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 章：

需要特别强调的是，这两个过程都是 非 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 状态发生切换。

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

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 结构如下：

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 层行为：

设计要点：这五个枚举值构成了从"轻度过载"到"接近熔断"的渐进档位。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 标准化范围）。典型的触发判据包括：

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

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

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。

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 的对比

此外，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 常见故障点

综合全文，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) — 第 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 — Release 19 NGAP 规范最新版本
3. 5G NGAP Overload Start Message — 3glteinfo — OVERLOAD START 消息 IE 解析与过程说明
4. Cisco Ultra Cloud Core 5G AMF — Overload Control for N2 and NAS — 厂商 AMF 过载控制策略与 N2/NAS 联动实现
5. ShareTechnote — 5G NGAP / N2 Interface — NGAP 协议结构与接口管理过程图解
6. open5gs DeepWiki — 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 等场景全覆盖。