本文技术原理深度参考了3GPP TS 38.413 V18.5.0 (2025-03) Release 18规范中,关于“8.7.4 NG Reset”的核心章节,旨在为读者提供一个关于NG-C接口在遭遇严重故障时如何进行“一键恢复”的深度洞察。

深度解析 3GPP TS 38.413:8.7.4 NG Reset (NG接口重置)

大家好,欢迎继续关注我们的3GPP规范深度解析系列。在前几期文章中,我们探讨了NG接口的建立(NG Setup)和动态维护(Configuration Update)。这些流程都属于网络正常运行时的“日常工作”。然而,再稳定的系统也无法完全避免故障。当AMF或gNB遭遇软件崩溃、硬件失效等严重问题,导致其内部保存的用户上下文信息大量丢失时,网络该如何自愈?

今天,我们将深入探讨NGAP协议中的“紧急恢复按钮”——**NG Reset (NG接口重置)**流程。

如果说NG Setup是gNB与AMF的初次“建交”,Configuration Update是日常的“工作通报”,那么NG Reset就是一方遭遇“失忆”后,向对方发出的“紧急同步请求”。这是一个强力的、用于从重大故障中恢复的机制,其核心目标是在最短时间内恢复两个网元之间状态的一致性,即便代价是中断受影响用户的业务。

这个流程同样是双向的,既可以由AMF发起,也可以由gNB发起。我们将继续使用我们的老朋友——gNB-CBD-01AMF-Alpha作为主角,通过模拟两种典型的灾难恢复场景,来剖析NG Reset流程的两种模式:

  1. AMF发起的重置:AMF-Alpha因故突然重启,丢失了所有在线用户的上下文信息。我们将看到它如何指令gNB-CBD-01进行同步清理。
  2. gNB发起的重置:gNB-CBD-01自身发生故障并重启,丢失了所有服务的UE上下文。我们将看到它如何通知AMF-Alpha进行状态同步。

通过这两个场景,我们将理解NG Reset为何是保障5G网络鲁棒性的关键一环,以及它是如何以“壮士断腕”的方式,确保整个系统在大规模故障后能够快速恢复秩序。


1. NG Reset 流程概述 (General)

NG Reset流程是NGAP协议中用于处理异常、恢复接口状态的核心机制之一。它的启动,通常意味着一方网元已经发生了比较严重的内部故障。

1.1 流程的目标与核心作用

规范开宗明义地指出了NG Reset的目的。

8.7.4.1 General The purpose of the NG Reset procedure is to initialise or re-initialise the RAN, or part of RAN NGAP UE-related contexts, in the event of a failure in the 5GC or vice versa. This procedure does not affect the application level configuration data exchanged during, e.g., the NG Setup procedure.

这段描述包含了几个至关重要的信息点:

  1. 触发条件:5GC(核心网,主要是AMF)或RAN(接入网,即gNB)中发生了故障
  2. 操作对象UE相关的上下文。重置的目标是清理掉那些因故障而变得不一致的用户状态数据。
  3. 重置粒度:可以是整个RAN接口,也可以是部分UE相关的上下文。这意味着NG Reset支持“全局重置”和“部分重置”两种模式。
  4. 保护对象不影响应用层配置数据。这一点至关重要!NG Reset清除的是动态的、与用户会话相关的上下文(例如,UE的连接状态、PDU会话信息等),但不会影响在NG Setup流程中交换的那些静态配置信息(如gNB支持的TA列表、AMF的服务GUAMI列表等)。换言之,gNB和AMF的“工作关系”还在,只是所有“正在处理的工单”被清空了。

2. AMF发起的NG Reset (NG Reset initiated by the AMF)

当故障发生在AMF侧时,由AMF主动发起,以确保其连接的所有gNB都能同步到一致的状态。

2.1 成功操作 (Successful Operation)

这是一个由AMF发起的简单请求-响应流程,如规范中的“Figure 8.7.4.2.1-1: NG reset initiated by the AMF: successful operation”所示。

场景引入: 正在稳定运行的AMF-Alpha突然遭遇了一个严重的软件Bug,导致其进程崩溃并自动重启。重启完成后,AMF-Alpha内存中所有关于活跃UE(包括那些正由gNB-CBD-01服务的UE)的上下文信息全部丢失。此时,AMF-Alpha“失忆”了,它不知道哪些UE处于连接状态,也不知道它们的PDU会话是怎样的。

然而,在gNB-CBD-01侧,它仍然认为这些UE是正常连接的。这种状态不一致是致命的,可能会导致寻呼失败、数据无法下发等一系列问题。为了解决这个问题,AMF-Alpha必须立即向gNB-CBD-01发起NG Reset流程。

At reception of the NG RESET message the NG-RAN node shall release all allocated resources on NG and Uu related to the UE association(s) indicated explicitly or implicitly in the NG RESET message and remove the indicated UE contexts including NGAP ID.

收到NG RESET消息后,gNB的任务非常明确:无条件释放所有被指定的UE相关的资源,包括NG接口上的逻辑连接、空口上的RRC连接以及与PDU会话相关的所有资源,并删除内部的UE上下文。

完成清理后,gNB会回复NG RESET ACKNOWLEDGE消息,告知AMF重置操作已完成。

2.1.1 重置的两种粒度:全局与部分

AMF可以根据故障的影响范围,选择两种不同的重置方式。

1. 全局重置 (Global Reset / Interface Reset)

当AMF丢失了与某个特定gNB相关的所有UE上下文时,它会发起全局重置。

  • 实现方式:AMF发送的NG RESET消息中,只包含Cause IE(例如,Cause = “AMF failure”),不包含UE-associated Logical NG-connection List IE。
  • 含义:这条消息的潜台词是:“我这边关于你(gNB)的所有用户记录都没了,请你也清空所有与我这个AMF相关的UE上下文。”
  • 影响:gNB-CBD-01上所有通过此NG接口连接到AMF-Alpha的UE都将被强制断开。

2. 部分重置 (Partial Reset)

当AMF的故障只影响了部分UE的上下文时,它可以发起部分重置,以减小对业务的影响。

  • 实现方式:AMF发送的NG RESET消息中,除了Cause IE,还必须包含一个UE-associated Logical NG-connection List IE。这个列表中会明确列出需要重置的UE的标识(AMF UE NGAP ID和/或RAN UE NGAP ID)。
  • 含义:“我这边只丢失了列表中这些特定用户的上下文,请你只清理掉这些用户的连接,其他用户不受影响。”
  • 影响:只有被列入清单的UE会受到影响,其他在该gNB上的UE业务可以继续,大大降低了故障的影响范围。

If the NG RESET message is received, any other ongoing procedure (except for another NG Reset procedure) on the same NG interface related to a UE association, indicated explicitly or implicitly in the NG RESET message, shall be aborted.

NG Reset流程拥有极高的优先级。一旦gNB收到了NG RESET消息,任何与受影响UE相关的正在进行的其他流程(如切换、PDU会话修改等)都必须被立即中止


3. gNB发起的NG Reset (NG Reset initiated by the NG-RAN node)

与AMF发起的重置相对应,当故障发生在gNB侧时,由gNB主动发起重置流程。

3.1 成功操作 (Successful Operation)

这是一个镜像流程,如规范中的“Figure 8.7.4.2.2-1: NG reset initiated by the NG-RAN node: successful operation”所示。

场景引入: gNB-CBD-01的一个处理板卡出现硬件故障,导致gNB自动重启。重启后,gNB丢失了所有之前在其上服务的UE的上下文信息。此时,gNB-CBD-01也“失忆”了。而AMF-Alpha对此毫不知情,仍然认为那些UE在gNB-CBD-01上处于连接状态。

为了恢复状态一致性,gNB-CBD-01在与AMF-Alpha重新建立SCTP连接并发起NG SETUP之后(如果需要),或者在已有的SCTP连接上,会立即向AMF-Alpha发送一个NG RESET消息。

At reception of the NG RESET message the AMF shall release all allocated resources on NG related to the UE association(s) indicated explicitly or implicitly in the NG RESET message and remove the NGAP ID for the indicated UE associations.

AMF收到消息后,会释放所有被指定的、与该gNB相关的UE在核心网侧的资源,并回复NG RESET ACKNOWLEDGE

同样,gNB发起的重置也支持全局重置(清空所有与该gNB相关的UE)和部分重置(清空特定UE列表)两种模式。

3.2 异常情况与特殊场景

NG Reset是一个非常鲁棒的流程,其异常处理机制也体现了这一点。

8.7.4.3 Unsuccessful Operation Not applicable.

规范中明确指出,NG Reset没有“不成功操作”的场景。这是一个强制性的指令,接收方必须执行。如果接收方没有响应,那将被视为更底层的传输网络故障,而不是NGAP流程本身的失败。

8.7.4.4.3 Crossing of NG RESET Messages If an NG Reset procedure is ongoing in the NG-RAN node and the NG-RAN node receives an NG RESET message from the peer entity…, the NG-RAN node shall respond with the NG RESET ACKNOWLEDGE message…

这是一个有趣的场景:交叉重置。即gNB和AMF都检测到对方出现问题(或自身出现问题),同时向对方发起了NG RESET。 这种情况下,规则很简单:双方都正常处理收到的NG RESET消息,完成本地的资源清理,然后回复NG RESET ACKNOWLEDGE。最终,接口两侧的UE上下文都会被完全清空,达到状态一致的目的。


FAQ

Q1: NG Reset流程和UE Context Release流程有什么核心区别?

A1: 核心区别在于触发原因影响范围

  • UE Context Release:这是一个常规流程,用于单个UE的正常业务结束或状态转换,例如用户长时间无数据传输(User Inactivity)、切换完成、UE关机等。它是由AMF或gNB根据UE的正常行为发起的、有序的资源释放过程。可以比作“单个客户销户”。
  • NG Reset:这是一个异常恢复流程,用于在网元发生故障后进行状态同步。它可以影响单个、多个甚至全部UE。它是一个强制性的、高优先级的清理过程,会中断所有其他正在进行的流程。可以比作“系统故障后,批量清理无效账户”。

Q2: 执行一次全局NG Reset后,gNB和AMF需要重新执行NG Setup吗?

A2: 不需要。这是一个非常关键的知识点。NG Reset清除的是与UE相关的动态上下文,但并不会清除在NG Setup阶段交换的静态应用层配置数据。gNB的ID、支持的TA列表、AMF的GUAMI列表等信息在Reset后依然有效。只要底层的SCTP连接没有断开,gNB和AMF之间的“工作关系”就依然存在,它们只是清空了所有关于UE的“临时档案”,无需重新“建交”。

Q3: 当NG Reset发生时,正在通话或上网的用户会经历什么?

A3: 对于受NG Reset影响的UE来说,业务会立即中断。从UE的角度看,它的无线连接会突然丢失(Radio Link Failure),所有的数据通道(PDU会话)都会被拆除。gNB会释放所有相关的空口资源。之后,UE的NAS层会检测到连接丢失,并尝试通过发起新的RegistrationService Request流程来重新接入网络。整个体验类似于手机突然掉出服务区,然后又重新找到信号的过程。

Q4: 为什么需要“部分重置”(Partial Reset)这种更复杂的机制,而不是在任何故障时都进行全局重置?

A4: 为了最小化故障对用户业务的冲击,提升网络的可用性。一个大型的AMF可能服务于数十万甚至上百万的用户,其内部可能由多个处理单元或虚拟机组成。当其中一个处理单元发生故障时,可能只会影响该单元上承载的一部分UE的上下文。 如果此时AMF对所有连接的gNB都发起全局重置,将会导致所有用户(包括那些未受故障影响的用户)全部掉线,造成大规模的业务中断。而通过部分重置,AMF可以精确地只清理那些受故障影响的UE的状态,从而将业务中断范围控制在最小,保障了绝大多数用户的服务连续性。

Q5: 如果gNB收到了AMF发来的NG RESET,但此时正好有一个高优先级的紧急呼叫正在建立,gNB会如何处理?

A5: 根据规范的交互原则,NG Reset具有最高优先级。规范明确指出:“如果收到NG RESET消息,与该UE关联相关的任何其他正在进行的流程都应被中止。” 这意味着,即使是正在建立的紧急呼叫,如果该UE在NG RESET的影响范围内,其建立流程也会被gNB强制中止。gNB必须优先执行Reset命令以确保与AMF的状态一致性。之后,UE需要重新接入网络,才能再次发起紧急呼叫。这再次凸显了NG Reset作为一种系统级恢复机制的强制性和高优先级。