# 5G AMF过载控制三径信令与N2推流博弈
## 引言：当AMF成为瓶颈
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过载检测：内部指标触发门限
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），不同级别触发不同强度的控制动作。
```mermaid
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(轻度)
拒绝Delay Tolerant接入
}
state Major {
note right of Major: NGAP Overload Start(中度)
拒绝非紧急+NAS Backoff
更新NRF负载
}
state Critical {
note right of Critical: NGAP Overload Start(重度)
仅允许紧急呼叫
停止接受新注册
}
```
## 二、N2/NGAP路径：Overload Start推流博弈
### 2.1 Overload Start消息结构（TS 38.413 Section 8.28）
当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的小区广播 | 轻度优化 |
```mermaid
sequenceDiagram
participant AMF
participant gNB1
participant gNB2
participant UE1 as UE(延迟容忍)
participant UE2 as UE(紧急呼叫)
participant UE3 as UE(普通注册)
Note over AMF: 检测到过载
CPU>85%, NAS队列积压
AMF->>gNB1: NGAP OVERLOAD START
Overload Response=2(拒绝延迟容忍)
Traffic Category=delay-tolerant
Reduction Factor=60%
AMF->>gNB2: NGAP OVERLOAD START
Overload Response=0(拒绝非紧急)
List of S-NSSAI: 切片A
Note over gNB1: 开始按60%概率
拒绝delay-tolerant接入
UE3->>gNB1: RRC Setup Request
(普通注册, 非delay-tolerant)
gNB1->>UE3: RRC Setup
(正常放行)
UE3->>gNB1: Initial UE Message
(Registration Request)
gNB1->>AMF: NGAP Initial UE Message
UE1->>gNB1: RRC Setup Request
(delay-tolerant接入)
Note over gNB1: 随机数<60%
拒绝该请求
gNB1->>UE1: RRC Reject
waitTime=30s
UE2->>gNB2: RRC Setup Request
(紧急呼叫, highPriorityAccess)
Note over gNB2: Overload Response=0
但紧急呼叫豁免
gNB2->>UE2: RRC Setup
(紧急呼叫放行)
UE2->>gNB2: Initial UE Message
(Emergency Registration)
gNB2->>AMF: NGAP Initial UE Message
Note over AMF: 过载缓解
CPU<60%持续60s
AMF->>gNB1: NGAP OVERLOAD STOP
AMF->>gNB2: NGAP OVERLOAD STOP
Note over gNB1,gNB2: 恢复正常操作
```
### 2.2 切片粒度过载控制（Rel-16增强）
Rel-16引入了List of Overload S-NSSAI Traffic IE，允许AMF按切片粒度控制过载。这意味着：
- **高优先级切片**（如URLLC工业控制）：即使AMF过载也不受影响
- **普通切片**（如eMBB视频流）：按比例削减
- **低优先级切片**（如mMTC物联网）：优先削减
这在实际部署中极具价值——运营商可以保护VIP用户和关键业务，同时削减普通流量。Cisco Ultra Cloud Core AMF（2025-01版）文档明确支持按S-NSSAI粒度配置过载策略。
### 2.3 Overload Stop与恢复（TS 38.413 Section 8.29）
当AMF过载缓解后，发送OVERLOAD STOP消息通知gNB恢复正常操作：
- OVERLOAD STOP消息结构非常简单，无需携带任何过载参数
- gNB收到后立即停止所有过载控制动作
- **关键时序博弈**：AMF不应过早发送Overload Stop——如果过载反复波动，频繁的Start/Stop会导致gNB信令处理振荡。实际实现中通常设置一个"恢复观察期"（如连续60秒低于门限才发送Stop）
## 三、NAS路径：拥塞拒绝与Backoff定时器博弈
### 3.1 NAS级拥塞控制机制（TS 24.501 Section 5.3.6）
当信令已经到达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的博弈分析：**
- UE收到T3346后，在该定时器运行期间**不得发起任何移动性和注册类NAS过程**
- 但**紧急呼叫和高优先级接入不受T3346约束**（TS 24.501 Section 5.3.6.5）
- AMF可以针对特定S-NSSAI设置不同的T3346值（切片级拥塞控制）
- **博弈关键**：T3346值设置过短→拥塞持续；过长→用户体验严重恶化。典型范围5分钟~4小时
### 3.2 NAS与NGAP双层控制的协同
```
信令流入口
│
┌────────────┼────────────┐
▼ ▼ ▼
gNB侧拦截 AMF入口过滤 NAS处理层
(NGAP层) (N2层) (NAS层)
│ │ │
Overload N2消息队列 NAS拥塞
Start动作 优先级调度 Backoff
│ │ │
┌────┴────┐ ┌───┴───┐ ┌───┴───┐
│按概率丢弃│ │优先级QoS│ │Cause#22│
│延迟容忍 │ │紧急优先│ │T3346 │
└─────────┘ └───────┘ └───────┘
```
**三层协同博弈的核心逻辑：**
1. **第一道防线（gNB侧）**：通过Overload Start，在RAN侧就拦截大量非紧急信令，这是最经济的方式——信令连AMF的门都没进
2. **第二道防线（N2入口）**：到达AMF N2接口但尚未进入NAS处理队列的消息，AMF可以实现优先级队列调度（紧急优先、普通按权重）
3. **第三道防线（NAS层）**：进入NAS处理但AMF无资源时，以Cause #22拒绝并附带Backoff Timer
## 四、SBI/NRF路径：负载重分配与AMF Set博弈
### 4.1 NRF负载信息更新（TS 29.510 Section 6.1.6.2.3）
当AMF过载时，第三条路径是通过SBI更新NRF中的NF Profile负载信息：
- AMF通过**NNRF_NFUpdate**请求更新NF Profile中的`nfLoad`字段
- NRF在后续的**NNRF_NFDiscovery**响应中，将负载信息返回给gNB或其他NF
- gNB在做AMF选择时可以参考负载信息，将新UE引导至轻载AMF
### 4.2 AMF Set与负载均衡（TS 23.501 Section 6.3.5）
AMF Set是5GC引入的关键概念——一组AMF实例共享相同的TAI范围和服务能力：
```mermaid
graph TB
subgraph "AMF Set (同一TAI范围)"
AMF1["AMF-1
Load: 95%
Status: Overloaded"]
AMF2["AMF-2
Load: 60%
Status: Normal"]
AMF3["AMF-3
Load: 40%
Status: Normal"]
end
NRF["NRF
NF Repository
存储各AMF负载"]
subgraph "RAN侧"
gNB1["gNB-1"]
gNB2["gNB-2"]
end
gNB1 -->|"Initial UE Message
AMF选择"| AMF1
AMF1 -->|"NNRF_NFUpdate
nfLoad=95%"| NRF
NRF -->|"NNRF_NFDiscovery
返回AMF-2(60%)"| gNB1
gNB2 -->|"后续UE
选择AMF-2或AMF-3"| AMF2
gNB2 -->|"后续UE
选择AMF-2或AMF-3"| AMF3
AMF1 -.->|"AMF Rebalancing
重分配部分UE"| AMF2
AMF1 -.->|"Configuration Update
重定向UE"| AMF3
style AMF1 fill:#ff6b6b
style AMF2 fill:#51cf66
style AMF3 fill:#51cf66
style NRF fill:#4dabf7
```
### 4.3 AMF Rebalancing信令流（TS 23.502 Section 4.2.5.3）
当AMF需要主动重分配负载时，执行AMF Rebalancing过程：
1. **源AMF**选择需要迁移的UE（基于策略：如最近注册的、非紧急会话的UE）
2. 源AMF发送**Namf_Communication_N1N2MessageTransfer**到目标AMF，或使用**UE Configuration Update Command**携带新5G-GUTI
3. 新5G-GUTI中编码了目标AMF的GUAMI
4. UE下次发起NAS过程时，gNB根据5G-GUTI路由到目标AMF
**Rebalancing的博弈困境：**
| 维度 | 快速重分配 | 温和重分配 |
|------|-----------|-----------|
| 速度 | 一次迁移大量UE | 逐步迁移少量UE |
| 风险 | 可能导致目标AMF也过载（级联效应） | 过载缓解慢 |
| 信令开销 | 大量Configuration Update | 开销可控 |
| UE影响 | 可能短暂中断业务 | 业务无感 |
## 五、三径协同：完整过载控制时序
```mermaid
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%
NAS队列=1200
AMF_O->>NRF: NNRF_NFUpdate
nfLoad=88%, status=overloaded
NRF-->>gNB: 后续Discovery响应
降低AMF_O权重
end
rect rgb(255, 245, 200)
Note over AMF_O,gNB: 阶段2: NGAP Overload Start推流
AMF_O->>gNB: NGAP OVERLOAD START
Response=2(拒绝延迟容忍)
Traffic=delay-tolerant
Reduction=70%
S-NSSAI List: 切片B
Note over gNB: gNB按70%概率拒绝
delay-tolerant接入
切片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
(Registration Request)
AMF_O->>AMF_O: NAS队列满
触发拥塞拒绝
AMF_O->>gNB: NGAP Downlink NAS Transport
(REGISTRATION REJECT)
gNB->>UE: REGISTRATION REJECT
Cause #22(congestion)
T3346=600s
Note over UE: 启动T3346=600s
期间不发起新注册
end
rect rgb(230, 230, 255)
Note over AMF_O,AMF_T: 阶段4: AMF Rebalancing
AMF_O->>NRF: NNRF_NFDiscovery
查询同Set轻载AMF
NRF-->>AMF_O: 返回AMF_T(load=40%)
AMF_O->>UE: UE Configuration Update
新5G-GUTI(编码AMF_T GUAMI)
UE->>gNB: Registration Request
携带新5G-GUTI
gNB->>AMF_T: NGAP Initial UE Message
(路由到AMF_T)
AMF_T->>AMF_O: Namf_Communication
UEContextTransfer
AMF_O->>UDM: Nudm_UECM_Registration
更新 serving AMF
end
rect rgb(220, 255, 220)
Note over AMF_O,gNB: 阶段5: 过载缓解与恢复
AMF_O->>AMF_O: CPU=55%持续120s
过载缓解确认
AMF_O->>gNB: NGAP OVERLOAD STOP
AMF_O->>NRF: NNRF_NFUpdate
nfLoad=55%, status=normal
Note over gNB: 恢复正常操作
end
```
## 六、Overload Start IE深度解析
### 6.1 IE嵌套结构（TS 38.413 Section 9.2.1.2）
```
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
```
### 6.2 Reduction Factor的随机丢弃算法
gNB收到Reduction Factor后，通常采用**随机早期检测(RED)**类算法：
- Reduction Factor=60%表示gNB应以60%的概率拒绝该类流量
- gNB对每个符合Overload条件的RRC请求，生成[0,99]随机数
- 若随机数 < Reduction Factor，则发送RRC Reject + waitTime
- **waitTime**由gNB本地配置（通常10~60秒）
这种概率性丢弃的好处是避免"同步振荡"——所有UE不会在同一时刻重试。
## 七、抓包识别与故障排错
### 7.1 Wireshark抓包过滤
```
# 过滤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`
### 7.2 常见故障场景
| 故障现象 | 可能原因 | 排错思路 |
|---------|---------|---------|
| 大量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信令连接。
## 参考来源
1. [3GPP TS 23.501 V18.x](https://www.3gpp.org/DynaReport/23501.htm) — Section 5.19 Overload Control框架, Section 6.3.5 AMF Set与负载均衡
2. [3GPP TS 23.502 V18.x](https://www.3gpp.org/DynaReport/23502.htm) — Section 4.2.5 过载控制过程, Section 4.2.5.3 AMF Rebalancing
3. [3GPP TS 38.413 V18.x](https://www.3gpp.org/DynaReport/38413.htm) — Section 8.28 Overload Start, Section 8.29 Overload Stop, Section 9.2.1.2 IE定义
4. [Cisco Ultra Cloud Core AMF Overload Control Guide](https://www.cisco.com/c/en/us/td/docs/wireless/ucc/amf/2025-01/config-and-admin/b_ucc-5g-amf-config-and-admin-guide_2025-01/m_overload-control-n2-nas.html) — N2/NAS双通道过载控制实现
5. [3GPP TS 29.510 V18.x](https://www.3gpp.org/DynaReport/29510.htm) — Section 6.1.6 NRF NF Profile管理与负载通告
6. [3glteinfo NGAP Overload Start](https://www.3glteinfo.com/messages/5g/ngap/overload-start/) — NGAP Overload Start消息IE详细解析
---
> 本文由「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 等场景全覆盖。
