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解析。

图表 1
设计意图:三层防御遵循"先拦截、后拒绝、再疏散"的原则。第一层在无线侧就拦截不必要的信令(效率最高),第二层在NAS层精确拒绝特定类型的请求(粒度更细),第三层将已注册UE迁移到其他AMF(长期均衡)。
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连接被占满 |
当AMF检测到过载条件满足时,向所连接的所有gNB发送OVERLOAD START NGAP消息(非UE关联的信令过程)。这是AMF过载控制中效率最高的一层——直接在无线侧拦截信令,避免过载消息进入核心网。

图表 2
根据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不必一次性拒绝所有流量,而是可以逐步调节:
这是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 | 保障紧急呼叫 |
当AMF过载条件解除时,发送OVERLOAD STOP消息通知gNB恢复正常处理。其ASN.1结构非常简洁:
OverloadStop ::= SEQUENCE {
protocolIEs ProtocolIE-Container {{OverloadStopIEs}}
}
关键行为:如果gNB在过载期间收到新的OVERLOAD START消息,必须替换(而非叠加)之前收到的过载控制信息。
当NGAP层面的过载控制不足以缓解AMF负载时,AMF会在NAS层直接拒绝UE的请求,并携带退避定时器。

图表 3
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 | 请求的切片全部被拒 |
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有充足恢复时间
TS 24.501 Section 5.5.1.2.5定义了通用NAS层移动性管理拥塞控制机制。AMF可以维护一个拥塞控制列表,按以下维度进行差异化控制:

图表 4
实用场景:当某个特定切片(如MIoT切片)下的设备产生信令风暴时,AMF可以只对该切片激活拥塞控制,而不影响eMBB和VoNR用户的正常使用。
当AMF持续处于高负载状态时,可以将已注册的UE迁移到AMF Pool中的其他AMF。这是最温和也最优雅的过载控制手段。

图表 5
负载重平衡依赖于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
根据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%以上。

图表 7
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)
| 故障现象 | 可能原因 | 排查思路 |
|---|---|---|
| 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实例。
本文由「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 等场景全覆盖。
