Service layer support of traffic steering over multiple accesses

Abstract

Service layer support of traffic steering over multiple accesses are described herein. In one aspect, a method performed by an application enabler layer (AEL) server, can include: receiving a request from a vertical application layer (VAL) server for configuring a traffic steering policy for one or more UEs; sending a response to the VAL server; receiving an application layer traffic flow request for one or more access network connections, where the request includes information corresponding to traffic steering policy and an access network identifier; mapping an AEL client and one or more traffic flow identifiers with the access network identifier and a VAL server identifier to enable traffic steering of application traffic; receiving traffic steering adaptation reports for one or more flows, and applying traffic adaptation processes to the one or more flows to an AEL client based on the traffic steering adaptation reports.

Description

SERVICE LAYER SUPPORT OF TRAFFIC STEERING OVER MULTIPLEACCESSESCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims benefit of U.S. Provisional Application No. 63 / 584,947 titled “Service Layer Support of Traffic Steering Over Multiple Accesses” filed September 25, 2023. the content of which is hereby incorporated by reference in its entirety for any and all purposes.BACKGROUND

[0002] Applications are becoming increasingly more complex and various mechanisms have been designed to assist with quicker development of the applications. One such mechanism is the introduction of different functional layers within (or adjacent to) the application layer to separate functions that may be accessed via application programming interfaces or APIs. FIG. 1 shows an example of a generalized application layer architecture that separates application development into three distinct layers: application-specific, vertical application enabler, and (common) service lay ers. At the bottom of the application stack is the (common) service layer, which provides common or horizontal services to all applications. The services may include location management, group management, configuration management, and security aspects for application development. Above the service layer is the vertical application enabler layer, which is a layer that manages services for a specific vertical application such as autonomous vehicles, drones, loT, gaming, etc. At the top of the application stack is the application-specific layer which serves specific applications within a vertical application. This layer contains custom or business logic for a particular application and may be provided by various service providers in a vertical application domain. One goal of this three-layered approach is to abstract common sen-ices for all applications to the vertical application enabler and service layers to simplify application development for faster deployments of the applications.

[0003] The architecture shown in FIG. 1 is based on a client-server communication model. One or more client applications on devices may communicate with one or more server applications on application servers. Note that server applications may reside in one or more application servers. The client application and server application of each layer communicatewith each other between the devices and application servers. The application-specific client and server may communicate with client and server applications at any of the lower layers, respectively. For example, an application-specific client may communicate with the client application at either the vertical application enabler or service layers. A network between the client and server applications provides the medium for communication. The network may be a cellular network such as a mobile operator network or the network may be a broadband service provider network providing access to the internet for client and server applications.

[0004] It is worth noting that the architecture shown in FIG. 1 may also apply to publish- subscribe and subscription-notification communication models. It is also worth noting that for decentralized deployments in which devices communicate directly with other devices, server functionality may reside on a device rather than on the application servers. For this case, devices may communicate with one another such that one device may function as a client and another device may function as a server.Service Enabler Architecture Laver Data Delivery (SEALDD)

[0005] 3GPP has defined a Service Enabler Architecture Layer for Verticals (SEAL) to provide a horizontal layer in which common services are made available to vertical application layers. Common services offered by SEAL are location management, group management, configuration management, identity management, key management, and network resource management. Vertical Application Layer (VAL) client(s) accesses SEAL services, which transports the application traffic to VAL servers over the SEAL layer.

[0006] In Release 18, 3GPP has enhanced the SEAL layer to support efficient data distribution, delivery, and caching towards the application layer. FIG. 2 shows the SEALDD architecture as found in [1], In the architecture, SEALDD clients and SEALDD servers provide the data delivery service over the SEALDD-UU interface for application traffic transfer from the VAL layer. In addition, the SEALDD server has access to exposure information available from the 3GPP network through the N33 / N5 and N6 interfaces and has the capability' to communicate w ith other SEALDD servers via the SEALDD-E interface. The SEALDD server can access performance statistics from a Network Data Analytics Function (NWDAF) through a Network Exposure Function (NEF) over the N33 interface, configure service parameters to the Policy Control Function (PCF) over the N5 interface and receive data traffic from the User Plane Function (UPF) over the N6 interface.

[0007] The SEALDD architecture offers vertical applications end-to-end data delivery sen-ice as shown in FIG. 3. A VAL client on a UE may request SEALDD services from a SEALDD client over the SEALDD-C interface. The SEALDD client sends application data to a SEALDD server using SEALDD flows over the SEALDD-UU interface, which may span over multiple network nodes. Upon receiving the SEALDD data traffic, the SEALDD server forwards the application data to the corresponding VAL server. The SEALDD layer supports the redundant transmission feature to offer reliable communications between a VAL client and a VAL server by transmitting application data between two SEALDD flows and also supports SEALDD transmission quality measurements that may be used to optimize data delivery services.Access Traffic Steering, Switching, Splitting (ATSSS)

[0008] The Access Traffic Steering, Switching, Splitting (ATSSS) feature of the 5G system allows for traffic steering between 3GPP and non-3GPP accesses. (Note that in this paper the term '‘traffic steering” is used to include the functionality of steering, switching, and splitting data traffic.) This feature allows data traffic between a user equipment (UE) and a core network to be routed over cellular or non-cellular (e.g. such as wifi networks) access networks or over both access networks at the same time. FIG. 4 shows the architectural diagram of the ATSSS feature within the 5G system. The 3 GPP access represents the cellular access network while the non-3GPP access represents wifi or similar access networks. Note that both access networks are connected to the 5G network, which allows the UPF to control traffic steering between both access networks.

[0009] In order to utilize the ATSSS feature, a UE creates Multi-Access (MA) PDU sessions with both 3GPP and non-3GPP access networks. The core network returns ATSSS rules to configure the UE on how' to route uplink traffic and multi-access rules (MAR) to configure the UPF on how to route downlink traffic. Within the ATSSS and MAR rules are steering modes that indicates how the UE and UPF should steer traffic. The steering modes consists of Active- Standby, Smallest Delay, Load-Balancing, Priority -based, and Redundant (without Threshold Values). A steering mode indicator may also be specified for the Load- Balancing steering mode, which indicates a UE may decide how to adjust traffic. Two steering mode indicators are available but they are mutually exclusive of each other: autonomous and UE-assistance. Performance measurements betw een the UE and UPF areavailable to assist with determining quality of access networks and making traffic steering decisions.

[0010] Application traffic may encounter delays and degradation during its journey from source to destination. The ATSSS feature aims to address those issues within the context of the 5G network between a UE and a UPF. However, the feature is not able to account for traffic after data exits the UPF as it is outside the domain of the 5G network. In addition, if the ATSSS feature is not uniformly deployed in the 5G network (e.g. UE is moving from one area of the network that supports ATSSS to another area of the network that does not support ATSSS), the UE is required to release resources associated with MA-PDU sessions when in an area without ATSSS support and traffic steering is unavailable.

[0011] The SEALDD layer aims to offer end-to-end data delivery service between a UE and application servers and even provides measurement capabilities to assist with the data delivery service. Therefore, adding application layer traffic steering capabilities to the SEALDD layer may offer end-to-end data delivery transmission guarantee that the ATSSS feature is not able to provide. SEALDD clients and SEALDD servers may utilize existing SEALDD measurements as well as measurements exposed by the 5G network to make traffic steering decisions that best suits the application requirements, including influencing the use of ATSSS functionality (when available) in the 3GPP network. In addition, having traffic steering capability at the application layer allows UEs to perform traffic adaptation when the ATSSS functionality is not available.SUMMARY

[0012] With increasing demands from higher bandwidth applications such as AI / ML and AR / VR, traffic steering can play an important role to deliver the required bandwidth for those applications at application enabler layers. The ATSSS functionality in the 5G network provides traffic steering between a UE and a UPF in the 5G network but it does not extend to application servers. Enabling application layer traffic steering may provide an end-to-end traffic steering mechanism between application enabler clients and servers that can be dynamically adapted to meet the needs of the application.

[0013] In one aspect according to the disclosure, a method for an AEL server to (e.g., support AL traffic steering adaptation of FIGS. 6 and 7) can include: receiving a request from a VAL server for configuring traffic steering policy for one or more UEs. In some cases, the traffic steering policy can include one or more of: application identifier(s), ATSSScapabilities, steering mode, default traffic steering, measurement events, steering percentage range, bandwidth sharing policy, and expiration time. The method can also include sending a response to the VAL server, the response includes one or more of: request status. IP address and port number, and any updates to the traffic steering policy to reflect authorization limits for the traffic steering. The method can also include receiving application layer traffic flow requests for one or more access network connections, the requests include information about traffic steering policy and an identifier for the access network. The method can also include mapping the AEL client and traffic flow identifiers with the access network identifier and the VAL server identifier to enable traffic steering of application traffic. The method can also include subscribing to receive measurements and analytics from a core network and / or application server, the measurements and / or analytics are used to assist with traffic steering adaptation. The method can also include receiving traffic steering adaptation for one or more flows. The method can also include applying traffic adaptation to the one or more flows to an AEL client.

[0014] In another aspect, a method for an AEL client to (e.g., support AL traffic steering adaptation as shown in FIGS. 6, 7. and 8) can include: receiving a request from a VAL client for configuring traffic steenng policy for application traffic. In some cases, the traffic steering policy can include one or more of: application identifier(s), ATSSS capabilities, steering mode, default traffic steering, measurement events, steering percentage range, bandwidth sharing policy, and expiration time. The method can also include establishing or modifying a data session with one or more access networks, the one or more access networks may be 3GPP or non-3GPP access networks. The method can include the establishment or upgrade of an AEL flow to utilize AL traffic steering with an AEL server, the request to establish or upgrade the AEL flow include information from the traffic steering policy. The method can also include determining traffic steering adaptation decisions based on local measurements and UE conditions or context. In some cases, the UE conditions or context can include one or more of: available battery power or power management settings, signal strength of the different accesses, UE loading, background and foreground activities on the UE, and application settings. The method can also include sending a request to AEL server to adapt downlink traffic to the UE.

[0015] In another aspect, a method for an AEL client (e.g., support bandwidth sharing, shown in FIGS. 9 and 10): receiving a request from a VAL client for configuring trafficsteering policy with bandwidth sharing for a first application. In some cases, the bandwidth sharing policy can include one or more of: indication for allowing bandwidth sharing, and a maximum steering percentage for sharing the bandwidth. The method can also include receiving application data from both a first and a second application, the first application whose traffic steering configuration allows for bandwidth sharing. The method can also include steering data from second application onto the flow of first application, the steering percentage to not exceed the maximum steering percentage specified in bandwidth sharing policy. The method can also include sending a request to an AEL server to apply bandwidth sharing of data for the first and second applications on the downlink direction according to bandwidth sharing policy steering percentages.

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

[0017] FIG. 1 shows an application layer architecture model.

[0018] FIG. 2 shows a SEALDD architecture.

[0019] FIG. 3 shows a SEALDD application traffic transfer flow.

[0020] FIG. 4 shows non-roaming and roaming with location breakout architecture for ATSSS support.

[0021] FIG. 5 shows proposed paths to support application layer traffic steering.

[0022] FIG. 6 shows AL traffic steering with ATSSS.

[0023] FIG. 7 shows AL traffic steering without ATSSS.

[0024] FIG. 8 shows AL Traffic Steering upgrade of SEALDD redundant transmission.

[0025] FIG. 9 shows bandwidth sharing of clients and servers.

[0026] FIG. 10 shows bandwidth sharing bandwidth sharing with multiple SEALDD flows.

[0027] FIG. 11 shows a graphical user interface for traffic steering and bandwidth sharing.

[0028] FIG. 12A depicts an example communications system in which the methods and apparatuses described and claimed herein may be an aspect of;

[0029] FIG. 12B depicts a block diagram of an example apparatus or device configured for wireless communications;

[0030] FIG. 12C depicts a system diagram of an example radio access network (RAN) and core network;

[0031] FIG. 12D depicts a system diagram of another example RAN and core network;

[0032] FIG. 12E depicts a system diagram of another example RAN and core network;

[0033] FIG. 12F depicts a block diagram of an example computing system; and

[0034] FIG. 12G depicts a block diagram of another example communications system.DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

[0035] Application layer traffic steering may operate with or without the ATSSS feature as shown in FIG. 5, which is a modification of FIG. 4 with an additional non-3GPP access path that is outside the 5G system. Paths A and B represent the paths used for ATSSS and path C is a path established between a UE and an application server (AS) over non-3GPP access outside the 5G system. An application enabler layer (AEL) client on the UE and an AEL server on or connected to an AS may provide traffic steering at the application enabler or sen-ice layer. The AEL client and AEL server may be realized as SEAL / SEALDD client and server that provide the application layer traffic steering services proposed hereinafter. Note that other application enabler clients and servers may also offer the traffic steering sen ices such as edge enabler clients and servers. Hereinafter, the term SEALDD will be used to refer to both SEAL and SEALDD layers and SEALDD clients and servers will be used as examples when describing application layer traffic steering.

[0036] SEALDD clients and SEALDD servers may provide application layer traffic steering with or without the ATSSS feature. VAL servers and VAL clients may request data delivery service from the SEALDD layer that utilizes traffic steering. If the ATSSS feature is available, the request may trigger a SEALDD server to configure the 5G network to enable MA-PDU sessions for a UE of interest. In the absence of the ATSSS feature, the SEALDD server may steer traffic between a PDU session on 3GPP access and a session over non-3GPP access outside the 5G network.

[0037] Note that paths A and B shown in FIG. 5 indicate that one 3GPP access and one non-3GPP access are used for the ATSSS feature. However, it may be possible where traffic steering is also available when both accesses are 3GPP accesses, e.g. one access is NR (5G)and the other access is LTE (4G). As a result, the proposed solution is not limited to one 3GPP access and one non-3GPP accesses. For scenarios using two 3GPP accesses, the access networks may belong to different mobile network operators and hence, MA-PDU sessions may not be available.E2EAL Traffic Steering with ATSSS

[0038] End-to-End (E2E) Application layer (AL) traffic steering may be provided by the SEALDD layer in conjunction with the ATSSS feature in the 5G network, which may expose configuring ATSSS parameters by AFs (e.g. SEALDD server) using the AF service parameter API over the Network Exposure Function (NEF). With support of traffic steering at the SEALDD layer, VAL servers and VAL clients are able to request end-to-end traffic steering services for their application data. FIG. 6 shows an example procedure of application layer traffic steering support in SEALDD layer. Note that the figure shows that it is assumed the SEALDD server and the VAL server are co-located or closely deployed to each other to minimize the traffic delays between the two servers to achieve as close to end-to-end functionality as possible. The servers may even be deployed on the same compute node in the network to achieve true end-to-end functionality between the UE and the VAL server.

[0039] Step 1: A VAL server may identity’, be provisioned with, or discover a SEALDD server that is able to provide the data delivery sendee and application layer traffic steering required by an application. The VAL server may send a request to the SEALDD server that includes a traffic steering policy and the information listed in Table 1. A list of one or more UE identifiers for which the application layer traffic steering is requested for may also be included within the request. Alternatively, the SEALDD server may receive the traffic steering policy based on pre-provisioned policies.Table 1 - Request parameters for traffic steering

[0040] The SEALDD server may first authorize the VAL server is able to utilize application layer traffic steering and if authorized, assign IP address and port number of the SEALDD server to the VAL server for application data traffic communication with a VAL client. The VAL server may receive a response from the SEALDD server with a status to the request, the IP address and port number of the SEALDD server for application traffic, and any updates to the traffic steering policy that the SEALDD server may override, e.g. based on authorization limits for the VAL server. Alternatively, the configuration and authorizations functionality in this step may be performed in conjunction with other, non-AL traffic steering related SEALDD functionality’, and other VAL or core network triggers (e.g. notifications, measurements) may be used to prompt the subsequent steps.

[0041] Step 2: The SEALDD server may determine to configure ATSSS support for the UE with the 5G network and make an AF sen ice parameter API request. The SEALDD server may use the ATSSS capabilities and steering mode lEs in the traffic steering policy or localpolicies to make the determination. The request may include an AF identifier associated with the SEALDD server, a UE identifier for the UE to use traffic steering, and new service parameters for the ATSSS feature. The ATSSS parameters may consist of supported steering functionalities and steering modes, steering mode indicator, and threshold values for measurements. The SEALDD server may configure the ATSSS parameters such that ATSSS- LL steering functionality is specified with load-balancing steering mode and autonomous steering mode indicator. Alternatively, the UE-assistance steering mode indicator may be specified instead of autonomous steering mode indicator. These configurations may allow the UE, and hence the SEALDD client, the abi 1 i ty to adapt traffic steering at the application layer and to use the ATSSS feature to apply the adaptation to either 3GPP and / or non-3GPP accesses. As part of the service parameter API request, the 5G network may send URSP and ATSSS rules to the UE to configure the UE for using the ATSSS feature by establishing MA- PDU sessions over 3GPP and non-3GPP accesses. It may be that in addition to configuring the new ATSSS parameters that the SEALDD server may also need to configure URSP parameters as well. In certain cases, if the ATSSS parameters are configured out of band, e.g. through service level agreements or other configuration mechanisms, the SEALLD server may only need to configure URSP parameters for the UE.

[0042] Note that the ATSSS parameters and / or URSP rule configuration determined by the SEALDD server to be used in this step can use pre-provisioned AL traffic steering information, as well as UE and network context information. This allows the AL traffic steering information provided by application service providers to be abstracted and generalized from the already defined ATSSS rules and policies in 3GPP.

[0043] Step 3: A VAL client and VAL server may communicate with each other that application layer traffic steering is required / enabled for a desired application. The VAL client and VAL server may communicate this information in an out of band mechanism, such as over application layer signaling, an agreement between a user and a service provider, or through a registration made by a user to the service provider. Note also that this functionality may be implemented by alternative mechanisms, e.g. by AL traffic steering policy distribution between VAL and SEALDD servers and clients.

[0044] Step 4: A VAL client may make a service request for data delivery service in which traffic steering is requested for the application traffic. The VAL client may includeinformation from an AL traffic steering policy as shown in Table 1, such as an application identifier, default steering percentage, and measurement events.

[0045] Step 5: In response, the UE may request to establish MA-PDU sessions over 3GPP and non-3GPP accesses using the URSP rules received from the 5G network. PDU session 1 may be associated with 3GPP access while PDU session 2 may be associated with non-3GPP access. If enabled, ATSSS performance measurements may be configured betw een the UE and UPF.

[0046] Alternatively, this step may be performed by the UE based on pre-provisioned policies and be prompted by other application, VAL, SEALDD or netw ork triggers (e g. notifications, measurements).

[0047] Step 6: The SEALDD client may request to create SEALDD flows with a SEALDD server using the MA-PDU sessions that have been established. SEALDD flow 1 may be created for the MA-PDU session associated with the 3GPP access and SEALDD flow 2 may be created for the MA-PDU session associated with the non-3GPP access. The SEALDD client may map the SEALDD flow' identifier, application identifier, access network identifier, and VAL server identifier together for the particular application traffic. This information may be used by the SEALDD client to steer uplink traffic onto the appropriate access networks and route downlink traffic to the appropriate application clients.

[0048] Note that the SEALDD client is not necessarily aw are of the access network through the access netw ork identifier or has information about the access network. The identifier maybe used to map to the SEALDD flow identifier to assist with traffic steering and may be opaque to the SEALDD client which access network is carrying the traffic. For example, the access network identifier may be labeled as 1 and 2 where 1 is mapped to the 3GPP access network and 2 is mapped to the non-3GPP access network. In another example, access network identifier 1 may be associated with non-3GPP access network and access network identifier 2 associated with 3GPP access network. In certain cases, access netw ork identifiers 1 and 2 may be associated with two 3GPP access networks where one 3GPP access network is NR and the other access network is LTE. Table 2 shows example configuration parameters that the SEALDD client may include in the request to establish the SEALDD flows with the SEALDD server for each access network.Table 2 - Traffic steering configuration parameters| Information Element | Description |

[0049] The SEALDD server may also map the SEALDD client and SEALDD flow identifiers with the access network identifier and the VAL server identifier to enable traffic steering on downlink application traffic to the UE. In addition, the SEALDD server may assign IP address and port number to establish a connection with the VAL server for the application traffic if this information was not previously provided.

[0050] Step 7: A service response may be returned to the VAL client from the SEALDD client to indicate the SEALDD flows have been created for traffic steering. SEALDD flow information mappings may also be included in the response.

[0051] Step 8: The SEALDD client and SEALDD server may set up the collection of SEALDD measurements to assist with making traffic steering adaptation at the application layer. In addition, the SEALDD server may subscribe to QoS monitoring and network data analytics from the 5G network as well as application analytics from an ADAE server. The SEALDD client and SEALDD server may also receive VAL measurements from VAL clients and VAL servers. Using the available measurements and analytics, the SEALDD server may be able to adapt traffic steering accordingly. Similarly, a UE may use measurements that it collects as well as UE conditions or context to make traffic steering adaptation decisions. UE conditions or context may consist of available battery power or power management settings, signal strength of the different accesses, UE loading, background and foreground activities on the UE, application settings, etc.

[0052] Step 9: Application traffic steering may be performed by the SEALDD client and SEALDD server to steer traffic over SEALDD flows 1 and 2. Traffic may be split evenlybetween the two flows or according to default traffic steering provided in the traffic steering policy during ty pical network conditions. Traffic may be adjusted to reflect possible network congestion on one flow.

[0053] Step 10: At configured reporting intervals, the SEALDD client and server may receive SEALDD measurement reports for each SEALDD flow. The SEALDD client or server may also receive ATSSS performance or other measurements that may be exposed by the 5G network to help determine where congestion may be occurring to assist with making traffic steering decisions. The SEALDD client or server may also receive VAL performance measurements from VAL clients and VAL servers to help determine VAL loading and availability7to assist with making traffic steering decisions. If analytics were subscribed to, then analytics statistics and / or predictions may be used to assist with traffic steering as well.

[0054] Step 11: Using the measurements and / or analytics obtained at the SEALDD and / or ADAE layers, from the 5G network, and / or from the VAL client and server, the SEALDD client or server may adapt traffic accordingly. For example, if measurements are showing that PDU session 1 is experiencing sendee degradation, the SEALDD client may steer a larger percentage of uplink traffic over to SEALDD flow 2 and PDU session 2. Similarly, the SEALDD server may steer a larger percentage of dow nlink traffic to SEALDD flow 2 and PDU session 2. The SEALDD client may compare ATSSS measurements with SEALDD measurements to determine congestion points in the end-to-end paths and make traffic steering adaptation accordingly. Similarly, the SEALDD server may use SEALDD measurements and QoS reports / analytics results (e.g. statistics and predictions) from the 5G network to make traffic steering adaptation accordingly.

[0055] Table 3 shows example traffic adaptation parameters a SEALDD client may send to a SEALDD server, or vice versa, prior to adapting application data traffic on the SEALDD flow. One traffic adaptation percentage may be specified on access 1 and another traffic adaptation percentage may be specified on access 2. In addition, the SEALDD server may also use the measurements to determine how to steer mobile originated traffic load across multiple instances of VAL servers providing the same service to a VAL client. Bandwidth sharing may also be enabled and more detail will be described in the Bandwidth Sharing section hereinafter.Table 3 - Traffic adaptation parametersInformation Element

[0056] The traffic adaptation percentages may be viewed as requests by either the SEALDD client or SEALDD server requesting the traffic steering be adjusted on downlink and uplink transmissions, respectively. For example, a SEALDD server may send the traffic adaptation parameter to a SEALDD client that includes the SEALDD flow identifier and the UL traffic adaptation percentages for accesses 1 and 2. In response, the SEALDD client may acknowledge the request and adapt the traffic steering on accesses 1 and 2 to the new percentages. It may be such that only one traffic adaptation information element is needed as the directionality of the request is implied. For example, a request by a SEALDD client may imply downlink traffic adaptation and a request by a SEALDD server may imply uplink traffic adaptation.

[0057] The procedure described in FIG. 6 shows the SEALDD server making an AF service parameter API call to the 5G network to configure ATSSS parameters for a UE. It may be such that the ATSSS parameters for a UE is configured through sendee level agreements between a user of the UE and a mobile netw ork operator. The SEALDD server for these cases may not need to explicitly configure the ATSSS parameters for the UE withthe 5G network. The procedure shown by FIG. 6 for these cases may still apply for enabling application layer traffic steering as described with the exception of the removal of step 3. The UE is still able to use the ATSSS functionality as the 5G network would have been provisioned with the ATSSS parameters and provide the UE with ATSSS and URSP rules.

[0058] In addition, a VAL client, and hence a SEALDD client, may initiate a request to use application layer traffic steering capabilities when initiating a sendee request. For these scenarios, the VAL or SEALDD client may have been provisioned with the appropriate traffic steering policies, ATSSS rules, and / or URSP rules. The provisioning of the traffic steering policies may indicate the VAL / SEALDD client is authorized to utilize AL traffic steering. The procedure for client initiated AL traffic steering may be similar to FIG. 6, mainly from step 4 to step 11.

[0059] As shown, application layer traffic steering may provide a holistic view to account for end-to-end transmission of application data. The measurement events provided in the traffic steering policy may trigger when traffic adaptation may be performed. SEALDD measurements, such as latency, bit rate, jitter, and packet loss rate (PLR), may be enabled by either the SEALDD client or SEALDD server to monitor the quality of SEALDD flows, which may also indicate access network connection quality.

[0060] Thresholds may be provided to define measurement events to assist with determining the quality of a SEALDD flow. For example, a measurement event PLR > 2% may be used to signify issues with a SEALDD flow. The event may indicate that packet loss rate is greater than 2%, which may be unacceptable for a particular application. The SEALDD client or server may then steer a greater percentage of traffic to the other SEALDD flow . Similar measurement events may be defined for latency, bitrate, jitter, and other SEALDD measurements.

[0061] Analytics may also contribute to traffic adaptation determination. A SEALDD server may subscribe to receive notifications from network analytics performed within the 5G network. Analytics on slice and network function loading, observed service experience, network and WLAN performance, user data congestion, and UE related analytics may provide additional insights on whether SEALDD flows are receiving appropriate data delivery services. The SEALDD server may use the statistics and / or predictions generated from the analytics function in conjunction with SEALDD measurements to make traffic adaptation decisions for application data.

[0062] Application analytics may also be available and subscribed to by SEALDD servers and clients. Analytics such as application and slice-specify application performance, slice usage pattern, and edge load analytics may provide performance from the perspective of applications. The statistics and predictions from ADAE servers may also be used by SEALDD servers and clients to assist with traffic adaptation decisions.

[0063] VAL servers and clients may also provide information that may be used to assist with traffic adaptation decisions. A VAL server may indicate loading of the VAL server and / or latencies experienced by the VAL server for one or more applications that may impact the data delivery service. Similarly, a VAL client may report loading on a UE and other UE context information such as available battery power, access network signal strength, UE mobility, UE loading, etc.E2EAL Traffic Steering, without ATSSS

[0064] Previously, application layer traffic steering was described in the context of utilizing ATSSS function available at the 5G network. There may be cases, however, in which the ATSSS feature is not widely deployed and therefore is not available for a portion of the network. For these cases, enabling application layer traffic steering may enable vertical service providers the ability to provide their customers with certain performance guarantees that traffic adaptation may be able to provide. FIG. 7 shows an example procedure where the ATSSS feature is not available on the 5G network and a SEALDD client and server provide application layer traffic steering. In this scenario, a UE may establish a PDU session with the 5G network on 3GPP access while also having a session with a non-3GPP access network outside the 5G network such as wifi. Since the 5G network only has vi sibil ity for data traffic sent on the PDU session, it is not able to determine traffic steering adaptation. The SEALDD client and server, on the other hand, have access to the data traffic on both the 3GPP and non- 3GPP accesses and therefore are able to adapt the traffic accordingly. Note also the case when two 3GPP access networks of different mobile network operators are used, the ATSSS feature may also not be available and application layer traffic steering may offer the ability to adapt data traffic over multiple access networks.

[0065] Step 1: A VAL server may identify, be provisioned with, or discover a SEALDD server that is able to provide the data delivery sendee and application layer traffic steering required by an application. The VAL server may send a request to the SEALDD server that includes a traffic steering policy7and the information found in Table 1. A list of one or moreUE identifiers for which the application layer traffic steering is requested for may also be included within the request. Alternatively, the SEALDD server may receive the traffic steering policy based on pre-provisioned policies.

[0066] The SEALDD server may first authorize the VAL server is able to utilize application layer traffic steering and if authorized, assign IP address and port number of the SEALDD server to the VAL server for application data traffic communication with a VAL client. The VAL server may receive a response from the SEALDD server with a status to the request, the IP address and port number of the SEALDD server for application traffic, and any updates to the traffic steering policy that the SEALDD server may override, e g. based on authorization limits for the VAL server. Alternatively, the configuration and authorizations functionality in this step may be performed in conjunction with other, non- AL traffic steering related SEALDD functionality, and other VAL or core network triggers (e.g. notifications, measurements) may be used to prompt the subsequent steps.

[0067] Step 2: A VAL client and VAL server may communicate with each other that application layer traffic steering is required / enabled for a desired application. The VAL client and VAL server may communicate this information in an out of band mechanism, such as over application layer signaling, an agreement between a user and a service provider, or through a registration made by a user to the service provider. Note also that this functionality may be implemented by alternative mechanisms, e.g. by AL traffic steering policy distribution between VAL and SEALDD servers and clients.

[0068] Step 3: A VAL client may make a service request for data delivery service in which traffic steering is requested for the application traffic. The VAL client may include information from an AL traffic steering policy as shown in Table 1, such as an application identifier, default steering percentage, and measurement events. Note that the SEALDD server may have already configured parameters for the 5G network to generate URSP rules for the UE to establish a PDU session for the application traffic.

[0069] Step 4: A UE may establish a PDU session with the 5G network over 3GPP access.

[0070] Step 5: The UE may establish a session over non-3GPP access that is not connected to the 5G network, e.g. a wifi network connected with a broadband internet service provider. As an alternative, the UE may establish a PDU session with another mobile network operator over 3GPP or non-3GPP access. For this scenario, the PDU sessions are regular, single access PDU sessions for which there is no relation between the PDU sessions in different mobilenetwork operator networks and hence, the ATSSS functionality is not available. Note that application layer traffic steering may also apply to scenarios with a UE that has establish single access PDU sessions with the same operator network in which ATSSS functionality is not supported.

[0071] Step 6: The SEALDD client on the UE may establish a SEALDD flow 1 using the PDU session created in step 4 over the first access network. Similar to step 6 of FIG. 6, the SEALDD client may provide configuration parameters for the SEALDD flow as listed in Table 2 and perform the associated mappings involving the SEALDD flow identifier, application identifier, access network identifier, and VAL server identifier. Likewise, the SEALDD server performs a similar mapping as previously described.

[0072] Step 7: Similarly, the SEALDD client on the UE may establish a SEALDD flow 2 using the session created in step 5 over the second access network. The second access network can be 3GPP access or non-3GPP access of another mobile network operator, 3GPP access or non-3GPP access of the same mobile network operator without ATSSS capability, or a non-3GPP access outside the 5G network. The SEALDD client and server may perform similar mappings as was done for the first access network.

[0073] Step 8: A service response may be returned to the VAL client from the SEALDD client with the status of the request, including the indication of traffic steering enablement and SEALDD flow information mappings.

[0074] Step 9: For each SEALDD flow, the SEALDD client and SEALDD server may configure the collection of SEALDD measurements to assist with making traffic steering adaptation at the application layer. In addition, the SEALDD server may subscribe to QoS monitoring and network data analytics from the 5G network as well as application analytics from an ADAE server. The SEALDD client and SEALDD server may receive VAL measurements from VAL clients and VAL servers. Using the available measurements and analytics, the SEALDD server may be able to adapt traffic steering accordingly. Similarly, a UE may use measurements that it collects as well as UE conditions or context to make traffic steering adaptation decisions. UE conditions or context may consist of available battery power or power management settings, signal strength of the different accesses, UE loading, background and foreground activities on the UE, application settings, etc.

[0075] Step 10: Application traffic steering may be performed by the SEALDD client and SEALDD server to steer traffic over SEALDD flows 1 and 2. Traffic may be split evenlybetween the two flows or according to default traffic steering provided in the traffic steering policy during ty pical network conditions. Traffic may also be adjusted to reflect possible network congestion on one flow.

[0076] Step 11 : During data transmission, SEALDD measurements may be obtained by both the SEALDD client and SEALDD server. At the configured reporting intervals, measurement reports may be generated for the SEALDD client and server. The SEALDD server may also receive other measurements that may be exposed by the 5G network to help determine where congestion may be occurring to assist with making traffic steering decisions. The SEALDD client or server may also receive VAL performance measurements from VAL clients and VAL servers to help determine VAL loading and availability to assist with making traffic steering decisions. If analytics were subscribed to, then analytics statistics and / or predictions may be used to assist with traffic steering as well.

[0077] Step 12: Using the measurements and / or analytics obtained from the SEALDD and / or ADAE layers, the 5G network, and / or VAL client or server, the SEALDD client or server may adapt traffic accordingly. For example, if measurements are showing that SEALDD flow 1 is experiencing service degradation, the SEALDD client may steer a larger percentage of uplink traffic over to SEALDD flow 2. Similarly, the SEALDD server may steer a larger percentage of downlink traffic to SEALDD flow 2. The traffic adaptation may be made between the SEALDD client and SEALDD server using the information elements as shown in Table 3. Either the SEALDD client or server may request from the other traffic adaptation steering percentages on downlink and uplink paths, respectively. In addition, the SEALDD server may also use the measurements to determine how to steer mobile originated traffic load across multiple instances of VAL servers providing the same service to a VAL client.

[0078] Traffic adaptation may also be performed due to other criteria. For example, a SEALDD client may adapt traffic steering to an access that has a stronger signal with an access network such as when the user is within range of a strong wifi signal as opposed to a weaker cellular signal. The SEALDD client may also adapt traffic steering due to conditions on the UE that may not be reflected in the network. For example, a UE may steer traffic onto one access network due to low available battery power or due to battery saving mode configured for the UE. The UE may also adapt traffic due to UE loading, application settings,the presence of foreground and background applications, and other UE conditions or context (e.g. configurations).

[0079] As previously mentioned, the SEALDD layer already supports redundant transmission where reliability of data delivery service is provided by replicating application data over two SEALDD flows. It is proposed that AL traffic steering may be layered on top of the redundant transmission feature if requested by a VAL client (e g. due to user configuration) or a VAL serv er (e.g. to upgrade user experience) and SEALDD measurements of the redundant flows indicate good transmission quality. Good transmission quality may be measured for example by low latency values, high data bitrate, low jitter or packet loss rate, and / or other SEALDD measurements representing good transmission quality. The VAL client request may be triggered by a user changing application configuration, e.g. by increasing resolution and / or refresh rates of a gaming application or selecting to enable AL traffic steering feature. FIG. 8 shows an example procedure for upgrading SEALDD redundant transmission function to application layer traffic steering.

[0080] Step 1: SEALDD redundant transmission may have been enabled and currently in use as configured by a VAL client or VAL server. Two SEALDD flows have been established and used to transport replicated application data.

[0081] Step 2: A user of the UE may decide to enable AL traffic steering for a particular application. For example, the user may configure XR application settings to provide a more immersive experience or increased resolution and refresh rate settings in a gaming application. Alternatively, a VAL client may determine to enable AL traffic steering. For example, based on the execution flow and events taking place at the VAL client. In either case, the VAL client may send a sendee (or update) request to the SEALDD client with an AL traffic steering indicator and / or QoS requirement upgrade for the application. Not shown in FIG. 8 but a VAL sen- er may instead determine to enable AL traffic steering and may send a service (or update) request to the SEALDD server wdth an AL traffic steering indicator and / or QoS requirement upgrade for the application. The SEALDD server may perform an AF influence URSP procedure w ith the 5G netw ork, which is also not shown, for the UE to modify the PDU session from using redundant PDU sessions to regular PDU sessions.

[0082] Step 3: The SEALDD client and SEALDD server may evaluate SEALDD measurement reports to evaluate if the SEALDD flow-s have sufficiently good transmission qualify to support AL traffic steering capabilities.

[0083] Step 4: If the SEALDD measurement reports indicate sufficiently good transmission quality, the SEALDD client may request to upgrade the redundant transmission flows to AL traffic steering flows. The SEALDD client may include a traffic steering policy and other information as found in Table 2 in the request. A default traffic steering percentages may be provided in the traffic steering policy to configure the initial split percentages and measurement events may also be provided to enable dynamic traffic adaptation capabilities. Not shown in FIG. 8 but a SEALDD server may instead initiate the upgrade of redundant transmission flows to AL traffic steering flows.

[0084] Step 5: The SEALDD server may grant the upgrade request and enable AL traffic steering and respond with an acknowledgement. The response may include updates to the traffic steering policy made by the SEALDD server. Note that with redundant transmission, the two SEALDD flow s have the same SEALDD flow identifier but during the upgrade of the SEALDD flows to AL traffic steering, the SEALDD client or SEALDD server may change the SEALDD flow identifiers so the SEALDD flow s have different identifiers. This may be performed as part of the mapping of SEALDD flow identifier, application identifier, access network identifier, and VAL client / server identifier. The SEALDD server may configure SEALDD measurements and may also subscribe to network measurements and analytics from the 5G network. Both the SEALDD client and server may also subscribe to application layer analytics from an ADAE server to further evaluate transmission quality of the SEALDD flows.

[0085] Step 6: If necessary, the UE may modify the PDU session to not use redundant PDU sessions with the 5G network. Note that redundant PDU sessions may be created in support of SEALDD redundant transmission as described in step 1. Since the AL traffic steering is performed at the application layer, the redundant PDU sessions may be maintained without the knowledge of the 5G network. The SEALDD layer may manage the traffic steering and let traffic flow through the redundant PDU sessions. How ever, it may be such that the redundant PDU sessions may need to be modified to regular PDU sessions as a result of upgrading to AL traffic steering capability7. If this is the case, then the UE may need to perform a PDU session modification before applying AL traffic steering functionality.

[0086] Step 7: A service response may be returned to the VAL client from the SEALDD client with the status of the request, including the indication of traffic steering enablement and the SEALDD flow7information mappings.

[0087] Step 8: Application layer traffic steering may be performed by the SEALDD client and SEALDD server to steer traffic over SEALDD flows 1 and 2. Traffic may be split according to the default traffic steering percentages provided in the traffic steering policy between the two SEALDD flows.

[0088] Step 9: During data transmission, SEALDD measurements may be obtained by both the SEALDD client and SEALDD server. At the configured reporting intervals, measurement reports may be generated for the SEALDD client and server. The SEALDD server may also receive other measurements that may be exposed by the 5G network to help determine where congestion may be occurring to assist with making traffic steering decisions. The SEALDD client or server may also receive VAL performance measurements from VAL clients and VAL servers to help determine VAL loading and availability to assist with making traffic steering decisions. If analytics were subscribed to, then analytics statistics and / or predictions may be used to assist with traffic steering as well.

[0089] Step 10: Using the measurements obtained from the SEALDD and ADAE layers, the 5G network, and / or VAL client or server, the SEALDD client or server may adapt traffic accordingly. For example, if measurements are showing that SEALDD flow 1 is experiencing service degradation, the SEALDD client may steer a larger percentage of uplink traffic over to SEALDD flow 2. Similarly, the SEALDD server may steer a larger percentage of downlink traffic to SEALDD flow 2. The traffic adaptation may be made between the SEALDD client and SEALDD server using the information elements as shown in Table 3. Either the SEALDD client or server may request from the other traffic adaptation steering percentages on downlink and uplink paths, respectively. In addition, the SEALDD server may also use the measurements to determine how to steer mobile originated traffic load across multiple instances of VAL servers providing the same service to a VAL client. Bandwidth Sharing at AEL

[0090] Application layer traffic steering may also support the concept of bandwidth sharing within the application enabler layer. This concept applies traffic steering to sharing the bandwidth of one application with another application. FIG. 9 illustrates the concept in more detail.

[0091] A user on a UE may be playing a game in the foreground and downloading a large application or machine learning model in the background. An AEL client on the UE may be configured to detect the concurrent activities for network bandwidth and may adapt thebackground activity to using a smaller percentage of its network bandwidth and sharing the remainder of the bandwidth with the foreground activity. The AEL client may have been provisioned with a traffic steering policy in which bandwidth sharing is configured and enabled. In this approach, more network bandwidth may be allocated to the foreground activity' than the background activity'. In effect, the AEL client may share part of the bandwidth of the background activity with the foreground activity'. An example will be provided to illustrate the bandwidth sharing that may be performed by an AEL layer.

[0092] From the example shown in FIG. 9, application 1 may be the gaming application while application 2 may be the downloading application. The user may have configured the gaming application to use higher resolution and refresh rates settings that require more bandwidth. Meanwhile, the downloading application may not have as much urgency to complete as it is a background task. The traffic steering policy for application 2 may specify that bandwidth sharing is allowed. The AEL client may detect the opportunity to share the bandwidth of application 2 with application 1 and request the AEL server to steer a portion of application 1 data onto the access of application 2. Note in this case, traffic steering is still performed for application 1 over both 3GPP and non-3GPP accesses. Application 2, however, may only be using one access as it is a background task and can use either 3GPP or non- 3GPP access. In the example of FIG. 9, application 2 is using non-3GPP access.

[0093] After receiving the traffic steering request, the AEL server may start to steer a portion (e.g. 50%) of application 1 data onto the application 2 access as shown in the figure. The AEL server and AEL client may continue to perform traffic steering of application 1 data over both 3GPP and non-3GPP accesses using a ratio of 30% and 70%, respectively. Upon receiving the data, the AEL client may separate application 1 data from application 2 data and combine with the remaining application 1 data received on the other access to send to the application 1 client. Similarly, the AEL client may send application 2 data to the application 2 client. Note that while FIG. 9 only shows bandwidth sharing for downlink traffic, bandwidth sharing may also apply to uplink traffic. For example, the AEL client may send 50% of application 2 data and 50% of application 1 data to the AEL server.

[0094] Prior to the use of bandwidth sharing between applications, the AEL server and client may be configured with such capabilities. For an AEL server, a VAL server may provide a bandwidth sharing policy that may include an indicator to enable the feature, a list of application identifiers that may request the feature, and a maximum traffic steeringpercentage as shown in Table 1. An AEL client may also be provisioned with such policy either by the AEL server, as part of a configuration for a service provider, or through local configuration.

[0095] FIG. 9 shows application 2 using a single access network for its traffic. It may be that a UE may be able to also use multiple accesses for application 2 traffic as well. For example, a UE may have the capability to use two 3GPP accesses, e.g. an NR access and an LTE access. For those cases, application 2 may use a 3GPP access and a non-3GPP access. The traffic steering may therefore be simplified where application 2 traffic may be steered onto one access while application 1 traffic is steered on the other access. Note also that the non-3GPP access may be connected to the cellular network or connected to a broadband network that is outside the cellular network.

[0096] Bandwidth sharing may also apply to SEALDD redundant transmission scenarios involving multiple VAL servers where application data are sent between two VAL clients on a UE and two VAL servers using redundant transmission as documented in [1], In this scenario, two SEALDD flows are configured for redundant transmission and carry traffic between two VAL clients and two VAL servers. The bandwidth of one application (e.g. app2) may be shared with another application (e.g. appl) as shown in Figure 10. The redundant transmission of SEALDD flow 1 has been upgraded to enable AL traffic steering similar to the procedure shown in Figure 8. Note the SEALDD flow 1 identifier have been changed to different identifiers for AL traffic steering.

[0097] SEALDD flow 2. on the other hand, may’ continue to use redundant transmission and share 50% of the bandwidth for application 1 data. However, SEALDD flow' 2 may also be upgraded to AL traffic steering in a similar fashion as SEALDD flow' 1 and traffic steering may be adapted according to SEALDD measurements, netw ork performance measurements, network and application layer analytics, and VAL client / server measurements and requests. As a result, application traffic adaptation may be performed for both applications 1 and 2. An example of where this scenario may' be useful is the case where picture-in-picture is utilized and application layer traffic adaptations may be required for two applications.User Interface

[0098] A graphical user interface (GUI) may be presented to users of a UE for enabling traffic steering and bandwidth sharing capabilities as shown in the example of FIG. 11. The GUI example show s the configuration of capabilities for different applications as part of atraffic steering configuration for a UE. Within the configuration window, a selection can be made for a particular application and options may be presented to enable traffic steering and / or allow bandwidth sharing for that application. A Settings button may appear for a user to configure additional settings for traffic steering and / or bandwidth sharing. The features may be configured with maximum steering percentages, access identifiers, and duration the features are enabled / allowed for.Example Communications System

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

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

[0101] FIG. 12A illustrates an example communications system 100 in which the methods and apparatuses described and claimed herein may be an aspect of. As shown, the example communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, 102e, 102f, and / or 102g (which generally or collectively may be referred to as WTRU 102), a radio access network (RAN) 103 / 104 / 105 / 103b / l 04b / l 08B. a core network 106 / 107 / 109, a public switched telephone netw ork (PSTN) 108, the Internet 110, other networks 112, and V2X server (or ProSe function and server) 113, though it will be appreciated that the disclosed examples contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c. 102d, 102e, 102f, 102g may be any type of apparatus or device configured to operate and / or communicate in a wireless environment. Although each WTRU 102a, 102b, 102c, 102d, 102e, 102f, 102g is depicted in FIGS. 12A-12E as a hand-held wireless communications apparatus, it is understood that with the wide variety of use cases contemplated for 5G wireless communications, each WTRU may comprise or be embodied in any type of apparatus or device configured to transmit and / or receive wireless signals, including, by way of example only, user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a tablet, a netbook, a notebook computer, a personal computer, a wireless sensor, consumer electronics, a w earable device such as a smart watch or smart clothing, a medical or eHealth device, a robot, industrial equipment, a drone, a vehicle such as a car, truck, train, or airplane, and the like.

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

[0103] The base station 114a may be part of the RAN 103 / 104 / 105, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114b may be part of the RAN 103b / l 04b / 105b, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114a may be configured to transmit and / or receive w ireless signals within a particular geographic region, which may be referred to as a cell (not shown). The base station 114b may be configured to transmit and / or receive wired and / or wireless signals within a particular geographic region, which may be referred to as a cell (not shown). The cell may further be divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, the base station 114a may include three transceivers, e.g., one for each sector of the cell. In some cases, thebase station 114a may employ multiple-input multiple output (MIMO) technology and, therefore, may utilize multiple transceivers for each sector of the cell.

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

[0105] The base stations 114b may communicate with one or more of the RRHs 118a, 118b, TRPs 119a, 119b, and / or RSUs 120a and 120b, over a wired or air interface115b / l 16b / l 17b, which may be any suitable wired (e.g., cable, optical fiber, etc.) or wireless communication link (e g., radio frequency (RF). microw ave, infrared (IR), ultraviolet (UV), visible light, cmWave. mmWave, etc.). The air interface 118B / 116b / l 17b may be established using any suitable radio access technology (RAT).

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

[0107] The WTRUs 102a, 102b, 102c,102d, 102e, 102f, and / or 102g may communicate with one another over an air interface 115d / l 16d / l 17d (not shown in the figures), which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, cmWave, mmWave, etc.). The air interface118D / 116d / l 17d may be established using any suitable radio access technology (RAT).

[0108] More specifically, as noted above, the communications system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a in the RAN 103 / 104 / 105 and the WTRUs 102a, 102b, 102c, or RRHs 118a, 118b, TRPs 119a. 119b and RSUs 120a, 120b, in the RAN 103b / 104b / 105b and the WTRUs 102c, 102d. 102e. 102f. may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 115 / 116 / 117 or 115c / l 16c / l 17c respectively using widebandCDMA (WCDMA). WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High-Speed Downlink Packet Access (HSDPA) and / or High-Speed Uplink Packet Access (HSUPA).

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

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

[0111] The base station 114c in FIG. 12A may be a wireless router, Home Node B. Home eNode B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity' in a localized area, such as a place of business, a home, a vehicle, a campus, and the like. In some cases, the base station 114c and the WTRUs 102e, may implement a radio technology such as IEEE 802. 11 to establish a wireless local area network (WLAN). In some cases, the base station 114c and the WTRUs 102d, may implement a radio technology7such as IEEE 802.15 to establish a wireless personal area network (WPAN). In some cases, the base station 114c and the WTRUs 102e, may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM. LTE, LTE-A, etc.) to establish a picocell or femtocell. As shown in FIG. 12A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 1 14c may not be required to access the Internet 110 via the core network 106 / 107 / 109.

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

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

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

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

[0116] FIG. 12B is a block diagram of an example apparatus or device configured for wireless communications in accordance with the aspects illustrated herein, such as for example, a WTRU 102. As shown in FIG. 12B, the example WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 113, a display / touchpad / indicators 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and other peripherals 138. It will be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an example. Also, in some cases the base stations 114a and 114b, and / or the nodes that base stations 1 14a and 114b may represent, such as but not limited to transceiver station (BTS), aNode-B, a site controller, an access point (AP), a home node-B, an evolved home node-B (eNodeB), a home evolved node-B (HeNB), a home evolved node-B gateway, and proxy nodes, among others, may include some or all of the elements depicted in FIG. 12B and described herein.

[0117] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality7of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other ty pe of integrated circuit (IC), a state machine, and the like. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120. which may be coupled to the transmi t / receive element 122. While FIG. 12B depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

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

[0119] In addition, although the transmit / receive element 122 is depicted in FIG. 12B as a single element, the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in some cases, the WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 115 / 116 / 117.

[0120] The transceiver 120 may be configured to modulate the signals that are to be transmitted by the transmit / receive element 122 and to demodulate the signals that are received by the transmit / receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as UTRA and IEEE 802. 11 , for example.

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

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

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

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

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

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

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

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

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

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

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

[0132] FIG. 12D is a system diagram of the RAN 104 and the core netw ork 107. As noted above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b. and 102c over the air interface 116. The RAN 104 may also be in communication with the core netw ork 107.

[0133] The RAN 104 may include eNode-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an aspect of the disclosure. The eNode-Bs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In some cases, the eNode-Bs 160a, 160b, 160c may implement MIMO technology. Thus, the eNode-B 160a, for example, may use multiple antennas to transmit wireless signals to. and receive wireless signals from, the WTRU 102a.

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

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

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

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

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

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

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

[0141] As shown in FIG. 12E, the RAN 105 may include base stations 180a, 180b, 180c, and an ASN gateway 182, though it will be appreciated that the RAN 105 may include any number of base stations and ASN gateway s while remaining consistent with an aspect of the disclosure. The base stations 180a, 180b, 180c may each be associated with a particular cell in the RAN 105 and may include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 117. In some cases, the base stations 180a, 180b, 180c may implement MIMO technology. Thus, the base station 180a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a. The base stations 180a, 180b, 180c may also provide mobility management functions, such as handoff triggering, tunnel establishment, radio resource management, traffic classification, quality of service (QoS) policy enforcement, and the like. The ASN gateway 182 may serve as a traffic aggregation point and may be responsible for paging, caching of subscriber profiles, routing to the core network 109. and the like.

[0142] The air interface 117 between the WTRUs 102a, 102b, 102c and the RAN 105 may be defined as an R1 reference point that implements the IEEE 802.16 specification. Inaddition, each of the WTRUs 102a, 102b, and 102c may establish a logical interface (not shown) with the core network 109. The logical interface between the WTRUs 102a, 102b, 102c and the core network 109 may be defined as an R2 reference point, which may be used for authentication, authorization, IP host configuration management, and / or mobility management.

[0143] The communication link between each of the base stations 180a, 180b, and 180c may be defined as an R8 reference point that includes protocols for facilitating WTRU handovers and the transfer of data between base stations. The communication link between the base stations 180a, 180b, 180c and the ASN gateway 182 may be defined as an R6 reference point. The R6 reference point may include protocols for facilitating mobility management based on mobility events associated with each of the WTRUs 102a, 102b, 102c.

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

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

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

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

[0148] FIG. 12F is a block diagram of an exemplary computing system 90 in which one or more apparatuses of the communications netw orks illustrated in FIGS. 12A, 12C, 12D and 12E may be embodied, such as certain nodes or functional entities in the RAN 103 / 104 / 105, Core Network 106 / 107 / 109, PSTN 108, Internet 110, or Other Networks 112. Computing system 90 may comprise a computer or server and may be controlled primarily by computer readable instructions, w hich may be in the form of software, w herever, or by whatever means such software is stored or accessed. Such computer readable instructions may be executed within a processor 91, to cause computing system 90 to do work. The processor 91 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC). a state machine, and the like. The processor 91 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the computing system 90 to operate in a communications network.Coprocessor 81 is an optional processor, distinct from main processor 91, that may perform additional functions or assist processor 91. Processor 91 and / or coprocessor 81 may receive, generate, and process data related to the methods and apparatuses disclosed herein.

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

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

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

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

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

[0154] FIG. 12G illustrates an example communications system 1 11 in which the methods and apparatuses described and claimed herein may be an aspect of. As shown, the example communications system 111 may include wireless transmit / receive units (WTRUs) A, B, C, D, E. F, a base station, a V2X server, and a RSUs A and B, though it will be appreciated that the disclosure contemplates any number of WTRUs, base stations, networks, and / or network elements. One or several or all WTRUs A, B, C, D, E may be out of range of the network (for example, in the figure out of the cell coverage boundary show n as the dash line). WTRUs A, B. C form a V2X group, among which WTRU A is the group lead and WTRUs B and C are group members. WTRUs A, B, C, D, E, F may communicate over Uu interface or Sidelink (PC5) interface.

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

[0156] Provided below are definitions for abbreviations found within the body of the disclosure.

Claims

What is claimed:

1. An apparatus, comprising: one or more processors; memory; and a set of computer-executable instructions that, when executed by the one or more processors, cause the apparatus to: receive, from a vertical application layer (VAL) server, a traffic steering policy and one or more request parameters for traffic steering; send, to the VAL server, a response comprising: a request status, application traffic information for the apparatus, traffic steering policy updates, or a combination thereof; receive, for one or more access network connections, one or more application layer traffic flow requests; enable traffic steering of application traffic according to the traffic steering policy by mapping an application enablement layer (AEL) client of a WTRU and one or more traffic flow identifiers with the one or more request parameters and information of the one or more application traffic flow requests; and initiate collecting of measurements for assisting in traffic steering adaptation decisions, wherein the measurements comprise end-to-end measurements, QoS monitoring, VAL layer measurements, network analytics, application analytics, or a combination thereof.

2. The apparatus of claim 1 , wherein the one or more request parameters for traffic steering comprise: a VAL server identifier, application data traffic identification information, a WTRU identifier, uality of service (QoS) requirements, or a combination thereof.

3. The apparatus of claim 1, wherein the one or more application layer traffic flow requests comprise: information corresponding to the traffic steering policy, an identifier for an access network of the one or more access networks, or both.

4. The apparatus of claim 1, wherein the traffic steering policy comprises an application identifier, a default traffic steering policy, traffic adaptation trigger events, steering ranges, bandwidth sharing policies, user policies, an expiration time, or a combination thereof.

5. The apparatus of claim 1, wherein the set of computer-executable instructions, when executed by the one or more processors, further cause the apparatus to: establish one or more data sessions with the one or more access networks, wherein the communicating is over the one or more data sessions.

6. The apparatus of claim 5, wherein the one or more access networks comprise a 3 GPP access network and a non-3GPP access network, and wherein the one or more data sessions comprises a 3GPP data session and a non-3GPP data session.

7. The apparatus of claim 1, wherein the set of computer-executable instructions, when executed by the one or more processors, further cause the apparatus to: send, to a core network or application server, a subscription request to receive measurement or analytics data corresponding to the communicating.

8. The apparatus of claim 7, wherein the set of computer-executable instructions, when executed by the one or more processors, further cause the apparatus to: receive for the one or more network access connections and based on the subscription request, the measurement or analytics data.

9. The apparatus of claim 1, wherein the set of computer-executable instructions, when executed by the one or more processors, further cause the apparatus to: receive information corresponding to the traffic steering policy; determine, based on the information corresponding to the traffic steering policy, one or more traffic adaptation trigger events are met; and adapt the communicating with the WTRU based on the determining.

10. The apparatus of claim 9, wherein the adapting comprises adjusting a traffic percentage across a network access connection of the one or more network access connections.

11. The apparatus of claim 1, wherein the set of computer-executable instructions, when executed by the one or more processors, further cause the apparatus to: receive, from the WTRU, a request to adapt downlink traffic to the WTRU: and adapt the communicating with the WTRU based on the request.

11. The apparatus of claim 1, wherein the apparatus comprises an AEL server.

12. The apparatus of claim 1, wherein the set of computer-executable instructions, when executed by the one or more processors, further cause the apparatus to: receive, from the WTRU, a request for configuring a bandwidth sharing policy with for an application; receive application data for a first application and a second application each corresponding to a traffic steering configuration, wherein the traffic steering configuration of the first application permits bandwidth sharing with the second application; and sending traffic of the first application and the second application to the WTRU and according to the traffic steering configuration of the first application.

13. The apparatus of claim 12, wherein the sending the traffic further comprises sending traffic for the second application over a data session of the first application.

14. The apparatus of claim 12, wherein the bandwidth sharing policy comprises: an indication for permitting bandwidth sharing, a maximum steering for sharing a bandwidth, or both.

15. A method performed by an application enablement layer (AEL) server, comprising: receiving, from a vertical application layer (VAL) server, a traffic steering policy and one or more request parameters for traffic steering;sending, to the VAL server, a response comprising: a request status, application traffic information for the apparatus, traffic steering policy updates, or a combination thereof; receiving, for one or more access network connections, one or more application layer traffic flow requests; enabling traffic steering of application traffic according to the traffic steering policy by mapping an AEL client of a WTRU and one or more traffic flow identifiers with the one or more request parameters and information of the one or more application traffic flow requests; and initiating collecting of measurements for assisting in traffic steering adaptation decisions, wherein the measurements comprise end-to-end measurements, QoS monitoring, VAL layer measurements, network analytics, application analytics, or a combination thereof.

16. The method of claim 15, wherein the one or more request parameters for traffic steering comprise: a VAL server identifier, application data traffic identification information, a WTRU identifier, QoS requirements, or a combination thereof.

17. The method of claim 15, wherein the one or more application layer traffic flow requests comprise: information corresponding to the traffic steering policy, an identifier for an access network of the one or more access networks, or both.

18. The method of claim 15, wherein the traffic steering policy comprises an application identifier, a default traffic steering policy, traffic adaptation trigger events, steering ranges, bandwidth sharing policies, user policies, an expiration time, or a combination thereof.

19. The method of claim 15, further comprising: establishing one or more data sessions with the one or more access networks, wherein the communicating is over the one or more data sessions.

20. The method of claim 19, wherein the one or more access networks comprise a 3GPP access network and a non-3GPP access netw ork, and wherein the one or more data sessions comprises a 3GPP data session and a non-3GPP data session.

Images