背景技术
随着通信技术的发展,LTE-A(Long Term Evolution Advanced,高级长期演进)***的峰值速率较LTE(Long Term Evolution,长期演进)有很大的提高,要求达到下行1Gbps,上行500Mbps。同时,LTE-A***要求和LTE***有很好的兼容性。基于提高峰值速率、与LTE***兼容以及充分利用频谱资源的需要,LTE-A***引入了CA(Carrier Aggregation,载波聚合)技术。
载波聚合技术是终端可以在多个cell(小区)上同时工作,一个cell包含一对UL/DL(Uplink/Downlink,上行/下行)CC(Component Carrier,成员载波),而不是LTE***以及之前的无线通信***中只有一套载波的模式。在载波聚合的***中各个成员载波可以是连续,也可以是非连续的,各成员载波的带宽可以相同或不同,为了保持和LTE***兼容,每个成员载波的最大带宽限制为20MHz,目前一般认为CC最大个数为5个。
此外,LTE-A还对cell进行了分类,分为:
(1)Primary cell(主小区),在UE(User Equipment,用户设备)聚合的cell中只有一个cell被定义为Primary cell。
(2)Secondary cell(辅小区),是指UE聚合的除了Primary cell之外的其它cell。
Primary cell由基站选择并通过RRC(Radio Resource Control,无线资源控制)信令配置给终端,不同终端的Primary cell可以不同。Primary cell的UL CC上配置有PUCCH(Physical Uplink Control Channel,物理上行控制信道),其它Secondary cell的UL CC不存在PUCCH。
在现有技术中,LTE***中MAC(Media Access Control,媒体接入控制)层的分组数据单元(Packet Data Unit,PDU)的结构示意图如图1所示。
该图中标识出一个MAC PDU中包括MAC头(MAC header)、MAC SDU(Service Data Units,服务数据单元)、MAC CE(Control Element,控制元)和padding(填充位)的情况。
MAC PDU具有如下基本特点:
MAC头由一个或多个MAC子头组成,每个MAC子头对应一个MAC SDU或者MAC CE或者padding;
MAC头和MAC SDU长度可变;
MAC子头、MAC SDU、MAC CE都要求字节对齐(byte alignment);
MAC PDU的比特流从高位到低位的顺序与协议中MAC PDU结构图的对应关系是:从左到右,从上到下的读取顺序;
MAC CE/MAC SDU/padding在MAC PDU中的顺序如下:MAC CE在最前面,但是,padding BSR(Buffer Status Reports,缓冲状态报告)MAC CE例外,然后是MAC SDU,然后是padding(padding BSR位于MAC PDU的最后);
MAC CE/MAC SDU/padding各自对应的子头在MAC头中的顺序与其在MAC PDU中的顺序一致;
PHR(功率余量上报,Power Headroom Reporting)是UE向基站报告UE发送功率和最大功率之间差值的一种机制。
在LTERel-8/9***中,PH(功率余量,Power Headroom)的定义是针对PUSCH(Physical Uplink Shared Channel,物理上行共享信道)的,定义如下:
PH=PCmax-PPUSCH
其中,
PCmax是终端满足射频指标情况下能够允许的最大发射功率。
PPUSCH为终端的发射功率。
LTE Rel-8/9***中,PH通过PHR MAC CE上报,PHR MAC CE包括一个MAC子头和一个MAC CE,其结构示意图分别如图2和图3所示。
其中,各域的含义如下:
LCID(Logical Channel Identity,逻辑信道标识)域:用于标识对应负荷部分的逻辑信道号,对于PHR过程来说,LCID用于标识对应的负荷部分为PHR。LTE Rel-8/9 PHR对应的LCID为11010,如表1所示:
表1上行LCID标识
Index |
LCID values |
00000 |
CCCH |
00001-01010 |
Identity of the logical channel |
01011-11001 |
Reserved |
11010 |
Power Headroom Report |
11011 |
C-RNTI |
11100 |
Truncated BSR |
11101 |
Short BSR |
11110 |
Long BSR |
11111 |
Padding |
其中,
E域:扩展比特,用于指示下一个byte是MAC子头还是MAC负荷。
R域:预留比特。
PH域:上行功率余量。
进一步的,对在LTE-A***中的PHR机制进行说明如下:
一、PH计算机制
目前,一般认为LTE-A中有两种PH计算方式:
方式一、Per CC PHR(基于CC上报PHR)
在该方式中,PH计算针对CC,由于PUCCH信道配置的不同,LTE-A针对Primary cell和Secondary cell定义了不同类型的PHR,具体如下:
(1)对于Primary cell定义了Type1和Type2两种类型的PHR,其中:
Type 1:PHRPUSCH=Pcmax,c-PPUSCH
Type 2:PHRPUCCH+PUSCH=Pcmax,c-PPUSCH-PPUCCH
(2)对于Secondary cell,由于其UL CC不存在PUCCH,因此,只定义了Type1 PHR:
Type 1:PHRPUSCH=Pcmax,c-PPUSCH
方式二、Per UE PHR(基于UE上报PHR)
目前公式还没有确定。一种可能的方式就是:
PHRUE=Pcmax-PPUSCH1-PPUSCH2-....-PPUSCHn-PPUCCH-multiple_CC_MPR
其中:
PPUSCHn:为配置给UE的载波CCn上PUSCH功率;
multiple_CC_MPR:为多个CC一起发送而引起的MPR(Maximum Power Reduction,最大功率削减);
不管是方式一的per CC PHR,还是方式二的per UE PHR都需考虑需要上报UE哪些UL CC的PHR,一般有三种选择:
(1)根据基站为UE配置的所有UL CC个数确定n;
(2)根据基站为UE配置且激活的UL CC个数确定n;
(3)根据基站为UE分配了UL grant的UL CC个数确定n;
对于前两种情况,当UE在某个UL CC上没有真实的PUCCH或PUSCH出现时,目前的一种方法是引入“虚拟PUCCH或者PUSCH”的概念。即采用某种参考格式计算虚拟PUCCH或PUSCH的功率。也就是说如果UE收不到grant,则会按照虚拟的PUCCH或PUSCH参考格式算出一个虚拟的PHR,只有收到真正的UL grant时才会上报真实的PHR。
二、PH上报机制
目前,关于Primary cell和Secondary cell上上报的PHR Type的结论如下:
(1)Secondary cell上只上报Type 1 PHR。
(2)在Primary cell上,当PUCCH和PUSCH一起出现时,Type1 PHR和Type2的PHR要同时上报。
(3)在Primary cell上,当PUCCH和PUSCH不同时出现时,Type1和Type2的PHR是否同时上报目前没有结论。
LTE-A***目前倾向于一旦UE有PHR被触发,那么所有CC上的per CC PHR一起同时上报,此外,也有公司建议,在所有CC上的per CC PHR一起同时上报的同时,还要一起上报per UE PHR。
在实现本发明实施例的过程中,申请人发现现有技术至少存在以下问题:
相对于LTE Rel-8/9,LTE-A多载波***中PH上报需要包含更多信息,比如:
(1)LTE-A CA UE需要上报多个CC的PH信息而且CC个数可以半静态或者动态变化。
(2)CA UE的PHR触发机制可能是UE级别的,即一旦满足PHR触发条件,则UE在需要上报PHR的时刻需要同时把多个CC的per CC PH信息都上报给基站。
(3)Primary cell需要区分Type1 PHR和Type2 PHR是否同时上报。
(4)若有per UE PHR的出现,还需要区分UE PH和CC PH信息。
此外,如果PH基于UE所有有UL grant的UL CC进行上报,还会引入另外一个问题,即如果基站发送了UL grant,而UE没有接收到,则这时UE将采用虚拟的PHR,而基站收到PHR会以为这是真实的PHR,这样会造成基站和UE理解的不一致,因此,PHR需要区分是真实的还是虚拟的。
综上,LTE Rel-8/9的PHR MAC CE的格式已经不适用,需要为CA***考虑新的PHR MAC CE格式。
具体实施方式
如背景技术所述,在LTE-A***中,为了支持更高的峰值速率,引入了CA技术,在此种情况下,多载波***中如何进行PHR需要考虑,一种比较可能的方式就是基于UE上报PHR,即只要有PHR被触发,那么终端所有配置或者配置且激活或者有UL grant(上行调度许可指示)的UL CC一起上报PHR,但现有的功率余量上报方案由于存在所携带的信息有限,不能满足这样的上报过程的要求。
基于此,本发明实施例给出了一种确定PHR MAC CE格式的技术方案,通过对PHR MAC CA和MAC子头中的信息形式的调整,使其能够在携带各上行成员载波的功率余量的同时,以具体的指示信息和策略处理使基站准确的获取到相应的功率余量。
如图4所示,为本发明实施例所提出的一种载波聚合场景下的功率余量上报方法的流程示意图,具体包括以下步骤:
步骤S401、终端设备根据预设的PHR MAC CE长度确定策略,确定需要上报的PHR MAC CE的长度。
在具体的应用场景中,根据预设的PHR MAC CE长度确定策略的区别,本步骤的具体实现过程包括以下两种:
策略一、PHR MAC CE的长度可变
终端设备根据当前需要上报功率余量的上行成员载波的数量和需要上报的功率余量的类型,确定当前需要上报的PHR MAC CE的长度。
其中,当前需要上报功率余量的上行成员载波,具体通过以下方式确定:
(1)终端设备确定基站为其配置的所有上行成员载波为当前需要上报功率余量的上行成员载波。
(2)终端设备确定基站为其配置且处于激活状态的所有上行成员载波为当前需要上报功率余量的上行成员载波。
此种情况需要基于的前提是上行成员载波支持激活和去激活特性。
(3)终端设备根据当前接收到的上行调度许可指示(UL grant),确定上行调度许可指示所对应的各上行成员载波为当前需要上报功率余量的上行成员载波。
策略二、PHRMAC CE的长度固定
终端设备根据***支持的上行成员载波的数量和需要上报的功率余量的类型,确定需要上报的PHR MAC CE的固定长度。
策略一和策略二中所述的功率余量类型包括Type1 PHR,和/或Type2 PHR,和/或UE PHR,其具体的定义与现有的标准相类似,在此不再重复说明。
步骤S402、终端设备根据确定的PHR MAC CE的长度,生成PHR MAC CE。
其中,PHR MAC CE中包含需要上报功率余量的各载波所对应的功率余量和/或UE的功率余量。
需要指出的是,对应前述的步骤S401中的策略一,当PHR MAC CE的长度可变时,为了使基站获知PHR MAC CE的长度信息,从而准确获取功率余量,本步骤中还进一步包括以下的至少一种处理过程:
(1)终端设备生成PHR MAC CE所对应的MAC子头,MAC子头包含长度指示域,长度指示域中包含终端设备所确定的PHR MAC CE的长度。
(2)终端设备在PHR MAC CE中添加成员载波索引信息,成员载波索引信息包括PHR MAC CE中是否携带当前需要上报功率余量的各上行成员载波的功率余量的指示信息,以及PHR MAC CE中所携带的各功率余量的类型信息。
通过成员载波索引信息,基站可以准确的知道PHR MAC CE中携带了哪些上行成员载波的功率余量,是否包含UE的功率余量以及这些功率余量的类型,从而确定该PHR MAC CE的长度。
例如,在PHR MAC CE加入CC index,和/或CC上包含的PHR类型(为区分Type1和Type 2 PH使用,如果某个CC上只可能有一种类型的PHR上报,则可以选择不指示),和/或UE PH信息。
(3)终端设备与基站中设置相同的PHR MAC CE长度确定策略,基站根据PHR MAC CE长度确定策略直接确定PHR MAC CE的长度。
这是一种隐式的通知方式,终端设备无需向基站发送任何的PHR MAC CE长度信息,但基站可以根据与终端设备相同的策略确定相同的PHR MAC CE长度结果。
例如,基站根据当前为UE配置,或配置且激活,或有UL grant的UL CC个数以及需要上报的PHR类型确定PHR MAC CE长度。
另一方面,对应前述的步骤S401中的策略二,当PHR MAC CE的长度固定时,为了使基站获知PHR MAC CE的长度信息,从而准确获取功率余量,本步骤中还进一步包括以下的至少一种处理过程:
(1)终端设备在PHR MAC CE中添加成员载波索引信息,成员载波索引信息包括PHR MAC CE中是否携带***支持的各上行成员载波的功率余量的指示信息,是否携带UE的PHR信息以及PHR MAC CE中所携带的各功率余量的类型信息。
(2)终端设备与基站设置相同的PHR MAC CE长度确定策略和各功率余量的排列顺序,基站根据PHR MAC CE长度确定策略直接确定PHR MAC CE的长度,并按照各功率余量的排列顺序,获取相对应的功率余量。
在此种情况下,由于在具体的应用场景中,可能会存在没有功率余量上报的上行成员载波(例如没有配置给该终端设备的上行成员载波或没有激活的上行成员载波等),所以,终端设备需要按照各功率余量的排列顺序,通过***支持的各上行成员载波所对应的预留比特位的取值或者功率余量域的取值来识别上行成员载波是否有功率余量上报。
例如,每个上行成员载波的各个类型的PH信息是按照预定义顺序进行排列,位置固定,比如先放置Per CC的PHR,然后放置Per UE的PHR,Per CC的PHR按照cell index升序或者降序排序。这样的顺序设定同样适用于上述的策略一,即无论PHR MAC CE的长度是否可变,均可以对PHR MAC CE中的功率余量的排列顺序进行设定,可以按照CC升序或者降序排列,也可以进一步将UE PH可以在最前面或最后面,并且,还可以进一步设置成员载波索引信息的位置。
需要进一步指出的是,无论对于上述的哪种策略,由于终端设备还可能一步上报虚拟功率余量,所以,为了使基站能够准确的区分功率余量是真实信息还是虚拟信息,本步骤中还需要为此建立相应的标识信息,具体说明如下:
如果终端设备不允许上报虚拟功率余量,那么只需要在终端设备和基站侧同时确认该策略,则基站无需再进行相应的区分,所收到的功率余量肯定全是真实值。
而如果终端设备允许上报虚拟功率余量,那么,相应的处理方式包括以下几种:
(1)终端设备可以在PHR MAC CE中添加了成员载波索引信息,指示PHR MAC CE中所携带的各功率余量是否为虚拟功率余量,以使基站据此进行识别。
(2)如果终端设备在PHR MAC CE中没有添加成员载波索引信息,那么,终端设备可以通过PHR MAC CE中所包含的各功率余量所对应的预留比特位的取值确定功率余量是否为虚拟功率余量。
(3)终端设备与基站中获取相同的资源分配状态,基站根据资源分配状态确定PHR MAC CE中所携带的各功率余量是否为虚拟功率余量,即根据基站的PUCCH资源配置情况以及PUSCH资源分配情况确定PHR MAC CE中所携带的各功率余量是否为虚拟功率余量。
这同样是一种隐式的通知方式,终端设备无需向基站发送任何关于虚拟功率余量的指示信息,而基站则可以直接根据资源分配状态确定PHR MAC CE中所携带的各功率余量是否为虚拟功率余量。
另外,为了准确的使基站确定各功率余量的类型,终端设备还可以通过以下方式将相应的功率余量的类型通知给基站,在具体的应用场景中,与现有技术相类似,功率余量的类型包括以下几种:
类型一、Secondary cell对应的UL CC上的Type 1 PH。
类型二、Primary cell对应的UL CC上的Type 1 PH。
类型三、Primary cell对应的UL CC上的Type 2 PH。
需要指出的是,此种类型为可选类型,该类型是否出现取决于标准中确定的Type2 PHR的上报规则,比如,如果在Primary cell上同时有PUCCH和PUSCH传输,则一定会同时上报Type1和Type2 PHR。
类型四、UE PH。
需要指出的是,此种类型同样为可选类型,如果标准中定义了UE PHR,那么可能需要和per CC的PHR一起上报,当然也可以为UE PH单独定义一个PHR MAC CE。
基于上述的功率余量的类型划分,本发明实施例中所提出的类型通知方式,具体说明如下:
(1)终端设备通过MAC子头中包含的LCID的内容,标识PHR MAC CE中所携带的功率余量的类型。
比如,利用LCID区分PHR MAC CE中的Type 1和Type 2 PHR,LCID的具体形式可以如表2所示:
表2利用LCID区分Pcell上是否同时传输Type1和Type2 PHR
(2)终端设备通过PHR MAC CE中所包含的各功率余量所对应的预留比特位的取值指示功率余量的类型。
即用PHR MAC CE中PH值前的2个预留比特位(R比特)来实现相应的通知,具体如表3所示:
表3利用R bit区分PH类型
Rbit取值 |
PHR Type |
00 |
Type1 |
01 |
Type2 |
10 |
Reserved |
11 |
UE |
步骤S403、终端设备向基站发送包含PHR MAC CE和PHR MAC CE所对应的MAC子头的MAC PDU。
需要进一步指出的是,为了更好的实现与现有技术的兼容,终端设备还可以通过MAC子头中包含的LCID的内容,指示PHR MAC CE针对的***类型,从而使基站确定当前收到的是根据上述技术方案得到的多载波***的PHR MAC CE,还是现有LTE***的PHR MAC CE,从而进行相应的处理。
上述过程为本发明实施例所提出的一种载波聚合场景下的功率余量上报方法在终端侧的实现流程,下面,本发明实施例进一步给出了一种载波聚合场景下的功率余量上报方法在基站侧的实现流程,其流程示意图如图5所示,具体包括以下步骤:
步骤S501、基站接收终端设备上报的包含PHR MAC CE和PHR MAC CE所对应的MAC子头的MAC PDU。
步骤S502、基站根据预设的策略识别PHR MAC CE的长度。
在具体的应用场景中,本步骤的实现包括以下三种情况:
(1)基站根据MAC子头的长度指示域中的信息确定PHRMAC CE的长度。
(2)基站根据PHR MAC CE中的成员载波索引信息确定PHR MAC CE的长度。
(3)当PHR MAC CE的长度固定时,基站根据***支持的上行成员载波的数量和各上行成员载波需要上报的功率余量的类型,确定PHR MAC CE的固定长度。
具体应用上述的哪种方式,可以依赖于预先的设定,也可以并不预先确定具体应用哪一种,而是根据终端设备侧所发送的具体信息进行识别,从而选择最合适的一种方式进行处理。
步骤S503、基站根据PHR MAC CE的长度,在PHR MAC CE中获取终端设备上报的各上行成员载波的功率余量。
在具体的应用场景中,本步骤的实现包括:
(1)基站根据MAC子头的LCID的信息,或PHR MAC CE中的成员载波索引信息,或PHR MAC CE中所包含的各功率余量所对应的预留比特位的取值,确定终端设备上报的各上行成员载波的功率余量的类型,并在PHR MAC CE中获取终端设备上报的各上行成员载波的功率余量。
(2)当PHR MAC CE的长度固定时,基站按照预设的PHR MAC CE中各功率余量的排列顺序,在PHR MAC CE中获取终端设备上报的各上行成员载波的功率余量。
需要指出的是,在上述的功率余量的获取过程中,还包括该功率余量是否为虚拟功率余量的识别过程,具体识别方式包括以下两种:
方式一、基站根据MAC子头的LCID的信息,或PHR MAC CE中的成员载波索引信息,或PHR MAC CE中所包含的各功率余量所对应的预留比特位的取值,确定PHR MAC CE中所携带的各功率余量是否为虚拟功率余量。
方式二、基站根据当前资源分配状态确定PHR MAC CE中所携带的各功率余量是否为虚拟功率余量。
需要进一步指出的是,与前述的技术过程相类似,为了更好的实现与现有技术的兼容,基站还可以通过MAC子头中包含的LCID的内容识别PHR MAC CE针对的***类型,确定当前收到的是根据上述技术方案得到的多载波***的PHR MAC CE,还是现有LTE***的PHR MAC CE,从而进行相应的处理。
与现有技术相比,本发明实施例具有以下优点:
通过应用本发明实施例的技术方案,可以根据需要上报功率余量的上行上行成员载波数量和需要上报的功率余量类型,确定PHR MAC CE和相对应的MAC子头,并在其中携带PHR MAC CE长度信息、和/或功率余量类型信息、和/或是否为虚拟功率余量等指示信息,以使基站能够准确的获取到各上行成员载波的功率余量,从而,解决了目前现有的LTE Rel-8/9中PHR MAC CE格式对LTE-A***不适用的问题。
下面,结合具体的应用场景,对本发明实施例所提出的技术方案进行说明。
首先,结合前述的技术方案,本发明实施例给出以下的PHR MAC CE的格式示例。
对应前述的步骤S401中的策略一,在PHR MAC CE长度可变的情况下,PHR MAC CE的格式示例如下:
格式示例一
在PHR MAC CE长度取决于当前需要上报PH的个数,且不允许上报包含invalid PH的信息的情况下。各个CC的PH的排列顺序,以及各种PH类型的排列顺序推荐如图6所示,当然,这仅是本发明实施例的一种优选示例,其它顺序的排列方式也可以应用于本发明实施例所提出的技术方案中。
eNB根据当前配置或者激活的CC个数或有UL grant的UL CC个数以及PHR类型来确定具体长度的大小。
格式示例二
当终端设备按照配置,或者激活,或者有UL grant的UL CC个数确定PHR长度时,为了避免基站和终端设备对于要PHR MAC CE长度理解不一致,可以在PHR MAC CE对应的MAC子头中增加长度指示域,PHR MAC CE的格式保持和格式示例一相同,而MAC子头的格式如图7所示,其中,L域为长度指示域。
格式示例三
基于格式示例一,进一步在PHR MAC CE中用bitmap方式增加所包含的CC索引。
Bitmap的方式可以有如下两种:
(1)按照CC index用0/1来表示是否有PH,对于一个CC有多个类型PHR上报以及是否存在UE PHR的情况,基站可以通过隐式方式确定。
(2)按照CC index,各个CC要上报的PHR Type,以及是否有UE PHR,统一进行bitmap,来表示是否包含PH。
当然各个CC对应的bitmap位置可以调整,只要保证基站和终端理解一致即可。比如:假设***支持5个CC,CC1为Pcell,要上报的PHR MAC CE包含CC 1/CC2/CC3的PHR,则方法(2)的示意如图8所示。
在该方式中,为了避免基站和终端对MAC CE长度理解不一致,PHRMAC CE子头也可以采用格式示例二中的格式。
基于格式示例一,对于UE按照配置的UL CC或者激活的UL CC上报PHR时,如果要求能够区分哪些UL CC上的PHR是基于虚拟PUSCH/PUCCH计算出来的,则进一步包括以下两种格式示例:
格式示例四
如图9所示,Bitmap可以按照UL CC的Cell index用0/1来表示是否是由虚拟PUSCH或者PUCCH计算出来的,对于Pcell可能需要占用2bit,分别表示Type1和Type2 PHR是否由虚拟PUSCH或者PUCCH计算得到的。此外,如果还有UE PHR,还可以用1bit指示UE PHR是否是虚拟的。
格式示例五
对于Scell,由于只有Type1 PHR上报,因此可以利用PH前面的两个Rbit区分PH是否是由虚拟PUSCH计算出来的。对于Pcell,如过Type1和Type2一定同时上报,那么就不需要用Rbit区分Type1和Type2 PHR,只要固定其在MAC CE中的位置即可,这种情况下也可以用R bit区分Pcell上的PH是否由虚拟PUCCH或者PUSCH计算出来的。
以只区分Scell上的PH是否由虚拟PUSCH计算得到的为例,Rbit取值可以如表4所示:
表4Rbit取值示意
Rbit取值 |
PHR Type |
00 |
Type1(表示Scell上的PH由真实PUSCH计算出来的) |
01 |
Type2 |
10 |
Type1(表示Scell上的PH是由虚拟PUSCH计算出来的) |
11 |
UE |
需要注意的是,如果利用Rbit区分PH是否是由虚拟PUSCH计算出来的,同样可以用于per CC PHR分别上报的场景。
对应前述的步骤S401中的策略二,在PHR MAC CE长度固定的情况下,PHR MAC CE的格式示例如下:
格式示例六
PHR MAC CE长度取决于***支持的UL CC个数,允许包含invalid PH的信息。各个CC的PH的排列顺序,以及各种PH类型的排列顺序推荐如图10所示(设***支持5个UL CC)。
格式示例七
基于格式示例六,如果要在MAC CE中区分哪些cell的PH是采用虚拟PUSCH/PUCCH计算出来的。可以有如下两种方式:
(1)Bitmap的方式:
可以按照cell的Cell index用0/1来表示是否是由虚拟PUSCH/PUCCH计算出来的。具体如图11所示。
(2)利用Rbit的方式:
由于Scell上只有Type1 PHR,因此可以利用Rbit表示该PH是否由虚拟PUSCH计算出来的。这种方式下PHR MAC CE格式和格式示例六一致。当然如果Pcell上一定同时有Type1和Type2 PHR,那么就无需用R bit区分Type1和Type2 PHR,这种情况下就可以用R bit来区分Type1和Type2 PHR是否由虚拟PUCCH/PUSCH计算出来的了。
需要进一步指出的是,对于以上的各个格式示例,需要说明的是,各个CC PH以及UE PH在MAC CE中的位置,以及CC bitmap的位置可以任意调整,只要预先定义好,能够保证基站和终端理解一致即可,这样的辩护同样属于本发明实施例的保护范围。
接下来,进一步结合具体的应用场景,说明本发明实施例所提出的技术方案的具体应用过程。
首先,统一假设后续实施例的前提条件如下:
假设***支持的UL CC个数为5个,编号分别为CC1、CC2、CC3、CC4、CC5,其中,CC2为Pcell。
基站为UE配置的UL CC为CC1、CC2、CC3和CC5,当前激活的CC个数为CC1、CC2和CC5。
基于上述假设的前提条件,本发明具体的实施例说明如下:
实施例一
设PHR基于配置的UL CC上报,Pcell根据Type1和Type2上报准则判断Pcell上只上报Type1 PHR,标准中不引入UE PHR,且不需要区分PH是virtual还是真实的,则可能的PHRMAC CE格式如下:
格式A、如图12所示,基站隐式确定PHR MAC CE长度,PHR MAC CE无需携带任何长度指示。
其中,各个CC PH在PHR MAC CE中的位置可以调整,只要预先定义好,保证基站和终端理解一致即可。
格式B、如图13所示,PHR MAC CE中携带CC bitmap指示PHR MAC CE中包含哪些CC的PHR信息。
其中,各个CC PH在PHR MAC CE中的位置可以调整,CC bitmap的顺序也可以调整,只要预先定义好,保证基站和终端理解一致即可。
实施例二
设PHR基于配置的UL CC上报,Pcell根据Type1和Type2上报准则判断Pcell上同时上报Type1和Type2 PHR,标准中不引入UE PHR,且不需要区分PH是virtual还是真实的,则可能的PHR MAC CE格式如下,需要用R bit区分Type1和Type2 PHR,比如:各个CC上Type1 PHR对应的Rbit可以取值“00”,Type2 PHR对应的R bit可以取值“01”。
格式A、如图14所示,基站隐式确定PHR MAC CE长度,PHR MAC CE无需携带任何长度指示。
其中,各个CC PH在PHR MAC CE中的位置可以调整,只要预先定义好,保证基站和终端理解一致即可。
格式B、如图15所示,PHR MAC CE中携带CC bitmap指示PHR MAC CE中包含哪些CC的PHR信息。
其中,各个CC PH在PHR MAC CE中的位置可以调整,CC bitmap的顺序也可以调整,只要预先定义好,保证基站和终端理解一致即可。
实施例三
设PHR基于配置的UL CC上报,Pcell根据Type1和Type2上报准则判断Pcell上同时上报Type1和Type2 PHR,标准中引入UE PHR,但是不需要区分PH是virtual还是真实的,则可能的PHR MAC CE格式如下,该实施例下需要用R bit区分Type1、Type2 PHR以及UE PHR,比如Type1 PHR对应的R bit可以取00,Type2 PHR对应的R bit可以取01,UE PHR对应的R bit可以取11。
格式A、如图16所示,基站隐式确定PHR MAC CE长度,PHR MAC CE无需携带任何长度指示。
其中,各个CC PH在PHR MAC CE中的位置可以调整,只要预先定义好,保证基站和终端理解一致即可。
格式B、如图17所示,PHR MAC CE中携带CC bitmap指示PHR MAC CE中包含哪些CC的PHR信息。
其中,各个CC PH在PHR MAC CE中的位置可以调整,CC bitmap的顺序也可以调整,只要预先定义好,保证基站和终端理解一致即可。
实施例四
设PHR基于配置的UL CC上报,Pcell根据Type1和Type2上报准则判断Pcell上同时上报Type1和Type2 PHR,标准中引入UE PHR,但是需要区分PH是virtual还是真实的,则可能的PHR MAC CE格式可能如下面格式1或者格式2所示。其实本实施例中PHRMAC CE和实施例3格式一致,只是需要注意:为了区分PH是virtual的还是真实的,一种最可能的办法就是用R bit,但是R bit只有2个,只能区分四类,这里既要区分Type1和Type2 PHR以及UE PHR,还要区分虚拟的和真实的PHR,显然,两个bit不够,因此可以通过如下方法解决:即固定UE PHR在PHR MAC CE中的位置(比如第一个byte或者最后一个byte),并且固定Pcell上Type1 PHR和Type2 PHR在MAC CE中的顺序(比如Type1 PHR在Type2 PHR之前的一个byte出现),这样就可以利用R bit区分各个PH是真实的还是虚拟的。比如可以用00表示真实的PHR,用01表示虚拟的PHR。
格式A、如图18所示,基站隐式确定PHR MAC CE长度,PHR MAC CE无需携带任何长度指示。
其中,各个CC PH在PHRMAC CE中的位置可以调整,只要预先定义好,保证基站和终端理解一致即可。
格式B、如图19所示,PHR MAC CE中携带CC bitmap指示PHR MAC CE中包含哪些CC的PHR信息。
其中,各个CC PH在PHR MAC CE中的位置可以调整,CC bitmap的顺序也可以调整,只要预先定义好,保证基站和终端理解一致即可。
实施例五
设PHR基于激活的UL CC上报,Pcell根据Type1和Type2上报准则判断Pcell上同时上报Type1和Type2 PHR,标准中不引入UE PHR,则可能的PHR MAC CE格式如下,需要用R bit区分Type1和Type2 PHR,比如:各个CC上Type1 PHR对应的Rbit可以取值“00”,Type2 PHR对应的R bit可以取值“01”。
格式A、如图20所示,基站根据激活情况隐式确定PHRMAC CE长度,PHR MAC CE无需携带任何长度指示。
其中,各个CC PH在PHR MAC CE中的位置可以调整,只要预先定义好,保证基站和终端理解一致即可。
格式B、如图21所示,PHR MAC CE中携带CC bitmap指示PHR MAC CE中包含哪些CC的PHR信息以及是否存在UE PHR。
其中,各个CC PH在PHR MAC CE中的位置可以调整,CC bitmap的顺序也可以调整,只要预先定义好,保证基站和终端理解一致即可。
实施例六
设PHR基于激活的UL CC上报,Pcell根据Type1和Type2上报准则判断Pcell上同时上报Type1和Type2 PHR,标准中引入UE PHR,则可能的PHRMAC CE格式如下,需要用R bit区分Type1和Type2 PHR,比如:各个CC上Type1 PHR对应的Rbit可以取值“00”,Type2 PHR对应的R bit可以取值“01”。
格式A、如图22所示,基站根据激活情况隐式确定PHR MAC CE长度,PHR MAC CE无需携带任何长度指示。
其中,各个CC PH在PHRMAC CE中的位置可以调整,只要预先定义好,保证基站和终端理解一致即可。
格式B、如图23所示,PHR MAC CE中携带CC bitmap指示PHR MAC CE中包含哪些CC的PHR信息以及是否存在UE PHR。
其中,各个CC PH在PHR MAC CE中的位置可以调整,CC bitmap的顺序也可以调整,只要预先定义好,保证基站和终端理解一致即可。
实施例七
设PHR基于激活的UL CC上报,Pcell根据Type1和Type2上报准则判断Pcell上同时上报Type1和Type2 PHR,标准中引入UE PHR,且需要区分PH是虚拟的还是真实的,则可能的PHR MAC CE格式如下可能如下面格式1或者格式2所示。其实本实施例中PHR MAC CE和实施例6格式一致,只是需要注意:为了区分PH是virtual的还是真实的,一种最可能的办法就是用R bit,但是R bit只有2个,只能区分四类,这里既要区分Type1和Type2 PHR以及UE PHR,还要区分虚拟的和真实的PHR,显然,两个bit不够,因此可以通过如下方法解决:即固定UE PHR在PHR MAC CE中的位置(比如第一个byte或者最后一个byte),并且固定Pcell上Type1 PHR和Type2 PHR在MAC CE中的顺序(比如Type1 PHR在Type2 PHR之前的一个byte出现),这样就可以利用R bit区分各个PH是真实的还是虚拟的。比如可以用00表示真实的PHR,用01表示虚拟的PHR。
格式A、如图24所示,基站根据激活情况隐式确定PHR MAC CE长度,PHR MAC CE无需携带任何长度指示。
其中,各个CC PH在PHR MAC CE中的位置可以调整,只要预先定义好,保证基站和终端理解一致即可。
格式B、PHR MAC CE中携带CC bitmap指示PHR MAC CE中包含哪些CC的PHR信息以及是否存在UE PHR。
其中,各个CC PH在PHR MAC CE中的位置可以调整,CC bitmap的顺序也可以调整,只要预先定义好,保证基站和终端理解一致即可。
需要进一步指出的是,上述各实施例中所给出的格式还有其它可能的格式,这里不在一一列举,只列举一下典型的格式,凡是符合本发明实施例所提出的技术方案的思想的格式都属于本发明的保护范围。
与现有技术相比,本发明实施例具有以下优点:
通过应用本发明实施例的技术方案,可以根据需要上报功率余量的上行成员载波数量和需要上报的功率余量类型,确定PHR MAC CE和相对应的MAC子头,并在其中携带PHR MAC CE长度信息、功率余量类型信息、是否为虚拟功率余量等指示信息,以使基站能够准确的获取到各上行成员载波的功率余量,从而,解决了目前现有的LTE Rel-8/9中PHR MAC CE格式对LTE-A***不适用的问题。
为了实现本发明实施例的技术方案,本发明实施例还提出了一种终端设备,其结构示意图如图26所示,具体包括:
设置模块261,用于设置PHR MAC CE长度确定策略。
确定模块262,用于根据设置模块261所设置的PHR MAC CE长度确定策略,确定需要上报的PHR MAC CE的长度。
其中,确定模块262,具体用于:
当设置模块261所设置的PHR MAC CE长度确定策略为PHR MAC CE的长度可变时,确定模块262根据当前需要上报功率余量的上行成员载波的数量和需要上报的功率余量的类型,确定当前需要上报的PHR MAC CE的长度;
当设置模块261所设置的PHR MAC CE长度确定策略为PHR MAC CE的长度固定时,确定模块262根据***支持的上行成员载波的数量和需要上报的功率余量的类型,确定需要上报的PHR MAC CE的固定长度。
生成模块263,用于根据确定模块262所确定的PHR MAC CE的长度,生成PHR MAC CE,PHR MAC CE中包含需要上报功率余量的各载波所对应的功率余量。
在具体的应用场景中,生成模块263,还用于生成PHR MAC CE所对应的MAC子头,
当设置模块261所设置的PHR MAC CE长度确定策略为PHR MAC CE的长度可变时,MAC子头包含长度指示域,长度指示域中包含终端设备所确定的PHR MAC CE的长度。
生成模块263,还用于在MAC子头中设置LCID的内容,以标识PHR MACCE中所携带的功率余量的类型,和/或,指示PHR MAC CE所针对的***类型。
生成模块263,还用于在PHR MAC CE中添加成员载波索引信息,
当设置模块261所设置的PHR MAC CE长度确定策略为PHR MAC CE的长度可变时,成员载波索引信息包括PHR MAC CE中是否携带当前需要上报功率余量的各上行成员载波的功率余量的指示信息,以及PHR MAC CE中所携带的各功率余量的类型信息。
当设置模块261所设置的PHR MAC CE长度确定策略为PHR MAC CE的长度固定时,成员载波索引信息包括PHR MAC CE中是否携带***支持的各上行成员载波的功率余量的指示信息,以及PHR MAC CE中所携带的各功率余量的类型信息。
发送模块264,用于向基站发送包含生成模块263所生成的PHR MAC CE和PHR MAC CE所对应的MAC子头的MAC PDU。
需要进一步指出的是,设置模块261,还用于设置是否允许上报虚拟功率余量;
如果允许,生成模块263在PHR MAC CE中所添加的成员载波索引信息,还包括PHR MAC CE中所携带的各功率余量是否为虚拟功率余量的指示信息;或,
如果允许,生成模块263,还用于设置PHR MAC CE中所包含的各功率余量所对应的预留比特位的取值,以指示功率余量是否为虚拟功率余量。
不仅如此,设置模块261,还用于当PHR MAC CE长度确定策略为PHRMAC CE的长度固定时,设置PHR MAC CE中各功率余量的排列顺序;
其中,所述各功率余量的排列顺序,具体为PHR MAC CE中所包括的各上行成员载波的功率余量,和/或成员载波索引信息,和/或终端设备的功率余量的排列顺序。
在此基础上,生成模块263,还用于按照设置模块261所设置的各功率余量的排列顺序,在PHR MAC CE中设置***支持的各上行成员载波所对应的预留比特位的取值,以标识上行成员载波是否有功率余量上报。
需要进一步指出的是,生成模块263,还用于设置PHR MAC CE中所包含的各功率余量所对应的预留比特位中的信息,以指示功率余量的类型。
另一方面,本发明实施例还提供了一种基站,其结构示意图如图27所示,包括:
设置模块271,用于设置PHR MAC CE的长度的识别策略;
接收模块272,用于接收终端设备上报的包含PHR MAC CE和PHR MACCE所对应的MAC子头的MAC PDU;
识别模块273,用于根据设置模块271所设置的识别策略识别接收模块272所接收的PHR MAC CE的长度;
获取模块274,用于根据识别模块273所识别的PHR MAC CE的长度,在接收模块272所接收的PHR MAC CE中获取终端设备上报的各上行成员载波的功率余量。
其中,识别模块273,具体用于:
根据MAC子头的长度指示域中的信息确定PHR MAC CE的长度;或,
根据PHR MAC CE中的成员载波索引信息确定PHR MAC CE的长度;或,
当PHR MAC CE的长度固定时,根据***支持的上行成员载波的数量和需要上报的功率余量的类型,确定PHR MAC CE的固定长度。
其中,获取模块274,具体用于:
根据MAC子头的LCID的信息,或PHR MAC CE中的成员载波索引信息,或PHR MAC CE中所包含的各功率余量所对应的预留比特位的取值,确定终端设备上报的各上行成员载波的功率余量的类型,并在PHR MAC CE中获取终端设备上报的各上行成员载波的功率余量;
当PHR MAC CE的长度固定时,按照设置模块271所设置的PHR MACCE中各功率余量的排列顺序,在PHR MAC CE中获取终端设备上报的各上行成员载波的功率余量。
其中,获取模块274,还用于:
根据MAC子头的LCID的信息,或PHR MAC CE中的成员载波索引信息,或PHR MAC CE中所包含的各功率余量所对应的预留比特位的取值,确定PHR MAC CE中所携带的各功率余量是否为虚拟功率余量;或,
根据当前资源分配状态确定PHR MAC CE中所携带的各功率余量是否为虚拟功率余量。
与现有技术相比,本发明实施例具有以下优点:
通过应用本发明实施例的技术方案,可以根据需要上报功率余量的上行上行成员载波数量和需要上报的功率余量类型,确定PHR MAC CE和相对应的MAC子头,并在其中携带PHR MAC CE长度信息、和/或功率余量类型信息、和/或是否为虚拟功率余量等指示信息,以使基站能够准确的获取到各上行成员载波的功率余量,从而,解决了目前现有的LTE Rel-8/9中PHR MAC CE格式对LTE-A***不适用的问题。
通过以上的实施方式的描述,本领域的技术人员可以清楚地了解到本发明实施例可以通过硬件实现,也可以借助软件加必要的通用硬件平台的方式来实现。基于这样的理解,本发明实施例的技术方案可以以软件产品的形式体现出来,该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM,U盘,移动硬盘等)中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本发明实施例各个实施场景所述的方法。
本领域技术人员可以理解附图只是一个优选实施场景的示意图,附图中的模块或流程并不一定是实施本发明实施例所必须的。
本领域技术人员可以理解实施场景中的装置中的模块可以按照实施场景描述进行分布于实施场景的装置中,也可以进行相应变化位于不同于本实施场景的一个或多个装置中。上述实施场景的模块可以合并为一个模块,也可以进一步拆分成多个子模块。
上述本发明实施例序号仅仅为了描述,不代表实施场景的优劣。
以上公开的仅为本发明实施例的几个具体实施场景,但是,本发明实施例并非局限于此,任何本领域的技术人员能思之的变化都应落入本发明实施例的业务限制范围。