《5G核心网原理与实践》实践篇 · BSF 网元功能
作者：爱卫生
在上一篇中，我们详细剖析了BSF如何向NRF发起服务注册——那是BSF从"不存在"到"被发现"的诞生过程。而本篇则关注BSF生命周期的另一个端点：服务去注册（Deregistration）。
当BSF因为维护、升级、故障或者其他运营原因需要停止服务时，它不能简单地"消失"，而是必须主动向NRF发起去注册，将自己从NRF的网元仓库中干净地移除。这就像员工离职时需要办理正式的离职手续、交接工作一样——如果不执行去注册，NRF仍然会认为该BSF在线可用，其他网元（如PCF、AF）可能会通过NRF发现到一个已经不存在的BSF，导致服务调用失败。
BSF服务去注册是指BSF主动向NRF发送DELETE请求，请求NRF删除该BSF的NFProfile和相关服务注册信息。去注册成功后：
NRF本地数据库中不再保留该BSF的任何信息；
其他NF通过NRF进行服务发现时，将无法再找到该BSF；
已经订阅了该BSF状态变更通知的NF，会收到NRF推送的通知（NF状态变为DEREGISTERED）。
值得注意的是，BSF从NRF中"消失"有两种途径：
| 方式 | 主动性 | 触发条件 | 是否优雅 |
|---|---|---|---|
| 主动去注册 | BSF主动 | BSF正常停机/维护/升级 | 优雅，所有资源被清理 |
|---|---|---|---|
| 心跳超时 | NRF被动 | BSF异常宕机/断网，心跳中断 | 非优雅，可能残留临时状态 |
| DELETE消息的URI | {apiRoot}/nnrf-nfm/v1/nf-instances/{nfInstanceID}，其中apiRoot和nfInstanceID与实际配置一致 |
||
| 消息Body | 不包含Body（DELETE请求不需要请求体） | ||
| URI | {apiRoot}/nnrf-nfm/v1/nf-instances/{nfInstanceID}，精确指向要删除的NF实例 |
||
| Body | 无，去注册不需要携带额外的请求体 | ||
| BSF主动去注册 | BSF通过DELETE主动告知NRF | 计划性维护、版本升级、正常停机 | |
| 运维平台强制去注册 | 运维人员通过OAM界面触发 | BSF异常时的手动干预 |
无论哪种方式，底层的SBI消息交互是一样的——都是DELETE请求。
在实际网络运营中，去注册流程并不总是一帆风顺。以下是一些常见的异常场景及其处理方式：
场景1：BSF发送DELETE后未收到响应
当BSF向NRF发送DELETE请求后，可能因为网络抖动、NRF繁忙等原因未收到响应。此时BSF应实现超时重试机制：
BSF发送DELETE请求
↓
等待响应超时（如5秒）
↓
重试发送DELETE请求（最多重试3次）
↓
3次重试均失败 → BSF记录告警日志
↓
BSF继续执行停机流程
↓
NRF侧：依赖心跳超时机制最终清理该BSF的NFProfile
这种场景下，虽然主动去注册失败，但NRF的心跳超时机制会作为兜底保障——BSF停止心跳后，NRF最终会将其标记为SUSPENDED。
场景2：NRF返回404 Not Found
如果NRF返回404，说明该nfInstanceID在NRF中已不存在。可能的原因：
| 原因 | 说明 | 处理方式 |
|---|---|---|
| BSF已被去注册 | 可能之前的去注册已成功，但BSF未收到响应 | 无需额外处理，记录日志即可 |
| nfInstanceID配置错误 | BSF使用了错误的实例标识 | 检查BSF配置，修正nfInstanceID |
| NRF数据被清理 | NRF重启或数据库被清理 | 无需额外处理 |
场景3：BSF异常宕机未执行去注册
当BSF因进程崩溃、服务器断电等原因突然宕机时，无法主动向NRF发送DELETE请求。此时NRF依赖心跳超时机制来检测BSF的离线：
BSF异常宕机
↓
BSF停止发送心跳
↓
NRF在heartBeatTimer超时后未收到心跳
↓
NRF将BSF标记为SUSPENDED
↓
NRF通知订阅方（PCF、AF等）
↓
后续服务发现中不再返回该BSF
这种场景虽然不如主动去注册"优雅"，但通过心跳超时机制仍能保证网络的一致性。
在运营商网络中，BSF的版本升级是一个常见的运维操作。典型的升级流程如下：
flowchart TD
A["开始BSF版本升级"] --> B["BSF发起服务去注册"]
B --> C["NRF返回204, BSF从NRF中消失"]
C --> D["BSF停止服务, 执行版本升级"]
D --> E["BSF启动新版本"]
E --> F["BSF发起服务注册"]
F --> G["NRF返回201, BSF重新上线"]
G --> H["版本升级完成"]
style B fill:#fff3e0,stroke:#e65100,stroke-width:2px
style H fill:#c8e6c9,stroke:#2e7d32,stroke-width:3px
关键注意事项：
去注册后到重新注册之间的时间窗口内，PCF和AF无法通过NRF发现该BSF；
如果BSF内部有持久化的绑定数据，升级后重新注册时绑定数据可以恢复；
在多BSF部署（BSF Pool）场景下，一个BSF的去注册不会影响其他BSF的服务能力。
| 验证项 | 结果 | 说明 |
|---|---|---|
| BSF服务去注册成功 | OK | NRF成功删除BSF的NFProfile |
| DELETE消息URI正确 | OK | 格式为/nnrf-nfm/v1/nf-instances/{nfInstanceID} |
| DELETE请求无Body | OK | 去注册请求不携带请求体 |
| NRF返回204 No Content | OK | 去注册成功且响应无Body |
| NRF查询验证 | OK | 查询返回"Can not find the nfInstance info" |
本测试用例完美通过。BSF通过Nnrf_NFManagement_NFDeregister服务（HTTP DELETE）成功向NRF发起了服务去注册。NRF返回204 No Content确认删除成功，后续查询确认该BSF的NFProfile已从NRF中完全移除。整个去注册流程与3GPP TS 29.510规范完全吻合。
协议参考汇总：
3GPP TS 29.510 第6.1.6.3节：NF Deregistration流程
3GPP TS 29.551：BSF Service-Based Interface
关于作者：爱卫生，从事通信教学18年，出版过《5G核心网原理与实践》等4本专业书籍。学5G核心网、IMS，来51学通信就对了！知识星球：200+小时视频、3000+精华文章、1年答疑群。公众号/知识星球：51学通信，微信：gprshome201101