5G核心网AMF过载控制三层防御机制深度拆解

本文聚焦一个被很多协议工程师"知道但说不清"的核心网机制：AMF（接入与移动性管理功能）在过载状态下，如何通过 N2(NGAP)、N1(NAS)、SBI(Nnrf/HTTP) 三个层面协同卸载与降级。我们将逐层拆解 TS 38.413、TS 24.501、TS 29.500/29.510 中的具体消息结构、关键 IE 与设计意图，并给出抓包识别与排错路径。

一、为什么AMF过载控制必须"分层"

AMF 是 5GC 中信令面最核心、也最容易被"打爆"的网络功能。它要同时承接三类流量来源：

1. 来自 RAN 侧的初始接入信令：海量 UE 同时发起注册/业务请求（如拥塞场景、地震/大型赛事、批量终端上电），通过 N2 接口灌入 AMF；
2. 来自 UE 侧的 NAS 信令：UE 周期性注册更新、Service Request、PDU Session 信令经 gNB 透传至 AMF；
3. 来自其它 NF 的 SBI 调用：SMF 的 Namf_Communication_N1N2MessageTransfer、PCF 的策略下发、UDM 的订阅通知等 HTTP/2 请求。

这三类流量的"源头"和"传输介质"完全不同。如果 AMF 只用一种手段（例如只对 UE 拒绝），就会出现：UE 不断重试放大风暴、gNB 持续向 AMF 灌入 RRC 信令、其它 NF 的 HTTP 请求耗尽 AMF 线程池。因此 3GPP 设计了三层纵深防御（Defense-in-Depth）体系，从源头逐层削峰：

下面给出三层防御的整体架构图：

flowchart TB
    subgraph UE["UE / N1 信令源"]
        U1[5GMM / 5GSM 实体]
    end
    subgraph RAN["NG-RAN (gNB) / N2"]
        G1[NGAP Overload 处理]
        G2[RRC 接入控制]
    end
    subgraph CN["5GC"]
        A1[AMF]
        NRF[NRF]
        OTH[SMF / PCF / UDM 等 NF]
    end
    U1 -->|N1 NAS 请求| G2
    G2 -->|透传 NAS| A1
    A1 -->|① NGAP OVERLOAD START/STOP TS38.413| G1
    G1 --> G2
    A1 -->|② NAS back-off T3346 TS24.501| U1
    A1 -->|③ HTTP 503 / Retry-After TS29.500| OTH
    A1 -.->|Nnrf_NFManagement NFProfile.load| NRF
    NRF -.->|NFStatusNotify load/状态| OTH

理解这张图，就理解了本文全部逻辑：AMF 是"被保护对象"，三层防御分别作用于流量的"入口、客户端、调用方"，互为补充。

二、第一层防御：N2 (NGAP) 过载控制 — TS 38.413

2.1 OVERLOAD START / OVERLOAD STOP 消息结构

NGAP 过载控制是 5G 时代从 LTE S1AP OVERLOAD START/STOP 直接迁移过来的机制，定义在 TS 38.413：消息功能性定义在 clause 8（Message Functional Definition），基本过程（Elementary Procedure）定义在 clause 9（Interface Management 相关过程）。

关键点：OVERLOAD START 与 OVERLOAD STOP 都是非 UE 关联（non-UE-associated）的单向信令，由 AMF 在与 gNB 之间的 SCTP/TNL 关联上发送，不需要 gNB 回任何响应。它本质是 AMF 给 gNB 的一条"指令"：请按这个策略削减你发给我的接入信令。

OVERLOAD START 消息的核心 IE：

OVERLOAD START  (Initiating Message, 无 Outcome)
├── ProtocolIE-Container
│   ├── OverloadResponse            (MANDATORY)   ← 必选，定义拒绝策略
│   ├── TrafficLoadReductionIndication (OPTIONAL)  ← INTEGER (1..98)，百分比削减
│   ├── OverloadStartNSSAIList      (OPTIONAL)     ← R17：按切片过载
│   └── AMF-TNLAssociationToAddList/...（按需）

其中 OverloadResponse 是一个枚举类型，是整个 N2 过载控制的"灵魂"。它把"该放行哪些 UE"的语义编码成四个互斥档位：

可选的 TrafficLoadReductionIndication（百分比 1–98）则是一种"软削峰"：gNB 在 RRC 建立层面按比例随机丢弃新接入，避免一刀切。R17 起增加的 OverloadStartNSSAIList 支持"切片级过载"——即 AMF 可以仅对某 S-NSSAI 触发过载，gNB 仅对承载该切片的接入信令执行削减，这是与 4G 的关键差异之一（4G 无切片概念）。

2.2 NGAP 过载控制时序

sequenceDiagram
    participant AMF
    participant gNB
    participant UE
    Note over AMF: CPU/队列深度/线程池 超过过载阈值
    AMF->>gNB: OVERLOAD START (OverloadResponse, TrafficLoadReductionIndication?)
    Note over gNB: 非UE关联信令，无响应
    UE->>gNB: RRC Setup Request (普通 MO data)
    gNB-->>UE: RRC Reject（依据 OverloadResponse）
    Note over UE: 按 RRC 协议等待/退避后重试
    UE->>gNB: RRC Setup Request (紧急呼叫 / MT data)
    gNB->>AMF: 仍放行（命中 OverloadResponse 白名单）
    Note over AMF: 负载回落至恢复阈值
    AMF->>gNB: OVERLOAD STOP
    Note over gNB: 恢复正常 RRC 接入

2.3 设计意图

把削峰点放在 RAN（gNB）而非 AMF，有两层考量：

• 避免无效空跑：如果让所有 UE 都把 RRC 建起来、把 NAS 消息透传到 AMF 再被拒绝，AMF 的 SCTP 栈、NAS 解析栈仍会被消耗。在 gNB 直接拒 RRC，等于在管道最上游关阀门，AMF 完全不感知这些 UE。
• 保留应急能力：OverloadResponse 的四个档位是"分级降级"而非"全部熔断"，紧急呼叫/高优先级/MPS/MT 业务始终在白名单内，符合电信级"保命业务优先"原则。

三、第二层防御：N1 (NAS) 拥塞控制 — TS 24.501 §5.3.9

3.1 为什么需要 NAS 层独立削峰

N2 过载控制削的是"新 RRC 建立"，但已经处于连接态的 UE 仍可通过已建立的 NAS 信令连接不断发起 Service Request、注册更新、PDU Session 信令。这些 UE 不会触发新的 RRC Setup（连 RRC 已建立），所以 N2 控制管不到。于是需要第二层在 NAS 协议层对 UE 下发"退避指令"，让 UE 在客户端侧自我抑制一段时间。

该机制定义在 TS 24.501 clause 5.3.9 "Handling of NAS level mobility management congestion control"，核心是给 UE 下发一个 back-off timer。

3.2 T3346：5GMM 移动性管理退避定时器

当 AMF 检测到通用 NAS 拥塞并决定对一个 UE 启用退避时，它会在以下 5GMM 拒绝/去注册消息中携带：

• REGISTRATION REJECT（5GMM cause #22 Congestion + T3346 值）
• SERVICE REJECT（cause #22 + T3346）
• CONFIGURATION UPDATE COMMAND（也可用于下发退避）
• DEREGISTRATION（网络发起，带退避）

UE 收到 T3346 后进入退避状态：在 T3346 运行期间，UE 不得发起 5GMM 相关过程（注册、Service Request 等），但保留若干例外：

• 紧急服务相关过程；
• 高优先级访问（High Priority Access / MPS）；
• 移动终止数据/信令触发的响应；
• 注销（Deregistration）。

T3346 取值范围以"去关联化"（de-correlated）的方式编码——AMF 会在配置的标称值附近引入随机抖动，避免大量 UE 在同一时刻同时重试形成"惊群效应（thundering herd）"。这是 NAS 拥塞控制最精妙的设计点之一。

3.3 5GSM 退避定时器（会话级）

除 5GMM 级别外，TS 24.501 还定义了会话管理级（5GSM）拥塞控制。当网络拥塞发生在特定 DNN 或 S-NSSAI 上时（例如某条切片的 SMF/UPF 满载），AMF/SMF 可在 5GSM 拒绝消息中携带 5GSM back-off timer value IE（如 PDU SESSION ESTABLISHMENT REJECT，5GSM cause #27 insufficient resources 或 #22）。

5GSM 退避的关键特征是按粒度作用：UE 仅对匹配该 DNN + S-NSSAI 的 PDU Session 建立请求进行退避，不影响其它 DNN/切片的会话，也不影响移动性管理。这与 T3346（全局移动性退避）形成互补：T3346 是"宽口径压制"，5GSM back-off 是"精准压制到某条业务通道"。

sequenceDiagram
    participant UE
    participant AMF
    Note over UE: 发起 Registration Request
    UE->>AMF: REGISTRATION REQUEST
    Note over AMF: NAS 拥塞控制激活
    AMF-->>UE: REGISTRATION REJECT (#22 Congestion, T3346=随机值)
    Note over UE: 启动 T3346，进入 5GMM 退避态
    UE->>UE: 抑制非紧急/非高优先级注册/Service Request
    Note over UE: 例：收到 MT paging → 仍允许 Service Request
    Note over UE: T3346 超时（带抖动）
    UE->>AMF: REGISTRATION REQUEST（重试，错峰）

3.4 NAS 退避定时器汇总表

四、第三层防御：SBI 过载控制 — TS 29.500 §6.4/6.5 + TS 29.510

4.1 从"主动负载"到"被动过载"两段式

AMF 在 SBA 架构中既是服务消费者（调用 UDM/PCF/UDSF）也是服务生产者（向 SMF/PCF 提供 Namf_Communication、Namf_EventExposure 等服务）。SBI 过载控制分两段，定义在 TS 29.500：

• Clause 6.4 Load control communication（负载控制，主动）：这是"未雨绸缪"。NF 通过 Nnrf_NFManagement 向 NRF 注册/更新自己的 NFProfile.load（0–100 的整数，表示相对负载）。NRF 在 NFStatusNotify 中把负载信息推送给订阅者。消费者（如 SMF 选择 AMF 实例时）优先选择 load 较低的实例，实现负载感知路由。
• Clause 6.5 Overload control communication（过载控制，被动）：这是"事后熔断"。当 AMF 已经过载、无力处理更多 SBI 请求时，它对收到的 HTTP/2 请求返回 HTTP 503 Service Unavailable，并携带 Retry-After 头（RFC 7231 §7.1.3，单位秒），告诉消费者"多久之后再来"。消费者据此在本地做客户端节流（client-side throttling），对该 AMF 实例的所有请求统一退避，而不是傻傻重试。

4.2 SBI 过载控制时序

sequenceDiagram
    participant SMF as SMF（消费者）
    participant AMF as AMF（生产者，过载中）
    participant NRF
    Note over AMF: SBI 线程池/队列 饱和
    SMF->>AMF: POST Namf_Communication_N1N2MessageTransfer
    AMF-->>SMF: HTTP 503 + Retry-After: 30
    Note over SMF: 本地节流：30s 内对该 AMF 实例退避
    AMF->>NRF: Nnrf_NFManagement Update (load=92)
    NRF-->>SMF: NFStatusNotify (AMF load=92)
    Note over SMF: 后续请求路由到同 Set 内低负载 AMF
    Note over AMF: 恢复后 load 下降
    AMF->>NRF: Nnrf_NFManagement Update (load=40)

4.3 与 AMF Set 的协同

当网络部署了 AMF Set（TS 23.501 中定义的一组服务于相同区域的 AMF 实例，共享 GUAMI 池），第三层防御可以更优雅：NRF 的 load 信息让 gNB/SMF 把流量重新分布到同 Set 内健康的 AMF 实例，配合 Namf_Communication_AMFStatusIndication（TS 29.518，AMF 状态指示，用于 AMF 故障/重启通知其它 AMF 转移 UE 上下文），实现过载/故障的无缝分担。这是单体 MME 时代做不到的弹性能力。

五、三层协同：AMF 过载状态机

三层防御不是孤立触发的，而是 AMF 内部一个过载状态机在不同水位下的渐进响应。下图刻画了从正常态到过载态再到恢复态的迁移：

stateDiagram-v2
    [*] --> Normal: 系统启动
    Normal: 正常态\n全部业务正常处理
    Guard: 告警态(Guard)\n仅 NRF NFProfile.load 上升\n引导流量分散
    Overloaded: 过载态\n下发OVERLOAD START\n下发NAS back-off\n返回SBI 503
    Recovering: 恢复态\n负载回落，逐步释放削峰
    Normal --> Guard: 负载 > Guard 阈值
    Guard --> Normal: 负载持续回落
    Guard --> Overloaded: 负载 > 过载阈值
    Overloaded --> Recovering: 负载 < 恢复阈值
    Recovering --> Normal: OVERLOAD STOP + 清除 backoff\n+ HTTP 200 恢复
    Recovering --> Overloaded: 负载反弹，再次触发

设计上，恢复阈值通常低于过载阈值（迟滞 hysteresis），避免在临界点反复抖动（flapping）导致 OVERLOAD START/STOP 频繁下发。

六、抓包识别与实战排错

6.1 抓包如何识别三层过载

在 Wireshark/tshark 中，可用过滤式 ngap.procedureCode == 19（Overload）或 nas_5gs.message_type == 0x44（Registration Reject）配合 nas_5gs.mm_cause == 22 快速定位。

6.2 常见故障点

1. OVERLOAD STOP 永不下发（"卡在过载态"）：AMF 触发了 OVERLOAD START 但恢复逻辑异常，导致 gNB 长期拒接入。表现为全网大量 UE 无法注册，但 AMF CPU 实际已空闲。排查：核对 AMF 过载状态机是否复位。
2. T3346 取值过大或无抖动：AMF 下发统一的 T3346（如统一 600s）且无随机抖动，T3346 超时后 UE 再次集中冲击形成"惊群"。排查：检查 AMF T3346 抖动算法配置。
3. 消费者忽略 Retry-After：SMF/PCF 不识别 HTTP 503 的 Retry-After，对过载 AMF 疯狂重试，反而加剧过载。排查：核对消费者是否实现 client-side throttling。
4. OverloadResponse 档位配置过严：误配为 permit-only-high-priority-and-emergency，导致普通用户完全无法接入。排查：核对策略档位与业务需求匹配。
5. NRF load 不更新：AMF 未及时上报 NFProfile.load，消费者无法做负载感知路由，全部挤到同一 AMF。排查：检查 Nnrf_NFManagement Update 是否周期触发。

常见问题

Q1：OVERLOAD START 和 NAS back-off（T3346）有什么本质区别？ A：OVERLOAD START 作用在 N2/RAN 层，是 AMF 让 gNB 在源头拒绝新 RRC 建立，UE 完全不感知、也不需要任何 NAS 消息交互；T3346 作用在 N1/NAS 层，是 AMF 对已经能通信的 UE 下发的退避指令，UE 自己在客户端抑制重试。前者是"管道关阀"，后者是"客户端排队"。

Q2：AMF 过载时，紧急呼叫还能打吗？ A：能。这是过载控制的核心设计原则——分级降级、保命优先。无论 OverloadResponse 选哪一档，紧急呼叫（Emergency）、高优先级访问（MPS/ARP 高优先级）始终在白名单内；T3346 退避也明确把紧急/高优先级列为例外。这保证了极端拥塞下公共安全通道依然可用。

Q3：HTTP 503 的 Retry-After 和 NAS 的 T3346 是一回事吗？ A：不是。Retry-After 作用于 SBI/NF 间（如 SMF 对 AMF 的 HTTP 请求退避），是生产者对消费者讲的；T3346 作用于 UE 侧（5GMM 退避），是 AMF 对终端讲的。两者协议栈、作用对象、携带消息都不同，但都遵循"带抖动的指数级退避"思想。

Q4：为什么 T3346 要引入随机抖动？ A：为避免惊群效应。若 AMF 给大量同时被拒的 UE 下发相同 T3346 值，所有 UE 会在同一时刻重试，反而制造第二次拥塞尖峰。抖动让各 UE 的重试时刻在标称值附近分散，把尖峰削成平台，是分布式系统退避的经典做法。

Q5：切片级过载（OverloadStartNSSAIList）解决了什么问题？ A：解决了"一刀切"问题。若某条 eMBB 切片流量暴涨导致 AMF 过载，传统机制会拒掉所有切片的接入（含高价值 URLLC）。R17 引入的 OverloadStartNSSAIList 让 AMF 可以仅对指定切片触发过载，gNB 只削减该切片的接入，其它切片（尤其是 URLLC/MPS）不受影响，实现精细化拥塞隔离。

参考来源

1. 3GPP TS 38.413 V19.0.0 — NG-RAN; NGAP — OVERLOAD START/STOP 消息定义（clause 8）与过载控制基本过程（clause 9），OverloadResponse / TrafficLoadReductionIndication / OverloadStartNSSAIList IE
2. 3GPP TS 24.501 — NAS protocol for 5GS; clause 5.3.9 Handling of NAS level mobility management congestion control — T3346 back-off timer 与 NAS 拥塞控制行为
3. Cisco Ultra Cloud Core 5G AMF — Overload Control for N2 and NAS — 厂商实现视角的 N2/NAS 过载控制与会话定时器（T3346 NAS-CONGESTION 态）
4. 3GPP TS 29.500 — Technical Realization of Service Based Architecture; clause 6.4/6.5 Load & Overload control communication — SBI 负载/过载控制、HTTP 503 + Retry-After
5. 3GPP TS 29.510 — Nnrf Services API — Nnrf_NFManagement / NFStatusNotify、NFProfile.load 与负载感知路由

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