给有 1–3 年经验的无线工程师：把"切换为什么会掉话"拆到协议机制层面，再讲清楚 R16 引入的 CHO 与 DAPS 两大移动性增强技术，到底各自消灭了哪一类痛点。
想象你在高铁上打电话。列车以 350 km/h 飞驰，每隔几秒手机就要换一个基站——这在通信里叫切换（Handover）。绝大多数时候你感觉不到，但偶尔会听到"喂？喂？你还在吗？"，那一下的断顿，甚至直接掉线，往往就发生在切换的瞬间。
为什么有的切换丝般顺滑，有的却要人命？答案藏在一个时间窗口里：从手机断开旧基站、到接上新基站的那段"空窗期"。这段空窗有多长、会不会失败，决定了你能不能保住这通电话。
5G 在 R16 版本里专门针对这个问题，掏出了两把新武器：
今天这篇文章，我们就把这两把武器拆开看，搞清楚它们为什么这样设计，以及现网里怎么用。在开始之前，先回头看看老办法到底哪里不行。
要理解增强，得先理解基线。下面这张图是传统的"网络控制、UE 执行"的同步切换信令时序：
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 重配了吗？它就是切换命令，里面装着目标小区的频点、随机接入参数、新密钥等"过户文件"。问题在于：这条命令只能通过源基站的无线链路下发。
把上面流程对着真实场景一对照，三个致命弱点就暴露出来了：
软肋一：切换命令靠"摇摇欲坠的链路"下发
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 个出口的方向、以及"什么时候该下"的判断标准，一次性都告诉你。比如"当右边那条路比当前路快 10%，且持续 5 秒，就从最近的符合条件的出口下"。这样即使导航信号临时中断，你已经知道该怎么做，自己判断、自己执行。
核心转变：切换的"执行决策权"从网络转移到了 UE 手里，切换命令提前下发。
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 哪个条件先满足就切哪个——软肋三（只能赌一个目标）也被缓解了。
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 过度敏感。
要诚实：CHO 不能消除切换空窗期本身。UE 一旦决定执行，依然要随机接入目标、做同步——这段中断和传统切换差不多。CHO 买来的是鲁棒性（降低失败率），不是零中断。这个区分极其重要，很多新人会混淆。
| 维度 | 传统切换 | 条件切换 CHO |
|---|---|---|
| 执行决策方 | 网络（源 gNB） | UE 自主 |
| 切换命令下发时机 | 临近切换、信号已变差时 | 提前下发，可多候选 |
| 命令丢失风险 | 高（依赖恶化链路） | 低（命令已到手） |
| 切换失败率 | 较高 | 显著降低 |
| 数据中断时长 | 20~40 ms 量级 | 与传统相近 |
| 信令开销 | 单候选 | 多候选，准备阶段开销略增 |
| 典型场景 | 一般移动 | 高铁、信号快变、微站密集 |
如果说 CHO 是"提前发令"，那 DAPS 是"双卡双待"。
普通切换像"先挂断旧电话，再拨新电话"，中间一定有几秒没人说话。DAPS 像你手机里同时插了两张卡：新基站已经接通、开始通话了，旧基站那条线还不断，等新的彻底稳定了，再优雅地挂掉旧的。两路同时在线，对话一刻不停。
DAPS 的本质，是让 UE 在切换期间同时维持两个独立的协议栈——一个连源、一个连目标，两套 MAC/RLC 各跑各的，下行可以同时接收两路数据。
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 消灭中断的精髓——把"先断旧再接新"变成"新旧并行，确认后断旧"。
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 | 好（双链路冗余） | 高（双栈并发） |
DAPS 听起来完美，为什么不全面铺开？因为代价不便宜：
所以 DAPS 是为 URLLC 等关键业务量身定做的高级武器，而不是所有场景的默认选择。
把两种技术放一起，你会发现一个清晰的分工逻辑：
| 痛点 | 谁来解决 | 牺牲了什么 | 适合谁 |
|---|---|---|---|
| 切换失败掉话（命令丢失、目标突变） | CHO | 多候选的信令开销 + UE 自主决策的复杂度 | 高铁、微站密集、信号快变 |
| 切换瞬间数据中断（几十 ms 冻结） | DAPS | UE 功耗 + 双倍资源占用 | URLLC、工业控制、车联网关键链路 |
为什么不全用 DAPS？ 因为对 99% 的普通业务（看视频、刷网页、语音通话），20~40 ms 的切换中断根本感知不到，而上 DAPS 要付出的功耗和资源代价完全不划算。好钢用在刀刃上——这才是 R16 把它们设计成"可选增强"而非"默认开启"的根本原因。
更进一步，这两种技术还可以叠加使用：在要求最高的场景，可以同时启用 CHO 的多候选预发令 + DAPS 的双栈零中断，做到既不丢命令、又不中断数据。
CHO 真正落地，网优工程师最常动的几个旋钮：
陷阱一：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 端用户较少直接感知，但当你坐的无人驾驶车平稳过基站、手术机器人不停顿时，背后就有它的功劳。
本文由「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 等场景全覆盖。