N5 — AF ⇔ PCF（Npcf_PolicyAuthorization 参照点）¶
学習目標¶
このページを読み終えると、次のことができるようになります。
- N5が SBI（Service Based Interface） であり、実体がPCFの提供するサービス Npcf_PolicyAuthorization（TS 29.514） であることを説明できる。
- N5が 信頼できる(trusted)AF がPCFへ直接要求するための窓口であり、非信頼AFは N33（NEF経由）で間接的に要求することを区別できる。
- AFがN5でPCFへ要求する内容（QoS要求・トラフィックルーティング（エッジ誘導）・課金方針への影響）を説明できる。
- PCFがAF要求を受けて PCC rule に反映し、N7 経由でSMF/UPFへ反映される流れを説明できる。
- 4G(EPC)の Rx（AF ⇔ PCRF, Diameter） との対応関係を説明できる。
前提知識¶
先に以下を理解しておくとスムーズです。
- SBA / SBI と HTTP/2・TLS の位置づけ → Protocol辞典
- N5の両端のNF → AF / PCF
- PCFがPCC ruleをSMFへ渡す道 → N7
- 非信頼AFがNEFを介する道 → N33 / NEF
- QoS（5QI/QFI）の使われ方 → QoS
- Interfaceと参照点の考え方 → Interface辞典
Why — なぜ必要なのか¶
アプリケーション側（例: 動画配信、クラウドゲーム、映像通話などのサービス基盤=AF）は、「このアプリの通信は高品質(低遅延・広帯域)で流したい」「このユーザのトラフィックは近くのエッジサーバへ誘導したい」「この通信は特別な課金にしたい」といった要望を持ちます。しかし、AFがネットワークのQoSや課金を勝手に設定できるわけではありません。
そこで、事業者ポリシーの元締めである PCF に対し、AFが「このアプリのために、こう扱ってほしい」と要求を伝える道が要ります。これがN5です。PCFはAFの要求を受け取り、事業者規約と突き合わせて認可した上で PCC rule（指示書） に反映し、N7 経由でSMF、さらにUPFへと落とし込みます。N5が無ければ、アプリの都合をネットワークのポリシーへ反映する経路が失われ、アプリ主導のきめ細かいQoS制御・エッジ誘導ができません。
ただしこの「直通の道」は、事業者が信頼できる(trusted)AFにのみ開かれます。第三者などの非信頼AFは、直接ではなく NEF（N33）という受付窓口を経由して間接的に要求します。
例え話: N5は、アプリの営業担当（AF）がポリシー規約部門（PCF）へ直接要望を伝える専用回線です。社内の信頼できる相手だからこそ、受付（NEF）を通さず直通で「このサービスはこう扱ってほしい」と要望できます。信頼できない外部からの要望は、必ず受付（NEF/N33）を通す決まりです。
Overview — 概要¶
N5は AF ⇔ PCF を結ぶ参照点です。N5はSBI（Service Based Interface） であり、共通の転送として HTTP/2 + JSON（RESTful）over TLS を用います。
N5の実体は、PCFが提供するサービス Npcf_PolicyAuthorization（TS 29.514） です。信頼できる(trusted)AF はこのサービスを呼び出して、特定アプリのための QoS要求・トラフィックルーティング（エッジ誘導）・課金方針への影響 をPCFへ直接要求します。PCFはこれを認可して PCC rule に反映し、N7（Npcf_SMPolicyControl）でSMFへ、SMFがUPFへと落とし込みます。
一方、非信頼AF はN5を直接使えず、NEF が公開するAPI（N33）を通じて要求を出し、NEFがPCFへ橋渡しします。N5は「信頼AFの直通」、N33は「非信頼AFの受付経由」という役割分担です。
参照点N5とサービスNpcf_PolicyAuthorizationは同じものの2つの見方
3GPPのアーキテクチャ図では 参照点として N5（AF⇔PCF） が示されますが、SBA（サービス化）ではこれが実体として PCFのサービス Npcf_PolicyAuthorization として実装されます。つまり「N5」と「Npcf_PolicyAuthorization」は、同じAF⇔PCF間の連携を、参照点の視点／サービスの視点で見たものです。どちらも指しているものは同一で、呼び方（視点）が違うだけ、と捉えてください（N7 とNpcf_SMPolicyControlの関係と同じ二重性）。
Basic Concept — 初心者向け説明¶
N5を、アプリの営業担当と規約部門の直通要望に例えます。
あるアプリサービス（AF）が「うちの映像通話は低遅延で流したい」「このユーザは近くのエッジサーバに繋ぎたい」と考えたとします。AFはこの要望を、事業者の規約部門であるPCFへ直接伝えます（Npcf_PolicyAuthorization での要求）。PCFは会社の規約や加入者データと照らし合わせ、要望を認可できるか判断し、認可した内容を PCC rule（指示書） に落とし込みます。この指示書は N7 経由でSMFに渡り、SMFがUPF（土管）へ「このアプリの通信はこの品質で、この経路で流せ」と設定します。
ただし、この直通の要望ができるのは信頼できる相手（trusted AF）だけです。外部の信頼できないアプリ（非信頼AF）は、直通ではなく受付窓口（NEF / N33）を通して要望を出します。受付が内容を確認し、問題なければPCFへ取り次ぎます。
このAFからの要求も、専用の電話回線ではなく、Web API（HTTP）でリクエストを投げて回答をもらうイメージです。これが SBI（Service Based Interface） ＝NF同士がWeb API（HTTP/2）で会話する仕組みで、要求も応答も JSON でやり取りされます。
Protocol / Transport¶
| 項目 | 内容 |
|---|---|
| Protocol | HTTP/2 + JSON（RESTful）— SBI（Service Based Interface）の共通スタック |
| サービス | Npcf_PolicyAuthorization（PCFが提供）— TS 29.514 |
| SBI framework | TS 29.500 / TS 29.501 系（SBIの共通規約・OpenAPI定義） |
| 下位Transport | TCP、TLS で保護（機密性・完全性・認証）— TS 33.501 |
| ポート | SBIの待受ポートは実装依存（NRF登録のエンドポイントで解決）。特定番号は断定しない |
| 適用範囲 | 信頼できる(trusted)AF が直接利用。非信頼AFは N33(NEF経由)で間接利用 |
N5はSBI。専用L4プロトコルではなくWeb技術ベース
N5はSBIなので、他のSBI（N7/N15/N33 等）と同じく HTTP/2 over TLS を共通の土台として使います。SCTP（N2）やPFCP（N4）はN5には一切関係しません。したがってN5の解析にSCTP固有のフィルタやポート番号を流用してはいけません。
Architecture¶
N5がAFとPCFを結び、非信頼AFがN33(NEF)経由となる二経路を示し、PCFが得たAF要求がN7でSMF、さらにUPFへ反映される文脈を示します。
flowchart LR
AF["AF (信頼・アプリ要求)"]
NEF["NEF (受付)"]
UAF["AF (非信頼)"]
PCF["PCF"]
SMF["SMF"]
UPF["UPF (転送)"]
AF == "N5 (Npcf_PolicyAuthorization)" ==> PCF
UAF -. "N33" .-> NEF
NEF -. "取次" .-> PCF
PCF == "N7 (Npcf_SMPolicyControl)" ==> SMF
SMF == "N4 (PFCP)" ==> UPF
classDef ctrl fill:#efe,stroke:#3a3,stroke-width:2px;
class AF,PCF ctrl;
図の読み方: 太い線(==>)のN5が、信頼AF⇔PCFの直接要求（SBI/HTTP2）。非信頼AFは点線のN33でNEF（受付）を経由し、NEFがPCFへ取り次ぎます。PCFはAF要求を認可してPCC ruleに反映し、N7でSMFへ、SMFがN4(PFCP)でUPFへ落とし込みます（右の太線）。N5は「アプリからの要望の入口」、N7は「その結果をセッションへ反映する道」という役割分担に注目してください。
利用Procedure¶
N5は、アプリ（AF）が特定のアプリケーションフローのために、QoS要求やトラフィックルーティング・課金影響をPCFへ要求する際に使われます。
- Policy Authorization Create（生成）: AFがアプリの通信要件（QoS要求、エッジへのルーティング、課金影響）を指定してPCFへ要求。PCFは認可して PCC rule に反映する。
- Policy Authorization Update（更新）: アプリの要件が変わる場合に、AFが要求内容を更新する。
- Policy Authorization Delete（削除）: アプリの要求が不要になった際に、認可を解放する。
- Notify（通知, PCF→AF）: セッションの状態（QoS通知、リソースの割当結果等）をPCFがAFへ通知する。
AFの要求を受けたPCFは、その内容を PDU Session Modification / Release の流れの中で PCC rule として更新し、N7 経由でSMFへ反映します。反映されたQoS/ルーティングは QoS の QoS Flow(QFI/5QI) としてUPFに設定されます。
手順の細部（メッセージシーケンス、条件、IE、正確なオペレーション名）は Release により差異があるため要確認とし、詳細は上記リンク先および PDU Session Modification を参照してください。
主なMessage¶
N5はSBIなので、メッセージはHTTPメソッド + リソース操作の形を取ります（NGAPのようなprocedureCodeではなくRESTful操作）。代表的なサービスオペレーションは次のとおりです。
| サービスオペレーション | HTTP操作(概念例) | 用途 |
|---|---|---|
| Npcf_PolicyAuthorization_Create | POST（リソース生成） | アプリ用のQoS要求・ルーティング・課金影響の認可要求 |
| Npcf_PolicyAuthorization_Update | POST/PUT（更新） | 既存のAF要求内容の変更 |
| Npcf_PolicyAuthorization_Delete | DELETE（リソース削除） | AF要求（認可）の解放 |
| Npcf_PolicyAuthorization_Notify | POST（PCF→AFへ通知callback） | QoS通知・イベント結果のAFへの通知 |
HTTP操作の対応は概念整理です: 上表の「HTTP操作」は理解のための対応づけであり、各オペレーションの正確なメソッド・リソースURI・呼び出し方向はTS 29.514のOpenAPI定義に従います。厳密なメソッド割り当ては要確認とします。各メッセージの詳細は Message辞典 を参照してください。
Packet Analysis (Wireshark)¶
N5はSBIなので、キャプチャ上は HTTP/2 として観測されます（NGAP/SCTPやPFCPのようなL4専用プロトコルは現れません）。
| 目的 | Display Filter |
|---|---|
| HTTP/2メッセージを抽出 | http2 |
| ヘッダのパスで絞る（概念） | http2.headers.path（:path に npcf-policyauthorization を含む） |
| JSONボディを見る | json（復号後） |
Decodeの見どころ:
- N5は TLSで暗号化されます。中身（HTTP/2ヘッダやJSONボディ）を見るには復号鍵（TLSセッションキー等）が必要です。鍵が無ければ
tlsの暗号化ペイロードとしてしか見えません。 - 復号できれば、HTTP/2の ヘッダ（
:method= POST等、:pathに.../npcf-policyauthorization/...を含むリソースパス）でオペレーションを識別できます。 - ボディは JSON（QoS要求、メディアコンポーネント情報、ルーティング要求、課金影響等）で、人間に読みやすい構造で入っています。
- N2のNGAP（バイナリ、SCTP上）と違い、N5はWeb的（HTTP/JSON）である点が観察の要です。SCTP/PFCP固有のフィルタは使いません。
EPCとの比較¶
- 4Gでは: アプリ機能（AF）がポリシー・課金へ影響を与える要求は、PCRF（Policy and Charging Rules Function） に対し Rx インターフェース（Diameterベース）で行っていました（TS 29.214）。AFはRxで、アプリのメディアフローに応じたQoS/課金の要求をPCRFへ伝えていました。
- 5Gでは: PCRFの役割を PCF が引き継ぎ、Rx相当が N5（Npcf_PolicyAuthorization） に SBI化されました。信頼AFがPCFへ直接要求する枠組みは継続しつつ、Diameterから HTTP/2 + JSON（SBI） へ置き換わっています（TS 29.514）。非信頼AFはNEF(N33)経由という区別が明確化されています。
| 4G (EPC) | 5G (5GC) |
|---|---|
| Rx（AF ⇔ PCRF） | N5（AF ⇔ PCF） |
| Diameter（専用L4上） | SBI: HTTP/2 + JSON over TLS |
| TS 29.214（Rx） | TS 29.514（Npcf_PolicyAuthorization） |
| PCRF | PCF |
AFがポリシー・課金へ影響を与えるという思想自体は4Gから継続しています。5Gでの主な変化は、Diameterベースの専用IF(Rx)が SBI（HTTP/2+JSON）化され、信頼AF直通(N5)／非信頼AFはNEF経由(N33)という区別が整理された点です。
3GPP Specification¶
- 3GPP TS 29.514 — Npcf_PolicyAuthorization サービス（AF⇔PCF, N5）。個別章番号は要確認
- 3GPP TS 29.500 / TS 29.501 — SBI framework（技術規約 / 設計原則・OpenAPI）。個別章番号は要確認
- 3GPP TS 23.501 §4 — システムアーキテクチャと参照点（N5の定義）
- 3GPP TS 23.503 — ポリシー・課金制御フレームワーク（PCC framework, AF影響のポリシーモデル）
- 3GPP TS 33.501 — SBIのセキュリティ（TLS等）。個別章番号は要確認
注記（要確認）: N5の実体が Npcf_PolicyAuthorization（TS 29.514）であること、SBI共通framework が TS 29.500/29.501 系であること、参照点N5とサービスNpcfが同じ連携の2つの見方であること、信頼AF直通／非信頼AFはNEF(N33)経由という区別は、3GPPアーキテクチャの一般的整理です。各サービスオペレーションの正確なメソッド・リソースURI・細目章番号は Release により差異があるため個別には要確認とします。
Summary¶
- N5は AF ⇔ PCF を結ぶ参照点で、SBI（Service Based Interface）。Protocolは HTTP/2 + JSON（RESTful）over TLS。
- 実体はPCFのサービス Npcf_PolicyAuthorization（TS 29.514）。参照点N5 = サービスNpcf_PolicyAuthorization の二重性は N7 と同じ。
- N5は 信頼できる(trusted)AF がPCFへ QoS要求・トラフィックルーティング（エッジ誘導）・課金影響 を直接要求する窓口。非信頼AFは N33（NEF経由） で間接要求する。
- PCFはAF要求を認可して PCC rule に反映し、N7 経由でSMF、さらにUPFへ落とし込む。
- 4Gの Rx（AF ⇔ PCRF, Diameter, TS 29.214） に相当し、5Gでは SBI化（TS 29.514）された。