用户功率余量报告相关方法、用户设备、基站和计算机可读
介质
技术领域
本公开涉及无线通信技术领域,更具体地,本公开涉及无线通信中用户功率余量报告相关的方法、相应的用户设备和基站、以及计算机可读介质。
背景技术
2017年3月,在第三代合作伙伴计划(3rd Generation Partnership Project:3GPP)RAN#75次全会上,一个关于进一步窄带物联网(NarrowBand Internet Of things,NB-IoT)增强的新工作项目(参见RP-170852:New WID on Further NB-IoT enhancements)获得批准。这个研究项目的目标之一是对用户反馈进行增强,例如在新的NB-IoT场景下,需要提高用户上行功率余量的反馈精度和反馈值的范围等。
针对上述需求和研究目标,本公开关注和解决版本(Release)15及后续版本中如何增强用户功率余量反馈的问题。
发明内容
本公开的目的旨在解决上述技术问题,具体地,本公开旨在解决Release 15及后续版本中如何增强用户功率余量反馈的技术问题。
为了实现上述目的,本公开的第一方面提供了一种在用户设备UE处执行的方法,包括:
从基站接收系统信息,所述系统信息包括用于指示所述基站支持或是否支持扩展数据量和功率余量报告DPR的指示信息;以及
根据UE支持扩展DPR的能力信息和接收到的指示所述基站支持扩展DPR的指示信息,确定在消息3Msg3中向基站发送扩展DPR。
在一示例性实施例中,扩展DPR由针对公共控制信道CCCH服务数据单元SDU的媒体接入控制MAC子头中或单独设置的媒体接入控制MAC子头中的逻辑信道标识LCID进行标识,所述LCID的值在LCID预留值中选取,或重用用于标识其他MAC CE的LCID值。
在一示例性实施例中,在满足以下条件中的至少一个的情况下,根据UE支持扩展DPR的能力信息和接收到的指示所述基站支持扩展DPR的指示信息,确定在Msg3中向基站发送扩展DPR:
UE要发送的数据量超过第一预定门限值;
UE的覆盖增强等级不超过第二预定门限值;
UE的电量不超过第三预定门限值,
其中所述第一、第二和第三预定门限值由系统预定义或从基站发送的无线资源控制RRC消息中获取。
本公开的第二方面提供了一种在用户设备UE处执行的方法,包括:
从基站接收用于请求UE无线接入能力的传递的UE能力问询消息;以及
向基站发送UE能力信息消息,所述UE能力信息消息包含UE支持或是否支持扩展数据量和功率余量报告DPR的指示信息。
本公开的第三方面提供了一种用户设备UE,包括:
通信接口,配置用于通信;
处理器;以及
存储器,存储有计算机可执行指令,所述指令在由所述处理器执行时,使所述处理器执行第一和第二方面所述的方法。
本公开的第四方面提供了一种在基站处执行的方法,包括:
向用户设备UE发送系统信息,所述系统信息包括用于指示所述基站支持或是否支持扩展数据量和功率余量报告DPR的指示信息;以及
从UE接收在消息3Msg3中发送的DPR。
在一示例性实施例中,所述方法还包括:
通过检测针对公共控制信道CCCH服务数据单元SDU的媒体接入控制MAC子头或单独设置的媒体接入控制MAC子头中的逻辑信道标识LCID的值,确定接收到的DPR是扩展DPR还是传统DPR,
其中如果检测到所述LCID值是LCID预留值、或是重用用于标识其他MAC CE的LCID值,则确定接收到的DPR是扩展DPR。
本公开的第五方面提供了一种在基站处执行的方法,包括:
向用户设备UE发送用于请求UE无线接入能力的传递的UE能力问询消息;以及
从UE接收UE能力信息消息,所述UE能力信息消息包含UE支持或是否支持扩展数据量和功率余量报告DPR的指示信息。
本公开的第六方面提供了一种基站,包括:
通信接口,配置用于通信;
处理器;以及
存储器,存储有计算机可执行指令,所述指令在由所述处理器执行时,使所述处理器执行如上所述的方法。
本公开的第七方面提供了一种计算机可读介质,在其上存储有指令,所述指令在由处理器执行时,使所述处理器执行第五和第六方面所述的方法。
本公开提供的上述方案给出了Release 15及后续版本中如何增强用户功率余量反馈的解决方案。例如,通过DPR类型的确定方法,UE可以确定在Msg3中发送的DRP类型是传统DPR还是扩展DPR。
本公开附加的方面和优点将在下面的描述中部分给出,这些将从下面的描述中变得明显,或通过本公开的实践了解到。
附图说明
通过下文结合附图的详细描述,本公开的上述和其它特征将会变得更加明显,其中:
图1示意性地示出了MAC PDU格式;
图2示意性地示出了未配置CA和DC时的传统PHR MAC CE格式;
图3示意性地示出了传统DPR MAC CE格式;
图4示意性地示出了两种传统BSR格式;
图5示意性示出了根据本公开示例性实施例的在UE处执行的发送扩展DPR的方法的流程图;
图6示意性示出了根据本公开示例性实施例的在UE处执行的上报是否支持扩展DPR能力的方法的流程图;
图7示意性地示出了根据本公开示例性实施例的扩展DPR MAC CE的格式;
图8示意性地示出了根据本公开示例性实施例的扩展DPR MAC CE的另一种格式;
图9示意性地示出了根据本公开示例性实施例的增强BPR MAC CE的格式;
图10示意性地示出了根据本公开示例性实施例的在Msg3之后发送的PHR格式;
图11示意性地示出了根据本公开示例性实施例的PHR发送请求MAC CE的格式;
图12示意性地示出了根据本发明示例性实施例的UE的结构框图;
图13示意性示出了根据本公开示例性实施例的在基站处执行的接收扩展DPR的方法的流程图;
图14示意性示出了根据本公开示例性实施例的在基站处执行的请求UE上报是否支持扩展DPR能力的方法的流程图;以及
图15示意性地示出了根据本发明示例性实施例的基站的结构框图。
具体实施方式
下面结合附图和具体实施方式对本申请进行详细阐述。应当注意,本申请不应局限于下文所述的具体实施方式。另外,为了简便起见,省略了对与本申请没有直接关联的公知技术的详细描述,以防止对本申请的理解造成混淆。
下面描述本公开涉及的部分术语,如未特别说明,本公开涉及的术语采用此处定义。本公开给出的术语或信元在5G新无线接入系统(New Radio,NR)、长期演进系统(LongTerm Evolution,LTE)和增强的长期研究系统(enhanced Long Term Evolution,eLTE)中可能采用不同的命名方式,但本公开中采用统一的术语或信元,在应用到具体的系统时,可以替换为相应系统中采用的术语或信元,信元的取值采用对应系统中规定的取值。本公开中基站可以是任何类型基站,包含Node B,增强基站eNB,也可以是5G通信系统基站gNB,或者微基站、微微基站、宏基站、家庭基站等;所述小区也可以是上述任何类型基站下的小区。本公开中基站、小区和演进的UMTS陆地无线接入网络(Evolved UMTS(Universal MobileTelecommunication System)Terrestrial Radio Access Network,E-UTRAN)可以互换。本公开内容可以应用于NB-IOT系统中,也可以应用到机器类型通信(Machine TypeCommunication,MTC)系统中。
下面描述本公开中涉及的一些概念。
功率余量(Power Headroom,PH):UE的发送功率余量信息,LTE中的用户装置(UserEquipment,UE)发送功率余量指的是对每一个激活的服务小区,均一化UE最大发送功率和上行共享信道(Uplink Shared Channel,UL-SCH)或探测参考信号(Sounding ReferenceSignal,SRS)传输的估计功率之间的差值;也可以指对物理上行控制信道(PhysicalUolink Control Channel,PUCCH)SCell和SpCell,均一化UE最大发送功率和UL-SCH和PUCCH传输的估计功率之间的差值。其中,PUCCH SCell指的是配置了PUCCH资源/信道的辅小区(Secondary Cell,SCell);在未配置双连接(Dual Connectivity,DC)时,SpCell指的是主小区(Primary cell,PCell),在配置了DC时,SpCell指的是主小区组的PCell或辅小区组的PSCell。在Release 14及之前版本的NB-IoT系统中,功率余量指的是对服务小区均一化UE最大发送功率和UL-SCH传输的估计功率之间的差值信息。
功率余量报告(Power Headroom Report,PHR):UE通过PHR向基站提供其功率余量信息,所述功率余量见上述。
数据量(Data Volume,DV):一个媒体接入控制(Medium Access Control,MAC)实体所关联的上行缓存中的可用于发送的数据总量信息。也可称缓存大小(Buffer Size,BS)。可用于发送的数据其定义可以参见3GPP技术规范协议36.321/36.322/36.323,本公开中参照所述技术规范的版本14,本公开中不再赘述。
缓存状态报告(Buffer Status Report,BSR):UE通过BSR告知基站其上行缓存中有多少数据需要发送,以便基站决定给该UE分配多少资源。
消息3(Msg3):随机接入过程中采用随机接入响应消息中的上行许可资源进行发送的上行传输。也描述为UL-SCH上发送的包含小区无线网络临时标识媒体接入控制控制元素(Cell-Radio Network Temporary identifier MAC Control Element,C-RNTI MAC CE)或公共控制信道服务数据单元(Common Control Channel Service Data Unit,CCCH SDU)(也称CCCH MAC SDU)的消息,MAC层从上层(无线资源控制(Radio Resource Control,RRC)层)获取该消息,其与UE竞争解析标识相关联,是随机接入过程的一部分。
覆盖增强等级(Coverage Enhancement level,CE level):增强覆盖技术中将需要增强覆盖的程度分为多个增强覆盖等级。在一些增强覆盖方法中,每一个增强覆盖等级可以对应一套不同的无线参数配置,如随机接入配置(如PRACH(Physical Random AccessChannel)资源)。也可称增强覆盖等级(Enhanced Coverage level,EC level)。
MAC协议数据单元:MAC PDU。指MAC层的数据包,其格式见图1所示,包含MAC头和MAC有效载荷两部分。其中,MAC头也可以称作MAC PDU头,其包括多个MAC子头(也可以称作MAC PDU子头),每个MAC子头对应MAC负载部分中的一个MAC CE或一个MAC SDU或填充比特。MAC负载部分包含零个或多个MAC CE和另个或多个MAC SDU,以及可能的填充比特。
在Release14及之前版本的LTE系统中,定义了多种PHR格式,在不配置载波聚合(Carrier Aggregation,CA)和DC时的PHR格式见图2所示。基站通过RRC消息来进行PHR配置,包括PHR相关参数的配置(如周期PHR定时器的值,禁止PHR定时器的值、用于判断PHR触发的下行路径损耗改变门限值等)、释放PHR等。UE在被配置了PHR配置信息时,根据所述PHR配置信息执行PHR上报流程,UE在未被配置或被去配置PHR(释放PHR)时,不进行PHR上报流程。PHR作为一个单独的MAC CE,当要发送PHR时,其对应一个MAC子头,其中的逻辑信道标识(Logical Channel Identity,LCID)采用“11010”值。
在Release14及之前版本的NB-IoT系统中,考虑到NB-IoT业务特性如较小数据包和较小数据量等特点,NB-IoT仅支持在随机接入过程中和Msg3一起上报PHR,采用数据量和功率余量报告(Data volume and Power Headroom Reporting,DPR)MAC CE。该MAC CE的格式如图3所示。也就是说,对NB-IoT而言,PH仅上报一次,且和数据量作为一个MAC CE一起上报。在DPR MAC CE中,R比特表示预留比特,置为0,用于发送功率余量信息的PH域占两个比特,可以表示4种不同的PH等级,用于发送数据量信息的DV域占4个比特,可以表示16中不同的数据量值。DPR MAC CE在Msg3中和CCCH SDU一起发送,DPR MAC CE由用于CCCH SDU的MAC子头来标识,其不需要额外的MAC子头,其在MAC PDU中的位置总是放在CCCH SDU之前。其中,CCCH SDU对应的MAC子头中,LCID采用“00000”值。
在Release14及之前版本的LTE系统中,定义了两种BSR格式见图4所示。基站通过RRC消息来配置BSR参数(如周期BSR定时器的值,重传BSR定时器等)等。BSR作为一个单独的MAC CE,当要发送BSR时,其对应一个MAC子头,其中,短BSR对应的LCID为“11101”值;截断BSR(Truncated BSR)对应的LCID为“11100”值;长BSR对应的LCID为“11110”值。NB-IoT系统不支持长BSR且所有的逻辑信道都属于一个逻辑信道组。
本公开的实施例给出了针对Release15中的NB-IoT新需求的PH增强方案。通过本公开所述方法,UE可以获取基站支持或是否支持增强的PH反馈,当UE和系统都支持增强的PH反馈时,UE可以应用增强的PH反馈流程将更精确的PH信息上报给基站,以用于接下来的上行调度方案,从而达到节省UE能耗和合理利用UE功率的目的。
在本公开中,区别于Release14及之前版本的DPR(本公开中称为传统DPR),将在Msg3中和/或Msg3之后发送的Release15及之后版本中的增强的DPR称为增强DPR(enhancedDPR)(将在技术规范文档36.321中定义),将在Msg3中发送的Release15及之后版本中的增强的DPR称为扩展DPR(extended DRB),即,在指代Msg3中发送的Release15及之后版本中的DPR时,“扩展DPR”可以与“增强DPR”互换使用。但是本领域技术人员可以理解,尽管在本公开中这样使用,但是Releasel5及之后版本中的增强的DPR并不限于这两种名称,比如也可称长DPR。DPR MAC CE也可以简称为DPR,BSR MAC CE也可以简称为BSR,PHR MAC CE也可以简称为PHR。
以下将参照图5,对根据本公开示例性实施例的在UE处执行的发送扩展DPR的方法进行描述。
图5示出了根据本公开示例性实施例的在UE处执行的发送扩展DPR的方法500的流程图。如图5所示,方法500可以包括步骤S501和S502。
在步骤S501中,UE(例如,NB-IoT UE,下同)可以从基站接收系统信息,所述系统信息包括指示信息(为避免混淆,以下称为第一指示信息),所述指示信息用于指示所述基站支持(或允许,二者可以互换,下同)扩展DPR、或指示所述基站是否支持扩展DPR。
具体地,所述第一指示信息可以指示基站所服务的小区允许或是否允许扩展DPR或者说允许或是否允许发送扩展DPR。优选地,若所述第一指示信息存在,则该小区允许扩展DPR或者说允许发送扩展DPR;若所述第一指示信息不存在,则该小区不允许扩展DPR或者说不允许发送扩展DPR。备选地,若所述第一指示信息被置为“TRUE”或“1”,则该小区允许扩展DPR或者说允许发送扩展DPR;若所述第一指示信息被置为“FALSE”或“0”,则该小区不允许扩展DPR或者说不允许发送扩展DPR。优选地,所述第一指示信息包含在系统信息中如系统信息块1或系统信息块2中,所述系统信息可以由RRC消息承载。
在步骤S501的另一实施方式中,UE可以判断从基站接收的RRC消息中包含或是否包含Release 15或后续版本特定的RRC信息元素。如果包含,则UE可以确定该基站是Release15基站或Release15后续版本基站,即UE可以确定该基站允许扩展DPR、或者说允许发送扩展DRP、或者说支持扩展DPR。否则,如果RRC消息中不包含Release 15或后续版本特定的RRC信息元素,则UE可以确定该基站是Release14基站或Release14之前版本基站,即UE可以确定该基站不允许扩展DPR、或者说不允许发送扩展DRP、或者说不支持扩展DPR。优选地,所述RRC消息是系统信息消息。在本实施方式中,假设所有Release15基站及后续版本基站都支持或允许扩展DPR。
接下来,UE可以基于UE和基站支持或是否支持扩展DPR的能力来确定在Msg3中向基站发送的DPR的类型。所述DPR类型包括传统DPR和扩展DPR。在本文中,扩展DPR是为了扩展传统DPR中PH值的范围和精度而定义的新的DPR MAC CE,被称为扩展DPR MAC CE或简称扩展DPR。
在步骤S402中,UE可以根据UE支持扩展DPR的能力信息和接收到的指示所述基站支持扩展DPR的第一指示信息,确定在Msg3中向基站发送扩展DPR,或称在Msg3中包含扩展DPR,亦或称通知复用组合(Multiplexing and Assembly)流程去生成和发送扩展DPR。
如果UE不支持扩展DPR或接收到的第一指示信息指示所述基站不支持扩展DPR,则UE确定在Msg3中向基站发送传统DPR,或称在Msg3中包含传统DPR,亦或称通知复用组合流程去生成和发送传统DPR。
在另一实施例中,UE可以基于UE和基站支持或是否支持扩展DPR的能力并根据满足或是否满足预定条件来确定在Msg3中向基站发送的DPR的类型。
在该实施例中的步骤S502中,UE可以在满足以下条件中的至少一个的情况下,根据UE支持扩展DPR的能力信息和接收到的指示所述基站支持扩展DPR的第一指示信息,确定在Msg3中向基站发送扩展DPR:
UE要发送的数据量超过第一预定门限值;
UE的覆盖增强等级不超过第二预定门限值;
UE的电量不超过第三预定门限值。
具体地,如果UE支持扩展DPR且基站也支持扩展DPR且满足上述预定条件中的至少一个,则UE确定在Msg3中发送扩展DPR,或称在Msg3中包含扩展DPR,亦或称通知复用组合(Multiplexing and Assembly)流程去生成和发送扩展DPR。
如果UE不支持扩展DPR或基站不支持扩展DPR或不满足上述预定条件中的至少一个,则UE确定在Msg3中发送传统DPR,或称在Msg3中包含传统DPR,亦或称通知复用组合流程去生成和发送传统DPR。
具体地,预定条件可以为UE有或是否有更多的数据要发送或者要发送的数据量超过或是否超过第一预定门限值。所述预定条件满足指有更多的数据要发送或者要发送的数据量超过第一预定门限值,所述预定条件不满足指的是没有更多的数据要发送或者要发送的数据量不超过所述第一预定门限值。
备选地,预定条件也可以为UE的覆盖增强等级不超过或是否不超过第二预定门限值。所述预定条件满足指UE的覆盖增强等级不超过第二预定门限值,所述预定条件不满足指UE的覆盖增强等级超过第二预定门限值。在另一实施方式中,预定条件也可以为UE的覆盖增强等级不低于或是否不低于第二预定门限值。所述预定条件满足指UE的覆盖增强等级不低于第二预定门限值,所述预定条件不满足指UE的覆盖增强等级低于第二预定门限值。
备选地,预定条件也可以为UE的电量是或是否是低电量或UE的电量不超过或是否不超过第三预定门限值。所述预定条件满足指UE的电量是低电量或UE的电量不超过第三预定门限值,所述预定条件不满足指的是UE的电量不是低电量或UE的电量超过第三预定门限值。所述UE的电量可以指UE的电池电量。
在该实施例中,所述第一、第二和第三预定门限值可以由系统预定义或从基站发送的RRC消息中获取。所述RRC消息可以是专用RRC消息,如RRC连接重配置消息,也可以是系统信息消息。
以下将在分别两个示例性实施例中描述在Msg3中承载扩展DPR或传统DPR的具体设置。该设置使UE在Msg3中发送DPR时可以区别地标识传统DRP和扩展DPR,从而接收到DPR的基站也可以识别出收到的DPR是传统DPR还是扩展DPR,以便正确进行解码/解析。
在第一实施例中,与传统DPR类似,扩展DPR与CCCH SDU共用一个MAC子头,没有增加任何额外的MAC子头,且总是放置于CCCH SDU前面。扩展DPR由针对CCCH SDU的MAC子头中的LCID进行标识,不同于传统DPR的是,用于标识扩展DPR的LCID值在LCID预留值01101~10011中选取,例如“01101”。备选地,该LCID值也可以重用LTE系统中用于标识其他MAC CE的LCID值,如重用长BSR的LCID“11110”或重用短BSR的LCID“11101”或重用截断BSR的LCID“11100”或重用PHR的LCID“11010”或重用扩展PHR的LCID“11001”或重用双连接PHR的LCID“11000”等。因为上述被重用的MAC CE和扩展DPR不会同时出现在msg3中,所以重用这些MACCE对应的LCID不会造成混淆。
对UE而言,若确定要发送的是扩展DPR,则采用所述新的LCID值例如LCID“01101”来指示CCCH SDU,否则(若确定要发送的是传统DPR),UE采用LCID“00000”来指示CCCH SDU。
所述确定要发送的是扩展DPR MAC CE也可描述为扩展DPR被发送,或可描述为扩展DPR被包含在MAC PDU中。
在第二实施例中,不同于传统DPR,扩展DPR对应一个单独为其设置的MAC子头,即扩展DPR对应的MAC子头是不与CCCH SDU或其他MAC SDU/CE共用的。所述扩展DPR由其对应MAC子头中的LCID进行标识。用于标识扩展DPR的LCID值在LCID预留值01101~10011中选取,例如“01101”。备选地,该LCID值也可以重用LTE系统中其他MAC CE对应的LCID值,如重用长BSR的LCID“11110”或重用短BSR的LCID“11101”或重用截断BSR的LCID“11100”或重用PHR的LCID“11010”或重用扩展PHR的LCID“11001”或重用双连接PHR的LCID“11000”等。因为上述被重用的MAC CE和扩展DPR不会同时出现在msg3中,所以重用这些MAC CE对应的LCID不会造成混淆。
对UE而言,若确定要发送的是扩展DPR MAC CE,则在MAC PDU中包含其对应的MAC子头,或者描述为为扩展DPR构建(或新建或增加)一个MAC子头,也可描述扩展DPR由对应的MAC子头指示或由对应的MAC子头和对应的LCID指示;否则(若确定要发送的是传统DPR),DPR由用于CCCH SDU的MAC子头所表示,且不增加任何额外的子头。
对扩展DPR,其在MAC PDU的位置可以在MAC SDU之前MAC头之后的任何位置,即不限于仅被放置在CCCH SDU前面。
所述确定要发送的是扩展DPR MAC CE也可描述为扩展DPR被发送,或可描述为扩展DPR被包含在MAC PDU中。
在一示例中,用于第二实施例的CCCH SDU的MAC子头中的LCID为“00000”。
也就是说,扩展DPR可以由针对CCCH SDU的MAC子头中或单独设置的MAC子头中的LCID进行标识,所述LCID的值在LCID预留值中选取,或重用用于标识其他MAC CE的LCID值。
尽管以上是以在UE处执行发送扩展DPR的完整过程进行描述的,但是本公开的实施例不仅包括上述完整过程,还包括在以下各个实施例中描述的与扩展DPR相关的单独的实现。
在Msg3中传输的增强DPR机制-UE侧
在该部分所述实施例中,为了扩展DPR中PH值的范围和精度,需要定义一种新的DPR MAC CE格式,称扩展DRP MAC CE。
UE侧实施例1
本实施例给出了一种区别传统DPR和扩展DPR的方法。通过该实施例,UE在发送DPR时可以区别地标识传统DRP和扩展DPR,使得DPR的接收端即基站也可以识别出收到的DPR是传统DPR还是扩展DPR,从而正确进行解码/解析。
本实施例中,与传统DPR类似,扩展DPR由用于CCCH SDU的MAC子头标识,其没有增加任何额外的MAC子头且总是放置于CCCH SDU前面。不同于传统DPR的是,标识扩展DPR的用于CCCH SDU的MAC子头中的LCID为一个不同的LCID值,其值在LCID预留值01101~10011中选取,例如“01101”。备选地,也可以重用LTE系统中其他MAC CE对应的LCID值,如重用长BSR的LCID“11110”或重用短BSR的LCID“11101”或重用截断BSR的LCID“11100”或重用PHR的LCID“11010”或重用扩展PHR的LCID“11001”或重用双连接PHR的LCID“11000”等。因为上述被重用的MAC CE和扩展DPR不会同时出现在msg3中,所以重用这些MAC CE对应的LCID不会造成混淆。
对UE而言,若确定要发送的是扩展DPR,则采用所述新的LCID值例如LCID“01101”来指示CCCH SDU,否则(若确定要发送的是传统DPR),UE采用LCID“00000”来指示CCCH SDU。
所述确定要发送的是扩展DPR MAC CE也可描述为扩展DPR被发送,或可描述为扩展DPR被包含在MAC PDU中。可选地,所述确定要发送的是扩展DPR MAC CE可以采用下述UE侧实施例3~5中的方法,但不限于这些方法。结合UE侧实施例3和6,所述确定要发送的是扩展DPR MAC CE描述为支持扩展DPR的NB-IoT UE若第一指示信息包含(或称被指示)在系统信息中;所述确定要发送的是传统DPR可描述为NB-IoT UE不支持扩展DPR或第一指示信息不包含(或称不被指示)在系统信息中。
UE侧实施例2
本实施例给出了另一种区别传统DPR和扩展DPR的方法。通过该实施例,UE在发送DPR时可以区别地标识传统DRP和扩展DPR,使得DPR的接收端即基站也可以识别出收到的DPR是传统DPR还是扩展DPR,从而正确进行解码/解析。
本实施例中,不同于传统DPR,扩展DPR对应一个MAC子头,即扩展DPR对应的MAC子头是不与CCCH SDU或其他MAC SDU/CE共用的。所述扩展DPR采用其对应MAC子头中的LCID来标识。例如,优选地,所述LCID可以是一个新的值“10011”,备选地,也可以重用LTE系统中其他MAC CE对应的LCID值,如重用长BSR的LCID“11110”或重用短BSR的LCID“11101”或重用截断BSR的LCID“11100”或重用PHR的LCID“11010”或重用扩展PHR的LCID“11001”或重用双连接PHR的LCID“11000”等。因为上述被重用的MAC CE和扩展DPR不会同时出现在msg3中,所以重用这些MAC CE对应的LCID不会造成混淆。
对UE而言,若确定要发送的是扩展DPR MAC CE,则在MAC PDU中包含其对应的MAC子头,或者描述为为扩展DPR构建(或新建或增加)一个MAC子头,也可描述扩展DPR由对应的MAC子头指示或由对应的MAC子头和对应的LCID指示;否则(若确定要发送的是传统DPR),DPR由用于CCCH SDU的MAC子头所表示,且不增加任何额外的子头。
对扩展DPR,其在MAC PDU的位置可以在MAC SDU之前MAC头之后的任何位置,即不限于仅被放置在CCCH SDU前面。
所述确定要发送的是扩展DPR MAC CE也可描述为扩展DPR被发送,或可描述为扩展DPR被包含在MAC PDU中。可选地,所述确定要发送的是扩展DPR MAC CE可以采用下述UE侧实施例3~5中的方法,但不限于这些方法。结合UE侧实施例3和6,所述确定要发送的是扩展DPR MAC CE描述为支持扩展DPR的NB-IoT UE若第一指示信息包含(或称被指示)在系统信息中;所述确定要发送的是传统DPR可描述为NB-IoT UE不支持扩展DPR或第一指示信息不包含(或称不被指示)在系统信息中。
更进一步地,本实施例中,用于CCCH SDU的MAC子头中的LCID为“00000”。
UE侧实施例3
本实施例给出了一种UE确定在Msg3中要发送的DPR类型的方法。所述DPR类型包括传统DPR和扩展DPR。
在本实施例中,UE基于UE和基站支持或是否支持扩展DPR的能力来确定发送的DPR的类型。若UE支持扩展DPR且基站也支持扩展DPR,则UE确定在Msg3中发送扩展DPR或称UE在Msg3中包含扩展DPR或称通知复用组合流程去生成和发送一个扩展DPR;否则(若UE不支持扩展DPR或基站不支持扩展DPR),则UE确定在Msg3中发送传统DPR或称UE在Msg3中包含传统DPR或称通知复用组合流程去生成和发送一个传统DPR。
结合UE侧实施例6,所述基站支持扩展DPR可以描述为:第一指示信息包含(或称被指示)在系统信息中。所述基站不支持扩展DPR可以描述为:第一指示信息不包含(或称不被指示)在系统信息中。
UE侧实施例4
本实施例给出了一种UE确定在Msg3中要发送的DPR类型的方法。所述DPR类型包括传统DPR和扩展DPR。
在本实施例中,UE基于UE和基站支持或是否支持扩展DPR的能力并根据预定条件满足或是否满足来确定发送的DPR的类型。
若UE支持扩展DPR且基站也支持扩展DPR,当预定条件满足时,则UE确定在Msg3中发送扩展DPR或称UE在Msg3中包含扩展DPR或称通知复用组合流程去生成和发送一个扩展DPR;否则(若UE不支持扩展DPR或基站不支持扩展DPR或预定条件不满足),则UE确定在Msg3中发送传统DPR或称UE在Msg3中包含传统DPR或称通知复用组合流程去生成和发送一个传统DPR。
在一种实施方式中,所述预定条件为有或是否有更多的数据要发送或者要发送的数据量超过或是否超过第一预定门限值。所述预定条件满足指有更多的数据要发送或者要发送的数据量大于或大于等于第一预定门限值。所述预定条件不满足指的是没有更多的数据要发送或者要发送的数据量小于或小于等于所述第一预定门限值。
在另一种实施方式中,所述预定条件也可以为UE的覆盖增强等级不超过或是否不超过第二预定门限值。所述预定条件满足指UE的覆盖增强等级不超过第二预定门限值,所述预定条件不满足指UE的覆盖增强等级超过第二预定门限值。在另一实施方式中,预定条件也可以为UE的覆盖增强等级不低于或是否不低于第二预定门限值。所述预定条件满足指UE的覆盖增强等级不低于第二预定门限值,所述预定条件不满足指UE的覆盖增强等级低于第二预定门限值。
在又一种实施方式中,所述预定条件为UE的电量是或是否是低电量或UE的电量低于或是否低于第三预定门限值。所述预定条件满足指UE的电量是低电量或UE的电量小于或小于等于第三预定门限值。所述预定条件不满足指的是UE的电量不是低电量或UE的电量大于或大于等于第三预定门限值。所述UE的电量可以指UE的电池电量。
可选地,UE确定在Msg3中要发送的DPR类型之前,还包括UE获取预定条件中的门限值(包括第一预定门限值或第二预定门限值或第三预定门限值)。所述预定条件中的门限值可以是系统预定义的,也可以是UE从基站通过RRC消息获取的。更进一步地,所述RRC消息可以是专用RRC消息如RRC连接重配置消息,也可以是系统信息。
结合UE侧实施例6,所述基站支持扩展DPR可以描述为:第一指示信息包含(或称被指示)在系统信息中。所述基站不支持扩展DPR可以描述为:第一指示信息不包含(或称不被指示)在系统信息中。
UE侧实施例5
本实施例给出了一种UE确定在Msg3中要发送的DPR类型的方法。所述DPR类型包括传统DPR和扩展DPR。
若UE支持扩展DPR且基站也支持扩展DPR,则UE随机选择在Msg3中要发送的DPR类型,若UE确定在Msg3中发送扩展DPR,则UE在Msg3中包含扩展DPR或称通知复用组合流程去生成和发送一个扩展DPR;否则(若UE不支持扩展DPR或基站不支持扩展DPR或UE确定在Msg3中发送传统DPR),则UE在Msg3中包含传统DPR或称通知复用组合流程去生成和发送一个传统DPR。
结合UE侧实施例6,所述基站支持扩展DPR可以描述为:第一指示信息包含(或称被指示)在系统信息中。所述基站不支持扩展DPR可以描述为:第一指示信息不包含(或称不被指示)在系统信息中。
UE侧实施例6
本实施例给出了UE获取基站支持或是否支持扩展DPR信息的方法。所述“支持”和“允许”可以替换。
在一种实施方式中,UE从基站接收第一指示信息,所述指示信息用于指示在该小区(是否)允许扩展DPR或者说(是否)允许发送扩展DPR。优选地,若所述指示信息存在,则该小区允许扩展DPR或者说允许发送扩展DPR;若所述指示信息不存在,则该小区不允许扩展DPR或者说不允许发送扩展DPR。备选地,若所述指示信息置为“TRUE”或“1”,则该小区允许扩展DPR或者说允许发送扩展DPR;若所述指示信息置为“FALSE”或“0”,则该小区不允许扩展DPR或者说不允许发送扩展DPR。优选地,所述指示信息包含在系统信息中如系统信息块1或系统信息块2中。
在一种实施方式中,UE从基站接收RRC消息,若RRC消息中包含Release 15或后续版本特定的RRC信息元素,则UE认为该基站是Release15基站或Release15后续版本基站,即UE认为该基站允许扩展DPR或者允许发送扩展DRP或者说支持扩展DPR。否则,若RRC消息中不包含Release 15或后续版本特定的RRC信息元素,则UE认为该基站是Release14基站或Release14之前版本基站,即UE认为该基站不允许扩展DPR或者不允许发送扩展DRP或者说不支持扩展DPR。优选地,所述RRC消息是系统信息。本实施方式中认为所有Release15基站及后续版本基站都支持或允许扩展DPR。
以下将参照图6,对根据本公开示例性实施例的在UE处执行的上报支持或是否支持扩展DPR能力的方法进行描述。
图6示意性示出了根据本公开示例性实施例的在UE处执行的上报是否支持扩展DPR能力的方法600的流程图。如图6所述,方法600可以包括步骤S601和S602。
在步骤S601中,UE可以从基站接收UE能力问询(UECapabilityEnquiry)消息,所述UE能力问询消息用于请求UE无线接入能力的传递。所述UE无线接入能力包括E-UTRA无线接入能力以及其他无线接入技术的无线接入能力。
在步骤S602中,UE可以向基站发送UE能力信息(UECapabilityInformation)消息,所述UE能力信息消息包含UE支持或是否支持扩展DPR的指示信息(为了避免混淆,以下称为第二指示信息)。在一示例中,若该第二指示信息被设置为“supported”,则表示UE支持扩展DPR;若该第二指示信息不存在,则表示UE不支持扩展DPR。
可选地,该第二指示信息可以是区分时分复用(Time Division Duplex,TDD)系统和频分复用(Frequency Division Duplex,FDD)系统的,即第二指示信息可以包括两部分:一部分用于指示对TDD系统UE支持或是否支持扩展DPR;另一部分指示对FDD系统UE支持或是否支持扩展DPR。
以下将结合图7和图8,对根据本公开示例性实施例的扩展DPR MAC CE的格式进行描述。应注意,以下实施例中给出的格式仅为示例,本公开其他实施例中所述扩展DPR的格式并不限于本实施例中的示例。
参照图7,其示出了扩展DPR MAC CE的一种格式。在该格式中,DPR为固定长度1byte,其中DV域占4比特,PH域占4比特。4比特的PH可以表示16种PH等级。备选地,PH域占3比特,剩余比特为预留比特,置为0。
参照图8,其示出了扩展DPR MAC CE的另一种格式。在该格式中,DPR为固定长度2byte,其中DV域占4比特,PH域占6比特,其余比特可以用于其他用途如将在之后描述的附加实施例6所述UE请求,也可以是预留比特,预留比特位置为“0”。6比特的PH可以表示64中PH等级。上述各个域的长度仅为示例。比如DV域也可以是6比特。
以下将对UE侧执行的本公开的其他示例性实施例进行描述。
在Msg3之后发送增强DPR的机制-UE侧
UE侧实施例7
该实施例提供一种Msg3之后发送的PHR的方法。在该方法中,PHR和BSR可以一起触发,或者PHR和BSR可以一起发送。所述PHR和BSR一起触发可以指对一个MAC实体,BSR被触发时,总是触发PHR;或者PHR被触发时,触发BSR。所述PHR和BSR一起发送指通过单一的MAC CE来发送PH信息和BS信息,类似于DPR,本公开中称其为缓存大小和功率余量上报(BufferSize and Power Headroom Report,BPR)MAC CE或增强BPR,其格式的示例可以参见图9。
可以使用一个独立的LCID来指示BPR MAC CE。BPR MAC CE对应一个MAC子头。UE或MAC实体在下述条件满足时发送BPR:当前TTI有可用的资源且既有等待发送的BSR又有等待的PHR。否则,当当前TTI有可用的资源但仅有等待的BSR时,发送BSR;或者当当前TTI有可用的资源但仅有等待的PHR时,发送PHR。
可选地,UE可以从基站接收使能信息,所述使能信息用于使能上述一起触发BSR和PHR和/或发送BPR。
在Msg3之后发送PHR的机制-UE侧
本公开中,Msg3之后发送PHR也可描述为Msg3之后的PHR,或者描述为不在Msg3中的PHR,或者描述为不和Msg3一起发送的PHR,或者描述为PHR MAC CE发送。
UE侧实施例8
本实施例给出了UE获取基站是否支持在Msg3之后发送PHR的方法。在一种实施方式中,UE从基站接收第三指示信息,所述第三指示信息用于指示在该小区(是否)允许在Msg3之后发送PHR。也可描述为所述指示信息用于指示所述小区(是否)支持在Msg3之后发送PHR。优选地,若所述第三指示信息存在,则该小区允许在Msg3之后发送PHR或者说该小区支持在Msg3之后发送PHR;若所述指示信息不存在,则该小区不允许在Msg3之后发送PHR或者说该小区不支持在Msg3之后发送PHR。备选地,若所述指示信息置为“TRUE”或“1”,则该小区允许在Msg3之后发送PHR或者说该小区支持在Msg3之后发送PHR;若所述指示信息置为“FALSE”或“0”,则该小区不允许在Msg3之后发送PHR或者说该小区不支持在Msg3之后发送PHR。优选地,所述第三指示信息包含在系统信息中如系统信息块1或系统信息块2中。备选地,所述第三指示信息包含在专用RRC消息中如RRC连接重配置消息或RRC连接建立消息或RRC连接重建立消息或RRC连接恢复消息中,更具体地,包含在RRC消息中的MAC-mainconfig信息元素中。
在一种实施方式中,UE从基站接收RRC消息,若RRC消息中包含Release 15或后续版本特定的RRC信息元素,则UE认为该基站是Release15基站或Release15后续版本基站,即UE认为该基站允许在Msg3之后发送PHR或者说支持在Msg3之后发送PHR。否则,若RRC消息中不包含Release 15或后续版本特定的RRC信息元素,则UE认为该基站是Release14基站或Release14之前版本基站,即UE认为该基站不允许在Msg3之后发送PHR或者说不支持在Msg3之后发送PHR。优选地,所述RRC消息是系统信息。本实施方式中认为所有Release15基站及后续版本基站都支持或允许在Msg3之后发送PHR。
UE侧实施例9
本实施例给出了一种在UE处执行的关于UE是否支持在Msg3之后发送PHR能力上报的方法。
步骤1:UE从基站接收UE能力问询(UECapabilityEnquiry)消息,该消息用于请求UE无线接入能力的传递。所述UE无线接入能力包括E-UTRA无线接入能力以及其他无线接入技术的无线接入能力。
步骤2:UE向基站发送UE能力信息(UECapabilityInformation)消息,其中包含UE支持或是否支持在Msg3之后发送PHR的第四指示信息。更进一步地,若第四指示信息设置为“supported”,则表示UE支持在Msg3之后发送PHR;若指示信息不存在,则表示UE不支持在Msg3之后发送PHR。
可选地,所述第四指示信息可以是区分TDD和FDD的,即第四指示信息可以包括两部分:一部分用于指示对TDD系统UE支持或是否支持在Msg3之后发送PHR;另一部分指示对FDD系统UE支持或是否支持在Msg3之后发送PHR。
UE侧实施例10
本实施例给出了一种激活/去激活在Msg3之后发送PHR的方法。
步骤1:UE接收在Msg3之后发送PHR的激活/去激活指示
步骤2:若所述在Msg3之后发送PHR的激活/去激活指示为激活,则UE激活Msg3之后的PHR发送流程;若所述在Msg3之后发送PHR的激活/去激活指示为去激活,则UE去激活Msg3之后的PHR发送流程,包含丢弃等待的PHR发送。所述Msg3之后的PHR发送流程用于在Msg3之后发送PHR信息。
优选地,所述在Msg3之后发送PHR的激活/去激活指示为MAC CE;备选地,所述在Msg3之后发送PHR的激活/去激活指示为层1信令,如包含在物理下行控制信道(PysicalDownlink Control Channel,PDCCH)中。
若所述在Msg3之后发送PHR的激活/去激活指示为MAC CE,则本实施例可以描述为:
对每个发送时间间隔(Transmission Time Interval)TTI,MAC实体将:
-若MAC实体在本TTI收到一个PHR激活/去激活MAC CE来激活PHR,激活PHR流程
-若MAC实体在本TTI收到一个PHR激活/去激活MAC CE来去激活PHR,去激活PHR流程。
若PHR流程被去激活,则UE执行下述操作的一种或多种:
-不发送任何PHR,
-不触发任何PHR,
-丢弃等待发送的PHR。
所述在Msg3之后发送的PHR其初始状态为预定义的,即预定义其初始状态为去激活(或激活)。或者其初始状态通过RRC消息来配置。
可选地,定义一个PHR去激活定时器。当UE或UE MAC实体收到所述用于激活PHR的PHR激活/去激活MAC CE时或收到包含PHR配置的RRC消息时,启动或重启所述PHR定时器;当所述PHR定时器超时时,去激活PHR或者说认为PHR去激活,可选地,还包括停止所述定时器。
UE侧实施例11
本实施例给出了在Msg3之后发送的PHR格式。
所述在Msg3之后发送的PHR,其格式示例如图10,在Msg3之后发送的PHR为固定长度1byte。PH域占3比特,剩余比特为预留比特;或者PH域为4比特,剩余比特为预留比特;或者PH域为5比特,剩余比特为预留布特。预留比特置为0。
为了与其他MAC CE区别,PHR有对应的MAC子头,在PHR对应的MAC子头中,优选地,其LCID的值为预留LCID中的一个如“10011”或“10010”;备选地,其LCID的值可重用LTE系统中的PHR对应的LCID值“11010”。
UE请求的PHR发送机制-UE侧
在本部分中,PHR包括msg3之后发送的PHR。本部分下述实施例提供了UE请求的PHR发送的方法。UE请求的PHR发送也可描述为PHR请求或PHR发送请求或UE请求的PHR。优选地,所述请求用于请求多次PHR发送;备选地,所述请求用于请求一次PHR发送。
所述PHR可以替换成“BSR”或者“PHR和BSR”或者上文所述“BPR”。
UE侧实施例12
本实施例提供了一种涉及PHR发送请求的方法,包括下述步骤。
步骤1:若UE支持PHR发送请求且基站允许PHR发送请求,则UE向基站发送PHR发送请求。
步骤2:UE从基站接收PHR发送许可。
步骤3:UE发送PHR。本步骤是可选的。
步骤1中所述UE发送的PHR发送请求可以包含在RRC信令中,也可以包含在MAC CE中,还可以是包含在层1信令中。更进一步地,下述给出几种方式。
在一种实施方式中,所述PHR发送请求包含在DPR中。若DPR中PHR发送请求比特置为“1”,则表示UE请求PHR发送;若置为“0”,则表示UE不请求PHR发送。
在一种实施方式中,所述PHR发送请求为单独的MAC CE,其格式示例如图11,称其为PHR发送请求MAC CE,其有对应的MAC子头及关联的LCID。
在一种实施方式中,所述PHR发送请求包含在RRC连接请求消息中或RRC连接建立完成消息中或RRC连接重建立完成中或RRC连接重配置完成中或RRC连接恢复完成中。若所述RRC消息中PHR发送请求信息元素置为“Ture”或“1”或“required”,则表示UE请求PHR发送,若所述RRC消息中PHR发送请求信息元素置为“False”或“0”或“not required”或不存在,则表示UE不请求PHR发送。
所述UE请求PHR发送也可表述为PHR可用或PHR发送(是否)需要或UE(是否)请求PHR发送。
步骤1中所述基站允许PHR发送请求示例见将在之后描述的UE侧实施例13,结合UE侧实施例13,步骤1可描述为:若(UE支持PHR发送请求且)第五指示信息被包含在RRC消息中或第五指示信息指示允许PHR发送请求,则UE向基站发送PHR发送请求。所述UE向基站发送PHR发送请求也可描述为:将PHR发送请求信息元素或比特置为“1”或“TURE”;或者可描述为:指示复用和组合过程去生成PHR发送请求MAC CE。
步骤2中,所述PHR发送许可包含在RRC消息中或包含在MAC CE中或包含在层1信令中。
若所述PHR发送许可包含在RRC消息中,优选地,所述PHR发送许可是包含在PHR配置信息元素中的PHR发送许可指示信息元素;若所述PHR发送许可指示信息元素置为“Ture”或“1”或“setup”,则表示允许或使能PHR发送,若所述RRC消息中PHR发送请求信息元素置为“False”或“0”或不存在,则表示不允许或去使能或禁止PHR发送。
若所述PHR发送许可包含在RRC消息中,备选地,所述PHR发送许可是PHR配置,所述PHR配置包括周期PHR定时器配置、禁止PHR定时器配置、下行路径损耗改变配置等中的一种或多种。若PHR配置包含在RRC消息中,则表示允许或使能PHR发送;若PHR配置不包含在RRC消息中或PHR配置为“release”,则表示不允许或去使能或禁止PHR发送。
若所述PHR发送许可包含在MAC CE中,则若PHR发送许可比特置为“1”,则表示允许或使能PHR发送;若置为“0”,则表示UE不允许或去使能或禁止PHR发送。备选地,包含PHR发送许可的MAC CE可以仅用于PHR发送许可,称为PHR发送许可MAC CE,其有对应的MAC子头和LCID。
若所述PHR发送许可包含在层1信令中,优选地,所述层1信令可以是承载在PDCCH的DCI。若PHR发送许可比特置为“1”,则表示允许或使能PHR发送;若置为“0”,则表示UE不允许或去使能或禁止PHR发送。
在步骤3中,若步骤2中被配置了PHR配置或PHR发送被允许或被使能,则UE启动PHR过程。所述启动PHR过程也可描述为激活PHR过程或使能PHR过程。可选地,所述启动PHR过程包括启动相关定时器、触发或上报PHR。
UE侧实施例13
本实施例给出了UE获取基站是否允许PHR发送请求的方法。所述“允许”可以和“支持”“使能”“激活”替换,所述“不支持”“不允许”可以和“去使能”“去激活”替换。
在一种实施方式中,UE从基站接收第五指示信息,所述第五指示信息用于指示所述小区(是否)允许PHR发送请求。优选地,若所述第五指示信息存在,则该小区允许PHR发送请求;若所述指示信息不存在,则该小区不允许PHR发送请求。备选地,若所述指示信息置为“TRUE”或“1”,则该小区允许PHR发送请求;若所述指示信息置为“FALSE”或“0”,则该小区不允许PHR发送请求。可选地,所述第五指示信息包含在系统信息中如系统信息块1或系统信息块2中。备选地,所述第五指示信息包含在专用RRC消息中如RRC连接重配置消息或RRC连接建立消息或RRC连接重建立消息或RRC连接恢复消息中,更进一步地,包含在RRC消息中的MAC-mainconfig信息元素中。备选地,所述第五指示信息包含在MAC CE中,该MAC CE有对应的MAC子头和LCID。
在一种实施方式中,UE从基站接收RRC消息,若RRC消息中包含Release 15或后续版本特定的RRC信息元素,则UE认为该基站是Release15基站或Release15后续版本基站,即UE认为该基站允许PHR发送请求。否则,若RRC消息中不包含Release 15或后续版本特定的RRC信息元素,则UE认为该基站是Release14基站或Release14之前版本基站,即UE认为该基站不允许PHR发送请求。优选地,所述RRC消息是系统信息。本实施方式中认为所有Release15基站及后续版本基站都支持PHR发送请求。
UE侧实施例14
本实施例给出了一种UE是否支持PHR发送请求能力上报的方法。在UE上执行,更进一步地在NB-IoT UE上执行。
步骤1:UE从基站接收UE能力问询(UECapabilityEnquiry)消息,该消息用于请求UE无线接入能力的传递。所述UE无线接入能力包括E-UTRA无线接入能力以及其他无线接入技术的无线接入能力。
步骤2:UE向基站发送UE能力信息(UECapabilityInformation)消息,其中包含UE支持或是否支持PHR发送请求的第六指示信息。更进一步地,若第六指示信息设置为“supported”,则表示UE支持PHR发送请求;若指示信息不存在,则表示UE不支持PHR发送请求。
可选地,所述第六指示信息可以是区分TDD和FDD的,即第六指示信息可以包括两部分:一部分用于指示对TDD系统UE支持或是否支持PHR发送请求;另一部分指示对FDD系统UE支持或是否支持PHR发送请求。
以下将参照图12,对根据本发明示例性实施例的UE的结构进行描述。图12示意性地示出了根据本发明示例性实施例的UE的结构框图。UE 1100可以用于分别执行参考图5和6描述的方法500和600以及在上述附加实施例1至8中描述的方法。为了简明,在此仅对根据本公开示例性实施例的UE的示意性结构进行描述,而省略了如前参考图5和6描述的方法500和600以及在上述附加实施例中描述的方法中已经详述过的细节。
如图12所示,UE 1200包括用于外部通信的通信接口1201;处理单元或处理器1202,该处理器1202可以是单个单元或者多个单元的组合,用于执行方法的不同步骤;存储器1203,其中存储有计算机可执行指令。
在UE 1200用于执行方法500的实施例中,所述指令在被处理器1202执行时,使处理器1202执行以下过程:
从基站接收系统信息,所述系统信息包括用于指示所述基站支持或是否支持DPR的指示信息;以及
根据UE支持扩展DPR的能力信息和接收到的指示所述基站支持扩展DPR的指示信息,确定在Msg3中向基站发送扩展DPR。
在一示例性实施例中,扩展DPR由针对公共控制信道CCCH服务数据单元SDU的媒体接入控制MAC子头中或单独设置的媒体接入控制MAC子头中的逻辑信道标识LCID进行标识,所述LCID的值在LCID预留值中选取,或重用用于标识其他MAC CE的LCID值。
在一示例性实施例中,在满足以下条件中的至少一个的情况下,根据UE支持扩展DPR的能力信息和接收到的指示所述基站支持扩展DPR的指示信息,确定在Msg3中向基站发送扩展DPR:
UE要发送的数据量超过第一预定门限值;
UE的覆盖增强等级不超过第二预定门限值;
UE的电量不超过第三预定门限值,
其中所述第一、第二和第三预定门限值由系统预定义或从基站发送的无线资源控制RRC消息中获取。
在UE 1200用于执行方法600的实施例中,所述指令在被处理器1202执行时,使处理器1202执行以下过程:
从基站接收用于请求UE无线接入能力的传递的UE能力问询消息;以及
向基站发送UE能力信息消息,所述UE能力信息消息包含UE支持或是否支持扩展数据量和功率余量报告DPR的指示信息。
以下将参照图13,对根据本公开示例性实施例的在基站处执行的接收扩展DPR的方法进行描述。
图13示出了根据本公开示例性实施例的在基站处执行的接收扩展DPR的方法1300的流程图。如图13所示,方法1300可以包括步骤S1301和S1302。
在步骤S1301中,基站向UE发送系统信息,所述系统信息包括用于指示所述基站支持或是否支持扩展DPR的指示信息(即,前述第一指示信息)。
在一种实施方式中,基站向UE发送第一指示信息,所述第一指示信息可以指示基站所服务的小区允许或是否允许扩展DPR或者说允许或是否允许发送扩展DPR。优选地,若所述第一指示信息存在,则该小区允许扩展DPR或者说允许发送扩展DPR;若所述第一指示信息不存在,则该小区不允许扩展DPR或者说不允许发送扩展DPR。备选地,若所述第一指示信息被置为“TRUE”或“1”,则该小区允许扩展DPR或者说允许发送扩展DPR;若所述第一指示信息被置为“FALSE”或“0”,则该小区不允许扩展DPR或者说不允许发送扩展DPR。优选地,所述第一指示信息包含在系统信息中如系统信息块1或系统信息块2中,所述系统信息可以由RRC消息承载。
在S1301的另一实施方式中,基站向UE发送RRC消息,若RRC消息中包含Release 15或后续版本特定的RRC信息元素,则该基站是Release15基站或Release15后续版本基站,即该基站允许扩展DPR或者允许发送扩展DRP或者说支持扩展DPR。否则,若RRC消息中不包含Release 15或后续版本特定的RRC信息元素,则该基站是Release14基站或Release14之前版本基站,即该基站不允许扩展DPR或者不允许发送扩展DRP或者说不支持扩展DPR。优选地,所述RRC消息是系统信息。本实施方式中认为所有Release15基站及后续版本基站都支持或允许扩展DPR。
在步骤S1302中,基站可以从UE接收在Msg3中发送的DPR。
方法1300还可以包括以下步骤(未示出):通过检测针对CCCH SDU的MAC子头或单独设置的MAC子头中的LCID的值,确定接收到的DPR是扩展DPR还是传统DPR,其中如果检测到所述LCID值是LCID预留值、或是重用用于标识其他MAC CE的LCID值,则确定接收到的DPR是扩展DPR。
在另一实施方式中,基站可以在RRC消息中向UE发送包含预定条件相关门限值的配置信息。所述RRC消息可以是专用RRC消息如RRC连接重配置消息,也可以是系统信息。
如前所述,所述预定条件门限值可以由UE用于确定发送的DPR的类型。
尽管以上是以在基站处执行接收扩展DPR的完整过程进行描述的,但是本公开的实施例不仅包括上述完整过程,还包括在以下各个实施例中描述的与扩展DPR相关的单独的实现。
基站侧实施例1
本实施例给出了一种区别传统DPR和扩展DPR的方法。通过该实施例,基站发送接收DPR时可以区别传统DRP和扩展DPR,从而正确进行解码/解析。
本实施例中,与传统DPR类似,扩展DPR由用于CCCH SDU的MAC子头标识,其没有增加任何额外的MAC子头且总是放置于CCCH SDU前面。不同与传统DPR的是,标识扩展DPR的用于CCCH SDU的MAC子头中的LCID为一个新的LCID值,其值在LCID预留值01101~10011中选取,例如“01101”。备选地,也可以重用LTE系统中其他MAC CE对应的LCID值,如重用长BSR的LCID“11110”或重用短BSR的LCID“11101”或重用截断BSR的LCID“11100”或重用PHR的LCID“11010”或重用扩展PHR的LCID“11001”或重用双连接PHR的LCID“11000”等。因为上述被重用的MAC CE和扩展DPR不会同时出现在msg3中,所以重用这些MAC CE对应的LCID不会造成混淆。
对基站而言,若CCCH SDU对应子头中的LCID为“00000”,则CCCH SDU前的DPR为传统DPR;否则CCCH SDU前的DPR为扩展DPR。
基站侧实施例2
本实施例给出了另一种区别传统DPR和扩展DPR的方法。
本实施例中,不同于传统DPR,扩展DPR对应一个MAC子头,即扩展DPR对应的MAC子头是不与CCCH SDU或其他MAC SDU/CE共用的。所述扩展DPR采用其对应MAC子头中的LCID来标识。例如,优选地,所述LCID可以是一个新的值“10011”,备选地,也可以重用LTE系统中其他MAC CE对应的LCID值,如重用长BSR的LCID“11110”或重用短BSR的LCID“11101”或重用截断BSR的LCID“11100”或重用PHR的LCID“11010”或重用扩展PHR的LCID“11001”或重用双连接PHR的LCID“11000”等。因为上述被重用的MAC CE和扩展DPR不会同时出现在msg3中,所以重用这些MAC CE对应的LCID不会造成混淆。
对扩展DPR,其在MAC PDU的位置可以在MAC SDU之前MAC头之后的任何位置,即不限于仅被放置在CCCH SDU前面。
基站侧实施例3
本实施例给出了一种确定在Msg3中要发送的DPR类型的方法。与UE侧实施例4相对应,提供一种预定条件的配置方式。所述DPR类型包括传统DPR和扩展DPR。
基站向UE下发包含预定条件相关门限值的配置信息。更进一步地,所述RRC消息可以是专用RRC消息如RRC连接重配置消息,也可以是系统信息。
如UE侧实施例4所述,所述预定条件门限值用于UE确定发送的DPR的类型。
在一种实施方式中,所述预定条件门限值为数据量值,称第一预定门限值。所述预定条件为有或是否有更多的数据要发送或者要发送的数据量超过或是否超过第一预定门限值。所述预定条件满足指有更多的数据要发送或者要发送的数据量大于或大于等于第一预定门限值。所述预定条件不满足指的是没有更多的数据要发送或者要发送的数据量小于或小于等于所述第一预定门限值。
在另一种实施方式中,所述预定条件也可以为UE的覆盖增强等级不超过或是否不超过第二预定门限值。所述预定条件满足指UE的覆盖增强等级不超过第二预定门限值,所述预定条件不满足指UE的覆盖增强等级超过第二预定门限值。在另一实施方式中,预定条件也可以为UE的覆盖增强等级不低于或是否不低于第二预定门限值。所述预定条件满足指UE的覆盖增强等级不低于第二预定门限值,所述预定条件不满足指UE的覆盖增强等级低于第二预定门限值。
在又一种实施方式中,所述预定条件门限值为电量值,称第三预定门限值。所述预定条件为UE的电量是或是否是低电量或UE的电量低于或是否低于第三预定门限值。所述预定条件满足指UE的电量是低电量或UE的电量小于或小于等于第三预定门限值。所述预定条件不满足指的是UE的电量不是低电量或UE的电量大于或大于等于第三预定门限值。所述UE的电量可以指UE的电池电量。
基站侧实施例4
本实施例给出了基站告知UE支持或是否支持扩展DPR信息的方法。所述“支持”和“允许”可以替换。
在一种实施方式中,基站向UE发送第一指示信息,所述指示信息用于指示在该小区允许或是否允许扩展DPR或者说允许或是否允许发送扩展DPR。优选地,若所述指示信息存在,则该小区允许扩展DPR或者说允许发送扩展DPR;若所述指示信息不存在,则该小区不允许扩展DPR或者说不允许发送扩展DPR。备选地,若所述指示信息置为“TRUE”或“1”,则该小区允许扩展DPR或者说允许发送扩展DPR;若所述指示信息置为“FALSE”或“0”,则该小区不允许扩展DPR或者说不允许发送扩展DPR。优选地,所述指示信息包含在系统信息中如系统信息块1或系统信息块2中。
在一种实施方式中,基站向UE发送RRC消息,若RRC消息中包含Release 15或后续版本特定的RRC信息元素,则该基站是Release15基站或Release15后续版本基站,即该基站允许扩展DPR或者允许发送扩展DRP或者说支持扩展DPR。否则,若RRC消息中不包含Release15或后续版本特定的RRC信息元素,则该基站是Release14基站或Release14之前版本基站,即该基站不允许扩展DPR或者不允许发送扩展DRP或者说不支持扩展DPR。优选地,所述RRC消息是系统信息。本实施方式中认为所有Release15基站及后续版本基站都支持或允许扩展DPR。
以下将参照图14,对根据本公开示例性实施例的在基站处执行的获取UE支持或是否支持扩展DPR能力的方法进行描述。
图14示意性地示出了根据本公开示例性实施例的在基站处执行的获取UE支持或是否支持扩展DPR能力的方法1400的流程图。如图14所述,方法1400可以包括步骤S1401和S1402。
在步骤S1401中,基站可以向UE发送用于请求UE无线接入能力的传递的UE能力问询消息;以及
在步骤S1402中,基站可以从UE接收UE能力信息消息,所述UE能力信息消息包含UE支持或是否支持DPR的指示信息(为了避免混淆,以下称为第二指示信息)。在一示例中,若该第二指示信息被设置为“supported”,则表示UE支持扩展DPR;若该第二指示信息不存在,则表示UE不支持扩展DPR。
可选地,该第二指示信息可以是区分时分复用(Time Division Duplex,TDD)系统和频分复用(Frequency Division Duplex,FDD)系统的,即第二指示信息可以包括两部分:一部分用于指示对TDD系统UE支持或是否支持扩展DPR;另一部分指示对FDD系统UE支持或是否支持扩展DPR。
以下将对基站侧执行的本公开的其他示例性实施例进行描述。
在Msg3之后发送的PHR机制-基站侧
本公开中,Msg3之后发送PHR也可描述为Msg3之后的PHR,或者描述为不在Msg3中的PHR,或者描述为不和Msg3一起发送的PHR,或者描述为PHR MAC CE发送。
基站侧实施例5
本实施例给出了基站告知UE其支持或是否支持在Msg3之后发送PHR的方法。在一种实施方式中,基站向UE发送第三指示信息,所述第三指示信息用于指示在该小区(是否)允许在Msg3之后发送PHR。也可描述为所述指示信息用于指示所述小区(是否)支持在Msg3之后发送PHR。优选地,若所述第三指示信息存在,则该小区允许在Msg3之后发送PHR或者说该小区支持在Msg3之后发送PHR;若所述指示信息不存在,则该小区不允许在Msg3之后发送PHR或者说该小区不支持在Msg3之后发送PHR。备选地,若所述指示信息置为“TRUE”或“1”,则该小区允许在Msg3之后发送PHR或者说该小区支持在Msg3之后发送PHR;若所述指示信息置为“FALSE”或“0”,则该小区不允许在Msg3之后发送PHR或者说该小区不支持在Msg3之后发送PHR。优选地,所述第三指示信息包含在系统信息中如系统信息块1或系统信息块2中。备选地,所述第三指示信息包含在专用RRC消息中如RRC连接重配置消息或RRC连接建立消息或RRC连接重建立消息或RRC连接恢复消息中,更进一步地,包含在RRC消息中的MAC-mainconfig信息元素中。
在一种实施方式中,基站向UE发送RRC消息,若RRC消息中包含Release 15或后续版本特定的RRC信息元素,则该基站是Release15基站或Release15后续版本基站,即该基站允许在Msg3之后发送PHR或者说支持在Msg3之后发送PHR。否则,若RRC消息中不包含Release 15或后续版本特定的RRC信息元素,则该基站是Release14基站或Release14之前版本基站,即该基站不允许在Msg3之后发送PHR或者说不支持在Msg3之后发送PHR。优选地,所述RRC消息是系统信息。本实施方式中认为所有Release15基站及后续版本基站都支持或允许在Msg3之后发送PHR。
基站侧实施例6
本实施例给出了一种基站获取UE是否支持在Msg3之后发送PHR能力的方法。
步骤1:基站向UE发送UE能力问询(UECapabilityEnquiry)消息,该消息用于请求UE无线接入能力的传递。所述UE无线接入能力包括E-UTRA无线接入能力以及其他无线接入技术的无线接入能力。
步骤2:基站从UE接收UE能力信息(UECapabilityInformation)消息,其中包含UE支持或是否支持在Msg3之后发送PHR的第四指示信息。更进一步地,若第四指示信息设置为“supported”,则表示UE支持在Msg3之后发送PHR;若指示信息不存在,则表示UE不支持在Msg3之后发送PHR。
可选地,所述第四指示信息可以是区分TDD和FDD的,即第四指示信息可以包括两部分:一部分用于指示对TDD系统UE支持或是否支持在Msg3之后发送PHR;另一部分指示对FDD系统UE支持或是否支持在Msg3之后发送PHR。
基站侧实施例7
本实施例给出了一种激活/去激活在Msg3之后发送PHR的方法。
步骤1:基站发送在Msg3之后发送PHR的激活/去激活指示
步骤2:若所述在Msg3之后发送PHR的激活/去激活指示为激活,则接收PHR。
优选地,所述在Msg3之后发送PHR的激活/去激活指示为MAC CE;备选地,所述在Msg3之后发送PHR的激活/去激活指示为层1信令,如包含在PDCCH中。
所述在Msg3之后发送的PHR其初始状态为预定义的,即预定义其初始状态为去激活(或激活)。或者其初始状态通过RRC消息来配置。
可选地,定义一个PHR去激活定时器。基站通过RRC消息向UE配置该PHR去激活定时器的值。
UE请求的PHR发送机制-基站侧
本部分中,所述PHR包括msg3之后发送的PHR。本部分下述实施例提供了UE请求的PHR发送的方法。UE请求的PHR发送也可描述为PHR请求或PHR发送请求或UE请求的PHR。优选地,所述请求用于请求多次PHR发送;备选地,所述请求用于请求一次PHR发送。
所述PHR可以替换成“BSR”或者“PHR和BSR”或者上文所述“BPR”。
基站侧实施例8
本实施例提供了一种涉及PHR发送请求的方法,包括下述步骤。
步骤1:基站接收UE发送的PHR发送请求。
步骤2:向UE发送PHR发送许可。
步骤3:接收UE发送的PHR。该步骤是可选的。
步骤1中所述UE发送的PHR发送请求可以包含在RRC信令中,也可以包含在MAC CE中,还可以是包含在层1信令中。更进一步地,下述给出几种方式。
在一种实施方式中,所述PHR发送请求包含在DPR中。若DPR中PHR发送请求比特置为“1”,则表示UE请求PHR发送;若置为“0”,则表示UE不请求PHR发送。
在一种实施方式中,所述PHR发送请求为单独的MAC CE,其格式示例如图9,称其为PHR发送请求MAC CE,其有对应的MAC子头及关联的LCID。
在一种实施方式中,所述PHR发送请求包含在RRC连接请求消息中或RRC连接建立完成消息中或RRC连接重建立完成中或RRC连接重配置完成中或RRC连接恢复完成中。若所述RRC消息中PHR发送请求信息元素置为“Ture”或“1”或“required”,则表示UE请求PHR发送,若所述RRC消息中PHR发送请求信息元素置为“False”或“0”或“not required”或不存在,则表示UE不请求PHR发送。
所述UE请求PHR发送也可表述为PHR可用或PHR发送(是否)需要或UE(是否)请求PHR发送。
步骤2中,所述PHR发送许可包含在RRC消息中或包含在MAC CE中或包含在层1信令中。
若所述PHR发送许可包含在RRC消息中,优选地,所述PHR发送许可是包含在PHR配置信息元素中的PHR发送许可指示信息元素;若所述PHR发送许可指示信息元素置为“Ture”或“1”或“setup”,则表示允许或使能PHR发送,若所述RRC消息中PHR发送请求信息元素置为“False”或“0”或不存在,则表示不允许或去使能或禁止PHR发送。
若所述PHR发送许可包含在RRC消息中,备选地,所述PHR发送许可是PHR配置,所述PHR配置包括周期PHR定时器配置、禁止PHR定时器配置、下行路径损耗改变配置等中的一种或多种。若PHR配置包含在RRC消息中,则表示允许或使能PHR发送;若PHR配置不包含在RRC消息中或PHR配置为“release”,则表示不允许或去使能或禁止PHR发送。
若所述PHR发送许可包含在MAC CE中,则若PHR发送许可比特置为“1”,则表示允许或使能PHR发送;若置为“0”,则表示UE不允许或去使能或禁止PHR发送。备选地,包含PHR发送许可的MAC CE可以仅用于PHR发送许可,称为PHR发送许可MAC CE,其有对应的MAC子头和LCID。
若所述PHR发送许可包含在层1信令中,优选地,所述层1信令可以是承载在PDCCH的DCI。若PHR发送许可比特置为“1”,则表示允许或使能PHR发送;若置为“0”,则表示UE不允许或去使能或禁止PHR发送。
基站侧实施例9
本实施例给出了基站告知UE基站是否允许PHR发送请求的方法。所述“允许”可以和“支持”“使能”“激活”替换,所述“不支持”“不允许”可以和“去使能”“去激活”替换。
在一种实施方式中,基站向UE发送第五指示信息,所述第五指示信息用于指示所述小区(是否)允许PHR发送请求。优选地,若所述第五指示信息存在,则该小区允许PHR发送请求;若所述指示信息不存在,则该小区不允许PHR发送请求。备选地,若所述指示信息置为“TRUE”或“1”,则该小区允许PHR发送请求;若所述指示信息置为“FALSE”或“0”,则该小区不允许PHR发送请求。可选地,所述第五指示信息包含在系统信息中如系统信息块1或系统信息块2中。备选地,所述第五指示信息包含在专用RRC消息中如RRC连接重配置消息或RRC连接建立消息或RRC连接重建立消息或RRC连接恢复消息中,更进一步地,包含在RRC消息中的MAC-mainconfig信息元素中。备选地,所述第五指示信息包含在MAC CE中,该MAC CE有对应的MAC子头和LCID。
在一种实施方式中,基站向UE发送RRC消息,若RRC消息中包含Release 15或后续版本特定的RRC信息元素,则该基站是Release15基站或Release15后续版本基站,即该基站允许PHR发送请求。否则,若RRC消息中不包含Release 15或后续版本特定的RRC信息元素,则该基站是Release14基站或Release14之前版本基站,即该基站不允许PHR发送请求。优选地,所述RRC消息是系统信息。本实施方式中认为所有Release15基站及后续版本基站都支持PHR发送请求。
基站侧实施例10
本实施例给出了一种基站获取UE是否支持PHR发送请求能力的方法。
步骤1:基站向UE发送UE能力问询(UECapabilityEnquiry)消息,该消息用于请求UE无线接入能力的传递。所述UE无线接入能力包括E-UTRA无线接入能力以及其他无线接入技术的无线接入能力。
步骤2:基站从UE接收UE能力信息(UECapabilityInformation)消息,其中包含UE是否支持PHR发送请求的第六指示信息。更进一步地,若第六指示信息设置为“supported”,则表示UE支持PHR发送请求;若指示信息不存在,则表示UE不支持PHR发送请求。
可选地,所述第六指示信息可以是区分TDD和FDD的,即第六指示信息可以包括两部分:一部分用于指示对TDD系统UE支持或是否支持PHR发送请求;另一部分指示对FDD系统UE支持或是否支持PHR发送请求。
在本公开的示例性实施例中,下述指示信息的任何几个可以是联合指示的:
-用于指示小区允许或是否允许扩展DPR的所述第一指示信息;
-用于指示小区支持或是否支持在Msg3之后发送PHR的所述第三指示信息。
-用于指示小区允许或是否允许PHR发送请求的所述第五指示信息。
所述联合指示的指的是用单个指示可以表示上述任意几个指示信息。比如:用单个指示既可以指示所述第一指示信息又可以指示所述第三指示信息,此时,当该单个指示设置为“1”或“Ture”时,指示小区允许扩展DPR和允许在Msg3之后发送PHR。
本公开中,下述指示信息的任何几个可以是联合指示的:
-用于指示UE支持或是否支持扩展DPR的所述第二指示信息;
-用于指示UE支持或是否持在Msg3之后发送PHR的所述第四指示信息。
-用于指示UE支持或是否支持PHR发送请求的所述第六指示信息。
所述联合指示的指的是用单个指示可以表示上述任意几个指示信息。比如:用单个指示既可以指示所述第二指示信息又可以指示所述第四指示信息,此时,当该单个指示设置为“supported”时,指示UE支持扩展DPR和在Msg3之后发送PHR。
以下将参照图15,对根据本发明示例性实施例的基站的结构进行描述。图15示意性地示出了根据本发明示例性实施例的基站的结构框图。基站1500可以用于分别执行参考图13和14描述的方法1300和1400以及在上述附加实施例9至14中描述的方法。为了简明,在此仅对根据本公开示例性实施例的基站的示意性结构进行描述,而省略了如前参考图13和14描述的方法1300和1400以及在上述附加实施例中描述的方法中已经详述过的细节。
如图15所示,基站1500包括用于外部通信的通信接口1501;处理单元或处理器1502,该处理器1502可以是单个单元或者多个单元的组合,用于执行方法的不同步骤;存储器1503,其中存储有计算机可执行指令。
在基站1500用于执行方法1300的实施例中,所述指令在被处理器1502执行时,使处理器1502执行以下过程:
向UE发送系统信息,所述系统信息包括用于指示所述基站支持或是否支持扩展数据量和功率余量报告DPR的指示信息;以及
从UE接收在Msg3 Msg3中发送的DPR。
在一示例性实施例中,所述指令在被处理器1502执行时,还使处理器1502执行以下过程:通过检测针对公共控制信道CCCH服务数据单元SDU的媒体接入控制MAC子头或单独设置的媒体接入控制MAC子头中的逻辑信道标识LCID的值,确定接收到的DPR是扩展DPR还是传统DPR,其中如果检测到所述LCID值是LCID预留值、或是重用用于标识其他MAC CE的LCID值,则确定接收到的DPR是扩展DPR。
在基站1500用于执行方法1400的实施例中,所述指令在被处理器1502执行时,使处理器1502执行以下过程:
向UE发送用于请求UE无线接入能力的传递的UE能力问询消息;以及
从UE接收UE能力信息消息,所述UE能力信息消息包含UE支持或是否支持扩展数据量和功率余量报告DPR的指示信息。
运行在根据本公开的设备上的程序可以是通过控制中央处理单元(CPU)来使计算机实现本公开的实施例功能的程序。该程序或由该程序处理的信息可以临时存储在易失性存储器(如随机存取存储器RAM)、硬盘驱动器(HDD)、非易失性存储器(如闪速存储器)、或其他存储器系统中。
用于实现本公开各实施例功能的程序可以记录在计算机可读记录介质上。可以通过使计算机系统读取记录在所述记录介质上的程序并执行这些程序来实现相应的功能。此处的所谓“计算机系统”可以是嵌入在该设备中的计算机系统,可以包括操作系统或硬件(如外围设备)。“计算机可读记录介质”可以是半导体记录介质、光学记录介质、磁性记录介质、短时动态存储程序的记录介质、或计算机可读的任何其他记录介质。
用在上述实施例中的设备的各种特征或功能模块可以通过电路(例如,单片或多片集成电路)来实现或执行。设计用于执行本说明书所描述的功能的电路可以包括通用处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)、或其他可编程逻辑器件、分立的门或晶体管逻辑、分立的硬件组件、或上述器件的任意组合。通用处理器可以是微处理器,也可以是任何现有的处理器、控制器、微控制器、或状态机。上述电路可以是数字电路,也可以是模拟电路。因半导体技术的进步而出现了替代现有集成电路的新的集成电路技术的情况下,本公开的一个或多个实施例也可以使用这些新的集成电路技术来实现。
此外,本公开并不局限于上述实施例。尽管已经描述了所述实施例的各种示例,但本公开并不局限于此。安装在室内或室外的固定或非移动电子设备可以用作终端设备或通信设备,如AV设备、厨房设备、清洁设备、空调、办公设备、自动贩售机、以及其他家用电器等。
如上,已经参考附图对本公开的实施例进行了详细描述。但是,具体的结构并不局限于上述实施例,本公开也包括不偏离本公开主旨的任何设计改动。另外,可以在权利要求的范围内对本公开进行多种改动,通过适当地组合不同实施例所公开的技术手段所得到的实施例也包含在本公开的技术范围内。此外,上述实施例中所描述的具有相同效果的组件可以相互替代。