1.为什么要使用DRX
在讲解DRX的概念前，我们需要先了解下什么是“空闲态”，什么是“连接态”。
我们经常会听到“空闲态”、“连接态”这样的术语，这个概念是从RRC层角度来说的。简单来说，当UE在某个小区完成了驻留之后，我们就可以称该UE进入了“空闲态”或“IDLE态”。如果该UE后续又完成了随机接入过程，那么我们就可以称该UE进入了“连接态”或“CONNECTED态”。
无论是空闲态，还是连接态，如果没有我们本文提到的DRX机制，UE就会一直监听下行PDCCH子帧，查看是否有来自服务小区的信息。这样做看起来没有问题，然而现实很多时候，UE并不是一直在和网络进行有效信息的交互，不会总是执行上传或者下载业务，通话时也不会一直有语音数据的传输。大多数的时间，UE和网络是没有数据交互的，如果这个时候UE还去持续的监听PDCCH子帧，显然是很费电的。因而，在保证数据能有效传输的前提下，有必要设计一种节省UE电量的机制，这个机制我们就叫做DRX。
2.什么是DRX
DRX，英文全称为Discontinuous Reception，即不连续接收，这种方法可以让UE周期性的在某些时候进入睡眠状态（sleep mode），不去监听PDCCH子帧，而需要监听的时候，则从睡眠状态中唤醒（wake up），这样就可以使UE达到省电的目的。虽然这样做对数据传输的时延有一定的影响，但如果这种时延并不影响用户体验，那么考虑到UE更为重要的功率消耗，执行DRX是很有意义的。
DRX机制在空闲态和连接态下的实现是不同的，相对而言，连接态下的DRX机制要复杂的多。本篇博文专门介绍连接态下的DRX机制（Connected DRX，CDRX），而空闲态下的DRX机制即寻呼机制，将在下一篇博文中介绍。下文描述的DRX均特指UE处于连接态时使用的DRX。
一个典型的DRX周期如图1所示。在这个图中，标识“On Duration”的这段时间是UE监控下行PDCCH子帧的时间，在这段时间里，UE是处于唤醒状态的。标识“Opportunity for DRX”的这段时间是DRX睡眠时间，即UE为了省电，进入了睡眠而不监控PDCCH子帧的时间。从这个图中可以看到，用于DRX睡眠的时间越长，UE的功率消耗就越低，但相应的，业务传输的时延也会跟着增加。
（图1）
3.为什么要使用drx-InactivityTimer
我们来考虑这样的一个场景：0号子帧是唤醒时间On_Duration的最后一个子帧，此时网侧刚好有一个较大字节的数据需要发给UE，这些数据无法在0号子帧全部发送完。如果按照上文图1的DRX周期，那么UE将在1号子帧进入DRX睡眠状态，不会再去接收来自网侧的任何下行PDSCH数据。网侧也只能等到DRX周期结束，并在下一个On_Duration时刻到来时，继续向UE发送没有传完的数据。这种处理机制虽然没有错，但显然增加了整个业务的处理时延。为了避免这种情况的出现，DRX机制中增加了drx-Inactivity定时器，如图2所示。
（图2）
如果drx-inactivity定时器正在运行，那么即便原本配置的On_Duration时间已经结束，UE仍然需要继续监听下行PDCCH子帧，直到DRX Inactivity定时器超时。增加了DRX-Inactivity机制之后，显然会减少数据的处理时延，但这将会引入下文描述的另一个问题。
4.增加DRX command控制单元的意义
上文图2描述了DRX-Inactivity定时器的作用是为了降低数据的处理时延，但如果DRX-Inactivity定时器的时长设置的过长，当网侧的数据发送完之后定时器还没有超时，则UE还不得不继续监听下行子帧，无法及时的进入睡眠状态。为了尽量快速的让UE进入睡眠状态，系统引入了一个与DRX相关的MAC控制单元DRX command，有时候也被形象的叫做Go-To-Sleep CE。
当网侧检测到已经没有下行数据可传时，可以向该UE发送一个MAC PDU，这个PDU里携带一个DRX command控制单元。当UE收到这个DRX控制单元之后，无论当前是处于On_Duration状态，还是Inactivity定时器正在运行，都会立即进入睡眠状态，如图3所示。
（图3）
每个MAC控制单元都对应着一个子头，并且一般来说，控制单元都占用特定长度的字节数，比如短BSR控制单元占用了1个字节，加上1个字节的子头，共占用2个字节；再比如长BSR控制单元占用了3个字节，加上1个字节的子头，共占用4个字节。但DRX Command控制单元比较特殊，它所占用的字节数是0，即只需要发送1个字节的子头即可，不需要为控制单元预留空间。这个子头里的LCID需要设置为0x1E，如图4所示。
（图4）
5.长周期和短周期
前文图1已经提到，一个DRX周期等于UE唤醒时间（ON-duration）和睡眠时间的总和。在LTE里，系统可以根据不同的业务场景，给UE分别配置短周期（short DRX cycle）或者长周期（long DRX cycle）。比如在进行VOIP业务时，语音编解码器通常20ms发送一个VOIP包，那么就可以配置长度为20ms的DRX短周期，而在语音通话期间较长的静默期，就可以配置DRX长周期。如果同时配置了短周期和长周期，且在drxShortCycleTimer个子帧内都没有监测到下行PDCCH，那么UE将进入一次长周期睡眠，如下图5所示。
（图5）
在图5中，我们还可以发现有个drxStartOffset参数，这个参数的含义是DRX周期是从哪个子帧开始的，比如周期是10个子帧，那么drxStartOffset的范围就是0～9；而如果周期是20个子帧，那么drxStartOffset的范围就是0～19，有点类似测量GAP里的gapOffset。
6.参数配置
前面已经介绍了与DRX相关的很多参数，包括on_duration时长、drx-Inactivity定时器、长短周期、drxShortCycleTimer、drxStartOffset等等，可能有些同学已经迫不及待的想知道怎么获取这些参数以及这些参数的范围是怎么样的了，下面就说说这个。
同样的，这些参数仍然由RRC配置，具体在消息 RRCConnectionSetup 或 RRCConnectionReconfiguration 或 RRCConnectionReestablishment 的
RadioResourceConfigDedicated 信元的 MAC-MainConfig 中，如图6所示。
（图6）
onDurationTimer：该参数表示在一个DRX周期里，UE睡醒后的在线时长。以PDCCH子帧个数为基本单位，比如psf6表示UE在线监测的时长为6个PDCCH子帧。
drx-InactivityTimer：该参数表示当UE成功解码到一个下行PDCCH之后，还需要继续监测多少个PDCCH子帧。同样以PDCCH子帧个数为基本单位，比如psf80表示UE还需要继续监测80个下行PDCCH子帧才能进入睡眠态。
drx-RetransmissionTimer：这个参数用在下行重传的场景，表示UE为了接收期望的下行重传数据，需要连续监测的最大PDCCH子帧个数。同样以PDCCH子帧个数为基本单位，比如psf8表示UE为了接收下行重传数据，还需要继续等待最多8个下行PDCCH子帧。因为下行重传是自适应的，时间并不确定，如果UE发现eNB需要进行一次重传，那么就需要等待一段时间，这个时间就由这个参数来控制。在定时器运行的这段时间内，UE也是需要盲检测PDCCH信道的。
longDRX-CycleStartOffset：这个参数可以同时表示 longDRX-Cycle 和 drxStartOffset 这两层含义，以子帧为单位。比如长周期选择sf1280，偏移选择0。但需要注意的是，如果网侧同时也配置了短周期（ShortDrx-Cycle）参数，那么长周期必须配置成短周期的整数倍。比如短周期配置的是sf64（64个子帧），那么长周期就不能配置sf80，因为80不能整除64。
shortDRX-Cycle：这个参数表示DRX采用的短周期时长，以子帧为单位，sf5表示短周期时长（含on-duration时间）为5个子帧。
drxShortCycleTimer：这个参数表示在短周期内持续多少个子帧没有收到PDCCH就进入长周期。如果值为2，则表示持续（2×shortDRX-Cycle）个子帧没有成功解码到PDCCH就进入长周期。
也就是说：与定时器相关的参数都是以PDCCH子帧为单位的，而与周期相关的都是以子帧为单位的。
一个典型的长短周期DRX流程如图7所示。具体流程为：UE在时刻（0，0）成功解码到一个PDCCH子帧，因此开启了drx-inactivity定时器（3个子帧的长度）；到了时刻（0，5），满足了进入短周期的时间条件（后文会介绍这个条件，这里记为条件1），UE被唤醒进入on-duration（持续2个子帧）；在时刻（1，0）和（1，5）多次进入短周期；到了（2，0）时刻，(drxShortCycleTimer×shortDrxCycle)=15个子帧内没有成功解码到PDCCH子帧，且满足长周期进入条件（这里先记为条件2，后文再介绍这个条件），UE进入长DRX周期，时刻（2，9）结束长周期；UE在（3，0）收到PDCCH子帧，因此重新启动了drx-inactivity定时器。
（图7）
再具体说说进入长短DRX周期的判断条件。对于进入短周期的条件1，帧号SFN和子帧号subframeNumber需要满足：
[(SFN *10) + subframeNumber] modulo (shortDRX-Cycle) = (drxStartOffset) modulo (shortDRX-Cycle) （条件1）
对照图7的例子，shortDrx-Cycle=5，drxStartOffset=0，因此时刻（0，5）、（1，0）、（1，5）都是满足条件1的。对于进入长周期的条件2，帧号SFN和子帧号subframeNumber需要满足：
[(SFN * 10) + subframeNumber] modulo (longDRX-Cycle) = drxStartOffset （条件2）
对照图7的例子，longDrx-Cycle=10，drxStartOffset=0，因此时刻（1，0）、（2，0）、（3，0）都是满足条件2的。我们可以看到，时刻（1，0）同时满足了短周期和长周期的条件，但为什么此时需要执行短周期DRX呢？下文会对这个地方做出解释。
7.HARQ RTT Timer
在DRX机制中，还需要用到一个名为“HARQ RTT Timer”的定时器，这个定时器或者说这个参数，也是与下行重传相关的。它的含义是，UE在收到期望的下行重传数据之前，需要等待的最少子帧个数。HARQ RTT Timer 和 drx-RetransmissionTimer 的关系，后文介绍DRX具体流程的时候会提到。
对于FDD-LTE来说，HARQ RTT Timer的值固定等于8个子帧。对于TDD-LTE来说，HARQ RTT Timer的值等于（k+4）个子帧，k表示下行PDSCH传输与其应答ACK的时延，具体值如下图8所示。比如当前是上下行子帧配置1，PDSCH是在9号子帧下发的，那么eNB将在3号子帧接收应答，所以k=4。
（图8）
8.DRX处理流程
前文已经提到，当UE处于on-duration时期，或者drx-InactivityTimer正在运行，或者drx-RetransmissionTimer正在运行，那么UE都需要持续的监测下行PDCCH信道（即UE处于激活时间）。除了这些情况之外，当以下条件之一发生时，UE也需要持续的监测PDCCH信道：
| （1）冲突解决定时器mac-ContentionResolutionTimer正在运行。 （2）有准备在PUCCH上发送的SR。 （3）上行HARQ重传的授权已经存在，且对应的HARQ缓存里有数据。 （4）非竞争随机接入过程成功收到RAR响应之后，还没有收到以CRNTI加扰的、指示有新数据的PDCCH。关于非竞争接入过程请参考《LTE-TDD随机接入过程（1）-目的和分类》。 |
DRX的处理流程需要考虑的场景比较多，如果用文字描述的话不太清晰，这里我用流程图的形式展示给大家，如下面的图9所示（因为截图的原因，所以尽量压缩了空间排版）。
（图9）
上面图9中提到的半双工FDD的概念，是2008年爱立信在深圳的一次3GPP会议中提出来的，初衷是允许UE在3.5GHz和小于860MHz的Band中，可以进入FDD半双工的模式。但截至目前，还没有听说哪家手机芯片厂商支持LTE半双工FDD的情况。
如果eNB配置了DRX功能，除了影响UE侧检测下行PDCCH子帧，还会影响UE侧SRS/CQI/PMI/RI的发送，具体为：
| （1）UE在非激活时间内，不发送SRS。 （2）如果上层配置了cqi-Mask，那么onDuration定时器不在执行时，UE不应该在PUCCH中发送CQI/PMI/RI；否则，如果没有配置cqi-Mask，那么当UE在非激活时间内，不应在PUCCH中发送CQI/PMI/RI。从这点可以看出，如果当前是LTE-TDD制式，RRC在配置参数的时候，应该确保onDuration或激活时间内，至少有1个上行子帧用于发送SRS/CQI/PMI/RI参数。 |
cqi-Mask参数是限制UE是否仅在DRX周期的onDuration时间内发送CQI/PMI/RI的，由RRC消息配置，具体在 RRCConnectionReconfiguration 或 RRCConnectionReestablishment 或 RRCConnectionSetup 消息的 RadioResourceConfigDedicated -> PhysicalConfigDedicated -> CQI-ReportConfig 字段中。
除此之外，考虑到UE侧的处理时延，如果UE在激活时间的最后4个子帧内检测到一个标识上行或下行新传的PDCCH子帧，那么在接下来的4个子帧内，UE是可以不用在PUCCH中发送CQI/PMI/RI或传输SRS的；而如果UE是因为收到了Go-To-Sleep控制单元而退出激活时间，那么UE也是可以选择在接下来的4个子帧里继续在PUCCH中发送CQI/PMI/RI或传输SRS的。
需要留意的是，无论UE是否在监听PDCCH子帧，都不影响UE发送或接收HARQ反馈。
参考文献：
（1）3GPP TS 36.321 V9.6.0 (2012-03) Medium Access Control (MAC) protocol specification
（2）3GPP TS 36.300 V9.10.0 (2012-12) Overall description
（3）3GPP TS 36.331 V9.18.0 (2014-06) Radio Resource Control (RRC)
（4）http://www.sharetechnote.com
（5）<<4G LTE/LTE-Advanced for Mobile Broadband>>
（6）http://people.cs.nctu.edu.tw/~yctseng/papers.pub/mobile93-drx-ieee-jetcas.pdf