LTE资源调度（7）-DRX不连续接收（1）

1.为何要使用DRX

在讲授DRX的概念前，我们需要先了解下甚么是“空闲态”，甚么是“连接态”。

我们常常会听到“空闲态”、“连接态”这样的术语，这个概念是从RRC层角度来讲的。简单来讲，当UE在某个小区完成了驻留以后，我们就能够称该UE进入了“空闲态”或“IDLE态”。如果该UE后续又完成了随机接入进程，那末我们就能够称该UE进入了“连接态”或“CONNECTED态”。

不管是空闲态，还是连接态，如果没有我们本文提到的DRX机制，UE就会1直监听下行PDCCH子帧，查看是不是有来自服务小区的信息。这样做看起来没有问题，但是现实很多时候，UE其实不是1直在和网络进行有效信息的交互，不会总是履行上传或下载业务，通话时也不会1直有语音数据的传输。大多数的时间，UE和网络是没有数据交互的，如果这个时候UE还去延续的监听PDCCH子帧，明显是很费电的。因此，在保证数据能有效传输的条件下，有必要设计1种节省UE电量的机制，这个机制我们就叫做DRX。

2.甚么是DRX

DRX，英文全称为Discontinuous Reception，即不连续接收，这类方法可让UE周期性的在某些时候进入眠眠状态（sleep mode），不去监听PDCCH子帧，而需要监听的时候，则从睡眠状态中唤醒（wake up），这样就能够使UE到达省电的目的。虽然这样做对数据传输的时延有1定的影响，但如果这类时延其实不影响用户体验，那末斟酌到UE更加重要的功率消耗，履行DRX是很成心义的。

DRX机制在空闲态和连接态下的实现是不同的，相对而言，连接态下的DRX机制要复杂的多。本篇博文专门介绍连接态下的DRX机制（Connected DRX，CDRX），而空闲态下的DRX机制即寻呼机制，将在下1篇博文中介绍。下文描写的DRX均特指UE处于连接态时使用的DRX。

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

（图1）

3.为何要使用drx-InactivityTimer

我们来斟酌这样的1个场景：0号子帧是唤醒时间On_Duration的最后1个子帧，此时网侧恰好有1个较大字节的数据需要发给UE，这些数据没法在0号子帧全部发送完。如果依照上文图1的DRX周期，那末UE将在1号子帧进入DRX睡眠状态，不会再去接收来自网侧的任何下行PDSCH数据。网侧也只能等到DRX周期结束，并在下1个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进入眠眠状态，系统引入了1个与DRX相干的MAC控制单元DRX command，有时候也被形象的叫做Go-To-Sleep CE。

当网侧检测到已没有下行数据可传时，可以向该UE发送1个MAC PDU，这个PDU里携带1个DRX command控制单元。当UE收到这个DRX控制单元以后，不管当前是处于On_Duration状态，还是Inactivity定时器正在运行，都会立即进入眠眠状态，如图3所示。

（图3）

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

（图4）

5.长周期和短周期

前文图1已提到，1个DRX周期等于UE唤醒时间（ON-duration）和睡眠时间的总和。在LTE里，系统可以根据不同的业务场景，给UE分别配置短周期（short DRX cycle）或长周期（long DRX cycle）。比如在进行VOIP业务时，语音编解码器通常20ms发送1个VOIP包，那末就能够配置长度为20ms的DRX短周期，而在语音通话期间较长的静默期，就能够配置DRX长周期。如果同时配置了短周期和长周期，且在drxShortCycleTimer个子帧内都没有监测到下行PDCCH，那末UE将进入1次长周期睡眠，以下图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：该参数表示在1个DRX周期里，UE睡醒后的在线时长。以PDCCH子帧个数为基本单位，比如psf6表示UE在线监测的时长为6个PDCCH子帧。

drx-InactivityTimer：该参数表示当UE成功解码到1个下行PDCCH以后，还需要继续监测多少个PDCCH子帧。一样以PDCCH子帧个数为基本单位，比如psf80表示UE还需要继续监测80个下行PDCCH子帧才能进入眠眠态。

drx-RetransmissionTimer：这个参数用在下行重传的场景，表示UE为了接收期望的下行重传数据，需要连续监测的最大PDCCH子帧个数。一样以PDCCH子帧个数为基本单位，比如psf8表示UE为了接收下行重传数据，还需要继续等待最多8个下行PDCCH子帧。由于下行重传是自适应的，时间其实不肯定，如果UE发现eNB需要进行1次重传，那末就需要等待1段时间，这个时间就由这个参数来控制。在定时器运行的这段时间内，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子帧为单位的，而与周期相干的都是以子帧为单位的。

1个典型的长短周期DRX流程如图7所示。具体流程为：UE在时刻（0，0）成功解码到1个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机制中，还需要用到1个名为“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处于激活时间）。除这些情况以外，当以下条件之1产生时，UE也需要延续的监测PDCCH信道：

DRX的处理流程需要斟酌的场景比较多，如果用文字描写的话不太清晰，这里我用流程图的情势展现给大家，以下面的图9所示（由于截图的缘由，所以尽可能紧缩了空间排版）。

（图9）

上面图9中提到的半双工FDD的概念，是2008年爱立信在深圳的1次3GPP会议中提出来的，初衷是允许UE在3.5GHz和小于860MHz的Band中，可以进入FDD半双工的模式。但截至目前，还没有听说哪家手机芯片厂商支持LTE半双工FDD的情况。

如果eNB配置了DRX功能，除影响UE侧检测下行PDCCH子帧，还会影响UE侧SRS/CQI/PMI/RI的发送，具体为：

cqi-Mask参数是限制UE是不是仅在DRX周期的onDuration时间内发送CQI/PMI/RI的，由RRC消息配置，具体在 RRCConnectionReconfiguration 或 RRCConnectionReestablishment 或 RRCConnectionSetup 消息的 RadioResourceConfigDedicated -> PhysicalConfigDedicated -> CQI-ReportConfig 字段中。

除此以外，斟酌到UE侧的处理时延，如果UE在激活时间的最后4个子帧内检测到1个标识上行或下行新传的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⑴2) Overall description

（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