Ensuring service continuity by facilitating handover

Abstract

Systems, methods, apparatuses, or computer-readable media for facilitating handover are presented. A first wireless communication node may send a handover request message to a second wireless communication node that identifies at least one of a user equipment (UE)-to-network relay configuration or an aggregation configuration. A first wireless communication node may receive handover request acknowledgement information from a second wireless communication node that identifies at least one wireless communication device with which handover is allowed.

Description

Technical Field

[0001] The present disclosure relates generally to wireless communications, including but not limited to systems and methods for performing handoffs. Background Art

[0002] The third generation partnership project (3GPP), a standardization organization, is currently specifying a new radio interface called 5G New Radio (5G NR) and the next generation packet core network (NG-CN or NGC). 5G NR will have three main components: 5G access network (5G-AN), 5G core network (5GC) and user equipment (UE). To facilitate the implementation of different data services and requirements, the elements of 5GC (also known as network functions) have been simplified, and some of them are software-based, so that these elements can be adjusted as needed. Summary of the invention

[0003] The exemplary embodiments disclosed herein are intended to solve problems related to one or more problems raised in the prior art, and when combined with the accompanying drawings, by reference to the following detailed description, additional features will be provided that are easily understood. According to various embodiments, exemplary systems, methods, devices, and computer program products are disclosed herein. However, it should be understood that these embodiments are given as examples and not limitations, and it is obvious to those of ordinary skill in the art who read this disclosure that various modifications can be made to the disclosed embodiments while still within the scope of this disclosure.

[0004] At least one aspect relates to a system, method, apparatus, or computer-readable medium for facilitating handover. A first wireless communication node may communicate tunnel configuration information of a forwarding tunnel of a data radio bearer (DRB) with a second wireless communication node. The second wireless communication node may be configured to communicate with the first wireless communication node using the tunnel configuration information.

[0005] In some embodiments, a first wireless communication node may send a sequence number (SN) transmission message to a second wireless communication node. In some embodiments, the SN transmission message may include sending the SN transmission message in response to receiving path switch information from the second wireless communication node. In some embodiments, the SN transmission message may include sending the SN transmission message in response to receiving an end marker from a user plane function (UPF). In some embodiments, the SN transmission message may include sending the SN transmission message in response to sending an RRCReconfiguration message containing information required to access the second wireless communication node to the wireless communication device. In some embodiments, the SN transmission message may include at least one of a DRB identifier or a downlink (DL) count.

[0006] In some embodiments, a first wireless communication node may send a packet data convergence protocol (PDCP) protocol data unit (PDU) packet from a second wireless communication node, the PDCP PDU packet having a PDCP encryption or PDCP compression algorithm configured at the second wireless communication node. In some embodiments, in response to receiving the PDCP PDU from the second wireless communication node, the first wireless communication node may send path switching information to the wireless communication device. In some embodiments, the path switching information may include a control PDU, the control PDU including at least one of the following: a DRB identifier, an indicator of an uplink (UL) or downlink (DL) direction, a path switching indication, or an indicator of a PDCP encryption or PDCP compression algorithm of the second wireless communication node. In some embodiments, in response to receiving a forwarding request from the second wireless communication node, the first wireless communication node may send tunnel configuration information and a corresponding DRB identifier to the second wireless communication node.

[0007] In some embodiments, the first wireless communication node may send a segmented or duplicated PDCP service data unit (SDU) of the DRB to the second wireless communication node. In some embodiments, in response to receiving a DL PDCP PDU at a lower layer, the first wireless communication node may send a DL count to the second wireless communication node. In some embodiments, before sending the SN transfer message, the first wireless communication node may perform at least one of the following: reordering, duplicate detection, discarding, or delivering the PDCP SDU to the UPF. In some embodiments, after receiving the SN transfer message, the second wireless communication node may perform at least one of the following: reordering, duplicate detection, discarding, or delivering the PDCP SDU to the UPF.

[0008] At least one aspect relates to a system, method, apparatus, or computer-readable medium for facilitating handover. A first wireless communication node may send a handover request message to a second wireless communication node, the handover request message identifying at least one wireless communication device in a user equipment (UE) to network relay configuration or aggregation configuration. The first wireless communication node may receive a handover request confirmation message from the second wireless communication node, the handover request confirmation message identifying at least one wireless communication device with which handover is allowed.

[0009] In some embodiments, the handover request message may include candidate UE information supporting aggregation, the candidate UE information supporting aggregation including at least one of the following: an identifier of at least one wireless communication device or a PDU session resource request. In some embodiments, the handover request message may include a mapping of a quality of service (QoS) flow to at least one of an identifier of at least one wireless communication device or a DRB.

[0010] In some embodiments, the handover request confirmation message may identify an RRCReconfiguration message that includes information required to access a second wireless communication node corresponding to at least one wireless communication device. In some embodiments, the handover request confirmation message may identify at least one second wireless communication device with which handover is not allowed, or include at least one cause value.

[0011] At least one aspect relates to a system, method, apparatus, or computer-readable medium for completing a handover. A first wireless communication device may transmit path switch information with a first wireless communication node. The path switch information may include a control protocol data unit (PDU), the control PDU including at least one of the following: a DRB identifier, an indicator of an uplink (UL) or downlink (DL) direction, a path switch indication, or an indicator of a PDCP encryption or compression algorithm configured by a second wireless communication node. In some embodiments, the path switch information may identify a PDCP PDU of the DRB to be switched to a PDCP encryption or compression algorithm configured by the second wireless communication node.

[0012] In some embodiments, the first wireless communication device may receive the path switching information from at least one of the second wireless communication nodes or via the second wireless communication device. In some embodiments, the first wireless communication device may send the path switching information to the first wireless communication node via the second wireless communication device.

[0013] In some embodiments, the first wireless communication device may send a PDCP PDU of a DRB to the first wireless communication node via the second wireless communication device. In some embodiments, in response to the first wireless communication node sending a sequence number (SN) transmission message of the DRB or the first wireless communication node receiving a user equipment (UE) context release from the second wireless communication node, the first wireless communication device may receive path switching information from the first wireless communication node.

[0014] In some embodiments, the first wireless communication device may send the path switching information of the DRB to the first wireless communication node via the second wireless communication device. In some embodiments, the first wireless communication device may receive the DL packet of the DRB from the first wireless communication node via the second wireless communication device.

[0015] In some embodiments, the first wireless communication device may use the PDCP entity to maintain a first function for DL ​​packets via a direct path and a second function for DL ​​packets via an indirect path. In some embodiments, the first wireless communication device may maintain a third function to perform at least one of the following: reordering, duplicate detection, discarding, or delivering a PDCP service data unit (SDU) to an upper layer.

[0016] In some embodiments, the first wireless communication device may maintain PDCP SN assignments for UL packets via a direct path and an indirect path. In some embodiments, the first wireless communication device may maintain a first configuration for processing split or duplicate UL packets via a direct path and a second configuration for processing split or duplicate UP packets via an indicated path. In some embodiments, the first configuration and the second configuration may be separate PDCP configurations to perform at least one of compression, ciphering, and adding a robust header compression (ROHC) header.

[0017] In some embodiments, the first wireless communication device may receive the first DL packet via the second wireless communication device via an indirect path, at least partially simultaneously with receiving the second DL packet from the second wireless communication node via a direct path. In some embodiments, the first wireless communication device may receive path switching information for the DRB from the second wireless communication node.

[0018] In some embodiments, the first wireless communication device may send the path switching information to the first wireless communication node via the second wireless communication device. In some embodiments, the first wireless communication device may receive at least one of a radio link channel (RLC) SDU or PDU from the second wireless communication device while or before the second wireless communication device reestablishes the RLC.

[0019] In some embodiments, the first wireless communication device may receive a status report of the DRB from the second wireless communication device. In some embodiments, the status report may include at least one of: an indicator identifying whether the PDCP PDU was successfully transmitted to the first wireless communication node; an identifier of the first wireless communication device; a DRB identifier; a UL count; or a receiver status of a UL PDCP SDU.

[0020] In some embodiments, the first wireless communication device may retransmit the PDCP PDU based on the PDCP status report. In some embodiments, retransmitting the PDCP PDU may include transmitting a PDCP PDU to the second wireless communication device for retransmitting the corresponding lost PDCP PDU. In some embodiments, in response to the corresponding UL PDCP PDU being successfully transmitted to the second wireless communication device, the first wireless communication device may avoid determining that the UL PDCP data PDU is successfully transmitted to the second wireless communication device.

[0021] In some embodiments, the first wireless communication device may receive an RRCReconfiguration message including information required to access the second wireless communication node from the first wireless communication node to the plurality of wireless communication devices in the aggregate configuration. In some embodiments, in response to the RRC reconfiguration of each of the plurality of wireless communication devices being completed, the first wireless communication device may perform aggregation-based communication with the plurality of wireless communication devices.

[0022] In some embodiments, the first wireless communication device may configure the path to at least one of: suspend transmission on the direct path, reroute packets to the indirect path, or set the indirect path as the primary path. In some embodiments, the first wireless communication device may receive the configuration from the first wireless communication node. In some embodiments, the configuration may include at least one of: adding or modifying or removing the direct path, adding or modifying or removing the indirect path, activating or deactivating the direct path, activating or deactivating the indirect path. In some embodiments, the first wireless communication device may receive a PDCP SDU or PDU in a user equipment (UE) to a network relay configuration or an aggregation configuration via a first path to the first wireless communication node, at least partially concurrently with the deactivation of the first path. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] Various exemplary embodiments of the present solution are described in detail below with reference to the following figures or drawings. The drawings are provided for illustrative purposes only and depict only exemplary embodiments of the present solution to facilitate the reader's understanding of the present solution. Therefore, the drawings should not be considered as limiting the breadth, scope or applicability of the present solution. It should be noted that for clarity and ease of illustration, these drawings are not necessarily drawn to scale.

[0024] Figure 1 An example cellular communication network according to an embodiment of the present disclosure is shown, in which the techniques disclosed herein may be implemented;

[0025] Figure 2A block diagram showing an example base station and user equipment device according to some embodiments of the present disclosure;

[0026] Figure 3 A block diagram of an example system for user equipment (UE) to network relay is shown in accordance with an illustrative embodiment;

[0027] Figure 4 A block diagram of an example system for user equipment (UE) aggregation is shown in accordance with an illustrative embodiment;

[0028] Figure 5 A block diagram showing an example system for handover (HO) of a user equipment (UE1) with multipath transmission and reception according to an illustrative embodiment;

[0029] Fig. 6A and Figure 6B A communication diagram showing a handover procedure with a data radio bearer (DRB1) via a direct path in accordance with an illustrative embodiment;

[0030] Fig. 7A and Figure 7B A communication diagram showing a handover procedure with a data radio bearer (DRB2) via an indirect path in accordance with an illustrative embodiment;

[0031] Fig. 8A A block diagram showing a data forwarding path of a multipath user equipment (UE1) prior to sequence number (SN) status transmission according to an illustrative embodiment;

[0032] Figure 8B A block diagram showing a data forwarding path of a multipath user equipment (UE1) after a sequence number (SN) status transmission according to an illustrative embodiment;

[0033] Fig. 9 A block diagram showing an example system for handover (HO) of multiple user equipments (UE1 and UE2) with multipath transmission and reception according to an illustrative embodiment is shown;

[0034] Fig.10 A flowchart showing a method of facilitating handover according to an illustrative embodiment; and

[0035] Fig.11 A flow chart of a method of completing a handover is shown in accordance with an illustrative embodiment. DETAILED DESCRIPTION

[0036] Various exemplary embodiments of the present solution are described below with reference to the accompanying drawings to enable those of ordinary skill in the art to make and use the present solution. It is apparent to those of ordinary skill in the art that, after reading this disclosure, various changes or modifications may be made to the examples described herein without departing from the scope of the present solution. Therefore, the present solution is not limited to the exemplary embodiments and applications described and illustrated herein. In addition, the specific order or hierarchy of steps in the methods disclosed herein are merely exemplary methods. Based on design preferences, the specific order or hierarchy of steps of the disclosed methods or processes may be rearranged while remaining within the scope of the present solution. Therefore, those of ordinary skill in the art will understand that the methods and techniques disclosed herein present various steps or actions in a sample order, and unless otherwise expressly stated, the present solution is not limited to the specific order or hierarchy presented.

[0037] 1. Mobile communication technology and environment

[0038] Figure 1 An example wireless communication network and / or system 100 is shown in accordance with an embodiment of the present disclosure, in which the techniques disclosed herein may be implemented. In the discussion that follows, the wireless communication network 100 may be any wireless network, such as a cellular network or a narrowband Internet of Things (NB-IoT) network, and is referred to herein as "network 100." Such an example network 100 includes a base station 102 (hereinafter referred to as "BS 102"; also referred to as a wireless communication node) and a user equipment device 104 (hereinafter referred to as "UE 104"; also referred to as a wireless communication device) that may communicate with each other via a communication link 110 (e.g., a wireless communication channel), and a cluster of cells 126, 130, 132, 134, 136, 138, and 140 covering a geographic area 101. In Figure 1 1, BS 102 and UE 104 are contained within the respective geographic boundaries of cell 126. Each of the other cells 130, 132, 134, 136, 138, and 140 may include at least one base station operating with its allocated bandwidth to provide adequate radio coverage to its intended users.

[0039] For example, BS 102 may operate on an allocated channel transmission bandwidth to provide adequate coverage to UE 104. BS 102 and UE 104 may communicate via downlink radio frames 118 and uplink radio frames 124, respectively. Each radio frame 118 / 124 may be further divided into subframes 120 / 127, which may include data symbols 122 / 128. In the present disclosure, BS 102 and UE 104 are described herein as non-limiting examples of "communication nodes," which may generally practice the methods disclosed herein. According to various embodiments of the present solution, such communication nodes may be capable of wireless and / or wired communication.

[0040] Figure 2 A block diagram of an example wireless communication system 200 for sending and receiving wireless communication signals (e.g., OFDM / OFDMA signals) according to some embodiments of the present solution is shown. The system 200 may include components and elements configured to support known or conventional operating features that need not be described in detail herein. In one illustrative embodiment, as described above, the system 200 may be used in applications such as Figure 1 The wireless communication environment 100 may be used to communicate (eg, send and receive) data symbols.

[0041] The system 200 generally includes a base station 202 (hereinafter referred to as "BS 202") and a user equipment device 204 (hereinafter referred to as "UE 204"). The BS 202 includes a BS (base station) transceiver module 210, a BS antenna 212, a BS processor module 214, a BS memory module 216, and a network communication module 218, each of which is coupled to and interconnected with each other via a data communication bus 220 as needed. The UE 204 includes a UE (user equipment) transceiver module 230, a UE antenna 232, a UE memory module 234, and a UE processor module 236, each of which is coupled to and interconnected with each other via a data communication bus 240 as needed. The BS 202 communicates with the UE 204 via a communication channel 250, which may be any wireless channel or other medium suitable for data transmission as described herein.

[0042] As will be appreciated by those skilled in the art, the system 200 may also include Figure 2Any number of modules outside the modules shown. It will be appreciated by those skilled in the art that the various illustrative blocks, modules, circuits, and processing logic described in conjunction with the embodiments disclosed herein can be implemented in hardware, computer-readable software, firmware, or any actual combination thereof. In order to clearly illustrate this interchangeability and compatibility of hardware, firmware, and software, various illustrative components, blocks, modules, circuits, and steps are generally described according to their functions. Such functions are implemented as hardware, firmware, or software, depending on the specific application and design constraints imposed on the entire system. People familiar with the concepts described herein can implement such functions in a manner suitable for each specific application, but such implementation decisions should not be interpreted as limiting the scope of the present disclosure.

[0043] According to some embodiments, the UE transceiver 230 may be referred to herein as an "uplink" transceiver 230, which includes a radio frequency (RF) transmitter and an RF receiver, each including circuitry coupled to an antenna 232. A duplex switch (not shown) may alternatively couple the uplink transmitter or receiver to the uplink antenna in a time duplex manner. Similarly, according to some embodiments, the BS transceiver 210 may be referred to herein as a "downlink" transceiver 210, which includes an RF transmitter and an RF receiver, each including circuitry coupled to an antenna 212. The downlink duplex switch may alternatively couple the downlink transmitter or receiver to the downlink antenna 212 in a time duplex manner. The operation of the two transceiver modules 210 and 230 may be coordinated in time such that the uplink receiver circuit is coupled to the uplink antenna 232 so as to receive transmissions over the wireless transmission link 250 while the downlink transmitter is coupled to the downlink antenna 212. Instead, the operation of the two transceivers 210 and 230 may be coordinated in time such that a downlink receiver coupled to downlink antenna 212 receives transmissions over wireless transmission link 250 at the same time as an uplink transmitter coupled to uplink antenna 232. In some embodiments, tight time synchronization with minimal guard times between changes in duplex direction is provided.

[0044] The UE transceiver 230 and the base station transceiver 210 are configured to communicate via a wireless data communication link 250 and cooperate with an appropriately configured RF antenna arrangement 212 / 232 that can support a specific wireless communication protocol and modulation scheme. In some illustrative embodiments, the UE transceiver 210 and the base station transceiver 210 are configured to support industry standards such as long-term evolution (LTE) and emerging 5G standards. However, it should be understood that the present disclosure is not necessarily limited to application to specific standards and related protocols. Instead, the UE transceiver 230 and the base station transceiver 210 can be configured to support alternative or additional wireless data communication protocols, including future standards or variations thereof.

[0045] According to various embodiments, for example, BS202 can be an evolved node B (eNB), a serving eNB, a target eNB, a femtocell or a microcell. In some embodiments, UE 204 can be embodied in various types of user equipment, such as mobile phones, smart phones, personal digital assistants (PDAs), tablet computers, laptop computers, wearable computing devices, etc. Processor modules 214 and 236 can be implemented or completed with a general-purpose processor, a content addressable memory, a digital signal processor, an application-specific integrated circuit, a field programmable gate array, any suitable programmable logic device, a discrete gate or transistor logic, a discrete hardware component, or any combination thereof for performing the functions described herein. In this way, the processor can be implemented as a microprocessor, a controller, a microcontroller, a state machine, etc. The processor can also be implemented as a combination of computing devices, for example, a combination of a digital signal processor and a microprocessor, a plurality of microprocessors, one or more microprocessors combined with a digital signal processor core, or any other such configuration.

[0046] In addition, the steps of the methods or algorithms described in conjunction with the embodiments disclosed herein may be directly embodied in hardware, in firmware, in software modules executed by the processor modules 214 and 236, respectively, or in any practical combination thereof. The memory modules 216 and 234 may be implemented as RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art. In this regard, the memory modules 216 and 234 may be coupled to the processor modules 210 and 230, respectively, so that the processor modules 210 and 230 can read information from the memory modules 216 and 234 and write information to the memory modules 216 and 234, respectively. The memory modules 216 and 234 may also be integrated into their respective processor modules 210 and 230. In some embodiments, the memory modules 216 and 234 may each include a cache memory for storing temporary variables or other intermediate information during the execution of instructions executed by the processor modules 210 and 230, respectively. Memory modules 216 and 234 may also each include non-volatile memory for storing instructions to be executed by processor modules 210 and 230, respectively.

[0047] The network communication module 218 generally represents the hardware, software, firmware, processing logic and / or other components of the base station 202 that enable bidirectional communication between the base station transceiver 210 and other network components and communication nodes configured to communicate with the base station 202. For example, the network communication module 218 can be configured to support Internet or WiMAX services. In a typical deployment, but not limited to, the network communication module 218 provides an 802.3 Ethernet interface so that the base station transceiver 210 can communicate with a traditional Ethernet-based computer network. In this way, the network communication module 218 can include a physical interface for connecting to a computer network (e.g., a mobile switching center (MSC)). The terms "configured for", "configured to" and their conjugates used herein for a specific operation or function refer to a device, component, circuit, structure, machine, signal, etc. that is physically constructed, programmed, formatted and / or arranged to perform a specific operation or function.

[0048] The Open Systems Interconnection (OSI) model (referred to herein as the "Open Systems Interconnection Model") is a conceptual and logical layout that defines network communications used by systems (e.g., wireless communication devices, wireless communication nodes) that are open to interconnection and communication with other systems. The model is divided into seven subcomponents or layers, each of which represents a conceptual set of services provided to the layers above and below it. The OSI model also defines a logical network and effectively describes computer packet transmission by using different layer protocols. The OSI model may also be referred to as a seven-layer OSI model or a seven-layer model. In some embodiments, the first layer may be a physical layer. In some embodiments, the second layer may be a medium access control (MAC) layer. In some embodiments, the third layer may be a radio link control (RLC) layer. In some embodiments, the fourth layer may be a packet data convergence protocol (PDCP) layer. In some embodiments, the fifth layer may be a radio resource control (RRC) layer. In some embodiments, the sixth layer may be a non-access (NAS) layer or an Internet Protocol (IP) layer, and the seventh layer is other layers.

[0049] 2. Systems and methods for performing handovers

[0050] This paper proposes a system and method for ensuring service continuity for a User Equipment (UE) with multipath transmission / reception in a network, focusing on UE handover (HO), reestablishment, and path switching.

[0051] With the development of wireless multimedia services, the demand for high data rate services will increase significantly. In this case, the requirements for system capacity and coverage of traditional cellular networks will become higher. On the other hand, due to various application scenarios (e.g., public safety, social networks, short-range data sharing, and content services), the demand for proximity services that allow users to confirm or communicate with neighboring users has also increased.

[0052] However, cellular networks may have difficulty supporting high data rate services and proximity services. Therefore, device-to-device (D2D) communication technology can be used to meet such needs. By adopting D2D technology, the burden on cellular networks can be reduced, the power consumption of user devices can be reduced, the data rate can be increased, and the robustness of the network infrastructure can be improved, thereby meeting the needs of high data rate services and proximity services. D2D technology can also be called proximity services (ProSe) or sidelink communication, and the interface between devices can be called PC5 interface.

[0053] In order to support applications and services with a wider range, sidelink-based relay communication can be used to extend the coverage and improve the power consumption of the network. For example, sidelink-based relay communication can be applied to indoor relay communication, smart agriculture, smart factories, and public safety services. Figure 3 , depicts a block diagram of an example system for user equipment (UE) to network relay. As shown, a system applying sidelink-based relay communication may include a user equipment (UE) (e.g., UE1 as shown) in a weak coverage area or a coverage-free area. In this case, UE1 may be allowed to communicate with the network (e.g., a base station (BS) as shown) via a nearby UE2 covered by the network. As a result, the coverage of the network can be extended and the capacity of the network is expanded. In this case, UE2 may be referred to as a UE to network relay, and UE1 may be referred to as a remote UE. On the other hand, if the remote UE is within coverage, multipath relaying may be supported. Within coverage, the remote UE may be connected to the network via both direct (e.g., data transmitted directly between the remote UE and the network) and indirect (e.g., data forwarded via a relay UE) paths, and may have the potential to improve reliability and robustness as well as throughput.

[0054] Such multipath relaying can also be used for UE aggregation, where a UE is connected to the network via a direct path and via another UE using non-standardized UE-UE interconnection. Figure 4, depicts a block diagram of an example system for user equipment (UE) aggregation. As shown, a system for applying UE aggregation may include a user equipment (UE) (e.g., UE1 as shown in the figure) that aggregates other UEs (e.g., UE2 and UE3 as shown in the figure) for their uplink transmission or downlink reception from the network. Here, the interconnection between UE1 and UE2 or between UE1 and UE3 can be based on a side link, Wifi, Bluetooth, or wired connection, etc. However, the interconnection between UEs can be an ideal connection. In the case where ordinary UEs are limited by UL UE transmission power and cannot achieve the required bit rate (especially at the edge of the cell), UE aggregation can provide applications requiring high UL bit rates on 5G terminals. In addition, UE aggregation can also improve the reliability, stability and reduce latency of services.

[0055] Methods, systems and devices are proposed herein for ensuring service continuity for UEs in a network with multi-path transmission and reception (e.g., indirect paths via UE to network relay or UE aggregation), focusing on UE path switching, HO and re-establishment.

[0056] The motivation for UE multipath transmission may be that the UE may be limited by the uplink (UL) transmission (Tx) capability, and one UE may be associated with many UEs for UE aggregation, or connected to many relay UEs for UE to network relay. In order to support higher requirements for UL services, including data rate, latency and reliability, multipath transmission can be used. Specifically, the UE can be connected to the network and can perform data service transmission or reception with the network via a direct path and via one or more indirect paths (e.g., data services forwarded by another UE). UE-UE interconnection can be based on a side link connection or use a non-standardized connection. In order to support this multipath situation, service continuity issues such as HO, reconstruction and path switching can be used.

[0057] A. Switching process of multipath UE1

[0058] Reference now Figure 5 , depicts a block diagram of an example system for handover (HO) of user equipment (UE) with multipath transmission and reception. In general, UE1 involved in aggregation may have a wired connection or may be co-located with other aggregation-supporting UEs (such as UE2). In some embodiments, UE1 may be connected to UE2 via a PC5 connection. It may be assumed that UE1 is a service originating or terminating UE, and UE2 is an aggregation UE or relay UE. When UE1 moves, UE1 may perform a HO from gNB1 to gNB2, as shown. However, the aggregation UE2 or relay UE2 may still be served by gNB1. In this case, inter-gNB interactions may be considered to ensure service continuity.

[0059] I. Handover Procedure for Multipath UE1 with Data Radio Bearer (DRB1) via Direct Path

[0060] Referring now to FIG. 6 , a communication diagram of a handover procedure for a multipath UE1 with a data radio bearer (DRB1) via a direct path is depicted. As shown, UE1 may perform a HO from gNB1 to gNB2. In this example, UE1 and UE2 may be aggregated to transmit traffic for UE1. The data radio bearer (DRB1) for UE1 may be in a radio link control (RLC) acknowledged mode (AM) mode and may be transmitted via a direct path. UE1 may perform a HO from gNB1 to gNB2 while UE2 remains served by gNB1. After UE1 receives the HO command from gNB1, UE1 may begin accessing gNB2 and no longer receive packets from or transmit packets to gNB1. Service continuity for DRB1 transmitted via a direct path may be ensured as described below.

[0061] As shown in the figure, after gNB1 sends a HO command to UE1 (e.g., with synchronized radio resource control reconfiguration (RRCReconfiguration)), the source gNB1 may continue to receive downlink (DL) packets of DRB1 from the core network 5GC. The source gNB1 may send a sequence number (SN) status transfer message to the target gNB2. The SN status transfer message contains the following fields: ID of DRB, downlink (DL) count of DRB, uplink (UL) count, and receiver status of UL packet data convergence protocol (PDCP) service data unit (SDU). Among them, the DL count of DRB may indicate the next PDCP SN to be assigned by the target gNB2 to the new PDCP SDU that does not yet have a PDCP SN. The UL count may indicate the PDCP-SN and superframe number of the first lost UL SDU. The target next generation radio access network (NG-RAN) node may not deliver any uplink packets with a PDCP-SN lower than the value contained in the UL count value to the 5GC. The receiver status of the UL PDCP SDU may include a first bit indicating the SDU status after the first lost UL PDCP SDU as indicated by the UL count.

[0062] The source gNB1 may forward the DL and UL packets of DRB1 to the target gNB2. For DL ​​packets to which a PDCP SN has been assigned but for which the source gNB1 has not yet received confirmation of successful reception, the source gNB1 may forward the corresponding PDCP SDU and the corresponding PDCP SN in a General Packet Radio Service Tunneling Protocol User Plane (GTP-U) extension header. For DL ​​packets received later from the UPF, the source gNB1 may forward the corresponding PDCP SDU without the PDCP SN, and the target gNB2 may assign the PDCP SN to the PDCP SDU. Similarly, the source gNB1 may forward out-of-sequence UL PDCP SDU to the target gNB2. The corresponding PDCP SN of the UL PDCP SDU may be included in the GTP-U extension header.

[0063] UE1 can perform reconfiguration with synchronization and security key refresh, including random access (RA) to the target gNB2, medium access control (MAC) reset, security refresh, and re-establishment of RLC and PDCP triggered by explicit L2 indicators. Specifically, when receiving an indication from the lower layer that random access to the target cell is successfully completed, UE1 can perform PDCP entity re-establishment on DRB1 (if reestablishPDCP is set). For DRB1, the PDCP re-establishment of the UL PDCP Tx entity can reset the robust header compression (ROHC) protocol of the uplink, applying the encryption and / or integrity protection algorithm and key provided by the upper layer during the PDCP entity re-establishment process.

[0064] In addition, for DRB1, the successful delivery of the corresponding PDCP data protocol data unit (PDU) of the first PDCP SDU may not be confirmed by the lower layer. In this case, before the PDCP entity is reestablished, UE1 may perform retransmission or transmission of all PDCP SDUs that have been associated with the PDCP SN in ascending order of the count value associated with the PDCP SDU. On the other hand, due to the reconstruction of the lower layer, the DL receiving PDCP entity of UE1 may process the PDCP data PDU received from the lower layer. The entity may also apply the encryption or integrity protection algorithm and key provided by the upper layer during the PDCP entity reconstruction process.

[0065] After PDCP re-establishment, UE1 may also transmit subsequent UL PDCP PDUs to the target gNB2. The target gNB2 may deliver the UL PDCP PDUs to the User Plane Function (UPF). On the other hand, the target gNB2 may send a PDCP status report to UE1 (similar to the SN status transmission received from gNB1). Upon receiving the status report, UE1 may consider, for each PDCP SDU (if any), the bit in the bitmap set to "1" or the associated count value that is less than the value of the Fixed Mobile Convergence (FMC) field as successfully delivered. UE1 may discard the PDCP SDU as well as the corresponding PDCP data PDU. If the corresponding PDCP data PDU has been submitted to the lower layers, the discard may be indicated to the lower layers.

[0066] From the perspective of the target gNB2, the target gNB2 may transmit the DL PDCP SDU forwarded by the source gNB1 to UE1. On the other hand, gNB2 may send a PATH SWITCH REQUEST message to the AMF to inform UE1 that it has changed cells. The UPF may switch the downlink data path to gNB2. The UPF may send one or more "end marker" packets to the source gNB1 on the old path and may then release any user plane or tunnel (TNL) resources to the source gNB1.

[0067] When receiving the PATH SWITCH REQUEST ACKNOWLEDGE message from the Access and Mobility Management Function (AMF), the traditional HO behavior can be that the target gNB2 sends UE CONTEXT RELEASE to inform gNB1 that the handover is successful. Then, gNB1 can release the radio and C-plane related resources associated with the UE context. However, for UE aggregation and UE to network relay scenarios, more issues can be considered.

[0068] II. Handover Procedure for Multipath UE1 with Data Radio Bearer (DRB2) via Indirect Path

[0069] Reference now Fig. 7A and Figure 7B, depicts a communication diagram of a handover procedure for a multipath UE1 with a data radio bearer (DRB2) via an indirect path. As shown, UE1 may perform a HO from a source gNB1 to a target gNB2. In this case, UE1 may be a remote UE and UE2 may be a relay UE. UE2 may assist in transmitting the service of UE1. For example, DRB2 of UE1 may be transmitted via an indirect path (via UE2). UE1 may perform a HO from source gNB1 to target gNB2 while UE2 remains served by gNB1. After UE1 receives a HO command from source gNB1, UE1 starts accessing target gNB2 and no longer receives packets from or transmits packets to source gNB1. Service continuity of DRB2 transmitted via an indirect path may be ensured as described below.

[0070] For DRB2 of UE1 to be delivered via UE2, since UE2 does not perform HO, data packets of UE1 for DRB2 may not be forwarded from source gNB1 to target gNB2. Therefore, DL data forwarding of DRB2 packets between gNB1 and gNB2 may be suppressed until the downlink data path is switched from source gNB1 to target gNB2, and gNB2 may begin to receive DL data packets of DRB2 from UPF. At this time, target gNB2 may send path switching success information to source gNB1, and source gNB1 may send an SN status report of DRB2 to target gNB2 in response. In some embodiments, as shown in the figure, once the end marker is received from UPF, source gNB1 may send an SN status report of DRB2 to target gNB2. Upon receiving the SN status report of DRB2, target gNB2 may begin to allocate PDCP SN, perform PDCP processing (e.g., ciphering and compression based on the configuration of target gNB2) on DRB2, or forward DL PDCP PDU packets of DRB2 to source gNB1. Regarding the source gNB1, gNB1 may first transmit the DL packets of DRB2 of UE1 received directly from the UPF to UE2 using the PDCP ciphering or compression algorithm configured by the source gNB1.

[0071] Thereafter, upon receiving the PDCP PDU of DRB2 forwarded by the target gNB2, the source gNB1 may send PDCP switching information to UE1, as shown in the figure. The PDCP switching information may be forwarded by UE2 via an indirect path, or forwarded by the target gNB2. The PDCP switching information may include the DRB ID, UL or DL ​​direction, and / or a PDCP switching indication. The PDCP switching information may be in the form of a PDCP control PDU. The PDCP switching information may indicate that the PDCP ciphering, deciphering, compression, or decompression of DRB2 has been switched to the target gNB2. Thereafter, the source gNB1 may deliver the DL packets of DRB2 of UE1 forwarded by gNB2 to UE2. Based on this approach, the DL data forwarding path of DRB2 before the path switching may be: from UPF to gNB1, to UE2, and then to UE1. The DL data forwarding path of DRB2 after the path switching may be from UPF to gNB2, to gNB1, to UE2, and then to UE1.

[0072] On the other hand, for the UL packet of DRB2 of UE1 received from the indirect path, the UL packet can be forwarded directly to the UPF by the source gNB1. However, if UE1 is already connected to the target gNB2, UE1 can switch to the PDCP configuration of the target gNB2 and perform encryption or compression accordingly. In this case, the PDCP PDU of DRB2 of UE1 can be forwarded by the source gNB1 to the target gNB2, and the PDCP entity of DRB2 of UE1 at the target gNB2 can perform PDCP decryption or decompression. In order to inform the source gNB1 when to forward the UL PDCP PDU to the target gNB2, UE1 can send PDCP switching information to the source gNB1, as shown in i. The PDCP switching information can be forwarded by UE2 via an indirect path. The PDCP switching information may include DRB ID, UL or DL ​​direction, or PDCP switching indication, etc. The PDCP switching information may be in the form of a PDCP control PDU. The PDCP switching information may indicate that the PDCP PDU of DRB2 has been switched to the configuration of the target gNB.

[0073] After UE1 sends PDCP switching information to source gNB1, UE1 may start processing packets for DRB2 with the PDCP configuration of target gNB2, and may send PDCP PDUs to source gNB1 via UE2. From the perspective of source gNB1, after gNB1 receives PDCP switching information for DRB2, gNB1 may start forwarding subsequent PDCP PDUs for DRB2 to target gNB2. Before or during UE1 HO execution, the UL data forwarding path may be from UE1 to UE2, to gNB1, and finally to UPF. The UL data forwarding path after HO may be from UE1 to UE2, to gNB1, to gNB2, and then to UPF.

[0074] The UL or DL ​​forwarding tunnel for DRB2 of UE1 may be established during the HO preparation process. For example, when source gNB1 sends a HO request message to target gNB2, gNB1 may include DL forwarding UP tunnel (TNL) information and the corresponding DRB ID. In some embodiments, if target gNB2 admits the quality of service (QoS) flow of DRB2 and still allows DRB2 of UE1 to deliver an indirect path via UE2, target gNB2 may send a DL forwarding request to source gNB1, and then source gNB1 may send DL forwarding UP TNL information and the corresponding DRB ID to target gNB2.

[0075] As shown in the figure, after HO of UE1, gNB1 can still forward UL packets of UE1 to gNB2, and can receive DL packets of DRB2 of UE1 from gNB2. In addition, gNB1 can map DL packets of DRB2 of UE1 to Uu RLC channel of UE2, and map UL packets of DRB2 of UE1 to GTP-U tunnel towards gNB2. Based on this, gNB1 can maintain the association between UE1 and UE2 and the mapping configuration as part of the context of UE2. For another context of UE1, gNB1 can remove the context of UE1 when receiving the UE context release message from gNB2.

[0076] It should be noted that it may not matter whether DRB2 is in RLC unacknowledged mode (UM) or RLC acknowledged mode (AM). DRB2 may maintain the PDCP SN between gNB1 and gNB2. The above-mentioned data forwarding between gNB1 and gNB2 may be applied. For DRBs via direct path and indirect path, both gNB1 and gNB2 may maintain PDCP entities for different DRBs of UE1 during the HO execution process. SN status transmission may be delivered twice for DRBs via direct path and indirect path respectively. DRBs via direct path may use PDCP on the target gNB, while DRBs via indirect path may use PDCP on the source gNB.

[0077] III. Handover Procedure for Multipath UE1 with Split or Duplicate Data Radio Bearer (DRB3)

[0078] as Figure 5 , UE1 may perform a HO from gNB1 to gNB2. In this scenario, UE1 and UE2 may aggregate to transport UE1's service. DRB3 of UE1 may be configured as a split or duplicate bearer and transported via both direct and indirect paths. UE1 may perform a HO from source gNB1 to target gNB2 while UE2 remains served by gNB1. After UE1 receives the RRCR configuration with synchronization from gNB1, UE1 may start accessing the target gNB2 and may no longer directly receive or send packets from or to gNB1. Service continuity of DRB3 transported via both direct and indirect paths may be ensured as described below.

[0079] DRB3 of UE1 may be configured with data segmentation or duplication, and transmitted via a direct path and an indirect path respectively. The following two cases may be considered.

[0080] In the first case, after the source gNB1 sends the RRCR configuration with synchronization to UE1, the source gNB1 may send an SN status transmission to the target gNB2. Then, gNB2 may become responsible for PDCP SN allocation and data segmentation or duplication. On the other hand, UE1 may no longer transmit and receive directly via the source gNB1. Instead, UE1 may start connecting to the target gNB2 and may perform RRC reconfiguration from the target gNB2. This means that the UL data forwarding path can be from UE1 to UE2, to gNB1, to gNB2, to UPF, and from UE1 to gNB2, to UPF. In addition, the DL data forwarding path during HO execution can be from UPF to gNB1, to gNB2, to gNB1, to UE2, to UE1, and from UPF->gNB1->gNB2->UE1. Data forwarding for indirect path transmission may go back and forth between gNB1 and gNB.

[0081] In the second case, in order to reduce the data forwarding path during HO, a HO similar to Dual Active Protocol Stack (DAPS) can be considered. For example, data packets of DRB3 via an indirect path can utilize the PDCP configuration of the source gNB1, while data packets via a direct path can utilize the PDCP configuration of the target gNB2. For DL ​​packets of DRB3, UE1 can receive DL packets from target gNB2 and UE2. The PDCP entity of UE1 can maintain separate security and ROHC header decompression functions for packets from direct path and indirect path respectively, while maintaining common functions for reordering, duplicate detection and discard, and PDCP SDU delivery to upper layers of UE1 in sequence. For UL packets, UE1 can maintain a common PDCP SN allocation. Split or duplicate PDCP SDUs to be forwarded to UE2 and target gNB2 can be handled with separate PDCP configurations for ROHC header compression, ciphering, and adding PDCP headers, etc.

[0082] After the source gNB1 sends RRCReconfiguration with synchronization to UE1, the source gNB1 may send an Early SN Transmission including the DRB ID and DL count of DRB3 to the target gNB2. In addition, the source gNB1 may forward the segmented or repeated PDCP SDUs of DRB3 to the target gNB2. The target gNB2 may perform ciphering or compression on the PDCP SDUs forwarded by the source gNB1. If DRB3 is configured for PDCP repetition, the source gNB1 may also later send an Early SN Transmission including a discarded DL count to the target gNB2 if it has been confirmed that some DL PDCP SDUs are received by the lower layers from the indirect path.

[0083] On the other hand, the source gNB1 may continue to transmit the segmented or duplicated PDCP PDUs of DRB3 with the PDCP configuration of the source gNB1 to UE2 via an indirect path. Therefore, UE1 may receive DL packets from both UE2 and target gNB2 for a period of time. Once the end marker is received from the UPF, the source gNB1 may send an SN status transmission. Thereafter, the UPF may deliver the DL packets directly to the target gNB2, and the target gNB2 is responsible for the PDCP SN allocation and data segmentation or duplication operations. For UL packets, before sending the SN status transmission to the target gNB2, the receive (Rx) PDCP entity at gNB1 may be responsible for reordering, duplicate detection and discarding, and sequential delivery of the PDCP SDUs to the UPF. Thereafter, the RxPDCP entity at gNB2 may be responsible for reordering, duplicate detection and discarding, and sequential delivery of the PDCP SDUs to the UPF.

[0084] For the uplink, UE1 may recognize when to fully utilize the PDCP ciphering or compression configuration from the target gNB2. Under one approach, after gNB2 receives the SN status transmission for DRB3, or before the target gNB2 sends the UE context release to the source gNB1, the target gNB2 may send the UL PDCP switching information for DRB3 to UE1. UE1 may send the UL PDCP switching control PDU to gNB1 via an indirect path. Upon receiving the UL PDCP switching information for DRB3, gNB1 may forward the subsequent PDCP PDUs for DRB3 to gNB2.

[0085] Reference now Fig. 8A and Figure 8B , depicting the state before SN transmission ( Fig. 8A ) and after SN status transmission ( Figure 8B ) is a block diagram of a data forwarding path of a multi-path user equipment (UE1) of FIG. 1 . As shown in the figure, the DL data forwarding path of DRB3 of UE1 during UE1 HO execution and before sending SN status transmission to target gNB2 may be from UPF to gNB1, to UE2, and then to UE1 for an indirect path, and from UPF to gNB1, to gNB2, and then to UE1 for a direct path. The DL data forwarding path after sending SN status transmission to target gNB2 and UPF path switching to target gNB2 may be from UPF to gNB2, to gNB1, to UE2, and then to UE1 for a direct path, and from UPF to gNB2, to gNB1, to UE2, and then to UE1 for an indirect path.

[0086] For uplink, the UL data forwarding path during UE1 HO execution and before sending SN status transmission to target gNB2 may be from UE1 to UE2, to gNB1, and then to UPF for an indirect path, and may be from UE1 to gNB2, to gNB1, and then to UPF. The UL data forwarding path after sending SN status transmission to target gNB2 and UPF path switching to gNB2 may be from UE1 to UE2, to gNB1, to gNB2, and then to UPF for an indirect path, and may be from UE1 to gNB2, and then to UPF for a direct path.

[0087] After the HO is completed, DAPS can be utilized like UL or DL ​​packet transmission. Compared with the above steps, there may be the following differences. For DL ​​packets, gNB2 can forward the segmented or duplicated PDCP SDUs with PDCP SN to gNB1, and gNB1 can perform PDCP encryption and compression. Similarly, for UL packets, UE1 can utilize the configuration of gNB1 and gNB2 to perform PDCP encryption and compression delivered via direct path and indirect path respectively. gNB1 can forward the UL PDCP SDU to gNB2. Therefore, gNB1 can maintain the context of UE1, especially for PDCP encryption or decryption, compression or decompression, and PDCP entity, etc. In addition, it may no longer be considered when to switch UE1's PDCP to a pure target configuration.

[0088] B. Switching process of multiple multipath user equipment (UE1 and UE2)

[0089] Reference now Fig. 9 , depicts a block diagram of an example system for handover (HO) of multiple user equipment (UE1 and UE2) with multipath transmission and reception. In general, the UE1 involved in the aggregation may have a wired connection or may be co-located with other aggregation-supporting UEs (such as UE2). In some embodiments, UE1 may be connected to UE2 via a PC5 connection. It may be assumed that UE1 may be a service originating or terminating UE, and UE2 may be an aggregation UE or a relay UE. When UE1 moves, UE1 may perform a HO from gNB1 to gNB2, as shown. For an aggregation UE2 or a relay UE2, UE2 may also perform a HO. In this case, UE1 and UE2 may perform HO one by one or perform a group handover.

[0090] I. Handover Procedure for Multipath UE1 and UE2 with Data Radio Bearer (DRB2 or DRB3) Reestablished Using Radio Link Control (RLC)

[0091] The HO process here may be similar to the process described herein in conjunction with FIG. 6 . In this case, UE1 may be a remote UE and UE2 may be a relay UE. UE2 may help transmit the service of UE1. For example, DRB2 of UE1 may be transmitted via an indirect path (via UE2). When UE1 has performed a HO from source gNB1 to target gNB2, the UL data forwarding path of DRB2 of UE1 may be from UE1 to UE2, to gNB1, to gNB2, and then to UPF. Conversely, the DL data forwarding path of DRB2 of UE1 may be from UPF to gNB2, to gNB1, to UE2, and then to UE1. When UE2 also wants to perform a HO, gNB1 may prioritize the HO of UE2 over gNB2. During the HO of UE2, service continuity of DRB2 or DRB3 may be ensured, as described below.

[0092] During the HO preparation phase, the source gNB1 may send a HO request for UE2 to the target gNB2. The target gNB2 may send a HO request confirmation to gNB1 and allow the HO of UE2. Afterwards, gNB2 may no longer forward PDCP packets for UE1's DRB2 to gNB1. Instead, gNB2 may buffer DL packets for a period of time. After UE2 accesses gNB2, gNB2 may send packets for UE1's DRB2 to UE2 via an indirect path. With respect to UL packets, upon receiving RRC reconfiguration with synchronization, UE2 may no longer send UL packets to gNB1. Instead, UE2 may connect to gNB2 and may continue to send UL PDCP packets for UE1's DRB2 to gNB2.

[0093] For the Uu RLC channel of UE2 for UL PDCP packet transmission of UE1, RLC reestablishment may be performed, which means that all RLC SDUs and RLC PDUs will be discarded. In addition, all state variables of the RLC entity may be reset to initial values. In order to ensure service continuity, the following methods may be considered.

[0094] Under the first method, during RLC reestablishment, UE2 can first reset state variables and timers. However, RLC SDUs or PDUs can still be transmitted or retransmitted to gNB2. Meanwhile, for RLC SDUs or PDUs received in the RLC receiving (Rx) entity, UE2 can deliver the SDUs or PDUs to UE1. Subsequently, UE1 and gNB2 can ensure lossless packet delivery via PDCP operations.

[0095] Under the second method, for the RLC SDU or PDU received in the RLC Rx entity, UE2 may deliver the SDU or PDUS to UE1 before the corresponding RLC channel is reestablished. In addition, UE2 may send a PDCP status report of UE1's DRB2 to UE1. The PDCP status report may indicate which PDCP PDU was not successfully transmitted to gNB1. The status report may include any combination of the following fields: UE ID, DRB ID, UL count, and receiver status of UL PDCP SDU, etc. Upon receiving the PDCP status report from UE2, UE1 may perform PDCP retransmission based on the PDCP status report. To support this, when UE1 successfully sends a UL PDCP PDU to UE2, UE1 may not consider that the successful delivery of the corresponding PDCP data PDU has been confirmed.

[0096] Under the third method, when UE1 successfully sends a UL PDCP PDU to UE2, UE1 may not consider that the corresponding PDCP data PDU has been confirmed to be successfully delivered. In addition, after UE2 performs HO and connects to gNB2, gNB2 may send a UL PDCP status report to UE1, and UE1 may perform UL PDCP retransmission for the lost PDCP PDU.

[0097] II. Handover Procedure for Multipath UE1 and UE2 with Data Radio Bearer (DRB3) Using Group Handover

[0098] The HO process here may be similar to the process described herein in conjunction with FIG. 6 . In this case, UE1 and UE2 may be aggregated, and UE1 may be a service-initiating UE, and UE2 may help deliver UE1's service. For example, DRB3 of UE1 may be transmitted via both a direct path and an indirect path (via UE2). When UE1 and UE2 are to move together and jointly perform HO from source gNB1 to target gNB2, service continuity of DRB3 during HO of UE2 may be ensured, as described below.

[0099] The UE1 that initiates the service can send not only its own measurement results to the gNB, but also the measurement results of other aggregated UEs or candidate UEs supporting aggregation (such as UE2). The source gNB1 can send a HO request to gNB2, which includes not only the UE that initiates the service, but also other aggregated UEs or candidate UEs supporting aggregation (for example, UE ID or PDU session resource requirements of the aggregated UE). In addition, the UE aggregation authorization information element (IE) can be included in the handover request message. The type of aggregated UE or candidate UE supporting aggregation can be indicated in the HO request. QoS flow to UE ID or DRB mapping can also be included in the HO request message.

[0100] Therefore, gNB2 may send a Handover Request Confirm message to gNB1 including RRCReconfiguration with synchronization for multiple UEs involved in the aggregation. The target gNB2 may allow HO for only a subset of the aggregated UEs. In this case, the target gNB2 may send a Handover Request Confirm message to the source gNB1 indicating which UEs are allowed to perform HO and the corresponding RRCReconfiguration with synchronization. For other UEs that are not allowed to perform HO, the target gNB2 may send a Handover Request Confirm message including a list of not allowed UEs or a cause value.

[0101] In addition, the target gNB2 may reconfigure the UE for aggregated operation. For example, the target gNB may only accept a subset of UE1's QoS flows and remove UE2's aggregation. In some embodiments, the target gNB may involve more UEs that support aggregation to offload traffic transmission from UE1. In this case, the Handover Request Confirmation message may also include RRCReconfiguration, synchronized with those of the aggregated UEs.

[0102] The source gNB1 may send an RRCReconfiguration message with reconfiguration of multiple UE synchronization to the service initiating UE. The service initiating UE may distribute RRCReconfiguration via an internal non-specified connection or PC5 interface, synchronized with those of the aggregated UE. The involved UEs may perform synchronization and random access to the target cell. Once the involved UEs send an RRCReconfigurationComplete message, the UE may resume aggregation-based transmission or reception.

[0103] In some embodiments, the source gNB1 may first send an RRCReconfiguration with synchronization to UE1. UE1 may start to perform HO to the target gNB2. In this case, the HO process described previously may be reused herein. For example, the source gNB1 may send an early SN transmission (for the DRBs of the aggregated UE1 to be delivered via the aggregated UE2) to the target gNB2. The early SN transmission may include a DRB ID, a DL count, or a discard bitmap. The source gNB1 may still forward duplicate or fragmented PDCP SDUs to the target gNB2. Later, when UE1 is connected to the target gNB2, the target gNB2 may send a HO success to the source gNB1. The source gNB1 may send an SN status transmission to the target gNB2. Later, gNB2 may be responsible for PDCP SN allocation. At this point, if UE2 has not yet performed HO, the DL packets delivered via UE2 may be buffered at the target gNB2, or the target gNB2 forwards the DL packets to UE2 and UE2 delivers them to UE1. This forwarding may be maintained until the gNB1 sends an RRCReconfiguration with synchronization to UE2.

[0104] In addition, the source gNB1 may first send an RRCReconfiguration with synchronization to UE2. In this case, the PDCP entity of UE1 may be anchored at the source gNB1. gNB1 may forward the RL or UL packets of UE1's DRB3 to gNB2 via UE2. Therefore, the source gNB1 and the target gNB1 may establish a data forwarding tunnel for UE1's DRB3 or UE2's Uu RLC channel. After UE2 completes the HO procedure, DL data may be forwarded from gNB1 to gNB2, and UL data may be forwarded from gNB2 to gNB1. When the source gNB1 later sends an RRCReconfiguration with synchronization to UE1, UE1 may start connecting to the target gNB2. At the same time, the source gNB1 may send an SN status transmission to the target gNB2. The following procedure may reuse the conventional procedure of the normal UE HO procedure.

[0105] C. Handling Radio Link Failures

[0106] A signaling procedure may be performed for a multipath UE that detects a radio link failure (RLF) or performs RRC reestablishment. The service initiating UE1 may initially be configured with both a direct path and an indirect path. When UE1 detects RLF of the direct path, UE1 may send a direct path failure (e.g., UE ID, failure type, or measurement result) to the gNB via the indirect path. In addition, UE1 may adjust its uplink transmission. For example, UE1 may suspend transmission of the direct path, reroute packets to the indirect path, or set the primary path to the indirect path. Upon receiving a direct path failure, the gNB may configure UE1 to use only the indirect path for data transmission or reception. At the same time, UE1 may continue to perform reference signal received power (RSRP) measurements of neighboring cells and may send measurement reports to the gNB. When the measurement results of neighboring cells within one gNB are satisfactory, the gNB may configure UE1 to connect to a new neighboring cell.

[0107] D. Types of Path Switching

[0108] When UE1 and UE2 are configured to support multipath delivery of UE1's DRB or signaling radio bearer (SRB), UE1 and UE2 can be connected or aggregated via PC5 via an internal connection. Multipath delivery can be reconfigured based on radio conditions and traffic load requirements. The following path switching scenarios can be considered.

[0109] In the first case, the multipath can be reconfigured from a direct path to an indirect path. This can be configured by the gNB to remove the direct path and add the indirect path. In the second case, the multipath can be reconfigured from an indirect path to a direct path. This can be configured by the gNB to remove the indirect path and add the direct path.

[0110] In the third case, the multipath can be reconfigured from the direct path to the indirect path and the direct path. This can be configured by the gNB to add one more path via RRC signaling on the direct path. Before this, the gNB can update the RLC channel or DRB configuration of the relay UE or the aggregated UE. After that, UE1 can use these two paths for transmission based on data segmentation or duplication.

[0111] In the fourth case, the multipath can be reconfigured from an indirect path to an indirect path and a direct path. This can be configured by the gNB to add a direct path via RRC signaling. Therefore, the service-initiating UE1 can first connect to the network via a relay UE or an aggregation UE. When the service-initiating UE1 receives the direct path configuration (e.g., via reconfiguration with synchronization), the UE can perform synchronization and random access with the gNB. The UE can then send an RRCReconfiguration Complete message to the gNB. Afterwards, UE1 can use these two paths to send data services.

[0112] In the fifth case, the multipath can be reconfigured from the indirect path and the direct path to the direct path. In this case, the gNB can directly configure the UE1 that initiated the service to use the direct path. The configuration of the indirect path can be removed or deactivated, or released completely. However, for the PDCP SDU or PDU that has been delivered to the aggregated UE or relay UE, the SDU or PDU can still be transmitted to the gNB before deactivation or release. If the channel condition of the aggregated relay UE is poor, or even RLF is detected, the PDCP status report can ensure lossless delivery of data. For example, the gNB can send a PDCP status report to the UE1 that initiated the service via the direct path, and the UE1 that initiated the service retransmits the PDCP SDU or PDU that was not acknowledged by the gNB.

[0113] In the sixth case, the multipath can be reconfigured from an indirect path and a direct path to an indirect path. In this case, the gNB can directly configure the service-initiating UE1 to use the indirect path. The configuration of the direct path can be removed or deactivated, or the direct connection can be released completely. However, for the PDCP SDU or PDU of the PDCP or RLC channel that has been delivered to the service aggregation UE, the SDU or PDU can still be transmitted to the gNB before removal, deactivation or release. If the channel condition of the service-initiating UE1 is poor, or even RLF is detected, the PDCP status report can ensure lossless delivery of data. For example, the gNB can send a PDCP status report to the service-initiating UE1 via an indirect path, and the service-initiating UE1 can retransmit the PDCP SDU / PDU that has not been confirmed by the gNB to the gNB via the indirect path.

[0114] E. Facilitating the switching process

[0115] Reference now Fig.10, a flow chart of a method 1000 for facilitating handover is shown. The method 1000 may be implemented using any of the components discussed herein or performed by any of the components discussed herein, such as BS 102 or 202 or UE 104 or 204, etc. In brief, a first wireless communication node may send a handover request (1005). A second wireless communication node may receive a handover request (1010). The second wireless communication node may send a handover confirmation message (1015). The first wireless communication node may receive a handover confirmation message (1020). The first wireless communication node may send a sequence number (SN) status transfer message (1025). The second wireless communication node may receive an SN status transfer message (1030). The first wireless communication node and the second wireless communication node may transmit data packets (1035 and 1035').

[0116] Further, the first wireless communication node (e.g., BS102 or 202) can provide, transmit or otherwise send a handover request message (1005) to the second wireless communication node (e.g., BS102 or 202). The handover request message can define, reference or otherwise identify at least one wireless communication device (e.g., UE 104 or 204) in a UE to network relay configuration or a UE aggregation configuration. In some embodiments, the handover request can identify or include candidate UE information that supports aggregation. The candidate UE information that supports aggregation can identify or include an identifier of at least one wireless communication device, a protocol data unit (PDU) session resource request, etc. In some embodiments, the handover request message can identify or include a mapping of a quality of service (QoS) flow to an identifier of at least one wireless communication device or a data radio bearer (DRB), etc. The second wireless communication node can retrieve, identify or otherwise receive the handover request (1010) from the first wireless communication node.

[0117] In conjunction with the handover request, the first wireless communication node may transmit tunnel configuration information of the forwarding tunnel of the DRB to the second wireless communication node. The second wireless communication node may use the tunnel configuration information to communicate with the first wireless communication node. In some embodiments, the first wireless communication node may provide, transmit, or otherwise send the tunnel configuration information to the second wireless communication node. The tunnel configuration may be sent to the second wireless communication node together with the corresponding DRB identifier. The sending of the tunnel configuration information and the corresponding DRB identifier may be in response to receiving a forwarding request from the second wireless communication node. In some embodiments, the first wireless communication node may retrieve, identify, or otherwise receive the tunnel configuration information from the second wireless communication node.

[0118] The second wireless communication node may provide, transmit, or otherwise send a handover request confirmation message to the first wireless communication node (1015). The handover request confirmation message may reference or identify at least one wireless communication device with which handover is allowed. In some embodiments, the handover request confirmation message may include or identify a radio resource control (RRC) reconfiguration message (e.g., RRCReconfiguration). The RRC reconfiguration message may include or contain information required to access the second wireless communication node corresponding to the at least one wireless communication device. In some embodiments, the handover request confirmation message may reference or identify at least one second wireless communication device (e.g., UE 104 or 204) with which handover is not allowed, or may include at least one cause value, etc. The first wireless communication node may retrieve, identify, or otherwise receive the handover confirmation message from the second wireless communication node (1020).

[0119] The first wireless communication node may provide, transmit, or otherwise send a sequence number (SN) transmission message to the second wireless communication node (1025). The SN transmission message may identify or include a DRB identifier or a downlink (DL) count, etc. In some embodiments, the SN transmission message may be sent by the first wireless communication node in response to receiving path switch information from the second wireless communication node. In some embodiments, the SN transmission message may be sent by the first wireless communication node in response to receiving an end marker from a user plane function (UPF). In some embodiments, the first wireless communication node may send the SN transmission message in response to sending an RRC reconfiguration message. The RRC reconfiguration message may identify, include, or otherwise contain information required for the wireless communication device to access the second wireless communication node. In some embodiments, before sending the SN transmission message, the first wireless communication node may perform reordering, duplicate detection, discard PDCP service data units (SDUs), or deliver PDCP service data units (SDUs) to the UPF. The second wireless communication node may retrieve, identify, or otherwise receive the SN transmission message from the first wireless communication node (1030). In some implementations, after receiving the SN transfer message from the first wireless communication node, the second wireless communication node may perform reordering, duplicate detection, discard, or deliver the PDCP SDU.

[0120] The first wireless communication node and the second wireless communication node may communicate data packets (1035 and 1035'). In some embodiments, the second wireless communication node may transmit, provide, or otherwise send a packet data convergence protocol (PDCP) protocol data unit (PDU) packet having a PDCP encryption or PDCP compression algorithm configured at the second wireless communication node. The first wireless communication node may retrieve, obtain, or otherwise receive the PDCP PDU from the second wireless communication node. In some embodiments, the first wireless communication node may provide, transmit, or otherwise send path switching information to the wireless communication device. The path switching information may include or identify a control PDU, the control PDU including at least one of the following: a DRB identifier, an indicator of an uplink (UL) or downlink (DL) direction, a path switching indication, or an indicator of a PDCP encryption or PDCP compression algorithm of the second wireless communication node, etc.

[0121] In some embodiments, the first wireless communication node may provide, transmit, or otherwise send a segmented or duplicated PDCP service data unit (SDU) of the DRB to the second wireless communication node. The second wireless communication node may retrieve, obtain, or otherwise receive the segmented or duplicated PDCP SDU from the first wireless communication node. In some embodiments, in response to receiving a DL PDCP PDU at a lower layer, the first wireless communication node may provide, transmit, or otherwise send a DL count to the second wireless communication node. The second wireless communication node may retrieve, obtain, or otherwise receive a DL count from the first wireless communication node.

[0122] F. Complete the switching process

[0123] Reference now Fig.11 , depicting a flow chart of a method 1110 for completing a handover. The method 1100 may be implemented using or performed by any of the components discussed herein, such as BS 102 or 202 or UE 104 or 204, etc. In short, a first wireless communication device may transmit path switching information to a first wireless communication node or a second wireless communication node (1105, 1105', or 1105"). The first wireless communication device may configure one or more paths (1110). The first wireless communication device may maintain functionality (1115). The first wireless communication device may transmit packets to a second wireless communication device, a first wireless communication node or a second wireless communication node, etc. (1120, 1120', 1120" or 1120'").

[0124] In more detail, the first wireless communication device (e.g., UE 104 or 204) may communicate path switching information with the first wireless communication node (e.g., BS 102 or 202) or the second wireless communication node (e.g., BS 102 or 202) (1105, 1105' or 1105"). In some embodiments, the first wireless communication device may retrieve, obtain, or otherwise receive the path switching information directly from the second wireless communication node or indirectly via the second wireless communication device (e.g., UE 102 or 202). The path switching information may include a control protocol data unit (PDU). The control PDU may identify or include one or more of the following: a DRB identifier, an indicator of an uplink (UL) or downlink (DL) direction, a path switching indication, or an indicator of a PDCP encryption or compression algorithm configured by the second wireless communication node, etc. In some embodiments, the path switching information may identify that a protocol data convergence protocol (PDCP) PDU of a data radio bearer (DRB) is switched to a PDCP encryption or PDCP compression algorithm configured by the second wireless communication node.

[0125] In some embodiments, the path switching information may be received from the first wireless communication node in response to the first wireless communication node sending a sequence number (SN) transmission message of a data radio bearer (DRB). In some embodiments, the path switching information may be received from the first wireless communication node in response to the first wireless communication node receiving a UE context release from the second wireless communication node. In some embodiments, the first wireless communication device may provide, transmit, or otherwise send the path switching information to the first wireless communication node via the second wireless communication device.

[0126] In some embodiments, the first wireless communication device may send path switching information of a data radio bearer (DRB) to the first wireless communication node via the second wireless communication device. In some embodiments, the first wireless communication device may receive path switching information of a DRB (e.g., a second DRB) from the second wireless communication. Upon receiving, the first wireless communication device may send the path switching information to the first wireless communication node via the second wireless communication device. In some embodiments, the first wireless communication device may send a PDCP PDU of the DRB to the first wireless communication node via the second wireless communication device.

[0127] The first wireless communication device may configure one or more paths (1110). A path may be a direct path that directly communicatively couples the first wireless communication device with a wireless communication node. A path may be an indirect path that indirectly communicatively couples the first wireless communication device with a wireless communication node. In some embodiments, the first wireless communication device may configure the path to suspend transmission on the direct path, reroute packets to the indirect path, or set the indirect path as the primary path. In some embodiments, the first wireless communication device may retrieve, identify, or otherwise receive the configuration from the wireless communication node. In some embodiments, the configuration may identify or include: the addition, modification, or removal of a direct path; the addition, modification, or removal of an indirect path; activation or deactivation of a direct path; or activation or deactivation of an indirect path, etc.

[0128] The first wireless communication device may establish, perform, or otherwise maintain a function (1115) for one or more paths. In some embodiments, the first wireless communication device may maintain a first function of transmitting a downlink (DL) packet via a direct path using a PDCP entity. The first function may be to perform at least one of decompression, decryption, and removal of a robust header compression (ROHC) header based on a configuration of the first wireless communication node. In some embodiments, the first wireless communication device may maintain a second function of transmitting a DL packet via an indirect path using a PDCP entity. The second function is to perform at least one of decompression, decryption, and removal of a robust header compression (ROHC) header based on a configuration of a second wireless communication node. In some embodiments, the first wireless communication device may maintain a third function to perform reordering, duplicate detection, discard, or delivery of a PDCP service data unit (SDU) to an upper layer, etc.

[0129] In some embodiments, the first wireless communication device may set, configure, or otherwise maintain PDCP SN assignments for uplink (UL) packets transmitted via a direct path and an indirect path. In some embodiments, the first wireless communication device may set or maintain a first configuration for handling fragmented or duplicated UL packets transmitted via a direct path. In some embodiments, the first wireless communication device may set or maintain a second configuration for handling fragmented or duplicated UL packets transmitted via an indirect path. The first configuration and the second configuration may be separate PDCP configurations to perform compression, ciphering, or adding a robust header compression (ROHC) header, etc.

[0130] In some embodiments, the first wireless communication device may communicate (e.g., PDCP SDUs or PDUs) in a UE-to-network relay configuration or a UE aggregation configuration, at least in part concurrently with the deactivation of the path. In some embodiments, the first wireless communication device may retrieve, obtain, or receive an RRC reconfiguration message containing information required to access the second wireless communication node from the first wireless communication node to the plurality of wireless communication devices in the UE aggregation configuration. In some embodiments, the first wireless communication device may perform or implement aggregation-based communications with the plurality of wireless communication devices in response to the RRC reconfiguration of each wireless communication device.

[0131] The first wireless communication device may transmit packets with a second wireless communication device, a first wireless communication node, or a second wireless communication node, etc. (1120, 1120', 1120", or 1120'). The first wireless communication device may receive a DL packet from a wireless communication node via a direct path or an indirect path. In some embodiments, the first wireless communication device may retrieve, obtain, or otherwise receive a DL packet of a DRB from the first wireless communication node via the second wireless communication device (e.g., using an indirect path). In some embodiments, the first wireless communication device may receive a DL packet via an indirect path via the second wireless communication device. In some embodiments, the first wireless communication device may receive a DL packet from the second wireless communication node via a direct path. In some embodiments, the first wireless communication device may retrieve, obtain, or otherwise receive a radio link channel (RLC) SDU or PDU from the second wireless communication device while or before the second wireless communication device reestablishes the RLC.

[0132] In some embodiments, the first wireless communication device may retrieve, obtain, or otherwise receive a status report of the DRB (e.g., a PDCP status report) from the second wireless communication device. In some embodiments, the status report may identify or include one or more of the following: an indicator identifying whether the PDCP PDU was successfully transmitted to the first wireless communication node; an identifier of the first wireless communication device; a DRB identifier; a UL count; or a receiver status of a UL PDCP SDU, etc. In some embodiments, the first wireless communication device may resend or retransmit the PDCP PDU based on the PDCP status report.

[0133] In some embodiments, the first wireless communication device may transmit a PDCP PDU to the second wireless communication device for retransmitting a corresponding lost PDCP PDU. In some embodiments, in response to a corresponding UL PDCP PDU being successfully transmitted to the second wireless communication device, the first wireless communication device may avoid determining that a UL PDCP data PDU is successfully transmitted to the second wireless communication device.

[0134] Although various embodiments of the present solution have been described above, it should be understood that they are given only by way of example and not by way of limitation. Similarly, various figures may depict example architectures or configurations, which are provided to enable those of ordinary skill in the art to understand the exemplary features and functions of the present solution. However, these personnel will understand that the present solution is not limited to the example architectures or configurations shown, but may be implemented using a variety of alternative architectures and configurations. In addition, as will be understood by those of ordinary skill in the art, one or more features of an embodiment may be combined with one or more features of another embodiment described herein. Therefore, the breadth and scope of the present disclosure should not be limited by any of the above-described exemplary embodiments.

[0135] It should also be understood that any reference to an element herein using names such as "first," "second," etc. does not generally limit the number or order of those elements. Rather, these names may be used herein as a convenient means of distinguishing between two or more elements or instances of an element. Thus, a reference to a first element and a second element does not mean that only two elements may be employed, or that the first element must precede the second element in some manner.

[0136] In addition, those of ordinary skill in the art will understand that information and signals may be represented using any of a variety of different technologies and techniques. For example, the data, instructions, commands, information, signals, bits, and symbols that may be referenced in the above description may be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof.

[0137] Those of ordinary skill in the art will further understand that any of the various illustrative logic blocks, modules, processors, devices, circuits, methods, and functions described in conjunction with the aspects disclosed herein may be implemented by electronic hardware (e.g., digital implementation, analog implementation, or a combination of the two), firmware, various forms of programs or design codes containing instructions (for convenience, may be referred to herein as "software" or "software modules"), or any combination of these technologies. In order to clearly illustrate this interchangeability of hardware, firmware, and software, various illustrative components, blocks, modules, circuits, and steps have been generally described above in terms of their functions. Whether such functionality is implemented as hardware, firmware, or software, or a combination of these technologies, depends on the specific application and the design constraints imposed on the overall system. Technicians may implement the described functions in various ways for each specific application, but such implementation decisions will not cause a departure from the scope of this disclosure.

[0138] In addition, it will be understood by those of ordinary skill in the art that the various illustrative logic blocks, modules, devices, components, and circuits described herein may be implemented or performed within or by an integrated circuit (IC) including a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), or other programmable logic device, or any combination thereof. The logic blocks, modules, and circuits may further include antennas and / or transceivers to communicate with various components within a network or within a device. A general purpose processor may be a microprocessor, but alternatively, the processor may be any conventional processor, controller, or state machine. The processor may also be implemented as a combination of computing devices, for example, a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors combined with a DSP core, or any other suitable configuration to perform the functions described herein.

[0139] If implemented in software, the function can be stored as one or more instructions or codes on a computer-readable medium. Therefore, the steps of the method or algorithm disclosed herein can be implemented as software stored on a computer-readable medium. Computer-readable media include both computer storage media and communication media, and the communication media include any media that can enable a computer program or code to be transferred from one place to another. The storage medium can be any available medium that a computer can access. As an example and not limitation, such a computer-readable medium may include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, disk storage or other magnetic storage device, or any other medium that can be used to store the desired program code in the form of instructions or data structures and can be accessed by a computer.

[0140] As used herein, the term "module" refers to software, firmware, hardware, and any combination of these elements to perform the relevant functions described herein. In addition, for the purpose of discussion, various modules are described as discrete modules. However, it is obvious to a person of ordinary skill in the art that two or more modules can be combined to form a single module that performs the relevant functions according to the implementation of the present solution.

[0141] In addition, memory or other storage and communication components can be used in the implementation of the present solution. It should be understood that, for the sake of clarity, the above description has described the implementation of the present solution with reference to different functional units and processors. However, it will be apparent that any appropriate functional distribution between different functional units, processing logic elements or domains can be used without departing from the present solution. For example, the functions illustrated as being performed by a separate processing logic element or controller can be performed by the same processing logic element or controller. Therefore, reference to a specific functional unit is only a reference to a suitable device for providing the described function, rather than indicating a strict logical or physical structure or organization.

[0142] Various modifications to the embodiments described in this disclosure will be apparent to those skilled in the art, and the general principles defined herein may be applied to other embodiments without departing from the scope of this disclosure. Therefore, this disclosure is not intended to be limited to the embodiments shown herein, but is to be given the widest scope consistent with the novel features and principles disclosed herein, as described in the appended claims.

Claims

1. A method for facilitating handover, comprising: The first wireless communication node and the second wireless communication node transmit tunnel configuration information of a forwarding tunnel of a data radio bearer (DRB), The second wireless communication node is configured to communicate with the first wireless communication node using the tunnel configuration information.

2. The method according to claim 1, further comprising: A sequence number (SN) transmission message is sent by the first wireless communication node to the second wireless communication node.

3. The method according to claim 2, wherein: Sending the SN transmission message further includes sending the SN transmission message in response to receiving path switching information from the second wireless communication node.

4. The method according to claim 2, wherein: Sending the SN transfer message further includes sending the SN transfer message in response to receiving an end marker from a user plane function (UPF).

5. The method according to claim 2, wherein: Sending the SN transmission message further comprises sending the SN transmission message in response to sending an RRCReconfiguration message including information required to access the second wireless communication node to the wireless communication device.

6. The method according to claim 5, wherein: The SN transfer message includes at least one of a DRB identifier or a downlink (DL) count.

7. The method according to claim 2, further comprising: A Packet Data Convergence Protocol (PDCP) Protocol Data Unit (PDU) packet is received by the first wireless communication node from the second wireless communication node, the PDCP PDU packet having a PDCP encryption or PDCP compression algorithm configured in the second wireless communication node.

8. The method according to claim 7, further comprising: In response to receiving the PDCP PDU from the second wireless communication node, the first wireless communication node sends path switch information to the wireless communication device.

9. The method according to claim 8, wherein: The path switch information includes a control PDU, which includes at least one of the following: a DRB identifier, an indicator of uplink (UL) or downlink (DL) direction, a path switch indication, or an indicator of the PDCP encryption or the PDCP compression algorithm of the second wireless communication node.

10. The method according to claim 1, wherein: Transmitting the tunnel configuration information further includes sending the tunnel configuration information and a corresponding DRB identifier to a second wireless communication node in response to receiving a forwarding request from the second wireless communication node.

11. The method according to claim 1, further comprising: The first wireless communication node sends a segmented or duplicated PDCP service data unit (SDU) of the DRB to the second wireless communication node.

12. The method according to claim 11, further comprising: In response to receiving a DL PDCP PDU at a lower layer, a DL count is sent by the first wireless communication node to the second wireless communication node.

13. The method according to claim 1, further comprising: Before sending the SN transfer message, the first wireless communication node performs at least one of the following: reordering, duplicate detection, discarding, or delivering the PDCP SDU to the UPF.

14. The method according to claim 13, further comprising: After receiving the SN transmission message, the second wireless communication node performs at least one of the following: reordering, duplicate detection, discarding or delivering the PDCP SDU to the UPF.

15. A method for facilitating handover, comprising: A handover request message is sent by a first wireless communication node to a second wireless communication node, the handover request message identifying a user equipment (UE) to at least one wireless communication device in a network relay configuration or an aggregation configuration.

16. The method according to claim 15, wherein: The handover request message includes candidate UE information supporting aggregation, and the candidate UE information supporting aggregation includes at least one of the following items: an identifier of the at least one wireless communication device or a PDU session resource request.

17. The method according to claim 15, wherein: The handover request message includes a mapping of a quality of service (QoS) flow to at least one of an identifier of the at least one wireless communication device or a DRB.

18. The method according to claim 15, further comprising: A handover request confirmation message is received by the first wireless communication node from the second wireless communication node, the handover request confirmation message identifying at least one wireless communication device with which handover is permitted.

19. The method according to claim 18, wherein: The handover request confirm message identifies an RRCReconfiguration message including information required to access the second wireless communication node corresponding to the at least one wireless communication device.

20. The method according to claim 18, wherein: The handover request confirm message identifies at least one second wireless communication device with which handover is not allowed, or includes at least one cause value.

21. A wireless communication device, comprising a processor and a memory, wherein: The processor is configured to read code from the memory and implement the method according to any one of claims 1 to 20.

22. A computer program product comprising computer readable program medium code stored thereon, which, when executed by a processor, causes the processor to implement the method according to any one of claims 1 to 20.

Images