为什么要使用DRX
无论是空闲态，还是连接态，如果没有我们本文提到的DRX机制，UE就会一直监听下行PDCCH子帧，查看是否有来自服务小区的信息。这样做看起来没有问题，然而现实很多时候，UE并不是一直在和网络进行有效信息的交互，不会总是执行上传或者下载业务，通话时也不会一直有语音数据的传输。大多数的时间，UE和网络是没有数据交互的，如果这个时候UE还去持续的监听PDCCH子帧，显然是很费电的。因而，在保证数据能有效传输的前提下，有必要设计一种节省UE电量的机制，这个机制我们就叫做DRX。
什么是DRX
DRX，英文全称为Discontinuous Reception，即不连续接收，这种方法可以让UE周期性的在某些时候进入睡眠状态（sleep mode），不去监听PDCCH子帧，而需要监听的时候，则从睡眠状态中唤醒（wake up），这样就可以使UE达到省电的目的。
这样做对数据传输的时延有一定的影响，但如果这种时延并不影响用户体验，那么考虑到UE更为重要的功率消耗，执行DRX是很有意义的。
RRC通过DRX-config配置某个UE配置的DRX相关参数。
DRX的分类
- 空闲态的DRX
空闲态下的DRX机制即寻呼机制
- 连接态的DRX
一个典型的DRX周期下图所示。
在这个图中，标识“On Duration”的这段时间是UE监控下行PDCCH子帧的时间，在这段时间里，UE是处于唤醒状态的。
标识“Opportunity for DRX”的这段时间是DRX睡眠时间，即UE为了省电，进入了睡眠而不监控PDCCH子帧的时间。（睡眠期的UE只是不接收PDCCH，但可以接收来自其他物理信道的数据）
从这个图中可以看到，用于DRX睡眠的时间越长，UE的功率消耗就越低，但相应的，业务传输的时延也会跟着增加。因此，DRX Cycle的选择需要考虑节电与时延的平衡。
以下是连接态下的DRX
DRX-InactivityTimer
我们来考虑这样的一个场景：0号子帧是唤醒时间On_Duration的最后一个子帧，此时网侧刚好有一个较大字节的数据需要发给UE，这些数据无法在0号子帧全部发送完。如果按照上文图1的DRX周期，那么UE将在1号子帧进入DRX睡眠状态，不会再去接收来自网侧的任何下行PDSCH数据。网侧也只能等到DRX周期结束，并在下一个On_Duration时刻到来时，继续向UE发送没有传完的数据。这种处理机制虽然没有错，但显然增加了整个业务的处理时延。为了避免这种情况的出现，DRX机制中增加了drx-Inactivity定时器，如下图所示。
如果DRX-inactivityTimer正在运行，那么即便原本配置的On_Duration时间已经结束，UE仍然需要继续监听下行PDCCH子帧，直到DRX InactivityTimer超时。增加了DRX-InactivityTimer机制之后，显然会减少数据的处理时延。
长周期和短周期
前文图1已经提到，一个DRX周期等于UE唤醒时间（ON-duration）和睡眠时间的总和。
在LTE里，系统可以根据不同的业务场景，给UE分别配置短周期（short DRX cycle）或者长周期（long DRX cycle）。比如在进行VOIP业务时，语音编解码器通常20ms发送一个VOIP包，那么就可以配置长度为20ms的DRX短周期，而在语音通话期间较长的静默期，就可以配置DRX长周期。
如果同时配置了短周期和长周期，且drxShortCycleTimer定时器超时，那么UE将进入一次长DRX周期，如下图5所示。图中，drx-InactivityTimer定时器超时后开启drxShortCycleTimer定时器。
| Item | 作用 | Start | End |
| onDurationTimer | 表示在一个DRX周期里，UE睡醒后的在线时长。以PDCCH子帧个数为基本单位， | shortDRX-Cycle：条件1见下 longDRX-Cycle：条件2见下 | （1）收到DRX MAC control element停止； （2）超时停止； |
| DRX-InactivityTimer | 表示当UE成功解码到一个下行PDCCH之后，还需要继续监测多少个PDCCH子帧。同样以PDCCH子帧个数为基本单位， | 当PDCCH子帧中显示有新的上行或下行传输时启动 | （1）收到DRX MAC control element停止； （2）超时停止； |
| DRX-RetransmissionTimer | 这个参数用在下行重传的场景。由于下行HARQ采用的是异步重传，因此UE并不确定eNB什么时候会下发重传数据，但UE也不可能无限制的等待下去，毕竟UE还需要省电，还需要进入睡眠状态，所以这个重传定时器是表示UE为了接收期望的下行重传数据，需要连续监测的最大PDCCH子帧个数。同样以PDCCH子帧个数为基本单位， | 当HARQ RTT定时器超时且下行HARQ缓存里还有数据没有被解码成功时启动 | （1）当收到PDCCH子帧显示该进程有数据传输; （2）当前属于DL-SPS子帧； （3）超时； |
| shortDRX-Cycle | 表示DRX采用的短周期时长，以子帧为单位， | NA | NA |
| DRXShortCycleTimer | 表示在短周期内持续多少个短周期没有收到PDCCH就进入长周期。如果值为2，则表示持续（2×shortDRX-Cycle）个子帧没有成功解码到PDCCH就进入长周期。 | DRX-InactivityTimer超时 | 超时，此时使用longDRX-Cycle |
| DRX-StartOffset | DRX周期起始的子帧号 | NA | NA |
条件1：
[(SFN *10) + subframeNumber] modulo (shortDRX-Cycle) = (DRXStartOffset) modulo (shortDRX-Cycle)
条件2：
[(SFN * 10) + subframeNumber] modulo (longDRX-Cycle) = DRXStartOffset
SFN(System Frame Number)
DRX流程总结
原文：https://blog.csdn.net/m_052148/article/details/52439789
https://wenku.baidu.com/view/ce832a3f492fb4daa58da0116c175f0e7cd119a4.html
以下是空闲态下的DRX
寻呼流程
寻呼的DRX
