---

CDRX概念概述

DRX: Discontinuous Reception
CDRX: Connected mode DRX

DRX是UE为了省电而引入的一项功能，由RRC层进行配置。通过控制DRX功能，可以控制UE在PDCCH上对C-RNTI、TPC-PUCCH-RNTI、TPC-PUSCH-RNTI、SPS C-RNTI等等的监测。在连接态下，如果RRC层对MAC层配置了DRX功能，那么UE在物理层就可以间断性地对PDCCH进行监测；否则，UE就必须连续地对PDCCH进行监测。CDRX，指的就是UE在连接态下的DRX功能；而空闲态下的DRX功能，则是我们所熟知的寻呼功能(paging)。本文将对CDRX的工作机制进行详细介绍，对paging的介绍不在本文范围之内。

通过CDRX，可以让UE周期性的在某些时候进入睡眠状态（sleep mode），不去监听PDCCH子帧，而需要监听的时候，则从睡眠状态中唤醒（wake up），这样就可以使UE达到省电的目的。虽然这样做对数据传输的时延有一定的影响，但如果这种时延并不影响用户体验，那么考虑到UE更为重要的功率消耗，执行DRX是很有意义的。

一个典型的DRX周期如下图所示。在这个图中，标识“On Duration”的这段时间是UE监控下行PDCCH子帧的时间，在这段时间里，UE是处于唤醒状态的。标识“Opportunity for DRX”的这段时间是DRX睡眠时间，即UE为了省电，进入了睡眠而不监控PDCCH子帧的时间。从这个图中可以看到，用于DRX睡眠的时间越长，UE的功率消耗就越低，但相应的，业务传输的时延也会跟着增加。

(36.321 Figure 3.1-1: DRX Cycle)

---

CDRX参数配置

DRX由eNodeB通过RRC层向MAC层配置，eNodeB通过ConnectionReconfiguration或者RRCConnectionSetup或者RRCConnectionReestablishment这三条RRC信令来告诉UE是否配置DRX以及DRX参数。UE侧RRC层收到DRX配置后，再向MAC层下发DRX配置参数。

在上面三条RRC消息中，如果MAC-MainConfig这个IE(information element)里带了DRX-Config字段，那么UE侧收到消息后，就会根据DRX-Config字段对UE侧MAC层进行DRX参数配置。DRX-Config的内容如下图所示，其中，psf表示PDCCH subframe，sf表示subframe。

(36.331 6.3.2 MAC-MainConfig information element)

---

CDRX参数介绍

DRX-Config字段里包含了DRX配置的相关参数，MAC层根据DRX-Config对CDRX相关参数进行配置，CDRX有关概念的定义如下所述(见36.321)。

下面对CDRX相关概念进行详细介绍。

---

onDurationTimer

该参数表示在一个DRX周期里，UE睡醒后的在线时长。以PDCCH子帧个数为基本单位，比如psf6表示UE在线监测的时长为6个PDCCH子帧。当UE满足DRX周期条件时，就会启动onDurationTimer，进入onDuration。在哪个(SFN,subframe)启动 onDurationTimer呢？计算公式如下：

1. 如果配置了short DRX,则(SFN,subframe)需要满足以下的式子(公式1)：
   $$[(SFN\ast 10)+subframenumber]mod(shortDRX\_Cycle)==(drxStartOffset)mod(shortDRX\_Cycle)$$
2. 如果配置了long DRX,则(SFN,subframe)需要满足以下的式子(公式2)：
   $$[(SFN\ast 10)+subframenumber]mod(longDRX\_Cycle)==(drxStartOffset)$$

ShortDRX和LongDRX计算公式中的drxStartOffset是同一个值，就是DRX-config中longDRX-CycleStartoffset中的CycleStartoffset。

---

drx-InactivityTimer

该参数表示当UE成功解码到一个下行PDCCH之后，还需要继续监测多少个PDCCH子帧。同样以PDCCH子帧个数为基本单位，比如psf80表示UE还需要继续监测80个下行PDCCH子帧才能进入睡眠态。当PDCCH子帧中显示有新的上行或下行传输时(即UE成功盲检到一个下行PDCCH之后)启动该定时器，当收到Go-To-Sleep CE(即DRX Command MAC CE)时停止该定时器。

当drx-InactivityTimer超时时，如果配置short DRX，则:

1. 使用short DRX
2. 触发drxShortCycleTimer

否则:

1. 使用 long DRX

有人可能会认为，如果配置DRX的话，UE一定会睡眠，而eNodeB一定会根据DRX的规则，只在特定的时间发送数据给UE。这种理解是不正确的，因为drx-InactivityTimer参数的存在，只要UE有新传数据到达(PDCCH盲检到新传)，drx-InactivityTimer 就会重新启动(reset), UE的激活的时间就会延长(extended)。因此，假如eNodeB一直不停地给UE发送数据，UE可能就一直处于激活的状态，而不会进入睡眠状态。

---

引入drx-InactivityTimer的意义

我们来考虑这样的一个场景：0号子帧是唤醒时间On_Duration的最后一个子帧，此时网侧刚好有一个较大字节的数据需要发给UE，这些数据无法在0号子帧全部发送完。如果按照上文图1(36.321 Figure 3.1-1)的DRX周期，那么UE将在1号子帧进入DRX睡眠状态，不会再去接收来自网侧的任何下行PDSCH数据。网侧也只能等到DRX周期结束，并在下一个On_Duration时刻到来时，继续向UE发送没有传完的数据。这种处理机制虽然没有错，但显然增加了整个业务的处理时延。为了避免这种情况的出现，DRX机制中增加了drx-Inactivity定时器，如下图所示。

如果drx-inactivityTimer正在运行，那么即便原本配置的On_Duration时间已经结束，UE仍然需要继续监听下行PDCCH子帧，直到DRX InactivityTimer超时。增加了DRX-InactivityTimer机制之后，显然会减少数据的处理时延，但这将会引入下文描述的另一个问题。

---

引入DRX command控制单元的意义

上节图中描述了DRX-InactivityTimer的作用是为了降低数据的处理时延，但如果DRX-InactivityTimer的时长设置的过长，当网侧的数据发送完之后定时器还没有超时，则UE还不得不继续监听下行子帧，无法及时的进入睡眠状态。为了尽量快速的让UE进入睡眠状态，系统引入了一个与DRX相关的MAC控制单元DRX command，有时候也被形象的叫做Go-To-Sleep CE。

当网侧检测到已经没有上下行数据可传时，可以向该UE发送一个MAC PDU，这个PDU里携带一个DRX command控制单元。当UE收到这个DRX控制单元之后，将停止OnDurationTimer和drx-InactivityTimer，尽快的进入睡眠状态，如下图所示。

每个MAC控制单元都对应着一个子头，并且一般来说，控制单元都占用特定长度的字节数，比如短BSR控制单元占用了1个字节，加上1个字节的子头，共占用2个字节；再比如长BSR控制单元占用了3个字节，加上1个字节的子头，共占用4个字节。但DRX Command控制单元比较特殊，它所占用的字节数是0，即只需要发送1个字节的子头即可，不需要为控制单元预留空间。这个子头里的LCID需要设置为0x1E(11110)，如下图所示。

(36.321 Table 6.2.1-1 Values of LCID for DL-SCH)

---

drx-RetransmissionTimer

这个参数用在下行重传的场景。由于下行HARQ采用的是异步重传，因此UE并不确定eNB什么时候会下发重传数据，但UE也不可能无限地等待下去，毕竟UE还需要省电，还需要进入睡眠状态，所以这个重传定时器是表示UE为了接收期望的下行重传数据，需要连续监测的最大PDCCH子帧个数。同样以PDCCH子帧个数为基本单位，比如psf8表示UE为了接收下行重传数据，还需要继续等待最多8个下行PDCCH子帧。

当下面两个条件都满足时，就会启动该重传定时器：

1. HARQ RTT Timer超时，且
2. 对应的DL HARQ进程buffer里的数据没有被成功解码

当满足下面两个条件其中之一时，就会停止该重传定时器：

1. PDCCH子帧显示该进程有数据传输，或
2. 当前属于DL-SPS子帧

为什么需要等到HARQ RTT Timer超时以后才启动drx-RetransmissionTimer呢？因为HARQ RTT Timer一旦超时就意味着UE可以开始接收eNodeB的重传数据了，若HARQ RTT Timer还没有超时，eNodeB也不会下发重传数据，因此此时也没必要启动drx-RetransmissionTimer。下图显示了HARQ RTT Timer和drx-RetransmissionTimer启动的先后关系，从下图中也可以看到drx-InactivityTimer重启3次(红色示意图)，延长了UE的激活时间。

---

drxShortCycleTimer

这个参数表示在短周期内持续多少个子帧没有收到PDCCH就进入长周期。如果值为2，则表示持续（2×shortDRX-Cycle）个子帧没有成功解码到PDCCH就进入长周期。

当配置了shortDRX 时，满足以下任意一个条件就会启动这个定时器：

1. drx-InactivityTimer超时
2. 收到DRX command MAC CE

drxShortCycleTimer超时后，UE就会切换到长周期，使用LongDRX cycle。

• if drx-InactivityTimer expires or a DRX Command MAC control element is received in this subframe:
  • if the Short DRX cycle is configured:
    • start or restart drxShortCycleTimer;
    • use the Short DRX Cycle.
  • else:
    • use the Long DRX cycle.

–36.321 section 5.7

为什么在drx-InactivityTimer超时之后不是进入长DRX周期，而是进入短DRX周期呢？这里举个可能不那么恰当，但是比较通俗的例子来说明，那就是新冠疫情的动态清零政策。比如，某个地区很长一段时间来都没有任何无症状感染者(类比睡眠状态)，那么防疫部门就不会要求该地区的人每天都去做核酸检测(一直monitor PDCCH)，可能一周才去做一次(long DRX cycle)。然后，突然某一天该地出现了一例无症状感染者(接收到PDCCH)，那么，防疫部门就会要求该地区的人接下来的几天每天都做核酸(连续monitor PDCCH)，假如连续几天都没有新增病例(drx-InactivityTimer超时了)，那么可以认为这一轮疫情大概率已经被消灭了，那么是不是可以直接恢复到一周一检测呢？并不是，为了保险起见，防疫部门会先做一段时间的试探性调整，在这段时间内把周期稍微调长一点，从原来的一天一检，变成到几天一检，比如三天一检(短DRX周期)，假如经过一段时间的试探(drxShortCycleTimer)以后，还是没有新增病例(没检测到PDCCH)，那么完全有理由相信这轮疫情已经结束，这时候就又可以恢复到一周一检的状态(long DRX)。

CDRX周期的调整也是采用类似的策略，通过动态地调整接收PDCCH的周期，一方面可以防止过于激进，假如UE在drx-InactivityTimer超时后直接进入长DRX周期，这就会导致在drx-InactivityTimer超时后到来的数据不得不等待漫长的长DRX周期才能发送至UE；另一方面，先经过一个短DRX周期的试探性的调整，再进入长DRX周期，这样又可以让UE能尽快地进入长DRX周期，以更进一步地省电。

---

longDRX-CycleStartoffset

这个参数可以同时表示 longDRX-Cycle 和 drxStartOffset 这两个字段，以子帧为单位。比如长周期选择sf1280，偏移选择0。但需要注意的是，如果网侧同时也配置了短周期（ShortDrx-Cycle）参数，那么长周期必须配置成短周期的整数倍。比如短周期配置的是sf64（64个子帧），那么长周期就不能配置sf80，因为80不能整除64。

---

shortDRX-Cycle

这个参数表示DRX采用的短周期时长，以子帧为单位，sf5表示短周期时长（含on-duration时间）为5个子帧。

---

long DRX cycle

一个DRX周期等于UE唤醒时间（ON-duration）和睡眠时间的总和。在LTE里，系统可以根据不同的业务场景，给UE分别配置短周期（short DRX cycle）或者长周期（long DRX cycle）。比如在进行VOIP业务时，语音编解码器通常20ms发送一个VOIP包，那么就可以配置长度为20ms的DRX短周期，而在语音通话期间较长的静默期，就可以配置DRX长周期。

Short DRX是可选的IE，如果网侧在配置了longDRX-CycleStartoffset的同时也配置了ShortDrx-Cycle参数，则网侧给UE同时配置了短周期和长周期，此时长周期必须配置成短周期的整数倍。当drxShortCycleTimer定时器超时后，UE将进入一次长DRX周期，如下图所示。图中，drx-InactivityTimer定时器超时后开启drxShortCycleTimer定时器。

根据36.321第5.7节，满足以下条件时，UE就会进入long DRX周期：

• if drx-InactivityTimer expires or a DRX Command MAC control element is received in this subframe:

  • if the Short DRX cycle is configured:
    • start or restart drxShortCycleTimer;
    • use the Short DRX Cycle.
  • else:
    • use the Long DRX cycle.

• if drxShortCycleTimer expires in this subframe:
  - use the Long DRX cycle.

• if a Long DRX Command MAC control element is received:
  - stop drxShortCycleTimer;
  - use the Long DRX cycle.

由以上各定时器与周期的描述可以看出：与定时器相关的参数都是以PDCCH子帧为单位的，而与周期相关的都是以子帧为单位的。

---

HARQ RTT Timer

在DRX机制中，还需要用到一个名为“HARQ RTT Timer”的定时器，这个定时器或者说这个参数，也是与下行重传相关的。它的含义是，UE在收到期望的下行重传数据之前，需要等待的最少子帧个数。当收到PDCCH子帧显示有下行传输或处于DL-SPS子帧时开启该RTT定时器，同时也将drx-RetransmissionTimer停掉，而当HARQ RTT Timer超时时会开启drx-RetransmissionTimer。

对于FDD-LTE来说，HARQ RTT Timer的值固定等于8个子帧。对于TDD-LTE来说，HARQ RTT Timer的值等于（k+4）个子帧，k表示下行PDSCH传输与其应答ACK的时延，具体值如下图所示。比如当前是上下行子帧配置1，上行子帧3(对应子帧n)用于回复eNodeB在下行子帧n-4发送的PDSCH的ACK/NACK。假如PDSCH是在9号子帧下发的，那么eNB将在3号子帧接收应答，所以k=4。

(36.213 Table 10.1.3.1-1: Downlink association set index K for TDD)

---

CDRX场景举例

在介绍完CDRX的相关概念后，下面介绍几个具体的场景。

---

场景1

一个典型的长短周期DRX流程如下图所示。具体流程为：UE在时刻（0，0）成功解码到一个PDCCH子帧，因此开启了drx-inactivityTimer（3个子帧的长度）；当drx-inactivityTimer超时后开启drxShortCycleTimer；到了时刻（0，5），满足了进入短周期的时间条件（即onDurationTimer小节的公式1），UE被唤醒进入on-duration（持续2个子帧）；在时刻（1，0）和（1，5）多次进入短周期；到了（1，9）时刻，(drxShortCycleTimer×shortDrxCycle)=15个子帧内没有成功解码到PDCCH子帧，准备进入长DRX周期，在（2，0）满足长周期进入条件（即onDurationTimer小节的公式2），UE进入长DRX周期，时刻（2，9）结束长周期；UE在（3，0）收到PDCCH子帧，因此重新启动了drx-inactivity定时器。

---

场景2

改变一下DRX参数，假如DRX参数如下：

short DRX

根据onDurationTimer小节公式1，
$$[(SFN\ast 10)+subframenumber]mod(shortDRX\_Cycle)==(drxStartOffset)mod(shortDRX\_Cycle)$$
可以计算出在短周期下onDurationTimer的启动时刻为满足以下条件的(SFN，subframe):
$$[(SFN\ast 10)+subframenumber]mod5==0mod5==0$$
因此，$(SFN,subframe)=(0,0),(0,5),(1,0),(1,5)(2,0),(2,5),(3,0),(3,5)\dots$

Long DRX

根据onDurationTimer小节公式2，
$$[(SFN\ast 10)+subframenumber]mod(longDRX\_Cycle)==(drxStartOffset)$$
可以计算出在长周期下onDurationTimer的启动时刻为满足以下条件的(SFN，subframe):
$$((SFN\ast 10)+subframe)mod10=0$$
因此，$(SFN,subframe)=(0,0),(1,0),(2,0),(3,0)$

UE在onDurationTimer 区间接收到PDCCH，会触发drx-InactivityTimer；drx-InactivityTimer超时，会触发drxShortCycleTimer；drxShortCycleTimer超时，会使用Long DRX cycle。

在下图中，UE在(0，1)盲检到PDCCH，于是启动drx-InactivityTimer。接着，在(0，4)时，drx-InactivityTimer超时，于是启动drxShortCycleTimer。在(1，4)时，drxShortCycleTimer超时，于是进入长周期，使用Long DRX cycle。

---

场景3

仍然使用场景2的DRX配置，如果在长DRX接收到PDCCH，会触发使用short DRX，如下图所示。由图可以看出，在(2，0)时UE接收到PDCCH，于是在(2，1)时启动drx-InactivityTimer。由于UE在接收到PDCCH时(即(2，0)子帧)处于长DRX，因此，在drx-InactivityTimer超时后(即(2，3)子帧)，UE便启动drxShortCycleTimer，切换到短周期，使用short Cycle。

---

一些疑问与自答

1. 在[6]这篇文章中，最后一张图第5步，收到DL grant后，并没停止drx-RetransmissionTimer，这是expected的吗？因为根据协议的说法¹，如果收到DL grant的话，就应该停止drx-RetransmissionTimer。
   

• if the PDCCH indicates a DL transmission or if a DL assignment has been configured for this subframe:
  • if the UE is an NB-IoT UE, a BL UE or a UE in enhanced coverage:
    • start the HARQ RTT Timer for the corresponding HARQ process in the subframe containing the last repetition of the corresponding PDSCH
      reception;
  • else:
    • start the HARQ RTT Timer for the corresponding HARQ process;
  • stop the drx-RetransmissionTimer or drx-RetransmissionTimerShortTTI for the corresponding HARQ process.

答案：这里应该是有误，根据协议，如果PDCCH指示了下行传输，就应该停止drx-RetransmissionTimer，因此，在上面第五步的时候drx-RetransmissionTimer就应该被停止了。

2. 为什么在上图第5步也没有重启drx-InactivityTimer？

答案：因为根据协议¹，只有PDCCH指示新传的时候，才会重启drx-InactivityTimer。

• if the PDCCH indicates a new transmission (DL, UL or SL):
  • except for an NB-IoT UE configured with a single DL and UL HARQ process, start or restart drx-InactivityTimer.
• if the PDCCH indicates a transmission (DL, UL) for an NB-IoT UE:
  • if the NB-IoT UE is configured with a single DL and UL HARQ process:
    • stop drx-InactivityTimer.
  • stop onDurationTimer.

---

参考文献

[1]. CDRX – LTE连接态下的DRX
[2]. DRX (Discontinuous Reception) - CDRX (Connected Mode DRX)
[3]. 3GPP 36.321
[4]. 3GPP 36.331
[5]. 深入理解LTE-A
[6]. Connected Mode DRX
[7]. LTE资源调度（7）-DRX不连续接收（1）

---

1. 36321 5.7 Discontinuous Reception (DRX) ↩︎ ↩︎