LOGICAL CHANNEL (LCH) SETTING METHOD, COMMUNICATION DEVICE, AND COMMUNICATION

Abstract

An embodiment of the present application discloses a logical channel (LCH) method and a communication device. In the method, a first data radio bearer (DRB) of a terminal corresponds to a first LCH, and the first LCH is for transmitting Packet Data Convergence Protocol (PDCP) data corresponding to a source donor node. The method includes: a first relay node generates configuration information for a second LCH corresponding to the first DRB, and the second LCH is for transmitting PDCP data corresponding to a target donor node, and the first relay node transmits the configuration information for the second LCH to the terminal. The source donor node and the target donor node are, respectively, a source donor node and a target donor node during a first relay node handover or a second relay node handover. The second relay node is a relay node on a link between the first relay node and the source donor node.

Description

[Technical field]

[0001] The present application relates to the field of communication technologies, and in particular to a data processing method, a communication device, and a communication system. [Background technology]

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims priority to Chinese Patent Application No. 202010757494.3, entitled “LOGICAL CHANNEL LCH CONFIGURATION METHOD, COMMUNICATION APPARATUS, AND COMMUNICATION SYSTEM,” filed with the State Intellectual Property Office of the People's Republic of China on July 31, 2020, which is hereby incorporated by reference in its entirety.

[0003] Compared with the fourth generation mobile communication system, the fifth generation (5G) mobile communication imposes more stringent requirements on various network performance indicators across the board. For example, the capacity indicator needs to be increased by 1000 times, wider coverage is required, and ultra-high reliability and ultra-low latency are required. Integrated access and backhaul systems (IAB) are emerging. In the IAB system, a large number of densely deployed nodes can provide adaptive and convenient access and backhaul services for terminals to expand coverage and meet the more stringent performance indicators of 5G.

[0004] In relay systems such as the IAB system, relay node handover may occur due to link quality, etc., and this relay node handover may cause service interruption for terminals, resulting in a significant reduction in user experience. Summary of the Invention

[0005] The embodiments of the present application provide a logical channel (LCH) setting method, a communication device, and a communication system for reducing the probability of a terminal experiencing service interruption during a relay node handover and ensuring service continuity for the terminal.

[0006] In the following, the downlink solutions provided in the embodiments of the present application are described with reference to the first to fourth aspects. It should be noted that the first to fourth aspects describe the downlink solutions from the perspective of separate network elements, and the contents of the first to fourth aspects may be cross-referenced.

[0007] A first aspect of an embodiment of the present application provides a logical channel LCH configuration method. The method may be implemented by a relay node or by a chip in a relay node. The following describes an example in which the method is implemented by a relay node. In the method, a first data radio bearer DRB of a terminal corresponds to a first LCH, and the first LCH is for transmitting Packet Data Convergence Protocol PDCP data corresponding to a source donor node. The method includes: a first relay node generates configuration information of a second LCH corresponding to the first DRB, and the second LCH is for transmitting PDCP data corresponding to a target donor node, and the first relay node transmits the configuration information of the second LCH to the terminal.

[0008] In this method, the first relay node is an access relay node of the terminal.

[0009] In this method, the source donor node is the source donor node during the first relay node handover, and the target donor node is the target donor node during the first relay node handover. In other words, the first relay node is the node where the handover occurs. Alternatively, the source donor node is the source donor node during the second relay node handover, the target donor node is the target donor node during the second relay node handover, and the second relay node is the relay node on the link between the first relay node and the source donor node. In other words, the second relay node is the node where the handover occurs.

[0010] In this method, a first DRB may correspond to a first LCH, and a second LCH may be configured for the first DRB. The first LCH is for transmitting data corresponding to a source donor node, and the second LCH is for transmitting data corresponding to a target donor node. The terminal may distinguish between data corresponding to the source donor node and data corresponding to the target donor node based on the different LCHs, ensure that the terminal processes data using correct configuration information, reduce the probability of service interruption, and improve service transmission continuity.

[0011] In a possible implementation, PDCP data corresponding to the source donor node is processed using PDCP setting information corresponding to the source donor node, and PDCP data corresponding to the target donor node is processed using PDCP setting information corresponding to the target donor node.

[0012] In a possible implementation, the PDCP data corresponding to the source donor node includes uplink PDCP data and / or downlink PDCP data corresponding to the source donor node, and the PDCP data corresponding to the target donor node includes uplink PDCP data and / or downlink PDCP data corresponding to the target donor node.

[0013] In a possible implementation, the method further includes: a first relay node receives first indication information from a source donor node or a target donor node, and the first relay node generates configuration information of a second LCH according to the first indication information.

[0014] Optionally, the first indication information is carried in a user equipment UE context modification request message received by the first relay node from the source donor node, or is carried in a UE context setup request message received by the first relay node from the target donor node.

[0015] In a possible implementation, after the first relay node receives the first message from the target donor node, the first relay node generates configuration information for the second LCH.

[0016] Optionally, the first message is a UE context setting request message.

[0017] In a possible implementation, the method further includes:

[0018] The first relay node sends second indication information to the terminal, the second indication information being for configuring a second LCH for the first DRB or for indicating the terminal to associate the first DRB with two LCHs.

[0019] Optionally, the second indication information may be generated by the first relay node and transmitted by the first relay node to the terminal. Alternatively, the second indication information may be generated by the target donor node, transmitted by the target donor node to the first relay node, and transmitted by the first relay node to the terminal.

[0020] In a possible implementation, the method further includes:

[0021] The first relay node sends third indication information to the terminal, which indicates the terminal to process the uplink data using PDCP configuration information corresponding to the target donor node. Optionally, the first relay node may be a node where handover occurs, or the second relay node is a node where handover occurs. The second relay node may send the third indication information to the first relay node, or the first relay node sends the third indication information to the terminal.

[0022] Optionally, the source donor node is a source donor node during the first relay node handover, and the target donor node is a target donor node during the first relay node handover. In other words, the first relay node is a node where handover occurs. The method includes: after the first relay node performs a physical uplink shared channel (PUSCH) switching or after a GTP tunnel is established between the first relay node and the target donor node, the first relay node sends a third indication information to the terminal.

[0023] In a possible implementation, the method further includes:

[0024] The first relay node sends fourth indication information to the target donor node, where the fourth indication information is used by the target donor node to indicate to the terminal to delete the first LCH.

[0025] Optionally, after the first relay node completes transmitting, to the terminal, PDCP data corresponding to the source donor node and buffered by the first relay node, the first relay node transmits a fourth indication information to the target donor node.

[0026] In a possible implementation, the source donor node is a source donor node during the first relay node handover, and the target donor node is a target donor node during the first relay node handover. The method further includes: the first relay node receives fifth indication information from the target donor node via the source donor node, and the first relay node maintains a connection with the source donor node during the handover based on the fifth indication information.

[0027] In a possible implementation, the method further includes: the first relay node sending capability indication information to the source donor node, and the source donor node sending the capability indication information to the target donor node, the capability indication information indicating that the first relay node supports a capability to maintain a connection with the source donor node during handover.

[0028] In a possible implementation, the first LCH corresponds to a GTP-U tunnel between the first relay node and a source donor node, and the second LCH corresponds to a GTP-U tunnel between the first relay node and a target donor node.

[0029] In a possible implementation, the method further includes: the first relay node receives information about a BAP address assigned by the target donor node via the source donor node, and the BAP address assigned to the first relay node by the target donor node is different from the BAP address assigned to the first relay node by the source donor node.

[0030] In this implementation, optionally, the PDCP data corresponding to the source donor node includes downlink PDCP data, where the downlink PDCP data corresponding to the source donor node includes a BAP address assigned by the source donor node to the first relay node, and the PDCP data corresponding to the target donor node includes downlink PDCP data, where the downlink PDCP data corresponding to the target donor node includes a BAP address assigned by the target donor node to the first relay node. In this way, the first relay node can determine whether the downlink data is from the source donor node or the target donor node based on the BAP address of the downlink data.

[0031] In a possible implementation, the method further includes: the first relay node receives sixth indication information from the target donor node, the sixth indication information indicating to the first relay node to initiate, activate, or enable a BAP layer dual configuration, the BAP layer dual configuration including a BAP configuration corresponding to the source donor node and a BAP configuration corresponding to the target donor node.

[0032] The first embodiment of the present application 2 The aspect provides a logical channel LCH configuration method. The method may be implemented by a terminal or by a chip in the terminal. The following description will be given using an example in which the method is implemented by the terminal. In the method, a first DRB of the terminal corresponds to a first LCH, and the first LCH is for transmitting PDCP data corresponding to a source donor node. The method includes: the terminal receives configuration information of a second LCH from a first relay node, and the second LCH is for transmitting PDCP data corresponding to a target donor node, and the terminal configures the second LCH for the first DRB.

[0033] In this method, the first relay node is an access relay node of the terminal.

[0034] In this method, the source donor node is the source donor node during the first relay node handover, and the target donor node is the target donor node during the first relay node handover. In other words, the first relay node is the node where the handover occurs. Alternatively, the source donor node is the source donor node during the second relay node handover, the target donor node is the target donor node during the second relay node handover, and the second relay node is the relay node on the link between the first relay node and the source donor node. In other words, the second relay node is the node where the handover occurs.

[0035] In a possible implementation, PDCP data corresponding to the source donor node is processed using PDCP setting information corresponding to the source donor node, and PDCP data corresponding to the target donor node is processed using PDCP setting information corresponding to the target donor node.

[0036] In a possible implementation, the PDCP data corresponding to the source donor node includes uplink PDCP data and / or downlink PDCP data corresponding to the source donor node, and the PDCP data corresponding to the target donor node includes uplink PDCP data and / or downlink PDCP data corresponding to the target donor node.

[0037] In a possible implementation, the method further includes: the terminal receives first indication information from the first relay node; and the terminal configures a second LCH for the first DRB including: the terminal configures a second LCH for the first DRB based on the first indication information to associate the first DRB with two LCHs.

[0038] In a possible implementation, the PDCP data corresponding to the source donor node includes downlink PDCP data, and the PDCP data corresponding to the target donor node includes downlink PDCP data. The method further includes:

[0039] The terminal receives downlink PDCP data corresponding to a source donor node and mapped to a first LCH from a first relay node, and the terminal processes the downlink PDCP data corresponding to the source donor node using PDCP configuration information corresponding to the source donor node; and / or The terminal receives downlink PDCP data corresponding to a target donor node and mapped to a second LCH from the first relay node, and the terminal processes the downlink PDCP data corresponding to the target donor node using PDCP configuration information corresponding to the target donor node.

[0040] In a possible implementation, the PDCP data corresponding to the source donor node includes uplink PDCP data, and the PDCP data corresponding to the target donor node includes uplink PDCP data. The method further includes:

[0041] The terminal processes uplink data using PDCP configuration information corresponding to the source donor node to obtain uplink PDCP data corresponding to the source donor node, maps the uplink PDCP data corresponding to the source donor node to a first LCH, and sends the uplink PDCP data corresponding to the source donor node and mapped to the first LCH to a first relay node; and / or The terminal processes uplink data using the PDCP setting information corresponding to the target donor node to obtain uplink PDCP data corresponding to the target donor node, maps the uplink PDCP data corresponding to the target donor node to a second LCH, and transmits the uplink PDCP data corresponding to the target donor node and mapped to the second LCH to the first relay node.

[0042] In a possible implementation, the PDCP data corresponding to the target donor node includes uplink PDCP data corresponding to the target donor node. The method further includes:

[0043] The terminal receives second indication information from the first relay node; The terminal processes the uplink data using the PDCP configuration information corresponding to the target donor node based on the second indication information, and obtains uplink PDCP data corresponding to the target donor node.

[0044] In a possible implementation, the PDCP data corresponding to the target donor node includes uplink PDCP data corresponding to the target donor node. The method further includes:

[0045] After receiving the configuration information of the second LCH from the target donor node via the first relay node, the terminal processes uplink data using the PDCP configuration information corresponding to the target donor node to obtain uplink PDCP data corresponding to the target donor node.

[0046] In a possible implementation, the method further includes: the terminal receives third indication information from the first relay node, and deletes the first LCH according to the third indication information.

[0047] A third aspect of an embodiment of the present application provides a BAP address allocation method. The method may be implemented by a source donor node or by a chip in the source donor node. The following description uses an example in which the method is implemented by the source donor node. The method includes: the source donor node sends a BAP address allocated to the access relay node by the source donor node to the target donor node.

[0048] In this method, the source donor node is the source donor node during the access relay node handover or during the intermediate relay node handover, and the target donor node is the target donor node during the access relay node handover or during the intermediate relay node handover. The intermediate relay node is connected to the access relay node. The relay node to which the handover occurs may be referred to as the transition relay node.

[0049] Optionally, the method further includes: the source donor node receives, from the target donor node, a BAP address assigned to the access relay node by the target donor node, and sends the BAP address to the access relay node.

[0050] In a possible implementation, the BAP address assigned to the access IAB node by the source donor node is different from the BAP address assigned to the access IAB node by the target donor node.

[0051] The source donor node and the target donor node assign different BAP addresses to the access relay node, so that after receiving downlink data, the access relay node can determine whether the downlink data is from the source donor node or the target donor node based on the BAP address carried in the downlink data, so that the downlink data can be processed with correct configuration information to ensure data continuity.

[0052] Optionally, the method further includes: the source donor node sends first indication information to the access relay node, whereby the access relay node generates configuration information of the second LCH. The first indication information may be carried in a UE context modification request message. Optionally, the access relay node is a relay node where the handover occurs. The method further includes: the source donor node receives second indication information from the target donor node and sends the second indication information to the access relay node. The second indication information indicates to the access relay node to maintain a connection with the source donor node during the handover.

[0053] Optionally, the access relay node is a relay node to which handover occurs. The method further includes: the source donor node receives capability indication information from the access relay node, the capability indication information indicating that the first relay node supports a capability to maintain a connection with the source donor node during handover, and the source donor node transmits the capability indication information to the target donor node.

[0054] A fourth aspect of the embodiment of the present application provides a BAP address allocation method. The method may be implemented by a target donor node or by a chip in the target donor node. The following description uses an example in which the method is implemented by the target donor node. The method includes: the target donor node receives a BAP address allocated to an access relay node by the target donor node from the source donor node.

[0055] In this method, the source donor node is the source donor node during the access relay node handover or during the intermediate relay node handover, and the target donor node is the target donor node during the access relay node handover or during the intermediate relay node handover. The intermediate relay node is connected to the access relay node. The relay node to which the handover occurs may be referred to as the transition relay node.

[0056] Optionally, the method further includes: the target donor node sends, to the access IAB node via the source donor node, a BAP address assigned to the access IAB node by the target donor node.

[0057] In a possible implementation, the BAP address assigned to the access IAB node by the source donor node is different from the BAP address assigned to the access IAB node by the target donor node.

[0058] In a possible implementation, the method further includes: the target donor node sends first indication information to the access relay node, whereby the access relay node generates configuration information of the second LCH. Optionally, the first indication information is carried in a UE context configuration request message.

[0059] In a possible implementation, the method further includes: the target donor node sends second indication information to the terminal via the access relay node, the second indication information being for configuring a second LCH for the first DRB or indicating the terminal to associate the first DRB with two LCHs.

[0060] In a possible implementation, the method further includes: the target donor node receives third indication information sent by the access relay node, the third indication information being used by the target donor node to indicate to the terminal to delete the first LCH.

[0061] In a possible implementation, the method further includes: the target donor node sending fourth indication information to the access relay node via the source donor node, the fourth indication information indicating to the access relay node to maintain a connection with the source donor node during the handover.

[0062] Optionally, the method includes: the target donor node receiving capability indication information from the access relay node via the source donor node, the capability indication information indicating that the access relay node supports a capability to maintain a connection with the source donor node during handover.

[0063] In a possible implementation, the method further includes: the target donor node sends fifth indication information to the access relay node, the fifth indication information indicating to the access relay node to initiate, activate or enable a dual configuration of the BAP layer, the dual configuration of the BAP layer including a BAP configuration corresponding to the source donor node and a BAP configuration corresponding to the target donor node.

[0064] One or more of the methods in the first to fourth aspects may be combined with each other. In addition, in the methods in each aspect, one or more of the multiple possible implementations may be combined with each other.

[0065] A fifth aspect of an embodiment of the present application provides a communication device, the communication device may be a terminal or a chip in the terminal, the communication device may be a relay node or a chip in the relay node, the communication device may be a target donor node or a chip in the target donor node, the communication device may be a source donor node or a chip in the source donor node. The communication device includes a processor, the processor is configured to execute computer programs or instructions to enable the communication device to perform the methods according to the first to fourth aspects.

[0066] Optionally, the communications device further comprises a memory. The processor is coupled to the memory, the memory configured to store computer programs or instructions, and the processor is configured to execute the computer programs or instructions in the memory.

[0067] Optionally, the communication device may further include a communication unit, which is configured to communicate with another device or another component in the communication device. For example, the communication device is a terminal and the communication unit is a transceiver. For example, the communication device is a chip in the terminal and the communication unit is an input / output circuit or an interface of the chip.

[0068] A sixth aspect of the embodiment of the present application provides a communication device, the communication device having a function of implementing the operation of a terminal, a relay node, a source donor node, or a target donor node in the aforementioned method aspects, and including corresponding means configured to perform the steps or functions described in the method aspects according to the first to sixth aspects, the steps or functions may be implemented by software, hardware, or a combination of hardware and software.

[0069] A seventh aspect of an embodiment of the present application provides a chip, the chip comprising a processor and an interface circuit, the interface circuit coupled to the processor, the processor configured to execute a computer program or instructions to implement a method according to any one of the first to fourth aspects, and the interface circuit configured to communicate with a module other than the chip.

[0070] An eighth aspect of an embodiment of the present application provides a computer storage medium, the computer storage medium storing a program for implementing a method according to any one of the first to fourth aspects, the program being executed on a wireless communication device to enable the wireless communication device to perform the method according to any one of the first to fourth aspects.

[0071] A ninth aspect of an embodiment of the present application provides a computer program product, the program product including a program which, when executed, performs a method according to any one of the first to fourth aspects.

[0072] A tenth aspect of the present application provides a communication system. The communication system includes one or more of the terminal, the relay node, the source donor node, and the target donor node in the methods of the first to fourth aspects. Optionally, the communication system may further include a core network element. Optionally, the core network element is connected to the source donor node and the target donor node. [Brief description of the drawings]

[0073] In order to more clearly describe the technical solutions in the embodiments or background of the present application, the following describes the accompanying drawings for illustrating the embodiments or background of the present application. [Figure 1] 1 is a schematic diagram of a mobile communication system 100 according to an embodiment of the present application. [Diagram 2] 2 is a schematic diagram of an IAB network 200 according to an embodiment of the present application. [Diagram 3] FIG. 2 is a schematic diagram of a CU-DU split architecture according to an embodiment of the present application; [Figure 4] FIG. 2 is a schematic diagram of a control plane protocol stack in a CU-DU split architecture according to an embodiment of the present application; [Diagram 5] FIG. 2 is a schematic diagram of a user plane protocol stack in a CU-DU split architecture according to an embodiment of the present application; [Figure 6] FIG. 2 is a schematic diagram of a control plane protocol stack in an IAB network according to an embodiment of the present application. [Figure 7] FIG. 2 is a schematic diagram of a user plane protocol stack in an IAB network according to an embodiment of the present application; [Figure 8] FIG. 1 is a schematic diagram of a DAPS according to an embodiment of the present application. [Figure 9A] 4 is a schematic flowchart of a DAPS-based handover in the case of a single air interface according to an embodiment of the present application; [Figure 9B] 4 is a schematic flowchart of a DAPS-based handover in the case of a single air interface according to an embodiment of the present application; [Figure 10] FIG. 2 is a schematic diagram of a relay node handover according to an embodiment of the present application; [Figure 11] FIG. 2 is a schematic diagram of a donor-CU handover according to an embodiment of the present application; [Figure 12] FIG. 2 is a schematic diagram of a dual LCH user plane protocol stack according to an embodiment of the present application. [Figure 13] 1 is a schematic flowchart of an LCH configuration method according to an embodiment of the present application; [Figure 14] 1 is a flowchart of an indication method according to an embodiment of the present application. [Figure 15] 2 is a flowchart of an LCH deletion method according to an embodiment of the present application. [Figure 16] 1 is a flowchart of an indication method according to an embodiment of the present application. [Figure 17A] FIG. 2 is a schematic diagram of a donor-to-node handover method according to an embodiment of the present application; [Figure 17B] FIG. 2 is a schematic diagram of a donor-to-node handover method according to an embodiment of the present application; [Figure 17C] FIG. 2 is a schematic diagram of a donor-to-node handover method according to an embodiment of the present application; [Figure 17D] FIG. 2 is a schematic diagram of a donor-to-node handover method according to an embodiment of the present application; [Figure 17E] FIG. 2 is a schematic diagram of a donor-to-node handover method according to an embodiment of the present application; [Figure 18A] FIG. 13 is a schematic diagram of another donor-to-node handover method according to an embodiment of the present application; [Figure 18B] FIG. 13 is a schematic diagram of another donor-to-node handover method according to an embodiment of the present application; [Figure 18C] FIG. 13 is a schematic diagram of another donor-to-node handover method according to an embodiment of the present application; [Figure 18D] FIG. 13 is a schematic diagram of another donor-to-node handover method according to an embodiment of the present application; [Figure 19] 1 is a schematic diagram of a structure of a terminal according to an embodiment of the present application; [Figure 20] 1 is a schematic diagram of the structure of a communication device according to an embodiment of the present application; [Figure 21] 1 is a schematic diagram of the structure of an access network device according to an embodiment of the present application; [Figure 22] 1 is a schematic diagram of the structure of a communication device according to an embodiment of the present application; DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0074] Hereinafter, embodiments of the present application will be described with reference to the accompanying drawings of embodiments of the present application.

[0075] 1 is a schematic diagram of an architecture of a communication system 100 according to an embodiment of the present application. The communication system 100 includes at least one terminal (e.g., a terminal 110 and a terminal 120), at least one relay node (RN) 130, at least one access network device 140, and at least one core network device 150. The terminals 110 and 120 are connected to the access network device 140, or the terminals 110 and 120 are connected to the access network device 140 through the relay node 130. The relay node 130 is connected to the access network device 140, or the relay node 130 is connected to the access network device 140 through another relay node. The access network device 140 is wired to the core network device 150. The terminals 110 and 120, the relay node 130, the access network device 140, and the core network device 150 can be connected wirelessly or wired. This is not limited in the present application.

[0076] The communication system provided in this application may be, for example, a long term evolution (LTE) system supporting 4G access technology, a new radio (NR) system supporting 5G access technology, any cellular system related to the 3rd generation partnership project (3GPP), a wireless fidelity (Wi-Fi) system, a worldwide interoperability for microwave access (WiMAX) system, a multi-radio access technology (Radio Access Technology (RAT) system, or a system using other future-oriented communication technologies. In this application, a terminal is a device having a radio transceiver function. The terminal may be located on land, including indoor or outdoor terminals, handheld terminals, wearable terminals, or vehicle-mounted terminals, may be located on water (e.g., on a ship), or may be located in the air (e.g., on a drone, airplane, balloon, and satellite). The terminal may be a mobile phone, a tablet, a computer having a wireless transceiver function, a virtual reality (VR) terminal device, an augmented reality (AR) terminal device, a wireless terminal in industrial control, a wireless terminal in self driving, a wireless terminal in remote medical, a wireless terminal in a smart grid, a wireless terminal in transportation safety, a wireless terminal in a smart city, a wireless terminal in a smart home, etc. Application scenarios are not limited in the embodiments of this application.A terminal may also be referred to as a terminal device, user equipment (UE), an access terminal device, a station, a UE unit, a UE station, a mobile station, a remote station, a remote terminal device, a mobile device, a UE terminal device, a terminal device, a wireless communication device, a UE agent, a UE equipment, or some other suitable terminology. A terminal may be fixed or mobile.

[0077] An access network device may be a device on the access network side and configured to support terminals in accessing a communication system. An access network device may be referred to as a base station (BS), for example, an evolved NodeB (eNB) in a communication system supporting 4G access technology, a next-generation NodeB (gNB) in a communication system supporting 5G access technology, a transmission reception point (TRP), a relay node (TRP), an access point (AP), an access node in a Wi-Fi system, or a wireless backhaul node. Alternatively, an access network device may be referred to as a donor node, an IAB donor, a donor IAB, a donor, a donor gNB (DgNB), etc. A base station may be a macro base station, a micro base station, a pico base station, a small cell, a relay station, etc. Multiple base stations may support the aforementioned networks using the same technology or different technologies. A base station may include one or more common or non-common site transmission reception points (TRPs). An access network device may alternatively be a radio controller, a central unit (CU), and / or a distributed unit (DU) in a cloud radio access network (CRAN) scenario. An access network device may alternatively be a server, a wearable device, an in-vehicle device, etc. In the following, an example in which an access network device is a base station is used for explanation. Multiple access network devices in a communication system may be the same type of base station or different types of base stations. A base station may communicate with a terminal or communicate with a terminal device via a relay station. A terminal may communicate with multiple base stations using different technologies.For example, the terminal may communicate with a base station supporting an LTE network, may communicate with a base station supporting a 5G network, or may support dual connectivity with a base station in an LTE network and a base station in a 5G network.

[0078] A core network device may be connected to one or more access network devices and may provide one or more functions of session management, access authentication, Internet Protocol (IP) address allocation, and data transmission to terminals in the system. For example, a core network device may be a mobility management entity (MME) or a serving gateway (SGW) in a communication system supporting 4G access technology, or an Access and Mobility Management Function (AMF) network element or a User Plane Function (UPF) network element in a communication system supporting 5G access technology. A core network device may alternatively be referred to as a core network element.

[0079] A relay node may be a node that provides wireless access services and / or wireless backhaul services. A wireless access service is a data and / or signaling access service provided via a wireless access link, and a wireless backhaul service is a data and / or signaling backhaul service provided via a wireless backhaul link. A relay node is configured to forward data and / or signaling between a terminal and an access network device. In one aspect, a relay node provides wireless access services to a terminal via an access link (AL). In another aspect, a relay node is connected to an access network device via a one-hop or multi-hop backhaul link (BL).

[0080] A relay node may have different names in different communication systems. For example, a relay node may be called a wireless backhaul node or a wireless backhaul device. For example, in a 5G system, a relay node may be called an integrated access and backhaul node (IAB node). Certainly, in future communication systems, a relay node may alternatively have different names. This is not limited herein.

[0081] Figure 2 is a schematic diagram of an integrated access and backhaul (IAB) network 200 according to an embodiment of the present application. Figure 2 is an application scenario of the communication system 100 shown in Figure 1. In the following, the terminal, relay node and access network device of Figure 1 will be further described with reference to Figure 2.

[0082] In FIG. 2, terminal 1 may be terminal 110 in FIG. 1. IAB node 2, IAB node 3, and IAB node 1 may be relay node 130 in FIG. 1. IAB donor 1 may be access network device 140 in FIG. 1. IAB donor 1 may be connected (e.g., wired) to core network device 150 in FIG. 1. The IAB donor may be referred to as a donor node, DgNB (i.e., donor gNodeB), or other suitable name. This is not limited in this application.

[0083] The IAB network 200 includes one or more terminals (for clarity, FIG. 2 shows only terminal 1), one or more IAB nodes (e.g., FIG. 2 shows three IAB nodes, namely, IAB node 2, IAB node 3, and IAB node 1), and one or more donor nodes (for clarity, FIG. 2 shows only IAB donor 1). Terminal 1 may be wirelessly connected to one or more IAB nodes. Each IAB node may be wirelessly connected to one or more other IAB nodes, and one or more IAB nodes may be wirelessly connected to one or more donor nodes. Optionally, one or more IAB nodes may be further wirelessly connected to each other. This is not limited in the present application.

[0084] In an IAB network, one transmission path between a terminal and a donor node may be understood to include one or more IAB nodes. When one IAB node is a node accessed by a terminal, the link between the IAB node and a child node (i.e., a terminal) may be referred to as an access link. When one IAB node is a node providing backhaul services to a terminal served by another IAB node, the link between the IAB node and a child node (i.e., another IAB node) may be referred to as a backhaul link. For example, as shown in FIG. 2, terminal 1 is connected to IAB node 2 via a wireless access link, IAB node 2 is connected to IAB node 3 via a wireless backhaul link, IAB node 3 is connected to IAB node 1 via a wireless backhaul link, and IAB node 1 is connected to an IAB donor via a wireless backhaul link.

[0085] In order to ensure service transmission reliability, the IAB network optionally supports multi-hop IAB node networking and multi-connectivity IAB node networking. There may be multiple transmission paths between a terminal and an IAB donor. On one path, there is a determined hierarchical relationship between IAB nodes and between IAB nodes and donor nodes that provide services to the IAB nodes. Each IAB node regards a node that provides access services to the IAB node as a parent node. Accordingly, each IAB node may be regarded as a child node of the parent node of the IAB node.

[0086] For example, in FIG. 2, the parent node of IAB node 1 is IAB donor 1, IAB node 1 is the parent node of IAB node 3, IAB node 3 is the parent node of IAB node 2, and IAB node 2 is the parent node of terminal 1.

[0087] An uplink data packet of the terminal may be transmitted to the donor node via one or more IAB nodes and then transmitted by the donor node to a core network device, for example, a mobile gateway device (e.g., a user plane function (UPF) network element in a 5G network). A downlink data packet of the terminal is received by the donor node from the core network device (i.e., a mobile gateway device) and then transmitted to the terminal via one or more IAB nodes.

[0088] For example, in FIG. 2, the transmission path of an uplink data packet between terminal 1 and IAB donor 1 is terminal 1 → IAB node 2 → IAB node 3 → IAB node 1 → IAB donor 1, and the transmission path of a downlink data packet between terminal 1 and IAB donor 1 is IAB donor 1 → IAB node 1 → IAB node 3 → IAB node 2 → terminal 1.

[0089] In an IAB network, an IAB node accessed by a terminal on one transmission path may be called an access IAB node, and another IAB node on the transmission path may be called an intermediate IAB node. An intermediate IAB node may provide backhaul services to a terminal. An IAB node may be used as an access IAB node for a terminal and may also be used as an intermediate IAB node for another terminal.

[0090] For example, in FIG. 2, on the route "terminal 1 → IAB node 2 → IAB node 3 → IAB node 1 → IAB donor 1", IAB node 2 is an access IAB node, and IAB node 3 and IAB node 1 are intermediate IAB nodes. IAB node 3 provides access service to IAB node 2 and / or backhaul service to terminal 1. IAB node 1 provides access service to IAB node 3 and / or backhaul service to terminal 1. When terminal 2 (not shown in FIG. 2) accesses IAB node 3, IAB node 3 becomes an intermediate IAB node for terminal 1, and IAB node 3 becomes an access IAB node for terminal 2.

[0091] In an IAB network, an IAB node and one or more IAB nodes served by the IAB node may be referred to as descendant nodes of the IAB node. Descendant nodes may be understood to include IAB nodes served by the IAB node, e.g., child nodes, grandchild nodes, and great-grandchild nodes, and terminals that access the IAB node, e.g., terminals that access the child nodes, grandchild nodes, and great-grandchild nodes.

[0092] For example, in FIG. 2, descendant nodes of IAB node 1 include terminal 1, IAB node 2, and IAB node 3.

[0093] The above IAB network is just an example. In the IAB network with multi-hop and multi-connectivity combined, there are many other possibilities in the IAB network. For example, a donor node and an IAB node served by another donor node form dual connectivity to serve a terminal. The possibilities are not listed one by one in this specification.

[0094] In an IAB network, with respect to an IAB donor, the IAB donor may include a central unit (sometimes referred to as an IAB donor CU) and distributed units (sometimes referred to as an IAB donor DU).

[0095] In an IAB network, with respect to an IAB node, when serving as a parent node, the IAB node may play a role similar to that of an access network device to provide access services to its child nodes, e.g., assign uplink resources for uplink data transmission to the child nodes of the IAB node by scheduling. When the IAB node serves as a child node, with respect to the parent node serving the IAB node, the IAB node may play a role of a terminal device, e.g., establish a connection with the parent node by operations such as cell selection and random access, and obtain uplink resources for uplink data transmission and scheduled for the IAB node by the parent node.

[0096] By way of example and not of limitation, in this embodiment of the present application, a functional unit in an IAB node that supports the IAB node in implementing the role of a terminal device is called a mobile terminal (MT) functional unit of the IAB node, this functional unit is called IAB-MT or IAB-UE for short, and a functional unit in an IAB node that supports the IAB node in implementing the role of an access network device is called a DU functional unit of the IAB node, this functional unit is called IAB-DU for short. The IAB-MT and IAB-DU may be logical functional units and the functions of the IAB-MT and IAB-DU are implemented by the IAB node. Alternatively, the IAB-MT and IAB-DU may be a physical division, and the IAB-MT and IAB-DU may be separate physical devices within the IAB node.

[0097] It should be noted that Fig. 2 is described using an IAB network as an example. The contents of Fig. 2 are also applicable to relay networks other than the IAB network, and "IAB" in Fig. 2 may be replaced with "relay". For example, IAB node 2 may be replaced with relay node 2, IAB node 3 may be replaced with relay node 3, IAB node 1 may be replaced with relay node 1, and IAB donor 1 may be replaced with donor node 1. For the description of the connection relationships between network elements, such as access links, backhaul links, parent nodes, child nodes, access relay nodes, intermediate access nodes, etc. in a relay network, please refer to the description of the IAB network 200.

[0098] Figure 3 is a schematic diagram of a CU-DU split architecture according to an embodiment of the present application. The access network device in Figure 1 or the IAB donor in Figure 2 may use a CU-DU split architecture. The following description will be given with reference to Figure 3.

[0099] The access network device 140 may be implemented using a cloud radio access network (C-RAN) architecture. Some functions of a base station (here, a gNB is used as an example for explanation) are implemented by a central unit (CU), and other functions are implemented by a distributed unit (DU). The CU-DU division may be implemented by a protocol stack. In a possible approach, a radio resource control (RRC) layer, a service data layer, and a UE layer may be implemented by a UE layer. AdaptationThe service data adaptation protocol (SDAP) layer and packet data convergence protocol (PDCP) layer are located in the CU, and the radio link control (RLC) layer, media access control (MAC) layer, and physical (PHY) layer are located in the DU. To facilitate network expansion, one CU may be connected to one or more DUs. The CU is connected to the DU via an interface (e.g., F1 interface), and the CU is connected to the core network via an interface (e.g., NG interface).

[0100] In implementation, the CU includes a User plane (UP for short) (referred to as CU-UP for short in this application) and a Control plane (CP for short) (referred to as CU-CP for short in this application).

[0101] In a single air interface scenario, a terminal may access a CU through a DU. The functions of the peer RLC layer, MAC layer, and PHY layer of the UE are implemented by the DU, and the functions of the corresponding PDCP layer, SDAP layer, and PDCP layer of the UE are implemented by the CU.

[0102] Figure 4 is a schematic diagram of a control plane protocol stack in a CU-DU split architecture according to an embodiment of the present application. Figure 5 is a schematic diagram of a user plane protocol stack in a CU-DU split architecture according to an embodiment of the present application. The following description will be made with reference to Figures 4 and 5.

[0103] For the control plane, as shown in Figure 4, the UE and CU each establish a peer RRC layer and a PDCP layer. The UE is connected to the DU via an interface (e.g., Uu interface), and the UE and DU each establish a peer RLC layer, a MAC layer, and a PHY layer. The DU is connected to the CU via a control plane interface (e.g., F1-control plane (F1-C) interface), and the DU and CU each establish a peer F1 application protocol (F1AP) layer, a stream control transmission protocol (SCTP) layer, an Internet Protocol (IP) layer, a layer (L) 2, and a layer (L) 1.

[0104] For the user plane, as shown in Figure 5, the UE and CU establish peer SDAP and PDCP layers, respectively. The UE is connected to the DU via a Uu interface, and the UE and DU establish peer RLC, MAC, and PHY layers, respectively. The DU is connected to the CU via an F1-user plane (F1-U) interface, and the DU and CU establish peer general packet radio service (GPRS) tunneling protocol-user plane (GTP-U) layer, user datagram protocol (UDP) layer, IP layer, L2, and L1, respectively.

[0105] FIG. 6 is a schematic diagram of a control plane protocol stack in an IAB network according to an embodiment of the present application. FIG. 7 is a schematic diagram of a user plane protocol stack in an IAB network according to an embodiment of the present application. The following description will be made with reference to FIG. 6 and FIG. 7.

[0106] In an IAB network, the terminal's peer PHY layer, MAC layer and RLC layer are located in the access IAB node, and the UE's peer PDCP layer, SDAP layer and RRC layer are located in the IAB donor CU. If the IAB donor CU includes a CP and a UP, for the control plane, the UE's peer PDCP layer and RRC layer are located in the CP of the IAB donor CU (i.e., donor-CU-CP), and for the user plane, the UE's peer PDCP layer and SDAP layer are located in the UP of the IAB donor CU (i.e., donor-CU-UP).

[0107] For the control plane, as shown in Fig. 6, a Uu interface is established between terminal 1 and DU of IAB node 2, and the peer protocol layer includes RLC layer, MAC layer, and PHY layer. An F1-C interface is established between DU of IAB node 2 and IAB donor CU 1, and the peer protocol layer includes F1AP layer and SCTP layer. An F1 interface in the IAB donor is established between IAB donor DU 1 and IAB donor CU 1, and the peer protocol layer includes IP layer, L2, and L1. A BL is established between IAB node 2 and IAB node 3, between IAB node 3 and IAB node 1, and between IAB node 1 and IAB donor DU 1, and the peer protocol layer includes Backhaul Adaptation Protocol (BAP) layer, RLC layer, MAC layer, and PHY layer. In addition, terminal 1 and IAB donor CU 1 each establish a peer RRC layer and a PDCP layer, and the DU of IAB node 2 and IAB donor DU 1 each establish a peer IP layer.

[0108] Compared with the control plane protocol stack of the single air interface, in the control plane protocol stack in the IAB network, the DU of the access IAB node may be known to implement the functions of the gNB-DU of the single air interface (i.e., the functions of establishing the peer RLC layer, MAC layer and PHY layer in the terminal, and establishing the peer F1AP layer and SCTP layer in the CU). The DU of the access IAB node in the IAB network may be understood to implement the functions of the gNB-DU of the single air interface, and the IAB donor CU to implement the functions of the gNB-CU of the single air interface.

[0109] In the control plane, the UE's RRC messages are encapsulated within F1AP messages between the access IAB node and the IAB donor CU for transmission.

[0110] For the user plane, as shown in Figure 7, a Uu interface is established between the terminal 1 and the DU of IAB node 2, and the peer protocol layer includes the RLC layer, the MAC layer, and the PHY layer. An F1-U interface is established between the DU of IAB node 2 and the IAB donor CU 1, and the peer protocol layer includes the GTP-U layer and the UDP layer. An F1 interface in the IAB donor is established between the IAB donor DU 1 and the IAB donor CU 1, and the peer protocol layer includes the IP layer, the L2, and the L1. A BL is established between the IAB node 2 and the IAB node 3, between the IAB node 3 and the IAB node 1, and between the IAB node 1 and the IAB donor DU 1, and the peer protocol layer includes the BAP layer, the RLC layer, the MAC layer, and the PHY layer. In addition, the terminal 1 and the IAB donor CU 1 respectively establish a peer SDAP layer and a PDCP layer, and the DU of IAB node 2 and the IAB donor DU 1 respectively establish a peer IP layer.

[0111] Compared with the user plane protocol stack of the single air interface, in the user plane protocol stack in the IAB network, the DU of the access IAB node may be known to implement the functionality of a gNB-DU of the single air interface (i.e., the functionality of establishing a peer RLC layer, MAC layer and PHY layer with the terminal, and establishing a peer GTP-U layer and UDP layer with the IAB donor CU 1). It may be understood that the DU of the access IAB node implements the functionality of a gNB-DU of the single air interface, and the IAB donor CU implements the functionality of a gNB-CU of the single air interface.

[0112] In the user plane, the UE's PDCP data packets are encapsulated in a GTP-U tunnel between the access IAB node and the IAB donor CU for transmission. The GTP-U tunnel is established on the F1-U interface.

[0113] 7, the PDCP entity, the RLC entity, and the GTP-U tunnel of the terminal may be established at a bearer granularity. In other words, the bearer, the PDCP entity, the RLC entity, and the GTP-U tunnel may have a one-to-one correspondence.

[0114] Logical channels are established between the terminal and the DU of the access IAB node. A logical channel is a transmission channel between the RLC entity and a lower layer entity of the RLC entity, i.e., a transmission channel between the RLC entity and the MAC entity. One RLC entity corresponds to one logical channel. RLC channels are established between the MT of the access IAB node and the DU of the intermediate IAB node (e.g., the MT of IAB node 2 and the DU of IAB node 3), between the MT of the intermediate IAB node and the DU of the intermediate IAB node (e.g., the MT of IAB node 3 and the DU of IAB node 1), and between the DU of the intermediate IAB node and the IAB donor DU (e.g., the MT of IAB node 1 and the IAB donor DU 1). An RLC channel is a transmission channel between the RLC entity and an upper layer entity of the RLC entity. For example, if the upper layer entity of the RLC entity is an adaptation (also called Backhaul Adaptation Protocol (BAP)) layer entity, the RLC channel on the backhaul link is a channel between the RLC entity and the BAP entity. One RLC entity corresponds to one RLC channel. Therefore, in Figure 7, the bearer, the PDCP entity, the RLC entity, the GTP-U tunnel, and the logical channel have a one-to-one correspondence.

[0115] Each of Fig. 6 and Fig. 7 is described using only the protocol stack of the IAB scenario shown in Fig. 2 as an example. It should be noted that one IAB node may play one or more roles. The IAB node may have one or more protocol stacks of one or more roles. Alternatively, the IAB node may have one protocol stack, and for different roles of the IAB node, protocol layers corresponding to different roles in the protocol stack may be used for processing. In the following, an example is used in which the IAB node has one or more protocol stacks of one or more roles.

[0116] (1) Terminal protocol stack

[0117] When accessing the IAB network, the IAB node may play the role of a terminal. In this case, the MT of the IAB node has a protocol stack of a terminal, for example, the protocol stack of the terminal 1 in Figures 6 and 7, i.e., the RRC layer, the PDCP layer, the RLC layer, the MAC layer, and the PHY layer. In the control plane, the RRC message of the IAB node is encapsulated in the F1AP message between the parent node of the IAB node and the IAB donor CU for transmission. In the user plane, the PDCP data packet of the IAB node is encapsulated in the GTP-U tunnel between the parent node of the IAB node and the IAB donor CU for transmission.

[0118] In addition, after the IAB node accesses the IAB network, the IAB node may still act as a terminal, for example, transmitting the IAB node's uplink and / or downlink data packets (e.g., OAM data packets) on the IAB donor and performing measurements via the RRC layer.

[0119] (2) Protocol stack of access IAB node

[0120] After the IAB node accesses the IAB network, the IAB node can provide an access service to the terminal and play the role of an access IAB node. In this case, the IAB node has a protocol stack of an access IAB node, for example, the protocol stack of the IAB node 2 in FIG. 6 and FIG. 7.

[0121] (3) Protocol stack of intermediate IAB node

[0122] After an IAB node accesses the IAB network, the IAB node may play the role of an intermediate IAB node. In this case, the IAB node has a protocol stack of an intermediate IAB node, for example, the protocol stack of IAB node 3 or IAB node 1 in FIG. 6 and FIG. 7.

[0123] An IAB node may have one or more protocol stacks of one or more roles. For example, after accessing an IAB network, an IAB node may play the role of a terminal and the role of an access IAB node. In this case, there may be two protocol stacks on the interface between the IAB node and the parent node of the IAB node. One is the protocol stack of the terminal, and the other is the protocol stack of a node that provides backhaul services to the terminal (i.e., the protocol stack of the access IAB node). In another example, after accessing an IAB network, an IAB node may play the role of a terminal and the role of an intermediate IAB node. In this case, there may be two protocol stacks on the interface between the IAB node and the parent node of the IAB node. One is the protocol stack of the terminal, and the other is the protocol stack of the intermediate IAB node. As yet another example, after accessing the IAB network, an IAB node can play the role of a terminal, the role of an access IAB node, and the role of an intermediate IAB node (e.g., an IAB node may be an access IAB node for some terminals and an intermediate IAB node for some other terminals, and in addition, the IAB node needs to transmit operation, administration and maintenance (OAM) data packets of the IAB node with the IAB donor). In this case, the IAB node may have three protocol stacks: one is a protocol stack of a terminal, one is a protocol stack of an access IAB node, and another is a protocol stack of an intermediate IAB node.

[0124] It should be noted that Figures 6 and 7 are respectively described using an IAB network as an example. The contents of Figures 6 and 7 also apply to relay networks other than an IAB network. For the architecture of the control plane protocol stack of a relay network, please refer to Figure 6. For the architecture of the user plane protocol stack of a relay network, please refer to Figure 7.

[0125] In a single air interface scenario, a terminal handover may occur. When a terminal is handed over from a source base station to a target base station, the terminal is first disconnected from the source base station, and the terminal's service transmission is interrupted. After the terminal accesses the target base station, the terminal's service transmission is resumed. In order to reduce the terminal's service transmission interruption problem in the case of a single air interface, a dual active protocol stack (DAPS) solution is introduced.

[0126] In the following, first, the DAPS solution for the single air interface case will be described with reference to Figures 8 to 9B.

[0127] FIG. 8 is a schematic diagram of a DAPS according to an embodiment of the present application. As shown in FIG. 8, a source base station receives downlink data of a terminal from a core network. During terminal handover, the source base station may transmit a part of the received downlink data to the terminal and forward another part of the received downlink data to a target base station (this part of data may be referred to as forwarding data), so that after the terminal accesses the target base station, the target base station transmits the part of data to the terminal. The source base station and the target base station have respective user plane protocol stacks. The terminal has two protocol stacks. One protocol stack corresponds to the source base station and includes a corresponding PHY entity, a MAC entity and an RLC entity. The other protocol stack corresponds to the target base station and includes a corresponding PHY layer, a MAC entity and an RLC entity. Although the terminal has two protocol stacks, for the forwarding data of the terminal, one PDCP entity is associated with two RLC entities, one RLC entity corresponds to the source base station and the other RLC entity corresponds to the target base station. The PDCP entity is configured at a bearer granularity, which may be understood as one bearer of a terminal corresponding to one PDCP entity. However, in the PDCP entity, functions such as header compression, header decompression, security processing, header add header, and header remove header are independent of each other in the source base station and the target base station, and the reordering function is common to the source base station and the target base station. The PDCP sequence number (SN) required for reordering may be assigned uniformly by the source base station.

[0128] 9A and 9B are schematic flowcharts of a DAPS-based handover in the case of a single air interface according to an embodiment of the present application. As shown in FIG. 9A and 9B, the method includes the following steps:

[0129] S901: A source base station performs a handover decision.

[0130] Before S901, the terminal establishes a protocol stack corresponding to the source base station shown in FIG. 8, and performs uplink data transmission and downlink data transmission with the source base station based on the protocol stack corresponding to the source base station.

[0131] S902: The source base station sends a handover request message to the target base station.

[0132] Since the handover request message includes the context information of the terminal, the target base station generates configuration information of the air interface resources of the target base station for the terminal.

[0133] S903: The target base station sends a handover request confirmation message to the source base station.

[0134] The handover request confirmation message includes a handover command message generated by the target base station. The handover command message includes configuration information of air interface resources generated by the target base station for the terminal. The configuration information of the air interface resources includes configuration information of air interface resources allocated by the target base station to forwarded data. The forwarded data of the terminal includes terminal data received by the source base station from the core network and forwarded to the target base station. The target base station transmits the forwarded data to the terminal. The configuration information of the air interface resources allocated by the target base station to the forwarded data includes configuration information of one or more of a PDCP layer, an RLC layer, a MAC layer, and a PHY layer. The configuration information of the PDCP layer may include security configuration information and / or a robust header compression (ROHC) profile. The security configuration information may include a security algorithm (e.g., an encryption algorithm and / or an integrity protection algorithm) and / or a key-related parameter.

[0135] S904: The source base station sends, to the terminal, a handover command message generated by the target base station.

[0136] The handover command message includes configuration information of air interface resources generated by the target base station for the terminal. The terminal may establish a protocol stack corresponding to the target base station shown in Figure 8 based on the configuration information. In this case, the terminal establishes a protocol stack corresponding to the source base station and a protocol stack corresponding to the target base station shown in Figure 8.

[0137] Optionally, the handover command message may further carry one indication information, which may correspond to one service bearer of the terminal, indicating that a DAPS handover should be configured for the service bearer of the terminal. The service bearer may be a data radio bearer (DRB).

[0138] S905: The terminal starts DAPS.

[0139] After the terminal initiates a DAPS operation on the service bearer corresponding to the indication information based on the indication information carried in the handover command message, because the terminal has not successfully accessed the target base station at this moment, the terminal may continue to use the protocol stack corresponding to the source base station to perform uplink data transmission and downlink data transmission with the source base station on the service bearer and simultaneously attempt to access the target base station.

[0140] S906 and S907 describe the process of the source base station forwarding sequence number (SN) status and data. The source base station may forward a portion of downlink data received from the core network for the terminal to the target base station, and the target base station transmits the portion of the downlink data to the terminal. The source base station continues to transmit the other portion of the data to the terminal.

[0141] S906: The source base station forwards the SN status to the target base station.

[0142] S907: The source base station forwards data to the target base station.

[0143] The terminal data forwarded by the source base station to the target base station is a PDCP service data unit (SDU). The source base station uniformly assigns a PDCP SN to the PDCP SDU, and forwards the PDCP SDU and the PDCP SN corresponding to the PDCP SDU to the target base station, so that after the terminal successfully accesses the target base station, the target base station processes the PDCP SDU according to the received PDCP SN and the configuration information of the PDCP layer, and then sends the processed PDCP SDU to the terminal.

[0144] S908: The terminal transmits a preamble to the target base station.

[0145] S909: The target base station sends a random access response (RAR) to the terminal.

[0146] S910: The terminal performs a physical uplink shared channel (PUSCH) switch.

[0147] Before the PUSCH switching, the terminal receives an uplink (UL) grant allocated by the target base station. For example, in non-contention-based random access, the UL grant is carried in the RAR of S909, and in contention-based random access, the UL grant may be carried in downlink control information (DCI) and transmitted to the terminal. After receiving the UL grant, the terminal performs a PUSCH switching operation, i.e., stops uplink data transmission with the source base station and starts uplink data transmission with the target base station. In other words, the PUSCH of the terminal is switched from the source base station to the target base station. It should be noted that although the PUSCH of the terminal is switched to the target base station and the terminal cannot perform uplink data transmission with the source base station, the terminal can still perform downlink data transmission with the source base station.

[0148] It can be known from the foregoing description that, in S904 to S910, the terminal and the source base station can perform downlink data transmission and uplink data transmission.

[0149] S911: The terminal sends an RRC reconfiguration complete message to the target base station.

[0150] After the terminal's PUSCH is switched to the target base station, the terminal may send an RRC reconfiguration complete message to the target base station on the resource indicated by the UL grant, which means that the terminal has successfully accessed the target base station, and the terminal can perform downlink data transmission with the target base station.

[0151] S912: The target base station sends a handover success message to the source base station, indicating the source base station to stop sending downlink data to the terminal.

[0152] From the above description, it can be known that in S911 to S912, the terminal and the source base station can perform downlink data transmission, the terminal and the target base station can perform downlink data transmission, and the terminal and the target base station may perform uplink data transmission.

[0153] Specifically, the terminal processes the downlink data received from the source base station based on the ROHC profile, security algorithm, and key configured by the source base station, and processes the downlink data received from the target base station based on the ROHC profile, security algorithm, and key configured by the target base station. Then, the terminal sends the processed packets to a public buffer of the PDCP layer for sorting, and submits the processed packets to the upper layer in sequence.

[0154] S913: The source base station stops transmitting downlink (DL) data to the UE.

[0155] After receiving the handover success message sent by the target base station, the source base station stops sending downlink data to the terminal, and sends the downlink data of the terminal remaining in the source base station to the target base station according to the following S914 and S915, and the target base station sends the downlink data to the terminal.

[0156] S914: The source base station forwards the SN status to the target base station.

[0157] S915: The source base station forwards data to the target base station.

[0158] S916: The target base station sends an RRC message to the terminal, indicating the terminal to release air interface resources corresponding to the source base station.

[0159] S917: The terminal switches from DAPS to a single active protocol stack.

[0160] After the terminal switches to the single-active protocol stack, the terminal completely stops transmission with the source base station, including physical uplink control channel (PUCCH) transmission, etc.

[0161] From the foregoing description, it can be seen that in S913 to S917, the terminal and the target base station perform downlink data transmission and uplink data transmission.

[0162] In the solution of Figures 9A and 9B, the terminal initiates DAPS, so that the terminal can maintain a connection with the source base station during inter-base station handover in the case of a single air interface, ensuring that the terminal's uplink data transmission and downlink data transmission are not interrupted, and improving the user experience.

[0163] In a relay network, a relay node handover may occur. Figure 10 is a schematic diagram of a relay node handover according to an embodiment of the present application. As shown in Figure 10, handing over a relay node from a source donor node to a target donor node may be understood as the source donor node being the source donor node during the relay node handover, and the target donor node being the target donor node during the relay node handover.

[0164] Optionally, a relay node handover may be understood as a relay node using the relay node and its descendant nodes as a group, which is handed over from a source donor node to a target donor node. In this embodiment of the present application, the node whose parent node changes is called the relay node, at which the handover occurs or is performed.

[0165] Optionally, the relay node through which the handover occurs may be referred to as a handover relay node or a transition relay node.

[0166] Optionally, the transition relay node may be a parent node of the terminal. In other words, the transition relay node is directly connected to the terminal, i.e., the transition relay node is an access relay node (in this embodiment of the present application, the relay node accessed by the terminal is called an access relay node). Or, the transition relay node may be connected to the terminal via one or more other relay nodes, i.e., the transition relay node is an intermediate relay node (in this embodiment of the present application, the relay node providing the backhaul service to the terminal is called an intermediate relay node).

[0167] Optionally, a source donor node being a source donor node during a relay node handover may be understood as a donor node before the relay node handover being a source donor node, or a relay node being connected to the source donor node before the handover. The manner of connecting a relay node to a source donor node is not limited in this application. For example, the source donor node may be a parent node of the relay node, or the source donor node may be connected to the relay node via one or more other relay nodes.

[0168] Optionally, the target donor node being the target donor node during the relay node handover may be understood as the donor node after the relay node handover becoming the target donor node, but the relay node handover may ultimately succeed or fail. This is not limited in this embodiment of the present application. The manner of connecting the relay node to the target donor node is not limited in the present application. For example, the target donor node may be the parent node of the relay node, or the target donor node may be connected to the relay node via one or more other relay nodes.

[0169] Optionally, the source parent node during relay node handover may be referred to as the source parent node, and the target parent node during relay node handover may be referred to as the target parent node. It may be understood that before the relay node handover, the relay node is connected to the source parent node, and the source parent node provides access services to the relay node. After the relay node handover, the relay node is connected to the target parent node, and the target parent node provides access services to the relay node.

[0170] Optionally, the source parent node may be a source donor node, or the source parent node is connected to the source donor node via m other relay nodes, where m is an integer equal to or greater than 1. The target parent node may be a target donor node, or the target parent node is connected to the target donor node via n other relay nodes, where n is an integer equal to or greater than 1. Optionally, the donor node may include a CU and / or a DU.

[0171] Optionally, the source donor node may include a source CU. Optionally, the source donor node may further include a source DU. The target donor node may include a target CU. Optionally, the target donor node may further include a target DU. The source CU is different from the target CU, and the source DU is different from the target DU.

[0172] The handover of the relay node from the source donor node to the target donor node may be referred to as a donor-to-node handover or an inter-CU handover.

[0173] With reference to the IAB scenario, the following further describes the donor-to-node handover using an example in which the relay node is an IAB node, the source donor node includes a source IAB donor CU, and the target donor node includes a target IAB donor CU.

[0174] 11 is a schematic diagram of donor-CU handover according to an embodiment of the present application. An example is taken in which donor-CU handover occurs at IAB node 3 in FIG. 2. As shown in FIG. 11, before handover, the parent node of IAB node 3 (i.e., the source parent node of IAB node 3) is IAB node 1, the source IAB donor DU is IAB donor DU 1, and the source IAB donor CU is IAB donor DU 2. B-Do After the handover, the parent node of IAB node 3 (i.e., the target parent node of IAB node 3) is IAB node 4, the target IAB donor DU is IAB donor DU 2, and the target IAB donor CU is IAB donor DU 3. B-Do It's Na CU 2.

[0175] A handover of the IAB node 3 may be considered as a handover of the MT of the IAB node 3. The source donor node may include an IAB donor CU 1, or the source donor node may include an IAB donor CU 1 and an IAB donor DU 1. The target donor node may include an IAB donor CU 2, or the target donor node may include an IAB donor CU 2 and an IAB donor DU 2.

[0176] It should be noted that while FIG. 11 is described only using an example in which an inter-donor node handover occurs to an intermediate IAB node, an inter-donor node handover may also occur to an access IAB node (e.g., IAB node 2).

[0177] In the relay node scenario, during the inter-donor node handover, the donor node connected to the relay node performing the handover changes, and the relay node must first disconnect from the source donor node (i.e., the relay node cannot receive the terminal's downlink data from the source donor node and cannot transmit the terminal's uplink data to the source donor node). As a result, the relay node stops serving the terminal, and the terminal's data transmission is interrupted. Then, the terminal detects that the RLF occurs on the link between the relay node and the terminal, and triggers the RRC re-establishment procedure to resume data transmission. In the process, the terminal's service transmission is interrupted, greatly reducing the user experience.

[0178] Therefore, the DAPS solution in the case of a single air interface can be applied to the donor-to-donor node handover scenario to ensure that the uplink and downlink data transmissions of the relay node acting as a terminal are not interrupted. Specifically, the relay node has the function of DAPS shown in FIG. 8 during handover. The relay node has two protocol stacks. In one protocol stack, the PHY layer, MAC layer and RLC layer of the relay node correspond to the source parent node of the relay node. In another protocol stack, the PHY layer, MAC layer and RLC layer of the relay node correspond to the target parent node of the relay node. The relay node includes one PDCP entity, which is associated with two RLC entities. One RLC entity corresponds to the source parent node, and the other RLC entity corresponds to the target parent node.

[0179] For example, a relay node may perform the operations performed by the terminal of Figures 9A and 9B, a source donor node may perform the operations performed by the source base station of Figures 9A and 9B, and a target donor node may perform the operations performed by the target base station of Figures 9A and 9B.

[0180] After the DAPS solution for the single air interface case is applied to the donor node-to-donor node handover scenario, it can be ensured that the transmission of the relay node's data (which may be understood as data terminated at the relay node, e.g., OAM data) is not interrupted during the relay node handover. In addition, the relay node may also provide backhaul services to the terminal during the handover (i.e., function as an access relay node or an intermediate relay node). Similar to the DAPS solution, the relay node may have both the peer protocol stack of the source parent node and the peer protocol stack of the target parent node, so that during the handover the relay node may transmit data (including uplink data and downlink data) between the terminal and the source donor node, or may transmit data (including uplink data and downlink data) between the terminal and the target donor node.

[0181] However, for a terminal, the terminal is always connected to a relay node, no handover occurs to the terminal, and the terminal cannot know whether the data is from a source donor node or a target donor node. Specifically, for downlink data, the terminal cannot know whether the downlink data received from the relay node is from a source donor node or a target donor node, and for uplink data, the terminal cannot know whether the uplink data transmitted is transmitted by the relay node to a source donor node or a target donor node. For ease of explanation, data received or transmitted to or from a source donor node is briefly referred to as data of a source donor node, and data received or transmitted to or from a target donor node is briefly referred to as data of a target donor node.

[0182] The configuration information required to process the data of the source donor node is different from the configuration information required to process the data of the target donor node. In other words, the data of the source donor node needs to be processed based on the configuration information of the source donor node, and the data of the target donor node needs to be processed based on the configuration information of the target donor node. The terminal cannot know whether the configuration information of the source donor node or the configuration information of the target donor node needs to be used to process the data packet, so the service of the terminal is interrupted.

[0183] For example, for downlink data, the terminal cannot know whether the received data packet is from the source donor node or the target donor node. As a result, the terminal cannot parse the received data packet with the correct configuration information. If the terminal fails to parse the data packet, packet loss is caused and the service is interrupted. For uplink data, the terminal cannot know whether the uplink data packet should be sent to the source donor node or the target donor node. As a result, the terminal cannot process the uplink data with the correct configuration information. If the donor node fails to parse the uplink data, packet loss occurs and the service of the terminal is interrupted.

[0184] In addition, even if the DAPS solution is not applied to the donor-to-node handover scenario, i.e., even if the relay node first disconnects from the source donor node during the donor-to-node handover (i.e., the terminal's uplink data and / or downlink data cannot be transmitted at the source donor node), the relay node may buffer downlink data previously received from the source donor node but not transmitted to the terminal. In this case, during the handover, the relay node may further continue to transmit the previously buffered downlink data received from the source donor node to the terminal. After the relay node is successfully handed over to the target donor node, the relay node may receive downlink data from the target donor node and transmit the downlink data received from the target donor node to the terminal. Therefore, due to the donor-to-node handover of the relay node, the terminal may receive two kinds of downlink data, i.e., the downlink data of the source donor node and the downlink data of the target donor node. The terminal cannot know whether the configuration information of the source donor node or the configuration information of the target donor node needs to be used to process the data, resulting in the service of the terminal being interrupted.

[0185] Based on this, an embodiment of the present application provides a solution for reducing the probability of service interruption of a terminal in an inter-donor node handover scenario and improving user experience. In this solution, an access relay node of the terminal may configure two logical channels (LCHs) for one bearer (e.g., one DRB) of the terminal. One LCH is for transmitting data corresponding to a source donor node, and the other LCH is for transmitting data corresponding to a target donor node. Based on the separate LCHs, the terminal may distinguish between data corresponding to the source donor node and data corresponding to the target donor node, ensuring that the terminal uses correct configuration information to process data, reducing the probability of service interruption and improving service transmission continuity.

[0186] Specifically, in this embodiment of the present application, for one bearer of the terminal, there is a GTP-U tunnel (hereinafter referred to as a GTP-U tunnel corresponding to a source donor node) between the access relay node and the source donor node, and there is another GTP-U tunnel (hereinafter referred to as a GTP-U tunnel corresponding to a target donor node) between the access relay node and the target donor node. For one bearer of the terminal, there are two LCHs in the terminal. One LCH of the terminal corresponds to a GTP-U tunnel corresponding to a source donor node, and the other LCH of the terminal corresponds to a GTP-U tunnel corresponding to a target donor node.

[0187] The following describes the dual LCH user plane protocol stack during inter-donor node handover in this embodiment of the present application.

[0188] FIG. 12 is a schematic diagram of a dual LCH user plane protocol stack according to an embodiment of the present application.

[0189] The terminal has one protocol stack including a PHY layer, a MAC layer, an RLC layer, and a PDCP layer. The RLC layer, the MAC layer, and the PHY layer of the terminal correspond to the RLC layer, the MAC layer, and the PHY layer of the terminal's parent node, and the PDCP layer of the terminal corresponds to the PDCP layer of the source donor node (i.e., IAB donor CU 1 in FIG. 12) and the PDCP layer of the target donor node (i.e., IAB donor CU 2 in FIG. 12).

[0190] Optionally, the PDCP layer includes a PDCP entity, the RLC layer includes an RLC entity, the MAC layer includes a MAC entity, and the PHY layer includes a PHY entity. The MAC entity and the PHY entity of the terminal are configured at terminal granularity, and the terminal has one MAC entity and one PHY entity. The PDCP entity of the terminal is configured at bearer granularity. For one bearer of the terminal, the terminal may have one corresponding PDCP entity.

[0191] Specifically, for one bearer, the terminal has only one PDCP entity, but PDCP setting information corresponding to a source donor node and PDCP setting information corresponding to a target donor node are configured for the PDCP entity, which may be understood as the PDCP entity may use or maintain both the PDCP setting information corresponding to the source donor node and the PDCP setting information corresponding to the target donor node, where the PDCP setting information corresponding to the source donor node may be for processing data (including uplink data and / or downlink data) corresponding to the source donor node, and the PDCP setting information corresponding to the target donor node may be for processing data (including uplink data and / or downlink data) corresponding to the target donor node.

[0192] It may be understood that the terminal has two sets of PDCP setting information, one set of PDCP setting information corresponding to the source donor node, and the other set of PDCP setting information corresponding to the target donor node.

[0193] It may be understood that the configuration information corresponds to each other, that the configuration information may be used together or in pairs.

[0194] Optionally, the configuration information corresponding to each other may include that the configuration information is the same. For example, one set of PDCP configuration information of the terminal is the same as the PDCP configuration information corresponding to the source donor node, and / or the other set of PDCP configuration information of the terminal is the same as the PDCP configuration information corresponding to the target donor node. Optionally, the configuration information corresponding to each other may include that the configuration information is different. For example, one set of PDCP configuration information of the terminal is different from the PDCP configuration information corresponding to the source donor node, and / or the other set of PDCP configuration information of the terminal is different from the PDCP configuration information corresponding to the target donor node.

[0195] Optionally, the PDCP configuration information for the terminal, which corresponds to the PDCP configuration information corresponding to the source donor node, may be assigned by the source donor node. For example, the source donor node transmits the PDCP configuration information corresponding to the PDCP configuration information corresponding to the source donor node to the terminal via the relay node. The PDCP configuration information for the terminal, which corresponds to the PDCP configuration information corresponding to the source donor node, may be referred to as the PDCP configuration information assigned by the source donor node or the PDCP configuration information corresponding to the source donor node. Similarly, the PDCP configuration information for the terminal, which corresponds to the PDCP configuration information corresponding to the target donor node, may be assigned by the target donor node. For example, the target donor node transmits the PDCP configuration information corresponding to the PDCP configuration information corresponding to the target donor node to the terminal via the relay node. The PDCP configuration information for the terminal, which corresponds to the PDCP configuration information corresponding to the target donor node, may be referred to as the PDCP configuration information assigned by the target donor node or the PDCP configuration information corresponding to the target donor node.

[0196] Specifically, in the PDCP entity, one or more functions of header compression, header decompression, security processing, add header, remove header, etc. are independent for the source donor node and the target donor node. In the PDCP entity, the reordering function is common to the source donor node and the target donor node. For details, please refer to the description of the PDCP entity in Figure 8.

[0197] Different from FIG. 7, one PDCP entity of the terminal may correspond to two RLC entities, one RLC entity corresponds to a source donor node, and the other RLC entity corresponds to a target donor node. The terminal has one MAC entity. One logical channel is between the MAC entity and the RLC entity corresponding to the source donor node, and another logical channel is between the MAC entity and the RLC entity corresponding to the target donor node. As shown in FIG. 12, one PDCP entity of the terminal corresponds to two RLC entities, and the terminal has only one MAC entity. LCH 1 is between the MAC entity and one RLC entity, namely RLC 1, and LCH 2 is between the MAC entity and the other RLC entity, namely RLC 2. One RLC entity of the terminal is configured to process data corresponding to the source donor node, and the LCH corresponding to the RLC entity is for transmitting data corresponding to the source donor node. The other RLC entity of the terminal is configured to process data corresponding to the target donor node, and the LCH corresponding to the other RLC entity is for transmitting data corresponding to the target donor node. As shown in Figure 12, RLC 1 of the terminal is configured to process data corresponding to the source donor node, and LCH 1 is for transmitting data corresponding to the source donor node, and RLC 2 of the terminal is configured to process data corresponding to the target donor node, and LCH 2 is for transmitting data corresponding to the target donor node.

[0198] The protocol stack on the DU of the access relay node is the same as that of the terminal, and "same" in this specification may be understood as "peered". Specifically, the DU of the access relay node has two RLC entities, one MAC entity and one PHY entity (peered to those of the terminal), the two RLC entities are peered to the two RLC entities of the terminal, and one LCH is between each of the two RLC entities and the MAC entity, and the two LCHs of the DU of the access relay node are peered to the two LCHs of the terminal. As shown in Figure 12, for one bearer of the terminal, the IAB node 2 has two RLC entities, namely RLC 1 and RLC 2. The RLC 1 of the IAB node 2 is peered to the RLC 1 of the terminal, and the RLC 2 of the IAB node 2 is peered to the RLC 2 of the terminal. An LCH, namely LCH 1, is between the RLC 1 and the MAC entity of the IAB node 2. Downlink transmission is used as an example. IAB node 2 transmits data on LCH 1 of IAB node 2, and terminal 1 receives the data on LCH 1 of terminal 1. An LCH, namely LCH 2, is between RLC 2 and the MAC entity of IAB node 2. Downlink transmission is used as an example. IAB node 2 transmits data on LCH 2 of IAB node 2, and terminal 1 receives the data on LCH 2 of terminal 1.

[0199] Similar to the case of the terminal, one RLC entity on the DU of the access relay node is configured to process data corresponding to the source donor node, and the LCH corresponding to the RLC entity is for transmitting data corresponding to the source donor node. The other RLC entity on the DU of the access relay node is configured to process data corresponding to the target donor node, and the LCH corresponding to the other RLC entity is for transmitting data corresponding to the target donor node. For details, please refer to the contents of the RLC entity and the LCH of the terminal. The details will not be described again in this specification. The LCH of the terminal and the access relay node may be used together, used in pairs, or used correspondingly, and the LCH of the terminal and the access relay node (or the configuration information of the LCH of the terminal and the access relay node) may be the same or different. This is not limited in this embodiment of the present application.

[0200] Corresponding GTP-U tunnels can be established between the DU of the access relay node and the source donor node, and between the DU of the access relay node and the target donor node at the granularity of the bearer of the terminal. For example, for one bearer of the terminal, a corresponding GTP tunnel is established between the IAB node 2 and the IAB donor CU 1, and a corresponding GTP tunnel is also established between the IAB node 2 and the IAB donor CU 2. As shown in Figure 12, for one bearer of the terminal, there is a GTP-U tunnel, i.e., GTP-U 1, between the DU of the IAB donor CU 1 and the IAB node 2. The GTP-U 1 is for transmitting data corresponding to the source donor node. There is another GTP-U tunnel, i.e., GTP-U 2, between the DU of the IAB donor CU 2 and the IAB node 2. The GTP-U 2 is for transmitting data corresponding to the target donor node.

[0201] One LCH of an access relay node corresponds to one GTP-U tunnel. In other words, the LCH and the GTP-U tunnel have a one-to-one correspondence. In the uplink direction, data received through one LCH is mapped to the GTP-U tunnel corresponding to the LCH. In the downlink direction, data received through one GTP-U tunnel is mapped to the LCH corresponding to the GTP-U tunnel. Using FIG. 12 as an example, in IAB node 2, LCH 1 and GTP-U 1 have a one-to-one correspondence, and LCH 2 and GTP-U 2 have a one-to-one correspondence. In the uplink direction, data received through LCH 1 is mapped to GTP-U 1 and sent to IAB donor CU 1, and data received through LCH 2 is mapped to GTP-U 2 and sent to IAB donor CU 2. In the downlink direction, data received from IAB donor CU 1 via GTP-U 1 is mapped to LCH 1, and data received from IAB donor CU 2 via GTP-U 2 is mapped to LCH 2.

[0202] For example, the transmission of uplink data corresponding to the source donor node (i.e., IAB donor CU 1) in FIG. 12 is used as an example. In terminal 1, the PDCP entity may process the uplink data using PDCP configuration information corresponding to IAB donor CU 1. Then, the PDCP entity transmits the uplink data that has been processed using the PDCP configuration information corresponding to the source donor node to RLC 1 of terminal 1. The RLC 1 of terminal 1 transmits the uplink data to the MAC entity of terminal 1 via LCH 1. The MAC entity of terminal 1 may encapsulate the data received from LCH 1 of terminal 1 and add an identifier of LCH 1 of terminal 1 to the MAC header. The PHY entity of terminal 1 processes the data and transmits the processed data to IAB node 2. Correspondingly, after IAB node 2 receives data from terminal 1, the MAC layer of IAB node 2 may parse the MAC header to obtain an identifier of LCH 1 of the terminal. The IAB node 2 sends data to RLC 1 via an LCH peered with the terminal's LCH 1, i.e., LCH 1 of the IAB node 2. The IAB node 2 extracts the terminal's uplink data from RLC 1, maps the uplink data to the corresponding GTP-U tunnel 1, and further transmits the data mapped to the GTP-U tunnel 1 to the IAB donor CU 1 via a backhaul link based on the current routing information. After extracting the terminal's uplink data from the GTP-U tunnel 1, the IAB donor CU 1 processes the uplink data using the PDCP configuration information corresponding to the IAB donor CU 1.

[0203] The transmission of uplink data corresponding to the target donor node (i.e., IAB donor CU 2) is similar to the transmission of uplink data corresponding to the source donor node. For details, please refer to the content of the transmission of uplink data corresponding to the source donor node.

[0204] As another example, the transmission of downlink data corresponding to the source donor node (i.e., IAB donor CU 1) in FIG. 12 is used as an example. The IAB donor CU 1 processes the downlink data using the PDCP configuration information corresponding to the IAB donor CU 1, and then the IAB donor CU 1 transmits the downlink data to the DU of the IAB node 2 through the GTP-U tunnel 1. After receiving the downlink data from the GTP-U tunnel 1, the DU of the IAB node 2 maps the downlink data to the RLC 1 corresponding to the GTP-U tunnel 1. The RLC 1 processes the downlink data and transmits the processed downlink data to the MAC entity through the LCH 1. The MAC entity may add an identifier of the LCH (i.e., the identifier of the LCH 1 of the terminal 1) in the terminal 1 and peered to the LCH 1 of the DU of the IAB node 2 to the MAC header. After being processed by the PHY layer of the DU of the IAB node 2, the downlink data is transmitted to the terminal 1. Correspondingly, after terminal 1 receives data from the DU of IAB node 2, the MAC entity of terminal 1 may parse the MAC header to obtain an identifier of LCH 1 of terminal 1. Then, terminal 1 transmits the data to RLC 1 of terminal 1 through LCH 1 of terminal 1. RLC 1 of terminal 1 processes the data and transmits the processed data to a corresponding PDCP entity. The PDCP entity processes the downlink data using configuration information corresponding to the source donor node.

[0205] The transmission of downlink data corresponding to the target donor node (i.e., IAB donor CU 2) is similar to the transmission of downlink data corresponding to the source donor node. For details, please refer to the content of the transmission of uplink data corresponding to the source donor node.

[0206] The MT of the access relay node has a BAP entity, an RLC entity, a MAC entity, and a PHY entity.

[0207] The DU of the transition relay node has a protocol stack (peered to that of the MT of the child node). As shown in Figure 12, the DU of IAB node 3 has a BAP entity, an RLC entity, a MAC entity, and a PHY entity (peered to those of the MT of IAB node 2).

[0208] Optionally, the source donor node may configure routing rules and / or bearer mapping rules for the path between the access relay node and the source donor node, and the target donor node may configure routing rules and / or bearer mapping rules for the path between the access relay node and the target donor node, which routing rules and / or bearer mapping rules are used for signal / data transmission.

[0209] To ensure that both data corresponding to the source donor node and data corresponding to the target donor node can be transmitted on the path between the access relay node and the transition relay node, two sets of BAP configurations are required to be supported in one or more MTs and / or DUs of one or more nodes (including the access relay node, the transition relay node, and one or more other relay nodes between the access relay node and the transition relay node) on the path between the access relay node and the transition relay node. One set of BAP configurations, including routing configuration and / or bearer mapping configuration, is provided by the source donor node, and the other set of BAP configurations, including routing configuration and / or bearer mapping configuration, is provided by the target donor node.

[0210] In the example, the access relay node is not a transition relay node. Since the parent node of the transition relay node changes, two sets of BAP settings are configured in the transition relay node. One set of BAP settings is the routing settings and / or bearer mapping settings provided by the source donor node, and the other set of BAP settings is the routing settings and / or bearer mapping settings provided by the target donor node. Since the parent node of the access relay node does not change, the bearer mapping to the link between the access relay node and the parent node may remain unchanged, but the routing settings on the link between the access relay node and the parent node may change (e.g., the BAP address of the access relay node during the routing settings changes). Thus, two sets of BAP settings are configured in the access relay node, one set of BAP settings is the routing settings provided by the source donor node, and the other set of BAP settings is the routing settings provided by the target donor node.

[0211] Optionally, one or more MTs (or DUs) of one or more nodes may have only one BAP entity, which supports two sets of BAP configurations. Alternatively, one or more MTs (or DUs) may have two BAP entities, one BAP entity supporting the BAP configurations provided by the source donor node and the other BAP entity supporting the BAP configurations provided by the target donor node.

[0212] Optionally, the target donor node may separately send the indication information to one or more nodes via the source donor node. Each of the indication information indicates a corresponding node to initiate two sets of BAP setting information. Initiating may be understood as activating or enabling, and initiating two sets of BAP setting information may be understood as initiating dual setting of the BAP layer. Alternatively, the source donor node may separately send the indication information to one or more nodes.

[0213] In the downlink, after receiving downlink data from a source donor node, a node in one or more nodes transmits the downlink data to its next-hop node based on the BAP setting of the source donor node, and / or after receiving downlink data from a target donor node, a node in one or more nodes transmits the downlink data to its next-hop node based on the BAP setting of the target donor node. Data transmission in the uplink direction is similar and will not be described again in this specification.

[0214] The MT of the transition relay node has a protocol stack similar to that of the DAPS. By the protocol stack being similar to that of the DAPS, it may be understood that the MT of the transition relay node has a protocol stack (peered to that of the source parent node) and a protocol stack (peered to that of the target parent node). The source downlink data received by the transition relay node from the source parent node may be processed using the protocol stack corresponding to the source parent node, and the target downlink data received by the transition relay node from the target parent node may be processed using the protocol stack corresponding to the target parent node. For example, as shown in FIG. 12, the MT of IAB node 3 has a BAP entity, an RLC entity, a MAC entity, and a PHY entity (peered to those of IAB node 1 and IAB node 4, respectively). It should be noted that the transition relay node may have only one BAP entity or two BAP entities. For details, please refer to the above description.

[0215] Optionally, one or more other relay nodes may be between the access relay node and the transition relay node. In this case, on the link between the access relay node and the transition relay node, the DU of each node has a BAP entity, an RLC entity, a MAC entity, and a PHY entity (peered with those of the MT of the child node). This is not limited in this embodiment of the present application.

[0216] Optionally, the access relay node and the transition relay node may be the same node, i.e., the handover occurs to the access relay node, in which case the access relay node has the protocol stack of the DU of IAB node 2 and the protocol stack of the MT of IAB node 3 in FIG.

[0217] As shown in Figure 12, two adjacent nodes between a source parent node and a source donor node, or between a target parent node and a target donor node, have peer protocol stacks. For details, please refer to the contents of Figure 7. The details will not be described again in this specification.

[0218] In the above embodiment, in the downlink, the access relay node distinguishes the data corresponding to the source donor node and / or the data corresponding to the target donor node based on the different GTP-U tunnels, maps the data to different LCHs, and transmits the data to the terminal, so that the terminal distinguishes the data corresponding to the source donor node and / or the data corresponding to the target donor node. In the uplink, the access relay node distinguishes the data corresponding to the source donor node and / or the data corresponding to the target donor node based on the different LCHs, maps the data to different GTP-U tunnels, and transmits the data to the source donor node and / or the target donor node.

[0219] In another possible implementation, in the downlink, downlink data packets may carry routing identifier (routing ID) information, and the access relay node may distinguish data corresponding to the source donor node and / or data corresponding to the target donor node based on the routing identifier information.

[0220] Specifically, the routing identifier information includes a BAP address and a path identifier (path ID) of the access relay node, and the access relay node may distinguish whether the downlink data packet is from the source donor node or the target donor node based on the BAP address carried in the routing identifier information, and further map the downlink data packet to a separate LCH and send the downlink data packet to the terminal. The source donor node and the target donor node respectively assign two different BAP addresses to the access relay node, and the routing identifier information in the downlink data packet sent by the source donor node carries the BAP address assigned to the access relay node by the source donor node, and the routing identifier information in the downlink data packet sent by the target donor node carries the BAP address assigned to the access relay node by the target donor node.

[0221] To ensure that the BAP address assigned to the access relay node by the source donor node is different from the BAP address assigned to the access relay node by the target donor node, in the handover preparation process, the source donor node may send the BAP address assigned to the access relay node by the source donor node to the target donor node, so that the target donor node generates a BAP address different from the BAP address assigned to the access relay node by the source donor node. In an example, the source donor node may include the BAP address assigned to the access relay node by the source donor node in a handover request message and send the handover request message to the target donor node. The target donor node may include the BAP address assigned to the access relay node by the target donor node in a handover command message (sometimes referred to as an RRC reconfiguration message) and send the handover command message to the access relay node via the source donor node.

[0222] The solution provided in this application will be described below with reference to Figures 13 to 16. The contents of Figures 13 to 16 and the contents of the protocol stack in Figure 12 may be mutually referenced.

[0223] In the methods of Figures 13, 14, 15, and 16, the first relay node is the access relay node of the terminal (or the first relay node may be understood to be the parent node of the terminal), and this first relay node may also be called the access relay node. A donor-node-to-donor-node handover may occur to the first relay node, specifically, the first relay node is handed over from the source donor node to the target donor node. Alternatively, a donor-node-to-donor-node handover may occur to a relay node (also called the second relay node) on a link between the first relay node and the source donor node, specifically, the first relay node is connected to the second relay node, and the second relay node is handed over from the source donor node to the target donor node. For the contents of the donor-node-to-donor-node handover, please refer to the contents of Figures 10 and 11. The donor-node-to-donor-node handover in Figure 11 is used as an example. The first relay node may be IAB node 2 in FIG. 11, and the second relay node may be IAB node 3 in FIG.

[0224] 13 is a schematic flowchart of an LCH configuration method according to an embodiment of the present application. As shown in FIG. 13, the method of FIG. 13 includes the following steps:

[0225] S100: A source donor node or a target donor node sends a first indication information to a first relay node.

[0226] S100 is optional.

[0227] The first relay node may generate, based on the first indication information, configuration information of a second LCH corresponding to the first bearer, where the second LCH is for transmitting PDCP data corresponding to the target donor node.

[0228] Optionally, the first indication information may be carried in the first message.

[0229] Optionally, before S100, a first bearer of the terminal corresponds to a first LCH, and the first LCH is for transmitting PDCP data corresponding to a source donor node.

[0230] Optionally, in the present application, the first bearer may be a first data radio bearer (DRB).

[0231] For example, before the first relay node or the second relay node performs an inter-donor node handover, the first relay node configures a first LCH for the terminal, where the first LCH is for transmitting PDCP data corresponding to the source donor node.

[0232] Specifically, before the first relay node or the second relay node performs an inter-donor node handover, the first relay node sends air interface configuration information of a first bearer to the terminal via the source donor node, where the air interface configuration information of the first bearer includes configuration information of a bottom layer (which may include one or more of an RLC layer, a MAC layer, a PHY layer and a first LCH) generated by the first relay node for the terminal.

[0233] Optionally, the first LCH may be LCH 1 of the terminal in Figure 12, and the second LCH may be LCH 2 of the terminal in Figure 12. For details, please refer to the contents of Figure 12.

[0234] There may be multiple types of content indicated by the first indication information, which will be described below with reference to some examples.

[0235] In the example, the first indication information may be bearer granular. In other words, the first indication information has a one-to-one correspondence with one bearer of the terminal. The first indication information may indicate to the first relay node to generate configuration information of a second LCH corresponding to one bearer, may indicate that data transmission of one bearer should not be interrupted during inter-donor node handover, may indicate that DAPS handover should be configured for one bearer, or may indicate other contents. This is not limited in this embodiment of the present application.

[0236] In this example, optionally, the first indication information may include an identifier of one bearer, where the bearer includes the first bearer.

[0237] In this example, the first relay node receives a plurality of first indication information, each of the first indication information has a one-to-one correspondence with one bearer, and the first relay node may generate configuration information of a second LCH for each one or more bearers of the terminal. In this application, the first bearer is used as an example for explanation. Those skilled in the art may know that the content in this embodiment of the present application is also applicable to the case of one or more other bearers.

[0238] In another example, the first indication information may be terminal granular. In other words, the first indication information does not indicate a specific bearer. The first indication information may indicate the first relay node to generate configuration information of the second LCH for each bearer of the terminal, may indicate that data transmission of the terminal should not be interrupted during the inter-donor node handover, may indicate that DAPS handover should be configured for the terminal, or may indicate other contents. This is not limited in this embodiment of the present application.

[0239] In this example, optionally, the first indication information may not include an identifier of the bearer.

[0240] In this example, the first relay node may generate configuration information of the second LCH for each bearer (including the first bearer) of the terminal. In this application, the first bearer is used as an example for explanation. Those skilled in the art may know that the content in this embodiment of the present application is also applicable to the cases of one or more other bearers.

[0241] The first indication information may be carried in the first message. There may be several situations when the source donor node or the target donor node sends the first message. The following will be described with reference to some examples.

[0242] It should be noted that if an inter-donor node handover occurs to a first relay node, the first relay node may detect the inter-donor node handover. For example, the first relay node may receive a handover command from a target donor node via a source donor node, and the first relay node may initiate a random access request to the target donor node. Then, after accessing the target donor node, the first relay node may establish a connection with the target donor node. If an inter-donor node handover occurs to a second relay node, the second relay node may detect the inter-donor node handover. Those skilled in the art may understand that the operations performed by the first relay node may alternatively be performed by the second relay node. However, if an inter-donor node handover occurs to a second relay node, the first relay node may not detect the handover. However, after the second relay node accesses the target donor node and the second relay base station establishes a connection with the target donor node, the descendant node of the second relay node sequentially establishes a connection with the target donor node to provide data transmission services to the terminal. Thus, the first relay node can detect the establishment of a connection with the target donor node. Thus, regardless of whether the inter-donor node handover occurs at the first relay node or the second relay node, the first relay node establishes a connection with the target donor node. The establishment of a connection in this specification may include the establishment of one or both of an F1 interface and a GTP-U tunnel.

[0243] In an example, after establishing a connection with the target donor node, a first relay node may receive a first message from the target donor node.

[0244] Optionally, in this example, the first message may be a UE context setup request message.

[0245] In another example, a first relay node may receive a first message from a source donor node prior to establishing a connection with a target donor node.

[0246] Specifically, when the source donor node determines that an inter-donor node handover will occur to the first relay node or the second relay node, the source donor node may send a handover request message to the target donor node. Before the source donor node makes the handover decision and sends the handover request message to the target donor node, or after the source donor node sends the handover request message to the target donor node, the first relay node receives a first message from the source donor node.

[0247] Optionally, in another example, the first message may be a UE context modification request message.

[0248] S101: A first relay node generates configuration information of a second LCH.

[0249] Optionally, S100 may be present, and the first relay node generates configuration information of the second LCH based on the first indication information.

[0250] Optionally, S100 may not exist. In an example, after the first relay node receives a connection establishment request from the target donor node, the first relay node generates configuration information of the second LCH. Optionally, the connection establishment request may be a GTP tunnel establishment request and / or an F1 interface establishment request, or the connection establishment request may have another name. This is not limited in this embodiment of the present application.

[0251] In the above example, after receiving a connection establishment request from the target donor node, the first relay node may generate configuration information of the second LCH for each bearer (including the first bearer) of the terminal. In this specification, the first bearer is used as an example for explanation. Those skilled in the art may know that the content in this embodiment of the present application is also applicable to the cases of one or more other bearers.

[0252] S102: The first relay node transmits configuration information of the second LCH to the terminal.

[0253] It may be understood that through S101 and S102, the first relay node configures the second LCH for the first DRB of the terminal, whereby the first bearer corresponds to the first LCH and the second LCH.

[0254] Optionally, the first bearer corresponds to the first LCH and the second LCH may be understood as the first LCH and the second LCH are configured for the first bearer, the first bearer is associated with the first LCH and the second LCH, the first bearer may use the first LCH and the second LCH, or the first bearer has the ability to use the first LCH and the second LCH, but whether the first bearer actually uses the first LCH and the second LCH depends on whether there is PDCP data corresponding to the source donor node and PDCP data corresponding to the target donor node. This is not limited in this embodiment of the present application. For example, in a period of time, there is only PDCP data corresponding to the source donor node and no PDCP data corresponding to the target donor node. Therefore, only the first LCH is used and the second LCH is not used. Alternatively, a first bearer corresponding to a first LCH and a second LCH may be understood to mean that when the first bearer uses the second LCH, the first LCH is maintained, is not released, is still in an active state, etc.

[0255] Optionally, the first bearer corresponding to the first LCH and the second LCH may be understood as the first bearer corresponding to both the first LCH and the second LCH, specifically, at one or more points in time or periods, the first bearer corresponds to both the first LCH and the second LCH.

[0256] Optionally, the configuration information of the second LCH includes one or more of an identifier of the second LCH, a priority of the second LCH, and a bearer identifier of the first DRB.

[0257] The first LCH is for transmitting PDCP data corresponding to a source donor node, and the second LCH is for transmitting PDCP data corresponding to a target donor node.

[0258] Optionally, the first LCH corresponds to a GTP-U tunnel between the first relay node and the source donor node, and the second LCH corresponds to a GTP-U tunnel between the first relay node and the target donor node. For details, please refer to the contents of Figure 12. The details will not be described again in this specification.

[0259] Optionally, the first LCH corresponds to a BAP address assigned by a source donor node to the first relay node, and the second LCH corresponds to a BAP address assigned by a target donor node to the first relay node. For details, please refer to the contents of Figure 12. The details will not be described again in this specification.

[0260] In a possible implementation, S102 may include: the first relay node sends configuration information of the second LCH to the terminal via the target donor node;

[0261] Specifically, the first relay node may send configuration information of the second LCH to the target donor node, and the target donor node generates a second message, the second message includes a third message, and the third message includes the configuration information of the second LCH. The target donor node sends the second message to the source donor node, and then the source donor node sends the third message to the terminal via the first relay node. For example, the third message may be an RRC reconfiguration message and may be referred to as a handover command. The second message may be a handover request response message.

[0262] The source donor node forwards the third message to the target donor node to avoid a situation in which the target donor node cannot send a message to the terminal on its own before the target donor node and the terminal conduct security negotiation based on the PDCP configuration information corresponding to the target donor node.

[0263] Optionally, in addition to the configuration information of the second LCH, the third message may further include one or more of the following: air interface configuration information of the first bearer, PDCP configuration information corresponding to the source donor node, PDCP configuration information corresponding to the target donor node, and a BAP address assigned to the first relay node by the target donor node. The air interface configuration information of the first bearer and the PDCP configuration information corresponding to the source donor node may be sent to the target donor node by the first relay node or the source donor node, and the PDCP configuration information corresponding to the target donor node may be generated by the target donor node. As described below.

[0264] Optionally, the third message may include air interface configuration information of the first bearer. Optionally, the air interface configuration information of the first bearer may include configuration information of the first LCH. For details, please refer to the above description. The third message includes configuration information of the second LCH and air interface configuration information of the first bearer. For the air interface configuration, the terminal replaces the existing air interface configuration between the terminal and the first relay node with the received configuration information of the second LCH and the air interface configuration information of the first bearer in a full configuration manner, so that the terminal performs data transmission with the first relay node based on the updated air interface configuration. Two LCHs are configured for the first bearer, one for transmitting data corresponding to the source donor node and the other for transmitting data corresponding to the target donor node, ensuring that the service transmission of the terminal is not interrupted during the handover of the first relay node or the handover of the second relay node.

[0265] Optionally, the third message may not include air interface configuration information of the first bearer, but may include configuration information of the second LCH. In this case, after the terminal receives the third message, to the air interface configuration of the first bearer, the terminal may add the second LCH in an incremental configuration manner based on the existing air interface configuration of the first bearer to save communication resources.

[0266] Optionally, the third message may include PDCP configuration information corresponding to the target donor node, but may not include PDCP configuration information corresponding to the source donor node. After receiving the third message, the terminal adds PDCP configuration information corresponding to the target donor node to the PDCP entity of the first bearer. Before receiving the third message, it may be understood that the PDCP entity of the first DRB of the terminal includes PDCP configuration information corresponding to the source donor node. After receiving the third message, to the PDCP configuration of the first bearer, the terminal may add PDCP configuration information corresponding to the target donor node in an incremental configuration manner based on the original PDCP entity of the first bearer. In addition, the third message includes configuration information of the second LCH and PDCP configuration information corresponding to the target donor node, which may imply that the configuration information of the second LCH corresponds to the PDCP configuration information corresponding to the target donor node. Specifically, in the downlink direction, data received by the terminal via the second LCH is processed using the PDCP configuration information corresponding to the target donor node, and in the uplink direction, the terminal may transmit uplink data that has been processed using the PDCP configuration information corresponding to the target donor node via the second LCH.

[0267] Optionally, the third message may include PDCP configuration information corresponding to the target donor node and PDCP configuration information corresponding to the source donor node. Thus, for the PDCP configuration of the first bearer, the terminal may replace the PDCP configuration information corresponding to the source donor node with the PDCP configuration information corresponding to the source donor node and the PDCP configuration information corresponding to the target donor node for the PDCP entity of the first bearer in a full configuration manner, so that the terminal performs data transmission with the first relay node based on the updated air interface configuration. Two LCHs are configured for the first bearer, one for transmitting data corresponding to the source donor node, which is processed using the PDCP configuration information corresponding to the source donor node, and the other for transmitting data corresponding to the target donor node, which is processed using the PDCP configuration information corresponding to the target donor node, to ensure that the service transmission of the terminal is not interrupted during the handover of the first relay node or the handover of the second relay node.

[0268] Optionally, there may be several situations when the first relay node sends the configuration information of the second LCH to the target donor node. For example, the first relay node sends the configuration information of the second LCH to the target donor node after the first relay node establishes a connection with the target donor node or before the first relay node establishes a connection with the target donor node. The following description will be given with reference to some implementations.

[0269] In implementation, after establishing a connection with the target donor node, the first relay node sends configuration information of the second LCH to the target donor node.

[0270] For example, the first relay node sends a fourth message to the target donor node, where the fourth message includes the configuration information of the second LCH. Then, the target donor node sends a second message to the source donor node, and the source donor node sends a third message to the terminal. For the contents of the second message and the third message, please refer to the above description.

[0271] It may be understood that when S100 is present, after the first relay node establishes a connection with the target donor node, the first relay node may first receive a first message carrying first indication information from the target donor node, and then the first relay node sends a fourth message to the target donor node.

[0272] Optionally, the first message may be a UE context setup request message, and the fourth message may be a UE context setup response message.

[0273] Optionally, S100 may not exist. After the first relay node receives the first message from the target donor node, the first relay node generates configuration information of the second LCH, and then the first relay node sends a fourth message to the target donor node. For details, please refer to the above.

[0274] Optionally, the fourth message may further include air interface setting information of the first bearer, such that the third message forwarded by the target donor node to the terminal via the source donor node may include the air interface setting information of the first bearer.

[0275] Optionally, the fourth message may not include the air interface configuration information of the first bearer. After the source donor node decides to hand over the transition relay node (i.e., the first relay node or the second relay node) from the source donor node to the target donor node, the source donor node may send the context of a descendant node of the transition relay node to the target donor node, the descendant node including a terminal, the context of the descendant node of the transition relay node including a context of the terminal, the context of the terminal including the PDCP configuration information corresponding to the source donor node and the air interface configuration information of the first DRB. Thus, the target donor node may obtain the PDCP configuration information corresponding to the source donor node and the air interface configuration information of the first DRB.

[0276] In another implementation, before the first relay node establishes a connection with the target donor node, the first relay node sends configuration information of the second LCH to the source donor node, and then the source donor node sends the configuration information of the second LCH to the target donor node.

[0277] It may be understood that because the first relay node has not established a connection with the target donor node, the first relay node cannot transmit information directly to the target donor node, but may transmit information to the target donor node via the source donor node.

[0278] For example, the first relay node sends a fifth message to the source donor node, and the source donor node sends a sixth message to the target donor node, where the fifth message and the sixth message include the configuration information of the second LCH. Then, the target donor node sends a second message to the source donor node, and the source donor node sends a third message to the terminal. For the contents of the second message and the third message, please refer to the above.

[0279] It may be understood that when S100 is present, before the first relay node establishes a connection with the target donor node, the first relay node may first receive a first message carrying first indication information from the source donor node, then send a fifth message to the source donor node, and the source donor node sends a sixth message to the target donor node.

[0280] Specifically, when the source donor node determines that the first relay node or the second relay node should perform handover, the source donor node sends a first message to the first relay node, and then the first relay node sends a fifth message to the source donor node, whereby the source donor node sends a sixth message to the target donor node.

[0281] Optionally, the first message may be a UE context modification request message, the fifth message may be a UE context modification response message, and the sixth message may be a handover request message.

[0282] Optionally, the fifth message may include the air interface configuration information of the first bearer. Alternatively, the fifth message may not include the air interface configuration information of the first bearer, and the source donor node has the air interface configuration information of the first bearer. For example, before the terminal establishes a connection with the source donor node, the source donor node receives the air interface configuration information of the first bearer from the first relay node and stores the air interface configuration information of the first bearer.

[0283] Optionally, the sixth message may include air interface configuration information of the first bearer and / or PDCP configuration information corresponding to the source donor node. Optionally, the sixth message may be sent by the source donor node to the target donor node after the source donor node decides to handover a transition relay node (i.e., the first relay node or the second relay node) from the source donor node to the target donor node.

[0284] S103: The terminal receives second indication information.

[0285] The terminal may configure a second LCH for the first bearer based on the second indication information.

[0286] There may be multiple types of content indicated by the second indication information, which will be described below with reference to some examples.

[0287] In the example, the second indication information may be bearer granular, in other words, the second indication information has a one-to-one correspondence with one bearer. The second indication information may indicate to the terminal to configure a first LCH and a second LCH for one bearer, may indicate to the terminal to configure a second LCH for one bearer, may indicate to associate one bearer with two LCHs, i.e., a first LCH and a second LCH, may indicate that both the first LCH and the second LCH of one bearer are used for data transmission of the bearer, may indicate to the terminal not to replace the first LCH of one bearer with the second LCH of the bearer, may indicate to the terminal to start or activate a function of PDCP dual setting for one bearer, where the PDCP dual setting may include PDCP setting information corresponding to the source donor node and PDCP setting information corresponding to the target donor node, may indicate that data transmission of one bearer should not be interrupted during inter-donor node handover, may indicate that DAPS handover should be configured for one bearer, or may indicate other contents, which are not limited in this embodiment of the present application.

[0288] In this example, optionally, the second indication information may include an identifier of a bearer, where the bearer includes the first bearer.

[0289] In this example, the first relay node receives a plurality of second indication information, 2 Each of the indication information has a one-to-one correspondence with one bearer. The first relay node may configure a second LCH for each one or more bearers of the terminal, the second LCH corresponding to the bearer. In this application, the first bearer is used as an example for explanation. Those skilled in the art may know that the content in this embodiment of the present application is also applicable to the case of one or more other bearers.

[0290] In another example, the second indication information may be terminal granular. In other words, the second indication information does not indicate a specific bearer. The second indication information may indicate that the first relay node configures the first LCH and the second LCH for each bearer of the terminal, indicate the terminal to configure the second LCH for each bearer, indicate that each bearer is associated with two LCHs, or indicate that the first LCH of each bearer is not replaced with the second LCH of the bearer, etc. For other contents that may be indicated by the second indication information, please refer to the contents described when the second indication information may be terminal granular. The difference is that the object indicated by the second indication information is a terminal or each bearer of the terminal. Alternatively, the second indication information may indicate that the data transmission of the terminal should not be interrupted during the inter-donor node handover, may indicate that a DAPS handover should be performed, or may indicate other contents. This is not limited in this embodiment of the present application.

[0291] In this example, optionally, the second indication information may not include an identifier of the bearer.

[0292] In this example, the first relay node may configure a second LCH for each bearer (including the first bearer) of the terminal. In this application, the first bearer is used as an example for explanation. Those skilled in the art may know that the contents in this embodiment of the present application are also applicable to the case of one or more other bearers. In this case, in S102, the terminal may receive configuration information of a second LCH corresponding to each of the one or more other bearers.

[0293] There are several ways for the terminal to receive the second indication information, which will be described below with reference to some possible implementations.

[0294] In a possible implementation, the target donor node transmits the second indication information to the terminal via the first relay node.

[0295] In this implementation, the second indication information is generated by the target donor node.

[0296] In this implementation, the second indication information and the configuration information of the second LCH sent by the target donor node to the terminal in S102 may be carried in a single message. For example, the message is a third message in S102, which may further include one or more of the air interface configuration information of the first bearer, the PDCP configuration information corresponding to the source donor node, and the PDCP configuration information corresponding to the target donor node, and the BAP address assigned to the first relay node by the target donor node. For details, refer to the process of the relay node sending the configuration information of the second LCH to the terminal via the target donor node in S102.

[0297] In another implementation, the first relay node transmits the second indication information to the terminal.

[0298] In this implementation, the second indication information is generated by the first relay node.

[0299] Optionally, when the first relay node generates configuration information of the second LCH, the first relay node may generate second indication information, and then send the second indication information to the terminal.

[0300] For example, the second indication information may be carried in a MAC CE.

[0301] In yet another implementation, the second indication information may be sent by the source donor node to the terminal, which is not limited in this embodiment of the present application.

[0302] The terminal receives the second indication information to avoid a situation in which the terminal receives configuration information of the second LCH and erroneously assumes that the configuration information of the first LCH needs to be deleted, so as to ensure that both the first LCH and the second LCH are configured for the first bearer of the terminal, thereby reducing the probability of data transmission interruption during inter-donor node handover and improving service continuity.

[0303] S103 is optional.

[0304] S104: The terminal configures a second LCH for the first bearer.

[0305] Optionally, after S104, the terminal may send PDCP data corresponding to the source donor node through the first LCH, and the terminal may send PDCP data corresponding to the target donor node through the second LCH. The following description will be given with reference to some implementations.

[0306] Optionally, the method of FIG. 13 may further include: The target donor node sends an indication to one or more nodes (including the access relay node, the transition relay node, and one or more other nodes between the access relay node and the transition relay node) on a link between the access relay node and the transition relay node via the source donor node to initiate a dual configuration of the BAP layer, where the dual configuration of the BAP layer includes a BAP configuration corresponding to the source donor node and a BAP configuration corresponding to the target donor node. For details, please refer to the contents of FIG. 12. The details will not be described again in this specification. Alternatively, the source donor node may send an indication to one or more nodes to initiate a dual configuration of the BAP layer.

[0307] Optionally, in the method of Figure 13, the PDCP data corresponding to the source donor node includes downlink PDCP data and / or uplink PDCP data. Optionally, the PDCP data corresponding to the target donor node includes downlink PDCP data and / or uplink PDCP data.

[0308] Optionally, the PDCP data corresponding to the source donor node may be processed using the PDCP configuration information corresponding to the source donor node and specifically processed by the source donor node or the terminal, and the PDCP data corresponding to the target donor node may be processed using the PDCP configuration information corresponding to the target donor node and specifically processed by the target donor node or the terminal.

[0309] Optionally, the PDCP entity of the first bearer of the terminal includes configuration information corresponding to the source donor node and configuration information corresponding to the target donor node. For details, please refer to the contents of Figure 12. The details will not be described again in this specification.

[0310] When the PDCP data corresponding to the source donor node is downlink PDCP data, the first LCH for transmitting the PDCP data corresponding to the source donor node may be understood to mean that the first LCH is for receiving the downlink PDCP data corresponding to the source donor node. Similarly, when the PDCP data corresponding to the target donor node is downlink PDCP data, the second LCH for transmitting the PDCP data corresponding to the target donor node may be understood to mean that the second LCH is for receiving the PDCP data corresponding to the target donor node.

[0311] In the example, the source donor node processes downlink PDCP data using PDCP configuration information corresponding to the source donor node and transmits the downlink PDCP data to the first relay node. The first relay node maps the downlink PDCP data corresponding to the source donor node to the first LCH and transmits the downlink PDCP data to the terminal. The terminal may receive the downlink PDCP data corresponding to the source donor node and mapped to the first LCH from the first relay node (this may be understood as the terminal receiving the downlink PDCP data corresponding to the source donor node via the first LCH). The terminal processes the downlink PDCP data corresponding to the source donor node using the PDCP configuration information corresponding to the source donor node.

[0312] In another example, the target donor node processes downlink PDCP data using PDCP configuration information corresponding to the target donor node and transmits the downlink PDCP data to a first relay node. The first relay node maps the downlink PDCP data corresponding to the target donor node to a second LCH and transmits the downlink PDCP data to the terminal. The terminal receives the downlink PDCP data corresponding to the target donor node and mapped to the second LCH from the first relay node (this may be understood as the terminal receiving the downlink PDCP data corresponding to the target donor node via the second LCH). The terminal processes the downlink PDCP data corresponding to the target donor node using the PDCP configuration information corresponding to the target donor node.

[0313] For downlink data, there may be only one of the above two examples, or there may be both of the above two examples. Optionally, for downlink data, during an inter-donor node handover process (in this embodiment of the present application, this process includes the process from the time when the source donor node decides to perform an inter-donor node handover to the time when the source parent node of the transition relay node releases the context of the transition relay node), the time when the source donor node transmits downlink PDCP data corresponding to the source donor node to the terminal may overlap with the time when the target donor node may transmit downlink PDCP data corresponding to the target donor node to the terminal, in other words, the terminal may receive downlink PDCP data corresponding to the source donor node and downlink PDCP data corresponding to the target donor node at the same time.

[0314] When the PDCP data corresponding to the source donor node is uplink PDCP data, the first LCH for carrying the PDCP data corresponding to the source donor node may be understood to mean that the first LCH is for transmitting the uplink PDCP data corresponding to the source donor node. Similarly, when the PDCP data corresponding to the target donor node is uplink PDCP data, the second LCH for carrying the PDCP data corresponding to the target donor node may be understood to mean that the second LCH is for transmitting the uplink PDCP data corresponding to the target donor node.

[0315] In the example, the terminal processes uplink data using PDCP configuration information corresponding to the source donor node to obtain uplink PDCP data corresponding to the source donor node, maps the uplink PDCP data corresponding to the source donor node to a first LCH, and transmits the uplink PDCP data corresponding to the source donor node and mapped to the first LCH to the first relay node (this may be understood as the terminal transmitting the uplink PDCP data corresponding to the source donor node via the first LCH). After receiving the uplink PDCP data corresponding to the source donor node and mapped to the first LCH, the first relay node transmits the uplink PDCP data to the source donor node. Finally, the source donor node processes the uplink PDCP data using the configuration information corresponding to the source donor node.

[0316] In another example, the terminal processes uplink data using PDCP configuration information corresponding to the target donor node to obtain uplink PDCP data corresponding to the target donor node, maps the uplink PDCP data corresponding to the target donor node to a second LCH, and transmits the uplink PDCP data corresponding to the target donor node and mapped to the second LCH to the first relay node (this may be understood as the terminal transmitting the uplink PDCP data corresponding to the target donor node via the second LCH). After receiving the uplink PDCP data corresponding to the target donor node and mapped to the second LCH, the first relay node transmits the uplink PDCP data to the target donor node. Finally, the target donor node processes the uplink PDCP data using the configuration information corresponding to the target donor node.

[0317] Optionally, for downlink data, the first relay node may distinguish between downlink PDCP data corresponding to the source donor node and the target donor node based on the GTP-U tunnel used for downlink data transmission. Alternatively, the first relay node may distinguish between downlink PDCP data corresponding to the source donor node and the target donor node based on the BAP address carried in the downlink data.

[0318] For the uplink data, there may be only one of the above two examples, or there may be both of the above two examples. Optionally, for the uplink data, during the inter-donor node handover, the time when the terminal transmits the uplink PDCP data corresponding to the source donor node to the source donor node may be interleaved with the time when the terminal transmits the uplink PDCP data corresponding to the target donor node to the target donor node, in other words, the terminal may sometimes transmit the uplink PDCP data corresponding to the source donor node to the source donor node, or transmit the uplink PDCP data corresponding to the target donor node to the target donor node.

[0319] For the transmission process of downlink data and uplink data, please refer to the contents of Figure 12. The details will not be described again in this specification.

[0320] In addition, before the transition relay node (i.e., the first relay node or the second relay node) establishes a connection with the target donor node, the terminal transmits uplink data to the source donor node. After the transition relay node establishes a connection with the target donor node, the terminal transmits uplink data to the target donor node. However, the terminal does not detect when the transition relay node establishes a connection with the target donor node. As a result, the terminal cannot determine whether to process uplink PDCP data using PDCP configuration information corresponding to the source donor node and transmit the uplink PDCP data to the source donor node, or to process uplink PDCP data using PDCP configuration information corresponding to the target donor node and transmit the uplink PDCP data to the target donor node. The embodiments of the present application provide the following solutions for ensuring that the terminal uses correct configuration information to process uplink data and avoid service interruption caused by packet loss.

[0321] Figure 14 is a flowchart of an indication method according to an embodiment of the present application. The method of Figure 14 may be implemented independently or based on the method of Figure 13. The contents of Figure 13 and Figure 14 may be cross-referenced.

[0322] In the method of Figure 14, a first LCH and a second LCH are configured for a first bearer of a terminal. The first LCH is for transmitting PDCP data corresponding to a source donor node, and the second LCH is for transmitting PDCP data corresponding to a target donor node. For the manner of configuring the first LCH, the second LCH, and the second LCH, please refer to the contents of Figure 13.

[0323] As shown in FIG. 14, the method of FIG. 14 includes the following steps.

[0324] S200: A terminal receives third indication information. The terminal may determine, based on the third indication information, to process uplink data using PDCP configuration information corresponding to the target donor node.

[0325] Optionally, the third indication information may indicate to the terminal to transmit data to the target donor node, may indicate to the terminal to process the data using configuration information corresponding to the target donor node, may indicate that the transition relay node has accessed the target parent node or that the relay node handover has been completed, or may indicate that the transition relay node has completed PUSCH switching.

[0326] In implementation, after performing the PUSCH switching, the transition relay node sends a third indication information to the terminal.

[0327] In this embodiment of the present application, performing PUSCH switching may be understood as switching the PUSCH of the transition relay node from the source parent node to the target parent node. Specifically, the transition relay node originally sends PUSCH data (e.g., uplink PDCP data of the terminal) to the source parent node via PUSCH, but now sends PUSCH data (e.g., uplink PDCP data of the terminal) to the target parent node via PUSCH. Specifically, after sending a preamble to the target donor node and receiving a random access response (RAR) message sent by the target donor node, the transition relay node performs PUSCH switching, and the RAR message includes a UL grant resource.

[0328] In another implementation, after the transition relay node is connected to the target donor node, the transition relay node sends a third indication information to the terminal.

[0329] In this embodiment of the present application, the transition relay node being connected to the target donor node may include: an F1 interface and a GTP tunnel are established between the transition relay node and the target donor node for the first bearer, and / or routing configuration and bearer mapping configuration are completed on the path between the transition relay node and the target donor node.

[0330] Optionally, in the above two implementations, the third indication information may be carried in downlink data and sent to the terminal, for example, in a MAC header field or an RLC header field of the downlink data. Alternatively, optionally, the third indication information may be carried in control signaling and sent to the terminal. The control signaling may be MAC CE or downlink control information (DCI).

[0331] In yet another implementation, after receiving the RRC reconfiguration complete message of the transition relay node, the target donor node may send a third indication information to the terminal.

[0332] Optionally, the target donor node may send the third indication information to the terminal via an RRC message.

[0333] Optionally, the above three implementations may be applied to a scenario in which the terminal receives the configuration information of the second LCH before the first relay node establishes a connection with the target donor node. In this scenario, the third indication information is sent to the terminal after the transition relay node performs PUSCH switching, or after the transition relay node establishes a connection with the target donor node, or after the target donor node receives an RRC reconfiguration complete message, to avoid the following situation: when the terminal receives the configuration information of the second LCH, the terminal processes uplink data using PDCP configuration information corresponding to the target donor node by default and sends the uplink data to the transition relay node, but because the transition relay node has not established a connection with the target donor node, the uplink data can only be sent to the source donor node, and the source donor node cannot analyze the uplink data, resulting in uplink data loss.

[0334] In yet another implementation, the target donor node may transmit the configuration information of the second LCH and the third indication information together to the terminal via the source donor node. For example, the target donor node transmits a second message to the source donor node, the second message including the third message. The source donor node transmits a third message to the terminal, the third message including the configuration information of the second LCH and the third indication information.

[0335] S201: The terminal processes uplink data using PDCP configuration information corresponding to the target donor node according to the third indication information. Optionally, the terminal may further map the uplink PDCP data corresponding to the target donor node to a second LCH and send the uplink PDCP data to the target donor node.

[0336] Specifically, after processing the uplink data using the PDCP configuration information corresponding to the target donor node, the terminal may obtain the uplink PDCP data corresponding to the target donor node, map the uplink PDCP data corresponding to the target donor node to a second LCH, and then transmit the uplink PDCP data corresponding to the target donor node via the second LCH. After receiving the uplink PDCP data corresponding to the target donor node and mapped to the second LCH, the first relay node transmits the uplink PDCP data to the target donor node. Finally, the target donor node processes the uplink PDCP data using the configuration information corresponding to the target donor node.

[0337] Optionally, before receiving the third indication information, the terminal uses the PDCP setting information corresponding to the source donor node to process the uplink PDCP data. After receiving the third indication information, the terminal continues to process the uplink PDCP data using the PDCP setting information corresponding to the target donor node. For a detailed description of the uplink PDCP data being processed using the PDCP setting information corresponding to the source donor node or the uplink PDCP data being processed using the PDCP setting information corresponding to the target donor node, please refer to the contents of Figure 13. The details will not be described again in this specification.

[0338] In the method of Figure 14, during inter-donor node handover, the parent node of the terminal may always remain unchanged, and the terminal does not detect when the transition relay node performs PUSCH switching. The third indication information is sent to the terminal, so that the terminal can determine to process uplink data using PDCP configuration information corresponding to the target donor node, ensure that the terminal processes uplink data using correct configuration information, avoid service interruption caused by packet loss, and improve service transmission continuity.

[0339] Optionally, in another alternative implementation of S200 and S201, S200 and S201 may not exist. After receiving the configuration information of the second LCH, the terminal performs S202, specifically, the terminal processes uplink data using the PDCP configuration information corresponding to the target donor node, maps the uplink PDCP data corresponding to the target donor node to the second LCH, and sends the uplink PDCP data to the target donor node.

[0340] Optionally, this implementation may be applied to a scenario in which the terminal receives the configuration information of the second LCH after the first relay node establishes a connection with the target donor node. In this scenario, when the terminal receives the configuration information of the second LCH, the terminal processes uplink data using PDCP configuration information corresponding to the target donor node by default, and sends the uplink data to the target donor node to ensure the continuity of service transmission and reduce signaling overhead.

[0341] Figure 15 is a flowchart of an LCH deletion method according to an embodiment of the present application. The method of Figure 15 may be implemented independently or based on one or both of the methods of Figure 13 and Figure 14. The contents of Figure 13, Figure 14 and Figure 15 may be cross-referenced.

[0342] In the method of Figure 15, a first LCH and a second LCH are configured for a first bearer of a terminal. The first LCH is for transmitting PDCP data corresponding to a source donor node, and the second LCH is for transmitting PDCP data corresponding to a target donor node. For the contents of the first LCH, the second LCH, and the manner of configuring the second LCH, please refer to the contents of Figure 14.

[0343] As shown in FIG. 15, the method of FIG. 15 includes the following steps.

[0344] S301: A first relay node sends a fourth indication information to a target donor node.

[0345] The fourth indication information is used by the target donor node to indicate to the terminal to delete the first LCH.

[0346] In the implementation, after the first relay node completes transmitting PDCP data corresponding to the source donor node and buffered by the first relay node to the terminal, the first relay node transmits a fourth indication information to the target donor node.

[0347] The PDCP data corresponding to the source donor node and buffered by the first relay node is to be mapped to the first LCH of the terminal for transmission, and therefore may also be referred to as PDCP data corresponding to the first LCH.

[0348] In this implementation, optionally, before S301, the method further includes: the first relay node receives a seventh message, the seventh message being for deleting an F1 interface and / or a GTP-U tunnel between the first relay node and the source donor node; After the first relay node receives the seventh message and completes sending PDCP data corresponding to the source donor node and buffered by the first relay node to the terminal, the first relay node sends a fourth indication information to the target donor node.

[0349] In an example, the method further includes: the target donor node sends an eighth message to the source donor node to trigger the source donor node to send a seventh message to the first relay node. For example, the seventh message and the eighth message may be UE context release messages.

[0350] Optionally, the seventh message may include an ID of the first LCH and / or indication information to indicate to the first relay node to delete the GTP-U tunnel between the first relay node and the source donor node.

[0351] Optionally, the first relay node completing transmission of the PDCP data corresponding to the source donor node and buffered by the first relay node to the terminal may be understood as the first relay node transmitting all of the PDCP data corresponding to the source donor node and buffered by the first relay node to the terminal, or no PDCP data corresponding to the source donor node is buffered at the first relay node, or a buffer corresponding to the first LCH at the first relay node is empty.

[0352] Optionally, there may be multiple situations for the content indicated by the fourth indication information. For example, the fourth indication information may indicate deleting the first LCH, may indicate that the first relay node has completed transmitting PDCP data corresponding to the first LCH and buffered by the first relay node to the terminal, may indicate that the buffer corresponding to the first LCH in the first relay node is empty, or may indicate other content. This is not limited in this embodiment of the present application. Optionally, the fourth indication information may include an ID of the first LCH and / or an identifier of the first bearer.

[0353] Optionally, the fourth indication information may be carried in a UE context modification required message. S302: The target donor node sends the fifth indication information to the first relay node.

[0354] After receiving the fourth indication information, the target donor node may determine a fifth indication information.

[0355] Optionally, the fifth indication information and the fourth indication information may be the same or different.

[0356] Optionally, there may be multiple situations for the content indicated by the fifth indication information. For example, the fifth indication information may indicate the terminal to delete the first LCH, may indicate the terminal to release the function of PDCP dual configuration, may indicate the terminal to delete the PDCP configuration information corresponding to the source donor node, or may indicate other content. This is not limited in this embodiment of the present application.

[0357] Optionally, the fifth indication information may be carried in an RRC message. The RRC message is carried in a UE context modification request message. The UE context modification request message may be an F1AP message.

[0358] Optionally, the fifth indication information may include an ID of the first LCH and / or an identifier of the first bearer.

[0359] S303: The first relay node sends fifth indication information to the terminal.

[0360] Optionally, S303 may be: The first relay node sends an RRC message to the terminal.

[0361] S304: The terminal deletes the first LCH of the first bearer based on the fifth indication information.

[0362] Optionally, when the fifth indication information includes the ID of the first LCH, the terminal deletes the first LCH based on the fifth indication information.

[0363] Optionally, if the fifth indication information does not include the ID of the first LCH, after receiving the fifth indication information, the terminal may delete the first LCH by default, i.e., delete the LCH corresponding to the source donor node by default.

[0364] Optionally, the method of FIG. 15 may further include: the first relay node deletes the configuration information of the first LCH, deletes one or both of the F1 interface and the GTP-U tunnel between the first relay node and the source donor node, etc. In an example, after S302 or S303, the first relay node may perform one or more of the following operations: deletes the configuration information of the first LCH, deletes the F1 interface between the first relay node and the source donor node, deletes the GTP-U tunnel between the first relay node and the source donor node, etc. It may be understood that after S302 or 303, the first relay node no longer needs to transmit messages or data between the terminal and the source donor node, and the first relay node deletes the configuration information of the first LCH, deletes the F1 interface between the first relay node and the source donor node, and / or deletes the GTP-U tunnel between the first relay node and the source donor node to save resources. Alternatively, in another example, before S302, the first relay node may perform one or more of the following operations: deleting the F1 interface between the first relay node and the source donor node, deleting the GTP-U tunnel between the first relay node and the source donor node, etc.

[0365] In the method of Figure 15, the terminal may delete the first LCH according to the network side indication to save air interface resources. In addition, after the first relay node completes sending PDCP data corresponding to the source donor node and buffered by the first relay node to the terminal, the first relay node sends fourth indication information to the target donor node, and the target donor node further indicates the terminal to delete the first LCH, so that the terminal deletes the first LCH only after all of the PDCP data corresponding to the source donor node is sent to the terminal via the first LCH, thereby ensuring data transmission continuity and avoiding data transmission interruption (caused by the terminal still receiving the PDCP data corresponding to the source donor node after the first LCH is deleted but cannot process or analyze the PDCP data corresponding to the source donor node).

[0366] Figure 16 is a flow chart of an indication method according to an embodiment of the present application. The method of Figure 16 may be implemented independently or based on one or more of the methods of Figure 13, Figure 14, and Figure 16. The contents of Figure 13 to Figure 16 may be cross-referenced. As shown in Figure 16, the method includes the following steps:

[0367] S401: A source donor node sends capability indication information to a target donor node.

[0368] Optionally, the capability indication information indicates that the transition relay node supports a capability. For example, the capability indication information may indicate that the transition relay node supports maintaining a connection to the source donor node during handover, indicate that the transition relay node supports maintaining a connection to both the source donor node and the target donor node during handover, indicate that the transition relay node supports DAPS, indicate that the transition relay node supports parallel PDSCH data transmission during handover, indicate that the transition relay node supports parallel PUSCH data transmission during handover, or indicate other content. This is not limited in this embodiment of the present application.

[0369] It should be noted that in this specification, an example in which the capability indication information is of the granularity of a transition relay node is used for explanation. Those skilled in the art may understand that the capability indication information in this specification may also be of the granularity of a bearer of a terminal. For example, the capability indication information may indicate that a first bearer of a terminal supports DAPS, parallel PDSCH transmission, or PUSCH transmission during handover, etc. This is not limited in this embodiment of the present application.

[0370] Optionally, the capability indication information may be generated by a source donor node.

[0371] Optionally, the capability indication information may also be transmitted by the transition relay node to the source donor node.

[0372] In an example, the capability indication information may be carried in a handover request message sent by the source donor node to the target donor node.

[0373] Optionally, in this example, the handover request message may further include context information of the transition relay node and descendant nodes of the transition relay node, including one or more of an identifier of the relay node accessed by the transition relay node and descendant nodes (e.g., IAB-DU id), an identifier of the relay node accessed by the transition relay node and descendant nodes (e.g., cell group identifier (CGI)), and a cell radio network temporary identifier (C-RNTI) of the transition relay node and descendant nodes in the accessed cell.

[0374] Optionally, the handover request message may be a handover request message for a group handover. A group handover may be understood as a descendant node of the transition relay node performing a handover together with the transition relay node when the transition relay node performs a handover. The transition relay node and the descendant node may be regarded as a group, and the group performs the handover.

[0375] S401 is optional.

[0376] S402: The target donor node sends a sixth indication information to the source donor node.

[0377] In the example, the sixth indication information is carried in an RRC reconfiguration message, and the RRC reconfiguration message is carried in a handover request response message sent by the target donor node to the source donor node. It can be understood that the target donor node sends the handover request response message to the source donor node. The handover request response message includes an RRC reconfiguration message, and the RRC reconfiguration message includes the sixth indication information.

[0378] Optionally, when S401 is present, the target donor node determines the sixth indication information based on the capability indication information. When S402 is not present, the target donor node generates the sixth indication information by default assuming that the transition relay node has the capability indicated by the capability indication information.

[0379] Optionally, there may be multiple cases for the contents indicated by the sixth indication information. For example, the sixth indication information may indicate that the transition relay node maintains a connection to the source donor node during handover, may indicate that the transition relay node maintains a connection to both the source donor node and the target donor node during handover, may indicate that the source donor node will transmit PDCP data corresponding to the source donor node to the transition relay node during handover, may indicate that the transition relay node initiates DAPS, may indicate that the transition relay node implements parallel PDSCH data transmission during handover, may indicate that the transition relay node implements parallel PUSCH data transmission during handover, or may indicate other contents. This is not limited in this embodiment of the present application. The handover process in the present application may include a process from a time when the transition relay node receives an RRC reconfiguration message from the source donor node to a time when the transition relay node receives a message from the target donor node to indicate that the transition relay node releases protocol stack resources between the transition relay node and the source parent node.

[0380] It should be noted that a transition relay node performing parallel PDSCH data transmission may be understood as the transition relay node may transmit both PDSCH data corresponding to the source donor node and PDSCH data corresponding to the target donor node. Similarly, a transition relay node performing parallel PUSCH data transmission may be understood as the transition relay node may transmit both PUSCH data corresponding to the source donor node and PUSCH data corresponding to the target donor node.

[0381] Optionally, the above provides an explanation using an example in which the sixth indication information is of the granularity of the transition IAB node. Optionally, the sixth indication information may be of the granularity of the terminal bearer. For details, please refer to the description that the capability indication information may be of the granularity of the terminal bearer. The details will not be described again in this specification.

[0382] Optionally, the capability indication information and the sixth indication information may be the same and may be carried in the same information element, or the capability indication information and the sixth indication information may be different.

[0383] Optionally, S402 is optional. Either S401 or S402 may occur, and both S401 and S402 may occur.

[0384] S403: The source donor node sends a sixth indication information to the transition relay node.

[0385] In an example, the sixth indication information may be carried in an RRC reconfiguration message sent by the source donor node to the transition relay node.

[0386] S404: The transition relay node maintains a connection to the source donor node during the handover based on the sixth indication information.

[0387] S404 is optional.

[0388] One or more of the methods in Figures 13 to 16 may be implemented together. Hereinafter, the contents in the embodiments of the present application will be further described with reference to Figures 17A to 18D. Figures 17A to 17E and Figures 18A to 18D are respectively described using the inter-donor node handover scenario in Figure 11 as an example. The contents in Figures 17A to 18D are not only applicable to the scenario in Figure 11, but also applicable to other inter-donor node handover scenarios.

[0389] 17A to 17E and 18A to 18D are respectively schematic diagrams of an inter-donor node handover method according to an embodiment of the present application, illustrating a handover process in which IAB node 3 is handed over from IAB node 1 to IAB node 4. The handover process is mainly divided into three processes: handover preparation, handover execution, and handover completion. In each process, the terminal may perform data transmission with IAB donor CU1 and / or IAB donor CU2, which is illustrated by dashed arrows in FIG. 17A to 18D. The difference is that in FIG. 17A to 17E, the second LCH of the first bearer is configured for the terminal in the handover completion process, while in FIG. 18A to 18D, the second LCH of the first bearer is configured for the terminal in the handover preparation process. Hereinafter, FIG. 17A to 17E and FIG. 18A to 18D will be described separately.

[0390] As shown in Figures 17A to 17E, the method includes the following steps.

[0391] The processes of S501 to S508 describe a handover preparation process, and the contents of Figures 17A to 17E and the contents of Figures 18A to 18D may be cross-referenced.

[0392] S501: IAB node 3 sends a measurement report to IAB donor CU1.

[0393] Based on the measurement configuration received from the IAB donor CU1, the IAB node 3 may measure the serving cell of the accessed IAB node 1 and the neighboring cell served by the IAB node 4 to obtain a measurement report, and send the measurement report to the IAB donor CU1.

[0394] S502: IAB donor CU1 performs handover decision.

[0395] IAB donor CU1 may decide to handover IAB node 3 from IAB node 1 to IAB node 4 based on the received measurement report.

[0396] For example, when the signal quality of the cell of IAB node 4 is better than the signal quality of the cell of IAB node 1, IAB donor CU1 may decide to handover IAB node 3 from IAB node 1 to IAB node 4.

[0397] S503: The IAB donor CU1 sends a handover request message to the IAB donor CU2, where the handover request message includes capability indication information.

[0398] Optionally, the handover request message may carry context information of IAB node 3 and descendant nodes of IAB node 3. For example, descendant nodes of IAB node 3 include IAB node 2 and terminal 1, and the handover request message may carry context information of IAB node 3, IAB node 2, and terminal 1. For details, see the context information of transition relay nodes and descendant nodes of transition relay nodes in S401.

[0399] The handover request message may include capability indication information, see S401 for details.

[0400] S504: IAB donor CU2 sends a context setting request message to IAB node 4.

[0401] S505: IAB node 4 sends a context setting application message to IAB donor CU2.

[0402] S506: The IAB donor CU2 sends a handover request response message to the IAB donor CU1, where the handover request response message includes a first RRC reconfiguration message, and the first RRC reconfiguration message includes the sixth indication information.

[0403] For the contents of the sixth indication information, please refer to the contents of S402.

[0404] The process from S509 to S513 describes the handover execution process, i.e., the random access process between the IAB node 3 and the IAB donor DU 2.

[0405] S507:IAB donor CU1 sends a first RRC reconfiguration message to IAB node 3, where the first RRC reconfiguration message includes the sixth indication information.

[0406] S508: IAB node 3 starts DAPS based on the sixth indication information.

[0407] For the relevant contents of DAPS, please refer to the contents of Figures 8 and 12.

[0408] The IAB node 3 initiating DAPS may be understood as meaning that the IAB node 3 may maintain a connection to the IAB donor CU1 during the handover.

[0409] S509: IAB node 3 sends a preamble to IAB node 4.

[0410] S510: IAB node 4 sends the RAR to IAB node 3.

[0411] S511: IAB node 3 performs PUSCH switch.

[0412] The IAB node 3 performing PUSCH switching can be understood as the IAB node 3 stopping transmission of uplink data (e.g., uplink data of a terminal) to the IAB node 1 and starting transmission of uplink data (e.g., uplink data of a terminal) to the IAB node 4, that is, the PUSCH of the IAB node 3 being switched from the IAB node 1 to the IAB node 4. The PUSCH of the IAB node 3 is switched to the IAB node 4, and the IAB node 3 cannot transmit uplink data to the IAB node 1, but the IAB node 3 can still transmit downlink data to the IAB node 1. Please refer to the above description for the contents of the PUSCH switching.

[0413] Optionally, after S511, the IAB node 3 may send a seventh indication information to the terminal 1, and the terminal 1 may stop processing uplink data using the PDCP configuration information corresponding to the source donor node and stop mapping the processed uplink data to the first LCH based on the seventh indication information. For example, the seventh indication information may indicate the terminal to stop sending uplink data to the source donor node. This avoids the case that after PUSCH switching, the IAB node 3 still receives uplink data corresponding to the source donor node, and the IAB node 3 sends uplink data corresponding to the source donor node to the target donor node, but the target donor node cannot parse the uplink data, resulting in packet loss, interruption of data transmission, and waste of buffer resources of nodes between the IAB node 3 and the target donor node.

[0414] S512: IAB node 3 sends an RRC reconfiguration complete message to IAB donor DU 2.

[0415] S513: The IAB donor DU2 sends an uplink RRC message transfer (UL RRC transfer) message to the IAB donor CU2, where the message includes an RRC reconfiguration complete message.

[0416] S514 to S536 describe the handover completion process.

[0417] S514: An F1 interface is established between IAB node 3 and IAB donor CU2.

[0418] Optionally, after obtaining the cell identification of the IAB node 3 in the IAB donor CU2, the IAB node 3 may initiate an F1 connection establishment procedure to the IAB donor CU2, and then an F1 interface is established between the IAB node 3 and the IAB donor CU2.

[0419] S515: An F1 interface is established between IAB node 2 and IAB donor CU2.

[0420] S516 to S521 describe a process of configuring a second LCH of a first bearer, and the contents here and the contents of Fig. 13 may be cross-referenced. For example, S516 to S521 may correspond to a case where the first relay node receives first indication information from the target donor node after the first relay node establishes a connection to the target donor node, and the first relay node transmits configuration information of the second LCH to the target donor node. It can be understood that the first message in Fig. 13 is a context configuration request message in S516, the fourth message is a UE context configuration response message in S518, the second message in Fig. 13 is a handover request response message in S506, and the third message in Fig. 13 is a second RRC reconfiguration message in S519 to S521.

[0421] S516: IAB donor CU2 sends a UE context setting request message to IAB node 2, where the UE context setting request message includes first indication information.

[0422] Optionally, the UE context setting request message may be for establishing a GTP tunnel and may be referred to as a GTP tunnel establishment request message. Optionally, the UE context setting request message may include a GTP tunnel identifier.

[0423] In another implementation of S516, the UE context setting request message may not include the first indication information.

[0424] S517: The IAB node 2 generates configuration information of a second LCH corresponding to the first bearer.

[0425] Optionally, when the UE context setting request message includes the first indication information, the IAB node 2 may generate setting information of the second LCH based on the first indication information. Alternatively, when the UE context setting request message does not include the first indication information, after receiving the UE context setting request message, the IAB node 2 may: S518 Then, generate configuration information of a second LCH for each bearer of the terminal, and configure a UE context. Fixed response The IAB donor CU2 may then transmit configuration information of the second LCH to the IAB donor CU2 via an answer message.

[0426] S518: The IAB node 2 sends a UE context setup response message to the IAB donor CU2, where the UE context setup response message includes setup information of the second LCH corresponding to the first bearer.

[0427] Through S516 to S518, a GTP-U tunnel may be established between the IAB Node 2 and the IAB Donor CU2 for the first bearer, where the GTP-U tunnel corresponds to the second LCH.

[0428] Optionally, in S516 to S518, routing setup and bearer mapping setup may be completed on the path between IAB node 2 and IAB donor CU2.

[0429] S519: The IAB donor CU2 sends a handover request response message to the IAB donor CU1, where the handover request response message includes a second RRC reconfiguration message, 2 The RRC reconfiguration message includes configuration information of a second LCH corresponding to the first bearer and second indication information.

[0430] S520: IAB donor CU1 sends a UE context modification request message to IAB node 2, where the UE context modification request message includes a second RRC reconfiguration message.

[0431] S521: IAB node 2 sends a second RRC reconfiguration message to the terminal.

[0432] The second RRC reconfiguration message includes one or more of the following: air interface configuration information of the first bearer, PDCP configuration information corresponding to the source donor node, and PDCP configuration information corresponding to the target donor node. For details, please refer to the content of S102.

[0433] Optionally, the second RRC reconfiguration message further includes third indication information. The terminal 1 may process the uplink data using PDCP configuration information corresponding to the target donor node based on the third indication information, and map the processed uplink data to the second LCH. Alternatively, optionally, the second RRC reconfiguration message may not include the third indication information. After the terminal 1 receives the second RRC reconfiguration message, if the second RRC reconfiguration message carries configuration information of the second LCH, the terminal 1 processes the uplink data using PDCP configuration information corresponding to the target donor node by default, and maps the processed uplink data to the second LCH.

[0434] S522: The terminal configures a second LCH for the first bearer.

[0435] For details, please refer to the contents of S104 in FIG.

[0436] S523: The IAB donor CU2 sends a handover success message to the IAB donor CU1, indicating the IAB donor CU1 to stop sending source downlink data to the IAB node 3.

[0437] S524: IAB donor CU1 stops transmitting source downlink data to IAB node 3.

[0438] Optionally, the IAB donor CU1 stops transmitting source downlink data to the IAB node 3, but the IAB node 3 continues transmitting source downlink data buffered in the IAB node 3 to the terminal 1.

[0439] S525 to S531 describe a process of deleting the first LCH of the first bearer. The contents here and the contents of Figure 15 may be cross-referenced. For example, the UE context release message of S525 is the seventh message of Figure 15, and the UE context release message of S526 is the eighth message of Figure 15.

[0440] S525: IAB donor CU2 sends a UE context release message to IAB donor CU1.

[0441] S526: IAB donor CU1 sends a UE context release message to IAB node 2.

[0442] S527: IAB node 2 determines that the buffer of the first LCH is empty.

[0443] S528: IAB node 2 sends a UE context modification message to IAB donor CU2, where the message includes the fourth indication information.

[0444] For the fourth indication information, please refer to the contents of FIG.

[0445] S529: IAB donor CU2 sends a UE context modification request message to IAB node 2, where the message includes a third RRC reconfiguration message, and the third RRC reconfiguration message includes the fifth indication information.

[0446] S530: The IAB node 2 sends a third RRC reconfiguration message to the terminal 1, where the third RRC reconfiguration message includes the fifth indication information.

[0447] S531: The terminal deletes the first LCH of the first bearer based on the fifth indication information.

[0448] For the fifth indication information, please refer to the contents of S302 to S304.

[0449] S532: IAB donor CU2 sends an F1 AP message to IAB node 3 to indicate IAB node 3 to release protocol stack resources between IAB node 3 and IAB node 1.

[0450] S533: IAB node 3 switches from DAPS to a single-active protocol stack.

[0451] A single active protocol stack can be understood as IAB node 3 only having protocol stack resources corresponding to the target parent node, in other words, IAB node 3 releases protocol stack resources between IAB node 3 and IAB node 1.

[0452] S534: IAB donor CU2 sends a context release message to IAB donor CU1.

[0453] S535: IAB donor CU1 sends a context release message to IAB node 1.

[0454] S536: IAB node 1 releases the context of IAB node 3.

[0455] 17A to 17E, before the IAB donor CU1 performs a handover decision, a first LCH is configured for the first bearer of the terminal, and the terminal may transmit downlink PDCP data corresponding to the source donor node (hereinafter abbreviated as source downlink data) and uplink PDCP data corresponding to the source donor node (hereinafter abbreviated as source uplink data) through the first LCH. In the handover completion phase, after the IAB node 2 configures a second LCH for the first bearer of the terminal through the IAB donor CU2, the terminal may transmit downlink PDCP data corresponding to the target donor node (hereinafter abbreviated as target downlink data) and uplink PDCP data corresponding to the target donor node (hereinafter abbreviated as target uplink data) through the second LCH.

[0456] Optionally, in S501 to S511, the IAB donor CU1 may send source downlink data to the terminal, and the terminal may send source uplink data to the IAB donor CU1.

[0457] Optionally, in S511 to S522, the IAB donor CU1 may transmit source downlink data to the terminal.

[0458] Optionally, in S522 to S524, IAB donor CU1 may transmit source downlink data to the terminal, IAB donor CU2 may transmit target downlink data to the terminal, and the terminal may transmit target uplink data to IAB donor CU2.

[0459] Optionally, from S524 to S527, IAB node 3 and IAB node 2 may continue to transmit source downlink data packets buffered in IAB node 3 or IAB node 2 to terminal 1, IAB donor CU2 may transmit target downlink data to the terminal, and the terminal may transmit target uplink data to IAB donor CU2.

[0460] Optionally, in S527 to S536, the IAB donor CU2 may send target downlink data to the terminal, and the terminal may send target uplink data to the IAB donor CU2.

[0461] For the method of processing the source uplink data, the source downlink data, the target uplink data, and / or the target downlink data, please refer to the above content, and the details will not be described again in this specification.

[0462] In the method of Figures 17A to 17E, during handover of the IAB node 3, the data transmission of the terminal is never interrupted, ensuring the continuity of data transmission.

[0463] 18A to 18D are schematic diagrams of another inter-donor node handover method according to an embodiment of the present application. As shown in FIG. 18A to 18D, the method includes the following steps:

[0464] The processes of S601 to S616 describe a handover preparation process, and the contents of Figures 17A to 17E and the contents of Figures 18A to 18D may be cross-referenced.

[0465] S601: IAB node 3 sends a measurement report to IAB donor CU1.

[0466] S602: IAB donor CU1 performs handover decision.

[0467] S603: The IAB donor CU1 sends a handover request message to the IAB donor CU2, where the handover request message includes capability indication information.

[0468] S604 to S606 describe a process of configuring a second LCH of a first bearer, and the contents here and the contents of FIG. 13 may be mutually referenced. For example, S604 to S606 may correspond to a case where the first relay node receives a first indication information from a source donor node and transmits configuration information of a second LCH to the source donor node, and the source donor node transmits configuration information of the second LCH to the target donor node before the first relay node establishes a connection to the target donor node. It may be understood that the first message in FIG. 13 is a UE context modification request message of S604, the fifth message in FIG. 13 is a UE context modification response message of S606, the sixth message in FIG. 13 is a handover request message of S609, the second message in FIG. 13 is a handover request response message of S613, and the first message in FIG. 13 is a second RRC reconfiguration message of S613 to S615.

[0469] S604: The IAB donor CU1 sends a UE context modification request message to the IAB node 2, where the UE context modification request message includes first indication information.

[0470] S605: The IAB node 2 generates configuration information of a second LCH corresponding to the first bearer.

[0471] The IAB node 2 may generate configuration information for the second LCH based on the first indication information.

[0472] S606: IAB node 2 sends a UE context modification response message to the IAB donor CU. 1 , and the UE context modification response message includes configuration information of the second LCH.

[0473] S607: IAB donor CU2 sends a context setting request message to IAB node 4.

[0474] S608: IAB node 4 sends a context setting response message to IAB donor CU2.

[0475] S609: The IAB donor CU1 sends a handover request message to the IAB donor CU2, where the handover request message includes configuration information of the second LCH.

[0476] Optionally, the messages of S609 and S603 may be the same handover request message.

[0477] Optionally, S609 can be performed before S607, between S607 and S608, or after S608, which is not limited in this embodiment of the present application.

[0478] S610: The IAB donor CU2 sends a handover request response message to the IAB donor CU1, where the handover request response message includes a first RRC reconfiguration message, and the first RRC reconfiguration message includes the sixth indication information.

[0479] S611:IAB donor CU1 sends a first RRC reconfiguration message to IAB node 3, where the first RRC reconfiguration message includes the sixth indication information.

[0480] S612: IAB node 3 starts DAPS based on the sixth indication information.

[0481] S613: The IAB donor CU2 sends a handover request response message to the IAB donor CU1, where the handover request response message includes a second LCH reconfiguration message, and 2The RRC reconfiguration message includes configuration information of a second LCH corresponding to the first bearer and second indication information.

[0482] S614: The IAB donor CU1 sends a UE context modification request message to the IAB node 2, where the UE context modification request message includes a second RRC reconfiguration message.

[0483] S615: IAB node 2 sends a second RRC reconfiguration message to the terminal.

[0484] Optionally, the messages of S610 and S613 may be the same handover request response message, where the handover request response message includes the first RRC reconfiguration message and the second RRC reconfiguration message.

[0485] S616: The terminal configures a second LCH for the first bearer.

[0486] The process from S617 to S621 describes the handover execution process, ie, the random access process between the IAB node 3 and the IAB donor DU 2.

[0487] S617: IAB node 3 sends a preamble to IAB node 4.

[0488] S618: IAB node 4 sends the RAR to IAB node 3.

[0489] S619: IAB node 3 performs PUSCH switch.

[0490] S620: IAB node 3 sends an RRC reconfiguration complete message to IAB donor DU 2.

[0491] S621: The IAB donor DU2 sends an uplink RRC message transfer (UL RRC transfer) message to the IAB donor CU2, where the message includes an RRC reconfiguration complete message.

[0492] S622: IAB node 3 sends third indication information to the terminal.

[0493] Optionally, the IAB node 3 may send a third indication information to the terminal after performing a PUSCH switch or establishing a connection to the target donor node. For details, see the content of S200.

[0494] S623: An F1 interface is established between IAB node 3 and IAB donor CU2.

[0495] S624: An F1 interface is established between IAB node 2 and IAB donor CU2.

[0496] S625: IAB donor CU2 sends a UE context setting request message to IAB node 2.

[0497] S626: IAB node 2 sets UE context Fixed response The IAB donor CU2 then sends a response message to the IAB donor CU2.

[0498] S627: The IAB donor CU2 sends a handover success message to the IAB donor CU1, indicating the IAB donor CU1 to stop sending source downlink data to the IAB node 3.

[0499] S628: IAB donor CU1 stops transmitting source downlink data to IAB node 3.

[0500] S629: IAB donor CU2 sends a UE context release message to IAB donor CU1.

[0501] S630: IAB donor CU1 sends a UE context release message to IAB node 2.

[0502] S631: IAB node 2 determines that the buffer of the first LCH is empty.

[0503] S632: IAB node 2 sends a UE context modification message to IAB donor CU2, where the message includes the fourth indication information.

[0504] S633: IAB donor CU2 sends a UE context modification request message to IAB node 2, where the message includes a third RRC reconfiguration message, and the third RRC reconfiguration message includes the fifth indication information.

[0505] S634: The IAB node 2 sends a third RRC reconfiguration message to the terminal 1, where the third RRC reconfiguration message includes the fifth indication information.

[0506] S635: The terminal deletes the first LCH of the first bearer based on the fifth indication information.

[0507] S636: IAB donor CU2 sends an F1 message to IAB node 3 to indicate IAB node 3 to release protocol stack resources between IAB node 3 and IAB node 1.

[0508] S637: IAB node 3 switches from DAPS to a single active protocol stack.

[0509] S638: IAB donor CU2 sends a context release message to IAB donor CU1.

[0510] S639: IAB donor CU1 sends a context release message to IAB node 1.

[0511] S640: IAB node 1 releases the context of IAB node 3.

[0512] For the contents of each step in Figures 18A to 18D, please refer to the contents of Figures 17A to 17E, and the details will not be described again in this specification.

[0513] Optionally, in S601 to S622, the IAB donor CU1 may send source downlink data to the terminal, and the terminal may send source uplink data to the IAB donor CU1.

[0514] Optionally, in S622 to S630, IAB donor CU1 may send source downlink data to the terminal, IAB donor CU2 may send target downlink data to the terminal, and the terminal may send source uplink data to IAB donor CU2.

[0515] Optionally, in S630 to S640, the IAB donor CU2 may send target downlink data to the terminal, and the terminal may send target uplink data to the IAB donor CU2.

[0516] For the method of processing the source uplink data, the source downlink data, the target uplink data, and / or the target downlink data, please refer to the above content, and the details will not be described again in this specification.

[0517] Hereinafter, the apparatus provided in the embodiment of the present application will be described with reference to Figures 19 to 22. The apparatus in Figures 19 to 22 may complete the method in Figures 13 to 18D. The contents of the apparatus and the contents of the method may be cross-referenced.

[0518] Figure 19 is a schematic diagram of the structure of a terminal according to an embodiment of the present application. The terminal may implement the functions of the terminal in the embodiment of the above method. For ease of explanation, Figure 19 shows the main components of the terminal. In Figure 19, the following are shown:

[0519] The terminal includes at least one processor 611, at least one transceiver 612, and at least one memory 613. The processor 611, the memory 613, and the transceiver 612 are connected to each other. Optionally, the terminal may further include an output device 614, an input device 615, and one or more antennas 616. The antenna 616 is connected to the transceiver 612, and the output device 614 and the input device 615 are connected to the processor 611.

[0520] The processor 611 is mainly configured to process communication protocols and communication data, control the entire terminal, execute software programs, and process data of the software programs.

[0521] In an optional implementation, In the end The terminal device may include a baseband processor, a baseband processor, and a central processing unit. The baseband processor is mainly configured to process communication protocols and communication data. The central processing unit is mainly configured to control the entire terminal device, execute software programs, and process data of the software programs.

[0522] The functions of the baseband processor and the central processing unit may be integrated into the processor of FIG. 19. Those skilled in the art may understand that the baseband processor and the central processing unit may alternatively be independent processors and may be interconnected using a technology such as a bus. Those skilled in the art may understand that the terminal device may include multiple baseband processors to accommodate different network standards, that the terminal device may include multiple central processing units to enhance the processing capabilities of the terminal device, and that the components of the terminal device may be connected using various buses. The baseband processor may alternatively be referred to as a baseband processing circuit or a baseband processing chip. The central processing unit may alternatively be referred to as a central processing circuit or a central processing chip. The function of processing the communication protocol and communication data may be incorporated into the processor or may be stored in the memory in the form of a software program. The processor executes the software program to implement the baseband processing function.

[0523] The memory 613 is mainly configured to store software programs and data. The memory 613 may exist independently and be connected to the processor 611. Optionally, the memory 613 and the processor 611 may be integrated with each other, for example integrated on a single chip, i.e., an on-chip memory, or the memory 613 is an independent storage element. This is not limited in this embodiment of the present application. The memory 613 may store a program code for implementing the technical solutions of the embodiments of the present application, and the processor 611 controls the execution of the program code. Various types of executed computer program codes may be regarded as drivers of the processor 611.

[0524] The transceiver 612 may be configured to perform conversion between baseband signals and radio frequency signals and process the radio frequency signals. The transceiver 612 may be connected to an antenna 616. The transceiver 612 includes a transmitter (Tx) and a receiver (Rx). Specifically, the one or more antennas 616 may receive the radio frequency signals. The receiver Rx of the transceiver 612 is configured to receive the radio frequency signals from the antenna, convert the radio frequency signals into digital baseband signals or digital intermediate frequency signals, and provide the digital baseband signals or digital intermediate frequency signals to the processor 611 so that the processor 611 further processes the digital baseband signals or digital intermediate frequency signals, e.g., performs demodulation and decoding processes. Furthermore, the transmitter Tx of the transceiver 612 is configured to receive modulated digital baseband signals or digital intermediate frequency signals from the processor 611, convert the modulated digital baseband signals or digital intermediate frequency signals into radio frequency signals, and transmit the radio frequency signals through the one or more antennas 616. Specifically, the receiver Rx may selectively perform one or more levels of frequency downmixing and analog-to-digital conversion on the radio frequency signal to obtain a digital baseband signal or a digital intermediate frequency signal. The order of the frequency downmixing and analog-to-digital conversion processes is adjustable. The transmitter Tx may selectively perform one or more levels of frequency upmixing and digital-to-analog conversion on the modulated digital baseband signal or the digital intermediate frequency signal to obtain a radio frequency signal. The order of the frequency upmixing and digital-to-analog conversion processes is adjustable. The digital baseband signal and the digital intermediate frequency signal may be collectively referred to as a digital signal. Optionally, the transmitter Tx and the receiver Rx may be implemented by different physical structures / circuits or may be implemented by the same physical structure / circuit, i.e., both the transmitter Tx and the receiver Rx may be implemented by the same physical structure / circuit. Integrated This may also occur.

[0525] The transceiver may also be referred to as a transceiver unit or a transceiver device. Optionally, a component in the transceiver configured to implement a receiving function may be considered as a receiving unit, and a component in the transceiver configured to implement a transmitting function may be considered as a transmitting unit. That is, the transceiver unit includes a receiving unit and a transmitting unit. The receiving unit may also be referred to as a receiver, an input port, a receiving circuit, or the like. The transmitting unit may also be referred to as a transmitter or a transmission circuit, or the like. Alternatively, the Tx, the Rx, and the antenna may be combined to form a transceiver.

[0526] The output device 614 displays information in a number of ways. For example, the output device 614 may be a Liquid Crystal Display (LCD), a Light Emitting Diode (LED) display device, a Cathode Ray Tube (CRT) display device, a projector, etc. The input device 615 may receive user input in a number of ways. For example, the input device 615 may be a mouse, a keyboard, a touch screen device, or a sensing device.

[0527] For example, the processor 611 may be configured to support the terminal to perform the actions described in the above-mentioned method embodiments. For example, the processor 611 (e.g., a baseband processor) may implement the functions of the dual configuration protocol stack of the terminal 1 in FIG. 12, obtain the first indication information, process the received downlink data or the transmitted uplink data using the configuration information corresponding to the source donor node or the configuration information corresponding to the target donor node, activate the configuration information corresponding to the source donor node and / or the configuration information corresponding to the target donor node, and delete the configuration information corresponding to the source donor node. For details, please refer to the contents of the above-mentioned method embodiments.

[0528] For example, the memory 613 may store program codes for executing operations performed by the terminal in the above-mentioned method embodiments, and the processor 611 controls the execution. For example, the memory 613 may store configuration information corresponding to a source donor node and / or a target donor node, the memory 613 may store indication information, etc., and the memory 613 may store downlink data received from a relay node or uplink data to be transmitted. For details, please refer to the contents of the above-mentioned method embodiments.

[0529] For example, the transceiver 612 and the antenna 616 may implement transmission with the parent node of the terminal, such as receiving downlink data, transmitting uplink data, or receiving indication information. For details, please refer to the contents of the above-mentioned method embodiments.

[0530] Figure 20 is a schematic diagram of the structure of a communication device according to an embodiment of the present application. The communication device may be a relay node and may implement the functions of the relay node in the above-mentioned method embodiment. Alternatively, the communication device may be a donor node and may implement the functions of the source donor node or the target donor node in the above-mentioned method embodiment. For ease of explanation, Figure 20 illustrates the main components of the communication device. The following are shown in Figure 20:

[0531] The communication device includes at least one processor 711, at least one memory 712, at least one transceiver 713, at least one network interface 714, and one or more antennas 715. The processor 711, the memory 712, the transceiver 713, and the network interface 714 are connected to each other, for example, using a bus. In this embodiment of the present application, this connection may include various types of interfaces, transmission lines, or buses, etc. This is not limited in this embodiment. The antenna 715 is connected to the transceiver 713. The network interface 714 is configured to allow the communication device to be connected to another network device through a communication link.

[0532] Transceiver 713, memory 712, and antenna 715 For implementing similar functionality, please refer to the related description in FIG.

[0533] When the communication device is a first relay node, the processor 711 may be configured to support the first relay node to perform the actions described in the above method embodiment. For example, the processor 711 may generate configuration information of a second LCH generated by the first relay node in the above method embodiment, and send the configuration information of the second LCH to the terminal. Specifically, after receiving a GTP tunnel establishment request from the target donor node, the first relay node may generate configuration information of the second LCH. In another example, the processor 711 may generate configuration information of the second LCH based on the received first indication information. For details, please refer to the contents of the above method embodiment.

[0534] The transceiver 713 and the antenna 715 may implement a connection between the first relay node and a source donor node, or a connection between the first relay node and a target donor node.

[0535] The transceiver 713 and the antenna 715 may implement transmission with the parent node of the first relay node and / or the child node of the first relay node, for example, receive data of the source donor node and / or the target donor node from the parent node of the first relay node, transmit data of the source donor node and / or the target donor node to the terminal, receive data of the terminal, transmit data of the terminal to the parent node of the first relay node, receive indication information generated by another node (e.g., the source donor node and / or the target donor node) from the parent node of the first relay node, and transmit the received indication information or the indication information generated by the first relay node to the terminal. For details, please refer to the contents of the above-mentioned method embodiments.

[0536] The memory 712 may store program codes and / or data for executing operations performed by the first relay node in the above-mentioned method embodiments, and the processor 711 controls the execution. For example, the memory 712 may store data or indication information received from a parent node and / or a child node of the first relay node, or may store indication information generated by the first relay node. For details, please refer to the contents of the above-mentioned method embodiments.

[0537] When the communication device is a target donor node, the processor 711 may be configured to support the target donor node to perform the actions described in the above method embodiments. For example, the processor 711 may generate indication information or data generated by the target donor node in the above method embodiments, etc. For details, please refer to the contents of the above method embodiments.

[0538] The transceiver 713 and the antenna 715 may implement a connection between the target donor node and the relay node. The transceiver 713 and the antenna 715 may implement transmission with a child node of the target donor node, for example, to transmit data and / or indication information to the child node and to receive data and / or indication information from the child node. For details, please refer to the contents of the above-mentioned method embodiment.

[0539] The memory 712 may store program codes and / or data for executing operations performed by the target donor node in the above-mentioned method embodiments, and the processor 711 controls the execution. For example, the memory 712 may store data or indication information received from another node, or may store data or indication information generated by the target donor node. For details, please refer to the contents of the above-mentioned method embodiments.

[0540] The network interface 714 may include a network interface between a target donor node and a core network element, such as an S1 interface. The network interface may include a network interface between an access network device and another network device, such as a network interface between a source donor node and a target donor node, such as an X2 or Xn interface.

[0541] When the communication device is a source donor node, the processor 711 may be configured to support the source donor node to perform the actions described in the above method embodiments. For example, the processor 711 may generate indication information or data generated by the source donor node in the above method embodiments, etc. For details, please refer to the contents of the above method embodiments.

[0542] The transceiver 713 and the antenna 715 may implement a connection between the source donor node and the relay node. The transceiver 713 and the antenna 715 may implement transmission with a child node of the source donor node, for example, to send data and / or indication information to the child node and to receive data and / or indication information from the child node. For details, please refer to the contents of the above-mentioned method embodiment.

[0543] The memory 712 may store program codes and / or data for executing the operations performed by the source donor node in the embodiments of the method described above, and the processor 711 controls the execution. For example, the memory 712 may store data or indication information received from another node, or sauce It may store data or indication information generated by the donor node, for details, please refer to the contents of the above method embodiment.

[0544] The network interface 714 is sauce The network interface may include a network interface between a donor node and a core network element, such as an S1 interface. The network interface may include a network interface between an access network device and another network device, such as a network interface between a target donor node and a source donor node, such as an X2 or Xn interface.

[0545] FIG. 21 is a schematic diagram of the structure of an access network device according to an embodiment of the present application. For example, FIG. 21 shows the structure of a donor node. of21 may be a schematic diagram. The DU included in the donor node may be a donor DU, and the CU included in the donor node may be a donor CU. As shown in Fig. 21, a base station may be used in the systems shown in Fig. 1, Fig. 2, Fig. 3, and Fig. 11 to implement the functions of the donor node (including the source donor node and / or the target donor node) in the embodiments of the above-mentioned method.

[0546] The access network device may include one or more DUs 1101 and one or more CUs 1102. The DU 1101 may include at least one antenna 11011, at least one radio frequency unit 11012, at least one processor 11013, and at least one memory 11014. The DU 1101 is mainly configured to transmit and receive radio frequency signals, perform conversion between radio frequency signals and baseband signals, and perform partial baseband processing. The CU 1102 may include at least one processor 11022 and at least one memory 11021. The CU 1102 and the DU 1101 may communicate with each other through an interface. The control plane interface may be F1-C, and the user plane interface may be F1-U.

[0547] The CU 1102 is mainly configured to perform baseband processing, control the base station, etc. The DU 1101 and the CU 1102 may be physically co-located, or may be physically separated, i.e., a distributed base station. The CU 1102 is the control center of the base station, may be called a processing unit, and is mainly configured to complete baseband processing functions. For example, the CU 1102 may be configured to control the base station to perform operation procedures related to the network device in the above-mentioned method embodiment.

[0548] Specifically, the baseband processing of the CU and DU may be classified based on the protocol layer of the wireless network. For details, see Figure 3.

[0549] Additionally, optionally, a donor base station 1100 may include one or more radio frequency units (RUs), one or more DUs, and one or more CUs. The DU may include the at least one processor 11013 and the at least one memory 11014 described above, the RU may include the at least one antenna 11011 and the at least one radio frequency unit 11012 described above, and the CU may include the at least one processor 11022 and the at least one memory 11021 described above.

[0550] In an example, the CU 1102 may include one or more boards, and the multiple boards may cooperate to support a radio access network of one access standard (e.g., a 5G network), or may separately support a radio access network of a different access standard (e.g., an LTE network, a 5G network, or another network). The memory 11021 and the processor 11022 may serve one or more boards. In other words, the memory and the processor may be disposed independently on each board, or the multiple boards may share the same memory and the same processor. Furthermore, the necessary circuits may be further disposed on each board. The DU 1101 may include one or more boards, and the multiple boards may cooperate to support a radio access network of one access standard (e.g., a 5G network), or may separately support a radio access network of a different access standard (e.g., an LTE network, a 5G network, or another network). The memory 11014 and the processor 11013 may serve one or more boards. In other words, the memory and processor may be located independently on each board, or multiple boards may share the same memory and the same processor, and further required circuitry may be located on each board.

[0551] For example, when the access network device is a target donor node, the CU of the target donor node may perform transmission with a child node through the DU. For example, in the downlink direction, the CU of the target donor node may generate data (e.g., PDCP data) and / or indication information and then transmit the data to the DU of the target donor node through the interface between the CU and the DU, and the DU of the target donor node transmits the data to the child node of the DU through the antenna. In the uplink direction, the DU of the target donor node may receive data from the child node through the antenna and then transmit the data to the CU of the target donor node through the interface between the CU and the DU.

[0552] For example, when the access network device is a source donor node, the CU of the source donor node may perform transmission with a child node through a DU. For example, in the downlink direction, the CU of the source donor node may generate data (e.g., PDCP data) and / or indication information and then transmit the data to the DU of the source donor node through an interface between the CU and the DU, and the DU of the source donor node transmits the data to the child node of the DU through an antenna. In the uplink direction, the DU of the source donor node may receive data from the child node through an antenna and then transmit the data to the CU of the source donor node through an interface between the CU and the DU.

[0553] FIG. 22 is a schematic diagram of a structure of a communication apparatus according to an embodiment of the present application. The communication apparatus may implement the method described in the above method embodiment. For details, please refer to the description of the above method embodiment. The communication apparatus may be used in a communication device, a circuit, a hardware component, or a chip. For example, the communication apparatus may be a terminal, a chip in a terminal, a donor node (including a source donor node or a target donor node), a chip in a donor node (including a source donor node or a target donor node), a relay node (including a first relay node and a second relay node), or a chip in a relay node.

[0554] The apparatus 1900 includes a processing unit 1901 and a communication unit 1902. Optionally, the communication apparatus 1900 further includes a storage unit 1903.

[0555] The processing unit 1901 may be a device having processing capabilities and may include one or more processors. The processor may be a general-purpose processor or a special-purpose processor, etc. The processor may be a baseband processor or a central processing unit. The baseband processor may be configured to process communication protocols and communication data. The central processing unit may be configured to control a device (e.g., a donor node, a terminal, or a chip), execute software programs, and process data of the software programs.

[0556] The communication unit 1902 may be a device for inputting (receiving) or outputting (transmitting) signals and is configured to effect signal transmission with another network device or another component within the device.

[0557] The storage unit 1903 may be a device having storage capabilities and may include one or more memories.

[0558] Optionally, the processing unit 1901, the communication unit 1902 and the storage unit 1903 are connected by means of a communication bus.

[0559] Optionally, the storage unit 1903 may exist independently and be connected to the processing unit 1901 by means of a communication bus. The storage unit 1903 may alternatively be integrated in the processing unit 1901.

[0560] Optionally, in this embodiment of the present application, the communication device 1900 may be a chip in a terminal or a donor node. The communication unit 1902 may be an input / output interface, a pin, or a circuit, etc. The memory unit 1903 may be a register, a cache, or a RAM, etc., and the memory unit 1903 may be integrated into the processing unit 1901. The memory unit 1903 may be a ROM or another type of static storage device that can store static information and instructions, and the memory unit 1903 may be independent from the processing unit 1901. Optionally, with the development of wireless communication technology, a transceiver may be integrated into the communication device 1900. For example, the transceiver 612 shown in FIG. 19 is integrated into the communication unit 1902.

[0561] In a possible design, the processing unit 1901 may include instructions that, when executed on the processor, may enable the communications device 1900 to perform the terminal or donor node methods in the above-described embodiments.

[0562] In another possible design, the storage unit 1903 may store instructions that are executed on the processing unit 1901 to enable the communication device 1900 to perform the method of the terminal or donor node in the above embodiments. Optionally, the storage unit 1903 may further store data. Optionally, the processing unit 1901 may also store instructions and / or data.

[0563] The communication device 1900 may be a terminal in an embodiment of the present application. A schematic diagram of the terminal may be shown in Fig. 19. Optionally, the communication unit 1902 of the device 1900 may be connected to an antenna and a transceiver of the terminal, such as the antenna in Fig. 19. 616 and transceivers 612 Optionally, the communication unit 1902 may further include an output device and an input device, such as the output device 614 and the input device 615 in FIG.

[0564] When the communication device 1900 may be a terminal or a chip of a terminal in the embodiments of the present application, the communication device 1900 may implement the functions implemented by the terminal in the embodiments of the foregoing method.

[0565] For example, the processing unit 1901 may configure a first LCH and / or a second LCH for a first bearer, process the received downlink data or the transmitted uplink data using the configuration information corresponding to the source donor node or the configuration information corresponding to the target donor node, map the uplink data processed using the configuration information corresponding to the source donor node or the configuration information corresponding to the target donor node to the first LCH or the second LCH, process the uplink data using the PDCP configuration information corresponding to the target donor node based on the second indication information, and delete the first LCH based on the indication information. The communication unit 1902 may implement transmission with a parent node of the terminal, for example, may receive downlink data, transmit uplink data, or receive indication information.

[0566] When the communication device 1900 may be a source donor node or a chip of a source donor node in an embodiment of the present application, the communication device 1900 may implement the functions of the source donor node in the embodiment of the aforementioned method.

[0567] For example, the processing unit 1901 may generate indication information or data generated by the source donor node in the above-mentioned method embodiment. For example, the communication unit 1902 may , S. A source donor node may perform transmissions with its child nodes, for example, sending data and / or indication information to the child nodes or receiving data and / or indication information from the child nodes.

[0568] When the communication device 1900 may be a target donor node or a chip of a target donor node in the embodiments of the present application, the communication device 1900 may implement the functions of the target donor node in the embodiments of the aforementioned method.

[0569] For example, the processing unit 1901 may generate indication information or data generated by the target donor node in the embodiment of the above method. For example, the communication unit 1902 may perform transmission with a child node of the target donor node, such as sending data and / or indication information to the child node or receiving data and / or indication information from the child node.

[0570] Above, the flow chart of the method of the embodiment of the present application has been described. It should be understood that the terminal may have a functional unit (means) corresponding to a method or step of the terminal, the relay node may have a functional unit corresponding to a method or step of the relay node, the source donor node (e.g., CU and / or DU) may have a functional unit corresponding to a method or step of the source donor node (e.g., CU and / or DU), the target donor node (e.g., CU and / or DU) may have a functional unit corresponding to a method or step of the target donor node (e.g., CU and / or DU), the CU of the source donor node may have a functional unit corresponding to a method or step of the CU of the source donor node, and another node in the relay system may have a functional unit corresponding to the other node. One or more of the aforementioned modules or units may be implemented by software, hardware, or a combination thereof. When any one of the aforementioned modules or units is implemented by software, the software exists in the form of computer program instructions and is stored in a memory. The processor may be configured to execute the program instructions to implement the steps of the aforementioned method.

[0571] The processor of the present application may include, but is not limited to, at least one of the following various computing devices that execute software: a central processing unit (CPU), a microprocessor, a digital signal processor (DSP), a microcontroller unit (MCU), or an artificial intelligence processor. Each computing device may include one or more cores configured to execute software instructions to perform an operation or process. The processor may be a separate semiconductor chip, or may be integrated with other circuits into a semiconductor chip, such as forming a system on a chip (SoC) with other circuits (e.g., codec circuits, hardware acceleration circuits, or various bus and interface circuits), or may be integrated in an application-specific integrated circuit (ASIC) as an embedded processor of the ASIC. The ASIC integrated with the processor may be packaged separately or together with other circuits. A processor includes a core for executing software instructions to perform operations or processes, and may further include necessary hardware accelerators, such as a field programmable gate array (FPGA), programmable logic device (PLD), or logic circuitry to perform special purpose logic operations.

[0572] The memory in the embodiments of the present application may include at least one of the following types: read-only memory (ROM) or another type of static storage device capable of storing static information and instructions, or random access memory (RAM) or another type of dynamic storage device capable of storing information and instructions, or may be an electrically erasable programmable read-only memory (EEPROM). In some scenarios, the memory may be a compact disc read-only memory (CD-ROM) or another compact disc storage, an optical disc storage (including a compact optical disc, a laser disc, an optical disc, a digital versatile disc, or a Blu-ray disc, etc.), a magnetic disc storage medium or another magnetic storage device, or any other medium that can be used to carry or store the expected program code in the form of instructions or data structures and that can be accessed by a computer. However, the memory is not limited thereto.

[0573] In addition to the data bus, the bus may further include a power bus, a control bus, a status signal bus, etc. However, for ease of explanation, the various types of buses in the figures are labeled as buses.

[0574] In the implementation process, the steps of the aforementioned method can be implemented by an integrated logic circuit of hardware in a processor, or can be implemented using instructions in the form of software. The steps of the method disclosed with reference to the embodiments of the present application can be directly implemented by a hardware processor, or can be implemented by a combination of hardware and software modules in a processor. The software modules can be located in a mature storage medium in the art, such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory, an electrically erasable programmable memory, or a register. The storage medium is located in the memory, and the processor reads the information in the memory and completes the steps of the aforementioned method in combination with the hardware of the processor. To avoid repetition, the details are not described again in this specification.

[0575] According to the method provided in the embodiment of the present application, the embodiment of the present application further provides a system including the aforementioned apparatus and one or more network devices.

[0576] It should be further understood that the first, second, third, fourth, and various numerals herein are used merely for distinction purposes for ease of explanation, and are not intended to limit the scope of the embodiments of the present application. These numerals may be substituted with other numerals.

[0577] It should be understood that the term "and / or" in this specification only describes an association relationship between related objects and indicates that three relationships may exist. For example, A and / or B may indicate three cases: when only A is present, when both A and B are present, and when only B is present. Furthermore, the character " / " generally indicates an "or" relationship between related objects.

[0578] It should be understood that the sequence numbers of the above processes do not refer to the execution order in various embodiments of the present application. The execution order of the processes shall be determined based on the functions and internal logic of the processes, and shall not be construed as any limitation on the implementation process of the embodiments of the present application.

[0579] Those skilled in the art may realize that the present application can be implemented by electronic hardware or a combination of computer software and electronic hardware in combination with various illustrative logical blocks and steps described in the embodiments disclosed herein. Whether a function is implemented by hardware or software depends on the individual application field and design constraints of the technical solution. Those skilled in the art may use various methods to implement the described functions for each specific application field, but the implementation shall be considered as not departing from the scope of the present application.

[0580] In some embodiments provided in the present application, it should be understood that the disclosed system, device, and method may be implemented in other ways. For example, the above-mentioned device embodiment is merely an example. For example, the division of units is merely a division of logical functions, and may be divided in other ways in actual implementation. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not implemented. Furthermore, the shown or described mutual couplings or direct couplings or communication connections may be implemented using some interfaces. Indirect couplings or communication connections between devices or units may be implemented in electronic, mechanical, or other forms.

[0581] All or part of the above-mentioned embodiments may be implemented by software, hardware, firmware, or any combination thereof. When software is used to implement the embodiments, all or part of the embodiments may be implemented in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the procedures or functions according to the embodiments of the present application are generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or may be transmitted from a computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions may be transmitted from a website, computer, server, or data center to another website, computer, server, or data center in a wired manner (e.g., coaxial cable, optical fiber, or digital subscriber line (DSL)) or wireless manner (e.g., infrared, radio, or microwave). The computer-readable storage medium may be any available medium accessible by a computer, or a data storage device, such as a server or a data center, incorporating one or more available media. The available medium may be a magnetic medium (e.g., a floppy disk, a hard disk, or a magnetic tape), an optical medium (e.g., a digital versatile disc (DVD), or a semiconductor medium (e.g., a solid-state drive, etc.).

[0582] The above description is merely a specific implementation of the present application, and is not intended to limit the scope of protection of the present application. Any variation or replacement that is easily apparent to a person skilled in the art within the technical scope disclosed in the present application shall be included in the scope of protection of the present application. Therefore, the scope of protection of the present application shall be determined by the scope of protection of the claims.

Claims

1. A logical channel (LCH) setup method, wherein a first data radio bearer (DRB) of a terminal corresponds to a first LCH, and the first LCH is for transmitting Packet Data Convergence Protocol (PDCP) data corresponding to a source donor node, the logical channel (LCH) setup method comprising: generating, by a first relay node, configuration information of a second LCH corresponding to the first DRB, the second LCH for transmitting PDCP data corresponding to a target donor node; transmitting, by the first relay node, the configuration information of the second LCH to the terminal; Including, The first relay node is an access relay node of the terminal, the source donor node is a source donor node during a first relay node handover and the target donor node is a target donor node during the first relay node handover, or the source donor node is a source donor node during a second relay node handover and the target donor node is a target donor node during the second relay node handover, and the second relay node is a relay node on a link between the first relay node and the source donor node; The terminal receives second indication information to avoid a situation in which the terminal receives the configuration information of the second LCH and erroneously considers that the configuration information of the first LCH needs to be deleted. A method for setting a logical channel (LCH).

2. 2. The method of claim 1, wherein the PDCP data corresponding to the source donor node is processed using PDCP configuration information corresponding to the source donor node, and the PDCP data corresponding to the target donor node is processed using the PDCP configuration information corresponding to the target donor node.

3. The logical channel (LCH) setting method includes: receiving, by the first relay node, a first indication information from the source donor node or the target donor node; generating, by the first relay node, the configuration information of the second LCH based on the first indication information; 3. The method of claim 1 or 2, further comprising:

4. 3. The method of claim 2, wherein the first indication is carried in a user equipment (UE) context modification request message received by the first relay node from the source donor node, or in a UE context establishment request message received by the first relay node from the target donor node.

5. The logical channel (LCH) setting method includes:

3. The logical channel (LCH) configuration method of claim 1 or 2, further comprising the step of generating, by the first relay node, the configuration information of the second LCH after the first relay node receives a first message from the target donor node.

6. The method of claim 5, wherein the first message is a user equipment (UE) context setup request message.

7. The logical channel (LCH) setting method includes:

7. The method of claim 1, further comprising the step of: transmitting, by the first relay node, the second indication information to the terminal, the second indication information being for configuring the second LCH for the first DRB or for indicating to the terminal to associate the first DRB with two LCHs.

8. The logical channel (LCH) setting method includes:

8. The method of claim 1, further comprising the step of: transmitting third indication information to the terminal by the first relay node, the third indication information indicating to the terminal to process uplink data using PDCP configuration information corresponding to the target donor node.

9. The source donor node is the source donor node during the first relay node handover, and the target donor node is the target donor node during the first relay node handover, and the logical channel (LCH) setting method includes:

9. The logical channel (LCH) setting method of claim 8, further comprising the step of transmitting the third indication information to the terminal by the first relay node after the first relay node performs a physical uplink shared channel (PUSCH) switch or after a General Packet Radio Service Tunnel Protocol (GTP) tunnel is established between the first relay node and the target donor node.

10. The logical channel (LCH) setting method includes:

10. The method of claim 1, further comprising the step of transmitting, by the first relay node, fourth indication information to the target donor node, the fourth indication information being used by the target donor node to indicate to the terminal to delete the first LCH.

11. 11. The method of claim 10, further comprising: transmitting, by the first relay node, the fourth indication information to the target donor node after the first relay node completes transmitting the PDCP data corresponding to the source donor node and buffered by the first relay node to the terminal.

12. The source donor node is a source donor node during the first relay node handover, and the target donor node is a target donor node during the first relay node handover, and the logical channel (LCH) setting method includes: receiving, by the first relay node, a fifth indication information from the target donor node via the source donor node; maintaining, by the first relay node, a connection with the source donor node during the handover based on the fifth indication information; 12. The method of claim 1, further comprising:

13. The logical channel (LCH) setting method includes:

13. The method of claim 12, further comprising the step of transmitting capability indication information by the first relay node to the target donor node via the source donor node, the capability indication information indicating that the first relay node supports the capability of maintaining a connection with the source donor node during the handover.

14. The logical channel (LCH) setting method according to any one of claims 1 to 13, wherein the first LCH corresponds to a General Packet Radio Service Tunnel Protocol-User Plane (GTP-U) tunnel between the first relay node and the source donor node, and the second LCH corresponds to a GTP-U tunnel between the first relay node and the target donor node.

15. The logical channel (LCH) setting method includes:

15. The method of claim 1, further comprising receiving, by the first relay node, information about a Backhaul Adaptation Protocol (BAP) address assigned by the target donor node via the source donor node, wherein the BAP address assigned to the first relay node by the target donor node is different from the BAP address assigned to the first relay node by the source donor node.

16. 16. The logical channel (LCH) setting method according to claim 1, further comprising a step of receiving, by the first relay node, a sixth indication information from the target donor node, the sixth indication information indicating to the first relay node to initiate, activate or enable a dual configuration of a BAP layer, the dual configuration of the BAP layer comprising a BAP configuration corresponding to the source donor node and a BAP configuration corresponding to the target donor node.

17. A logical channel (LCH) setup method, wherein a first data radio bearer (DRB) of a terminal corresponds to a first LCH, and the first LCH is for transmitting Packet Data Convergence Protocol (PDCP) data corresponding to a source donor node, the logical channel (LCH) setup method comprising: receiving, by the terminal, configuration information of a second LCH from a first relay node, the second LCH being for transmitting PDCP data corresponding to a target donor node; configuring, by the terminal, the second LCH for the first DRB; Including, The first relay node is an access relay node of the terminal, the source donor node is a source donor node during a first relay node handover and the target donor node is a target donor node during the first relay node handover, or the source donor node is a source donor node during a second relay node handover and the target donor node is a target donor node during the second relay node handover, and the second relay node is a relay node on a link between the first relay node and the source donor node; The terminal receives second indication information to avoid a situation in which the terminal receives the configuration information of the second LCH and erroneously considers that the configuration information of the first LCH needs to be deleted. A method for setting a logical channel (LCH).

18. 18. The method of claim 17, wherein the PDCP data corresponding to the source donor node is processed using PDCP configuration information corresponding to the source donor node, and the PDCP data corresponding to the target donor node is processed using the PDCP configuration information corresponding to the target donor node.

19. The logical channel (LCH) setting method includes: receiving, by the terminal, first indication information from the first relay node; The step of configuring the second LCH for the first DRB by the terminal comprises:

19. The logical channel (LCH) setting method according to claim 17 or 18, comprising a step of configuring, by the terminal, the second LCH for the first DRB based on the first indication information, and associating the first DRB with two LCHs.

20. The PDCP data corresponding to the target donor node includes uplink PDCP data corresponding to the target donor node, and the logical channel (LCH) establishment method includes: receiving, by the terminal, the second indication information from the first relay node; processing, by the terminal, uplink data using PDCP configuration information corresponding to the target donor node according to the second indication information, to obtain the uplink PDCP data corresponding to the target donor node; 20. The method of claim 17, further comprising:

21. The PDCP data corresponding to the target donor node includes uplink PDCP data corresponding to the target donor node, and the logical channel (LCH) establishment method includes:

20. The method of claim 17, further comprising: after the terminal receives the configuration information of the second LCH from the target donor node via the first relay node, the terminal processes uplink data using PDCP configuration information corresponding to the target donor node to obtain the uplink PDCP data corresponding to the target donor node.

22. The logical channel (LCH) setting method includes: receiving, by the terminal, third indication information from the first relay node; deleting, by the terminal, the first LCH based on the third indication information; 22. The method of claim 17, further comprising:

23. 17. A communications device comprising at least one processor and a memory coupled to the at least one processor, the at least one processor configured to implement a method for establishing a logical channel (LCH) according to any one of claims 1 to 16.

24. 23. A communications device comprising at least one processor and a memory coupled to the at least one processor, the at least one processor configured to implement a method for establishing a logical channel (LCH) according to any one of claims 17 to 22.

25. 23. A computer readable storage medium, the computer readable storage medium storing a program or instructions for implementing a logical channel (LCH) setting method according to any one of claims 1 to 22.

26. 23. A computer program comprising instructions which, when executed, perform the method of claim 1 to 22.

27. A communication system, the communication system comprising the first relay node according to any one of claims 1 to 16 and the terminal according to any one of claims 17 to 22.

Images