Multipath communication for user equipment in centralized and distributed unit split architectures

Abstract

Presented is a system, method, apparatus, or computer-readable medium for multipath communication. A centralized unit (CU) may send multipath configuration information to a distributed unit (DU). The CU may receive multipath configuration response information from the DU. In some embodiments, the multipath configuration information comprises mapping information that may identify an association between an F1-U tunnel of a data radio bearer (DRB) for a remote wireless communication device and a Uu radio link control (RLC) channel for a relay wireless communication device, or an association between an F1-U tunnel of a data radio bearer (DRB) for an anchor wireless communication device and a Uu radio link control (RLC) channel for an aggregated wireless communication device.

Description

[Technical Field]

[0001] The present disclosure relates generally to wireless communications, including, but not limited to, systems and methods for multipath transmission and reception for user equipment (UE) in a centralized unit (CU) and distributed unit (DU) split architecture. [Background technology]

[0002] The 3rd Generation Partnership Project (3GPP®), a standards organization, is currently working on the specification of a new air interface called 5G New Radio (5G NR) and the Next Generation Packet Core Network (NG-CN or NGC). 5G NR will have three major components: a 5G Access Network (5G-AN), a 5G Core Network (5GC), and a User Equipment (UE). To facilitate the enablement of different data services and requirements, elements of the 5GC, also called network functions, have been simplified, with some of them being software-based so that they can be adapted according to need. Summary of the Invention [Means for solving the problem]

[0003] The exemplary embodiments disclosed herein are directed to solving one or more problems associated with the prior art and providing additional features that will become readily apparent by reference to the following detailed description when considered in conjunction with the accompanying drawings. According to various embodiments, exemplary systems, methods, devices, and computer program products are disclosed herein. It should be understood, however, that these embodiments are presented by way of example, and not limitation, and that various modifications to the disclosed embodiments may be made while remaining within the scope of the present disclosure, as will be apparent to those skilled in the art upon perusal of this disclosure.

[0004] At least one aspect is directed to a system, method, apparatus, or computer-readable medium for multipath communication. A centralized unit (CU) may send multipath configuration information to a distributed unit (DU). The CU may receive multipath configuration response information from the DU. In some embodiments, the multipath configuration information may include path indication information that identifies at least one of a direct path or an indirect path.

[0005] In some embodiments, the multipath configuration information comprises mapping information that may identify an association between an F1-U tunnel of a data radio bearer (DRB) for a remote wireless communication device and a Uu radio link control (RLC) channel for a relay wireless communication device, or an association between an F1-U tunnel of a data radio bearer (DRB) for an anchor wireless communication device and a Uu radio link control (RLC) channel for an aggregated wireless communication device.

[0006] In some embodiments, the multipath configuration information comprises mapping information that may identify an association between a signaling radio bearer (SRB) for a remote wireless communication device and a Uu radio link control (RLC) channel for a relay wireless communication device, or an association between a signaling radio bearer (SRB) for an anchor wireless communication device and a Uu radio link control (RLC) channel for an aggregated wireless communication device.

[0007] In some embodiments, the multipath configuration information may include at least one of an identifier for a radio bearer (RB), an uplink (UL) user plane (UP) tunnel (TNL) information, an identifier for a relay wireless communication device, an identifier for an aggregated wireless communication device, an identifier for a Uu radio link control (RLC) channel, an identifier for a path, an indication of a direct or indirect path, an indication of a primary or secondary path, an indication of data splitting or data duplication, or a path activation indication.

[0008] In some embodiments, the identifier of the RB may be at least one of an identifier of a DRB or an SRB. In some embodiments, the multipath configuration information with the mapping information may be used by the DU to refrain from setting up an RLC channel of a relay wireless communication device or an anchor wireless communication device for a DRB. In some embodiments, the multipath configuration information with the indirect path indication may be used by the DU to refrain from setting up an RLC channel of a relay wireless communication device or an anchor wireless communication device for a DRB or an SRB.

[0009] In some embodiments, the multipath configuration information may be used by the DU to configure a first RLC channel of a relay wireless communication device or an anchor wireless communication device for a direct path of a DRB or SRB. In some embodiments, the multipath configuration information may include a path activation indication that identifies the path as active or inactive. In some embodiments, the data split indication may include at least one of a data split threshold or a data split ratio.

[0010] In some embodiments, the multipath configuration information with data splitting may indicate distribution of multiple data packets across a first RLC channel corresponding to a direct path and a second RLC channel corresponding to an indirect path. In some embodiments, the multipath configuration information may identify DRBs for multiple F1 user plane tunnels between the CU and the DU.

[0011] In some embodiments, the multipath configuration information may include uplink (UL) user plane (UP) tunnel (TNL) information for at least one of the direct or indirect paths. In some embodiments, the multipath configuration information may include two or more UL UP TNL information for the split DRB.

[0012] In some embodiments, the multipath configuration response information may indicate at least one of an acceptance or failure of a route. In some embodiments, the multipath configuration response information may include an identifier for the route, or an indication of a direct or indirect route, or an indication of a primary or secondary route that is accepted or rejected. In some embodiments, the multipath configuration response information may identify one of a cause of the route failure or an identifier for a non-acceptable or non-acceptable route for data packet delivery.

[0013] In some embodiments, the multipath configuration response information may indicate a multipath SRB or DRB setup failure or a multipath SRB or DRB modification failure. In some embodiments, the multipath configuration response information may include downlink (DL) user plane (UP) tunnel (TNL) information regarding an acceptable path. In some embodiments, the multipath configuration information may include at least one of a multipath setup request, a multipath modification request, or a multipath release request. [Brief explanation of the drawings]

[0014] 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 merely depict exemplary embodiments of the present solution to facilitate the reader's understanding of the present solution. As such, the drawings should not be considered limiting of the scope, scope, or applicability of the present solution. It should be noted that for clarity and ease of illustration, the drawings are not necessarily drawn to scale.

[0015] [Figure 1] FIG. 1 illustrates an example cellular communication network in which the techniques disclosed herein may be implemented, according to certain embodiments of the present disclosure.

[0016] [Figure 2]FIG. 2 illustrates a block diagram of an example base station and user equipment device, in accordance with some embodiments of the present disclosure.

[0017] [Figure 3] FIG. 3 illustrates a block diagram of a user equipment (UE) to network relay in accordance with an illustrative embodiment.

[0018] [Figure 4] FIG. 4 illustrates a block diagram of user equipment (UE) aggregation, in accordance with an illustrative embodiment.

[0019] [Figure 5A] FIG. 5A illustrates a block diagram of an intra-distribution unit (DU) multipath configuration, in accordance with an illustrative embodiment.

[0020] [Figure 5B] FIG. 5B illustrates a block diagram of an inter-distribution unit (DU) multipath configuration, in accordance with an illustrative embodiment.

[0021] [Figure 6] FIG. 6 illustrates a communication diagram of a multipath configuration for different radio bearers (RBs) and multiple distributed units (DUs), in accordance with an illustrative embodiment.

[0022] [Figure 7] FIG. 7 illustrates a communication diagram of a multipath configuration with split bearers and multiple distributed units (DUs), in accordance with an illustrative embodiment.

[0023] [Figure 8] FIG. 8 illustrates a communication diagram of a multipath configuration for different radio bearers (RBs) and a single distribution unit (DU), in accordance with an illustrative embodiment.

[0024] [Figure 9]FIG. 9 illustrates a communication diagram of a multipath configuration for split bearers under the same centralized unit (CU) and distributed unit (DU), in accordance with an illustrative embodiment.

[0025] [Figure 10] FIG. 10 illustrates a communication diagram of a multipath configuration for split bearers under the same centralized unit (CU) and distributed unit (DU) for data splitting, in accordance with an illustrative embodiment.

[0026] [Figure 11] FIG. 11 illustrates a communication diagram of a multipath signaling radio bearer (SRB) configuration under the same centralized unit (CU) and distributed unit (DU) for data splitting or duplication, in accordance with an illustrative embodiment.

[0027] [Figure 12] FIG. 12 illustrates a flow diagram of a method for multipath communication, in accordance with an illustrative embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0028] Detailed Description Various exemplary embodiments of the present solution are described below with reference to the accompanying figures to enable those skilled in the art to make and use the present solution. As will be apparent to those skilled in the art, after reading this disclosure, various changes or modifications of the examples described herein can be made without departing from the scope of the present solution. Thus, the present solution is not limited to the exemplary embodiments and applications described and illustrated herein. Additionally, any specific order or hierarchy of steps in the methods disclosed herein is merely an example approach. Based on design preferences, the specific order or hierarchy of steps in a disclosed method or process can be rearranged while remaining within the scope of the present solution. Thus, those skilled in the art will understand that the methods and techniques disclosed herein present various steps or acts in a sample order, and that the present solution is not limited to the specific order or hierarchy presented, unless expressly stated otherwise. 1. Mobile communication technology and environment

[0029] 1 illustrates an exemplary wireless communication network and / or system 100 in which the techniques disclosed herein may be implemented, according to certain embodiments of the present disclosure. In the following discussion, 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 exemplary network 100 includes a base station 102 (hereinafter “BS 102,” also referred to as a wireless communication node), user equipment devices 104 (hereinafter “UE 104,” also referred to as a wireless communication device), which may communicate with each other via communication links 110 (e.g., wireless communication channels), and a cluster of cells 126, 130, 132, 134, 136, 138, and 140 overlaying a geographic area 101. In FIG. 1, the BS 102 and the UE 104 are contained within the respective geographic boundaries of the cell 126. Each of the other cells 130, 132, 134, 136, 138, and 140 may include at least one base station operating in its allocated bandwidth and providing adequate radio coverage to its intended users.

[0030] For example, the BS 102 may operate within an allocated channel transmission bandwidth to provide adequate coverage to the UE 104. The BS 102 and the 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 this disclosure, the BS 102 and the UE 104 are generally described herein as non-limiting examples of “communication nodes” that may practice the methods disclosed herein. Such communication nodes may be capable of wireless and / or wired communication in accordance with various embodiments of the present solution.

[0031] 2 illustrates a block diagram of an exemplary wireless communication system 200 for transmitting and receiving wireless communication signals (e.g., OFDM / OFDMA signals) in accordance with some embodiments of the present solution. System 200 may include components and elements configured to support known or conventional operational features that need not be described in detail herein. In one illustrative embodiment, system 200 can be used to communicate (e.g., transmit and receive) data symbols within a wireless communication environment, such as wireless communication environment 100 of FIG. 1, as described above.

[0032] The system 200 generally includes a base station 202 (hereinafter “BS 202”) and a user equipment device 204 (hereinafter “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 and interconnected, as needed, with each other via a data communication bus 220. 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 and interconnected, as needed, with each other via a data communication bus 240. The BS 202 communicates with the UE 204 via a communication channel 250, which may be any wireless channel or other medium suitable for the transmission of data as described herein.

[0033] As will be understood by those skilled in the art, system 200 may further include any number of modules other than those shown in FIG. 2 . Those skilled in the art will understand that the various illustrative blocks, modules, circuits, and processing logic described in connection with the embodiments disclosed herein may be implemented in hardware, computer-readable software, firmware, or any practical combination thereof. To clearly illustrate this interchangeability and compatibility of hardware, firmware, and software, the various illustrative components, blocks, modules, circuits, and steps are described generally in terms of their functionality. Whether such functionality is implemented as hardware, firmware, or software may depend on the particular application and design constraints imposed on the overall system. Those skilled in the art, familiar with the concepts described herein, may implement such functionality in a suitable manner for each particular application, but such implementation decisions should not be interpreted as limiting the scope of the present disclosure.

[0034] According to some embodiments, the UE transceiver 230 may be referred to herein as an “uplink” transceiver 230, including a radio frequency (RF) transmitter and an RF receiver, each with circuitry coupled to the antenna 232. A duplex switch (not shown) may alternatively couple the uplink transmitter or receiver to the uplink antenna in a time-duplexed manner. Similarly, according to some embodiments, the BS transceiver 210 may be referred to herein as a “downlink” transceiver 210, including an RF transmitter and an RF receiver, each with circuitry coupled to the antenna 212. A downlink duplex switch may alternatively couple the downlink transmitter or receiver to the downlink antenna 212 in a time-duplexed manner. The operation of the two transceiver modules 210 and 230 may be coordinated in time such that the downlink transmitter is coupled to the downlink antenna 212 at the same time that the uplink receiver circuitry is coupled to the uplink antenna 232 for reception of transmissions over the wireless transmission link 250. Conversely, the operation of the two transceivers 210 and 230 may be coordinated in time such that the uplink transmitter is coupled to the uplink antenna 232 at the same time that the downlink receiver is coupled to the downlink antenna 212 for reception of transmissions over the wireless transmission link 250. In some embodiments, there is close time synchronization, with minimal guard time between duplex direction changes.

[0035] The UE transceiver 230 and the base station transceiver 210 are configured to communicate over a wireless data communication link 250 and cooperate with suitably configured RF antenna arrays 212 / 232 capable of supporting a particular wireless communication protocol and modulation scheme. In some demonstrative 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 and the like. However, it should be understood that the present disclosure is not necessarily limited in application to particular standards and associated protocols. Rather, the UE transceiver 230 and the base station transceiver 210 may be configured to support alternative or additional wireless data communication protocols, including future standards or variations thereof.

[0036] According to various embodiments, the BS 202 may be, for example, an evolved NodeB (eNB), a serving eNB, a target eNB, a femto station, or a pico station. In some embodiments, the UE 204 may be embodied in various types of user devices, such as a mobile phone, a smartphone, a personal digital assistant (PDA), a tablet, a laptop computer, a wearable computing device, etc. The processor modules 214 and 236 may be implemented or realized using 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, discrete gate or transistor logic, discrete hardware components, or any combination thereof, designed to perform the functions described herein. As such, a processor may be realized as a microprocessor, a controller, a microcontroller, a state machine, or the like. A processor may also be implemented as a combination of computing devices, e.g., a digital signal processor and a microprocessor, multiple microprocessors, one or more microprocessors in conjunction with a digital signal processor core, or any other such configuration.

[0037] Furthermore, the steps of a method or algorithm described in connection with the embodiments disclosed herein may be embodied in hardware, firmware, software modules, or any practical combination thereof, executed directly by processor modules 214 and 236, respectively. Memory modules 216 and 234 may be implemented as RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. In this regard, memory modules 216 and 234 may be coupled to processor modules 210 and 230, respectively, such that processor modules 210 and 230 may read information from and write information to memory modules 216 and 234, respectively. Memory modules 216 and 234 may also be integrated within their respective processor modules 210 and 230. In some embodiments, memory modules 216 and 234 may each include a cache memory for storing temporary variables or other intermediate information during execution of instructions to be executed by 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.

[0038] The network communications module 218 generally represents the hardware, software, firmware, processing logic, and / or other components of the base station 202 that enable bidirectional communications 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 communications module 218 may be configured to support Internet or WiMAX traffic. In a typical deployment, without limitation, the network communications module 218 provides an 802.3 Ethernet interface so that the base station transceiver 210 may communicate with conventional Ethernet-based computer networks. As such, the network communications module 218 may include a physical interface for connection to a computer network (e.g., a mobile switching center (MSC)). As used herein with respect to specified operations or functions, the terms “configured for,” “configured to,” and variations thereof, refer to devices, components, circuits, structures, machines, signals, etc. that are physically constructed, programmed, formatted, and / or arranged to perform the specified operations or functions.

[0039] The Open Systems Interconnection (OSI) model (referred to herein as the "Open Systems Interconnection Model") is a conceptual and logical layout that defines the network communications used by systems (e.g., wireless communication devices, wireless communication nodes) that open them to interconnect and communicate with other systems. The model is divided into seven subcomponents or layers, each representing a conceptual collection of services provided to the layers above and below it. The OSI model also defines logical networks and effectively describes computer packet transfers by using different layer protocols. The OSI model may also be referred to as the seven-layer OSI model or seven-layer model. In some embodiments, the first layer may be the physical layer. In some embodiments, the second layer may be the medium access control (MAC) layer. In some embodiments, the third layer may be the radio link control (RLC) layer. In some embodiments, the fourth layer may be the packet data convergence protocol (PDCP) layer. In some embodiments, the fifth layer may be the radio resource control (RRC) layer. In some embodiments, the sixth layer is a non-access stratum (NAS) layer or an Internet Protocol (IP) layer, and the seventh layer may be another layer. 2. Multipath communication for user equipment (UE) in a centralized unit (CU) and distributed unit (DU) split architecture

[0040] Presented herein are systems and methods for multipath transmission and reception for UEs in a CU / DU split architecture that focus on data splitting, data duplication over multipaths, and path switching between direct and indirect paths.

[0041] With the development of wireless multimedia services, the demand for high-data-rate services may increase significantly. Under such conditions, the system capacity and coverage requirements of traditional cellular networks may become higher. Meanwhile, due to application scenarios of public safety, social networks, short-distance data sharing, and local content deployment, among others, the demand for proximity services, which enable users to recognize or communicate with neighboring users or objects, may also increase.

[0042] However, cellular networks may have limitations in supporting high data rate services and proximity services. As a result, device-to-device (D2D) communication technologies may be proposed to meet such demands. By adopting D2D technologies, the load on cellular networks can be reduced, the power consumption of user equipment can be reduced, data rates can be increased, and the robustness of the network infrastructure can be improved. The demand for high data rate services and proximity services can therefore be met. D2D technologies may also be referred to as proximity services (ProSe) or sidelink communications, and the interface between devices may be a PC5 interface.

[0043] To support applications and services involving a wider range, sidelink-based relay communication can be used to extend coverage and improve network power consumption. For example, sidelink-based relay communication can be applied to indoor relay communication, smart agriculture, smart factories, and public safety services. Referring now to FIG. 3 , depicted is a block diagram of a user equipment (UE) to a network relay. As shown, sidelink-based relay communication can involve a user equipment (UE) (e.g., UE1 shown in FIG. 3 ) in an area with weak or no coverage. Under such conditions, UE1 can be enabled to communicate with the network (e.g., base station (BS) shown in FIG. 3 ) via a nearby UE2 covered by the network. As a result, the network coverage can be extended and the network capacity can be expanded. In this scenario, UE2 can be referred to as a UE-network relay, and UE1 can be referred to as a remote UE. On the other hand, if the remote UE is within coverage, multipath relaying can be supported. In coverage, remote UEs can be connected to the network via both direct (e.g., data is transmitted directly between the remote UE and the network) and indirect (e.g., data is forwarded via a relay UE) paths, which can have the potential to improve reliability, robustness, and throughput.

[0044] This multipath relay approach can also be utilized for UE aggregation, where a UE is connected to the network via a direct route and via another UE using non-standardized UE-UE interconnection. Figure 4 illustrates a block diagram of user equipment (UE) aggregation. As shown, UE aggregation may involve one user equipment (UE) (e.g., UE1 shown in Figure 4) aggregating other UEs (e.g., UE2 and UE3 shown in Figure 4) for their uplink (UL) transmission to the network or downlink reception from it. Here, the interconnection between UE1 and UE2 or between UE1 and UE3 may be based on sidelink, Wi-Fi, Bluetooth, or a wired connection. Nevertheless, the interconnection between the UEs may be ideal. UE aggregation may target applications requiring high UL bit rates on 5G terminals when a typical UE is too limited by its UL UE transmit power to achieve the required bit rate, especially at the edge of the cell. Additionally, UE aggregation can improve reliability, stability, and reduce service delay as well.

[0045] With the development of 5G mobile radio technology, one such technology that may be used may include a split network architecture in which radio access network (RAN) functionality is divided between a centralized unit (CU) and multiple distributed units (DUs). For example, RAN functions may be split at the point between the Packet Data Convergence Protocol (PDCP) layer and the Radio Link Control (RLC) layer of the 5G protocol stack. In the stack, the DU may handle all processes up to and including the RLC layer functions, and the CU may handle the PDCP layer and higher layer functions prior to the core network. This differentiation of RAN functions may provide numerous advantages to mobile network operators. For example, through isolation of the stack from the PDCP layer and above, the CU may be able to act as a cloud-based convergence point between multiple heterogeneous technologies in the provisioned network and, therefore, may be able to serve multiple heterogeneous DUs.

[0046] Regarding support for multipath UE-network relay and UE aggregation, impacts on the CU / DU split architecture focus on multipath configuration and path switching, which may be used for multipath support (e.g., a direct path via the UE and an indirect path via UE-network relay or aggregated UEs). Under UE multipath transmission, the UE may be limited in UL transmission (Tx) capability, and one UE may be associated with many UEs for UE aggregation or connected to many relay UEs for UE-network relay. To support higher requirements for UL traffic, including data rate, latency, and reliability, multipath transmission may be used. A UE may be connected to a network and may transmit or receive data traffic with the network via a direct path and one or more indirect paths (e.g., data traffic is forwarded by another UE). UE-UE interconnection may be based on a sidelink connection or use a non-standardized connection.

[0047] Figure 5A illustrates a block diagram of an intra-distribution unit (DU) multipath configuration, and Figure 5B illustrates a block diagram of an inter-distribution unit (DU) multipath configuration. For UEs connected to the same gNB using one direct path and one indirect path, the direct and indirect paths may be via the same DU or different DUs. UE1 may be a remote UE, traffic-originating UE, or anchor UE, while UE2 may be a relay UE or aggregated UE. UE1 and UE2 may be interconnected via a PC5 or internal interface. UE1 and UE2 may be served by the same DU (e.g., as in Figure 5A) or different DUs (e.g., as in Figure 5B). To support this multipath scenario under the CU-DU split architecture, the following issues may be examined, and potential solutions are discussed herein below. A. Inter-Distributed Unit (DU) Scenario

[0048] In one scenario, UE1 and UE2 may be served by different DUs, and what is discussed herein is the multipath transmission configuration of UE1 between the CU and the DU. I. Multipath Configuration for Different Radio Bearers (RBs) and Multiple Distributed Units (DUs)

[0049] UE1 and UE2 are served by different DUs due to multipath delivery of UE1's traffic. UE1's Quality of Service (QoS) flows may be mapped to two bearers, namely, data radio bearers DRB1 and DRB2. DRB1 may be delivered via a direct path, while DRB2 may be delivered via an indirect path (to be forwarded by UE2). DRB1 and DRB2 may share the same Service Data Adaptation Protocol (SDAP) entity, while separate PDCP entities may be established for DRB1 and DRB2.

[0050] Referring now to Figure 6, depicted is a communication diagram of a multipath configuration for different radio bearers (RBs) and multiple distributed units (DUs). The CU may request the DU1 to configure DRB1 and send a direct path indication via a UE context modification request. In addition, uplink (UL) user plane (UP) tunnel (TNL) information may be included in the UE context modification request. In response to receiving the DRB1 configuration request, if the UL UP TNL Information information element (IE) is included in the UE CONTEXT MODIFICATION REQUEST message for DRB1, the gNB-DU may include a downlink (DL) user plane (UP) tunnel (TNL) information IE in the UE CONTEXT MODIFICATION RESPONSE message and may configure one radio link control (RLC) entity for DRB1 using the direct path indication.

[0051] For DRB2, associated data packets may be delivered via UE2's relay, and therefore a Uu RLC channel between DU2 and UE2 should be established. As shown, the CU may request DU2 to establish a Uu RLC channel via UE2-specific F1AP signaling. The CU may also request DU2 to establish DRB2 via UE1-specific F1AP signaling. The CU also sends to DU2 an indirect path indication, UL UP TNL information, or mapping information between DRB2's F1-U tunnel and relay UE2's Uu RLC channel. The mapping information may include any combination of the following fields: data radio bearer identifier (DRB ID), relay UE ID or aggregated UE ID, and Uu RLC channel ID.

[0052] In response to receiving the DRB2 setup request, if the UL UP TNL Information IE is included in the UE CONTEXT SETUP REQUEST message for DRB2, the gNB-DU may include the DL UP TNL Information IE in the UE CONTEXT SETUP RESPONSE message. However, because this DRB indicates an indirect path or a mapping between the F1-U tunnel and the Uu RLC channel of DRB2 is configured, DU2 cannot set up one additional RLC channel with UE1 for DRB2. DU2 may send a response message to the CU with the established DRB2 ID and logical channel identifier (LCID).

[0053] After the F1AP-based configuration, the CU may send an RRCReconfiguration message to UE1, including the configuration of DRB1, DRB2, or a path indication. In addition, the CU may send an RRCReconfiguration message to UE2, including the configuration of the Uu RLC channel or mapping information between the Uu RLC channel and UE1's DRB.

[0054] Thereafter, when DU2 receives a data packet from the CU via the F1-U tunnel corresponding to DRB2, DU2 may map the packet to a Uu RLC channel with UE2 and deliver the data packet to UE2. In response to receiving the data packet, UE2 may automatically forward the packet to UE1 via the internal connection or via the PC5 RLC channel. II. Multipath Configuration for Split Bearer and Multiple Distributed Units (DUs)

[0055] Referring now to FIG. 7, depicted is a communication diagram of a multipath configuration for split bearers and multiple distributed units (DUs). Some of UE1's QoS flows may be mapped to DRB3, and DRB3 may be configured as a split bearer to be delivered via both the direct and indirect paths. In this case, the CU may request DU1 and DU2 to set up DRB3, respectively. Two F1-U tunnels corresponding to DU1 and DU2 may be established for DRB3. For DL packets, the PDCP entity in the CU may be responsible for data segmentation and deliver the split packets to the corresponding F1-U tunnels. In this way, DU1 and DU2 may receive packets to be delivered to UE1 via the direct and indirect paths, respectively.

[0056] Using DU2 as an example, the CU may request DU2 to configure DRB3 via UE1-specific F1AP signaling. The CU may also send to DU2 an indirect path indication, UL UP TNL information, or mapping information between DRB3's F1-U tunnel and UE2's Uu RLC channel. The mapping information may include any combination of the following fields: DRB ID, relay UE ID or aggregated UE ID, and Uu RLC channel ID. In response to receiving the DRB3 configuration request, if the UL UP TNL Information IE is included in the UE CONTEXT SETUP REQUEST message for DRB3, the gNB-DU may include the DL UP TNL Information IE in the UE CONTEXT SETUP RESPONSE message. Because this DRB indicates an indirect path or mapping between DRB3's F1-U tunnel and Uu RLC channel is configured, DU2 cannot configure an additional RLC channel with UE1 for DRB3. DU2 may send a response message to CU with the established DRB3 ID and LCID.

[0057] After the F1AP-based configuration, the CU may send an RRCReconfiguration message to UE1, including the configuration of DRB3, the data splitting rule, or the indirect path mapping information. In addition, the CU may send an RRCReconfiguration message to UE2, including the configuration of the Uu RLC channel or the mapping information between the Uu RLC channel of UE2 and the DRB of UE1.

[0058] When DU2 receives a DL packet from the F1-U tunnel corresponding to DRB3, DU2 may detect that the packet from this F1-U tunnel should be mapped to a Uu RLC channel with UE2 (relay UE or aggregated UE). DU2 may then add an adaptation layer header, deliver the packet to the Uu RLC channel with UE2, and transmit it to UE2. When UE2 receives a data packet from the Uu RLC channel, UE2 may check the adaptation layer header and then forward the packet to UE1 via the PC5 interface or internal connection.

[0059] For UL packets, the PDCP entity in UE1 may perform data segmentation based on segmentation rules configured by the CU and deliver the packets to Uu via its own RLC channel (direct route) or to UE2 via the PC5 interface or internal connection (indirect route). When UE2 receives a data packet from UE1, UE2 may detect the corresponding source UE and RB IDs, then map the packet to the Uu RLC channel, and deliver the packet to DU2. DU2 may identify the source UE ID and radio bearer (RB) ID in the adaptation layer header and detect that this is a packet for UE1's DRB3. DU2 may then forward the packet to the CU via the F1-U tunnel corresponding to UE1's DRB3. Data packets transmitted via the indirect route may include an adaptation layer header (i.e., including a UE ID and an RB ID), which can be encapsulated by UE1 or UE2. For an indirect path via an internal connection or PC5 connection between UE1 and UE2, UE2 may be configured with a mapping between UE1's DRB ID and UE2's Uu RLC channel ID. DU2 may further forward packets to the CU via the F1-U tunnel. The PDCP entity of DRB3 located in the CU may perform PDCP PDU decoding, decompression, and reordering. III. Multipath Configuration for Packet Data Convergence Protocol (PDCP) Replication

[0060] Some of UE1's QoS flows may be mapped to DRB4. DRB4 may be configured for PDCP replication, and packets may be delivered via both the direct and indirect routes. In this case, the CU may request DU1 and DU2 to configure DRB4, respectively. Two F1-U tunnels corresponding to DU1 and DU2 may be established for DRB4. For DL packets, the PDCP entity in the CU may be involved in data replication and deliver the replicated packets to the corresponding F1-U tunnels. In this way, DU1 and DU2 may receive packets to be delivered to UE1 via the direct and indirect routes, respectively.

[0061] Using DU2 as an example, the CU may request DU2 to configure DRB4 via UE1-specific F1AP signaling. The CU may also send to DU2 a primary or secondary path indication, configured multipath replication, multipath replication activation, UL UP TNL information, or mapping information between DRB4's F1-U tunnel and UE2's Uu RLC channel. Among them, multipath replication activation can be configured as active or inactive. The mapping information may include any combination of the following fields: DRB ID, relay UE ID or aggregated UE ID, and Uu RLC channel ID. In response to receiving the DRB4 configuration request, if the UL UP TNL Information IE is included in the UE CONTEXT SETUP REQUEST message for DRB4, the gNB-DU may include the DL UP TNL Information IE in the UE CONTEXT SETUP RESPONSE message. Because the mapping between the F1-U tunnel and the Uu RLC channel of DRB4 is configured, DU2 cannot set up one additional RLC channel with UE1 for DRB4. DU2 may send a response message with the established DRB4 ID and LCID to the CU.

[0062] After the F1AP-based configuration, the CU may send an RRCReconfiguration message to UE1, including the configuration of DRB4, data replication indication, or indirect path mapping information. In addition, the CU may send an RRCReconfiguration message to UE2, including the configuration of the Uu RLC channel or mapping information between the Uu RLC channel and UE1's DRB. If DU2 receives multipath replication activation as inactive, replicated packets received from the corresponding F1-U tunnel may be discarded.

[0063] When DU2 receives a DL packet from the F1-U tunnel corresponding to DRB4, DU2 may detect that the packet from this F1-U tunnel should be mapped to a Uu RLC channel with UE2 (relay UE or aggregated UE). DU2 may then add an adaptation layer header, deliver the packet to the Uu RLC channel with UE2, and transmit it to UE2. When UE2 receives a data packet from the Uu RLC channel, DU2 may check the adaptation layer header and then forward the packet to UE1 via the PC5 interface or internal connection.

[0064] For the UL, UE1 may duplicate the data packet of DRB4 and deliver the packet to DU1 and UE2, respectively. When UE2 receives the data packet from UE1, DU2 may detect the corresponding source UE and RB ID, then map the packet to the Uu RLC channel, and deliver the packet to DU2. DU2 may further forward the packet to the CU via the F1-U tunnel. The PDCP entity of DRB4 located in the CU may perform PDCP PDU decoding, decompression, reordering, and duplicate packet discarding.

[0065] For UL packets, the PDCP entity in UE1 may perform data replication and deliver the packets to Uu via its own RLC channel (e.g., via the direct route) or to UE2 via the PC5 interface or internal connection (e.g., via the indirect route). When UE2 receives a data packet from UE1, UE2 may detect the corresponding source UE and RB IDs. UE2 may then map the packet to the Uu RLC channel and deliver the packet to DU2. DU2 may identify the source UE ID and RB ID in the adaptation layer header and detect that the packet is for UE1's DRB4. DU2 may then forward the packet to the CU via the F1-U tunnel corresponding to UE1's DRB4. The data packet transmitted via the indirect route may include an adaptation layer header (e.g., including the UE ID and RB ID), which can be encapsulated by UE1 or UE2. DU2 may further forward the packet to the CU via the F1-U tunnel. UE2 may be configured by the gNB with a mapping between UE1 DRB ID and UE2's Uu RLC channel. The PDCP entity of DRB4 located in the CU may perform PDCP PDU decoding, decompression, and reordering. B. Intra-Distributed Unit (DU) Scenario

[0066] UE1 and UE2 may be served by the same DU for multipath delivery of UE1's traffic, and what is discussed in this specification is the UE's multipath transmission configuration between the CU and the DU. I. Multipath configuration for different radio bearers (RB) under the same distribution unit (DU)

[0067] UE1 and UE2 are served by the same DU, and for multipath delivery of UE1's traffic, the following scenarios may be considered: UE1's QoS flow may be mapped to two bearers, namely DRB1 and DRB2. DRB1 may be delivered via a direct path, while DRB2 may be delivered via an indirect path (forwarded by UE2). DRB1 and DRB2 may share the same SDAP entity, while separate PDCP entities are established for DRB1 and DRB2.

[0068] Referring now to Figure 8, depicted is a communication diagram of a multipath configuration for different radio bearers (RBs) and a single distributed unit (DU). As shown, the CU may request DU1 to configure DRB1 via a UE context modification request. In addition, UL UP TNL information may be included in the UE context modification request. In response to receiving the DRB1 configuration request, if the UL UP TNL Information IE is included in the UE CONTEXT MODIFICATION REQUEST message for DRB1, DU1 may include the DL UP TNL Information IE in a UE CONTEXT MODIFICATION RESPONSE message and configure one RLC entity for DRB1.

[0069] For DRB2, related data packets may be delivered through UE2's relay, and therefore a Uu RLC channel between DU1 and UE2 needs to be established. The CU may request DU1 to establish a Uu RLC channel via UE2-specific F1AP signaling. The CU may also request DU1 to establish DRB2 via UE1-specific F1AP signaling. The CU may also send UL UP TNL information and mapping information between DRB2's F1-U tunnel and UE2's Uu RLC channel to DU1. The mapping information may include any combination of the following fields: DRB ID, relay UE ID or aggregated UE ID, and Uu RLC channel ID. In response to receiving the DRB2 establishment request, if the UL UP TNL Information IE is included in the UE CONTEXT SETUP REQUEST message for DRB2, DU1 may include a DL UP TNL Information IE in the UE CONTEXT SETUP RESPONSE message. Since the mapping between the F1-U tunnel and the Uu RLC channel of DRB2 is configured, DU1 cannot set up one additional RLC channel with UE1 for DRB2. Instead, the Uu RLC channel of UE2 may be used for delivery of data packets of DRB2. DU2 may send a response message with the established DRB2 ID and LCID to the CU.

[0070] After the F1AP-based configuration, the CU may send an RRCReconfiguration message to UE1, including the configuration of DRB1, DRB2, or a path indication. In addition, the CU may send an RRCReconfiguration message to UE2, including the configuration of the Uu RLC channel or mapping information between the Uu RLC channel and UE1's DRB.

[0071] Thereafter, when DU1 receives a data packet from the CU via the F1-U tunnel corresponding to DRB2, DU1 may map the packet to a Uu RLC channel with UE2 and deliver the data packet to UE2. In response to receiving the data packet, UE2 may automatically forward the packet to UE1 via the internal connection or via the PC5 RLC channel. II. Multipath Split Bearer Configuration Under the Same DU and CU for Data Split

[0072] Some of UE1's QoS flows may be mapped to DRB3, which is configured as a split bearer to be delivered via both the direct and indirect paths. In this case, the CU may request DU1 to set up DRB3. Referring now to FIG. 9, depicted is a communication diagram of a multipath configuration for split bearers under the same centralized unit (CU) and distributed unit (Du). Two F1-U tunnels corresponding to the direct and indirect paths may be established for DRB3a. For DL packets, the PDCP entity in the CU may be responsible for data segmentation and deliver the split packets to the corresponding F1-U tunnels. In this way, DU1 may receive split packets from different F1-U tunnels and then deliver them to UE1 via the direct and indirect paths, respectively.

[0073] Because data packets of DRB3 will be delivered via UE2's relay (indirect path), a Uu RLC channel between DU1 and UE2 may be established. As shown, the CU may request DU1 to establish a Uu RLC channel via UE2-specific F1AP signaling. Then, the CU may request DU1 to establish DRB3 via UE1-specific F1AP signaling. The CU may also send a set of path information to DU1, which may include at least one of the following information: a path ID, a direct path or indirect path indication, a primary path or secondary path indication, UL UP TNL information, or mapping information between DRB3's F1-U tunnel and UE2's Uu RLC channel. The mapping information may include any combination of the following fields: a DRB ID or UL UP TNL information, a relay UE ID or aggregated UE ID, and a Uu RLC channel ID.

[0074] More than one UL UP TNL information may be included. One may be for the direct path and the others may be for the indirect path. Alternatively, one regular UL UP TNL information may be sent by the CU to DU1, and one or more additional UL UP TNLs for data division may be sent by the CU to DU1. In addition, the CU may also include a primary or secondary path indication to DU1. For example, the CU may indicate to DU1 that the indirect path (or one of the F1-U tunnels) is the primary path and the direct path (the other F1-U tunnel) is the secondary path, or vice versa.

[0075] In response to receiving the DRB3 configuration request, DU1 may configure one RLC entity or logical channel for the direct path of DRB3. For the indirect path, DU1 may not configure one additional RLC channel with UE1 for DRB3. Instead, the Uu RLC channel with UE2 may be used for DRB3 delivery. DU1 may send a response message to the CU with the established DRB3 ID and LCID. In response to receiving the DRB3 configuration request, if the UL UP TNL Information IE is included in the UE CONTEXT SETUP REQUEST message for DRB3, the gNB-DU may include the DL UP TNL Information IE in the UE CONTEXT SETUP RESPONSE message.

[0076] If DU1 can accept one of the data packet delivery paths, DU1 may send a response to the CU to indicate the accepted path. For example, DU1 may send a response to the CU to indicate that the direct path, the indirect path, or both are accepted. Alternatively, DU1 may send a response to the CU to indicate that the primary path, the secondary path, or both are accepted. DU1 may also send an accepted path ID or a rejected path ID to the CU. In addition, one or more corresponding DL UP TNL information may be included in the response message sent by DU1 to the CU. Alternatively, if DU1 can accept one of the data packet delivery paths, DU1 may send a response to the CU to indicate that the DRB failed to be set up. In addition, DU1 may send a response to the CU to indicate that the failure cause is that the data packet delivery path is not accepted or one of the rejected path IDs.

[0077] After the F1AP-based configuration, the CU may send an RRCReconfiguration message to UE1, including the configuration of DRB3, data splitting rules, or indirect path mapping information. In addition, the CU may send an RRCReconfiguration message to UE2, including the configuration of the Uu RLC channel or mapping information between the Uu RLC channel and UE1's DRB. Thereafter, data packets of DRB3 may be delivered between UE1 and the DU / CU via both direct and indirect paths. III. Multipath Configuration for Split Bearers Under the Same Centralized Unit (CU) and Distributed Unit (DU) for Data Splitting

[0078] Some of UE1's QoS flows may be mapped to DRB3, and DRB3 may be configured as a split bearer to be delivered via both direct and indirect paths. In this case, the CU may request DU1 to set up DRB3. Compared with the scenario with multi-path split bearer configuration as discussed above, in this scenario, there may be one F1-U tunnel between DU1 and the CU for DRB3. The CU may send data splitting rules to DU1, and DU1 may be involved in data splitting and deliver the split packets to corresponding RLC channels.

[0079] Since the data packets of DRB3 will be delivered via the relay (indirect path) of UE2, a Uu RLC channel between DU1 and UE2 may be established. Referring now to Figure 10, depicted is a communication diagram of a multipath configuration for split bearers under the same centralized unit (CU) and distributed unit (DU) for data splitting. As shown, the CU may request DU1 to establish a Uu RLC channel via UE2-specific F1AP signaling.

[0080] The CU may then request DU1 to configure DRB3 via UE1-specific F1AP signaling. The CU may also send a data splitting rule for DRB3 and a set of path information, which may include at least one of the following information: a path ID, a direct or indirect path indication, a primary or secondary path indication, or mapping information. The data splitting rule may include a threshold for data splitting or a data split ratio between a set of paths. The mapping information may include any combination of the following fields: a DRB ID, a relay UE ID or aggregated UE ID, or a Uu RLC channel ID, among others. One UL UP TNL information may be included in the DRB3 configuration request sent from the CU to DU1.

[0081] In response to receiving the DRB3 configuration request, DU1 may configure one additional RLC entity or logical channel with UE1 for the direct path of DRB3 or for a path not associated with bearer mapping information. For an indirect path or a path associated with bearer mapping information, DU1 may not configure one additional RLC entity or logical channel with UE1 for DRB3. Instead, the Uu RLC channel with UE2 may be used for DRB3 delivery. DU1 may send a response message with the established DRB3 ID to the CU. In response to receiving the DRB3 configuration request, if the UL UP TNL Information IE is included in the UE CONTEXT SETUP REQUEST message for DRB3, the gNB-DU may include the DL UP TNL Information IE in the UE CONTEXT SETUP RESPONSE message.

[0082] If DU1 can accept one of the data packet delivery paths, DU1 may send a response to the CU to indicate the accepted path. For example, DU1 may send a response to the CU to indicate that the direct path, the indirect path, or both are accepted. Alternatively, DU1 may send a response to the CU to indicate that the primary path, the secondary path, or both are accepted. DU1 may also send accepted path IDs or rejected path IDs to the CU. In addition, one or more corresponding DL UP TNL information may be included in the response message sent by DU1 to the CU. Alternatively, if DU1 can accept only one of the data packet delivery paths, DU1 may send a response to the CU to indicate that the DRB failed to be set up. In addition, DU1 may send a response to the CU to indicate that the failure cause is that the data packet delivery path is not accepted or one of the rejected path IDs.

[0083] After the F1AP-based configuration, the CU may send an RRCReconfiguration message to UE1, including the configuration of DRB3, data splitting rules, or indirect path mapping information. In addition, the CU may send an RRCReconfiguration message to UE2, including the configuration of the Uu RLC channel or mapping information between the Uu RLC channel and UE1's DRB. Thereafter, data packets of DRB3 may be delivered between UE1 and the DU / CU via both direct and indirect paths.

[0084] When DU1 receives DL packets from the F1-U tunnel corresponding to DRB3, DU1 may detect that packets from this F1-U tunnel should be split into direct and indirect paths. The direct path may be configured as the primary path, and the indirect path may be configured as the secondary path, and a threshold for data splitting may be configured. In such a case, DU1 may transmit data packets toward the direct path when the data buffer size of DRB3 is lower than the threshold for data splitting. Otherwise, DU1 may transmit packets toward either the direct path or the indirect path. Alternatively, if a data split ratio is configured in DU1, DU1 may distribute data packets to the RLC channels corresponding to the direct path or the indirect path based on the data split ratio.

[0085] For UL packets, the PDCP entity in UE1 may perform data segmentation based on segmentation rules configured by the CU and deliver the packets to Uu via its own RLC entity or logical channel (e.g., via a direct route) or to UE2 via a PC5 interface or internal connection (e.g., via an indirect route). When UE2 receives a data packet from UE1, UE2 may detect the corresponding source UE and RB IDs. UE2 may then map the packet to a Uu RLC channel and deliver the packet to DU1. DU1 identifies the source UE ID and RB ID in the adaptation layer header and detects that the packet is for UE1's DRB3. DU1 may then forward the packet to the CU via the F1-U tunnel corresponding to UE1's DRB3. Also, when DU1 receives a data packet for DRB3 from UE1, DU1 may also forward the packet to the CU via the same F1-U tunnel corresponding to UE1's DRB3. The PDCP entity of the DRB3 located in the CU may perform PDCP PDU decoding, decompression, and reordering. IV. Multipath Signaling Radio Bearer (SRB) Configuration Under the Same Centralized Unit (CU) and Distributed Unit (DU) for Data Splitting or Replication

[0086] UE1's SRB2 may be configured as a duplicated or split bearer to be delivered via both the direct and indirect paths. In this case, the CU may request DU1 to set up SRB2. The CU may send a data splitting rule or a duplication indication to DU1, and DU1 may participate in data splitting or duplication and deliver the split or duplicated packets to the corresponding RLC channels.

[0087] A Uu RLC channel between DU1 and UE2 may be established because data packets of SRB2 will be delivered via UE2's relay (indirect path). Referring now to FIG. 11 , depicted is a communication diagram for a multipath signaling radio bearer (SRB) configuration under the same centralized unit (CU) and distributed unit (DU) for data splitting or duplication. As shown, the CU may request DU1 to set up a Uu RLC channel via UE2-specific F1AP signaling. Then, the CU may request DU1 to set up SRB2 via UE1-specific F1AP signaling. The CU may also send a data splitting rule or duplication indication for SRB2 to DU1.

[0088] In addition, the CU may send a set of route information, which may include at least one of the following information: route ID, direct or indirect route indication, primary or secondary route indication, or mapping information. The data splitting rule may include a threshold for data splitting or a data split ratio among the set of routes. The mapping information may include any combination of the following fields: SRB ID, relay UE ID or aggregated UE ID, Uu RLC channel ID.

[0089] In response to receiving the SRB2 configuration request, DU1 may configure one RLC entity or logical channel for SRB2 if a direct path is configured or a path not associated with bearer mapping information is configured. For an indirect path or a path associated with bearer mapping information, DU1 may not configure one additional RLC entity or logical channel with UE1 for SRB2. Instead, the Uu RLC channel with UE2 may be used for DRB3 delivery. DU1 may send a response message with the established SRB ID to the CU.

[0090] If DU1 can accept one of the data packet delivery paths, DU1 may send a response to the CU to indicate the accepted paths. For example, DU1 sends a response to the CU to indicate that the direct path, the indirect path, both, or all are accepted. Alternatively, DU1 may send a response to the CU to indicate that the primary path, the secondary path, both, or all are accepted. DU1 may also send the accepted path IDs or the rejected path IDs to the CU. Alternatively, if DU1 cannot accept all of the data packet delivery paths, DU1 may send a response to the CU to indicate that the SRB setup failed. In addition, DU1 may send a response to the CU to indicate that the failure cause is that the data packet delivery path is not accepted or one of the rejected path IDs.

[0091] After the F1AP-based configuration, the CU may send an RRCReconfiguration message to UE1, including the configuration of SRB2, data splitting rules, or indirect path mapping information. In addition, the CU may send an RRCReconfiguration message to UE2, including the configuration of the Uu RLC channel or mapping information between the Uu RLC channel and UE1's SRB. Thereafter, data packets of SRB2 may be delivered between UE1 and the DU / CU via both direct and indirect paths.

[0092] When DU1 receives data packets for SRB2 included in F1AP signaling to UE1, DU1 may detect that the data packets of SRB2 should be split or duplicated to the direct and indirect paths. A threshold for data splitting may be configured. Using the configuration, DU1 may transmit the data packets toward the direct path when the data buffer size of DRB3 is lower than the threshold for data splitting. Otherwise, DU1 may transmit the packets to either the direct or indirect path. Alternatively, if a data split ratio is configured in DU1, DU1 may distribute the data packets of SRB2 to RLC channels corresponding to the direct or indirect path based on the data split ratio. On the other hand, if the data packets of SRB2 are configured to be duplicated, DU1 may perform packet duplication and then distribute the duplicated data packets of SRB2 to RLC entities or logical channels corresponding to both the direct and indirect paths.

[0093] When UE1 first accesses the network via the direct route, UE1's SRB via the direct route may be used for signaling delivery. After a while, if an indirect route is configured, both the direct route and the indirect route may become available for SRB packet delivery. The CU may send a request to DU1 to modify the SRB. The CU may send an SRB list to DU1 to be modified. The list may include at least one of the following fields: SRB ID, data splitting rule or duplication indication, duplication activation indication, and a set of path information to be added, modified, or released, among others.

[0094] Regarding the path information to be added or modified, the information may include at least one of the following information: a path ID, a direct or indirect path indication, a primary or secondary path indication, or mapping information. Regarding the path information to be released, the information may include a path ID, a direct or indirect path indication, a primary or secondary path indication. The mapping information may include any combination of the following fields: an SRB ID, a relay UE ID or aggregated UE ID, and a Uu RLC channel ID. The replication activation indication may indicate active or inactive. Based on the SRB modification request sent from the CU, DU1 may modify the corresponding SRB configuration and then perform SRB packet delivery accordingly. V. Multiple F1-U tunnel configuration for UE aggregation

[0095] For a CU / DU split scenario, multiple F1-U tunnels may be established between the CU and the DU for each aggregated transmission. For example, UE1's DRB1 traffic may be delivered via an aggregation of UE1, UE2, and UE3, and a Dual Active Protocol Stack (DAPS)-like aggregation mode may be used. In such a case, the DRB may be configured for UE1, UE2, and UE3 with the same set of QoS flows. Here, the DAPS-like aggregation mode may mean that a common PDCP entity responsible for PDCP sequence number (SN) allocation or PDCP reordering and duplicate discarding may be established in UE1 and the CU. On the other hand, separate PDCP entities responsible for UE1's packet encryption and decryption or compression and decompression may be established in UE1, UE2, and UE3, and the CU. When the DU delivers data packets from these DRBs to the CU, the DU may deliver the DRBs through different F1-U tunnels so that the CU can further deliver these data packets to different PDCP entities. In this sense, multiple DRBs and corresponding F1-U tunnels may be established between a CU and a DU for DAPS-like aggregation for a given traffic source UE.

[0096] For DAPS-like aggregation, a different GTP-U tunnel may be established between the CU and the DU for each aggregated path. Alternatively, F1-U may be extended to include path ID or UE ID and DRB ID information for the CU to identify the corresponding PDCP entity for subsequent decoding and decompression processing.

[0097] On the other hand, for L2 SL U2N relay-based aggregation, one F1-U tunnel may be used for data delivery of a given DRB, independent of the number of paths configured. However, the CU may send data segmentation rules to the DU so that the DU can perform data segmentation and distribute data packets to the corresponding UE RLC channels or logical channels. For replication, the CU may also inform the DU of the aggregation-based replication of the DRB. The CU may set up two GTP-U tunnels with the DUs corresponding to the source and replicated packet delivery. In this case, the UE DRB request and response to be set up may include two GTP-U tunnel configurations. One configuration may be for the source packets, and another configuration may be for the replicated packets. In addition, the DU may be informed of the mapping between the two GTP-U tunnels, the aggregation paths, the UE ID, and the RLC channel or logical channel ID. C. Route switching

[0098] UE1 and UE2 may be served by the same DU. The CU may configure UE1 to use multipath distribution of UE1's DRB or SRB. The multipath distribution may be reconfigured based on radio conditions and traffic load requirements. The following path switching scenarios may be considered: I. Direct to Multipath and Multipath to Direct

[0099] UE1's SRB1 may initially be configured to use direct path distribution. After some time, the CU may reconfigure UE1's SRB1 using multipath distribution. For DL, the CU may split or duplicate SRB1's signaling to two or more paths. The CU may request the DU to configure the Uu RLC channel and mapping rules on the indirect path. In addition, the CU may request the DU to modify UE1's SRB configuration, which may include the SRB ID and the modified path configuration. The modified path configuration may include path additional information. The path additional information configuration may include any combination of the following fields: path ID, direct or indirect path, primary or secondary path, path activation, and bearer mapping, among others. The CU may then split or duplicate the PDCP PDU and transmit the PDU via multiple direct and indirect paths. From the perspective of traffic terminating UE1, UE1 may now begin receiving DL PDCP PDUs from multiple paths. For the UL, once anchor UE1 receives the configuration to switch to multiple paths, UE1 may start transmitting subsequent PDCP PDUs on multiple direct and indirect paths.

[0100] On the other hand, the CU may switch UE1's DRB transmission from multiple paths and use only the direct path. For DL, the CU may request the DU to modify UE1's DRB configuration, which may include the DRB ID and the modified path configuration. The modified path configuration may include path release information. The path release information configuration may include any combination of the following fields: path ID, direct or indirect path, primary or secondary path, and deactivation, among others. The CU or anchor UE1 can no longer deliver DL or UL PDCP PDUs to the RLC channels of the indirect path. Instead, the CU or UE1 may deliver DL or UL PDCP PDUs toward the logical channels of the direct path. For packets delivered to the RLC channels of the indirect path, packets can still be transmitted until the RLC channels or logical channels become empty. II. Direct to indirect and indirect to direct pathways

[0101] With respect to the switch from the direct path to the indirect path, the CU or anchor UE may no longer deliver DL or UL PDCP PDUs to the RLC entity or logical channel of the direct path. Instead, the CU or UE may deliver DL or UL PDCP PDUs toward the RLC channel of the indirect path. To support this, the CU may request the DU to modify UE1's DRB configuration, which may include the DRB or SRB ID and the modified path configuration. The modified path configuration may include the following fields: indirect path add and direct path release configuration, which may further include any combination of the following: path ID, direct or indirect path, primary or secondary path, path activation, or deactivation, among others. For packets delivered to the RLC entity or logical channel of the direct path, packets may still be transmitted until the RLC entity or logical channel becomes empty. This may also apply to the switch from the indirect path to the direct path. III. Indirect to Multipath and Multipath to Indirect

[0102] The gNB may send the Uu RLC channel configuration to UE 2. The gNB may then switch data packets from UE 1 to UE 2. Similarly, for the uplink, the gNB may send a Uu RLC channel to UE 2, and UE 1 may then send UL data packets to UE 2, which forwards them to the gNB. D. Process for multipath communication

[0103] 12, depicted is a flow diagram of a method 1200 for multipath communication. Method 1200 may be implemented using or performed by any of the components discussed above, such as a centralized unit (CU) and one or more distributed units (DUs) of base station 102 or 202. Under method 1200, the CU may transmit multipath configuration information (1205). The DU may receive the multipath configuration information (1210). The DU may transmit multipath configuration response information (1215). The CU may receive the multipath configuration response information (1220).

[0104] More specifically, the CU may provide, transmit, or otherwise send the multipath configuration information to a DU (e.g., DU1 or DU2) (1205). The multipath configuration information may include various information for adding, establishing, modifying, or releasing a route at the DU. In some embodiments, the multipath configuration information may include a multipath setup request to establish, add, or set a route, a multipath modification request to modify an existing route, or a multipath release request to release a route. The multipath configuration information may include or identify route indication information. The route indication information may identify a direct or indirect route to be configured.

[0105] The multipath configuration information may identify or include mapping information. In some embodiments, the mapping information may include or identify an association between an F1-U tunnel of a data radio bearer (DRB) for a remote UE (e.g., UE 104 or 204) and a Uu radio link control (RLC) channel for a relay UE (e.g., UE 104 or 204). In addition, the mapping information may include an association between a signaling radio bearer (SRB) for the remote UE and a Uu radio link control (RLC) channel for the relay UE. A remote UE (or remote wireless communication device) may be connected to a base station via a relay UE (or relay wireless communication device) that is directly connected to the base station.

[0106] In some embodiments, the mapping information may include or identify an association between an F1-U tunnel of a DRB for the anchor UE (e.g., UE 104 or 204) and a Uu RLC channel for the aggregated UE. In some embodiments, the mapping information may include or identify an association between a signaling radio bearer (SRB) for the anchor wireless communication device and a Uu radio link control (RLC) channel for the aggregated wireless communication device. The aggregated UE (or aggregated wireless communication device) may be connected to a base station or to a base station through another UE (e.g., anchor UE or anchor wireless communication device).

[0107] Additionally, the multipath configuration information may include or identify various identifiers. In some embodiments, the multipath configuration information may include an identifier for a path (e.g., an indirect or direct path) to be configured (e.g., added, modified, or released). In some embodiments, the multipath configuration information may include a radio bearer (RB) identifier. The identifier may be for a data radio bearer (DRB) or a signaling radio bearer (SRB) for the path to be configured.

[0108] Subsequently, the multipath configuration information may include or identify identifiers for the UEs. In some embodiments, the multipath configuration information may include identifiers for relay UEs. A relay UE may be directly connected to a base station and may support indirect connections for remote UEs. In some embodiments, the multipath configuration information may include identifiers for aggregated UEs. An aggregated UE may include a set of UEs that are connected to each other and to a base station.

[0109] The multipath configuration information may include or identify various indicators associated with paths to be configured. In some embodiments, the multipath configuration information may include an indication of a path, such as a direct path or an indirect path. A direct path may be a direct link between the UE and the base station. In some embodiments, the multipath configuration information may include an indication of a path, such as a primary path or a secondary path. A primary path may correspond to a path over which packet transmission is preferred over a secondary path. In some embodiments, the multipath configuration information may include a path activation indication. The path activation indication may identify whether a path should be active or inactive to receive data packets.

[0110] In some embodiments, the multipath configuration information may include an indication of data splitting or duplication for one or more paths. Data splitting may specify separating packets traversing direct and indirect paths. Data duplication may specify copying of packets over and within the direct path. In some embodiments, the indication of data splitting may identify a data splitting threshold or a data splitting ratio. The data splitting threshold may define an amount of data over a path at which to initiate data splitting. The data splitting ratio may define a ratio of the amount of data communicated over the path. In some embodiments, the multipath configuration information may define, identify, or indicate a distribution of data packets over a direct path (e.g., corresponding to a first RLC channel) and an indirect path (e.g., corresponding to a second RLC channel) for data splitting.

[0111] The multipath configuration information may include or identify tunnel information. In some embodiments, the multipath configuration information may identify or include uplink (UL) user plane (UP) tunnel (TNL) information. In some embodiments, the UL UP TNL information may be for a direct path or an indirect path. The UL UP TNL information may be included for a particular DRB. In some embodiments, multiple sets of UL UP TNL information may be for a split DRB. In some embodiments, the multipath configuration information may include an identifier for a Uu Radio Link Control (RLC) channel to use. The UE's Uu RLC channel may be mapped to the DRB's F1-U tunnel. In some embodiments, the multipath configuration information may identify a DRB (e.g., using a DRB ID) for a set of F1-U tunnels between the CU and DU.

[0112] The DU may retrieve, identify, or otherwise receive multipath configuration information from the CU (1210). In response to receiving, the DU may parse the multipath configuration information and extract or identify various information, such as mapping information. The DU may use the multipath configuration to configure a direct path or a path not associated with the mapping information (e.g., using a DRB or SRB). The direct path or the not associated path may correspond to an RLC channel. In some embodiments, the DU may use the multipath configuration information to configure an RLC channel for a relay UE or anchor UE for a direct path for a DRB or SRB.

[0113] On the other hand, the DU may use the multipath configuration and refrain from setting up an additional RLC channel for RBs such as DRBs or SRBs. The additional RLC channel may be for an indirect path. In some embodiments, the DU may use the mapping information and refrain from setting up an RLC channel for the relay UE or anchor UE for the DRB. In some embodiments, the DU may use the indirect path indication and refrain from setting up an RLC channel for the relay UE or anchor UE for the DRB or SRB.

[0114] The DU may provide, transmit, or otherwise send the multipath configuration response information to the CU (1215). When using the multipath configuration information, the DU may generate the multipath configuration response information. The CU may retrieve, identify, or otherwise receive the multipath configuration response information from the DU (1220). In some embodiments, the multipath configuration response information may identify or include downlink (DL) user plane (UP) tunnel (TNL) information regarding the path to be configured. The path may correspond to what is accepted at the DU.

[0115] In some embodiments, the multipath configuration response information may identify or include an identifier for a path. The path may correspond to one configured using the multi-configuration information. In some embodiments, the multipath configuration response information may identify or include an indication of a direct path or an indirect path. The indirect or direct path may correspond to one configured using the multi-configuration information. In some embodiments, the multipath configuration response information may identify or include an indication of an accepted or rejected primary path or secondary path.

[0116] In some embodiments, the multipath configuration response information may identify or indicate the acceptance or failure of a path. The indication and related information may be generated and provided by the DU. In some embodiments, the multipath configuration response information may include or identify a cause of the path failure. The cause may include, for example, among other things, an identifier for a non-acceptance or non-acceptance of data packet delivery via the path. In some embodiments, the multipath configuration response information may identify or indicate a failure of a multipath SRB or DRB setup. In some embodiments, the multipath configuration response information may identify or indicate a failure of a multipath SRB or DRB modification.

[0117] While various embodiments of the present solution have been described above, it should be understood that they are presented by way of example only, and not by way of limitation. Similarly, various diagrams may depict example architectures or configurations, which are provided to enable those skilled in the art to understand example features and functionality of the present solution. However, such skilled artisans 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. Additionally, as will be understood by those skilled in the art, one or more features of one embodiment can be combined with one or more features of another embodiment described herein. Thus, the scope and scope of the present disclosure should not be limited by any of the example embodiments described above.

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

[0119] Additionally, those skilled 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.

[0120] Those skilled in the art will further understand that any of the various illustrative logic blocks, modules, processors, means, circuits, methods, and functions described in connection with the aspects disclosed herein may be implemented by electronic hardware (e.g., digital implementations, analog implementations, or a combination of the two), firmware, various forms of programs or design code incorporating instructions (which may be referred to herein for convenience as “software” or “software modules”), or any combination of these techniques. To clearly illustrate this interchangeability of hardware, firmware, and software, the various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware, firmware, or software, or a combination of these techniques, depends on the particular application and design constraints imposed on the overall system. Those skilled in the art may implement the described functionality in various ways for each particular application, but such implementation decisions do not cause a departure from the scope of the present disclosure.

[0121] Furthermore, those skilled in the art will understand that the various illustrative logic blocks, modules, devices, components, and circuits described herein may be implemented in or by integrated circuits (ICs), which may include general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, 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 device. A general-purpose processor may be a microprocessor, but alternatively, the processor may be any conventional processor, controller, or state machine. A processor may also be implemented as a combination of computing devices, e.g., a DSP and a microprocessor, multiple microprocessors, one or more microprocessors in conjunction with a DSP core, or any other suitable configuration for performing the functions described herein.

[0122] If implemented in software, the functions can be stored as one or more instructions or code on a computer-readable medium. Thus, the steps of a method or algorithm disclosed herein can be implemented as software stored on a computer-readable medium. Computer-readable media includes both computer storage media and communication media, including any medium that can enable a computer program or code to be transferred from one place to another. A storage medium can be any available medium that can be accessed by a computer. By way of example, and not limitation, such computer-readable media can include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer.

[0123] As used herein, the term "module" refers to software, firmware, hardware, and any combination of these elements for performing the associated functions described herein. Additionally, for purposes of discussion, various modules are described as discrete modules; however, as would be apparent to one skilled in the art, two or more modules may be combined to form a single module that performs the associated functions according to embodiments of the present solution.

[0124] Additionally, memory or other storage and communication components may be employed in embodiments of the solution. It should be understood that, for purposes of clarity, the above description describes embodiments of the solution with reference to different functional units and processors. However, it will be apparent that any suitable distribution of functionality between different functional units, processing logic elements, or domains may be used without departing from the solution. For example, functionality illustrated as being performed by separate processing logic elements or controllers may be performed by the same processing logic element or controller. References to specific functional units therefore do not indicate a strict logical or physical structure or organization, but merely to suitable means for providing the described functionality.

[0125] Various modifications of the embodiments described in this disclosure will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the scope of the present disclosure. Thus, the present disclosure is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the novel features and principles disclosed herein, as recited in the following claims.

Claims

1. 1. A method of multipath communication, comprising: Sending multipath configuration information by a centralization unit (CU) to a distribution unit (DU); receiving, by the CU, multipath configuration response information from the DU; A method comprising:

2. The method of claim 1 , wherein the multipath configuration information comprises path indication information that identifies at least one of a direct path or an indirect path.

3. The multipath configuration information is An association between an F1-U tunnel of a data radio bearer (DRB) for a remote wireless communication device and a Uu radio link control (RLC) channel for a relay wireless communication device; or Association between an F1-U tunnel of a data radio bearer (DRB) for an anchor wireless communication device and a Uu radio link control (RLC) channel for an aggregated wireless communication device The method of claim 1 , further comprising: mapping information identifying:

4. The multipath configuration information is an association between a signaling radio bearer (SRB) for the remote wireless communication device and a Uu radio link control (RLC) channel for the relay wireless communication device; or Association between a signaling radio bearer (SRB) for an anchor wireless communication device and a Uu radio link control (RLC) channel for an aggregated wireless communication device The method of claim 1 , further comprising: mapping information identifying:

5. 2. The method of claim 1, wherein the multipath configuration information comprises at least one of a radio bearer (RB) identifier, an uplink (UL) user plane (UP) tunnel (TNL) information, an identifier for a relay wireless communication device, an identifier for an aggregated wireless communication device, an identifier for a Uu radio link control (RLC) channel, an identifier for a path, an indication of a direct or indirect path, an indication of a primary or secondary path, an indication of data splitting or data duplication, or a path activation indication.

6. The method of claim 5 , wherein the RB identifier may be at least one of a DRB or an SRB identifier.

7. The method according to claims 3-5, wherein the multipath configuration information together with the mapping information is used by the DU to refrain from setting up an RLC channel of a relay wireless communication device or an anchor wireless communication device for the DRB.

8. The method according to claims 3-5, wherein the multipath configuration information with an indirect path indication is used by the DU to refrain from setting up an RLC channel of a relay wireless communication device or an anchor wireless communication device for the DRB or SRB.

9. The method of claim 1 , wherein the multipath configuration information is used by the DU to configure a first RLC channel of a relay wireless communication device or an anchor wireless communication device for a direct path of a DRB or SRB.

10. The method of claim 1 , wherein the multipath configuration information comprises a path activation indication that identifies a path as active or inactive.

11. The method of claim 5 , wherein the indication of data splitting comprises at least one of a data splitting threshold or a data splitting ratio.

12. 2. The method of claim 1, wherein the multipath configuration information with data split indicates distribution of a plurality of data packets across a first RLC channel corresponding to a direct path and a second RLC channel corresponding to an indirect path.

13. The method of claim 1 , wherein the multipath configuration information identifies a DRB for multiple F1 user plane tunnels between the CU and DU.

14. The method of claim 1 , wherein the multipath configuration information comprises uplink (UL) user plane (UP) tunnel (TNL) information for at least one of a direct path or an indirect path.

15. The method of claim 1 , wherein the multipath configuration information comprises two or more UL UP TNL information for a split DRB.

16. The method of claim 1 , wherein the multipath configuration response information indicates at least one of an acceptance or failure of a path.

17. 17. The method of claim 16, wherein the multipath configuration response information includes an identifier for a path, or an indication of a direct or indirect path, or an indication of an accepted or rejected primary or secondary path.

18. 17. The method of claim 16, wherein the multipath configuration response information identifies one of a cause of failure of the path or an identifier for the path that is unacceptable or unacceptable for data packet delivery.

19. The method of claim 16 , wherein the multipath configuration response information indicates a multipath SRB or DRB setup failure or a multipath SRB or DRB modification failure.

20. 17. The method of claim 16, wherein the multipath configuration response information includes downlink (DL) user plane (UP) tunnel (TNL) information for the accepted path.

21. The method of claim 1 , wherein the multipath configuration information comprises at least one of a multipath setup request, a multipath modification request, or a multipath release request.

Images