本文格式为Word版，下载可任意编辑LTE DRX处理流程 DRX处理流程 本节主要介绍处于RRC_CONNECTED态下的UE的DRX处理流程结合3GPP协议，介绍了几个timer的作用，同时还简朴介绍了载波聚合对DRX的影响 1.1 DRX介绍 基于包的数据流通常是突发性的，在一段时间内有数据传输，但在接下来的一段较长时间内没有数据传输在没有数据传输的时候，可以通过中断接收PDCCH（此时会中断PDCCH盲检）来降低功耗，从而提升电池使用时间这就是DRX（Discontinuous Reception，非连续接收）的由来 DRX的根本机制是为处于RRC_CONNECTED态的UE配置一个DRX cycleDRX 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 ::= release setup CHOICE { NULL, SEQUENCE { ENUMERATED { psf1, psf2, psf3, psf4, psf5, psf6, psf8, psf10, psf20, psf30, psf40, psf50, psf60, psf80, psf100, psf200},-------从一个DRX Cycle的起始处算起，连续监 onDurationTimer 听的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 sf10 sf20 sf32 sf40 sf64 sf80 sf128 sf160 sf256 sf320 sf512 sf640 sf1024 CHOICE { INTEGER(0..9), INTEGER(0..19), INTEGER(0..31), INTEGER(0..39), INTEGER(0..63), INTEGER(0..79), INTEGER(0..127), INTEGER(0..159), INTEGER(0..255), INTEGER(0..319), INTEGER(0..511), INTEGER(0..639), INTEGER(0..1023), } } sf1280 sf2048 sf2560 INTEGER(0..1279), INTEGER(0..2047), INTEGER(0..2559) },-------指定了longDRX-Cycle和drxStartOffset。
shortDRX } SEQUENCE { ENUMERATED { sf2, sf5, sf8, sf10, sf16, sf20, sf32, sf40, sf64, sf80, sf128, sf160, sf256, sf320, sf512, sf640},-------指定了short shortDRX-Cycle DRX Cycle持续的子帧数，即short DRX Cycle的大小 drxShortCycleTimer OPTIONAL INTEGER (1..16)-------指定了UE在多长的时间内，使用的是 -- Need OR short DRX Cycle该值为shortDRX-Cycle的倍数 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为此预留。