首页 › deep-tech › 5G增强切换CHO与DAPS原理图解

5G增强切换：CHO与DAPS如何消灭切换掉话

你坐高铁从北京去上海，一路上手机要经过几十次基站切换。传统切换每次中断10-30毫秒，你可能感觉不到——但如果某次切换失败了，你的视频会卡顿、游戏会掉线、语音通话会中断。更糟糕的是，在高铁350km/h的速度下，传统切换的成功率并不理想。

3GPP在Release 16中引入了两大切换增强技术：条件切换（CHO）和双激活协议栈切换（DAPS）。它们从两个完全不同的角度解决切换问题——CHO解决"什么时候切"的决策问题，DAPS解决"怎么切不中断"的执行问题。今天我们就深入拆解这两个机制的底层设计哲学。

一、传统切换为什么不够好

1.1 传统切换的三步曲

在5G R15标准中，切换是一个网络控制、网络触发的过程：

测量报告：UE向源基站上报邻区测量结果
切换命令：源基站向目标基站申请资源后，向UE下发切换命令
执行切换：UE断开源基站，同步到目标基站，完成随机接入

这个过程看似合理，但存在一个致命弱点——从测量报告到切换命令之间有一个"决策空窗期"。在这个窗口内，信道条件可能已经急剧变化。

1.2 三种典型切换故障

传统切换在现网中主要面临三类问题：

故障类型	根因	现网表现
切换过晚（Too Late HO）	测量上报后，源基站处理切换请求耗时过长	UE在源小区信号已经恶化到无法解码切换命令，导致RLF
切换过早（Too Early HO）	源基站过于激进地触发切换	UE在目标小区信号还不够好就切换过去，立即失败并回退
乒乓切换（Ping-Pong）	两小区信号强度接近，来回切换	短时间内反复切换，浪费资源，用户体验极差

用一个生活类比来理解：

想象你在开车，传统切换就像是你看到前方有收费站（测量报告），然后打电话给收费站预约车道（切换请求），收费站确认后告诉你去几号车道（切换命令）。问题是：等你收到确认时，可能已经开出很远了，或者车况已经不允许你安全变道了。

flowchart TD
    A["UE上报测量报告<br/>信号开始下降"] --> B["源gNB发起切换请求<br/>Xn接口信令交互"]
    B --> C["目标gNB准备资源<br/>分配C-RNTI、 preamble等"]
    C --> D["源gNB下发RRC Reconfiguration<br/>包含切换命令"]
    D --> E{"UE能否解码<br/>切换命令？"}
    E -->|"✓ 信号尚可"| F["UE断开源侧<br/>同步到目标小区"]
    E -->|"✗ 信号已恶化"| G["RLF！切换失败<br/>进入RRC重建流程"]
    F --> H{"随机接入成功？"}
    H -->|"✓"| I["切换完成<br/>存在10-30ms中断"]
    H -->|"✗"| G

    style G fill:#ff6b6b,stroke:#333,color:#fff
    style I fill:#51cf66,stroke:#333

1.3 关键瓶颈：信令环回时延

从UE上报测量报告到收到切换命令，信令需要经过：

$$T_{total} = T_{L1_filter} + T_{L3_filter} + T_{Xn_HO_Request} + T_{Target_prep} + T_{Xn_HO_Ack} + T_{RRC_encode}$$

在典型配置下，这个环回时延可达 20-50ms。在高铁场景（350km/h ≈ 97m/s），这50ms内UE已经移动了近5米——如果此时正好处于两个基站覆盖交界处的"信号悬崖"，切换命令可能根本来不及送达。

这就是R16移动性增强的根本动因：把切换从"网络说了算"变成更灵活、更容错的方式。

二、条件切换CHO：提前备好，条件触发

2.1 核心设计思想

条件切换（Conditional Handover，CHO）的设计哲学可以用一句话概括：提前办好登机牌，但什么时候登机由你自己决定。

具体来说：

传统切换：网络决定目标小区和切换时机，UE只能被动执行
条件切换：网络提前为UE准备好候选目标小区和执行条件，UE持续评估条件，满足时自主触发切换

这就像你提前在网上办好值机手续（候选小区已准备好），但你不会在候机厅还没广播时就登机——你会等到听到你的航班号（执行条件满足）才行动。

2.2 CHO完整信令流程

sequenceDiagram
    participant UE as UE（手机）
    participant SgNB as 源gNB
    participant TgNB1 as 候选目标gNB#1
    participant TgNB2 as 候选目标gNB#2
    participant AMF as AMF

    Note over UE,SgNB: 阶段一：测量与触发
    UE->>SgNB: 测量报告（邻区信号强度）

    Note over SgNB: 源gNB决定发起CHO<br/>选择多个候选小区

    Note over SgNB,TgNB2: 阶段二：准备阶段（提前准备）
    SgNB->>TgNB1: HO Request（请求准备资源）
    TgNB1-->>SgNB: HO Request Ack（含候选配置#1）
    SgNB->>TgNB2: HO Request（请求准备资源）
    TgNB2-->>SgNB: HO Request Ack（含候选配置#2）

    Note over SgNB,UE: 阶段三：配置下发（只发一次）
    SgNB->>UE: RRCReconfiguration<br/>+ CHO配置<br/>（候选列表+执行条件）
    UE-->>SgNB: RRCReconfigurationComplete

    Note over UE: 阶段四：条件评估<br/>UE持续监测邻区信号<br/>评估是否满足执行条件

    Note over UE,TgNB1: 阶段五：自主执行（条件满足时）
    rect rgb(255, 250, 230)
        Note over UE: 候选#1的执行条件满足！
        UE->>TgNB1: 随机接入（使用候选#1的专用preamble）
        TgNB1-->>UE: Random Access Response
        UE->>TgNB1: RRCReconfigurationComplete
    end

    TgNB1->>AMF: Path Switch Request
    AMF-->>TgNB1: Path Switch Request Ack
    TgNB1->>SgNB: UE CONTEXT RELEASE<br/>（告知释放资源）
    TgNB1->>TgNB2: HO CANCEL<br/>（通知候选#2释放预留资源）

2.3 CHO配置的核心参数

源基站在RRCReconfiguration消息中下发的CHO配置包含三个关键要素：

参数	说明	典型值
候选小区列表	最多8个候选目标小区（R16）	2-4个
执行条件	基于测量事件的触发条件，如Event A3/A5	A3偏移量2-6dB
专用随机接入资源	每个候选小区的专用preamble和PRACH资源	CFRA（无竞争随机接入）

执行条件详解：

CHO的执行条件通常是测量事件与逻辑运算的组合。以Event A3为例：

$$\text{触发条件：} M_n + O_{fn} + Hys > M_s + O_{fs} + Off$$

其中： - $M_n$：邻区测量结果 - $M_s$：服务小区测量结果 - $O_{fn}, O_{fs}$：频率特定偏移 - $Hys$：迟滞值（防止乒乓） - $Off$：事件偏移量

当至少一个候选小区满足其对应的执行条件时，UE立即触发向该小区的切换——不需要再向源基站请示。

2.4 CHO的执行规则

UE收到CHO配置后，必须遵循严格的执行规则：

只执行一次：CHO配置在执行后立即失效，UE不能对同一个配置执行两次切换
最先满足原则：如果多个候选同时满足条件，UE选择最先满足条件的小区
配置存储：UE在进入RRC_INACTIVE态时保存CHO配置，回到CONNECTED态后如果配置未过期可以继续使用
取消机制：源基站可以随时通过CHO取消消息废除已下发的CHO配置

类比理解：CHO就像你提前在手机上存好了几个酒店的预订信息（候选小区），每个预订都有入住条件（执行条件）——比如"到店距离小于500米"或"价格低于300元"。你一路开车，当某个酒店的条件先满足时，直接去那个酒店入住，不需要再打电话给前台确认。

2.5 CHO vs 传统切换的关键差异

对比维度	传统切换（R15）	条件切换CHO（R16）
切换决策者	源基站	UE（基于网络预设条件）
目标小区准备时机	切换触发时准备	提前准备
从条件满足到执行	需等待网络下发命令	UE立即执行
候选小区数量	1个	最多8个（R16）
抗信道波动能力	弱（命令可能来不及送达）	强（条件实时评估）
信令开销	失败时需重试，开销大	一次准备，成功率高
适用场景	低速/中速	高速、小区边缘、密集城区

三、DAPS切换：双管齐下的零中断方案

3.1 核心设计思想

如果说CHO解决的是"什么时候切"的问题，那DAPS（Dual Active Protocol Stack，双激活协议栈）解决的就是"怎么切不中断"的问题。

传统切换是一个"先断后建"（Break-Before-Make）的过程——UE先断开源基站，再连接目标基站。这中间存在10-30ms的数据传输中断。

DAPS的核心思想非常简单却有效：在切换过程中，UE同时保持与源基站和目标基站的连接。数据传输不会中断，直到目标基站连接建立成功后，才释放源基站。

类比理解：传统切换就像你搬家——先把老房子退租，再搬进新房子，中间可能无家可归几天。DAPS切换就像你先租好新房子，搬完东西，确认一切OK后再退掉老房子。中间你两个住处都有钥匙，随时可以来回。

3.2 DAPS的协议栈行为

DAPS的名字"双激活协议栈"已经揭示了它的实现方式——UE在切换期间同时维护两套协议栈：

graph TB
    subgraph "DAPS切换期间的UE协议栈"
        direction TB
        PDCP["PDCP层（共用）<br/>负责重排序和加密<br/>管理两个RLC实体"]

        subgraph "源侧协议栈"
            RLC_S["RLC（源）"]
            MAC_S["MAC（源）"]
            PHY_S["PHY（源）"]
        end

        subgraph "目标侧协议栈"
            RLC_T["RLC（目标）"]
            MAC_T["MAC（目标）"]
            PHY_T["PHY（目标）"]
        end

        PDCP --> RLC_S
        PDCP --> RLC_T
        RLC_S --> MAC_S
        MAC_S --> PHY_S
        RLC_T --> MAC_T
        MAC_T --> PHY_T
    end

    subgraph "下行数据流"
        DL_S["源gNB → UE下行<br/>继续传输直到切换成功"]
        DL_T["目标gNB → UE下行<br/>随机接入成功后开始传输"]
    end

    subgraph "上行数据流"
        UL_S["UE → 源gNB上行<br/>切换命令后继续发送"]
        UL_T["UE → 目标gNB上行<br/>随机接入成功后切换"]
    end

    PHY_S -.->|"下行数据"| DL_S
    PHY_T -.->|"下行数据"| DL_T
    PHY_S -.->|"上行数据"| UL_S
    PHY_T -.->|"上行数据"| UL_T

    style PDCP fill:#ffd43b,stroke:#333
    style RLC_S fill:#74c0fc,stroke:#333
    style RLC_T fill:#69db7c,stroke:#333
    style MAC_S fill:#74c0fc,stroke:#333
    style MAC_T fill:#69db7c,stroke:#333

下行（DL）行为：

在DAPS切换期间，下行数据同时在源链路和目标链路上传输。UE的PDCP层负责重排序——因为数据包可能通过两条路径到达，顺序可能错乱。PDCP通过COUNT值（包含PDCP SN和HFN）来识别和排序数据包。

上行（UL）行为：

在随机接入目标基站之前：上行数据继续通过源链路发送
随机接入成功后：上行切换到目标链路
源链路在上行切换后仍保持接收下行数据

3.3 DAPS完整信令流程

sequenceDiagram
    participant UE as UE
    participant SgNB as 源gNB
    participant TgNB as 目标gNB
    participant UPF as UPF

    Note over UE,SgNB: 步骤1：DAPS切换触发
    UE->>SgNB: 测量报告
    SgNB->>SgNB: 判断UE支持DAPS能力<br/>决定发起DAPS切换

    SgNB->>TgNB: HO Request<br/>（含DAPS支持指示）
    TgNB-->>SgNB: HO Request Ack<br/>（含DAPS配置）

    SgNB->>UE: RRCReconfiguration<br/>（含DAPS-Config）
    UE-->>SgNB: RRCReconfigurationComplete

    Note over UE,TgNB: 步骤2：双激活阶段（关键！）
    rect rgb(230, 255, 230)
        Note over UE,SgNB: 源链路保持活跃
        Note over UE,UPF: 下行数据继续通过源链路传输
        UPF->>SgNB: 下行数据包
        SgNB->>UE: 下行数据（源链路）
        UE->>SgNB: 上行数据（源链路）
        SgNB->>UPF: 上行数据转发

        Note over UE,TgNB: 同时建立目标链路
        UE->>TgNB: RA Preamble（随机接入）
        TgNB-->>UE: RA Response
        Note over UE: 此时UE同时连接两个基站！
    end

    Note over UE,TgNB: 步骤3：目标链路建立完成
    UE->>TgNB: RRCReconfigurationComplete

    rect rgb(255, 240, 230)
        Note over TgNB,SgNB: 源释放阶段
        TgNB->>SgNB: HANDOVER SUCCESS
        SgNB->>UE: DAPS Source Release<br/>（源连接释放命令）
        Note over UE,SgNB: 源链路断开<br/>仅保留目标链路
    end

    TgNB->>UPF: Path Switch Request
    UPF-->>TgNB: 数据路径更新完成

3.4 DAPS的关键技术细节

（1）PDCP层处理

DAPS切换中，PDCP层是最关键的协调者：

PDCP功能	DAPS行为	目的
重排序	同时维护源和目标两个接收窗口	处理两条路径的数据包乱序
加密/解密	源侧用旧密钥，目标侧用新密钥	安全性保障
头压缩	两边独立压缩/解压	提高空口效率
重复检测	检查来自两条路径的重复包	避免数据重复递交上层

（2）源释放时机

源基站释放连接的时机非常关键——不能太早（否则失去安全网），也不能太晚（否则浪费无线资源）。DAPS的源释放由目标基站发起：

目标基站收到UE的RRCReconfigurationComplete → 确认切换成功
目标基站向源基站发送 HANDOVER SUCCESS 指示
源基站向UE发送 DAPS Source Release 命令
UE释放源侧的MAC/PHY/RLC实体

（3）失败回退机制

DAPS的一个独特优势是内置回退能力：如果UE在目标基站的随机接入失败，UE不必像传统切换那样进入RRC重建流程——它可以直接回到源基站继续通信，因为源链路一直保持活跃。这大大降低了切换失败导致的掉话率。

3.5 DAPS的中断时间分析

切换类型	中断时间来源	典型值
传统R15切换	UE断开源 → 同步目标 → RACH → RRC完成	10-30ms
DAPS切换	几乎无中断（下行持续传输）	0ms（理论值）

DAPS下行中断时间接近0ms的原因是：UE在整个切换过程中始终在源链路上接收下行数据。上行切换时存在微小中断（从源上行切换到目标上行），但远小于传统切换。

四、CHO与DAPS的协同与互斥

4.1 一个重要限制：CHO和DAPS不能同时使用

R16标准明确规定：CHO和DAPS不能同时配置给同一个UE。这是一个合理的设计取舍：

考虑因素	分析
UE复杂度	CHO需要维护候选列表和条件评估，DAPS需要维护双协议栈。两者叠加会使UE实现过于复杂
功耗	DAPS双栈已经增加功耗，再加上CHO的多候选监测会进一步加重负担
增益重叠	两者都旨在提高切换鲁棒性，同时使用增益不会线性叠加
资源效率	DAPS占用两个基站的空口资源，CHO占用多个候选小区的预留资源，叠加会浪费大量网络资源

4.2 场景适配指南

graph TD
    Start["切换增强选择"] --> Q1{"主要问题是什么？"}
    Q1 -->|"切换命令来不及送达<br/>（高速、覆盖悬崖）"| CHO["选择CHO"]
    Q1 -->|"切换中断影响业务<br/>（VoNR、URLLC）"| DAPS["选择DAPS"]

    CHO --> CHO_S{"部署场景？"}
    CHO_S -->|"高铁/高速公路"| CHO_H["CHO + 8候选小区<br/>A3事件触发"]
    CHO_S -->|"密集城区<br/>小站密集"| CHO_U["CHO + 4候选小区<br/>A5事件触发"]
    CHO_S -->|"FR2毫米波"| CHO_M["CHO + 条件组合<br/>信号+定时器"]

    DAPS --> DAPS_S{"业务类型？"}
    DAPS_S -->|"VoNR语音"| DAPS_V["DAPS切换<br/>保障语音连续性"]
    DAPS_S -->|"URLLC工业控制"| DAPS_U["DAPS切换<br/>零中断保障"]
    DAPS_S -->|"普通eMBB"| Legacy["传统切换即可<br/>中断可接受"]

    style CHO fill:#74c0fc,stroke:#333
    style DAPS fill:#69db7c,stroke:#333
    style Legacy fill:#dee2e6,stroke:#333

五、R17/R18的演进增强

5.1 R17增强

R17对CHO做了重要扩展：

CHO扩展至NR-DC场景：条件切换可以应用于MR-DC（Multi-RAT Dual Connectivity）中的辅节点变更
CHO评估条件增强：支持更复杂的条件组合（AND/OR逻辑）

5.2 R18增强

R18进一步增强了CHO：

增强项	内容
候选小区数量扩展	从8个增加到更多候选
跨系统CHO	开始研究5G到4G的条件切换（R16仅支持NR系统内）
CHO与SDT结合	RRC_INACTIVE态小数据传输场景下的条件切换
LTM（L1/L2驱动的移动性）	引入基于L1测量的快速切换，进一步减少切换时延

六、现网部署实战

6.1 CHO部署调优要点

候选小区数量选择： - 候选小区太少（1-2个）：无法覆盖所有可能的移动方向 - 候选小区太多（7-8个）：浪费网络资源（每个候选都需要预留 preamble、C-RNTI等） - 推荐值：高铁场景4-6个，城区3-4个

执行条件参数调优： - A3偏移量设置过大：触发过晚，可能错过最佳切换窗口 - A3偏移量设置过小：触发过早，导致不必要的切换 - 推荐值：高铁场景A3偏移2-4dB，城区A3偏移3-6dB

CHO取消定时器： - 源基站需要设置CHO配置的有效期，避免候选小区资源长期被占用 - 如果UE长时间不触发CHO，源基站应发送CHO取消命令释放资源

6.2 DAPS部署调优要点

UE能力协商： - DAPS需要UE在UECapabilityInformation中声明支持DAPS能力 - 网络只在确认UE支持DAPS时才会发起DAPS切换 - 目前支持DAPS的终端比例在逐步提升

DRB级别的DAPS配置： - DAPS可以按DRB（Data Radio Bearer）粒度配置，不必所有承载都使用DAPS - 建议对语音承载（QCI 1/5QI 1）和URLLC承载配置DAPS，普通数据承载可使用传统切换 - 这样可以在保障关键业务连续性的同时降低UE功耗

6.3 调试中的常见陷阱

陷阱1：混淆CHO失败与传统切换失败

CHO失败的RRC重建原因码与传统切换不同。在分析路测日志时，需要注意： - CHO切换失败通常记录为"CHO execution failure" - 传统切换失败通常记录为"handover failure"或"RLF" - 两者在优化策略上是不同的

陷阱2：忽略DAPS的功耗影响

DAPS在切换期间UE同时维护两套射频链路，功耗显著增加。在电量紧张的场景下（如IoT终端），应谨慎使用DAPS。

陷阱3：CHO候选小区资源泄漏

如果CHO配置后UE从未触发切换（比如移动方向改变），候选小区上的预留资源不会被自动释放。运维人员需要监控候选小区的资源利用率，确保没有大量"僵尸预留"。

七、总结

CHO和DAPS代表了5G移动性管理的两个重要演进方向：

	CHO（条件切换）	DAPS（双激活协议栈）
解决的问题	切换决策时延	切换执行中断
核心机制	提前准备+条件触发	双链路并行传输
中断时间	与传统切换类似	接近0ms
切换成功率	显著提升	显著提升
适用场景	高速移动、覆盖边缘	时延敏感业务
UE复杂度	中等	较高
R16限制	仅NR系统内	仅NR系统内

两者虽然不能同时使用，但它们共同构成了5G移动性增强的完整工具箱。网络可以根据场景灵活选择最适合的方案。

常见问题

Q1: CHO和传统切换的根本区别是什么？

A: 根本区别在于"谁来决定切换时机"。传统切换由源基站决定——它收到测量报告后，先向目标基站申请资源，再把切换命令下发给UE。CHO则由源基站提前准备好候选目标，但把"什么时候切"的决定权交给UE——UE实时评估执行条件，满足时立即切换，不再需要等待网络命令。这消除了"信令环回时延"这个瓶颈。

Q2: DAPS切换真的能做到0ms中断吗？

A: "0ms"是理论值，实际工程中可能有极微小的中断。下行传输确实可以做到近零中断，因为源链路在整个过程中持续传输数据。但上行方向，UE需要从源上行切换到目标上行，存在一个极短的切换时间。总体来说，DAPS将中断时间从10-30ms降低到接近0ms，对VoNR和URLLC等时延敏感业务有显著改善。

Q3: 为什么CHO和DAPS不能同时使用？

A: 主要是UE实现复杂度和资源效率的权衡。CHO需要UE持续评估多个候选小区的条件（计算开销），DAPS需要UE同时维护两套完整的协议栈（射频开销）。两者叠加会使UE的处理能力和功耗达到难以承受的水平。此外，两者的增益有重叠——如果CHO已经通过提前准备避免了切换失败，再用DAPS消除中断的边际收益就不大了。

Q4: 工程师在路测中如何判断网络是否启用了CHO？

A: 关键看RRCReconfiguration消息的内容。如果消息中包含condReconfigToAddModList字段，说明网络配置了CHO。UE收到CHO配置后会持续评估条件，路测软件中可以看到"CHO Condition Evaluation"状态。如果看到UE在满足条件后直接向目标小区发起随机接入（没有先收到新的切换命令），就说明执行了CHO。

Q5: DAPS切换中，数据包会不会重复或丢失？

A: 设计上不会。下行方向，源基站持续发送数据直到收到切换成功指示，目标基站在此期间开始通过新路径转发数据。PDCP层通过COUNT值（序列号+超帧号）进行重复检测和重排序——如果同一个COUNT的数据包从两条路径都收到了，PDCP会丢弃重复包。上行方向，UE在切换到目标链路前通过源链路继续发送，源基站会转发这些数据到核心网，避免丢失。

参考来源

Conditional Handover in 5G - Principles, Future Use Cases and FR2 Performance — IEEE开放论文，详细解释CHO原理和毫米波场景性能分析
ShareTechnote: 5G CHO — 经典技术教程站，包含CHO信令流程和参数说明
Ericsson Blog: The Key to Mobility Robustness in 5G Networks — 爱立信官方博客，R16移动性增强的实践视角
Devopedia: DAPS Handover — DAPS切换技术百科，涵盖原理和协议栈行为
知乎专栏: NR双激活协议栈(DAPS)切换 — 中文技术社区详细解读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学通信知识星球海报-扫码加入