AMF（Access and Mobility Management Function）是5G核心网的"咽喉要道"——所有UE的注册、移动性管理、寻呼、N2信令都必须经过它。当信令风暴来袭（如海量终端同时注册、区域性灾害触发批量重 attach），AMF率先过载。3GPP为AMF设计了三径过载控制机制：N2/NGAP推流、NAS拥塞拒绝、SBI/NRF负载重分配。本文基于TS 23.501 V18.x Section 5.19、TS 23.502 V18.x Section 4.2.5、TS 38.413 V18.x Section 8.28/8.29，逐信令拆解这三条路径的博弈逻辑。
AMF过载并非凭空判断。TS 23.501 Section 5.19.5.2定义了AMF应监控以下指标：
| 指标类别 | 具体参数 | 典型触发门限 |
|---|---|---|
| CPU利用率 | AMF进程CPU占用率 | >80%持续N秒 |
| 内存占用 | NAS上下文存储使用率 | >75% |
| NAS消息队列深度 | 待处理NAS消息积压数 | >阈值 |
| N2连接数 | 活跃N2 UE关联数 | 接近License上限 |
| 数据库响应时延 | UDR/UDM查询RTT | >基线200% |
| 信令速率 | 每秒处理的NAS/NGAP消息数 | 超过处理能力 |
AMF通常实现多级过载状态（如Normal/Minor/Major/Critical），不同级别触发不同强度的控制动作。
stateDiagram-v2
[*] --> Normal: 系统启动
Normal --> Minor: CPU>70% 或 NAS队列>阈值1
Minor --> Normal: 指标回落持续T1
Minor --> Major: CPU>85% 或 NAS队列>阈值2
Major --> Minor: 指标回落持续T2
Major --> Critical: CPU>95% 或 内存>90%
Critical --> Major: 指标回落持续T3
state Normal {
note right of Normal: 正常处理所有信令
}
state Minor {
note right of Minor: NGAP Overload Start(轻度)<br/>拒绝Delay Tolerant接入
}
state Major {
note right of Major: NGAP Overload Start(中度)<br/>拒绝非紧急+NAS Backoff<br/>更新NRF负载
}
state Critical {
note right of Critical: NGAP Overload Start(重度)<br/>仅允许紧急呼叫<br/>停止接受新注册
}
当AMF进入过载状态，它通过NGAP Overload Start消息通知所连接的gNB减少信令负载。这是最直接、最有效的过载控制手段——在RAN侧就拦截多余信令，不让其进入核心网。
OVERLOAD START消息的关键IE：
| IE名称 | 必选/可选 | 说明 |
|---|---|---|
| AMF Overload Response | 必选 | 指示gNB应采取的过载动作 |
| Overload Additional Traffic Reduction List | 可选 | 按流量类别指定削减百分比 |
| Traffic Category | 条件必选 | delay-tolerant / non-delay-tolerant |
| Overload Reduction Factor | 条件必选 | 削减百分比（0~100） |
| List of Overload Plmn Traffic | 可选 | 按PLMN粒度控制 |
| List of Overload S-NSSAI Traffic | 可选 | 按切片粒度控制 |
AMF Overload Response的4种动作等级：
| 取值 | 动作描述 | 典型触发场景 |
|---|---|---|
| 0 | 拒绝所有非紧急的RRC连接请求（紧急和高优先级除外） | Critical过载 |
| 1 | 拒绝所有非紧急和移动终结服务的RRC连接请求（仅保留紧急） | Critical过载升级 |
| 2 | 拒绝延迟容忍接入的RRC连接请求 | Minor过载 |
| 3 | 不拒绝但停止向该AMF发送NAS Level的小区广播 | 轻度优化 |
sequenceDiagram
participant AMF
participant gNB1
participant gNB2
participant UE1 as UE(延迟容忍)
participant UE2 as UE(紧急呼叫)
participant UE3 as UE(普通注册)
Note over AMF: 检测到过载<br/>CPU>85%, NAS队列积压
AMF->>gNB1: NGAP OVERLOAD START<br/>Overload Response=2(拒绝延迟容忍)<br/>Traffic Category=delay-tolerant<br/>Reduction Factor=60%
AMF->>gNB2: NGAP OVERLOAD START<br/>Overload Response=0(拒绝非紧急)<br/>List of S-NSSAI: 切片A
Note over gNB1: 开始按60%概率<br/>拒绝delay-tolerant接入
UE3->>gNB1: RRC Setup Request<br/>(普通注册, 非delay-tolerant)
gNB1->>UE3: RRC Setup<br/>(正常放行)
UE3->>gNB1: Initial UE Message<br/>(Registration Request)
gNB1->>AMF: NGAP Initial UE Message
UE1->>gNB1: RRC Setup Request<br/>(delay-tolerant接入)
Note over gNB1: 随机数<60%<br/>拒绝该请求
gNB1->>UE1: RRC Reject<br/>waitTime=30s
UE2->>gNB2: RRC Setup Request<br/>(紧急呼叫, highPriorityAccess)
Note over gNB2: Overload Response=0<br/>但紧急呼叫豁免
gNB2->>UE2: RRC Setup<br/>(紧急呼叫放行)
UE2->>gNB2: Initial UE Message<br/>(Emergency Registration)
gNB2->>AMF: NGAP Initial UE Message
Note over AMF: 过载缓解<br/>CPU<60%持续60s
AMF->>gNB1: NGAP OVERLOAD STOP
AMF->>gNB2: NGAP OVERLOAD STOP
Note over gNB1,gNB2: 恢复正常操作
Rel-16引入了List of Overload S-NSSAI Traffic IE，允许AMF按切片粒度控制过载。这意味着：
这在实际部署中极具价值——运营商可以保护VIP用户和关键业务，同时削减普通流量。Cisco Ultra Cloud Core AMF（2025-01版）文档明确支持按S-NSSAI粒度配置过载策略。
当AMF过载缓解后，发送OVERLOAD STOP消息通知gNB恢复正常操作：
当信令已经到达AMF但无法处理时，AMF使用NAS级拥塞控制：
| NAS消息 | 拥塞控制IE | 说明 |
|---|---|---|
| REGISTRATION REJECT | 5GMM Cause #22 (congestion) + T3346 Backoff Timer | 注册拒绝+退避定时器 |
| SERVICE REJECT | 5GMM Cause #22 + T3346 | 服务拒绝+退避 |
| CONFIGURATION UPDATE COMMAND | 配置更新+Backoff指示 | 网络侧主动配置 |
| DEREGISTRATION REQUEST | 去注册+重新定向 | 强制重定向到其他AMF |
Backoff定时器T3346的博弈分析：
信令流入口
│
┌────────────┼────────────┐
▼ ▼ ▼
gNB侧拦截 AMF入口过滤 NAS处理层
(NGAP层) (N2层) (NAS层)
│ │ │
Overload N2消息队列 NAS拥塞
Start动作 优先级调度 Backoff
│ │ │
┌────┴────┐ ┌───┴───┐ ┌───┴───┐
│按概率丢弃│ │优先级QoS│ │Cause#22│
│延迟容忍 │ │紧急优先│ │T3346 │
└─────────┘ └───────┘ └───────┘
三层协同博弈的核心逻辑：
当AMF过载时，第三条路径是通过SBI更新NRF中的NF Profile负载信息：
nfLoad字段AMF Set是5GC引入的关键概念——一组AMF实例共享相同的TAI范围和服务能力：
graph TB
subgraph "AMF Set (同一TAI范围)"
AMF1["AMF-1<br/>Load: 95%<br/>Status: Overloaded"]
AMF2["AMF-2<br/>Load: 60%<br/>Status: Normal"]
AMF3["AMF-3<br/>Load: 40%<br/>Status: Normal"]
end
NRF["NRF<br/>NF Repository<br/>存储各AMF负载"]
subgraph "RAN侧"
gNB1["gNB-1"]
gNB2["gNB-2"]
end
gNB1 -->|"Initial UE Message<br/>AMF选择"| AMF1
AMF1 -->|"NNRF_NFUpdate<br/>nfLoad=95%"| NRF
NRF -->|"NNRF_NFDiscovery<br/>返回AMF-2(60%)"| gNB1
gNB2 -->|"后续UE<br/>选择AMF-2或AMF-3"| AMF2
gNB2 -->|"后续UE<br/>选择AMF-2或AMF-3"| AMF3
AMF1 -.->|"AMF Rebalancing<br/>重分配部分UE"| AMF2
AMF1 -.->|"Configuration Update<br/>重定向UE"| AMF3
style AMF1 fill:#ff6b6b
style AMF2 fill:#51cf66
style AMF3 fill:#51cf66
style NRF fill:#4dabf7
当AMF需要主动重分配负载时，执行AMF Rebalancing过程：
Rebalancing的博弈困境：
| 维度 | 快速重分配 | 温和重分配 |
|---|---|---|
| 速度 | 一次迁移大量UE | 逐步迁移少量UE |
| 风险 | 可能导致目标AMF也过载（级联效应） | 过载缓解慢 |
| 信令开销 | 大量Configuration Update | 开销可控 |
| UE影响 | 可能短暂中断业务 | 业务无感 |
sequenceDiagram
participant UE
participant gNB
participant AMF_O as AMF(过载)
participant NRF
participant AMF_T as AMF(目标)
participant UDM
rect rgb(255, 230, 230)
Note over AMF_O: 阶段1: 过载检测与NRF更新
AMF_O->>AMF_O: 检测CPU=88%<br/>NAS队列=1200
AMF_O->>NRF: NNRF_NFUpdate<br/>nfLoad=88%, status=overloaded
NRF-->>gNB: 后续Discovery响应<br/>降低AMF_O权重
end
rect rgb(255, 245, 200)
Note over AMF_O,gNB: 阶段2: NGAP Overload Start推流
AMF_O->>gNB: NGAP OVERLOAD START<br/>Response=2(拒绝延迟容忍)<br/>Traffic=delay-tolerant<br/>Reduction=70%<br/>S-NSSAI List: 切片B
Note over gNB: gNB按70%概率拒绝<br/>delay-tolerant接入<br/>切片B流量削减
end
rect rgb(230, 255, 230)
Note over AMF_O,UE: 阶段3: NAS拥塞控制
UE->>gNB: RRC Setup(非delay-tolerant)
gNB->>AMF_O: NGAP Initial UE Message<br/>(Registration Request)
AMF_O->>AMF_O: NAS队列满<br/>触发拥塞拒绝
AMF_O->>gNB: NGAP Downlink NAS Transport<br/>(REGISTRATION REJECT)
gNB->>UE: REGISTRATION REJECT<br/>Cause #22(congestion)<br/>T3346=600s
Note over UE: 启动T3346=600s<br/>期间不发起新注册
end
rect rgb(230, 230, 255)
Note over AMF_O,AMF_T: 阶段4: AMF Rebalancing
AMF_O->>NRF: NNRF_NFDiscovery<br/>查询同Set轻载AMF
NRF-->>AMF_O: 返回AMF_T(load=40%)
AMF_O->>UE: UE Configuration Update<br/>新5G-GUTI(编码AMF_T GUAMI)
UE->>gNB: Registration Request<br/>携带新5G-GUTI
gNB->>AMF_T: NGAP Initial UE Message<br/>(路由到AMF_T)
AMF_T->>AMF_O: Namf_Communication<br/>UEContextTransfer
AMF_O->>UDM: Nudm_UECM_Registration<br/>更新 serving AMF
end
rect rgb(220, 255, 220)
Note over AMF_O,gNB: 阶段5: 过载缓解与恢复
AMF_O->>AMF_O: CPU=55%持续120s<br/>过载缓解确认
AMF_O->>gNB: NGAP OVERLOAD STOP
AMF_O->>NRF: NNRF_NFUpdate<br/>nfLoad=55%, status=normal
Note over gNB: 恢复正常操作
end
OVERLOAD START
├── ProtocolIE-Container
│ ├── AMF Overload Response [M] ← 必选
│ │ └── OverloadAction: ENUMERATED
│ │ ├── reject-non-emergency-sessions (0)
│ │ ├── reject-non-emergency-and-mt (1)
│ │ ├── reject-delay-tolerant (2)
│ │ └── allow-emergency-and-high-priority-only (3)
│ │
│ ├── Overload Additional Traffic Reduction List [O] ← 可选
│ │ └── SEQUENCE OF OverloadAdditionalTrafficReduction
│ │ ├── Traffic Category: ENUMERATED
│ │ │ ├── delay-tolerant-access (0)
│ │ │ └── non-delay-tolerant-access (1)
│ │ └── Overload Reduction Factor: INTEGER(0..100)
│ │
│ ├── List of Overload Plmn Traffic [O] ← 可选(Rel-16)
│ │ └── SEQUENCE OF OverloadPlmnTraffic
│ │ ├── PLMN Identity
│ │ └── Traffic Category + Reduction Factor
│ │
│ └── List of Overload S-NSSAI Traffic [O] ← 可选(Rel-16)
│ └── SEQUENCE OF OverloadSNSSAITraffic
│ ├── S-NSSAI
│ └── Traffic Category + Reduction Factor
gNB收到Reduction Factor后，通常采用随机早期检测(RED)类算法：
这种概率性丢弃的好处是避免"同步振荡"——所有UE不会在同一时刻重试。
# 过滤NGAP Overload Start/Stop消息
ngap.procedureCode == 19 || ngap.procedureCode == 20
# 更精确地过滤（Overload Start=19, Overload Stop=20）
ngap.element_dir == 1 && ngap.procedureCode == 19
在Wireshark中，Overload Start消息会显示为：
- NGAP: Overload Start
- AMF Overload Response: Overload Action = reject-delay-tolerant (2)
- Overload Additional Traffic Reduction List
- Traffic Category: delay-tolerant-access (0)
- Overload Reduction Factor: 60
| 故障现象 | 可能原因 | 排错思路 |
|---|---|---|
| 大量RRC Reject无明确原因 | AMF发送Overload Start但gNB未正确处理 | 检查gNB是否收到Overload Start，NGAP日志 |
| UE反复注册失败（Cause #22） | AMF NAS拥塞但Backoff Timer过短或UE不遵守 | 检查T3346值，确认UE实现是否正确忽略高优先级豁免 |
| 过载恢复后仍有大量拒绝 | AMF已发Overload Stop但gNB未收到或处理延迟 | 检查NGAP链路状态，确认Overload Stop到达 |
| 级联过载（多个AMF同时过载） | Rebalancing目标选择不当，或信令风暴超出全网容量 | 检查NRF负载信息更新是否及时，考虑AMF Set扩容 |
| 特定切片用户全部失败 | Overload Start中List of S-NSSAI配置不当 | 检查是否误将高优先切片纳入过载控制列表 |
| ## 八、与4G MME过载控制的演进对比 |
| 维度 | 4G MME (S1AP) | 5G AMF (NGAP) |
|---|---|---|
| 过载信令 | S1AP Overload Start/Stop | NGAP Overload Start/Stop |
| 动作类型 | 4种（类似但无切片支持） | 4种 + 切片/PLMN粒度 |
| 切片控制 | 不支持（4G无切片概念） | 支持S-NSSAI粒度 |
| PLMN控制 | 支持 | 支持 |
| 负载重分配 | MME Pool内均衡（DNS-based） | AMF Set内均衡（NRF-based） |
| SBI集成 | 无（SBA架构不存在） | NRF实时负载通告 |
| NAS级控制 | EMM Cause #22 + T3402 | 5GMM Cause #22 + T3346 |
| 新增特性 | - | UE Configuration Update重定向 |
5G相比4G的关键增强是NRF-based的实时负载感知和切片粒度过载控制。4G时代MME Pool的负载均衡依赖DNS解析，更新延迟大；5G通过NRF的SBI订阅/通知机制，AMF负载变化可以在秒级内通知到全网相关NF。
Q1: Overload Start和NAS Backoff Timer能否同时生效？ A: 可以且推荐同时使用。Overload Start在gNB侧拦截大量信令（第一道防线），对于已经到达AMF的少量信令，通过NAS Cause #22 + T3346做第二层控制。两者互补而非互斥。实际部署中通常先触发NGAP Overload Start，当过载持续恶化时叠加NAS拥塞控制。
Q2: gNB收到多个AMF的Overload Start（不同策略）如何处理？ A: gNB与每个AMF分别维护过载状态。gNB根据UE Initial Message路由目标AMF的过载策略来决定是否拒绝。即gNB对每个AMF连接独立执行过载动作。
Q3: 紧急呼叫在过载时真的不受影响吗？ A: 根据TS 38.413，Overload Response的所有动作等级都明确豁免紧急呼叫（Emergency）和高优先级接入（highPriorityAccess, ms-HighPriorityAccess）。但gNB实现是否严格遵守这一规则需要通过测试验证。在Open5GS等开源实现中，紧急呼叫的豁免逻辑已实现。
Q4: AMF Rebalancing会导致UE业务中断吗？ A: 正常情况下不会。AMF通过UE Configuration Update更新5G-GUTI，UE使用新GUTI发起Mobility Registration Update，在注册过程中通过UE Context Transfer从源AMF迁移到目标AMF。正在进行的PDU Session通过SMF保持不变，数据面不中断。但如果Rebalancing过程中NAS安全上下文迁移失败，可能导致UE重新完整注册。
Q5: 为什么Overload Start是"非UE关联信令"？ A: 因为Overload Start不是针对某个特定UE的，而是AMF向gNB广播的"全局控制指令"。一个AMF连接的所有gNB都会收到相同的（或策略性不同的）Overload Start。这与UE-specific的NGAP消息（如Initial Context Setup）完全不同，它使用的是非UE关联的NGAP信令连接。
本文由「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 等场景全覆盖。