首页 › protocols › 5G Xn接口切换信令全链拆解

5G Xn接口跨gNB切换信令全链拆解

在5G SA网络中，终端（UE）在CM-CONNECTED状态下从一个gNB移动到另一个gNB时，核心网与无线接入网之间会执行一次完整的"控制面重组+用户面改道"。前序文章已系统拆解过基于N2接口的NG切换（TS 23.502 4.9.1.3），本文聚焦其"姊妹机制"——基于Xn接口的切换（TS 23.502 Clause 4.9.1.2 / TS 38.423 XnAP / TS 38.413 NGAP）。两者最本质的差异在于：Xn切换在"准备阶段"完全旁路5GC，由源/目标gNB在Xn-C上直接握手完成资源预留与切换命令的协商，AMF只有在最后的"路径切换"阶段才被目标gNB通知。这一设计直接决定了Xn切换的低时延特性，也带来了一些N2切换所没有的关键机制——数据前转（Data Forwarding）、SN状态传递（SN STATUS TRANSFER）、以及目标gNB主动发起的PATH SWITCH REQUEST。本文按照"准备→执行→完成"三阶段、逐消息、逐IE拆解整条信令链。

一、设计原理：为什么让gNB"绕开"AMF做切换

3GPP在TS 23.502 4.9.1.2开宗明义地规定了Xn切换的前提条件：

UE处于CM-CONNECTED状态；
源gNB与目标gNB之间存在可用的Xn接口（Xn-C + Xn-U）；
源gNB根据UE的测量报告（MR）判决"基于Xn的切换"可行（典型判据：目标在同一AMF服务区、无需变更AMF、且两gNB间Xn链路健康）。

满足上述条件时，源gNB不必把切换请求经N2上送给AMF、再由AMF经N2下发给目标gNB这条"两跳"路径，而是直接在Xn-C上发起HANDOVER REQUEST。这条优化路径把准备阶段的信令往返时延从"两次N2往返"压缩到"一次Xn往返"，是高铁、密集城区等高速移动场景下保持业务连续性的关键。

代价是：源gNB必须自行承担准入决策信息的封装——它要把SMF在会话建立时下发的QoS流描述、安全上下文（NH、下一跳链计数器）、UE的RRC上下文（DRX周期、能力、历史信息）等，全部"打包"进XnAP消息透传给目标gNB。这就是为什么HANDOVER REQUEST的IE结构如此庞大。

二、三阶段信令全链时序图

下图把一条完整的Xn切换从测量上报一直画到源gNB资源释放，涵盖控制面（Xn-C/NG-C/N2）与用户面（Xn-U/N3）的耦合关系：

sequenceDiagram
    participant UE
    participant Src as 源gNB
    participant Tgt as 目标gNB
    participant AMF
    participant SMF
    participant UPF

    Note over UE,UPF: === 准备阶段 Preparation（Xn-C，旁路5GC）===
    UE->>Src: Measurement Report（含目标小区PCI/RSRP）
    Src->>Src: HO决策：Xn可行？（Xn健康+同AMF区）
    Src->>Tgt: XnAP HANDOVER REQUEST<br/>(UE-XnAP-ID-src, PDU Session Res To Setup,<br/>Security Context, RRC Container, DRX, UE History)
    Tgt->>Tgt: 准入控制 Admission Control
    Tgt-->>Src: XnAP HANDOVER REQUEST ACKNOWLEDGE<br/>(UE-XnAP-ID-tgt, RRC Container=HO Command,<br/>DL/UL Forwarding TNL Info)

    Note over UE,UPF: === 执行阶段 Execution ===
    Src->>UE: RRC Reconfiguration（reconfigurationWithSync = HO Command）
    Note right of UE: T304启动；UE开始向目标随机接入
    Src->>Tgt: XnAP SN STATUS TRANSFER<br/>(每个DRB的上/下行PDCP SN+HFN)
    Src->>Tgt: Xn-U 下行数据前转 DL Forwarding（GTP-U）
    Tgt-->>Tgt: 缓存前转数据，待UE同步后按序发送
    UE->>Tgt: 随机接入 Msg1/Msg2（或2-step MsgA/MsgB）
    UE->>Tgt: RRC Reconfiguration Complete
    Note over UE,UPF: UE业务面已锚定在目标gNB，但N3仍指向源gNB

    Note over UE,UPF: === 完成阶段 Completion（NG-C/N2，5GC介入）===
    Tgt->>AMF: NGAP PATH SWITCH REQUEST<br/>(RAN-UE-NGAP-ID, Source AMF UE NGAP ID,<br/>PDU Session Res To Be Switched DL List,<br/>新 DL N3 UP TNL Info)
    AMF->>SMF: Nsmf_PDUSession_UpdateSMContext（目标侧）
    SMF->>UPF: N4 Session Modification Request<br/>(更新 DL F-TEID → 目标gNB N3；触发End Marker)
    UPF-->>Src: End Marker（旧N3下行链路，标记流尾）
    Note over UPF,Src: 源gNB收到End Marker后停止前转
    UPF->>Tgt: DL数据走新N3隧道
    SMF-->>AMF: 响应（含新UL N9 TNL等）
    AMF-->>Tgt: NGAP PATH SWITCH REQUEST ACKNOWLEDGE
    Tgt->>Src: XnAP UE CONTEXT RELEASE
    Note over Src: 释放源gNB的UE上下文与空口资源

整条链路的关键转折点在第10步PATH SWITCH REQUEST：在此之前，UE的用户面下行数据其实还在走"UPF→源gNB→（Xn-U前转）→目标gNB→UE"这条迂回路径，只有当目标gNB拿到Path Switch Ack后，N3隧道才正式锚定到目标gNB，迂回被消除。理解这一点，是理解Xn切换所有异常现象的钥匙。

三、准备阶段：XnAP消息与关键IE拆解

3.1 HANDOVER REQUEST（XnAP，TS 38.423 §9.1.1）

这是整个流程中信息密度最高的一条消息。源gNB必须把"目标gNB为UE建立一切所需上下文"的素材一次性凑齐：

IE 名称	含义	设计意图
`Source UE-XnAP-ID`	源gNB内标识UE的XnAP ID	Xn-C上后续消息回链用，目标gNB需建立配对
`Cause`	切换原因（如 `ho-rn`/无线原因）	便于网管统计与目标侧策略
`UE Security Capabilities`	NR/UTRA等加解密算法能力集	目标侧必须按此选择算法（受限算法集时降级）
`Security Context`	含 `nextHopChainingCount`(NCC)与 `K~NG-RAN~*`/NH	目标gNB据此派生自己的 `K~gNB~`，避免回5GC取密钥
`RRC Container`（source-to-target）	透传的RRC上下文容器	把AS层细节封装透传，避免XnAP重新定义RRC语义
`PDU Session Resource To Setup List`	每条PDU会话的QoS流、TNL、PDU类型等	目标侧准入与DRB建立的核心输入
`DRX Cycle`	UE当前DRX参数	目标gNB寻呼/重配时必须沿用，否则UE收不到
`UE History Information`	UE最近访问的小区列表	目标侧用于移动性优化、负载与乒乓抑制
`Masked IMEISV`	脱敏后的终端型号	目标侧差异化准入门道（仅特定场景）

其中安全上下文是Xn切换能旁路AMF的"通行证"。源gNB持有NH（Next Hop）与NCC，按TS 33.501的横向/纵向密钥派生，把派生参数交给目标gNB，目标gNB本地即可算出K~gNB~，全程无需UDM/ARPF/AUSF参与。这把鉴权链路完全排除在切换之外。

3.2 HANDOVER REQUEST ACKNOWLEDGE / PREPARATION FAILURE

目标gNB执行准入控制（检查切片资源、PRB、SRI、PDCP资源、传输带宽）后，回送：

准入成功：HANDOVER REQUEST ACKNOWLEDGE，内含：
Target UE-XnAP-ID（建立ID配对）；
RRC Container：目标gNB生成的切换命令RRC容器（即RRCReconfiguration，内嵌reconfigurationWithSync），由源gNB原封不动透传给UE；
PDU Session Resource Admitted List：成功准入的会话/流；
DL Forwarding TNL Info / UL Forwarding TNL Info：前转隧道的GTP-U TEID——这是数据无损切换的命脉；
可能携带 PDU Session Resource Failed to Setup List（部分失败）。
准入失败：HANDOVER PREPARATION FAILURE，携带Cause（典型值 radio-resources-not-available、tnl-failure、unknown-PDU-session-ID、slice-not-supported）。源gNB可据此回退重选目标小区或升级为N2切换。

3.3 准入决策判断流程

源gNB在收到测量报告后，并非"看到强小区就切"。其判决逻辑大致如下：

flowchart TD
    A[收到MR，候选目标小区列表] --> B{与目标gNB存在健康Xn?}
    B -- 否 --> Z[走N2/NG切换流程]
    B -- 是 --> C{目标在源AMF服务区内?}
    C -- 否 --> Z
    C -- 是 --> D{目标小区支持UE当前切片/S-NSSAI?}
    D -- 否 --> Z
    D -- 是 --> E{目标小区信号质量优于源小区<br/>且满足迟滞/触发时间TimeToTrigger?}
    E -- 否 --> F[保持当前小区，更新候选列表]
    E -- 是 --> G[发起XnAP HANDOVER REQUEST]
    G --> H{收到ACK or FAILURE?}
    H -- FAILURE --> I{Cause是否可重试?}
    I -- 是 --> J[重选次优目标]
    I -- 否 --> Z
    J --> G
    H -- ACK --> K[进入执行阶段]

注意图中TimeToTrigger（TTT）与迟滞（Hys）的配合是抑制乒乓切换的关键；slice-not-supported类Cause会强制回退到N2切换——这是切片部署早期最常见的"Xn切不动"原因。

四、执行阶段：RRC切换命令、SN状态传递与数据前转

4.1 RRC Reconfiguration（含reconfigurationWithSync）

源gNB收到ACK后，向UE发送RRCReconfiguration，其中关键域是reconfigurationWithSync——这就是俗称为"切换命令"（HO Command）的部分：

flowchart TD
    subgraph RRC[RRCReconfiguration 消息结构]
        direction TB
        R1[reconfigurationWithSync<br/>= 切换命令]
        R2[其它 radioBearerConfig /<br/>secondaryCellGroup 等]
    end
    subgraph SYNC[reconfigurationWithSync 内容]
        direction TB
        S1[spCellConfigCommon<br/>目标小区公共配置:<br/>SSB位置/TDD UL-DL配置/PRACH]
        S2[spCellConfig<br/>目标小区UE专属配置:<br/>TA/新C-RNTI/TC-RNTI]
        S3[reconfigurationWithSync<br/>里的 masterCellGroup]
    end
    R1 --> SYNC

UE收到后启动定时器T304，并按spCellConfig中给出的新C-RNTI/TC-RNTI、定时提前（TA）等参数，向目标小区发起随机接入。若T304超时尚未在目标同步成功，UE执行切换失败回退（RRC连接重建或回到源小区配置）。

4.2 SN STATUS TRANSFER 与无缝数据前转

这是Xn切换区别于N2切换的第二个独有机制。源gNB在停止向UE发送下行、停止从UE接收上行后，立即在Xn-C上发送SN STATUS TRANSFER（TS 38.423 §9.1.5），对每一个保留PDCP的DRB传递：

下行：下一个待发送PDCP SDU的PDCP SN与超帧号HFN，以及"已收到UE确认的最高上行PDCP SN"；
上行：期望从UE收到的下一个PDCP SN。

目标gNB据此：丢弃源侧已发送但未确认的重复包、按SN续传、对乱序到达的上行重排序。配合Xn-U数据前转隧道（其TEID来自HO ACK），源gNB把所有"已从N3收到、但尚未发给UE"的下行PDCP SDU逐包前转给目标gNB。两者结合，实现切换期间用户面零丢包（对RLC AM承载）/低丢包（对UM）。

下表对比前转方向与触发：

前转类型	方向	触发时机	终止条件
DL Forwarding	源gNB→目标gNB（Xn-U）	收到HO ACK后立即开始	源gNB从旧N3收到End Marker
UL Forwarding	源gNB→目标gNB（Xn-U）	可选，目标gNB在HO ACK中请求	Path Switch Ack后或源gNB上行缓冲清空
End Marker	UPF→源gNB（旧N3）	SMF经N4指示UPF切换DL F-TEID时触发	单条GTP-U标记，无净荷

End Marker的本质是"用户面栅栏"——它告诉源gNB"5GC已经把DL切换走了，你再不会从旧N3收到任何业务包，可以安全停止前转"。没有End Marker，源gNB的前转隧道无法正常关闭，这是排错时一个高频盲点。

五、完成阶段：PATH SWITCH REQUEST 全链

5.1 NGAP PATH SWITCH REQUEST（TS 38.413 §8.2）

目标gNB在UE成功同步并完成RRCReconfigurationComplete后，主动在N2接口向AMF发起PATH SWITCH REQUEST。注意这条消息虽由切换触发，但它本身是NGAP消息（走N2/SCTP 38412）而非XnAP，这是初学者最易混淆之处。其核心IE：

IE	含义
`Source AMF UE NGAP ID`	UE在源侧的N2标识，让AMF定位已有UE上下文
`RAN UE NGAP ID`	目标gNB新建的N2标识
`PDU Session Resource To Be Switched in Downlink List`	待切换的会话列表，每条含 `PDU Session ID` + `Path Switch Request Transfer`容器（内含新的DL N3 UP TNL Information = 目标gNB的N3 TEID+IP）
`PDU Session Resource Failed to Setup List`	目标侧未能建立的会话
`User Location Information`	UE当前TAI/NCGI，用于5GC更新位置
`UE Presence in Area of Interest`（R17+）	UE是否处于关注的区域，触发区域业务策略

5.2 N4会话改道与End Marker注入

AMF收到后，按每条PDU会话调用Nsmf_PDUSession_UpdateSMContext通知SMF；SMF经N4向UPF发送N4 Session Modification Request，把下行F-TEID从源gNB的N3地址改写为目标gNB的N3地址，并指示UPF在切换点向旧下行路径发送End Marker。此后：

UPF新收到的DL业务 → 直送目标gNB N3 → UE；
旧N3路径上的End Marker → 源gNB → 源gNB据此停止前转、释放Xn-U前转隧道；
SMF把新的上行N9 TNL（若UPF未变则不变）回给AMF；
AMF回送PATH SWITCH REQUEST ACKNOWLEDGE，可携带"切换失败的会话列表"用于异常处理。

5.3 资源释放

目标gNB收到Ack后，在Xn-C上向源gNB发送UE CONTEXT RELEASE（TS 38.423 §9.1.8），源gNB据此释放全部UE上下文、空口与Xn-U资源。整条Xn切换至此闭合。

六、Xn切换 vs N2切换：核心差异对照

维度	Xn-based Handover（4.9.1.2）	N2/NG-based Handover（4.9.1.3）
准备阶段信令面	Xn-C（gNB↔gNB直连）	NG-C/N2（经AMF两跳）
5GC在准备阶段是否介入	否（旁路）	是（AMF转发HO Request/Required）
AMF角色	仅完成阶段收Path Switch Request	全程参与，可能触发AMF Relocation
目标侧完成信号	目标gNB发 Path Switch Request	目标gNB发 Handover Notify
N3用户面	直接从源gNB-N3锚点迁到目标gNB-N3	由AMF/SMF协调，N3路径可重新规划
UPF是否可能变更	通常不变更（锚点UPF保持）	可能涉及UPF重定位（如远端会话迁移）
时延特性	低（一跳Xn往返）	较高（两跳N2往返）
适用前提	Xn可达 + 同AMF服务区	跨AMF、Xn不可达、或需重选5GC节点
数据前转	DL/UL Forwarding + End Marker	同样支持，但前转路径规划更灵活

一句话总结：Xn切换是把"控制面"的AMF环节压到最小，让gNB自治完成切换；N2切换则是把"控制面"完整交还5GC，以换取对跨节点、跨UPF场景的灵活性。 网络中两者并存，由源gNB按链路可达性自动选择。

七、关键定时器与状态机

stateDiagram-v2
    [*] --> RRC_CONNECTED: 业务/信令激活
    RRC_CONNECTED --> HO_Preparation: MR触发，Xn可行
    HO_Preparation --> HO_Executing: 收到HO ACK，下发HO Command<br/>启动T304
    HO_Preparation --> RRC_CONNECTED: HO Preparation Failure<br/>回退
    HO_Executing --> HO_Completing: UE在目标RRC Reconfig Complete
    HO_Executing --> HO_Failed: T304超时（未同步）
    HO_Completing --> RRC_CONNECTED: Path Switch Ack + UE Context Release
    HO_Failed --> RRC_Reestablishment: 触发RRC重建
    RRC_Reestablishment --> RRC_CONNECTED: 重建成功
    RRC_Reestablishment --> RRC_IDLE: 重建失败

定时器	位置	作用	超时后果
T304	UE侧	限制UE在新小区完成同步的时间	切换失败，触发RRC重建或回退
T310/T311	UE侧	RRC连接重建相关	不在本流程核心，但与失败回退衔接
源gNB前转守护	源gNB	等待End Marker后停前转	收不到End Marker会持续前转/泄漏隧道
Path Switch响应守护	目标gNB	等待AMF的Ack	超时按失败处理，可能保留用户面+上报告警

八、抓包识别与故障排错实战

8.1 在Wireshark/TShark中识别

Xn-C信令：SCTP，端口36422，过滤 sctp.port==36422 && xnap；
Xn-U数据：GTP-U，过滤 gtp.teid == <前转TEID>；
N2信令：SCTP，端口38412，过滤 ngap.procedureCode==pathSwitchRequest（Procedure Code 39）或 ngap.rANPage；
End Marker：gtp.message_type==0xfe（End Marker，消息类型254）且方向UPF→源gNB。

一条典型Xn切换在抓包里表现为：XnAP Handover Request → Handover Request Ack → NGAP Path Switch Request → Path Switch Request Ack → XnAP UE Context Release。其中Path Switch Request始终走N2，这是判断"这到底是Xn切还是N2切"最硬的证据——只要看到Path Switch Request而非Handover Notify，就是Xn切换。

8.2 高频故障点与排查思路

故障现象	可能根因	排查方向
Xn切不出去，总走N2	Xn链路断/未配置；切片在目标不支持	查`HANDOVER PREPARATION FAILURE`的Cause；核查Xn链路与目标切片配置
准备阶段一直Failure	目标资源不足、TNL不通、S-NSSAI不匹配	看Cause值；`radio-resources-not-available`多为准入拒绝
UE切换后掉线（T304超时）	HO Command无法解析；目标RACH资源冲突；TA错误	核查`reconfigurationWithSync`是否完整下发；查目标PRACH/前导分配
切换后下行丢包/卡顿	End Marker未送达，前转隧道早关或晚关	抓包确认End Marker方向与时机；核对N4下发的DL F-TEID改写
Path Switch失败	N3新TEID配错；SMF拒绝；PDU会话状态异常	看SMF日志；确认`Path Switch Request Transfer`容器中的UP TNL
跨切片切换异常	目标小区未配置该S-NSSAI；NSAG/NSI限制	核查切片NSI可用性与UE订阅NSSAI
## 常见问题

Q1：Xn切换中，AMF到底什么时候才知道发生了切换？ A：只有在完成阶段。准备阶段和执行阶段AMF完全不参与；直到目标gNB向AMF发送PATH SWITCH REQUEST（携带Source AMF UE NGAP ID），AMF才"知道"UE已经换到新gNB，并据此更新UE的N2连接锚点。这也是Xn切换低时延的根本来源。

Q2：Path Switch Request为什么走N2而不走Xn？ A：因为路径切换的本质是"把5GC的下行N3隧道锚点改到目标gNB"，这件事只能由5GC（AMF→SMF→UPF经N4）完成，Xn接口触达不到UPF。目标gNB作为新锚点的"申请人"，必须经N2向AMF申请，AMF再调度SMF/UPF改写F-TEID。所以Xn切换是"准备阶段走Xn、完成阶段走N2"的混合流程。

Q3：数据前转（Data Forwarding）和End Marker是什么关系？源gNB怎么知道何时停止前转？ A：数据前转是源gNB通过Xn-U把"已从旧N3收到、还没发给UE"的下行包送给目标gNB的过程；End Marker是UPF在N3切换点向源gNB发送的一条GTP-U标记包（无净荷）。源gNB收到End Marker，就意味着"5GC的下行流已经彻底切到新N3了，旧N3不会再有业务包到来"，于是停止前转并释放前转隧道。没有End Marker，前转隧道无法安全关闭。

Q4：什么情况下源gNB会放弃Xn切换、改走N2切换？ A：三类典型场景：(1) 源/目标gNB间无健康Xn链路或Xn不可达；(2) 目标小区不在源AMF服务区，需AMF Relocation；(3) 准备阶段回送HANDOVER PREPARATION FAILURE且Cause指向需5GC协调（如slice-not-supported、unknown-target-AMF）。此时源gNB会回退到N2切换，由AMF主导准备。

Q5：Xn切换能否变更UPF锚点（即远端PDU会话迁移）？ A：标准Xn切换（4.9.1.2）不变更UPF锚点，N3隧道仅在两个gNB间迁移，UPF保持不变。如果业务需要变更UPF（如SSC模式3的会话连续性重锚定、或URllC下沉到边缘UPF），应使用N2切换配合UPF重定位，或专门的SSC模式3流程，而非普通Xn切换。

参考来源

3GPP TS 23.502 V18.x — System procedures for the 5G System, Clause 4.9.1.2 Handover procedures (Xn-based) — Xn切换标准流程定义与前提条件。
3GPP TS 38.423 V18.6.0 — NG-RAN; Xn Application Protocol (XnAP) — Handover Request/ACK、SN STATUS TRANSFER、UE CONTEXT RELEASE等消息与IE定义。
3GPP TS 38.413 V18.x — NG-RAN; NG Application Protocol (NGAP) — PATH SWITCH REQUEST 消息与Path Switch Request Transfer容器定义。
3glteinfo — 5G NR Xn Handover Procedure Call Flow 与 XnAP Handover Request Message — 信令流程与消息IE解读。
free5GC — Introduction of Xn and NG (N2) based handover — Xn/N2切换对比与N4会话改道实现分析。

本文由「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学通信知识星球海报-扫码加入