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过载的判定是厂商实现相关的,3GPP规范不规定具体算法,但定义了触发过载控制行为的框架条件:
| 维度 | 典型阈值触发 | 参考来源 |
|---|---|---|
| CPU利用率 | 超过配置的高水位线(如80%/90%/95%多级) | 厂商实现 |
| 内存占用 | UE Context数量逼近最大容量 | 厂商实现 |
| N2 SCTP连接 | 每条SCTP关联的待处理消息队列深度超限 | TS 38.412 |
| NAS信令队列 | 待处理的NAS PDU积压超过阈值 | 厂商实现 |
| NF Service负载 | Namf接口HTTP请求速率超限 | TS 29.500 |
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。
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检测到过载<br/>(CPU 92%, UE Context满)
rect rgb(255, 200, 200)
Note over AMF,gNB2: 阶段1: 过载通知下发
AMF->>gNB1: NGAP OVERLOAD START<br/>OverloadResponse = reject non-emergency MO Data<br/>TrafficLoadReductionIndication = 60%
AMF->>gNB2: NGAP OVERLOAD START<br/>OverloadResponse = reject non-emergency MO Data<br/>TrafficLoadReductionIndication = 60%
Note over gNB1: gNB-1按照60%比例<br/>拒绝非紧急MO Data的RRC建立
Note over gNB2: gNB-2按照60%比例<br/>拒绝非紧急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<br/>waitTime = 8s
Note over gNB1: 随机丢弃60%的<br/>非紧急MO Data请求
UE2->>gNB1: RRC Connection Request (Emergency)
gNB1->>AMF: NGAP Initial UE Message<br/>(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<br/>OverloadResponse = emergency sessions only<br/>TrafficLoadReductionIndication = 90%
AMF->>gNB2: NGAP OVERLOAD START<br/>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
OVERLOAD START是非UE关联的NGAP信令(Non-UE-associated Signalling),在AMF与gNB之间的SCTP关联上发送,不需要gNB回复确认。
根据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 },
...
}
| IE名称 | 存在性 | 类型 | 说明 |
|---|---|---|---|
| OverloadResponse | 必选 | 枚举组合 | 定义gNB应采取的过载动作,可包含多个动作 |
| TrafficLoadReductionIndication | 可选 | 整数(0..100) | 百分比指示gNB应减少多少N2流量 |
| OverloadStartNSSAIList | 可选(Rel-16+) | S-NSSAI列表 | 按切片粒度控制过载,仅对特定切片抑制 |
这是整个过载控制机制的核心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 | 仅允许紧急会话 | 极度过载 |
graph TD
A[OVERLOAD START Message] --> B[OverloadResponse IE<br/>Mandatory]
A --> C[TrafficLoadReductionIndication<br/>Optional: 0-100%]
A --> D[OverloadStartNSSAIList<br/>Optional: Rel-16+]
B --> E[Overload Action 1:<br/>reject-non-emergency-mo-data]
B --> F[Overload Action 2:<br/>reject-non-emergency-mo-signalling]
B --> G[Overload Action 3:<br/>permit-emergency-sessions-and-mt-access-only]
B --> H[Overload Action 4:<br/>permit-emergency-sessions-only]
D --> I[S-NSSAI 1<br/>e.g. eMBB: 010001]
D --> J[S-NSSAI 2<br/>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
这个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
Rel-16引入的重要增强,允许AMF对特定网络切片进行精准过载控制:
当UE的NAS信令已经到达AMF但AMF无法处理时,AMF在NAS层直接进行拒绝。这与N2层控制互补——N2控制在gNB侧拦截请求,NAS控制在AMF侧拒绝已到达的请求。
| 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在退避期间不得重新发起同类请求。
根据TS 24.501 Section 5.5.1.3.5:
stateDiagram-v2
[*] --> Idle: UE已注册
Idle --> Attempting: 发起Registration Request
Attempting --> Rejected: 收到Reg Reject #22 + T3346
Rejected --> Backoff: 启动T3346定时器<br/>(如30分钟)
Backoff --> Backoff_Hold: UE收到寻呼/紧急呼叫
Backoff_Hold --> Backoff: 紧急呼叫结束<br/>T3346继续运行
Backoff --> Idle: T3346超时<br/>可重新发起请求
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分钟
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%<br/>触发过载控制
par N2通道抑制
AMF->>gNB: NGAP OVERLOAD START<br/>Action: reject MO Data<br/>Reduction: 70%
Note over gNB: gNB开始按70%概率<br/>丢弃MO Data RRC请求
and NAS通道抑制准备
Note over AMF: 配置NAS Congestion Control<br/>Reject Cause #22<br/>T3346 = 30 min
end
Note over UE1: 新UE尝试接入
UE1->>gNB: RRC Connection Request (MO Data)
Note over gNB: random(0,100)=45 < 70<br/>丢弃此请求
gNB-->>UE1: RRC Connection Reject<br/>waitTime = 16s
Note over UE1: UE启动waitTime定时器<br/>16s内不重试
Note over UE2: 已连接UE发起Service Request
UE2->>gNB: RRC Connection Request (MO Signaling)
Note over gNB: MO Signaling不在抑制范围<br/>正常转发
gNB->>AMF: NGAP Initial UE Message<br/>(Service Request)
Note over AMF: NAS层判断:AMF过载中<br/>拒绝Service Request
AMF->>gNB: NGAP Downlink NAS Transport<br/>(Service Reject #22 + T3346=30min)
gNB->>UE2: RRC: DLInformationTransfer<br/>(NAS Service Reject)
Note over UE2: UE启动T3346=30分钟<br/>30分钟内不发起Service Request
Note over AMF: AMF负载恢复
AMF->>gNB: NGAP OVERLOAD STOP
Note over gNB: 恢复正常
除了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应按照指示的比例减少后续请求。
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
stateDiagram-v2
[*] --> Normal: AMF启动
Normal --> MinorOverload: CPU > 80%<br/>或UE Context > 70%
MinorOverload --> Normal: CPU < 60%<br/>持续30秒
MinorOverload --> ModerateOverload: CPU > 90%<br/>或UE Context > 85%
ModerateOverload --> MinorOverload: CPU < 75%<br/>持续30秒
ModerateOverload --> SevereOverload: CPU > 95%<br/>或UE Context > 95%
SevereOverload --> ModerateOverload: CPU < 85%<br/>持续30秒
SevereOverload --> CriticalOverload: CPU > 99%<br/>或资源耗尽
CriticalOverload --> SevereOverload: CPU < 90%<br/>持续60秒
state Normal {
[*] --> FullService
FullService: 接受所有类型请求
}
state MinorOverload {
[*] --> RejectMOData
RejectMOData: NGAP: reject-non-emergency-mo-data<br/>Reduction: 30%<br/>NAS: T3346=5min
}
state ModerateOverload {
[*] --> RejectMOSignaling
RejectMOSignaling: NGAP: reject MO Signaling<br/>Reduction: 50%<br/>NAS: T3346=15min
}
state SevereOverload {
[*] --> EmergencyAndMTOnly
EmergencyAndMTOnly: NGAP: emergency+MT only<br/>Reduction: 80%<br/>NAS: T3346=30min
}
state CriticalOverload {
[*] --> EmergencyOnly
EmergencyOnly: NGAP: emergency only<br/>Reduction: 95%<br/>NAS: T3346=60min
}
识别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)
| 故障现象 | 可能原因 | 排查思路 |
|---|---|---|
| 大量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,实现更精细的端到端流量管理。
N2通道抑制(NGAP Overload Start)和NAS通道抑制(5GMM Reject)各有不可替代的作用:
N2通道抑制是"预防性"的:在gNB侧就拦截了大部分不需要的请求,保护了AMF的SCTP接收缓冲区和NAS解析资源。这是效率最高的方式——请求根本不会到达AMF。
NAS通道抑制是"兜底性"的:对于已经通过N2到达AMF的请求(例如在Overload Start消息到达gNB之前已经发出的请求,或者不在OverloadResponse排除范围内的请求类型),NAS层提供最后一道防线。
NGAP Overload Start和Overload Stop都是非UE关联的单向通知消息,不需要gNB回复。这样设计的原因:
在所有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粒度进行过载控制,避免一刀切。
本文由「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 等场景全覆盖。
