BSF — Binding Support Function¶
Learning objectives¶
After reading this page, you will be able to:
- Explain the role of the BSF (the correspondence between a given PDU session and its responsible PCF = PCF binding) in one sentence.
- Explain why the BSF is needed in a multi-PCF environment (the problem that, with multiple PCFs, the responsible one is not determined).
- Explain why the SMF side (SMPolicy) and the AF/NEF side (AF session) must converge on the same PCF.
- Explain where the BSF is positioned within the PCC (Policy and Charging Control) framework.
Prerequisites¶
It goes more smoothly if you understand the following first.
- The role of the PCF and the basics of PCC (policy and charging control) → PCF
- The basics of SBA (Service Based Architecture) and SBI → Curriculum
- The positioning of each interface → Interface dictionary
What you will learn in this chapter¶
We first enter from the Why (what goes wrong in a multi-PCF environment without a BSF), then organize the What (binding information, role, provided API = Nbsf_Management) with tables and a Mermaid diagram, and finally move to the How (appearance in procedures, EPC comparison, reference specs).
Why — Why it is needed¶
In an environment where multiple PCFs are deployed, the PCF that handles the policy for a given PDU session must be settled to exactly one. However, there are multiple elements involved in that session. One is the SMPolicy (SM Policy Association) established via the SMF; the other is the AF session (QoS requests from applications, etc.) coming in via the AF/NEF.
If the SMF side and the AF/NEF side look up the PCF for the same session separately, they may happen to connect to different PCFs, and the policy for the same session becomes split across two PCFs, causing contradictions. To prevent this, a common roster is needed that says "which PCF is responsible for this session (this UE IP/DNN/S-NSSAI)." The BSF (Binding Support Function) is what manages this roster.
Analogy: The BSF is an assignment ledger that records the assignment of the person in charge (PCF). Without the ledger, multiple front desks (the SMF side and the AF/NEF side) would connect the same case to different persons in charge, and their instructions would conflict. By keeping a single ledger that everyone consults to align on the person in charge, discrepancies are prevented.
Overview¶
The BSF (Binding Support Function) is an NF that manages the binding information between a PDU session and its responsible PCF. Its operational flow is as follows.
- Registration: When a PCF establishes the policy for that session, it registers binding information (UE IP address / DNN / S-NSSAI ↔ the identifier of itself = the responsible PCF) with the BSF.
- Query: The AF/NEF involved in that session, or the SMF, queries (Discovery) the BSF for "which PCF handles the policy for this session," and reaches the same PCF.
This guarantees that the multiple paths involved in the same PDU session (the SMPolicy and the AF session) converge on the same PCF. The BSF is the linchpin of multi-PCF consistency in the PCC (Policy and Charging Control) framework.
Basic Concept — Explanation for beginners¶
It is easier to understand the BSF as a "ledger-lookup service for making the persons in charge match."
- A given PDU session (= one customer's case) carries markers such as the UE IP address, DNN, and S-NSSAI.
- When a PCF (person in charge) takes on a case, it records in the ledger (BSF) that "the case with this marker is mine."
- When another front desk (AF/NEF, or the SMF) later handles the same case, it uses the marker as a key to look up the ledger and confirm "who is in charge," then connects to the same person in charge (the same PCF).
In this way, multiple front desks can always reach the same person in charge for the same case.
Network Function details¶
| Item | Content |
|---|---|
| Role | Manages the binding information between a PDU session and its responsible PCF, and lets the PCF for the same session be resolved uniquely in a multi-PCF environment |
| Retained information | Binding information = markers such as UE IP address / DNN / S-NSSAI / PDU Session ID ↔ ID/address of the responsible PCF |
| Main APIs used (calling other NFs) | NF discovery via NRF (Discovery), etc. The coordination is implementation-/configuration-dependent |
| Provided APIs (exposed by itself) | Nbsf_Management (Register / Deregister / Discovery) — registration, deletion, and query of binding information (TS 29.521) |
| Related interfaces | SBI (Nbsf) — between PCF / AF / NEF / SMF and the BSF |
| Impact on failure | In a multi-PCF configuration, PCF inconsistency can occur and the binding of the AF session and the SM policy (aggregation to the same PCF) can fail. In a single-PCF configuration the responsible one is obvious, so the impact is limited |
Architecture¶
The BSF functions as a hub for binding information: it receives binding registrations from the PCF and answers PCF queries from the AF/NEF and SMF.
flowchart LR
PCF["PCF (responsible policy)"]
BSF["BSF (binding management)"]
SMF["SMF"]
AFNEF["AF / NEF (application requests)"]
PCF -- "Nbsf_Management_Register (register binding)" --> BSF
SMF -. "Nbsf_Management_Discovery (query PCF)" .-> BSF
AFNEF -. "Nbsf_Management_Discovery (query PCF)" .-> BSF
BSF -. "return responsible PCF" .-> AFNEF
BSF -. "return responsible PCF" .-> SMF
How to read the diagram: When a PCF establishes the policy for a session, it registers binding information (UE IP/DNN/S-NSSAI ↔ itself) with the BSF. When the SMF or AF/NEF wants to know the PCF for the same session, it queries (Discovery) the BSF, and the BSF returns the responsible PCF, so that both can reach the same PCF. Whether to deploy a BSF, or how to resolve the binding, is implementation-/configuration-dependent.
Interface¶
The main interfaces the BSF has and their roles.
| Interface | Both ends | Role |
|---|---|---|
| SBI (Nbsf) | PCF / AF / NEF / SMF ⇔ BSF | Registration of binding information (PCF→BSF) and query (AF/NEF/SMF→BSF). Unique resolution of the responsible PCF |
The BSF coordinates over SBI (Nbsf_Management) and does not have its own N-numbered reference-point page. For a list of related reference points, see the Interface dictionary.
Appearance in procedures¶
- When establishing SM policy: Along with the establishment of a PDU session's SM Policy Association, the PCF registers binding information with the BSF (an applied context; it is meaningful in a multi-PCF configuration).
- When an external AF makes a QoS request: When an external AF makes a QoS request via the NEF, it discovers the PCF handling that session through the BSF before delivering the request to that PCF.
These are mainly behaviors aimed at consistency in a multi-PCF environment; in a single-PCF configuration the responsible one is obvious, so they may be omitted. For the policy-side details see PCF, and for the QoS-request context see QoS. The fine details of the procedure (messages, IEs, etc.) are to be confirmed.
Comparison with EPC¶
In 4G/EPC, the DRA (Diameter Routing Agent) provided binding/routing support that routed the Diameter signaling (Gx/Rx, etc.) involved in the same session to the same PCRF (PCRF binding). In 5G, this role of "converging the same session on the same policy decision point" can be understood as having been reorganized within the SBA as the BSF (to be confirmed).
| 4G (EPC) | 5G (5GC) |
|---|---|
| DRA (Diameter Routing Agent) binding/routing support (aggregating Gx/Rx to the same PCRF) | BSF (Binding Support Function, Nbsf) |
| PCRF (the policy decision point that is the binding target) | PCF (the policy decision point that is the binding target) |
The DRA is an element responsible for Diameter routing in general, and one of its functions (PCRF binding for the same session) maps to the BSF — that is the framing. The precise functional correspondence is to be confirmed.
Release differences¶
- Rel-15: Defines the basic BSF functions (Register / Deregister / Discovery of binding information, Nbsf_Management).
- Rel-16 / Rel-17: Possible functional extensions. The specific items and section numbers are to be confirmed.
3GPP Specification¶
- 3GPP TS 23.503 — The definition of the BSF is contained in this TS, which specifies the PCC (Policy and Charging Control) framework. The BSF is positioned in terms of binding/PCF-discovery support.
- 3GPP TS 23.501 — The base TS for the system architecture, but note that §6.2 (Network Functions) does not have an independent section for the BSF (the BSF definition is on the TS 23.503 side).
- 3GPP TS 29.521 — The standard specification of the Nbsf_Management service (Register / Deregister / Discovery). The individual section numbers are to be confirmed.
Note (to be confirmed): Unlike other NFs (AMF/SMF, etc.), the BSF does not have an independent section in TS 23.501 §6.2; its definition and role are described in TS 23.503, which deals with the PCC framework (consistent with the NF dictionary). SBI is realized over HTTP/2 + JSON over TLS.
Summary¶
- The BSF is an NF that manages the binding information between a PDU session and its responsible PCF and lets the PCF be resolved uniquely in a multi-PCF environment.
- The binding information is "UE IP / DNN / S-NSSAI / PDU Session ID ↔ responsible PCF"; the PCF registers it, and the AF/NEF and SMF query it (Nbsf_Management: Register / Deregister / Discovery, TS 29.521).
- The purpose is to make the SMF side (SMPolicy) and the AF/NEF side (AF session) converge on the same PCF, which is the linchpin of multi-PCF consistency.
- The role corresponding to the 4G/EPC DRA (PCRF binding/routing support) was reorganized in 5G as the BSF within the SBA (to be confirmed).
- Note that the definition of the BSF is in TS 23.503 (the PCC framework) and it does not have an independent section in TS 23.501 §6.2.
Next Step¶
- PCF — the policy decision point that is the BSF's binding target
- NEF — the side that uses the BSF when bridging external AF requests to the PCF
- QoS — the context of AF QoS requests and PCF discovery
- NF dictionary — to confirm terms for the BSF and related NFs
- Interface dictionary — to confirm SBI (Nbsf)