Multi-path relay and service continuity enhancements

Abstract

Embodiments attempt to address challenges in a wireless communication system (e.g., a cellular system). Embodiments describe various techniques, systems, and devices that support multi-path relay operation of user equipments (UEs) (e.g., remote UEs and relay UEs) and base stations (e.g., g Node B (gNB)) in 3rd Generation Partnership Project (3G PP) 5th Generation (5G) new air interface (NR) or 6th Generation (6G) systems and other wireless communication systems. Other embodiments are described and claimed.

Description

[0001] This application claims the benefit of and priority to previously filed U.S. Provisional Patent Application Serial No. 63 / 485,502, filed on February 16, 2023, entitled “MULTI-PATH RELAYING WITH IDEAL UE-UE LINK AND SERVICE CONTINUITY ENHANCEMENTS,” the entire contents of which are incorporated herein by reference. Background Art

[0002] The use of wireless communication systems is rapidly increasing. Furthermore, wireless communication technology has evolved from solely voice communication to also include the transmission of data, such as the internet and multimedia content, to a variety of devices. To accommodate the increasing number of devices communicating, many wireless communication systems share available communication channel resources between devices. Furthermore, the use of Internet of Things (IoT) devices is also growing, and they can coexist with user devices in various wireless communication systems, such as cellular networks. BRIEF DESCRIPTION OF THE DRAWINGS

[0003] To easily identify the discussion of any particular element or act, one or more digits in a reference number refer to the figure number in which the element is first introduced.

[0004] Figure 1 A wireless communication system according to one embodiment is shown.

[0005] Figure 2 A wireless communication system according to one embodiment is shown.

[0006] Figure 3A A user plane protocol stack according to one embodiment is shown.

[0007] Figure 3B A control plane protocol stack according to one embodiment is shown.

[0008] Figure 4 An operating environment according to one embodiment is shown.

[0009] Figure 5 A message flow according to one embodiment is shown.

[0010] Figure 6 A wireless communication system according to one embodiment is shown.

[0011] Figure 7 An operating environment according to one embodiment is shown.

[0012] Figure 8A A data pattern of UE capability information according to one embodiment is shown.

[0013] Figure 8B FIG. 4 shows a data pattern of UE configuration information according to an embodiment.

[0014] Figure 9A An apparatus for a remote UE according to one embodiment is shown.

[0015] Figure 9B An apparatus for relaying a UE according to one embodiment is shown.

[0016] Figure 10 An apparatus for a base station according to one embodiment is shown.

[0017] Figure 11 A logic flow according to one embodiment is shown.

[0018] Figure 12 A logic flow according to one embodiment is shown.

[0019] Figure 13 A logic flow according to one embodiment is shown.

[0020] Figure 14 A first network according to one embodiment is shown.

[0021] Figure 15 A second network according to one embodiment is shown.

[0022] Figure 16 A third network according to one embodiment is shown.

[0023] Figure 17 A computer-readable storage medium according to one embodiment is shown. DETAILED DESCRIPTION

[0024] The present disclosure provides a technology for implementing multipath relay between network devices in a wireless network. Generally, multipath relay refers to a technology for transmitting information between network devices using multiple communication paths. Each communication path carries the same information to achieve redundancy. The number of communication paths can vary according to a given system design and a set of design constraints. Based on the availability of network resources, the communication paths can utilize different technologies, protocols, radio, radio frequency (RF) spectrum, etc. In some cases, the communication paths can pass through different communication links and / or network devices. This promotes the efficient use of scarce network resources while increasing resilience and robustness to ensure that network devices maintain seamless and continuous communication. In the event of interference or failure in the first communication path, the network device can continue to communicate using the second communication path, and vice versa. In this way, the use of multipath relay enhances the communication reliability, performance, and service continuity between network devices.

[0025] In various embodiments, a communication path refers to a sequence of communication links in a communication system. This communication path represents the physical or logical connection between a transmitter of a source device and a receiver of a destination device. A communication link is a physical or logical connection between a pair of network devices. A source device refers to a network device that encodes or transmits information. A destination device refers to a network device that decodes or receives information. A single network device can operate as either a source device or a destination device, depending on the network device's operating mode at any given moment.

[0026] In various embodiments, a communication path may include a direct path or an indirect path. A direct path utilizes a single communication link between a pair of network devices. For example, the pair of network devices may include a source device and a destination device. An indirect path utilizes multiple communication links between a pair of network devices. Furthermore, an indirect path traverses one or more intermediate devices. An intermediate device is any network device configured to relay information between a source device and a destination device.

[0027] In the context of a 3rd Generation Partnership Project (3GPP) wireless system, examples of network devices may include user equipment (UE), base stations, access points, servers of a core network, and the like. Examples of base stations may include eNodeBs (eNBs), gNodeBs (gNBs), and the like. With respect to multipath relaying, a UE and a base station may establish multiple communication paths between each other to achieve redundancy, reliability, or survivability. For example, multipath relaying may include a first communication path and a second communication path between the UE and the base station. The first communication path may include a direct path. The direct path utilizes a single communication link between the UE and the base station. The second communication path may include an indirect path. The indirect path utilizes multiple communication links and at least one intermediate node between the UE and the base station.

[0028] In one scenario, for example, a first UE and a base station may use a direct path having a single communication link between the first UE and the base station. The first UE and the base station may also use an indirect path having multiple communication links between the first UE and the base station. The multiple communication links may include, for example, a first communication link and a second communication link. The first communication link is between the first UE and an intermediate device. The second communication link is between the intermediate device and the base station. For example, the intermediate device may include a second UE different from the first UE. The first UE and the second UE may establish a device-to-device (D2D) or peer-to-peer (P2P) connection between each other over a shorter distance.

[0029] In a given operational scenario, a first UE or a base station may operate as a source device or a destination device, depending on which device is sending a set of information and which device is receiving the set of information. For example, a source device such as a first UE may communicate information with a destination device such as a base station. The first UE may send a set of information via a direct path. The first UE may also send a copy of the set of information via an indirect path via a second UE. The base station may receive the information and / or copy the information.

[0030] When both the direct path and the indirect path are active, the base station can receive both information and duplicate information, respectively. In this case, the base station uses de-duplication techniques to discard duplicate information and form a single, unified set of information. The base station also uses sorting techniques to ensure that information is received in the correct sequential order, for example, a stream of data packets sent in sequential order. When either the direct path or the indirect path is inactive, the base station receives information or duplicate information. In this case, the base station can also use sorting techniques to locate the received information in the correct sequential order. This same process typically occurs when the source device is a base station transmitting information to a first UE, which is the destination device.

[0031] In some cases, some of the network devices along the direct path and the indirect path may utilize different technologies, protocols, radios, radio frequency (RF) spectrum, etc. For example, the source device and the destination device may establish a first communication path using a first set of wireless communication protocols and a second communication path using a second set of wireless communication protocols. The first set of wireless communication protocols may include a wireless protocol stack that is different from the wireless protocol stack of the second set of wireless communication protocols. For example, the first set of wireless communication protocols may be implemented as a long-range wireless protocol, and the second set of wireless communication protocols may be implemented as a short-range wireless protocol. An example of the first set of communication protocols may include one or more cellular protocols, such as 3GPP protocols. An example of the second set of communication protocols may include one or more non-cellular protocols or non-3GPP protocols, such as WiFi, Bluetooth, Zigbee, etc. The embodiments are not limited to these examples.

[0032] Some examples of long-range wireless protocols may include several cellular protocols that have been developed and evolved over the years, such as: (1) second generation (2G) cellular protocols, such as Global System for Mobile Communications (GSM) and Code Division Multiple Access (CDMA), which are protocols that are primarily focused on voice services and provide limited data capabilities; (2) third generation (3G) cellular protocols, such as Universal Mobile Telecommunications System (UMTS) and CDMA2000, which introduced high-speed data services in addition to voice and provided a significant improvement in data rates over 2G networks; (3) fourth generation (4G) cellular protocols, such as Long Term Evolution (LTE), which provide significant enhancements in data speed, capacity, and overall network performance, providing faster data rates, lower latency, and improved system efficiency compared to previous generations; and (4) fifth generation (5G) cellular protocols, such as 5G New Radio (5GNR). (5) sixth generation (6G) cellular protocols, which deliver significantly faster data rates than 5G, potentially reaching speeds of terabits per second (Tbps). The embodiments are not limited to these examples.

[0033] Some examples of short-range wireless protocols may include several non-cellular protocols, such as: (1) the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard (e.g., WiFi) for local area network (LAN) connections; (2) the IEEE 802.15.1 standard (e.g., Bluetooth), which is designed for personal area networks (PANs) to connect devices such as smartphones, laptops, headsets, and IoT devices; (3) the IEEE 802.15.4 standard (e.g., Zigbee), which is a low-power, low-data-rate wireless protocol for wireless sensor networks (WSNs) and IoT applications; (4) Z-Wave, which is a wireless protocol primarily used for smart home automation, enabling devices such as smart locks, lighting systems, and thermostats to communicate with a centralized controller; (5) Near Field Communication (NFC), which is a short-range wireless technology for contactless communication between devices over short distances (typically a few centimeters) and is commonly used for mobile payments, ticketing, information exchange, and other applications requiring close-range communication; (6) Radio Frequency Identification (RFID), which uses radio waves to identify and track objects or individuals for applications such as inventory management, access control, electronic toll collection, and asset tracking; (7) Long Range Wide Area Network (WAN) (LoRaWAN) in IoT applications, which enables long-range communication with low power consumption, making it suitable for applications such as smart cities, agriculture, and utility metering; and (8) Infrared (IR) communication, which uses infrared light to wirelessly transmit data and is commonly used for remote control and short-range communication between devices such as TVs, audio systems, and other consumer electronics. The embodiments are not limited to these examples.

[0034] Regarding the multipath relay aspect of the present disclosure, Layer 2 (L2) UE-to-Network (U2N) relay is defined in 3GPP Release 17 (Rel-17) to support network coverage extension for remote UEs. Support for multipath, where a UE has one direct path to a gNB and one indirect path to another UE, is being studied and specified in 3GPP Release 18 (Rel-18). While the case where the indirect path is via an L2U2N relay UE is well studied, the case where the indirect path is via a peer-to-peer link (e.g., wired, WiFi, etc.) has not yet been fully studied and developed. As used herein, the term "peer-to-peer link" refers to a communication link between a pair of network devices that operates at a theoretical maximum in terms of efficiency or throughput, such as a peer-to-peer (P2P) or device-to-device (D2D) communication link between a pair of UEs.

[0035] This disclosure provides techniques and technologies for implementing multipath via indirect paths over peer-to-peer links (e.g., wired, WiFi, etc.), including both transmit and receive operations. This includes when the indirect path is via an L2 U2N relay UE, as defined by one or more 3GPP standards. This disclosure also provides support for lossless delivery for inter-gNB path switching scenarios.

[0036] This disclosure discusses the following enhancements for 3GPP multipath relaying, including: (1) reliability and throughput enhancements for remote UEs when within the coverage area of ​​a network node (e.g., a gNB); (2) multipath enhancements (e.g., when a UE uses a direct path and an indirect path to connect to the same gNB); (3) enhancements to support lossless delivery and service continuity for inter-gNB path switching scenarios using L2 U2N relaying UEs; and (4) enhancements to fault notification for U2U relaying to support service continuity. Other enhancements for 3GPP are described and claimed.

[0037] In these and other ways, multiple paths for transmitting data packets will enable remote UEs to improve their performance. The advanced relay solutions discussed herein can provide efficiencies in resource usage and / or consumption and improved user experience for sidelink technologies used in IoT and / or vehicle-to-everything (V2X) networks, as well as other types of networks.

[0038] The following description and accompanying drawings illustrate specific aspects that enable those skilled in the art to practice. Other aspects may incorporate structural, logical, electrical, process, and other changes. Portions and features of some aspects may be included in or replace portions and features of other aspects, and are intended to cover available equivalents of the described elements.

[0039] The word “exemplary” is used herein to mean “serving as an example, instance, or illustration.” Any aspect or design described herein as “exemplary” is not to be construed as preferred or advantageous over other aspects or designs.

[0040] The words "plurality" and "multiple" in the specification or claims explicitly refer to a number greater than one. The terms "group," "set," "collection," "series," "sequence," "grouping," etc. in the specification or claims refer to a number equal to or greater than one, i.e., one or more. Any term expressed in plural form without explicitly stating "plurality" and "multiple" also refers to a number equal to or greater than one. The terms "proper subset," "reduced subset," and "smaller subset" refer to a subset of a set that is not equal to the set, i.e., a subset of a set that contains fewer elements than the set.

[0041] It should be understood that any vector or matrix symbol used herein is essentially an example, and is only used for the purpose of explanation. Therefore, it should be understood that the method described in detail in this disclosure is not limited to being realized using only vectors or matrices, and can be about the set, sequence, group, etc. of data, observation, information, signal, sample, symbol, element, etc., equivalently perform associated processes and calculations. In addition, it should be understood that reference to "vector" can refer to vectors of any size or orientation, such as including 1x1 vectors (e.g., scalars), 1xM vectors (e.g., row vectors), and Mx1 vectors (e.g., column vectors). Similarly, it should be understood that reference to "matrix" can refer to matrices of any size or orientation, such as including 1x1 matrices (e.g., scalars), 1xM matrices (e.g., row vectors), and Mx1 matrices (e.g., column vectors).

[0042] As used herein, the term "software" includes any type of executable instructions or instruction sets, including embedded data in software. Software may also include firmware. Software may be created, deleted, or modified, for example, through a machine learning process.

[0043] As used herein, "module" is understood to include any type of functional implementation entity, which may include hardware-defined modules (e.g., dedicated hardware), software-defined modules (e.g., processors that execute software or firmware), and hybrid modules including both hardware-defined components and software-defined components. Therefore, a module can be an analog circuit or component, a digital circuit, a mixed-signal circuit or component, a logic circuit, a processor, a microprocessor, a central processing unit (CPU), an application processor, a graphics processing unit (GPU), a digital signal processor (DSP), a field programmable gate array (FPGA), an integrated circuit, a discrete circuit, an application-specific integrated circuit (ASIC), etc., or any combination thereof. Any other type of implementation of the corresponding function, which will be further described in detail below, may also be understood as a "module". It should be understood that any two (or more) modules of the modules detailed herein can be implemented as a single module with substantially equivalent functions, and conversely, any single module detailed herein can be implemented as two (or more) separate modules with substantially equivalent functions. Additionally, a reference to a "module" may refer to two or more modules that together form a single module.

[0044] The term "terminal device" as used herein includes user-side devices (both mobile and fixed) that can be connected to the core network and various external networks via a radio access network. The term "network access node" as used herein includes network-side devices that provide a radio access network, through which terminal devices can connect to other networks and exchange information.

[0045] The term "base station" used with respect to an access node of a mobile communication network may be understood to include macro base stations (e.g., for cellular communications), micro / pico / femto base stations, node Bs, evolved node Bs (base stations), home base stations, remote radio heads (RRHs), relay points, access points (APs, e.g., for Wi-Fi, WLAN, WiGig millimeter wave (mmWave), etc.), etc. As used herein, a "cell" in a telecommunications setting may be understood to include an area (e.g., a public place) or space (e.g., a multi-story building or airspace) served by a base station or access point. A base station may include a mobile device (e.g., installed in a vehicle), and the coverage area or space may be moved accordingly. Thus, a cell may be covered by a set of co-located transmit and receive antennas that are also capable of covering and serving specific sectors of the cell. A base station or access point may serve one or more cells, where the cells are characterized by different communication channels or standards (e.g., a base station providing 2G, 3G, and LTE services). Macrocells, microcells, femtocells, and picocells can have different cell sizes and ranges and can be static or dynamic (for example, a cell installed in a drone or balloon), or dynamically change its characteristics (for example, from macrocell to picocell, from static deployment to dynamic deployment, from omnidirectional to directional, from broadcast to narrowcast). The communication channel can include narrowband or broadband. The communication channel can also use carrier aggregation across radio communication technologies and standards, or flexibly adapt the bandwidth to communication needs. In addition, the terminal device can include or serve as a base station or access point or repeater or other network access node.

[0046] As used herein, the term "network," for example, with respect to a communication network (e.g., a mobile communication network), encompasses both the access portion of the network (e.g., the radio access network (RAN) portion) and the core portion of the network (e.g., the core network portion), but for an end-to-end system, the term "network" also encompasses mobility (including peer-to-peer, device-to-device, or machine-to-machine communication), access, backhaul, servers, backbones, and gateway / switching elements to other networks of the same or different types. The terms "radio idle mode" or "radio idle state" as used herein with respect to a mobile terminal refer to a radio control state in which the mobile terminal is not assigned a dedicated communication channel of the mobile communication network. The terms "radio connected mode" or "radio connected state" as used with respect to a mobile terminal refer to a radio control state in which the mobile terminal is assigned a dedicated uplink communication channel of the mobile communication network. The uplink communication channel may be a physical channel or a virtual channel. The idle or connected mode may be connection-switched or packet-switched.

[0047] Unless explicitly specified, the term "send" encompasses both direct (point-to-point) transmission and indirect transmission (via one or more intermediate points or nodes). Similarly, the term "receive" includes both direct and indirect reception. In addition, the terms "send," "receive," "communicate," and other similar terms encompass both physical transmission (e.g., transmission of radio signals) and logical transmission (e.g., transmission of logical data connected via a software level). For example, a processor can send or receive data with another processor in the form of radio signals, where the physical transmission and reception are handled by radio layer components such as RF transceivers and antennas, and the logical transmission and reception are performed by the processor. The term "communicate" encompasses one or both of sending and receiving, i.e., unidirectional or bidirectional communication in one or both of the incoming and outgoing directions. The term "compute" encompasses both "direct" computation via mathematical expressions / formulas / relations and "indirect" computation via lookups or hash tables and other array indexing or search operations.

[0048] Some of the features in this document are defined for the network side, such as access points, eNodeBs, New Radio (NR), or next-generation NodeBs (gNodeBs or gNBs—note that this term is typically used in the context of 3GPP fifth-generation (5G) communication systems). However, user equipment (UE) can also play this role and function as an access point, eNodeB, gNodeB, etc. That is, some features defined for network devices can be implemented by UEs.

[0049] As used herein, the term "circuitry" may refer to, be part of, or include a circuit, an integrated circuit (IC), a monolithic IC, a discrete circuit, a hybrid integrated circuit (HIC), an application specific integrated circuit (ASIC), an electronic circuit, a logic circuit, a microcircuit, a hybrid circuit, a microchip, a chip, a chiplet, a chipset, a multi-chip module (MCM), a semiconductor die, a system on a chip (SoC), a processor (shared, dedicated, or group), a processor circuit, a processing circuit, or associated memory (shared, dedicated, or group) operably coupled to the circuitry that executes one or more software or firmware programs, a combinational logic circuit, or other suitable hardware component that provides the described functionality. In some embodiments, the circuitry may be implemented in one or more software or firmware modules, or the functionality associated with the circuitry may be implemented by one or more software or firmware modules. In some embodiments, the circuitry may include logic that may be partially operational in hardware.

[0050] Figure 1An example wireless communication system 100 is shown. For convenience and not limitation, the example wireless communication system 100 is described in the context of Long Term Evolution (LTE) and fifth generation (5G) New Radio (NR) (5G NR) or sixth generation (6G) cellular network communication standards, such as 3GPP Technical Specification (TS) 38.300, entitled "Technical Specification Group Radio Access Network; NR; NR and NG-RAN Overall Description; Stage 2," Releases 17 and 18, January 12, 2024 (3GPP TS 38.300 standard); 3GPP TS 38.331, entitled "Technical Specification Group Radio Access Network; NR; Radio Resource Control (RRC) protocol specification," Releases 17 and 18, January 15, 2024 (3GPP TS 38.331 standard), or other 3GPP standards or specifications. However, other types of wireless standards are also possible.

[0051] Regarding the 3GPP TS 38.300 standard, the 3GPP Technical Specification Group (TSG) Radio Access Network (RAN) (TSG-RAN) Working Group 2 (WG2) (RAN2) has proposed Change Request (CR) 0771, Revision 3, titled "Introduction of NR sidelink relay enhancements," numbered R2-2314074, for 3GPP TS 38.300 Version 17.6.0, November 2023 (CR 0771). CR 0771 introduces NR sidelink relay enhancements, including sidelink UE-to-UE (U2U) relay, UE-to-network (U2N) service continuity enhancements, and multipath relay. CR 0771 also introduces support for Layer 2 (L2) U2U relay functionality, including Layer 2 (L2) U2U relay discovery and selection or reselection. CR 0771 also introduces control plane procedures for supporting U2U relay operations. Direct-to-indirect inter-gNB path handover, direct-to-indirect inter-gNB path handover, and indirect-to-indirect inter-gNB / intra-gNB path handover are introduced to support enhanced service continuity. CR (i.e., R3-238113) approved by 3GPP TSG-RAN Working Group 3 (WG3) (RAN3) is adapted to support inter-gNB path handover. Support for multipath relay functionality with sidelink indirect or non-3GPP indirect paths is introduced. NR sidelink relay enhancements for sidelink UE-to-UE relay, service continuity, and multipath operation are not supported in NR.

[0052] To implement multipath relay, as defined by various 3GPP standards, network devices such as UEs may implement various types of functionality to support multipath relay operations. In various embodiments, the UE may be configured with functionality to operate as a UE-to-network (U2N) relay UE, a U2N remote UE, a UE-to-UE (U2U) relay UE, a U2U remote UE, a multipath (MP) relay UE, an MP remote UE, or the like. A U2N relay UE is a UE that provides functionality to support connection to a network for (one or more) U2N remote UEs. A U2N remote UE is a UE that communicates with a network via a U2N relay UE. A U2U relay UE is a UE that provides functionality to support connection between two U2U remote UEs. A U2U remote UE is a UE that communicates with other (one or more) UEs via a U2U relay UE. An MP relay UE is a UE that provides functionality to support connection to a network for (one or more) MP remote UEs. An MP remote UE is a UE that communicates with a network via a direct Uu link and an MP relay UE. Embodiments that use the more general terms "remote UE" and "relay UE" may apply to all types of UEs to support MP operation. Similarly, embodiments that use specific terms such as "U2N" or "U2U" or "MP" as prefixes to UEs may apply to all types of UEs to support MP operation. In some cases, embodiments may use prefixes such as Layer 2 (L2) or Layer 3 (L3) that refer to corresponding layers in a network protocol stack (e.g., a 3GPP protocol stack or a non-3GPP protocol stack). Embodiments are not limited to these examples of network devices that support MP operation.

[0053] Figure 1 A representative cellular system implementing one or more 3GPP standards is shown. Figure 1As depicted, the wireless communication system 100 supports two classes of UE devices, including a reduced capability (RedCap) UE 102a and a standard UE 102b (collectively referred to as "UE 102"). In one embodiment, the UE 102a may have a set of one or more reduced capabilities relative to a set of standard capabilities of the standard UE 102b. Examples of reduced capabilities may include, but are not limited to: (1) 20 megahertz (MHz) in the sub-7 gigahertz (GHz) band or 100 MHz in the millimeter wave (mmWave) band; (2) a single transmit (Tx) antenna (1Tx); (3) a single receive (Rx) antenna (1Rx), with 2 antennas (2Rx) being optional; (4) optional support for half-duplex FDD; (5) low-order modulation, with 256 quadrature amplitude modulation (QAM) being optional; and (6) support for lower transmit power. In one embodiment, for example, the standard UE 102b may have 2Rx antennas, while the UE 102a may have only 1Rx antenna. The UE 102a may also have other simplified capabilities.The embodiments are not limited in this context.

[0054] In this example, the UE 102 is shown as a smartphone (e.g., a handheld touchscreen mobile computing device that can connect to one or more cellular networks). In other examples, any of the UEs 102 may include other mobile or non-mobile computing devices, such as consumer electronic devices, cellular phones, smartphones, feature phones, tablet computers, wearable computer devices, personal digital assistants (PDAs), pagers, wireless handsets, desktop computers, laptop computers, in-vehicle infotainment systems (IVIs), in-car entertainment (ICE) devices, instrument clusters (ICs), heads-up display (HUD) devices, on-board diagnostic (OBD) devices, dashboard mobile equipment (DME), mobile data terminals (MDTs), electronic engine management systems (EEMS), electronic / engine control units (ECUs), electronic / engine control modules (ECMs), embedded systems, microcontrollers, control modules, engine management systems (EMSs), networked or “smart” appliances, machine type communication (MTC) devices, machine-to-machine (M2M) devices, Internet of Things (IoT) devices, or combinations thereof, and the like.

[0055] In some implementations, any of the UEs 102 may be an IoT UE, which may include a network access layer designed for low-power IoT applications that utilize short-term UE connections. The IoT UE may utilize technologies such as M2M or MTC to exchange data with an MTC server or device using, for example, a public land mobile network (PLMN), proximity services (ProSe), device-to-device (D2D) communication, a sensor network, an IoT network, or a combination thereof, among others. The M2M or MTC data exchange may be a machine-initiated data exchange. The IoT network describes interconnected IoT UEs, which may include uniquely identifiable embedded computing devices (within the Internet infrastructure) with short-term connections. The IoT UE may execute background applications (e.g., keep alive messages or status updates) to facilitate connectivity to the IoT network.

[0056] The UE 102 is configured to be connected (e.g., communicatively coupled) to a radio access network (RAN) 112. In some implementations, the RAN 112 may be a next-generation RAN (NG RAN), an evolved UMTS terrestrial radio access network (E-UTRAN), or a legacy RAN (e.g., a UMTS terrestrial radio access network (UTRAN) or a GSM EDGE radio access network (GERAN)). As used herein, the term "NG RAN" may refer to the RAN 112 operating in a 5G NR wireless communication system 100, and the term "E-UTRAN" may refer to the RAN 112 operating in an LTE or 4G wireless communication system 100.

[0057] To connect to the RAN 112, the UE 102 utilizes connections (or channels) 118 and 120, respectively, each of which may include a physical communication interface or layer, as described below. In this example, the connections 118 and 120 are shown as air interfaces to achieve communication coupling and may be consistent with a cellular communication protocol (e.g., a Global System for Mobile Communications (GSM) protocol, a Code Division Multiple Access (CDMA) network protocol, a Push-to-Talk (PTT) protocol, a Cellular PTT (POC) protocol, a Universal Mobile Telecommunications System (UMTS) protocol, a 3GPP LTE protocol, a 5G NR protocol, or a combination thereof, among other communication protocols).

[0058] UE 102b is shown as being configured to access an access point (AP) 104 (also referred to as "WLAN node 104," "WLAN 104," "WLAN terminal 104," "WT 104," etc.) using a connection 122. Connection 122 may comprise a local wireless connection, such as one consistent with any IEEE 802.11 protocol, where AP 104 would comprise a Wireless Fidelity (Wi-Fi) router. In this example, AP 104 is shown as being connected to the Internet and not to the core network of the wireless system, as described in further detail below.

[0059] The RAN 112 may include one or more nodes that implement connections 118 and 120, such as RAN nodes 106a and 106b (collectively referred to as "RAN nodes 106" or "RAN nodes 106"). As used herein, the terms "access node," "access point," and the like may describe a device that provides radio baseband functionality for data or voice connections, or both, between a network and one or more users. These access nodes may be referred to as base stations (BSs), gNodeBs, gNBs, eNodeBs, eNBs, NodeBs, RAN nodes, roadside units (RSUs), transmit receive points (TRxPs or TRPs), and links, and may include ground stations (e.g., terrestrial access points) or satellite stations that provide coverage within a geographic area (e.g., a cell). As used herein, the term "NG RAN node" may refer to a RAN node 106 (e.g., a gNB) operating in a 5G NR wireless communication system 100, and the term "E-UTRAN node" may refer to a RAN node 106 (e.g., an eNB) operating in an LTE or 4G wireless communication system 100. In some implementations, the RAN node 106 may be implemented as one or more dedicated physical devices, such as a macrocell base station or a low power (LP) base station, which is used to provide a femtocell, picocell, or other similar cell with a smaller coverage area, smaller user capacity, or higher bandwidth than a macrocell.

[0060] In some implementations, some or all of the RAN nodes 106 may be implemented as one or more software entities running on a server computer as part of a virtual network, which may be referred to as a cloud RAN (CRAN) or virtual baseband unit pool (vBBUP). The CRAN or vBBUP may implement RAN functional splitting, such as packet data convergence protocol (PDCP) splitting, where the radio resource control (RRC) and PDCP layers are operated by the CRAN / vBBUP and other Layer 2 (e.g., data link layer) protocol entities are operated by individual RAN nodes 106; medium access control (MAC) / physical layer (PHY) splitting, where the RRC, PDCP, MAC, and radio link control (RLC) layers are operated by the CRAN / vBBUP and the PHY layer is operated by individual RAN nodes 106; or "lower PHY" splitting, where the RRC, PDCP, RLC, and MAC layers, as well as the upper portion of the PHY layer, are operated by the CRAN / vBBUP and the lower portion of the PHY layer is operated by individual RAN nodes 106. This virtualization framework allows freed-up processor cores of the RAN nodes 106 to execute, for example, other virtualized applications. In some implementations, individual RAN nodes 106 may represent nodes using individual F1 interfaces ( Figure 1 102. The gNB-DUs (not shown) may include individual gNB distributed units (DUs) connected to a gNB central unit (CU). In some implementations, the gNB-DUs may include one or more remote radio heads or RFEMs, and the gNB-CUs may be operated by a server (not shown) located in the RAN 112 or by a pool of servers in a manner similar to a CRAN / vBBUP. Additionally or alternatively, one or more of the RAN nodes 106 may be next-generation eNBs (ng-eNBs), including RAN nodes that provide E-UTRA user plane and control plane protocol terminations to the UE 102 and connect to a 5G core network (e.g., the core network 114) using a next-generation interface.

[0061] In a vehicle-to-everything (V2X) scenario, one or more of the RAN nodes 106 may be or function as an RSU. The term "roadside unit" or "RSU" refers to any transportation infrastructure entity used for V2X communications. An RSU may be implemented in or by a suitable RAN node or a fixed (or relatively fixed) UE, where an RSU implemented in or by a UE may be referred to as a "UE-type RSU," an RSU implemented in or by an eNB may be referred to as an "eNB-type RSU," an RSU implemented in or by a gNB may be referred to as a "gNB-type RSU," and so on. In one example, an RSU is a computing device coupled to a roadside RF circuitry that provides connectivity support to passing vehicle UEs 102 (vUEs 102). The RSU may also include internal data storage circuitry to store intersection map geometry, traffic statistics, media, and applications or other software for sensing and controlling ongoing vehicular and pedestrian traffic. The RSU can operate on the 5.9 GHz Direct Short Range Communication (DSRC) band to provide very low latency communications required for high-speed events (e.g., collision avoidance, traffic warnings, etc.). Additionally or alternatively, the RSU can operate on the cellular V2X band to provide the aforementioned low latency communications as well as other cellular communication services. Additionally or alternatively, the RSU can operate as a Wi-Fi hotspot (2.4 GHz band) or provide connectivity to one or more cellular networks to provide uplink and downlink communications or both. Some or all of the computing device(s) and the RSU's RF circuitry can be enclosed in a weatherproof enclosure suitable for outdoor installation and can include a network interface controller to provide a wired connection (e.g., Ethernet) to a traffic signal controller or a backhaul network or both.

[0062] Any of the RAN nodes 106 may terminate the air interface protocol and may be the first point of contact for the UE 102. In some implementations, any of the RAN nodes 106 may perform various logical functions of the RAN 112, including, but not limited to, radio network controller (RNC) functions, such as radio bearer management, uplink and downlink dynamic radio resource management and data packet scheduling, and mobility management.

[0063] In some implementations, the UEs 102 may be configured to communicate with each other or with any of the RAN nodes 106 over a multi-carrier communication channel using orthogonal frequency division multiplexing (OFDM) communication signals in accordance with various communication techniques, such as, but not limited to, OFDMA communication techniques (e.g., for downlink communications) or SC-FDMA communication techniques (e.g., for uplink communications), although the scope of the techniques described herein is not limited in this respect. An OFDM signal may include multiple orthogonal subcarriers.

[0064] The RAN node 106 can transmit to the UE 102 via various channels. Various examples of downlink communication channels include the Physical Broadcast Channel (PBCH), the Physical Downlink Control Channel (PDCCH), and the Physical Downlink Shared Channel (PDSCH). Other types of downlink channels are possible. The UE 102 can transmit to the RAN node 106 via various channels. Various examples of uplink communication channels include the Physical Uplink Shared Channel (PUSCH), the Physical Uplink Control Channel (PUCCH), and the Physical Random Access Channel (PRACH). Other types of uplink channels are possible.

[0065] In some implementations, a downlink resource grid can be used for downlink transmissions from any of the RAN nodes 106 to the UE 102, while uplink transmissions can utilize similar techniques. The grid can be a time-frequency grid (referred to as a resource grid or time-frequency resource grid), which represents the physical resources in the downlink during each time slot. This time-frequency plane representation is common in OFDM systems and makes radio resource allocation intuitive. Each column and row of the resource grid corresponds to an OFDM symbol and an OFDM subcarrier, respectively. The duration of the resource grid in the time domain corresponds to a time slot in a radio frame. The smallest time-frequency unit in the resource grid is represented as a resource element. Each resource grid includes multiple resource blocks, which describe the mapping of certain physical channels to resource elements. Each resource block includes a collection of resource elements; in the frequency domain, this can represent the minimum number of resources that can currently be allocated. There are several different physical downlink channels that are transmitted using such resource blocks.

[0066] The PDSCH carries user data and higher layer signaling destined for the UE 102. The PDCCH carries information regarding, among other things, the transport format and resource allocation associated with the PDSCH channel. It may also inform the UE 102 of the transport format, resource allocation, and hybrid automatic repeat request (HARQ) information associated with the uplink shared channel. Downlink scheduling (e.g., assigning control and shared channel resource blocks to UEs 102b within a cell) may be performed at any of the RAN nodes 106 based on channel quality information fed back from any of the UEs 102. Downlink resource assignment information may be sent on the PDCCH for (e.g., assigned to) any of the UEs 102.

[0067] PDCCH uses control channel elements (CCE) to transmit control information. Before being mapped to resource elements, the PDCCH complex symbols can first be organized into four tuples, which can then be permuted using a sub-block interleaver for rate matching. In some implementations, each PDCCH can be sent using one or more of these CCEs, where each CCE can correspond to nine groups of four physical resource elements (collectively referred to as resource element groups (REGs)). Four quadrature phase shift keying (QPSK) symbols can be mapped to each REG. Depending on the size of the downlink control information (DCI) and the channel conditions, one or more CCEs can be used to send the PDCCH. In LTE, there can be four or more different PDCCH formats defined with different numbers of CCEs (e.g., aggregation levels L=1, 2, 4, or 8).

[0068] Some implementations may use concepts for resource allocation of control channel information that are extensions of the above concepts. For example, some implementations may utilize an enhanced PDCCH (EPDCCH) that uses PDSCH resources for control information transmission. EPDCCH may be transmitted using one or more enhanced CCEs (ECCEs). Similar to the above, each ECCE may correspond to nine groups of four physical resource elements, collectively referred to as enhanced REGs (EREGs). ECCEs may have other numbers of EREGs.

[0069] The RAN nodes 106 are configured to communicate with each other using an interface 132. In an example, for example, where the wireless communication system 100 is an LTE system (e.g., when the core network 114 is an evolved packet core (EPC) network), the interface 132 may be an X2 interface 132. The X2 interface may be defined as between two or more RAN nodes 106 (e.g., two or more eNBs, etc.) connected to the EPC 114, or between two eNBs connected to the EPC 114, or both. In some implementations, the X2 interface may include an X2 user plane interface (X2-U) and an X2 control plane interface (X2-C). The X2-U may provide a flow control mechanism for user data packets transmitted over the X2 interface and may be used to transmit information regarding the delivery of user data between eNBs. For example, X2-U may provide specific sequence number information for user data transmitted from the primary eNB to the secondary eNB; information about successfully in-sequence delivery of PDCP protocol data units (PDUs) for user data from the secondary eNB to the UE 102; information about PDCP PDUs that were not delivered to the UE 102; information about the current minimum expected buffer size at the secondary eNB for sending user data to the UE, and other information. X2-C may provide intra-LTE access mobility functions, including context transfer or user plane transmission control from a source eNB to a target eNB; load management functions; inter-cell interference coordination functions, and other functions.

[0070] In some implementations, for example, when the wireless communication system 100 is a 5G NR system (e.g., when the core network 114 is a 5G core network), the interface 132 may be an Xn interface 132. The Xn interface may be defined as being between two or more RAN nodes 106 (e.g., two or more gNBs, etc.) connected to the 5G core network 114, between a RAN node 106 (e.g., a gNB) and an eNB connected to the 5G core network 114, or between two eNBs connected to the 5G core network 114, or a combination thereof. In some implementations, the Xn interface may include an Xn user plane (Xn-U) interface and an Xn control plane (Xn-C) interface. The Xn-U interface may provide non-guaranteed delivery of user plane PDUs and support / provide data forwarding and flow control functions. Xn-C can provide management and error handling functions, functions for managing the Xn-C interface, mobility support for UE 102 in connected mode (e.g., CM-CONNECTED), including functions for managing connected-mode UE mobility between one or more RAN nodes 106, and other functions. Mobility support can include context transfer from the old (source) serving RAN node 106 to the new (target) serving RAN node 106, and control of the user plane tunnel between the old (source) serving RAN node 106 and the new (target) serving RAN node 106. The protocol stack of Xn-U can include a transport network layer built on the Internet Protocol (IP) transport layer, and a GPRS Tunneling Protocol (GTP-U) layer for the user plane, built on top of the User Datagram Protocol (UDP) or one or more IP layers, or both, to carry user plane PDUs. The Xn-C protocol stack can include an application layer signaling protocol, referred to as the Xn Application Protocol (Xn-AP or XnAP), and a transport network layer (TNL) built on top of the Stream Control Transmission Protocol (SCTP). SCTP can be on top of the IP layer and can provide guaranteed delivery of application layer messages. In the transport IP layer, point-to-point transport is used to deliver signaling PDUs. In other implementations, the Xn-U protocol stack or the Xn-C protocol stack or both can be the same or similar to the user plane protocol stack(s) and / or control plane protocol stack(s) shown and described herein.

[0071] RAN 112 is shown as being communicatively coupled to a core network 114 (referred to as "CN 114"). CN 114 includes multiple network elements, such as network element 108a and network element 108b (collectively, "network elements 108"), which are configured to provide various data and telecommunication services to customers / subscribers (e.g., users of UE 102) who connect to CN 114 using RAN 112. The components of CN 114 may be implemented in one physical node or in separate physical nodes, and may include components that read and execute instructions from a machine-readable medium or computer-readable medium (e.g., a non-transitory machine-readable storage medium). In some implementations, network function virtualization (NFV) may be used to virtualize some or all of the network node functions described herein using executable instructions stored in one or more computer-readable storage media, as described in further detail below. A logical instantiation of CN 114 may be referred to as a network slice, and a logical instantiation of a portion of CN 114 may be referred to as a network sub-slice. NFV architecture and infrastructure can be used to virtualize one or more network functions that could otherwise be performed by proprietary hardware onto physical resources including a combination of industry-standard server hardware, storage hardware, or switches. In other words, NFV systems can be used to perform virtual or reconfigurable implementations, or both, of one or more network components or functions.

[0072] The application server 110 may be an element that provides applications that use IP bearer resources (e.g., UMTS packet service (PS) domain, LTE PS data services, etc.) with the core network. The application server 110 may also be configured to support one or more communication services (e.g., VoIP sessions, PTT sessions, group communication sessions, social networking services, etc.) for the UE 102 using the CN 114. The application server 110 may use the IP communication interface 130 to communicate with one or more network elements 108a.

[0073] In some implementations, CN 114 may be a 5G core network (referred to as "5GC 114" or "5G core network 114"), and RAN 112 may connect to CN 114 using a next-generation interface 124. In some implementations, next-generation interface 124 may be divided into two parts: a next-generation user plane (NG-U) interface 114, which carries traffic data between RAN node 106 and a user plane function (UPF); and an S1 control plane (NG-C) interface 126, which is a signaling interface between RAN node 106 and an access and mobility management function (AMF). Examples of CN 114 being a 5G core network are discussed in more detail with respect to subsequent figures.

[0074] In some implementations, the CN 114 may be an EPC (referred to as “EPC 114” or the like), and the RAN 112 may connect to the CN 114 using an S1 interface 124. In some implementations, the S1 interface 124 may be divided into two parts: an S1-user plane (S1-U) interface 128, which carries traffic data between the RAN node 106 and a serving gateway (S-GW); and an S1-MME interface 126, which is a signaling interface between the RAN node 106 and a mobility management entity (MME).

[0075] Regarding the multipath relay aspect of the present disclosure, Layer 2 (L2) UE-to-Network (U2N) relay was defined in 3GPP Release 17 (Rel-17) to support network coverage extension for remote UEs. Support for multipath, where a UE has one direct path to a gNB and one indirect path to another UE, is being studied and specified in 3GPP Release 18 (Rel-18). While the case where the indirect path is via an L2U2N relay UE is well studied, the case where the indirect path is via a peer-to-peer link (e.g., wired, WiFi, etc.) has not yet been fully studied and developed. As used herein, the term "peer-to-peer link" refers to a communication link between a pair of network devices that operates at a theoretical maximum in terms of efficiency or throughput, such as a P2P or D2D communication link between a pair of UEs.

[0076] This disclosure provides techniques and technologies for implementing multipath via indirect paths over peer-to-peer links (e.g., wired, WiFi, etc.), including both transmit and receive operations. For the case where the indirect path is via an L2 U2N relay UE, this disclosure also provides support for lossless delivery for inter-gNB path switching scenarios.

[0077] This disclosure discusses the following enhancements for Release 18 multipath relaying, including: (1) reliability and throughput enhancements for remote UEs when within the coverage of a network node (e.g., a gNB); (2) multipath enhancements (e.g., when a UE uses a direct path and an indirect path to connect to the same gNB); (3) enhancements to support lossless delivery and service continuity for inter-gNB path switching scenarios using L2 U2N relaying UEs; and (4) enhancements to fault notification for U2U relaying to support service continuity. Other enhancements for Release 18 are described and claimed.

[0078] In these and other ways, multiple paths for transmitting data packets will enable remote UEs to improve their performance. The advanced relay solutions discussed herein can provide efficiencies in resource usage and / or consumption and improved user experience for sidelink technologies used in IoT and / or vehicle-to-everything (V2X) networks, as well as other types of networks.

[0079] As previously discussed, in some implementations, the individual RAN nodes 106 may be implemented as a gNB dual architecture including multiple gNB-DUs connected to the gNB-CU using respective F1 interfaces. Figure 2 An example of a gNB dual architecture for the RAN node 106 is shown in FIG.

[0080] Figure 2 2 shows a wireless communication system 200. The wireless communication system 200 is Figure 1 The wireless communication system 200 depicts a UE 202 connected to a gNB 204 via a connection 214. The UE 202 and the connection 214 are similar to those described in reference Figure 1 UE 102 and connections 118, 120 are depicted. The gNB 204 is similar to the RAN node 106, and the implementation of the RAN node 106 is shown as a gNB with a dual architecture.

[0081] like Figure 2 As depicted, the gNB 204 is divided into two physical entities, referred to as a centralized or central unit (CU) and a distributed unit (DU). The gNB 204 may include a gNB-CU 212 and one or more gNB-DUs 210. The gNB-CU 212 is further divided into a gNB-CU control plane (gNB-CU-CP) 206 and a gNB-CU user plane (gNB-CU-UP) 208. The gNB-CU-CP 206 and the gNB-CU-UP 208 communicate over an E1 interface. The gNB-CU-CP 206 communicates with one or more gNB-DUs 210 over an F1-C interface. The gNB-CU-UP 208 communicates with one or more gNB-DUs 210 over an F1-U interface.

[0082] In some implementations, there is a single gNB-CU 212 for each gNB 204 that controls multiple gNB-DUs 210. For example, a gNB 204 may have more than 100 gNB-DUs 210 connected to a single gNB-CU 212. Each gNB-DU 210 can support one or more cells, and one gNB 204 can potentially control hundreds of cells in a 5G NR system.

[0083] The gNB-CU 212 is primarily responsible for controlling and managing overall network operations, performing control plane-related tasks such as connection establishment, mobility management, and signaling. It is responsible for non-real-time functions, including policy decisions, routing, and session management. The gNB-CU-CP 206 and gNB-CU-UP 208 provide support for higher layers of the protocol stack, such as the Service Data Adaptation Protocol (SDAP), Packet Data Convergence Protocol (PDCP), and RRC.

[0084] The gNB-DU 210 is responsible for real-time, high-speed functions such as scheduling radio resources, managing the data plane, and performing error handling and retransmissions. The gNB-DU 210 provides support for lower layers of the protocol stack, such as the radio link control (RLC), MAC layer, and PHY layer.

[0085] like Figure 2 As depicted, the gNB-DU 210 includes a scheduler 218. To efficiently utilize radio resources, the MAC in the gNB 204 includes a dynamic resource scheduler that allocates physical layer resources for downlink and uplink traffic. In wireless communication system 100 and / or wireless communication system 200, scheduling (including configuration and allocation) of communication paths and / or communication links for UE 202 is primarily handled by the base station of the serving cell, by scheduler 218. Scheduler 218 operates in real time and is responsible for making immediate decisions regarding allocating radio resources for communication paths or communication links, managing interference, and adhering to the quality of service (QoS) requirements of different services and users. Scheduler 218 within gNB-DU 210 makes decisions regarding resource allocation, including when and how to schedule communication paths and / or communication links for UE 202. It takes into account, among other factors, the capabilities, mobility status, quality of service requirements, and current network conditions of UE 202.

[0086] Although the scheduler 218 resides within the gNB-DU, it frequently interacts with the gNB-CU. The gNB-CU provides the gNB-DU with necessary control and configuration information, which the gNB-CU uses to make real-time scheduling decisions and efficiently manage radio resources. The configuration, policies, and user-specific QoS parameters provided by the gNB-CU help the scheduler 218 in the gNB-DU efficiently allocate resources and manage user traffic to meet the diverse service requirements of 5G and 6G networks.

[0087] Regarding NR sidelink relay enhancement, Figure 2An architecture for multipath transmission using two communication paths (e.g., a direct path 230 and an indirect path 232) is shown. This scenario has the potential to improve reliability and / or robustness as well as throughput and is therefore considered an enhancement area in the 3GPP Release 18 work item. The multipath relay solution is used for UE aggregation, where a UE is connected to the network via a direct path 230 and via an indirect path 232 of another UE using a non-standardized UE-UE interconnect. UE aggregation aims to provide applications that require high uplink (UL) bit rates on 5G terminals in situations where normal UEs are too limited by the UL UE transmission power to achieve a defined bit rate (particularly at the cell edge). In addition, UE aggregation can also improve reliability, stability and reduce latency of services, i.e., if the channel conditions of a terminal deteriorate, another terminal can be used to compensate for the unstable service performance caused by the changing channel conditions.

[0088] like Figure 2 As depicted, UE 202 or UE 220 can be configured to operate as a source device, and gNB 204 can be configured to operate as a destination device, or vice versa. For example, assume that UE 202 is a remote UE. For example, UE 202 can connect to gNB 204 via communication link 214 (e.g., a Uu link) using direct path 230. For example, UE 202 can also connect to gNB 204 via first communication link 222 (e.g., a U2U link) using indirect path 232. For example, indirect path 232 can also include second communication link 224, e.g., a Uu link. In turn, gNB 204 can communicate with core network 114 via communication link 228 (e.g., an N2 / N3 link). In multipath discussions within RAN2 and in 3GPP Release 18 work and this disclosure, this configuration is sometimes referred to as "Multipath Scenario 2" for multipath.

[0089] Figure 3A A user plane protocol stack 300 is shown. The user plane protocol stack 300 is suitable for supporting the communication of information (such as user plane data and / or control plane data) for the wireless communication system 100 and / or the wireless communication system 200. For example, the user plane protocol stack 300 is a protocol stack for a cellular network (such as, for example, a wireless communication system). Figure 1 and Figure 2 Specifically, the user plane protocol stack 300 is an example of a protocol stack for multipath scenario 2 in the multipath discussion in Release 18 work and this disclosure.

[0090] like Figure 3AAs depicted, remote UE 302 and relay UE 304 can communicate information with gNB 204 and vice versa using user plane protocol stack 300. For example, remote UE 302 can include an example of UE 202, and relay UE 304 can include an example of UE 220. Remote UE 302 can communicate with gNB 204 via direct path 230 and / or indirect path 232. Direct path 230 does not traverse intermediary devices, such as relay UE 304. Indirect path 232 traverses intermediary devices, such as relay UE 304.

[0091] like Figure 3A As depicted, the user plane protocol stack 300 for 3GPP typically includes multiple layers and associated network interfaces, such as the radio interface of the Uu link. For example, as defined in Release 17, the user plane protocol stack 300 may include a first layer, known as the physical layer (PHY). This layer is responsible for the physical transmission and reception of data over the air interface. It involves functions such as modulation, coding, and multiplexing of data. The second layer is the medium access control (MAC) layer. The MAC layer manages access to shared radio resources and provides efficient data transmission between the PHY and higher layers. It handles tasks such as scheduling, prioritization, and efficient multiplexing of data. The third layer is the radio link control (RLC) layer. The RLC layer ensures reliable and efficient data transmission between the UE and the network. It performs functions such as segmentation, reassembly, error correction, and flow control. The fourth layer is the packet data convergence protocol (PDCP) layer. The PDCP layer provides header compression, encryption, and integrity protection for efficient transmission of IP packets over the radio interface. It also handles functions such as packet reordering and duplicate detection. The fifth layer is the Service Data Adaptation Protocol (SDAP) layer. The SDAP layer classifies, prioritizes, and maps different data flows to specific radio bearers based on Quality of Service (QoS) requirements. It ensures that different types of services receive appropriate service levels. The user plane protocol stack 300 typically includes other protocol layers (not shown), such as: an Internet Protocol (IP) layer, which handles routing and addressing of data packets within the network and performs functions such as encapsulation, decapsulation, and packet routing to ensure end-to-end delivery of data; a transport layer, which provides reliable and congestion-controlled data transmission between the UE and the network and also handles tasks such as segmentation, reassembly, flow control, and error recovery; and an application layer, which represents the highest level of the protocol stack and contains various protocols and services that support specific applications, such as voice, video, messaging, or web browsing.

[0092] A network device may implement some or all of the user plane protocol stack 300 depending on its capabilities and operational role in the network. In one embodiment, for example, remote UE 302 may implement a substack of five protocol layers, including Uu-SDAP 306, Uu-PDCP 308, Uu-RLC 310, Uu-MAC 312, and Uu-PHY 314. Similarly, gNB 204 may also implement a substack of five protocol layers, including Uu-SDAP 326, Uu-PDCP 328, Uu-RLC 330, Uu-MAC 332, and Uu-PHY 334. Relay UE 304 may also implement a substack of the user plane protocol stack 300, such as Uu-RLC 320, Uu-MAC 322, and Uu-PHY 324. The remote UE 302, the relay UE 304, and the gNB 204 may use the user plane protocol stack 300 to communicate information, e.g., user plane data and / or control plane data.

[0093] Remote UE 302 and relay UE 304 may also communicate with each other using a cellular protocol stack (e.g., user plane protocol stack 300), as described further below. In this case, remote UE 302 and relay UE 304 may communicate using, for example, the RLC, MAC, and PHY layers of user plane protocol stack 300.

[0094] Additionally or alternatively, the remote UE 302 and the relay UE 304 can use a non-cellular protocol stack to transmit information to each other. Examples of non-cellular protocol stacks are a P2P protocol stack or a D2D protocol stack for a P2P network. For example, the remote UE 302 can implement a non-cellular stack 316 (e.g., a non-3GPP stack), and the relay UE 304 can implement a non-cellular stack 318 (e.g., a non-3GPP stack). Although this example uses a non-cellular stack (e.g., a P2P protocol stack, a non-3GPP or D2D protocol stack for a P2P network), it will be appreciated that any type of cellular or non-cellular protocol stack can be implemented for the communication link between the remote UE 302 and the relay UE 304. The embodiments are not limited to these examples.

[0095] Generally, a P2P network is a type of network architecture in which participants in the network (called peers) communicate directly with each other and share resources without the need for a central server or intermediary. In a P2P network, each peer has equal capabilities and responsibilities, allowing them to act as both clients and servers. In the traditional client-server network model, a central server manages and controls the network, and clients request resources from the server. However, in a P2P network, each participating node can initiate requests, share resources, and provide services to other nodes in a decentralized manner. P2P networks are commonly used for file sharing, where peers can download files directly from each other, rather than relying on a central file server. Each peer contributes a portion of its own resources (e.g., processing power, storage, or bandwidth) to facilitate data distribution across the network. P2P networks offer several advantages, including increased scalability, fault tolerance, and reduced reliance on central points of failure. P2P networks can efficiently distribute data and services, as well as provide a degree of anonymity and privacy. When a network device operates in P2P mode, it can implement any number of shorter-range wired or wireless technologies, as previously described.

[0096] The P2P protocol stack may include one or more protocol layers for a non-cellular network. For example, the P2P protocol stack may be implemented using underlying wireless technology such as WiFi technology used in WiFi networks (e.g., IEEE 802.11x networks). An example of a protocol stack for a WiFi radio may include a PHY layer, a MAC layer, a distributed coordination function (DCF) layer, a point coordination function (PCF) layer, a logical link control (LLC) layer, an IP layer, a transmission control protocol (TCP) layer, a user datagram protocol (UDP) layer, and an application layer.

[0097] The remote UE 302 and the gNB 204 may communicate information, such as user plane data and / or control plane data, via various protocol layers of the user plane protocol stack 300 via the direct path 230. As previously described, the direct path 230 includes a single communication link 214 between the remote UE 302 and the relay UE 304. In this case, the remote UE 302 and the gNB 204 do not use the relay UE 304 for communication.

[0098] Remote UE 302 and gNB 204 may also communicate information, such as user plane data and / or control plane data, via various protocol layers of user plane protocol stack 300 via indirect path 232. In this case, indirect path 232 includes multiple links, such as communication link 222 and communication link 224. Remote UE 302 and relay UE 304 may communicate information via remote channel 340 using non-cellular stack 316 and non-cellular stack 318, respectively, via communication link 222. For example, remote channel 340 may include a Uu remote UE RLC channel. Relay UE 304 and gNB 204 may communicate information via relay channel 342 using layers of user plane protocol stack 300 via communication link 224. For example, relay channel 342 may include a Uu relay UE RLC channel. When combined, remote channel 340 and relay channel 342 form indirect path 232.

[0099] Figure 3B A control plane protocol stack 350 is shown. The control plane protocol stack 350 is suitable for supporting the communication of information (e.g., control plane data and / or user plane data) for the wireless communication system 100 and / or the wireless communication system 200. The control plane protocol stack 350 is a protocol stack for a cellular network (e.g., as shown in FIG. Figure 1 Specifically, the control plane protocol stack 350 is an example of a protocol stack for multipath scenario 2 in the multipath discussion in Release 18 work and this disclosure.

[0100] The control plane protocol stack 350 is similar to the user plane protocol stack 300. However, the control plane protocol stack 350 includes the Uu-RRC 344 layer instead of the Uu-SDAP 306 layer. For the control plane architecture, similar to the case of the L2 relay UE 304, the remote UE 302 has a single RRC state based on the RRC connection to its serving gNB 204. If the control plane is supported entirely through the indirect path 232 (e.g., through the split bearer option), then Figure 3B A control plane protocol stack 350 is shown.

[0101] For the purposes of this disclosure, an "L2 remote UE" refers to a Layer 2 (L2) source UE that is registered with the network (e.g., has a Uu UE context at the network), is within coverage, is in the RRC_CONNECTED state to support multipath, and is also authorized by the core network 114. Additionally, an "L2 relay UE" refers to an L2 relay UE that supports UE aggregation and is within coverage. When an L2 relay UE is performing UE-to-network data forwarding for a remote UE 302, it is also assumed that the L2 relay UE is connected to a network element (e.g., gNB 204) and / or the core network 114. The relay UE 304 may also be referred to as an "L2 relay UE," "L2 forwarding UE," "L2 aggregation UE," etc. Furthermore, the gNB 204 may refer to a RAN node, a radio access network (RAN), and / or an NG-RAN.

[0102] This disclosure provides additional details of multipath enhancements for multipath scenario 2 beyond those previously proposed, and briefly covers the following issues: (1) transmit and receive operation procedures for multipath with non-3GPP links; and (2) replication enhancements and failure handling.

[0103] As previously mentioned, the discussion in this disclosure relates to a scenario where a remote UE 302 has a connection via another UE (e.g., relay UE 304), assuming a theoretically ideal UE-UE interconnection. With respect to multipath in RAN2, this is referred to as "Multipath Scenario 2." This can be particularly beneficial for improving UL data throughput to meet the limited UL transmission power constraints of any given remote UE 302. Here, the ideal connection can be due to the close proximity of the two UEs and / or, for example, a lossless wired connection between the two UEs. The embodiments are not limited in this context.

[0104] The process of multipath enablement and transmission and reception operations for multipath scenario 2 using UE-UE peer links is described below. Multipath enablement refers to how to enable remote UE 302 to utilize multiple (e.g., two in Release 18) available paths for packet transmission. For multipath scenario 2, in which the UE-UE peer link is used as the indirect path 232, the gNB 204 is notified of the available indirect path 232 when the direct path 230 connection is established, and the gNB 204 then provides the configuration to the L2 remote UE 302 accordingly. In one example, the configuration for UE aggregation is provided in the PDCP configuration for each bearer, or the L2 remote / relay UE configuration, or in an RRC reconfiguration within a new configuration information element (IE), including a BOOLEAN indication for turning multipath ideal links on or off.

[0105] The process of DL data transmission is described as follows. In one example, for a receive operation of an L2 relay UE 304, when a multipath ideal link is configured and enabled or set to true for a given remote UE 302 resource bearer (RB) identifier (ID), for example, within a PDCP configuration or other configuration, the UE delivers data packets received on a specifically configured Uu RLC entity with a specific channel ID (e.g., from an ingress RLC channel mapped or configured with the corresponding remote UE 302 RB ID) to a non-cellular protocol stack (e.g., a P2P stack). In another example, for a receive operation of an L2 U2N remote UE 302, when a multipath ideal link is configured and enabled or set to true for a given remote UE 302 RB ID (e.g., within a PDCP configuration or other configuration), the UE delivers data packets received on a peer link to an upper layer (e.g., PDCP) based on the remote UE 302 RB ID, according to an implementation.

[0106] The process for UL data transmission is described as follows. In one example of a transmit operation for a L2 U2N remote UE 302, when a multipath ideal link is configured and enabled or set to true for a given remote UE 302 RB ID (e.g., within a PDCP configuration or other configuration), and if replication is enabled / activated for the RB, then if it is a PDCP data protocol data unit (PDU), the data PDU is replicated and submitted to the associated RLC entity (e.g., Uu entity) for processing in a conventional manner, and given that the transmitting PDCP entity is associated with one RLC entity and one peer link, the packet is delivered to the non-cellular protocol stack for carriage to the relay UE 304.

[0107] In another example of a receive operation for an L2 relay UE 304, when a multipath ideal link is configured and enabled or set to true for a given remote UE 302 RB ID (e.g., within a PDCP configuration or other configuration), the relay UE 304 receives all packets on the non-cellular link and uses the remote UE 302 RB ID information received on the non-cellular link to deliver the packets to its own RLC layer / entity based on the mapping configuration.

[0108] Depending on the implementation of the relay UE 304, each RLC entity established based on the gNB configuration receives the corresponding packet based on a one-to-one (1:1) mapping of the RLC channel ID associated with the remote UE 302 RB ID. Once at the corresponding RLC entity, if the packet is destined for the relay UE 304, the packet is sent to upper layers.

[0109] In another example of a transmit operation for an L2 relay UE 304, when a multipath ideal link is configured and enabled or set to true for a given remote UE 302 RB ID (e.g., within a PDCP configuration or other configuration), the corresponding relay UE 304 RLC entity of the egress RLC channel then submits the packet to the lower layers for delivery to the gNB 204.

[0110] CR 0771 for the 3GPP TS 38.300 standard defines multi-path (MP) relay in Section 16.X entitled "Multi-path Relay", which incorporates some of the embodiments disclosed herein, such as references to Figure 3A and Figure 3B The user plane protocol stack 300 and / or control plane protocol stack 350 are described. In a multi-path relay scenario, when the MP remote UE 302 is in the RRC_CONNECTED state, the MP remote UE 302 is connected to a single gNB 204 via one direct path and one indirect path 232. For the indirect path 232, both L2 and L3 MP relay architectures are supported. With the exception of the control sidelink resources, the L3 MP relay architecture is transparent to the serving NG-RAN of the MP relay UE 304. When the MP remote UE 302 uses the SL indirect path, Mode 1 resource allocation is supported only for the intra-DU case, where SR / BSR and grants are sent over the direct path 230.

[0111] In multipath relay, the interface between the MP remote UE 302 and the MP relay UE 304 may be a proximity communication 5 (PC5) interface or a non-3GPP connection (NC3) interface. The PC5 interface and the NC3 interface are merely examples, and other interfaces, such as those suitable for short-range communication and communication protocols, may also be used. The embodiments are not limited in this context.

[0112] The PC5 interface is a communication interface for direct device-to-device (D2D) communication in LTE and NR networks. Specifically, the PC5 interface is an interface for the PC5 relay RLC channel, which is an RLC channel between an L2 U2N remote UE 302 and an L2 U2N relay UE 304, or between an L2 U2U remote UE 302 and an L2 U2U relay UE 304, and is used to transmit packets for L2 UE-to-network / UE-to-UE relay via PC5. The PC5 interface operates in unlicensed spectrum to enable direct communication between devices without the need for network infrastructure. It is particularly useful in scenarios requiring low latency, high speed, and reliable communication, such as vehicle-to-vehicle (V2V) or vehicle-to-infrastructure (V2I) communication. The PC5 interface allows devices to directly exchange control and data information, thereby improving the overall efficiency and performance of the communication network. NC3 is a functional entity that facilitates interoperability between 3GPP networks and non-3GPP access networks (e.g., Wi-Fi or Ethernet).

[0113] The N3C interface is the communication interface responsible for managing control plane procedures (including authentication and session establishment) between 3GPP core network and non-3GPP access network elements. It enables seamless connectivity and interoperability between different types of networks within the 3GPP ecosystem. When the interface between MP remote UE 302 and MP relay UE 304 is the N3C interface, the relationship between MP remote UE 302 and MP relay UE 304 is either pre-configured or static, depending on the given implementation as to how the pre-configuration is performed or whether it is made static.

[0114] Multipath relay supports MP remote UE 302 and MP relay UE 304 when they are within a gNB, and the primary cell (PCell) is always on the direct path 230. Multipath relay is typically supported in the following cell deployment scenarios: (1) MP relay UE 304 and MP remote UE 302 are served by the same cell; (2) MP relay UE 304 and MP remote UE 302 are served by different intra-frequency cells of the same gNB; or (3) MP relay UE 304 and MP remote UE 302 are served by different inter-frequency cells of the same gNB. Multipath relay is typically supported in the following sidelink scenarios: (1) the sidelink TX / RX and Uu link share the same carrier at the MP remote UE 302; (2) the sidelink TX / RX and Uu link use different carriers at the MP remote UE 302; (3) the sidelink TX / RX and Uu link share the same carrier at the MP relay UE 304; or (4) the sidelink TX / RX and Uu link use different carriers at the MP relay UE 304.

[0115] Multipath relaying can leverage a given protocol architecture. For example, from the perspective of an L2 MP remote UE 302, there are three bearer types: direct bearer, indirect bearer, and split bearer. Direct bearers involve only Uu radio resources, while indirect bearers involve only PC5 or N3C radio resources. Split bearers involve both Uu and PC5 / N3C radio resources.

[0116] For multipath relay using N3C indirect path between remote UE 302 and relay UE 304, the protocol stacks for user plane and control plane of L2 MP relay architecture are described in CR 0771. Figure 16 .x.2.2-1 and Figure 16 As shown in .x.2.2-2, the L2 MP relay UE 304 and the L2 MP remote UE 302 are connected via an N3C interface.

[0117] In multipath relay using N3C indirect path 232, the SRAP sublayer is not present on the protocol stack. Without an SRAP entity between L2 MP remote UE 302 and L2 MP relay UE 304, Uu SDAP, PDCP, and RRC terminate at gNB 204 and L2 MP remote UE 302. RLC, MAC, and PHY terminate within the Uu hop. UL PDCP PDUs in L2 MP remote UE 302 can be delivered to the Uu RLC entity and the intended PDCP entity or RLC entity in L2 MP relay UE 304. By configuring a 1:1 bearer mapping between RBs in L2 MP remote UE 302 and Uu relay RLC channels in L2 MP relay UE 304, more than one RB on the Uu link of L2 MP relay UE 304 is supported. The Uu relay RLC channels used for PDU delivery for local and relayed traffic on L2 MP relay UE 304 are configured differently. In the L2 PDU over the Uu link, no bearer identification other than the logical channel identifier (LCID) is required. If split bearers are configured and PDCP PDU duplication is activated on the PDCP entity, the duplicated PDCP PDUs are delivered via both the direct path 230 and the indirect path 232.

[0118] Regarding the failure report response, similar to the dual connectivity scenario, in a multipath scenario, when the L2 remote UE 302 has enabled or set multipath or multipath ideal link to true and is currently using the direct path 230 and the indirect path 232, if a failure occurs on one of the links, the remote UE 302 can generate and send a path failure report reporting failure information using the other available path. In one example, upon receiving the failure information, the gNB 204 can provide a response with a configuration setting multipath or multipath ideal link to false, thereby changing the multipath path to a single path. In another example, the gNB 204 can release the available path and the corresponding configuration. In yet another example, the gNB 204 can release the radio configuration associated with the failed path. In yet another example, the gNB 204 can provide a configuration to suspend data transmission and reception for all radio bearers or specific radio bearers until the failed path is reestablished.

[0119] CR 0771 for the 3GPP TS 38.300 standard defines path failure reporting in section 16.x.3.x entitled "Path Failure Report," which incorporates some of the embodiments disclosed herein, such as the failure report responses discussed herein. The embodiments are not limited to the following examples.

[0120] In a first example, the L2 MP remote UE 302 in RRC_CONNECTED performs Uu RLM (as described in clause 9.2.7 of the 3GPP TS 38.300 standard). When the L2 MP remote UE 302 detects a Uu radio link failure (RLF) on the direct path 230, if split SRB1 is configured and the indirect path 232 is not suspended, the L2 MP remote UE 302 triggers a path failure report over the indirect path 232 via an RRC message. Otherwise, an RRC connection reestablishment is initiated.

[0121] In a second example, when the L2 MP remote UE 302 using the PC5 indirect path 232 detects a PC5 radio link failure (RLF) and / or a Uu link failure on the indirect path 232, if the direct path is not suspended, the L2 MP remote UE 302 triggers a path failure report over the direct path 230 via an RRC message.

[0122] In a third example, when the L2 MP remote UE 302 using the N3C indirect path 232 detects an N3C link failure and / or a Uu link failure on the indirect path 232, if the direct path 230 is not suspended, the L2 MP remote UE 302 triggers a path failure report through the direct path 230 via an RRC message.

[0123] Figure 4 An operating environment 400 for wireless communication system 100 and / or wireless communication system 200 is shown. Specifically, operating environment 400 provides an example of data replication and data deduplication for multipath relay in a wireless network (e.g., multipath scenario 2 of a 3GPP network). Furthermore, operating environment 400 provides an example of a sequencer for multipath relay in a wireless network (e.g., multipath scenario 2 of a 3GPP network).

[0124] like Figure 4 As depicted in FIG, remote UE 302 and gNB 204 transmit information to each other in the form of PDU 1-PDU N, where N represents any positive integer. For example, gNB 204 may transmit three PDUs (i.e., N=3) to remote UE 302 via direct path 230 and / or indirect path 232.

[0125] In operating environment 400, a remote UE 302 or gNB 204 can operate as a source device or a destination device, depending on which device is sending a set of information and which device is receiving the set of information. For example, a source device, such as gNB 204, can implement a replicator 402 to communicate information in a first data stream 432 with a destination device, such as remote UE 302. gNB 204 transmits the first data stream 432 via a direct path 230. gNB 204 also uses replicator 402 to transmit a copy of the set of information in a second data stream 434 via an indirect path 232 via relay UE 304. Remote UE 302 can receive the first data stream 432 and / or the replicated second data stream 434.

[0126] When both the direct path 230 and the indirect path 232 are active, the remote UE 302 can receive both the first data stream 432 and the second data stream 434, respectively. In this case, the remote UE 302 uses a deduplicator 404 to identify and discard duplicate information (e.g., duplicate data packets (e.g., PDUs)) to generate a single, unified set of information to output a non-duplicate third data stream 436. The remote UE 302 also uses a sequencer 406 to ensure that the data packets (e.g., PDUs) are received in the correct sequential order, for example, a stream of PDU 1, PDU 2, and PDU 3 sent in a sequential order from PDU 1 to PDU 3.

[0127] Sequencer 406 performs a process known as "packet reordering." In data communications networks, packets may sometimes arrive at their destination out of order due to network congestion, routing issues, or varying transmission paths. To ensure the correct sequential delivery of data, the receiving system uses a sequence number assigned to each packet. During packet reordering, sequencer 406 checks the sequence numbers of incoming packets and rearranges them into the correct order. This process involves buffering out-of-order packets until all necessary packets are received. Once all packets are collected, they are reordered based on their sequence numbers, ensuring that the data is reconstructed in the intended order and then delivered to the receiving application. By employing sequence numbers, packet reordering helps maintain data integrity and ensures that the original message or data stream sent by the sender is faithfully reconstructed at the receiving end.

[0128] When the direct path 230 or the indirect path 232 is inactive, the remote UE 302 receives duplicate information as the first data stream 432 or the second data stream 434. In this case, the remote UE 302 can skip duplicates using the deduplicator 404. However, when data packets arrive out of order in the receive queue, the remote UE 302 can still use the sequencer 406 to locate the received information in the correct sequential order.

[0129] The above-described process of the gNB 204 sending information to the remote UE 302 using multipath relaying also typically occurs when the source device is the remote UE 302 transmitting information to the gNB 204 as the destination device.

[0130] Operating environment 400 illustrates an example of an architecture supporting RAN-based redundancy for multipath scenario 2, using multipath transmission via a direct path 230 through a Uu link and an indirect path 232 through a relay channel 342 and an ideal UE-UE remote channel 340. Increased transmit power is one way to improve data reliability, as it directly correlates to an increased signal-to-noise ratio (SNR). Another way to enhance reliability is through data replication, for example, using multiple communication paths to transmit the same data.

[0131] In the DL, the gNB 204 may duplicate the PDU by implementing a duplicator 402 at the PDCP layer, where the gNB 204 sends two copies, e.g. Figure 4 As shown, one copy is via a direct path 230 and one copy is via an indirect path 232. Details concerning triggering conditions, activation / deactivation, etc. of data replication in the downlink may vary based on a given gNB implementation.

[0132] In the context of PDCP duplication in Ultra-Reliable Low Latency Communication (URLLC), the t-reordering timer is configured by upper layers. However, for the case of sidelink communication, the timer is determined by a given UE implementation. In the case of multipath transmission in a relay environment, the t-reordering timer can be configured by upper layers similar to the URLLC case, and each receiving PDCP entity runs only one t-reordering timer at a given time. When the t-reordering timer expires, the receiving PDCP entity (e.g., at the remote UE 302 in the case of DL PDCP duplication) delivers all stored PDCP service data units (SDUs) to the upper layers in ascending order of sequence numbers (SN). This PDCP duplication in the downlink is similar to multipath scenario 1, where the indirect path 232 is connected via PC5 with a relay UE 304. For multipath scenario 1, the sidelink radio link failure (RLF) detection is based on the 3GPP Release 16 (Rel-16) V2X specification, while failure detection of the peer link is outside the scope of 3GPP. However, in terms of reordering, if a failure occurs on the peer link (with low probability), the remote UE 302 is unaware of such failure and will wait until the t-reordering timer expires to receive the missing PDU, assuming its duplicate copy is also lost / delayed on Uu, for in-sequence delivery to upper layers. For the case of multipath scenario 2, since both data rate and reliability can be assumed to be high and also deterministic, and there are fewer variables as in the case of the wireless PC5 link in multipath scenario 1, these factors may affect the length of the t-reordering timer, however, this depends on the given gNB implementation.

[0133] When the indirect path includes a relay UE 304, the gNB 204 can perform reselection if the relay UE 304 does not meet certain channel quality criteria. On the other hand, in multipath scenario 2, such reselection triggering is not considered, so an indication of link failure for the ideal UE-UE connection (similar to the case of the relay UE 304) would be useful. Especially for time-sensitive use cases, the ideal UE can explicitly indicate a link failure to the gNB 204 over Uu, in which case the gNB 204 can trigger a PDCP status report from the remote UE 302. If the gNB 204 has not received an acknowledgment for the RLC Acknowledged Mode (AM) Uu Data Radio Bearer (DRB) for such packets, the gNB 204 can then retransmit the lost packets as needed.

[0134] For AM DRBs configured by upper layers to send PDCP status reports in the uplink (as defined in 3GPP TS 38.331, statusReportRequired), the receiving PDCP entity triggers a PDCP status report in the following situations: (1) the upper layer requests PDCP entity re-establishment; (2) the upper layer requests PDCP data recovery; (3) the upper layer requests uplink data handover; (4) the upper layer reconfigures the PDCP entity to release the dual active protocol stack (DAPS) and daps-SourceRelease is configured in 3GPP TS 38.331; and (5) the receiving PDCP entity receives a perfect link failure notification from the relay UE 304 in multipath scenario 2.

[0135] For unacknowledged mode (UM) DRBs configured by upper layers to send PDCP status reports in the uplink (as defined in 3GPP TS 38.331, statusReportRequired), the receiving PDCP entity triggers a PDCP status report in the following situations: (1) the upper layers request an uplink data handover; and (2) the receiving PDCP entity receives a perfect link failure notification from a relay UE in multipath scenario 2.

[0136] Figure 5 A message flow 500 is shown. The message flow 500 depicts a message flow between multiple network devices or network entities (e.g., a remote UE 302, a relay UE 304, a source gNB 502 (or other remote UE 302 and / or other relay UE 304), a target gNB 504 (or other remote UE 302), an AMF 506, and one or more UPFs 508). Specifically, the message flow 500 represents an example of a message flow for service continuity and lossless delivery of U2N relay according to one or more embodiments.

[0137] CR 0771 for the 3GPP TS 38.300 standard defines service continuity procedures in Section 16.12.6, entitled "Service Continuity for L2 U2N Relay." The service continuity procedures apply to mobility scenarios involving path switching from an indirect path 232 to a direct path 230 and from a direct path 230 to an indirect path 232, when the L2 U2N remote UE 302 and the L2 U2N relay UE 304 belong to the same gNB or different gNBs. The procedures also apply to mobility scenarios involving path switching from an indirect path 232 to an indirect path 232, when both L2 U2N relay UEs belong to the same gNB or different gNBs. For inter-gNB path switching, the source gNB 502 determines the triggering of the path switch and the path switch type, i.e., direct path 230 or indirect path 232.

[0138] CR 0771 for the 3GPP TS 38.300 standard also defines a handover from the indirect path 232 to the direct path 230. For service continuity of the L2 U2N relay UE 304, when the L2 U2N remote UE 302 switches from the indirect path 232 to the direct path 230 under the same gNB, the CR 0771 for the 3GPP TS 38.300 standard is used. Figure 16 Specifically, this procedure is used for intra-gNB handover of the L2 U2N remote UE 302 from the indirect path 232 to the direct path 230. For service continuity of the L2 U2N relay, when the L2 U2N remote UE 302 switches from the indirect path 232 to the direct path 230 under another gNB, CR 0771 of the 3GPP TS 38.300 standard is used. Figure 16 .12.6.1-2. Specifically, this procedure is used for inter-gNB handover of an L2 U2N remote UE 302 from an indirect path to a direct path.

[0139] like Figure 5 As depicted, message flow 500 illustrates an example of messages and operations for a process of inter-gNB handover of an L2 U2N remote UE 302 from an indirect path 232 to a direct path 230. Embodiments are not limited to the example given by message flow 500.

[0140] The message flow 500 begins with the remote UE 302 exchanging messages 516 including UL data and / or DL ​​data with the UPF 508. The remote UE 302 then exchanges messages 518 with the source gNB 502 for measurement configuration and reporting. For example, the Uu measurement configuration is configured by the source gNB 502, and the measurement report signaling procedure is performed by the L2 U2N remote UE 302 to evaluate both relay link measurements and Uu link measurements. When the configured measurement reporting criteria are met, the measurement results from the L2 U2N remote UE 302 are reported. The sidelink relay measurement report should include at least the L2 U2N relay UE 304 source L2 ID, the serving cell ID (i.e., NCGI / NCI), and the sidelink measurement quantity result. The sidelink measurement quantity can be the SL-RSRP of the serving L2 U2N relay UE, or SD-RSRP if SL-RSRP is not available.

[0141] At block 520, the source gNB 502 decides to trigger a path handover for the L2 U2N remote UE 302 onto the direct path 230. The source gNB 502 sends a message 522 as a HANDOVER REQUEST message to the target gNB 504, which contains the necessary information to prepare for the handover on the target side. To support DL lossless handover for the L2 U2N remote UE 302, the source gNB 502 may not discard the DL data even if the L2 U2N relay UE 304 has already confirmed the delivery of the data based on the gNB implementation. The source gNB 502 then forwards the buffered DL data to the target gNB 504 during the data forwarding process.

[0142] The target gNB 504 may perform admission control. The target gNB 504 sends a message 524 as a HANDOVER REQUEST ACKNOWLEDGE message to the source gNB 502, which contains the new RRC configuration for the L2 U2N remote UE 302. The source gNB 502 triggers a path switch by sending a message 526 as an RRCReconfiguration message to the L2 U2N remote UE 302, which contains at least the cell ID and information required to access the target cell. After receiving the RRCReconfiguration message, the L2 U2N remote UE 302 stops user plane (UP) and control plane (CP) transmissions via the L2 U2N relay UE.

[0143] The source gNB 502 sends a message 528 as an SN STATUS TRANSFER message to the target gNB 504 to transfer the uplink PDCP SN receiver status and downlink PDCP SN transmitter status of the L2 U2N remote UE 302 DRB (i.e., for RLC AM) for which the PDCP state is reserved. The L2 U2N remote UE 302 sends a message 530 to synchronize with the target gNB 504 and perform random access (RA).

[0144] At block 532, the source gNB 502 receives a message 534 with the data from the UPF 508 and delivers the buffered data and the new data as a message 536 from the UPF 508 to the target gNB 504. At block 538, the target gNB 504 buffers the user data from the relay UE 304 via the source gNB 502.

[0145] The L2 U2N remote UE 302 sends a message 540 as an RRCReconfigurationComplete message to the target gNB 504 via the direct path 230. The target gNB 504 optionally sends a UE CONTEXT RELEASE message to notify the source gNB 502 of the success of the path switch.

[0146] The source gNB 502 and the relay UE 304 exchange RRC reconfiguration and RRC reconfiguration complete messages 542, such as an RRCReconfiguration message to the L2 U2N relay UE 304, which is used to reconfigure the connection between the L2 U2N relay UE 304 and the source gNB 502. Based on a given source gNB 502 implementation, the RRCReconfiguration message to the L2 U2N relay UE 304 can be sent at any time after the SN STATUS TRANSFER message. For example, the RRCReconfiguration message can include values ​​carried by one or more IESs to release the Uu relay RLC channel and PC5 relay RLC channel configuration for relaying, as well as the bearer mapping configuration associated with the L2 U2N remote UE, and other RRC reconfiguration information. The L2 U2N relay UE 304 or L2 U2N remote UE 302 AS layer instructs upper layers to release the PC5 unicast link after receiving the RRCReconfiguration message from the source gNB 502. The timing of performing the link release depends on a given UE implementation.For example, the remote UE 302 may send the message 544 to the relay UE 304 as a PC5 link release message.

[0147] Once the HO is completed, the remote UE 302 and the UPF 508 may exchange messages 546 with UL data and / or DL ​​data via the target gNB 504.

[0148] As described above, message flow 500 illustrates an example of messages and operations for an inter-gNB handover process for an L2 U2N remote UE 302 from an indirect path 232 to a direct path 230. Based at least in part on legacy 3GPP Release 15 (Rel-15) handover (HO) operations, path switching from an indirect path 232 to a direct path 230 is supported for a U2N L2 relay, such that the remote UE 302 stops user plane (UP) and control plane (CP) transmissions via the L2 relay UE 304 after receiving an RRCReconfiguration message with the path switch configuration. An example of this path switching process for an inter-gNB scenario from an indirect path 232 to a direct path 230 is illustrated in message flow 500. Message flow 500 is based at least in part on a 3GPP Release 17 relay UE 304 intra-gNB indirect path 232 to direct path 230 handover scenario. For example, for the intra-gNB scenario in 3GPP Release 17, if the gNB is configured as defined in 3GPP TS 38.300, PDCP re-establishment or PDCP data resumption in uplink is performed by the L2 remote UE 302 during path switch for lossless delivery.

[0149] The message flow 500 provides an example of inter-gNB U2N relay for both uplink (UL) and downlink (DL) use cases where data loss may occur, for example, when following the 3GPP Release 15 legacy break-before-make handover strategy.

[0150] In one example, for a DL scenario, relay UE 304 receives and confirms the delivery of PDUs on the RLC AM bearer from source gNB 502. Source gNB 502 decides to perform a path switch to direct path 230 after measurement event X1 and sends an RRCReconfiguration message to remote UE 302, at which point remote UE 302 stops UP and CP transmissions via L2 U2N relay UE 304. During this time, data loss may occur if a PC5 RLF occurs. This is because RLC terminates at each hop. Source gNB 502 may have received acknowledgments from lower layers for some packets successfully received by relay UE 304. However, upon PDCP re-establishment, remote UE 302 is unaware of these packets and therefore loses them.

[0151] In another example, for an UL scenario, relay UE 304 receives and confirms the delivery of PDUs on the SL-RLC AM bearer from remote UE 302. Source gNB 502 decides to perform a path switch to the direct path after measurement event X1 and sends an RRCReconfiguration message to remote UE 302, at which point remote UE 302 stops UP and CP transmissions via L2 U2N relay UE 304. If a Uu RLF occurs after remote UE 302 stops using relay UE 304 for UP / CP transmissions, relay UE 304 cannot indicate the Uu RLF to remote UE 302, and data loss may occur. This is because remote UE 302 may have received acknowledgments from lower layers for certain packets successfully received by relay UE 304. However, these packets may not have been received by source gNB 502 and, therefore, were not included in the SN STATUS transmission to be resumed.

[0152] For example, even though PDCP is terminated between the remote UE 302 and the gNB and does not have per-hop termination as in the case of the RLC layer, for PDCP data resumption (if performed by the remote UE 302 for gNB configuration, such as in the case of intra-gNB path switching), the following conditions as given in 3GPP TS 38.232 need to be met: For AM DRBs, when upper layers request PDCP data resumption for a radio bearer, the transmitting PDCP entity performs retransmission of all PDCP data PDUs previously submitted to the re-established or released AM RLC entity, whose successful delivery has not been acknowledged by lower layers, in ascending order of the associated COUNT values.

[0153] Similarly, the procedure for the case of PDCP entity re-establishment is performed as follows: (1) for SRBs, discard all stored PDCP SDUs and PDCP PDUs; (2) apply the encryption algorithm and key provided by the upper layer during the PDCP entity re-establishment procedure; (3) apply the integrity protection algorithm and key provided by the upper layer during the PDCP entity re-establishment procedure; (4) for UM DRBs, for each PDCP SDU that has been associated with a PDCP SN but whose corresponding PDU has not been previously submitted to the lower layer; and (5) for an AM DRB of the Uu interface whose PDCP entity is suspended, the first PDCP SDU from which the successful delivery of its corresponding PDCP data PDU has not been acknowledged by the lower layer, for each PDCP SDU that has been associated with a PDCP SN: (5.1) consider the PDCP SDUs received from the upper layer; (5.2) perform transmission of the PDCP SDUs in ascending order of the COUNT value associated with the PDCP SDUs before PDCP re-establishment without restarting the discardTimer, as TS as specified in clause 5.2.1 of 38.323; (5.3) for an AM DRB whose PDCP entity is not suspended, from the first PDCP SDU for which the successful delivery of its corresponding PDCP data PDU has not been acknowledged by lower layers, before the PDCP entity is re-established, 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 (other <text omitted>).

[0154] As mentioned in the UL and DL scenarios, in the case of RLF, there is a possibility that successful delivery will not be confirmed by the lower (RLC) layers, and end-to-end lossless delivery is not guaranteed. This issue arises for the case of intra-gNB delivery. However, considering extreme cases, no specification changes were agreed. However, for the case of inter-gNB path switching, where path switching may be slower than intra-gNB path switching, the probability of RLF (Uu or PC5) occurring is higher, and therefore some techniques can be pursued to ensure lossless delivery (possibly with minimal specification impact).

[0155] The process for updated status reporting is performed as follows. Relay UE 304 is aware of the path switch command sent from the gNB to remote UE 302. This can occur via a PC5-RRC message from remote UE 302 or signaling from source gNB 502. In this case, when relay UE 304 receives the path switch indication for remote UE 302, relay UE 304 indicates to remote UE 302 via PC5 or to the gNB via the Uu link all data in the UL / DL that has not yet been forwarded to the next hop. This can be similar to the status PDU sent to remote UE 302 for DL ​​or to source gNB 502 for uplink (e.g., using the RLC SN, as relay UE 304 is unaware of the PDCP SN). That is, for example, in the DL case, relay UE 304 notifies remote UE 302 of all buffered data for the PC5 hop that has not yet been acknowledged by lower layers, and remote UE 302 includes the SN of the PDU indicated by relay UE 304 in the PDCP status report.

[0156] Upon receiving the path switch command, the remote UE 302 sends a PDCP status report to the source gNB 502 before the source gNB 502 performs the SN state transfer to the target gNB 504, i.e., the path switch triggers the PDCP status report.

[0157] The process for data buffering is performed as follows: The relay UE 304 retains both UL data and DL data until PDCP retransmission / reestablishment is completed.

[0158] For UL data transmission, the relay UE 304 buffers UL data that has not been RLC-acknowledged over Uu. In the event of UuRLF, the relay UE 304 sends a PC5-S or PC5-RRC message to the remote UE 302 with information about the buffered data that has not been acknowledged by the source gNB 502.

[0159] During PDCP reestablishment or data recovery, if data loss is detected by the remote UE 302 in the DL scenario or the source gNB 502 in the UL scenario, the relay UE 304 can forward buffered data or maintained information to the remote UE 302 or source gNB 502, respectively, as needed. To this end, a path switch buffer timer (pathSwitchBufferTimer) may be required to determine how long packets need to be buffered. Since the PDCP entity is not located at the relay UE 304, the existing SDU discard mechanism based on the discardTimer cannot be used by the relay UE 304 in this scenario, and a new timer must be defined. Another consideration in this data buffering scenario is the relay UE 304's ability to store data from the remote UE 302. This is because the relay UE 304 is a separate UE and may have power consumption and memory / storage limitations. If the relay UE 304 is capable of data buffering, the gNB can configure it to support lossless delivery only during path switching and not otherwise. Another possible limitation for the UE-to-network relay case is that the relay UE 304 must discard buffered data if it moves away from the remote UE 302 during the path switch procedure such that it is no longer within the coverage of both the source gNB 502 and the target gNB 504. This could potentially use the same pathSwitchBufferTimer.

[0160] In 3GPP Release 17, the timing of the PC5 link release depends on the UE implementation and can be performed by the AS layer of the L2 U2N relay UE 304 or the L2 U2N remote UE 302. In the case of an inter-gNB path switch from the indirect path 232 to the direct path 230, the PC5 link can be forced to be maintained until the PDCP data recovery procedure is completed.

[0161] Figure 6 A wireless communication system 600 is shown. The wireless communication system 600 is similar to the wireless communication systems 100 and 200. The wireless communication system 600 provides an example of sidelink U2U relay service continuity support. Specifically, to better support the use case of sidelink relay, supporting UE-to-UE relay is useful for sidelink coverage extension, independent of uplink and downlink usage. This is specified in 3GPP Release 18.

[0162] Figure 6Another example scenario of UE-to-UE relay is shown, in which PC5 links are established between a source remote UE 602 and a relay UE 304, and between the relay UE 304 and a target remote UE 604, to establish an end-to-end PC5 link between the source remote UE 602 and the target remote UE 604 or another destination UE via the relay UE 304. The relay UE 304 may communicate with the gNB 204, thereby allowing communication paths from the source remote UE 602 to the gNB 204 via the relay UE 304, and from the target remote UE 604 to the gNB 204 via the relay UE 304. Embodiments are not limited to this topology.

[0163] Each of the PC5 links needs to be maintained separately to ensure that the source remote UE 602 can successfully communicate with the destination UE or target remote UE 604. In one example, in a layer 2 UE-to-UE relay with a side link, when a PC5 link between the target remote UE 604 or the destination UE and the UE-to-UE relay fails, the relay UE 304 may provide a notification message with an indication of a PC5 link 2 failure notification to enable the source remote UE 602 to quickly perform any of the following: relay reselection or buffering of data, releasing the PC5 connection, or notifying upper layers to determine which action to take for service continuity and reliability.

[0164] Figure 7 An operating environment 700 is shown. The operating environment 700 illustrates operations for the wireless communication system 100, the wireless communication system 200, and / or the wireless communication system 600.

[0165] like Figure 7 As depicted, UE 202 communicates with scheduler 218 for one or more RAN nodes (e.g., gNB 204). UE 202 may be implemented as a remote UE 302 or a relay UE 304. UE 202 may communicate with scheduler 218 to coordinate multipath relay operations for UE 202. UE 202 may send UE capability information 702 to scheduler 218. Scheduler 218 may receive UE capability information 702 and generate multipath relay configuration information 704 for UE 202. Scheduler 218 may send multipath relay configuration information 704 to UE 202. UE 202 may configure its multipath relay operations based on multipath relay configuration information 704. UE 202 may send UE confirmation information 706 to scheduler 218. Scheduler 218 may then update network settings based on UE confirmation information 706 and send new control instructions to UE 202.

[0166] During RRC connection establishment, UE 202 sends an RRC Connection Request message to gNB 204. The RRC Connection Request includes information such as the UE identity and the establishment cause (e.g., MO Data, MO Signaling, etc.). After receiving and processing the RRC Connection Request message, gNB 204 sends an RRC Connection Setup message to UE 202. This message carries the initial configuration for UE 202, including the Signaling Radio Bearer 1 (SRB1) configuration and other parameters required for UE 202 to communicate in RRC Connected Mode. SRB1 is used to send RRC and Non-Access Layer (NAS) messages. Once UE 202 receives and processes the RRC Connection Setup message, it moves to the RRC Connected state and responds with an RRC Connection Setup Complete message. This message typically carries the selected Public Land Mobile Network Identifier (PLMN-ID) and an initial NAS message, typically a Service Request message or an Attach Request message, to initiate NAS-level procedures for network attachment and service accessibility. The RRC Connection Setup procedure results in the establishment of SRB1, allowing UE 202 and gNB 204 to exchange RRC and NAS messages. The UE moves from the RRC Idle state to the RRC Connected state, enabling it to initiate NAS procedures to access network services. The initial configuration provided in the RRC Connection Setup message enables UE 202 to efficiently communicate with the network in the RRC Connected state.

[0167] At some time during or after RRC connection establishment, UE 202 sends UE capability information 702 to gNB 204. UE capability information 702 may include path information 712, path setup information 714, or a combination of path information 712 and path setup information 714.

[0168] The UE capability information 702 includes path information 712 regarding the UE capabilities, including whether the UE 202 is a remote UE 302 capable of communicating with the relay UE 304, or vice versa. The path information 712 may include information describing the communication capabilities of the UE 202, including whether the UE 202 has a non-cellular protocol stack suitable for: establishing a long-range channel 340 with the relay UE 304 when the UE 202 is configured as a remote UE 302, establishing a long-range channel 340 with the remote UE 304 when the UE 202 is configured as a relay UE 304, or establishing a relay channel 342 with the gNB 204 when the UE 202 is configured as a relay UE 304. For example, the UE 202 may be equipped with multiple radio frequency (RF) transceivers capable of operating according to long-range cellular protocols and / or short-range non-cellular protocols.

[0169] The UE capability information 702 also includes path setup information 714. The path setup information 714 includes information related to the multipath relay capability of the UE 202. Examples of the path setup information 714 include, but are not limited to, whether multipath relay is enabled or disabled, a handover (HO) procedure for sustainability of indirect path 232 user plane data or control plane data, an RLC fault reporting procedure, radio bearer (RB) information, ingress Uu RLC channel, egress Uu RLC channel, t-reordering timer information, PDCP status report information, path switching information, SN state transfer information, data buffering information, relay selection information, relay reselection information, or any type of path related information related to multipath relay.

[0170] UE 202 may send UE confirmation information 706 to scheduler 218. UE confirmation information 706 may include confirmation or denial of multipath relay configuration information 704 from scheduler 218, request for new path information 712, request for new path setup information 714, and any other type of confirmation information related to multipath relaying.

[0171] Figure 8A A more detailed view of a data pattern 800 or messaging format suitable for communicating UE capability information 702 is shown. Figure 8A As depicted, UE 202 may communicate UE capability information 702 including path information 712 and / or path setup information 714 in messages defined in accordance with one or more 3GPP standards (eg, 3GPP TS 38.300 standard).

[0172] UE capability information 702 may be carried by a network message including information element 802. Examples of network messages and / or information elements 802 may include, but are not limited to, any network message, such as messages and / or information elements defined in 3GPP Release 17 or Release 18. Examples of configuration values ​​804 may include, but are not limited to, indirect path capabilities 806, relay path information 808, remote path information 810, and status report information 812. Each of indirect path capabilities 806, relay path information 808, remote path information 810, and status report information 812 may conform to corresponding values ​​defined in the 3GPP 38.300 standard. Embodiments are not limited to these examples.

[0173] Figure 8B A more detailed view of a data pattern 844 or messaging format suitable for conveying multipath relay configuration information 704 is shown. Figure 8BAs depicted, a base station (e.g., gNB 204) may transmit multipath relay configuration information 704 including path information 712 and / or path setup information 714 in a message defined in accordance with one or more 3GPP standards (e.g., 3GPP TS 38.300 standard).

[0174] The multipath relay configuration information 704 may be carried by a network message including an information element 838. Examples of network messages and / or information elements 838 may include, but are not limited to, any network message, such as messages and / or information elements defined in 3GPP Release 17 or Release 18. Examples of configuration values ​​840 may include, but are not limited to, multipath settings 814, path switching information 816, reconfiguration information 818, and channel information 820. Each of multipath settings 814, path switching information 816, reconfiguration information 818, and channel information 820 may conform to corresponding values ​​defined in the 3GPP 38.300 standard. Embodiments are not limited to these examples.

[0175] Figure 9A An apparatus 900 is shown that is suitable for implementation as a UE 202 in a wireless communication system 100. As previously described, the UE 202 may operate as a remote UE 302 or a relay UE 304 as defined by the 3GPP TS 38.300 standard (including CR 0771 or other 3GPP standards or non-3GPP standards). Figure 9A , UE 202 is configured to operate as remote UE 302. The embodiments are not limited in this context.

[0176] like Figure 9A As depicted, apparatus 900 may include processor circuitry 904, memory 908 having a radio manager 914, a memory interface 918, a data storage device 926, RF circuitry 920, and RF circuitry 922. Radio manager 914 may include codec 902, user plane protocol stack 300, control plane protocol stack 350, replicator / de-duplicator 934 (e.g., a combination of replicator 402 and de-duplicator 404), and sequencer 406. RF circuitry 920 may include RF circuitry for indirect path 232. For example, RF circuitry 920 may utilize one or more short-range communication protocols, such as non-cellular protocols (e.g., WiFi or Bluetooth). RF circuitry 922 may include RF circuitry for direct path 230. For example, RF circuitry 922 may utilize one or more long-range communication protocols, such as cellular protocols (e.g., 3GPP 5G, NR, or 6G). Apparatus 900 may optionally include a set of platform components (not shown) suitable for UE 202, such as input / output devices, a memory controller, different types of memory, a network interface, hardware ports, and the like.

[0177] Apparatus 900 for UE 202 may receive multipath relay configuration information 704 from base station 924 via RF circuitry 920. Base station 924 may include a Node B, eNode B, or gNB 204 of wireless communication system 100, wireless communication system 200, and / or wireless communication system 600. Apparatus 900 may decode multipath relay configuration information 928 from UE confirmation information 706, as previously described.

[0178] In one example, apparatus 900 for UE 202 includes a memory interface 918 to send or receive multipath relay configuration information 704 for wireless communication system 100, wireless communication system 200, or wireless communication system 600 to or from a data storage device 930. Apparatus 900 also includes processor circuitry 904 operatively coupled to memory interface 918. Processor circuitry 904 is configured to determine whether multipath relay is enabled based on multipath relay configuration information 928. Processor circuitry 904 encodes a first data stream 432 of packet data units (PDUs) for uplink (UL) data transmission to base station 924 via a direct path 230. Processor circuitry 904 encodes a second data stream 434 of PDUs for UL data transmission to base station 924 via an indirect path 232. The second data stream 434 of PDUs is a copy of the first data stream 432 of PDUs. The indirect path 232 may include a remote channel 340 and a relay channel 342.

[0179] The processor circuitry 904 may forward the encoded first data stream 432 of the PDUs to a cellular protocol stack for UL data transmission to the base station 924 via the direct path 230. The processor circuitry may forward the encoded second data stream 434 of the PDUs to a non-cellular protocol stack (e.g., 3GPP user plane protocol stack 300 or 3GPP control plane protocol stack 350) for UL data transmission to the relay UE 304 via a remote channel 340 of the indirect path 232. The direct path 230 may traverse a single communication link 214, and the indirect path 232 may traverse multiple communication links, such as communication link 222 and communication link 224. The remote channel 340 may include a non-cellular channel (e.g., remote channel 340) using a non-cellular protocol stack (e.g., non-cellular stack 316). The relay channel 342 may include a cellular channel using a cellular protocol stack.

[0180] Remote channel 340 may include a communication channel between remote UE 302 and relay UE 304. Relay channel 342 is a communication channel between relay UE 304 and base station 924.

[0181] Processor circuitry 904 may decode a third data stream of packet data units (PDUs) for downlink (DL) data transmission from base station 924 via direct path 230. Processor circuitry 904 may decode a fourth data stream of PDUs for DL ​​data transmission from base station 924 via remote channel 340 of indirect path 232. The fourth data stream of PDUs is a copy of the third data stream of PDUs. Processor circuitry 904 may generate a fifth data stream based on the third data stream of PDUs and the fourth data stream of PDUs.

[0182] The processor circuitry 904 may detect a radio link failure (RLF) on the direct path 230 or the indirect path 232. The processor circuitry 904 may generate a path failure report 938 to indicate the RLF of the direct path 230 or the indirect path 232, and encode the path failure report 938 for UL data transmission to the base station 924 over the direct path 230 when the RLF is for the indirect path 232, or encode the path failure report 938 for UL data transmission to the base station 924 over the indirect path 232 when the RLF is for the direct path 230.

[0183] As previously described, remote UE 302 may perform multipath relay operations and actions based on one or more multipath relay configurations defined by 3GPP TS 38.300, CR 0771 for 3GPP TS 38.300, or other 3GPP or non-3GPP standards. The embodiments are not limited in this context.

[0184] Figure 9B An apparatus 950 is shown that is suitable for implementation as a UE 202 in a wireless communication system 100. As previously described, the UE 202 may operate as a remote UE 302 or a relay UE 304 as defined by the 3GPP TS 38.300 standard (including CR 0771 or other 3GPP standards or non-3GPP standards). Figure 9B , UE 202 is configured to operate as a relay UE 304. The embodiments are not limited in this context.

[0185] The relay UE 304 is configured similarly to the remote UE 302. However, the multipath relay configuration information 928 also includes other types of information, such as mapping information (e.g., RLC information, RB information, ingress channel information, egress channel information, etc.), to allow the relay UE 304 to identify and forward data flows having PDUs received from the base station 924 and intended for the remote UE 302, as previously described.

[0186] In one example, an apparatus 950 for relaying a UE 304 includes a memory interface 918 to send or receive multipath relay configuration information 704 for the wireless communication system 100, the wireless communication system 200, or the wireless communication system 600 to or from the data storage device 930. The apparatus 950 also includes a processor circuit system 904 operatively coupled to the memory interface 918, the processor circuit system 904 configured to decode a data stream of PDUs for UL data transmission from the remote channel 340 of the indirect path 232 for the remote UE 302, and to encode a data stream of PDUs for UL data transmission from the remote channel 342 of the indirect path 232 for the remote UE 302 to the base station 924. The processor circuit system 904 can decode the data stream of the PDU for downlink (DL) data transmission from the relay channel 342 of the indirect path 232 to the base station 924, and encode the data stream of the PDU for DL ​​data transmission from the base station 924 to the remote UE 302 via the remote channel 340 of the indirect path 232.

[0187] As previously described, relay UE 304 may perform multipath relay operations and actions based on one or more multipath relay configurations defined by 3GPP TS 38.300, CR 0771 for 3GPP TS 38.300, or other 3GPP or non-3GPP standards. The embodiments are not limited in this context.

[0188] Figure 10 An apparatus 1000 is shown that is suitable for implementation as a base station 924 in the wireless communication system 100, the wireless communication system 200, and / or the wireless communication system 600. The base station 924 is an example of a gNB 204. As previously discussed, the base station 924 can receive UE capability information 702 from the UE 202. The base station 924 can send multipath relay configuration information 704 to the UE 202 based on the received UE capability information 702. The UE 202 can be arranged to operate as a remote UE 302 or a relay UE 304.

[0189] like Figure 10As depicted, apparatus 1000 may include processor circuitry 1004, memory 1006 with scheduler 218, memory interface 1030, data storage device 1032, and RF circuitry 1034. Scheduler 218 may include codec 1008 and schedule manager 1010. Scheduler 218 may generate multipath relay configuration information 704, which includes path information 712 and path setup information 714. Apparatus 1000 may optionally include a set of platform components (not shown) suitable for UE 202, such as input / output devices, memory controllers, different types of memory, network interfaces, hardware ports, etc.

[0190] In one embodiment, the apparatus 1000 may be implemented for the base station 924. For example, the apparatus 1000 for the base station 924 includes a memory interface 1030 to send or receive the multipath relay configuration information 704 for the wireless communication system 100, the wireless communication system 200, or the wireless communication system 600 to or from the data storage device 1032. The apparatus 1000 also includes a processor circuit system 1004 operably coupled to the memory interface 1030, the processor circuit system 1004 being configured to: encode a first data stream 432 of packet data units (PDUs) for downlink (DL) data transmission to a remote UE 302 via a direct path; forward the encoded first data stream 432 of the PDUs to a cellular protocol stack for DL ​​data transmission to the remote UE 302 via the direct path 230; encode a second data stream 434 of the PDUs for DL ​​data transmission to the remote UE 302 via an indirect path 232, wherein the second data stream 434 of the PDUs is a copy of the first data stream 432 of the PDUs; and forward the encoded second data stream 434 of the PDUs to the cellular protocol stack for DL ​​data transmission to the relay UE 304 via the relay channel 342 of the indirect path 232.

[0191] Processor circuitry 1004 may decode a third data stream of PDUs for uplink (UL) data transmission from remote UE 302 via direct path 230, decode a fourth data stream of PDUs for UL data transmission from relay UE 304 on behalf of remote UE 302 via relay channel 342 of indirect path 232, wherein the fourth data stream of PDUs is a copy of the third data stream of PDUs, and generate a fifth data stream based on the third data stream of PDUs and the fourth data stream of PDUs. Processor circuitry 1004 may remove duplicate PDUs from the third data stream and the fourth data stream to generate the fifth data stream. Processor circuitry 1004 may perform packet reordering to reorder PDUs from the third data stream or the fourth data stream based on the sequence number of each PDU to generate the fifth data stream in a sequential order.

[0192] As previously described, base station 924 may perform multipath relay operations and actions based on one or more multipath relay configurations defined by 3GPP TS 38.300, CR0771 for 3GPP TS 38.300, or other 3GPP or non-3GPP standards. The embodiments are not limited in this context.

[0193] The operation of the disclosed embodiments may be further described with reference to the following figures. Some of the figures in the accompanying drawings may include logic flows. Although such figures presented herein may include specific logic flows, it will be understood that the logic flows merely provide examples of how the general functionality described herein may be implemented. Furthermore, unless otherwise indicated, a given logic flow does not necessarily have to be executed in the order presented. Furthermore, in some embodiments, not all actions shown in the logic flow may be required. Furthermore, a given logic flow may be implemented by hardware elements, software elements executed by a processor, or any combination thereof. The embodiments are not limited in this context.

[0194] Figure 11 An embodiment of a logic flow 1100 is shown. The logic flow 1100 may represent some or all of the operations performed by one or more embodiments described herein. For example, the logic flow 1100 may include some or all of the operations performed by a device or entity (e.g., remote UE 302) within the wireless communication system 100, the wireless communication system 200, and / or the wireless communication system 600. The embodiments are not limited in this context.

[0195] At block 1102, logic flow 1100 determines, based on multipath relay configuration information, that multipath relay is enabled. At block 1104, logic flow 1100 encodes a first data stream of packet data units (PDUs) for uplink (UL) data transmission to a base station via a direct path. At block 1106, logic flow 1100 encodes a second data stream of PDUs for UL data transmission to the base station via an indirect path, the indirect path comprising a remote channel and a relay channel, wherein the second data stream of PDUs is a copy of the first data stream of PDUs. At block 1108, logic flow 1100 transmits the first encoded data stream to the base station via the direct path. At block 1110, logic flow 1100 transmits the encoded second data stream to the relay UE via the remote channel of the indirect path, wherein the first RF circuitry is cellular RF circuitry and the second RF circuitry is non-cellular RF circuitry.

[0196] As an example, apparatus 900 for UE 202 includes a memory interface 918 to send or receive multipath relay configuration information 704 for wireless communication system 100, wireless communication system 200, or wireless communication system 600 to or from a data storage device 930. Apparatus 900 also includes processor circuitry 904 operatively coupled to memory interface 918. Processor circuitry 904 is configured to determine whether multipath relay is enabled based on multipath relay configuration information 928. Processor circuitry 904 encodes a first data stream 432 of packet data units (PDUs) for uplink (UL) data transmission to a base station 924 via a direct path 230. Processor circuitry 904 encodes a second data stream 434 of PDUs for UL data transmission to the base station 924 via an indirect path 232. The second data stream 434 of PDUs is a copy of the first data stream 432 of PDUs. The indirect path 232 may include a remote channel 340 and a relay channel 342. RF circuit system 922 transmits the encoded first data stream 432 to base station 924 via direct path 230. RF circuit system 920 transmits the encoded second data stream 434 to relay UE 304 via remote channel 340 of indirect path 232. First RF circuit system 922 is a cellular RF circuit system, and second RF circuit system 920 is a non-cellular RF circuit system, or vice versa. Embodiments are not limited to this example.

[0197] Figure 12An embodiment of a logic flow 1200 is shown. The logic flow 1200 may represent some or all of the operations performed by one or more embodiments described herein. For example, the logic flow 1200 may include some or all of the operations performed by a device or entity (e.g., relay UE 304) within the wireless communication system 100, the wireless communication system 200, and / or the wireless communication system 600. The embodiments are not limited in this context.

[0198] At block 1202, logic flow 1200 receives a data stream of PDUs for UL data transmission from a remote UE via a remote channel of an indirect path. At block 1204, logic flow 1200 decodes the data stream of PDUs for UL data transmission from the remote channel of the indirect path to the remote UE. At block 1206, logic flow 1200 encodes the data stream of PDUs for UL data transmission from the remote UE to a base station via a relay channel of the indirect path. At block 1208, logic flow 1200 transmits the encoded data stream of PDUs for UL data transmission on behalf of the remote UE to the base station via the relay channel of the indirect path.

[0199] As an example, an apparatus 950 for relaying a UE 304 includes a memory interface 918 to send or receive multipath relay configuration information 704 for the wireless communication system 100, the wireless communication system 200, or the wireless communication system 600 to or from the data storage device 930. The apparatus 950 also includes a processor circuit system 904 operatively coupled to the memory interface 918, the processor circuit system 904 being configured to decode a data stream of PDUs for UL data transmission from the remote channel 340 of the indirect path 232 for the remote UE 302, and to encode a data stream of PDUs for UL data transmission from the remote channel 342 of the indirect path 232 for the remote UE 302 to the base station 924. The processor circuit system 904 can decode the data stream of the PDU for downlink (DL) data transmission from the relay channel 342 of the indirect path 232 to the base station 924, and encode the data stream of the PDU for DL ​​data transmission from the base station 924 to the remote UE 302 via the remote channel 340 of the indirect path 232.

[0200] Apparatus 950 may further include RF circuitry 920 and RF circuitry 922. RF circuitry 920 may receive a data stream of PDUs from remote UE 302 for UL data transmission via remote channel 340 of indirect path 232. RF circuitry 922 may transmit the encoded data stream of PDUs to a base station for UL data transmission on behalf of remote UE 302 via relay channel 342 of indirect path 232. For example, RF circuitry 922 may be cellular RF circuitry, and RF circuitry 920 may be non-cellular RF circuitry. Embodiments are not limited to this example.

[0201] Figure 13 An embodiment of a logic flow 1300 is shown. The logic flow 1300 may represent some or all of the operations performed by one or more embodiments described herein. For example, the logic flow 1300 may include some or all of the operations performed by a device or entity (e.g., base station 924) within the wireless communication system 100, the wireless communication system 200, and / or the wireless communication system 600. The embodiments are not limited in this context.

[0202] In block 1302, logic flow 1300 encodes a first data stream of packet data units (PDUs) for downlink (DL) data transmission to a remote user equipment (UE) via a direct path. In block 1304, logic flow 1300 forwards the encoded first data stream of PDUs to a cellular protocol stack for DL ​​data transmission to the remote UE via the direct path. In block 1306, logic flow 1300 encodes a second data stream of PDUs for DL ​​data transmission to the remote UE via an indirect path, wherein the second data stream of PDUs is a copy of the first data stream of PDUs. In block 1308, logic flow 1300 forwards the encoded second data stream of PDUs to a cellular protocol stack for DL ​​data transmission to a relay UE via a relay channel of the indirect path.

[0203] By way of example, the apparatus 1000 can be implemented for the base station 924. For example, the apparatus 1000 for the base station 924 includes a memory interface 1030 to send or receive the multipath relay configuration information 704 for the wireless communication system 100, the wireless communication system 200, or the wireless communication system 600 to or from the data storage device 1032. The apparatus 1000 also includes a processor circuitry 1004 operatively coupled to the memory interface 1030, the processor circuitry 1004 configured to: encode a first data stream 432 of packet data units (PDUs) for downlink (DL) data transmission to a remote UE 302 via a direct path; forward the encoded first data stream 432 of PDUs to a cellular protocol stack for DL ​​data transmission to the remote UE 302 via the direct path 230; encode a second data stream 434 of PDUs for DL ​​data transmission to the remote UE 302 via an indirect path 232, wherein the second data stream 434 of PDUs is a copy of the first data stream 432 of PDUs; and forward the encoded second data stream 434 of PDUs to the cellular protocol stack for DL ​​data transmission to the relay UE 304 via the relay channel 342 of the indirect path 232. Embodiments are not limited to this example.

[0204] Figure 11-14 Various systems, devices, and components are shown that can implement aspects of the disclosed embodiments. The systems, devices, and components can be used with reference to Figures 1 to 12 The systems, devices, and components described are the same or similar.

[0205] Figure 14 A network 1400 is shown according to various embodiments. The network 1400 may operate in a manner consistent with 3GPP technical specifications for LTE or 5G / NR systems. However, the example embodiments are not limited in this respect, and the described embodiments may be applied to other networks that benefit from the principles described herein, such as future 3GPP systems, etc.

[0206] The network 1400 may include a UE 1402, which may include any mobile or non-mobile computing device designed to communicate with the RAN 1430 via an over-the-air connection. The UE 1402 may be communicatively coupled to the RAN 1430 via a Uu interface. The UE 1402 may be, but is not limited to, a smartphone, a tablet computer, a wearable computer device, a desktop computer, a laptop computer, an in-vehicle infotainment device, an in-car entertainment device, an instrument cluster, a head-up display device, an on-board diagnostic device, a dashboard mobile device, a mobile data terminal, an electronic engine management system, an electronic / engine control unit, an electronic / engine control module, an embedded system, a sensor, a microcontroller, a control module, an engine management system, a networked device, a machine type communication device, an M2M or D2D device, an IoT device, etc.

[0207] In some embodiments, the network 1400 may include multiple UEs directly coupled to each other via sidelink interfaces. The UEs may be M2M / D2D devices that communicate using physical sidelink channels (e.g., but not limited to, PSBCH, PSDCH, PSSCH, PSCCH, PSFCH, etc.).

[0208] In some embodiments, the UE 1402 may also communicate with the AP 1404 via an over-the-air connection. The AP 1404 may manage the WLAN connection, which may be used to offload some / all network traffic from the RAN 1430. The connection between the UE 1402 and the AP 1404 may be consistent with any IEEE 802.11 protocol, where the AP 1404 may be a Wireless Fidelity (Wi-Fi) In some embodiments, the UE 1402, RAN 1430, and AP 1404 may utilize cellular WLAN aggregation (e.g., LWA / LWIP). Cellular WLAN aggregation may involve the UE 1402 being configured by the RAN 1430 to utilize both cellular radio resources and WLAN resources.

[0209] RAN 1430 may include one or more access nodes, such as AN 1460. AN 1460 may terminate air interface protocols for UE 1402 by providing access layer protocols, including RRC, PDCP, RLC, MAC, and L1 protocols. In this manner, AN 1460 facilitates data / voice connectivity between CN 1418 and UE 1402. In some embodiments, AN 1460 may be implemented in a discrete device or as one or more software entities running on a server computer, for example, as part of a virtual network, which may be referred to as a CRAN or virtual baseband unit pool. AN 1460 is also referred to as a BS, gNB, RAN node, eNB, ng-eNB, Node B, RSU, TRxP, TRP, etc. AN 1460 may be a macrocell base station or a low-power base station used to provide femtocells, picocells, or other similar cells with smaller coverage areas, lower user capacity, or higher bandwidth than macrocells.

[0210] In an embodiment where the RAN 1430 includes multiple ANs, these ANs may be coupled to each other via an X2 interface (if the RAN 1430 is an LTE RAN) or an Xn interface (if the RAN 1430 is a 5G RAN). The X2 / Xn interface, which may be divided into a control / user plane interface in some embodiments, may allow the ANs to communicate information related to handover, data / context transfer, mobility, load management, interference coordination, etc.

[0211] Each AN of the RAN 1430 may manage one or more cells, cell groups, component carriers, etc., to provide an air interface for network access to the UE 1402. The UE 1402 may be simultaneously connected to multiple cells provided by the same or different ANs of the RAN 1430. For example, the UE 1402 and the RAN 1430 may use carrier aggregation to allow the UE 1402 to connect to multiple component carriers, each corresponding to a PCell or an Scell. In a dual connectivity scenario, the first AN may be a primary node providing an MCG, and the second AN may be a secondary node providing an SCG. The first AN / second AN may be any combination of an eNB, a gNB, an ng-eNB, etc.

[0212] The RAN 1430 may provide an air interface over a licensed spectrum or an unlicensed spectrum. To operate in an unlicensed spectrum, a node may employ LAA, eLAA, and / or feLAA mechanisms based on CA techniques utilizing PCell / Scell. Before accessing an unlicensed spectrum, a node may perform medium / carrier sensing operations based on, for example, a listen-before-talk (LBT) protocol.

[0213] In a V2X scenario, the UE 1402 or AN 1460 may be or function as an RSU, which may refer to any transport infrastructure entity used for V2X communication. The RSU may be implemented in or by a suitable AN or a fixed (or relatively fixed) UE. An RSU implemented in or by a UE may be referred to as a "UE-type RSU"; an RSU implemented in or by an eNB may be referred to as an "eNB-type RSU"; an RSU implemented in or by a gNB may be referred to as a "gNB-type RSU"; and so on. In one example, an RSU is a computing device coupled to a roadside RF circuit system that provides connectivity support to passing vehicle UEs. The RSU may also include internal data storage circuit systems to store intersection map geometry, traffic statistics, media, and applications / software for sensing and controlling on-going vehicular and pedestrian traffic. The RSU can provide very low-latency communications required for high-speed events (e.g., collision avoidance, traffic warnings, etc.). Additionally or alternatively, the RSU may provide other cellular / WLAN communication services. The components of the RSU may be enclosed in a weatherproof enclosure suitable for outdoor installation and may include a network interface controller to provide a wired connection (e.g., Ethernet) to a traffic signal controller or backhaul network.

[0214] In some embodiments, the RAN 1430 may be an LTE RAN 1426 with an eNB (e.g., eNB 1454). The LTE RAN 1426 may provide an LTE air interface with the following characteristics: a 15 kHz SCS; a CP-OFDM waveform for the DL and an SC-FDMA waveform for the UL; turbo codes for data and TBCC for control; etc. The LTE air interface may rely on CSI-RS for CSI acquisition and beam management; PDSCH / PDCCH DMRS for PDSCH / PDCCH demodulation; and CRS for cell search and initial acquisition, channel quality measurement, and channel estimation for coherent demodulation / detection at the UE. The LTE air interface may operate in sub-6 GHz frequency bands.

[0215] In some embodiments, the RAN 1430 may be an NG-RAN 1428 having a gNB (e.g., gNB 1456) or an ng-eNB (e.g., ng-eNB 1458). The gNB 1456 may connect to a 5G-enabled UE using a 5G NR interface. The gNB 1456 may connect to the 5G core via an NG interface, which may include an N2 interface or an N3 interface. The ng-eNB 1458 may also connect to the 5G core via an NG interface, but may connect to the UE via an LTE air interface. The gNB 1456 and the ng-eNB 1458 may connect to each other via an Xn interface.

[0216] In some embodiments, the NG interface can be divided into two parts: the NG user plane (NG-U) interface, which carries service data between the nodes of the NG-RAN 1428 and the UPF 1438 (e.g., the N3 interface); and the NG control plane (NG-C) interface, which is the signaling interface between the nodes of the NG-RAN 1428 and the AMF 1434 (e.g., the N2 interface).

[0217] The NG-RAN 1428 may provide a 5G-NR air interface with the following features: variable SCS; CP-OFDM for DL, CP-OFDM and DFT-s-OFDM for UL; polarization, repetition, simplex, and Reed-Muller codes for control, and LDPC for data. The 5G-NR air interface may rely on CSI-RS and PDSCH / PDCCH DMRS similar to the LTE air interface. The 5G-NR air interface may not use CRS, but may use PBCH DMRS for PBCH demodulation; PTRS for phase tracking of PDSCH; and tracking reference signals for time tracking. The 5G-NR air interface may operate in FR1 bands, including bands below 6 GHz, or FR2 bands, including bands from 24.25 GHz to 52.6 GHz. The 5G-NR air interface may include SSBs, which are regions of the downlink resource grid that include PSS / SSS / PBCH.

[0218] In some embodiments, the 5G-NR air interface can utilize BWPs for various purposes. For example, BWPs can be used for dynamic adaptation of SCSs. For example, UE 1402 can be configured with multiple BWPs, each configured with a different SCS. When a BWP change is indicated to UE 1402, the transmitted SCS also changes. Another example use case for BWPs involves power conservation. Specifically, UE 1402 can be configured with multiple BWPs with different amounts of frequency resources (e.g., PRBs) to support data transmission in different traffic load scenarios. A BWP containing a smaller number of PRBs can be used for data transmission with light traffic load, while allowing power savings at UE 1402 and, in some cases, at gNB 1456. A BWP containing a larger number of PRBs can be used in scenarios with higher traffic loads.

[0219] RAN 1430 is communicatively coupled to CN 1418, which includes network elements for providing various functions to support data and telecommunication services to customers / subscribers (e.g., users of UE 1402). Components of CN 1418 may be implemented in one physical node or in separate physical nodes. In some embodiments, NFV may be used to virtualize any or all of the functions provided by the network elements of CN 1418 onto physical compute / storage resources in servers, switches, etc. A logical instantiation of CN 1418 may be referred to as a network slice, and a logical instantiation of a portion of CN 1418 may be referred to as a network sub-slice.

[0220] In some embodiments, CN 1418 may be LTE CN 1424, which may also be referred to as EPC. LTE CN 1424 may include MME 1406, SGW 1408, SGSN 1414, HSS 1416, PGW 1410, and PCRF 1412 coupled to one another via interfaces (or "reference points"), as shown. The functions of the elements of LTE CN 1424 may be briefly described as follows.

[0221] The MME 1406 may implement mobility management functions to track the current location of the UE 1402 to facilitate paging, bearer activation / deactivation, handover, gateway selection, authentication, and the like.

[0222] The SGW 1408 can terminate the S1 interface towards the RAN and route data packets between the RAN and the LTE CN 1424. The SGW 1408 can be the local mobility anchor point for handovers between RAN nodes and can also provide an anchor point for inter-3GPP mobility. Other responsibilities may include lawful interception, charging, and some policy enforcement.

[0223] The SGSN 1414 can track the location of the UE 1402 and perform security functions and access control. In addition, the SGSN 1414 can perform inter-EPC node signaling for mobility between different RAT networks; PDN and S-GW selection specified by the MME 1406; MME selection for handover; etc. The S3 reference point between the MME 1406 and the SGSN 1414 can implement user and bearer information exchange for inter-3GPP access network mobility in idle / active states.

[0224] The HSS 1416 may include a database for network users, including subscription-related information used to support network entities handling communication sessions. The HSS 1416 may provide support for routing / roaming, authentication, authorization, naming / addressing resolution, location dependency, etc. The S6a reference point between the HSS 1416 and the MME 1406 may facilitate the transfer of subscription and authentication data used to authenticate / authorize users to access the LTE CN 1418.

[0225] The PGW 1410 may terminate the SGi interface toward a data network (DN) 1422, which may include an application / content server 1420. The PGW 1410 may route data packets between the LTE CN 1424 and the data network 1422. The PGW 1410 may be coupled to the SGW 1408 via an S5 reference point to facilitate user plane tunneling and tunnel management. The PGW 1410 may also include a node (e.g., PCEF) for policy enforcement and charging data collection. Alternatively, the SGi reference point between the PGW 1410 and the data network 1422 may be an operator-external public or private PDN or an intra-operator packet data network, e.g., for providing IMS services. The PGW 1410 may be coupled to the PCRF 1412 via a Gx reference point.

[0226] PCRF 1412 is the policy and charging control element of LTE CN 1424. PCRF 1412 can be communicatively coupled to application / content server 1420 to determine appropriate QoS and charging parameters for service flows. PCRF 1410 can provide the associated rules to PCEF (via the Gx reference point) with the appropriate TFT and QCI.

[0227] In some embodiments, CN 1418 may be 5GC 1452. 5GC 1452 may include AUSF 1432, AMF 1434, SMF 1436, UPF 1438, NSSF 1440, NEF 1442, NRF 1444, PCF 1446, UDM 1448, and AF 1450 coupled to one another via interfaces (or "reference points"), as shown. The functions of the elements of 5GC 1452 may be briefly described as follows.

[0228] The AUSF 1432 may store data used for authentication of the UE 1402 and handle authentication-related functions. The AUSF 1432 may facilitate a common authentication framework for various access types. In addition to communicating with other elements of the 5GC 1452 over reference points as shown, the AUSF 1432 may also present an interface based on the Nausf service.

[0229] The AMF 1434 may allow other functions of the 5GC 1452 to communicate with the UE 1402 and the RAN 1430, and to subscribe to notifications about mobility events related to the UE 1402. The AMF 1434 may be responsible for registration management (e.g., for registering the UE 1402), connection management, reachability management, mobility management, lawful interception of AMF-related events, and access authentication and authorization. The AMF 1434 may provide transport for SM messages between the UE 1402 and the SMF 1436, and act as a transparent proxy for routing SM messages. The AMF 1434 may also provide transport for SMS messages between the UE 1402 and the SMSF. The AMF 1434 may interact with the AUSF 1432 and the UE 1402 to perform various security anchor and context management functions. In addition, the AMF 1434 can be the termination point of the RANCP interface, which may include or be the N2 reference point between the RAN 1430 and the AMF 1434; and the AMF 1434 can be the termination point of NAS (N1) signaling and perform NAS encryption and integrity protection. The AMF 1434 can also support NAS signaling with the UE 1402 over the N3 IWF interface.

[0230] The SMF 1436 may be responsible for SM (e.g., session establishment, tunnel management between the UPF 1438 and the AN 1460); UE IP address allocation and management (including optional authorization); selection and control of UP functions; configuring traffic steering at the UPF 1438 to route traffic to the appropriate destination; terminating the interface toward the policy control function; controlling part of policy enforcement, billing, and QoS; lawful interception (for SM events and interfaces to the LI system); terminating the SM portion of the NAS message; downlink data notification; initiating AN-specific SM information, which is sent to the AN 1460 via the AMF 1434 over N2; and determining the SSC mode for the session. SM may refer to the management of a PDU session, and a PDU session or "session" may refer to a PDU connection service that provides or enables the exchange of PDUs between the UE 1402 and the data network 1422.

[0231] The UPF 1438 can serve as an anchor point for intra-RAT and inter-RAT mobility, an external PDU session point for interconnecting to the data network 1422, and a branch point to support multi-homed PDU sessions. The UPF 1438 can also perform packet routing and forwarding, perform packet inspection, enforce the user plane portion of policy rules, lawful interception of packets (UP collection), perform service usage reporting, perform user plane QoS processing (e.g., packet filtering, gating, UL / DL rate enforcement), perform uplink service validation (e.g., SDF to QoS flow mapping), transport-level packet marking in the uplink and downlink, and perform downlink packet buffering and downlink data notification triggering. The UPF 1438 can include an uplink classifier to support routing of service flows to the data network.

[0232] NSSF 1440 may select a set of network slice instances to serve UE 1402. If necessary, NSSF 1440 may also determine the allowed NSSAI and the mapping to the subscribed S-NSSAI. NSSF 1440 may also determine the set of AMFs or the list of candidate AMFs to be used to serve UE 1402 based on appropriate configuration and possibly by querying NRF 1444. The selection of a set of network slice instances for UE 1402 may be triggered by AMF 1434, to which UE 1402 is registered by interacting with NSSF 1440, which may result in a change of AMF. NSSF 1440 may interact with AMF 1434 via the N22 reference point; and may communicate with another NSSF in the visited network via the N31 reference point (not shown). In addition, NSSF 1440 may present an interface based on Nnssf services.

[0233] NEF 1442 can securely expose services and capabilities provided by 3GPP network functions to third parties, internal exposure / re-exposure, AFs (e.g., AF 1450), edge computing or fog computing systems, and the like. In such embodiments, NEF 1442 can authenticate, authorize, or throttle the AF. NEF 1442 can also convert information exchanged with AF 1450 and information exchanged with internal network functions. For example, NEF 1442 can convert between AF-Service-Identifiers and internal 5GC information. NEF 1442 can also receive information from other NFs based on their exposed capabilities. This information can be stored as structured data in NEF 1442 or in a data storage device NF using standardized interfaces. The stored information can then be re-exposed by NEF 1442 to other NFs and AFs or used for other purposes, such as analysis. In addition, NEF 1442 can present an interface based on NNEF services.

[0234] NRF 1444 can support service discovery functionality, receiving NF discovery requests from NF instances and providing information about discovered NF instances to the NF instances. NRF 1444 also maintains information about available NF instances and the services they support. As used herein, the terms "instantiate," "instantiate," and the like can refer to the creation of an instance, and "instance" can refer to the specific occurrence of an object, for example, an object can occur during the execution of program code. Additionally, NRF 1444 can present an interface based on Nnrf services.

[0235] The PCF 1446 can provide policy rules to the control plane functions for implementation and can also support a unified policy framework to manage network behavior. The PCF 1446 can also implement a front end to access subscription information related to policy decisions in the UDR of the UDM 1448. In addition to communicating with functions through reference points as shown, the PCF 1446 also exposes an interface based on the NPCF service.

[0236] The UDM 1448 can process subscription-related information to support network entities' handling of communication sessions and can store subscription data for the UE 1402. For example, subscription data can be transferred via the N8 reference point between the UDM 1448 and the AMF 1434. The UDM 1448 can include two components: an application front-end and a UDR. The UDR can store subscription data and policy data for the UDM 1448 and PCF 1446, and / or application data for the NEF 1442 (including PFDs for application detection, application request information for multiple UEs 1402), and structured data for exposure. The UDR 221 can present an interface based on Nudr services to allow the UDM 1448, PCF 1446, and NEF 1442 to access a specific set of stored data, as well as read, update (e.g., add, modify), delete, and subscribe to notifications of changes to relevant data in the UDR. The UDM can include a UDM-FE, which is responsible for handling credentials, location management, subscription management, etc. Several different front ends can serve the same user in different transactions. The UDM-FE accesses subscription information stored in the UDR and performs authentication credential processing, user identity processing, access authorization, registration / mobility management, and subscription management. In addition to communicating with other NFs via reference points as shown, the UDM 1448 can also present an interface based on Nudm services.

[0237] The AF 1450 can provide application influence on service routing, provide access to the NEF, and interact with the policy framework for policy control.

[0238] In some embodiments, the 5GC 1452 can implement edge computing by selecting an operator / third-party service that is geographically close to the point where the UE 1402 attaches to the network. This can reduce latency and load on the network. To provide an edge computing implementation, the 5GC 1452 can select a UPF 1438 close to the UE 1402 and perform traffic steering from the UPF 1438 to the data network 1422 via the N6 interface. This can be based on UE subscription data, UE location and information provided by the AF 1450. In this way, the AF 1450 can influence UPF (re)selection and traffic routing. Based on operator deployment, the network operator can allow the AF 1450 to interact directly with the relevant NF when the AF 1450 is considered a trusted entity. In addition, the AF 1450 can present an interface based on the Naf service.

[0239] The data network 1422 may represent various network operator services, Internet access, or third-party services that may be provided by one or more servers (including, for example, the application / content server 1420 ).

[0240] Figure 15 Schematically illustrated is a wireless network 1500 in accordance with various embodiments. The wireless network 1500 may include a UE 1502 in wireless communication with an AN 1524. The UE 1502 and the AN 1524 may be similar to, and substantially interchangeable with, similarly named components described elsewhere herein.

[0241] UE 1502 may be communicatively coupled with AN 1524 via connection 1546. Connection 1546 is shown as an air interface for achieving the communicative coupling and may be consistent with a cellular communication protocol, such as a 5G NR protocol or an LTE protocol operating at mmWave or sub-6 GHz frequencies.

[0242] UE 1502 may include a host platform 1504 coupled to a modem platform 1508. Host platform 1504 may include application processing circuitry 1506, which may be coupled to protocol processing circuitry 1510 of modem platform 1508. Application processing circuitry 1506 may run various applications for UE 1502 that generate / consume application data. Application processing circuitry 1506 may also implement one or more layer operations to send / receive application data to / from a data network. These layer operations may include transport (e.g., UDP) operations and internet (e.g., IP) operations.

[0243] Protocol processing circuitry 1510 may implement one or more of the layer operations to facilitate sending or receiving data over connection 1546. The layer operations implemented by protocol processing circuitry 1510 may include, for example, MAC, RLC, PDCP, RRC, and NAS operations.

[0244] The modem platform 1508 may also include a digital baseband circuit system 1512, which may implement one or more layer operations that are performed as "lower" layer operations by the protocol processing circuit system 1510 in the network protocol stack. These operations may include, for example, PHY operations, including one or more of the following: HARQ-ACK functions, scrambling / descrambling, encoding / decoding, layer mapping / demapping, modulation symbol mapping, received symbol / bit metric determination, multi-antenna port precoding / decoding (which may include one or more of the following: space-time, space-frequency, or space coding), reference signal generation / detection, preamble sequence generation and / or decoding, synchronization sequence generation / detection, control channel signal blind decoding, and other related functions.

[0245] The modem platform 1508 may also include a transmit circuit system 1514, a receive circuit system 1516, an RF circuit system 1518, and an RF front end (RFFE) 1520, which may include or be connected to one or more antenna panels 1522. In short, the transmit circuit system 1514 may include digital-to-analog converters, mixers, intermediate frequency (IF) components, etc.; the receive circuit system 1516 may include analog-to-digital converters, mixers, IF components, etc.; the RF circuit system 1518 may include low-noise amplifiers, power amplifiers, power tracking components, etc.; the RFFE 1520 may include filters (e.g., surface / bulk acoustic wave filters), switches, antenna tuners, beamforming components (e.g., phased array antenna components), etc. The selection and arrangement of the components of transmit circuitry 1514, receive circuitry 1516, RF circuitry 1518, RFFE 1520, and antenna panel 1522 (generally referred to as "transmit / receive components") may be specific to the details of a particular implementation, e.g., whether the communication is TDM or FDM, at mmWave or sub-6 GHz frequencies, etc. In some embodiments, the transmit / receive components may be arranged in multiple parallel transmit / receive chains, may be provided on the same or different chips / modules, etc.

[0246] In some embodiments, protocol processing circuitry 1510 may include one or more instances of control circuitry (not shown) to provide control functionality for the transmit / receive components.

[0247] UE reception may be established by and via antenna panel 1522, RFFE 1520, RF circuitry 1518, receive circuitry 1516, digital baseband circuitry 1512, and protocol processing circuitry 1510. In some embodiments, antenna panel 1522 may receive transmissions from AN 1524 via receive beamforming signals received by multiple antennas / antenna elements of one or more antenna panels 1522.

[0248] UE transmission may be established by and via protocol processing circuitry 1510, digital baseband circuitry 1512, transmit circuitry 1514, RF circuitry 1518, RFFE 1520, and antenna panel 1522. In some embodiments, the transmit component of UE 1524 may apply a spatial filter to the data to be transmitted to form a transmit beam sent by the antenna elements of antenna panel 1522.

[0249] Similar to UE 1502, AN 1524 may include a host platform 1526 coupled to a modem platform 1530. Host platform 1526 may include application processing circuitry 1528 coupled to protocol processing circuitry 1532 of modem platform 1530. The modem platform may also include digital baseband circuitry 1534, transmit circuitry 1536, receive circuitry 1538, RF circuitry 1540, RFFE circuitry 1542, and an antenna panel 1544. The components of AN 1524 may be similar to and substantially interchangeable with similarly named components of UE 1502. In addition to performing data transmission / reception as described above, the components of AN 1504 may also perform various logical functions, including, for example, RNC functions, such as radio bearer management, uplink and downlink dynamic radio resource management, and data packet scheduling.

[0250] Figure 16 is a block diagram illustrating components according to some example embodiments that are capable of reading instructions from a machine-readable medium or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and performing any one or more of the methodologies discussed herein. Specifically, Figure 16 A diagrammatic representation of hardware resources 1630 is shown, including one or more processors (or processor cores) 1610, one or more memory / storage devices 1622, and one or more communication resources 1626, each of which can be communicatively coupled via a bus 1620 or other interface circuitry. For embodiments in which node virtualization (e.g., NFV) is utilized, a hypervisor 1602 can be executed to provide an execution environment for one or more network slices / subslices to utilize the hardware resources 1630.

[0251] Processor 1610 may include, for example, processor 1612 and processor 1614. Processor 1610 may be, for example, a central processing unit (CPU), a reduced instruction set computing (RISC) processor, a complex instruction set computing (CISC) processor, a graphics processing unit (GPU), a DSP such as a baseband processor, an ASIC, an FPGA, a radio frequency integrated circuit (RFIC), another processor (including those discussed herein), or any suitable combination of the foregoing.

[0252] The memory / storage device 1622 may include main memory, disk storage, or any suitable combination thereof. The memory / storage device 1622 may include, but is not limited to, any type of volatile, non-volatile, or semi-volatile memory, such as dynamic random access memory (DRAM), static random access memory (SRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, solid-state storage, and the like.

[0253] The communication resources 1626 may include interconnect or network interface controllers, components, or other suitable devices to communicate with one or more peripheral devices 1604 or one or more databases 1606 or other network elements via the network 1608. For example, the communication resources 1626 may include wired communication components (e.g., for coupling via USB, Ethernet, etc.), cellular communication components, NFC components, (or Low power) components, components and other communication components.

[0254] The instructions 106, 1618, 1624, 1628, 1632 may include software, programs, applications, applet, apps, or other executable code for causing at least one of the processors 1610 to perform any one or more of the methods discussed herein. The instructions 106, 1618, 1624, 1628, 1632 may reside, in whole or in part, within any one of the processors 1610 (e.g., within a cache memory of the processor), the memory / storage device 1622, or any suitable combination thereof. In addition, any portion of the instructions 106, 1618, 1624, 1628, 1632 may be transferred to the hardware resources 1630 from any combination of the peripheral device 1604 or the database 1606. Thus, the memory of the processor 1610, the memory / storage device 1622, the peripheral device 1604, and the database 1606 are examples of computer-readable media and machine-readable media.

[0255] For one or more embodiments, at least one of the components described in one or more of the foregoing figures may be configured to perform one or more operations, techniques, processes, and / or methods as described in the Examples section below. For example, the baseband circuit system described above in conjunction with one or more of the foregoing figures may be configured to operate according to one or more of the examples described below. As another example, the circuit system associated with the UE, base station, network element, etc., as described above in conjunction with one or more of the foregoing figures, may be configured to operate according to one or more of the examples described in the Examples section below.

[0256] Figure 17 Computer-readable storage medium 1700 is shown. Computer-readable storage medium 1700 may include any non-transitory computer-readable storage medium or machine-readable storage medium, such as optical, magnetic, or semiconductor storage media. In various embodiments, computer-readable storage medium 1700 may include an article of manufacture. In some embodiments, computer-readable storage medium 1700 may store computer-executable instructions 1702 that may be executed by a circuit system. For example, computer-executable instructions 1702 may include computer-executable instructions 1702 for implementing the operations described with respect to logic flow 1100 and / or logic flow 1100. Examples of computer-readable storage medium 1700 or machine-readable storage medium 1700 may include any tangible medium capable of storing electronic data, including volatile or non-volatile memory, removable or non-removable memory, erasable or non-erasable memory, writable or rewritable memory, and the like. Examples of computer-executable instructions 1702 may include any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, object-oriented code, visual code, and the like.

[0257] The components and features of the above-described devices may be implemented using any combination of discrete circuitry, application-specific integrated circuits (ASICs), logic gates, and / or single-chip architectures. Additionally, where appropriate, features of the devices may be implemented using microcontrollers, programmable logic arrays, and / or microprocessors, or any combination of the foregoing. Note that hardware, firmware, and / or software elements may be collectively or individually referred to herein as "logic" or "circuitry."

[0258] It should be understood that the exemplary devices shown in the above block diagrams may represent a functional descriptive example of many potential implementations. Therefore, the division, omission, or inclusion of block functions depicted in the drawings does not mean that the hardware components, circuits, software, and / or elements used to implement these functions must be divided, omitted, or included in the embodiments.

[0259] At least one computer-readable storage medium may include instructions that, when executed, cause a system to perform any of the computer-implemented methods described herein.

[0260] Some embodiments may be described using the expression "one embodiment" or "an embodiment" and their derivatives. These terms mean that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. The appearance of the phrase "in one embodiment" in various places in the specification does not necessarily all refer to the same embodiment. Furthermore, unless otherwise indicated, the above-described features are considered to be usable together in any combination. Therefore, unless the features are indicated to be incompatible with each other, any features discussed separately can be used in combination with each other.

[0261] The detailed description herein may be presented in terms of program processes executed on a computer or computer network with general reference to the symbols and terms used herein. These process descriptions and representations are used by those skilled in the art to most efficiently convey the substance of their work to others skilled in the art.

[0262] A process is here, and generally, considered to be a self-consistent sequence of operations leading to a desired result. These operations are those requiring physical manipulation of physical quantities. Usually, though not necessarily, these quantities take the form of electrical, magnetic, or optical signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like. It should be noted, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities.

[0263] Furthermore, the manipulations performed are often referred to in terms such as addition or comparison, which are often associated with mental operations performed by a human operator. In any of the operations described herein that form part of one or more embodiments, such capabilities of a human operator are not required or desirable in most cases. Rather, the operations are machine operations. Useful machines for performing the operations of various embodiments include general-purpose digital computers or similar devices.

[0264] The expressions "coupled" and "connected," and their derivatives, may be used to describe some embodiments. These terms are not necessarily intended to be synonyms for each other. For example, some embodiments may be described using the terms "connected" and / or "coupled" to indicate that two or more elements are in direct physical or electrical contact with each other. However, the term "coupled" may also mean that two or more elements are not in direct contact with each other, but still cooperate or interact with each other.

[0265] Various embodiments also relate to apparatus or systems for performing these operations. The apparatus may be specially constructed for the desired purpose, or the apparatus may comprise a general-purpose computer selectively activated or reconfigured by a computer program stored in the computer. The processes presented herein are not inherently related to a particular computer or other apparatus. Various general-purpose machines may be used with programs written in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the required method steps. The required structure for a variety of these machines will be apparent from the description given.

[0266] The above description includes examples of the disclosed architecture. It is, of course, not possible to describe every conceivable combination of components and / or methodologies, but one skilled in the art will recognize that many further combinations and permutations are possible. Accordingly, the novel architecture is intended to embrace all such changes, modifications, and variations that fall within the spirit and scope of the appended claims.

[0267] As previously referenced Figures 1-17 The various elements of the described devices may include various hardware elements, software elements, or a combination of the two. Examples of hardware elements may include devices, logic devices, components, processors, microprocessors, circuits, processors, circuit elements (e.g., transistors, resistors, capacitors, inductors, etc.), integrated circuits, application specific integrated circuits (ASICs), programmable logic devices (PLDs), digital signal processors (DSPs), field programmable gate arrays (FPGAs), memory cells, logic gates, registers, semiconductor devices, chips, microchips, chipsets, etc. Examples of software elements may include software components, programs, applications, computer programs, application programs, system programs, software development programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, functions, methods, processes, software interfaces, application programming interfaces (APIs), instruction sets, computing codes, computer codes, code segments, computer code segments, words, values, symbols, or any combination thereof. However, determining whether to implement an embodiment using hardware elements and / or software elements may vary depending on any number of factors, such as desired computational rate, power levels, thermal tolerances, processing cycle budgets, input data rates, output data rates, memory resources, data bus speeds, and other design or performance constraints, as desired for a given implementation.

[0268] One or more aspects of at least one embodiment may be implemented by representative instructions stored on a machine-readable medium, which represents various logic within a processor, and when read by a machine, the instructions cause the machine to manufacture logic to perform the techniques described herein. Such representations, referred to as "IP cores," may be stored on tangible machine-readable media and provided to various customers or manufacturing facilities to be loaded into manufacturing machines that manufacture the logic or processor. Some embodiments may be implemented, for example, using a machine-readable medium or article of manufacture, which may store instructions or instruction sets that, if executed by a machine, may cause the machine to perform methods and / or operations according to the embodiments. Such a machine may include, for example, any suitable processing platform, computing platform, computing device, processing device, computing system, processing system, computer, processor, etc., and may be implemented using any suitable combination of hardware and / or software. The machine-readable medium or article of manufacture may include, for example, any suitable type of memory unit, memory device, memory article, memory medium, storage device, storage article, storage medium, and / or storage unit, such as memory, removable or non-removable media, erasable or non-erasable media, writable or rewritable media, digital or analog media, hard disk, floppy disk, compact disk read only memory (CD-ROM), compact disk recordable (CD-R), compact disk rewritable (CD-RW), optical disk, magnetic media, magneto-optical media, removable memory cards or disks, various types of digital versatile disks (DVDs), magnetic tape, tape cassettes, etc. The instructions may include any suitable type of code implemented using any suitable high-level, low-level, object-oriented, visual, compiled and / or interpreted programming language, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, encrypted code, etc.

[0269] It should be understood that the exemplary devices shown in the above block diagrams may represent a functional descriptive example of many potential implementations. Therefore, the division, omission, or inclusion of block functions depicted in the drawings does not mean that the hardware components, circuits, software, and / or elements used to implement these functions must be divided, omitted, or included in the embodiments.

[0270] At least one computer-readable storage medium may include instructions that, when executed, cause a system to perform any of the computer-implemented methods described herein.

[0271] Some embodiments may be described using the expression "one embodiment" or "an embodiment" and their derivatives. These terms mean that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. The appearance of the phrase "in one embodiment" in various places in the specification does not necessarily all refer to the same embodiment. Furthermore, unless otherwise indicated, the above-described features are considered to be usable together in any combination. Therefore, unless the features are indicated to be incompatible with each other, any features discussed separately can be used in combination with each other.

[0272] The following examples relate to further embodiments, from which numerous permutations and configurations will be apparent.

[0273] Example Group 1

[0274] Additional examples of the presently described methods, devices, systems, and networks discussed herein include the following non-limiting implementations. Each of the following non-limiting examples may stand alone or in any permutation or combination with any one or more of the other examples provided below or throughout this disclosure.

[0275] Example 1 includes a method that allows at least two communication paths between a UE and a network, where one path is an indirect path via a forwarding / relay UE to relay information (control and user plane) between the remote UE and the network, and the other path is a direct path via a Uu link, where the remote UE and the relay UE belong to the same gNB but can be on the same or different cells.

[0276] Example 2 includes the method of Example 1 and / or some other examples herein, wherein the remote UE or relay UE may inform the gNB of the ideal indirect path therebetween.

[0277] Example 3 includes the method of Examples 1-2 and / or some other examples herein, wherein the indication for enabling multipath for the peer link is configured on a per-bearer basis for a UE using the peer link as one of the paths.

[0278] Example 4 includes the method of Example 3 and / or some other examples herein, wherein downlink data received from the gNB on a specifically configured ingress UuRLC channel is delivered to a peer link protocol stack of the UE.

[0279] Example 5 includes the methods of Examples 3-4 and / or some other examples herein, wherein uplink data from a UE from a specific transmitting PDCP entity / radio bearer ID is replicated if configured and one copy is delivered to the UE's peer link protocol stack.

[0280] Example 6 includes the method of Example 5 and / or some other examples herein, wherein the copied uplink packet is carried in an egress RLC channel to be delivered to the gNB.

[0281] Example 7 includes the method of Examples 3-6 and / or some other examples herein, wherein the gNB releases the configuration of the failed path and / or the available path upon receiving failure information of the direct path.

[0282] Example 8 includes the method of Examples 3-7 and / or some other examples herein, wherein the gNB suspends data transmission and reception for all radio bearers upon receiving failure information of the direct path.

[0283] Example 9 includes a method of supporting PDCP duplication in downlink for multipath transmission using a Uu link and an indirect path using an ideal UE-UE connection.

[0284] Example 10 includes the method of Example 9 and / or some other examples herein, wherein the t-reordering timer is preempted in the event of a link failure indication for a perfect UE-UE connection.

[0285] Example 11 includes the method of Examples 9-10 and / or some other examples herein, wherein, in the event of a link failure indication for a desired UE-UE connection, the gNB triggers a PDCP status report for a PDCP data recovery procedure.

[0286] Example 12 includes a method that enables end-to-end lossless delivery for inter-gNB path switching using UE-to-network relay.

[0287] Example 13 includes the method of Example 12 and / or some other examples herein, wherein the L2 U2N relay UE is aware of the path switch command sent from the gNB to the remote UE.

[0288] Example 14 includes the method of Examples 12-13 and / or some other examples herein, wherein the L2 U2N relay UE provides a status update to the source gNB regarding any packets that have not yet been sent through the second hop in the downlink.

[0289] Example 15 includes the method of Examples 12-14 and / or some other examples herein, wherein the L2 U2N relay UE provides a status update to the L2U2N remote UE regarding any packets that have not been sent through the second hop in the uplink.

[0290] Example 16 includes the method of Examples 12-15 and / or some other examples herein, wherein the path switch triggers a status report from the remote UE to the source gNB before the source gNB performs an SN state transfer to the target gNB.

[0291] Example 17 includes the method of Examples 12-16 and / or some other examples herein, wherein the method comprises employing data buffering at the U2N relay UE to buffer data for the remote UE during the inter-gNB path handover.

[0292] Example 18 includes the method of Example 17 and / or some other examples herein, wherein a new timer is introduced to indicate a duration for which the remote UE's data is buffered.

[0293] Example 19 includes the method of Examples 17-18 and / or some other examples herein, wherein a new capability is introduced for the relay UE to configure whether the relay UE supports data buffering.

[0294] Example 20 includes the method of Examples 12-19 and / or some other examples herein, wherein the PC5 link is maintained during the indirect to direct inter-gNB path handover until the PDCP data recovery procedure is completed.

[0295] Example 21 includes a method for layer 2 UE-to-UE relay for UE coverage extension, which, as an example, supports reporting link failure information to the source UE to enable failure handling for relay reselection.

[0296] Example 22 includes the method of Example 21 and / or some other examples herein, wherein the method includes any one or more of Examples 1-20.

[0297] Example Group 2

[0298] In one aspect, an apparatus for a user equipment (UE) includes: a memory interface configured to send or receive multipath relay configuration information for a wireless communication system to or from a data storage device. The apparatus also includes a processor circuit system operably coupled to the memory interface, the processor circuit system configured to: determine that multipath relay is enabled based on the multipath relay configuration information; encode a first data stream of packet data units (PDUs) for uplink (UL) data transmission to a base station via a direct path; and encode a second data stream of PDUs for UL data transmission to the base station via an indirect path, the indirect path comprising a remote channel and a relay channel, wherein the second data stream of the PDUs is a copy of the first data stream of the PDUs.

[0299] The apparatus may further include processor circuitry for forwarding the encoded first data stream of PDUs to a cellular protocol stack for UL data transmission to the base station over the direct path.

[0300] The apparatus may further include processor circuitry configured to: forward the encoded second data stream of the PDU to a non-cellular protocol stack for UL data transmission to the relay UE via the remote channel of the indirect path. The apparatus may further include: wherein the direct path traverses a single communication link and the indirect path traverses multiple communication links.

[0301] The apparatus may further include wherein the remote channel is a non-cellular channel using a non-cellular protocol stack, and the relay channel is a cellular channel using a cellular protocol stack.

[0302] The apparatus may further include: wherein the remote channel is between the remote UE and the relay UE, and the relay channel is between the relay UE and the base station.

[0303] The apparatus may further include a processor circuit system for decoding a third data stream of a packet data unit (PDU) for downlink (DL) data transmission from the base station via the direct path; decoding a fourth data stream of the PDU for DL ​​data transmission from the base station via the remote channel of the indirect path, wherein the fourth data stream of the PDU is a copy of the third data stream of the PDU; and generating a fifth data stream based on the third data stream of the PDU and the fourth data stream of the PDU.

[0304] The apparatus may further include processor circuitry to: detect a radio link failure (RLF) on the direct path or the indirect path; generate a path failure report to indicate the RLF for the direct path or the indirect path; and encode the path failure report for UL data transmission to the base station over the direct path when the RLF is for the indirect path; or encode the path failure report for UL data transmission to the base station over the indirect path when the RLF is for the direct path.

[0305] The apparatus may further include: a first radio frequency (RF) circuit system for transmitting the encoded first data stream as an RF signal to a base station via a direct path; and a second RF circuit system for transmitting the encoded second data stream as an RF signal to a relay UE via a remote channel of an indirect path, wherein the first RF circuit system is a cellular RF circuit system and the second RF circuit system is a non-cellular RF circuit system.

[0306] In one aspect, an apparatus for a user equipment (UE) includes a memory interface for sending or receiving multipath relay configuration information for a wireless communication system to or from a data storage device.

[0307] The apparatus also includes a processor circuit system operably coupled to the memory interface, the processor circuit system configured to: decode a data stream of PDUs for UL data transmission from a remote channel of the indirect path for a remote UE; and encode the data stream of PDUs for UL data transmission to a base station via a relay channel of the indirect path for the remote UE.

[0308] The apparatus may further include a processor circuit system for decoding a data stream of the PDU for downlink (DL) data transmission from a relay channel of an indirect path to a base station, and encoding a data stream of the PDU for DL ​​data transmission from a remote channel of an indirect path to a remote UE by a base station.

[0309] In one aspect, an apparatus for a base station includes a memory interface for sending or receiving multipath relay configuration information for a wireless communication system to or from a data storage device.

[0310] The apparatus also includes a processor circuit system operably coupled to the memory interface, the processor circuit system being configured to: encode a first data stream of a packet data unit (PDU) for downlink (DL) data transmission to a remote user equipment (UE) via a direct path; forward the encoded first data stream of the PDU to a cellular protocol stack for DL ​​data transmission to the remote UE via the direct path; encode a second data stream of the PDU for DL ​​data transmission to the remote UE via an indirect path, wherein the second data stream of the PDU is a copy of the first data stream of the PDU; and forward the encoded second data stream of the PDU to the cellular protocol stack for DL ​​data transmission to the relay UE via a relay channel of the indirect path.

[0311] The apparatus may further include a processor circuit system for: decoding a third data stream of the PDU for uplink (UL) data transmission from a remote UE via a direct path; decoding a fourth data stream of the PDU for UL data transmission from a relay UE representing the remote UE via a relay channel of an indirect path, wherein the fourth data stream of the PDU is a copy of the third data stream of the PDU; and generating a fifth data stream based on the third data stream of the PDU and the fourth data stream of the PDU.

[0312] The apparatus may further include processor circuitry for removing duplicate PDUs from the third data stream and the fourth data stream to generate a fifth data stream.

[0313] The apparatus may further include a processor circuit system for performing packet reordering to reorder the PDUs from the third data stream or the fourth data stream according to the sequence number of each PDU to generate the fifth data stream in a sequential order. Other technical features may be apparent to those skilled in the art based on the following.

[0314] In one aspect, a method for a user equipment (UE) includes: determining that multipath relay is enabled based on multipath relay configuration information; encoding a first data stream of a packet data unit (PDU) for uplink (UL) data transmission to a base station via a direct path; and encoding a second data stream of the PDU for UL data transmission to the base station via an indirect path, the indirect path including a remote channel and a relay channel, wherein the second data stream of the PDU is a copy of the first data stream of the PDU.

[0315] The method may further include forwarding the encoded first data stream of PDUs to a cellular protocol stack for UL data transmission to the base station over the direct path.

[0316] The method may further include forwarding the encoded second data stream of PDUs to a non-cellular protocol stack for UL data transmission to a relay UE over the remote channel of the indirect path.

[0317] The method may also include wherein the direct path traverses a single communication link and the indirect path traverses multiple communication links.

[0318] The method may further include wherein the remote channel is a non-cellular channel using a non-cellular protocol stack and the relay channel is a cellular channel using a cellular protocol stack.

[0319] The method may further include: wherein the remote channel is between the remote UE and the relay UE, and the relay channel is between the relay UE and the base station.

[0320] The method may further include decoding a third data stream of a packet data unit (PDU) for downlink (DL) data transmission from the base station via the direct path; decoding a fourth data stream of the PDU for DL ​​data transmission from the base station via the remote channel of the indirect path, wherein the fourth data stream of the PDU is a copy of the third data stream of the PDU; and generating a fifth data stream based on the third data stream of the PDU and the fourth data stream of the PDU.

[0321] The method may further include removing duplicate PDUs from the third data stream and the fourth data stream to generate the fifth data stream.

[0322] The method may further include performing packet reordering to reorder PDUs from the third data flow or the fourth data flow according to a sequence number of each PDU to generate the fifth data flow in a sequential order.

[0323] The method may further include: detecting a radio link failure (RLF) on the direct path or the indirect path; generating a path failure report to indicate the RLF of the direct path or the indirect path; and encoding the path failure report for UL data transmission to the base station via the direct path when the RLF is for the indirect path; or encoding the path failure report for UL data transmission to the base station via the indirect path when the RLF is for the direct path.

[0324] The method may also include sending the encoded first data stream as a radio frequency (RF) signal to a base station via a direct path, and sending the encoded second data stream as an RF signal to a relay UE via a remote channel of an indirect path, wherein the first RF circuit system is a cellular RF circuit system and the second RF circuit system is a non-cellular RF circuit system.

[0325] In one aspect, a method for a user equipment (UE) includes decoding a data stream of a PDU for UL data transmission from a remote channel of an indirect path for a remote UE; and encoding the data stream of the PDU for UL data transmission to a base station through a relay channel of the indirect path for the remote UE.

[0326] The method may further include decoding a data stream of the PDU for downlink (DL) data transmission for the base station from a relay channel of the indirect path, and encoding the data stream of the PDU for DL ​​data transmission for the base station to a remote UE through a remote channel of the indirect path.

[0327] In one aspect, a non-transitory machine-readable storage medium includes instructions that, when executed by a circuit system, cause the circuit system to: determine that multipath relay is enabled based on multipath relay configuration information; encode a first data stream of packet data units (PDUs) for uplink (UL) data transmission to a base station via a direct path; and encode a second data stream of PDUs for UL data transmission to the base station via an indirect path, the indirect path including a remote channel and a relay channel, wherein the second data stream of the PDUs is a copy of the first data stream of the PDUs.

[0328] The machine-readable storage medium may further include instructions that, when executed by the circuitry, cause the circuitry to forward the encoded first data stream of PDUs to a cellular protocol stack for UL data transmission to the base station over the direct path.

[0329] The machine-readable storage medium may further include instructions that, when executed by the circuitry, cause the circuitry to forward the encoded second data stream of PDUs to a non-cellular protocol stack for UL data transmission to the relay UE over the remote channel of the indirect path.

[0330] The machine-readable storage medium may also include: wherein the direct path traverses a single communication link and the indirect path traverses multiple communication links.

[0331] The machine-readable storage medium may further include: wherein the remote channel is a non-cellular channel using a non-cellular protocol stack, and the relay channel is a cellular channel using a cellular protocol stack.

[0332] The machine-readable storage medium may further include: wherein the remote channel is between a remote UE and a relay UE, and the relay channel is between the relay UE and a base station.

[0333] The machine-readable storage medium may also include: instructions that, when executed by the circuit system, cause the circuit system to perform the following operations: decode a third data stream of a packet data unit (PDU) for downlink (DL) data transmission from the base station via the direct path; decode a fourth data stream of the PDU for DL ​​data transmission from the base station via the remote channel of the indirect path, wherein the fourth data stream of the PDU is a copy of the third data stream of the PDU; and generate a fifth data stream based on the third data stream of the PDU and the fourth data stream of the PDU.

[0334] The machine-readable storage medium may further include instructions that, when executed by the circuit system, cause the circuit system to perform the following operations: remove duplicate PDUs from the third data stream and the fourth data stream to generate the fifth data stream.

[0335] The machine-readable storage medium may also include: instructions that, when executed by the circuit system, cause the circuit system to perform the following operations: perform packet reordering to reorder PDUs from the third data stream or the fourth data stream according to the sequence number of each PDU to generate the fifth data stream in a sequential order.

[0336] The machine-readable storage medium may further include instructions that, when executed by the circuit system, cause the circuit system to: detect a radio link failure (RLF) on the direct path or the indirect path; generate a path failure report to indicate the RLF of the direct path or the indirect path; and when the RLF is for the indirect path, encode the path failure report for UL data transmission to the base station via the direct path; or when the RLF is for the direct path, encode the path failure report for UL data transmission to the base station via the indirect path.

[0337] The machine-readable storage medium may also include instructions that, when executed by the circuit system, cause the circuit system to perform the following operations: send the encoded first data stream as a radio frequency (RF) signal to a base station via a direct path, and send the encoded second data stream as an RF signal to a relay UE via a remote channel of an indirect path, wherein the first RF circuit system is a cellular RF circuit system and the second RF circuit system is a non-cellular RF circuit system.

[0338] In one aspect, a non-transitory machine-readable storage medium includes instructions that, when executed by a circuit system, cause the circuit system to: decode a data stream of a PDU for UL data transmission from a remote channel of an indirect path for a remote UE; and encode the data stream of the PDU for UL data transmission to a base station through a relay channel of the indirect path for the remote UE.

[0339] The machine-readable storage medium may also include: instructions that, when executed by the circuit system, cause the circuit system to perform the following operations: decoding the data stream of the PDU for downlink (DL) data transmission from the relay channel of the indirect path to the base station; and encoding the data stream of the PDU for DL ​​data transmission to the remote UE through the remote channel of the indirect path to the base station.

[0340] The apparatus may further include processor circuitry for removing duplicate PDUs from the third data stream and the fourth data stream to generate the fifth data stream.

[0341] The apparatus may further include processor circuitry for performing packet reordering to reorder PDUs from the third data flow or the fourth data flow according to a sequence number of each PDU to generate the fifth data flow in a sequential order.

[0342] The apparatus may further include: a first radio frequency (RF) circuit system for transmitting an RF signal representing an encoded data stream of a PDU to a base station via a relay channel of an indirect path on behalf of a remote UE for UL data transmission; and a second RF circuit system for receiving an RF signal representing the data stream of the PDU from the remote UE via a remote channel of the indirect path for UL data transmission, wherein the first RF circuit system is a cellular RF circuit system and the second RF circuit system is a non-cellular RF circuit system.

[0343] The method may further include sending a radio frequency (RF) signal representing an encoded data stream of the PDU to the base station on behalf of the remote UE through a relay channel of the indirect path for UL data transmission, and receiving an RF signal representing the data stream of the PDU from the remote UE from the remote channel of the indirect path for UL data transmission, wherein the first RF circuit system is a cellular RF circuit system and the second RF circuit system is a non-cellular RF circuit system.

[0344] The machine-readable storage medium may also include: instructions that, when executed by the circuit system, cause the circuit system to perform the following operations: sending a radio frequency (RF) signal representing an encoded data stream of a PDU to a base station through a relay channel of an indirect path on behalf of a remote UE for UL data transmission, and receiving an RF signal representing a data stream of the PDU from the remote UE through a remote channel of the indirect path for UL data transmission, wherein the first RF circuit system is a cellular RF circuit system and the second RF circuit system is a non-cellular RF circuit system.

[0345] the term

[0346] For the purposes of this document, the following terms and definitions apply to the examples and embodiments discussed herein.

[0347] As used herein, the term "circuitry" refers to a hardware component (e.g., an electronic circuit, a logic circuit, a processor (shared, dedicated, or group) and / or memory (shared, dedicated, or group), an application specific integrated circuit (ASIC), a field programmable device (FPD) (e.g., a field programmable gate array (FPGA), a programmable logic device (PLD), a complex PLD (CPLD), a high capacity PLD (HCPLD), a structured ASIC, or a programmable SoC), a digital signal processor (DSP), etc.) that is configured to provide the described functionality, is part of, or includes the hardware component. In some embodiments, the circuitry may execute one or more software or firmware programs to provide at least some of the described functionality. The term "circuitry" may also refer to a combination of one or more hardware elements (or a combination of circuits used in an electrical or electronic system) and program code for executing the functionality of the program code. In these embodiments, the combination of hardware elements and program code may be referred to as a specific type of circuitry.

[0348] As used herein, the term "processor circuitry" refers to a circuitry that is capable of sequentially and automatically performing a sequence of arithmetic or logical operations or recording, storing and / or transmitting digital data, is part of or includes the circuitry. The processing circuitry may include one or more processing cores for executing instructions and one or more memory structures for storing program and data information. The term "processor circuitry" may refer to one or more application processors, one or more baseband processors, a physical central processing unit (CPU), a single-core processor, a dual-core processor, a triple-core processor, a quad-core processor and / or any other device capable of executing or otherwise operating computable instructions (e.g., program code, software modules and / or functional processes). The processing circuitry may include more hardware accelerators, which may be microprocessors, programmable processing devices, etc. One or more hardware accelerators may include, for example, computer vision (CV) and / or deep learning (DL) accelerators. The terms "application circuitry" and / or "baseband circuitry" may be considered synonymous with "processor circuitry" and may be referred to as "processor circuitry."

[0349] As used herein, the term "interface circuitry" refers to, is a part of, or includes circuitry that enables information to be exchanged between two or more components or devices. The term "interface circuitry" may refer to one or more hardware interfaces, such as a bus, an I / O interface, a peripheral component interface, a network interface card, and the like.

[0350] As used herein, the term "user equipment" or "UE" refers to a device with radio communication capabilities and may describe a remote user of network resources in a communication network. The term "user equipment" or "UE" may be considered synonymous with, and may be referred to as, a client, a mobile device, a mobile device, a mobile terminal, a user terminal, a mobile unit, a mobile station, a mobile user, a subscriber, a user, a remote station, an access agent, a user agent, a receiver, a radio device, a reconfigurable radio device, a reconfigurable mobile device, or the like. Furthermore, the term "user equipment" or "UE" may include any type of wireless / wired device or any computing device having a wireless communication interface.

[0351] As used herein, the term "network element" refers to a physical or virtualized device and / or infrastructure used to provide wired or wireless communication network services. The term "network element" may be considered synonymous with and / or referred to as a networked computer, networking hardware, network device, network node, router, switch, hub, bridge, radio network controller, RAN equipment, RAN node, gateway, server, virtualized VNF, NFVI, etc.

[0352] As used herein, the term "computer system" refers to any type of interconnected electronic devices, computing devices, or components thereof. Additionally, the terms "computer system" and / or "system" may refer to various components of a computer that are communicatively coupled to one another. Furthermore, the terms "computer system" and / or "system" may refer to multiple computing devices and / or multiple computing systems that are communicatively coupled to one another and configured to share computing and / or networking resources.

[0353] As used herein, the terms "apparatus," "computer apparatus," and the like refer to a computer device or computer system having program code (e.g., software or firmware) specifically designed to provide specific computing resources. A "virtual apparatus" is a virtual machine image to be implemented by a hypervisor-equipped apparatus that virtualizes or emulates a computer apparatus or is otherwise dedicated to providing specific computing resources.

[0354] As used herein, the term "resource" refers to a physical or virtual component within a computing environment, a physical or virtual device, and / or a physical or virtual component within a specific device, such as computer equipment, mechanical equipment, memory space, processor / CPU time, processor / CPU usage, processor and accelerator load, hardware time or usage, power, input / output operations, ports or network slots, channel / link allocation, throughput, memory usage, storage, network, database, and application, workload units, etc. "Hardware resources" may refer to computing, storage, and / or network resources provided by (one or more) physical hardware elements. "Virtualized resources" may refer to computing, storage, and / or network resources provided by a virtualized infrastructure to an application, device, system, etc. The term "network resources" or "communication resources" may refer to resources accessible to a computer device / system via a communication network. The term "system resources" may refer to any type of shared entity that provides a service, and may include computing and / or network resources. System resources may be considered to be a set of coherent functions, network data objects, or services accessible through a server, wherein such system resources reside on a single host or multiple hosts and are clearly identifiable.

[0355] As used herein, the term "channel" refers to any transmission medium, tangible or intangible, for transmitting data or data streams. The term "channel" may be synonymous and / or equivalent to "communication channel," "data communication channel," "transmission channel," "data transmission channel," "access channel," "data access channel," "link," "data link," "carrier," "radio frequency carrier," and / or any other similar terms representing a path or medium through which data is transmitted. Additionally, the term "link," as used herein, refers to a connection between two devices over a RAT for the purpose of transmitting and receiving information.

[0356] As used herein, the terms "instantiate," "instantiate," and the like refer to the creation of an instance. "Instance" also refers to a specific occurrence of an object, such as an object may occur during the execution of program code.

[0357] The terms "coupled", "communicatively coupled" and their derivatives are used herein. The term "coupled" can mean that two or more elements are in direct physical or electrical contact with each other, can mean that two or more elements are in indirect contact with each other but still cooperate or interact with each other, and / or can mean that one or more other elements are coupled or connected between elements that are referred to as being coupled to each other. The term "directly coupled" can mean that two or more elements are in direct contact with each other. The term "communicatively coupled" can mean that two or more elements can contact each other by means of communication (including by wired or other interconnected connections, by wireless communication channels or links, etc.).

[0358] The term "information element" refers to a structural element that contains one or more fields. The term "field" refers to the individual contents of an information element or a data element that contains content.

[0359] The term "SMTC" refers to the SSB-based measurement timing configuration configured by SSB-MeasurementTimingConfiguration.

[0360] The term "SSB" refers to SS / PBCH block.

[0361] The term "primary cell" refers to an MCG cell operating on a primary frequency, where the UE performs an initial connection establishment procedure or initiates a connection re-establishment procedure.

[0362] The term "primary SCG cell" refers to an SCG cell in which a UE performs random access when performing reconfiguration using a synchronization procedure for DC operation.

[0363] The term "secondary cell" refers to a cell that provides additional radio resources on top of a special cell for a UE configured with CA.

[0364] The term "secondary cell group" refers to a subset of serving cells for a UE configured with DC, which includes a PSCell and zero or more secondary cells.

[0365] The term "serving cell" refers to a primary cell for a UE in RRC_CONNECTED where CA / DC is not configured, and there is only one serving cell including the primary cell.

[0366] The term "serving cell" or "serving cells" refers to a set of cells including special cell(s) and all secondary cells for a UE in RRC_CONNECTED configured with CA / .

[0367] The term "special cell" refers to the PCell of an MCG or the PSCell of an SCG for DC operation; otherwise, the term "special cell" refers to the Pcell.

Claims

1. An apparatus for a user equipment (UE), comprising: a memory interface configured to send or receive multipath relay configuration information for a wireless communication system to or from a data storage device; as well as processor circuitry operatively coupled to the memory interface, the processor circuitry configured to: determining, based on the multipath relay configuration information, that multipath relay is enabled; encoding a first data stream of packet data units (PDUs) for uplink (UL) data transmission to a base station via a direct path; as well as A second data stream of the PDU is encoded for UL data transmission to the base station through an indirect path, the indirect path including a remote channel and a relay channel, wherein the second data stream of the PDU is a copy of the first data stream of the PDU.

2. The device according to claim 1, wherein The remote channel is a non-cellular channel using a non-cellular protocol stack, and the relay channel is a cellular channel using a cellular protocol stack.

3. The apparatus of claim 1 , wherein the processor circuitry is configured to: forwarding the encoded first data stream of PDUs to a cellular protocol stack for UL data transmission to the base station over the direct path; and The encoded second data stream of PDUs is forwarded to a non-cellular protocol stack for UL data transmission to a relay UE over the remote channel of the indirect path.

4. The apparatus of claim 1 , wherein the processor circuitry is configured to: decoding a third data stream of packet data units (PDUs) for downlink (DL) data transmission from the base station over the direct path; decoding a fourth data stream of PDUs for DL ​​data transmission from the base station via the relay UE over the remote channel of the indirect path, wherein The fourth data flow of the PDU is a copy of the third data flow of the PDU; as well as A fifth data stream is generated according to the third data stream of the PDU and the fourth data stream of the PDU. 5 . The apparatus of claim 4 , the processor circuitry configured to remove duplicate PDUs from the third data stream and the fourth data stream to generate the fifth data stream.

6. The apparatus of claim 4, the processor circuitry to perform packet reordering to reorder PDUs from the third data flow or the fourth data flow according to a sequence number of each PDU to generate the fifth data flow in a sequential order.

7. The apparatus of claim 1 , wherein the processor circuitry is configured to: detecting a radio link failure (RLF) on the direct path or the indirect path; generating a path failure report to indicate the RLF of the direct path or the indirect path; and When the RLF is for the indirect path, encoding the path failure report to transmit UL data to the base station through the direct path; or When the RLF is for the direct path, the path failure report is encoded for UL data transmission to the base station through the indirect path.

8. A method for a user equipment (UE), comprising: determining, based on the multipath relay configuration information, that multipath relay is enabled; encoding a first data stream of packet data units (PDUs) for uplink (UL) data transmission to a base station via a direct path; as well as A second data stream of the PDU is encoded for UL data transmission to the base station through an indirect path, the indirect path including a remote channel and a relay channel, wherein the second data stream of the PDU is a copy of the first data stream of the PDU.

9. The method according to claim 8, wherein The remote channel is a non-cellular channel using a non-cellular protocol stack, and the relay channel is a cellular channel using a cellular protocol stack.

10. The method according to claim 8, comprising: forwarding the encoded first data stream of PDUs to a cellular protocol stack for UL data transmission to the base station over the direct path; as well as The encoded second data stream of PDUs is forwarded to a non-cellular protocol stack for UL data transmission to a relay UE over the remote channel of the indirect path.

11. The method according to claim 8, comprising: decoding a third data stream of packet data units (PDUs) for downlink (DL) data transmission from the base station over the direct path; decoding a fourth data stream of a PDU for DL ​​data transmission from the base station via the relay UE through the remote channel of the indirect path, wherein the fourth data stream of the PDU is a copy of the third data stream of the PDU; as well as A fifth data stream is generated according to the third data stream of the PDU and the fourth data stream of the PDU.

12. The method according to claim 8, comprising: Duplicate PDUs are removed from the third data stream and the fourth data stream to generate the fifth data stream.

13. The method according to claim 8, comprising: Packet reordering is performed to reorder PDUs from the third data flow or the fourth data flow according to a sequence number of each PDU to generate the fifth data flow in a sequential order.

14. The method according to claim 8, comprising: detecting a radio link failure (RLF) on the direct path or the indirect path; generating a path failure report to indicate the RLF of the direct path or the indirect path; as well as When the RLF is for the indirect path, encoding the path failure report to transmit UL data to the base station through the direct path; or When the RLF is for the direct path, the path failure report is encoded for UL data transmission to the base station through the indirect path.

15. A machine-readable storage medium comprising instructions that, when executed by a circuit system, cause the circuit system to: determining, based on the multipath relay configuration information, that multipath relay is enabled; encoding a first data stream of packet data units (PDUs) for uplink (UL) data transmission to a base station via a direct path; and encoding a second data stream of the PDU for UL data transmission to the base station via an indirect path, the indirect path comprising a remote channel and a relay channel, wherein: The second data flow of the PDU is a copy of the first data flow of the PDU.

16. The machine-readable storage medium of claim 15, wherein: The remote channel is a non-cellular channel using a non-cellular protocol stack, and the relay channel is a cellular channel using a cellular protocol stack.

17. The machine-readable storage medium of claim 15, comprising instructions that, when executed by the circuit system, cause the circuit system to: forwarding the encoded first data stream of PDUs to a cellular protocol stack for UL data transmission to the base station over the direct path; and The encoded second data stream of PDUs is forwarded to a non-cellular protocol stack for UL data transmission to a relay UE over the remote channel of the indirect path.

18. The machine-readable storage medium of claim 15, comprising instructions that, when executed by the circuitry, cause the circuitry to: decoding a third data stream of packet data units (PDUs) for downlink (DL) data transmission from the base station over the direct path; decoding a fourth data stream of PDUs for DL ​​data transmission from the base station via the relay UE over the remote channel of the indirect path, wherein The fourth data flow of the PDU is a copy of the third data flow of the PDU; as well as A fifth data stream is generated according to the third data stream of the PDU and the fourth data stream of the PDU.

19. The machine-readable storage medium of claim 15, comprising instructions that, when executed by the circuitry, cause the circuitry to: remove duplicate PDUs from the third data stream and the fourth data stream to generate the fifth data stream.

20. The machine-readable storage medium of claim 15, comprising instructions that, when executed by the circuitry, cause the circuitry to: detecting a radio link failure (RLF) on the direct path or the indirect path; generating a path failure report to indicate the RLF of the direct path or the indirect path; and When the RLF is for the indirect path, encoding the path failure report to transmit UL data to the base station through the direct path; or When the RLF is for the direct path, the path failure report is encoded for UL data transmission to the base station through the indirect path.

Images