[go: up one dir, main page]

CN112954822B - 处理rlc失败的方法、网络设备及计算机存储介质 - Google Patents

处理rlc失败的方法、网络设备及计算机存储介质 Download PDF

Info

Publication number
CN112954822B
CN112954822B CN202110287480.4A CN202110287480A CN112954822B CN 112954822 B CN112954822 B CN 112954822B CN 202110287480 A CN202110287480 A CN 202110287480A CN 112954822 B CN112954822 B CN 112954822B
Authority
CN
China
Prior art keywords
information
rlc
failure
rlc failure
rlc entity
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.)
Active
Application number
CN202110287480.4A
Other languages
English (en)
Other versions
CN112954822A (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.)
Samsung Electronics Co Ltd
Original Assignee
Samsung Electronics 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
Application filed by Samsung Electronics Co Ltd filed Critical Samsung Electronics Co Ltd
Priority to CN202110287480.4A priority Critical patent/CN112954822B/zh
Publication of CN112954822A publication Critical patent/CN112954822A/zh
Application granted granted Critical
Publication of CN112954822B publication Critical patent/CN112954822B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/19—Connection re-establishment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/24—Reselection being triggered by specific parameters
    • H04W36/30—Reselection being triggered by specific parameters by measured or perceived connection quality data
    • H04W36/305—Handover due to radio link failure
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/0005—Control or signalling for completing the hand-off
    • H04W36/0055—Transmission or use of information for re-establishing the radio link
    • H04W36/0069—Transmission or use of information for re-establishing the radio link in case of dual connectivity, e.g. decoupled uplink/downlink
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/08—Reselecting an access point
    • H04W36/087—Reselecting an access point between radio units of access points
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/11—Allocation or use of connection identifiers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/18—Management of setup rejection or failure
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/20—Manipulation of established connections
    • H04W76/22—Manipulation of transport tunnels
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/22—Processing or transfer of terminal data, e.g. status or physical capabilities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W92/00—Interfaces specially adapted for wireless communication networks
    • H04W92/04—Interfaces between hierarchically different network devices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/08—Access point devices
    • H04W88/085—Access point devices with remote components

Landscapes

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

Abstract

本申请涉及无线通信技术领域，公开了一种处理RLC失败的方法、电子设备及计算机可读存储介质，其中，处理RLC失败的方法包括：第一网络设备接收用户设备UE的RLC失败相关信息；基于接收到的RLC失败相关信息，通过与第二网络设备进行交互，来对RLC失败进行相应处理。本申请实施例的方法，使得第一网络设备能够直接与第二网络设备进行交互，从而能够直接根据接收到的UE上报的RLC失败相关信息以及交互信息，决定对该RLC失败的处理，从而简化RLC处理的流程，提高处理效率，便于RLC失败的正确且快速的解决，提升用户体验。

Description

处理RLC失败的方法、网络设备及计算机存储介质
本申请为申请号为201810646390.8，申请日为2018年6月21日，发明名称为“处理RLC失败的方法、网络设备及计算机存储介质”的发明专利申请的分案申请。
技术领域
本申请涉及无线通信技术领域，具体而言，本申请涉及一种处理RLC失败的方法、网络设备及计算机存储介质。
背景技术
在NR(New Radio access，新无线接入)网络或第五代5G网络中，为了保证数据传输的可靠性，定义了基于CA的duplication机制(即基于载波聚合的数据包重复机制)，如图1所示。其中，PDCP(packet data convergence protocol，分组数据汇聚协议)层会将产生的PDCP PDU(Protocol Data Unit，协议数据单元)复制成两份，分别发送给两个不同的RLC(Radio link control，无线链路控制)实体(比如RLC1和RLC2)，然后通过不同的逻辑信道(比如逻辑信道1和逻辑信道2)发送给MAC(medium access control，媒体访问控制)层。而来自不同逻辑信道的数据需要通过不同的小区发送，比如来自逻辑信道1的数据需要通过至少一个小区(如小区1-1,小区1-2,…)来发送，来自逻辑信道2的数据需要通过至少一个小区(如小区2-1，小区2-2，…)来发送，并且服务逻辑信道1和逻辑信道2的小区是不同的小区。在上述基于CA的duplication机制中，可以认为该机制所服务的用户被配置了两条路径(path)，一条路径对应的是RLC1，逻辑信道1以及该逻辑信道对应的小区，另一条路径对应的是RLC2，逻辑信道2以及该逻辑信道对应的小区。在图1中，如果是上行，则发送端是UE，接收端是基站；如果是下行，则发送端是基站，接收端是用户。
近期的研究表明，对于配置了CA duplication的用户，如果该用户的逻辑信道所对应(或者说“所关联”)的小区都是SCell(Secondary Cell，辅小区，即不包含主小区PCell和主辅小区PSCell的小区，PCell、PSCell及SCell的定义可以参见协议TS38.331或TS36.331)，当该逻辑信道对应的RLC实体发生了失败(重传次数达到或超过最大重传次数)时，用户侧(即用户设备UE)无需启动RRC(Radio Resource Control，无线资源控制)重建过程，该UE可以向网络侧(即网络侧的设备，可简称为网络设备)提供相关信息(即RLC失败相关信息)，由网络侧来决定对这个失败的处理。在UE向网络侧上报该信息时，可以包含发生失败的RLC实体对应的逻辑信道的标识，也可以包括指示发生失败的RLC实体所对应的SCell所处的小区组(如MCG(Master Cell Group，主小区组)，SCG(Secondary Cell Group,辅小区组)等)。
虽然网络侧能够根据UE上报的RLC失败相关信息对RLC失败进行处理，但是处理过程繁琐、效率低下，不利于正确且快速的解决RLC失败，极大降低了用户体验。
发明内容
本申请的目的旨在至少能解决上述的技术缺陷之一，特别是处理过程繁琐、效率低下的技术缺陷。
第一方面，提供了一种处理RLC失败的方法，包括：
接收用户设备UE发送的RLC失败相关信息；
基于接收到的RLC失败相关信息，对RLC失败进行相应处理。
第二方面，提供了一种处理RLC失败的方法，包括：
第二网络设备接收第一网络设备发送的包括来自UE的RLC失败相关信息的第二请求消息；
基于接收到的第二请求消息，来对RLC失败进行相应处理。
第三方面，提供了一种网络设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行程序时实现上述的处理RLC失败的方法。
第四方面，提供了一种计算机可读存储介质，计算机可读存储介质上存储有计算机程序，该程序被处理器执行时实现上述的处理RLC失败的方法。
本申请实施提供的处理RLC失败的方法，第一网络设备接收用户设备UE的RLC失败相关信息，为后续网络设备对RLC失败进行相应处理提供前提保障；基于接收到的RLC失败相关信息，通过与第二网络设备进行交互，来对RLC失败进行相应处理，使得第一网络设备能够直接与第二网络设备进行交互，从而能够直接根据接收到的UE上报的RLC失败相关信息以及交互信息，决定对该RLC失败的处理，从而简化RLC处理的流程，提高处理效率，便于RLC失败的正确且快速的解决，提升用户体验。
本申请实施例提供的方法，与现有技术相比，第二网络设备接收第一网络设备发送的包括来自UE的RLC失败相关信息的第二请求消息，为后续网络设备对RLC失败进行相应处理提供前提保障；基于接收到的第二请求消息，来对RLC失败进行相应处理，使得第二网络设备能够通过与第一网络设备进行交互，从而能够获取到RLC失败相关信息，进而基于接收到的RLC失败相关信息以及交互得到的交互信息，决定对该RLC失败的处理，从而简化RLC处理的流程，提高处理效率，便于RLC失败的正确且快速的解决，提升用户体验。
本申请附加的方面和优点将在下面的描述中部分给出，这些将从下面的描述中变得明显，或通过本申请的实践了解到。
附图说明
本申请上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中：
图1为现有的基于载波聚合的数据包重复机制的数据传输过程示意图；
图2为现有的CU-DU分离的基站结构；
图3为本申请实施例的一种处理RLC失败的方法的流程示意图；
图4为本申请实施例的CU决定针对RLC失败进行处理的第一流程示意图；
图5为本申请实施例的CU决定针对RLC失败进行处理的第二流程示意图；
图6为本申请实施例的CU决定针对RLC失败进行处理的第三流程示意图；
图7为本申请实施例的另一种处理RLC失败的方法的流程示意图；
图8为本申请实施例的DU决定针对RLC失败进行处理的第一流程示意图；
图9为本申请实施例的DU决定针对RLC失败进行处理的第二流程示意图；
图10为本申请实施例的DU决定针对RLC失败进行处理的第三流程示意图；
图11为本申请实施例的基站间交互RLC失败相关信息的过程示意图；
图12为可用于实现本申请实施例公开的用于执行处理RLC失败的方法的计算系统的框图。
具体实施方式
下面详细描述本申请的实施例，实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，仅用于解释本申请，而不能解释为对本申请的限制。
本技术领域技术人员可以理解，除非特意声明，这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是，本申请的说明书中使用的措辞“包括”是指存在所述特征、整数、步骤、操作、元件和/或组件，但是并不排除存在或添加一个或多个其他特征、整数、步骤、操作、元件、组件和/或它们的组。应该理解，当我们称元件被“连接”或“耦接”到另一元件时，它可以直接连接或耦接到其他元件，或者也可以存在中间元件。此外，这里使用的“连接”或“耦接”可以包括无线连接或无线耦接。这里使用的措辞“和/或”包括一个或更多个相关联的列出项的全部或任一单元和全部组合。
为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请实施方式作进一步地详细描述。
在5G系统中，为了支持网络功能的虚拟化，定义了CU-DU分离的基站结构。即一个基站(比如gNB，eNB)可以进一步分成集中单元gNB-CU(gNB central unit)和分布单元gNB-DU(gNB distributed unit)，集中单元gNB-CU和分布单元gNB-DU可分别简称为CU和DU。CU(central unit，集中单元)具有无线资源控制(RRC)，服务数据自适应协议(SDAP，ServiceData Adaptation Protocol)和分组数据汇聚协议(PDCP)协议层等。DU(distributedunit，分布单元)具有无线链路控制协议(RLC)、介质访问控制(MAC)和物理层等。其中，CU和DU之间是标准化的公开接口F1，F1接口分控制平面F1-C和用户平面F1-U，图2示出了CU和DU的结构。因此，在CU-DU分离的情况下，考虑到RLC失败信息是通过RRC信令发送，用户发送的该信息最终会通过DU发送给CU。
另外，在现有技术中，RLC失败信息是发送给CU，但是根据目前的协议(TS38.473)，CU所获得的信息还不足以帮助CU获得与RLC失败有关的其他信息(比如哪个RLC实体发生了失败，发生失败的RLC实体相关联的SCell是哪些等)，而这些其他信息只有DU能够知道。因此，为了帮助网络侧解决UE的RLC失败的问题，需要CU和DU间交互更多的信息。
此外，虽然网络侧能够根据UE上报的RLC失败相关信息对RLC失败进行处理，但是处理过程繁琐、效率低下，不利于正确且快速的解决RLC失败，极大降低了用户体验。
本申请提供的处理RLC失败的方法、电子设备和计算机可读存储介质，旨在解决现有技术的如上技术问题。
下面以具体地实施例对本申请的技术方案以及本申请的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图，对本申请的实施例进行描述。
本发明中提及的地址信息(如CU侧的地址信息，DU侧的地址信息，基站侧的地址信息)可以参见TS38.473中相关的定义(如UP Transport Layer Information)或TS36.423中相关的定义(如GTP Tunnel Endpoint)或TS38.423中的相关定义(如UP Transport LayerInformation)。
本发明中提及的处理RLC失败的行为只是示例，其他能够解决RLC失败的行为均适用。
实施例一
本申请实施例提供了一种处理RLC失败的方法，应用于网络设备，如图3所示，包括：
步骤S310，第一网络设备接收用户设备UE的RLC失败相关信息。
具体地，当UE的一个逻辑信道所对应的小区都是SCell，且该逻辑信道对应的RLC实体发生了失败(重传次数达到或超过最大重传次数)时，UE向网络设备上报RLC失败相关信息，即第一网络设备接收用户设备UE发送的RLC失败相关信息，以便后续基于该RLC失败相关信息进行RLC失败处理。
进一步地，该一个逻辑信道可以是针对配置了基于CA的duplication机制的UE的一个逻辑信道。
步骤S320，基于接收到的RLC失败相关信息，通过与第二网络设备进行交互，来对RLC失败进行相应处理。
具体地，当第一网络设备接收到备UE发送的RLC失败相关信息时，基于该接收到的RLC失败相关信息，通过与第二网络设备进行交互，来决定对该RLC失败的处理，即基于接收到的RLC失败相关信息，通过与第二网络设备进行交互，来对RLC失败进行相应处理。
进一步地，本申请中的消息名称只是示例，也可以根据需要采用其他名称。
本申请实施例提供的处理RLC失败的方法，与现有技术相比，第一网络设备接收用户设备UE的RLC失败相关信息，为后续网络设备对RLC失败进行相应处理提供前提保障；基于接收到的RLC失败相关信息，通过与第二网络设备进行交互，来对RLC失败进行相应处理，使得第一网络设备能够直接与第二网络设备进行交互，从而能够直接根据接收到的UE上报的RLC失败相关信息以及交互信息，决定对该RLC失败的处理，从而简化RLC处理的流程，提高处理效率，便于RLC失败的正确且快速的解决，提升用户体验。
实施例二
本申请实施例提供了另一种可能的实现方式，在实施例一的基础上，还包括实施例二所示的方法，其中，
第一网络设备为集中单元CU，第二网络设备为分布单元DU；或者，所述第一网络设备为第一基站，第二网络设备为第二基站。
步骤S320具体包括步骤S3201(图中未标注)与步骤S3202(图中未标注)，其中，
步骤S3201：向第二网络设备发送第一请求消息。
步骤S3202：接收第二网络设备针对所述第一请求消息返回的第一响应消息。
具体地，第一请求消息包括以下至少一项：
RLC失败相关信息；
指示网络设备处理RLC失败的行为的指示信息；
针对发生RLC失败的RLC实体，需去掉或去激活的小区的信息；
第一网络设备向第二网络设备发送第一请求消息的原因信息；
指示网络设备处理RLC失败的行为的指示信息，包括指示以下至少一种行为：重建发生RLC失败的RLC实体；释放小区；不将一个或多个小区配置为与发生RLC失败的RLC实体对应的小区；去激活载波聚合的数据包重复机制CA duplication；切换频带部分BWP；重配置发生RLC失败的RLC实体对应的DRB/SRB；同小区切换。
进一步地，本申请实施例主要是针对第一网络设备CU(下述简称CU)接收到RLC失败信息后，通过与第二网络设备DU(下述简称DU)间交互相关信息来完成对RLC失败的处理，具体处理过程如图4所示，在图4中包括步骤3a-0、步骤3a-1与步骤3a-2。具体请见下述实施3a：
实施例3a：(CU决定针对RLC失败的处理：收到UE发送的RLC失败有关信息后，CU进行处理)
步骤3a-1：通过CU向DU发送第一请求消息；
具体地，第一请求消息(如用户上下文修改请求消息，UE Context ModificationRequest消息)，该消息的内容可以参见TS38.473，还可以进一步包括以下至少一项：
■RLC失败相关信息，可以至少为如下信息之一：
■发生RLC失败的RLC实体对应的逻辑信道的信息(如逻辑信道标识信息)，进一步，与该RLC实体相关联的小区都是SCell；
■发生RLC失败的RLC实体对应的一个或多个小区的标识信息，进一步，与该RLC实体相关联的小区都是SCell，所以该一个或多个小区都是SCell；
■发生RLC失败的RLC实体所对应的DRB/SRB的信息(如标识信息)，进一步，与该RLC实体相关联的小区都是SCell；
■发生RLC失败的用户标识信息，其中，发生RLC失败的RLC实体相关联的小区都是SCell；
■发生RLC失败的RLC实体所对应的小区组的信息，如MCG，SCG等，进一步，与该RLC实体相关联的小区都是SCell；
■指示网络侧(如DU，CU，或CU与DU)处理RLC失败的行为的指示信息，该指示信息可以是针对至少一个DRB和/或SRB，也可以针对用户，该指示信息可以是显示的，也可以是隐式的，该信息可以用来指示至少如下行为之一：
■重建发生RLC失败的RLC实体，还可以进一步的包括需要重建的RLC实体对应的逻辑信道信息，如逻辑信道标识；
■释放小区(如SCell)，在包含指示该行为的指示信息时，还可以进一步包括需要释放的一个或多个小区的标识信息(小区的NR CGI(Cell Interconnection Gateway，小区互联网关)，或PCI(Physical Cell Identifier，物理小区标识)，或索引Index)；
■不将一个或多个小区(如SCell)配置为与发生RLC失败的RLC实体对应的小区，在包含指示该行为的指示信息时，还可以进一步包括小区的标识信息；
■去激活CA duplication；
■切换BWP(bandwidth part，频带部分)；
■重配发生RLC失败的RLC实体对应的DRB/SRB；
■同小区切换(intra-cell handover)；
■针对发生RLC失败的RLC实体，需要去掉(或去激活)的小区(如SCell)的信息，如标识信息(NR CGI，或PCI，或Index)，这里的“去掉”表明该信息所指示的小区不再为该RLC实体服务；
■CU向DU发送消息1-1的原因信息，原因信息的具体内容可参考本申请下述实施例九。
步骤3a-2：通过CU接收DU针对第一请求消息返回的第一响应消息(如用户上下文修改响应消息，UE Context Modification Response消息)，该消息的内容可以参见TS38.473。
进一步地，在通过CU向DU发送第一请求消息之前，还包括步骤3a-0：
通过CU接收UE的RLC失败相关信息，具体地，该RLC失败相关信息包括以下至少一项：
■发生RLC失败的UE标识信息；
■发生RLC失败的RLC实体对应的逻辑信道的信息；
■发生RLC失败RLC实体对应的小区组的信息；
■发生RLC失败的RLC实体对应的一个或多个小区的标识信息；
■发生RLC失败的RLC实体对应的DRB/SRB的信息。
进一步地，在通过CU向DU发送第一请求消息之后，DU侧的行为还包括至少如下行为之一：
■重建发生RLC失败的逻辑信道对应的RLC实体；
■释放与发生RLC失败的逻辑信道对应的小区；
■将与发生RLC失败的逻辑信道对应的小区中的一个或多个或全部去掉(或去激活)，以使这些小区不再为该RLC实体服务；
■去激活发生RLC失败的逻辑信道对应的DRB/SRB的CA duplication；
■切换服务发生RLC失败的逻辑信道对应的DRB/SRB的BWP；
■重配发生RLC失败的RLC实体对应的DRB/SRB；
■同小区切换(intra-cell handover)。
上述DU侧的行为可以发生在步骤3a-2之前，也可以发生在步骤3a-2之后，也可以和步骤3a-2同时发生。
进一步地，在一个实施方式中，在步骤3a-1之前，CU已经获取了一些关于配置了CAduplication的DRB/SRB的相关的信息，如与一个RLC实体对应的逻辑信道的信息，利用该信息以及收到的来自UE的与RLC失败有关的信息来决定对RLC失败的处理。
实施例三
本申请实施例提供了另一种可能的实现方式，在实施例一的基础上，还包括实施例三所示的方法，其中，
第一网络设备为集中单元CU，第二网络设备为分布单元DU；或者，所述第一网络设备为第一基站，第二网络设备为第二基站。
还包括步骤S3001(图中未标注)与步骤S3002(图中未标注)，其中，
步骤S3001：第一网络设备向第二网络设备发送第五请求消息。
步骤S3002：接收第二网络设备反馈的第五响应消息。
具体地，第五请求消息包括以下至少一项：
UE的标识信息；
针对一个DRB或SRB，用于指示配置CA duplication的指示信息；
指示上报为支持CA duplication所配置的至少一个路径对应的逻辑信道信息的指示信息；
指示上报为支持CA duplication所配置的至少一个路径对应的小区标识的指示信息；
针对一个DRB或SRB，用于指示配置CA duplication的指示信息，通过包含两个第一网络设备的地址信息来指示或者通过重复指示Duplication indication来指示；
第五响应消息包括以下至少一项：
UE的标识信息；
第二网络设备生成的关于UE的配置信息；
两个第二网络设备的地址信息，所述两个第二网络设备的地址信息是针对配置了CA duplication的一个DRB的；
为支持CA duplication所配置的至少一个路径对应的逻辑信道信息；
为支持CA duplication所配置的至少一个路径对应的一个或多个小区标识。
进一步地，本申请实施例主要是针对第一网络设备CU(下述简称CU)接收到RLC失败信息后，通过与第二网络设备DU(下述简称DU)间交互相关信息来完成对RLC失败的处理，具体处理过程如图5所示，在图5中包括步骤3a-a、步骤3a-b、步骤3a-0、步骤3a-1与步骤3a-2。具体请见下述实施3b：
实施例3b：(CU决定针对RLC失败的处理：在获取CAduplication信息后，收到UE发送的RLC失败有关信息，然后CU进行处理)
步骤3a-0～3a-2，可以参见实施例3a中的描述。
此外，进一步，可选的，在步骤3a-0之前还可以包括：
步骤3a-a：CU向DU发送消息3a-a(如用户上下文建立/修改请求消息)，该消息至少包含如下信息之一(可以参见TS38.473的UE context setup/modification request消息)：
■用户的标识信息，如gNB-DU/gNB-CU UE F1AP ID；
■针对一个DRB或SRB，用于指示配置CA duplication的指示信息，该信息可以是一个隐式的指示信息，也可以是一个显示的指示信息，可能为如下形式之一：
■用包含两个CU侧的地址信息来指示；
■用Duplication indication(重复指示)来指示；
除了上述信息外，可选的，针对一个DRB或SRB(一个实施例中，该DRB或SRB需要或已经配置了CA duplication)还可以至少包括如下信息之一：
■指示上报为支持CA duplication所配置的至少一个路径path(如primary path和/或secondary path)对应的逻辑信道信息的指示信息，进一步的，还可以限制，如果上述至少一个路径path对应的一个或多个小区都是Secondary cell(SCell)，DU才上报逻辑信道信息的指示信息；
■指示上报为支持CA duplication所配置的至少一个路径path(如primary path和/或secondary path)对应的小区标识的指示信息，进一步的，还可以限制，如果上述至少一个路径path所对应的一个或多个小区都是Secondary cell(SCell)，DU才上报小区标识信息的指示信息；
步骤3a-b：DU向CU发送消息3a-b(如用户上下文建立/修改响应消息)，该消息至少包括如下信息之一(可以参见TS38.473的UE context setup/modification response消息)：
■用户的标识信息，如gNB-DU/gNB-CU UEF1AP ID；
■DU侧生成的关于用户的配置信息(如TS38.473“DU to CU RRC Information”IE)；
■针对一个DRB，如果配置了CA duplication，包含两个DU侧的地址信息；
除了上述信息外，可选的，针对一个DRB或SRB(一个实施例，该DRB或SRB需要或已经配置CA duplication)还可以至少包括如下信息之一：
■为支持CA duplication所配置的至少一个路径path(如primary path和/或secondary path)对应的逻辑信道信息(如逻辑信道标识)，进一步，如果上述至少一个path对应的逻辑信道所对应的小区只有SCell时，DU才包含上述至少一个path对应的逻辑信道信息(如逻辑信道标识)；进一步，如果上述为支持CA duplication配置了两个path，DU会包含与该两个path对应的逻辑信道的信息(如逻辑信道标识)；进一步的，如果上述为支持CAduplication配置了两个path，且两个path对应的逻辑信道所对应的小区只有SCell时，DU才会包含与该两个path对应的逻辑信道的信息(如逻辑信道标识)。
■为支持CA duplication所配置的至少一个路径path(如primary path和/或secondary path)对应的一个或多个小区标识，进一步，如果上述至少一个path对应的小区只有SCell时，DU才包含上述至少一个路径path对应的一个或多个SCell的标识信息。进一步，如果上述为支持CA duplication配置了两个path，DU会包含与该两个path对应的一个或多个小区的标识信息；进一步的，如果上述为支持CA duplication配置了两个path，且两个path对应的的小区只有SCell时，DU才会包含与该两个path对应的一个或多个小区的标识信息。
进一步的，该实施例的步骤3a-a和步骤3a-b可以作为一个获取CA duplication配置信息的流程来在CU和DU间进行CA duplication的配置和相关信息的获取，即这两个步骤的流程可以单独使用，无需再包括步骤3a-0～3a-2。
实施例四
本申请实施例提供了另一种可能的实现方式，在实施例一的基础上，还包括实施例四所示的方法，其中，
第一网络设备为集中单元CU，第二网络设备为分布单元DU；或者，所述第一网络设备为第一基站，第二网络设备为第二基站。
还包括步骤S3101(图中未标注)与步骤S3102(图中未标注)，其中，
步骤S3101：第一网络设备向第二网络设备发送包括RLC失败相关信息的消息。
步骤S3102：接收第二网络设备反馈的包含与发生RLC失败的RLC实体有关的信息。
具体地，与发生RLC失败的RLC实体有关的信息，包括以下至少一项：
发生RLC失败的RLC实体对应的逻辑信道的信息；
发生RLC失败的RLC实体对应的一个或多个小区的标识信息；
发生RLC失败的RLC实体所对应的DRB/SRB的信息。
进一步地，本申请实施例主要是针对第一网络设备CU(下述简称CU)接收到RLC失败信息后，通过与第二网络设备DU(下述简称DU)间交互相关信息来完成对RLC失败的处理，具体处理过程如图6所示，在图6中包括步骤3a-0、步骤3a-c、步骤3a-d、步骤3a-1与步骤3a-2。具体请见下述实施3c：
实施例3c：(CU决定针对RLC失败的处理：收到UE发送的RLC失败有关信息后，CU获取与发生RLC失败的RLC实体的有关信息，然后CU进行处理)
在实施例3a的步骤3a-0之后，步骤3a-1之前，可选的，还可以包括：
步骤3a-c：CU向DU发送包含RLC失败相关信息的消息3a-c，该消息至少包含如下信息之一：
■发生RLC失败的RLC实体对应的逻辑信道的信息(如逻辑信道标识信息)，进一步，与该RLC实体相关联的小区都是SCell；
■发生RLC失败的RLC实体对应的一个或多个小区的标识信息，进一步，与该RLC实体相关联的小区都是SCell，所以该一个或多个小区都是SCell；
■发生RLC失败的RLC实体所对应的DRB/SRB的信息(如标识信息)，进一步，与该RLC实体相关联的小区都是SCell；
■发生RLC失败的用户标识信息，如gNB-DU/CU UE F1AP ID，其中，发生RLC失败的RLC实体相关联的小区都是SCell；
■发生RLC失败的RLC实体所对应的小区组的信息，如MCG，SCG等，进一步，与该RLC实体相关联的小区都是SCell；
步骤3a-d：DU根据接收的消息3a-c向CU反馈消息3a-d，该消息包含与发生RLC失败的RLC实体有关的信息，至少包含如下信息之一：
■发生RLC失败的RLC实体对应的逻辑信道的信息(如逻辑信道标识信息)，其中，与该RLC实体相关联的小区都是SCell；
■发生RLC失败的RLC实体对应的一个或多个小区的标识信息，进一步，与该RLC实体相关联的小区都是SCell，所以该一个或多个小区都是SCell；
■发生RLC失败的RLC实体所对应的DRB/SRB的信息(如标识信息)，其中，与该RLC实体相关联的小区都是SCell；
进一步的，该实施例的步骤3a-c和步骤3a-d可以作为一个获取与发生RLC失败的RLC实体有关的信息的流程来在CU和DU间进行，或者在第一基站和第二基站间进行，即这两个步骤的流程可以单独使用，无需再包括步骤3a-0～3a-2。
实施例五
本申请实施例提供了另一种可能的实现方式，在实施例四的基础上，还包括实施例五所示的方法，其中，
第一网络设备为集中单元CU，第二网络设备为分布单元DU；或者，所述第一网络设备为第一基站，第二网络设备为第二基站。
还包括步骤S330(图中未标注)：通过预定义的与无线链路失败有关的原因信息，来对RLC失败进行相应处理。
预定义的与无线链路失败有关的原因信息，包括以下至少一项：
主小区无线链路失败；
下行链路无线链路失败；
上行链路无线链路失败；
辅小区无线链路失败；
下行链路辅小区无线链路失败；
上行链路辅小区无线链路失败。
进一步地，本申请实施例主要是定义了与无线链路失败有关的原因信息，其中，可以定义如下原因信息：
■主小区主小区无线链路失败RL failure(或SCG failure或MCG failure)：这个原因信息表明超过了RLC实体的ARQ的最大重传次数，或者物理链路的问题或错误；进一步的，该原因信息还可以指示与该RLC实体相关的小区至少包括PCell或PSCell或SpCell(SpCell是PCell与PSCell的统称)，与该物理链路相关联的小区至少包括PCell或PSCell或SpCell(SpCell是PCell与PSCell的统称)；
■下行链路无线链路失败DL RL failure(或者称作DL SCG failure或DL MCGfailure)：这个原因信息表明超过了RLC实体(如基站侧的RLC实体)的ARQ的最大重传次数，或者下行的物理链路的问题或错误；进一步的，该原因信息还可以指示与该RLC实体相关联的小区至少包括PCell或PSCell或SpCell(SpCell是PCell与PSCell的统称)，与该物理链路相关联的小区至少包括PCell或PSCell或SpCell(SpCell是PCell与PSCell的统称)；
■上行链路无线链路失败UL RL failure：这个原因信息表明发生失败的原因是超过了RLC实体(如用户侧的RLC实体)的ARQ的最大重传次数，或者上行的物理链路的问题或错误；进一步的，该原因信息还可以指示与该RLC实体相关联的小区至少包括PCell或PSCell或SpCell(SpCell是PCell与PSCell的统称)，与该物理链路相关联的小区至少包括PCell或PSCell或SpCell(SpCell是PCell与PSCell的统称)；
■辅小区无线链路失败SCell RL failure(或者称作SCell Failure)：这个原因信息表明超过了RLC实体的ARQ的最大重传次数，或者物理链路的问题或错误；与该RLC实体相关联的小区都是SCell，与该物理链路相关联的都是SCell；
■下行辅小区无线链路失败DL SCell RL failure(或者称作DL SCellFailure)：这个原因信息表明超过了RLC实体(如基站侧的RLC实体)的ARQ的最大重传次数，或者下行的物理链路的问题或错误；与该RLC实体相关联的小区都是SCell，与该物理链路相关联的都是SCell；
■上行辅小区无线链路失败UL SCell RL failure(或者称作UL SCellFailure)：这个原因信息表明超过了RLC实体(如用户侧的RLC实体)的ARQ最大重传次数，或者上行的物理链路的问题或错误；与该RLC实体相关联的小区都是SCell，与该物理链路相关联的都是SCell。
上述原因信息可以是CU发送给DU，也可以是DU发送给CU，进一步，CU可以选择上述原因信息之一发送给DU，DU可以选择上述原因信息之一发送给CU。
进一步地，上述原因信息可以是针对一个DRB/SRB(如在提供该原因信息时，要指示该原因信息所针对的DRB/SRB的信息，如DRB/SRB标识信息)，也可以是针对一个小区(如在提供该原因信息时，要指示该原因信息所针对的小区的信息，如小区标识信息)。
进一步地，上述原因消息可以是针对CU发送给DU的一条消息，用来表明CU发送该消息的原因，或是DU发送给CU的一条消息，用来表明DU发送该消息的原因。
进一步地，上述原因信息可以在两个基站间交互，可以是针对一个DRB/SRB，也可以是针对一个小区，也可以用来表明基站发送消息的原因。
进一步地，上述原因信息的名称只是示例，还可以为其他的名称。
进一步地，基于上述原因信息，CU或DU或基站在接收到一条消息后，可以理解该消息发送的原因。进一步地，收到上述原因信息后，CU或DU或基站可以决定接下来的行为，如重建RLC实体，释放或移除小区，或进行同小区的切换，或者进行不同小区的切换等。
进一步地，上述原因信息不仅限于被用到对RLC失败进行处理，也可以用于其他适用的情况。
进一步地，上述原因信息不仅适用CU决定对RLC失败的处理的情况，也适用于DU决定对RLC失败的处理的情况。
进一步地，上述交互原因信息的过程可以是一个独立的过程。
实施例六：(DU决定对RLC失败的处理)
本申请实施例提供了一种处理RLC失败的方法，应用于网络设备，如图7所示，包括：
步骤S710，第二网络设备接收第一网络设备发送的包括来自UE的RLC失败相关信息的第二请求消息。
步骤S720，基于接收到的第二请求消息，来对RLC失败进行相应处理。
本申请实施例提供的方法，与现有技术相比，第二网络设备接收第一网络设备发送的包括来自UE的RLC失败相关信息的第二请求消息，为后续网络设备对RLC失败进行相应处理提供前提保障；基于接收到的第二请求消息，来对RLC失败进行相应处理，使得第二网络设备能够通过与第一网络设备进行交互，从而能够获取到RLC失败相关信息，进而基于接收到的RLC失败相关信息以及交互得到的交互信息，决定对该RLC失败的处理，从而简化RLC处理的流程，提高处理效率，便于RLC失败的正确且快速的解决，提升用户体验。
实施例七：(DU决定对RLC失败的处理)
本申请实施例提供了另一种可能的实现方式，在实施例六的基础上，还包括实施例七所示的方法，其中，
第一网络设备为集中单元CU，第二网络设备为分布单元DU；或者，所述第一网络设备为第一基站，第二网络设备为第二基站。
第二请求消息包括以下至少一项：
RLC失败相关信息；
指示网络设备处理RLC失败的行为的指示信息；
需释放或需移除的小区的信息；
针对发生RLC失败的RLC实体，需去掉或去激活的小区的信息；
需修改的数据无线承载DRB/信令无线承载SRB的信息；
第一网络设备向第二网络设备发送第一请求消息的原因信息；
所述处理RLC失败的行为包括以下至少一种：重建发生RLC失败的RLC实体；释放小区；不将一个或多个小区配置为与发生RLC失败的RLC实体对应的小区；去激活载波聚合的数据包重复机制CA duplication；切换频带部分BWP；重配置发生RLC失败的RLC实体对应的DRB/SRB；同小区切换。
步骤S720具体包括步骤S7201(图中未标注)：基于接收到的第二请求消息，向第一网络设备发送第二响应信息。
具体地，第二响应消息包括以下至少一项：
第二网络设备生成的关于UE的配置信息；
与被修改的DRB/SRB有关的信息；
与被释放或被移除的小区有关的信息；
与发生RLC失败的RLC实体有关的信息；
第二网络设备生成的关于UE的配置信息包括以下至少一项：逻辑信道标识信息；重建RLC实体的指示信息；被释放的小区的标识信息；
与被修改的DRB/SRB有关的信息包括以下至少一项：被修改的DRB/SRB的标识信息；被修改的DRB/SRB的至少一个逻辑信道的信息；被修改的DRB/SRB的至少一个逻辑信道对应的小区的标识信息；与被修改的DRB对应的一个第二网络设备侧的地址信息；
与被释放或被移除的小区有关的信息包括以下至少一项：小区的标识信息；小区服务的DRB/SRB的有关信息；小区对应的逻辑信道的信息；
与发生RLC失败的RLC实体有关的信息包括以下至少一项：发生RLC失败的RLC实体对应的逻辑信道的信息；发生RLC失败的RLC实体对应的一个或多个小区的标识信息；发生RLC失败的RLC实体所对应的DRB/SRB的信息。
进一步地，在步骤S7201之后还包括步骤S7202(图中未标注)：第二网络设备进行如下行为中的至少一项：重建发生RLC失败的逻辑信道对应的RLC实体；释放与发生RLC失败的逻辑信道对应的小区；将与发生RLC失败的逻辑信道对应的小区中的至少一个去掉或去激活；去激活发生RLC失败的逻辑信道对应的DRB/SRB的CA duplication；切换服务发生RLC失败的逻辑信道对应的DRB/SRB的BWP；重配置发生RLC失败的RLC实体对应的DRB/SRB；同小区切换。
进一步地，本申请实施例主要是针对收到RLC失败信息后，DU来完成对RLC失败的处理，具体处理过程如图8所示，在图8中包括步骤1-1与步骤1-2，其中，
步骤1-1：CU向DU发送消息1-1(如用户上下文修改请求消息，UE ContextModification Request消息)，该消息的内容可以参见TS38.473，此外，该消息还可以至少包含如下信息之一：
■RLC失败相关信息，可以至少为如下信息之一：
■发生RLC失败的RLC实体对应的逻辑信道的信息(如逻辑信道标识信息)，进一步，与该RLC实体相关联的小区都是SCell；
■发生RLC失败的RLC实体对应的一个或多个小区的标识信息，进一步，与该RLC实体相关联的小区都是SCell，所以该一个或多个小区都是SCell；
■发生RLC失败的RLC实体所对应的DRB/SRB的信息(如标识信息)，进一步，与该RLC实体相关联的小区都是SCell；
■发生RLC失败的用户标识信息，其中，发生RLC失败的RLC实体相关联的小区都是SCell；
■发生RLC失败的RLC实体所对应的小区组的信息，如MCG，SCG等，进一步，与该RLC实体相关联的小区都是SCell；
■指示网络侧(如DU，CU，或CU与DU)处理RLC失败的行为的指示信息，该指示信息可以是针对至少一个DRB和/或SRB，也可以针对用户，该指示信息可以是显示的，也可以是隐式的，该信息可以用来指示至少如下行为之一：
■重建发生RLC失败的RLC实体，还可以进一步的包括需要重建的RLC实体对应的逻辑信道信息，如逻辑信道标识；
■释放小区(如SCell)，在包含指示该行为的指示信息时，还可以进一步包括需要释放的一个或多个小区的标识信息(小区的NR CGI(Cell Interconnection Gateway，小区互联网关)，或PCI(Physical Cell Identifier，物理小区标识)，或索引Index)；
■不将一个或多个小区(如SCell)配置为与发生RLC失败的RLC实体对应的小区，在包含指示该行为的指示信息时，还可以进一步包括小区的标识信息；
■去激活CA duplication；
■切换BWP(bandwidth part，频带部分)；
■重配发生RLC失败的RLC实体对应的DRB/SRB；
■同小区切换(intra-cell handover)；
■需释放或移除的小区(如SCell)的信息，如标识信息(NR CGI，或PCI，或Index)，一个实施例是，该小区只能是SCell；
■针对发生RLC失败的RLC实体，需要去掉(或去激活)的小区(如SCell)的信息，如标识信息(NR CGI，或PCI，或Index)，这里的“去掉”表明该信息所指示的小区不再为该RLC实体服务；
■需要修改的DRB/SRB的信息，如DRB/SRB的标识信息；
■CU向DU发送消息1-1的原因信息，原因信息的具体内容可参考本申请下述实施例九。
步骤1-2：DU向CU发送消息1-2(如用户上下文修改响应消息，UE ContextModification Response消息)，该消息的内容可以参见TS38.473，此外，该消息还可以至少包含如下信息之一：
■DU侧(即本申请实施例中的DU)生成的关于用户的配置信息(如TS38.473“DU toCU RRC Information”IE)，该信息可以包含至少如下信息之一：
■逻辑信道标识信息；
■重建RLC实体的指示信息；
■被释放的小区的标识信息；
■与被修改的DRB/SRB有关的信息，该信息表示DU已经完成了对该信息指示的DRB/SRB的修改，进一步的，该被修改的DRB/SRB与发生RLC失败的RLC实体对应，该信息至少包含如下信息之一：
■被修改的DRB/SRB的标识信息；
■被修改的DRB/SRB的至少一个逻辑信道的信息(如逻辑信道标识信息)；
■被修改的DRB/SRB的至少一个逻辑信道对应的小区的标识信息，该信息所指示的小区不再为该DRB/SRB服务；
■与被修改的DRB对应的一个DU侧的地址信息(如DL UP TNL information)。现有技术中，步骤1-1的消息1-1中提供的该被修改的DRB的CU侧地址信息的个数应该与步骤1-2的消息1-2中提供的DU侧的地址信息个数相同。但是在本发明中，允许步骤1-1的消息1-1中提供的该被修改的DRB的CU侧地址信息的个数应该与步骤1-2的消息1-2中提供的DU侧的地址信息个数不同。一种实施方式是，在步骤1-1的消息1-1中，CU向DU提供与该DRB对应的两个CU侧的地址信息，根据现有技术，在步骤1-2的消息1-2中，DU需要向CU提供与该DRB对应的两个DU侧的地址信息，但在本方案中，DU只向CU提供与该DRB对应的一个DU侧的地址信息，CU收到该消息1-2后，CU可以选择消息1-1中所包含的两个CU侧的地址信息之一来作为服务该DRB的CU侧的地址信息。另一个实施方式是，在步骤1-1的消息1-1中，CU未向DU提供与该DRB的CU侧的地址信息，但是当前时刻，CU侧已经利用两个地址在为该DRB服务，DU侧已经利用两个地址在为该DRB服务，根据现有技术，DU不会在消息1-2中包含DU侧的地址信息，但在本方案中，允许包含一个DU侧的地址信息。
在现有技术中，包含上述“与被修改的DRB/SRB有关的信息”的前提条件是，在步骤1-1的消息1-1中包含了“需修改的DRB/SRB有关的信息”。具体的说，如果步骤1-1的消息1-1中包含“DRB to Be Modified List”IE(Information Element，信息元素)，该IE指示了需要修改的DRB的信息，那么步骤1-2的消息1-2中会包含“DRB Modified List”IE，该IE表示了被成功修改的DRB，这些DRB是从步骤1-1的消息1-1中“DRB to Be Modified List”IE所指示的DRB中选择的。但是在本方案中，针对一个DRB/SRB，允许在步骤1-1的消息1-1中没有包含与该DRB/SRB对应的“需修改的DRB/SRB有关的信息”时，DU也可以在步骤1-2的消息1-2中包含与该DRB/SRB对应的上述“与被修改的DRB/SRB有关的信息”，进一步，如果在步骤1-1的消息1-1中包含了“RLC失败相关信息”时，即使步骤1-1的消息中没有包含针对某个DRB/SRB的“需修改的DRB/SRB有关的信息”，DU也可以在步骤1-2的消息1-2中包含与该DRB/SRB对应的上述“与被修改的DRB/SRB有关的信息”。
■与被释放或被移除的小区(如SCell)有关的信息，该信息至少包括如下内容之一：
■小区的标识信息；
■该小区所服务的DRB/SRB有关的信息，如标识信息；
■该小区所对应的逻辑信道的信息，如逻辑信道标识信息，进一步的，该逻辑信道对应的RLC实体发生了失败，即该逻辑信道包含在了步骤1-1的消息1-1中的“RLC失败相关信息”内；
进一步地，如果在步骤1-1的消息1-1中包含了“RLC失败相关信息”时，允许步骤1-2的消息1-2中包含“与被释放或被移除的小区(如SCell)有关的信息”，而这些被释放的小区与发生RLC失败的RLC实体对应。与发生RLC失败的RLC实体有关的信息，该信息至少包括如下信息之一：
■与发生RLC失败的RLC实体有关的信息，该信息至少包括如下信息之一：
■发生RLC失败的RLC实体对应的逻辑信道的信息(如逻辑信道标识信息)，其中，与该RLC实体相关联的小区都是SCell；
■发生RLC失败的RLC实体对应的一个或多个小区的标识信息，进一步，与该RLC实体相关联的小区都是SCell，所以该一个或多个小区都是SCell；
■发生RLC失败的RLC实体所对应的DRB/SRB的信息(如标识信息)，其中，与该RLC实体相关联的小区都是SCell；
进一步地，CU收到上述与发生RLC失败的RLC实体有关的信息后来进一步进行对RLC失败的处理。
进一步地，如果在步骤1-1的消息1-1中包含了“RLC失败相关信息”时，允许步骤1-2的消息1-2中包含“与被释放或被移除的小区(如SCell)有关的信息”，而这些被释放的小区与发生RLC失败的RLC实体对应。
进一步地，在步骤1-1之前，还包括CU接收到用户的RLC失败相关信息，该信息可以是用户通过DU发送给CU的，也可以是其他基站或基站的CU发送给该CU的。
进一步地，DU侧的行为还包括至少如下行为之一：
■重建发生RLC失败的逻辑信道对应的RLC实体；
■释放与发生RLC失败的逻辑信道对应的小区；
■将与发生RLC失败的逻辑信道对应的小区中的一个或多个或全部去掉(或去激活)，以使这些小区不再为该RLC实体服务；
■去激活发生RLC失败的逻辑信道对应的DRB/SRB的CA duplication；
■切换服务发生RLC失败的逻辑信道对应的DRB/SRB的BWP；
■重配发生RLC失败的RLC实体对应的DRB/SRB；
■同小区切换(intra-cell handover)。
上述DU侧的行为可以发生在步骤1-2之前，也可以发生在步骤1-2之后，也可以和步骤1-2同时发生。
实施例八：(DU决定对RLC失败的处理)
本申请实施例提供了另一种可能的实现方式，在实施例六的基础上，还包括实施例八所示的方法，其中，
第一网络设备为集中单元CU，第二网络设备为分布单元DU；或者，所述第一网络设备为第一基站，第二网络设备为第二基站。
步骤S720包括步骤S7201(图中未标注)与步骤S7202(图中未标注)，其中，
步骤S7201：向第一网络设备发送包括RLC失败相关信息的第三请求消息。
步骤S7202：接收第一网络设备针对所述第三请求消息返回的第三响应消息。
具体地，第三请求消息包括以下至少一项：
第二网络设备生成的关于UE的配置信息；
与需修改的DRB/SRB有关的信息；
与需释放或被移除的小区有关的信息；
指示网络设备处理RLC失败的行为的指示信息；
第二网络设备向第一网络设备发送第二请求消息的原因信息；
与发生RLC失败的RLC实体有关的信息；
第二网络设备生成的关于UE的配置信息包括以下至少一项：逻辑信道标识信息；重建RLC实体的指示信息；被释放的小区的标识信息；
与需修改的DRB/SRB有关的信息包括以下至少一项：被修改的DRB/SRB的标识信息；被修改的DRB/SRB的至少一个逻辑信道的信息；被修改的DRB/SRB的至少一个逻辑信道对应的小区的标识信息；与被修改的DRB对应的一个第二网络设备侧的地址信息；
与需释放或需移除的小区有关的信息包括以下至少一项：小区的标识信息；小区服务的DRB/SRB的信息；小区对应的逻辑信道的信息；
处理RLC失败的行为包括以下至少一种：重建发生RLC失败的RLC实体；释放小区；不将一个或多个小区配置为与发生RLC失败的RLC实体对应的小区；去激活CAduplication；切换BWP；重配置发生RLC失败的RLC实体对应的DRB/SRB；同小区切换；
与发生RLC失败的RLC实体有关的信息包括以下至少一项：发生RLC失败的RLC实体对应的逻辑信道的信息；发生RLC失败的RLC实体对应的一个或多个小区的标识信息；发生RLC失败的RLC实体所对应的DRB/SRB的信息。
进一步地，RLC失败相关信息包括以下至少一项：
发生RLC失败的UE标识信息；
发生RLC失败的RLC实体对应的逻辑信道的信息；
发生RLC失败RLC实体对应的小区组的信息；
发生RLC失败的RLC实体对应的一个或多个小区的标识信息；
发生RLC失败的RLC实体对应的DRB/SRB的信息。
进一步地，与发生RLC失败的RLC实体有关的信息包括以下至少一项：发生RLC失败的RLC实体对应的逻辑信道的信息，进一步的，与该RLC实体相关联的小区都是SCell；发生RLC失败的RLC实体对应的一个或多个小区的标识信息，进一步的，与该RLC实体相关联的小区都是SCell；发生RLC失败的RLC实体所对应的DRB/SRB的信息，进一步的，与该RLC实体相关联的小区都是SCell。
进一步地，本申请实施例主要是针对收到RLC失败信息后，由DU对RLC失败进行处理，如图9所示，在图9中包括步骤2-1、步骤2-2与步骤2-3，其中，
步骤2-1：CU向DU发送消息2-1(如该消息是一个无需DU反馈的Class2消息)，该消息包含RLC失败相关信息，至少包括如下信息之一：
■发生RLC失败的RLC实体对应的逻辑信道的信息(如逻辑信道标识信息)，进一步，与该RLC实体相关联的小区都是SCell；
■发生RLC失败的RLC实体对应的一个或多个小区的标识信息，进一步，与该RLC实体相关联的小区都是SCell，所以该一个或多个小区都是SCell；
■发生RLC失败的RLC实体所对应的DRB/SRB的信息(如标识信息)，进一步，与该RLC实体相关联的小区都是SCell。
步骤2-2：DU向CU发送消息2-2(如UE上下文修改需求消息：UE contextmodification required消息)，该消息的内容可以参见TS38.473，该消息还可以至少包含如下信息之一：
■DU侧生成的关于用户的配置信息(如TS38.473“DU to CU RRC Information”IE),该信息可以包含至少如下信息之一：
■逻辑信道标识信息；
■重建RLC实体的指示信息；
■被释放的小区的标识信息；
■与需修改的DRB/SRB有关的信息，该信息表示DU已经完成了对该信息指示的DRB/SRB的修改，进一步的，该被修改的DRB/SRB与发生RLC失败的RLC实体对应，该信息至少包含如下信息之一：
■需修改的DRB/SRB的标识信息；
■需修改的DRB/SRB的至少一个逻辑信道的信息(如逻辑信道标识信息)；
■需修改的DRB/SRB的至少一个逻辑信道对应的小区的标识信息，该信息所指示的小区不再为该DRB/SRB服务；
■与需修改的DRB对应的一个DU侧的地址信息(如DL UP TNL information，下行用户平面传输网络层信息，参见TS38.473)。一个实施方式是，当前时刻，CU侧已经利用两个地址在为该DRB服务，DU侧已经利用两个地址在为该DRB服务，根据现有技术，DU不会在消息2-2中只包含DU侧的一个地址信息，但在本方案中，允许包含一个DU侧的地址信息；
■与需释放或需移除的小区(如SCell)有关的信息，该信息至少包括如下内容之一：
■小区的标识信息；
■该小区所服务的DRB/SRB有关的信息，如标识信息；
■该小区所对应的逻辑信道的信息，如逻辑信道标识信息，进一步的，该逻辑信道对应的RLC实体发生了失败，即该逻辑信道包含在了步骤2-1的消息2-1中的“RLC失败相关信息”内；
■指示网络侧(如DU，CU，或CU与DU)处理RLC失败的行为的指示信息，该指示信息可以是针对至少一个DRB和/或SRB，也可以针对用户，该指示信息可以是显示的，也可以是隐式的，该信息可以用来指示至少如下行为之一：
■重建发生RLC失败的RLC实体，进一步的还可以包括重建的RLC实体的逻辑信道标识；
■释放小区(如SCell)，在包含指示该行为的指示信息时，还可以进一步包括需要释放的一个或多个小区的标识信息(小区的NR CGI，或PCI，或Index)；
■不将一个或多个小区(如SCell)配置为与发生RLC失败的RLC实体对应的小区，在包含指示该行为的指示信息时，还可以进一步包括小区的标识信息；
■去激活CA duplication；
■切换BWP；
■重配发生RLC失败的RLC实体对应的DRB/SRB；
■同小区切换(intra-cell handover)；
■发送该消息2-2的原因信息，该原因信息可以参考本申请的下述实施例六；
■与发生RLC失败的RLC实体有关的信息，该信息至少包括如下信息之一：
■发生RLC失败的RLC实体对应的逻辑信道的信息(如逻辑信道标识信息)，其中，与该RLC实体相关联的小区都是SCell；
■发生RLC失败的RLC实体对应的一个或多个小区的标识信息，其中，与该RLC实体相关联的小区都是SCell，所以该一个或多个小区都是SCell；
■发生RLC失败的RLC实体所对应的DRB/SRB的信息(如标识信息)，其中，与该RLC实体相关联的小区都是SCell；
进一步地，CU收到上述与发生RLC失败的RLC实体有关的信息后来进一步进行对RLC失败的处理。
步骤2-3：CU向DU发送消息2-3(如UE上下文修改确认消息：UE contextmodification confirme消息)，该消息的内容可以参见TS38.473。
进一步地，在步骤2-1之前，还包括CU接收到用户的RLC失败相关信息，该信息可以是用户通过DU发送给CU的，也可以是其他基站或基站的CU发送给该CU的。
另外，本申请也包括一个CU向DU发送RLC失败有关信息的过程，该过程可以作为一个独立过程。该过程中，RLC失败相关信息至少包括如下信息之一：
■发生RLC失败的RLC实体对应的逻辑信道的信息(如逻辑信道标识信息)，进一步，与该RLC实体相关联的小区都是SCell；
■发生RLC失败的RLC实体对应的一个或多个小区的标识信息，进一步，与该RLC实体相关联的小区都是SCell，所以该一个或多个小区都是SCell；
■发生RLC失败的RLC实体所对应的DRB/SRB的信息(如标识信息)，进一步，与该RLC实体相关联的小区都是SCell。
■发生RLC失败的UE标识信息，进一步，与发生RLC失败的RLC实体相关联的小区都是SCell；
■发生RLC失败RLC实体对应的小区组的信息，如MCG，SCG，进一步，与该RLC实体相关联的小区都是SCell；
其中，该RLC失败相关信息，可以通过一个第二类型(Class2)信令(该信令没有对应的来自DU的反馈消息)由CU发送给DU，也可以通过一个第一类型(Class1)的信令(该信令有对应的来自DU的反馈消息)由CU发送给DU。上述第一类型信令和第二类型信令的定义可以参见TS38.413和TS36.413。
进一步地，在一个实施方式中，DU收到上述信息后，可以进行针对发生RLC失败的DRB/SRB的处理。
进一步地，在另一个实施方式中，DU收到上述信息后，可以帮助DU了解CU进行的针对发生RLC失败的DRB/SRB的处理。
实施例九
本申请实施例提供了另一种可能的实现方式，在实施例六至实施例八的基础上，还包括实施例九所示的方法，其中，
该方法还包括步骤S730(图中未标注)：通过预定义的与无线链路失败有关的原因信息，来对RLC失败进行相应处理。
具体地，预定义的与无线链路失败有关的原因信息，包括以下至少一项：
主小区无线链路失败；
下行链路无线链路失败；
上行链路无线链路失败；
辅小区无线链路失败；
下行链路辅小区无线链路失败；
上行链路辅小区无线链路失败。
进一步地，本申请实施例主要是定义了与无线链路失败有关的原因信息，其中，可以定义如下原因信息：
■主小区无线链路失败RL failure(或MCG failure)：这个原因信息表明超过了RLC实体的ARQ的最大重传次数，或者物理链路的问题或错误；进一步的，该原因信息还可以指示与该RLC实体相关的小区至少包括PCell或PSCell或SpCell(SpCell是PCell与PSCell的统称)，与该物理链路相关联的小区至少包括PCell或PSCell或SpCell(SpCell是PCell与PSCell的统称)；
■下行链路无线链路失败DL RL failure(或者称作DL SCG failure或DL MCGfailure)：这个原因信息表明超过了RLC实体(如基站侧的RLC实体)的ARQ的最大重传次数，或者下行的物理链路的问题或错误；进一步的，该原因信息还可以指示与该RLC实体相关联的小区至少包括PCell或PSCell或SpCell(SpCell是PCell与PSCell的统称)，与该物理链路相关联的小区至少包括PCell或PSCell或SpCell(SpCell是PCell与PSCell的统称)；
■上行链路无线链路失败UL RL failure：这个原因信息表明发生失败的原因是超过了RLC实体(如用户侧的RLC实体)的ARQ的最大重传次数，或者上行的物理链路的问题或错误；进一步的，该原因信息还可以指示与该RLC实体相关联的小区至少包括PCell或PSCell或SpCell(SpCell是PCell与PSCell的统称)，与该物理链路相关联的小区至少包括PCell或PSCell或SpCell(SpCell是PCell与PSCell的统称)；
■辅小区无线链路失败SCell RL failure(或者称作SCell Failure)：这个原因信息表明超过了RLC实体的ARQ的最大重传次数，或者物理链路的问题或错误；与该RLC实体相关联的小区都是SCell，与该物理链路相关联的都是SCell；
■下行辅小区无线链路失败DL SCell RL failure(或者称作DL SCellFailure)：这个原因信息表明超过了RLC实体(如基站侧的RLC实体)的ARQ的最大重传次数，或者下行的物理链路的问题或错误；与该RLC实体相关联的小区都是SCell，与该物理链路相关联的都是SCell；
■上行辅小区无线链路失败UL SCell RL failure(或者称作UL SCellFailure)：这个原因信息表明超过了RLC实体(如用户侧的RLC实体)的最大重传次数，或者上行的物理链路的问题或错误；与该RLC实体相关联的小区都是SCell，与该物理链路相关联的都是SCell。
上述原因信息可以是CU发送给DU，也可以是DU发送给CU，进一步，CU可以选择上述原因信息之一发送给DU，DU可以选择上述原因信息之一发送给CU。
进一步地，上述原因信息可以是针对一个DRB/SRB(如在提供该原因信息时，要指示该原因信息所针对的DRB/SRB的信息，如DRB/SRB标识信息)，也可以是针对一个小区(如在提供该原因信息时，要指示该原因信息所针对的小区的信息，如小区标识信息)。
进一步地，上述原因消息可以是针对CU发送给DU的一条消息，用来表明CU发送该消息的原因，或是DU发送给CU的一条消息，用来表明DU发送该消息的原因。
进一步地，上述原因信息可以在两个基站间交互，可以是针对一个DRB/SRB，也可以是针对一个小区，也可以用来表明基站发送消息的原因。
进一步地，上述原因信息的名称只是示例，还可以为其他的名称。
进一步地，基于上述原因信息，CU或DU或基站在接收到一条消息后，可以理解该消息发送的原因。进一步地，收到上述原因信息后，CU或DU或基站可以决定接下来的行为，如重建RLC实体，释放或移除小区，进行PCell/PSCell的切换等。
进一步地，上述原因信息不仅限于被用到对RLC失败进行处理，也可以用于其他适用的情况。
实施例十
本申请实施例提供了另一种可能的实现方式，在实施例六至实施例九的基础上，还包括实施例十所示的方法，其中，
该方法还包括步骤S740(图中未标注)与步骤S750(图中未标注)，其中，
步骤S740：接收第一网络设备发送的第四请求消息。
步骤S750：向第一网络设备返回针对所述第四请求消息的第四响应消息。
其中，第四请求消息中关于一个DRB的地址信息数量和第四响应消息中的关于所述DRB的地址信息数量不同。
第四请求消息包括以下至少一项：
待配置duplication的DRB的信息；
第一网络设备服务所述DRB的两个地址信息；
第四响应消息包括以下至少一项：
已配置的duplication的DRB的信息；
第二网络设备服务所述DRB的一个地址信息。
进一步地，第二网络设备服务所述DRB的一个地址信息，以使得第一网络设备基于预设规则从服务所述DRB的两个地址信息中选择一个，作为服务第二网络设备的所述DRB的一个地址信息；或者，第二网络设备服务所述DRB的一个地址信息，以使得第一网络设备从服务所述DRB的两个地址信息中选择对应的地址信息，作为服务第二网络设备的所述DRB的一个地址信息。
进一步地，本申请实施例主要是给出了配置duplication的过程，如图10所示，包括步骤4-1与步骤4-2，其中，
步骤4-1：CU向DU发送消息4-1(如用户上下文建立/修改请求消息)，或基站1向基站2发送消息4-1(如SgNB Addition/Modification request消息)，该消息用来配置duplication，可以参考TS38.473,TS36.423,TS38.423，其可以至少包含如下信息之一：
■待配置的duplication的DRB的信息，如DRB标识信息；
■发送端(如CU，基站1)服务该DRB的地址信息(如GTP隧道端点标识GTP-TEID，传输层地址Transport Layer Address)，可以包含两个地址信息。
步骤4-2：DU向CU发送消息4-2(如用户上下文建立/修改响应消息)，或基站2向基站1发送消息4-2(如SgNB Addition/Modification acknowledge消息)可以参考TS38.473,TS36.423,TS38.423，其可以至少包括如下信息之一：
■已配置的duplication的DRB的信息，如DRB标识信息；
■发送端(如DU，基站2)服务该DRB的地址信息(如GTP-TEID，传输层地址Transport Layer Address)，可以包含两个地址信息。在另一个实施例中，可以只包含一个地址信息，在这种情况下，CU或基站1收到该消息后，可以从步骤4-1的消息4-1中所包含的两个地址信息中选择一个作为服务该DRB的地址信息，该选择的一个地址信息可以根据默认的原则选择，也可以是在消息4-2中指定一个。
上述流程不仅限于对RLC失败进行的处理，对于其他适用的情况也可以采用上述流程来配置duplication。
进一步地，本申请要解决的问题包括如下四个方面的内容：
1、CU和DU间交互相关信息来帮助网络侧处理RLC失败；
2、定义新的原因信息来帮助网络侧了解RLC失败的原因；
3、配置CA duplication来帮助网络侧解决RLC失败；
4、在基站间交互RLC失败相关信息来帮助网络侧获得RLC失败的信息。
上述实施例一至实施例十已对第一方面到第三方面的内容进行了详细介绍，下面对第四方面的内容进行详细介绍：
图11给出了在基站间交互RLC失败相关信息的基本过程，在图11中包括步骤5-1与步骤5-2，其中，
步骤5-1：基站1(即本申请实施例中的第一网络设备)接收用户发送RLC失败相关信息(消息5-1)，该消息5-1是UE直接发送给基站1的或通过基站1的DU发送给基站1的CU的，该消息5-1至少包括如下信息之一：
■发生RLC失败的用户标识信息；
■发生RLC失败的RLC实体对应的逻辑信道的信息(如逻辑信道标识信息)；
■发生RLC失败RLC实体所对应的小区组的信息，如MCG，SCG等；
■发生RLC失败的RLC实体对应的一个或多个小区的标识信息，进一步，该一个或多个小区都是SCell；
■发生RLC失败的RLC实体所对应的DRB/SRB的信息(如标识信息)。
步骤5-2：基站1将收到的消息5-1或消息5-1中的部分内容通过消息5-2发送给基站2(即本申请实施例中的第二网络设备)，该消息5-2可以是通过X2接口发送，也可以是通过Xn接口发送。
基站2收到上述消息5-2后，会对发生RLC失败的用户进行处理，如重建用户RLC实体，释放小区等。
进一步地，对于第一方面的“CU和DU间交互相关信息来帮助网络侧处理RLC失败”，本申请实施例中的相应概述为：当第一网络设备为CU，第二网络设备为DU时，基于接收到的RLC失败相关信息，通过与第二网络设备进行交互，来对RLC失败进行相应处理。即在本申请实施例中，通过CU与DU间的交互，来交互CU与DU间的相关信息，从而帮助处理RLC失败。下面通过实施例三至初实施例五，分别来介绍通过CU与DU间的交互来对RLC失败进行相应处理的情况。
实施例十一
本申请实施例提供了一种网络设备，包括：处理器；以及存储器，配置用于存储机器可读指令，指令在由处理器执行时，使得处理器执行上述的处理RLC失败的方法。
图12示意性示出了根据本公开实施例的可用于执行本申请公开的处理RLC失败的方法的计算系统的框图。
如图12所示，计算系统1200包括处理器1210、计算机可读存储介质1220、输出接口1230、以及输入接口1240。该计算系统1200可以执行上面参考图3、图7描述的方法，以处理RLC失败。
具体地，处理器1210例如可以包括通用微处理器、指令集处理器和/或相关芯片组和/或专用微处理器(例如，专用集成电路(ASIC))，等等。处理器1210还可以包括用于缓存用途的板载存储器。处理器1210可以是用于执行参考图3、图7描述的方法流程的不同动作的单一处理单元或者是多个处理单元。
计算机可读存储介质1220，例如可以是能够包含、存储、传送、传播或传输指令的任意介质。例如，可读存储介质可以包括但不限于电、磁、光、电磁、红外或半导体系统、装置、器件或传播介质。可读存储介质的具体示例包括：磁存储装置，如磁带或硬盘(HDD)；光存储装置，如光盘(CD-ROM)；存储器，如随机存取存储器(RAM)或闪存；和/或有线/无线通信链路。
计算机可读存储介质1220可以包括计算机程序，该计算机程序可以包括代码/计算机可执行指令，其在由处理器1210执行时使得处理器1210执行例如上面结合图3、图7所描述的方法流程及其任何变形。
计算机程序可被配置为具有例如包括计算机程序模块的计算机程序代码。例如，在示例实施例中，计算机程序中的代码可以包括一个或多个程序模块，例如包括模块1、模块2、……。应当注意，模块的划分方式和个数并不是固定的，本领域技术人员可以根据实际情况使用合适的程序模块或程序模块组合，当这些程序模块组合被处理器1210执行时，使得处理器1210可以执行例如上面结合图3所描述的方法流程及其任何变形。
根据本公开的实施例，处理器1210可以使用输出接口1230和输入接口1240来执行上面结合图3所描述的方法流程及其任何变形。
本申请实施例提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该程序被处理器执行时实现实施例一所示的方法。与现有技术相比，第一网络设备接收用户设备UE的RLC失败相关信息，为后续网络设备对RLC失败进行相应处理提供前提保障；基于接收到的RLC失败相关信息，通过与第二网络设备进行交互，来对RLC失败进行相应处理，使得第一网络设备能够直接与第二网络设备进行交互，从而能够直接根据接收到的UE上报的RLC失败相关信息以及交互信息，决定对该RLC失败的处理，从而简化RLC处理的流程，提高处理效率，便于RLC失败的正确且快速的解决，提升用户体验。
本申请实施例提供的计算机可读存储介质适用于上述方法的任一实施例。在此不再赘述。
应该理解的是，虽然附图的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，其可以以其他的顺序执行。而且，附图的流程图中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，其执行顺序也不必然是依次进行，而是可以与其他步骤或者其他步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。
以上仅是本申请的部分实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本申请的保护范围。

Claims (10)

1.一种由基站中的集中单元CU执行的用于处理无线链路控制RLC失败的方法，其特征在于，包括：
从用户设备UE接收关于RLC失败的信息；
向基站中的分布单元DU发送UE上下文修改请求消息，所述UE上下文修改请求消息包括与关于RLC失败的信息相关联的第一信息；
从所述DU接收UE上下文修改响应消息，所述UE上下文修改响应消息包括关于与RLC失败相关的至少一个小区的第二信息；
其中，所述第一信息包括逻辑信道标识；
所述逻辑信道标识与需要重建的RLC实体相关联。
2.根据权利要求1所述的方法，其特征在于，所述第二信息包括与所述第一信息指示的所述RLC实体相关联的辅小区的列表。
3.一种由基站中的分布单元DU执行的用于处理无线链路控制RLC失败的方法，其特征在于，包括：
从基站中的集中单元CU接收UE上下文修改请求消息，所述UE上下文修改请求消息包括与关于RLC失败的信息相关联的第一信息；
向所述CU发送UE上下文修改响应消息，所述UE上下文修改响应消息包括关于与RLC失败相关的至少一个小区的第二信息；
其中，所述关于RLC失败的信息由所述CU从用户设备UE接收；
所述第一信息包括逻辑信道标识；
所述逻辑信道标识与需要重建的RLC实体相关联。
4.根据权利要求3所述的方法，其特征在于，所述第二信息包括与所述第一信息指示的所述RLC实体相关联的辅小区的列表。
5.一种基站中的集中单元CU，其特征在于，包括：
一个收发器；以及一个处理器，所述一个处理器可操作地耦合到所述一个收发器，所述一个处理器配置为：
从用户设备UE接收关于RLC失败的信息；
向基站中的分布单元DU发送UE上下文修改请求消息，所述UE上下文修改请求消息包括与关于RLC失败的信息相关联的第一信息；
从所述DU接收UE上下文修改响应消息，所述UE上下文修改响应消息包括关于与RLC失败相关的至少一个小区的第二信息；
其中，所述第一信息包括逻辑信道标识；
所述逻辑信道标识与需要重建的RLC实体相关联。
6.根据权利要求5所述的CU，其特征在于，所述第二信息包括与所述第一信息指示的所述RLC实体相关联的辅小区的列表。
7.一种基站中的分布单元DU，其特征在于，包括：
一个收发器；以及一个处理器，所述一个处理器可操作地耦合到所述一个收发器，所述一个处理器配置为：
从基站中的集中单元CU接收UE上下文修改请求消息，所述UE上下文修改请求消息包括与关于RLC失败的信息相关联的第一信息；
向所述CU发送UE上下文修改响应消息，所述UE上下文修改响应消息包括关于与RLC失败相关的至少一个小区的第二信息；
其中，所述关于RLC失败的信息由所述CU从用户设备UE接收；
所述第一信息包括逻辑信道标识；
所述逻辑信道标识与需要重建的RLC实体相关联。
8.根据权利要求7所述的DU，其特征在于，所述第二信息包括与所述第一信息指示的所述RLC实体相关联的辅小区的列表。
9.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序，该程序被处理器执行时实现权利要求1或2所述的处理RLC失败的方法。
10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序，该程序被处理器执行时实现权利要求3或4所述的处理RLC失败的方法。
CN202110287480.4A 2018-06-21 2018-06-21 处理rlc失败的方法、网络设备及计算机存储介质 Active CN112954822B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202110287480.4A CN112954822B (zh) 2018-06-21 2018-06-21 处理rlc失败的方法、网络设备及计算机存储介质

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201810646390.8A CN110636564A (zh) 2018-06-21 2018-06-21 处理rlc失败的方法、网络设备及计算机存储介质
CN202110287480.4A CN112954822B (zh) 2018-06-21 2018-06-21 处理rlc失败的方法、网络设备及计算机存储介质

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
CN201810646390.8A Division CN110636564A (zh) 2018-06-21 2018-06-21 处理rlc失败的方法、网络设备及计算机存储介质

Publications (2)

Publication Number Publication Date
CN112954822A CN112954822A (zh) 2021-06-11
CN112954822B true CN112954822B (zh) 2023-04-11

Family

ID=68966706

Family Applications (2)

Application Number Title Priority Date Filing Date
CN202110287480.4A Active CN112954822B (zh) 2018-06-21 2018-06-21 处理rlc失败的方法、网络设备及计算机存储介质
CN201810646390.8A Pending CN110636564A (zh) 2018-06-21 2018-06-21 处理rlc失败的方法、网络设备及计算机存储介质

Family Applications After (1)

Application Number Title Priority Date Filing Date
CN201810646390.8A Pending CN110636564A (zh) 2018-06-21 2018-06-21 处理rlc失败的方法、网络设备及计算机存储介质

Country Status (7)

Country Link
US (2) US11825541B2 (zh)
EP (1) EP3811676B1 (zh)
KR (2) KR102738392B1 (zh)
CN (2) CN112954822B (zh)
AU (1) AU2019288875B2 (zh)
CA (1) CA3104651A1 (zh)
WO (1) WO2019245323A1 (zh)

Families Citing this family (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111030798B (zh) * 2017-03-03 2021-04-02 Oppo广东移动通信有限公司 传输数据的方法和设备
WO2018170377A1 (en) * 2017-03-17 2018-09-20 Intel Corporation Re-transmission of pdcp pdus by centralized nodes of a ran architecture
CN112954822B (zh) * 2018-06-21 2023-04-11 北京三星通信技术研究有限公司 处理rlc失败的方法、网络设备及计算机存储介质
CN112312442A (zh) * 2019-08-02 2021-02-02 中兴通讯股份有限公司 异常小区处理方法、装置、单元和计算机可读存储介质
CN113259991A (zh) * 2020-02-13 2021-08-13 华为技术有限公司 通信方法及装置
CN113163416B (zh) * 2020-12-30 2022-11-29 京信网络系统股份有限公司 消息处理方法、装置、基站和存储介质
US11800404B1 (en) 2021-05-20 2023-10-24 Amazon Technologies, Inc. Multi-tenant radio-based application pipeline processing server
US11720425B1 (en) 2021-05-20 2023-08-08 Amazon Technologies, Inc. Multi-tenant radio-based application pipeline processing system
US11916999B1 (en) 2021-06-30 2024-02-27 Amazon Technologies, Inc. Network traffic management at radio-based application pipeline processing servers
US12236248B1 (en) 2021-06-30 2025-02-25 Amazon Technologies, Inc. Transparent migration of radio-based applications
US12255951B1 (en) 2021-06-30 2025-03-18 Amazon Technologies, Inc. Capacity management for radio-based applications
US11356500B1 (en) * 2021-06-30 2022-06-07 Amazon Technologies, Inc. Disaggregated processing of radio-based applications
US11539582B1 (en) 2021-08-30 2022-12-27 Amazon Technologies, Inc. Streamlined onboarding of offloading devices for provider network-managed servers
EP4417011A1 (en) * 2021-10-14 2024-08-21 Telefonaktiebolaget LM Ericsson (publ) Methods and apparatuses for handling of inter-cell multi-trp configurations during re-establishment
US11985065B2 (en) 2022-06-16 2024-05-14 Amazon Technologies, Inc. Enabling isolated virtual network configuration options for network function accelerators
US12213014B1 (en) 2022-06-23 2025-01-28 Amazon Technologies, Inc. Enabling direct connectivity between distributed units of radio-based applications to improve post-handover retransmission performance
US11824943B1 (en) 2022-06-29 2023-11-21 Amazon Technologies, Inc. Managed connectivity between cloud service edge locations used for latency-sensitive distributed applications
US11937103B1 (en) 2022-08-17 2024-03-19 Amazon Technologies, Inc. Enhancing availability of radio-based applications using multiple compute instances and virtualized network function accelerators at cloud edge locations
US12153535B2 (en) 2022-12-16 2024-11-26 Amazon Technologies, Inc. Portable mobile private networks using pluggable hardware modules

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015008962A1 (en) * 2013-07-17 2015-01-22 Lg Electronics Inc. Method for reporting a radio link control re-transmission failure and a device therefor
CN105103616A (zh) * 2014-01-29 2015-11-25 华为技术有限公司 一种无线链路失败的处理方法及设备

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10008148A1 (de) * 2000-02-22 2001-08-23 Bosch Gmbh Robert Verfahren zum Betreiben eines Mobilfunknetzes
US10306695B2 (en) * 2014-01-31 2019-05-28 Qualcomm Incorporated Procedures for managing secondary eNB (SeNB) radio link failure (S-RLF) in dual connectivity scenarios
US10470233B2 (en) * 2014-10-01 2019-11-05 Telefonaktiebolaget Lm Ericsson (Publ) RLC delivery failure resolution
KR102386844B1 (ko) * 2017-05-12 2022-04-14 삼성전자 주식회사 클라우드 랜 환경에서 네트워크 엔티티들 간의 통신 방법 및 장치
CN110022224B (zh) * 2018-01-10 2020-09-01 维沃移动通信有限公司 一种数据的处理方法、用户侧设备及网络侧设备
CN112954822B (zh) * 2018-06-21 2023-04-11 北京三星通信技术研究有限公司 处理rlc失败的方法、网络设备及计算机存储介质
CN113784457B (zh) 2018-08-10 2022-08-19 华为技术有限公司 一种通知方法、装置及基站

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015008962A1 (en) * 2013-07-17 2015-01-22 Lg Electronics Inc. Method for reporting a radio link control re-transmission failure and a device therefor
CN105103616A (zh) * 2014-01-29 2015-11-25 华为技术有限公司 一种无线链路失败的处理方法及设备

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
3GPP TS 36.331 V15.2.0 (2018-06);3GPP;《3GPP》;20180620;第5.6.13-5.6.13a节 *
3GPP TS 38.473 V15.1.1 (2018-04);3GPP;《3GPP》;20180411;第8节 *
R2-1807215，RLC failure for duplication;Ericsson;《3GPP》;20180511;全文 *

Also Published As

Publication number Publication date
KR102738392B1 (ko) 2024-12-06
KR20250002712A (ko) 2025-01-07
AU2019288875B2 (en) 2024-05-23
EP3811676A1 (en) 2021-04-28
KR20210012039A (ko) 2021-02-02
US20190394826A1 (en) 2019-12-26
AU2019288875A1 (en) 2021-02-11
US11825541B2 (en) 2023-11-21
WO2019245323A1 (en) 2019-12-26
US20240090065A1 (en) 2024-03-14
EP3811676B1 (en) 2024-07-31
CA3104651A1 (en) 2019-12-26
EP3811676A4 (en) 2022-04-06
CN110636564A (zh) 2019-12-31
CN112954822A (zh) 2021-06-11

Similar Documents

Publication Publication Date Title
CN112954822B (zh) 处理rlc失败的方法、网络设备及计算机存储介质
CN108306708B (zh) 一种数据包处理方法及装置
CN107708215B (zh) 载波资源配置方法、上行信息传输方法、基站及用户设备
CN108307538B (zh) 用于建立/重配置数据承载的方法和设备
EP3761681B1 (en) Multi-connection data amount reporting method
US11206538B2 (en) Control signaling processing method, device, and system
US10735164B2 (en) Data transmission method, apparatus, user equipment, and base station
KR20200035904A (ko) 무선 통신 시스템에서 이중 접속을 수행하는 방법 및 장치.
EP4329372A1 (en) Data transmission method and apparatus
US20230025829A1 (en) Method and apparatus for managing timer related to segmentation transmission of rrc message in next-generation mobile communication system
CN107251605B (zh) 有效可靠传输的方法及用户装置
WO2016127666A1 (zh) 一种rlc数据包分流方法及基站
WO2020199992A1 (zh) 一种通信方法及装置
WO2017185374A1 (zh) 一种语音业务的处理方法及基站
CN107347199A (zh) 一种切换及其控制方法、装置
CN116601989B (zh) 数据传输处理方法及相关装置
CN104429109A (zh) 一种通信方法及装置
US20200077298A1 (en) Method and apparatus for processing data at high speed
CN107360606B (zh) 一种分布式处理节点切换的处理方法及装置
US20220394799A1 (en) Method and device for segmenting downlink radio resource control message in next-generation mobile communication system
JP7656098B2 (ja) データ伝送方法、装置、及びシステム
JP2024524407A (ja) データ伝送方法、装置、及びシステム

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