5G AMF过载控制机制全链拆解：NGAP Overload Start/Stop 与 SBI OCI 双平面抑制

一、机制定位：为什么5G核心网的过载防线必须落在AMF

在5G系统（5GS）架构中，AMF（Access and Mobility Management Function）是整个控制面信令的"漏斗尖"。无论UE发起注册、去注册、服务请求、移动性更新，还是被叫寻呼响应，所有NAS信令都必须先经过NG-RAN（gNB）的N2接口汇聚到AMF；AMF再通过SBI（Service Based Interface）把业务扇出到SMF、UDM、AUSF、PCF、NSSF等NF。这意味着任何一个信令风暴源——大规模IoT上电、地震/体育赛事触发的同步重注册、信令DDoS、邻区故障触发的批量切换——都会把流量集中到AMF这一节点。一旦AMF的CPU、内存或信令队列被打爆，后果不是某个UE掉线，而是整片服务区的所有接入请求全部超时，形成"信令雪崩"。

5G为此设计了三层防线：

本文聚焦的核心机制，是N2平面的NGAP Overload Start/Stop（反应式过载通告），并把它与SBI平面的OCI（Overload Control Information）概率抑制作为一对孪生机制完整拆解——二者共同实现了3GPP在TS 23.501中定义的"优雅降级（graceful degradation）"目标：过载时按优先级丢弃低价值业务、保护紧急/高优先级业务，而不是整体崩溃。值得注意的是，这一机制在已覆盖主题列表中尚未出现，且属于典型的core-network域机制。

二、N2控制面：NGAP Overload Start/Stop 全链拆解

2.1 触发条件与消息本质

Overload Start并非由任何外部信令触发，而是AMF本地拥塞检测函数的产物。AMF持续监控内部指标——CPU利用率、内存占用、NAS信令队列深度、单位时间内Pending的InitialUEMessage数量、SCTP流控状态等。当任一指标越过运营商可配置的"拥塞阈值（congestion threshold）"并持续一个去抖周期后，AMF的拥塞控制状态机进入过载态（overloaded），随即向所有与之建立NG接口关联的gNB发送NGAP OVERLOAD START消息。

关键点：OVERLOAD START属于NGAP的"非UE关联信令（non-UE-associated signalling）"，它在SCTP关联级别上发送，不携带任何特定UE的标识，因此一条消息即可影响该gNB下所有后续UE的接纳决策。这一点与初始上下文建立、PDU会话建立等"UE关联信令"形成鲜明对照——后者每UE一条、必须串行，而Overload Start是一条消息管控一片基站。

2.2 完整信令时序

sequenceDiagram
    participant UE
    participant gNB as NG-RAN (gNB)
    participant AMF
    participant NF as 其他NF (SMF/UDM/PCF)
    AMF->>AMF: 本地拥塞检测<br/>(信令队列/CPU 越过阈值)
    AMF->>gNB: NGAP OVERLOAD START<br/>(OverloadAction, TrafficLoadReduction=30%,<br/>Overload Start NSSAI List[可选,Rel-16])
    AMF->>NF: HTTP响应携带OCI header<br/>(metric=40, period=10s, epoc)
    Note over gNB: gNB进入过载抑制态<br/>按OverloadAction过滤RRC请求
    UE->>gNB: RRCSetupRequest (cause=mo-Signalling)
    gNB-->>UE: RRCReject (被抑制)
    UE->>gNB: RRCSetupRequest (cause=emergency)
    gNB->>AMF: InitialUEMessage (紧急业务放行)
    Note over AMF: 负载回落至恢复阈值以下
    AMF->>gNB: NGAP OVERLOAD STOP
    Note over gNB: 退出过载抑制态<br/>恢复正常接纳

2.3 OVERLOAD START消息的IE结构

OVERLOAD START消息在TS 38.413 clause 8（Elementary Procedures）中定义，其承载的IE见clause 9.3。下表逐项拆解：

其中Overload Action是整个机制的灵魂，它直接决定gNB在收到RRC连接请求时放行还是拒绝。其结构关系如下：

flowchart TD
    A["NGAP OVERLOAD START 消息<br/>(非UE关联信令)"] --> B["Overload Response (M)"]
    A --> C["Traffic Load Reduction Indication (O)"]
    A --> D["Overload Start NSSAI List (O, Rel-16)"]
    B --> E["Overload Action (枚举)"]
    E --> E1["reject-non-emergency-mo-data-transfers<br/>拒绝非紧急主叫数据"]
    E --> E2["reject-mo-signalling<br/>拒绝主叫信令"]
    E --> E3["permit-emergency-and-mt-only<br/>仅放行紧急会话+被叫业务"]
    E --> E4["permit-high-priority-and-mt-only<br/>仅放行高优先级+被叫业务"]
    D --> D1["SliceOverloadItem: NSSAI"]
    D1 --> D2["该切片独立的 Overload Action"]

四种Overload Action对应的gNB实际行为：

设计意图极其清晰：按业务价值分层降级。紧急呼叫（如110/120）、被叫业务（避免主叫方听到盲音）、MPS/MCS优先通信被层层保护在抑制策略的"白名单"里；而普通的"主叫信令"（如周期性注册更新）和"主叫数据"则是首先被牺牲的对象。这种分层，让网络在过载时仍能维持核心社会功能，而不是无差别地拒绝一切。

2.4 Traffic Load Reduction：从"二元拒绝"到"概率抑制"

仅有Overload Action的"一刀切"拒绝是不够的——它会导致流量在过载阈值上下剧烈震荡（乒乓效应）。为此引入了Traffic Load Reduction Indication：一个0–100的百分比。gNB在执行Action的基础上，再对"本应放行"的请求进行概率丢弃。例如Action=permit-emergency-and-mt-only、TrafficLoadReduction=30，意味着即使是被叫业务，也有30%的概率被随机拒绝。

概率丢弃是一个去中心化的优雅设计：gNB本地用伪随机数决定每个请求的去留，无需再向AMF逐条请示，既减轻了AMF的负担，又实现了平滑的流量削减曲线，避免了硬阈值带来的抖动。

2.5 Overload Start NSSAU List：Rel-16切片感知过载

5G网络切片让"过载"从"AMF整体过载"细化到"切片级过载"。Rel-16引入的Overload Start NSSAI List允许AMF在一条OVERLOAD START中携带多个切片项，每项独立指定一个NSSAI及其专属的Overload Action。这意味着AMF可以对"某个mMTC切片的IoT洪峰"施加reject-mo-signalling，而对同一节点上承载的URLLC切片保持完全放行——实现切片间的过载隔离，这是网络切片承诺SLA的关键一环。

2.6 OVERLOAD STOP：解除抑制

当AMF检测到负载回落至"恢复阈值"以下（恢复阈值通常设得比触发阈值低，构成迟滞回环hysteresis，避免乒乓），AMF发送NGAP OVERLOAD STOP消息。该消息结构极简——核心是让gNB恢复到正常接纳态。设计上，Overload Stop与Overload Start在同一非UE关联信令通道上对称出现，构成完整的"抑制-恢复"生命周期。

三、SBI控制面：OCI（Overload Control Information）概率抑制

AMF的过载不仅来自gNB侧的接入信令，也来自核心网内部NF对AMF的SBI调用（如SMF的Namf_Communication服务、UDM/AUSF在注册流程中与AMF的交互）。为此，TS 29.500 clause 6.4定义了OCI机制，把概率抑制思想从N2平面延伸到SBI平面。

3.1 OCI的参数与工作方式

OCI通过HTTP/2响应（及可选的请求）头携带一组参数，核心字段如下：

当AMF（作为NF service producer）过载时，它在给SMF/UDM等消费端的HTTP响应中插入OCI。消费端收到后，在本地建立一条"概率丢弃管道"：后续发往该AMF实例的请求，按metric%随机本地丢弃，被丢弃的请求直接返回错误而不真正上送，从而从源头削减AMF负载。

sequenceDiagram
    participant C as NF Consumer (SMF)
    participant P as NF Producer (AMF, 过载)
    C->>P: HTTP/2 POST Namf_Communication_N1N2MessageTransfer
    P-->>C: HTTP 200 + OCI header (metric=40, period=10s, epoc=...)
    Note over C: 消费端记录OCI策略<br/>建立40%概率丢弃管道
    loop 后续请求
        C->>C: 随机判定: 丢弃 or 上送?
        alt 未命中丢弃
            C->>P: 正常上送请求
            P-->>C: 正常响应
        else 命中丢弃
            C->>C: 本地直接丢弃<br/>(不占用AMF资源)
            C-->>C: 上层重试/降级
        end
    end

3.2 与NRF负载选择的协同

OCI是反应式（reactive）的——负载已超时才通告抑制。而TS 29.510（NRF）的NF负载信息则是预防式（proactive）的：每个NF在向NRF注册/更新（Nnrf_NFManagement）时上报capacity、load、loadTimeStamp等字段；消费端通过Nnrf_NFDiscovery选择实例时，可依据load做加权选择，把新流量导向较空闲的AMF实例。二者构成"预防式负载均衡 + 反应式过载抑制"的完整闭环。值得注意的是，NG Setup Response和AMF Configuration Update中携带的Relative AMF Capacity（0–255）与AMF Weight Factor，是N2平面预防式负载均衡的对应物——gNB据此在新UE接入时把流量按权重分发到AMF Set内的不同实例。

四、N2 + SBI双平面协同：一次真实过载事件的完整轨迹

把前述机制串联起来，一次典型的"地震触发同步重注册"过载事件，其完整轨迹为：

sequenceDiagram
    participant Storm as 信令风暴<br/>(海量UE同步重注册)
    participant gNB
    participant AMF
    participant SMF
    participant UDM
    Storm->>gNB: 海量RRCSetupRequest
    gNB->>AMF: 海量InitialUEMessage
    Note over AMF: CPU/信令队列越过拥塞阈值
    rect rgb(255,235,235)
    AMF->>gNB: OVERLOAD START<br/>(permit-emergency-and-mt-only, TLR=30, NSSAI List)
    AMF-->>SMF: OCI header(metric=40)
    AMF-->>UDM: OCI header(metric=40)
    end
    gNB-->>Storm: 大量RRCReject(主叫业务)
    SMF->>SMF: 40%概率丢弃对AMF的调用
    Note over AMF: 流量被双平面同时削减<br/>负载逐步回落
    rect rgb(235,255,235)
    AMF->>gNB: OVERLOAD STOP
    end
    Note over gNB: 恢复正常接纳

可以看到，N2平面的Overload Start从"接入侧"切断了新增信令的源头，而SBI平面的OCI从"核心网内部"削减了正在处理的流程对AMF的进一步调用——两把剪刀同时落下，才能在最短时间内把AMF从崩溃边缘拉回。

六、抓包识别与故障排查

6.1 抓包识别

在Wireshark中，Overload Start/Stop可通过如下方式定位：

• 显示过滤器：ngap && (ngap.procedureCode == <id-OverloadStart> || ngap.procedureCode == <id-OverloadStop>)，或在NGAP消息树中直接展开查看Overload Response、Traffic Load Reduction Indication、Overload Start NSSAI List字段。
• 由于是非UE关联信令，它出现在SCTP关联的初始化后、不携带任何UE相关的RAN UE NGAP ID/AMF UE NGAP ID，这是与UE关联信令快速区分的特征。
• SBI侧的OCI则可在HTTP/2响应头中观察Overload Control Information相关头部及其metric/period字段。

6.2 常见故障点

1. Overload Stop丢失/延迟：AMF负载已回落，但OVERLOAD STOP因SCTP链路问题未送达，导致gNB长期处于抑制态，大量正常用户被拒。排查：核对gNB与AMF两侧抑制状态机时间线，确认Stop消息收发。
2. Overload Action策略过激：如长期配置permit-emergency-and-mt-only + 高TrafficLoadReduction，会持续掉话。需结合现网话务结构调优。
3. NSSAI列表不匹配：Rel-16切片感知过载要求gNB与AMF对NSSAI编码理解一致，否则切片项被忽略，退化为整体抑制。
4. OCI metric过高导致雪崩式重试：消费端按metric丢弃后，若上层无退避，会产生重试风暴，反向加剧拥塞。应配合Retry-After与指数退避。
5. 迟滞区间设置不当：触发阈值与恢复阈值过近，导致Overload Start/Stop频繁交替（乒乓），信令面震荡。

七、横向对比：5G NGAP vs SBI OCI vs 4G S1AP

可以看到，5G在继承4G成熟模型的基础上，用OCI补齐了核心网内部的过载缺口，并用NSSAI List补齐了切片感知能力，构成了比4G更完整的过载防御体系。

常见问题

Q1：NGAP Overload Start和AMF Configuration Update有什么区别？

A：二者都走N2非UE关联信令，但目的不同。Overload Start是反应式过载抑制——AMF已过载，通告gNB削减新接入；AMF Configuration Update是配置同步——更新GUAMI列表、Relative AMF Capacity、AMF Weight Factor等供gNB做预防式AMF选择。前者是"已经着火、关掉进风口"，后者是"调整消防通道布局"。Relative AMF Capacity的更新可视为负载均衡的预防手段，而Overload Start才是真正的应急抑制。

Q2：gNB收到Overload Start后，是否需要向AMF逐条确认每个被拒绝的UE？

A：不需要。gNB在本地按Overload Action和Traffic Load Reduction的概率模型，自主决定放行还是拒绝（对被拒UE发送RRCReject）。这一设计正是为了避免过载时反而向AMF产生更多确认信令，把抑制决策彻底下放到最接近源头的gNB。

Q3：SBI的OCI metric=50，消费端是真的"每2个请求丢1个"吗？

A：理论上metric=50表示50%的概率丢弃，但实际是基于伪随机的统计丢弃，在足够多请求样本上趋近于50%，单次行为是概率性的。消费端通常维护一个滑动窗口的丢弃计数器，使长期丢弃率收敛到目标值，避免简单的"交替丢弃"被流量模式反向利用。

Q4：Overload Start NSSAU List中，gNB如何知道某个RRC请求属于哪个切片？

A：UE在RRCSetupRequest本身不携带NSSAI；但gNB可在5G-GUTI已分配的UE上下文、或AMF在Initial Context Setup时下发的Allowed NSSAI中获得切片归属信息。对于全新UE，gNB可结合默认切片策略与Overload Start NSSAI List中的默认项处理。这也是为什么切片感知过载在首次注册场景下的精细度受限——它对已有上下文的UE更精准。

Q5：为什么4G只有S1AP过载而5G新增了OCI？

A：4G核心网网元间（MME-SGW-PGW）是Diameter/GTP-C点对点接口，过载主要由MME→eNB的S1AP单一平面承担。5G改用SBI服务化架构后，NF间调用是HTTP/2松耦合的，任何一个NF Producer都可能成为瓶颈，仅靠N2平面无法覆盖核心网内部拥塞，因此3GPP必须为SBI单独定义OCI，形成N2+SBI双平面过载防御。

参考来源

1. 3GPP TS 38.413 V19.0.0 — NG-RAN; NG Application Protocol (NGAP) — Overload Start/Stop过程（clause 8）与Overload Response/Action、Traffic Load Reduction Indication、Overload Start NSSAI List等IE（clause 9.3）。
2. 3GPP TS 29.500 — 5G System; Technical Realization of SBI, Section 6.4 Overload Control — OCI参数定义与概率抑制模型（6.4.2 / 6.4.3.2）。
3. 3GPP TS 29.510 — Network Repository Function (NRF); Nnrf_NFManagement/NFDiscovery — NF负载/容量上报与预防式负载均衡。
4. Cisco UCC 5G AMF Configuration & Administration Guide — Overload Control for N2 and NAS — 商用AMF过载控制特性与参数配置。
5. 5G NGAP Overload Start Message — 3glteinfo — Overload Start消息IE结构与图解。
6. Open5GS NGAP Protocol Handling — DeepWiki — 开源参考实现中Overload Start/Stop的处理逻辑。

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