首页 › core-network › 5G AMF过载控制三层防护机制拆解

5G AMF过载控制三层防护机制全链拆解

一、概述:为什么AMF过载控制如此关键

在5G核心网架构中,AMF(Access and Mobility Management Function)是所有UE接入的第一道关口,承担着注册管理、连接管理、可达性管理和NAS信令传递四大核心职责。当信令风暴(Signaling Storm)来袭——无论是海量物联网设备同时上线、突发事件引发集中注册潮、还是NF异常导致信令重传风暴——AMF首当其冲。

3GPP在TS 23.501 Section 5.19.5.2和TS 23.502 Section 4.2.5中定义了AMF过载控制的完整框架。与4G时代MME仅依赖S1AP Overload单一机制不同,5G引入了三层立体防护体系:

层次 接口 协议 核心机制 规范依据
第一层:N2过载控制 N2 (AMF↔gNB) NGAP Overload Start/Stop TS 38.413 Section 8.7.7
第二层:NAS拥塞控制 N1 (AMF↔UE) 5GMM/5GSM Back-off Timer + Cause Code TS 24.501 Section 5.5
第三层:SBI过载控制 SBI (AMF↔其他NF) HTTP/2 503/429/OCI Header TS 29.500 Section 6.4

这三层机制协同工作,从RAN侧节流、UE侧退避、NF侧限流三个维度,构成AMF过载保护的完整闭环。

flowchart TB
    subgraph 过载源["信令过载来源"]
        A1["海量IoT设备同时上线"]
        A2["突发事件集中注册潮"]
        A3["NF异常导致信令重传"]
        A4["恶意信令风暴攻击"]
    end

    subgraph AMF["AMF 过载控制三层防护"]
        B1["第一层: N2过载控制<br/>NGAP Overload Start/Stop<br/>→ gNB侧节流"]
        B2["第二层: NAS拥塞控制<br/>Registration/Service Reject<br/>+ T3346/T3525退避定时器<br/>→ UE侧退避"]
        B3["第三层: SBI过载控制<br/>HTTP 503/429 + OCI Header<br/>→ NF侧限流"]
    end

    subgraph 监控["AMF内部监控"]
        C1["CPU利用率"]
        C2["内存使用率"]
        C3["NAS连接数"]
        C4["消息队列深度"]
        C5["信令处理延迟"]
    end

    A1 & A2 & A3 & A4 --> B1 & B2 & B3
    C1 & C2 & C3 & C4 & C5 -->|"触发阈值"| B1 & B2 & B3

二、第一层防护:N2接口NGAP过载控制详解

2.1 Overload Start消息的完整IE结构

当AMF检测到自身过载时,首先通过N2接口向所有连接的gNB发送NGAP Overload Start消息。该消息定义在TS 38.413 Section 8.7.7.1,是AMF→NG-RAN方向的非UE关联信令(Non-UE associated signalling)。

根据TS 38.413规范,Overload Start消息的关键IE如下:

IE名称 是否必选 类型 说明
AMF Name M(必选) OCTET STRING 过载AMF的标识
Overload Response M ENUMERATED 告知gNB应采取的过载响应动作
Traffic Load Reduction Indication O(可选) INTEGER(0..100) 请求gNB减少的信令流量百分比
Overload Start NSSAI List O SEQUENCE OF 针对特定S-NSSAI切片的过载控制

其中,Overload Response是整个消息的灵魂,定义了四种响应动作:

动作值 含义 gNB行为
overload-reject-all-non-emergency-sessions 拒绝非紧急会话 gNB拒绝所有非紧急的初始NAS消息,仅允许紧急注册/呼叫
overload-reject-all-new-sessions 拒绝所有新会话 gNB拒绝所有新建立的NAS信令连接
overload-allow-emergency-and-high-priority-only 仅允许紧急和高优先级 gNB仅转发紧急和高优先级接入类别(Access Identity 1/2)
overload-reject-all-new-sessions-except-emergency-and-mobility 仅允许紧急和移动性注册 gNB拒绝新会话但允许移动性注册和紧急业务
sequenceDiagram
    participant AMF
    participant gNB1 as gNB-1
    participant gNB2 as gNB-2
    participant gNB3 as gNB-3

    Note over AMF: 监控到CPU>85%<br/>NAS连接数>阈值<br/>消息队列积压

    AMF->>gNB1: NGAP Overload Start<br/>Overload Response = reject-all-non-emergency<br/>Traffic Load Reduction = 60%
    AMF->>gNB2: NGAP Overload Start<br/>Overload Response = reject-all-non-emergency<br/>Traffic Load Reduction = 60%
    AMF->>gNB3: NGAP Overload Start<br/>Overload Response = allow-emergency-high-priority-only<br/>Overload Start NSSAI List = SST:1 SD:010203

    Note over gNB1,gNB2: 开始按60%比例<br/>丢弃非紧急NAS信令
    Note over gNB3: 仅转发紧急会话<br/>且仅限特定切片

    gNB1--xAMF: RRC Reject (非紧急UE)
    gNB2--xAMF: 拒绝新NAS连接

    Note over AMF: 过载缓解<br/>CPU<60%

    AMF->>gNB1: NGAP Overload Stop
    AMF->>gNB2: NGAP Overload Stop
    AMF->>gNB3: NGAP Overload Stop

    Note over gNB1,gNB3: 恢复正常信令转发

2.2 Traffic Load Reduction Indication的精妙设计

Traffic Load Reduction Indication IE是一个0到100的整数值,表示AMF希望gNB减少的信令流量百分比。例如,值为60表示gNB应当只转发40%的非紧急信令流量。

这个机制的设计精妙之处在于渐进式过载恢复:

这种渐进式设计避免了"全有全无"的粗暴方式,保障了关键业务(紧急呼叫、高优先级政府/公共安全用户)的连续性。

2.3 切片感知的过载控制(Slice-Aware Overload)

5G引入了网络切片概念,AMF可以为不同切片施加差异化的过载控制策略。通过Overload Start NSSAI List IE,AMF可以:

这一点在TS 23.501 Section 5.19.5.2中有明确描述:AMF可以根据收到的信令风暴分析信息(来自NWDAF,参见TS 23.288 Section 6.22),针对特定UE组、特定切片或特定优先级进行精细化过载控制。

2.4 Overload Stop消息

当AMF恢复正常运行状态后,发送NGAP Overload Stop消息(TS 38.413 Section 8.7.7.2),通知gNB恢复正常信令转发。该消息结构极为简洁:

IE名称 是否必选 说明
AMF Name M 恢复正常的AMF标识

gNB收到Overload Stop后,立即停止所有过载节流动作,恢复正常信令转发。

三、第二层防护:NAS层拥塞控制机制

3.1 NAS级拥塞控制的工作原理

当N2过载控制不足以缓解AMF压力时,AMF启用NAS层拥塞控制——直接在UE层面进行信令抑制。该机制定义在TS 24.501 Section 5.5中。

NAS拥塞控制的核心逻辑是:AMF在拒绝UE的NAS请求时,携带退避定时器(Back-off Timer),要求UE在指定时间窗口内不再发起同类请求。

sequenceDiagram
    participant UE
    participant gNB
    participant AMF

    UE->>gNB: RRC Connection Request
    gNB->>UE: RRC Connection Setup
    UE->>gNB: RRC Connection Setup Complete<br/>(NAS Registration Request)
    gNB->>AMF: NGAP Initial UE Message<br/>(NAS: Registration Request)

    Note over AMF: NAS拥塞状态<br/>拒绝非紧急注册

    AMF->>gNB: NGAP Downlink NAS Transport<br/>(NAS: Registration Reject)
    gNB->>UE: NAS Registration Reject<br/>5GMM Cause #22 (Congestion)<br/>T3346 = 300秒

    Note over UE: 启动T3346定时器<br/>300秒内不发起<br/>非紧急注册请求

    UE->>UE: T3346超时

    UE->>gNB: RRC Connection Request<br/>(重新尝试注册)
    gNB->>AMF: NGAP Initial UE Message<br/>(NAS: Registration Request)
    AMF->>gNB: NGAP Initial Context Setup Request<br/>(NAS: Registration Accept)

3.2 关键NAS退避定时器

NAS层拥塞控制涉及多个退避定时器,分别对应不同的NAS流程:

定时器 适用流程 携带消息 5GMM Cause 取值范围
T3346 注册/移动性管理 Registration Reject / Service Reject #22 (Congestion) 5秒~30分钟
T3525 PDU Session Establishment PDU Session Establishment Reject #27 (Missing or unknown DNN) / #67 (Insufficient resources) 5秒~30分钟
T3502 通用NAS退避 Configuration Update Command N/A(配置值) 1秒~3600秒
T3511 SMS over NAS 配置消息 N/A 5秒~45分钟

其中,T3346是最重要的拥塞退避定时器。值得注意的是:

3.3 NAS拥塞控制的5GMM Cause Code

AMF在拒绝NAS请求时携带的原因值(5GMM Cause Code)决定了UE的后续行为:

Cause Code 含义 UE行为
#22 (Congestion) 网络拥塞 UE启动T3346退避定时器,期间不发起注册
#27 (Missing or unknown DNN) DNN未知/缺失 UE启动T3525退避定时器,不重试该DNN
#67 (Insufficient resources) 资源不足 UE启动T3525退避定时器
#3 (Illegal UE) 非法UE UE停止所有NAS过程(非拥塞场景)
#11 (PLMN not allowed) PLMN不允许 UE将该PLMN加入禁止列表
#13 (Roaming not allowed in TA) TA区域不允许漫游 UE将该TA加入禁止列表

在拥塞场景中,AMF应使用Cause #22,这是标准的拥塞拒绝原因值。

3.4 NAS层的S-NSSAI感知拥塞控制

与N2层类似,NAS层也支持切片感知的拥塞控制。当AMF在Registration Reject或PDU Session Establishment Reject中携带Rejected NSSAI IE时,UE会针对被拒绝的S-NSSAI启动退避机制,而不影响其他切片的注册和使用。

Rejected NSSAI IE中可以包含: - 被拒绝的S-NSSAI值 - 拒绝原因值(如拥塞、不支持、未授权) - 退避定时器值(仅针对该S-NSSAI)

四、第三层防护:SBI过载控制机制

4.1 SBI过载控制的三种模式

5G核心网采用SBA(Service Based Architecture),AMF与其他NF(如UDM、SMF、PCF、NSSF)之间通过HTTP/2接口通信。当AMF过载时,它需要向调用其服务的NF消费者反馈过载信息。

TS 29.500 Section 6.4定义了三种SBI过载控制模式:

模式一:HTTP状态码反馈

HTTP状态码 含义 调用方行为
503 Service Unavailable 服务不可用(携带Retry-After头) 调用方等待Retry-After秒后重试
429 Too Many Requests 请求过于频繁 调用方降低请求速率
307 Temporary Redirect 临时重定向到其他AMF实例 调用方将请求重定向到目标AMF

模式二:OCI(Overload Control Information)Header

OCI是一种更精细的过载控制机制,通过HTTP响应头传递过载控制信息。OCI Header包含:

参数 说明
OCI-RI(Redirection Indicator) 指示是否需要将请求重定向到其他NF实例
OCI-RI-Target 重定向目标NF的URI
overload-pct 过载百分比(0-100),100表示完全过载
overload-info 过载原因和附加信息

模式三:NRF负载感知

AMF在向NRF注册时(Namf_Registration),可以更新自身的负载信息和容量。NRF在进行NF发现(Nnrf_NFDiscovery)时,会将负载因素纳入选择算法,将新请求引导到负载较轻的AMF实例。

flowchart TD
    subgraph NF消费者
        SMF["SMF"]
        UDM["UDM"]
        PCF["PCF"]
        AUSF["AUSF"]
    end

    subgraph SBI过载控制
        M1["模式一: HTTP状态码<br/>503 + Retry-After<br/>429 + 速率限制<br/>307 + 重定向"]
        M2["模式二: OCI Header<br/>overload-pct<br/>OCI-RI Target"]
        M3["模式三: NRF负载感知<br/>NF负载上报<br/>加权选择"]
    end

    subgraph AMF集群
        A1["AMF-1<br/>负载 92%"]
        A2["AMF-2<br/>负载 45%"]
        A3["AMF-3<br/>负载 38%"]
    end

    SMF & UDM & PCF & AUSF -->|"HTTP/2 请求"| M1 & M2
    M1 & M2 -->|"反馈过载"| SMF & UDM & PCF & AUSF
    M3 -->|"引导至轻载实例"| A2 & A3

4.2 AMF作为SBI消费者的过座行为

AMF不仅是SBI服务的提供者,也是其他NF服务的消费者(例如调用Nudm_SDM_Get获取用户签约数据、调用Nsmf_PDUSession_CreateSMContext建立PDU会话上下文)。当AMF调用其他NF时遇到过载响应,需要遵循以下策略:

五、AMF过载状态机

AMF内部维护一个过载状态机,驱动三层防护机制的协同工作:

stateDiagram-v2
    [*] --> Normal: 系统启动

    Normal --> Early_Warning: CPU>70% 或<br/>NAS连接数>80%阈值
    Early_Warning --> Normal: 负载回落
    Early_Warning --> Moderate_Overload: CPU>80% 或<br/>消息队列积压

    Moderate_Overload --> Early_Warning: 负载下降
    Moderate_Overload --> Severe_Overload: CPU>90% 或<br/>消息处理超时率>5%
    Moderate_Overload --> Normal: 负载恢复正常

    Severe_Overload --> Moderate_Overload: 负载缓解
    Severe_Overload --> Critical_Overload: CPU>95% 或<br/>系统濒临崩溃
    Severe_Overload --> Moderate_Overload: 部分恢复

    Critical_Overload --> Severe_Overload: 负载缓解

    state Early_Warning {
        [*] --> SBI_Throttle
        SBI_Throttle: SBI层: 上报NRF负载升高
        SBI_Throttle: N2层: 无动作
        SBI_Throttle: NAS层: 无动作
    }

    state Moderate_Overload {
        [*] --> N2_Throttle
        N2_Throttle: SBI层: 503+Retry-After
        N2_Throttle: N2层: Overload Start<br/>Response=reject-non-emergency<br/>Reduction=30%
        N2_Throttle: NAS层: 无直接动作
    }

    state Severe_Overload {
        [*] --> NAS_Congestion
        NAS_Congestion: SBI层: 503+OCI Header
        NAS_Congestion: N2层: Overload Start<br/>Response=allow-emergency-only<br/>Reduction=60%
        NAS_Congestion: NAS层: Registration Reject<br/>Cause#22 + T3346
    }

    state Critical_Overload {
        [*] --> Full_Protection
        Full_Protection: SBI层: 503 全部拒绝
        Full_Protection: N2层: Overload Start<br/>Response=reject-all<br/>Reduction=100%
        Full_Protection: NAS层: 全部拒绝<br/>仅保留紧急会话
    }

六、与4G MME过载控制的对比分析

维度 4G MME过载控制 5G AMF过载控制
RAN侧接口 S1AP Overload Start/Stop(TS 36.413) NGAP Overload Start/Stop(TS 38.413)
NAS退避定时器 T3346(EMM层) T3346/T3525(5GMM/5GSM层)
切片感知 ❌ 无(4G无切片概念) ✅ 支持S-NSSAI级过载控制
SBI过载控制 ❌ 无(4G使用Diameter/GTP-C) ✅ HTTP/2 503/429/307 + OCI Header
NF发现负载感知 DNS轮询(粗粒度) NRF加权选择(细粒度)
NWDAF集成 ❌ 无 ✅ NWDAF提供信令风暴预测(TS 23.288)
AMF Set/Pool MME Pool(SGSN Pool) AMF Set(支持更灵活的负载重分配)
退避粒度 PLMN级 PLMN + S-NSSAI + 接入类别级

5G相较4G最大的进步在于切片感知和NWDAF智能预测两个方面。NWDAF可以根据历史数据和实时分析,在信令风暴真正形成之前就通知AMF提前启动过载保护。

七、AMF Set场景下的过载控制

当部署AMF Set(多个AMF实例组成逻辑集合)时,过载控制策略需要全局协调:

场景:AMF Set内单实例过载

当AMF-1过载时,除了启动上述三层防护机制外,还应:

  1. 更新NRF注册信息:AMF-1在NRF中更新自身的负载状态和容量信息(TS 29.510)
  2. 触发N2重路由:gNB在后续的NGAP Initial UE Message中,NRF可以选择将新UE引导到AMF-2或AMF-3
  3. 利用AMF Set内的N1/N2接口转移:通过Namf_Communication_N1N2MessageTransfer服务,将部分UE的NAS信令转移到负载较轻的AMF实例
  4. 执行UE Configuration Update:触发UE重新注册到新AMF(TS 23.502 Section 4.2.2.2.3)
sequenceDiagram
    participant gNB
    participant NRF
    participant AMF1 as AMF-1<br/>(负载92%)
    participant AMF2 as AMF-2<br/>(负载45%)
    participant UDM

    AMF1->>NRF: Nnrf_NFUpdate<br/>负载=92%, 容量=低
    Note over NRF: 更新AMF-1负载信息

    gNB->>NRF: Nnrf_NFDiscovery<br/>查找可用AMF
    NRF->>gNB: 返回AMF-2(负载最优)

    gNB->>AMF2: NGAP Initial UE Message<br/>(新UE注册引导至AMF-2)

    Note over AMF1: 对已连接UE<br/>启动过载控制

    AMF1->>gNB: NGAP Overload Start<br/>Reduction=40%
    AMF1->>AMF1: 对部分已注册UE<br/>发起UE Configuration Update
    AMF1->>AMF2: Namf_Communication<br/>转移UE上下文

八、抓包识别AMF过载流程

8.1 关键抓包过滤条件

在实际网络运维中,使用Wireshark/TShark抓包识别AMF过载流程:

NGAP Overload Start/Stop消息过滤:

# 过滤NGAP Overload Start消息
tshark -i eth0 -f "tcp port 38412" \
  -Y "ngap.procedureCode == 17 && ngap.initiatingMessage"

# 过滤NGAP Overload Stop消息
tshark -i eth0 -f "tcp port 38412" \
  -Y "ngap.procedureCode == 18 && ngap.initiatingMessage"

NAS Registration Reject(拥塞原因)过滤:

# 过滤NAS Registration Reject Cause #22
tshark -i eth0 -f "tcp port 38412" \
  -Y "nas-5gs.regist.reject && nas-5gs.cause == 22"

SBI 503/429响应过滤:

# 过滤AMF返回的503/429响应
tshark -i eth0 -f "tcp port 8000" \
  -Y "http2.response.code == 503 || http2.response.code == 429"

8.2 常见故障点与排错思路

故障现象 可能原因 排错思路
大面积Registration Reject AMF过载导致N2+NAS双层拒绝 检查AMF CPU/内存,查看NGAP Overload Start是否发出
gNB未执行节流 gNB未正确处理Overload Start消息 抓包确认gNB收到Overload Start,检查gNB日志
UE退避后立即重试 T3346定时器值设置过短 检查Registration Reject中的T3346 IE值
过载恢复后仍被拒绝 Overload Stop未发送或未到达gNB 抓包确认Overload Stop是否发送并到达
仅特定切片用户被拒 AMF针对特定S-NSSAI施加过载控制 检查Overload Start NSSAI List内容
SBI调用持续失败 其他NF过载,AMF未正确处理503/429 检查AMF到其他NF的HTTP/2交互日志
## 九、NWDAF与AMF过载预测的联动(Rel-18/19增强)

3GPP从Rel-18开始,通过NWDAF(Network Data Analytics Function)为AMF过载控制引入了预测性保护能力。TS 23.288 Section 6.22定义了"Signalling Storm Analytics"功能:

这种从"被动过载保护"到"主动信令风暴预防"的演进,是5G Advanced阶段的核心网自优化能力之一。

十、完整信令流程示例:AMF从过载到恢复

下面展示一个完整的AMF过载控制生命周期,包含三层防护的协同工作:

sequenceDiagram
    participant UE1 as 普通UE
    participant UE2 as 紧急UE
    participant gNB
    participant AMF
    participant SMF
    participant UDM
    participant NRF

    Note over AMF: T0: 正常运行状态

    Note over AMF: T1: 大量IoT设备同时注册<br/>CPU升至85%

    rect rgb(255, 230, 230)
        Note over AMF: 第一阶段:SBI+轻微N2节流
        AMF->>NRF: Nnrf_NFUpdate(负载=85%)
        AMF->>gNB: NGAP Overload Start<br/>Response=reject-non-emergency<br/>Reduction=20%
    end

    Note over UE1: UE1发起注册
    UE1->>gNB: NAS Registration Request
    Note over gNB: gNB按20%比例随机丢弃
    gNB--xUE1: RRC Reject(被节流)

    Note over AMF: T2: 负载继续上升至92%

    rect rgb(255, 200, 200)
        Note over AMF: 第二阶段:加强N2节流+NAS拥塞
        AMF->>gNB: NGAP Overload Start<br/>Response=allow-emergency-high-priority<br/>Reduction=60%
    end

    UE1->>gNB: NAS Registration Request
    gNB->>AMF: NGAP Initial UE Message
    AMF->>gNB: NGAP DL NAS Transport
    gNB->>UE1: Registration Reject<br/>Cause #22, T3346=300s
    Note over UE1: 300秒内不再注册

    UE2->>gNB: NAS Registration Request<br/>(Emergency)
    gNB->>AMF: NGAP Initial UE Message<br/>(Emergency Registration)
    Note over AMF: 紧急注册不受过载控制
    AMF->>UDM: Nudm_SDM_Get
    UDM-->>AMF: 签约数据
    AMF->>gNB: Registration Accept

    Note over AMF: AMF调用SMF遭遇过载
    AMF->>SMF: Nsmf_PDUSession_CreateSMContext
    SMF-->>AMF: HTTP 503 + Retry-After:30
    Note over AMF: 30秒后重试SMF

    Note over AMF: T3: 负载下降至65%

    rect rgb(230, 255, 230)
        Note over AMF: 第三阶段:逐步恢复
        AMF->>gNB: NGAP Overload Start<br/>Response=reject-non-emergency<br/>Reduction=10%
    end

    Note over AMF: T4: 负载降至50%

    AMF->>gNB: NGAP Overload Stop
    AMF->>NRF: Nnrf_NFUpdate(负载=50%)
    Note over AMF,gNB: 恢复正常运行

常见问题

Q1: AMF的N2过载控制和NAS拥塞控制有什么区别?什么时候该用哪个?

A: N2过载控制(NGAP Overload Start/Stop)作用在AMF与gNB之间,gNB根据Overload Response动作和Traffic Load Reduction比例在RAN侧直接丢弃或拒绝信令,信令根本不会到达AMF。NAS拥塞控制则作用在AMF与UE之间,AMF收到NAS消息后返回拒绝响应并携带退避定时器,信令已经到达AMF但被拒绝处理。实际部署中两者配合使用:先用N2过载控制在RAN侧截流,仍到达AMF的过量信令再用NAS拥塞控制处理。

Q2: Traffic Load Reduction Indication值为0或100分别意味着什么?

A: 值为0表示gNB不需要减少任何信令流量(实际上等同于不发送Overload Start)。值为100表示gNB应当减少100%的指定类型信令,即完全停止转发该类信令。实际部署中,典型的取值范围是20%~80%,避免0和100的极端情况。

Q3: AMF过载时紧急呼叫是否受影响?

A: 不会。3GPP规范明确要求所有过载控制机制都必须豁免紧急业务。无论Overload Response取值为何,紧急注册和紧急呼叫始终不受限制。UE使用Access Identity 2标识紧急接入,gNB和AMF在过载控制中对该类接入不做限制。

Q4: Open5GS是否支持完整的AMF过载控制?

A: Open5GS目前(截至v2.7.x)提供了基础的NGAP Overload Start/Stop消息编解码框架(在ngap-build.c/ngap-handler.c中),但完整的过载检测(CPU/内存监控)、动态Traffic Load Reduction调整和NAS层拥塞控制(T3346分配)尚未完全实现。社区Discussion #3638中有相关实现讨论。

Q5: AMF Set内某个AMF过载时,如何将UE迁移到其他AMF?

A: 主要有三种方式:(1) AMF通过UE Configuration Update Procedure(TS 23.502 Section 4.2.4.2)通知UE重新注册,UE重新注册时由NRF引导到负载较轻的AMF;(2) AMF通过N1/N2接口转移机制将UE上下文迁移到目标AMF;(3) gNB后续的新UE连接通过NRF发现直接路由到负载较轻的AMF实例。

参考来源

  1. 3GPP TS 38.413 V19.0.0 — NGAP规范,Section 8.7.7 Overload Start/Stop消息定义
  2. 3GPP TS 23.501 Section 5.19.5.2 — 5G系统架构,AMF过载控制架构定义
  3. 3GPP TS 29.500 Section 6.4 — SBI技术实现,过载控制机制(HTTP状态码+OCI)
  4. Cisco UCC 5G AMF Overload Control for N2 and NAS — Cisco AMF过载控制配置指南
  5. 5G NGAP Overload Start Message — 3glteinfo.com — NGAP Overload Start消息IE详细解析

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

51学通信知识星球海报-扫码加入