切换：连接态的基站接力赛

你正坐在高铁上刷视频，列车以 350km/h 的速度穿过几十个基站的小区，可画面始终流畅，通话从未中断。这背后发生了一场又一场精密到毫秒级的"接力赛"——切换（Handover）。旧的基站（接力棒的上一棒）要在你彻底跑出它的覆盖范围之前，把你的数据连接、信令上下文、未发完的下行数据包，准确无误地交给下一个基站。交早了浪费资源，交晚了你就掉线。这篇文章就拆解这场接力赛的内幕：怎么决定该交棒、交给谁、用什么姿势交、交不出去怎么办。

一、从一个常识开始：为什么不能让手机自己"跳"过去

很多人对切换的第一直觉是："手机发现信号差了，自己连到下一个基站不就行了？"——这其实是小区重选的逻辑，那是空闲态（RRC_IDLE/RRC_INACTIVE） 的事。空闲态手机没在传业务，自己换个小区安静得很，失败了大不了重新发起业务。

但连接态（RRC_CONNECTED） 完全不同：你正在通话、正在下载、正在打游戏。此时手机和基站之间维护着严密的"状态"——无线承载（RB）、PDCP 序列号、加密密钥、调度上下文、核心网 N3 隧道。如果让手机自己擅自跳走，会出现三个灾难性后果：

所以连接态的切换必须是一场"有组织的交接"，由网络（而非手机单方面）主导：网络提前在目标基站备好资源、备好上下文、备好"逃生通道"（数据转发），然后给手机下达一条精确的指令，手机才能在受控状态下完成跳转。这就是切换区别于重选的根本所在：重选是终端的"自主漫游"，切换是网络的"受控交接"。

二、切换的三段式骨架：准备 → 执行 → 完成

无论哪种制式（4G/5G）、哪种路径（站内/Xn/N2），所有切换都可以抽象成三个阶段。理解了这个骨架，后面所有细节都是往里填肉。

flowchart TD
    subgraph 准备阶段["🟦 准备阶段 Preparation"]
        M[UE测量上报] --> D[源gNB切换判决]
        D --> REQ[向目标gNB申请资源]
        REQ --> AC[目标gNB准入控制<br/>+资源预留]
        AC --> CMD[生成切换命令<br/>RRC Reconfiguration]
    end
    subgraph 执行阶段["🟧 执行阶段 Execution"]
        CMD --> SYNC[UE与新小区同步<br/>随机接入]
        SYNC --> SN[SN状态转移]
    end
    subgraph 完成阶段["🟩 完成阶段 Completion"]
        SYNC2[UE接入成功] --> PATH[路径切换<br/>下行隧道改道]
        PATH --> REL[源gNB释放上下文]
    end
    准备阶段 --> 执行阶段 --> 完成阶段
    style 准备阶段 fill:#dbeafe
    style 执行阶段 fill:#fed7aa
    style 完成阶段 fill:#bbf7d0

这三段的分工非常清晰，可以用一句话记住每段的核心问题：

阶段	核心问题	关键动作	谁在忙
准备	目标基站"准备好了吗"？	测量、判决、申请资源、生成命令	源+目标gNB
执行	手机"跳过去"的那一瞬间	下发命令、随机接入、状态转移	UE+两个gNB
完成	数据通路"改道"了吗？	路径切换、资源释放	目标gNB+核心网

注意一个反直觉的点：切换命令（RRC Reconfiguration）是在准备阶段结束时由源基站下发给手机的。也就是说，源基站在让你"离开"自己之前，已经替你把新基站的一切都安排好了。它不会说"你去试试那边行不行"，而是说"那边我已经铺好路了，你照着这个参数走过去就行"。这叫"先铺路，再放人"，是切换可靠性的根基。

三、决策的眼睛：测量报告与事件触发

切换判决不是拍脑袋，它依赖手机持续上报的测量报告（Measurement Report）。手机测量的是参考信号——5G 里主要是 SSB（同步信号块）和 CSI-RS 的 RSRP（参考信号接收功率）/ RSRQ（质量）/ SINR。

基站通过 RRC 测量配置（measConfig） 告诉手机：测哪些频点、哪些邻区、什么时候报、按什么门限报。手机一旦满足某个测量事件的进入条件，且持续超过TTT（Time To Trigger，触发时延），就上报。TTT 是个关键参数——它用来防止手机因为瞬间的信号抖动而误报。

其中： - $Mn$：邻区测量值；$Mp$：服务小区测量值 - $Ocn$、$Ocp$：邻区/服务小区的特定偏移（运营商可调，用来"人为"压低/抬高某小区优先级） - $Hys$：迟滞值（防止在门限附近反复横跳） - $Off$：A3 专用偏移（通常默认为0）

事件	触发语义	典型用途
A1	服务小区信号好于门限	信号好，停止异频/异系统测量（省电）
A2	服务小区信号差于门限	信号变差，启动异频/异系统测量
A3	邻区信号优于服务小区一个偏移量	最常用的同频/异频切换触发
A4	邻区信号高于绝对门限	负载均衡时往好小区切
A5	服务小区低于门限1 且邻区高于门限2	服务变差+邻区够好，触发切换
B1/B2	异系统（如5G↔4G）邻区变好	跨制式互操作

这个不等式的物理含义很朴素："邻居比我好得够多，就该换邻居了"。其中"够多"由 $Hys + Off$ 把关——好一点点不算，要好出一定裕量，这就是为什么在两个小区覆盖重叠的中心地带，手机不会因为微小波动而频繁切换（频繁切换叫乒乓切换，是网络优化的头号顽疾）。

离开条件是反过来的：$Mn - Mp < Ocn - Ocp + Hys - Off$。进入和离开之间形成一段迟滞带，避免抖动。

四、谁说了算：源基站是切换的"裁判"

一个常见误解：以为是核心网（AMF）在决定切换。错。在 5G 分布式 RAN 架构下，切换判决权在源 gNB 手里。源基站收到测量报告，自己跑一套切换算法（结合 RSRP、负载、邻区关系、UE 能力），决定该切到哪个目标小区。

核心网只在两种情况下"插手"： - N2 切换时：源基站没有到目标基站的 Xn 直连，必须"借道"核心网转发信令，此时 AMF 只是个"信令中转站"，决策仍是源基站做的。 - 负载均衡/接入控制：核心网可以给基站下发"邻居关系限制"或切片约束，影响可选目标，但不直接做点对点的切换指令。

记住这个比喻：源基站是足球教练，UE 是球员，目标基站是替补席。教练根据场上形势（测量报告）决定换谁、何时换，AMF 是俱乐部管理层，提供规则但不临场指挥。

五、三种接力路径：站内、Xn、N2

切换命令准备好之后，信令走哪条路取决于网络拓扑。这就是三条核心路径：

flowchart TB
    UE((UE))
    S["源 gNB"]
    T["目标 gNB"]
    AMF["AMF（核心网）"]
    UE -.测量报告.-> S
    S --> Path{有Xn直连吗?}
    Path -->|有| Xn["✅ Xn切换<br/>gNB↔gNB直接谈"]
    Path -->|无| N2["❌ N2切换<br/>绕道AMF转发"]
    S -->|同站?| Intra["✅ 站内切换<br/>基站内部搞定"]
    Xn --> T
    N2 --> AMF
    AMF --> T
    style Xn fill:#bbf7d0
    style N2 fill:#fed7aa
    style Intra fill:#dbeafe

维度	站内切换	Xn 切换	N2 切换
发生场景	同一 gNB 内不同小区	不同 gNB，有 Xn 接口	不同 gNB，无 Xn（或跨 AMF）
信令路径	gNB 内部	gNB↔gNB（XnAP）	gNB→AMF→gNB（NGAP）
核心网参与	不参与	仅最后路径切换	全程参与
切换时延	最短	短	较长
N3 通路变更	不变	变（路径切换）	变（路径切换）
类比	同公司换工位	两公司直谈跳槽	经猎头（AMF）跳槽

工程上优先级永远是：站内 > Xn > N2。时延越短、参与网元越少，越不容易出问题。所以网优的一个基本功就是确保邻区 gNB 之间Xn 链路连通，把潜在的 N2 切换升级成 Xn 切换。

六、Xn 切换时序图：一场高效的"直谈"

下面是 5G 中最常见的 Xn 切换完整信令流程。请特别注意每条消息的目的，而不是死记名字：

sequenceDiagram
    participant UE
    participant SgNB as 源 gNB
    participant TgNB as 目标 gNB
    participant AMF
    Note over UE,SgNB: ━━ 准备阶段 ━━
    UE->>SgNB: Measurement Report (Event A3)
    Note right of SgNB: 判决：该切换了
    SgNB->>TgNB: Handover Request (XnAP)
    Note right of TgNB: 准入控制+预留资源<br/>生成UE上下文
    TgNB-->>SgNB: Handover Request Acknowledge
    Note right of TgNB: 携带:目标小区配置/专用前导码
    Note over UE,SgNB: ━━ 执行阶段 ━━
    SgNB->>UE: RRC Reconfiguration (=切换命令)
    SgNB->>TgNB: SN Status Transfer
    Note right of SgNB: PDCP SN状态,告诉目标<br/>上行/下行发到第几号了
    Note over UE: 此时UE脱离源小区
    UE->>TgNB: Random Access (专用preamble)
    TgNB-->>UE: RAR (上行TA+资源)
    Note over UE,TgNB: 上下行恢复,数据可传
    Note over UE,TgNB: ━━ 完成阶段 ━━
    TgNB->>AMF: Path Switch Request
    Note right of AMF: 把N3下行隧道<br/>从源改到目标gNB
    AMF-->>TgNB: Path Switch Request Ack
    TgNB->>SgNB: UE Context Release
    Note right of SgNB: 释放源端资源,接力完成

1. 为什么 Handover Request Ack 要带"专用前导码"？ 随机接入是切换执行阶段最耗时也最容易冲突的环节。如果让手机和普通接入一样去抢随机的前导码，可能撞车（碰撞）。所以目标基站为这台手机预留一个专用的 preamble（前导码），保证手机到新小区的第一步是"零冲突"的。这一个细节能省下数十毫秒。

2. SN Status Transfer 在干什么？ PDCP 层每个数据包都有个递增的序列号（SN）。源基站通过这条消息告诉目标基站："下行包我已经发到 SN=1000，但 UE 只确认收到 995，所以 996~1000 你得重发；上行 UE 发到 800，你从 801 开始数。" 这就是切换无损性的关键——上下行的序列号无缝衔接，应用层感觉不到任何丢包或乱序。

3. Path Switch 为什么放在最后？ 核心网到 gNB 的下行数据隧道（N3/GTP-U 隧道）默认还是连在源基站的。在切换执行的那几毫秒里，核心网不知道你换了基站，下行数据会继续涌向源基站。源基站有两个选择：要么直接扔掉，要么通过 Xn 接口"转发"给目标基站（数据转发 forwarding）。等 UE 在目标站稳了，目标基站才通过 Path Switch 通知核心网"把隧道改道到我这里"。改道之后，源基站就没用了，于是发 UE Context Release 释放自己。

七、N2 切换时序图：绕道核心网的"长路径"

当没有 Xn 接口（比如不同厂家设备未互通 Xn、或跨 AMF 区域）时，信令必须绕道核心网。流程上多了一跳，但骨架完全一样：

sequenceDiagram
    participant UE
    participant SgNB as 源 gNB
    participant AMF
    participant TgNB as 目标 gNB
    Note over UE,SgNB: ━━ 准备阶段 ━━
    UE->>SgNB: Measurement Report
    SgNB->>AMF: Handover Required (NGAP)
    Note right of AMF: AMF转发,但不做判决
    AMF->>TgNB: Handover Request (NGAP)
    TgNB-->>AMF: Handover Request Acknowledge
    AMF-->>SgNB: Handover Command
    Note over UE,SgNB: ━━ 执行阶段 ━━
    SgNB->>UE: RRC Reconfiguration
    SgNB->>AMF: Uplink RAN Status Transfer
    AMF->>TgNB: Downlink RAN Status Transfer
    Note right of AMF: SN状态经核心网转一道
    UE->>TgNB: Random Access
    TgNB-->>UE: RAR
    Note over UE,TgNB: ━━ 完成阶段 ━━
    TgNB->>AMF: Handover Notify
    Note right of TgNB: "我接入成功了"
    Note over AMF: 核心网切换N3下行隧道
    AMF->>SgNB: UE Context Release Command
    SgNB-->>AMF: UE Context Release Complete

注意 N2 切换里 SN 状态转移要拆成两条、经 AMF 转一道（Uplink/Downlink RAN Status Transfer），因为源和目标之间没有直连。这也是 N2 切换比 Xn 切换慢的根本原因——每多一跳中转，就多一段时延和一次失败可能。

工程上的实战意义：如果你在抓包时发现某片区域大量出现 N2 切换而非 Xn 切换，第一反应应该是检查 Xn 接口是否配置/连通，而不是怀疑切换算法。Xn 自配置（自动建立 Xn 链路）没开好，是导致切换走"长路径"的最常见原因。

八、数据转发：那几毫秒里下行包去哪了

这是新手最容易忽略、却最关键的工程细节。切换执行的那段时间（从 UE 离开源小区到 Path Switch 完成），核心网的下行数据仍在往源基站送。这些数据怎么办？

$$\text{下行数据流} = \underbrace{\text{核心网} \xrightarrow{N3} \text{源gNB}}_{\text{改道前}} \xrightarrow[\text{转发}]{Xn} \underbrace{\text{目标gNB} \xrightarrow{} \text{UE}}$$

源基站在切换期间扮演"临时中转站"，把收到的下行包通过 Xn 接口转发给目标基站，目标基站再按 SN 顺序发给 UE。这样 UE 在整个切换过程中几乎不丢包。这种转发分两类：

如果目标基站已经准备好，部分数据甚至可以在切换前就由源基站提前转发（early data forwarding） 缓存好。这一切都发生在底层，对上层应用（你的视频流、游戏）完全透明——这正是切换设计的精妙之处。

九、交棒失败与新招式：CHO、DAPS、LTM

传统切换有个固有弱点："准备阶段"和"执行阶段"是分开的。准备时测得的信号，到执行时可能已经变了。尤其高铁、车载高速场景，信令还没跑完，手机已经冲出了目标小区，导致切换失败（RLF，无线链路失败），进而触发 RRC 重建，掉话。

技术	引入版本	核心思想	解决的问题
CHO（条件切换）	R16	一次准备多个候选小区，UE 自己等条件满足时自主执行	信令时延与执行时延之间的"信号变化"问题
DAPS（双激活协议栈）	R16	切换瞬间同时保持新旧两套连接	0ms 中断切换
LTM（L1/L2 触发移动性）	R18	切换决策下沉到物理层/MAC层，不靠RRC	把切换时延从几十毫秒压到几毫秒

条件切换（CHO） 是最值得展开的。传统切换是"父亲（源基站）说该过马路了，孩子（UE）才能走"。CHO 是"父亲提前给了孩子一张候选过马路清单和各自的条件（A3事件），孩子自己盯着红绿灯，哪条满足就走哪条"。

flowchart LR
    subgraph 传统切换["传统切换：串行"]
        A1[准备单个目标] --> B1[回源gNB拿命令] --> C1[执行]
    end
    subgraph CHO["条件切换CHO：并行预配置"]
        A2[一次性准备多个候选小区<br/>cell1/cell2/cell3] --> B2[UE收到多套配置+各自条件]
        B2 --> C2{UE实时监测<br/>哪个条件先满足?}
        C2 -->|cell2先满足| D2[UE自主接入cell2]
    end
    style 传统切换 fill:#fee2e2
    style CHO fill:#dcfce7

CHO 的好处是把切换的"反应时间"从网络侧的信令往返，缩短到了 UE 侧的实时监测。一旦某个候选小区满足条件，UE 立刻执行，不再等源基站那条慢慢悠悠的切换命令。在高铁、小区边缘快速移动、信号剧烈波动的场景下，CHO 显著提升了切换成功率。代价是要在多个候选小区预留资源，有一定资源开销——工程上一般只配 1~3 个候选。

DAPS 更激进：切换瞬间，UE 同时和源、目标两个小区都保持连接（双收），等目标站稳了再断源，实现接近零中断的切换，专治对时延极度敏感的业务。

LTM 则代表了另一种思路——把切换从"重信令流程"降级为"轻量 MAC 命令"，类似激活一个预先配置好的候选小区，切换时延能压到个位数毫秒级别，是面向 R18/R19 低时延高可靠场景的关键演进。

十、工程实战：这些原理在调试时怎么用

1. 掉话分析时，先看切换还是看重建？ 抓取 trace 后，如果看到"Handover Command 之后没有 Path Switch/Handover Notify，反而出现 RRC Reestablishment"，基本可判定切换执行失败。再看失败前最后一次测量报告的 RSRP：如果目标小区 RSRP 本来就低，是切换过早（判决时目标信号不够好）；如果切换命令到执行间隔过长，是切换过晚（信令太慢，UE 已冲出覆盖）。这三种典型问题（过早/过晚/乒乓）是网优切换专题的核心。

2. 乒乓切换怎么治？ 同一个边界区域每几秒就来回切一次。根因是迟滞（Hys）、偏移（Off）、TTT 设置不合理。增大 TTT（让 UE 稳定一段时间再切）、增大 A3 的 Off/Hys（要求邻区好得更多才切），通常能缓解。但要平衡——门限太严又会变成"切换过晚"，二者是跷跷板。

3. 怎么判断一片区域走的是 Xn 还是 N2？ 看信令里准备阶段的消息类型：XnAP（Handover Request/Request Ack）走 Xn，NGAP（Handover Required/Request）走 N2。N2 切换多→查 Xn 自配置；Xn 切换准备失败率高→查目标基站资源/邻区关系。

4. 上下文释放没跟上会怎样？ 如果 Path Switch 之后源基站迟迟不释放 UE Context，会产生"幽灵上下文"占用资源，且可能导致 AMF 状态不一致。排查时关注 UE Context Release 消息时序。

十一、一句话总结

切换的本质是一场网络的受控接力：它用测量事件（A3 公式）决定何时交棒，用源基站的判决决定交给谁，用三段式流程（准备-执行-完成）保证交得稳，用 SN 状态转移和数据转发保证交得不丢包，用 CHO/DAPS/LTM 应对高速和零中断的新挑战。理解了"先铺路再放人"这个核心理念，你就抓住了所有切换流程的灵魂。

常见问题

Q1：切换和小区重选到底什么区别？ A：最本质的区别是终端状态和主导权。切换发生在连接态，由网络（源基站）主导，是一场有组织的资源交接；小区重选发生在空闲态/非激活态，由终端自主完成，不涉及业务连续性。一个"正在通话不能掉"，一个"没业务随便换"。

Q2：为什么高铁上切换容易失败？ A：核心矛盾是信令时延 vs 信号变化速度。传统切换准备+执行要几十毫秒，而高铁在几十毫秒里已经移动了几米到十几米，目标小区信号可能已剧烈变化。解法是 CHO（提前准备多候选、UE 自主执行）和缩短 TTT、增大候选冗余。

Q3：Xn 切换和 N2 切换，UE 侧能感知到区别吗？ A：几乎不能。对 UE 而言，两种切换收到的切换命令（RRC Reconfiguration）和执行过程（随机接入）是一样的，区别只在网络侧信令路径。这也是为什么 UE 不需要为"走哪条路"做任何特殊配置。

Q4：切换过程中数据会丢吗？ A：在理想情况下不丢——靠 SN 状态转移保证序列号连续，靠数据转发（forwarding）保证那几毫秒的下行包不落空。但如果切换失败触发 RLF 重建，或目标基站没启用转发，则可能丢包，上层（TCP）会重传。

Q5：CHO 的"条件"具体是什么？ A：通常还是测量事件（如 A3），只不过 UE 收到的是一组候选小区各自对应的执行条件。UE 持续评估，一旦某个候选满足条件且持续 TTT，就自主发起向该候选的接入，不再等待源基站二次下发命令——这就是"条件"二字的含义。