Seamless Edge Application Handover

Abstract

An edge application handover client in a user equipment can use application client information, such as type service, provider, location, context, and service requirements, to facilitate seamless edge application handover of the application client between edge application servers. For example, the handover client can use the context information to determine the expected route of the user equipment and thereby determine the next edge application server for handoff. The handover client can evaluate the needs of multiple application clients when selecting a server for handover. The handover client can issue requests to the server to request assistance in the handover operation, can issue subscription requests to the server, and can further determine handover success by monitoring application state synchronization or transition between edge application handover servers.

Description

[Technical field]

[0001] (CROSS REFERENCE TO RELATED APPLICATIONS) This application claims the benefit of U.S. Provisional Patent Application No. 62 / 951,377, filed December 20, 2019, entitled "Seamless Edge Application Handover," the contents of which are incorporated herein by reference. [Background technology]

[0002] Deployment of Machine-to-Machine (M2M), Internet of Things (IoT), and Web of Things (WoT) networks may involve a wide variety of servers, gateways, and devices, such as those described in, for example, 3GPP Application Layer Support for Vehicle-to-Everything (V2X) Services (3GPP® TS23.286 v16.1.0), 3GPP Study on Extensions to Application Layer Support for V2X Services (3GPP TR23.764, v0.2.0), 3GPP Study on Application Architectures to Enabling Edge Applications (3GPP TR23.758, v1.0.0), oneM2M 3GPP Interworking (oneM2M TS-0026, v4.2.0), and Open Mobile Alliance (OMA) Lightweight Machine-to-Machine (LWM2M) Protocol v1.1. Summary of the Invention

[0003] The Edge Application Handover Client (EAHC) function is hosted on a UE that performs one or more of the following operations and can assist an Application Client (AC) on the UE with handover between different instances of an Edge Application Server (EAS) in the system.

[0004] The EAHC function on the UE may be a new dedicated function or may be a sub-function of an existing function such as 3GPP Edge Enabler Client, 3GPP V2X Application Enabler Client, oneM2M Common Service Entity (CSE), oneM2M AE, or LWM2M Client.

[0005] The EAHC can support the ability to configure EAH policies. An EAH policy can include criteria used to determine which EAH actions the EAHC should perform and under what conditions these actions should be performed. An EAH policy can include rules that condition: The type of service requested ·Users, subscribers and / or ACs Network and / or service providers QoS / QoE Levels UE location(s) - UE's designated route(s) or predicted route(s) The edge or local area data network instance to which the UE is connected The status or availability of the edge node · Deployment status of requested services

[0006] The EAHC may support the ability to interface with ACs hosted on the UE to enable the ACs to share their past, current, or future application service requirements and context information with the EAHC. The EAHC may store and process this information locally to assist in seamless edge application handover of ACs between EASs. The EAHC may take this context into account in determining if / when handover of an AC from one EAS to another is required. The EAHC may also share this information with the EAHS in the network to assist the AC in managing seamless edge application handover between EASs.

[0007] By interfacing with the AC on the UE, the EAHC can also support the ability of the AC to initiate EAH. For example, if the AC detects that the level of service it is receiving from the EAS does not meet its requirements, the AC may initiate EAH via a request to the EAHC. The EAHC can receive such requests from the AC and assist the AC by performing EAH operations on their behalf.

[0008] The EAHC may support the ability to analyze service requirements and context information regarding the AC, the EAS, and the network(s) interconnecting the AC and the EAS. Based on this analysis and the EAH policy, the EAHC may determine if / when an EAH is required. The EAHC may trigger the AC to perform the EAH operation. Alternatively, the EAHC may perform the EAH operation on behalf of the AC to assist in the execution of the EAH.

[0009] Since the EAHC may be aware of the service requirements and context information of all ACs hosted on the UE, the EAHC may aggregate this information to make an optimized EAH decision across all ACs on the UE. For example, if a single edge node in the network supports all EASs required by different ACs on the UE, the EAHC may determine that an EAH operation that causes the ACs to use the EASs hosted on this single edge node is desirable because the UE may operate in a more efficient manner (e.g., the UE only needs a single PDU session to a single edge node).

[0010] The EAHC may issue a request to one or more EAHSs in the network to assist them in the EAH operation. One type of request may include a request to obtain information about available EASs that are in the current vicinity of the UE (e.g., in the same LADN) and are the best candidate EASs for the AC to be handed over.

[0011] The EAHC may issue subscription request(s) to the EAHS in the network to receive notifications from the EAHS. One type of subscription may be to receive notifications if / when the EAHS determines that an AC should be handed off from one EAS to another.

[0012] Based on the subscription request to the EAHS, the EAHC can receive notifications from the EAHS. One type of notification may be a trigger to the EAHC to perform an EAH operation for one or more specified ACs.

[0013] The EAHC can perform EAS FQDN resolution assistance operations when an EAH occurs. To minimize the impact of the EAH on the AC and to allow the AC to continue using the same EAS FQDN before and after an EAH occurs, the EAHC can perform EAS FQDN resolution operations on behalf of the AC. This allows the AC to communicate with the EAS using the same EAS FQDN even after an EAH occurs. Thus, the AC does not bear the burden of managing lower-level EAS point-of-contact information (e.g., IP addresses, ports, URIs), which may become stale after an EAH occurs. Instead, the EAHC can handle this burden on behalf of the AC.

[0014] The EAHC can perform security session establishment and teardown in an EAH-aware manner on behalf of the AC. These operations can be performed by the EAHC when the EAHC triggers the EAH or in response to an EAH request that the EAHC receives from the AC or the EAHS.

[0015] The EAHC can trigger and monitor application state synchronization or migration between EASs during the EAH, and based on the status of the state synchronization or migration, determine whether the EAH was successful or whether another EAH is needed.

[0016] The EAHC can buffer outgoing requests from the AC to the EAS while EAH operations are being performed (e.g., refreshing DNS lookup results, migrating state information to the new EAS, etc.) Once the EAH operations are completed and the new EAS is accessible, the EAHC can forward these requests to the new EAS for processing.

[0017] The Edge Application Handover Server (EAHS) function may perform one or more of the following operations to support an Application Client (AC) hosted on a UE with seamless handover between different instances of an Edge Application Server (EAS) in the system:

[0018] The EAHS may be a standalone function or a sub-function of an existing EAHS, such as a V2X Application Enabler Server, a SEAL Server, an Edge Enabler Server, an Edge Data Network Configuration Server, a oneM2M CSE, or an LWM2M Server.

[0019] The EAHS can support the ability to configure EAH policies. EAH policies can include rules that are used to determine which EAH actions the EAHS should perform and under what conditions these actions should be performed. EAH policies can include rules that condition: The type of service requested ·Users, subscribers and / or ACs Network and / or service providers QoS / QoE Levels UE location(s) - UE's designated route(s) or predicted route(s) The edge or local area data network instance to which the UE is connected The status or availability of the edge node · Deployment status of requested services

[0020] EAHS policy rules may be conditioned on context information relating to information such as the current location of the UE, the planned or predicted route of the UE, status information relating to the network (eg, congestion levels), and the like.

[0021] The EAHS can interface with and receive context information from various entities in the 3GPP system, including but not limited to a Core Network Function, an Application Client, an Edge Enabler Client, an Edge Application Handover Client, a V2X Application Enabler Server, a SEAL Server, an Edge Enabler Server, an Edge Data Network Configuration Server, a oneM2M CSE, or an LWM2M Server.

[0022] Based on the EAH policy, the EAHC can analyze context information and service requirements from entities in the system and determine whether / when an EAH is needed. The EAHS can trigger the EAHC to perform EAH operations on behalf of the AC and assist the EAHC to perform the EAH.

[0023] The EAHS may receive a subscription request(s) from the EAHC hosted on the UE and receive notifications from the EAHS. One type of subscription may be to receive notifications if / when the EAHS determines that the AC should be handed off from one EAS to another EAS.

[0024] Based on a subscription request from the EAHC, the EAHS may send a notification to the EAHC. One type of notification may be a trigger to the EAHC to perform an EAH action for one or more specified ACs.

[0025] The EAHS can interface with management function(s) within the system to query and discover available edge nodes that host (or are capable of hosting) one or more specified types of EAS.

[0026] The EAHS may further specify queried edge nodes that are located in close proximity to the specified UE and / or along the expected route of the UE.

[0027] Based on the EAH policy and associated context information, the EAHS can determine if / when an edge node (e.g., an edge node in proximity to the AC's current location or along the expected route) needs to perform an EAS management operation.

[0028] The EAHS can interface with management function(s) in the system to manage the deployment of EAS and installed EAS instances on available edge nodes (e.g., edge nodes in proximity to the AC's current location or along the expected route).

[0029] The EAHS may assist the management function(s) in the system by sharing EAH-related context information and / or by performing the EAH required by the management function(s).

[0030] The EAHS can help the management function(s) in the system interact with the service provider to trigger management actions (e.g., deployment of a new EAS, installation / activation of the EAS). The EAHS can interface with 3GPP network functions to configure and reserve connectivity-centric resources in the 3GPP network (e.g., QoS sessions) between an AC on the UE and an EAS in proximity to the UE's current location or along the expected route.

[0031] The EAHS can send a request to the EAHC to instruct the EAHC to refresh the cached DNS lookup results for the specified EAS FQDN by having the EAHC perform another DNS lookup. The request can also instruct the EAHC to switch to a new DNS server to perform the lookup by providing the EAHC with updated DNS server contact information. Before issuing the request to the EAHC, the EAHS can first initiate an update of the EAS contact information stored in the DNS records of the DNS server so that the EAS FQDN is mapped to a different EAS.

[0032] When handover of the AC to a new EAS occurs, the EAHS can share the AC's credentials with the new EAS via the secure communication session that exists between the EAHS and the EAS. The EAHS can also share the EAS's credentials with the EAHC via the secure communication session that exists between the EAHS and the EAHC. During this process, the EAHS can also communicate with security functions in the network if new / updated credentials are needed.

[0033] When an EAH occurs, the EAHS can help establish trust relationships so that the EASs involved in the handoff with each other can securely perform handoff operations, such as secure synchronization / migration of application state. When a handover of an AC to a new EAS occurs, the EAHS can share the credentials of the old EAS with the new EAS and vice versa.

[0034] When an EAH occurs, the EAHS can trigger and monitor the application state synchronization or migration operations that occur between the EASs during the EAH. Based on the status of the application state synchronization or migration, the EAHS can determine whether the EAH was successful or whether another EAH is required.

[0035] Using the context information, a predicted route is calculated by the EAHS, which can then be used to select the next EAS(s) to which the AC(s) hosted on the UE will be handed off. The EAHS can monitor the current position of the UE(s) relative to different waypoints defined by the route and track the UE's movement along the route as well as any unexpected deviations.

[0036] The EAHS can share predicted route information for one or more UEs with the 3GPP network so that the network can configure and optimize its network resources to ensure that the requirements (e.g., QoS) of the UE(s) are met while traveling along the route.

[0037] The EAHS may request that the 3GPP network track the movement of the UE(s) along a predicted route on its behalf and send notifications regarding the UE(s) movement along the route, such as notifications when the UE(s) arrive at a specified waypoint along the route or when the UE deviates from the route.

[0038] 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. Moreover, the claimed subject matter is not limited to limitations that solve any or all of the disadvantages noted in any part of the present disclosure. [Brief description of the drawings]

[0039] A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings, in which: [Figure 1]FIG. 1 is a block diagram of an example of the use of edge and cloud V2X application servers by a V2X application client on a user equipment (UE). [Diagram 2] FIG. 2 is a block diagram of an example 3GPP architecture for enabling edge applications. [Diagram 3] 3 is a block diagram of an example 3GPP-defined architecture for enabling V2X applications, see TS 23.286. [Figure 4] FIG. 4 illustrates an exemplary protocol stack supporting the service layer. [Diagram 5] FIG. 5 is a block diagram of an example IoT Service Layer (SL) deployed on various types of connected network nodes. [Figure 6] FIG. 6 is a block diagram of an example edge application handover client function and edge application handover server function. [Figure 7] FIG. 7 is an example IEAHC-AC function call flow. [Figure 8] FIG. 8 is an example IEAHS-EAS function call flow. [Figure 9] FIG. 9 is an example IEAHS-EAHC function call flow. [Figure 10] FIG. 10 is an example IEAHS-3GPP function call flow. [Figure 11] FIG. 11 is an example IEAHS-MF function call flow. [Figure 12] FIG. 12 is an example EAH policy function call flow. [Figure 13A] FIG. 13A illustrates an example EAH-aware FQDN resolution call flow. [Figure 13B] FIG. 13B illustrates an example EAH-aware FQDN resolution call flow. [Figure 14A] FIG. 14A illustrates an example EAH-aware session disconnection and establishment call flow. [Figure 14B] FIG. 14B illustrates an exemplary EAH-aware session disconnection and establishment call flow. [Figure 15A] FIG. 15A illustrates an example EAH awareness state synchronization / transition call flow. [Figure 15B] FIG. 15B illustrates an example EAH awareness state synchronization / transition call flow. [Figure 16A] FIG. 16A illustrates an example EAH recognition request buffering call flow. [Figure 16B] FIG. 16B illustrates an example EAH recognition request buffering call flow. [Figure 17A] FIG. 17A illustrates an example EAH-aware session QoS continuity call flow. [Figure 17B] FIG. 17B illustrates an example EAH-aware session QoS continuity call flow. [Figure 17C] FIG. 17C illustrates an example EAH-aware session QoS continuity call flow. [Figure 18A] FIG. 18A illustrates the call flows for various exemplary scenarios of the EAH awareness management procedure. [Figure 18B] FIG. 18B illustrates the call flows for various exemplary scenarios of the EAH awareness management procedure. [Figure 18C] FIG. 18C illustrates the call flows for various exemplary scenarios of the EAH awareness management procedure. [Figure 19A] FIG. 19A shows call flows for two example scenarios of EAH-aware edge computing service provider interaction. [Figure 19B] FIG. 19B shows call flows for two example scenarios of EAH-aware edge computing service provider interaction. [Figure 20A] FIG. 20A illustrates a call flow for an example of route-assisted EAH. [Figure 20B] FIG. 20B illustrates an example call flow for route assisted EAH. [Figure 21]FIG. 21 is a block diagram of an example of 3GPP SA6 EDGEAPP. [Figure 22] FIG. 22 is a block diagram of an example 3GPP SA6 V2X. [Diagram 23] FIG. 23 is a block diagram of an example of oneM2M. [Figure 24] FIG. 24 is a block diagram of an example of LWM2M. [Diagram 25] FIG. 25 illustrates an exemplary graphical user interface (GUI) for configuring an EAH policy. [Figure 26A] FIG. 26A illustrates an example communication system in which the methods and apparatus described and claimed herein may be implemented. [Figure 26B] FIG. 26B is a block diagram of an example apparatus or device configured for wireless communication. [Figure 26C] FIG. 26C is a system diagram of an example radio access network (RAN) and core network. [Figure 26D] FIG. 26D is a system diagram of another example RAN and core network. [Figure 26E] FIG. 26E is a system diagram of another example RAN and core network. [Figure 26F] FIG. 26F is a block diagram of an exemplary computing system. [Figure 26G] FIG. 26G is a block diagram of another example communication system. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0040] Appendix Table 1 contains explanations of selected abbreviations used herein. Table 2 contains explanations of selected terms.

[0041] (Edge application deployment) Advantages of deploying Application Servers (AS) at the edge of a 3GPP system, rather than in the cloud, include reduced access latency and increased reliability for Application Clients (ACs) accessing services provided by these ASs. In addition, network operators can also benefit from deploying ASs at the edge of their networks, as this deployment model may enable them to distribute the load and reduce congestion levels in the network (e.g., by enabling localized communication between ACs and ASs).

[0042] For example, Figure 1 illustrates an autonomous vehicle use case. The vehicle hosts a UE, and hosted on the UE is a V2X AC that is used by the vehicle's autonomous driving control system. The V2X AC communicates with V2X services (e.g., platooning service, cooperative driving service, collision avoidance service, etc.) deployed in the 3GPP system. The V2X services are deployed in a distributed manner throughout the system as a combination of V2X ASs deployed on edge nodes (e.g., roadside units, cell towers, etc.) as well as in the cloud.

[0043] As a way to access V2X services by the V2X AC for improved performance (e.g., reduced access latency and increased reliability), it is preferable to access the V2X AS via a V2X AS deployed in an edge network in the system closer to the vehicle, rather than via the cloud. When accessing the V2X AS at the edge, the V2X AC hosted on the UE in the vehicle can utilize more timely and reliable information about other vehicles and road and traffic conditions. As a result, the vehicle can travel at higher speeds and reduce the distance between it and other vehicles. The vehicle can also change lanes more frequently and effectively without sacrificing safety. In contrast, when accessing the V2X AS in the cloud, the availability of timely information is reduced, and the vehicle must revert to a more conservative mode of operation. This typically results in reduced vehicle speeds and increased distance between it and other vehicles, resulting in suboptimal lane changes.

[0044] As a vehicle moves along the road, the handover of the V2X AC between the V2X ASs hosted on different edge nodes closest to the vehicle needs to be coordinated. Similarly, the handover of the V2X AC between the V2X ASs hosted on edge nodes and V2X ASs hosted in the cloud also needs to be coordinated for cases where edge network coverage fades in and out as the vehicle moves. For all of these scenarios, seamless (e.g., low latency and reliable) V2X AC handover between ASs hosted both on edge nodes and in the cloud is important and essential for the successful deployment of this type of V2X use case as well as other types of use cases with similar requirements to V2X.

[0045] (3GPP Architecture for Enabling Edge Applications) Figure 2 shows the 3GPP defined architecture for enabling edge applications. See TR23.758. The framework for enabling edge applications consists of an edge enabler client and application client(s) hosted on the UE, and an edge enabler server and edge application server(s) hosted in the edge data network. An edge data network configuration server is used to configure the edge enabler client and edge enabler server. The edge enabler client and edge enabler server provide edge-centric capabilities to the application client and application server, respectively. The edge enabler server and edge data network configuration server can also interact with the 3GPP network.

[0046] (3GPP Architecture for Enabling V2X Applications) Figure 3 shows the 3GPP defined architecture for enabling V2X applications. See TS 23.286. The V2X Application Enablement (VAE) layer consists of a VAE Client hosted on the UE and a VAE Server hosted in the network. The VAE Client and VAE Server provide VAE-centric capabilities to the V2X Application Client and V2X Application Server. The VAE Client and VAE Server interface to more general (e.g., non-V2X specific) services provided by the Service Enabler Architecture Layer (SEAL) Client and SEAL Server, respectively. The SEAL services consist of location management, group management, configuration management, identity management, key management, and network resource management.

[0047] The VAE server and the SEAL server may also interact with 3GPP network systems (eg, via 3GPP-defined reference points such as V2, MB2, xMB, Rx, and T8).

[0048] (IoT Service Layer (SL)) IoT Service Layer (SL) is a technology that specifically targets providing value-added services for IoT devices, IoT applications, and IoT data. Recently, several industry standard organizations have developed IoT SL to address challenges related to the integration of IoT devices, applications, and data into deployments with Internet / Web, cellular, enterprise, and home networks. These include, for example, oneM2M, ETSI, OCF, and OMA. See, for example, 3GPP Application Layer Support for Vehicle-to-Everything (V2X) Services (3GPP TS23.286 v16.1.0), 3GPP Study on Extensions to Application Layer Support for V2X Services (3GPP TR23.764, v0.2.0), oneM2M TR23.758, oneM2M 3GPP Interworking (oneM2M TS-0026, v4.2.0), and Open Mobile Alliance (OMA) Lightweight Machine-to-Machine (LWM2M) Protocol v1.1.

[0049] IoT SL can provide applications and devices with access to a collection of IoT-oriented capabilities. Some examples include security, billing, data management, device management, discovery, provisioning, and connectivity management. These capabilities are made available to devices and applications through APIs that utilize message formats, resource structures, and resource representations supported by IoT SL.

[0050] From a protocol stack perspective, SLs typically sit above application layer protocols and provide value-added services to the applications they support. Thus, SLs are often classified as "middleware" services. Figure 4 shows an example service layer between the application protocols and the applications.

[0051] From a deployment perspective, IoT SL can be deployed on various types of network nodes, including IoT Servers, IoT Gateways, and IoT Devices, as shown in FIG. 5.

[0052] (Example problem) 3GPP is in the process of defining a 5G edge application architecture. See, for example, TR 23.758. The motivation is to define a standardized framework for deploying various types of edge application servers (EAS) at edge nodes of a 3GPP system with minimal impact on application clients (ACs) hosted on the UE. However, the current 5G edge application architecture does not yet define adequate support for seamless handover of an AC from one EAS to another EAS for use cases with ACs hosted on the UE that require frequent handovers between EASs. Here, seamless handover of an AC from one EAS to another EAS means that the level of service received by the AC is maintained and there is no noticeable service degradation or service interruption. The frequency of handover is determined by the level of service (e.g., latency) required by the AC and the service coverage area of ​​the available EASs.

[0053] 3GPP is also in the process of defining a 5G V2X application architecture, see for example TS 23.286 and TR 23.764. The motivation is to define a standardized type of V2X application server (e.g., platooning) that can be deployed on 3GPP systems. However, the current 5G V2X application architecture does not yet define proper support for seamless handover of V2X ACs between V2X EASs.

[0054] To support use cases such as the V2X example shown in Figure 1, the ability to seamlessly transition (e.g., handover) an AC from one EAS to another with low latency and high reliability is required. Below is a summary of some of the unique challenges associated with achieving seamless handover of an AC between EASs. These challenges have not yet been adequately addressed by 5G edge application architectures or 5G V2X application architectures.

[0055] Since there are many conditions to consider, which may be highly variable and originate from multiple different entities in the system, it may be difficult to determine which EAS in the system is the best one to use at a given time and when the AC needs to transition to using this EAS to ensure that service continuity is maintained. For example, the status and context of the UEs and their ACs, the health and availability of the EASs in close proximity to the UEs, and the health and availability of the network connecting the ACs and the EASs may all be highly variable. Relying on the AC to make optimal decisions about which EAS to use and when a handover to a different EAS needs to be performed is neither practical nor optimal in real deployments.

[0056] EASs are typically deployed on different edge nodes in the system. Each EAS has its own contact point(s), including IP address(es), port(s), and URI path(s) for the services and resources they provide. To access a given EAS, the AC needs to send a request to the contact point of the EAS. A change in contact information occurs when / if a handover to a new EAS occurs. A change in contact information of an EAS can have significant impacts on the AC. It is not uncommon for the contact information of an EAS to be directly configured and / or encoded into the AC. Thus, when a change in contact information of an EAS occurs, the AC usually needs to be aware of this change. The AC then needs to stop communicating with the old EAS, initiate disconnection of various types of sessions (e.g., PDU, QoS, security) between the AC and the old EAS, and establish corresponding sessions with the new EAS. This disconnection and re-establishment of various types of sessions requires that the new sessions are configured in a consistent manner with the previous sessions so that the handover is seamless. This also needs to be done in a timely manner so that there is no interruption of service to the AC.

[0057] Ensuring optimal usage of limited edge node and edge network resources in the system while still ensuring that the service requirements of the AC are met is challenging, and these may directly conflict with each other. Edge nodes are typically deployed with a fixed / limited amount of resources (e.g., CPU, memory, storage). Unlike cloud deployments, which typically support the ability to be dynamically scaled via cloud scaling techniques, additional resources typically cannot be easily added once the edge node's resources are consumed. Similarly, edge nodes are typically deployed in edge networks (e.g., 3GPP LADNs) that have a fixed / limited amount of resources (e.g., bandwidth) compared to the core network. Given these fixed / limited amounts of resources, it may not be possible to deploy EAS on edge nodes in a static or pre-provisioned manner well before the time when the AC requires EAS. Thus, a more dynamic method may be needed to intelligently manage EAS on edge nodes in the system to efficiently utilize resources on the edge nodes and still meet the service requirements of the AC. For example, deploying an EAS on an edge node may require first removing or disabling other EASs to free up edge node resources for the new EAS. This may require coordination between entities in the system to determine which EASs are actively used by the AC and which are not, and thus determine candidates for removal or deactivation. For example, V2X use cases typically include V2X ACs hosted on vehicles that frequently move in and out of the vicinity of different edge nodes of the system. In these use cases, the V2X ACs need to use the V2X EAS for short periods of time while they are in the vicinity of the edge node that hosts the V2X EAS.When a vehicle and its V2X AC leave the vicinity of an edge node hosting a V2X EAS and enter the vicinity of another edge node, methods are needed to ensure that the required type(s) of V2X EAS are available and accessible on the appropriate edge node in the vicinity of the V2X AC. These methods need to ensure that the required instance(s) of the V2X EAS are installed, running, and securely accessible by the V2X AC so that the transition is seamless and without interrupting the service continuity of the V2X AC. Depending on the speed at which the vehicle is moving and the service requirements of its V2X AC (e.g., latency, reliability, etc.), it can be extremely challenging to manage different V2X EAS hosted on different edge nodes in the system so that seamless edge application handover can occur. Ensuring that the required instances of the EAS are available on the appropriate edge node, in the right location, and within the right time window when the AC needs access to them can be an administratively challenging task.

[0058] (Example solution) Figure 6 illustrates an edge application handover client function and an edge application handover server function. Several concepts are presented herein to address shortcomings of existing 5G edge application architectures and 5G V2X application architectures, which are related to insufficient support for seamless handover of UE application clients (ACs) between vertical application servers, such as edge application servers (EASs) and / or VAE application servers, in 3GPP systems. See, for example, TS23.286, TR23.758, and TR23.764. In this specification, EASs may include or imply vertical application servers, such as VAE application servers defined in 3GPP SA6 or other standards, unless explicitly specified.

[0059] In addition, the techniques for supporting AC using handover between EASs described in this specification can be applied to support AC using handover between an EAS and a cloud application server, for example, as in the use case of FIG. 1. (Assisted Edge Application Handover Framework) To enable seamless handover of ACs between EASs in a system (e.g., when a UE moves out of the vicinity of one EAS and into the vicinity of another EAS), an Edge Application Handover (EAH) framework is described that provides assisted handover capabilities for ACs and EASs. The EAH framework can be deployed in a distributed manner consisting of an Edge Application Handover Client (EAHC) and an Edge Application Handover Server (EAHS), as shown in Figure 6.

[0060] The Edge Application Handover Client (EAHC) and the Edge Application Handover Server (EAHS) interface to various other entities in the system, such as one or more Application Clients (AC), Edge Application Servers (EAS), Management Functions (MF), and the 3GPP network, as indicated via the IEAHC-AC, IEAHS-EAS, IEAHS-MF, and IEAHS-3GPP reference points, respectively. The EAHC and EAHS may also interface with each other via the IEAHS-EAHC reference point.

[0061] The EAHC function may be hosted on a UE in the system and interacts with the EAHS function to support seamless handover of AC between EASs. The EAHC may be deployed as a standalone function on the UE or as a sub-function of an existing 3GPP defined function such as an edge enabler client or a V2X application enabler client. The EAHC may also be deployed as a sub-function of an existing non-3GPP defined function such as a oneM2M CSE or an LWM2M client. The EAHC may interface and interact with various other functions in the system when supporting edge application handover. This may include the EAHC sharing information, receiving events, and performing actions involving other functions in the system. Further details of this interaction are provided in subsequent sections of this specification.

[0062] The EAHS function is defined such that it may be deployed outside of the UE in the system. The EAHS may be deployed as a standalone function in the system or as a sub-function of an existing function such as a 3GPP V2X Application Enabler Server, SEAL Server, Edge Enabler Server, Edge Data Network Configuration Server, or SCS / AS. The EAHS may also be deployed as a sub-function of an existing non-3GPP defined function such as a oneM2M CSE or LWM2M Server. The EAHC interacts with the EAHS function to support seamless handover of AC between EASs. The EAHS function may be deployed in an edge data network, a cloud network, or a 3GPP network. The EAHS may also interface and interact with various other functions in the system when supporting edge application handover. This may include the EAHS sharing information, receiving events, and performing operations involving other functions in the system. Further details of this interaction are provided in subsequent sections of this specification.

[0063] A management function (MF) function is defined such that it may be deployed outside of the UE in the system. The MF may be deployed as a standalone function in the system or as a sub-function of an existing function such as a 3GPP edge data network configuration server or SCS / AS. The MF may also be deployed as a sub-function of an existing non-3GPP defined function such as a oneM2M CSE or LWM2M server. The MF interacts with the EAHS function to receive information regarding the capabilities and instantiation of the EAHS. The MF interacts with the EAHC to send EAH policies to the EAHC. The MF function may be deployed in an edge data network, a cloud network, or a 3GPP network. The MF may also interface and interact with various other functions in the system when supporting edge application handover. This may include the MF sharing information, receiving events, and performing operations involving other functions in the system. Further details of this interaction are provided in subsequent sections of this specification.

[0064] (Reference point for assisted edge application handover) (IEAHC-AC reference point) As shown in Figure 7, the EAHC may support a reference point to an AC hosted on the UE (IEAHC-AC). Through the IEAHC-AC, the EAHC may support various types of EAH-centric operations between itself and the AC, such as, but not limited to, those described in Table 3 of the Annex and shown in Figure 7. It should be noted that the EAH operations may be performed in a different sequence than that shown, and the operations may be performed independently of each other.

[0065] Additional details of the exemplary IEAHC-AC operations defined in Table 3 of the Annex are described below.

[0066] The EAHC may support the ability to analyze service requirements and context information (e.g., based on EAH policies) received from the AC, the EAS, and the network interconnecting the AC and the EAS. Based on this analysis, the EAHC may determine if / when an EAH is required. The EAHC may then trigger the AC to initiate the EAH, or alternatively, the EAHC may perform EAH operations on behalf of the AC to assist in the execution of the EAH.

[0067] Because the EAHC may be aware of the service requirements and context information of all ACs hosted on the UE, the EAHC may support the ability to aggregate this information to make optimized EAH decisions across all ACs on the UE. For example, if a single edge node in the network supports all EASs required by different ACs on the UE, the EAHC may determine that an EAH operation that causes the ACs to use the EASs hosted on this single edge node is desirable because the UE may operate in a more efficient manner (e.g., the UE only needs a single PDU session to a single edge node).

[0068] The EAHC may receive prioritization information. The prioritization information may be obtained from a user interface (e.g., a graphical user interface). The prioritization information may indicate to the EAHC the relative importance of the application clients, which the EAHC may use when determining which edge data network and EAS to connect to. For example, the EAHC may decide not to perform a handover action to avoid causing one application client to lose connectivity and interrupting the connection of another application client. Alternatively, the EAHC may decide to perform a handover action to avoid causing one application client to lose connectivity and interrupting the connection of another application client.

[0069] (IEAHS-EAS reference point) As shown in Figure 8, the EAHS can support a reference point (IEAHS-EAS) to communicate with the EASs in the system. Through the IEAHS-EAS, the EAHS can support various types of EAH-centric operations between itself and the EASs (e.g., but not limited to, those in Table 4 of the Annex). It should be noted that the operations shown in Figure 8 may be performed in a different order than that shown, and operations may be performed independently of one another.

[0070] The IEAHS-EAS reference point may support operations such as, but not limited to, those in Table 4 of the Annex.

[0071] (IEAHS-EAHC Reference Point) As shown in Figure 9, the EAHC may support a reference point (IEAHS-EAHC) to communicate with one or more EAHSs in the system. For example, the EAHC may support the ability to interface with the EAHS and share information with the EAHS about the AC so that the EAHS can assist the EAHC by performing EAH operations on behalf of the AC. Note that the operations shown in Figure 9 may be performed in a different order than shown, and some operations may be performed independently of others.

[0072] The IEAHS-EAHC may support operations such as, but not limited to, those in Table 5 of the Annex.

[0073] (IEAHS-3GPP reference point) FIG. 10 illustrates an IEAHS-3GPP function. As shown in FIG. 10, the EAHS can support a reference point (IEAHS-3GPP) to communicate with the 3GPP network and its respective functions (e.g., NEF). Through the IEAHS-3GPP, the EAHS can support exchanging various types of EAH-centric operations with the 3GPP network. For example, the EAHS may send a request to the 3GPP network to trigger a single UE (e.g., a vehicle) or a group of UEs (e.g., a platoon of vehicles) to connect to a particular edge data network (e.g., a 3GPP LADN) that the EAHS determines is in the same vicinity as the UE(s). The 3GPP network can then trigger the UE(s) to connect to the edge data network. It should be noted that the operations illustrated in FIG. 10 may be performed in a different order than illustrated, and operations may be performed independently of one another. The IEAHS-3GPP reference point can support operations such as, but not limited to, those in Table 6 of the Annex.

[0074] (IEAHS-MF and IEAHC-MF reference points) FIG. 11 illustrates the IEAHS-MF functionality. As shown in FIG. 11, the EAHS may support a reference point (IEAHS-MF) to communicate with a management function (MF) in the system. The MF in the system may be responsible for managing the EAS deployed in the system, such as installing / uninstalling, activating / deactivating, and configuring / reconfiguring the EAS hosted on the edge nodes in the edge network of the system. Through the IEAHS-MF, the EAHS may support communication with the MF to assist in managing the EAS and ensure that edge application handovers occur seamlessly. For example, the EAHS may support the ability to interface to the MF to request that the EAS be installed, configured, and / or activated on the edge nodes in the particular edge network to which the UE has connected or is attempting to connect. By interfacing to and assisting in the management of the MF, the EAHS may help ensure that the AC hosted on the UE can transition to a new EAS with little / no interruption. It should be noted that the operations illustrated in FIG. 11 may be performed in a different order than illustrated, and operations may be performed independently of one another. The IEAHS-MF reference point may support operations such as, but not limited to, those in Table 7 of the Annex.

[0075] In addition, although not shown in Figure 11 or Table 7 of the Appendix, the EAHC can support being configured with EAH policies or being instructed to perform EAH-related operations via the MF on the IEAHC-MF reference point. The EAHC can also issue requests to the MF to perform EAH-related operations on the IEAHC-MF.

[0076] (Assisted Edge Application Handover Procedure) In the following subsections, procedures are defined that enable the EAHC and EAHS to assist the AC and EAS in performing edge application handover. These procedures leverage the operations defined by each of the EAHC and EAHS reference points mentioned above.

[0077] (EAH Policy Configuration) FIG. 12 illustrates the EAH policy function. As shown in steps 1a and 1b of FIG. 12, both the EAHS and EAHC in the system can be configured with EAH policies. The EAH policies can include criteria used to determine which EAH actions the EAHS or EAHC should perform and under what conditions they should perform these actions. These policies may be configured by various entities in the system, such as but not limited to users, core network functions, application clients, edge enabler clients, edge application handover clients, V2X application enabler servers, SEAL servers, edge enabler servers, edge data network configuration servers, and SCS / AS. These entities can issue requests to the EAHS or EAHC to configure its EAH policies. Alternatively, the EAHS or EAHC can retrieve EAH policies from these entities or subscribe to these entities to receive notifications if / when changes to the EAH policies are needed (not shown in FIG. 12).

[0078] The EAH policy may include EAH rules, such as, but not limited to, those defined in Table 8. These rules may be stored and used by the EAHS or EAHC to control which EAH actions are performed and under what conditions the EAH actions are performed (steps 2a and 2b in FIG. 12). The information in Table 8 of the Appendix may be provided for each EAS type or for each EAS type.

[0079] The EAH policy rules may have dependencies on various types of EAH-related context information available in the system (e.g., but not limited to, types defined in Table 9 of the Annex). This context information may originate from various entities in the 3GPP system, such as, but not limited to, Core Network Functions, Application Clients, Edge Enabler Clients, Edge Application Handover Clients, V2X Application Enabler Servers, SEAL Servers, Edge Enabler Servers, Edge Data Network Configuration Servers, and SCSs / ASs. As shown in steps 3a and 3b of FIG. 12, these entities may issue requests to the EAHS or EAHC to share EAH-related context information. Alternatively, the EAHS or EAHC may retrieve EAH-related context from these entities or subscribe to these entities to receive notifications if / when the context information of interest becomes available (not shown in FIG. 12). The EAH-related context information may be made available to the EAHS and EAHC in the system so that the EAHS and EAHC can evaluate it together with specified rules defined in the EAH policy to determine which EAH actions to perform and under what conditions (steps 4a and 4b in FIG. 12).

[0080] EAH-Aware FQDN Resolution To minimize the complexity and overhead of the EAH for the AC, the EAHC and EAHS may support a feature that allows the AC to continue to use the same EAS FQDN after the EAH that it used before the EAH. This feature includes the EAHC and EAHS managing the lower-level contact information of the EAS (e.g., IP addresses, ports, URI paths, identifiers, security credentials, and / or service description information) and performing EAS FQDN resolution operations on behalf of the AC. In doing so, the EAHC and EAHS can relieve the AC of the burden of performing these operations, or even be aware that these operations are being performed on their behalf.

[0081] This functionality includes the EAHC supporting an extended DNS client function that also knows when an edge application handover is taking place, so that the EAHC can successfully resolve the EAS FQDN to the correct EAS contact even when the UE connects to / from a different edge network and a runtime edge application handover is occurring. The EAHC may also support an API that allows the AC to issue requests to the EAHC to resolve the EAS FQDN on their behalf and receive EAS contact information if necessary.

[0082] 13A and 13B show an example of EAH-aware FQDN resolution function. To enable the EAHC to perform this function, the EAHC may support the ability to be configured with contact information for DNS server(s) (step 1 in FIG. 13A). The DNS server(s) host the DNS records of the EAS (e.g., EAS#1) currently available to the AC. If the UE connects to a different network domain (either core or edge network domain), the UE may be configured with this contact information for DNS server(s). The entity that configures the EAHC of the UE with this DNS server contact information may be the EAHS as shown in step 1, or may be another entity in the system, such as, but not limited to, an edge data network configuration server, a SEAL server, an edge enabler server, or an SCS / AS. In step 1, multiple DNS server contacts may be provided to the UE. Each contact may be associated with an S-NSSAI and a DNN. An EAS may be associated with a particular network slice. For example, the UE accesses a given EAS using a particular 3GPP PDU session associated with a particular network slice. Thus, a given DNS server may be associated with a particular edge data network and / or a particular 3GPP network slice. Note that the SMF may provide a DNS server window to the UE during PDU session establishment. The EAHC may give higher priority to the DNS server window provisioned by the edge data network configuration server, the SEAL server, the edge enabler server, or the SCS / AS, and may only use the DNS server window provided by the SMF if the window provisioned by the edge data network configuration server, the SEAL server, the edge enabler server, or the SCS / AS cannot resolve the FQDN.

[0083] Once the EAHC is configured with contact information for one or more DNS servers, it can process requests from the AC to resolve the FQDN of the EAS (step 2). When the EAHC receives a request targeting a given EAS FQDN for the first time, it can perform a DNS lookup against the configured DNS servers (step 3) to resolve the FQDN to the appropriate EAS contact information (step 4). The EAHC can return the EAS contact information to the AC (step 5). The EAHC can also cache the contact information (step 6) so that subsequent requests from the same AC to the same EAS do not need to repeat another DNS lookup (steps 8 and 9). The AC can then use the EAS contact information to access the EAS (steps 7 and 10).

[0084] If / when an EAH for one or more ACs is triggered by an AC, EAHC, or EAHS (step 11), the EAHC may detect the occurrence of the EAH, determine the affected ACs and EASs (step 12a), and mark any cached DNS lookup results for these affected ACs and EASs as invalid / stale so that they are not used (step 12b). In addition, the EAHC may also receive updated DNS server window(s) if the UE is connected to a different edge network, which has different DNS server(s) that bind the EAS FQDN to different windows (step 13a in FIG. 13B). Alternatively, if a handover to a different EAS in the same edge network occurs, the EAHS may instead update the DNS server records on the DNS server to update the EAS FQDN window information to reflect the new EAS to be accessed instead of the old EAS (step 13b). The updated DNS information may be sent from the EAHS to the EAHC in an EAH notification request. After updating the DNS server, the EAHS can notify the EAHC(s) so that the EAHC(s) know that it has refreshed any cached DNS results for the updated DNS server(s) (step 13c). Following the EAH, when the EAHC receives the next request from the AC to resolve the EAS FQDN (step 14), the EAHC can perform a new DNS lookup and obtain the latest EAS contact information (steps 15 and 16). The EAHC can return this contact information to the AC and cache it until if / when another EAH is triggered (steps 17 and 18). The AC can then use the EAS contact information to access the new EAS (step 19).

[0085] Alternatively, not shown in Figures 13A and 13B, rather than the AC issuing an EAS FQDN resolution request to the EAHC and having the EAHC return the EAS contact information to the AC, the EAHC can instead act as a message proxy between the AC and the EAS. When acting as a proxy, the AC can forward its request targeted to the EAS to the EAHC to proxy on its behalf. In that request, the AC can use the FQDN of the target EAS rather than the contact information resolved for the EAS. Upon receiving the request from the AC, the EAHC can then perform the EAS FQDN resolution in an EAH-aware manner and replace the FQDN with the appropriate EAS contact information before forwarding the request to the EAS. By doing so, the AC does not need to be aware of the EAS contact information. The EAHC can hide the EAS contact information from the AC and perform the EAS FQDN resolution on behalf of the AC.

[0086] (EAH-aware security session disconnection and establishment) Depending on the requirements of the use case, secure communication between the AC and the EAS may be required. If secure communication is required, the AC and EAS must be configured with appropriate credentials necessary to enable the AC and EAS to authenticate and establish a secure and trusted communication session with each other (e.g., performing a two-way authentication handshake using a security protocol such as TLS). To enable seamless handover of ACs between different EASs in the system, the EAHC and EAHS can provide the AC and EAS with assistance in managing credentials to assist in setting up and tearing down secure communication sessions between the AC and the EAS. In doing so, the EAHC and EAHS can alleviate the burden on the AC and EAS to perform these operations themselves.

[0087] 14A and 14B show an example of a function including the EAHC and EAHS assisting in the setup and teardown of secure communication sessions between the AC and the EAS when an edge application handover occurs. The EAHC and EAHS can leverage existing trust relationships established between different pairwise entities in the system, such as the AC and EAHC, the EAHC and EAHS, the EAS and EAHS, or security functions (e.g., AAA servers, certificate authorities, etc.) in the EAHS and the network. These pairwise trust relationships can be established using existing well-known security methods (e.g., TLS sessions).

[0088] Once these pairwise trust relationships are established, the EAHC and EAHS can layer additional security functionality on top of these pairwise trust relationships. This additional functionality can help the AC establish run-time trust relationships with the EASs in the system and can help the EASs establish run-time trust relationships with other EASs (e.g., allowing the EASs to securely synchronize or migrate edge application state during edge application handover). This functionality can be particularly useful when frequent edge application handovers occur, since the overhead of managing security credentials between the AC and the EASs can be high.

[0089] Leveraging their knowledge of when an edge application handover occurs and their trust relationships with the respective ACs and EASs (step 0 in FIG. 14A), the EAHC and EAHS can perform credential management operations to securely configure the ACs and EASs with each other's public credentials (e.g., PSKs, certificates, etc.) if / when an EAH occurs. The ACs can securely (e.g., in an encrypted manner) pass their credentials to the EAHC via a secure communication session that exists between the EAHC and the AC (step 1). Similarly, the EASs can securely pass their credentials to the EAHS via a secure communication session that exists between the EAHS and the EAS (step 2). When a handover of the AC to a new EAS occurs (step 3), the EAHC can securely pass the AC's credentials to the EAHS via a secure communication session that exists between the EAHC and the EAHS (step 4). The EAHS can then securely pass the AC's credentials to the new EAS via a secure communication session that exists between the EAHS and the EAS (step 5). Similarly, the EAHS can securely pass the EAS's credentials to the EAHC via the secure communication session that exists between the EAHS and the EAHC (step 6). The EAHC can then securely pass the EAS's credentials to the AC via the secure communication session that exists between the EAHC and the AC (step 7). During this process, the EAHS can also communicate with a security function in the network if new / updated credentials are needed (not shown in Figures 14A and 14B). Once the AC and EAS are configured with each other's credentials, they can perform a two-way authentication handshake to establish a trust relationship and a secure communication session with each other that can be used to securely exchange application layer messages with each other (step 12a).

[0090] Similarly, the EAHS can also assist the EASs involved in the handoff with each other to establish trust relationships with each other so that they can securely perform handoff operations such as secure synchronization / migration of application state. When a handover of the AC to a new EAS occurs, the EAHS can securely pass the credentials of the old EAS to the new EAS and vice versa (step 8 in FIG. 14A and step 9 in FIG. 14B). This can be done via a secure communication session that exists between the EAHS and each EAS. During this process, the EAHS can also communicate with security functions in the network if new / updated credentials are required (not shown in FIG. 14A and FIG. 14B). Once the EASs are configured with each other's credentials, the EASs can perform a two-way authentication handshake to establish trust relationships and secure communication sessions with each other (step 10), which can then be used to securely synchronize / migrate application layer states with each other (step 11).

[0091] In addition to assisting in credential management, the EAHC and / or EAHS may also assist in establishing and / or tearing down a secure communication session between the AC and the EAS. Since the EAHC is hosted on the same UE with the same IP address as the AC, the EAHC is well positioned to act as a security proxy on behalf of the AC. The EAHC may establish (step 12b) and / or tear down (step 13) a secure communication session with the EAS on behalf of the AC. This relieves the AC of the burden of doing this itself, thus freeing the AC to perform other application-centric operations more efficiently. Furthermore, since the EAHC may be involved in the occurrence of EAH operations earlier than the AC, the EAHC may be able to perform these operations in a more efficient manner. Thus, the EAHC may be able to initiate the establishment or teardown of a secure communication session earlier than the AC. This may help reduce EAH latency and improve overall system performance. For example, when the EAHC and EAHS are performing EAH operations, such as transitioning / synchronizing state between the ESAs during the EAH, the EAHC and EAHS can recognize that the secure communication session to the ESA is no longer needed and can disconnect the secure communication between the AC and the EAS in an efficient and timely manner.

[0092] (EAH aware application state synchronization / transition) Depending on the requirements of the use case, it may require synchronization or migration of application state from the EAS that the AC is currently using to the new EAS to which the AC is being handed off.

[0093] To enable seamless handover of ACs between different EASs in the system, the EAHC and EAHS can assist the ACs and EASs in managing efficient synchronization or migration of application states between EASs, thereby reducing the burden on the ACs to perform these operations.

[0094] 15A and 15B show an example of a function including the EAHC and / or EAHS triggering application state synchronization or migration operations during EAH (step 1 in FIG. 15A). These triggers can be sent to the AC as desired to cause the AC to initiate and / or execute synchronization or migration operations (step 2a). Alternatively, triggers can be sent from the EAHS or EAHC to the old EAS (EAS#1) (step 2b) and / or new EAS (EAS#2) (step 2c) involved in the EAH, or both. The EAHC and / or EAHS can trigger application state synchronization or migration operations when they detect that an EAH is required and other required EAH operations (e.g., discovery of the selection of a new EAS, provisioning of EAS credentials to the EAS involved in the handoff) are completed. After triggering the application state synchronization or migration operations, the EAHC and / or EAHC can monitor whether the operations are completed successfully (step 4 in FIG. 15B). The EAHC and / or EAHS may receive a status update from the EAS and / or AC regarding whether the application state synchronization or migration operation completed successfully. If successful, the EAHC and / or EAHS may use this as a qualification that the EAH completed successfully and send a notification to the AC that the new EAS is ready for access (step 6a). If unsuccessful, the EAHC and / or EAHS may use this as a qualification that the EAH failed and may then identify a new EAS and perform additional operations such as triggering a new EAH (step 6b). Leveraging knowledge of when an edge application handover is initiated, the EAHC and EAHS can be better positioned to perform this triggering in a more optimal manner than the AC, thereby relieving the AC of the burden of having to initiate this action itself.

[0095] (EAH recognition request buffering) To enable seamless handover of an AC between different EASs in the system, the EAHC can store and forward origination requests from the AC to the EAS(s) until the EAH operations are completed and the AC is able to communicate with its new EAS(s).

[0096] 16A and 16B show an example of the function in which EAH is triggered in the system (step 1 in FIG. 16A). While the EAH is being processed, the AC continues to issue requests to access the EAS (step 2). While EAH operations are being performed by the EAHC and / or the EAHS, the EAHC buffers these requests. For example, EAH operations such as EAH-aware FQDN resolution, EAH-aware session disconnection and establishment, and EAH state synchronization / transition (step 4). Once all EAS handover operations are successfully completed (step 5 in FIG. 16B), the EAHC can forward the buffered request to the "new" EAS (EAS#2) involved in the handover (step 6), and the response can be returned to the AC (step 7). When forwarding the buffered request, the EAHC can verify that the target EAS FQDN specified in the buffered request has been correctly resolved to the refreshed contact information of the "new" EAS to which the AC was handed off.

[0097] (EAH-Aware Session QoS Continuity) To enable seamless handover of ACs between different EASs in the system, the EAHC or EAHS may support the capability of supporting an EAH-aware session QoS continuity function. This function requires that the EAHC or EAHS ensures that the configuration of 3GPP network QoS flow(s) established between AC(s) hosted on the UE and corresponding EAS(s) hosted on the edge node(s) is kept consistent when an EAH handover occurs. When an EAH handover occurs, the EAHC or EAHS may assist in the establishment of new QoS flow(s) between the AC(s) and the new EAS(s) to which they are handed off. The EAHC or EAHS may track the configuration of session QoS flows existing between the AC(s) and the EAS(s) when assisting in their establishment. If / when the EAH is triggered, the EAHC or EAHS may configure the session QoS flows between the AC(s) and the new EAS(s) such that they are consistent with the existing flows established between the AC(s) and the current EAS(s) they are accessing.

[0098] FIG. 17A-FIG. 17C show an example in which an AC may share its QoS requirements with an EAHC (step 1 in FIG. 17A). A first EAH is triggered in the system (step 2). While the EAH is being processed, the EAHS initiates a request to the 3GPP network to establish a session QoS flow between the AC and the EAS#1 that satisfies the QoS session requirements of the AC (step 3a). The 3GPP network receives and processes the request, and configures the QoS flow between the AC and the EAS#1 (step 3b). The 3GPP network returns a response including a flow identifier, e.g., 5 QI (5G QoS Identifier), used to identify the session QoS flow (step 3c). The EAHS maintains the session QoS flow information including the flow identifier and the applicable AC and EAS (step 4). The AC initiates communication with the EAS#1 to access its offered service (step 5). During this communication, the 3GPP network ensures that the QoS requirements of the AC are met.

[0099] At some subsequent time, another EAH is triggered and EAS#2 is identified as the target EAS for the handover (step 6). The EAHS performs an EAH-aware session QoS continuity function. One method that the EAHS may use to perform EAH-aware session QoS continuity is by first sending a new session QoS establishment request to the 3GPP network to establish a session QoS flow between the AC and the EAS#2 with the same QoS requirements as those defined by the AC and maintained by the EAHS (step 7a in FIG. 17B). The 3GPP network receives and processes the request and configures the QoS flow between the AC and the EAS#2 (step 7b). The 3GPP network returns a response including a flow identifier used to identify the session QoS flow (step 7c). The EAHS then issues another request to terminate the session QoS flow between the AC and the EAS#1 (step 8a). The 3GPP network receives and processes the request and disconnects the QoS flow between the AC and the EAS#1 (step 8b). The 3GPP network returns a response (step 8c). The EAHS maintains the session QoS flow information (step 4), including the flow identifier and the applicable AC and EAS. The AC starts to communicate with the EAS#1 to access its offered services (step 5). During this communication, the 3GPP network ensures that the QoS requirements of the AC are met.

[0100] Another method that the EAHS may use to perform EAH-aware session QoS continuity is to issue a session QoS handover request to the 3GPP network (step 9a in FIG. 17C). In this request, the EAHS may include a QoS flow identifier for the existing session QoS flow between the AC and EAS#1 and an identifier of the EAS (EAS#2) that is the target of the handover. The 3GPP network receives and processes the request, and establishes a session QoS flow between the AC and EAS#2 that has the same QoS requirements as the flow between the AC and EAS#1 (step 9b). In this way, the QoS flow identifier for the existing session is used to identify the desired QoS characteristics for the new session with the target EAS. After establishing this session QoS flow, the 3GPP network disconnects the session QoS flow between the AC and EAS#1 (step 9c). The 3GPP network then returns a response to the EAHS that includes a flow identifier used to identify the new session QoS flow (step 9d). The EAHS maintains the session QoS flow information including the flow identifier and the applicable AC and EAS (step 10). The AC starts communicating with EAS#2 to access its offered services (step 11). During this communication, the 3GPP network ensures that the QoS requirements of the AC are met. (EAH Awareness Management Procedure) To enable seamless handover of ACs between different EASs in the system, the EAHC or EAHS can interface with various management functions in the system and assist them in performing different types of management operations. Conversely, the management functions can also assist the EAHC or EAHS in performing edge application handovers.

[0101] Figures 18A and 18B show an example where an EAHC or EAHS may provide EAH-related context information to a management function in the system (step 1 in Figure 18A), such as but not limited to the types of context defined in Table 9 of the Annex. The management function can take this information into account in its decision-making about whether / when to perform a particular management action (steps 2 and 3). For example, the EAHC or EAHS may provide EAH-related context regarding where an EAS may be deployed (e.g., on a set of edge nodes such that load balancing or performance scaling may be performed by managing the EAS status on these nodes), when an EAH is needed (e.g., immediately or at some specified time or schedule in the future), where an EAH is needed (e.g., within a specified geographic location or region, within a specified area of ​​the network such as within a specified edge network, or along a specified route), who an EAH is needed by (e.g., which UE, AC, EAS, edge node), and why an EAH is needed (e.g., whether a UE has changed location, whether an AC is not satisfied with the service level from the current EAS, whether the 3GPP network has signaled a problem such as network congestion).

[0102] The EAHC or EAHS may also determine that a particular management action is required (step 4) and send a trigger request to a management function (step 5) to cause a particular type of management action to be performed on its behalf, such as, but not limited to, deploying an EAS in a specified edge network or on a specified edge node, installing and activating / deactivating an EAS in a specified edge network or on a specified edge node (step 6).

[0103] Some types of management actions for which EAHC or EAHS assistance may be useful may include, but are not limited to: Optimal selection of which edge networks and edge nodes in the system are the best candidates for a particular EAS deployment Optimal selection of which edge networks and edge nodes in the system are the best candidates for the installation of a new instance of EAS or the activation of an already installed EAS Optimal selection of which edge networks, edge nodes, and existing EASs in the system are the best candidates for access by a particular AC Detecting whether there are service availability problems in the system that either completely prevent an AC from accessing a particular EAS or that degrade the AC's service level when accessing the EAS. Optimal selection of which existing EASs in the system are the best candidates for disabling and / or uninstallation from the edge network and edge nodes when there is a lack of available resources in the edge network or edge nodes. Determining the best time to install / activate / deactivate / modify EAS Determining the optimal schedule for activating and deactivating the EAS Reserve resources on edge nodes to host EAS Adjusting EAS status, such as EAS edge resource usage Configuring access control policies in the system where the AC determines which edge networks, edge nodes, edge servers, and edge application servers are allowed to access

[0104] Conversely, the management function in the system can assist the EAHC or EAHS by sharing management-related information with the EAHC or EAHS (step 7 in FIG. 18B). Some types of management-related information can be the status and / or availability of edge networks, edge nodes, or EASs in the system. The EAHC or EAHS can take this information into account in deciding whether to trigger an EAH (step 8). The EAHC or EAHS can then decide to initiate a handover of the AC to a new EAS to relieve the overload situation on the EAS that the AC currently accesses (step 9).

[0105] The management function can also determine that an EAH is necessary (step 10) and send a request to the EAHC or EAHS to trigger the EAHC or EAHS to perform an EAH (step 11) to alleviate the problem detected by the management function. The EAHC or EAHS can then initiate a handover to a new EAS for the AC to alleviate the overload condition on the EAS currently accessed by the AC (step 12).

[0106] 19A and 19B show an exemplary EAH-aware edge computing service provider interaction. An edge computing service provider (ECSP) can also interact with the management function to trigger management actions such as deploying a new edge application to the edge network, installing a new EAS instance, or adjusting the current status of a deployed or installed EAS. The EAHS can assist the management function in interacting with the ECSP by sharing EAH-related context information to optimize the deployment and status of the EAS.

[0107] The management function can receive information from the EAHS regarding existing EAS deployment status or instance status, based on which the management function can identify the need to deploy or install a new / additional EAS (EAS of a particular type is missing in an edge network, an existing EAS of a particular type is overloaded and a new instance is needed, etc.). The management function can determine the optimal action to take, including but not limited to the type of desired EAS, the edge nodes and edge networks that may host the desired EAS, when a new EAS is needed, if / when an EAH is needed, etc. Such information can then be sent to the ECSP as a recommendation. After receiving the recommendation, the ECSP can determine whether the proposed action is agreed upon. If agreed upon, the ECSP can send a request to the management function to trigger the recommended action, for example, to deploy the desired EAS to more edge nodes or install more instances of the desired EAS.

[0108] The management function can receive queries from the ECSP regarding the deployment status and instance status of the EAS and collect the required information from the EAHS. After receiving the response, the ECSP can trigger management actions such as deploying a new EAS, adjusting the status of the deployed / installed EAS, or running the EAHS.

[0109] (Route Assisted EAH) To further optimize edge application handover for use cases involving mobile UEs, route information of the UE can be leveraged to assist in managing the edge application handover. Route-assisted edge application handover involves leveraging route information to coordinate and manage to which target EAS the AC is next handed off. The route information may consist of a series of waypoints. The waypoints may be defined in terms of geographic coordinates or expressed in other terms, such as, but not limited to, identifiers of edge networks, edge nodes, and / or edge servers along the route.

[0110] 20A and 20B show an example of a route-assisted EAH function. Route information can come from multiple types of entities in the system, including but not limited to a user or an AC that explicitly defines a predefined route in advance (step 1). For example, in planning a journey, a start and end point and intermediate points are defined. If a predefined route is not defined, the route can be predicted or inferred based on real-time and / or historical context information available from various entities in the system (step 2). For example, using context information such as the road the UE is currently traveling on, combined with historical context such as the UE's commuting patterns, a predicted route can be calculated by the EAHS and used to assist in the selection of the next EAS(s) to which the AC(s) hosted on the UE will be handed off. Predictive analytics techniques can be used to assist in the calculation of the predicted route. Both the ability to allow a predefined route to be specified and the ability to leverage context information and predictive analytics to predict the UE's route are functions that can be supported by the EAHC or EAHS.

[0111] Once the route information is available, the desired EAS can be proactively deployed at edge nodes along the route. The EAS along the UE route may be pre-installed and pre-configured based on the UE's route information. Alternatively, the deployed EAS need not be immediately installed or activated or remain active all the time. The timing of installation / activation / deactivation can be determined by the EAHC or EAHS according to the UE's location (Scenario #1 or #2 in FIG. 18). The EAHC or EAHS can utilize the route information to monitor the UE's current location relative to different waypoints defined by the route and track the movement of the UE(s) along the route as well as any unexpected deviations. To monitor and track the UE's location along the route (step 7), the EAHC or EAHS can rely on updates of the UE's current location. These updates can come from the UE itself (step 3), from a location function in the 3GPP network (step 4), or from other entities in the system (e.g., SCS / AS).

[0112] The EAHC or EAHS can share the predicted route information for the UE with the 3GPP network so that the network can configure and optimize its network resources to ensure that the UE's requirements (e.g., QoS) are met while the UE moves along the route (step 5). The EAHC or EAHS can also request that the 3GPP network track the UE's movement along the route on its behalf and send notifications regarding the UE's movement along the route (step 6). For example, notifications include, but are not limited to, when the UE arrives at a specified waypoint along the route or when the UE deviates from the specified route.

[0113] Leveraging location information regarding the UE's movement along the route, the EAHC or EAHS can compare the UE's movement with available edge networks, edge nodes, and / or EASs deployed in close proximity to the UE along the same route. Based on this comparison and any configured EAH policies, the EAHC or EAHS can determine if / when to trigger an EAH and which EAS(es) to select as the target(s) of the EAH (step 8). If the EAHC or EAHS determines that an EAH is required, it can trigger and assist other entities in the system by performing EAH operations (step 9).

[0114] Figures 20A and 20B show route-assisted EAH. In addition to supporting route-assisted edge application handover for a single UE, the EAHC or EAHC can support route-assisted EAH functionality for a group of UEs moving together (e.g., V2X platooning). Note that this functionality is not captured in Figures 20A and 20B.

[0115] In addition to the operations captured in Figures 20A and 20B, the EAHS can also send one or more requests to register an AC and / or reserve an existing EAS for use by an AC at an edge or cloud node at a particular location or along a specified route so that the EAS is not overloaded. These requests can be sent in advance (e.g., when the itinerary is configured and the route is determined) and before the AC is in the vicinity of the cloud / edge node. Alternatively, these requests can be sent on the fly when the EAHS detects that the location of the AC has changed and is within a particular vicinity of a given edge or cloud node. The request can include information such as the security credentials and identifier of the AC, predicted QoS / QoE service requirements such as a required service availability schedule (e.g., time window of planned use of an application or service), user profile or preference information (e.g., application settings), and / or service usage requirements (e.g., rate of request, application request rate, data limit, etc.). These requests may be sent directly to the edge node or cloud hosting the service, or may be sent to another function in the network that facilitates registration and / or reservation of services hosted on the edge node or cloud.

[0116] (An example service layer approach) The assisted edge application handover ideas described herein can be applied to a variety of multiple service layer technologies, including but not limited to 3GPP SA6, oneM2M, and OMA LWM2M.

[0117] (Example of 3GPP SA6 EDGEAPP) Figure 21 shows an example of how the concepts described herein can be applied in a 3GPP SA6 defined architecture to enable edge applications. See, e.g., TS 23.286.

[0118] The defined EAHC function can be implemented as a new function within the existing Edge Enabler Client function. Alternatively, the EAHC may be implemented as a new standalone function in the UE. In this case, new reference points (e.g., Edge-13 and Edge-14) can be defined to support interworking with the new standalone EAHC.

[0119] The defined EAHS function can be implemented as a new function of the edge enabler server or edge data network configuration server function. Alternatively, the EAHS may be implemented as a new standalone function in the system. This new standalone function may be deployed in the cloud or at the edge of the network. New reference points (e.g., Edge-8, Edge-9, Edge-10, Edge-11, and Edge-12) may also be defined to support interactions between the new standalone EAHS and the EAS, edge enabler server, edge data network configuration server, UE, and / or 3GPP core network.

[0120] Table 10 in the Appendix provides an example of how the SA6 EDGEAPP architecture reference points can be aligned and extended with the functionality defined for each of the respective reference points described herein.

[0121] 3GPP SA6 V2X Example Figure 22 shows an example of how the concepts described herein can be applied in a 3GPP SA6 V2X architecture. See, for example, TS 23.286 and 3GPP TR 23.764.

[0122] The defined EAHC functionality may be implemented as a new functionality added to the existing VAE client and / or SEAL client functionality hosted on the UE. Alternatively, the EAHC may be implemented as a new standalone functionality in the UE (not shown in FIG. 22). In this case, new reference points may be defined to support interaction with the new standalone EAHC.

[0123] The defined EAHS function can be realized as a new function added to an existing V2X Application Enabler (VAE) server. Alternatively, the EAHS may be realized as a new standalone function in the system (not shown in FIG. 22). This new standalone function may be deployed in the cloud or at the edge of the network. In this case, new reference points may be defined to support interaction with the new standalone EAHS.

[0124] Table 11 of the Annex provides an example of how the reference points of the SA6 V2X architecture may be aligned and extended with the functions defined for each of the respective reference points described herein.

[0125] (Example of oneM2M) Figure 23 shows an example of how the functionality described herein can be applied in a oneM2M architecture, see for example TS 23.286 and 3GPP TR 23.764.

[0126] The defined EAHC functionality may be implemented as new functionality added to the existing oneM2M ASN / MN-CSE hosted on the UE. The defined EAHS functionality may be implemented as new functionality added to the existing oneM2M IN-CSE.

[0127] Table 12 in the Appendix provides an example of how the SA6 EDGEAPP architecture reference points can be aligned and extended with the functionality defined for each of the respective reference points described herein.

[0128] (Example of LWM2M) Figure 24 shows an example of how the concepts described herein can be applied in an OMA LWM2M architecture. The defined functionality of the EAHC can be implemented as a new function added to the existing LWM2M client hosted on the UE. The defined functionality of the EAHS can be implemented as a new function added to the existing LWM2M server function.

[0129] (Graphical User Interface (GUI)) 25 illustrates an exemplary GUI that a person operating a cellular device may use to request configuration of EAH policy settings associated with the cellular device. These policies may be used by the EAHC and / or EAHS server functions described herein.

[0130] (Example environment) The Third Generation Partnership Project (3GPP) develops technical standards for cellular telecommunications network technologies, including radio access, core transport networks, and service capabilities, including work on codecs, security, and quality of service. Recent radio access technology (RAT) standards include WCDMA (commonly referred to as 3G), LTE (commonly referred to as 4G), and LTE-Advanced standards. 3GPP has begun working on the standardization of the next generation of cellular technologies, referred to as New Radio (NR), also referred to as "5G". The development of the 3GPP NR standard is expected to include the definition of next generation radio access technologies (new RATs), including the provision of new flexible radio access below 6 GHz and the provision of new ultra-mobile broadband radio access above 6 GHz. Flexible radio access is expected to consist of new non-backward compatible radio access in the new spectrum below 6 GHz, and is expected to address a broad set of 3GPP NR use cases with different requirements, including different operating modes that may be multiplexed together in the same spectrum. Ultra Mobile Broadband is expected to include centimeter and millimeter wave spectrum, which provides opportunities for ultra mobile broadband access for indoor applications and hotspots, for example. In particular, ultra mobile broadband is expected to share a common design framework with sub-6 GHz flexible wireless access, with centimeter and millimeter wave specific design optimizations.

[0131] 3GPP has identified a variety of use cases that NR is expected to support, resulting in a wide variety of user experience requirements in terms of data rates, latency, and mobility, including the following general categories: enhanced mobile broadband (e.g., broadband access in dense areas, indoor ultra-high broadband access, broadband access in crowds, 50+Mbps everywhere, ultra-low cost broadband access, mobile broadband in vehicles), critical communications, large-scale machine-type communications, network operations (e.g., network slicing, routing, migration and interworking, energy conservation), and enhanced vehicle-to-vehicle / vehicle-to-infrastructure (eV2X) communications, which may include any of vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), vehicle-to-network (V2N), vehicle-to-pedestrian (V2P), and vehicle communications with other entities. Specific services and applications in these categories include, for example, surveillance and sensor networks, device remote control, two-way remote control, personal cloud computing, video streaming, wireless cloud-based office, first responder connectivity, vehicle emergency notification systems, disaster alerts, real-time gaming, multi-party video calling, autonomous driving, augmented reality, haptic internet, and virtual reality, to name a few. All of these use cases and more are contemplated herein.

[0132] 26A illustrates one embodiment of an example communication system 100 in which the methods and apparatus described and claimed herein may be embodied. As illustrated, the example communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, 102e, 102f, and / or 102g (which may be generally or collectively referred to as WTRUs 102), radio access networks (RANs) 103 / 104 / 105 / 103b / 104b / 105b, core networks 106 / 107 / 109, public switched telephone network (PSTN) 108, the Internet 110, other networks 112, and a V2X server (or ProSe function and server) 113, although it will be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d, 102e, 102f, 102g may be any type of apparatus or device configured to operate and / or communicate in a wireless environment. Although each WTRU 102a, 102b, 102c, 102d, 102e, 102f, 102g is illustrated in Figures 26A-26E as a handheld wireless communications device, it should be 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. The apparatus or devices may include, 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, a consumer electronic device, a wearable device such as a smart watch or smart clothing, a medical or e-health device, a robot, an industrial device, a drone, a vehicle such as a car, a truck, a train, or an airplane, and the like.

[0133] The communication system 100 may also include a base station 114a and a base station 114b. The base station 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 other networks 112. The base station 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, the TRPs (transmission and reception points) 119a, 119b, and / or the RSUs (road side units) 120a and 120b to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, other networks 112, and / or the V2X server (or ProSe function and server) 113. The RRHs 118a, 118b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102c to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, and / or other networks 112. The TRPs 119a, 119b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102d to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, and / or other networks 112. The RSUs 120a and 120b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102e or 102f to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, other networks 112, and / or a V2X server (or ProSe function and server) 113.By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node B, an eNodeB, a Home Node B, a Home eNodeB, a site controller, an access point (AP), a wireless router, etc. Although the base stations 114a, 114b are each shown as a single element, it will be understood that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

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

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

[0136] The base station 114b can communicate with one or more of the RRHs 118a, 118b, the TRPs 119a, 119b, and / or the RSUs 120a and 120b via a wired or air interface 115b / 116b / 117b, which can be any suitable wired communication link (e.g., cable, optical fiber, etc.) or wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, centimeter wave, millimeter wave, etc.). The air interface 115b / 116b / 117b can be established using any suitable radio access technology (RAT).

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

[0138] The WTRUs 102a, 102b, 102c, 102d, 102e, 102f, and / or 102g may communicate with one another over an air interface 115d / 116d / 117d (not shown), which may be any suitable wireless communications link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, centimeter wave, millimeter wave, etc.). The air interface 115d / 116d / 117d may be established using any suitable radio access technology (RAT).

[0139] More specifically, as mentioned above, the communication 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, etc. For example, the base station 114a and the WTRUs 102a, 102b, 102c in the RAN 103 / 104 / 105, or the RRHs 118a, 118b, TRPs 119a, 119b and RSUs 120a, 120b and the WTRUs 102c, 102d, 102e, 102f in the RAN 103b / 104b / 105b, may implement a radio technology, such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), thereby establishing the air interface 115 / 116 / 117 or 115c / 116c / 117c, respectively, using Wideband CDMA (WCDMA). WCDMA may include communication protocols such as High Speed ​​Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High Speed ​​Downlink Packet Access (HSDPA) and / or High Speed ​​Uplink Packet Access (HSUPA).

[0140] In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c, or the RRHs 118a, 118b, TRPs 119a, 119b, and / or RSUs 120a, 120b and the WTRUs 102c, 102d in the RANs 103b / 104b / 105b may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 115 / 116 / 117 or 115c / 116c / 117c, 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. LTE and LTE-A technologies include LTE D2D and V2X technologies and interfaces (e.g., sidelink communications, etc.). 3GPP NR technology includes NR V2X technology and interfaces (e.g., sidelink communications, etc.).

[0141] In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c in the RAN 103 / 104 / 105, or the RRHs 118a, 118b, TRPs 119a, 119b, and / or the RSUs 120a, 120b and the WTRUs 102c, 102d, 102e, 102f in the RAN 103b / 104b / 105b, may be connected to a wireless LAN (WAN) or a wireless LAN (LAN) in a wireless LAN (LAN) network. Wireless technologies such as EDGE can be implemented.

[0142] The base station 114c of FIG. 26A may be, for example, a wireless router, a Home NodeB, a Home eNodeB, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in a local area, such as a workplace, a home, a vehicle, a campus, etc. In one embodiment, the base station 114c and the WTRU 102e may implement a radio technology, such as IEEE 802.11, to establish a wireless local area network (WLAN). In one embodiment, the base station 114c and the WTRU 102d may implement a radio technology, such as IEEE 802.15, to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114c and the WTRU 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. 26A, the base station 114b may have a direct connection to the Internet 110. Therefore, the base station 114c may not need to access the Internet 110 via the core network 106 / 107 / 109.

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

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

[0145] 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 a circuit-switched telephone network providing plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and Internet Protocol (IP) in the TCP / IP Internet protocol suite. The network 112 may include wired or wireless communication networks owned and / or operated by other service providers. For example, the network 112 may include another core network connected to one or more RANs that may use the same RAT as the RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 105b or a different RAT.

[0146] 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. 26A may be configured to communicate with a base station 114a, which may employ a cellular-based radio technology, and a base station 114c, which may employ an IEEE 802 radio technology.

[0147] 26B is a block diagram of an example apparatus or device configured for wireless communication according to the embodiments described herein, such as, for example, a WTRU 102. As shown in FIG. 26B, the example WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad / indicators 128, non-removable memory 130, removable memory 132, a power source 134, a Global Positioning System (GPS) chipset 136, and other peripherals 138. It will be understood that the WTRU 102 may include any subcombination of the foregoing elements while remaining consistent with an embodiment. Also, embodiments contemplate that the base stations 114a and 114b, and / or the nodes that the base stations 114a and 114b may represent, including, but not limited to, a transceiver station (BTS), a Node B, a site controller, an access point (AP), a Home Node B, an evolved Home Node B (eNodeB), a Home Evolved Node B (HeNB), a Home Evolved Node B Gateway, and a proxy node, may include some or all of the elements shown in FIG. 26B and described herein.

[0148] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. Although FIG. 26B depicts the processor 118 and the transceiver 120 as separate components, it should be understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

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

[0150] 26B 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 one embodiment, the WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 115 / 116 / 117.

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

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

[0153] The processor 118 may receive power from the power source 134 and may be configured to distribute and / or control the power to other components within the WTRU 102. The power source 134 may be any suitable device for providing power to the WTRU 102. For example, the power source 134 may include one or more dry batteries, solar cells, fuel cells, etc.

[0154] Processor 118 can also be coupled to a GPS chipset 136 configured to provide position information (e.g., longitude and latitude) regarding the current location of WTRU 102. In addition to, or instead of, information from GPS chipset 136, WTRU 102 can receive position information from a base station (e.g., base stations 114a, 114b) via air interfaces 115 / 116 / 117 and / or can determine its position based on the timing of signals received from two or more nearby base stations. It will be understood that WTRU 102 can obtain position information by any suitable positioning method while maintaining consistency with one embodiment.

[0155] Processor 118 can further be coupled to other peripheral devices 138, which can include one or more software modules and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, peripheral devices 138 can include various sensors such as an accelerometer, a biometrics (e.g., fingerprint) sensor, an e-compass, a satellite transceiver, a digital camera (for photos or video), a universal serial bus (USB) port or other interconnect interface, a vibration device, a television transceiver, a hands-free headset, a Bluetooth® module, a frequency modulation (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, etc.

[0156] WTRU 102 can be embodied in other apparatuses or devices such as sensors, consumer electronics, wearable devices such as smart watches or smart clothing, medical or e-health devices, robots, industrial equipment, drones, vehicles such as cars, trucks, trains, or airplanes. WTRU 102 can be connected to other components, modules, or systems of such apparatuses or devices via one or more interconnect interfaces such as an interconnect interface that includes one of peripheral devices 138.

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

[0158] As shown in FIG. 26C, Node B 140a, 140b can communicate with RNC 142a. Additionally, Node B 140c can communicate with RNC 142b. Node B 140a, 140b, 140c can communicate with their respective RNC 142a, 142b via an Iub interface. The RNCs 142a, 142b can communicate with each other via an Iur interface. Each of the RNCs 142a, 142b can be configured to control the respective Node B 140a, 140b, 140c to which it is connected. Additionally, each of the RNCs 142a, 142b can be configured to perform or support other functions, such as outer loop power control, load control, admission control, packet scheduling, handover control, macro diversity, security functions, data encryption, etc.

[0159] The core network 106 shown in Figure 26C 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. Although each of the foregoing elements is shown as part of the core network 106, it will be understood that any one of these elements may be owned and / or operated by an entity other than the core network operator.

[0160] The RNC 142a in the RAN 103 may be connected to an MSC 146 in the core network 106 via an IuCS interface. The MSC 146 may be connected to the MGW 144. The MSC 146 and 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.

[0161] The RNC 142a in the RAN 103 may also be connected to an SGSN 148 in the core network 106 via an IuPS interface. The SGSN 148 may be connected to a GGSN 150. The SGSN 148 and GGSN 150 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.

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

[0163] 26D is a system diagram of the RAN 104 and the core network 107 according to one embodiment. As mentioned above, the RAN 104 may communicate with the WTRUs 102a, 102b, and 102c over the air interface 116 using E-UTRA radio technology. The RAN 104 may also communicate with the core network 107.

[0164] The RAN 104 may include eNodeBs 160a, 160b, 160c, although it will be understood that the RAN 104 may include any number of eNodeBs while remaining consistent with an embodiment. The eNodeBs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the eNodeBs 160a, 160b, 160c may implement MIMO technology. Thus, the eNodeB 160a may, for example, use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.

[0165] Each of the eNodeBs 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 on the uplink and / or downlink, etc. As shown in FIG. 26D, the eNodeBs 160a, 160b, 160c may communicate with one another over an X2 interface.

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

[0167] The MME 162 may be connected to each of the eNodeBs 160a, 160b, and 160c in the RAN 104 via an S1 interface and may function 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 initial attachment of the WTRUs 102a, 102b, 102c, etc. 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.

[0168] The serving gateway 164 may be connected to each of the eNodeBs 160a, 160b, and 160c in the RAN 104 via an S1 interface. The serving gateway 164 may generally route and forward user data packets to / from the WTRUs 102a, 102b, 102c. The serving gateway 164 may also perform other functions, such as anchoring the user plane during inter-eNodeB handover, triggering paging when downlink data is available to the WTRUs 102a, 102b, 102c, managing and storing the context of the WTRUs 102a, 102b, 102c, etc.

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

[0170] 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 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 networks 112, which may include other wired or wireless networks owned and / or operated by other service providers.

[0171] 26E is a system diagram of the RAN 105 and the core network 109, according to one embodiment. The RAN 105 may be an Access Service Network (ASN) that employs IEEE 802.16 wireless technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 117. As described further below, communication links between different functional entities of the WTRUs 102a, 102b, 102c, the RAN 105, and the core network 109 may be defined as reference points.

[0172] As shown in FIG. 26E, the RAN 105 may include base stations 180a, 180b, 180c and an ASN gateway 182, although it will be understood that the RAN 105 may include any number of base stations and ASN gateways while remaining consistent with an embodiment. Each of the base stations 180a, 180b, 180c may 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 an embodiment, the base stations 180a, 180b, 180c may implement MIMO technology. Thus, the base station 180a may, for example, 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, etc. The ASN gateway 182 can act as a traffic aggregation point and can be responsible for paging, caching of subscriber profiles, routing to the core network 109, etc.

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

[0174] 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, and 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, and 102c.

[0175] As shown in Figure 26E, the RAN 105 may be connected to a core network 109. The communication link between the RAN 105 and the core network 109 may be defined as an R3 reference point including protocols for facilitating data transfer and mobility management capabilities, for example. The core network 109 may include a Mobile IP Home Agent (MIP-HA) 184, an Authentication, Authorization, and Accounting (AAA) server 186, and a gateway 188. Although each of the foregoing elements are shown as part of the core network 109, it will be understood that any one of these elements may be owned and / or operated by an entity other than a core network operator.

[0176] The MIP-HA may be responsible for IP address management and may enable the WTRUs 102a, 102b, and 102c to roam between different ASNs and / or different core networks. The MIP-HA 184 may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The AAA server 186 may be responsible for user authentication and support of 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 owned and / or operated by other service providers.

[0177] Although not shown in Figure 26E, it will be understood 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 and the other ASNs may be defined as an R4 reference point, which may include protocols for coordinating mobility of the WTRUs 102a, 102b, 102c between the RAN 105 and the other ASNs. The communication link between the core network 109 and the other core networks may be defined as an R5 reference, which may include protocols for facilitating interworking between a home core network and a visited core network.

[0178] It should be understood that although the core network entities described herein and shown in Figures 26A, 26C, 26D, and 26E are identified by names given to those entities in certain existing 3GPP specifications, in the future, those entities and functions 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, it should be understood that the specific network entities and functions described and shown in Figures 26A, 26B, 26C, 26D, and 26E are provided by way of example only, and that the subject matter disclosed and claimed herein may be embodied or implemented in any similar communications system, whether currently defined or defined in the future.

[0179] FIG. 26F is a block diagram of an exemplary computing system 90 in which one or more devices of the communications networks shown in FIG. 26A, FIG. 26C, FIG. 26D, and FIG. 26E may be embodied, such as particular nodes or functional entities in the RAN 103 / 104 / 105, the core network 106 / 107 / 109, the PSTN 108, the Internet 110, or other networks 112. The computing system 90 may comprise a computer or server and may be controlled primarily by computer-readable instructions, which may be in the form of software, and such software may be stored or accessed anywhere or by any means. Such computer-readable instructions may be executed within a processor 91 to operate the computing system 90. The processor 91 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 91 may perform signal coding, data processing, power control, input / output processing, and / or any other function that enables the computing system 90 to operate within a communication network. The coprocessor 81 is an optional processor separate from the main processor 91 that may perform additional functions or assist the processor 91. The processor 91 and / or the coprocessor 81 may receive, generate, and process data related to the methods and apparatus disclosed herein.

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

[0181] The memories coupled to the system bus 80 include a random access memory (RAM) 82 and a read only memory (ROM) 93. Such memories include circuits that allow information to be stored and retrieved. The ROM 93 generally includes stored data that cannot be easily modified. Data stored in the RAM 82 can be read or changed by the processor 91 or other hardware devices. Access to the RAM 82 and / or the ROM 93 can be controlled by a memory controller 92. The memory controller 92 can provide an address translation function that converts virtual addresses to physical addresses when instructions are executed. The memory controller 92 can also provide a memory protection function that separates processes in the system and separates system processes from user processes. Thus, a program operating in the first mode can only access memory mapped by its own process virtual address space and cannot access memory in another process' virtual address space unless memory sharing between the processes is set up.

[0182] Additionally, computing system 90 may include a peripheral controller 83 responsible for communicating instructions from processor 91 to peripheral devices such as printer 94 , keyboard 84 , mouse 95 , and disk drive 85 .

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

[0184] Furthermore, the computing system 90 may include a communication circuit, such as a network adapter 97, for example, which can be used to connect the computing system 90 to an external communication network, such as the RAN 103 / 104 / 105, core network 106 / 107 / 109, PSTN 108, Internet 110, or other network 112 in FIGS. 26A, 26B, 26C, 26D, and 26E, so that the computing system 90 can communicate with other nodes or functional entities of those networks. The communication circuit may be used, alone or in combination with the processor 91, to perform the transmission and reception processes of some of the devices, nodes, or functional entities described herein.

[0185] FIG. 26G illustrates one embodiment of an example communication system 111 in which the methods and apparatus described and claimed herein may be embodied. As illustrated, the example communication system 111 may include wireless transmit / receive units (WTRUs) A, B, C, D, E, F, a base station, a V2X server, and RSUs A and B, although it will be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. One or more or all of WTRUs A, B, C, D, E may be outside the range of the network (e.g., outside the cell coverage boundary shown as a dashed line in the figure). WTRUs A, B, C form a V2X group, in which WTRU A is a group lead and WTRUs B and C are group members. WTRUs A, B, C, D, E, F may communicate over a Uu interface or a sidelink (PC5) interface.

[0186] It should be understood that any or all of the devices, systems, methods, and processes described herein may be embodied in the form of computer-executable instructions (e.g., program code) stored on a computer-readable storage medium, which, when executed by a processor, such as processor 118 or 91, causes the processor to perform and / or implement the systems, methods, and processes described herein. In particular, any of the steps, operations, or functions described herein may be implemented in the form of such computer-executable instructions and executed on a processor of a device or computing system configured for wireless and / or wired network communication. Computer-readable storage media include volatile and non-volatile media, removable and non-removable media implemented in any non-transitory (e.g., tangible or physical) method or technology for storage of information, although 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 disk (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other tangible or physical medium that can be used to store the desired information and that can be accessed by a computing system.

[0187] [Annex] [Table 1] [Table 2] [Table 3-1] [Table 3-2] [Table 3-3] [Table 4-1]

Table 4-2

Table 5-1

Table 5-2

Table 6-1

Table 6-2

Table 7

Table 8

Table 9

Table 10

Table 11

Table 12

Claims

1. 1. A user equipment (UE) hosting an edge application handover client (EAHC), the UE comprising a processor, a memory, and a communication circuit, the UE being connected to a first network via the communication circuit, the UE further comprising computer-executable instructions stored in the memory, the computer-executable instructions, when executed by the processor, causing the UE to: configuring the EAHC with application information from one or more Application Clients (ACs), the ACs being present on the UE, the application information including a designated route for the UE or a predicted route for the UE; sharing a designated route of the UE or a predicted route of the UE with a 3GPP network using the EAHC; receiving a notification from the 3GPP network regarding the movement of the UE; comparing the UE's movements with a plurality of Edge Application Servers (EAS) deployed along the UE's designated route or the UE's predicted route; determining, using the EAHC and based on the comparison, when the EAHC triggers an edge application handover; providing assistance for seamless edge application handover of an AC between the EASs using the EAHC and based on the determination; To carry out User Equipment (UE).

2. 2. The UE of claim 1, wherein the EAHC comprises a dedicated function or sub-function of a 3GPP Edge Enabler Client, a 3GPP Vehicle-to-Everything (V2X) Application Enabler Client, a oneM2M Common Services Entity, a oneM2M Application Entity (AE), or an LWM2M Client.

3. The instruction is to the EAHC: determining a predicted route for the UE using the context information; determining a next edge application server for handoff of the AC based on the predicted route and a selected UE location; The UE of claim 1 , further comprising:

4. The instruction is to the EAHC: determining service requirements and context information by analysis of the AC, the EAS, and one or more networks interconnecting the AC and the EAS; using the service requirements and context information in providing the assistance for seamless edge application handover; The UE of claim 1 , further comprising:

5. The instruction is to the EAHC: aggregating service requirements and context information of all ACs on the UE; and optimizing edge application handover decisions across all ACs on the UE; and The UE of claim 1 , further comprising:

6. 2. The UE of claim 1, wherein the instructions further cause the EAHC to issue a request to one or more Edge Application Handover Servers (EAHSs) in the first network, the request relating to assistance with an edge application handover operation.

7. The UE of claim 1 , wherein the instructions further cause the EAHC to issue a subscription request to an Edge Application Handover Server (EAHS) in the first network.

8. The UE of claim 7 , wherein the instructions further cause the EAHC to receive, from the EAHS, a notification responsive to the subscription request.

9. The instruction is to the EAHC: During edge application handover, monitoring application state synchronization or transition between edge application handover servers; determining whether the edge application handover was successful and whether another edge application handover is required based on the application state synchronization or transition; The UE of claim 1 , further comprising:

10. An edge application handover server (EAHS) comprising a processor, a memory, and a communication circuit, the EAHS coupled to a first network via the communication circuit, the EAHS further comprising computer-executable instructions stored in the memory, the computer-executable instructions, when executed by the processor, causing the EAHS to: Configuring an Edge Application Handover (EAH) policy using application information from one or more Application Clients (ACs), the ACs being present on User Equipment (UE), the application information including a designated route for the UE or a predicted route for the UE; Sharing the designated route of the UE or the predicted route of the UE with a 3GPP network; receiving a notification from the 3GPP network regarding the movement of the UE; comparing the UE's movements with a plurality of Edge Application Servers (EAS) deployed along the UE's designated route or the UE's predicted route; determining when to trigger an edge application handover based on the comparison; and providing support for seamless edge application handover of an AC between the EASs based on the determination; and To carry out Edge Application Handover Server (EAHS).

11. 11. The EAHS of claim 10, wherein the EAHS comprises a V2X application enabler server, a service enabler architecture layer server, an edge enabler server, an edge data network configuration server, a oneM2M common services entity, or an LWM2M server.

12. The instruction is to the EAHS: supporting an interface to a 3GPP entity within a 3GPP system; receiving 3GPP context information from the 3GPP entity for one or more of a core network function, an application client, an edge enabler client, an edge application handover client, a V2X application enabler server, a service enabler architecture layer server, an edge enabler server, an edge data network configuration server, a ONEm2m common services entity, and a LWM2M server; using the 3GPP context information in providing the assistance; and The EAHS of claim 10 , further comprising:

13. 11. The EAHS of claim 10, wherein the instructions further cause the EAHS to trigger an edge application handover client (EAHC) to perform an edge application handover operation on behalf of an AC and assist the AC in performing the edge application handover.

14. The EAHS of claim 10 , wherein the instructions further cause the EAHS to receive, from an EAHC hosted on a second UE, a subscription request relating to receiving notifications from the EAHS.

15. The EAHS of claim 14 , wherein the instructions further cause the EAHS to send a notification to the EAHC in response to the subscription request.

16. The instruction is to the EAHS: Supporting an interface to management functions; discovering available edge nodes capable of hosting one or more specified types of edge application servers via the interface to the management function; The EAHS of claim 10 , further comprising:

17. 17. The EAHS of claim 16, wherein the instructions further cause the EAHS to specify to the management function edge node criteria regarding proximity of a selected UE to a route.

18. The EAHS of claim 10 , wherein the instructions further cause the EAHS to monitor operation of application state synchronization or migration occurring between edge application servers during edge application handover.

19. The instruction is to the EAHS: determining a predicted route for the selected UE using the context information; determining a next edge application server for handoff of one or more application clients hosted on the selected UE based on the predicted route and a location of the selected UE; The EAHS of claim 10 , further comprising:

20. The instruction is to the EAHS: sending to the 3GPP network a request for the 3GPP network to track movement of the selected UE along a predicted route; receiving a notification from the 3GPP network regarding the movement of the selected UE, the notification including either an indication of the arrival of the selected UE within a vicinity of a waypoint along the predicted route or an indication that the selected UE has deviated from the predicted route; The EAHS of claim 10 , further comprising:

Images