AF / N5 / Application Session — アプリの要求がQoS Flowになるまで¶

学習目標¶

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

• N5 = Npcf_PolicyAuthorization（TS 29.514）であり、AFがService Consumer、PCFがService Producer であることを説明できる
• Application Session Context（app-sessions リソース）と、Create / Update / Delete / Subscribe / Unsubscribe / Notify の HTTP 上の見え方を説明できる
• PCFが Application Session と SM Policy Association を対応付ける（Session Binding） 仕組みと、複数PCF構成で BSF が必要になる理由を説明できる
• Media Component / Media Sub-Component / Flow Description が、PCC Rule の SDF template を経て QoS Rule（N1）・QoS Flow（N2）・PDR / QER（N4） になるまでを図で説明できる
• 「AF Request が PCF に来ない」「PCF までは成功するが QoS Flow が作られない」「Traffic が PDR に Match しない」を区間ごとに切り分けられる

前提知識¶

• PCF / SM Policy Association / PCC Rule — PCC Rule の構成と、SMF による N1 / N2 / N4 への翻訳
• N7 SBI解析 — SBI の HTTP/2・JSON・ProblemDetails の読み方
• N5 / AF / PCF — 参照点とNFの概要
• 補助: PDR / PDI / SDF Filter / QoS Flow / QFI / 5QI / GFBR / MFBR / AMBR / ARP / VoNR / Policy

Why — アプリはQoS Flowを直接作れない¶

VoNR の通話、クラウドゲーム、ライブ映像など、アプリケーションには「このメディアにはこの帯域・この遅延が必要」という要求があります。しかし、その要求を知っているのは アプリ側（AF） で、QoS を実際に適用するのは UE・gNB・UPF です。

• AF は UE の PDU Session ID も QFI も SEID も知りません。知っているのは、たいてい UEのIPアドレスと、メディアの宛先・ポート・コーデック・帯域 です。
• UE・gNB・UPF を設定できるのは SMF だけで、SMF に QoS の方針（PCC Rule）を渡すのは PCF です（PCF / PCC）。

そこで、アプリの言葉（メディア・フロー・帯域）を PCF が受け取り、5GC の言葉（PCC Rule）に翻訳する入口 が必要になります。それが N5 / Npcf_PolicyAuthorization です（TS 23.501 §6.2.10、TS 29.514 §4.1（要確認））。

例え話: AF は「イベント主催者」、PCF は「道路管理局」、SMF は「現場の交通整理責任者」です。主催者は「午後7時から、この会場とこの駐車場の間を、このくらいの台数が通る」と申請します（Application Session）。管理局は申請を審査し、「この区間をこの条件で優先レーンにする」という許可書（PCC Rule）を発行します。実際にコーンを置いて車線を作る（QoS Flow / PDR / QER）のは現場責任者です。主催者が自分でコーンを置くことはできません。

What — N5 と Npcf_PolicyAuthorization¶

参照点とサービス¶

通知（Notify）は方向が逆になり、PCF が AF の Callback URI（notifUri）へ POST します。このときだけ HTTP の Client / Server が入れ替わります。

Trusted AF と Untrusted AF¶

TS 23.501 §6.2.10 は、オペレータが信頼する AF は関連NFと直接やり取りでき、直接アクセスを許可されない AF は NEF 経由の外部 Exposure フレームワークを使う と定めています。

flowchart LR
    TAF["Trusted AF
例: IMSのP-CSCF"] == "N5
Npcf_PolicyAuthorization" ==> PCF["PCF"]
    XAF["Untrusted AF
外部アプリ事業者"] -- "N33
AsSessionWithQoS 等" --> NEF["NEF"]
    NEF -- "Npcf_PolicyAuthorization
(NEFがAFとして振る舞う)" --> PCF
    PCF == "N7
Npcf_SMPolicyControl" ==> SMF["SMF"]

PCFから見ると、どちらも 同じ Application Session です。違いは手前の認可と識別子変換で、それは NEF / N33 で扱います。

What — Application Session Context¶

リソース構造¶

N5 の中心は、AF が PCF 上に作る Application Session Context（「App Session」とも呼ばれる）です（TS 29.514 §5.3、要確認）。

{apiRoot}/npcf-policyauthorization/v1
└─ /app-sessions                              ← Application Sessions（コレクション）
    └─ /{appSessionId}                        ← Individual Application Session Context
        ├─ /delete                            ← 削除用カスタムオペレーション（POST）
        └─ /events-subscription               ← Events Subscription（個別リソース）

{notifUri}（AFが指定したCallback）
├─ /notify                                    ← イベント通知（PCF → AF）
└─ /terminate                                 ← 終了要求（PCF → AF）

サービスオペレーション¶

（オペレーションの節番号、各ステータスコードの使い分け、/delete を DELETE メソッドでなくカスタムオペレーション（POST）とする理由は、対象 Release の TS 29.514 §4.2 / §5.3 で要確認。Stage 2 は TS 23.502 §5.2.5.3、要確認）

AppSessionContextReqData の主要属性¶

Create の Body は AppSessionContext で、その中の ascReqData（AppSessionContextReqData）に要求内容が入ります（TS 29.514 §5.6.2.2 / §5.6.2.3、要確認）。

主要属性の抜粋であり、網羅ではありません。必須 / 任意 / 条件付きの区分と Release ごとの追加属性は TS 29.514 §5.6 で確認してください（要確認）。

Media Component / Media Sub-Component / Flow Description¶

AF が QoS を要求する単位は Media Component（メディア1本、例: 音声）で、その中にフロー単位の Media Sub-Component を持ちます。

medComponents (map)
└─ "1": MediaComponent                     ← 例: SDP の 1番目の m= 行（音声）
    ├─ medCompN: 1                         ← Media Component Number（必須）
    ├─ medType: AUDIO                      ← AUDIO / VIDEO / DATA / CONTROL 等
    ├─ codecs: [...]                       ← SDP の codec 情報（AFがSDPから作る）
    ├─ marBwUl / marBwDl: "41 Kbps"        ← Maximum Requested Bandwidth（UL / DL）
    ├─ mirBwUl / mirBwDl                   ← Minimum Requested Bandwidth（任意）
    ├─ fStatus: ENABLED                    ← Flow Status（ゲート）
    └─ medSubComps (map)
        ├─ "1": MediaSubComponent          ← 例: RTP
        │   ├─ fNum: 1                     ← Flow Number（必須）
        │   ├─ fDescs: [ UL用, DL用 ]      ← Flow Description（最大2つ）
        │   └─ flowUsage: NO_INFO
        └─ "2": MediaSubComponent          ← 例: RTCP
            ├─ fNum: 2
            ├─ fDescs: [ ... ]
            └─ flowUsage: RTCP             ← RTCP / AF_SIGNALLING / NO_INFO

Flow Description の書式は Rx の Flow-Description AVP を引き継いだ IPFilterRule 形式です（TS 29.514 §5.6.3。エンコードは TS 29.212 §5.4.2 の Flow-Description AVP、元の定義は Rx の TS 29.214 §5.3.8。いずれも要確認。PDR / PDI / SDF Filter と同じ参照先）。

permit out 17 from 198.51.100.20 40000 to 10.45.0.2 50000    ← DL（相手 → UE）
permit out 17 from 10.45.0.2 50000 to 198.51.100.20 40000    ← UL（UE → 相手）
         │   │   └ 送信元アドレス ポート    └ 宛先アドレス ポート
         │   └ プロトコル番号（17 = UDP）
         └ 方向キーワード

Rx 由来の規約では、方向キーワードは out に固定し、UL / DL は送信元・宛先アドレスのどちらが UE かで区別する とされています（TS 29.212 §5.4.2 / TS 29.214 §5.3.8、要確認）。この「方向の書き方」は、N5 → N7（flowInfos の flowDirection）→ N4（SDF Filter）と変換されるたびに解釈が入るため、実装間の不一致が PDR 不一致の原因になり得ます（後述の Trouble Shooting）。

What — N5 と N7 の関係（Session Binding）¶

PCF は「どのPDU Sessionか」をどう知るか¶

AF が App Session を作っても、それだけでは どの UE のどの PDU Session に効かせるのか が決まりません。PCF は App Session を、自分が持っている SM Policy Association（N7） のどれかに結び付けます。これを Session Binding と呼びます（TS 23.503 §6.1.3.2、要確認）。

flowchart LR
    AF["AF
App Session
ueIpv4=10.45.0.2
dnn=ims"] -- "N5" --> PCF["PCF"]
    SMF["SMF
PDU Session
UE IP=10.45.0.2
DNN=ims, S-NSSAI"] -- "N7
SM Policy Association" --> PCF
    PCF --> B{"Session Binding
UEアドレス + DNN 等が一致?"}
    B -- "一致" --> R["PCC Rule を作り
その SM Policy へ UpdateNotify"]
    B -- "不一致" --> X["App Session を拒否
例: PDU_SESSION_NOT_AVAILABLE"]

TS 23.503 §6.1.3.2 の Binding mechanism は、おおむね次の3段で整理されています（枝番は要確認）。

最後の QoS Flow binding が SMF の仕事 である点が重要です。PCF が「新しい QoS Flow を作れ」と命令するのではなく、PCF は PCC Rule を渡し、新しい QoS Flow を作るかどうかは SMF が binding parameter を見て決めます（PCF / PCC）。

複数 PCF 構成と BSF¶

PCF が複数ある網では、AF は その PDU Session の SM Policy Association を持つ PCF に App Session を作らなければなりません。別の PCF に届くと、Session Binding に失敗します。

SMF ──N7── PCF-B   ← UE IP 10.45.0.2 の SM Policy Association を持つ
AF  ──N5── PCF-A ✗ ← 対象 Session を知らない → 拒否
AF  ──N5── PCF-B ✓ ← Binding 成功

AF が担当 PCF を見つける方法は、BSF への Nbsf_Management_Discovery（UE IP・DNN・S-NSSAI をキーに担当PCFを検索）、SCP 経由の Delegated Discovery、Rx を使う AF なら BSF の Diameter Proxy / Redirect、ローカル設定 などがあり、どれを使うかは 配備依存 です（TS 23.503 §6.1.1.2、要確認）。詳細は BSF / PCF Binding と SBI Communication Model を参照してください。

How — AF要求がQoS Flowになるまで（End-to-End）¶

Call Flow¶

TS 23.502 §4.16.5.2（PCF-initiated SM Policy Association Modification）と §4.3.3.2（Network requested PDU Session Modification）を組み合わせた代表例です（step 番号・順序は版により異なるため要確認）。

sequenceDiagram
    participant AF
    participant BSF
    participant PCF
    participant SMF
    participant AMF
    participant gNB
    participant UPF
    AF->>BSF: Nbsf_Management_Discovery
(UE IP, DNN, S-NSSAI)
    BSF-->>AF: 200 OK (担当PCF)
    AF->>PCF: Npcf_PolicyAuthorization_Create
POST app-sessions (medComponents, notifUri, evSubsc)
    PCF->>PCF: Session Binding
PCC Rule 認可・生成
    PCF-->>AF: 201 Created (Location: app-sessions/ID)
    PCF->>SMF: Npcf_SMPolicyControl_UpdateNotify
(PCC Rule 追加)
    SMF-->>PCF: 200 OK / 204 No Content
    Note over SMF: QoS Flow binding
新QFI割当 or 既存QoS Flowへ
    SMF->>AMF: Namf_Communication_N1N2MessageTransfer
(N1: PDU Session Modification Command
N2: PDU Session Resource Modify Request Transfer)
    AMF->>gNB: NGAP PDU Session Resource Modify Request
    gNB-->>AMF: PDU Session Resource Modify Response
    AMF->>SMF: Nsmf_PDUSession_UpdateSMContext (N2 SM情報)
    SMF->>UPF: PFCP Session Modification Request
(Create PDR / QER)
    UPF-->>SMF: PFCP Session Modification Response
    Note over SMF: UE の Modification Complete 受信後
PCC Rule の結果を報告
    SMF->>PCF: Npcf_SMPolicyControl_Update
(Rule の結果報告)
    PCF->>AF: Npcf_PolicyAuthorization_Notify
POST notifUri/notify (SUCCESSFUL_RESOURCES_ALLOCATION 等)

• TS 23.502 §4.3.3.2 では N4 Session Modification が条件付きで複数の step に現れ（N2 応答の後、UE の Complete の後など。step 番号は要確認）、N4 更新のタイミングに選択肢があります。実際にどのタイミングで更新するかは実装依存です。UE が CM-IDLE なら、N1/N2 を届ける前に Paging が必要です（TS 23.502 §4.2.3.3）。
• PCF が AF への応答を UpdateNotify の前に返すか後に返すかは、仕様上の順序と実装の両方を確認してください（要確認）。

Signal Flow¶

変換の連鎖 — Flow Description から PDR まで¶

[N5] AF: MediaComponent
     ├─ medType=AUDIO, codecs, marBwUl/Dl ─────┐
     ├─ fStatus=ENABLED ──────────────┐        │  PCF: QoSマッピング（TS 29.513 §7.3）
     └─ medSubComp.fDescs ──┐         │        │       + 加入者・事業者ポリシー
                            ▼         ▼        ▼
[N7] PCF: PccRule ── flowInfos(SDF template) / precedence
          ├─ refTcData → TrafficControlData.flowStatus（Gate）
          └─ refQosData → QosData（5qi, arp, maxbrUl/Dl, gbrUl/Dl）
                            │
                            ▼ SMF: QoS Flow binding（5QI / ARP 等）→ QFI 割当
        ┌───────────────────┼─────────────────────────┐
        ▼                   ▼                         ▼
[N1] QoS Rule          [N2] QoS Flow Level        [N4] PDR（PDI: SDF Filter, QFI 等）
     (UL Packet Filter,      QoS Parameters             + QER（QFI, MBR/GBR, Gate Status）
      Precedence, QFI)       (QFI, 5QI, ARP, GFBR/MFBR)

（属性名は概念表現。TS 29.512 §5.6.2、TS 24.501 §9.11.4.12 / §9.11.4.13、TS 38.413 §9.3.1.12、TS 29.244 §8.2.5（SDF Filter）。いずれも節番号は要確認）

• PCC Rule を Media Component 単位で作るか、Media Sub-Component（フロー）単位で作るかは PCF 実装依存 です。
• AUDIO を 5QI=1 にするといった対応は TS 29.513 §7.3 のマッピングと事業者ポリシーで決まり、AF が 5QI を直接指定するのではありません（Rel-16 以降の QoS Reference 等による例外は要確認）。

How — VoNR の P-CSCF で見る¶

VoNR では、IMS の P-CSCF が Trusted AF として N5 を使います。SIP の SDP から Media Component を組み立てるのは P-CSCF の仕事です。

sequenceDiagram
    participant UE
    participant PCSCF as P-CSCF (AF)
    participant PCF
    participant SMF
    UE->>PCSCF: SIP INVITE (SDP offer)
    Note over PCSCF: 相手側から SDP answer を受信
(例: 183 Session Progress)
    PCSCF->>PCF: Npcf_PolicyAuthorization_Create
(ueIpv4, dnn=ims, AUDIO, fDescs RTP/RTCP)
    PCF-->>PCSCF: 201 Created
    PCF->>SMF: UpdateNotify (5QI=1 GBR の PCC Rule)
    Note over SMF: 新 QoS Flow (5QI=1) を追加
N1 / N2 / N4 を更新
    PCF->>PCSCF: Notify (SUCCESSFUL_RESOURCES_ALLOCATION)
    PCSCF->>UE: SIP 183 / UPDATE 等で呼が進む
    Note over UE,PCSCF: 通話終了 (BYE)
    PCSCF->>PCF: POST app-sessions/ID/delete
    PCF->>SMF: UpdateNotify (PCC Rule 削除)
    Note over SMF: 5QI=1 の QoS Flow を解放

（SDP から Media Component への変換規則は TS 29.513 §7.2 等、P-CSCF が N5 要求を出すタイミング（SDP offer / answer のどちらで出すか）は TS 29.513 / TS 23.228 と P-CSCF の設定に依存します。いずれも要確認）

Packet Analysis (Wireshark)¶

N5 / N7 は SBI なので HTTP/2 です。SBI では TLS のサポートは必須ですが、PLMN 内で実際に適用するかはオペレータの判断 です（TS 33.501 §13.1、要確認）。TLS が適用されていれば復号鍵（キーログ等）が必要です。ラボの Open5GS / free5GC 等では平文の HTTP/2（h2c）で構成されることもあります（設定依存）。なお、外部AFが使う N33（Northbound API）は HTTP/1.1 と HTTP/2 の両方があり得ます（TS 29.122 §5.2.2、要確認。NEF / N33）。

Display Filter¶

フィールド名は Wireshark の版により異なる場合があります（要確認）。

Decode例（概念表現）¶

以下は TS 29.514 / TS 29.512 の OpenAPI に沿った 概念表現 で、属性名は要確認、値は架空例です（要キャプチャ）。

[N5] POST /npcf-policyauthorization/v1/app-sessions
AppSessionContext
└─ ascReqData
    ├─ ueIpv4: 10.45.0.2
    ├─ dnn: ims
    ├─ notifUri: https://pcscf.example/n5cb/abc123
    ├─ suppFeat: "..."
    ├─ evSubsc
    │   └─ events: [ SUCCESSFUL_RESOURCES_ALLOCATION, FAILED_RESOURCES_ALLOCATION ]
    └─ medComponents
        └─ "1"
            ├─ medCompN: 1, medType: AUDIO
            ├─ marBwUl: "41 Kbps", marBwDl: "41 Kbps"
            ├─ fStatus: ENABLED
            └─ medSubComps
                ├─ "1": fNum 1
                │   fDescs: [ "permit out 17 from 198.51.100.20 40000 to 10.45.0.2 50000",
                │             "permit out 17 from 10.45.0.2 50000 to 198.51.100.20 40000" ]
                └─ "2": fNum 2, flowUsage: RTCP, fDescs: [ ...40001 / 50001... ]
→ 201 Created
  Location: https://pcf-b.example/npcf-policyauthorization/v1/app-sessions/7f3c...

[N7] POST {SMFのnotificationUri}/update      ← UpdateNotify
SmPolicyNotification
└─ smPolicyDecision
    ├─ pccRules
    │   └─ "voice-1": flowInfos [ {flowDescription, flowDirection: DOWNLINK}, {..., UPLINK} ]
    │                 precedence: 50, refQosData: ["qos-voice"], refTcData: ["tc-voice"]
    ├─ qosDecs
    │   └─ "qos-voice": 5qi 1, gbrUl/gbrDl, maxbrUl/maxbrDl, arp {priorityLevel, preemptCap, preemptVuln}
    └─ traffContDecs
        └─ "tc-voice": flowStatus ENABLED

[N4] PFCP Session Modification Request
├─ Create PDR (UL): PDI { Source Interface: Access, Local F-TEID, QFI 2, SDF Filter } → QER 2
├─ Create PDR (DL): PDI { Source Interface: Core, UE IP 10.45.0.2, SDF Filter } → QER 2
└─ Create QER 2: QFI 2, Gate Status OPEN, MBR / GBR

見る順番¶

flowchart LR
    A["① N5
Create の応答
201 / 4xx / 5xx"] --> B["② N7
UpdateNotify の有無
PCC Rule の中身"]
    B --> C["③ N2 / N1
Modify Request / Response
Modification Command"]
    C --> D["④ N4
Create PDR / QER
SDF Filter と Precedence"]
    D --> E["⑤ N3
実トラフィックの
5-tuple と QFI"]
    E --> F["⑥ N5 Notify
成否イベント"]

区間ごとに 相関キーが入れ替わる 点に注意します。

Trouble Shooting¶

AF Request が PCF に来ない — 下から順に¶

① AF は Request を送信しているか（AF ログ、送信側キャプチャ）
② 宛先 PCF は正しいか（BSF Discovery の 200 / 204、SCP のルーティング、ローカル設定）
③ TCP / TLS は確立しているか（TLS Alert、証明書）
④ HTTP/2 として届いているか（:path が /npcf-policyauthorization/v1/app-sessions か、API バージョン）
⑤ PCF の応答は何か（201 / 400 / 403 / 404 / 5xx と ProblemDetails）

PCF までは成功するが QoS Flow が作られない¶

201 Created の後に見るべきなのは N7 の UpdateNotify です。

AF ──201──► 成功          ← ここで安心しない
PCF ──UpdateNotify──► SMF ← 出ているか / PCC Rule の 5QI・ARP・flowInfos は期待どおりか
SMF ──► N2 / N1 / N4      ← 新 QFI が割り当てられたか、既存 Flow に束ねられたか
SMF ──Update(ruleReports)──► PCF  ← 失敗報告が来ていないか
PCF ──Notify──► AF        ← FAILED_RESOURCES_ALLOCATION が来ていないか

Traffic が PDR に Match しない — 比較表を作る¶

（値は架空例。要キャプチャ）UL では、UE が QoS Rule の Packet Filter に従って QFI を付けます。UL PDR が QFI も条件にしている場合、UE 側の分類がずれていると UPF の PDR に Match しません。PDR の Match 規則の詳細は PDR / PDI / SDF Filter を参照してください。

3GPP仕様とVendor実装の境界¶

EPC（4G）との比較¶

N5 は、4G の Rx（AF ⇔ PCRF、Diameter、TS 29.214）を SBI 化したものです。

（対応は本章の整理。Rx の AVP 定義は TS 29.214 §5.3、Diameter Command は §5.6（要確認））

3GPP Specification¶

Summary¶

• N5 = Npcf_PolicyAuthorization（TS 29.514）。AF が Consumer、PCF が Producer。Notify だけは PCF → AF の Callback
• AF は PCF 上に Application Session Context（app-sessions/{appSessionId}）を作り、Update（PATCH）・Delete（POST .../delete）・Subscribe（PUT events-subscription）で管理する
• AF が渡すのは Media Component / Flow Description / 帯域 というアプリの言葉。PCF が Session Binding でPDU Sessionに結び付け、PCC Rule に翻訳し、N7 UpdateNotify で SMF へ渡す
• 新しい QoS Flow を作るかは SMF の QoS Flow binding が決める。SMF が N1（QoS Rule）・N2（QoS Flow）・N4（PDR / QER）へ展開する
• 複数 PCF 構成では、AF は 担当PCF に届かなければならない → BSF。外部 AF は NEF 経由
• 201 Created は QoS 適用完了ではない。UpdateNotify → N2 / N1 / N4 → N3 の実トラフィック → Notify まで追う

理解度チェック¶

Next Step¶

• 外部 AF が NEF 経由で同じ App Session を作る仕組み → NEF / N33 / Event Exposure
• AF が担当PCFを見つける仕組み → BSF / PCF Binding / SBI Communication Model
• PCC Rule が N1 / N2 / N4 に翻訳される詳細 → PCF / SM Policy Association / PCC Rule / N7 SBI解析
• SDF Filter と PDR の Match → PDR / PDI / SDF Filter / QoS Flow / QFI / 5QI
• P-CSCF を AF とする代表例 → VoNR / PDU Session Modification
• 概要ページ → AF / N5 / Policy