# 切换：连接态的基站接力赛 你正坐在高铁上刷视频，列车以 350km/h 的速度穿过几十个基站的小区，可画面始终流畅，通话从未中断。这背后发生了一场又一场精密到毫秒级的"接力赛"——**切换（Handover）**。旧的基站（接力棒的上一棒）要在你彻底跑出它的覆盖范围之前，把你的数据连接、信令上下文、未发完的下行数据包，准确无误地交给下一个基站。交早了浪费资源，交晚了你就掉线。这篇文章就拆解这场接力赛的内幕：怎么决定该交棒、交给谁、用什么姿势交、交不出去怎么办。 ## 一、从一个常识开始：为什么不能让手机自己"跳"过去 很多人对切换的第一直觉是："手机发现信号差了，自己连到下一个基站不就行了？"——这其实是**小区重选**的逻辑，那是**空闲态（RRC_IDLE/RRC_INACTIVE）** 的事。空闲态手机没在传业务，自己换个小区安静得很，失败了大不了重新发起业务。 但**连接态（RRC_CONNECTED）** 完全不同：你正在通话、正在下载、正在打游戏。此时手机和基站之间维护着严密的"状态"——无线承载（RB）、PDCP 序列号、加密密钥、调度上下文、核心网 N3 隧道。如果让手机自己擅自跳走，会出现三个灾难性后果： 1. **下行数据黑洞**：核心网还在往旧基站推数据，旧基站已经联系不上你，数据全丢。 2. **乱序与重复**：新基站不知道你上一个包收到了没有，重传、乱序接踵而至。 3. **密钥与上下文断裂**：新基站没有你的安全上下文，根本无法为你解密/加密。 所以**连接态的切换必须是一场"有组织的交接"**，由网络（而非手机单方面）主导：网络提前在目标基站备好资源、备好上下文、备好"逃生通道"（数据转发），然后给手机下达一条精确的指令，手机才能在受控状态下完成跳转。这就是切换区别于重选的根本所在：**重选是终端的"自主漫游"，切换是网络的"受控交接"**。 ## 二、切换的三段式骨架：准备 → 执行 → 完成 无论哪种制式（4G/5G）、哪种路径（站内/Xn/N2），所有切换都可以抽象成三个阶段。理解了这个骨架，后面所有细节都是往里填肉。 ```mermaid flowchart TD subgraph 准备阶段["🟦 准备阶段 Preparation"] M[UE测量上报] --> D[源gNB切换判决] D --> REQ[向目标gNB申请资源] REQ --> AC[目标gNB准入控制
+资源预留] AC --> CMD[生成切换命令
RRC Reconfiguration] end subgraph 执行阶段["🟧 执行阶段 Execution"] CMD --> SYNC[UE与新小区同步
随机接入] SYNC --> SN[SN状态转移] end subgraph 完成阶段["🟩 完成阶段 Completion"] SYNC2[UE接入成功] --> PATH[路径切换
下行隧道改道] 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 是个关键参数——它用来防止手机因为瞬间的信号抖动而误报。 5G 定义了一组事件，理解它们的"语义"比记编号重要： | 事件 | 触发语义 | 典型用途 | |------|---------|---------| | **A1** | 服务小区信号**好于**门限 | 信号好，停止异频/异系统测量（省电） | | **A2** | 服务小区信号**差于**门限 | 信号变差，启动异频/异系统测量 | | **A3** | 邻区信号**优于**服务小区一个偏移量 | **最常用的同频/异频切换触发** | | **A4** | 邻区信号**高于**绝对门限 | 负载均衡时往好小区切 | | **A5** | 服务小区低于门限1 **且** 邻区高于门限2 | 服务变差+邻区够好，触发切换 | | **B1/B2** | 异系统（如5G↔4G）邻区变好 | 跨制式互操作 | **A3 是切换的绝对主力**，它的进入条件用公式表达最直观： $$Mn - Mp > Ocn - Ocp + Hys + Off$$ 其中： - $Mn$：邻区测量值；$Mp$：服务小区测量值 - $Ocn$、$Ocp$：邻区/服务小区的特定偏移（运营商可调，用来"人为"压低/抬高某小区优先级） - $Hys$：迟滞值（防止在门限附近反复横跳） - $Off$：A3 专用偏移（通常默认为0） 这个不等式的物理含义很朴素：**"邻居比我好得够多，就该换邻居了"**。其中"够多"由 $Hys + Off$ 把关——好一点点不算，要好出一定裕量，这就是为什么在两个小区覆盖重叠的中心地带，手机不会因为微小波动而频繁切换（频繁切换叫**乒乓切换**，是网络优化的头号顽疾）。 离开条件是反过来的：$Mn - Mp < Ocn - Ocp + Hys - Off$。进入和离开之间形成一段**迟滞带**，避免抖动。 ## 四、谁说了算：源基站是切换的"裁判" 一个常见误解：以为是核心网（AMF）在决定切换。**错**。在 5G 分布式 RAN 架构下，**切换判决权在源 gNB 手里**。源基站收到测量报告，自己跑一套切换算法（结合 RSRP、负载、邻区关系、UE 能力），决定该切到哪个目标小区。 核心网只在两种情况下"插手"： - **N2 切换**时：源基站没有到目标基站的 Xn 直连，必须"借道"核心网转发信令，此时 AMF 只是个"信令中转站"，决策仍是源基站做的。 - **负载均衡/接入控制**：核心网可以给基站下发"邻居关系限制"或切片约束，影响可选目标，但不直接做点对点的切换指令。 记住这个比喻：**源基站是足球教练，UE 是球员，目标基站是替补席。教练根据场上形势（测量报告）决定换谁、何时换，AMF 是俱乐部管理层，提供规则但不临场指挥。** ## 五、三种接力路径：站内、Xn、N2 切换命令准备好之后，信令走哪条路取决于网络拓扑。这就是三条核心路径： ```mermaid flowchart TB UE((UE)) S["源 gNB"] T["目标 gNB"] AMF["AMF（核心网）"] UE -.测量报告.-> S S --> Path{有Xn直连吗?} Path -->|有| Xn["✅ Xn切换
gNB↔gNB直接谈"] Path -->|无| N2["❌ N2切换
绕道AMF转发"] S -->|同站?| Intra["✅ 站内切换
基站内部搞定"] 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 切换完整信令流程。请特别注意每条消息的目的，而不是死记名字： ```mermaid 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: 准入控制+预留资源
生成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状态,告诉目标
上行/下行发到第几号了 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下行隧道
从源改到目标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 区域）时，信令必须绕道核心网。流程上多了一跳，但骨架完全一样： ```mermaid 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 在整个切换过程中**几乎不丢包**。这种转发分两类： - **按序转发（in-order forwarding）**：保持 PDCP SN 顺序，目标基站收到后排序再发。 - **直接转发（direct forwarding）**：源→目标直连走 Xn。 如果目标基站已经准备好，部分数据甚至可以在切换前就由源基站**提前转发（early data forwarding）** 缓存好。这一切都发生在底层，对上层应用（你的视频流、游戏）完全透明——这正是切换设计的精妙之处。 ## 九、交棒失败与新招式：CHO、DAPS、LTM 传统切换有个固有弱点：**"准备阶段"和"执行阶段"是分开的**。准备时测得的信号，到执行时可能已经变了。尤其高铁、车载高速场景，信令还没跑完，手机已经冲出了目标小区，导致**切换失败（RLF，无线链路失败）**，进而触发 RRC 重建，掉话。 为此，5G 在 R16/R17/R18 演进中引入了一系列"新招式"： | 技术 | 引入版本 | 核心思想 | 解决的问题 | |------|---------|---------|-----------| | **CHO（条件切换）** | R16 | 一次准备**多个候选小区**，UE 自己等条件满足时**自主执行** | 信令时延与执行时延之间的"信号变化"问题 | | **DAPS（双激活协议栈）** | R16 | 切换瞬间**同时保持**新旧两套连接 | 0ms 中断切换 | | **LTM（L1/L2 触发移动性）** | R18 | 切换决策下沉到**物理层/MAC层**，不靠RRC | 把切换时延从几十毫秒压到几毫秒 | **条件切换（CHO）** 是最值得展开的。传统切换是"父亲（源基站）说该过马路了，孩子（UE）才能走"。CHO 是"父亲提前给了孩子一张候选过马路清单和各自的条件（A3事件），孩子自己盯着红绿灯，哪条满足就走哪条"。 ```mermaid flowchart LR subgraph 传统切换["传统切换：串行"] A1[准备单个目标] --> B1[回源gNB拿命令] --> C1[执行] end subgraph CHO["条件切换CHO：并行预配置"] A2[一次性准备多个候选小区
cell1/cell2/cell3] --> B2[UE收到多套配置+各自条件] B2 --> C2{UE实时监测
哪个条件先满足?} 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，就**自主**发起向该候选的接入，不再等待源基站二次下发命令——这就是"条件"二字的含义。 ## 参考来源 1. [5G 信令流程 — 5GS 的 gNB 切换（Xn/N2 Handover）管理 — CSDN](https://blog.csdn.net/Jmilk/article/details/113873811) — 系统梳理 Xn/N2 两种切换的完整信令流程与阶段划分 2. [5G NR Conditional Handover (CHO) — Techplayon](https://www.techplayon.com/conditional-handover-cho/) — 讲解 R16 条件切换原理、候选小区预配置与自主执行机制 3. [5G/NR CHO (Conditional Handover) — ShareTechnote](https://www.sharetechnote.com/html/5G/5G_CHO.html) — 图文化讲解条件切换与传统切换的差异 4. [Measurement Report Event A3 in 5G NR — WirelessBrew](https://wirelessbrew.com/5g-nr/measurement-report-event-a3-in-5g-nr/) — A3 事件进入/离开条件公式与迟滞参数详解 5. [5G NR Measurement Events Explained — 3glteinfo](https://www.3glteinfo.com/5g/architecture/ran/measurement-events/) — A1–A5、B1–B2 测量事件语义与触发条件对照 --- > 本文由「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 等场景全覆盖。