N37 — NEF ⇔ UDR（構造化データの格納アクセス）¶

難易度: 中級／想定学習時間: 12分／接続点: NEF ⇔ UDR ／ Protocol: SBI (HTTP/2 over TLS) ／関連Interface: N33, N35, N36

学習目標¶

このページを読み終えると、次のことができるようになります。

N37が NEF（能力公開ゲートウェイ） と UDR（データ層） を結ぶ SBI（Service Based Interface） であり、構造化データの格納アクセスに使われることを説明できる。
N37の実体がUDRの提供するサービス Nudr_DataRepository（TS 29.504） であることを説明できる。
NEFが外部AFから預かる/外部へ見せる 構造化データ（Application Data・外部パラメータプロビジョニング・パケットフロー記述等） をUDRへ永続化する流れを説明できる。
N35（UDM）／N36（PCF）／N37（NEF）が同じNudr_DataRepository で、利用側NFと格納データ種別が違うだけであることを説明できる。
4G（EPC）に明確な1対1対応が薄く、能力公開のデータ集約が5GでUDR+N37に整理された経緯を（要確認を含め）説明できる。

前提知識¶

先に以下を理解しておくとスムーズです。

SBA / SBI と HTTP/2・TLS の位置づけ → Protocol辞典
N37の両端のNF → NEF / UDR
能力公開（外部AFへの公開・外部からのプロビジョニング）の考え方 → N33
UDRを共有する他のSBI → N35（UDM⇔UDR）/ N36（PCF⇔UDR）
Interfaceと参照点の考え方 → Interface辞典

Why — なぜ必要なのか¶

NEF（Network Exposure Function）は、5GC内部の能力を外部のAF（Application Function）へ安全に公開する窓口です。逆に、外部AFがネットワークへ設定（プロビジョニング）する経路にもなります。このとき、外部から預かった値や外部へ見せる値——たとえば Application Data・外部パラメータプロビジョニング・パケットフロー記述（Packet Flow Description） 等の構造化データ——は、その場限りで消えては困ります。他NFが後から参照したり、変更を追跡したりできるよう、どこかに永続化しておく必要があります。

しかしNEF自身がデータベースを抱え込むと、データが各NFに散らばり、一貫性の管理が破綻します。5GCはデータ層を UDR に集約する設計を採るため、NEFは自前でデータを持たず、UDRへ構造化データを読み書きする道を使います。これがN37です。N37が無ければ、NEFは外部から預かったデータを保管する共通の置き場を持てず、能力公開で扱うデータの一貫性・共有性が確保できません。

例え話: N37は、受付窓口（NEF）と倉庫（UDR）をつなぐ搬入・搬出路です。外部の客（AF）から預かった荷物（Application Data 等）を、受付は自席に抱え込まず倉庫へ運んで保管し（Create/Update）、必要になれば倉庫から取り出します（Query）。倉庫は他の窓口（UDM/PCF）も共同で使う共通倉庫です。

Overview — 概要¶

N37は NEF ⇔ UDR を結ぶ参照点で、SBI（Service Based Interface） です。SBIとはNF同士がWeb API（HTTP）でサービスを呼び合う仕組みで、共通の転送として HTTP/2 + JSON（RESTful）over TLS を用います。

N37の実体は、UDRが提供するサービス Nudr_DataRepository（TS 29.504） です。NEFはこのサービスを呼び出し、能力公開に伴う構造化データをUDRへ格納（Create/Update）・参照（Query）・削除（Delete）し、変更をSubscribeするというCRUD的な操作を行います。TS 29.504ではこの用途のデータが "Structured Data for exposure"（能力公開向け構造化データ） として整理されています。

参照点N37とサービスNudr_DataRepositoryは同じものの2つの見方

3GPPのアーキテクチャ図では 参照点として N37（NEF⇔UDR） が示されますが、SBA（サービス化）ではこれが実体として UDRのサービス Nudr_DataRepository として実装されます。つまり「N37」と「Nudr_DataRepository」は、同じNEF⇔UDR間の連携を、参照点の視点／サービスの視点で見たものです。どちらも指しているものは同一で、呼び方（視点）が違うだけ、と捉えてください。

N35 / N36 / N37 は同じNudr_DataRepository（利用側と格納データ種別が違うだけ）

UDRはデータ層として複数のNFに共有され、いずれも同じサービス Nudr_DataRepository を提供します。違うのは利用側NFと格納されるデータ種別だけです。
・N35 = UDM ⇔ UDR：加入者データ（Subscription Data）
・N36 = PCF ⇔ UDR：ポリシーデータ（Policy Data）
・N37 = NEF ⇔ UDR：能力公開向けの構造化データ（Application Data 等）
「N35/N36/N37は別物のインターフェースだが、実体は同じNudr_DataRepositoryで、どのNFがどの区分のデータを読み書きするかが違う」と理解してください。

Basic Concept — 初心者向け説明¶

N37を、受付窓口と共通倉庫のやり取りに例えます。

外部のアプリ事業者（AF）が「この加入者のこのフローはこう扱ってほしい」といった設定を持ち込むと、受付である NEF が N33 経由でそれを受け取ります。ですが受付は書類を自席に溜め込みません。共通倉庫である UDR へ運んで保管します。これがN37です。逆に外部へ何かを見せるときも、倉庫から取り出して渡します。

この倉庫は受付（NEF）専用ではなく、名簿係（UDM）や規約係（PCF）も同じ倉庫を使います。棚（データ区分）が違うだけで、倉庫も出し入れの作法も同じ——それが「N35/N36/N37は同じNudr_DataRepository」という意味です。

倉庫への出し入れは、専用の電話回線（N2やN4のような専用プロトコル）ではなく、社内Webシステム（HTTP）でリクエストを投げて結果をもらうイメージです。これが SBI（Service Based Interface）＝NF同士がWeb API（HTTP/2）で会話する仕組みで、やり取りは人間に読みやすい JSON 書式で行われます。操作対象（データ）に「住所（URI）」を与え、POST/PUT/DELETE等のHTTP操作で作成・更新・削除する作法をRESTfulと呼びます。

Protocol / Transport¶

項目	内容
Protocol	HTTP/2 + JSON（RESTful）— SBI（Service Based Interface）の共通スタック
サービス	Nudr_DataRepository（UDRが提供）— TS 29.504（Structured Data for exposure を含む）
SBI framework	TS 29.500 / TS 29.501 系（SBIの共通規約・OpenAPI定義）
下位Transport	TCP、TLS で保護（機密性・完全性・認証）— TS 33.501
ポート	SBIの待受ポートは実装依存（NRF登録のエンドポイントで解決）。特定番号は断定しない
特徴	専用L4プロトコルではなくWeb技術ベース。HTTPメソッド(POST/PUT/DELETE)＋リソースURIで操作。RESTful

N2/N4のような専用L4ではなくWeb技術ベース

N2は NGAP over SCTP、N4は PFCP over UDP という専用の下位プロトコルを持ちますが、N37にはそれらは一切当てはまりません。N37はSBIなので、他のSBI（N35/N36/N33 等）と同じく HTTP/2 over TLS を共通の土台として使います。したがってN37の解析にSCTP固有のフィルタやポート番号を流用してはいけません。

Architecture¶

N37がNEFとUDRを結び、NEFがN33で外部AFと接し、同じUDRをUDM（N35）・PCF（N36）も共有する文脈を示します。

flowchart LR
  AF["AF (外部アプリ)"]
  NEF["NEF (能力公開GW)"]
  UDR[("UDR (データ層)")]
  UDM["UDM"]
  PCF["PCF"]

  AF -. "N33" .- NEF
  NEF == "N37 (Nudr: DataRepository)" ==> UDR
  UDM -. "N35" .- UDR
  PCF -. "N36" .- UDR

  classDef ctrl fill:#efe,stroke:#3a3,stroke-width:2px;
  class NEF,UDR ctrl;

図の読み方: 太い線(==>)のN37がNEF⇔UDRの構造化データ格納アクセス（SBI/HTTP2、実体はNudr_DataRepository）です。NEFは点線のN33で外部AFと接し、そこで預かった/外部へ見せるデータの内部保管にN37を使います。同じUDRを、UDMがN35で（加入者データ）、PCFがN36で（ポリシーデータ）共有している点に注目してください。N35/N36/N37はどれも同じNudr_DataRepositoryで、格納するデータ種別が違うだけです。

利用Procedure¶

N37は、能力公開に伴う構造化データの永続化の局面でNEFがUDRを読み書きする際に使われます（細部は要確認）。

プロビジョニングの永続化: 外部AFが N33 経由でNEFへデータ（外部パラメータ・Application Data 等）をプロビジョニングすると、NEFがN37でUDRへ Create/Update して永続化する。
他NFからの参照: 他NFが同じデータを参照する際も、直接NEFに聞くのではなくUDR経由でアクセスする（UDRがデータ層として集約）。
変更通知（Subscribe/Notify）: データ変更を関心のあるNFへ通知する必要がある場合、Subscribe しておき、変更発生時に通知を受ける。

これらオペレーションの正確な呼び出し方向・条件・IE、および各データ区分の扱いは、能力公開手順の詳細に依存します。手順の細部（メッセージシーケンス・章番号等）は要確認とし、本ページでは概念的な位置づけに留めます。

主なMessage¶

N37はSBIなので、メッセージはHTTPメソッド + リソース操作の形を取ります（NGAPのようなprocedureCodeではなくRESTful操作）。Nudr_DataRepositoryの代表的なサービスオペレーションは次のとおりです（いずれも概念例。正確なメソッド・URI・区分名は要確認）。

サービスオペレーション(概念例)	HTTP操作(概念例)	用途
Nudr_DataRepository_Query	GET（リソース取得）	構造化データ（Application Data 等）の参照
Nudr_DataRepository_Create	PUT/POST（リソース生成）	プロビジョニングされたデータの新規格納
Nudr_DataRepository_Update	PATCH/PUT（更新）	既存の構造化データの変更
Nudr_DataRepository_Delete	DELETE（削除）	不要になったデータの削除
Nudr_DataRepository_Subscribe	POST（購読登録・通知callback）	データ変更の購読と通知受信

オペレーション・HTTP操作の対応は概念整理です: 上表のオペレーション名・「HTTP操作」・データ区分名（Application Data 等）は理解のための対応づけであり、正確なメソッド・リソースURI・呼び出し方向・区分名はTS 29.504のOpenAPI定義に従います。厳密な割り当ては要確認とします。各メッセージの詳細は Message辞典を参照してください。

Packet Analysis (Wireshark)¶

N37はSBIなので、キャプチャ上は HTTP/2 として観測されます（NGAP/SCTPのようなL4専用プロトコルは現れません）。

目的	Display Filter
HTTP/2メッセージを抽出	`http2`
ヘッダのパスで絞る（概念）	`http2.headers.path`（`:path` に `nudr-dr` を含む）
JSONボディを見る	`json`（復号後）

Decodeの見どころ:

N37は TLSで暗号化されます。中身（HTTP/2ヘッダやJSONボディ）を見るには復号鍵（TLSセッションキー等）が必要です。鍵が無ければ tls の暗号化ペイロードとしてしか見えません。
復号できれば、HTTP/2の ヘッダ（:method、:path に Nudr_DataRepository のリソースパスを含む）でオペレーションを識別できます（パス表記は要確認）。
ボディは JSON（構造化データ／Application Data 等）で、人間に読みやすい構造で入っています。
N2のNGAP（バイナリ、SCTP上）と違い、N37はWeb的（HTTP/JSON）である点が観察の要です。SCTP固有のフィルタ（sctp.port 等）は使いません。

EPCとの比較¶

4Gでは: 能力公開（Exposure）の窓口は SCEF（Service Capability Exposure Function） が担いましたが、能力公開で扱うデータを標準的に集中保管する共通データ層の位置づけは薄く、NEF⇔UDR（N37）に明確に1対1対応するインターフェースは見当たりません。能力公開そのものがRel-15前後で整理が進んだ、比較的新しい概念寄りです。
5Gでは: 能力公開の窓口を NEF が担い、扱う構造化データをデータ層 UDR に集約し、その読み書きを N37（Nudr_DataRepository, TS 29.504） として整理しました。データの一貫性・共有性がUDR集約で確保されます。

4G (EPC)	5G (5GC)
SCEF周辺（能力公開のデータ保管は明確な標準対応が薄い）	N37（NEF ⇔ UDR、SBI: Nudr_DataRepository）
—（1対1対応薄い）	SBI: HTTP/2 + JSON over TLS
—（該当規格が明確でない）	TS 29.504（Nudr_DataRepository）
対応薄い／集中保管の標準が明確でない	UDRにデータ集約（データ層の分離）

注記（要確認／相当なし）: 4G側でN37に明確に対応するインターフェースは特定しにくく、相当なし〜要確認とするのが正直な整理です。ポイントは、4Gでは能力公開データの標準的な集中保管が薄かったのに対し、5GではUDR＋N37に整理されたという点です。個別の対応関係の断定は避けます。

3GPP Specification¶

3GPP TS 29.504 — Nudr_DataRepository サービス（Unified Data Repository Services、"Structured Data for exposure" を含む。N35/N36/N37共通）。個別章番号は要確認
3GPP TS 29.500 / TS 29.501 — SBI framework（技術規約 / 設計原則・OpenAPI）。個別章番号は要確認
3GPP TS 23.501 §6.2.5 — NEF（Network Exposure Function）の機能定義（節番号は要確認）
3GPP TS 23.501 §6.2.11 — UDR（Unified Data Repository）の機能定義（節番号は要確認）
3GPP TS 23.502 — 能力公開・プロビジョニング手順（該当手順の章番号は要確認）
3GPP TS 33.501 — SBIのセキュリティ（TLS等）。個別章番号は要確認

注記（要確認）: N37の実体が Nudr_DataRepository（TS 29.504）であること、N35/N36/N37が同一サービスの利用側違いであることは3GPPアーキテクチャの一般的整理です。各オペレーションの正確なメソッド・リソースURI・データ区分名・節番号はReleaseにより差異があるため、個別には要確認とします。

Summary¶

N37は NEF ⇔ UDR を結ぶ SBI（Service Based Interface） で、能力公開に伴う構造化データの格納アクセスに使う。Protocolは HTTP/2 + JSON over TLS。
N37の実体はUDRのサービス Nudr_DataRepository（TS 29.504、Structured Data for exposure） ＝参照点N37とサービスNudrは同じ連携の2つの見方。
NEFは外部AFから預かる/外部へ見せる Application Data・外部パラメータプロビジョニング・パケットフロー記述等をUDRへ Create/Update/Query/Delete/Subscribe（細部は要確認）で永続化する。
N37はNEFが N33 で外部AFと接する能力公開の裏方（内部データ保管）であり、N35（UDM）／N36（PCF）／N37（NEF）は同一のNudr_DataRepositoryで格納データ種別が違うだけ。
4Gには明確な1対1対応が薄く（相当なし〜要確認）、能力公開データの集中保管が5GでUDR＋N37に整理された。

Next Step¶

NEF — N37の利用側。外部AF向け能力公開のゲートウェイ
UDR — N37の相手側。Nudr_DataRepositoryを提供するデータ層
N33 — NEFが外部AFと接する能力公開インターフェース（N37はその裏方）
N35 — UDM⇔UDR。N37と同じNudr_DataRepository（加入者データ）
Interface辞典 — 参照点・SBIの一覧確認