DRX
本节主要介绍处于RRC_CONNECTED态下的UE的DRX处理流程。结合3GPP协议，介绍了几个timer的作用，同时还简单介绍了载波聚合对DRX的影响。
1.1 DRX介绍 基于包的数据流通常是突发性的，在一段时间内有数据传输，但在接下来的一段较长时间内没有数据传输。在没有数据传输的时候，可以通过停止接收PDCCH（此时会停止PDCCH盲检）来降低功耗，从而提升电池使用时间。这就是DRX（Discontinuous Reception，非连续接收）的由来。 DRX的基本机制是为处于RRC_CONNECTED态的UE配置一个DRX cycle。DRX cycle由“On Duration”和“Opportunity for DRX”组成：在“On Duration”时间内，UE监听并接收PDCCH（激活期）；在“Opportunity for DRX”时间内，UE不接收PDCCH以减少功耗（休眠期）。
从图1可以看出，在时域上，时间被划分成一个个连续的DRX Cycle。
On DurationUE shall monitor PDCCHOpportunity for DRXDRX Cycle
图1：DRX cycle
注意：处于休眠期的UE，只是不接收PDCCH，但是可以接收来自其它物理信道的数据，如PDSCH、ACK/NACK等。例如：在SPS调度中，处于休眠期的UE可以接收周期性配置的下行子帧上发送的PDSCH数据。
eNodeB通过DRX-Config来配置某个UE的DRX相关参数。
DRX-Config ::= CHOICE { release NULL, setup SEQUENCE { onDurationTimer ENUMERATED { psf1, psf2, psf3, psf4, psf5, psf6, psf8, psf10, psf20, psf30, psf40, psf50, psf60, psf80, psf100, psf200},-------从一个DRX Cycle的起始处算起，连续监听的PDCCH子帧数。 drx-InactivityTimer ENUMERATED { 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-RetransmissionTimer ENUMERATED { psf1, psf2, psf4, psf6, psf8, psf16, psf24, psf33},-------从UE期待收到DL重传的子帧（HARQ RTT之后）开始，连续监听的PDCCH子帧数。 longDRX-CycleStartOffset CHOICE { sf10 INTEGER(0..9), sf20 INTEGER(0..19), sf32 INTEGER(0..31), sf40 INTEGER(0..39), sf64 INTEGER(0..63), sf80 INTEGER(0..79), sf128 INTEGER(0..127), sf160 INTEGER(0..159), sf256 INTEGER(0..255), sf320 INTEGER(0..319), sf512 INTEGER(0..511), sf640 INTEGER(0..639), sf1024 INTEGER(0..1023), sf1280 INTEGER(0..1279), sf2048 INTEGER(0..2047), sf2560 INTEGER(0..2559) },-------指定了longDRX-Cycle和drxStartOffset。 shortDRX SEQUENCE { shortDRX-Cycle ENUMERATED { sf2, sf5, sf8, sf10, sf16, sf20, sf32, sf40, sf64, sf80, sf128, sf160, sf256, sf320, sf512, sf640},-------指定了short DRX Cycle持续的子帧数，即short DRX Cycle的大小。 drxShortCycleTimer INTEGER (1..16)-------指定了UE在多长的时间内，使用的是short DRX Cycle。该值为shortDRX-Cycle的倍数。 } OPTIONAL -- Need OR } }
DRX cycle的选择需要考虑电池节约与延迟之间的平衡。从一个方面讲，长DRX周期有益于延长UE的电池使用时间；例如网页浏览过程中，当用户正在阅读已经下载好的网页时，UE持续接收下行数据是对资源的浪
费。从另一个方面讲，当有新的数据传输时，一个更短的DRX周期有益于更快的响应，例如用户请求另一个网页或者进行VoIP通话时。为了满足上述需求，每个UE可以配置两个DRX cycle：shortDRX-Cycle和longDRX-Cycle。如果UE配置了shortDRX-Cycle，则longDRX-Cycle应该配置为shortDRX-Cycle的倍数。但在任一时刻，UE只能使用其中一种配置。
drxStartOffset指定DRX cycle的起始子帧，longDRX-Cycle指定了一个long DRX cycle占多少个子帧（即连续的“子帧数”），这两个参数都是由longDRX-CycleStartOffset字段确定的。onDurationTimer指定了从DRX cycle的起始子帧算起，需要监听PDCCH的连续“PDCCH子帧数”。
对于DRX，需要注意“连续的子帧数”与“连续的PDCCH子帧数”的区别。
FDD中，PDCCH子帧可以是任意子帧；但在TDD中，PDCCH子帧只包含下行子帧和包含DwPTS的子帧，这是因为只有下行子帧才有可能传输PDCCH。
DRX中定义了多个定时器（timer），有些指定的是“连续的子帧数”，而另一些指定的是“连续的PDCCH子帧数”。在TDD中，如果某个定时器指定的是“连续的PDCCH子帧数”，则上行子帧是不统计在该定时器的持续时间中的，此时该定时器实际持续的“子帧数”可能大于其指定的“PDCCH子帧数”。（见图3）
在大多数情况下，当一个UE在某个子帧被调度并接收或发送数据后，很可能在接下来的几个子帧内继续被调度，如果要等到下一个DRX cycle再来接收或发送这些数据将会带来额外的延迟。为了降低这类延迟，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重传并不关心DRX cycle，配置了DRX的UE与没有配置DRX时使用相同的方式来接收/发送HARQ反馈和重传。上行使用同步方式，前一次传输与重传之间有固定的timing关系。下行使用异步方式，前一次传输与重传之间没有固定的timing关系，因此LTE定义了一个时间窗（HARQ RTT Timer），允许UE从前一次下行传输算起，并持续该时间窗之后，才开始监听下行的重传。
为了允许UE在HARQ RTT期间内休眠，每个DL HARQ process定义了一个 “HARQ RTT(Round Trip Time) timer”。当某个下行HARQ process的TB解码失败时，UE可以假定至少在“HARQ RTT”子帧后才会有重传，因此当HARQ RTT timer正在运行时，UE没必要监听PDCCH。当HARQ RTT timer超时，且对应HARQ process接收到的数据没有被成功解码时，UE会为该HARQ process启动一个drx-RetransmissionTimer。当该timer运行时，UE会监听用于HARQ重传的PDCCH。drx-RetransmissionTimer的长度与eNodeB调度器的灵活度要求相关。如果是
要达到最优的电池消耗，就要求eNodeB在HARQ RTT timer超时之后，立即调度HARQ重传，这就也要求eNodeB为此预留无线资源，此时drx-RetransmissionTimer也就可以配得短些。drx-RetransmissionTimer指
定了从UE期待收到DL重传的子帧（HARQ RTT之后）开始，连续监听的“PDCCH子帧数”。注意：这里针对的是“下行重传”，而不是“上行重传”。 对FDD而言，HARQ RTT Timer的大小固定为8个子帧。对TDD而言，HARQ RTT Timer的大小为k + 4个子帧，其中k值为下行传输与对应HARQ反馈之间的时间间隔（k值见36.213的Table 10.1.3.1-1）。
相关推荐：
loading