<!-- title: 5G N2切换信令流全链拆解 -->
<!-- domain: core-network -->

# 5G N2切换（NG Handover）完整信令流深度拆解

## 一、N2切换概述与触发场景

### 1.1 什么是N2切换

5G系统中，当UE在不同gNB之间移动时，需要执行切换（Handover）以保持业务连续性。根据信令路径不同，切换分为两种：

- **Xn切换**：源gNB与目标gNB之间存在Xn接口，切换信令直接在gNB之间交互，延迟低
- **N2切换（NG Handover）**：源gNB与目标gNB之间不存在Xn接口（或Xn切换失败），切换信令需经由AMF中转，走N2/NG-C接口

**N2切换是"兜底"的切换方式**——当Xn不可用时，核心网必须介入协调切换过程。根据TS 23.502 Section 4.9.1.3.1的定义，N2切换的典型触发场景包括：

1. 源gNB与目标gNB之间无Xn连接（不同厂商设备、不同MEC区域）
2. Xn切换失败后回退（如目标gNB返回错误指示，表明与源UPF无IP连通性）
3. 源RAN基于动态信息决定走N2路径
4. Inter-PLMN切换（跨运营商）
5. 卫星NTN场景中跨国家的切换

### 1.2 N2切换与Xn切换的核心差异

| 对比维度 | N2切换 | Xn切换 |
|---------|--------|--------|
| **信令路径** | S-gNB → AMF → T-gNB（核心网中转） | S-gNB → T-gNB（直连） |
| **控制面延迟** | 约20-40ms（增加AMF跳转） | 约5-15ms |
| **路径切换触发** | AMF收到Handover Notify后触发SMF | 目标gNB发起Path Switch Request |
| **数据转发** | 通常间接转发（经UPF） | 可直接转发（Xn-U） |
| **SN Status Transfer** | 经AMF中转（Uplink/Downlink RAN Status Transfer） | 直接Xn接口传递 |
| **适用场景** | 无Xn、跨厂商、跨PLMN | 同区域、Xn可达 |
| **规范章节** | TS 23.502 §4.9.1.3 | TS 23.502 §4.9.1.2 |

## 二、N2切换完整信令时序图

N2切换分为两个主要阶段：**准备阶段（Preparation Phase）** 和 **执行阶段（Execution Phase）**。以下是基于TS 23.502 Figure 4.9.1.3.2-1和Figure 4.9.1.3.3-1的完整信令流。

### 2.1 准备阶段信令时序图

```mermaid
sequenceDiagram
    participant UE
    participant S-RAN as 源gNB(S-RAN)
    participant S-AMF as 源AMF(S-AMF)
    participant T-AMF as 目标AMF(T-AMF)
    participant SMF
    participant UPF_PSA as UPF(PSA)
    participant T-UPF as T-UPF(中间)
    participant T-RAN as 目标gNB(T-RAN)

    Note over UE,T-RAN: 准备阶段 (Preparation Phase)
    
    UE->>S-RAN: Measurement Report
    S-RAN->>S-AMF: 1. Handover Required<br/>(Target ID, Source→Target Container,<br/>PDU Session IDs, SM N2 Info)
    
    Note over S-AMF,T-AMF: 2. [条件] AMF重选<br/>S-AMF选择T-AMF
    S-AMF->>T-AMF: 3. [条件] Namf_Communication_CreateUEContext<br/>(SUPI, N2 Info, UE Context)
    
    T-AMF->>SMF: 4. Nsmf_PDUSession_UpdateSMContext<br/>(PDU Session ID, Target ID, N2 SM Info)
    
    Note over SMF,T-UPF: 5. SMF检查UPF服务区<br/>选择新中间UPF
    SMF->>UPF_PSA: 6a. [条件] N4 Session Modification Request
    UPF_PSA-->>SMF: 6b. N4 Session Modification Response<br/>(CN Tunnel Info on N9)
    SMF->>T-UPF: 6c. [条件] N4 Session Establishment Request
    T-UPF-->>SMF: 6d. N4 Session Establishment Response<br/>(DL/UL CN Tunnel Info)
    
    SMF-->>T-AMF: 7. Nsmf_PDUSession_UpdateSMContext Response<br/>(N2 SM Info, N3 UP Address)
    
    Note over T-AMF: 8. AMF等待所有SMF响应<br/>或最大等待时间超时
    
    T-AMF->>T-RAN: 9. Handover Request<br/>(Source→Target Container,<br/>N2 SM Info, Security Context)
    T-RAN-->>T-AMF: 10. Handover Request Acknowledge<br/>(Target→Source Container,<br/>PDU Session List, N3 Tunnel Info)
    
    T-AMF->>SMF: 11a. Nsmf_PDUSession_UpdateSMContext Request<br/>(N2 SM Response from T-RAN)
    SMF->>T-UPF: 11b. [条件] N4 Session Modification Request<br/>(T-RAN N3 Forwarding Info)
    T-UPF-->>SMF: 11c. N4 Session Modification Response
    SMF->>UPF_PSA: 11d. [条件] N4 Modification(Forwarding Info)
    UPF_PSA-->>SMF: 11e. N4 Modification Response
    SMF-->>T-AMF: 11f. Nsmf_PDUSession_UpdateSMContext Response<br/>(N2 SM Info with DL Forwarding Tunnel)
    
    T-AMF-->>S-AMF: 12. [条件] Namf_Communication_CreateUEContext Response<br/>(Target→Source Container, N2 SM Info)
```

### 2.2 执行阶段信令时序图

```mermaid
sequenceDiagram
    participant UE
    participant S-RAN as 源gNB(S-RAN)
    participant S-AMF as 源AMF(S-AMF)
    participant T-AMF as 目标AMF(T-AMF)
    participant SMF
    participant UPF_PSA as UPF(PSA)
    participant S-UPF as S-UPF(中间)
    participant T-UPF as T-UPF(中间)
    participant T-RAN as 目标gNB(T-RAN)

    Note over UE,T-RAN: 执行阶段 (Execution Phase)
    
    S-AMF->>S-RAN: 1. Handover Command<br/>(Target→Source Container, PDU Session List)
    S-RAN->>UE: 2. RRC Reconfiguration<br/>(UE Container from T-RAN)
    
    S-RAN->>S-AMF: 2a. Uplink RAN Status Transfer<br/>(PDCP SN/HFN per DRB)
    S-AMF->>T-AMF: 2b. [条件] Namf_N1N2MessageTransfer<br/>(RAN Status Transfer)
    T-AMF->>T-RAN: 2c. Downlink RAN Status Transfer
    
    Note over S-RAN,T-RAN: 3. 数据转发阶段
    Note over S-RAN,T-RAN: 3a. 直接转发(如果可用)
    Note over S-RAN,T-UPF: 3b. 间接转发(经UPF)
    
    UE->>T-RAN: 4. Handover Confirm<br/>(随机接入成功)
    T-RAN->>T-AMF: 5. Handover Notify<br/>(User Location Info)
    
    T-AMF->>S-AMF: 6a. [条件] Namf_Communication_N2InfoNotify
    S-AMF-->>T-AMF: 6b. [条件] N2InfoNotify ACK
    S-AMF->>SMF: 6c. [条件] Nsmf_PDUSession_ReleaseSMContext<br/>(非接受PDU Session释放)
    
    T-AMF->>SMF: 7. Nsmf_PDUSession_UpdateSMContext Request<br/>(Handover Complete Indication)
    
    SMF->>T-UPF: 8a. [条件] N4 Modification(DL AN Tunnel Info)
    T-UPF-->>SMF: 8b. N4 Modification Response
    SMF->>S-UPF: 9a. [条件] N4 Modification(DL AN Tunnel Info)
    S-UPF-->>SMF: 9b. N4 Modification Response
    
    SMF->>UPF_PSA: 10a. N4 Modification Request<br/>(N3 AN Tunnel Info of T-RAN)
    Note over UPF_PSA: UPF(PSA)切换下行路径<br/>发送End Marker
    UPF_PSA-->>SMF: 10b. N4 Modification Response
    Note over UPF_PSA,T-RAN: UPF(PSA)开始向T-RAN<br/>发送下行数据
    
    SMF-->>T-AMF: 11. Nsmf_PDUSession_UpdateSMContext Response
    
    Note over UE,T-AMF: 12. UE发起移动性注册更新<br/>(Registration procedure子集)
    
    Note over SMF,S-UPF: 定时器超时后
    SMF->>S-UPF: 13a. N4 Session Release Request
    S-UPF-->>SMF: 13b. N4 Session Release Response
    
    S-AMF->>S-RAN: 14a. UE Context Release Command
    S-RAN-->>S-AMF: 14b. UE Context Release Complete
```

## 三、关键信令消息IE深度解析

### 3.1 HANDOVER REQUIRED（源gNB → AMF）

这是N2切换的起始消息，由TS 38.413 Section 8.4.1定义。源gNB检测到UE的测量报告满足切换条件且Xn不可用时发起。

**关键IE结构：**

```
HANDOVER REQUIRED
├── Source NG-RAN Node UE NGAP ID     -- 源侧UE标识
├── AMF UE NGAP ID                    -- AMF侧UE标识
├── Reason                            -- 切换原因值
│   └── ho-to-5GC / inter-gNB-N2
├── Target ID                         -- 目标gNB标识
│   ├── Target RAN Node ID           -- Global RAN Node ID
│   └── TAC                          -- 目标跟踪区编码
├── Source to Target Transparent Container  -- 源到目标透明容器
│   ├── UE History Information       -- UE历史驻留小区列表
│   ├── UE Radio Capability          -- UE无线能力
│   ├── PDU Session Resource Info    -- 各PDU Session的QoS Flow/DRB信息
│   ├── DL Forwarding Proposed       -- 下行转发提议(每QoS Flow)
│   ├── UL Forwarding Proposed       -- 上行转发提议(每QoS Flow)
│   └── DRBs to QoS Flows Mapping    -- DRB与QoS Flow映射关系
├── PDU Session Resource List         -- PDU Session资源列表
│   └── Per PDU Session:
│       ├── PDU Session ID
│       ├── Handover Required Transfer IE  -- 透传给SMF
│       └── SM N2 Info
├── Direct Forwarding Path Availability -- 直接转发路径可用性指示
└── DAPS Request Information           -- [R18] DAPS切换请求
```

**设计意图**：Source to Target Transparent Container是整个切换过程中最关键的IE之一。它由源RAN创建，核心网完全透明传输，目标RAN据此准备无线资源配置。这种"透明容器"设计将无线侧细节与核心网解耦——核心网不需要理解RRC配置，只负责路由转发。

### 3.2 HANDOVER REQUEST（AMF → 目标gNB）

由TS 38.413 Section 8.4.2定义，AMF向目标gNB请求预留无线和传输资源。

**关键IE参数说明：**

| IE名称 | 必选/可选 | 说明 |
|--------|---------|------|
| AMF UE NGAP ID | M | AMF分配的UE标识 |
| Handover Type | M | 切换类型：intra5GC / inter5GC |
| Source to Target Transparent Container | M | 从Step 1透传 |
| UE Security Capabilities | M | NR加密/完整性保护算法能力 |
| Security Context | M | KgNB或目标gNB密钥 |
| UE Aggregate Maximum Bit Rate | M | UE-AMBR |
| PDU Session Resource Setup List | M | 各PDU Session资源建立请求 |
| ↪ PDU Session ID | M | PDU Session标识 |
| ↪ QoS Flow Setup Request List | M | QFI + QoS参数(5QI, ARP, GBR/MBR) |
| ↪ UL/DL TEID | M | UPF侧N3隧道端点 |
| ↪ S-NSSAI | M | 网络切片标识 |
| Allowed NSSAI | M | UE允许的S-NSSAI列表 |
| Mobility Restriction List | O | 禁止区域、RAT限制 |
| Masked IMEISV | O | 设备标识 |
| UE Radio Capability ID | O | [R18] RACS能力ID |
| UE History Information | M | UE最近驻留的小区列表 |
| Trace Activation | O | 跟踪需求 |
| PDU Set QoS Parameters | O | [R18] PDU Set级QoS参数 |

**目标gNB处理逻辑**（TS 38.413 §8.4.2.2）：

收到HANDOVER REQUEST后，目标gNB需要执行以下操作：

1. 尝试执行请求的PDU Session配置和关联安全配置
2. 存储UE-AMBR用于所有Non-GBR QoS Flow
3. 存储Mobility Restriction List到UE上下文
4. 存储Security Context并按TS 33.501使用
5. 收集UE History Information中的必选信息
6. 为每个PDU Session预留C-RNTI、配置DRB/SRB
7. 建立GTP-U隧道（每个PDU Session的QoS Flow）
8. 准备RRC Reconfiguration消息（嵌入Target to Source Container）

### 3.3 HANDOVER REQUEST ACKNOWLEDGE（目标gNB → AMF）

目标gNB资源预留成功后返回，这是切换准备阶段最关键的响应消息。

```mermaid
graph TD
    A[HANDOVER REQUEST ACKNOWLEDGE] --> B[AMF UE NGAP ID]
    A --> C[Target to Source Transparent Container]
    A --> D[PDU Session Resource Admitted List]
    A --> E[PDU Session Resource Failed List]

    C --> C1[UE Container<br/>AS part + NAS part]
    C1 --> C2[RRC Reconfiguration<br/>目标小区配置]
    C1 --> C3[New C-RNTI]
    C1 --> C4[Security Algorithm Config]
    C1 --> C5[Random Access Parameters]
    C --> C6[DAPS Response Info<br/>R18可选]

    D --> D1[PDU Session ID]
    D1 --> D2[Handover Request Acknowledge Transfer IE]
    D2 --> D3[QoS Flow Setup Response List<br/>已接纳QoS Flow]
    D2 --> D4[UL/DL Forwarding UP TNL Info<br/>数据转发隧道]
    D2 --> D5[UP Transport Layer Info<br/>N3隧道端点]
    D2 --> D6[Security Result<br/>加密/完整性保护结果]

    E --> E1[PDU Session ID]
    E1 --> E2[Failure Cause<br/>e.g. S-NSSAI不可用]
```

**关键设计点**：

- **Target to Source Transparent Container**包含目标RAN为UE准备的RRC Reconfiguration消息。这个容器从目标gNB透传至源gNB，源gNB不做任何修改直接通过空口发送给UE
- **数据转发隧道信息**：目标gNB为需要数据转发的QoS Flow/DRB提供DL/UL Forwarding UP TNL Information
- **失败处理**：如果某些PDU Session无法建立，目标gNB在Failed List中说明原因，SMF据此决定是释放PDU Session还是去激活UP连接

### 3.4 SN Status Transfer机制

在N2切换中，SN（Sequence Number）状态传递必须经由AMF中转，这是与Xn切换的重要区别。在Xn切换中，SN Status Transfer直接在gNB间传递。

**流程（TS 23.502 §4.9.1.3.3 Step 2a-2c）：**

1. **Uplink RAN Status Transfer**：源gNB → 源AMF，携带每个DRB的PDCP SN和HFN
2. **Namf_Communication_N1N2MessageTransfer**（AMF变更时）：源AMF → 目标AMF
3. **Downlink RAN Status Transfer**：目标AMF → 目标gNB

**SN Status Transfer IE内容**：

| 字段 | 说明 |
|------|------|
| DRB ID | 数据无线承载标识 |
| UL COUNT Value | 上行PDCP计数值（SN + HFN） |
| DL COUNT value | 下行PDCP计数值 |
| UL Reception Status | 上行接收状态（位图） |
| DL Delivery Status | 下行投递状态 |

**设计意图**：SN Status Transfer确保目标gNB能够从源gNB中断的位置继续PDCP数据的收发，避免数据重复或丢失。源gNB可以省略发送此消息（如果不需要对UE的任何无线承载进行PDCP状态保持）。

## 四、UPF重定位与数据转发路径

### 4.1 UPF服务区判断与重选

N2切换准备阶段，SMF收到Nsmf_PDUSession_UpdateSMContext后，必须判断目标gNB是否仍在当前UPF的服务区内（TS 23.502 §4.9.1.3.2 Step 5）：

```mermaid
flowchart TD
    A[SMF收到UpdateSMContext] --> B{Target ID在UPF服务区内?}
    B -->|是| C[保持当前UPF<br/>直接提供N3隧道信息]
    B -->|否| D{存在可用I-UPF?}
    D -->|是| E[选择新T-UPF<br/>N4 Session Establishment]
    E --> F[更新UPF PSA的N9隧道]
    F --> G[建立新N3/N9路径]
    D -->|否| H[不提供N2 SM Info<br/>PDU Session不切换]
    H --> I{本地策略}
    I --> J[触发PDU Session重建立]
    I --> K[保持PDU Session<br/>UP连接去激活]
    I --> L[释放PDU Session]
```

### 4.2 直接转发 vs 间接转发

数据转发机制的选择是N2切换中的关键决策点：

| 转发类型 | 路径 | 条件 | 延迟 |
|---------|------|------|------|
| **直接转发** | S-RAN → T-RAN | S-RAN与T-RAN之间有IP连通性且安全关联就绪 | 低（1-3ms） |
| **间接转发** | S-RAN → S-UPF → T-UPF → T-RAN | 无直接IP连通性 | 较高（5-15ms） |

根据TS 23.502 §4.9.1.3.1，直接转发路径可用性由源RAN判断并通过HANDOVER REQUIRED消息中的**Direct Forwarding Path Availability IE**指示给SMF。SMF根据此指示决定转发类型。

**间接转发隧道的建立过程**（TS 23.502 §4.9.1.3.2 Step 11b-11e）：

1. SMF向T-UPF提供T-RAN的N3转发信息，请求分配DL转发隧道
2. T-UPF返回转发隧道端点（T-UPF N3地址 + Tunnel ID）
3. SMF将T-UPF（或T-RAN）的转发信息提供给S-UPF
4. S-UPF分配自身的转发隧道端点并返回给SMF
5. SMF通过N2 SM Info将最终转发路径信息经AMF发送给源gNB

### 4.3 End Marker机制

路径切换完成后（Step 10a-10b），UPF（PSA）在旧路径上发送一个或多个**End Marker**包，然后在新路径上开始发送下行数据。源gNB收到End Marker后将其转发给目标gNB，目标gNB据此判断旧路径数据已全部到达，可以开始按序向上层递交数据。

**End Marker处理关键规则**：
- 当存在多个UPF(PSA)时（如UL CL/BP场景），SMF只指示其中一个PSA发送End Marker
- SMF应先修改其他PSA的路径，再指示发送End Marker，确保End Marker是旧路径上最后一个用户面数据包

## 五、AMF变更场景处理

### 5.1 AMF重选条件

当S-AMF无法继续服务UE时（例如UE移出了S-AMF的服务区域），触发AMF重选。S-AMF根据TS 23.501 §6.3.5的AMF选择功能选择T-AMF。

**AMF变更时的关键信令**：

```
S-AMF → T-AMF: Namf_Communication_CreateUEContext Request
  ├── SUPI
  ├── N2 Information (Target ID, Source→Target Container, SM N2 Info)
  ├── UE Context (Service Area Restriction, Allowed NSSAI, S-NSSAI)
  ├── PDU Session ID + SMF Info + S-NSSAI
  ├── PCF ID(s)
  ├── UE Radio Capability ID / Info
  ├── N2 Notify URI (S-AMF的Notify地址)
  └── NWDAF Analytics Subscriptions

T-AMF → S-AMF: Namf_Communication_CreateUEContext Response
  ├── Target→Source Transparent Container
  ├── PDU Sessions Failed to Setup List
  ├── N2 SM Information (N3 DL Forwarding Info)
  ├── PCF ID / PCF Reselect Indication
  └── Target AMF ID
```

### 5.2 AMF不变场景简化

当S-AMF仍能服务UE时（Step 3和Step 12不执行），整个流程简化为：
- S-AMF直接与SMF交互
- S-AMF直接向目标gNB发送HANDOVER REQUEST
- 无需Namf_Communication_CreateUEContext

## 六、PDU Session切换状态机

每个PDU Session在N2切换过程中独立处理，存在以下状态转换：

```mermaid
stateDiagram-v2
    [*] --> Active: UE在S-RAN有UP连接
    Active --> HO_Preparing: S-RAN发起Handover Required
    HO_Preparing --> HO_Accepted: T-RAN接纳 + SMF准备完成
    HO_Preparing --> HO_Rejected_SMF: SMF无法找到I-UPF
    HO_Preparing --> HO_Rejected_RAN: T-RAN拒绝建立
    HO_Preparing --> HO_Rejected_AMF: S-NSSAI在T-AMF不可用
    
    HO_Accepted --> HO_Executing: AMF下发Handover Command
    HO_Executing --> HO_Completed: UE发送Handover Confirm
    
    HO_Rejected_SMF --> Reestablish: SMF决定触发重建立
    HO_Rejected_SMF --> Deactivated: SMF决定去激活UP
    HO_Rejected_SMF --> Released: SMF决定释放Session
    
    HO_Rejected_RAN --> Released: SMF释放Session
    HO_Rejected_RAN --> Deactivated: UP连接去激活
    
    HO_Completed --> PathSwitched: SMF更新UPF路径
    PathSwitched --> S_UPF_Release: 定时器超时释放S-UPF
    S_UPF_Release --> Active: UE在T-RAN有UP连接
    
    Active --> [*]
    Released --> [*]
```

## 七、实战抓包与故障排查

### 7.1 抓包识别N2切换流程

在核心网侧，通过SCTP端口（通常38412）和NGAP协议过滤：

```
# Wireshark过滤NGAP切换消息
ngap.procedureCode == 22  # Handover Preparation
ngap.procedureCode == 23  # Handover Resource Allocation
ngap.procedureCode == 24  # Handover Notification

# 或按消息类型
ngap.messageType == 16  # Handover Required
ngap.messageType == 17  # Handover Command
ngap.messageType == 18  # Handover Preparation Failure
ngap.messageType == 19  # Handover Request
ngap.messageType == 20  # Handover Request Acknowledge
ngap.messageType == 21  # Handover Notify
```

**N2切换在抓包中的标志性特征**：
1. 同一UE的NGAP消息出现在**不同的gNB SCTP关联**上（源gNB和目标gNB分别与AMF的SCTP连接）
2. AMF向SMF发送的HTTP POST中`n2InfoContainer`包含`N2Handover`类型
3. 存在Uplink/Downlink RAN Status Transfer消息（Xn切换中不会出现此消息经核心网传递）

### 7.2 常见故障点

| 故障现象 | 可能原因 | 排查方向 |
|---------|---------|---------|
| Handover Required后无响应 | T-AMF选择失败 / SCTP连接断开 | 检查AMF日志中的NRF Discovery结果 |
| SMF返回non-acceptance | UPF服务区不覆盖目标gNB / N4会话建立失败 | 检查SMF的UPF选择逻辑和N4连接状态 |
| T-RAN拒绝PDU Session | S-NSSAI不可用 / QoS资源不足 / 用户面安全策略不支持 | 检查T-RAN的切片配置和负载 |
| 数据转发丢包 | 间接转发隧道未建立 / End Marker未正确处理 | 检查UPF的N4会话中的转发规则 |
| 切换后注册失败 | T-AMF与UDM交互异常 / PCF策略获取失败 | 检查T-AMF与UDM/PCF的连接 |
| 源gNB资源不释放 | S-AMF定时器未超时 / UE Context Release未发出 | 检查S-AMF的HO定时器配置 |
| PDU Session部分切换失败 | T-RAN只接纳部分QoS Flow | 正常行为，SMF后续触发PDU Session Modification移除未接纳Flow |
## 八、Release 18增强特性

### 8.1 DAPS（Dual Active Protocol Stack）切换

R18引入的DAPS切换允许UE在切换过程中同时保持与源gNB和目标gNB的连接，对于特定DRB实现"零中断"切换。

**DAPS在N2切换中的关键变化**：
- 源gNB在Source to Target Container中包含DAPS Request Information
- 目标gNB在Target to Source Container中包含DAPS Response Information
- 执行阶段使用RAN Early Status Transfer（而非普通Status Transfer）
- 目标gNB在Handover Notify中包含Notify Source NG-RAN node information
- 源gNB收到Handover Success后停止UL数据传输

### 8.2 RACS（Radio Capability Control Signaling）优化

R18引入UE Radio Capability ID机制，源gNB可以在Container中不携带完整UE无线能力，仅提供ID。目标gNB通过本地缓存或向AMF请求获取完整能力信息，减少Container大小和空口开销。

### 8.3 Time-based Handover

针对NTN卫星场景，R18支持基于时间的切换触发条件。源gNB在Container中携带time-based handover parameters，UE在指定时间窗口执行切换。

## 九、常见问题

**Q1: N2切换和Xn切换在信令层面最本质的区别是什么？**
A: 最本质的区别在于**SN Status Transfer的传递路径**和**路径切换的触发方**。Xn切换中，SN Status Transfer直接通过Xn-C接口传递，路径切换由目标gNB发起Path Switch Request。N2切换中，SN Status Transfer必须经AMF中转（Uplink RAN Status Transfer → AMF → Downlink RAN Status Transfer），路径切换由AMF在收到Handover Notify后通过SMF触发。此外，N2切换的Handover Request/Command消息都经由AMF中转，增加了约20-40ms的控制面延迟。

**Q2: 为什么同一个PDU Session可能只部分切换成功？**
A: 目标gNB基于无线资源状况逐QoS Flow评估接纳能力。对于GBR QoS Flow，如果目标小区没有足够的PRB资源满足其GFBR保证，gNB会拒绝该QoS Flow但可能接纳同一PDU Session中的Non-GBR Flow。切换完成后，SMF通过PDU Session Modification过程移除未被接纳的QoS Flow（TS 23.502 §4.9.1.3.2 Step 11a的后续处理）。

**Q3: AMF在切换过程中如何处理并发的N2信令？**
A: AMF采用"暂停"策略。从收到Handover Required开始，AMF暂停非切换相关的N2接口过程（如DL NAS Transfer、Location Report Control等），直到切换成功（Handover Notify）或失败。如果AMF检测到需要AMF变更，则拒绝SMF发起的N2请求并携带"切换进行中"指示。SMF收到后启动本地guard timer，暂停向AMF发送该UE的信令消息（TS 23.502 §4.9.1.3.1）。

**Q4: 间接转发时数据包从源gNB到目标gNB经过哪些节点？**
A: 间接转发路径为：S-RAN → S-UPF → T-UPF → T-RAN。源gNB将下行数据发送到S-UPF的N3转发隧道端点，S-UPF根据SMF下发的转发规则将数据通过N9隧道发送给T-UPF，T-UPF再通过N3隧道转发给目标gNB。转发完成后SMF启动indirect data forwarding timer，超时后释放间接转发隧道的N4会话资源。

**Q5: N2切换后UE为什么要发起移动性注册更新？**
A: UE到达目标gNB后需要执行移动性注册更新（TS 23.502 §4.2.2.2.2），目的是：1）更新UDM中的服务AMF记录；2）更新PCF中的移动性策略；3）如果AMF变更，T-AMF需向UDM注册并获取用户订阅数据。T-AMF知道这是切换场景，仅执行Registration procedure的子集，跳过Step 4/5/10（AMF间的context transfer步骤）。

## 参考来源

1. [3GPP TS 23.502 V18.x.x](https://www.3gpp.org/DynaReport/23502.htm) — Section 4.9.1.3: Inter NG-RAN node N2 based handover
2. [3GPP TS 38.413 V18.5.0](https://www.3gpp.org/DynaReport/38413.htm) — Section 8.4: NGAP Handover Procedures (Handover Preparation, Handover Resource Allocation, Handover Notification)
3. [free5GC — Introduction of Xn and NG (N2) based handover](https://free5gc.org/blog/20251105/20251105/) — N2切换信令流程图解与开源实现分析
4. [3G LTE Info — 5G NR N2 Handover Procedure](https://www.3glteinfo.com/call-flows/5g/n2-handover/) — N2切换完整Call Flow与IE解析
5. [ETH Zurich — A Comprehensive Formal Analysis of 5G Handover](https://people.inf.ethz.ch/rsasse/pub/5G-handover-WISEC21.pdf) — 5G切换安全性形式化分析（含N2/Xn切换对比）

---
> 本文由「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)