# 5G AMF过载控制N2/NAS双通道流量抑制信令流拆解
## 一、引言：为什么AMF过载控制如此关键
AMF（Access and Mobility Management Function）是5G核心网中所有UE接入的第一道关口。每一个Registration Request、每一个Service Request、每一条NAS信令都必须经过AMF处理。当海量UE同时发起接入——例如大型赛事结束、突发事件告警推送、节假日旅游景区峰值——AMF的CPU、内存和SCTP连接资源可能在数秒内被耗尽。
与4G MME类似但机制更为精密，5G AMF的过载控制采用了**N2接口（NGAP层）和NAS层双通道协同抑制**的策略。N2侧通过NGAP Overload Start/Stop消息向gNB下发流量抑制指令，NAS侧则通过5GMM Reject消息携带T3346退避定时器直接控制UE行为。两套机制协同工作，形成从RAN到UE的全链路过载保护。
本文将基于3GPP TS 23.502 V18.x Section 4.22、TS 23.501 Section 5.19.5.2、TS 38.413 Section 8.20/8.21以及TS 24.501，逐信令、逐IE地拆解这套机制的完整运行流程。
## 二、AMF过载检测：内部触发条件
### 2.1 过载判定维度
AMF过载的判定是**厂商实现相关**的，3GPP规范不规定具体算法，但定义了触发过载控制行为的框架条件：
| 维度 | 典型阈值触发 | 参考来源 |
|------|------------|---------|
| CPU利用率 | 超过配置的高水位线（如80%/90%/95%多级） | 厂商实现 |
| 内存占用 | UE Context数量逼近最大容量 | 厂商实现 |
| N2 SCTP连接 | 每条SCTP关联的待处理消息队列深度超限 | TS 38.412 |
| NAS信令队列 | 待处理的NAS PDU积压超过阈值 | 厂商实现 |
| NF Service负载 | Namf接口HTTP请求速率超限 | TS 29.500 |
### 2.2 过载等级与抑制策略映射
Cisco Ultra Cloud Core AMF的实现给出了一个典型的多级过载策略：
```
Level 1 (Minor) → 拒绝非紧急MO Data的RRC连接
Level 2 (Moderate) → 拒绝非紧急MO Signaling的RRC连接
Level 3 (Severe) → 仅允许紧急呼叫和MT服务
Level 4 (Critical) → 仅允许紧急呼叫
```
这套分级机制对应TS 38.413中定义的**OverloadResponse IE**中的五种Overload Action。
## 三、N2通道抑制：NGAP Overload Start/Stop信令流
### 3.1 完整信令时序图
```mermaid
sequenceDiagram
participant AMF
participant gNB1 as gNB-1
participant gNB2 as gNB-2
participant UE1 as UE-1
participant UE2 as UE-2
Note over AMF: AMF检测到过载
(CPU 92%, UE Context满)
rect rgb(255, 200, 200)
Note over AMF,gNB2: 阶段1: 过载通知下发
AMF->>gNB1: NGAP OVERLOAD START
OverloadResponse = reject non-emergency MO Data
TrafficLoadReductionIndication = 60%
AMF->>gNB2: NGAP OVERLOAD START
OverloadResponse = reject non-emergency MO Data
TrafficLoadReductionIndication = 60%
Note over gNB1: gNB-1按照60%比例
拒绝非紧急MO Data的RRC建立
Note over gNB2: gNB-2按照60%比例
拒绝非紧急MO Data的RRC建立
end
rect rgb(255, 255, 200)
Note over UE1,UE2: 阶段2: 过载期间流量抑制
UE1->>gNB1: RRC Connection Request (MO Data)
gNB1-->>UE1: RRC Connection Reject
waitTime = 8s
Note over gNB1: 随机丢弃60%的
非紧急MO Data请求
UE2->>gNB1: RRC Connection Request (Emergency)
gNB1->>AMF: NGAP Initial UE Message
(Emergency Registration)
AMF->>gNB1: NGAP Initial Context Setup Request
gNB1->>UE2: RRC Connection Reconfiguration
Note over UE2: 紧急呼叫正常建立
end
rect rgb(200, 255, 200)
Note over AMF,gNB2: 阶段3: 过载升级（恶化时）
AMF->>gNB1: NGAP OVERLOAD START
OverloadResponse = emergency sessions only
TrafficLoadReductionIndication = 90%
AMF->>gNB2: NGAP OVERLOAD START
OverloadResponse = emergency sessions only
Note over gNB1: 升级为仅允许紧急呼叫
end
rect rgb(200, 200, 255)
Note over AMF,gNB2: 阶段4: 过载恢复
Note over AMF: AMF负载恢复至安全水位
AMF->>gNB1: NGAP OVERLOAD STOP
AMF->>gNB2: NGAP OVERLOAD STOP
Note over gNB1: 恢复正常操作
Note over gNB2: 恢复正常操作
end
```
### 3.2 NGAP OVERLOAD START消息IE深度解析
OVERLOAD START是**非UE关联的NGAP信令**（Non-UE-associated Signalling），在AMF与gNB之间的SCTP关联上发送，不需要gNB回复确认。
#### 3.2.1 消息结构
根据TS 38.413 Section 9.2.1.2，OVERLOAD START消息的ASN.1定义（简化）：
```
OVERLOAD-START ::= SEQUENCE {
protocolIEs ProtocolIE-Container {{OverloadStartIEs}},
...
}
OverloadStartIEs NGAP-PROTOCOL-IES ::= {
{ ID id-AMFOverloadResponse CRITICALITY reject TYPE OverloadResponse PRESENCE mandatory } |
{ ID id-TrafficLoadReductionIndication CRITICALITY ignore TYPE TrafficLoadReductionIndication PRESENCE optional } |
{ ID id-OverloadStartNSSAIList CRITICALITY ignore TYPE OverloadStartNSSAIList PRESENCE optional },
...
}
```
#### 3.2.2 关键IE参数说明
| IE名称 | 存在性 | 类型 | 说明 |
|--------|--------|------|------|
| **OverloadResponse** | 必选 | 枚举组合 | 定义gNB应采取的过载动作，可包含多个动作 |
| **TrafficLoadReductionIndication** | 可选 | 整数(0..100) | 百分比指示gNB应减少多少N2流量 |
| **OverloadStartNSSAIList** | 可选(Rel-16+) | S-NSSAI列表 | 按切片粒度控制过载，仅对特定切片抑制 |
#### 3.2.3 OverloadResponse IE动作枚举
这是整个过载控制机制的核心IE，定义了gNB应执行的具体抑制动作：
| 动作值（枚举） | 行为 | 适用场景 |
|----------------|------|---------|
| **reject-non-emergency-mo-data** | 拒绝非紧急、非高优先级的MO Data RRC建立 | 轻度过载 |
| **reject-non-emergency-mo-signalling** | 拒绝非紧急MO Signaling的RRC建立 | 中度过载 |
| **reject-non-emergency-mo-data-and-signalling** | 同时拒绝非紧急MO Data和Signaling | 较重过载 |
| **permit-emergency-sessions-and-mt-access-only** | 仅允许紧急会话和MT（Mobile Terminated）服务 | 严重过载 |
| **permit-emergency-sessions-only** | 仅允许紧急会话 | 极度过载 |
#### 3.2.4 OverloadResponse IE结构图
```mermaid
graph TD
A[OVERLOAD START Message] --> B[OverloadResponse IE
Mandatory]
A --> C[TrafficLoadReductionIndication
Optional: 0-100%]
A --> D[OverloadStartNSSAIList
Optional: Rel-16+]
B --> E[Overload Action 1:
reject-non-emergency-mo-data]
B --> F[Overload Action 2:
reject-non-emergency-mo-signalling]
B --> G[Overload Action 3:
permit-emergency-sessions-and-mt-access-only]
B --> H[Overload Action 4:
permit-emergency-sessions-only]
D --> I[S-NSSAI 1
e.g. eMBB: 010001]
D --> J[S-NSSAI 2
e.g. URLLC: 020102]
style A fill:#ff6b6b,color:#fff
style B fill:#ffd93d,color:#333
style C fill:#6bcb77,color:#fff
style D fill:#4d96ff,color:#fff
```
### 3.3 TrafficLoadReductionIndication的工作原理
这个IE是N2过载控制的精妙之处。AMF不是简单地"全开或全关"，而是指定一个**百分比**，让gNB按比例随机丢弃特定类型的RRC连接请求：
**工作机制**（TS 23.501 Section 5.19.5.2）：
- AMF发送TrafficLoadReductionIndication = 60，表示希望减少60%的N2流量
- gNB对本应转发的RRC连接请求，以60%的概率执行随机丢弃
- 被丢弃的UE收到RRC Connection Reject，携带waitTime（等待时间）
- 40%的请求正常转发给AMF
**概率丢弃算法示意**：
```
对每个符合OverloadResponse过滤条件的RRC请求:
random_value = random(0, 100)
if random_value < TrafficLoadReductionIndication:
→ RRC Connection Reject (waitTime)
else:
→ 正常转发Initial UE Message给AMF
```
### 3.4 OverloadStartNSSAIList：切片级过载控制
Rel-16引入的重要增强，允许AMF对特定网络切片进行精准过载控制：
- 当某个S-NSSAI对应的SMF/UPF负载过高时，AMF可以仅对该切片的PDU会话建立请求进行抑制
- gNB在Initial UE Message中会携带Requested NSSAI，AMF据此判断切片归属
- 在Overload Start中携带OverloadStartNSSAIList，仅对列表中的切片执行过载动作
- 这意味着eMBS切片可以正常运行，而URLLC切片可以单独被抑制
## 四、NAS通道抑制：5GMM Reject与T3346退避
### 4.1 NAS层过载控制策略
当UE的NAS信令已经到达AMF但AMF无法处理时，AMF在NAS层直接进行拒绝。这与N2层控制互补——N2控制在gNB侧拦截请求，NAS控制在AMF侧拒绝已到达的请求。
### 4.2 NAS Reject消息与5GMM Cause Code
| NAS过程 | Reject消息 | 5GMM Cause | T3346携带 |
|---------|-----------|------------|-----------|
| Registration Request | Registration Reject | #22 (Congestion) | 是 |
| Service Request | Service Reject | #22 (Congestion) | 是 |
| PDU Session Establishment | 5GSM Reject (via NAS) | #27 (Missing or unknown DNN) 或 #22 | 可能 |
| Configuration Update | 无Reject（静默丢弃） | — | — |
**关键点**：当AMF发送携带5GMM Cause #22（Congestion）的Reject消息时，必须携带**T3346 IE**（GPRS Timer 3编码），指示UE在退避期间不得重新发起同类请求。
### 4.3 T3346退避定时器机制
根据TS 24.501 Section 5.5.1.3.5：
```mermaid
stateDiagram-v2
[*] --> Idle: UE已注册
Idle --> Attempting: 发起Registration Request
Attempting --> Rejected: 收到Reg Reject #22 + T3346
Rejected --> Backoff: 启动T3346定时器
(如30分钟)
Backoff --> Backoff_Hold: UE收到寻呼/紧急呼叫
Backoff_Hold --> Backoff: 紧急呼叫结束
T3346继续运行
Backoff --> Idle: T3346超时
可重新发起请求
Backoff --> Attempting: T3346超时后重新尝试
```
**T3346编码规则**（TS 24.501 Section 9.9.2.14a）：
GPRS Timer 3 IE采用以下编码格式：
| 字段 | 长度 | 说明 |
|------|------|------|
| IEI | 1字节 | 0x5E（标识T3346） |
| Length | 1字节 | IE长度 |
| Unit | 2 bits | 00=2秒, 01=分钟, 10=6分钟, 11=小时 |
| Timer Value | 6 bits | 计数值 |
**举例**：Unit=01(分钟), Timer Value=30 → T3346 = 30分钟
### 4.4 NAS层与N2层协同抑制流程
```mermaid
sequenceDiagram
participant UE1 as UE-1 (新接入)
participant UE2 as UE-2 (已连接)
participant gNB as gNB
participant AMF as AMF (过载中)
Note over AMF: AMF CPU 95%
触发过载控制
par N2通道抑制
AMF->>gNB: NGAP OVERLOAD START
Action: reject MO Data
Reduction: 70%
Note over gNB: gNB开始按70%概率
丢弃MO Data RRC请求
and NAS通道抑制准备
Note over AMF: 配置NAS Congestion Control
Reject Cause #22
T3346 = 30 min
end
Note over UE1: 新UE尝试接入
UE1->>gNB: RRC Connection Request (MO Data)
Note over gNB: random(0,100)=45 < 70
丢弃此请求
gNB-->>UE1: RRC Connection Reject
waitTime = 16s
Note over UE1: UE启动waitTime定时器
16s内不重试
Note over UE2: 已连接UE发起Service Request
UE2->>gNB: RRC Connection Request (MO Signaling)
Note over gNB: MO Signaling不在抑制范围
正常转发
gNB->>AMF: NGAP Initial UE Message
(Service Request)
Note over AMF: NAS层判断：AMF过载中
拒绝Service Request
AMF->>gNB: NGAP Downlink NAS Transport
(Service Reject #22 + T3346=30min)
gNB->>UE2: RRC: DLInformationTransfer
(NAS Service Reject)
Note over UE2: UE启动T3346=30分钟
30分钟内不发起Service Request
Note over AMF: AMF负载恢复
AMF->>gNB: NGAP OVERLOAD STOP
Note over gNB: 恢复正常
```
## 五、SBI接口过载控制：NF间协同
### 5.1 服务化接口的过载控制
除了N2（NGAP）和NAS通道外，AMF还需要向其他NF（如SMF、UDM、SMSF等）传递过载状态。这通过SBI（Service Based Interface）的**OverloadControlInfo IE**实现（TS 29.500 Section 6.6）。
当AMF过载时，在Namf接口的HTTP响应中携带以下IE：
| IE字段 | 说明 |
|--------|------|
| **Overload Reduction** | 0-100的百分比值，指示调用方应减少多少流量 |
| **Validity Time** | 过载控制信息的有效期，超时后调用方可恢复 |
| **Scope** | 受影响的API列表或操作范围 |
| **Traffic Load Reduction Information** | 流量削减的具体参数 |
例如，当SMF调用Namf_Communication的N1N2MessageTransfer时，如果AMF返回OverloadControlInfo，SMF应按照指示的比例减少后续请求。
### 5.2 NRF与AMF过载信息交互
NRF（Network Repository Function）维护着全网NF实例的状态信息。AMF可以将过载状态注册到NRF：
```
AMF → NRF: NFUpdate Request
nfStatus = "overloaded"
load = 95
NRF → SMF (NFDiscovery Response):
AMF实例1: status=overloaded, load=95
AMF实例2: status=registered, load=30
SMF优先选择AMF实例2
```
## 六、AMF Overload Control状态机
### 6.1 AMF过载状态转换
```text
stateDiagram-v2
[*] --> Normal: AMF启动
Normal --> MinorOverload: CPU > 80%
或UE Context > 70%
MinorOverload --> Normal: CPU < 60%
持续30秒
MinorOverload --> ModerateOverload: CPU > 90%
或UE Context > 85%
ModerateOverload --> MinorOverload: CPU < 75%
持续30秒
ModerateOverload --> SevereOverload: CPU > 95%
或UE Context > 95%
SevereOverload --> ModerateOverload: CPU < 85%
持续30秒
SevereOverload --> CriticalOverload: CPU > 99%
或资源耗尽
CriticalOverload --> SevereOverload: CPU < 90%
持续60秒
state Normal {
[*] --> FullService
FullService: 接受所有类型请求
}
state MinorOverload {
[*] --> RejectMOData
RejectMOData: NGAP: reject-non-emergency-mo-data
Reduction: 30%
NAS: T3346=5min
}
state ModerateOverload {
[*] --> RejectMOSignaling
RejectMOSignaling: NGAP: reject MO Signaling
Reduction: 50%
NAS: T3346=15min
}
state SevereOverload {
[*] --> EmergencyAndMTOnly
EmergencyAndMTOnly: NGAP: emergency+MT only
Reduction: 80%
NAS: T3346=30min
}
state CriticalOverload {
[*] --> EmergencyOnly
EmergencyOnly: NGAP: emergency only
Reduction: 95%
NAS: T3346=60min
}
```
## 七、抓包识别与故障排查
### 7.1 Wireshark抓包识别
**识别OVERLOAD START**：
- 过滤条件：`ngap.procedureCode == 19`（Overload Start的Procedure Code为19）
- SCTP流：非UE关联信令流（Stream ID = 0）
- 消息方向：AMF → gNB
**识别OVERLOAD STOP**：
- 过滤条件：`ngap.procedureCode == 20`（Overload Stop的Procedure Code为20）
**识别NAS Reject**：
- 过滤条件：`nas-5gs.message_type == 0x44`（Registration Reject）或 `nas-5gs.message_type == 0x54`（Service Reject）
- 检查5GMM Cause Code是否为22（Congestion）
- 检查是否携带T3346 IE（IEI = 0x5E）
### 7.2 常见故障场景
| 故障现象 | 可能原因 | 排查思路 |
|----------|---------|---------|
| 大量UE Registration Reject #22 | AMF过载或配置错误 | 检查AMF CPU/内存利用率；检查过载控制阈值配置是否过低 |
| OVERLOAD START后长时间无OVERLOAD STOP | AMF过载未恢复或BUG | 检查AMF负载是否持续高位；检查OVERLOAD STOP发送逻辑 |
| 部分gNB未收到OVERLOAD START | SCTP连接异常 | 检查AMF到该gNB的SCTP关联状态 |
| UE T3346超时后立即再次被拒绝 | AMF持续过载 | 检查是否需要增加AMF容量或调整T3346值 |
| 紧急呼叫被错误拒绝 | OverloadResponse配置错误 | 检查AMF是否正确配置了Emergency Session优先级 |
| 切片级过载控制不生效 | gNB不支持Rel-16+特性 | 检查gNB软件版本是否支持OverloadStartNSSAIList |
## 八、与4G MME过载控制的对比
| 维度 | 4G MME (S1AP) | 5G AMF (NGAP) |
|------|---------------|----------------|
| 接口 | S1-MME (S1AP) | N2 (NGAP) |
| 过载通知消息 | S1AP OVERLOAD START | NGAP OVERLOAD START |
| 动作类型 | 4种（基本相同） | 5种（增加切片级控制） |
| 流量削减指示 | Traffic Load Reduction Indication | TrafficLoadReductionIndication + NSSAI |
| NAS退避 | T3402/T3448 | T3346（统一的NAS退避定时器） |
| 服务化过载通知 | 无（S1AP only） | SBI OverloadControlInfo |
| NRF集成 | 无 | 通过NRF发布过载状态 |
| 切片感知 | 不支持 | Rel-16+支持NSSAI级控制 |
**关键演进**：5G相比4G最大的改进在于**服务化接口的过载控制**（SBI OverloadControlInfo）和**NRF感知**。4G的MME过载控制仅限于S1接口，而5G AMF可以通过SBI将过载状态传播到全网NF，实现更精细的端到端流量管理。
## 九、设计意图与架构思考
### 9.1 为什么采用双通道抑制？
N2通道抑制（NGAP Overload Start）和NAS通道抑制（5GMM Reject）各有不可替代的作用：
- **N2通道抑制是"预防性"的**：在gNB侧就拦截了大部分不需要的请求，保护了AMF的SCTP接收缓冲区和NAS解析资源。这是效率最高的方式——请求根本不会到达AMF。
- **NAS通道抑制是"兜底性"的**：对于已经通过N2到达AMF的请求（例如在Overload Start消息到达gNB之前已经发出的请求，或者不在OverloadResponse排除范围内的请求类型），NAS层提供最后一道防线。
### 9.2 为什么Overload Start不需要ACK？
NGAP Overload Start和Overload Stop都是**非UE关联的单向通知消息**，不需要gNB回复。这样设计的原因：
1. **可靠性由SCTP保证**：SCTP协议本身提供可靠传输，消息到达即表示gNB已收到
2. **时效性优先**：过载场景下，AMF的资源极为紧张，不应再处理额外的响应消息
3. **幂等性**：多次发送Overload Start是安全的，gNB以最后一次收到的指令为准
### 9.3 Emergency Session的绝对优先
在所有Overload Action中，Emergency Session始终被豁免。这不仅是技术设计，更是**法规要求**（FCC/ETSI强制规定紧急呼叫的接入保障）。AMF和gNB必须确保在任何过载等级下，紧急呼叫的信令路径畅通无阻。
## 常见问题
**Q1: AMF发送OVERLOAD START后，UE正在进行的会话会中断吗？**
A: 不会。OVERLOAD START仅影响新的RRC连接建立请求（新接入），对已经建立连接的UE会话没有任何影响。正在进行的VoNR通话、数据传输、视频流等不会因为过载控制而中断。
**Q2: TrafficLoadReductionIndication的百分比是精确的吗？**
A: 不是。百分比是统计意义上的指导值，gNB通过随机丢弃算法近似实现。实际丢弃率取决于gNB的实现，可能存在一定偏差。在低流量场景下偏差更明显，高流量下趋向精确。
**Q3: 如果AMF连接了10个gNB，OVERLOAD START要发给所有gNB吗？**
A: 不一定。AMF可以选择性地发送给部分gNB。典型策略有两种：一是发送给所有连接的gNB（广播），二是仅发送给流量贡献最大的gNB子集。选择策略是厂商实现决定的，TS 23.502未做强制规定。可选的TAI List for Overload Start可以进一步限定过载控制的地理范围。
**Q4: T3346定时器运行期间UE收到寻呼怎么处理？**
A: 根据TS 24.501 Section 5.5.1.3.5，T3346运行期间，如果UE收到寻呼（MT service）或需要发起紧急呼叫，UE应暂停T3346并响应寻呼或发起紧急呼叫。这些高优先级操作完成后，T3346继续运行。这保证了过载控制不会阻塞被叫业务。
**Q5: 5G的AMF过载控制相比4G MME有什么本质改进？**
A: 最大的改进有三点：(1) **SBI层面的过载控制**——AMF可以通过HTTP响应中的OverloadControlInfo IE通知其他NF（SMF、UDM等）进行流量削减，4G没有这个机制；(2) **NRF集成**——AMF可以将过载状态注册到NRF，其他NF在发现阶段即可避开过载AMF；(3) **切片级精准控制**——Rel-16引入的OverloadStartNSSAIList允许按S-NSSAI粒度进行过载控制，避免一刀切。
## 参考来源
1. [3GPP TS 23.502 V18.10.0](https://www.etsi.org/deliver/etsi_ts/123500_123599/123502/18.10.00_60/ts_123502v181000p.pdf) — Section 4.22: Overload Control
2. [3GPP TS 23.501 Section 5.19.5.2](https://itecspec.com/3gpp/23.501/s/5.19.5.2) — AMF Overload Control
3. [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.20/8.21: NGAP Overload Start/Stop, Section 9.2.1.2/9.2.1.3: Message IE Definitions
4. [Cisco UCC 5G 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 Overload Control实现配置
5. [3glteinfo NGAP Overload Start](https://www.3glteinfo.com/messages/5g/ngap/overload-start/) — 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 等场景全覆盖。
