Sidelink Adaptation Protocol for Remote Ue Connectivity

This application is a continuation of U.S. Non-Provisional patent application Ser. No. 17/999,264, filed Nov. 18, 2022, which is the National Stage Application of International Patent Application No. PCT/US2021/033179, filed May 19, 2021, which claims the benefit of U.S. Provisional Patent Application No. 63/026,904, filed on May 19, 2020, entitled “Sidelink Adaptation Protocol For Remote UE Connectivity,” and U.S. Provisional Patent Application No. 63/094,485, filed on Oct. 21, 2020, entitled “Sidelink Adaptation Protocol For Remote UE Connectivity,” the contents of both are hereby incorporated by reference herein.

1 FIG. 2 FIG. In 3GPP RAN, a Release 15 study item “Further Enhancements LTE Device to Device, UE to Network Relays for IoT and Wearable” was approved (RP-161303: “Further Enhancements LTE Device to Device, UE to Network Relays for IoT and Wearables”). The objective of this SI is to study enhancements to ProSe UE-to-network relaying and to the LTE D2D framework for commercial and public safety applications such as wearable and IoT devices. The resulting protocol stack architecture is captured inand(from 3GPP TR 36.746 V15.1.1 Study on further enhancements to LTE Device to Device (D2D), User Equipment (UE) to network relays for Internet of Things (IoT) and wearables; (Release 15)). The detail of the adaptation protocol was not studied.

In 3GPP RAN, a release 16 study item on “Integrated Access and Backhaul for NR” was approved. The objective of the study is to identify and evaluate potential solutions for the following requirements and aspects associated with the efficient operation of integrated access and wireless backhaul for NR. This work led to the specification of a Backhaul Adaptation Protocol (BAP) (3GPP TS 38340 V1.0.0) in support of data forwarding between a DeNB and a remote UE. The protocol stack that uses this BAP is captured in 38.300 (R2-2002407, CR 0153 to 38.300 on Integrated Access and Backhaul for NR). It should be noted that the BAP does not support multiplexing of different users or bearers with the same QoS level once the corresponding data units are multiplexed onto the backhaul RLC channels, and therefore doesn't provide mechanism at the peer receiver BAP to route the received data units to the correct upper layer protocol instances. This function is instead provided by the GTP-U protocol (3GPP TS 29281 V16.0.0) in the user plane or STCP protocol (Stream Transmission Control Protocol, IETF RFC 4960) in the control plane.

3 FIG. 4 FIG. In 3GPP, a release 17 study was conducted by the SA working group SA2 to identify and evaluate architecture enhancements of 5G System design needed to support proximity based services based on SA1 requirements defined in TS 22.278 V17.1.0, TS 22.261 V17.1.0 and TS 22.115 V17.0.0 and determine which of the solutions can proceed to normative specifications. The resulting protocol stack architecture is captured inand(from 3GPP TR 23.752 V0.3.0 (Release 17)). The detail of the adaptation protocol was not studied.

This background information is provided to reveal information believed by the applicant to be of possible relevance. No admission is necessarily intended, nor should be construed, that any of the preceding information constitutes prior art.

Disclosed herein are methods, systems, and devices that may assist in remote UE connectivity.

In an example, there may be use of an enhanced version of Backhaul Adaption Protocol (BAP) on the sidelink for multi-hop connection oriented sidelink communication or multi-hop connectionless sidelink communication, with additional enhancements to allow multiplexing and demultiplexing of bearers over Relay Link (RaL) RLC channels.

In another example, there may be a new intra-device packet routing data link layer protocol denoted Relay Link Tunneling Protocol (RaLTP) that runs over an enhanced BAP on the sidelink or Uu link and provide bearer multiplexing and demultiplexing over the RaL RLC channels, in support of multi-hop connection oriented sidelink communication or multi-hop connectionless sidelink communication.

In another example, there may be a data link layer based end-to-end keep alive procedure, there may be a data link layer based end-to-end flow control procedure, or there may be a data link layer end-to-end RLF indication.

This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not constrained to limitations that solve any or all disadvantages noted in any part of this disclosure.

The following terms are used herein.

Relay Link (RaL): a radio link of a relay node over sidelink (PC5) interface or Uu interface

RaL RLC channel: An RLC channel between two nodes, which is used to transport relay link packets.

Ingress RaL RLC channel: An RaL RLC channel on which a packet is received by a node.

Egress RaL RLC channel: An RaL RLC channel on which a packet is transmitted by a node.

Ingress link: A radio link on which a packet is received by a node.

Egress link: A radio link on which a packet is transmitted by a node.

Local Link (LoL): an access radio link over sidelink (PC5) interface or Uu interface

Local UE: A UE is a local UE to a node if this UE is served over a local link by this node. The node for which a UE is a local UE may be for example a base station, a Relay UE, a UE-to-Network Relay, a peer UE.

Remote UE: A UE is a remote UE with respect to a node if this UE is served over multi-hop link by this node, wherein the multi-hop link may comprise of only sidelinks, only Uu links or a combination of sidelink and Uu link.

Routing ID: Routing identity that comprises a routing address and a path identity.

Translated Address: this is an address an intermediary node on a communication path uses to override the current destination filed (address) in a packet before forwarding the packet to the next hop. The intermediary node maintains a mapping between the original destination address and the translated address for address translation purposes.

Translated Tunnel Identity: this is a tunnel identity an intermediary node on a communication path uses to override the current TEID filed (tunnel identity) in a packet before forwarding the packet to the next hop. The intermediary node maintains a mapping between the original tunnel identity and the translated tunnel identity for tunnel identity translation purposes.

Translated Path Identity: this is a path identity an intermediary node on a communication path uses to override the current PATH filed (path identity) in a packet before forwarding the packet to the next hop. The intermediary node maintains a mapping between the original path identity and the translated path identity for path identity translation purposes.

Translated Routing Identity: this is a routing identity an intermediary node on a communication path uses to override the current routing identity in a packet e.g., the destination filed (address) and the path field (path identity) in a packet before forwarding the packet to the next hop. The intermediary node maintains a mapping between the original routing identity and the translated routing identity for routing identity translation purposes.

1 FIG. 2 FIG. 3 FIG. 4 FIG. For 3GPP RAN there is a need to identify mechanisms to support QoS for relaying functionality wherein a remote UE, is served over a multi-hop link that includes Uu link and PC5 interface sidelink(s). Also, there is a need to investigate the impact on user plane protocol stack and control plane procedure in support of such a remote UE. As discussed above, the BAP does not support multiplexing of different users or bearers with the same QoS once the corresponding data units are multiplexed onto the backhaul RLC channels, and therefore doesn't provide mechanism at the peer receiver BAP to route the received data units to the correct upper layer protocol instances. This function is instead provided by the GTP-U protocol (3GPP TS 29281 V16.0.0) in the user plane or STCP protocol (Stream Transmission Control Protocol, IETF RFC 4960) in the control plane. However, UDP/IP is the only path protocol defined to transfer GTP message in version 1 of GTP while UDP/IP or TCP/IP can be used as path protocols for GTP messages in version 0 of the GTP protocol. Because of overhead and complexity, it is likely that UDP/IP or TCP/IP will not be used as path protocol over the sidelink, as highlighted by the protocol stack examples provided in,,, and. Assuming these path protocols are not used, then it might not be efficient to use the GTP or STCP directly over a link adaptation protocol such as BAP, and even if there was a re-use of the BAP over sidelink, additional enhancements such as the ability to differentiate/demultiplex at the peer BAP receiver, different bearers with the same QoS or different users will be needed. In light of this, the 5G NR protocol stack architecture needs to be enhanced to provide data transfer function and QoS support for data exchange between peer remote UEs/RSUs or between a remote UE/RSU and a controller node, such as a base station or an RSU base station.

Disclosed herein are enhancements to the NR protocol stack, for sidelink data connectivity between a remote UE (or a UE-like RSU) and a base station (or a base station like RSU), or for sidelink connectivity between two peer-remote UEs. Disclosed herein is the use of an enhanced version of Backhaul Adaption Protocol (BAP) on the sidelink for multi-hop connection oriented sidelink communication or multi-hop connectionless sidelink communication, with additional enhancements to allow multiplexing and demultiplexing of bearers over Relay Link (RaL) RLC channels. The resulting protocol is an inter-device packet routing data link layer (DLL) protocol denoted Relay Link Adaptation Protocol (RaLAP). Disclosed herein is a new intra-device packet routing data link layer protocol denoted Relay Link Tunneling Protocol (RaLTP) that runs over an enhanced BAP on the sidelink or Uu link and provide bearer multiplexing and demultiplexing over the RaL RLC channels, in support of multi-hop connection oriented sidelink communication or multi-hop connectionless sidelink communication. The RaLTP also provide supports for end-to-end keep-alive mechanism of a multi-hop data link. Disclosed herein are configuration methods for the RaLAP protocol or the RaLTP protocol including data link layer address translation capability at the intermediary hops between the source and destination nodes in support of connectionless packet routing. Disclosed herein is a data link layer based end-to-end keep alive procedure. Disclosed herein is a data link layer based end-to-end flow control procedure. Disclosed herein is a data link layer end-to-end RLF indication.

With reference to the aforementioned enhancement, the subject matter (SM) disclosed herein include the following.

First subject matter for a first device may include instructions stored in the first device which, when executed cause the first device to: control (e.g., use) intra-device packet routing data link layer (DLL) protocol (e.g., RaLTP) for packet routing to or from data link upper layer protocols based on a RaLTP DLL routing entries; control inter-device packet routing DLL protocol (e.g., RaLAP) for packet routing between the first device and a second device based on a RaLAP DLL routing entries; control Quality of Service (QoS) of packet transfer function based on RaLAP and RaLTP DLL QoS entries; perform inter-device packet routing actions on a packet based on a first RaLAP address or RaLAP path identity or a first RaLTP identity; perform intra-device packet routing actions on a packet based on a first RaLAP address or first RaLTP identity; or perform Quality of Service actions for a packet transfer based on a first RaLAP address and first RaLTP identity, or an upper layer protocol identity. Packet routing may be to or from data link upper layer protocols.

The first device may receive from a third device, information indicating parameters which may include the following: a) plurality of entries for control of inter-device packet routing, control of intra-device packet routing, or control of QoS for transfer of a packet from upper layer protocol above RaLAP and RaLTP to next hop, in which each entry may include upper layer protocol IDentity (ID), RaLAP routing ID that includes RaLAP address and RaLAP path ID, translated RaLAP ID that includes a translated RaLAP address and a translated RaLAP path ID, RaLTP ID, translated RaLTP ID, next hop RaLAP address, egress link ID, or egress RLC Channel ID; b) a plurality of entries for control of inter-device packet routing, control of intra-device packet routing, or control of QoS for transfer of a packet from ingress link RaLAP and RaLTP to next hop, in which each entry may include RaLAP ID that includes RaLAP address and RaLAP path identity, translated RaLAP ID that includes a translated RaLAP address and a translated RaLAP path identity, RaLTP ID, translated RaLTP ID, next hop RaLAP address, ingress link ID, ingress RLC Channel ID, egress link ID, or egress RLC Channel ID; or c) plurality of entries for control of inter-device packet routing, or control of intra-device packet routing of a packet from ingress link RaLAP and RaLTP to upper layer protocol or local link, in which each entry may include RaLAP ID that includes RaLAP address and RaLAP path ID, RaLTP ID, or Upper layer protocol ID.

The parameters associated with the first device of the first subject matter for control of routing or QoS may further be preconfigured into the device or specified by standards, and may include the following: a) a plurality of entries for control of inter-device packet routing, control of intra-device packet routing, or control of QoS for transfer of a packet from upper layer protocol above RaLAP and RaLTP to next hop, in which each entry may include upper layer protocol ID, RaLAP routing ID consisting of RaLAP address and RaLAP path identity, translated RaLAP routing ID that includes a translated RaLAP address and a translated RaLAP path ID, RaLTP ID, translated RaLTP ID, next hop RaLAP address, egress link ID, or egress RLC Channel ID; b) a plurality of entries for control of inter-device packet routing, or control of intra-device packet routing, or control of QoS for transfer of a packet from ingress link RaLAP and RaLTP to next hop, in which each entry may include RaLAP ID that includes RaLAP address and RaLAP path identity, translated RaLAP ID that includes a translated RaLAP address and a translated RaLAP path identity, RaLTP ID, translated RaLTP ID, next hop RaLAP address, ingress link ID, ingress RLC Channel ID, egress link ID, or egress RLC Channel ID; c) in which each entry may include RaLAP ID that includes RaLAP address and RaLAP path ID, RaLTP ID, or Upper layer protocol ID.

The RaLAP or RALTP may further include a transmitting part and a receiving part. The first RaLTP identity may be an identity of a bearer, an identity of a tunnel associated with a bearer, an identity of a tunnel associated with an upper layer protocol above the intra-device routing DLL protocol, or an identity 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 the first device and a second device. The tunnel may be a multi-hop tunnel between the first device and the second device. A 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 device 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.

The first RaLTP identity may be an identity which is a translation from a second RaLTP identity at a fourth device on the communication path between the first device and the second device. The first RaLAP address may be an address which is a translation from a second RaLAP address at a fourth device on the communication path between the first device and the second device. The fourth device may be a relay UE or a UE-to-NW relay.

Intra-device packet routing actions may be performed on a packet based on a first RaLAP address or a first RaLTP identity and may further include: selecting from the plurality of entries for control of inter-device packet routing, control of intra-device packet routing, or control of QoS for transfer of a packet from upper layer protocol above RaLAP and RaLTP to next hop, in which the entry with its upper layer protocol identity corresponds to the upper layer protocol identity of this packet; selecting the RaLTP identity in the entry selected above as the first RaLTP entity; or including the first RaLTP identity into the Tunnel End Point ID (TEID) field of this packet header.

The performing of inter-device packet routing actions on a packet based on a first RaLAP address or a RaLAP path identity or a first RaLTP identity, may further include: selecting from the plurality of entries for control of inter-device packet routing, control of intra-device packet routing, or control of QoS for transfer of a packet from upper layer protocol above RaLAP and RaLTP to next hop, in which the entry with its upper layer protocol identity corresponds to the upper layer protocol identity of this packet; selecting the RaLAP address from the routing identity in the entry selected above as the first RaLAP address; selecting the path identity from the routing identity in the entry selected above if the path identity is available; or including into the destination field of this packet header the first RaLAP address and if available the path identity.

The performing of Quality of Service actions for a packet transfer based on a first RALAP address and a first RaLTP identity or an upper layer protocol identity may further include: a) selecting from the plurality of entries for control of inter-device packet routing, control of intra-device packet routing, or control of QoS for transfer of a packet from upper layer protocol above RaLAP and RaLTP to next hop, in which the entry with its upper layer protocol identity corresponds to the upper layer protocol identity of this packet; selecting the egress link ID and the egress RLC channel ID in the entry selected above; or submitting the packet to the RLC entity that corresponds to the selected egress link ID and the selected egress RLC channel ID.

The performing of inter-device packet routing actions on a packet based on a first RaLAP address or an RaLAP path identity or a first RaLTP identity may further include: determining the first RaLTP identity as the identity in the Tunnel End point ID (TEID) field of this packet header; determining the first RaLAP address and the RaLAP path identity as the address and path identity in the destination field of this packet header; selecting from the plurality of entries for control of inter-device packet routing, control of intra-device packet routing, or control of QoS for transfer of a packet from ingress link RaLAP and RaLTP to next hop, in which the entry with its RaLAP address corresponds to the first RaLAP address, and whose egress link corresponding to the Next hop RaLAP address is available and its RaLTP identity corresponds to the first RaLTP identity; selecting the egress link corresponding to the next hop RaLAP address in the entry selected above; selecting the translated RaLAP address in the selected entry as the first RaLAP address if RaLAP address translation applies, and including the first RaLAP address into the destination field of this packet header; or selecting the translated RaLTP identity in the selected entry as the first RaLTP identity if RALTP identity translation applies, and including the first RaLTP identity into the TEID field of this packet header.

The performing of Quality of Service actions for a packet transfer based on a first RaLAP address and a first RaLTP identity, or an upper layer protocol identity may further include: selecting from the plurality of entries for control of inter-device packet routing, or control of intra-device packet routing, or control of QoS for transfer of a packet from ingress link RaLAP and RaLTP to next hop, the entry with its ingress link ID corresponds to this packet ingress link, its ingress RLC channel ID correspond to this packet ingress RLC channel, its egress link ID corresponds to selected egress link; selecting the egress RLC channel corresponding to the egress RLC channel ID of the selected entry above; or submitting this packet to the RLC entity that corresponds to the selected egress link ID and the selected RLC channel ID.

The performing of intra-device packet routing actions based on a first RaLAP address and a first RaLTP identity, or an upper layer protocol identity may further include: determining the first RaLTP identity as the identity in the Tunnel End point ID (TEID) field of this packet header; determining the first RaLAP address and the RaLAP path identity as the address and path identity in the destination field of this packet header; selecting from the plurality of entries for control of inter-device packet routing, control of intra-device packet routing, control of QoS for transfer of a packet from ingress link RaLAP and RaLTP to upper layer or local link, the entry with its RaLAP address corresponds to the first RaLAP address, and its RaLTP identity corresponds to the first RaLTP identity; selecting the upper layer protocol identity in the selected entry; removing the RaLAP and RaLTP headers from the packet; or submitting the packet without the RaLAP header and without RaLTP header to the upper layer protocol that corresponds to the selected upper layer protocol identity.

The first device and the second device may exchange end-to-end keep-alive messages. The first device and the second device may be connected through one or more PC5 interface links. The first device and the second device may be connected through one or more PC5 interface link, and at least one Uu interface link. The first RaLTP identity may be coded into the packet header by reusing the reserved bit in the BAP PDU header. The first RaLTP identity may reuse the Tunneling End point ID (TEID) of the Generalized Tunneling Protocol in User Plane (GTP-U). There may be at least one RaLAP entity per RaLAP routing address space or per routing network. The may be at least one RaLTP entity per RaLTP identity space or per routing network. The first device may receive from a third device information in PC5 RRC signaling. The first device may receive from a third device information in Uu RRC signaling. The RaLAP protocol and the RaLTP protocol may constitute one protocol. The third device may be on the communication path between the first device and the second device.

The plurality of entries for control of inter-device packet routing, control of intra-device packet routing, or control of QoS for transfer of a packet from upper layer protocol above RaLAP and RaLTP to next hop may be specific to a RaLAP routing address space, specific to a RaLTP identity space, or specific to a combination of RaLAP routing address space and RaLTP identity space.

The upper layer protocol identity may be submitted to RaLTP protocol, RaLAP protocol with an indication of an RaLAP routing address space, or an indication of an RaLTP identity space, an indication of a combination RaLAP routing address space and RaLTP identity space.

The plurality of entries for control of inter-device packet routing, control of intra-device packet routing, or control of QoS for transfer of a packet from ingress link RaLAP and RaLTP to next hop may be specific to a RaLAP routing address space, specific to a RaLTP identity space, or specific to a combination of RaLAP routing address space and RaLTP identity space.

The plurality of entries for control of inter-device packet routing, control of intra-device packet routing, or control of QoS for transfer of a packet from ingress link RaLAP and RaLTP to upper layer or local link may be specific to a RaLAP routing address space, specific to a RaLTP identity space, or specific to a combination of RaLAP routing address space and RaLTP identity space.

The first device and the second device may exchange end-to-end radio link failure (RLF) indication messages. The first device and the second device may exchange end-to-end flow control message. The and a fifth device may exchange hop-by-hop keep-alive message, with the fifth device being on the communication path between the first device and the second device. The first device and a fifth device may exchange hop-by-hop RLF indication, with the fifth device being on the communication path between the first device and the second device. The first device and a fifth device may exchange hop-by-hop flow control message, with the fifth device being on the communication path between the first device and the second device.

5 FIG. To address the issues described herein, a first option of a link adaptation protocol denoted herein Architecture Option 1 is disclosed. This architecture option assumes the use of a BAP with enhancements to enable intra-node routing including multiplexing bearers into RLC channel, and demultiplexing of traffic from RLC channel into corresponding bearers and forwarding to the proper upper layer protocol. The resulting protocol is denoted Relay Link Adaptation Protocol (RaLAP). Therepresents one possible structure for RaLAP at a node. In the RaLAP sublayer, in one embodiment it is disclosed one RaLAP entity be instantiated per routing identity space per node. In another embodiment, it is disclosed that the RaLAP layer includes two RaLAP entities per routing identity space per node wherein there is a first RaLAP entity that communicates with a first sub-network or node for e.g. upstream node and, there is a second RaLAP entity that communicate with a second subnetwork or node for e.g. downstream node, wherein the network node including the RaLAP sublayer serves as a communication hop between the two subnetworks served by the two RaLAP entities. Such two entities will be denoted paired RaLAP entities or paired RaLAP entity of one another. In yet another alternative, it is disclosed one RaLAP entity be instantiated per routing address space per node. It should be noted herein that a routing identity comprises a routing address and a path identity. In another embodiment, it is disclosed that the RaLAP layer includes two RaLAP entities per routing address space per node, wherein there is a first RaLAP entity that communicates with a first sub-network or node for e.g. upstream node and, there is a second RaLAP entity that communicate with a second subnetwork or node for e.g. downstream node, wherein the network node including the RaLAP sublayer serves as a communication hop between the two subnetworks served by the two RaLAP entities.

In yet another embodiment, it is disclosed one RaLAP entity per routing ID space per sidelink L2 destination ID or per routing address space per sidelink L2 destination ID, wherein there is one RaLAP entity that communicates with one L2 Destination ID, and a second RaLAP entity that communicate with a second L2 Destination ID, wherein the network node including the RaLAP sublayer serves as a communication hop between the two sidelink L2 Destination IDs.

In another embodiment, it is disclosed one RaLAP entity per routing ID space per sidelink L2 link for e.g. unicast link ID or per routing address space per sidelink L2 link for e.g. unicast link ID, wherein there is one RaLAP entity that communicates with one L2 link ID, and a second RaLAP entity that communicate with a second L2 link ID, wherein the network node including the RaLAP sublayer serves as a communication hop between the two sidelink L2 links.

202 203 One or more routing identity space or routing address space may be configured into a node for example a relay UE node, a UE-to-Network Relay node, a remote UE, an RSU, a gNB, a gNB DU or a gNB CU. A routing identity space or a routing address space may be defined on the basis of one routing identity space or one routing address space per serving gNB, or on the basis of one routing identity space or one routing address space per a peer destination remote UE, or on the basis of one routing identity space or one routing address space per source UE, or on the basis of one routing identity space or one routing address space per layer-2 destination ID, or on the basis of one routing identity space or one routing address space per routing tree or on the basis of one per routing network.

It should be noted that when there is only one RaLAP routing identity space or routing address space per node, then the qualifying terms used herein, wherein references are made to “per routing ID space” or “per routing address space” can be omitted. For example, the term “per routing address space per L2 Destination ID” becomes “per L2 Destination ID”.

6 FIG. Each RaLAP entity has a transmitting part and a receiving part on the node that implements the RaLAP entity. Furthermore, the transmitting part has a corresponding receiving entity of an RaLAP entity at the communicating peer node across a sidelink or across a Uu link as illustrated in in.

6 FIG. Theshows an example of the functional view of the RaLAP sublayer at a node. In this example, the receiving part on the RaLAP entity delivers RaLAP PDUs to the collocated transmitting part on the RaLAP entity. Alternatively, the receiving part may deliver RaLAP SDUs to the collocated transmitting part. When passing RaLAP SDUs, the receiving part removes the RaLAP header and the transmitting part adds the RaLAP header with the same RaLAP routing ID as carried on the RaLAP PDU header prior to removal. Passing RaLAP SDUs in this manner is therefore functionally equivalent to passing RaLAP PDUs, in implementation. In the remaining of this disclosure, RaLAP SDU or RaLAP PDU is simply referred to as RaLAP data units or RaLAP packet unless indicated otherwise.

The following services may be provided by the RaLAP sublayer to upper layers: Data transfer

Service Expected from Lower Layers

An RaLAP sublayer expects the following services from lower layers per RLC entity: acknowledged data transfer service or unacknowledged data transfer service.

The RaLAP support 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 keep alive indication, or end-to-end keep alive indication.

Inter-node routing may include the following: determination of RaLAP destination and path for packets from upper layers; determination of transmitting part of the RaLAP sublayer on the same node for routing to next hop of packets from receiving part of the RaLAP sublayer on the same node; In other words, the RaLAP sublayer must determine the RaLAP entity to use on a node for routing to next hop of packets received from another RaLAP entity on the same node; routing of packets to next hop; differentiating traffic to be delivered to upper layers from traffic to be delivered to egress link; or differentiating traffic to be delivered over SL egress link versus traffic to be delivered over Uu egress link.

Intra-node routing may include the following: differentiating traffic to be delivered to upper layers from traffic to be delivered to egress link; or demultiplexing of bearers, e.g., demultiplexing of traffic mapped to the same SL RLC channel, but destinated to different upper layer protocol entities for example PDCP entities within the same node.

Support for QoS requirements may include the following: Multiplexing of bearers into RLC channels e.g., determining upper layer protocol entities for e.g. PDCP entities whose traffics are to be mapped to the same SL RLC channel, e.g., determination of upper layer protocol identity for e.g. PDCP entity identity for packet multiplexing and including such an identity into the RaLAP header. In the remaining in the remaining disclosure, this identity will be denoted bearer identity or bearer ID for short, or an identity of a tunnel associated with a bearer, or an identity of a tunnel associated with an upper layer protocol above the RaLAP protocol, or an identity of an upper layer protocol above the RaLAP protocol; or determination of egress SideLink (SL) RLC channels for packets routed to next hop.

In this section, various alternatives of end-to-end protocols that integrates the RaLAP into the data link layer e.g., Layer-2 (L2) protocols are disclosed.

201 202 203 204 In option 1a, the protocol stack in the remote UEdoesn't include the RaLAP protocol. Instead the RaLAP protocol resides in the Relay UE, the UE-to-Network relay, or in the base station.

202 203 204 201 201 201 201 201 202 208 202 203 7 FIG. 7 FIG. 9 FIG. 8 FIG. 8 FIG. 10 FIG. 8 FIG. 8 FIG. 10 FIG. This protocol architecture option may be used for connection-oriented communication or connectionless communication wherein the nodes that implements the RaLAP such as the Relay UEor the UE-to-Network relaymay be configured with RaLAP configuration information as described herein. The base station(e.g.,) may configure into various nodes in the communication path (e.g.,or) to the remote UE, the necessary configuration parameters for RaLAP operation. The configuration signaling may use RRC dedicated signaling, RRC common signaling, or a combination thereof. Similarly, a remote UE(e.g.,) or a third entity such as an RSU may configure into various nodes in the communication path (e.g.,or) to the remote UE, the necessary configuration parameters for RaLAP operation. The configuration signaling may use RRC dedicated signaling, or RRC common signaling or a combination thereof. Additionally, the adjacent nodes e.g., nodes connected with a non-multi-hop link may maintain local peer-to-peer control plane connection or communication, for example at the RRC sublayer or the PC5-S sublayer, in support for example of local configuration information exchange between adjacent nodes. For example, in the example of, an RRC or PC5-S communication or connection could exist between Remote UEand L2 Relay UE. Similarly, an RRC or PC5-S communication or connection could exist between the Remote UEand the L2 Relay UE, wherein these RRC communication or connections may be used for local peer-to-peer information exchange in support of operation of RaLAP protocol through the intermediary hops in the communication path between the two remotes UEs, as illustrated inor. Such communication arrangement could be used for connectionless RaLAP communication on the paths between L2 Relay UEand UE-to-Network relaywhich might include multiple hops.

201 201 202 203 204 201 201 201 201 201 201 209 202 202 203 11 FIG. 11 FIG. 13 FIG. 12 FIG. 12 FIG. 14 FIG. 12 FIG. 12 FIG. 14 FIG. In option 1b, the protocol stack in the remote UEalso includes the RaLAP protocol. This protocol architecture option may also be used for connection-oriented communication or connectionless communication wherein the nodes that implements the RaLAP, such as the UE, the Relay UE, or the UE-to-Network relaymay be configured with RaLAP configuration information as described herein. The base station() may configure into the various node in the communication path (or) to the remote UEincluding the remote UE, the necessary configuration parameters for RaLAP operation. The configuration signaling may use RRC dedicated signaling, RRC common signaling, or a combination thereof. Similarly, a remote UE() or a third entity such as an RSU may configure into the various nodes in the communication path (or) to the remote UE, the necessary configuration parameters for RaLAP operation. The configuration signaling may use RRC dedicated signaling, or RRC common signaling or a combination thereof. Additionally, the adjacent nodes e.g., nodes connected with a non-multi hop link may maintain local peer-to-peer control plane connection or communication, for example at the RRC sublayer or the PC5-S sublayer, in support for example of local configuration information exchange between adjacent nodes. For example, in the example of, an RRC or PC5-S communication or connection could exist between Remote UEand L2 Relay UE. Similarly, an RRC or PC5-S communication or connection could exist between the Remote UEand the L2 Relay UE, wherein these RRC communication or connections may be used for local peer-to-peer information exchange in support of operation of RaLAP protocol through the intermediary hops in the communication path between the two remotes UEs as illustrated inor. Such communication arrangement could be used for connectionless RaLAP communication on the paths between L2 Relay UEand UE-to-Network relaywhich might include multiple hops.

15 FIG. 16 FIG. 17 FIG. 18 FIG. 202 203 202 203 204 201 209 Theillustrates the downlink Layer-2 (L2) data structure including the RaLAP protocol, for the user plane at a gNB. Theillustrates the downlink L2 data structure including the RaLAP protocol, for the user plane at a Relay UE nodeor a UE-to-Network relay node. Theillustrates the uplink L2 data structure including the RaLAP protocol, for the user plane at a Relay UE nodeor a UE-to-Network relay node. Theillustrates the uplink L2 data structure including the RaLAP protocol, for the user plane at a gNB. It should be noted that while the terms downlink or uplink are used to describe the direction of the traffic, the design concepts captured by these figures may not be limited this characterization. For example, for use cases involving communication between two peer remote UEs, e.g., UEand UE, downlink direction versus uplink direction may be arbitrarily decided. The term downstream might also be used instead of downlink. Similarly, the term upstream might be used instead of uplink.

19 FIG. To address the issues described herein, a second option of a link adaptation protocol denoted herein Architecture Option 2 is disclosed. This architecture option assumes the use of two new protocols, the Relay Link Adaptation Protocol (RaLAP) protocol and the Relay Link Tunneling Protocol (RaLTP). The RaLAP protocol is an inter-device packet routing datalink layer (DLL) protocol like the BAP, which provide in addition to inter-node packet routing function, data aggregation and support for QoS requirements through proper mapping of data packets onto RLC channels, wherein the RLC channels provide QoS differentiation for data transfer over one or more hops. In one embodiment, the current BAP may be used as an RaLAP protocol. The RaLTP protocol is an intra-device packet routing data link layer protocol that runs over the RaLAP protocol on the sidelink or the Uu link. The RaLTP protocol supports bearer multiplexing over RLC channel or demultiplexing of bearers from RLC channel and provides intra-node routing of packets to upper layer protocols, such as PDCP. Therepresents one possible structure for RaLTP and RaLAP at a node. As described in Architecture Option 1, the following embodiments in relation with the number of RaLAP entities in a node also applies to the RaLAP protocol as defined in the architecture option 2. In the RaLAP sublayer, in one embodiment it is disclosed one RaLAP entity be instantiated per routing identity space per node. In another embodiment, it is disclosed that the RaLAP layer includes two RaLAP entities per routing identity space per node wherein there is one RaLAP entity that communicates with one sub-network or node for e.g. upstream node and, there is a second RaLAP entity that communicate with a second subnetwork or node for e.g. downstream node, wherein the network node including the RaLAP sublayer serves as a communication hop between the two subnetworks served by the two RaLAP entities. In yet another alternative, it is disclosed one RaLAP entity be instantiated per routing address space per node. In another embodiment, it is disclosed that the RaLAP layer includes two RaLAP entities per routing address space per node, wherein there is one RaLAP entity that communicates with one sub-network or node for e.g. upstream node and, there is a second RaLAP entity that communicate with a second subnetwork or node for e.g. downstream node, wherein the network node including the RaLAP sublayer serves as a communication hop between the two subnetworks served by the two RaLAP entities.

In yet another embodiment, it is disclosed one RaLAP entity per routing ID space per sidelink L2 destination ID or per routing address space per sidelink L2 destination ID, wherein there is one RaLAP entity that communicates with one L2 Destination ID, and a second RaLAP entity that communicate with a second L2 Destination ID, wherein the network node including the RaLAP sublayer serves as a communication hop between the two sidelink L2 Destination IDs.

In another embodiment, it is disclosed one RaLAP entity per routing ID space per sidelink L2 link for e.g. unicast link ID or per routing address space per sidelink L2 link for e.g. unicast link ID, wherein there is one RaLAP entity that communicates with one L2 link ID, and a second RaLAP entity that communicate with a second L2 link ID, wherein the network node including the RaLAP sublayer serves as a communication hop between the two sidelink L2 links.

202 203 201 204 One or more routing identity space or routing address space may be configured into a node for example a relay UE node, a UE-to-Network Relay node, a remote UE, an RSU, a gNB, a gNB DU, or a gNB CU. A routing identity space or a routing address space may be defined on the basis of one routing identity space or one routing address space per serving gNB, or on the basis of one routing identity space or one routing address space per a peer destination remote UE, or on the basis of one routing identity space or one routing address space per source UE, or on the basis of one routing identity space or one routing address space per layer-2 destination ID, or on the basis of one routing identity space or one routing address space per routing tree or on the basis of one per routing network.

It should be note that when there is only one RaLAP routing identity space or routing address space per node, then the qualifying terms used herein, wherein references are made to “per routing ID space” or “per routing address space” can be omitted. For example, the term “per routing address space per L2 Destination ID” becomes “per L2 Destination ID”.

Each RaLAP entity has a transmitting part and a receiving part on the node that implements the RaLAP entity. Furthermore, the transmitting part has a corresponding receiving entity of an RaLAP entity at the communicating peer node across a sidelink or across a Uu link.

In the RaLTP sublayer, in one embodiment it is disclosed one RaLTP entity be instantiated per tunneling protocol identity space per node. In another embodiment, it is disclosed that the RaLTP layer includes two RaLTP entities per tunneling protocol identity space per node wherein there is one RaLTP entity that communicates with one sub-network or node for e.g. upstream node and, there is a second RaLTP entity that communicates with a second subnetwork or node for e.g. downstream node, wherein the network node including the RaLTP sublayer serves as a communication hop between the two subnetworks served by the two RaLTP entities.

In yet another embodiment, it is disclosed one RaLTP entity per tunneling protocol ID space per sidelink L2 destination ID, wherein there is one RaLTP entity that communicates with one L2 Destination ID, and a second RaLTP entity that communicates with a second L2 Destination ID, wherein the network node including the RaLTP sublayer serves as a communication hop between the two sidelink L2 Destination IDs.

In another embodiment, it is disclosed one RaLTP entity per tunneling protocol ID space per sidelink L2 link for e.g. unicast link ID, wherein there is one RaLTP entity that communicates with one L2 link ID, and a second RaLTP entity that communicate with a second L2 link ID, wherein the network node including the RaLTP sublayer serves as a communication hop between the two sidelink L2 links.

202 203 201 204 One or more tunneling protocol identity space may be configured into a node for example a relay UE node, a UE-to-Network Relay node, a remote UE, an RSU, a gNB, a gNB DU or a gNB CU. A tunneling protocol identity may be defined on the basis of one tunneling protocol identity space per serving gNB, or on the basis of one tunneling protocol identity space per a peer destination remote UE, or on the basis of one tunneling protocol identity space per source UE, or on the basis of one tunneling protocol identity space per layer-2 destination ID, or on the basis of one tunneling identity space per routing tree or on the basis of one tunneling protocol identity space per routing network.

It should be noted that when there is only one RaLAP routing identity space or routing address space per node, then the qualifying terms used herein, wherein references are made to “per routing ID space” or “per routing address space”, or “per tunneling identity space” can be omitted. For example, the term “per routing address space per L2 Destination ID” becomes “per L2 Destination ID”.

20 FIG. Each RaLAP entity may have a transmitting part and a receiving part on the node that implements the RaLAP entity. Furthermore, the transmitting part has a corresponding receiving entity of an RaLAP entity at the communicating peer node across a sidelink or across a Uu link. Similarly, each RaLTP entity has a transmitting part and a receiving part on the node that implements the RaLTP entity. Furthermore, the transmitting part has a corresponding receiving entity of an RaLTP entity at the communicating peer node across a sidelink or across a Uu link as illustrated on.

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

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

Service Expected from Lower Layers

An RaLTP sublayer expects the following services from lower layers: Acknowledged data transfer service; or Unacknowledged data transfer service.

An RaLAP sublayer may expect the following services from lower layers: Acknowledged data transfer service; or Unacknowledged data transfer service.

The RaLTP support the following functions: data transfer; 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 destinated to different upper layer protocol entities for example PDCP entities within the same node or Bearer identification in support of bearer multiplexing into RLC channels; Herein, the identity for bearer identification in the RaLTP sublayer will be denoted the RaLTP identity, that may be an identity of a bearer or an identity of a tunnel associated with a bearer, or an identity of a tunnel associated with an upper layer protocol above the RaLTP, or an identity of an upper layer protocol above the RaLTP.

The RaLAP support the following functions: data transfer; 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 determination of RaLAP destination and path for packets from upper layers; determination of transmitting part of the RaLAP sublayer on the same node for routing to next hop of packets from receiving part of the RaLAP sublayer on the same node; In other words, the RaLAP sublayer must determine the RaLAP entity to use on a node for routing to next hop of packets received from another RaLAP entity on the same node; routing of packets to next hop; differentiating traffic to be delivered to upper layers from traffic to be delivered to egress link; or differentiating traffic to be delivered over SL egress link versus traffic to be delivered over Uu egress link. Support for QoS requirements may include multiplexing of bearers into RLC channels e.g., determining upper layer protocol entities for e.g. PDCP entities whose traffics are to be mapped to the same SL RLC channel, e.g., determination of upper layer protocol identity for e.g. PDCP entity identity for packet multiplexing and including such an identity into the RaLAP header. In the remaining disclosure, this identity will be denoted bearer identity or bearer ID for short. In addition support for QoS requirements may include determination of egress SideLink (SL) RLC channels for packets routed to next hop.

In this section, various alternatives of end-to-end protocols that integrates the RaLTP and RaLAP into the data link layer e.g., Layer-2 (L2) protocols are disclosed.

201 204 202 201 204 204 203 In option 2a, the protocol stack in the remote UEdoesn't include the RaLTP protocol or the RaLAP protocol. The RaLTP protocol resides in the gNBand the access Relay UE e.g., the Relay UEthat provides direct access link to the remote UEover the sidelink. In other words, the RaLTP is an end-to-end protocol between an access relay UE and a base stationor between two peer access relay UEs. The RaLAP protocol resides in the gNB, the UE-to-Network relayor in a Relay.

202 203 204 201 201 201 201 202 209 203 202 203 21 FIG. 21 FIG. 23 FIG. 22 FIG. 22 FIG. 24 FIG. 22 FIG. 22 FIG. 24 FIG. This protocol architecture option may be used for connection-oriented communication or connectionless communication wherein the nodes that implements the RaLTP and RaLAP, such as the Relay UEor the UE-to-Network relaymay be configured with RaLTP and RaLAP configuration information as described herein. The base station() may configure into the various node in the communication path (or) to the remote UE, the necessary configuration parameters for RaLTP and RaLAP operation. The configuration signaling may use RRC dedicated signaling, or RRC common signaling or a combination thereof. Similarly, a remote UE() or a third entity such as an RSU may configure into the various nodes in the communication path (or) to the remote UE, the necessary configuration parameters for RaLTP or RaLAP operation. The configuration signaling may use RRC dedicated signaling, or RRC common signaling or a combination thereof. Additionally, the adjacent nodes e.g., nodes connected with a non-multi hop link may maintain local peer-to-peer control plane connection or communication, for example at the RRC sublayer or the PC5-S sublayer, in support for example of local configuration information exchange between adjacent nodes. For example, in the example of, an RRC or PC5-S communication or connection could exist between Remote UEand L2 Relay UE. Similarly, an RRC or PC5-S communication or connection could exist between the Remote UEand the UE-to-Network relay, wherein these RRC communication or connections may be used for local peer-to-peer information exchange in support of operation of RaLTP protocol or RaLAP protocol through the intermediary hops in the communication path between the two remotes UEs as illustrated inor. Such communication arrangement could be used for connectionless RaLTP and RaLAP communication on the paths between L2 Relay UEand UE-to-Network relaywhich might include multiple hops.

201 201 204 201 202 203 204 201 204 201 201 204 201 204 25 FIG. 26 FIG. 27 FIG. 28 FIG. In option 2b, the protocol stack in the remote UEmay also include the RaLTP protocol, or the RaLAP protocol, or both. For example in one embodiment, the RaLTP protocol might be only part of the data link layer protocol in a remote UEand a base station, or only in both peer remote UEs in the case of sidelink only communication, providing end to end communication between the end peer-to-peer nodes while the RaLAP is part of the data link layer protocol in each node on the transmission part including remote UE, Relay UE node, UE-to-Network Relay node, and the base station. In another embodiment, the RaLTP protocol might be only part of the data link layer protocol in the UEand the base station, or in both peer remote UEs in the case of sidelink only communication, providing end to end communication between the end peer-to-peer nodes while the RaLAP is part of the datalink layer protocol only in the intermediary nodes on the path between the remote UEand the base station or peer remote UE. In yet another embodiment, both the RaLTP and the RaLAP protocols are part of the data link layer protocol in the UE, the base stationor the peer remote UE as well as all the other nodes in the communication path between the UEand a base stationor a peer remote UE as illustrated in,,, or.

201 202 203 204 204 201 201 201 201 201 202 201 203 202 203 25 FIG. 25 FIG. 27 FIG. 26 FIG. 26 FIG. 28 FIG. 26 FIG. 26 FIG. 28 FIG. Similar to Architecture option 1, this protocol architecture option may also be used for connection-oriented communication or connectionless communication wherein the nodes that implements the RaLAP such as the remote UE, the Relay UE, the UE-to-Network relay, or the base stationmay be configured with RaLTP and RaLAP configuration information as described herein. The base station() may configure into the various nodes in the communication path (or) to the remote UEincluding the remote UE, the necessary configuration parameters for RaLTP and RaLAP operation. The configuration signaling may use RRC dedicated signaling, or RRC common signaling or a combination thereof. Similarly, a remote UE() or a third entity such as an RSU may configure into the various nodes in the communication path (or) to the remote UE, the necessary configuration parameters for RaLTP or RaLAP operation. The configuration signaling may use RRC dedicated signaling, RRC common signaling, a combination thereof. Additionally, the adjacent nodes e.g., nodes connected with a non-multi hop link may maintain local peer-to-peer control plane connection or communication, for example at the RRC sublayer or the PC5-S sublayer, in support for example of local configuration information exchange between adjacent nodes. For example, in the example of, an RRC or PC5-S communication or connection could exist between Remote UEand L2 Relay UE. Similarly, an RRC or PC5-S communication or connection could exist between the Remote UEand the UE-to-Network relay, wherein these RRC communication or connections may be used for local peer-to-peer information exchange in support of operation of RaLTP protocol and RaLAP protocol through the intermediary hops in the communication path between the two remotes UEs as illustrated inor. Such communication arrangement could be used for connectionless RaLTP and RaLAP communication on the paths between L2 Relay UEand UE-to-Network relay, which might include multiple hops.

29 FIG. 30 FIG. 31 FIG. 32 FIG. 204 202 203 202 203 201 209 Theillustrates the downlink Layer-2 (L2) data structure including the RaLTP protocol and the RaLAP protocol, for the user plane at a gNB. Theillustrates the downlink L2 data structure including the RaLTP protocol and the RaLAP protocol, for the user plane at a Relay UE nodeor a UE-to-Network relay node. Theillustrates the uplink L2 data structure including the RaLTP protocol and the RaLAP protocol, for the user plane at a Relay UE nodeor a UE-to-Network relay node. Theillustrates the uplink L2 data structure including the RaLTP protocol and the RaLAP protocol, for the user plane at a gNB. It should be noted that while the terms “downlink” or “uplink” are used to describe the direction of the traffic, the design concepts captured by these figures may not be limited this characterization. For example, for use cases involving communication between two peer remote UEs, e.g. UEand UE, downlink direction versus uplink direction may be arbitrarily decided. The term downstream might also be used instead of downlink. Similarly, the term upstream might be used instead of uplink.

201 202 203 Example configuration of RaLAP and RaLTP in support of routing and fulfillment of QoS requirements are captured in Table 1, Table 2, Table 3 and Table 4 below. The configuration may be configured into the various nodes for example the remote UE, the Relay UE, or the UE-to-Network Relaythrough RRC dedicated signaling using dedicated resources or a common resources, or RRC common signaling for e.g. broadcast signaling or signaling through common resources, or a combination thereof.

The parameters in Table 1, Table 2, Table 3 and Table 4 might also be preconfigured into the UE. Furthermore some of the values of code points might be specified by the standards and with assigned specific meanings. For example, a specific value of an RLC channel might be reserved or specific to certain QoS Profile. Similarly, a specific value for Upper layer protocol ID might be reserved or be specific to a certain upper layer protocol instance for example to a PDCP instance for given signaling radio bearer or data radio bearer. It should be noted that while the routing configuration parameters and QoS mapping parameters are jointly presented in the same table for illustration purposes, these parameters may be configured into a node separately, for example routing configuration parameters may be configured separately from the QoS routing mapping parameters.

TABLE 1 Control of Routing and QoS for Traffic from Upper layers of RaLAP/RaLTP to next hop Routing entries Translated Translated RaLAP RaLAP RaLTP QoS entries Upper Routing ID Routing ID RaLTP identity or Egress layer (RaLAP (RaLAP Identity translated Next hop RLC Protocol address, address, or tunnel tunnel RaLAP Egress Channel Entries Identity Path ID) Path ID) identity identity address link ID ID 1 2 . . . n

TABLE 2 Control of Routing and QoS for Traffic from Ingress Link RaLAP/RaLTP to Next Hop Routing entries Translated Translated RaLAP RaLAP RaLTP QoS entries Routing ID Routing ID RaLTP identity or Ingress Egress (RaLAP (RaLAP Identity translated Next hop RLC RLC address, address, or tunnel tunnel RaLAP Ingress Channel Egress Channel Entries Path ID) Path ID) identity identity address link ID ID link ID ID 1 2 . . . n

TABLE 3 Control of Routing for Traffic from Ingress Link RaLAP/RaLTP to Upper layer Protocols or Local Link UE Routing entries RaLAP Routing ID RaLTP Upper (RaLAP Identity Layer address, or tunnel Protocol Entries Path ID) identity Identity 1 2 . . . n

TABLE 4 Control of Routing and QoS for Traffic from Ingress Link RaLAP/RaLTP to Next Hop with Paired RaLAP entity. Routing entries Translated Paired RaLAP RaLAP Translated RaLAP QoS entries Routing ID Routing ID RaLTP address or Ingress Egress (RaLAP (RaLAP identity or translated Next hop RLC RLC address address, RaLTP tunnel tunnel RaLAP Ingress Channel Egress Channel Entries Path ID) Path ID) Identity identity identity address link ID ID link ID ID 1 2 . . . n

When upper layers request establishment of an RaLAP entity, the node may: establish an RaLAP entity as per the request; or follow the procedures described with regard to draft transfer.

The establishment request from upper layer may include additional context information such as one or more of the configuration parameters as captured in the configuration tables (Table 1, Table 2, Table 3 or Table 4), and in accordance with the protocol architecture principles captured in sidelink adaptation protocol structure and entity options disclosed herein.

When upper layers request release of a RaLAP entity, the node may release RaLAP entity as per the request. When an RaLAP entity is released, the RaLTP entities mapped to that RaLAP entity may also be released.

When upper layers request establishment of an RaLTP entity, the node may: establish an RaLTP entity as per the request; or follow the procedures with regard to data transfer.

The establishment request from upper layer may include additional context information such as one or more of the configuration parameters as captured in the configuration tables Table 1, Table 2, Table 3, or Table 4, and in accordance with the protocol architecture principles captured with regard to option 1 and option 2 for sidelink adaption protocol structure and entities.

When upper layers request release of a RaLTP entity, the node may release RaLAP entity as per the request.

The transmitting part of an RaLAP entity can receive RaLAP SDUs from upper layers and RaLAP Data Units from the receiving part of the same RaLAP entity of the same node or from the receiving part of the paired RaLAP entity of the same node, and construct RaLAP Data PDUs as needed.

33 FIG. 34 FIG. A high-level view of the transmitter part operation of the RaLAP protocol is illustrated in. Similarly, a high-level view of the transmitter part operation of the RaLAP protocol is illustrated in.

In should be noted that all the descriptive text below in support of data transmission operation is described some time herein in terms of RaLAP data PDU transmission, or RaLTP data PDU transmission, the same steps in terms of routing identity selection, tunnel identity selection, inter-node routing, intra-node routing and Mapping to RLC channel are equally applicable to the transmission of RaLAP control PDU transmission or RaLTP control PDU transmission.

33 FIG. 221 222 222 223 224 225 With reference to, at step, receive RaLAP SDU from upper layers. At step, determining that RaLAP include RaLTP functions. may Based on step, at stepselect a tunneling identity address in accordance with regard to the Tunnel Identity (RaLTP identity) Selection for RaLTP Operation disclosed herein if the RaLAP also support intra-node routing function. At step, select RaLAP routing identity. Selection of an RaLAP address, an RaLAP path identity if required for this RaLAP SDU in accordance with regard to routing identity selection for RaLAP operation as disclosed herein. At step, construct an RaLAP Data PDU by adding an RaLAP header to the RaLAP SDU, where the DESTINATION field is set to the selected RaLAP address, the PATH field if required is set to the selected RaLAP path identity, and the TEID field is set to the selected tunnelling identity if the RaLAP also support intra-node routing function, in accordance with the Data PDU formats disclosed herein. It should be noted that the inclusion of path identity into the RaLAP header might not be required when performing connectionless data routing.

226 227 228 When the RaLAP entity has an RaLAP Data PDU to transmit, the transmitting part of the RaLAP entity may, at step, perform inter-node routing to determine the egress link in accordance with regard to routing (inter-node routing) as disclosed herein. At step, determine the egress Relay Link (RaL) RLC channel in accordance with Mapping to RaL RLC channel as disclosed herein. At step, submit this RaLAP Data PDU to the selected egress RaL RLC channel of the selected egress link.

The node may perform data buffering on the transmitting part of the RaLAP entity, e.g., until RLC-AM entity has received an acknowledgement. In case of RaL RLF, the transmitting part of RaLAP entity may reroute the RaLAP Data PDUs, which have not been acknowledged by lower layer before the RaL RLF, to an alternative path.

34 FIG. 231 With reference, at step, the transmitting part of an RaLTP entity can receive RaLAP SDUs from upper layers and construct RaLTP Data PDUs as needed.

232 233 At step, upon receiving an RaLTP SDU from upper layers, the transmitting part of the RaLTP entity may select an RaLTP identity in accordance with data procedures disclosed herein. At step, construct an RaLTP Data PDU by adding an RaLTP header to the RaLTP SDU, where the TEID field is set to the selected RaLTP identity, in accordance with Data PDU formats disclosed herein.

234 235 At step, when the RaLTP entity has an RaLTP Data PDU to transmit, the transmitting part of the RaLTP entity maymay perform intra-node routing to determine the RaLAP entity in accordance with regard to bearer multiplexing (Intra-node routing). At step, submit this RaLTP Data PDU to the selected RaLAP entity.

201 204 203 201 202 201 An RaLAP at a remote UE, a peer Remote UE, an RSU UE, a gNB, a gNB RSU, a UE-to-NW relayfor example when offering an access link to a remote UE, or a relay UEfor example when offering an access UE to a remote UEmay perform a routing identity selection.

Case of RaLAP that Includes RaLTP Functions

Ata node, for an RaLAP SDU received from upper layers for transmission, the RaLAP entity performs mapping to a RaLAP address and if applicable to a RaLAP path ID based on Traffic to Routing ID Mapping Configuration as illustrated in Table 1.

Each entry of the Traffic to Routing ID Mapping Configuration includes at least one or more of the following: an upper layer protocol identity or an RaLAP routing ID.

An upper layer protocol identity: The upper layer protocol identity may be for example a PDCP identity, a bearer identity or any other identity configured for upper layer protocol instances differentiation or bearer differentiation, or an identity of a tunnel associated with an upper layer protocol above the RaLAP protocol, or an identity assigned to an upper layer protocol above the RaLAP protocol. The upper layer protocol identity may also be a traffic type specifier; and

An RaLAP routing ID may include a RaLAP address and if applicable a path ID as illustrated in Table 1.

At a node, for a RaLAP SDU received from upper layers for transmission, the RaLAP entity maymay, if the Traffic to Routing ID Mapping Configuration is not configured as illustrated in Table 1, select the RaLAP address and if applicable the RaLAP path identity from a default control routing and QoS mapping table which is pre-provisioned or pre-configured into the UE, or which is specified with default parameters to be used for control of routing and data transfer according to QoS requirements;

Else: select an entry from the traffic to routing ID mapping configuration with its upper layer protocol identity corresponds to the upper layer protocol identity of this RaLAP SDU.

Next, select the RaLAP address and if applicable the path ID from the routing ID in the entry selected above.

Case of RaLAP that Relies on an RaLTP as a Separate Protocol

At an RaLAP node, for an RaLAP SDU received from RaLTP protocol for transmission, the RaLAP entity performs mapping to a RaLAP address and if applicable to a RaLAP path ID based on Tunnel identity to Routing ID Mapping Configuration, as illustrated in Table 1.

Each entry of the Tunnel identity to Routing ID Mapping Configuration may include one or more of the following: a tunnel identity or an RaLAP routing ID. a tunnel identity. The tunnel identity may be the RaLTP identity, or a PDCP identity, a bearer identity, or any other identity configured for upper layer protocol instances differentiation or bearer differentiation, or an identity of a tunnel associated with an upper layer protocol above the RaLAP protocol or RaLTP protocol, or an identity assigned to an upper layer protocol above the RaLAP protocol or RaLTP protocol. The tunnel identity may also be a traffic type specifier.

A RaLAP routing ID may include a RaLAP address and if applicable a path ID as illustrated in Table 1.

At the RaLAP node, for a RaLAP SDU received from RaLTP protocol for transmission, the RaLAP entity may, if the Tunnel identity to Routing ID Mapping Configuration is not configured as illustrated in Table 1, select the RaLAP address and if applicable the RaLAP path identity from a default control routing and QoS mapping table which is pre-provisioned or pre-configured into the UE, or which is specified with default parameters to be used for control of routing and data transfer according to QoS requirements.

Else: select an entry from the tunnel identity to routing ID mapping configuration with its tunnel identity corresponds to the value of the TEID field of this RaLAP SDU.

Next, select the RaLAP address and if applicable the path ID from the routing ID in the entry selected above.

201 204 An RaLTP at a remote UE, a peer Remote UE, an RSU UE, a gNB, a gNB RSU, may perform a routing identity selection. It should be noted as discussed herein, when RaLTP is used in combination with RaLAP, the terms tunnel identity and RaLTP identity are used interchangeably.

At an RaLTP node, for an RaLTP SDU received from upper layers for transmission, the RaLTP entity performs mapping to an RaLTP identity based on Traffic to Tunnel identity Mapping Configuration as illustrated in Table 1.

Each entry of the Traffic to Tunnel Identity Mapping Configuration includes at least one or more of the following: an upper layer protocol identity or an RaLTP identity. The upper layer protocol identity may be for example a PDCP identity, a bearer identity or any other identity configured for upper layer protocol instances differentiation or bearer differentiation, or an identity of a tunnel associated with an upper layer protocol above RaLTP, or an identity assigned to an upper layer protocol above the RaLTP protocol. The upper layer protocol identity may also be a traffic type specifier. An RaLTP identity is illustrated in Table 1.

At the RaLTP node, for a RaLTP SDU received from upper layers for transmission, the RaLTP entity may, if the Traffic to Tunnel identity Mapping Configuration is not configured as illustrated in Table 1, select the RaLTP identity from a default control routing and QoS mapping table which is pre-provisioned or pre-configured into the UE, or which is specified with default parameters to be used for control of routing and data transfer according to QoS requirements. Else: select an entry from the Traffic to Tunnel identity mapping configuration with its upper layer protocol identity corresponds to the upper layer protocol identity of this RaLTP SDU.

Next, select the RaLTP identity (tunnel identity) in the entry selected above.

The RaLAP entity may perform routing based on RaL routing configuration parameters described in Table 1, Table 2, Table 3, or Table 4.

Each entry of the RaL Routing Configuration may include one or more of the following: a RaLAP Routing ID consisting of a RaLAP address and a RaLAP path identity, or a Next Hop RaLAP Address.

For a RaLAP Data PDU to be transmitted, RaLAP entity may: if the RaLAP Data PDU corresponds to a RaLAP SDU received from the upper layer and if there are no configuration parameters configured into the UE as illustration in the configuration disclosed herein, select any egress link. For example, the UE may selected an egress link from a default control routing and QoS mapping table which is pre-provisioned or pre-configured into the UE, or which is specified with default parameters to be used for control of routing and data transfer according to QoS requirements. Else if there is an entry in the RaL Routing Configuration whose RaLAP address matches the DESTINATION field, whose path identity is the same as the PATH field, and whose egress link corresponding to the Next Hop RaLAP Address is available, then select the egress link corresponding to the Next Hop RaLAP Address of the entry.

NOTE 1: An egress link is not considered to be available if the link is in RLF. NOTE 2: It is assumed the control of routing and QoS tables described herein are configurated into the UE on per routing identity space basis, or on per routing address basis, or on per tunnel identity space basis or a combination thereof.

Else 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 Address is available: 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.

An RaLTP entity may perform intra-node routing (bearer multiplexing) based on the selected RaLTP identity as described herein with regard to tunnel identity (RaLTP identity) selection for RaLTP operation.

For an RaLTP Data PDU to be transmitted, the RaLTP entity may: select an entry from the traffic to Tunnel identity Mapping Configuration (as illustrated in Table 1) whose RaLTP identity matches the selected RaLTP identity; select the RaLAP routing identity (or the RaLAP address) of the selected entry above; and select the RaLAP entity corresponding to the selected RaLAP routing identity (or routing address).

Mapping to RaL RLC Channel for Traffic from Upper Layer to Next HopCase of RaLAP that Includes RaLTP Functions

For an RaLAP SDU received from upper layers at an RaLAP node, the RaLAP entity performs mapping to an egress RaL RLC channel based on Traffic to RaL RLC Channel Mapping Configuration as illustrated in Table 1.

Each entry of the Traffic to RaL RLC Channel Mapping Configuration includes: an upper layer protocol identity, an egress link ID, or an egress RaL RLC channel ID. An upper layer protocol identity. For example, the upper layer protocol identity may be a PDCP identity, a bearer identity or any other identity configured for upper layer protocol instances differentiation or bearer differentiation, or an identity of a tunnel associated with an upper layer protocol above the RaLAP protocol, or an identity assigned to an upper layer protocol above the RaLAP protocol. The upper layer protocol identity may also be a traffic type specifier.

An egress link ID may be indicated by the egress link that corresponds to the Next-Hop RaLAP address as captured in the Traffic to Routing ID Mapping Configuration as illustrated in Table 1.

An egress RaL RLC channel ID may be indicated by the egress RLC channel ID as captured in the Traffic to RaL RLC channel Mapping Configuration as illustrated in Table 1.

For an RaLAP SDU received from upper layers at an RaLAP node for transmission, whose egress link has been selected as specified with regard to routing (inter-node routing), the RaLAP entity may, if the Traffic to RaL RLC channel Mapping Configuration is not configured as illustrated in Table 1, select the egress RaL RLC channel from a default control routing and QoS mapping table which is pre-provisioned or pre-configured into the UE, or which is specified with default parameters to be used for control of routing and data transfer according to QoS requirements.

Else: select an entry from the traffic to RaL RLC channel mapping configuration with its upper layer protocol identity corresponds to the upper layer protocol identity of this RaLAP SDU and its egress link ID corresponding to the selected egress link; and select the egress RaL RLC channel of the entry selected above.

Case of RaLAP that Relies on an RaLTP as a Separate Protocol

For an RaLAP SDU received from upper layers at an RaLTP node, the RaLAP entity performs mapping to an egress RaL RLC channel based on tunnel identity to RaL RLC channel Mapping Configuration as illustrated in Table 1.

Each entry of the Tunnel identity to RaL RLC Channel Mapping Configuration may include: a tunnel identity, an egress link ID, or an egress RaL RLC channel ID. The tunnel identity may be for example a PDCP identity, a bearer identity, or any other identity configured for upper layer protocol instances differentiation or bearer differentiation, or an identity of a tunnel associated with an upper layer protocol above the RaLTP protocol, or an identity assigned to an upper layer protocol above the RaLTP protocol. The upper layer protocol identity may also be a traffic type specifier.

An egress link ID may be indicated by the egress link that corresponds to the Next-Hop RaLAP address as captured in the Tunnel identity to RaL RLC channel Mapping Configuration as illustrated in Table 1.

An egress RaL RLC channel ID may be indicated by the egress RLC channel ID as captured in the Tunnel identity to RaL RLC channel Mapping Configuration as illustrated in Table 1.

For an RaLAP SDU received from an RaLTP protocol for transmission, whose egress link has been selected as specified with regard to routing (inter-node routing), the RaLAP entity may, if the Traffic to RaL RLC channel Mapping Configuration is not configured as illustrated in Table 1, select the egress RaL RLC channel from a default control routing and QoS mapping table which is pre-provisioned or pre-configured into the UE, or which is specified with default parameters to be used for control of routing and data transfer according to QoS requirements.

Else: select an entry from the tunnel identity to RLC channel mapping configuration with its tunnel identity corresponds to the value of the TEID filed of this RaLAP SDU and its egress link ID corresponding to the selected egress link; and select the egress RaL RLC channel of the entry selected above.

Mapping to RaL RLC Channel for Traffic from Ingress Link to Next Hop

For a RaLAP Data PDU received from a peer RaLAP entity or from a collocated RaLAP entity, the transmitting part of the RaLAP entity performs mapping to an egress BH RLC channel based on RaL ingress to egress RLC Channel Mapping Configuration, as illustrated in Table 2 or Table 4.

Each entry of the RaL ingress to egress RLC Channel Mapping Configuration may include: an ingress link ID; an egress link ID; an ingress RaL RLC channel ID; or an egress RaL RLC channel ID.

For a RaLAP Data PDU received from an ingress RaL RLC channel of an ingress link and for which the egress link has been selected: select an entry from the RaL ingress to egress RLC Channel Mapping Configuration, whose ingress RLC channel ID matches the RaLAP Data PDU's ingress RaL RLC channel, whose ingress link ID corresponds to the RaLAP Data PDU's ingress link, and whose egress link ID corresponds to the selected egress link; and select the egress RaLAP RLC channel corresponding to egress RLC channel ID of the entry selected above.

35 FIG. A high-level view of the receiver part operation of the RaLAP protocol is illustrated in.

Case of RaLAP that Includes RaLTP Function

35 FIG. 241 242 243 244 245 246 With reference to, at step, receive RaLAP PDU. At step, then determining whether destination field of the RaLAP PDU matches the RaLAP address of the node upon receiving the RaLAP Data PDU from lower layer (e.g., ingress RaL RLC channel). may At step, determining that RaLAP includes RaLTP functions. At step, perform bearer demultiplexing (intra-node routing) according to demultiplexing (intra-node routing) disclosed herein, to select the upper layer protocol entity the RaLAP SDU should be delivered to. At step, remove the RaLAP header of the RaLAP PDU. At step, deliver the RaLAP SDU to the selected upper layer protocol entity.

242 243 245 246 Else, from step, skip steps-step, and go to stepto deliver the RaLAP Data Unit to the transmitting part of the collocated paired RaLAP entity if the RaLAP entity has a paired RaLAP entity collocated on the node. Note: As described in option 1 and option 2 for sidelink adaptation protocol structure and entities; an RaLAP entity may be paired with a another RaLAP entity on the same node, wherein the two RaLAP entities worked in tandem as a hop, 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.

Else deliver the RaLAP Data Unit to the transmitting part of this RaLAP entity.

Case of RaLAP that Relies on an RaLTP as a Separate Protocol

Upon receiving an RaLAP Data PDU from lower layer (e.g., ingress RaL RLC channel), the receiving part of the RaLAP entity may if 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 upper layers.

Else: deliver the RaLAP Data Unit to the transmitting part of the collocated paired RaLAP entity if the RaLAP entity has a paired RaLAP entity collocated on the node. Note: As described in option 1 and option 2 for sidelink adaptation protocol structure and entities; an RaLAP entity may be paired with a another RaLAP entity on the same node, wherein the two RaLAP entities worked in tandem as a hop, 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.

Else deliver the RaLAP Data Unit to the transmitting part of this RaLAP entity.

36 FIG. A high-level view of the receiver part operation of the RaLAP protocol is illustrated in.

36 FIG. 251 252 253 With reference to, at stepreceive RaLTP PDU. At step, upon receiving an RaLTP Data PDU from lower layer (e.g., RaLAP), the receiving part of the RaLTP entity maymay perform bearer demultiplexing according to demultiplexing (intra-node routing) as disclosed herein. At step, remove or deliver the RaLAP SDU to the selected upper layer protocol entity.

The bearer demultiplexing may be performed based on RaL intra-node routing (bearer demultiplexing) configuration as illustrated in Table 3.

Each entry of the RaL bearer demultiplexing configuration includes one or more of the following: an RaLAP Routing ID consisting of an RaLAP address and if applicable, an RaLAP path identity; a tunnel identity; or an upper layer protocol identity.

For an RaLAP SDU to be transmitted to upper layers, the RaLAP entity may, if there is RaL bearer demultiplexing configuration as illustrated in Table 3, select any upper layer protocol identity or in an alternative embodiment, select a default upper layer protocol identity as pre-configured or pre-provisioned into the RaLAP node or in yet another embodiment, or select a default upper layer protocol identity that is specified for, e.g. by standards.

Else 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 identity is the same as the TEID field, select the upper layer protocol identity of the entry.

For an RaLTP SDU to be transmitted to upper layers, the RaLAP entity may, if there is RaL bearer demultiplexing configuration as illustrated in Table 3, select any upper layer protocol identity or in an alternative embodiment, select a default upper layer protocol identity as pre-configured or pre-provisioned into the RaLTP node or in yet another embodiment, or select a default upper layer protocol identity that is specified for, e.g. by standards.

Else if there is an entry in the RaL bearer demultiplexing configuration whose RaLAP address matches the RaLAP address for this RaLTP SDU, and whose tunnel identity is same as the TEID field, select the upper layer protocol identity of the entry.

For a link, when a 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 part, the transmitting part of this RaLAP entity, the receiving part of the RaLAP entity receiving the traffic subject to flow control may: construct a RaLAP Control PDU for flow control feedback in accordance with control PDU formats 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.

Else submit this RaLAP Control PDU to any egress RaL RLC channel of the egress link.

The flow control feedback mechanism described above is a flow control for a specific link, the flow control feedback is between two adjacent nodes.

Herein, it is also disclosed to enhance the feedback scheme above to allow end-to-end flow control feedback between peer RaLAP entities. Such flow control feedback scheme may be beneficial for example for use cases where RaLAP entity provides RaLTP functions such as bearer multiplexing or bearer demultiplexing.

The quantity reported in the flow control feedback may be available buffer size, or preferred data rate, etc. In order to limit flow control feedback reporting overhead, the quantity reported in the flow control feedback may be quantized over a number of levels, wherein a level may correspond to a range of the quantity being reported. For example, if the quantity reported in a flow control feedback is expressed in kilobyte, a quantized level could represent for example a range from 0 to 100 kilobytes, the next level could represent a range from above 100 kilobytes to 200 kilobytes and so on.

The flow control feedback mechanism described herein may also be used by RaLTP protocol. For example, the RaLTP protocol may be used for an end-to-end flow control feedback mechanism wherein the link, tunnel or bearer subject to flow control is between two peers RaLTP protocols. The following is an exemplary embodiment.

For a link, the receiving part of the RaLTP entity receiving the traffic subject to flow control: when a 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 part, the transmitting part of this RaLTP entity may: construct a RaLTP Control PDU for flow control feedback in accordance with control PDU formats disclosed herein or transmit this RaLTP Control PDU following RaLTP PDU transmission procedure as described herein with regard to transmitting operation.

The procedure above may also be used by an RaLAP protocol to perform an end-to-end flow control. The following is an exemplary text:

For a link, when a 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 part, the transmitting part of this RaLAP entity, the receiving part of the RaLAP entity receiving the traffic subject to flow control may: construct a RaLAP Control PDU for flow control feedback in accordance with control PDU disclosed herein; or transmit this RaLAP Control PDU following RaLAP PDU transmission procedure as described herein with regard to transmitting operation.

The granularity of a flow control feedback may be per RLC channel feedback, or per bearer or per tunnel feedback, or per sidelink L2 destination feedback, or per RLC channel per sidelink L2 destination feedback or per RaLAP entity feedback or per RaLAP address feedback or per routing ID feedback or per node feedback.

When a flow control poll is to be transmitted over an egress link, the transmitting part of the RaLAP entity at a node, constructs a RaLAP Control PDU for flow control polling in accordance with control PDU disclosed herein.

If the egress RaL RLC channel for the RaLAP control PDU is configured as specified herein, submit this RaLAP Control PDU to the configured egress RaL RLC channel of the egress link. Else: submit this RaLAP Control PDU to any egress RaL RLC channel of the egress link.

In an additional embodiment, an RaLAP protocol may use the flow control polling to request the peer RaLAP protocol to increase data rate or to decrease data rate.

The flow control polling mechanism described herein may also be used by RaLTP protocol. For example, the RaLTP protocol may be used for an end-to-end flow control polling mechanism wherein the link, tunnel or bearer subject to flow control polling is between two peer RaLTP protocols. The following is an exemplary embodiment:

For a link, the RaLTP entity at the RaLTP may when a flow control polling is triggered, the transmitting part of this RaLTP entity may: construct a RaLTP Control PDU for flow control polling in accordance with control PDU format disclosed herein; or transmit this RaLTP Control PDU following RaLTP PDU transmission procedure as described herein with regard to transmitting operation.

The procedure above may also be used by an RaLAP protocol to perform an end-to-end flow control polling. The following is an exemplary text.

For a link, the RaLAP entity at a node may when a flow control polling is triggered, the transmitting part of this RaLAP entity may: construct a RaLAP Control PDU for flow control polling in accordance with control PDU format disclosed herein; or transmit this RaLAP Control PDU following RaLAP PDU transmission procedure as described herein with regard to transmitting operation.

The granularity of a flow control polling may be per RLC channel, per bearer or per tunnel, per sidelink L2 destination, or per RLC channel per sidelink L2 destination, or per RaLAP entity, per RaLAP address, or per routing ID or per node.

When a RaL RLF recovery failure is detected, for each egress link associated with the detected RLF, the transmitting part of the RaLAP entity may construct an RaLAP Control PDU for RaL RLF indication in accordance with control PDU formats disclosed herein. if the egress RaL RLC channel for the RaLAP control PDU is configured as specified herein, submit this RaLAP Control PDU to the configured egress RaL RLC channel of the egress link; else submit this RaLAP Control PDU to any egress RaL RLC channel of the egress link.

The granularity of a RLF indication may be per link, per RLC channel, per bearer or per tunnel, per sidelink L2 destination, per RLC channel per sidelink L2 destination, per RaLAP entity, per RaLAP address, per routing ID, or per node.

indicate to upper layers that the backhaul RLF indication has been received for the ingress link where this RaLAP Control PDU is received. Upon receiving a RaLAP Control PDU for backhaul RLF indication from lower layer (e.g., ingress RaL RLC channel), the receiving part of the RaLAP entity may:

When a keep alive poll is to be transmitted over an egress link, the transmitting part of the RaLAP entity may constructs a RaLAP Control PDU for keep alive polling in accordance with control PDU format disclosed herein. If the egress RaL RLC channel for the RaLAP control PDU is configured as specified herein, submit this RaLAP Control PDU to the configured egress RaL RLC channel of the egress link. Else: submit this RaLAP Control PDU to any egress RaL RLC channel of the egress link.

The keep alive polling mechanism described herein may also be used by RaLTP protocol. For example, the RaLTP protocol may be used for an end-to-end keep alive polling mechanism wherein the link, tunnel or bearer subject to keep alive polling is between two peer RaLTP protocols. The following is an exemplary embodiment.

For a link, the RaLTP entity at the RaLTP, may when a keep alive polling is triggered, the transmitting part of this RaLTP entity may: construct a RaLTP Control PDU for keep alive polling in accordance with control PDU formats disclosed herein; or transmit this RaLTP Control PDU following RaLTP PDU transmission procedure as described herein with regard to transmitting operation.

The procedure above may also be used by an RaLAP protocol to perform an end-to-end keep alive polling. The following is exemplary text.

For a link, the RaLAP entity at the RaLAP may: when a keep alive polling is triggered, the transmitting part of this RaLAP entity may: construct a RaLAP Control PDU for keep alive polling in accordance with control PDU formats disclosed herein; or transmit this RaLAP Control PDU following RaLAP PDU transmission procedure as described herein with regard to transmitting operation.

The granularity of a keep alive polling may be per link, per RLC channel, per bearer, per tunnel, per sidelink L2 destination, per RLC channel per sidelink L2 destination, per RaLAP entity, per RaLAP address, per routing ID, or per node.

As described herein, one of the functions of the adaptation layer (i.e. RaLAP or RaLTP) is the multiplexing of bearers into RLC channels i.e. the determination of one or more upper layer protocol entities for, e.g. PDCP entities whose traffics are to be mapped to the same SL RLC channel or Uu RLC channel. As such, the multiplexing function may require the identification of the upper layer protocol instance associated with a data packet, i.e. an upper layer protocol identity for, e.g. PDCP entity identity that will be used for packet multiplexing, and included into the adaptation layer header. Denoted herein is such an identity (e.g., a bearer identity or bearer ID for short, the PDCP entity identity, an identity of a tunnel associated with a bearer, an identity of a tunnel associated with an upper layer protocol above the RaLAP protocol or the RaLTP protocol, an identity of an upper layer protocol above the RaLAP protocol or the RaLTP protocol, or the identity of the RaLTP protocol. Another function of the adaptation layer (e.g., RaLAP or RALTP) is the demultiplexing of bearers, e.g., demultiplexing of traffic mapped to the same SL RLC channel, but destinated to different upper layer protocol entities for example PDCP entities within the same node. This function is also referred to in this disclosure as intra-node routing.

201 204 209 204 201 209 209 201 204 In one embodiment, the intra-node routing identity or bearer identity generically denoted in this disclosure TEID, may only have local significance within the node performing multiplexing function (for e.g. a source remote UE, or base station), or demultiplexing function (for example a destination remote UE, or a base station). In another embodiment, the TEID may have broader significance for example across more than one node, for example in both source remote UEand destination remote UE, or in both base station and destination remote UEor in source remote UEand base station, etc.

In one embodiment, the TEID structure may comprise of the identity of the source node and a local TEID value, wherein the local TEID has only local significance. In another embodiment, the TEID structure may comprise of the identity of the destination node and a local TEID value, wherein the local TEID has only local significance. In yet another embodiment, the TEID may be a single component identity, wherein the TEID has either only local significance or a broader significance as defined herein.

201 204 209 204 201 204 209 204 209 204 201 204 204 201 209 The source node (for e.g. source remote UEor base station) and destination node (for e.g. destination remote UEor base station) may exchange signaling, for example in the control plane, to configure each other with their respective TEID(s). The source node (for e.g. source remote UEor base station) may configure the destination node (for e.g. destination remote UEor base station) with one or more TEIDs of the source node, or one or more TEIDs of the destination nodes or both. Similarly, the destination node (for e.g. destination remote UEor base station) may configure the source node (for e.g. source remote UEor base station), with one or more TEIDs of the destination node, or one or more TEIDs of the source node TEID or both. Alternatively, a third entity for example a base stationmay configure the source remote UEor into the destination remote UE, with one or more TEIDs, wherein the one or more TEIDs may have significance in both the source node and the destination node.

202 203 201 209 204 209 201 201 209 As discussed herein, one or more tunneling protocol identity space may be configured into a node for example a relay UE node, a UE-to-Network Relay node, a source remote UE, a remote destination UE, a UE, an RSU, a gNB, a gNB DU, or a gNB CU. A tunneling protocol identity may be defined on the basis of one tunneling protocol identity space per serving gNB, or on the basis of one tunneling protocol identity space per destination remote UE, or on the basis of one tunneling protocol identity space per source remote UE, or on the basis of one tunneling protocol identity space per layer-2 destination ID, or on the basis of one tunneling identity space per routing tree or on the basis of one tunneling protocol identity space per routing network, etc. In this case, the structure of the TEID may additionally include the TEID space identity. Similarly, if a node (for e.g. a source remote UE, a destination remote UE, a U2U relay or U2N relay) is configured with more than one node address space for that node (for e.g. a source UE is configured with more than one source node address space), then the node address structure may comprise of a node address space identity and the address of the node within that address space. For example, a source node address may comprise of the address space identity and the address of the source within that address space.

The RaLAP Data PDU or the RaLTP Data PDU may be used to convey one of the following in addition to the PDU header upper layer data.

The RaLAP Control PDU or the RaLTP control PDU is used to convey one of the following [in addition to the PDU header]: flow control feedback with various level of granularity as described herein with regard to flow control feedback disclosed herein; flow control polling with various level of granularity as described herein with regard to flow control polling disclosed herein; RaL RLF indication with various level of granularity as described herein with regard to relay link RLF indication disclosed herein; or keep alive polling with various level of granularity as described herein with regard to end-to-end keep alive disclosed herein.

An RaLAP PDU or an RaLTP PDU is a bit string that is byte aligned (e.g., multiple of 8 bits) in length. The formats of RaLAP PDUs and RaLTP PDUs are described in later section below.

37 FIG. Theillustrates an exemplary embodiment of an RaLAP data PDU. In this example, the TEID field (tunnel identity) is coded on 2 bits, the destination field is coded on 10 bits and the PATH field (or path identity) is coded on 10 bits. The D/C (Data or Control) field is coded on 1 bit and there is only one reserved (R) bit. The Data field start from the fourth octet and can be multiple octets long.

38 FIG. Theillustrates another exemplary embodiment of an RaLAP data PDU. In this example, the TEID field (tunnel identity) is coded on 3 bits, the destination field is coded on 10 bits and the PATH field (or path identity) is coded on 10 bits. The D/C (Data or Control) field is coded on 1 bit and there is no reserved (R) bit. The Data field start from the fourth octet and can be multiple octets long.

39 FIG. illustrates yet another exemplary embodiment of an RaLAP data PDU. In this example, the R bits may be re-used to signal the TEID. In a first embodiment, the TEID filed may be coded over 3 bits, wherein all the reserved bits are used to represents the TEID. In a second embodiment, as represented by the circle around the R bits and the arrow pointing away from the solid line to the dash line, the TEID (tunnel identity) field may be coded over more than 3 bits, the destination field may be coded on less than 10 bits or the PATH field (or path identity) may be coded on less than 10 bits. In this embodiment, the D/C (Data or Control) field if it exists may be code coded on 1 bit, otherwise there is no DC filed. Yet in a third embodiment, the R field may be coded in less than 3 bits e.g., the TEID field may use up to all three R bits. In this embodiment, there might not be an R bit. The Data field start from the fourth octet and can be multiple octets long.

40 FIG. Theillustrates an exemplary embodiment of an RaLTP data PDU. In this example, the TEID (tunnel identity) field is coded on 4 bytes (.e.g., 4 octets). The Data field start from the fifth octet and can be multiple octets long.

41 FIG. Theillustrates another exemplary embodiment of an RaLTP data PDU. In this example, the TEID field (tunnel identity) is coded on 4 octets. The D/C (Data or Control) field is coded on 1 bit and there are three reserved (R) bits. The Data field start from the fifth octet and can be multiple octets long.

The following are examples of a control PDU for RaLAP or RaLTP.

42 FIG. Theillustrates an exemplary embodiment of an RaLAP or an RaLTP control PDU. In a first embodiment, the PDU type might be coded on 3 bits. In a second embodiment, as represented by the circle around the R bits and the arrow pointing away from the solid line to the dash line, the PDU Type may be coded over more than 3 bits. The D/C (Data or Control) field if it exists may be code coded on 1 bit, otherwise there is no DC filed. Similarly, the PDU type coding may re-used some of the R bits. In this second embodiment, the R bit may be coded in less than 4 bits, and possibly depending on the size of the PDU Type field there might not be an R bit. In a third embodiment, the PDU Type may be coded in less than 3 bits. In this third embodiment, there might be more than 4 reserved bits. In this example there is no TEID field. One possible specification direction is to define a standardized TEID value that is used for the exchange of control PDU between peer RaLAP or RaLTP protocols. Alternatively, the TEID used for control PDU may be configured into the nodes or exchanges between nodes. It should be noted that in an alternative to this embodiment, a TEID filed may be included in the control PDU wherein is the TEID field may be 1 to 4 bits long. In the case the TEID field is 4 bits long, there is no R bit.

43 FIG. Theillustrates another exemplary embodiment of an RaLAP or an RaLTP control PDU. In this example, the PDU Type field is coded over 3 bits. The D/C (Data or Control) field is coded on 1 bit. The TEID field is coded over 4 octets.

44 FIG. Theillustrates an exemplary embodiment of an RaLAP or an RaLTP control PDU. In a first embodiment, the PDU type might be coded on 3 bits. In a second embodiment, as represented by the circle around the R bits and the arrow pointing away from the solid line to the dash line, the PDU Type may be coded over more than 3 bits. The D/C (Data or Control) field if it exists may be code coded on 1 bit, otherwise there is no DC filed. Similarly, the PDU type coding may re-used some of the R bits. In this second embodiment, the R bit may be coded in less than 4 bits, and possibly depending on the size of the PDU Type field there might not be an R bit. In a third embodiment, the PDU Type may be coded in less than 3 bits. In this third embodiment, there might be more than 4 reserved bits. In this example the TEID field is 4 octet long. It should be noted that in a fourth embodiment, a TEID filed may be included in the control PDU wherein is the TEID field may be 1 to 4 bits long. In the case the TEID field is 4 bits long, there is no R bit.

45 FIG. 46 FIG. 45 FIG. 46 FIG. 47 FIG. 48 FIG. 47 FIG. 48 FIG. 47 FIG. 48 FIG. 49 FIG. 50 FIG. 201 201 209 201 204 209 204 201 Herein are exemplary illustrations of tunnel endpoint identity structure, and example of tunnel endpoint identity structure inside sidelink adaptation layer protocol header. It is understood the exemplary illustrations of TEID provided herein may be used inside any PDU header (control or data) of sidelink adaptation layer protocol (RaLAP or RaLTP) proposed in this disclosure. In, The TEID is coded on 4 bytes (e.g., 4 octets) with the SOURCE field coded on 10 bits and the local TEID (L-TEID) coded on 22 bits. In, TEID is also coded on 4 bytes with the SOURCE field coded on 24 bits and the local TEID may be coded on 8 bits or less for e.g. 5 bits. In should be noted that inand, the SOURCE and the L-TEID may be coded in any combination of bits, For example, the SOURCE field may have been coded on 16 bits for example if the standards decided to use a SOURCE field length that is same as that of C-RNTI. In this case the TEID may be coded on 16 bits or less with the remaining bits used for data or other header information.and, are illustrations of the use of source remote node (example source remote UE) Identity and local TEID in a Data PDU header of the sidelink adaptation protocol.illustrates a case where the SOURCE field is coded on 24 bits and the local TEID is coded on 5 bits. This example assumed the SOURCE may be coded like a sidelink Source Layer-2 ID, which is coded on 24 bits. The coding of the local TEID on 5 bits assumes the local TEID range is same as the maximum number of 32 bearers for communication per UE currently specified for the Uu interface.illustrates a case where the SOURCE field is coded on 24 bits and the local TEID is coded on 9 bits for a total of 512 possible bearers per source remote UE, or 512 possible bearers per destination remote UE, or 512 possible bearers per context of source Remote UEin a base stationor the like, or 512 possible bearers per context of destination remote UEin a base station. This is example assumed the SOURCE may be coded like a sidelink Source Layer-2 ID, which is coded on 24 bits. The local TEID coded on 5 bits assumes the local TEID range is same as the maximum number of 512 bearers for NR sidelink communication per UE. In bothand, the DESTINATION field is also ode on 24 bites, with the assumption that the DESTINATION field may be coded like a sidelink Destination Layer-2 ID, which is coded on 24 bits.andare illustrations of the use of source remote node(e.g., source remote UE) Identity and local TEID in a Control PDU header of the sidelink adaptation protocol, where in the SOURCE field, the local TEID and the DESTINATION field are coded the same way as in the data PDU header.

If not otherwise mentioned in the definition of each field, the bits in the parameters may be interpreted as follows: the left most bit string is the first and most significant and the right most bit is the last and least significant bit.

Unless otherwise mentioned, integers are encoded in standard binary encoding for unsigned integers. In all cases the bits appear ordered from MSB to LSB when read in the PDU.

202 203 209 204 This field carries RaLAP address of destination of a base station, a peer remote UE or a relay node for e.g. Relay UE node, UE-to-Network Relay node. In the context of the adaptation protocol layer, this filed may be interpreted as the identity of the destination remote UE, or of the destination base station, or of any other destination node.

201 202 203 201 204 This field carries RaLAP address of source of a base station, a remote UEor a relay node for e.g. Relay UE node, UE-to-Network Relay node. In the context of the adaptation protocol layer, this filed may be interpreted as the identity of the source remote UE, or of the source base station, or of any other source node.

201 209 This field identifies, a bearer, or an upper layer protocol above the adaptation layer. The field may only have local significance relative to the context of a node for example a source node or a remote node. Alternatively, this field may have broader significance, for example across more than one contexts, for example across the context of a source remote node (e.g. source remote UE) and the context of a destination remote node (e.g. destination remote UE).

This field carries RaLAP path identity.

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

Similarly, in the case of RaLAP protocol that also provide RaLTP function, this field carries the RaLAP SDU (for e.g. PDCP PDU). In the case of RaLAP that operates with a separate RaLTP protocol, this field carries the RaLAP SDU (for e.g. RaLTP PDU).

Reserved. In a given version of the protocol, the reserved bits may be set to 0. In yet another version of the protocol, one or more of the reserved bits may be used to carry out additional control message or information between peer RaLAP protocols or between peer RaLTP protocol.

In the case of RaLAP protocol, this field indicates whether the corresponding RaLAP PDU is an RaLAP Data PDU or an RaLAP Control PDU. Similarly, in the case of RaLTP protocol, this field indicates whether the corresponding RaLTP PDU is an RaLTP Data PDU or an RaLTP Control PDU.

TABLE 5 D/C field Bit Description 0 RaLAP Control PDU for RaLAP protocol or RaLTP control PDU for RaLTP protocol 1 RaLAP Data PDU for RaLAP protocol or RaLTP data PDU for RaLTP protocol

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

TABLE 6 PDU Type Example 1 Bit Description 0 End-to-end keep-alive polling 1 End-to-end keep-alive response 10 End-to-end RLF indication 11 End-to-end flow control feedback 100 End-to-end flow control polling 101-111 Reserved

TABLE 7 PDU Type Example 2 Bit Description 0 Flow control feedback per BH RLC channel 1 Flow control feedback per routing ID 10 Flow control feedback polling 11 BH RLF indication 100 Keep alive poling 101 Keep alive poling response 0110-1111 Reserved

The RaL RLC channel ID is the identity of the RAL RLC channel. It may be 16 bits long.

The routing ID is the identity of a route, that comprises a routing address and a path identity. It may be 20 bits long.

1 FIG. 50 FIG. 52 FIG.F 52 FIG.G 1 FIG. 50 FIG. It is understood that the entities performing the steps illustrated herein, such as-, may be logical entities. The steps may be stored in a memory of, and executing on a processor of, a device, server, or computer system such as those illustrated inor. Skipping steps, combining steps, or adding steps between exemplary methods disclosed herein (e.g.,-) is contemplated.

Table 8 provides exemplary abbreviations and definitions.

TABLE 8 Abbreviations and Definitions Abbreviations Definitions 3GPP 3rd Generation Partnership Project 5G 5th Generation 5GS 5G System AMF Access and Mobility Management Function APP or AP Application AS Access Stratum BAP Backhaul Adaptation Protocol CN Core Network CU Central Unit CP Control Plane D2D Device to Device Communication DeNB Donor eNB DLL Data Link Layer DU Distributed Unit E2E End to End eNB Evolved Node B gNB NR NodeB GPRS General Packet Radio Service GTP GPRS Tunneling Protocol GTP-C GTP Control GTP-U GTP User HARQ Hybrid Automatic Repeat Request IoT Internet of Things IP Internet Protocol ID Identity or Identifier L1 Layer-1 L2 Layer-2 LCH Logical Channel LoL Local Link LTE Long Term Evolution L-TEID Local TEID MAC Medium Access Control MM Mobility Management N2 Reference point between the (R)AN and the AMF N3 Reference point between the (R)AN and the UPF N6 Reference point between the UPF and a Data Network N11 Reference point between the AMF and the SMF NAS Non-AS NB NodeB NG Next Generation NR New Radio NW Network PC5 The reference point between ProSe-enabled UEs used for control and user plane for ProSe Direct Discovery, ProSe Direct Communication and ProSe UE-to-Network Relay PDCP Packet Data Convergence Protocol PDU Protocol Data Unit PHY Physical layer ProSe Proximity-Based Services PS Protocol Stack PSID Provider Service Identifier QoS Quality of Service R Reserved RaL Relay Link RaLAP Relay Link Adaptation Protocol RaLTP Relay Link Tunneling Protocol RAN or Radio Access Network R(AN) RLC Radio Link Control ROHC Robust Header Compression RRC Radio Resource Control RSU Roadside Unit RX Receiver, Receive SA System Aspects SA1 SA working group 1 SA2 SA working group 2 SCTP Stream Control Transmission Protocol SDAP Service Data Adaptation Protocol SDU Service Data Unit SI Study Item SL Sidelink SM Session Management SMF SM Function SRC Source or SOURCE TCP Transmission Control Protocol TEID or Tunnel Endpoint ID TE-ID TS Technical Specification TR Technical Report TX Transmitter, Transmit U2N UE to Network U2U UE to UE UDP User Datagram Protocol UE User Equipment UL Uplink UP User Plane Uu Radio Interface between the base station (e.g. Node B) and the UE V2X Vehicle-to-X Communication

51 FIG. 901 902 902 902 901 903 illustrates an exemplary display (e.g., graphical user interface) that may be generated based on the methods, systems, and devices of sidelink adaptation protocol for remote UE connectivity, as discussed herein. Display interface(e.g., touch screen display) may provide text in blockassociated with of sidelink adaptation protocol for remote UE connectivity, such as sidelink adaptation related parameters, method flow, and sidelink adaptation protocol associated current conditions. Progress of any of the steps (e.g., sent messages or success of steps) discussed herein may be displayed in block. In addition, graphical outputmay be displayed on display interface. Graphical outputmay be the topology of the devices implementing the methods, systems, and devices of sidelink adaptation protocol for remote UE connectivity, a graphical output of the progress of any method or systems discussed herein, or the like.

The 3rd Generation Partnership Project (3GPP) develops technical standards for cellular telecommunications network technologies, including radio access, the core transport network, and service capabilities—including work on codecs, security, and quality of service. Recent radio access technology (RAT) standards include WCDMA (commonly referred as 3G), LTE (commonly referred as 4G), LTE-Advanced standards, and New Radio (NR), which is also referred to as “5G”. 3GPP NR standards development is expected to continue and include the definition of next generation radio access technology (new RAT), which is expected to include the provision of new flexible radio access below 7 GHz, and the provision of new ultra-mobile broadband radio access above 7 GHz. The flexible radio access is expected to consist of a new, non-backwards compatible radio access in new spectrum below 6 GHz, and it is expected to include different operating modes that may be multiplexed together in the same spectrum to address a broad set of 3GPP NR use cases with diverging requirements. The ultra-mobile broadband is expected to include cmWave and mmWave spectrum that will provide the opportunity for ultra-mobile broadband access for, e.g., indoor applications and hotspots. In particular, the ultra-mobile broadband is expected to share a common design framework with the flexible radio access below 7 GHz, with cmWave and mmWave specific design optimizations.

3GPP has identified a variety of use cases that NR is expected to support, resulting in a wide variety of user experience requirements for data rate, latency, and mobility. The use cases include the following general categories: enhanced mobile broadband (eMBB) ultra-reliable low-latency Communication (URLLC), massive machine type communications (mMTC), network operation (e.g., network slicing, routing, migration and interworking, energy savings), and enhanced vehicle-to-everything (eV2X) communications, which may include any of Vehicle-to-Vehicle Communication (V2V), Vehicle-to-Infrastructure Communication (V2I), Vehicle-to-Network Communication (V2N), Vehicle-to-Pedestrian Communication (V2P), and vehicle communications with other entities. Specific service and applications in these categories include, e.g., monitoring and sensor networks, device remote controlling, bi-directional remote controlling, personal cloud computing, video streaming, wireless cloud-based office, first responder connectivity, automotive ecall, disaster alerts, real-time gaming, multi-person video calls, autonomous driving, augmented reality, tactile internet, virtual reality, home automation, robotics, and aerial drones to name a few. All of these use cases and others are contemplated herein.

52 FIG.A 5 FIG. 50 FIG. 100 100 102 102 102 102 102 102 102 102 102 100 103 104 105 103 104 105 106 107 109 108 110 112 113 113 a b c d e f g b b b illustrates an example communications systemin which the methods and apparatuses of sidelink adaptation protocol for remote UE connectivity, such as the systems and methods illustrated inthroughdescribed and claimed herein may be used. The communications systemmay include wireless transmit/receive units (WTRUs),,,,,, or(which generally or collectively may be referred to as WTRUor WTRUs). The communications systemmay include, a radio access network (RAN)/////, a core network//, a public switched telephone network (PSTN), the Internet, other networks, and Network Services. Network Servicesmay include, for example, a V2X server, V2X functions, a ProSe server, ProSe functions, IoT services, video streaming, or edge computing, etc.

102 102 102 102 102 102 102 102 102 102 102 102 102 102 a b c d e f g a b c d e f g 52 FIG.A 52 FIG.B 52 FIG.C 52 FIG.D 52 FIG.E 52 FIG.F It will be appreciated that the concepts disclosed herein may be used with any number of WTRUs, base stations, networks, or network elements. Each of the WTRUs,,,,,, ormay be any type of apparatus or device configured to operate or communicate in a wireless environment. Although each WTRU,,,,,, ormay be depicted in,,,,, oras a hand-held wireless communications apparatus, it is understood that with the wide variety of use cases contemplated for 5G wireless communications, each WTRU may comprise or be embodied in any type of apparatus or device configured to transmit or receive wireless signals, including, by way of example only, user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a tablet, a netbook, a notebook computer, a personal computer, a wireless sensor, consumer electronics, a wearable device such as a smart watch or smart clothing, a medical or eHealth device, a robot, industrial equipment, a drone, a vehicle such as a car, bus, truck, train, or airplane, and the like.

100 114 114 114 114 114 114 114 102 102 102 106 107 109 110 113 112 114 118 118 119 119 120 120 106 107 109 110 112 113 118 118 102 102 106 107 109 110 113 112 a b a b a b a a b c b a b a b a b a b c 52 FIG.A The communications systemmay also include a base stationand a base station. In the example of, each base stationsandis depicted as a single element. In practice, the base stationsandmay include any number of interconnected base stations or network elements. Base stationsmay be any type of device configured to wirelessly interface with at least one of the WTRUs,, andto facilitate access to one or more communication networks, such as the core network//, the Internet, Network Services, or the other networks. Similarly, base stationmay be any type of device configured to wiredly or wirelessly interface with at least one of the Remote Radio Heads (RRHs),, Transmission and Reception Points (TRPs),, or Roadside Units (RSUs)andto facilitate access to one or more communication networks, such as the core network//, the Internet, other networks, or Network Services. RRHs,may be any type of device configured to wirelessly interface with at least one of the WTRUs, e.g., WTRU, to facilitate access to one or more communication networks, such as the core network//, the Internet, Network Services, or other networks

119 119 102 106 107 109 110 113 112 120 120 102 102 106 107 109 110 112 113 114 114 a b d a b e f a b TRPs,may be any type of device configured to wirelessly interface with at least one of the WTRU, to facilitate access to one or more communication networks, such as the core network//, the Internet, Network Services, or other networks. RSUsandmay be any type of device configured to wirelessly interface with at least one of the WTRUor, to facilitate access to one or more communication networks, such as the core network//, the Internet, other networks, or Network Services. By way of example, the base stations,may be a Base Transceiver Station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a Next Generation Node-B (gNode B), a satellite, a site controller, an access point (AP), a wireless router, and the like.

114 103 104 105 114 103 104 105 114 114 114 114 114 114 a b b b b a b b a a a The base stationmay be part of the RAN//, which may also include other base stations or network elements (not shown), such as a Base Station Controller (BSC), a Radio Network Controller (RNC), relay nodes, etc. Similarly, the base stationmay be part of the RAN//, which may also include other base stations or network elements (not shown), such as a BSC, a RNC, relay nodes, etc. The base stationmay be configured to transmit or receive wireless signals within a particular geographic region, which may be referred to as a cell (not shown). Similarly, the base stationmay be configured to transmit or receive wired or wireless signals within a particular geographic region, which may be referred to as a cell (not shown) for methods, systems, and devices of sidelink adaptation protocol for remote UE connectivity, as disclosed herein. Similarly, the base stationmay be configured to transmit or receive wired or wireless signals within a particular geographic region, which may be referred to as a cell (not shown). The cell may further be divided into cell sectors. For example, the cell associated with the base stationmay be divided into three sectors. Thus, in an example, the base stationmay include three transceivers, e.g., one for each sector of the cell. In an example, the base stationmay employ multiple-input multiple output (MIMO) technology and, therefore, may utilize multiple transceivers for each sector of the cell.

114 102 102 102 102 115 116 117 115 116 117 a a b c g The base stationsmay communicate with one or more of the WTRUs,,, orover an air interface//, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, cmWave, mmWave, etc.). The air interface//may be established using any suitable radio access technology (RAT).

114 118 118 119 119 120 120 115 116 117 115 116 117 b a b a b a b b b b b b b The base stationsmay communicate with one or more of the RRHs,, TRPs,, or RSUs,, over a wired or air interface//, which may be any suitable wired (e.g., cable, optical fiber, etc.) or wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, cmWave, mmWave, etc.). The air interface//may be established using any suitable radio access technology (RAT).

118 118 119 119 120 120 102 102 102 102 115 116 117 115 116 117 a b a b a b c d e f c c c c c c The RRHs,, TRPs,or RSUs,, may communicate with one or more of the WTRUs,,,over an air interface//, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, cmWave, mmWave, etc.). The air interface//may be established using any suitable radio access technology (RAT).

102 102 102 102 102 102 115 116 117 115 116 117 a b c d e f d d d d d d The WTRUs,,,,, ormay communicate with one another over an air interface//, such as Sidelink communication, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, cmWave, mmWave, etc.). The air interface//may be established using any suitable radio access technology (RAT).

100 114 103 104 105 102 102 102 118 118 119 119 120 120 103 104 105 102 102 102 102 115 116 117 115 116 117 a a b c a b a b a b b b b c d e f c c c The communications systemmay be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base stationin the RAN//and the WTRUs,,, or RRHs,,TRPs,and RSUs,, in the RAN//and the WTRUs,,,, may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface//or//respectively using wideband CDMA (WCDMA). 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).

114 102 102 102 118 118 119 119 120 120 103 104 105 102 102 115 116 117 115 116 117 115 116 117 115 116 117 a a b c a b a b a b b b b c d c c c c c c In an example, the base stationand the WTRUs,,, or RRHs,, TRPs,, or RSUs,in the RAN//and the WTRUs,, may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface//or//respectively using Long Term Evolution (LTE) or LTE-Advanced (LTE-A). In the future, the air interface//or//may implement 3GPP NR technology. The LTE and LTE-A technology may include LTE D2D and V2X technologies and interfaces (such as Sidelink communications, etc.). Similarly, the 3GPP NR technology includes NR V2X technologies and interface (such as Sidelink communications, etc.).

114 103 104 105 102 102 102 102 118 118 119 119 120 120 103 104 105 102 102 102 102 a a b c g a b a b a b b b b c d e f The base stationin the RAN//and the WTRUs,,, andor RRHs,, TRPs,or RSUs,in the RAN//and the WTRUs,,,may implement radio technologies such as IEEE 802.16 (e.g., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1×, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.

114 114 102 102 114 102 114 102 102 114 110 114 110 106 107 109 c c e c d c e c c 52 FIG.A 52 FIG.A The base stationinmay be a wireless router, Home Node B, Home eNode B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a train, an aerial, a satellite, a manufactory, a campus, and the like, for implementing the methods, systems, and devices of sidelink adaptation protocol for remote UE connectivity, as disclosed herein. In an example, the base stationand the WTRUs, e.g., WTRU, may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). similarly, the base stationand the WTRUs, may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another example, the base stationand the WTRUs, e.g., WTRU, may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, NR, etc.) to establish a picocell or femtocell. As shown in, the base stationmay have a direct connection to the Internet. Thus, the base stationmay not be required to access the Internetvia the core network//.

103 104 105 103 104 105 106 107 109 102 102 102 102 106 107 109 b b b a b c d The RAN//or RAN//may be in communication with the core network//, which may be any type of network configured to provide voice, data, messaging, authorization and authentication, applications, or voice over internet protocol (VoIP) services to one or more of the WTRUs,,,. For example, the core network//may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, packet data network connectivity, Ethernet connectivity, video distribution, etc., or perform high-level security functions, such as user authentication.

52 FIG.A 103 104 105 103 104 105 106 107 109 103 104 105 103 104 105 103 104 105 103 104 105 106 107 109 b b b b b b b b b Although not shown in, it will be appreciated that the RAN//or RAN//or the core network//may be in direct or indirect communication with other RANs that employ the same RAT as the RAN//or RAN//or a different RAT. For example, in addition to being connected to the RAN//or RAN//, which may be utilizing an E-UTRA radio technology, the core network//may also be in communication with another RAN (not shown) employing a GSM or NR radio technology.

106 107 109 102 102 102 102 102 108 110 112 108 110 112 112 103 104 105 103 104 105 a b c d e b b b The core network//may also serve as a gateway for the WTRUs,,,,to access the PSTN, the Internet, or other networks. The PSTNmay include circuit-switched telephone networks that provide plain old telephone service (POTS). The Internetmay include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and the internet protocol (IP) in the TCP/IP internet protocol suite. The networksmay include wired or wireless communications networks owned or operated by other service providers. For example, the networksmay include any type of packet data network (e.g., an IEEE 802.3 Ethernet network) or another core network connected to one or more RANs, which may employ the same RAT as the RAN//or RAN//or a different RAT.

102 102 102 102 102 102 100 102 102 102 102 102 102 102 114 114 a b c d e f a b c d e f g a c 52 FIG.A Some or all of the WTRUs,,,,, andin the communications systemmay include multi-mode capabilities, e.g., the WTRUs,,,,, andmay include multiple transceivers for communicating with different wireless networks over different wireless links for implementing methods, systems, and devices of sidelink adaptation protocol for remote UE connectivity, as disclosed herein. For example, the WTRUshown inmay be configured to communicate with the base station, which may employ a cellular-based radio technology, and with the base station, which may employ an IEEE 802 radio technology.

52 FIG.A 106 107 109 115 116 117 115 116 117 c c c Although not shown in, it will be appreciated that a User Equipment may make a wired connection to a gateway. The gateway maybe a Residential Gateway (RG). The RG may provide connectivity to a Core Network//. It will be appreciated that much of the subject matter included herein may equally apply to UEs that are WTRUs and UEs that use a wired connection to connect with a network. For example, the subject matter that applies to the wireless interfaces,,and//may equally apply to a wired connection.

52 FIG.B 52 FIG.B 103 106 103 102 102 102 115 103 106 103 140 140 140 102 102 102 115 140 140 140 103 103 142 142 103 a b c a b c a b c a b c a b is a system diagram of an example RANand core networkthat may implement methods, systems, and devices of sidelink adaptation protocol for remote UE connectivity, as disclosed herein. As noted above, the RANmay employ a UTRA radio technology to communicate with the WTRUs,, andover the air interface. The RANmay also be in communication with the core network. As shown in, the RANmay include Node-Bs,, and, which may each include one or more transceivers for communicating with the WTRUs,, andover the air interface. The Node-Bs,, andmay each be associated with a particular cell (not shown) within the RAN. The RANmay also include RNCs,. It will be appreciated that the RANmay include any number of Node-Bs and Radio Network Controllers (RNCs.)

52 FIG.B 140 140 142 140 142 140 140 140 142 142 142 142 142 142 140 140 140 142 142 a b a c b a b c a b a b a b a b c a b As shown in, the Node-Bs,may be in communication with the RNC. Additionally, the Node-Bmay be in communication with the RNC. The Node-Bs,, andmay communicate with the respective RNCsandvia an Iub interface. The RNCsandmay be in communication with one another via an lur interface. Each of the RNCsandmay be configured to control the respective Node-Bs,, andto which it is connected. In addition, each of the RNCsandmay be configured to carry out or support other functionality, such as outer loop power control, load control, admission control, packet scheduling, handover control, macro-diversity, security functions, data encryption, and the like.

106 144 146 148 150 106 52 FIG.B The core networkshown inmay include a media gateway (MGW), a Mobile Switching Center (MSC), a Serving GPRS Support Node (SGSN), or a Gateway GPRS Support Node (GGSN). While each of the foregoing elements are depicted as part of the core network, it will be appreciated that any one of these elements may be owned or operated by an entity other than the core network operator.

142 103 146 106 146 144 146 144 102 102 102 108 102 102 102 a a b c a b c The RNCin the RANmay be connected to the MSCin the core networkvia an IuCS interface. The MSCmay be connected to the MGW. The MSCand the MGWmay provide the WTRUs,, andwith access to circuit-switched networks, such as the PSTN, to facilitate communications between the WTRUs,, and, and traditional land-line communications devices.

142 103 148 106 148 150 148 150 102 102 102 110 102 102 102 a a b c a b c The RNCin the RANmay also be connected to the SGSNin the core networkvia an IuPS interface. The SGSNmay be connected to the GGSN. The SGSNand the GGSNmay provide the WTRUs,, andwith access to packet-switched networks, such as the Internet, to facilitate communications between and the WTRUs,, and, and IP-enabled devices.

106 112 The core networkmay also be connected to the other networks, which may include other wired or wireless networks that are owned or operated by other service providers.

52 FIG.C 104 107 104 102 102 102 116 104 107 a b c is a system diagram of an example RANand core networkthat may implement methods, systems, and devices of sidelink adaptation protocol for remote UE connectivity, as disclosed herein. As noted above, the RANmay employ an E-UTRA radio technology to communicate with the WTRUs,, andover the air interface. The RANmay also be in communication with the core network.

104 160 160 160 104 160 160 160 102 102 102 116 160 160 160 160 102 a b c a b c a b c a b c a a. The RANmay include eNode-Bs,, and, though it will be appreciated that the RANmay include any number of eNode-Bs. The eNode-Bs,, andmay each include one or more transceivers for communicating with the WTRUs,, andover the air interface. For example, the eNode-Bs,, andmay implement MIMO technology. Thus, the eNode-B, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU

160 160 160 160 160 160 a b c a b c 52 FIG.C Each of the eNode-Bs,, andmay be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the uplink or downlink, and the like. As shown in, the eNode-Bs,, andmay communicate with one another over an X2 interface.

107 162 164 166 107 52 FIG.C The core networkshown inmay include a Mobility Management Gateway (MME), a serving gateway, and a Packet Data Network (PDN) gateway. While each of the foregoing elements are depicted as part of the core network, it will be appreciated that any one of these elements may be owned or operated by an entity other than the core network operator.

162 160 160 160 104 162 102 102 102 102 102 102 162 104 a b c a b c a b c The MMEmay be connected to each of the eNode-Bs,, andin the RANvia an S1 interface and may serve as a control node. For example, the MMEmay be responsible for authenticating users of the WTRUs,, and, bearer activation/deactivation, selecting a particular serving gateway during an initial attach of the WTRUs,, and, and the like. The MMEmay also provide a control plane function for switching between the RANand other RANs (not shown) that employ other radio technologies, such as GSM or WCDMA.

164 160 160 160 104 164 102 102 102 164 102 102 102 102 102 102 a b c a b c a b c a b c The serving gatewaymay be connected to each of the eNode-Bs,, andin the RANvia the S1 interface. The serving gatewaymay generally route and forward user data packets to/from the WTRUs,, and. The serving gatewaymay also perform other functions, such as anchoring user planes during inter-eNode B handovers, triggering paging when downlink data is available for the WTRUs,, and, managing and storing contexts of the WTRUs,, and, and the like.

164 166 102 102 102 110 102 102 102 a b c a b c The serving gatewaymay also be connected to the PDN gateway, which may provide the WTRUs,, andwith access to packet-switched networks, such as the Internet, to facilitate communications between the WTRUs,,, and IP-enabled devices.

107 107 102 102 102 108 102 102 102 107 107 108 107 102 102 102 112 a b c a b c a b c The core networkmay facilitate communications with other networks. For example, the core networkmay provide the WTRUs,, andwith access to circuit-switched networks, such as the PSTN, to facilitate communications between the WTRUs,, andand traditional land-line communications devices. For example, the core networkmay include, or may communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the core networkand the PSTN. In addition, the core networkmay provide the WTRUs,, andwith access to the networks, which may include other wired or wireless networks that are owned or operated by other service providers.

52 FIG.D 105 109 105 102 102 117 105 109 199 102 198 199 109 a b c is a system diagram of an example RANand core networkthat may implement methods, systems, and devices of sidelink adaptation protocol for remote UE connectivity, as disclosed herein. The RANmay employ an NR radio technology to communicate with the WTRUsandover the air interface. The RANmay also be in communication with the core network. A Non-3GPP Interworking Function (N3IWF)may employ a non-3GPP radio technology to communicate with the WTRUover the air interface. The N3IWFmay also be in communication with the core network.

105 180 180 105 180 180 102 102 117 109 180 180 180 102 105 105 a b a b a b a b a a The RANmay include gNode-Bsand. It will be appreciated that the RANmay include any number of gNode-Bs. The gNode-Bsandmay each include one or more transceivers for communicating with the WTRUsandover the air interface. When integrated access and backhaul connection are used, the same air interface may be used between the WTRUs and gNode-Bs, which may be the core networkvia one or multiple gNBs. The gNode-Bsandmay implement MIMO, MU-MIMO, or digital beamforming technology. Thus, the gNode-B, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU. It should be appreciated that the RANmay employ of other types of base stations such as an eNode-B. It will also be appreciated the RANmay employ more than one type of base station. For example, the RAN may employ eNode-Bs and gNode-Bs.

199 180 199 180 102 198 180 102 198 c c c c c The N3IWFmay include a non-3GPP Access Point. It will be appreciated that the N3IWFmay include any number of non-3GPP Access Points. The non-3GPP Access Pointmay include one or more transceivers for communicating with the WTRUsover the air interface. The non-3GPP Access Pointmay use the 802.11 protocol to communicate with the WTRUover the air interface.

180 180 180 180 a b a b 52 FIG.D Each of the gNode-Bsandmay be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the uplink or downlink, and the like. As shown in, the gNode-Bsandmay communicate with one another over an Xn interface, for example.

109 109 109 90 52 FIG.D 52 FIG.G The core networkshown inmay be a 5G core network (5GC). The core networkmay offer numerous communication services to customers who are interconnected by the radio access network. The core networkcomprises a number of entities that perform the functionality of the core network. As used herein, the term “core network entity” or “network function” refers to any entity that performs one or more functionalities of a core network. It is understood that such core network entities may be logical entities that are implemented in the form of computer-executable instructions (software) stored in a memory of, and executing on a processor of, an apparatus configured for wireless or network communications or a computer system, such as systemillustrated in.

52 FIG.D 52 FIG.D 109 172 174 176 176 197 190 196 184 199 178 109 a b In the example of, the 5G Core Networkmay include an access and mobility management function (AMF), a Session Management Function (SMF), User Plane Functions (UPFs)and, a User Data Management Function (UDM), an Authentication Server Function (AUSF), a Network Exposure Function (NEF), a Policy Control Function (PCF), a Non-3GPP Interworking Function (N3IWF), a User Data Repository (UDR). While each of the foregoing elements are depicted as part of the 5G core network, it will be appreciated that any one of these elements may be owned or operated by an entity other than the core network operator. It will also be appreciated that a 5G core network may not consist of all of these elements, may consist of additional elements, and may consist of multiple instances of each of these elements.shows that network functions directly connect with one another, however, it should be appreciated that they may communicate via routing agents such as a diameter routing agent or message buses.

52 FIG.D In the example of, connectivity between network functions is achieved via a set of interfaces, or reference points. It will be appreciated that network functions could be modeled, described, or implemented as a set of services that are invoked, or called, by other network functions or services. Invocation of a Network Function service may be achieved via a direct connection between network functions, an exchange of messaging on a message bus, calling a software function, etc.

172 105 172 105 172 172 102 102 102 a b c 52 FIG.D The AMFmay be connected to the RANvia an N2 interface and may serve as a control node. For example, the AMFmay be responsible for registration management, connection management, reachability management, access authentication, access authorization. The AMF may be responsible forwarding user plane tunnel configuration information to the RANvia the N2 interface. The AMFmay receive the user plane tunnel configuration information from the SMF via an N11 interface. The AMFmay generally route and forward NAS packets to/from the WTRUs,, andvia an N1 interface. The N1 interface is not shown in.

174 172 184 176 176 174 174 102 102 102 176 176 172 a b a b c a b The SMFmay be connected to the AMFvia an N11 interface. Similarly the SMF may be connected to the PCFvia an N7 interface, and to the UPFsandvia an N4 interface. The SMFmay serve as a control node. For example, the SMFmay be responsible for Session Management, IP address allocation for the WTRUs,, and, management and configuration of traffic steering rules in the UPFand UPF, and generation of downlink data notifications to the AMF.

176 176 102 102 102 110 102 102 102 176 176 102 102 102 112 176 176 174 176 176 176 a b a b c a b c a b a b c a b a b The UPFand UPFmay provide the WTRUs,, andwith access to a Packet Data Network (PDN), such as the Internet, to facilitate communications between the WTRUs,, andand other devices. The UPFand UPFmay also provide the WTRUs,, andwith access to other types of packet data networks. For example, Other Networksmay be Ethernet Networks or any type of network that exchanges packets of data. The UPFand UPFmay receive traffic steering rules from the SMFvia the N4 interface. The UPFand UPFmay provide access to a packet data network by connecting a packet data network with an N6 interface or by connecting to each other and to other UPFs via an N9 interface. In addition to providing access to packet data networks, the UPFmay be responsible packet routing and forwarding, policy rule enforcement, quality of service handling for user plane traffic, downlink packet buffering.

172 199 102 170 199 105 c The AMFmay also be connected to the N3IWF, for example, via an N2 interface. The N3IWF facilitates a connection between the WTRUand the 5G core network, for example, via radio interface technologies that are not defined by 3GPP. The AMF may interact with the N3IWFin the same, or similar, manner that it interacts with the RAN.

184 174 172 188 184 172 174 184 172 102 102 102 102 102 102 102 102 102 52 FIG.D a b c a b c a b c. The PCFmay be connected to the SMFvia an N7 interface, connected to the AMFvia an N15 interface, and to an Application Function (AF)via an N5 interface. The N15 and N5 interfaces are not shown in. The PCFmay provide policy rules to control plane nodes such as the AMFand SMF, allowing the control plane nodes to enforce these rules. The PCF, may send policies to the AMFfor the WTRUs,, andso that the AMF may deliver the policies to the WTRUs,, andvia an N1 interface. Policies may then be enforced, or applied, at the WTRUs,, and

178 178 184 178 196 178 197 The UDRmay act as a repository for authentication credentials and subscription information. The UDR may connect with network functions, so that network function can add to, read from, and modify the data that is in the repository. For example, the UDRmay connect with the PCFvia an N36 interface. Similarly, the UDRmay connect with the NEFvia an N37 interface, and the UDRmay connect with the UDMvia an N35 interface.

197 178 197 178 197 172 197 174 197 190 178 197 The UDMmay serve as an interface between the UDRand other network functions. The UDMmay authorize network functions to access of the UDR. For example, the UDMmay connect with the AMFvia an N8 interface, the UDMmay connect with the SMFvia an N10 interface. Similarly, the UDMmay connect with the AUSFvia an N13 interface. The UDRand UDMmay be tightly integrated.

190 178 172 The AUSFperforms authentication related operations and connect with the UDMvia an N13 interface and to the AMFvia an N12 interface.

196 109 188 188 109 The NEFexposes capabilities and services in the 5G core networkto Application Functions (AF). Exposure may occur on the N33 API interface. The NEF may connect with an AFvia an N33 interface and it may connect with other network functions in order to expose the capabilities and services of the 5G core network.

188 109 188 196 188 109 109 Application Functionsmay interact with network functions in the 5G Core Network. Interaction between the Application Functionsand network functions may be via a direct interface or may occur via the NEF. The Application Functionsmay be considered part of the 5G Core Networkor may be external to the 5G Core Networkand deployed by enterprises that have a business relationship with the mobile network operator.

Network Slicing is a mechanism that could be used by mobile network operators 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 running across a single RAN. Network slicing enables the operator to create networks customized to provide optimized solutions for different market scenarios which demands diverse requirements, e.g. in the areas of functionality, performance and isolation.

3GPP has designed the 5G core network to support Network Slicing. Network Slicing is a good tool that network operators can use to support the diverse set of 5G use cases (e.g., massive IoT, critical communications, V2X, and enhanced mobile broadband) which demand very diverse and sometimes extreme requirements. Without the use of network slicing techniques, it is likely that the network architecture would not be flexible and scalable enough to efficiently support a wider range of use cases need when each use case has its own specific set of performance, scalability, and availability requirements. Furthermore, introduction of new network services should be made more efficient.

52 FIG.D 102 102 102 172 102 102 102 176 176 174 176 176 174 a b c a b c a b a b Referring again to, in a network slicing scenario, a WTRU,, ormay connect with an AMF, via an N1 interface. The AMF may be logically part of one or more slices. The AMF may coordinate the connection or communication of WTRU,, orwith one or more UPFand, SMF, and other network functions. Each of the UPFsand, SMF, and other network functions may be part of the same slice or different slices. When they are part of different slices, they may be isolated from each other in the sense that they may utilize different computing resources, security credentials, etc.

109 109 109 108 109 109 102 102 102 188 170 102 102 102 112 a b c a b c The core networkmay facilitate communications with other networks. For example, the core networkmay include, or may communicate with, an IP gateway, such as an IP Multimedia Subsystem (IMS) server, that serves as an interface between the 5G core networkand a PSTN. For example, the core networkmay include, or communicate with a short message service (SMS) service center that facilities communication via the short message service. For example, the 5G core networkmay facilitate the exchange of non-IP data packets between the WTRUs,, andand servers or applications functions. In addition, the core networkmay provide the WTRUs,, andwith access to the networks, which may include other wired or wireless networks that are owned or operated by other service providers.

52 FIG.A 52 FIG.C 52 FIG.D 52 FIG.E 52 FIG.A 52 FIG.B 52 FIG.C 52 FIG.D 52 FIG.E The core network entities described herein and illustrated in,,, orare identified by the names given to those entities in certain existing 3GPP specifications, but it is understood that in the future those entities and functionalities may be identified by other names and certain entities or functions may be combined in future specifications published by 3GPP, including future 3GPP NR specifications. Thus, the particular network entities and functionalities described and illustrated in,,,, orare provided by way of example only, and it is understood that the subject matter disclosed and claimed herein may be embodied or implemented in any similar communication system, whether presently defined or defined in the future.

52 FIG.E 111 111 121 124 123 123 131 a b illustrates an example communications systemin which the systems, methods, apparatuses that implement sidelink adaptation protocol for remote UE connectivity, described herein, may be used. Communications systemmay include Wireless Transmit/Receive Units (WTRUs) A, B, C, D, E, F, a base station gNB, a V2X server, and Road Side Units (RSUs)and. In practice, the concepts presented herein may be applied to any number of WTRUs, base station gNBs, V2X networks, or other network elements. One or several or all WTRUs A, B, C, D, E, and F may be out of range of the access network coverage. WTRUs A, B, and C form a V2X group, among which WTRU A is the group lead and WTRUs B and C are group members.

129 121 131 131 125 125 128 131 131 131 131 52 FIG.E 52 FIG.E a b WTRUs A, B, C, D, E, and F may communicate with each other over a Uu interfacevia the gNBif they are within the access network coverage. In the example of, WTRUs B and F are shown within access network coverage. WTRUs A, B, C, D, E, and F may communicate with each other directly via a Sidelink interface (e.g., PC5 or NR PC5) such as interface,, or, whether they are under the access network coverageor out of the access network coverage. For instance, in the example of, WRTU D, which is outside of the access network coverage, communicates with WTRU F, which is inside the coverage.

123 123 133 125 124 127 128 a b b WTRUs A, B, C, D, E, and F may communicate with RSUorvia a Vehicle-to-Network (V2N)or Sidelink interface. WTRUs A, B, C, D, E, and F may communicate to a V2X Servervia a Vehicle-to-Infrastructure (V2I) interface. WTRUs A, B, C, D, E, and F may communicate to another UE via a Vehicle-to-Person (V2P) interface.

52 FIG.F 52 FIG.A 52 FIG.B 52 FIG.C 52 FIG.D 52 FIG.E 5 FIG. 50 FIG. 52 FIG.F 52 FIG.F 102 102 201 202 203 204 206 207 208 209 210 211 102 118 120 122 124 126 128 130 132 134 136 138 102 114 114 114 114 a b a b is a block diagram of an example apparatus or device WTRUthat may be configured for wireless communications and operations in accordance with the systems, methods, and apparatuses that implement sidelink adaptation protocol for remote UE connectivity, described herein, such as a WT RUof,,,, or, or-(e.g., remote UE, relay UE, UE-to-NW relay, base station, AMF, SMF, relay UE, remote UE, UPF, or relay UE). As shown in, the example WTRUmay include a processor, a transceiver, a transmit/receive element, a speaker/microphone, a keypad, a display/touchpad/indicators, non-removable memory, removable memory, a power source, a global positioning system (GPS) chipset, and other peripherals. It will be appreciated that the WTRUmay include any sub-combination of the foregoing elements. Also, the base stationsand, or the nodes that base stationsandmay represent, such as but not limited to transceiver station (BTS), a Node-B, a site controller, an access point (AP), a home node-B, an evolved home node-B (eNodeB), a home evolved node-B (HeNB), a home evolved node-B gateway, a next generation node-B (gNode-B), and proxy nodes, among others, may include some or all of the elements depicted inand may be an exemplary implementation that performs the disclosed systems and methods for sidelink adaptation protocol for remote UE connectivity described herein.

118 118 102 118 120 122 118 120 118 120 52 FIG.F The processormay be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processormay perform signal coding, data processing, power control, input/output processing, or any other functionality that enables the WTRUto operate in a wireless environment. The processormay be coupled to the transceiver, which may be coupled to the transmit/receive element. Whiledepicts the processorand the transceiveras separate components, it will be appreciated that the processorand the transceivermay be integrated together in an electronic package or chip.

122 114 115 116 117 115 116 117 122 122 122 122 a d d d 52 FIG.A The transmit/receive elementof a UE may be configured to transmit signals to, or receive signals from, a base station (e.g., the base stationof) over the air interface//or another UE over the air interface//. For example, the transmit/receive elementmay be an antenna configured to transmit or receive RF signals. The transmit/receive elementmay be an emitter/detector configured to transmit or receive IR, UV, or visible light signals, for example. The transmit/receive elementmay be configured to transmit and receive both RF and light signals. It will be appreciated that the transmit/receive elementmay be configured to transmit or receive any combination of wireless or wired signals.

122 102 122 102 102 122 115 116 117 52 FIG.F In addition, although the transmit/receive elementis depicted inas a single element, the WTRUmay include any number of transmit/receive elements. More specifically, the WTRUmay employ MIMO technology. Thus, the WTRUmay include two or more transmit/receive elements(e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface//.

120 122 122 102 120 102 The transceivermay be configured to modulate the signals that are to be transmitted by the transmit/receive elementand to demodulate the signals that are received by the transmit/receive element. As noted above, the WTRUmay have multi-mode capabilities. Thus, the transceivermay include multiple transceivers for enabling the WTRUto communicate via multiple RATs, for example NR and IEEE 802.11 or NR and E-UTRA, or to communicate with the same RAT via multiple beams to different RRHs, TRPs, RSUs, or nodes.

118 102 124 126 128 118 124 126 128 118 130 132 130 132 118 102 118 128 128 124 126 128 128 5 FIG. 50 FIG. The processorof the WTRUmay be coupled to, and may receive user input data from, the speaker/microphone, the keypad, or the display/touchpad/indicators(e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit. The processormay also output user data to the speaker/microphone, the keypad, or the display/touchpad/indicators. In addition, the processormay access information from, and store data in, any type of suitable memory, such as the non-removable memoryor the removable memory. The non-removable memorymay include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memorymay include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. The processormay access information from, and store data in, memory that is not physically located on the WTRU, such as on a server that is hosted in the cloud or in an edge computing platform or in a home computer (not shown). The processormay be configured to control lighting patterns, images, or colors on the display or indicatorsin response to whether the setup of the sidelink adaptation protocol for remote UE connectivity in some of the examples described herein are successful or unsuccessful, or otherwise indicate a status of sidelink adaptation protocol for remote UE connectivity and associated components. The control lighting patterns, images, or colors on the display or indicatorsmay be reflective of the status of any of the method flows or components in the FIG.'s illustrated or discussed herein (e.g.,-, etc.). Disclosed herein are messages and procedures of sidelink adaptation protocol for remote UE connectivity. The messages and procedures may be extended to provide interface/API for users to request resources via an input source (e.g., speaker/microphone, keypad, or display/touchpad/indicators) and request, configure, or query sidelink adaptation protocol for remote UE connectivity related information, among other things that may be displayed on display.

118 134 102 134 102 134 The processormay receive power from the power sourceand may be configured to distribute or control the power to the other components in the WTRU. The power sourcemay be any suitable device for powering the WTRU. For example, the power sourcemay include one or more dry cell batteries, solar cells, fuel cells, and the like.

118 136 102 136 102 115 116 117 114 114 102 a b The processormay also be coupled to the GPS chipset, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU. In addition to, or in lieu of, the information from the GPS chipset, the WTRUmay receive location information over the air interface//from a base station (e.g., base stations,) or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRUmay acquire location information by way of any suitable location-determination method.

118 138 138 The processormay further be coupled to other peripherals, which may include one or more software or hardware modules that provide additional features, functionality, or wired or wireless connectivity. For example, the peripheralsmay include various sensors such as an accelerometer, biometrics (e.g., finger print) sensors, an e-compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port or other interconnect interfaces, a vibration device, a television transceiver, a hands free headset, a Bluetooth© module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like.

102 102 138 The WTRUmay be included in other apparatuses or devices, such as a sensor, consumer electronics, a wearable device such as a smart watch or smart clothing, a medical or eHealth device, a robot, industrial equipment, a drone, a vehicle such as a car, truck, train, or an airplane. The WTRUmay connect with other components, modules, or systems of such apparatuses or devices via one or more interconnect interfaces, such as an interconnect interface that may comprise one of the peripherals.

52 FIG.G 52 FIG.A 52 FIG.C 52 FIG.D 52 FIG.E 5 FIG. 50 FIG. 90 103 104 105 106 107 109 108 110 112 113 90 91 90 91 91 90 81 91 91 91 81 is a block diagram of an exemplary computing systemin which one or more apparatuses of the communications networks illustrated in,,andas well as sidelink adaptation protocol for remote UE connectivity, such as the systems and methods illustrated inthroughdescribed and claimed herein may be embodied, such as certain nodes or functional entities in the RAN//, Core Network//, PSTN, Internet, Other Networks, or Network Services. Computing systemmay comprise a computer or server and may be controlled primarily by computer readable instructions, which may be in the form of software, wherever, or by whatever means such software is stored or accessed. Such computer readable instructions may be executed within a processor, to cause computing systemto do work. The processormay be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processormay perform signal coding, data processing, power control, input/output processing, or any other functionality that enables the computing systemto operate in a communications network. Coprocessoris an optional processor, distinct from main processor, that may perform additional functions or assist processor. Processoror coprocessormay receive, generate, and process data related to the methods and apparatuses disclosed herein for sidelink adaptation protocol for remote UE connectivity, such as receiving messages.

91 80 90 80 80 In operation, processorfetches, decodes, and executes instructions, and transfers information to and from other resources via the computing system's main data-transfer path, system bus. Such a system bus connects the components in computing systemand defines the medium for data exchange. System bustypically includes data lines for sending data, address lines for sending addresses, and control lines for sending interrupts and for operating the system bus. An example of such a system busis the PCI (Peripheral Component Interconnect) bus.

80 82 93 93 82 91 82 93 92 92 92 Memories coupled to system businclude random access memory (RAM)and read only memory (ROM). Such memories include circuitry that allows information to be stored and retrieved. ROMsgenerally include stored data that cannot easily be modified. Data stored in RAMmay be read or changed by processoror other hardware devices. Access to RAMor ROMmay be controlled by memory controller. Memory controllermay provide an address translation function that translates virtual addresses into physical addresses as instructions are executed. Memory controllermay also provide a memory protection function that isolates processes within the system and isolates system processes from user processes. Thus, a program running in a first mode may access only memory mapped by its own process virtual address space; it cannot access memory within another process's virtual address space unless memory sharing between the processes has been set up.

90 83 91 94 84 95 85 In addition, computing systemmay include peripherals controllerresponsible for communicating instructions from processorto peripherals, such as printer, keyboard, mouse, and disk drive.

86 96 90 86 96 86 Display, which is controlled by display controller, is used to display visual output generated by computing system. Such visual output may include text, graphics, animated graphics, and video. The visual output may be provided in the form of a graphical user interface (GUI). Displaymay be implemented with a CRT-based video display, an LCD-based flat-panel display, gas plasma-based flat-panel display, or a touch-panel. Display controllerincludes electronic components required to generate a video signal that is sent to display.

90 97 90 103 104 105 106 107 109 108 110 102 112 90 91 52 FIG.A 52 FIG.B 52 FIG.C 52 FIG.D 52 FIG.E Further, computing systemmay include communication circuitry, such as for example a wireless or wired network adapter, that may be used to connect computing systemto an external communications network or devices, such as the RAN//, Core Network//, PSTN, Internet, WTRUs, or Other Networksof,,,, or, to enable the computing systemto communicate with other nodes or functional entities of those networks. The communication circuitry, alone or in combination with the processor, may be used to perform the transmitting and receiving steps of certain apparatuses, nodes, or functional entities described herein.

118 91 It is 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 instructions, when executed by a processor, such as processorsor, 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, executing on the processor of an apparatus or computing system configured for wireless or wired network communications. Computer readable storage media includes volatile and nonvolatile, removable and non-removable media implemented in any non-transitory (e.g., tangible or physical) method or technology for storage of 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 technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other tangible or physical medium which may be used to store the desired information and which may be accessed by a computing system.

In describing preferred methods, systems, or apparatuses of the subject matter of the present disclosure—sidelink adaptation protocol for remote UE connectivity—as illustrated in the Figures, specific terminology is employed for the sake of clarity. The claimed subject matter, however, is not intended to be limited to the specific terminology so selected.

The various techniques described herein may be implemented in connection with hardware, firmware, software, or where appropriate, combinations thereof. Such hardware, firmware, and software may reside in apparatuses located at various nodes of a communication network. The apparatuses may operate singly or in combination with each other to effectuate the methods described herein. As used herein, the terms “apparatus,” “network apparatus,” “node,” “device,” “network node,” or the like may be used interchangeably. In addition, the use of the word “or” is generally used inclusively unless otherwise provided herein.

This written description uses examples for the disclosed subject matter, including the best mode, and also to enable any person skilled in the art to practice the disclosed subject matter, including making and using any devices or systems and performing any incorporated methods. The disclosed subject matter (e.g., option 1 and option 2) may include other examples that occur to those skilled in the art (e.g., skipping steps, combining steps, or adding steps between exemplary methods disclosed herein).

Methods, systems, and apparatuses, among other things, as described herein may provide for controlling (e.g., using) intra-device packet routing data link layer (DLL) protocol (RaLTP) for packet routing to data link upper layer protocols based on a RaLTP DLL routing entries; controlling inter-device packet routing DLL protocol (RaLAP) for packet routing between the first device and a second device based on a RaLAP DLL routing entries; controlling Quality of Service of packet transfer function based on RaLAP or RaLTP DLL QoS entries; performing inter-device packet routing actions on a packet based on a first RaLAP address or RaLAP path identity or a first RaLTP identity; performing intra-device packet routing actions on a packet based on a first RaLAP address or first RaLTP identity; or performing Quality of Service actions for a packet transfer based a first RaLAP address and first RaLTP identity, or an upper layer protocol identity. Methods, systems, and apparatuses, among other things, as described herein may provide for receiving from a third device, information indicating parameters. All combinations in this paragraph and the following paragraph (including the removal or addition of steps) are contemplated in a manner that is consistent with the other portions of the detailed description.

Methods, systems, and apparatuses, among other things, as described herein may provide for using relay link tunneling protocol (RaLTP) for packet routing to datalink upper layer protocols based on RaLTP data link layer (DLL) routing entries, wherein RaLTP is located in DLL and functions to perform intra-device packet routing; and performing intra-device packet routing actions on a packet based on a first relay link adaptation protocol (RaLAP) address or first RaLTP identity. Methods, systems, and apparatuses, among other things, as described herein may provide for using relay link adaptation protocol (RaLAP) for packet routing between a first device and a second device based on a RaLAP data link layer (DLL) routing entries, wherein the RaLAP is located in the DLL and functions to perform inter-device packet routing; and performing inter-device packet routing actions on a packet based on a first RaLAP address or RaLAP path identity, and a first Relay Link Tunneling Protocol (RaLTP) identity. RaLAP—located in DLL and functions to perform inter-device packet routing. RaLTP—located in DLL and functions to perform intra-device packet routing. Methods, systems, and apparatuses, among other things, as described herein may provide for using Quality of Service of packet transfer function based on RaLAP or Relay Link Tunneling Protocol (RaLTP) DLL QoS entries and performing Quality of Service actions for a packet transfer based on a first RaLAP address or first RaLTP identity, and an upper layer protocol identity. All combinations in this paragraph and the below (including the removal or addition of steps) are contemplated in a manner that is consistent with the other portions of the detailed description.

Methods, systems, and apparatuses, among other things, as described herein may provide for using relay link tunneling protocol (RaLTP) for packet routing to data link upper layer protocols based on RaLTP data link layer (DLL) routing entries, wherein RaLTP is located in DLL and functions to perform intra-device packet routing; and performing intra-device packet routing actions on a packet based on a first relay link adaptation protocol (RaLAP) address or first RaLTP identity. Methods, systems, and apparatuses, among other things, as described herein may provide for using inter-device packet routing DLL protocol (RaLAP) for packet routing between the first device and a second device based on a RaLAP DLL routing entries; and performing inter-device packet routing actions on a packet based on a first RaLAP address or RaLAP path identity, and a first Relay Link Tunneling Protocol (RaLTP) identity. Methods, systems, and apparatuses, among other things, as described herein may provide for using Quality of Service of packet transfer function based on RaLAP and Relay Link Tunneling Protocol (RaLTP) DLL QoS entries; and performing Quality of Service actions for a packet transfer based on a first RaLAP address or first RaLTP identity, and an upper layer protocol identity. Methods, systems, and apparatuses, among other things, as described herein may provide for receiving first information, second information, or second information. First information indicating one or more first parameters for controlling intra-device packet routing, controlling inter-device packet routing, or controlling QoS for transfer of a packet from upper layer protocol above RaLAP and RaLTP to next hop, wherein the one or more first parameters comprise upper layer protocol IDentity (ID), RaLAP routing ID that includes RaLAP address and RaLAP path ID, translated RaLAP ID that includes a translated RaLAP address and a translated RaLAP path ID, RaLTP ID, translated RaLTP ID, next hop RaLAP address, egress link ID, or egress RLC Channel ID. Second information indicating one or more second parameters for controlling intra-device packet routing, controlling inter-device packet routing, or controlling QoS for transfer of a packet from ingress link RaLAP and RaLTP to next hop, wherein the one or more second parameters comprise RaLAP ID that includes RaLAP address and RaLAP path identity, translated RaLAP ID that includes a translated RaLAP address and a translated RaLAP path identity, RaLTP ID, translated RaLTP ID, next hop RaLAP address, ingress link ID, ingress RLC Channel ID, egress link ID, or egress RLC Channel ID. Third information indicating one or more third parameters for controlling intra-device packet routing, controlling inter-device packet routing of a packet from ingress link RaLAP and RaLTP to upper layer protocol or local link, wherein the one or more third parameters comprise RaLAP address and RaLAP path ID, RaLTP ID, or Upper layer protocol ID. All combinations in this paragraph and below (including the removal or addition of steps) are contemplated in a manner that is consistent with the other portions of the detailed description.

The one or more first parameters, the one or more second parameters, or the one or more third parameters are preconfigured or specified by standards. The first RaLTP identity is an identity of a bearer, an identity of a tunnel associated with a bearer, an identity of a tunnel associated with an upper layer protocol above the intra-device routing DLL protocol, or an identity 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. The performing intra-device packet routing actions may include: selecting from the plurality of entries for control of inter-device packet routing, control of intra-device packet routing, or control of QoS for transfer of a packet from upper layer protocol above RaLAP and RaLTP to next hop, the entry with its upper layer protocol identity corresponds to the upper layer protocol identity of this packet; selecting the RaLTP identity in the entry selected above as the first RaLTP entity; or including the first RaLTP identity into the Tunnel End Point ID (TEID) field of this packet header. The performing inter-device packet routing actions may include: selecting from the plurality of entries for control of inter-device packet routing, control of intra-device packet routing, or control of QoS for transfer of a packet from upper layer protocol above RaLAP and RaLTP to next hop, the entry with its upper layer protocol identity corresponds to the upper layer protocol identity of this packet; selecting the RaLAP address from the routing identity in the entry selected above as the first RaLAP address; selecting the path identity from the routing identity in the entry selected above if the path identity is available; or including into the destination field of this packet header the first RaLAP address and if available the path identity. All combinations in this paragraph and below (including the removal or addition of steps) are contemplated in a manner that is consistent with the other portions of the detailed description.

The performing Quality of Service actions comprise selecting from the plurality of entries for control of inter-device packet routing, control of intra-device packet routing, or control of QoS for transfer of a packet from upper layer protocol above RaLAP and RaLTP to next hop, the entry with its upper layer protocol identity corresponds to the upper layer protocol identity of this packet; selecting the egress link ID and the egress RLC channel ID in the entry selected above; or submitting the packet to the RLC entity that corresponds to the selected egress link ID and the selected egress RLC channel ID. The performing inter-device packet routing actions comprise determining the first RaLTP identity as the identity in the Tunnel End point ID (TEID) field of this packet header; determining the first RaLAP address and the RaLAP path identity as the address and path identity in the destination field of this packet header; selecting from the plurality of entries for control of inter-device packet routing, control of intra-device packet routing, or control of QoS for transfer of a packet from ingress link RaLAP and RaLTP to next hop, the entry with its RaLAP address corresponds to the first RaLAP address, and whose egress link corresponding to the Next hop RaLAP address is available and its RaLTP identity corresponds to the first RaLTP identity; selecting the egress link corresponding to the next hop RaLAP address in the entry selected above; selecting the translated RaLAP address in the selected entry as the first RaLAP address if RaLAP address translation applies, and including the first RaLAP address into the destination field of this packet header; or selecting the translated RaLTP identity in the selected entry as the first RaLTP identity if RALTP identity translation applies, and including the first RaLTP identity into the TEID field of this packet header. All combinations in this paragraph and below (including the removal or addition of steps) are contemplated in a manner that is consistent with the other portions of the detailed description.

The performing Quality of Service actions comprise: selecting from the plurality of entries for control of inter-device packet routing, control of intra-device packet routing, or control of QoS for transfer of a packet from upper layer protocol above RaLAP and RaLTP to next hop, the entry with its upper layer protocol identity corresponds to the upper layer protocol identity of this packet; selecting the egress link ID and the egress RLC channel ID in the entry selected above; or submitting the packet to the RLC entity that corresponds to the selected egress link ID and the selected egress RLC channel ID. The performing inter-device packet routing actions comprise determining the first RaLTP identity as the identity in the Tunnel End point ID (TEID) field of this packet header; determining the first RaLAP address and the RaLAP path identity as the address and path identity in the destination field of this packet header; selecting from the plurality of entries for control of inter-device packet routing, control of intra-device packet routing, or control of QoS for transfer of a packet from ingress link RaLAP and RaLTP to next hop, the entry with its RaLAP address corresponds to the first RaLAP address, and whose egress link corresponding to the Next hop RaLAP address is available and its RaLTP identity corresponds to the first RaLTP identity; selecting the egress link corresponding to the next hop RaLAP address in the entry selected above; selecting the translated RaLAP address in the selected entry as the first RaLAP address if RaLAP address translation applies, and including the first RaLAP address into the destination field of this packet header; or selecting the translated RaLTP identity in the selected entry as the first RaLTP identity if RALTP identity translation applies, and including the first RaLTP identity into the TEID field of this packet header. The performing Quality of Service actions comprise: selecting from the plurality of entries for control of inter-device packet routing, control of intra-device packet routing or control of QoS for transfer of a packet from ingress link RaLAP and RaLTP to next hop, the entry with its ingress link ID corresponds to this packet ingress link, its ingress RLC channel ID correspond to this packet ingress RLC channel, its egress link ID corresponds to selected egress link; selecting the egress RLC channel corresponding to the egress RLC channel ID of the selected entry above; or submitting this packet to the RLC entity that corresponds to the selected egress link ID and the selected RLC channel ID. All combinations in this paragraph and below (including the removal or addition of steps) are contemplated in a manner that is consistent with the other portions of the detailed description.

The performing intra-device packet routing actions comprise: determining the first RaLTP identity as the identity in the Tunnel End point ID (TEID) field of this packet header; determining the first RaLAP address and the RaLAP path identity as the address and path identity in the destination field of this packet header; selecting from the plurality of entries for control of inter-device packet routing, control of intra-device packet routing, or control of QoS for transfer of a packet from ingress link RaLAP and RaLTP to upper layer or local link, the entry with its RaLAP address corresponds to the first RaLAP address, and its RaLTP identity corresponds to the first RaLTP identity; selecting the upper layer protocol identity in the selected entry; removing the RaLAP and RaLTP headers from the packet; or submitted the packet without the RaLAP header and without RaLTP header to the upper layer protocol that corresponds to the selected upper layer protocol identity. The first device and the second device exchange: end-to-end keep-alive messages, end-to-end radio link failure (RLF) indication message, or end-to-end flow control message. The first device and the second device are connected through one or more PC5 interface links. The first device and an another device exchange: hop-by-hop keep-alive message, with the another device being on the communication path between the first device and the second device; hop-by-hop RLF indication, with the another device being on the communication path between the first device and the second device; or hop-by-hop flow control message, with the another device being on the communication path between the first device and the second device. Selecting the first entry egress link when available corresponding to the next hop RaLAP address in the first entry. Including into a destination field of the second packet header the first RaLAP address if not already included, and including into a path field of the second packet header, the first path identity when available and not already included. The first entry egress link corresponds to a selected egress link. Submitting the third packet to an RLC entity that corresponds to the egress link ID and the egress RLC channel ID. The first entry egress link corresponds to a selected egress link. The address in the destination field of the second packet header, and the first path identity as the path identity in the path field of the second packet header. The first path identity as the path identity in the path field of the first packet header. Selecting a first entry from a plurality of entries for control of inter-device packet routing, control of intra-device packet routing, or control of QoS from ingress link RaLAP and RaLTP to upper layer or local link, the first entry RaLAP address corresponds to the first RaLAP address, and first entry RaLTP identity corresponds to the first path identity. All combinations in this paragraph and the above paragraphs (including the removal or addition of steps) are contemplated in a manner that is consistent with the other portions of the detailed description.