《5G核心网原理与实践》实践篇 · BSF 网元功能
作者：爱卫生
在前五篇文章中，我们系统性地介绍了BSF（Binding Support Function，绑定支持功能）的基本概念、架构设计、服务注册发现以及会话绑定信息的查询机制。作为5G核心网中连接PCF与AF的"桥梁"，BSF承担着为应用层精确路由策略控制信息的关键职责。
然而，在实际运营商级部署中，任何一个核心网网元都必须面对一个根本性的挑战——高可用性（High Availability, HA）。当BSF节点发生故障时，整个策略绑定体系是否会瘫痪？AF还能否找到对应的PCF？正在进行的会话是否会被中断？
本篇聚焦BSF的可靠性保障机制，重点验证以下场景：当BSF所依赖的主NRF（Network Repository Function）发生故障时，BSF能否自动切换至备用NRF，继续完成NF注册更新流程，从而保证BSF服务的持续可用性。
在5GC服务化架构中，BSF的可靠性保障主要涉及以下几个层面：
NRF主备容灾：BSF配置主、备两个NRF地址，当主NRF不可达时自动切换至备NRF进行注册更新；
BSF自身的主备/负荷分担部署：多个BSF实例可部署为主备模式或负荷分担模式，通过NRF的服务发现机制实现负载均衡和故障转移；
数据同步机制：BSF实例之间进行会话绑定信息的数据复制，确保主备切换后绑定数据不丢失。
本测试用例主要验证第一层——BSF对主备NRF切换的支持能力。
sequenceDiagram
participant BSF as SMF/BSF
participant PrimaryNRF as 主NRF
participant StandbyNRF as 备NRF
Note over BSF, PrimaryNRF: 正常状态: BSF注册在主NRF
BSF->>PrimaryNRF: Nnrf_NFManagement_NFRegister Request
PrimaryNRF-->>BSF: Nnrf_NFManagement_NFRegister Response (201 Created)
Note over PrimaryNRF: 主NRF故障!
Note over BSF, StandbyNRF: BSF检测到主NRF不可达
BSF->>StandbyNRF: Nnrf_NFManagement_NFUpdate Request
Note right of BSF: 注册更新请求发送给备NRF
StandbyNRF-->>BSF: Nnrf_NFManagement_NFUpdate Response (200 OK)
Note over BSF, StandbyNRF: BSF成功切换至备NRF
flowchart LR
A["BSF初始注册到主NRF"] --> B["主NRF正常运行"]
B --> C["主NRF故障"]
C --> D["BSF检测主NRF不可达"]
D --> E["BSF向备NRF发送注册更新"]
E --> F["备NRF响应成功"]
F --> G["BSF服务持续可用"]
style A fill:#e3f2fd,stroke:#1565c0,stroke-width:2px
style C fill:#ffcdd2,stroke:#c62828,stroke-width:2px
style F fill:#c8e6c9,stroke:#2e7d32,stroke-width:3px
style G fill:#c8e6c9,stroke:#2e7d32,stroke-width:3px
验证BSF支持主备NRF的切换功能。当BSF注册的主NRF发生故障时，BSF能够自动将注册更新请求发送给备用NRF，确保BSF服务不中断。
5GC网络中各网元系统及操作维护台运行正常。
BSF上已配置主、备NRF的地址信息。
BSF已成功注册在主NRF中，且主NRF中存在BSF的NFProfile。
服务化接口的信令监控与分析工具准备就绪。
BSF（内置于SMF中）和PCF网元服务注册成功。
确认BSF当前已注册在主NRF中，检查BSF在主NRF上的注册状态为正常。
模拟主NRF故障（可通过关闭主NRF进程或断开网络连接等方式实现）。
等待BSF发送注册更新请求（Nnrf_NFManagement_NFUpdate）。
捕获并分析BSF发送的注册更新请求的目的地址，确认请求是否发送给备NRF。
检查备NRF是否成功响应BSF的注册更新请求。
验证BSF服务是否仍然可用（可通过发起会话绑定信息查询来验证）。
BSF在主NRF故障后，能够自动检测到主NRF不可达。
BSF将注册更新请求（Nnrf_NFManagement_NFUpdate）发送给备NRF，而非主NRF。
备NRF成功响应BSF的注册更新请求，返回200 OK或204 No Content。
BSF的服务状态保持正常，能够继续处理会话绑定相关的业务请求。
当主NRF恢复正常后，BSF可以选择性地重新注册回主NRF（取决于厂商实现）。
本测试涉及的核心信令是BSF与NRF之间的Nnrf_NFManagement服务，具体为NF注册更新（NFUpdate）流程。下面我们逐步解析这一过程的信令细节。
（注：为保护网络安全，以下log中的网元IP及实例ID等敏感信息已做严格脱敏处理）
在测试开始前，BSF已经完成了向主NRF的NF注册。这一过程通过Nnrf_NFManagement_NFRegister服务实现，BSF将自己的NFProfile（包含NF类型、实例ID、服务列表等信息）注册到主NRF中。
sequenceDiagram
participant BSF as SMF/BSF
participant NRF as 主NRF
Note over BSF, NRF: 初始注册阶段
BSF->>NRF: PUT /nnrf-nfm/v1/nf-instances/{bsfInstanceId}
Note right of BSF: 请求体携带:<br/>nfType: BSF<br/>nfInstanceId<br/>services列表<br/>ipv4Addresses
NRF-->>BSF: 201 Created
Note left of NRF: NRF存储BSF的NFProfile<br/>设置heartBeatTimer
注册请求关键参数：
PUT /nnrf-nfm/v1/nf-instances/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
JavaScript Object Notation: application/json
Object
Member Key: nfType
String value: "BSF"
# 网元类型标识为BSF
Member Key: nfInstanceId
String value: "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"
# BSF的NF实例ID
Member Key: nfServices
Array
Object
Member Key: serviceName
String value: "nnbsf_management"
# BSF提供的核心服务：Nbsf_Management
Member Key: versions
Array
String value: "v1"
Member Key: ipv4Addresses
Array
String value: "10.XX.XX.XX"
# BSF的服务IP地址
| 参数 | 含义 | 说明 |
|---|---|---|
nfType |
NF类型 | 标识为BSF，供其他网元通过NRF发现 |
|---|---|---|
nfInstanceId |
NF实例ID | UUID格式，全局唯一标识该BSF实例 |
nfServices |
服务列表 | BSF对外提供的SBI服务，核心为nnbsf_management |
ipv4Addresses |
服务地址 | 其他网元访问BSF的IP地址 |
协议参考：根据3GPP TS 29.551第6.1节，BSF作为服务生产者（Service Producer）需要在NRF中注册自己的NFProfile，其中包含BSF支持的服务能力信息。其他网元（如AF、PCF）通过NRF发现BSF时，NRF会根据NFProfile中的信息进行匹配和返回。
当主NRF发生故障时，BSF会通过心跳检测机制发现主NRF不可达。随后BSF触发注册更新流程，将目标NRF切换为备用NRF。
切换触发机制：
BSF与NRF之间通过心跳机制保持连接。3GPP规范中定义了heartBeatTimer参数，NRF在注册响应中会携带该参数，BSF需要定期向NRF发送心跳更新。当BSF连续多次心跳失败时，会判定当前NRF不可用，触发向备NRF的切换。
flowchart TD
A["BSF定期向主NRF发送心跳"] --> B["心跳是否成功"]
B -->|"是"| A
B -->|"否: 超时或连接失败"| C["重试N次"]
C --> D["重试是否全部失败"]
D -->|"否"| B
D -->|"是"| E["判定主NRF故障"]
E --> F["切换到备NRF"]
F --> G["向备NRF发送NFUpdate请求"]
G --> H["备NRF响应成功"]
H --> I["BSF注册信息迁移完成"]
style E fill:#ffcdd2,stroke:#c62828,stroke-width:2px
style I fill:#c8e6c9,stroke:#2e7d32,stroke-width:3px
切换过程中的注册更新请求：
# BSF检测到主NRF不可达后，向备NRF发送注册更新
PUT /nnrf-nfm/v1/nf-instances/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
Host: 10.XX.XX.XY:8080 # 注意：这里的目标地址是备NRF的IP
Content-Type: application/json
JavaScript Object Notation: application/json
Object
Member Key: nfType
String value: "BSF"
Member Key: nfInstanceId
String value: "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"
Member Key: nfStatus
String value: "REGISTERED"
# 标识NF状态为已注册
Member Key: nfServices
Array
Object
Member Key: serviceName
String value: "nnbsf_management"
Member Key: versions
Array
String value: "v1"
# 备NRF响应
HTTP/1.1 200 OK
# 或 204 No Content
# 表示备NRF已成功接收并存储了BSF的注册信息
关键验证点：
| 验证项 | 检查方法 | 预期结果 |
|---|---|---|
| 目标地址切换 | 检查HTTP请求的Host头 | 从主NRF的IP变更为备NRF的IP |
| 注册更新成功 | 检查备NRF的响应码 | 200 OK或204 No Content |
| 服务持续可用 | 通过AF发起会话绑定查询 | 查询成功返回绑定信息 |
| 心跳恢复 | 检查BSF后续心跳目标 | 心跳发送给备NRF |
协议参考：根据3GPP TS 29.551第6.2节和TS 29.510第5.2.2节，NF注册更新（NFUpdate）允许BSF在已有的注册信息基础上进行更新。当BSF切换到备NRF时，相当于在备NRF上创建了一条新的注册记录。备NRF需要能够正确处理这种"非初始注册"场景。
BSF成功切换到备NRF后，最关键的问题是：其他网元（如AF、PCF）能否继续通过NRF发现BSF并使用其服务？
这涉及5GC服务化架构中的一个重要机制——NRF的同步。在运营商部署中，主备NRF之间通常会进行数据同步，确保NF注册信息的一致性。当主NRF故障、备NRF接管后，备NRF中应该已经拥有（或通过BSF重新注册获得了）BSF的NFProfile信息。
sequenceDiagram
participant AF as AF/PCF
participant NRF as 备NRF
participant BSF as SMF/BSF
Note over AF, BSF: 切换后的服务发现流程
AF->>NRF: GET /nnrf-nfm/v1/nf-instances?nf-type=BSF
Note right of AF: 服务发现请求<br/>查询BSF实例
NRF-->>AF: 200 OK (含BSF的NFProfile)
Note left of NRF: 备NRF返回BSF注册信息<br/>包含BSF地址和服务列表
AF->>BSF: GET /nbsf-management/v1/pcfBindings?ipv4Addr=10.XX.XX.XX
Note right of AF: 使用BSF服务查询会话绑定
BSF-->>AF: 200 OK (含绑定信息)
Note left of BSF: BSF正常响应<br/>服务连续性得到保障
切换后的服务发现请求示例：
# AF/PCF向备NRF发起BSF服务发现
GET /nnrf-nfm/v1/nf-instances?nf-type=BSF&target-nf-type=AF
Host: 10.XX.XX.XY:8080
# 备NRF响应
HTTP/1.1 200 OK
JavaScript Object Notation: application/json
Object
Member Key: nfInstances
Array
Object
Member Key: nfInstanceId
String value: "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"
Member Key: nfType
String value: "BSF"
Member Key: ipv4Addresses
Array
String value: "10.XX.XX.XX"
Member Key: nfServices
Array
Object
Member Key: serviceName
String value: "nnbsf_management"
Member Key: apiPrefix
String value: "http://10.XX.XX.XX:8080"
除了NRF主备切换之外，BSF自身的可靠性部署也是运营商网络设计的关键议题。根据3GPP TS 29.551的架构定义，BSF支持以下部署模式：
模式一：内置BSF（本测试采用的方式）
BSF功能内置于SMF中，作为SMF的一个功能模块运行。这种部署方式的优点是SMF与BSF之间的交互为内部调用，无需经过SBI接口，性能开销小。但缺点是BSF的可靠性与SMF绑定，SMF故障时BSF也不可用。
模式二：独立BSF
BSF作为独立网元部署，可以通过主备或负荷分担方式提高可靠性。多个BSF实例注册到NRF中，AF/PCF通过NRF进行服务发现和负载均衡。
flowchart TD
A["BSF可靠性部署模式"] --> B["模式一: 内置BSF"]
A --> C["模式二: 独立BSF"]
B --> B1["BSF内置于SMF"]
B1 --> B2["优点: 内部调用性能高"]
B1 --> B3["缺点: 与SMF耦合"]
B3 --> B4["可靠性方案: SMF主备切换"]
C --> C1["BSF独立部署"]
C1 --> C2["主备模式: Active-Standby"]
C1 --> C3["负荷分担: Load Balancing"]
C2 --> C4["主BSF故障时备BSF接管"]
C3 --> C5["多实例分担, 单实例故障影响小"]
style B2 fill:#e8f5e9,stroke:#2e7d32
style C2 fill:#e3f2fd,stroke:#1565c0
style C3 fill:#e3f2fd,stroke:#1565c0
BSF数据同步机制：
当采用独立BSF部署时，多个BSF实例之间需要同步会话绑定信息，确保任何一个BSF实例都能响应AF/PCF的查询请求。数据同步通常采用以下方式：
| 同步方式 | 原理 | 适用场景 |
|---|---|---|
| 实时同步 | 主BSF每次收到绑定创建/删除请求时，实时同步到备BSF | 对数据一致性要求高的场景 |
| 定期同步 | 主BSF定期批量同步绑定信息到备BSF | 对实时性要求不高的场景 |
| 共享存储 | 多个BSF实例访问同一个后端数据库 | 大规模部署场景 |
协议参考：根据3GPP TS 29.551第5.2节，BSF的
Nbsf_Management服务是无状态的（stateless），这意味着BSF可以将绑定信息持久化到外部存储（如UDR），从而实现多个BSF实例之间的数据共享。这也是5GC服务化架构"控制面与数据面分离"设计理念的体现。
| 验证项 | 结果 | 说明 |
|---|---|---|
| BSF初始注册到主NRF | OK | BSF通过Nnrf_NFManagement_NFRegister成功注册 |
| 主NRF故障检测 | OK | BSF通过心跳机制检测到主NRF不可达 |
| 自动切换到备NRF | OK | BSF将注册更新请求发送给备NRF |
| 备NRF成功响应 | OK | 备NRF返回200 OK，注册信息更新成功 |
| 服务连续性 | OK | 切换后BSF仍能正常提供会话绑定服务 |
本测试用例验证了BSF在主NRF故障场景下的可靠性保障能力。BSF能够通过心跳检测机制及时发现主NRF不可达，并自动将注册更新请求切换至备用NRF，确保BSF服务的持续可用性。这一机制是运营商级5GC网络可靠性的基础保障之一，确保了会话绑定服务在NRF单点故障场景下不中断。
结合3GPP TS 29.551规范，BSF的可靠性保障还包括BSF自身的主备/负荷分担部署以及数据同步机制，这些内容将在后续文章中结合实际部署场景进一步展开分析。
关于作者：爱卫生，从事通信教学18年，出版过《5G核心网原理与实践》等4本专业书籍。学5G核心网、IMS，来51学通信就对了！知识星球：200+小时视频、3000+精华文章、1年答疑群。公众号/知识星球：51学通信，微信：gprshome201101