Dynamic User Plane Management

Abstract

A method for dynamic user plane management may include a new Layer 2 architecture to support simultaneous user plane direct and indirect connections between a remote UE and a gNB. A method for dynamically managing a UP plane connection based on QoS requirements of traffic flows and power consumption requirements of the remote UE is described. A method for dynamically managing a CP connection between a remote UE and a remote UE via a direct CP connection is described. A method for dynamically managing a CP connection between a remote UE and a remote UE via an indirect CP connection is described.

Description

Technical Field

[0001] (Cross - reference to related applications) This application claims the benefit of U.S. Provisional Patent Application No. 63 / 168,547, filed on March 31, 2021, entitled "Methods And Apparatus For Dynamic User Plane Management", the content of which is incorporated herein by reference.

Background Art

[0002] As described in 3GPP TR 36.836 V2.0.0 Study on NR Sidelink Relay (Release 17), the first version of NR Sidelink has been developed that focuses only on supporting V2X - related road safety services in Release 16. This design aims to provide support for broadcast, group - cast, and unicast communications in both out - of - coverage scenarios and in - network coverage scenarios.

Summary of the Invention

[0003] This specification describes methods, apparatuses, and systems for dynamic user plane management. In one aspect, a new Layer 2 (L2) architecture for supporting simultaneous user plane (UP) direct and indirect connections between a remote UE and a gNB is described.

[0004] In another aspect, methods for dynamically managing user plane connections based on the QoS requirements of traffic flows and the power consumption requirements of remote UEs are described. In one example, a method for dynamically managing the UP connection between a remote UE and a gNB via a direct control plane (CP) connection is described. In another example, a method for dynamically managing the UP connection between a remote UE and a gNB via an indirect CP connection is described.

[0005] This summary is provided to introduce a selection of concepts in a simplified form, which is further described below in “Modes for Carrying Out the Invention.” This summary is not intended to identify any major 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 features that resolve any or all of the defects described in any part of this disclosure. [Brief explanation of the drawing]

[0006] The embodiments for carrying out the following invention will be better understood when read in conjunction with the attached drawings. In the drawings, [Figure 1] This shows a user-plane protocol stack for L2 UE network relay. [Figure 2] This shows a control plane protocol stack for L2 UE network relay. [Figure 3] This shows another user-plane protocol stack for L2 UE network relay. [Figure 4] This shows another control plane protocol stack for L2 UE network relay. [Figure 5] An exemplary use case is shown. [Figure 6] Examples of simultaneous user plane connections via direct and indirect routes are shown. [Figure 7] Examples of a control plane via a direct path and a user plane via an indirect path are shown. [Figure 8] Examples of a control plane via an indirect path and a user plane via a direct path are shown. [Figure 9] This example shows user plane connectivity management when the control plane is directly on the path. [Figure 10] This example shows user plane connectivity management when the control plane is on an indirect path. [Figure 11]Examples of multiple user plane connections in the PDCP layer via direct and indirect routes are shown. [Figure 12] Examples of multiple user-plane connections in the RLC layer via direct and indirect routes are shown. [Figure 13] This document illustrates an exemplary method for dynamically managing the UP connection between a gNB and a remote UE via a direct CP connection. [Figure 14] This document illustrates an exemplary method for dynamically managing the UP connection between a gNB and a remote UE via an indirect CP connection. [Figure 15A] An example communication system is shown. [Figure 15B] An exemplary Radio Access Network (RAN) and core network are shown. [Figure 15C] An exemplary radio access network (RAN) and core network are shown. [Figure 15D] An exemplary radio access network (RAN) and core network are shown. [Figure 15E] Another exemplary communication system is shown. [Figure 15F] An example of a communication device or apparatus is shown. [Figure 15G] This illustrates an exemplary computing system. [Modes for carrying out the invention]

[0007] As described in 3GPP TR 36.836 V2.0.0 Study on NR Sidelink Relay (Release 17), the first version of NR Sidelink was developed in Release 16, focusing solely on supporting V2X-related road safety services. This design aims to provide support for broadcast, groupcast, and unicast communications in both out-of-coverage and in-network coverage scenarios.

[0008] To further explore coverage extension for sidelink-based communication, coverage extension from the UE to the network or from the UE to the UE may be considered.

[0009] Regarding UE-network coverage extension, Uu coverage reachability is required for the UE to reach a server within the PDN network or a corresponding UE outside the proximity area. However, the Release 13 solution regarding UE-network relay is limited to EUTRA-based technologies and is not applicable to the NR-based system for both NG-RAN and NR-based sidelink communication.

[0010] Regarding UE-to-UE coverage extension, the current proximity reachability is limited to a single hop of sidelink communication via either EUTRA-based or NR-based sidelink technology. However, considering the limited single-hop sidelink coverage, it is not sufficient in scenarios where there is no Uu coverage and satellite coverage.

[0011] Overall, sidelink connectivity can be further extended in the NR framework to support extended QoS requirements.

[0012] The protocol stacks for the user plane and control plane of the L2 UE-network relay architecture are shown in FIGS. 1 and 2 for the case where the adaptation layer is not supported at the PC5 interface, and in FIGS. 3 and 4 for the case where the adaptation layer is supported at the PC5 interface.

[0013] In the case of an L2 inter-UE network relay, the adaptation layer is placed above the RLC sublayer for both the control plane (CP) and the user plane (UP) at the Uu interface between the relay UE 202 and the gNB 203. Uu SDAP / PDCP and RRC are terminated between the remote UE 201 and the gNB 203, and RLC, MAC, and PHY are terminated at each link (e.g., the link between the remote UE 201 and the inter-UE network relay UE 202, and the link between the inter-UE network relay UE 202 and the gNB 203). Whether the adaptation layer is also supported at the PC5 interface between the remote UE 201 and the relay UE 202 is left to the WI phase (assuming a downselection first before overly verifying the detailed PC5 adaptation layer functionality).

[0014] Figure 5 shows an exemplary use case where the remote UE 201 is within the coverage of the same cell as the relay UE 202.

[0015] The Release 17 sidelink relay design decision can support a remote UE202 that may have a direct Uu connection or a connection via a single relay UE201, but these two connections should not be active simultaneously. In other words, this design decision restricts (e.g., prevents) a remote UE201 from having a user plane simultaneously via both direct and indirect paths, as shown in Figure 6. Simultaneous connections via direct and indirect paths can provide reliable communication to the remote UE201. Furthermore, the Release 17 sidelink relay design also restricts control plane connections and user plane connections from using the same path. Power consumption of the remote UE201 can be reduced by routing control plane and user plane connections via different paths. This is because, for example, power can be saved by routing user plane traffic through closer relay nodes for shorter-distance transmissions while keeping control plane traffic on the direct path. This user-plane and control-plane splitting also provides latency reduction flexibility by eliminating the possibility of retransmission and thus reducing the overall latency of data packets, while keeping control-plane traffic, which typically has lower data rates on the direct path, routed through nearby relay nodes using shorter transmission distances and better radio conditions. For example, as shown in Figure 7, in a scenario where the remote UE201 has control-plane connectivity via a direct path and user-plane connectivity via an indirect path, the remote UE201 is closer to the relay UE202 than the gNB203, thus reducing power consumption. Another example is a scenario where the remote UE201 has control-plane connectivity via an indirect path and user-plane connectivity via a direct path, as shown in Figure 8. Since the remote UE201 is one hop away from the gNB203, it is possible to reduce the transmission latency that may occur for user-plane traffic while using the indirect path for control traffic with lower data rates on the indirect path.

[0016] A consideration is that current 5G architectures do not support simultaneous user plane connections via direct and indirect routes. This specification discloses an architecture that supports a remote UE201 to have at least a direct or indirect user plane connection. The remote UE201 may transmit the same traffic using both direct and indirect connections to enhance the reliability of the communication. The remote UE201 may also transmit different traffic using either direct or indirect connections to meet QoS or power consumption requirements.

[0017] Further consideration is that a new user plane management procedure is required to support simultaneous user plane connections. As shown in Figure 9, in scenarios where the control plane is on the direct path, the remote UE201 must dynamically manage its own user plane connections on the direct or indirect path. As shown in Figure 10, in scenarios where the control plane is on the indirect path, the remote UE must dynamically manage its own user plane connections on the direct or indirect path. For example, verify the trigger events of the user plane management procedure. How to select a user plane path to meet the QoS requirements of the traffic flow and the capability requirements of the remote UE201. Configuration of the remote UE201 and relay UE202 via the direct or indirect path to meet the QoS requirements of the traffic flow.

[0018] Taking these points into consideration, this specification describes methods, apparatus, or systems for dynamic user plane management.

[0019] One embodiment describes a Layer 2 architecture for supporting simultaneous user-plane direct and indirect connections between a remote UE201 and a gNB203.

[0020] In another aspect, a method for dynamically managing UP plane connections based on traffic flow QoS requirements and power consumption requirements of the remote UE201 is described. One example describes a method for dynamically managing the UP connection between the remote UE201 and the gNB203 via a direct CP connection. Another example describes a method for dynamically managing the UP connection between the remote UE201 and the gNB203 via an indirect CP connection.

[0021] Hereinafter, the term UP connection may be understood as the connection between a remote UE201 and a gNB203 carrying user plane information, and may consist of one or more Data Radio Bearers (DRBs) between the remote UE201 and the gNB203 (which may be communicated between one or more hops). Hereinafter, the terms UP connection and DRB connection may be used interchangeably. Similarly, hereinafter, the term CP connection may be understood as the connection between a remote UE201 and a gNB203 carrying control plane information, and may consist of one or more Signaling Radio Bearers (SRBs) between the remote UE201 and the gNB203 (which may be communicated between one or more hops). Hereinafter, the terms CP connection and SRB connection may be used interchangeably. Furthermore, although this specification refers to the gNB203, any base station may be applicable.

[0022] In the following, the term "direct connection" may be understood as a connection using a direct route. For example, communication between gNB203 and remote UE201 takes place via the Uu interface. Similarly, the term "indirect connection" may be understood as a connection using an indirect route. For example, communication between gNB203 and remote UE201 takes place via relay UE202.

[0023] Architecture that supports dynamic user plane connections Hereafter, the term "connection" also applies to various protocol layers of the UE access layer. For example, refer to an SDAP connection or a PDCP connection. This term is primarily used to describe the endpoint or termination point of these protocols. Therefore, an SDAP connection between remote UE201 and gNB203 suggests that the remote UE and gNB203 are the termination points of the SDAP protocol.

[0024] Multiple architectures for supporting dynamic user plane connectivity are described. In the first disclosed architecture shown in Figure 11, the remote UE201 and gNB203 have one common SDAP layer connection. However, they have direct end-to-end connections at the PDCP, RLC, MAC, or PHY layers, and indirect end-to-end connections at the PDCP layer, and indirect hop-by-hop connections at the adaptation, RLC, MAC, or PHY layers. For example, SDAP is Uu-SDAP, PDCP1 is Uu-PDCP, RLC1 is Uu-RLC, MAC1 is Uu-MAC, and PHY1 is Uu-PHY. PDCP2 is Uu-PDCP, RLC2 is PC5-RLC, MAC2 is PC5-MAC, or PHY2 is PC5-PHY.

[0025] In the second disclosed architecture shown in Figure 12, the remote UE201 and gNB203 have one common SDAP and PDCP layer connection. However, they also have direct end-to-end connections at the RLC, MAC, or PHY layers, as well as indirect hop-by-hop connections at the adaptation, RLC, MAC, or PHY layers. In this example, RLC1 is Uu-RLC, MAC1 is Uu-MAC, and PHY1 is Uu-PHY. RLC2 is PC5-RLC, MAC2 is PC5-MAC, or PHY2 is PC5-PHY.

[0026] User Plane Management This specification describes a new user plane management method for supporting dynamic user plane connections.

[0027] Dynamic UP connection management via direct route In a scenario where the control plane is directly on the path, as shown in Figure 9, the gNB203 can dynamically manage its own user plane connections between remote UE201s, as shown in Figure 13.

[0028] Referring to Figure 13, the remote UE201 and gNB203 may perform the following steps to (re)establish or release the UP connection.

[0029] In step 210a, the remote UE201 establishes an SRB connection with the gNB203 via a direct path, and the remote UE201 may also establish an UP connection with the gNB203 via a direct or indirect path.

[0030] In step 210b, gNB203 may send an RRC message to the remote UE201 to configure the remote UE201 to measure and report UP route selection context information via the direct route. gNB203 may configure the remote UE201 to report information periodically or when a configured threshold is exceeded for changes in context information.

[0031] In step 210c, the remote UE201 may send an RRC message to the gNB203 to report UP route selection context information via the direct route. Hereinafter, this context information may be referred to as route selection context information. The UP route selection context information may include information on a list of candidate relay UEs. This information may include, among other things, a list of UEs suitable to operate as relay UEs (e.g., a list of UE IDs of UEs that meet threshold metrics for operating as relay UEs), the preference of relay UE202 (e.g., relay UE202 with the highest capacity), the relay UE202 with the best signal quality, the battery status of the remote UE201, the battery status of relay UE202, the power saving requirements of the remote UE201, or the power saving requirements of relay UE202.

[0032] In step 210d, gNB203 may send an RRC message to relay UE202 to configure relay UE202 to measure and report UP route selection context information.

[0033] In step 210e, relay UE202 may send an RRC message to gNB203 to report UP route selection context information. The UP route selection context information may include its traffic load (e.g., channel busy ratio), battery status, and the number of remote UE201s that use the UE as relay UE202.

[0034] In step 211, gNB203 is triggered to (re)establish or release the UP connection with the remote UE201. UP connection (re)establishment or release may be triggered when receiving a PDU SESSION RESOURCE MODIFY REQUEST message (or another message) from AMF for a new QoS flow, or a PDU SESSION RESOURCE SETUP REQUEST message from AMF. UP connection establishment may be triggered when gNB203 receives a new traffic flow from the remote UE201 and the existing connection cannot meet the QoS requirements (e.g., QoS thresholds) for the traffic flow. UP connection re-establishment may be triggered when the existing UP connection is disconnected or cannot meet the QoS requirements.

[0035] In step 212, based on QoS requirements, gNB203 may select a route to (re)establish or release the UP connection. For example, if using an indirect route satisfies the flow's latency requirements and requires the remote UE201 to minimize power consumption, gNB203 may select relay UE202 to establish the UP connection over the indirect route. The remote UE201 may provide gNB203 with a metric to use in selecting relay UE201. For example, the metric may be the available capacity at relay UE202. gNB203 may select the relay UE202 with the largest available capacity. In another example, the metric may be the channel load between remote UE201 and relay UE202, or the channel load between relay UE202 and gNB203. The load may be the channel busy ratio. gNB203 may select the relay UE202 with the lowest channel load. In yet another example, if using an indirect route cannot satisfy the flow's latency requirements, gNB203 may select a direct route to establish the UP connection. In yet another example, if neither the direct nor the indirect route can meet the flow's reliability requirements, the gNB203 may select both the direct and indirect routes and send duplicate packets on both routes to meet the reliability requirements. In a scenario where the remote UE201 has UP connections to both the direct and indirect routes, and using the indirect route can meet the flow's latency requirements, and the remote UE201 requires minimizing power consumption, the gNB203 may release the direct route. In yet another example, if using the indirect route cannot meet the flow's latency requirements, the gNB203 may release the UP connection on the indirect route.

[0036] In step 213, to establish or release an UP connection via an indirect path, the gNB203 may send user plane connection configuration information to the selected relay UE202. The transmission may be performed via an RRC reconfiguration message to the selected relay UE202. For establishing an UP connection, the RRC reconfiguration message may include the bearer ID, the remote UE ID, and the RLC channel mapping configuration associated with the new connection. The RRC reconfiguration message may also include QoS requirements for the traffic flow. For releasing an UP connection, the RRC reconfiguration message may include the bearer ID, the remote UE ID, or the RLC channel mapping configuration associated with the connection to be released. The user plane connection configuration information may include the bearer identifier (ID), the UE ID of the device (e.g., the remote UE or relay UE), the Radio Link Control (RLC) channel mapping configuration associated with the new sidelink connection, or the Quality of Service (QoS) requirements for the traffic flow.

[0037] In step 214, relay UE202 may configure its adaptation layer based on the RRC reconfiguration message. Relay UE202 may send an RRC reconfiguration complete message to gNB203 to confirm the configuration for the UP connection.

[0038] In step 215, gNB203 may send user plane connection configuration information to the remote UE201. This transmission may be performed via an RRC reconfiguration message to the remote UE201 via the Uu interface. To establish a UP connection via an indirect path, the RRC reconfiguration message may include an indirect path configuration instruction, a bearer ID (e.g., DRB ID), a selected relay UE ID, and an RLC channel mapping configuration associated with the new connection. The RRC reconfiguration message may also include QoS requirements for the traffic flow for the remote UE201 to establish a PC5 connection with the selected relay UE202. To establish a UP connection via a direct path, the RRC reconfiguration message may include a legacy Uu UP configuration.

[0039] In step 216, based on the information received from the RRC reconfiguration message in step 215, the remote UE201 or relay UE202 may establish a sidelink UP, or release the sidelink UP if the existing sidelink UP cannot meet the QoS requirements of the new traffic flow.

[0040] In step 217, after the new UP connection is established, the remote UE201 may map the data flow packets to one or more PDCP entities, one of which may be a Uu-PDCP or a PC5 PDCP. The remote UE201 may also map the data flow packets to the same PDCP entities, but one or more RLC entities, one of which may be a Uu-RLC or a PC5 RLC.

[0041] In step 218a, if the sidelink UP is successfully established or released, the remote UE201 sends an RRC reconfiguration complete message to the gNB203 to confirm the UP configuration. After the new UP connection is established, the gNB203 may map the data flow packets to one or more PDCP entities, one of which may be a Uu-PDCP or a PC5 PDCP. The gNB203 may also map the data flow packets to the same PDCP entities, but one or more RLC entities, one of which may be a Uu-RLC or a PC5 RLC.

[0042] In step 218b, if the establishment or release of the sidelink UP fails, the remote UE201 sends an RRC reconfiguration reestablishment message to the gNB203 to notify it of the failure. The gNB203 may need to perform UP route reselection, as in step 212.

[0043] In step 212, if gNB203 determines to set up the UP connection on the direct path rather than the indirect path, gNB203 may send an RRC reconfiguration message to the remote UE201 using the direct CP connection. The RRC reconfiguration message may include the legacy Uu UP configuration. After configuration, the remote UE201 may send an RRC reconfiguration complete message to gNB203.

[0044] In step 212, if gNB203 determines to set up UP connections on both the direct and indirect paths, gNB203 may send an RRC reconfiguration message to relay UE202 (as in step 213) and an RRC reconfiguration message to remote UE201 (as in step 215). However, the latter message may include configuration information for both the direct and indirect paths.

[0045] Figure 13 illustrates the steps for establishing, re-establishing, or releasing an UP connection. This may be based on inputs from the core network or the arrival of new flows to the gNB203. In addition to these inputs, triggers may occur in the gNB203 to modify the UP connection. For example, changing the UP connection from a direct path to an indirect path, from an indirect path to a direct path, from sending on a single path to sending on both paths for throughput, from sending on a single path to sending on both paths for reliability, or from sending on both paths to sending on a single path.

[0046] Such a first trigger may be based on a measurement report from a remote UE201 or relay UE202. The measurement report may include an indication of signal quality exceeding a threshold. This threshold may be different from the threshold used for mobility considerations. The measurement report may include an indication of signal load exceeding a threshold. The measurement report may include an indication of battery condition exceeding a threshold. As can be inferred, the trigger may also be an event that occurs at the base station, notifying the base station to correct the UP connection.

[0047] This second trigger may be a physical layer instruction from the remote UE201 or relay UE202. This third trigger may be a MAC control element from the remote UE201 or relay UE. This fourth trigger may be an RRC message from the remote UE201 or relay UE202.

[0048] This fifth trigger may be a NAS message from a remote UE201 or relay UE202. The NAS message may include instructions regarding the flow's latency, for example, whether the flow's threshold latency is met. Alternatively, the NAS message may include instructions regarding the flow's throughput, for example, whether the threshold throughput requirement is met.

[0049] Figure 13 shows that a UP connection can be established via the RRC reconfiguration procedure. Alternatively, the UP connection may be established via the RRC connection establishment procedure. In this case, the configuration of the UP connection may be included in the gNB203 RRC setup message. The remote UE201 response may be included in the RRC setup complete message (e.g., for a successful establishment) or in the RRC reject message (e.g., for a failed establishment). The relay UE202 response may be included in the RRC setup complete message (e.g., for a successful establishment) or in the RRC reject message (e.g., for a failed establishment).

[0050] Dynamic UP connection management via indirect routes In a scenario where the control plane (CP) is on an indirect path, as shown in Figure 10, the gNB203 may dynamically manage its own user plane (UP) connection to the remote UE201, as shown in Figure 14.

[0051] Referring to Figure 14, the remote UE201 and gNB203 may perform the following steps to (re)establish or release the UP connection.

[0052] In step 220a, the remote UE201 may establish an SRB connection with the gNB203 via an indirect path. The remote UE201 may also establish an UP connection with the gNB203 via a direct or indirect path.

[0053] In step 220b, gNB203 may send an RRC message to the remote UE201 to configure the remote UE201 to measure and report UP route selection context information via the indirect route. gNB203 may configure the remote UE201 to report information periodically or when a configured threshold is exceeded for changes in context information.

[0054] In step 220c, the remote UE201 may send an RRC message to the gNB203 to report UP route selection context information via an indirect path. The UP route selection context information may include, among other things, information about candidate relay UEs, the preference of relay UE202 (e.g., relay UE202 with the highest capacity), the relay UE with the best signal quality, the battery status of the remote UE201, the battery status of relay UE202, the power saving requirements of the remote UE201, or the power saving requirements of relay UE202.

[0055] In step 220d, gNB203 may send an RRC message to relay UE202 to configure relay UE202 to measure and report UP route selection context information.

[0056] In step 220e, relay UE202 may send an RRC message to gNB203 to report UP route selection context information. The UP route selection context information may include its traffic load (e.g., channel busy ratio), its battery status, and the number of remote UEs using the UE as relay UE202.

[0057] In step 221, gNB203 is triggered to (re)establish or release the UP connection with the remote UE201. UP connection (re)establishment or release may be triggered when receiving a PDU SESSION RESOURCE MODIFY REQUEST message (or another message) from AMF for a new QoS flow, or a PDU SESSION RESOURCE SETUP REQUEST message from AMF. UP connection establishment may be triggered when gNB203 receives a new traffic flow from the remote UE201 and the existing connection cannot meet the QoS requirements (e.g., QoS thresholds) for the traffic flow. UP connection re-establishment may be triggered when the existing UP connection is disconnected or cannot meet the QoS requirements.

[0058] In step 222, based on QoS requirements, gNB203 may select a route to (re)establish or release the UP connection. For example, if using an indirect route satisfies the flow's latency requirements and requires the remote UE201 to minimize power consumption, gNB203 may select relay UE202 to establish the UP connection over the indirect route. The remote UE201 may provide gNB203 with a metric to use in selecting relay UE201. For example, the metric may be the available capacity at relay UE202. gNB203 may select relay UE202 with the largest available capacity. In another example, the metric may be the channel load between remote UE201 and relay UE202, or the channel load between relay UE202 and gNB203. The load may be the channel busy ratio. gNB203 may select relay UE202 with the lowest channel load. In yet another example, if using an indirect route cannot satisfy the flow's latency requirements, gNB203 may select a direct route to establish the UP connection. In yet another example, if neither the direct nor the indirect route can meet the flow's reliability requirements, the gNB203 may select both the direct and indirect routes and send duplicate packets on both routes to meet the reliability requirements. In a scenario where the remote UE201 has UP connections to both the direct and indirect routes, and using the indirect route can meet the flow's latency requirements, and the remote UE201 requires minimizing power consumption, the gNB203 may release the direct route. In yet another example, if using the indirect route cannot meet the flow's latency requirements, the gNB203 may release the UP connection on the indirect route.

[0059] In step 223, gNB203 may send user plane connection configuration information to remote UE201. Transmission may be performed via an RRC reconfiguration message to remote UE201 through relay UE202. To establish an UP connection via an indirect path, the RRC reconfiguration message may include an indirect path configuration instruction, bearer ID, selected relay UE ID, and RLC channel mapping configuration associated with the new connection. The RRC reconfiguration message may also include QoS requirements for the traffic flow for remote UE201 to establish a PC5 connection with the selected relay UE202. To establish an UP connection via a direct path, the RRC reconfiguration message may include a legacy Uu UP configuration.

[0060] In step 224, to establish or release an UP connection via an indirect path, gNB203 may send user plane connection configuration information to the selected relay UE202. This transmission may be performed via an RRC reconfiguration message to the selected relay UE202. For establishing an UP connection, the RRC reconfiguration message may include the bearer ID, the remote UE201 ID, and the RLC channel mapping configuration associated with the new connection. The RRC reconfiguration message may also include QoS requirements for the traffic flow. For releasing an UP connection, the RRC reconfiguration message may include the bearer ID (e.g., DRB ID), the remote UE ID, or the RLC channel mapping configuration associated with the connection to be released.

[0061] In step 225, relay UE202 may configure its adaptation layer based on the RRC reconfiguration message. Relay UE202 may send an RRC reconfiguration complete message to gNB203 to confirm the configuration for the UP connection.

[0062] In step 226, if the remote UE201 or relay UE202 is unable to meet the QoS requirements of the new traffic flow, it may correct or release the existing sidelink UP based on the information received from the RRC reconfiguration message in step 225.

[0063] In step 227, after the new UP connection is established, the remote UE201 may map the data flow packets to one or more PDCP entities, one of which may be a Uu-PDCP or a PC5 PDCP. The remote UE201 may also map the data flow packets to the same PDCP entities, one or more of which may be RLC entities, one of which may be a Uu-RLC or a PC5 RLC.

[0064] In step 228a, if the sidelink UP is successfully established or released, the remote UE201 sends an RRC reconfiguration complete message to the gNB203 to confirm the UP configuration via the relay UE202. After the new UP connection is established, the gNB203 may map the data flow packets to one or more PDCP entities, one of which may be a Uu-PDCP or a PC5 PDCP. The gNB203 may also map the data flow packets to the same PDCP entities, but one or more RLC entities, one of which may be a Uu-RLC or a PC5 RLC.

[0065] In step 228b, if the establishment or release of the sidelink UP fails, the remote UE201 sends an RRC reconfiguration re-establishment message to the gNB203 to notify it of the failure. The gNB203 then needs to perform UP route reselection as in step 222.

[0066] In step 222, if gNB203 determines to set up the UP connection on the direct path rather than the indirect path, gNB203 may send an RRC reconfiguration message to the remote UE201 using the indirect CP connection. The RRC reconfiguration message may include the legacy Uu UP configuration. After configuration, the remote UE201 may send an RRC reconfiguration complete message to gNB203.

[0067] In step 222, if gNB203 determines to set up UP connections on both the direct and indirect paths, gNB203 may send an RRC reconfiguration message to relay UE202 (as in step 224) and an RRC reconfiguration message to remote UE201 (as in step 223). However, the latter message may include configuration information for both the direct and indirect paths.

[0068] As an alternative to steps 223 and 224, gNB203 may send a single RRC reconfiguration message. This message may include configuration for both relay UE202 and remote UE201. The configuration for remote UE201 may be contained within the container of the single RRC reconfiguration message. Relay UE202 may forward the configuration information to remote UE201 using PC5 RRC signaling.

[0069] Figure 14 illustrates the steps for establishing, re-establishing, or releasing an UP connection. This is based on inputs from the core network or the arrival of new flows to the gNB203. In addition to these inputs, triggers can occur in the gNB203 to modify the UP connection. For example, changing the UP connection from a direct path to an indirect path, from an indirect path to a direct path, from sending on a single path to sending on both paths for throughput, from sending on a single path to sending on both paths for reliability, or from sending on both paths to sending on a single path.

[0070] These first triggers may be based on measurement reports from the remote UE201 or relay UE202. The measurement reports may include indications of signal quality exceeding a threshold. This threshold may be different from the threshold used for mobility considerations. The measurement reports may include indications of signal load exceeding a threshold. The measurement reports may include indications of battery condition exceeding a threshold.

[0071] This second trigger may be a physical layer instruction from the remote UE201 or relay UE202. This third trigger may be a MAC control element from the remote UE201 or relay UE202. This fourth trigger may be an RRC message from the remote UE201 or relay UE202.

[0072] This fifth trigger may be a NAS message from a remote UE201 or relay UE202. The NAS message may include instructions regarding the flow's latency, for example, whether the flow's threshold latency is met. Alternatively, the NAS message may include instructions regarding the flow's throughput, for example, whether the threshold throughput requirement is met.

[0073] Figure 14 shows that a UP connection can be established via the RRC reconfiguration procedure. Alternatively, the UP connection may be established via the RRC connection establishment procedure. In this case, the configuration of the UP connection may be included in the gNB203 RRC setup message. The remote UE201 response may be included in the RRC setup complete message (e.g., for a successful establishment) or in the RRC reject message (e.g., for a failed establishment). The relay UE202 response may be included in the RRC setup complete message (e.g., for a successful establishment) or in the RRC reject message (e.g., for a failed establishment).

[0074] The disclosed subject matter may be logic in a WTRU (e.g., UE), and the WTRU can be configured on communication path 1 in detail with respect to how it 1) determines route selection information and transmits it to the gNB on path 1, and 2) transmits UP traffic to the gNB on path 2. Control plane information and user plane information for the UE may be on different paths (one direct, one indirect).

[0075] Table 1 is a list of acronyms that may appear in the following descriptions. Unless otherwise specified, acronyms used herein refer to the corresponding terms listed below.

[0076] [Table 1]

[0077] It is understood that entities performing the steps described herein may be logical entities. These steps may be stored in the memory of a device, server, or computer system, such as those shown in Figure 15F or Figure 15G, and executed on its processor. It is conceivable to skip steps, combine steps, or add steps between the exemplary methods disclosed herein (e.g., Figures 13–14).

[0078] The 3rd Generation Partnership Project (3GPP) develops technical standards for cellular telecommunications network technologies, including radio access, core transport networks, and service capabilities, including work on codecs, security, and quality of service. Recent Radio Access Technology (RAT) standards include WCDMA (commonly referred to as 3G), LTE (commonly referred to as 4G), LTE-Advanced standards, and New Radio (NR), also referred to as "5G." 3GPP NR standard development is expected to continue and include the definition of next-generation radio access technology (New RAT), which is expected to include the provision of new flexible radio access below 7 GHz and new ultra-mobile broadband radio access above 7 GHz. Flexible radio access is expected to consist of new non-backward compatible radio access in new spectrums below 6 GHz, and is expected to include different operating modes that can be multiplexed together in the same spectrum to address a wide range of 3GPP NR use cases with branching requirements. Ultra-mobile broadband is expected to include cmWave and mmWave spectra, for example, providing opportunities for ultra-mobile broadband access for indoor applications and hotspots. In particular, ultra-mobile broadband is expected to share a common design framework with flexible radio access below 7 GHz, utilizing centimeter-wave and millimeter-wave specific design optimizations.

[0079] 3GPP identifies the various use cases that NR is expected to support, resulting in a wide range of user experience requirements for data transfer speed, latency, and mobility. Common categories of use cases include enhanced mobile broadband (eMBB), ultra-reliable low-latency communication (URLLC), non-terrestrial networks (NTN), massive machine type communications (mMTC), network operations (e.g., network slicing, routing, migration and interworking, energy saving), and enhanced vehicle-to-vehicle and vehicle-to-infrastructure (eV2X) communications, which may include any of the following: vehicle-to-vehicle communication (V2V), vehicle-to-infrastructure (V2I), vehicle-to-network communication (V2N), vehicle-to-pedestrian communication (V2P), and vehicle-to-infrastructure communication (eV2X). Specific services and applications within these categories include, to name a few, surveillance and sensor networks, device remote control, two-way remote control, personal cloud computing, video streaming, wireless cloud-based offices, first-person connectivity, automotive e-calls, disaster alerts, real-time gaming, multi-person video conferencing, autonomous driving, augmented reality, haptic internet, virtual reality, home automation, robotics, and aerial drones. All of these use cases are discussed herein.

[0080] Figure 15A shows an exemplary communication system 100 in which methods and apparatus for dynamic user plane management may be used, such as the systems and methods shown in Figures 11 to 14 as described and claimed herein. The communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, 102e, 102f, or 102g (which may be generally or collectively referred to as WTRU 102 or a plurality of WTRUs 102). The communication system 100 may include radio access networks (RANs) 103 / 104 / 105 / 103b / 104b / 105b, core networks 106 / 107 / 109, a public switched telephone network (PSTN) 108, the internet 110, other networks 112, and network services 113. The network service 113 may include, for example, a V2X server, V2X functionality, a ProSe server, ProSe functionality, IoT services, video streaming, or edge computing.

[0081] It is understood that the concepts disclosed herein may be used with any number of WTRUs, base stations, networks, or network elements. Each of WTRUs 102a, 102b, 102c, 102d, 102e, 102f, or 102g may be any type of device or apparatus configured to operate or communicate in a wireless environment. WTRUs 102a, 102b, 102c, 102d, 102e, 102f, and 102g may be illustrated as handheld wireless communication devices as shown in Figures 15A, 15B, 15C, 15D, 15E, or 15F, respectively. However, in the various use cases considered for 5G wireless communication, each WTRU is understood to comprise or be embodied in any type of device or apparatus configured to transmit or receive wireless signals, including, for example, user equipment (UE), mobile stations, fixed or mobile subscriber units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, tablets, netbooks, notebook computers, personal computers, wireless sensors, consumer electronics, wearable devices such as smartwatches or smart clothing, medical or e-health devices, robots, industrial equipment, drones, cars, buses, trucks, trains, or airplanes.

[0082] The communication system 100 may also include base stations 114a and 114b. In the example in Figure 15A, each base station 114a and 114b is illustrated as a single element. In practice, base stations 114a and 114b may include any number of interconnected base stations or network elements. Base station 114a may be any type of device configured to wirelessly connect to at least one of WTRUs 102a, 102b, and 102c to facilitate access to one or more communication networks, such as core networks 106 / 107 / 109, the Internet 110, network services 113, or other networks 112. Similarly, base station 114b may be any type of device configured to connect by wire or wirelessly to at least one of the following: Remote Radio Head (RRH) 118a, 118b, Transmission and Reception Point (TRP) 119a, 119b, or Roadside Unit (RSU) 120a and 120b, in order to facilitate access to one or more communication networks, such as core networks 106 / 107 / 109, the Internet 110, other networks 112, or network servers 113. RRH 118a, 118b may be any type of device configured to connect wirelessly to at least one of the WTRU 102, for example, WTRU 102c, in order to facilitate access to one or more communication networks, such as core networks 106 / 107 / 109, the Internet 110, network services 113, or other networks 112.

[0083] TRP119a, 119b may be any type of device configured to wirelessly connect to at least one of WTRU102d to facilitate access to one or more communication networks, such as core networks 106 / 107 / 109, the Internet 110, network services 113, or other networks 112. RSU120a, 120b may be any type of device configured to wirelessly connect to at least one of WTRU102e or 102f to facilitate access to one or more communication networks, such as core networks 106 / 107 / 109, the Internet 110, other networks 112, or network services 113. For example, base stations 114a, 114b may be a Base Transceiver Station (BTS), Node B, eNode B, Home Node B, Home eNode B, Next Generation Node-B (gNode B), satellite, site controller, Access Point (AP), wireless router, etc.

[0084] Base station 114a may be part of RAN 103 / 104 / 105, which may also include other base stations or network elements (not shown), such as a Base Station Controller (BSC), a Radio Network Controller (RNC), and relay nodes. Similarly, base station 114b may be part of RAN 103b / 104b / 105b, which may also include other base stations or network elements (not shown), such as a BSC, RNC, and relay nodes. Base station 114a may be configured to transmit or receive wireless signals within a specific geographic area, which may be referred to as a cell (not shown). Similarly, base station 114b may be configured to transmit or receive wired or wireless signals within a specific geographic area, which may be referred to as a cell (not shown) for dynamic user plane management methods, systems, and devices, as disclosed herein. Similarly, base station 114b may be configured to transmit or receive wired or wireless signals within a specific geographic area, which may be referred to as a cell (not shown). A cell may be further divided into cell sectors. For example, a cell associated with base station 114a may be divided into three sectors. Thus, in one example, base station 114a may include three transceivers, for example, one transceiver per sector of the cell. In one example, base station 114a may use Multiple-Input Multiple Output (MIMO) technology, and therefore may utilize multiple transceivers for each sector of the cell.

[0085] Base station 114a may communicate with one or more WTRUs 102a, 102b, 102c, and 102g via air interfaces 115 / 116 / 117, which may be any suitable radio communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, centimeter wave, millimeter wave, etc.). Air interfaces 115 / 116 / 117 may be established using any suitable radio access technology (RAT).

[0086] Base station 114b may communicate with one or more of the RRH 118a, 118b, TRP 119a, 119b, or RSU 120a, 120b via 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, centimeter wave, millimeter wave, etc.). Air interface 115b / 116b / 117b may be established using any suitable radio access technology (RAT).

[0087] RRH118a, 118b, TRP119a, 119b, or RSU120a, 120b may communicate with one or more WTRU102c, 102d, 102e, 102f via air interfaces 115c / 116c / 117c, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, centimeter wave, millimeter wave, etc.). Air interfaces 115c / 116c / 117c may be established using any suitable radio access technology (RAT).

[0088] WTRU102a, 102b, 102c, 102d, 102e, or 102f may communicate with each other via air interfaces 115d / 116d / 117d (such as sidelink communication), which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, centimeter wave, millimeter wave, etc.). Air interfaces 115d / 116d / 117d may be established using any suitable radio access technology (RAT).

[0089] The communication system 100 may be a multiple access system and may employ one or more channel access methods such as CDMA, TDMA, FDMA, OFDMA, and SC-FDMA. For example, base stations 114a in RAN103 / 104 / 105, and WTRU102a, 102b, 102c, or RRH118a, 118b, TRP119a, 119b, and RSU120a, 120b in RAN103b / 104b / 105b, as well as WTRU102c, 102d, 102e, 102f, may implement radio technologies such as Universal Mobile Telecommunications System (UMTS) or Terrestrial Radio Access (UTRA), which may establish air interfaces 115 / 116 / 117 or 115c / 116c / 117c respectively using Wideband CDMA (WCDMA). WCDMA may include communication protocols such as High-Speed ​​Packet Access (HSPA) or Advanced HSPA (HSPA+). HSPA may include High-Speed ​​Downlink Packet Access (HSDPA) or High-Speed ​​Uplink Packet Access (HSUPA).

[0090] In one embodiment, base stations 114a and WTRUs 102a, 102b, 102c, or RANs 103b / 104b / 105b may implement radio technologies such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish air interfaces 115 / 116 / 117 or 115c / 116c / 117c using Long Term Evolution (LTE) or LTE-Advanced (LTE-A), respectively. In the future, air interfaces 115 / 116 / 117 or 115c / 116c / 117c may implement 3GPP NR technology. LTE and LTE-A technologies may include LTE D2D and V2X technologies and interfaces (such as sidelink communication). Similarly, 3GPP NR technologies include NR V2X technologies and interfaces (such as sidelink communication).

[0091] Base stations 114a in RAN103 / 104 / 105 and WTRU102a, 102b, 102c, and 102g, or RRH118a, 118b, TRP119a, 119b, or RSU120a, 120b and WTRU102c, 102d, 102e, and 102f in RAN103b / 104b / 105b are IEEE 802.16 (for example, Worldwide Interoperability for Microwave Access (WiMAX), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Telephone). Wireless technologies such as communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), and GSM EDGE (GERAN) may be implemented.

[0092] As disclosed herein, to realize methods, systems, and devices for dynamic user plane management, the base station 114c in Figure 15A may be, for example, a wireless router, home node B, home eNode B, or access point, and any suitable RAT may be used to facilitate wireless connectivity in local areas such as offices, homes, vehicles, trains, airborne, satellite, factories, and campuses. In embodiments, the base station 114c and WTRU 102, for example WTRU 102e, may establish a Wireless Local Area Network (WLAN) by performing radio technology such as IEEE 802.11. Similarly, the base station 114c and WTRU 102d may establish a Wireless Personal Area Network (WPAN) by performing radio technology such as IEEE 802.15. In yet another example, base stations 114c and WTRU 102, for example WTRU 102e, may establish a picocell or femtocell using a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, NR, etc.). As shown in Figure 15A, base station 114c may be directly connected to the internet 110. Therefore, base station 114c may not need to access the internet 110 via the core network 106 / 107 / 109.

[0093] RAN103 / 104 / 105 or RAN103b / 104b / 105b may communicate with core networks 106 / 107 / 109, which may be any type of network configured to provide voice, data, messaging, authentication and authorization, applications, or Voice Over Internet Protocol (VoIP) services to one or more of WTRU102a, 102b, 102c, or 102d. For example, core networks 106 / 107 / 109 may provide call control, billing services, mobile location-based services, prepaid calling, internet connectivity, packet data network connectivity, Ethernet connectivity, video distribution, etc., or may perform high-level security functions such as user authentication.

[0094] Although not shown in Figure 15A, it is understood that RAN103 / 104 / 105 or RAN103b / 104b / 105b or core network 106 / 107 / 109 may communicate directly or indirectly with other RANs employing the same RAT as RAN103 / 104 / 105 or RAN103b / 104b / 105b, or different RATs. For example, in addition to connecting to RAN103 / 104 / 105 or RAN103b / 104b / 105b which may utilize E-UTRA radio technology, core network 106 / 107 / 109 may also communicate with another RAN (not shown) using GSM or NR radio technology.

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

[0096] As disclosed herein, in order to implement methods, systems, and devices for dynamic user plane management, some or all of the WTRUs 102a, 102b, 102c, 102d, 102e, and 102f in the communication system 100 may include multimode functionality. For example, WTRUs 102a, 102b, 102c, 102d, 102e, and 102f may include multiple transceivers for communicating with different wireless networks through different wireless links. For example, WTRU 102g shown in Figure 15A may be configured to communicate with a base station 114a that may use cellular-based radio technology and a base station 114c that may use IEEE 802 radio technology.

[0097] Although not shown in Figure 15A, it is understood that user equipment may be connected to the gateway via a wired connection. The gateway may be a Residential Gateway (RG). The RG may provide connectivity to the core network 106 / 107 / 109. It is understood that much of the subject matter included herein may be equally applicable to UEs, which are WTRUs and UEs that use wired connections to connect to the network. For example, the subject matter applicable to wireless interfaces 115, 116, 117, and 115c / 116c / 117c may be equally applicable to wired connections.

[0098] Figure 15B is a system diagram of an exemplary RAN103 and core network 106 capable of performing the methods, systems, and devices for dynamic user plane management disclosed herein. As described above, RAN103 may communicate with WTRU102a, 102b, and 102c via air interface 115 using UTRA radio technology. RAN103 may also communicate with core network 106. As shown in Figure 15B, RAN103 may include Node-B140a, 140b, and 140c, each of which may include one or more transceivers for communicating with WTRU102a, 102b, and 102c via air interface 115. Node-B140a, 140b, and 140c may each be associated with a specific cell (not shown) within RAN103. RAN103 may also include RNC142a, 142b. It is understood that RAN103 may include any number of Node B and radio network controllers (RNCs).

[0099] As shown in Figure 15B, Node-B140a and 140b may communicate with RNC142a. Furthermore, Node-B140c may communicate with RNC142b. Node-B140a, 140b, and 140c may communicate with their respective RNC142a and 142b via the Iub interface. RNC142a and 142b may communicate with each other via the Iur interface. Each of RNC142a and 142b may be configured to control their respective Node-B140a, 140b, and 140c. In addition, each of RNC142a and 142b may be configured to perform or support other functions such as external loop power control, load control, admission control, packet scheduling, handover control, macro diversity, security functions, and data encryption.

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

[0101] The RNC142a in RAN103 may be connected to the MSC146 in the core network 106 via the IuCS interface. The MSC146 may be connected to the MGW144. The MSC146 and MGW144 may provide the WTRU102a, 102b, and 102c with access to a circuit-switched network such as the PSTN108 to facilitate communication between the WTRU102a, 102b, and 102c and conventional terrestrial line communication devices.

[0102] RNC142a in RAN103 may also be connected to SGSN148 in core network 106 via an IuPS interface. SGSN148 may be connected to GGSN150. SGSN148 and GGSN150 may provide WTRU102a, 102b, and 102c with access to a packet-switched network such as the Internet 110 to facilitate communication between WTRU102a, 102b, and 102c and IP-enabled devices.

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

[0104] Figure 15C is a system diagram of an exemplary RAN 104 and core network 107 capable of performing the methods, systems, and devices for dynamic user plane management disclosed herein. As described above, RAN 104 may communicate with WTRU 102a, 102b, and 102c via air interface 116 using E-UTRA radio technology. RAN 104 may also communicate with core network 107.

[0105] RAN104 may include eNode-B160a, 160b, and 160c, but it is understood that RAN104 may include any number of eNode-B. Each of eNode-B160a, 160b, and 160c may include one or more transceivers for communicating with WTRU102a, 102b, and 102c via the air interface 116. For example, eNode-B160a, 160b, and 160c may implement MIMO technology. Thus, eNode-B160a may, for example, use multiple antennas to transmit wireless signals to WTRU102a and receive wireless signals from WTRU102a.

[0106] Each of the eNode-B160a, 160b, and 160c may be associated with a specific cell (not shown) and may be configured to handle wireless resource management decisions, handover decisions, user scheduling, etc., in the uplink or downlink. As shown in Figure 15C, the eNode-B160a, 160b, and 160c may communicate with each other through the X2 interface.

[0107] The core network 107 shown in Figure 15C may include a Mobility Management Gateway (MME) 162, a Serving Gateway 164, and a Packet Data Network (PDN) Gateway 166. Although each of the aforementioned elements is illustrated as part of the core network 107, it is understood that any of these elements may be owned and / or operated by an entity other than the core network operator.

[0108] MME162 may be connected to each of the e-nodes B160a, 160b, and 160c within RAN104 via the S1 interface and may function as a control node. For example, MME162 may perform roles such as authenticating users for WTRU102a, 102b, and 102c, bearer activation / deactivation, and selecting a specific serving gateway during the initial attachment of WTRU102a, 102b, and 102c. MME162 may also provide control plane functionality for exchanges between RAN104 and other RANs (not shown) using other radio technologies such as GSM or WCDMA.

[0109] The serving gateway 164 may be connected to each of the eNode-B 160a, 160b, and 160c in RAN 104 via the S1 interface. The serving gateway 164 may generally route and forward user data packets to and from WTRU 102a, 102b, and 102c. The serving gateway 164 may also perform other functions, such as anchoring the user plane during eNode B handover, triggering paging when downlink data is available to WTRU 102a, 102b, and 102c, and managing and remembering the context of WTRU 102a, 102b, and 102c.

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

[0111] The core network 107 may facilitate communication with other networks. For example, the core network 107 may provide WTRU 102a, 102b, and 102c with access to a circuit-switched network such as PSTN 108, thereby facilitating communication between WTRU 102a, 102b, and 102c and conventional fixed-line communication devices. For example, the core network 107 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that functions as an interface between the core network 107 and PSTN 108. In addition, the core network 107 may provide WTRU 102a, 102b, and 102c with access to network 112, which may include other wired or wireless networks owned or operated by other service providers.

[0112] Figure 15D is a system diagram of an exemplary RAN 105 and core network 109 capable of performing a method, system, and device for dynamic user plane management as disclosed herein. RAN 105 may communicate with WTRU 102a and 102b via air interface 117 using NR radio technology. RAN 105 may also communicate with core network 109. A Non-3GPP Interworking Function (N3IWF) 199 may communicate with WTRU 102c via air interface 198 using Non-3GPP radio technology. N3IWF 199 may also communicate with core network 109.

[0113] RAN105 may include gNode-B180a and 180b. It is understood that RAN105 may include any number of gNode-B. Each of gNode-B180a and 180b may include one or more transceivers for communicating with WTRU102a and 102b via air interface 117. When integrated access and backhaul connectivity is used, the same air interface may be used between the WTRU and the gNode-B, and this air interface may be a core network 109 via one or more gNBs. gNode-B180a and 180b may implement MIMO, MU-MIMO, or digital beamforming techniques. Thus, gNode-B180a may, for example, use multiple antennas to transmit wireless signals to and receive wireless signals from WTRU102a. It should be understood that RAN105 may use other types of base stations, such as eNode-B. It is also understood that RAN105 may employ two or more types of base stations. For example, RAN may use eNode-B and gNode-B.

[0114] N3IWF199 may include non-3GPP access points 180c. It is understood that N3IWF199 may include any number of non-3GPP access points. Non-3GPP access points 180c may include one or more transceivers for communicating with WTRU102c via air interface 198. Non-3GPP access points 180c may communicate with WTRU102c via air interface 198 using the 802.11 protocol.

[0115] Each of the gNode-B180a and 180b may be associated with a specific cell (not shown) and may be configured to handle wireless resource management decisions, handover decisions, user scheduling, etc., on the uplink or downlink. As shown in Figure 15D, the gNode-B180a and 180b may communicate with each other, for example, through an Xn interface.

[0116] The core network 109 shown in Figure 15D may be a 5G core network (5GC). The core network 109 may provide numerous communication services to customers interconnected by a wireless access network. The core network 109 includes numerous entities that perform the functionality of the core network. As used herein, the terms “core network entity” or “network function” refer to any entity that performs one or more functions of the core network. It is understood that such core network entities may be devices configured for wireless or network communications, or logical entities implemented in the form of computer executable instructions (software) stored in the memory of a computer system such as system 90 shown in Figure 15G and executed on its processors.

[0117] In the example in Figure 15D, the 5G core network 109 may include an access and mobility management function (AMF) 172, a session management function (SMF) 174, user plane functions (UPFs) 176a and 176b, a user data management function (UDM) 197, an authentication server function (AUSF) 190, a network exposure function (NEF) 196, a policy control function (PCF) 184, a non-3GPP interworking function (N3IWF) 199, and a user data repository (UDR) 178. Although each of the aforementioned elements is illustrated as part of the 5G core network 109, it is understood that any of these elements may be owned or operated by an entity other than the core network operator. Furthermore, it should be understood that a 5G core network may not consist of all of these elements, but may include additional elements, and may consist of multiple examples of each of these elements. Figure 15D shows network functions directly connected to each other, but it should be understood that these network functions may communicate via routing agents such as a direct routing agent or a message bus.

[0118] In the example in Figure 15D, connectivity between network functions is achieved through a set of interfaces or reference points. It is understood that network functions may be modeled, described, or implemented as a set of services that are invoked or called by other network functions or services. Invocation of network function services may be achieved through direct connections between network functions, messaging exchanges on a message bus, or invocation of software functions.

[0119] AMF172 may be connected to RAN105 via the N2 interface and may function as a control node. For example, AMF172 may perform registration management, connection management, reachability management, access authentication, and access authorization roles. AMF may also be responsible for forwarding user plane tunnel configuration information to RAN105 via the N2 interface. AMF172 may also receive user plane tunnel configuration information from SMF via the N11 interface. Generally, AMF172 may route and forward NAS packets to / from WTRU102a, 102b, and 102c via the N1 interface. The N1 interface is not shown in Figure 15D.

[0120] SMF174 may be connected to AMF172 via the N11 interface. Similarly, SMF may be connected to PCF184 via the N7 interface and to UPF176a and 176b via the N4 interface. SMF174 may function as a control node. For example, SMF174 may be responsible for session management, IP address allocation for WTRU102a, 102b, and 102c, management and configuration of traffic steering rules in UPF176a and UPF176b, and generation of downlink data notifications to AMF172.

[0121] UPF176a and UPF176b may provide WTRU102a, 102b, and 102c with access to a packet data network (PDN), such as the Internet 110, to facilitate communication between WTRU102a, 102b, and 102c and other devices. UPF176a and UPF176b may also provide WTRU102a, 102b, and 102c with access to other types of packet data networks. For example, the other network 112 may be an Ethernet network or any type of network that exchanges data packets. UPF176a and UPF176b may receive traffic steering rules from SMF174 via the N4 interface. UPF176a and UPF176b may provide access to a packet data network by connecting it to the N6 interface or by connecting it to each other or to other UPFs via the N9 interface. In addition to providing access to the packet data network, UPF176 may also play a role in packet routing and forwarding, enforcement of policy rules, quality of service for user plane traffic, and downlink packet buffering.

[0122] AMF172 may also be connected to N3IWF199, for example via the N2 interface. N3IWF facilitates connection between WTRU102c and the 5G core network 170, for example via radio interface technology not defined by 3GPP. AMF may interact with N3IWF199 in the same or similar manner as it interacts with RAN105.

[0123] PCF184 may be connected to SMF174 via the N7 interface, to AMF172 via the N15 interface, and to Application Function (AF) 188 via the N5 interface. The N15 and N5 interfaces are not shown in Figure 15D. PCF184 may also provide policy rules to control plane nodes such as AMF172 and SMF174, enabling the control plane nodes to enforce these rules. PCF184 may send policies to AMF172 for WTRU102a, 102b, and 102c, and AMF may deliver policies to WTRU102a, 102b, and 102c via the N1 interface. The policies may then be enforced or applied in WTRU102a, 102b, and 102c.

[0124] UDR178 may function as a repository for authentication certificates and enrollment information. UDR may connect to a network function, which may add, read, and modify data in the repository. For example, UDR178 may connect to PCF184 via the N36 interface. Similarly, UDR178 may connect to NEF196 via the N37 interface, and UDR178 may connect to UDM197 via the N35 interface.

[0125] UDM197 may function as an interface between UDR178 and other network functions. UDM197 may authorize network functions for access to UDR178. For example, UDM197 may connect to AMF172 via the N8 interface, or to SMF174 via the N10 interface. Similarly, UDM197 may connect to AUSF190 via the N13 interface. UDR178 and UDM197 may be tightly integrated.

[0126] The AUSF190 performs authentication-related operations and connects to the UDM178 via the N13 interface and to the AMF172 via the N12 interface.

[0127] NEF196 exposes the capabilities and services of the 5G core network 109 to the application function (AF) 188. Exposure may occur via the N33 API interface. The NEF may connect to AF188 via the N33 interface, or it may connect to other network functions to expose the capabilities and services of the 5G core network 109.

[0128] The application function 188 may interact with network functions within the 5G core network 109. The interaction between the application function 188 and the network functions may occur via a direct interface or via the NEF 196. The application function 188 may be considered part of the 5G core network 109, or it may be outside the 5G core network 109 and deployed by a company that has a business relationship with a mobile network operator.

[0129] Network slicing is a mechanism used by mobile network operators to support one or more "virtual" core networks behind the operator's air interface. This involves "slicing" the core network into one or more virtual networks to support different RANs or different service types running across a single RAN. Network slicing allows operators to create customized networks that provide optimized solutions for different market scenarios requiring diverse requirements, for example, in the areas of functionality, performance, and isolation.

[0130] 3GPP is designing the 5G core network to support network slicing. Network slicing is a good tool that network operators can use to support a diverse set of 5G use cases (e.g., large-scale IoT, critical communications, V2X, and enhanced mobile broadband) that may require very diverse and extreme requirements. Without network slicing technology, the network architecture is likely to lack sufficient flexibility and scalability to efficiently support the needs of a wider range of use cases, as each use case has its own specific set of performance, scalability, and availability requirements. Furthermore, it should make the deployment of new network services more efficient.

[0131] Referring again to Figure 15D, in the network slicing scenario, WTRU102a, 102b, or 102c may be connected to AMF172 via the N1 interface. The AMF may be logically part of one or more slices. The AMF may coordinate the connection or communication of WTRU102a, 102b, or 102c to one or more UPF176a and 176b, SMF174, and other network functions. UPF176a and 176b, SMF174, and other network functions may each be part of the same slice or different slices. When they are part of different slices, they may be isolated from each other in terms of being able to utilize different computing resources, security certificates, etc.

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

[0133] The core network entities described herein and shown in Figures 15A, 15C, 15D, or 15E are identified by the names given to those entities in certain existing 3GPP specifications, but future entities and functions may be identified by other names, and it is understood that certain entities or functions may be combined in future specifications published by 3GPP, including future 3GPP NR specifications. Accordingly, the specific network entities and functions described and shown in Figures 15A, 15B, 15C, 15D, or 15E are provided merely as examples, and it is understood that the subject matter disclosed and claimed herein may be embodied or implemented in any similar communication system, whether currently defined or hereafter defined.

[0134] Figure 15E shows an exemplary communication system 111 in which a system, method, or apparatus for performing dynamic user plane management as described herein may be used. The communication system 111 may include wireless transmission / receiving units (WTRUs) A, B, C, D, E, F, a base station gNB 121, a V2X server 124, and roadside units (RSUs) 123a and 123b. In practice, the concepts presented herein may apply to any number of WTRUs, base station gNBs, V2X networks, or other network elements. One or more, or all, WTRUs A, B, C, D, E, and F may be outside the scope of access network coverage 131. WTRUs A, B, and C form a V2X group in which WTRU A is the group lead and WTRUs B and C are group members.

[0135] WTRUs A, B, C, D, E, and F may communicate with each other across the Uu interface 129 via the gNB 121 if they are within access network coverage 131. In the example in Figure 15E, WTRUs B and F are shown within access network coverage 131. WTRUs A, B, C, D, E, and F may communicate with each other directly via sidelink interfaces such as interfaces 125a, 125b, or 128 (e.g., PC5 or NR PC5), regardless of whether they are under or outside access network coverage 131. For example, in the example in Figure 15E, WTRU D, which is outside access network coverage 131, communicates with WTRU F, which is within coverage 131.

[0136] WTRUs A, B, C, D, E, and F may communicate with RSU 123a or 123b via vehicle-to-network communication (V2N) 133 or side-link interface 125b. WTRUs A, B, C, D, E, and F may communicate with V2X server 124 via vehicle-to-infrastructure communication (V2I) interface 127. WTRUs A, B, C, D, E, and F may communicate with another UE via vehicle-to-human communication (V2P) interface 128.

[0137] Figure 15F is a block diagram of an exemplary apparatus or device WTRU102 that may be configured for wireless communication and operation by a system, method, and apparatus performing dynamic user plane management as described herein, such as WTRU102 in Figures 15A, 15B, 15C, 15D, or 15E or Figures 11-14 (e.g., remote UE201, relay UE202, or gNB203). As shown in Figure 15F, the exemplary WTRU102 may include a processor 78, a transceiver 120, a transmission / reception element 122, a speaker / microphone 74, a keypad 126, a display / touchpad / indicator 77, non-removable memory 130, removable memory 132, a power supply 134, a global positioning system (GPS) chipset 136, and other peripherals 138. It is understood that WTRU102 may include any partial combination of the aforementioned elements. Furthermore, base stations 114a and 114b, or the nodes represented by base stations 114a and 114b, are not limited, but in particular, transceiver stations (BTS), node B, site controllers, access points (AP), home node B, evolved home node-B (eNodeB), home evolved node-B (HeNB), home evolved node-B gateway, next-generation node B (gNode-B), and proxy nodes may include some or all of the elements illustrated in Figure 15F and may be exemplary implementations of the disclosed systems and methods for dynamic user plane management described herein.

[0138] The processor 78 may be a general-purpose processor, a dedicated processor, a conventional processor, a Digital Signal Processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 78 may perform signal coding, data processing, power control, input / output processing, or any other function that enables the WTRU 102 to operate in a wireless environment. The processor 78 may be coupled to a transceiver 120 which can be coupled to the transmit / receive element 122. Figure 15F shows the processor 78 and the transceiver 120 as separate components, but it is understood that the processor 78 and the transceiver 120 can be integrated in an electronic package or chip.

[0139] The UE's transmission / receiving element 122 may be configured to transmit signals to or receive signals from a base station (e.g., base station 114a in Figure 15A) via air interfaces 115 / 116 / 117, or to transmit signals to or receive signals from another UE via air interfaces 115d / 116d / 117d. For example, the transmission / receiving element 122 may be an antenna configured to transmit or receive RF signals. The transmission / receiving element 122 may be an emitter / detector configured to transmit or receive, for example, IR, UV, Radar, LiDAR, or visible light signals. The transmission / receiving element 122 may be configured to transmit and receive both RF signals and optical signals. It is understood that the transmission / receiving element 122 may be configured to transmit or receive any combination of wireless or wired signals.

[0140] In addition, although the transmission / reception element 122 is illustrated as a single element in Figure 15F, the WTRU 102 may include any number of transmission / reception elements 122. More specifically, the WTRU 102 may use MIMO technology. Therefore, the WTRU 102 may include two or more transmission / reception elements 122 (e.g., multiplex antennas) for transmitting and receiving wireless signals via the air interfaces 115 / 116 / 117.

[0141] The transceiver 120 may be configured to modulate the signal transmitted by the transmit / receive element 122 and demodulate the signal received by the transmit / receive element 122. As described above, the WTRU 102 may have multimode capabilities. Therefore, the transceiver 120 may include multiple transceivers that enable the WTRU 102 to communicate over multiple RATs, e.g., NR and IEEE 802.11 or NR and E-UTRA, or to communicate with the same RAT over multiple beams to different RRHs, TRPs, RSUs, or nodes.

[0142] The processor 78 of the WTRU102 may be coupled to a speaker / microphone 74, a keypad 126, or a display / touchpad / indicator 77 (e.g., a liquid crystal display (LCD) display unit or an organic light-emitting diode (OLED) display unit) and may receive user input data from them. The processor 78 may also output user data to the speaker / microphone 74, the keypad 126, or the display / touchpad / indicator 77. Furthermore, the processor 78 may access information from any type of suitable memory, such as non-removable memory 130 or removable memory 132, and store data in that memory. 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. The processor 78 may access information from memory not physically located on the WTRU 102, such as on a server hosted on a cloud or edge computing platform or a home computer (not shown), and store data in that memory. The processor 78 may be configured to control a lighting pattern, image, or color on the display or indicator 77, or to indicate the status of dynamic user plane management, including associated components, depending on whether the setup was successful or unsuccessful in some of the embodiments described herein. The controlled lighting pattern, image, or color on the display or indicator 77 may reflect the status of any of the method flows or components in the diagrams shown or considered herein (e.g., Figures 11-14). Messages and procedures for dynamic user plane management are disclosed herein.The messages and procedures may be extended to provide an interface / API for the user to request resources via an input source (e.g., speaker / microphone 74, keypad 126, or display / touchpad / indicator 77) and to request, configure, or query dynamic user plane management-related information among other things that may be displayed on the display 77.

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

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

[0145] The processor 78 may be further coupled to other peripherals 138, which may include one or more software or hardware modules that provide additional features, functions, or wired or wireless connectivity. For example, peripherals 138 may include various sensors such as accelerometers, biometric (e.g., fingerprint) sensors, electronic compasses, satellite transceivers, digital cameras (for photography or video), Universal Serial Bus (USB) ports or other interconnection interfaces, vibration devices, television transceivers, hands-free headsets, Bluetooth® modules, frequency-modulated (FM) radio units, digital music players, media players, video game player modules, internet browsers, and the like.

[0146] WTRU102 may be included in other devices or apparatus, such as sensors, consumer electronics, wearable devices such as smartwatches or smart clothing, medical or e-health devices, robots, industrial equipment, drones, automobiles, trucks, trains, airplanes, and other vehicles. WTRU102 may be connected to other components, modules, or systems of such devices or apparatus via one or more interconnect interfaces, such as an interconnect interface that may include one of the peripheral devices 138.

[0147] Figure 15G is a block diagram of an exemplary computing system 90 in which one or more devices of the communication network shown in Figures 15A, 15C, 15D, and 15E, as well as dynamic user plane management, can be embodied, including the systems and methods shown in Figures 11-14 as described and claimed herein, such as RAN 103 / 104 / 105, core networks 106 / 107 / 109, PSTN 108, the Internet 110, other networks 112, or specific nodes or functional entities in network services 113. The computing system 90 may include a computer or server and may be controlled primarily by computer-readable instructions. Computer-readable instructions may be in the form of software, in any location, or by any means by which such software is stored or accessed. Such computer-readable instructions may be executed within a processor 91 to cause the computing system 90 to perform its work. The processor 91 may be a general-purpose processor, a dedicated processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 91 may perform signal coding, data processing, power control, input / output processing, or any other function that enables the computing system 90 to operate on a communication network. The coprocessor 81 is any processor distinct from the main processor 91 and may perform additional functions or assist the processor 91. The processor 91 or coprocessor 81 may receive, generate, and process data related to the methods and apparatus disclosed herein for dynamic user plane management, such as receiving messages via the control plane or user plane.

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

[0149] The memory coupled to the system bus 80 includes random access memory (RAM) 82 and read-only memory (ROM) 93. Such memory includes circuitry that enables the storage and retrieval of information. ROM 93 generally contains stored data that cannot be easily modified. Data stored in RAM 82 may be read or modified by the processor 91 or other hardware devices. Access to RAM 82 or ROM 93 may be controlled by a memory controller 92. The memory controller 92 may provide address translation functionality that translates virtual addresses to physical addresses when instructions are executed. The memory controller 92 may also provide memory protection functionality that isolates processes within the system and separates system processes from user processes. Thus, a program running in the first mode may only access memory mapped by its process virtual address space and cannot access memory in the virtual address space of another process unless inter-process memory sharing is configured.

[0150] Furthermore, the computing system 90 may include a peripheral device controller 83 that communicates instructions from the processor 91 to peripheral devices such as a printer 94, a keyboard 84, a mouse 95, and a disk drive 85.

[0151] The display 86, controlled by the display controller 96, is used to display visual output generated by the 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). The display 86 may be implemented as a CRT-based video display, an LCD-based flat panel display, a gas plasma-based flat panel display, or a touch panel. The display controller 96 includes the electronic components necessary to generate the video signal transmitted to the display 86.

[0152] Furthermore, the computing system 90 may include communication circuits, such as a wireless or wired network adapter 97, which can be used to connect the computing system 90 to external communication networks or devices such as RAN 103 / 104 / 105, core networks 106 / 107 / 109, PSTN 108, the Internet 110, WTRU 102, or other networks 112 in Figures 15A, 15B, 15C, 15D, or 15E, enabling the computing system 90 to communicate with other nodes or functional entities in those networks. The communication circuits may be used alone or in combination with the processor 91 to perform the transmission and reception steps of specific devices, nodes, or functional entities described herein.

[0153] Any or all of the apparatus, 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, such instructions are understood to cause a processor, such as processor 78 or 91, to execute or implement the systems, methods, and processes described herein when executed by the processor. Specifically, any of the steps, operations, or functions described herein may be implemented in the form of such computer-executable instructions that are executed on a processor of an apparatus or computing system configured for wireless or wired network communication. Computer-readable storage mediums include volatile and non-volatile, removable and non-removable media implemented in any non-temporary (e.g., tangible or physical) method or technology for storing information, but such computer-readable storage mediums do not contain signals. Computer-readable storage media include RAM, ROM, EEPROM, flash memory, or other memory technologies; CD-ROM, Digital Versatile Disks (DVDs), or other optical disc storage devices; magnetic cassettes, magnetic tapes, magnetic disk storage devices, or other magnetic storage devices; or any other tangible or physical media used to store desired information and accessible by a computing system.

[0154] In describing preferred methods, systems, or apparatus for dynamic user plane management, which are the subject matter of this disclosure, certain terms are used for clarity, as illustrated in the figures. However, the claimed subject matter is not intended to be limited to the specific terms thus selected.

[0155] The various technologies described herein may be implemented in relation to hardware, firmware software, or, as appropriate, a combination thereof. Such hardware, firmware, and software may reside in devices located at various nodes of a communication network. The devices may operate individually or in combination with each other to implement the methods described herein. As used herein, terms such as “device,” “network device,” “node,” “device,” and “network node” may be used interchangeably. In addition, the use of the word “or” is generally used comprehensively unless otherwise specified herein.

[0156] The descriptions provided include examples for the disclosed subject matter, including the best form, and enable a person skilled in the art to practice the disclosed subject matter, including making and using any device or system and performing any incorporated method. The disclosed subject matter may also include other examples conceivable by a person skilled in the art, such as skipping steps, combining steps, or adding steps between the exemplary methods disclosed herein.

[0157] In particular, the methods, systems, and apparatus described herein may provide dynamic user plane management. A method, system, computer-readable storage medium, or apparatus comprises: receiving a request for managing data traffic flows from or to a second device having QoS requirements; obtaining route selection context information from the second device; obtaining route selection context information from a third device; selecting one or more routes to establish a user plane connection for a traffic flow based on the obtained route selection context information and the QoS requirements of the traffic flow; configuring the second and third devices to establish a user plane connection; and mapping the data flow traffic to one or more UP connections. The first device may include a base station (e.g., an eNB or gNB), the second device may include a remote UE, and the third device may include a relay UE. The first device may receive a request from a fourth device or a second device. The fourth device may include an AMF. The routing context information obtained from the second device may include power consumption requirements, channel busy ratio, a list of candidate second devices, or the preference for the second device. The routing context information obtained from the third device may include channel busy ratio or battery status. The first device may select the third device to forward the data traffic flow to the second device in order to minimize the power consumption of the second device. The first device may choose to forward the data traffic flow directly to the second device in order to meet the latency requirements of the data traffic flow. The first device may select the third device to indirectly forward the data traffic flow to or from the second device, or simultaneously forward the data traffic flow directly to the second device, in order to meet the reliability requirements of the data traffic flow. The first device may configure the third device to forward data traffic to or from the second device based on the QoS of the data traffic flow.All combinations in this paragraph or the following paragraph (including the removal or addition of steps) shall be considered to be consistent with the rest of the detailed explanation.

[0158] The first device may configure the second device to send to or receive from the third device for a specified data traffic flow based on the QoS of the data traffic flow. The second or third device may establish a connection based on configuration information received from the first device. The second or third device releases the connection based on configuration information received from the first device. The first device directly configures the second device. If the current user plane connection cannot meet the QoS requirements of the traffic flow, the first device may re-select one or more paths to establish a user plane connection for the traffic flow. The UP connection may be a direct connection or one or more indirect connections via the third device. The first device maps data flow packets to one or more PDCP entities. The first device maps data flow packets to one or more RLC entities that are the same PDCP entities. All combinations in this paragraph or the following paragraph (including the removal or addition of steps) are considered to be consistent with other parts of the detailed description.

[0159] A method, system, computer-readable storage medium, or apparatus comprises a first device receiving path selection context configuration information from a second device via a first path; transmitting the path selection context information to the second device via the first path based on the received "path selection context" configuration information; receiving "user plane connection" configuration information from the second device via the first path; configuring the first device to communicate with the second device via the second path based on the received "user plane connection" configuration information; and accepting the received user plane connection configuration in response to the second device via the first path. The first path may be a direct path between the first device and the second device, or an indirect path between the first device and the second device. The first device includes a relay UE or a remote UE. Route selection context information may include battery status, load status, power consumption requirements, channel busy ratio, a list of preferred relay UE candidates, or the number of attached remote UEs. The first device may be a remote UE or a relay UE. User plane connection configuration information may include one or more of the following: bearer ID, UE ID of the first device, UE ID of the third device, remote UE ID, relay UE ID, radio link control (RLC) channel mapping configuration associated with the new sidelink connection, or quality of service (QoS) requirements for the traffic flow. Configuring the first device to communicate with the second device may further involve the first device establishing a sidelink connection to the third device. The first route may be over an indirect connection, and user plane connection configuration information may be transported in PC5 Radio Resource Control (RRC) messages from the third device.Route selection context information may be transmitted via measurement reports, physical layer instructions, Media Access Control (MAC) control elements (CE), RRC messages, or NAS messages. Route selection context information may be transmitted periodically or based on any triggered event, based on a request from a second device. All combinations in this paragraph (including the removal or addition of steps) are considered in accordance with other parts of the detailed description.

Claims

1. A remote wireless transmitter / receiver unit (WTRU), User plane (UP) route selection context information is transmitted to the base station via a first wireless communication path, and the UP route selection context information includes information associated with the route selection preference of the relay WTRU. The base station receives user plane connection configuration information, Based on the user plane connection configuration information, it is determined whether to communicate via the first wireless communication path or via the second wireless communication path. Based on the decision to communicate via the first wireless communication path or the second wireless communication path, data traffic is transmitted to the base station via the first wireless communication path or the second wireless communication path. Processor configured in such a way A remote WTRU equipped with this.

2. The remote WTRU according to claim 1, wherein the route selection preference of the relay WTRU is associated with power requirements, the battery status of the relay WTRU, the battery status of the remote WTRU, or the capacity in the relay WTRU.

3. The remote WTRU according to claim 1, wherein the first wireless communication path is an indirect wireless communication path between the remote WTRU and the base station, and the second wireless communication path is a direct wireless communication path between the remote WTRU and the base station.

4. The remote WTRU according to claim 1, wherein the processor is configured to establish or modify the UP connection and determine the second wireless communication path.

5. The remote WTRU according to claim 1, wherein the UP route selection context information includes one or more parameters from the following: battery status, load status, channel busy ratio, a list of candidate relay WTRUs, or the number of remote WTRUs that use the relay WTRUs.

6. The remote WTRU according to claim 1, wherein the user plane connection configuration information includes a bearer identifier (ID), a wireless transmit / receive unit (WTRU) ID of the relay WTRU, a WTRU ID of a third device, a remote WTRU ID, a radio link control (RLC) channel mapping configuration associated with the sidelink connection, or quality of service (QoS) requirements for the traffic flow.

7. The remote WTRU according to claim 1, wherein the user plane connection configuration information includes first configuration information corresponding to a radio link control (RLC) layer, a medium access control (MAC) layer, or a physical (PHY) layer relating to direct communication, and the user plane connection configuration information includes second configuration information corresponding to an RLC layer, a MAC layer, or a PHY layer relating to sidelink communication.

8. The remote WTRU according to claim 1, wherein the first wireless communication path is via an indirect wireless communication path, and the user plane connection configuration information is carried by PC5 wireless resource control (RRC) messages from the device.

9. The remote WTRU according to claim 1, wherein the UP route selection context information is transmitted via at least one of a measurement report, a physical layer instruction, a media access control (MAC) control element (CE), a radio resource control (RRC) message, or a non-access layer (NAS) message.

10. The remote WTRU according to claim 1, wherein the UP route selection context information is transmitted based on a triggered event and based on a request from the base station.

11. A method performed by a wireless transmit / receive unit (WTRU), Transmitting user plane (UP) route selection context information to a base station via a first wireless communication path, wherein the UP route selection context information includes information associated with the route selection preference of a relay WTRU. Receiving user plane connection configuration information from the aforementioned base station, Based on the user plane connection configuration information, it is determined whether to communicate via the first wireless communication path or via the second wireless communication path. Based on the decision to communicate via the first wireless communication path or the second wireless communication path, data traffic is transmitted to the base station via the first wireless communication path or the second wireless communication path. A method that includes [a certain feature].

12. The method according to claim 11, wherein the route selection preference of the relay WTRU is associated with power requirements, battery status of a remote WTRU, battery status of the relay WTRU, or capacity in the relay WTRU.

13. The method according to claim 11, wherein the first wireless communication path is an indirect wireless communication path between the remote WTRU and the base station, and the second wireless communication path is a direct wireless communication path between the remote WTRU and the base station.

14. The method according to claim 11, further comprising determining the second wireless communication path by establishing or modifying the UP connection.

15. The method according to claim 11, wherein the UP route selection context information includes one or more parameters from the following: battery status, load status, channel busy ratio, a list of candidate relay WTRUs, or the number of remote WTRUs that use the relay WTRUs.

16. The method according to claim 11, wherein the user plane connection configuration information includes a bearer identifier (ID), a wireless transmit / receive unit (WTRU) ID of the relay WTRU, a WTRU ID of a third device, a remote WTRU ID, a radio link control (RLC) channel mapping configuration associated with the sidelink connection, or quality of service (QoS) requirements for the traffic flow.

17. The method according to claim 11, wherein the user plane connection configuration information includes first configuration information corresponding to a radio link control (RLC) layer, a medium access control (MAC) layer, or a physical (PHY) layer relating to direct communication, and the user plane connection configuration information includes second configuration information corresponding to an RLC layer, a MAC layer, or a PHY layer relating to side link communication.

18. When executed by a computing device, Transmitting user plane (UP) route selection context information to a base station via a first wireless communication path, wherein the UP route selection context information includes information associated with the route selection preference of a relay WTRU. Receiving user plane connection configuration information from the aforementioned base station, Based on the user plane connection configuration information, it is determined whether to communicate via the first wireless communication path or via the second wireless communication path. Based on the decision to communicate via the first wireless communication path or the second wireless communication path, data traffic is transmitted to the base station via the first wireless communication path or the second wireless communication path. A computer-readable storage medium that stores computer-executable instructions causing the computing device to perform an operation including the following.

19. The computer-readable storage medium according to claim 18, wherein the user plane connection configuration information includes first configuration information corresponding to a radio link control (RLC) layer, a medium access control (MAC) layer, or a physical (PHY) layer relating to direct communication, and the user plane connection configuration information includes second configuration information corresponding to an RLC layer, a MAC layer, or a PHY layer relating to side link communication.

Images