在5G NR网络中,UE(用户设备)从一个gNB覆盖区域移动到另一个gNB覆盖区域时,需要执行切换(Handover)以维持业务连续性。与4G LTE的X2切换类似,5G引入了Xn接口切换——一种不经过核心网(AMF/UPF)参与的接入网内部切换机制,核心仅在下发路径切换(路径切换)阶段才介入。
Xn切换的显著优势在于低时延和轻量信令:整个准备和执行阶段完全在NG-RAN内部完成,避免了N2切换中AMF和SMF的多轮交互,典型信令时延可控制在20-40ms以内(N2切换则需40-80ms)。
本文将基于 3GPP TS 38.300 Section 9.3、TS 38.423 XnAP、TS 38.331 RRC 和 TS 38.413 NGAP 四个核心规范,逐信令、逐IE地拆解Xn切换的完整流程。
Xn切换可以分为四个阶段:触发与准备 → 执行 → 完成 → 资源释放。下面的时序图展示了完整的信令交互过程。
sequenceDiagram
participant UE
participant Src_gNB as 源gNB
participant Tgt_gNB as 目标gNB
participant AMF
participant UPF
Note over UE,Src_gNB: 阶段1:触发与测量
UE->>Src_gNB: MeasurementReport (Event A3)
Note right of Src_gNB: 切换判决算法评估
Note over Src_gNB,Tgt_gNB: 阶段2:Xn准备
Src_gNB->>Tgt_gNB: XnAP HANDOVER REQUEST
Note right of Tgt_gNB: 准入控制 & 资源预留
Tgt_gNB-->>Src_gNB: XnAP HANDOVER REQUEST ACKNOWLEDGE
Note over UE,Src_gNB: 阶段3:切换执行
Src_gNB->>UE: RRCReconfiguration (含ReconfigurationWithSync)
Note over UE: 应用目标小区配置
Src_gNB->>Tgt_gNB: XnAP SN STATUS TRANSFER
Note over Src_gNB,Tgt_gNB: 数据转发开始 (Xn-U)
UE->>Tgt_gNB: Random Access (Preamble)
Tgt_gNB-->>UE: Random Access Response
UE->>Tgt_gNB: RRCReconfigurationComplete
Note over Tgt_gNB,AMF: 阶段4:路径切换
Tgt_gNB->>AMF: NGAP PATH SWITCH REQUEST
AMF->>UPF: N4 Session Modification
UPF-->>AMF: N4 Session Modification Response
AMF-->>Tgt_gNB: NGAP PATH SWITCH REQUEST ACKNOWLEDGE
Note over Src_gNB,Tgt_gNB: 阶段5:资源释放
Tgt_gNB->>Src_gNB: XnAP UE CONTEXT RELEASE
Note right of Src_gNB: 释放UE上下文与无线资源
UE根据源gNB下发的MeasConfig(测量配置)中的报告配置,对邻区进行测量。在Xn切换场景中,最典型的触发事件为Event A3,定义于TS 38.331 Section 5.5.4。
Event A3触发条件:
Mn + Ofn + Ocn - Hys > Mp + Ofp + Ocp + Off
| 参数 | 含义 | 来源 |
|---|---|---|
| Mn | 邻区测量值(RSRP/RSRQ/SINR) | UE实测 |
| Mp | 服务小区测量值 | UE实测 |
| Ofn | 邻区频率特定偏移 | meableObject中配置 |
| Ocn | 邻区小区特定偏移 | meableObject中配置 |
| Ofp | 服务频率特定偏移 | meableObject中配置 |
| Ocp | 服务小区特定偏移 | measObject中配置 |
| Hys | 滞后参数(Hysteresis) | reportConfig中配置 |
| Off | 偏移参数(A3 Offset) | reportConfig中配置 |
离开条件(触发报告取消):
Mn + Ofn + Ocn + Hys < Mp + Ofp + Ocp + Off
滞后参数Hys的作用是防止乒乓切换——UE在小区边界来回移动时,必须超过一定门限差值才会真正触发。
UE在满足A3事件条件后,向源gNB发送MeasurementReport消息,关键IE包括:
| IE名称 | 描述 | 说明 |
|---|---|---|
| measId | 测量标识 | 关联measObjId和reportConfigId |
| measResultServingMO | 服务小区测量结果 | 包含RSRP/RSRQ值 |
| measResultNeighCells | 邻区测量结果 | 包含physCellId和对应测量值 |
| cellsTriggeredList | 触发事件的小区列表 | 指明哪些邻区满足A3条件 |
源gNB收到报告后,执行内部切换判决算法。该算法不仅考虑无线信号质量,还综合评估负载均衡、频率优先级、UE能力等因素,最终确定目标小区。
源gNB确定目标后,通过Xn-C接口发送HANDOVER REQUEST消息。该消息定义于TS 38.423 Section 8.4.1,是整个准备阶段的核心。
graph TD
A[HANDOVER REQUEST] --> B[Source NG-RAN Node UE XnAP ID]
A --> C[Target Cell ID]
A --> D[UE History Information]
A --> E[PDU Session Resources to Setup List]
A --> F[UE Security Capabilities]
A --> G[RRC Container]
E --> E1[PDU Session ID]
E --> E2[QoS Flow Setup Request List]
E --> E3[UL NG-U UP TNL Information]
E --> E4[Data Forwarding Info]
E2 --> Q1[QoS Flow Identifier QFI]
E2 --> Q2[QoS Flow Level QoS Parameters]
E2 --> Q3[5QI / ARP]
F --> F1[Encryption Algorithms]
F --> F2[Integrity Protection Algorithms]
F --> F3[Security Key KgNB]
G --> G1[UE Capability]
G --> G2[Source Cell Config]
G --> G3[Measurement Config]
关键IE详解:
| IE | 类型 | 作用 |
|---|---|---|
| Source NG-RAN Node UE XnAP ID | Integer | 源gNB侧的UE逻辑标识,贯穿整个Xn切换过程 |
| Target Cell ID | NR CGI | 目标小区的全局标识(含PLMN + Cell Identity) |
| UE History Information | List | UE最近访问的小区列表,辅助目标gNB做移动性预判 |
| PDU Session Resources to Setup List | List | 需要在目标侧建立的所有PDU会话资源 |
| UE Security Capabilities | Bit String | UE支持的加密/完整性保护算法列表 |
| Security Key | Bit String | 当前 KgNB 或衍生密钥,目标gNB用于推演新密钥 |
| RRC Container | Octet String | 包含UE RRC上下文的透传容器 |
每个PDU Session Resource条目包含:
目标gNB收到HANDOVER REQUEST后,执行以下准入检查(Admission Control):
准入成功后,目标gNB回复HANDOVER REQUEST ACKNOWLEDGE(TS 38.423 Section 8.4.2)。这是整个Xn切换流程中信息量最大的消息。
| IE | 描述 | 设计意图 |
|---|---|---|
| Target NG-RAN Node UE XnAP ID | 目标侧UE标识 | 双向标识配对 |
| PDU Session Resources Admitted List | 成功准入的PDU会话资源 | 告知源gNB哪些资源已就绪 |
| PDU Session Resources Failed to Setup List | 准入失败的资源 | 部分接纳机制——即使部分QoS Flow无法满足也允许切换 |
| RRC Container | 最关键IE | 包含目标gNB生成的RRCReconfiguration消息 |
| Data Forwarding Address | 数据转发地址 | DL forwarding的GTP-U TEID |
| Selected Security Algorithm | 选定的安全算法 | 目标gNB选出的加密/完整性保护算法 |
| UE Context Kept Indicator | UE上下文保留指示 | DAPS切换时源侧需保留上下文 |
RRC Container内部的RRCReconfiguration消息(TS 38.331 Section 6.2.2):
该消息是目标gNB为UE准备的完整目标小区配置,包括:
当目标gNB无法接纳切换请求时,回复HANDOVER PREPARATION FAILURE(TS 38.423 Section 8.4.3)。
| Cause值 | 含义 | 典型场景 |
|---|---|---|
| Radio Resources Not Available | 无线资源不足 | 小区负载过高 |
| Transport Resources Unavailable | 传输资源不足 | Xn/NG-U隧道拥塞 |
| Target AMF not available | AMF不可达 | 仅N2切换场景 |
| Handover Desirable for Radio Reason | 无线原因建议切换 | 覆盖盲区 |
| Unknown Target ID | 未知目标标识 | 配置错误 |
| No Radio Resources Available in Target Cell | 目标小区无资源 | 拥塞 |
源gNB收到拒绝后,可执行以下策略: - 尝试其他候选目标gNB - 发起N2切换(通过核心网中转) - 调整切换参数降低触发门限
源gNB将目标gNB生成的RRC Container透传给UE。在Uu接口上,源gNB通过RRCReconfiguration消息下发切换命令。
graph LR
A[RRCReconfiguration] --> B[ReconfigurationWithSync]
A --> C[RadioBearerConfig]
A --> D[SecondaryCellGroupConfig]
A --> E[MeasConfig]
A --> F[SecurityConfig]
B --> B1[targetPhysCellId: 目标PCI]
B --> B2[RACH-ConfigDedicated: 专用Preamble]
B --> B3[newUE-Identity: 新C-RNTI]
B --> B4[T304 timer: 切换超时定时器]
B --> B5[SSB资源信息]
C --> C1[DRB-ToAddModList]
C --> C2[DRB-ToReleaseList]
C --> C3[PDCP-Config]
C --> C4[RLC-Config]
F --> F1[securityAlgorithmConfig]
F --> F2[keyToUse: 指示使用哪个密钥]
ReconfigurationWithSync IE的核心参数:
| 参数 | 含义 | 典型值/说明 |
|---|---|---|
| targetPhysCellId | 目标小区PCI | 0-1007 |
| newUE-Identity | 新的C-RNTI | 16-bit,目标gNB分配 |
| T304 | 切换执行定时器 | ms100, ms200, ms500等 |
| RACH-ConfigDedicated | 专用RACH配置 | 包含专用Preamble Index |
| rach-Occasion | RACH时机 | PRACH occasion的时频位置 |
T304定时器的意义:UE收到RRCReconfiguration后启动T304。如果T304超时时UE仍未成功接入目标小区,则判定为切换失败,UE发起RRC连接重建立(RRC Re-establishment)。
源gNB在向UE发送RRCReconfiguration之后、收到UE上下文释放之前,发送SN STATUS TRANSFER消息(TS 38.423 Section 8.6)。
这个消息的作用是将PDCP层的序列号状态从源gNB传递给目标gNB,确保数据无损/按序传输。
graph TD
A[SN STATUS TRANSFER] --> B[Source NG-RAN Node UE XnAP ID]
A --> C[Target NG-RAN Node UE XnAP ID]
A --> D[DRBs Subject to Status Transfer List]
A --> E[DRBs Subject to SN Status Indication List]
D --> D1[E-UTRAN RB ID]
D --> D2[UL PDCP SN Receiver Status]
D --> D3[DL PDCP SN Status]
D2 --> D2a[Last Received UL PDCP SN]
D2 --> D2b[UL Receiving Status Bitmap]
D3 --> D3a[Last Transmitted DL PDCP SN]
D3 --> D3b[DL Transmitting Status Bitmap]
| IE | 描述 | 用途 |
|---|---|---|
| UL PDCP SN Receiver Status | 上行接收状态 | 告知目标gNB哪些上行PDCP SN已被源gNB确认 |
| DL PDCP SN Status | 下行发送状态 | 告知目标gNB下一个待发送的下行PDCP SN |
| DL Transmitting Status Bitmap | 下行发送位图 | 标记哪些SN已发送但尚未收到确认 |
设计意图:对于AM(Acknowledged Mode)DRB,SN Status Transfer确保目标gNB能从正确的SN继续发送,避免数据重复或丢失。对于UM(Unacknowledged Mode)DRB,仅传递SN指示即可。
SN Status Transfer后,数据转发开始。源gNB通过Xn-U接口将缓存的下行PDCP SDU转发给目标gNB。
数据转发模式:
| 模式 | 描述 | 适用场景 |
|---|---|---|
| 直接转发 | 源gNB → 目标gNB(通过Xn-U) | Xn-U可达时的首选方式 |
| 间接转发 | 源gNB → UPF → 目标gNB(通过NG-U) | Xn-U不可达时 |
| 无转发 | 不转发数据 | 某些UM DRB或时延不敏感业务 |
UE收到RRCReconfiguration后,断开与源小区的连接,向目标小区发起随机接入:
RACH-ConfigDedicated(专用Preamble),UE执行非竞争随机接入UE成功接入目标小区后,发送RRCReconfigurationComplete给目标gNB,标志着UE侧切换完成。
该消息包含: - RRC-Transaction Identifier:与RRCReconfiguration中的Transaction ID匹配 - UE-MRDC-capability(可选):更新后的MRDC能力
目标gNB收到UE的RRCReconfigurationComplete后,向AMF发送PATH SWITCH REQUEST(TS 38.413 Section 8.9),请求将DL数据路径从源gNB切换到目标gNB。
| IE | 描述 |
|---|---|
| AMF UE NGAP ID | AMF侧UE标识 |
| RAN UE NGAP ID | 目标gNB侧UE标识 |
| Source NG-RAN Node UE XnAP ID | 用于AMF关联源gNB |
| User Location Information | UE当前位置(TAI + NR CGI) |
| PDU Session Resources to Switch List | 需切换的PDU会话资源 |
| DL NG-U UP TNL Information | 目标gNB的下行GTP-U端点 |
AMF收到Path Switch Request后,触发以下核心网内部流程:
AMF向目标gNB确认路径切换成功,携带:
路径切换成功后,目标gNB向源gNB发送UE CONTEXT RELEASE消息(TS 38.423 Section 8.4.4)。源gNB收到后释放所有与该UE相关的无线资源和C-plane资源,包括:
stateDiagram-v2
[*] --> Connected: RRC_CONNECTED
Connected --> HO_Triggered: MeasurementReport (A3)
HO_Triggered --> HO_Preparation: HO Request Sent
HO_Preparation --> HO_Executing: HO Request ACK + RRCReconfig
HO_Preparation --> HO_Failed: HO Preparation Failure
HO_Executing --> HO_Completed: RACH Success + RRCReconfigComplete
HO_Executing --> HO_Failed: T304 Expiry
HO_Completed --> Connected: Path Switch Success
HO_Failed --> RRC_Reestablish: RRC Connection Re-establishment
HO_Failed --> RRC_Idle: Re-establishment Failure
RRC_Reestablish --> Connected: Re-establishment Success
RRC_Reestablish --> RRC_Idle: Re-establishment Failure
RRC_Idle --> [*]
| 维度 | Xn切换 | N2(NG-C)切换 |
|---|---|---|
| 核心网参与 | 仅路径切换阶段 | 全程参与(准备+执行) |
| 信令接口 | Xn-C + Uu + NG-C(路径切换) | NG-C + Uu + NG-U |
| 典型时延 | 20-40ms | 40-80ms |
| 数据中断时间 | 约10-15ms | 约20-50ms |
| 适用条件 | 源/目标gNB同AMF、Xn可达 | 跨AMF、Xn不可达或inter-RAT |
| 准入控制 | 目标gNB执行 | 目标gNB + AMF + SMF协同 |
| 数据转发 | 直接(Xn-U)或间接 | 间接(通过UPF) |
| 规范章节 | TS 38.300 Sec 9.3 | TS 38.300 Sec 9.4 |
| 协议层 | 过滤条件 | 关键观察点 |
|---|---|---|
| XnAP | xnap 或 sctp.port == <Xn-C port> |
HANDOVER REQUEST/ACK的时序 |
| RRC | rrc.rrcRelease 或 NAS过滤 |
RRCReconfiguration中的targetPhysCellId |
| NGAP | ngap |
PATH SWITCH REQUEST/ACK |
| GTP-U | gtp 且 Xn接口IP |
数据转发的TEID变化 |
| 故障现象 | 可能原因 | 排查思路 |
|---|---|---|
| 切换准备反复失败 | 目标gNB资源不足 | 检查HANDOVER PREPARATION FAILURE的Cause值,评估目标小区负载 |
| T304超时 | UE无法接入目标小区 | 检查目标小区SSB配置、RACH参数、是否存在干扰 |
| 路径切换失败 | UPF隧道更新异常 | 检查N4 Session Modification是否成功,F-TEID是否一致 |
| 数据丢包 | SN状态未正确传递 | 检查SN STATUS TRANSFER消息是否发送、DL PDCP SN是否连续 |
| 乒乓切换 | A3参数配置不当 | 调整Hys和Off参数,增大迟滞门限 |
| ## 十、Rel-16/17增强:CHO与DAPS |
Rel-16引入了CHO机制(TS 38.300 Section 9.2.3.5),核心思想是网络预先准备多个候选目标gNB,UE自行判断何时执行切换。
CHO vs 传统Xn切换:
| 对比项 | 传统Xn HO | CHO |
|---|---|---|
| 切换执行决策 | 网络侧 | UE侧(基于CHO条件) |
| 准备阶段 | 单目标 | 多候选目标 |
| 信令开销 | 较小 | 较大(需预准备多个目标) |
| 切换中断时间 | ~10ms | ~0ms(条件满足即执行) |
| 适用场景 | 正常移动 | 高速移动、信令拥塞 |
Rel-16同时引入了DAPS(TS 38.300 Section 9.2.3.6),UE在切换过程中同时维持与源小区和目标小区的连接,实现零中断切换。
trueQ1: Xn切换和N2切换如何选择?由谁决定? A: 由源gNB决定。源gNB根据以下条件判断:(1) 源/目标gNB之间Xn接口是否可用;(2) 是否属于同一AMF服务区域;(3) 目标gNB是否可达。如果Xn可用且同AMF,优先选择Xn切换以降低时延和信令开销。
Q2: SN Status Transfer消息为什么在RRCReconfiguration之后发送? A: 因为源gNB在发送RRCReconfiguration后仍可能收到UE在上行发送的数据(UE可能在收到切换命令前已经发送了上行数据),源gNB需要等到UE确认已离开后再精确统计SN状态。对于AM DRB,准确的SN状态传递是实现零丢包切换的关键。
Q3: 切换失败后UE如何恢复?
A: 如果T304超时(UE未能成功接入目标小区),UE会发起RRC Connection Re-establishment(TS 38.331 Section 5.3.7)。UE选择一个合适的小区(可能是源小区或其他小区),发送RRCReestablishmentRequest,携带physCellId和shortMAC-I。网络侧验证通过后恢复连接。如果重建立也失败,UE进入RRC_IDLE态。
Q4: CHO中多个候选目标同时准入成功,UE如何选择? A: UE根据CHO配置中的执行条件(execution condition,通常是A3事件参数)逐一评估候选小区。当第一个满足执行条件的候选小区被确认后,UE立即向该小区发起接入。不会同时接入多个目标,这是CHO的"先到先得"机制。
Q5: 数据转发中"End Marker"的作用是什么? A: End Marker是GTP-U层面的标记包,由UPF发送。当路径切换完成后,UPF向源gNB侧隧道发送End Marker,源gNB收到后将End Marker通过Xn-U转发给目标gNB。目标gNB收到End Marker后,知道从源gNB转发的数据已全部接收完毕,此后仅从NG-U接收下行数据。这避免了目标gNB向UE乱序发送数据的问题。
本文由「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 等场景全覆盖。
