N35 — UDM ⇔ UDR（加入データの永続化アクセス）¶

学習目標¶

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

• N35が UDM（機能層） から UDR（データ層） へ加入者データを読み書きする SBI（Service Based Interface） であることを説明できる。
• 5Gで UDM（ロジック）＋UDR（永続化） に機能とデータが分離され、UDMがN8/N10/N13で外部NFに見せるデータの実体はUDRにあることを説明できる。
• N35の実体がUDRの提供するサービス Nudr_DataRepository（TS 29.504 / 29.505） であることを説明できる。
• 4G(EPC)の HSS（機能とデータを一体保有） から、5Gで UDM＋UDR分離 へ進化した対応関係を説明できる。
• N35（UDM）／N36（PCF）／N37（NEF） が同じNudr_DataRepositoryへのアクセスで、利用側NFと格納データ種別だけが違うことを説明できる。

前提知識¶

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

• SBA / SBI と HTTP/2・TLS の位置づけ → Protocol辞典
• N35の両端のNF → UDM / UDR
• UDMが外部NFへデータを見せるIF → N8 / N10 / N13
• Interfaceと参照点の考え方 → Interface辞典

Why — なぜ必要なのか¶

UDMは、AMFへ加入情報を渡し(N8)、SMFへセッション加入データを渡し(N10)、AUSFへ認証データを渡します(N13)。しかし、これらの加入者データをUDM自身が抱え込むと、機能ロジック（データの解釈・提供の仕方）とデータの格納が一体化し、データを冗長化・拡張・共有したいときにUDMごと作り替える羽目になります。

そこで5Gでは、加入者データの実体を格納する専用の器として UDR(Unified Data Repository)を切り出し、UDMは機能ロジックだけを担う設計にしました。UDMが外部に見せるデータの実物はUDRに永続化され、UDMは必要なときにUDRから出し入れします。このUDM⇔UDR間のデータアクセス経路がN35です。N35が無ければ、UDMは自前のストレージにデータを持つしかなく、5Gが狙った「機能とデータの分離」が成立しません。

例え話: N35は、窓口係（UDM）と書庫（UDR）をつなぐ搬送経路です。窓口係は利用者対応（N8/N10/N13）をしますが、書類の実物は書庫（UDR）に保管されており、窓口係は必要な書類を書庫へ出し入れ（N35）して応対します。

Overview — 概要¶

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

N35の実体は、UDRが提供するサービス Nudr_DataRepository（TS 29.504 / TS 29.505） です。UDMはこのサービスを呼び出し、認証データ・アクセス&モビリティ加入・SM加入といった加入者データを、UDR上のリソースとして Query（読み出し）／Create／Update／Delete、さらに変更通知の Subscribe で読み書きします。UDMは機能ロジック層、UDRはデータ格納層という役割分担が、N35の本質です。

Basic Concept — 初心者向け説明¶

N35を、窓口係（UDM）と書庫（UDR）の搬送に例えます。

あなたのスマホがネットワークに登録・接続しようとすると、加入情報を提供する窓口係（UDM）が動きます。窓口係は、AMFやSMFやAUSF（利用者）に対して「この加入者はこういう契約・こういう認証情報です」と応対します（N8/N10/N13）。しかし窓口係は書類の実物を自分の机には置いていません。書類（加入者データの実体）は書庫（UDR）に保管されているので、窓口係は要求が来るたびに書庫へ「この加入者の書類を出して」と取りに行き（Query）、内容が変わったら書庫の書類を差し替えます（Update）。この窓口係⇔書庫の搬送経路が N35 です。

この搬送は、専用の電話回線（N2やN4のような専用プロトコル）ではなく、社内Webシステム（HTTP）でリクエストを投げて回答をもらうイメージです。これが SBI（Service Based Interface）＝NF同士がWeb API（HTTP/2）で会話する仕組みです。要求も応答も、人間に読みやすい JSON という書式でやり取りされます。操作対象（加入者データのレコード）に「住所（URI）」を与え、そこにGET/PUT/PATCH/DELETEなどを投げて読み書きします。

ポイントは、機能（UDM）とデータ（UDR）を分けたことです。窓口係は「どう応対するか」というロジックに専念し、書庫は「どう安全に大量保管するか」に専念できます。

Protocol / Transport¶

Architecture¶

N35がUDM（機能層）とUDR（データ層）を結び、UDMがN8/N10でAMF/SMFへ応対し、UDRが同じNudr_DataRepositoryをN36/N37でPCF/NEFにも提供する文脈を示します。

flowchart LR
  AMF["AMF"]
  SMF["SMF"]
  UDM["UDM (機能層)"]
  UDR[("UDR (データ層)")]
  PCF["PCF"]
  NEF["NEF"]

  AMF -."N8".- UDM
  SMF -."N10".- UDM
  UDM =="N35 (Nudr: DataRepository)"==> UDR
  PCF -."N36".- UDR
  NEF -."N37".- UDR

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

図の読み方: 太い線(==>)のN35がUDM⇔UDRのデータアクセス（SBI/HTTP2）です。UDMは左側でN8(AMF)・N10(SMF)などの外部要求に応対しますが、その加入者データの実体はUDRにあり、UDMはN35で出し入れします。右下では、同じUDRが提供するNudr_DataRepositoryを N36でPCFが（ポリシーデータ）／N37でNEFが（構造化データ） 利用します。UDMは「応対する機能」、UDRは「保管するデータ」という役割分担に注目してください。

利用Procedure¶

N35は、UDMが外部NFからのデータ要求を処理する裏側で、UDRとの間で使われます。

• データ読み出し（Query）: UDMがN8のSDM Get等の外部要求を受けた際、内部でN35を用いUDRから該当加入者データ（認証データ／アクセス&モビリティ加入／SM加入 等）を Query し、UDMが加工して応答する。
• データ生成・更新（Create / Update）: 加入者データの登録・変更が生じた際、UDMがN35でUDR上のレコードを Create / Update し、永続化する。
• 変更通知の購読（Subscribe / Notify）: UDMがUDRのデータ変更を継続的に把握したい場合、Subscribe して変更通知（Notify）を受ける。

各オペレーションの正確なメソッド・リソースURI・呼び出し方向、および上記の対応づけの細部は要確認です（TS 29.504 / 29.505 のOpenAPI定義に従います）。手順全体の中でのUDMの役割は UDM を参照してください。

主なMessage¶

N35はSBIなので、メッセージはHTTPメソッド + リソース操作の形を取ります。UDRのサービス Nudr_DataRepository の代表的なオペレーション（いずれも概念例・細部は要確認）は次のとおりです。

オペレーション対応は概念整理です: 上表のオペレーション名・粒度は理解のための概念例であり、正確なオペレーション名・メソッド・リソースURIはTS 29.504 / 29.505 のOpenAPI定義に従います。厳密な割り当ては要確認とします。各メッセージの詳細は Message辞典 を参照してください。

Packet Analysis (Wireshark)¶

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

Decodeの見どころ:

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

EPCとの比較¶

• 4Gでは: 加入者データの管理は HSS（Home Subscriber Server） が担い、機能（データの提供ロジック）とデータ（実体の格納）を一体で保有していました。HSS内部のデータ格納層は標準化された外部インタフェースとしては公開されておらず、機能とデータは分離されていませんでした。
• 5Gでは: HSSの役割が UDM（機能層）＋UDR（データ層） に分離され、両者を結ぶ内部インタフェースが N35（Nudr_DataRepository） として SBI化されました。データの実体はUDRに永続化され、UDMは機能ロジックに専念します。

4GのHSSが機能とデータを一体で持っていた構成が、5Gでは UDM（機能）＋UDR（データ）に分離され、その間を N35 が結びます。これにより、データの冗長化・共有（同じUDRをN36/N37でPCF/NEFも利用）が可能になりました。

3GPP Specification¶

• 3GPP TS 29.504 — Nudr_DataRepository サービス（UDRのデータアクセス共通枠組み、N35/N36/N37共通）。個別章番号は要確認
• 3GPP TS 29.505 — 加入データ用のデータモデル（UDRに格納する加入者データの構造）。個別章番号は要確認
• 3GPP TS 29.500 / TS 29.501 — SBI framework（技術規約 / 設計原則・OpenAPI）。個別章番号は要確認
• 3GPP TS 23.501 §6.2.7（UDM）/ §6.2.11（UDR）— NFの定義と役割
• 3GPP TS 33.501 — SBIのセキュリティ（TLS等）。個別章番号は要確認

注記（要確認）: N35の実体が Nudr_DataRepository（TS 29.504／データモデルは TS 29.505）であること、同サービスがN35/N36/N37で共通に用いられること、参照点N35とサービスNudrが同じ連携の2つの見方であることは、3GPPアーキテクチャの一般的整理です。各オペレーション名・リソースURI・データの論理分割の細目章番号は Release により差異があるため個別には要確認とします。

Summary¶

• N35は UDM ⇔ UDR を結ぶ SBI（Service Based Interface） で、Protocolは HTTP/2 + JSON over TLS。
• 5Gで UDM（機能ロジック層）＋UDR（データ格納層） に機能とデータが分離され、UDMがN8/N10/N13で外部NFに見せる加入者データの実体はUDRに永続化されている。
• N35の実体はUDR提供のサービス Nudr_DataRepository（TS 29.504／データモデル TS 29.505） で、UDMはこれで加入データをQuery/Create/Update/Delete/Subscribeする（細部要確認）。
• 4Gの HSS（機能＋データ一体） が、5Gでは UDM＋UDRに分割され、その内部IFがN35。
• N35（UDM）／N36（PCF）／N37（NEF） は同じNudr_DataRepositoryへのアクセスで、利用側NFと格納データ種別が違うだけ。

Next Step¶

• UDM — N35の機能層側。加入者データを外部NFへ提供するロジックの中枢
• UDR — N35のデータ層側。加入者データを永続化しNudr_DataRepositoryを提供
• N36 — PCF⇔UDR。同じNudr_DataRepositoryでポリシーデータにアクセス
• N37 — NEF⇔UDR。同じNudr_DataRepositoryで構造化データにアクセス
• Interface辞典 — N8/N10/N13 ほか参照点の確認