# 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）**体系，从源头逐层削峰： | 防御层 | 接口/协议 | 规范 | 削峰对象 | 削峰手段 | |--------|----------|------|----------|----------| | 第一层 N2 | NGAP | **TS 38.413** | gNB→AMF 的接入信令 | OVERLOAD START/STOP，按 OverloadResponse 拒 RRC | | 第二层 N1 | 5G-NAS | **TS 24.501 §5.3.9** | UE→AMF 的 NAS 请求 | back-off timer（T3346 / 5GSM）抑制重试 | | 第三层 SBI | HTTP/2 + Nnrf | **TS 29.500 §6.4/6.5、TS 29.510** | NF→AMF 的 SBI 请求 | HTTP 503 + Retry-After；NRF load 路由规避 | 下面给出三层防御的整体架构图： ```mermaid 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"的语义编码成四个互斥档位： | 枚举值（OverloadResponse） | gNB 处置 | 放行场景 | |---------------------------|----------|----------| | `reject-all-new-RRC-for-non-emergency-and-non-high-priority-MO-data` | 拒绝非紧急、非高优先级 MO 数据的新 RRC 建立 | MT 数据、紧急、高优先级、MPS 可建立 | | `reject-all-new-RRC-for-non-emergency-MO-data` | 拒绝所有非紧急 MO 数据的新 RRC 建立 | 紧急、MT、高优先级、MPS 可建立 | | `permit-only-emergency-and-MT-data` | 仅允许紧急会话与移动终止数据 | 紧急 + MT（含高优先级 MT） | | `permit-only-high-priority-and-emergency` | 仅允许高优先级 + 紧急 | 高优先级（MPS/ARP）+ 紧急 | 可选的 **TrafficLoadReductionIndication**（百分比 1–98）则是一种"软削峰"：gNB 在 RRC 建立层面按比例随机丢弃新接入，避免一刀切。R17 起增加的 **OverloadStartNSSAIList** 支持"切片级过载"——即 AMF 可以仅对某 S-NSSAI 触发过载，gNB 仅对承载该切片的接入信令执行削减，这是与 4G 的关键差异之一（4G 无切片概念）。 ### 2.2 NGAP 过载控制时序 ```mermaid 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 是"精准压制到某条业务通道"。 ```mermaid 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 退避定时器汇总表 | 定时器/IE | 作用域 | 携带消息 | 作用对象 | 例外放行 | |-----------|--------|----------|----------|----------| | **T3346**（5GMM back-off） | 全局移动性管理 | REGISTRATION/ SERVICE REJECT、DEREGISTRATION 等 | 所有 5GMM 过程 | 紧急、高优先级、MT 响应 | | **5GSM back-off timer value** | 会话级（per DNN+S-NSSAI） | PDU SESSION ESTABLISHMENT/ MODIFICATION REJECT | 仅匹配 DNN+切片的 PDU Session | 紧急 PDU Session、高优先级 | | （R16）per-S-NSSAI back-off | 切片级 | CONFIGURATION UPDATE / 拒绝消息 | 指定切片的接入 | 其它切片不受影响 | --- ## 四、第三层防御：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 过载控制时序 ```mermaid 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 内部一个**过载状态机**在不同水位下的渐进响应。下图刻画了从正常态到过载态再到恢复态的迁移： ```mermaid 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 抓包如何识别三层过载 | 抓包点 | 协议层 | 识别特征 | |--------|--------|----------| | gNB↔AMF（SCTP/NGAP） | N2 | 出现 `OVERLOAD START`（Procedure Code = id-Overload）；OverloadResponse 取值非空 | | UE↔网络（NAS） | N1 | `REGISTRATION REJECT`/`SERVICE REJECT`，cause = #22 Congestion，且携带 T3346 值 | | NF↔AMF（HTTP/2） | SBI | 响应码 `503`，响应头含 `Retry-After`；NRF 侧 `NFStatusNotify` 携带高 load 值 | 在 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](https://www.etsi.org/deliver/etsi_ts/138400_138499/138413/19.00.00_60/ts_138413v190000p.pdf) — 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](https://itecspec.com/3gpp/24.501/s/5.3.9) — T3346 back-off timer 与 NAS 拥塞控制行为 3. [Cisco Ultra Cloud Core 5G AMF — Overload Control for N2 and NAS](https://www.cisco.com/c/en/us/td/docs/wireless/ucc/amf/2026-02/config-and-admin/ucc-5g-amf-configuration-and-administration-guide-release-2026-02/m_overload-control-n2-nas.pdf) — 厂商实现视角的 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](https://www.etsi.org/deliver/etsi_ts/129500_129599/129500/17.07.00_60/ts_129500v170700p.pdf) — SBI 负载/过载控制、HTTP 503 + Retry-After 5. [3GPP TS 29.510 — Nnrf Services API](https://www.3gpp.org/dynareport/29510.htm) — 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 等场景全覆盖。