SCP — Service Communication Proxy と通信モデル A〜D¶

難易度: 中〜上級／想定学習時間: 25分／関連NF: NRF・全NF ／関連Interface: SBI

学習目標¶

SCP（Service Communication Proxy）が、NF 間の SBI 通信を仲介する「間接通信」の要素であることを説明できる。
NF 間通信の4パターン（Model A / B / C / D）を、Direct / Indirect Communication と Delegated Discovery（発見の委譲） の有無という2軸で区別できる。
各モデルで NRF・SCP がどう関与するか（誰が Discovery し、誰が Routing するか）を説明できる。

前提知識¶

SBA（Service Based Architecture）／NF／SBI の基礎 → 5GC概要とSBA
NRF による NF Registration / Discovery → NRF
Protocol（HTTP/2＋JSON over TLS） → Protocol辞典

この章で学べること¶

まず Why として、NF が直接互いを呼び合う「直接通信」だけでは、経路制御・負荷分散・可観測性といった運用上の要求に応えにくいことを確認します。次に What として、SCP を挟む「間接通信」と、発見（Discovery）を SCP に委譲するかどうかで通信パターンが4つ（Model A〜D）に整理されることを学びます。最後に How として、各モデルの通信の流れを NRF・SCP の関与とともに理解します。

Why — なぜ必要なのか¶

SBA では、各 NF は NRF を使って相手 NF を発見し、SBI（HTTP/2）で直接呼び出せます。しかし NF が多数・動的にスケールする実運用環境では、

呼び出し経路の集約・負荷分散
リトライやフェイルオーバーの共通化
トラフィックの可観測性（監視・トレース）

といった横断的な関心事を、各 NF に個別実装させるのは非効率です。これらを通信を仲介する専用要素にまとめるという発想が SCP（Service Communication Proxy）です。SCP を挟む通信を Indirect Communication（間接通信） と呼びます。

例え話: 直接通信は、社員同士が互いの内線番号を調べて直接電話し合う状態。間接通信（SCP）は、いったん代表電話（交換手）につなぎ、交換手が適切な相手へ取り次ぐ状態です。交換手に「誰につなぐか探す」役目まで任せるか、自分で相手を調べてから「この人につないで」と頼むかで、さらにパターンが分かれます。

Overview — 概要¶

NF 間通信は、次の2つの軸で整理されます。

通信の経路: NF が相手を直接呼ぶ（Direct）か、SCP を経由して呼ぶ（Indirect）か。
発見（Discovery）の主体: 呼び出し側 NF が自分で NRF に問い合わせて相手を発見するか、その発見を SCP に委譲（Delegated Discovery）するか。

この2軸の組み合わせが Model A / B / C / D です。

根拠となる仕様

これらの通信モデルは TS 23.501 の Service Based Architecture に関する記述（Annex 相当の通信モデル整理）で定義されています。節番号・図番号は Release により異なる場合があるため 要確認 としますが、A〜D の分類自体は 3GPP で標準的に用いられる整理です。

Model A〜D の分類¶

モデル	通信経路	Discovery の主体	SCP の関与
Model A	Direct（直接）	発見なし／事前設定で相手を知っている	なし
Model B	Direct（直接）	呼び出し側 NF が自分で NRF に問い合わせ	なし
Model C	Indirect（SCP 経由）	呼び出し側 NF が自分で NRF に問い合わせ、その結果を添えて SCP に依頼	ルーティングを担当（Discovery はしない）
Model D	Indirect（SCP 経由）	SCP に委譲（Delegated Discovery）。SCP が NRF に問い合わせて相手を発見	発見＋ルーティングの両方を担当

ポイントは次の2つの軸で読むことです。

A・B は Direct（SCP なし）／ C・D は Indirect（SCP あり）
A・C は呼び出し側が発見主体（または発見不要）／ D は発見を SCP に委譲

この2軸で4モデルを1枚の座標に置くと、A→B→C→D と進むにつれて SCP と NRF の関与が増えていく関係が一目で分かります。

flowchart TB
    subgraph DIRECT["経路: Direct（SCP なし）"]
        direction LR
        A["Model A
発見なし（事前設定）
NRF✗ / SCP✗"]
        B["Model B
NF が自力で NRF 発見
NRF○ / SCP✗"]
    end
    subgraph INDIRECT["経路: Indirect（SCP 経由）"]
        direction LR
        C["Model C
NF が自力発見→SCP に依頼
NRF○(NFが) / SCP○(経路)"]
        D["Model D
発見も SCP に委譲
NRF○(SCPが) / SCP○(発見+経路)"]
    end
    A -->|"発見を足す"| B
    B -->|"経路を SCP に載せる"| C
    C -->|"発見も SCP に渡す"| D

    classDef direct fill:#efe,stroke:#3a3;
    classDef indirect fill:#eef,stroke:#66a;
    class A,B direct;
    class C,D indirect;

図の読み方

上段の緑（Model A/B）は SCP を介さない Direct 通信、下段の青（Model C/D）は SCP を介する Indirect 通信です。左から右へ、A（NRF も SCP も使わず事前設定で直接）→ B（NF が自力で NRF に発見を要求し直接呼ぶ）→ C（NF が自力発見した結果を SCP に渡して経路制御を任せる）→ D（発見そのものも SCP に委譲＝Delegated Discovery）と、関与する要素が段階的に増えていくのが要点です。「経路を SCP に載せるか（縦軸）」×「発見を誰がやるか（横軸の進み方）」 の2軸で捉えると、各モデルの位置づけが整理できます。個々の通信フローは下の各モデル図を参照してください。

Model A — 直接通信・発見なし¶

呼び出し側 NF が、相手 NF のエンドポイントをあらかじめ知っている（ローカル設定等）前提で、NRF も SCP も介さずに直接 SBI 呼び出しを行う最もシンプルな形です。

flowchart LR
  NFc["NF
(Consumer)"] -->|"直接 SBI 呼び出し"| NFp["NF
(Producer)"]

Model B — 直接通信・自力 Discovery¶

呼び出し側 NF が自分で NRF に問い合わせて相手を発見し、その後は直接 SBI 呼び出しを行います。SCP は介しません。

flowchart LR
  NFc["NF
(Consumer)"] -->|"1. Discovery 要求"| NRF["NRF"]
  NRF -->|"2. 候補を返す"| NFc
  NFc -->|"3. 直接 SBI 呼び出し"| NFp["NF
(Producer)"]

Model C — 間接通信・自力 Discovery（SCP はルーティング）¶

呼び出し側 NF が自分で NRF に問い合わせて相手を発見し、発見結果を添えて SCP 経由で呼び出します。SCP は経路制御（ルーティング・負荷分散等）を担いますが、Discovery は行いません。

flowchart LR
  NFc["NF
(Consumer)"] -->|"1. Discovery 要求"| NRF["NRF"]
  NRF -->|"2. 候補を返す"| NFc
  NFc -->|"3. 発見結果を添えて依頼"| SCP["SCP"]
  SCP -->|"4. ルーティングして呼び出し"| NFp["NF
(Producer)"]

Model D — 間接通信・委譲 Discovery（SCP が発見＋ルーティング）¶

呼び出し側 NF は相手を自分で発見せず、発見そのものを SCP に委譲（Delegated Discovery）します。SCP が NRF に問い合わせて相手を発見し、ルーティングまで行います。呼び出し側 NF から見ると「SCP に頼めば適切な相手へ届く」状態です。

flowchart LR
  NFc["NF
(Consumer)"] -->|"1. SCP に依頼
(相手条件を渡す)"| SCP["SCP"]
  SCP -->|"2. Discovery 要求"| NRF["NRF"]
  NRF -->|"3. 候補を返す"| SCP
  SCP -->|"4. ルーティングして呼び出し"| NFp["NF
(Producer)"]

SCP（Service Communication Proxy）詳細¶

項目	内容
役割	NF 間の SBI 通信を仲介する間接通信の要素。経路制御・負荷分散・（Model D では）Delegated Discovery を担う
導入	Rel-16 で SBA の拡張として導入された（詳細な節番号は要確認）
関与するモデル	Model C（ルーティング）・Model D（発見＋ルーティング）
NRF との関係	Model D では SCP が NRF に対して Discovery を行う。Model C では発見は呼び出し側 NF が行う
障害時の影響	間接通信に依存する経路が影響を受ける。ただし冗長化や、直接通信（Model A/B）へのフォールバック設計で緩和されうる（構成依存・要確認）

SCP は「通す」だけではない場合がある

SCP は単なる L4/L7 プロキシではなく、SBI のセマンティクス（サービス・API 単位のルーティング等）を理解して仲介します。具体的にどの機能まで担うか（メッセージ変換・ポリシー適用等）は実装・構成に依存する部分があり、標準の必須範囲との切り分けは 要確認 です。

NRF・SCP・SEPP の役割の違い¶

混同しやすい3つを整理します。

NRF: NF の登録・発見のリポジトリ（誰がどこにいるか）。→ NRF
SCP: 同一 PLMN 内の NF 間通信の仲介（間接通信・Model C/D）。
SEPP: PLMN 間（ローミング）の SBI 境界のセキュリティ・仲介（N32）。→ SEPP

SCP は主に PLMN 内の通信最適化、SEPP は PLMN 間の境界、という住み分けです。

Summary¶

NF 間通信は Direct/Indirect と Discovery を委譲するかの2軸で Model A〜D に分類される。
A: 直接・発見なし／ B: 直接・自力発見／ C: SCP 経由・自力発見／ D: SCP 経由・委譲発見。
SCP は間接通信（C・D）を仲介する要素で、Model D では NRF への Discovery まで代行する。
NRF＝発見のリポジトリ、SCP＝PLMN 内の通信仲介、SEPP＝PLMN 間の境界、と役割が分かれる。

3GPP Specification¶

TS 23.501: SBA・通信モデル（Direct/Indirect Communication、Model A〜D）の定義（節・図番号は Release により異なるため要確認）
TS 29.500: SBI の技術的実現（SCP を介した通信の扱いを含む。詳細は要確認）
TS 29.510: NRF（Nnrf、NFManagement/NFDiscovery）

Next Step¶

NRF — 発見のリポジトリとしての詳細
SEPP — PLMN 間の SBI 境界（対比で理解）
5GC概要とSBA — SBA 全体像の復習