LTE-DRX处理流程

DRX处理流程本节主要介绍处于RRC_CONNECTED态下的UE的DRX处理流程。结合3GPP协议，介绍了几个timer的作用，同时还简单介绍了载波聚合对DRX的影响。1.1DRX介绍基于包的数据流通常是突发性的，在一段时间内有数据传输，但在接下来的一段较长时间内没有数据传输。在没有数据传输的时候，可以通过停止接收PDCCH（此时会停止PDCCH盲检）来降低功耗，从而提升电池使用时间。这就是DRX（DiscontinuousReception，非连续接收）的由来。DRX的基本机制是为处于RRC_CONNECTED态的UE配置一个DRXcycle。DRXcycle由“OnDuration”和“OpportunityforDRX”组成：在“OnDuration”时间内，UE监听并接收PDCCH（激活期）；在“OpportunityforDRX”时间内，UE不接收PDCCH以减少功耗（休眠期）。从图1可以看出，在时域上，时间被划分成一个个连续的DRXCycle。UEshallmonitorPDCCHOnDurationDRXCycleOpportunityforDRX图1：DRXcycle注意：处于休眠期的UE，只是不接收PDCCH，但是可以接收来自其它物理信道的数据，如PDSCH、ACK/NACK等。例如：在SPS调度中，处于休眠期的UE可以接收周期性配置的下行子帧上发送的PDSCH数据。eNodeB通过DRX-Config来配置某个UE的DRX相关参数。DRX-Config::=CHOICE{releaseNULL,setupSEQUENCE{onDurationTimerENUMERATED{psf1,psf2,psf3,psf4,psf5,psf6,psf8,psf10,psf20,psf30,psf40,psf50,psf60,psf80,psf100,psf200},-------从一个DRXCycle的起始处算起，连续监听的PDCCH子帧数。drx-InactivityTimerENUMERATED{psf1,psf2,psf3,psf4,psf5,psf6,psf8,psf10,psf20,psf30,psf40,psf50,psf60,psf80,psf100,psf200,psf300,psf500,psf750,psf1280,psf1920,psf2560,psf0-v1020,spare9,spare8,spare7,spare6,spare5,spare4,spare3,spare2,spare1},-------当UE成功解码一个指示初传的UL或DL用户数据的PDCCH后，持续处于激活态的连续PDCCH子帧数。drx-RetransmissionTimerENUMERATED{psf1,psf2,psf4,psf6,psf8,psf16,psf24,psf33},-------从UE期待收到DL重传的子帧（HARQRTT之后）开始，连续监听的PDCCH子帧数。longDRX-CycleStartOffsetCHOICE{sf10INTEGER(0..9),sf20INTEGER(0..19),sf32INTEGER(0..31),sf40INTEGER(0..39),sf64INTEGER(0..63),sf80INTEGER(0..79),sf128INTEGER(0..127),sf160INTEGER(0..159),sf256INTEGER(0..255),sf320INTEGER(0..319),sf512INTEGER(0..511),sf640INTEGER(0..639),sf1024INTEGER(0..1023),sf1280INTEGER(0..1279),sf2048INTEGER(0..2047),sf2560INTEGER(0..2559)},-------指定了longDRX-Cycle和drxStartOffset。shortDRXSEQUENCE{shortDRX-CycleENUMERATED{sf2,sf5,sf8,sf10,sf16,sf20,sf32,sf40,sf64,sf80,sf128,sf160,sf256,sf320,sf512,sf640},-------指定了shortDRXCycle持续的子帧数，即shortDRXCycle的大小。drxShortCycleTimerINTEGER(1..16)-------指定了UE在多长的时间内，使用的是shortDRXCycle。该值为shortDRX-Cycle的倍数。}OPTIONAL--NeedOR}}DRXcycle的选择需要考虑电池节约与延迟之间的平衡。从一个方面讲，长DRX周期有益于延长UE的电池使用时间；例如网页浏览过程中，当用户正在阅读已经下载好的网页时，UE持续接收下行数据是对资源的浪费。从另一个方面讲，当有新的数据传输时，一个更短的DRX周期有益于更快的响应，例如用户请求另一个网页或者进行VoIP通话时。为了满足上述需求，每个UE可以配置两个DRXcycle：shortDRX-Cycle和longDRX-Cycle。如果UE配置了shortDRX-Cycle，则longDRX-Cycle应该配置为shortDRX-Cycle的倍数。但在任一时刻，UE只能使用其中一种配置。drxStartOffset指定DRXcycle的起始子帧，longDRX-Cycle指定了一个longDRXcycle占多少个子帧（即连续的“子帧数”），这两个参数都是由longDRX-CycleStartOffset字段确定的。onDurationTimer指定了从DRXcycle的起始子帧算起，需要监听PDCCH的连续“PDCCH子帧数”。对于DRX，需要注意“连续的子帧数”与“连续的PDCCH子帧数”的区别。FDD中，PDCCH子帧可以是任意子帧；但在TDD中，PDCCH子帧只包含下行子帧和包含DwPTS的子帧，这是因为只有下行子帧才有可能传输PDCCH。DRX中定义了多个定时器（timer），有些指定的是“连续的子帧数”，而另一些指定的是“连续的PDCCH子帧数”。在TDD中，如果某个定时器指定的是“连续的PDCCH子帧数”，则上行子帧是不统计在该定时器的持续时间中的，此时该定时器实际持续的“子帧数”可能大于其指定的“PDCCH子帧数”。（见图3）在大多数情况下，当一个UE在某个子帧被调度并接收或发送数据后，很可能在接下来的几个子帧内继续被调度，如果要等到下一个DRXcycle再来接收或发送这些数据将会带来额外的延迟。为了降低这类延迟，UE在被调度后，会持续处于激活期，即会在配置的激活期内持续监听PDCCH。其实现机制是：每当UE被调度以初传数据时，就会启动（或重启）一个定时器drx-InactivityTimer，UE将一直处于激活态直到该定时器超时。drx-InactivityTimer指定了当UE成功解码一个指示初传的UL或DL用户数据的PDCCH后，持续处于激活态的连续PDCCH子帧数。即当UE有初传数据被调度时，该定时器就启动或重启一次。注意：（1）这里是初传而不是重传，即指示重传的PDCCH并不会重启该定时器；（2）周期性的SPS子帧上发送的PDSCH虽然是初传，但并没有伴随着传输PDCCH，因此该PDSCH并不会重启该定时器；（3）drx-InactivityTimer指定的是连续的“PDCCH子帧数（下行子帧）”，而不是连续的“子帧数”。HARQ重传并不关心DRXcycle，配置了DRX的UE与没有配置DRX时使用相同的方式来接收/发送HARQ反馈和重传。上行使用同步方式，前一次传输与重传之间有固定的timing关系。下行使用异步方式，前一次传输与重传之间没有固定的timing关系，因此LTE定义了一个时间窗（HARQRTTTimer），允许UE从前一次下行传输算起，并持续该时间窗之后，才开始监听下行的重传。为了允许UE在HARQRTT期间内休眠，每个DLHARQprocess定义了一个“HARQRTT(RoundTripTime)timer”。当某个下行HARQprocess的TB解码失败时，UE可以假定至少在“HARQRTT”子帧后才会有重传，因此当HARQRTTtimer正在运行时，UE没必要监听PDCCH。当HARQRTTtimer超时，且对应HARQprocess接收到的数据没有被成功解码时，UE会为该HARQprocess启动一个drx-RetransmissionTimer。当该timer运行时，UE会监听用于HARQ重传的PDCCH。drx-RetransmissionTimer的长度与eNodeB调度器的灵活度要求相关。如果是要达到最优的电池消耗，就要求eNodeB在HARQRTTtimer超时之后，立即调度HARQ重传，这就也要求eNodeB为此预留无线资源，此时drx-RetransmissionTimer也就可以配得短些。drx-RetransmissionTimer指定了从UE期待收到DL重传的子帧（HARQRTT之后）开始，连续监听的“PDCCH子帧数”。注意：这里针对的是“下行重传”，而不是“上行重传”。对FDD而言，HARQRTTTimer的大小固定为8个子帧。对TDD而言，HARQRTTTimer的大小为k+4个子帧，其中k值为下行传输与对应HARQ反馈之间的时间间隔（k值见36.213的Table10.1.3.1-1）。图2：DRX流程当UE在“OnDuration”期间收到一个调度消息（指示初传的PDCCH）时，UE会启动一个“drx-InactivityTimer”并在该timer运行期间的每一个下行子帧监听PDCCH。当“drx-InactivityTimer”运行期间收到一个调度信息（指示初传的PDCCH）时，UE会重启该timer。（对应图2中标红为(2)的部分）当“drx-InactivityTimer”超时或收到DRXCommandMACcontrolelement时：1）如果UE没有配置shortDRXcycle，则直接使用longDRXcycle；2）如果UE配置了shortDRXcycle，UE会使用shortDRXcycle并启动（或重启）“drxShortCycleTimer”，当“drxShortCycleTimer”超时，UE使用longDRXcycle。（对应图2中标红为(3)的部分）如果UE当前使用shortDRXcycle，且[(SFN*10)+subframenumber]modulo(shortDRX-Cycle)=(drxStartOffset)modulo(shortDRX-Cycle)；或者UE当前使用longDRXcycle，且[(SFN*10)+subframenumber]modulo(longDRX-Cycle)=drxStartOffset，则启动“onDurationTimer”。（对应图2中标红为(1)的部分）注：drxShortCycleTimer启动后，只说明当前使用shortDRXcycle，但此时未必启动了DRXshortcycle。DRXshortcycle是与onDurationTimer同时启动的。类似的，longDRXcycle也是与onDurationTimer同时启动的。当UE配置了DRXcycle时，UE处于激活期的时间包括：onDurationTimer、或InactivityTimer、或drx-RetransmissionTimer、或mac-ContentionResolutionTimer正在运行时；UE已经在PUCCH上发送了SR，且该SR当前处于pending态；UE的HARQbuffer存在数据，并等待HARQ重传的ULgrant时；UE成功接收了用于响应非UE选择的preamble的RAR，却没有收到指示初传（使用C-RNTI）的PDC