在5GC中，NF之间的通信基于服务化接口（SBI），所有服务发现都通过NRF进行。如果某个BSF异常宕机（如进程崩溃、服务器断电），但它之前已经在NRF中注册了NFProfile，那么NRF仍然认为该BSF在线可用。其他NF（如PCF、AF）通过NRF发现该BSF后，会尝试调用其服务，结果必然失败。

心跳检测机制就是为了解决这个问题——通过周期性的心跳信号，NRF能够及时发现BSF的异常离线，并自动更新其状态，避免其他NF向一个不存在的BSF发起请求。

心跳检测的工作原理

flowchart LR

    A["BSF注册成功"] --> B["NRF返回heartBeatTimer=120秒"]

    B --> C["BSF启动心跳定时器"]

    C --> D["定时器超时, BSF发送心跳"]

    D --> E["NRF收到心跳, 重置超时计时器"]

    E --> C

    D -->|"BSF异常, 未发送心跳"| F["NRF超时未收到心跳"]

    F --> G["NRF将BSF标记为SUSPENDED"]

    style G fill:#ffcdd2,stroke:#c62828,stroke-width:2px

心跳检测涉及两个关键的定时器：

定时器	方向	说明

心跳发送定时器（BSF侧）	BSF -> NRF	BSF每隔heartBeatTimer秒向NRF发送一次心跳
心跳超时计时器（NRF侧）	NRF内部	NRF如果超过一定时间未收到BSF心跳，则标记BSF为SUSPENDED
URI	{apiRoot}/nnrf-nfm/v1/nf-instances/{nfInstanceID}
Body	包含NF Instance标识
URI	/nnrf-nfm/v1/nf-instances/{nfInstanceID}，与注册URI格式一致
nfInstanceID	BSF的NF实例标识，NRF通过此标识定位NFProfile
heartBeatTimer	120秒	下一次心跳的间隔时长
nfStatus	REGISTERED	BSF状态正常，仍然在线可用
服务发现	NRF在后续的服务发现请求中，将不再返回SUSPENDED状态的BSF
状态通知	已订阅该BSF状态变更的NF（如PCF、AF）将收到通知
NFProfile保留	NRF不会删除NFProfile，仅改变其nfStatus为SUSPENDED
恢复机制	BSF恢复后重新发送心跳或重新注册，NRF可将其状态恢复为REGISTERED
注册成功	启动心跳定时器，开始周期性发送心跳
服务更新	NRF可能在响应中返回新的heartBeatTimer，BSF需调整心跳周期
去注册	停止心跳定时器，不再发送心跳
心跳成功	重置心跳定时器，维持REGISTERED状态
心跳失败	NRF超时后将BSF标记为SUSPENDED

特别说明：服务更新与心跳的关系

当BSF进行服务更新（PUT全量更新）时，NRF在响应中可能返回一个新的heartBeatTimer值。BSF应使用最新的heartBeatTimer值来调整心跳间隔。这意味着：

• 运维人员可以通过修改NRF配置来动态调整BSF的心跳周期；

• 不同时刻的心跳周期可能不同（NRF有权动态调整）。

---

2.6 【工程细节】心跳机制的设计考量

1) 为什么使用PATCH而不是PUT？

心跳使用HTTP PATCH（增量更新）而非PUT（全量更新），这是一个重要的设计优化：

• PATCH请求体很小，仅包含nfInstanceID等必要字段；

• 不需要发送完整的NFProfile，减少网络带宽消耗；

• PATCH操作不会意外覆盖NFProfile中的其他字段。

对比：

心跳（PATCH）:

  请求体大小: 约100字节

  网络开销: 极小

  处理复杂度: 低

注册更新（PUT）:

  请求体大小: 约1~5KB（含完整NFProfile）

  网络开销: 较大

  处理复杂度: 高

2) 心跳周期120秒的选择

本测试中NRF返回的心跳周期为120秒（2分钟），这是一个常见的默认值。运营商可以根据网络规模调整：

心跳周期	适用场景	NRF负载	故障检测延迟
30秒	高可靠性场景（如IMS）	较高	较短（30秒内发现故障）
60秒	一般场景	中等	中等
120秒	默认场景	较低	较长（120秒内发现故障）
300秒	低优先级NF	极低	很长

3) 心跳重试机制

当BSF发送心跳失败（如NRF暂时不可达、网络抖动）时，BSF应实现重试机制：

发送心跳 → 失败

  ↓

等待短暂时间（如5秒）

  ↓

重试发送心跳 → 失败

  ↓

等待更长时间（如10秒）

  ↓

再次重试 → 成功

  ↓

恢复正常心跳周期

如果多次重试均失败，BSF可能需要触发自身的告警机制，通知运维人员NRF不可达。

4) 心跳与NRF高可用

在实际部署中，NRF通常采用主备或多副本部署。BSF的心跳请求可能被负载均衡到不同的NRF实例。NRF集群内部需要同步心跳状态，确保：

• 任何NRF实例都能处理BSF的心跳请求；

• BSF在某个NRF实例上的SUSPENDED状态能被其他NRF实例感知；

• NRF主备切换时不会导致BSF心跳超时。

---

2.7 【深度分析】心跳机制对BSF服务发现的影响

心跳机制直接影响BSF在NRF中的可见性，进而影响服务发现的结果：

正常心跳场景下的服务发现：

PCF → NRF: 发现BSF (target-nf-type=BSF)

NRF → PCF: 返回BSF实例 (nfStatus=REGISTERED)

PCF → BSF: 调用nbsf_management服务 → 成功

心跳超时后的服务发现：

PCF → NRF: 发现BSF (target-nf-type=BSF)

NRF → PCF: 无匹配结果 (BSF已被标记为SUSPENDED, 不参与服务发现)

PCF: 无法找到BSF → 可能触发降级处理或告警

这体现了心跳机制的自我保护特性——当BSF不可用时，通过心跳超时机制自动将其从服务发现结果中排除，避免PCF/AF向不可用的BSF发起请求。

---

3 测试结论

验证项	结果	说明
BSF心跳功能正常	OK	BSF能按周期发送心跳PATCH请求
NF Instance标识一致	OK	PATCH消息中的nfInstanceID与实际配置一致
心跳周期一致	OK	120秒间隔，与NRF返回的heartBeatTimer一致
NRF响应正确	OK	每次返回200 OK
心跳周期稳定性	OK	连续5次心跳间隔误差在毫秒级
BSF状态维持	OK	nfStatus始终为REGISTERED

本测试用例完美通过。BSF通过Nnrf_NFManagement_NFHeartBeat服务（HTTP PATCH）按120秒的周期向NRF发送心跳信号。NRF收到心跳后正确返回200 OK确认，BSF状态始终维持在REGISTERED。通过连续多次观察，确认心跳间隔稳定在120秒左右（误差在毫秒级），与NRF返回的heartBeatTimer完全一致。整个心跳机制与3GPP TS 29.510规范完全吻合。

协议参考汇总：

• 3GPP TS 29.510 第6.1.6.2.4节：NF Heartbeat流程

• 3GPP TS 29.510 第6.1.6.2节：NF Profile管理

• 3GPP TS 29.551：BSF Service-Based Interface

---

---

关于作者：爱卫生，从事通信教学18年，出版过《5G核心网原理与实践》等4本专业书籍。学5G核心网、IMS，来51学通信就对了！知识星球：200+小时视频、3000+精华文章、1年答疑群。公众号/知识星球：51学通信，微信：gprshome201101