N36 — PCF ⇔ UDR（ポリシーデータの永続化アクセス）¶

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

学習目標¶

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

N36が PCF（ポリシー決定層） と UDR（データ格納層） を結ぶ SBI（Service Based Interface） であることを説明できる。
PCFがN7/N15/N5でポリシー決定する際に参照する 加入者別ポリシー/PCC基礎データの実体がUDRにあることを説明できる。
N36の実体がUDRの提供するサービス Nudr_DataRepository（TS 29.504／ポリシーデータモデルはTS 29.519） であることを説明できる。
N35（UDM）/N36（PCF）/N37（NEF）が同じNudr_DataRepositoryで、利用側NFと格納データ種別が違うだけであることを説明できる。
4G(EPC)の SPR/UDR（PCRF向けデータ） との対応関係を説明できる。

前提知識¶

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

SBA / SBI と HTTP/2・TLS の位置づけ → Protocol辞典
N36の両端のNF → PCF / UDR
PCFがポリシー決定に使う参照点 → N7 / N15
同じNudr_DataRepositoryを使う兄弟インターフェース → N35 / N37
Interfaceと参照点の考え方 → Interface辞典

Why — なぜ必要なのか¶

PCFは「この加入者・このセッションをどう扱うか」というポリシーを決定するNFです。しかしその判断材料となる 加入者別ポリシー・PCC基礎データ・使用量監視の閾値 といったデータを、PCF自身がずっと抱え込んでしまうと問題が起きます。PCFが複数台に増えたりリスタートしたりすると、どのPCFが最新の加入者データを持っているか分からなくなり、データの一貫性が崩れるからです。

そこで5GCは、ポリシー決定の「ロジック」と、その材料である「データ」を分離しました。データの永続化（保管）は専用の格納層 UDR が担い、PCFは必要なときにUDRから取り寄せて判断します。この「PCFがUDRへポリシーデータを読み書きする道」がN36です。N36が無ければ、PCFは加入者別のポリシーを永続的に共有できず、ステートレスな決定層として振る舞えません。

例え話: N36は、方針決定者（PCF）と資料室（UDR）をつなぐ通路です。方針（ポリシー）を決めるPCFは、判断材料（加入者別ポリシー）を自分の机に貯め込まず、必要なたびに資料室（UDR）から取り寄せます（N36）。決めるのはPCF、しまっておくのはUDR、という役割分担です。

Overview — 概要¶

N36は PCF ⇔ UDR を結ぶ参照点で、SBI（Service Based Interface） です。したがって共通の転送として HTTP/2 + JSON（RESTful）over TLS を用います。

N36の実体は、UDRが提供するサービス Nudr_DataRepository です。UDRは「あらゆる利用側NFにデータの永続化サービスを提供する汎用の格納層」であり、PCFはそのNudr_DataRepositoryを使ってポリシーデータ（加入者別ポリシー、PCC基礎データ、使用量監視閾値等）をQuery（参照）・Create・Update・Delete・Subscribe（変更通知購読）します。ポリシーデータの共通枠組みは TS 29.504、ポリシーデータ用のデータモデルは TS 29.519 で定義されます（章番号は要確認）。

N36はNudr_DataRepositoryの2つの見方

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

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

UDRは汎用のデータ格納層であり、利用側NFごとに異なる参照点名が付いています。N35＝UDM⇔UDR（加入者データ・認証データ等）、N36＝PCF⇔UDR（ポリシーデータ）、N37＝NEF⇔UDR（アプリ由来の構造化データ等）です。3つとも実体は同じ Nudr_DataRepository で、利用側NFと、そこで扱うデータ種別（論理区分）が違うだけです。この論理区分名の細部は要確認とします。

Basic Concept — 初心者向け説明¶

N36を、方針決定者と資料室に例えます。

あなたのスマホがデータ通信を始めるとき、規約部門の PCF が「この客をどんな品質・課金・優先度で扱うか」という方針（ポリシー）を決めます。しかしPCFは、その判断に使う会員名簿や規約集（加入者別ポリシー・PCC基礎データ）を自分の机に貯め込みません。必要になるたびに、資料室（UDR）へ取りに行きます。これがN36です。

資料室（UDR）は、方針を決める部門（PCF）だけでなく、加入者情報を管理する部門（UDM）やアプリ連携部門（NEF）にも同じように資料を貸し出す共用の書庫です。PCFが使う通路がN36、UDMが使う通路が N35、NEFが使う通路が N37 というだけで、書庫そのもの（Nudr_DataRepository）は同じです。

この資料の取り寄せは、専用の電話回線ではなく、社内Webシステム（HTTP）でリクエストを投げて回答をもらうイメージです。これが SBI（Service Based Interface）＝NF同士がWeb API（HTTP/2）で会話する仕組みで、要求も応答も人間に読みやすい JSON でやり取りされます。閾値の変更などを「更新があったら知らせて」と購読（Subscribe）しておけば、UDR側の変化がPCFへ通知されます。

Protocol / Transport¶

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

N35/N37と同じSBIスタック

N36はSBIなので、他のSBI（N7/N15/N35/N37 等）と同じく HTTP/2 over TLS を共通の土台として使います。N35・N36・N37は同じNudr_DataRepositoryを指すため、Transport・プロトコルスタックも共通です。したがってN36の解析にSCTP固有のフィルタやポート番号を流用してはいけません。

Architecture¶

N36がPCF（決定層）とUDR（データ層）を結び、PCFがN7/N15でポリシー決定を行う一方、UDRが同じNudr_DataRepositoryをN35/N37でも提供する文脈を示します。

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

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

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

図の読み方: 太い線(==>)のN36が、決定層のPCFとデータ層のUDRを結ぶ「ポリシーデータの取り寄せ」です。PCFはN7（SMF）・N15（AMF）でポリシー要求を受け、その判断材料をN36でUDRから取り出します。UDRは同じNudr_DataRepositoryを、UDMにはN35、NEFにはN37として提供します（点線）。「決めるPCF」と「しまうUDR」の分離、そしてN35/N36/N37が同じ書庫（Nudr）の別入口である点に注目してください。

利用Procedure¶

N36は、PCFがポリシー決定を行うライフサイクルの中で、UDRへポリシーデータを読み書きする際に使われます。

ポリシーデータの取得（Query）: PCFが N7（SM Policy）や N15（AM Policy）でポリシー要求を受けた際、内部でN36を用いてUDRから該当する加入者別ポリシー/PCC基礎データをQueryし、ポリシー決定に反映する。
ポリシーデータの更新（Update）＋変更通知（Subscribe）: 使用量監視の閾値や加入者別ポリシーが変わる場合、PCFがN36でUpdateし、また関連データの変更をSubscribeして通知を受領する。
作成/削除（Create/Delete）: 必要に応じてポリシーデータ関連リソースをCreate/Deleteする。

各オペレーションの正確なメソッド・リソースURI・呼び出し方向・条件の細部は要確認とします。PCFのポリシー決定手順そのものは N7 / N15 側に集約されており、N36はその内部で使われる「データ取り寄せ」の道です。

主なMessage¶

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

サービスオペレーション（概念例）	用途
Nudr_DataRepository_Query	加入者別ポリシー/PCC基礎データの参照
Nudr_DataRepository_Create	ポリシーデータ関連リソースの生成
Nudr_DataRepository_Update	使用量監視閾値・加入者別ポリシー等の更新
Nudr_DataRepository_Delete	ポリシーデータ関連リソースの削除
Nudr_DataRepository_Subscribe	データ変更通知の購読（変更をPCFへ通知）

オペレーション名・対応は概念整理です: 上表のオペレーション区分は理解のための概念例であり、正確なオペレーション名・メソッド・リソースURI・呼び出し方向はTS 29.504／TS 29.519のOpenAPI定義に従います。細目は Release により差異があるため要確認とします。各メッセージの詳細は Message辞典を参照してください。

Packet Analysis (Wireshark)¶

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

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

Decodeの見どころ:

N36は TLSで暗号化されます。中身（HTTP/2ヘッダやJSONボディ）を見るには復号鍵（TLSセッションキー等）が必要です。鍵が無ければ tls の暗号化ペイロードとしてしか見えません。
復号できれば、HTTP/2の ヘッダ（:method、:path にNudr_DataRepositoryのリソースパスを含む）でオペレーションを識別できます。
ボディは JSON（ポリシーデータのデータモデル、TS 29.519）で、人間に読みやすい構造で入っています。
N35/N37と同じNudr_DataRepositoryなので、パケット上は同種のHTTP/2として見えます。利用側NF（PCF）とデータ種別（ポリシーデータ）で文脈を切り分けます。SCTP固有のフィルタ（sctp.port 等）は使いません。

EPCとの比較¶

4Gでは: PCRF向けの加入者ポリシーデータは SPR（Subscription Profile Repository） や後継の UDR に格納され、PCRFとは Sp（PCRF⇔SPR）や Ud（⇔UDR）で連携していました（プロトコルはDiameter/LDAP系など実装により差異）。
5Gでは: PCRFの役割を PCF が引き継ぎ、そのポリシーデータの格納は共用の UDR に集約され、PCF⇔UDRの連携が N36（Nudr_DataRepository） に SBI化されました。データモデルは TS 29.519 で定義されます。

4G (EPC)	5G (5GC)
Sp（PCRF ⇔ SPR） / Ud（⇔ UDR）	N36（PCF ⇔ UDR, SBI: Nudr_DataRepository）
Diameter / LDAP系（実装依存）	SBI: HTTP/2 + JSON over TLS
—（データモデル規定は別体系）	TS 29.519（ポリシーデータモデル）
SPR / UDR（PCRF向けデータ格納）	UDR（汎用データ層、N35/N36/N37で共用）

4GのSPR/UDR（PCRF向けデータ）が5GでUDR+N36に: 4Gでは加入者ポリシーデータの格納がSPR/UDRとして存在し、5Gでは共用UDRへ集約され、PCFからのアクセスがN36としてSBI化されました。この対応関係は概念整理であり、細部は要確認とします。

3GPP Specification¶

3GPP TS 29.504 — Nudr_DataRepository サービス（UDRのデータアクセス共通枠組み）。個別章番号は要確認
3GPP TS 29.519 — ポリシー・課金制御に関するデータ（ポリシーデータ用のデータモデル、N36で扱うデータ）。個別章番号は要確認
3GPP TS 23.501 §6.2.4（PCF）/ §6.2.11（UDR）— NFの定義と役割
3GPP TS 23.503 — ポリシー・課金制御フレームワーク（PCC framework）
3GPP TS 29.500 / TS 29.501 — SBI framework（技術規約 / 設計原則・OpenAPI）。個別章番号は要確認
3GPP TS 33.501 — SBIのセキュリティ（TLS等）。個別章番号は要確認

注記（要確認）: N36の実体が Nudr_DataRepository（TS 29.504、ポリシーデータモデルはTS 29.519）であること、N35/N36/N37が同じNudr_DataRepositoryで利用側NFが違うだけであること、参照点N36とサービスNudrが同じ連携の2つの見方であることは、3GPPアーキテクチャの一般的整理です。各オペレーションの細目・正確なリソースURI・ポリシーデータの論理区分名は Release により差異があるため個別には要確認とします。

Summary¶

N36は PCF ⇔ UDR を結ぶ SBI（Service Based Interface） で、Protocolは HTTP/2 + JSON over TLS。
PCFはポリシー決定ロジック層、UDRはデータ格納層であり、PCFが判断に使う加入者別ポリシー/PCC基礎データの実体はUDRに永続化されている（決定層/データ層の分離）。
N36の実体はUDRのサービス Nudr_DataRepository（共通枠組みTS 29.504／ポリシーデータモデルTS 29.519）。
N35（UDM）/N36（PCF）/N37（NEF）は同じNudr_DataRepositoryで、利用側NFと格納データ種別が違うだけ。
4Gの SPR/UDR（PCRF向けデータ） に相当し、5GではUDRへ集約されPCFアクセスがN36として SBI化された。

Next Step¶

PCF — N36の利用側。ポリシー決定の中枢（決定層）
UDR — N36の相手側。ポリシーデータを永続化する格納層
N7 — PCFがSMポリシー決定に使う参照点（N36で取り寄せたデータを反映）
N35 — 同じNudr_DataRepositoryをUDMが使う参照点
Interface辞典 — N37ほか参照点の確認