N15 — AMF ⇔ PCF（Npcf_AMPolicyControl 参照点）¶

難易度: 中級／想定学習時間: 15分／接続点: AMF ⇔ PCF ／ Protocol: HTTP/2 + JSON (SBI) ／関連Interface: N7, N5, N8

学習目標¶

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

N15が SBI（Service Based Interface） であり、N2(NGAP/SCTP)やN4(PFCP/UDP)とはProtocol/Transportが根本的に異なることを説明できる。
N15の実体がPCFの提供するサービス Npcf_AMPolicyControl（TS 29.507） であることを説明できる。
AMFが AM Policy Association を確立して アクセス&モビリティ関連ポリシー（RFSP、サービスエリア制限、移動制限等）を取得する流れを説明できる。
N7がSM（セッション管理）側ポリシーなら、N15はMM（モビリティ管理）側ポリシーという役割分担を説明できる。
「参照点N15」と「サービスNpcf_AMPolicyControl」が同じものの2つの見方であることを説明できる。

前提知識¶

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

SBA / SBI と HTTP/2・TLS の位置づけ → Protocol辞典
N15の両端のNF → AMF / PCF
SM側ポリシー(PCC rule)との対比 → N7
アクセス&モビリティ制御（移動制限・RFSP等）が効いてくる文脈 → Registration
Interfaceと参照点の考え方 → Interface辞典

Why — なぜ必要なのか¶

AMFはUEの登録・モビリティを管理する際、「この加入者はどのエリアで通信を許すか（サービスエリア制限）」「どのRAT/周波数を優先させるか（RFSP）」「移動をどこまで許容するか（移動制限）」を決めなければなりません。しかしこれらをAMF自身が勝手に決めると、事業者のアクセス&モビリティ規約（このプランはこの地域だけ、この端末はこの周波数優先等）を変えるたびにAMFを直す羽目になります。

そこで、事業者ポリシーの元締めである PCF に「この加入者のモビリティ・アクセスはどう扱う?」と問い合わせる道が要ります。これがN15です。AMFはN15でPCFに問い合わせ、PCFは加入者データ（UDR由来）や事業者規約から判断した アクセス&モビリティポリシー を返します。N15が無ければ（またはPCF連携しなければ）、AMFは静的な既定値でしかモビリティを扱えず、加入者ごとのきめ細かい動的なアクセス&モビリティ制御ができません。

例え話: N15は、移動管理の受付担当（AMF）が規約部門（PCF）に判断を仰ぐ専用回線です。受付は勝手に規約を決めず、この回線で「この客の移動制限・優先周波数は?」と問い合わせ、規約部門の回答に従って登録を進めます。N7がセッション担当（SMF）用の回線なら、N15はモビリティ担当（AMF）用の回線、というイメージです。

Overview — 概要¶

N15は AMF ⇔ PCF を結ぶ参照点です。ただしN15はSBI（Service Based Interface）である点が、N2(NGAP/SCTP)やN4(PFCP/UDP)と決定的に異なります。SBIとはNF同士がWeb API（HTTP）でサービスを呼び合う仕組みで、共通の転送として HTTP/2 + JSON（RESTful）over TLS を用います。

N15の実体は、PCFが提供するサービス Npcf_AMPolicyControl（TS 29.507） です。AMFはこのサービスを呼び出して AM Policy Association（アクセス&モビリティポリシーの結び付き）を確立し、認可された アクセス&モビリティ関連ポリシー（RFSP、サービスエリア制限、移動制限、UE-AMBR関連等）を取得します。

N7がSM側ポリシーなら、N15はMM側ポリシー

5Gのポリシー参照点は、扱う対象で2系統に分かれます。N7（SMF⇔PCF, Npcf_SMPolicyControl） は SM（セッション管理）側のポリシー＝PCC rule（QoS・課金・ゲーティング）を扱います。一方 N15（AMF⇔PCF, Npcf_AMPolicyControl） は MM（モビリティ管理）側のポリシー＝アクセス&モビリティ制御（RFSP・移動制限等）を扱います。両者は「PCFへポリシーを問い合わせるSBI」という点では同じ作法ですが、SM担当のN7とMM担当のN15という役割分担で対になっています。

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

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

Basic Concept — 初心者向け説明¶

N15を、移動管理受付と規約部門の問い合わせに例えます。

あなたのスマホがネットワークに登録しようとすると、モビリティ担当のAMFが動きます。AMFは「この客はどのエリアで通信を許す? どの周波数を優先させる? どこまで移動を許容する?」を自分では決めず、規約部門のPCFに問い合わせます（AM Policy Association の確立）。PCFは会員名簿（加入者データ）と会社の規約を照らし合わせ、アクセス&モビリティポリシー（RFSP・サービスエリア制限・移動制限等の指示）を返します。AMFはこの指示どおりに、UEの登録や移動制御を進めます。

このPCFへの問い合わせは、専用の電話回線（N2やN4のような専用プロトコル）ではなく、社内Webシステム（HTTP）でリクエストを投げて回答をもらうイメージです。これが SBI（Service Based Interface）＝NF同士がWeb API（HTTP/2）で会話する仕組みです。要求も応答も、人間に読みやすい JSON という書式でやり取りされます。

このWeb APIでは、操作対象（AM Policy Associationなどのリソース）に「住所（URI）」を与え、そこにPOSTなどのHTTP操作を投げて作成・更新・削除します。この作法をRESTfulと呼びます。

Protocol / Transport¶

項目	内容
Protocol	HTTP/2 + JSON（RESTful）— SBI（Service Based Interface）の共通スタック
サービス	Npcf_AMPolicyControl（PCFが提供）— TS 29.507
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:38412、N4は PFCP over UDP という専用の下位プロトコルを持ちますが、N15にはそれらは一切当てはまりません。N15はSBIなので、他のSBI（N7/N8/N10/N11 等）と同じく HTTP/2 over TLS を共通の土台として使います。したがってN15の解析にSCTP固有のフィルタやポート番号、PFCPを流用してはいけません。

Architecture¶

N15がAMFとPCFを結び、SM側のN7（SMF⇔PCF）と対になり、PCFがNudrで加入者ポリシーをUDRから取り出す文脈を示します。

flowchart LR
  AMF["AMF (MM)"]
  PCF["PCF"]
  SMF["SMF (SM)"]
  UDR[("UDR (ポリシーデータ)")]

  AMF == "N15 (Npcf_AMPolicyControl)" ==> PCF
  SMF -. "N7 (Npcf_SMPolicyControl)" .-> PCF
  PCF -. "Nudr (ポリシー取得)" .-> UDR

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

図の読み方: 太い線(==>)のN15がAMF⇔PCFのポリシー問い合わせ（SBI/HTTP2）で、MM（モビリティ管理）側のアクセス&モビリティポリシーを扱います。破線のN7はSMF⇔PCFでSM（セッション管理）側のPCC ruleを扱います。PCFはNudrで加入者ポリシーをUDRから取り出し、両方の問い合わせに答えます。N15＝MMポリシー、N7＝SMポリシーという役割分担に注目してください。

利用Procedure¶

N15は Registration（登録） のライフサイクルの中で、AMFがPCFへアクセス&モビリティポリシーを問い合わせる際に使われます。

AM Policy Association Establishment（確立）: Registration中、AMFがPCFへ Npcf_AMPolicyControl_Create で問い合わせ、アクセス&モビリティポリシー（RFSP・サービスエリア制限・移動制限等）を取得する。取得したポリシーに基づき、AMFはUEの移動制御や登録処理を進める。
AM Policy Association Modification（変更）: ポリシーが変わる場合（AMF起因の更新、またはPCFからの通知）に、Update / UpdateNotify でポリシーを更新する。
AM Policy Association Termination（解放）: UEの登録解除等で、AM Policy Associationを終了する。

このPCF連携は任意/条件付きで、動的なアクセス&モビリティポリシー構成のときに行われます。PCFと連携しない構成では、AMFの既定ポリシーで処理が継続されます（構成依存）。

手順の詳細な流れ（メッセージシーケンス、条件、IE等）は Registration の記述に集約されています。手順の細部はそちらを参照してください（細部は要確認）。

主なMessage¶

N15はSBIなので、メッセージはHTTPメソッド + リソース操作の形を取ります（NGAPのようなprocedureCodeではなくRESTful操作）。代表的なサービスオペレーションは次のとおりです。

サービスオペレーション	HTTP操作(概念例)	用途
Npcf_AMPolicyControl_Create	POST（リソース生成）	AM Policy Association確立、アクセス&モビリティポリシー取得
Npcf_AMPolicyControl_Update	POST（更新オペレーション呼び出し）	AMF起因のポリシー更新要求
Npcf_AMPolicyControl_UpdateNotify	POST（PCF→AMFへ通知callback）	PCFからAMFへのポリシー変更通知
Npcf_AMPolicyControl_Delete	DELETE（リソース削除）	AM Policy Association解放

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

Packet Analysis (Wireshark)¶

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

目的	Display Filter
HTTP/2メッセージを抽出	`http2`
ヘッダのパスで絞る（概念）	`http2.headers.path`（`:path` に `npcf-am-policy-control` を含む。正確な文字列は要確認）
JSONボディを見る	`json`（復号後）

Decodeの見どころ:

N15は TLSで暗号化されます。中身（HTTP/2ヘッダやJSONボディ）を見るには復号鍵（TLSセッションキー等）が必要です。鍵が無ければ tls の暗号化ペイロードとしてしか見えません。
復号できれば、HTTP/2の ヘッダ（:method = POST等、:path に AMPolicyControl のリソースパスを含む）でオペレーションを識別できます（正確なパス文字列は要確認）。
ボディは JSON（RFSP・サービスエリア制限・移動制限等のポリシー情報）で、人間に読みやすい構造で入っています。具体的なポリシー値の形式は要確認です。
N2のNGAP（バイナリ、SCTP上）と違い、N15はWeb的（HTTP/JSON）である点が観察の要です。SCTP固有のフィルタ（sctp.port 等）やPFCPは使いません。

EPCとの比較¶

4Gでは: アクセス&モビリティに関わる制御（在圏管理・移動制御・RAT/周波数選択優先度等）は主に MME の内部機能として実現され、PCRFは主にゲートウェイ側（SM/課金）のポリシー（Gx等）を担っていました。そのため、MM側ポリシーを独立した参照点として明確に外出しする形は薄かった（詳細は要確認）。
5Gでは: PCF がSM側（N7）とMM側（N15）の両方のポリシーを統括し、アクセス&モビリティポリシーを独立の参照点 N15（Npcf_AMPolicyControl）として持つ構成になりました。MM側ポリシーをSBIで動的に取得できる点が5Gの特徴です。

4G (EPC)	5G (5GC)
移動制御はMME内包（明確なAMポリシー参照点は薄い, 要確認）	N15（AMF ⇔ PCF）
—（専用の参照点として明確でない, 要確認）	SBI: HTTP/2 + JSON over TLS
—（要確認）	TS 29.507（Npcf_AMPolicyControl）
MME（アクセス&モビリティ制御を内包）	PCF（AMポリシーを提供）／ AMF（取得・適用）

MM側ポリシーを独立参照点として持つのは5Gの特徴です。 4Gでは移動制御が主にMME内に閉じており、5Gでこれが AMF⇔PCF の N15 としてSBI化・外出しされました。4G側の厳密な対応関係は要確認とします。

3GPP Specification¶

3GPP TS 29.507 — Npcf_AMPolicyControl サービス（Access and Mobility Policy, N15）。個別章番号は要確認
3GPP TS 29.500 / TS 29.501 — SBI framework（技術規約 / 設計原則・OpenAPI）。個別章番号は要確認
3GPP TS 23.503 — ポリシー・課金制御フレームワーク（アクセス&モビリティポリシーのポリシーモデルを含む）
3GPP TS 23.501 §4 — システムアーキテクチャと参照点（N15の定義）
3GPP TS 33.501 — SBIのセキュリティ（TLS等）。個別章番号は要確認

注記（要確認）: N15の実体が Npcf_AMPolicyControl（TS 29.507）であること、SBI共通framework が TS 29.500/29.501 系であること、参照点N15とサービスNpcfが同じ連携の2つの見方であることは、3GPPアーキテクチャの一般的整理です。各サービスオペレーションの細目章番号・正確なリソースURI・具体的なポリシー値（RFSP値等）の形式は Release により差異があるため個別には要確認とします。

Summary¶

N15は AMF ⇔ PCF を結ぶ参照点だが、SBI（Service Based Interface）である点がN2(NGAP/SCTP)・N4(PFCP/UDP)と根本的に異なる。
Protocolは HTTP/2 + JSON（RESTful）over TLS、実体はPCFのサービス Npcf_AMPolicyControl（TS 29.507）。
AMFは AM Policy Association を確立し、アクセス&モビリティ関連ポリシー（RFSP・サービスエリア制限・移動制限等）を取得して、UEの登録・移動制御に適用する。
N7がSM（セッション管理）側ポリシーなら、N15はMM（モビリティ管理）側ポリシー。両者は対でPCFがまとめて統括する。
参照点N15 = サービスNpcf_AMPolicyControl は同じAMF⇔PCF連携の2つの見方。MM側ポリシーを独立参照点として持つのは5Gの特徴（4G側の対応は要確認）。

Next Step¶

PCF — N15の相手側。アクセス&モビリティ／SMポリシーの中枢
AMF — N15を利用してアクセス&モビリティポリシーを取得し、登録・移動制御に適用するNF
N7 — SM側ポリシー（PCC rule）を扱う対の参照点
Registration — AM Policy Association確立の手順（詳細）
Interface辞典 — N7・N5・N8 ほか参照点の確認