第三章 LTE MAC协议解读 --- 非连续接收(DRX) 分享.docx

转载第三章LTEMAC协议解读-非连续接收（DRX）分享(2012-01-10 10:10:32)删除 标签： 转载原文地址：第三章LTEMAC协议解读-非连续接收（DRX）分享作者：LTE通信人家 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 TimerUE每次从DRX醒来后维持醒着的时间,UE在该段时间内会搜索PDCCH。Inactivity TimerUE在醒着时每次成功解码HARQ初始发送的PDCCH后保持active的时间，它的意思就是，当UE收到的PDCCH指示的是一个UL/DL的初始传输，而不是重传。UE在醒着时每次成功解码HARQ初始发 送的PDCCH后保持active的时间Active TimeUE从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 TimerUE预期DL Retransmission到达的最少间隔时间，也就是说重传最早会什么时候到，那么UE暂且不需要理会，也就是说这一段时间，改怎样就怎样，等到这个定时器超时了，那么它就要处于醒着的状态。DRX Retransmission TimerUE预期接收DL Retransmission的时间，也就 是需要这么多时间来接受下行重传。DRX cycle lengthDRX 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-savi