<!-- title: 5G DRX：终端省电的核心机制 -->

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

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

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

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

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

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

| 维度 | 持续监听 | DRX模式 |
|------|---------|---------|
| 射频模块状态 | 始终开启 | 周期性关闭 |
| 功耗（相对值） | 100%（基准） | 20%-60% |
| PDCCH解码次数/秒 | 1000-4000次 | 几十到几百次 |
| 电池续航影响 | 5G下可能仅数小时 | 可延长30%-50% |

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

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

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

```mermaid
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的机制与空闲态基本相同，但有几点关键区别：

| 特征 | 空闲态DRX | 非活跃态DRX |
|------|----------|------------|
| 寻呼发起方 | AMF（核心网） | 上一个服务gNB（RAN侧） |
| 寻呼范围 | TA列表（跟踪区） | RNA（RAN通知区） |
| 恢复时延 | 较长（需完整RRC建立） | 较短（RRC Resume） |
| 上下文保持 | 不保持 | gNB和核心网均保持 |
| 寻呼周期配置 | SIB1广播 | SIB1 + RRC释放消息 |

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

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

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

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

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

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

```mermaid
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 六个核心参数详解

| 参数 | 含义 | 典型值 | 对省电的影响 |
|------|------|--------|-------------|
| **onDurationTimer** | 每个DRX周期开始时，终端保持清醒的时间 | 1-10ms | 越短越省电，但可能漏掉调度 |
| **drx-InactivityTimer** | 收到PDCCH后，终端继续保持清醒的时间 | 2-100ms | 越短越省电，但 burst传输可能中断 |
| **drx-LongCycle** | 长DRX周期（一次醒来到下一次醒来的间隔） | 40-320ms | 越长越省电，但调度延迟增大 |
| **drx-ShortCycle** | 短DRX周期（可选，用于过渡） | 2-80ms | 提供省电与响应速度的折中 |
| **drx-ShortCycleTimer** | 经过多少个短周期后切换到长周期 | 2-16 | 控制过渡时间 |
| **drx-RetransmissionTimer** | 等待HARQ重传时保持清醒的时间 | 0-6ms | 确保不漏掉重传 |

### 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（活跃时间）**的定义。终端在以下任一条件满足时必须保持清醒：

| 条件 | 触发原因 | 说明 |
|------|---------|------|
| onDurationTimer运行中 | DRX周期开始 | 必须监听PDCCH看有没有调度 |
| InactivityTimer运行中 | 刚收到PDCCH调度 | 可能有连续的burst传输 |
| RetransmissionTimer运行中 | 等待HARQ重传 | 不能漏掉重传数据 |
| 竞争解决定时器运行中 | 随机接入进行中 | 需要等待Msg4 |
| 调度请求待处理 | 终端请求上行资源 | 需要等待基站分配资源 |
| MAC层期望收到新数据的重传 | HARQ NACK已发送 | 需要等待基站重传 |

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

```mermaid
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到来之前，基站提前告诉终端"你需不需要醒"**。

```mermaid
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 不同业务场景的推荐配置

| 业务场景 | On Duration | 长周期 | Inactivity Timer | 短周期 | 设计逻辑 |
|---------|------------|--------|-----------------|--------|---------|
| **VoLTE/VoNR语音** | 2-5ms | 20-40ms | 5-10ms | 不配或10ms | 语音包每20ms一个，周期必须匹配 |
| **视频流媒体** | 2-5ms | 40-80ms | 20-50ms | 20ms | Burst传输后需要缓冲期 |
| **即时消息** | 2ms | 80-160ms | 5-10ms | 20-40ms | 低频小包，允许稍高延迟 |
| **后台数据** | 1-2ms | 160-320ms | 2-5ms | 40ms | 最大省电，容忍较高延迟 |
| **云游戏/AR** | 5-10ms | 10-20ms | 20-50ms | 不配 | 极低延迟需求，几乎不睡眠 |

### 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问题时，工程师最常关注以下信息：

| 日志字段 | 含义 | 调试关注点 |
|---------|------|-----------|
| DRX Status | 当前DRX状态 | 是否正确进入/退出DRX |
| On Duration Start/End | On Duration的起止时间 | 是否与配置一致 |
| Inactivity Timer状态 | 定时器运行/超时 | 是否因为业务频繁而无法进入DRX |
| Short Cycle计数 | 短周期执行次数 | 是否在短周期和长周期间正常切换 |
| PDCCH解码次数 | On Duration期间的盲检次数 | 验证省电效果 |
| Active Time比例 | 活跃时间占总时间比例 | 核心省电指标 |

**一个实用的经验公式：**

$$省电比例 \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的演进

| 特性 | 4G LTE DRX | 5G NR DRX |
|------|-----------|-----------|
| 时间粒度 | 子帧级（1ms） | 时隙级（可变，取决于子载波间隔） |
| RRC状态 | 两种（IDLE/CONNECTED） | 三种（IDLE/INACTIVE/CONNECTED） |
| 唤醒信号 | 无（R15之前） | DCI Format 2-6（R16引入） |
| 跨载波调度 | 有限支持 | 更灵活的跨时隙调度感知 |
| SCell管理 | 无休眠态 | SCell休眠态（R16） |
| 波束管理 | 不涉及 | DRX需要考虑波束恢复时间 |
| 典型最小周期 | 10ms | 可更短（取决于SCS） |

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技术原理深度解析 — 百度文库](https://wenku.baidu.com/noteview/83721c09bf68a98271fe910ef12d2af90242a8c3.html) — C-DRX工作机制与参数详解
2. [5G NR: Connected Mode DRX — How LTE Stuff Works](https://howltestuffworks.blogspot.com/2021/04/5g-nr-connected-mode-drx.html) — 英文技术博客，含详细时序图解
3. [5G NR DRX框架 — 知乎专栏](https://zhuanlan.zhihu.com/p/625249413) — 双连接场景下的DRX配置
4. [深度解析R16 NR C-DRX工作原理及UE省电机制 — 阿里云开发者社区](https://developer.aliyun.com/article/1305666) — R16增强特性与WUS详解
5. [5G WUS Wake Up Signal — ShareTechnote](https://www.sharetechnote.com/html/5G/5G_WUS.html) — 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 等场景全覆盖。

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