<!-- title: 图解连接态DRX：省电与时延的平衡术 -->

# 图解连接态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 的调度，手机监听完就继续睡；如果恰好有调度，故事就进入了「加班模式」。整个过程可以用一张时间轴示意：

```mermaid
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 信令里看到的真实名字）：

| 参数 | 通俗类比 | 作用 | 典型配置示例 |
|---|---|---|---|
| drx-LongCycleStartOffset | 值班表的起始页 | 定义长周期长度及周期起点相位偏移 | 320ms / 640ms |
| drx-onDurationTimer | 每次强制值班时长 | 周期起点强制监听 PDCCH 的时间 | 2ms～20ms |
| drx-InactivityTimer | 加班计时器 | 每次被调度后延长清醒时间，超时才准睡 | 2ms～100ms |
| drx-ShortCycle | 小睡周期 | 忙碌刚结束后的短周期浅睡 | 20ms～80ms |
| drx-ShortCycleTimer | 小睡次数上限 | 短周期重复多少次后升级为长周期 | 1～16 次 |
| drx-HARQ-RTT-Timer | 等回执的闹钟 | 首传数据发出后，等待对方反馈的固定时延 | 数个符号～数毫秒 |
| drx-RetransmissionTimer | 等补考的通知窗 | RTT 超时后，继续监听重传调度的窗口 | 数个时隙 |

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

### 3.3 活动期的完整状态机

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

```mermaid
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 用「双周期」结构优雅地建模了这种行为：

```mermaid
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）深度睡眠，把功耗压到最低。

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

| 维度 | 短 DRX 周期 | 长 DRX 周期 |
|---|---|---|
| 唤醒频率 | 高 | 低 |
| 响应时延 | 小（数据很快等到唤醒窗） | 大（最坏等一个长周期） |
| 平均功耗 | 较高 | 最低 |
| 适用阶段 | 流量刚停歇的「余温期」 | 长时间静默的「冬眠期」 |
| 进入条件 | InactivityTimer 超时 | ShortCycleTimer 耗尽 |

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

$$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）。手机用一个专用的低功耗检测器瞄一眼即可：

```mermaid
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_{\text{cycle}} - 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](https://www.sharetechnote.com/html/5G/5G_DRX.html) — 工程师社区经典站点，含 DRX 参数图解与计时器时序示例。
3. [WirelessMoves](https://wirelessmoves.com) — 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 等场景全覆盖。

![51学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)