首页 › core-network › 5G AMF过载控制N2/NAS双通道抑制拆解

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 完整信令时序图

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

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结构图

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

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对特定网络切片进行精准过载控制:

四、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:

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分钟

4.4 NAS层与N2层协同抑制流程

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: 恢复正常

五、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过载状态转换

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
    }

七、抓包识别与故障排查

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)各有不可替代的作用:

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 — Section 4.22: Overload Control
  2. 3GPP TS 23.501 Section 5.19.5.2 — AMF Overload Control
  3. 3GPP TS 38.413 V18.6.0 — 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 — N2/NAS Overload Control实现配置
  5. 3glteinfo 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 等场景全覆盖。

51学通信知识星球海报-扫码加入