图解连接态DRX：手机为什么敢「上班打盹」

一、从一个生活类比说起

想象一个 7×24 小时值班的前台保安。领导的要求是：有访客必须立刻接待，但公司一年到头也没几个访客。如果他每一秒都瞪大眼睛盯着门口，人很快就累垮了；如果他干脆睡觉，又可能错过重要客户。

真实世界里优秀保安的做法是：大部分时间坐着休息，但每隔固定时间抬头看一眼门口；一有客人来，就连续忙碌一阵子；忙完之后，再回到「定时抬头看门口」的节奏，并且越忙完越容易进入深度休息。

手机在 RRC 连接态下面对的就是完全相同的处境：网络随时可能通过 PDCCH（物理下行控制信道）呼叫它「有你的数据」，但实际上绝大部分时间 PDCCH 上根本没有调度它的任何信息。如果手机在连接态下每个符号都醒来监听 PDCCH，射频收发机和基带解码器就必须持续工作，耗电量将完全不可接受。

解决这个矛盾的机制，就是连接态不连续接收（Connected mode DRX，简称 CDRX）：手机在保持 RRC 连接的前提下，周期性地「睡一会、醒一会」，只在特定时间窗内监听 PDCCH，其余时间关闭接收机大部分电路。

二、为什么省电这件事如此关键

要理解 DRX 的设计动机，先看手机的功耗结构。手机通信相关的功耗大致由三部分构成：

• 射频前端（功放、收发器）：收发信号时功耗最高；
• 基带处理器：解码 PDCCH、PDSCH，编码 PUSCH 等；
• 常驻开销：晶振、时钟、监听唤醒信号的极小电路。

其中「每个子帧都盲解 PDCCH」是最烧电的行为之一，因为它要求基带以最高节奏持续运转。而大量实测研究表明，智能手机在屏幕熄灭待机时，绝大部分耗电恰恰来自周期性被网络「骚扰」：心跳包、推送信令、各种 keepalive。每一次信令交互都要把手机从浅睡中拉起来，走一遍「听 PDCCH → 收数据 → 回 ACK」的完整流程。

DRX 的本质，就是把「手机什么时候听」这件事合同化、周期化：手机和基站提前签好一份「作息合同」——什么时间必须值班、值班时要不要加班、加班后睡多久。基站严格按合同在手机值班时才调度它，手机则放心大胆地在合同允许的时段断电休息。

一个重要的边界要先划清：DRX 分为空闲态 DRX 和连接态 DRX，两者是完全不同的东西。空闲态 DRX 实际上就是「寻呼周期」——手机没有连接，按核心网给的周期醒来听寻呼；而本文主角 CDRX 是手机已经保持 RRC 连接、拥有上下文的情况下，由基站通过 RRC 重配消息下发的一套 MAC 层作息规则。后者参数更精细，也是日常网络优化中打交道最多的。

三、CDRX 的核心机制：一份精密的「作息合同」

3.1 最小骨架：周期 + 唤醒窗

CDRX 最基础的骨架只有两个要素：

1. DRX 周期（Long Cycle）：多久「值班」一次，例如 40ms、320ms、1280ms；
2. 唤醒窗（OnDuration）：每个周期开始时，强制醒来监听 PDCCH 的时长，例如 2ms、10ms。

如果唤醒窗内 PDCCH 上没有任何针对该 UE 的调度，手机监听完就继续睡；如果恰好有调度，故事就进入了「加班模式」。整个过程可以用一张时间轴示意：

flowchart LR
  subgraph CY["一个DRX周期"]
    direction LR
    A["OnDuration<br/>定时唤醒监听PDCCH"] --> B["活动期<br/>有调度则持续收发"]
    B --> C["睡眠期<br/>关闭PDCCH监听"]
  end
  C --> D["下一周期起点<br/>再次进入OnDuration"]

3.2 完整参数家族

真实合同远比「周期+唤醒窗」复杂。下表列出 CDRX 的核心参数，用类比方式解释每个参数的职责（参数名即工程师在 RRC 信令里看到的真实名字）：

注意一个 5G 相对 4G 的细节差异：LTE 中这些计时器基本以毫秒为单位，而 NR 中与 HARQ 相关的计时器改用符号或时隙为单位——这源自 NR 子载波间隔可变（15kHz 到 120kHz+），固定毫秒无法适配不同 numerology 下的调度节奏。

3.3 活动期的完整状态机

「手机到底什么时候是醒着的」这个问题，答案是 CDRX 的灵魂。我们把整个状态流转画出来：

flowchart TD
  S["睡眠中<br/>等待下一次OnDuration"] --> W["OnDuration到来<br/>开始监听PDCCH"]
  W --> P{"PDCCH上有<br/>我的调度吗"}
  P -->|有数据首传| I["启动drx-InactivityTimer<br/>进入活动期"]
  P -->|无调度| TO["唤醒窗结束<br/>回到睡眠"]
  I --> P2{"活动期内又收到<br/>新的PDCCH调度吗"}
  P2 -->|是| I
  P2 -->|InactivityTimer超时| H{"还有HARQ进程<br/>等重传吗"}
  I --> H
  H -->|是| RT["drx-RetransmissionTimer运行<br/>继续监听"]
  H -->|否| SL["进入睡眠"]
  RT -->|等到重传| I
  RT -->|超时无重传| SL

从状态机可以读出三条关键规则：

规则一：每次被调度都会「续命」。 只要 PDCCH 上出现了该 UE 的调度（无论上下行），drx-InactivityTimer 就被重置。这意味着持续突发的数据流会让手机一直保持清醒，直到流量真正停歇。这是一个自适应设计：忙时彻底忙，闲时才休息。

规则二：HARQ 重传期间不许睡。 下行数据首传后，接收端要解码并可能反馈 NACK 请求重传。在 HARQ 往返时延内，UE 先启动 drx-HARQ-RTT-Timer（这段时间可以小睡，因为重传调度一定不会来）；RTT 超时后立刻启动 drx-RetransmissionTimer（这段时间必须醒着，因为重传调度随时可能到达）。用公式表达这层关系：

$$T_{\text{监听重传}} = T_{\text{RetransmissionTimer}}, \quad T_{\text{可小睡}} = T_{\text{HARQ-RTT-Timer}}$$

这个设计的精妙之处在于：把「肯定不用听」和「可能要听」的时间段严格分开，前者大胆睡，后者必须醒，一毫秒的监听都不浪费。

规则三：上行发送也受活动期约束。 数据到达 UE 缓存时，UE 需要发调度请求（SR）向基站申请上行资源——但 SR 只能在活动期内发送。如果此刻正在睡觉，UE 只能攥着数据等到下一次 OnDuration。这个细节在排障时极其重要，后文详述。

四、短周期与长周期：刚忙完和真正闲下来是两回事

观察现实：一个用户刚看完一段视频，紧接着再点开下一段的概率，远大于他一小时后才看。流量具有突发后紧随的自相关特性。CDRX 用「双周期」结构优雅地建模了这种行为：

flowchart TD
  A["数据传完<br/>InactivityTimer超时"] --> B["进入短DRX周期<br/>启动drx-ShortCycleTimer"]
  B --> C{"短周期内<br/>又来新数据"}
  C -->|是| D["回到活动期<br/>重新计数"]
  D --> A
  C -->|否| E["ShortCycleTimer耗尽<br/>切换到长DRX周期"]
  E --> F["深度低频睡眠<br/>功耗最低"]

设计逻辑非常直觉化：

• 刚忙完 → 短周期：数据大概率还会来，用短的睡眠片段（如 20ms～80ms）保持「浅睡易唤醒」状态，牺牲一点功耗换取极低的响应时延；
• 连续几个短周期都无事发生 → 长周期：确认流量真的停了，切换到大周期（如 320ms、1280ms）深度睡眠，把功耗压到最低。

两种周期的权衡总结如下：

可以估算一下占空比与功耗的关系。定义占空比为清醒时间占比：

$$D = \frac{T_{\text{on}} + T_{\text{inactivity}}}{T_{\text{cycle}}}$$

若近似认为清醒功耗为 $P_{\text{awake}}$、睡眠功耗为 $P_{\text{sleep}}$，则平均功耗为：

$$P_{\text{avg}} \approx P_{\text{sleep}} + \left(P_{\text{awake}} - P_{\text{sleep}}\right) \times D$$

由于 $P_{\text{awake}}$ 与 $P_{\text{sleep}}$ 可相差一个数量级以上，把周期从 40ms 拉长到 640ms，待机功耗可能下降数倍——这就是为什么后台静默应用对电池寿命影响巨大，也是为什么芯片厂商与运营商都如此看重 CDRX 参数。

五、5G 带来了什么新花样

5G 在沿用 CDRX 骨架的同时，针对「睡着也要耗电」这个残余问题打了三个补丁：

补丁一：唤醒信号（WUS）。 以前即使配置了 DRX，UE 每到 OnDuration 都必须真正醒来解 PDCCH——而解 PDCCH 本身就是耗电大户，绝大多数时候解出来是空的。5G 引入了唤醒机制：基站在唤醒窗到来之前，先发一个极简、极低功耗的指示信号（业内俗称 WUS）。手机用一个专用的低功耗检测器瞄一眼即可：

sequenceDiagram
  participant G as 基站
  participant U as 手机
  Note over G,U: 唤醒窗到来之前
  G->>U: 低功耗唤醒指示WUS
  alt 指示唤醒
    U->>U: 正常醒来监听PDCCH
  else 指示继续睡
    U->>U: 跳过本次唤醒窗 保持睡眠
  end

相当于把「每班必到」改成了「保安队长提前发微信：今天没事，别来了」，把最贵的「解 PDCCH」环节从大多数空巡中省掉。

补丁二：跨时隙调度。 传统调度里，UE 收到 PDCCH 的同一时隙往往就要收/发数据，因此不敢错过任何 PDCCH 机会。跨时隙调度让基站提前几个时隙把调度信息发出来，UE 明确知道「哪些时隙 PDCCH 上不可能有自己的信息」，即使处于活动期也可以局部休眠。

补丁三：UE 辅助信息。 手机可以向网络主动报告自己的业务预期（例如「接下来几十秒没有流量」），基站据此提前让 UE 进入更深度的睡眠，而不是等计时器一格格走完。

此外，RRC_INACTIVE（非激活态）也继承了 DRX 思想并允许更长的非连续接收间隔，面向的是「偶尔发一小包」的物联网型流量，相当于在连接态与空闲态之间加了一档更省电的中间档位。

六、实战连接：工程师在哪里会撞上 CDRX

6.1 调试时延问题时的「DRX 帽子」

最经典的现场问题：用户抱怨时延大，但路测软件显示速率和 SINR 都正常。此时第一个该检查的就是 CDRX 配置。

数据在睡眠期到达时，必须等下一次唤醒窗，平均等待时间近似为：

$$\bar{T}{\text{wait}} \approx \frac{T$$}} - T_{\text{on}}}{2

代入一组典型后台配置（长周期 320ms、OnDuration 10ms），平均额外时延约 155ms——这足以让 ping 值从 20ms 恶化到 170ms 以上，且呈现出以周期为步长的阶梯状抖动。看到 ping 时延直方图出现 320ms（或 640ms、1280ms）间隔的多峰结构，基本可以直接断言「这是 CDRX 的签名」。

6.2 上行首包延迟：最容易踩的坑

下行业务到达时，基站遵守合同、等 UE 醒来再发即可；但上行业务要等 UE 醒来后先发 SR、再等授权、才能发数据，链条更长。所以「应用层发出请求很慢」类问题（如某 App 后台上传卡顿）往往是上行 SR 等待唤醒窗所致，与下行无关。此时适当缩短周期或加长 onDurationTimer，比盲目加功率、查干扰有效得多。

6.3 功耗与 KPI 的跷跷板

调参时永远在跷跷板两端找平衡：

• 省电方向：拉长周期、缩短唤醒窗、缩短 InactivityTimer——代价是时延和吞吐劣化（活动期变短，调度机会减少，峰值速率受限）；
• 性能方向：缩短周期、加长唤醒窗——代价是待机电流上升，用户续航投诉。

典型经验取向：游戏、实时通话类业务用短周期（甚至不启用深层 CDRX）；后台 IM、穿戴设备用长周期。现网常见做法是在 QoS 流与 DRX 参数间做映射，让不同业务特征获得不同作息表。

6.4 信令怎么看

在空口抓包或基站日志里，CDRX 配置出现在 RRCReconfiguration 消息的 drx-Config 字段中。排障第一步永远是核对实际下发的参数组合：常见故障包括短周期与长周期不成整数倍关系（合法但会造成唤醒相位漂移）、HARQ 计时器与调度周期冲突导致重传监听窗错位等。另外注意：CDRX 是基站级的 MAC 层行为，核心网不感知——所以核心网侧的信令追踪查不出「手机在睡」，这是定位问题时容易走错的岔路。

6.5 三个常见误解

1. 「DRX 是让手机关机」——错。RRC 连接、安全上下文、承载全部保持，只是暂停监听 PDCCH；网络视角下 UE 一直「在线」。
2. 「上下行需要各自独立的 DRX」——错。DRX 只有一套活动期定义，上行业务通过「只在活动期发 SR / 基站只在活动期调度上行」来跟随同一张作息表。
3. 「活动期越长越保险」——错。活动期与 HARQ 重传监听相互叠加，可能形成「重传拖着 InactivityTimer、InactivityTimer 又拖着重传」的连锁，导致清醒时间远超预期，功耗不降反升。

常见问题

Q1：连接态 DRX 和空闲态寻呼周期的本质区别是什么？ A：空闲态 DRX（寻呼周期）是手机没有连接时按核心网下发的周期醒来监听寻呼，被呼中还要先走连接建立流程才能传数据；连接态 DRX 是手机保持完整连接上下文时按基站配置的 MAC 作息监听 PDCCH，醒来就能直接收发。前者的参数由核心网侧控制、粒度粗，后者由基站 RRC 专用信令配置、粒度细到毫秒和符号。

Q2：drx-InactivityTimer 和 drx-RetransmissionTimer 都会让手机「多醒一会」，它们有何不同？ A：InactivityTimer 是「业务层面」的加班——只要有新调度就重置，表达的是流量还在继续；RetransmissionTimer 是「HARQ 进程层面」的等待——针对每一个未完成确认的传输块独立运行，表达的是旧数据还没交付成功。两者可以同时运行，任一处于运行状态手机就必须保持清醒。

Q3：为什么有了长周期还要设计短周期，直接全用长周期不是更省电吗？ A：全用长周期在流量完全静默时确实最省电，但流量有「突发后紧随」的自相关特性。短周期提供了一个性价比极高的中间态：唤醒频率比长周期高、功耗又远低于持续清醒，恰好覆盖「刚忙完、可能还有余单」的窗口期，用很少的电量换回了大幅降低的响应时延。

Q4：CDRX 对 ping 时延的影响能估算吗？ A：可以粗估：数据落在睡眠期的概率约为 $\frac{T_{\text{cycle}} - T_{\text{on}}}{T_{\text{cycle}}}$，平均额外等待约为 $\frac{T_{\text{cycle}} - T_{\text{on}}}{2}$。周期越长影响越大。若 ping 直方图出现与周期等间隔的多峰，几乎可以确定是 CDRX 在起作用。

Q5：WUS（唤醒信号）和 CDRX 是替代关系吗？ A：不是替代，而是叠加优化。CDRX 定义了「何时可能需要醒」，WUS 则在此基础上把「大概率白醒一次」的成本再砍一刀：唤醒窗到来前先发一个低成本指示，有事务才真正醒来。可以理解为 CDRX 是作息合同，WUS 是合同之上的「没事别来打卡」补充条款。

参考来源

2. ShareTechnote 5G/NR - DRX — 工程师社区经典站点，含 DRX 参数图解与计时器时序示例。
3. WirelessMoves — Martin Sauter 的移动网络博客，有多篇 CDRX 实测功耗与时延影响的现场分析。

本文由「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 等场景全覆盖。