Sidelink adaptation protocol for remote ue connection

Abstract

Methods, systems, and devices are provided herein that can facilitate remote UE connectivity. An enhanced version of the Backhaul Adaptation Protocol (BAP) can be used on the sidelink for sidelink communication oriented multi-hop connectivity or multi-hop connectionless sidelink communication with additional enhancements to allow multiplexing and demultiplexing of bearers over the Relay Link (RaL) RLC channel.

Description

[0001] Cross-references to related applications

[0002] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 026,904, filed May 19, 2020, entitled “Sidelink Adaptation Protocol For Remote UE Connectivity,” and U.S. Provisional Patent Application No. 63 / 094,485, filed October 21, 2020, entitled “Sidelink Adaptation Protocol For Remote UE Connectivity,” the contents of which are incorporated herein by reference. Background Technology

[0003] LTE remote UE version 15 working

[0004] In the 3GPP RAN, the Release 15 research project "Further Enhancements to LTE Device-to-Device and UE-to-Network Relays for IoT and Wearable Devices" (RP-161303: "Further Enhancements to LTE Device-to-Device and UE-to-Network Relays for IoT and Wearable Devices") was approved. The purpose of this SI is to study enhancements to the ProSe UE-to-Network Relay and LTE D2D framework for commercial and public safety applications such as wearable devices and IoT devices. Figure 1 and Figure 2 The resulting protocol stack architecture was captured (from the 3GPP TR36.746V15.1.1 study on further enhancements to LTE device-to-device (D2D) and user equipment (UE) to network relay for Internet of Things (IoT) and wearable devices; (Revision 15)). Details of the adaptation protocols were not examined.

[0005] 1.1NR Integrated Access Backhaul Version 16 Working

[0006] In 3GPP RAN, the Release 16 study project on "Integrated Access and Backhaul for NR" was approved. The purpose of this study was to identify and evaluate potential solutions for the following requirements and aspects associated with efficient operation of integrated access and radio backhaul for NR. This work resulted in the specification of a Backhaul Adaptation Protocol (BAP) (3GPP TS 38340V1.0.0) supporting data forwarding between DeNB and remote UE. The protocol stack using this BAP was captured in 38.300 (R2-2002407, CR0153 to 38.300, on Integrated Access and Backhaul for NR). It should be noted that once the corresponding data element is multiplexed onto the backhaul RLC channel, the BAP does not support multiplexing of different users or bearers with the same QoS level, and therefore does not provide a mechanism at the peer receiver BAP to route the received data element to the correct upper-layer protocol instance. This functionality is alternatively provided by the GTP-U protocol in the user plane (3GPP TS 29281V16.0.0) or the STCP protocol (Stream Transport Control Protocol, IETF RFC 4960) in the control plane.

[0007] NR Remote UE Version 17 Working

[0008] In 3GPP, the SA working group SA2 conducted a version 17 study to identify and evaluate the architectural enhancements required for 5G system design to support proximity-based services, based on the SA1 requirements defined in TS 22.278V17.1.0, TS22.261V17.1.0, and TS 22.115V17.0.0, and to determine which solutions can be implemented in accordance with the standardized specifications. Figure 3 and Figure 4 The obtained protocol stack architecture (from 3GPP TR 23.752V0.3.0 (version 17)) was captured. Details of the adapted protocols were not investigated.

[0009] This background information is provided to disclose information that the applicant deems potentially relevant. It is neither necessary to acknowledge, nor should it be construed as, any of the aforementioned information constituting prior art. Summary of the Invention

[0010] This article discloses methods, systems, and devices that can facilitate remote UE connectivity.

[0011] In one example, an enhanced version of the Backhaul Adaptation Protocol (BAP) can be used on the side link for side link communication oriented towards multi-hop connections or multi-hop connectionless side link communication, with additional enhancements to allow bearer multiplexing and demultiplexing via Relay Link (RaL) RLC channels.

[0012] In another example, there may be a new in-device packet routing data link layer protocol, represented as Relay Link Tunneling Protocol (RaLTP), which operates on a side link or Uu link via an enhanced BAP and provides bearer multiplexing and demultiplexing over RaL RLC channels to support side link communication for multi-hop connections or multi-hop connectionless side link communication.

[0013] In another example, there may be an end-to-end keep-alive procedure based on the data link layer, an end-to-end flow control procedure based on the data link layer, or an end-to-end RLF indication based on the data link layer.

[0014] The purpose of providing this summary is to introduce selected concepts in a simplified form, which are further described in the following detailed description. This summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to addressing any or all of the shortcomings pointed out in any part of this disclosure. Attached Figure Description

[0015] A more detailed understanding can be obtained from the following description, given by way of example in conjunction with the accompanying drawings, in which:

[0016] Figure 1 An exemplary user plane radio protocol stack for UE to network relay (PC5) for Layer 2 evolution is shown;

[0017] Figure 2 An exemplary control plane radio protocol stack for UE to network relay (PC5) for Layer 2 evolution is shown;

[0018] Figure 3 An exemplary user plane stack for L2 UE to network relay UE is shown;

[0019] Figure 4 An exemplary control plane for L2 UE to network relay UE is shown;

[0020] Figure 5 An exemplary RaLAP layer structure view is shown;

[0021] Figure 6 An exemplary functional view of the RaLAP sublayer is shown;

[0022] Figure 7 An exemplary RaLAP-based E2E CP PS-option 1a is shown, with use case 1 for communication via NW;

[0023] Figure 8An exemplary RaLAP-based E2E CP PS-option 1a is shown, with use case 2 for side-link communication only;

[0024] Figure 9 An exemplary RaLAP-based E2E UP PS-option 1a is shown, with use case 1 for communication via NW;

[0025] Figure 10 An exemplary RaLAP-based E2E UP PS-option 1a is shown, with use case 2 featuring side-link communication only;

[0026] Figure 11 An exemplary RaLAP-based E2E CP PS-option 1b is shown, with use case 1 for communication via NW;

[0027] Figure 12 An exemplary RaLAP-based E2E CP PS-option 1b is shown, with use case 2 featuring only side-link communication;

[0028] Figure 13 An exemplary RaLAP-based E2E UP PS-option 1b is shown, with use case 1 for communication via NW;

[0029] Figure 14 An exemplary RaLAP-based E2E UP PS-option 1b is shown, with use case 2 featuring side-link communication only;

[0030] Figure 15 An exemplary DL L2 structure of the user plane at gNB is shown;

[0031] Figure 16 An exemplary DL L2 structure is shown at the relay UE or UE to NW relay;

[0032] Figure 17 An exemplary UL L2 structure is shown at the relay UE or UE to NW relay;

[0033] Figure 18 An exemplary UL L2 structure at gNB is shown;

[0034] Figure 19 An exemplary RaLAP and RaLTP layer structure view is shown;

[0035] Figure 20 An exemplary functional view of the RaLTP sublayer is shown;

[0036] Figure 21An exemplary use case of RaLAP / RaLTP-based E2E CP PS—Option 2a, communicating via NW, is shown;

[0037] Figure 22 An exemplary use case for RaLAP / RaLTP-based E2E CP PS—Option 2a, with only side-link communication, is shown;

[0038] Figure 23 An exemplary use case of RaLAP / RaLTP-based E2E UP PS—Option 2a, communicating via NW, is shown;

[0039] Figure 24 An exemplary use case for E2E UP PS-option 2a based on RaLAP / RALTP, with only side link communication, is shown;

[0040] Figure 25 An exemplary use case of RaLAP / RaLTP-based E2E CP PS—Option 2b, communicating via NW, is shown;

[0041] Figure 26 An exemplary use case for RaLAP / RaLTP-based E2E CP PS—Option 2b, with only side-link communication, is shown;

[0042] Figure 27 An exemplary use case of RaLAP / RaLTP-based E2E UP PS—Option 2b, communicating via NW, is shown;

[0043] Figure 28 An exemplary use case for RaLAP / RaLTP-based E2E UP PS—Option 2b, with only side-link communication, is shown;

[0044] Figure 29 An exemplary DL L2 structure of the user plane at gNB is shown;

[0045] Figure 30 An exemplary DL L2 structure is shown at the relay UE or UE to NW relay;

[0046] Figure 31 An exemplary UL L2 structure is shown at the relay UE or UE to NW relay;

[0047] Figure 32 An exemplary UL L2 structure at gNB is shown;

[0048] Figure 33 An exemplary RaLAP transmitter section operation high-level view is shown;

[0049] Figure 34 An exemplary RaLTP transmitter section operation high-level view is shown;

[0050] Figure 35 An exemplary RaLAP receiver operation advanced view is shown;

[0051] Figure 36 An exemplary RaLTP receiver section operation advanced view is shown;

[0052] Figure 37 An exemplary RaLAP data PDU format is shown - Example 1;

[0053] Figure 38 An exemplary RaLAP data PDU format is shown - Example 2;

[0054] Figure 39 An exemplary RaLAP data PDU format is shown - Example 3;

[0055] Figure 40 An exemplary RaLTP data PDU format is shown - Example 1;

[0056] Figure 41 An exemplary RaLTP data PDU format is shown - Example 2;

[0057] Figure 42 An exemplary RaLAP or RaLTP control PDU format is shown - Example 1;

[0058] Figure 43 An exemplary RaLAP or RaLTP control PDU format is shown - Example 2;

[0059] Figure 44 An exemplary RaLAP or RaLTP control PDU format is shown - Example 3;

[0060] Figure 45 An exemplary TEID structure is shown - Example 1;

[0061] Figure 46 An exemplary TEID structure is shown - Example 2;

[0062] Figure 47 An exemplary RaLAP data PDU format based on local TEID is shown - Example 1;

[0063] Figure 48 An exemplary RaLAP data PDU format based on local TEID is shown - Example 2;

[0064] Figure 49 An exemplary RaLAP control PDU format based on local TEID is shown - Example 1;

[0065] Figure 50 An exemplary RaLAP control PDU format based on local TEID is shown - Example 2;

[0066] Figure 51 Exemplary displays (e.g., graphical user interfaces) that can be generated based on methods, systems, and devices for sidelink adaptation protocols used for remote UE connectivity are shown;

[0067] Figure 52A An exemplary communication system is shown;

[0068] Figure 52B An exemplary system including the RAN and core network is shown;

[0069] Figure 52C An exemplary system including the RAN and core network is shown;

[0070] Figure 52D An exemplary system including the RAN and core network is shown;

[0071] Figure 52E Another exemplary communication system is shown;

[0072] Figure 52F This is a block diagram of an exemplary device or apparatus (such as a WTRU); and

[0073] Figure 52G This is a block diagram of an exemplary computing system. Detailed Implementation

[0074] The following terms are used in this article.

[0075] Relay Link (RaL): The radio link of a relay node on the sidelink (PC5) interface or the Uu interface.

[0076] RaL RLC channel: An RLC channel between two nodes used to transmit relay link packets.

[0077] Ingress RaL RLC Channel: The RaL RLC channel on which nodes receive packets.

[0078] Outgoing RaL RLC channel: A RaL RLC channel on which nodes transmit packets.

[0079] Ingress link: The radio link on which a node receives packets.

[0080] Egress link: A radio link on which a node transmits packets.

[0081] Local Link (LoL): Access radio link on the sidelink (PC5) interface or Uu interface.

[0082] Local UE: If a node provides services to a UE via a local link, then this UE is a local UE of this node. A node whose UE is a local UE can be, for example, a base station, a relay UE, a UE-to-network relay, or a peer UE.

[0083] Remote UE: If a node provides services to a UE via a multi-hop link, then the UE is a remote UE relative to this node, wherein the multi-hop link may include a side-link only, a Uu-link only, or a combination of a side-link and a Uu-link.

[0084] Route ID: A route identifier that includes the route address and path identifier.

[0085] Translated Address: This is the address used by intermediate nodes in the communication path to overwrite the current destination field (address) in the packet before forwarding it to the next hop. Intermediate nodes maintain a mapping between the original destination address and the translated address for address translation purposes.

[0086] Transformed Tunnel Identifier: This is the tunnel identifier used by intermediate nodes along the communication path to overwrite the current TEID field (tunnel identifier) ​​in the packet before forwarding it to the next hop. Intermediate nodes maintain a mapping between the original tunnel identifier and the transformed tunnel identifier for tunnel identifier transformation purposes.

[0087] Translated Path Identifier: This is the path identifier used by intermediate nodes on the communication path to overwrite the current path field (path identifier) ​​in the packet before forwarding it to the next hop. Intermediate nodes maintain a mapping between the original path identifier and the transformed path identifier for path identifier transformation purposes.

[0088] Translated route identifier: This is a route identifier used by intermediate nodes along the communication path to overwrite the current route identifier in the packet before forwarding it to the next hop. Examples include the packet's destination field (address) and path field (path identifier). Intermediate nodes maintain a mapping between the original route identifier and the translated route identifier for route identifier translation purposes.

[0089] question

[0090] For 3GPP RAN, mechanisms supporting QoS for relay functions need to be identified, where services are provided to remote UEs via multi-hop links including Uu links and PC5 interface-side walkways. Furthermore, the impact of supporting such remote UEs on the user plane protocol stack and control plane procedures needs to be investigated. As discussed above, once the corresponding data unit is multiplexed onto the backhaul RLC channel, the BAP does not support multiplexing of different users or bearers with the same QoS, and therefore does not provide a mechanism at the peer receiver BAP to route received data units to the correct upper-layer protocol instance. This functionality is instead provided by the GTP-U protocol in the user plane (3GPP TS 29281V16.0.0) or the STCP protocol (Stream Transport Control Protocol, IETF RFC4960) in the control plane. However, in GTP version 1, UDP / IP is the only defined path protocol for delivering GTP messages, while in GTP version 0, either UDP / IP or TCP / IP can be used as the path protocol for GTP messages. Due to overhead and complexity, UDP / IP or TCP / IP are unlikely to be used as path protocols on sidelinks, such as Figure 1 , Figure 2 , Figure 3 and Figure 4 As highlighted in the protocol stack example provided, directly using GTP or STCP on link adaptation protocols such as BAP may not be efficient if these path protocols are not used, and even if BAP is reused on sidelinks, additional enhancements are required, such as the ability to differentiate / demultiplex at peer BAP receivers, different bearers with the same QoS, or different users. Therefore, the 5G NR protocol stack architecture needs to be enhanced to provide data delivery capabilities and QoS support for data exchange between peer remote UEs / RSUs or between remote UEs / RSUs and controller nodes (such as base stations or RSU base stations).

[0091] This document discloses enhancements to the NR protocol stack for sidelink data connections between a remote UE (or a UE similar to an RSU) and a base station (or a base station similar to an RSU), or for sidelink connections between two peer remote UEs. This document discloses an enhanced version of the Backhaul Adaptation Protocol (BAP) over sidelinks for sidelink communication oriented towards multi-hop connections or multi-hop connectionless sidelink communication, with additional enhancements to allow bearer multiplexing and demultiplexing on the Relay Link (RaL) RLC channel. The resulting protocol is an inter-device packet routing data link layer (DLL) protocol represented as the Relay Link Adaptation Protocol (RaLAP). This document discloses a new intra-device packet routing data link layer protocol represented as the Relay Link Tunneling Protocol (RaLTP), which operates over a sidelink or Uu link via an enhanced BAP and provides bearer multiplexing and demultiplexing over the RaL RLC channel to support sidelink communication oriented towards multi-hop connections or multi-hop connectionless sidelink communication. RaLTP also provides support for end-to-end keep-alive mechanisms for multi-hop data links. This document discloses configuration methods for RaLAP or RaLTP protocols that include data link layer address translation capabilities supporting connectionless packet routing at intermediate hops between source and destination nodes. This document also discloses a data link layer-based end-to-end keep-alive procedure. Furthermore, this document discloses a data link layer-based end-to-end flow control procedure. Finally, this document discloses a data link layer end-to-end RLF indication.

[0092] Referring to the aforementioned enhancements, the subject matter (SM) disclosed herein includes the following.

[0093] A first subject of the first device may include instructions stored in the first device that, when executed, cause the first device to: control (e.g., use) an intra-device packet routing data link layer (DLL) protocol (RaLTP) to or from a data link upper layer protocol based on RaLTP DLL routing entries; control an inter-device packet routing DLL protocol (e.g., RaLAP) to perform packet routing between the first and second devices based on RaLAP DLL routing entries; control the quality of service (QoS) of packet delivery functions based on RaLAP and RaLTP DLL QoS entries; perform inter-device packet routing actions on packets based on a first RaLAP address or RaLAP path identifier or a first RaLTP identifier; perform intra-device packet routing actions on packets based on a first RaLAP address or a first RaLTP identifier; or perform QoS actions for packet delivery based on a first RaLAP address and a first RaLTP identifier or an upper layer protocol identifier. Packet routing may be performed to or from a data link upper layer protocol.

[0094] The first device may receive information indicating parameters from the third device, which may include the following: a) multiple entries for controlling inter-device packet routing, controlling intra-device packet routing, or controlling the QoS of packet delivery from upper-layer protocols above RaLAP and RaLTP to the next hop, wherein each entry may include an upper-layer protocol identifier (ID), a RaLAP route ID including a RaLAP address and a RaLAP path ID, a translated RaLAP ID including a translated RaLAP address and a translated RaLAP path ID, a RaLTP ID, a translated RaLTP ID, a next-hop RaLAP address, an egress link ID, or an egress RLC channel ID. b) Multiple entries for controlling inter-device packet routing, controlling intra-device packet routing, or controlling QoS of packet delivery from ingress link RaLAP and RaLTP to the next hop, wherein each entry may include: RaLAP ID including RaLAP address and RaLAP path identifier, translated RaLAP ID including translated RaLAP address and translated RaLAP path identifier, RaLTPID, translated RaLTP ID, next-hop RaLAP address, ingress link ID, ingress RLC channel ID, egress link ID, or egress RLC channel ID; or c) Multiple entries for controlling inter-device packet routing or controlling intra-device packet routing from ingress link RaLAP and RaLTP to upper-layer protocols or local links, wherein each entry may include: RaLAP ID including RaLAP address and RaLAP path ID, RaLTP ID, or upper-layer protocol ID.

[0095] The parameters associated with the first device of the first topic for controlling routing or QoS may also be pre-configured in the device or specified by the standard, and may include the following: a) multiple entries for controlling inter-device packet routing, controlling intra-device packet routing, or controlling QoS of packet delivery from upper-layer protocols above RaLAP and RaLTP to the next hop, wherein each entry may include an upper-layer protocol ID, a RaLAP route ID consisting of a RaLAP address and a RaLAP path identifier, a translated RaLAP route ID including a translated RaLAP address and a translated RaLAP path ID, a RaLTPID, a translated RaLTP ID, a next-hop RaLAP address, an egress link ID, or an egress RLC channel ID; b) multiple entries for controlling inter-device packet routing, or controlling intra-device packet routing, or controlling QoS of packet delivery from ingress links RaLAP and RaLTP to the next hop, wherein each entry may include: a RaLAP ID including a RaLAP address and a RaLAP path identifier, a translated RaLAP ID including a translated RaLAP address and a translated RaLAP path identifier, a RaLTPID, a translated RaLTP... ID, next-hop RaLAP address, ingress link ID, ingress RLC channel ID, egress link ID or egress RLC channel ID; c) where each entry may include: RaLAP ID, RaLTP ID or upper-layer protocol ID including RaLAP address and RaLAP path ID.

[0096] RaLAP or RALTP may also include a transmitting section and a receiving section. The first RaLTP identifier may be the identifier of a bearer, the identifier of a tunnel associated with the bearer, the identifier of a tunnel associated with a higher-layer protocol above the in-device routing DLL protocol, or the identifier of a higher-layer protocol above the in-device routing DLL protocol. The higher-layer protocol may be a Packet Data Convergence Protocol (PDCP). The tunnel may be between the first and second devices. The tunnel may be a multi-hop tunnel between the first and second devices. The third device may be a base station, a roadside unit base station, a relay user equipment (UE), a UE-to-network (NW) relay, a UE, or a roadside unit UE. The third device may be the same as the second device. The first or second device may be a base station, a roadside unit base station, a relay UE, a UE-to-NW relay, a UE, or a roadside unit UE.

[0097] The first RaLTP identifier can be derived from the second RaLTP identifier at a fourth device on the communication path between the first and second devices. The first RaLAP address can be derived from the second RaLAP address at a fourth device on the communication path between the first and second devices. The fourth device can be a relay UE or a UE-to-NW relay.

[0098] Intra-device packet routing actions can be performed on packets based on a first RaLAP address or a first RaLTP identifier, and the intra-device packet routing action may further include: selecting from a plurality of entries for controlling inter-device packet routing, controlling intra-device packet routing, or controlling QoS of packet delivery from upper-layer protocols above RaLAP and RaLTP to the next hop, wherein the upper-layer protocol identifier of the entry corresponds to the upper-layer protocol identifier of this packet; selecting the RaLTP identifier as the first RaLTP entity from the selected entries; or including the first RaLTP identifier in the Tunnel Endpoint ID (TEID) field of this packet header.

[0099] Performing inter-device packet routing based on a first RaLAP address, RaLAP path identifier, or first RaLTP identifier may further include: selecting from a plurality of entries used to control inter-device packet routing, control intra-device packet routing, or control the QoS of packet delivery from upper-layer protocols above RaLAP and RaLTP to the next hop, wherein the upper-layer protocol identifier of the entry corresponds to the upper-layer protocol identifier of the packet; selecting a RaLAP address as the first RaLAP address from the routing identifiers in the selected entries; selecting a path identifier from the routing identifiers in the selected entries if a path identifier is available; or including the first RaLAP address and the path identifier (if available) in the destination field of the packet header.

[0100] Performing a QoS action for packet delivery based on the first RALAP address and the first RaLTP identifier or upper-layer protocol identifier may further include: a) selecting from a plurality of entries for controlling inter-device packet routing, controlling intra-device packet routing, or controlling QoS for packet delivery from upper-layer protocols above RaLAP and RaLTP to the next hop, wherein the upper-layer protocol identifier of the entry corresponds to the upper-layer protocol identifier of the packet; selecting an egress link ID and an egress RLC channel ID from the selected entries; or submitting the packet to an RLC entity corresponding to the selected egress link ID and the selected egress RLC channel ID.

[0101] Performing inter-device packet routing based on a first RaLAP address, RaLAP path identifier, or first RaLTP identifier may further include: determining the first RaLTP identifier as the identifier in the Tunnel Endpoint ID (TEID) field of the packet header; determining the first RaLAP address and RaLAP path identifier as the address and path identifier in the destination field of the packet header; selecting from multiple entries used to control inter-device packet routing, control intra-device packet routing, or control QoS of packet delivery from the RaLAP and RaLTP links to the next hop, wherein the RaLAP address of the entry corresponds to the first RaLAP address, and the entry's... The egress link for the next-hop RaLAP address is available, and the RaLTP identifier of this entry corresponds to the first RaLTP identifier; select the egress link corresponding to the next-hop RaLAP address in the selected entry above; if RaLAP address translation is applicable, select the translated RaLAP address as the first RaLAP address in the selected entry, and include the first RaLAP address in the destination field of this packet header; or if RALTP identifier translation is applicable, select the translated RaLTP identifier as the first RaLTP identifier in the selected entry, and include the first RaLTP identifier in the TEID field of this packet header.

[0102] Performing QoS actions for packet delivery based on the first RaLAP address and the first RaLTP identifier or upper-layer protocol identifier may further include: selecting from a plurality of entries for controlling inter-device packet routing, or controlling intra-device packet routing, or controlling QoS for packet delivery from the ingress link RaLAP and RaLTP to the next hop, wherein the ingress link ID of the entry corresponds to the packet's ingress link, the ingress RLC channel ID of the entry corresponds to the packet's ingress RLC channel, and the egress link ID of the entry corresponds to the selected egress link; selecting an egress RLC channel corresponding to the egress RLC channel ID of the entry selected above; or submitting the packet to an RLC entity corresponding to the selected egress link ID and the selected RLC channel ID.

[0103] Performing intra-device packet routing based on the first RaLAP address and the first RaLTP identifier or the upper-layer protocol identifier may further include: determining the first RaLTP identifier as the identifier in the Tunnel Endpoint ID (TEID) field of the packet header; determining the first RaLAP address and RaLAP path identifier as the address and path identifier in the destination field of the packet header; selecting from a plurality of entries used for controlling inter-device packet routing, controlling intra-device packet routing, and controlling the QoS of packet delivery from RaLAP and RaLTP on the ingress link to the upper-layer or local link, wherein the RaLAP address of the entry corresponds to the first RaLAP address and the RaLTP identifier of the entry corresponds to the first RaLTP identifier; selecting the upper-layer protocol identifier from the selected entries; removing the RaLAP and RaLTP headers from the packet; or submitting a packet without a RaLAP header and without a RaLTP header to the upper-layer protocol corresponding to the selected upper-layer protocol identifier.

[0104] The first and second devices can exchange end-to-end keep-alive messages. The first and second devices can be connected via one or more PC5 interface links. The first and second devices can be connected via one or more PC5 interface links and at least one Uu interface link. The first RaLTP identifier can be encoded into the packet header by reusing reserved bits in the BAP PDU header. The first RaLTP identifier can reuse the Tunnel Endpoint ID (TEID) of the Common Tunneling Protocol (GTP-U) in the user plane. At least one RaLAP entity can exist in each RaLAP routing address space or each routing network. At least one RaLTP entity can exist in each RaLTP identifier space or each routing network. The first device can receive information from the third device in PC5 RRC signaling. The first device can receive information from the third device in Uu RRC signaling. The RaLAP protocol and the RaLTP protocol can constitute a single protocol. The third device can be on the communication path between the first and second devices.

[0105] Multiple entries used to control packet routing between devices, control packet routing within devices, or control the QoS of packet delivery from upper-layer protocols above RaLAP and RaLTP to the next hop can be specific to the RaLAP routing address space, specific to the RaLTP identity space, or specific to a combination of the RaLAP routing address space and the RaLTP identity space.

[0106] Upper-layer protocol identifiers can be submitted to the RaLTP protocol, the RaLAP protocol, which has an indication of the RaLAP routing address space, or an indication of the RaLTP identifier space, or an indication of a combination of the RaLAP routing address space and the RaLTP identifier space.

[0107] Multiple entries used to control packet routing between devices, control packet routing within devices, or control the QoS of packet delivery from ingress links RaLAP and RaLTP to the next hop can be specific to the RaLAP routing address space, specific to the RaLTP identifier space, or specific to a combination of the RaLAP routing address space and the RaLTP identifier space.

[0108] Multiple entries used to control packet routing between devices, control packet routing within devices, or control the QoS of packet delivery from ingress links RaLAP and RaLTP to upper-layer or local links can be specific to the RaLAP routing address space, specific to the RaLTP identification space, or specific to a combination of the RaLAP routing address space and the RaLTP identification space.

[0109] The first and second devices can exchange end-to-end radio link failure (RLF) indication messages. The first and second devices can exchange end-to-end flow control messages. A fifth device can exchange hop-by-hop keep-alive messages, wherein the fifth device is on the communication path between the first and second devices. The first and fifth devices can exchange hop-by-hop RLF indications, wherein the fifth device is on the communication path between the first and second devices. The first and fifth devices can exchange hop-by-hop flow control messages, wherein the fifth device is on the communication path between the first and second devices.

[0110] Architecture Option 1

[0111] Sidelink Adaptation Protocol Structure and Entities

[0112] To address the problem described herein, a first option of the link adaptation protocol, referred to herein as architecture option 1, is disclosed. This architecture option assumes the use of a BAP with enhanced functionality to enable intra-node routing, including multiplexing bearers to RLC channels and demultiplexing traffic from RLC channels to corresponding bearers and forwarding it to the appropriate upper-layer protocol. The resulting protocol is referred to as the Relay Link Adaptation Protocol (RaLAP). Figure 5This document describes one possible structure for representing RaLAP at a node. In one implementation, it is disclosed that, within the RaLAP sublayer, each node instantiates one RaLAP entity per routing identifier space. In another implementation, it is disclosed that each node in the RaLAP layer includes two RaLAP entities per routing identifier space, wherein for example, an upstream node, there exists a first RaLAP entity communicating with a first subnetwork or node, and for example, a downstream node, there exists a second RaLAP entity communicating with a second subnetwork or node, including network nodes in the RaLAP sublayer acting as communication hops between the two subnetworks served by the two RaLAP entities. Such two entities will be represented as RaLAP entities paired with each other or RaLAP entities paired with each other. In yet another alternative, it is disclosed that each node instantiates one RaLAP entity per routing address space. It should be noted here that the routing identifier includes a routing address and a path identifier. In another implementation, it is disclosed that each node of the RaLAP layer includes two RaLAP entities per routing address space, wherein for example, an upstream node, there is a first RaLAP entity that communicates with a first subnetwork or node, and for example, a downstream node, there is a second RaLAP entity that communicates with a second subnetwork or node, including network nodes of the RaLAP sublayer acting as communication hops between the two subnetworks served by the two RaLAP entities.

[0113] In another implementation, it is disclosed that there is one RaLAP entity per route ID space or per route address space for each sidelink L2 destination ID, wherein there is a RaLAP entity communicating with one L2 destination ID and a second RaLAP entity communicating with a second L2 destination ID, including network nodes of the RaLAP sublayer acting as communication hops between the two sidelink L2 destination IDs.

[0114] In another implementation, it is disclosed that, for example, a unicast link ID, there is one RaLAP entity per routing ID space for each sidelink L2 link, or for example, a unicast link ID, there is one RaLAP entity per routing address space for each sidelink L2 link, wherein there is a RaLAP entity communicating with one L2 link ID and a second RaLAP entity communicating with a second L2 link ID, including network nodes of the RaLAP sublayer acting as communication hops between the two sidelink L2 links.

[0115] One or more routing identifier spaces or routing address spaces can be configured as nodes, such as relay UE node 202, UE-to-network relay node 203, remote UE, RSU, gNB, gNB DU, or gNB CU. The routing identifier space or routing address space can be defined based on one routing identifier space or one routing address space per serving gNB, or one routing identifier space or one routing address space per peer destination remote UE, or one routing identifier space or one routing address space per source UE, or one routing identifier space or one routing address space per Layer-2 destination ID, or one routing identifier space or one routing address space per routing tree, or one routing identifier space or one routing address space per routing network.

[0116] It should be noted that when each node has only one RaLAP route identifier space or route address space, the qualifying terms used in this document can be omitted, where "per route ID space" or "per route address space" is used. For example, the term "per L2 destination ID per route address space" becomes "per L2 destination ID".

[0117] Each RaLAP entity has a transmitting part and a receiving part on the node implementing RaLAP. Furthermore, the transmitting part has a corresponding receiving entity for the RaLAP entity at the communication peer node, across the side link or across the Uu link, such as... Figure 6 As shown.

[0118] Figure 6 An example of a functional view of the RaLAP sublayer at a node is shown. In this example, the receive portion on the RaLAP entity delivers a RaLAP PDU to a co-located transmit portion on the RaLAP entity. Alternatively, the receive portion may deliver a RaLAP SDU to a co-located transmit portion. When a RaLAP SDU is delivered, the receive portion removes the RaLAP header, and the transmit portion adds a RaLAP header with the same RaLAP routing ID carried in the RaLAP PDU header before removal. Therefore, in a specific implementation, delivering a RaLAP SDU in this manner is functionally equivalent to delivering a RaLAP PDU. For the remainder of this disclosure, RaLAP SDU or RaLAP PDU is simply referred to as a RaLAP data unit or RaLAP packet, unless otherwise stated.

[0119] Serve

[0120] Services provided to the upper level

[0121] The following services can be provided from the RaLAP sublayer to the upper layer: data transfer

[0122] Expectations for services from lower levels

[0123] The RaLAP sublayer expects each RLC entity to come from the following services from the lower layer: confirmed data delivery service or unconfirmed data delivery service.

[0124] Function

[0125] RaLAP supports the following functions: data transfer, inter-node routing, intra-node routing, QoS requirements, hop-by-hop flow control feedback signaling, end-to-end flow control feedback signaling, hop-by-hop RLF indication, end-to-end RLF indication, hop-by-hop hold-alive indication, or end-to-end hold-alive indication.

[0126] Inter-node routing may include the following: determination of the RaLAP destination and path of packets from the upper layer; determination of the transmitting portion of the RaLAP sublayer on the same node for routing packets from the receiving portion of the RaLAP sublayer on the same node to the next hop; in other words, the RaLAP sublayer must determine the RaLAP entity used on the node to route packets received from another RaLAP entity on the same node to the next hop; packet-to-next-hop routing; distinguishing traffic to be delivered to the upper layer from traffic to be delivered to the egress link; or distinguishing traffic to be delivered via the SL egress link from traffic to be delivered via the Uu egress link.

[0127] Intra-node routing may include the following: distinguishing traffic destined for an upper layer from traffic destined for an egress link; or demultiplexing of traffic carried (e.g., demultiplexing traffic mapped to the same SL RLC channel but destined for different upper-layer protocol entities (e.g., PDCP entities within the same node).

[0128] Support for QoS requirements may include the following: multiplexing of bearers into RLC channels, for example, determining the upper-layer protocol entity for a PDCP entity whose traffic is to be mapped to the same SL RLC channel, for example, determining the upper-layer protocol identifier for a PDCP entity identifier used for packet multiplexing, and including that identifier in the RaLAP header. In the remainder of the disclosure, this identifier will be simply referred to as the bearer identifier or bearer ID, or the identifier of the tunnel associated with the bearer, or the identifier of the tunnel associated with an upper-layer protocol above the RaLAP protocol, or the identifier of an upper-layer protocol above the RaLAP protocol; or determining the egress-side SL RLC channel for packets routed to the next hop.

[0129] End-to-end protocol stack and L2 architecture

[0130] This section discloses various alternatives to integrating RaLAP into the data link layer as an end-to-end protocol, such as a layer 2 (L2) protocol.

[0131] End-to-end protocol stack

[0132] Option 1a

[0133] In option 1a, the protocol stack in remote UE 201 does not include the RaLAP protocol. Instead, the RaLAP protocol resides in relay UE 202, UE-to-network relay 203, or base station 204.

[0134] This protocol architecture option can be used for connection-oriented or connectionless communication, where nodes implementing RaLAP (such as relay UE 202 or UE-to-network relay 203) can be configured with RaLAP configuration information as described herein. Base station 204 (e.g., Figure 7 The configuration parameters required for RaLAP operation can be configured into the communication path to the remote UE 201 (e.g., Figure 7 or Figure 9 In each node of ), configuration signaling can use RRC-specific signaling, RRC public signaling, or a combination thereof. Similarly, remote UE201 (e.g., Figure 8 Or a third entity such as the RSU can configure the configuration parameters required for RaLAP operation to the communication path to the remote UE201 (e.g., Figure 8 or Figure 10 In each node of the RRC (Regulatory Control Code) system, configuration signaling can use RRC-specific signaling, RRC common signaling, or a combination thereof. Additionally, neighboring nodes (e.g., nodes connected to non-multi-hop links) can maintain local peer control plane connections or communications, for example, at the RRC sublayer or PC5-S sublayer, to support, for example, the exchange of local configuration information between neighboring nodes. Figure 8 In the example, RRC or PC5-S communication or connection may exist between remote UE 201 and L2 relay UE 201. Similarly, RRC or PC5-S communication or connection may exist between remote UE 202 and L2 relay UE 208, where these RRC communications or connections can be used for local peer-to-peer information exchange to support the operation of the RaLAP protocol through intermediate hops in the communication path between the two remote UEs, such as... Figure 8 or Figure 10 As shown. This communication arrangement can be used for connectionless RaLAP communication on the path between L2 relay UE 202 and network relay 203, and can include multiple hops.

[0135] Option 1b

[0136] In option 1b, the protocol stack in remote UE 201 also includes the RaLAP protocol. This protocol architecture option can also be used for connection-oriented or connectionless communication, where nodes implementing RaLAP (such as UE 201, relay UE 202, or UE-to-network relay 203) can be configured with RaLAP configuration information as described herein. Base station 204 ( Figure 11 The configuration parameters required for RaLAP operation can be configured into the communication path to remote UE 201 (including remote UE 201). Figure 11 or Figure 13 In each node of ), configuration signaling can use RRC-specific signaling, RRC public signaling, or a combination thereof. Similarly, remote UE 201 ( Figure 12 Or a third entity such as the RSU can configure the configuration parameters required for RaLAP operation into the communication path to the remote UE 201. Figure 12 or Figure 14 In each node of the RRC (Regulatory Control Code) system, configuration signaling can use RRC-specific signaling, RRC common signaling, or a combination thereof. Additionally, neighboring nodes (e.g., nodes connected to non-multi-hop links) can maintain local peer control plane connections or communications, for example, at the RRC sublayer or PC5-S sublayer, to support, for example, the exchange of local configuration information between neighboring nodes. Figure 12 In the example, RRC or PC5-S communication or connection may exist between remote UE 201 and L2 relay UE 201. Similarly, RRC or PC5-S communication or connection may exist between remote UE 209 and L2 relay UE 202, where these RRC communications or connections can be used for local peer-to-peer information exchange to support the operation of the RaLAP protocol through intermediate hops in the communication path between the two remote UEs, such as... Figure 12 or Figure 14 As shown. This communication arrangement can be used for connectionless RaLAP communication on the path between L2 relay UE 202 and network relay 203, and can include multiple hops.

[0137] L2 structure

[0138] Figure 15 The downlink layer 2 (L2) data structure including the RaLAP protocol for the user plane at the gNB is shown. Figure 16 The downlink L2 data structure including the RaLAP protocol is shown for the user plane used to relay UE node 202 or UE to network relay node 203. Figure 17 The uplink L2 data structure including the RaLAP protocol is shown for the user plane used to relay UE node 202 or UE to network relay node 203. Figure 18The uplink L2 data structure, including the RaLAP protocol, for the user plane at gNB 204 is shown. It should be noted that while the terms downlink or uplink are used to describe the direction of traffic, the design concepts captured by these diagrams may not be limited to this representation. For example, for use cases involving communication between two peer-to-peer remote UEs (e.g., UE 201 and UE 209), the downlink and uplink directions can be arbitrarily determined. The term downlink can also be used instead of uplink. Similarly, the term upstream can be used instead of uplink.

[0139] Architecture Option 2

[0140] Sidelink Adaptation Protocol Structure and Entities

[0141] To address the problems described herein, a second option for the link adaptation protocol, referred to herein as Architecture Option 2, is disclosed. This architecture option assumes the use of two new protocols: the Relay Link Adaptation Protocol (RaLAP) and the Relay Link Tunneling Protocol (RaLTP). RaLAP is an inter-device packet routing data link layer (DLL) protocol similar to BAP, which, in addition to inter-node packet routing functionality, provides data aggregation and support for QoS requirements by correctly mapping data packets to RLC channels, where the RLC channels provide QoS differentiation for data delivery over one or more hops. In one implementation, the current BAP can be used as the RaLAP protocol. RaLTP is an intra-device packet routing data link layer protocol that runs on sidelinks or Uu links. RaLTP supports bearer multiplexing on or from RLC channels and provides intra-node routing of packets to upper-layer protocols such as PDCP. Figure 19This represents one possible structure for RaLTP and RaLAP at a node. The following implementations, relating to the number of RaLAP entities in a node, as described in Architecture Option 1, also apply to the RaLAP protocol as defined in Architecture Option 2. In one implementation, in the RaLAP sublayer, it is disclosed that each node instantiates one RaLAP entity per routing identifier space. In another implementation, it is disclosed that each node in the RaLAP layer includes two RaLAP entities per routing identifier space, wherein for example, an upstream node, there is one RaLAP entity communicating with a subnetwork or node, and for example, a downstream node, there is a second RaLAP entity communicating with a second subnetwork or node, including network nodes in the RaLAP sublayer acting as communication hops between the two subnetworks served by the two RaLAP entities. In yet another alternative, it is disclosed that each node instantiates one RaLAP entity per routing address space. In another implementation, it is disclosed that each node in the RaLAP layer includes two RaLAP entities per routing address space, wherein for example, an upstream node, there is a RaLAP entity that communicates with a subnetwork or node, and for example, a downstream node, there is a second RaLAP entity that communicates with a second subnetwork or node, including network nodes of the RaLAP sublayer acting as communication hops between the two subnetworks served by the two RaLAP entities.

[0142] In another implementation, it is disclosed that there is one RaLAP entity per route ID space or per route address space for each sidelink L2 destination ID, wherein there is a RaLAP entity communicating with one L2 destination ID and a second RaLAP entity communicating with a second L2 destination ID, including network nodes of the RaLAP sublayer acting as communication hops between the two sidelink L2 destination IDs.

[0143] In another implementation, it is disclosed that, for example, a unicast link ID, there is one RaLAP entity per routing ID space for each sidelink L2 link, or for example, a unicast link ID, there is one RaLAP entity per routing address space for each sidelink L2 link, wherein there is a RaLAP entity communicating with one L2 link ID and a second RaLAP entity communicating with a second L2 link ID, including network nodes of the RaLAP sublayer acting as communication hops between the two sidelink L2 links.

[0144] One or more routing identifier spaces or routing address spaces can be configured as nodes, such as relay UE node 202, UE to network relay node 203, UE 201, RSU, gNB 204, gNB DU, or gNB CU. The routing identifier space or routing address space can be defined based on one routing identifier space or one routing address space per serving gNB, or one routing identifier space or one routing address space per peer destination remote UE, or one routing identifier space or one routing address space per source UE, or one routing identifier space or one routing address space per Layer-2 destination ID, or one routing identifier space or one routing address space per routing tree, or one routing identifier space or one routing address space per routing network.

[0145] It should be noted that when each node has only one RaLAP route identifier space or route address space, the qualifying terms used in this document can be omitted, where "per route ID space" or "per route address space" is used. For example, the term "per L2 destination ID per route address space" becomes "per L2 destination ID".

[0146] Each RaLAP entity has a transmitting part and a receiving part on the node implementing RaLAP. Furthermore, the transmitting part has a corresponding receiving entity for the RaLAP entity at the communication peer node, across side links or across Uu links.

[0147] In one implementation, within the RaLTP sublayer, it is disclosed that each node instantiates one RaLTP entity per tunnel protocol identifier space. In another implementation, it is disclosed that each node in the RaLTP layer includes two RaLTP entities per tunnel protocol identifier space, wherein for example, an upstream node, there is one RaLTP entity communicating with a subnetwork or node, and for example, a downstream node, there is a second RaLTP entity communicating with a second subnetwork or node, including network nodes in the RaLTP sublayer acting as communication hops between the two subnetworks served by the two RaLTP entities.

[0148] In another implementation, it is disclosed that each sidelink L2 destination ID has one RaLTP entity per tunnel protocol ID space, wherein there is a RaLTP entity communicating with one L2 destination ID and a second RaLTP entity communicating with a second L2 destination ID, including network nodes of the RaLTP sublayer acting as communication hops between the two sidelink L2 destination IDs.

[0149] In another implementation, it is disclosed that, for example, a unicast link ID, each sidelink L2 link has one RaLTP entity per tunnel protocol ID space, wherein there is a RaLTP entity communicating with one L2 link ID and a second RaLTP entity communicating with a second L2 link ID, including network nodes of the RaLTP sublayer acting as communication hops between the two sidelink L2 links.

[0150] One or more tunnel protocol identifier spaces can be configured, for example, as relay UE node 202, UE to network relay node 203, UE 201, RSU, gNB 204, gNB DU, or gNB CU. Tunnel protocol identifiers can be defined based on one tunnel protocol identifier space per serving gNB, or one tunnel protocol identifier space per peer destination remote UE, or one tunnel protocol identifier space per source UE, or one tunnel protocol identifier space per Layer-2 destination ID, or one tunnel protocol identifier space per routing tree, or one tunnel protocol identifier space per routing network.

[0151] It should be noted that when each node has only one RaLAP route identifier space or route address space, the qualifying terms used in this document can be omitted, where "per route ID space" or "per route address space" or "per tunnel identifier space" are used. For example, the term "per L2 destination ID per route address space" becomes "per L2 destination ID".

[0152] Each RaLAP entity may have a transmitting part and a receiving part on the node implementing RaLAP. Furthermore, the transmitting part has a corresponding receiving entity for the RaLAP entity across sidelinks or across Uu links at the communication peer nodes. Similarly, each RaLTP entity has a transmitting part and a receiving part on the node implementing RaLTP. Furthermore, the transmitting part has a corresponding receiving entity, the RaLTP entity, across sidelinks or across Uu links at the communication peer nodes, such as... Figure 20 As shown.

[0153] Serve

[0154] Services provided to the upper level

[0155] The following services are provided by the RaLTP sublayer to the upper layer: delivery of user plane data; delivery of control plane data; or bearer identification (e.g., intra-node packet routing).

[0156] The following services are provided by the RaLAP sublayer to the upper layer: transmission of user plane data; transmission of control plane data; or inter-node routing and packet mapping to the RLC channel.

[0157] Expectations for services from lower levels

[0158] The RaLTP sublayer expects the following services from the lower layer: acknowledged data delivery service; or unacknowledged data delivery service.

[0159] The RaLAP sublayer can expect the following services from the lower layer: confirmed data delivery service; or unconfirmed data delivery service.

[0160] Function

[0161] RaLTP supports the following functions: data delivery; intra-node routing; end-to-end flow control feedback signaling; end-to-end RLF indication, or end-to-end keep-alive indication. Intra-node routing may include the following: demultiplexing of bearers (e.g., demultiplexing of traffic mapped to the same SL RLC channel but destined for different upper-layer protocol entities (e.g., PDCP entities within the same node), or bearer identifiers that support bearer multiplexing to RLC channels; in this document, the identifier used for bearer identification in the RaLTP sublayer will be represented as a RaLTP identifier, which may be the identifier of the bearer or the identifier of the tunnel associated with the bearer, or the identifier of the tunnel associated with an upper-layer protocol above RaLTP, or the identifier of an upper-layer protocol above RaLTP.

[0162] RaLAP supports the following functions: data delivery; inter-node routing; support for QoS requirements; hop-by-hop flow control feedback signaling, hop-by-hop RLF indication, or hop-by-hop keep-alive indication. Inter-node routing may include: determining the RaLAP destination and path of packets from the upper layer; determining the transmit portion of the RaLAP sublayer on the same node for routing packets from the receive portion of the RaLAP sublayer on the same node to the next hop; in other words, the RaLAP sublayer must determine the RaLAP entities used on the node to route packets received from another RaLAP entity on the same node to the next hop; packet-to-next-hop routing; distinguishing traffic to be delivered to the upper layer from traffic to be delivered to the egress link; or distinguishing traffic to be delivered via the SL egress link from traffic to be delivered via the Uu egress link. Support for QoS requirements may include: multiplexing of bearers into RLC channels, for example, determining the upper-layer protocol entity for a PDCP entity whose traffic is to be mapped to the same SL RLC channel, for example, determining the upper-layer protocol identifier for a PDCP entity identifier used for packet multiplexing, and including this identifier in the RaLAP header. In the remainder of the disclosure, this identifier will be represented as a bearer identifier or bearer ID. Furthermore, support for QoS requirements may include determining the egress-side SL RLC channel for packets routed to the next hop.

[0163] End-to-end protocol stack and L2 architecture

[0164] This section discloses various alternatives to integrating RaLTP and RaLAP into the data link layer as end-to-end protocols, such as layer 2 (L2) protocols.

[0165] End-to-end protocol stack

[0166] Option 2a

[0167] In option 2a, the protocol stack in remote UE 201 does not include the RaLTP or RaLAP protocols. The RaLTP protocol resides in gNB 204 and an access relay UE (e.g., relay UE 202) that provides a direct access link to remote UE 201 via a sidelink. In other words, RaLTP is an end-to-end protocol between the access relay UE and base station 204, or between two peer access relay UEs. The RaLAP protocol resides in gNB 204, UE-to-network relay 203, or a relay.

[0168] This protocol architecture option can be used for connection-oriented or connectionless communication, where nodes implementing RaLTP and RaLAP (such as relay UE 202 or UE-to-network relay 203) can be configured with RaLTP and RaLAP configuration information as described herein. Base station 204 ( Figure 21 The configuration parameters required for RaLTP and RaLAP operation can be configured into the communication path to the remote UE 201. Figure 21 or Figure 23 In each node of ), configuration signaling can use RRC-specific signaling, RRC public signaling, or a combination thereof. Similarly, remote UE 201 ( Figure 22 Or a third entity such as the RSU can configure the configuration parameters required for RaLTP or RaLAP operation to the communication path to the remote UE 201. Figure 22 or Figure 24 In each node of the RRC (Regulatory Control Code) system, configuration signaling can use RRC-specific signaling, RRC common signaling, or a combination thereof. Additionally, neighboring nodes (e.g., nodes connected to non-multi-hop links) can maintain local peer control plane connections or communications, for example, at the RRC sublayer or PC5-S sublayer, to support, for example, the exchange of local configuration information between neighboring nodes. Figure 22 In the example, RRC or PC5-S communication or connection may exist between remote UE 201 and L2 relay UE 202. Similarly, RRC or PC5-S communication or connection may exist between remote UE 209 and UE-to-network relay 203, where these RRC communications or connections can be used for local peer-to-peer information exchange to support the operation of RaLTP or RaLAP protocols through intermediate hops in the communication path between the two remote UEs, such as... Figure 22 or Figure 24 As shown. This communication arrangement can be used for connectionless RaLTP and RaLAP communication on the path between L2 relay UE 202 and network relay 203, and may include multiple hops.

[0169] Option 2b

[0170] In option 2b, the protocol stack in remote UE 201 may further include the RaLTP protocol or the RaLAP protocol, or both. For example, in one implementation, the RaLTP protocol may be part of the data link layer protocol in remote UE 201 and base station 204, or only in the two peer remote UEs (in the case of sidelink-only communication), providing end-to-end communication between end-to-end peer nodes, while RaLAP is part of the data link layer protocol in each node on the transmit section (including remote UE 201, relay UE node 202, UE-to-network relay node 203, and base station 204). In another implementation, the RaLTP protocol may be part of the data link layer protocol in UE 201 and base station 204, or in the two peer remote UEs (in the case of sidelink-only communication), providing end-to-end communication between end-to-end peer nodes, while RaLAP is only part of the data link layer in intermediate nodes on the path between remote UE 201 and the base station or peer remote UEs. In another implementation, both the RaLTP and RaLAP protocols are part of the data link layer protocols in the communication path between UE 201, base station 204 or a peer remote UE, and all other nodes in the communication path between UE 201 and base station 204 or a peer remote UE, such as Figure 25 , Figure 26 , Figure 27 or Figure 28 As shown.

[0171] Similar to architecture option 1, this protocol architecture option can also be used for connection-oriented or connectionless communication, where nodes implementing RaLAP (such as remote UE 201, relay UE 202, UE-to-network relay 203, or base station 204) can be configured with RaLTP and RaLAP configuration information as described herein. Base station 204 ( Figure 25 The configuration parameters required for RaLTP and RaLAP operation can be configured into the communication path to remote UE 201 (including remote UE 201). Figure 25 or Figure 27 In each node of ), configuration signaling can use RRC-specific signaling, RRC public signaling, or a combination thereof. Similarly, remote UE 201 ( Figure 26Or a third entity such as the RSU can configure the configuration parameters required for RaLTP or RaLAP operation to the communication path to the remote UE 201. Figure 26 or Figure 28 In each node of the network, configuration signaling can use RRC-specific signaling, RRC common signaling, or a combination thereof. Additionally, neighboring nodes (e.g., nodes connected to non-multi-hop links) can maintain local peer control plane connections or communications, for example, at the RRC sublayer or PC5-S sublayer, to support, for example, the exchange of local configuration information between neighboring nodes. Figure 26 In the example, RRC or PC5-S communication or connection may exist between remote UE 201 and L2 relay UE 202. Similarly, RRC or PC5-S communication or connection may exist between remote UE 201 and UE-to-network relay 203, where these RRC communications or connections can be used for local peer-to-peer information exchange to support the operation of RaLTP and RaLAP protocols through intermediate hops in the communication path between the two remote UEs, such as... Figure 26 or Figure 28 As shown. This communication arrangement can be used for connectionless RaLTP and RaLAP communication on the path between L2 relay UE 202 and network relay 203, and may include multiple hops.

[0172] L2 structure

[0173] Figure 29 The downlink layer-2 (L2) data structure, including the RaLTP and RaLAP protocols, is shown for the user plane at gNB 204. Figure 30 The downlink L2 data structure, including RaLTP and RaLAP protocols, is shown for the user plane used to relay UE node 202 or UE to network relay node 203. Figure 31 The uplink L2 data structure, including RaLTP and RaLAP protocols, is shown for the user plane used to relay UE node 202 or UE to network relay node 203. Figure 32 The uplink L2 data structure for the user plane at the gNB, including the RaLTP and RaLAP protocols, is shown. It should be noted that while the terms "downlink" or "uplink" are used to describe the direction of traffic, the design concepts captured by these diagrams may not be limited to this representation. For example, in use cases involving communication between two peer-to-peer remote UEs (e.g., UE 201 and UE 209), the downlink and uplink directions can be arbitrarily determined. The term "downlink" can also be used instead of "uplink." Similarly, the term "uplink" can be used instead of "uplink."

[0174] Configuration

[0175] Exemplary configurations for RaLAP and RaLTP that support routing and fulfilling QoS requirements are shown in Tables 1, 2, 3, and 4 below. This configuration can be applied to individual nodes, such as remote UE 201, relay UE 202, or UE-to-network relay 203, using dedicated or public resources' dedicated signaling, or RRC public signaling for, for example, broadcast signaling or signaling via public resources, or a combination thereof.

[0176] The parameters in Tables 1, 2, 3, and 4 can also be pre-configured in the UE. Furthermore, some values ​​for code points may be specified by the standard and have specific meanings. For example, specific values ​​for RLC channels may be reserved or specific to a particular QoS profile. Similarly, specific values ​​for upper-layer protocol IDs may be reserved or specific to a particular upper-layer protocol instance, such as a PDCP instance specific to a given signaling radio bearer or data radio bearer. It should be noted that although routing configuration parameters and QoS mapping parameters are presented together in the same table for illustrative purposes, these parameters can be configured separately in nodes; for example, routing configuration parameters can be configured separately from QoS routing mapping parameters.

[0177] Table 1: Routing and QoS Control of Traffic from the Upper Layer of RaLAP / RaLTP to the Next Hop

[0178]

[0179] Table 2: Routing and QoS Control of Traffic from Ingress Link RaLAP / RaLTP to Next Hop

[0180]

[0181] Table 3: Control of traffic routing from ingress link RaLAP / RaLTP to upper layer protocols or local link UE

[0182] Routing entries entry RaLAP Route ID (RaLAP address, path ID) RaLTP sign or tunnel sign Upper-layer protocol identifier 1 2 … n

[0183] Table 4: Routing and QoS of traffic from ingress link RaLAP / RaLTP to the next hop with paired RaLAP entities control .

[0184]

[0185] program

[0186] RaLAP / RaLTP entity processing

[0187] When an upper layer requests the creation of a RaLAP entity, a node may: create a RaLAP entity according to the request; or follow the procedures described regarding data transfer.

[0188] Establishment requests from the upper layer may include additional contextual information, such as one or more configuration parameters captured in the configuration tables (Table 1, Table 2, Table 3, or Table 4), and based on the protocol architecture principles captured in the sidelink adaptation protocol structure and entity options disclosed herein.

[0189] When an upper layer requests the release of a RaLAP entity, the node can release the RaLAP entity accordingly. When a RaLAP entity is released, the RaLTP entity mapped to that RaLAP can also be released.

[0190] When an upper layer requests the establishment of a RaLTP entity, a node can: establish a RaLTP entity according to the request; or follow the procedures for data transfer.

[0191] Establishment requests from the upper layer may include additional contextual information, such as one or more configuration parameters captured in the configuration tables (Table 1, Table 2, Table 3, or Table 4), and the protocol architecture principles captured by Options 1 and 2 regarding the sidelink adaptation protocol structure and entities.

[0192] When the upper layer requests the release of the RaLTP entity, the node can release the RaLAP entity according to the request.

[0193] Data transmission

[0194] Launch operation

[0195] The transmitting part of a RaLAP entity can receive RaLAP SDUs from the upper layer and receive RaLAP data units from the receiving part of the same RaLAP entity on the same node or from the receiving part of a paired RaLAP entity on the same node, and construct RaLAP data PDUs as needed.

[0196] Figure 33 The image shows a high-level view of the transmitter portion of the RaLAP protocol. Similarly, Figure 34 The diagram shows a high-level view of the transmitter portion of the RaLAP protocol.

[0197] It should be noted that all the descriptive texts supporting data transmission operations described below at some point in this document describe RaLAP data PDU transmission or RaLTP data PDU transmission, and the same steps in route identifier selection, tunnel identifier selection, inter-node routing, intra-node routing, and mapping to RLC channels also apply to RaLAP control PDU transmission or RaLTP control PDU transmission.

[0198] refer to Figure 33At step 221, a RaLAP SDU is received from the upper layer. At step 222, it is determined that RaLAP includes RaLTP functionality. Based on step 222, if RaLAP also supports intra-node routing, at step 223, a tunnel identifier address is selected according to the tunnel identifier (RaLTP identifier) ​​selection for RaLTP operation disclosed herein. At step 224, a RaLAP routing identifier is selected. The RaLAP address and RaLAP path identifier (if required by this RaLAP SDU) are selected according to the routing identifier selection for RaLAP operation disclosed herein. At step 225, a RaLAP data PDU is constructed by adding a RaLAP header to the RaLAP SDU according to the data PDU format disclosed herein, wherein the destination field is set to the selected RaLAP address, the path field (if required) is set to the selected RaLAP path identifier, and the TEID field is set to the selected tunnel identifier (if RaLAP also supports intra-node routing). It should be noted that when performing connectionless data routing, it may not be necessary to include the path identifier in the RaLAP header.

[0199] When a RaLAP entity has a RaLAP data PDU to transmit, the transmitting portion of the RaLAP entity may perform inter-node routing at step 226 to determine the egress link based on the routing (inter-node routing) disclosed herein. At step 227, the egress relay link (RaL) RLC channel is determined based on the mapping to RaL RLC channels disclosed herein. At step 228, this RaLAP data PDU is submitted to the selected egress RaL RLC channel of the selected egress link.

[0200] Nodes can perform data buffering on the transmit portion of a RaLAP entity, for example, until the RLC-AM entity has received an acknowledgment. In the case of RaL RLF, the transmit portion of a RaLAP entity can reroute RaLAP data PDUs to alternative paths that were not acknowledged by the lower layer before RaL RLF.

[0201] refer to Figure 34 At step 231, the transmitting part of the RaLTP entity can receive RaLAP SDU from the upper layer and construct RaLTP data PDU as needed.

[0202] At step 232, upon receiving a RaLTP SDU from the upper layer, the transmitting portion of the RaLTP entity may select a RaLTP identifier according to the data procedure disclosed herein. At step 233, a RaLTP data PDU is constructed by adding a RaLTP header to the RaLTP SDU according to the data PDU format disclosed herein, wherein the TEID field is set to the selected RaLTP identifier.

[0203] At step 234, when a RaLTP entity has a RaLTP data PDU to transmit, the RaLTP transmit portion can perform intra-node routing to determine the RaLAP entity based on bearer multiplexing (intra-node routing). At step 235, this RaLTP data PDU is submitted to the selected RaLAP entity.

[0204] Route identifier selection for RaLAP operations

[0205] RaLAP can perform route identifier selection at remote UE 201, peer remote UE, RSU UE, gNB 204, gNB RSU, UE to NW trunk 203 (e.g., when providing an access link to remote UE 201) or trunk UE 202 (e.g., when providing an access UE to remote UE 201).

[0206] RaLAP case study including RaLTP functionality

[0207] At the node, for the RaLAP SDU received from the upper layer for transmission, the RaLAP entity performs a mapping to the RaLAP address based on the traffic-to-route ID mapping configuration shown in Table 1, and, if applicable, a mapping to the RaLAP path ID.

[0208] Each entry in the traffic-to-route-ID mapping configuration includes at least one or more of the following: upper-layer protocol identifier or RaLAP route ID.

[0209] Upper-layer protocol identifier: The upper-layer protocol identifier can be, for example, a PDCP identifier, a bearer identifier, or any other identifier configured for upper-layer protocol instance differentiation or bearer differentiation, or an identifier of a tunnel associated with an upper-layer protocol above the RaLAP protocol, or an identifier assigned to an upper-layer protocol above the RaLAP protocol. The upper-layer protocol identifier can also be a traffic type specifier; and

[0210] The RaLAP route ID may include the RaLAP address and, if applicable, the path ID, as shown in Table 1.

[0211] At the node, for RaLAP SDUs received from the upper layer for transmission, the RaLAP entity may: if the traffic-to-route-ID mapping configuration is not configured as shown in Table 1, select a RaLAP address from the default control route and QoS mapping table, and if applicable, select a RaLAP path identifier. This default control route and QoS mapping table is either pre-provided or pre-configured in the UE, or is specified with default parameters for controlling routing and data delivery according to QoS requirements.

[0212] Otherwise: Select an entry from the traffic-to-routing-ID mapping configuration, whose upper-layer protocol identifier corresponds to the upper-layer protocol identifier of this RaLAP SDU.

[0213] Next, select the RaLAP address from the route IDs in the entries selected above, and select the path ID if applicable.

[0214] RaLAP case study relying on RaLTP as a standalone protocol

[0215] At the RaLAP node, for RaLAP SDUs received from the RaLTP protocol for transmission, the RaLAP entity performs a mapping to the RaLAP address based on the tunnel identifier to route ID mapping configuration shown in Table 1, and, if applicable, a mapping to the RaLAP path ID.

[0216] Each entry in the tunnel identifier to route ID mapping configuration may include one or more of the following: a tunnel identifier or a RaLAP route ID. The tunnel identifier may be a RaLTP identifier, or a PDCP identifier, a bearer identifier, or any other identifier configured for upper-layer protocol instance differentiation or bearer differentiation, or the identifier of a tunnel associated with an upper-layer protocol above the RaLAP protocol or RaLTP protocol, or an identifier assigned to an upper-layer protocol above the RaLAP protocol or RaLTP protocol. The tunnel identifier may also be a traffic type specifier.

[0217] The RaLAP route ID may include the RaLAP address and, if applicable, the path ID, as shown in Table 1.

[0218] At the RaLAP node, for a RaLAP SDU received from the RaLTP protocol for transmission, the RaLAP entity may: if the tunnel identifier to route ID mapping configuration is not configured as shown in Table 1, select a RaLAP address from the default control route and QoS mapping table, and if applicable, select a RaLAP path identifier. This default control route and QoS mapping table is either pre-provided or pre-configured in the UE, or is specified with default parameters for controlling routing and data delivery according to QoS requirements.

[0219] Otherwise: Select an entry from the tunnel identifier to route ID mapping configuration, where the tunnel identifier of the entry corresponds to the value of the TEID field of this RaLAP SDU.

[0220] Next, select the RaLAP address from the route IDs in the entries selected above, and select the path ID if applicable.

[0221] Tunnel Identifier (RaLTP Identifier) ​​Selection for RaLTP Operations

[0222] RaLTP can perform route identifier selection at remote UE 201, peer remote UE, RSU UE, gNB 204, and gNB RSU. It should be noted that, as discussed herein, the terms tunnel identifier and RaLTP identifier are used interchangeably when RaLTP is used in conjunction with RaLAP.

[0223] At the RaLTP node, for RaLTP SDUs received from the upper layer for transmission, the RaLTP entity performs the mapping to RaLTP identifiers based on the traffic-to-tunnel identifier mapping configuration shown in Table 1.

[0224] Each entry in the traffic-to-tunnel identifier mapping configuration includes at least one or more of the following: an upper-layer protocol identifier or a RaLTP identifier. The upper-layer protocol identifier can be, for example, a PDCP identifier, a bearer identifier, or any other identifier configured for upper-layer protocol instance differentiation or bearer differentiation, or the identifier of the tunnel associated with an upper-layer protocol above RaLTP, or the identifier assigned to an upper-layer protocol above RaLTP. The upper-layer protocol identifier can also be a traffic type specifier. RaLTP identifiers are shown in Table 1.

[0225] At the RaLTP node, for a RaLTP SDU received from the upper layer for transmission, the RaLTP entity may: if the traffic-to-tunnel identifier mapping configuration is not configured as shown in Table 1, select a RaLTP identifier from the default control route and QoS mapping table, which is pre-provided or pre-configured in the UE, or specified with default parameters for controlling routing and data delivery according to QoS requirements. Otherwise: select an entry from the traffic-to-tunnel identifier mapping configuration whose upper-layer protocol identifier corresponds to the upper-layer protocol identifier of this RaLTP SDU.

[0226] Next, select the RaLTP identifier (tunnel identifier) ​​from the entries selected above.

[0227] Routing (Inter-node routing)

[0228] RaLAP entities can perform routing based on the RaL routing configuration parameters described in Table 1, Table 2, Table 3, or Table 4.

[0229] Each entry in a RaL routing configuration may include one or more of the following: a RaLAP route ID, which consists of a RaLAP address and a RaLAP path identifier; or a next-hop RaLAP address.

[0230] For a RaLAP data PDU to be transmitted, the RaLAP entity may: select any egress link if the RaLAP data PDU corresponds to a RaLAP SDU received from the upper layer, and if no configuration parameters are configured in the UE as shown in the configuration disclosed herein. For example, the UE may select an egress link from a default control route and QoS mapping table that is pre-provided or pre-configured in the UE, or is specified to have default parameters for controlling routing and data delivery according to QoS requirements. Otherwise, if an entry exists in the RaL routing configuration whose RaLAP address matches the destination field, whose path identifier is the same as the path field, and whose corresponding egress link to the next-hop RaLAP address is available, the egress link corresponding to that entry's next-hop RaLAP address is selected.

[0231] Note 1: If the outgoing link is in an RLF, the link is considered unavailable. Note 2: It can be assumed that the control of routing and QoS tables described in this document is configured in the UE based on each route identifier space, or based on each route address, or based on each tunnel identifier space, or a combination thereof.

[0232] Otherwise, if there is at least one entry in the RaL routing configuration (Table 2 or Table 4) whose RaLAP address is the same as the destination field and whose egress link corresponding to the next-hop RaLAP is available, then: select an entry from the RaL routing configuration whose RaLAP address is the same as the destination field and whose egress link corresponding to the next-hop RaLAP address is available; and select the egress link corresponding to the next-hop RaLAP address of the entry selected above.

[0233] Bearer reuse (internal routing within a node)

[0234] RaLTP entities can perform intra-node routing (bearer multiplexing) based on the selected RaLTP identifier, as described in this paper regarding the selection of tunnel identifiers (RaLTP identifiers) for RaLTP operations.

[0235] For a RaLTP data PDU to be transmitted, the RaLTP entity can: select an entry from the traffic-to-tunnel identifier mapping configuration (as shown in Table 1), the RaLTP identifier of which matches the selected RaLTP identifier; select the RaLAP route identifier (or RaLAP address) of the selected entry; and select the RaLAP entity corresponding to the selected RaLAP route identifier (or route address).

[0236] To RaL RLC channel mapping

[0237] Mapping of traffic from the upper layer to the next hop to the RaL RLC channel

[0238] RaLAP case study including RaLTP functionality

[0239] For RaLAP SDUs received from the upper layer at the RaLAP node, the RaLAP entity performs mapping to the egress RaL RLC channel based on the traffic-to-RaL RLC channel mapping configuration shown in Table 1.

[0240] Each entry in the traffic-to-RaL RLC channel mapping configuration includes: an upper-layer protocol identifier, an egress link ID, or an egress RaL RLC channel ID. The upper-layer protocol identifier can be, for example, a PDCP identifier, a bearer identifier, or any other identifier configured for upper-layer protocol instance differentiation or bearer differentiation, or the identifier of a tunnel associated with an upper-layer protocol above the RaLAP protocol, or an identifier assigned to an upper-layer protocol above the RaLAP protocol. The upper-layer protocol identifier can also be a traffic type specifier.

[0241] The egress link ID can be indicated by the egress link corresponding to the next-hop RaLAP address captured in the traffic-to-routing ID mapping configuration shown in Table 1.

[0242] The egress RaL RLC channel ID can be indicated by the egress RLC channel ID captured in the traffic-to-RaL RLC channel mapping configuration as shown in Table 1.

[0243] For RaLAP SDUs received from the upper layer at the RaLAP node for transmission, whose egress links have been selected according to the routing (inter-node routing) specifications, the RaLAP entity may: if the traffic-to-RaL RLC channel mapping configuration is not configured as shown in Table 1, select the egress RaL RLC channel from the default control route and QoS mapping table, which is pre-provided or pre-configured in the UE, or is specified with default parameters for controlling routing and data delivery according to QoS requirements.

[0244] Otherwise: Select an entry from the traffic to RaL RLC channel mapping configuration, where the upper-layer protocol identifier of the entry corresponds to the upper-layer protocol identifier of this RaLAP SDU, and the egress link ID of the entry corresponds to the selected egress link; and select the egress RaL RLC channel of the ingress selected above.

[0245] RaLAP case study relying on RaLTP as a standalone protocol

[0246] For RaLAP SDUs received from the upper layer at RaLTP nodes, the RaLAP entity performs mapping to the egress RaL RLC channel based on the tunnel identifier to RaL RLC channel mapping configuration shown in Table 1.

[0247] Each entry in the Tunnel Identifier to RaL RLC Channel Mapping configuration may include: a tunnel identifier, an egress link ID, or an egress RaL RLC channel ID. The tunnel identifier can be, for example, a PDCP identifier, a bearer identifier, or any other identifier configured for upper-layer protocol instance differentiation or bearer differentiation, or the identifier of a tunnel associated with an upper-layer protocol above the RaLTP protocol, or an identifier assigned to an upper-layer protocol above the RaLTP protocol. The upper-layer protocol identifier can also be a traffic type specifier.

[0248] The egress link ID can be indicated by the egress link corresponding to the next-hop RaLAP address captured in the RaL RLC channel mapping configuration as shown in Table 1.

[0249] The exit RaL RLC channel ID can be indicated by the exit RLC channel ID captured in the tunnel identifier to RaL RLC channel mapping configuration as shown in Table 1.

[0250] For RaLAP SDUs received from the RaLTP protocol for transmission, their egress links have been selected according to the provisions regarding routing (inter-node routing). The RaLAP entity may: if the traffic-to-RaL RLC channel mapping configuration is not configured as shown in Table 1, select the egress RaL RLC channel from the default control route and QoS mapping table, which is provided in advance or pre-configured in the UE, or is specified to have default parameters for controlling routing and data delivery according to QoS requirements.

[0251] Otherwise: Select an entry from the tunnel identifier to RLC channel mapping configuration, where the tunnel identifier of the entry corresponds to the value of the TEID field of this RaLAP SDU, and the egress link ID of the entry corresponds to the selected egress link; and select the egress RaL RLC channel of the ingress selected above.

[0252] Traffic from the ingress link to the next hop via RaL RLC channel mapping

[0253] For RaLAP data PDUs received from peer RaLAP entities or co-located RaLAP entities, the transmit portion of the RaLAP entity performs mapping to the exit BH RLC channel based on the RaL ingress-to-exgress RLC channel mapping configuration, as shown in Table 2 or Table 4.

[0254] Each entry in the RaL ingress-to-egress RLC channel mapping configuration may include: ingress link ID; egress link ID; ingress RaL RLC channel ID; or egress RaL RLC channel ID.

[0255] For a RaLAP data PDU received from an ingress RaL RLC channel of an ingress link and for which an egress link has been selected: select an entry from the RaL ingress-to-egress RLC channel mapping configuration, wherein the ingress RLC channel ID of the entry matches the ingress RaL RLC channel of the RaLAP data PDU, the ingress link ID of the entry corresponds to the ingress link of the RaLAP data PDU, and the egress link ID of the entry corresponds to the selected egress link; and select an egress RaLAP RLC channel corresponding to the egress RLC channel ID of the ingress selected above.

[0256] Receive operation

[0257] Reception operation under the RaLAP protocol

[0258] Figure 35 The diagram shows a high-level view of the operation of the receiver portion of the RaLAP protocol.

[0259] RaLAP case study including RaLTP functionality

[0260] refer to Figure 35 At step 241, a RaLAP PDU is received. Then, at step 242, upon receiving a RaLAP data PDU from a lower layer (e.g., an ingress RaL RLC channel), it is determined whether the destination field of the RaLAP PDU matches the node's RaLAP address. At step 243, it is determined that the RaLAP includes RaLTP functions. At step 244, bearer demultiplexing (intra-node routing) is performed according to the demultiplexing (intra-node routing) disclosed herein to select the upper-layer protocol entity to which the RaLAP SDU should be delivered. At step 245, the RaLAP header of the RaLAP PDU is removed. At step 246, the RaLAP SDU is delivered to the selected upper-layer protocol entity.

[0261] Otherwise, starting from step 242, skipping steps 243 to 245, proceed to step 246, whereby if the RaLAP entity has a paired RaLAP entity co-located on the node, the RaLAP data unit is delivered to the transmit portion of the co-located paired RaLAP entity. Note: Protocol structures and entities for sidelink adaptation as described in Options 1 and 2; a RaLAP entity may be paired with another RaLAP object on the same node, wherein the two RaLAP entities work as hops, one before the other, relaying traffic from one part of the network or from one node of the network or from one data link to another part of the network or to another node of the network or to another data link.

[0262] Otherwise, the RaLAP data unit is delivered to the transmit section of this RaLAP entity.

[0263] RaLAP case study relying on RaLTP as a standalone protocol

[0264] After receiving a RaLAP data PDU from a lower layer (e.g., an ingress RaL RLC channel), the receiving portion of the RaLAP entity may: if the destination field of this RaLAP PDU matches the RaLAP address of this node, remove the RaLAP header of this RaLAP PDU and deliver the RaLAP SDU to the upper layer.

[0265] Otherwise: If a RaLAP entity has a paired RaLAP entity co-located on the node, the RaLAP data unit is delivered to the transmit portion of the co-located paired RaLAP entity. Note: Protocol structures and entities for sidelink adaptation as described in Options 1 and 2; a RaLAP entity may be paired with another RaLAP object on the same node, wherein the two RaLAP entities operate as hops, relaying traffic from one part of the network or from one node of the network or from one data link to another part of the network or to another node of the network or to another data link.

[0266] Otherwise, the RaLAP data unit is delivered to the transmit section of this RaLAP entity.

[0267] Receiving operations under the RaLTP protocol

[0268] Figure 36 The diagram shows a high-level view of the operation of the receiver portion of the RaLAP protocol.

[0269] refer to Figure 36At step 251, a RaLTP PDU is received. At step 252, upon receiving a RaLTP data PDU from a lower layer (e.g., RaLAP), the receiving portion of the RaLTP entity may perform bearer demultiplexing according to demultiplexing (intra-node routing) as disclosed herein. At step 253, a RaLAP SDU is removed or delivered to a selected upper-layer protocol entity.

[0270] Bearer demultiplexing (intra-node routing)

[0271] Bearer demultiplexing can be performed based on the RaL intra-node routing (bearer demultiplexing) configuration shown in Table 3.

[0272] Each entry in the RaL bearer demultiplexing configuration includes one or more of the following: a RaLAP route ID, which consists of a RaLAP address and a RaLAP path identifier (if applicable); a tunnel identifier; or an upper-layer protocol identifier.

[0273] RaLAP performs bearer demultiplexing case :

[0274] For a RaLAP SDU to be transmitted to the upper layer, the RaLAP entity may: select any upper layer protocol identifier if a RaL bearer demultiplexing configuration as shown in Table 3 exists, or in an alternative implementation, select a default upper layer protocol identifier that is pre-configured or pre-provided to the RaLAP node, or in yet another implementation, select a default upper layer protocol identifier, for example, that is specified by the standard.

[0275] Otherwise, if there is an entry in the RaL bearer demultiplexing configuration whose RaLAP address matches the destination field in the corresponding RaLAP PDU and whose tunnel identifier is the same as the TEID field, then the upper-layer protocol identifier of that entry is selected.

[0276] RaLTP performs bearer demultiplexing case :

[0277] For a RaLTP SDU to be transmitted to the upper layer, the RaLAP entity may: select any upper layer protocol identifier if a RaL bearer demultiplexing configuration as shown in Table 3 exists, or in an alternative implementation, select a default upper layer protocol identifier that is pre-configured or pre-provided to the RaLTP node, or in yet another implementation, select a default upper layer protocol identifier, for example, that is specified by the standard.

[0278] Otherwise, if there is an entry in the RaL bearer demultiplexing configuration whose RaLAP address matches the RaLAP address of this RaLTP SDU and whose tunnel identifier is the same as the TEID field, then the upper-layer protocol identifier of that entry is selected.

[0279] Flow control feedback

[0280] For a link, when flow control feedback is triggered when the buffer load exceeds a certain level, or when a RaLAP control PDU for flow control polling is received at the receiving section, the transmitting section of this RaLAP entity and the receiving section of the RaLAP entity receiving flow-controlled traffic can: construct a RaLAP control PDU for flow control feedback according to the control PDU format disclosed herein; and if the egress RaL RLC channel for the RaLAP control PDU is configured as described herein, submit this RaLAP control PDU to the configured egress RaL RLC channel of the egress link.

[0281] Otherwise, submit this RaLAP control PDU to any exit RaL RLC channel on the egress link.

[0282] The aforementioned flow control feedback mechanism is for flow control of a specific link, and flow control feedback is performed between two adjacent nodes.

[0283] This paper also discloses enhancements to the above feedback scheme to allow end-to-end flow control feedback between peer RaLAP entities. For example, this flow control feedback scheme may be beneficial for use cases where RaLAP entities provide RaLTP functionality (such as bearer multiplexing or bearer demultiplexing).

[0284] The quantity reported in flow control feedback can be the available buffer size or the preferred data rate, etc. To limit the overhead of flow control feedback reporting, the quantity reported in flow control feedback can be quantized at multiple levels, where each level corresponds to a range of the quantity being reported. For example, if the quantity reported in flow control feedback is expressed in kilobytes, the quantization level could represent, for example, a range from 0 to 100 kilobytes, the next level could represent a range from over 100 kilobytes to 200 kilobytes, and so on.

[0285] The flow control feedback mechanism described herein can also be used by the RaLTP protocol. For example, the RaLTP protocol can be used for an end-to-end flow control feedback mechanism, where a flow-controlled link, tunnel, or bearer exists between two peer RaLTP protocols. The following are exemplary implementations.

[0286] For a link, the receiving portion of a RaLTP entity receiving flow-controlled traffic: when flow control feedback is triggered when the buffer load exceeds a certain level, or when a RaLTP control PDU for flow control polling is received at the receiving portion, the transmitting portion of this RaLTP entity may: construct a RaLTP control PDU for flow control feedback according to the control PDU format disclosed herein, or transmit this RaLTP control PDU according to the RaLTP PDU transmission procedure described herein regarding transmission operations.

[0287] The above procedure can also be used by the RaLAP protocol to perform end-to-end flow control. The following is an example text:

[0288] For a link, when flow control feedback is triggered when the buffer load exceeds a certain level, or when a RaLAP control PDU for flow control polling is received at the receiving section, the transmitting section of this RaLAP entity and the receiving section of the RaLAP entity receiving flow-controlled traffic may: construct a RaLAP control PDU for flow control feedback based on the control PDU disclosed herein; or transmit this RaLAP control PDU according to the RaLAP PDU transmission procedure described herein regarding transmission operations.

[0289] The granularity of flow control feedback can be per RLC channel, per bearer, per tunnel, per sidelink L2 destination, per sidelink L2 destination per RLC channel, per RaLAP entity, per RaLAP address, per route ID, or per node.

[0290] Flow control polling

[0291] When the stream control polling is to be transmitted through the egress link, the transmitting part of the RaLAP entity at the node constructs a RaLAP control PDU for stream control polling based on the control PDU disclosed herein.

[0292] If the egress RaL RLC channel for the RaLAP control PDU is configured as specified herein, then submit this RaLAP control PDU to the configured egress RaL RLC channel of the egress link. Otherwise: submit this RaLAP control PDU to any egress RaL RLC channel of the egress link.

[0293] In an additional implementation, the RaLAP protocol may use flow control polling to request peer RaLAP protocols to increase or decrease their data rates.

[0294] The flow control polling mechanism described in this article can also be used by the RaLTP protocol. For example, the RaLTP protocol can be used for an end-to-end flow control polling mechanism, where the flow-controlled polled link, tunnel, or bearer is between two peer RaLTP protocols. The following are exemplary implementations:

[0295] For a link, when flow control polling is triggered, the RaLTP entity at RaLTP can transmit the RaLTP entity by: constructing a RaLTP control PDU for flow control polling according to the control PDU format disclosed herein; or transmitting the RaLTP control PDU according to the RaLTP PDU transmission procedure described herein regarding transmission operations.

[0296] The above procedure can also be used by the RaLAP protocol to perform end-to-end flow control polling. The following is an example text.

[0297] For a link, when flow control polling is triggered, the RaLAP entity at the node can transmit the RaLAP entity in either the form of a RaLAP control PDU for flow control, constructed according to the control PDU format disclosed herein, or by transmitting the RaLAP control PDU according to the RaLAP PDU transmission procedure described herein regarding transmission operations.

[0298] The granularity of flow control polling can be per RLC channel, per bearer, or per tunnel, per sidelink L2 destination, or per sidelink L2 destination per RLC channel, or per RaLAP entity, per RaLAP address, or per route ID, or per node.

[0299] Relay link RLF indication

[0300] Launch section

[0301] When a RaL RLF recovery failure is detected, for each egress link associated with the detected RLF, the transmit portion of the RaLAP entity may construct a RaLAP control PDU for RaL RLF indication according to the control PDU format disclosed herein. If the egress RaL RLC channel for the RaLAP control PDU is configured as specified herein, the RaLAP control PDU is submitted to the configured egress RaL RLC channel of the egress link; otherwise, the RaLAP control PDU is submitted to any egress RaL RLC channel of the egress link.

[0302] The granularity of RLF indication can be per link, per RLC channel, per bearer or per tunnel, per sidelink L2 destination, per sidelink L2 destination per RLC channel, per RaLAP entity, per RaLAP address, per route ID, or per node.

[0303] Receiving section

[0304] Upon receiving a RaLAP control PDU for backhaul RLF indication from a lower layer (e.g., the ingress RaL RLC channel), the receiving portion of the RaLAP entity may:

[0305] - Indicate to the upper layer that a return RLF indication has been received for the ingress link that received this RaLAP control PDU.

[0306] End-to-end survival

[0307] When maintaining active polling is to be transmitted via the egress link, the transmitting portion of the RaLAP entity can construct a RaLAP control PDU for maintaining active polling according to the control PDU format disclosed herein. If the egress RaLRLC channel for the RaLAP control PDU is configured as specified herein, then this RaLAP control PDU is submitted to the configured egress RaLRLC channel of the egress link. Otherwise: this RaLAP control PDU is submitted to any egress RaLRLC channel of the egress link.

[0308] The keep-alive polling mechanism described herein can also be used by the RaLTP protocol. For example, the RaLTP protocol can be used for an end-to-end keep-alive polling mechanism, where the keep-alive polled link, tunnel, or bearer is between two peer RaLTP protocols. The following are exemplary implementations.

[0309] For a link, the RaLTP entity at RaLTP may: when keep-alive polling is triggered, the transmitting portion of this RaLTP entity may: construct a RaLTP control PDU for keep-alive polling according to the control PDU format disclosed herein; or transmit this RaLTP control PDU according to the RaLTP PDU transmitting procedure described herein regarding the transmitting operation.

[0310] The above procedure can also be used by the RaLAP protocol to perform end-to-end keep-alive polling. The following is an example text.

[0311] For a link, the RaLAP entity at RaLAP may: when keep-alive polling is triggered, the transmitting portion of this RaLAP may: construct a RaLAP control PDU for keep-alive polling according to the control PDU format disclosed herein; or transmit this RaLAP control PDU according to the RaLAP PDU transmitting procedure described herein regarding the transmitting operation.

[0312] The granularity of active polling can be per link, per RLC channel, per bearer, per tunnel, per sidelink L2 destination, per sidelink L2 destination per RLC channel, per RaLAP entity, per RaLAP address, per route ID, or per node.

[0313] Tunnel End Point Identifier (TEID) Structure

[0314] As described herein, one function of the adaptation layer (i.e., RaLAP or RaLTP) is the multiplexing of bearers into RLC channels, specifically the determination of one or more upper-layer protocol entities, for example, for PDCP entities whose traffic will be mapped to the same SL RLC or Uu RLC channel. Therefore, for example, for PDCP entity identifiers used for packet multiplexing and included in the adaptation layer header, the multiplexing function may need to identify the upper-layer protocol instance associated with the data packet, i.e., the upper-layer protocol identifier. This document refers to such identifiers (e.g., bearer identifier or simply bearer ID, PDCP entity identifier, identifier of the tunnel associated with the bearer, identifier of the tunnel associated with an upper-layer protocol above the RaLAP or RaLTP protocol, identifier of the upper-layer protocol above the RaLAP or RaLTP protocol, or the RaLTP protocol identifier). Another function of the adaptation layer (e.g., RaLAP or RALTP) is the demultiplexing of bearers, for example, the demultiplexing of traffic mapped to the same SL RLC channel but destined for different upper-layer protocol entities (e.g., PDCP entities within the same node). This feature is also referred to in this disclosure as intra-node routing.

[0315] In one embodiment, the intra-node routing identifier or bearer identifier (generally referred to as TEID in this disclosure) may have local meaning only within the node performing a multiplexing function (e.g., source remote UE 201 or base station 204) or a demultiplexing function (e.g., destination remote UE 209 or base station 204, etc.). In another embodiment, the TEID may have a broader meaning, for example, across more than one node, such as in source remote UE 201 and destination remote UE 209, or in base station and destination remote UE 209, or in source remote UE 201 and base station 204, etc.

[0316] In one implementation, the TEID structure may include an identifier of the source node and a local TEID value, wherein the local TEID has only local meaning. In another implementation, the TEID structure may include an identifier of the destination node and a local TEID value, wherein the local TEID has only local meaning. In yet another implementation, the TEID may be a single component identifier, wherein the TEID has only local meaning or a broader meaning as defined herein.

[0317] A source node (e.g., source remote UE 201 or base station 204) and a destination node (e.g., destination remote UE 209 or base station 204) may exchange signaling, for example, in the control plane, to configure each other using their respective TEIDs. A source node (e.g., source remote UE 201 or base station 204) may configure a destination node (e.g., destination remote UE 209 or base station 204) using one or more TEIDs of the source node, or one or more TEIDs of the destination node, or both. Similarly, a destination node (e.g., destination remote UE 209 or base station 204) may configure a source node (e.g., source remote UE 201 or base station 204) using one or more TEIDs of the destination node, or one or more TEIDs of the source node, or both. Alternatively, a third entity (e.g., base station 204) may use one or more TEIDs to configure the source remote UE 201 or the destination remote UE 209, where one or more TEIDs may be significant in both the source and destination nodes.

[0318] As discussed herein, one or more tunnel protocol identifier spaces can be configured in nodes, such as relay UE node 202, UE-to-network relay node 203, source remote UE 201, remote destination UE 209, UE, RSU, gNB 204, gNBDU, or gNB CU. Tunnel protocol identifiers can be defined based on one tunnel protocol identifier space per serving gNB, or one tunnel protocol identifier space per destination remote UE 209, or one tunnel protocol identifier space per source remote UE 201, or one tunnel protocol identifier space per Layer-2 destination ID, or one tunnel protocol identifier space per routing tree, or one tunnel protocol identifier space per routing network, etc. In this case, the TEID structure may additionally include TEID space identifiers. Similarly, if a node (e.g., source remote UE 201, destination remote UE 209, U2U trunk, or U2N trunk) is configured with more than one node address space (e.g., the source UE is configured with more than one source node address space), the node address structure may include a node address space identifier and the addresses of nodes within that address space. For example, a source node address may include an address space identifier and the addresses of sources within that address space.

[0319] Protocol data units, formats and parameters

[0320] Protocol Data Unit

[0321] Data PDU

[0322] In addition to the upper-layer data in the PDU header, RaLAP data PDUs or RaLTP data PDUs can also be used to transmit one of the following.

[0323] Control PDU

[0324] RaLAP control PDUs or RaLTP control PDUs are used to transmit one of the following [in addition to the PDU header]: flow control feedback at various granularities as described herein with respect to flow control feedback; flow control polling at various granularities as described herein with respect to flow control polling; RaL RLF indication at various granularities as described herein with respect to trunk link RLF indication; or hold-up activity polling at various granularities as described herein with respect to end-to-end hold-up activity.

[0325] Format

[0326] RaLAP PDU or RaLTP PDU is a bit string that is byte-aligned in length (e.g., a multiple of 8 bits). The format of RaLAPPDU and RaLTP PDU is described below in a later section.

[0327] Data PDU

[0328] RaLAP

[0329] Figure 37 An exemplary implementation of a RaLAP data PDU is shown. In this example, the TEID field (tunnel identifier) ​​is encoded with 2 bits, the destination field with 10 bits, and the path field (or path identifier) ​​with 10 bits. The D / C (data or control) field is encoded with 1 bit, and only one reserved (R) bit exists. The data field starts at the fourth octet and can be multiple octets long.

[0330] Figure 38 Another exemplary implementation of the RaLAP data PDU is shown. In this example, the TEID field (tunnel identifier) ​​is encoded with 3 bits, the destination field with 10 bits, and the path field (or path identifier) ​​with 10 bits. The D / C (data or control) field is encoded with 1 bit, and there are no reserved (R) bits. The data field starts from the fourth octet and can be multiple octets long.

[0331] Figure 39Another exemplary implementation of the RaLAP data PDU is shown. In this example, the R bits can be reused to signal the TEID. In a first implementation, the TEID field can be encoded with 3 bits, where all reserved bits are used to represent the TEID. In a second implementation, as shown by the circle around the R bits and the arrow pointing from the solid line to the dashed line, the TEID (Tunnel Identifier) ​​field can be encoded with more than 3 bits, the destination field can be encoded with less than 10 bits, or the path field (or path identifier) ​​can be encoded with less than 10 bits. In this implementation, if a D / C (Data or Control) field is present, it can be encoded with 1 bit; otherwise, the DC field is absent. However, in a third implementation, the R field can be encoded with less than 3 bits; for example, the TEID field can use up to all three R bits. In this implementation, the R bits may not be present. The data field starts with the fourth octet and can be multiple octets long.

[0332] RaLTP

[0333] Figure 40 An exemplary implementation of a RaLTP data PDU is shown. In this example, the TEID (Tunnel Identifier) ​​field is encoded as 4 bytes (e.g., 4 octets). Data fields begin at the fifth octet and can be multiple octets long.

[0334] Figure 41 Another exemplary implementation of a RaLTP data PDU is shown. In this example, the TEID field (tunnel identifier) ​​is encoded as 4 octets. The D / C (data or control) field is encoded as 1 bit, with three reserved (R) bits. The data field starts at the fifth octet and can be multiple octets long.

[0335] Control PDU

[0336] The following are examples of control PDUs for RaLAP or RaLTP.

[0337] Figure 42Exemplary implementations of RaLAP or RaLTP control PDUs are shown. In a first implementation, the PDU type may be encoded with 3 bits. In a second implementation, as indicated by the circle around the R bits and the arrow pointing from the solid line to the dashed line, the PDU type may be encoded with more than 3 bits. If a D / C (data or control) field is present, it may be encoded with 1 bit; otherwise, the DC field is absent. Similarly, the PDU type encoding may reuse some bits from the R bits. In this second implementation, the R bits may be encoded with fewer than 4 bits, and may be absent depending on the size of the PDU type field. In a third implementation, the PDU type may be encoded with fewer than 3 bits. In this third implementation, there may be more than 4 reserved bits. In this example, the TEID field is absent. One possible specification direction is to define a standardized TEID value for the exchange of control PDUs between peer-to-peer RaLAP or RaLTP protocols. Alternatively, the TEID for the control PDU may be configured in the exchange between nodes or nodes. It should be noted that, in an alternative implementation, the TEID field may be included in the control PDU, where the TEID field can be 1 to 4 bits long. In the case where the TEID field is 4 bits long, there is no R bit.

[0338] Figure 43 Another exemplary implementation of RaLAP or RaLTP control PDUs is shown. In this example, the PDU type field is encoded with 3 bits. The D / C (data or control) field is encoded with 1 bit. The TEID field is encoded with 4 octets.

[0339] Figure 44 Exemplary implementations of RaLAP or RaLTP control PDUs are shown. In a first implementation, the PDU type may be encoded with 3 bits. In a second implementation, as indicated by the circle around the R bits and the arrow pointing from the solid line to the dashed line, the PDU type may be encoded with more than 3 bits. If a D / C (data or control) field is present, it may be encoded with 1 bit; otherwise, the DC field is absent. Similarly, the PDU type encoding may reuse some bits from the R bits. In this second implementation, the R bits may be encoded with fewer than 4 bits, and may be absent depending on the size of the PDU type field. In a third implementation, the PDU type may be encoded with fewer than 3 bits. In this third implementation, there may be more than 4 reserved bits. In this example, the TEID field is 4 octets long. It should be noted that in a fourth implementation, the TEID field may be included in the control PDU, where the TEID field may be 1 to 4 bits long. In the case where the TEID field is 4 bits long, the R bits are absent.

[0340] Example of TEID structure

[0341] This document provides an exemplary illustration of the Tunnel Endpoint Identifier (TEID) structure and an example of a Tunnel Endpoint Identifier (TEID) structure within a Sidelink Adaptor Layer Protocol (RaLAP) header. It should be understood that the exemplary illustration of the TEID provided herein can be used within any PDU header (control or data) of the Sidelink Adaptor Layer Protocol (RaLAP or RaLTP) as presented in this disclosure. Figure 45 In this context, TEID is encoded in 4-byte format (e.g., 4 octets), with the source field encoded in 10-bit format and the local TEID (L-TEID) encoded in 22-bit format. Figure 46 In this context, TEID is also encoded in 4-byte format, with the source field encoded in 24-bit format, and the local TEID can be encoded in 8 bits or less (e.g., 5 bits). It should be noted that in... Figure 45 and Figure 46 In this standard, the source and L-TEID can be encoded using any combination of bits. For example, if the standard decides to use the same source field length as C-RNTI, the source field may already be encoded with 16 bits. In this case, the TEID can be encoded with 16 bits or less, with the remaining bits used for data or other header information. Figure 47 and Figure 48 The use of the source remote node (exemplary source remote UE 201) identifier and local TEID in the data PDU header of the sidelink adaptation protocol is shown. Figure 47 This example illustrates a scenario where the source field is encoded with 24 bits and the local TEID is encoded with 5 bits. This example assumes the source can be encoded like the sidelink source layer 2 ID, which is encoded with 24 bits. The 5-bit encoding of the local TEID assumes the local TEID range is the same as the maximum of 32 bearers currently specified for each UE communication for the Uu interface. Figure 48 This example illustrates a scenario where, for a total of 512 possible bearers for each source remote UE 201, or for a total of 512 possible bearers for each destination remote UE 209, or for a total of 512 possible bearers per context of source remote UE 201 in base station 204, or for a total of 512 possible carriers per context of destination remote UE 209 in base station 204, the source field is encoded with 24 bits and the local TEID with 9 bits. This example assumes that the source can be encoded like the side-link source layer 2 ID, which is encoded with 24 bits. The 5-bit encoded local TEID assumes that the local TEID range is the same as the maximum number of 512 bearers for each UE's NR side-link communication. Figure 47 and Figure 48 In both cases, the destination field is also encoded in 24-bit format, assuming that the destination field can be encoded in the same way as the sidelink destination layer-2 ID, which is encoded in 24-bit format. Figure 49 and Figure 50The use of the source remote node 201 (e.g., source remote UE) identifier and local TEID in the control PDU header of the sidelink adaptation protocol is shown, wherein the local TEID and destination field in the source field are encoded in the same manner as in the data PDU header.

[0342] parameter

[0343] Unless otherwise specified in the definition of each field, the bits in the parameters can be interpreted as follows: the leftmost bit string is the first bit and also the most significant bit, and the rightmost bit is the last bit and also the least significant bit.

[0344] Unless otherwise stated, integers are encoded using the standard binary encoding for unsigned integers. In all cases, when read from the PDU, the bits are arranged in order from MSB to LSB.

[0345] destination :

[0346] This field carries the RaLAP address of the destination of the base station, peer remote UE, or relay node (e.g., relay UE node 202, UE to network relay node 203). In the context of the adaptation protocol layer, this field can be interpreted as the identifier of the destination remote UE 209, or the identifier of the destination base station 204, or the identifier of any other destination node.

[0347] source :

[0348] This field carries the RaLAP address of the source, such as the base station, remote UE 201, or relay node (e.g., relay UE node 202, UE to network relay node 203). In the context of the adaptation protocol layer, this field can be interpreted as the identifier of the source remote UE 201, or the identifier of the source base station 204, or the identifier of any other source node.

[0349] TEID :

[0350] This field identifies the bearer or upper-layer protocol above the adaptation layer. This field may have only a local meaning relative to the context of the node (e.g., the source node or the remote node). Alternatively, this field may have a broader meaning, such as spanning more than one context, for example, across the context of the source remote node (e.g., source remote UE 201) and the context of the destination remote node (e.g., destination remote UE 209).

[0351] path :

[0352] This field carries the RaLAP path identifier.

[0353] data :

[0354] In the case of the RaLTP protocol, this field carries the RaLTP SDU (e.g., PDCP PDU).

[0355] Similarly, in the case of a RaLAP protocol that also provides RaLTP functionality, this field carries the RaLAP SDU (e.g., PDCP PDU). In the case of RaLAP operating as a separate RaLTP protocol, this field carries the RaLAP SDU (e.g., RaLTPPDU).

[0356] R :

[0357] Reserved. In a given version of the protocol, the reserved bits can be set to 0. In a further version of the protocol, one or more of the reserved bits can be used to execute additional control messages or information between peer RaLAP protocols or between peer RaLTP protocols.

[0358] D / C :

[0359] In the case of the RaLAP protocol, this field indicates whether the corresponding RaLAP PDU is a RaLAP data PDU or a RaLAP control PDU. Similarly, in the case of the RaLTP protocol, this field indicates whether the corresponding RaLTP PDU is a RaLTP data PDU or a RaLTP control PDU.

[0360] Table 5: D / C Field

[0361] Bit describe 0 RaLAP control PDU for the RaLAP protocol or RaLTP control PDU for the RaLTP protocol 1 RaLAP data PDUs for the RaLAP protocol or RaLTP data PDUs for the RaLTP protocol

[0362] PDU type :

[0363] This field indicates the type of control information included in the corresponding RaLAP control PDU or RaLTP control PDU.

[0364] Table 6: Example 1 of PDU type

[0365] Bit describe 000 End-to-end keep-alive polling 001 End-to-end activity response 010 End-to-end RLF indication 011 End-to-end flow control feedback 100 End-to-end flow control polling 101-111 reserve

[0366] Table 7: Example 2 of PDU type

[0367]

[0368]

[0369] RaL RLC Channel ID :

[0370] The RaL RLC channel ID is the identifier of the RAL RLC channel. It can be 16 bits long.

[0371] Router ID :

[0372] The route ID is the identifier of a route, which includes the route address and path identifier. It can be 20 bits long.

[0373] It should be understood that performing the actions described in this document (such as...) Figures 1 to 50 The entities shown in the diagram can be logical entities. These steps can be stored in, for example, Figure 52F or Figure 52G The device, server, or computer system shown is stored in its memory and executed on its processor. It is conceivable that this document (e.g., Figures 1 to 50 Skipping steps, combining steps, or adding steps between the disclosed exemplary methods.

[0374] Table 8 provides exemplary abbreviations and definitions.

[0375] Table 8 - Abbreviations and Definitions

[0376]

[0377]

[0378]

[0379] Figure 51 An exemplary display (e.g., a graphical user interface) that can be generated based on methods, systems, and devices for sidelink adaptation protocols for remote UE connectivity, as discussed herein, is illustrated. Display interface 901 (e.g., a touchscreen display) may provide text associated with the sidelink adaptation protocol for remote UE connectivity, such as sidelink adaptation-related parameters, method flows, and the sidelink adaptation protocol associated with the current conditions, within box 902. Progress of any step discussed herein (e.g., messages sent or success of a step) may be displayed in box 902. Furthermore, graphical output 902 may be displayed on display interface 901. Graphical output 903 may be a device topology for implementing the sidelink adaptation protocol for remote UE connectivity, graphical output of the progress of any method or system discussed herein, etc.

[0380] The 3rd Generation Partnership Project (3GPP) developed technical standards for cellular telecommunications network technologies, including radio access, core transport networks, and service capabilities, encompassing studies on codecs, security, and quality of service. Recent Radio Access Technology (RAT) standards include WCDMA (commonly referred to as 3G), LTE (commonly referred to as 4G), LTE Advanced, and New Radio (NR) (also referred to as "5G"). It is hoped that the 3GPP NR standard will continue to evolve and include definitions for next-generation radio access technologies (new RATs), providing new flexible radio access below 7 GHz and new ultra-mobile broadband radio access above 7 GHz. This flexible radio access is expected to include new non-backward-compatible radio access in new spectrum below 6 GHz and is expected to include different operating modes that can be multiplexed together in the same spectrum to address a wide range of 3GPP NR use cases with varying needs. Ultra-mobile broadband is expected to include centimeter-wave and millimeter-wave spectrum, which will provide opportunities for ultra-mobile broadband access, such as for indoor applications and hotspots. Specifically, it is anticipated that ultra-mobile broadband and flexible radio access below 7 GHz will share a common design framework, while featuring centimeter-wave and millimeter-wave-specific design optimizations.

[0381] 3GPP has identified a variety of use cases that NR is expected to support, resulting in diverse user experience requirements regarding data rates, latency, and mobility. Use cases include the following general categories: enhanced mobile broadband (eMBB), ultra-reliable low-latency communications (URLLC), massive machine-type communications (mMTC), network operations (e.g., network slicing, routing, migration and interworking, energy saving), and enhanced vehicle-to-everything (eV2X) communications, which can include any of vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), vehicle-to-network (V2N), vehicle-to-pedestrian (V2P), and vehicle-to-vehicle communications with other entities. Specific services and applications within these categories include, for example, surveillance and sensor networks, remote device control, two-way remote control, personal cloud computing, video streaming, cloud-based wireless offices, first responder connectivity, car emergency calls, disaster alarms, real-time gaming, multi-person video calling, autonomous driving, augmented reality, haptic internet, virtual reality, home automation, robotics, and drones. This article considers all of these and other use cases.

[0382] Figure 52A An exemplary communication system 100 is shown, in which methods and apparatuses for sidelink adaptation protocols for remote UE connections, such as those described and claimed herein, can be used. Figures 5 to 50The system and method are illustrated. Communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, 102e, 102f, or 102g (which may generally or collectively be referred to as WTRU 102 or WTRUs 102). Communication system 100 may include radio access networks (RANs) 103 / 104 / 105 / 103b / 104b / 105b, core networks 106 / 107 / 109, a public switched telephone network (PSTN) 108, the Internet 110, other networks 112, and network services 113. Network services 113 may include, for example, V2X servers, V2X functions, ProSe servers, ProSe functions, IoT services, video streaming, or edge computing.

[0383] It should be understood that the concepts disclosed herein can be used with any number of WTRUs, base stations, networks, or network elements. Each of the WTRUs 102a, 102b, 102c, 102d, 102e, 102f, or 102g can be any type of device or equipment configured to operate or communicate in a wireless environment. Although each WTRU 102a, 102b, 102c, 102d, 102e, 102f, or 102g may... Figure 52A , Figure 52B , Figure 52C , Figure 52D , Figure 52E or Figure 52F While described as a handheld wireless communication device, it should be understood that each WTRU may include or embody any type of device or equipment configured to transmit or receive wireless signals in various envisioned use cases for 5G wireless communication, including by way of example only, user equipment (UE), mobile station, fixed or mobile subscriber unit, pager, cellular phone, personal digital assistant (PDA), smartphone, laptop, tablet, netbook, notebook computer, personal computer, wireless sensor, consumer electronics, wearable devices (such as smartwatches or smart clothing), medical or e-health devices, robots, industrial equipment, drones, vehicles (such as cars, buses, trucks, trains, or airplanes), etc.

[0384] The communication system 100 may also include base station 114a and base station 114b. Figure 52AIn the example, each base station 114a and 114b is depicted as a single element. In practice, base stations 114a and 114b may include any number of interconnected base stations or network elements. Base station 114a may be any type of device configured to connect to the wireless interface of at least one of WTRUs 102a, 102b, and 102c to facilitate access to one or more communication networks (such as core networks 106 / 107 / 109, the Internet 110, network services 113, or other networks 112). Similarly, base station 114b may be any type of device configured to connect to the wired or wireless interface of at least one of Remote Radio Headers (RRHs) 118a and 118b, Transmit and Receive Points (TRPs) 119a and 119b, or Roadside Units (RSUs) 120a and 120b to facilitate access to one or more communication networks (such as core networks 106 / 107 / 109, the Internet 110, other networks 112, or network services 113). RRH 118a, 118b can be any type of device configured to connect to the wireless interface of at least one of WTRU 102 (e.g., WTRU 102c) to facilitate access to one or more communication networks (such as core network 106 / 107 / 109, Internet 110, network service 113, or other network 112).

[0385] TRPs 119a and 119b can be any type of device configured to connect to at least one of the radio interfaces of WTRU 102d to facilitate access to one or more communication networks (such as core network 106 / 107 / 109, Internet 110, network service 113, or other network 112). RSUs 120a and 120b can be any type of device configured to connect to at least one of the radio interfaces of WTRU 102e or 102f to facilitate access to one or more communication networks (such as core network 106 / 107 / 109, Internet 110, other network 112, or network service 113). As an example, base stations 114a and 114b can be base transceiver stations (BTS), Node Bs, evolved Node Bs, home Node Bs, home evolved Node Bs, next-generation Node Bs (gNode Bs), satellites, site controllers, access points (APs), wireless routers, etc.

[0386] Base station 114a may be part of RAN 103 / 104 / 105, which may also include other base stations or network elements (not shown), such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes, etc. Similarly, base station 114b may be part of RAN 103b / 104b / 105b, which may also include other base stations or network elements (not shown), such as BSCs, RNCs, relay nodes, etc. Base station 114a may be configured to transmit or receive radio signals within a specific geographical area, which may be referred to as a cell (not shown), as disclosed herein. Similarly, base station 114b may be configured to transmit or receive wired or radio signals within a specific geographical area, which may be referred to as a cell (not shown) of methods, systems, and apparatus for sidelink adaptation protocols for remote UE connectivity. Cells may be further subdivided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Therefore, in one example, base station 114a may include three transceivers, for example, one transceiver per sector of the cell. In one example, base station 114a may employ multiple-input multiple-output (MIMO) technology and thus may utilize multiple transceivers for each sector of the cell.

[0387] Base station 114a can communicate with one or more of WTRUs 102a, 102b, 102c, or 102g via air interface 115 / 116 / 117, which can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, centimeter wave, millimeter wave, etc.). Any suitable radio access technology (RAT) can be used to establish air interface 115 / 116 / 117.

[0388] Base station 114b can communicate with one or more of RRH 118a, 118b, TRP 119a, 119b, or RSU 120a, 120b via wired or air interfaces 115b / 116b / 117b. These wired or air interfaces can be any suitable wired communication link (e.g., cable, fiber optic, etc.) or wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, centimeter wave, millimeter wave, etc.). Any suitable radio access technology (RAT) can be used to establish air interfaces 115b / 116b / 117b.

[0389] RRH 118a, 118b, TRP 119a, 119b, or RSU 120a, 120b can communicate with one or more of WTRU 102c, 102d, 102e, 102f via air interface 115c / 116c / 117c, which can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, centimeter wave, millimeter wave, etc.). Any suitable radio access technology (RAT) can be used to establish air interface 115c / 116c / 117c.

[0390] WTRUs 102a, 102b, 102c, 102d, 102e, or 102f can communicate with each other via air interface 115d / 116d / 117d, such as sidelink communication. This air interface can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, centimeter wave, millimeter wave, etc.). Any suitable radio access technology (RAT) can be used to establish air interface 115d / 116d / 117d.

[0391] The communication system 100 can be a multiple access system and can employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, base station 114a in RAN103 / 104 / 105 and WTRU 102a, 102b, 102c or RRH 118a, 118b, TRP 119a, 119b and RSU 120a, 120b and WTRU 102c, 102d, 102e, 102f in RAN 103b / 104b / 105b can implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which can use Wideband CDMA (WCDMA) to establish air interfaces 115 / 116 / 117 or 115c / 116c / 117c respectively. WCDMA may include communication protocols such as High-Speed ​​Packet Access (HSPA) or evolved HSPA (HSPA+). HSPA may include High-Speed ​​Downlink Packet Access (HSDPA) or High-Speed ​​Uplink Packet Access (HSUPA).

[0392] In one example, base station 114a and WTRUs 102a, 102b, 102c or RAN103b / 104b / 105b, specifically RRH 118a, 118b, TRP 119a, 119b or RSU 120a, 120b and WTRUs 102c, 102d, can implement radio technologies such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which can establish air interfaces 115 / 116 / 117 or 115c / 116c / 117c using Long Term Evolution (LTE) or LTE-A, respectively. In the future, air interfaces 115 / 116 / 117 or 115c / 116c / 117c can implement 3GPP NR technology. LTE and LTE-A technologies may include LTE D2D and V2X technologies and interfaces (such as sidelink communication). Similarly, 3GPP NR technology includes NR V2X technology and interfaces (such as sidelink communication).

[0393] Base stations 114a and WTRUs 102a, 102b, 102c and 102g in RAN 103 / 104 / 105, or RRHs 118a, 118b, TRPs 119a, 119b, or RSUs 120a, 120b and WTRUs 102c, 102d, 102e, 102f in RAN 103b / 104b / 105b, can implement radio technologies such as IEEE 802.16 (e.g., Global Microwave Access Interoperability (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rate GSM Evolution (EDGE), GSMEDGE (GERAN), etc.

[0394] Figure 52ABase station 114c can be, for example, a wireless router, home Node B, home eNode B, or access point, and can utilize any suitable RAT to facilitate wireless connectivity in local areas such as commercial areas, homes, vehicles, trains, aircraft, satellites, manufacturing plants, campuses, etc., to implement the methods, systems, and devices for sidelink adaptation protocols for remote UE connectivity disclosed herein. In one example, base station 114c and WTRU 102 (e.g., WTRU 102e) can implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). Similarly, base station 114c and WTRU 102d can implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another example, base station 114c and WTRU 102 (e.g., WTRU 102e) can utilize cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, NR, etc.) to establish picocells or femtocells. Figure 52A As shown, base station 114c may have a direct connection to Internet 110. Therefore, base station 114c may not need to access Internet 110 via core network 106 / 107 / 109.

[0395] RAN 103 / 104 / 105 or RAN 103b / 104b / 105b can communicate with core network 106 / 107 / 109, which can be any type of network configured to provide voice, data, messaging, authorization and authentication, application and / or Voice over Internet Protocol (VoIP) services to one or more of WTRUs 102a, 102b, 102c, and 102d. For example, core network 106 / 107 / 109 can provide call control, billing services, location-based services, prepaid calling, internet connectivity, packet data network connectivity, Ethernet connectivity, video distribution, etc., or perform advanced security functions such as user authentication.

[0396] Although not in Figure 52A As shown, but it should be understood, RAN 103 / 104 / 105 or RAN 103b / 104b / 105b and / or core network 106 / 107 / 109 can communicate directly or indirectly with other RANs using the same RAT as or a different RAT than RAN 103 / 104 / 105 or RAN 103b / 104b / 105b. For example, in addition to being connected to RAN 103 / 104 / 105 or RAN 103b / 104b / 105b which can utilize E-UTRA radio technology, core network 106 / 107 / 109 can also communicate with another RAN (not shown) using GSM or NR radio technology.

[0397] Core networks 106 / 107 / 109 can also serve as gateways for WTRUs 102a, 102b, 102c, 102d, and 102e to access PSTN 108, the Internet 110, or other networks 112. PSTN 108 may include a circuit-switched telephone network providing Common Old-Style Telephone Service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and Internet Protocol (IP) from the TCP / IP Internet Protocol suite. Network 112 may include wired or wireless communication networks owned or operated by other service providers. For example, network 112 may include any type of packet data network (e.g., IEEE 802.3 Ethernet) or another core network connected to one or more RANs, which may use the same RAT as or a different RAT than RAN 103 / 104 / 105 or RAN 103b / 104b / 105b.

[0398] Some or all of the WTRUs 102a, 102b, 102c, 102d, 102e, and 102f in the communication system 100 may include multi-mode capabilities. For example, WTRUs 102a, 102b, 102c, 102d, 102e, and 102f may include multiple transceivers for communicating with different wireless networks via different radio links to implement the methods, systems, and apparatus for sidelink adaptation protocols for remote UE connectivity as disclosed herein. For example, Figure 52A The WTRU 102g shown can be configured to communicate with a base station 114a that can employ cellular-based radio technology and with a base station 114c that can employ IEEE 802 radio technology.

[0399] Despite Figure 52A Although not shown, it should be understood that user equipment can be wired to a gateway. The gateway may be a residential gateway (RG). The RG can provide connectivity to the core network 106 / 107 / 109. It should be understood that many of the topics included herein are equivalent to those applied to UEs acting as WTRUs and UEs using wired connections to the network. For example, topics applicable to radio interfaces 115, 116, 117, and 115c / 116c / 117c are equivalent to those applied to wired connections.

[0400] Figure 52BThis is a system diagram of an exemplary RAN 103 and core network 106 for implementing the sidelink adaptation protocol for remote UE connectivity as disclosed herein. As described above, RAN 103 can communicate with WTRUs 102a, 102b, and 102c via air interface 115 using UTRA radio technology. RAN 103 can also communicate with core network 106. Figure 52B As shown, RAN 103 may include nodes B 140a, 140b, and 140c, each of which may include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 115. Nodes B 140a, 140b, and 140c may each be associated with a specific cell (not shown) within RAN 103. RAN 103 may also include RNCs 142a and 142b. It should be understood that RAN 103 may include any number of node Bs and radio network controllers (RNCs).

[0401] like Figure 52B As shown, nodes B 140a and 140b can communicate with RNC 142a. Additionally, node B 140c can communicate with RNC 142b. Nodes B 140a, 140b, and 140c can communicate with their respective RNCs 142a and 142b via the Iub interface. RNCs 142a and 142b can communicate with each other via the Iur interface. Each of RNCs 142a and 142b can be configured to control the corresponding nodes B 140a, 140b, and 140c to which it is connected. Furthermore, each of RNCs 142a and 142b can be configured to perform or support other functionalities such as outer-loop power control, load control, admission control, packet scheduling, handover control, macro diversity, security functions, and data encryption.

[0402] Figure 52B The core network 106 shown may include a media gateway (MGW) 144, a mobile switching center (MSC) 146, a serving GPRS support node (SGSN) 148, or a gateway GPRS support node (GGSN) 150. Although each of the foregoing elements is depicted as part of the core network 106, it should be understood that any of these elements may be owned or operated by an entity other than the core network operator.

[0403] RNC 142a in RAN 103 can be connected to MSC 146 in core network 106 via IuCS interface. MSC 146 can be connected to MGW 144. MSC 146 and MGW 144 provide WTRU 102a, 102b, and 102c with access to circuit-switched networks (such as PSTN 108) to facilitate communication between WTRU 102a, 102b, and 102c and legacy landline communication equipment.

[0404] RNC 142a in RAN 103 can also be connected to SGSN 148 in core network 106 via IuPS interface. SGSN 148 can be connected to GGSN 150. SGSN 148 and GGSN 150 provide WTRU 102a, 102b, and 102c with access to packet-switched networks (such as Internet 110) to facilitate communication between WTRU 102a, 102b, and 102c and IP-enabled devices.

[0405] The core network 106 can also be connected to other networks 112, which may include other wired or wireless networks owned or operated by other service providers.

[0406] Figure 52C This is a system diagram of an exemplary RAN 104 and core network 107 that implements the sidelink adaptation protocol for remote UE connectivity as disclosed herein. As described above, RAN 104 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using E-UTRA radio technology. RAN 104 can also communicate with core network 107.

[0407] RAN 104 may include evolved Node Bs 160a, 160b, and 160c, but it should be understood that RAN 104 may include any number of evolved Node Bs. Evolved Node Bs 160a, 160b, and 160c may each include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. For example, evolved Node Bs 160a, 160b, and 160c may implement MIMO technology. Therefore, eNode-B 160a may, for example, use multiple antennas to transmit radio signals to and receive radio signals from WTRU 102a.

[0408] Each of the evolved nodes B 160a, 160b, and 160c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, and user scheduling in the uplink or downlink, etc. Figure 52CAs shown, evolution nodes B 160a, 160b and 160c can communicate with each other via the X2 interface.

[0409] Figure 52C The core network 107 shown may include a mobility management gateway (MME) 162, a serving gateway 164, and a packet data network (PDN) gateway 166. Although each of the foregoing elements is depicted as part of the core network 107, it should be understood that any of these elements may be owned or operated by an entity other than the core network operator.

[0410] The MME 162 can connect to each of the eNode-Bs 160a, 160b, and 160c in RAN 104 via the S1 interface and can be used as a control node. For example, the MME 162 can be responsible for authenticating users of WTRUs 102a, 102b, and 102c, bearer activation / deactivation, selecting a specific serving gateway during the initial attachment of WTRUs 102a, 102b, and 102c, etc. The MME 162 can also provide control plane functions for handover between RAN 104 and other RANs (not shown) employing other radio technologies such as GSM or WCDMA.

[0411] Serving Gateway 164 can connect to each of the eNode-Bs 160a, 160b, and 160c in RAN 104 via the S1 interface. Serving Gateway 164 typically routes and forwards user data packets to and from WTRUs 102a, 102b, and 102c. Serving Gateway 164 may also perform other functions, such as anchoring the user plane during inter-evolved Node-B handover, triggering paging when downlink data is available for WTRUs 102a, 102b, and 102c, and managing and storing the context of WTRUs 102a, 102b, and 102c.

[0412] Service gateway 164 can also be connected to PDN gateway 166, which provides WTRUs 102a, 102b, and 102c with access to packet-switched networks (such as Internet 110) to facilitate communication between WTRUs 102a, 102b, and 102c and IP-enabled devices.

[0413] Core network 107 can facilitate communication with other networks. For example, core network 107 can provide WTRUs 102a, 102b, and 102c with access to circuit-switched networks (such as PSTN 108) to facilitate communication between WTRUs 102a, 102b, and 102c and traditional landline communication equipment. For example, core network 107 may include an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between core network 107 and PSTN 108, or be able to communicate with such an IP gateway. Additionally, core network 107 can provide WTRUs 102a, 102b, and 102c with access to other networks 112, which may include other wired or wireless networks owned or operated by other service providers.

[0414] Figure 52D This is a system diagram of an exemplary RAN 105 and core network 109 for implementing the sidelink adaptation protocol for remote UE connectivity as disclosed herein. RAN 105 may communicate with WTRUs 102a and 102b via air interface 117 using NR radio technology. RAN 105 may also communicate with core network 109. Non-3GPP Interoperability Function (N3IWF) 199 may communicate with WTRU 102c via air interface 198 using non-3GPP radio technology. N3IWF 199 may also communicate with core network 109.

[0415] RAN 105 may include Next Generation Node Bs 180a and 180b. It should be understood that RAN 105 may include any number of Next Generation Node Bs. Next Generation Node Bs 180a and 180b may each include one or more transceivers for communicating with WTRUs 102a and 102b via air interface 117. When using integrated access and backhaul connectivity, the same air interface can be used between the WTRU and the Next Generation Node Bs, which may be via the core network 109 of one or more gNBs. Next Generation Node Bs 180a and 180b may implement MIMO, MU-MIMO, or digital beamforming technologies. Therefore, Next Generation Node B 180a may, for example, use multiple antennas to transmit radio signals to and receive radio signals from WTRU 102a. It should be understood that RAN 105 may employ other types of base stations, such as Evolved Node Bs. It should also be understood that RAN 105 may employ more than one type of base station. For example, the RAN may employ both Evolved Node Bs and Next Generation Node Bs.

[0416] N3IWF 199 may include a non-3GPP access point 180c. It should be understood that N3IWF 199 may include any number of non-3GPP access points. The non-3GPP access point 180c may include one or more transceivers for communicating with WTRU 102c via air interface 198. The non-3GPP access point 180c may communicate with WTRU 102c via air interface 198 using the 802.11 protocol.

[0417] Each of the next-generation nodes B 180a and 180b can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, and user scheduling in the uplink or downlink, etc. Figure 52D As shown, next-generation nodes B 180a and 180b can communicate with each other, for example, via the Xn interface.

[0418] Figure 52D The core network 109 shown may be a 5G core network (5GC). The core network 109 can provide various communication services to customers interconnected via a radio access network. The core network 109 includes multiple entities that perform the functionality of the core network. As used herein, the terms "core network entity" or "network function" refer to any entity that performs one or more functions of the core network. It should be understood that such core network entities may be logical entities implemented in the form of computer-executable instructions (software), which are stored in a device or computer system configured for wireless or network communication (such as...). Figure 52G The system 90 shown is stored in its memory and executed on its processor.

[0419] exist Figure 52D In the example, the 5G core network 109 may include Access and Mobility Management Functions (AMF) 172, Session Management Functions (SMF) 174, User Plane Functions (UPF) 176a and 176b, User Data Management Functions (UDM) 197, Authentication Server Functions (AUSF) 190, Network Exposure Functions (NEF) 196, Policy Control Functions (PCF) 184, Non-3GPP Interoperability Functions (N3IWF) 199, and User Data Repository (UDR) 178. While each of the foregoing elements is depicted as part of the 5G core network 109, it should be understood that any of these elements may be owned or operated by an entity other than the core network operator. It should also be understood that the 5G core network may not include all of these elements, may include additional elements, and may include multiple instances of each of these elements. Figure 52D The network functions are shown to be directly connected to each other; however, it should be understood that they may communicate via routing agents such as diameter routing agents or message buses.

[0420] exist Figure 52DIn the example, connections between network functions are achieved through a set of interfaces or reference points. It should be understood that a network function can be modeled, described, or implemented as a set of services invoked or called by other network functions or services. Invocation of network function services can be achieved through direct connections between network functions, message exchange on a message bus, invoking software functions, etc.

[0421] The AMF 172 can connect to RAN 105 via the N2 interface and can be used as a control node. For example, the AMF 172 can be responsible for registration management, connection management, reachability management, access authentication, and access authorization. The AMF can forward user plane tunnel configuration information to RAN 105 via the N2 interface. The AMF 172 can receive user plane tunnel configuration information from the SMF via the N11 interface. The AMF 172 can typically route and forward NAS packets to / from WTRUs 102a, 102b, and 102c via the N1 interface. The N1 interface... Figure 52D Not shown in the image.

[0422] SMF 174 can connect to AMF 172 via interface N11. Similarly, SMF 174 can connect to PCF184 via interface N7 and to UPF 176a and 176b via interface N4. SMF 174 can be used as a control node. For example, SMF 174 can be responsible for session management, IP address allocation for WTRU 102a, 102b, and 102c, management and configuration of traffic redirection rules in UPF 176a and UPF 176b, and generation of downlink data notifications to AMF 172.

[0423] UPF 176a and UPF 176b provide WTRU 102a, 102b, and 102c with access to a packet data network (PDN) (such as the Internet 110) to facilitate communication between WTRU 102a, 102b, and 102c and other devices. UPF 176a and UPF 176b also provide WTRU 102a, 102b, and 102c with access to other types of packet data networks. For example, other networks 112 can be any type of network, such as Ethernet or switched data packets. UPF 176a and UPF 176b can receive traffic redirection rules from SMF 174 via the N4 interface. UPF 176a and UPF 176b can provide access to packet data networks by connecting to a packet data network via the N6 interface or by connecting to each other and other UPFs via the N9 interface. In addition to providing access to packet data networks, UPF 176 is also responsible for packet routing and forwarding, policy rule enforcement, quality of service for user plane traffic, and downlink packet buffering.

[0424] The AMF 172 can also connect to the N3IWF 199, for example, via the N2 interface. The N3IWF facilitates the connection between the WTRU 102c and the 5G core network 170, for example, via a radio interface technology not defined by 3GPP. The AMF can interact with the N3IWF 199 in the same or similar manner as it interacts with the RAN 105.

[0425] The PCF 184 can be connected to the SMF 174 via the N7 interface, to the AMF172 via the N15 interface, and to the Application Function (AF) 188 via the N5 interface. The N15 and N5 interfaces are... Figure 52D Not shown in the diagram. PCF 184 can provide policy rules to control plane nodes such as AMF 172 and SMF 174, thereby allowing the control plane nodes to enforce these rules. PCF 184 can send policies for WTRUs 102a, 102b, and 102c to AMF 172, enabling AMF to deliver policies to WTRUs 102a, 102b, and 102c via the N1 interface. The policies can then be enforced or applied at WTRUs 102a, 102b, and 102c.

[0426] The UDR 178 can act as a repository for authentication credentials and subscription information. The UDR can connect to network functions, allowing them to add, read, and modify data in the repository. For example, the UDR 178 can connect to the PCF 184 via the N36 interface. Similarly, the UDR 178 can connect to the NEF 196 via the N37 interface, and the UDR 178 can connect to the UDM 197 via the N35 interface.

[0427] The UDM 197 serves as an interface between the UDR 178 and other network functions. The UDM 197 can authorize network functions to access the UDR 178. For example, the UDM 197 can connect to the AMF 172 via the N8 interface, and to the SMF 174 via the N10 interface. Similarly, the UDM 197 can connect to the AUSF 190 via the N13 interface. The UDR 178 and UDM 197 can be tightly integrated.

[0428] The AUSF 190 performs authentication-related operations and connects to the UDM 178 via the N13 interface and to the AMF 172 via the N12 interface.

[0429] NEF 196 exposes the capabilities and services of the 5G core network 109 to Application Function (AF) 188. Exposure may occur on the N33 API interface. NEF can connect to AF 188 via the N33 interface, and NEF can connect to other network functions to demonstrate the capabilities and services of the 5G core network 109.

[0430] Application function 188 can interact with network functions in the 5G core network 109. The interaction between application function 188 and network functions can occur via a direct interface or via NEF 196. Application function 188 can be considered part of the 5G core network 109, or it can be deployed outside the 5G core network 109 by an enterprise with a business relationship with the mobile network operator.

[0431] Network slicing is a mechanism that mobile network operators can use to support one or more "virtual" core networks behind the operator's air interface. This involves "slicing" the core network into one or more virtual networks to support different RANs or different service types operating across a single RAN. Network slicing enables operators to create customized networks to provide optimized solutions for different market scenarios that require diverse requirements in terms of functionality, performance, and isolation.

[0432] 3GPP has designed the 5G core network to support network slicing. Network slicing is a valuable tool for network operators to support a wide range of 5G use cases with highly diverse and sometimes extreme requirements, such as massive IoT, critical communications, V2X, and enhanced mobile broadband. Without network slicing, the flexibility and scalability of the network architecture may be insufficient to effectively support a broader range of use case needs when each use case has its own specific set of requirements for performance, scalability, and availability. Furthermore, new network services should be introduced more efficiently.

[0433] See you again Figure 52D In a network slicing scenario, WTRU 102a, 102b, or 102c can connect to AMF172 via the N1 interface. AMF can be a logical part of one or more slices. AMF coordinates the connection or communication between WTRU 102a, 102b, or 102c and one or more of UPF176a and 176b, SMF174, and other network functions. Each of UPF176a and 176b, SMF174, and other network functions can be part of the same slice or different slices. When they are part of different slices, they can be isolated from each other in terms of their access to different computing resources, security credentials, etc.

[0434] Core network 109 may facilitate communication with other networks. For example, core network 109 may include an IP gateway (such as an IP Multimedia Subsystem (IMS) server) that serves as an interface between 5G core network 109 and PSTN 108, or may communicate with such an IP gateway. For example, core network 109 may include a Short Message Service (SMS) service center that facilitates communication via Short Message Service, or may communicate with such an SMS service center. For example, 5G core network 109 may facilitate the exchange of non-IP data packets between WTRUs 102a, 102b, and 102c and server or application function 188. Additionally, core network 170 may provide WTRUs 102a, 102b, and 102c with access to other networks 112, which may include other wired or wireless networks owned or operated by other service providers.

[0435] This article describes and Figure 52A , Figure 52C , Figure 52D or Figure 52E The core network entities shown are identified by the names given to those entities in certain existing 3GPP specifications. However, it should be understood that in the future, those entities and functions may be identified by other names, and some entities or functions may be combined in future specifications released by 3GPP, including future 3GPP NR specifications. Therefore, in Figure 52A , Figure 52B , Figure 52C , Figure 52D or Figure 52E The specific network entities and functions described and illustrated herein are provided by way of example only, and it should be understood that the subject matter disclosed and claimed herein may be embodied or implemented in any similar communication system (whether currently defined or to be defined in the future).

[0436] Figure 52E An exemplary communication system 111 is illustrated, in which systems, methods, and apparatuses described herein for implementing sidelink adaptation protocols for remote UE connectivity are used. Communication system 111 may include radio transmit / receive units (WTRUs) A, B, C, D, E, F, a base station gNB 121, a V2X server 124, and roadside units (RSUs) 123a and 123b. In practice, the concepts presented herein can be applied to any number of WTRUs, base station gNBs, V2X networks, or other network elements. One or more or all WTRUs A, B, C, D, E, and F may be located outside the coverage area 131 of the access network. WTRUs A, B, and C form a V2X group, where WTRU A is the group leader and WTRUs B and C are group members.

[0437] If WTRUs A, B, C, D, E, and F are within the coverage area 131 of the access network, they can communicate with each other via gNB 121 through Uu interface 129. Figure 52E In the example, WTRUs B and F are shown within access network coverage 131. WTRUs A, B, C, D, E, and F can communicate directly with each other via side link interfaces (e.g., PC5 or NR PC5) (such as interfaces 125a, 125b, or 128), regardless of whether they are within or outside access network coverage 131. For example, in Figure 52E In the example, WRTU D outside the access network coverage 131 communicates with WTRU F inside the coverage 131.

[0438] WTRUs A, B, C, D, E, and F can communicate with RSUs 123a or 123b via Vehicle-to-Network (V2N) 133 or sidelink interface 125b. WTRUs A, B, C, D, E, and F can communicate with V2X server 124 via Vehicle-to-Infrastructure (V2I) interface 127. WTRUs A, B, C, D, E, and F can communicate with another UE via Vehicle-to-Pedestrian (V2P) interface 128.

[0439] Figure 52F This is a block diagram of an exemplary apparatus or device WTRU 102 configurable for wireless communication and operation, which implements a sidelink adaptation protocol for remote UE connectivity according to the methods and devices described herein. Figure 52A , Figure 52B , Figure 52C , Figure 52D or Figure 52E or Figures 5 to 50 WTRU 102 (e.g., remote UE 201, relay UE 202, UE to NW relay 203, base station 204, AMF 206, SMF 207, relay UE 208, remote UE 209, UPF 210, or relay UE 211). For example... Figure 52FAs shown, the exemplary WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad / indicator 128, non-removable memory 130, removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136, and other peripheral devices 138. It should be understood that WTRU 102 may include any sub-combination of the foregoing elements. Furthermore, base stations 114a and 114b, or base stations 114a and 114b, may represent nodes (such as, but not limited to, transceiver stations (BTS), Node-B, site controllers, access points (APs), home node-B, evolved home node-B (eNodeB), evolved home node-B (HeNB), evolved home node-B gateway, next-generation node-B (gNode-B), and proxy nodes, etc.) that may be included. Figure 52F Some or all of the elements depicted may be exemplary specific implementations of the disclosed systems and methods for performing the sidelink adaptation protocol for remote UE connectivity described herein.

[0440] Processor 118 can be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. Processor 118 can perform signal encoding, data processing, power control, input / output processing, or any other function that enables WTRU 102 to operate in a wireless environment. Processor 118 can be coupled to transceiver 120, which can be coupled to transmitting / receiving element 122. Although Figure 52F While the processor 118 and transceiver 120 are depicted as separate components, it should be understood that the processor 118 and transceiver 120 may be integrated together in an electronic package or chip.

[0441] The UE's transmit / receive element 122 can be configured to transmit data to a base station (e.g., via air interface 115 / 116 / 117). Figure 52AThe base station 114a) transmits signals or receives signals from the base station, or transmits signals to or receives signals from another UE via air interface 115d / 116d / 117d. For example, the transmit / receive element 122 may be an antenna configured to transmit or receive RF signals. The transmit / receive element 122 may be a transmitter / detector configured to transmit or receive, for example, IR signals, UV signals, or visible light signals. The transmit / receive element 122 may be configured to transmit and receive both RF signals and optical signals. It should be understood that the transmit / receive element 122 may be configured to transmit or receive any combination of wireless signals or wired signals.

[0442] Furthermore, although the transmitting / receiving element 122 is in Figure 52F While depicted as a single element, WTRU 102 may include any number of transmitting / receiving elements 122. More specifically, WTRU 102 may employ MIMO technology. Therefore, WTRU 102 may include two or more transmitting / receiving elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals via air interfaces 115 / 116 / 117.

[0443] Transceiver 120 can be configured to modulate signals transmitted by transmitting / receiving element 122 and demodulate signals received by transmitting / receiving element 122. As noted above, WTRU 102 may have multi-mode capability. Therefore, transceiver 120 may include multiple transceivers to enable WTRU 102 to communicate via multiple RATs (e.g., NR and IEEE 802.11 or NR and E-UTRA), or via multiple beams to the same RAT at different RRHs, TRPs, RSUs, or nodes.

[0444] The processor 118 of WTRU 102 can be coupled to a speaker / microphone 124, a keypad 126, or a display / touchpad / indicator 128 (e.g., a liquid crystal display (LCD) unit or an organic light-emitting diode (OLED) display unit) and can receive user input data from them. The processor 118 can also output user data to the speaker / microphone 124, keypad 126, or display / touchpad / indicator 128. Furthermore, the processor 118 can access information in any type of suitable memory (such as non-removable memory 130 or removable memory 132) and store data in any type of suitable memory. Non-removable memory 130 may include random access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. Removable memory 132 may include a Subscriber Identity Module (SIM) card, a Memory Stick, a Secure Digital (SD) memory card, etc. Processor 118 may access memory information that is never physically located on WTRU 102 (e.g., on a server hosted in the cloud, on an edge computing platform, or on a home computer (not shown)) and store the data in that memory. Processor 118 may be configured to control the lighting pattern, image, or color on display or indicator 128 in response to whether the setup of the sidelink adaptation protocol for remote UE connectivity in some examples described herein is successful or unsuccessful, or otherwise indicate the status of the sidelink adaptation protocol for remote UE connectivity and associated components. The control lighting pattern, image, or color on display or indicator 128 may reflect the figures shown or discussed herein (e.g., Figures 5 to 50 The status of any method flow or component (etc.). This document discloses messages and procedures for the side walkway adaptation protocol for remote UE connectivity. These messages and procedures are extensible to provide an interface / API for users to request resources via input sources (e.g., speaker / microphone 124, keypad 126, or display / touchpad / indicator 128), and to request, configure, or query side walkway adaptation protocol related information for remote UE connectivity, as well as other information that can be displayed on display 128.

[0445] The processor 118 may receive power from the power supply 134 and may be configured to distribute or control power to other components in the WTRU 102. The power supply 134 may be any suitable device for powering the WTRU 102. For example, the power supply 134 may include one or more dry cell batteries, solar cells, fuel cells, etc.

[0446] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) about the current location of the WTRU 102. In addition to or instead of the information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via air interface 115 / 116 / 117 or determine its location based on the timing of signals received from two or more nearby base stations. It should be understood that the WTRU 102 may acquire location information using any suitable location determination method.

[0447] The processor 118 may also be coupled to other peripheral devices 138, which may include one or more software or hardware modules that provide additional features, functions, or wired or wireless connectivity. For example, peripheral device 138 may include various sensors such as accelerometers, biometric (e.g., fingerprint) sensors, electronic compasses, satellite transceivers, digital cameras (for photos or videos), Universal Serial Bus (USB) ports or other interconnect interfaces, vibration devices, television transceivers, hands-free headsets, etc. Modules, FM radio units, digital music players, media players, video game player modules, internet browsers, and so on.

[0448] WTRU 102 may be included in other devices or equipment, such as sensors, consumer electronics, wearable devices (such as smartwatches or smart clothing), medical or e-health devices, robots, industrial equipment, drones, or vehicles (such as cars, trucks, trains, or airplanes). WTRU 102 may be connected to other components, modules, or systems of such devices or equipment via one or more interconnect interfaces, such as interconnect interfaces that may include one of the peripheral devices 138.

[0449] Figure 52G This is a block diagram of an exemplary computing system 90, which can illustrate... Figure 52A , Figure 52C , Figure 52D and Figure 52E The communication network shown includes one or more devices and a sidelink adaptation protocol for remote UE connectivity, such as those described and claimed herein. Figures 5 to 50The systems and methods shown may include certain nodes or functional entities in RAN 103 / 104 / 105, core network 106 / 107 / 109, PSTN 108, Internet 110, other networks 112, or network services 113. The computing system 90 may include a computer or server and may be controlled primarily by computer-readable instructions, which may be in the form of software, regardless of where or by what means such software is stored or accessed. Such computer-readable instructions may be executed within a processor 91 to enable the computing system 90 to function. The processor 91 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 91 may perform signal encoding, data processing, power control, input / output processing, or any other function that enables the computing system 90 to function in a communication network. Coprocessor 81 is an optional processor, distinct from main processor 91, that can perform additional functions or assist processor 91. Processor 91 or coprocessor 81 can receive, generate, and process data related to the methods and apparatus disclosed herein for the sidelink adaptation protocol for remote UE connectivity, such as receiving messages.

[0450] In operation, processor 91 fetches instructions, decodes and executes them, and transfers information to and from other resources via the main data transfer path (system bus 80) of the computing system. This system bus connects components within the computing system 90 and defines the medium for data exchange. System bus 80 typically includes data lines for transmitting data, address lines for transmitting addresses, and control lines for transmitting interrupts and operating the system bus. An example of such a system bus 80 is the PCI (Peripheral Component Interconnect) bus.

[0451] The memory coupled to the system bus 80 includes random access memory (RAM) 82 and read-only memory (ROM) 93. This type of memory includes circuitry that allows information to be stored and retrieved. ROM 93 typically contains stored data that cannot be easily modified. Data stored in RAM 82 can be read or changed by the processor 91 or other hardware devices. Access to RAM 82 or ROM 93 can be controlled by the memory controller 92. The memory controller 92 provides address translation functionality, translating virtual addresses into physical addresses as instructions are executed. The memory controller 92 also provides memory protection functionality that isolates processes within the system and separates system processes from user processes. Therefore, a program running in first mode can only access memory mapped through its own process virtual address space; it cannot access memory in another process's virtual address space unless inter-process memory sharing is configured.

[0452] In addition, the computing system 90 may include a peripheral device controller 83 responsible for transmitting instructions from the processor 91 to peripheral devices such as a printer 94, a keyboard 84, a mouse 95, and a disk drive 85.

[0453] A display 86, controlled by a display controller 96, is used to display visual output generated by a computing system 90. This visual output may include text, graphics, animated graphics, and video. The visual output can be provided in the form of a graphical user interface (GUI). The display 86 can be implemented using a CRT-based video display, an LCD-based flat panel display, a gas plasma-based flat panel display, or a touchpad. The display controller 96 includes the electronic components required to generate the video signals sent to the display 86.

[0454] Furthermore, the computing system 90 may include communication circuitry, such as, for example, a wireless or wired network adapter 97, which can be used to connect the computing system 90 to an external communication network or device, such as... Figure 52A , Figure 52B , Figure 52C , Figure 52D or Figure 52E The RAN103 / 104 / 105, core network 106 / 107 / 109, PSTN 108, Internet 110, WTRU 102, or other networks 112 are configured to enable the computing system 90 to communicate with other nodes or functional entities in these networks. Communication circuitry, either separately or in conjunction with the processor 91, can be used to perform the transmit and receive steps of certain means, nodes, or functional entities described herein.

[0455] It should be understood that any or all of the apparatuses, systems, methods, and processes described herein may be embodied in the form of computer-executable instructions (e.g., program code) stored on a computer-readable storage medium, which, when executed by a processor (such as processor 118 or 91), cause the processor to perform or implement the systems, methods, and processes described herein. Specifically, any of the steps, operations, or functions described herein may be implemented in the form of such computer-executable instructions that execute on a processor of an apparatus or computing system configured for wireless or wired network communication. Computer-readable storage media include volatile and non-volatile, removable and non-removable media implemented using any non-transitory (e.g., tangible or physical) method or technology for storing information, but such computer-readable storage media do not include signals. Computer-readable storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical disc storage devices, magnetic tape cassettes, magnetic tape, disk storage devices or other magnetic storage devices, or any other tangible or physical medium that can be used to store desired information and is accessible by a computing system.

[0456] In describing preferred methods, systems, or apparatuses of the subject matter of this disclosure (sidelink adaptation protocol for remote UE connectivity) as illustrated in the accompanying drawings, specific terminology has been used for clarity. However, the claimed subject matter is not intended to be limited to the specific terminology chosen in this way.

[0457] The various techniques described herein can be implemented in combination of hardware, firmware, or software, or, where appropriate, in combination thereof. Such hardware, firmware, and software can reside in devices located at various nodes of a communication network. These devices can operate individually or in combination with each other to implement the methods described herein. As used herein, the terms “device,” “network device,” “node,” “equipment,” “network node,” etc., are used interchangeably. Furthermore, unless otherwise provided herein, the word “or” is generally used in a manner that includes the end value.

[0458] This written specification uses examples of the subject matter disclosed in this invention (including the best mode) and also enables any person skilled in the art to practice the disclosed subject matter, including making and using any device or system and performing any incorporated methods. The disclosed subject matter (e.g., options 1 and 2) may include other examples that will occur to those skilled in the art (e.g., skipped steps, combined steps, or added steps between exemplary methods disclosed herein).

[0459] The methods, systems, and apparatuses described herein can provide for: controlling (e.g., using) an intra-device packet routing data link layer (DLL) protocol (RaLTP) to route packets to a data link upper layer protocol based on RaLTP DLL routing entries; controlling an inter-device packet routing DLL protocol (RaLAP) to route packets between a first device and a second device based on RaLAP DLL routing entries; controlling the quality of service (QoS) of a packet delivery function based on RaLAP or RaLTP DLL QoS entries; performing inter-device packet routing actions on packets based on a first RaLAP address or RaLAP path identifier or a first RaLTP identifier; performing intra-device packet routing actions on packets based on a first RaLAP address or a first RaLTP identifier; or performing QoS actions for packet delivery based on a first RaLAP address and a first RaLTP identifier or an upper layer protocol identifier. The methods, systems, and apparatuses described herein can provide information for receiving indication parameters from a third device. All combinations (including deletions or additions of steps) in this and the following paragraphs are contemplated in a manner consistent with other parts of the detailed embodiments.

[0460] The methods, systems, and apparatuses described herein can provide for: performing packet routing to a data link upper-layer protocol using the Relay Link Tunneling Protocol (RaLTP) based on RaLTP data link layer (DLL) routing entries, wherein RaLTP is located in the DLL and used to perform intra-device packet routing; and performing intra-device packet routing actions on packets based on a first Relay Link Adaptation Protocol (RaLAP) address or a first RaLTP identifier. The methods, systems, and apparatuses described herein can also provide for: performing packet routing between a first device and a second device using the Relay Link Adaptation Protocol (RaLAP) based on RaLAP data link layer (DLL) routing entries, wherein RaLAP is located in the DLL and used to perform inter-device packet routing; and performing inter-device packet routing actions on packets based on a first RaLAP address or RaLAP path identifier and a first Relay Link Tunneling Protocol (RaLTP) identifier. RaLAP - located in the DLL and used to perform inter-device packet routing. RaLTP - located in the DLL and used to perform intra-device packet routing. The methods, systems, and apparatuses described herein can provide for: using packet delivery functions based on RaLAP or Relay Link Tunneling Protocol (RaLTP) DLL QoS entries; and performing QoS actions for packet delivery based on a first RaLAP address or a first RaLTP identifier and an upper-layer protocol identifier. All combinations (including deletions or additions of steps) in this and following paragraphs are contemplated in a manner consistent with other parts of the detailed embodiments.

[0461] The methods, systems, and apparatuses described herein can be used to: route packets to a data link upper-layer protocol using the Relay Link Tunneling Protocol (RaLTP) based on RaLTP data link layer (DLL) routing entries, wherein RaLTP resides in the DLL and is used to perform intra-device packet routing; and perform intra-device packet routing actions on packets based on a first Relay Link Adaptation Protocol (RaLAP) address or a first RaLTP identifier. The methods, systems, and apparatuses described herein can also be used to: route packets between a first device and a second device using the Inter-device Packet Routing DLL Protocol (RaLAP) based on RaLAP DLL routing entries; and perform inter-device packet routing actions on packets based on a first RaLAP address or RaLAP path identifier and a first Relay Link Tunneling Protocol (RaLTP) identifier. The methods, systems, and apparatuses described herein can also be used to: use Quality of Service (QoS) for packet delivery functions based on RaLAP and Relay Link Tunneling Protocol (RaLTP) DLL QoS entries; and perform QoS actions for packet delivery based on a first RaLAP address or a first RaLTP identifier and an upper-layer protocol identifier. The methods, systems, and apparatuses described herein may provide for receiving first information, second information, or a combination of both. The first information indicates one or more first parameters for controlling intra-device packet routing, controlling inter-device packet routing, or controlling QoS of packet delivery from upper-layer protocols above RaLAP and RaLTP to the next hop, wherein the one or more first parameters include an upper-layer protocol identifier (ID), a RaLAP route ID including a RaLAP address and a RaLAP path ID, a translated RaLAP ID including a translated RaLAP address and a translated RaLAP path ID, a RaLTP ID, a translated RaLTP ID, a next-hop RaLAP address, an egress link ID, or an egress RLC channel ID. The second information indicates one or more second parameters for controlling intra-device packet routing, inter-device packet routing, or controlling the QoS of packet delivery from ingress link RaLAP and RaLTP to the next hop, wherein the one or more second parameters include: a RaLAP ID including a RaLAP address and a RaLAP path identifier, a translated RaLAP ID including a translated RaLAP address and a translated RaLAP path identifier, a RaLTP ID, a translated RaLTP ID, a next-hop RaLAP address, an ingress link ID, an ingress RLC channel ID, an egress link ID, or an egress RLC channel ID. The third information indicates one or more third parameters for controlling intra-device packet routing or inter-device packet routing from ingress link RaLAP and RaLTP to upper-layer protocols or local links, wherein the one or more third parameters include a RaLAP address and a RaLAP path ID, a RaLTP ID, or an upper-layer protocol ID.All combinations (including the deletion or addition of steps) in this paragraph and the following paragraphs can be envisioned in a manner consistent with the other parts of the specific implementation.

[0462] One or more first parameters, one or more second parameters, or one or more third parameters are pre-configured or specified by the standard. The first RaLTP identifier is the identifier of the bearer, the identifier of the tunnel associated with the bearer, the identifier of the tunnel associated with an upper-layer protocol above the intra-device routing DLL protocol, or the identifier of an upper-layer protocol above the intra-device routing DLL protocol. The upper-layer protocol may be a Packet Data Convergence Protocol (PDCP). The tunnel may be between a first device and a second device. The tunnel may be a multi-hop tunnel. Performing intra-device packet routing actions may include: selecting from multiple entries used to control inter-device packet routing, control intra-device packet routing, or control the QoS of packet delivery from upper-layer protocols above RaLAP and RaLTP to the next hop, where the upper-layer protocol identifier of the entry corresponds to the upper-layer protocol identifier of this packet; selecting the RaLTP identifier as the first RaLTP entity from the selected entries; or including the first RaLTP identifier in the Tunnel Endpoint ID (TEID) field of this packet header. Performing inter-device packet routing actions may include: selecting from a plurality of entries used to control inter-device packet routing, control intra-device packet routing, or control the QoS of packet delivery from upper-layer protocols above RaLAP and RaLTP to the next hop, wherein the upper-layer protocol identifier of the entry corresponds to the upper-layer protocol identifier of this packet; selecting a RaLAP address as a first RaLAP address from the routing identifiers in the selected entries; selecting a path identifier from the routing identifiers in the selected entries if a path identifier is available; or including the first RaLAP address and the path identifier (if available) in the destination field of this packet header. All combinations (including deletions or additions of steps) in this and the following paragraphs are contemplated in a manner consistent with other parts of the detailed implementation.

[0463] Performing Quality of Service (QoS) actions includes: selecting from multiple entries used to control inter-device packet routing, control intra-device packet routing, or control QoS for packet delivery from upper-layer protocols above RaLAP and RaLTP to the next hop, wherein the upper-layer protocol identifier of the entry corresponds to the upper-layer protocol identifier of the packet; selecting the egress link ID and egress RLC channel ID from the selected entries; or submitting the packet to the RLC entity corresponding to the selected egress link ID and selected egress RLC channel ID. Performing inter-device packet routing actions includes: determining the first RaLTP identifier as the identifier in the Tunnel Endpoint ID (TEID) field of the packet header; determining the first RaLAP address and RaLAP path identifier as the address and path identifier in the destination field of the packet header; selecting from multiple entries used to control inter-device packet routing, control intra-device packet routing, or control QoS for packet delivery from RaLAP and RaLTP links to the next hop, wherein the RaLAP address of the entry corresponds to the first RaLAP address, and the egress link of the entry corresponds to the next-hop RaLAP address. It is available, and the RaLTP identifier of the entry corresponds to the first RaLTP identifier; select the egress link corresponding to the next-hop RaLAP address in the entry selected above; if RaLAP address translation is applicable, select the translated RaLAP address as the first RaLAP address in the selected entry, and include the first RaLAP address in the destination field of this packet header; or if RALTP identifier translation is applicable, select the translated RaLTP identifier as the first RaLTP identifier in the selected entry, and include the first RaLTP identifier in the TEID field of this packet header. All combinations (including deletions or additions of steps) in this paragraph and the following paragraphs are contemplated in a manner consistent with other parts of the specific implementation.

[0464] Performing Quality of Service (QoS) actions includes: selecting from multiple entries used to control inter-device packet routing, control intra-device packet routing, or control QoS for packet delivery from upper-layer protocols above RaLAP and RaLTP to the next hop, wherein the upper-layer protocol identifier of the entry corresponds to the upper-layer protocol identifier of the packet; selecting the egress link ID and egress RLC channel ID from the selected entries; or submitting the packet to the RLC entity corresponding to the selected egress link ID and selected egress RLC channel ID. Performing inter-device packet routing actions includes: determining the first RaLTP identifier as the identifier in the Tunnel Endpoint ID (TEID) field of the packet header; determining the first RaLAP address and RaLAP path identifier as the address and path identifier in the destination field of the packet header; selecting from multiple entries used to control inter-device packet routing, control intra-device packet routing, or control QoS for packet delivery from RaLAP and RaLTP links to the next hop, wherein the RaLAP address of the entry corresponds to the first RaLAP address, and the egress link of the entry corresponds to the next-hop RaLAP address. It is available, and the RaLTP identifier of this entry corresponds to the first RaLTP identifier; select the egress link corresponding to the next-hop RaLAP address in the entry selected above; if RaLAP address translation is applicable, select the translated RaLAP address as the first RaLAP address in the selected entry, and include the first RaLAP address in the destination field of this packet header; or if RALTP identifier translation is applicable, select the translated RaLTP identifier as the first RaLTP identifier in the selected entry, and include the first RaLTP identifier in the TEID field of this packet header. Performing a Quality of Service (QoS) action includes: selecting from multiple entries for controlling inter-device packet routing, controlling intra-device packet routing, or controlling QoS for packet delivery from ingress links RaLAP and RaLTP to the next hop, where the entry's ingress link ID corresponds to the packet's ingress link, the entry's ingress RLC channel ID corresponds to the packet's ingress RLC channel, and the entry's egress link ID corresponds to the selected egress link; selecting an egress RLC channel corresponding to the egress RLC channel ID of the entry selected above; or submitting the packet to an RLC entity corresponding to the selected egress link ID and the selected RLC channel ID. All combinations (including deletions or additions of steps) in this and the following paragraphs are contemplated in a manner consistent with other parts of the specific implementation.

[0465] Performing intra-device packet routing actions includes: identifying the first RaLTP identifier as the identifier in the Tunnel Endpoint ID (TEID) field of the packet header; identifying the first RaLAP address and RaLAP path identifier as the address and path identifier in the destination field of the packet header; selecting from multiple entries used to control inter-device packet routing, control intra-device packet routing, or control QoS of packet delivery from the ingress link RaLAP and RaLTP to an upper-layer or local link, wherein the RaLAP address of the entry corresponds to the first RaLAP address, and the RaLTP identifier of the entry corresponds to the first RaLTP identifier; selecting an upper-layer protocol identifier from the selected entry; removing the RaLAP and RaLTP headers from the packet; or submitting a packet without a RaLAP header and without a RaLTP header to the upper-layer protocol corresponding to the selected upper-layer protocol identifier. The first and second devices exchange: an end-to-end keep-alive message, an end-to-end radio link failure (RLF) indication message, or an end-to-end flow control message. The first and second devices are connected via one or more PC5 interface links. The first device and the other device exchange: a hop-by-hop keep-alive message, wherein the other device is on the communication path between the first device and the second device; a hop-by-hop RLF indication, wherein the other device is on the communication path between the first device and the second device; or a hop-by-hop flow control message, wherein the other device is on the communication path between the first device and the second device. When the next-hop RaLAP address corresponding to the first entry is available, the first entry egress link is selected. If the first RaLAP address is not already included, it is included in the destination field of the second packet header, and if the first path identifier is available but not yet included, it is included in the path field of the second packet header. The first entry egress link corresponds to the selected egress link. The third packet is submitted to the RLC entity corresponding to the egress link ID and the egress RLC channel ID. The first entry egress link corresponds to the selected egress link. The first RaLAP address is determined as the address in the destination field of the second packet header, and the first path identifier is determined as the path identifier in the path field of the second packet header. The first path identifier is determined as the path identifier in the path field of the first packet header. A first entry is selected from a plurality of entries used for controlling inter-device packet routing, controlling intra-device packet routing, or controlling QoS from ingress link RaLAP and RaLTP to an upper layer or local link, wherein the first entry RaLAP address corresponds to a first RaLAP address and the first entry RaLTP identifier corresponds to a first path identifier. All combinations (including deletions or additions of steps) in this and the preceding paragraphs are contemplated in a manner consistent with other parts of the specific implementation.

Claims

1. A wireless transmit / receive unit (WTRU), the WTRU comprising: processor; and A memory coupled to the processor, the memory storing executable instructions that, when executed by the processor, cause the processor to perform operations including: Receive configuration information for a remote WTRU from a network node, wherein the configuration information includes an identifier of the remote WTRU and an identifier of the radio link control (RLC) channel associated with the remote WTRU; Receive data packets from the network node; Determine the information associated with the data packet, wherein the information associated with the data packet includes a WTRU identifier (ID) and a bearer ID; Based on the information associated with the data packets and the configuration information received from the network node, an outgoing communication link is determined; Based on the information associated with the data packets, the RLC channel of the outgoing communication link is determined; and The data packets are submitted to the designated RLC channel of the outgoing communication link for transmission to the remote WTRU.

2. The WTRU of claim 1, wherein the WTRU ID and the bearer ID are in the header of the data packet.

3. The WTRU according to claim 1, wherein the WTRU is a relay WTRU.

4. The WTRU of claim 1, wherein the configuration information for the remote WTRU is received via Radio Resource Control (RRC) signaling.

5. The WTRU according to claim 1, wherein the identifier of the RLC channel is the identifier of the side link (SL) RLC channel.

6. The WTRU of claim 1, wherein the WTRU ID includes a remote WTRU ID.

7. The WTRU of claim 1, wherein the information associated with the data packet includes configuration information provided to multiple nodes via radio resource control signaling.

8. A method for a sidelink (SL) adaptation protocol for a remote wireless transmit / receive unit (WTRU) connection, the method comprising: Receive configuration information for the remote WTRU from the network node, wherein the configuration information includes the identifier of the remote WTRU and the identifier of the radio link control (RLC) channel associated with the remote WTRU; Receive data packets from the network node; Determine the information associated with the data packet, wherein the information associated with the data packet includes a WTRU identifier (ID) and a bearer ID; Based on the information associated with the data packets and the configuration information received from the network node, an outgoing communication link is determined; Based on the information associated with the data packets, the RLC channel of the outgoing communication link is determined; and The data packets are submitted to the designated RLC channel of the outgoing communication link for transmission to the remote WTRU.

9. The method of claim 8, wherein the WTRU ID and the bearer ID are in the header of the data packet.

10. The method of claim 8, wherein the WTRU is a relay WTRU.

11. The method of claim 8, wherein the configuration information for the remote WTRU is received via Radio Resource Control (RRC) signaling.

12. The method of claim 8, wherein the identifier of the RLC channel is the identifier of the SL RLC channel.

13. The method of claim 8, wherein the WTRU ID includes a remote WTRU ID.

14. The method of claim 8, wherein the information associated with the data packet includes configuration information provided to multiple nodes via radio resource control signaling.

15. A computer-readable storage medium storing computer-executable instructions, which, when executed by a computing device, cause the computing device to perform operations including: Receive configuration information for the Remote Wireless Transmit / Receive Unit (WTRU) from the network node, wherein, The configuration information includes the identifier of the remote WTRU and the identifier of the radio link control (RLC) channel associated with the remote WTRU. Receive data packets from the network node; Determine the information associated with the data packet, wherein the information associated with the data packet includes a WTRU identifier (ID) and a bearer ID; Based on the information associated with the data packets and the configuration information received from the network node, an outgoing communication link is determined; Based on the information associated with the data packets, the RLC channel of the outgoing communication link is determined; as well as The data packets are submitted to the designated RLC channel of the outgoing communication link for transmission to the remote WTRU.

16. The computer-readable storage medium of claim 15, wherein the WTRU ID and the bearer ID are in the header of the data packet.

17. The computer-readable storage medium of claim 15, wherein the WTRU is a relay WTRU.

18. The computer-readable storage medium of claim 15, wherein the configuration information for the remote WTRU is received via Radio Resource Control (RRC) signaling.

19. The computer-readable storage medium of claim 15, wherein the identifier of the RLC channel is the identifier of a side-link (SL) RLC channel.

20. The computer-readable storage medium of claim 15, wherein the WTRU ID includes a remote WTRU ID.

Images