BSF / PCF Binding — Finding "the PCF of this Session" Among Multiple PCFs¶

Learning objectives¶

After reading this chapter, you will be able to:

• Explain that the BSF is not "an NF that decides policy" but an NF that helps consumers reach a PCF that has already been selected
• Explain the difference between the NRF (discovering candidate PCFs that are available) and the BSF (discovering the PCF that serves this PDU Session)
• Explain the information contained in a PcfBinding (UE IP / IPv6 prefix, DNN, S-NSSAI, SUPI / GPSI, PCF FQDN / IP endpoint / Instance ID / Set ID, Binding Level)
• Explain the Nbsf_Management Register / Deregister / Discovery / Update / Subscribe operations and how they look on HTTP
• Understand the difference between 200 OK and 204 No Content in Discovery, and isolate BSF-related failures in a trace

Prerequisites¶

• PCF / SM Policy Association / PCC Rule — the SM Policy Association between the SMF and the PCF
• AF / N5 / Application Session — Npcf_PolicyAuthorization, with which the AF requests QoS etc. from the PCF
• NEF / N33 / Event Exposure — how the NEF bridges external AF requests into the 5GC
• Supplementary: BSF / PCF / NRF / N5 / Policy

Why — why do we need a mechanism to find "the PCF of this Session"?¶

In commercial networks, PCFs are normally deployed in multiples for redundancy and load balancing. At PDU Session establishment, the SMF selects one PCF using the NRF or other means and creates an SM Policy Association (PCF Discovery and Selection is TS 23.501 §6.3.7.1, to be confirmed; the related clause on the TS 23.503 side is also to be confirmed).

The problem comes later. When the application side (AF) or the NEF requests "raise the QoS of the traffic for UE IP 10.1.1.10," the request is meaningless unless it reaches the PCF that holds the SM Policy Association of that PDU Session.

           SMF ──── N7 ──── PCF-B   ← holds the SM Policy Association of this Session
            │
       PDU Session
       UE IP = 10.1.1.10

External AF ─N33→ NEF ─→ PCF-A ?   ← if it reaches another PCF, that PCF does not know the Session
                     └─→ PCF-B ✓   ← if it reaches the right PCF, the PCC Rules can be updated

The AF / NEF does not know which PCF the SMF selected. Asking the NRF returns "PCFs available as candidates," not "the PCF serving this Session." So an NF is needed that holds, and makes searchable, the mapping between a PDU Session (UE address etc.) and its serving PCF. That is the BSF (Binding Support Function) (TS 23.503 §6.1.1.2).

Analogy: The NRF is "the hospital's directory of doctors": it tells you which doctors work in which department, but not "who is Mr. A's attending physician." The BSF is "the reception desk's patient-record ledger," which records the attending physician (PCF) for each patient (PDU Session). An outside inquiry (AF request) must be routed by looking up the patient-record ledger, not the directory; otherwise it reaches a doctor who knows nothing about the case.

What — where the BSF and PCF Binding fit¶

Roles of the NRF / BSF / PCF¶

The NRF and the BSF are not alternatives; they are often used in two stages.

flowchart LR
    NEF["NEF / AF"] -- "① Nnrf_NFDiscovery
target-nf-type=BSF" --> NRF["NRF"]
    NRF -- "Candidate BSFs
(BsfInfo: IPv4 ranges / DNN etc.)" --> NEF
    NEF -- "② Nbsf_Management_Discovery
UE IP / DNN / S-NSSAI" --> BSF["BSF"]
    BSF -- "PcfBinding
(PCF FQDN / Endpoint / Instance ID / Set ID)" --> NEF
    NEF -- "③ Npcf_PolicyAuthorization" --> PCF["PCF-B
(serving PCF)"]

The BSF can register with the NRF as NF Type BSF and advertise, in the BsfInfo of its NF Profile, the UE IPv4 address ranges, IPv6 prefix ranges, DNNs, IP domains etc. that it serves (TS 29.510; the clause defining BsfInfo is to be confirmed). In networks with multiple BSFs, a consumer first asks the NRF for "the BSF serving this UE address" and then queries that BSF for the binding. Some deployments do not use the NRF and fix the BSF by local configuration (implementation/deployment dependent).

Deployment options for the BSF¶

TS 23.503 §6.1.1.2 allows the BSF to be deployed as a standalone NF or co-located with other NFs (PCF, UDR, NRF, SMF etc.) (the exact list and sub-clause numbering are to be confirmed). Note that TS 23.501 §6.2 (functional descriptions of Network Functions) has no dedicated clause for the BSF; the role of the BSF is described in TS 23.503 (see the note in the NF Dictionary).

In addition, the BSF may exhibit the following "routing-oriented" behaviors.

PcfBinding — what is written in the ledger¶

The binding information held by the BSF is represented by the PcfBinding data type of TS 29.521 (TS 29.521 §5.6.2.2; clause number to be confirmed). The representative attributes, grouped by role:

This is an excerpt of the main attributes, not an exhaustive list. Check the mandatory / optional / conditional classification of each attribute and the attributes added per Release in the relevant version of TS 29.521.

UE IPv4: 10.1.1.10
  ├─ DNN=internet,   S-NSSAI=SST1/SD 010203 → PCF-B
  └─ DNN=enterprise, S-NSSAI=SST1/SD 0A0B0C → PCF-C

How — registering, discovering and using the binding¶

Nbsf_Management service operations¶

Update was added in Rel-16 and Subscribe / Notify in Rel-17; their use involves Supported Features negotiation (Releases and feature names to be confirmed).

How it looks on HTTP (PDU Session binding)¶

Let {apiRoot}/nbsf-management/v1 be the root of the API (TS 29.521 §5.1 / §5.3; clause numbers to be confirmed).

The PCF remembers the bindingId (Location header) returned by Register and uses it for Update / Deregister. Discovery is a query on the collection rather than on an individual resource, so the consumer can search without knowing the bindingId.

Call Flow — register → discover → apply policy¶

The following is the conceptual order for the case where, after the PDU Session is established and PCF-B is selected, an external AF requests QoS via the NEF. The actual timing and additional messages differ by scenario and Release.

sequenceDiagram
    participant SMF
    participant PCFB as PCF-B
    participant BSF
    participant NRF
    participant NEF
    participant AF
    participant UPF
    SMF->>PCFB: Npcf_SMPolicyControl_Create
(SUPI, DNN, S-NSSAI, UE IPv4)
    PCFB-->>SMF: 201 Created (SM Policy Decision)
    PCFB->>BSF: Nbsf_Management_Register
POST /pcfBindings (PcfBinding)
    BSF-->>PCFB: 201 Created
Location: .../pcfBindings/{bindingId}
    Note over SMF,UPF: Some time later, a QoS request from the application side
    AF->>NEF: N33 AF Session with QoS request
(UE IPv4, requested QoS)
    NEF->>NRF: Nnrf_NFDiscovery (target-nf-type=BSF)
    NRF-->>NEF: Candidate BSFs (NF Profile / BsfInfo)
    NEF->>BSF: Nbsf_Management_Discovery
GET /pcfBindings?ipv4Addr=...&dnn=...&snssai=...
    BSF-->>NEF: 200 OK (PcfBinding: PCF-B FQDN / Endpoint)
    NEF->>PCFB: Npcf_PolicyAuthorization_Create
    PCFB-->>NEF: 201 Created
    PCFB->>SMF: Npcf_SMPolicyControl_UpdateNotify
(PCC Rule update)
    SMF->>UPF: PFCP Session Modification Request
    UPF-->>SMF: PFCP Session Modification Response
    Note over PCFB,BSF: At PDU Session Release
    PCFB->>BSF: Nbsf_Management_Deregister
DELETE /pcfBindings/{bindingId}
    BSF-->>PCFB: 204 No Content

The key point of the figure is that the PCF registers the binding and the NEF / AF (or the SCP) looks it up. The SMF does not register with the BSF. A trusted AF can find the serving PCF without going through the NEF and send the request directly over N5 (N5). It can find it by Discovery towards the BSF, via the SCP, through the BSF acting as Diameter proxy / redirect for an AF using Rx, or by local configuration; which one is used is deployment dependent. For details of the request flow via the NEF, see NEF / N33.

When does the PCF register, update and delete?¶

Summarizing the approach of TS 23.503 §6.1.1.2 (sub-clause numbering to be confirmed):

Signal Flow¶

Packet Analysis (Wireshark)¶

Display Filter¶

The names and types of HTTP/2 header fields (http2.headers.path / http2.headers.status etc.) vary between Wireshark versions, so they are not stated definitively here (to be confirmed). SBI is normally protected by TLS, so seeing the contents requires decryption using a TLS key log or NF-side traces / logs (Packet Analysis Tips).

Decode example (conceptual representation)¶

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

[PCF-B → BSF] HEADERS
  :method: POST
  :path: /nbsf-management/v1/pcfBindings
  content-type: application/json
[PCF-B → BSF] DATA  (JSON: PcfBinding)
  {
    "supi": "imsi-001010000000001",
    "ipv4Addr": "10.1.1.10",
    "dnn": "internet",
    "snssai": { "sst": 1, "sd": "010203" },
    "pcfFqdn": "pcf-b.example.invalid",
    "pcfIpEndPoints": [ { "ipv4Address": "192.0.2.20", "port": 443 } ],
    "pcfId": "6f1c2c1e-....",
    "pcfSetId": "set1.pcfset.5gc.mnc001.mcc001",
    "bindLevel": "NF_SET"
  }
[BSF → PCF-B] HEADERS
  :status: 201
  location: https://bsf.example.invalid/nbsf-management/v1/pcfBindings/abc123

[NEF → BSF] HEADERS
  :method: GET
  :path: /nbsf-management/v1/pcfBindings?ipv4Addr=10.1.1.10&dnn=internet&snssai=...
[BSF → NEF] HEADERS
  :status: 200            ← match found. PcfBinding in DATA
  (or :status: 204        ← no match. No DATA)
  (or :status: 400        ← ProblemDetails in DATA, cause = MULTIPLE_BINDING_INFO_FOUND)

Object-type query parameters such as snssai appear in :path as encoded JSON. The encoded display is hard to read, so decode the values and compare them side by side with the expected DNN / S-NSSAI.

Order of inspection¶

flowchart TD
    A["① SMF → PCF
Npcf_SMPolicyControl_Create
which PCF was selected"] --> B["② PCF → BSF
POST /pcfBindings
registered content (UE IP / DNN / S-NSSAI)"]
    B --> C["③ BSF → PCF
201 Created / Location / bindingId"]
    C --> D["④ NEF・AF → BSF
GET /pcfBindings
query conditions"]
    D --> E["⑤ BSF → NEF・AF
200 + PcfBinding / 204 / 4xx"]
    E --> F["⑥ NEF・AF → PCF
Npcf_PolicyAuthorization
does the destination match the PCF in ①"]
    F --> G["⑦ PCF → SMF → UPF
UpdateNotify / PFCP Modification"]

The trick is to cross-check whether the PCF selected by the SMF in ①, the PCF returned by the BSF in ⑤, and the PCF the request actually reached in ⑥ are the same. On HTTP/2, look at :method, :path, :status, the stream ID, the JSON body, and the cause of ProblemDetails (for how to read ProblemDetails, see N7 SBI Analysis).

Trouble Shooting¶

Boundary between 3GPP specifications and vendor implementations¶

For BSF-related failures, separate "whether the binding was registered and looked up as specified (3GPP signaling)" from "data synchronization or caching problems inside the BSF product (implementation)." The former can be verified with traces; the latter belongs to product logs and vendor support.

Comparison with EPC (4G)¶

The 4G DRA was a routing element that "relays messages while steering them to the same PCRF," whereas the 5G BSF is basically organized as a lookup service that "tells you the serving PCF." However, combined with indirect communication via the SCP or with Diameter proxy behavior, it can look similar to a DRA.

3GPP Specification¶

Summary¶

• The BSF holds the mapping (PcfBinding) between a PDU Session (UE address, DNN, S-NSSAI etc.) and its serving PCF and makes it searchable. It does not decide policy
• The NRF answers "candidate PCFs (or BSFs) that are available"; the BSF answers "the PCF currently serving this Session." They are often used in two stages
• The PCF registers, updates and deletes bindings; the NEF / AF / SCP looks them up. Nbsf_Management offers Register / Deregister / Discovery / Update (+ Subscribe / Notify from Rel-17)
• A Discovery 204 No Content is a normal response meaning "no matching binding." 400 MULTIPLE_BINDING_INFO_FOUND indicates the conditions are ambiguous and no unique binding can be determined
• A PcfBinding carries the PCF's destination (FQDN / endpoint) and identity (Instance ID / Set ID / Binding Level), which affect reachability when PCFs are made redundant
• In failure analysis, cross-check in the trace whether the PCF selected by the SMF = the PCF returned by the BSF = the PCF the request reached

Comprehension check¶

Next Step¶

• The relation between PCF redundancy and Binding Level / Binding Indication → NF Set / Binding Indication / PCF Redundancy
• Indirect communication in which the SCP uses the BSF to forward to the serving PCF → SBI Communication Model A–D / SCP
• NFs that look up the BSF → NEF / N33 / Event Exposure / AF / N5 / Application Session
• Related NFs / interfaces → BSF / PCF / NRF / SCP / N5 / Policy