<!-- title: 5G NR Xn切换准备与执行全流程拆解 -->
<!-- domain: ran -->

# 5G NR Xn切换准备与执行全流程拆解

## 一、Xn切换在5G移动性管理中的定位

5G NR连接态移动性管理中，**Xn接口切换**（简称Xn HO）是最核心的同AMF/同SMF切换路径。与N2（NGAP）切换不同，Xn切换在**准备阶段和执行阶段完全不需要5GC参与**——两个gNB之间通过Xn-C接口直接协调切换资源预留和RRC重配信令的生成，仅在最末的完成阶段通过Path Switch Request通知AMF/UPF切换N3数据面锚点。

这一设计理念直接继承自LTE的X2切换，但NR在波束管理、PDCP无损切换、R18条件切换（CHO）等方面做了大量增强。本文基于 **TS 38.423 V18.6.0**（XnAP规范）、**TS 38.331 V19.2.0**（RRC规范）和**TS 38.300 V18.5.0**（NR Overall Description），对Xn切换的完整信令流程进行逐IE拆解。

### Xn切换 vs N2切换：触发条件与决策逻辑

| 对比维度 | Xn切换 | N2（NGAP）切换 |
|---------|--------|---------------|
| **切换范围** | 同AMF、同SMF、同UPF（或UPF内部分支） | 跨AMF、跨SMF、跨UPF |
| **信令路径** | gNB↔gNB（Xn-C直连） | gNB→AMF→gNB（绕行核心网） |
| **切换时延** | 典型10-20ms（准备+执行） | 典型30-50ms（需AMF中转） |
| **数据面中断** | 最小化（数据转发+无损PDCP） | 较长（N3路径切换开销） |
| **触发条件** | 源/目标gNB有Xn-C连接、同一PLMN | 无Xn-C连接或跨AMF区域 |
| **规范引用** | TS 38.423 Section 9.2 | TS 38.413 Section 8.4 |

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

以下时序图涵盖了从测量报告触发到Path Switch完成的Xn切换全流程（TS 38.300 Section 9.2.3）：

```mermaid
sequenceDiagram
    participant UE
    participant Src_gNB as 源gNB
    participant Tgt_gNB as 目标gNB
    participant AMF
    participant UPF

    Note over UE,Src_gNB: 阶段0：测量配置与报告
    Src_gNB->>UE: RRCReconfiguration（measConfig）
    UE->>Src_gNB: MeasurementReport（事件A3触发）

    Note over Src_gNB,Tgt_gNB: 阶段1：切换准备（Preparation）
    Src_gNB->>Tgt_gNB: XnAP: HANDOVER REQUEST
    Note right of Tgt_gNB: 准入控制、S-NSSAI校验、<br/>L1/L2资源预留
    Tgt_gNB-->>Src_gNB: XnAP: HANDOVER REQUEST ACKNOWLEDGE
    Note right of Tgt_gNB: 包含RRC Container<br/>（reconfigurationWithSync）

    Note over UE,Tgt_gNB: 阶段2：切换执行（Execution）
    Src_gNB->>UE: RRCReconfiguration（HO Command）
    Note right of UE: 启动T304定时器
    Src_gNB->>Tgt_gNB: XnAP: SN STATUS TRANSFER
    Note right of Tgt_gNB: PDCP UL/DL SN+HFN
    Src_gNB->>Tgt_gNB: 数据转发（DL Data Forwarding）
    UE->>Tgt_gNB: CFRA随机接入（Msg1/Msg2）
    UE->>Tgt_gNB: RRCReconfigurationComplete

    Note over Tgt_gNB,UPF: 阶段3：切换完成（Completion）
    Tgt_gNB->>AMF: NGAP: PATH SWITCH REQUEST
    AMF->>UPF: N4 Session Modification
    UPF->>Tgt_gNB: DL Data（新N3路径）
    UPF-->>Src_gNB: End Marker（旧N3路径）
    AMF-->>Tgt_gNB: NGAP: PATH SWITCH REQUEST ACK
    Tgt_gNB->>Src_gNB: XnAP: UE CONTEXT RELEASE
```

## 三、阶段1深度拆解：XnAP HANDOVER REQUEST

### 3.1 HANDOVER REQUEST消息IE结构

源gNB在收到UE的MeasurementReport并做出切换判决后，向目标gNB发送 **XnAP HANDOVER REQUEST**（TS 38.423 Section 9.2.1.1）。这是整个Xn切换的触发信令，包含目标gNB完成准入控制和资源预留所需的全部UE上下文信息。

```mermaid
graph TD
    A[HANDOVER REQUEST] --> B[UE-XnAP-ID Pair]
    A --> C[Target Cell ID]
    A --> D[UE Context]
    A --> E[PDU Session Resources]

    D --> D1[Security Information]
    D --> D2[UE Aggregate Maximum Bit Rate]
    D --> D3[UE History Information]
    D --> D4[UE Capability Information]

    D1 --> D1a[KgNB / KeNB]
    D1 --> D1b[Security Algorithm]

    E --> E1[PDU Session ID]
    E --> E2[S-NSSAI]
    E --> E3[QoS Flow Level QoS Profile]
    E --> E4[UL/DL GTP Tunnel Info]

    A --> F[RRC Container<br/>源gNB当前RRC配置]
```

### 3.2 关键IE参数详解

| IE名称 | 说明 | 规范章节 |
|--------|------|---------|
| **Source UE-XnAP-ID** | 源gNB分配的UE标识，Xn-C接口唯一 | TS 38.423 §9.2.1.1 |
| **Target Cell ID** | 目标小区全局标识（NCGI）+ PCI | TS 38.423 §9.2.1.1 |
| **KgNB** | 当前安全密钥，用于目标gNB派生新密钥 | TS 33.501 §6.9.2 |
| **UE-AMBR** | UE聚合最大比特率，用于准入控制 | TS 38.423 §9.2.1.1 |
| **S-NSSAI** | 切片标识，目标gNB做切片感知准入 | TS 38.423 §9.2.1.1 |
| **DRB QoS Info** | 每个DRB的5QI、ARP、GBR参数 | TS 38.423 §9.2.1.1 |
| **UE History Info** | UE最近访问小区列表，用于移动性优化 | TS 38.423 §9.2.1.1 |

**设计意图**：HANDOVER REQUEST中的RRC Container是"透明容器"——源gNB将自己当前的RRC配置打包传给目标gNB，目标gNB据此生成差异化的RRC重配命令。这种设计使得两个gNB之间**不需要理解对方厂商的私有RRC扩展**，只要遵循TS 38.331的ASN.1编码即可互操作。

### 3.3 目标gNB准入控制决策

目标gNB收到HANDOVER REQUEST后，按以下优先级执行准入控制（TS 38.300 Section 9.2.3 Step 4）：

1. **S-NSSAI校验**：如果PDU Session关联的目标切片在目标gNB不受支持，该PDU Session直接拒绝（不影响其他PDU Session的准入）
2. **QoS Flow级准入**：对每个QoS Flow的5QI参数（GBR/Non-GBR）评估无线资源是否满足
3. **UE-AMBR约束**：所有准入的DRB总速率不超过UE-AMBR
4. **L1/L2资源预留**：为UE分配C-RNTI、专属RACH资源、PDSCH/PUSCH资源

准入失败时，目标gNB回复 **HANDOVER PREPARATION FAILURE**，携带Cause值（典型：`no-radio-resources-available`、`transport-resource-unavailable`）。

## 四、阶段2深度拆解：RRC重配与reconfigurationWithSync

### 4.1 reconfigurationWithSync IE完整结构

HANDOVER REQUEST ACKNOWLEDGE中最关键的IE是嵌入在RRC Container中的 **reconfigurationWithSync**（TS 38.331 Section 6.2.2，RRCReconfiguration-IEs）。这个IE是UE在目标小区进行同步和接入所需的全部参数集合。

```mermaid
graph LR
    A[RRCReconfiguration] --> B[reconfigurationWithSync]
    B --> B1[spCellConfigCommon]
    B --> B2[newUE-Identity]
    B --> B3[t304]
    B --> B4[rach-ConfigDedicated]
    B --> B5[ssbConfig]
    B --> B6[csi-RSConfig]

    B1 --> B1a[physCellId]
    B1 --> B1b[downlinkConfigCommon]
    B1 --> B1c[uplinkConfigCommon]
    B1 --> B1d[ssb-PositionsInBurst]
    B1 --> B1e[tdd-UL-DL-ConfigurationCommon]

    B4 --> B4a[cfra: preamble index]
    B4 --> B4b[cfra: PRACH mask index]
    B4 --> B4c[cfra: ssb-ResourceList]

    B5 --> B5a[ssbToRachMapping]
    B5 --> B5b[ssb-rsrp-ThresholdSSB]
```

### 4.2 reconfigurationWithSync核心参数表

| 参数 | 含义 | 典型取值 | 设计意图 |
|------|------|---------|---------|
| **physCellId** | 目标小区物理层标识 | 0-1007 | UE快速锁定目标小区PCI |
| **newUE-Identity** | 目标小区分配的新C-RNTI | 16-bit MAC层标识 | 避免目标小区C-RNTI冲突 |
| **t304** | 切换执行定时器 | ms50/ms100/ms150/ms200 | UE必须在T304超时前完成目标小区同步 |
| **rach-ConfigDedicated** | 专属CFRA参数 | preamble index + PRACH mask | 消除RACH竞争、降低切换时延 |
| **ssbConfig** | SSB与RACH资源的映射关系 | ssb-ResourceList | NR特有：波束级RACH资源分配 |
| **csi-RSConfig** | CSI-RS与RACH资源的映射 | csi-RS-ResourceList | 支持基于CSI-RS的精细化波束切换 |
| **downlinkConfigCommon** | 目标小区DL公共配置 | BWP、CORESET、SearchSpace | UE无需读取目标小区SIB即可工作 |
| **uplinkConfigCommon** | 目标小区UL公共配置 | BWP、RACH-ConfigCommon | 同上 |

**关键设计考量**：

- **CFRA（无竞争随机接入）** vs CBRA（竞争随机接入）：目标gNB为UE分配专属preamble，UE在目标小区的Msg1无需竞争解决。这在URLLC场景尤为重要——CFRA的RACH时延是确定性的（1次Msg1+Msg2），而CBRA需要4-step或2-step RA的完整竞争解决过程。

- **SSB-based RACH映射**：这是NR相对于LTE的显著增强。LTE的切换命令仅指定目标小区PCI和频点，UE需要盲搜目标小区。NR通过`ssbConfig`明确告知UE目标小区的SSB时频位置和RSRP门限，UE可以**在切换前就测量目标小区波束质量**，切换后直接使用最佳波束发起RACH。

- **T304定时器保护**：T304是UE侧的切换失败安全阀。UE收到RRCReconfiguration（含reconfigurationWithSync）后启动T304。如果UE在T304超时前未能完成以下全部动作——同步到目标小区DL、发送Msg1、接收Msg2、发送RRCReconfigurationComplete——则判定切换失败，触发RRC Re-establishment。

### 4.3 切换执行阶段的PDCP处理

切换执行阶段，源gNB在发送RRCReconfiguration给UE后，立即向目标gNB发送 **SN STATUS TRANSFER**（TS 38.423 Section 9.2.1.5），这是无损切换的关键。

| IE字段 | 方向 | 含义 |
|--------|------|------|
| **DL COUNT** | 源→目标 | 下一个待发送PDCP PDU的PDCP SN + HFN |
| **UL COUNT** | 源→目标 | 下一个期望接收PDCP PDU的PDCP SN + HFN |
| **DL 1st Missing SN** | 源→目标 | 第一个未收到UE确认的DL PDCP PDU SN |
| **DL Receive Status** | 源→目标 | 位图：指示哪些DL PDCP PDU已被UE成功确认 |
| **DRBs Subject to Status Transfer** | 双向 | 需要传递SN状态的DRB列表 |

**无损切换的数据面机制**（TS 38.300 Section 9.2.3.4）：

对于AM（Acknowledged Mode）DRB，源gNB在SN STATUS TRANSFER之后，将所有未被UE确认的DL PDCP SDU转发给目标gNB。目标gNB在收到转发的数据后，**按PDCP SN排序后发送**，确保UE不会因切换而丢失任何下行数据包。对于UM（Unacknowledged Mode）DRB，仅转发SN状态，不保证按序交付。

## 五、阶段3深度拆解：Path Switch与资源释放

### 5.1 Path Switch Request

UE成功接入目标gNB并完成RRCReconfigurationComplete后，目标gNB向AMF发送 **NGAP PATH SWITCH REQUEST**（TS 38.413 Section 8.9），触发核心网将N3 DL数据路径从源gNB切换到目标gNB。

关键IE包括：
- **AMF UE NGAP ID**：AMF侧UE标识
- **RAN UE NGAP ID**：目标gNB新分配的UE标识
- **PDU Session Resources to be Switched in UL**：每个PDU Session的新UL GTP Tunnel Endpoint
- **User Location Information**：UE在目标小区的位置信息（用于TAI更新判断）
- **UESecurityCapabilities**：用于AMF验证安全算法

**Path Switch的信令序列**：

```mermaid
sequenceDiagram
    participant Tgt_gNB as 目标gNB
    participant AMF
    participant SMF
    participant UPF
    participant Src_gNB as 源gNB

    Tgt_gNB->>AMF: NGAP: PATH SWITCH REQUEST
    AMF->>SMF: Nsmf_PDUSession_UpdateSMContext<br/>（N3 UL Tunnel变更）
    SMF->>UPF: N4 Session Modification<br/>（DL F-TEID更新）
    Note over UPF: 切换DL数据路径到目标gNB
    UPF->>UPF: 发送End Marker到旧N3隧道
    UPF->>Tgt_gNB: DL Data（新N3路径）
    SMF-->>AMF: Nsmf Response
    AMF-->>Tgt_gNB: NGAP: PATH SWITCH REQUEST ACK
    Tgt_gNB->>Src_gNB: XnAP: UE CONTEXT RELEASE
    Note over Src_gNB: 释放UE上下文和<br/>L1/L2无线资源
```

### 5.2 End Marker机制与数据面无丢包保证

UPF在收到SMF的N4 Session Modification后，首先向源gNB的旧N3隧道发送一个或多个 **End Marker** 包（GTP-U协议，Packet Type = "End Marker"）。源gNB收到End Marker后，将其连同还在缓存中的DL数据包一起转发给目标gNB。目标gNB在End Marker之前的所有数据包按序发送给UE，End Marker之后的第一个新数据包就是UPF直接通过新N3隧道发送的。

这一机制确保了**下行数据面的无损切换**——即使N3路径切换需要数十毫秒（SMF→UPF的N4交互），数据也不会丢失，只是缓存在源gNB等待转发。

## 六、RRC状态转换图

整个Xn切换过程涉及UE的RRC状态转换（TS 38.331 Section 4.2）：

```mermaid
stateDiagram-v2
    [*] --> RRC_CONNECTED: 初始状态
    RRC_CONNECTED --> RRC_RECONFIGURING: 收到RRCReconfiguration<br/>（含reconfigurationWithSync）
    RRC_RECONFIGURING --> T304_Running: 启动T304
    T304_Running --> CFRA_Msg1: 向目标gNB发送专属Preamble
    CFRA_Msg1 --> CFRA_Msg2: 收到RAR
    CFRA_Msg2 --> RRC_CONNECTED: 发送RRCReconfigurationComplete<br/>到目标gNB
    T304_Running --> HO_Failure: T304超时
    HO_Failure --> RRC_Reestablishment: 触发RRC重建
    RRC_CONNECTED --> [*]
```

**T304超时后的处理**（TS 38.331 Section 5.3.5.5）：

1. UE停止T304，回退到源小区的配置
2. UE使用源小区的PCI和频点发起 **RRC Re-establishment**（如果源小区仍可用）
3. 如果源小区也不可用，UE进入RRC_IDLE，重新发起初始接入

## 七、实战抓包识别指南

### 7.1 Wireshark过滤器

```
# XnAP Handover Request
xnap.procedureCode == 10 && xnap.messageType == 1

# XnAP Handover Request Acknowledge
xnap.procedureCode == 10 && xnap.messageType == 2

# XnAP SN Status Transfer
xnap.procedureCode == 13

# RRC Reconfiguration with reconfigurationWithSync
rrc.rrcReconfiguration.reconfigurationWithSync == 1

# NGAP Path Switch Request
ngap.procedureCode == 42 && ngap.messageType == 1
```

### 7.2 关键Field ID识别

在XnAP HANDOVER REQUEST ACK消息中，重点抓取以下字段：

1. **RRC Container**（OCTET STRING）：内含目标gNB生成的RRCReconfiguration，可用Wireshark的"Decode As → NR RRC"进行内层解码
2. **Data Forwarding Info**：DL/UL GTP Tunnel Endpoint，用于判断数据转发隧道是否正确建立
3. **Accepted PDU Session List**：如果某些PDU Session未被接受，说明目标gNB准入失败

### 7.3 常见故障排查

| 故障现象 | 可能原因 | 排查方法 |
|---------|---------|---------|
| T304超时、切换失败 | 目标小区SSB信号弱或被遮挡 | 检查`ssb-rsrp-ThresholdSSB`配置与实际RSRP |
| HANDOVER PREPARATION FAILURE | 目标gNB无线资源不足 | 查看Cause值，评估目标小区负载 |
| 数据丢包（AM DRB） | SN STATUS TRANSFER未及时发送 | 检查源gNB是否在RRCReconfiguration后立即发送 |
| End Marker后仍有丢包 | UPF N4 Modification延迟 | 检查SMF→UPF的N4信令时延 |
| UE发RRC Re-establishment | T304超时或目标小区PRACH故障 | 分析目标gNB的PRACH接收日志 |
## 常见问题

**Q1: Xn切换和N2切换可以同时配置吗？UE如何知道该走哪条路径？**

A: 可以同时配置。但路径选择不在UE侧——UE只负责上报MeasurementReport，切换类型的决策完全由**源gNB**做出。源gNB根据以下条件判断：是否与目标gNB有Xn-C连接、目标gNB是否在同一AMF Service Area、源/目标是否属于同一SMF/UPF。如果满足Xn切换条件就选Xn，否则回退到N2切换。

**Q2: reconfigurationWithSync中的spCellConfigCommon是否等同于目标小区的SIB1？**

A: 不完全等同，但功能相似。spCellConfigCommon包含了UE在目标小区立即工作所需的**最小公共配置集**（BWP、CORESET、RACH配置等），目的是让UE**不读取目标小区的SIB1就能发起随机接入**。但spCellConfigCommon不包含SIB2-SIB12等系统信息。UE在切换完成后的空闲时刻再接收完整的SI（通过SI-Window调度）。

**Q3: SN STATUS TRANSFER丢失会怎样？**

A: 如果SN STATUS TRANSFER在传输过程中丢失，对于AM DRB，目标gNB无法知道哪些DL PDCP PDU已被UE确认，可能导致重复发送或序号错乱。NR的PDCP层设计了一定的容错机制：目标gNB可以从源gNB转发的数据包中推断SN状态，但恢复效率较低。实际网络中，Xn-C接口底层使用SCTP传输，保证SN STATUS TRANSFER可靠送达。

**Q4: Xn切换支持跨频点（inter-frequency）吗？**

A: 支持。Xn切换同时支持intra-frequency和inter-frequency场景。inter-frequency切换时，源gNB在测量配置中会下发异频测量事件（A4/A5/A6），UE通过Gap测量异频小区并上报MeasurementReport。后续的Xn切换信令流程与同频完全一致——因为Xn-C是逻辑接口，不关心底层频点差异。差异仅在UE侧的射频重调（retuning）。

**Q5: R18条件切换（CHO）对Xn切换流程有什么影响？**

A: CHO在Xn切换的**准备阶段**引入了多候选gNB并行准备的机制。源gNB可以同时向多个目标gNB发送HANDOVER REQUEST（每个候选小区一个），UE收到多个RRCReconfiguration（含reconfigurationWithSync）后缓存但**不立即执行**，而是等待特定执行条件（如候选小区RSRP超过服务小区+偏移量）满足后才触发切换执行。执行阶段和完成阶段与普通Xn切换相同。CHO显著降低了高速移动场景的切换失败率。

## 参考来源

1. [3GPP TS 38.423 V18.6.0](https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3228) — Section 9.2: Xn Handover Preparation/Resource Status/UE Context Management procedures
2. [3GPP TS 38.331 V19.2.0](https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3197) — Section 6.2.2: RRCReconfiguration message definition, Section 6.3.2: ReconfigurationWithSync IE structure
3. [3GPP TS 38.300 V18.5.0](https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3146) — Section 9.2.3: Handover procedures in NR, Section 9.2.3.4: Data forwarding
4. [free5GC: Introduction of Xn and NG(N2) based handover](https://free5gc.org/blog/20251105/20251105/) — Xn/N2切换完整信令流对比
5. [iTelcoTech: 5G NR Mobility – Handover](https://www.itelcotech.com/blog/5g-nr-mobility-handover) — 切换C-Plane/U-Plane处理详解
6. [ShareTechnote: 5G NR RRC Reconfiguration](https://www.sharetechnote.com/html/5G/5G_RRC_Reconfiguration.html) — RRC重配消息的字段级分析

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