Layer 2 ue-to-ue data forwarding

Abstract

Systems and methods for transmitting data of interest received from a first remote UE to a second remote UE over a UE-to-UE relay within a wireless communication system using a relay user equipment (UE) are discussed herein. These methods can be performed at layer 2 of a protocol stack of the wireless communication system. Data packets transmitted over the UE-to-UE relay can include adaptive headers that include routing information (e.g., layer 2 addresses, bearer-specific indices, etc.) for the UE-to-UE relay. Accordingly, an adaptive layer can be provided within layer 2 to decode these adaptive headers. In some cases, per-bearer methods can be used to map between individual direct bearers of a hop-by-hop path configuration of the UE-to-UE relay. Implementations are also described that avoid the adaptive headers and instead use logical channel identifiers (LCIDs) for routing indications.

Description

Technical Field

[0001] This application relates in general to wireless communication systems, including wireless communication systems having one or more user equipments (UEs) that can perform UE-to-UE relay functions using a Layer 2 method. Background Technology

[0002] Wireless mobile communication technologies use various standards and protocols to transmit data between base stations and wireless mobile devices. Wireless communication system standards and protocols may include 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, commonly referred to by the industry organization as WiMAX; and the IEEE 802.11 standard for Wireless Local Area Networks (WLANs), commonly referred to by the industry organization as Wi-Fi. In the 3GPP Radio Access Network (RAN) of an LTE system, a base station may include RAN nodes such as an Evolved Universal Terrestrial Radio Access Network (E-UTRAN) Node B (also commonly referred to as Evolved Node B, Enhanced Node B, eNodeB, or eNB) and / or a Radio Network Controller (RNC) in the E-UTRAN, which communicates with wireless communication equipment called User Equipment (UE). In the fifth generation (5G) wireless RAN, RAN nodes may include 5G nodes and NR nodes (also known as next-generation node B or g NodeB (gNB)).

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

[0004] 5G NR frequency bands can be divided into two distinct frequency ranges. Frequency range 1 (FR1) may include bands operating below 6 GHz, some of which are available for previous standards and can potentially be extended to cover new spectrum offerings from 410 MHz to 7,125 MHz. Frequency range 2 (FR2) may include bands from 24.25 GHz to 52.6 GHz. The bands in the millimeter wave (mmWave) range of FR2 may have a smaller range than those in FR1 but potentially higher available bandwidth. Those skilled in the art will recognize that these frequency ranges, presented by way of example, may vary over time or in different regions. Attached Figure Description

[0005] To facilitate identification of any particular element or action being discussed, one or more of the most significant digits in the reference numerals refer to the drawing number in which the element was first introduced.

[0006] Figure 1 The diagram illustrates a relay UE that provides UE-to-UE relay according to an implementation scheme.

[0007] Figure 2 The illustration shows a process for setting up a relay UE to provide UE-UE relay between a first remote UE and a second remote UE, according to an implementation scheme.

[0008] Figure 3 This is a diagram illustrating the source remote UE, relay UE, and destination remote UE, as well as their various user protocol stacks, according to the implementation scheme described herein.

[0009] Figure 4 The illustration shows a UE-to-UE relay transmitting a first data packet between a source remote UE and a relay UE, according to an implementation scheme.

[0010] Figure 5 The illustration shows a UE-to-UE relay between a source remote UE and a destination remote UE, according to an implementation scheme, transmitting a second data packet between the relay UE and the destination remote UE.

[0011] Figure 6 The various possible adaptive headers that can be used according to some implementation schemes are shown.

[0012] Figure 7 A method for configuring a hop-by-hop path from a source remote UE to a destination remote UE via a relay UE, according to an implementation scheme, is shown.

[0013] Figure 8 This is a diagram illustrating the use of a data forwarding method per bearer according to some implementation schemes.

[0014] Figure 9 A method for configuring a hop-by-hop path from a source remote UE to a destination remote UE via a relay UE, according to an implementation scheme, is shown.

[0015] Figure 10 This is a diagram illustrating the use of a data forwarding method per bearer according to some implementation schemes.

[0016] Figure 11 A method for relaying a UE according to an implementation scheme is shown.

[0017] Figure 12 A method for relaying a UE according to an implementation scheme is shown.

[0018] Figure 13 A method for relaying a UE according to an implementation scheme is shown.

[0019] Figure 14 A method for establishing a hop-by-hop path configuration for a relay UE, according to an implementation scheme, is shown.

[0020] Figure 15 A method for establishing a hop-by-hop path configuration for a relay UE, according to an implementation scheme, is shown.

[0021] Figure 16 A UE according to one implementation is shown.

[0022] Figure 17 A network node according to one implementation scheme is shown.

[0023] Figure 18 An exemplary service-based architecture according to certain implementation schemes is shown.

[0024] Figure 19 The components according to one implementation are shown. Detailed Implementation

[0025] A relay UE can receive data from a wireless mobile device and transmit it to another wireless mobile device. For example, a relay UE can receive data from a first remote UE and transmit it to a base station (and vice versa). In other words, the relay UE acts as a UE-to-network (NW) relay between the first remote UE and the base station. In other examples, a relay UE can receive data from a first remote UE and transmit it to a second remote UE (and vice versa). In other words, the relay UE provides UE-to-UE relay between the first and second remote UEs.

[0026] A UE providing UE-to-UE relay can help users of remote UEs connect to each other. For example, a relay UE can be helpful to users of a first remote UE who are outside the range of a second remote UE on a sidelink (SL). In these cases, data can be transmitted from the first remote UE to the relay UE providing UE-to-UE relay, and then forwarded to the second remote UE on the UE-to-UE relay. A relay UE can be similarly used for UE-to-NW relay applications. In this way, communication from the first remote UE can be received by entities outside the direct range of the first remote UE in the wireless communication system. This can be useful, for example, when one or more various entities (UEs, base stations) in the wireless communication system are widely dispersed, where each entity is within the range of only one or a few (but not all) other entities within the wireless communication system.

[0027] It is conceivable that UE-to-UE relay functionality can be implemented at Layer 2 (sometimes referred to herein as "L2") of the 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 other wireless communication system). Furthermore, any Layer 2 UE-to-UE relay functionality used within a wireless communication system can correspond to / be designed for use with UE-to-NW relay functionality implemented at Layer 2 of the protocol stack within the wireless communication system.

[0028] Compared to, for example, Layer 3 methods, the Layer 2 methods disclosed herein provide better end-to-end security protection (because relay UEs cannot snoop on data shared between remote UEs in such Layer 2 methods). Furthermore, the Layer 2 methods enable Access Layer (AS) mechanisms to ensure Quality of Service (QoS) and service continuity, which is impossible when using Layer 3 relay methods. Additionally, Layer 2 UE-to-UE relay and Layer 2 UE-to-NW relay can share a common scalable design, which can be extended to support multi-hop relay.

[0029] Systems that enable UE-to-UE relay functionality may be useful in situations such as public safety or vehicle-to-everything (V2X), where a UE may be outside the range of a base station but within the range of one or more (potentially dispersed) other UEs.

[0030] Figure 1 A relay UE 102 providing UE-to-UE relay according to an embodiment is shown. The relay UE 102 can connect to a first remote UE 104 via a first PC5 link 106. The relay UE 102 can also connect to a second remote UE 108 via a second PC5 link 110. Data can be transmitted on one or both of the first PC5 link 106 and / or the second PC5 link 110. These data transmissions (and other data transmissions on the PC5 links) may be discussed herein as “SL transmissions” or “SL messages”.

[0031] Relay UE 102 can receive data of interest from a second remote UE 108 as part of one or more data packets from a first remote UE 104 on a first PC5 link 106. Relay UE 102 can then transmit the data of interest as part of one or more data packets on a second PC5 link 110 to the second remote UE 108.

[0032] about Figure 1 The described message transmission can be usefully applied to various coverage scenarios. For example, it is possible that all three of the relay UE 102, the first remote UE 104, and the second remote UE 108 are outside the coverage area (e.g., outside 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 achieve communication between the first remote UE 104 and the second remote UE 108. As another example, it is possible that only the relay UE 102 is within the coverage area. In this case, the relay UE 102 can forward data of interest to the second remote UE 108 as described (and this can happen 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 yet another example, the relay UE 102 and one of the first remote UE 104 or the second remote UE 108 are within the coverage area, but the other of the first remote UE 104 and the second remote UE 108 is outside the coverage area. In this scenario, the relay UE 102 can forward the data of interest directly from one of the first remote UE 104 and the second remote UE 108 to the other (e.g., via UE-to-UE relay) instead of involving the base station during data transmission, which may require a greater number of transmissions than in the case of UE-to-UE relay.

[0033] It can be anticipated that, in some implementations, a relay UE providing UE-to-UE relay can also provide UE-to-NW relay.

[0034] Figure 2 A setup process 200, according to an embodiment, is illustrated for setting up a relay UE 202 to provide UE-UE relay 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 each other's SL range.

[0035] 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 each other's SL range.

[0036] The order in which the first PC5 discovery 208 and the second PC5 discovery 210 are executed can be reversed.

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

[0038] 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 (e.g., for SL communication).

[0039] 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 (e.g., for SL communication).

[0040] The order in which the first PC5 link establishment 212 and the second PC5 link establishment 214 are executed can be reversed. Furthermore, it is conceivable that each of the first PC5 discovery 208 and the first PC5 link establishment 212 may be executed before either or both of the second PC5 discovery 210 and / or the second PC5 link establishment 214, and / or each of the second PC5 discovery 210 and the second PC5 link establishment 214 may be executed before either or both of the first PC5 discovery 208 and / or the first PC5 link establishment 212.

[0041] The setup process 200 also optionally includes performing hop-by-hop path configuration 216. A “hop” can be a direct communication (or one of several direct communications) between UEs that are part of a UE-to-UE relay (e.g., SL communication between a first remote UE 204 and a relay UE 202 can be a “hop”, and 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, hop-by-hop path configuration 216 can be useful where the adaptive header is not carried, for example, in one or more data packets sent along the UE to the UE relay, such as a Layer 2 address (sometimes referred to herein as a “Layer 2 ID” or “L2 ID”) and / or where the adaptive header is not used at all in one or more data packets sent along the UE to the UE relay. These hop-by-hop path configurations 216 can be configured (or reconfigured) to be directly carried by one or more (per hop) identified by the Logical Channel Identifier (LCID) used in the data packets using that hop and / or by data found in the adaptive header of the data packets using that hop. This may be the case for all hops between endpoints (e.g., in Figure 2 In the case of all hops between the first remote UE 204 and the second remote UE 206.

[0042] The setup process 200 may further include performing an end-to-end PC5 link setup (control plane) 218, wherein one or more end-to-end bearers are established between 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 end-to-end PC5 signaling (PC5-S) procedures and / or end-to-end PC5 radio resource control (PC5-RRC) procedures. Each end-to-end bearer may have a unique ID relative to other end-to-end bearers between the same pair of UE endpoints (but may not be globally unique within the wireless communication system).

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

[0044] The setup process 200 also includes end-to-end data transmission (user plane) 220. This end-to-end data transmission (user plane) 220 may involve data transmission between endpoints and via 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 relay UE 202). This transmission may involve end-to-end transmission via a relay UE using an SL DRB established in the manner described above.

[0045] Figure 3 Figure 300 illustrates a source remote UE 302, a relay UE 304, and a destination remote UE 306 according to an embodiment herein, along with their various user protocol stacks. As described herein, a "source remote UE" can be a UE-to-UE relay UE that initiates data to a "destination remote UE." Correspondingly, a "destination remote UE" can be a UE that is the intended destination of such data packets.

[0046] The user protocol stack according to the embodiments herein may include one or more of the following: Physical (PHY) layer, Media Access Control (MAC) layer, Radio Link Control (RLC) layer, Adaptive Layer, and Packet Data Convergence Protocol (PDCP) layer. As shown in the figure, 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 Adaptive Layer 316, and a PDCP layer 318. Furthermore, 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 Adaptive Layer 328, and an outgoing user protocol stack 330 having a PHY layer 332, a MAC layer 334, an RLC layer 336, and an Adaptive 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 Adaptive Layer 348, and a PDCP layer 350.

[0047] Each of the PHY layer, MAC layer, RLC layer, and PDCP layer can be those layers understood by a person skilled in the art in relation to the relevant wireless communication system (e.g., NR and / or LTE wireless communication systems).

[0048] The adaptive layer can be used to assist the relay UE in making forwarding decisions as part of the Layer 2 forwarding process described herein. An adaptive header can be placed within the Radio Link Control (RLC) Protocol Data Unit (PDU) of the first data packet. Decoding of this adaptive header can occur at the adaptive layer. By decoding this adaptive header, the adaptive layer inbound to the user protocol stack can be enabled to identify the bearer and / or next hop according to the UE-to-UE relay implementation. Furthermore, the adaptive layer outbound to the user protocol stack can be responsible for encoding corresponding information into the adaptive header of the second data packet to be transmitted according to the UE-to-UE relay function.

[0049] As shown relative to relay UE 304, a UE (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 corresponding to incoming data packets and others 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) may be used to encode data packets to be transmitted.

[0050] According to the embodiments described herein, UE-to-UE relay transmissions using Layer 2 transport can use PDCP bearers as end-to-end bearers. These end-to-end PDCP bearers may include DRBs and SRBs. As shown in the figure, a UE-to-UE relay transmission from source remote UE 302 to destination remote UE 306 via relay UE 304 can use, for example, PDCP bearer 352 as an end-to-end bearer.

[0051] PDCP bearer 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. The first RLC bearer 354 and the second RLC bearer 356 may be examples of direct bearers as described herein.

[0052] Although Figure 300 has been shown and described from the perspective of data transmission from source remote UE 302 to destination remote UE 306 via relay UE 304 on a UE-to-UE relay, it is conceivable that in many cases, any of the UEs will be able to perform the functions 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 Figure 300, it is conceivable that similar principles will apply, as described herein, to extending UE-to-UE relays to use any number of relay UEs.

[0053] Figure 4 The illustration shows a UE-to-UE relay according to an embodiment, in which a first data packet 402 is transmitted between a source remote UE 302 and a relay UE 304. The source remote UE 302, relay UE 304, and destination remote UE 306 (as well as PDCP bearer 352, first RLC bearer 354, and second RLC bearer 356) can be as described above regarding... Figure 3 Those that were discussed.

[0054] Among other things, the first data packet 402 may include a source UE Layer 2 address 404, etc. 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.

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

[0056] MAC subheader 410 may include LCID 414. LCID 414 can be used to indicate QoS information to relay UE 304. For example, if LCID 414 has a specific value understood by relay UE 304, relay UE 304 may process the first data packet 402 with a specific QoS priority or processing. In some embodiments, LCID 414 may also include routing indications used by 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 conceivable that other MAC subheaders of MAC PDU payload 408 may have similar content.

[0057] RLC PDU 412 can be conceptually part of a packet “transmitted” on the first RLC bearer 354. For example, RLC PDU 412 can be decoded at RLC layer 326 of relay UE 304.

[0058] RLC PDU 412 may include RLC header 416.

[0059] In addition, RLC PDU 412 may include an adaptive header 418. The adaptive header 418 may include routing information useful for the relay UE 304 in determining how to forward data taken from the first data packet 402 to the destination remote UE 306. For example, the adaptive header 418 may include the identity of the end-to-end bearer (e.g., PDCP bearer 352) between the source remote UE 302 and the destination remote UE 306. Alternatively or additionally, the adaptive header 418 may include the Layer 2 address of the source remote UE 302. Alternatively or additionally, the adaptive header 418 may include the Layer 2 address of the destination remote UE 306. Alternatively or additionally, the adaptive header 418 may include QoS information corresponding to the first data packet. Additionally or alternatively, the adaptive 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 the 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, the adaptive header 418 may not be used in some embodiments herein when certain types of routing indication are possible in the LCID.

[0060] RLC PDU 412 may also include PDCP PDU 420. PDCP PDU 420 may be part of the conceptual “transmission” of a packet over PDCP bearer 352. As shown, PDCP PDU 420 may not be decoded at relay UE 304 (because relay UE 304 is not the final destination of PDCP PDU 420).

[0061] PDCP PDU 420 may be or include data of interest that drives the use of UE-to-UE relay provided by relay UE 304, and is determined (e.g., by source remote UE 302) to be delivered from source remote UE 302 to destination remote UE 306 according to the UE-to-UE relay provided between these devices by relay UE 304. Therefore, as will be discussed regarding Figure 5 As shown, PDCP PDU 420 can be forwarded by relay UE 304 to destination remote UE 306.

[0062] Figure 5The illustration shows a UE-to-UE relay according to an embodiment, in which a second data packet 502 is transmitted between a relay UE 304 and a destination remote UE 306, based on a source remote UE 302 and a destination remote UE 306. The source remote UE 302, relay UE 304, and destination remote UE 306 (as well as PDCP bearer 352, first RLC bearer 354, and second RLC bearer 356) can be as described above regarding... Figure 3 Those that were discussed.

[0063] Among other things, the second data packet 502 may include a source UE Layer 2 address 504, etc. 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.

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

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

[0066] RLC PDU 512 can be conceptually part of a packet “transmitted” on a second RLC bearer 356. For example, RLC PDU 512 can be decoded at RLC layer 346 of the destination remote UE 306.

[0067] The RLC PDU 512 mainly includes the RLC header 516.

[0068] Furthermore, RLC PDU 512 may include an adaptive header 518. The adaptive header 518 may include routing information useful for the destination remote UE 306 to determine that it is, for example, the final destination of 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 adaptive header 518 may not be used when certain types of routing indication are possible in the LCID.

[0069] The RLC PDU 512 may also include the PDCP PDU 420 (e.g., regarding...). Figure 4The same PDCP PDU is introduced. PDCPPDU 420 can be part of the conceptual “transmission” of a packet on PDCP bearer 352. As discussed above, PDCP PDU 420 can be or includes data of interest that drives the use of UE-to-UE relay provided by relay UE 304 and is determined (e.g., by source remote UE 302) to be delivered from source remote UE 302 to destination remote UE 306 according to the UE-to-UE relay established between these devices by relay UE 304. Because destination remote UE 306 is the intended destination remote UE, PDCP PDU 420 can be decoded at PDCP layer 520 of destination remote UE 306.

[0070] The solutions discussed herein can use an adaptive header, as introduced above and 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 LCID of the data packets) the UE-to-UE relay function shown. Other solutions can completely circumvent the adaptive header and can be configured to make one or more routing indications in the LCID, for example, for routing purposes. Any of these solutions can be used to inform the source UE where the relay UE should forward data packets (e.g., to which remote UE). In some implementations, the use of the LCID to distinguish traffic to be forwarded to the (final) destination remote UE from traffic to be passed up to the local PDCP entity can be avoided. For example, an adaptive header containing routing information can use a specified index value to mark packets to be processed locally. Alternatively or additionally, the adaptive header may include the destination remote UE's Layer 2 address for the traffic. In these kinds of implementations, the LCID may not indicate routing information, and the adaptive header is always used by the first remote UE for any outgoing traffic to instruct the relay UE receiving that traffic how to process it.

[0071] The first approach leverages per-packet configuration by explicitly placing one or more Layer 2 addresses in the adaptive header. Under this approach, the UE can use the PC5 QoS Identifier (PQI) to SL Radio Bearer (SLRB) mapping to classify traffic into different logical channels. In some cases, a single LCID value (even if corresponding to the same QoS priority or processing) can be used to distinguish traffic terminated at the relay UE, rather than traffic intended to be forwarded by the relay UE on a UE-to-UE relay provided by the relay UE.

[0072] In the first method, the adaptive header can be used to indicate QoS information and, in many cases, the relay destination. The relay destination can be the Layer 2 address of the final destination remote UE.

[0073] For example, QoS information can be end-to-end QoS information or remaining QoS information. End-to-end QoS information can indicate that specific data on a given end-to-end bearer in a UE-to-UE relay will be processed at each hop using a specific (static) QoS priority or processing. Remaining QoS information can be the sum of the remaining (unused) time for delivering data to the destination remote UE, and can be updated at each UE-to-UE relay hop based on the amount of time spent making that hop.

[0074] Figure 6 Various possible adaptive headers 600 that may be used according to some implementation schemes are shown. Possible adaptive headers 600 may be used as part of a first method. Possible adaptive headers 600 include a first-hop adaptive header format 602. The first-hop adaptive 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 adaptive 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 adaptive 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 PDU) from the received data packet on the corresponding outgoing data packet according to UE-to-UE relay. Furthermore, the relay UE may use the QoS information field 612 to identify which QoS to use to send the corresponding outgoing data packet. In some implementations, when a relay UE receives traffic from a previous relay UE, the first-hop adaptive header may include the Layer 2 address of the source remote UE. In some implementations, when a relay UE receives traffic from a source remote UE, the first-hop adaptive header may include the Layer 2 source address of the source remote UE, making this information readily retrievable by the adaptive layer (instead of retrievable from the MAC header).

[0075] Possible adaptive header 600 includes a second-hop adaptive header format 604. The second-hop adaptive header format 604 can be sent from a 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 adaptive 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 originates. Layer 2 destination address and / or QoS information fields may not be necessary in this case, as 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 intended for use at the destination remote UE (and is not further relayed). Alternatively, another version of the second-hop adaptive 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 intended for use at the destination remote UE (and not for further relay).

[0076] Possible adaptive header 600 includes a uniform adaptive header format 606. In some implementations, it may be more direct to use the format according to the uniform adaptive header format 606 in each data packet used in UE-UE relay (rather than distinguishing between, for example, the use of first-hop adaptive header format 602 and second-hop adaptive header format 604). Therefore, the uniform adaptive header format 606 includes all the previously discussed fields of possible adaptive header 600 in the adaptive header, including the Layer 2 source address field 618, the Layer 2 destination address field 620, the end-to-end bearer ID field 622, and the QoS information field 624 (where each may be an example of routing information as discussed herein), each of which is used (where necessary) at each UE in UE-UE relay.

[0077] Table 1

[0078]

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

[0080] In other cases, if the adaptive 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 in order to forward data of interest to the destination remote UE in a data packet that also includes an appropriate adaptive header (with appropriate routing information, as described above) formed by the relay UE for this purpose.

[0081] It should be noted that because a pair of UEs can communicate using more than one end-to-end bearer, and because the end-to-end bearer ID may not be a global ID (but can 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 perform a complete forwarding determination as described above.

[0082] It is conceivable that the adaptive header of the first method can be used in implementations involving more than one relay UE. In this case, the adaptive header of the first-hop adaptive header format 602 can be sent by each relay UE (except for the last relay UE, which can then send the adaptive header of the second-hop adaptive header format 604). In other such implementations, the adaptive header of a uniform adaptive header format 606 can be used in each case. Furthermore, it may be necessary to update QoS information (e.g., remaining QoS information) in the manner described above to account for each hop.

[0083] The second approach could be a per-bearer method, which utilizes implicit instructions based on a pre-established hop-by-hop path configuration. As described above, to use such a per-bearer implicit method, it may be necessary to first establish a hop-by-hop path configuration. Establishing the hop-by-hop path configuration corresponds to performing the steps described above. Figure 2 The hop-by-hop path configuration discussed is 216.

[0084] Compared to methods using one or more of the possible adaptive headers 600 according to the first method, using such an implicit per-bearer method based on hop-by-hop path configuration can reduce the amount of data in the adaptive header (and thus reduce the processing resources required to interpret and / or use such data). For example, in the second method, the adaptive header may contain only index values, which is the opposite of the (potentially large and multiple) values ​​discussed in the adaptive headers according to the first method (e.g., possible adaptive headers 600).

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

[0086] Figure 7 A method 700 for establishing a hop-by-hop path configuration from a source remote UE 702 to a destination remote UE 706 via a relay UE 704, according to an embodiment, is shown. Method 700 includes performing a first PC5 link establishment 708 and a second PC5 link establishment 710. This can be performed, for example, with... Figure 2 The above methods are used to complete the establishment of the first PC5 link 212 and the establishment of the second PC5 link 214.

[0087] Method 700 also includes sending message 712 between the source remote UE 702 and the relay UE 704. Message 712 may be an SL configuration message, such as a “SidelinkReconfig” message, or some other message configured to carry the parameters shown. The parameters of 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 exist 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) to be used according to the hop-by-hop path configuration. The parameters of message 712 also include LCID, which corresponds to the QoS priority or processing of data that the source remote UE 702 will transmit 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 the relay UE 704 the final destination (e.g., the destination remote UE) of the data transmitted 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 the relay UE 704 the end-to-end bearer corresponding to the hop-by-hop path configuration. Message 712 also includes next-hop QoS, which allows the relay UE 704 to determine the QoS priority or treatment that should be given to data transmitted 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 general (static) QoS priority or treatment that should be used for all data on the hop-by-hop path configuration. Finally, message 712 may also include an index that can be used to uniquely identify the hop between the source remote UE 702 and the relay UE 704 within the hop-by-hop path configuration. In other words, the index uniquely identifies the use of the direct bearer within that particular hop-by-hop path configuration (as opposed to, for example, using the same direct bearer in different hop-by-hop path configurations).

[0088] Method 700 further includes recording 714 at the relay UE 704 the end-to-end bearer ID corresponding to the hop-by-hop path configuration received in message 712. Method 700 further includes recording 716 at the relay UE 704 the next-hop QoS requirement corresponding to the next hop of the hop-by-hop path configuration received in message 712.

[0089] Method 700 also includes checking any existing LCIDs of the direct bearer between relay UE 704 and destination remote UE 706 to see if such bearers meet the next-hop QoS requirements of the hop configured for the hop-by-hop path between relay UE 704 and destination remote UE 706.

[0090] Method 700 also includes sending message 720 between relay UE 704 and destination remote UE 706. Message 720 may be a sidelink configuration message, such as a “SidelinkReconfig” message or some other message configured to carry the parameters shown. The parameters of message 720 may include SLRB-config, which may indicate new bearer configuration information regarding a newly established bearer (by relay UE 704) between relay UE 704 and relay destination remote UE 706. This parameter may be optional, as it may only exist if a new such bearer is being established for use according to the hop-by-hop path configuration (rather than, for example, if the LCID of an existing direct bearer satisfies the next-hop QoS requirements of that hop in the hop-by-hop path configuration, and relay UE 704 decides to reuse the existing direct bearer between relay UE 704 and destination remote UE 706, where relay UE 704 checks the next-hop QoS requirements as described above in inspection 718). The parameters of message 720 also include an LCID, which corresponds to the QoS priority or processing of the data that relay UE 704 will transmit on this bearer, and will be further used (as described below) to identify the data to the hop-by-hop path configuration. This 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 transmitted according to the hop-by-hop path configuration (e.g., using the Layer 2 address of the final destination of the data, which could 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. This end-to-end bearer ID is the same end-to-end bearer ID that the source remote UE 702 sends to the relay UE 704. Message 720 also includes next-hop QoS, which allows the destination remote UE 706 to determine the QoS priority or treatment that should be given to data transmitted on the next hop according to the hop-by-hop path configuration (in cases where the relay UE 704 is unaware that the destination remote UE 706 is the destination; however, note that including this information would also be useful if the relay UE 704 instead establishes a hop-by-hop path configuration with another relay UE instead of 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 may also include an index that can be used to uniquely identify the 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 within that specific hop-by-hop path configuration (as opposed to, for example, using the same direct bearer in different hop-by-hop path configurations). Because the index is local to the direct bearer for both 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 independent of its value.

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

[0092] Then, to confirm the establishment of the portion of the hop-by-hop path configuration using 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. Message 724 may include the (other) index of the hop in the hop-by-hop path configuration between the source remote UE 702 and the relay UE 704.

[0093] Method 700 further includes storing at relay UE 704 a correspondence or mapping between 726 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 the Layer 2 address of the source remote UE 702 and the Layer 2 address of the destination remote UE 706 corresponding to the hop-by-hop path configuration; storing the end-to-end bearer ID corresponding to the hop-by-hop path configuration; and storing QoS information for one or both hops of the hop-by-hop path configuration.

[0094] Method 700 then proceeds to PC5 secure link establishment (end-to-end) 728, which can correspond to Figure 2 The end-to-end PC5 link setup (control plane) 218.

[0095] It is conceivable that method 700 can be extended to include multiple relay UEs (not just relay UE 704). In these instances, each relay UE can receive messages similar to message 712 from a previous UE in the UE-to-UE relay; perform operations similar to record 714, record 716, and check 718; send messages similar to message 720 to the next UE in the UE-to-UE relay; receive messages similar to message 722 from the next UE in the UE-to-UE relay; send messages similar to message 724 back to the previous UE in the UE-to-UE relay; and perform operations similar to storage 726.

[0096] It is also conceivable that similar information sent in messages 712 and 720 could be echoed back on messages 722 and 724 (e.g., SL configuration messages such as the “SidelinkReconfig” message shown in messages 712 and 720 could be sent on messages 722 and 724, possibly with additional acknowledgment signaling subsequently added to method 700). This could allow for a second hop-by-hop path configuration that is the opposite of the first configuration using only a single message delivery method. For example, in Figure 7 In method 700, support for data forwarding setup is provided for a directed end-to-end PDCP bearer from source remote UE 702 to destination remote UE 706. If another directed bearer exists from destination remote UE 706 to source remote UE 702, a similar set of configuration parameters can be included in a "SidelinkReconfigComplete" message or any other type of message for a similar purpose. Data forwarding setup can then be implemented for traffic in both directions between source remote UE 702 and destination remote UE 706 in a single round trip.

[0097] It is also conceivable that multiple hop-by-hop path configurations can be implemented in a single message round trip by including a copy of the information in question (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 source remote UE 702 to destination remote UE 706, a configuration array can be included in the "SidelinkReconfig" message or any other kind of message for similar purposes, one of which is for each of the multiple PDCP bearers.

[0098] Once the hop-by-hop path configuration described above is established, a per-bearer implicit approach for UE-to-UE relay can be implemented. In this approach, the LCID value placed in the data packet can be used to distinguish between data packets terminated at the receiving UE and any data packets to be forwarded to, for example, a destination remote UE or another relay UE. This means that for a single QoS priority or processing, there may be multiple available LCID values, one indicating a data packet terminated at the receiving UE, and another indicating that the data packet will be forwarded along the UE-to-UE relay. Under this approach, the UE can use a PQI-to-SLRB mapping to classify traffic into different logical channels.

[0099] The index value of a specific hop used in the specific hop-by-hop path configuration is placed in the adaptive header of the data packet to be sent.

[0100] 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 shown 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 (or unnecessary) forwarding configuration for the data of interest in the received data packets.

[0101] Figure 8 Figure 800 illustrates the use of a data forwarding method per bearer according to some implementation schemes. Figure 800 includes a first remote UE 802 (in... Figure 8 (marked as "UE 1"), relay UE 804 (in Figure 8 The second remote UE 806 (marked as "UE 2") is located in the middle. Figure 8 (marked as "UE 3") and the third remote UE 808 (in Figure 8 (Catalyzed as "UE 4"). A first hop-by-hop path configuration 810 has been established between the first remote UE 802 and the 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 use the above information. Figure 7 The publicly disclosed method is used to establish it.

[0102] Table 2

[0103]

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

[0105] In other cases, a data packet may be received at relay UE 804, having an LCID (e.g., LCID ≠ 0) indicating that data of interest should be forwarded, and an index in the adaptive header corresponding to a specific hop in the specific hop-by-hop path configuration used to send the data packet. Relay UE 804 may then refer to the index and LCID stored during the establishment 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 that data packet should be encapsulated in another (outgoing) data packet and sent on the next hop of the specific hop-by-hop path configuration (according to its corresponding index). Therefore, relay UE 804 may generate a data packet containing the data of interest, including the LCID and an index value in the adaptive header corresponding to the next hop in the specific hop-by-hop path configuration determined during the establishment of the hop-by-hop path configuration. This data packet is then sent by relay UE 804 on the direct bearer corresponding to that specific hop in the specific hop-by-hop path configuration.

[0106] For example, as shown in the second row of Table 2, relay UE 804 can receive data packets with LCID = 1 and index (from the adaptive header) = 1 from first remote UE 802. This could correspond to an incoming hop in second hop-by-hop configuration 812 that maps to an outgoing hop in second hop-by-hop configuration 812, which uses a mapped direct bearer with LCID = 1 and index (in the adaptive header) = 5 to send the data of interest to second remote UE 806. Therefore, relay UE 804 prepares the corresponding data packet, places the data of interest in it, and forwards it to second remote UE 806 on the mapped direct bearer.

[0107] As another example, as shown in the third row of Table 2, relay UE 804 can receive data packets with LCID = 2 and index (from the adaptive header) = 2 from first remote UE 802. This could correspond to an incoming hop in third hop-by-hop configuration 814, which maps to an outgoing hop in third hop-by-hop configuration 814, which uses a mapped direct bearer with LCID = 1 and index (in the adaptive header) = 5 to send the data of interest to second remote UE 806. Therefore, relay UE 804 prepares the corresponding data packet, places the data of interest in it, and forwards it to second remote UE 806 on the mapped direct bearer.

[0108] As another example, as shown in the fourth row of Table 2, relay UE 804 can receive data packets with LCID=4 and index (from the adaptive header)=1 from third remote UE 808. This could correspond to an incoming hop of fourth hop-by-hop configuration 816, which maps to an outgoing hop of fourth hop-by-hop configuration 816, which uses a mapped direct bearer with LCID=3 and index (in the adaptive header)=1 to send the data of interest to second remote UE 806. Therefore, relay UE 804 prepares the corresponding data packet, places the data of interest in it, and forwards it to second remote UE 806 on the mapped direct bearer.

[0109] It is conceivable that the implementation of the second method can be extended to include devices other than the UE, such as base stations (in which case the method would be considered to operate in the UE-to-NW relay context).

[0110] The third approach can also be a per-bearer approach, which utilizes implicit indications based on a pre-established hop-by-hop path configuration. The third approach can differ from the second approach because, in at least some cases, a sufficiently wide range of LCID values ​​can be available, allowing the LCID values ​​themselves to be configured to provide routing indications (without interfering with necessary communication of QoS information within 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, indexing may not be necessary (since LCID values ​​can provide similar indications), and therefore adaptive headers may be unnecessary and can be omitted, thus granting even further gains to signaling efficiency.

[0111] A UE may need to transmit data in one or more data packets along a UE-UE relay, and these data packets may need to be transmitted according to a specific LCID (which may represent the QoS priority or processing of the packet). Each UE may check its current direct bearer (e.g., DRB) with the next UE in the UE-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 a suitable LCID to satisfy the QoS priority or processing of the data in question), or whether the current direct bearer will satisfy the UE-UE relay hop for that data.

[0112] Figure 9 A method 900 for establishing a hop-by-hop path configuration from a source remote UE 902 to a destination remote UE 906 via a relay UE 904, according to an embodiment, is shown. Method 900 includes performing a first PC5 link establishment 908 and a second PC5 link establishment 910. This can be performed, for example, with... Figure 2 The above methods are used to complete the establishment of the first PC5 link 212 and the establishment of the second PC5 link 214.

[0113] Method 900 also includes sending message 912 between source remote UE 902 and relay UE 904. Message 912 may be an SL configuration message, such as a “SidelinkReconfig” message, or some other message configured to carry the parameters shown. The parameters of message 912 may include SLRB-config, which may indicate new bearer configuration information regarding 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 exist if a new such direct bearer is being established (rather than an existing direct bearer between source remote UE 902 and relay UE 904 being reused, as described above) to be used according to the hop-by-hop path configuration. The parameters of message 912 also include LCID, which corresponds to the QoS priority or processing of data that source remote UE 902 will transmit on the direct bearer. The LCID may also provide (e.g., represented by a specific value due to the selected LCID) a routing indication that relay UE 904 can adequately identify the next direct bearer corresponding to the hop-by-hop path configuration. Message 912 also includes a destination address parameter that indicates to the relay UE 904 the final destination (e.g., a destination remote UE) of the data transmitted 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 the relay UE 904 the end-to-end bearer corresponding to the hop-by-hop path configuration. Message 912 also includes next-hop QoS, which allows the relay UE 904 to determine the QoS priority or treatment that should be given to data transmitted 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 general (static) QoS priority or treatment that should be used for all data on the hop-by-hop path configuration.

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

[0115] Method 900 also includes sending 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 parameters shown. The parameters of message 922 may include SLRB-config, which may indicate new bearer configuration information regarding 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 exist 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 an existing direct bearer satisfies the next-hop QoS requirements of that hop in the hop-by-hop path configuration, and relay UE 904 instead decides to reuse the existing direct bearer between relay UE 904 and destination remote UE 906, wherein relay UE 904 checks the next-hop QoS requirements as described above in selection 920). The parameters of message selection 920 also include an LCID, which corresponds to the QoS priority or processing of the data that relay UE 704 will transmit on this bearer. This LCID can be selected based on a next-hop QoS indicator received from the source remote UE 902. The LCID can also provide (e.g., represented by a specific value due to the selected LCID) information sufficient to indicate to the destination remote UE 906 the data to be identified in the hop-by-hop path configuration. Message 922 also includes a destination address parameter that indicates to the destination remote UE 906 the final destination of the data transmitted according to the hop-by-hop path configuration (e.g., using the Layer 2 address of the final destination of the data, which could be the Layer 2 address of the destination remote UE 906). Message 922 also includes an end-to-end bearer ID that indicates to the destination remote UE 906 the end-to-end bearer corresponding to the hop-by-hop path configuration. This end-to-end bearer ID is the same 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 transmitted on the next hop according to the hop-by-hop path configuration (this information is useful if relay UE 904 is unaware that destination remote UE 906 is the destination; however, note that this information will also be useful if relay UE 904 instead establishes a hop-by-hop path configuration with another relay UE instead of 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.

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

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

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

[0119] Method 900 then proceeds to PC5 secure link establishment (end-to-end) 930, which can correspond to Figure 2 The end-to-end PC5 link setup (control plane) 218.

[0120] It is conceivable that method 900 can be extended 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 a previous UE in the UE-to-UE relay; perform operations similar to record 914, record 916, record 918, and pick 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 an operation similar to hold 928.

[0121] It is also conceivable that similar information sent in messages 912 and 922 could be echoed back on messages 924 and 926 (e.g., SL configuration messages such as the “SidelinkReconfig” message shown in messages 912 and 922 could be sent on messages 924 and 926, possibly with additional acknowledgment signaling subsequently added to method 900). This could allow for a second hop-by-hop path configuration that is the opposite of the first configuration using only a single message delivery method.

[0122] It is also conceivable that multiple hop path configurations can be implemented in a single message delivery round trip by including a copy of the information in question (relative to each individual hop path configuration) in each of messages 912, 922, 924 and 926.

[0123] Once the hop-by-hop path configuration described above is established, a per-bearer implicit approach for UE-to-UE relay 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 terminated at the receiving UE and any data packets to be forwarded to, for example, a destination remote UE or another relay UE. This routing indication under the third approach can also distinguish the direct bearer used on the next hop in the hop-by-hop path configuration.

[0124] Once received at the receiving UE, the sending UE's LCID value and Layer 2 source address (from, for example, the MAC header, as shown 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 (or unnecessary) forwarding configuration for the data of interest in the received data packets.

[0125] Figure 10 Figure 1000 illustrates the use of a data forwarding method per bearer according to some implementation schemes. Figure 1000 includes a first remote UE 1002 (in... Figure 10 (marked as "UE 1"), relay UE 1004 (in Figure 10 The second remote UE 1006 (marked as "UE2") is located in the middle. Figure 10 The third remote UE 1008 (marked as "UE 3") is located in the middle. Figure 10 (marked as "UE4") and the fourth remote UE 1010 (in Figure 10 (Illustrated as "UE 5"). A first hop-by-hop path configuration 1012 has been established between the first remote UE 1002 and the relay UE 1004. A second hop-by-hop path configuration 1014 has been established between the first remote UE 1002 and the second remote UE 1006. A third hop-by-hop path configuration 1016 has been established between the third remote UE 1008 and the second remote UE 1006. A fourth hop-by-hop path configuration 1018 has been established between the first remote UE 1002 and the fourth remote UE 1010. Each of these hop-by-hop path configurations can use the above information. Figure 9 The publicly disclosed method is used to establish it.

[0126] Table 3

[0127]

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

[0129] In other cases, a data packet with an LCID can be received at relay UE 1004. This LCID provides a routing indication that data of interest within the data packet should be forwarded. Relay UE 1004 can then refer to the LCID stored during the setup of a 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 that data packet should be encapsulated in another (outgoing) data packet and transmitted on the next hop of the specific hop-by-hop path configuration. Therefore, relay UE 1004 can generate a data packet containing the data of interest, which includes the LCID corresponding to the next hop in the specific hop-by-hop path configuration determined during setup. This data packet is then transmitted by relay UE 1004 on the bearer corresponding to that specific hop in the specific hop-by-hop path configuration.

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

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

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

[0133] It is conceivable that the implementation of this third method can be extended to include devices other than the UE, such as base stations (in which case the method would be considered to operate in the UE-to-NW relay context).

[0134] Figure 11 A method 1100 for relaying a UE according to an embodiment is shown. Method 1100 includes receiving 1102 a data packet including an RLC PDU from a first remote UE, the RLC PDU including a PDCP PDU and a first adaptive header having first routing information.

[0135] Method 1100 further includes decoding 1104 first routing information from the first adaptive header at the adaptive layer of the relay UE between the RLC layer and the PDCP layer of the UE.

[0136] Method 1100 also includes determining, based on the first routing information, that 1106PDCP PDU should be forwarded to the second remote UE.

[0137] Method 1100 also includes generating 1108 a second group comprising PDCP PDU.

[0138] Method 1100 also includes forwarding the second packet to the second remote UE.

[0139] Figure 12A method 1200 for relaying a UE according to an embodiment is shown. Method 1200 includes receiving 1202 a data packet from a first remote UE, including an LCID and an RLC PDU, the RLC PDU including a PDCP PDU and a first adaptive header having first routing information.

[0140] Method 1200 further includes decoding 1204 first routing information from the first adaptive header at the adaptive layer of the relay UE between the RLC layer and the PDCP layer of the UE.

[0141] Method 1200 also includes determining, based on the LCID and first routing information, that the 1206PDCP PDU should be forwarded to the second remote UE.

[0142] Method 1200 also includes generating 1208 a second group comprising PDCP PDU.

[0143] Method 1200 further includes identifying a bearer between the 1210 relay UE and the second remote UE based on an index located in the first routing information for forwarding PDCP PDUs to the second remote UE; wherein the bearer is used to forward the second packet to the second remote UE.

[0144] Method 1200 also includes forwarding the second packet 1212 to the second remote UE.

[0145] Figure 13 A method 1300 for relaying a UE according to an embodiment is shown. Method 1300 includes receiving a data packet 1302 from a first remote UE, the data packet including a MAC header, an LCID including a routing indication, and an RLCPDU including a PDCP PDU.

[0146] Method 1300 also includes determining, based on the routing indication of the LCID and the Layer 2 address provided in the MAC header, that the 1304PDCP PDU should be forwarded to the second remote UE.

[0147] Method 1300 also includes generating 1306 a second group comprising PDCP PDU.

[0148] Method 1300 further includes identifying a bearer between the 1308 relay UE and the second remote UE based on a routing indication in the LCID for forwarding PDCP PDUs to the second remote UE; wherein the bearer is used to forward the second packet to the second remote UE.

[0149] Method 1300 also includes forwarding the second packet 1310 to the second remote UE.

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

[0151] Method 1400 further includes generating a second SL configuration message corresponding to a second bearer between a relay UE and a 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.

[0152] Method 1400 also includes sending a second SL configuration message 1406 to a second remote UE.

[0153] Method 1400 also includes receiving, 1408, a first SL reconfiguration complete message including a second index from a second remote UE.

[0154] Method 1400 also includes sending a second SL reconfiguration complete message, including a first index, to the first remote UE 1410.

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

[0156] Method 1500 further 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 indication, a second layer 2 address, and an end-to-end bearer ID.

[0157] Method 1500 also includes sending a second SL configuration message 1506 to a second remote UE.

[0158] Method 1500 also includes receiving a first SL reconfiguration complete message 1508 from a second remote UE.

[0159] Method 1500 also includes sending a second SL reconfiguration complete message 1510 to the first remote UE.

[0160] Figure 16This is a block diagram of a configurable exemplary UE 1600 according to various embodiments of the present disclosure, including instructions executed on a computer-readable medium corresponding to any of the exemplary methods and / or processes described herein. The UE 1600 includes one or more processors 1602, transceivers 1604, memory 1606, a user interface 1608, and a control interface 1610.

[0161] 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 executable by one or more processors 1602 to configure and / or facilitate the UE 1600 to perform various operations, including those described herein. For example, the execution of 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 protocols that may be used in conjunction with one or more transceivers 1604, user interface 1608, and / or control interface 1610. As another example, one or more processors 1602 may execute program code stored in 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, processor 1602 may execute program code stored in memory 1606 or other memory that, together with 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).

[0162] Memory 1606 may include memory regions for one or more processors 1602 to store variables (including operations corresponding to or including any of the exemplary methods and / or processes described herein) used in protocols, configurations, controls, and other functions of UE 1600. Furthermore, memory 1606 may include non-volatile memory (e.g., flash memory), volatile memory (e.g., static or dynamic RAM), or combinations thereof. Additionally, memory 1606 may interact with memory time slots through which one or more removable memory cards of various formats (e.g., SD cards, Memory Sticks, Compact Flash, etc.) can be inserted and removed.

[0163] 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 down-converting RF signals received from a front-end module (FEM) and providing baseband signals to one or more processors 1602. The RF circuitry may also include a transmit signal path that may include circuitry for up-converting the baseband signals provided by the baseband processor and providing an RF output signal for transmission to the FEM. The FEM may include a receive signal path that may include circuitry configured to operate on RF signals received from one or more antennas, amplify the received signals, and provide an amplified version of the received signals to the RF circuitry for further processing. The FEM may also include a transmit signal path that may include circuitry configured to amplify transmit signals provided by the RF circuitry for transmission by one or more antennas. In various implementations, amplification along the transmit or receive signal path can be performed only in the RF circuitry, only in the FEM, or in both the RF and FEM circuitries. In some implementations, the FEM circuitry may include a TX / RX switch to switch between transmit and receive mode operation.

[0164] In some exemplary embodiments, one or more transceivers 1604 include transmitters and receivers that enable 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 cooperatively with one or more processors 1602 to implement a PHY layer based on OFDM, OFDMA, and / or SC-FDMA technologies, as described herein with reference to other figures.

[0165] User interface 1608 may take various forms depending on the specific implementation, or may not be present in UE 1600. In some implementations, user interface 1608 includes a microphone, speaker, slide button, pressable button, display, touchscreen display, mechanical or virtual keypad, mechanical or virtual keyboard, and / or any other user interface features typically present on mobile phones. In other implementations, UE 1600 may include a tablet computing device with a large touchscreen display. In such implementations, one or more of the mechanical features of user interface 1608 may be replaced by equivalent or functionally equivalent virtual user interface features (e.g., virtual keypad, virtual buttons, etc.) implemented using a touchscreen display, as is well known to those skilled in the art. In other implementations, UE 1600 may be a digital computing device, such as a laptop computer, desktop computer, workstation, etc., which includes a mechanical keyboard that can be integrated, detached, or removable according to a particular exemplary implementation. Such digital computing devices may also include a touchscreen display. Many exemplary implementations of UE 1600 with a touchscreen display are capable of receiving user input, such as input relating to exemplary methods and / or processes described herein or known to those skilled in the art.

[0166] In some exemplary embodiments of this disclosure, the UE 1600 includes an orientation sensor that can be used in various ways by the features and functions of the UE 1600. For example, the UE 1600 can use the output of the orientation sensor to determine when a user has changed the physical orientation of the UE 1600's touchscreen display. An indication signal from the orientation sensor can be used by any application executing on the UE 1600 to automatically change the orientation of the screen display (e.g., from portrait to landscape) when the indication signal indicates a change of approximately 90 degrees in the physical orientation of the device. This allows the application to maintain the screen display in a user-readable manner regardless of the device's physical orientation. Additionally, the output of the orientation sensor can be used in conjunction with various exemplary embodiments of this disclosure.

[0167] The control interface 1610 may take various forms depending on the specific implementation. For example, the control interface 1610 may include an RS-232 interface, an RS-485 interface, a USB interface, an HDMI interface, a Bluetooth interface, an IEEE (“FireWire”) interface, and an I / O interface. 2 Interfaces include C-type interfaces, PCMCIA interfaces, etc. In some exemplary embodiments of this disclosure, control interface 1260 may include an IEEE 802.3 Ethernet interface, as described above. In some embodiments of this disclosure, control interface 1610 may include analog interface circuitry, including, for example, one or more digital-to-analog (D / A) converters and / or analog-to-digital (A / D) converters.

[0168] Those skilled in the art will recognize that the list of features, interfaces, and radio frequency communication standards above is merely exemplary and not limited to the scope of this disclosure. In other words, UE 1600 may include more than Figure 16 Further functionalities are shown, including, for example, a video and / or still image camera, microphone, media player, and / or recorder. Additionally, 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 memory 1606 to control such additional functionalities. For example, directional velocity and / or position estimates output from a GPS receiver can 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 this disclosure.

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

[0170] 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. Network node 1700 may include, for example, a base station, eNB, gNB, access node, or components thereof.

[0171] One or more processors 1702 may include any type of processor or processing circuitry and may be configured to perform any of the methods or processes disclosed herein. Memory 1706 may store software code, programs, and / or instructions executable by the one or more processors 1702 to configure network node 1700 to perform various operations, including those described herein. For example, execution of such stored instructions may configure network node 1700 to communicate with one or more other devices using protocols (including one or more methods and / or processes described above) according to various embodiments of this disclosure. Furthermore, execution of such stored instructions may configure and / or facilitate 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-level protocol used in conjunction with radio network interface 1704 and 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 those standardized by 3GPP. The memory 1706 may also store variables used in the protocols, configurations, control, and other functions of the network node 1700. Therefore, 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 devices, or combinations thereof.

[0172] The radio network interface 1704 may include a transmitter, receiver, signal processor, ASIC, antenna, beamforming unit, and other circuitry enabling the network node 1700 to communicate with other equipment (such as multiple compatible UEs in some embodiments). In some embodiments, the network node 1700 may include various protocols or protocol layers, such as the PHY, MAC, RLC, PDCP, and RRC layer protocols standardized by 3GPP for LTE, LTE-A, and / or 5G / NR. According to further embodiments of this disclosure, the radio network interface 1704 may include a PHY layer based on OFDM, OFDMA, and / or SC-FDMA technologies. 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.

[0173] The core network interface 1708 may include a transmitter, a receiver, and other circuitry enabling 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 (PS) core 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 SGW, MEE, SGSN, GGSN, and other physical devices, which include functionality known to those skilled in the art 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 layer 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.

[0174] Other interfaces 1710 may include transmitters, receivers, and other circuitry that enables network node 1700 to communicate with external networks, computers, databases, etc., for the operation, management, and maintenance of network node 1700 or other network equipment operatively connected thereto.

[0175] Exemplary System Architecture

[0176] In some implementations, 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 leverage service-based interactions between control plane network functions. Separating user plane functions from control plane functions allows for independent scalability, evolution, and flexible deployment (e.g., centralized or distributed (remote) locations). Modular function design allows for function reuse and enables flexible and efficient network slicing. Network functions and their network function services can interact directly or indirectly with another NF and its network function services via a service communication broker. Another intermediate function helps route control plane messages. This architecture minimizes dependencies between the AN and CN. The architecture may include an aggregated core network with a common AN-CN interface integrating different access types (e.g., 3GPP access and non-3GPP access). The architecture also supports a unified authentication framework, stateless NFs that decouple compute and storage resources, capability exposure, concurrent access to local and centralized services (to support low-latency services and access to local data networks, with user plane functions deployed near the AN), and / or roaming in the visited PLMN using both home-routed traffic and local breakout traffic.

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

[0178] Figure 18 A service-based architecture 1800 in 5GS according to one implementation is shown. As described in 3GPP TS23.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 It also shows the corresponding service-based interfaces including Nutm, Naf, Nudm, Npcf, Nsmf, Nnrf, Namf, Nnef, Nnssf, and Nausf, as well as reference points N1, N2, N3, N4, and N6. The following describes the... Figure 18 The NF shown provides some exemplary functionalities.

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

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

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

[0182] PCF 1812 supports a unified policy framework for managing network behavior. PCF 1812 provides policy rules for control plane functions to enforce them. PCF 1812 accesses subscription information related to policy decisions in the Unified Data Repository (UDR). PCF 1812 can access the UDR located in the same PLMN as PCF.

[0183] UDM 1826 supports the generation of 3GPP AKA authentication credentials, user identification processing (e.g., storage and management of SUPI for each subscriber in a 5G system), de-hiding of privacy-preserving subscription identifiers (SUCI), access authorization based on subscription data (e.g., roaming restrictions), UE service NF registration management (e.g., storing AMF for UE storage services, storing SMF for UE PDU sessions), service / session continuity (e.g., maintaining SMF / DNN allocation for ongoing sessions), MT-SMS delivery, lawful interception functionality (especially in outbound roaming scenarios where the UDM is the only contact point of the LI), subscription management, SMS management, 5GLAN group management processing, and / or external parameter configuration (expected UE behavior parameters or network configuration parameters). To provide these functions, UDM 1826 uses subscription data (including authentication data) that can be stored in a UDR. In this case, the UDM implements application logic and may not require internal user data storage, and several different UDMs can provide services to the same user in different transactions. UDM 1826 may reside in the HPLMN of its subscriber and can access information of the UDR located in the same PLMN.

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

[0185] The AMF 1820 supports the termination of the RAN CP interface (N2), the termination of the 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), transmission of SM messages between the UE and SMF, transparent proxy for routing SM messages, access authentication, access authorization, transmission of SMS messages between the UE and SMSF, SEAF, location service management for regulated services, transmission of location service messages between the UE and LMF and between the RAN and LMF, EPS bearer ID allocation for interoperability 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 in the AMF functionality can be supported in a single instance of the AMF 1820. Regardless of the number of network functions, in some implementations, only one NAS interface instance per access network between the UE and the CN terminates with one of the network functions that implements at least NAS security and mobility management. AMF 1820 may also include strategy-related functions.

[0186] In addition to the functions described above, the AMF 1820 may also include the following functions supporting non-3GPP access networks: support for the N2 interface with N3IWF / TNGF, on which some information (e.g., 3GPP cell identifier) ​​and procedures (e.g., handover related) defined on 3GPP access may not be applicable, and non-3GPP access-specific information not applicable to 3GPP access can be applied; support for NAS signaling by UE via N3IWF / TNGF, where some procedures supported by NAS signaling on 3GPP access may not be applicable to untrusted non-3GPP (e.g., paging) access; support for authentication of UEs connected via N3IWF / TNGF; management of mobility, authentication, and separate security context states for UEs connected via non-3GPP access or simultaneously via 3GPP access or non-3GPP access; support for effective coordination of RM management contexts on both 3GPP and non-3GPP access; and / or support for dedicated CM management contexts for UEs connecting via non-3GPP access. Support for all of the above functions may not be required in network slicing instances.

[0187] The SMF 1822 supports session management (e.g., session establishment, modification, and publication, including tunnel maintenance between UPF and AN nodes), UE IP address allocation and management (including optional authorization) (where UE IP addresses can be received from the UPF or from an external data network), DHCPv4 (server and client) and DHCPv6 (server and client) functions, the ability to respond to Address Resolution Protocol (ARP) requests and / or IPv6 neighbor request requests based on Ethernet PDU local cache information (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-directing configuration at the UPF to route traffic to the appropriate destination, and 5G VN group management (e.g., maintaining the topology of the involved PSA UPF, in the PSA...). Establish and publish N19 tunnels between UPFs, configure traffic forwarding at the UPF to apply local handover, and / or N6-based or N19-based forwarding, terminate the interface for policy control functions, lawful interception (for SM events and interfaces to the LI system), charge for data collection and support the billing interface, control and coordinate billing data collection at the UPF, terminate the SM portion of NAS messages, downlink data notification, initiator of AN-specific SM information sent to the AN via the AMF through N2, determination of the SSC mode of the session, control plane CIoT 5GS optimization, header compression, act as an I-SMF in the deployment of insertable / removable / repositionable I-SMFs, 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 the VPLMN for SM events and interfaces to LI systems), interaction with external DNs to transmit signaling for PDU session authentication / authorization for external DNs and / or instructing UPF and NG-RAN to perform redundant transmissions on N3 / N9 interfaces. Some or all of the SMF functions may be supported in a single instance of the SMF. However, in some implementations, not all functions need to be supported in instances of network slices. In addition to functionality, SMF 1822 may include policy-related functions.

[0188] 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 for NF service consumers to access NF service manufacturer APIs), load balancing, monitoring, overload control, etc.; and / or optionally interacting with a 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 some implementations, SCP 1824 can be deployed in a distributed manner and / or more than one SCP may exist in the communication path between NF services. SCPs can be deployed at the PLMN level, shared slice level, and slice-specific level. Carrier deployments may be left to ensure that the SCP can communicate with the relevant NRF.

[0189] UE 1816 may include devices 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), pager, laptop computer, desktop computer, 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 to utilize low-power IoT applications with short-lived UE connections. The IoT UE may exchange data with an MTC server or device via a PLMN, other UEs using ProSe or D2D communication, sensor networks, or IoT networks using technologies such as M2M, MTC, or mMTC. M2M or MTC data exchange may be machine-initiated data exchange. An IoT network describes interconnected IoT UEs, which may include uniquely identifiable embedded computing devices (within the Internet infrastructure). IoT UEs may execute background applications (e.g., keeping track of activity messages, status updates, etc.) to facilitate connectivity within the IoT network.

[0190] UE 1816 can be configured to connect or communicatively couple with (R)AN 1806 via radio interface 1830, which can be a physical communication interface or layer configured to operate using cellular communication protocols such as GSM, CDMA network protocols, keyless to talk (PTT) protocols, cellular PTT (POC) protocols, UMTS protocols, 3GPP LTE protocols, 5G protocols, NR protocols, etc. For example, UE 1816 and (R)AN 1806 can use a Uu interface (e.g., an LTE-Uu interface) to exchange control plane data via a protocol stack including PHY, MAC, RLC, PDCP, and RRC layers. DL transmissions can be made from (R)AN 1806 to UE 1816, and UL transmissions can be made from UE 1816 to (R)AN 1806. UE 1816 can also use a sidelink to communicate directly 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 the Physical Side Link Control Channel (PSCCH), Physical Side Link Shared Channel (PSSCH), Physical Side Link Discovery Channel (PSDCH), and Physical Side Link Broadcast Channel (PSBCH).

[0191] (R)AN 1806 may include one or more access nodes, which may be referred to as a base station (BS), node B, evolved Node B (eNB), next-generation Node B (gNB), RAN node, controller, transport receiving point (TRP), etc., and may include ground stations (e.g., terrestrial access points) or satellite stations that provide coverage within a geographic area (e.g., a cell). (R)AN 1806 may include one or more RAN nodes for providing coverage of macrocells, picocells, femtocells, or other types of cells. Macrocells may cover a relatively large geographic area (e.g., with a radius of several kilometers) and may allow UEs to have unrestricted access with a service subscription. Picocells may cover a relatively small geographic area and may allow UEs to have unrestricted access with a service subscription. Femtocells may cover a relatively small geographic area (e.g., a home) and may allow restricted access for UEs associated with a femtocell (e.g., a UE in a closed subscriber group (CSG), a UE of a user in a home, etc.).

[0192] Although not shown, multiple RAN nodes (such as (R)AN 1806) may be used, with Xn interfaces defined between two or more nodes. In some specific implementations, the Xn interface may include an Xn user plane (Xn-U) interface and an Xn control plane (Xn-C) interface. Xn-U provides non-guaranteed delivery of user plane PDUs and supports / provides data forwarding and flow control functions. Xn-C provides management and error handling functions for managing the functionality of the Xn-C interface; mobility support for UE 1816 in connected modes (e.g., CM-CONNECTED) includes functions for managing UE mobility in connected modes between one or more (R)AN nodes. Mobility support may include context transfer from the old (source) serving (R)AN node to the new (destination) serving (R)AN node, and control of user plane tunnels between the old (source) serving (R)AN node and the new (destination) serving (R)AN node.

[0193] The UPF 1802 can serve as an anchor point for mobility within and between RATs, an external PDU session point interconnected with the DN 1804, and a branch point supporting multihomed PDU sessions. The UPF 1802 can also perform packet routing and forwarding, packet inspection, enforce the user plane portion of policy rules, legally 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 authentication (e.g., SDF-to-QoS flow mapping), transport-level packet marking in uplink and downlink, and downlink packet buffering and downlink data notification triggering. The UPF 1802 may include an uplink classifier to support routing traffic flows to the data network. The DN 1804 can represent various network operator services, Internet access, or third-party services. The DN 1804 may include, for example, an application server.

[0194] Figure 19 This is a block diagram illustrating a component 1900, according to some example embodiments, capable of reading instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and capable of executing any or more of the methods discussed herein. Specifically, Figure 19 A schematic diagram of hardware resource 1902 is shown, which includes 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 is communicatively coupled via bus 1916. For implementations utilizing node virtualization (e.g., NFV), an executable hypervisor 1922 provides an execution environment for one or more network slices / subslices to utilize hardware resource 1902.

[0195] 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.

[0196] The memory / storage device 1914 may include main memory, disk storage devices, 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 devices, etc.

[0197] Communication resource 1924 may include interconnect or network interface components or other suitable devices for communicating with one or more peripheral devices 1904 or one or more databases 1920 via network 1918. For example, communication resource 1924 may include wired communication components (e.g., for coupling via Universal Serial Bus (USB), cellular communication components, NFC components, etc. Components (e.g.) (low power consumption) Components and other communication components.

[0198] Instruction 1912 may include software, programs, applications, applets, or other executable code for causing at least one processor in processor 1906 to perform any or more of the methods discussed herein. Instruction 1912 may reside wholly or partially within at least one processor in processor 1906 (e.g., within the processor's cache memory), memory / storage device 1914, or any suitable combination thereof. Furthermore, any portion of instruction 1912 may be transferred from peripheral device 1904 or database 1920 to hardware resource 1902. Thus, the memory of processor 1906, memory / storage device 1914, peripheral device 1904, and database 1920 are examples of computer-readable and machine-readable media.

[0199] 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 Embodiments 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 examples below. As 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.

[0200] Example Section

[0201] The following examples relate to other implementation schemes.

[0202] Example 1 is a method for relay 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 adaptive layer of the relay UE between the RLC layer and the PDCP layer of the UE; determining, based on the first routing information, that the PDCP PDU should be forwarded to a second remote UE; generating a second packet including the PDCP PDU; and forwarding the second packet to the second remote UE.

[0203] Example 2 is the method according to Example 1, wherein the first routing information includes the identity of the end-to-end bearer.

[0204] Example 3 is the method according to Example 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.

[0205] Example 4 is the method according to Example 2, wherein the end-to-end bearer is a data radio bearer (DRB).

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

[0207] Example 6 is a method according to any one of Examples 1 to 5, wherein the first routing information includes the Layer 2 address of the second remote UE.

[0208] Example 7 is a method according to any one of Examples 1 to 6, wherein the first routing information includes Quality of Service (QoS) information.

[0209] Example 8 is a method according to any one of Examples 1 to 7, wherein the second packet includes a second adaptive header, the second adaptive header including second routing information.

[0210] Example 9 is a method according to any one of Examples 1 to 8, wherein the second routing information includes the Layer 2 address of the first remote UE.

[0211] Example 10 is a method for a relay user equipment (UE), the method comprising: receiving from a first remote UE a data packet including a Logical Channel Identifier (LCID) and a Radio Link Control (RLC) Protocol Data Unit (PDU), 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 adaptive layer of the relay UE between the RLC layer and the PDCP layer of the UE; determining, based on the LCID and the first routing information, that the PDCP PDU should be forwarded to a second remote UE; generating a second packet including the PDCP PDU; and forwarding the second packet to the second remote UE.

[0212] Example 11 is the method according to Example 10, wherein the LCID is a value indicating that the PDCP PDU should be forwarded.

[0213] Example 12 is a method according to any one of Examples 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 PDCPPDU to the second remote UE; wherein the bearer is used to forward the second packet to the second remote UE.

[0214] Example 13 is the method according to Example 12, wherein the bearer between the relay UE and the second remote UE is an RLC bearer.

[0215] Example 14 is a method for relaying a user equipment (UE), the method comprising: receiving a data packet from a first remote UE, the data packet including a Media Access Control (MAC) header, a Logical Channel Identifier (LCID) including a routing indication, and a Radio Link Control (RLC) Protocol Data Unit (PDU) including a Packet Data Convergence Protocol (PDCP) PDU; determining, based on the routing indication in the LCID and a Layer 2 address provided in the MAC header, that the PDCP PDU should be forwarded to the second remote UE; generating a second packet including the PDCP PDU; and forwarding the second packet to the second remote UE.

[0216] Example 15 is the method according to Example 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 bearer is used to forward the second packet to the second remote UE.

[0217] Example 16 is the method according to Example 15, wherein the bearer between the relay UE and the second remote UE is an RLC bearer.

[0218] Example 17 is a method according to any one of Examples 14 to 16, wherein the Layer 2 address is the Layer 2 address of the first remote UE.

[0219] Example 18 is a method for establishing a relay user equipment (UE) hop-by-hop path configuration. The method includes: 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 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 the 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 from the second remote UE a first SL reconfiguration complete message including the second index; and sending to the first remote UE a second SL reconfiguration complete message including the first index.

[0220] Example 19 is the method according to Example 18, wherein each of the first bearer and the second bearer is a radio link control (RLC) bearer.

[0221] Example 20 is a method according to any one of Examples 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.

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

[0223] Example 22 is a method according to any one of Examples 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.

[0224] Example 23 is a method according to any one of Examples 18 to 22, wherein the first layer 2 address is the destination address and the second layer 2 address is the source address.

[0225] Example 24 is a method for establishing a relay UE for hop-by-hop path configuration. The method includes: 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 including a first logical channel identifier (LCID), a first layer 2 address, an end-to-end bearer ID, and a next-hop quality of service (QoS) indicator configured to provide routing indication; 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 including a second LCID, a second layer 2 address, and the end-to-end bearer ID configured to provide routing indication; sending the second SL configuration message to the second remote UE; receiving a first SL reconfiguration complete message from the second remote UE; and sending a second SL reconfiguration complete message to the first remote UE.

[0226] Example 25 is the method according to Example 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.

[0227] Example 26 is the method according to Example 24, wherein each of the first bearer and the second bearer is a radio link control (RLC) bearer.

[0228] Example 27 is a method according to any one of Examples 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.

[0229] Example 28 is a method according to any one of Examples 24 to 27, wherein the first layer 2 address is the destination address and the second layer 2 address is the source address.

[0230] Example 29 may include an apparatus comprising one or more elements for performing the method or any other method or process described herein, as described in any of the above embodiments or related to them.

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

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

[0233] Example 32 may include any of the methods, techniques, or processes described or related to any of the above examples, or any part or component thereof.

[0234] Example 33 may include an apparatus comprising one or more processors and one or more computer-readable media, the one or more computer-readable media including instructions that, when executed by the one or more processors, cause the one or more processors to perform the methods, techniques, or processes or portions thereof described in or associated with any of the above embodiments.

[0235] Example 34 may include any signal or part or component thereof that is described or associated with any of the above examples.

[0236] Example 35 may include datagrams, packets, frames, segments, protocol data units (PDUs) or messages or parts or components thereof as described in or related to any of the above examples, or as otherwise described in this disclosure.

[0237] Embodiment 36 may include any data-encoded signal or part or component thereof in or related to any of the above embodiments, or other content described in this disclosure.

[0238] Embodiment 37 may include signals or portions thereof encoded as datagrams, packets, frames, segments, PDUs or messages in any of the above embodiments or in connection with them, or other content described in this disclosure.

[0239] Example 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 any of the methods, techniques or processes or portions thereof described in or related to any of the above examples.

[0240] Example 39 may include a computer program comprising instructions, wherein execution of the program by a processing element will cause the processing element to perform any of the methods, techniques, or processes or portions thereof described in or associated with any of the above embodiments.

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

[0242] Example 41 may include methods for communicating in a wireless network as shown and described herein.

[0243] Example 42 may include a system for providing wireless communication as shown and described herein.

[0244] Example 43 may include devices for providing wireless communication as shown and described herein.

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

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

[0247] It should be recognized that the systems described herein include descriptions of specific implementations. These implementations may be combined into a single system, partially integrated into other systems, divided into multiple systems, or otherwise partitioned or combined. Furthermore, it is conceivable to use parameters, attributes, aspects, etc., of one implementation in another implementation. For clarity, these parameters, attributes, aspects, etc., are described only in one or more implementations, and it should be recognized that unless specifically stated herein, these parameters, attributes, aspects, etc., may be combined with or substituted for parameters, attributes, aspects, etc., of another implementation.

[0248] As is widely recognized, the use of personally identifiable information should comply with privacy policies and practices that are generally accepted to meet or exceed industry or governmental requirements for protecting 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 explained to users.

[0249] Although the foregoing has been described in considerable detail for clarity, it will be apparent that certain changes and modifications can be made without departing from the principles of the invention. It should be noted that many alternative ways exist to implement both the processes and apparatus described herein. Therefore, embodiments of the invention should be considered illustrative rather than restrictive, and this specification is not limited to the details given herein, but can be modified within the scope of the appended claims and their equivalents.

Claims

1. A method for relaying a user equipment (UE), the method comprising: The first remote UE receives a data packet including a Radio Link Control (RLC) Protocol Data Unit (PDU), wherein the RLC Protocol Data Unit (PDU) includes a Packet Data Convergence Protocol (PDCP) Protocol Data Unit and a first adaptive header having first routing information. The first routing information is decoded from the first adaptive header at the adaptive layer of the relay UE between the RLC layer and the PDCP layer of the relay UE, wherein the first routing information includes the identity of the end-to-end bearer that travels from the first remote UE through the relay UE and terminates at the second remote UE; Based on the first routing information, it is determined that the PDCP PDU should be forwarded to the second remote UE; Generate a second group including the PDCP PDU; as well as The second packet is forwarded to the second remote UE.

2. The method according to claim 1, wherein the end-to-end bearer is a PDCP bearer.

3. The method of claim 1, wherein the end-to-end bearer is a data radio bearer (DRB).

4. The method of claim 1, wherein the end-to-end bearer is a signaling radio bearer (SRB).

5. The method according to claim 1, wherein the first routing information includes the layer 2 address of the second remote UE.

6. The method according to claim 1, wherein the first routing information includes Quality of Service (QoS) information.

7. The method of claim 1, wherein the second packet includes a second adaptive header, the second adaptive header including second routing information.

8. The method of claim 7, wherein the second routing information includes the layer 2 address of the first remote UE.

9. A method for relaying a user equipment (UE), the method comprising: The first remote UE receives a data packet including a Logical Channel Identifier (LCID) and a Radio Link Control (RLC) Protocol Data Unit (PDU), wherein the RLC PDU includes a Packet Data Convergence Protocol (PDCP) Protocol Data Unit (PDU) and a first adaptive header having first routing information. The first routing information is decoded from the first adaptive header at the adaptive layer of the relay UE between the RLC layer and the PDCP layer of the relay UE, wherein the first routing information includes an index of a bearer between the relay UE and the second remote UE, the bearer being used to forward the PDCPPDU received from the first remote UE to the second remote UE. Based on the LCID and the first routing information, it is determined that the PDCP PDU should be forwarded to the second remote UE; Generate a second group including the PDCP PDU; as well as The second packet is forwarded to the second remote UE.

10. The method of claim 9, wherein the LCID is a value indicating that the PDCP PDU should be forwarded.

11. The method of claim 9, wherein the bearer is used to forward the second packet to the second remote UE.

12. The method of claim 9, wherein the bearer between the relay UE and the second remote UE is an RLC bearer.

13. A method for relaying a user equipment (UE), the method comprising: The data packet received from the first remote UE includes a Medium Access Control (MAC) header, a Logical Channel Identifier (LCID) including a routing indication, and a Radio Link Control (RLC) Protocol Data Unit (PDU) including a Packet Data Convergence Protocol (PDCP) Protocol Data Unit (PDU). Based on the routing indication of the LCID and the Layer 2 address provided in the MAC header, it is determined that the PDCP PDU should be forwarded to the second remote UE, wherein the routing indication is used to indicate the bearer between the relay UE and the second remote UE for forwarding the PDCP PDU received from the first remote UE to the second remote UE; Generate a second group including the PDCP PDU; as well as The second packet is forwarded to the second remote UE.

14. The method of claim 13, wherein the bearer is used to forward the second packet to the second remote UE.

15. The method of claim 13, wherein the bearer between the relay UE and the second remote UE is an RLC bearer.

16. The method of claim 13, wherein the layer 2 address is the layer 2 address of the first remote UE.

Images