第三章 LTE MAC协议解读

3.4.3 DRX(非连续接收)

DRX，在一段时间里停止监听PDCCH信道，DRX分两种：IDLE DRX，顾名思义，也就是当UE处于IDLE状态下的非连续性接收，由于处于IDLE状态时，已经没有RRC连接以及用户的专有资源，因此这个主要是监听呼叫信道与广播信道，只要定义好固定的周期，就可以达到非连续接收的目的。但是UE要监听用户数据信道，则必须从IDLE状态先进入连接状态。

而另一种就是ACTIVE DRX，也就是UE处在RRC-CONNECTED 状态下的DRX， 可以优化系统资源配置，更重要的是可以节约手机功率，而不需要通过让手机进入到RRC_IDLE 模式来达到这个目的，例如一些非实时应用，像web浏览，即时通信等，总是存在一段时间，手机不需要不停的监听下行数据以及相关处理，那么DRX就可以应用到这样的情况，另外由于这个状态下依然存在RRC连接，因此UE要转到支持状态的速度非常快。

这里我们先介绍ACTIVE DRX，而IDLE DRX我打算放在呼叫那部分来介绍。而要理解DRX，我们就必须理解下面要描述的几个定时器与概念（所有的时间都是基于子帧的，也就是ms为单位）：

On duration Timer

UE每次从DRX醒来后维持醒着的时间,UE在该段时间内会搜索PDCCH。

Inactivity Timer

UE在醒着时每次成功解码HARQ初始发送的PDCCH后保持active的时间，它的意思就是，当UE收到的PDCCH指示的是一个UL/DL的初始传输，而不是重传。

UE在醒着时每次成功解码HARQ初始发送的PDCCH后保持active的时间

Active Time

UE从DRX醒来后保持醒着的总时间，在此时间段，UE监听PDCCH，包括所有导致UE处于ACTIVE的状态，比如是DRX周期开始“On Duration”，或者收到初始传输的PDCCH，或者是监听重传，等等，在36.321 5.7节，是这样定义ACTIVE TIME的，如果配置了DRX，那么ACTIVE Time 包括以下时间：

• onDurationTimer、drx-InactivityTimer、drx-RetransmissionTimer 以及 mac-ContentionResolutionTimer 运行的时间，或者
• 有SR（调度请求）已近发送到PUCCH，并且处于挂起的状态（也就是这个调度请求还没有满足，如此之类的）或者，
• 对一个挂起的HARQ重传存在上行授权，并且在对应的HARQ 缓冲区里面有数据；或者
• 在非竞争随机接入后，成功收到随机接入响应消息，此时应该有PDCCH发送给UE指示一个新的传输，但是这个PDCCH还没有收到，此时UE还是必须处于ACTIVE状态

HARQ RTT Timer

UE预期DL Retransmission到达的最少间隔时间，也就是说重传最早会什么时候到，那么UE暂且不需要理会，也就是说这一段时间，改怎样就怎样，等到这个定时器超时了，那么它就要处于醒着的状态。

DRX Retransmission Timer

UE预期接收DL Retransmission的时间，也就是需要这么多时间来接受下行重传。

DRX cycle length

DRX cycle length一旦配置/重配置就固定，即不会因为active time大于on duration而变化。

DRX运行：

• 如果在使用短DRX周期，检查当前子帧是否满足下面的公式：

[(SFN * 10) + subframe number] modulo (shortDRX-Cycle) = (drxStartOffset) modulo (shortDRX-Cycle)

• 或者在使用长DRX周期，那么检查如下的公式：

[(SFN * 10) + subframe number] modulo (longDRX-Cycle) = drxStartOffset

当上面的两个条件满足其中之一，那么就启动定时器onDurationTimer，此时UE就要开始监听PDCCH信道了

• 如果在这个子帧HARQ RTT 定时器超时，从前面的定时器介绍我们已经知道它是期望重发的最短时间，那么这个定时器超时后，重发就有可能到来了。如果这时对于的HARQ进程的软缓冲区还有没有解码成功的数据（也就是前面的数据接收失败了，要求重传的数据），那么就启动定时器drx-RetransmissionTimer开始监听PDCCH重传相关的内容。
• 如果收到DRX MAC控制信息单元，也就意味着eNB要求UE进入睡眠状态，那么这时就会停止两个定时器onDurationTimer和drx-InactivityTimer，但是并不会停止跟重传相关的定时器，我想这是因为eNB即使这时还是希望那个继续监听重传的内容。
• 如果drx-InactivityTimer 超时或者收到DRX MAC控制信息单元:
• 如果配置了短DRX周期:
• 那么启动或者重启drxShortCycleTimer;
• 使用短DRX周期。
• 否则；
• 使用长DRX 周期。
• 如果drxShortCycleTimer超时，那么
• 使用长DRX 周期。由于在短周期里面没有收到PDCCH，则就认为确实没什么数据发送接收，那么短周期的监听似乎没有必要，因此把监听的周期变长一点，这样长短周期配合能够达到更好的DRX效果。

上面一段话大部分摘自协议，并且加了自己的理解，但是也省略了一些我认为对协议理解无关的内容，如果大家还想完全了解，建议完整的读完协议。看来这么多文字描述，我想最好用一个图列来说明问题了，下面就是一个稍微复杂的例子：

图3.4.3-1 DRX应用举例

我们来看看上图，

一开始的时候无论是长或者短周期都会启动onDurationTimer定时器，开始监听PDCCH，一开始收到下行的一个新包（1），但是解码失败，此时就要启动两个定时器一个是drx-InactivityTimer定时器用来延长监听的时间的，还有一个是HARQ RTT定时器，因为失败了，所以它估计最早重传会这个定时器超时后来到，所以在这一段时间里，它还是可以不理会重传。

接着有一个上行的包发送（2），此时需要重启drx-InactivityTimer定时器，因为现在要完成这个上行的包发送的处理，所以它还会持续监听这么长时间，不过这个包成功了，所以不出什么意外它就会等到定时器超时；

然后定时器还没有超时，这个时候又来了一个下行的新包（3），所以又要启动drx-InactivityTimer定时器，不过由于新包解码成功，因此等到定时器超时，它就进入了睡眠状态了，此时要启动drxShortCycleTimer定时器，图上没有画出来。

经过一段时间，这个周期结束了，进入下一个短周期的开始点了，因此需要重启onDurationTimer定时器。这个定时器没结束之前，HARQ RTT定时器超时，UE认为此后重传可能会到，所以要启动HARQ 重传定时器监听重传的PDCCH信息，接着重传到了，并且成功了。

随后又发送了一个上行包，没有出错，因此等到定时器超时，就进入睡眠状态，此时需要启动drxShortCycleTimer定时器，但是如果在它超时之前，都没有收到PDCCH，那么它就进入了长DRX周期了。

这一个过程就完成了。

DRX、跟WiMAX power-saving 模式的实现机制是一样的，多个定时器的配合在于对于特定情况下，虽然从DRX cycle情况处于睡眠状态的时间，但是依然需要监听PDCCH，长和短周期的交互配合在于提高DRX的效果，当short DRX timer 超时但是没有任何PDCCH只是接收，那么转入到Long 周期提高power saving 效果降低系统延时。