非连续接收DRX

1. 非连续接收的由来
2. 分类
3. 原理
   3.1空闲状态下的DRX
   3.2连接状态下的DRX
4. DRX相关的timer启动和停止的触发条件
5. 调试所需的LOG包

1. 非连续接收的由来

非连续接收（DRX，Discontinuous Reception）基于包的数据流通常是突发性的，在一段时间内有数据传输，但在接下来的一段较长时间内没有数据传输。在没有数据传输的时候，可以通过停止接收PDCCH（此时会停止PDCCH盲检）来降低功耗，从而提升电池使用时间。

2. 分类

UE在一段时间里停止监听PDCCH信道，DRX分两种：

IDLE DRX，即当UE处于IDLE状态下的非连续性接收，由于处于IDLE状态时，已经没有RRC连接以及用户的专有资源，因此这个主要是监听呼叫信道与广播信道，只要定义好固定的周期，就可以达到非连续接收的目的。但是UE要监听用户数据信道，则必须从IDLE状态先进入连接状态。在Idle-DRX模式中，UE没有无线资源连接，主要完成对呼叫信道和广播信道监听，为了达到非连续接收，只需配置好固定睡眠周期。空闲模式下的DRX周期分为激活期和睡眠期。

另一种就是ACTIVE DRX，也就是UE处在RRC-CONNECTED 状态下的DRX， 可以优化系统资源配置，更重要的是可以节约手机功率，而不需要通过让手机进入到RRC_IDLE 模式来达到这个目的，例如一些非实时应用，像web浏览，即时通信等，总是存在一段时间，手机不需要不停的监听下行数据以及相关处理，那么DRX就可以应用到这样的情况，另外由于这个状态下依然存在RRC连接，因此UE要转到支持状态的速度非常快。在Connected-DRX模式中，UE有三种状态，分别处于活跃期，短DRX周期（浅睡眠期）和长DRX周期（深睡眠期）。在活跃期，UE处于功率消耗模；在浅、深睡眠期，UE处于功率节省模式。

3. 原理

IDLE 态和连接态下都有的paging DRX 和连接态下的DRX。前者是寻呼DRX，完全由NAS控制，控制UE监听P-RNTI加扰的PDCCH；后者是eNB控制，由RRC下发信令通知UE各种DRX参数的配置，同时MAC层也可以通过MAC CE控制DRX。

3.1空闲状态下的DRX

在RRC_ Idle状态下，UE在演进的分组系统（EPS）的移动性管理实体（MME）中注册，但并没有相应的活动，在这种状态下，UE只能因为有下行数据的到来被网络寻呼。UE也可以因有上行业务需要传送而向eNB发起RRC连接请求。

当UE在很长一段时间内没有都没有数据要传输或接收，eNB将释放UE的RRC连接并要求MME释放UE的S1连接，移除储存在MME和SGW中有关eNB部分的UE上下文。处于I D L E 模式下的UE，可以在其特定的寻呼周期内相应的寻呼帧（PF）上的寻呼时刻（PO） 去监听PDCCH周期性地监听PDCCH，如果从PDCCH 信道上解出了寻呼无线网络临时标识（P-RNTI），则根据PDCCH指示的RB分配和调制编码方式(MCS)，从同一子帧的PDSCH上获取寻呼消息。如果寻呼消息含有本UE的ID，则发起寻呼响应；否则，在下个寻呼周期里继续监听相应子帧的PDCCH。

在LTE中，每个小区在系统广播消息SIB2中的PCCH Config参数中定义了缺省的寻呼周期。除此之外，UE还可以通过上层信令通知EUTRAN 自己特定的寻呼周期，在这种情况下，UE使用两者中的最小值。寻呼帧PF对应一个LTE无线帧（10ms），寻呼时刻PO对应LTE一个无线帧中某个子帧（1ms），通过PF和PO，终端就知道在哪个PF的PO中监听寻呼消息。

在时域上，UE只会在其Paging周期内的某个特定帧（称为PF）的特定子帧（称为PO）去尝试接收Paging消息。
PO（Paging Occasion）是一个子帧，在该子帧上可能会有使用P-RNTI加扰，并指示Paging消息的PDCCH。当使用了DRX，UE在每个DRX cycle上只需要检测1个PO，也就是说，对应每个UE，在每个Paging周期内只有1个子帧可用于发送Paging。DRX cycle与Paging周期是同一概念。
PF（Paging Frame）是一个无线帧，该帧可能包含一个或多个PO。PF是满足如下公式的系统帧： SFN mod T= (T div N)*(UE_ID mod N)。
用索引i_s查表，可得到PO。其中i_s通过下面的公式得到： i_s = floor(UE_ID/N) mod Ns。

表3-1 FDD/TDD模式查询PO

表3-2 PF/PO公式的相关参数说明

举例子说明如何计算UE 的PF 和PO。
1）FDD 下，某个UE 的paging配置如下

计算如下：

从计算结果可以看出：
a) 该UE 需要每320 ms（T * 10ms）醒来一次，并尝试接收Paging 消息（即该UE 的DRX cycle 为32 个系统帧）。
b) 在该UE 的DRX cycle 内，每2 个系统帧（N=16）中会有一个PF 可用于Paging。(注: 上N =16表示在每个DRX cycle 内包含了16个PF，而T=32，故而每2 个系统帧会有一个PF 可用于Paging)。该UE对应的DRX cycle 内有16 个PO（nB = 16）。不同的UE 基于其不同的UE_ID，可以在这16 个PO 中选择1 个来接收Paging。
c) 每个PF 内只有1 个PO（Ns=1 ）。
d) 根据预先定义好的用于FDD 的样式，对于，i_s=0，PF 内的子帧9 用于PO。根据计算的参数查表可得子帧号。

图3-1：IMSI=404685505601234、、nB = 16 的UE

3.2连接状态下的DRX

在RRC-Connected状态下，UE可以通过两种方式来进入到DRX模式：
1）UE基于定时器的超时而进入到DRX状态。
2）网络侧通过MAC控制单元所携带的DRX Command 来通知UE进入到DRX模式。DRX机制使得每个UE都会分配到一个定期的清醒（ON）时间，在这段时间内UE监听网络，在其他时间内（OFF），UE关掉自己的接收器，进入节省功率模式。UE能够清醒的定时和网络传输定时同步，是由网络配置一系列的DRX定时器参数，通过RRC Connection Reconfiguration 或者RRC Connection Setup命令来通知UE的定时信息。这些定时器有些是周期性的，有些是非周期性的。非周期定时器的触发需要依赖特定的条件。

DRX的基本机制是为处于RRC_CONNECTED态的UE配置一个DRX cycle。DRX cycle由“On Duration”和“Opportunity for DRX”组成：在“On Duration”时间内，UE监听并接收PDCCH（激活期）；在“Opportunity for DRX”时间内，UE不接收PDCCH以减少功耗（休眠期）。在时域上，时间被划分成一个个连续的DRX Cycle。

图3-1 DRX cycle
注：处于休眠期的UE，只是不接收PDCCH，但是可以接收来自其它物理信道的数据，如PDSCH、ACK/NACK等。例如：在SPS调度中，处于休眠期的UE可以接收周期性配置的下行子帧上发送的PDSCH数据。
eNodeB通过DRX-Config来配置某个UE的DRX相关参数。



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子帧数”。

在大多数情况下，当一个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反馈之间的时间间隔。

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

当“drx-InactivityTimer”超时或收到DRX Command MAC control element时：（1）如果UE没有配置short DRX cycle，则直接使用long DRX cycle；（2）如果UE配置了short DRX cycle，UE会使用short DRX cycle并启动（或重启）“drxShortCycleTimer”，当“drxShortCycleTimer”超时，UE使用long DRX cycle。（对应上图中标红为(3)的部分） 如果UE当前使用short DRX cycle，且[(SFN * 10) + subframe number] modulo (shortDRX - Cycle) = (drxStartOffset) modulo (shortDRX-Cycle)；或者UE当前使用long DRX cycle，且[(SFN * 10) + subframe number] modulo (longDRX-Cycle) = drxStartOffset，则启动“onDurationTimer”。（对应上图中标红为(1)的部分）

注：drxShortCycleTimer启动后，只说明当前使用short DRX cycle，但此时未必启动了DRX short cycle。DRX short cycle是与onDurationTimer同时启动的。类似的，long DRX cycle也是与onDurationTimer同时启动的。

当UE配置了DRX cycle时，UE处于激活期的时间包括：• onDurationTimer、或InactivityTimer、或drx-RetransmissionTimer、或mac-ContentionResolutionTimer正在运行时；
UE已经在PUCCH上发送了SR，且该SR当前处于pending态；
UE的HARQ buffer存在数据，并等待HARQ重传的UL grant时；
UE成功接收了用于响应非UE选择的preamble的RAR，却没有收到指示初传（使用C-RNTI）的PDCCH时。
DRX是UE级别的特性，而不是基于每个无线承载来配置的。
当UE配置了DRX时， UE只能在“激活期”的时间内发送周期性CQI。eNodeB在使用RRC来配置周期性CQI上报时，可以进一步地限制UE只能在“on-duration”的时间内发送CQI。

4. DRX相关的timer启动和停止的触发条件

表4-1 DRX相关的timer启动和停止的触发条件

注：longDRX-Cycle和shortDRX-Cycle指定的是连续的“子帧数”。
除了HARQ RTT timer和drx-RetransmissionTimer是每个DL HARQ process都有一个外，其它的timer是每个UE只有一个。
当任一timer启动时，不会影响其它timer的运行。也即，UE处于激活态的最短时间为onDurationTimer指定的时间，而最长时间是不定的。
需要说明的是，对于eNodeB的调度器而言，需要知道UE何时处于激活期，何时处于休眠期，以便只在激活期调度该UE。

5. 调试所需的LOG包

0xB0C0 LTE RRC OTA Packet-DL_DCCH(MAC DRx config)
0xB130 LTE LL1 PDCCH Decoding Result(Inactivity Timer start/stop)
0xB198 LTE ML1 CDRx Events Info
0xB16C LTE DCI Information Report
0xB173 LTE PDSCH Stat Indication

注：经过所抓log测试，在移动卡下可见0xB198 LTE ML1 CDRx Events Info包，而联通和电信卡下则不可见。

移动卡：

参考文献：

[1] 温金辉《深入理解LTE-A》其中第十六章有DRX的相关描述。