5G AMF过载控制信令全链拆解：NGAP OVERLOAD START/STOP 与 NAS 拥塞控制的协同防御

一、为什么 AMF 过载控制是核心网的"安全阀"

AMF（Access and Mobility Management Function）作为 5G 核心网控制面唯一与 NG-RAN 直连的 NF，承载着注册、连接管理、移动性、SMF 选择等几乎所有 UE 发起的 NAS 信令的"入口"职能。一旦发生信令风暴（signalling storm）——例如某切片下海量 IoT 设备同时发起注册、某 APP 触发重连潮、或灾难漫游场景下的接入洪峰——AMF 的处理资源（CPU、信令队列、数据库连接）会在数秒内被耗尽，进而拖垮 UDM/UDR、SMF、AUSF 等下游 NF，形成级联雪崩。

3GPP 在 TS 23.501 Section 5.19.5.2（AMF Overload Control） 中明确给出了防御思路：AMF 进入过载状态时，需同时从两个维度施加控制——一是通过 NGAP 接口信令（OVERLOAD START）反向通知 NG-RAN 在源头削减/过滤信令；二是激活 NAS 层拥塞控制（TS 23.501 Section 5.19.7）直接对 UE 下发 backoff timer。这两条机制一"外"一"内"，构成了 AMF 的双重过载防护体系。

本文聚焦 3GPP TS 38.413 Section 8.7.7（AMF Overload Control） 中 OVERLOAD START / OVERLOAD STOP 这一对非 UE 关联的接口管理消息，逐 IE 拆解其触发逻辑、消息结构、切片级扩展（Overload Start NSSAI List）以及与 NAS 层 backoff 机制的协同，并给出抓包识别与排错实战。

二、过载控制的整体协同架构

AMF 过载控制并非孤立消息，而是一条"感知—决策—下发—执行—解除"的闭环链路。下图展示了从过载感知到三层协同控制的完整视图：

flowchart TD
    subgraph 感知["感知层"]
        NWDAF["NWDAF<br/>TS 23.288 §6.22<br/>信令风暴分析"]
        AMFMON["AMF 本地过载监控<br/>CPU/队列/信令速率"]
    end

    subgraph 决策["决策层（AMF）"]
        DEC{"是否过载?<br/>或信令风暴<br/>高概率预警"}
    end

    subgraph 执行["三层协同执行"]
        NAS["① NAS 层拥塞控制<br/>T3346 backoff<br/>TS 24.501 §5.4.4"]
        NGAP["② NGAP 过载控制<br/>OVERLOAD START<br/>TS 38.413 §8.7.7"]
        SBI["③ SBI 过载控制<br/>503 + Retry-After<br/>TS 29.500 §4.7"]
    end

    subgraph 受控["受控对象"]
        UE["UE"]
        RAN["NG-RAN / gNB"]
        NF["下游 NF Consumer"]
    end

    NWDAF --> DEC
    AMFMON --> DEC
    DEC -->|激活| NAS
    DEC -->|下发| NGAP
    DEC -->|触发| SBI
    NAS -->|直接抑制| UE
    NGAP -->|源头过滤| RAN
    SBI -->|退避| NF
    RAN -.->|拒绝/降级| UE

三者的分工互补：

• NAS 层拥塞控制（面向已注册 UE）：AMF 直接对 UE 下发 backoff timer（如 T3346），UE 本地抑制后续 NAS 信令，粒度可精确到通用、DNN/S-NSSAI、接入类别（Access Category）。
• NGAP 过载控制（面向新接入 UE，本文核心）：在 RRC 连接建立阶段就由 gNB 在源头拦截，连 NAS 消息都不需要送到 AMF，是"最廉价"的过滤。
• SBI 过载控制（面向 NF 间）：AMF 作为 SBI Consumer 访问 UDM/SMF 时，若下游过载，则遵循 503+Retry-After 退避，保护下游 NF。

三、NGAP OVERLOAD START 消息逐 IE 拆解

3.1 消息定位

OVERLOAD START 属于非 UE 关联（non-UE-associated）的接口管理信令，承载于 SCTP 之上的 NG-C 接口，与具体 UE 无关，是 AMF→NG-RAN 单向的节点级控制信号。规范定位见 TS 38.413 Section 8.7.7、8.7.7.1（OVERLOAD START）、8.7.7.2、8.7.7.3（OVERLOAD STOP），消息与 IE 的功能定义在 Section 9，ASN.1 定义在 Annex A。

3.2 关键 IE 结构

下表为 OVERLOAD START 携带的三个核心 IE（以 Rel-18 基线为准）：

3.3 Overload Response IE 的七档语义

Overload Response（即 OverloadAction）是整条消息的灵魂。它定义了 gNB 在源头对 RRC 连接建立的拦截策略，严格遵循"由宽到严"的梯度设计：

3.4 设计意图

这套梯度设计的精妙之处在于业务优先级保底：无论过载多严重，紧急呼叫（Emergency）和高优先级接入（如 MPS、关键业务）始终在白名单内，符合 TS 22.261 对灾难/应急通信的可达性要求。档位 0/1/2 提供了"外科手术式"的精细过滤——只掐掉引发风暴的特定业务（如 IoT 设备 SMS 心跳潮），而不波及其他正常业务，避免一刀切带来的次级拥塞。

四、信令时序：从过载感知到解除的完整流程

下图呈现了 AMF 过载控制从启动到恢复的完整时序，包含 NGAP 消息交互、NAS backoff 联动与解除阶段：

sequenceDiagram
    autonumber
    participant UE as UE
    participant RAN as NG-RAN (gNB)
    participant AMF as AMF
    participant NWDAF as NWDAF

    Note over AMF,NWDAF: ① 过载感知阶段
    NWDAF->>AMF: 信令风暴分析(异常NF/特定UE组/切片)<br/>TS 23.288 §6.22
    AMF->>AMF: 本地监控触发过载阈值

    Note over AMF,RAN: ② 过载控制激活阶段
    AMF->>AMF: 激活 NAS 层拥塞控制(§5.19.7)<br/>向受影响UE下发 T3346 backoff
    AMF->>RAN: NGAP: OVERLOAD START<br/>(OverloadAction, Reduction %, NSSAI List)

    Note over RAN,UE: ③ 源头执行阶段
    UE->>RAN: RRC Setup Request (新UE发起接入)
    RAN->>RAN: 校验 OverloadAction & Reduction%<br/>匹配 NSSAI List
    alt 命中拒绝策略
        RAN-->>UE: RRC Reject (按概率/分类拒绝)
        Note right of RAN: NAS消息无需上送AMF
    else 允许放行
        RAN->>AMF: 正常 NAS 信令(Initial UE Message)
    end

    Note over AMF,RAN: ④ 状态刷新阶段(可选)
    AMF->>RAN: NGAP: OVERLOAD START (新一轮)<br/>gNB 用新控制替换旧控制

    Note over AMF,RAN: ⑤ 过载解除阶段
    AMF->>RAN: NGAP: OVERLOAD STOP
    RAN->>RAN: 清除该AMF的过载状态<br/>恢复全部RRC接入

关键执行语义说明：

1. 非 UE 关联性：第 3 步的 OVERLOAD START 不携带任何 UE 标识，gNB 收到后建立的是"针对该 AMF 的节点级过载状态表"，对所有后续接入 UE 统一适用。
2. 替换语义（Replace）：第 4 步体现了 TS 38.413 的明确要求——若 gNB 已存在该 AMF 的过载控制信息，又收到新的 OVERLOAD START，必须用最新的控制信息完整替换旧信息，而非叠加。这意味着过载档位可实时动态调整（如从档位 4 收紧到档位 6）。
3. 解除的唯一方式：OVERLOAD STOP 是清除过载状态的唯一正向消息。此外，若 NG-C 接口的 SCTP 关联断开，gNB 也会清除与该 AMF 关联的过载状态（兜底机制）。

五、与 NAS 层拥塞控制的协同：T3346 与 NGAP 过载的边界

NGAP 过载控制与 NAS 层拥塞控制并非替代关系，而是面向不同人群的协同。理解二者边界是排错的关键。

flowchart TD
    A["AMF 检测过载"] --> B{"UE 是否已有<br/>NAS 信令连接?"}
    B -->|是, 已注册| C["NAS 层拥塞控制<br/>§5.19.7"]
    B -->|否, 新接入| D["NGAP 过载控制<br/>§8.7.7"]

    C --> C1["通用: T3346 backoff"]
    C --> C2["DNN/S-NSSAI 特定: T3396"]
    C --> C3["接入类别特定<br/>Access Category backoff"]
    C1 & C2 & C3 --> E["UE 本地抑制<br/>到期前不发 NAS"]

    D --> D1["gNB 在 RRC 建立阶段拦截"]
    D1 --> F["UE 收到 RRC Reject<br/>或被概率性放行"]

    E --> G["信令洪峰从两端被削峰"]
    F --> G

两者的边界与互补关系如下表：

协同要点：当 AMF 处于过载时，两类机制往往同时生效。NAS 层负责"劝退"已注册 UE 的重复 NAS 信令（如周期性注册风暴），NGAP 负责"挡住"新 UE 的初始接入。两者叠加，才能在不拒绝紧急业务的前提下削峰。

六、切片级过载控制：Overload Start NSSAI List 的精细治理

Rel-17 起，3GPP 引入了 Overload Start NSSAI List，使过载控制可下沉到切片粒度。这与 5G 网络切片"按需隔离"的核心理念一致：当某个特定切片（如海量 mMTC 切片）下 UE 引发风暴时，AMF 无需对全网所有切片一刀切降级，而是仅对该切片施加更严的 OverloadAction。

这一机制也呼应了 TS 23.288 中 NWDAF 对"特定切片/特定 UE 组"的信令风暴分析能力——分析结果可精准驱动切片级过载控制的施加。

下表对比 AMF 级与切片级过载控制：

设计意图：切片级控制实现了"故障切片隔离"，是网络切片端到端 QoS 保障与隔离在过载域的直接体现。AMF 可对 mMTC 切片施加档位 3（拒绝非紧急），同时保持 VoNR 切片完全放行，避免"一刀切"误伤高价值业务。

七、SBI 过载控制：AMF 作为 Consumer 的退避

除对外下发过载指令，AMF 自身作为 SBI Consumer 访问 UDM/SMF/AUSF 时，也可能遭遇下游 NF 过载。依据 TS 29.500 Section 4.7（Overload Control） 与 TS 29.510（NRF），当 NF Producer（或 SCP）过载时，会返回 HTTP 503 Service Unavailable 并携带 Retry-After 头，指示退避时长。

sequenceDiagram
    autonumber
    participant AMF as AMF (Consumer)
    participant SCP as SCP
    participant UDM as UDM (Producer)

    AMF->>SCP: HTTP/2 POST /udm/... (间接通信)
    SCP->>UDM: 转发请求
    Note over UDM: UDM 检测过载
    UDM-->>SCP: 503 Service Unavailable<br/>Retry-After: 30
    SCP-->>AMF: 503 + Retry-After: 30
    AMF->>AMF: 启动 backoff<br/>对该UDM实例暂存退避
    Note over AMF: 退避期内本地拒绝<br/>指向该UDM的相关请求
    Note over AMF: 退避到期后恢复请求

SCP（Service Communication Proxy）在此过程中可代替 NF Producer 进行过载检测与节流，甚至修改/转发 Retry-After 值，实现间接通信场景下的集中式过载治理。这与 NGAP 过载控制形成呼应：一个是 AMF 对上游 RAN 的反向施压，一个是 AMF 对下游 NF 的退避服从。

八、抓包识别与实战排错

8.1 抓包识别要点

在 Wireshark/TShark 中过滤 OVERLOAD START：

# Wireshark 显示过滤器
ngap.procedureCode == 17 && ngap.initiatingMessage

# OVERLOAD START 的 procedureCode 为 17
# OVERLOAD STOP 的 procedureCode 为 18

关键识别信号： - OVERLOAD START 出现在 SCTP 流的非 UE 关联信令上（无 UE-NGAP-ID、AMF-UE-NGAP-ID）。 - 关注 ngap.OverloadResponse 字段的枚举值，对应上文七档。 - 关注 ngap.TrafficLoadReductionIndication 的百分比与 OverloadStartNSSAIList 内容。

8.2 常见故障点

Q1: OVERLOAD START 和 NAS 层拥塞控制（T3346）会不会冲突？ A: 不冲突，二者作用域互补。OVERLOAD START 作用于 gNB，拦截尚未到达 AMF 的新接入信令；NAS 层 backoff 作用于 UE 本地，抑制已注册 UE 的重复 NAS 信令。AMF 过载时通常两者并行启用，分别从接入端与已注册端削峰。

Q2: 为什么强调"新 OVERLOAD START 替换旧控制"而不是叠加？ A: 叠加会导致语义混乱——若先档位 4 再档位 5 叠加，gNB 无法判断最终策略。替换语义保证过载控制状态始终是 AMF 当前最新决策的单一映射，使档位可随过载程度实时动态收紧或放松（如档位 4→6→4），实现闭环自适应。

Q3: OVERLOAD STOP 没收到，过载状态会一直保持吗？ A: 不会。规范设计了兜底：若 NG-C 接口的 SCTP 关联断开，gNB 会清除与该 AMF 关联的过载状态。此外，AMF 在过载恢复后会主动下发 OVERLOAD STOP。但若 AMF 实现存在缺陷遗漏 STOP，确会造成接入持续受阻，需抓包核查。

Q4: 切片级过载控制（NSSAI List）和 AMF 级控制同时配置时谁优先？ A: 当 UE 请求的 NSSAI 匹配 NSSAI List 中的某个 S-NSSAI 时，切片级控制优先，该 UE 适用对应 S-NSSAI 的独立 OverloadAction 与 Reduction；未匹配的切片则回落到 AMF 级（AMF-wide）控制。这实现了"故障切片隔离"。

Q5: gNB 自己过载时怎么办？ A: gNB 过载不属于本文 NGAP AMF Overload Control 范畴。NG-RAN 自身的过载通过 RRC 层机制（如 RRC Reject with waitTime）处理，并配合 N2 接口的 RAN 拥塞控制逻辑。本文的 OVERLOAD START 专门服务于"保护 AMF"这一单向目标。

参考来源

1. 3GPP TS 38.413 - NGAP, Section 8.7.7 AMF Overload Control — OVERLOAD START/STOP 消息与 Overload Response IE 定义（Annex A ASN.1）
2. 3GPP TS 23.501 - System architecture, Section 5.19.5.2 AMF Overload Control — 过载控制的 Stage 2 架构定义，含与 NAS 拥塞控制（§5.19.7）联动及 NWDAF 信令风暴分析引用（TS 23.288 §6.22）
3. TS 23.501 Section 5.19.5.2 解读 — iTecSpec — AMF 过载控制与 NAS 层拥塞控制协同关系
4. 5G NGAP Overload Start Message — 3GLTEInfo — OVERLOAD START 消息 IE 结构、NSSAI List 切片级控制与替换语义
5. 3GPP TS 29.500 - SBI General, Section 4.7 Overload Control — SBI 503 + Retry-After 退避与 SCP 间接通信过载治理

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