5G核心网AMF过载控制NGAP信令全链拆解

聚焦 3GPP TS 38.413 NGAP 的 OVERLOAD START / OVERLOAD STOP 基本过程，并联通 TS 29.500 的 SBI 过载控制机制，从触发、信令IE、gNB侧行为到抓包排错，逐层拆解核心网"减负"的具体协议机制。

一、为什么5G核心网需要专门的过载控制机制

在5G网络中，AMF（Access and Mobility Management Function）是所有 UE 接入核心网的"第一道关口"。无论是初始注册、服务请求、移动性注册更新，还是周期性注册，所有 NAS 信令都必须先穿越 NG-RAN 的 N2 接口抵达 AMF。当出现信令风暴（如大型集会、节假日、灾害后位置区集中更新、IoT 海量设备并发接入）时，AMF 的 CPU、内存、数据库连接、UDM/UDR 查询队列会迅速饱和。如果此时 AMF 只是简单地"丢弃"或"超时"信令，会导致 UE 无差别重试，进一步加剧风暴，形成雪崩效应（avalanche effect）。

为避免这种灾难性正反馈，3GPP 在控制面设计了两级闭环过载控制：

1. N2（NGAP）过载控制：AMF 在感知到自身过载后，主动通过 NGAP 的 OVERLOAD START 基本过程，通知 NG-RAN（gNB）"我扛不住了，请你按我给的策略，在接入侧就帮我挡掉一部分信令"。这是面向无线接入网的减负链路。
2. SBI（服务化接口）过载控制：当一个网络功能（NF）作为服务消费者（NF consumer）调用另一个NF（如 AMF→UDM、SMF→PCF）时，被调用的NF如果过载，会通过 HTTP 503 Service Unavailable + Retry-After + RFC 7807 Problem Details 把过载状态回传，由消费者侧执行退避。这是面向NF间的减负链路，定义在 TS 29.500 第6.2.4节。

本文聚焦第一条链路——NGAP 过载控制信令全链，因为它是真正能把信令"堵在无线侧"、避免核心网被淹没的关键机制。

二、过载控制整体架构与触发条件

2.1 AMF 过载的内部触发逻辑

AMF 内部运行着过载检测器（Overload Detector），它持续监控以下指标（具体阈值由运营商策略和厂商实现决定，规范不强制）：

当任一维度越过"高水位线（High Watermark）"，AMF 的 OAM 子系统或应用层过载管理模块会向 AMF 的 NGAP 协议栈发送内部原语，触发 OVERLOAD START 过程；当所有维度回落到"低水位线（Low Watermark）"以下且持续一段时间（避免抖动），触发 OVERLOAD STOP。

设计意图：高低水位之间留有滞回区间（hysteresis），防止负载在阈值附近波动时反复发送 START/STOP，造成 gNB 侧状态机震荡。

2.2 两条减负链路的协同

flowchart TD
    UE[UE / 大量终端] -->|RRC/NAS信令| RAN[NG-RAN gNB]
    RAN -->|N2 NGAP| AMF[AMF 控制面]

    AMF -->|1. NGAP OVERLOAD START<br/>OverloadAction+TrafficReduction| RAN
    RAN -.->|按策略拒绝接入| UE

    AMF -->|2. SBI调用其他NF| NF2[UDM/PCF/SMF...]
    NF2 -->|HTTP 503 + Retry-After<br/>TS 29.500 §6.2.4| AMF
    AMF -.->|退避重试/降级| NF2

    AMF -->|3. AMF Set内重平衡<br/>TS 23.501 §5.22| AMF2[AMF Set内其他AMF]

    style AMF fill:#ffd6d6,stroke:#c00
    style RAN fill:#fff3cd,stroke:#a80

上图揭示了核心网减负的三条腿：①把信令挡在无线侧（本文主线）；②NF间互相退避；③利用 AMF Set（AMF 集合）内的弹性容量做负载重平衡。本文重点拆解第①条。

三、NGAP OVERLOAD START 信令全链拆解

OVERLOAD START 是 TS 38.413 定义的一个非UE关联信令基本过程（non-UE associated signalling elementary procedure）。它的关键特征是：不针对某一个特定UE，而是面向整个 gNB 与 AMF 之间的 N2 连接，属于"广播类"管理过程。

3.1 完整信令时序图

sequenceDiagram
    autonumber
    participant UE as UE(若干)
    participant RAN as gNB / NG-RAN
    participant AMF as AMF(过载中)
    participant OAM as OAM / 过载管理

    Note over AMF: 信令风暴涌入，CPU/队列飙升
    AMF->>OAM: 内部原语：overload_detected(threshold)
    OAM-->>AMF: 决策：启动过载控制，策略=reject非紧急MO data，减负40%

    rect rgb(255, 230, 230)
    Note over AMF,RAN: NGAP OVERLOAD START 过程
    AMF->>RAN: NGAP OVERLOAD START (Non-UE)
    Note right of AMF: PDU: <br/> OverloadResponse=OverloadAction<br/> TrafficLoadReductionIndication=40<br/> OverloadStartNSSAI(可选)<br/> AMFSet(可选)
    end

    Note over RAN: gNB 进入"受限转发"模式
    RAN->>RAN: 按40%比例 + Action策略<br/>筛选新接入NAS消息

    UE->>RAN: Registration Request (普通MO data类)
    RAN--xRAN: 随机/加权判定 → 拒绝(命中40%)
    RAN-->>UE: RRC Reject / MM cause #22 (congestion)

    UE->>RAN: Service Request (紧急呼叫)
    RAN->>AMF: 正常转发(紧急类豁免)

    Note over AMF: 负载回落至低水位，持续T秒
    AMF->>RAN: NGAP OVERLOAD STOP
    Note over RAN: 恢复正常转发

3.2 OVERLOAD START 的 PDU 结构与关键IE

按 TS 38.413 第8章（基本过程）与第9章（信息元素）定义，OVERLOAD START 消息的核心 ASN.1 结构如下（简化呈现，便于理解IE层级）：

graph TD
    A["NGAP PDU<br/>InitiatingMessage<br/>procedureCode = id-OverloadStart"] --> B["OverloadStart"]
    B --> C["protocolIEs"]
    C --> D["IE-1: AMFSet<br/>(可选, Rel-16+)<br/>标识哪个AMF集过载"]
    C --> E["IE-2: OverloadStartNSSAI<br/>(可选, Rel-16+)<br/>按切片粒度过载"]
    C --> F["IE-3: OverloadResponse<br/>(必选, 核心IE)"]
    C --> G["IE-4: TrafficLoadReductionIndication<br/>(可选, 0..100%)"]

    F --> F1["OverloadAction<br/>枚举：5个值之一"]
    G --> G1["整数百分比<br/>gNB按此比例丢弃"]

    style F fill:#fff3cd
    style F1 fill:#ffd6d6
    style G fill:#d6e4ff

下表逐IE说明其语义：

3.3 OverloadAction 的5个值详解（核心IE）

OverloadAction（定义于 TS 38.413 第9章 OverloadResponse）是一个枚举类型，决定 gNB 在过载期间的"准入闸门"策略。这是过载控制最容易被误解的IE，必须逐值吃透：

关键辨析：reject-non-emergency-mo-data-traffic 不是拒绝"数据包"，而是拒绝"与MO数据业务相关的NAS信令过程"（如为建立数据连接的 Service Request）。注册类信令通常仍被放行，因为AMF需要保持UE的可达性管理能力。这就是为什么过载期间用户"打不开网页但还能看到信号"——UE可能仍处于CM-CONNECTED/REGISTERED，但新的数据会话建立被拒。

3.4 TrafficLoadReductionIndication：百分比减负机制

这个可选IE是过载控制的精细化旋钮。它的取值是 0~100 的整数百分比，语义为："请你（gNB）把指向我（AMF）的非紧急MO数据信令，再额外丢弃 N%"。

举例：AMF 发送 OverloadAction = reject-non-emergency-mo-data-traffic + TrafficLoadReductionIndication = 40。则 gNB 的执行逻辑是：

对每一条新到达的、属于"非紧急MO数据"类别的NAS信令：
  - 以 60% 的概率放行（转发给AMF）
  - 以 40% 的概率拒绝（不转发，直接向UE回拒）

具体采用随机丢弃还是加权轮询，规范不规定，由厂商实现。这种"按比例"机制的好处是：AMF 可以平滑调节减负强度，而不是一刀切开关。过载加重时把百分比调高，缓解时调低，实现闭环自适应。

3.5 AMF Set 与切片粒度：Rel-16/17的弹性增强

早期版本（Rel-15）的过载控制是"全 gNB 粒度"的——一旦 AMF 过载，整个 gNB 下所有UE都受影响。这在切片网络和 AMF Set 部署下显得过粗。后续版本引入两个增强：

• AMF Set 粒度：5G 引入 AMF Set（一组功能等价的 AMF，TS 23.501 §5.22.2）。当 Set 内部分 AMF 过载时，OVERLOAD START 携带 AMF Set 信息，gNB 可结合 capacity metric，把后续注册的 UE 通过 5G-GUTI 重分配 或 AMF 重定向路由到 Set 内健康 AMF，实现负载自适应迁移。
• 切片粒度：OverloadStartNSSAI 允许 AMF 只对某几个 S-NSSAI 对应的切片信令触发过载。例如一个 eMBB 切片因突发流量过载，但 URLLC 切片仍需保障，AMF 可只对 eMBB 切片发 OVERLOAD START，URLLC 信令不受影响——这是网络切片隔离在过载控制维度的体现。

四、NGAP OVERLOAD STOP 过程拆解

当 AMF 负载回落，需取消过载控制，发送 OVERLOAD STOP：

sequenceDiagram
    autonumber
    participant RAN as gNB
    participant AMF as AMF

    Note over AMF: 负载回落至低水位，<br/>持续T_stable秒未再触发高水位
    AMF->>RAN: NGAP OVERLOAD STOP
    Note right of AMF: 携带可选 AMFSet / NSSAI<br/>精确取消对应粒度的过载
    Note over RAN: 清除对应过载状态<br/>恢复正常转发

要点： - OVERLOAD STOP 同样是非UE关联信令。 - 若之前 OVERLOAD START 带了 AMFSet/NSSAI，STOP 也可对应携带，实现精确取消（只解除特定切片/Set的过载，其余维持）。 - gNB 收到 STOP 后，必须清除本地保存的过载状态，否则会持续误拒用户。

五、gNB 侧状态转换与执行行为

5.1 gNB 过载状态机

stateDiagram-v2
    [*] --> Normal: N2建立，初始状态
    Normal --> Overloaded: 收到 OVERLOAD START<br/>(无NSSAI/全gNB)
    Normal --> SlicedOverload: 收到 OVERLOAD START<br/>(带OverloadStartNSSAI)
    Normal --> SetOverload: 收到 OVERLOAD START<br/>(带AMFSet)

    Overloaded --> Normal: 收到 OVERLOAD STOP
    SlicedOverload --> Normal: 收到匹配STOP
    SetOverload --> Normal: 收到匹配STOP

    state Overloaded {
        [*] --> ApplyAction
        ApplyAction: 按OverloadAction + <br/>TrafficReduction% 筛选NAS
    }

5.2 gNB 拒绝UE的具体方式

当 gNB 决定拒绝某条 NAS 信令时，它通常：

1. 对注册类请求：回 RRC Reject，并在 NAS 层可能携带 5GMM cause = #22 (congestion)，配合 T3346 定时器，指示 UE 退避一段时间后再试。
2. 对服务请求类：回 Service Reject，cause #22 (congestion)，避免UE立即重试。
3. 紧急呼叫、高优先级（ARP/MPS）信令一律豁免，正常转发。

这种"无线侧就拒"的设计，使得信令根本不进入核心网，从源头保护了AMF。

六、与SBI过载控制的对比（TS 29.500 §6.2.4）

两者互补而非替代：N2 过载控制挡住"从UE涌入的信令洪流"，SBI 过载控制调节"核心网内部NF之间的调用压力"。一个完善的过载防御体系两者都必须启用。

七、抓包识别与故障排查实战

7.1 如何在抓包中识别过载控制流程

使用 Wireshark / TShark 过滤 N2 接口（SCTP承载NGAP）：

# 识别OVERLOAD START/STOP
tshark -r n2.pcap -Y "ngap.procedureCode==17 || ngap.procedureCode==18" \
       -T fields -e frame.number -e ngap.OverloadResponse -e ngap.OverloadAction \
       -e ngap.TrafficLoadReductionIndication

注：OVERLOAD START 的 procedureCode 在 TS 38.413 中为 id-OverloadStart，STOP 为 id-OverloadStop。抓包时这些消息出现频次应极低（正常网络每天0次；一旦出现，说明AMF已触发保护）。

7.2 常见故障点与排错思路

Q1: OVERLOAD START 是不是发给某个特定UE的？ A: 不是。它是非UE关联信令，作用于整个N2连接（AMF与某gNB之间），不携带UE标识。它影响的是该gNB下所有符合OverloadAction条件的UE的后续接入信令。

Q2: OverloadAction 里的 reject-non-emergency-mo-data-traffic 会把已注册的UE踢下线吗？ A: 一般不会。它针对的是新的MO数据相关信令过程（如新的Service Request），已建立的PDU会话通常不受影响。UE仍保持注册态，只是无法发起新的数据会话建立。

Q3: TrafficLoadReductionIndication 和 OverloadAction 是"或"还是"与"的关系？ A: 是叠加（与）关系。OverloadAction 定义"对哪类信令动手"，TrafficLoadReductionIndication 定义"动手的强度比例"。例如 Action=reject非紧急MO数据 + Reduction=40，则gNB对该类信令丢弃40%。

Q4: 过载期间UE被拒后会一直被拒吗？ A: 不会。gNB通常配合定时器（如T3346）让UE退避。一旦AMF发送OVERLOAD STOP，gNB立即恢复正常转发。UE退避期满后重试即可恢复服务。

Q5: NGAP过载控制和SBI过载控制哪个更优先部署？ A: 两者解决不同链路的压力，应同时启用。N2过载控制是第一道防线（挡信令洪流入核心网），SBI过载控制防止核心网内部NF间级联拥塞。生产网络缺一不可。

参考来源

1. 3GPP TS 38.413 — NG-RAN; NG Application Protocol (NGAP) — 第8章基本过程 OVERLOAD START / OVERLOAD STOP，第9章 OverloadResponse/OverloadAction/TrafficLoadReductionIndication/OverloadStartNSSAI/AMFSet 信息元素
2. 3GPP TS 29.500 — 5G System; Technical Realization of Service Based Architecture — 第6.2.4节 SBI Overload control（HTTP 503 + Retry-After + RFC 7807 ProblemDetails）
3. 3GPP TS 23.501 — System architecture for the 5G System — §5.22 AMF Set 弹性、§5.19 控制面拥塞控制相关架构
4. ShareTechnote — 5G NGAP Overload — NGAP 过载过程与IE图解
5. RFC 7807 — Problem Details for HTTP APIs — SBI 过载控制回传的 ProblemDetails 格式定义

本文由「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 等场景全覆盖。