连接态DRX原理：手机的智能打盹术

一、从一个值班室的类比说起

想象你是小区保安亭里的值班员，需要24小时守着对讲机等指令。如果每一秒都竖起耳朵全神贯注地听，一晚上下来人会精疲力尽——这正是手机射频接收电路的处境。接收机只要开机（物理层持续监测PDCCH控制信道），电流消耗就一直维持在高位，哪怕根本没有一帧数据传给你。

值班员很聪明：他定了个闹钟，每半小时醒来一次，看一眼对讲机有没有动静，没动静就继续睡。有人找他时，会等他下一次醒来时再交代任务，或者干脆用较长的时间窗把事情说完整。这个"定时醒来、没事就睡"的机制，就是不连续接收（DRX, Discontinuous Reception）的雏形。

但值班员的困境也很真实：睡得越沉，醒来响应越慢。如果正好在睡觉时来了一条紧急指令，他只能等到下一个闹钟响起才能处理。手机也一样——DRX本质上是在终端功耗与数据时延/吞吐之间做的一场精心设计的折衷。这一折衷做不好，轻则手机发烫、续航骤降，重则游戏延迟飙高、语音丢包。理解DRX的每一个参数为什么存在、它们之间如何联动，是无线工程师调优功耗与时延问题的基本功。

二、为什么省电这件事在手机上如此苛刻

手机和基站最大的硬件差异之一：基站靠市电供电，不在乎接收电路一直开着；手机靠电池，每一毫安时都要精打细算。有评测和研究反复证实过，现代智能手机的耗电大头是屏幕和射频，而在射频部分，接收链路持续开启监测控制信道是纯数据待机场景下最稳定的耗电源之一。原因在于：

1. 控制信道必须盲收。下行数据什么时候来，手机事先不知道，只能持续解码PDCCH（物理下行控制信道），看有没有调度给自己的DCI（下行控制信息）。PDCCH解码是全速运行的操作，功耗可观。
2. 没有数据不等于可以关机。若彻底关闭接收机，网络将无法呼通这台手机——既收不到数据，也收不到信令，等于掉网。

所以问题被转化为：能不能在不漏掉任何"可能到来"的数据的前提下，尽量少地睁眼？ DRX给出的答案是分层做梦：绝大多数时间深睡（长周期），业务活跃时浅睡（短周期），业务进行中不睡（激活期）。这与操作系统的CPU调频Governor、后台服务的保活策略在设计哲学上如出一辙——用状态机管理"完全开"与"完全关"之间的灰色地带。

三、核心参数：一部闹钟系统的五个角色

连接态DRX（C-DRX）由一组定时器和一个周期结构组成。先把参数全部放到桌面上，再用类比逐一拆解：

NR（5G）中这套参数名称为 drx-LongCycleStartOffset、drx-ShortCycle、drx-onDurationTimer 等，语义与LTE一致，但单位从"子帧"细化为毫秒甚至时隙级粒度，短周期可以压到2ms，以适配URLLC类业务。

把这组参数串成一个值班员的一天：

flowchart TD
    A[睡眠中<br/>不监听PDCCH] -->|长/短周期闹钟到点| B[onDuration开启<br/>睁眼监听PDCCH]
    B -->|onDuration内没收到任何调度| A
    B -->|收到上行/下行DCI调度| C[启动 drx-InactivityTimer<br/>加班模式]
    C -->|每次收到新调度| C
    C -->|计时到且无新调度| D{配置了短周期?}
    D -->|是| E[进入短DRX周期<br/>浅睡, 高频闹钟]
    E -->|短周期持续期间又来数据| C
    E -->|连续若干短周期无事<br/>drx-ShortCycleTimer到期| F[回到长DRX周期<br/>深睡, 低频闹钟]
    D -->|否| F

这张状态图里藏着三个关键设计问题，也是DRX原理的精髓所在。

3.1 为什么"醒着的时间"和"加班时间"要分开？

onDurationTimer 是周期性的睁眼窗口：闹钟一响就开，无论有没有事。它保证的是网络随时能叫醒你——基站知道你的DRX配置，会把下行数据安排在你的onDuration期间发送。

drx-InactivityTimer 则是事件驱动的加班：一旦真的收到了调度，说明业务来了，大概率还有后续包（想想网页的首包之后是几十个包的瀑布），此时若立刻按闹钟回去睡，每个包都要等下一个周期，时延会灾难性地放大。所以收到调度就重置加班定时器，让手机跟着业务节奏保持清醒，直到业务自然结束。

这解释了一个现网现象：刷10秒短视频，手机射频活跃可能长达30~60秒。视频流结束后，心跳包、信令、ACK/NACK等零散流量不断重置inactivity timer，激活期被一拖再拖。功耗优化工程师做"激活期压缩"，本质上就是在分析哪些包在"非法加班"。

3.2 为什么要有短周期？——流量的"余温"特性

业务流量有强烈的突发成簇（bursty）特征：一次网页浏览是"密-疏-密-疏"的簇状分布。簇刚结束的那一刻，用户随时可能点击下一个链接，此时若立刻进入1.28秒才醒一次的长周期深睡，下一次点击的首包延迟将高达数百毫秒甚至秒级，用户能明确感知到"卡"。

短周期就是为此设计的浅睡缓冲带：业务结束后先用高频闹钟（如20ms一次）守几分钟（由 drx-ShortCycleTimer 控制守多少个短周期），确认真的没事了，再退回长周期深睡。整个过程像人入睡的生理节奏——先浅睡，再深睡。

timeline
    title 一次网页浏览前后的DRX状态迁移（示意）
    浏览中 : inactivity timer持续被重置 : 完全活跃, 不睡眠
    页面加载完成 : 计时器到期 : 进入短DRX(如20ms周期)
    短周期期间 : 用户又点击一个链接 : 立即唤醒, 回到完全活跃
    短周期计数耗尽 : 无任何流量 : 退回长DRX(如640ms周期)
    长周期期间 : 只有onDuration瞬间醒来 : 深睡省电

3.3 HARQ重传和睡眠会不会打架？

这是DRX设计中最精巧的部分。下行HARQ的节奏是：基站发数据 → 手机8ms后回ACK/NACK → 若是NACK，基站在RTT到期后再调度重传。问题来了：如果第一次传输落在onDuration里，而重传被安排在手机"该睡觉"的时间点怎么办？

标准的设计是双定时器接力：第一次传输结束后启动 drx-HARQ-RTT-Timer（比如8ms），告诉手机"这段时间基站不可能重传，放心睡"；该定时器到期时启动 drx-RetransmissionTimer，强制手机在重传可能到来的窗口内保持清醒去听PDCCH。每个HARQ进程（LTE下行8个并行进程）各自维护一对定时器，互不干扰。

换句话说，HARQ的时序约束硬生生地在DRX的睡眠时间表上"凿"出了清醒窗口。手机不是简单地按闹钟睡觉，而是闹钟、业务时钟、重传时钟三方协商出一个交集。这也是为什么你在协议流程分析里会看到：即便配置了很长的DRX周期，混合重传期间的激活占比依然不低。

四、一次完整的C-DRX时序推演

把所有角色放到一条时间轴上，看一次典型的"唤醒-收包-浅睡-深睡"全过程：

sequenceDiagram
    participant UE as 手机(UE)
    participant eNB as 基站

    Note over UE: 深睡中(长DRX周期=640ms)
    eNB->>UE: 周期到点, onDuration开启(如10ms)
    UE->>eNB: 醒来, 解码PDCCH
    eNB->>UE: PDCCH携带DCI: 有你的下行数据
    Note over UE: 启动 drx-InactivityTimer (如200ms)
    eNB->>UE: PDSCH数据块#1
    UE->>eNB: HARQ反馈ACK/NACK
    alt 解码失败(NACK)
        Note over UE: 启动HARQ-RTT Timer
        Note over UE: RTT到期→启动Retransmission Timer<br/>强制保持清醒等重传
        eNB->>UE: PDCCH调度重传 + PDSCH重传数据
    end
    eNB->>UE: 后续数据持续调度<br/>(每次都重置InactivityTimer)
    Note over UE: 数据流结束, InactivityTimer自然到期
    Note over UE: 进入短DRX周期(20ms), 浅睡
    Note over UE: drx-ShortCycleTimer到期(无事发生)
    Note over UE: 回到长DRX周期(640ms), 深睡

从这张图可以读出两条重要的工程直觉：

直觉一：唤醒延迟的上界是长周期。 假设数据包恰好在onDuration结束后的第1ms到达基站，而inactivity timer已过期、手机已入眠，那么这批数据必须等到下一个onDuration窗口。若长周期是640ms，最坏情况下这第一个包要干等640ms——对游戏、语音这类时延敏感业务是致命的。均匀假设下，平均唤醒等待约为长周期的一半：

$$\bar{t}{wake} \approx \frac{T$$}}{2

直觉二：占空比决定功耗基线。 忽略HARQ与信令的扰动，纯待机场景的射频活跃占比近似为：

$$D = \frac{T_{onDuration}}{T_{cycle}}$$

若onDuration为10ms、长周期为640ms，占空比约1.6%。把周期缩短到64ms，占空比涨到15.6%，接收功耗提升近10倍——但换来的最坏唤醒延迟从640ms降到64ms。参数配置就是在这一条功耗-时延曲线上选点，没有免费午餐。

五、三种"睡眠"的辨析：别把它们混为一谈

工程师讨论省电时常把几个概念搅在一起，下表做一次彻底切割：

三者是一条省电强度递增、恢复代价也递增的阶梯。C-DRX是"打盹"，空闲态是"回家睡觉"，休眠BWP则是"趴在桌上闭眼"——至于RRC INACTIVE态（5G新增的挂起态），则是介于打盹和回家之间的"在宿舍待命"，其唤醒机制同样建立在DRX之上。

六、现网映射：工程师在哪里会撞上DRX

6.1 参数配置与业务失配是最大坑源

• 语音业务（VoLTE/VoNR）：语音编解码器每20ms产出一个包。理想配置是短DRX周期恰好等于20ms，让唤醒节奏与语音节奏锁相。若配成64ms短周期，每3~4个语音包才有一次"天然唤醒窗"，其余全靠inactivity timer强撑，激活占比反而虚高，或者更糟——包迟到了挤进抖动缓冲区溢出，表现为通话偶发断续。
• IM/心跳类应用：微信类应用的心跳周期（如4~5分钟）若与DRX周期不对齐，每条心跳都会走"长周期唤醒→建激活→inactivity拖尾→浅睡→深睡"的完整流程。某些厂商的"应用速冻"优化就是让心跳对齐DRX边界，减少唤醒次数。
• TCP吞吐类业务：下载中途若某个RTT内恰好跨过onDuration边界且inactivity timer偏短，TCP的ACK时序会被DRX"锯齿化"，表现为吞吐曲线周期性凹陷。抓空口 traces 看到规则的锯齿时，第一反应应该是查DRX参数而不是怀疑带宽。

6.2 调试时的实用锚点

1. 从功耗倒查DRX：实验室里用电流台架测稳态待机电流，若明显高于竞品数毫安的量级，先算理论占空比 $D = T_{on}/T_{cycle}$ 是否偏大，再核对现网下发的 SIB2/RRC重配置中实际生效的DRX参数（现网参数与设计文档不一致是家常便饭）。
2. 区分"DRX睡眠"与"信号差导致的静默"：两者在业务层都表现为"没流量"，但DRX睡眠是周期性的、可预测的；弱信号静默伴随重传激增与RSRP恶化。看时间轴形状即可分辨：锯齿=DRX，乱麻=弱覆盖。
3. 切换/重建后的DRX重置：切换完成后DRX定时器会重新起算，若切换频繁（如高铁场景），手机可能几乎无法进入深睡——这也是高铁上手机掉电快的隐性原因之一，别只怪大功率发射。

6.3 一个常见误解

误解："DRX期间手机关闭射频模块，完全不耗电。" 事实：C-DRX的睡眠主要省的是PDCCH盲解码与控制信道监测的功耗，射频前端仍有同步、测量（邻区、间隙测量）、信令等开销。DRX能显著降低待机电流，但"关机级"的省电要到空闲态/INACTIVE才能接近。把待机功耗全部押在DRX参数上，会撞到物理下限。

常见问题

Q1: DRX周期和寻呼周期是一回事吗？ A: 不是。DRX周期是连接态的睡眠节奏，服务的是"已有连接但暂时没数据"；寻呼周期是空闲态的唤醒节奏，服务的是"网络要呼入/来数据了先通知UE起身建链"。前者由eNB/gNB通过RRC专用信令下发，后者广播在系统消息里、还叠加IMS层（VoLTE振铃走IMS信令）的寻呼。两者参数独立、机制独立，只是名字都带"DRX"。

Q2: 短DRX周期为什么不能一直用，非要退回长周期？ A: 因为短周期的占空比是长周期的数倍到数十倍。若一个20ms短周期配5ms onDuration，占空比25%，待机电流不可接受。短周期的定位是业务余温期的"快速响应缓冲"，流量真正平静后必须退回长周期，drx-ShortCycleTimer 就是给这个缓冲期计时的。

Q3: 上行也需要DRX吗？ A: 不需要对称机制。上行发送由手机自己决定，"想发就发"（有缓存数据就触发调度请求），不存在"漏听"。DRX针对的是下行接收必须持续监听这一不对称性。但DRX间接影响上行——上行调度授权只能在手机醒着的时候收到，所以深睡期连上行都会被顺带延迟。

Q4: 5G的DRX和4G有什么本质变化？ A: 机制骨架相同（那套定时器体系原样继承），变化在三个方向：一是粒度更细，支持毫秒级甚至更短周期，配合URLLC；二是与BWP联动，可在onDuration内先唤醒到小带宽BWP再按需切换，进一步压占空比；三是跨时隙调度配合，允许调度指示与数据传输错开时隙，让"醒着"的那段时间被更精确地利用。

Q5: 为什么我的手机待机一晚掉电8%，竞品只掉2%？ A: DRX参数是第一嫌疑犯（唤醒太频繁/onDuration太长/inactivity太长），但它只解释一部分。还应排查：心跳类应用数量、始终开启的测量（如频繁的邻区测量间隙）、弱信号下反复的搜网与重选、以及后台定位。定位方法：开启开发者选项的功耗深挖或用电流台架，对齐"掉电时间点-射频活跃段"，看活跃是周期性（DRX问题）还是事件性（应用问题）。

参考来源

说明：本次撰写会话中联网搜索工具权限受限，未能进行在线抓取核验；以下条目为该主题长期稳定存在的权威公开入口，建议读者自行访问复核最新内容。

2. ShareTechnote: DRX — 工程师社区中广泛引用的LTE DRX参数与时序图解页。
3. 3GPP TS 36.321 / TS 38.321（MAC层规范）中的DRX章节 — 各定时器与状态转移的一手定义（正文按科普定位未展开规范编号，需查证细节时以此为入口，通过 3gpp.org 官网检索获取）。
4. 《通信原理》与《移动通信》类教材中"多址接入与节能机制"章节 — 教科书体系下对占空比、睡眠调度的一般性论述。

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