本文技术原理深度参考了3GPP TS 38.413 V18.5.0 (2025-03) Release 18规范中，关于“8.7.5 Error Indication”、“8.7.6 AMF Status Indication”、“8.7.7 Overload Start”和“8.7.8 Overload Stop”的核心章节，旨在为读者提供一个关于NG-C接口如何优雅处理协议错误、网元不可用和信令风暴等异常情况的全景视图。
深度解析 3GPP TS 38.413：8.7.5-8.7.8 异常处理与网络稳定机制
大家好，欢迎回到我们的3GPP规范深度解析系列。在之前的章节中，我们已经详细探讨了NG-C接口的“生命周期”——从NG Setup的建立，到Configuration Update的维护，再到NG Reset的灾难恢复。这些流程构成了接口管理的主干。然而，一个健壮的网络不仅要能处理好“计划内”的事件，更要能优雅地应对各种“意料之外”的状况。
今天的文章，我们将聚焦于保障NG-C接口稳定运行的“免疫系统”和“熔断机制”。当gNB和AMF之间的“对话”出现误解、一方即将“下线维护”，或者突发的大量用户接入导致信令风暴时，网络是如何应对的？
我们将引入两位新主角——经验丰富的网络监控专家Morpheus和他的新徒弟Neo。他们正在监控一个覆盖了大型跨年晚会现场的5G网络，这是一个极易出现信令拥塞和各种异常的典型场景。通过Morpheus对Neo的现场教学，我们将深入剖析以下四个关键的接口管理流程：
- 8.7.5 Error Indication (错误指示)：当gNB或AMF收到一条“看不懂”或“格式错误”的消息时，它该如何礼貌地“指出错误”而不是粗暴地中断连接？
- 8.7.6 AMF Status Indication (AMF状态指示)：当一台AMF需要进行计划内维护而下线时，它如何“优雅退场”，确保gNB能平滑地将用户引导至备用AMF？
- 8.7.7 Overload Start (过载开始)：跨年钟声敲响的瞬间，成千上万的用户同时发起呼叫和数据连接，导致AMF不堪重负。AMF如何启动“流量管制”，命令gNB限制新的接入请求？
- 8.7.8 Overload Stop (过载停止)：流量高峰过后，AMF如何通知gNB“解除警报”，恢复正常服务？
这些流程虽然不像用户业务流程那样直接面向终端，但它们是确保整个5G网络在高压和异常下依然保持稳定、可靠的关键所在。
1. Error Indication (错误指示)
在复杂的协议交互中，总有可能出现一方发送了另一方无法理解或处理的消息。Error Indication流程就是这样一个通用的、用于报告协议错误的机制。
1.1 通用流程 (General)
8.7.5.1 General The Error Indication procedure is initiated by a node in order to report detected errors in one incoming message, provided they cannot be reported by an appropriate failure message. If the error situation arises due to reception of a message utilising UE-associated signalling, then the Error Indication procedure uses UE-associated signalling. Otherwise the procedure uses non-UE associated signalling.
这段定义指出了它的核心本质：它是一个“兜底”的错误报告机制。当一个流程有专门的FAILURE消息时（例如HANDOVER PREPARATION FAILURE），应优先使用那个消息来报告功能性失败。只有当错误是协议层面的，比如消息格式不对、ID不认识，且没有更合适的失败消息时，才使用Error Indication。
场景引入：
Morpheus指着监控屏幕上的告警，对Neo说：“看，这是一个典型的协议错误。AMF-Alpha刚刚给gNB-CBD-01发了一条DOWNLINK NAS TRANSPORT消息，但它使用的RAN UE NGAP ID是一个gNB-CBD-01已经释放掉的ID。”
1.2 成功操作 (Successful Operation)
这是一个单向的通知流程，由检测到错误的一方发起。
- AMF发起的错误指示：如“Figure 8.7.5.2-1: Error indication initiated by the AMF”所示。
- gNB发起的错误指示：如“Figure 8.7.5.2-2: Error indication initiated by the NG-RAN node”所示。
8.7.5.2 Successful Operation The ERROR INDICATION message shall contain at least either the Cause IE or the Criticality Diagnostics IE. In case the Error Indication procedure is triggered by utilising UE-associated signalling the AMF UE NGAP ID IE and the RAN UE NGAP ID IE shall be included in the ERROR INDICATION message. If one or both of the AMF UE NGAP ID IE and the RAN UE NGAP ID IE are not correct, the cause shall be set to an appropriate value, e.g., “Unknown local UE NGAP ID” or “Inconsistent remote UE NGAP ID”.
ERROR INDICATION消息的核心是Cause IE和Criticality Diagnostics IE。
CauseIE：指明错误的原因，如“未知的本地UE NGAP ID”。Criticality DiagnosticsIE：更详细地指出是消息中的哪个IE、哪个部分导致了错误。- UE NGAP IDs：如果错误与特定UE相关，消息中必须携带双方的UE NGAP ID，以便对方定位问题。
场景演绎：
Neo在屏幕上看到了gNB-CBD-01发给AMF-Alpha的ERROR INDICATION消息。Morpheus解释道：“看，gNB明确告诉AMF，它不认识消息里的RAN UE NGAP ID。Cause值是‘Unknown local UE NGAP ID’。AMF收到后，就会知道这个UE的上下文可能已经不同步了，它会立即清理掉本地关于这个UE NGAP ID的所有信息，从而避免后续更多的错误。”
2. AMF Status Indication (AMF状态指示)
这是一个由AMF主动发起的，用于通知gNB其服务状态即将变为“不可用”的流程。它是实现AMF平滑维护和高可用性的关键。
2.1 通用流程 (General)
8.7.6.1 General The purpose of the AMF Status Indication procedure is to support AMF management functions. The procedure uses non UE-associated signalling.
这个流程服务于AMF的管理功能，例如计划内的软件升级或下线维护。
2.2 成功操作 (Successful Operation)
流程如图“Figure 8.7.6.2-1: AMF status indication”所示，由AMF向gNB广播其状态变化。
场景引入： Morpheus需要在跨年夜流量高峰到来之前，对AMF-Alpha进行一次关键的软件补丁升级，这需要短暂地将AMF-Alpha下线。为了不影响新用户的接入，他需要先将AMF-Alpha的服务平滑地交接给备用机AMF-Beta。
8.7.6.2 Successful Operation Upon receipt of the AMF STATUS INDICATION message, the NG-RAN node shall consider the indicated GUAMI(s) will be unavailable and perform AMF reselection as defined in TS 23.501.
AMF STATUS INDICATION消息中最重要的IE是Unavailable GUAMI List。
Unavailable GUAMI ListIE：AMF在这个列表中列出它即将停止服务的GUAMI。GUAMI是AMF的唯一标识，gNB通过它来选择AMF。
当gNB收到这个消息后，它会立即将这些GUAMI从其“可选AMF列表”中标记为不可用。对于之后发起初始接入且没有携带有效GUAMI的UE，gNB将不会再选择这个“即将下线”的AMF。
If the
Backup AMF NameIE is included in the AMF STATUS INDICATION message, the NG-RAN node shall, if supported, perform AMF reselection considering the AMF as indicated by the Backup AMF Name IE…
Backup AMF NameIE：更进一步，AMF可以在通知自己不可用的同时，明确指定一个“接替者”（备用AMF）。gNB收到后，在进行AMF重选时，会优先考虑这个备用AMF。
场景演绎：
Morpheus在AMF-Alpha上触发了AMF STATUS INDICATION流程。gNB-CBD-01收到了这条消息，内容是：“我（AMF-Alpha）所服务的GUAMI列表[…]即将不可用，请将新用户引导至我的备用AMF——AMF-Beta。”
Neo观察到，从这一刻起，gNB-CBD-01的监控界面上，所有新UE的初始接入请求都被路由到了AMF-Beta，而AMF-Alpha则不再接收任何新的连接。Morpheus解释说：“这样，我们就可以等待AMF-Alpha上现有的会话自然结束，然后安全地进行升级，整个过程对新用户完全透明。”
3. Overload Control (过载控制)
这是5G网络面对“信令风暴”时的核心防御机制。当AMF因处理能力达到上限而无法响应新的请求时，它会启动过载控制，主动要求gNB进行前端的“限流”。
3.1 Overload Start (过载开始)
8.7.7.1 General The purpose of the Overload Start procedure is to inform an NG-RAN node to reduce the signalling load towards the concerned AMF.
场景引入： 跨年钟声即将敲响，晚会现场成千上万的用户同时举起手机，发送新年祝福、开启视频直播。海量的RRC连接请求瞬间涌向gNB-CBD-01，并被转发至AMF-Alpha。AMF-Alpha的CPU使用率瞬间飙升至99%。
为了防止系统崩溃，AMF-Alpha的过载控制模块被触发，它立即向gNB-CBD-01发送OVERLOAD START消息，如图“Figure 8.7.7.2-1: Overload start”所示。
8.7.7.2 Successful Operation If the Overload Action IE is included the AMF Overload Response IE within the OVERLOAD START message, the NG-RAN node shall use it to identify the related signalling traffic.
OVERLOAD START消息的核心是**Overload Action IE**，它定义了gNB需要采取的“限流”策略。规范定义了多种粒度的拒绝行为：
"reject RRC connection establishments for non-emergency mobile originated data transfer"：这是最轻量级的管制。AMF指示gNB：“拒绝那些因为用户想上网、发消息而发起的新的RRC连接请求（mo-data），但紧急呼叫（emergency）和别人打给用户的呼叫（mt-Access）还是要放行。”"reject RRC connection establishments for signalling"：管制升级。AMF说：“除了上面的，连那些为了位置更新等信令目的发起的连接（mo-signalling）也给我拒掉。”"only permit RRC connection establishments for emergency sessions and mobile terminated services"：最高级别的管制。AMF指示：“情况紧急，只允许紧急呼叫和被叫业务接入，其他所有主动发起的连接请求一律拒绝！”
此外，AMF还可以进行更精细的控制：
AMF Traffic Load Reduction IndicationIE：AMF可以要求gNB按百分比进行限流，例如“拒绝10%的新接入请求”。Overload Start NSSAI ListIE：AMF可以实现基于切片的过载控制。例如，如果只有处理eMBB业务的模块过载，AMF可以只要求gNB拒绝发往eMBB切片的新请求，而保障URLLC切片的业务不受影响。
场景演绎：
AMF-Alpha向gNB-CBD-01发送了OVERLOAD START消息，Overload Action设置为“只允许紧急和被叫业务”。Neo看到，gNB-CBD-01开始在其空口上拒绝大部分新的RRC连接请求。Morpheus解释说：“这就是网络的自我保护。与其让所有请求都涌到AMF导致系统崩溃，不如在接入侧就进行拦截，虽然部分用户体验受损，但保证了核心网络的存活和高优先级业务的畅通。”
3.2 Overload Stop (过载停止)
8.7.8.1 General The purpose of the Overload Stop procedure is to signal to an NG-RAN node the AMF is connected to that the overload situation at the AMF has ended and normal operation shall resume.
当流量高峰过去，AMF的负载恢复正常后，它会发送OVERLOAD STOP消息（如图“Figure 8.7.8.2-1: Overload stop”所示）来“解除警报”。gNB收到后，就会停止之前的限流策略，恢复对所有新连接请求的正常处理。
场景演绎：
跨年高峰过去几分钟后，AMF-Alpha的负载回落到正常水平。它自动向gNB-CBD-01发送了OVERLOAD STOP消息。Neo看到，gNB的RRC连接拒绝率立即降为零，网络恢复了正常服务。
FAQ
Q1: NG Reset和AMF STATUS INDICATION都会导致gNB不再向某个AMF发送新业务，它们有什么区别？
A1: 尽管结果相似，但它们的起因、目的和后续行为完全不同。
NG Reset是事后补救。它发生在AMF已经发生故障并“失忆”之后。它的目的是强制清理双方不一致的UE上下文。收到Reset后，gNB不仅停止为新UE选择该AMF，还会立即释放所有已存在的与该AMF相关的UE连接。AMF STATUS INDICATION是事前通知。它发生在AMF计划下线之前。它的目的是实现服务的平滑迁移。收到Status Indication后，gNB只是停止为新UE选择该AMF，但并不会立即释放已存在的连接，而是等待它们自然结束或通过切换等方式迁移走。
Q2: 如果gNB收到了AMF的OVERLOAD START指令，它具体是如何“拒绝”UE的接入请求的？
A2:
gNB会在RRC层面上拒绝UE的连接请求。当一个UE发起RRC连接建立过程时，它会在RRCSetupRequest消息中携带一个establishmentCause（建立原因），例如mo-data、mo-signalling、emergency等。gNB在收到OVERLOAD START消息后，会根据其中Overload Action的指示，检查新接入UE的establishmentCause。如果该原因属于被拒绝的类别，gNB就会向UE回复RRCSetupReject消息，从而在空口早期就拒绝了该接入，避免了信令被送往已经过载的AMF。
Q3: AMF的过载控制只针对信令面吗？对用户的数据传输（用户面）有影响吗？
A3:
OVERLOAD START流程本身是NG-C接口（信令面）的流程，它直接控制的是新的RRC连接建立请求，也就是信令面的接入。对于那些已经处于RRC_CONNECTED状态的用户，他们的用户面数据传输不会因为这个流程而直接中断。但是，信令面的拥塞最终会间接影响用户面。例如，如果一个处于连接态的用户需要发起切换，或者修改PDU会话的QoS，这些都需要信令交互。如果AMF过载，这些信令处理的延迟会变得非常高，从而可能导致切换失败、业务质量下降等问题。
Q4: 如果gNB没有收到OVERLOAD STOP消息（例如消息丢失），它会一直处于“限流”状态吗？
A4:
不会。这是一个很好的问题，体现了协议设计的鲁棒性。通常，AMF在过载期间，会周期性地重新发送OVERLOAD START消息。gNB侧会维护一个与过载状态关联的定时器。每次收到OVERLOAD START消息，gNB就重置这个定时器。如果定时器超时，而gNB没有收到新的OVERLOAD START消息，它就会自动认为过载状态已经结束，并恢复正常运行。这种机制确保了即使OVERLOAD STOP消息丢失，网络也能在一段时间后自动恢复，避免了被“锁死”在过载状态。
Q5: gNB能否对AMF的过载指示提出异议或忽略它？
A5:
不能。OVERLOAD START是一个强制性指令。从AMF的角度看，它已经处于或即将处于不稳定状态，继续接收新的信令请求可能会导致整个服务崩溃。因此，gNB作为接入侧的执行单元，必须严格遵守AMF的过载策略。忽略这个指令会导致过载情况恶化，最终可能引发更大范围的网络故障。这体现了核心网在网络控制中的权威性。