5G DRX：终端省电的核心机制——从"一直盯着"到"按需醒来"

你的手机连接5G网络后，如果什么都不做，电池能撑多久？答案取决于一个关键机制：DRX（不连续接收）。没有DRX，你的手机需要每个毫秒都盯着下行控制信道（PDCCH），看基站有没有给它发数据——这就好比你站在快递柜前，24小时不间断地盯着屏幕等快递通知，体力消耗可想而知。

DRX的核心思想很简单：没数据的时候就去睡觉，有数据的时候再醒来。但"什么时候醒""醒多久""怎么判断该不该醒"这些问题的答案，构成了5G中最精巧的省电设计之一。

一、为什么需要DRX？从"持续监听"的代价说起

在移动通信中，基站通过PDCCH（物理下行控制信道）告诉终端："下一个时隙，你的数据在哪个资源格子上"。如果终端不持续监听PDCCH，就可能漏掉基站的调度指令，导致数据丢失或延迟。

但持续监听的代价极其昂贵：

这就引出了DRX的设计目标：在满足业务延迟要求的前提下，尽可能减少终端不必要的PDCCH监听。

二、5G三种RRC状态与三种DRX模式

5G NR引入了三种RRC状态，每种状态都有自己的DRX机制。理解这三者的关系，是掌握DRX全景的关键。

stateDiagram-v2
    [*] --> RRC_IDLE: 开机注册
    RRC_IDLE --> RRC_CONNECTED: RRC Setup/Resume
    RRC_CONNECTED --> RRC_IDLE: RRC Release
    RRC_CONNECTED --> RRC_INACTIVE: RRC Release（挂起）
    RRC_INACTIVE --> RRC_CONNECTED: RRC Resume
    RRC_INACTIVE --> RRC_IDLE: 移出RNA区域

    state RRC_IDLE {
        [*] --> 寻呼DRX
        寻呼DRX: 监听P-RNTI
        寻呼DRX: 周期320ms~2.56s
    }

    state RRC_INACTIVE {
        [*] --> 寻呼DRX_RAN
        寻呼DRX_RAN: 监听P-RNTI
        寻呼DRX_RAN: RAN侧寻呼
    }

    state RRC_CONNECTED {
        [*] --> CDRX
        CDRX: 监听C-RNTI
        CDRX: 周期10ms~1024ms
    }

2.1 空闲态DRX（Idle DRX）——等电话的"闹钟模式"

手机在RRC_IDLE状态下，与网络没有连接，但网络可能随时发起寻呼（比如有人打电话给你）。终端需要周期性地醒来检查有没有属于自己的寻呼消息。

工作原理： - 网络通过SIB1广播寻呼周期（默认320ms、640ms、1.28s或2.56s） - 终端根据自己的UE_ID（5G-S-TMSI）计算自己应该在哪个寻呼帧（PF）和寻呼时机（PO）醒来 - 每个周期只需醒来监听一个PO（通常1个时隙），其余时间全部休眠

$$PF = (T \div N) \times (UE_ID \mod N)$$

$$i_s = \lfloor (UE_ID \div N) \mod Ns \rfloor$$

其中$T$是寻呼周期，$N$是$T$内的PF数量，$Ns$是每个PF内的PO数量，$i_s$是PO的索引。

省电效果： 非常显著。以默认1.28s周期为例，终端每1.28秒只需醒来监听约1ms，99.9%的时间在睡觉，待机功耗接近关机状态。

2.2 非活跃态DRX（Inactive DRX）——"假休眠"的聪明设计

RRC_INACTIVE是5G新引入的状态。终端虽然释放了空口连接，但核心网和基站侧仍然保留了终端的上下文。这样当有下行数据到达时，可以通过RAN侧寻呼快速恢复连接，而不需要走完整的初始接入流程。

非活跃态DRX的机制与空闲态基本相同，但有几点关键区别：

2.3 连接态DRX（C-DRX）——本文的核心主角

连接态DRX是最复杂也最有工程价值的DRX机制。终端虽然保持着RRC连接，但不需要每个时隙都监听PDCCH，而是按照网络配置的周期性"值班表"来工作。

一个生活类比： 想象你是一个值班保安。以前的工作方式是24小时盯着监控屏幕（持续监听PDCCH），非常累。现在公司给你配了一个值班表： - 每隔一段时间（DRX周期），你到监控室盯一会儿（On Duration） - 如果这段时间内监控有异常（收到PDCCH调度），你就继续工作（重启非活跃定时器） - 如果一切正常（定时器超时），你就回休息室睡觉

这就是C-DRX的核心逻辑。

三、C-DRX的核心参数：六个定时器如何协同工作

C-DRX的精妙之处在于，它不是简单的"醒-睡-醒-睡"循环，而是由多个定时器协同控制的状态机。理解这些参数的含义和交互关系，是调优DRX配置的基础。

flowchart TB
    subgraph DRX状态机
        A[持续监听PDCCH] -->|drx-InactivityTimer超时| B{配置了短周期?}
        B -->|是| C[进入短DRX周期]
        B -->|否| D[进入长DRX周期]
        C -->|drx-ShortCycleTimer次后| D
        D -->|On Duration到来| E[监听PDCCH]
        E -->|收到调度| A
        E -->|onDurationTimer超时 无调度| D
        A -->|收到调度 重启| A
    end

    style A fill:#ff6b6b,color:#fff
    style C fill:#ffd93d,color:#333
    style D fill:#6bcb77,color:#fff
    style E fill:#4d96ff,color:#fff

3.1 六个核心参数详解

3.2 一个完整的C-DRX工作时序

让我们用一个具体的例子来说明C-DRX的完整工作流程：

时间轴 →

|←── 长DRX周期 (160ms) ──→|←── 长DRX周期 (160ms) ──→|
|                           |                          |
| OnDuration |   睡眠      | OnDuration |   睡眠      |
|  5ms监听   |   155ms     |  5ms监听   |   155ms     |
|            |             |            |             |
  ↓ 收到调度   ↑            ↓ 无调度     ↑
  |            |             |            |
  |← InactivityTimer →|     回去睡觉
  |   20ms保持清醒     |
  |   持续监听PDCCH    |
  |                    |
  ↑ 再次收到调度，重启Timer

关键时间节点解释：

1. t=0ms：On Duration开始，终端醒来监听PDCCH
2. t=2ms：收到DCI调度（有新数据），启动drx-InactivityTimer=20ms
3. t=5ms：On Duration结束，但因为InactivityTimer还在运行，终端继续保持清醒
4. t=10ms：又收到调度，InactivityTimer重启
5. t=30ms：InactivityTimer超时（最后一次收到调度后20ms），终端进入睡眠
6. t=160ms：下一个长DRX周期的On Duration到来，终端再次醒来

3.3 短周期与长周期的协同——"过渡缓冲"的智慧

为什么需要短周期？直接用长周期不就最省电吗？

考虑一个典型的流量模式：短视频播放。视频数据是以突发（burst）方式到达的，两个burst之间有一个短暂的间隔。如果数据刚停下来就切换到160ms的长周期，下一个数据突发到达时可能要等最坏情况下160ms才能被调度，用户会感受到卡顿。

短周期的设计就像一个过渡缓冲：

活跃状态 → [InactivityTimer超时] → 短周期(20ms × 几次) → 长周期(160ms)

• 刚停下来的前几个周期用短周期（如20ms），响应快
• 如果仍然没有数据，才切换到长周期（如160ms），深度省电
• 这样既保证了省电效果，又避免了"刚睡着就被叫醒"的尴尬

$$T_{short_total} = drx_ShortCycle \times drx_ShortCycleTimer$$

例如：短周期=20ms，短周期定时器=8，则过渡期总时长=160ms，之后切换到长周期。

四、DRX的"Active Time"——终端什么时候不能睡

理解DRX的关键之一是弄清楚Active Time（活跃时间）的定义。终端在以下任一条件满足时必须保持清醒：

用Mermaid时序图来展示一个完整的Active Time生命周期：

sequenceDiagram
    participant UE as 终端
    participant gNB as 基站

    Note over UE: On Duration到来，醒来
    UE->>UE: 启动onDurationTimer
    gNB->>UE: DCI: DL调度(新数据)
    UE->>UE: 重启drx-InactivityTimer
    Note over UE: Active Time持续

    gNB->>UE: DCI: 又一次DL调度
    UE->>UE: 再次重启InactivityTimer

    Note over UE: onDurationTimer超时
    Note over UE: InactivityTimer仍在运行

    gNB->>UE: DCI: UL调度
    UE->>UE: 再次重启InactivityTimer

    Note over UE: InactivityTimer超时
    Note over UE: Active Time结束，进入睡眠

    Note over UE: 等待下一个On Duration...

五、R16增强：唤醒信号（WUS）——"先看一眼再决定醒不醒"

到5G R16版本，DRX机制得到了进一步增强：引入了DCI Format 2-6，也就是所谓的唤醒信号（WUS）。

5.1 传统DRX的痛点

传统C-DRX有一个浪费：即使基站在整个On Duration期间都没有数据要发给终端，终端也必须醒来，打开射频模块，解码PDCCH，最后发现"原来没有我的数据"，再回去睡觉。

这个过程虽然比持续监听好得多，但仍然浪费了： - 射频模块启动和稳定的能量 - PDCCH盲检的基带处理功耗 - On Duration期间的时钟和处理器功耗

5.2 WUS的设计思路

WUS的核心想法是：在On Duration到来之前，基站提前告诉终端"你需不需要醒"。

flowchart LR
    A[DRX睡眠中] --> B{On Duration到来前<br/>监听DCI 2-6}
    B -->|WUS=1 有数据| C[正常醒来<br/>监听On Duration]
    B -->|WUS=0 无数据| D[跳过On Duration<br/>继续睡觉]

    style A fill:#95a5a6,color:#fff
    style C fill:#2ecc71,color:#fff
    style D fill:#3498db,color:#fff

具体工作机制：

1. 网络通过RRC配置终端在On Duration之前的一个偏移时间（ps-Offset）监听DCI Format 2-6
2. DCI 2-6用PS-RNTI（Power Saving RNTI）加扰，是一组终端共享的组播DCI
3. 每个终端在DCI 2-6中占一个bit，指示该终端是否需要醒来
4. 如果指示"不需要醒来"（WUS=0），终端跳过整个On Duration，继续睡眠
5. 如果指示"需要醒来"（WUS=1），终端按正常流程进入On Duration

5.3 WUS的省电增益

WUS的省电效果可以用以下公式估算：

$$P_{saving} = P_{DRX} \times P_{no_data}$$

其中$P_{DRX}$是On Duration期间的功耗，$P_{no_data}$是On Duration期间没有数据的概率。

在实际网络中，终端大部分时间处于连接态但没有数据传输。假设： - On Duration = 5ms，DRX周期 = 160ms - 80%的On Duration没有数据（典型场景） - WUS监听仅需约0.5ms

无WUS时的功耗： 每个160ms周期醒来5ms 有WUS时的功耗： 每个160ms周期仅醒来0.5ms（80%情况），仅20%情况需要醒来5ms

$$E_{WUS} = 0.8 \times 0.5 + 0.2 \times 5.5 = 0.4 + 1.1 = 1.5ms$$

$$E_{noWUS} = 5ms$$

省电增益： $(5 - 1.5) / 5 = 70\%$（在On Duration部分额外省电70%）

六、DRX配置的工程实践——省电与性能的博弈

6.1 不同业务场景的推荐配置

6.2 DRX参数调优的常见误区

误区1：DRX周期越长越省电

不完全正确。过长的DRX周期会导致： - 调度延迟增加，影响TCP拥塞窗口增长 - 可能触发基站过早释放RRC连接（因为基站认为终端不活跃） - 在移动场景中，长周期可能错过切换命令

误区2：On Duration越短越好

On Duration太短的风险： - 如果基站在On Duration期间正好有下行数据但还没来得及组DCI，终端已经睡着了 - 导致多次不必要的短周期→长周期切换 - 反而可能因为重传而更费电

误区3：DRX和调度策略无关

实际上，DRX参数与基站的调度策略紧密耦合： - 基站的调度器需要知道终端的DRX配置，才能在On Duration期间调度数据 - 如果基站调度器与DRX配置不匹配，可能出现"基站想发数据但终端在睡觉"的情况 - 现网中，基站通常会在终端醒来时批量缓存数据（buffering），以最大化DRX效果

6.3 DRX相关的关键日志分析

调试DRX问题时，工程师最常关注以下信息：

一个实用的经验公式：

$$省电比例 \approx 1 - \frac{Active_Time}{Total_Time}$$

如果Active Time比例从100%（无DRX）降到30%（有DRX），理论上省电约70%。

七、DRX与HARQ的交互——"该等还得等"

DRX与HARQ（混合自动重传请求）的交互是工程实践中的一个常见困惑点。

问题场景： 终端收到一个TB（传输块），解码失败，发送NACK。按照HARQ机制，基站需要重传。但此时如果终端的InactivityTimer超时了怎么办？

答案：DRX为HARQ重传专门设计了Retransmission Timer。

时间轴：

收到数据 → 解码失败 → 发NACK → 启动drx-RetransmissionTimer
                                        |
                                    等待重传...
                                        |
                              ┌─ 收到重传 → 解码成功 → Timer停止
                              └─ Timer超时 → 不再等待 → 进入睡眠

关键规则： - 每个HARQ进程有独立的状态追踪 - 只有当对应HARQ进程的NDI（新数据指示）翻转时，才认为收到了新数据 - Retransmission Timer确保终端不会因为提前睡眠而漏掉重传

8个HARQ进程的并行管理使得DRX状态机更加复杂，但核心逻辑不变：只要有未完成的重传，终端就不能完全睡眠。

八、从4G到5G：DRX的演进

5G引入的RRC_INACTIVE状态本身就与DRX密切相关。INACTIVE态下的终端使用与IDLE类似的寻呼DRX，但保留了连接上下文，使得从"深度省电"到"快速恢复"的路径更短——这就是5G在省电设计上的整体思路升级。

九、总结：DRX设计的核心哲学

回过头来看DRX的整套设计，可以提炼出三个核心哲学：

1. 预测性省电：通过定时器和周期配置，让终端和基站达成默契——"你在这个时间醒，我保证在这个时间之前把数据准备好"

2. 分层渐进：活跃→短周期→长周期，逐级深入省电，避免"非黑即白"的二元选择

3. 业务感知：不同的业务特征（语音、视频、消息）匹配不同的DRX配置，没有"万能参数"

DRX不是孤立的技术点，它是5G协议栈中MAC层、RRC层、物理层协同工作的缩影。理解DRX，就理解了移动通信中"如何在保持连接的同时最小化功耗"这一核心矛盾的经典解法。

常见问题

Q1: C-DRX和Idle DRX最本质的区别是什么？ A: 本质区别在于终端与网络的关系不同。Idle DRX的终端没有RRC连接，醒来是为了听寻呼（有人找你）；C-DRX的终端保持着RRC连接，醒来是为了听调度（基站给你分配资源）。C-DRX的周期更短（毫秒级），Idle DRX的周期更长（秒级），因此省电效果差异很大。

Q2: 如果DRX周期内终端有上行数据要发怎么办？ A: 终端可以随时发起调度请求（SR），这会立即中断DRX睡眠，进入Active Time。终端不需要等到下一个On Duration才能发数据。这也是为什么DRX主要针对下行省电——上行数据是终端主动发起的，不受DRX周期限制。

Q3: WUS（唤醒信号）在现网中普及了吗？ A: WUS（DCI Format 2-6）在R16中引入，目前主流芯片平台（高通、联发科）均已支持，但运营商网络的开启程度不一。部分运营商在VoNR场景下已启用WUS来延长通话时的终端续航，因为语音通话期间大部分On Duration确实没有数据。

Q4: DRX配置是谁决定的——终端还是网络？ A: DRX配置由网络侧（基站）通过RRC Reconfiguration消息下发。终端可以上报辅助信息（UE Assistance Information），告知网络自己的省电偏好，但最终决策权在基站。终端不能自行修改DRX参数。

Q5: 同一个基站下所有终端的DRX配置都一样吗？ A: 不一定。C-DRX是终端级别的配置，基站可以根据终端的业务类型和QoS需求为不同终端配置不同的DRX参数。但Idle DRX的寻呼周期是小区级别的广播参数，同一小区内所有终端使用相同的寻呼周期（但每个终端的PO位置不同）。

参考来源

1. 5G连接模式DRX技术原理深度解析 — 百度文库 — C-DRX工作机制与参数详解
2. 5G NR: Connected Mode DRX — How LTE Stuff Works — 英文技术博客，含详细时序图解
3. 5G NR DRX框架 — 知乎专栏 — 双连接场景下的DRX配置
4. 深度解析R16 NR C-DRX工作原理及UE省电机制 — 阿里云开发者社区 — R16增强特性与WUS详解
5. 5G WUS Wake Up Signal — ShareTechnote — WUS与DCI Format 2-6技术参考

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