NF Set / Binding Indication / SCP Routing — Preserving Policy Continuity When a PCF Fails¶

Learning objectives¶

After reading this chapter, you will be able to:

• Explain the differences between NF Instance / NF Set / NF Service Instance / NF Service Set (TS 23.501 §5.21.3)
• Explain that the Binding Level expresses "to which scope subsequent requests are bound, and within which scope reselection is allowed on failure"
• Explain the difference between the PCF Binding in the BSF (Nbsf_Management) and the SBI Binding Indication (3gpp-Sbi-Binding / 3gpp-Sbi-Routing-Binding)
• Isolate PCF failover in three stages: ① discovery and routing, ② context continuity, ③ binding consistency
• Read the binding-related headers, Location and 3gpp-Sbi-Target-apiRoot in Wireshark and trace "where a request went and who processed it"

Prerequisites¶

• BSF / PCF Binding — how the BSF manages "the PCF in charge of this PDU Session"
• SCP — Direct / Indirect Communication and Models A–D
• NRF — NF Profile registration and Discovery
• Supplementary: PCF / BSF / UDSF (one possible store for shared context) / GUAMI / AMF Region / Set / Pointer (contrast with the AMF Set) / Policy

Why — why "just send it to another PCF" is not enough¶

Consider the following PDU Session.

UE ── AMF ── SMF ── N7 ── PCF-A
                 │          │
                 │          └─ Context of the SM Policy Association
                 └─ UPF

AF ── NEF ── BSF ──────────> PCF-A (binding target)

After PCF-A fails, even if PCF-B of the same type is running, PCF-B cannot necessarily handle the context of that session. Only when PCF-A and PCF-B belong to the same NF Set and share context can PCF-B continue processing the existing SM Policy Association or AF session.

There are three broad conditions:

1. Discovery and routing — an alternative PCF can be found and the request can be resent within the scope the specification allows
2. Context continuity — the alternative PCF can use the context of the existing Policy Association, etc.
3. Binding consistency — the binding in the BSF, the SBI Binding Indication and the PCF instance that actually processed the request do not contradict one another

Analogy: A PCF Set is "a team of counters sharing the same customer ledger." Even if the counter in charge (PCF-A) suddenly closes, another counter on the same team (PCF-B) can look at the shared ledger (context) and continue. But if you are sent to a counter at a different branch (a different set, or a PCF that does not share the ledger), you will be told "I know nothing about that case." And if the ticket (binding) says "counter A only," the usher (SCP) must not send you to another counter at will.

What — the building blocks of NF Set and binding¶

NF Instance / NF Set / NF Service Instance / NF Service Set¶

TS 23.501 §5.21.3 handles NF reliability in units of NF Set and NF Service Set (the NF Set concept was generalized in the Rel-16 SBA enhancements, to be confirmed; the AMF Set has existed since Rel-15). The definitions of each term are in TS 23.501 §3.1 (Definitions) (to be confirmed); §5.21.3 is the functional description.

                    PCF Set X (NF Set)
   ┌────────────────────────────────────────────────┐
   │ PCF-A (NF Instance)      PCF-B (NF Instance)    │
   │  ├─ NF Service Set S1      ├─ NF Service Set S1'│
   │  │   ├─ SMPolicyControl #1 │   └─ ...           │
   │  │   └─ SMPolicyControl #2 │                    │
   │  └─ PolicyAuthorization #1 └─ ...               │
   └────────────────────────────────────────────────┘
                         │
            Shared context (UDSF or an implementation-specific DB)

NF Set ID notation¶

TS 23.003 §28.12 defines the NF Set ID as a globally unique string of the following form (NF Service Set ID in §28.13, to be confirmed).

set<Set ID>.<nftype>set.5gc.mnc<MNC>.mcc<MCC>
Example (test PLMN 001-01, PCF): set1.pcfset.5gc.mnc001.mcc001

Only the AMF Set uses a special form, set<AMF Set ID>.region<AMF Region ID>.amfset.5gc.mnc<MNC>.mcc<MCC>, which corresponds to the AMF Region / AMF Set of the GUAMI (see GUAMI). The AMF Set is a kind of NF Set, and the basic ideas in this chapter apply to the AMF as well. However, the AMF has its own specific handling such as the GUAMI, the Backup AMF (backupamfinst) and the planned removal procedure (TS 23.501 §5.21.2 / GUAMI).

How it looks in the NRF¶

Each NF instance publishes the NF Set(s) it belongs to (nfSetIdList) and, per NF service, the NF Service Set(s) (nfServiceSetIdList) in the NF Profile it registers with the NRF (NFProfile / NFService types of TS 29.510; attribute names and clause numbers to be confirmed). Consumers and the SCP search the NRF for "PCFs belonging to this NF Set" to obtain alternative candidates (query parameter target-nf-set-id, to be confirmed).

Binding Level — to "which scope" subsequent requests are bound¶

TS 23.501 §6.3.1.0 (Principles for Binding, Selection and Reselection) describes binding as a mechanism that indicates "to which NF producer instance(s) subsequent requests concerning a specific NF producer resource (context) should be sent," and defines the following four Binding Levels.

The table is a conceptual summary of the table in TS 23.501 §6.3.1.0 (Binding, selection and reselection). The exact conditions in each cell are to be confirmed against the original text.

The BSF's PCF Binding and the SBI Binding Indication are different things¶

The names are similar, but the owner, format and users are completely different.

The BSF's PCF Binding can also contain the PCF Set ID and the Binding Level (NF Instance / NF Set) (PcfBinding type of TS 29.521, pcfId / pcfSetId / bindLevel; attribute names to be confirmed). Note that the Binding Levels handled in the BSF's PCF Binding are NF Instance and NF Set, a different scope from the NF Service Instance / NF Service Set levels defined for the SBI in general (TS 23.503 §6.1.1.2.2, to be confirmed).

Two headers — 3gpp-Sbi-Binding and 3gpp-Sbi-Routing-Binding¶

PCF ── 201 Created + 3gpp-Sbi-Binding (optional) ──> Consumer (NEF / SMF)
                                                    │ stores the binding
                                                    ▼ subsequent request
Consumer ── 3gpp-Sbi-Routing-Binding ──> SCP ──> PCF (an instance within the binding scope)

Main parameters (ABNF in TS 29.500 §5.2.3.2.6)¶

The above is an excerpt of the main parameters; parameters have been added across Releases (not exhaustive).

Reading the header (schematic examples)¶

The following are schematic examples showing how to read the header; the IDs are illustrative. They do not mean that this header is mandatory in every request.

:method: POST
:path: /npcf-policyauthorization/v1/app-sessions
3gpp-Sbi-Routing-Binding: bl=nfset; nfset=set1.pcfset.5gc.mnc001.mcc001

• bl=nfset: the Binding Level is NF Set (spelling to be confirmed)
• nfset=...: the target NF Set ID
• :path: the API resource being invoked

A schematic example at NF Instance Level:

3gpp-Sbi-Routing-Binding: bl=nfinstance; nfinst=54804518-4191-46b3-955c-ac631f953ed8; nfset=set1.pcfset.5gc.mnc001.mcc001

nfinst identifies a specific NF instance. Even if nfset is also present, bl=nfinstance is not treated as bl=nfset (see the warning above).

How — behavior on PCF failure¶

Call Flow (via the SCP, conceptual)¶

sequenceDiagram
    participant SMF
    participant NEF
    participant BSF
    participant SCP
    participant PCFA as PCF-A
    participant PCFB as PCF-B
    SMF->>SCP: Npcf_SMPolicyControl_Create
    SCP->>PCFA: Forward (selects an instance in the PCF Set)
    PCFA-->>SMF: 201 Created + Location + 3gpp-Sbi-Binding (optional, via SCP)
    PCFA->>BSF: Nbsf_Management_Register (pcfId, pcfSetId, bindLevel)
    NEF->>BSF: Nbsf_Management_Discovery (UE IP, DNN, S-NSSAI)
    BSF-->>NEF: 200 OK (PCF Binding)
    NEF->>SCP: Npcf_PolicyAuthorization_Create + 3gpp-Sbi-Routing-Binding
    SCP-xPCFA: Forwarding fails (PCF-A failure)
    Note over SCP: Reselects an alternative in the same PCF Set
within the scope the Binding Level allows
    SCP->>PCFB: Forward
    Note over PCFB: Looks up the SM Policy Association
from the shared context
    PCFB-->>NEF: 201 Created + Location + 3gpp-Sbi-Binding (optional, via SCP)
    PCFB->>SMF: Npcf_SMPolicyControl_UpdateNotify (PCC Rule update)
    opt When required
        PCFB->>BSF: Nbsf_Management_Update (reflect the new instance)
    end

This is a conceptual diagram for understanding. The actual reselection conditions, error responses, retry counts and how context is taken over depend on the procedures in the specifications and on the implementation and configuration. Going through the SCP does not automatically recover from every failure.

Signal Flow¶

What happens to the resource URI after reselection¶

A producer's resource URI has the form {apiRoot}/{apiName}/{apiVersion}/{resource} (TS 29.501 §4.4.1, to be confirmed). For reselection within an NF Set, the approach is to replace the apiRoot part with that of the alternative instance and keep the rest of the path when sending subsequent requests (TS 29.500 §6.12; sub-clause and conditions to be confirmed). If the alternative instance has taken over the resource, the updated target may be returned in the response's Location or in a new 3gpp-Sbi-Binding, and the consumer is expected to use that value from then on (consumer-side rules to be confirmed in TS 29.500 §6.12).

Old: https://pcf-a.example/npcf-policyauthorization/v1/app-sessions/as-123
New: https://pcf-b.example/npcf-policyauthorization/v1/app-sessions/as-123
     └ only the apiRoot changes ┘└─────────── same path ──────────────┘

At this point, even with the same path, processing fails if PCF-B cannot retrieve the context (as-123). This is why "switching routing" and "continuing the context" are separate problems.

Thinking about PCF failover in three stages¶

flowchart TD
    F["PCF-A failure"] --> A1
    subgraph SA["Stage A: discovery and routing (specified by 3GPP)"]
        A1["Check Binding Level and indicated scopes"] --> A2["Check instances of the same PCF Set in the NRF
NF Status / Service / Endpoint"]
        A2 --> A3["Consumer or SCP reselects
within the permitted scope"]
    end
    A3 --> B1
    subgraph SB["Stage B: context continuity (mainly implementation-dependent)"]
        B1["Can the alternative PCF access the SM Policy Association
AF session / PCC Rules"]
    end
    B1 --> C1
    subgraph SC["Stage C: binding consistency"]
        C1["PCF Binding in the BSF"] --- C2["SBI Binding Indication"]
        C2 --- C3["PCF instance that actually processed it"]
    end

Stage A: can the route be switched?

PCF-A failure
   ↓
Check the Binding Level (NF Set Level, or NF Instance Level + NF Set indicated)
   ↓
Check the NF Profile in the NRF (nfSetIdList / Status / Service / Endpoint)
   ↓
Consumer (Direct) or SCP (Indirect) reselects within the permitted scope

Stage B: can the alternative PCF handle the context?

PCF-B
 ├─ Can it access the context of the SM Policy Association?
 ├─ Can it keep the association between the AF session and the PCC Rules?
 └─ Is context sharing (UDSF / implementation-specific DB) or synchronization complete?

The very definition of an NF Set presupposes that its members "can access the same context data" (TS 23.501 §5.21.3). Some configurations use UDSF (storage of unstructured data) as the place to keep the context, but the concrete sharing, replication and recovery methods are vendor implementation-dependent.

Stage C: is the binding consistent?

PCF Binding in the BSF
       ↕
SBI Binding Indication (value stored by the consumer / Routing-Binding)
       ↕
PCF instance that actually processed the request (3gpp-Sbi-Producer-Id / Location)

There are scenarios in which the BSF binding must be updated with Nbsf_Management_Update when a new PCF instance is selected (TS 23.503 §6.1.1.2.2; applicability conditions to be confirmed). If the binding is registered in the BSF at NF Set level, a change of instance within the set is less likely to contradict the BSF entry; if it is registered at NF Instance level, the entry may keep pointing to the old instance.

The Direct Communication case¶

In Direct Communication without the SCP (Models A / B), the consumer itself may reselect using the Binding Indication and the NF Set information obtained from the NRF. In Indirect Communication (Models C / D), the SCP can reselect based on the 3gpp-Sbi-Routing-Binding etc. added by the consumer. In either case, the Binding Level (and the scopes indicated with it) is the basis for the judgment (TS 23.501 §6.3.1.0). The overall communication models are covered in SBI Communication Model A–D.

Packet Analysis (Wireshark)¶

Display Filter¶

Field names (http2.header.name / http2.headers.path, etc.) may differ between Wireshark versions (to be confirmed). In HTTP/2, header names are carried in lowercase (RFC 9113 §8.2.1).

Decode example (conceptual)¶

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

HyperText Transfer Protocol 2
 └─ Stream: HEADERS, Stream ID: 7
     ├─ :method: POST
     ├─ :scheme: https
     ├─ :authority: scp.example:443
     ├─ :path: /npcf-policyauthorization/v1/app-sessions
     ├─ 3gpp-sbi-target-apiroot: https://pcf-a.example:443
     └─ 3gpp-sbi-routing-binding: bl=nfset; nfset=set1.pcfset.5gc.mnc001.mcc001

HyperText Transfer Protocol 2
 └─ Stream: HEADERS, Stream ID: 7
     ├─ :status: 201
     ├─ location: https://pcf-b.example:443/npcf-policyauthorization/v1/app-sessions/as-123
     ├─ 3gpp-sbi-binding: bl=nfset; nfset=set1.pcfset.5gc.mnc001.mcc001
     └─ 3gpp-sbi-producer-id: <NF Instance ID of PCF-B>

In this example, the consumer sent the request toward PCF-A (Target-apiRoot), but the response's Location and Producer-Id point to PCF-B. This is the typical reading that indicates the SCP reselected within the NF Set (whether the SCP or the producer adds Producer-Id, and its inclusion conditions, are to be confirmed).

Order of inspection¶

flowchart LR
    A["① BSF Discovery response
pcfId / pcfSetId / bindLevel"] --> B["② Subsequent request headers
Routing-Binding / Target-apiRoot"]
    B --> C["③ Where the SCP forwarded
capture of the SCP⇔PCF leg"]
    C --> D["④ Response
status / Location / Binding / Producer-Id"]
    D --> E["⑤ Downstream processing
UpdateNotify / PFCP"]

• Match requests and responses by Stream ID (Stream IDs are per HTTP/2 connection, so the consumer⇔SCP leg and the SCP⇔PCF leg have different IDs).
• If TLS is used, rely on decryptable traces (key logs, etc.) or each NF's SBI logs. Do not conclude that a header was not sent just because it is not visible in the capture.
• For reading HTTP/2 / ProblemDetails, see N7 SBI Analysis; for general tips, see Packet Analysis Tips.

Trouble Shooting¶

Case 1: PCF-A is down and PCF-B is healthy, yet requests fail¶

Order of investigation:

1. Check the PCF Instance ID / PCF Set ID / Binding Level in the BSF Discovery response
2. Check 3gpp-Sbi-Routing-Binding in subsequent requests (bl and the indicated scopes)
3. Check that PCF-B is registered in the NRF with the same NF Set ID and offers the required NF services
4. Check whether the SCP (or the consumer, in Direct mode) reselected PCF-B within the scope the specification permits
5. Check whether PCF-B has, or can access, the relevant context

Case 2: the BSF returns PCF-B, but requests go to PCF-A¶

Compare three things: the BSF response, the subsequent request headers and the SCP's actual forwarding destination. After PolicyAuthorization Create, the NEF/AF sends subsequent requests using the resource URI and Binding Indication it stored at creation, so it does not necessarily consult the latest BSF value every time. In an ongoing service session, the Binding Indication received from the producer may take precedence (TS 23.501 §6.3.1.0; applicability conditions to be confirmed). It is important not to conclude misrouting by looking only at the BSF value.

Case 3: HTTP/2 succeeded, but the policy is not applied¶

NEF → SCP → PCF-B   HTTP 201/204 success
                    │
                    ├─ Did PCF-B associate it with the correct Policy Association context?
                    ├─ Was UpdateNotify from PCF-B to the SMF sent? Is the target SMF correct?
                    └─ Did the PFCP Session Modification from SMF to UPF succeed?

HTTP success and end-to-end policy success are different things. If the SMF is also made redundant with an NF Set, notifications from the PCF are delivered according to the binding indicated by the SMF (step 1). For the PFCP side, see PFCP Rules.

By symptom¶

Boundary between 3GPP specifications and vendor implementations¶

Comparison with EPC (4G)¶

In 4G, much of PCRF redundancy was left to vendor-specific cluster designs, whereas in 5G the principles of NF Set, Binding Level and reselection via the SCP are specified by 3GPP — a major difference (although the context sharing method remains implementation-dependent).

3GPP Specification¶

Summary¶

• An NF Instance is an individual NF entity; an NF Set is a group of interchangeable NF instances that can access the same context. An NF Service Set is a group of service instances within one NF instance
• The Binding Level is the scope to which subsequent requests are bound, and is the starting point for judging the permitted scope of reselection on failure. NF Instance Level + NF Set indicated means the indicated instance normally, and reselection within the set only when it is unavailable
• The BSF's PCF Binding is mainly the ledger used to "first find the PCF in charge"; the SBI Binding Indication (3gpp-Sbi-Binding / 3gpp-Sbi-Routing-Binding) is the header that says "where to carry subsequent requests". A producer's inclusion of 3gpp-Sbi-Binding is optional
• The SCP can reselect in Indirect Communication based on Routing-Binding, but that alone does not recover from every failure
• On PCF failure, isolate in three stages: ① discovery and routing, ② context continuity, ③ binding consistency. Switching routing and continuing the policy context are separate problems

Check your understanding¶

Next Step¶

• Compare the communication models that use the SCP with packet captures → SBI Communication Model A–D / SCP / SCP
• Details of the ledger used to find the PCF in charge → BSF / PCF Binding / BSF
• Basics of the PCF and Policy Associations → PCF / SM Policy Association / PCC Rule / PCF
• Reading SBI HTTP/2 and ProblemDetails → N7 SBI Analysis
• Requests from the AF / NEF side → AF / N5 / Application Session / NEF / N33 / Event Exposure
• Contrast with the AMF Set → GUAMI / AMF Region / Set / Pointer
• Where shared context is stored → UDSF / NRF