LTE DRX处理流程

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 ::=

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为此预留无线资源，此时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）。

图2：DRX流程

当UE在“On Duration”期间收到一个调度消息（指示初传的PDCCH）时，UE会启动一个“drx-InactivityTimer”并在该timer运行期间的每一个下行子帧监听PDCCH。当“drx-InactivityTimer”运行期间收到一个调度信息（指示初传的PDCCH）时，UE会重启该timer。（对应图2中标红为(2)的部分）

当“drx-InactivityTimer”超时或收到DRX Command MAC control element时：1）如果UE没有配置short DRX cycle，则直接使用long DRX

本文来源：https://www.bwwdw.com/article/j295.html