NF Set / Binding Indication / SCP Routing — PCF障害時にPolicyの継続性をどう守るか¶

学習目標¶

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

• NF Instance / NF Set / NF Service Instance / NF Service Set の違いを説明できる（TS 23.501 §5.21.3）
• Binding Level が「後続Requestをどの範囲に結び付け、障害時にどの範囲で再選択してよいか」を表すことを説明できる
• BSFのPCF Binding（Nbsf_Management）と、SBIのBinding Indication（3gpp-Sbi-Binding / 3gpp-Sbi-Routing-Binding）の違いを説明できる
• PCF障害時の切替を ①発見・ルーティング ②Context継続性 ③Binding整合性 の3段階に分けて切り分けられる
• Wiresharkで Binding関連Header・Location・3gpp-Sbi-Target-apiRoot を読み、Requestが「どこへ向かい、誰が処理したか」を追える

前提知識¶

• BSF / PCF Binding — BSFが「このPDU Sessionの担当PCF」を管理する仕組み
• SCP — Direct / Indirect Communication と Model A〜D
• NRF — NF Profile の登録と Discovery
• 補助: PCF / BSF / UDSF（Context共有の格納先の1つ） / GUAMI / AMF Region / Set / Pointer（AMF Setとの対比） / Policy

Why — なぜ「別のPCFに送れば直る」では済まないのか¶

次のPDU Sessionを考えます。

UE ── AMF ── SMF ── N7 ── PCF-A
                 │          │
                 │          └─ SM Policy Association の Context
                 └─ UPF

AF ── NEF ── BSF ──────────> PCF-A（Binding先）

PCF-Aが故障した後、同じ種類のPCF-Bが稼働していても、PCF-Bが対象SessionのContextを扱えるとは限りません。PCF-AとPCF-Bが同じNF Setに属し、かつContextを共有していて初めて、PCF-Bは既存のSM Policy AssociationやAF Sessionの続きを処理できます。

必要な条件は大きく3つです。

1. 発見・ルーティング — 代替PCFを見つけ、仕様が許す範囲でRequestを送り直せること
2. Contextの継続性 — 代替PCFが既存のPolicy Association等のContextを利用できること
3. Bindingの整合性 — BSFのBinding、SBIのBinding Indication、実際に処理したPCF Instanceが矛盾しないこと

例え話: PCF Setは「同じ顧客台帳を共有する窓口チーム」です。担当窓口（PCF-A）が急に休んでも、同じチームの別窓口（PCF-B）なら共有台帳（Context）を見て対応を続けられます。しかし、別の支店の窓口（別Setや台帳を共有しないPCF）へ回されると、「その案件は存じません」と言われてしまいます。また受付票（Binding）に「A窓口限定」と書かれていれば、案内係（SCP）は勝手に別窓口へ回してはいけません。

What — NF Set と Binding の構成要素¶

NF Instance / NF Set / NF Service Instance / NF Service Set¶

TS 23.501 §5.21.3 は、NFの信頼性（Reliability）を NF Set と NF Service Set という単位で扱います（NF Set概念の一般化はRel-16のSBA拡張、要確認。AMF SetはRel-15から存在）。各用語の定義文は TS 23.501 §3.1（Definitions）にあり（要確認）、§5.21.3 はその機能説明です。

                    PCF Set X（NF Set）
   ┌────────────────────────────────────────────────┐
   │ PCF-A（NF Instance）     PCF-B（NF Instance）   │
   │  ├─ NF Service Set S1      ├─ NF Service Set S1'│
   │  │   ├─ SMPolicyControl #1 │   └─ ...           │
   │  │   └─ SMPolicyControl #2 │                    │
   │  └─ PolicyAuthorization #1 └─ ...               │
   └────────────────────────────────────────────────┘
                         │
            共有Context（UDSF または 実装固有のDB）

NF Set ID の表記¶

NF Set IDは TS 23.003 §28.12 で、次の形式のグローバルに一意な文字列として定義されます（NF Service Set ID は §28.13、要確認）。

set<Set ID>.<nftype>set.5gc.mnc<MNC>.mcc<MCC>
例（テスト用PLMN 001-01、PCF）: set1.pcfset.5gc.mnc001.mcc001

AMF Setだけは set<AMF Set ID>.region<AMF Region ID>.amfset.5gc.mnc<MNC>.mcc<MCC> という特別な形式になり、GUAMIのAMF Region / AMF Setと対応します（GUAMI参照）。AMF SetはNF Setの一種 であり、本章の基本的な考え方はAMFにも当てはまります。ただしAMFには GUAMI・Backup AMF（backupamfinst）・計画停止手順などの固有の扱いがあります（TS 23.501 §5.21.2 / GUAMI）。

NRFでの見え方¶

各NF Instanceは、NRFへ登録するNF Profileで自分の所属NF Set（nfSetIdList）や、NF Serviceごとの NF Service Set（nfServiceSetIdList）を公開します（TS 29.510 のNFProfile / NFService型、属性名・節番号は要確認）。Consumer や SCP は、NRF Discovery で「このNF Setに属するPCF」を検索して代替候補を得ます（クエリパラメータ target-nf-set-id、要確認）。

Binding Level — 後続Requestを「どの範囲」に結び付けるか¶

TS 23.501 §6.3.1.0（Principles for Binding, Selection and Reselection）は、Binding を「特定のNF Producer側リソース（Context）に関する後続Requestを、どのNF Producer Instance群へ送るべきかを示す仕組み」として整理し、次の4つの Binding Level を定めています。

表は TS 23.501 §6.3.1.0 の表（Binding, selection and reselection）を概念的に要約したものです。各セルの厳密な条件は原文で要確認です。

BSFのPCF Binding と SBIのBinding Indication は別物¶

名前が似ていますが、持ち主・形式・利用者がまったく異なります。

BSFのPCF Bindingにも、PCF Set ID と Binding Level（NF Instance / NF Set）を含められます（TS 29.521 の PcfBinding型 pcfId / pcfSetId / bindLevel、属性名は要確認）。BSFのPCF Bindingで扱うBinding Levelは NF Instance と NF Set で、SBI全般で定義される NF Service Instance / NF Service Set Level とは扱う範囲が異なる点に注意してください（TS 23.503 §6.1.1.2.2、要確認）。

2つのHeader — 3gpp-Sbi-Binding と 3gpp-Sbi-Routing-Binding¶

PCF ── 201 Created + 3gpp-Sbi-Binding（任意）──> Consumer（NEF / SMF）
                                                    │ Binding を保存
                                                    ▼ 後続Request
Consumer ── 3gpp-Sbi-Routing-Binding ──> SCP ──> PCF（Binding範囲内のInstance）

主なパラメータ（TS 29.500 §5.2.3.2.6 のABNF）¶

上記は主要パラメータの抜粋で、Releaseによりパラメータが追加されています（網羅ではありません）。

Header の読み方（模式例）¶

以下はHeaderの読み方を示す模式例で、IDは説明用です。全てのRequestにこのHeaderが必須という意味ではありません。

:method: POST
:path: /npcf-policyauthorization/v1/app-sessions
3gpp-Sbi-Routing-Binding: bl=nfset; nfset=set1.pcfset.5gc.mnc001.mcc001

• bl=nfset：Binding Level は NF Set（綴りは要確認）
• nfset=...：対象NF Set ID
• :path：呼び出すAPI Resource

NF Instance Levelの模式例:

3gpp-Sbi-Routing-Binding: bl=nfinstance; nfinst=54804518-4191-46b3-955c-ac631f953ed8; nfset=set1.pcfset.5gc.mnc001.mcc001

nfinst は特定NF Instanceを表します。nfset が併記されていても、bl=nfinstance が bl=nfset として扱われるわけではありません（上の warning 参照）。

How — PCF障害時の振る舞い¶

Call Flow（SCP経由・概念図）¶

sequenceDiagram
    participant SMF
    participant NEF
    participant BSF
    participant SCP
    participant PCFA as PCF-A
    participant PCFB as PCF-B
    SMF->>SCP: Npcf_SMPolicyControl_Create
    SCP->>PCFA: 転送（PCF Set内のInstanceを選択）
    PCFA-->>SMF: 201 Created + Location + 3gpp-Sbi-Binding（任意、経由はSCP）
    PCFA->>BSF: Nbsf_Management_Register（pcfId, pcfSetId, bindLevel）
    NEF->>BSF: Nbsf_Management_Discovery（UE IP, DNN, S-NSSAI）
    BSF-->>NEF: 200 OK（PCF Binding）
    NEF->>SCP: Npcf_PolicyAuthorization_Create + 3gpp-Sbi-Routing-Binding
    SCP-xPCFA: 転送失敗（PCF-A障害）
    Note over SCP: Binding Levelが許す範囲で
同一PCF Set内の代替を再選択
    SCP->>PCFB: 転送
    Note over PCFB: 共有ContextからSM Policy Associationを参照
    PCFB-->>NEF: 201 Created + Location + 3gpp-Sbi-Binding（任意、経由はSCP）
    PCFB->>SMF: Npcf_SMPolicyControl_UpdateNotify（PCC Rule更新）
    opt 必要なシナリオ
        PCFB->>BSF: Nbsf_Management_Update（新Instanceを反映）
    end

これは理解用の概念図です。実際の再選択条件、エラー応答、リトライ回数、Contextの引継ぎ方法は、仕様のProcedureと実装構成に依存します。SCPを経由するだけで全ての障害が自動回復するわけではありません。

Signal Flow¶

再選択したら、リソースURIはどうなるか¶

ProducerのリソースURIは {apiRoot}/{apiName}/{apiVersion}/{resource} の形をしています（TS 29.501 §4.4.1、要確認）。NF Set内での再選択では、apiRoot部分を代替Instanceのものに置き換え、残りのパスは維持して 後続Requestを送る、という考え方が取られます（TS 29.500 §6.12、枝番・条件は要確認）。代替Instanceがリソースを引き継いだ場合、応答の Location や新しい 3gpp-Sbi-Binding で更新後の宛先が返ることがあり、Consumerは以後その値を使うことが想定されます（Consumer側の規定は TS 29.500 §6.12 で要確認）。

旧: https://pcf-a.example/npcf-policyauthorization/v1/app-sessions/as-123
新: https://pcf-b.example/npcf-policyauthorization/v1/app-sessions/as-123
    └ apiRoot だけが変わる ┘└──────── パスは同じ ────────────────┘

このとき、パスが同じでもPCF-BがContext（as-123）を引けなければ処理は失敗します。ここが「ルーティングの切替」と「Contextの継続」が別問題である理由です。

PCF障害時の切替を3段階で考える¶

flowchart TD
    F["PCF-A障害"] --> A1
    subgraph SA["段階A: 発見・ルーティング（3GPPが規定）"]
        A1["Binding Levelと併記範囲を確認"] --> A2["NRFで同一PCF SetのInstanceを確認
NF Status / Service / Endpoint"]
        A2 --> A3["Consumer または SCPが
許容範囲内で再選択"]
    end
    A3 --> B1
    subgraph SB["段階B: Context継続性（主に実装依存）"]
        B1["代替PCFがSM Policy Association
AF Session / PCC Ruleを参照できるか"]
    end
    B1 --> C1
    subgraph SC["段階C: Binding整合性"]
        C1["BSFのPCF Binding"] --- C2["SBIのBinding Indication"]
        C2 --- C3["実際に処理したPCF Instance"]
    end

段階A：経路を切り替えられるか？

PCF-A障害
   ↓
Binding Level確認（NF Set Level か、NF Instance Level + NF Set併記か）
   ↓
NRFのNF Profile（nfSetIdList / Status / Service / Endpoint）を確認
   ↓
Consumer（Direct）または SCP（Indirect）が許容範囲内で再選択

段階B：代替PCFがContextを扱えるか？

PCF-B
 ├─ SM Policy Association のContextを参照できる？
 ├─ AF Session と PCC Rule の関連を維持できる？
 └─ Context共有（UDSF / 実装固有DB）や同期は完了している？

NF Setの定義自体が「同じContextデータにアクセスできる」ことを前提としています（TS 23.501 §5.21.3）。Contextを置く場所として UDSF（非構造化データの格納）を使う構成もありますが、具体的な共有・複製・復旧方式はVendor実装依存 です。

段階C：Bindingが整合しているか？

BSF の PCF Binding
       ↕
SBI の Binding Indication（Consumerが保存した値 / Routing-Binding）
       ↕
実際にRequestを処理したPCF Instance（3gpp-Sbi-Producer-Id / Location）

新しいPCF Instanceが選ばれた場合、BSFのBindingを Nbsf_Management_Update で更新する必要があるシナリオがあります（TS 23.503 §6.1.1.2.2、適用条件は要確認）。Binding Level が NF Set でBSFに登録されていれば、Set内のInstance交代ではBSF側の記載と矛盾しにくくなりますが、NF Instance Levelで登録されている場合は古いInstanceを指したままになり得ます。

Direct Communication の場合¶

SCPを使わない Direct Communication（Model A / B）では、Consumer自身 がBinding Indicationと NRF から得たNF Set情報を使って再選択し得ます。Indirect Communication（Model C / D）では、Consumerが付けた 3gpp-Sbi-Routing-Binding 等を見て SCP が再選択を行えます。どちらの場合も、Binding Level（と併記された範囲）が判断の基準になります（TS 23.501 §6.3.1.0）。通信モデルの全体像は SBI Communication Model A–D で扱います。

Packet Analysis (Wireshark)¶

Display Filter¶

フィールド名（http2.header.name / http2.headers.path 等）はWiresharkの版で異なる場合があります（要確認）。HTTP/2ではHeader名は小文字で運ばれます（RFC 9113 §8.2.1）。

Decode例（概念表現）¶

以下は表示構造の概念表現で、値は架空例です（要キャプチャ）。

HyperText Transfer Protocol 2
 └─ Stream: HEADERS, Stream ID: 7
     ├─ :method: POST
     ├─ :scheme: https
     ├─ :authority: scp.example:443
     ├─ :path: /npcf-policyauthorization/v1/app-sessions
     ├─ 3gpp-sbi-target-apiroot: https://pcf-a.example:443
     └─ 3gpp-sbi-routing-binding: bl=nfset; nfset=set1.pcfset.5gc.mnc001.mcc001

HyperText Transfer Protocol 2
 └─ Stream: HEADERS, Stream ID: 7
     ├─ :status: 201
     ├─ location: https://pcf-b.example:443/npcf-policyauthorization/v1/app-sessions/as-123
     ├─ 3gpp-sbi-binding: bl=nfset; nfset=set1.pcfset.5gc.mnc001.mcc001
     └─ 3gpp-sbi-producer-id: <PCF-B の NF Instance ID>

この例では、Consumerは PCF-A 宛て（Target-apiRoot）に送ったが、応答のLocationとProducer-IdはPCF-B を示しています。SCPがNF Set内で再選択したことを示す典型的な読み筋です（Producer-Id を付けるのがSCPかProducerか、付与条件は要確認）。

見る順番¶

flowchart LR
    A["① BSF Discovery応答
pcfId / pcfSetId / bindLevel"] --> B["② 後続Request Header
Routing-Binding / Target-apiRoot"]
    B --> C["③ SCPの転送先
SCP⇔PCF区間のキャプチャ"]
    C --> D["④ 応答
status / Location / Binding / Producer-Id"]
    D --> E["⑤ 後続処理
UpdateNotify / PFCP"]

• 同じ Stream ID でRequestと応答を対応付けます（Stream IDはHTTP/2コネクション単位なので、Consumer⇔SCP区間とSCP⇔PCF区間では別のIDになります）。
• TLSで暗号化されている場合は、復号可能なTrace（鍵ログ等）や各NFのSBIログを使います。HeaderがCapture上で見えないだけで、送信されていないとは断定しません。
• HTTP/2 / ProblemDetails の読み方は N7 SBI解析、全体のTipsは パケット解析のTips を参照してください。

Trouble Shooting¶

ケース1：PCF-AがDown、PCF-BはHealthyなのにRequestが失敗する¶

調査の順序:

1. BSF Discovery応答の PCF Instance ID / PCF Set ID / Binding Level を確認する
2. 後続Requestの 3gpp-Sbi-Routing-Binding（bl と併記範囲）を確認する
3. NRFに PCF-B が 同じNF Set ID で登録され、必要なNF Serviceを提供しているか確認する
4. SCP（またはDirectならConsumer）が 仕様上許される範囲で PCF-Bを再選択したか確認する
5. PCF-Bが対象Contextを持つか、参照可能か確認する

ケース2：BSFはPCF-Bを返すのに、RequestはPCF-Aへ向かう¶

BSF応答・後続Request Header・SCPの実際の転送先 の3点を比較します。NEF/AFは、PolicyAuthorization Create 以降は 作成時に保存したリソースURIとBinding Indication で後続Requestを送るため、BSFの最新値を毎回参照するとは限りません。継続中のService Sessionでは Producer から受け取った Binding Indication が優先される場合があります（TS 23.501 §6.3.1.0、適用条件は要確認）。BSFの値だけを見て誤転送と断定しない ことが重要です。

ケース3：HTTP/2は成功したのにPolicyが反映されない¶

NEF → SCP → PCF-B   HTTP 201/204 成功
                    │
                    ├─ PCF-B は正しい Policy Association Context に紐付けた？
                    ├─ PCF-B → SMF の UpdateNotify は送られた？宛先SMFは正しい？
                    └─ SMF → UPF の PFCP Session Modification は成功した？

HTTP成功とPolicyのEnd-to-End成功は別 です。SMF側もNF Setで冗長化されている場合、PCFからの通知はSMFが示したBinding（手順1）に従って届けられます。PFCP側は PFCP Rules を参照してください。

症状別一覧¶

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

EPC（4G）との比較¶

4GではPCRFの冗長化の多くがベンダー独自のクラスタ設計に委ねられていましたが、5GではNF Set・Binding Level・SCPによる再選択の 原則 が3GPPで規定された点が大きな違いです（ただしContext共有の方式は依然として実装依存）。

3GPP Specification¶

Summary¶

• NF Instance は個別のNF実体、NF Set は同じContextにアクセスできる相互代替可能なNF Instance群。NF Service Set は1つのNF Instance内のService Instance群
• Binding Level は後続Requestの結び付け範囲であり、障害時の Reselection の許容範囲 を判断する出発点。NF Instance Level＋NF Set併記は、通常は指定Instance、利用不可時のみSet内で再選択
• BSFのPCF Binding は主に「最初に担当PCFを見つける」ための台帳、SBIのBinding Indication（3gpp-Sbi-Binding / 3gpp-Sbi-Routing-Binding）は「後続Requestをどこへ運ぶか」のHeader。Producerによる 3gpp-Sbi-Binding の付与は任意
• SCP は Indirect Communication で Routing-Binding を見て再選択できるが、それだけで全障害が回復するわけではない
• PCF障害時は ①発見・ルーティング ②Context継続性 ③Binding整合性 の3段階で切り分ける。Routingの切替とPolicy Contextの継続は別問題

理解度チェック¶

Next Step¶

• SCPを使う通信モデルを Packet Capture で比較 → SBI Communication Model A–D / SCP / SCP
• 担当PCFを見つける台帳の詳細 → BSF / PCF Binding / BSF
• PCFとPolicy Associationの基本 → PCF / SM Policy Association / PCC Rule / PCF
• SBIのHTTP/2・ProblemDetailsの読み方 → N7 SBI解析
• AF / NEF側からの要求 → AF / N5 / Application Session / NEF / N33 / Event Exposure
• AMF Setとの対比 → GUAMI / AMF Region / Set / Pointer
• Context共有の格納先 → UDSF / NRF