SBI Communication Model A〜D / SCP — DiscoveryとRoutingは別の仕事¶

学習目標¶

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

• SBIでNFを呼ぶときの仕事を Discovery（候補を探す）/ Selection（1つに決める）/ Routing（届ける経路） に分けて説明できる
• 4つの Communication Model（A / B / C / D） を「Direct / Indirect」と「Discoveryを誰が行うか」の2軸で説明できる（TS 23.501 Annex E）
• Model C と Model D を HTTP/2 ヘッダ（3gpp-sbi-target-apiroot、3gpp-sbi-discovery-*、3gpp-sbi-producer-id）と NRFへの通信経路 の組み合わせで見分けられる
• SMF → PCF の SM Policy Association 作成 を Model D で行うときの Call Flow を、ヘッダ単位で追える
• SCP経由の失敗を 「SCPが返したエラー」か「Producerが返したエラー」か に切り分けられる

前提知識¶

• SCP — Model A〜D の概要（この章はその深掘り）
• NRF — NF Profile と Nnrf_NFDiscovery
• NF Set / Binding Indication / PCF冗長 — NF Set、3gpp-Sbi-Routing-Binding
• N7 SBI解析 — HTTP/2・ProblemDetails の読み方
• 補助: PCF / N7 / 5GC概要とSBA / HTTP API辞典 / Protocol辞典

Why — なぜ「Discovery」と「Routing」を分けて考えるのか¶

SMFがPCFへ SM Policy Association を作りたいとき、少なくとも次の判断が必要です。

[Discovery]  「Npcf_SMPolicyControl を提供できる PCF はどれ？」 → 候補リスト
      ↓
[Selection]  「今回は PCF-B を使おう」                            → 1つに決定
      ↓
[Routing]    「SMF → PCF-B へ直接？ それとも SCP 経由？」          → 届ける経路

SBAの初期（Rel-15）は、Consumer（SMF）自身が NRF に問い合わせ（Discovery）、自分で選び（Selection）、直接送る（Routing）形が基本でした。Rel-16 で SCP（Service Communication Proxy） が導入され、Routing を SCP に任せる Indirect Communication と、さらに Discovery / Selection まで SCP に任せる Delegated Discovery が加わりました（TS 23.501 §6.2.19 / Annex E）。

その結果、「SCPを経由している」という事実だけでは、誰が候補を探し、誰が宛先を決めたのか が分からなくなりました。障害解析で「SCPが悪いのか、NRFのProfileが悪いのか、SMFの設定が悪いのか、PCFが拒否したのか」を切り分けるには、この3つの仕事を分けて見る必要があります。

例え話: 社外の専門家に仕事を頼む場面を考えます。Model A は「名刺ファイルに書いてある番号へ直接電話」、Model B は「電話帳（NRF）で調べて直接電話」、Model C は「電話帳で相手を決めてから、代表交換（SCP）に『○○さんにつないで』と頼む」、Model D は「代表交換に『こういう条件の専門家につないで』とだけ頼み、探すのも選ぶのも交換手に任せる」です。交換手経由（C と D）でも、相手を決めたのが自分か交換手か で、トラブル時に確認すべき場所が変わります。

What — 4つの Communication Model¶

全体像（TS 23.501 Annex E）¶

TS 23.501 の informative Annex E「Communication models for NF/NF services interaction」 は、NF/NF Service 間の相互作用を4つのモデルに整理しています（比較表は Table E.1-1。表番号は要確認）。Direct / Indirect Communication そのものの規定は TS 23.501 §6.3.1.0 と §7.1.1 にあります（要確認）。

flowchart LR
    subgraph DIRECT["Direct Communication"]
        A["Model A
ローカル設定
NRFなし"]
        B["Model B
Consumer が
NRF Discovery"]
    end
    subgraph INDIRECT["Indirect Communication（SCP経由）"]
        C["Model C
Consumer が NRF Discovery
SCP は Routing"]
        D["Model D
Discovery と Selection を
SCP に委譲"]
    end
    A -->|"Discovery を足す"| B
    B -->|"Routing を SCP へ"| C
    C -->|"Discovery も SCP へ"| D

Model A — Direct、NRFなし¶

SMF ──────────────────────────► PCF-A
      宛先 apiRoot はローカル設定

• SMF は PCF-A の FQDN / IP をローカル設定で持っています。NRF も SCP も登場しません。
• 小規模構成やラボで多い形です。PCF-A が落ちたときの代替先も設定で持つ必要があります。

Model B — Direct、Consumer が NRF Discovery¶

SMF ── Nnrf_NFDiscovery ──► NRF
SMF ◄─ NF Profile 候補 ──── NRF
SMF ── SBI Request ───────────────► PCF-B

• SMF が GET /nnrf-disc/v1/nf-instances?target-nf-type=PCF... で候補を得て（TS 29.510、節番号は要確認）、自分で選び、直接送ります。
• Rel-15 の基本形です。

Model C — Indirect、Consumer が NRF Discovery、SCP は Routing¶

SMF ── Nnrf_NFDiscovery ──► NRF
SMF ◄─ NF Profile 候補 ──── NRF
SMF ── SBI Request ──► SCP ──► PCF-B
       (宛先を指定)

• SMF は Discovery と Selection を自分で行い、選んだ宛先を Request に明示して SCP へ送ります。
• 宛先の明示に使うのが 3gpp-Sbi-Target-apiRoot ヘッダです（後述）。

Model D — Indirect、Delegated Discovery¶

SMF ── SBI Request ───────► SCP ── Nnrf_NFDiscovery ──► NRF
       + Discovery 条件          ◄── NF Profile 候補 ──
                                 SCP が PCF-B を選択
                            SCP ── SBI Request ───────► PCF-B

• SMF は NRF を見ません。「こういう条件の Producer に届けて」という Discovery 条件 を 3gpp-Sbi-Discovery-* ヘッダで Request に載せて SCP へ送ります（TS 29.500 §6.10.3、要確認）。
• SCP が Discovery と Selection を行い、選んだ Producer へ転送します。

SCP の機能（TS 23.501 §6.2.19）¶

SCP の機能定義は TS 23.501 §6.2.19 にあります。主な項目は次のとおりです（列挙は要約。原文の網羅性・表現は要確認）。

• SCP 自身は PCF や UDM のような NF Service を提供するわけではありません。あくまで他の NF の Service への通信を仲介する要素です。
• SCP 自体の発見・選択（Consumer がどの SCP を使うか）は TS 23.501 §6.3.16（要確認）で扱われ、ローカル設定や NRF を用いた方法があります。

例え話: SCP は「代表交換＋配車センター」です。電話をつなぐ（Routing）だけでなく、頼まれれば条件に合う担当者を探して（Discovery）割り当てる（Selection）ところまでやりますが、自分で料理を作る（Policy を決める）わけではありません。

How — Model C と Model D を HTTP/2 で見分ける¶

SCP の前後は別の HTTP/2 接続¶

SMF ══ TLS/HTTP2 接続① ══ SCP ══ TLS/HTTP2 接続② ══ PCF
      :authority = SCP           :authority = PCF-B

SCP は HTTP のアプリケーション層で中継するので、SMF→SCP と SCP→PCF は別の TCP / TLS / HTTP/2 接続 です。接続①のパケットだけを見ても、接続②が成功したかは分かりません。

Model C の Request（Consumer が PCF-B を選択済み）¶

:method: POST
:scheme: https
:authority: scp.5gc.example
:path: /npcf-smpolicycontrol/v1/sm-policies
3gpp-sbi-target-apiroot: https://pcf-b.5gc.example
content-type: application/json

• :authority は このホップの宛先（SCP）です。
• 3gpp-sbi-target-apiroot は 最終宛先の apiRoot（{scheme}://{authority}[/{apiPrefix}] 形式。apiPrefix は任意。apiRoot の定義は TS 29.501 §4.4.1、要確認）です。ヘッダ定義は TS 29.500 §5.2.3.2（枝番は要確認）、SCP への Request の宛先指定方法は TS 29.500 §6.10.2（要確認）。
• SCP は、このヘッダの apiRoot を使って Request URI を組み立て直し、PCF-B へ転送します（ヘッダの削除・書き換えの細部は TS 29.500 §6.10.2、要確認）。
• SCP 側の URI に apiPrefix が付く構成もあります（例: /scp-prefix/npcf-smpolicycontrol/...。付けるかどうかは構成依存）。

Model D の Request（Discovery を SCP に委譲）¶

:method: POST
:scheme: https
:authority: scp.5gc.example
:path: /npcf-smpolicycontrol/v1/sm-policies
3gpp-sbi-discovery-target-nf-type: PCF
3gpp-sbi-discovery-requester-nf-type: SMF
3gpp-sbi-discovery-service-names: npcf-smpolicycontrol
3gpp-sbi-discovery-snssais: [{"sst":1,"sd":"010203"}]
3gpp-sbi-discovery-dnn: internet
content-type: application/json

• 3gpp-sbi-target-apiroot が無い のが最初の手掛かりです。Consumer はまだ宛先を知りません。
• 3gpp-Sbi-Discovery-<パラメータ名> 形式のヘッダは、Nnrf_NFDiscovery の検索条件（query parameter）と対応 します（ヘッダ定義は TS 29.500 §5.2.3.2 内の Discovery 系ヘッダの節。§5.2.3.2.7 とされるが枝番は要確認。各パラメータの意味は TS 29.510）。
• Nnrf_NFDiscovery では target-nf-type と requester-nf-type が必須の query parameter です（TS 29.510、節番号は要確認）。Delegated Discovery で Consumer が必ず付けるべき 3gpp-Sbi-Discovery-* ヘッダ、および SCP が requester の NF Type をどこから得るかは TS 29.500 §6.10.3 を参照してください（要確認）。
• 値のエンコード（配列や JSON オブジェクトの書き方）は 要確認。上の例は説明用の概念表現で、そのまま送れる完全な Request ではありません。

Response 側の手掛かり — 3gpp-Sbi-Producer-Id¶

Model D では、SMF は「どの PCF が選ばれたか」を知りません。そのため Response には、選ばれた Producer を示す 3gpp-sbi-producer-id（NF Instance ID。NF Service Instance ID 等を含み得る）が付いて SMF に届きます。Producer 自身が付けるのか SCP が付けるのか、付与条件はどうかは TS 29.500 §5.2.3.2 / §6.10.3 を参照してください（いずれも枝番を含め要確認）。

:status: 201
location: https://pcf-b.5gc.example/npcf-smpolicycontrol/v1/sm-policies/abc123
3gpp-sbi-producer-id: nfinst=54804518-4191-46b3-955c-ac631f953ed8
content-type: application/json

（値は架空例。ヘッダ値の書式は要確認）

• location には PCF-B の apiRoot が入っており、SMF は以後このリソースを PCF-B 上のものとして扱えます。
• 以後の Update / Delete では、SMF は 3gpp-sbi-target-apiroot（Location 由来） を付けて SCP へ送ります（TS 29.500 §6.10、要確認）。再選択に備えて 3gpp-sbi-discovery-* や 3gpp-sbi-routing-binding を併せて付けることもあります。つまり Model D の運用でも、2通目以降の Request は Model C と同じ見た目 になり得ます（TS 29.500 §6.10、要確認）。
• PCF が Binding Indication（3gpp-sbi-binding）を返した場合、SMF は後続 Request に 3gpp-sbi-routing-binding を付け、PCF-B が使えないときに SCP が同じ NF Set 内の代替 PCF へ再選択できるようにします（詳細は NF Set / Binding Indication / PCF冗長）。

判定の早見表¶

Call Flow — SMF → PCF の SM Policy Association を Model D で作る¶

PDU Session Establishment の中で、SMF は SM Policy Association を確立します（TS 23.502 §4.16.4、Npcf_SMPolicyControl_Create は TS 29.512 §4.2.2、いずれも要確認）。この Create を Model D で行う場合の流れです。

sequenceDiagram
    participant SMF
    participant SCP
    participant NRF
    participant PCF as PCF-B
    SMF->>SCP: (1) POST /npcf-smpolicycontrol/v1/sm-policies
authority=SCP, discovery-target-nf-type=PCF
discovery-service-names, snssais, dnn
    alt SCP に有効なキャッシュが無い
        SCP->>NRF: (2) GET /nnrf-disc/v1/nf-instances
target-nf-type=PCF ほか
        NRF-->>SCP: (3) 200 OK SearchResult
nfInstances = PCF-A, PCF-B
    end
    SCP->>SCP: (4) PCF-B を選択
Priority, Capacity, Load 等を考慮
    SCP->>PCF: (5) POST /npcf-smpolicycontrol/v1/sm-policies
authority=PCF-B
    PCF-->>SCP: (6) 201 Created
Location, SmPolicyDecision
    SCP-->>SMF: (7) 201 Created
3gpp-sbi-producer-id=PCF-B
    Note over SCP,SMF: producer-id の付与主体と条件は要確認
    Note over SMF: SM Policy Association 成立
以後は Location の apiRoot を
target-apiroot として使う
    SMF->>SCP: (8) POST .../sm-policies/abc123/update
target-apiroot=PCF-B, routing-binding
    SCP->>PCF: (9) POST .../sm-policies/abc123/update

Signal Flow 表¶

見るべき対応関係は SMF の Discovery 条件 → NRF が返した NF Profile → SCP が選んだ PCF → PCF の Response → SMF に残った Association（Location） の一本の線です。

SCP経由の失敗 — SCP が返したのか、Producer が返したのか¶

SCP が入ると、SMF が受け取るエラーには 2つの出どころ があります。

flowchart TD
    E["SMF がエラー Response を受信"] --> S{"Server ヘッダは?"}
    S -- "SCP を示す値" --> SCPERR["SCP が生成したエラー
Discovery 失敗 / 宛先到達不可 /
タイムアウト / 過負荷 等"]
    S -- "PCF を示す値" --> PCFERR["Producer が生成したエラー
SCP は中継しただけ"]
    S -- "無い / 判別不能" --> T["ProblemDetails の cause と
SCP-PCF 区間の Trace で判定"]
    SCPERR --> N1["SCP-NRF / SCP-PCF 区間を調べる"]
    PCFERR --> N2["PCF のログと Request 内容を調べる"]

例え話: 宅配の不在票が「配送センター（SCP）発行」か「届け先（PCF）が受け取り拒否」かで、次に電話する相手が変わります。不在票の発行元欄（server ヘッダ）と、配送記録（SCP⇔PCF区間の Trace）の両方を見て判断します。

Packet Analysis (Wireshark)¶

Display Filter¶

フィールド名（http2.headers.path 等）は Wireshark の版で異なり得るため 要確認 です。GUI でヘッダを右クリックして「フィルタとして適用」すると確実です。

Decode例（概念表現）¶

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

HyperText Transfer Protocol 2
 └─ Stream: HEADERS, Stream ID: 1, Length ...
     ├─ Header: :method: POST
     ├─ Header: :scheme: https
     ├─ Header: :authority: scp.5gc.example
     ├─ Header: :path: /npcf-smpolicycontrol/v1/sm-policies
     ├─ Header: 3gpp-sbi-discovery-target-nf-type: PCF
     ├─ Header: 3gpp-sbi-discovery-requester-nf-type: SMF
     ├─ Header: 3gpp-sbi-discovery-service-names: npcf-smpolicycontrol
     └─ Header: content-type: application/json

HyperText Transfer Protocol 2
 └─ Stream: HEADERS, Stream ID: 1, Length ...
     ├─ Header: :status: 504
     ├─ Header: server: SCP-scp.5gc.example
     └─ Header: content-type: application/problem+json
 └─ Stream: DATA
     └─ JSON: {"status":504, "cause":"TARGET_NF_NOT_REACHABLE", ...}

ProblemDetails の Content-Type は application/problem+json です（RFC 9457、旧 RFC 7807。TS 29.500 §5.2.7、要確認）。

見る順番¶

flowchart LR
    A["① SMF-SCP
authority, path
target-apiroot か
discovery-* か"] --> B["② SCP-NRF
Discovery の
query と SearchResult"]
    B --> C["③ SCP-PCF
接続と Request
authority=PCF"]
    C --> D["④ PCF の Response
201 / 4xx / 5xx
Location"]
    D --> E["⑤ SCP-SMF
producer-id
server ヘッダ"]

SMF → SCP：HTTP/2 接続 OK
       ≠
SCP → PCF：HTTP/2 接続 OK
       ≠
PCF：SM Policy Association 作成 OK

Trouble Shooting¶

よくある誤解¶

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

EPC（4G）との比較¶

EPC の Diameter 系インタフェースにも、メッセージを中継するエージェント（Relay / Proxy / Redirect Agent、RFC 6733 §2.8）や、PCRF 選択のための DRA（Diameter Routing Agent）（TS 29.213 §7、要確認）がありました。考え方は似ていますが、同じものではありません。

右列と左列は 類推による対応 であり、仕様上の対応関係を定義したものではありません。

3GPP Specification¶

Summary¶

• SBI で NF を呼ぶ仕事は Discovery / Selection / Routing の3つに分かれる
• Model A: Direct・NRFなし ／ B: Direct・Consumer が NRF Discovery ／ C: SCP 経由・Consumer が NRF Discovery ／ D: SCP 経由・Discovery と Selection を SCP に委譲
• Model C でも、NF Set まで指定された場合は SCP が Instance を選ぶ。Discovery と Selection は別物
• 初回 Request に 3gpp-sbi-target-apiroot があれば Consumer が宛先を決めた（C 型）、無くて 3gpp-sbi-discovery-* があれば委譲（D 型）。ただし単一ヘッダで断定せず、Consumer→NRF の通信の有無も見る
• Model D では Response の 3gpp-sbi-producer-id（付与主体は要確認）で選ばれた Producer が分かり、以後は Location 由来の target-apiroot で送る
• SCP の前後は 別の HTTP/2 接続。エラーは server ヘッダ・cause・SCP⇔PCF 区間の Trace で SCP 起因か Producer 起因かを切り分ける
• SCP の routing policy、キャッシュ、Retry、Service Mesh での実装は Vendor 実装依存

理解度チェック¶

Next Step¶

• SCP の基本と Model A〜D の位置づけ → SCP
• NF Profile と Discovery の基礎 → NRF
• SCP 経由の再選択を支える NF Set / Binding → NF Set / Binding Indication / PCF冗長 / BSF / PCF Binding / BSF
• N7 上の HTTP/2 と ProblemDetails の読み方 → N7 SBI解析 / N7 / PCF
• PLMN 間の SBI 中継（SCP との対比） → SEPP / N32
• SBI の API とプロトコルを引く → HTTP API辞典 / Protocol辞典 / Spec辞典
• Trace の取り方と仕様の読み方 → Packet Analysis Tips / Spec Reading Tips