LTE：DRX介绍

《LTE：DRX介绍》由会员分享，可在线阅读，更多相关《LTE：DRX介绍（8页珍藏版）》请在装配图网上搜索。

1、本文介绍了LTE中关于RRC_CONNECTED态下的UE的DRX处理流程。主要结合3GPP协议，介绍了几个timer的作用。同时简单介绍了载波聚合对DRX的影响。一、DRX介绍基于包的数据流通常是突发性的，在没有数据传输的时候，可以通过关闭UE的接收电路来降低功耗，从而提升电池使用时间。这就是DRX（DiscontinuousReception，不连续接收）的由来。DRX的基本机制是为处于RRC_CONNECTED态的UE配置一个DRXcycle。DRXcycle由“OnDuration”和“OpportunityforDRX”组成：在“OnDuration”的时间内，UE监听并接收PDCC

2、H（激活期）；在“OpportunityforDRX”时间内，UE不接收下行信道的数据以节省功耗（休眠期）。从下图可以看出，在时域上，时间被划分成一个个连续的DRXCycle。图一：DRXcycledrxStartOffset指定DRXcycle的起始子帧，longDRX-Cycle指定了一个longDRXcycle占多少个子帧，这两个参数都是由longDRX-CycleStartOffset字段确定的。onDurationTimer指定了从DRXcycle的起始子帧算起，需要监听PDCCH的连续子帧数（即激活期持续的子帧数）。在大多数情况下，当一个UE在某个子帧被调度并接收或发送数据后，很可

3、能在接下来的几个子帧内继续被调度，如果要等到下一个DRXcycle再来接收或发送这些数据将会带来额外的延迟。为了降低这类延迟，UE在被调度后，会持续位于激活期，即会在配置的激活期内持续监听PDCCH。其实现机制是：每当UE被调度以初传数据时，就会启动（或重启）一个定时器drx-InactivityTimer，UE将一直位于激活态直到该定时器超时。drx-InactivityTimer指定了当UE成功解码一个指示初传的UL或DL用户数据的PDCCH后，持续位于激活态的连续子帧数。即每当UE有初传数据被调度，该定时器就重启一次。（注意：这里是初传而不是重传）为了允许UE在HARQRTT期间内休眠，

4、每个DLHARQprocess定义了一个“HARQRTT（RoundTripTime）timer”。当某个下行HARQprocess的TB解码失败时，UE可以假定至少在“HARQRTT”子帧后才会有重传，因此当HARQRTTtimer正在运行时，UE没必要监听PDCCH。当HARQRTTtimer超时，且对应HARQprocess接收到的数据没有被成功解码时，UE会为该HARQprocess启动一个drx-RetransmissionTimer。当该timer运行时，UE会监听用于HARQ重传的PDCCH。drx-RetransmissionTimer的长度与eNodeB调度器的灵活度要求相关

5、。如果是要达到最优的电池消耗，就要求eNodeB在HARQRTTtimer超时之后，立即调度HARQ重传，这就也要求eNodeB为此预留无线资源，此时drx-RetransmissionTimer也就可以配得短些。drx-RetransmissionTimer指定了从UE期待收到DL重传的子帧（HARQRTT之后）开始，连续监听PDCCH的最大子帧数。DXRcycle的选择包含了电池节约和延迟之间的平衡。从一个方面讲，长DRX周期有益于延长UE的电池使用时间；例如网页浏览，当用户在阅读已经下载好的网页时，如果此时UE持续接收下行数据则是浪费资源。从另一个方面讲，当有新的数据传输时，一个更短的D

6、RX周期有利于更快的响应；例如用户请求另一个网页或者VoIP。为了满足上述需求，每个UE可以配置两个DRXcycle：shortDRX-Cycle和longDRX-Cycle。图二：DRX流程当UE在“OnDuration”期间收到一个调度消息时，UE会启动一个“drx-InactivityTimer”并在该timer运行期间的每一个子帧监听PDCCH。当“drx-InactivityTimer”运行期间收到一个调度信息时，UE会重启该Timer。（对应上图标红为（2）的部分）当“drx-InactivityTimer”超时或收到DRXCommandMACcontrolelement时：1）如

7、果UE没有配置shortDRXcycle，则直接使用longDRXcycle；2）如果UE配置了shortDRXcycle，UE会使用shortDRXcycle并启动（或重启）“drxShortCycleTimer，当drxShortCycleTimer”超时,UE使用longDRXcycle。（对应图中标红为（3）的部分）如果UE当前使用shortDRXcycle,且(SFN*10)+ramenumber(drxStartOffset)modulo(shortDRX-Cycle);或者当UE当前使用longDRXcycle,且(SFN*10)+subframenumbermodulo(lon

8、gDRX-Cycle)=drxStartOffset,启动“onDurationTimer”。（对应上图标红为（1）的部分）总、结一下如何控制处于RRC_CONNECTED的UE进入DRX模式：?UE侧：UE基于定时器的超时来进入DRX态；?eNodeB侧：eNodeB通过DRXCommandMACcontrolelement来通知UE进入DRX态；总结一下当配置了DRXcycle,UE处于激活期的时间（有些并没有在前面介绍）：?onDurationTimer或InactivityTimer或drx-RetransmissionTimer或mac-ContentionResolutionTim

9、er正在运行时；?UE有在PUCCH上发送的挂起的SR时；?UE的HARQbuffer存在数据，并等待用于HARQ重传的ULgrant时；?UE成功接收用于响应非UE选择的preamble的RAR,却没有收到指示初传(使用C-RNTI)的PDCCH时。关于DRX的详细处理流程：见36.321的5.7节DRX是UE级别的特性，而不是基于每个无线承载来配置的。当UE配置了DRX时，UE只能在“激活期”的时间内发送周期性CQI。eNodeB在使用RRC来配置周期性CQI上报时，可以进一步地限制UE只能在“on-duration”的时间内发送CQI。图三结合36.213的5.7节总结了关于各种DRX相

10、关的timer启动和停止的触发条件。TimerStart(Restart)Stop当前使用Long(1)收到DRXCycle且(SFNDRXCommandM*10)+subframeACcontrolelement；onDurationTimernumbermodulo(longDRX-Cycle)=drxStartOffset。(2)timer超时收到用于调度new(1)收到transmission的DRXCommandMdrx-InactivityTimerPDCCH(DL和UL的ACcontrolelement;均可)(2)timer超时drx-RetransmissionTimerHA

11、RQRIITimer超时且对应HARQprocess的buffer中的数据没有成功解码(1)收到指示下行传输的PDCCH;(2)timer超时drxShortCycleTimer当配置了ShortDRXcycle时，如果drx-InactivityTimer超时，或收到DRXCommandMACcontrolelement,则启动或重启drxShortCycleTimer,并开始使用ShortDRXcycleTimer超时，此时开始使用LongDRXcycleHARQRTTtimerUE收到一个指示下行传输的PDCCHTimer超时图三：与DRX相关timer的启动和停止除了HARQRTTti

12、mer和drx-RetransmissionTimer是每个DLHARQprocess都有一个外，其它的timer是每个UE只有一个。从图三可以看出，当任一timer启动时，不会影响其它timer的运行。也即，UE处于激活态的最短时间为onDurationTimer指定的时间，而最长时间是不定的。二、载波聚合(CarrierAggregation，CA)对DRX的影响如果配置了一个或多个SCell，则所有的servingcells使用相同的DRX操作：?对于所有的DL载波单元(componentcarrier)而言，PDCCH监测的激活时间是相同的；?当UE处于休眠期时，所有的载波单元都不接收

13、数据；?当UE被激活时，所有activated的载波单元都将被激活以接收数据。虽然DRX降低了UE的功耗，但CA可能进一步提高功耗，因此，LTE提供了载波单元的activation/deactivation机制。(详见我的博客中关于CA的介绍)关于RRC_IDLE态下的DRX，请参见参考资料中的7，这篇文章介绍得相当详细。【参考资料】1 36.321的5.7节2 36.300的12章3 LTE-TheUMTSLongTermEvolution,2ndEdition的4 4GLTE/LTE-AdvancedforMobileBroadband的5 36.321的DRX-Config6 36.300的12章DRXinRRC_CONNECTED和7 DiscontinuousReception(DRX)inRRC_IDLE:Part1DiscontinuousReception(DRX)inRRC_IDLE:Part2