深入理解LTE网络的CDRX


CDRX概念概述

DRX: Discontinuous Reception
CDRX: Connected mode DRX

DRX是UE为了省电而引入的一项功能,由RRC层进行配置。通过控制DRX功能,可以控制UE在PDCCH上对C-RNTI、TPC-PUCCH-RNTI、TPC-PUSCH-RNTI、SPS C-RNTI等等的监测。在连接态下,如果RRC层对MAC层配置了DRX功能,那么UE在物理层就可以间断性地对PDCCH进行监测;否则,UE就必须连续地对PDCCH进行监测。CDRX,指的就是UE在连接态下的DRX功能;而空闲态下的DRX功能,则是我们所熟知的寻呼功能(paging)。本文将对CDRX的工作机制进行详细介绍,对paging的介绍不在本文范围之内。

通过CDRX,可以让UE周期性的在某些时候进入睡眠状态(sleep mode),不去监听PDCCH子帧,而需要监听的时候,则从睡眠状态中唤醒(wake up),这样就可以使UE达到省电的目的。虽然这样做对数据传输的时延有一定的影响,但如果这种时延并不影响用户体验,那么考虑到UE更为重要的功率消耗,执行DRX是很有意义的。

一个典型的DRX周期如下图所示。在这个图中,标识“On Duration”的这段时间是UE监控下行PDCCH子帧的时间,在这段时间里,UE是处于唤醒状态的。标识“Opportunity for DRX”的这段时间是DRX睡眠时间,即UE为了省电,进入了睡眠而不监控PDCCH子帧的时间。从这个图中可以看到,用于DRX睡眠的时间越长,UE的功率消耗就越低,但相应的,业务传输的时延也会跟着增加。
36.321 Figure 3.1-1: DRX Cycle

(36.321 Figure 3.1-1: DRX Cycle)

CDRX参数配置

DRX由eNodeB通过RRC层向MAC层配置,eNodeB通过ConnectionReconfiguration或者RRCConnectionSetup或者RRCConnectionReestablishment这三条RRC信令来告诉UE是否配置DRX以及DRX参数。UE侧RRC层收到DRX配置后,再向MAC层下发DRX配置参数。

在上面三条RRC消息中,如果MAC-MainConfig这个IE(information element)里带了DRX-Config字段,那么UE侧收到消息后,就会根据DRX-Config字段对UE侧MAC层进行DRX参数配置。DRX-Config的内容如下图所示,其中,psf表示PDCCH subframe,sf表示subframe。
36.331 DRX-Config IE

(36.331 6.3.2 MAC-MainConfig information element)

CDRX参数介绍

DRX-Config字段里包含了DRX配置的相关参数,MAC层根据DRX-Config对CDRX相关参数进行配置,CDRX有关概念的定义如下所述(见36.321)。

参数定义
Active TimeTime related to DRX operation, as defined in subclause 5.7, during which the MAC entity monitors the PDCCH.
DRX CycleSpecifies the periodic repetition of the On Duration followed by a possible period of inactivity (see figure 3.1-1 below).
drx-InactivityTimerIt specifies the number of consecutive PDCCH-subframe(s) after the subframe in which a PDCCH indicates an initial UL, DL or SL user data transmission for this MAC entity.
drx-RetransmissionTimerSpecifies the maximum number of consecutive PDCCH-subframe(s) until a DL retransmission is received.
drxShortCycleTimerSpecifies the number of consecutive subframe(s) the MAC entity shall follow the Short DRX cycle.
drxStartOffsetSpecifies the subframe where the DRX Cycle starts.
drx-ULRetransmissionTimerSpecifies the maximum number of consecutive PDCCH-subframe(s) until a grant for UL retransmission or the HARQ feedback is received.
HARQ RTT TimerThis parameter specifies the minimum amount of subframe(s) before a DL assignment for HARQ retransmission is expected by the MAC entity.
onDurationTimerSpecifies the number of consecutive PDCCH-subframe(s) at the beginning of a DRX Cycle.
PDCCH-subframeRefers to a subframe with PDCCH. This represents the union over PDCCH-subframes for all serving cells excluding cells configured with cross carrier scheduling for both uplink and downlink, as specified in TS 36.331 [8]; except if the UE is not capable of simultaneous reception and transmission in the aggregated cells where this instead represents the PDCCH-subframes of the SpCell.
UL HARQ RTT TimerThis parameter specifies the minimum amount of subframe(s) before a UL HARQ retransmission grant is expected by the MAC entity.

下面对CDRX相关概念进行详细介绍。


onDurationTimer

该参数表示在一个DRX周期里,UE睡醒后的在线时长。以PDCCH子帧个数为基本单位,比如psf6表示UE在线监测的时长为6个PDCCH子帧。当UE满足DRX周期条件时,就会启动onDurationTimer,进入onDuration。在哪个(SFN,subframe)启动 onDurationTimer呢?计算公式如下:

  1. 如果配置了short DRX,则(SFN,subframe)需要满足以下的式子(公式1):
    [ ( S F N ∗ 10 ) + s u b f r a m e   n u m b e r ]   m o d   ( s h o r t D R X _ C y c l e ) = = ( d r x S t a r t O f f s e t )   m o d   ( s h o r t D R X _ C y c l e ) [(SFN * 10) + subframe\ number]\ mod\ (shortDRX\_Cycle) == (drxStartOffset)\ mod\ (shortDRX\_Cycle) [(SFN10)+subframe number] mod (shortDRX_Cycle)==(drxStartOffset) mod (shortDRX_Cycle)
  2. 如果配置了long DRX,则(SFN,subframe)需要满足以下的式子(公式2):
    [ ( S F N ∗ 10 ) + s u b f r a m e   n u m b e r ]   m o d   ( l o n g D R X _ C y c l e ) = = ( d r x S t a r t O f f s e t ) [(SFN * 10) + subframe\ number]\ mod\ (longDRX\_Cycle) == (drxStartOffset) [(SFN10)+subframe number] mod (longDRX_Cycle)==(drxStartOffset)

ShortDRX和LongDRX计算公式中的drxStartOffset是同一个值,就是DRX-config中longDRX-CycleStartoffset中的CycleStartoffset。


drx-InactivityTimer

该参数表示当UE成功解码到一个下行PDCCH之后,还需要继续监测多少个PDCCH子帧。同样以PDCCH子帧个数为基本单位,比如psf80表示UE还需要继续监测80个下行PDCCH子帧才能进入睡眠态。当PDCCH子帧中显示有新的上行或下行传输时(即UE成功盲检到一个下行PDCCH之后)启动该定时器,当收到Go-To-Sleep CE(即DRX Command MAC CE)时停止该定时器。

当drx-InactivityTimer超时时,如果配置short DRX,则:

  1. 使用short DRX
  2. 触发drxShortCycleTimer

否则:

  1. 使用 long DRX

有人可能会认为,如果配置DRX的话,UE一定会睡眠,而eNodeB一定会根据DRX的规则,只在特定的时间发送数据给UE。这种理解是不正确的,因为drx-InactivityTimer参数的存在,只要UE有新传数据到达(PDCCH盲检到新传),drx-InactivityTimer 就会重新启动(reset), UE的激活的时间就会延长(extended)。因此,假如eNodeB一直不停地给UE发送数据,UE可能就一直处于激活的状态,而不会进入睡眠状态。


引入drx-InactivityTimer的意义

我们来考虑这样的一个场景:0号子帧是唤醒时间On_Duration的最后一个子帧,此时网侧刚好有一个较大字节的数据需要发给UE,这些数据无法在0号子帧全部发送完。如果按照上文图1(36.321 Figure 3.1-1)的DRX周期,那么UE将在1号子帧进入DRX睡眠状态,不会再去接收来自网侧的任何下行PDSCH数据。网侧也只能等到DRX周期结束,并在下一个On_Duration时刻到来时,继续向UE发送没有传完的数据。这种处理机制虽然没有错,但显然增加了整个业务的处理时延。为了避免这种情况的出现,DRX机制中增加了drx-Inactivity定时器,如下图所示。
在这里插入图片描述
如果drx-inactivityTimer正在运行,那么即便原本配置的On_Duration时间已经结束,UE仍然需要继续监听下行PDCCH子帧,直到DRX InactivityTimer超时。增加了DRX-InactivityTimer机制之后,显然会减少数据的处理时延,但这将会引入下文描述的另一个问题。


引入DRX command控制单元的意义

上节图中描述了DRX-InactivityTimer的作用是为了降低数据的处理时延,但如果DRX-InactivityTimer的时长设置的过长,当网侧的数据发送完之后定时器还没有超时,则UE还不得不继续监听下行子帧,无法及时的进入睡眠状态。为了尽量快速的让UE进入睡眠状态,系统引入了一个与DRX相关的MAC控制单元DRX command,有时候也被形象的叫做Go-To-Sleep CE。

当网侧检测到已经没有上下行数据可传时,可以向该UE发送一个MAC PDU,这个PDU里携带一个DRX command控制单元。当UE收到这个DRX控制单元之后,将停止OnDurationTimer和drx-InactivityTimer,尽快的进入睡眠状态,如下图所示。
在这里插入图片描述
每个MAC控制单元都对应着一个子头,并且一般来说,控制单元都占用特定长度的字节数,比如短BSR控制单元占用了1个字节,加上1个字节的子头,共占用2个字节;再比如长BSR控制单元占用了3个字节,加上1个字节的子头,共占用4个字节。但DRX Command控制单元比较特殊,它所占用的字节数是0,即只需要发送1个字节的子头即可,不需要为控制单元预留空间。这个子头里的LCID需要设置为0x1E(11110),如下图所示。
在这里插入图片描述

(36.321 Table 6.2.1-1 Values of LCID for DL-SCH)

drx-RetransmissionTimer

这个参数用在下行重传的场景。由于下行HARQ采用的是异步重传,因此UE并不确定eNB什么时候会下发重传数据,但UE也不可能无限地等待下去,毕竟UE还需要省电,还需要进入睡眠状态,所以这个重传定时器是表示UE为了接收期望的下行重传数据,需要连续监测的最大PDCCH子帧个数。同样以PDCCH子帧个数为基本单位,比如psf8表示UE为了接收下行重传数据,还需要继续等待最多8个下行PDCCH子帧。

当下面两个条件都满足时,就会启动该重传定时器:

  1. HARQ RTT Timer超时,且
  2. 对应的DL HARQ进程buffer里的数据没有被成功解码

当满足下面两个条件其中之一时,就会停止该重传定时器:

  1. PDCCH子帧显示该进程有数据传输,或
  2. 当前属于DL-SPS子帧

为什么需要等到HARQ RTT Timer超时以后才启动drx-RetransmissionTimer呢?因为HARQ RTT Timer一旦超时就意味着UE可以开始接收eNodeB的重传数据了,若HARQ RTT Timer还没有超时,eNodeB也不会下发重传数据,因此此时也没必要启动drx-RetransmissionTimer。下图显示了HARQ RTT Timer和drx-RetransmissionTimer启动的先后关系,从下图中也可以看到drx-InactivityTimer重启3次(红色示意图),延长了UE的激活时间。
在这里插入图片描述


drxShortCycleTimer

这个参数表示在短周期内持续多少个子帧没有收到PDCCH就进入长周期。如果值为2,则表示持续(2×shortDRX-Cycle)个子帧没有成功解码到PDCCH就进入长周期。

当配置了shortDRX 时,满足以下任意一个条件就会启动这个定时器:

  1. drx-InactivityTimer超时
  2. 收到DRX command MAC CE

drxShortCycleTimer超时后,UE就会切换到长周期,使用LongDRX cycle。

  • if drx-InactivityTimer expires or a DRX Command MAC control element is received in this subframe:
    • if the Short DRX cycle is configured:
      • start or restart drxShortCycleTimer;
      • use the Short DRX Cycle.
    • else:
      • use the Long DRX cycle.

–36.321 section 5.7

为什么在drx-InactivityTimer超时之后不是进入长DRX周期,而是进入短DRX周期呢?这里举个可能不那么恰当,但是比较通俗的例子来说明,那就是新冠疫情的动态清零政策。比如,某个地区很长一段时间来都没有任何无症状感染者(类比睡眠状态),那么防疫部门就不会要求该地区的人每天都去做核酸检测(一直monitor PDCCH),可能一周才去做一次(long DRX cycle)。然后,突然某一天该地出现了一例无症状感染者(接收到PDCCH),那么,防疫部门就会要求该地区的人接下来的几天每天都做核酸(连续monitor PDCCH),假如连续几天都没有新增病例(drx-InactivityTimer超时了),那么可以认为这一轮疫情大概率已经被消灭了,那么是不是可以直接恢复到一周一检测呢?并不是,为了保险起见,防疫部门会先做一段时间的试探性调整,在这段时间内把周期稍微调长一点,从原来的一天一检,变成到几天一检,比如三天一检(短DRX周期),假如经过一段时间的试探(drxShortCycleTimer)以后,还是没有新增病例(没检测到PDCCH),那么完全有理由相信这轮疫情已经结束,这时候就又可以恢复到一周一检的状态(long DRX)。

CDRX周期的调整也是采用类似的策略,通过动态地调整接收PDCCH的周期,一方面可以防止过于激进,假如UE在drx-InactivityTimer超时后直接进入长DRX周期,这就会导致在drx-InactivityTimer超时后到来的数据不得不等待漫长的长DRX周期才能发送至UE;另一方面,先经过一个短DRX周期的试探性的调整,再进入长DRX周期,这样又可以让UE能尽快地进入长DRX周期,以更进一步地省电。


longDRX-CycleStartoffset

这个参数可以同时表示 longDRX-Cycle 和 drxStartOffset 这两个字段,以子帧为单位。比如长周期选择sf1280,偏移选择0。但需要注意的是,如果网侧同时也配置了短周期(ShortDrx-Cycle)参数,那么长周期必须配置成短周期的整数倍。比如短周期配置的是sf64(64个子帧),那么长周期就不能配置sf80,因为80不能整除64。


shortDRX-Cycle

这个参数表示DRX采用的短周期时长,以子帧为单位,sf5表示短周期时长(含on-duration时间)为5个子帧。


long DRX cycle

一个DRX周期等于UE唤醒时间(ON-duration)和睡眠时间的总和。在LTE里,系统可以根据不同的业务场景,给UE分别配置短周期(short DRX cycle)或者长周期(long DRX cycle)。比如在进行VOIP业务时,语音编解码器通常20ms发送一个VOIP包,那么就可以配置长度为20ms的DRX短周期,而在语音通话期间较长的静默期,就可以配置DRX长周期。

Short DRX是可选的IE,如果网侧在配置了longDRX-CycleStartoffset的同时也配置了ShortDrx-Cycle参数,则网侧给UE同时配置了短周期和长周期,此时长周期必须配置成短周期的整数倍。当drxShortCycleTimer定时器超时后,UE将进入一次长DRX周期,如下图所示。图中,drx-InactivityTimer定时器超时后开启drxShortCycleTimer定时器。
在这里插入图片描述
根据36.321第5.7节,满足以下条件时,UE就会进入long DRX周期:

  • if drx-InactivityTimer expires or a DRX Command MAC control element is received in this subframe:

    • if the Short DRX cycle is configured:
      • start or restart drxShortCycleTimer;
      • use the Short DRX Cycle.
    • else:
      • use the Long DRX cycle.
  • if drxShortCycleTimer expires in this subframe:
    - use the Long DRX cycle.

  • if a Long DRX Command MAC control element is received:
    - stop drxShortCycleTimer;
    - use the Long DRX cycle.

由以上各定时器与周期的描述可以看出:与定时器相关的参数都是以PDCCH子帧为单位的,而与周期相关的都是以子帧为单位的。


HARQ RTT Timer

在DRX机制中,还需要用到一个名为“HARQ RTT Timer”的定时器,这个定时器或者说这个参数,也是与下行重传相关的。它的含义是,UE在收到期望的下行重传数据之前,需要等待的最少子帧个数。当收到PDCCH子帧显示有下行传输或处于DL-SPS子帧时开启该RTT定时器,同时也将drx-RetransmissionTimer停掉,而当HARQ RTT Timer超时时会开启drx-RetransmissionTimer。

对于FDD-LTE来说,HARQ RTT Timer的值固定等于8个子帧。对于TDD-LTE来说,HARQ RTT Timer的值等于(k+4)个子帧,k表示下行PDSCH传输与其应答ACK的时延,具体值如下图所示。比如当前是上下行子帧配置1,上行子帧3(对应子帧n)用于回复eNodeB在下行子帧n-4发送的PDSCH的ACK/NACK。假如PDSCH是在9号子帧下发的,那么eNB将在3号子帧接收应答,所以k=4。
在这里插入图片描述

(36.213 Table 10.1.3.1-1: Downlink association set index K for TDD)

CDRX场景举例

在介绍完CDRX的相关概念后,下面介绍几个具体的场景。


场景1

一个典型的长短周期DRX流程如下图所示。具体流程为:UE在时刻(0,0)成功解码到一个PDCCH子帧,因此开启了drx-inactivityTimer(3个子帧的长度);当drx-inactivityTimer超时后开启drxShortCycleTimer;到了时刻(0,5),满足了进入短周期的时间条件(即onDurationTimer小节的公式1),UE被唤醒进入on-duration(持续2个子帧);在时刻(1,0)和(1,5)多次进入短周期;到了(1,9)时刻,(drxShortCycleTimer×shortDrxCycle)=15个子帧内没有成功解码到PDCCH子帧,准备进入长DRX周期,在(2,0)满足长周期进入条件(即onDurationTimer小节的公式2),UE进入长DRX周期,时刻(2,9)结束长周期;UE在(3,0)收到PDCCH子帧,因此重新启动了drx-inactivity定时器。
场景1


场景2

改变一下DRX参数,假如DRX参数如下:

参数Value
onDurationTimer2
drx-InactivityTimer2
drxShortCycleTimer2 (2*shortDRXcycle = 10subframe)
shortDRXcycle5
longDRXcycle10
drxStartOffset0

short DRX

根据onDurationTimer小节公式1,
[ ( S F N ∗ 10 ) + s u b f r a m e   n u m b e r ]   m o d   ( s h o r t D R X _ C y c l e ) = = ( d r x S t a r t O f f s e t )   m o d   ( s h o r t D R X _ C y c l e ) [(SFN * 10) + subframe\ number]\ mod\ (shortDRX\_Cycle) == (drxStartOffset)\ mod\ (shortDRX\_Cycle) [(SFN10)+subframe number] mod (shortDRX_Cycle)==(drxStartOffset) mod (shortDRX_Cycle)
可以计算出在短周期下onDurationTimer的启动时刻为满足以下条件的(SFN,subframe):
[ ( S F N ∗ 10 ) + s u b f r a m e   n u m b e r ]   m o d   5 = = 0   m o d   5 = = 0 [(SFN * 10) + subframe\ number]\ mod\ 5 == 0\ mod\ 5 == 0 [(SFN10)+subframe number] mod 5==0 mod 5==0
因此, ( S F N , s u b f r a m e ) = ( 0 , 0 ) , ( 0 , 5 ) , ( 1 , 0 ) , ( 1 , 5 ) ( 2 , 0 ) , ( 2 , 5 ) , ( 3 , 0 ) , ( 3 , 5 ) … (SFN,subframe) = {(0,0),(0,5) ,(1,0),(1,5)(2,0),(2,5),(3,0),(3,5)…} (SFN,subframe)=(0,0),(0,5),(1,0),(1,5)(2,0),(2,5),(3,0),(3,5)

Long DRX

根据onDurationTimer小节公式2,
[ ( S F N ∗ 10 ) + s u b f r a m e   n u m b e r ]   m o d   ( l o n g D R X _ C y c l e ) = = ( d r x S t a r t O f f s e t ) [(SFN * 10) + subframe\ number]\ mod\ (longDRX\_Cycle) == (drxStartOffset) [(SFN10)+subframe number] mod (longDRX_Cycle)==(drxStartOffset)
可以计算出在长周期下onDurationTimer的启动时刻为满足以下条件的(SFN,subframe):
( ( S F N ∗ 10 ) + s u b f r a m e )   m o d   10 = 0 ((SFN * 10) + subframe)\ mod\ 10 = 0 ((SFN10)+subframe) mod 10=0
因此, ( S F N , s u b f r a m e ) = ( 0 , 0 ) , ( 1 , 0 ) , ( 2 , 0 ) , ( 3 , 0 ) (SFN,subframe) ={(0,0), (1,0),(2,0),(3,0)} (SFN,subframe)=(0,0),(1,0),(2,0),(3,0)

UE在onDurationTimer 区间接收到PDCCH,会触发drx-InactivityTimer;drx-InactivityTimer超时,会触发drxShortCycleTimer;drxShortCycleTimer超时,会使用Long DRX cycle。

在下图中,UE在(0,1)盲检到PDCCH,于是启动drx-InactivityTimer。接着,在(0,4)时,drx-InactivityTimer超时,于是启动drxShortCycleTimer。在(1,4)时,drxShortCycleTimer超时,于是进入长周期,使用Long DRX cycle。
场景2


场景3

仍然使用场景2的DRX配置,如果在长DRX接收到PDCCH,会触发使用short DRX,如下图所示。由图可以看出,在(2,0)时UE接收到PDCCH,于是在(2,1)时启动drx-InactivityTimer。由于UE在接收到PDCCH时(即(2,0)子帧)处于长DRX,因此,在drx-InactivityTimer超时后(即(2,3)子帧),UE便启动drxShortCycleTimer,切换到短周期,使用short Cycle。
场景3


一些疑问与自答

  1. [6]这篇文章中,最后一张图第5步,收到DL grant后,并没停止drx-RetransmissionTimer,这是expected的吗?因为根据协议的说法1,如果收到DL grant的话,就应该停止drx-RetransmissionTimer
    在这里插入图片描述
  • if the PDCCH indicates a DL transmission or if a DL assignment has been configured for this subframe:
    • if the UE is an NB-IoT UE, a BL UE or a UE in enhanced coverage:
      • start the HARQ RTT Timer for the corresponding HARQ process in the subframe containing the last repetition of the corresponding PDSCH
        reception;
    • else:
      • start the HARQ RTT Timer for the corresponding HARQ process;
    • stop the drx-RetransmissionTimer or drx-RetransmissionTimerShortTTI for the corresponding HARQ process.

答案:这里应该是有误,根据协议,如果PDCCH指示了下行传输,就应该停止drx-RetransmissionTimer,因此,在上面第五步的时候drx-RetransmissionTimer就应该被停止了。

  1. 为什么在上图第5步也没有重启drx-InactivityTimer

答案:因为根据协议1,只有PDCCH指示新传的时候,才会重启drx-InactivityTimer

  • if the PDCCH indicates a new transmission (DL, UL or SL):
    • except for an NB-IoT UE configured with a single DL and UL HARQ process, start or restart drx-InactivityTimer.
  • if the PDCCH indicates a transmission (DL, UL) for an NB-IoT UE:
    • if the NB-IoT UE is configured with a single DL and UL HARQ process:
      • stop drx-InactivityTimer.
    • stop onDurationTimer.

参考文献

[1]. CDRX – LTE连接态下的DRX
[2]. DRX (Discontinuous Reception) - CDRX (Connected Mode DRX)
[3]. 3GPP 36.321
[4]. 3GPP 36.331
[5]. 深入理解LTE-A
[6]. Connected Mode DRX
[7]. LTE资源调度(7)-DRX不连续接收(1)


  1. 36321 5.7 Discontinuous Reception (DRX) ↩︎ ↩︎

  • 6
    点赞
  • 49
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值