<!-- title: 5G AMF过载控制N2节流与退避信令拆解 -->
<!-- domain: core-network -->

# 5G AMF过载控制：N2节流与NAS退避信令全链路拆解

## 1. 机制背景与设计动机

在5G核心网中，AMF（Access and Mobility Management Function）是所有UE接入的第一道关口——无论是注册、去注册、服务请求还是移动性更新，所有NAS信令都必须经过AMF处理。当大量UE同时发起信令请求（如突发事件导致mass event、IoT设备批量唤醒、灾难恢复后的re-attach风暴），AMF的CPU、内存和信令处理队列会在短时间内被压垮。

3GPP为此设计了一套**多层次协同的过载控制机制**，其核心思想是：**从源头压制信令流量，让拥塞在到达AMF之前就被网络边缘（RAN侧）消化**。这套机制分布在三个层次：

| 层次 | 接口 | 核心规范 | 机制 |
|------|------|----------|------|
| N2层过载控制 | AMF ↔ NG-RAN (N2/NGAP) | TS 38.413 Section 8.12/8.13 | Overload Start/Stop |
| NAS层拥塞控制 | AMF ↔ UE (N1/NAS) | TS 24.501 Section 5.3 | NAS Reject + Backoff Timer |
| AMF重平衡 | AMF Set ↔ NG-RAN | TS 23.501 Section 5.19.5.3 | AMF Weight Factor调整 |

本文聚焦于**N2层过载控制**的完整信令链路，同时分析其与NAS层退避机制的协同工作方式，涉及的3GPP规范包括：
- **TS 23.501 V18.x** Section 5.19.5.2（AMF Overload Control架构性描述）
- **TS 23.502 V18.x** Section 4.3.5（过载控制通用流程）
- **TS 38.413 V18.x** Section 8.12/8.13（NGAP Overload Start/Stop消息定义）
- **TS 24.501 V18.x** Section 5.3（NAS层拥塞处理）

---

## 2. AMF过载检测：从内部度量到阈值触发

AMF过载控制的起点是AMF自身的过载检测逻辑。3GPP并未标准化AMF内部的过载检测算法，这属于实现细节，但典型的检测维度包括：

```
AMF内部过载检测度量:
├── CPU利用率（per-AMF实例）
├── 内存使用率（UE Context数量 vs 容量上限）
├── NAS消息队列深度（待处理的Initial UE Message数量）
├── N2信令处理速率（NGAP消息/秒 vs 处理能力上限）
├── 数据库访问延迟（UDM/UDR查询响应时间）
└── 线程池/进程池饱和度
```

当上述任一度量超过配置的**过载阈值（Overload Threshold）**时，AMF触发过载控制流程。通常厂商实现中会设置**多级阈值**：

| 阈值级别 | 触发条件 | 典型动作 |
|----------|---------|---------|
| Level 1 (轻度) | CPU > 70% 或 NAS队列 > 50% | 启动N2 Overload Start（仅抑制非紧急信令连接） |
| Level 2 (中度) | CPU > 85% 或 NAS队列 > 75% | 升级Overload Response策略（仅允许紧急+MT+高优先级） |
| Level 3 (严重) | CPU > 95% 或 NAS队列 > 90% | 最严格策略 + NAS层Reject + T3346退避 |

---

## 3. N2过载控制信令流程全解

### 3.1 完整信令时序图

```mermaid
sequenceDiagram
    participant UE as UE
    participant gNB as gNB(NG-RAN)
    participant AMF as AMF
    participant PCF as PCF
    participant UDM as UDM

    Note over AMF: AMF检测到过载<br/>(CPU/内存/队列超阈值)

    rect rgb(255, 230, 230)
    Note over AMF,gNB: === 过载控制启动阶段 ===
    
    AMF->>gNB: NGAP OVERLOAD START<br/>+ Overload Response IE<br/>+ Traffic Load Reduction Indication
    Note right of AMF: 指示gNB执行流量抑制策略
    Note right of gNB: gNB根据Overload Response<br/>执行差异化流量控制
    end

    rect rgb(255, 255, 220)
    Note over UE,gNB: === 过载期间的信令处理 ===

    UE->>gNB: RRC Setup Request<br/>(非紧急MO信令)
    gNB-->>UE: RRC Reject<br/>+ waitTime
    Note right of gNB: 根据Overload Response<br/>拒绝非紧急MO信令

    UE->>gNB: RRC Setup Request<br/>(Emergency/High Priority)
    gNB->>AMF: NGAP Initial UE Message<br/>(允许紧急/高优先级通过)
    AMF->>gNB: NGAP Initial Context Setup Request
    gNB->>UE: RRC Reconfiguration
    Note right of gNB: 紧急呼叫和高优先级<br/>始终放行

    UE->>gNB: RRC Setup Request<br/>(普通MO Data)
    gNB-->>UE: RRC Reject<br/>+ waitTime
    Note right of gNB: 根据策略拒绝/延迟<br/>普通数据连接请求
    end

    rect rgb(220, 255, 220)
    Note over AMF,gNB: === NAS层协同退避 ===

    UE->>gNB: RRC Setup Request<br/>(MT Data - 被允许)
    gNB->>AMF: NGAP Initial UE Message<br/>(Service Request)
    AMF-->>UE: NAS Registration/Service Reject<br/>+ Cause: Congestion<br/>+ T3346 Backoff Timer
    Note right of AMF: AMF也通过NAS层<br/>直接拒绝部分请求
    end

    rect rgb(220, 220, 255)
    Note over AMF,gNB: === 过载恢复阶段 ===

    Note over AMF: AMF检测到负载降低<br/>低于恢复阈值

    AMF->>gNB: NGAP OVERLOAD STOP
    Note right of gNB: gNB恢复正常操作<br/>接受所有RRC连接请求

    UE->>gNB: RRC Setup Request<br/>(之前被拒绝的UE重试)
    gNB->>AMF: NGAP Initial UE Message
    Note right of gNB: 正常处理流程恢复
    end
```

### 3.2 NGAP OVERLOAD START消息深度解析

OVERLOAD START是AMF向NG-RAN节点发送的** unilateral通知消息**，不需要gNB回复确认。该消息通过N2接口（NGAP协议）传输，定义于TS 38.413 Section 8.12。

#### 消息结构（ASN.1抽象语法）

```
OVERLOAD START ::= SEQUENCE {
    protocolIEs    ProtocolIE-Container { {OverloadStartIEs} },
    ...
}

OverloadStartIEs NGAP-ELEMENTARY-PROCEDURE ::= {
    { ID id-OverloadResponse    CRITICALITY reject    TYPE OverloadResponse    PRESENCE mandatory } |
    { ID id-TrafficLoadReductionIndication   CRITICALITY ignore   TYPE TrafficLoadReductionIndication   PRESENCE optional } |
    { ID id-OverloadStartNSSAIList           CRITICALITY ignore   TYPE OverloadStartNSSAIList           PRESENCE optional },
    ...
}
```

#### 关键IE详解

**IE 1: Overload Response（必选）**

这是Overload Start消息中最核心的IE，定义了gNB应采取的过载响应动作类型：

| Overload Response选项 | 含义 | 典型场景 |
|----------------------|------|---------|
| **reject-all-signalling** | 拒绝所有新RRC信令连接建立请求（非紧急） | 极端过载 |
| **reject-non-emergency-mo-data** | 拒绝所有非紧急的MO数据传输RRC建立请求 | 中度过载 |
| **permit-emergency-and-mt-only** | 仅允许紧急会话和MT（Mobile Terminated）服务 | 重度过载 |
| **permit-emergency-mt-high-priority** | 允许紧急会话、MT服务和高优先级接入 | 轻/中度过载 |

**IE 2: Traffic Load Reduction Indication（可选）**

这是一个**百分比数值**（0~100），表示AMF希望gNB减少的流量比例。例如值为50时，gNB应拒绝约50%的受影响RRC连接请求。gNB的实现策略通常是：

```
gNB流量抑制实现逻辑（伪代码）:
if (random(0, 100) < trafficLoadReductionIndication) {
    reject RRC Connection Request;
    send RRC Reject with waitTime;
} else {
    allow RRC Connection Request;
    forward to AMF via NGAP Initial UE Message;
}
```

**IE 3: Overload Start NSSAI List（可选，Rel-16+）**

这是5G特有的增强，允许AMF按**网络切片（S-NSSAI）**进行差异化过载控制。AMF可以指定对特定切片的流量进行抑制，而不影响其他切片：

```
OverloadStartNSSAIList ::= SEQUENCE (SIZE(1..maxnoofSliceItems)) OF OverloadStartNSSAIItem

OverloadStartNSSAIItem ::= SEQUENCE {
    sliceOverloadResponse          SliceOverloadResponse,
    sliceTrafficLoadReductionIndication  SliceTrafficLoadReductionIndication OPTIONAL,
    s-NSSAI                         S-NSSAI
}
```

这意味着AMF可以对IoT切片实施严格的过载控制，同时保持eMBB切片的正常服务——这是5G相比4G（EPS MME过载控制）的重大架构优势。

### 3.3 NGAP OVERLOAD STOP消息

当AMF的负载降至恢复阈值以下时，AMF发送OVERLOAD STOP消息通知gNB恢复正常操作：

```
OVERLOAD STOP ::= SEQUENCE {
    protocolIEs    ProtocolIE-Container { {OverloadStopIEs} }
}
```

OVERLOAD STOP消息结构极其简单，**不包含任何必选IE**（仅可能的可选IE），因为它的语义就是"取消之前OVERLOAD START的所有约束"。gNB收到后立即恢复正常的RRC连接接纳逻辑。

### 3.4 gNB侧行为规范

根据TS 38.413 Section 8.12.2，gNB收到OVERLOAD START后必须遵循以下规则：

```mermaid
flowchart TD
    A[收到OVERLOAD START] --> B{解析Overload Response IE}
    B --> C[存储过载策略到gNB上下文]
    C --> D{收到RRC Connection Request}
    D --> E{检查UE Access Category<br/>和Access Identity}
    E --> F{UE是否属于<br/>豁免类别?}
    F -->|Emergency| G[允许RRC建立<br/>正常转发至AMF]
    F -->|High Priority AI 11-15| G
    F -->|MT Service<br/>寻呼响应| H{Overload Response<br/>是否允许MT?}
    H -->|permit-emergency-mt| G
    H -->|permit-emergency-mt-hp| G
    H -->|reject-all-signalling| I[拒绝RRC建立]
    F -->|普通MO信令/数据| J{应用Traffic Load<br/>Reduction概率}
    J -->|random < threshold| I
    J -->|random >= threshold| G
    I --> K[发送RRC Reject<br/>+ waitTime]

    L[收到OVERLOAD STOP] --> M[清除过载策略]
    M --> N[恢复正常RRC接纳逻辑]
```

**豁免规则**：无论Overload Response策略如何严格，以下类型的UE请求**始终豁免**：
- Access Identity 1（MPS/IMS语音紧急呼叫）
- Access Identity 2（MCS/关键任务服务）
- Access Category 0（紧急呼叫）
- Access Identity 11-15（运营商特定高优先级）

---

## 4. NAS层拥塞控制与T3346退避机制

### 4.1 NAS层与N2层的协同

AMF的过载控制不仅通过N2向RAN侧施加压力，同时也在**NAS层直接拒绝部分已到达AMF的信令请求**，形成"双层防线"：

```mermaid
flowchart TD
    subgraph 第一层防线
        A[gNB] -->|Overload Start| B[拒绝部分RRC请求<br/>源头压制]
    end

    subgraph 第二层防线
        C[AMF] -->|NAS Reject + T3346| D[已到达AMF的请求<br/>直接退避]
    end

    B -->|漏过的流量| C
    D --> E[UE进入退避状态<br/>不再发起请求]
```

### 4.2 NAS Reject消息中的关键参数

当AMF在过载状态下收到NAS消息并决定拒绝时，AMF在NAS Reject消息中携带以下关键IE：

| NAS Reject类型 | Cause Value | 携带的退避定时器 | 规范引用 |
|----------------|-------------|-----------------|---------|
| Registration Reject | #22 (Congestion) | T3346 (GPRS Timer 3) | TS 24.501 Section 5.3.2 |
| Service Reject | #22 (Congestion) | T3346 | TS 24.501 Section 5.3.3 |
| Deregistration Reject | #22 (Congestion) | T3346 | TS 24.501 Section 5.3.4 |
| 5GMM Status | #22 (Congestion) | — | TS 24.501 Section 5.3.5 |

**T3346（GPRS Timer 3）**的编码格式定义在TS 24.501 Section 9.11.2.5中：

```
GPRS Timer 3 IE结构:
┌────────────────────────────────────────┐
│  Bit 8  7  6  5  4  3  2  1           │
├────────────────────────────────────────┤
│ Byte 1: [Unit][Timer Value (5 bits)]   │
│   Unit: 00=2秒, 01=1分, 10=6分, 11=拒绝│
│   Timer Value: 0-31 (乘以Unit)         │
├────────────────────────────────────────┤
│ Byte 2: 扩展值 (如果使用扩展格式)      │
└────────────────────────────────────────┘

示例: Unit=01(1分钟), Value=30 → T3346=30分钟
```

### 4.3 UE收到T3346后的行为

UE收到携带T3346的NAS Reject后，执行以下动作：

1. **启动T3346定时器**，进入NAS-CONGESTION状态
2. 在T3346运行期间，**禁止发起**以下NAS过程：
   - Registration Request（紧急注册除外）
   - Service Request（紧急服务除外）
   - Mobility Registration Update
3. **仍允许**的NAS过程：
   - 紧急注册/紧急服务请求
   - 高优先级接入
   - Mobile Terminated请求的响应
4. T3346超时后，UE可以重新发起NAS请求
5. 如果UE在T3346运行期间收到**同PLMN的新T3346值**，替换当前值（取较小值）

---

## 5. 按切片差异化过载控制（Rel-16/18增强）

### 5.1 设计动机

5G网络切片引入了多样化的业务场景。一个典型的场景：智慧城市中百万级IoT传感器同时唤醒上报数据，导致AMF信令风暴。如果采用4G时代的"一刀切"过载控制（MME向所有eNB发送统一的Overload Response），将导致同一区域内的智能手机VoNR通话、URLLC工业控制等业务也被误杀。

Rel-16引入的**按切片过载控制**解决了这个问题：

```mermaid
flowchart TB
    subgraph AMF过载检测
        A[AMF检测到过载]
    end

    subgraph 切片级策略
        B[S-NSSAI: IoT切片<br/>Traffic Reduction: 80%<br/>Response: reject-all-signalling]
        C[S-NSSAI: eMBB切片<br/>Traffic Reduction: 20%<br/>Response: reject-non-emergency-mo-data]
        D[S-NSSAI: URLLC切片<br/>不包含在Overload Start中<br/>→ 不受影响]
    end

    A --> B
    A --> C
    A --> D

    subgraph gNB差异化执行
        E[IoT UE → 80%概率拒绝]
        F[eMBB UE → 20%概率拒绝]
        G[URLLC UE → 正常服务]
    end

    B --> E
    C --> F
    D --> G
```

### 5.2 gNB识别切片的方法

gNB通过以下信息关联UE请求与切片策略：

| 信息来源 | 说明 |
|---------|------|
| **UE的Requested NSSAI** | UE在RRC Setup Complete中携带的Requested NSSAI |
| **Allowed NSSAI** | gNB从AMF的NGAP消息（如Initial Context Setup）中获取的Allowed NSSAI |
| **缺省切片** | 如果UE尚未建立PDU Session，gNB使用UE的Subscribed S-NSSAI匹配 |

---

## 6. 与4G MME过载控制的对比

| 对比维度 | 4G MME过载控制 | 5G AMF过载控制 |
|---------|---------------|---------------|
| **接口** | S1AP (S1-MME) | NGAP (N2) |
| **消息名** | OVERLOAD START/STOP | OVERLOAD START/STOP（名称相同） |
| **Overload Response选项** | 4种（与5G基本相同） | 4种（继承4G） + 按切片扩展 |
| **Traffic Reduction** | S1AP有Traffic Load Reduction Indication | NGAP有Traffic Load Reduction Indication |
| **切片级控制** | 不支持（EPS无切片概念） | **支持**（Overload Start NSSAI List） |
| **NAS退避定时器** | T3446（EMM Backoff Timer） | T3346（5GMM Backoff Timer） |
| **AMF Set Load Rebalance** | MME Pool内负载重分配 | AMF Set内Weight Factor调整 |
| **Nssf协助** | 不涉及 | 可通过Nssf进行切片级AMF选择优化 |

---

## 7. AMF Set负载重平衡（关联机制）

当AMF Set内某个AMF过载时，除了触发N2 Overload Start外，还有一个**负载重平衡机制**定义在TS 23.501 Section 5.19.5.3：

1. 过载AMF通过**AMF Configuration Update**消息修改NGAP中的**AMF Weight Factor**
2. Weight Factor降低意味着gNB在选择AMF时分配更少的UE给该AMF
3. 新的Initial Registration请求会被gNB通过AMF Set内的其他AMF处理
4. 已注册的UE可以通过**Configuration Update Command**触发重注册到负载较轻的AMF

```mermaid
flowchart LR
    subgraph AMF Set
        A1[AMF-1<br/>Weight: 0.1<br/>过载]
        A2[AMF-2<br/>Weight: 0.5<br/>正常]
        A3[AMF-3<br/>Weight: 0.4<br/>正常]
    end

    subgraph gNB
        G1[新UE接入]
    end

    G1 -->|10%概率| A1
    G1 -->|50%概率| A2
    G1 -->|40%概率| A3

    A1 -.->|Overload Start| G1
    A1 -.->|Config Update<br/>Weight: 0→0.1| G1
```

---

## 8. 抓包识别与故障排查

### 8.1 抓包识别方法

**在N2接口（NGAP层）识别过载控制**：

```bash
# Wireshark/tshark过滤NGAP Overload Start
ngap.procedureCode == 17

# 过滤Overload Stop
ngap.procedureCode == 18

# 过滤携带T3346的NAS Reject
nas_5gs.message_type == 0x44 && nas_5gs.cause == 22
```

**Overload Start消息在Wireshark中的典型呈现**：

```
NGAP Overload Start
├── AMF Overload Response
│   └── reject-non-emergency-mo-data (1)
├── Traffic Load Reduction Indication
│   └── 50 (即50%流量抑制)
└── Overload Start NSSAI List (如果存在)
    ├── Item 1:
    │   ├── S-NSSAI: SST=1, SD=010203
    │   ├── Slice Overload Response: reject-all-signalling
    │   └── Slice Traffic Load Reduction: 80
    └── Item 2:
        ├── S-NSSAI: SST=2, SD=040506
        ├── Slice Overload Response: reject-non-emergency-mo-data
        └── Slice Traffic Load Reduction: 30
```

### 8.2 常见故障场景

| 故障现象 | 可能原因 | 排查步骤 |
|---------|---------|---------|
| 大量UE Registration Reject (Cause 22) | AMF过载触发NAS拥塞控制 | 检查AMF CPU/内存指标；查看NGAP Overload Start是否发出 |
| gNB不执行流量抑制 | Overload Start未到达gNB或gNB实现缺陷 | 抓N2接口确认Overload Start是否发送；检查gNB日志中的Overload处理 |
| UE退避时间过长 | T3346配置值过大 | 检查AMF的T3346配置策略；确认是否符合运营商策略 |
| 过载恢复后仍被拒绝 | AMF未发送Overload Stop | 检查AMF恢复阈值配置；确认Overload Stop是否发送 |
| 特定切片UE全部被拒 | Overload Start NSSAI List配置错误 | 检查切片级Traffic Reduction值是否合理 |
| AMF过载但gNB未感知 | Overload Start消息丢失 | 检查SCTP连接状态；确认N2链路是否正常 |
## 9. 过载控制状态机

从AMF视角，过载控制的状态转换如下：

```text
stateDiagram-v2
    [*] --> Normal: AMF启动
    Normal --> Overload_Level1: 度量超过阈值L1
    Normal --> Overload_Level2: 度量超过阈值L2
    Normal --> Overload_Level3: 度量超过阈值L3
    
    Overload_Level1 --> Overload_Level2: 度量恶化超L2阈值
    Overload_Level1 --> Normal: 度量低于恢复阈值<br/>发送OVERLOAD STOP
    Overload_Level2 --> Overload_Level3: 度量恶化超L3阈值
    Overload_Level2 --> Overload_Level1: 度量改善至L1范围
    Overload_Level3 --> Overload_Level2: 度量改善至L2范围
    
    Overload_Level1: 轻度过载<br/>N2 Overload Start<br/>Response: permit-emergency-mt-hp
    Overload_Level2: 中度过载<br/>升级Overload Response<br/>+ NAS Reject部分请求
    Overload_Level3: 严重过载<br/>最严格Response<br/>+ 全量NAS Reject + T3346
    Normal: 正常运行<br/>无过载控制约束
    
    note right of Overload_Level1
        发送NGAP OVERLOAD START
        Traffic Reduction: 20-40%
    end note
    
    note right of Overload_Level3
        发送升级的OVERLOAD START
        Traffic Reduction: 60-100%
        可能触发AMF重平衡
    end note
```

---

## 10. 完整信息元素参考表

### NGAP OVERLOAD START消息IE汇总

| IE名称 | IE ID | 必选/可选 | 类型 | 说明 |
|--------|-------|----------|------|------|
| Overload Response | 50 | **M** | CHOICE | 指定gNB的过载响应策略（4种选项） |
| Traffic Load Reduction Indication | 56 | O | INTEGER(0..100) | 流量抑制百分比 |
| Overload Start NSSAI List | 182 | O | SEQUENCE OF | 按切片的过载策略列表（Rel-16+） |

### NGAP OVERLOAD STOP消息IE汇总

| IE名称 | IE ID | 必选/可选 | 类型 | 说明 |
|--------|-------|----------|------|------|
| （无必选IE） | — | — | — | 仅通知gNB停止过载控制 |

### NAS Reject中的关键IE

| IE名称 | 参考章节 | 说明 |
|--------|---------|------|
| 5GMM Cause | TS 24.501 Section 9.11.3.2 | 值22表示Congestion |
| T3346 Value (GPRS Timer 3) | TS 24.501 Section 9.11.2.5 | 退避定时器，编码格式见上文 |
| EAP Message | TS 24.501 Section 9.11.2.2 | 如果使用EAP-AKA'鉴权时的拒绝消息 |

---

## 常见问题

**Q1: OVERLOAD START消息为什么不需要gNB回复确认？**
A: 这是3GPP的设计哲学——过载控制场景下，AMF的信令处理能力已经严重不足，要求gNB回复确认只会增加额外的信令负担。AMF采用"best effort"通知模式，发送后即假设gNB会执行。如果SCTP链路正常，消息可靠传输由SCTP层保证。

**Q2: Traffic Load Reduction Indication的百分比值是精确的还是近似的？**
A: 是**近似指导值**。3GPP TS 38.413明确规定gNB的实现是厂商特定的——gNB只需要"尽力"达到指定的流量抑制比例。实际抑制效果取决于gNB的具体算法（随机丢弃、令牌桶、per-UE计数器等）。

**Q3: 如果AMF在Overload Start之后崩溃重启，gNB会一直处于过载抑制状态吗？**
A: 不会。当AMF崩溃后SCTP关联断开，gNB检测到SCTP连接失败后会清除与该AMF关联的所有状态，包括过载控制状态。当AMF重新建立SCTP连接时，默认是Normal状态，不会自动发送Overload Start。

**Q4: N2过载控制和NAS拥塞控制可以同时激活吗？**
A: 可以，而且这是**推荐的组合策略**。N2过载控制在RAN侧从源头压制流量（第一道防线），NAS拥塞控制在AMF侧处理漏过的流量（第二道防线）。两者的粒度不同：N2控制是基于整个AMF或切片的粗粒度控制，NAS控制可以基于DNN/S-NSSAI/UE group等细粒度控制。

**Q5: 按切片的过载控制中，gNB如何在RRC阶段就识别UE的切片？**
A: 这是一个实际挑战。在Initial Registration阶段，UE尚未建立PDU Session，gNB只能依赖UE在RRC Setup Complete中携带的**Requested NSSAI**来推断切片归属。如果UE未携带Requested NSSAI，gNB可能无法在RRC阶段执行精确的切片级过载控制。这是3GPP规范中一个已知的实现灵活性区域。

---

## 参考来源

1. [3GPP TS 38.413 V18.6.0 — NG-RAN; NG Application Protocol (NGAP)](https://www.3gpp.org/DynaReport/38413.htm) — Section 8.12 Overload Start, Section 8.13 Overload Stop, Section 9.2.1.34 Overload Response IE
2. [3GPP TS 23.501 V18.x — 5G System Architecture](https://www.3gpp.org/DynaReport/23501.htm) — Section 5.19.5.2 AMF Overload Control, Section 5.19.5.3 AMF Load Rebalancing
3. [3GPP TS 24.501 V18.x — NAS for 5GS](https://www.3gpp.org/DynaReport/24501.htm) — Section 5.3 NAS Congestion Control, Section 9.11.2.5 GPRS Timer 3
4. [Cisco Ultra Cloud Core 5G AMF Overload Control Guide](https://www.cisco.com/c/en/us/td/docs/wireless/ucc/amf/2025-01/config-and-admin/b_ucc-5g-amf-config-and-admin-guide_2025-01/m_overload-control-n2-nas.html) — N2和NAS过载控制配置与行为说明
5. [3GLTEInfo — 5G NGAP Overload Start Message](https://www.3glteinfo.com/messages/5g/ngap/overload-start/) — NGAP消息结构与IE参考
6. [IEEE — Congestion Control by Mobile Core and RAN Coordination in 5G](https://ieeexplore.ieee.org/document/10199592) — 核心网与RAN协同拥塞控制学术分析

---
> 本文由「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学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)