承载的配置方法、网络侧设备及终端

技术领域

本申请属于无线通信技术领域，具体涉及一种承载的配置方法、网络侧设备及终端。

背景技术

在现有机制中，一个用户设备(User Equipment，UE)与核心网建立自己的控制面连接和用户面连接，例如协议数据单元(Protocol Data Unit，PDU)会话(session)。当UE在不同的小区、不同的基站，甚至是不同的核心网节点之间移动时，网络侧将该UE的控制面连接和用户面连接以及传输状态，在不同的网络节点之间进行传递，以确保UE的业务传输能够连续、不中断、以及按照需求达到无损的要求。

当两个UE进行数据传输时，两个UE各自建立自己的核心网或接入网的控制面连接和用户面连接，例如非接入层(Non Access Stratum，NAS)连接(核心网控制面)、无线资源控制(Radio Resource Control，RRC)连接(接入网控制面)，PDU session(核心网用户面)、数据无线承载(Data Radio Bearer，DRB)以及服务质量(Quality of Service，QoS)流(flow)(接入网用户面)等都是两个UE各自独立的。因此，在现有技术中无法实现多UE协作传输。

发明内容

本申请实施例提供一种承载的配置方法、网络侧设备及终端，能够解决现有技术中无法实现多UE协作传输的问题。

第一方面，提供了一种承载的配置方法，包括：无线接入网络RAN节点向第一用户设备UE发送第一配置信息，其中，所述第一配置信息用于配置多UE协作传输的承载。

第二方面，提供了一种承载的配置装置，包括：第一获取模块，用于获取第一UE的第一配置信息，其中，所述第一配置信息用于配置多UE协作传输的承载；第一收发模块，用于向所述第一UE发送所述第一配置信息。

第三方面，提供了一种多UE协作传输的配置方法，包括：核心网设备向RAN节点发送关联关系信息，其中，所述关联关系信息用于指示第一UE与第二UE具有关联关系，所述第一UE和所述第二UE具有建立多UE协作传输的能力。

第四方面，提供了一种多UE协作传输的配置装置，包括：第二获取模块，用于获取关联关系信息，其中，所述关联关系信息用于指示第一UE与第二UE具有关联关系，所述第一UE和所述第二UE具有建立多UE协作传输的能力；第二收发模块，用于向RAN节点发送所述关联关系。

第五方面，提供了一种多UE协作传输的请求方法，包括：第一UE向RAN节点发送第一请求，其中，所述第一请求用于请求所述RAN节点为所述第一UE配置多UE协作传输的承载，所述第一请求中携带有第二UE的标识。

第六方面，提供了一种多UE协作传输的请求装置，包括：第一确定模块，用于确定第一UE需要执行多UE协作传输；第三收发模块，用于向RAN节点发送第一请求，其中，所述第一请求用于请求所述RAN节点为所述第一UE配置多UE协作传输的承载，所述第一请求中携带有第二UE的标识。

第七方面，提供了一种多UE协作传输的响应方法，包括：第二UE接收RAN节点发送的第二配置信息，其中，所述第二配置信息用于指示所述第二UE为第一UE进行多UE协作传输的承载配置；在同意为所述第一UE进行多UE协作传输的情况下，所述第二UE应用所述第二配置信息，向所述RAN节点发送配置完成消息。

第八方面，提供了一种多UE协作传输的响应装置，包括：第四收发模块，用于接收RAN节点发送的第二配置信息，其中，所述第二配置信息用于指示所述第二UE为第一UE进行多UE协作传输的承载配置；第二确定模块，用于确定是否同意为所述第一UE进行多UE协作传输；所述第四收发模块还用于在同意为所述第一UE进行多UE协作传输的情况下，所述第二UE应用所述第二配置信息，向所述RAN节点发送配置完成消息。

第九方面，提供了一种终端，该终端包括处理器、存储器及存储在所述存储器上并可在所述处理器上运行的程序或指令，所述程序或指令被所述处理器执行时实现如第五方面所述的方法的步骤，或者实现如第七方面所述的方法的步骤。

第十方面，提供了一种终端，包括处理器及通信接口，其中，所述处理器用于实现如第一方面所述的方法的步骤，，或者实现如第七方面所述的方法的步骤所述通信接口用于与外部设备进行通信。

第十一方面，提供了一种网络侧设备，该网络侧设备包括处理器、存储器及存储在所述存储器上并可在所述处理器上运行的程序或指令，所述程序或指令被所述处理器执行时实现如第一方面所述的方法的步骤，或者实现如第三方面所述的方法的步骤。

第十二方面，提供了一种网络侧设备，包括处理器及通信接口，其中，所述处理器用于实现如第一方面所述的方法的步骤，或者实现如第三方面所述的方法的步骤，所述通信接口用于与外部设备进行通信。

第十三方面，提供了一种可读存储介质，所述可读存储介质上存储程序或指令，所述程序或指令被处理器执行时实现如第一方面所述的方法的步骤，或者实现如第三方面所述的方法的步骤，或者实现如第五方面所述的方法的步骤，或者实现如第七方面所述的方法的步骤。

第十四方面，提供了一种芯片，所述芯片包括处理器和通信接口，所述通信接口和所述处理器耦合，所述处理器用于运行程序或指令，实现如第一方面所述的方法的步骤，或者实现如第三方面所述的方法的步骤，或者实现如第五方面所述的方法的步骤，或者实现如第七方面所述的方法的步骤。

第十五方面，提供了一种计算机程序/程序产品，所述计算机程序/程序产品被存储在非瞬态的存储介质中，所述计算机程序/程序产品被至少一个处理器执行以实现第一方面所述的方法的步骤，或者实现如第三方面所述的方法的步骤，或者实现如第五方面所述的方法的步骤，或者实现如第七方面所述的方法的步骤。

在本申请实施例中，无线接入网络(Radio Access Network，RAN)节点可以向第一UE发送第一配置，配置多UE协作传输的承载，从而使得第一UE可以进行多UE协作传输。

附图说明

图1示出本申请实施例可应用的一种无线通信系统的示意图；

图2示出本申请实施例提供的承载的配置方法的一种流程示意图；

图3a示出本申请实施例提供的一种多UE传输架构的示意图；

图3b示出本申请实施例提供的另一种多UE传输架构的示意图；

图3c示出本申请实施例提供的又一种多UE传输架构的示意图；

图4示出本申请实施例提供的多UE协作传输的配置方法的一种流程示意图；

图5示出本申请实施例提供的多UE协作传输的配置方法的一种流程示意图；

图6示出本申请实施例提供的多UE协作传输的响应方法的一种流程示意图；

图7示出本申请实施例提供的多UE协作传输的承载建立方法的一种流程示意图；

图8示出本申请实施例提供的多UE协作传输的承载建立方法的另一种流程示意图；

图9示出本申请实施例提供的承载的配置装置的一种结构示意图；

图10示出本申请实施例提供的多UE协作传输的配置装置的一种结构示意图；

图11示出本申请实施例提供的多UE协作传输的配置装置的一种结构示意图；

图12示出本申请实施例提供的多UE协作传输的响应装置的一种结构示意图；

图13示出本申请实施例提供的一种通信设备的结构示意图；

图14示出本申请实施例提供的一种终端的硬件结构示意图；

图15示出本申请实施例提供的一种网络侧设备的硬件结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本申请保护的范围。

本申请的说明书和权利要求书中的术语“第一”、“第二”等是用于区别类似的对象，而不用于描述特定的顺序或先后次序。应该理解这样使用的术语在适当情况下可以互换，以便本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施，且“第一”、“第二”所区别的对象通常为一类，并不限定对象的个数，例如第一对象可以是一个，也可以是多个。此外，说明书以及权利要求中“和/或”表示所连接对象的至少其中之一，字符“/”一般表示前后关联对象是一种“或”的关系。

值得指出的是，本申请实施例所描述的技术不限于长期演进型(Long TermEvolution，LTE)/LTE的演进(LTE-Advanced，LTE-A)系统，还可用于其他无线通信系统，诸如码分多址(Code Division Multiple Access，CDMA)、时分多址(Time DivisionMultiple Access，TDMA)、频分多址(Frequency Division Multiple Access，FDMA)、正交频分多址(Orthogonal Frequency Division Multiple Access，OFDMA)、单载波频分多址(Single-carrier Frequency-Division Multiple Access，SC-FDMA)和其他系统。本申请实施例中的术语“系统”和“网络”常被可互换地使用，所描述的技术既可用于以上提及的系统和无线电技术，也可用于其他系统和无线电技术。以下描述出于示例目的描述了新空口(NewRadio，NR)系统，并且在以下大部分描述中使用NR术语，但是这些技术也可应用于NR系统应用以外的应用，如第6代(6

图1示出本申请实施例可应用的一种无线通信系统的示意图。无线通信系统包括终端11和网络侧设备12。其中，终端11也可以称作终端设备或者用户终端(UserEquipment，UE)，终端11可以是手机、平板电脑(Tablet Personal Computer)、膝上型电脑(Laptop Computer)或称为笔记本电脑、个人数字助理(Personal Digital Assistant，PDA)、掌上电脑、上网本、超级移动个人计算机(ultra-mobile personal computer，UMPC)、移动上网装置(Mobile Internet Device，MID)、可穿戴式设备(Wearable Device)或车载设备(VUE)、行人终端(PUE)等终端侧设备，可穿戴式设备包括：智能手表、手环、耳机、眼镜等。需要说明的是，在本申请实施例并不限定终端11的具体类型。网络侧设备12可以是基站或核心网，其中，基站可被称为节点B、演进节点B、接入点、基收发机站(Base TransceiverStation，BTS)、无线电基站、无线电收发机、基本服务集(Basic Service Set，BSS)、扩展服务集(Extended Service Set，ESS)、B节点、演进型B节点(eNB)、家用B节点、家用演进型B节点、WLAN接入点、WiFi节点、发送接收点(TransmittingReceivingPoint，TRP)或所述领域中其他某个合适的术语，只要达到相同的技术效果，所述基站不限于特定技术词汇，需要说明的是，在本申请实施例中仅以NR系统中的基站为例，但是并不限定基站的具体类型。

下面结合附图，通过一些实施例及其应用场景对本申请实施例提供的承载的配置方法、网络侧设备及终端进行详细地说明。

图2示出本申请实施例中的承载的配置方法的一种流程示意图，该方法200可以由RAN节点执行。换言之，所述方法可以由安装在RAN节点上的软件或硬件来执行。如图2所示，该方法可以包括以下步骤。

S210，RAN节点向第一UE发送第一配置信息，其中，所述第一配置信息用于配置多UE协作传输的承载。

在本申请实施例中，RAN节点可以是基站或者集中式单元(Centralized Unit，CU)，具体本申请实施例中不作限定。

在相关技术中，不同UE的接入网连接或核心网连接彼此之间独立，各个UE只能独立的进行业务传输，然而在实际使用中，用户可能需要两个UE之间进行业务共同传输，例如用户在室内使用手机进行听歌/听书时，准备出门跑步，用户希望手环能够连续的进行相关业务的接收，给用户带来连续性的业务体验。或者，当一个UE的发送功率受限或者上行传输速率不够的情况下，可以使用两个或者多个UE的发送功率和传输能力进行共同传输。或者，当用户的业务具有比较高的可靠性时，可以在两个或者更多UE建立连接备份，根据链路质量决定当前使用哪条链路传输，以满足低时延和高可靠性的传输需求。然而这些场景在现有的架构和机制中是无法支持的，需要用户手动的在新设备上对业务的接收和接收进度进行设置或者通过业务层，才能达到连续性接收的效果，或者通过硬切换达到链路变化，降低了体验的便利性和用户QoS体验效果。而在本申请实施例提供的技术方案中，RAN节点为第一UE配置用于多UE协作传输的承载，从而使得第一UE可以用于多UE协作传输，提高业务传输的便利性和用户QoS体验效果。

可选地，所述第一配置信息可以包括：第二UE的标识以及承载架构的配置信息。

在本申请实施例中，所述承载架构的配置信息是指多UE协作传输(也可以称为聚合传输、备份传输或切换传输等)的多UE架构配置，例如，可以包括图3a所示的分组数据汇聚协议(Packet Data Convergence Protocol，PDCP)锚(anchor)架构、图3b所示的无线链路控制(Radio Link Control，RLC)anchor架构、图3c所示的媒体接入控制(Medium AccessControl，MAC)anchor架构中的至少之一的配置信息。

当然，并不限于此，多UE架构除了图3a至图3c中所示的架构之外，还可以采用其它的架构，例如，将某一层(例如PDCP或MAC)的部分公共功能(common function)设置于第一UE，而将分叉功能(split function)设置于第二UE。

在具体应用中，协议可以选择一种或多种架构，如果选择一种架构，则第一配置信息中包括该架构相关的协议实体的配置，如果采用两种或以上的架构，则RAN节点可以按需进行不同架构的选择和配置，具体本申请实施例中不作限定。

在一个可能的实现方式中，为了避免第二UE不同意与第一UE进行多UE协作传输而导致第一UE还需要释放刚建立的多UE协作传输的承载的情况，该方法还可以包括：在所述RAN节点向第一UE发送第一配置信息之前，所述方法还包括：所述RAN节点向所述第二UE发送第二配置信息，其中，所述第二配置信息用于指示所述第二UE为所述第一UE进行多UE协作传输的承载配置；所述RAN节点接收所述第二UE返回的配置完成消息。采用该可能的实现方式，RAN节点先向第二UE发送所述第二配置信息，在接收到所述第二UE发送的配置完成消息之后，再向第一UE发送所述第一配置信息，从而可以在第二UE同意与第一UE进行多UE协作传输之后，再重配置第一UE的承载，避免了流程的浪费。

在本申请实施例中，RAN节点可以自行判断向第一UE发送第一配置信息，或者，也可以在核心网的触发下向第一UE发送第一配置信息，或者，也可以是在第一UE的请求下向第一UE发送第一配置信息，下面分别进行说明。

(一)核心网触发

在该可能的实现方式中，在S210之前，该方法还可以包括：RAN节点接收核心网下发的关联关系信息，其中，所述关联关系信息用于指示所述第一UE与第二UE之间的关联关系。

由于多UE架构牵涉到两个或者多个UE之间的深度合作，需要使用到其它UE的传输能力和传输硬件资源，以及涉及到一些计费和安全因素，因此一种比较典型的场景是，需要进行多UE架构传输的用户之间，先经过签约等过程使彼此之间的关联关系(也可以称为绑定关系)静态化。例如，一个用户的手机与可穿戴设备，甚至是与家用设备之间，可以通过签约过程初始化彼此之间的关联关系。再比如，一个工厂的特定设备之间因为需要协同工作，也可以通过预先的过程初始化彼此之间的关联关系。

一般来说，签约过程或者预先初始化过程的关联关系需要存储在核心网节点，由核心网节点负责验证关联关系的有效性。

可选地，签约或者预先的关联关系，可以包括以下之一：

(1)一组具有关联关系的UE列表，列表中的UE彼此之间可以互相协作传输，每个UE根据需要决定作为主UE(P-UE)或者辅UE(S-UE)；

(2)一组具有关联关系的UE列表，其中每个UE的属性P-UE还是S-UE是提前预设的；

(3)一组具有关联关系的UE列表，其中设定了每个UE可以支持的属性，例如P-UEonly，S-UE only或者both P-UE and S-UE；

其中，上述关联关系可以是基于UE粒度，即这些UE之间的任何业务都可以进行多UE架构建立和传输，也可以进一步基于特定业务的粒度，即在UE列表的基础上，限制这些UE之间，针对什么样的业务进行多UE架构建立和传输，其中业务限制可以是业务标识，业务的具体QoS参数，业务的具体QoS参数的范围等。

其中，上述主UE(Primary UE，P-UE)是业务发起的UE或者业务源/业务传输的高层协议位于该UE，辅UE(Secondary UE，S-UE)是协助主UE进行业务传输的，一般只具有传输协议较低层的协议层，只完成协助传输的相关功能。

核心网存储上述签约过程或者预先初始化过程的关联关系，在需要时下发给RAN节点，便于RAN节点进行后续的多UE架构的配置。在一个可能实现方式中，核心网下发给RAN节点的关联关系信息可以包括以下至少之一：

(1)具有关联关系的UE标识列表，其中，所述UE标识列表中包括所述第一UE的标识和所述第二UE的标识；例如，具有绑定关系的UE ID list，其中UE ID可以为全球唯一标识、公共陆地移动网络(Public Land Mobile Network，PLMN)内UE标识、接入和移动管理功能(Access and Mobility Management Function，AMF)节点内标识或者gNB/CU内的标识，可以是S-临时移动签约标识(S-Temporary Mobile Subscription Identifier，S-TMSI)、AMFUE ID或者gNB UE ID等。

(2)第一业务识别信息，其中，所述第一业务识别信息用于指示能够执行多UE协作传输的业务；即指示UE标识列表中的各个UE基于特定业务具有关联关系。其中，第一业务识别信息可以为业务标识(service ID，service code，QoS flow ID等)，也可以是业务特征，例如，满足QoS参数等于某个数值或者处于某一个特定区间的业务。

(3)具有关联关系的UE标识列表中的各个UE的属性。例如P-UE only,S-UE only，或者both P-UE and S-UE。

在该可能的实现方式中，核心网设备可以在以下至少之一的情况下，向RAN节点发送所述关联关系信息：

(1)所述核心网设备(CN)获知所述第一UE和所述第二UE均处于连接态；由于CN可以从RAN节点实时上报的信息中获取RAN节点下激活的连接态UE，因此CN可以将其中有关联关系的UE的关联关系信息都下发给RAN节点；

(2)所述核心网设备发现所述第一UE进入连接态，其中，所述第一UE与所述第二UE基于任意业务均具有关联关系；例如，当一个UE进入连接态之后，如果核心网设备发现该UE具有关联关系，则下发该UE的关联关系信息给该UE的服务RAN节点；

(3)所述核心网设备发现所述第一UE进入连接态且发起第一业务之后，其中，所述第一UE与所述第二UE基于目标业务具有关联关系，所述目标业务包括所述第一业务；例如，当一个UE进入连接态并发起业务之后，如果核心网设备发现基于该业务该UE具有关联关系，则下发该UE的关联关系信息给该UE的服务RAN节点；

(4)接收到所述RAN节点发送的第二请求，所述第二请求用于请求所述第一UE所关联的所有UE，或者，所述第二请求用于请求基于第二业务与所述第一UE具有关联关系的UE。即RAN节点主动向CN节点请求，例如，RAN节点根据需要，该需要可以是RAN节点自行判断，也可以是UE向RAN节点请求之后触发，向CN节点请求。其中，RAN节点可以请求所有其下UE的绑定关系，也可以是特定UE的绑定关系，也可以是特定UE的特定业务的绑定关系。

通过本申请实施例提供的技术方案，RAN节点可以在核心网设备的触发下，为第一UE和第二UE分别配置用于多UE协作传输的承载，从而可以实现第一UE与第二UE的协作传输。

(二)RAN节点自行确定

在该可能的实现方式中，所述RAN节点可以在确定满足第一条件的情况下，向第一UE发送第一配置信息。

可选地，第一条件包括但不限于以下至少之一：

(1)所述RAN节点从核心网获取到所述第一UE与所述第二UE的关联关系信息；例如，RAN节点被CN下发了UE之间的关联关系，因此获知了UE之间是可以或者需要进行协作传输(或聚合/备份/切换传输)；

(2)所述RAN节点作为所述第一UE的服务节点，确定具有关联关系的第一UE和第二UE处于连接态；例如，RAN节点作为UE的服务节点，当发现具有绑定关系的两个或者更多UE进入了连接态，具备建立协作/聚合/备份/切换传输的可行性；

(3)所述RAN节点作为所述第一UE的服务节点，确定所述第一UE的至少部分业务传输无法满足QoS需求或业务体验需求；所述RAN节点对所述第二UE进行寻呼，确定所述第二UE进入连接态；例如，RAN节点作为P-UE的服务节点，如果发现P-UE的一个或多个业务传输，无法满足QoS需求或者业务体验需求，可以主动的在所述RAN节点覆盖的范围内，进行对应S-UE的寻呼，使S-UE进入连接态，为P-UE进行协作/聚合/备份/切换传输；

(4)所述第一UE当前的至少部分业务具有支持多UE传输的特征。例如，-P-UE当前的业务，具有支持协作/聚合/备份/切换传输的特征。

在一个可能的实现方式中，为了确保第一UE与第二UE之间的通信，在所述RAN节点确定满足预定条件之后，向第一UE发送第一配置信息之前，所述方法还可以包括：所述RAN节点确定所述第一UE与所述第二UE之间的传输距离和/或链路情况满足多UE传输需求。例如，RAN节点可以根据定位或者归属小区等信息判断，也可以向第一UE进行问询得到所述第一UE与所述第二UE之间的传输距离和/或链路情况。

在满足上述前提之后，RAN可以确定以下至少之一：第一UE和第二UE之间有CN许可的关联关系、第一UE和第二UE位于同一个基站下，可以进行彼此通信、第一UE的业务具有建立多UE架构承载的特征。因此，RAN节点可以发起建立多UE架构的流程。例如，可以包括以下步骤：

步骤1、RAN节点向第二UE发送重配置消息，其中携带第二配置信息。

可选地，第二配置信息中可以包括：第一UE标识、和分叉承载(split bearer)的配置等，使得第二可以UE判断是否同意为该第一UE进行多UE协作传输架构的建立；

可选地，第二配置信息中还可以包括第二DRB标识，用于指示所述第二UE为所述第一UE进行多UE协作传输的业务承载，通过第二DRB标识，第二UE可以判断是否同意为第一UE的指定DRB(即与第二DRB标识对应的DRB)进行多UE协作传输。

步骤2，如果第二UE同意，则按照接收到的重配置消息指示完成配置，并向网络侧(即RAN节点)返回配置完成消息；

如果第二UE不同意，则流程结束。

步骤3，RAN节点向第一UE发送重配置消息，其中携带第一配置信息；

可选地，所述第一配置信息可以包括：第二UE标识、和承载架构信息及相关配置，便于第一UE获知是与第二UE建立了多UE传输架构，并按照接收到的重配置消息指示完成配置；

可选地，第一配置信息中还可以携带第三DRB-ID，用于指示为所述第一UE配置的多UE协作传输的业务承载。

步骤4，第一UE向网络侧返回配置完成消息。

之后，第一UE可以将(指定DRB ID)的数据包向第二UE进行发送，由第二UE向网络侧进行传输，下行传输也是类似的。

需要说明是的是，上述第二DRB ID和第三DRB ID的作用是使第二UE和第一UE获取分叉承载的关联关系：例如，对于某个DRB承载(承载标识为DRB ID 1)，其分裂出位于第一UE的区域设置标识符(LCID)1以及位于第二UE的LCID 2，则RAN节点在配置第一配置信息和第二配置信息时，可以通过以下方式配置关联：

(1)给第一UE的配置为DRB ID 1分裂到第一UE的LCID1和第二UE的LCID2(即第三DRB标识)，给第二UE配置LCID 2(即第二DRB标识)，第一UE和第二UE之间通过LCID2可以获知数据流都关联到DRB1上的；

(2)给第一UE配置DRB ID1关联第一UE的LCID(即第三DRB标识)1，给第二UE配置LCID2关联第一UE的DRB ID 1(即第二DRB标识)，第一UE和第二UE之间通过DRB ID 1，可以获知两个数据流都关联到同一个DRB1上。

在该可能的实现方式中，RAN节点也可以向第一UE询问是否进行多UE架构的建立，或者，向第一UE询问是否进行特定业务的多UE架构的建立，在接收到第一UE返回的肯定回答后，执行S210。例如，RAN节点可以在确定满足所述第一条件后，向第一UE进行询问。

其中，RAN节点还需要问询第二UE是否同意进行多UE架构或者基于特定业务的多UE架构的建立，待同意之后进行多UE架构或者特定业务多UE架构的配置，即进行多UE协作传输的承载配置。

通过该可能的实现方式，RAN节点可以在满足第一条件时，进行多UE协作传输的承载的配置或特定业务的多UE协作传输的承载的配置，从而可以实现多UE协作传输。

(三)第一UE请求

在该可能的实现方式中，在S210之前，该方法还可以包括：接收所述第一UE发送的第一请求，其中，所述第一请求用于请求所述第一配置信息，所述第一请求中携带有第二UE的标识。通过第一请求，第一UE向RAN节点请求与第二UE进行协作传输(或称为聚合传输、备份传输、切换传输)。

可选地，该第一请求中还可以携带第二业务识别信息，用于指示所述第一UE期望进行多UE协作传输的业务信息。

例如，所述第二业务识别信息包括但不限于以下至少之一：

(1)第一无线数据承载(DRB)标识；所述第一DRB标识可以为当前第一UE已经建立的数据无线承载的标识；

(2)服务标识(Service ID)；所述服务标识可以为当前第一UE正在传输或者后续将要传输的业务标识；

(3)QoS流标识(QoS flow ID)；所述QoS流标识可以为当前第一UE正在传输或者后续将要传输的QoS流标识。

(4)业务的特征信息。例如，QoS参数值等于某个值，或者位于一定的区间等，通过该特征信息，可以确定第一UE期望进行多UE协议传输的业务。

在一个可能的实现方式中，在接收第一UE发送的第一请求后，所述RAN节点向所述第二UE发送第二配置信息，其中，所述第二配置信息用于指示所述第二UE为所述第一UE进行多UE协作传输的承载配置。

其中，第二配置信息与上述可能实现方式中的第二配置信息相同，具体可以参见上述实现方式中的相关描述，在此不再赘述。

在一个可能的实现方式中，在所述RAN节点向所述第二UE发送第二配置信息之后，如果RAN节点接收所述第二UE发送的配置完成消息，则表明第二UE同意为所述第一UE进行多UE协作传输，则RAN节点向所述第一UE发送重配置消息，其中，所述重配置消息中携带所述第一配置信息。

其中，第一配置信息与上述可能实现方式中的第一配置信息相同，具体可以参见上述实现方式中的相关描述，在此不再赘述。

在具体应用中，在建立上述多UE协作传输之后，由于某种原因，例如，第一UE的业务传输发生变化、或者第二UE的业务传输发生变化、或者RAN节点的负荷等发生变化，需要修改或释放多UE协作传输的承载，因此，在建立上述多UE协作传输的承载之后，还可以需要修改或释放该承载。

因此，在一个可能的实现方式中，在S210之后，该方法还可以包括：

步骤1，所述RAN节点向所述第二UE发送第一重配置命令，其中，所述第一重配置信令中携带有所述第一UE的标识、重配置的第一承载标识以及重配置的内容信息，所述第一承载标识对应的承载为所述多UE协作传输的承载；

步骤2，所述RAN节点向所述第一UE发送第二重配置命令，其中，所述第二重配置信令中携带有所述第二UE的标识、所述第一承载标识以及所述重配置的内容信息。

需要说明的是，上述步骤1和步骤2在执行顺序上没有严格的顺序，RAN节点可以先向第二UE发送第一重配置命令，再向第一UE发送第二重配置命令，也可以先第一UE发送第二重配置命令，再向第二UE发送第一重配置命令，具体本申请实施例不作限定。例如，作为一种可选的方案，RAN节点可以在接收到第二UE发送的重配置完成消息之后，再向第一UE发送所述第二重配置命令。

可选地，在所述RAN节点向所述第一UE发送第二重配置命令之后，所述RAN节点还可以接收第一UE发送的重配置完成消息，从而使得RAN节点可以获知第一UE完成重配置。

在另一个可能的实现方式中，在S210之后，该方法还可以包括：

步骤1，所述RAN节点向所述第二UE发送第一释放命令，其中，所述第一释放命令中携带有所述第一UE的标识、释放的第二承载标识以及释放的内容信息，所述第二承载标识对应的承载为所述多UE协作传输的承载；

步骤2，所述RAN节点向所述第一UE发送第二释放命令，其中，所述第二释放命令中携带有所述第二UE的标识、所述第二承载标识以及释放的内容信息。

需要说明的是，上述步骤1和步骤2在执行顺序上没有严格的顺序，RAN节点可以先向第二UE发送第一释放命令，再向第一UE发送第二释放命令，也可以先第一UE发送第二释放命令，再向第二UE发送第一释放命令，具体本申请实施例不作限定。例如，作为一种可选的方案，RAN节点可以在接收到第二UE发送的释放完成消息之后，再向第一UE发送所述第二释放命令。

可选地，在所述RAN节点向所述第一UE发送第二释放命令之后，所述RAN节点还可以接收第一UE发送的释放完成消息，从而使得RAN节点可以获知第一UE完成释放。

由于多UE架构是在RAN节点、第一UE以及第二UE之间建立的联合传输架构，因此RAN节点、第一UE以及第二UE都有可能对该联合传输架构(即上述的多UE架构，或多UE传输架构，或多UE协作传输架构)提出修改。例如，第一UE或者第二UE可以向网络进行请求，当网络同意之后，来执行修改的流程。

因此，在一个可能的实现方式中，在所述RAN节点向所述第二UE发送第一重配置命令之前，所述方法还包括：接收所述第一UE或所述第二UE发送的修改请求，其中，所述修改请求用于请求修改所述第一承载标识对应的承载。

或者，在所述RAN节点向所述第二UE发送第一释放命令之前，所述方法还包括：接收所述第一UE或所述第二UE发送的释放请求，其中，所述释放请求用于请求释放所述第二承载标识对应的承载。

当然，并不限于此，RAN节点作为集中控制实体，具有直接的决策权，例如当RAN节点负荷较高，不能支持这种多UE传输架构时，则RAN节点可以修改一部分或者全部的多UE协作传输的承载。再例如当UE的业务结束时，RAN节点可以直接释放多UE协作传输的承载。

在多UE架构承载完成了修改或者释放，后续不再使用，或者使用新的配置进行传输。

图4示出本申请实施例提供的多UE协作传输的配置方法的一种流程图，该方法400可以由核心网设备执行。换言之，所述方法可以由安装在核心网设备上的软件或硬件来执行。如图4所示，该方法可以包括以下步骤。

S410，核心网设备向RAN节点发送关联关系信息，其中，所述关联关系信息用于指示第一UE与第二UE具有关联关系，所述第一UE和所述第二UE具有建立多UE协作传输的能力。

本申请实施例提供的方法400是与方法200对应的核心网侧的执行流程，具有与方法200涉及核心网设备相关的可能实现方式的对应实现方式，具体可以参见方法200的描述，下面只能涉及核心网设备的步骤的可能实现方式进行说明。

在一个可能的实现方式中，在核心网设备向RAN节点发送关联关系信息之前，所述方法还包括以下至少之一：

(1)所述核心网设备获知所述第一UE和所述第二UE均处于连接态；

(2)所述核心网设备发现所述第一UE进入连接态，其中，所述第一UE与所述第二UE基于任意业务均具有关联关系；

(3)所述核心网设备发现所述第一UE进入连接态且发起第一业务之后，其中，所述第一UE与所述第二UE基于目标业务具有关联关系，所述目标业务包括所述第一业务；

(4)接收到所述RAN节点发送的第二请求，所述第二请求用于请求所述第一UE所关联的所有UE，或者，所述第二请求用于请求基于第二业务与所述第一UE具有关联关系的UE。

可选地，核心网设备向RAN节点发送的关联关系信息可以包括以下至少之一：

(1)具有关联关系的UE标识列表，其中，所述UE标识列表中包括所述第一UE的标识和所述第二UE的标识；

(2)第一业务识别信息，其中，所述第一业务识别信息用于指示能够执行多UE协作传输的业务；例如，第一业务识别信息可以包括DRB ID、Service ID、QoS flow ID或者业务的特征信息等。

(3)具有关联关系的UE标识列表中指示的各个UE的属性。

在一个可能的实现方式中，在核心网设备向RAN节点发送关联关系信息之前，所述方法还包括：所述核心网设备获取所述第一UE签约的关联关系信息或所述第一UE预先设置的关联关系信息。

例如，签约或预先设置的关联关系信息可以包括以下之一：

(1)一组具有绑定关系的UE列表，列表中的UE彼此之间可以互相协作传输，每个UE根据需要决定作为P-UE或者S-UE；

(2)一组具有绑定关系的UE列表，其中每个UE的属性P-UE还是S-UE是提前预设的；

(3)一组具有绑定关系的UE列表，其中每个UE可以支持的属性，例如P-UE only，S-UE only或者both P-UE and S-UE是设定的。

其中，上述绑定关系可以是基于UE粒度，即这些UE之间的任何业务都可以进行多UE架构建立和传输，也可以进一步基于特定业务的粒度，即在UE列表的基础上，限制这些UE之间，只能针对什么样的业务进行多UE架构建立和传输，其中业务限制可以是业务标识，业务的具体QoS参数，业务的具体QoS参数的范围等。

通过本申请实施例提供的技术方案，核心网设备可以触发RAN节点进行多UE协作传输的承载配置，从而使得第一UE与第二UE之间可以进行多UE协作传输，保障了UE的业务体验和系统效率。

图5示出本申请实施例提供的多UE协作传输的配置方法的一种流程图，该方法500可以由第一UE执行。换言之，所述方法可以由安装在第一UE上的软件或硬件来执行。如图5所示，该方法可以包括以下步骤。

S510，第一UE向RAN节点发送第一请求，其中，所述第一请求用于请求所述RAN节点为所述第一UE配置多UE协作传输的承载，所述第一请求中携带有第二UE的标识。

本申请实施例提供的方法500是与方法200对应的第一UE的执行流程，具有与方法200涉及第一UE相关的可能实现方式的对应实现方式，具体可以参见方法200的描述，下面只能涉及第一UE执行的步骤的可能实现方式进行说明。

在一个可能的实现方式中，在第一UE向RAN节点发送第一请求之前，所述方法还可以包括：

步骤1，所述第一UE通过UE之间的接口，发送第三请求，其中，所述第三请求用于请求为所述第一UE进行聚合传输；

步骤2，所述第一UE接收所述第二UE反馈的确认消息，其中，所述确认消息中携带的所述第二UE的标识。

通过该可能的实现方式，第一UE可以与第二UE进行交互，获取第二UE的标识。

在一个可能的实现方式中，第一UE发送的所述第一请求中还携带有第二业务识别信息，所述第二业务识别信息用于指示所述第一UE期望进行多UE协作传输的业务信息。

可选地，所述第二业务识别信息包括但不限于以下至少之一：

(1)第一DRB标识；

(2)服务标识；

(3)QoS流标识；

(4)业务的特征信息。

在一个可能的实现方式中，在第一UE向RAN节点发送第一请求之后，所述方法还可以包括：

步骤1，所述第一UE接收所述RAN节点发送的重配置消息，其中，所述重配置消息中携带第一配置信息，所述第一配置信息用于为所述第一UE配置多UE协作传输的承载；

步骤2，所述第一UE应用所述第一配置信息进行重配置。

例如，RAN节点可以在接收到第一请求之后，根据第一请求，对第二UE进行重配置完成之后，向第一UE发送上述重配置消息，为第一UE配置多UE传输架构的承载。

可选地，所述第一配置信息包括：所述第二UE标识、以及承载架构的配置信息。

可选地，所述第一配置信息还包括：第三DRB标识，用于指示为所述第一UE配置的多UE协作传输的业务承载。

在一个可能的实现方式，在所述第一UE接收所述RAN节点发送的重配置消息之后，所述方法还包括：

步骤1，接收所述RAN节点发送的第二重配置命令，其中，所述第二重配置信令中携带有所述第二UE的标识、重配置的第一承载标识以及所述重配置的内容信息，所述第一承载标识对应的承载为所述多UE协作传输的承载；

步骤2，执行所述第二重配置命令。

例如，RAN节点可以在当前网络状态不能支持一个或多个多UE协作传输时，发送所述第二重配置命令，对多UE协作传输承载进行修改。

或者，也可以是第一UE请求RAN节点对多UE协作传输进行修改，因此，在一个可能的实现方式中，在接收所述RAN节点发送的第二重配置命令之前，所述方法还可以包括：向所述RAN节点发送修改请求，其中，所述修改请求用于请求修改所述第一承载标识对应的承载。

在另一个可能的实现方式中，在所述第一UE接收所述RAN节点发送的重配置消息之后，所述方法还包括：

步骤1，接收所述RAN节点发送的第二释放命令，其中，所述第二释放命令中携带有所述第二UE的标识、释放的第二承载标识以及释放的内容信息，所述第二承载标识对应的承载为所述多UE协作传输的承载；

步骤2，执行所述第二释放命令，释放所述第二承载标识对应的承载。

例如，RAN节点可以在完成第一UE需要协作传输的业务之后，发送所述第二释放命令。

或者，RAN节点也可以是基于第一UE的请求，发送所述第二释放命令，因此，在一个可选的实现方式中，在接收所述RAN节点发送的第二释放命令之前，所述方法还可以包括：向所述RAN节点发送释放请求，其中，所述释放请求用于请求释放所述第二承载标识对应的承载。

通过本申请实施例提供的技术方案，第一UE可以在需要时，请求RAN节点进行多UE协作传输的承载配置，从而使得第一UE与第二UE之间可以进行多UE协作传输，保障了UE的业务体验和系统效率。

图6示出本申请实施例提供的多UE协作传输的响应方法的一种流程图，该方法600可以由第二UE执行。换言之，所述方法可以由安装在第二UE上的软件或硬件来执行。如图6所示，该方法可以包括以下步骤。

S610，第二UE接收RAN节点发送的第二配置信息，其中，所述第二配置信息用于指示所述第二UE为第一UE进行多UE协作传输的承载配置。

S612，在同意为所述第一UE进行多UE协作传输的情况下，所述第二UE应用所述第二配置信息，向所述RAN节点发送配置完成消息。

本申请实施例提供的方法600是与方法200对应的第二UE的执行流程，具有与方法200涉及第二UE相关的可能实现方式的对应实现方式，具体可以参见方法200的描述，下面只能涉及第二UE执行的步骤的可能实现方式进行说明。

在一个可能的实现方式中，所述第二配置信息包括：所述第一UE的标识、以及分叉承载的配置信息。

在一个可能的实现方式中，所述第二配置信息还包括：第二DRB标识，用于指示所述第二UE为所述第一UE进行多UE协作传输的业务承载。

在一个可能的实现方式中，在第二UE接收RAN节点发送的第二配置信息之前，所述方法还包括：

步骤1，所述第二UE接收所述第一UE发送的第三请求，其中，所述第三请求用于请求为所述第一UE进行聚合传输；

步骤2，所述第二UE向所述第一UE反馈确认消息，其中，所述确认消息中携带所述第二UE的标识。

在一个可能的实现方式中，在向所述RAN节点发送配置完成消息之后，所述方法还包括：

步骤1，接收所述RAN节点发送的第一重配置命令，其中，所述第一重配置信令中携带有所述第一UE的标识、重配置的第一承载标识以及所述重配置的内容信息，所述第一承载标识对应的承载为所述多UE协作传输的承载；

步骤2，执行所述第一重配置命令。

例如，RAN节点可以在业务传输或网络环境发生改变是，发送所述第一重配置命令，对多UE协作传输的承载进行修改。

或者，RAN节点也可以基于第二UE的请求，对多UE协作传输的承载进行修改，例如，第二UE本身的业务传输增加或减少，为第一UE协作传输的能力减少或增加，需要对多UE协作传输的承载进行修改，则可以向RAN节点发起请求。因此，在一个可能的实现方式中，在接收所述RAN节点发送的第一重配置命令之前，所述方法还包括：向所述RAN节点发送修改请求，其中，所述修改请求用于请求修改所述第一承载标识对应的承载。

在一个可能的实现方式，在向所述RAN节点发送配置完成消息之后，所述方法还包括：

步骤1，接收所述RAN节点发送的第一释放命令，其中，所述第一释放命令中携带有所述第一UE的标识、释放的第二承载标识以及释放的内容信息，所述第二承载标识对应的承载为所述多UE协作传输的承载；

步骤2，执行所述第一释放命令，释放所述第二承载标识对应的承载。

例如，RAN节点可以在第一UE请求协作传输的业务完成后，发送所述第一释放命令。

或者，RAN节点也可以基于第二UE的请求，对多UE协作传输的承载进行修改，例如，第二UE本身的业务传输增加，无法为第一UE进行协作传输，需要对多UE协作传输的承载进行释放，则可以向RAN节点发起请求。因此，在一个可能的实现方式中，在接收所述RAN节点发送的第一释放命令之前，所述方法还包括：向所述RAN节点发送释放请求，其中，所述释放请求用于请求释放所述第二承载标识对应的承载。

通过本申请实施例提供的技术方案，第二UE可以响应RAN节点进行多UE协作传输的承载配置，从而建立多UE协作传输承载，使得第一UE与第二UE之间可以进行多UE协作传输，保障了UE的业务体验和系统效率。

下面以第一UE(即主UE，P-UE)请求为例，对本申请实施例提供的技术方案进行说明。

图7示出本申请实施例提供的多UE协作传输的承载建立方法的一种流程示意图，如图7所示，该方法主要包括以下步骤。

S701，P-UE即有业务需要传输的UE，通过UE之间的接口，向自己周围的其它S-UE进行请求，例如，发送聚合(Aggregation)传输请求(reques)t，还可以为备份传输请求、切换传输请求等。通过该请求向S-UE请求一下是否能够为自己进行聚合传输。

其中，在该请求中，可以携带如下信息其中至少一种或者组合：

(1)P-UE的用户标识，该用户标识是为了识别P-UE，一方面是为了确认意愿和授信，另一个重要方面就是便于gNB对两个UE进行后续过程的标识和识别，标识可以是全球唯一标识、PLMN内唯一标识、服务基站/小区下的标识等，例如S-TMSI，C-RNTI等。

(2)P-UE自己的服务基站，携带服务基站的作用是为了将多UE架构尽量在一个基站下进行实现，避免因此引入基站之间的接口，复杂度和时延会高很多。

S702，S-UE向对应的服务基站发起RRC连接建立过程，并进行激活自己的安全模式指令(Security Mode Command，SMC)的过程。

其中，如果S-UE当前如果处于RRC Connected状态，则该步骤可以省略。通过该步骤，可以获取一个gNB可以识别的S-UE的UE标识，该标识可以是全球唯一标识、PLMN内唯一标识，服务基站/小区下的标识等，例如S-TMSI，C-RNTI等、

S703，S-UE如果同意为P-UE进行聚合/备份/切换传输，则可以向P-UE回复确认，并告知自己的UE标识。

S704，P-UE在获得S-UE同意或者获得其UE标识之后，向自己的服务基站上报请求进行多UE架构配置，并携带S-UE的UE标识，表明P-UE与指定的S-UE进行聚合/备份/切换传输。

其中，S704可以在省略S701-S703的情况下直接发起，只要P-UE和S-UE之间交互过，具有S-UE的用户标识即可。

S705，基站在接收到P-UE的请求之后，生成对应的配置，发送给指定的S-UE。

通过S705，可以征求S-UE的同意看其是否愿意为P-UE进行聚合/备份/切换传输。其中，基站发送给S-UE的配置信息中携带P-UE标识，指示配置的多UE架构的P-UE，便于S-UE进行当下的意愿判断以及后续的协同操作。

S706，S-UE同意之后，执行配置，并向gNB返回确认。

S707，gNB向P-UE进行多架构确认操作，可选的，gNB向P-UE发送的消息中还可以携带多UE架构的对应配置。

在上述的流程中，给出了P-UE和S-UE建立多UE架构的请求和相关信令流程的示意举例，因为在上述过程中没有指示任何的业务信息，只是针对两个UE进行了许可和配置，则可以理解这两个UE之间此时是可以建立任何的聚合/备份/切换的承载的。例如，可以将P-UE的所有承载，都配置成多UE架构传输；或者，可以由基站算法来决定，根据业务QoS等，对需要的P-UE的承载，进行多UE架构传输配置；又或者，可以由基站根据核心网下发的绑定信息，对许可的P-UE的承载，进行多UE架构传输配置。

图8示出本申请实施例提供的多UE协作传输的承载建立方法的另一流程示意图，如图8所示，该方法主要包括以下步骤。

S801，P-UE向网络发送多UE架构请求，该请求中可以携带S-UE的用户标识以及携带期望进行多UE架构传输的业务信息。

其中，该业务信息可以包括以下至少之一：

(1)DRB ID，当前P-UE已经建立的数据无线承载的标识；

(2)Service ID或者QoS flow ID，当前P-UE正在传输或者后续将要传输的业务标识，QoS流标识等；

(3)业务的特征，例如QoS参数值等于某个值，或者位于一定的区间等。

在S801之前，还可以执行方法700中的S701-S703。方法800与方法700的区别在于，方法800是基于特定业务进行多播架构建立的流程。

S802，基站向S-UE发送重配置信息，用于配置多UE架构相关的承载。

其中，基站向S-UE发送的重配置信息可以携带如下信息：

(1)P-UE的用户标识，便于S-UE对P-UE进行识别，是否愿意为其建立聚合/备份/切换承载，以及如果愿意则后续为协同工作时，互相标识；

(2)DRB ID，基站明确指明，为哪个承载进行聚合/备份/切换配置；

(3)RLC、MAC、PHY、LCID等信息，通过这些信息可以对为了聚合/备份/切换承载进行的S-UE侧的配置。

S803，S-UE如果同意，则按照配置进行准备，且向基站回复配置完成.

S804，基站向P-UE返回承载重配置确认，确定为请求的或者指定的承载DRB ID已经配置了相应的聚合/备份/切换的多UE架构配置.

后续，P-UE就可以将自己的该DRB ID的数据交给S-UE，由S-UE向gNB进行发送。

在上述方法700中所提到的聚合/备份/切换的多UE架构配置，主要指图3a所示的PDCP anchor架构、图3b所示的RLC anchor架构、以及图3c所示MAC anchor架构中的一个或多个。

当然除了上述举例的架构之外，也不排除将某一层，例如PDCP或者MAC的部分common function位于P-UE，而将split function位于S-UE，这样的架构也是可以工作的。

协议可能选定一种或者多种架构，如果仅选择了一种架构，则网络侧默认进行该架构相关的协议实体的配置即可。如果选择了两种或者以上的架构，则网络侧可以按需进行不同架构的选择和配置。

通过本申请实施例提供的上述方法，RAN侧可以对多个UE进行配置，使得UE在网络侧的控制之下能够多设备共同传输，保障了UE的业务体验和系统效率。

需要说明的是，本申请实施例提供的承载的配置方法，执行主体可以为承载的配置装置，或者，该承载的配置装置中的用于执承载的配置方法的控制模块。本申请实施例中以承载的配置装置执行承载的配置方法为例，说明本申请实施例提供的承载的配置装置。

图9示出本申请实施例提供的承载的配置装置的一种结构示意图，如图9所示，该装置900主要包括：第一获取模块901和第一收发模块902。

在本申请实施例中，第一获取模块901，用于获取第一UE的第一配置信息，其中，所述第一配置信息用于配置多UE协作传输的承载；第一收发模块902，用于向所述第一UE发送所述第一配置信息。

在一个可能的实现方式中，第一收发模块902还用于在向第一UE发送第一配置信息之前，接收核心网下发的关联关系信息，其中，所述关联关系信息用于指示所述第一UE与第二UE之间的关联关系。

在一个可能的实现方式中，所述关联关系信息包括以下至少之一：

具有关联关系的UE标识列表，其中，所述UE标识列表中包括所述第一UE的标识和所述第二UE的标识；

第一业务识别信息，其中，所述第一业务识别信息用于指示能够执行多UE协作传输的业务；

具有关联关系的UE标识列表中的各个UE的属性。

在一个可能的实现方式中，所述第一获取模块901还用于确定满足第一条件。

在一个可能的实现方式中，所述第一条件包括以下至少之一：

从核心网获取到所述第一UE与所述第二UE的关联关系信息；

作为所述第一UE的服务节点，确定具有关联关系的第一UE和第二UE处于连接态；

作为所述第一UE的服务节点，确定所述第一UE的至少部分业务传输无法满足服务质量QoS需求或业务体验需求；所述RAN节点对所述第二UE进行寻呼，确定所述第二UE进入连接态；

所述第一UE当前的至少部分业务具有支持多UE传输的特征。

在一个可能的实现方式中，第一获取模块901还用于在向第一UE发送第一配置信息之前，确定所述第一UE与所述第二UE之间的传输距离和/或链路情况满足多UE传输需求。

在一个可能的实现方式中，第一收发模块902还用于在向第一UE发送第一配置信息之前，向所述第二UE发送第二配置信息，其中，所述第二配置信息用于指示所述第二UE为所述第一UE进行多UE协作传输的承载配置；接收所述第二UE发送的配置完成消息。

在一个可能的实现方式中，第一收发模块902还用于在向第一UE发送第一配置信息之前，接收所述第一UE发送的第一请求，其中，所述第一请求用于请求所述第一配置信息，所述第一请求中携带有第二UE的标识。

在一个可能的实现方式中，所述第一请求中还携带有第二业务识别信息，用于指示所述第一UE期望进行多UE协作传输的业务信息。

在一个可能的实现方式中，所述第二业务识别信息包括以下至少之一：

第一无线数据承载DRB标识；

服务标识；

QoS流标识；

业务的特征信息。

在一个可能的实现方式中，第一收发模块902还用于在接收所述第一UE发送的第一请求之后，向所述第二UE发送第二配置信息，其中，所述第二配置信息用于指示所述第二UE为所述第一UE进行多UE协作传输的承载配置。

在一个可能的实现方式中，所述第二配置信息包括：所述第一UE的标识、以及分叉承载的配置信息。

在一个可能的实现方式中，所述第二配置信息还包括：第二DRB标识，用于指示所述第二UE为所述第一UE进行多UE协作传输的业务承载。

在一个可能的实现方式中，第一收发模块902还用于在向所述第二UE发送第二配置信息之后，接收所述第二UE发送的配置完成消息；向所述第一UE发送重配置消息，其中，所述重配置消息中携带所述第一配置信息。

在一个可能的实现方式中，所述第一配置信息包括：

所述第二UE的标识、以及承载架构的配置信息。

在一个可能的实现方式中，所述第一配置信息还包括：第三DRB标识，用于指示为所述第一UE配置的多UE协作传输的业务承载。

在一个可能的实现方式中，第一收发模块902还用于在向第一用户设备UE发送第一配置信息之后，向所述第二UE发送第一重配置命令，其中，所述第一重配置信令中携带有所述第一UE的标识、重配置的第一承载标识以及重配置的内容信息，所述第一承载标识对应的承载为所述多UE协作传输的承载；向所述第一UE发送第二重配置命令，其中，所述第二重配置信令中携带有所述第二UE的标识、所述第一承载标识以及所述重配置的内容信息。

在一个可能的实现方式中，第一收发模块902还用于在向所述第二UE发送第一重配置命令之前，接收所述第一UE或所述第二UE发送的修改请求，其中，所述修改请求用于请求修改所述第一承载标识对应的承载。

在一个可能的实现方式中，第一收发模块902还用于在向第一用户设备UE发送第一配置信息之后，向所述第二UE发送第一释放命令，其中，所述第一释放命令中携带有所述第一UE的标识、释放的第二承载标识以及释放的内容信息，所述第二承载标识对应的承载为所述多UE协作传输的承载；向所述第一UE发送第二释放命令，其中，所述第二释放命令中携带有所述第二UE的标识、所述第二承载标识以及释放的内容信息。

在一个可能的实现方式中，第一收发模块902还用于在向所述第二UE发送第一释放命令之前，接收所述第一UE或所述第二UE发送的释放请求，其中，所述释放请求用于请求释放所述第二承载标识对应的承载。

本申请实施例中的承载的配置装置可以是装置，也可以是网络侧设备中的部件、集成电路、或芯片。该装置可以是基站，也可以是CU，本申请实施例不作具体限定。

本申请实施例中的承载的配置装置可以为具有操作系统的装置。该操作系统可以为安卓(Android)操作系统，可以为ios操作系统，还可以为其他可能的操作系统，本申请实施例不作具体限定。

本申请实施例提供的承载的配置装置能够实现图2至图8的方法实施例中RAN节点实现的各个过程，并达到相同的技术效果，为避免重复，这里不再赘述。

图10示出本申请实施例提供的多UE协作传输的配置装置的一种结构示意图，如图10所示，该装置主要包括：第二获取模块1001和第二收发模块1002。

基本申请实施例中，第二获取模块1001，用于获取关联关系信息，其中，所述关联关系信息用于指示第一UE与第二UE具有关联关系，所述第一UE和所述第二UE具有建立多UE协作传输的能力；第二收发模块1002，用于向RAN节点发送所述关联关系。

在一个可能的实现方式中，第二收发模块1002还用于在向RAN节点发送关联关系信息之前，执行以下至少之一：

获知所述第一UE和所述第二UE均处于连接态；

发现所述第一UE进入连接态，其中，所述第一UE与所述第二UE基于任意业务均具有关联关系；

发现所述第一UE进入连接态且发起第一业务之后，其中，所述第一UE与所述第二UE基于目标业务具有关联关系，所述目标业务包括所述第一业务；

接收到所述RAN节点发送的第二请求，所述第二请求用于请求所述第一UE所关联的所有UE，或者，所述第二请求用于请求基于第二业务与所述第一UE具有关联关系的UE。

在一个可能的实现方式中，所述关联关系信息包括以下至少之一：

具有关联关系的UE标识列表，其中，所述UE标识列表中包括所述第一UE的标识和所述第二UE的标识；

第一业务识别信息，其中，所述第一业务识别信息用于指示能够执行多UE协作传输的业务；

具有关联关系的UE标识列表中指示的各个UE的属性。

在一个可能的实现方式中，第二获取模块1001还用于在向RAN节点发送关联关系信息之前，获取所述第一UE签约的关联关系信息或所述第一UE预先设置的关联关系信息。

本申请实施例中的多UE协作传输的配置装置可以是装置，也可以是网络侧设备中的部件、集成电路、或芯片。该装置可以是基站，也可以是CU，本申请实施例不作具体限定。

本申请实施例中的多UE协作传输的配置装置可以为具有操作系统的装置。该操作系统可以为安卓(Android)操作系统，可以为ios操作系统，还可以为其他可能的操作系统，本申请实施例不作具体限定。

本申请实施例提供的多UE协作传输的配置装置能够实现图2至图8的方法实施例中核心网设备或核心网实现的各个过程，并达到相同的技术效果，为避免重复，这里不再赘述。

图11示出本申请实施例提供的多UE协作传输的请求装置的一种结构示意图，如图11所示，该装置1100主要包括：第一确定模块1101和第三收发模块1102。

在本申请实施例中，第一确定模块1101，用于确定第一UE需要执行多UE协作传输；第三收发模块1102，用于向RAN节点发送第一请求，其中，所述第一请求用于请求所述RAN节点为所述第一UE配置多UE协作传输的承载，所述第一请求中携带有第二UE的标识。

在一个可能的实现方式中，第三收发模块1102还用于在向RAN节点发送第一请求之前，通过UE之间的接口，发送第三请求，其中，所述第三请求用于请求为所述第一UE进行聚合传输；接收所述第二UE反馈的确认消息，其中，所述确认消息中携带的所述第二UE的标识。

在一个可能的实现方式中，第三收发模块1102还用于在向RAN节点发送第一请求之后，接收所述RAN节点发送的重配置消息，其中，所述重配置消息中携带第一配置信息，所述第一配置信息用于为所述第一UE配置多UE协作传输的承载；应用所述第一配置信息进行重配置。

在一个可能的实现方式中，所述第一配置信息包括：所述第二UE标识、以及承载架构的配置信息。

在一个可能的实现方式中，所述第一配置信息还包括：第三DRB标识，用于指示为所述第一UE配置的多UE协作传输的业务承载。

在一个可能的实现方式中，第三收发模块1102还用于在接收所述RAN节点发送的重配置消息之后，接收所述RAN节点发送的第二重配置命令，其中，所述第二重配置信令中携带有所述第二UE的标识、重配置的第一承载标识以及所述重配置的内容信息，所述第一承载标识对应的承载为所述多UE协作传输的承载；执行所述第二重配置命令。

在一个可能的实现方式中，第三收发模块1102还用于在接收所述RAN节点发送的第二重配置命令之前，向所述RAN节点发送修改请求，其中，所述修改请求用于请求修改所述第一承载标识对应的承载。

在一个可能的实现方式中，第三收发模块1102还用于在接收所述RAN节点发送的重配置消息之后，接收所述RAN节点发送的第二释放命令，其中，所述第二释放命令中携带有所述第二UE的标识、释放的第二承载标识以及释放的内容信息，所述第二承载标识对应的承载为所述多UE协作传输的承载；执行所述第二释放命令，释放所述第二承载标识对应的承载。

在一个可能的实现方式中，第三收发模块1102还用于在接收所述RAN节点发送的第二释放命令之前，向所述RAN节点发送释放请求，其中，所述释放请求用于请求释放所述第二承载标识对应的承载。

在一个可能的实现方式中，所述第一请求中还携带有第二业务识别信息，所述第二业务识别信息用于指示所述第一UE期望进行多UE协作传输的业务信息。

在一个可能的实现方式中，所述第二业务识别信息包括以下至少之一：

第一无线数据承载DRB标识；

服务标识；

QoS流标识；

业务的特征信息。

本申请实施例中的多UE协作传输的请求装置可以是装置，也可以是终端设备中的部件、集成电路、或芯片。该装置可以是基站，也可以是CU，本申请实施例不作具体限定。

本申请实施例中的多UE协作传输的请求装置可以为具有操作系统的装置。该操作系统可以为安卓(Android)操作系统，可以为ios操作系统，还可以为其他可能的操作系统，本申请实施例不作具体限定。

本申请实施例提供的多UE协作传输的请求装置能够实现图2至图8的方法实施例中第一UE实现的各个过程，并达到相同的技术效果，为避免重复，这里不再赘述。

图12示出本申请实施例提供的多UE协作传输的响应装置的一种结构示意图，如图12所示，该装置1200主要包括：第四收发模块1201和第二确定模块1202。

在本申请实施例中，第四收发模块1201，用于接收RAN节点发送的第二配置信息，其中，所述第二配置信息用于指示所述第二UE为第一UE进行多UE协作传输的承载配置；第二确定模块1202，用于确定是否同意为所述第一UE进行多UE协作传输；所述第四收发模块1201还用于在同意为所述第一UE进行多UE协作传输的情况下，所述第二UE应用所述第二配置信息，向所述RAN节点发送配置完成消息。

在一个可能的实现方式中，所述第二配置信息包括：所述第一UE的标识、以及分叉承载的配置信息。

在一个可能的实现方式中，所述第二配置信息还包括：第二DRB标识，用于指示所述第二UE为所述第一UE进行多UE协作传输的业务承载。

在一个可能的实现方式中，第四收发模块1201还用于在接收RAN节点发送的第二配置信息之前，接收所述第一UE发送的第三请求，其中，所述第三请求用于请求为所述第一UE进行聚合传输；向所述第一UE反馈确认消息，其中，所述确认消息中携带所述第二UE的标识。

在一个可能的实现方式中，第四收发模块1201还用于在向所述RAN节点发送配置完成消息之后，接收所述RAN节点发送的第一重配置命令，其中，所述第一重配置信令中携带有所述第一UE的标识、重配置的第一承载标识以及所述重配置的内容信息，所述第一承载标识对应的承载为所述多UE协作传输的承载；执行所述第一重配置命令。

在一个可能的实现方式中，第四收发模块1201还用于在接收所述RAN节点发送的第一重配置命令之前，向所述RAN节点发送修改请求，其中，所述修改请求用于请求修改所述第一承载标识对应的承载。

在一个可能的实现方式中，第四收发模块1201还用于在向所述RAN节点发送配置完成消息之后，接收所述RAN节点发送的第一释放命令，其中，所述第一释放命令中携带有所述第一UE的标识、释放的第二承载标识以及释放的内容信息，所述第二承载标识对应的承载为所述多UE协作传输的承载；执行所述第一释放命令，释放所述第二承载标识对应的承载。

在一个可能的实现方式中，第四收发模块1201还用于在接收所述RAN节点发送的第一释放命令之前，向所述RAN节点发送释放请求，其中，所述释放请求用于请求释放所述第二承载标识对应的承载。

本申请实施例中的多UE协作传输的响应可以是装置，也可以是终端设备中的部件、集成电路、或芯片。该装置可以是基站，也可以是CU，本申请实施例不作具体限定。

本申请实施例中的多UE协作传输的响应可以为具有操作系统的装置。该操作系统可以为安卓(Android)操作系统，可以为ios操作系统，还可以为其他可能的操作系统，本申请实施例不作具体限定。

本申请实施例提供的多UE协作传输的响应能够实现图2至图8的方法实施例中第二UE实现的各个过程，并达到相同的技术效果，为避免重复，这里不再赘述。

可选的，如图13所示，本申请实施例还提供一种通信设备1300，包括处理器1301，存储器1302，存储在存储器1302上并可在所述处理器1301上运行的程序或指令，例如，该通信设备1300为终端时，该程序或指令被处理器1301执行时实现上述方法400实施例或方法500实施例的各个过程，且能达到相同的技术效果。该通信设备1300为网络侧设备时，该程序或指令被处理器1301执行时实现上述方法200实施例或方法300实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。

本申请实施例还提供一种终端，包括处理器和通信接口，处理器用于实现上述方法400实施例或方法500实施例的各个过程，通信接口用于与外部设备进行通信。该终端实施例是与上述终端侧方法实施例对应的，上述方法实施例的各个实施过程和实现方式均可适用于该终端实施例中，且能达到相同的技术效果。具体地，图14为实现本申请实施例的一种终端的硬件结构示意图。

该终端1400包括但不限于：射频单元1401、网络模块1402、音频输出单元1403、输入单元1404、传感器1405、显示单元1406、用户输入单元1407、接口单元1408、存储器1409、以及处理器1410等部件。

本领域技术人员可以理解，终端1400还可以包括给各个部件供电的电源(比如电池)，电源可以通过电源管理系统与处理器1410逻辑相连，从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。图14中示出的终端结构并不构成对终端的限定，终端可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置，在此不再赘述。

应理解的是，本申请实施例中，输入单元1404可以包括图形处理器(GraphicsProcessing Unit，GPU)14041和麦克风14042，图形处理器14041对在视频捕获模式或图像捕获模式中由图像捕获装置(如摄像头)获得的静态图片或视频的图像数据进行处理。显示单元1406可包括显示面板14061，可以采用液晶显示器、有机发光二极管等形式来配置显示面板14061。用户输入单元1407包括触控面板14071以及其他输入设备14072。触控面板14071，也称为触摸屏。触控面板14071可包括触摸检测装置和触摸控制器两个部分。其他输入设备14072可以包括但不限于物理键盘、功能键(比如音量控制按键、开关按键等)、轨迹球、鼠标、操作杆，在此不再赘述。

本申请实施例中，射频单元1401将来自网络侧设备的下行数据接收后，给处理器1410处理；另外，将上行的数据发送给网络侧设备。通常，射频单元1401包括但不限于天线、至少一个放大器、收发信机、耦合器、低噪声放大器、双工器等。

存储器1409可用于存储软件程序或指令以及各种数据。存储器1409可主要包括存储程序或指令区和存储数据区，其中，存储程序或指令区可存储操作系统、至少一个功能所需的应用程序或指令(比如声音播放功能、图像播放功能等)等。此外，存储器1409可以包括高速随机存取存储器，还可以包括非瞬态性存储器，其中，非瞬态性存储器可以是只读存储器(Read-OnlyMemory，ROM)、可编程只读存储器(ProgrammableROM，PROM)、可擦除可编程只读存储器(ErasablePROM，EPROM)、电可擦除可编程只读存储器(ElectricallyEPROM，EEPROM)或闪存。例如至少一个磁盘存储器件、闪存器件、或其他非瞬态性固态存储器件。

处理器1410可包括一个或多个处理单元；可选的，处理器1410可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统、用户界面和应用程序或指令等，调制解调处理器主要处理无线通信，如基带处理器。可以理解的是，上述调制解调处理器也可以不集成到处理器1410中。

其中，射频单元1401，用于向RAN节点发送第一请求，其中，所述第一请求用于请求所述RAN节点为所述第一UE配置多UE协作传输的承载，所述第一请求中携带有第二UE的标识。

或者，射频单元1401，用于接收RAN节点发送的第二配置信息，其中，所述第二配置信息用于指示所述第二UE为第一UE进行多UE协作传输的承载配置；在同意为所述第一UE进行多UE协作传输的情况下，所述第二UE应用所述第二配置信息，向所述RAN节点发送配置完成消息。

本申请实施例还提供一种网络侧设备，包括处理器和通信接口，处理器用于实现上述方法200实施例或方法300实施例的各个过程，通信接口用于与外部设备进行通信。该网络侧设备实施例是与上述网络侧设备方法实施例对应的，上述方法实施例的各个实施过程和实现方式均可适用于该网络侧设备实施例中，且能达到相同的技术效果。

具体地，本申请实施例还提供了一种网络侧设备。如图15所示，该网络设备1500包括：天线1501、射频装置1502、基带装置1503。天线1501与射频装置1502连接。在上行方向上，射频装置1502通过天线1501接收信息，将接收的信息发送给基带装置1503进行处理。在下行方向上，基带装置1503对要发送的信息进行处理，并发送给射频装置1502，射频装置1502对收到的信息进行处理后经过天线1501发送出去。

上述频带处理装置可以位于基带装置1503中，以上实施例中网络侧设备执行的方法可以在基带装置1503中实现，该基带装置1503包括处理器1504和存储器1505。

基带装置1503例如可以包括至少一个基带板，该基带板上设置有多个芯片，如图15所示，其中一个芯片例如为处理器1504，与存储器1505连接，以调用存储器1505中的程序，执行以上方法实施例中所示的网络设备操作。

该基带装置1503还可以包括网络接口1506，用于与射频装置1502交互信息，该接口例如为通用公共无线接口(common public radio interface，简称CPRI)。

具体地，本发明实施例的网络侧设备还包括：存储在存储器1505上并可在处理器1504上运行的指令或程序，处理器1504调用存储器1505中的指令或程序执行图9或图10所示各模块执行的方法，并达到相同的技术效果，为避免重复，故不在此赘述。

本申请实施例还提供一种可读存储介质，所述可读存储介质可以是易失性的，也可以是非易失性的，所述可读存储介质上存储有程序或指令，该程序或指令被处理器执行时实现上述方法200实施例的各个过程，或实现上述方法300实施例的各个过程，或实现上述方法400实施例的各个过程，或实现上述方法500实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。

其中，所述处理器为上述实施例中所述的终端中的处理器。所述可读存储介质，包括计算机可读存储介质，如计算机只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等。

本申请实施例另提供了一种芯片，所述芯片包括处理器和通信接口，所述通信接口和所述处理器耦合，所述处理器用于运行程序或指令，实现上述方法200实施例的各个过程，或实现上述方法300实施例的各个过程，或实现上述方法400实施例的各个过程，或实现上述方法500实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。

应理解，本申请实施例提到的芯片还可以称为系统级芯片，系统芯片，芯片系统或片上系统芯片等。

本申请实施例还提供了一种计算机程序/程序产品，所述计算机程序/程序产品被存储在非瞬态的存储介质中，所述计算机程序/程序产品被至少一个处理器执行以实现上述方法200实施例的各个过程，或实现上述方法300实施例的各个过程，或实现上述方法400实施例的各个过程，或实现上述方法500实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。此外，需要指出的是，本申请实施方式中的方法和装置的范围不限按示出或讨论的顺序来执行功能，还可包括根据所涉及的功能按基本同时的方式或按相反的顺序来执行功能，例如，可以按不同于所描述的次序来执行所描述的方法，并且还可以添加、省去、或组合各种步骤。另外，参照某些示例所描述的特征可在其他示例中被组合。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以计算机软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端(可以是手机，计算机，服务器，空调器，或者网络设备等)执行本申请各个实施例所述的方法。

上面结合附图对本申请的实施例进行了描述，但是本申请并不局限于上述的具体实施方式，上述的具体实施方式仅仅是示意性的，而不是限制性的，本领域的普通技术人员在本申请的启示下，在不脱离本申请宗旨和权利要求所保护的范围情况下，还可做出很多形式，均属于本申请的保护之内。