SBI Communication Models A–D / SCP — Discovery and Routing Are Different Jobs¶

Learning objectives¶

After reading this chapter, you will be able to:

• Explain the work of calling an NF over the SBI as three separate jobs: Discovery (finding candidates) / Selection (choosing one) / Routing (the path for delivery)
• Explain the four Communication Models (A / B / C / D) along two axes: "Direct / Indirect" and "who performs Discovery" (TS 23.501 Annex E)
• Tell Model C from Model D by combining HTTP/2 headers (3gpp-sbi-target-apiroot, 3gpp-sbi-discovery-*, 3gpp-sbi-producer-id) with the communication paths toward the NRF
• Follow, header by header, the call flow for creating the SMF → PCF SM Policy Association with Model D
• Determine whether a failure via the SCP is "an error returned by the SCP" or "an error returned by the producer"

Prerequisites¶

• SCP — overview of Models A–D (this chapter digs deeper)
• NRF — NF Profiles and Nnrf_NFDiscovery
• NF Set / Binding Indication / PCF Redundancy — NF Sets, 3gpp-Sbi-Routing-Binding
• N7 SBI Analysis — how to read HTTP/2 and ProblemDetails
• Supplementary: PCF / N7 / 5GC Overview and SBA / HTTP API Dictionary / Protocol Dictionary

Why — why separate "Discovery" from "Routing"?¶

When the SMF wants to create an SM Policy Association toward a PCF, at least the following decisions are needed.

[Discovery]  "Which PCFs can provide Npcf_SMPolicyControl?"   → candidate list
      ↓
[Selection]  "This time, let's use PCF-B"                       → one chosen
      ↓
[Routing]    "SMF → PCF-B directly? Or via an SCP?"             → delivery path

In the early SBA (Rel-15), the basic form was that the consumer (SMF) itself queried the NRF (Discovery), chose by itself (Selection) and sent the request directly (Routing). Rel-16 introduced the SCP (Service Communication Proxy), adding Indirect Communication, in which routing is left to the SCP, and Delegated Discovery, in which Discovery / Selection are also left to the SCP (TS 23.501 §6.2.19 / Annex E).

As a result, the mere fact that "the request goes via an SCP" no longer tells you who searched for candidates and who decided the destination. To isolate in troubleshooting whether "the SCP is at fault, the NRF profile is wrong, the SMF configuration is wrong, or the PCF rejected," you need to look at these three jobs separately.

Analogy: Think of asking an outside expert for help. Model A is "calling the number written in your business-card file directly," Model B is "looking it up in the phone directory (NRF) and calling directly," Model C is "deciding on the person using the directory, then asking the switchboard (SCP) to 'connect me to Mr. X'," and Model D is "just telling the switchboard 'connect me to an expert who meets these conditions' and leaving both the search and the choice to the operator." Even when going via the switchboard (C and D), whether you or the operator chose the person changes where to look when trouble occurs.

What — the four Communication Models¶

Big picture (TS 23.501 Annex E)¶

The informative Annex E "Communication models for NF/NF services interaction" of TS 23.501 organizes interactions between NFs / NF services into four models (the comparison table is Table E.1-1; table number to be confirmed). Direct / Indirect Communication themselves are specified in TS 23.501 §6.3.1.0 and §7.1.1 (to be confirmed).

flowchart LR
    subgraph DIRECT["Direct Communication"]
        A["Model A
Local configuration
No NRF"]
        B["Model B
Consumer performs
NRF Discovery"]
    end
    subgraph INDIRECT["Indirect Communication (via SCP)"]
        C["Model C
Consumer performs NRF Discovery
SCP does routing"]
        D["Model D
Discovery and Selection
delegated to SCP"]
    end
    A -->|"add Discovery"| B
    B -->|"move routing to SCP"| C
    C -->|"move Discovery to SCP too"| D

Model A — Direct, no NRF¶

SMF ──────────────────────────► PCF-A
      destination apiRoot from local configuration

• The SMF has the FQDN / IP of PCF-A in its local configuration. Neither the NRF nor an SCP appears.
• This form is common in small deployments and labs. The alternative destination for when PCF-A fails must also be configured.

Model B — Direct, consumer performs NRF Discovery¶

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

• The SMF obtains candidates with GET /nnrf-disc/v1/nf-instances?target-nf-type=PCF... (TS 29.510, clause number to be confirmed), chooses by itself and sends directly.
• This is the basic form of Rel-15.

Model C — Indirect, consumer performs NRF Discovery, SCP does routing¶

SMF ── Nnrf_NFDiscovery ──► NRF
SMF ◄─ NF Profile candidates ── NRF
SMF ── SBI Request ──► SCP ──► PCF-B
       (destination specified)

• The SMF performs Discovery and Selection by itself and sends the request to the SCP with the chosen destination stated explicitly in the request.
• The 3gpp-Sbi-Target-apiRoot header is used to state the destination (see below).

Model D — Indirect, Delegated Discovery¶

SMF ── SBI Request ───────► SCP ── Nnrf_NFDiscovery ──► NRF
       + discovery conditions    ◄── NF Profile candidates ──
                                 SCP selects PCF-B
                            SCP ── SBI Request ───────► PCF-B

• The SMF does not consult the NRF. It sends the request to the SCP carrying discovery conditions meaning "deliver this to a producer that meets these conditions" in 3gpp-Sbi-Discovery-* headers (TS 29.500 §6.10.3, to be confirmed).
• The SCP performs Discovery and Selection and forwards the request to the chosen producer.

Functions of the SCP (TS 23.501 §6.2.19)¶

The functional definition of the SCP is in TS 23.501 §6.2.19. The main items are as follows (the list is a summary; completeness and wording of the original are to be confirmed).

• The SCP itself does not provide NF services the way the PCF or UDM does. It is an element that mediates communication toward other NFs' services.
• Discovery and selection of the SCP itself (which SCP a consumer uses) is covered in TS 23.501 §6.3.16 (to be confirmed); methods based on local configuration or on the NRF exist.

Analogy: The SCP is a "switchboard plus dispatch center." It not only connects calls (Routing) but, if asked, also searches for a person who meets the conditions (Discovery) and assigns one (Selection) — but it does not cook the meal itself (decide the policy).

How — telling Model C from Model D in HTTP/2¶

Before and after the SCP are separate HTTP/2 connections¶

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

Because the SCP relays at the HTTP application layer, SMF→SCP and SCP→PCF are separate TCP / TLS / HTTP/2 connections. Looking only at the packets of connection ① does not tell you whether connection ② succeeded.

A Model C request (the consumer has already chosen 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 is the destination of this hop (the SCP).
• 3gpp-sbi-target-apiroot is the apiRoot of the final destination (format {scheme}://{authority}[/{apiPrefix}]; apiPrefix is optional. The definition of apiRoot is in TS 29.501 §4.4.1, to be confirmed). The header is defined in TS 29.500 §5.2.3.2 (sub-clause to be confirmed), and how to address a request toward the SCP is in TS 29.500 §6.10.2 (to be confirmed).
• The SCP rebuilds the request URI using the apiRoot in this header and forwards the request to PCF-B (details of removing / rewriting headers are in TS 29.500 §6.10.2, to be confirmed).
• Some deployments add an apiPrefix to the SCP-side URI (e.g., /scp-prefix/npcf-smpolicycontrol/...; whether to add one depends on the deployment).

A Model D request (Discovery delegated to the 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

• The first clue is that there is no 3gpp-sbi-target-apiroot. The consumer does not yet know the destination.
• Headers of the form 3gpp-Sbi-Discovery-<parameter name> correspond to the search conditions (query parameters) of Nnrf_NFDiscovery (the header definition is in the clause for discovery headers within TS 29.500 §5.2.3.2; it is said to be §5.2.3.2.7, but the sub-clause is to be confirmed. The meaning of each parameter is in TS 29.510).
• In Nnrf_NFDiscovery, target-nf-type and requester-nf-type are mandatory query parameters (TS 29.510, clause number to be confirmed). For which 3gpp-Sbi-Discovery-* headers a consumer must always include in Delegated Discovery, and where the SCP obtains the requester's NF type, refer to TS 29.500 §6.10.3 (to be confirmed).
• The encoding of values (how arrays and JSON objects are written) is to be confirmed. The example above is a conceptual representation for explanation, not a complete request that can be sent as is.

A clue on the response side — 3gpp-Sbi-Producer-Id¶

In Model D, the SMF does not know "which PCF was chosen." Therefore the response reaches the SMF carrying 3gpp-sbi-producer-id, which indicates the chosen producer (the NF Instance ID; may include an NF Service Instance ID, etc.). Whether the producer itself or the SCP adds it, and under which conditions, refer to TS 29.500 §5.2.3.2 / §6.10.3 (both, including sub-clauses, to be confirmed).

: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

(Values are fictitious examples. The header value format is to be confirmed.)

• location contains the apiRoot of PCF-B, so from then on the SMF can treat this resource as one on PCF-B.
• For subsequent Update / Delete, the SMF sends to the SCP with 3gpp-sbi-target-apiroot (derived from Location) (TS 29.500 §6.10, to be confirmed). It may also add 3gpp-sbi-discovery-* or 3gpp-sbi-routing-binding in preparation for reselection. In other words, even when operating with Model D, the second and later requests can look the same as Model C (TS 29.500 §6.10, to be confirmed).
• If the PCF returns a Binding Indication (3gpp-sbi-binding), the SMF adds 3gpp-sbi-routing-binding to subsequent requests so that, when PCF-B is unavailable, the SCP can reselect an alternative PCF in the same NF Set (details in NF Set / Binding Indication / PCF Redundancy).

Quick reference for the determination¶

Call Flow — creating the SMF → PCF SM Policy Association with Model D¶

During PDU Session Establishment, the SMF establishes an SM Policy Association (TS 23.502 §4.16.4; Npcf_SMPolicyControl_Create is TS 29.512 §4.2.2; both to be confirmed). The flow when this Create is done with Model D is as follows.

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 has no valid cache
        SCP->>NRF: (2) GET /nnrf-disc/v1/nf-instances
target-nf-type=PCF and others
        NRF-->>SCP: (3) 200 OK SearchResult
nfInstances = PCF-A, PCF-B
    end
    SCP->>SCP: (4) Select PCF-B
considering Priority, Capacity, Load etc.
    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: Who adds producer-id and when is to be confirmed
    Note over SMF: SM Policy Association established
from then on, use the apiRoot of Location
as 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 table¶

The correspondence to follow is a single line: the SMF's discovery conditions → the NF Profiles returned by the NRF → the PCF chosen by the SCP → the PCF's response → the association (Location) retained by the SMF.

Failures via the SCP — did the SCP return it, or the producer?¶

Once an SCP is inserted, the error the SMF receives has two possible origins.

flowchart TD
    E["SMF receives an error response"] --> S{"What does the Server header say?"}
    S -- "A value indicating the SCP" --> SCPERR["Error generated by the SCP
Discovery failure / destination unreachable /
timeout / overload etc."]
    S -- "A value indicating the PCF" --> PCFERR["Error generated by the producer
The SCP only relayed it"]
    S -- "Absent / cannot tell" --> T["Decide using ProblemDetails cause
and the SCP-PCF segment trace"]
    SCPERR --> N1["Investigate SCP-NRF / SCP-PCF segments"]
    PCFERR --> N2["Investigate PCF logs and request contents"]

Analogy: Whether a delivery failure notice was "issued by the distribution center (SCP)" or "the recipient (PCF) refused delivery" changes whom you call next. Look at both the issuer field of the notice (the server header) and the delivery record (the trace of the SCP⇔PCF segment) before deciding.

Packet Analysis (Wireshark)¶

Display filters¶

Field names (http2.headers.path etc.) may differ between Wireshark versions and are to be confirmed. Right-clicking a header in the GUI and choosing "Apply as Filter" is the reliable approach.

Decode example (conceptual)¶

The following is a conceptual representation of the display structure, with fictitious values (capture required).

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", ...}

The Content-Type of ProblemDetails is application/problem+json (RFC 9457, formerly RFC 7807; TS 29.500 §5.2.7, to be confirmed).

Order of checks¶

flowchart LR
    A["① SMF-SCP
authority, path
target-apiroot or
discovery-*"] --> B["② SCP-NRF
Discovery
query and SearchResult"]
    B --> C["③ SCP-PCF
connection and request
authority=PCF"]
    C --> D["④ PCF response
201 / 4xx / 5xx
Location"]
    D --> E["⑤ SCP-SMF
producer-id
server header"]

SMF → SCP: HTTP/2 connection OK
       ≠
SCP → PCF: HTTP/2 connection OK
       ≠
PCF: SM Policy Association created OK

Trouble Shooting¶

Common misconceptions¶

Boundary between 3GPP specifications and vendor implementations¶

Comparison with EPC (4G)¶

Diameter-based interfaces in the EPC also had agents that relay messages (Relay / Proxy / Redirect Agents, RFC 6733 §2.8) and the DRA (Diameter Routing Agent) for PCRF selection (TS 29.213 §7, to be confirmed). The idea is similar, but they are not the same thing.

The right and left columns are correspondences by analogy, not correspondences defined by the specifications.

3GPP Specification¶

Summary¶

• The work of calling an NF over the SBI splits into three jobs: Discovery / Selection / Routing
• Model A: Direct, no NRF / B: Direct, consumer performs NRF Discovery / C: via SCP, consumer performs NRF Discovery / D: via SCP, Discovery and Selection delegated to the SCP
• Even in Model C, when only an NF Set is specified, the SCP selects the instance. Discovery and Selection are different things
• If the first request has 3gpp-sbi-target-apiroot, the consumer decided the destination (C type); if it lacks it and has 3gpp-sbi-discovery-*, discovery was delegated (D type). However, do not decide from a single header; also check whether consumer→NRF traffic exists
• In Model D, the chosen producer is identified by 3gpp-sbi-producer-id in the response (who adds it is to be confirmed), and afterwards requests are sent with a target-apiroot derived from Location
• Before and after the SCP are separate HTTP/2 connections. Use the server header, the cause, and the trace of the SCP⇔PCF segment to separate SCP-originated errors from producer-originated ones
• The SCP's routing policy, caching, retries, and service-mesh implementation are vendor implementation dependent

Comprehension check¶

Next Step¶

• SCP basics and where Models A–D fit → SCP
• Basics of NF Profiles and Discovery → NRF
• NF Set / Binding, which supports reselection via the SCP → NF Set / Binding Indication / PCF Redundancy / BSF / PCF Binding / BSF
• How to read HTTP/2 and ProblemDetails on N7 → N7 SBI Analysis / N7 / PCF
• SBI relaying between PLMNs (in contrast to the SCP) → SEPP / N32
• Look up SBI APIs and protocols → HTTP API Dictionary / Protocol Dictionary / Spec Dictionary
• How to capture traces and read specifications → Packet Analysis Tips / Spec Reading Tips