SCP — Service Communication Proxy and communication models A–D¶

Learning objectives¶

• Explain that the SCP (Service Communication Proxy) is the "indirect communication" element that mediates SBI communication between NFs.
• Distinguish the four patterns of inter-NF communication (Model A / B / C / D) along two axes: the presence/absence of Direct / Indirect Communication and of Delegated Discovery.
• Explain how the NRF and the SCP are involved in each model (who does the Discovery, and who does the Routing).

Prerequisites¶

• Basics of SBA (Service Based Architecture) / NF / SBI → 5GC overview and SBA
• NF Registration / Discovery by the NRF → NRF
• Protocol (HTTP/2 + JSON over TLS) → Protocol dictionary

What you'll learn in this chapter¶

First, as the Why, we confirm that "direct communication," where NFs call each other directly, alone struggles to meet operational requirements such as path control, load balancing, and observability. Next, as the What, we learn that "indirect communication" through the SCP, and whether or not Discovery is delegated to the SCP, organize communication into four patterns (Models A–D). Finally, as the How, we understand the communication flow of each model together with the involvement of the NRF and the SCP.

Why — why it's needed¶

In the SBA, each NF can use the NRF to discover a peer NF and call it directly over SBI (HTTP/2). However, in a real operational environment where NFs are numerous and scale dynamically,

• aggregation and load balancing of call paths
• commonization of retry and failover
• observability of traffic (monitoring and tracing)

are cross-cutting concerns, and having each NF implement them individually is inefficient. The idea of consolidating these into a dedicated element that mediates communication is the SCP (Service Communication Proxy). Communication that goes through the SCP is called Indirect Communication.

Analogy: Direct communication is like employees looking up each other's extension numbers and calling one another directly. Indirect communication (SCP) is like first connecting to the main line (the operator), who then transfers you to the appropriate person. Depending on whether you also entrust the operator with the job of "finding whom to connect to," or you look up the peer yourself and then ask "please connect me to this person," further patterns emerge.

Overview¶

Inter-NF communication is organized along the following two axes.

1. Communication path: Does the NF call the peer directly (Direct), or via the SCP (Indirect)?
2. Who performs Discovery: Does the calling NF query the NRF itself to discover the peer, or does it delegate that discovery to the SCP (Delegated Discovery)?

The combinations of these two axes are Model A / B / C / D.

Classification of Models A–D¶

The key is to read this along the following two axes.

• A and B are Direct (no SCP) / C and D are Indirect (with SCP)
• A and C have the caller as the discovery agent (or discovery is unnecessary) / D delegates discovery to the SCP

If you place the four models on a single coordinate along these two axes, you can see at a glance the relationship where, as you move A→B→C→D, the involvement of the SCP and the NRF increases.

flowchart TB
    subgraph DIRECT["Path: Direct (no SCP)"]
        direction LR
        A["Model A
no discovery (pre-configured)
NRF✗ / SCP✗"]
        B["Model B
NF discovers via NRF itself
NRF○ / SCP✗"]
    end
    subgraph INDIRECT["Path: Indirect (via SCP)"]
        direction LR
        C["Model C
NF discovers itself→requests SCP
NRF○(by NF) / SCP○(routing)"]
        D["Model D
discovery also delegated to SCP
NRF○(by SCP) / SCP○(discovery+routing)"]
    end
    A -->|"add discovery"| B
    B -->|"put path on SCP"| C
    C -->|"hand discovery to SCP too"| D

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

Model A — direct communication, no discovery¶

The simplest form, in which the calling NF already knows the endpoint of the peer NF (via local configuration, etc.) and performs the SBI call directly, without going through either the NRF or the SCP.

flowchart LR
  NFc["NF
(Consumer)"] -->|"direct SBI call"| NFp["NF
(Producer)"]

Model B — direct communication, self Discovery¶

The calling NF queries the NRF itself to discover the peer, and thereafter performs the SBI call directly. It does not go through the SCP.

flowchart LR
  NFc["NF
(Consumer)"] -->|"1. Discovery request"| NRF["NRF"]
  NRF -->|"2. return candidates"| NFc
  NFc -->|"3. direct SBI call"| NFp["NF
(Producer)"]

Model C — indirect communication, self Discovery (SCP does routing)¶

The calling NF queries the NRF itself to discover the peer, and calls via the SCP with the discovery result attached. The SCP handles path control (routing, load balancing, etc.) but does not do Discovery.

flowchart LR
  NFc["NF
(Consumer)"] -->|"1. Discovery request"| NRF["NRF"]
  NRF -->|"2. return candidates"| NFc
  NFc -->|"3. request with discovery result attached"| SCP["SCP"]
  SCP -->|"4. route and call"| NFp["NF
(Producer)"]

Model D — indirect communication, delegated Discovery (SCP does discovery + routing)¶

The calling NF does not discover the peer itself but delegates the discovery itself to the SCP (Delegated Discovery). The SCP queries the NRF to discover the peer and performs routing as well. From the calling NF's viewpoint, it is a state where "asking the SCP delivers to the appropriate peer."

flowchart LR
  NFc["NF
(Consumer)"] -->|"1. request the SCP
(pass peer conditions)"| SCP["SCP"]
  SCP -->|"2. Discovery request"| NRF["NRF"]
  NRF -->|"3. return candidates"| SCP
  SCP -->|"4. route and call"| NFp["NF
(Producer)"]

SCP (Service Communication Proxy) details¶

Difference in the roles of NRF, SCP, and SEPP¶

Let us organize these three that are easy to confuse.

• NRF: the repository for NF registration and discovery (who is where). → NRF
• SCP: the mediation of communication between NFs within the same PLMN (indirect communication, Model C/D).
• SEPP: the security and mediation of the SBI boundary between PLMNs (roaming) (N32). → SEPP

The division is that the SCP is mainly for communication optimization within a PLMN, and the SEPP is for the boundary between PLMNs.

Summary¶

• Inter-NF communication is classified into Models A–D along the two axes of Direct/Indirect and whether Discovery is delegated.
• A: direct, no discovery / B: direct, self discovery / C: via SCP, self discovery / D: via SCP, delegated discovery.
• The SCP is the element that mediates indirect communication (C and D); in Model D it even performs Discovery to the NRF on the caller's behalf.
• The roles are divided: NRF = the repository of discovery, SCP = communication mediation within a PLMN, SEPP = the boundary between PLMNs.

3GPP Specification¶

• TS 23.501: Definition of the SBA and communication models (Direct/Indirect Communication, Models A–D) (section and figure numbers differ by Release, so to be confirmed)
• TS 29.500: Technical realization of the SBI (including the handling of communication via the SCP; details to be confirmed)
• TS 29.510: NRF (Nnrf, NFManagement/NFDiscovery)

Next Step¶

• NRF — details as the repository of discovery
• SEPP — the SBI boundary between PLMNs (to understand by contrast)
• 5GC overview and SBA — a review of the overall SBA picture