5G核心网AMF过载控制机制深度解读：NGAP OVERLOAD START与NAS T3346/T3502双级限流全景

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

在5G SBA架构中，AMF（Access and Mobility Management Function）是全网的信令汇聚点：所有UE的Registration、Service Request、Mobility Registration Update、Paging响应等N1/N2信令都要经过AMF处理。在物联网大规模部署（mMTC场景下单AMF可管理数百万NB-IoT终端）、灾害后网络恢复（海量终端同时开机重注册）、或核心网软件升级重启等异常场景下，瞬时信令洪峰可能直接压垮AMF进程。

更危险的是信令风暴（Signalling Storm）的正反馈效应：AMF因过载而响应变慢或宕机 → gNB重传/UE重试 → 信令量进一步放大 → 雪崩式瘫痪。3GPP在TS 23.501 §5.19.5.2中明确指出，当"AMF已达到过载状态，或基于TS 23.288 §6.22描述的NWDAF信令风暴分析判断信令风暴发生概率很高"时，AMF必须启动拥塞控制。

为此，3GPP设计了一套双级过载控制体系，从两个不同的关口拦截信令：

两级控制的精髓在于将拒绝动作尽可能前移：最理想的状况是UE根本不发NAS信令出来——由gNB在RRC层直接拒绝（UE侧由统一接入控制UAC barring阻止后续尝试），这样AMF完全不受影响；漏网的NAS请求到达AMF后，AMF用cause #22 + T3346告知UE"X分钟后再来"，避免UE立即重试形成风暴。

flowchart TB
    subgraph UE["UE"]
        A1["REGISTRATION REQUEST<br/>(5GMM NAS)"]
        A2["RRC Connection Request"]
    end
    subgraph GNB["gNB (NG-RAN)"]
        B1["UAC统一接入控制<br/>按Access Category拒绝<br/>RRC Reject + wait time"]
        B2["NAS转发决策"]
    end
    subgraph AMF["AMF"]
        C1["NAS级拥塞检测<br/>CPU/内存/会话数阈值"]
        C2["拒绝列表判定<br/>豁免: 紧急/MT/高优先级"]
        C3["NGAP过载决策<br/>minor / major / critical"]
    end
    D["5GMM cause #22 Congestion<br/>+ T3346退避定时器"]
    E["NGAP OVERLOAD START<br/>Overload Response +<br/>Traffic Load Reduction Indication"]
    F["NGAP OVERLOAD STOP"]

    A1 -->|"①漏网NAS请求"| C2
    C2 -->|"拒绝"| D
    D -.->|"T3346运行期<br/>禁止发起新注册/业务请求"| A1
    C3 -->|"过载开始"| E
    E -->|"②全量/按比例发送"| B1
    B1 -->|"RRC层拒绝"| A2
    C3 -->|"过载恢复"| F

二、N2过载控制：NGAP OVERLOAD START / STOP 详解

2.1 流程定位与消息特征

OVERLOAD START属于TS 38.413定义的NGAP非UE关联（non-UE associated）信令，方向为AMF → NG-RAN节点。dstest.info的NGAP字典对该消息的官方定义是：

"The purpose of the Overload Start procedure is to inform an NG-RAN node to reduce the signalling load towards the concerned Core Access and Mobility Management Function (AMF). The procedure uses non-UE associated signalling. This message is sent by the AMF and is used to indicate that the AMF is overloaded. Direction: AMF --> NG-RAN node."

TS 38.413 §8.7.7 / §8.7.8分别定义了Overload Start和Overload Stop过程。按照规范要求，NG-RAN节点收到OVERLOAD START后"shall consider the AMF as being in an overloaded state"（视该AMF为过载状态），并根据Traffic Load Reduction Indication"reduce the signalling traffic by the indicated percentage"（按指示百分比削减信令流量）；收到OVERLOAD STOP后清除该过载状态。

一个容易被忽视的细节：TS 23.501 §5.19.5.2要求，当同一PLMN内多个AMF（或同一AMF Set内的AMF）都向同一个gNB发送OVERLOAD START时，"应当确保信令负载在PLMN内和每个AMF Set内均匀分布"——这意味着gNB不能把所有过载AMF的流量都丢给同一个"健康"AMF，否则过载只是被转移而非消除。

2.2 关键Information Element解析

根据TS 23.501 §5.19.5.2，AMF通过OVERLOAD START可以请求gNB对本AMF正在服务的UE施加以下五种行为之一：

• a) 限制非紧急、非异常报告、非高优先级MO业务的5G-AN信令连接请求；
• b) 限制发往本AMF的上行NAS信令传输类连接请求；
• c) 限制AS层Requested NSSAI仅包含指定S-NSSAI的连接请求——该限制同样适用于RRC_INACTIVE恢复过程（当RAN侧存储UE上下文中的Allowed NSSAI仅包含OVERLOAD START所列S-NSSAI时）；
• d) 仅允许紧急会话和移动被叫（MT）业务；
• e) 仅允许高优先级会话、异常报告和MT业务。

这五种选项构成了一个从"全面封堵"到"保底放行"的策略光谱。设计意图非常清晰：紧急呼叫和被叫业务永远不能被过载控制杀死——用户欠费可以限速，但110/119电话和寻呼响应在任何拥塞等级下都必须放行（TS 23.501 §5.19.5.2特别要求"During an overload situation, the AMF should attempt to maintain support for emergency services and for MPS"）。

2.3 完整N2过载信令时序

sequenceDiagram
    autonumber
    participant UE as UE
    participant gNB as gNB (NG-RAN)
    participant AMF as AMF

    Note over AMF: 系统负载超阈值<br/>(如 critical: 95%)
    AMF->>gNB: NGAP OVERLOAD START<br/>Overload Response = reject-non-emergency-sessions<br/>Traffic Load Reduction = 60%
    Note over gNB: 标记该AMF为过载状态<br/>激活UAC按比例barring

    UE->>gNB: RRC Connection Request<br/>(Access Category判定)
    gNB-->>UE: RRC Reject (wait time)<br/>注: 也可在SIB1广播barring参数

    Note over UE: UE按wait time退避<br/>不再立即重试

    UE->>+AMF: RRC/Initial UE Message<br/>REGISTRATION REQUEST (漏网流量)
    AMF-->>UE: REGISTRATION REJECT<br/>cause #22 + T3346 (双保险)

    Note over AMF: 负载降至阈值以下
    AMF->>gNB: NGAP OVERLOAD STOP<br/>(清除过载状态)
    Note over gNB: 恢复正常接纳策略
    AMF->>-AMF: 恢复处理全量NAS信令

恢复阶段有个细腻的设计：TS 23.501 §5.19.5.2规定AMF恢复时有两种选择——发送新的OVERLOAD START（把百分比调高，允许更多连接成功）或直接发OVERLOAD STOP。这允许AMF做灰度恢复而不是一步到位，避免恢复瞬间积压UE涌入再次触发过载。

三、NAS级拥塞控制：cause #22 与 T3346 的攻防博弈

3.1 AMF侧：谁能拒绝，谁必须放行

TS 24.501 §5.3.9规定，当通用NAS级拥塞控制激活时，AMF不应拒绝以下7类请求：

这份豁免清单是排错时的"金标准"——凡是AMF在拥塞期拒绝了e)类paging触发的Service Request，都是违反规范的实现缺陷。

对于其余请求（初始注册、CM-IDLE态的Service Request、CM-IDLE态的MRU、周期性注册更新等），AMF拒绝时在REGISTRATION REJECT / SERVICE REJECT中携带5GMM cause #22 "Congestion" 以及T3346 value IE。UE收到后启动T3346，在定时器运行期间禁止发起新的Registration/Service Request（豁免场景除外）。

一个关键的工程细节（TS 24.501 §5.3.9原文）："To avoid that large numbers of UEs simultaneously initiate deferred requests, the AMF should select the value for the timer T3346 for the rejected UEs so that timeouts are not synchronised."——AMF必须为不同UE随机化T3346取值，否则所有被拒UE会在同一毫秒集体重试，退避机制反而制造了第二波同步风暴。这是典型的分布式系统"抖动（jitter）"设计在电信协议中的体现。

3.2 T3346的七条特殊行为规则

TS 24.501 §5.3.9对UE侧T3346的处理定义了大量边界情况，以下几条是开发和测试中最容易踩坑的：

1. 双接入绑定：UE在3GPP接入和non-3GPP接入同时注册到同一PLMN时，AMF下发的T3346对两种接入同时生效；
2. Paging打断退避：T3346运行中收到paging或NOTIFICATION消息，UE停止两种接入的T3346并立即响应——被叫优先级永远高于退避；
3. 去注册后仍继续：T3346运行中UE进入5GMM-DEREGISTERED态，但只要保持开机且USIM不变，T3346继续运行（防止去注册-重注册循环绕过退避）；
4. 关机-开机续跑：设t1为关机时T3346剩余时间、t为关机到开机的间隔——若t1 > t，开机后以(t1 − t)重启定时器；若t1 ≤ t则无需重启；若UE无法确定t，则以t1重启。这条规则堵死了"重启手机绕过拥塞退避"的漏洞；
5. 换非等效PLMN则失效：UE在T3346运行中进入一个非等效的新PLMN/SNPN并发起5GMM过程时，停止T3346——因为退避只针对发出它的那个网络；
6. 注册状态联动：注册区域改变后，若T3346在运行且5GS update status为5U1 UPDATED，UE须将状态改为5U2 NOT UPDATED并进入5GMM-REGISTERED.ATTEMPTING-REGISTRATION-UPDATE（确保定时器到期后能完整重注册）；
7. 豁免穿透：高优先级UE、紧急业务/紧急回退、不连续覆盖不可用性报告，即使T3346运行中也允许发起5GMM过程。

3.3 UE状态机视图

stateDiagram-v2
    [*] --> T3346_Idle: 初始状态
    T3346_Idle --> T3346_Running: 收到REJECT<br/>cause #22 + T3346
    T3346_Running --> T3346_Running: 3GPP/non-3GPP接入同时受限
    T3346_Running --> T3346_Idle: 定时器到期<br/>发起重注册
    T3346_Running --> T3346_Idle: 收到paging/NOTIFICATION<br/>(停止并响应被叫)
    T3346_Running --> T3346_Running: 进入5GMM-DEREGISTERED<br/>(开机+USIM不变则继续)
    T3346_Running --> T3346_Suspended: 关机 (保存t1)
    T3346_Suspended --> T3346_Running: 开机 (t1>t时以t1-t续跑)
    T3346_Running --> T3346_Idle: 切换到非等效PLMN/SNPN
    T3346_Running --> Emergency_Path: 紧急业务/高优先级/异常报告<br/>(豁免穿透)
    Emergency_Path --> T3346_Running: 过程完成后定时器继续

3.4 T3502：注册尝试层面的第二道闸门

除T3346外，REGISTRATION REJECT中还可能携带T3502 value IE，同时gNB也可以在SIB1中广播T3502值（另见TS 38.331）。T3502是周期性注册尝试定时器：当UE因cause #22被拒或收到特定拒绝原因后，除了单次退避T3346，还需等待T3502才能进行下一次注册尝试。3glteinfo的排错文档描述了典型现场表现："Registration Reject received with cause #22 - T3346 or T3502 is present"，解读为"network is applying explicit retry control"（网络正在施加显式重试控制）。

T3346与T3502的分工：T3346管"这一次被拒后多久能再试"（UE本地定时器，网络点对点下发）；T3502管"整个区域内注册尝试的节奏"（可在小区广播层面统一约束），两者叠加构成双层重试节流。

3.5 一个致命的交互：T3346 vs T3512 + 隐式去注册

Cisco AMF实现文档披露了一个标准要求但容易被实现忽略的边界：若AMF下发的T3346值大于UE的周期性注册定时器T3512与隐式去注册定时器之和，AMF必须相应调整自身的mobile reachable timer和implicit deregistration timer，否则会出现荒谬的局面——UE还在老老实实等T3346退避，AMF却因"太长时间没有周期性注册更新"把它隐式去注册了，定时器到期后的重注册反而变成了全新注册，信令开销更大且用户上下文丢失。

四、为什么这样设计：三重设计意图剖析

意图一：拒绝动作逐级前移，保护最昂贵的资源。 AMF的处理能力（CPU/内存/事务上下文）是最稀缺资源，gNB的处理能力次之，UE自身的重试行为最廉价。N2过载控制在gNB层用RRC Reject拦截（每条被拦消息不消耗任何AMF资源），NAS控制在AMF层用T3346换取"延迟到达"而非"丢弃"。两级配合下，AMF只需要处理极小比例的漏网流量。

意图二：百分比削峰 + 定时器随机化 = 分布式流量整形。 Traffic Load Reduction Indication（1–99%）允许AMF像调节水阀一样渐进泄洪；T3346取值的去同步化要求，则防止"锯齿形"流量脉冲。两者结合，把无序的信令洪峰整形为可平滑消化的稳态负载。

意图三：过载不等于降级安全与可达性。 无论哪一级控制，紧急业务、MT业务、高优先级用户（MPS）、异常报告都被硬性豁免。这反映了3GPP的一贯立场：拥塞控制优化的目标是"多数人的普通业务让路"，而不是"所有人的所有业务陪葬"。

五、与其他方案对比

六、实战：抓包识别、故障排查与厂商实现

6.1 抓包如何识别

N2侧在SCTP 38412端口上抓包，Wireshark中直接使用以下过滤式：

• ngap.OverloadStart / ngap.OverloadStop —— 定位过载开始/停止消息；
• ngap.TrafficLoadReductionIndication —— 查看AMF要求的削峰百分比；
• ngap.OverloadResponse —— 确认gNB被要求执行的拒绝策略（枚举值对应§2.2的五种行为）。

NAS侧在N1信令（经Initial UE Message / Downlink NAS Transport封装）中过滤：

• nas-5gs.mm.message_type == 0x45（REGISTRATION REJECT类消息）附近配合
• nas-5gs.mm.cause == 22 —— 5GMM cause #22 "Congestion"；
• 同一条REJECT中的T3346 value IE采用GPRS Timer 3式编码（TS 24.501 §9.11.2），解码时注意单位换算（分钟为最小粒度）。

健康网络中OVERLOAD START应当几乎不出现；若在稳定期反复看到，大概率是阈值配置过低（Cisco实现中minor默认可配置为85%负载）而非真实过载。

6.2 常见故障点与排错思路

1. UE反复注册失败，REJECT带cause #22：先查AMF负载监控（如Cisco的amf_overload_status指标，取值minor/major/critical）；确认是真实拥塞还是阈值误配；再查T3346取值是否被正确随机化——若所有REJECT中T3346值完全相同，说明AMF实现违反了去同步化要求，退避到期时会形成同步重试脉冲；
2. 过载期间被叫丢失：检查AMF是否拒绝了paging触发的Service Request（违反§3.1豁免表e项）；同时检查gNB是否把UAC barring错误地施加到了被叫接入尝试上；
3. OVERLOAD START只发给部分gNB：这可能是AMF的刻意设计（TS 23.501 §5.19.5.2允许通过控制发送比例来匹配削峰需求），但如果目标是全量限制而只发了部分，属于AMF过载扩散逻辑缺陷；
4. T3346到期后UE仍未注册成功且状态为5U2：核对UE是否正确执行了"注册区域改变后置5U2 NOT UPDATED"规则，以及AMF是否在T3346 > T3512+隐式去注册定时器之和时调整了自身的可达性定时器；
5. SNPN本地业务场景的误判：SNPN提供本地化服务时，AMF可能用cause #74 "Temporarily not authorized for this SNPN"且不带T3346（TS 24.501 §5.3.9），让UE进入PLMN-SEARCH重选网络——不要把它当拥塞故障处理。

常见问题

Q1: OVERLOAD START（N2级）和REGISTRATION REJECT cause #22 + T3346（NAS级）同时存在吗？谁是主力？ A: 两者通常级联出现但分工不同。N2级是"预防性"的——gNB在RRC层直接拒绝，NAS请求根本到不了AMF；NAS级是"兜底"的——漏网请求到达AMF后被拒并下发T3346。一个完整过载事件中，你会先看到AMF发出OVERLOAD START，随后gNB侧大量RRC Reject，只有少量NAS REJECT（漏网流量）。若只看到NAS REJECT而没有OVERLOAD START，说明AMF只启用了NAS拥塞（N2功能未配置或未触发）。

Q2: T3346和T3502的区别是什么？ A: T3346是UE本地的MM退避定时器，由AMF在REGISTRATION REJECT/SERVICE REJECT中针对该UE单独下发，运行期内禁止发起新的注册/业务请求（豁免除外）；T3502是注册尝试级定时器，可在REJECT中下发、也可由gNB在SIB1中小区级广播，约束的是下一次注册尝试的时机。T3346粒度是"这个UE + 这类请求"，T3502粒度是"这个小区/网络 + 注册动作"。

Q3: UE收到cause #22 + T3346后强制关机再开机，能绕过退避吗？ A: 不能。TS 24.501 §5.3.9明确要求：开机后若t1（关机时剩余时间）大于关机经过时间t，则以t1 − t重启T3346；无法确定t则以t1重启。且T3346运行中去注册（保持开机、USIM不变）也不会停止定时器。这条规则专门封堵"重启绕过"漏洞，测试用例中应覆盖。

Q4: 过载时紧急呼叫会不会被拒绝？MT业务（别人打给我的电话）呢？ A: 不会被拒绝。两级控制都有硬性豁免：N2级OVERLOAD START的d)/e)选项明确"only permit emergency sessions and mobile terminated services"；NAS级TS 24.501 §5.3.9的a)/e)项禁止拒绝紧急请求和paging触发的请求。且T3346运行中收到paging，UE必须停止定时器并立即响应。若现场出现紧急呼叫或被叫因拥塞失败，属于违规实现，可直接对照规范提缺陷。

Q5: Overload Start NSSAI（切片级限流）现网能用吗？ A: 标准完全支持——TS 23.501 §5.19.5.2允许AMF在OVERLOAD START中携带S-NSSAI列表，只限制指定切片的信令，甚至覆盖RRC_INACTIVE恢复场景。但商用实现进度不一：Cisco AMF 2026.03版文档明确将其列为局限（"N2 Overload Control is applied at the system-level and not supported at individual S-NSSAI"）。在多切片专网项目中，该能力需纳入POC验证项而非默认假设可用。

参考来源

1. TS 23.501 Section 5.19.5.2 — AMF Overload Control（iTecSpec在线规范） — N2过载控制五种Overload Response行为、S-NSSAI限制、百分比削峰、恢复策略的规范原文
2. TS 24.501 Section 5.3.9 — Handling of NAS level mobility management congestion control（iTecSpec在线规范） — T3346全部行为规则、7类豁免清单、cause #22/#74定义
3. 3GPP TS 24.501 V18.8.0（ETSI PDF，Rel-18） — NAS协议正式版本，含消息IE编码
4. 3GPP TS 38.413 V16.2.0 — NG-RAN; NG Application Protocol（ETSI PDF） — OVERLOAD START/STOP过程定义（§8.7.7/§8.7.8）
5. Cisco UCC 5G AMF配置管理指南 Release 2026.03 — Overload Control for N2 and NAS — 商用AMF的三级阈值、action profile配置与实现局限性
6. OVERLOAD START Message — dstest.info NGAP字典 — NGAP消息方向与非UE关联信令定义
7. 5G Registration Reject Cause Analysis — 3glteinfo — cause #22现场排错流程
8. LTE EMM Cause #22: Congestion and T3346 Back-off Timer — hicelltek — LTE同名机制背景，用于4G/5G对照
9. NextgCoreLab/nextgsim issue #41 — NGAP Overload Start实现缺陷 — 开源gNB实现OVERLOAD START的规范引用与缺陷记录

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