在5G核心网架构中,AMF(Access and Mobility Management Function)是所有UE接入的第一道关口,承担着注册管理、连接管理、可达性管理和NAS信令传递四大核心职责。当信令风暴(Signaling Storm)来袭——无论是海量物联网设备同时上线、突发事件引发集中注册潮、还是NF异常导致信令重传风暴——AMF首当其冲。
3GPP在TS 23.501 Section 5.19.5.2和TS 23.502 Section 4.2.5中定义了AMF过载控制的完整框架。与4G时代MME仅依赖S1AP Overload单一机制不同,5G引入了三层立体防护体系:
| 层次 | 接口 | 协议 | 核心机制 | 规范依据 |
|---|---|---|---|---|
| 第一层:N2过载控制 | N2 (AMF↔gNB) | NGAP | Overload Start/Stop | TS 38.413 Section 8.7.7 |
| 第二层:NAS拥塞控制 | N1 (AMF↔UE) | 5GMM/5GSM | Back-off Timer + Cause Code | TS 24.501 Section 5.5 |
| 第三层:SBI过载控制 | SBI (AMF↔其他NF) | HTTP/2 | 503/429/OCI Header | TS 29.500 Section 6.4 |
这三层机制协同工作,从RAN侧节流、UE侧退避、NF侧限流三个维度,构成AMF过载保护的完整闭环。
flowchart TB
subgraph 过载源["信令过载来源"]
A1["海量IoT设备同时上线"]
A2["突发事件集中注册潮"]
A3["NF异常导致信令重传"]
A4["恶意信令风暴攻击"]
end
subgraph AMF["AMF 过载控制三层防护"]
B1["第一层: N2过载控制<br/>NGAP Overload Start/Stop<br/>→ gNB侧节流"]
B2["第二层: NAS拥塞控制<br/>Registration/Service Reject<br/>+ T3346/T3525退避定时器<br/>→ UE侧退避"]
B3["第三层: SBI过载控制<br/>HTTP 503/429 + OCI Header<br/>→ NF侧限流"]
end
subgraph 监控["AMF内部监控"]
C1["CPU利用率"]
C2["内存使用率"]
C3["NAS连接数"]
C4["消息队列深度"]
C5["信令处理延迟"]
end
A1 & A2 & A3 & A4 --> B1 & B2 & B3
C1 & C2 & C3 & C4 & C5 -->|"触发阈值"| B1 & B2 & B3
当AMF检测到自身过载时,首先通过N2接口向所有连接的gNB发送NGAP Overload Start消息。该消息定义在TS 38.413 Section 8.7.7.1,是AMF→NG-RAN方向的非UE关联信令(Non-UE associated signalling)。
根据TS 38.413规范,Overload Start消息的关键IE如下:
| IE名称 | 是否必选 | 类型 | 说明 |
|---|---|---|---|
| AMF Name | M(必选) | OCTET STRING | 过载AMF的标识 |
| Overload Response | M | ENUMERATED | 告知gNB应采取的过载响应动作 |
| Traffic Load Reduction Indication | O(可选) | INTEGER(0..100) | 请求gNB减少的信令流量百分比 |
| Overload Start NSSAI List | O | SEQUENCE OF | 针对特定S-NSSAI切片的过载控制 |
其中,Overload Response是整个消息的灵魂,定义了四种响应动作:
| 动作值 | 含义 | gNB行为 |
|---|---|---|
| overload-reject-all-non-emergency-sessions | 拒绝非紧急会话 | gNB拒绝所有非紧急的初始NAS消息,仅允许紧急注册/呼叫 |
| overload-reject-all-new-sessions | 拒绝所有新会话 | gNB拒绝所有新建立的NAS信令连接 |
| overload-allow-emergency-and-high-priority-only | 仅允许紧急和高优先级 | gNB仅转发紧急和高优先级接入类别(Access Identity 1/2) |
| overload-reject-all-new-sessions-except-emergency-and-mobility | 仅允许紧急和移动性注册 | gNB拒绝新会话但允许移动性注册和紧急业务 |
sequenceDiagram
participant AMF
participant gNB1 as gNB-1
participant gNB2 as gNB-2
participant gNB3 as gNB-3
Note over AMF: 监控到CPU>85%<br/>NAS连接数>阈值<br/>消息队列积压
AMF->>gNB1: NGAP Overload Start<br/>Overload Response = reject-all-non-emergency<br/>Traffic Load Reduction = 60%
AMF->>gNB2: NGAP Overload Start<br/>Overload Response = reject-all-non-emergency<br/>Traffic Load Reduction = 60%
AMF->>gNB3: NGAP Overload Start<br/>Overload Response = allow-emergency-high-priority-only<br/>Overload Start NSSAI List = SST:1 SD:010203
Note over gNB1,gNB2: 开始按60%比例<br/>丢弃非紧急NAS信令
Note over gNB3: 仅转发紧急会话<br/>且仅限特定切片
gNB1--xAMF: RRC Reject (非紧急UE)
gNB2--xAMF: 拒绝新NAS连接
Note over AMF: 过载缓解<br/>CPU<60%
AMF->>gNB1: NGAP Overload Stop
AMF->>gNB2: NGAP Overload Stop
AMF->>gNB3: NGAP Overload Stop
Note over gNB1,gNB3: 恢复正常信令转发
Traffic Load Reduction Indication IE是一个0到100的整数值,表示AMF希望gNB减少的信令流量百分比。例如,值为60表示gNB应当只转发40%的非紧急信令流量。
这个机制的设计精妙之处在于渐进式过载恢复:
这种渐进式设计避免了"全有全无"的粗暴方式,保障了关键业务(紧急呼叫、高优先级政府/公共安全用户)的连续性。
5G引入了网络切片概念,AMF可以为不同切片施加差异化的过载控制策略。通过Overload Start NSSAI List IE,AMF可以:
这一点在TS 23.501 Section 5.19.5.2中有明确描述:AMF可以根据收到的信令风暴分析信息(来自NWDAF,参见TS 23.288 Section 6.22),针对特定UE组、特定切片或特定优先级进行精细化过载控制。
当AMF恢复正常运行状态后,发送NGAP Overload Stop消息(TS 38.413 Section 8.7.7.2),通知gNB恢复正常信令转发。该消息结构极为简洁:
| IE名称 | 是否必选 | 说明 |
|---|---|---|
| AMF Name | M | 恢复正常的AMF标识 |
gNB收到Overload Stop后,立即停止所有过载节流动作,恢复正常信令转发。
当N2过载控制不足以缓解AMF压力时,AMF启用NAS层拥塞控制——直接在UE层面进行信令抑制。该机制定义在TS 24.501 Section 5.5中。
NAS拥塞控制的核心逻辑是:AMF在拒绝UE的NAS请求时,携带退避定时器(Back-off Timer),要求UE在指定时间窗口内不再发起同类请求。
sequenceDiagram
participant UE
participant gNB
participant AMF
UE->>gNB: RRC Connection Request
gNB->>UE: RRC Connection Setup
UE->>gNB: RRC Connection Setup Complete<br/>(NAS Registration Request)
gNB->>AMF: NGAP Initial UE Message<br/>(NAS: Registration Request)
Note over AMF: NAS拥塞状态<br/>拒绝非紧急注册
AMF->>gNB: NGAP Downlink NAS Transport<br/>(NAS: Registration Reject)
gNB->>UE: NAS Registration Reject<br/>5GMM Cause #22 (Congestion)<br/>T3346 = 300秒
Note over UE: 启动T3346定时器<br/>300秒内不发起<br/>非紧急注册请求
UE->>UE: T3346超时
UE->>gNB: RRC Connection Request<br/>(重新尝试注册)
gNB->>AMF: NGAP Initial UE Message<br/>(NAS: Registration Request)
AMF->>gNB: NGAP Initial Context Setup Request<br/>(NAS: Registration Accept)
NAS层拥塞控制涉及多个退避定时器,分别对应不同的NAS流程:
| 定时器 | 适用流程 | 携带消息 | 5GMM Cause | 取值范围 |
|---|---|---|---|---|
| T3346 | 注册/移动性管理 | Registration Reject / Service Reject | #22 (Congestion) | 5秒~30分钟 |
| T3525 | PDU Session Establishment | PDU Session Establishment Reject | #27 (Missing or unknown DNN) / #67 (Insufficient resources) | 5秒~30分钟 |
| T3502 | 通用NAS退避 | Configuration Update Command | N/A(配置值) | 1秒~3600秒 |
| T3511 | SMS over NAS | 配置消息 | N/A | 5秒~45分钟 |
其中,T3346是最重要的拥塞退避定时器。值得注意的是:
AMF在拒绝NAS请求时携带的原因值(5GMM Cause Code)决定了UE的后续行为:
| Cause Code | 含义 | UE行为 |
|---|---|---|
| #22 (Congestion) | 网络拥塞 | UE启动T3346退避定时器,期间不发起注册 |
| #27 (Missing or unknown DNN) | DNN未知/缺失 | UE启动T3525退避定时器,不重试该DNN |
| #67 (Insufficient resources) | 资源不足 | UE启动T3525退避定时器 |
| #3 (Illegal UE) | 非法UE | UE停止所有NAS过程(非拥塞场景) |
| #11 (PLMN not allowed) | PLMN不允许 | UE将该PLMN加入禁止列表 |
| #13 (Roaming not allowed in TA) | TA区域不允许漫游 | UE将该TA加入禁止列表 |
在拥塞场景中,AMF应使用Cause #22,这是标准的拥塞拒绝原因值。
与N2层类似,NAS层也支持切片感知的拥塞控制。当AMF在Registration Reject或PDU Session Establishment Reject中携带Rejected NSSAI IE时,UE会针对被拒绝的S-NSSAI启动退避机制,而不影响其他切片的注册和使用。
Rejected NSSAI IE中可以包含: - 被拒绝的S-NSSAI值 - 拒绝原因值(如拥塞、不支持、未授权) - 退避定时器值(仅针对该S-NSSAI)
5G核心网采用SBA(Service Based Architecture),AMF与其他NF(如UDM、SMF、PCF、NSSF)之间通过HTTP/2接口通信。当AMF过载时,它需要向调用其服务的NF消费者反馈过载信息。
TS 29.500 Section 6.4定义了三种SBI过载控制模式:
模式一:HTTP状态码反馈
| HTTP状态码 | 含义 | 调用方行为 |
|---|---|---|
| 503 Service Unavailable | 服务不可用(携带Retry-After头) | 调用方等待Retry-After秒后重试 |
| 429 Too Many Requests | 请求过于频繁 | 调用方降低请求速率 |
| 307 Temporary Redirect | 临时重定向到其他AMF实例 | 调用方将请求重定向到目标AMF |
模式二:OCI(Overload Control Information)Header
OCI是一种更精细的过载控制机制,通过HTTP响应头传递过载控制信息。OCI Header包含:
| 参数 | 说明 |
|---|---|
| OCI-RI(Redirection Indicator) | 指示是否需要将请求重定向到其他NF实例 |
| OCI-RI-Target | 重定向目标NF的URI |
| overload-pct | 过载百分比(0-100),100表示完全过载 |
| overload-info | 过载原因和附加信息 |
模式三:NRF负载感知
AMF在向NRF注册时(Namf_Registration),可以更新自身的负载信息和容量。NRF在进行NF发现(Nnrf_NFDiscovery)时,会将负载因素纳入选择算法,将新请求引导到负载较轻的AMF实例。
flowchart TD
subgraph NF消费者
SMF["SMF"]
UDM["UDM"]
PCF["PCF"]
AUSF["AUSF"]
end
subgraph SBI过载控制
M1["模式一: HTTP状态码<br/>503 + Retry-After<br/>429 + 速率限制<br/>307 + 重定向"]
M2["模式二: OCI Header<br/>overload-pct<br/>OCI-RI Target"]
M3["模式三: NRF负载感知<br/>NF负载上报<br/>加权选择"]
end
subgraph AMF集群
A1["AMF-1<br/>负载 92%"]
A2["AMF-2<br/>负载 45%"]
A3["AMF-3<br/>负载 38%"]
end
SMF & UDM & PCF & AUSF -->|"HTTP/2 请求"| M1 & M2
M1 & M2 -->|"反馈过载"| SMF & UDM & PCF & AUSF
M3 -->|"引导至轻载实例"| A2 & A3
AMF不仅是SBI服务的提供者,也是其他NF服务的消费者(例如调用Nudm_SDM_Get获取用户签约数据、调用Nsmf_PDUSession_CreateSMContext建立PDU会话上下文)。当AMF调用其他NF时遇到过载响应,需要遵循以下策略:
AMF内部维护一个过载状态机,驱动三层防护机制的协同工作:
stateDiagram-v2
[*] --> Normal: 系统启动
Normal --> Early_Warning: CPU>70% 或<br/>NAS连接数>80%阈值
Early_Warning --> Normal: 负载回落
Early_Warning --> Moderate_Overload: CPU>80% 或<br/>消息队列积压
Moderate_Overload --> Early_Warning: 负载下降
Moderate_Overload --> Severe_Overload: CPU>90% 或<br/>消息处理超时率>5%
Moderate_Overload --> Normal: 负载恢复正常
Severe_Overload --> Moderate_Overload: 负载缓解
Severe_Overload --> Critical_Overload: CPU>95% 或<br/>系统濒临崩溃
Severe_Overload --> Moderate_Overload: 部分恢复
Critical_Overload --> Severe_Overload: 负载缓解
state Early_Warning {
[*] --> SBI_Throttle
SBI_Throttle: SBI层: 上报NRF负载升高
SBI_Throttle: N2层: 无动作
SBI_Throttle: NAS层: 无动作
}
state Moderate_Overload {
[*] --> N2_Throttle
N2_Throttle: SBI层: 503+Retry-After
N2_Throttle: N2层: Overload Start<br/>Response=reject-non-emergency<br/>Reduction=30%
N2_Throttle: NAS层: 无直接动作
}
state Severe_Overload {
[*] --> NAS_Congestion
NAS_Congestion: SBI层: 503+OCI Header
NAS_Congestion: N2层: Overload Start<br/>Response=allow-emergency-only<br/>Reduction=60%
NAS_Congestion: NAS层: Registration Reject<br/>Cause#22 + T3346
}
state Critical_Overload {
[*] --> Full_Protection
Full_Protection: SBI层: 503 全部拒绝
Full_Protection: N2层: Overload Start<br/>Response=reject-all<br/>Reduction=100%
Full_Protection: NAS层: 全部拒绝<br/>仅保留紧急会话
}
| 维度 | 4G MME过载控制 | 5G AMF过载控制 |
|---|---|---|
| RAN侧接口 | S1AP Overload Start/Stop(TS 36.413) | NGAP Overload Start/Stop(TS 38.413) |
| NAS退避定时器 | T3346(EMM层) | T3346/T3525(5GMM/5GSM层) |
| 切片感知 | ❌ 无(4G无切片概念) | ✅ 支持S-NSSAI级过载控制 |
| SBI过载控制 | ❌ 无(4G使用Diameter/GTP-C) | ✅ HTTP/2 503/429/307 + OCI Header |
| NF发现负载感知 | DNS轮询(粗粒度) | NRF加权选择(细粒度) |
| NWDAF集成 | ❌ 无 | ✅ NWDAF提供信令风暴预测(TS 23.288) |
| AMF Set/Pool | MME Pool(SGSN Pool) | AMF Set(支持更灵活的负载重分配) |
| 退避粒度 | PLMN级 | PLMN + S-NSSAI + 接入类别级 |
5G相较4G最大的进步在于切片感知和NWDAF智能预测两个方面。NWDAF可以根据历史数据和实时分析,在信令风暴真正形成之前就通知AMF提前启动过载保护。
当部署AMF Set(多个AMF实例组成逻辑集合)时,过载控制策略需要全局协调:
场景:AMF Set内单实例过载
当AMF-1过载时,除了启动上述三层防护机制外,还应:
sequenceDiagram
participant gNB
participant NRF
participant AMF1 as AMF-1<br/>(负载92%)
participant AMF2 as AMF-2<br/>(负载45%)
participant UDM
AMF1->>NRF: Nnrf_NFUpdate<br/>负载=92%, 容量=低
Note over NRF: 更新AMF-1负载信息
gNB->>NRF: Nnrf_NFDiscovery<br/>查找可用AMF
NRF->>gNB: 返回AMF-2(负载最优)
gNB->>AMF2: NGAP Initial UE Message<br/>(新UE注册引导至AMF-2)
Note over AMF1: 对已连接UE<br/>启动过载控制
AMF1->>gNB: NGAP Overload Start<br/>Reduction=40%
AMF1->>AMF1: 对部分已注册UE<br/>发起UE Configuration Update
AMF1->>AMF2: Namf_Communication<br/>转移UE上下文
在实际网络运维中,使用Wireshark/TShark抓包识别AMF过载流程:
NGAP Overload Start/Stop消息过滤:
# 过滤NGAP Overload Start消息
tshark -i eth0 -f "tcp port 38412" \
-Y "ngap.procedureCode == 17 && ngap.initiatingMessage"
# 过滤NGAP Overload Stop消息
tshark -i eth0 -f "tcp port 38412" \
-Y "ngap.procedureCode == 18 && ngap.initiatingMessage"
NAS Registration Reject(拥塞原因)过滤:
# 过滤NAS Registration Reject Cause #22
tshark -i eth0 -f "tcp port 38412" \
-Y "nas-5gs.regist.reject && nas-5gs.cause == 22"
SBI 503/429响应过滤:
# 过滤AMF返回的503/429响应
tshark -i eth0 -f "tcp port 8000" \
-Y "http2.response.code == 503 || http2.response.code == 429"
| 故障现象 | 可能原因 | 排错思路 |
|---|---|---|
| 大面积Registration Reject | AMF过载导致N2+NAS双层拒绝 | 检查AMF CPU/内存,查看NGAP Overload Start是否发出 |
| gNB未执行节流 | gNB未正确处理Overload Start消息 | 抓包确认gNB收到Overload Start,检查gNB日志 |
| UE退避后立即重试 | T3346定时器值设置过短 | 检查Registration Reject中的T3346 IE值 |
| 过载恢复后仍被拒绝 | Overload Stop未发送或未到达gNB | 抓包确认Overload Stop是否发送并到达 |
| 仅特定切片用户被拒 | AMF针对特定S-NSSAI施加过载控制 | 检查Overload Start NSSAI List内容 |
| SBI调用持续失败 | 其他NF过载,AMF未正确处理503/429 | 检查AMF到其他NF的HTTP/2交互日志 |
| ## 九、NWDAF与AMF过载预测的联动(Rel-18/19增强) |
3GPP从Rel-18开始,通过NWDAF(Network Data Analytics Function)为AMF过载控制引入了预测性保护能力。TS 23.288 Section 6.22定义了"Signalling Storm Analytics"功能:
这种从"被动过载保护"到"主动信令风暴预防"的演进,是5G Advanced阶段的核心网自优化能力之一。
下面展示一个完整的AMF过载控制生命周期,包含三层防护的协同工作:
sequenceDiagram
participant UE1 as 普通UE
participant UE2 as 紧急UE
participant gNB
participant AMF
participant SMF
participant UDM
participant NRF
Note over AMF: T0: 正常运行状态
Note over AMF: T1: 大量IoT设备同时注册<br/>CPU升至85%
rect rgb(255, 230, 230)
Note over AMF: 第一阶段:SBI+轻微N2节流
AMF->>NRF: Nnrf_NFUpdate(负载=85%)
AMF->>gNB: NGAP Overload Start<br/>Response=reject-non-emergency<br/>Reduction=20%
end
Note over UE1: UE1发起注册
UE1->>gNB: NAS Registration Request
Note over gNB: gNB按20%比例随机丢弃
gNB--xUE1: RRC Reject(被节流)
Note over AMF: T2: 负载继续上升至92%
rect rgb(255, 200, 200)
Note over AMF: 第二阶段:加强N2节流+NAS拥塞
AMF->>gNB: NGAP Overload Start<br/>Response=allow-emergency-high-priority<br/>Reduction=60%
end
UE1->>gNB: NAS Registration Request
gNB->>AMF: NGAP Initial UE Message
AMF->>gNB: NGAP DL NAS Transport
gNB->>UE1: Registration Reject<br/>Cause #22, T3346=300s
Note over UE1: 300秒内不再注册
UE2->>gNB: NAS Registration Request<br/>(Emergency)
gNB->>AMF: NGAP Initial UE Message<br/>(Emergency Registration)
Note over AMF: 紧急注册不受过载控制
AMF->>UDM: Nudm_SDM_Get
UDM-->>AMF: 签约数据
AMF->>gNB: Registration Accept
Note over AMF: AMF调用SMF遭遇过载
AMF->>SMF: Nsmf_PDUSession_CreateSMContext
SMF-->>AMF: HTTP 503 + Retry-After:30
Note over AMF: 30秒后重试SMF
Note over AMF: T3: 负载下降至65%
rect rgb(230, 255, 230)
Note over AMF: 第三阶段:逐步恢复
AMF->>gNB: NGAP Overload Start<br/>Response=reject-non-emergency<br/>Reduction=10%
end
Note over AMF: T4: 负载降至50%
AMF->>gNB: NGAP Overload Stop
AMF->>NRF: Nnrf_NFUpdate(负载=50%)
Note over AMF,gNB: 恢复正常运行
Q1: AMF的N2过载控制和NAS拥塞控制有什么区别?什么时候该用哪个?
A: N2过载控制(NGAP Overload Start/Stop)作用在AMF与gNB之间,gNB根据Overload Response动作和Traffic Load Reduction比例在RAN侧直接丢弃或拒绝信令,信令根本不会到达AMF。NAS拥塞控制则作用在AMF与UE之间,AMF收到NAS消息后返回拒绝响应并携带退避定时器,信令已经到达AMF但被拒绝处理。实际部署中两者配合使用:先用N2过载控制在RAN侧截流,仍到达AMF的过量信令再用NAS拥塞控制处理。
Q2: Traffic Load Reduction Indication值为0或100分别意味着什么?
A: 值为0表示gNB不需要减少任何信令流量(实际上等同于不发送Overload Start)。值为100表示gNB应当减少100%的指定类型信令,即完全停止转发该类信令。实际部署中,典型的取值范围是20%~80%,避免0和100的极端情况。
Q3: AMF过载时紧急呼叫是否受影响?
A: 不会。3GPP规范明确要求所有过载控制机制都必须豁免紧急业务。无论Overload Response取值为何,紧急注册和紧急呼叫始终不受限制。UE使用Access Identity 2标识紧急接入,gNB和AMF在过载控制中对该类接入不做限制。
Q4: Open5GS是否支持完整的AMF过载控制?
A: Open5GS目前(截至v2.7.x)提供了基础的NGAP Overload Start/Stop消息编解码框架(在ngap-build.c/ngap-handler.c中),但完整的过载检测(CPU/内存监控)、动态Traffic Load Reduction调整和NAS层拥塞控制(T3346分配)尚未完全实现。社区Discussion #3638中有相关实现讨论。
Q5: AMF Set内某个AMF过载时,如何将UE迁移到其他AMF?
A: 主要有三种方式:(1) AMF通过UE Configuration Update Procedure(TS 23.502 Section 4.2.4.2)通知UE重新注册,UE重新注册时由NRF引导到负载较轻的AMF;(2) AMF通过N1/N2接口转移机制将UE上下文迁移到目标AMF;(3) gNB后续的新UE连接通过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 等场景全覆盖。
