好的，我们继续跟随5-G基站工程师小雷，深入探索NG接口上那些保障网络稳健运行和资源高效利用的关键流程。这一次，我们将再次聚焦于一个看似简单，实则对网络性能和信令负载影响深远的话题——过载控制流程。

深度解析 3GPP TS 38.410：6.13 Overload Control procedures (过载控制流程)

本文技术原理深度参考了3GPP TS 38.410 V18.2.0 (2024-06) Release 18规范中，关于“6.13 Overload Control procedures”的核心章节，并结合其在NGAP协议（TS 38.413）中的具体实现，为读者完整呈现5G网络中，核心网AMF与基站gNB之间，在面对信令过载时，是如何通过NG接口进行“告警”与“解-警”的。

引言：从“功能描述”到“泄压阀”的实操

在之前的5.19节解读中，我们已经从“功能”的视角，理解了过载控制“是什么”——它是一套“智能熔断与预警系统”，允许不堪重负的网络节点（gNB或AMF），向上游节点请求“减负”，以实现自我保护。

现在，我们将进入6.13节，从“流程”的视角，深入探索这套“泄压阀”是“怎么做”的。6.13节将5.19节的功能定义，分解为两个方向相反、逻辑清晰的NGAP信令流程。它不再是高层的概念描述，而是AMF与gNB在面对信令风暴时，那本简洁而高效的“紧急制动手册”。

本篇文章，我们将聚焦于6.13节所定义的“一启一停”两大核心流程，通过模拟AMF过载的场景，详细拆解**过载的启动（Overload Start）和过载的停止（Overload Stop）**全过程。

---

1. 流程的“剧本”：过载控制的“拉闸”与“合闸”

6.13 Overload Control procedures

The following procedures are used by the AMF to start or stop overload control:

• Overload Start;
• Overload Stop.

6.13节为我们定义了由AMF发起的过载控制的“流程二人组”：

1. Overload Start (过载启动): AMF向gNB拉响“红色警报”，请求gNB协助“限流”。
2. Overload Stop (过载停止): AMF向gNB发出“警报解除”，通知gNB恢复正常流量。

值得注意的是，38.410的6.13节只描述了AMF发起的过载控制。实际上，我们在5.19节的解读中知道，gNB也会发起过载控制。gNB发起的过载控制，其流程名称在NGAP协议中是相同的（OVERLOAD START/STOP），只是方向相反（gNB → AMF）。本篇我们严格遵循6.13节的范畴，聚焦于AMF侧的视角。

---

2. “红色警报”：Overload Start Procedure

这是AMF在感知到自身即将不堪重负时，采取的主动防御措施。

NGAP Procedure: Overload Start (AMF Initiated)

实战演练（一）：核心网的“信令拥堵”

• 触发: 由于邻近区域网络大面积故障，海量用户漫游涌入，导致AMF-01的CPU占用率飙升至95%。AMF-01的过载控制模块被激活。

• AMF → gNB (OVERLOAD START):

  • 流程启动！ AMF-01立即向所有与它连接的gNB（包括小雷的gNB）广播一条OVERLOAD START消息。
  • 消息内容（“限流通知单”）:
    • AMF Overload Response IE: 最重要的部分。AMF会在这里明确告知gNB，希望gNB如何配合“限流”。常见的策略有：
      • reject-rrc-cr-signalling: AMF请求gNB：“请拒绝所有非紧急、非高优先级的新用户（IDLE态UE）发起的、并且打算路由给我的接入请求。”
      • permit-emergency-sessions-and-high-priority-sessions-only: 更严厉的策略，AMF请求gNB：“只放行那些紧急业务和高优先级的接入请求过来，其他的都拦住。”
    • AMF Traffic Load Reduction Indication IE (可选): AMF可以给出一个更具体的“降压”建议，例如10%，意味着“请将发往我这里的初始接入信令流量，在现有基础上减少10%。”
    • Overload Start NSSAI List IE (可选): 如果过载只发生在某个特定的网络切片上，AMF可以在这里指明，请求gNB只针对该切片的流量进行限制。

• gNB的响应动作:

  • 小雷的gNB收到了来自AMF-01的这份“限流通知单”。
  • gNB的**NAS节点选择功能（5.7节）**立即做出调整。
  • 对于一个新接入的、没有指定AMF的UE，gNB在做路由选择时，会极大地降低甚至完全避免选择AMF-01。它会优先将流量引向AMF Pool中其他健康的AMF（如AMF-02, AMF-03）。
  • 如果一个UE因为GUTI的原因，必须被路由到AMF-01，gNB会检查AMF要求的Overload Action。如果UE的接入请求不属于“紧急”或“高优先级”，gNB甚至可能会在本地就直接拒绝这次接入，而根本不向AMF-01转发INITIAL UE MESSAGE，从而从源头上为AMF-01“挡掉”了信令冲击。

• 这是一个**Class 2 (无响应)**的流程。gNB在收到并开始执行限流策略后，无需向AMF回复一个“收到”的响应。

---

3. “警报解除”：Overload Stop Procedure

当AMF的负载高峰过去，恢复到正常水平时，它需要及时通知所有gNB“解除限流”。

NGAP Procedure: Overload Stop (AMF Initiated)

实战演练（二）：拥堵缓解，恢复常态

• 触发: 随着网络故障的恢复和用户疏散，AMF-01的CPU占用率回落到安全水平。

• AMF → gNB (OVERLOAD STOP):

  • 流程启动！ AMF-01立即向所有之前收到过OVERLOAD START的gNB，广播一条OVERLOAD STOP消息。
  • 消息内容: 这条消息非常简单，其核心就是宣告“警报解除”。它可以选择性地包含之前过载的NSSAI List，以实现切片级的“解-警”。

• gNB的响应动作:

  • 小雷的gNB收到了“警报解除”通知。
  • 它会立即在其NAS节点选择功能中，将AMF-01恢复到正常的权重。
  • 对于后续新接入的UE，gNB又会开始按照负载均衡的原则，将一部分流量正常地分配给AMF-01。
  • 这也是一个**Class 2 (无响应)**的流程。

---

总结：从“各自为战”到“上下游联动”的流量调控

通过对6.13节核心流程的深度剖析，我们看到了5G网络在应对核心网信令过载时，所设计的上下游联动的智慧。

• 清晰的告警与恢复机制: Overload Start和Overload Stop这一对“开关”流程，为AMF与gNB之间，建立了一个清晰、明确、高效的过载状态同步通道。
• 智能下沉到RAN: 过载控制的最终执行点，被巧妙地放在了gNB的NAS节点选择功能上。这使得“限流”的动作，发生在信令风暴的源头——UE初始接入的第一跳，效率最高，效果最好。
• 精细化的控制粒度: 支持基于业务优先级和基于网络切片的差异化过载控制，实现了“精准熔断”，在保护网络的同时，最大限度地保障了高价值业务的连续性。

对于基站工程师小雷来说，监控OVERLOAD START消息，是他判断核心网“健康状况”的重要晴雨表。当他看到这条消息时，他知道核心网的某个“入口”正在经历“交通拥堵”。他需要关注他gNB的NAS节点选择功能是否正确地执行了“绕行”策略，并将流量智能地引导到了其他通畅的“入口”。这套自动化的“上游预警 + 本地绕行”机制，共同构成了5G网络控制面强大的弹性和自愈能力。