在5G核心网中,AMF(Access and Mobility Management Function)是所有UE接入的第一道关口——无论是注册、去注册、服务请求还是移动性更新,所有NAS信令都必须经过AMF处理。当大量UE同时发起信令请求(如突发事件导致mass event、IoT设备批量唤醒、灾难恢复后的re-attach风暴),AMF的CPU、内存和信令处理队列会在短时间内被压垮。
3GPP为此设计了一套多层次协同的过载控制机制,其核心思想是:从源头压制信令流量,让拥塞在到达AMF之前就被网络边缘(RAN侧)消化。这套机制分布在三个层次:
| 层次 | 接口 | 核心规范 | 机制 |
|---|---|---|---|
| N2层过载控制 | AMF ↔ NG-RAN (N2/NGAP) | TS 38.413 Section 8.12/8.13 | Overload Start/Stop |
| NAS层拥塞控制 | AMF ↔ UE (N1/NAS) | TS 24.501 Section 5.3 | NAS Reject + Backoff Timer |
| AMF重平衡 | AMF Set ↔ NG-RAN | TS 23.501 Section 5.19.5.3 | AMF Weight Factor调整 |
本文聚焦于N2层过载控制的完整信令链路,同时分析其与NAS层退避机制的协同工作方式,涉及的3GPP规范包括: - TS 23.501 V18.x Section 5.19.5.2(AMF Overload Control架构性描述) - TS 23.502 V18.x Section 4.3.5(过载控制通用流程) - TS 38.413 V18.x Section 8.12/8.13(NGAP Overload Start/Stop消息定义) - TS 24.501 V18.x Section 5.3(NAS层拥塞处理)
AMF过载控制的起点是AMF自身的过载检测逻辑。3GPP并未标准化AMF内部的过载检测算法,这属于实现细节,但典型的检测维度包括:
AMF内部过载检测度量:
├── CPU利用率(per-AMF实例)
├── 内存使用率(UE Context数量 vs 容量上限)
├── NAS消息队列深度(待处理的Initial UE Message数量)
├── N2信令处理速率(NGAP消息/秒 vs 处理能力上限)
├── 数据库访问延迟(UDM/UDR查询响应时间)
└── 线程池/进程池饱和度
当上述任一度量超过配置的过载阈值(Overload Threshold)时,AMF触发过载控制流程。通常厂商实现中会设置多级阈值:
| 阈值级别 | 触发条件 | 典型动作 |
|---|---|---|
| Level 1 (轻度) | CPU > 70% 或 NAS队列 > 50% | 启动N2 Overload Start(仅抑制非紧急信令连接) |
| Level 2 (中度) | CPU > 85% 或 NAS队列 > 75% | 升级Overload Response策略(仅允许紧急+MT+高优先级) |
| Level 3 (严重) | CPU > 95% 或 NAS队列 > 90% | 最严格策略 + NAS层Reject + T3346退避 |
sequenceDiagram
participant UE as UE
participant gNB as gNB(NG-RAN)
participant AMF as AMF
participant PCF as PCF
participant UDM as UDM
Note over AMF: AMF检测到过载<br/>(CPU/内存/队列超阈值)
rect rgb(255, 230, 230)
Note over AMF,gNB: === 过载控制启动阶段 ===
AMF->>gNB: NGAP OVERLOAD START<br/>+ Overload Response IE<br/>+ Traffic Load Reduction Indication
Note right of AMF: 指示gNB执行流量抑制策略
Note right of gNB: gNB根据Overload Response<br/>执行差异化流量控制
end
rect rgb(255, 255, 220)
Note over UE,gNB: === 过载期间的信令处理 ===
UE->>gNB: RRC Setup Request<br/>(非紧急MO信令)
gNB-->>UE: RRC Reject<br/>+ waitTime
Note right of gNB: 根据Overload Response<br/>拒绝非紧急MO信令
UE->>gNB: RRC Setup Request<br/>(Emergency/High Priority)
gNB->>AMF: NGAP Initial UE Message<br/>(允许紧急/高优先级通过)
AMF->>gNB: NGAP Initial Context Setup Request
gNB->>UE: RRC Reconfiguration
Note right of gNB: 紧急呼叫和高优先级<br/>始终放行
UE->>gNB: RRC Setup Request<br/>(普通MO Data)
gNB-->>UE: RRC Reject<br/>+ waitTime
Note right of gNB: 根据策略拒绝/延迟<br/>普通数据连接请求
end
rect rgb(220, 255, 220)
Note over AMF,gNB: === NAS层协同退避 ===
UE->>gNB: RRC Setup Request<br/>(MT Data - 被允许)
gNB->>AMF: NGAP Initial UE Message<br/>(Service Request)
AMF-->>UE: NAS Registration/Service Reject<br/>+ Cause: Congestion<br/>+ T3346 Backoff Timer
Note right of AMF: AMF也通过NAS层<br/>直接拒绝部分请求
end
rect rgb(220, 220, 255)
Note over AMF,gNB: === 过载恢复阶段 ===
Note over AMF: AMF检测到负载降低<br/>低于恢复阈值
AMF->>gNB: NGAP OVERLOAD STOP
Note right of gNB: gNB恢复正常操作<br/>接受所有RRC连接请求
UE->>gNB: RRC Setup Request<br/>(之前被拒绝的UE重试)
gNB->>AMF: NGAP Initial UE Message
Note right of gNB: 正常处理流程恢复
end
OVERLOAD START是AMF向NG-RAN节点发送的 unilateral通知消息,不需要gNB回复确认。该消息通过N2接口(NGAP协议)传输,定义于TS 38.413 Section 8.12。
OVERLOAD START ::= SEQUENCE {
protocolIEs ProtocolIE-Container { {OverloadStartIEs} },
...
}
OverloadStartIEs NGAP-ELEMENTARY-PROCEDURE ::= {
{ ID id-OverloadResponse CRITICALITY reject TYPE OverloadResponse PRESENCE mandatory } |
{ ID id-TrafficLoadReductionIndication CRITICALITY ignore TYPE TrafficLoadReductionIndication PRESENCE optional } |
{ ID id-OverloadStartNSSAIList CRITICALITY ignore TYPE OverloadStartNSSAIList PRESENCE optional },
...
}
IE 1: Overload Response(必选)
这是Overload Start消息中最核心的IE,定义了gNB应采取的过载响应动作类型:
| Overload Response选项 | 含义 | 典型场景 |
|---|---|---|
| reject-all-signalling | 拒绝所有新RRC信令连接建立请求(非紧急) | 极端过载 |
| reject-non-emergency-mo-data | 拒绝所有非紧急的MO数据传输RRC建立请求 | 中度过载 |
| permit-emergency-and-mt-only | 仅允许紧急会话和MT(Mobile Terminated)服务 | 重度过载 |
| permit-emergency-mt-high-priority | 允许紧急会话、MT服务和高优先级接入 | 轻/中度过载 |
IE 2: Traffic Load Reduction Indication(可选)
这是一个百分比数值(0~100),表示AMF希望gNB减少的流量比例。例如值为50时,gNB应拒绝约50%的受影响RRC连接请求。gNB的实现策略通常是:
gNB流量抑制实现逻辑(伪代码):
if (random(0, 100) < trafficLoadReductionIndication) {
reject RRC Connection Request;
send RRC Reject with waitTime;
} else {
allow RRC Connection Request;
forward to AMF via NGAP Initial UE Message;
}
IE 3: Overload Start NSSAI List(可选,Rel-16+)
这是5G特有的增强,允许AMF按网络切片(S-NSSAI)进行差异化过载控制。AMF可以指定对特定切片的流量进行抑制,而不影响其他切片:
OverloadStartNSSAIList ::= SEQUENCE (SIZE(1..maxnoofSliceItems)) OF OverloadStartNSSAIItem
OverloadStartNSSAIItem ::= SEQUENCE {
sliceOverloadResponse SliceOverloadResponse,
sliceTrafficLoadReductionIndication SliceTrafficLoadReductionIndication OPTIONAL,
s-NSSAI S-NSSAI
}
这意味着AMF可以对IoT切片实施严格的过载控制,同时保持eMBB切片的正常服务——这是5G相比4G(EPS MME过载控制)的重大架构优势。
当AMF的负载降至恢复阈值以下时,AMF发送OVERLOAD STOP消息通知gNB恢复正常操作:
OVERLOAD STOP ::= SEQUENCE {
protocolIEs ProtocolIE-Container { {OverloadStopIEs} }
}
OVERLOAD STOP消息结构极其简单,不包含任何必选IE(仅可能的可选IE),因为它的语义就是"取消之前OVERLOAD START的所有约束"。gNB收到后立即恢复正常的RRC连接接纳逻辑。
根据TS 38.413 Section 8.12.2,gNB收到OVERLOAD START后必须遵循以下规则:
flowchart TD
A[收到OVERLOAD START] --> B{解析Overload Response IE}
B --> C[存储过载策略到gNB上下文]
C --> D{收到RRC Connection Request}
D --> E{检查UE Access Category<br/>和Access Identity}
E --> F{UE是否属于<br/>豁免类别?}
F -->|Emergency| G[允许RRC建立<br/>正常转发至AMF]
F -->|High Priority AI 11-15| G
F -->|MT Service<br/>寻呼响应| H{Overload Response<br/>是否允许MT?}
H -->|permit-emergency-mt| G
H -->|permit-emergency-mt-hp| G
H -->|reject-all-signalling| I[拒绝RRC建立]
F -->|普通MO信令/数据| J{应用Traffic Load<br/>Reduction概率}
J -->|random < threshold| I
J -->|random >= threshold| G
I --> K[发送RRC Reject<br/>+ waitTime]
L[收到OVERLOAD STOP] --> M[清除过载策略]
M --> N[恢复正常RRC接纳逻辑]
豁免规则:无论Overload Response策略如何严格,以下类型的UE请求始终豁免: - Access Identity 1(MPS/IMS语音紧急呼叫) - Access Identity 2(MCS/关键任务服务) - Access Category 0(紧急呼叫) - Access Identity 11-15(运营商特定高优先级)
AMF的过载控制不仅通过N2向RAN侧施加压力,同时也在NAS层直接拒绝部分已到达AMF的信令请求,形成"双层防线":
flowchart TD
subgraph 第一层防线
A[gNB] -->|Overload Start| B[拒绝部分RRC请求<br/>源头压制]
end
subgraph 第二层防线
C[AMF] -->|NAS Reject + T3346| D[已到达AMF的请求<br/>直接退避]
end
B -->|漏过的流量| C
D --> E[UE进入退避状态<br/>不再发起请求]
当AMF在过载状态下收到NAS消息并决定拒绝时,AMF在NAS Reject消息中携带以下关键IE:
| NAS Reject类型 | Cause Value | 携带的退避定时器 | 规范引用 |
|---|---|---|---|
| Registration Reject | #22 (Congestion) | T3346 (GPRS Timer 3) | TS 24.501 Section 5.3.2 |
| Service Reject | #22 (Congestion) | T3346 | TS 24.501 Section 5.3.3 |
| Deregistration Reject | #22 (Congestion) | T3346 | TS 24.501 Section 5.3.4 |
| 5GMM Status | #22 (Congestion) | — | TS 24.501 Section 5.3.5 |
T3346(GPRS Timer 3)的编码格式定义在TS 24.501 Section 9.11.2.5中:
GPRS Timer 3 IE结构:
┌────────────────────────────────────────┐
│ Bit 8 7 6 5 4 3 2 1 │
├────────────────────────────────────────┤
│ Byte 1: [Unit][Timer Value (5 bits)] │
│ Unit: 00=2秒, 01=1分, 10=6分, 11=拒绝│
│ Timer Value: 0-31 (乘以Unit) │
├────────────────────────────────────────┤
│ Byte 2: 扩展值 (如果使用扩展格式) │
└────────────────────────────────────────┘
示例: Unit=01(1分钟), Value=30 → T3346=30分钟
UE收到携带T3346的NAS Reject后,执行以下动作:
5G网络切片引入了多样化的业务场景。一个典型的场景:智慧城市中百万级IoT传感器同时唤醒上报数据,导致AMF信令风暴。如果采用4G时代的"一刀切"过载控制(MME向所有eNB发送统一的Overload Response),将导致同一区域内的智能手机VoNR通话、URLLC工业控制等业务也被误杀。
Rel-16引入的按切片过载控制解决了这个问题:
flowchart TB
subgraph AMF过载检测
A[AMF检测到过载]
end
subgraph 切片级策略
B[S-NSSAI: IoT切片<br/>Traffic Reduction: 80%<br/>Response: reject-all-signalling]
C[S-NSSAI: eMBB切片<br/>Traffic Reduction: 20%<br/>Response: reject-non-emergency-mo-data]
D[S-NSSAI: URLLC切片<br/>不包含在Overload Start中<br/>→ 不受影响]
end
A --> B
A --> C
A --> D
subgraph gNB差异化执行
E[IoT UE → 80%概率拒绝]
F[eMBB UE → 20%概率拒绝]
G[URLLC UE → 正常服务]
end
B --> E
C --> F
D --> G
gNB通过以下信息关联UE请求与切片策略:
| 信息来源 | 说明 |
|---|---|
| UE的Requested NSSAI | UE在RRC Setup Complete中携带的Requested NSSAI |
| Allowed NSSAI | gNB从AMF的NGAP消息(如Initial Context Setup)中获取的Allowed NSSAI |
| 缺省切片 | 如果UE尚未建立PDU Session,gNB使用UE的Subscribed S-NSSAI匹配 |
| 对比维度 | 4G MME过载控制 | 5G AMF过载控制 |
|---|---|---|
| 接口 | S1AP (S1-MME) | NGAP (N2) |
| 消息名 | OVERLOAD START/STOP | OVERLOAD START/STOP(名称相同) |
| Overload Response选项 | 4种(与5G基本相同) | 4种(继承4G) + 按切片扩展 |
| Traffic Reduction | S1AP有Traffic Load Reduction Indication | NGAP有Traffic Load Reduction Indication |
| 切片级控制 | 不支持(EPS无切片概念) | 支持(Overload Start NSSAI List) |
| NAS退避定时器 | T3446(EMM Backoff Timer) | T3346(5GMM Backoff Timer) |
| AMF Set Load Rebalance | MME Pool内负载重分配 | AMF Set内Weight Factor调整 |
| Nssf协助 | 不涉及 | 可通过Nssf进行切片级AMF选择优化 |
当AMF Set内某个AMF过载时,除了触发N2 Overload Start外,还有一个负载重平衡机制定义在TS 23.501 Section 5.19.5.3:
flowchart LR
subgraph AMF Set
A1[AMF-1<br/>Weight: 0.1<br/>过载]
A2[AMF-2<br/>Weight: 0.5<br/>正常]
A3[AMF-3<br/>Weight: 0.4<br/>正常]
end
subgraph gNB
G1[新UE接入]
end
G1 -->|10%概率| A1
G1 -->|50%概率| A2
G1 -->|40%概率| A3
A1 -.->|Overload Start| G1
A1 -.->|Config Update<br/>Weight: 0→0.1| G1
在N2接口(NGAP层)识别过载控制:
# Wireshark/tshark过滤NGAP Overload Start
ngap.procedureCode == 17
# 过滤Overload Stop
ngap.procedureCode == 18
# 过滤携带T3346的NAS Reject
nas_5gs.message_type == 0x44 && nas_5gs.cause == 22
Overload Start消息在Wireshark中的典型呈现:
NGAP Overload Start
├── AMF Overload Response
│ └── reject-non-emergency-mo-data (1)
├── Traffic Load Reduction Indication
│ └── 50 (即50%流量抑制)
└── Overload Start NSSAI List (如果存在)
├── Item 1:
│ ├── S-NSSAI: SST=1, SD=010203
│ ├── Slice Overload Response: reject-all-signalling
│ └── Slice Traffic Load Reduction: 80
└── Item 2:
├── S-NSSAI: SST=2, SD=040506
├── Slice Overload Response: reject-non-emergency-mo-data
└── Slice Traffic Load Reduction: 30
| 故障现象 | 可能原因 | 排查步骤 |
|---|---|---|
| 大量UE Registration Reject (Cause 22) | AMF过载触发NAS拥塞控制 | 检查AMF CPU/内存指标;查看NGAP Overload Start是否发出 |
| gNB不执行流量抑制 | Overload Start未到达gNB或gNB实现缺陷 | 抓N2接口确认Overload Start是否发送;检查gNB日志中的Overload处理 |
| UE退避时间过长 | T3346配置值过大 | 检查AMF的T3346配置策略;确认是否符合运营商策略 |
| 过载恢复后仍被拒绝 | AMF未发送Overload Stop | 检查AMF恢复阈值配置;确认Overload Stop是否发送 |
| 特定切片UE全部被拒 | Overload Start NSSAI List配置错误 | 检查切片级Traffic Reduction值是否合理 |
| AMF过载但gNB未感知 | Overload Start消息丢失 | 检查SCTP连接状态;确认N2链路是否正常 |
| ## 9. 过载控制状态机 |
从AMF视角,过载控制的状态转换如下:
stateDiagram-v2
[*] --> Normal: AMF启动
Normal --> Overload_Level1: 度量超过阈值L1
Normal --> Overload_Level2: 度量超过阈值L2
Normal --> Overload_Level3: 度量超过阈值L3
Overload_Level1 --> Overload_Level2: 度量恶化超L2阈值
Overload_Level1 --> Normal: 度量低于恢复阈值<br/>发送OVERLOAD STOP
Overload_Level2 --> Overload_Level3: 度量恶化超L3阈值
Overload_Level2 --> Overload_Level1: 度量改善至L1范围
Overload_Level3 --> Overload_Level2: 度量改善至L2范围
Overload_Level1: 轻度过载<br/>N2 Overload Start<br/>Response: permit-emergency-mt-hp
Overload_Level2: 中度过载<br/>升级Overload Response<br/>+ NAS Reject部分请求
Overload_Level3: 严重过载<br/>最严格Response<br/>+ 全量NAS Reject + T3346
Normal: 正常运行<br/>无过载控制约束
note right of Overload_Level1
发送NGAP OVERLOAD START
Traffic Reduction: 20-40%
end note
note right of Overload_Level3
发送升级的OVERLOAD START
Traffic Reduction: 60-100%
可能触发AMF重平衡
end note
| IE名称 | IE ID | 必选/可选 | 类型 | 说明 |
|---|---|---|---|---|
| Overload Response | 50 | M | CHOICE | 指定gNB的过载响应策略(4种选项) |
| Traffic Load Reduction Indication | 56 | O | INTEGER(0..100) | 流量抑制百分比 |
| Overload Start NSSAI List | 182 | O | SEQUENCE OF | 按切片的过载策略列表(Rel-16+) |
| IE名称 | IE ID | 必选/可选 | 类型 | 说明 |
|---|---|---|---|---|
| (无必选IE) | — | — | — | 仅通知gNB停止过载控制 |
| IE名称 | 参考章节 | 说明 |
|---|---|---|
| 5GMM Cause | TS 24.501 Section 9.11.3.2 | 值22表示Congestion |
| T3346 Value (GPRS Timer 3) | TS 24.501 Section 9.11.2.5 | 退避定时器,编码格式见上文 |
| EAP Message | TS 24.501 Section 9.11.2.2 | 如果使用EAP-AKA'鉴权时的拒绝消息 |
Q1: OVERLOAD START消息为什么不需要gNB回复确认? A: 这是3GPP的设计哲学——过载控制场景下,AMF的信令处理能力已经严重不足,要求gNB回复确认只会增加额外的信令负担。AMF采用"best effort"通知模式,发送后即假设gNB会执行。如果SCTP链路正常,消息可靠传输由SCTP层保证。
Q2: Traffic Load Reduction Indication的百分比值是精确的还是近似的? A: 是近似指导值。3GPP TS 38.413明确规定gNB的实现是厂商特定的——gNB只需要"尽力"达到指定的流量抑制比例。实际抑制效果取决于gNB的具体算法(随机丢弃、令牌桶、per-UE计数器等)。
Q3: 如果AMF在Overload Start之后崩溃重启,gNB会一直处于过载抑制状态吗? A: 不会。当AMF崩溃后SCTP关联断开,gNB检测到SCTP连接失败后会清除与该AMF关联的所有状态,包括过载控制状态。当AMF重新建立SCTP连接时,默认是Normal状态,不会自动发送Overload Start。
Q4: N2过载控制和NAS拥塞控制可以同时激活吗? A: 可以,而且这是推荐的组合策略。N2过载控制在RAN侧从源头压制流量(第一道防线),NAS拥塞控制在AMF侧处理漏过的流量(第二道防线)。两者的粒度不同:N2控制是基于整个AMF或切片的粗粒度控制,NAS控制可以基于DNN/S-NSSAI/UE group等细粒度控制。
Q5: 按切片的过载控制中,gNB如何在RRC阶段就识别UE的切片? A: 这是一个实际挑战。在Initial Registration阶段,UE尚未建立PDU Session,gNB只能依赖UE在RRC Setup Complete中携带的Requested NSSAI来推断切片归属。如果UE未携带Requested NSSAI,gNB可能无法在RRC阶段执行精确的切片级过载控制。这是3GPP规范中一个已知的实现灵活性区域。
本文由「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 等场景全覆盖。
