WO2021236894A1

WO2021236894A1 - Sidelink relay connectivity management

Info

Publication number: WO2021236894A1
Application number: PCT/US2021/033337
Authority: WO
Inventors: Zhuo Chen; Pascal Adjakple; Michael Starsinic; Rocco Di Girolamo; Joseph Murray; Hongkun Li; Yifan Li; Kyle Pan; Mohamed M. AWANDIN; Allan Tsai; Guodong Zhang
Original assignee: Convida Wireless, Llc
Priority date: 2020-05-20
Filing date: 2021-05-20
Publication date: 2021-11-25

Abstract

Multi-hop RRC connections between a UE and a gNB may be enabled by a Relay Adaptation Protocol (RAP) layer and/or multi-hop RRC states for a UE. For example, a UE may determine to use an indirect network connection path, rather than a direct network connection path, for communications with a base station (gNB), rather to the gNB, and discover one or more candidate relay User Equipments (UEs), then select and establish a PCS connection to a relay UE. The UE may then; establish an RRC) connection to the gNB via the indirect path and maintain the first RRC connection to fulfill a QoS requirement of an existing traffic flow and/or a new traffic flow of the UE. The UE may receive an RRC setup message from the gNB via the PCS connection and configure an Access Stratum context of the UE accordingly.

Description

SIDELINK RELAY CONNECTIVITY MANAGEMENT

BACKGROUND

[0001] This disclosure pertains wireless machine-to-machine networks such as, but not limited to, those described in: 3 GPP TR 36.746 V15.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); RP-193118 New SID: Study on NR sidelink relay; 3GPP TR 22.804 VI 6.2.0 Study on Communication for Automation in Vertical Domains (Release 16); and 3 GPP TS 22.261 VI 7.1.0 Service requirements for the 5G system; Stage 1 (Release 17).

SUMMARY

[0002] Multi-hop RRC connections between a UE and a gNB may be enabled by a Relay Adaptation Protocol (RAP) layer and/or new multi-hop RRC states for a UE.

[0003] New functions for Relay Adaptation Protocol (RAP) Layer may be used, and new fields are introduced into the RAP header. For the RAP layer, a RAP routing ID management function may be used in the adaptation layer of an access relay UE, which enables the adaptation layer of the access relay UE to generate a unique routing ID for each SL RLC Channel of its child remote UE.

[0004] Further, for the RAP layer, a re-directing function to support service continuity may be used, whereby the RAP of a relay UE replaces the “original routing ID” in the RAP header associated with the original connection with a “new routing ID” in the RAP header associated with the new connection. The QoS context that associates with a routing ID may be used to be pre-configured or carried in the RAP header in the message to enable the new connection to fulfill the same or higher QoS requirement of the original connection. A new identifier that identifies the originator of a packet may be used to be added into the RAP header, which allows the relay UE in the middle to re-direct the packet to an alternative connection.

[0005] New Multi-hop RRC states for a UE, such as M-RRC connected and M-RRC idle. Sixth types of procedures may be used for a UE to transit between these states.

[0006] First is synchronization and local discovery procedures for a UE to acquire system information, and discovery of the serving gNB and one or more candidate paths to the gNB. [0007] Second is relay (re)selection and path (re)selection methods may be used for a UE to select one or more candidate paths to fulfil the QoS and service continuity requirement of the traffic.

[0008] Third is creating one or more multi-hop RRC (M-RRC) connections to the gNB including creating multi-hop Signalling Radio Bearers (M-SRB) and multi-hop Data Radio Bearers (M-DRB) to the gNB.

[0009] Fourth, the gNB or a UE may modify a connection to fulfill the QoS requirement of a traffic flow including service continuity requirement.

[0010] Fifth, are methods to release one or more multiple hop RRC connections between a UE and the gNB.

[0011] Sixth, are methods for a UE to re-establish multi-hop RRC connection to the gNB.

[0012] A UE may manage multi-hop connections to a gNB in at least four ways.

[0013] First a state machine in the RRC layer may be used to support multiple hop connection management. For example, new multi-hop RRC states, e.g., M-RRC connected and M-RRC idle, may be used in procedures for a UE to transit between these states.

[0014] Second, to manage multi-hop connections, a UE may acquire system information, select the serving gNB, and discover one or more candidate paths to the gNB. The UE sends a relay discovery request message which contains the relay and path selection criteria to one or more neighbour UEs. The UE receive relay discovery response messages and relay advertainment request messages which contain relay and path selection context information. The UE then selects neighbor relay UEs, a connection, or a path based on relay and path selection criteria. The criteria may include, e.g., PLMN and gNB ID, M-RRC connection state, QoS requirement of the traffic, number of hops towards the gNB.

[0015] Third to manage multi-hop connections, a UE may establish a multi-hop RRC connection along the selected connections paths and relay UEs. Here, the UE sends a multi-hop RRC connection request to the selected relay UE towards the gNB along the selected path or connection, where the request also contains information about whether it has an adaptation layer. The UE receives a multi-hop RRC setup message to configure its AS context to establish a new connection. The message contains the configuration of its adaptation layer address, RLC channel mapping between the access relay UE. The UE then sends a multi-hop RRC setup complete message towards the gNB using the newly created connection.

[0016] Fourth, to manage multi-hop connections, a UE may maintain the connection between a UE and gNB to fulfill the QoS of existing traffic flows and new traffic flows. The may be achieved by the UE sending a UE relay context report message to the gNB periodically, after receiving a UE relay context request message from the gNB, after setting up a connection with the gNB or when its UE relay context information changed. The UE may send all its UE relay context information or the context information that has been changed since the last reporting.

[0017] The UE then receives a M-RRC reconfiguration message including M-SRB and M-DRB AS context configurations. A configuration may include a QFI to M-DRB(s) mapping rule, for example, wherein the mapping rules contains the priority of M-DRBs. A configuration may include an adaptation layer configuration for the new M-SRB and M-DRBs including at least routing ID and RLC channel mapping configuration, the priority of each connection within a M-DRB.

[0018] The UE then sending an M-RRC Reconfiguration Complete message to the gNB to confirm the new M-SRB and M-DRB AS context configurations, and receives a connection modification notification which includes the routing ID associated with the connection that cannot meet the QoS requirement including service continuity, and then using another M-DRB or connection for the traffic flow.

[0019] Fifth, to manage multi-hop connections, a UE may receive a M-RRC release message from the gNB to release one or more RRC connection via removing M-SRB and M- DRB AS context configurations including the connection ID and RLC channel mapping configuration associated with the connection, but keeping the routing information to the gNB including adaptation layer address of itself, access relay UE, and gNB.

[0020] An access relay UE may assist its child UEs to manage at least one multi-hop connection to the gNB in at least four ways.

[0021] First, the access relay UE may use an adaptation layer that adds RAP headers for packets from its child remote UEs, manages the routing ID of its child remote UEs, determines whether a packet is destinated to its child remote UEs. The adaptation layer may use an alterative connection to forward a packet to the destination when the original connection cannot fulfill the QoS requirement of the traffic by replacing the original routing ID in the RAP header with the routing ID of a new connection and keeping the original route ID in the RAP head in separated fields, and indicating the connection is changed.

[0022] Second, an access relay UE may assist its child UEs: in acquiring system information, in selecting the serving gNB, and in discovering one or more candidate paths to the gNB. The access relay UE may receive relay discovery request messages from its neighbour UEs. These request messages may contain relay and path selection criteria. The access relay UE may send relay discovery response messages and relay advertisement request messages to its neighbor UEs. These messages containing relay and path selection context information.

[0023] Third, an access relay UE may assist its child UEs establish a multi-hop RRC connection along selected connections and paths. This may be achieved by forwarding the multi-hop RRC connection request from its child UEs to the gNB by. Here, the access relay UE generates an RRC message to encapsulate the message, which includes its own UE ID; adding an adaptation layer header to the RRC message including a routing ID that contains the gNB’s adaptation layer address and the connection ID to the gNB; sending the RRC message via its SRB. The access relay UE may generate an RRC message to encapsulate the message, which includes its own UE ID, adding an adaptation layer header to the RRC message including a routing ID that contains the gNB’s adaptation layer address as the destination. The access relay UE adds an adaptation layer header to the message including a routing ID that contains the gNB’s adaptation layer address as the destination.

[0024] An access relay UE may also assist its child UEs in establishing a multi-hop RRC connection along selected connections and paths by forwarding the multi-hop RRC connection setup message from the gNB to its child UEs. This may be achieved by receiving an RRC message from the gNB which includes a multi-hop RRC connection setup message to its child UE and adaptation layer configuration information, and then removing the header of adaptation layer and extracts the RRC connection setup message to its child UE.

[0025] Fourth, an access relay UE may assist its child UEs by assisting its Child UEs in maintaining the connection to the gNB to fulfill the QoS of existing and new traffic flows.

The access relay UE detects a connection cannot fulfill the QoS of the traffic flow when forwarding a packet along the connection, and sends a connection modification notification message to the end node of the connection, e.g., the gNB, relay UEs and remote UEs, notifying the connection cannot fulfill the QoS requirement of the flow, wherein the message contains the routing ID associated with the connection. The access relay UE then forwards the packet to the destination using an alternative connection by replacing the original routing ID in the RAP header using the routing ID of a new connection and keeping the original route ID in the RAP head as separated fields, and indicating the connection is changed due to a link failure.

[0026] A gNB may be adapted to manage multi-hop connections to a UE in how the gNB establishes, maintains, and releases connections.

[0027] To establish a multi-hop RRC connection along selected connections, paths, and relay UEs, the receives a multi-hop RRC connection request from a UE wherein the request may contain information about whether the UE has an adaptation layer. The gNB then generates a RAP routing ID for the new connection and configuring the adaptation layer of each relay UEs on the path. Next the gNB sends a multi-hop RRC setup message to the UE which contains AS context to establish a new connection including the UE’s adaptation layer address and RLC channel mapping between the access relay UE. Then the gNB receives a multi-hop RRC setup complete message from the UE.

[0028] To maintain the connection between a UE and gNB to fulfill the QoS of existing and new traffic flows, the gNB receives a UE relay context report message from a UE. The gNB may select a path for each M-SRB and M-DRB and assigning a new connection ID associated with each new M-SRB and M-DRB and send RAP Reconfiguration request to all relay UEs on the paths. The gNB may also send a M-RRC reconfiguration message to a UE including new M- SRB and M-DRB AS context configurations including anew QFI to M-DRB(s) mapping rule, wherein the mapping rules contain the priority of M-DRBs, and/or an adaptation layer configuration for the new M-SRB and M-DRBs including at least routing ID and RLC channel mapping configuration, the priority of each connection within a M-DRB.

[0029] The gNB may then receive an M-RRC Reconfiguration Complete message from a UE to confirm the new M-SRB and M-DRB AS context configurations, and receive a connection modification notification which includes the routing ID associated with the connection that cannot meet the QoS requirement including service continuity, and then use another M-DRB or connection for the traffic flow.

[0030] To release a connection, the gNB may send an M-RRC release message to a UE to release one or more RRC connection via removing M-SRB and M-DRB AS context configurations including the connection ID and RLC channel mapping configuration associated with the connection, but keeping the routing information to the gNB including adaptation layer address of itself, access relay UE, and gNB.

[0031] 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 limited to limitations that solve any or all disadvantages noted in any part of this disclosure.

BRIEF DESCRIPTION OF THE DRAWINGS

[0032] A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings.

[0033] Figure 1 is a block diagram illustrating an example user plane radio protocol stack for a layer 2 evolved UE-to-N etwork relay (PCS).

[0034] Figure 2 is a block diagram illustrating an example control plane radio protocol stack for a layer 2 evolved UE-to-N etwork relay (PCS).

[0035] Figure 3 is a block diagram illustrating an example of UE to NW traffic in a massive wireless sensor network.

[0036] Figure 4 is a block diagram illustrating an example of UE to UE traffic in a control-to-control communication in Industrial IoT.

[0037] Figure 5 is a block diagram illustrating an example of RRC or data connection between each UE/relay UE and gNB.

[0038] Figure 6 is a block diagram illustrating an example control plane between a remote UE and the gNB.

[0039] Figure 7 is a block diagram illustrating an example control plane between a relay UE and the gNB.

[0040] Figure 8 is a block diagram illustrating an example user plane between a remote UE and the gNB.

[0041] Figure 9 is a block diagram illustrating an example user plane between a relay UE and the gNB. [0042] Figure 10 is a block diagram illustrating an example DL L2-structure for user plane at gNB.

[0043] Figure 11 is a block diagram illustrating an example DL L2-structure for user plane at a relay UE.

[0044] Figure 12 is a block diagram illustrating an example UL L2-structure for user plane at relay UE.

[0045] Figure 13 is an example M-RRC connection management state transition diagram.

[0046] Figure 14 is a flow chart of an example M-RRC connection management state transition.

[0047] Figure 15 is a call flow diagram of an example of remote UE initiated synchronization and local discovery.

[0048] Figure 16 is a call flow diagram of an example of relay UE initiated synchronization and local discovery.

[0049] Figure 17 is a flow chart of an example relay (re)selection and path (re) selection procedure.

[0050] Figures 18A-C show a call flow of an example initial connection between a remote UE and the network when the access relay has a connection to the network.

[0051] Figures 19A-C show a call flow of an example initial connection between a UE- to-UE relay and the network when the access relay has a connection to the network.

[0052] Figures 20A-C show a call flow of an example initial connection between a remote UE and the network when the access relay has a route to the network.

[0053] Figures 21A-C show a call flow of an example initial connection between a UE- to-UE relay and the network when the access relay has a route to the network.

[0054] Figure 22 is a call flow of an example method for a gNB to obtain relay context information of all UEs in the network.

[0055] Figure 23 is a call flow of an example procedure for creation new M-SRBs and M-DRBs to a remote UE initiated by the gNB.

[0056] Figure 24 is a call flow of an example procedure for creation new M-SRBs and M-DRBs to a relay UE initiated by the gNB. [0057] Figure 25 is a call flow of an example procedure for creation new M-DRBs for DL data with new QoS flow ID for a remote UE.

[0058] Figure 26 is a call flow of an example procedure for creation of new M-DRBs for DL data with new QoS flow ID for a relay UE.

[0059] Figure 27 is a call flow of an example procedure for UL data with new QoS flow for which a mapping does not exist in the UE.

[0060] Figure 28 is a call flow of an example proactive connection modification procedure

[0061] Figure 29 is a call flow of an example reactive path modification procedure [0062] Figure 30 is a call flow of an example multi-hop RRC connection release procedure.

[0063] Figures 31A-C show a call flow of an example initial connection between a remote UE and the network when the access relay has a route to the network

[0064] Figures 32A-C show a call flow of an example initial connection between a UE- to-UE relay and the network when the access relay has a route to the network.

[0065] Figure 33A illustrates an example communications system in which the methods and apparatuses described and claimed herein may be embodied.

[0066] Figure 33B is a block diagram of an example apparatus or device configured for wireless communications.

[0067] Figure 33C is a system diagram of an example radio access network (RAN) and core network.

[0068] Figure 33D is a system diagram of another example RAN and core network. [0069] Figure 33E is a system diagram of another example RAN and core network. [0070] Figure 33F is a block diagram of an example computing system.

[0071] Figure 33G is a block diagram of another example communications system.

DETAILED DESCRIPTION

[0072] Table 5 of the Appendix describes many of the abbreviations used herein. [0073] Layer 2 Evolved UE-to-Network Relay Solution - Architecture [0074] For protocol architecture for the user plane and control plane, relaying is performed above RLC sublayer. See 3 GPP TR 36.746 V15.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 evolved ProSe Remote UE's user plane and control plane data are relayed above RLC via the evolved ProSe UE-to-Network relay UE from the evolved ProSe Remote UE to network and vice versa. Uu PDCP and RRC are terminated between the evolved ProSe Remote UE and the eNB while RLC, MAC and PHY and the non-3GPP transport layers are terminated in each link (e.g., the link between the evolved ProSe Remote UE and the evolved ProSe UE-to-Network relay UE and the link between the evolved ProSe UE-to-Network relay UE and the eNB). The user plane protocol stack and the control plane protocol stack when PC5 is used between the evolved ProSe remote UE and the evolved ProSe UE-to-Network relay UE is shown in Figure 1 and Figure 2, as defined in TR 36.746. Figure 1 illustrates an example user plane radio protocol stack for layer 2 evolved UE-to-Network relay (PC5), and Figure 2 illustrates an example control plane radio protocol stack for layer 2 evolved UE-to-Network relay (PC5).

[0075] Connection Oriented Communication vs Connectionless Communication [0076] In the connection-oriented communication, a dedicated path is established at the start between the source and the destination. In comparison, in connectionless communication, a packet can be sent from the source to the destination without prior arrangement. In the connectionless communication, each data packet is individually addressed and routed based on information carried in each packet, rather than in the setup information of a prearranged, fixed data channel as in connection-oriented communication. Connection-oriented communications handle real-time traffic substantially more efficiently than connectionless communication, especially with short constant length packets. However, a connectionless communication has an advantage over a connection-oriented communication, in that it has relatively lower overhead, e.g., lower signaling, setup and/or configuration overhead. In connection-oriented communication, control signaling are required for a path setup procedure. When a path is broken due to a topology change, a new path setup procedure needs to be triggered. Connectionless communications also allow for multicast and broadcast operations in which the same data are transmitted to several recipients in a single transmission. Note that, for the connectionless communication, a routing entry may still need to be built at each relay UE in order to forward a message if source routing is not used. Source routing is a routing mechanism where the source specifies the route of the packet and includes this route in the packet. Therefore, whether to choose connection-oriented and connectionless communication depends on the QoS requirements and how often the topology is changed.

[0077] Release 17 Study Item

[0078] As described in RP- 193118 New SID: Study on NR sidelink relay, a first version of NR Sidelink has been developed and it solely focuses on supporting V2X related road safety services in Release 16. The design aims to provide support for broadcast, groupcast and unicast communications in both out-of-coverage and in-network coverage scenarios. On top of that, Sidelink-based relaying functionality should be additionally studied for Sidelink/network coverage extension and power efficiency improvement, considering wider range of applications and services.

[0079] The study discusses coverage extension for UE-to-network sidelink-based communication. Uu coverage reachability is necessary for UEs to reach server in PDN network or counterpart UE out of proximity area. However, release- 13 solution on UE-to-network relay is limited to EUTRA-based technology, and thus cannot be applied to NR-based system, for both NG-RAN and NR-based Sidelink communication.

[0080] The study discusses coverage extension for sidelink-based UE-to-UE communication. Currently proximity reachability is limited to single-hop for the Sidelink communication, either via EUTRA-based or NR-based Sidelink technology. However, that is not enough in the scenario where there is no Uu coverage and satellite coverage, considering the limited single-hop Sidelink coverage.

[0081] The study discusses whether, overall, sidelink connectivity should be further extended in NR framework, in order to support the enhanced QoS requirements.

[0082] Example Use Case

[0083] It is a requirement of 5G system that there can be one or more relay UE(s)

(more than one hop) between the network and the remote UE. A remote UE can have one or multiple traffic flows to the network. Theses traffic flows can be relayed via different indirect network connection paths based on QoS requirements. For example, as shown in Figure 3, Sensing devices continuously send current sensor status to centralised computing instance for learning of the environment. See 3GPP TR 22.804 V16.2.0 Study on Communication for Automation in Vertical Domains (Release 16). Gateway Type B in this figure is used in reference to a base station for e.g., a small cell base station. Sensing data traffics will be relayed to other sensor devices and require from relatively low to relatively high latency and from relatively low to relatively high reliability. Examples of potential key performance indicators for UE to network relaying are captured in the Table 1 of the Appendix.

[0084] Figure 3 illustrates UE to NW traffic in a massive wireless sensor network.

[0085] In 5G, there can also be one or more relay UE(s) (more than one hop) between two UEs. A source UE can have one or multiple traffic flows to the destination UE. These traffic flows can be relayed via different Sidelink connection paths and path selection may be based on QoS requirements. Figure 4 illustrates and example of UE to UE traffic for control-to-control communication in an industrial IoT. As shown in the example of Figure 4, a UE, e.g., a sensor or actuator, may send cyclic and non-cyclic data to another UE, e.g., a sensor or actuator, which is more than one hop away. See 3 GPP TS 22.261 VI 7.1.0 Service requirements for the 5G system; Stage 1 (Release 17). This data traffic will be relayed to other sensors or actuators, and may have stringent requirements on end-to-end latency, communication service availability, and determinism, e.g., bounds on latency, loss, and packet delay variation (jitter), and high reliability. Appropriate relay UEs among the available relays will be selected to guarantee the QoS requirements of the traffic.

[0086] KPIs for UE to network relaying in the 5G system are defined in TS 22.261 . In several scenarios, it can be beneficial to relay communication between one UE and the network via one or more other UEs. Table 1 of the Appendix shows the performance requirements for relaying in different scenarios.

[0087] Issues in relation with Connectivity of a Remote UE to a Network assuming a Connection Oriented Framework

[0088] Problem 1: Architecture enhancements for QoS Support and Connection

Management

[0089] When a remote UE connects to a network, it needs to establish signalling or data connections with the network. However, different from the scenario that a UE is in coverage, a UE does not have a direct Uu interface with the gNB. The UE has to establish signalling or data connections to the network via one or more relay UEs. The existing protocol stack architecture needs to be enhanced to support message forwarding between the remote UE and the gNB and fulfil the QoS requirements of traffic flow between the remote UE and the gNB. [0090] Problem 2: Relay (Re)Selection and Path (Re)Selection issues including consideration to service continuity.

[0091] When a remote UE starts connecting to the network, it needs to acquire system information and select the serving gNB. However, different from the scenario that a UE is in coverage, a UE does not have a Uu interface with the gNB. How the remote UE acquires system information and selects the serving gNB becomes an issue. Since the UE has to connect to the network via one or more relay UEs, how does the UE discover other relay UEs that forward signalling and data message to the network also becomes an issue. Moreover, there may be more than one path between the remote UE and the network. How to discover and select one or more candidate paths to guarantee the QoS and service continuity requirement of the traffic becomes an issue.

[0092] Problem 3: Signaling Procedures for Connection Establishment

[0093] After a remote UE discovers one or more candidate paths, how to setup the signalling connection and data connection becomes an issue. For example, what are the procedures to create signalling radio bearers, and data radio bearer and the configuration of the necessary hop-by-hop Sidelink data forwarding channels that ensure QoS requirements are met. Procedures are needed to create new PC5 connections and release old PC5 connections to establish the connectivity. Procedures are needed to configure the relay UEs along the connectivity path to forward message between the remote UE and the gNB to fulfil the QoS and service continuity requirements.

[0094] Problem 4: Signaling Procedures for Connection Modification or Release including consideration to service continuity.

[0095] The quality of the established connection along the path between the remote UE and the gNB may change. For example, an established connection may be broken if one of the links on the path is broken. A link can be broken due to UE mobility or when a UE stops serving as a relay due to low battery power. Therefore, methods are needed to be developed about how the connectivity between a UE and gNB is maintained to fulfill the QoS of existing flows. For example, the following six issues may need to be addressed.

[0096] First, how can a failure on a route or a path from a remote UE to the destination gNB be detected? [0097] Second, how can a topology change event, e.g., two UEs move in or out communication range of each other, be detected?

[0098] Third, how to report a link broken or topology change?

[0099] Fourth, which entity should report this information?

[00100] Fifth, how to guarantee the service continuity when a broken path is detected?

[00101] Sixth, how to identify, configure or reconfigure an alternative path and re-route the data traffic to an alternative path to guarantee the service continuity?

[00102] Architecture Enhancements for QoS Support and Connection Management

[00103] When a remote UE connects to a network, it needs to establish signalling or data connection with the network. However, different from the scenario that a UE is in coverage, a UE does not have a direct Uu interface with the gNB. The UE has to establish signalling or data connection to the network via one or more relay UEs. A new architecture may be used to support message forwarding between the remote UE and the gNB and fulfil the QoS requirements of traffic flow between the remote UE and the gNB. Moreover, new protocol stacks may be used including new service functions or services that are provided by the adaptation layer of a relay UE and a gNB. Based on the new architecture and protocol stacks, new Multi-hop RRC states for a UE, e.g., M-RRC connected and M-RRC idle may be used. New procedures also may be used for a UE to transit between these states and UE behavior in these states is defined.

[00104] Herein, we use the terms “intermediary nodes” and “intermediary relay UEs” interchangeably.

[00105] Herein, we use the term “path” or “communication path” to denote how the transmissions from a UE are sent to a gNB and/or how the transmissions from a UE are received from a gNB. These transmissions may traverse zero, one, or more relay UEs along this path. In the case the traffic traverses zero relay UEs, this is also referred to as a direct path. In the case the traffic traverses one or more relay UEs, this is also referred to as an indirect path. Any communication between the UE and the relay UE as well as any communication between the relay UEs, is over the sidelink (over a PC5 link). Any communication between a UE and the gNB, is over the Uu link. The number of relay UEs that are traversed may be denoted as the number of hops in the communication path. Alternatively, the number PC5 links that are traversed may be denoted as the number of hops in the communication path. Alternatively, the total number of links that are traversed (PCS links and Uu links) may be denoted as the number of hops in the communication path. In an indirect path, the last relay UE in the communication path may also be referred to as a UE-to-Network (U2N) relay. Such a relay UE has one PCS link to another UE as well as a Uu link to a gNB. In this same indirect path, all the other relay UEs in the communication path may also be referred to as UE-to-UE (U2U) relays.

[00106] In the following, the terms “path”, “communication path”, “route” and “communication route” are sometimes used interchangeably. A UE may have one or multiple paths to a gNB. These paths may be used simultaneously to allow communication between the UE and the gNB

[00107] New Architecture and Protocol Stack for QoS Support and Connection

Management

[00108] In a new architecture for QoS support and connection management, all UEs that are connected to a gNB via one or multiple hops form a directed acyclic graph (DAG) topology with the gNB at its root. In this DAG topology, the neighbor UE toward the gNB is referred to as a parent UE, and the neighbor UE away from the gNB is referred as a child UE. The direction toward the child UE is further referred to as downstream while the direction toward the parent node is referred to as upstream. For a remote UE, the parent UE is also called an access relay UE. The gNB may perform centralized resource, topology, and route management for the network. Figure 5 shows an example of RRC or data connection between each UE/relay UE and gNB. In the example of Figure 5 there is a two-hop chain of relay UEs underneath a gNB. A remote UE connects to an access relay UE via PC5 interface. A remote UE can connect to more than one access relay UE. The access relay UE may be a UE-to-UE relay or UE-to-NW relay. Each relay UE connects to an upstream relay UE (the parent relay UE) or the gNB. For example, a UE-to-UE Relay connects to an upstream relay UE via PCS interface. A UE-to-NW Relay connects to the gNB via Uu interface. A relay UE can connect to more than one upstream relay UEs. It is assumed that a relay UE is served by only one gNB. The serving gNB of a relay UE may change due to topology change. The connection between each UE and gNB runs over an RLC channel between relay UEs and the gNB. An adaptation layer is introduced on these relays and the gNB to forward signalling and data message between the remote UE and the network as shown in Figures 6-9. The terms adaptation layer and adaptation sublayer are used interchangeably. Furthermore, the functionality at this layer is defined by a Relay Adaptation Protocol (RAP).

[00109] The main service and functions of the adaptation sublayer may include: transfer of data; routing of packets to next hop; determining the adaptation layer address of the destination and connection for packets from upper layers; determining the adaptation layer address of the destination and connection for packets from child remote UE; determination of egress RLC channels for packets routed to next hop determining whether traffic to be delivered to upper layers, an egress Relay link, an egress RLC channel, a gNB, or a remote UE; flow control notification; RLF notification; RAP routing ID Management for a remote UE; and/or a re-directing function to support service continuity.

[00110] Figure 5 shows an example of adaptation layer interaction between UEs and the gNB.

[00111] Figure 6 shows an example control plane protocol stack between a remote UE and the gNB. Figure 7 shows an example control plane protocol stack between a relay UE and the gNB. Figure 8 shows an example user plane protocol stack between a remote UE and the gNB. Figure 9 shows an example user plane protocol stack between a relay UE and the gNB. On each link (relay link or link between U2N relay and gNB), the adaptation layer PDU are carried by RLC channels. Multiple RLC channels can be configured on each link (relay link or link between U2N relay and gNB) to allow traffic prioritization and QoS enforcement. The RLC channel mapping for adaptation layer PDUs is performed by the adaptation layer on each relay UE and the gNB. The RLC channel between UEs is also referred to as a SL RLC channel or PC5 RLC channel. The RLC channel between a UE and the gNB is also referred to as a Uu RLC channel

[00112] On the adaptation sublayer, packets are routed based on the adaptation routing ID, which is carried in the adaptation sublayer header. The adaptation sublayer header is added to the packet when it arrives from upper layers, from a child remote UE, and it is stripped off when it has reached its destination node. The selection of the packet’s adaptation sublayer routing ID is configured by the relay UE and the gNB. The adaptation sublayer routing ID consists of adaptation sublayer address and adaptation sublayer connection ID, where the adaptation sublayer address indicates the destination node of the packet on the adaptation sublayer, and the adaptation sublayer connection ID indicates the routing path the packet should follow to this destination. For the purpose of routing, each relay UE is further configured with a designated adaptation sublayer address. Note that in the following, the terms adaptation sublayer routing ID, adaptation routing ID, RAP routing ID, and routing ID are used interchangeably. Also, the terms adaptation sublayer connection ID, adaptation connection ID, RAP connection ID, and connection ID are used interchangeably.

[00113] The Relay Adaptation Protocol (RAP) on the relay UE manages the RAP routing ID for its child remote UE(s). The access relay UE manages a unique RAP routing ID for each SL RLC Channel of its child remote UE(s). This may be because a remote UE does not have an adaptation layer and cannot maintain an adaptation layer address and a routing ID itself. The RAP address of the routing ID may be the same as the RAP address ID of the access relay UE or may be a different adaptation address ID assigned by the gNB. Note that the adaptation address ID should be unique within the domain of the serving gNB for the routing purposes, thus it has to be assigned by the gNB. The connection ID of the routing ID may be assigned by the access relay UE or the gNB.

[00114] On each hop of the packet’s path, the relay UE inspects the packets adaptation sublayer address in the routing header to determine if the packet has reached its destination, e.g., the relay UE matches the relay UE’s adaptation sublayer address or the relay UE’s child remote UE adaptation sublayer address. In case the packet has not reached the destination, the relay UE determines the next hop link, referred to as egress link, based on the adaptation sublayer routing ID carried in the packet header and a routing configuration it received from the gNB. In the case the packet is for a relay UE’s child remote UE, based on the adaptation sublayer routing ID carried in the packet header, the relay UE determines the Sidelink RLC channel to forward the packet.

[00115] The relay UE also selects the RLC channel on the designated egress link. For packets arriving from upper layers the selection of the RLC channel is based on upper layer traffic specifiers. For packet arriving from Child remote UE Sidelink, the RLC channel on the egress link is determined based on mapping configuration between ingress Sidelink RLC channels and egress RLC channel provided by itself or the gNB. When packets are routed from one link to another, the RLC channel on the egress link is determined based on the mapping configuration between ingress RLC channels and egress RLC channels provided by the gNB. [00116] Figure 10 depicts an example Layer 2 architecture for downlink on the gNB. Figure 11 and Figure 12 depict example Layer 2 architecture for downlink and uplink on the relay UE, respectively, wherein the Relay Adaptation Protocol (RAP) layer offers routing functionality and mapping to Relay RLC channels and SL RLC channels.

[00117] New Multi-hop RRC States for a UE and State Transition Procedure

[00118] A new state machine in the RRC layer is herein proposed to support multiple hop connection management. First, new Multi-hop RRC states for a UE, e.g., M-RRC connected and M-RRC idle may be used. Second, new procedures are also proposed for a UE to transit between these states.

[00119] A UE that is in M-RRC connected state has at least one multi-hop RRC connection with the gNB. This means not only at least one path or route is set up between the UE and the gNB, but also the RLC channel mappings are configured at the relay UEs on the path. Note that, it is not required that a relay UE on the path is in the M-RRC connected state.

[00120] A UE that is in M-RRC idle state has at least one multi-hop path or route to the gNB but there is no RLC channel mapping configured at the relay UEs on the path.

[00121] The M-RRC state is a separate state machine with Uu RRC state. In other words, a UE can have two simultaneous connections with a gNB. One connection is via Uu and another is via multi-hop Sidelink. It may be transparent from upper layer or core network whether a connection is a M-RRC connection or Uu RRC connection. For example, a UE is in CM-Connected state if there is a M-RRC connection or Uu RRC connection between the UE and the gNB.

[00122] Alternatively, the M-RRC state may not necessarily be a separate state from the legacy RRC state but rather an extension to the legacy RRC state wherein the remote UE or relay UE RRC context in RRC CONNECTED state or RRC INACTIVE state is extended to include context information related to multi-hop connectivity. In other words, the RRC signaling connection may be a multi-connectivity signaling connection that comprises of one or more connectivity paths, wherein a path may be via a direct path across Uu interface with no involvement of PC5 interface, or a path may be an indirect path possibly with multi-hop, that involves a PC5 interface. With the extension of RRC state to include M-RRC state as described herein, traffic on signaling radio bearers (for e.g. SRB0, SRBl, SRB2 or even SRB3) may be carried over a direct path involving only Uu interface, or carried over an indirect path that involves a PC5 interface. Hereinafter, an M-RRC state may be understood as an RRC sub-state in reference to the existence of an RRC signaling connection or a lack thereof of an RRC signaling connection, over an indirect path that involved a PCS interface. Unless otherwise stated, hereinafter, the terms M-RRC state and RRC state will be used interchangeably to denote an RRC state wherein the state i.e. RRC IDLE, RRC INACTIVE, or RRC CONNECTED is in reference to the existence of an RRC signaling connection or a lack thereof of an RRC signaling connection, over an indirect path that involved a PCS interface, or over a direct path that involved Uu interface only, or both direct path and an indirect path.

[00123] Additionally, hereinafter, the term multi -hop will be used to denote a connectivity path between two remote nodes, that comprise of a Uu leg, and one or more PCS legs, or that comprises of one or more PCS leg with no Uu leg.

[00124] Additionally, hereinafter the term multi-hop is used to denote connectivity related aspects over an indirect path. For example, an RRC connection for a UE (remote UE or relay UE) using an indirect path is referred to as a multi-hop RRC connection, an RRC message to/from a UE using an indirect path is referred to as a multi-hop RRC message, an RRC message exchange to/from a UE using an indirect path is referred to as a multi-hop RRC message exchange, a SRB set up for the UE using an indirect path is referred to as a multi-hop SRB, and a DRB set up for the UE using an indirect path is referred to as a multi-hop DRB.

[00125] Figure 13 shows an example state transition diagram when a UE is powered on. An example high-level illustration of multi-hop RRC connection management operation with is shown in Figure 14.

[00126] In step 1 of Figure 14 the UE is powered on.

[00127] In step 2, the UE is either pre-configured (in SIM or ME), provisioned by a V2X Application Server, or provisioned by the SL/V2X control function located in the core network with information in support of SL operation e.g., discovery procedure whereby the UE discover other devices for SL communication. The SL Control Function may be a Policy Charging Function (PCF). The PCF may deliver information in support of SL operation to the UE in the form of policies. The information may be part of an Access and Mobility Policy or a UE Route Selection Policy. The information may indicate to the UE whether the UE is allowed to act as a relay, whether the UE is allowed to act as a remote UE, the identities, or UE types, of the other UE that the UE may use as a remote UE, and the identities, or UE types, of the other UE that the UE may serve as a remote UE. The information may also indicate the delay tolerance, or maximum number of hops for various traffic types.

[00128] In step 3, the UE may perform synchronization and discovery in order to identify its neighbor UEs in step 3. See Figures 15-17.

[00129] In step 4, Based on the information discovered in step 3 and the information that was configured in step 2, the UE initiates a relay or path selection procedure for creating a multi-hop RRC connection to the gNB. The detail procedures for step 4 are described. See Figures 15-17.

[00130] In step 5, the UE will initiate a multi-hop RRC setup procedure along the relays or paths selected in step 4. See Figures 18-21.

[00131] In step 6, after a successful multi-hop RRC setup procedure, the UE switches to M-RRC connected state to transmit communication packet. In the M-RRC connected state, the UE will maintain the multi-hop RRC connection with the gNB. For example, if a new traffic is initiated by the upper layer and the existing Multi-hop DRB (M-DRB) cannot fulfill the QoS requirement of the new traffic, the UE will create a new multi-hop DRB along the same path or a different path to the gNB. In another example, if the existing DRB is broken or cannot fulfill the QoS of the traffic, the UE will create a new multi-hop DRB along the same path or a different path to the gNB. The detail procedures for step 6 are described in relation to Figures 22 to 29.

[00132] In step 7, a multi-hop RRC a procedure to release a multi-hop RRC connection is described relation to Figure 30.

[00133] In step 8, after a successful multi-hop RRC connection release procedure, a UE will be in M-RRC idle state as in step 8. In the M-RRC idle state, the UE may store the previous path information to the gNB, do the local discovery and report relay context information to the gNB.

[00134] In step 9, a UE may receive a paging message from gNB for to initiate Mobile Terminated (MT) traffic as in step 9.

[00135] In step 10, a UE may also initiate a new Mobile Originated (MO) traffic from upper layer. In these scenarios, the UE may initiate relay or path reselection procedure for creating a multi-hop RRC connection to the gNB in step 10.

[00136] In step 11, a UE will initiate a multi-hop RRC re-establishment procedure along the relays or paths selected in step 10. The detail procedures for step 11 are described in relation to Figures 31 and 32. After a successful multi-hop RRC re-establishment procedure, the UE switches to M-RRC connected state to transmit communication packet. In the M-RRC connected state, the UE will maintain the multi-hop RRC connection with the gNB as in step 6 and as described in relation to Figures 22 to 29.

[00137] Methods for Relay (Re)Selection and Path (Re)Selection

[00138] When a remote UE starts connecting to the network, it needs to acquire system information and select the serving gNB. However, different from the scenario that a UE is in coverage, a UE does not have a Uu interface with the gNB. Methods are proposed herein for a UE to acquire system information and select the serving gNB. Since a UE has to connect to the network via one or more relay UEs, methods are also proposed for a remote UE discover other relay UEs that forward signalling and data messages to the network. Moreover, there may be more than one path between the remote UE and the network. Methods may be used to discover and select one or more candidate paths to guarantee the QoS and service continuity requirement of the traffic. A UE will periodically do the synchronization and local discovery procedure with its neighbor UEs. See Figures 15 and 16. A relay or path (re)selection procedure may be triggered when a new multi-hop connection is needed.

[00139] For example, the following five events may trigger a new multi-hop connection. First, the UE is powered on. Second, the UE is in M-RRC idle and a new MO traffic is initiated by the upper layer. Third, the UE is in M-RRC idle and receive a multi-hop paging message from the gNB for a new MT traffic. Fourth, the UE is in M-RRC connected and a new MO traffic is initiated by the upper layer and the existing connection cannot fulfill the QoS requirement of the new traffic. Fifth, the UE is in M-RRC connected and a new MT traffic is initiated by the network and the existing connection cannot fulfill the QoS requirement of the new traffic.

[00140] Regarding relay or path (re)selection, see Figure 17.

[00141] Synchronization and Local Discovery

[00142] Synchronization and local discovery procedures are proposed herein for a UE to acquire system information, select the serving gNB and discover one or more candidate paths to the gNB. In the remote UE initiated procedure, the remote UE may broadcast relay discovery request message to all its neighbor UEs or transmit the discovery request to UEs that the remote UE has already paired with as shown in the example of Figure 15. The message may contain the relay and path selection criteria for the connection as shown in Table 2 of the Appendix.

[00143] After receiving the request, the relay will send a relay discovery response message to the remote UE if it is willing to serve as a relay UE of the remote UE and meet the relay and path selection criteria of the remote UE. The message may contain the relay and path selection context information as shown in Table 3 of the Appendix.

[00144] In the relay UE initiated procedure, the relay UE may periodically broadcast relay advertisement request message to all its neighbour UE or transmit to UEs that it has paired with as shown in the example of Figure 16. The message may contain the relay and path selection context information as shown in Table 3 of the Appendix. After receiving the request, remote UE may send a relay advertisement response message to confirm the received message. The response message may also contain the indication that the remote UE selects the relay UE as an access relay UE to establish a Multi-hop connection. See Figures 18-21.

[00145] Relay (re)selection and path (re)Selection Criteria

[00146] After the remote UE obtained the relay and path selection context information from its neighbors, it may start a relay (re)selection and path (re)selection procedure. The procedure may be triggered periodically or aperiodically via some events, e.g., When initiating a new traffic or the existing connection cannot fulfill the QoS requirements for the existing traffic flow, or the PCS connection to the a relay UE experiences an RLF, or the Relay UE experiences an RLF to one of its upstream nodes, or the Relay UE asks the remote UE to select another relay UE. An example illustration of relay (re)selection and path (re)Selection is shown in Figure 17. The remote UE first selects a neighbor relay UEs based on relay and path selection criteria as described in Table 2 and Table 3 of the Appendix. For example, the remote UE only selects relay UEs that have the same PLMN ID and gNB it has provisioned. Among these neighbor relay UEs, the remote UE may select neighbor relay UEs which are in the M-RRC connected state. Among those neighbor relay UEs, the remote UE may further select the relay UEs that have at least a M- RRC connection that meet the QoS requirement of the new traffic. Among those neighbor relay UEs, the remote UE may further select the relay UEs that have the highest QoS of M-RRC connections. A neighbor relay UE may have more than one connection, the remote UE may further select the connection that have can fulfill its QoS requirements. After selection, the relay UEs, the remote UE initiates an M-RRC setup procedure along the selected connection. See Figures 18 and 19. If there is no neighbor relay UEs in M-RRC connected state or none of neighbor relay UEs has a M-RRC connection that meets the QoS requirement of the new traffic flows, the remote UE may select neighbor relay UEs which are in the M-RRC idle state. Among those neighbor relay UEs, the remote UE may further select the relay UEs that has a path with the minimum number of hops towards the gNB. Although the selection criteria above are described in sequence, it should be understood that the criteria may be applied in any order and in any combination. Additional criteria from the relay and path selection context information may also be used for relay UE selection including: Relay UE serving gNB, Relay UE PLMN ID, Relay UE capability, Relay UE RRC state, Relay UE load (e.g., a backhaul load in terms of backhaul free capacity, or a fronthaul load in terms of fronthaul free capacity), and Relay UE signal quality

[00147] After selecting the relay UEs, the remote initiates a M-RRC setup procedure along the selected path. See Figures 20 and 21.

[00148] Signaling Procedures for Connection Establishment

[00149] After a remote UE discovers one or more candidate paths, methods may be used to setup the signalling connection and data connection to the gNB including the creation of Multi-hop Signalling Radio Bearers (M-SRBs) and Multi-hop Data Radio Bearers (M-DRB) to the gNB. Methods are also proposed to configure the adaptation layer on the relay UEs on the path to forwarded messages between the remote UE and the gNB.

[00150] Procedure for Multi-hop RRC Connection Setup along an Existing M-RRC Connection of One or More its Neighbors.

[00151] Methods may be used herein to setup a multi-hop RRC along an existing M- RRC connection of one or more its neighbours. An example procedure for a remote UE to set up an initial RRC connection is described in reference to Figures 18A-C. An example procedure for a UE-to-UE Relay to set up an initial RRC connection is described reference to Figures 19A-C.

[00152] Figures 18A-18C illustrate an example call flow for an initial connection, between a remote UE and the network when the access relay has a connection to the network. Steps 1-13 Figures 18A-18C are described below.

[00153] In step 1. After the remote UE selects a neighbor relay UE as its access relay UE, it sends "RRC setup request" to access relay UE. The “RRC setup request” may be encapsulated in an PC5 control plane or user plane message. In the PC5 message, the remote UE may indicate the payload contains a “RRC setup request” to the gNB and it is a remote UE that does not have an adaptation layer and cannot have an adaptation layer address. The remote UE may indicate the connection it selects for forwarding the message. This message may also include the ID of the Access Relay UE.

[00154] In step 2, when the access relay UE receives the PC5 message, it knows the payload contains a “RRC setup request” to the gNB. The access relay UE generates an RRC message carrying the RRC setup request sent from the remote UE. The message includes its own UE ID and adds an adaptation layer header including routing ID, e.g., gNB adaptation layer address and the connection ID.

[00155] In step 3, the access relay UE transmits the encapsulated RRC message to the gNB via a multi-hop SRB connection specified by the routing ID.

[00156] In step 4, when the UE-to-NW Relay receives the message, its adaptation layer receives the packet from ingress Relay RLC channel and then maps it to the egress Relay RLC channel based on the configuration and routing ID in the adaptation layer header.

[00157] In step 5, the adaptation layer of UE-to-NW Relay forwards the RRC message to the gNB.

[00158] In step 6, the gNB removes the header of adaptation layer, and decapsulation the payloadZ (including the RRC message from the access relay UE), and then obtains the "RRC setup request" message inside payloadZ through further decapsulation. From the RRC setup request message, the gNB knows the request is sent from a remote UE and the UE-to-UE network relay is its access relay UE. The gNB generates a RAP routing ID for the new connection and configure the adaptation layer of each relay UEs on the path. In one example, the RAP address of the routing ID may be the same as the RAP address of the access relay UE. In this scenario, the connection ID would be a different ID from the connection ID that the access relay UE is using. In another example, the RAP address of the routing ID may be a different RAP address of the access relay UE. During the configuration, the new RAP routing ID may have the same Relay RLC channel mapping configuration of the RAP routing ID of the access relay UE. The gNB configure each relay UE on the path in step 6a-d. Note that, the RAP configuration to the Access Relay may also be carried in the RRC response message in step 7 instead. It should be understood that the RAP configuration may also be carried in an RRC Reconfiguration message. [00159] In step 7, the gNB sends an RRC response message, which contains “RRC setup” towards the remote UE. The gNB adds the adaptation layer header which includes essential routing information for the RRC message via SRB specified by the routing ID. In the RRC message, the gNB may indicate the RAP routing ID assigned to the initial connection with the remote UE and the RLC channel mapping between the Sidelink RLC channel and the Relay RLC channel.

[00160] In step 8, when the UE-to-NW Relay receives the message, its adaptation layer receives the packet from ingress RLC channel and then maps it to the egress RLC channel based on routing ID and RLC channel mapping configuration.

[00161] In step 9, the adaptation layer of UE-to-NW Relay forwards the RRC message to the access relay UE.

[00162] In step 10, the access relay UE learns the specific message type according to the specific SRB or the message type indicator and knows that the RRC message is for itself from the routing information in the adaptation header. Then the access relay UE removes the header of adaptation layer and extracts the payload which includes “RRC setup” for the remote UE from the RRC message. Based on the information from the RRC message, the access relay UE also configures its RAP to support the new connection based on the RAP routing ID assigned to the remote UE contained in the message. It may also configure the RLC channel mapping between the Sidelink RLC channel and the Relay RLC channel-based information provided by the gNB. The access relay UE may also select the ingress Sidelink RLC channel ID from the remote UE and map to the egress Relay RLC Channel ID to the UE-to-NW Relay for the upstream traffic from the remote UE. The access relay UE may select the egress Sidelink RLC channel ID to the remote UE and map to the ingress Relay RLC Channel ID from the UE-to-NW Relay for downstream traffic to the remote UE.

[00163] In step 11, the access relay UE encapsulates the “RRC setup” towards remote UE in a PC5 message via control plane or user plane.

[00164] In step 12, the remote UE configures its AS context to support the new connection based on the information in the “RRC setup” and sends RRC setup complete towards the gNB using the new created connection, e.g., M-SRB 1.

[00165] In step 13, further actions are taken for the remote UE to connect the network, such as the remote UE setups other M-SRBs and M-DRBs to the gNB. See Figures 23 and 24 [00166] Figures 19A-19C illustrate an example call flow for an initial connection between a UE-to-UE Relay and the network when the access relay has a connection to the network. The following steps are written from the perspective of the initial connection between a UE-to-UE Relay and the network. It should be understood that the same steps may also apply to the initial connection between a remote UE with an adaptation layer and the network. In step 1 of Figure 19 A, after the relay UE selects a neighbor relay UE as its access relay UE, it sends "RRC setup request" to access relay UE. The “RRC setup request” may be encapsulated in an PC5 control plane or user plane message. In the PCS message, the relay UE may indicate the payload contains a “RRC setup request” to the gNB and it is a relay UE that has an adaptation layer and requests an adaptation layer address. The relay UE may indicate the connection it selects for forwarding the message.

[00167] In step 2, when the access relay UE receives the PCS message, it knows the payload contains a “RRC setup request” to the gNB. The access relay UE generates an RRC message carrying the RRC setup request sent from the relay UE. The message includes its own UE ID and adds the adaptation layer header including routing ID, e.g., connection ID selected by the relay UE and gNB adaptation layer address.

[00168] In step 3, the access relay UE transmits the encapsulated uplink RRC message to the gNB via a multi-hop SRB connection specified by the routing ID.

[00169] In step 4, when the UE-to-NW Relay receives the message, its adaptation layer receives the packet from ingress Relay RLC channel and then maps it to the egress Relay RLC channel based on the configuration and routing ID in the adaptation layer header.

[00170] In step 5, the adaptation layer of UE-to-NW Relay forwards the RRC message to the gNB.

[00171] In step 6, the gNB removes the header of adaptation layer, and decapsulates the payload2 (including the RRC message from the access relay UE), and then obtains the "RRC setup request" message inside payload2 through further decapsulation. From the RRC setup request message, the gNB know the request is sent from a relay UE and the UE-to-UE network relay is its access relay UE for the initial connection. The gNB generates a RAP routing ID for the new connection and configures the adaptation layer of each relay UEs on the path. In the RAP routing ID, the gNB assigns a RAP address for the relay UE. During the configuration, the new RAP routing ID may have the same Relay RLC channel mapping configuration of the RAP routing ID of the access relay UE. The gNB configure each relay UE on the path in step 6a-d. Note that, the RAP configuration to the Access Relay may also be carried in the RRC response message in step 7 instead.

[00172] In step 7, the gNB sends an RRC response message, which contains “RRC setup” towards the relay UE. The gNB adds the adaptation layer header which includes essential routing information for the RRC message via SRB specified by the routing ID. In the “RRC setup” message, the gNB may indicate the RAP routing ID assigned to the initial connection with the relay UE and the RLC channel mapping between the Relay RLC channel of the relay UE and access relay UE.

[00173] In step 8, when the UE-to-NW Relay receives the message, its adaptation layer receives the packet from ingress RLC channel and then maps it to the egress RLC channel based on routing ID and RLC channel mapping configuration.

[00174] In step 9, the adaptation layer of UE-to-NW Relay forwards the RRC message to the access relay UE.

[00175] In step 10, the access relay UE leams the specific message type according to the specific SRB or the message type indicator and knows that the RRC message is for itself from the routing information in the adaptation header. Then the access relay UE removes the header of adaptation layer extracts the payload which includes “RRC setup” for the relay UE from the RRC message. Base on the information from the RRC message, the access relay UE also configures the Relay RLC channel mapping-based information provided by the gNB. The access relay UE may also select the ingress Relay RLC channel ID from the relay UE and map to the egress Relay RLC Channel ID to the UE-to-NW Relay for the upstream traffic from the relay UE. The access relay UE may select the egress Relay RLC channel ID to the relay UE and map to the ingress Relay RLC Channel ID from the UE-to-NW Relay for downstream traffic to the relay UE.

[00176] In step 11. The access relay UE encapsulates the “RRC setup” towards remote UE in a PC5 message via control plane or user plane. Based on the information in the “RRC setup” message, the relay UE configures its RAP to support the new connection based on the RAP routing ID assigned to it. It may also configure the RAP RLC channel mapping between the access relay UE based information provided by the gNB. [00177] In step 12. The relay UE configure its RAP to support the new connection based on the information in the “RRC setup” and then sends RRC setup complete towards the gNB using the new created connection, e.g., M-SRB 1.

[00178] In step 13. More subsequent steps for the relay UE to connect the network, such as the relay UE setups other M-SRBs and M-DRBs to the gNB. See Figures 23 and 24

[00179] Procedure of multi-hop RRC connections setup along an existing path of one or more its neighbors

[00180] Procedures are proposed herein whereby a UE sets up an initial RRC connection after selecting an access relay UE that does not have an M-RRC connection but has a path or route with the gNB. In one approach, after receiving a request from the UE, the access relay UE initiates a procedure to switch from M-RRC idle to M-RRC connected. The UE then initiates the connection that follow the same procedure as described in connection with Figures 18 and 19. In an alternative approach, after receiving a request from the UE, the access relay UE initiates a procedure that it may not need to switch from M-RRC idle to M-RRC connected but sets up the initial connection for the UE. The detail procedure for a remote UE to set up an initial RRC connections is described in reference to Figures 20A-C. The detail procedure for a UE-to- UE Relay to set up an initial RRC connection is described in reference to Figures 21A-C.

[00181] In such a case, the adaptation layer in the access relay UE may be configured based on an old configuration that the access relay UE received while the access relay UE was in M-RRC connected state. Alternatively, the gNB may perform RAP configuration for the access relay UE based on some other indication or event. For example, some UEs may regularly or periodically be provided with RAP configurations.

[00182] Figures 20A-20C illustrate an example call flow for an initial connection between a remote UE and the network when the access relay has a route to the network. Steps 1-13 Figures 20A-20C are described below.

[00183] In step 1. After the remote UE selects a neighbor relay UE as its access relay UE, it sends "RRC setup request" to access relay UE. The “RRC setup request” may be encapsulated in an PC5 control plane or user plane message. In the PCS message, the remote UE may indicate the payload contains a “RRC setup request” to the gNB and it is a remote UE that does not have an adaptation layer and cannot have an adaptation layer address. [00184] In step 2. When the access relay UE receives the PC5 message, it knows the payload contains a “RRC setup request” to the gNB. The access relay UE generates an RRC message, e.g., RRC Setup request message to the gNB. The message may also carry the RRC setup request sent from the remote UE as the payload. The message includes its own UE ID and adds an adaptation layer header including routing info, e.g., gNB RAP address as the destination address, its own RAP address as the originator address.

[00185] In step 3, the access relay UE transmits the RRC message to the next hop relay UE towards gNB based on its routing configuration.

[00186] In step 4, when the UE-to-NW Relay receives the message, its adaptation layer receives the packet from prior hop relay UE and then forwards it to the next hop relay UE based on the routing configuration and destination address in the adaptation layer header.

[00187] In step 5, the adaptation layer of UE-to-NW Relay forwards the RRC message to the gNB.

[00188] In step 6, the gNB removes the header of adaptation layer and receives the RRC message, e.g., RRC Setup request message, from the access relay UE. The gNB then obtains the "RRC setup request" sent by the remote UE inside payload2 through further decapsulation. From the RRC setup request message associated with the remote UE, the gNB knows the request is sent from a remote UE and the UE-to-UE network relay is its access relay UE. The gNB generates a RAP routing ID for the new connection. The gNB also selects a path to the remote UE and configure the adaptation layer of each relay UEs on the path. In one example, the RAP address of the routing ID may be the same as the RAP address of the access relay UE.

In this scenario, the connection ID would be a different ID from the connection ID that the access relay UE is using. In another example, the RAP address of the routing ID may be a different RAP address from the access relay UE. Similarly, from the RRC message, e.g., RRC setup request message, associated with the access relay UE, the gNB knows the request is sent from an access relay UE. If the access relay UE also requests to re-establish a connection with the gNB, the gNB generates a connection ID for the new connection associated with the access relay UE. The gNB selects a path to the access relay UE and configures the adaptation layer of each relay UEs on the path. During the configuration, the new RAP routing ID associated with the remote UE connection may have the same Relay RLC channel mapping configuration of the access relay UE. The gNB configure each relay UE on the path in step 6a-d. [00189] In step 7, the gNB sends an RRC Setup message towards the remote UE and the message is encapsulated in an RRC message, e.g., the “RRC setup” message, sent towards the access relay UE. The gNB adds the adaptation layer header which includes essential routing information for the RRC message to the access relay UE specified by the routing ID. In the RRC message, the gNB may indicate the RAP routing ID assigned to the initial connection with the remote UE, the re-established connection with the access relay UE and the RLC channel mapping between the Sidelink RLC channel and the Relay RLC channel.

[00190] In step 8, when the UE-to-NW Relay receives the message, its adaptation layer receives the packet from ingress RLC channel and then maps it to the egress RLC channel based on routing ID and RLC channel mapping configuration.

[00191] In step 9, the adaptation layer of UE-to-NW Relay forwards the RRC message to the access relay UE.

[00192] In step 10, the access relay UE finds that the RRC message, e.g., RRC setup message, is for itself from the routing information in the adaptation header. Then the access relay UE removes the header of adaptation layer extracts the RRC message, e.g., “RRC setup.” Based on the information from the RRC message, the access relay UE may configure its RAP to reestablish a connection based on the RAP routing ID contained in the message. It may also configure the RLC channel mapping-based information provided by the gNB. The access relay UE also configures its RAP to support the new connection based on the RAP routing ID assigned to the remote UE contained in the message. It may also configure the RLC channel mapping between the Sidelink RLC channel and the Relay RLC channel, based on information provided by the gNB. The access relay UE may also select the ingress Sidelink RLC channel ID from the remote UE and map to the egress Relay RLC Channel ID to the UE-to-NW Relay for the upstream traffic from the remote UE. The access relay UE may select the egress Sidelink RLC channel ID to the remote UE and map to the ingress Relay RLC Channel ID from the UE-to-NW Relay for downstream traffic to the remote UE. The access relay UE then decapsulates the “RRC Setup” message associated with the remote UE.

[00193] In step 11. The access relay UE encapsulates the “RRC setup” towards remote UE in a PC5 message via control plane or user plane. [00194] In step 12. The remote UE configures its AS context to support the new connection based on the information in the “RRC setup” and sends RRC setup complete towards the gNB using the new created connection, e.g., M-SRB 1.

[00195] In step 13. More subsequent steps for the remote UE to connect the network, such as the remote UE setups other M-SRBs and M-DRBs to the gNB. See Figures 23 and 24.

[00196] Figures 21A-C illustrate an example call flow for an initial connection between a UE-to-UE relay and the network when the access relay has a route to the network. The following steps are written from the perspective of the initial connection between a UE-to-UE Relay and the network. It should be understood that the same steps apply to the initial connection between a remote UE with an adaptation layer and the network. Steps 1-13 Figures 21A-C are described below.

[00197] In step 1. After the relay UE selects a neighbor relay UE as its access relay UE, it sends "RRC setup request" to access relay UE. The “RRC setup request” may be encapsulated in an PCS control plane or user plane message. In the PCS message, the relay UE may indicate the payload contains a “RRC setup request” to the gNB and it is a relay UE that has an adaptation layer and requests an adaptation layer address.

[00198] In step 2, when the access relay UE receives the PCS message, it knows the payload contains a “RRC setup request” to the gNB. The access relay UE generates an RRC message, e.g., RRC Setup request message to the gNB. The message may also carry the RRC setup request sent from the remote UE as the payload. The message includes its own UE ID and adds an adaptation layer header including routing info, e.g., gNB RAP address as the destination address, its own RAP address as the originator address.

[00199] In step 3, the access relay UE transmits the RRC message to the next hop relay UE towards gNB based on its routing configuration.

[00200] In step 4, when the UE-to-NW Relay receives the message, its adaptation layer receives the packet from prior hop relay UE and then forwards it to the next hop relay UE based on the configuration and routing ID in the adaptation layer header.

[00201] In step 5, the adaptation layer of UE-to-NW Relay forwards the RRC message to the gNB.

[00202] In step 6, the gNB removes the header of adaptation layer and receives the RRC message, e.g., RRC Setup request message from the access relay UE. The gNB then obtains the "RRC setup request" sent by the relay UE inside payload2 through further decapsulation. From the RRC setup request message associated with the relay UE, the gNB knows the request is sent from a relay UE and the UE-to-UE network relay is its access relay UE. The gNB generates a RAP routing ID for the new connection and configures the adaptation layer of each relay UEs on the path. The gNB generates a RAP routing ID for the new connection associated with the relay UE. The gNB then finds a path and configures the adaptation layer of each relay UEs on the path. In the RAP routing ID, the gNB assigns a new RAP address for the relay UE. Similarly, from the RRC message associated with the access relay UE, the gNB knows that if the access relay UE requests to re-establish a connection with the gNB, the gNB generates a connection ID for the new connection associated with the access relay UE and configures the adaptation layer of each relay UEs on the path. During the configuration, the RAP routing ID associate with the relay UE may have the same Relay RLC channel mapping configuration of the RAP routing ID of the access relay UE. The gNB configures each relay UE on the path in step 6a-d.

[00203] In step 7, the gNB sends an RRC Setup message towards the relay UE and the message is encapsulated in an RRC message, e.g., “RRC setup” message, sent towards the access relay UE. The gNB adds the adaptation layer header which includes essential routing information for the RRC message specified by the routing ID associated with the access relay UE. In the “RRC setup” message associated with the access relay UE, the gNB may indicate the RAP routing ID assigned to the re-established connection with the access relay UE and the RLC channel mapping configurations. In the “RRC setup” message associated with relay UE, the gNB may indicate the RAP routing ID assigned to the initial connection with the relay UE and the RLC channel mapping between the relay UE and the access relay UE.

[00204] In step 8, when the UE-to-NW Relay receives the message, its adaptation layer receives the packet from ingress RLC channel and then maps it to the egress RLC channel based on routing ID and RLC channel mapping configuration.

[00205] In step 9, the adaptation layer of UE-to-NW Relay forwards the RRC message to the access relay UE.

[00206] In step 10, the access relay UE finds that the RRC message, e.g., RRC setup message, is for itself from the routing information in the adaptation header. The access relay UE then removes the header of adaptation layer extracts the payload which includes the RRC message, e.g., “RRC setup” for the access relay UE to re-establish a connection. Based on the information from the RRC message associated with the access relay UE, the access relay UE may configure its RAP to re-establish a connection based on the RAP routing ID contained in the message. It may also configure the RLC channel mapping-based information provided by the gNB. The access relay UE may also select the ingress Relay RLC channel ID from the relay UE and map to the egress Relay RLC Channel ID to the UE-to-NW Relay for the upstream traffic from the relay UE. The access relay UE may select the egress Relay RLC channel ID to the relay UE and map to the ingress Relay RLC Channel ID from the UE-to-NW Relay for downstream traffic to the relay UE. The access relay UE then decapsulates the “RRC Setup” message associated with the relay UE.

[00207] In step 11. The access relay UE encapsulates the “RRC setup” towards relay UE in a PCS message via control plane or user plane. Based on the information in the “RRC setup” message, the relay UE configures its RAP to support the new connection based on the RAP routing ID assigned to it. It may also configure the RLC channel mapping between the access relay UE based information provided by the gNB.

[00208] In step 12. The relay UE sends RRC setup complete towards the gNB using the new created connection, e.g., M-SRB 1.

[00209] In step 13. More subsequent steps for the remote UE to connect the network, such as the relay UE setups other M-SRBs and M-DRBs to the gNB. See Figures 23 and 24.

[00210] Signaling Procedures for Connection Maintenance

[00211] The gNB or a UE may maintain the connection between a remote UE and gNB to fulfill the QoS of existing traffic flows and new traffic flows. New M-SRBs and M-DRBs may be created after the RRC connection has been established. See Figures 23 and 24. The gNB or a UE may create new M-DRBs that meet the QoS requirements for a new traffic flow. See Figures 18-21. 25-27. The gNB or a UE may modify a connection to meet the QoS requirement of the traffic flow including service continuity requirement , e.g., as described with reference Figures 28 and 29. However, before managing a connection, the gNB needs to obtain relay context information of all UEs in the network. Therefore, methods are described herein for the gNB to obtain relay context information of all UEs in the network.

[00212] Methods for the gNB to obtain relay context information of all UEs in the network [00213] Methods may be used for a gNB to obtain relay context information reported by each UE in the network. Each UE in the network maintains its relay context information, as indicated in Table 4 of the Appendix, and report its relay context information to gNB, as shown in the example of Figure 22.

[00214] The UE may send a UE relay context report message to the gNB periodically, after receiving a UE relay context request message from the gNB, after setup a connection with the gNB or when its UE relay context information changed. The UE may send all its UE relay context information after it first connects to the gNB. After that, the UE may only send the context information that has been changed since the last reporting. For example, when the UE detects the link between one of its neighbors UE is broken, it indicates the removal of previous neighbor UE from its neighbors set in the relay context report message. In another example, when the UE discovers a new neighbor UE, it indicates the addition of the new neighbor UE into its neighbor set in the relay context report message.

[00215] Methods to create new Multi-hop SRB and DRBs after the M-RRC connection is established

[00216] One or more new multi-hop SRBs (M-SRB) and multi-hop DRBs may be created after the RRC connection is established, e.g., as described with reference Figures 18-21.

[00217] Figure 23 is a call flow of an example procedure for creation new M-SRB s and M-DRBs to a remote UE initiated by the gNB. Steps 0-11 of Figure 23 are explained below.

In step 0. A M-RRC connection, e.g., a M-SRB 1 has been already established.

[00218] In step 1, the gNB receives an initial context setup request from CN that contains UE context data (including PDU session context, the Security Key, UE Radio Capability and UE Security Capabilities, etc.).

[00219] In step 2. In order to establish new M-SRB(s) and M-DRB(s), the gNB first selects a path for each M-SRB and M-DRB, the paths can be the same path as M-SRB 1 or could be a different path. After selecting the paths, the gNB assigns a new connection ID associated with each new M-SRB and M-DRB. The gNB then sends RAP Reconfiguration request to all relay UEs on the paths as in step 3-6. After configuring each relay UE, the gNB then sends a M- RRC reconfiguration message to the remote UE to configure M-DRBs as in step 8. [00220] In step 3, the gNB sends a RAP reconfiguration request to the UE-to-NW Relay on the new connection. The RAP reconfiguration request contains the new routing ID and RLC channel mapping configuration associated with the new M-SRB and M-DRB.

[00221] In step 4, the UE-to-NW Relay configures RAP based on the RAP reconfiguration request. The UE-to-NW Relay sends a RAP reconfiguration complete message to the gNB to confirm the RAP configuration for the new M-SRB and M-DRB.

[00222] In step 5, the gNB sends a RAP reconfiguration request to the access relay UE on the path. The RAP reconfiguration request contains the new routing ID and RLC channel mapping configuration associated with the new M-SRB and M-DRB.

[00223] In step 6, the access relay UE configures RAP based on the RAP reconfiguration request. The access relay UE sends a RAP reconfiguration complete message to the gNB to confirm the RAP configuration for the new M-SRB and M-DRB.

[00224] In step 7/7a, the gNB activates the AS security with the UE via M-SRB 1.

[00225] In step 8, the gNB sends an M-RRC reconfiguration message via M-SRB 1 to the remote UE including the new M-SRB and M-DRB configurations. The M-RRC reconfiguration message also contains the RLC channel mapping configuration for the new M- SRB and M-DRB s.

[00226] In step 9, the remote UE establishes the new M-SRB and M-DRBs. The remote UE also configure its SL RLC channel based on the reconfiguration request message for each M- SRB and M-DRB.

[00227] In step 10, the remote UE sends an M-RRC Reconfiguration Complete message to gNB.

[00228] In step 11 , the gNB sends an initial context setup response message to informs the CN that the setup procedure is completed

[00229] Figure 24 is a call flow of an example procedure for creation new M-SRB s and M-DRBs to a relay UE initiated by the gNB. Steps 0-11 of Figure 24 are described below.

[00230] In step 0. A M-RRC connection, e.g., a M-SRB 1 has been already established.

[00231] In step 1, the gNB receives an initial context setup request from CN that contains UE context data (including PDU session context, the Security Key, UE Radio Capability and UE Security Capabilities, etc.). [00232] In step 2. In order to establish new M-SRB(s) and M-DRB(s), the gNB first selects a path for each M-SRB and M-DRB, the paths can be the same path as M-SRB 1 or could be a different path. After selecting the paths, the gNB assigns a new connection ID associated with each new M-SRB and M-DRB. The gNB then sends RAP Reconfiguration request to all relay UEs on the paths as in step 3-6. After configuring each relay UE, the gNB then sends a M- RRC reconfiguration message to the relay UE to configure M-DRBs as in step 8.

[00233] In step 3, the gNB sends a RAP reconfiguration request to the UE-to-NW Relay on the new path. The RAP reconfiguration request contains the new routing ID and RLC channel mapping configuration associated with the new M-SRB and M-DRB.

[00234] In step 4, the UE-to-NW Relay configures RAP based on the RAP reconfiguration request. The UE-to-NW Relay sends a RAP reconfiguration complete message to the gNB to confirm the RAP configuration for the new M-SRB and M-DRB.

[00235] In step 5, the gNB sends a RAP reconfiguration request to the access relay UE on the path. The RAP reconfiguration request contains the new routing ID and RLC channel mapping configuration associated with the new M-SRB and M-DRB.

[00236] In step 6, the access relay UE configures RAP based on the RAP reconfiguration request. The access relay UE sends a RAP reconfiguration complete message to the gNB to confirm the RAP configuration for the new M-SRB and M-DRB.

[00237] In step 7/7a, the gNB activates the AS security with the relay UE via M-SRB

1.

[00238] In step 8, the gNB sends an M-RRC reconfiguration message via M-SRB 1 to the relay UE including the new M-SRB and M-DRB configurations. The M-RRC reconfiguration message contains the new routing ID assigned to M-SRB and M-DRB and the RAP RLC channel mapping configuration for the new M-SRB and M-DRB.

[00239] In step 9, the relay UE establishes the new M-SRB and M-DRBs. The remote UE also configure its RAP by adding the new routing ID for each path associated with the M- SRB and M-DRB and add RAP RLC channel based on the reconfiguration request message for each M-SRB and M-DRB.

[00240] In step 10. The relay UE sends an M-RRC Reconfiguration Complete message to gNB. [00241] In step 11. The gNB sends an initial context setup response message to informs the CN that the setup procedure is completed

[00242] Methods to create one or more new Multi-hop DRBs that meet the QoS requirements including service continuity requirement for a new traffic flow

[00243] Methods may be used for creating one or more new Multi-hop DRBs to meet the QoS requirement including service continuity requirement for a new traffic flow. Figure 25 and Figure 26 shows an example message flow when the gNB receives a new QoS flow establishment request from CN. The QoS flow establishment request provides the gNB and UE with the QoS parameters for the QFI. Figure 27 shows an example message flow when the UE AS receives an UL packet for a new QoS flow for which a QFI to DRB mapping rule does not exist. In all these examples, the gNB decides to establish new DRB(s) for this QoS flow and provides the mapping rule over M-RRC signaling to the UE which may be a remote UE or a relay UE.

[00244] Figure 25 is a call flow of an example procedure for creation new M-DRBs for DL data with new QoS flow ID for a remote UE. Steps 0-11 of Figure 25 are described below.

[00245] In step 0, a session and M-DRB(s) have been already established.

[00246] In step 1 , the gNB receives a PDU session resource modify request for a new QoS flow after PDU session and M-DRB(s) has been established.

[00247] In step 2, If the gNB cannot find an existing M-DRB to map this new QoS flow, it decides to establish one or more new M-DRBs. The number of new M-DRBs to be established depends on the service continuity requirement of the QoS flow. In order to establish new M-DRB(s), the gNB first select one or more paths for the M-DRB(s), the paths can be a path of existing SRB or DRB and could be a different path. After select the paths, the gNB assigns a new connection ID associated with each new M-DRB. The gNB then sends RAP Reconfiguration request to all relay UEs on the paths as in step 3-6. After configuring each relay UE, the gNB then sends a M-RRC reconfiguration message to the remote UE to configure M- DRBs as in step 7.

[00248] In step 3, the gNB sends a RAP reconfiguration request to the Access Relay 2 on the new path 2. The RAP reconfiguration request contains the new routing ID and RLC channel mapping configuration associated with the new M-DRB 2. [00249] In step 4, the access relay UE 2 configures RAP based on the RAP reconfiguration request. The access relay UE 2 sends a RAP reconfiguration complete message to the gNB to confirm the RAP configuration for the new M-DRB 2.

[00250] In step 5, the gNB sends a RAP reconfiguration request to the access relay UE 1 on the path. The RAP reconfiguration request contains the new routing ID and RLC channel mapping configuration associated with the new M-DRB 1.

[00251] In step 6, the access relay UE 1 configures RAP based on the RAP reconfiguration request. The access relay UE sends a RAP reconfiguration complete message to the gNB to confirm the RAP configuration for the new M-DRB 1.

[00252] In step 7, the gNB sends an M-RRC reconfiguration message to the remote UE including the M-DRB s configurations with the new QFI to M-DRB(s) mapping rule and the NAS message received at step 1. In the mapping rules, the gNB may indicate the priority of these M-DRBs. For example, it can indicate one of M-DRB s as the default or primary M-DRB for the traffic flow and indicate other M-DRB as a backup or secondary M-DRB to use if the default or primary M-DRB is broken. The M-RRC reconfiguration message also contains the RLC channel mapping configuration for the new M-DRBs.

[00253] In step 8, the remote UE establishes the M-DRBs for the new QoS flow associated with this PDU session and updates the mapping rules. Based on the mapping rules, the remote UE may setup the priority of these M-DRBs. For example, it can setup one of M-DRBs as the default or primary M-DRB for the flow and indicate other M-DRB as a backup or secondary M-DRB to use in the case the default or primary M-DRB is broken. The remote UE also configure its SL RLC channel based on the reconfiguration request message for each M- DRB.

[00254] In step 9, the remote UE sends an M-RRC Reconfiguration Complete message to gNB.

[00255] In step 10. The gNB sends a PDU session resource modify response to the CN.

[00256] In step 11. User Plane Data can then be exchanged between the remote UE and the gNB over M-DRB(s) according to the mapping rules and between CN and gNB over the tunnel for the PDU session.

[00257] Figure 26 is a call flow of an example procedure for creation of new M-DRBs for DL data with new QoS flow ID for a relay UE. Steps 0-11 of Figure 26 are described below. [00258] In step 0, a PDU session and M-DRB(s) have been already established.

[00259] In step 1, the gNB receives a PDU session resource modify request for a new QoS flow after PDU session and M-DRB(s) has been established.

[00260] In step 2, if the gNB cannot find an existing DRB to map this new QoS flow, it decides to establish a new M-DRB. In order to meet the service continuity requirement of the QoS flow, a M-DRB can be setup over more than one path. The gNB first select one or more paths for the M-DRB, the paths can be a path of existing SRB or DRB and could be a different path. After selecting the paths, the gNB assigns a new connection ID associated with each path for the new M-DRB. The gNB then sends RAP Reconfiguration request to all relay UEs on the paths as in step 3-6. After configuring each relay UE, the gNB then sends a M-RRC reconfiguration message to the relay UE to configure the M-DRB as in step 7.

[00261] In step 3, the gNB sends a RAP reconfiguration request to the Access Relay 2 on the new path 2. The RAP reconfiguration request contains the new routing ID and RLC channel mapping configuration associated with the path 2 of the new M-DRB.

[00262] In step 4, the access relay UE 2 configures RAP based on the RAP reconfiguration request. The access relay UE 2 sends a RAP reconfiguration complete message to the gNB to confirm the RAP configuration for the new M-DRB.

[00263] In step 5, the gNB sends a RAP reconfiguration request to the access relay UE 1 on the new path 1, the RAP reconfiguration request contains the new routing ID and RLC channel mapping configuration associated with the path 1 of the new M-DRB.

[00264] In step 6, the access relay UE 1 configures RAP based on the RAP reconfiguration request. The access relay UE sends a RAP reconfiguration complete message to the gNB to confirm the RAP configuration for the new M-DRB.

[00265] In step 7, the gNB sends an M-RRC reconfiguration message to the relay UE including the M-DRB configurations with the new QFI to M-DRB mapping rule and the NAS message received at step 1. In the mapping rules, the gNB may indicate the priority of connections associated with the M-DRB. For example, it can indicate one of the connections as the default or primary connection for the M-DRB and indicate other connections as a backup or secondary connection to use if the default or primary connection is broken. The M-RRC reconfiguration message also contains the new routing ID and RLC channel mapping configuration for different connections associated with the new M-DRB. [00266] In step 8, the relay UE establishes the M-DRB with multiple connection for the new QoS flow associated with this PDU session and updates the mapping rules. Based on the RAP configurations, the relay UE may setup the priority of these connection. For example, it can setup one of the connections as the default or primary connection for the traffic flow and indicate other connections as a backup or secondary connection to use in the case the default or primary connection is broken. The relay UE also configures its RAP by adding the new routing ID for each connection associated with the M-DRB and RAP RLC channel based on the reconfiguration request message for each path associated with the M-DRB.

[00267] In step 9, the relay UE sends an M-RRC Reconfiguration Complete message to gNB.

[00268] In step 10. The gNB sends a PDU session resource modify response to the CN.

[00269] In step 11. User Plane Data can then be exchanged between the relay UE and the gNB over M-DRB(s) according to the mapping rules and between CN and gNB over the tunnel for the PDU session.

[00270] Figure 27 is a call flow of an example procedure for UL data with new QoS flow for which a mapping does not exist in the UE. Steps 0-7 of Figure 27 are described below.

[00271] In step 0. PDU session and M-DRBs (including a default M-DRB) have been already established.

[00272] In step 1. UE AS receives a packet with a new QFI from UE upper layers.

[00273] In step 2. UE uses the QFI of the packet to map it to a M-DRB. If there is no mapping of the QFI to a M-DRB in the AS mapping rules for this PDU session, then the packet is assigned to the default M-DRB.

[00274] In step 3. UE sends the UL packet on the default M-DRB. The UE includes the QFI in the SDAP header.

[00275] In step 4. gNB sends UL packets to CN and includes the corresponding QFI.

[00276] In step 5. If gNB wants to use a new M-DRB for this QoS flow, it sets up one. It can also choose to move the QoS flow to an existing M-DRB.

[00277] In step 6a-f. The gNB create a new or choose to move the QoS flow to an existing M-DRB by using procedures in Figure 26 and Figure 25. [00278] In step 6. User Plane Data for the new QoS flow can then be exchanged between UE and gNB over the M-DRB according to the updated mapping rules and between CN and gNB over the tunnel for the PDU session.

[00279] In step 7. UP Data (QFI) is exchanged.

[00280] Method for modifying a connection to meet the QoS requirement of a traffic flow including service continuity requirement

[00281] Methods may be used for the gNB or a UE to modify a connection to meet the QoS requirement of a traffic flow including service continuity requirement. In the first proposed method shown in Figure 28, a UE on the connection may detect that one of the links on the connection is broken or the quality of the link cannot meet the QoS requirement of the connection. The UE will send a connection modification notification message to the end node of the connection, e.g., the gNB, relay UEs and remote UEs, notifying the connection cannot fulfill the QoS requirement of the flow. The connection modification notification message may contain the routing ID associated with the connection. If there are multiple connections associated with the link, the connection modification notification message contains the routing ID of all connections. If the route is broken due to the link failure, the connection modification notification message can be sent via any path to the end node of the connection. When the gNB receives the connection modification notification, it may use a backup connection, e.g., a default or an existing connection or M-DRB for the traffic flow or set up new M-DRBs or connection as described. When the remote UE receives the connection modification notification, it may use a backup M-DRB for the traffic flow or use the default M-DRB to send the UP data as described to set up new M-DRBs or paths. When the relay UE receives the path modification notification, it may use a backup path or M-DRB for the traffic flow or use the default M-DRB to send UP data. See the discussion of Figures 25 through 27 for more details. M-RRC Reconfiguration procedure may be triggered by the gNB to switch to a backup M-DRB or connection to send UP Data.

[00282] In the second proposed method shown in Figure 29, a relay UE on the connection may detect one of link on the connection is broken when it is forwarding a packet along the connection. For example, receiving a transmission failure indication from a lower layer. The RAP of the UE may use an alternative connection to forward the packet to the destination. In order to achieve this, the RAP of the relay UE replaces the original routing ID in the RAP header using the routing ID of a new connection and keeps the original route ID in the RAP head as separated fields, and indicates the connection is changed due to a link failure. When the RAP of the destination node, e.g., the gNB, receives the message, its RAP re-map the message to the M-DRB using the original routing ID in the RAP header. The UE may also send a connection modification message to the originator of the message notifying the path is broken. The end node of the connection, e.g., the gNB, relay UEs and remote UEs, can modify the M- DBR and the connection using the same procedure described in step 3 to step 4 in Figure 28.

[00283] Signaling Procedures for Connection Release

[00284] Procedures are proposed for the gNB to release a M-RRC connection. Before the gNB sends a M-RRC release message to the UE, it first sends RAP reconfiguration requests to all relay UEs that are on all connections of existing M-SRBs and M-DRB s. In the RAP reconfiguration request, the gNB requests the relay UE to delete the connection ID and RAP RLC channel mapping configuration associated with the connection. Note that, the relay UE may keep the routing information between the gNB and the UE. The relay UE also keep some context information of the network, e.g., the ID of serving gNB and PLMN ID. After receiving the M- RRC release message, the UE releases M-RRC connection related context with the gNB, e.g., removes the M-SRB and M-DRB and related connections and RLC channel mapping configurations. The UE keeps the routing information to the gNB. For example, the access relay UE may store the RAP address assigned to the remote UE, the relay UE may store the assigned RAP address.

[00285] Figure 30 is a call flow of an example multi-hop RRC connection release procedure.

[00286] Procedure of multi-hop RRC connections re-establishment [00287] A UE may re-establish an RRC connection. The detail procedure for a remote UE to set up RRC connections is described in Figures 31 A-C. The detail procedure for a UE-to- UE Relay to set up RRC connections is describe in Figures 32 A-C. Note that a UE may also use the procedures in described in connection with Figures 18 through 21 to re-establish an RRC connection.

[00288] Figures 31A-C illustrate an example call flow for an initial connection, between a remote UE and the network when the access relay has a route to the network. Steps 1 - 13 Figures 31A-C are described below. [00289] In step 1, the remote UE sends "RRC setup request" to access relay UE. The “RRC setup request” is sent using a pre-configured PCS RLC channel. The remote UE may indicate the payload contains a “RRC setup request” to the gNB and it is a remote UE that does not have an adaptation layer and cannot have an adaptation layer address.

[00290] In step 2, when the access relay UE receives the message via a pre-configured PCS RLC channel, the adaptation layer adds Adapt layer Header including routing info, e.g., gNB RAP address as the destination address, the RAP address assigned to the remote UE as the source address.

[00291] In step 3, the adaptation layer of the access relay UE Relay forwards the RRC message to the next hop relay UE based on the routing configuration and destination address in the adaptation layer header.

[00292] In step 4, when the UE-to-NW Relay receives the message, its adaptation layer receives the packet from prior hop relay UE and then forwards it to the next hop relay UE based on the routing configuration and destination address in the adaptation layer header.

[00293] In step 5, the adaptation layer of UE-to-NW Relay forwards the RRC message to the gNB.

[00294] In step 6, the gNB removes the header of adaptation layer and receives the RRC Setup request message from the remote UE. From the RRC setup request message, the gNB knows the request is sent from a remote UE. The gNB generates a new connection ID for the new connection. The gNB also selects a path to the remote UE and configure the adaptation layer of each relay UEs on the path. The gNB selects a path to the remote UE and configures the adaptation layer of each relay UEs on the path. The gNB configure each relay UE on the path in step 6a-d.

[00295] In step 7, the gNB sends an RRC Setup message towards the remote UE and adds the adaptation layer header which includes essential routing information for the RRC message to the remote UE specified by the routing ID.

[00296] In step 8, when the UE-to-NW Relay receives the message, its adaptation layer receives the packet from ingress RLC channel and then maps it to the egress RLC channel based on routing ID and RLC channel mapping configuration.

[00297] In step 9, the adaptation layer of UE-to-NW Relay forwards the RRC message to the access relay UE. [00298] In step lO.The access relay UE removes the header of adaptation layer extracts the “RRC setup” message and forward it to the remote UE.

[00299] In step 11. The access relay UE forwards the “RRC setup” towards remote UE using a pre-configured PC5 RLC channel.

[00300] In step 12. The remote UE configures its AS context to support the new connection based on the information in the “RRC setup” and sends RRC setup complete towards the gNB using the new created connection, e.g., M-SRB 1.

[00301] In step 13. More subsequent steps for the remote UE to connect the network, such as the remote UE setups other M-SRBs and M-DRBs to the gNB that is described in connection with Figures 23 and 24.

[00302] Figures 3A-C illustrate an example call flow for an initial connection, between a UE -to-UE relay and the network when the access relay has a route to the network. Steps 1-13 Figures 32A-C are described below.

[00303] In step 1, the relay UE sends "RRC setup request" to the gNB and adds an adaptation layer header including routing info, e.g., gNB RAP address as the destination address, its own RAP address as the originator address. In the request the relay UE may indicate that it is a relay UE and has an adaptation layer and requests an adaptation layer address.

[00304] In step 2, when the Access Relay receives the message, its adaptation layer receives the packet from prior hop relay UE and then forwards it to the next hop relay UE based on the configuration and routing ID in the adaptation layer header.

[00305] In step 3, the access relay UE transmits the RRC message to the next hop relay UE towards gNB based on its routing configuration.

[00306] In step 4, when the UE-to-NW Relay receives the message, its adaptation layer receives the packet from prior hop relay UE and then forwards it to the next hop relay UE based on the configuration and routing ID in the adaptation layer header.

[00307] In step 5, the adaptation layer of UE-to-NW Relay forwards the RRC message to the gNB.

[00308] In step 6, the gNB removes the header of adaptation layer and receives the RRC Setup request message from the relay UE. From the RRC setup request message, the gNB knows the request is sent from a relay UE. The gNB generates a RAP connection ID for the new connection and configures the adaptation layer of each relay UEs on the path. The gNB configures each relay UE on the path in step 6a-d.

[00309] In step 7, the gNB sends an RRC Setup message towards the relay UE and adds the adaptation layer header which includes essential routing information for the RRC message specified by the routing ID associated with the relay UE. In the message, the gNB may also indicate the RAP routing ID assigned to the connection with the relay UE and the RLC channel mapping between the relay UE and the access relay UE.

[00310] In step 8, when the UE-to-NW Relay receives the message, its adaptation layer receives the packet from ingress RLC channel and then maps it to the egress RLC channel based on routing ID and RLC channel mapping configuration.

[00311] In step 9, the adaptation layer of UE-to-NW Relay forwards the RRC message to the access relay UE.

[00312] In step 10, when the Access Relay receives the message, its adaptation layer receives the packet from ingress RLC channel and then maps it to the egress RLC channel based on routing ID and RLC channel mapping configuration.

[00313] In step 11, the adaptation layer of the access relay UE forwards the RRC message to the relay UE.

[00314] In step 12, the relay UE configures its AS context to support the new connection based on the information in the “RRC setup” and sends RRC setup complete towards the gNB using the new created connection, e.g., M-SRB 1

[00315] In step 13, further actions are taken for the remote UE to connect the network, such as the relay UE setups other M-SRBs and M-DRBs to the gNB that is described in connection with Figures 23 and 24.

[00316] Example Frameworks

[00317] 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), and LTE-Advanced standards. 3GPP has begun working on the standardization of next generation cellular technology, called New Radio (NR), which is also referred to as “5G”. 3 GPP NR standards development is expected to include the definition of next generation radio access technology (new RAT), which is expected to include the provision of new flexible radio access below 6 GHz, and the provision of new ultra-mobile broadband radio access above 6 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 6 GHz, with cmWave and mmWave specific design optimizations.

[00318] 3 GPP 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 (e.g., broadband access in dense areas, indoor ultra-high broadband access, broadband access in a crowd, 50+ Mbps everywhere, ultra-low cost broadband access, mobile broadband in vehicles), critical communications, massive machine type communications, 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-Inffastructure Communication (V2I), V ehicle-to-N etwork 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, and virtual reality to name a few. All of these use cases and others are contemplated herein.

[00319] Figure 33 A illustrates one embodiment of an example communications system 100 in which the methods and apparatuses described and claimed herein may be embodied. As shown, the example communications system 100 may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, 102d, 102e, 102f, and/or 102g (which generally or collectively may be referred to as WTRU 102), a radio access network (RAN) 103/104/ 105/103b/ 104b/ 105b, a core network 106/107/109, a public switched telephone network (PSTN) 108, the Internet 11099 other networks 112, and V2X server (or ProSe function and server) 113, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements. Each of the WTRUs 102a, 102b, 102c, 102d, 102e, 102f, 102g may be any type of apparatus or device configured to operate and/or communicate in a wireless environment. Although each WTRU 102a, 102b, 102c, 102d, 102e, 102f, 102g is depicted in Figures 33 A-33E as 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 and/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, truck, train, or airplane, and the like.

[00320] The communications system 100 may also include a base station 114a and a base station 114b. Base stations 114a may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c to facilitate access to one or more communication networks, such as the core network 106/107/109, the Internet 110, and/or the other networks 112. Base stations 114b may be any type of device configured to wiredly and/or wirelessly interface with at least one of the RRHs (Remote Radio Heads) 118a, 118b, TRPs (Transmission and Reception Points) 119a, 119b, and/or RSUs (Roadside Units) 120a and 120b to facilitate access to one or more communication networks, such as the core network 106/107/109, the Internet 110, the other networks 112, and/or V2X server (or ProSe function and server) 113. RRHs 118a, 118b may be any type of device configured to wirelessly interface with at least one of the WTRU 102c, to facilitate access to one or more communication networks, such as the core network 106/107/109, the Internet 110, and/or the other networks 112. TRPs 119a, 119b may be any type of device configured to wirelessly interface with at least one of the WTRU 102d, to facilitate access to one or more communication networks, such as the core network 106/107/109, the Internet 110, and/or the other networks 112. RSUs 120a and 120b may be any type of device configured to wirelessly interface with at least one of the WTRU 102e or 102f, to facilitate access to one or more communication networks, such as the core network 106/107/109, the Internet 110, the other networks 112, and/or V2X server (or ProSe function and server) 113. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and/or network elements.

[00321] The base station 114a may be part of the RAN 103/104/105, which may also include other base stations and/or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114b may be part of the RAN 103 b/ 104b/ 105b, which may also include other base stations and/or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114a may be configured to transmit and/or receive wireless signals within a particular geographic region, which may be referred to as a cell (not shown). The base station 114b may be configured to transmit and/or receive wired and/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 station 114a may be divided into three sectors. Thus, in an embodiment, the base station 114a may include three transceivers, e.g., one for each sector of the cell. In an embodiment, the base station 114a may employ multiple-input multiple output (MIMO) technology and, therefore, may utilize multiple transceivers for each sector of the cell.

[00322] The base stations 114a may communicate with one or more of the WTRUs 102a, 102b, 102c over an air interface 115/116/117, 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 115/116/117 may be established using any suitable radio access technology (RAT).

[00323] The base stations 114b may communicate with one or more of the RRHs 118a, 118b, TRPs 119a, 119b, and/or RSUs 120a and 120b, over a wired or air interface 115b/ 116b/ 117b, 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 115b/l 16b/l 17b may be established using any suitable radio access technology (RAT).

[00324] The RRHs 118a, 118b, TRPs 119a, 119b and/or RSUs 120a, 120b, may communicate with one or more of the WTRUs 102c, 102d, 102e, 102f over an air interface 115c/l 16c/l 17c, 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 115c/l 16c/l 17c may be established using any suitable radio access technology (RAT).

[00325] The WTRUs 102a, 102b, 102c,102d, 102e, 102f, and/or 102g may communicate with one another over an air interface 115d/l 16d/l 17d (not shown in the figures), 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 115d/l 16d/l 17d may be established using any suitable radio access technology (RAT).

[00326] More specifically, as noted above, the communications system 100 may 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 station 114a in the RAN 103/104/105 and the WTRUs 102a, 102b, 102c, or RRHs 118a, 118b, TRPs 119a, 119b and RSUs 120a, 120b, in the RAN 103b/ 104b/ 105b and the WTRUs 102c, 102d, 102e, 102f, may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 115/116/117 or 115c/l 16c/l 17c respectively using wideband CDMA (WCDMA). WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and/or Evolved HSPA (HSPA+). HSPA may include High-Speed Downlink Packet Access (HSDPA) and/or High- Speed Uplink Packet Access (HSUPA).

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

[00328] In an embodiment, the base station 114a in the RAN 103/104/105 and the WTRUs 102a, 102b, 102c, or RRHs 118a, 118b, TRPs 119a, 119b and/or RSUs 120a, 120b, in the RAN 103b/ 104b/ 105b and the WTRUs 102c, 102d, 102e, 102 f may implement radio technologies such as IEEE 802.16 (e.g., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 IX, 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.

[00329] The base station 114c in Figure 33 A may 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 campus, and the like. In an embodiment, the base station 114c and the WTRUs 102e, may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In an embodiment, the base station 114c and the WTRUs 102d, may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114c and the WTRUs 102e, may utilize a cellular- based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish a picocell or femtocell. As shown in Figure 33A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114c may not be required to access the Internet 110 via the core network 106/107/109.

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

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

[00332] The core network 106/107/109 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d, 102e to access the PSTN 108, the Internet 110, and/or other networks 112. The PSTN 108 may include circuit-switched telephone networks that provide plain old telephone service (POTS). The Internet 110 may 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 networks 112 may include wired or wireless communications networks owned and/or operated by other service providers. For example, the networks 112 may include another core network connected to one or more RANs, which may employ the same RAT as the RAN 103/104/105 and/or RAN 103b/ 104b/ 105b or a different RAT.

[00333] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multi-mode capabilities, e.g., the WTRUs 102a, 102b, 102c, 102d, and 102e may include multiple transceivers for communicating with different wireless networks over different wireless links. For example, the WTRU 102e shown in Figure 33 A may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114c, which may employ an IEEE 802 radio technology.

[00334] Figure 33B is a block diagram of an example apparatus or device configured for wireless communications in accordance with the embodiments illustrated herein, such as for example, a WTRU 102. As shown in Figure 33B, the example WTRU 102 may include a processor 118, a transceiver 120, a transmit/receive element 122, a speaker/microphone 124, a keypad 126, a display/touchpad/indicators 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and other peripherals 138. It will be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment. Also, embodiments contemplate that the base stations 114a and 114b, and/or the nodes that base stations 114a and 114b may 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, and proxy nodes, among others, may include some or all of the elements depicted in Figure 33B and described herein.

[00335] The processor 118 may 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 processor 118 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit/receive element 122. While Figure 33B depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[00336] The transmit/receive element 122 may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 114a) over the air interface 115/116/117. For example, in an embodiment, the transmit/receive element 122 may be an antenna configured to transmit and/or receive RF signals. In an embodiment, the transmit/receive element 122 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, for example. In yet an embodiment, the transmit/receive element 122 may be configured to transmit and receive both RF and light signals. It will be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals.

[00337] In addition, although the transmit/receive element 122 is depicted in Figure 33B as a single element, the WTRU 102 may include any number of transmit/receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in an embodiment, the WTRU 102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 115/116/117. [00338] The transceiver 120 may be configured to modulate the signals that are to be transmitted by the transmit/ receive element 122 and to demodulate the signals that are received by the transmit/receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as UTRA and IEEE 802.11, for example.

[00339] The processor 118 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker/microphone 124, the keypad 126, and/or the display/touchpad/indicators 128 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display/touchpad/indicators 128. In addition, the processor 118 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and/or the removable memory 132. The non- removable memory 130 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In an embodiment, the processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

[00340] The processor 118 may receive power from the power source 134 and may be configured to distribute and/or control the power to the other components in the WTRU 102.

The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry cell batteries, solar cells, fuel cells, and the like.

[00341] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or in lieu of, the information from the GPS chipset 136, the WTRU 102 may receive location information over the air interface 115/116/117 from a base station (e.g., base stations 114a, 114b) and/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 WTRU 102 may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment. [00342] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and/or hardware modules that provide additional features, functionality and/or wired or wireless connectivity. For example, the peripherals 138 may 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.

[00343] The WTRU 102 may be embodied 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 airplane. The WTRU 102 may connect to 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 138.

[00344] Figure 33C is a system diagram of the RAN 103 and the core network 106 according to an embodiment. As noted above, the RAN 103 may employ a UTRA radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 115. The RAN 103 may also be in communication with the core network 106. As shown in Figure 33C, the RAN 103 may include Node-Bs 140a, 140b, 140c, which may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 115. The Node-Bs 140a, 140b, 140c may each be associated with a particular cell (not shown) within the RAN 103. The RAN 103 may also include RNCs 142a, 142b. It will be appreciated that the RAN 103 may include any number of Node-Bs and RNCs while remaining consistent with an embodiment.

[00345] As shown in Figure 33C, the Node-Bs 140a, 140b may be in communication with the RNC 142a. Additionally, the Node-B 140c may be in communication with the RNC 142b. The Node-Bs 140a, 140b, 140c may communicate with the respective RNCs 142a, 142b via an Iub interface. The RNCs 142a, 142b may be in communication with one another via an Iur interface. Each of the RNCs 142a, 142b may be configured to control the respective Node- Bs 140a, 140b, 140c to which it is connected. In addition, each of the RNCs 142a, 142b may 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.

[00346] The core network 106 shown in Figure 33C may include a media gateway (MGW) 144, a mobile switching center (MSC) 146, a serving GPRS support node (SGSN) 148, and/or a gateway GPRS support node (GGSN) 150. While each of the foregoing elements are depicted as part of the core network 106, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.

[00347] The RNC 142a in the RAN 103 may be connected to the MSC 146 in the core network 106 via an IuCS interface. The MSC 146 may be connected to the MGW 144. The MSC 146 and the MGW 144 may provide the WTRUs 102a, 102b, 102c with access to circuit- switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices.

[00348] The RNC 142a in the RAN 103 may also be connected to the SGSN 148 in the core network 106 via an IuPS interface. The SGSN 148 may be connected to the GGSN 150. The SGSN 148 and the GGSN 150 may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between and the WTRUs 102a, 102b, 102c and IP-enabled devices.

[00349] As noted above, the core network 106 may also be connected to the networks 112, which may include other wired or wireless networks that are owned and/or operated by other service providers.

[00350] Figure 33D is a system diagram of the RAN 104 and the core network 107 according to an embodiment. As noted above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 116. The RAN 104 may also be in communication with the core network 107.

[00351] The RAN 104 may include eNode-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-Bs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In an embodiment, the eNode-Bs 160a, 160b, 160c may implement MIMO technology. Thus, the eNode-B 160a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a. [00352] Each of the eNode-Bs 160a, 160b, and 160c may 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 and/or downlink, and the like.

As shown in Figure 33D, the eNode-Bs 160a, 160b, 160c may communicate with one another over an X2 interface.

[00353] The core network 107 shown in Figure 33D may include a mobility management gateway (MME) 162, a serving gateway 164, and a packet data network (PDN) gateway 166. While each of the foregoing elements are depicted as part of the core network 107, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.

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

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

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

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

[00358] Figure 33E is a system diagram of the RAN 105 and the core network 109 according to an embodiment. The RAN 105 may be an access service network (ASN) that employs IEEE 802.16 radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 117. As will be further discussed below, the communication links between the different functional entities of the WTRUs 102a, 102b, 102c, the RAN 105, and the core network 109 may be defined as reference points.

[00359] As shown in Figure 33E, the RAN 105 may include base stations 180a, 180b,

180c, and an ASN gateway 182, though it will be appreciated that the RAN 105 may include any number of base stations and ASN gateways while remaining consistent with an embodiment.

The base stations 180a, 180b, 180c may each be associated with a particular cell in the RAN 105 and may include one or more transceivers for communicating with the WTRUs 102 a, 102b, 102c over the air interface 117. In an embodiment, the base stations 180a, 180b, 180c may implement MIMO technology. Thus, the base station 180a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a. The base stations 180a, 180b, 180c may also provide mobility management functions, such as handoff triggering, tunnel establishment, radio resource management, traffic classification, quality of service (QoS) policy enforcement, and the like. The ASN gateway 182 may serve as a traffic aggregation point and may be responsible for paging, caching of subscriber profiles, routing to the core network 109, and the like.

[00360] The air interface 117 between the WTRUs 102a, 102b, 102c and the RAN 105 may be defined as an R1 reference point that implements the IEEE 802.16 specification. In addition, each of the WTRUs 102a, 102b, and 102c may establish a logical interface (not shown) with the core network 109. The logical interface between the WTRUs 102a, 102b, 102c and the core network 109 may be defined as an R2 reference point, which may be used for authentication, authorization, IP host configuration management, and/or mobility management. [00361] The communication link between each of the base stations 180a, 180b, and 180c may be defined as an R8 reference point that includes protocols for facilitating WTRU handovers and the transfer of data between base stations. The communication link between the base stations 180a, 180b, 180c and the ASN gateway 182 may be defined as an R6 reference point. The R6 reference point may include protocols for facilitating mobility management based on mobility events associated with each of the WTRUs 102a, 102b, 102c.

[00362] As shown in Figure 33E, the RAN 105 may be connected to the core network 109. The communication link between the RAN 105 and the core network 109 may defined as an R3 reference point that includes protocols for facilitating data transfer and mobility management capabilities, for example. The core network 109 may include a mobile IP home agent (MIP-HA) 184, an authentication, authorization, accounting (AAA) server 186, and a gateway 188. While each of the foregoing elements are depicted as part of the core network 109, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.

[00363] The MIP-HA may be responsible for IP address management, and may enable the WTRUs 102a, 102b, and 102c to roam between different ASNs and/or different core networks. The MIP-HA 184 may provide the WTRUs 102a, 102b, 102c with access to packet- switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP -enabled devices. The AAA server 186 may be responsible for user authentication and for supporting user services. The gateway 188 may facilitate interworking with other networks. For example, the gateway 188 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. In addition, the gateway 188 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired or wireless networks that are owned and/or operated by other service providers.

[00364] Although not shown in Figure 33E, it will be appreciated that the RAN 105 may be connected to other ASNs and the core network 109 may be connected to other core networks. The communication link between the RAN 105 the other ASNs may be defined as an R4 reference point, which may include protocols for coordinating the mobility of the WTRUs 102a, 102b, 102c between the RAN 105 and the other ASNs. The communication link between the core network 109 and the other core networks may be defined as an R5 reference, which may include protocols for facilitating interworking between home core networks and visited core networks.

[00365] The core network entities described herein and illustrated in Figures 33A, 33C, 33D, and 33E are identified by the names given to those entities in certain existing 3 GPP 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 3 GPP NR specifications. Thus, the particular network entities and functionalities described and illustrated in Figures 33A-33E are 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.

[00366] Figure 33F is a block diagram of an example computing system 90 in which one or more apparatuses of the communications networks illustrated in Figures 33 A, 33C, 33D, and 33E may be embodied, such as certain nodes or functional entities in the RAN 103/104/105, Core Network 106/107/109, PSTN 108, Internet 110, or Other Networks 112. Computing system 90 may 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 91, to cause computing system 90 to do work. The processor 91 may 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 processor 91 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the computing system 90 to operate in a communications network. Coprocessor 81 is an optional processor, distinct from main processor 91, that may perform additional functions or assist processor 91. Processor 91 and/or coprocessor 81 may receive, generate, and process data related to the methods and apparatuses disclosed herein. [00367] In operation, processor 91 fetches, decodes, and executes instructions, and transfers information to and from other resources via the computing system’s main data-transfer path, system bus 80. Such a system bus connects the components in computing system 90 and defines the medium for data exchange. System bus 80 typically 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 bus 80 is the PCI (Peripheral Component Interconnect) bus.

[00368] Memories coupled to system bus 80 include random access memory (RAM) 82 and read only memory (ROM) 93. Such memories include circuitry that allows information to be stored and retrieved. ROMs 93 generally contain stored data that cannot easily be modified. Data stored in RAM 82 may be read or changed by processor 91 or other hardware devices. Access to RAM 82 and/or ROM 93 may be controlled by memory controller 92. Memory controller 92 may provide an address translation function that translates virtual addresses into physical addresses as instructions are executed. Memory controller 92 may 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.

[00369] In addition, computing system 90 may contain peripherals controller 83 responsible for communicating instructions from processor 91 to peripherals, such as printer 94, keyboard 84, mouse 95, and disk drive 85.

[00370] Display 86, which is controlled by display controller 96, is used to display visual output generated by computing system 90. 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). Display 86 may 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 controller 96 includes electronic components required to generate a video signal that is sent to display 86.

[00371] Further, computing system 90 may contain communication circuitry, such as for example a network adapter 97, that may be used to connect computing system 90 to an external communications network, such as the RAN 103/104/105, Core Network 106/107/109, PSTN 108, Internet 110, or Other Networks 112 of Figures 33A-33E, to enable the computing system 90 to communicate with other nodes or functional entities of those networks. The communication circuitry, alone or in combination with the processor 91 , may be used to perform the transmitting and receiving steps of certain apparatuses, nodes, or functional entities described herein.

[00372] Figure 33G illustrates one embodiment of an example communications system 111 in which the methods and apparatuses described and claimed herein may be embodied. As shown, the example communications system 111 may include wireless transmit/receive units (WTRUs) A, B, C, D, E, F, a base station, a V2X server, and a RSUs A and B, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements. One or several or all WTRUs A, B, C, D, E can be out of range of the network. In this example, the out of the cell coverage boundary is shown with a dashed line. WTRUs A, B, C form a V2X group, among which WTRU A is the group lead and WTRUs B and C are group members. WTRUs A, B, C, D, E, F may communicate over Uu interface or Sidelink (PCS) interface.

[00373] 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 processors 118 or 91 , cause the processor to perform and/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 and/or wired network communications. Computer readable storage media include 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.

Claims

CLAIMS We claim:

1. An apparatus, comprising a processor, a memory, communication circuitry, and instructions stored in the memory which, when executed by the processor, cause the apparatus to: determine to use an indirect network connection path between the apparatus and a base station (gNB), rather than a direct network connection path to the gNB; discover one or more candidate relay User Equipments (UEs); select, from the one or more candidate relay UEs, a selected relay UE; establish a PCS connection to the selected relay UE, thereby creating the indirect network connection path between the UE and the gNB; establish, via the indirect network connection path, a first Radio Resource Control (RRC) connection to the gNB; and maintain the first RRC connection to fulfill a first quality-of-service (QoS) requirement of an existing traffic flow and/or a new traffic flow of the apparatus.

2. The apparatus of claim 1, wherein the instructions further cause the apparatus to: send, to one or more neighbour UEs, a relay discovery request message comprising a relay selection criterion and/or a path selection criterion; receive a relay discovery response message comprising relay selection context information and/or a path selection context information; and select, based on the relay selection criteria and/or the relay selection context information, the selected relay UE.

3. The apparatus of claim 1 , wherein the instructions further cause the apparatus to select, based on the path selection criteria and the path selection context information, the indirect path to the gNB through the selected relay UE.

4. The apparatus of claim 2 or claim 3, where the path selection criterion, the path selection context information, the relay selection criterion, and the relay selection context information comprise one or more of the following: a PLMN ID, a gNB ID, a relay UE RRC connection state, a power status, a second QoS requirement, a relay UE capability, a capability of the apparatus, a relay load, a link quality, a relay available uplink capacity, a backhaul load in terms of backhaul free capacity, a relay available downlink capacity, a fronthaul load in terms of fronthaul free capacity resource allocation information, and a number of hops towards the gNB.

5. The apparatus of claim 1, wherein the instructions further cause the apparatus to: send, over the PC5 connection to the selected relay UE, an RRC connection request that is directed towards the gNB along the indirect path; receive, over the PC5 connection from the selected relay UE, an RRC setup message that is sent from the gNB along the indirect path; configure an Access Stratum (AS) context of the apparatus in accordance with the RRC setup message; establish, via the AS context, the first RRC connection to the gNB, wherein the first RRC connection comprises a first Signalling Radio Bearer (SRB); and send, over the PC5 connection to the selected relay UE, an RRC setup complete message that is directed toward the gNB along the indirect path.

6. The apparatus of claim 5, wherein the RRC connection request comprises an indication of whether the apparatus comprises an adaptation layer.

7. The apparatus of claim 5, wherein the apparatus is a remote UE having no adaptation layer.

8. The apparatus of claim 5, wherein the apparatus is a remote UE comprising an adaptation layer.

9. The apparatus of claim 5, wherein the apparatus is a relay UE comprising an adaptation layer.

10. The apparatus of claim 8 or claim 9, wherein the RRC setup message comprises an adaptation protocol layer configuration, the adaptation protocol layer configuration comprising one or more of: a UE adaptation protocol layer address, a Radio Link Control (RLC) channel mapping configuration, and a routing ID.

11. The apparatus of claim 9, wherein the instructions further cause the apparatus to: select and use the direct path to gNB; and receive an RRC reconfiguration message comprising an adaptation protocol layer configuration for a new or modified RRC connection of a remote UE that uses the apparatus in a path of the remote UE to the gNB.

12. The apparatus of claim 1 , wherein the UE receives, over the PC5 connection from the selected relay UE, an RRC release message that is sent from the gNB along the indirect path.

13. The apparatus of claim 12, wherein the apparatus further comprises an adaptation layer and the instructions further cause the apparatus to: remove, from the AS context of the apparatus and in response the RRC release message, a Signalling Radio Bearer (SRB) context configuration and a Data Radio Bearer (DRB) context configuration, an adaptation layer context configuration comprising a routing ID and a Radio Link Control (RLC) channel mapping configuration associated with the first RRC connection; and retain, after processing the RRC release message, routing information regarding a path to the gNB, the routing information comprising an adaptation layer address of the apparatus, an adaptation layer address of the selected relay UE, and an adaptation layer address of the gNB.

14. The apparatus of claim 9, wherein the instructions further cause the apparatus to assist a child UE in: acquiring system information; selecting the gNB as a serving gNB of the child UE; discovering one or more candidate paths to the gNB; establishing a second RRC connection to the gNB, the second RRC connection comprising the indirect path to the gNB; and/or assisting the child UE to maintain the second RRC connection to fulfill a third QoS requirement of an existing and/or a new traffic flow of the child UE.

15. The apparatus of claim 9, wherein the instructions further cause the apparatus to: receive, in the RRC setup message or an RRC reconfiguration message, adaptation protocol layer configuration information; configure the adaptation layer of the apparatus in accordance with the adaptation protocol layer configuration information; add, to packets received from a child remote UE, an adaptation protocol header; receive traffic on an ingress Relay Radio Link Control channel, and route the traffic to an egress Relay Radio Link Control channel, based on a Radio Link Control channel mapping configuration; manage a routing ID of the child remote UE; and/or determine whether a packet is destinated to the child remote UE.

16. The apparatus of 9, wherein the instructions further cause the apparatus to: send, to the gNB, a UE relay context report comprising a UE ID for the apparatus and information regarding discovered neighbor UEs of the apparatus; receive an RRC reconfiguration message comprising new SRB and DRB AS context configurations, the new SRB and DRB AS context configurations comprising a QoS Flow Identifier (QFI) to DRB mapping rule, wherein the QFI to DRB mapping rule comprises a priority of one or more DRB and further comprises an adaptation layer configuration pertaining to a new SRB and one or more new DRBs; and send, to the gNB, an RRC reconfiguration complete message that confirms the new SRB and DRB AS context configurations .

17. The apparatus of 16, wherein the instructions further cause the apparatus to send the UE relay context report periodically, after receiving a UE relay context request message from the gNB, after setting up an RRC connection with the gNB, and/or after UE relay context information changes.

18. The apparatus of 16, wherein the UE relay context report comprises only UE relay context information that has changed since a last reporting.

19. The apparatus of claim 9, wherein the instructions further cause the apparatus to: receive an RRC connection modification notification comprising a routing ID, the routing ID being associated with a path that cannot meet a service continuity QoS requirement; and select, in response to the RRC connection modification notification, a new DRB or a new path for the traffic flow for the RRC connection.

20. The apparatus of claim 9, wherein the instructions cause the adaptation layer of the apparatus to: determine, based on a first path being unable to fulfill the first QoS requirement, to use an alternative path to forward a packet to a destination; replace, in the packet, an original routing ID in a Relay Adaptation Protocol (RAP) header with a routing ID of the alternative path; send, to the destination, the packet, wherein the packet comprises, in separated fields of the RAP header, the routing ID of the alternative path, the original routing ID, and an indication of a change in path.

21. A method performed by a base station apparatus (gNB), the method comprising: establishing, via an indirect network connection path, an RRC connection between a first User Equipment (UE) and the gNB; configuring an adaptation layer of a second UE, the second UE being part of the indirect network connection path to the first UE; if the first UE has an adaptation layer, configuring the adaptation layer of the first UE; and maintaining the RRC connection to fulfill a quality-of-service (QoS) requirement of an existing and/or a new traffic flow.