<!-- title: 5G AMF过载控制信令全链拆解 -->
<!-- domain: core-network -->

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

```mermaid
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 基线为准）：

| IE 名称 | Presence | 作用 | 取值/说明 |
|---------|----------|------|-----------|
| **AMF Overload Response**（Overload Response） | Mandatory | 告知 gNB 应拒绝/放行哪类 RRC 连接建立 | OverloadAction 枚举，0–6 共 7 档（见下表） |
| **AMF Traffic Load Reduction Indication** | Optional | 给出降低幅度的百分比 | 0–100，gNB 据此按比例随机拒绝非允许类业务 |
| **Overload Start NSSAI List** | Optional | 切片级过载控制，仅对匹配 S-NSSAI 的 UE 生效 | Rel-17 引入，含每个 S-NSSAI 独立的 OverloadAction 与 Reduction Indication |

### 3.3 Overload Response IE 的七档语义

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

| 档位 | OverloadAction 值 | gNB 行为 | 典型场景 |
|------|------------------|----------|----------|
| 0 | Reject for "MMTEL voice" | 仅拒绝 MMTEL 语音相关的 RRC 建立 | 语音信令突发，但数据可承载 |
| 1 | Reject for "MMTEL video" | 仅拒绝 MMTEL 视频 | 视频呼叫潮 |
| 2 | Reject for "SMS" | 仅拒绝 SMS | SMS 风暴 |
| 3 | Reject all non-emergency & non-high-priority | 拒绝所有非紧急/非高优先级 | 中度过载，保紧急业务 |
| 4 | Permit emergency + MT data only | 仅放行紧急业务与被叫数据 | 较重过载 |
| 5 | Permit emergency + MO data only | 仅放行紧急业务与主叫数据 | 较重过载 |
| 6 | Permit high-priority access + emergency only | 最严格，仅放行高优先级与紧急 | 极端过载/灾难场景 |

### 3.4 设计意图

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

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

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

```mermaid
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 层拥塞控制并非替代关系，而是面向不同人群的协同。理解二者边界是排错的关键。

```mermaid
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
```

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

| 维度 | NGAP 过载控制（本文） | NAS 层拥塞控制 |
|------|----------------------|----------------|
| 规范出处 | TS 38.413 §8.7.7 | TS 24.501 §5.4.4 / TS 23.501 §5.19.7 |
| 执行节点 | NG-RAN（gNB） | UE（本地） |
| 作用对象 | 还未到达 AMF 的新接入信令 | 已有/即将建立 NAS 连接的 UE |
| 控制粒度 | 业务类型 + 百分比 + 切片 | 通用/DNN/S-NSSAI/接入类别 |
| 消息载体 | NGAP OVERLOAD START/STOP | NAS 消息中的 Backoff Timer IE |
| 时延特性 | 源头拦截，零 AMF 开销 | UE 自主退避，需 UE 端时序配合 |

**协同要点**：当 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 级与切片级过载控制：

| 维度 | AMF 级过载控制 | 切片级过载控制（NSSAI List） |
|------|---------------|---------------------------|
| 作用范围 | 该 AMF 下所有 UE | 仅请求 NSSAI 匹配的 UE |
| IE 载体 | AMF Overload Response / Reduction | Overload Start NSSAI List 中每个 S-NSSAI 独立设置 |
| 典型用途 | 全局信令风暴、灾难漫游洪峰 | 单切片 IoT 风暴，避免波及 eMBB/VoNR 切片 |
| 替换语义 | 新 OVERLOAD START 整体替换 | 列表整体替换（非逐项合并） |

**设计意图**：切片级控制实现了"故障切片隔离"，是网络切片端到端 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** 头，指示退避时长。

```mermaid
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 常见故障点

| 现象 | 可能原因 | 排错方向 |
|------|---------|---------|
| 接入成功率骤降、大面积 RRC Reject | gNB 持续应用档位 3–6 的过载控制 | 查 AMF 是否真正过载；查 OVERLOAD STOP 是否遗漏下发 |
| 过载恢复后仍拒绝接入 | gNB 未正确处理 OVERLOAD STOP 或 SCTP 重连后状态未清 | 抓包确认 STOP 是否到达；核查 gNB 状态机 |
| 特定切片接入受阻而其他切片正常 | 切片级 NSSAI List 过载控制生效 | 检查 Overload Start NSSAI List 配置是否过严 |
| UE 频繁重连但 NAS backoff 无效 | NAS 层 T3346 与 NGAP 过载控制未协同 | 区分是 RAN 侧拦截还是 UE 本地退避 |
| 下游 UDM 查询异常积压 | AMF 未遵守 SBI 503+Retry-After 退避 | 检查 AMF 对 Retry-After 的处理实现 |
## 九、常见问题

**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](https://www.3gpp.org/dynareport/38413.htm) — 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](https://www.3gpp.org/dynareport/23501.htm) — 过载控制的 Stage 2 架构定义，含与 NAS 拥塞控制（§5.19.7）联动及 NWDAF 信令风暴分析引用（TS 23.288 §6.22）
3. [TS 23.501 Section 5.19.5.2 解读 — iTecSpec](https://itecspec.com/3gpp/23.501/s/5.19.5.2) — AMF 过载控制与 NAS 层拥塞控制协同关系
4. [5G NGAP Overload Start Message — 3GLTEInfo](https://www.3glteinfo.com/messages/5g/ngap/overload-start/) — OVERLOAD START 消息 IE 结构、NSSAI List 切片级控制与替换语义
5. [3GPP TS 29.500 - SBI General, Section 4.7 Overload Control](https://www.3gpp.org/dynareport/29500.htm) — 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 等场景全覆盖。

![51学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)