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

# 5G AMF 过载控制（Overload Start/Stop）NGAP 信令机制全链拆解

## 一、为什么 AMF 需要专门的过载控制机制

在 5G 核心网（5GC）的架构中，AMF（Access and Mobility Management Function）是所有 UE 接入的"唯一入口"——无论是初始注册、业务请求、切换还是寻呼响应，所有 NAS 信令都必须先穿越 NG-C（N2）接口抵达 AMF。这意味着 AMF 是整个控制面的"信令漏斗"，也是最容易遭遇**信令风暴（Signaling Storm）**的单点。

当大量 UE 在短时间内并发发起注册（例如：体育场散场后集中开机、节假日区域断电恢复后海量终端同时 Attach、或在网络切片配置变更引发批量重注册时），AMF 的 CPU 利用率会瞬间飙升，消息队列深度急剧膨胀，最终导致 NAS 处理时延劣化甚至队列溢出、UE 上下文丢失。如果不加干预，这种过载会向下游的 SMF/UDM/AUSF 级联扩散，形成全局雪崩。

3GPP 为此在 NGAP（TS 38.413）中定义了一套**AMF 过载控制过程**（AMF Overload Control Procedures），让 AMF 能够在自身压力告急时，主动通过 `OVERLOAD START` 消息通知 NG-RAN（gNB）削减信令负载，并在压力缓解后通过 `OVERLOAD STOP` 消息恢复正常。这套机制的本质是：**把"削减决策"下放到 gNB 执行，让 gNB 在 RRC 层就把过载流量挡在 AMF 之外**，从而在最接近信令源头处实现分级防护。

> 核心设计哲学：过载控制不是 AMF 自己丢弃已收到的信令，而是通过 NGAP 指令让 NG-RAN 在 RRC 连接建立阶段就实施"准入控制（Admission Control）"。这是一种**反向施压、就近削减**的分层防御思想。

## 二、机制全景：两个非 UE 关联的 NGAP 过程

AMF 过载控制由两个独立的 NGAP 基本过程（Elementary Procedure）组成，二者均属于 **NG 接口管理类过程（NG Interface Management Procedures）**，定义于 TS 38.413 第 8 章：

| 过程 | 方向 | 性质 | 用途 |
|------|------|------|------|
| Overload Start | AMF → NG-RAN | 非 UE 关联信令（Non-UE-associated Signaling） | 指示 NG-RAN 开始削减发往该 AMF 的信令 |
| Overload Stop | AMF → NG-RAN | 非 UE 关联信令 | 指示 NG-RAN 恢复正常处理 |

需要特别强调的是，这两个过程都是 **非 UE 关联信令**。这意味着：

1. 它们**不携带任何特定 UE 的标识**（如 AMF UE NGAP ID），而是针对"gNB 与某 AMF（或某 AMF Set、某 TNL Association）之间的整条信令通道"生效。
2. NG-RAN **不需要回复任何确认消息**（没有 Overload Start Acknowledge / Overload Stop Acknowledge）。这是单向通知型过程。
3. NG-RAN 收到 `OVERLOAD START` 后，会持续执行其中规定的 Overload Action，**直到收到对应的 `OVERLOAD STOP` 或 AMF 状态发生切换**。

下面这张时序图展示了完整的过载进入与退出的信令流转：

```mermaid
sequenceDiagram
    autonumber
    participant UE as UE（多个）
    participant gNB as NG-RAN (gNB)
    participant AMF as AMF

    Note over AMF: 监控本地指标<br/>(CPU/队列深度/NAS处理时延)
    Note over AMF: 触发条件命中<br/>(拥塞级别达到阈值)

    AMF->>gNB: OVERLOAD START<br/>(Overload Response + Traffic Load Reduction %)<br/>非UE关联信令
    Note over gNB: 记录过载动作 & 削减比例<br/>进入"过载应用"状态

    UE->>gNB: RRC Setup Request (MO)
    Note over gNB: 按比例随机拒绝<br/>或按动作类型拒绝

    alt 命中拒绝
        gNB-->>UE: RRC Reject
        Note over gNB: 信令在RRC层被挡<br/>不转发至AMF
    else 命中放行
        gNB->>AMF: Initial UE Message (NAS)
    end

    Note over AMF: 指标回落至恢复阈值以下
    AMF->>gNB: OVERLOAD STOP<br/>(仅Message Type)<br/>非UE关联信令
    Note over gNB: 清除过载动作<br/>恢复正常准入
    UE->>gNB: RRC Setup Request
    gNB->>AMF: Initial UE Message
```

## 三、OVERLOAD START 消息 IE 深度解析

`OVERLOAD START` 是整个机制的核心，它携带的 IE 决定了 gNB 该拒绝什么、拒绝多少。其 IE 结构如下：

```mermaid
graph TD
    OS["OVERLOAD START 消息"] --> MT["Message Type<br/>(必选, = OVERLOAD START)"]
    OS --> OR["Overload Response<br/>(必选) — 过载动作类型"]
    OS --> TLR["Traffic Load Reduction Indication<br/>(可选) — 削减百分比 0..100"]
    OS --> NS["NSSAI<br/>(可选) — 切片级过载控制"]

    OR --> OR1["reject non-emergency MO data transfers"]
    OR --> OR2["reject all mobile originated signalling"]
    OR --> OR3["reject all mobile originated data transfers"]
    OR --> OR4["only allow high priority sessions<br/>and mobile terminated services"]
    OR --> OR5["reject all mobile originated registrations<br/>(Rel-16 增补)"]

    style OS fill:#fce4ec,stroke:#c2185b,stroke-width:2px
    style OR fill:#e3f2fd,stroke:#1565c0,stroke-width:2px
    style TLR fill:#fff3e0,stroke:#ef6c00
    style NS fill:#f1f8e9,stroke:#558b2f
```

### 3.1 Overload Response——过载动作的"枚举开关"

Overload Response 是一个**枚举类型（OverloadResponse）**，它直接告诉 gNB 要对哪一类业务执行拒绝动作。下表逐一拆解每个枚举值的设计含义与 RRC 层行为：

| Overload Response 枚举值 | 对 NG-RAN 的指令（RRC 层行为） | 设计意图 |
|---|---|---|
| reject non-emergency mobile originated data transfers | 拒绝非紧急的 MO（移动主叫）数据传输，可放行 MO 信令与 MT 服务 | **最温和**：仅压制"数据"流量，保留注册/信令通路，适合轻度过载 |
| reject all mobile originated data transfers | 拒绝所有 MO 数据传输 | 中度过载，把数据面压力完全卸载给 RAN |
| reject all mobile originated signalling | 拒绝所有 MO 信令（含注册、业务请求等 MO 流程） | **较激进**：彻底切断 UE 主动发起的控制面，仅保留 MT 能力 |
| only allow high priority sessions and mobile terminated services | 仅允许高优先级会话与 MT（移动被叫）服务，其余全部拒绝 | **接近全面熔断**：保留紧急呼叫、高优先级、被叫可达性 |
| reject all mobile originated registrations | 拒绝所有 MO 注册流程 | Rel-16 新增，专门针对"注册风暴"场景（如批量重注册） |

> **设计要点**：这五个枚举值构成了从"轻度过载"到"接近熔断"的渐进档位。AMF 可根据自身拥塞等级动态选择合适的动作，而不必"一刀切"。其中"only allow high priority sessions and mobile terminated services"是最高保护档，它确保紧急呼叫（Emergency）和被叫业务（如下行短信、被叫语音）在极端拥塞下仍可达——这是电信级**紧急服务可达性**的硬性要求。

### 3.2 Traffic Load Reduction Indication——百分比平滑削减

当 AMF 不希望"全量拒绝"某类业务，而是希望 gNB **按比例随机丢弃**时，就会携带 `Traffic Load Reduction Indication` 这个可选 IE。它是一个整数（0..100），表示 gNB 应当削减的信令百分比。

- 当该 IE 存在时，gNB 对每一个匹配 Overload Response 类型的 RRC 连接请求，按**伪随机算法**以该概率决定是放行还是拒绝。
- 这是一种**概率性准入控制**：理论上若 AMF 请求削减 30%，gNB 会随机拒绝约 30% 的目标信令，使到达 AMF 的流量降低约 30%。

这种百分比机制的价值在于**平滑恢复**：AMF 可以先请求削减 50%，观察自身负载；缓解后再发 `OVERLOAD START` 削减 20%；进一步缓解后发 `OVERLOAD STOP`。这种阶梯式调节避免了"开/关"突变带来的二次冲击。

### 3.3 NSSAI——Rel-16 切片级过载控制

可选的 `NSSAI` IE 让 AMF 能够**仅对特定网络切片的 UE 施加过载控制**。例如，当某个商业大客户的切片签约用户集中发起注册，拖垮了 AMF 处理能力时，AMF 可以只针对该 S-NSSAI 发送过载指令，而不影响其他切片用户。

这是 5GC 相对 4G EPC（S1AP Overload Control）的一个重要增强：**过载控制从"全 gNB 级"细化到"切片级"**，体现了网络切片隔离与精细化运维的能力。

## 四、Overload Start/Stop 与 AMF 触发判据

NGAP 规范只定义了"消息怎么发、IE 怎么填"，但**AMF 在何时、依据什么指标触发过载**，是由各厂商的 AMF 实现策略决定的（TS 23.502 第 4.x 节给出总体框架，具体阈值不在 3GPP 标准化范围）。典型的触发判据包括：

| 监控维度 | 典型触发逻辑 |
|---|---|
| CPU/线程池利用率 | 利用率持续高于高水位（如 80%）N 秒，升级拥塞级别 |
| NAS 消息队列深度 | 待处理 NAS 队列长度超过门限，触发削减 |
| NAS 平均处理时延 | 端到端 NAS 处理时延超过 SLA 阈值 |
| 内存/UE 上下文数量 | 在线 UE 上下文逼近容量上限 |
| 下游 NF 响应异常 | UDM/SMF 响应超时率上升，反向触发保护 |

厂商通常实现**多级拥塞状态机**（如 Low/Medium/High/Critical），不同级别映射不同的 Overload Response 与 Traffic Load Reduction 组合，实现"过载越重、动作越激进"的自适应调节。

下图是 AMF 拥塞状态机的一个典型模型（厂商实现各异，此处为通用抽象）：

```mermaid
stateDiagram-v2
    [*] --> Normal
    Normal --> Congested_Low: 监控指标>低水位
    Congested_Low --> Congested_Medium: 指标>中水位
    Congested_Medium --> Congested_High: 指标>高水位
    Congested_Low --> Normal: 指标<恢复阈值
    Congested_Medium --> Congested_Low: 指标<恢复阈值
    Congested_High --> Congested_Medium: 指标<恢复阈值

    state Congested_Low {
        [*] --> Send_OS_1
        Send_OS_1 : 发送OVERLOAD START<br/>reject MO data + 削减20%
    }
    state Congested_Medium {
        [*] --> Send_OS_2
        Send_OS_2 : 发送OVERLOAD START<br/>reject all MO signalling + 削减40%
    }
    state Congested_High {
        [*] --> Send_OS_3
        Send_OS_3 : 发送OVERLOAD START<br/>only allow HP + MT
    }
    Normal --> Send_STOP: 发送OVERLOAD STOP
```

注意图中存在**迟滞（Hysteresis）**：触发阈值与恢复阈值不同（恢复阈值更低），这是为了避免在临界点上反复振荡导致 `OVERLOAD START`/`STOP` 频繁抖动。

## 五、NG-RAN 侧的执行逻辑

gNB 收到 `OVERLOAD START` 后的本地行为是过载控制能否生效的关键。其处理流程如下：

1. **解析并存储**：解析 Overload Response、Traffic Load Reduction Indication、NSSAI，存储为本 gNB 对该 AMF（按 AMF Name / TNL Association 标识）的"过载状态"。
2. **匹配 UE**：当后续有 UE 发起 RRC 连接（RRC Setup Request），gNB 根据该 UE 的 NAS 信令类型（注册/业务请求/数据）、优先级、归属 NSSAI，判断是否命中过载动作。
3. **执行削减**：命中则通过 `RRC Reject`（携带 wait time）拒绝，或在更早阶段拒绝；放行的才组装 `Initial UE Message` 转发至 AMF。
4. **持续生效**：过载状态持续存在，直到收到 `OVERLOAD STOP` 或该 AMF 的 TNL Association 不可用。
5. **范围控制**：gNB 对**每个 AMF 维护独立的过载状态**，因此若 gNB 连接多个 AMF（多 AMF Set 场景），某个 AMF 过载不会误伤其他 AMF 服务的 UE。

```mermaid
flowchart TD
    A[UE发起RRC Setup Request] --> B{gNB是否存在对该AMF的<br/>有效Overload状态?}
    B -->|否| Z[正常建立RRC, 转发Initial UE Message至AMF]
    B -->|是| C{UE归属NSSAI命中<br/>Overload的NSSAI?}
    C -->|不命中/无NSSAI限制| Z
    C -->|命中| D{信令类型是否匹配<br/>Overload Response动作?}
    D -->|不匹配| Z
    D -->|匹配| E{是否携带<br/>Traffic Load Reduction?}
    E -->|否| F[全部拒绝: RRC Reject]
    E -->|是| G[按百分比随机判定]
    G -->|拒绝| F
    G -->|放行| Z

    style F fill:#ffebee,stroke:#c62828
    style Z fill:#e8f5e9,stroke:#2e7d32
```

## 六、与 4G S1AP 及 AMF Status Indication 的对比

| 维度 | 4G S1AP（TS 36.413）Overload Start/Stop | 5G NGAP（TS 38.413）Overload Start/Stop | 备注 |
|---|---|---|---|
| 接口 | S1-MME（MME↔eNB） | NG-C（AMF↔gNB） | 控制面对等迁移 |
| 信令性质 | 非 UE 关联 | 非 UE 关联 | 完全一致 |
| Overload Response 动作 | 4 个枚举值 | 5 个枚举值（Rel-16 新增"reject all MO registrations"） | 5G 针对注册风暴增强 |
| 百分比削减 | 无标准化 | Traffic Load Reduction Indication（0..100） | 5G 支持平滑调节 |
| 切片感知 | 无 | NSSAI 切片级控制 | 5G 独有，体现切片能力 |
| 配套过程 | — | AMF Status Indication（TS 38.413）协同 | AMF 不可用时切换服务 AMF |

此外，AMF 过载控制还与 **AMF Status Indication** 过程协同：当 AMF 不仅过载而是彻底不可用时，会通过 AMF Status Indication 通知 gNB 该 AMF（或其部分 TNL Association）无法服务，gNB 会将后续 UE 引导至 AMF Set 内的其他可用 AMF（依赖 AMF Set 与 GUAMI 机制）。二者区分点在于：**Overload Start 是"还能干，但请少干"，AMF Status Indication 是"完全不能干，请找别人"。**

## 七、实战抓包识别与排错

### 7.1 如何在抓包中识别该流程

由于 Overload Start/Stop 是**非 UE 关联信令**，在 Wireshark/tshark 中它不会挂在某条 UE 的 NGAP 流上，而是出现在 NG-C 接口的**非 UE 关联 SCTP 流（Stream 0）**上。识别要点：

- 过滤条件：`ngap.procedureCode == 17`（Overload Start，具体值依版本）或直接按 procedure name 过滤 `ngap && (ngap.overloadStart || ngap.overloadStop)`。
- `OVERLOAD START` 展开后可看到 `Overload Response`、`Traffic Load Reduction Indication`、`NSSAI` 三个 IE 的实际值。
- `OVERLOAD STOP` 仅有 Message Type，结构极简。

### 7.2 常见故障点

| 故障现象 | 可能根因 | 排错思路 |
|---|---|---|
| 区域内大批 UE 无法注册，但 AMF 负载并不高 | `OVERLOAD STOP` 丢失或 gNB 未正确清除过载状态 | 检查 gNB 是否仍持有陈旧的 Overload 状态；确认 SCTP 链路无中断导致 Stop 未送达 |
| 过载未生效，AMF 仍被信令压垮 | Overload Response 动作选择过轻，或 gNB 百分比削减实现过于宽松 | 抓包核对实际下发的削减比例与动作；评估 gNB 的随机拒绝算法 |
| UE 被误拒但本属高优先级/紧急 | gNB 未正确识别优先级，将高优先级会话一并拒绝 | 核对 gNB 对 "only allow high priority" 的实现，确认 ARP/5QI 优先级判断逻辑 |
| 切片级过控误伤其他切片 UE | gNB NSSAI 匹配逻辑错误，将匹配范围放大 | 检查 gNB 对 NSSAI IE 的精确匹配实现 |
## 八、设计意图总结

综合全文，AMF 过载控制机制体现了 3GPP 在控制面可靠性上的三个核心设计思想：

1. **就近削减、反向施压**：与其让 AMF 自己丢弃已接收的信令（既浪费传输资源，又难以精细控制），不如通过 NGAP 指令把"准入控制"下推到最接近 UE 的 gNB，在 RRC 层就完成削减。
2. **渐进式、可恢复**：Overload Response 多档枚举 + Traffic Load Reduction 百分比，使 AMF 能够像"调节阀"一样平滑控制流量，配合迟滞状态机避免振荡。
3. **切片感知、精细隔离**：Rel-16 引入的 NSSAI 与注册拒绝动作，让过载控制与 5G 网络切片能力深度结合，实现"过载也隔离"，这是 5GC 相对 EPC 的运维进步。

## 常见问题

**Q1：Overload Start/Stop 为什么是"非 UE 关联信令"？它和 UE 关联信令（如 Initial UE Message）有何本质区别？**
A：UE 关联信令必须携带 UE 的 NGAP 标识（AMF UE NGAP ID / RAN UE NGAP ID），绑定在某条特定的 NGAP UE 信令连接上，针对单个 UE 生命周期。而非 UE 关联信令不绑定任何 UE，针对"gNB 与 AMF 之间整条接口通道"的全局状态。过载控制是全局策略，需对所有经过该通道的 UE 统一生效，因此必须是非 UE 关联的，且通过 SCTP 的非 UE 关联流传输。

**Q2：gNB 收到 OVERLOAD START 后如果不执行削减，会怎样？标准有强制约束吗？**
A：TS 38.413 规定 NG-RAN"应（shall）"按照 Overload Response 执行相应动作，属于规范性要求。但标准不约束具体算法（如百分比削减如何实现）。若 gNB 未执行，结果是 AMF 仍被过载流量压垮，此时 AMF 自身会启动本地拥塞控制（如 NAS 拒绝、延迟处理）作为兜底。运维中通常通过抓包核对 gNB 的实际拒绝率来验证执行情况。

**Q3：Traffic Load Reduction Indication 的百分比是"精确的"吗？gNB 真能精确削减 30%？**
A：不是精确的。它是统计意义上的目标值，gNB 通过随机/哈希算法近似达到。短时间内实际削减比例会有波动，只有在大量样本下才趋近设定值。这也是为什么 AMF 需要持续监控并动态调整该百分比——形成闭环。

**Q4：Overload Start 和 AMF Status Indication 都用于 AMF 异常，二者如何选择？**
A：Overload Start 用于 AMF"过载但仍在服务"，目的是让 gNB 削减负载、AMF 自行恢复；AMF Status Indication 用于 AMF"不可用（如故障、维护、TNL 断开）"，目的是让 gNB 将 UE 重定向到 AMF Set 内其他可用 AMF。简单记：能救则 Overload Start，不能救则 AMF Status Indication + 重选。

**Q5：过载期间被 RRC Reject 的 UE 会怎样？用户体验如何？**
A：gNB 通常通过 `RRC Reject` 消息携带 `waitTime`，UE 进入退避（backoff），在等待期内不再发起 RRC 建立。UE 侧表现为"信号正常但无法接入/注册"，业务感知为"转圈、注册失败"。若过载持续且 waitTime 反复刷新，UE 会在较长时间内无法获得服务，这也是为何过载控制必须配合快速恢复机制与运维告警。

## 参考来源

1. [3GPP TS 38.413 V18.6.0 — NG-RAN; NG Application Protocol (NGAP)](https://www.etsi.org/deliver/etsi_ts/138400_138499/138413/18.06.00_60/ts_138413v180600p.pdf) — 第 8 章 NG Interface Management Elementary Procedures（Overload Start / Overload Stop）、第 9 章消息与 IE 定义（Overload Response、Traffic Load Reduction Indication、NSSAI）
2. [3GPP TS 38.413 V19.0.0](https://www.etsi.org/deliver/etsi_ts/138400_138499/138413/19.00.00_60/ts_138413v190000p.pdf) — Release 19 NGAP 规范最新版本
3. [5G NGAP Overload Start Message — 3glteinfo](https://www.3glteinfo.com/messages/5g/ngap/overload-start/) — OVERLOAD START 消息 IE 解析与过程说明
4. [Cisco Ultra Cloud Core 5G AMF — Overload Control for N2 and NAS](https://www.cisco.com/c/en/us/td/docs/wireless/ucc/amf/2025-01/config-and-admin/b_ucc-5g-amf-config-and-admin-guide_2025-01/m_overload-control-n2-nas.html) — 厂商 AMF 过载控制策略与 N2/NAS 联动实现
5. [ShareTechnote — 5G NGAP / N2 Interface](https://www.sharetechnote.com/html/5G/5G_NGAP.html) — NGAP 协议结构与接口管理过程图解
6. [open5gs DeepWiki — NGAP Protocol Handling](https://deepwiki.com/open5gs/open5gs/3.2.3-ngap-protocol-handling) — 开源 5GC 中 AMF NGAP 层实现参考

---
> 本文由「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)