5G Xn切换SN状态转移与PDCP无缝衔接信令拆解

引言：为什么Xn切换是无损切换的基石

在5G NR网络中，Xn接口连接两个相邻gNB，为UE在gNB间移动提供了不经过核心网的直接切换通道。与N2切换（需经AMF中转）不同，Xn切换将切换决策和准备阶段完全局限在接入网内，AMF仅在最后的路径切换阶段才被通知。这一架构选择带来了一个关键问题：当UE从源gNB切换到目标gNB时，PDCP层的序列号（PDCP SN）和超帧号（HFN）如何无缝传递，以保证AM承载的无损传输和按序投递？

答案就是XnAP协议中的SN Status Transfer过程——一个看似简单却承载着PDCP状态连续性全部重量的Xn消息。本文将基于TS 38.423、TS 38.323和TS 23.502，深度拆解这一机制的每一个字节和每一个设计决策。

一、Xn切换整体架构与触发条件

1.1 Xn切换 vs N2切换：核心架构差异

设计意图：Xn切换优先于N2切换，因为直达路径减少了信令往返时延。只有当Xn接口不可用（不同厂商设备未建立Xn、跨PLMN、Xn链路故障）时，才回退到N2切换。

1.2 Xn切换触发条件

根据TS 38.300 Section 9.3.2，Xn切换的触发条件包括：

• 同频切换（Intra-frequency）：UE上报测量报告，源gNB决定切换到同频邻区
• 异频切换（Inter-frequency）：源gNB通过A4/A5事件触发异频切换
• 负载均衡触发：OAM配置的负载迁移
• 前提条件检查：
• 源gNB与目标gNB之间存在活跃的Xn接口
• UE的PDU Session对应的AMF和SMF在切换后不变（Intra-AMF/Intra-SMF）
• 目标gNB属于相同PLMN

二、Xn切换四阶段完整信令时序

以下是完整的Xn切换信令流程，涵盖切换准备、执行、SN状态转移和路径切换四个阶段。

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

    Note over UE,Src: 阶段1: 切换准备
    UE->>Src: Measurement Report<br/>(RSRP/RSRQ of neighbor cells)
    Src->>Src: 切换决策: 选择目标小区<br/>检查Xn接口可用性
    Src->>Tgt: XnAP: HANDOVER REQUEST<br/>[UE Context + PDU Session Resource List<br/>+ DRB QoS Info + Security Context]
    Tgt->>Tgt: 准入控制(Admission Control)<br/>DRB配置 + QoS Flow映射
    Tgt->>Src: XnAP: HANDOVER REQUEST ACKNOWLEDGE<br/>[RRC Reconfig Container<br/>+ DL Forwarding TEID + UL Forwarding TEID]

    Note over UE,Src: 阶段2: 切换执行
    Src->>UE: RRC Reconfiguration<br/>(包含HO Command)
    Note over UE: 同步到目标小区<br/>Random Access Preamble
    UE->>Tgt: MSG3: RRC Reconfiguration Complete

    Note over Src,Tgt: 阶段3: SN状态转移与数据转发
    Src->>Tgt: XnAP: SN STATUS TRANSFER<br/>[DL COUNT + UL COUNT<br/>+ UL Receive Status Bitmap]
    Src->>Tgt: GTP-U: Data Forwarding<br/>(DL PDCP PDUs)

    Note over Tgt,UPF: 阶段4: 路径切换
    Tgt->>AMF: NGAP: PATH SWITCH REQUEST<br/>[Source AMF UE NGAP ID<br/>+ PDU Session Path Switch List]
    AMF->>SMF: Nsmf_PDUSession_UpdateSMContext Req
    SMF->>UPF: N4 Session Modification<br/>(更新DL F-TEID指向目标gNB)
    UPF->>SMF: N4 Session Modification Response
    SMF->>AMF: Nsmf_PDUSession_UpdateSMContext Resp
    AMF->>Tgt: NGAP: PATH SWITCH REQUEST ACK
    Tgt->>Src: XnAP: UE CONTEXT RELEASE
    Src->>Src: 释放UE上下文和转发隧道

关键步骤解析

步骤1-4（准备阶段）：源gNB基于UE测量报告做出切换决策，通过Xn接口直接向目标gNB发送HANDOVER REQUEST。目标gNB执行准入控制，为每个DRB分配资源并映射QoS Flow。

步骤5-7（执行阶段）：源gNB向UE发送包含目标小区配置的RRC Reconfiguration消息。UE完成随机接入过程并同步到目标小区。

步骤8-9（SN状态转移）：这是本文的核心——源gNB在停止调度UE后，立即向目标gNB发送SN STATUS TRANSFER消息，随后开始数据转发。

步骤10-15（路径切换）：目标gNB通过N2接口通知AMF路径切换，AMF协调SMF和UPF将下行数据路径从源gNB切换到目标gNB。

三、SN STATUS TRANSFER消息深度解析

3.1 消息结构

根据TS 38.423 Section 9.1.1.4，SN STATUS TRANSFER消息的ASN.1结构如下：

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["SRBs Subject to Status Transfer List<br/>(Rel-18新增)"]

    D --> F["DRB ID"]
    D --> G["DL COUNT Value"]
    D --> H["UL COUNT Value"]
    D --> I["UL Receive Status of PDCP SDUs<br/>(Bitmap)"]
    D --> J["DL Deliver PDCP SN Status<br/>(Rel-18可选)"]

    G --> G1["PDCP SN (12/18 bit)"]
    G --> G2["HFN"]

    H --> H1["PDCP SN (12/18 bit)"]
    H --> H2["HFN"]

    I --> I1["Bitmap: 指示已成功接收<br/>的乱序UL PDCP SDU"]

    E --> E1["SRB ID"]
    E --> E2["SRB DL COUNT Value"]
    E --> E3["SRB UL COUNT Value"]

3.2 关键IE参数详解

3.3 COUNT值的精确含义

PDCP COUNT是PDCP层最核心的状态变量，由32位组成：低12位（或18位）为PDCP SN，高20位（或14位）为HFN。

COUNT (32 bit) = HFN (20/14 bit) | PDCP SN (12/18 bit)

DL COUNT Value的设计语义： - 该值 = 源gNB已转发给目标gNB的最后一个PDCP PDU的COUNT + 1 - 目标gNB从该COUNT值开始发送新的DL PDCP PDU - 目标gNB对转发的PDCP PDU按COUNT排序后按序投递

UL COUNT Value的设计语义： - 该值 = 源gNB期望收到的下一个UL PDCP SDU的COUNT - 目标gNB用该值初始化UL接收窗口 - 小于该COUNT的UL PDCP SDU被视为重复而被丢弃

3.4 UL Receive Status Bitmap的工作原理

这是SN Status Transfer中最精巧的IE。当源gNB已接收到一些乱序的UL PDCP SDU时，需要通知目标gNB这些PDU的状态，以避免目标gNB重复请求。

UL Receive Status Bitmap示例（12-bit SN模式）：

SN=100: 已接收 ✓ → Bit[0] = 1
SN=101: 未接收 ✗ → Bit[1] = 0
SN=102: 已接收 ✓ → Bit[2] = 1
SN=103: 已接收 ✓ → Bit[3] = 1
...

Bitmap覆盖范围：从UL COUNT Value指示的SN开始，覆盖一个完整的SN周期（4096或262144个SN），每个bit对应一个SN。

设计意图：目标gNB收到该Bitmap后，可以： 1. 对于标记为"已接收"的PDCP SDU，直接投递给上层（如果尚未投递） 2. 对于标记为"未接收"的PDCP SDU，等待UE重传 3. 当所有缺失的UL PDCP SDU都收到后，按序投递给上层

四、PDCP重建立与SN保持机制

4.1 切换场景下的PDCP行为

根据TS 38.323 Section 5.5，Xn切换时PDCP层的行为取决于DRB的RLC模式：

stateDiagram-v2
    [*] --> 源gNB正常传输: UE处于RRC_CONNECTED
    源gNB正常传输 --> PDCP_Suspend: 收到HO Command
    PDCP_Suspend --> PDCP_Reestablishment: 目标gNB收到<br/>SN STATUS TRANSFER
    PDCP_Reestablishment --> 恢复DL传输: 目标gNB用<br/>新COUNT继续
    PDCP_Reestablishment --> 恢复UL接收: 目标gNB用<br/>UL Receive Status<br/>处理乱序PDU
    恢复DL传输 --> 正常传输: 转发数据发送完毕
    恢复UL接收 --> 正常传输
    正常传输 --> [*]

4.2 AM DRB无损切换的精确流程

对于AM DRB（这是最常见的数据承载类型），无损切换的完整流程如下：

在源gNB侧：

1. 停止DL发送：源gNB不再为该UE调度新的DL PDCP PDU
2. 缓存状态处理： - 已发送但未收到RLC ACK的PDCP SDU → 通过转发隧道发送给目标gNB（带原始PDCP SN） - 尚未发送的PDCP SDU → 也通过转发隧道发送给目标gNB
3. 生成SN Status Transfer： - DL COUNT Value = 下一个要发送的PDCP PDU的COUNT - UL COUNT Value = 下一个期望收到的UL COUNT - UL Receive Status Bitmap = 已收到的乱序UL PDU的状态
4. 发送SN Status Transfer到目标gNB

在目标gNB侧：

1. 初始化PDCP实体： - DL发送：从SN Status Transfer中的DL COUNT Value开始编号 - UL接收：从UL COUNT Value开始构建接收窗口
2. 处理转发数据： - 将源gNB转发的DL PDCP SDU按COUNT值排序 - 按序投递给上层
3. 处理UL数据： - 收到UE的UL PDCP PDU后，对照UL Receive Status Bitmap - 如果该SN已被标记为"已接收"（在源gNB侧已投递），则丢弃 - 如果是新SN，正常处理
4. 当所有缺口填补后，恢复正常的按序投递

4.3 加密与完整性保护的连续性

Xn切换时，安全密钥需要刷新但COUNT值保持连续：

目标gNB的密钥派生：
K_gNB* = KDF(K_AMF, "gNB", PCI_target, ARFCN_target)
K_RRC_enc* = KDF(K_gNB*, "RRC_enc", algorithm_id)
K_UP_enc* = KDF(K_gNB*, "UP_enc", algorithm_id)

关键点：虽然密钥刷新了，但PDCP COUNT不归零。这是因为： - COUNT连续性防止了PDCP层的重放攻击 - 新密钥 + 旧COUNT的组合确保了加密流不重复 - 如果COUNT归零，在相同密钥下会出现密钥流重复，违反安全性

五、数据转发：Early vs Late两种模式

5.1 两种数据转发模式

根据TS 38.423 Section 8.2.1，Xn切换支持两种数据转发模式：

flowchart LR
    subgraph Early Forwarding
        A1[源gNB发送HO Request<br/>携带EARLY FORWARDING标志] --> A2[目标gNB分配<br/>Early Forwarding TEID]
        A2 --> A3[源gNB收到HO Request Ack前<br/>即开始转发DL数据]
    end

    subgraph Late Forwarding
        B1[源gNB发送HO Request] --> B2[目标gNB回复<br/>HO Request Ack<br/>携带Forwarding TEID]
        B2 --> B3[源gNB收到Ack后<br/>开始转发DL数据]
    end

5.2 数据转发隧道的GTP-U结构

数据转发通过Xn-U接口的GTP-U隧道实现：

转发DL PDCP PDU的GTP-U封装：
┌─────────────────────────────────────────┐
│  Outer IP Header (源gNB IP → 目标gNB IP) │
├─────────────────────────────────────────┤
│  Outer UDP Header                        │
├─────────────────────────────────────────┤
│  GTP-U Header                            │
│  ├── TEID = 目标gNB分配的转发TEID        │
│  ├── Sequence Number (可选)              │
│  └── Extension Header (PDCP PDU Number)  │
├─────────────────────────────────────────┤
│  PDCP PDU (带原始PDCP SN)               │
│  ├── PDCP Header (SN = 原始序列号)       │
│  ├── Payload (加密后的用户数据)          │
│  └── MAC-I (完整性保护校验)              │
└─────────────────────────────────────────┘

设计要点： - 转发的PDCP PDU保持原始的PDCP SN，目标gNB不重新编号 - 目标gNB根据PDCP SN进行排序后按序投递 - GTP-U Extension Header中可携带PDCP PDU Number，用于辅助排序

六、路径切换阶段的信令细节

6.1 PATH SWITCH REQUEST消息

SN Status Transfer和数据转发完成后，目标gNB需要通知核心网更新数据路径。根据TS 38.413 Section 8.9.1，PATH SWITCH REQUEST消息包含：

6.2 SMF与UPF的N4会话修改

AMF收到PATH SWITCH REQUEST后，向SMF发送PDU Session Update SM Context Request。SMF执行以下操作：

1. N4 Session Modification：通知UPF将DL F-TEID更新为目标gNB的地址
2. UPF建立新隧道：UPF开始在新的N3隧道上向目标gNB发送DL数据
3. End Marker机制：UPF在旧隧道上发送End Marker标记，通知源gNB数据流结束
4. Multi-UPF场景：如果涉及I-UPF（Intermediate UPF），SMF可能需要插入或替换UPF

End Marker的重要性：End Marker是一个特殊的GTP-U数据包，标记旧数据路径的结束。源gNB收到End Marker后，可以安全地知道所有DL数据已经转发完毕，并释放转发隧道。

6.3 路径切换后的资源释放

目标gNB收到PATH SWITCH REQUEST ACKNOWLEDGE后，向源gNB发送UE CONTEXT RELEASE消息（XnAP），源gNB释放： - UE的RRC上下文 - DRB和SRB配置 - Xn-U数据转发隧道 - 源gNB本地缓存的PDCP PDU

七、抓包识别与故障排查

7.1 Wireshark抓包识别Xn切换

Xn切换涉及两个接口的抓包：

Xn-U数据转发识别特征： - GTP-U TEID与正常N3隧道的TEID不同 - 转发数据包的目的IP为目标gNB的Xn-U地址 - 数据包携带PDCP PDU Number Extension Header

7.2 常见故障点与排错思路

8.1 Conditional Handover (CHO)

Rel-16引入的CHO允许UE在满足特定条件时自主执行切换，无需等待源gNB的HO Command。这对SN Status Transfer的影响：

• SN Status Transfer时机变化：源gNB在发送CHO配置时就准备好SN Status，但不立即发送，而是在检测到UE离开后才发送
• 多候选目标gNB：源gNB需要为每个候选目标gNB准备独立的转发隧道和SN Status
• UE自主选择目标：UE可能选择任意候选gNB，源gNB需要通过Xn信令或N2通知确定UE最终选择

8.2 DAPS Handover

Rel-16引入的Dual Active Protocol Stack (DAPS) handover允许UE在切换期间同时保持与源gNB和目标gNB的连接：

• SN Status Transfer延迟发送：DAPS场景下，源gNB继续为UE服务一段时间，SN Status Transfer在源gNB释放连接时才发送
• 数据分流：源gNB和目标gNB同时为UE提供DL数据
• 无中断切换：DAPS的目标是实现0ms中断的切换，SN Status Transfer的时机更加灵活

九、SN Status Transfer vs N2 RAN Status Transfer对比

常见问题

Q1: SN Status Transfer只适用于AM DRB吗？

A: 不是。SN Status Transfer主要针对AM DRB，因为AM承载需要无损和按序投递。但对于UM DRB，源gNB也可以选择性地发送SN Status Transfer（TS 38.423 Section 8.2.2.1说明为"may"），主要用于减少目标gNB侧的PDCP重排序窗口混乱。SRB的SN Status Transfer是Rel-18新增功能。

Q2: 如果SN Status Transfer消息丢失会怎样？

A: XnAP基于SCTP传输，保证了消息的可靠交付。但如果Xn接口发生SCTP关联中断，SN Status Transfer确实会丢失。此时目标gNB将无法正确初始化PDCP接收/发送状态，可能导致：AM DRB的DL数据从COUNT=0重新开始（触发PDCP重建立恢复过程），UL数据可能产生重复投递。严重情况下可能导致PDU Session异常释放，触发UE重新建立PDU Session。

Q3: Xn切换时UPF侧的DL数据会不会短暂中断？

A: 会有短暂中断。在路径切换完成前，UPF仍然向源gNB发送DL数据。源gNB通过Xn-U转发隧道将这些数据转发给目标gNB。路径切换（N4 Session Modification）完成后，UPF直接向目标gNB发送数据。在路径切换的过渡期间（约10-50ms），DL数据依赖转发隧道维持连续性。End Marker标记确保了新旧路径的无缝切换。

Q4: PDCP SN长度在切换过程中能改变吗？

A: 不能。TS 38.323明确规定，PDCP SN长度（12-bit或18-bit）在切换过程中不能改变。如果源gNB使用12-bit SN，目标gNB必须使用相同的12-bit SN。这是因为在SN Status Transfer中，COUNT值（包括SN和HFN）必须连续。如果SN长度改变，COUNT的位结构将不一致，导致PDCP无法正确解密和重排序。

Q5: Xn切换支持跨PLMN吗？

A: 不支持。Xn切换要求源gNB和目标gNB属于同一PLMN。跨PLMN场景（如漫游场景下的PLMN切换）必须使用N2切换，因为N2切换通过核心网（AMF）进行协调，支持跨PLMN的会话迁移。

参考来源

1. 3GPP TS 38.423 V18.x.x — Xn Application Protocol (XnAP) — Section 8.2.2 SN Status Transfer, Section 9.1.1.4 Message Definition
2. 3GPP TS 23.502 V19.x.x — Procedures for the 5G System — Section 4.9.1.2 Xn-based Handover
3. 3GPP TS 38.323 V18.x.x — PDCP Specification — Section 5.5 PDCP Re-establishment
4. 3GPP TS 38.300 V18.x.x — NR Overall Description — Section 9.3.2 Handover Procedures
5. free5GC Blog — Introduction of Xn and N2 based handover — Xn/N2 handover流程对比分析

本文由「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 等场景全覆盖。