BSF / PCF Binding — 複数PCFの中から「そのSessionのPCF」を見つける¶

学習目標¶

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

• BSF が「Policyを決めるNF」ではなく、既に選ばれたPCFへの到達を支援するNF であることを説明できる
• NRF（利用可能なPCF候補の発見） と BSF（このPDU Sessionを担当するPCFの発見） の違いを説明できる
• PcfBinding に含まれる情報（UE IP / IPv6 prefix、DNN、S-NSSAI、SUPI / GPSI、PCF FQDN / IP Endpoint / Instance ID / Set ID、Binding Level）を説明できる
• Nbsf_Management の Register / Deregister / Discovery / Update / Subscribe と、HTTP上の見え方を説明できる
• Discovery の 200 OK と 204 No Content の意味の違いを理解し、BSFが絡む障害を Trace で切り分けられる

前提知識¶

• PCF / SM Policy Association / PCC Rule — SMFとPCFの間の SM Policy Association
• AF / N5 / Application Session — AFがPCFへQoS等を要求する Npcf_PolicyAuthorization
• NEF / N33 / Event Exposure — 外部AFの要求をNEFが5GC内部へ橋渡しする仕組み
• 補助: BSF / PCF / NRF / N5 / Policy

Why — なぜ「そのSessionのPCF」を探す仕組みが必要なのか¶

商用網では、PCFは冗長化・負荷分散のために 複数台 配置されるのが普通です。PDU Session確立時、SMFは NRF 等を使って PCF を1つ選び、SM Policy Association を作ります（PCF Discovery and Selection は TS 23.501 §6.3.7.1、要確認。TS 23.503 側の関連節も要確認）。

問題はその後です。アプリケーション側（AF）や NEF が「UE IP 10.1.1.10 の通信の QoS を上げたい」と要求するとき、要求は そのPDU SessionのSM Policy Associationを持っているPCF に届かなければ意味がありません。

           SMF ──── N7 ──── PCF-B   ← このSessionのSM Policy Associationを持つ
            │
       PDU Session
       UE IP = 10.1.1.10

External AF ─N33→ NEF ─→ PCF-A ?   ← 別のPCFに届くと、対象Sessionを知らない
                     └─→ PCF-B ✓   ← 正しいPCFに届けば、PCC Ruleを更新できる

AF / NEF は SMF がどのPCFを選んだかを知りません。NRFに聞いても返ってくるのは「PCFとして利用可能な候補」であって、「このSessionの担当PCF」ではありません。そこで、PDU Session（UEアドレス等）と担当PCFの対応関係 を保持し、検索できる NF が必要になります。それが BSF（Binding Support Function） です（TS 23.503 §6.1.1.2）。

例え話: NRFは「病院の医師名簿」で、どの科にどの医師がいるかは分かりますが、「Aさんの主治医は誰か」は分かりません。BSFは「受付のカルテ台帳」で、患者（PDU Session）ごとに主治医（PCF）が記録されています。外部からの問い合わせ（AF要求）は、名簿ではなくカルテ台帳を引いて主治医へ回さないと、話の通じない医師に届いてしまいます。

What — BSF と PCF Binding の位置づけ¶

NRF / BSF / PCF の役割の違い¶

NRF と BSF は対立するものではなく、2段階 で使われることがよくあります。

flowchart LR
    NEF["NEF / AF"] -- "① Nnrf_NFDiscovery
target-nf-type=BSF" --> NRF["NRF"]
    NRF -- "BSFの候補
(BsfInfo: IPv4範囲 / DNN 等)" --> NEF
    NEF -- "② Nbsf_Management_Discovery
UE IP / DNN / S-NSSAI" --> BSF["BSF"]
    BSF -- "PcfBinding
(PCF FQDN / Endpoint / Instance ID / Set ID)" --> NEF
    NEF -- "③ Npcf_PolicyAuthorization" --> PCF["PCF-B
(担当PCF)"]

BSF は NRF に NF Type BSF として登録でき、NF Profile の BsfInfo に担当する UE IPv4 アドレス範囲・IPv6 prefix 範囲・DNN・IP Domain 等を載せられます（TS 29.510、BsfInfo の定義節は要確認）。BSF を複数配置する網では、Consumer はまず NRF で「このUEアドレスを担当するBSF」を探し、そのBSFに Binding を問い合わせます。NRF を使わずローカル設定で BSF を固定する構成もあります（実装・配備依存）。

BSF の配備形態¶

TS 23.503 §6.1.1.2 は、BSF を 単独のNF として配備することも、他のNF（PCF、UDR、NRF、SMF 等）と同居 させることも認めています（列挙の正確な範囲・枝番は要確認）。なお TS 23.501 §6.2（Network Functions の機能記述）には BSF の独立節がなく、BSF の役割は TS 23.503 側に記述されています（NF辞典 の注記参照）。

さらに、BSF は次のような「ルーティング寄り」の振る舞いも持ち得ます。

PcfBinding — 台帳に書かれていること¶

BSF が保持する Binding 情報は、TS 29.521 の PcfBinding データ型で表現されます（TS 29.521 §5.6.2.2、節番号は要確認）。代表的な属性を、役割ごとに整理します。

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

UE IPv4: 10.1.1.10
  ├─ DNN=internet,   S-NSSAI=SST1/SD 010203 → PCF-B
  └─ DNN=enterprise, S-NSSAI=SST1/SD 0A0B0C → PCF-C

How — Binding の登録・検索・利用¶

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

Update は Rel-16 で、Subscribe / Notify は Rel-17 で追加された機能で、利用には Supported Features のネゴシエーションが関係します（Release・Feature 名は要確認）。

HTTP 上の見え方（PDU Session Binding）¶

{apiRoot}/nbsf-management/v1 を API のルートとします（TS 29.521 §5.1 / §5.3、節番号は要確認）。

Register で返る bindingId（Location ヘッダ） を PCF が覚えておき、Update / Deregister ではそれを使います。Discovery は 個別リソースではなくコレクションへのクエリ なので、Consumer は bindingId を知らなくても検索できます。

Call Flow — 登録 → 検索 → Policy 適用¶

以下は、PDU Session が確立して PCF-B が選択された後、外部 AF が NEF 経由で QoS を要求する場合の 概念的な順序 です。実際のタイミングや追加メッセージはシナリオ・Release により異なります。

sequenceDiagram
    participant SMF
    participant PCFB as PCF-B
    participant BSF
    participant NRF
    participant NEF
    participant AF
    participant UPF
    SMF->>PCFB: Npcf_SMPolicyControl_Create
(SUPI, DNN, S-NSSAI, UE IPv4)
    PCFB-->>SMF: 201 Created (SM Policy Decision)
    PCFB->>BSF: Nbsf_Management_Register
POST /pcfBindings (PcfBinding)
    BSF-->>PCFB: 201 Created
Location: .../pcfBindings/{bindingId}
    Note over SMF,UPF: しばらく後、アプリ側からQoS要求
    AF->>NEF: N33 AF Session with QoS 要求
(UE IPv4, 要求QoS)
    NEF->>NRF: Nnrf_NFDiscovery (target-nf-type=BSF)
    NRF-->>NEF: BSF候補 (NF Profile / BsfInfo)
    NEF->>BSF: Nbsf_Management_Discovery
GET /pcfBindings?ipv4Addr=...&dnn=...&snssai=...
    BSF-->>NEF: 200 OK (PcfBinding: PCF-B FQDN / Endpoint)
    NEF->>PCFB: Npcf_PolicyAuthorization_Create
    PCFB-->>NEF: 201 Created
    PCFB->>SMF: Npcf_SMPolicyControl_UpdateNotify
(PCC Rule 更新)
    SMF->>UPF: PFCP Session Modification Request
    UPF-->>SMF: PFCP Session Modification Response
    Note over PCFB,BSF: PDU Session Release 時
    PCFB->>BSF: Nbsf_Management_Deregister
DELETE /pcfBindings/{bindingId}
    BSF-->>PCFB: 204 No Content

図のポイントは、Binding を登録するのは PCF、検索するのは NEF / AF（あるいは SCP） である点です。SMF は BSF に登録しません。Trusted AF は NEF を介さずに担当 PCF を見つけ、N5 で直接要求できます（N5）。見つけ方は、BSF への Discovery、SCP 経由、Rx を使う AF なら BSF の Diameter Proxy / Redirect、ローカル設定などがあり、どれを使うかは 配備依存 です。NEF 経由の要求の流れの詳細は NEF / N33 を参照してください。

PCF はいつ登録・更新・削除するか¶

TS 23.503 §6.1.1.2（枝番は要確認）の考え方を整理すると次のとおりです。

Signal Flow¶

Packet Analysis (Wireshark)¶

Display Filter¶

HTTP/2 ヘッダのフィールド名（http2.headers.path / http2.headers.status 等）や型は Wireshark の版で異なるため断定しません（要確認）。SBI は通常 TLS で保護されるため、中身を見るには TLS 鍵ログによる復号 か、NF 側の Trace / ログ が必要です（Packet Analysis の Tips）。

Decode例（概念表現）¶

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

[PCF-B → BSF] HEADERS
  :method: POST
  :path: /nbsf-management/v1/pcfBindings
  content-type: application/json
[PCF-B → BSF] DATA  (JSON: PcfBinding)
  {
    "supi": "imsi-001010000000001",
    "ipv4Addr": "10.1.1.10",
    "dnn": "internet",
    "snssai": { "sst": 1, "sd": "010203" },
    "pcfFqdn": "pcf-b.example.invalid",
    "pcfIpEndPoints": [ { "ipv4Address": "192.0.2.20", "port": 443 } ],
    "pcfId": "6f1c2c1e-....",
    "pcfSetId": "set1.pcfset.5gc.mnc001.mcc001",
    "bindLevel": "NF_SET"
  }
[BSF → PCF-B] HEADERS
  :status: 201
  location: https://bsf.example.invalid/nbsf-management/v1/pcfBindings/abc123

[NEF → BSF] HEADERS
  :method: GET
  :path: /nbsf-management/v1/pcfBindings?ipv4Addr=10.1.1.10&dnn=internet&snssai=...
[BSF → NEF] HEADERS
  :status: 200            ← 一致あり。DATA に PcfBinding
  （または :status: 204   ← 一致なし。DATA なし）
  （または :status: 400   ← DATA に ProblemDetails, cause = MULTIPLE_BINDING_INFO_FOUND）

snssai のようなオブジェクト型のクエリパラメータは、JSON をエンコードした形で :path に現れます。エンコード後の表示は見づらいので、デコードした値を DNN / S-NSSAI の期待値と並べて 確認します。

見る順番¶

flowchart TD
    A["① SMF → PCF
Npcf_SMPolicyControl_Create
どのPCFが選ばれたか"] --> B["② PCF → BSF
POST /pcfBindings
登録内容 (UE IP / DNN / S-NSSAI)"]
    B --> C["③ BSF → PCF
201 Created / Location / bindingId"]
    C --> D["④ NEF・AF → BSF
GET /pcfBindings
検索条件"]
    D --> E["⑤ BSF → NEF・AF
200 + PcfBinding / 204 / 4xx"]
    E --> F["⑥ NEF・AF → PCF
Npcf_PolicyAuthorization
宛先は ① のPCFと一致するか"]
    F --> G["⑦ PCF → SMF → UPF
UpdateNotify / PFCP Modification"]

確認のコツは、① で SMF が選んだ PCF と、⑤ で BSF が返した PCF と、⑥ で実際に要求が届いた PCF が、同じものか を突き合わせることです。HTTP/2 では :method・:path・:status・stream ID、JSON Body、ProblemDetails の cause を見ます（ProblemDetails の読み方は N7 SBI解析 を参照）。

Trouble Shooting¶

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

BSF が絡む障害では、「Binding が仕様どおり登録・検索されたか（3GPP の信号）」と「BSF 製品内部のデータ同期やキャッシュの問題（実装）」 を分けて考えます。前者は Trace で確認でき、後者は製品ログ・ベンダーサポートの領域です。

EPC（4G）との比較¶

4G の DRA は「メッセージを中継しながら同じ PCRF へ振り分ける」ルーティング要素でしたが、5G の BSF は基本的に 「担当 PCF を教える」検索サービス として整理されています。ただし SCP 経由の間接通信や Diameter Proxy としての振る舞いを組み合わせると、DRA に近い見え方にもなります。

3GPP Specification¶

Summary¶

• BSF は、PDU Session（UE アドレス・DNN・S-NSSAI 等）と 担当 PCF の対応（PcfBinding）を保持し、検索可能にする NF。Policy は決めない
• NRF は「利用可能な PCF（や BSF）の候補」、BSF は「このSessionを今担当する PCF」を答える。2 段階で使われることが多い
• Binding を 登録・更新・削除するのは PCF、検索するのは NEF / AF / SCP。Nbsf_Management は Register / Deregister / Discovery / Update（＋ Rel-17 以降の Subscribe / Notify）
• Discovery の 204 No Content は「一致する Binding が無い」という正常応答。400 MULTIPLE_BINDING_INFO_FOUND は条件が曖昧で一意に決まらないことを示す
• PcfBinding は PCF の宛先（FQDN / Endpoint）と識別（Instance ID / Set ID / Binding Level） を持ち、PCF 冗長時の到達性に関わる
• 障害解析では、SMF が選んだ PCF ＝ BSF が返した PCF ＝ 要求が届いた PCF かを Trace で突き合わせる

理解度チェック¶

Next Step¶

• PCF 冗長と Binding Level / Binding Indication の関係 → NF Set / Binding Indication / PCF冗長
• SCP が BSF を使って担当 PCF へ転送する間接通信 → SBI Communication Model A–D / SCP
• BSF を引く側の NF → NEF / N33 / Event Exposure / AF / N5 / Application Session
• 関連する NF / Interface → BSF / PCF / NRF / SCP / N5 / Policy