发明内容
为了解决上面所提到的一些技术问题,本公开的一个方面提供一种在支持用户设备与宏基站和小型基站的双连接的无线通信网络中使用的方法,其中所述小型基站至少包括配置用于所述用户设备的物理上行链路控制信道传输的一个特殊小区,所述方法包括在发生从旧的特殊小区到新的特殊小区的改变的情形下,在所述用户设备处执行一个或多个动作以处理所述旧的特殊小区的先前传输。
在一个实施方式中,其中在所述用户设备处执行的一个或多个动作涉及所述旧的特殊小区的上行链路同步状态。
在一个实施方式中,该方法进一步包括停止定时提前定时器以及确定所述旧的特殊小区的上行链路同步为无效。
在另一个实施方式中,所述方法进一步包括检查定时提前定时器的状态,响应于所述定时提前定时器仍在运行,确定所述旧的特殊小区的上行链路同步为有效;以及响应于所述定时提前定时器在特殊小区改变过程中停止或到期,确定所述旧的特殊小区的上行链路同步为无效。
在又一个实施方式中,所述方法进一步包括响应于完成特殊小区重配置过程,重新启动定时提前定时器并且确定所述旧的特殊小区的上行链路同步为有效。
在一个实施方式中,所述方法进一步包括基于来自基站的指示对定时提前定时器执行操作,以便基于所述操作来确定所述旧的特殊小区的上行链路同步为有效或无效。
在另一个实施方式中,其中在所述用户设备处执行的一个或多个动作涉及所述旧的特殊小区的相对于所述用户设备的激活或去激活状态。
在又一实施方式中,所述方法进一步包括确定所述旧的特殊小区相对于所述用户设备处于所述激活状态以及启动小区去激活定时器。
在一个实施方式中,所述方法进一步包括确定所述旧的特殊小区相对于所述用户设备处于所述去激活状态。
在又一实施方式中,所述方法进一步包括基于来自基站的指示来确定所述旧的特殊小区相对于所述用户设备处于所述激活或去激活状态。
在一个实施方式中,其中在所述用户设备处执行的一个或多个动作涉及所述旧的特殊小区的先前下行链路传输。
在又一实施方式中,其中所述旧的特殊小区相对于所述用户设备处于激活状态,所述方法进一步包括以下中的一项:释放在所述旧的特殊小区上正在进行的下行链路混合自动重传请求进程并且释放所有相关的下行链路混合自动重传请求缓冲器;保持所述下行链路混合自动重传请求进程和相关的缓冲器直到相应的下行链路传输被正确接收;在特殊小区改变过程后,响应于在所述旧的特殊小区上接收到下行链路调度信令,将新接收的下行链路传输和缓冲的信息合并;以及在特殊小区改变过程后,响应于从所述小型基站接收到新的下行链路传输,释放来自于所述旧的特殊小区的缓冲的信息。
在另一实施方式中,其中所述旧的特殊小区相对于所述用户设备处于去激活状态,所述方法进一步包括释放针对所述旧的特殊小区的所有下行链路混合自动重传请求缓冲器和下行链路混合自动重复请求进程;以及等待所述小型基站调度新的传输。
在又一实施方式中,其中在所述用户设备处执行的一个或多个动作涉及所述旧的特殊小区的先前上行链路传输。
在另一实施方式中,其中所述先前上行链路传输包括上行链路上行控制信息传输,所述方法进一步包括以下中的一项:响应于完成在所述新的特殊小区上的上行链路随机接入过程,触发在所述旧的特殊小区上的所述上行链路上行控制信息传输;响应于完成在所述旧的特殊小区上的上行链路随机接入过程,触发在所述旧的特殊小区上的所述上行链路上行控制信息传输,其中所述上行链路随机接入过程用于所述用户设备和所述小型基站之间的上行链路同步;响应于在所述新的特殊小区上的上行链路上行控制信息传输,触发在所述旧的特殊小区上的所述上行链路上行控制信息传输;响应于在所述新的特殊小区上接收到首个调度信令,触发在所述旧的特殊小区上的所述上行链路上行控制信息传输;响应于在所述旧的特殊小区上接收到调度信令或响应于接收到关于所述旧的特殊小区的调度信令,触发在所述旧的特殊小区上的所述上行链路上行控制信息传输;以及响应于接收到来自于基站在介质访问控制控制单元中传输的指示,触发在所述旧的特殊小区上的所述上行链路上行控制信息传输。
在一个实施方式中,其中所述先前上行链路传输包括上行链路上行数据信息传输,并且所述旧的特殊小区处于激活状态,所述方法进一步包括以下中的一项:释放与所述旧的特殊小区相关的所有正在进行的上行链路混合自动重传请求进程和上行链路混合自动重传请求缓冲器;以及暂停与所述旧的特殊小区相关的所有正在进行的上行链路混合自动重传请求进程并且保留对于接收到否定确认的上行链路混合自动重传请求进程的所有上行链路混合自动重传请求缓冲器,以便执行以下之一:响应于成功接入到所述新的特殊小区,重新开始在所述旧的特殊小区上的上行链路传输;响应于在成功接收到来自所述新的特殊小区的首个调度信令,重新开始在所述旧的特殊小区上的非自适应重传;响应于在所述旧的特殊小区上接收到首个上行链路信令,重新开始在所述旧的特殊小区上的所有暂停的上行链路混合自动重传请求进程;响应于完成在所述旧的特殊小区上的上行链路随机接入过程,触发在所述旧的特殊小区上的所述上行链路上行数据信息传输,其中所述上行链路随机接入过程用于所述用户设备和所述小型基站之间的上行链路同步;以及响应于在所述旧的特殊小区上接收到与暂停的上行链路混合自动重传请求进程相关联的上行链路信令,重新开始在所述旧的特殊小区上的所述暂停的上行链路混合自动重传请求进程。
在另一实施方式中,其中在从所述旧的特殊小区到所述新的特殊小区的改变过程中,所述方法包括释放所述旧的特殊小区。这里,所述释放动作可以例如是在特殊小区(无线电资源控制RRC)改变过程中,用户设备基于接收到来自于小型基站的指示进行相应的动作,例如用户设备根据指示来释放旧的特殊小区,或者根据指示来保持该旧的特殊小区,即不释放该旧的特殊小区。
在又一实施方式中,所述释放所述旧的特殊小区包括以下至少一项:释放与所述旧的特殊小区相关的所有上行链路上行控制信息配置;释放与所述旧的特殊小区相关的所有上行或下行混合自动重复请求进程;以及释放与所述旧的特殊小区相关的所有上行或下行混合自动重复请求缓冲器。
在一个实施方式中,其中所述先前上行链路传输包括上行链路上行数据信息传输,并且所述旧的特殊小区处于非激活状态,所述方法进一步包括释放与所述旧的特殊小区相关的所有正在进行的上行链路混合自动重传请求进程和上行链路混合自动重传请求缓冲器。
本公开的另一方面提供一种在支持用户设备与宏基站和小型基站的双连接的无线通信网络中使用的设备,其中所述小型基站至少包括配置用于所述用户设备的物理上行链路控制信道传输的一个特殊小区,所述设备包括:执行单元,用于在发生从旧的特殊小区到新的特殊小区的改变的情形下,在所述用户设备处执行一个或多个动作以处理所述旧的特殊小区的先前传输。
本公开的另一方面提供一种用于执行上述方法的用户设备。
利用根据本公开的多个方面和实施方式的方法和设备,可以很好地解决在双连接构架下如何处理旧的特殊小区的先前传输的问题,进一步提高双连接无线传输中的可能性和可靠性,并且也提高了传输效率。
具体实施方式
本公开在多个示例性实施方式中提出了关于如何处理旧的SPcell的先前传输的多个解决方案。具体地,本公开提出用于在SPcell改变过程完成后处理旧的SPcell的UL同步状态的四种实施方式、在SPcell改变过程完成后处理旧的SPcell的激活/去激活状态的三种实施方式、根据旧的SPcell激活/去激活状态来处理先前的下行链路(“DL”)传输的UE行为准则/解决方案、如何自动地重新开始在旧的SPcell上的UL UCI(“UCI”)传输并且确保在此类的ULUCI传输上的SeNB和UE之间的同步的五种实施方式,以及如何处理先前的UL物理上行链路共享信道(“PUSCH”)传输并且确保在旧的SPcell上的自动UL PUSCH传输时SeNB和UE之间同步的五种实施方式。
如前面所提到的,在SPcell改变过程后,旧的SPcell已经转变成一个常规的Scell。在该SPcell改变过程前,在该旧的SPcell上必然存在着UL传输,例如UL PUSCH(例如UL HARQ进程传输)传输、UL UCI传输,例如UL探测参考信号(“SRS”)、UL信道质量指示符(“CQI”)、预编码矩阵指示符(“PMI”)和秩指示(“RI”)传输等。另外,由于在SPcell重配置过程前,该旧的SPcell总是处于激活状态,因此小区去激活定时器sCellDeactivationTimer并没有运行。鉴于此,本公开也提出了关于UE在SPcell重配置过程后的相关行为以适当地处理旧的SPcell的先前传输。
总之,在完成SPcell改变过程后,对于旧的SPcell,本公开旨在至少解决下面的问题:
问题1:如何处理旧的SPcell的上行(UL)同步(“SYN”)状态;
问题2:在UE侧完成SPcell改变过程后,如何处理或确定旧的SPcell的激活/去激活状态;以及
问题3:如何处理旧的SPcell的先前UL/DL数据传输以及ULUCI传输。
问题1.处理旧的SPcell UL SYN的解决方案
为了确保在SPcell改变过程后正确且适当地进行UL传输,应当识别或确定旧的SPcell的UL SYN状态,以便正确地引导UE在旧的SPcell上的后续操作。为此,本公开提出下面的四个示例性实施方式,其将导致不同的UE行为:
· 实施方式1:当SPcell配置完成时,UE停止定时提前定时器(“TAT”)并且接着将旧的SPcell的UL同步状态视为无效,即认为UE与旧的SPcell上行传输并不同步;
· 实施方式2:SPcell改变过程并不影响当前正在运行的TAT定时器,并且UE将在其侧完成SPcell改变过程后检查该定时器状态,并且
如果TAT仍在运行,则确认UE与旧的SPcell上行同步;
替代地,如果TAT在SPcell重配置过程期间停止/到期,则UE与旧的SPcell UL同步被视为无效,即确定UE与旧的SPcell上行并不同步。
· 实施方式3:在完成SPcell重配置后,UE重启TAT定时器并且确认UE与旧的SPcell上行是同步的;
· 实施方式4:SeNB在MeNB向UE传输的无线电资源控制(“RRC”)消息中增加额外的指示,以指示UE来执行相应的动作,例如停止TAT定时器或保持该定时器、或重启定时器等。
根据本公开上述讨论的实施方式,对于实施方式1,在SPcell改变过程完成后,如果用于旧的SPcell的TAT定时器仍在运行,则UE将停止该定时器并且认为旧的SPcell UL同步状态将不再有效。接着,UE将不在该旧的SPcell上执行任何的UL传输直到获得新的定时提前(“TA”)。例如,如果该旧的SPcell处于与新的SPcell处于相同的定时提前组(“TAG”)内,则UE认为该新的SPcell的UL同步也是无效的。为此,在开始新的SPcell上的任何UL传输前,UE将执行与新的SPcell的UL同步。相应地,如果在新的SPcell获得了新的UL同步,例如基于竞争的上行PRACH过程或免竞争的上行PRACH过程,则UE在旧的SPcell上的UL同步状态也将自动地重新开始,从而UL传输可以重新开始。另一方面,如果旧的SPcell处于与新的SPcell不同的TAG,则在SPcell改变过程后,SeNB将知道UE在旧的SPcell的上行同步是无效的。为此,SeNB将在旧的SPcell上触发新的上行随机接入过程(或在本申请中称为上行PRACH过程),以获得与旧的SPcell的UL同步,从而可以重新开始在旧的SPcell上的UL传输。
在R10/R11中,当由HO过程触发Pcell改变过程时,源eNB的所有TAG的TAT定时器都将被释放。相比而言,对于本公开所建议的实施方式2,其SPcell改变过程不影响旧的SPcell的TAT操作。即,在UE侧接收到SPcell改变命令时,UE将不会如R10中所规定的那样停止或释放该定时器。相反,UE将令旧的SPcell的TAT定时器继续运行。在UE侧完成SPcell改变过程后,UE将检查TAT状态:
如果TAT定时器仍在运行,则UE认为旧的SPcell UL同步仍然有效。如果旧的SPcell处于与新的SPcell相同的TAG内,则UE将认为与新的SPcell的上行同步也是有效的。因此,没有必要在新的SPcell上执行上行PRACH过程,除非SeNB要求UE这样做;
如果TAT定时器在SPcell改变过程期间到期,则UE可以认为其与旧的SPcell的UL同步不再有效。此时,SeNB可以基于其自身的相应TAT定时器状态来检测到该情形并且确定UE在旧的SPcell的UL同步是无效的。接着,SeNB可以或者触发UE来执行在旧的SPcell上的上行PRACH过程,或者令UE来决定何时基于竞争的PRACH过程来重新获得与旧的SPcell的UL同步。
对于实施方式3,在完成SPcell改变过程后,无论旧的SPcell的TAT定时器情况如何,UE将重启旧的SPcell的TAT定时器。接着,可以确定在旧的SPcell上的上行同步状态。在SeNB侧,如果检测到在旧的SPcell上的上行同步状态并不好,例如基于在旧的SPcell上的后续上行传输,则SeNB将触发在旧的SPcell上的上行PRACH过程以重新改进UE与旧的SPcell UL同步状态。从这点来看,实施方式3对于实现UE与旧的SPcell上行同步非常有效。
对于实施方式4,SeNB可以通过在SPcell改变RRC消息中包括指示来控制UE的行为或动作。例如,在SPcell改变过程后,SeNB可以指示UE执行在旧的SPcell上的新的上行PRACH过程。接着,在UE侧,UE将确定或知道旧的SPcell的UL同步已被视为无效。因此,UE将不会在旧的SPcell上执行任何的UL传输,直到重新获得与旧的SPcell上的UL同步。另一方面,SeNB也可以要求UE来保持TAT运行,并且接着在SPcell改变过程完成后,可以在UE侧执行如实施方式2中所定义的操作规则。
总之,本公开上述所提出的四个实施方式可以导致或得到不同的UE行为,并且也确保了UE在旧的SPcell上的操作可以被正确地执行。
问题2.如何处理旧的SPcell的激活/去激活状态
根据当前的R12DC规定,SPcell将总是处于激活状态,因此在SPcell的生存期期间,应该不存在运行的小区去激活定时器(“CellDeactivationTimer”)。接着,该旧的SPcell转换成一个常规的Scell。而对于一个常规的Scell来说,其应该具有不同的激活/去激活状态,并且应该具有定时器CellDeactivationTimer来关联到该旧的SPcell。
鉴于上述,本公开建议下面的三个实施方式来处理在SPcell过程改变后如何处理旧的SPcell的激活/去激活状态:
· 实施方式1:保持旧的SPcell为激活状态;
· 实施方式2:保持旧的SPcell为去激活状态;以及
· 实施方式3:基于包括在SPcell改变RRC消息中的SeNB
的命令来确定SPcell处于激活或去激活状态。
对于实施方式1,在SPcell改变过程完成后,旧的SPcell将被认为是处于激活状态。然而,该“激活”状态仅仅是暂时性地“激活”,并且不同于先前的“总是激活状态”。接着,在完成SPcell改变过程后,当旧的SPcell被认为是激活状态时,UE应该自动地启动相应的sCellDeactivationTimer定时器。在该定时器到期后,UE将认为该旧的SPcell的相对于该UE的激活状态应该被停止并且接着自动地进入到非激活状态。可以看出,该全新的UE行为可以被认为是基于由定时器sCellDeactivationTimer运行所触发的RRC消息的方式。
对于实施方式2,在UE完成SPcell改变过程后,旧的SPcell将被认为是处于非激活状态。接着,UE应该释放所有相应的混合自动重复请求(“HARQ”)进程,从而导致数据丢失以及后续的冗余重传。该实施方式使用SPcell改变RRC消息来触发UE去激活旧的SPcell,因此可以被视为RRC触发的Scell去激活操作,而这在R10/R11中并未规定。因为在先前的版本中,激活或去激活是由介质访问控制(“MAC”)控制单元(“CE”)来控制的而非由RRC过程来控制的。
对于实施方式3,SeNB将在SPcell改变RRC消息中给出新的指示,以引导UE行为。例如,如果SeNB指示UE来将旧的SPcell保持为相对于所述UE为去激活,则UE应该执行在实施方式1中定义的新的操作。另一方面,如果SeNB命令UE去激活旧的SPcell,则UE将执行实施方式2中所定义的新的操作。
总之,不管采取上述三种实施方式中的哪一种,UE将确保其在完成SPcell改变过程后执行正确合适的操作。
问题3.如何处理旧的SPcell的先前DL传输
该问题涉及对于在SPcell改变过程后,对于旧的SPcell激活/去激活状态,即问题2中采取哪个实施方式:
对于问题2中的实施方式1或实施方式3中SeNB在RRC消息中给出激活状态指示的情形,在SPcell改变过程完成后,旧的SPcell将保持在激活状态。对于该情形,本公开提出了下面的UE行为/操作:
· UE将继续维护和暂停在旧的SPcell上的正在进行的DLHARQ进程;
· 进一步,UE继续保持相应的DL HARQ缓冲器,直到数据被正确地接收;
· UE等待SeNB的进一步DL调度信令(例如许可(“grant”))以便重新开始或释放在该旧的SPcell上的这些暂停的DLHARQ进程;
· 在SPcell改变过程后,UE将自动重新开始检测旧的SPcell上的SeNB的DL传输,从而UE知道如何处理旧的SPcell上的暂停的DL HARQ进程。例如,
如果SeNB通过在旧的SPcell上向UE发送相关的DL许可来执行DL HARQ重传,则UE将新近接收到的DL传输与在相应的缓冲器中缓冲的信息组合以便传输;
另一方面,如果UE接收到作为新的传输的DL许可,则UE将释放在相应的HARQ缓冲器中缓冲的信息,并且将接收到的DL传输视为新的传输。
· 替代地,如果采取问题2中的实施方式2,或采取问题2中的实施方式3但SeNB要求UE去激活旧的SPcell,则UE将释放所有的DL HARQ缓冲器并且等待SeNB调度新的传输。
总之,基于本公开上述的各个实施方式,可以看出在旧的SPcell上的先前DL传输将在SPcell改变过程完成后被正确地处理。
问题4.如何处理旧的SPcell的先前UL传输
如上所述,在SPcell改变过程前,在旧的SPcell上肯定存在UL传输,例如物理上行链路共享信息(“PUSCH”)、PUCCH以及UL UCI传输,包括SRS、CQI/PMI/RI反馈等。接着,在SPcell改变过程完成后,需要确定如果处理现有的UL HARQ操作、如何以及何时重新开始UE自动地执行UL UCI传输等。这些问题也涉及问题2和问题1中采取哪个实施方式。
如问题2中所描述的,当采取实施方式2时,SPcell改变的RRC过程触发去激活旧的SPcell,UE将释放所有先前的UL HARQ操作,并且停止所有正在进行的UL UCI传输,而不考虑旧的SPcell的UL同步状态。
另一方面,如果采取问题3中的实施方式1,即在SPcell改变过程后,旧的SPcell将保持激活状态,则需要确定如果处理旧的SPcell上的UL UCI和UL HARQ进程,如下所讨论的。为了简化描述,假设在SPcell改变过程后旧的SPcell的UL同步仍将保持。否则,在重新开始旧的SPcell的UL同步后,将考虑下面的实施方式:
问题4.1如何在SPcell改变过程后重新开始UL UCI传输
对于UL传输,关键的问题在于当UE将执行UL传输时,必须确保eNB和UE是同步的,从而eNB可以接收到来自UE的UL传输。在R10/R11中,例如UL SRS/PMI/RI/CQI等的UL UCI传输由RRC消息来配置。接着,eNB将知道UE何时将执行这些UL传输,例如基于UL RRC消息重配置完成消息。然而在R12DC场景中,该策略将不再有效,因为RRC协议仅位于MeNB侧,并且SeNB不知道MeNB何时接收到RRC重配置完成消息。即,SeNB很难知道这些自动的UL UCI传输将何时开始,因此SeNB很难并且不太可能在旧的SPcell上接收到UL UCI传输。为了解决该问题,本公开提出下面的实施方式:
· 实施方式1:UE在新的SPcell上完成上行PRACH过程时将触发UE重新开始在旧的SPcell上的UL UCI传输。类似地,UE也可以根据完成在旧的SPcell上执行上行PRACH过程来触发重新开始在旧的SPcell上的UL UCI传输;
· 实施方式2:UE开始在新的SPcell上进行UL UCI传输时将触发UE在旧的SPcell上重新开始自动化的UL UCI传输;
· 实施方式3:在新的SPcell上接收到首个调度信令(例如,许可)时将触发UE在旧的SPcell上的UL UCI传输。即,在新的SPcell上的首次数据传输将触发UE在旧的SPcell上重新开始UL UCI传输;
· 实施方式4:在旧的SPcell上接收到调度信令或接收到指示旧的SPcell传输的调度信令时将触发UE来在旧的SPcell执行UL UCI传输。即,在旧的SPcell上的首次数据传输将触发在旧的SPcell上重新开始UL UCI传输;
· 实施方式5:设计新的MAC CE,从而SeNB可以通过该MAC CE来请求UE执行在旧的SPcell上的UL UCI传输;
· 实施方式6:通过来自于SeNB的激活/去激活MAC CE来指示UE在旧的SPcell上执行UL UCI传输。对于该实施方式,无论旧的SPcell处于何种状态,如果SeNB希望UE在旧的SPcell上开始UL UCI传输,则SeNB将向下发送指示“激活”状态的激活/去激活MAC CE。而在UE侧处,当接收到该首个MAC CE时,UE将自动地重新开始在旧的SPcell上的UL UCI传输。该实施方式类似于其中UE行为由SeNB控制的实施方式5,但不同之处在于实施方式6为此目的而使用了激活/去激活MAC CE。
对于实施方式1,当UE完成在新的SPcell上的上行PRACH过程时的时间点将用于同步UE和SeNB在旧的SPcell上的UL UCI传输。例如,对于免于竞争的PRACH过程,在发送消息2后,SeNB知道UE将在某个时间段(例如4毫秒)后重新开始在旧的SPcell上执行UL UCI传输。而在UE侧,当在新的SPcell上接收到消息2后,UE将在某个时间段(例如4毫秒)后重新开始在旧的SPcell上执行UL UCI传输。再例如,对于基于竞争的PRACH过程,消息4的传输用作时间点来同步UE和SeNB在旧的SPcell上的UL UCI传输。即,当接收到消息4后,UE将在4毫秒后在旧的SPcell上重新开始UL UCI传输,如图2中的实施方式1所示出的。
对于实施方式2,当UE开始执行在新的SPcell上的UL UCI传输时,无论是由何种实施方式触发,UE将自动地在旧的SPcell上开始进行其UL UCI传输,这是出于SeNB应该知道UE何时将开始在新的SPcell上的UL UCI传输。接着,对于实施方式2,SeNB也将知道UE何时将开始在旧的SPcell上的UL UCI传输。即,UE和SeNB在旧的SPcell上的UL UCI传输中同步。该同步情形可以参见图2中示出的实施方式2。
对于实施方式3,当UE在新的SPcell上接收到调度信令时,UE将利用该接收作为时间点来重新开始其在旧的SPcell上的UL UCI传输。原因在于SeNB知道UE何时在新的SPcell上接收调度信令并且因此SeNB将知道UE何时将开始其在旧的SPcell上的UL UCI传输。即,在新的SPcell上的调度信令的接收用作同步UE和SeNB以便在旧的SPcell执行UL UCI传输。参见图2中的实施方式3中所示出的,在新的SPcell上接收到首个PDCCH后的4毫秒,UE将在旧的SPcell上执行UL UCI传输。
对于实施方式4,当在旧的SPcell上接收到调度信令时或接收到指示在旧的SPcell上传输的调度信令时,UE将在旧的SPcell上重新开始其UL UCI传输。原因与实施方式3类似,因为SeNB知道何时将接收到针对于旧的SPcell的调度信令并且因此SeNB应该也知道UE何时将重新开始在旧的SPcell上的UL UCI传输。参见图2中的实施方式4所示出的,在旧的SPcell上接收的首个PDCCH后的4毫秒,UE将在旧的SPcell上进行UL UCI传输。
上述的实施方式1-4都涉及到UE的自动行为,不同之处在于每个实施方式具有不同的UL UCI传输触发基准或参考。尽管如此,SeNB也可以命令UE来执行UL UCI传输,如实施方式5所建议的。这类似于R10,其中UL UCI传输由RRC过程来触发。即,可以认为R10/R11UL UCI传输是由eNB基于RRC过程来请求的。相比而言,在R12DC中,由于在SeNB处没有RRC协议,本公开建议SeNB通过MAC CE来命令UE重新开始在旧的SPcell上的UL UCI传输。为此,本公开提出一种新的MAC CE,该MAC CE具有比较简单的格式。例如,该MAC CE仅包含MAC CE子报头而不跟随有MAC CE净荷(数据部分),并且子报头仅是一个字节,即R/R/E/LCID,如图3中上一部分所示出的,其中定义一个新的逻辑信道标识(“LCID”),用于指示UE将执行UL UCI传输。可选地,如图3中下一部分所示出,可以在该MAC CE中包括一个字节的MAC CE净荷,其指示UE应该在哪个小区上执行UL UCI传输。该方式是有效的并且简单,因为在SeNB中存在MAC实体。通过上述实施方式,本公开可以获得如R10/R11中由RRC消息来触发UL UCI传输的相同性能。
对于实施方式6,SeNB激活/去激活MAC CE用于触发UE来重新开始在旧的SPcell上的UL UCI传输。因此,本公开定义了新的UE行为:在完成SPcell改变过程后,首个激活/去激活MAC CE将触发UE执行UL UCI传输。
总之,上述实施方式1-6对于引导UE在旧的SPcell上重新开始UL UCI传输是可行的。特别地,实施方式5确保了UE和SeNB在接下来的UL UCI传输中完全同步,从而达到与R10/R11相类似的性能。
问题4.2如何在SPcell改变过程后重新开始UL PUSCH传输
如上所指出的,另一个重要问题是在SPcell改变过程完成后如何处理在旧的SPcell上的先前正在进行的UL PUSCH传输(即,数据传输)。该问题与在执行SPcell改变过程后,在问题1中如何在旧的SPcell上处理UL同步的实施方式有关,以及在问题2中如何处理旧的SPcell的激活/去激活状态的实施方式有关。如果采取问题2中的实施方式2或采取实施方式3但由SeNB请求去激活旧的SPcell,则UE应该释放所有正在进行的UL HARQ进程并且也释放所有相关的HARQ缓冲器信息。
另一方面,如果在SPcell改变过程后认为旧的SPcell处于激活状态,则本公开建议执行下面的操作来处理在旧的SPcell上执行先前正在进行的UL PUSCH。下面的讨论基于假设确认了UE和旧的SPcell的UL同步。
· 实施方式1:尽管在SPcell改变过程完成后,旧的SPcell被保持为激活状态,但UE将释放所有正在进行的ULHARQ进程和释放所有的UL HARQ缓冲器;
· 实施方式2:UE维持和暂停所有正在进行的UL HARQ进程。另外,UE将保持针对于此前接收到NACK的HARQ进程的所有UL HARQ缓冲器。在UE成功地完成在新的SPcell上的UL PRACH过程后,UE将自动地在旧的SPcell上重新开始UL传输(非自适应HARQ重传);
· 实施方式3:类似于实施方式2,UE维持和暂停所有正在进行的UL HARQ进程。另外,UE将保持针对于此前接收到NACK的HARQ进程的所有UL HARQ缓冲器。在UE成功地完成在新的SPcell接收到首个调度信令后,UE将自动地重新开始在旧的SPcell上的UL非自适应重传;
· 实施方式4:类似于实施方式2,UE维持和暂停所有正在进行的UL HARQ进程。另外,UE将保持针对于此前接收到NACK的HARQ进程的所有UL HARQ缓冲器。但不同于实施方式2,UE应该等待来自于SeNB的进一步UL调度信令,以便重新开始UL重传或释放这些保存的UL HARQ缓冲器。即,在旧的SPcell上接收到的首个UL调度信令将重新开始UE的所有暂停的UL HARQ进程操作。
· 实施方式5:类似于实施方式2,UE将保持针对于先前接收到的NACK的HARQ进程的所有UL HARQ缓冲器。但不同于实施方式2,UE应该等待来自于SeNB的进一步UL调度信令,以便重新开始UL重传或释放相应的ULHARQ缓冲器。即,在旧的SPcell上接收到的UL调度信令将仅重新开始相应的UL HARQ进程操作。如果没有接收到相应的UL调度信令,则UE应该继续暂停其他的HARQ进程。
对于实施方式1,在完成SPcell改变过程后,即使旧的SPcell仍处于激活状态中,UE释放所有正在进行的UL HARQ缓冲器。因此,该实施方式将导致不必要的冗余重传但具有相对简化的优势。
对于实施方式2,维护UL HARQ缓冲器和正在进行的UL HARQ进程。当UE在新的SPcell上完成上行PRACH过程后,UE将对于那些先前接收到NACK的UL HARQ进程自动地开始在旧的SPcell上的非自适应UL HARQ重传。对于该实施方式,消息2或消息4的接收将用作同步SeNB和UE在旧的SPcell上的UL传输的时间点,如图4中所示出的。
对于实施方式3,其类似于实施方式2,而不同之处在于当在新的SPcell上接收到首个调度信令时,UE将重新开始其在旧的SPcell上的UL非自适应HARQ重传。即,在新的SPcell上的首个调度信令将用作同步SeNB和UE在旧的SPcell上的UL HARQ重传的时间点,如图5中所示出的。
对于实施方式4,UE将不重新开始其UL HARQ操作,直到在旧的SPcell上接收到首个调度信令。对于该实施方式,仅一个调度信令将重新开始所有当前暂停的UL HARQ进程。例如,在UE基于接收到TTI i中的UL许可来执行相应的UL HARQ传输后,即使没有接收到进一步的UL许可,UE将继续在后续的TTI中执行非自适应的UL HARQ重传,如图6中所示出的。
对于实施方式5,UE将保持和维护所有正在进行的UL HARQ进程。UE将不会重新开始暂停的UL HARQ进程,直到在旧的SPcell上接收到相应的UL调度信令。即,当在旧的SPcell上接收到UL调度信令时,UE将仅重新开始相对应的UL HARQ进程,但继续保持其他的UL HARQ暂停。这意味着一个UL调度信令将仅重新开始一个UL HARQ进程,这明显不同于实施方式4。如图7中所示,假设首个调度信令关联于UL HARQ进程i,则UE将通过根据接收到的调度信令来执行自适应的重传或执行新的传输,而重新开始ULHARQ进程。在下一TTI中,由于没有接收到相应的调度信令,UE将继续暂停UL HARQ进程i+1,如图中“X”所指示的。在后续的TTI中,由于再次接收到调度信令,UE将进一步重新开始UL HARQ进程i+2并且执行由接收到的调度信令所指示的自适应重传或新的传输,并且相同的过程将持续进行。应当理解的是这里的进程表示i、i+1、i+2或i+n等仅仅是示例性的,并且n依起始基准位置的不同而可以取合适的值。
总之,实施方式1-5对于在旧的SPcell上重新开始暂停的ULHARQ进程是可行的,因为SeNB和UE同步在当UE应该在旧的SPcell上重新开始UL传输的时间点上。
图8示意性示出根据本公开的实施方式的方法800的流程图。如前所述,该方法800在支持用户设备与宏基站和小型基站的双连接的无线通信网络中使用,如图1中所示出的示例性无线通信网络。如图8中所示,方法800开始于步骤S801,并且前进到步骤S802,在该步骤处,在发生从旧的特殊小区到新的特殊小区的改变的情形下,在所述用户设备处执行一个或多个动作以处理所述旧的特殊小区的先前传输。接着,方法800在步骤S803处结束。
在一个实施方式中,其中在所述用户设备处执行的一个或多个动作涉及所述旧的特殊小区的UL同步状态。
在一个实施方式中,该方法800进一步包括停止定时提前定时器以及确定所述旧的特殊小区的UL同步为无效。
在另一个实施方式中,所述方法800进一步包括检查定时提前定时器的状态,响应于所述定时提前定时器仍在运行,确定所述旧的特殊小区的UL同步为有效;以及响应于所述定时提前定时器在特殊小区改变过程中停止或到期,确定所述旧的特殊小区的UL同步为无效。
在又一个实施方式中,所述方法800进一步包括响应于完成特殊小区重配置过程,重新启动定时提前定时器并且确定所述旧的特殊小区的UL同步为有效。
在一个实施方式中,所述方法800进一步包括基于来自基站的指示对定时提前定时器执行操作,以便基于所述操作来确定所述旧的特殊小区的UL同步为有效或无效。
在另一个实施方式中,其中在所述用户设备处执行的一个或多个动作涉及所述旧的特殊小区的相对于所述用户设备的激活或去激活状态。
在又一实施方式中,所述方法800进一步包括确定所述旧的特殊小区相对于所述用户设备处于所述激活状态以及启动小区去激活定时器。
在一个实施方式中,所述方法800进一步包括确定所述旧的特殊小区相对于所述用户设备处于所述去激活状态。
在又一实施方式中,所述方法800进一步包括基于来自基站的指示来确定所述旧的特殊小区相对于所述用户设备处于所述激活或去激活状态。
在一个实施方式中,其中在所述用户设备处执行的一个或多个动作涉及所述旧的特殊小区的先前下行链路传输。
在又一实施方式中,其中所述旧的特殊小区相对于所述用户设备处于激活状态,所述方法进一步包括以下中的一项:释放在所述旧的特殊小区上正在进行的下行链路混合自动重传请求进程并且释放所有相关的下行链路混合自动重传请求缓冲器;保持所述下行链路混合自动重传请求进程和相关的缓冲器直到相应的下行链路传输被正确接收;在特殊小区改变过程后,响应于在所述旧的特殊小区上接收到下行链路调度信令,将新接收的下行链路传输和缓冲的信息合并;以及在特殊小区改变过程后,响应于从所述小型基站接收到新的下行链路传输,释放来自于所述旧的特殊小区的缓冲的信息。
在另一实施方式中,其中所述旧的特殊小区相对于所述用户设备处于去激活状态,所述方法进一步包括释放针对所述旧的特殊小区的所有下行链路混合自动重传请求缓冲器和下行链路混合自动重复请求进程;以及等待所述小型基站调度新的传输。
在又一实施方式中,其中在所述用户设备处执行的一个或多个动作涉及所述旧的特殊小区的先前UL传输。
在另一实施方式中,其中所述先前UL传输包括UL UCI传输,所述方法进一步包括以下中的一项:响应于完成在所述新的特殊小区上的UL随机接入过程,触发在所述旧的特殊小区上的所述UL UCI传输;响应于完成在所述旧的特殊小区上的UL随机接入过程,触发在所述旧的特殊小区上的所述UL UCI传输,其中所述UL随机接入过程用于所述用户设备和所述小型基站之间的UL同步;响应于在所述新的特殊小区上的UL UCI传输,触发在所述旧的特殊小区上的所述UL UCI传输;响应于在所述新的特殊小区上接收到首个调度信令,触发在所述旧的特殊小区上的所述UL UCI传输;响应于在所述旧的特殊小区上接收到调度信令或响应于接收到关于所述旧的特殊小区的调度信令,触发在所述旧的特殊小区上的所述UL UCI传输;以及响应于接收到来自于基站在介质访问控制控制单元中传输的指示,触发在所述旧的特殊小区上的所述UL UCI传输。
在一个实施方式中,其中所述先前UL传输包括UL上行数据信息传输,并且所述旧的特殊小区处于激活状态,所述方法进一步包括以下中的一项:释放与所述旧的特殊小区相关的所有正在进行的UL混合自动重传请求进程和UL混合自动重传请求缓冲器;以及暂停与所述旧的特殊小区相关的所有正在进行的UL混合自动重传请求进程并且保留对于接收到否定确认的UL混合自动重传请求进程的所有UL混合自动重传请求缓冲器,以便执行以下之一:响应于成功接入到所述新的特殊小区,重新开始在所述旧的特殊小区上的UL传输;响应于在成功接收到来自所述新的特殊小区的首个调度信令,重新开始在所述旧的特殊小区上的非自适应重传;响应于在所述旧的特殊小区上接收到首个UL信令,重新开始在所述旧的特殊小区上的所有暂停的UL混合自动重传请求进程;响应于完成在所述旧的特殊小区上的UL随机接入过程,触发在所述旧的特殊小区上的所述UL上行数据信息传输,其中所述上行链路随机接入过程用于所述用户设备和所述小型基站之间的UL同步;以及响应于在所述旧的特殊小区上接收到与暂停的UL混合自动重传请求进程相关联的UL信令,重新开始在所述旧的特殊小区上的所述暂停的UL混合自动重传请求进程。
在另一实施方式中,其中在从所述旧的特殊小区到所述新的特殊小区的改变过程中,所述方法包括释放所述旧的特殊小区。如前所述,这里的释放可以是接收到来自于小型基站的指示,从而用户设备可以依该指示来释放旧的特殊小区。附加地,用户设备也可以依该指示来保持该旧的特殊小区。
在又一实施方式中,所述释放所述旧的特殊小区包括以下至少一项:释放与所述旧的特殊小区相关的所有UL UCI配置;释放与所述旧的特殊小区相关的所有上行或下行混合自动重复请求进程;以及释放与所述旧的特殊小区相关的所有上行或下行混合自动重复请求缓冲器。
在一个实施方式中,其中所述先前UL传输包括UL上行数据信息传输,并且所述旧的特殊小区处于非激活状态,所述方法进一步包括释放与所述旧的特殊小区相关的所有正在进行的UL混合自动重传请求进程和UL混合自动重传请求缓冲器。
图9是示意性示出根据本公开实施方式的在支持双连接的无线通信系统中使用的设备900的框图。如前所述,该设备900使用在支持用户设备与宏基站和小型基站的双连接的无线通信网络中,其中所述小型基站至少包括配置用于所述用户设备的物理UL控制信道传输的一个特殊小区。如图9所示,所述设备900包括:执行单元901,用于在发生从旧的特殊小区到新的特殊小区的改变的情形下,在所述用户设备处执行一个或多个动作以处理所述旧的特殊小区的先前传输。应该理解的是这里的设备900可以实现为用户设备或其一部分,并且可以配置成执行根据图8所示出的方法800及其多个实施方式。即,本公开的另一方面提供一种用于执行上述方法800的UE。
综上,结合附图对本公开的各个实施方式进行了详细的描述。本领域技术人员可以理解本公开的实施方式可以通过硬件、软件、固件、模块或者其结合来实现,也可以在供任何合适数据处理系统使用的信号承载介质上所设置的计算机程序产品中体现本公开。这种信号承载介质可以是传输介质或用于机器可读信息的可记录介质,包括磁介质、光介质或其他合适介质。可记录介质的示例包括:硬盘驱动器中的磁盘或软盘、用于光驱的光盘、磁带,以及本领域技术人员所能想到的其他介质。本领域技术人员应该认识到,具有合适编程装置的合适通信设备都将能够执行如程序产品中体现的本公开方法的步骤。
应当注意,为了使本公开更容易理解,上面的描述省略了对于本领域的技术人员来说是公知的、并且对于本公开的实现可能是必需的更具体的一些技术细节。
尽管已经公开了本公开的特定实施方式,但本领域技术人员将理解可针对特定的实施方式做出改变而不会偏离本公开的精神和范围。因此,本公开不限于特定的实施方式,并且所附权利要求包含本公开范围内的任何和所有这样的应用、修改和实施方式。