CN110831248A - 一种通知方法、装置及基站 - Google Patents

一种通知方法、装置及基站 Download PDF

Info

Publication number
CN110831248A
CN110831248A CN201810914051.3A CN201810914051A CN110831248A CN 110831248 A CN110831248 A CN 110831248A CN 201810914051 A CN201810914051 A CN 201810914051A CN 110831248 A CN110831248 A CN 110831248A
Authority
CN
China
Prior art keywords
message
rlc
drb
lcid
processing
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN201810914051.3A
Other languages
English (en)
Other versions
CN110831248B (zh
Inventor
罗海燕
杨旭东
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority to CN201810914051.3A priority Critical patent/CN110831248B/zh
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Priority to CN202110844100.2A priority patent/CN113784457B/zh
Priority to EP19848173.1A priority patent/EP3820238B1/en
Priority to PCT/CN2019/100098 priority patent/WO2020030154A1/zh
Priority to EP23219018.1A priority patent/EP4362600A2/en
Priority to AU2019319488A priority patent/AU2019319488B2/en
Publication of CN110831248A publication Critical patent/CN110831248A/zh
Priority to US17/169,800 priority patent/US11963131B2/en
Application granted granted Critical
Publication of CN110831248B publication Critical patent/CN110831248B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W76/00Connection management
    • H04W76/20Manipulation of established connections
    • H04W76/22Manipulation of transport tunnels
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W68/00User notification, e.g. alerting and paging, for incoming communication, change of service or the like
    • H04W68/005Transmission of information for alerting of incoming communication
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W76/00Connection management
    • H04W76/10Connection setup
    • H04W76/11Allocation or use of connection identifiers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W76/00Connection management
    • H04W76/10Connection setup
    • H04W76/15Setup of multiple wireless link connections
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W76/00Connection management
    • H04W76/10Connection setup
    • H04W76/15Setup of multiple wireless link connections
    • H04W76/16Involving different core network technologies, e.g. a packet-switched [PS] bearer in combination with a circuit-switched [CS] bearer
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W76/00Connection management
    • H04W76/10Connection setup
    • H04W76/19Connection re-establishment
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W76/00Connection management
    • H04W76/20Manipulation of established connections
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W76/00Connection management
    • H04W76/30Connection release
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W80/00Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/02Data link layer protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W88/00Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/08Access point devices
    • H04W88/085Access point devices with remote components

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

本申请实施例提供一种通知方法、装置及基站,涉及通信领域,实现在CU‑DU架构中保证DU进行准确的L2处理。具体包括:CU向DU发送第一消息,第一消息包括发生承载类型切换的第一DRB的ID以及指示DU执行L2处理的第一指示信息,或者,第一消息包括第一DRB的ID以及指示发生承载类型切换的第二指示信息;CU接收DU发送的第二消息,第二消息包括L2处理的小区组配置。

Description

一种通知方法、装置及基站
技术领域
本申请涉及通信领域,尤其涉及一种通知方法、装置及基站。
背景技术
随着通信技术的飞速发展,移动通信已进入第五代移动通信技术(5th-generation,5G)时代。面向5G,基于集中单元-分布单元(centralized unit-distributedunit,CU-DU)的两级接入网架构也已经被业界所认可,这一网络架构与无线云化的结合,构成了5G云无线接入网(cloud radio access network,C-RAN)的两个基本要素。由此可见,CU-DU架构是研究C-RAN的基础。
目前,5G无线接入网(radio access network,RAN)架构考虑基站采用CU和DU独立部署的方式,以更好地满足各场景和应用的需求。一个基站可以包括一个CU和一个或多个DU。基站的CU-DU划分方式对外不可见。在基站为CU-DU架构时,对协议层进行了分割,无线链路控制层(radio link control,RLC)/媒体接入控制层(media access control,MAC)/物理层(port physical layer,PHY)层由DU负责,而CU负责无线资源控制(radio resourcecontrol,RRC)/服务数据适配协议(service data adaptation protocol,SDAP)/分组数据汇聚协议(packet data convergence protocol,PDCP)层,CU/DU对各自负责的协议层进行相关配置。
在网络应用中,需要进行层2(layer 2,L2)处理的情况(例如承载类型切换或者RLC失败)时时发生。而CU-DU架构中,DU如何获知需要进行L2处理的情况,对RLC层及MAC层进行对应的配置,成为亟待解决的问题。
发明内容
本申请实施例提供一种通知方法、装置及基站,实现在CU-DU架构中保证DU进行准确的L2处理。
为达到上述目的,本申请的实施例采用如下技术方案:
第一方面,本申请提供一种通知方法,应用于CU-DU架构中的CU,该方法可以包括:CU向DU发送第一消息,第一消息包括发生承载类型切换的第一数据无线承载(data readiobearer,DRB)的标识(identity,ID)以及指示DU执行L2处理的第一指示信息;或者,第一消息包括第一DRB的ID以及指示发生承载类型切换的第二指示信息。CU接收DU发送的第二消息,第二消息包括L2处理的小区组配置。
通过本申请提供的通知方法,CU将发生承载类型切换的第一DRB的ID以及DU执行L2处理的方案的第一指示信息通知给DU;或者,CU将第一DRB的ID通知给DU并通过第二指示信息通知DU发生了承载类型切换。这样一来,使得DU获知发生了承载类型切换的DRB ID以及L2处理的方案;或者,使得DU获知哪些DRB发生了承载类型切换,便于DU执行准确对应的L2处理,以进行适应用户设备通信链路变化的L2配置。
其中,承载类型切换,即bearer type change,是在支持多种承载类型的网络中,根据业务需求切换承载的一种网络操作。
第一指示信息用于指示CU决策的由DU执行L2处理的具体方案,该指示信息的类型以及内容可以根据实际需求配置,本申请对此不进行具体限定。例如,第一指示信息可以为L2处理的名称信息,即可以定义每个L2处理的方案的名称,将方案名称作为第一指示信息;或者,第一指示信息可以为L2处理的内容信息,即也可以采用L2处理的方案内容作为第一指示信息;或者,第一指示信息可以为L2处理的标识信息,也可以配置每个L2处理的方案的标识,将该标识作为第一指示信息。当然,凡是可以用来指示L2处理的具体方案的信息,均可以作为第一指示信息。
第二指示信息用于向DU通知发生了承载类型切换,该第二指示信息的形式以及内容可以根据实际需求配置,本申请对此不进行具体限定。例如,第二指示信息可以为承载类型切换这个网络操作的名称信息,即将“bearer type change”或者“key change”或者“bearer type change with key change”字段作为第二指示信息;或者,第二指示信息可以为承载类型切换这个网络操作的表示信息,即网络中定义一个承载类型切换这种网络操作的网络标识,用于唯一指示发生了承载类型切换,将该网络标识作为第一指示信息等等。凡是可以用来指示发生了承载类型切换这一网络操作的信息,均可以作为第二指示信息。
需要说明的是,第一DRB可以为至少一个DRB。对于每一个第一DRB执行相同的L2处理或不同的L2处理,本申请以处理一个第一DRB描述具体方案,其他不再进行赘述。
结合第一方面,在一种可能的实现方式中,本申请提供几种具体的执行L2处理的方案,执行L2处理具体可以包括:MAC重置(MAC reset)以及RLC重建立(RLC re-establishment);或者,更改逻辑信道标识(logical channel identify,LCID)(change ofLCID)以及RLC重建立;或者,MAC同步重配置(MAC reset by reconfiguration with sync)以及RLC重建立;或者,更改LCID以及RLC承载释放和增加。特别地,MAC同步重配置具体可以理解为通过同步重配置实现MAC重置。
可选的,L2处理的具体方案可以参照第三代合作伙伴计划(3rd generationpartnership project,3GPP)协议中TS37.340v15.2.0或R2-1810953定义的表格A-1,名称为承载类型切换伴随或不伴随安全密钥改变的L2处理(L2handling for bearer typechange with and without security key change)中的具体方案,此处不再进行赘述。
结合第一方面或上述任一种可能的实现方式,在另一种可能的实现方式中,第一消息还可以包括主小区组(master cell group,MCG)指示,该MCG指示用于指示CU-DU架构的基站为双连接架构中的主节点(master node,MN)角色。在此情况下,DU执行L2处理可以包括:MAC重置以及RLC重建立;或者,更改LCID以及RLC重建立。
其中,MCG指示可以为MCG字符串本身,或者预先配置的其他字符或比特,例如,MCG/SCG指示包含枚举值为MCG,或者MCG/SCG指示=0则表示MCG,本申请对此不进行具体限定。
需要说明的是,本文中的双连接结构可以为演进的陆地无线接入网(evolveduniversal mobile telecommunications system terrestrial radio access network,E-UTRAN)及新无线电(new radio,NR)双连接(E-UTRAN-NR dual connectivity,EN-DC)架构,或者也可以为多无线接入类型双连接(multi-radio access type dualconnectivity,MR-DC)架构,或者也可以为NR-DC即新无线电双连接,或者也可以为长期演进(Long Term Evolution,LTE)DC即LTE双连接,或者其他双连接架构,本申请对此不进行具体限定。
结合第一方面或上述任一种可能的实现方式,在另一种可能的实现方式中,第一消息还可以包括辅小区组(secondary cell group,SCG)指示,该SCG指示用于指示CU-DU架构的基站为双连接架构中的辅节点(secondary node,SN)角色。在此情况下,DU执行L2处理可以包括:MAC同步重配置以及RLC重建立;或者,更改LCID以及RLC承载释放和增加。
其中,SCG指示可以为SCG字符串本身,或者预先配置的其他字符或比特,例如,MCG/SCG指示包含枚举值为SCG,或者MCG/SCG指示=1则表示SCG,本申请对此不进行具体限定。
结合第一方面或上述任一种可能的实现方式,在另一种可能的实现方式中,第一消息还可以包括:第二DRB的ID,第二DRB的ID用于替换第一DRB的ID。承载类型切换时,DRBID需要更换的情况中,第一消息通过包括第二DRB的ID以替换第一DRB的ID。
需要说明的是,承载类型切换时,切换后的承载标识也可以与切换前的承载标识一致,此时,第一消息中可以不包括第二DRB的ID。
结合第一方面或上述任一种可能的实现方式,在另一种可能的实现方式中,第一消息可以包括但不限于:UE上下文修改请求消息,或者,F1接口消息,或者,W1接口消息。当然,第一消息的类型可以根据实际需求选择,本申请对此不进行具体限定。
可选的,第一消息可以为CU-DU接口消息,即CU与DU之间的接口上传递的消息,当CU-DU架构的网络制式不同时,接口消息还可以定义不同的名称,本申请不进行具体限定。示例性的,F1接口消息是指新无线(new radio,NR)网络中,CU与DU之间的接口上传递的消息的统称。LTE网络中,CU-DU架构的基站中CU-DU之间的接口可以定义为W1接口,W1接口上传递的消息称之为W1消息。
其中,UE上下文修改请求消息为一种F1接口消息,当然,第一消息可以为其他类型的F1消息,本申请对此不进行具体限定。
结合第一方面或上述任一种可能的实现方式,在另一种可能的实现方式中,第二消息可以包括:UE上下文修改请求消息的响应消息。
在一种可能的实现方式中,若第一消息为请求响应机制的请求消息,则第二消息可以为第一消息的响应消息;若第一消息为非请求响应机制的消息,则第二消息为一条单独的消息。本申请对于第二消息的类型不进行具体限定。
结合第一方面或上述任一种可能的实现方式,在另一种可能的实现方式中,UE上下文修改请求消息中第一字段包括第一DRB的ID以及第一指示信息;或者,UE上下文修改请求消息中第一字段包括第一DRB的ID以及第二指示信息。其中,第一字段为UE上下文修改请求消息中任一个字段,本申请对此不进行具体限定。
需要说明的是,第一DRB的ID以及第一指示信息或者第一DRB的ID以及第二指示信息可以直接包含在第一消息中,与字段同一级,或者,也可以包括于第一消息中的一个字段中。本申请对此不进行具体限定。
结合第一方面或上述任一种可能的实现方式,在另一种可能的实现方式中,第一字段可以包括第一DRB的DRB修改列表字段。
结合第一方面或上述任一种可能的实现方式,在另一种可能的实现方式中,第一字段可以包括新增字段,该新增字段的名称可以根据实际需求配置,本申请对此不进行具体限定。
结合第一方面或上述任一种可能的实现方式,在另一种可能的实现方式中,若第一消息包括第一DRB的ID以及第一指示信息,本申请第一方面提供的通知方法还可以包括:CU决策执行L2处理的方案。在实际应用中,决策L2处理的方案的算法可以根据实际需求选择,本申请对此不进行具体限定。
结合第一方面或上述任一种可能的实现方式,在另一种可能的实现方式中,在CU接收DU发送的第二消息之后,本申请提供的通知方法还可以包括:CU向用户设备(userequipment,UE)发送包括小区组配置的RRC重配置消息,以使得UE按照包括L2处理的小区组配置进行相应的L2处理,保证网络通信的一致性。
在另一种可能的实现方式中,可以通过用户面(user plane,UP)实现本申请提供的通知方法。在此实现中,第一消息包括第一DRB ID对应的接口隧道端点标识(tunnelendpoint identify,TEID)以及第一指示信息;或者,第一消息包括第一DRB ID对应的TEID以及第二指示信息。或者,第一消息包括第一DRB ID对应的接口传输层地址以及第一指示信息;或者,第一消息包括第一DRB ID对应的接口传输层地址以及第二指示信息。或者,第一消息包括第一DRB ID对应的TEID、接口传输层地址以及第一指示信息;或者,第一消息包括第一DRB ID对应的TEID、接口传输层地址以及第二指示信息。其具体实现可以参考上述控制面的具体实现,此处不再一一赘述。此时,第一消息可以包括下行协议数据单元(protocol data unit,PDU)。
第二方面,本申请提供另一种通知方法,该方法应用于CU-DU架构中的DU,该方法可以包括:DU从CU接收第一消息,第一消息包括发生承载类型切换的第一DRB的ID以及指示DU执行L2处理的第一指示信息;或者,第一消息包括第一DRB的ID以及指示发生承载类型切换的第二指示信息;DU执行L2处理;DU向CU发送第二消息,第二消息包括L2处理的小区组配置。
通过本申请提供的通知方法,DU从CU获取发生承载类型切换的第一DRB的ID以及执行L2处理的第一指示信息;或者,DU从CU获取第一DRB的ID以及发生了承载类型切换的第二指示信息。这样一来,使得DU获知发生了承载类型切换的DRB ID以及L2处理的方案;或者,使得DU获知哪些DRB发生了承载类型切换,便于DU执行准确对应的L2处理,以进行适应用户设备通信链路变化的L2配置。
结合第二方面,在一种可能的实现方式中,若第一消息包括第一DRB的ID以及第二指示信息,DU执行L2处理,具体可以包括:DU决策并执行L2处理。在实际应用中,决策L2处理的方案的算法可以根据实际需求选择,本申请对此不进行具体限定。
结合第二方面或上述任一种可能的实现方式,在另一种可能的实现方式中,本申请提供几种具体的执行L2处理的方案,执行L2处理具体可以包括:MAC重置(MAC reset)以及RLC重建立(RLC re-establishment);或者,更改LCID(change of LCID)以及RLC重建立;或者,MAC同步重配置(MAC reset by reconfiguration with sync)以及RLC重建立;或者,更改LCID以及RLC承载释放和增加。特别地,MAC同步重配置具体可以理解为通过同步重配置实现MAC重置。
可选的,L2处理的具体方案可以参照3GPP协议中TS37.340定义的表格A-1中的具体方案,此处不再进行赘述。
结合第二方面或上述任一种可能的实现方式,在另一种可能的实现方式中,第一消息还可以包括MCG指示,该MCG指示用于指示CU-DU为双连接架构中的MN角色。在此情况下,DU执行L2处理可以包括:MAC重置以及RLC重建立;或者,更改LCID以及RLC重建立。
其中,MCG指示可以为MCG字符串本身,或者预先配置的其他字符或比特,例如,MCG/SCG指示包含枚举值为MCG,或者MCG/SCG指示=0则表示MCG,本申请对此不进行具体限定。
结合第二方面或上述任一种可能的实现方式,在另一种可能的实现方式中,第一消息还可以包括SCG指示,该SCG指示用于指示CU-DU为双连接架构中的SN角色。在此情况下,DU执行L2处理可以包括:MAC同步重配置以及RLC重建立;或者,更改LCID以及RLC承载释放和增加。
其中,SCG指示可以为SCG字符串本身,或者预先配置的其他字符或比特,例如,MCG/SCG指示包含枚举值为SCG,或者MCG/SCG指示=1则表示SCG,本申请对此不进行具体限定。
结合第二方面或上述任一种可能的实现方式,在另一种可能的实现方式中,第一消息还可以包括:第二DRB的ID,第二DRB的ID用于替换第一DRB的标识。承载类型切换时,DRB ID需要更换的情况,第一消息通过包括第二DRB的ID以替换第一DRB的ID。本申请第二方面提供的通知方法还可以包括:DU对第一DRB和/或第二DRB执行L2处理。
其中,DU对第一DRB和/或第二DRB执行L2处理,是指DU执行的L2处理中的一系列操作,操作对象可以是第一DRB、第二DRB中的一个或两个。例如,若DU执行的L2处理为RLC承载的释放和增加,则对第一DRB进行释放操作,对第二DRB进行增加操作。DU对第一DRB和/或第二DRB执行L2处理,就是DU执行L2处理时将第一DRB相关的所有配置关联到第二DRB。当执行change of LCID时,则DU将改变后的LCID和第二DRB标识关联。此外,DU还将第一DRB标识关联的F1接口用户面隧道和第二DRB标识关联。
需要说明的是,承载类型切换时,切换后的承载的ID也可以与切换前的承载ID一致,此时,第一消息中可以不包括第二DRB的ID。
结合第二方面或上述任一种可能的实现方式,在另一种可能的实现方式中,第一消息可以包括但不限于:UE上下文修改请求消息,或者,F1接口消息,或者,W1接口消息。当然,第一消息的类型可以根据实际需求选择,本申请对此不进行具体限定。
结合第二方面或上述任一种可能的实现方式,在另一种可能的实现方式中,第二消息可以包括:UE上下文修改请求消息的响应消息。
在一种可能的实现方式中,若第一消息为请求响应机制的消息,则第二消息可以为第一消息的响应消息;若第一消息为非请求响应机制的消息,则第二消息为一条单独的消息。本申请对于第二消息的类型不进行具体限定。
结合第二方面或上述任一种可能的实现方式,在另一种可能的实现方式中,UE上下文修改请求消息中第一字段包括第一DRB的ID以及第一指示信息;或者,UE上下文修改请求消息中第一字段包括第一DRB的ID以及第二指示信息。其中,第一字段为UE上下文修改请求消息中任一个字段,本申请对此不进行具体限定。
需要说明的是,第一DRB的ID以及第一指示信息或者第一DRB的ID以及第二指示信息可以直接包含在第一消息中,与字段同一级,或者,也可以包括于第一消息中的一个字段中。本申请对此不进行具体限定。
结合第二方面或上述任一种可能的实现方式,在另一种可能的实现方式中,第一字段可以包括第一DRB的DRB修改列表字段。
在第二方面的另一种可能的实现方式中,可以通过UP实现本申请提供的通知方法,在此实现中,第一消息包括第一DRB ID对应的接口TEID以及第一指示信息,或者,第一消息包括第一DRB ID对应的TEID以及第二指示信息。或者,第一消息包括第一DRB ID对应的接口传输层地址以及第一指示信息,或者,第一消息包括第一DRB ID对应的接口传输层地址以及第二指示信息。或者,第一消息包括第一DRB ID对应的TEID、接口传输层地址以及第一指示信息,或者,第一消息包括第一DRB ID对应的TEID、接口传输层地址以及第二指示信息。其具体实现可以参考上述控制面的具体实现,此处不再一一赘述。此时,第一消息可以包括下行PDU。
需要说明的是,第一方面与第二方面提供的通知方法,是从CU-DU架构中CU、DU角度描述的同一个方法,其具体实现可以相互参考。
第三方面,本申请提供再一种通知方法,该方法应用于CU-DU架构中的DU,该方法可以包括:DU从CU接收第三消息,第三消息包括发生RLC失败的LCID以及指示DU执行L2处理的指示信息;或者,第三消息包括发生RLC失败的LCID;DU执行L2处理;DU向CU发送第四消息,第四消息包括L2处理的小区组配置。
通过本申请提供的通知方法,DU从CU获取发生RLC失败的LCID以及指示DU执行L2处理的指示信息;或者,DU从CU获取发生RLC失败的LCID确定发生了RLC失败。这样一来,使得DU获知发生了RLC失败的LCID以及L2处理的方案;或者,使得DU获知哪些LCID发生了RLC失败,便于DU执行准确对应的L2处理,以进行适应用户设备通信链路变化的L2配置。
其中,RLC失败,即RLC failure,当RLC关联的所有服务小区不包含主小区(primary cell,PCell)/主辅小区(primary secondary cell,PSCell)只包括辅小区(secondary cell,SCell),若RLC重传达到最大次数,称之为RLC失败。
可选的,RLC失败可以发生在双连接网络中,也可以发生在单连接执行载波聚合(carrier aggregation,CA)的网络中,本申请对此不进行具体限定。
指示DU执行L2处理的指示信息用于指示CU决策的在发生RLC失败时,由DU执行L2处理的具体方案,该指示信息的类型以及内容可以根据实际需求配置,本申请对此不进行具体限定。例如,该指示信息可以为L2处理的名称信息,即可以定义每个L2处理的方案的名称,将方案名称作为指示信息;或者,该指示信息可以为L2处理的内容信息,即也可以采用L2处理的方案内容作为指示信息;或者,该指示信息可以为L2处理的标识信息,也可以配置每个L2处理的方案的标识,将该标识作为指示信息。当然,凡是可以用来指示L2处理的具体方案的信息,均可以作为指示DU执行L2处理的指示信息。
结合第三方面,在一种可能的实现方式中,指示信息可以包括下述指示中任一种:是否保留PDCP重复的指示;是否删除PDCP重复的指示;是否删除LCID的指示;是否保留LCID的指示。当然,根据L2处理的方案不同,具体的指示信息的内容可以根据实际需求配置,本申请对此不进行具体限定。
其中,PDCP重复,即PDCP duplication机制,是将PDCP PDU复制2份,然后通过两个RLC实体传输。
结合第三方面或上述任一种可能的实现方式,在另一种可能的实现方式中,若第三消息仅包括发生RLC失败的LCID,DU执行L2处理,具体可以包括:DU决策并执行L2处理。在实际应用中,决策L2处理的方案的算法可以根据实际需求选择,本申请对此不进行具体限定。
结合第三方面或上述任一种可能的实现方式,在另一种可能的实现方式中,执行L2处理包括可以下述方案中至少一项:删除发生RLC失败的LCID对应的SCells、删除发生RLC失败LCID、去激活PDCP重复、保留PDCP重复、删除PDCP重复、RLC重建立。当然,还可以根据实际需求配置执行L2处理的方案,本申请对此不进行具体限定。
结合第三方面或上述任一种可能的实现方式,在另一种可能的实现方式中,第三消息可以包括但不限于:UE上下文修改请求消息,或者,F1接口消息,或者,W1接口消息。当然,第三消息的类型可以根据实际需求选择,本申请对此不进行具体限定。
可选的,第一消息可以为CU-DU接口消息,即CU与DU之间的接口上传递的消息,当CU-DU架构的网络制式不同时,接口消息还可以定义不同的名称,本申请不进行具体限定。示例性的,F1接口消息是指NR网络中,CU与DU之间的接口上传递的消息的统称。LTE网络中,CU-DU架构的基站中CU-DU之间的接口可以定义为W1接口,W1接口上传递的消息称之为W1消息。
其中,UE上下文修改请求消息为一种F1接口消息,当然,第三消息可以为其他类型的F1消息,本申请对此不进行具体限定。
结合第三方面或上述任一种可能的实现方式,在另一种可能的实现方式中,第四消息可以包括:UE上下文修改请求消息的响应消息。
在一种可能的实现方式中,若第三消息为请求响应机制的请求消息,则第四消息可以为第三消息的响应消息;若第三消息为非请求响应机制的消息,则第四消息为一条单独的消息。本申请对于第四消息的类型不进行具体限定。
需要说明的是,发生RLC失败的LCID以及指示信息或者发生RLC失败的LCID可以直接包含在第三消息中,与字段同一级,或者,也可以包括于第三消息中的一个字段中。本申请对此不进行具体限定。
结合第三方面或上述任一种可能的实现方式,在另一种可能的实现方式中,UE上下文修改请求消息中RLC失败的LCID列表(LCID with RLC failure list)字段包括发生RLC失败的LCID以及指示DU执行L2处理的指示信息;或者,UE上下文修改请求消息中RLC失败的LCID列表字段包括发生RLC失败的LCID。当然,也可以是UE上下文修改请求消息中的其他字段包括发生RLC失败的LCID以及指示DU执行L2处理的指示信息,或者发生RLC失败的LCID,本申请实施例对此不进行具体限定。
在另一种可能的实现方式中,可以通过UP实现本申请提供的通知方法,在此实现中,第三消息包括发生RLC失败的LCID对应的TEID和/或接口传输层地址、RLC失败指示以及指示DU执行L2处理的指示信息;或者,第三消息包括发生RLC失败的LCID对应的TEID和/或接口传输层地址以及指示DU执行L2处理的指示信息;或者,第三消息包括发生RLC失败的LCID对应的TEID和/或接口传输层地址以及RLC失败指示。其具体实现可以参考上述控制面的具体实现,此处不再一一赘述。此时,第三消息可以包括下行PDU。
第四方面,本申请提供再一种通知方法,其特征在于,该方法应用于CU-DU架构中的CU,该方法可以包括:CU向DU发送第三消息,第三消息包括发生RLC失败的LCID以及指示DU执行L2处理的指示信息,或者,第三消息包括发生RLC失败的LCID;CU接收DU发送的第四消息,第四消息包括L2处理的小区组配置。
通过本申请提供的通知方法,CU将发生RLC失败的LCID以及指示DU执行L2处理的指示信息通知给DU;或者,CU将发生RLC失败的LCID通知DU以通知DU发生了RLC失败。这样一来,使得DU获知发生了RLC失败的LCID以及L2处理的方案;或者,使得DU获知LCID发生了RLC失败,便于DU执行准确对应的L2处理,以进行适应终端设备通信链路变化的L2配置。
需要说明的是,第四方面提供的通知方法与上述第三方面提供的通知方法,是从CU-DU是从CU-DU架构中CU、DU角度描述的同一个方法,其具体实现可以相互参考。
指示信息以及RLC失败已经在第三方面中进行了详细描述,此处不再进行赘述。
结合第四方面,在一种可能的实现方式中,指示信息可以包括下述指示中任一种:是否保留PDCP重复的指示;是否删除PDCP重复的指示;是否删除LCID的指示;是否保留LCID的指示。当然,根据L2处理的方案不同,具体的指示信息的内容可以根据实际需求配置,本申请对此不进行具体限定。
结合第四方面或上述任一种可能的实现方式,在另一种可能的实现方式中,执行L2处理包括可以下述方案中至少一项:删除发生RLC失败的LCID对应的SCells、删除发生RLC失败LCID、去激活PDCP重复、保留PDCP重复、删除PDCP重复、RLC重建立。当然,还可以根据实际需求配置执行L2处理的方案,本申请对此不进行具体限定。
结合第四方面或上述任一种可能的实现方式,在另一种可能的实现方式中,第三消息可以包括但不限于:UE上下文修改请求消息,或者,F1接口消息,或者,W1接口消息。当然,第三消息的类型可以根据实际需求选择,本申请对此不进行具体限定。
结合第四方面或上述任一种可能的实现方式,在另一种可能的实现方式中,第四消息可以包括:UE上下文修改请求消息的响应消息。
在一种可能的实现方式中,若第三消息为请求响应机制的请求消息,则第四消息可以为第三消息的响应消息;若第三消息为非请求响应机制的消息,则第四消息为一条单独的消息。本申请对于第四消息的类型不进行具体限定。
结合第四方面或上述任一种可能的实现方式,在另一种可能的实现方式中,UE上下文修改请求消息中RLC失败的LCID列表(LCID with RLC failure list)字段包括发生RLC失败的LCID以及指示DU执行L2处理的指示信息;或者,UE上下文修改请求消息中RLC失败的LCID列表字段包括发生RLC失败的LCID。当然,也可以是UE上下文修改请求消息中的其他字段包括发生RLC失败的LCID以及指示DU执行L2处理的指示信息,或者发生RLC失败的LCID,本申请实施例对此不进行具体限定。
结合第四方面或上述任一种可能的实现方式,在另一种可能的实现方式中,若第三消息包括发生RLC失败的LCID以及指示信息,本申请第四方面提供的通知方法还可以包括:CU决策执行L2处理的方案。在实际应用中,决策L2处理的方案的算法可以根据实际需求选择,本申请对此不进行具体限定。
结合第四方面或上述任一种可能的实现方式,在另一种可能的实现方式中,在CU接收DU发送的第四消息之后,本申请提供的通知方法还可以包括:CU向UE发送包括小区组配置的RRC重配置消息,以使得UE按照L2处理的小区组配置进行相应的L2处理,保证网络通信的一致性。
在另一种可能的实现方式中,可以通过UP实现本申请提供的通知方法,在此实现中,第三消息包括发生RLC失败的LCID对应的TEID和/或接口传输层地址、RLC失败指示以及指示DU执行L2处理的指示信息;或者,第三消息包括发生RLC失败的LCID对应的TEID和/或接口传输层地址以及指示DU执行L2处理的指示信息;或者,第三消息包括发生RLC失败的LCID对应的TEID和/或接口传输层地址以及RLC失败指示。其具体实现可以参考上述控制面的具体实现,此处不再一一赘述。此时,第三消息可以包括下行PDU。
需要说明的是,本申请提供通知方法,可以由CU/DU执行,也可以由CU/DU中的功能单元或者芯片执行,本申请对此不进行具体限定。
第五方面,本申请提供一种通知装置,该装置部署于CU-DU架构中的CU,该装置可以包括:发送单元及接收单元。其中,发送单元,用于向DU发送第一消息,第一消息包括发生承载类型切换的第一DRB的ID以及指示DU执行L2处理的第一指示信息;或者,第一消息包括第一DRB的ID以及指示发生承载类型切换的第二指示信息;接收单元,用于接收DU发送的第二消息,第二消息包括L2处理的小区组配置。
通过本申请提供的通知装置,通知装置将发生承载类型切换的第一DRB的ID以及DU执行L2处理的方案的第一指示信息通知给DU;或者,通知装置将第一DRB的ID通知给DU并通过第二指示信息通知DU发生了承载类型切换,这样一来,使得DU获知发生了承载类型切换的DRB ID以及L2处理的方案;或者,使得DU获知哪些DRB发生了承载类型切换,便于DU执行准确对应的L2处理,以进行适应终端设备通信链路变化的L2配置。
结合第五方面,在一种可能的实现方式中,执行L2处理可以包括:MAC重置以及RLC重建立;或者,更改LCID以及RLC重建立;或者,MAC同步重配置以及RLC重建立;或者,更改LCID以及RLC承载释放和增加。
结合第五方面或上述任一种可能的实现方式,在另一种可能的实现方式中,第一消息还可以包括MCG指示,执行L2处理具体可以包括:MAC重置以及RLC重建立;或者,更改LCID以及RLC重建立。
结合第五方面或上述任一种可能的实现方式,在另一种可能的实现方式中,第一消息还可以包括SCG指示,执行L2处理具体可以包括:MAC同步重配置以及RLC重建立;或者,更改LCID以及RLC承载释放和增加。
结合第五方面或上述任一种可能的实现方式,在另一种可能的实现方式中,第一消息还可以包括:第二DRB的ID,第二DRB的ID用于替换第一DRB的ID。
需要说明的是,第五方面提供的通知装置,用于执行第一方面提供的通知方法,其具体实现可以参照第一方面的实现,此处不再进行赘述。
第六方面,本申请提供另一种通知装置,该装置部署于CU-DU架构中的DU,该装置可以包括:接收单元、处理单元以及发送单元。其中,接收单元,用于从CU接收第一消息,第一消息包括发生承载类型切换的第一DRB的ID以及指示DU执行L2处理的方案的第一指示信息;或者,第一消息包括第一DRB的ID以及指示发生承载类型切换的第二指示信息;处理单元,用于执行L2处理;发送单元,用于向CU发送第二消息,第二消息包括L2处理的小区组配置。
通过本申请提供的通知装置,通知装置从CU获取发生承载类型切换的第一DRB的ID以及执行L2处理的第一指示信息;或者,通知装置从CU获取第一DRB的ID并获取到发生了承载类型切换的第二指示信息。这样一来,使得通知装置获知发生了承载类型切换的DRBID以及L2处理的方案,或者,使得通知装置获知哪些DRB发生了承载类型切换,便于部署通知装置的DU执行准确对应的L2处理,以进行适应终端设备通信链路变化的L2配置。
结合第六方面,在一种可能的实现方式中,若第一消息包括第一DRB的ID以及第二指示信息,处理单元具体可以用于:决策并执行L2处理。
结合第六方面或上述任一种可能的实现方式,在另一种可能的实现方式中,执行L2处理包括:MAC重置以及RLC重建立;或者,更改LCID以及RLC重建立;或者,MAC同步重配置以及RLC重建立;或者,更改LCID以及RLC承载释放和增加。
结合第六方面或上述任一种可能的实现方式,在另一种可能的实现方式中,第一消息还可以包括MCG指示,执行L2处理包括:MAC重置以及RLC重建立;或者,更改LCID以及RLC重建立。
结合第六方面或上述任一种可能的实现方式,在另一种可能的实现方式中,第一消息还可以包括SCG指示,执行L2处理包括:MAC同步重配置以及RLC重建立;或者,更改LCID以及RLC承载释放和增加。
结合第六方面或上述任一种可能的实现方式,在另一种可能的实现方式中,第一消息还可以包括:第二DRB的ID,第二DRB的ID用于替换发生所述第一DRB的ID;处理单元还用于对第一DRB和/或第二DRB执行L2处理。
需要说明的是,第六方面提供的通知装置,用于执行第二方面提供的通知方法,其具体实现可以参照第二方面的实现,此处不再进行赘述。
第七方面,本申请提供又一种通知装置,部署于应用于CU-DU架构中的DU,该装置可以包括:接收单元、处理单元、发送单元。其中,发送单元用于从CU接收第三消息,第三消息包括发生RLC失败的LCID以及指示DU执行L2处理的指示信息;或者,第三消息包括发生RLC失败的LCID;处理单元用于执行L2处理;发送单元用于向CU发送第四消息,第四消息包括L2处理的小区组配置。
通过本申请提供的通知装置,通知装置从CU获取发生RLC失败的LCID以及指示DU执行L2处理的指示信息,或者,通知装置从CU获取发生RLC失败的LCID确定发生了RLC失败。这样一来,使得通知装置获知发生了RLC失败的LCID以及L2处理的方案;或者,使得通知装置获知哪些LCID发生了RLC失败,便于部署通知装置的DU执行准确对应的L2处理,以进行适应终端设备通信链路变化的L2配置。
结合第七方面,在一种可能的实现方式中,若第三消息包括发生RLC失败的LCID,处理单元具体用于:决策并执行L2处理。
结合第七方面或上述任一种可能的实现方式,在另一种可能的实现方式中,指示DU执行L2处理的指示信息可以包括下述指示中任一种:是否保留PDCP重复的指示;是否删除PDCP重复的指示;是否删除所述LCID的指示;是否保留所述LCID的指示。
结合第七方面或上述任一种可能的实现方式,在另一种可能的实现方式中,执行L2处理的方案包括下述方案中至少一项:删除发生RLC失败的LCID对应的SCells、删除发生RLC失败LCID、去激活PDCP重复、保留PDCP重复、删除PDCP重复、RLC重建立。
需要说明的是,第七方面提供的通知装置,用于执行第三方面提供的通知方法,其具体实现可以参照第三方面的实现,此处不再进行赘述。
第八方面,本申请提供再一种通知装置,该装置部署于CU-DU架构中的CU,该装置可以包括:发送单元、接收单元。其中,发送单元用于向DU发送第三消息,第三消息包括发生RLC失败的LCID以及指示DU执行L2处理的指示信息,或者,第三消息包括发生RLC失败的LCID;接收单元用于接收DU发送的所述第四消息,第四消息包括L2处理的小区组配置。
通过本申请提供的通知装置,通知装置将发生RLC失败的LCID以及指示DU执行L2处理的指示信息通知给DU;或者,通知装置将发生RLC失败的LCID通知DU以通知DU发生了RLC失败。这样一来,使得DU获知发生了RLC失败的LCID以及L2处理的方案,或者,使得DU获知LCID发生了RLC失败,便于DU执行准确对应的L2处理,以进行适应终端设备通信链路变化的L2配置。
结合第八方面,在一种可能的实现方式中,指示DU执行L2处理的指示信息可以包括下述指示中任一种:是否保留PDCP重复的指示;是否删除PDCP重复的指示;是否删除所述LCID的指示;是否保留所述LCID的指示。
结合第八方面或上述任一种可能的实现方式,在另一种可能的实现方式中,执行L2处理包括下述方案中至少一种:删除发生RLC失败的LCID对应的辅小区组SCells、删除发生RLC失败LCID、去激活PDCP重复、保留PDCP重复、删除PDCP重复、RLC重建立。
需要说明的是,第八方面提供的通知装置,用于执行第四方面提供的通知方法,其具体实现可以参照第四方面的实现,此处不再进行赘述。
第九方面,本申请实施例提供了一种通知装置,该通知装置可以实现上述第一方面或第二方面的方法示例中的CU的功能,所述功能可以通过硬件实现,也可以通过硬件执行相应的软件实现。所述硬件或软件包括一个或多个上述功能相应的模块。
结合第九方面,在一种可能的实现方式中,该通知装置的结构中包括处理器和收发器,该处理器被配置为支持该通知装置执行上述方法中相应的功能。该收发器用于支持该通知装置与其他设备之间的通信。该通知装置还可以包括存储器,该存储器用于与处理器耦合,其保存该通知装置必要的程序指令和数据。
第十方面,本申请实施例提供了一种CU,包括实现上述第一方面或第二方面的方法示例中的CU的功能的通知装置。
第十一方面,本申请实施例提供了一种通知装置,该通知装置可以实现第一方面或第二方面的上述方法示例中的DU的功能,所述功能可以通过硬件实现,也可以通过硬件执行相应的软件实现。所述硬件或软件包括一个或多个上述功能相应的模块。
结合第十一方面,在一种可能的实现方式中,该通知装置的结构中包括处理器和收发器,该处理器被配置为支持该通知装置执行上述方法中相应的功能。该收发器用于支持该通知装置与其他设备之间的通信。该通知装置还可以包括存储器,该存储器用于与处理器耦合,其保存该通知装置必要的程序指令和数据。
第十二方面,本申请实施例提供了一种DU,包括实现上述第一方面或第二方面的方法示例中的DU的功能的通知装置。
第十三方面,本申请实施例提供了一种基站,包括上述第十方面描述的CU,及上述第十二方面描述的DU。
第十四方面,本申请实施例提供了一种通知装置,该通知装置可以实现上述第三方面或第四方面的方法示例中的CU的功能,所述功能可以通过硬件实现,也可以通过硬件执行相应的软件实现。所述硬件或软件包括一个或多个上述功能相应的模块。
结合第十四方面,在一种可能的实现方式中,该通知装置的结构中包括处理器和收发器,该处理器被配置为支持该通知装置执行上述方法中相应的功能。该收发器用于支持该通知装置与其他设备之间的通信。该通知装置还可以包括存储器,该存储器用于与处理器耦合,其保存该通知装置必要的程序指令和数据。
第十五方面,本申请实施例提供了一种CU,包括实现上述第三方面或第四方面的方法示例中的CU的功能的通知装置。
第十六方面,本申请实施例提供了一种通知装置,该通知装置可以实现第三方面或第四方面的上述方法示例中的DU的功能,所述功能可以通过硬件实现,也可以通过硬件执行相应的软件实现。所述硬件或软件包括一个或多个上述功能相应的模块。
结合第十六方面,在一种可能的实现方式中,该通知装置的结构中包括处理器和收发器,该处理器被配置为支持该通知装置执行上述方法中相应的功能。该收发器用于支持该通知装置与其他设备之间的通信。该通知装置还可以包括存储器,该存储器用于与处理器耦合,其保存该通知装置必要的程序指令和数据。
第十七方面,本申请实施例提供了一种DU,包括实现上述第三方面或第四方面的方法示例中的DU的功能的通知装置。
第十八方面,本申请实施例提供了一种基站,包括上述第十五方面描述的CU,及上述第十七方面描述的DU。
第十九方面,本申请实施例提供了一种计算机存储介质,用于储存为上述方法示例所用的计算机软件指令,其包含用于执行上述第一方面至第四方面所设计的程序。
第二十方面,本申请实施例提供了一种计算机程序产品,当其在计算机上运行时,使得计算机执行执行上述第一方面至第四方面所设计的程序。
上述第九方面至第二十方面提供的方案,用于实现上述第一方面至第四方面提供的通知方法,因此可以与第一方面至第四方面达到相同的有益效果,此处不再进行赘述。
附图说明
图1为现有技术提供的一种CU-DU架构示意图;
图2为现有技术提供的一种双连接无线通信系统的架构示意图;
图3为MR-DC架构支持的多种承载类型示意图;
图4为本申请实施例提供的一种CU的结构示意图;
图5为本申请实施例提供的一种DU的结构示意图;
图6为本申请实施例提供的一种通知方法的流程示意图;
图7为本申请实施例提供的另一种通知方法的流程示意图;
图8为本申请实施例提供的再一种通知方法的流程示意图;
图9为本申请实施例提供的又一种通知方法的流程示意图;
图10为本申请实施例提供的一种通知装置的结构示意图;
图11为本申请实施例提供的另一种通知装置的结构示意图;
图12为本申请实施例提供的再一种通知装置的结构示意图;
图13为本申请实施例提供的又一种通知装置的结构示意图;
图14为本申请实施例提供的又一种通知装置的结构示意图。
具体实施方式
5G RAN架构提出的CU-DU架构,并且将协议层进行了分割,RLC/MAC/PHY层由DU负责,而CU负责RRC/SDAP/PDCP。当CU确定需要进行L2处理(MAC层及RLC层配置)时,比如发生承载类型切换或者RLC失败,如何通知DU进行准确的L2处理目前还没有相关实现方案。基于此,本申请提出一种通知方法,实现在CU-DU架构中保证DU进行准确的L2处理,其基本原理是:CU决策L2处理的方案,并指示DU按照CU决策的方案执行L2处理;或者,CU将发生了承载类型切换或RLC失败这一情况通知给DU,由DU自身决策并执行L2处理,保证DU进行准确的L2处理。
为了更清楚的描述本申请提供的方案的实现过程,先将本申请方案的应用场景进行描述。
在LTE和/或NR无线系统中,支持一个UE同时连接到两个或多个基站。以连接两个基站为例,两个基站可以具有相同无线接入技术,例如都是LTE基站或都是NR基站;也可以具有不同无线接入技术,例如一个是LTE基站一个是NR基站。UE首次接入的基站被称为主站/MN。接着,主站指示UE接入辅站/SN。这种方式通常称之为双连接(dual connectivity,DC)。双连接技术利用两个基站的无线资源来为用户提供服务,更易于满足用户的容量需求和覆盖要求。
3GPP的R10版本中提出了LTE-A载波聚合技术,实现不同系统、不同频段、不同带宽间频带的组合使用,以便利用更大的带宽来提供系统性能。载波聚合技术中,多个载波主要在MAC层进行聚合,多个分量载波共享MAC资源,MAC层需要支持跨载波调度。通常情况下,一个载波对应一个小区。在双连接方式下,如果在主站上执行载波聚合,则UE在主站上首次接入的小区被称为PCell,其他小区被称为SCell。如果在辅站上执行载波聚合,则UE在辅站上首次接入的小区被称为PSCell,其他小区同样被称为辅小区。
若基站间采用的链路时延较大时,载波聚合的性能受到影响,因此提出了双连接技术。在双连接技术中,为了规避MAC层调度过程中的时延和同步要求,数据在PDCP层进行分割和合并,随后将用户数据流通过多个基站同时传送给用户。双连接中两个网络节点的角色不同,作为UE的无线侧锚点,主站为UE提供与核心网唯一的控制面连接的网络节点。辅站只为UE提供额外的无线资源,用于用户数据以及信令的传输。在双连接技术中,由MN控制的服务小区组,称之为主小区组(master cell group,MCG),由SN控制的服务小区组称之为辅小区组(secondary cell group,SCG)。
在双连接中,数据面无线承载根据占用空口资源的情况,可以分为3类:MCG承载,SCG承载和分离(Split)承载。其中空口资源具体指RLC/MAC/PHY层资源。仅占用MN/MCG侧空口资源时称为MCG承载,仅占用SN/SCG侧空口资源时称之为SCG承载,同时占用MN/MCG和SN/SCG侧空口资源时称之为Split承载。
其中,无线承载是UE与基站间传输数据的通道,是基站为UE分配的一系列实体及配置的总称,无线承载在建立RRC连接时建立。无线承载根据承载的内容不同,分为信令无线承载(signaling radio bearer,SRB)和DRB。SRB承载控制面信令数据,是系统的信令消息实际传输的通道,DRB承载用户面数据,是用户数据实际传输的通道。
逻辑信道是MAC层提供数据传送的通道,逻辑信道分配的标识称之为LCID。一般情况下,一个DRB/SRB和一个RLC实体以及一个LCID关联。当DRB/SRB执行Split操作时(可以理解为变成Split承载),一个DRB/SRB和2个RLC实体以及2个LCID关联。当DRB/SRB执行PDCP重复(PDCP duplication)机制时,一个DRB/SRB和2个RLC实体以及2个LCID关联。DRB/SRB执行Split操作和PDCP重复操作的唯一区别在于,PDCP协议数据单元(PDU,protocol dataunit)是否被复制。即当Split操作时,PDCP PDU不经过复制,不同序号的PDCP PDU分别通过2条通道传输,即2个RLC实体进行传输。当PDCP duplicaiton操作时,PDCP PDU经过复制,相同序号的PDCP PDU分别通过2条通道传输。在RRC重配置消息中,每个LCID有对应的ServedRadioBearer,用来通知UE LCID和DRB/SRB ID的映射关系。
当DRB/SRB执行PDCP duplication时,一个DRB关联2个RLC实体以及2个LCID,且标准要求不同的LCID需要调度在不同的服务小区上。在RRC重配置消息中,LogicalChannelConfig中包含LCID对应的allowedServingCells字段。由此UE可以获得LCID和服务小区的对应关系。
依托5G系统对接入网架构的需求,5G接入网逻辑架构中,已经明确将接入网分为CU和DU逻辑节点,CU和DU组成gNB基站。如图1所示,CU是集中式节点,对上通过NG接口与核心网相连接,在接入网内部则能够控制和协调多个小区,包括协议栈高层控制和数据功能。DU是分布式节点,DU实现射频处理功能和RLC、MAC以及PHY等基带处理功能。CU和DU之间通过F1接口连接。
本申请提供的应用于发生承载类型切换时的通知方法,应用于如图2所示的双连接无线通信系统架构中。如图2所示,该无线通信系统架构中包括第一网络中的基站201、第二网络中的基站202,UE203。其中,UE203使用基站201及202的无线资源,从第一网络和第二网络同时获取数据。基站201或者基站202配置为如图1所示的CU-DU架构。基站201或基站202可以作为MN也可以作为SN。
示例性的,图2示出的双连接无线通信系统架构中的第一网络可以为LTE网络、第二网络可以为5G网络,称之为EN-DC。图2示出的双连接无线通信系统架构中的第一网络和第二网络可以为两种具有不同无线接入技术的网络,例如第一网络为NR网络,第二网络为LTE网络,称之为MR-DC;也可以是两种具有相同无线接入技术的网络。图2示出的双连接无线通信系统架构中的第一网络和第二网络可以为相同无线接入技术的网络,例如都是5G网络,称之为NR-DC;例如都是LTE网络,称之为LTE双连接。对于本申请的方案所应用的网络的类型,本申请实施例对此并不进行具体限定。
本申请提供的应用于发生RLC失败时的通知方法,可以应用于如图2所示的双连接无线通信系统架构中。也可以应用于执行载波聚合的无线通信系统架构中,本申请实施例对此不进行具体限定。
前述无线接入技术,是指各种通信系统中所采用的接入方式。本申请实施例的技术方案可以包括各种无线接入技术,例如:全球移动通讯(global system of mobilecommunication,GSM)接入技术、码分多址(code division multiple access,CDMA)接入技术、宽带码分多址(wideband code division multiple access,WCDMA)接入技术、通用分组无线业务(general packet radio service,GPRS)接入技术、LTE接入技术、LTE频分双工(frequency division duplex,FDD)接入技术、LTE时分双工(time division duplex,TDD)接入技术、通用移动通信系统(universal mobile telecommunication system,UMTS)接入技术、全球互联微波接入(worldwide interoperability for microwave access,WiMAX)通信接入技术、第五代(5th generation,5G)系统或NR接入技术等,本申请对于方案的的无线接入技术的类型不进行具体限定。
本申请中描述的UE,是指用户使用的移动通信设备的部分或全部。例如,UE可以为手机、平板电脑、笔记本电脑、超级移动个人计算机(ultra-mobile personal computer,UMPC)、上网本、个人数字助理(personal digital assistant,PDA)、电子书、移动电视、穿戴设备、个人电脑(personal computer,PC)等等。在不同制式的通信系统中,终端设备可以有不同的称呼。本申请实施例对于终端设备的类型也不进行具体限定。
需要说明的是,图2仅仅是通过举例对双连接无线通信系统架构的示意。对于该无线通信系统架构中包括的设备类型及数量均可以根据实际需求配置,图2并不是对此内容的具体限定。
3GPP的RAN 2讨论中的TS37.340V15.2.0定义了MR-DC下支持的多种承载类型。图3示意了MR-DC架构支持的多种承载类型。如图3所示,MR-DC下支持的多种承载类型可以包括:
终结在MN的MCG承载(MN terminated MCG bearer);
终结在MN的SCG承载(MN terminated SCG bearer);
终结在MN的split承载(MN terminated split bearer);
终结在SN的MCG承载(SN terminated MCG bearer);
终结在SN的SCG承载(SN terminated SCG bearer);
终结在SN的split承载(SN terminated split bearer)。
其中,MCG承载是指只涉及MCG侧空口资源,空口资源主要指包含RLC/MAC/PHY层的资源。SCG承载是指只涉及SCG侧空口资源、数据面无线承载仅由SN服务的承载,Split承载是指MCG侧空口资源和SCG侧空口资源都涉及、数据面无线承载由MN和SN同时服务的承载。MN/SN终结是指PDCP实体在MN或SN。根据实际网络情况(可以是业务情况,或者链路情况,或者无线资源情况),可以在多个承载类型间切换,这一网络操作称之为承载类型切换。
示例性的,某个DRB开始只使用MCG空口资源,后续CU发现SN的信号很好,决定将MCG承载变换为Split承载。或者若CU发现SN负载较小,决定将MCG承载变换为SCG承载。当然,在实际应用中,发生承载类型切换的场景很多,此处不再一一列举。
在描述本申请提供的通知方法的具体实现之前,先对本申请实施例涉及的名字进行如下解释。
承载类型切换,即bearer type change,是在支持多种承载类型的网络中,根据业务需求切换承载的一种网络操作。
RLC失败,即RLC failure,是当RLC关联的所有服务小区不包含PCell/PSCell,只包括SCell,若RLC重传达到最大次数,称之为RLC失败。RLC失败的主要原因可能是RLC实体或LCID关联的SCell信号不好,或者配置不合理等。当UE发现发生了RLC failure,需要通知基站,例如通过RRC消息通知基站哪些LCID发生了RLC失败。特别地,当处于双连接状态时,UE还需要额外指示是MCG还是SCG的那些LCID发生了RLC失败。例如UE上报的RRC消息中包含发生RLC失败的LCID列表,里面包含LCID。可选地,每个LCID还携带MCG/SCG指示。在CU-DU架构中,由于CU负责RRC模块,也就是说RLC失败的情况只有CU知道。
本申请实施例的说明书和权利要求书中的术语“第一”和“第二”等是用于区别不同的对象,而不是用于描述对象的特定顺序。例如,第一指示信息和第二指示信息等是用于区别不同的指示信息,而不是用于描述信息的特定顺序。
在本申请实施例中,“示例性的”或者“例如”等词用于表示作例子、例证或说明。本申请实施例中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言,使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念,便于理解。
下面结合附图,对本申请的实施例进行具体阐述。
一方面,本申请实施例提供一种CU。图4示出的是与本申请各实施例相关的一种CU40。CU 40可以为图1所示的双连接无线通信系统架构中的采用CU-DU架构的基站中的CU。如图4所示,CU 40可以包括:处理器401、存储器402、收发器403。
下面结合图4对CU 40的各个构成部件进行具体的介绍:
存储器402,可以是易失性存储器(volatile memory),例如随机存取存储器(random-access memory,RAM);或者非易失性存储器(non-volatile memory),例如只读存储器(read-only memory,ROM),快闪存储器(flash memory),硬盘(hard disk drive,HDD)或固态硬盘(solid-state drive,SSD);或者上述种类的存储器的组合,用于存储可实现本申请方法的程序代码、以及配置文件。
处理器401是CU 40的控制中心,可以是一个中央处理器(central processingunit,CPU),也可以是特定集成电路(application specific integrated circuit,ASIC),或者是被配置成实施本申请实施例的一个或多个集成电路,例如:一个或多个微处理器(digital singnal processor,DSP),或,一个或者多个现场可编程门阵列(fieldprogrammable gate array,FPGA)。处理器401可以通过运行或执行存储在存储器402内的软件程序和/或模块,以及调用存储在存储器402内的数据,执行CU 40的各种功能。
收发器403用于CU 40与其他单元进行交互。示例性的,收发器403可以为CU 40的收发天线或通信端口。
一种可能的实现中,处理器401通过运行或执行存储在存储器402内的软件程序和/或模块,以及调用存储在存储器402内的数据,执行如下功能:
通过收发器403向DU发送第一消息,第一消息包括发生承载类型切换的第一DRB的ID以及指示DU执行L2处理的第一指示信息;或者,第一消息包括第一DRB的ID以及指示发生承载类型切换的第二指示信息;通过收发器403接收DU发送的第二消息,第二消息包括L2处理的小区组配置。
一种可能的实现中,处理器401通过运行或执行存储在存储器402内的软件程序和/或模块,以及调用存储在存储器402内的数据,执行如下功能:
通过收发器403向DU发送第三消息,第三消息包括发生RLC失败的LCID以及指示DU执行L2处理的指示信息;或者,第三消息包括发生RLC失败的LCID;通过收发器接收DU发送的第四消息,第四消息包括L2处理的小区组配置。
另一方面,本申请实施例提供一种DU。图5示出的是与本申请各实施例相关的一种DU50。DU 50可以为图1所示的双连接无线通信系统架构中配置CU-DU架构的基站中的DU。如图5所示,DU 50可以包括:处理器501、存储器502、收发器503。
下面结合图5对DU 50的各个构成部件进行具体的介绍:
存储器502,可以是易失性存储器,例如RAM;或者non-volatile memory,例如ROM,flash memory,HDD或SSD;或者上述种类的存储器的组合,用于存储可实现本申请方法的程序代码、以及配置文件。
处理器501是DU 50的控制中心,可以是一个CPU,也可以是ASIC,或者是被配置成实施本申请实施例的一个或多个集成电路,例如:一个或多个DSP,或,一个或者多个FPGA。处理器501可以通过运行或执行存储在存储器502内的软件程序和/或模块,以及调用存储在存储器502内的数据,执行DU 50的各种功能。
收发器503用于DU 50与其他单元进行交互。示例性的,收发器503可以为DU 50的收发天线或通信端口。
一种可能的实现中,处理器501通过运行或执行存储在存储器502内的软件程序和/或模块,以及调用存储在存储器502内的数据,执行如下功能:
通过收发器503从CU接收第一消息,第一消息包括发生承载类型切换的第一DRB的ID以及指示DU执行L2处理的方案的第一指示信息;或者,第一消息包括第一DRB的ID以及指示发生承载类型切换的第二指示信息;执行L2处理;通过收发器503向CU发送第二消息,第二消息包括L2处理的小区组配置。
另一种可能的实现中,处理器501通过运行或执行存储在存储器502内的软件程序和/或模块,以及调用存储在存储器502内的数据,执行如下功能:
通过收发器503从CU接收第三消息,第三消息包括发生RLC失败的LCID以及指示DU执行L2处理的指示信息;或者,第三消息包括发生RLC失败的LCID;执行L2处理;通过收发器503向CU发送第四消息,第四消息包括L2处理的小区组配置。
再一方面,本申请实施例提供一种通知方法,应用于CU-DU架构中发生承载类型切换时CU与DU的通信过程中。本申请描述的CU/DU执行的某操作,可以理解为由CU/DU执行,也可以理解为CU/DU内的功能单元或者芯片执行,本申请实施例对此不进行具体限定,下文中仅描述为CU/DU执行某操作。CU/DU内执行本申请提供的通知方法的功能单元或者芯片可以称之为本申请所称的通知装置。
如图6所示,本申请实施例提供的通知方法可以包括:
S601、CU向DU发送第一消息,第一消息包括发生承载类型切换的第一DRB的ID以及指示DU执行L2处理的第一指示信息,或者,第一消息包括第一DRB的ID以及指示发生承载类型切换的第二指示信息。
需要说明的是,发生承载类型切换的第一DRB可以为至少一个,本申请实施例对于发生承载类型切换的DRB的数量不进行具体限定。对于每个发生承载类型切换的DRB执行本申请方案的过程相同。
其中,S601是CU确定发生承载类型切换时执行。
可选的,当CU-DU架构应用于双连接网络中的SN时,CU接收到MN发送的指示,该指示中可以包括最新网络配置内容,根据指示确定发生了承载类型切换。例如,CU通过对比前后收到的EN-DC resource configuration字段的变化,获知发生了bearer type change,以及具体哪些DRB发生了bearer type change。其中,发生bearer type change的DRB可以为至少一个DRB。例如CU第一次收到EN-DC resource configuration中指示所述DRB的PDCP实体在MN上,只占用MCG侧空口资源。CU第二次收到EN-DC resource configuration中指示所述DRB的PDCP实体在MN上,同时占用MCG侧空口资源和SCG侧空口资源。由此CU获知所述DRB从MCG承载切换到了split承载,但是安全密钥没有发生变化。
可选的,当CU-DU架构应用于双连接网络中的MN时,CU根据终端设备通信链路变化自行决定哪些DRB进行承载类型切换。其中,进行bearer type change的DRB可以为至少一个DRB。例如,某个DRB开始只使用MCG空口资源,后续CU发现SN的信号很好,决定将MCG承载变换为Split承载。或者若CU发现SN负载较小,决定将MCG承载变换为SCG承载。此处只是示例性说明,并不是对CU根据终端设备通信链路变化自行决定进行承载类型切换的方案的具体限定。
需要说明的是,本申请实施例提供的通知方法应用于CU确定发生了承载类型切换后,对于CU如何确定发生了承载类型切换的过程不进行限定,也不在此进行赘述。
具体的,在S601中第一消息的内容包括下述两种情况:
第一情况、第一消息包括发生承载类型切换的第一DRB的ID以及指示DU执行L2处理的第一指示信息。
在第一情况中,由CU决策确定发生承载类型切换时DU执行L2处理的具体操作,并通过第一指示信息向DU指示其执行L2处理的具体操作。
在第一情况中,如图7所示,在S601之前,本申请实施例提供的通知方法还可以包括S601a。
S601a、CU确定DU执行L2处理的方案。
可选的,CU可以从L2处理的方案集合中决策确定发生承载类型切换时DU执行L2处理的具体操作。其中,L2处理的方案集合可以为预先定义的至少两种L2处理方案。需要说明的是,L2处理方案集合的具体内容,可以根据实际需求配置,本申请实施例对此不进行具体限定。
需要说明的是,在执行本申请提供的通知方法时,如果有S601a时,S601中则执行的是第一情况,不涉及第二情况。
可选的,一种可能的实现中,执行L2处理可以包括:MAC重置(MAC reset)以及RLC重建立(RLC re-establishment);或者,更改LCID(change of LCID)以及RLC重建立;或者,MAC同步重配置(MAC reset by reconfiguration with sync)以及RLC重建立;或者,更改LCID以及RLC承载释放和增加(RLC bearer release and add)。当然,执行L2处理可以包括其他L2处理的具体操作,此处只是示例描述,并不是对此内容的具体限定。
需要说明的是,本文中描述的“执行L2处理包括”可以理解为:执行L2处理的具体操作包括,后面不再一一说明。
可选的,一种可能的实现中,第一消息还可以包括MCG指示,该MCG指示用于指示CU-DU架构的基站为双连接中的MN角色;或者,DU通过其他方式获知当前处于MN角色时(即第一消息不包含显示的MCG指示),执行L2处理可以包括:MAC重置以及RLC重建立;或者,更改LCID以及RLC重建立。
其中,MCG指示可以为MCG字符串本身,或者预先配置的其他字符或比特,例如,MCG/SCG指示包含枚举值为MCG,或者MCG/SCG指示=1则表示MCG,本申请对此不进行具体限定。其中,MCG/SCG指示=1,是指“MCG/SCG指示”这个比特位取值为1。
可选的,一种可能的实现中,第一消息还可以包括SCG指示,SCG指示用于指示CU-DU架构的基站为双连接架构中的SN角色;或者,DU通过其他方式获知当前处于SN角色时(即第一消息不包含显示的SCG指示),执行L2处理可以包括:MAC同步重配置以及RLC重建立;或者,更改LCID以及RLC承载释放和增加。
其中,SCG指示可以为SCG字符串本身,或者预先配置的其他字符或比特,例如,MCG/SCG指示包含枚举值为SCG,或者MCG/SCG指示=0则表示SCG,本申请对此不进行具体限定。其中,MCG/SCG指示=0,是指“MCG/SCG指示”这个比特位取值为0。
一种可能的实现中,L2处理的方案集合可以为3GPP中TS 37.340v15.2.0或R2-1810953中定义的表格A-1,名称为承载类型切换伴随或不伴随安全密钥改变的L2处理(L2handling for bearer type change with and without security key change),其涉及DU进行L2处理的内容如表1所示。
表1
Figure BDA0001762105000000181
Figure BDA0001762105000000191
其中,with key change是指安全密钥更新。例如,当承载的PDCP实体所在节点发生变化或者说承载的PDCP实体发生变化,例如从MN切换到SN或者反之,则需要进行安全密钥的更新。以MCG承载到MCG承载的切换,且伴随安全密钥更新为例,一种可能是,MCG承载的PDCP开始在MN,且占用MCG侧空口资源。后来该MCG承载的PDCP切换到SN,但还是占用MCG侧空口资源。另一种可能是,MCG承载的PDCP开始在SN,且占用MCG侧空口资源。后来该MCG承载的PDCP切换到MN,但还是占用MCG侧空口资源。
表1中提供了从横行中的承载类型切换到竖列中的承载类型且伴随安全密钥更新时,对应的L2处理方案。例如,从Split承载切换到SCG承载,查询表1中的第三行第四列,得到该承载类型切换的L2处理方案为PDCP层执行Re-establish,MCG的RLC层执行Establish,MCG的MAC层执行reconfigure,SCG的RLC层参照注2执行L2处理,SCG的MAC层参照注2执行L2处理。
第一指示信息用于指示CU决策的由DU执行L2处理的具体方案,该指示信息的类型以及内容可以根据实际需求配置,本申请对此不进行具体限定。例如,第一指示信息可以为L2处理的名称信息,即可以定义每个L2处理的方案的名称,将方案名称作为第一指示信息;或者,第一指示信息可以为L2处理的内容信息,即也可以采用L2处理的方案内容作为第一指示信息;或者,第一指示信息可以为L2处理的标识信息,也可以配置每个L2处理的方案的标识,将该标识作为第一指示信息。当然,凡是可以用来指示L2处理的具体方案的信息,均可以作为第一指示信息。
示例性的,以表1示意的内容为例,假设DU属于SCG,其L2处理可以包括“MAC resetby reconfiguration with sync+RLC re-establishment”,或者“change of LCID+RLCbearer release and add”,对于第一指示信息可以有如下几种实现:
第一实现:采用方案内容作为第一指示信息。
将MAC reset by reconfiguration with sync+RLC re-establishment或changeof LCID+RLC bearer release and add作为第一指示信息,即将方案具体内容作为指示信息。
需要说明的是,在采用方案内容作为第一指示信息时,可以是方案的完整内容,也可以是方案的部分内容,或者是方案的简写内容,凡是可以明确指示方案的内容信息,均可以作为第一指示信息。
第二实现:采用方案名称作为第一指示信息。
对“MAC reset by reconfiguration with sync+RLC re-establishment”定义名称为方案A,对“change of LCID+RLC bearer release and add”定义名称为方案B,将“方案A”或“方案B”作为第一指示信息。
第三实现:采用方案标识作为第一指示信息。
用1比特信息表示第一指示信息,用0标识“MAC reset by reconfiguration withsync+RLC re-establishment”,用于1标识“change of LCID+RLC bearer release andadd”,用0/1作为第一指示信息。
第四实现、对于可以采用隐式指示的方案,采用隐式表示内容作为第一指示信息。
例如,对于“change of LCID+RLC bearer release and add”,CU通过UE contextmodification request消息中的DRB to be released list字段和DRB to be added list字段来实现DRB的释放和增加,等同于通知DU进行RLC的释放和增加,达到了通知的目的。
第二情况、第一消息包括第一DRB的ID以及指示发生承载类型切换的第二指示信息。
其中,第二指示信息用于向DU通知发生了承载类型切换,该第二指示信息的形式以及内容可以根据实际需求配置,本申请对此不进行具体限定。例如,第二指示信息可以为承载类型切换这个网络操作的名称信息,即将“bearer type change”或者“key change”或者“bearer type change with key change”作为第二指示信息,或者,第二指示信息可以为承载类型切换这个网络操作的表示信息,即网络中定义一个承载类型切换这种网络操作的网络标识,用于唯一指示发生了承载类型切换,将该网络标识作为第一指示信息等等。凡是可以用来指示发生了承载类型切换这一网络操作的信息,均可以作为第二指示信息。
在第二情况中,由CU向DU指示发生承载类型切换的至少一个DRB,DU执行L2处理的具体操作,由DU接收到第一消息时自行决策并执行。具体地,DU可以从L2处理的方案集合中决策确定发生承载类型切换时执行L2处理的具体操作,并执行相应的L2处理。
需要说明的是,第二情况中DU接收到第一消息后决策执行L2处理的具体操作,以及第二情况中L2处理的内容与第一情况中描述的相同,只是决策的执行主体不同,详细内容已经在上述第一情况中进行了详细说明,此处不再进行赘述。
进一步可选的,承载类型切换时,发生承载类型切换的DRB的ID可以更换,也可能不更换,本申请实施例对此不进行具体限定。当承载类型切换时,发生承载类型切换的DRB的ID更换时,第一消息还可以包括:第二DRB的ID,第二DRB的ID用于替换第一DRB的ID,以指示DU第一DRB和/或第二DRB执行对应的L2处理。
第一消息是CU-DU接口消息。目前,NR网络中CU-DU接口消息定义为F1消息。当然,CU-DU接口消息也可以有其他名称,当CU-DU架构的网络制式不同时,接口消息还可以定义不同的名称,本申请不进行具体限定。例如,LTE网络中,CU-DU架构的基站中CU-DU之间的接口可以定义为W1接口,W1接口上传递的消息称之为W1消息。示例性的,第一消息可以是W1消息。
可选的,第一消息可以为当前现有的CU-DU接口消息,或者,第一消息也可以为新定义的专用于承载类型切换时通知DU执行L2处理的消息,本申请实施例对此也不进行具体限定。示例性的,第一消息可以是UE上下文修改请求(UE context modification request)消息,或者定义一条新的第一消息,示例性的,新定义的第一消息可以为承载类型切换通知(bearer type change notification)消息。可选的,第一消息中包括的第一DRB的ID以及第一指示信息,或者,第一DRB的ID以及第二指示信息,可以直接包含于第一消息,作为第一消息中的字段。
可选的,第一消息中包括的第一DRB的ID以及第一指示信息,或者,第一DRB的ID以及第二指示信息,可以包含于第一消息中的第一字段中。其中,第一字段为第一消息中的任一字段。
可选的,当第一消息为现有消息时,第一字段可以为现有消息中的现有字段,也可以为新定义的字段,本申请实施例对此不进行具体限定。
示例性的,当第一消息为UE上下文修改请求消息时,UE上下文修改请求消息中第一字段包括第一DRB的ID以及第一指示信息;或者,UE上下文修改请求消息中第一字段包括第一DRB的ID以及第二指示信息。该第一字段可以为UE上下文修改请求消息中的现有字段,也可以为新定义字段,本申请实施例对此不进行具体限定。
示例性的,当第一消息为UE上下文修改请求消息时,第一字段可以包括第一DRB的DRB修改列表(DRB to be modified List)字段。
示例性的,当第一消息为UE上下文修改请求消息,第一字段为第一DRB的DRB toBe Modified List字段,该字段内容可以为:
DRB to be modified list
>DRB to be modified item IEs
>>第一DRB ID
>>第一指示信息(例如MAC reset/MAC reset reconfiguration with sync/RLCreestablish/change of LCID/RLC release and add)或第二指示信息(例如bearer typechange/key change/bearer type change with key change)。
进一步可选的,如果第一DRB关联了不止1个RLC实体(或者LCID),则第一消息还可以包括第一DRB中发生承载类型切换的LCID,以便DU针对LCID对应的RLC实体或逻辑信道执行L2处理。
S602、DU从CU接收第一消息。
其中,第一消息包括发生承载类型切换的第一DRB的ID以及指示DU执行L2处理的方案的第一指示信息;或第一消息包括第一DRB的ID以及指示发生承载类型切换的第二指示信息。
需要说明的是,S602中DU从CU接收的第一消息,即S601中CU发送的第一消息,对于第一消息已经在S601中进行了详细说明,此处不再进行赘述。
S603、DU执行L2处理。
具体的,对应于S601中第一消息的两种情况,S603中的处理方式不同。
可选的,对应于S601中的第一情况,S603中DU根据第一指示信息的指示执行L2处理。对应于S601中的第二情况,S603中DU决策并执行L2处理。
其中,DU决策是指DU根据网络状态确定执行L2处理的具体操作。其具体操作的可选方案,已经在S601中第一情况中进行了详细说明,此处不再进行赘述。
示例性的,基于表1内容,当CU-DU架构应用于SN时,DU收到第一消息,就知道发生了以下4种情况中的一种:1)Split->Split with key change;2)Split->SCG with keychange;3)SCG->Split with key change;4)SCG->SCG with key change。接着DU根据第一指示信息的指示执行以下L2处理中的一种,或者根据第二指示信息决策执行以下L2处理中的一种:1)MAC reset reconfiguration with sync+RLC re-establishment;2)change ofLCID+RLC bearer release and add。
其中,“Split->Split with key change”表示从Split承载切换到Split承载伴随安全密钥更新。例如从PDCP锚点在MN改变成PDCP锚点在SN,或者反之。PDCP锚点发生变化,导致安全密钥更新。
示例性的,基于表1内容,当CU-DU架构应用于MN时,DU收到第一消息,就知道发生了以下种情况中的一种:1)MCG->MCG with key change;2)MCG->Split with key change;3)Split->MCG with key change;4)Split->Split with key change。接着DU根据第一指示信息的指示执行以下L2处理中的一种,或者根据第二指示信息决策执行以下L2处理中的一种:1)MAC reset+RLC re-establishment;2)change of LCID+RLC re-establishment。
需要说明的是,对于DU执行L2处理的过程,即进行RLC层及MAC层配置,本申请对该过程不进行赘述,可以参考现有机制进行。
示例性的,DU进行RLC重建立具体动作参见3GPP中的TS 36.322v15.1.0或TS38.322v15.2.0,根据模式不同动作不同。例如RLC重建立时,对于透明模式(transparentmode,TM)的RLC实体,将删除所有RLC服务数据单元(service data unit,SDU)。针对RLCrelease+add的情况,还需要配置新的LCID。
可选的,当第一消息还包括第二DRB的ID时,DU还需对第一DRB和/或第二DRB执行的L2处理。
其中,DU对第一DRB和/或第二DRB执行L2处理,是指DU执行的L2处理中的一系列操作,操作对象可以是第一DRB、第二DRB中的一个或两个。例如,若DU执行的L2处理为RLC承载的释放和增加,则对第一DRB进行释放操作,对第二DRB进行增加操作。DU对第一DRB和/或第二DRB执行L2处理,就是DU执行L2处理时将第一DRB相关的所有配置关联到第二DRB。当执行change of LCID时,则DU将改变后的LCID和第二DRB标识关联。此外,DU还将第一DRB标识关联的F1接口用户面隧道和第二DRB标识关联。
S604、DU向CU发送第二消息,第二消息包括L2处理的小区组配置。
具体的,DU执行L2处理,需要进行RLC层及MAC层配置,其配置的具体内容生成包括L2处理的小区组配置(CellGroupConfig)。其中小区组配置信息需要通过CU发送给UE,以使得UE进行相同的配置。例如DU通过UE上下文修改响应消息或者发起UE上下文修改需求消息(UE context modification required)将所述CellGroupConfig发送给CU。
需要说明的是,DU可以先生成包括L2处理的小区组配置再执行L2处理或者,先执行L2处理再生成包括L2处理的小区组配置,或者同时进行,本申请实施例对此不进行具体限定。
示例性的,CellGroupConfig可以包含RLC-config(RLC配置),RLC-bearer config(RLC承载配置),MAC-cellgroupconfig(MAC层小区组配置),LCID等。其中RLC-config包含re-establishRlc字段,而RLC-bearerConfig中包含LCID替换指示信息。
其中,LCID替换指示信息,可以通过隐式的方法实现。例如,原来LCID=1,对应的DRB ID=1。现在LCID=5(用于替换LCID=1),对应的DRB ID=1。UE通过对比前后LCID变化,就可以获知LCID改变。LCID替换指示信息也可以通过增加新IE的方法实现,例如在RLC-bearerconfig里面包含新LCID字段实现。本申请实施例对此不进行具体限定。
示例性的,若DU执行L2处理为MAC reset by reconfiguration with sync+RLCre-establishment,CellGroupConfig还可以包含reconfiguration with sync(同步重配置),例如Reconfiguration with sync字段。当执行change of LCID,则DU将产生新LCID,并和第一DRB ID绑定。LCID和DRB的绑定关系,是通过RLC-bearer config里面的servedradio bearer字段所体现的。当执行change of LCID,且CU指示第二DRB的ID,则DU将产生LCID,并将新LCID和第二DRB的ID关联。当执行RLC re-establish时,DU产生的小区组配置信息中可能包含re-establishRlc字段。当执行RLC释放和增加,DU产生的小区组配置信息中可能包含RLC-bearer to release list和RLC-bearer to add mod list。因此,DU通过向CU发送第二消息,以通过CU将小区组配置发送给UE。
可选的,若第一消息为请求响应机制中的请求消息,则第二消息可以为第一消息的响应消息;若第一消息为非请求响应机制的消息,则第二消息为一条单独的消息。本申请对于第二消息的类型不进行具体限定。
示例性的,第二消息可以是UE上下文修改请求消息的响应消息。
S605、CU接收DU发送的第二消息。
其中,第二消息包括L2处理的小区组配置。
需要说明的是,S605中CU从DU接收的第二消息,即S604中DU发送的第二消息,对于第二消息已经在S604中进行了详细说明,此处不再进行赘述。
进一步的,如图7所示,在S605之后,本申请实施例提供的通知方法还可以包括S606。
S606、CU向UE发送RRC重配置消息,RRC重配置消息包括小区组配置。
具体的,CU在S605中接收到第二消息后,将自身负责的L2处理(例如PDCP层配置)的相关配置以及第二消息中的小区组配置,添加至RRC重配置消息中发送给UE,以使得UE进行相同的配置,其具体过程不在进行赘述。
通过本申请提供的通知方法,CU将发生承载类型切换的第一DRB的ID以及DU执行L2处理的方案的第一指示信息通知给DU;或者,CU将第一DRB的ID通知给DU并通过第二指示信息通知DU发生了承载类型切换。这样一来,使得DU获知发生了承载类型切换的DRB以及L2处理的方案,或者,使得DU获知哪些DRB发生了承载类型切换,便于DU执行准确对应的L2处理,以进行适应终端设备通信链路变化的L2配置。
需要说明的是,上述实现是从控制面实现CU向DU通知,即通过F1接口的控制面消息实现CU向DU通知。在另一种可能的实现方式中,可以通过用户面实现本申请提供的通知方法,即通过F1接口的用户面隧道发送的数据包携带信息实现所述通知。
具体的,CU和DU之间的用户面隧道是DRB或LCID粒度的。例如当CU和DU执行基于载波聚合的PDCP重复时,CU和DU之间将针对一个DRB建立2个接口用户面隧道。例如,CU在UEcontext setup/modification request(UE上下文建立/修改请求)消息中包含DRB ID以及对应的CU侧传输层信息,传输层信息可以包含TEID(为隧道分配的识别标识)和/或传输层地址,DU在响应消息中包含DRB ID以及对应的DU侧传输层信息。CU侧TEID和DU侧TEID可以唯一识别一个用户面隧道,即唯一识别一个DRB/LCID。在此实现中,第一消息包括第一DRBID对应的接口TEID以及第一指示信息,或者,第一消息包括第一DRB ID对应的TEID以及第二指示信息。其具体实现可以参考上述控制面的具体实现,此处不再一一赘述。此时,第一消息可以包括下行PDU。例如在下行PDU的控制字段包括第一DRB ID对应的接口TEID以及第一指示信息或者第一DRB ID对应的TEID以及第二指示信息。可选地,CU侧传输层地址和DU侧传输层地址可以唯一识别一个用户面隧道,即唯一识别一个DRB/LCID。则第一消息中可以包括和DRB ID对应的接口传输层地址。
其中,PDCP重复(PDCP duplication)机制,即将PDCP PDU复制2份,然后通过2个RLC实体传输。PDCP重复可以应用于SRB,也可以应用于DRB。
当CU在给DU发送下行数据包时,在数据包头将携带TEID。当数据包头携带第一指示信息时,根据隧道端点地址TEID和DRB/LCID的绑定关系,确定哪个DRB/LCID需要执行什么样的L2处理。当数据包头携带第二指示信息时,根据隧道端点地址和DRB/LCID的绑定关系,确定是哪个DRB/LCID发生承载类型切换。
再一方面,本申请实施例提供一种通知方法,应用于CU-DU架构中发生RLC失败时CU与DU的通信过程中。本申请描述的CU/DU执行的某操作,可以理解为由CU/DU执行,也可以理解为CU/DU内的功能单元或者芯片执行,本申请实施例对此不进行具体限定,下文中仅描述为CU/DU执行某操作。CU/DU内执行本申请提供的通知方法的功能单元或者芯片可以称之为本申请所称的通知装置。
如图8所示,本申请实施例提供的通知方法可以包括:
S801、CU向DU发送第三消息,第三消息包括发生RLC失败的LCID以及指示DU执行L2处理的指示信息;或者,第三消息包括发生RLC失败的LCID。
需要说明的是,发生RLC失败的LCID可以为至少一个,本申请实施例对于发生RLC失败的LCID的数量不进行具体限定。对于每个发生RLC失败的LCID执行本申请方案的过程相同。
其中,S801是CU确定发生RLC切换时执行。CU可以根据UE上报的信息确定发生RLC失败。例如CU根据UE上报的RRC消息中包含的LCID确定哪些LCID发生了RLC失败。基站或CU还可以根据UE上报的MCG/SCG指示,确定是MCG还是SCG发生了RLC失败。当CU-DU架构的基站作为MN时,CU还可以通过基站间接口例如Xn/X2接口告知辅站SN哪些LCID发生了RLC失败。例如在Xn/X2接口消息中包含发生RLC失败的LCID列表,里面包含发生RLC失败的LCID。
需要说明的是,本申请实施例提供的通知方法应用于CU确定发生了RLC失败后,对于CU如何确定发生了RLC失败的过程不进行限定,也不在此进行赘述。
具体的,在S801中第三消息的内容包括下述两种情况:
情况1、第三消息包括发生RLC失败的LCID以及指示DU执行L2处理的指示信息。
在情况1中,由CU决策确定发生RLC失败时,DU执行L2处理的具体操作,并通过指示信息向DU指示其执行L2处理的具体操作。
在情况1中,如图9所示,在S801之前,本申请实施例提供的通知方法还可以包括S801a。
S801a、CU确定DU执行L2处理的方案。
可选的,CU可以从L2处理的方案集合中决策确定发生RLC失败时,DU执行L2处理的具体操作。其中,L2处理的方案集合可以为预先定义的至少两种L2处理方案。需要说明的是,L2处理方案集合的具体内容,可以根据实际需求配置,本申请实施例对此不进行具体限定。
需要说明的是,在执行本申请提供的通知方法时,如果有S801a时,S801中则执行的是情况1,不涉及情况2。
可选的,一种可能的实现中,在发生RLC失败时,执行L2处理可以包括下述方案中至少一种:删除发生RLC失败的LCID对应的SCells、删除发生RLC失败LCID、去激活PDCP重复、保留PDCP重复、删除PDCP重复、RLC重建立。当然,在发生RLC失败时执行L2处理可以包括其他L2处理的具体操作,此处只是示例描述,并不是对此内容的具体限定。其中,去激活PDCP重复是指模式的资源对应关系保留但不使能,即不执行PDCP PDU复制操作;保留PDCP重复是指保持该模式的资源对应关系,即继续执行PDCP PDU复制操作;删除PDCP重复是指将该模式的资源对应关系删除,例如删除DRB/SRB关联的一个RLC实体和一个LCID,只保留一个RLC实体和一个LCID。
当DRB/SRB执行PDCP重复时,一个DRB关联2个RLC实体以及2个LCID,且标准要求不同的LCID需要调度在不同的服务小区上。在RRC重配置消息中,logical channel config字段包含LCID对应的allowedservingcells字段。由此UE可以获得LCID和服务小区的对应关系。当LCID关联的服务小区全部都是SCell,且当RLC重传次数超过最大次数时,即所述LCID发生了RLC失败。对于DRB而言,去激活PDCP重复可以通过MAC控制字段通知UE是否激活或去激活PDCP duplication。此时,一个DRB还是对应2个RLC实体以及2个LCID。保留PDCP重复即保留一个DRB对应的2个RLC实体以及2个LCID。删除PDCP重复即一个DRB从对应2个RLC实体以及2个LCID,变成只对应一个RLC实体和一个LCID。对于SRB而言,去激活PDCPduplication可以通过CU告知DU不需要对PDCP PDU进行复制了。例如CU可以通过将F1接口消息下行RRC消息传输(DL RRC message transfer)中包含的执行重复(executeduplication)字段设置为false,以通知DU不需要对PDCP PDU进行复制了。
示例性的,当L2处理为删除PDCP重复时,还需删除发生RLC失败的LCID。可选的,对于DRB执行PDCP重复的情况,CU可以决定是否删除LCID对应的DRB关联的其中一个F1-U隧道。例如CU首先可以通过DU之前反馈的CellGroupConfig获知DRB ID和LCID的映射关系。接着CU根据UE上报的发生RLC失败的LCID,以及DRB ID和LCID的映射关系,找到对应的DRBID。CU可以通过UE上下文修改请求,请求消息中所述DRB只包含1个传输层信息,即一个TEID和/或一个传输层地址。DU收到该消息,可以获知CU决定删除DRB关联的一个F1-U隧道,即删除PDCP重复。相应地,DU产生新的CellGroupConfig,所述DRB只关联一个LCID,即删除了该DRB关联的发生RLC失败的LCID。对于SRB执行PDCP重复的情况,CU可以通知DU删除SRB对应的其中一个RLC实体和LCID。例如CU通过将UE context modification request消息中的SRB to be modified list字段中的duplication indication设置为false,指示DU删除对应的SRB对应的一个RLC实体。相应地,DU还将删除该RLC实体对应的LCID,并产生新的CellGroupConfig。所述SRB只关联一个LCID,即删除了该SRB关联的发生RLC失败的LCID。
其中,指示DU执行L2处理的指示信息用于指示CU决策的由DU执行L2处理的具体操作,该指示信息的类型以及内容可以根据实际需求配置,本申请对此不进行具体限定。例如,第一指示信息可以为L2处理的名称信息,即可以定义每个L2处理的方案的名称,将方案名称作为指示信息;或者,指示信息可以为L2处理的内容信息,即也可以采用L2处理的方案内容作为指示信息;或者,指示信息可以为L2处理的标识信息,也可以配置每个L2处理的方案的标识,将该标识作为指示信息。当然,凡是可以用来指示L2处理的具体方案的信息,均可以作为指示信息,本申请实施例对此不进行具体限定。
可选的,指示DU执行L2处理的指示信息可以包括下述指示中任一种:是否保留PDCP重复的指示;是否删除PDCP重复的指示;是否删除发生RLC失败的LCID的指示;是否保留发生RLC失败的LCID的指示;保留PDCP重复的指示;删除PDCP重复的指示;删除发生RLC失败的LCID的指示;保留发生RLC失败的LCID的指示。需要说明的是,此处的指示信息的内容只是通过列举的方式举例说明,并不是对指示信息的内容的限定。
其中,是否保留PDCP重复的指示用于指示保留PDCP重复或者删除PDCP重复的方案,当“是否保留PDCP重复的指示”取值为是,则指示保留PDCP重复,当“是否保留PDCP重复的指示”取值为否,则指示删除PDCP重复。
是否删除PDCP重复的指示用于指示保留PDCP重复或者删除PDCP重复的方案,当“是否删除PDCP重复的指示”取值为是,则指示删除PDCP重复,当“是否删除PDCP重复的指示”取值为否,则指示保留PDCP重复。
例如,在CU给DU的第三消息中增加PDCP duplicaiton字段,该字段为枚举类型,包含2个值,分别为kept和not kept,分别表示保留PDCP重复和不保留PDCP重复。或者该字段为整型,包含2个值0和1,分别表示保留PDCP重复和不保留PDCP重复。需要说明的是,PDCPduplicaiton字段在第三消息中的位置不进行限定。
是否删除发生RLC失败的LCID的指示用于指示删除LCID或不删除LCID的方案,当“是否删除发生RLC失败的LCID的指示”取值为是,则指示删除LCID,当“是否删除发生RLC失败的LCID的指示”取值为否,则指示不删除LCID。
是否保留发生RLC失败的LCID的指示用于指示删除LCID或不删除LCID的方案,当“是否保留发生RLC失败的LCID的指示”取值为是,则指示不删除LCID,当“是否保留发生RLC失败的LCID的指示”取值为否,则指示删除LCID。
类似地,例如增加removal of LCID字段,该字段为枚举类型,包含2个值,分别为true和false,分别表示删除LCID和保留LCID。或者该字段为整型,包含2个值0和1,分别表示删除LCID和保留LCID。
可选的,该指示信息可以为必选项,通过不同的赋值指示不同的内容;或者,该指示信息也可以为可选项,通过有或者无来指示不同内容。
情况2、第三消息仅包括发生RLC失败的LCID。
在情况2中,由CU向DU指示哪些LCID发生了RLC失败,DU执行L2处理的具体操作,由DU接收到第三消息时自行决策并执行。
需要说明的是,情况2中DU接收到第三消息后决策执行L2处理的具体操作,以及情况2中L2处理的内容与情况1中描述的相同,只是决策的执行主体不同,详细内容已经在上述情况1中进行了详细说明,此处不再进行赘述。
第三消息是CU-DU接口消息。目前,NR网络中CU-DU接口消息定义为F1消息。当然,CU-DU接口消息也可以有其他名称。当CU-DU架构的网络制式不同时,接口消息还可以定义不同的名称,本申请不进行具体限定。例如,LTE网络中,CU-DU架构的基站中CU-DU之间的接口可以定义为W1接口,W1接口上传递的消息称之为W1消息。示例性的,第三消息可以是W1消息。
可选的,第三消息可以为当前现有的CU-DU接口消息,或者,第三消息也可以为新定义的专用于RLC失败时通知DU执行L2处理的消息,本申请实施例对此也不进行具体限定。
一种可能的实现中,当第三消息为当前现有的CU-DU接口消息时,第三消息可以是UE上下文修改请求(UE context modification request)消息。当第三消息为新定义的F1接口消息或W1接口消息时,第三消息可以是RLC失败通知(RLC failure notificaiton)消息。
可选的,第三消息中包括的发生RLC失败的LCID以及指示DU执行L2处理的指示信息,或者,发生RLC失败的LCID,可以直接包含于第三消息,作为第三消息中的字段。
可选的,第三消息中包括的发生RLC失败的LCID以及指示DU执行L2处理的指示信息,或者,发生RLC失败的LCID,可以包含于第三消息中的第二字段中。其中,第二字段为第三消息中的任一字段。
可选的,当第三消息为现有消息时,第二字段可以为现有消息中的现有字段,也可以为新定义的字段,本申请实施例对此不进行具体限定。
示例性的,当第三消息为UE上下文修改请求消息时,UE上下文修改请求消息中第二字段包括发生RLC失败的LCID以及指示DU执行L2处理的指示信息,或者,发生RLC失败的LCID。该第二字段可以为UE上下文修改请求消息中的现有字段,也可以为新定义字段,本申请实施例对此不进行具体限定。
示例性的,当第三消息为UE上下文修改请求消息时,第二字段可以包括新定义的RLC失败的LCID列表(LCID with RLC failure list)字段。
示例性的,当第三消息为UE上下文修改请求消息,第一字段为新定义的RLC失败的LCID列表字段,该字段内容可以为:
LCID with RLC failure list
>LCID with RLC failure list IEs
>>LCID
>>PDCP duplication/removal of LCID/keep PDCP duplication/remove PDCPduplication/keep LCID/remove LCID(可选)。
该字段中包含发生RLC失败的LCID。可选地,还可以包含是否保留PDCP复制的指示即PDCP duplication,或者是否删除LCID的指示即removal of LCID,或者保留PDCP重复的指示即keep PDCP duplicaiton,或者删除PDCP重复的指示,或者保留LCID的指示即keepLCID,或者删除LCID的指示即remove LCID。
示例性的,当第三消息为UE上下文修改请求消息,第二字段为发生RLC失败的LCID对应的DRB的DRB to Be Modified List字段,该字段内容可以为:
DRB to be modified List
>DRB to be modified Item IEs
>>DRB ID
>>RLC failure或者LCID with RLC failure
>>PDCP duplication/removal of LCID/keep PDCP duplication/remove PDCPduplication/keep LCID/remove LCID(可选)。
需要说明的是,第二字段为发生RLC失败的LCID对应的DRB的DRB to Be ModifiedList字段时,前提要求CU可以获知DRB的ID和LCID的映射关系,根据LCID找到对应的DRB的ID,并增加RLC failure指示。当消息中包含RLC failure指示时,DU需要根据DRB的ID和LCID的映射关系,找到对应的LCID,获知改LCID发生了RLC failure。当消息中包含LCIDwith RLC failure,DU直接可以获知哪个LCID发生了RLC failure。
示例性的,当第三消息为UE上下文修改请求消息,第二字段为发生RLC失败的LCID对应的SRB的SRB to Be Modified List字段,该字段内容可以为:
SRB to be modified List
>SRB to be modified Item IEs
>>SRB ID
>>RLC failure或者LCID with RLC failure
>>PDCP duplication/removal of LCID/keep PDCP duplication/remove PDCPduplication/keep LCID/remove LCID(可选)。
需要说明的是,第二字段为发生RLC失败的LCID对应的SRB的SRB to Be ModifiedList字段时,前提要求CU可以获知SRB的ID和LCID的映射关系,根据LCID找到对应的SRB的ID,并增加RLC failure指示。当消息中包含RLC failure指示时,DU需要根据SRB的ID和LCID的映射关系,找到对应的LCID,获知改LCID发生了RLC failure。当消息中包含LCIDwith RLC failure,DU直接可以获知哪个LCID发生了RLC failure。
示例性的,当第三消息为UE上下文修改请求消息,L2处理为删除发生RLC失败的LCID对应的SCells时,第二字段可以为UE上下文修改请求消息中的辅小区删除列表(SCells to be removed list)。例如CU通过读取DU提供的小区组配置,获知LCID和辅小区的映射关系,例如通过读取LCID对应的allowedservingcell字段。CU根据LCID找到对应的辅小区,CU在UE上下文修改请求消息中增加辅小区删除列表,包含发生RLC失败的LCID所对应的SCells。
进一步可选的,第三消息还可以包括CU提供的新的SCell,以替换发生RLC失败的LCID对应的SCell。
示例性的,可以通过现有的SCell to be added list字段提供的新的SCell,当然,也可以通过其他方式提供,本申请实施例对此不进行具体限定。
S802、DU从CU接收第三消息。
其中,第三消息包括发生RLC失败的LCID以及指示DU执行L2处理的指示信息;或者,第三消息包括发生RLC失败的LCID。
需要说明的是,S802中DU从CU接收的第三消息,即S801中CU发送的第三消息,对于第三消息已经在S801中进行了详细说明,此处不再进行赘述。
S803、DU执行L2处理。
具体的,对应于S801中第三消息的两种情况,S803中的处理方式不同。
可选的,对应于S801中的情况1,S803中DU根据指示信息的指示执行L2处理。对应于S801中的情况2,S803中DU决策并执行L2处理。
其中,DU决策是指DU根据网络状态确定执行L2处理的具体操作。其具体操作的可选方案,已经在S801中情况1中进行了详细说明,此处不再进行赘述。
进一步可选的,对应于S801中的情况2,S803中DU决策并执行L2处理后,还需要将其决策的L2处理的内容向CU进行通知。
示例性的,假设L2处理为DU删除发生RLC失败的LCID对应的SCells,即CU通过第三消息指示获知哪些LCID发生了RLC失败,就暗示了DU需要删除发生RLC失败的LCID对应的SCells。此外,DU还可以决策是否保留PDCP重复。DU将决策结果告知CU,例如DU给CU发送通知消息,该通知消息可以包含是否删除PDCP重复的指示,或者删除PDCP重复的指示,或者是否保留PDCP重复的指示,或者保留PDCP重复的指示。当然,也可以使只有当DU决定删除PDCP重复时,才需要通知CU。该通知消息可以包含是否删除PDCP重复的指示,或者删除PDCP重复的指示。以便CU在PDCP配置中删除PDCP重复相关的配置信息。或者,DU还可以决策是否删除发生RLC失败的LCID。当DU决定是否删除发生RLC失败的LCID,或者决定删除发生RLC失败的LCID时,将决策结果告知CU,通知方法和通知CU是否删除PDCP重复或删除PDCP重复类似,此处不再赘述。
需要说明的是,对于DU执行L2处理的过程,即进行RLC层及MAC层配置,本申请对该过程不进行赘述,可以参考现有机制进行。
进一步可选的,当DU执行L2处理删除了SCell,还需要进行SCell分配。一种可能的实现是将现有的SCell重新分配,一种可能是将现有的SCell以及CU提供的新的SCell一起重新分配。本申请实施例对此不进行具体限定。
进一步可选的,第三消息还可以包括CU提供的新的SCell,以替换发生RLC失败的LCID对应的SCell。
示例性的,假设DRB1对应LCID1和LCID2,其中LCID2对应的RLC发生了RLCfailure,假设CU提供的新SCell为6、7,DU进行SCell分配如表2所示。
表2
Figure BDA0001762105000000291
S804、DU向CU发送第四消息,第四消息包括L2处理的小区组配置。
具体的,DU执行了L2处理,进行RLC层及MAC层配置,其配置的具体内容生产小区组配置(CellGroupConfig),需要通过CU发送给UE,以使得UE进行相同的配置。因此,DU通过向CU发送第二消息,以通过CU将小区组配置发送给UE。
可选的,若第三消息为请求响应机制的请求消息,则第四消息可以为第三消息的响应消息;若第三消息为非请求响应机制的消息,则第四消息为一条单独的消息。本申请对于第四消息的类型不进行具体限定。
示例性的,第四消息可以包括:UE上下文修改请求消息的响应消息。
S805、CU接收DU发送的第四消息。
其中,第四消息包括L2处理的小区组配置。
需要说明的是,S805中CU从DU接收的第四消息,即S804中DU发送的第四消息,对于第四消息已经在S804中进行了详细说明,此处不再进行赘述。
进一步的,如图9所示,在S805之后,本申请实施例提供的通知方法还可以包括S806。
S806、CU向UE发送RRC重配置消息,RRC重配置消息包括小区组配置。
具体的,CU在S805中接收到第四消息后,将自身负责的L2处理(例如PDCP层配置)的相关配置以及第四消息中的小区组配置,添加至RRC重配置消息中发送给UE,以使得UE进行相同的配置,其具体过程不在进行赘述。
通过本申请提供的通知方法,DU从CU获取发生RLC失败的LCID以及执行L2处理的方案的指示信息;或者,DU从CU获取发生RLC失败的LCID确定发生了RLC失败。这样一来,使得DU获知发生了RLC失败的LCID以及L2处理的方案;或者,使得DU获知哪些LCID发生了RLC失败,便于DU执行准确对应的L2处理,以进行适应终端设备通信链路变化的L2配置。
需要说明的是,上述实现是从控制面实现CU向DU通知,在另一种可能的实现方式中,可以通过UP实现本申请提供的通知方法。
具体的,CU和DU之间的用户面隧道是DRB粒度或LCID粒度的。例如当CU和DU执行基于载波聚合的PDCP重复时,CU和DU之间将针对一个DRB建立2个F1-U隧道。例如,CU在UEcontext setup/modification request(UE上下文建立/修改请求)消息中包含DRB ID以及对应的CU侧传输层信息,传输层信息可以包含TEID和或传输层地址,DU在响应消息中包含DRB ID以及对应的DU侧TEID。CU侧TEID和DU TEID可以唯一识别一个用户面隧道,即唯一识别一个DRB/LCID。可选地,CU侧传输层地址和DU侧传输层地址可以唯一识别一个用户面隧道,即唯一识别一个DRB/LCID。则第一消息中可以包括和DRB ID对应的接口传输层地址。在此实现中,第三消息包括发生RLC失败的LCID对应的接口TEID,RLC失败指示以及指示DU执行L2处理的指示信息;或者,第三消息包括发生RLC失败的LCID对应的接口TEID以及指示DU执行L2处理的指示信息;或者,第三消息包括发生RLC失败的LCID对应的TEID以及RLC失败指示。其具体实现可以参考上述控制面的具体实现,此处不再一一赘述。当CU在给DU发送下行数据包时,在数据包头将携带TEID。当数据包头携带RLC失败指示时,根据隧道端点地址和LCID的绑定关系,确定是哪个LCID发生RLC失败。当数据包头携带RLC失败指示以及指示DU执行L2处理的指示信息时,根据隧道端点地址和LCID的绑定关系,确定哪个LCID发生了RLC失败,需要执行什么样的L2处理。当当数据包头携带指示DU执行L2处理的指示信息时,根据隧道端点地址和LCID的绑定关系,确定哪个LCID需要执行什么样的L2处理。
上述主要从CU、DU的工作过程的角度对本申请实施例提供的方案进行了介绍。可以理解的是,CU、DU为了实现上述功能,其包含了执行各个功能相应的硬件结构和/或软件模块。本领域技术人员应该很容易意识到,结合本文中所公开的实施例描述的各示例的单元及算法步骤,本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行,取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能,但是这种实现不应认为超出本申请的范围。
需要说明的是,CU、DU中执行本申请提供的通知方法的功能部分称之为通知装置,可以理解的是,通知装置可以为CU或DU的部分或全部,换言之,通知装置可以与CU或DU等价,或者,通知装置也可以部署在CU或DU内,以支持CU或DU执行本申请提供的通知方法。
本申请实施例可以根据上述方法示例对CU、DU进行功能模块的划分,例如,可以对应各个功能划分各个功能模块,也可以将两个或两个以上的功能集成在一个处理模块中。上述集成的模块既可以采用硬件的形式实现,也可以采用软件功能模块的形式实现。需要说明的是,本申请实施例中对模块的划分是示意性的,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式。当通知装置为CU或DU的部分或全部时,对CU或DU进行功能模块的划分,就相当于对通知装置进行功能模块的划分;或者,当通知装置为CU或DU的部分或全部时,对通知装置进行功能模块的划分,就相当于对CU或DU进行功能模块的划分。
在采用对应各个功能划分各个功能模块的情况下,图10示出了上述实施例中所涉及的CU中的通知装置的一种可能的结构示意图。通知装置100可以包括:发送单元1001以及接收单元1002。发送单元1001用于执行图6或图7中的过程S601、S606,或者执行图8或图9中的过程S801、S806;接收单元1002用于执行图6或图7中的过程S605,或者执行图8或图9中的过程S805。其中,上述方法实施例涉及的各步骤的所有相关内容均可以援引到对应功能模块的功能描述,在此不再赘述。
进一步的,如图11所示,通知装置100还可以包括处理单元1003。其中,处理单元1003用于执行图6或图7中的过程S601a,或者执行图8或图9中的过程S801a。
在采用集成的单元的情况下,图12示出了上述实施例中所涉及的CU中的通知装置的一种可能的结构示意图。通知装置120可以包括:处理模块1201、通信模块1202。处理模块1201用于对通知装置120的动作进行控制管理。例如,处理模块1201用于通过通信单元1202支持通知装置120执行图6或图7中的过程S601、S605、S606,或者执行图8或图9中的过程S801、S805、S806;处理模块1201用于支持通知装置120执行图6或图7中的过程S601a,或者执行图8或图9中的过程S801a。通知装置120还可以包括存储模块1203,用于存储通知装置120的程序代码和数据。
其中,当通知装置120部署在CU内时,处理模块1201可以为图4所示的CU 40的实体结构中的处理器401,可以是处理器或控制器。例如可以是CPU,通用处理器,DSP,ASIC,FPGA或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。其可以实现或执行结合本申请公开内容所描述的各种示例性的逻辑方框,模块和电路。处理器1201也可以是实现计算功能的组合,例如包含一个或多个微处理器组合,DSP和微处理器的组合等等。通信模块1202可以为图4所示的CU 40的实体结构中的收发器403,通信模块1202可以是通信端口,或者可以是收发器、收发电路或通信接口等。或者,上述通信接口可以通过上述具有收发功能的元件,实现与其他设备的通信。上述具有收发功能的元件可以由天线和/或射频装置实现。存储模块1203可以是图4所示的CU 40的实体结构中的存储器402。
当处理模块1201为处理器,通信模块1202为收发器,存储模块1203为存储器时,本申请实施例图12所涉及的通知装置120可以为图4所示的CU 40的部分或全部。
如前述,本申请实施例提供的通知装置100或通知装置120可以用于实施上述本申请各实施例实现的方法中CU的功能,为了便于说明,仅示出了与本申请实施例相关的部分,具体技术细节未揭示的,请参照本申请各实施例。
在采用对应各个功能划分各个功能模块的情况下,图13示出了上述实施例中所涉及的DU中的通知装置的一种可能的结构示意图。通知装置130可以包括:接收单元1301、处理单元1302、发送单元1303。接收单元1301用于执行图6或图7中的过程S602,或者执行图8或图9中的过程S802;处理单元1302用于执行图6或图7中的过程S603,或者执行图8或图9中的过程S803;发送单元1303用于执行图6或图7中的过程S604,或者执行图8或图9中的过程S804。其中,上述方法实施例涉及的各步骤的所有相关内容均可以援引到对应功能模块的功能描述,在此不再赘述。
在采用集成的单元的情况下,图14示出了上述实施例中所涉及的DU中的通知装置的一种可能的结构示意图。通知装置140可以包括:处理模块1401、通信模块1402。处理模块1401用于对通知装置140的动作进行控制管理。例如,处理模块1401用于通过通信单元1402支持通知装置140执行图6或图7中的过程S602、S604,或者执行图8或图9中的过程S802、S804;处理模块1401用于支持通知装置140执行图6或图7中的过程S603,或者执行图8或图9中的过程S803。通知装置140还可以包括存储模块1403,用于存储通知装置140的程序代码和数据。
其中,当通知装置140部署在DU内时,处理模块1401可以为图5所示的DU 50的实体结构中的处理器501,可以是处理器或控制器。例如可以是CPU,通用处理器,DSP,ASIC,FPGA或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。其可以实现或执行结合本申请公开内容所描述的各种示例性的逻辑方框,模块和电路。处理器1401也可以是实现计算功能的组合,例如包含一个或多个微处理器组合,DSP和微处理器的组合等等。通信模块1402可以为图5所示的DU 50的实体结构中的收发器503,通信模块1402可以是通信端口,或者可以是收发器、收发电路或通信接口等。或者,上述通信接口可以通过上述具有收发功能的元件,实现与其他设备的通信。上述具有收发功能的元件可以由天线和/或射频装置实现。存储模块1403可以是图5所示的DU 50的实体结构中的存储器502。
当处理模块1401为处理器,通信模块1402为收发器,存储模块1403为存储器时,本申请实施例图14所涉及的通知装置140可以为图5所示的DU 50的部分或全部。
如前述,本申请实施例提供的通知装置130或通知装置140可以用于实施上述本申请各实施例实现的方法中DU的功能,为了便于说明,仅示出了与本申请实施例相关的部分,具体技术细节未揭示的,请参照本申请各实施例。
再一方面,本申请实施例提供一种基站,包括上述任一承载类型切换实施例描述的CU,以及上述任一承载类型切换实施例描述的DU。
再一方面,本申请实施例提供一种基站,包括上述任一RLC失败实施例描述的CU,以及上述任一RLC失败实施例描述的DU。
结合本申请公开内容所描述的方法或者算法的步骤可以硬件的方式来实现,也可以是由处理器执行软件指令的方式来实现。软件指令可以由相应的软件模块组成,软件模块可以被存放于RAM、闪存、ROM、可擦除可编程只读存储器(Erasable Programmable ROM,EPROM)、电可擦可编程只读存储器(Electrically EPROM,EEPROM)、寄存器、硬盘、移动硬盘、只读光盘(CD-ROM)或者本领域熟知的任何其它形式的存储介质中。一种示例性的存储介质耦合至处理器,从而使处理器能够从该存储介质读取信息,且可向该存储介质写入信息。当然,存储介质也可以是处理器的组成部分。处理器和存储介质可以位于ASIC中。另外,该ASIC可以位于核心网接口设备中。当然,处理器和存储介质也可以作为分立组件存在于核心网接口设备中。或者,存储器可以与处理器耦合,例如存储器可以是独立存在,通过总线与处理器相连接。存储器也可以和处理器集成在一起。存储器可以用于存储执行本申请实施例提供的技术方案的应用程序代码,并由处理器来控制执行。处理器用于执行存储器中存储的应用程序代码,从而实现本申请实施例提供的技术方案。
本申请实施例再提供一种芯片系统,该芯片系统包括处理器,用于实现本发明实施例通信设备的技术方法。在一种可能的设计中,该芯片系统还包括存储器,用于保存本发明实施例通信设备必要的程序指令和/或数据。在一种可能的设计中,该芯片系统还包括存储器,用于处理器调用存储器中存储的应用程序代码。该芯片系统,可以由一个或多个芯片构成,也可以包含芯片和其他分立器件,本申请实施例对此不作具体限定。
所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,上述描述的系统,装置和单元的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。
本领域技术人员应该可以意识到,在上述一个或多个示例中,本申请所描述的功能可以用硬件、软件、固件或它们的任意组合来实现。当使用软件实现时,可以将这些功能存储在计算机可读介质中或者作为计算机可读介质上的一个或多个指令或代码进行传输。计算机可读介质包括计算机存储介质和通信介质,其中通信介质包括便于从一个地方向另一个地方传送计算机程序的任何介质。存储介质可以是通用或专用计算机能够存取的任何可用介质。所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,上述描述的系统,装置和单元的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。
在本申请所提供的几个实施例中,应该理解到,所揭露的系统,装置和方法,可以通过其它的方式实现。例如,以上所描述的装置实施例仅仅是示意性的,例如,所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,装置或单元的间接耦合或通信连接,可以是电性或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外,在本申请各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理包括,也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现,也可以采用硬件加软件功能单元的形式实现。
上述以软件功能单元的形式实现的集成的单元,可以存储在一个计算机可读取存储介质中。上述软件功能单元存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本申请各个实施例所述方法的部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(Read-Only Memory,ROM)、随机存取存储器(Random Access Memory,RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
最后应说明的是:以上实施例仅用以说明本申请的技术方案,而非对其限制;尽管参照前述实施例对本申请进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。

Claims (29)

1.一种通知方法,其特征在于,应用于集中单元CU-分布单元DU架构中的所述CU,所述方法包括:
所述CU向所述DU发送第一消息,所述第一消息包括发生承载类型切换的第一数据无线承载DRB的标识ID以及指示所述DU执行L2处理的第一指示信息;或者,所述第一消息包括所述第一DRB的ID以及指示发生承载类型切换的第二指示信息;
所述CU接收所述DU发送的第二消息,所述第二消息包括L2处理的小区组配置。
2.根据权利要求1所述的通知方法,其特征在于,所述执行L2处理包括:
媒体接入控制层MAC重置以及无线链路控制层RLC重建立;或者,
更改逻辑信道标识LCID以及RLC重建立;或者,
MAC同步重配置以及RLC重建立;或者,
更改LCID以及RLC承载释放和增加。
3.根据权利要求1或2所述的通知方法,其特征在于,所述第一消息还包括主小区组MCG指示,所述执行L2处理包括:
MAC重置以及RLC重建立;或者,
更改LCID以及RLC重建立。
4.根据权利要求1或2所述的通知方法,其特征在于,所述第一消息还包括辅小区组SCG指示,所述执行L2处理包括:
MAC同步重配置以及RLC重建立;或者,
更改LCID以及RLC承载释放和增加。
5.根据权利要求1-4任一项所述的通知方法,其特征在于,所述第一消息还包括:
第二DRB的ID,所述第二DRB的ID用于替换所述第一DRB的ID。
6.一种通知方法,其特征在于,应用于集中单元CU-分布单元DU架构中的所述DU,所述方法包括:
所述DU从所述CU接收第一消息,所述第一消息包括发生承载类型切换的第一数据无线承载DRB的标识ID以及指示所述DU执行L2处理的方案的第一指示信息;或者,所述第一消息包括所述第一DRB的ID以及指示发生承载类型切换的第二指示信息;
DU执行L2处理;
所述DU向所述CU发送第二消息,所述第二消息包括L2处理的小区组配置。
7.根据权利要求6所述的通知方法,其特征在于,若所述第一消息包括所述第一DRB的ID以及所述第二指示信息,所述DU执行L2处理,包括:
所述DU决策并执行L2处理。
8.根据权利要求6或7所述的通知方法,其特征在于,所述执行L2处理的方案包括:
媒体接入控制层MAC重置以及无线链路控制层RLC重建立;或者,
更改逻辑信道标识LCID以及RLC重建立;或者,
MAC同步重配置以及RLC重建立;或者,
更改LCID以及RLC承载释放和增加。
9.根据权利要求6-8任一项所述的通知方法,其特征在于,所述第一消息还包括主小区组MCG指示,所述执行L2处理的方案包括:
MAC重置以及RLC重建立;或者,
更改LCID以及RLC重建立。
10.根据权利要求6-8任一项所述的通知方法,其特征在于,所述第一消息还包括辅小区组SCG指示,所述执行L2处理的方案包括:
MAC同步重配置以及RLC重建立;或者,
更改LCID以及RLC承载释放和增加。
11.根据权利要求6-10任一项所述的通知方法,其特征在于,所述第一消息还包括:第二DRB的ID,所述第二DRB的ID用于替换所述第一DRB的ID;
所述方法还包括:所述DU对所述第一DRB和/或所述第二DRB执行L2处理。
12.一种通知装置,其特征在于,部署于集中单元CU-分布单元DU架构中的所述CU,所述装置包括:
发送单元,用于向所述DU发送第一消息,所述第一消息包括发生承载类型切换的第一数据无线承载DRB的标识ID以及指示所述DU执行L2处理的第一指示信息;或者,所述第一消息包括所述第一DRB的ID以及指示发生承载类型切换的第二指示信息;
接收单元,用于接收所述DU发送的第二消息,所述第二消息包括L2处理的小区组配置。
13.根据权利要求12所述的通知装置,其特征在于,所述执行L2处理包括:
媒体接入控制层MAC重置以及无线链路控制层RLC重建立;或者,
更改逻辑信道标识LCID以及RLC重建立;或者,
MAC同步重配置以及RLC重建立;或者,
更改LCID以及RLC承载释放和增加。
14.根据权利要求12或13所述的通知装置,其特征在于,所述第一消息还包括主小区组MCG指示,所述执行L2处理包括:
MAC重置以及RLC重建立;或者,
更改逻辑信道标识LCID以及RLC重建立。
15.根据权利要求12或13所述的通知装置,其特征在于,所述第一消息还包括辅小区组SCG指示,所述执行L2处理包括:
MAC同步重配置以及RLC重建立;或者,
更改LCID以及RLC承载释放和增加。
16.根据权利要求12-15任一项所述的通知装置,其特征在于,所述第一消息还包括:
第二DRB的ID,所述第二DRB的ID用于替换所述第一DRB的ID。
17.一种通知装置,其特征在于,部署于集中单元CU-分布单元DU架构中的所述DU,所述装置包括:
接收单元,用于从所述CU接收第一消息,所述第一消息包括发生承载类型切换的第一数据无线承载DRB的标识ID以及指示所述DU执行L2处理的方案的第一指示信息;或者,所述第一消息包括所述第一DRB的ID以及指示发生承载类型切换的第二指示信息;
处理单元,用于执行L2处理;
发送单元,用于向所述CU发送第二消息,所述第二消息包括L2处理的小区组配置。
18.根据权利要求17所述的通知装置,其特征在于,若所述第一消息包括所述第一DRB的ID以及所述第二指示信息,所述处理单元具体用于:决策并执行L2处理。
19.根据权利要求17或18所述的通知装置,其特征在于,所述执行L2处理包括:
媒体接入控制MAC重置以及无线链路控制层RLC重建立;或者,
更改逻辑信道标识LCID以及RLC重建立;或者,
MAC同步重配置以及RLC重建立;或者,
更改LCID以及RLC承载释放和增加。
20.根据权利要求17-19任一项所述的通知装置,其特征在于,所述第一消息还包括主小区组MCG指示,所述执行L2处理包括:
MAC重置以及RLC重建立;或者,
更改逻辑信道标识LCID以及RLC重建立。
21.根据权利要求17-19任一项所述的通知装置,其特征在于,所述第一消息还包括辅小区组SCG指示,所述执行L2处理包括:
MAC同步重配置以及RLC重建立;或者,
更改LCID以及RLC承载释放和增加。
22.根据权利要求17-21任一项所述的通知装置,其特征在于,所述第一消息还包括:第二DRB的ID,所述第二DRB的ID用于替换所述第一DRB的ID;
所述方法还包括:所述DU对所述第一DRB和/或所述第二DRB执行L2处理。
23.一种通知装置,其特征在于,所述装置包括处理器、存储器以及存储在存储器上并可在处理器上运行的指令,当所述指令被运行时,使得所述装置执行如权利要求1至5任一项所述的通知方法。
24.一种通知装置,其特征在于,所述装置包括处理器、存储器以及存储在存储器上并可在处理器上运行的指令,当所述指令被运行时,使得所述装置执行如权利要求6至11任一项所述的通知方法。
25.一种集中单元CU,其特征在于,包括如权利要求23所述的通知装置。
26.一种分布单元DU,其特征在于,包括如权利要求24所述的通知装置。
27.一种基站,其特征在于,包括如权利要求25所述的集中单元CU,及如权利要求26所述的分布单元DU。
28.一种计算机可读存储介质,其特征在于,包括指令,当其在计算机上运行时,使得计算机执行如权利要求1至5任一项所述的通知方法。
29.一种计算机程序产品,其特征在于,包括指令,当其在计算机上运行时,使得计算机执行权利要求6至11任一项所述的通知方法。
CN201810914051.3A 2018-08-10 2018-08-10 一种通知方法、装置及基站 Active CN110831248B (zh)

Priority Applications (7)

Application Number Priority Date Filing Date Title
CN202110844100.2A CN113784457B (zh) 2018-08-10 2018-08-10 一种通知方法、装置及基站
CN201810914051.3A CN110831248B (zh) 2018-08-10 2018-08-10 一种通知方法、装置及基站
PCT/CN2019/100098 WO2020030154A1 (zh) 2018-08-10 2019-08-09 一种通知方法、装置及通信系统
EP23219018.1A EP4362600A2 (en) 2018-08-10 2019-08-09 Notification method, apparatus, and communications system
EP19848173.1A EP3820238B1 (en) 2018-08-10 2019-08-09 Notification methods
AU2019319488A AU2019319488B2 (en) 2018-08-10 2019-08-09 Notification method, apparatus, and communications system
US17/169,800 US11963131B2 (en) 2018-08-10 2021-02-08 Notification method, apparatus, and communications system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201810914051.3A CN110831248B (zh) 2018-08-10 2018-08-10 一种通知方法、装置及基站

Related Child Applications (1)

Application Number Title Priority Date Filing Date
CN202110844100.2A Division CN113784457B (zh) 2018-08-10 2018-08-10 一种通知方法、装置及基站

Publications (2)

Publication Number Publication Date
CN110831248A true CN110831248A (zh) 2020-02-21
CN110831248B CN110831248B (zh) 2021-08-03

Family

ID=69413243

Family Applications (2)

Application Number Title Priority Date Filing Date
CN202110844100.2A Active CN113784457B (zh) 2018-08-10 2018-08-10 一种通知方法、装置及基站
CN201810914051.3A Active CN110831248B (zh) 2018-08-10 2018-08-10 一种通知方法、装置及基站

Family Applications Before (1)

Application Number Title Priority Date Filing Date
CN202110844100.2A Active CN113784457B (zh) 2018-08-10 2018-08-10 一种通知方法、装置及基站

Country Status (5)

Country Link
US (1) US11963131B2 (zh)
EP (2) EP4362600A2 (zh)
CN (2) CN113784457B (zh)
AU (1) AU2019319488B2 (zh)
WO (1) WO2020030154A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2022067525A1 (zh) * 2020-09-29 2022-04-07 华为技术有限公司 一种指示业务状态的方法、基站及终端
CN115085877A (zh) * 2021-03-11 2022-09-20 维沃移动通信有限公司 信息传输方法、装置及iab节点

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018165995A1 (zh) * 2017-03-13 2018-09-20 华为技术有限公司 一种数据处理方法及终端设备、基站
CN112954822B (zh) 2018-06-21 2023-04-11 北京三星通信技术研究有限公司 处理rlc失败的方法、网络设备及计算机存储介质
CN112385173B (zh) * 2018-07-19 2023-05-16 Oppo广东移动通信有限公司 D2d通信的方法和终端设备
CN114513803B (zh) * 2022-02-25 2024-03-22 成都中科微信息技术研究院有限公司 一种提升基站cu和du之间小区管理状态一致性的方法及系统
CN117014976A (zh) * 2022-04-29 2023-11-07 维沃移动通信有限公司 小区切换方法、装置、终端及网络侧设备
WO2023225895A1 (zh) * 2022-05-25 2023-11-30 Oppo广东移动通信有限公司 无线通信的方法及设备
WO2024082361A1 (en) * 2022-11-11 2024-04-25 Lenovo (Beijing) Limited Method and apparatus of data transmission

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106134240A (zh) * 2014-03-21 2016-11-16 三星电子株式会社 用于在支持多个载波的移动通信系统中发送/接收信号的方法和装置
WO2018059866A1 (en) * 2016-09-28 2018-04-05 Sony Corporation Telecommunications apparatus and methods for handling split radio bearers
US20180124612A1 (en) * 2016-11-02 2018-05-03 Ofinno Technologies, Llc Dual connectivity with licensed assisted access
CN108282892A (zh) * 2017-01-06 2018-07-13 电信科学技术研究院 无线资源控制消息的传输方法、中央单元及分布式单元
CN108307545A (zh) * 2016-09-23 2018-07-20 中兴通讯股份有限公司 Bbu和rru功能重构后的数据发送装置及方法

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU2667508C2 (ru) * 2014-01-29 2018-09-21 Хуавэй Текнолоджиз Ко., Лтд. Способ и устройство для обработки отказа линии радиосвязи
WO2015143702A1 (zh) * 2014-03-28 2015-10-01 富士通株式会社 承载管理装置、方法以及通信系统
US10219317B2 (en) * 2014-09-25 2019-02-26 Lg Electronics Inc. Method for handling of data transmission and reception for SeNB related bearer release at a user equipment in a dual connectivity system and device therefor
CN106162730B (zh) * 2016-07-12 2019-11-15 上海华为技术有限公司 一种通信的方法、设备及系统
CN112672343B (zh) * 2016-08-09 2022-04-26 三星电子株式会社 无线通信系统中管理用户平面操作的方法和装置
CN107872876B (zh) * 2016-09-23 2021-07-16 华为技术有限公司 消息的发送方法和装置
EP3515148B1 (en) * 2016-10-27 2021-03-17 LG Electronics Inc. Method and apparatus for establishing bearer
KR102222830B1 (ko) * 2017-03-21 2021-03-04 삼성전자 주식회사 이동통신에서 연결 모드의 비연속 수신 모드를 지원하는 방법 및 장치
KR20240010085A (ko) * 2017-05-05 2024-01-23 삼성전자주식회사 패킷 데이터 수렴 프로토콜 복제 기능을 지원하는 시스템, 데이터 송신 방법 및 네트워크 장비, 및 부가적 상향링크 반송파 구성 정보를 전송하는 방법 및 장치 그리고 연결 이동성 조정을 수행하는 방법 및 장치
US10470159B2 (en) * 2017-05-08 2019-11-05 Kt Corporation Method and apparatus for transmitting and receiving message based on fronthaul interface
US10499376B2 (en) * 2017-06-16 2019-12-03 Kt Corporation Methods for managing resource based on open interface and apparatuses thereof
CN111096061A (zh) * 2017-06-16 2020-05-01 苹果公司 用于承载类型更改的l2处理
EP4132212A3 (en) * 2017-06-16 2023-06-07 Beijing Xiaomi Mobile Software Co., Ltd. Distributed unit configuration update
US10869353B2 (en) * 2017-07-23 2020-12-15 Lg Electronics Inc. Method and apparatus for modifying radio bearer in CU-DU split scenario
CN110999521B (zh) * 2017-07-30 2023-06-30 Lg 电子株式会社 在cu-du划分场景中恢复rrc连接的方法和装置
CN109788544B (zh) * 2017-11-15 2021-06-18 大唐移动通信设备有限公司 一种层2处理方法、cu及du

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106134240A (zh) * 2014-03-21 2016-11-16 三星电子株式会社 用于在支持多个载波的移动通信系统中发送/接收信号的方法和装置
CN108307545A (zh) * 2016-09-23 2018-07-20 中兴通讯股份有限公司 Bbu和rru功能重构后的数据发送装置及方法
WO2018059866A1 (en) * 2016-09-28 2018-04-05 Sony Corporation Telecommunications apparatus and methods for handling split radio bearers
US20180124612A1 (en) * 2016-11-02 2018-05-03 Ofinno Technologies, Llc Dual connectivity with licensed assisted access
CN108282892A (zh) * 2017-01-06 2018-07-13 电信科学技术研究院 无线资源控制消息的传输方法、中央单元及分布式单元

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
SAMSUNG: "《3GPP TSG-RAN WG2 Meeting #102;R2-1807551》", 10 May 2018 *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2022067525A1 (zh) * 2020-09-29 2022-04-07 华为技术有限公司 一种指示业务状态的方法、基站及终端
CN115085877A (zh) * 2021-03-11 2022-09-20 维沃移动通信有限公司 信息传输方法、装置及iab节点
CN115085877B (zh) * 2021-03-11 2024-05-03 维沃移动通信有限公司 信息传输方法、装置及iab节点

Also Published As

Publication number Publication date
AU2019319488A1 (en) 2021-03-04
CN113784457B (zh) 2022-08-19
US20210168758A1 (en) 2021-06-03
EP3820238B1 (en) 2024-01-31
US11963131B2 (en) 2024-04-16
EP3820238A4 (en) 2021-09-01
WO2020030154A1 (zh) 2020-02-13
CN110831248B (zh) 2021-08-03
AU2019319488B2 (en) 2022-03-24
EP4362600A2 (en) 2024-05-01
CN113784457A (zh) 2021-12-10
EP3820238A1 (en) 2021-05-12

Similar Documents

Publication Publication Date Title
CN110831248B (zh) 一种通知方法、装置及基站
JP7222419B2 (ja) 重複伝送の設定及び/又はアクティベーション方法、重複伝送の方法及び装置
CN112584550A (zh) 一种双连接管理方法和通信装置
CN114900547B (zh) 一种通信方法及装置
JP2017514367A (ja) ベアラ管理装置、方法及び通信システム
US11558925B2 (en) Notification method and device for execution of PDCP data recovery
CN110868733B (zh) 一种数据传输方法和装置
CN110999388B (zh) 通信装置、方法
US11611501B2 (en) Apparatus, method, and computer program
CN111757548A (zh) 通信方法和通信装置
CN113543214A (zh) 用于分离用户面的服务质量实现
CN114365531A (zh) 主节点、辅节点及其方法
JP7250114B2 (ja) サービスノードの更新方法、端末機器、および、ネットワーク側機器
CN110972215B (zh) 一种切换方法及基站
WO2020030059A1 (zh) 一种信息指示方法及装置
CN109803390B (zh) 消息、策略发送方法及装置,存储介质,处理器
CN113316202A (zh) 一种切换方法及通信装置
JP2018174597A (ja) ベアラ管理装置、方法及び通信システム
WO2022120541A1 (zh) 数据传输的方法和装置
WO2023127272A1 (ja) User Equipment、無線アクセスネットワークノード、及びこれらの方法
WO2021102968A1 (zh) 无线通信的方法、终端设备和网络设备
CN115278653A (zh) 资源调度方法、网络设备、双卡终端和通信系统
WO2023016652A1 (en) Method, apparatus and computer program
CN115696612A (zh) 通信方法、装置及存储介质
CN117676741A (zh) QoS信息的发送方法、接收方法、装置、设备及介质

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant