为什么要使用DRX
无论是空闲态,还是连接态,如果没有我们本文提到的DRX机制,UE就会一直监听下行PDCCH子帧,查看是否有来自服务小区的信息。这样做看起来没有问题,然而现实很多时候,UE并不是一直在和网络进行有效信息的交互,不会总是执行上传或者下载业务,通话时也不会一直有语音数据的传输。大多数的时间,UE和网络是没有数据交互的,如果这个时候UE还去持续的监听PDCCH子帧,显然是很费电的。因而,在保证数据能有效传输的前提下,有必要设计一种节省UE电量的机制,这个机制我们就叫做DRX。
什么是DRX
DRX,英文全称为Discontinuous Reception,即不连续接收,这种方法可以让UE周期性的在某些时候进入睡眠状态(sleep mode),不去监听PDCCH子帧,而需要监听的时候,则从睡眠状态中唤醒(wake up),这样就可以使UE达到省电的目的。
这样做对数据传输的时延有一定的影响,但如果这种时延并不影响用户体验,那么考虑到UE更为重要的功率消耗,执行DRX是很有意义的。
RRC通过DRX-config配置某个UE配置的DRX相关参数。
DRX的分类
- 空闲态的DRX
空闲态下的DRX机制即寻呼机制
- 连接态的DRX
一个典型的DRX周期下图所示。
在这个图中,标识“On Duration”的这段时间是UE监控下行PDCCH子帧的时间,在这段时间里,UE是处于唤醒状态的。
标识“Opportunity for DRX”的这段时间是DRX睡眠时间,即UE为了省电,进入了睡眠而不监控PDCCH子帧的时间。(睡眠期的UE只是不接收PDCCH,但可以接收来自其他物理信道的数据)
从这个图中可以看到,用于DRX睡眠的时间越长,UE的功率消耗就越低,但相应的,业务传输的时延也会跟着增加。因此,DRX Cycle的选择需要考虑节电与时延的平衡。
以下是连接态下的DRX
DRX-InactivityTimer
我们来考虑这样的一个场景:0号子帧是唤醒时间On_Duration的最后一个子帧,此时网侧刚好有一个较大字节的数据需要发给UE,这些数据无法在0号子帧全部发送完。如果按照上文图1的DRX周期,那么UE将在1号子帧进入DRX睡眠状态,不会再去接收来自网侧的任何下行PDSCH数据。网侧也只能等到DRX周期结束,并在下一个On_Duration时刻到来时,继续向UE发送没有传完的数据。这种处理机制虽然没有错,但显然增加了整个业务的处理时延。为了避免这种情况的出现,DRX机制中增加了drx-Inactivity定时器,如下图所示。
如果DRX-inactivityTimer正在运行,那么即便原本配置的On_Duration时间已经结束,UE仍然需要继续监听下行PDCCH子帧,直到DRX InactivityTimer超时。增加了DRX-InactivityTimer机制之后,显然会减少数据的处理时延。
长周期和短周期
前文图1已经提到,一个DRX周期等于UE唤醒时间(ON-duration)和睡眠时间的总和。
在LTE里,系统可以根据不同的业务场景,给UE分别配置短周期(short DRX cycle)或者长周期(long DRX cycle)。比如在进行VOIP业务时,语音编解码器通常20ms发送一个VOIP包,那么就可以配置长度为20ms的DRX短周期,而在语音通话期间较长的静默期,就可以配置DRX长周期。
如果同时配置了短周期和长周期,且drxShortCycleTimer定时器超时,那么UE将进入一次长DRX周期,如下图5所示。图中,drx-InactivityTimer定时器超时后开启drxShortCycleTimer定时器。
Item | 作用 | Start | End |
onDurationTimer | 表示在一个DRX周期里,UE睡醒后的在线时长。以PDCCH子帧个数为基本单位, | shortDRX-Cycle:条件1见下 longDRX-Cycle:条件2见下 | (1)收到DRX MAC control element停止; (2)超时停止; |
DRX-InactivityTimer | 表示当UE成功解码到一个下行PDCCH之后,还需要继续监测多少个PDCCH子帧。同样以PDCCH子帧个数为基本单位, | 当PDCCH子帧中显示有新的上行或下行传输时启动 | (1)收到DRX MAC control element停止; (2)超时停止; |
DRX-RetransmissionTimer | 这个参数用在下行重传的场景。由于下行HARQ采用的是异步重传,因此UE并不确定eNB什么时候会下发重传数据,但UE也不可能无限制的等待下去,毕竟UE还需要省电,还需要进入睡眠状态,所以这个重传定时器是表示UE为了接收期望的下行重传数据,需要连续监测的最大PDCCH子帧个数。同样以PDCCH子帧个数为基本单位, | 当HARQ RTT定时器超时且下行HARQ缓存里还有数据没有被解码成功时启动 | (1)当收到PDCCH子帧显示该进程有数据传输; (2)当前属于DL-SPS子帧; (3)超时; |
shortDRX-Cycle | 表示DRX采用的短周期时长,以子帧为单位, | NA | NA |
DRXShortCycleTimer | 表示在短周期内持续多少个短周期没有收到PDCCH就进入长周期。如果值为2,则表示持续(2×shortDRX-Cycle)个子帧没有成功解码到PDCCH就进入长周期。 | DRX-InactivityTimer超时 | 超时,此时使用longDRX-Cycle |
DRX-StartOffset | DRX周期起始的子帧号 | NA | NA |
条件1:
[(SFN *10) + subframeNumber] modulo (shortDRX-Cycle) = (DRXStartOffset) modulo (shortDRX-Cycle)
条件2:
[(SFN * 10) + subframeNumber] modulo (longDRX-Cycle) = DRXStartOffset
SFN(System Frame Number)
DRX流程总结
原文:https://blog.csdn.net/m_052148/article/details/52439789
https://wenku.baidu.com/view/ce832a3f492fb4daa58da0116c175f0e7cd119a4.html
以下是空闲态下的DRX
寻呼流程
寻呼的DRX