背景技术
在基于共享信道的移动通信***中,例如LTE(Long Term Evolution,长期演进)中,上下行数据的传输由eNB(evolved Node-B,基站)调度器负责控制,当调度器确定调度某用户时,将通过控制信道通知终端在何种资源上发送或接收数据。UE(User Equipment,终端)监听控制信道,当检测到包含自己的调度信息时,根据控制信道上的指示完成数据的发送(上行)或接收(下行)。在激活状态下,由于终端不确定eNB何时对其进行调度,因此一种常见的工作模式为,终端连续监听控制信道,对每个包含其下行调度控制信道的子帧都进行解析,以判断是否被调度。这种工作方式在终端数据量较大,可能被频繁调度的情况下能获得较高的效率。然而对某些业务而言,数据的到达频率较低,导致终端被调度的次数也较小,如果终端仍然连续监听控制信道,无疑会增加其耗电量。为了解决耗电问题,LTE***采用了DRX(Discontinuous Reception,非连续接收)工作模式,在这种工作模式下,终端周期性的对控制信道进行监听,从而达到节电的目的。
DRX的基本原理如图1所示,其中On duration表示UE监听控制信道的时间段,其间射频通道打开,并连续监听控制信道;除去On duration之外的其它时间,UE处于Sleep(睡眠)状态,其射频链路将被关闭,不再监听控制信道,以达到省电的目的。On Duration都是周期性出现(Cycle),具体周期由eNB配置实现。
LTE的DRX机制考虑了数据业务的到达模型,即数据分组的到达是突发的(可以理解为,一旦有数据分组到达,那么会在较短时间内连续到达较多的分组)。为了适应这种业务到达特点,LTE DRX过程采用了多种定时器,并与HARQ(Hybrid-ARQ,混合自动重传请求)过程相结合,以期到达更好的节电性能。
LTE DRX过程采用的定时器包括:
On duration timer:UE周期性醒来在On duration时间内连续监听控制信道,如图1所示。
Short DRX cycle Timer:为了更好的配合数据业务到达的特点,LTE***允许配置两种DRX cycle:long cycle和short cycle。两种cycle的on duration timer相同,但sleep的时间不一样。在short cycle中,sleep时间相对更短,UE可以更快地再次监听控制信道。Long cycle时必须配置的,并且是DRX过程的默认状态;short cycle是可选的。short DRX cycle timer设置了采用short cycle持续的时间。Short cycle timer超时后,UE将使用Long cycle。
drx-Inactivity timer:配置了DRX后,当UE在允许监听控制信道的时间内(Active Time)收到HARQ初始传输的控制信令时打开该定时器,在该定时器超时之前,UE连续监听控制信道。如果在drx-Inactivity timer超时前,UE收到HARQ初始传输的控制信令,将终止并重新启动drx-Inactivity timer。
HARQ RTT(Round-Trip Time,往返时延)timer:仅适用于DL(Downlink,下行),使UE有可能在下次重传到来前不监听控制信道,达到更好的节电效果。UE如果收到了HARQ传输(初始传输或重传)的控制信令,将打开此定时器。如果对应HARQ进程中的数据在前一次HARQ传输后解码不成功(UE反馈NACK),在HARQ RTT timer超时后,UE打开drx-Retransmission timer。如果对应HARQ进程中的数据在前一次HARQ传输后解码成功(UE反馈ACK),在HARQ RTT timer定时器超时后,UE不启动drx-Retransmission timer。如果当前只有HARQ RTT timer运行,UE不监听控制信道。
drx-Retransmission timer:仅适用于DL。在drx-Retransmission timer其间,UE监听控制信令,等待对应HARQ进程的重传调度。一旦接收到针对重传的调度,则停止该定时器。
图2给出了上述定时器的工作过程和相互关系。在on duration其间的t1时刻,eNB调度了针对process 1的初始传输,于是UE打开drx-Inactivity timer和对应的HARQ RTT timer1。由于Process 1的初始传输解码不成功,HARQ RTTtimer超时后,UE打开了drx-Retransmission timer1。
t2时刻,eNB调度了针对Process 2的初始传输,drx-Inactivity timer被重新启动,同时打开针对Process 2的HARQ RTT timer2。
在drx-Retransmission timer1超时前的t3时刻,UE收到了针对Process 1的重传,于是终止drx-Retransmission timer1,并打开HARQ RTT timer1。
HARQ RTT timer2超时后,由于Process 2的初始传输没有解码成功,于是UE打开drx-Retransmission timer2。在drx-Retransmission timer2超时前的t4时刻,eNB调度了Process 2的重传,于是UE终止drx-Retransmission timer2,打开HARQ RTT timer2。
在drx-Retransmission timer1超时之前的t5时刻,eNB继续调度了Process 1的重传,于是drx-Retransmission timer1被终止,同时启动HARQ RTT timer1。在HARQ RTT timer2超时之前,UE对Process 2中的数据解码成功,于是向eNB反馈ACK,同时在HARQ RTT timer2超时后,也不再启动drx-Retransmissiontimer2。同样,在HARQ RTT timer1超时之前,UE对Process 1中的数据解码成功,于是向eNB反馈ACK,在HARQ RTT timer1超时后,也不再启动drx-Retransmission timer1。
通过上述过程可以看出,在On duration Timer、drx-Retransmission timer和drx-Inactivity timer中,有任何一个定时器正在运行,UE都将监听控制信道。UE监听控制信道的时间又称为Active Time。UE的行为由定时器的相互作用决定。
LTE及以前的无线通信***中,通常每个小区中只有一个(或一对)载波,UE同一时刻只能在一个小区中(载波上)进行数据收发。在LTE***中载波的最大带宽为20MHz,如图3所示。在LTE Advanced(LTE-A)***中,***的峰值速率比LTE有很大的提高,要求达到下行1Gbps,上行500Mbps,20MHz的传输带宽已经无法满足这种需求。为了提供更高的传输速率,LTE-A***采用了载波聚合技术,即UE能够同时聚合多个成员载波并在这些载波上同时进行数据传输,从而提高数据传输速率。为了保证LTE的UE能在每一个聚合的载波下工作,每一个载波最大不超过20MHz。LTE-A中CA技术如图4所示。在图4所示的LTE-A***中,UE可聚合的载波个数为4个,网络侧可以同时在4个载波上和UE进行数据传输。
在多载波***中基站可以根据UE请求的所有业务的最大速率之和为UE配置一个CC(工作载波)集合。在给UE配置的CC集合中,***会基于UE选择一个CC作为该UE的PCC(Primary Component Carrier,主载波),配置载波集合中的其它CC则称为SCC(Secondary Component Carrier,辅载波)。需要注意:不同UE的PCC可能不同。
在LTE-A***中,为了节电同样定义了DRX,目前LTE-A中关于DRX的定义如下:UE对所有配置载波使用相同的DRX操作,比如相同的active time(激活时间)。该定义只是说明了各个DL CC上的active time相同,并未定义DRX timer如何操作的细节。基于上述定义关于DRX有如下两种理解:
DRX机制理解1如图5所示:
配置CC集合为一个整体,即可以看成一个CC,DRX timer按照如下方式配置与维护:
On duration timer:针对UE配置,配置CC集合内所有CC的on duration时刻一致。
Short DRX cycle Timer:针对UE配置,配置CC集合内所有CC一致。Shortcycle timer超时后,UE将使用Long cycle。
drx-Inactivity timer:针对UE配置,UE在active time内激活CC集合内的任何一个CC上收到HARQ初始传输的控制信令即启动该定时器,在该定时器超时之前,UE连续监听所有激活CC上的控制信道。如果在drx-Inactivity timer超时前,UE在激活CC集合内的任何一个CC上收到HARQ初始传输的控制信令,将重新启动drx-Inactivity timer。
HARQ RTT timer:针对进程配置,仅适用于DL,UE如果在激活的CC集合内的任何一个CC上收到了HARQ传输(初始传输或重传)的调度信令,将启动该定时器。如果对应HARQ进程中的数据在前一次HARQ传输后解码不成功(UE反馈NACK),在HARQ RTT timer超时后,UE将打开drx-Retransmissiontimer。如果对应HARQ进程中的数据在前一次HARQ传输后解码成功(UE反馈ACK),在HARQ RTT timer定时器超时后,UE不启动drx-Retransmissiontimer。如果当前只有HARQ RTT timer运行,UE不监听控制信道。
drx-Retransmission timer:针对进程配置,仅适用于DL。在drx-Retransmission timer其间,UE监听控制信令,等待对应HARQ进程的重传调度。一旦接收到针对该进程重传的调度,则停止该定时器。虽然drx-Retransmission timer是针对一个进程控制的,但只要任何一个CC上的drx-Retransmission timer运行,UE都将在所有激活的CC上监听PDCCH。
基于上述理解,根据LTE规范,UE的active time包含如下时间:
On Duration Timer或者drx-Inactivity timer或者drx-Retransmission timer或者mac-contentionResolutionTimer运行的时间;
在PCC的PUCCH(Physical Uplink Control Channel,物理上行控制信道)上发送SR(scheduling request,调度请求)后等待UL(Up Link,上行)调度的时间;
配置集合内任何一个DL CC上有可能有针对对应UL CC上的上行重传调度信令的时刻;
对于非竞争随机接入,UE接收到RAR(random access response,随机接入响应)到等待接收针对该UE C-RNTI的新传输的调度信令的时间;
DRX机制理解2如图6所示:
至少drx-Inactivity timer、HARQ RTT timer和drx-Retransmission timer三个DRX相关定时器基于CC维护,只要任何一个CC处于active time,则其它CC也处于active time。timer按照如下操作:
On duration timer:针对UE配置,所有CC一致。
Short DRX cycle Timer:针对UE配置,所有CC一致。Short cycle timer超时后,UE将在使用Long cycle。
drx-Inactivity timer:针对CC配置,UE在active time内在对应的CC上收到HARQ初始传输的控制信令即启动该定时器,在该定时器超时之前,UE连续监听对应CC上的控制信道。如果在drx-Inactivity timer超时前,UE在对应CC上收到HARQ初始传输的控制信令,则在该CC以及调度它的DL CC上将终止并重新启动drx-Inactivity timer。虽然drx-Inactivity timer是针对CC维护的,但只要任何一个CC上的drx-Inactivity timer运行,UE都将在所有激活的CC上监听PDCCH。
HARQ RTT timer:针对进程配置,仅适用于DL,UE如果在对应CC上收到了HARQ传输(初始传输或重传)的控制信令,将启动该定时器。如果对应HARQ进程中的数据在前一次HARQ传输后解码不成功(UE反馈NACK),在HARQ RTT timer超时后,UE打开drx-Retransmission timer。如果对应HARQ进程中的数据在前一次HARQ传输后解码成功(UE反馈ACK),在HARQ RTTtimer定时器超时后,UE不启动drx-Retransmission timer。如果当前只有HARQRTT timer运行,UE不监听控制信道。
drx-Retransmission timer:针对进程配置,仅适用于DL。在drx-Retransmission timer其间,UE监听控制信令,等待对应HARQ进程的重传调度。一旦接收到针对该进程重传的调度,则停止该定时器。虽然drx-Retransmission timer是针对一个进程控制的,但只要任何一个CC上的drx-Retransmission timer运行,UE都将在所有激活的CC上监听PDCCH。
在该理解下UE的active time包含如下时间:
On Duration Timer或者任何一个CC上有drx-Inactivity timer或者drx-Retransmission timer或者mac-contentionResolutionTimer运行的时间;
在PCC的PUCCH上发送SR(scheduling request,调度请求)后等待UL调度的时间;
配置集合内任何一个DL CC上有可能有针对对应UL CC上的上行重传调度信令的时刻;
对于非竞争随机接入,UE接收到RAR(random access response,随机接入响应)到等待接收针对该UE C-RNTI的新传输的调度信令的时间。
由于UE的业务具有波动性和突发性,即某段时间内业务量很少,而某段时间内业务量很大,因此在UE业务量比较少的时候,为了更好的节电,可以进一步对配置CC集合内的CC按照UE当前的业务情况进行载波激活/去激活操作,对于去激活的载波,UE不需要再监听PDCCH,这样就可以达到更好的节电效果。
LTE-A***规定UE的PCC不允许激活/去激活,一直默认是激活的,而配置CC集合中的SCC默认是去激活的,如果需要使用这些SCC,需要首先进行载波激活操作。目前协议已经规定对多载波***中的载波激活/去激活操作可以采用显式方式,即使用载波激活/去激活MAC CE(MAC control element,媒体接入控制层控制单元)。除了显式方式外,协议还支持隐式去激活机制,但是目前对于隐式去激活方式尚在讨论之中,没有明确结论。
具体实施方式
本发明实施例中利用DRX相关的timer进行隐式载波去激活的方案可以分为两种,一种是基于UE进行隐式去激活,一种是基于CC进行隐式去激活。前一种方式只能对UE所有的DL SCC去激活,后一种方式则可以针对不同DL SCC分别进行去激活。
同时,基于DRX机制的不同理解,本发明实施例中的利用DRX相关的timer进行隐式载波去激活的方案也不相同,下面分别就DRX机制理解1和2的情况对本发明实施例中的隐式载波去激活方案进行介绍。
本发明实施例一提供一种隐式载波去激活的方法,该方法应用于DRX机制理解1的情况,如图7所示,包括:
步骤701,UE获取配置的drx-Inactivity timer/HARQ RTTtimer/drx-Retransmission timer的状态;当drx-Inactivity timer/HARQ RTTtimer/drx-Retransmission timer的状态都处于超时或者未启动状态时,执行步骤702。
具体的,本步骤中确定UE配置的drx-Inactivity timer/HARQ RTTtimer/drx-Retransmission timer状态时要考虑UE的所有DL CC。
步骤702,UE判断所有DL SCC可以调度的UL CC上是否有上行进程数据挂起;如果没有执行步骤703。
步骤703,UE去激活所有DL SCC。
需要说明的是,当用户终端在任一DL CC上接收到针对初始传输的调度信令,则启动该用户终端对应的drx-Inactivity timer。
本实施例中,drx-Inactivity timer/HARQ RTT timer/drx-Retransmission timer的长度可以根据实际需要灵活设置。
下面举例说明上述方法,设为UE配置了三个CC,分别标记为CC1、CC2和CC3,其中CC1为PCC,CC2和CC3为SCC,隐式去激活方法如图8所示,包括:
T1:UE在CC1上接收到针对CC1下行的调度信令以及对应的下行进程1的数据传输,此时UE应该启动drx-Inactivity timer和针对CC1上进程1的HARQ RTT timer11;
T2:因为CC1上进程1的下行数据中包含激活CC2和CC3的载波激活MAC CE,因此当UE解析出该数据包后应该激活CC2和CC3,因为此时UE的drx-Inactivity timer处于启动状态,因此CC2和CC3也应该处于激活状态;
T3:UE接收到针对CC2上进程1的初始传输的调度,此时UE应该重启drx-Inactivity timer并针对CC2上进程1启动HARQ RTT timer21;
T4:UE接收到针对CC3上进程1的初始传输的调度,此时UE应该重启drx-Inactivity time并针对CC3上进程1启动HARQ RTT timer31;
T5:UE在CC2的进程1的drx-Retransmission timer21运行期间接收到针对CC2上进程1的重传的调度信令,则此时UE应该启动针对CC2上该进程的HARQ RTT timer21;
T6:UE在CC3上的进程1传输成功;
T7:UE在CC2上的进程1传输成功;
T8:在T8时刻UE的drx-Inactivity timer和针对该UE任何CC上的任何进程的HARQ RTT timer以及drx-Retransmission timer都处于未启动状态,如果此时该UE在SCC可以调度的UL CC上也没有挂起的上行传输,则说明UE配置的所有SCC上没有数据和控制信息的传输需求,应该此时隐式去激活为该UE配置的所有SCC,即CC2和CC3。
本发明实施例二提供一种隐式载波去激活的方法,该方法应用于DRX机制理解1的情况,如图9所示,包括:
步骤901,UE获取配置的drx-Inactivity timer的状态,若drx-Inactivity timer处于超时或者未启动状态,则执行步骤902。
本实施例中,需要配置drx-Inactivity timer足够长,保证所有DL SCC以及所有DL SCC可以调度的UL CC上的所有初传和重传完成时drx-Inactivitytimer仍未超时。
步骤902,UE去激活所有DL SCC。
需要说明的是,当用户终端在任一DL CC上接收到针对初始传输的调度信令,则启动该用户终端对应的drx-Inactivity timer。
下面举例说明上述方法,设为UE配置了三个CC,分别标记为CC1、CC2和CC3,其中CC1为PCC,CC2和CC3为SCC,则隐式去激活方法如图10所示,其中,T1-T7操作与实施例一图8中相同,在此不再赘述,不同之处,在于T8时刻,即只有当drx-Inactivity Timer超时时,UE才会去激活所有SCC,即去激活CC2和CC3。
本发明实施例三提供一种隐式载波去激活的方法,该方法应用于DRX机制理解2的情况,如图11所示,包括:
步骤1101,UE获取为任一DL SCC配置的drx-Inactivity timer/HARQ RTTtimer/drx-Retransmission timer的状态;当为任一DL SCC配置的drx-Inactivitytimer/HARQ RTT timer/drx-Retransmission timer的状态都处于超时或者未启动状态时,执行步骤1102。
具体的,本步骤中UE为每一DL SCC分别配置对应的drx-Inactivitytimer/HARQ RTT timer/drx-Retransmission timer,UE分别获取每一DL SCC对应的DRX相关timer的状态。
步骤1102,UE判断该DL SCC可以调度的UL CC上及其可以调度的UL/DL CC上是否有进程数据挂起,如果没有执行步骤1103。
步骤1103,UE去激活该SCC。
需要说明的是,本实施例中UE接收到针对任一DL SCC的初始传输的调度信令或者该任一DL SCC上接收到针对其可以调度的UL/DL CC上的初始传输的调度信令时,启动该任一DL SCC对应的drx-Inactivity timer。
下面举例说明上述方法,设为UE配置了三个CC,分别标记为CC1、CC2和CC3,其中CC1为PCC,CC2和CC3为SCC,则隐式去激活方法如图12所示,包括
T1:UE在CC1上接收到针对CC1下行的调度信令以及对应的下行进程1的数据传输,此时UE应该启动针对CC1上进程1的drx-Inactivity timer1和HARQ RTT timer11;
T2:因为CC1上进程1的下行数据中包含激活CC2和CC3的载波激活MAC CE,因此当UE解析出该数据包后应该激活CC2和CC3,因为UE在CC2和CC3上应该分别启动针对CC2和CC3的drx-Inactivity timer2和drx-Inactivity timer3;
T3:UE接收到针对CC2上进程1的初始传输的调度,此时UE应该重启CC2上的drx-Inactivity timer2并针对CC2上进程1启动HARQ RTT timer21;
T4:UE接收到针对CC3上进程1的初始传输的调度,此时UE应该重启CC3上的drx-Inactivity time3并针对CC3上进程1启动HARQ RTT timer31;
T5:UE在CC3上的进程1传输成功;
T6:在T6时刻UE在CC3上的drx-Inactivity timer3和针对该CC任何进程的HARQ RTT timer以及drx-Retransmission timer都处于未启动状态,如果此时在CC3可以调度的UL CC上也没有挂起的上行传输,则应该隐式去激活CC3。
T7:UE在CC2的进程1的drx-Retransmission timer21运行期间接收到针对CC2上进程1的重传的调度信令,则此时UE在CC2上应该启动针对该进程的HARQ RTT timer21;
T8:在CC2上HARQ RTT timer21未超时之前,UE成功接收CC3上的进程1;
T9:在T9时刻UE在CC2上的drx-Inactivity timer2和针对该CC任何进程的HARQ RTT timer以及drx-Retransmission timer都处于未启动状态,如果此时在CC2可以调度的UL CC上也没有挂起的上行传输,则隐式去激活CC2。
本发明实施例四提供一种隐式载波去激活的方法,该方法应用于DRX机制理解2的情况,如图13所示,包括:
步骤1301,UE获取为任一DL SCC配置的drx-Inactivity timer的状态;当为任一DL SCC配置的drx-Inactivity timer的状态处于超时或者未启动状态时,执行步骤1302。
具体的,本步骤中UE为每一DL SCC分别配置的drx-Inactivity timer足够长,能够保证该DL CC自身及其可以调度的所有UL/DL CC上的所有初传和重传完成时drx-Inactivity timer仍未超时。
步骤1302,UE去激活该SCC。
需要说明的是,该方法下UE接收到针对任一DL SCC的初始传输的调度信令或者该任一DL SCC上接收到针对其可以调度的UL/DL CC上的初始传输的调度信令时,启动该任一DL SCC对应的drx-Inactivity timer。
下面举例说明上述方法,设为UE配置了三个CC,分别标记为CC1、CC2和CC3,其中CC1为PCC,CC2和CC3为SCC,则隐式去激活方法如图14所示,其中,T1-T5与实施例三中图12所示相同,区别在于:
T6:UE在CC2的进程1的drx-Retransmission timer21运行期间接收到针对CC2上进程1的重传的调度信令,则此时UE在CC2上应该启动针对该进程的HARQ RTT timer21;
T7:在CC2上HARQ RTT timer21未超时之前,UE成功接收CC3上的进程1;
T8:在T8时刻UE在CC2上的drx-Inactivity timer2超时,则应该隐式去激活CC2。
T9:在T9时刻UE在CC3上的drx-Inactivity timer2超时,则应该隐式去激活CC3。
对于没有配置DRX的UE,如果要进行隐式载波激活/去激活也可以考虑引入drx-Inactivity timer,该drx-Inactivity timer使用RRC信令配置。这种情况下可以采用与上述实施例相同的.timer维护方式,同样可以实现基于timer的隐式载波去激活机制。只是需要注意,在UE没有配置DRX的情况下,如果引入drx-Inactivity timer,则drx-Inactivity timer要设置的足够长,以保证UE在DL SCC或者UL CC上进行重传的时候,对应的DL SCC不能被去激活。下面给出两个相关实施例。
本发明实施例五提供一种利用DRX相关timer基于UE进行隐式去激活的方法,应用于UE没有配置DRX的情况,如图15所示,设为UE配置了三个DL CC,分别标记为CC1、CC2和CC3,其中CC1为DL PCC,CC2和CC3为DL SCC,UE为CC1、CC2和CC3配置共同的drx-Inactivity timer,则利用DRX相关timer基于UE进行隐式去激活的方法包括:
T1:UE在CC1上接收到针对CC1下行的调度信令以及对应的下行进程1的数据传输,CC1的下行进程1传输的数据块中包含载波激活MAC CE,该MAC CE可以激活载波CC2和CC3;
T2:因为CC1上进程1的下行数据中包含激活CC2和CC3的载波激活MAC CE,因此当UE解析出该数据包后应该激活CC2和CC3,此时UE启动drx-Inactivity timer;
T3:UE接收到针对CC2上进程1的初始传输的调度,此时UE应该重启drx-Inactivity timer;
T4:UE接收到针对CC3上进程1的初始传输的调度,此时UE应该重启drx-Inactivity timer;
T5:在UE的drx-Inactivity timer未超时之前,CC3上进程1的初始传输成功;
T6:UE在T6时刻收到针对CC2上进程1重传的调度信令,则重启drx-Inactivity timer;
T7:在UE的drx-Inactivity timer未超时之前,UE在CC2上的进程1传输成功;
T8:在T8时刻UE的在UE的drx-Inactivity timer超时且此时所有DL SCC可以调度的UL CC上没有进程挂起,因此UE在T8时刻可以隐式去激活所有激活的DL SCC,即CC2和CC3。
本发明实施例六提供一种隐式载波去激活的方法,应用于UE没有配置DRX的情况,如图16所示,设为UE配置了三个DL CC,分别标记为CC1、CC2和CC3,其中CC1为DL PCC,CC2和CC3为DL SCC,UE为CC1、CC2和CC3分别配置对应的drx-Inactivity timer,则利用DRX相关timer基于UE进行隐式去激活的方法包括:
T1:UE在CC1上接收到针对CC1下行的调度信令以及对应的下行进程1的数据传输,CC1的下行进程1传输的数据块中包含载波激活MAC CE,该MAC CE可以激活载波CC2和CC3;
T2:因为CC1上进程1的下行数据中包含激活CC2和CC3的载波激活MAC CE,因此当UE解析出该数据包后应该激活CC2和CC3,此时UE针对DL CC2和CC3分别启动其对应的去激活定时器drx-Inactivity timer2和drx-Inactivity timer3;
T3:UE在T3时刻接收到针对CC2上进程1的初始传输的调度,此时UE应该重启CC2对应的去激活定时器drx-Inactivity timer2;
T4:UE在T4时刻接收到针对CC3上进程1的初始传输的调度,此时UE应该重启CC3对应的去激活定时器drx-Inactivity timer3;
T5:在CC3的drx-Inactivity timer3未超时之前,CC3上进程1的初始传输成功;
T6:UE在T6时刻收到针对CC2上进程1重传的调度信令,则UE应该重启CC2对应的去激活定时器drx-Inactivity timer2;
T7:在CC2的drx-Inactivity timer2未超时之前,UE在CC2上的进程1传输成功;
T8:在T8时刻UE的在CC3上的drx-Inactivity timer3超时且此时该DLSCC可以调度的UL CC上没有进程挂起,因此CC3可以在T8时刻被隐式去激活;
T9:在T9时刻UE的在CC2上的drx-Inactivity timer2超时且此时该DLSCC可以调度的UL CC上没有进程挂起,因此CC2可以在T9时刻被隐式去激活。
本发明实施例七提供一种用户终端,如图17所示,包括:
获知单元10,用于获知配置的下行辅载波DL SCC上的数据和控制信息的传输状态;
去激活单元20,用于当所述获知单元10获知所述DL SCC上没有数据和控制信息的传输需要时,去激活所述DL SCC。
如图18所示,所述获知单元10包括:
获取子单元11,用于获取所述DL SCC对应的去激活定时器的状态;
确定子单元12,用于所述获取子单元11获取到所述去激活定时器超时或者未启动时,确定所述DL SCC上没有数据和控制信息的传输需求。
如图19所示,所述获知单元10还可以包括:
获取子单元11,用于获取所述DL SCC对应的去激活定时器的状态;
判断子单元12,用于判断所述DL SCC调度的UL CC上是否有进程数据挂起;
确定子单元13,用于所述获取子单元11获取到所述去激活定时器超时或者未启动、且所述判断子单元12的判断结果为否时,确定所述DL SCC上没有数据和控制信息的传输需求。
其中,所述去激活定时器包括drx-Inactivity timer。
所述去激活定时器还可以包括drx-Inactivity timer、HARQ RTT timer和drx-Retransmission timer。
所述确定子单元13还用于:
当与所述用户终端的所有DL SCC对应的去激活定时器超时或者未启动时,确定所述所有DL SCC上没有数据和控制信息的传输需求。
所述确定子单元13还用于:
当与所述用户终端的任一DL SCC对应的去激活定时器超时或者未启动时,确定所述任一DL SCC上没有数据和控制信息的传输需求。
所述确定子单元13还用于:
当与所述用户终端的所有DL SCC对应的去激活定时器超时或者未启动、且所述用户终端的所有DL SCC调度的UL CC上没有进程数据挂起时,确定所有DL SCC上没有数据和控制信息的传输需求。
所述确定子单元13还用于:
当与所述用户终端的任一DL SCC对应的去激活定时器超时或者未启动、且所述任一DL SCC调度的UL CC上没有进程数据挂起时,确定所述任一DLSCC上没有数据和控制信息的传输需求。
所述获知单元还包括:
启动子单元,用于当所述用户终端在任一DL CC上接收到针对初始传输的调度信令时,启动该用户终端对应的drx-Inactivity timer。
该启动子单元还用于所述用户终端接收到针对所述任一DL SCC的初始传输的调度信令或者所述任一DL SCC上接收到针对其可以调度的UL/DL CC上的初始传输的调度信令时,启动所述DL SCC对应的drx-Inactivity timer。
通过以上的实施方式的描述,本领域的技术人员可以清楚地了解到本发明可借助软件加必需的通用硬件平台的方式来实现,当然也可以通过硬件,但很多情况下前者是更佳的实施方式。基于这样的理解,本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本发明各个实施例所述的方法。
本领域技术人员可以理解附图只是一个优选实施例的示意图,附图中的模块或流程并不一定是实施本发明所必须的。
本领域技术人员可以理解实施例中的装置中的模块可以按照实施例描述进行分布于实施例的装置中,也可以进行相应变化位于不同于本实施例的一个或多个装置中。上述实施例的模块可以合并为一个模块,也可以进一步拆分成多个子模块。
上述本发明实施例序号仅仅为了描述,不代表实施例的优劣。
以上公开的仅为本发明的几个具体实施例,但是,本发明并非局限于此,任何本领域的技术人员能思之的变化都应落入本发明的保护范围。