首页 › deep-tech › Xn与N2切换的信令博弈

Xn与N2切换：连接态移动性的信令博弈

一、从一个生活类比说起

想象你正在打一通重要的电话，一边走一边聊。当你从客厅走到玄关时，家里那台 Wi-Fi 路由器的信号开始变弱，但你楼上还有一台路由器信号很强。要做到"通话不中断"，你需要完成一件事：在断开旧连接之前（或几乎同时），把数据流无缝地搬到新的路由器上，而且搬的过程中既不能丢一个字、也不能重复一个字。

这就是移动通信里切换（Handover，HO）要解决的核心问题。只不过在蜂窝网络里，"路由器"换成了基站（gNB），"数据流"背后还牵涉到核心网、用户面隧道、加密计数器等一整套精密的机制。

理解切换，关键不在于背诵十几条信令的名字，而在于搞懂三件事：网络为什么要这样编排信令？数据怎么做到不丢不重？工程师在现场调问题时该看哪一步？ 本文就围绕这三点展开。

二、切换的本质：三阶段模型

在 4G/5G 协议里，无论哪种切换，都可以抽象成准备、执行、完成三个阶段。这套模型之所以重要，是因为它把"换基站"这件复杂的事拆成了三个相互独立、各司其职的环节，每个环节都有清晰的失败处理逻辑。

flowchart TD
    A[测量上报<br/>A3事件触发] --> B{切换决策}
    B --> C[阶段1: 准备<br/>Preparation]
    C --> C1[源gNB向目标gNB<br/>申请资源]
    C1 --> C2[目标gNB接纳控制<br/>分配无线资源]
    C2 --> C3[返回切换命令]
    C3 --> D[阶段2: 执行<br/>Execution]
    D --> D1[源gNB下发切换命令<br/>UE同步到目标小区]
    D1 --> D2[数据转发启动]
    D2 --> E[阶段3: 完成<br/>Completion]
    E --> E1[UE随机接入成功<br/>路径切换]
    E1 --> E2[源gNB释放<br/>UE上下文]
    style C fill:#e8f4f8,stroke:#2196F3
    style D fill:#fff3e0,stroke:#FF9800
    style E fill:#e8f5e9,stroke:#4CAF50

需要特别说明的是，切换决策本身不是切换流程的一部分。决策依赖于测量上报（比如你之前了解的 A1~A6 事件），当 UE 上报"目标小区比服务小区好 X dB"（A3 事件）时，源 gNB 才会触发准备阶段。换句话说，测量是"扳机"，而切换三阶段是"开枪后子弹飞行的全过程"。这一点很多初学者会混淆，以为测量事件属于切换流程——其实它只是入口。

三、Xn 切换 vs N2 切换：两条路的本质差异

5G 里基站之间的切换主要有两条路径：基于 Xn 接口的切换和基于 N2 接口（NGAP）的切换。理解它们的区别，本质上是理解"指挥权在谁手里"。

graph TB
    subgraph AMF域[核心网控制面]
        AMF[AMF]
    end
    subgraph 基站域[无线接入网]
        SG[源 gNB]
        TG[目标 gNB]
    end
    UE[UE]

    UE -.下行/上行.-> SG
    UE -.切换后.-> TG

    UE ---|路径1: Xn切换<br/>核心网基本不参与准备| SG
    SG ==>|Xn-C 直连信令| TG
    SG -.路径切换请求.-> AMF

    UE ---|路径2: N2切换<br/>AMF全程居中协调| SG
    SG -->|N2 上报 AMF| AMF
    AMF -->|N2 转发给目标| TG

    style SG fill:#bbdefb,stroke:#1976D2
    style TG fill:#c8e6c9,stroke:#388E3C
    style AMF fill:#ffe0b2,stroke:#F57C00

Xn 切换的核心思想是"放权"：当源基站和目标基站之间有 Xn 直连接口时，切换的准备阶段完全在两个基站之间完成，核心网的 AMF 只在最后的"路径切换"阶段被叫起来改一下数据隧道的方向。这样做的好处是信令路径短、延迟低——两个邻居基站商量一下就能把事办了，没必要事事上报"总部"。

N2 切换则是"集权"：当两个基站之间没有 Xn 接口（比如跨厂商、跨配置边界），或者属于不同的 AMF 服务区域时，源基站只能把"我要切换"这件事通过 N2 接口报告给 AMF，由 AMF 居中协调，把请求转发给目标基站，再把结果带回来。AMF 全程在场，信令要绕核心网一个来回，速度自然慢一些。

对比维度 Xn 切换 N2/NGAP 切换
信令接口 Xn-C（基站↔基站直连） N2（基站↔AMF）
准备阶段 AMF 是否参与 否，两基站直谈 是，AMF 居中转发
准备延迟 低（一跳直达） 较高（绕核心网往返）
适用场景 同厂商、有 Xn 链路 无 Xn、跨 AMF、跨厂商边界
数据路径切换信令 Path Switch Request（目标gNB→AMF） Handover Notify（目标gNB→AMF）
源基站释放 Xn 上的 UE Context Release N2 上的 UE Context Release Command
现网占比 绝大多数同区域切换 少数边界/特殊场景

记住一个直觉：网络总是优先尝试 Xn 切换，只有在 Xn 不可用时才"退而求其次"用 N2 切换。 这就好比公司内部调动，能部门之间直接协调的，就别走 HR 审批流程。

四、Xn 切换信令时序详解

下面是 Xn 切换的完整信令时序。请重点关注每一步"在解决什么问题"。

sequenceDiagram
    participant UE
    participant SG as 源 gNB
    participant TG as 目标 gNB
    participant AMF
    participant UPF

    UE->>SG: ① 测量上报 (Measurement Report)
    Note over SG: 切换决策成立
    SG->>TG: ② XnAP: Handover Request<br/>(UE上下文、QoS流、DRB配置)
    Note over TG: ③ 接纳控制 + 资源分配
    TG-->>SG: ④ XnAP: Handover Request Acknowledge<br/>(目标小区配置、转发隧道信息)
    SG->>TG: ⑤ XnAP: SN Status Transfer<br/>(每个DRB的PDCP COUNT)
    SG->>UE: ⑥ RRC Reconfiguration<br/>(含切换命令:目标PCI、C-RNTI)
    Note over UE: 断开源小区
    par 数据转发
        SG->>TG: ⑦ DL数据转发 (Xn-U隧道)
        UPF->>SG: 仍向源gNB下发下行数据
    end
    UE->>TG: ⑧ 随机接入 (msg1~msg3)
    UE->>TG: ⑨ RRC Reconfiguration Complete
    TG->>AMF: ⑩ Path Switch Request
    AMF->>UPF: ⑪ 切换N3隧道到目标gNB
    UPF->>TG: 下行数据直达目标gNB
    AMF-->>TG: ⑫ Path Switch Request Acknowledge
    TG->>SG: ⑬ XnAP: UE Context Release
    Note over SG: 释放UE上下文与转发隧道

逐条拆解几个关键设计意图：

五、SN 状态转移：切换为什么不丢包

很多人理解切换，停在"换了基站，业务继续"的层面就过去了。但真正决定"无缝"二字含金量的，是 SN（Sequence Number，序列号）状态转移。它解决的是一个看似不起眼却极为致命的问题：加密计数器不能断档。

在 5G 的 PDCP 层，每个数据包都有一个 32 位的 COUNT 值，它由 HFN（超帧号）和 SN（序列号）拼接而成：

$$ \text{COUNT} = \text{HFN} \times 2^{\text{SN_length}} + \text{SN} $$

COUNT 值同时承担两个职责：重排序（保证包按顺序递交，去重）和加解密（作为加密算法的输入计数器）。这就意味着，源基站和目标基站对同一个 DRB（数据无线承载）必须使用连续的 COUNT 值。如果源基站发到 COUNT=1000 就停了，目标基站绝不能从 950 或 1005 开始——前者会导致重复包，后者会导致 COUNT 缺口，加密结果对不上，UE 解出来全是乱码。

SN Status Transfer 信令传递的就是这个"接力棒"。对每个需要无损传输的 DRB，源基站会上报：

传递参数 含义 作用
DL PDCP SN 下一条要发给 UE 的下行包序列号 目标基站从此值继续编号下行
UL PDCP SN 期望从 UE 收到的下一条上行包序列号 目标基站据此识别上行包是否重复/缺失
HFN 超帧号，与 SN 组合成 COUNT 保证加密计数器连续
接收状态位图 哪些上行包源基站已收/未收 目标基站据此请求 UE 重传缺失包

一个重要的工程细节：SN Status Transfer 只对配置了 PDCP SN 且使用确认模式（AM）RLC 的 DRB 有意义。 对于非确认模式（UM）的承载或信令无线承载（SRB），本身就是"尽力而为"，不需要严密的序号交接。

调试陷阱：现网中如果遇到切换后业务"卡住几十毫秒然后恢复"或出现一段乱码，排查方向往往是 SN 状态传递异常或 PDCP COUNT 错位，而不是物理层信号问题。这是新手常踩的坑——以为切换问题都在 RF 侧，实则很多在协议栈的序号管理。

六、数据转发：分流量的智慧

SN 状态转移解决了"序号不乱"，但还有一个现实问题：在路径切换完成前，正飞在空中的数据包怎么办？ 这些包有的源基站已经发出但 UE 还没收到，有的源基站刚收到还没来得及发。如果直接"撒手不管"，这些包就丢了。

数据转发（Data Forwarding）就是为了接住这些"在途包"。它的本质是：源基站在切换期间充当一个临时中转站，把收到的下行数据通过 Xn-U 隧道转交给目标基站，由目标基站接力发给 UE。

flowchart LR
    subgraph 切换前
        UPF1[UPF] -->|下行数据| SG1[源 gNB]
        SG1 -->|空口| UE1[UE]
    end
    subgraph 切换中[切换中: 两段式]
        UPF2[UPF] -->|数据仍发往源| SG2[源 gNB]
        SG2 -.转发.-> TG2[目标 gNB]
        TG2 -->|空口| UE2[UE]
    end
    subgraph 切换后
        UPF3[UPF] -->|数据直达| TG3[目标 gNB]
        TG3 -->|空口| UE3[UE]
    end
    style SG2 fill:#fff3e0,stroke:#FF9800
    style TG2 fill:#e8f5e9,stroke:#4CAF50

转发分两类，对应两种"在途包"：

转发类型 对应的包 处理方式
未发送包转发 源基站收到但还没来得及空口发送的下行包 整包转发给目标，目标首次发送
未确认包转发 源基站已发但 UE 未确认收到的下行包 转发给目标，目标据此判断是否需要重传

注意，UE 收到包后会通过 PDCP 层的 SN 去重——同一个 SN 的包，UE 只会接受第一个正确解密的，后续重复的直接丢弃。所以即便源基站和目标基站都发了一份相同 SN 的包，也绝不会在 UE 侧出现重复业务数据。PDCP 序号机制是整个无损切换的"安全网"。

一个容易忽略的点：数据转发的隧道是临时的。它要么在源基站收到 UE Context Release 后释放，要么由一个可配置的定时器到期后自动清除。如果这个定时器配得太长，会浪费传输资源；配得太短，又可能在路径切换前就断流。这是传输网优化的一个调参点。

七、N2/NGAP 切换：核心网下场指挥

当 Xn 不可用时，切换的准备阶段就要"上交"给核心网。这就是 N2 切换。它的信令路径明显更长，但解决的是 Xn 切换覆盖不到的场景。

sequenceDiagram
    participant UE
    participant SG as 源 gNB
    participant AMF
    participant TG as 目标 gNB
    participant UPF

    UE->>SG: ① 测量上报
    Note over SG: 切换决策成立,但无Xn链路
    SG->>AMF: ② NGAP: Handover Required
    Note over AMF: ③ 选择目标、转发请求
    AMF->>TG: ④ NGAP: Handover Request
    Note over TG: ⑤ 接纳控制 + 资源分配
    TG-->>AMF: ⑥ NGAP: Handover Request Acknowledge
    AMF-->>SG: ⑦ NGAP: Handover Command
    SG->>UE: ⑧ RRC Reconfiguration
    UE->>TG: ⑨ 随机接入 + RRC Reconfiguration Complete
    TG->>AMF: ⑩ NGAP: Handover Notify
    Note over AMF: ⑪ 触发N3路径切换
    AMF->>SG: ⑫ NGAP: UE Context Release Command
    Note over SG: 释放资源

对比 Xn 切换，N2 切换多出了第②③⑦步的"核心网往返"。这里有两个设计要点值得玩味：

第一，为什么 AMF 要全程在场？ 因为没有 Xn 直连，两个基站互相"看不见"对方，必须有一个共同的可信第三方来中转。AMF 作为 UE 的移动性锚点，天然知道 UE 在哪个基站、要去哪个基站，由它来当"信使"最合理。这也是为什么 N2 切换常出现在跨 AMF 服务区、跨厂商设备边界的场景——这些地方恰恰缺少直连链路。

第二，Handover Notify 的意义。 在 Xn 切换里，路径切换是目标基站主动发 Path Switch Request；而在 N2 切换里，由于 AMF 已经深度参与，目标基站只需要发一个 Handover Notify 通知"UE 已到我这边"，AMF 自己就知道该去切路径了。这是两种切换在完成阶段的根本差异。

八、R16 演进：CHO 提前准备与 DAPS 双栈

到这里，你可能觉得传统切换已经够完善了。但在高铁、车联网、工业控制等极端移动性场景下，传统切换有一个致命弱点：整个准备+执行过程必须在无线链路彻底崩溃前完成。一旦信号下降得比信令完成得还快（这在高铁过隧道、覆盖空洞区域极其常见），UE 收不到切换命令，就会发生无线链路失败（RLF），业务直接断掉。

为了解决这个问题，3GPP 在 R16 引入了两种革命性的增强机制，它们的哲学恰好相反：

特性 传统切换（R15） CHO 条件切换（R16） DAPS 双栈切换（R16）
核心思想 测到即切换 提前准备，延迟执行 新旧并存，无缝切换
切换命令下发时机 信号开始变差时 信号还很好时就下发
谁决定执行 网络 UE 自己（满足条件时） 网络
中断时间 约 10~50ms 约 10~50ms 接近 0ms
主要目标 基础移动性 提高可靠性，降低RLF 零中断，服务连续
UE 复杂度/功耗 低 中 高（两套MAC）
典型场景 普通场景 高铁、覆盖空洞 URLLC、工业控制、语音

CHO（Conditional Handover，条件切换） 的精髓可以用八个字概括："提前准备，延迟执行"。网络在 UE 信号还很好的时候，就把切换命令和候选目标小区一起下发；UE 收到后并不立即切换，而是把这个"锦囊"揣在兜里，等到自己判断满足执行条件（比如目标小区 RSRP 超过门限且持续一段时间），才自主发起切换。这样就把"能否收到切换命令"这个最脆弱的环节，从信号变差时移到了信号还好时——彻底消除了信令与信道质量的赛跑。

DAPS（Dual Active Protocol Stack，双激活协议栈切换） 走的是另一条路。它让 UE 在切换瞬间同时维持与源基站和目标基站的连接——旧的链路不断，新的链路先建好，确认新链路可用后再释放旧的。这就是通信界常说的 make-before-break（先建后断）。代价是 UE 要同时跑两套 MAC 实体，功耗和复杂度显著上升，所以它专门服务于对中断极度敏感的 URLLC（超可靠低时延）业务。

理解了这两者，你就理解了移动性增强的设计脉络：CHO 解决的是"切换成不成"的问题（可靠性），DAPS 解决的是"切换痛不痛"的问题（连续性）。 它们不是替代关系，而是互补——网络可以根据业务类型和移动特征，灵活选择甚至组合使用。

九、实战连接：网优工程师怎么用这些知识

把上面的原理落到现网，工程师在调切换问题时，思维框架其实就三条线：

1. 看"切得对不对"——决策线。 切换失败的第一步永远是核对测量配置和切换参数。A3 事件偏移量（offset）、迟滞（hysteresis）、触发时延（TTT）这三个参数决定了切换的"早晚"。配得太早，容易乒乓切换（来回切，浪费信令）；配得太晚，容易掉线。这是 RF 优化的主战场。

2. 看"准不准备得及"——准备线。 如果决策正确但切换仍失败，要查准备阶段。Xn 链路是否正常建立？目标基站接纳控制是否拒绝（容量不足）？这一步在信令跟踪里表现为 Handover Request 是否有对应的 Acknowledge。如果是 N2 切换，还要看 AMF 转发是否正常。

3. 看"数据通不通"——数据线。 切换成功了但用户感知卡顿，问题往往在 SN 状态转移和数据转发。检查 COUNT 是否连续、转发隧道是否在路径切换前就异常释放、是否有 PDCP 重排序超时。这类问题最隐蔽，因为切换信令是"成功"的，但用户体验是"差"的。

常见误区：很多工程师一看到掉话就往覆盖上找原因，铺开扫频、调功率。实际上连接态的掉话，有相当比例是切换流程的协议问题——尤其是跨厂商、跨区域边界处用 N2 切换的场景。学会区分"信号差导致的掉话"和"切换失败导致的掉话"，是 RF 优化工程师进阶为系统优化工程师的分水岭。

十、常见问题

Q1: Xn 切换和 N2 切换，UE 侧感知有区别吗？ A: 几乎没有。对 UE 而言，无论哪种切换，它看到的都是"收到一条 RRC Reconfiguration 切换命令 → 随机接入新小区 → 上报完成"。切换类型的差异完全在基站和核心网之间的信令路径上，对 UE 是透明的。这也是为什么切换类型的选择由网络自动决定，用户无感。

Q2: 数据转发会不会一直进行，浪费带宽？ A: 不会。转发隧道是临时的，在源基站收到 UE Context Release 后立即释放，或由定时器兜底。网络只在"路径切换完成前的过渡期"使用转发，一旦数据直达目标基站，转发立刻停止。转发期间的数据量通常很小（在途包），对带宽影响有限。

Q3: 为什么 SN Status Transfer 不对所有承载都做？ A: 因为它有成本。SN 状态转移的意义是"无损、按序"，这只对确认模式的承载（如 TCP 类业务）有意义。对于非确认模式的承载（如 VoNR 语音，丢一两个包无所谓，关键是低时延），强行做序号交接反而增加时延和信令开销。所以协议只对有需要的 DRB 做，这是可靠性与效率的折中。

Q4: CHO 会不会导致 UE 切错了目标？ A: 不会。CHO 的执行条件由网络严格配置（候选小区列表+触发条件），UE 只能在网络授权的候选小区里、按网络定义的条件自主触发。UE 没有"自由发挥"的空间。网络还可以随时取消已下发的 CHO 配置，控制权始终在网络手里。所谓"UE 自主"，是指在条件满足时的执行时机由 UE 判断，而非目标选择由 UE 决定。

Q5: 高铁场景为什么特别需要 CHO？ A: 因为高铁速度快、多普勒频移大、经常过隧道，信号在毫秒级时间内就可能从可用跌到不可用。传统切换要在"信号变差但还没断"的窗口内完成全部信令，这个窗口在高铁场景下短得难以保证。CHO 把命令下发提前到信号还好的时候，等于把这个窗口从几十毫秒拉长到几秒，从根本上消除了"来不及切"的风险。

参考来源

  1. 5G 信令流程 — 5GS 的 gNB 切换（Xn/N2 Handover）管理 — 华为云社区，详解 Xn/N2 两类切换的准备与执行完成阶段
  2. Introduction of Xn and NG (N2) based handover - free5FC — free5GC 开源项目官方博客，对比 Xn 与 N2 切换的信令路径差异
  3. 5G Inter-gNB Handover (Xn-based HO) and Data Forwarding — TelecomHall，Xn 切换信令流程与数据转发机制详解
  4. 5G SN Status Transfer | XnAP Message — 3glteinfo，PDCP SN 状态转移信令字段说明
  5. 5G Handover - Devopedia — Devopedia，切换机制综述含 R16 CHO/DAPS 演进

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

📎 本分类最新文章