设想你在开车，正在用手机开一场重要的远程会议。车飞速穿过几个基站覆盖区，每一次跨区，画面都会"卡顿半秒"。对刷短视频的用户来说，这半秒微不足道；但对工业机器人、自动驾驶、远程手术这类超可靠低时延（URLLC）业务来说，这半秒就是事故。
这段卡顿，专业上叫切换中断时间（Handover Interruption Time）。传统切换走的是"先断后连"（break-before-make）的路子：终端必须先松开源基站，再去和目标基站重新对暗号、重新同步、重新排队等数据。这个空窗期，数据流是断的。
那么，能不能像"双卡双待"手机一样——在切到新卡之前，旧卡还在通话，等新的稳了再断旧的？让交接的过程里永远有人在岗，做到"换岗不脱岗"？
这正是5G在R16引入的双激活协议栈（DAPS, Dual Active Protocol Stack）切换要解决的问题。它的目标很激进：把切换中断时间压到接近0毫秒。
今天这篇，我们就拆开DAPS的"零中断魔术"，看看它是怎么改造协议栈、怎么编排信令、又付出了哪些代价。
要理解DAPS为什么有效，先得搞清楚传统切换的"缝隙"由哪些时间片拼成。一次传统（先断后连）切换，从终端收到切换命令那一刻起，中断大致由下面几块组成：
| 中断组成 | 大致含义 | 典型耗时（FR1同频） |
|---|---|---|
| 源链路释放处理 | 终端停止与源小区的收发 | 1～2 ms |
| 射频重调（异频才有） | 重新调谐到目标频点 | 0（同频）/ 数 ms（异频） |
| 目标下行同步 | 捕获目标小区的同步信号块 | 数 ms |
| 随机接入（RACH） | 与目标基站完成上行接入握手 | 数～十几 ms |
| 首包到达 | 目标侧第一个下行数据包送达 | 1～数 ms |
把这几项加起来，传统同频切换的中断通常在十毫秒量级；到了毫米波频段，由于波束扫描的存在，这个缝隙还可能更长。对普通业务无所谓，但对URLLC"99.999%可靠性+1ms空口时延"的目标，十几毫秒的中断足以把可靠性指标打穿。
用一句话概括传统切换的命门：
它在物理上要求"独占"——终端只有一套收发链，必须先释放源，才能腾出手去抓目标。
DAPS的核心突破，正是要打破这个"独占"假设。
DAPS换了一种哲学：先连后断。终端在收到切换命令后，并不立即扔掉源链路，而是同时维持源和目标两条激活链路，直到目标链路稳稳接管，才释放源链路。
我们可以用一张时间线对比直观感受两者的差别：
sequenceDiagram
participant S as 源gNB
participant U as 终端(UE)
participant T as 目标gNB
Note over S,U: 【传统切换】break-before-make
S->>U: 切换命令
Note over U: ❌ 停止源收发(中断开始)
U->>T: RACH同步(数据真空)
T->>U: 首个下行包(中断结束)
Note over S,U: 中断≈十毫秒量级
Note over S,U: ━━━━━━━━━━━━━━━━━
Note over S,U: 【DAPS切换】make-before-break
S->>U: DAPS切换命令
Note over U: ✅ 源链路继续收发(不断)
U->>T: RACH同步(同时源仍在传)
T->>U: 目标链路就绪
Note over U: 业务无缝迁移到目标
S->>T: SN STATUS转移+数据转发
T->>S: 释放源上下文
Note over U: 此时才断开源(≈0中断)
关键差别一目了然：传统切换在中间有一段"真空"，而DAPS全程至少有一条链路在传数据，切换动作发生在两条链路重叠的窗口里，用户感知不到任何中断。
打个更生活化的比方：传统切换像换岗时先下班再上岗，中间岗位空着；DAPS像新旧保安并肩站岗，新保安到岗、熟悉环境、确认无误后，老保安才离开，全程岗位上从未没人。
"先连后断"听起来简单，但要在一个终端里同时维持两条激活链路，协议栈必须动手术。DAPS对承载（DRB）的改造是这样的：
flowchart TB
subgraph UE["终端(UE) DAPS承载结构"]
PDCP["PDCP实体（共用·重排序/加密）"]
SRLC["源侧RLC实体"]
TRLC["目标侧RLC实体"]
SMAC["源MAC实体"]
TMAC["目标MAC实体"]
PDCP --> SRLC
PDCP --> TRLC
SRLC --> SMAC
TRLC --> TMAC
end
SMAC -.收发.-> SRC["源小区(继续下行)"]
TMAC -.接入.-> TGT["目标小区(新建)"]
style PDCP fill:#cfe8ff,stroke:#1976d2
style SRLC fill:#ffe0b2,stroke:#e65100
style TRLC fill:#c8e6c9,stroke:#2e7d32
为什么要这样设计？因为切换的本质是一条逻辑承载在不同物理支路间迁移。PDCP是"账本"，记录哪些包发了、哪些没发、序号到哪了；RLC/MAC是"运输队"。DAPS让一个账本同时指挥两支运输队（源队继续送旧货，目标队准备接新货），账本负责把两支队送来的货按序号理顺，避免重复或乱序。
这一点和双连接（DC）的分流承载很像，但用途完全不同：DC是为了"一份数据两条腿走、凑吞吐量"，是稳态的长期配置；DAPS是为了"切换这一瞬间的平稳过渡"，是短暂的临时态。
一句话记牢：DAPS = 一个账本（PDCP）+ 两个运输队（源RLC/MAC + 目标RLC/MAC）+ 一个重叠窗口。
现在把完整的信令时序摊开看。这是一次基于Xn接口的DAPS切换，请重点留意源链路在何时才真正断开：
sequenceDiagram
autonumber
participant U as 终端UE
participant S as 源gNB
participant T as 目标gNB
participant AMF as 核心网(AMF/UPF)
U->>S: 1.测量报告(MeasurementReport)
Note over S: 判决触发DAPS切换
S->>T: 2.切换请求(Handover Request, Xn)
Note over T: 准入、分配资源、生成DAPS切换命令
T->>S: 3.切换请求确认(含DAPS切换命令)
S->>U: 4.RRC重配(reconfigurationWithSync=切换命令)
Note over U: ★关键:不断开源!同时启动目标RACH
par 源链路保持激活
S-->>U: 源侧继续下行数据
U-->>S: 源侧继续上行数据
and 目标链路建立
U->>T: 5.随机接入(RACH,可RACH-less)
end
S->>T: 6.SN STATUS转移(上行计数/下行状态)
S->>T: 7.数据转发(在途下行包)
U->>T: 8.RRC重配完成(经目标侧)
Note over U,T: 目标链路就绪,业务无缝迁移
T->>AMF: 9.路径切换请求(Path Switch, N2)
AMF->>T: 10.路径切换响应(N3隧道改到目标)
T->>S: 11.UE上下文释放(UE Context Release)
Note over S: ★此刻才释放源小区链路
把这张时序图和传统切换对照看，你会发现DAPS在第4步后多了两个"并行轨"，这是整个设计的灵魂所在。梳理几个关键节点：
第2～3步，切换请求与确认：源gNB通过Xn向目标gNB发起请求，目标gNB在响应里带回一份"透传容器"——里面装着给UE的DAPS切换命令（即 reconfigurationWithSync），源gNB不解析、只转发。
第4步，下发切换命令：UE收到命令后，不释放源链路，而是立即把目标小区的配置激活，同时保持源的收发。这是DAPS与传统切换最大的分水岭。
第5步的并行轨：源侧数据照常流淌，目标侧同时进行随机接入。两条腿同时迈，这就是零中断的物理来源。
第6步，SN STATUS转移：源gNB把PDCP序列号状态（哪些上行包还没收到确认、下行序号发到哪了）交给目标gNB，让目标gNB能无缝续上。
第7步，数据转发：源gNB把还在路上、没收到的下行包转发给目标gNB，避免丢包。
第8～9步，完成与路径切换：UE通过目标侧回送完成消息，目标gNB向核心网请求把N3下行隧道改路到自己这边。
第11步，才释放源：直到此刻，源小区链路才被释放。在此之前，UE始终有一条激活链路在传数据。
中断时间之所以趋近于0，本质上是因为"断开源"这个动作被推迟到了"目标已就绪"之后，两件事不再串行，而是并行重叠。
从时序抽象成公式，传统切换的中断时间近似为各段串行之和：
$$ T_{int}^{legacy} \approx T_{retune} + T_{sync}^{DL} + T_{RACH} + T_{first} $$
而DAPS由于源链路持续在岗，目标侧的同步与接入完全隐藏在源侧数据传输的时间窗口内，中断时间近似为：
$$ T_{int}^{DAPS} \approx \max(0,\; T_{switch} - T_{overlap}) \;\to\; \approx 0 $$
其中 $T_{switch}$ 是业务从源迁到目标的那一瞬切换动作耗时，$T_{overlap}$ 是两条链路重叠的可用时间。只要重叠窗口足够（通常都足够），中断就趋近于0。
| 维度 | 传统切换 | DAPS切换 |
|---|---|---|
| 哲学 | 先断后连 | 先连后断 |
| 源链路 | 切换命令后立即断 | 目标就绪后才断 |
| 协议栈 | 单激活 | 双激活（双MAC/双RLC） |
| 中断时间 | 十毫秒量级 | ≈0 ms |
| 失败回退 | 需RRC重建，代价大 | 可优雅退回源 |
| 适用 | 通用业务 | URLLC、语音、实时业务 |
| 代价 | 低 | UE复杂、功率分摊 |
DAPS还有一个常被低估的优势——切换失败时的鲁棒性。
传统切换一旦目标接入失败，源链路早已释放，UE只能走RRC连接重建，相当于"断线重连"，业务中断动辄上百毫秒，甚至掉话。
而DAPS由于源链路一直在线，目标失败时只要源还可用，UE可以直接退回源继续传，像是什么都没发生过：
flowchart LR
A["UE发DAPS切换"] --> B{"目标接入成功?"}
B -- 是 --> C["业务迁移到目标<br/>释放源(正常完成)"]
B -- 否 --> D{"源链路仍可用?"}
D -- 是 --> E["优雅退回源<br/>业务不中断"]
D -- 否 --> F["RRC重建(最后手段)"]
style E fill:#c8e6c9,stroke:#2e7d32
style F fill:#ffcdd2,stroke:#c62828
这让DAPS在高移动、信号波动剧烈的场景（高铁、密集城区）天然多了一层保险——既快，又稳。
把DAPS和它的"同期同学"条件切换（CHO）放在一起比，思路非常清晰。两者都是R16为提升移动性引入的，但解决的是完全不同的痛点：
| 维度 | 传统切换 | 条件切换(CHO) | DAPS切换 |
|---|---|---|---|
| 解决痛点 | 基础移动性 | 切换可靠性/成功率 | 切换中断时间 |
| 核心机制 | 命令即执行 | 提前准备、满足条件再执行 | 双链并行、先连后断 |
| 准备时机 | 即时 | 提前下发 | 即时 |
| 中断时间 | 十毫秒量级 | 十毫秒量级 | ≈0 |
| 失败鲁棒性 | 弱 | 强（条件触发，时机更准） | 强（可退回源） |
| 代价 | 低 | 中（需维护候选+条件） | 高（双栈、功率分摊） |
可以这样记：
有意思的是，三者并不互斥，规范里DAPS和条件切换还可以组合使用：提前准备 + 双链并行，兼顾"准"与"快"。
理论落到现网，工程师会在这些地方和DAPS打交道：
1. 能力协商是前提。 DAPS是UE可选能力，并非所有终端都支持。网络侧只有在UE上报支持DAPS、且配置了DAPS承载时，才会下发DAPS切换命令。调试时若发现某UE从不走DAPS，先查能力位和承载配置，别急着怀疑基站。
2. 功率分摊（Power Sharing）是核心代价。 终端要同时在上行维持源和目标两条链路，发射功率必须在这两条链路间分摊。这会降低两条链路上的上行质量，可能出现覆盖收缩、上行SINR下降。优化时关注的不是"中断够不够短"，而是"双链重叠期内的上行功率够不够用"。
3. 适用场景聚焦。 DAPS主要服务于对中断敏感的业务：URLLC（工业控制、远程操作）、VoNR语音连续性、云游戏、V2X等。对普通尽力而为业务，传统切换已足够，强行用DAPS只增加复杂度和功耗。
4. 调试常见坑： - 误以为DAPS适用异频：DAPS要求终端能同时收发两个小区，基本限于同频（或终端具备双射频链的异频场景），异频场景因需重新调谐射频，"先连后断"难以直接成立。 - 只看中断时间不看上行代价：DAPS把代价转嫁到了上行功率和UE复杂度上，评估时要算总账。 - 混淆DAPS与双连接：DC是稳态的吞吐增强，DAPS是切换瞬间的过渡机制，别在抓包时把两者信令搞混。
DAPS很好，但不是免费的午餐，它至少带来三类代价：
所以工程上的判断标准很朴素：中断带来的损失，是否大于双栈带来的代价？ 对一条人命攸关的远程手术链路，值；对一条后台同步的微信消息，不值。
DAPS用"双激活协议栈"把切换从中断的"先断后连"改造成无缝的"先连后断"。它的智慧不在于更快的同步算法，而在于改变了交接的哲学——让新旧链路并肩站岗、重叠过渡，把"真空窗口"彻底消除。
记住三个关键画面就够了：
当你的业务对"卡顿零容忍"，DAPS就是那道让切换"无感"的关键设计。
Q：DAPS和双连接（DC）是不是一回事？ A：不是。两者协议栈结构相似（共用PDCP+多条RLC支路），但用途不同：DC是稳态的长期配置，目的是分流提速、凑吞吐；DAPS是切换瞬间的临时机制，目的是平稳过渡、消除中断。一个为"跑得快"，一个为"换得稳"。
Q：DAPS真的能做到完全0毫秒中断吗？ A：是"趋近于0"。业务在重叠窗口内从源无缝迁移到目标，用户和上层业务感知不到中断，但协议层那一切换动作本身仍耗极短时间，因此业界普遍表述为"≈0ms"或"近零中断"。
Q：为什么DAPS基本只用于同频切换？ A：因为"先连后断"要求终端能同时收发源和目标两个小区。同频时终端可同时处理；异频则需重新调谐射频，除非终端具备独立的双射频链，否则无法真正并行，所以DAPS主要落在同频场景。
Q：DAPS和条件切换（CHO）该选哪个？ A：看痛点。CHO解决切换成功率（提前准备、条件触发，但中断时间不变）；DAPS解决切换中断时间（双链并行、近零中断）。两者不互斥，对极敏感业务可组合使用——既提前准备又双链过渡，兼顾稳与快。
Q：终端功率有限，DAPS同时维持两条上行链路不会影响覆盖吗？ A：会，这正是DAPS的主要代价。终端需在源和目标间分摊上行发射功率（半静态或动态），导致两条链路上行质量下降，小区边缘尤其明显。所以DAPS评估要算"中断收益 vs 上行代价"的总账，而非只盯着中断时间。
本文由「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 等场景全覆盖。