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

# 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）**，它持续监控以下指标（具体阈值由运营商策略和厂商实现决定，规范不强制）：

| 监控维度 | 典型指标 | 触发示例 |
|---------|---------|---------|
| CPU 负载 | 进程CPU利用率 | 持续5秒 > 85% |
| 消息队列深度 | NAS消息队列积压 | 队列长度 > 50000 |
| 虚拟机/容器资源 | vCPU、内存水位 | 内存 > 90% |
| 数据库连接 | UDM/UDR 查询等待 | 平均响应 > 800ms |
| 信令速率 | 注册/服务请求QPS | 超过设计峰值120% |

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

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

### 2.2 两条减负链路的协同

```mermaid
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 完整信令时序图

```mermaid
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层级）：

```mermaid
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说明其语义：

| 信息元素（IE） | 必选性 | 取值/类型 | 含义与作用 |
|--------------|--------|----------|-----------|
| **AMFSet** | 可选 | AMF Set标识 | 当一个 AMF Set 中仅部分AMF过载，gNB 可据此把后续 NAS 路由到该 Set 内健康的 AMF（结合 AMF Set 的 `AMF Set ID` 与容量因子 capacity metric） |
| **OverloadStartNSSAI** | 可选 | 切片列表(S-NSSAI) | **切片粒度过载**：只对特定网络切片触发过载控制，不影响其它切片的UE。这是为切片隔离设计的关键IE |
| **OverloadResponse** | **必选** | OverloadAction枚举 | 指示 gNB 应采取的"接入抑制策略"——这是整个消息的灵魂IE |
| **TrafficLoadReductionIndication** | 可选 | 整数 0..100（百分比） | 指示 gNB 应**减少的流量比例**。如值为40，表示 gNB 应把指向该AMF的非紧急MO信令**额外丢弃40%**，与 OverloadAction 叠加生效 |

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

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

| OverloadAction 取值 | gNB 侧执行行为 | 设计意图 |
|---------------------|--------------|---------|
| `reject-non-emergency-mo-data-traffic` | 拒绝非紧急的、移动台发起(MO)的数据相关信令（如普通Service Request） | **最常用**。把数据面信令挡掉，保留注册/紧急能力，确保控制面不彻底瘫痪 |
| `reject-emergency-mo-data-traffic` | 连紧急MO数据信令也拒绝 | **极高过载**才用。规范要求紧急服务优先级最高，此值仅在极端拥塞、需保命系统能力时启用 |
| `permit-high-priority-sessions-and-emergency-mobile-terminated-services-only` | 只允许高优先级会话 + 紧急MT（移动台终止）服务 | 优先保障被叫紧急服务和MPS（Multimedia Priority Service） |
| `permit-high-priority-sessions-only` | 仅放行高优先级会话（MPS） | 最高级封锁，几乎拒绝所有普通用户业务 |
| `unspecified` | 不指定具体动作 | 通常用于 `OVERLOAD STOP` 语境，表示过载结束、恢复正常 |

> **关键辨析**：`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`：

```mermaid
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 过载状态机

```mermaid
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 NGAP 过载控制 | SBI 过载控制 |
|------|----------------|------------|
| **定义规范** | TS 38.413 §8 OVERLOAD START/STOP | TS 29.500 §6.2.4 |
| **作用接口** | N2（AMF↔gNB） | NF间SBI（HTTP/2） |
| **方向** | AMF→gNB，由被压方主动通知 | 被调用NF→调用方NF，响应中携带 |
| **载体消息** | NGAP独立基本过程 | HTTP `503` + `Retry-After` header + RFC 7807 `ProblemDetails` |
| **减负粒度** | Action枚举 + 百分比 + 切片/Set | 退避时长 + 按端点/服务名 |
| **执行主体** | gNB（在接入侧丢弃信令） | 调用方NF（停止/降频发起请求） |
| **典型场景** | AMF被海量注册/服务请求淹没 | UDM/PCF/CHF被高频查询拖慢 |

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

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

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

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

```bash
# 识别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 常见故障点与排错思路

| 故障现象 | 可能根因 | 排查方向 |
|---------|---------|---------|
| 大量用户同时注册失败，cause #22 | AMF真过载，发了OVERLOAD START | 抓N2确认是否收到START；查AMF CPU/队列指标 |
| 过载已缓解但仍大量用户被拒 | gNB未正确处理OVERLOAD STOP / 状态未清除 | 检查gNB是否收到STOP；查gNB过载状态机日志 |
| 仅某切片用户被拒，其它正常 | AMF按NSSAI发了切片粒度过载 | 抓包看OverloadStartNSSAI；评估该切片是否真实过载 |
| 过载START/STOP频繁震荡 | 高低水位滞回区间设置过窄 | 调整OAM阈值，加大滞回窗口与去抖动时间 |
| 紧急呼叫也被拒 | OverloadAction错误地设为reject-emergency | 核查AMF过载策略配置，紧急类应豁免 |
## 八、常见问题

**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)](https://www.3gpp.org/dynareport/38413.htm) — 第8章基本过程 OVERLOAD START / OVERLOAD STOP，第9章 OverloadResponse/OverloadAction/TrafficLoadReductionIndication/OverloadStartNSSAI/AMFSet 信息元素
2. [3GPP TS 29.500 — 5G System; Technical Realization of Service Based Architecture](https://www.3gpp.org/dynareport/29500.htm) — 第6.2.4节 SBI Overload control（HTTP 503 + Retry-After + RFC 7807 ProblemDetails）
3. [3GPP TS 23.501 — System architecture for the 5G System](https://www.3gpp.org/dynareport/23501.htm) — §5.22 AMF Set 弹性、§5.19 控制面拥塞控制相关架构
4. [ShareTechnote — 5G NGAP Overload](https://www.sharetechnote.com/) — NGAP 过载过程与IE图解
5. [RFC 7807 — Problem Details for HTTP APIs](https://datatracker.ietf.org/doc/html/rfc7807) — 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 等场景全覆盖。

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