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切换完整信令时序图

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

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上下文信息。

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参数详解

设计意图：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在目标小区进行同步和接入所需的全部参数集合。

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核心参数表

关键设计考量：

• 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），这是无损切换的关键。

无损切换的数据面机制（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的信令序列：

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）：

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 常见故障排查

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 — Section 9.2: Xn Handover Preparation/Resource Status/UE Context Management procedures
2. 3GPP TS 38.331 V19.2.0 — Section 6.2.2: RRCReconfiguration message definition, Section 6.3.2: ReconfigurationWithSync IE structure
3. 3GPP TS 38.300 V18.5.0 — 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 — Xn/N2切换完整信令流对比
5. iTelcoTech: 5G NR Mobility – Handover — 切换C-Plane/U-Plane处理详解
6. ShareTechnote: 5G NR RRC Reconfiguration — 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 等场景全覆盖。