为了给手机省电，，LTE 和NR 都做了些啥？--DRX前言一、why and how二、基本实现以及几个重要timer总结

71 阅读 0 评论 47 点赞

我是靠谱客的博主飞快金针菇，最近开发中收集的这篇文章主要介绍为了给手机省电，，LTE 和NR 都做了些啥？--DRX前言一、why and how二、基本实现以及几个重要timer总结，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

前言

DRX （Discontinuous Reception, 不连续接收)， 作为从LTE初期就引入的一项技术，主要目的就是降低终端功耗，提高其电池使用时间。NR中仍然
采用DRX, 实现框架基本与LTE 一致。C-DRX指的是处于RRC connection下终端的DRX处理流程。

一、why and how


现网中的数据包时常是突发性的，一段时间有，一段时间根本就没有数据传输。如果我们的终端一直去试着监听PDCCH, 那无疑对终端的功耗很不友好。
那么我们可能会想，没有数据的时候就让终端进入休眠模式呗。那么，当网络侧有数据发来的时候，终端还处于休眠模式，咋办？怎么既让终端能尽可能的
省电，又不错过网络侧发来的数据呢？
这就是DRX的由来：让终端一段时间处于休眠态，之后醒来去监听网络是否有数据来，没有数据的话，一段时间后再次进入休眠态。重复这个过程。听起来
很完美。那么会不会发生以下情景呢？网络发数据的时候，恰好终端处于休眠，然后终端醒了，网络又没有数据发送了。完美的错过！
为了避免这种worst case, 需要做到网络侧和终端的同步，网络侧的调度器，需要知道终端啥时候处于激活态，啥时候处于休眠期，以便只在激活态的时
侯去调度终端。 其实终端的这些DRX周期配置信息都是网络侧配给它的，所以网路侧自然可知。

二、基本实现以及几个重要timer

1.DRX cycle

下图中是一个基本的DRX cycle, on duration时候终端是醒着的，opportunity for DRX时候是休眠态。休眠态的终端，只是不再接收PDCCH, 但是可以接收其他物理信道的数据，比如，PDSCH和ACK/NACK.
在这里插入图片描述

2.几个重要的timer

下边是网络通过RRCconnectionReconfig来告诉某个终端的DRX 参数。也可以通过RRCconnectionSetup 信令。
一样的都有下边红色drx-config部分。
几个基本timer：
1)onDurationTimer: 从一个DRX cycle开始处算起，连续监听的PDCCH子帧数。
2) drx-InactivityTimer:是终端成功解码一个指示初传的上下行数据的PDCCH后，持续处于激活态的连续PDCCH子帧数。
3) drx-RetransmissionTimer: 从终端期待收到下行重传的子帧开始，连续监听的PDCCH子帧数。
4）longDRX-CycleStartoffset: 指定了longDRX-cycle和drxstartffset.
5) shortDRX-cycle :shortDRX cycle持续的子帧数。
6) drxShortCycleTimer 指定终端在多长时间内使用short DRX cycle。该值是short DRX cycle的倍数。
在这里插入图片描述

一些说明：
1）通常，终端采用的是Long DRX cycle. 但如果它当前已经被调度，则在一段时间内采用short DRX cycle.
2）通常，终端如果被调度且在一个子帧内处于激活态来进行数据的收或发，它很可能近期再被调度。原因之一是，它不
可能将传输缓冲器中的数据在一个子帧内传输完毕，需要更多子帧。所以终端在被调度之后的一段可配置时间内处于激活
态，即drxinactivityTimer的作用。

举个例子，参照下图。
1） C-DRX 相关参数已经配置给终端，最后一个DCI到达， SFN#0, sf#0.
2) drxInactivityTimer启动，持续3个子帧，之后到子帧5满足shortDrxCycle条件，就开始可短周期DRX. 周期是5个子帧，drxshortCycleTimer是3，
也就是3个短DRX周期。
3）在这三个短DRX周期内，都没有DCI来，所以从SFN#2, sf#0开始了长DRX周期。

在这里插入图片描述

	以下总结来自shareTechNote, 总结的很全。
if(drx-Config == setup) {
if((Short DRX Cycle
is configured/activated)
&& ( [(SFN * 10) + subframe number] mod (shortDRX_Cycle) == (drxStartOffset) mod (shortDRX_Cycle)) {
start onDurationTimer;
}
//短DRX周期激活，且满足SF开始条件，激活onDuration Timer.
if((Long DRX Cycle
is configured/activated)
&& ( [(SFN * 10) + subframe number] mod (longDRX_Cycle) == (drxStartOffset) ) {
start onDurationTimer;
} ///长DRX周期激活，且满足SF开始条件，激活onDuration Timer.
if( (a HARQ RTT Timer expires in this subframe)
&& (the data in the soft buffer of the corresponding HARQ process was not successfully decoded) {
start the drx-RetransmissionTimer for the corresponding HARQ process;
}// HARQ RTT timer是定义的一个时间窗，允许终端从前一次下行传输后，并持续这个timer超时后，才开始监听下行的重传。这是因为下行HARQ采用
异步方式，重传与之前传输之间并没有固定的时间关系。主要是为了允许终端在这个HARQ RTT 期间休眠。
if( DRX Command MAC control element is received ) {
stop onDurationTimer;
stop drx-InactivityTimer;
}// DRX commmand MAC CE收到后， 激活的这两种timer都会停止。我的理解，可能场景是网络侧知道下行没有额外的数据在等待传输，因此不需要
终端保持激活了，就强行把之前开始的激活timer终止了。强行省电！
if( (drx-InactivityTimer expires)
|| (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( during the Active Time, for a PDCCH-subframe,
if the subframe is not required for uplink transmission for halfduplex FDD UE operation and
if the subframe is not part of a configured measurement gap) {
monitor the PDCCH;
if (PDCCH indicates a DL transmission ||
DL assignment has been configured for this subframe ) {
start the HARQ RTT Timer for the corresponding HARQ process;
stop the drx-RetransmissionTimer for the corresponding HARQ process;
}
if (the PDCCH indicates a new transmission (DL or UL) ) {
start or restart drx-InactivityTimer;
}
}
if( not in the Active Time) {
CQI/PMI/RI on PUCCH and SRS shall not be reported;
}
}

总结

以上主要是RRC 连接态的DRX 处理过程。
关于RRC idle态的终端的DRX处理流程是不太一样的。paging支持DRX使RRC idle态的终端只在预先定义好的时间段内醒来接收paging消息，其他时间内
休眠，来降低功耗。网络侧同样需要知道某一终端的DRX cycle, PF(paging frame),PO(paging occasion)， 这样网络侧才能在对应的PO上给终端发送
pagingi消息。 处于RRC idle 态的终端在对应PO上醒来，去监听使用P-RNT加扰的PDCCH。如果检测到，终端会去读取paging消息中的被寻呼的终端标识，
如果跟自己的标识一致，则终端会将该标识发往上层处理。如果不一致，即被寻呼的不是自己，则终端会丢弃该paging消息，进入休眠。