5G核心网网络健壮性增强方案研究

张欣，朱晓林，滕佳欣，刘凡栋（.中国联合网络通信集团有限公司，北京 00033；.中讯邮电咨询设计院有限公司郑州分公司，河南郑州 450007）

0 引言

随着通信网络的IP 化和云化演进，网络故障的影响范围扩大。当发生网络故障时，故障点可能对大量用户业务形成“堰塞湖”效应，并在故障解除时触发瞬间的信令冲击。为了降低网络故障的影响、减少信令风暴的产生，需进一步增强网元功能，提升网络健壮性。本文主要对AMF 主备网元用户动态数据热备功能和5GC免UDM惯性运行功能进行研究，提出5GC网元功能增强方案。

1 网络功能增强解决方案

1.1 AMF主备网元用户动态数据热备功能

AMF 主备网元之间保持用户动态数据的同步，发生主备倒换后，备用网元有用户动态数据，用户无需重新注册，无注册浪涌信令，减少对各网元的信令冲击。

正常工作状态，AMF 将用户上下文状态数据同时保存到其备份AMF 中。当AMF 故障后，周边网元把用户消息发送给备份AMF，备份AMF查询用户上下文状态数据，继续处理用户业务流程，从而保障了业务连续性。同时，由于UE 不用重新注册就能使业务继续，无注册浪涌信令，减少了对各网元的信令冲击。

周边网元发送至AMF 的消息包括从RAN 发起和其他5GC 网元发起2 类，其中RAN 侧主动发起的业务流程如图1所示。

图1 RAN主动发起的业务流程

a）为AMF1（原AMF）配置备份的AMF2（备份AMF），AMF1 将Served GUAMI 以及Backup AMF 信息下发给gNodeB。AMF2 通过NF 注册流程将其备份的GUAMI保存到NRF中，供其他NF获取。

b）用户接入网络并进行业务流程处理。AMF1在业务处理流程中，将用户上下文状态数据同步到AMF2中，AMF2保存同步数据。

c）当AMF1 发生故障时，UE 发起业务请求，gNodeB 发送消息无响应，gNodeB 识别并判定AMF1 故障，将用户的请求消息发送给AMF2。AMF2 接收用户请求后，判断其原为AMF1所处理的用户，从保存数据中获取用户上下文状态数据，并继续处理此用户的相关业务流程。AMF2 为用户重新分配5G-GUTI，向gNodeB 发送更新5G-GUTI 及AMF UE NGAP ID 的消息，后续此用户业务由AMF2 进行处理。AMF2 与其他NF交互，其他NF 接收消息后，识别AMF1 故障，后续与AMF2交互处理此用户相关业务流程。

d）后续此UE的业务将在AMF2正常处理。

周边5GC网元主动发起的业务流程如图2所示。

图2 周边5GC网元主动发起的业务流程

a）正常业务处理流程中，UE1 用户的业务由AMF1处理。业务流程处理完毕，AMF1将用户上下文状态数据同步到为其备份的AMF2中，AMF2保存同步数据。

b）当AMF1 发生故障时，无法正常向NRF 发送Heartbeat 保活机制的更新消息，NRF 识别并判定AMF1 故障。NRF向订阅了 原AMF 状态 的NF 发送状态变更通知消息（原AMF故障）。周边NF如SMF、PCF等在本地没有备份AMF信息的情况下，可向NRF执行AMF发现流程，用于获取原AMF的备份AMF信息。

c）周边NF 如SMF、PCF 等在需要主动发起业务流程的情况下，选择故障AMF1（即原AMF）的备份AMF（AMF2），将业务消息发送给AMF2。AMF2 接收业务消息后，判断其原为AMF1所处理的用户，从保存的数据中获取UE1 用户上下文状态数据，并继续处理此用户的相关业务流程。AMF2 为用户重新分配5GGUTI，向gNodeB 发送消息更新5G-GUTI 及AMF UE NGAP ID 的消息，后续此用户业务由AMF2 进行处理。AMF2 与其他NF（如PCF）交互，继续处理此用户业务流程。其他NF 接收消息后，识别AMF1 故障，后续与AMF2 交互处理此用户相关业务流程。AMF2 与UDM交互，通知AMF2 成为此用户的服务AMF，UDM 保存相关信息，同时与备份AMF 交互处理此用户相关业务流程。

d）后续UE1的业务由AMF2进行处理。

1.2 5GC免UDM惯性运行功能

5GC 免UDM 惯性运行功能主要针对AMF 和SMF网元，包含4个部分，即故障检测、故障后处理、故障恢复检测、故障恢复处理。

1.2.1 故障检测

AMF、SMF 支持如下方式检测UDM 是否故障：基于NRF 状态通知、本地NF 状态检测、基于响应状态码和错误码。

1.2.1.1 基于NRF状态通知

基于NRF 状态通知适用于直连组网、SCP C 组网模式。如图3 所示，AMF、SMF 向NRF 订阅UDM 状态变更通知，当NRF 检测到UDM 状态由正常状态变换为故障状态后，触发NF 状态通知，告知AMF、SMF 新的UDM 状态。AMF、SMF 故障检测机制相同，以AMF为例进行说明，流程如下：

图3 基于NRF状态通知

步骤1：AMF 向NRF 发送订阅请求Nnrf_NFManagement_NFStatusSubscribe Request，携带需要订阅的UDM。

步骤2：NRF 保存订阅信息，并返回响应Nnrf_NFManagement_NFStatusSubscribe Response。

步骤3：NRF 检测到UDM 状态变为故障态，比如通过本地NF检测。

步骤4：NRF 触发NF 状态通知NnrfNF_Management_NFStatusNotify给AMF，携带UDM最新状态。

1.2.1.2 本地NF状态检测

本地NF 状态检测仅适用于直连组网模式。通过定时向目标NF 发起HTTP PING 检测消息，以确认目标NF是否正常，如图4所示。

图4 本地NF状态检测

步骤1：AMF定时向UDM触发HTTP PING检测。

步骤2：AMF 等待HTTP PING 响应超时次数超过门限，判定UDM 故障，将对应UDM 加入到故障列表中。

1.2.1.3 基于响应状态码和错误码

基于响应状态码和错误码适用于SCP D 组网模式。如图5 所示，AMF 基于SCP/UDM 返回响应的HTTP 状态码以及应用错误码，判断UDM 是否故障。UDM bypass 是一个定制功能，为了防止该功能对原有功能产生影响，建议SCP 检测到UDM 故障时，返回状态码502以及应用错误码bypass。其中，bypass为自定义的应用错误码。流程如下：

图5 基于响应状态码与应用错误码图

步骤1：SCP 通过本地状态检测或者NRF 状态通知，检测到UDM已经故障。

步骤2：AMF 收到用户业务且需要和UDM 交互，比如向UDM 请求签约数据，则发送用户业务请求消息给SCP。

步骤3：SCP 根据本地已保存的UDM 状态信息，判定用户归属的UDM 已全部故障，则回复用户业务失败响应，携带已经规划的指示UDM 全故障的状态码或应用层错误码。AMF 收到该失败响应后，判断用户归属的UDM故障。

1.2.2 故障后处理

如图6 所示，AMF、SMF 检测到UDM 故障，则启用本地缓存的用户签约数据或本地配置的签约数据，跳过UDM 注册、订阅以及请求签约数据过程，继续用户当前信令业务，触发用户进入bypass 状态。AMF、SMF故障后处理机制相同，以AMF 为例进行说明，流程如下：

图6 故障后处理流程图

步骤1：UE 触发业务请求，比如用户从4G 移动到5G，或者从其他AMF 回到本AMF，或者本局重新初始注册等。

步骤2：AMF 已通过本地NF 检测、NRF 状态通知等方式，检测到用户归属的UDM全部故障。

步骤3：若AMF 根据步骤2 判断用户归属UDM 全部故障后，触发用户进入bypass 状态，跳过用户鉴权、UDM注册、UDM订阅、向UDM请求签约数据。若AMF本地未缓存用户签约数据，则启用本地配置的签约数据。

步骤4：用户信令业务继续，给UE回复成功响应。

1.2.3 故障恢复检测

AMF、SMF 支持3 种方式检测UDM 是否故障恢复：基于NRF 状态通知、本地NF 状态检测、基于响应状态码和错误码。

1.2.3.1 基于NRF状态通知

如图7 所示，AMF、SMF 向NRF 订阅UDM 状态变更通知，当NRF 检测到UDM 状态由正常状态变换为故障状态后，触发NF 状态通知，告知AMF、SMF 新的UDM 状态。AMF、SMF 故障恢复检测机制相同，以AMF为例进行说明，流程如下：

图7 基于NRF状态通知

步骤1：AMF 已经检测到UDM 故障，且AMF 已经向NRF订阅了UDM状态。

步骤2：UDM从故障状态恢复为正常状态。

步骤3：NRF通过本地NF检测或者UDM主动触发更新流程，判定UDM已经从故障态恢复为正常状态。

步骤4：NRF 触发NF 状态通知NnrfNF_Management_NFStatusNotify给AMF，携带UDM最新状态。

1.2.3.2 本地NF状态检测

如图8 所示，通过定时向检测到的故障NF 发起HTTP PING 检测消息，以确认目标NF 是否正常。本地NF状态检测流程如下。

图8 本地NF状态检测

步骤1：UDM已经从故障态恢复。

步骤2：AMF 定时向检测到的故障UDM 触发HTTP PING REQUEST。

步骤3：UDM 回复响应HTTP PING RESPONSE。AMF 判定UDM 已经恢复，从NF 故障列表中将对应UDM移除。

1.2.3.3 基于响应状态码和错误码

如图9所示，AMF基于SCP返回响应的HTTP状态码以及应用错误码，判断UDM是否恢复。流程如下：

图9 基于响应状态码和错误码

步骤1：UDM已经从故障态恢复。

步骤2：SCP已通过故障检测机制，比如本地NF检测机制，检测到UDM已经恢复。

步骤3：AMF 定时扫描bypass 状态用户，触发用户级检测请求消息，该请求消息经过SCP转发给UDM。

步骤4：UDM 回复响应消息，经过SCP 转发给AMF。若为成功响应，或者虽然为失败响应但消息中未携带指示UDM 故障的状态码以及应用层错误码，则AMF判定用户归属的UDM已经恢复。

1.2.4 故障恢复处理

AMF 定时扫描bypass 状态用户，通过故障恢复检测机制，判定UDM 已经恢复后，触发用户下线并重新注册。在用户重新注册时，恢复用户鉴权以及和UDM交互过程。故障恢复处理流程如图10所示。

图10 故障恢复处理流程图

步骤1：AMF定时扫描bypass用户。

步骤2：AMF通过故障恢复检测机制，比如NRF状态通知、本地NF 通知或者用户级检测消息，判定UDM已经恢复。

步骤3：AMF 触发用户下线，下发Deregistration Request，携带re-registration required，请求用户重新注册。若用户处于空闲态，需要先触发用户寻呼。

步骤4：UE 触发注册过程，发送Registration Request给AMF。

步骤5：AMF 根据本地策略判定需要鉴权用户，则触发鉴权过程。

步骤6：AMF 判断用户为bypass 用户，则触发向UDM注册过程。

步骤7：AMF 判断bypass 用户且用户签约数据为本地配置的签约数据，则触发向UDM 请求用户签约数据。

步骤8：AMF 判断用户为bypass 用户，则触发向UDM订阅用户签约数据变更。

步骤9：AMF 将用户退出bypass 状态，继续用户注册流程。

2 测试验证

为了进一步验证本文方法的有效性，组织5G核心网主设备厂家基于实验环境进行了相关功能测试。

2.1 AMF主备网元用户动态数据热备功能测试

2.1.1 测试内容

如表1 所示，针对AMF 主备网元用户动态数据热备功能测试，设计了4个测试用例。

表1 AMF主备网元用户动态数据热备功能测试表

2.1.2 测试结果

AMF 主备网元用户动态数据热备功能测试情况如表2所示。

表2 AMF主备网元用户动态数据热备功能测试结果表

2.2 5GC免UDM惯性运行功能测试

2.2.1 测试内容

如表3 所示，针对5GC 免UDM 惯性运行功能测试，设计了10个测试用例。

表3 5GC免UDM惯性运行功能测试表

2.2.2 测试结果

测试情况如表4所示。

表4 5GC免UDM惯性运行功能测试结果表

因测试环境原因，2个厂家都未进行用例4、用例7测试。因A 厂家AMF、SMF 目前暂不支持手动进入UDM bypass状态，暂未测试用例9。

2.3 测试结论总结和局限性说明

通过实验室测试验证，基本验证了AMF 主备网元用户动态数据热备功能和5GC 免UDM 惯性运行功能的有效性和可行性，为进一步开展现网测试验证提供了参考依据。但受限于测试环境和测试版本，部分测试用例未完成测试，且异厂家的兼容性测试未进行，有待进一步测试验证。

3 结束语

面对网络故障或业务异常导致的信令风暴，通过引入AMF 主备网元用户动态数据热备、5GC 免UDM惯性运行等功能，可进一步提升网络业务保障能力，规避用户大量下线、业务中断导致的信令风暴，降低信令风暴对网络的冲击，进一步提升网络的健壮性。