<!-- title: 5G AMF过载控制三层防护机制拆解 -->
<!-- domain: core-network -->

# 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过载保护的完整闭环。

```mermaid
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拒绝新会话但允许移动性注册和紧急业务 |

```mermaid
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%的非紧急信令流量。

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

- **初始过载**：AMF先设置较低的Traffic Load Reduction（如20%），请求gNB适度减少流量
- **过载恶化**：如果过载未缓解，AMF逐步提高比例（40%→60%→80%）
- **极端过载**：配合更严格的Overload Response动作（如仅允许紧急和高优先级）
- **过载恢复**：逐步降低Traffic Load Reduction比例，最终发送Overload Stop

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

### 2.3 切片感知的过载控制（Slice-Aware Overload）

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

- **针对特定切片过载**：例如当eMBB切片用户激增时，仅对该切片施加过载控制，而URLLC切片不受影响
- **保护关键切片**：在过载时优先保障URLLC、V2X等关键切片的信令处理
- **差异化处理**：不同切片配置不同的Traffic Load Reduction比例

这一点在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在指定时间窗口内不再发起同类请求。

```mermaid
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**是最重要的拥塞退避定时器。值得注意的是：

- **T3346不阻止紧急注册**：UE始终可以发起紧急业务的注册请求
- **T3346不阻止高优先级接入**：Access Identity 1（运营商）和Access Identity 2（紧急）不受限
- **T3346按PLMN粒度管理**：UE在不同PLMN维护独立的T3346定时器
- **T3346在UE关机或拔出USIM后清除**：但小区重选不清除

### 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实例。

```mermaid
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时遇到过载响应，需要遵循以下策略：

- 收到**503 Service Unavailable**：AMF根据Retry-After头等待后重试，或选择备用NF实例
- 收到**429 Too Many Requests**：AMF降低对该NF的请求速率，可能触发NAS层向UE返回拥塞拒绝
- 收到**307 Temporary Redirect**：AMF将请求重定向到目标NF

## 五、AMF过载状态机

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

```text
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）

```mermaid
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消息过滤**：
```bash
# 过滤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（拥塞原因）过滤**：
```bash
# 过滤NAS Registration Reject Cause #22
tshark -i eth0 -f "tcp port 38412" \
  -Y "nas-5gs.regist.reject && nas-5gs.cause == 22"
```

**SBI 503/429响应过滤**：
```bash
# 过滤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"功能：

- **NWDAF分析维度**：基于NF异常信令、特定UE组、特定切片、特定优先级分析信令风暴风险
- **通知机制**：NWDAF通过Nnwdaf_AnalyticsSubscription服务向AMF推送分析结果
- **AMF响应**：AMF根据NWDAF分析结果**提前启动**过载控制，而非等到实际过载后被动响应

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

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

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

```mermaid
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](https://www.etsi.org/deliver/etsi_ts/138400_138499/138413/19.00.00_60/ts_138413v190000p.pdf) — NGAP规范，Section 8.7.7 Overload Start/Stop消息定义
2. [3GPP TS 23.501 Section 5.19.5.2](https://itecspec.com/3gpp/23.501/s/5.19.5.2) — 5G系统架构，AMF过载控制架构定义
3. [3GPP TS 29.500 Section 6.4](https://itecspec.com/3gpp/29.500/s/6.4) — SBI技术实现，过载控制机制（HTTP状态码+OCI）
4. [Cisco UCC 5G AMF Overload Control for N2 and NAS](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) — Cisco AMF过载控制配置指南
5. [5G NGAP Overload Start Message — 3glteinfo.com](https://www.3glteinfo.com/messages/5g/ngap/overload-start/) — 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学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)