背景技术
在基于共享信道的移动通信***中,例如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-Retransmission timer2。同样,在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操作,比如相同的PDCCHactive time(激活时间),该定义只是说明了各个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一致。Short cycle 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-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进程的重传调度。一旦接收到针对该进程重传的调度,则停止该定时器。虽然drx-Retransmission timer是针对一个进程控制的,但只要任何一个CC上的drx-Retransmission timer运行,UE都将在所有激活的CC上监听PDCCH。
基于上述理解,根据LTE规范,UE的active time包含如下时间:
On Duration Timer或者drx-Inactiviry 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 RTT timer定时器超时后,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,媒体接入控制层控制单元)。这种方式由eNB通过RRC信令控制UE激活和去激活SCC,这种方式需要定义新的RRC消息和相应的控制过程,增加了信令开销和复杂度,而且通过RRC消息进行载波激活和去激活模式控制的时延比较长。除了显式方式外,协议还支持隐式去激活机制,但是目前对于隐式去激活方式尚在讨论之中,没有明确结论。
具体实施方式
本发明实施例提供的载波去激活的方法中,首先介绍de-activation timer的时间长度的配置方式,de-activation timer的时间长度由RRC信令配置,具体配置方式包括如下两种:
1)基于CC配置;
2)基于UE配置。
具体的,通过RRC信令配置de-activation timer的时间长度。即基站eNB向用户终端发送携带de-activation timer的时间长度信息的RRC信令,用户终端获取RRC信令,配置对应的de-activation timer的时间长度。Deactivation-Timer的长度可用基于UE配置,也可以基于CC配置。
用户终端上配置的de-activation timer的时间长度基于CC配置时,对于每一DL SCC,分别设置de-activation timer的时间长度,使用户终端能够灵活控制每个DL SCC进行去激活的时间;而基于UE配置时,用户终端上配置的de-activation timer长度对于所有DL SCC都适用。
需要说明的是,为de-activation timer配置的时间长度至少需要大于HARQRTT的时间,要有一定余量以保证在UE可以收到针对重传的调度信令之前不会被去激活。
下面重点通过de-activation timer的维护方式介绍本发明实施例中提供的利用定时器进行隐式载波去激活的方法。
针对de-activation timer是基于UE还是基于CC配置以及UE是否配置有DRX,de-activation timer的维护方式也不完全相同,下面针对不同场景具体介绍de-activation timer可能的维护方式。
首先介绍第一种情况,de-activation timer基于UE配置,此时de-activation timer基于UE维护,de-activation timer的维护方式如图7所示,包括:
步骤701,UE接收到针对任何一个DL SCC的DL初始传输或者重传的调度信令之后启动/重启UE的de-acitvation timer;
此外,可选的,UE在任何一个DL SCC上接收到针对UL CC的初始传输或者重传的调度信令之后也可以启动/重启de-activation timer;另外,UE在任何一个DL SCC上接收到针对UL CC的初始传输或者重传的HARQ反馈为NACK之后,启动/重启UE的deactivation timer,此处的UL CC可以为任何一个UL CC。
需要说明的是,针对上述三种启动/重启UE的deactivation timer的方式,UE可以根据其中一种启动或者重启deactivation timer(本发明实施例中的启动/重选均表示启动或者重传),也可以根据其中任意两种或者三种启动或者重启deactivation timer。
步骤702,当de-activation timer超时的时刻,如果任何一个DL SCC可以调度的UL CC有进程数据挂起(即HARQ buffer中有数据),则重启de-activation timer。
需要说明的是,UE可以根据本步骤中重启de-activation timer的方式与步骤701中的任意一种或者多种启动或者重启deactivation timer的方式结合使用,也可以单独使用本步骤中重启de-activation timer的方式。
步骤703,当de-activation timer超时,去激活该UE所有的DL SCC。
例如,假定为UE配置了三个DL CC,分别标记为CC1、CC2和CC3,其中CC1为DL PCC,CC2和CC3为DL SCC,如图8所示,de-activation timer的维护以及隐式去激活机制如下:
T1:UE在CC1上接收到针对CC 1下行的调度信令以及对应的下行进程1的数据传输,CC1的下行进程1传输的数据块中包含载波激活MAC CE,该MAC CE可以激活载波CC2和CC3;
T2:因为CC1上进程1的下行数据中包含激活CC2和CC3的载波激活MAC CE,因此当UE解析出该数据包后应该激活CC2和CC3,此时UE启动de-activation timer;
T3:UE接收到针对CC2上进程1的初始传输的调度,此时UE应该重启de-activation timer;
T4:UE接收到针对CC3上进程1的初始传输的调度,此时UE应该重启de-activation timer;
T5:在UE的de-activation timer未超时之前,CC3上进程1的初始传输成功;
T6:UE在T6时刻收到针对CC2上进程1重传的调度信令,则重启de-activation timer;
T7:在UE的de-activation timer未超时之前,UE在CC2上的进程1传输成功;
T8:在T8时刻UE的在UE的de-activation timer超时且此时所有DL SCC可以调度的UL CC上没有进程挂起,因此UE在T8时刻可以隐式去激活所有激活的DL SCC,即CC2和CC3。
第一种情况下,de-activation timer的维护方式还可以为:
UE接收到针对任何一个DL SCC的DL初始传输的调度信令需要启动/重启UE的de-activation timer,此外,可选的,UE在任何一个DL SCC上接收到针对UL CC的初始传输的调度信令之后也可以启动/重启该UE的de-activation timer;且UE可以根据上述两种启动/重启该UE的de-activation timer的方式中的一种启动/重启该UE的de-activation timer,也可以同时根据该两种方式启动/重启该UE的de-activation timer。当UE的de-activation timer超时,去激活UE的所有DL SCC。需要说明的是,这种方式下要求de-activation timer的时间长度足够长,需要保证在UE的de-activation timer超时之前,UE所有DL SCC以及其可以调度的所有UL CC上的初始传输和重传都能够完成。
例如,设为UE配置了三个DL CC,分别标记为CC1、CC2和CC3,其中CC1为DL PCC,CC2和CC3为DL SCC,则de-activation timer的维护以及隐式去激活机制如图9所示,与图8的区别在于T4和T8,T4针对重传不需要重启de-activation timer,T8只需要判断de-activation timer是否超时。
第二种情况,de-activation timer基于CC配置,de-activation timer基于CC维护,此时de-activation timer的维护方式如图10所示,包括:
步骤1001,UE接收到针对任何一个DL SCC的DL初始传输或者重传的调度信令则在该DL SCC以及调度该DL SCC的DL SCC上启动或者重启de-activation timer。
步骤1002,UE在某个DL SCC上接收到针对某个UL CC的初始传输或者重传的调度信令之后启动或者重启该DL SCC对应的de-activation timer,和/或UE在某个DL SCC上接收到针对某个UL CC的初始传输或者重传的HARQ反馈为NACK之后,启动或者重启该DL SCC对应的de-activation timer。
需要说明的是,此步骤为可选步骤,可以不执行本步骤而直接执行步骤1003。
步骤1003,当某个DL SCC的de-activation timer定时器即将超时的时刻如果该DL SCC可以调度的UL CC有进程数据挂起,则重启该DL SCC对应的de-activation timer。
需要说明的是,UE可以根据本步骤中重启de-activation timer的方式与步骤1002中的任意一种或者多种启动或者重启deactivation timer的方式结合使用,也可以单独使用本步骤中重启de-activation timer的方式。
需要说明的是,此步骤为可选步骤,可以不执行本步骤而直接执行步骤1004。
步骤1004,当某个DL SCC的de-activation timer超时时去激活该DL SCC。
在这种方式下,需要注意,任何一个DL SCC被激活,则UE需要启动针对该CC的de-activation timer。
例如,设为UE配置了三个DL CC,分别标记为CC1、CC2和CC3,其中CC1为DL PCC,CC2和CC3为DL SCC,基于CC配置的de-activation timer维护机制如图11所示,de-activation timer的维护以及隐式去激活机制包括:
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分别启动其对应的去激活定时器de-activation timer2和de-activation timer3;
T3:UE在T3时刻接收到针对CC2上进程1的初始传输的调度,此时UE应该重启CC2对应的去激活定时器de-activation timer2;
T4:UE在T4时刻接收到针对CC3上进程1的初始传输的调度,此时UE应该重启CC3对应的去激活定时器de-activation timer3;
T5:在CC3的de-activation timer3未超时之前,CC3上进程1的初始传输成功;
T6:UE在T6时刻收到针对CC2上进程1重传的调度信令,则UE应该重启CC2对应的去激活定时器de-activation timer2;
T7:在CC2的de-activation timer2未超时之前,UE在CC2上的进程1传输成功;
T8:在T8时刻UE的在CC3上的de-activation timer3超时且此时该DLSCC可以调度的UL CC上没有进程数据挂起,因此CC3可以在T8时刻被隐式去激活;
T9:在T9时刻UE的在CC2上的de-activation timer2超时且此时该DLSCC可以调度的UL CC上没有进程挂起,因此CC2可以在T9时刻被隐式去激活。
第二种情况下,de-activation timer的维护方式还可以为:
UE在某个DL SCC上接收到针对该DL SCC或者其可调度的DL SCC上的初始传输的调度信令,则启动/重启该DL SCC及其调度的DL SCC上的de-activation timer;此外,可选的,当UE在某个DL SCC上收到针对任何一个UL CC的初始传输的调度信令之后启动/重启UE在该DL SCC上的de-activation timer;且上述两种启动/重启de-activation timer的方式可以单独使用或者结合使用。当UE在某个DL SCC上的de-activation timer超时,则去激活该DL SCC。
需要注意,这种方式下要求de-activation timer足够长,需要保证在该DLSCC上的de-activation timer超时之前,UE在该DL SCC以及其可以调度的所有DL或者UL CC上的初始传输和重传都能够完成。在这种方式下,还需要注意UE任何一个DL SCC被激活都需要启动或者重启UE在该DL SCC上的de-activation timer。
例如,设为UE配置了三个DL CC,分别标记为CC1、CC2和CC3,其中CC1为DL PCC,CC2和CC3为DL SCC,则基于CC配置的de-activation timer维护机制如图12所示,de-activation timer的维护以及隐式去激活机制与图11中的区别在于:
T6:针对CC2上的重传,无需重启de-activation timer2;
T8:为CC2上只需要判断de-activation timer2超时就可以去激活该DLSCC;
T9:为CC3上只需要判断de-activation timer3超时就可以去激活该DLSCC。
第三种情况,de-activation timer基于UE配置、UE配置有DRX,且基于DRX理解1,de-activation timer基于UE维护,此时de-activation timer的维护方式如图13所示,包括:
步骤1301,UE接收到针对任何一个DL SCC的DL初始传输或者重传的调度信令需要启动/重启UE的de-activation timer;
此外,可选的:如果UE在任何一个DL SCC上接收到针对UL CC的初始传输或者重传的调度信令或者UE在任何一个DL SCC上接收到针对UL CC的初始传输或者重传的HARQ反馈为NACK之后可以启动/重启UE的de-activation timer;需要说明的是,UE可以根据上述三种启动或者重启deactivation timer的方式中的一种或多种启动或者重启deactivation timer。
步骤1302,当任何一个DL SCC可以调度的UL CC上有进程数据挂起时,则在可能发送上行重传调度信令的时刻重启UE的de-activation timer。
需要说明的是,此步骤为可选步骤,可以不执行本步骤而直接执行步骤1303。
步骤1303,de-activation timer超时、且UE的drx-Inactivity timer和/或HARQ RTT timer/drx-Retransmission timer均未启动或者超时,UE去激活所有的DL SCC。
此外,该方法中最后两个过程还可以按照如下处理:当de-activation timer超时且UE的drx-Inactivity timer/HARQ RTT timer/drx-Retransmission timer均未启动或者超时,如果有任何一个DL SCC可以调度的UL CC上没有进程挂起,则重启de-activation timer,否则UE去激活所有的DL SCC。需要说明的是,UE还可以仅判断用户终端的drx-Inactivity timer是否启动或者超时,若用户终端的drx-Inactivity timer未启动或者超时,去激活所有的DL SCC;UE还可以仅判断用户终端的HARQ RTT timer和drx-Retransmission timer是否启动或者超时,若HARQ RTT timer和drx-Retransmission timer均未启动或者超时,去激活所有的DL SCC。
例如,设为UE配置了三个DL CC,分别标记为CC1、CC2和CC3,其中CC1为DL PCC,CC2和CC3为DL SCC,基于UE配置的de-activation timer维护机制如图14所示,de-activation timer的维护以及隐式去激活机制包括:
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也应该处于激活状态,此时应该启动UE的隐式去激活定时器启动de-activation timer;
T3:UE接收到针对CC2上进程1的初始传输的调度,此时UE应该重启drx-Inactivity timer并针对CC2上进程1启动HARQ RTT timer21,此外,还需要重启UE的隐式去激活定时器启动de-activation timer;
T4:UE接收到针对CC3上进程1的初始传输的调度,此时UE应该重启drx-Inactivity time并针对CC3上进程1启动HARQ RTT timer31,此外,还需要重启UE的隐式去激活定时器启动de-activation timer;
T5:UE在CC2的进程1的drx-Retransmission timer21运行期间接收到针对CC2上进程1的重传的调度信令,则此时UE应该启动针对CC2上该进程的HARQ RTT timer21,此外,还需要重启UE的隐式去激活定时器启动de-activation timer;
T6:在UE的de-activation timer和HARQ RTT timer31未超时之前,CC3上进程1的初始传输成功;
T7:在UE的de-activation timer和HARQ RTT timer21未超时之前,UE在CC2上的进程1传输成功;
T8:在T8时刻UE的de-activation timer超时并且该时刻UE的drx-Inactivity timer和针对该UE任何CC上的任何进程的HARQ RTT timer以及drx-Retransmission timer都处于未启动状态,如果此时该UE在所有SCC可以调度的UL CC上也没有挂起的上行传输,则应该此时隐式去激活为该UE配置的所有SCC,即CC2和CC3。
这种情况下,de-activation timer的维护方式也可以为:
UE接收到针对任何一个DL SCC的DL初始传输的调度信令之后启动/重启或者UE的de-activation timer,此外,可选的,UE在任何一个DL SCC上接收到针对UL CC的初始传输的调度信令之后都需要启动/重启该UE的de-activation timer;当UE的de-activation timer超时,则去激活UE的所有DLSCC。
需要说明的是,这种维护方式要求de-activation timer的时间长度足够长,需要保证在UE的de-activation timer超时之前,UE所有DL SCC以及其可以调度的所有UL CC上的初始传输和重传都能够完成。
例如,设为UE配置了三个DL CC,分别标记为CC1、CC2和CC3,其中CC1为DL PCC,CC2和CC3为DL SCC,则基于UE配置的de-activation timer维护机制如图15所示,de-activation timer的维护以及隐式去激活机制与图14的不同在于:
T5:UE在CC2的进程1的drx-Retransmission timer21运行期间接收到针对CC2上进程1的重传的调度信令,则此时UE应该启动针对CC2上该进程的HARQ RTT timer21,此时无需重启de-activation timer;
T8:在T8时刻UE的de-activation timer超时则可以去激活为该UE配置的所有SCC,即CC2和CC3。
第三种情况下,de-activation timer的维护方式还可以如图16所示,包括:
步骤1601,当UE的drx-Inactivity timer超时,启动或者重启该UE的de-activation timer;
步骤1602,当UE任何一个DL SCC的HARQ RTT timer超时,启动或者重启该UE的de-activation timer;
步骤1603,当UE任何一个DL SCC的drx-Retransmission timer超时,启动或者重启该UE的de-activation timer;
需要说明的是,步骤1602与1603之间没有必然的顺序关系,且这两种启动或者重启针对该DL SCC的de-activation timer的方式可以分别独立使用或者结合使用。
步骤1604,当de-activation timer超时且UE的drx-Inactivity timer/HARQRTT timer/drx-Retransmission timer均未启动,且UE所有DL SCC可以调度的所有UL CC上都没有进程数据挂起时,UE去激活所有的DL SCC。
需要说明的是,UE还可以仅判断用户终端的drx-Inactivity timer是否启动或者超时,若用户终端的drx-Inactivity timer未启动或者超时,去激活所有的DL SCC;UE还可以仅判断用户终端的HARQ RTT timer和drx-Retransmission timer是否启动或者超时,若HARQ RTT timer和drx-Retransmission timer均未启动或者超时,去激活所有的DL SCC。
这种情况下,de-activation timer的维护方式还可以为:
当UE的drx-Inactiviry timer超时,则启动/重启该UE的de-activation timer;当de-activation timer超时则去激活UE的所有DL SCC。需要说明的是,这种方式下,de-activation timer的长度可以为0,也可以为其它值,只要能保证在UE的de-activation timer超时之前,UE所有DL SCC以及其可以调度的所有UL CC上的初始传输和重传都能够完成。
第四种情况,de-activation timer基于CC配置,UE配置有DRX,基于DRX理解2,de-activation timer基于CC维护,如图17所示,此时de-activationtimer的维护方式包括:
步骤1701,UE接收到针对任何一个DL SCC的DL初始传输或者重传的调度信令,在该DL SCC以及调度该DL SCC的DL SCC上启动/重启de-activation timer。
步骤1702,UE在某个DL SCC上接收到针对某个UL CC的初始传输或者重传的调度信令之后都需要重启该DL SCC对应的de-activation timer,和/或UE在某个DL SCC接收到针对某个UL CC的初始传输或者重传的HARQ反馈为NACK之后重启该DL SCC对应的de-activation timer。
需要说明的是,此步骤为可选步骤,可以不执行本步骤而直接执行步骤1703。
步骤1703,当UE的某个DL SCC的de-activation timer超时,但是该DLSCC可以调度的任何一个UL CC上有进程数据挂起,则重启该DL SCC对应的de-activation timer。
需要说明的是,UE可以根据本步骤中重启该DL SCC对应的de-activation timer的方式与步骤1702中的任意一种或者多种启动或者重启该DL SCC对应的deactivation timer的方式结合使用,也可以单独使用本步骤中重启该DLSCC对应的de-activation timer的方式。
需要说明的是,此步骤为可选步骤,可以不执行本步骤而直接执行步骤1704。
步骤1704,当某个DL SCC上的de-activation timer超时,该DL SCC上的drx-Inactivity timer/HARQ RTT timer/drx-Retransmission timer均未启动或者超时,UE去激活该DL SCC。
需要说明的是,在这种方式下,任何一个DL SCC被激活,UE需要启动针对该CC的de-activation timer。这种方式下对于de-activation timer长度没有限制。
此外,该方法中最后两个过程还可以按照如下处理:当某个DL SCC上的de-activation timer超时,该DL SCC上的drx-Inactivity timer/HARQ RTTtimer/drx-Retransmission timer均未启动或者超时,且该DL SCC可以调度的任何一个UL CC上都没有进程挂起的时候,UE去激活该DL SCC。需要说明的是,UE还可以仅判断DL SCC上的drx-Inactivity timer是否启动或者超时,若DL SCC上的drx-Inactivity timer未启动或者超时,去激活该DL SCC;UE还可以仅判断DL SCC上的HARQ RTT timer和drx-Retransmission timer是否启动或者超时,若HARQ RTT timer和drx-Retransmission timer均未启动或者超时,去激活该DL SCC。
例如,设为UE配置了三个DL CC,分别标记为CC1、CC2和CC3,其中CC1为DL PCC,CC2和CC3为DL SCC,则基于CC配置的de-activation timer维护机制如图18所示,de-activation timer的维护以及隐式去激活机制包括:
T1:UE在CC1上接收到针对CC1下行的调度信令以及对应的下行进程1的数据传输,此时UE应该启动针对CC1上进程1的drx-Inactivity timer11和HARQ RTT timer11;
T2:因为CC1上进程1的下行数据中包含激活CC2和CC3的载波激活MAC CE,因此当UE解析出该数据包后应该激活CC2和CC3,因为UE在CC2和CC3上应该分别启动针对CC2和CC3的drx-Inactivity timer2和drx-Inactivity timer3以及隐式去激活定时器de-activation timer2和de-activationtimer3;
T3:UE接收到针对CC2上进程1的初始传输的调度,此时UE应该重启CC2上的drx-Inactivity timer2并针对CC2上进程1启动HARQ RTT timer21,此时还需要重启CC2对应的去激活定时器de-activation timer2;
T4:UE接收到针对CC3上进程1的初始传输的调度,此时UE应该重启CC3上的drx-Inactivity time3并针对CC3上进程1启动HARQ RTT timer31,UE应该重启CC3对应的去激活定时器de-activation timer3;
T5:在CC3的de-activation timer3和HARQ RTT timer31未超时之前,CC3上进程1的初始传输成功;
T6:在T6时刻UE在CC3上的de-activation timer超时且CC3上的drx-Inactivity timer以及HARQ RTT timer和drx-Retransmission timer都处于未启动状态,如果此时在CC3可以调度的UL CC上也没有挂起的上行传输,则应该隐式去激活CC3。
T7:UE在CC2的进程1的drx-Retransmission timer21运行期间接收到针对CC2上进程1的重传的调度信令,则此时UE在CC2上应该启动针对该进程的HARQ RTT timer2以及CC2上的隐式去激活定时器de-activation timer2;
T8:在CC2上的de-activation timer2和HARQ RTT timer21未超时之前,UE成功接收CC3上的进程1;
T9:在T6时刻UE在CC2上的de-activation timer超时且CC2上的drx-Inactivity timer以及HARQ RTT timer和drx-Retransmission timer都处于未启动状态,如果此时在CC2可以调度的UL CC上也没有挂起的上行传输,则应该隐式去激活CC2。
这种情况下,de-activation timer的维护方式还可以为:UE在某个DL SCC上接收到针对该DL SCC或者其可调度的DL SCC上的初始传输的调度信令,则启动/重启该DL SCC及其调度的DL SCC上的de-activation timer;此外,可选的,当UE在某个DL SCC上收到针对任何一个UL CC的初始传输的调度信令之后都需要启动/重启该UE的de-activation timer;当UE在某个DL SCC上的de-activation timer超时,则去激活该DL SCC。需要说明的是,这种方式下要求de-activation timer足够长,需要保证在该DL SCC上的de-activation timer超时之前,UE在该DL SCC以及其可以调度的所有DL/UL CC上的初始传输和重传都能够完成。在这种方式下,还需要注意UE任何一个DL SCC被激活都需要启动/重启UE在该DL SCC上的de-activation timer。
例如,设为UE配置了三个DL CC,分别标记为CC1、CC2和CC3,其中CC1为DL PCC,CC2和CC3为DL SCC,则基于CC配置的de-activationtimer维护机制如图19所示,de-activation timer的维护以及隐式去激活机制与图18的区别在于:
T6:UE在CC2的进程1的drx-Retransmission timer21运行期间接收到针对CC2上进程1的重传的调度信令,则此时UE在CC2上应该启动针对该进程的HARQ RTT timer2,无需重启CC2上的隐式去激活定时器de-activationtimer2;
T7:在CC2上的de-activation timer2和HARQ RTT timer21未超时之前,UE成功接收CC3上的进程1;
T8:在T8时刻UE在CC2上的de-activation timer超时且CC2上的drx-Inactivity timer则应该隐式去激活CC2。
T9:在T9时刻UE在CC3上的de-activation timer超时且CC2上的drx-Inactivity timer则应该隐式去激活CC3。
第四种情况下,如图20所示,de-activation timer的维护方式还可以包括:
步骤2001,当UE在某个DL SCC上的drx-Inactivity timer超时,则UE启动或者重启针对该DL SCC的de-activation timer;
步骤2002,当UE任何一个DL SCC的HARQ RTT timer超时,则UE启动或者重启针对该DL SCC的de-activation timer;
步骤2003,当UE任何一个DL SCC的drx-Retransmission timer超时,UE启动或者重启针对该DL SCC的de-activation timer;
需要说明的是,本步骤与步骤2002之间没有必然的顺序关系,且这两种启动或者重启针对该DL SCC的de-activation timer的方式可以分别独立使用或者结合使用。
步骤2004,当某个DL SCC的de-activation timer超时,针对该DL SCC的drx-Inactivity timer/HARQ RTT timer/drx-Retransmission timer均未启动,且该DL SCC可以调度的所有UL CC上都没有进程数据挂起时,UE去激活该DL SCC。需要说明的是,UE还可以仅判断DL SCC上的drx-Inactivity timer是否启动或者超时,若DL SCC上的drx-Inactivity timer未启动或者超时,去激活该DL SCC;UE还可以仅判断DL SCC上的HARQ RTT timer和drx-Retransmission timer是否启动或者超时,若HARQ RTT timer和drx-Retransmission timer均未启动或者超时,去激活该DL SCC。
这种情况下,de-activation timer的维护方式还可以为:当UE在DL SCC上的drx-Inactivity timer超时,则启动或者重启该UE的de-activation timer,当DL SCC上的de-activation timer超时,UE去激活该DL SCC。该情况下,de-activation timer的长度可以为0,也可以为其它值,只要能保证在UE的de-activation timer超时之前,UE在DL SCC及其可以调度的所有UL CC上的初始传输和重传都能够完成。
需要说明的是,本发明实施例提供的方法中,用户终端收到显式激活信令后,停止与DL SCC对应的drx-Inactivity timer,具体包括:若用户终端基于UE维护deactivation timer,则停止与UE对应的drx-Inactivity timer;若用户终端基于CC维护deactivation timer,则停止与显式激活信令对应的DL SCC上的drx-Inactivity timer。
通过采用本发明实施例提供的方法,根据下行辅载波DL SCC上的数据和控制信息的传输需求维护载波去激活定时器,当载波去激活定时器超时时去激活对应的DL SCC,从而提供了LTE-A***中的隐式去激活机制。
基于与上述方法相同的技术构思,本发明实施例提供一种用户终端,如图21所示,包括:
维护单元11,用于根据下行辅载波DL SCC上的数据和控制信息的传输需求维护载波去激活定时器;
去激活单元12,用于若所述载波去激活定时器超时,去激活对应的DL SCC。
所述载波去激活定时器及其长度由RRC信令配置,所述载波去激活定时器及其长度基于DL SCC或者用户终端配置。
所述载波去激活定时器基于DL SCC或者用户终端维护。
所述维护单元11还用于:
当接收到针对用户终端配置的任何一个DL SCC的下行初始传输或者重传的调度信令之后启动或者重启与所述用户终端对应的载波去激活定时器;和/或
当针对用户终端配置的任何一个DL SCC上接收到针对UL CC的初始传输或者重传的调度信令之后启动或者重启与所述用户终端对应的载波去激活定时器;和/或
当针对用户终端配置的任何一个DL SCC上接收到针对UL CC的初始传输或重传的HARQ反馈为NACK之后启动或者重启与所述用户终端对应的载波去激活定时器;和/或
在所述载波去激活定时器超时的时刻,如果任何一个DL SCC调度的ULCC有进程数据挂起,重启与所述用户终端对应的载波去激活定时器。
其中,所述载波去激活定时器的时间长度可以设置为大于所述DL SCC和UL CC上的一个进程连续两次传输之间需要的最长时间。
所述维护单元11还可以用于:
当接收到针对用户终端配置的任何一个DL SCC的下行初始传的调度信令之后启动或者重启与所述用户终端对应的载波去激活定时器;和/或
当针对用户终端配置的任何一个DL SCC上接收到针对UL CC的初始传输的调度信令之后启动或者重启与所述用户终端对应的载波去激活定时器。
所述维护单元11还可以用于:
当接收到针对用户终端配置的任一DL SCC的下行初始传输或者重传的调度信令,在所述任一DL SCC以及调度所述任一DL SCC的DL SCC上启动或者重启载波去激活定时器;和/或
当在针对用户终端配置的任一DL SCC上接收到针对UL CC初始传输或者重传的调度信令,在所述任一DL SCC上启动或者重启载波去激活定时器;和/或
当针对用户终端配置的任一DL SCC上接收到针对UL CC的初始传输或重传的HARQ反馈为NACK,在所述任一DL SCC上启动或者重启载波去激活定时器;和/或
在所述任一DL SCC对应的载波去激活定时器超时的时刻,若所述任一DL SCC调度的UL CC上有进程数据挂起,则重启所述任一DL SCC对应的载波去激活定时器。
其中,所述载波去激活定时器的时间长度可以设置为大于所述DL SCC和UL CC上的一个进程连续两次传输之间需要的最长时间。
所述维护单元11还可以用于:
当接收到针对用户终端配置的任一DL SCC的下行初始传输的调度信令,在所述任一DL SCC以及调度所述任一DL SCC的DL SCC上启动或者重启载波去激活定时器;和/或
当在针对用户终端配置的任一DL SCC上接收到针对UL CC初始传输的调度信令,在所述任一DL SCC上启动或者重启载波去激活定时器。
其中,所述载波去激活定时器的时间长度大于所述DL SCC和UL CC上的一个进程开始到重传结束所需要的最长时间。
所述维护单元11还可以用于:当用户终端的drx-Inactivity timer超时,启动或者重启所述用户终端的载波去激活定时器。所述维护单元11还可以用于:当所述用户终端的任一DL SCC的HARQ RTT timer超时,启动或者重启所述用户终端的载波去激活定时器;和/或当所述用户终端的任一DL SCC的drx-Retransmission timer超时,启动或者重启所述用户终端的载波去激活定时器。
所述维护单元11还可以用于:当所述用户终端在任一DL SCC上的drx-Inactivity timer超时,启动或者重启所述任一DL SCC上的载波去激活定时器。所述维护单元11还用于:当所述用户终端在所述任一DL SCC的HARQRTT timer超时,启动或者重启所述任一DL SCC的载波去激活定时器;和/或当所述用户终端在所述任一DL SCC的drx-Retransmission timer超时,启动或者重启所述任一DL SCC的载波去激活定时器。
其中,所述载波去激活定时器的时间长度大于所述DL SCC和UL CC上的一个进程开始到重传结束所需要的最长时间。
本发明实施例中,还包括判断单元13,用于判断所述用户终端的drx-Inactivity timer是否启动或者超时;和/或判断所述用户终端的HARQ RTTtimer和drx-Retransmission timer是否启动或者超时;所述去激活单元12还用于:所述判断单元的判断结果为未启动或者超时时,去激活所述DL SCC。
判断单元13,还可以用于判断所述DL SCC上的drx-Inactivity timer是否启动或者超时;和/或判断所述DL SCC上的HARQ RTT timer和drx-Retransmission timer是否启动或者超时;所述去激活单元12还用于:所述判断单元的判断结果为未启动或者超时时,去激活所述DL SCC。
本发明实施例中,所述载波去激活定时器超时则去激活该UE所有的DLSCC,或者所述任一DL SCC上的载波去激活定时器超时,则去激活所述任一DL SCC。
本发明实施例中,还包括:
停止单元14,用于接收到显式去激活信令时,停止与所述DL SCC对应的载波去激活定时器。
通过采用本发明实施例提供的用户终端,根据下行辅载波DL SCC上的数据和控制信息的传输需求维护载波去激活定时器,当载波去激活定时器超时时去激活对应的DL SCC,从而提供了LTE-A***中的隐式去激活机制。
通过以上的实施方式的描述,本领域的技术人员可以清楚地了解到本发明可借助软件加必需的通用硬件平台的方式来实现,当然也可以通过硬件,但很多情况下前者是更佳的实施方式。基于这样的理解,本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本发明各个实施例所述的方法。
本领域技术人员可以理解附图只是一个优选实施例的示意图,附图中的模块或流程并不一定是实施本发明所必须的。
本领域技术人员可以理解实施例中的装置中的模块可以按照实施例描述进行分布于实施例的装置中,也可以进行相应变化位于不同于本实施例的一个或多个装置中。上述实施例的模块可以合并为一个模块,也可以进一步拆分成多个子模块。
上述本发明实施例序号仅仅为了描述,不代表实施例的优劣。
以上公开的仅为本发明的几个具体实施例,但是,本发明并非局限于此,任何本领域的技术人员能思之的变化都应落入本发明的保护范围。