首页 › core-network › 5G AMF过载控制N2节流与退避信令拆解

5G AMF过载控制:N2节流与NAS退避信令全链路拆解

1. 机制背景与设计动机

在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层拥塞处理)


2. AMF过载检测:从内部度量到阈值触发

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退避

3. N2过载控制信令流程全解

3.1 完整信令时序图

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

3.2 NGAP OVERLOAD START消息深度解析

OVERLOAD START是AMF向NG-RAN节点发送的 unilateral通知消息,不需要gNB回复确认。该消息通过N2接口(NGAP协议)传输,定义于TS 38.413 Section 8.12。

消息结构(ASN.1抽象语法)

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详解

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过载控制)的重大架构优势。

3.3 NGAP OVERLOAD STOP消息

当AMF的负载降至恢复阈值以下时,AMF发送OVERLOAD STOP消息通知gNB恢复正常操作:

OVERLOAD STOP ::= SEQUENCE {
    protocolIEs    ProtocolIE-Container { {OverloadStopIEs} }
}

OVERLOAD STOP消息结构极其简单,不包含任何必选IE(仅可能的可选IE),因为它的语义就是"取消之前OVERLOAD START的所有约束"。gNB收到后立即恢复正常的RRC连接接纳逻辑。

3.4 gNB侧行为规范

根据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(运营商特定高优先级)


4. NAS层拥塞控制与T3346退避机制

4.1 NAS层与N2层的协同

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/>不再发起请求]

4.2 NAS Reject消息中的关键参数

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

4.3 UE收到T3346后的行为

UE收到携带T3346的NAS Reject后,执行以下动作:

  1. 启动T3346定时器,进入NAS-CONGESTION状态
  2. 在T3346运行期间,禁止发起以下NAS过程: - Registration Request(紧急注册除外) - Service Request(紧急服务除外) - Mobility Registration Update
  3. 仍允许的NAS过程: - 紧急注册/紧急服务请求 - 高优先级接入 - Mobile Terminated请求的响应
  4. T3346超时后,UE可以重新发起NAS请求
  5. 如果UE在T3346运行期间收到同PLMN的新T3346值,替换当前值(取较小值)

5. 按切片差异化过载控制(Rel-16/18增强)

5.1 设计动机

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

5.2 gNB识别切片的方法

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匹配

6. 与4G MME过载控制的对比

对比维度 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选择优化

7. AMF Set负载重平衡(关联机制)

当AMF Set内某个AMF过载时,除了触发N2 Overload Start外,还有一个负载重平衡机制定义在TS 23.501 Section 5.19.5.3:

  1. 过载AMF通过AMF Configuration Update消息修改NGAP中的AMF Weight Factor
  2. Weight Factor降低意味着gNB在选择AMF时分配更少的UE给该AMF
  3. 新的Initial Registration请求会被gNB通过AMF Set内的其他AMF处理
  4. 已注册的UE可以通过Configuration Update Command触发重注册到负载较轻的AMF
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

8. 抓包识别与故障排查

8.1 抓包识别方法

在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

8.2 常见故障场景

故障现象 可能原因 排查步骤
大量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

10. 完整信息元素参考表

NGAP OVERLOAD START消息IE汇总

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+)

NGAP OVERLOAD STOP消息IE汇总

IE名称 IE ID 必选/可选 类型 说明
(无必选IE) — — — 仅通知gNB停止过载控制

NAS Reject中的关键IE

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规范中一个已知的实现灵活性区域。


参考来源

  1. 3GPP TS 38.413 V18.6.0 — NG-RAN; NG Application Protocol (NGAP) — Section 8.12 Overload Start, Section 8.13 Overload Stop, Section 9.2.1.34 Overload Response IE
  2. 3GPP TS 23.501 V18.x — 5G System Architecture — Section 5.19.5.2 AMF Overload Control, Section 5.19.5.3 AMF Load Rebalancing
  3. 3GPP TS 24.501 V18.x — NAS for 5GS — Section 5.3 NAS Congestion Control, Section 9.11.2.5 GPRS Timer 3
  4. Cisco Ultra Cloud Core 5G AMF Overload Control Guide — N2和NAS过载控制配置与行为说明
  5. 3GLTEInfo — 5G NGAP Overload Start Message — NGAP消息结构与IE参考
  6. IEEE — Congestion Control by Mobile Core and RAN Coordination in 5G — 核心网与RAN协同拥塞控制学术分析

本文由「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学通信知识星球海报-扫码加入