# 条件切换与双栈切换：消灭中断掉话 > 给有 1–3 年经验的无线工程师：把"切换为什么会掉话"拆到协议机制层面，再讲清楚 R16 引入的 CHO 与 DAPS 两大移动性增强技术，到底各自消灭了哪一类痛点。 --- ## 一、从一个生活场景说起 想象你在高铁上打电话。列车以 350 km/h 飞驰，每隔几秒手机就要换一个基站——这在通信里叫**切换（Handover）**。绝大多数时候你感觉不到，但偶尔会听到"喂？喂？你还在吗？"，那一下的断顿，甚至直接掉线，往往就发生在切换的瞬间。 为什么有的切换丝般顺滑，有的却要人命？答案藏在一个时间窗口里：**从手机断开旧基站、到接上新基站的那段"空窗期"**。这段空窗有多长、会不会失败，决定了你能不能保住这通电话。 5G 在 R16 版本里专门针对这个问题，掏出了两把新武器： - **CHO（Conditional Handover，条件切换）**——消灭"切换失败导致的掉话" - **DAPS（Dual Active Protocol Stack，双激活协议栈切换）**——消灭"切换瞬间的数据中断" 今天这篇文章，我们就把这两把武器拆开看，搞清楚它们**为什么这样设计**，以及**现网里怎么用**。在开始之前，先回头看看老办法到底哪里不行。 --- ## 二、传统切换的时序与三大软肋 ### 2.1 传统同步切换的时序 要理解增强，得先理解基线。下面这张图是传统的"网络控制、UE 执行"的同步切换信令时序： ```mermaid sequenceDiagram participant UE as 终端 UE participant Src as 源 gNB participant Tgt as 目标 gNB participant CN as 核心网 AMF/UPF UE->>Src: 1. 测量报告 (Measurement Report) Note over UE,Src: UE 发现邻区信号超过服务小区 Src->>Tgt: 2. 切换请求 (Handover Request) Tgt-->>Src: 3. 切换请求确认 (Request Ack + 切换命令) Src->>UE: 4. RRC 重配 (含 reconfigurationWithSync) Note over UE: ⚠ 关键时刻：命令必须经源链路送达 Note over UE: === 切换空窗期开始 === UE->>Tgt: 5. 随机接入 (RACH preamble) Tgt-->>UE: 6. 随机接入响应 (TA 调整) UE->>Tgt: 7. RRC 重配完成 (切换完成) Note over UE: === 切换空窗期结束 === Tgt->>CN: 8. 路径切换 (Path Switch Request) CN-->>Tgt: 9. 路径切换确认 Tgt->>Src: 10. UE 上下文释放 ``` 看到第 4 步那个 `RRC 重配`了吗？它就是切换命令，里面装着目标小区的频点、随机接入参数、新密钥等"过户文件"。问题在于：**这条命令只能通过源基站的无线链路下发**。 ### 2.2 三大软肋 把上面流程对着真实场景一对照，三个致命弱点就暴露出来了： **软肋一：切换命令靠"摇摇欲坠的链路"下发** UE 之所以要切换，正是因为源小区信号在变差。可偏偏在信号最差的时候，网络才下发切换命令。这就好比"火快烧到房梁了，才让人跑出去拿灭火器"。如果此刻源链路突然彻底断开（无线快衰落），切换命令根本收不到，UE 只能等无线链路失败，触发 RRC 重建——这就是**切换失败导致的掉话**。高铁、城区微站、信号快速波动的场景里，这类失败尤其多。 **软肋二：切换空窗期的同步中断** 从第 4 步 UE 断开源链路，到第 7 步在目标完成接入，中间 UE 要做随机接入、定时提前（TA）调整、安全激活等一系列动作。这段空窗期里，下行数据送不到、上行数据发不出，业务被"冻结"。这个中断时间可以用一个简化式子表达： $$ T_{interrupt} \approx T_{RACH\_preamble} + T_{RAR} + T_{UL\_grant} + T_{TA\_adjust} + T_{msg\_proc} $$ 各项相加，传统同步切换的下行中断通常落在 **20~40 ms** 量级（和频段、子载波间隔、负载都有关）。对普通上网无伤大雅，但对**车联网、工业控制、AR/VR 这类对时延零容忍的 URLLC 业务**，几十毫秒的冻结就是事故。 **软肋三：一次只能赌一个目标** 传统切换是网络"钦点"一个目标小区，UE 必须切过去。如果目标小区此刻拥塞、或信道突变变差，UE 扑了个空，照样失败。没有"Plan B"。 这三个软肋，正是 CHO 和 DAPS 各自要解决的对象。记住这个对应关系，后面就好懂了。 --- ## 三、解法一：条件切换 CHO —— "预发令"的智慧 ### 3.1 一个类比 传统切换像这样：你在高速公路上开车，导航（网络）每到一个出口才临时告诉你"下一个出口下，往左"。可万一那个瞬间导航信号断了，你就开过头了。 CHO 的思路换成了：**导航提前把前方 3 个出口的方向、以及"什么时候该下"的判断标准，一次性都告诉你**。比如"当右边那条路比当前路快 10%，且持续 5 秒，就从最近的符合条件的出口下"。这样即使导航信号临时中断，你已经知道该怎么做，自己判断、自己执行。 **核心转变：切换的"执行决策权"从网络转移到了 UE 手里，切换命令提前下发。** ### 3.2 CHO 的三阶段时序 ```mermaid sequenceDiagram participant UE as 终端 UE participant Src as 源 gNB participant C1 as 候选 gNB-1 participant C2 as 候选 gNB-2 Note over UE,C2: 【准备阶段】网络提前备好多个候选 Src->>C1: 1. 切换请求 C1-->>Src: 2. 确认 (返回候选1的切换配置+执行条件) Src->>C2: 3. 切换请求 C2-->>Src: 4. 确认 (返回候选2的切换配置+执行条件) Src->>UE: 5. RRC 重配 (含 CHO 配置: 候选列表 + 各自执行条件) Note over UE: UE 存储 CHO 配置, 持续评估条件 Note over UE,C2: 【执行阶段】UE 自主决定时机 Note over UE: 源链路即使恶化, 命令早已在手 ✅ loop 持续评估 UE->>UE: 6. 判断: 候选i 的执行条件是否满足并持续 TTT? end Note over UE: 条件满足! 选定候选1, 自主执行 UE->>C1: 7. 随机接入 (用预存的候选1配置) UE->>C1: 8. RRC 重配完成 Note over UE,C2: 【完成阶段】 C1->>Src: 9. UE 上下文释放 (经 Xn) Note over Src: 释放源侧资源与剩余候选配置 ``` 看明白关键在哪了吗？第 5 步**只有一次**，网络把"切换命令 + 触发条件"提前打包发给了 UE。之后就算源链路完全恶化，UE 手里也已经有命令了，自己根据条件执行。**软肋一（命令下发依赖恶化链路）被直接消灭。** 而且因为提前准备了候选 1 和候选 2 两个选项，UE 哪个条件先满足就切哪个——**软肋三（只能赌一个目标）也被缓解了**。 ### 3.3 "条件"到底是什么？—— A3 事件的数学表达 CHO 最让人困惑的往往是：UE 到底用什么标准判断"该切了"？答案是**测量事件**，最常用的是 A3 事件。 A3 事件的进入条件（满足时认为"邻区比服务小区好"，值得切换）： $$ M_n + O_{fn} + O_{cn} - Hys > M_s + O_{fs} + O_{cs} + Off $$ 符号含义见下表： | 符号 | 含义 | 工程意义 | |---|---|---| | $M_n$ | 邻区（候选）测量值，如 RSRP | 邻区信号强度 | | $M_s$ | 服务小区测量值 | 当前信号强度 | | $O_{fn}$ / $O_{fs}$ | 邻区 / 服务小区的频率特定偏置 | 跨频点切换的倾向调节 | | $O_{cn}$ / $O_{cs}$ | 小区特定偏置（CIO） | 网优"调节旋钮"，可让 UE 更倾向/回避某小区 | | $Hys$ | 迟滞（Hysteresis） | 防止信号小幅抖动导致来回切换（乒乓） | | $Off$ | 偏移量（Offset） | 控制切换早晚，越大切得越晚 | 光满足公式还不够，UE 必须让这个条件**持续满足一个 Time-To-Trigger（TTT，触发时间）**，比如 320 ms，才会真正执行切换。这就像"不是看一眼就跳，得连续确认几眼"。 **为什么这样设计？** 加 Hys 和 TTT 都是为了**抗抖动**。无线信号天然波动，如果没有这两道"过滤器"，UE 会在两个信号差不多的小区之间疯狂来回横跳（乒乓切换），反而更糟。CHO 把执行权交给 UE，就更需要这些"确认机制"防止 UE 过度敏感。 ### 3.4 CHO 没解决什么？ 要诚实：CHO **不能消除切换空窗期本身**。UE 一旦决定执行，依然要随机接入目标、做同步——这段中断和传统切换**差不多**。CHO 买来的是**鲁棒性（降低失败率）**，不是**零中断**。这个区分极其重要，很多新人会混淆。 | 维度 | 传统切换 | 条件切换 CHO | |---|---|---| | 执行决策方 | 网络（源 gNB） | UE 自主 | | 切换命令下发时机 | 临近切换、信号已变差时 | 提前下发，可多候选 | | 命令丢失风险 | 高（依赖恶化链路） | 低（命令已到手） | | 切换失败率 | 较高 | 显著降低 | | 数据中断时长 | 20~40 ms 量级 | 与传统相近 | | 信令开销 | 单候选 | 多候选，准备阶段开销略增 | | 典型场景 | 一般移动 | 高铁、信号快变、微站密集 | --- ## 四、解法二：双栈切换 DAPS —— 通信界的"双卡双待" ### 4.1 还是用类比 如果说 CHO 是"提前发令"，那 DAPS 是"双卡双待"。 普通切换像"先挂断旧电话，再拨新电话"，中间一定有几秒没人说话。DAPS 像你手机里同时插了两张卡：**新基站已经接通、开始通话了，旧基站那条线还不断**，等新的彻底稳定了，再优雅地挂掉旧的。两路同时在线，对话一刻不停。 ### 4.2 DAPS 的核心机制 DAPS 的本质，是让 UE 在切换期间**同时维持两个独立的协议栈**——一个连源、一个连目标，两套 MAC/RLC 各跑各的，**下行可以同时接收两路数据**。 ```mermaid sequenceDiagram participant UE as 终端 UE (双栈) participant Src as 源 gNB participant Tgt as 目标 gNB Note over UE: === 切换前: 仅源栈活跃 === UE<<->>Src: 业务正常收发 UE->>Src: 1. 测量报告 Src->>Tgt: 2. 切换请求 (指示 DAPS) Tgt-->>Src: 3. 确认 (含 DAPS 切换命令) Src->>UE: 4. RRC 切换命令 (DAPS HO) Note over UE: 激活目标栈, 源栈保留不停 Note over UE,Tgt: === 双栈并行期: 数据零/近零中断 === par 并行操作 UE<<->>Src: 5a. 源链路仍持续收发 (尤其是上行) and UE->>Tgt: 5b. 与目标随机接入 + 同步 Tgt-->>UE: 5c. 接入响应 end Note over UE: 目标同步完成, 下行已可双收 Src-->>UE: 6. 网络指示释放源链路 Note over UE: 仅在确认目标稳定后, 才释放源栈 UE->>Tgt: 7. 后续业务全走目标 Note over UE: === 切换完成: 仅目标栈活跃 === ``` 注意第 5 步的并行块：UE 一边和目标做随机接入同步，一边源链路还在持续传数据。**这就是 DAPS 消灭中断的精髓——把"先断旧再接新"变成"新旧并行，确认后断旧"。** ### 4.3 DAPS 的中断时间到底有多短？ DAPS 把中断时间从"几十毫秒"压缩到接近零，而且**上下行表现不同**： $$ T_{interrupt,DAPS}^{UL} \approx 0 \quad(\text{上行: 源链路持续到释放指示, 零中断}) $$ $$ T_{interrupt,DAPS}^{DL} \approx 0 \sim \text{极短} \quad(\text{下行: 可同时收两路, 仅在切换重配的极短瞬间}) $$ 下表把三类切换的中断表现放在一起，一目了然： | 切换类型 | 下行中断 | 上行中断 | 切换失败鲁棒性 | UE 复杂度/功耗 | |---|---|---|---|---| | 传统同步切换 | 20~40 ms 量级 | 20~40 ms 量级 | 差（命令易丢） | 低 | | 条件切换 CHO | 与传统相近 | 与传统相近 | 好（命令提前到手） | 低 | | 双栈切换 DAPS | ≈ 0（极短） | ≈ 0 | 好（双链路冗余） | **高**（双栈并发） | ### 4.4 天下没有免费的午餐 DAPS 听起来完美，为什么不全面铺开？因为代价不便宜： 1. **UE 必须具备双栈能力**：要同时跑两套 MAC、两个独立的 HARQ 实体、维持两条上行定时提前，对射频和基带芯片是硬要求，不是所有终端都支持。 2. **功耗翻倍**：双栈并发意味着切换期间功耗显著上升，对功耗敏感的物联网终端并不友好。 3. **资源消耗**：源小区在切换期间还要继续给 UE 分配资源，相当于"占着两个坑"，频谱效率下降。 4. **复杂度**：双栈下的密钥管理、PDCP 重排序、乱序处理都比单栈复杂。 所以 DAPS 是**为 URLLC 等关键业务量身定做的高级武器**，而不是所有场景的默认选择。 --- ## 五、工程权衡：为什么不全用 DAPS？ 把两种技术放一起，你会发现一个清晰的分工逻辑： | 痛点 | 谁来解决 | 牺牲了什么 | 适合谁 | |---|---|---|---| | 切换失败掉话（命令丢失、目标突变） | **CHO** | 多候选的信令开销 + UE 自主决策的复杂度 | 高铁、微站密集、信号快变 | | 切换瞬间数据中断（几十 ms 冻结） | **DAPS** | UE 功耗 + 双倍资源占用 | URLLC、工业控制、车联网关键链路 | **为什么不全用 DAPS？** 因为对 99% 的普通业务（看视频、刷网页、语音通话），20~40 ms 的切换中断根本感知不到，而上 DAPS 要付出的功耗和资源代价完全不划算。**好钢用在刀刃上**——这才是 R16 把它们设计成"可选增强"而非"默认开启"的根本原因。 更进一步，这两种技术还可以**叠加使用**：在要求最高的场景，可以同时启用 CHO 的多候选预发令 + DAPS 的双栈零中断，做到既不丢命令、又不中断数据。 --- ## 六、实战连接：工程师调试时会用到 ### 6.1 网优参数在哪里调 CHO 真正落地，网优工程师最常动的几个旋钮： - **执行事件与偏置（Off、CIO）**：调小 Off 切换更激进，调大更保守。城区高站容易乒乓，通常加大 Off 或 Hys。 - **TTT（触发时间）**：高铁场景反而要**缩短** TTT，因为信号变化太快，TTT 太长会导致 UE 还没确认就已经错过最佳切换点。 - **候选数量**：候选越多越鲁棒，但 Xn 准备信令开销越大，且占用更多目标资源，需权衡。 ### 6.2 常见调试陷阱 **陷阱一：CHO 配置下发失败** 现象：网管开了 CHO，但日志里 UE 仍在做传统切换。原因往往是 UE 的 UECapabilitySearch 里**没上报 CHO 能力**，或源/目标 gNB 能力不匹配。排查先抓 UE 能力上报消息，确认 UE 支持且网络已下发 CHO 配置（RRC 重配里能看到 `condReconfigToAddModList`）。 **陷阱二：CHO 执行后目标拒绝** 现象：UE 满足条件切到候选小区，却被目标拒绝导致失败。常见原因是**候选资源预留超时**——CHO 准备后到 UE 真正执行之间可能隔很久，目标那边的预留资源可能已被回收或拥塞。这也是为什么 CHO 配置有"有效期"，超时需重新准备。 **陷阱三：误以为 CHO 零中断** 调试 URLLC 业务时，工程师可能以为开了 CHO 就不怕中断，结果指标还是抖动。记住：**CHO 买的是成功率不是零中断**，要消灭中断得上 DAPS，别选错武器。 **陷阱四：乒乓切换** UE 在两个候选间反复跳。通常是 Hys/TTT/CIO 调得不当，让条件过于敏感。回到第 3.3 节的 A3 公式，检查这几个抗抖动参数。 --- ## 七、常见问题 **Q1：CHO 和传统切换可以共存吗？网络怎么选？** A：可以。网络根据 UE 能力、负载、移动速度等综合判断。对信号稳定的低速 UE 用传统切换（开销小）；对高铁、信号快变场景用 CHO。同一网络会按场景混用，并非二选一。 **Q2：DAPS 说"零中断"，真的一个比特都不丢吗？** A：严格说是"中断时间趋近于零"，业务连续性得到保障。下行可同时收两路、上行持续到释放指示，所以**用户层面感知不到中断**。但物理层切换重配的极短瞬间理论上仍有纳秒到微秒级的不连续，工程上视为零。配合数据转发机制，丢包也能通过重传补上。 **Q3：CHO 的候选小区最多能配几个？** A：协议支持为 UE 配置**多个**候选，每个带独立执行条件。实际现网受限于 Xn 信令开销和资源预留成本，通常配 2~4 个最常见。候选越多越鲁棒，但边际效益递减、开销递增。 **Q4：为什么 CHO 把决策权交给 UE，不担心 UE 乱切吗？** A：通过三重约束防止"乱切"：一是**执行条件由网络配置**（UE 不能自创条件）；二是 **Hys + TTT 抗抖动**；三是候选小区是网络**提前准入**过的。UE 只能在"网络圈定的候选里、按网络定的规则、确认足够久"才切，自由度是被框定的。 **Q5：普通用户什么时候能享受到 CHO/DAPS？** A：CHO 在高铁、地铁、大型场馆等场景已逐步商用，主要表现为"通话更不容易掉"。DAPS 面向 URLLC 垂直行业（工业控制、远程驾驶、智能电网），C 端用户较少直接感知，但当你坐的无人驾驶车平稳过基站、手术机器人不停顿时，背后就有它的功劳。 --- ## 参考来源 1. [5G NR中的条件切换（CHO）— CSDN](https://blog.csdn.net/kangzenghui_liu/article/details/141207584) — CHO 定义、触发条件与流程的中文解读 2. [5G无缝移动性演进：从L3切换到L1/L2触发机制深度解析](https://zhuanlan.zhihu.com/p/1948433520193143849) — 从切换中断演进角度对比传统切换、CHO、DAPS，含 R18 优化方向 3. [浅析 R16 移动性增强（DAPS/CHO/MRO）— CSDN](https://blog.csdn.net/qfturauyls/article/details/139379273) — DAPS 双激活协议栈核心思想与流程详解 4. [Conditional Handover (CHO) in 5G NR Release 16 — wirelessbrew](https://wirelessbrew.com/5g-nr/conditional-handover-in-5g-nr-release16/) — CHO 准备/执行/完成三阶段英文原理 5. [Conditional Handover in 5G: Principles, Future Use Cases and FR2 — arXiv](https://arxiv.org/abs/2204.01283) — CHO 原理学术综述，含高频段（FR2）应用分析 --- > 本文由「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 等场景全覆盖。