Layer 2 UE-to-UE data forwarding

Abstract

The invention relates to layer 2 UE-to-UE data forwarding. Systems and methods are provided for transmitting data of interest received from a first remote UE to a second remote UE on a UE-to-UE relay within a wireless communication system using a relay user equipment (UE). The methods may be performed at Layer 2 of a protocol stack of the wireless communication system. A data packet sent on the UE-to-UE relay may include an adaptive header that includes routing information (e.g., Layer 2 address, bearer specific index, etc.) for the UE-to-UE relay. Thus, an adaptive layer may be provided within Layer 2 to decode these adaptive headers. In some cases, a per-bearer method may be used to map between respective direct bearers of a hop-by-hop path configuration of the UE-to-UE relay. Embodiments are also described that avoid the adaptive header and instead use a logical channel identifier (LCID) to make a routing indication.

Description

[0001] Division Statement

[0002] This application is a divisional application of the Chinese invention patent application with the application date of October 22, 2020, the invention name of which is “Layer 2 UE to UE data forwarding” and the application number of which is 202080107317.9. Technical Field

[0003] The present application generally relates to wireless communication systems, including wireless communication systems having one or more user equipments (UEs) that can perform UE-to-UE relay functionality using layer 2 methods. Background Art

[0004] Wireless mobile communication technology uses various standards and protocols to transmit data between base stations and wireless mobile devices. Wireless communication system standards and protocols may include the 3rd Generation Partnership Project (3GPP) Long Term Evolution (LTE) (e.g., 4G) or New Radio (NR) (e.g., 5G); the Institute of Electrical and Electronics Engineers (IEEE) 802.16 standard, which is commonly referred to by industry organizations as Worldwide Interoperability for Microwave Access (WiMAX); and the IEEE 802.11 standard for Wireless Local Area Networks (WLANs), which is commonly referred to by industry organizations as Wi-Fi. In the 3GPP Radio Access Network (RAN) in an LTE system, a base station may include a RAN node such as an Evolved Universal Terrestrial Radio Access Network (E-UTRAN) Node B (also commonly referred to as an evolved Node B, enhanced Node B, eNodeB, or eNB) and / or a Radio Network Controller (RNC) in the E-UTRAN, which communicates with a wireless communication device referred to as a user equipment (UE). In the fifth generation (5G) wireless RAN, the RAN nodes may include 5G nodes, NR nodes (also known as next generation Node B or g NodeB (gNB)).

[0005] The RAN uses radio access technologies (RATs) to communicate between RAN nodes and UEs. The RAN may include Global System for Mobile Communications (GSM), Enhanced Data Rates for GSM Evolution (EDGE) RAN (GERAN), Universal Terrestrial Radio Access Network (UTRAN), and / or E-UTRAN, which provide access to communication services through the core network. Each RAN operates according to a specific 3GPP RAT. For example, GERAN implements GSM and / or EDGE RATs, UTRAN implements Universal Mobile Telecommunications System (UMTS) RATs or other 3GPP RATs, E-UTRAN implements LTE RATs, and NG-RAN implements 5G RATs. In some deployments, E-UTRAN may also implement 5G RATs.

[0006] The frequency bands for 5G NR can be divided into two different frequency ranges. Frequency Range 1 (FR1) may include frequency bands operating at frequencies below 6 GHz, some of which may be used by previous standards and may potentially be expanded to cover new spectrum products from 410 MHz to 7,125 MHz. Frequency Range 2 (FR2) may include frequency bands from 24.25 GHz to 52.6 GHz. The frequency bands in the millimeter wave (mmWave) range of FR2 may have a smaller range but potentially higher available bandwidth than the frequency bands in FR1. The skilled person will recognize that these frequency ranges, which are provided by way of example, may vary over time or from region to region. Summary of the Invention

[0007] Some embodiments of the present application provide a method for establishing a relay user equipment (UE) for a hop-by-hop path configuration, the method comprising: receiving a first side link (SL) configuration message corresponding to a first bearer between the first remote UE and the relay UE from a first remote UE, the first SL configuration message including a first logical channel identifier (LCID), an end-to-end bearer ID, a next-hop quality of service (QoS) indicator, and a first index; generating a second SL configuration message corresponding to a second bearer between the relay UE and a second remote UE, the second SL configuration message including a second LCID, the end-to-end bearer ID, and a second index; sending the second SL configuration message to the second remote UE; receiving a first SL reconfiguration completion message from the second remote UE; and sending a second SL reconfiguration completion message to the first remote UE.

[0008] Some embodiments of the present application also provide another method for establishing a relay user equipment (UE) with a hop-by-hop path configuration, the method comprising: receiving a first side link (SL) configuration message corresponding to a first bearer between the first remote UE and the relay UE from a first remote UE, the first SL configuration message including a first logical channel identifier (LCID) configured to provide routing indications, an end-to-end bearer ID, and a next-hop quality of service (QoS) indicator; generating a second SL configuration message corresponding to a second bearer between the relay UE and a second remote UE, the second SL configuration message including a second LCID configured to provide routing indications and the end-to-end bearer ID; sending the second SL configuration message to the second remote UE; receiving a first SL reconfiguration completion message from the second remote UE; and sending a second SL reconfiguration completion message to the first remote UE.

[0009] Some embodiments of the present application also provide an apparatus for establishing a relay user equipment (UE) for hop-by-hop path configuration, the apparatus comprising one or more processors and a memory, the memory storing instructions that, when executed by the one or more processors, configure the relay UE to: receive a first side link (SL) configuration message corresponding to a first bearer between the first remote UE and the relay UE from a first remote UE, the first SL configuration message comprising a first logical channel identifier (LCID), an end-to-end bearer ID, a next-hop quality of service (QoS) indicator, and a first index; generate a second SL configuration message corresponding to a second bearer between the relay UE and the second remote UE, the second SL configuration message comprising a second LCID, the end-to-end bearer ID, and a second index; send the second SL configuration message to the second remote UE; receive a first SL reconfiguration completion message from the second remote UE; and send a second SL reconfiguration completion message to the first remote UE. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] To easily identify the discussion of any particular element or act, the most significant digit(s) in a reference number refers to the drawing number that first introduces the element.

[0011] Figure 1 A relay UE providing UE-to-UE relaying according to an embodiment is shown.

[0012] Figure 2 A setup procedure for setting up a relay UE to provide UE-to-UE relay between a first remote UE and a second remote UE according to an embodiment is shown.

[0013] Figure 3 is a diagram illustrating a source remote UE, a relay UE, and a destination remote UE and their various user protocol stacks according to embodiments herein.

[0014] Figure 4 Shown is sending a first data packet between a source remote UE and a relay UE according to a UE-to-UE relay between the source remote UE and the destination remote UE according to an embodiment.

[0015] Figure 5 Transmitting a second data packet between a relay UE and a destination remote UE according to a UE-to-UE relay between the source remote UE and the destination remote UE according to an embodiment is shown.

[0016] Figure 6 Various possible adaptation headers that may be used are shown according to some embodiments.

[0017] Figure 7A method for setting up a hop-by-hop path configuration from a source remote UE to a destination remote UE through a relay UE according to an embodiment is shown.

[0018] Figure 8 is a diagram illustrating the use of a data forwarding method per bearer method according to some embodiments.

[0019] Figure 9 A method for setting up a hop-by-hop path configuration from a source remote UE to a destination remote UE through a relay UE according to an embodiment is shown.

[0020] Figure 10 is a diagram illustrating the use of a data forwarding method per bearer method according to some embodiments.

[0021] Figure 11 A method of relaying UE according to an embodiment is shown.

[0022] Figure 12 A method of relaying UE according to an embodiment is shown.

[0023] Figure 13 A method of relaying UE according to an embodiment is shown.

[0024] Figure 14 A method of a relay UE for establishing a hop-by-hop path configuration according to an embodiment is shown.

[0025] Figure 15 A method of a relay UE for establishing a hop-by-hop path configuration according to an embodiment is shown.

[0026] Figure 16 A UE according to one embodiment is shown.

[0027] Figure 17 A network node according to one embodiment is shown.

[0028] Figure 18 An exemplary service-based architecture is shown in accordance with certain embodiments.

[0029] Figure 19 Components according to one embodiment are shown. DETAILED DESCRIPTION

[0030] A relay UE may be capable of receiving data from a wireless mobile device and transmitting it to another wireless mobile device. For example, a relay UE may be capable of receiving data from a first remote UE and transmitting it to a base station (or vice versa, receiving data from a base station and transmitting it to a first remote UE). In other words, the relay UE acts as a UE-to-network (NW) relay between a first remote UE and a base station. In other examples, a relay UE may be capable of receiving data from a first remote UE and transmitting it to a second remote UE (or vice versa, receiving data from a second remote UE and transmitting it to a first remote UE). In other words, the relay UE provides UE-to-UE relay between a first remote UE and a second remote UE.

[0031] A UE that provides UE-to-UE relay can help users of remote UEs connect to each other. For example, a relay UE may be helpful for users of a first remote UE that is out of range of a second remote UE on a side link (SL). In these cases, data can be transmitted from the first remote UE to a relay UE that provides UE-to-UE relay and then forwarded to the second remote UE on the UE-to-UE relay. The relay UE can be similarly used for UE-to-NW relay applications. In this way, communications from the first remote UE can be received by an entity outside the direct range of the first remote UE in the wireless communication system. This may be useful in situations where, for example, one or more various entities (UE, base station) of a wireless communication system are widely dispersed, where each entity is within the range of only one or only a small amount (but not all) of other entities within the wireless communication system.

[0032] It is contemplated that the UE-to-UE relay functionality may be implemented in layer 2 (sometimes referred to herein as "L2") of a protocol stack of, for example, an NR wireless communication system (among other possible systems, such as an LTE wireless communication system or a hybrid or another wireless communication system). Furthermore, any layer 2 UE-to-UE relay functionality used within the wireless communication system may correspond to / be designed for use with the UE-to-NW relay functionality within the wireless communication system implemented in layer 2 of the protocol stack.

[0033] Compared to, for example, Layer 3 approaches, the Layer 2 approach disclosed herein can provide better end-to-end security protection (because the relay UE cannot peek at the data shared between remote UEs in such a Layer 2 approach). Furthermore, the Layer 2 approach enables access stratum (AS) layer mechanisms to ensure quality of service (QoS) and service continuity, which is not possible when using a Layer 3 relay approach. Furthermore, Layer 2 UE-to-UE relay and Layer 2 UE-to-NW relay can have a common scalable design that can be extended to support multi-hop relaying.

[0034] A system implementing UE-to-UE relay functionality may be useful, for example, in public safety situations or vehicle-to-everything (V2X) situations, where a UE may be out of range of a base station but within range of one or more (possibly dispersed) other UEs.

[0035] Figure 1 A relay UE 102 is shown providing UE-to-UE relaying according to an embodiment. The relay UE 102 may be connected to a first remote UE 104 using a first PC5 link 106. The relay UE 102 may also be connected to a second remote UE 108 over a second PC5 link 110. Data may be sent over one or both of the first PC5 link 106 and / or the second PC5 link 110. These data transmissions (as well as other data transmissions over the PC5 links) may be discussed herein as "SL transmissions" or "SL messages."

[0036] Relay UE 102 may receive data of interest for second remote UE 108 as part of one or more data packets from first remote UE 104 over first PC5 link 106. Relay UE 102 may then send the data of interest to second remote UE 108 as part of one or more data packets over second PC5 link 110.

[0037] about Figure 1The described message transmission can be usefully applied to various coverage scenarios. For example, it may be that all three of the relay UE 102, the first remote UE 104, and the second remote UE 108 are out of coverage (e.g., not within the communication range of the base station of the wireless communication system). In this case, these devices can use the first PC5 link 106 and the second PC5 link 110 to enable communication between the first remote UE 104 and the second remote UE 108. As another example, it may be that only the relay UE 102 is in coverage. In this case, the relay UE 102 can forward the data of interest to the second remote UE 108 as described (and this can occur directly via UE-to-UE relay, rather than, for example, the relay UE 102 involving the base station by acting as a UE-to-NW relay). As another example, the relay UE 102 and one of the first remote UE 104 or the second remote UE 108 are in coverage, but the other of the first remote UE 104 and the second remote UE 108 is out of coverage. In this case, the relay UE 102 can forward the data of interest from one of the first remote UE 104 and the second remote UE 108 directly to the other of the first remote UE 104 and the second remote UE 108 (e.g., via UE-to-UE relay), rather than involving a base station in the data transmission process, which may require a greater number of transmissions than in the UE-to-UE relay case.

[0038] It is contemplated that in some embodiments, a relay UE that is providing UE-to-UE relaying may also provide UE-to-NW relaying.

[0039] Figure 2 A setup process 200 is shown according to an embodiment for setting up a relay UE 202 to provide UE-to-UE relaying between a first remote UE 204 and a second remote UE 206. The setup process 200 may include performing a first PC5 discovery 208, during which the relay UE 202 and the second remote UE 206 discover that they are within SL range of each other.

[0040] The setup process 200 may also include performing a second PC5 discovery 210 during which the relay UE 202 and the first remote UE 204 discover that they are within SL range of each other.

[0041] The order of performing the first PC5 discovery 208 and the second PC5 discovery 210 may be reversed.

[0042] As part of performing the first PC5 discovery 208 and / or the second PC5 discovery 210, it may be that, for example, the first remote UE 204 discovers that the second remote UE 206 will be reachable by the first remote UE 204 via the UE-to-UE relay provided by the relay UE 202, and / or the second remote UE 206 discovers that the first remote UE 204 will be reachable by the second remote UE 206 via the UE-to-UE relay provided by the relay UE 202.

[0043] The setup process 200 may also include performing a first PC5 link setup 212, during which the relay UE 202 and the second remote UE 206 establish a PC5 link between them (eg, for SL communication).

[0044] The setup process 200 may also include performing a second PC5 link setup 214, during which the relay UE 202 and the first remote UE 204 establish a PC5 link between them (eg, for SL communication).

[0045] The order in which the first PC5 link setup 212 and the second PC5 link setup 214 are performed may be reversed. Furthermore, it is contemplated that each of the first PC5 discovery 208 and the first PC5 link setup 212 may be performed before either / both of the second PC5 discovery 210 and / or the second PC5 link setup 214 are performed, and / or each of the second PC5 discovery 210 and the second PC5 link setup 214 may be performed before either / both of the first PC5 discovery 208 and / or the first PC5 link setup 212 are performed.

[0046] The setup process 200 also optionally includes performing hop-by-hop path configuration 216. A "hop" can be one direct communication (or one of multiple direct communications) between UEs that are part of a UE-to-UE relay (e.g., a SL communication between a first remote UE 204 and a relay UE 202 can be a "hop," and a SL communication between a relay UE 202 and a second remote UE 206 can be a "hop"). As will be described in further detail below, the hop-by-hop path configuration 216 can be useful in situations where an adaptation header does not carry, for example, a layer 2 address (sometimes referred to herein as a "layer 2 ID" or "L2 ID") in one or more data packets sent along the UE-to-UE relay and / or where an adaptation header is not used at all in one or more data packets sent along the UE-to-UE relay. These hop-by-hop path configurations 216 can configure (or reconfigure) one or more (per-hop) direct bearers identified by a logical channel identifier (LCID) used in data packets using that hop and / or data found in an adaptation header in data packets using that hop. This may be the case for all hops between the endpoints (e.g., in Figure 2 In the case of , all hops between the first remote UE 204 and the second remote UE 206).

[0047] The setup process 200 may also include performing an end-to-end PC5 link setup (control plane) 218, wherein one or more end-to-end bearers are established between the endpoints (e.g., between the first remote UE 204 and the second remote UE 206). These end-to-end bearers may include or contain bearers corresponding to a single "hop" as described above. These end-to-end bearers may include SL signaling radio bearers (SRBs) and / or SL data radio bearers (DRBs). These end-to-end bearers may be established using an end-to-end PC5 signaling (PC5-S) procedure and / or an end-to-end PC5 radio resource control (PC5-RRC) procedure. Each end-to-end bearer may have an ID that is unique with respect to other end-to-end bearers between the same pair of UE endpoints (but may not be globally unique within the wireless communication system).

[0048] End-to-end PC5 link setup (control plane) 218 ​​may not be performed until the intermediate relay UEs (e.g., relay UE 202) are ready to forward data that is not terminated locally at the respective relay UEs. For this reason, in some embodiments, hop-by-hop path configuration 216 is performed. For example, in embodiments using a per-bearer reservation system, hop-by-hop path configuration 216 may be necessary (as opposed to embodiments using per-packet configuration, where all required routing information is conveyed in a user plane header (e.g., an adaptation header) in each data packet, and thus hop-by-hop path configuration 216 may not be necessary).

[0049] The setup process 200 also includes end-to-end data transmission (user plane) 220. The end-to-end data transmission (user plane) 220 may involve data transmission between endpoints and through a relay UE in the manner described above (e.g., data transmission between a first remote UE 204 and a second remote UE 206 via a relay UE 202). The transmission may involve end-to-end transmission using SL DRBs via a relay UE established in the manner described above.

[0050] Figure 3 300 is a diagram illustrating a source remote UE 302, a relay UE 304, and a destination remote UE 306 and their various user protocol stacks according to embodiments herein. As described herein, a "source remote UE" may be a UE that initiates a UE-to-UE relay of data destined for a "destination remote UE." Accordingly, a "destination remote UE" may be a UE that is the intended destination of such data packets.

[0051] The user protocol stack according to the embodiments herein may include one or more of a physical (PHY) layer, a medium access control (MAC) layer, a radio link control (RLC) layer, an adaptation layer, and a packet data convergence protocol (PDCP) layer. As shown, the outgoing user protocol stack 308 of the source remote UE 302 according to the embodiments herein may include a PHY layer 310, a MAC layer 312, an RLC layer 314, an adaptation layer 316, and a PDCP layer 318. In addition, the relay UE 304 may include an incoming user protocol stack 320 having a PHY layer 322, a MAC layer 324, an RLC layer 326, and an adaptation layer 328, and an outgoing user protocol stack 330 having a PHY layer 332, a MAC layer 334, an RLC layer 336, and an adaptation layer 338. Finally, the destination remote UE 306 may include an incoming user protocol stack 340 having a PHY layer 342, a MAC layer 344, an RLC layer 346, an adaptation layer 348, and a PDCP layer 350.

[0052] Each of the PHY layer, MAC layer, RLC layer, and PDCP layer may be layers understood by a person skilled in the art of related wireless communication systems (e.g., NR and / or LTE wireless communication systems).

[0053] The adaptation layer may be used to assist the relay UE in making forwarding decisions as part of the layer 2 forwarding process described herein. An adaptation header may be placed within a radio link control (RLC) protocol data unit (PDU) of the first data packet. Decoding of the adaptation header may occur at the adaptation layer. By decoding the adaptation header, the adaptation layer of the incoming user protocol stack may be enabled to identify the bearer and / or next hop according to the UE-to-UE relay implementation. Additionally, the adaptation layer of the outgoing user protocol stack may be responsible for encoding corresponding information into the adaptation header of the second data packet to be sent according to the UE-to-UE relay functionality.

[0054] As shown with respect to relay UE 304, UEs (including, for example, source remote UE 302, relay UE 304, and / or destination remote UE 306) may use multiple instances of such user plane protocol stacks, some of which are used corresponding to incoming data packets and others of which are used corresponding to outgoing data packets. For example, some of these instances (such as incoming user protocol stack 320 and incoming user protocol stack 340) may be used to decode received data packets, while other instances (such as outgoing user protocol stack 308 and outgoing user protocol stack 330) are used to encode data packets to be transmitted.

[0055] UE-to-UE relay transmissions using layer 2 transmission according to embodiments herein may use PDCP bearers as end-to-end bearers. These end-to-end PDCP bearers may include DRBs and SRBs. As shown, transmissions from a source remote UE 302 via a relay UE 304 to a destination remote UE 306 according to UE-to-UE relay transmissions may use, for example, PDCP bearer 352 as an end-to-end bearer.

[0056] PDCP bearers 352 may include each of a first RLC bearer 354 traveling from source remote UE 302 to relay UE 304 and a second RLC bearer 356 traveling from destination remote relay UE 304 to PHY layer 310. First RLC bearer 354 and second RLC bearer 356 may be examples of direct bearers as described herein.

[0057] Although diagram 300 has been shown and described from the perspective of a source remote UE 302 transmitting data over UE-to-UE relay to a destination remote UE 306 via relay UE 304, it is contemplated that in many cases any of the UEs will be able to perform the functionality of any of the source remote UE 302, relay UE 304, and / or destination remote UE 306. Furthermore, although only a single relay UE is shown in diagram 300, it is contemplated that similar principles will apply to extending UE-to-UE relaying to use any number of relay UEs as described herein.

[0058] Figure 4 1 shows a first data packet 402 being sent between a source remote UE 302 and a relay UE 304 according to a UE-to-UE relay between the source remote UE 302 and the destination remote UE 306 according to an embodiment. The source remote UE 302, the relay UE 304, and the destination remote UE 306 (as well as the PDCP bearer 352, the first RLC bearer 354, and the second RLC bearer 356) may be the same as described above with respect to Figure 3 those discussed.

[0059] The first data packet 402 may include, among other things, a source UE layer 2 address 404. The source UE layer 2 address 404 may indicate the layer 2 address of the source remote UE 302. The first data packet 402 may also include a destination UE layer 2 address 406. The destination UE layer 2 address 406 may indicate the layer 2 address of the relay UE 304.

[0060] The first data packet 402 may also include a MAC PDU payload 408, which may include one or more MAC subheaders, such as the MAC subheader 410, and one or more RLC PDUs, such as the RLC PDU 412.

[0061] The MAC subheader 410 may include an LCID 414. The LCID 414 may be used to indicate QoS information to the relay UE 304. For example, if the LCID 414 has a specific value understood by the relay UE 304, the relay UE 304 may process the first data packet 402 with a specific QoS priority or treatment. In some embodiments, the LCID 414 may also include routing instructions used by the relay UE 304 to determine the identity of the destination remote UE 306 for routing purposes, as will be discussed in further detail below. It is contemplated that other MAC subheaders of the MAC PDU payload 408 may have similar content.

[0062] The RLC PDU 412 may be part of a packet that is conceptually “sent” on the first RLC bearer 354. For example, the RLC PDU 412 may be decoded at the RLC layer 326 of the relay UE 304.

[0063] The RLC PDU 412 may include an RLC header 416 .

[0064] In addition, the RLC PDU 412 may include an adaptation header 418. The adaptation header 418 may include routing information that is useful to the relay UE 304 in determining how to forward data from the first data packet 402 to the destination remote UE 306. For example, the adaptation header 418 may include the identity of an end-to-end bearer (e.g., PDCP bearer 352) between the source remote UE 302 and the destination remote UE 306. Additionally or alternatively, the adaptation header 418 may include a layer 2 address of the source remote UE 302. Additionally or alternatively, the adaptation header 418 may include a layer 2 address of the destination remote UE 306. Additionally or alternatively, the adaptation header 418 may include QoS information corresponding to the first data packet. Additionally or alternatively, the adaptation header 418 may include an index (sometimes referred to herein as a "local index") that can be used by the relay UE 304 to determine a bearer between the relay UE 304 and the destination remote UE 306 for forwarding data to the destination remote UE 306. The use of each of these types of routing information will be discussed in more detail below. As will be discussed below, when certain types of routing indications are possible in the LCID, the adaptation header 418 may not be used in some embodiments herein.

[0065] The RLC PDU 412 may also include a PDCP PDU 420. The PDCP PDU 420 may be part of a packet that is conceptually "sent" on the PDCP bearer 352. As shown, the PDCP PDU 420 may not be decoded at the relay UE 304 (because the relay UE 304 is not the ultimate destination of the PDCP PDU 420).

[0066] The PDCP PDU 420 may be or include data of interest that drives the use of UE-to-UE relaying provided by the relay UE 304 and is determined (e.g., by the source remote UE 302) to be delivered from the source remote UE 302 to the destination remote UE 306 in accordance with the UE-to-UE relaying provided between these devices by the relay UE 304. Figure 5 As shown, the PDCP PDU 420 may be forwarded by the relay UE 304 to the destination remote UE 306 .

[0067] Figure 5 306 according to an embodiment according to UE-to-UE relay between the source remote UE 302 and the destination remote UE 306, a second data packet 502 is shown being sent between the relay UE 304 and the destination remote UE 306. The source remote UE 302, the relay UE 304 and the destination remote UE 306 (as well as the PDCP bearer 352, the first RLC bearer 354 and the second RLC bearer 356) may be the same as described above with respect to Figure 3 those discussed.

[0068] The second data packet 502 may include, among other things, a source UE layer 2 address 504. The source UE layer 2 address 504 may indicate the layer 2 address of the relay UE 304. The second data packet 502 may also include a destination UE layer 2 address 506. The destination UE layer 2 address 506 may indicate the layer 2 address of the destination remote UE 306.

[0069] The second data packet 502 may also include a MAC PDU payload 508, which may include one or more MAC subheaders, such as the MAC subheader 510, and one or more RLC PDUs, such as the RLC PDU 512.

[0070] The MAC subheader 510 may include an LCID 514. The LCID 514 may have a value that indicates to the destination remote UE 306 that it is the final destination of the PDCP PDU 420 included in the second data packet 502, for example.

[0071] The RLC PDU 512 may be part of a packet that is conceptually "sent" on the second RLC bearer 356. For example, the RLC PDU 512 may be decoded at the RLC layer 346 of the destination remote UE 306.

[0072] The RLC PDU 512 mainly includes an RLC header 516 .

[0073] In addition, the RLC PDU 512 may include an adaptation header 518. The adaptation header 518 may include routing information that is useful for the destination remote UE 306 to determine that it is the final destination of, for example, the PDCP PDU 420 included in the second data packet 502. This will be discussed in further detail below. As will also be discussed, in some embodiments herein, the adaptation header 518 may not be used when certain types of routing indications are possible in the LCID.

[0074] The RLC PDU 512 may also include a PDCP PDU 420 (e.g., Figure 4 306). The PDCP PDU 420 may be a portion of a packet that is conceptually "sent" on the PDCP bearer 352. As discussed above, the PDCP PDU 420 may be or include data of interest that drives the use of UE-to-UE relaying provided by the relay UE 304 and is determined (e.g., by the source remote UE 302) to be delivered from the source remote UE 302 to the destination remote UE 306 in accordance with the UE-to-UE relay established between these devices by the relay UE 304. Because the destination remote UE 306 is the intended destination remote UE, the PDCP PDU 420 may be decoded at the PDCP layer 520 of the destination remote UE 306.

[0075] The solutions discussed herein may utilize an adaptation header, as introduced above, included in one or more data packets, which enables (in some cases, in conjunction with other information from the data packets, such as information found in the data packets' LCIDs) the UE-to-UE relay functionality described. Other solutions may avoid the adaptation header entirely and may be configured to include one or more routing indications, for example, in the LCIDs used for routing purposes. Any of these solutions may be used to provide a way for a source UE to inform a relay UE where to forward data packets (e.g., to which remote UE). In some embodiments, the use of the LCID to distinguish traffic to be forwarded to the (ultimate) destination remote UE from traffic to be passed up to the local PDCP entity may be avoided. For example, the adaptation header containing routing information may use a designated index value to mark packets for local processing. Alternatively or additionally, the adaptation header may include the Layer 2 address of the destination remote UE for the traffic. In these types of embodiments, the LCID may not indicate routing information, and the adaptation header is always used by the first remote UE for any outgoing traffic to direct the relay UE receiving that traffic on how to handle that traffic.

[0076] The first approach can utilize per-packet configuration by explicitly placing one or more Layer 2 addresses in the adaptation header. Under this approach, the UE can use PC5 QoS identifier (PQI) to SL Radio Bearer (SLRB) mapping to classify traffic into different logical channels. In some cases, separate LCID values ​​(even if corresponding to the same QoS priority or treatment) can be used to distinguish traffic terminated at the relay UE from traffic intended to be forwarded by the relay UE on the UE-to-UE relay provided by the relay UE.

[0077] Under the first approach, the adaptation header may be used to indicate QoS information and, in many cases, a relay destination. The relay destination may be the layer 2 address of the final destination remote UE.

[0078] For example, the QoS information may be end-to-end QoS information or residual QoS information. The end-to-end QoS information may indicate that specific data on a given end-to-end bearer of a UE-to-UE relay will be processed with a specific (static) QoS priority or treatment at each hop. The residual QoS information may be the sum of the remaining (unused) time remaining for delivering the data to the destination remote UE, and the residual QoS information may be updated at each hop of the UE-to-UE relay based on the amount of time it takes to make that hop.

[0079] Figure 6Various possible adaptation headers 600 that may be used according to some embodiments are shown. The possible adaptation headers 600 may be used as part of a first method. The possible adaptation headers 600 include a first-hop adaptation header format 602. The first-hop adaptation header format 602 may be sent from a source remote UE (or a previous relay UE) to a relay UE in a data packet containing data to be forwarded by the relay UE. The first-hop adaptation header format 602 includes a layer 2 destination address field 608, an end-to-end bearer ID field 610, and a QoS information field 612, each of which may be an example of routing information as discussed herein. A relay UE receiving the first-hop adaptation header format 602 may use the layer 2 destination address field 608 and the end-to-end bearer ID field 610 to identify how to forward data of interest (e.g., PDCP PDUs) from the received data packet on a corresponding outgoing data packet according to UE-to-UE relay. Additionally, the relay UE may use the QoS information field 612 to identify the QoS with which to transmit the corresponding outgoing data packet. In some embodiments, when the relay UE receives traffic from a previous relay UE, the first hop adaptation header may include the layer 2 address of the source remote UE. In some embodiments, when the relay UE receives traffic from a source remote UE, the first hop adaptation header may include the layer 2 source address of the source remote UE so that this information can be conveniently retrieved by the adaptation layer (rather than from the MAC header).

[0080] The possible adaptation header 600 includes a second-hop adaptation header format 604. The second-hop adaptation header format 604 can be sent from the relay UE to the destination remote UE in a data packet containing data of interest to be used at the destination remote UE (e.g., data in the PDCP PDU of the data packet). The second-hop adaptation header format 604 includes a layer 2 source address field 614 and an end-to-end bearer ID field 616, each of which can be an example of routing information as discussed herein. The layer 2 source address field 614 and the end-to-end bearer ID field 616 can be used by the destination remote UE to identify the UE from which the data of interest from the data packet to be used originated. The layer 2 destination address and / or QoS information fields may not be necessary in this case because the data of interest has already reached its destination. As discussed above, the destination remote UE can use the LCID to determine that the received data is for use at the destination remote UE (and not to be further relayed). Alternatively, another version of the second hop adaptation header format 604 may include a layer 2 destination address field (with the layer 2 address of the destination remote UE), which can then be used by the destination remote UE to determine that the received data is for use at the destination remote UE (and not further relayed).

[0081] The possible adaptation header 600 includes a unified adaptation header format 606. In some embodiments, it may be more straightforward to determine that a format according to the unified adaptation header format 606 is used in each data packet used in UE-to-UE relay (rather than distinguishing between the use cases of, for example, the first-hop adaptation header format 602 and the second-hop adaptation header format 604). Thus, the unified adaptation header format 606 includes all of the previously discussed fields of the possible adaptation header 600 in the adaptation header, including a layer 2 source address field 618, a layer 2 destination address field 620, an end-to-end bearer ID field 622, and a QoS information field 624 (each of which may be an example of routing information as discussed herein), each of which is used (where necessary) at each UE in the UE-to-UE relay.

[0082] Table 1

[0083]

[0084] Table 1 shows the functionality of the relay UE according to the first method just described. If the packet received at the relay UE does not include an adaptation header, the relay UE determines that it is the final destination of the data of interest (e.g., PDCP PDU) and passes the data packet containing the data to the PDCP layer of the relay UE for decoding and further use. In other cases, if the adaptation header includes a layer 2 destination address field and the value in the field is the layer 2 address of the relay UE, the relay UE determines that it is the final destination of the data of interest (e.g., PDCP PDU) and passes the data packet containing the data to the PDCP layer of the relay UE for decoding and further use.

[0085] In other cases, if the adaptation header includes a Layer 2 destination address field and the value in that field is the address of the destination remote UE, the relay UE can then use the address of the destination remote UE and the bearer ID value from the end-to-end bearer ID field to determine the PC5 link to forward the data of interest to the destination remote UE in a data packet that also includes the appropriate adaptation header (with appropriate routing information, as described above) formed by the relay UE for this purpose.

[0086] Note that because a pair of UEs may communicate using more than one end-to-end bearer, and because the end-to-end bearer ID may not be a global ID (but may be understood as an ID that is unique only between a given pair of UEs), it may be necessary to include both the end-to-end bearer ID field and the layer 2 address of one of the UEs in order to make a complete forwarding determination as described above.

[0087] It is contemplated that the adaptation header of the first method may be used in implementations involving more than one relay UE. In this case, an adaptation header in the first-hop adaptation header format 602 may be sent by each relay UE (except for the last relay UE, which may then send an adaptation header in the second-hop adaptation header format 604). In other such implementations, an adaptation header in the unified adaptation header format 606 may be used in each case. Furthermore, QoS information (e.g., remaining QoS information) may need to be updated in the manner described above to account for each hop.

[0088] The second method may be a per-bearer method that utilizes implicit indications based on a pre-established hop-by-hop path configuration. As described above, in order to use such a per-bearer implicit method, it may be necessary to first establish a hop-by-hop path configuration. The establishment of the hop-by-hop path configuration may correspond to performing the above-described Figure 2 The hop-by-hop path configuration 216 in question.

[0089] Using such an implicit per-bearer approach, possibly based on a hop-by-hop path configuration, can reduce the amount of data in the adaptation header (and therefore reduce the processing resources required to interpret and / or use such data) compared to an approach using one or more of the possible adaptation headers 600 according to the first approach. For example, in the second approach, the adaptation header may contain only an index value, as opposed to the (possibly large and multiple) values ​​discussed in the adaptation header according to the first approach (e.g., possible adaptation header 600).

[0090] A UE may need to send data in one or more data packets along the UE-to-UE relay, and these data packets may need to be sent according to a specific LCID (which may indicate the QoS priority or treatment of the packet). Each UE may check its current direct bearer (e.g., DRB) with the next UE in the UE-to-UE relay and determine whether a new direct bearer needs to be established (because no direct bearer currently exists between the UEs, or because the direct bearer established between the UEs does not have an appropriate LCID to meet the QoS priority or treatment of the data in question), or whether the current direct bearer will meet the requirements for that hop of the UE-to-UE relay for the data.

[0091] Figure 7 A method 700 for setting up a hop-by-hop path configuration from a source remote UE 702 to a destination remote UE 706 via a relay UE 704 is shown according to an embodiment. The method 700 includes performing a first PC5 link setup 708 and a second PC5 link setup 710. This can be performed in the same manner as, for example, performing Figure 2 The first PC5 link establishment 212 and the second PC5 link establishment 214 are completed in the above-mentioned manner.

[0092] The method 700 also includes sending a message 712 between the source remote UE 702 and the relay UE 704. The message 712 may be a SL configuration message, such as a "SidelinkReconfig" message or some other message configured to carry the indicated parameters. The parameters of the message 712 may include SLRB-config, which may indicate new bearer configuration information regarding a newly established direct bearer between the source remote UE 702 and the relay UE 704 (by the source remote UE 702). This parameter may be optional, as it may only be present if a new such direct bearer is being established (rather than an existing direct bearer between the source remote UE 702 and the relay UE 704 being reused, as described above) for use according to the hop-by-hop path configuration. The parameters of the message 712 also include an LCID, which corresponds to the QoS priority or treatment of data to be sent by the source remote UE 702 on the bearer, and may also be used (as described below) to identify data to the hop-by-hop path configuration. Message 712 also includes a destination address parameter that indicates to relay UE 704 the final destination (e.g., a destination remote UE) of data sent according to the hop-by-hop path configuration (e.g., using the layer 2 address of the final destination). Message 712 also includes an end-to-end bearer ID that indicates to relay UE 704 the end-to-end bearer corresponding to the hop-by-hop path configuration. Message 712 also includes a next-hop QoS that allows relay UE 704 to determine the QoS priority or treatment that should be given to data sent on the next hop according to the hop-by-hop path configuration. The next-hop QoS included in message 712 can be an explicit indication of the QoS priority or treatment that should be given to such data. Alternatively, the next-hop QoS included in message 712 can be an indication of a common (static) QoS priority or treatment that should be applied to all data on the hop-by-hop path configuration. Finally, message 712 can also include an index that can be used to uniquely identify a hop between source remote UE 702 and relay UE 704 within the hop-by-hop path configuration. In other words, the index uniquely identifies the use of the direct bearer as being within that particular hop-by-hop path configuration (as opposed to, for example, using the same direct bearer within a different hop-by-hop path configuration).

[0093] The method 700 also includes recording 714 at the relay UE 704 an end-to-end bearer ID corresponding to the hop-by-hop path configuration received in the message 712. The method 700 also includes recording 716 at the relay UE 704 a next-hop QoS requirement corresponding to the next hop of the hop-by-hop path configuration received in the message 712.

[0094] The method 700 also includes checking 718 any existing LCIDs of direct bearers between the relay UE 704 and the destination remote UE 706 to see if such bearers meet the next-hop QoS requirements of the configured hops of the hop-by-hop path between the relay UE 704 and the destination remote UE 706 .

[0095] The method 700 also includes sending a message 720 between the relay UE 704 and the destination remote UE 706. The message 720 may be a sidelink configuration message, such as a "SidelinkReconfig" message or some other message configured to carry the indicated parameters. The parameters of the message 720 may include SLRB-config, which may indicate new bearer configuration information for a newly established bearer (by the relay UE 704) between the relay UE 704 and the relay destination remote UE 706. This parameter may be optional, as it may only be present if a new such bearer is being established for use according to the hop-by-hop path configuration (rather than, for example, if the relay UE 704 instead decides to reuse an existing direct bearer between the relay UE 704 and the destination remote UE 706 if the LCID of the existing direct bearer meets the next-hop QoS requirement for that hop of the hop-by-hop path configuration, where the relay UE 704 checks the next-hop QoS requirement as described above in check 718). The parameters of message 720 also include an LCID, which corresponds to the QoS priority or treatment of data to be sent by relay UE 704 on the bearer, and will be further used (as described below) to identify data to the hop-by-hop path configuration. The LCID can be selected based on the next-hop QoS indicator received from the source remote UE 702. Message 720 also includes a destination address parameter, which indicates to the destination remote UE 706 the final destination of the data sent according to the hop-by-hop path configuration (for example, using the layer 2 address of the final destination of the data, which can be the layer 2 address of the destination remote UE 706). Message 720 also includes an end-to-end bearer ID, which indicates to the relay destination remote UE 706 the end-to-end bearer corresponding to the hop-by-hop path configuration. The end-to-end bearer ID is the same end-to-end bearer ID as the end-to-end bearer ID sent by the source remote UE 702 to the relay UE 704. Message 720 also includes a next-hop QoS that allows the destination remote UE 706 to determine the QoS priority or treatment that should be given to data sent on the next hop according to the hop-by-hop path configuration (in the case where the relay UE 704 is unaware that the destination remote UE 706 is the destination, but note that including this information would also be useful if the relay UE 704 instead sets up a hop-by-hop path configuration with another relay UE rather than the destination remote UE 706). The next-hop QoS included in message 720 can be an explicit indication of the QoS priority or treatment that should be given to such data. Alternatively, the next-hop QoS included in message 720 can be an indication of a general (static) QoS priority or treatment that should be used for all data on the hop-by-hop path configuration. Finally, message 720 can also include an index that can be used to uniquely identify a hop between the relay UE 704 and the destination remote UE 706 within the hop-by-hop path configuration.In other words, the index uniquely identifies the use of the direct bearer as being within that particular hop-by-hop path configuration (as opposed to, for example, using the same direct bearer within a different hop-by-hop path configuration). Because the index is local to the direct bearer for the relay UE 704 and the destination remote UE 706, the value of the index between the source remote UE 702 and the relay UE 704 is irrelevant.

[0096] To confirm the portion of the hop-by-hop path configuration between the relay UE 704 and the destination remote UE 706 that uses the direct bearer between the relay UE 704 and the destination remote UE 706, the destination remote UE 706 sends an SL reconfiguration complete message 722, such as a "SidelinkReconfigComplete" message or some other message. The message 722 may include an index identifying a hop of the hop-by-hop path configuration between the relay UE 704 and the destination remote UE 706.

[0097] Then, to confirm the establishment of the portion of the hop-by-hop path configuration between the source remote UE 702 and the relay UE 704 that uses the (other) direct bearer between the source remote UE 702 and the relay UE 704, the relay UE 704 sends an SL reconfiguration complete message 724, such as a "SidelinkReconfigComplete" message or some other message. The message 724 may include an (other) index identifying a hop of the hop-by-hop path configuration between the source remote UE 702 and the relay UE 704.

[0098] The method 700 also includes storing 726, at the relay UE 704, a correspondence or mapping between the indices (e.g., storing information that each of the indices discussed above is part of the same hop-by-hop path configuration); storing a relationship between each index and its corresponding LCID; storing a mapping between a layer 2 address of the source remote UE 702 and a layer 2 address of the destination remote UE 706 corresponding to the hop-by-hop path configuration; storing an end-to-end bearer ID corresponding to the hop-by-hop path configuration; and storing QoS information regarding one or both of the hops of the hop-by-hop path configuration.

[0099] Method 700 then continues with PC5 secure link establishment (end-to-end) 728, which may correspond to Figure 2 End-to-end PC5 link establishment (control plane) 218.

[0100] It is contemplated that method 700 can be expanded to include multiple relay UEs (not just relay UE 704). In these instances, each relay UE can receive a message similar to message 712 from a previous UE in the UE-to-UE relay; perform operations similar to recording 714, recording 716, and checking 718; send a message similar to message 720 to the next UE in the UE-to-UE relay; receive a message similar to message 722 from the next UE in the UE-to-UE relay; send a message similar to message 724 back to the previous UE in the UE-to-UE relay; and perform operations similar to storing 726.

[0101] It is also contemplated that similar information as sent in messages 712 and 720 may be sent back on messages 722 and 724 (e.g., SL configuration messages such as the illustrated "SidelinkReconfig" messages of messages 712 and 720 may be sent on messages 722 and 724, possibly with additional confirmation signaling subsequently added to method 700). This may allow for configuration of a second hop-by-hop path configuration, as opposed to a first configuration that used only a single messaging approach. For example, Figure 7 In the illustrated method 700, data forwarding setup is supported for a directional end-to-end PDCP bearer from the source remote UE 702 to the destination remote UE 706. If another directional bearer exists from the destination remote UE 706 to the source remote UE 702, a similar set of configuration parameters may be included in a "SidelinkReconfigComplete" message or any other type of message used for a similar purpose. Data forwarding setup may then be achieved for traffic in both directions between the source remote UE 702 and the destination remote UE 706 with a single round trip.

[0102] It is also contemplated that multiple hop-by-hop path configurations may be implemented in one messaging round trip by including a copy of the discussed information (relative to each individual hop-by-hop path configuration) in each of messages 712, 720, 722, and 724. For example, if there are multiple end-to-end PDCP bearers to be established from the source remote UE 702 to the destination remote UE 706, then an array of configurations, one for each of the multiple PDCP bearers, may be included in the "SidelinkReconfig" message, or any other type of message used for a similar purpose.

[0103] Once the hop-by-hop path configuration as described above is set up, a per-bearer implicit approach for UE-to-UE relays can be implemented. In this approach, the LCID value placed in the data packet can be used to distinguish between data packets that terminate at the receiving UE and any data packets that are to be forwarded to, for example, a destination remote UE or another relay UE. This means that there may be multiple LCID values ​​available for a single QoS priority or treatment, one of which is used to indicate a data packet that terminates at the receiving UE and another of which is used to indicate that the data packet is to be forwarded along the UE-to-UE relay. Under this approach, the UE can use the PQI to SLRB mapping to classify traffic into different logical channels.

[0104] The index value of the particular hop used in the particular hop-by-hop path configuration used is placed into the adaptation header of the data packet to be sent.

[0105] Once received at the receiving UE, the sending UE's LCID value, index value, and layer 2 source address (from, for example, the MAC header, as in Figure 4 The source UE layer 2 address 404 and Figure 5 The source UE layer 2 address 504) is used at each receiving UE on the UE-to-UE relay (whether it is a relay UE or a destination remote UE) to determine the necessary forwarding configuration (or not) for the data of interest in the received data packets.

[0106] Figure 8 FIG800 is a diagram illustrating the use of a data forwarding method per bearer method according to some embodiments. FIG800 includes a first remote UE 802 ( Figure 8 , UE 1), relay UE 804 (in Figure 8 , a second remote UE 806 (labeled as "UE 2" in Figure 8 ) and a third remote UE 808 (labeled as "UE 3" in Figure 8 806). A first hop-by-hop path configuration 810 has been established between a first remote UE 802 and a relay UE 804. A second hop-by-hop path configuration 812 has been established between the first remote UE 802 and the second remote UE 806. A third hop-by-hop path configuration 814 has been established between the first remote UE 802 and the second remote UE 806. A fourth hop-by-hop path configuration 816 has been established between the third remote UE 808 and the second remote UE 806. Each of these hop-by-hop path configurations can be configured using the configurations described above with respect to Figure 7 The disclosed method is established.

[0107] Table 2

[0108]

[0109] Table 2 shows the incoming and outgoing processing of the data of interest in the data packets received at the relay UE 804. For example, if a data packet with a specific LCID (e.g., LCID=0) indicating that the data is not forwarded is received, the data of interest is decoded by the PDCP layer of the relay UE 804. This is applied to Figure 8 The first row of Table 2 of the first hop-by-hop path configuration 810 .

[0110] In other cases, a data packet may be received at a relay UE 804 that includes an LCID (e.g., LCID≠0) indicating that data of interest should be forwarded and an index in the adaptation header corresponding to a specific hop in a specific hop-by-hop path configuration used to transmit the data packet. The relay UE 804 may then refer to the index and LCID stored during the setup of the specific hop-by-hop path configuration to identify the hop-by-hop path configuration corresponding to the received data packet, and further determine that the data of interest from the data packet should be encapsulated into another (outgoing) data packet and transmitted on the next hop of the specific hop-by-hop path configuration (according to its corresponding index). Accordingly, the relay UE 804 may generate a data packet containing the data of interest, the data of interest including the LCID and an index value in the adaptation header corresponding to the next hop in the specific hop-by-hop path configuration determined during the setup of the hop-by-hop path configuration. The data packet may then be transmitted by the relay UE 804 on a direct bearer corresponding to the specific hop of the specific hop-by-hop path configuration.

[0111] For example, as shown in the second row of Table 2, the relay UE 804 may receive a data packet with LCID=1 and index (from the adaptation header)=1 from the first remote UE 802. This may correspond to an incoming hop of the second hop-by-hop path configuration 812, which is mapped to an outgoing hop of the second hop-by-hop path configuration 812, which sends the data of interest to the second remote UE 806 using the mapped direct bearer with LCID=1 and index (in the adaptation header)=5. Therefore, the relay UE 804 prepares the corresponding data packet, places the data of interest therein, and forwards it to the second remote UE 806 on the mapped direct bearer.

[0112] As another example, as in the third row of Table 2, the relay UE 804 may receive a data packet with LCID=2 and index (from the adaptation header)=2 from the first remote UE 802. This may correspond to an incoming hop of the third hop-by-hop path configuration 814, which is mapped to an outgoing hop of the third hop-by-hop path configuration 814, which sends the data of interest to the second remote UE 806 using a mapped direct bearer with LCID=1 and index (in the adaptation header)=5. Therefore, the relay UE 804 prepares a corresponding data packet, places the data of interest therein, and forwards it to the second remote UE 806 on the mapped direct bearer.

[0113] As another example, as in the fourth row of Table 2, the relay UE 804 may receive a data packet with LCID=4 and index (from the adaptation header)=1 from the third remote UE 808. This may correspond to an incoming hop of the fourth hop-by-hop path configuration 816, which is mapped to an outgoing hop of the fourth hop-by-hop path configuration 816, which sends the data of interest to the second remote UE 806 using the mapped direct bearer with LCID=3 and index (in the adaptation header)=1. Therefore, the relay UE 804 prepares the corresponding data packet, places the data of interest therein, and forwards it to the second remote UE 806 on the mapped direct bearer.

[0114] It is envisaged that embodiments according to this second method may be extended to include devices other than UEs, such as base stations (in which case the method would be considered to function in a UE-to-NW relay context).

[0115] The third approach may also be a per-bearer approach that utilizes implicit indications based on a pre-established hop-by-hop path configuration. The third approach may differ from the second approach because, in at least some cases, there may be a sufficiently wide range of LCID values ​​available for use so that the LCID values ​​themselves can be configured to provide routing indications (without interfering with the necessary communication of QoS information in the LCID values ​​within the wireless communication system). This may be the case when there are not many UEs involved in UE-to-UE relay operations within the wireless communication system. In this case, an index may not be needed (because the LCID values ​​can make a similar indication), and therefore an adaptation header may not be needed and can be omitted, thereby granting an even further gain to signaling efficiency.

[0116] A UE may need to send data in one or more data packets along the UE-to-UE relay, and these data packets may need to be sent according to a specific LCID (which may indicate the QoS priority or treatment of the packet). Each UE may check its current direct bearer (e.g., DRB) with the next UE in the UE-to-UE relay and determine whether a new direct bearer needs to be established (because there is no established direct bearer or because the established direct bearer does not have an appropriate LCID to meet the QoS priority or treatment of the data in question) or whether the current direct bearer will meet the requirements for that hop of the UE-to-UE relay for the data.

[0117] Figure 9 A method 900 for setting up a hop-by-hop path configuration from a source remote UE 902 to a destination remote UE 906 via a relay UE 904 is shown according to an embodiment. The method 900 includes performing a first PC5 link setup 908 and a second PC5 link setup 910. This can be performed in the same manner as, for example, performing Figure 2 The first PC5 link establishment 212 and the second PC5 link establishment 214 are completed in the above-mentioned manner.

[0118] Method 900 also includes sending a message 912 between source remote UE 902 and relay UE 904. Message 912 may be a SL configuration message, such as a "SidelinkReconfig" message, or some other message configured to carry the indicated parameters. Parameters of message 912 may include SLRB-config, which may indicate new bearer configuration information for a newly established direct bearer between source remote UE 902 and relay UE 904 (by source remote UE 902). This parameter may be optional, as it may only be present if a new such direct bearer is being established (rather than reusing an existing direct bearer between source remote UE 902 and relay UE 904, as described above) for use according to the hop-by-hop path configuration. Parameters of message 912 may also include an LCID, which corresponds to the QoS priority or treatment to which the source remote UE 902 will transmit data on the direct bearer. The LCID may also provide (e.g., due to the particular value of the selected LCID) a routing indication for instructing relay UE 904 to identify the next direct bearer corresponding to the hop-by-hop path configuration. Message 912 also includes a destination address parameter that indicates to relay UE 904 the final destination (e.g., a destination remote UE) of data sent according to the hop-by-hop path configuration (e.g., using the layer 2 address of the final destination). Message 912 also includes an end-to-end bearer ID that indicates to relay UE 904 the end-to-end bearer corresponding to the hop-by-hop path configuration. Message 912 also includes a next-hop QoS that allows relay UE 904 to determine the QoS priority or treatment that should be given to data sent on the next hop according to the hop-by-hop path configuration. The next-hop QoS included in message 912 can be an explicit indication of the QoS priority or treatment that should be given to such data. Alternatively, the next-hop QoS included in message 912 can be an indication of a common (static) QoS priority or treatment that should be used for all data on the hop-by-hop path configuration.

[0119] The method 900 also includes recording 914, at the relay UE 904, an end-to-end bearer ID corresponding to the hop-by-hop path configuration received in the message 912. The method 900 also includes recording 916, at the relay UE 904, an LCID corresponding to the previous hop of the hop-by-hop path configuration received in the message 912. The method 900 also includes recording 918, at the relay UE 904, a next-hop QoS requirement corresponding to the next hop of the hop-by-hop path configuration received in the message 912. The method 900 also includes selecting a new LCID for the next hop that meets the next-hop QoS requirement (and, if necessary, selecting a new SLRB configuration for a direct bearer for the next hop that meets the LCID, if such a direct bearer between the relay UE 904 and the destination remote UE 906 does not already exist; otherwise, an existing direct bearer that meets the LCID may be used instead).

[0120] Method 900 also includes sending a message 922 between relay UE 904 and destination remote UE 906. Message 922 may be a sidelink configuration message, such as a "SidelinkReconfig" message or some other message configured to carry the indicated parameters. Parameters of message 922 may include SLRB-config, which may indicate new bearer configuration information for a newly established bearer (by relay UE 904) between relay UE 904 and relay destination remote UE 906. This parameter may be optional, as it may only be present if a new such direct bearer is being established for use according to the hop-by-hop path configuration (rather than, for example, if the LCID of the existing direct bearer satisfies the next-hop QoS requirement for that hop of the hop-by-hop path configuration, where relay UE 904 checks the next-hop QoS requirement as described above in selecting 920). The parameters of message selection 920 also include an LCID, which corresponds to the QoS priority or treatment of the data to be sent by the relay UE 704 on the bearer. The LCID can be selected based on the next-hop QoS indicator received from the source remote UE 902. The LCID can also provide (e.g., due to the specific value of the selected LCID) a parameter for indicating that the destination remote UE 906 is sufficient to identify the data to the hop-by-hop path configuration. The message 922 also includes a destination address parameter, which indicates to the destination remote UE 906 the final destination of the data sent according to the hop-by-hop path configuration (e.g., using the layer 2 address of the final destination of the data, which can be the layer 2 address of the destination remote UE 906). The message 922 also includes an end-to-end bearer ID, which indicates to the destination remote UE 906 the end-to-end bearer corresponding to the hop-by-hop path configuration. The end-to-end bearer ID is the same end-to-end bearer ID as the end-to-end bearer ID sent by the source remote UE 902 to the relay UE 904. Message 912 also includes Next Hop QoS, which allows relay UE 904 to determine the QoS priority or treatment that should be given to data sent on the next hop according to the hop-by-hop path configuration (in the case where relay UE 904 is unaware that destination remote UE 906 is the destination, but note that this information will also be useful if relay UE 904 instead sets up a hop-by-hop path configuration with another relay UE rather than destination remote UE 906). The Next Hop QoS included in message 912 can be an explicit indication of the QoS priority or treatment that should be given to such data. Alternatively, the Next Hop QoS included in message 912 can be an indication of a general (static) QoS priority or treatment that should be used for all data on the hop-by-hop path configuration.

[0121] To confirm the portion of the hop-by-hop path configuration between relay UE 904 and destination remote UE 906 using the direct bearer between relay UE 904 and destination remote UE 906, destination remote UE 906 sends an SL reconfiguration complete message 924, such as a "SidelinkReconfigComplete" message or some other message.

[0122] Then, to confirm the establishment of the portion of the hop-by-hop path configuration between the source remote UE 902 and the relay UE 904 using the (other) direct bearer between the source remote UE 902 and the relay UE 904, the relay UE 904 sends an SL reconfiguration completion message 926, such as a "SidelinkReconfigComplete" message or some other message.

[0123] The method 900 also includes maintaining 928 a correspondence or mapping between LCID pairs at the relay UE 904; storing a mapping between a layer 2 address of the source remote UE 902 and a layer 2 address of the destination remote UE 906 corresponding to the hop-by-hop path configuration; storing an end-to-end bearer ID corresponding to the hop-by-hop path configuration; and storing QoS information for one or both of the hops of the hop-by-hop path configuration.

[0124] Method 900 then proceeds to perform PC5 secure link establishment (end-to-end) 930, which may correspond to Figure 2 End-to-end PC5 link establishment (control plane) 218.

[0125] It is contemplated that method 900 can be expanded to include multiple relay UEs (not just relay UE 904). In these instances, each relay UE can receive a message similar to message 912 from the previous UE in the UE-to-UE relay; perform operations similar to record 914, record 916, record 918, and select 920; send a message similar to message 922 to the next UE in the UE-to-UE relay; receive a message similar to message 924 from the next UE in the UE-to-UE relay; and send a message similar to message 926 back to the previous UE in the UE-to-UE relay and perform operations similar to hold 928.

[0126] It is also contemplated that similar information as sent in message 912 and log message 922 may be sent back on messages 924 and 926 (e.g., SL configuration messages such as the illustrated “SidelinkReconfig” messages of messages 912 and 922 may be sent on messages 924 and 926, possibly with additional confirmation signaling subsequently added to method 900). This may allow for configuration of a second hop-by-hop path configuration, as opposed to the first configuration using only a single messaging approach.

[0127] It is also contemplated that multiple hop-by-hop path configurations may be implemented in one messaging round trip by including a copy of the discussed information in each of messages 912, 922, 924, and 926 (relative to each individual hop-by-hop path configuration).

[0128] Once the hop-by-hop path configuration described above is established, a per-bearer implicit approach for UE-to-UE relaying can be implemented. In this approach, the LCID value within the received data packet can provide a routing indication that can be used to distinguish between data packets that terminate at the receiving UE and any data packets to be forwarded, for example, to a destination remote UE or another relay UE. This routing indication under the third approach can also distinguish between direct bearers used at the next hop of the hop-by-hop path configuration.

[0129] Once received at the receiving UE, the LCID value and layer 2 source address of the sending UE (from, for example, the MAC header, as in Figure 4 The source UE layer 2 address 404 and Figure 5 The source UE layer 2 address 504) is used at each receiving UE on the UE-to-UE relay (whether it is a relay UE or a destination remote UE) to determine the necessary forwarding configuration (or not) for the data of interest in the received data packets.

[0130] Figure 10 FIG1000 is a diagram illustrating the use of a data forwarding method per bearer method according to some embodiments. FIG1000 includes a first remote UE 1002 ( Figure 10 1), relay UE 1004 (in Figure 10 , a second remote UE 1006 (labeled as "UE2" in Figure 10 3), a third remote UE 1008 (labeled as "UE 3" in Figure 10 ) and a fourth remote UE 1010 (labeled as "UE4" in Figure 10 5). A first hop-by-hop path configuration 1012 has been established between a first remote UE 1002 and a relay UE 1004. A second hop-by-hop path configuration 1014 has been established between the first remote UE 1002 and a second remote UE 1006. A third hop-by-hop path configuration 1016 has been established between a third remote UE 1008 and a second remote UE 1006. A fourth hop-by-hop path configuration 1018 has been established between the first remote UE 1002 and a fourth remote UE 1010. Each of these hop-by-hop path configurations may be configured using the configurations described above with respect to Figure 9 The disclosed method is established.

[0131] Table 3

[0132]

[0133] Table 2 shows the incoming and outgoing processing of the data of interest in the data packets received at the relay UE 1004. For example, if a data packet is received with an LCID (e.g., LCID=0) that provides a routing indication that the data of interest is not to be forwarded, the data of interest is decoded by the PDCP layer of the relay UE 1004. This is applied to Figure 10 The first hop-by-hop path configuration diagram 1000 is shown in the first row of Table 2.

[0134] In other cases, a data packet with an LCID that provides a routing indication that data of interest in the data packet needs to be forwarded can be received at the relay UE 1004. The relay UE 1004 can then refer to the LCID saved during the setup of the particular hop-by-hop path configuration to identify the hop-by-hop path configuration corresponding to the received data packet, and further determine that the data of interest from the data packet should be encapsulated into another (outgoing) data packet and sent on the next hop of the particular hop-by-hop path configuration. Thus, the relay UE 1004 can generate a data packet containing the data of interest, the data of interest containing the LCID corresponding to the next hop in the particular hop-by-hop path configuration determined during the setup. The data packet is then sent by the relay UE 1004 on the bearer corresponding to the particular hop of the particular hop-by-hop path configuration.

[0135] For example, as shown in the second row of Table 2, the relay UE 1004 may receive a data packet with LCID=x from the first remote UE 1002. This may correspond to an incoming hop of the second hop-by-hop path configuration 1014, which is mapped to an outgoing hop of the second hop-by-hop path configuration 1014, which uses the mapped direct bearer with LCID y to send the data of interest to the second remote UE 1006. Therefore, the relay UE 1004 prepares a corresponding data packet, places the data of interest therein, and forwards it to the second remote UE 1006 on the mapped direct bearer.

[0136] As another example, as shown in the third row of Table 2, the relay UE 1004 may receive a data packet with LCID=p from the third remote UE 1008. This may correspond to an incoming hop of the third hop-by-hop path configuration 1016, which is mapped to an outgoing hop of the third hop-by-hop path configuration 1016, which uses the mapped direct bearer with LCID q to send the data of interest to the second remote UE 1006. Therefore, the relay UE 1004 prepares the corresponding data packet, places the data of interest therein, and forwards it to the second remote UE 1006 on the mapped direct bearer.

[0137] As another example, as shown in the fourth row of Table 2, the relay UE 1004 may receive a data packet with LCID=u from the first remote UE 1002. This may correspond to an incoming hop of the fourth hop-by-hop path configuration 1018, which is mapped to an outgoing hop of the fourth hop-by-hop path configuration 1018, which uses the mapped direct bearer with LCID=i to send data of interest to the fourth remote UE 1010. Therefore, the relay UE 1004 prepares a corresponding data packet, places the data of interest therein, and forwards it to the fourth remote UE 1010 on the mapped direct bearer.

[0138] It is envisaged that embodiments according to this third method may be extended to include devices other than UEs, such as base stations (in which case the method would be considered to function in a UE-to-NW relay context).

[0139] Figure 11 A method 1100 of a relay UE according to an embodiment is shown. The method 1100 includes receiving 1102 a data packet from a first remote UE including an RLC PDU including a PDCP PDU and a first adaptation header having first routing information.

[0140] The method 1100 also includes decoding 1104 first routing information from the first adaptation header at an adaptation layer of a relay UE between the RLC layer of the UE and the PDCP layer of the UE.

[0141] The method 1100 also includes determining 1106 that the PDCP PDU should be forwarded to a second remote UE based on the first routing information.

[0142] The method 1100 also includes generating 1108 a second packet including the PDCP PDU.

[0143] The method 1100 also includes forwarding the second packet to a second remote UE.

[0144] Figure 12A method 1200 of a relay UE according to an embodiment is shown. The method 1200 includes receiving 1202 a data packet from a first remote UE including an LCID and an RLC PDU including a PDCP PDU and a first adaptation header with first routing information.

[0145] The method 1200 also includes decoding 1204 first routing information from the first adaptation header at an adaptation layer of a relay UE between the RLC layer of the UE and the PDCP layer of the UE.

[0146] The method 1200 also includes determining 1206 that the PDCP PDU should be forwarded to a second remote UE based on the LCID and the first routing information.

[0147] The method 1200 also includes generating 1208 a second packet including the PDCP PDU.

[0148] The method 1200 also includes identifying 1210 a bearer between the relay UE and the second remote UE for forwarding the PDCP PDU to the second remote UE based on an index located in the first routing information; wherein the second packet is forwarded to the second remote UE using the bearer.

[0149] The method 1200 also includes forwarding 1212 the second packet to a second remote UE.

[0150] Figure 13 A method 1300 of a relay UE according to an embodiment is shown. The method 1300 includes receiving 1302 a data packet from a first remote UE, the data packet including a MAC header, an LCID including a routing indication, and an RLC PDU including a PDCP PDU.

[0151] The method 1300 also includes determining 1304 that the PDCP PDU should be forwarded to a second remote UE based on the routing indication of the LCID and the layer 2 address provided in the MAC header.

[0152] The method 1300 also includes generating 1306 a second packet including the PDCP PDU.

[0153] The method 1300 also includes identifying 1308 a bearer between the relay UE and the second remote UE for forwarding the PDCP PDU to the second remote UE based on the routing indication in the LCID; wherein the second packet is forwarded to the second remote UE using the bearer.

[0154] The method 1300 also includes forwarding 1310 the second packet to a second remote UE.

[0155] Figure 14A method 1400 of a relay UE for establishing a hop-by-hop path configuration according to an embodiment is shown. The method 1400 includes receiving 1402 a first SL configuration message corresponding to a first bearer between the first remote UE and the relay UE from a first remote UE, the first SL configuration message including a first LCID, a first layer-2 address, an end-to-end bearer ID, a next-hop QoS indicator, and a first index.

[0156] The method 1400 also includes generating 1404 a second SL configuration message corresponding to a second bearer between the relay UE and the second remote UE, the second SL configuration message including a second LCID, a second layer 2 address, an end-to-end bearer ID, and a second index.

[0157] The method 1400 also includes sending 1406 a second SL configuration message to a second remote UE.

[0158] The method 1400 also includes receiving 1408 a first SL reconfiguration complete message including a second index from a second remote UE.

[0159] The method 1400 also includes sending 1410 a second SL reconfiguration complete message including the first index to the first remote UE.

[0160] Figure 15 A method 1500 for a relay UE to establish a hop-by-hop path configuration according to an embodiment is shown. The method 1500 includes receiving 1502 a first SL configuration message corresponding to a first bearer between the first remote UE and the relay UE from a first remote UE, the first SL configuration message including a first LCID configured to provide routing indications, a first layer-2 address, an end-to-end bearer ID, and a next-hop QoS indicator.

[0161] The method 1500 also includes generating 1504 a second SL configuration message corresponding to a second bearer between the relay UE and the second remote UE, the second SL configuration message including a second LCID configured to provide routing indications, a second layer 2 address, and an end-to-end bearer ID.

[0162] The method 1500 also includes sending 1506 a second SL configuration message to a second remote UE.

[0163] The method 1500 also includes receiving 1508 a first SL reconfiguration complete message from the second remote UE.

[0164] The method 1500 also includes sending 1510 a second SL reconfiguration complete message to the first remote UE.

[0165] Figure 1616 is a block diagram of an exemplary UE 1600 that can be configured according to various embodiments of the present disclosure, including by executing instructions corresponding to any of the exemplary methods and / or processes described herein on a computer-readable medium. The UE 1600 includes one or more processors 1602, a transceiver 1604, a memory 1606, a user interface 1608, and a control interface 1610.

[0166] The one or more processors 1602 may include, for example, an application processor, an audio digital signal processor, a central processing unit, and / or one or more baseband processors. Each of the one or more processors 1602 may include internal memory and / or may include an interface for communicating with external memory (including memory 1606). The internal or external memory may store software code, programs, and / or instructions for execution by the one or more processors 1602 to configure and / or facilitate the UE 1600 to perform various operations, including the operations described herein. For example, execution of the instructions may configure the UE 1600 to communicate using one or more wired or wireless communication protocols, including one or more wireless communication protocols standardized by 3GPP, such as those commonly referred to as 5G / NR, LTE, LTE-A, UMTS, HSPA, GSM, GPRS, EDGE, etc., or any other current or future protocol that may be used in conjunction with the one or more transceivers 1604, the user interface 1608, and / or the control interface 1610. As another example, the one or more processors 1602 may execute program code stored in the memory 1606 or other memory corresponding to the MAC, RLC, PDCP, and RRC layer protocols standardized by 3GPP (e.g., for NR and / or LTE). As yet another example, the processor 1602 may execute program code stored in the memory 1606 or other memory that, together with the one or more transceivers 1604, implements corresponding PHY layer protocols such as orthogonal frequency division multiplexing (OFDM), orthogonal frequency division multiple access (OFDMA), and single carrier frequency division multiple access (SC-FDMA).

[0167] The memory 1606 may include a memory area for one or more processors 1602 to store variables used in protocols, configurations, controls, and other functions of the UE 1600 (including operations corresponding to or including any of the exemplary methods and / or processes described herein). In addition, the memory 1606 may include non-volatile memory (e.g., flash memory), volatile memory (e.g., static or dynamic RAM), or a combination thereof. In addition, the memory 1606 may interact with a memory slot through which removable memory cards of one or more formats (e.g., SD card, memory stick, compact flash, etc.) may be inserted and removed.

[0168] One or more transceivers 1604 may include radio frequency transmitter and / or receiver circuitry that facilitates communication between the UE 1600 and other equipment supporting similar wireless communication standards and / or protocols. For example, one or more transceivers 1604 may include switches, mixer circuitry, amplifier circuitry, filter circuitry, and synthesizer circuitry. Such RF circuitry may include a receive signal path having circuitry for downconverting RF signals received from a front-end module (FEM) and providing the baseband signal to a baseband processor of the one or more processors 1602. The RF circuitry may also include a transmit signal path having circuitry for upconverting the baseband signal provided by the baseband processor and providing an RF output signal to the FEM for transmission. The FEM may include a receive signal path having circuitry configured to operate on RF signals received from one or more antennas, amplify the received signals, and provide the amplified versions of the received signals to the RF circuitry for further processing. The FEM may also include a transmit signal path having circuitry configured to amplify transmit signals provided by the RF circuitry for transmission via the one or more antennas. In various embodiments, amplification through the transmit or receive signal path may be accomplished in only the RF circuitry, only the FEM, or in both the RF circuitry and the FEM circuitry. In some embodiments, the FEM circuitry may include a TX / RX switch to switch between transmit and receive mode operation.

[0169] In some exemplary embodiments, the one or more transceivers 1604 include transmitters and receivers that enable the device 1200 to communicate with various 5G / NR networks according to various protocols and / or methods proposed for standardization by 3GPP and / or other standards bodies. For example, such functionality may operate in cooperation with the one or more processors 1602 to implement a PHY layer based on OFDM, OFDMA, and / or SC-FDMA techniques, such as described herein with reference to other figures.

[0170] User interface 1608 may take various forms depending on the particular embodiment, or may not be present in UE 1600. In some embodiments, user interface 1608 includes a microphone, a speaker, a slidable button, a depressible button, a display, a touchscreen display, a mechanical or virtual keypad, a mechanical or virtual keyboard, and / or any other user interface features typically present on mobile phones. In other embodiments, UE 1600 may comprise a tablet computing device with a larger touchscreen display. In such embodiments, one or more of the mechanical features of user interface 1608 may be replaced with comparable or functionally equivalent virtual user interface features (e.g., a virtual keypad, virtual buttons, etc.) implemented using a touchscreen display, as will be familiar to those skilled in the art. In other embodiments, UE 1600 may be a digital computing device, such as a laptop computer, desktop computer, workstation, etc., that includes a mechanical keyboard, which may be integrated, detachable, or removable, depending on the particular exemplary embodiment. Such digital computing devices may also include a touchscreen display. Many exemplary embodiments of UE 1600 with a touchscreen display are capable of receiving user input, such as input related to the exemplary methods and / or processes described herein or known to those skilled in the art.

[0171] In some exemplary embodiments of the present disclosure, UE 1600 includes an orientation sensor that can be used in various ways by the features and functions of UE 1600. For example, UE 1600 can use the output of the orientation sensor to determine when a user has changed the physical orientation of the touch screen display of UE 1600. The indication signal from the orientation sensor can be used for any application executed on UE 1600, so that the application can automatically change the orientation of the screen display (e.g., from portrait to landscape) when the indication signal indicates an approximately 90-degree change in the physical orientation of the device. In this way, regardless of the physical orientation of the device, the application can maintain the screen display in a user-readable manner. In addition, the output of the orientation sensor can be used in conjunction with various exemplary embodiments of the present disclosure.

[0172] The control interface 1610 can take various forms depending on the particular implementation. For example, the control interface 1610 can include an RS-232 interface, an RS-485 interface, a USB interface, an HDMI interface, a Bluetooth interface, an IEEE ("FireWire") interface, an I 2 C interface, PCMCIA interface, etc. In some exemplary embodiments of the present disclosure, the control interface 1260 may include an IEEE 802.3 Ethernet interface, such as described above. In some exemplary embodiments of the present disclosure, the control interface 1610 may include an analog interface circuit, which includes, for example, one or more digital-to-analog (D / A) converters and / or analog-to-digital (A / D) converters.

[0173] One of ordinary skill in the art will recognize that the above list of features, interfaces, and radio frequency communication standards is merely exemplary and does not limit the scope of the present disclosure. Figure 16 The UE 1600 may include further functionality, including, for example, a video and / or still image camera, a microphone, a media player and / or recorder, and the like. Furthermore, the one or more transceivers 1604 may include circuitry for communicating using additional radio frequency communication standards, including Bluetooth, GPS, and / or others. Furthermore, the one or more processors 1602 may execute software code stored in the memory 1606 to control such additional functionality. For example, the directional velocity and / or position estimate output from the GPS receiver may be used by any application executing on the UE 1600, including various exemplary methods and / or computer-readable media according to various exemplary embodiments of the present disclosure.

[0174] Figure 17 is a block diagram of an exemplary network node 1700 configurable according to various embodiments of the present disclosure, including by executing instructions on a computer-readable medium corresponding to any of the exemplary methods and / or processes described herein.

[0175] The network node 1700 includes one or more processors 1702, a radio network interface 1704, a memory 1706, a core network interface 1708, and other interfaces 1710. The network node 1700 may comprise, for example, a base station, an eNB, a gNB, an access node, or components thereof.

[0176] The one or more processors 1702 may include any type of processor or processing circuit and may be configured to perform any of the methods or processes disclosed herein. The memory 1706 may store software code, programs, and / or instructions executed by the one or more processors 1702 to configure the network node 1700 to perform various operations, including the operations described herein. For example, the execution of such stored instructions may configure the network node 1700 to communicate with one or more other devices using protocols according to various embodiments of the present disclosure (including one or more methods and / or processes described above). In addition, the execution of such stored instructions may also configure and / or facilitate the network node 1700 to communicate with one or more other devices using other protocols or protocol layers (such as one or more of the PHY, MAC, RLC, PDCP, and RRC layer protocols standardized by 3GPP for LTE, LTE-A, and / or NR, or any other higher layer protocols used in conjunction with the radio network interface 1704 and the core network interface 1708). By way of example and not limitation, the core network interface 1708 includes an S1 interface, and the radio network interface 1704 may include a Uu interface, such as standardized by 3GPP. The memory 1706 may also store variables used in protocols, configuration, control, and other functions of the network node 1700. Thus, the memory 1706 may include non-volatile memory (e.g., flash memory, hard disk, etc.), volatile memory (e.g., static or dynamic RAM), network-based (e.g., "cloud") storage, or a combination thereof.

[0177] The radio network interface 1704 may include a transmitter, a receiver, a signal processor, an ASIC, an antenna, a beamforming unit, and other circuits that enable the network node 1700 to communicate with other equipment (in some embodiments, such as multiple compatible UEs). In some embodiments, the network node 1700 may include various protocols or protocol layers, such as PHY, MAC, RLC, PDCP, and RRC layer protocols standardized by 3GPP for LTE, LTE-A, and / or 5G / NR. According to another embodiment of the present disclosure, the radio network interface 1704 may include a PHY layer based on OFDM, OFDMA, and / or SC-FDMA technology. In some embodiments, the functionality of such a PHY layer may be provided collaboratively by the radio network interface 1704 and one or more processors 1702.

[0178] The core network interface 1708 may include transmitters, receivers, and other circuits that enable the network node 1700 to communicate with other equipment in the core network (in some embodiments, such as a circuit-switched (CS) and / or packet-switched core (PS) network). In some embodiments, the core network interface 1708 may include an S1 interface standardized by 3GPP. In some embodiments, the core network interface 1708 may include one or more interfaces to one or more SGWs, MEEs, SGSNs, GGSNs, and other physical devices, including functions known to those skilled in the art that exist in GERAN, UTRAN, E-UTRAN, and CDMA2000 core networks. In some embodiments, these one or more interfaces may be multiplexed together on a single physical interface. In some embodiments, the lower layers of the core network interface 1708 may include one or more of asynchronous transfer mode (ATM), Internet Protocol over Ethernet (IP), SDH over fiber, T1 / E1 / PDH over copper, microwave radio, or other wired or wireless transmission technologies known to those skilled in the art.

[0179] Other interfaces 1710 may include transmitters, receivers, and other circuits that enable network node 1700 to communicate with external networks, computers, databases, etc., for operation, management, and maintenance of network node 1700 or other network equipment operably connected thereto.

[0180] Exemplary system architecture

[0181] In certain embodiments, the 5G system architecture supports data connectivity and services, enabling deployment using technologies such as network function virtualization and software-defined networking. The 5G system architecture can utilize service-based interactions between control plane network functions. Separating user plane functions from control plane functions allows independent scalability, evolution, and flexible deployment (e.g., centralized location or distributed (remote) location). Modular function design allows functional reuse and enables flexible and efficient network slicing. A network function and its network function service can interact with another NF and its network function service directly or indirectly via a service communication agent. Another intermediate function can help route control plane messages. The architecture minimizes the dependency between AN and CN. The architecture may include an aggregated core network with a public AN-CN interface that integrates different access types (e.g., 3GPP access and non-3GPP access). The architecture may also support a unified authentication framework, stateless NFs with decoupling of compute and storage resources, capability exposure, concurrent access to local and centralized services (to support low-latency services and access to local data networks, user plane functions may be deployed near the AN), and / or roaming in the visited PLMN with both home-routed traffic as well as local breakout traffic.

[0182] The 5G architecture can be defined as service-based, and the interactions between network functions can include service-based representations, where a network function within the control plane (e.g., AMF) enables other authorized network functions to access its services. The service-based representation can also include point-to-point reference points. The reference point representation can also be used to show the interactions between NF services in network functions described by a point-to-point reference point (e.g., N11) between any two network functions (e.g., AMF and SMF).

[0183] Figure 18 A service-based architecture 1800 in 5GS according to one embodiment is shown. As described in 3GPP TS 23.501, the service-based architecture 1800 includes NFs such as NSSF 1808, NEF 1810, NRF 1814, PCF 1812, UDM 1826, AUSF 1818, AMF 1820, and SMF 1822 for communicating with UE 1816, (R)AN 1806, UPF 1802, and DN 1804. NFs and NF services can communicate directly (referred to as direct communication) or indirectly via SCP 1824 (referred to as indirect communication). Figure 18 Also shown are the corresponding service-based interfaces including Nutm, Naf, Nudm, Npcf, Nsmf, Nnrf, Namf, Nnef, Nnssf and Nausf and reference points N1, N2, N3, N4 and N6. Figure 18 Some exemplary functions provided by the NF are shown.

[0184] The NSSF 1808 supports functions such as: selecting the set of network slice instances to serve the UE; determining the allowed NSSAIs and, if required, the mapping to the subscribed S-NSSAIs; determining the configured NSSAIs and, if required, the mapping to the subscribed S-NSSAIs; and / or determining the set of AMFs to be used to serve the UE, or a list of candidate AMFs, possibly by querying the NRF based on the configuration.

[0185] NEF 1810 supports the exposure of capabilities and events. NF capabilities and events can be securely exposed by NEF 1810 (e.g., for third parties, application functions, and / or edge computing). NEF 1810 can store / retrieve information as structured data using a standardized interface to UDR (Nudr). NEF 1810 can also securely provide information from external applications to the 3GPP network, and can provide application functions to securely provide information (e.g., expected UE behavior, 5GLAN group information, and service-specific information) to the 3GPP network, where NEF 1810 can authenticate and authorize and help restrict application functions. NEF 1810 can provide internal-external information conversion by converting between information exchanged with AF 1828 and information exchanged with internal network functions. For example, NEF 1810 converts between AF service identifiers and internal 5G core information (such as DNN and S-NSSAI). NEF 1810 can handle the masking of network and user sensitive information of external AFs based on network policies. NEF 1810 can receive information from other network functions (based on the exposed capabilities of other network functions) and store the received information as structured data using a standardized interface to the UDR. The stored information can then be accessed by NEF 1810 and re-exposed to other network functions and application functions, and used for other purposes such as analysis. For external exposure of services related to a specific UE, NEF 1810 can reside in the HPLMN. Depending on the operator agreement, the NEF 1810 in the HPLMN may have an interface with the NF in the VPLMN. When the UE is able to switch between the EPC and 5GC, the SCEF+NEF can be used for service exposure.

[0186] The NRF 1814 supports service discovery functionality by receiving NF discovery requests from NF instances or SCPs and providing information about the discovered NF instances to the NF instances or SCPs. The NRF 1814 may also support P-CSCF discovery (a special case of SMF discovery of AFs), maintain NF profiles of available NF instances and their supported services, and / or notify subscribed NF service consumers or SCPs of newly registered / updated / deregistered NF instances along with their NF services. In the context of network slicing, based on network specific implementation, multiple NRFs may be deployed at different levels, such as PLMN level (NRF configured with information about the entire PLMN), shared slice level (NRF configured with information belonging to a set of network slices), and / or slice-specific level (NRF configured with information belonging to the S-NSSAI). In the context of roaming, multiple NRFs may be deployed in different networks, where the NRF in the visited PLMN (called vNRF) is configured with information about the visited PLMN, and where the NRF in the home PLMN (called hNRF) is configured with information about the home PLMN, referenced by the vNRF via the N27 interface.

[0187] The PCF 1812 supports the unified policy framework to govern network behavior. The PCF 1812 provides policy rules for control plane functions to enforce them. The PCF 1812 accesses subscription information related to policy decisions in the unified data repository (UDR). The PCF 1812 can access the UDR located in the same PLMN as the PCF.

[0188] The UDM 1826 supports the generation of 3GPP AKA authentication credentials, user identification processing (e.g., storage and management of the SUPI for each subscriber in the 5G system), unhiding of the privacy-preserving subscription identifier (SUCI), access authorization based on subscription data (e.g., roaming restrictions), UE registration with the serving NF (e.g., storing the service AMF for the UE and storing the service SMF for the UE's PDU session), service / session continuity (e.g., by maintaining SMF / DNN allocation for ongoing sessions), MT-SMS delivery, lawful intercept functionality (particularly in outbound roaming scenarios where the UDM is the sole point of contact for the LI), subscription management, SMS management, 5G LAN group management processing, and / or external parameter configuration (expected UE behavior parameters or network configuration parameters). To provide such functionality, the UDM 1826 uses subscription data (including authentication data) that may be stored in the UDR. In this case, the UDM implements the application logic and may not require internal user data storage, and several different UDMs may serve the same user in different transactions. The UDM 1826 may be located in the HPLMN of the subscriber it serves and may access information from UDRs located in the same PLMN.

[0189] AUSF 1818 supports authentication for 3GPP access and untrusted non-3GPP access. AUSF 1818 also provides support for network slice-specific authentication and authorization.

[0190] The AMF 1820 supports termination of the RAN CP interface (N2), termination of NAS (N1) for NAS encryption and integrity protection, registration management, connection management, reachability management, mobility management, lawful interception (for AMF events and interfaces to the LI system), transport of SMS messages between the UE and SMF, transparent proxy for routing SM messages, access authentication, access authorization, transport of SMS messages between the UE and SMSF, SEAF, location service management for regulated services, transport of location service messages between the UE and LMF and between the RAN and LMF, EPS bearer ID allocation for interworking with EPS, UE mobility event notification, control plane CIoT 5GS optimization, user plane CIoT 5GS optimization, configuration of external parameters (expected UE behavior parameters or network configuration parameters), and / or network slice-specific authentication and authorization. Some or all of the AMF functions may be supported in a single instance of the AMF 1820. Regardless of the number of network functions, in some embodiments, only one NAS interface instance per access network between the UE and the CN terminates at one of the network functions that implements at least NAS security and mobility management. AMF 1820 may also include policy-related functions.

[0191] In addition to the above functions, the AMF 1820 may also include the following functions to support non-3GPP access networks: support N2 interface with N3IWF / TNGF, on which some information (e.g., 3GPP cell identity) and procedures (e.g., handover related) defined on 3GPP access may not be applicable, and non-3GPP access specific information that is not applicable to 3GPP access may be applied; support NAS signaling with UE through N3IWF / TNGF, where some procedures supported by NAS signaling through 3GPP access may not be applicable to untrusted non-3GPP (e.g., paging) access; support authentication of UEs connected through N3IWF / TNGF; management of mobility, authentication, and separate security context states for UEs connected via non-3GPP access or via both 3GPP access and non-3GPP access; support coordinated RM management context valid on 3GPP access and non-3GPP access; and / or support dedicated CM management context for UEs connected via non-3GPP access. It may not be necessary to support all of the above functions in the instance of network slicing.

[0192] SMF 1822 supports session management (e.g., session establishment, modification, and release, including tunnel maintenance between UPF and AN nodes), UE IP address allocation and management (including optional authorization) (where the UE IP address can be received from the UPF or from an external data network), DHCPv4 (server and client) and DHCPv6 (server and client) functions, functions for responding to Address Resolution Protocol requests and / or IPv6 neighbor request requests based on local cache information of Ethernet PDUs (e.g., the SMF responds to ARP and / or IPv6 neighbor request requests by providing the MAC address corresponding to the IP address sent in the request), selection and control of user plane functions (including controlling the UPF to proxy ARP or IPv6 neighbor discovery or forwarding all ARP / IPv6 neighbor request traffic to the SMF for Ethernet PDU sessions), traffic steering configuration at the UPF to route traffic to the appropriate destination, 5G VN group management (e.g., maintaining the topology of the involved PSA UPFs, in which the PSA Establish and issue N19 tunnels between UPFs, configure traffic forwarding at UPF to apply local switching and / or N6-based forwarding or N19-based forwarding), terminate interfaces towards policy control function, lawful interception (for SM events and interfaces to LI system), charge for data collection and support billing interfaces, control and coordination of billing data collection at UPF, terminate SM part of NAS messages, downlink data notification, initiator of AN-specific SM information sent to AN via AMF over N2, determination of SSC mode for session, control plane CIoT 5GS optimization, header compression, act as I-SMF in deployments where I-SMF can be inserted / removed / relocated, configure external parameters (expected UE behavior parameters or network configuration parameters), P-CSCF discovery for IMS services, roaming functions (e.g., handling local implementation to apply QoS SLA (VPLMN), charging data collection and charging interface (VPLMN) and / or lawful interception (in VPLMN for SM events and interface to LI system), interaction with external DN to transmit signaling for PDU session authentication / authorization for external DN and / or instructing UPF and NG-RAN to perform redundant transmission on N3 / N9 interface. Some or all SMF functions can be supported in a single instance of SMF. However, in some embodiments, not all functions need to be supported in an instance of network slice. In addition to the functions, SMF 1822 may include policy-related functions.

[0193] SCP 1824 includes one or more of the following functions: indirect communication; delegated discovery; message forwarding and routing to the destination NF / NF service; communication security (e.g., authorization of NF service consumers to access NF service manufacturer APIs), load balancing, monitoring, overload control, etc.; and / or optionally interacting with the UDR to resolve UDM group ID / UDR group ID / AUSF group ID / PCF group ID / CHF group ID / HSS group ID based on UE identity (e.g., SUPI or IMPI / IMPU). Some or all of the SCP functions may be supported in a single instance of the SCP. In certain embodiments, SCP 1824 can be deployed in a distributed manner and / or more than one SCP may be present in the communication path between NF services. SCPs can be deployed at the PLMN level, shared slice level, and slice-specific level. Operator deployment may be left to ensure that the SCP can communicate with the relevant NRFs.

[0194] UE 1816 may include a device with radio communication capabilities. For example, UE 1816 may include a smartphone (e.g., a handheld touchscreen mobile computing device that can connect to one or more cellular networks). UE 1816 may also include any mobile or non-mobile computing device, such as a personal data assistant (PDA), a pager, a laptop computer, a desktop computer, a wireless handheld device, or any computing device that includes a wireless communication interface. UE is also referred to as a client, mobile phone, mobile device, mobile terminal, user terminal, mobile unit, mobile station, mobile user, subscriber, user, remote station, access agent, user agent, receiver, radio equipment, reconfigurable radio equipment, or reconfigurable mobile device. UE 1816 may include 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 exchange data with an MTC server or device via a PLMN, other UEs using ProSe or D2D communications, a sensor network, or an IoT network using technologies (e.g., M2M, MTC, or mMTC technologies). M2M or MTC data exchanges may be machine-initiated data exchanges. The IoT network describes interconnected IoT UEs, which may include uniquely identifiable embedded computing devices (within the Internet infrastructure). The IoT UEs may execute background applications (e.g., keep-alive messages, status updates, etc.) to facilitate connectivity to the IoT network.

[0195] The UE 1816 may be configured to connect or communicatively couple with the (R)AN 1806 via a radio interface 1830, which may be a physical communication interface or layer configured to operate with a cellular communication protocol (such as a GSM protocol, a CDMA network protocol, a push-to-talk (PTT) protocol, a PTT over cellular (POC) protocol, a UMTS protocol, a 3GPP LTE protocol, a 5G protocol, a NR protocol, etc.). For example, the UE 1816 and the (R)AN 1806 may use a Uu interface (e.g., an LTE-Uu interface) to exchange control plane data via a protocol stack including a PHY layer, a MAC layer, an RLC layer, a PDCP layer, and an RRC layer. DL transmissions may be from the (R)AN 1806 to the UE 1816, and UL transmissions may be from the UE 1816 to the (R)AN 1806. The UE 1816 may also use a side link to directly communicate with another UE (not shown) for D2D, P2P, and / or ProSe communication. For example, the ProSe interface may include one or more logical channels, including but not limited to a physical sidelink control channel (PSCCH), a physical sidelink shared channel (PSSCH), a physical sidelink discovery channel (PSDCH), and a physical sidelink broadcast channel (PSBCH).

[0196] The (R)AN 1806 may include one or more access nodes, which may be referred to as a base station (BS), a Node B, an evolved Node B (eNB), a next-generation Node B (gNB), a RAN node, a controller, a transmission reception point (TRP), etc., and may include a ground station (e.g., a terrestrial access point) or a satellite station that provides coverage within a geographic area (e.g., a cell). The (R)AN 1806 may include one or more RAN nodes that provide macro cells, pico cells, femto cells, or other types of cells. A macro cell may cover a relatively large geographic area (e.g., several kilometers in radius) and may allow unrestricted access to a UE with a service subscription. A pico cell may cover a relatively small geographic area and may allow unrestricted access to a UE with a service subscription. A femto cell may cover a relatively small geographic area (e.g., a home) and may allow restricted access to UEs associated with the femto cell (e.g., UEs in a closed subscriber group (CSG), UEs of users in a home, etc.).

[0197] Although not shown, multiple RAN nodes (such as (R)AN 1806) may be used, with an Xn interface defined between two or more nodes. 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 may provide non-guaranteed delivery of user plane PDUs and support / provide data forwarding and flow control functions. The Xn-C may provide management and error handling functions for managing the functions of the Xn-C interface; mobility support for UE 1816 in connected mode (e.g., CM-CONNECTED) includes functions for managing UE mobility in connected mode between one or more (R)AN nodes. Mobility support may include context transfer from an old (source) serving (R)AN node to a new (target) serving (R)AN node, and control of a user plane tunnel between the old (source) serving (R)AN node and the new (target) serving (R)AN node.

[0198] The UPF 1802 can serve as an anchor point for intra-RAT and inter-RAT mobility, an external PDU session point interconnected with the DN 1804, and a branch point to support multi-homed PDU sessions. The UPF 1802 can also perform packet routing and forwarding, packet inspection, enforce the user plane portion of policy rules, and lawfully intercept packets (UP collection); traffic usage reporting, perform QoS processing on the user plane (e.g., packet filtering, gating, UL / DL rate enforcement), perform uplink traffic validation (e.g., SDF to QoS flow mapping), transport level packet marking in the uplink and downlink, and downlink packet buffering and downlink data notification triggering. The UPF 1802 may include an uplink classifier to support routing of traffic flows to the data network. The DN 1804 may represent various network operator services, Internet access, or third-party services. The DN 1804 may include, for example, an application server.

[0199] Figure 19 is a block diagram illustrating means 1900 capable of reading instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and capable of performing any one or more of the methods discussed herein, according to some example embodiments. Specifically, Figure 19 A schematic diagram of hardware resources 1902 is shown, including one or more processors 1906 (or processor cores), one or more memory / storage devices 1914, and one or more communication resources 1924, each of which may be communicatively coupled via a bus 1916. For embodiments in which node virtualization (e.g., NFV) is utilized, a hypervisor 1922 may be executed to provide an execution environment for one or more network slices / sub-slices to utilize the hardware resources 1902.

[0200] Processor 1906 (e.g., 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 digital signal processor (DSP) (such as a baseband processor), an application-specific integrated circuit (ASIC), a radio frequency integrated circuit (RFIC), another processor, or any suitable combination thereof) may include, for example, processor 1908 and processor 1910.

[0201] The memory / storage device 1914 may include main memory, disk storage, or any suitable combination thereof. The memory / storage device 1914 may include, but is not limited to, any type of volatile or non-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, etc.

[0202] The communication resources 1924 may include interconnect or network interface components or other suitable devices to communicate with one or more peripheral devices 1904 or one or more databases 1920 via the network 1918. For example, the communication resources 1924 may include wired communication components (e.g., for coupling via a universal serial bus (USB)), cellular communication components, NFC components, Parts (such as Low power consumption), components and other communication components.

[0203] The instructions 1912 may include software, a program, an application, an applet, an application, or other executable code for causing at least one of the processors 1906 to perform any one or more of the methods discussed herein. The instructions 1912 may reside, in whole or in part, within at least one of the processors 1906 (e.g., within a cache memory of the processor), the memory / storage device 1914, or any suitable combination thereof. Furthermore, any portion of the instructions 1912 may be transferred to the hardware resources 1902 from any combination of the peripheral devices 1904 or the database 1920. Thus, the memory of the processor 1906, the memory / storage device 1914, the peripheral devices 1904, and the database 1920 are examples of computer-readable and machine-readable media.

[0204] For one or more embodiments, at least one of the components shown in one or more of the foregoing figures may be configured to perform one or more operations, techniques, processes, and / or methods described in the Examples section below. For example, the baseband circuitry described above in conjunction with one or more of the foregoing figures may be configured to operate according to one or more of the following examples. For another example, circuitry associated with the UE, base station, network element, etc. 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 shown in the Examples section below.

[0205] Examples

[0206] The following examples relate to additional embodiments.

[0207] Embodiment 1 is a method of relaying user equipment (UE), the method comprising: receiving a data packet including a radio link control (RLC) protocol data unit (PDU) from a first remote UE, the RLC PDU including a packet data convergence protocol (PDCP) PDU and a first adaptive header having first routing information; decoding the first routing information from the first adaptive header at an adaptation layer of the relay UE between the RLC layer of the UE and the PDCP layer of the UE; determining that the PDCP PDU should be forwarded to a second remote UE based on the first routing information; generating a second packet including the PDCP PDU; and forwarding the second packet to the second remote UE.

[0208] Embodiment 2 is a method according to embodiment 1, wherein the first routing information includes an identity of an end-to-end bearer.

[0209] Embodiment 3 is the method of embodiment 2, wherein the end-to-end bearer is a PDCP bearer that travels from the first remote UE through the relay UE and terminates at the second remote UE.

[0210] Embodiment 4 is the method of embodiment 2, wherein the end-to-end bearer is a data radio bearer (DRB).

[0211] Embodiment 5 is a method according to embodiment 2, wherein the end-to-end bearer is a signaling radio bearer (SRB).

[0212] Embodiment 6 is a method according to any one of embodiments 1 to 5, wherein the first routing information includes a layer 2 address of the second remote UE.

[0213] Embodiment 7 is the method of any one of embodiments 1 to 6, wherein the first routing information includes quality of service (QoS) information.

[0214] Embodiment 8 is the method of any one of embodiments 1 to 7, wherein the second packet includes a second adaptation header including second routing information.

[0215] Embodiment 9 is a method according to any one of embodiments 1 to 8, wherein the second routing information includes a layer 2 address of the first remote UE.

[0216] Embodiment 10 is a method of relaying user equipment (UE), the method comprising: receiving a data packet including a logical channel identifier (LCID) and a radio link control (RLC) protocol data unit (PDU) from a first remote UE, the RLC PDU including a packet data convergence protocol (PDCP) PDU and a first adaptive header having first routing information; decoding the first routing information from the first adaptive header at an adaptation layer of the relay UE between the RLC layer of the UE and the PDCP layer of the UE; determining that the PDCP PDU should be forwarded to a second remote UE based on the LCID and the first routing information; generating a second packet including the PDCP PDU; and forwarding the second packet to the second remote UE.

[0217] Embodiment 11 is the method of embodiment 10, wherein the LCID is a value indicating that the PDCP PDU should be forwarded.

[0218] Embodiment 12 is a method according to any one of embodiments 10 to 11, further comprising: identifying a bearer between the relay UE and the second remote UE based on an index located in the first routing information for forwarding the PDCP PDU to the second remote UE; wherein the second packet is forwarded to the second remote UE using the bearer.

[0219] Embodiment 13 is a method according to embodiment 12, wherein the bearer between the relay UE and the second remote UE is an RLC bearer.

[0220] Embodiment 14 is a method for relaying user equipment (UE), the method comprising: receiving a data packet from a first remote UE, the data packet comprising a medium access control (MAC) header, a logical channel identifier (LCID) comprising a routing indication, and a radio link control RLC protocol data unit (PDU) comprising a packet data convergence protocol (PDCP) PDU; determining that the PDCP PDU should be forwarded to the second remote UE based on the routing indication of the LCID and the layer 2 address provided in the MAC header; generating a second packet comprising the PDCP PDU; and forwarding the second packet to the second remote UE.

[0221] Embodiment 15 is a method according to embodiment 14, further comprising identifying a bearer between the relay UE and the second remote UE based on the routing indication in the LCID for forwarding the PDCP PDU to the second remote UE; wherein the second packet is forwarded to the second remote UE using the bearer.

[0222] Embodiment 16 is a method according to embodiment 15, wherein the bearer between the relay UE and the second remote UE is an RLC bearer.

[0223] Embodiment 17 is a method according to any one of embodiments 14 to 16, wherein the layer 2 address is a layer 2 address of the first remote UE.

[0224] Embodiment 18 is a method for a relay user equipment (UE) to establish a hop-by-hop path configuration, the method comprising: receiving a first side link (SL) configuration message corresponding to a first bearer between the first remote UE and the relay UE from a first remote UE, the first SL configuration message including a first logical channel identifier (LCID), a first layer 2 address, an end-to-end bearer ID, a next hop quality of service (QoS) indicator, and a first index; generating a second SL configuration message corresponding to a second bearer between the relay UE and a second remote UE, the second SL configuration message including a second LCID, a second layer 2 address, the end-to-end bearer ID, and a second index; sending the second SL configuration message to the second remote UE; receiving a first SL reconfiguration completion message including the second index from the second remote UE; and sending a second SL reconfiguration completion message including the first index to the first remote UE.

[0225] Embodiment 19 is the method of embodiment 18, wherein each of the first bearer and the second bearer is a radio link control (RLC) bearer.

[0226] Embodiment 20 is a method according to any one of embodiments 18 to 19, wherein the first bearer between the first remote UE and the relay UE is a new bearer, and wherein the first SL configuration message further includes new bearer configuration information.

[0227] Embodiment 21 is a method according to any one of embodiments 18 and 19, wherein the first bearer between the first remote UE and the relay UE is an existing bearer.

[0228] Embodiment 22 is a method according to any one of embodiments 18 to 21, wherein the second LCID is selected by the relay UE based on the next hop QoS indicator from the first remote UE for use in the second SL configuration message.

[0229] Embodiment 23 is the method of any one of embodiments 18 to 22, wherein the first layer 2 address is a destination address and the second layer 2 address is a source address.

[0230] Embodiment 24 is a method for establishing a relay UE with a hop-by-hop path configuration, the method comprising: receiving a first side link (SL) configuration message corresponding to a first bearer between the first remote UE and the relay UE from a first remote UE, the first SL configuration message including a first logical channel identifier (LCID) configured to provide routing indications, a first layer 2 address, an end-to-end bearer ID, and a next-hop quality of service (QoS) indicator; generating a second SL configuration message corresponding to a second bearer between the relay UE and a second remote UE, the second SL configuration message including a second LCID configured to provide routing indications, a second layer 2 address, and the end-to-end bearer ID; sending the second SL configuration message to the second remote UE; receiving a first SL reconfiguration completion message from the second remote UE; and sending a second SL reconfiguration completion message to the first remote UE.

[0231] Embodiment 25 is a method according to embodiment 24, wherein the first bearer between the first remote UE and the relay UE is a new bearer, and wherein the first SL configuration message further includes new bearer configuration information.

[0232] Embodiment 26 is the method of embodiment 24, wherein each of the first bearer and the second bearer is a radio link control (RLC) bearer.

[0233] Embodiment 27 is a method according to any one of embodiments 24 to 26, wherein the second LCID is selected by the relay UE based on the next hop QoS indicator from the first remote UE.

[0234] Embodiment 28 is the method of any one of embodiments 24 to 27, wherein the first layer 2 address is a destination address and the second layer 2 address is a source address.

[0235] Example 29 may include an apparatus comprising means for performing one or more elements of the method described in or related to any of the above examples or any other method or process described herein.

[0236] Embodiment 30 may include one or more non-transitory computer-readable media, which include instructions that, when executed by one or more processors of an electronic device, cause the electronic device to perform one or more elements of a method described in or related to any of the above embodiments or any other method or process described herein.

[0237] Embodiment 31 may include an apparatus comprising logic components, modules, or circuits for performing one or more elements of the method described in or related to any of the above embodiments or any other method or process described herein.

[0238] Embodiment 32 may include methods, techniques, or processes described in or related to any of the above embodiments, or parts or components thereof.

[0239] Embodiment 33 may include a device comprising: one or more processors and one or more computer-readable media, wherein the one or more computer-readable media include instructions that, when executed by the one or more processors, cause the one or more processors to perform the method, technique, or process, or portion thereof, described in or related to any one of the above embodiments.

[0240] Embodiment 34 may include signals or portions or components thereof as described in or related to any one of the above embodiments.

[0241] Embodiment 35 may include a datagram, packet, frame, segment, protocol data unit (PDU) or message or a portion or component thereof as described in any of the above embodiments or in connection therewith, or as otherwise described in this disclosure.

[0242] Embodiment 36 may include a signal encoded with data or a portion or component thereof as described in any of the above embodiments or related thereto, or as otherwise described in this disclosure.

[0243] Embodiment 37 may include a signal or portion or component thereof encoding a datagram, packet, frame, segment, PDU or message as described in any of the above embodiments or in connection therewith, or as otherwise described in this disclosure.

[0244] Embodiment 38 may include an electromagnetic signal carrying computer-readable instructions, wherein execution of the computer-readable instructions by one or more processors will cause the one or more processors to perform a method, technique, or process, or portion thereof, as described in or related to any of the above embodiments.

[0245] Embodiment 39 may include a computer program comprising instructions, wherein execution of the program by a processing element causes the processing element to perform a method, technique, or process, or portion thereof, as described in or related to any one of the above embodiments.

[0246] Embodiment 40 may include signals in a wireless network as shown and described herein.

[0247] Embodiment 41 may include a method of communicating in a wireless network as shown and described herein.

[0248] Embodiment 42 may include a system for providing wireless communications as shown and described herein.

[0249] Embodiment 43 may include an apparatus for providing wireless communications as shown and described herein.

[0250] Unless expressly stated otherwise, any of the above embodiments may be combined with any other embodiment (or combination of embodiments). The foregoing description of one or more specific implementations provides illustration and description, but is not intended to be exhaustive or to limit the scope of the embodiments to the precise forms disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of the various embodiments.

[0251] Embodiments and implementations of the systems and methods described herein may include various operations that may be embodied in machine-executable instructions to be executed by a computer system. A computer system may include one or more general-purpose or special-purpose computers (or other electronic devices). A computer system may include hardware components that include specific logic components for performing the operations, or may include a combination of hardware, software, and / or firmware.

[0252] It should be understood that the systems described herein include descriptions of specific embodiments. These embodiments can be combined into a single system, partially integrated into other systems, separated into multiple systems, or otherwise divided or combined. In addition, it is contemplated that parameters, attributes, aspects, etc. of one embodiment can be used in another embodiment. For clarity, these parameters, attributes, aspects, etc. are described only in one or more embodiments, and it should be understood that unless otherwise stated herein, these parameters, attributes, aspects, etc. can be combined with or substituted for parameters, attributes, aspects, etc. of another embodiment.

[0253] It is understood that the use of personally identifiable information should be subject to privacy policies and practices that are generally recognized to meet or exceed industry or government requirements for maintaining user privacy. Specifically, personally identifiable information data should be managed and processed to minimize the risk of unintentional or unauthorized access or use, and the nature of authorized use should be clearly stated to users.

[0254] Although the foregoing has been described in considerable detail for purposes of clarity, it will be apparent that certain changes and modifications may be made without departing from the principles of the invention. It should be noted that there are many alternative ways of implementing both the processes and the apparatus described herein. The embodiments of the present invention are therefore to be considered illustrative and not restrictive, and the description is not to be limited to the details given herein, but may be modified within the scope and equivalents of the appended claims.

Claims

1. A method for establishing a relay user equipment (UE) for hop-by-hop path configuration, the method comprising: receiving, from a first remote UE, a first sidelink (SL) configuration message corresponding to a first bearer between the first remote UE and the relay UE, the first SL configuration message comprising a first logical channel identifier (LCID), an end-to-end bearer ID, a next hop quality of service (QoS) indicator, and a first index; Generate a second SL configuration message corresponding to a second bearer between the relay UE and the second remote UE, the second SL configuration message including a second LCID, the end-to-end bearer ID, and a second index; Sending the second SL configuration message to the second remote UE; receiving a first SL reconfiguration complete message from the second remote UE; as well as Send a second SL reconfiguration completion message to the first remote UE. 2 . The method of claim 1 , wherein each of the first bearer and the second bearer is a radio link control (RLC) bearer. 3 . The method according to claim 1 , wherein the first bearer between the first remote UE and the relay UE is a new bearer, and wherein the first SL configuration message further includes new bearer configuration information. The method of claim 1 , wherein the first bearer between the first remote UE and the relay UE is an existing bearer.

5. The method of claim 1, wherein the second LCID is selected by the relay UE for use in the second SL configuration message based on the next hop QoS indicator from the first remote UE.

6. The method of claim 1, wherein the end-to-end bearer ID identifies a data radio bearer (DRB).

7. The method of claim 1, wherein the end-to-end bearer ID identifies a signaling radio bearer (SRB).

8. A method for establishing a relay user equipment (UE) for hop-by-hop path configuration, the method comprising: receiving, from a first remote UE, a first sidelink (SL) configuration message corresponding to a first bearer between the first remote UE and the relay UE, the first SL configuration message comprising a first logical channel identifier (LCID) configured to provide a routing indication, an end-to-end bearer ID, and a next hop quality of service (QoS) indicator; generating a second SL configuration message corresponding to a second bearer between the relay UE and the second remote UE, the second SL configuration message comprising a second LCID configured to provide a routing indication and the end-to-end bearer ID; Sending the second SL configuration message to the second remote UE; receiving a first SL reconfiguration complete message from the second remote UE; as well as Send a second SL reconfiguration completion message to the first remote UE.

9. The method according to claim 8, wherein the first bearer between the first remote UE and the relay UE is a new bearer, and wherein the first SL configuration message further includes new bearer configuration information.

10. The method of claim 8, wherein each of the first bearer and the second bearer is a radio link control (RLC) bearer.

11. The method of claim 8, wherein the second LCID is selected by the relay UE based on the next hop QoS indicator from the first remote UE.

12. The method of claim 8, wherein the end-to-end bearer ID identifies a data radio bearer (DRB).

13. The method of claim 8, wherein the end-to-end bearer ID identifies a signaling radio bearer (SRB).

14. An apparatus for establishing a relay user equipment (UE) for hop-by-hop path configuration, the apparatus comprising: one or more processors, and a memory storing instructions, which, when executed by the one or more processors, configure the relay UE to: receiving, from a first remote UE, a first sidelink (SL) configuration message corresponding to a first bearer between the first remote UE and the relay UE, the first SL configuration message comprising a first logical channel identifier (LCID), an end-to-end bearer ID, a next hop quality of service (QoS) indicator, and a first index; Generate a second SL configuration message corresponding to a second bearer between the relay UE and the second remote UE, the second SL configuration message including a second LCID, the end-to-end bearer ID, and a second index; Sending the second SL configuration message to the second remote UE; receiving a first SL reconfiguration complete message from the second remote UE; as well as Send a second SL reconfiguration completion message to the first remote UE.

15. The apparatus of claim 14, wherein each of the first bearer and the second bearer is a radio link control (RLC) bearer.

16. The apparatus of claim 14, wherein the first bearer between the first remote UE and the relay UE is a new bearer, and wherein the first SL configuration message further includes new bearer configuration information.

17. The apparatus of claim 14, wherein the first bearer between the first remote UE and the relay UE is an existing bearer.

18. The apparatus of claim 14, wherein the second LCID is selected by the relay UE for use in the second SL configuration message based on the next hop QoS indicator from the first remote UE.

19. The apparatus of claim 14, wherein the end-to-end bearer ID identifies a data radio bearer (DRB).

20. The apparatus of claim 14, wherein the end-to-end bearer ID identifies a signaling radio bearer (SRB).

Images