<!-- title: 5G AMF过载控制三层防御机制深度解析 -->
<!-- domain: core-network -->

# 5G AMF过载控制三层防御机制深度解析：从NGAP到NAS的全链路信令流分析

## 一、引言：为什么AMF过载控制是5GC的生死线

AMF（Access and Mobility Management Function）是5G核心网控制面的中枢网元，承担NAS信令终结、注册管理、连接管理和移动性管理等核心职责。当大规模信令冲击发生时——无论是百万级IoT设备批量上线、突发事件引发信令风暴，还是网络故障导致批量UE重连——AMF首当其冲。

与4G MME相比，5G AMF面临的挑战更为严峻：网络切片引入了差异化SLA保障需求，SBI（Service Based Interface）架构使NF间耦合更紧密，一个AMF过载可能引发SMF、PCF、UDM的级联故障。3GPP从Rel-15开始就为AMF设计了**三层防御体系**：N2接口层（NGAP Overload控制）、N1接口层（NAS拥塞控制）和NF间层（NRF负载重平衡）。

本文将深入解析TS 23.501 Section 5.19.5.2、TS 38.413 Section 8.7、TS 24.501 Section 5.5等核心章节中定义的具体机制，并给出完整的信令时序图和IE解析。

## 二、AMF过载控制总体架构

### 2.1 三层防御体系


![图表1](images/telecom-3gpp-1531-mermaid-0.png)

> *图表 1*


**设计意图**：三层防御遵循"先拦截、后拒绝、再疏散"的原则。第一层在无线侧就拦截不必要的信令（效率最高），第二层在NAS层精确拒绝特定类型的请求（粒度更细），第三层将已注册UE迁移到其他AMF（长期均衡）。

### 2.2 过载检测触发条件

AMF过载检测通常基于以下量化参数（TS 23.501 Section 5.19.5.2）：

| 检测维度 | 典型阈值 | 说明 |
|---------|---------|------|
| CPU利用率 | >80% | 持续超过阈值触发过载 |
| NAS消息队列深度 | >配置值 | 待处理NAS消息堆积 |
| N2接口消息速率 | >配置值 | 来自gNB的Initial UE Message速率 |
| 内存使用率 | >85% | UE Context占用内存 |
| NF Service响应时延 | >配置值 | SBI调用UDM/PCF响应超时 |
| SBI连接池耗尽 | 连接池空 | HTTP/2连接被占满 |

## 三、第一层防御：NGAP Overload控制（TS 38.413 Section 8.7）

### 3.1 OVERLOAD START消息解析

当AMF检测到过载条件满足时，向所连接的所有gNB发送**OVERLOAD START** NGAP消息（非UE关联的信令过程）。这是AMF过载控制中效率最高的一层——直接在无线侧拦截信令，避免过载消息进入核心网。


![图表2](images/telecom-3gpp-1531-mermaid-1.png)

> *图表 2*


### 3.2 OVERLOAD START消息关键IE

根据TS 38.413 Section 8.7.2.1，OVERLOAD START消息包含以下关键Information Element：

| IE名称 | 是否必选 | 取值范围 | 说明 |
|--------|---------|---------|------|
| **AMF Overload Response** | 必选(M) | 3种枚举值 | 决定gNB如何响应过载 |
| **Traffic Load Reduction Indication** | 可选(O) | 0~100%（步长1%） | 指示gNB减少的流量百分比 |
| **Overload Start NSSAI List** | 可选(O) | S-NSSAI列表 | 按切片进行差异化过载控制 |

**AMF Overload Response**的三种取值及其含义：

| 枚举值 | 含义 | gNB行为 |
|--------|------|---------|
| `reject-all-new-sessions` | 拒绝所有新会话 | 拒绝所有非紧急的RRC连接建立 |
| `reject-non-emergency-sessions` | 拒绝非紧急会话 | 允许紧急呼叫和高优先级接入 |
| `permit-emergency-sessions-only` | 仅允许紧急会话 | 仅允许AMF指示的特定接入类别 |

**Traffic Load Reduction Indication**的设计精妙之处在于，它允许AMF进行**渐进式过载控制**。AMF不必一次性拒绝所有流量，而是可以逐步调节：

- 轻度过载：Traffic Load Reduction = 30%，gNB随机拒绝30%的新连接请求
- 中度过载：Traffic Load Reduction = 60%
- 重度过载：Traffic Load Reduction = 100%（等效于reject-all）

### 3.3 Overload Start NSSAI List：切片感知的过载控制

这是Rel-16引入的重要增强。AMF可以按切片维度进行差异化过载控制，保障高优先级切片（如URLLC）的业务不受影响：

| 切片类型 | S-NSSAI | 过载策略 | 设计理由 |
|---------|---------|---------|---------|
| eMBB（普通用户） | 010001 | reject-all-new-sessions | 可延迟，用户容忍度高 |
| URLLC（工业控制） | 020002 | 不过载 | SLA要求严格，不可中断 |
| MIoT（物联网） | 030003 | reject-all + Load Reduction 80% | 设备量大，可延迟重连 |
| VoNR（IMS语音） | 040004 | permit-emergency-only | 保障紧急呼叫 |

### 3.4 OVERLOAD STOP消息

当AMF过载条件解除时，发送**OVERLOAD STOP**消息通知gNB恢复正常处理。其ASN.1结构非常简洁：

```
OverloadStop ::= SEQUENCE {
    protocolIEs  ProtocolIE-Container {{OverloadStopIEs}}
}
```

**关键行为**：如果gNB在过载期间收到新的OVERLOAD START消息，必须**替换**（而非叠加）之前收到的过载控制信息。

## 四、第二层防御：NAS层拥塞控制（TS 24.501 Section 5.5）

### 4.1 NAS层拥塞控制触发流程

当NGAP层面的过载控制不足以缓解AMF负载时，AMF会在NAS层直接拒绝UE的请求，并携带退避定时器。


![图表3](images/telecom-3gpp-1531-mermaid-2.png)

> *图表 3*


### 4.2 NAS拒绝消息中的关键IE

AMF在拒绝NAS请求时使用的核心IE如下（TS 24.501 Section 8.2.9.1）：

| IE名称 | 类型 | 说明 |
|--------|------|------|
| **5GMM Cause** | 必选 | 拒绝原因值，拥塞场景通常使用#22 |
| **T3346 GPRS Timer** | 条件选填 | 移动性管理退避定时器 |
| **T3346 GPRS Timer 3** | 条件选填 | 增强版退避定时器（Rel-17+） |
| **Rejected NSSAI** | 条件选填 | 被拒绝的切片列表 |
| **EAP message** | 条件选填 | EAP认证场景使用 |

**5GMM Cause值与拥塞控制的对应关系**：

| Cause值 | 名称 | 典型使用场景 |
|---------|------|-------------|
| #9 | UE身份不能被网络派生 | UDM不可达导致 |
| #18 | Serving节点拥塞 | AMF本地过载 |
| #22 | 拥塞 | 通用NAS层拥塞控制 |
| #27 | 缺少DNN | S-NSSAI对应DNN不可用 |
| #72 | 不允许的NSSAI | 请求的切片全部被拒 |

### 4.3 T3346定时器：退避时间的精确控制

T3346是5GMM退避定时器，其取值编码遵循GPRS Timer 3格式（TS 24.501 Section 9.11.2.9）：

| 定时器值编码 | 含义 | 精度 |
|-------------|------|------|
| 二进制0000 | 0秒（即不使用定时器） | - |
| 二进制0001-0010 | 2秒 × 编码值 | 2秒步长 |
| 二进制0011-0111 | 60秒 × (编码值-2) | 分钟步长 |
| 二进制1000-1011 | 360秒 × (编码值-7) | 6分钟步长 |
| 二进制1100-1110 | 3600秒 × (编码值-11) | 小时步长 |
| 二进制1111 | UE自行随机选择退避时间 | - |

**设计意图**：为什么需要如此复杂的定时器编码？因为在不同拥塞程度下，AMF需要精确控制退避时间：
- 轻度拥塞：T3346 = 30s，让UE快速重试
- 中度拥塞：T3346 = 300s（5分钟），显著降低信令速率
- 重度拥塞：T3346 = 7200s（2小时），让AMF有充足恢复时间

### 4.4 基于NSSAI/DNN/UE Group的差异化拥塞控制

TS 24.501 Section 5.5.1.2.5定义了**通用NAS层移动性管理拥塞控制**机制。AMF可以维护一个拥塞控制列表，按以下维度进行差异化控制：


![图表4](images/telecom-3gpp-1531-mermaid-3.png)

> *图表 4*


**实用场景**：当某个特定切片（如MIoT切片）下的设备产生信令风暴时，AMF可以只对该切片激活拥塞控制，而不影响eMBB和VoNR用户的正常使用。

## 五、第三层防御：AMF负载重平衡（TS 23.502 Section 4.2.2.2.3）

### 5.1 AMF负载重平衡流程

当AMF持续处于高负载状态时，可以将已注册的UE迁移到AMF Pool中的其他AMF。这是最温和也最优雅的过载控制手段。


![图表5](images/telecom-3gpp-1531-mermaid-4.png)

> *图表 5*


### 5.2 AMF Set与AMF Region的概念

负载重平衡依赖于AMF Pool（AMF Set）架构：

| 概念 | 定义 | 关系 |
|------|------|------|
| **AMF Region** | 一个或多个AMF Set的集合 | 最大的管理域 |
| **AMF Set** | 功能等价的AMF集合 | 同Set内AMF可互为备份 |
| **GUAMI** | Globally Unique AMF ID | 精确标识UE所注册的AMF |
| **AMF Pointer** | GUAMI中的低位比特 | 用于Set内负载均衡 |

AMF负载重平衡的关键在于：源AMF通过修改UE的5G-GUTI中的GUAMI，将UE"引导"到目标AMF。gNB在收到UE的后续请求时，根据GUAMI路由到目标AMF。

## 六、三层防御的协同工作机制

### 6.1 过载控制状态机


![图表6](images/telecom-3gpp-1531-mermaid-5.png)

> *图表 6*


### 6.2 三层防御的性能对比

根据IEEE论文《Congestion Control by Mobile Core and RAN Coordination in 5G Mobile Network》（IEEE WCNC 2023）的分析数据，不同过载控制层的效果差异显著：

| 控制层级 | 生效延迟 | 信令拦截率 | UE影响范围 | 粒度 |
|---------|---------|-----------|-----------|------|
| **NGAP Overload** | <100ms | 70-90% | 小区内所有UE | 粗（小区级） |
| **NAS拥塞控制** | 1-3s | 40-70% | 特定NSSAI/DNN/UE组 | 中（切片/用户组级） |
| **AMF负载重平衡** | 30-120s | 逐UE迁移 | 迁移的UE个体 | 细（UE级） |

实测数据显示：在百万级IoT设备批量上电场景下，**三层协同防御**相比仅使用单层控制，AMF的CPU峰值利用率可降低约35-45%，信令处理成功率从约60%提升至约95%以上。

### 6.3 三层防御协同时序


![图表7](images/telecom-3gpp-1531-mermaid-6.png)

> *图表 7*

## 七、抓包识别与故障排查

### 7.1 Wireshark抓包识别

**NGAP OVERLOAD START消息**的抓包特征：

```
NGAP ::= NGAP-PDU
  initiatingMessage
    procedureCode: 17 (id-OverloadStart)
    value: OverloadStart
      protocolIEs
        AMFOverloadResponse  -- 核心IE
          reject-all-new-sessions / reject-non-emergency-sessions / permit-emergency-sessions-only
        TrafficLoadReductionIndication  -- 可选，0~100
        OverloadStartNSSAIList  -- 可选，按切片控制
```

**NAS Registration Reject**的抓包特征：

```
5GS Mobility Management
  Message Type: Registration Reject (0x44)
  5GMM Cause: 0x16 (22) - Congestion
  T3346 GPRS Timer 3
    Unit: 0 (2 second multiples)
    Timer Value: 150 (300 seconds)
```

### 7.2 常见故障点

| 故障现象 | 可能原因 | 排查思路 |
|---------|---------|---------|
| UE反复Registration Reject | T3346定时器过短 | 检查AMF配置的T3346是否合理，建议轻度>30s，重度>300s |
| gNB不执行Overload控制 | OVERLOAD START消息未到达 | 检查N2接口SCTP连接状态，确认AMF与gNB的NGAP版本匹配 |
| 高优先级切片被误拒 | NSSAI List配置错误 | 检查Overload Start NSSAI List中各切片的overload response |
| 负载重平衡后UE掉线 | GUAMI路由配置不一致 | 确认gNB的AMF Set配置与新AMF的GUAMI一致 |
| Overload Stop后仍拒绝 | gNB缓存了旧的Overload状态 | 检查OVERLOAD STOP是否正确发送，gNB是否正确处理 |
## 八、5G与4G过载控制对比

| 机制 | 4G MME | 5G AMF | 增强点 |
|------|--------|--------|--------|
| N2/N2接口过载 | S1AP Overload Start | NGAP Overload Start | 新增NSSAI维度切片感知 |
| NAS拥塞控制 | EMM Cause #22 + T3402 | 5GMM Cause #22 + T3346 | 支持NSSAI/DNN/UE Group粒度 |
| 负载重平衡 | MME Pool内迁移 | AMF Set内迁移 | 引入AMF Region/Set层级 |
| SBI过载保护 | N/A（无SBI） | HTTP/2流控+限流 | 全新机制 |
| NF状态通知 | N/A | NRF通知订阅 | 自动化的NF健康监控 |

## 九、常见问题

**Q1: OVERLOAD START和NAS拥塞控制是互斥的吗？**
A: 不是。它们可以同时激活，形成分层防御。NGAP Overload在RAN侧粗粒度拦截，NAS拥塞控制在核心网侧细粒度拒绝。实际部署中通常先启动NAS拥塞控制（更精确），当负载持续上升再叠加NGAP Overload（更高效）。

**Q2: T3346定时器到期后UE立即重试，会不会造成二次拥塞？**
A: 3GPP设计了防护机制。TS 24.501规定：当UE收到带有T3346的拒绝后，UE应在定时器值的基础上叠加一个随机抖动（randomization factor），避免大量UE在完全相同的时刻重试。此外，AMF可以在T3346到期前主动发起Configuration Update Command来提前恢复UE的注册。

**Q3: AMF负载重平衡会不会导致UE业务中断？**
A: TS 23.502 Section 4.2.2.2.3定义的负载重平衡过程是无缝的。源AMF通过Configuration Update Command修改UE的GUTI，UE发起mobility registration更新到新AMF。在整个过程中，UE的PDU Session保持不中断，数据面流量通过UPF继续转发。

**Q4: AMF如何避免OVERLOAD START消息本身的丢失？**
A: NGAP Overload Start使用SCTP传输层，SCTP提供可靠传输保证。如果SCTP关联正常，OVERLOAD START消息不会丢失。但如果AMF与gNB之间的SCTP连接本身已经中断，则AMF应通过其他手段（如NAS层直接拒绝）来执行过载控制。

**Q5: 在AMF Pool部署中，单个AMF过载时其他AMF如何感知？**
A: 通过NRF（Network Repository Function）。每个AMF定期向NRF更新自身的负载状态（Nnrf_NFManagement_NFUpdate），NRF将负载变化通知订阅者。其他AMF在选择目标AMF进行负载重平衡时，会查询NRF获取负载最低的AMF实例。

## 参考来源

1. [3GPP TS 23.501 V18.x.x](https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3144) — Section 5.19.5.2: AMF Overload Control
2. [3GPP TS 38.413 V18.6.0](https://www.etsi.org/deliver/etsi_ts/138400_138499/138413/18.06.00_60/ts_138413v180600p.pdf) — Section 8.7: Overload Control
3. [3GPP TS 24.501 V18.x.x](https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3175) — Section 5.5: NAS Congestion Control
4. [Congestion Control by Mobile Core and RAN Coordination in 5G Mobile Network](https://ieeexplore.ieee.org/document/10199592) — IEEE WCNC 2023, 核心网与RAN协同拥塞控制性能分析
5. [On the scalability of 5G Core network: the AMF case](https://inria.hal.science/hal-01657667/document) — INRIA研究报告, AMF可扩展性与信令负载分析

---
> 本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵**爱卫生**（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。
> 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。

> [!tip] 51学通信知识星球
> **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。
> **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。
> **当前规模**：5200 篇主题 / 990 个回答，198 元/年。
> **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。
> **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。

![51学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)