User equipment and network devices for seamless edge application switching

Abstract

The edge application switching client in the user equipment can use application client information, such as type service, provider, location, context, and recipient requirements, to assist in seamless edge application switching of application clients between edge application servers. For example, the switching client can use context information to determine the expected route of the user equipment and thereby determine the next edge application server for handover. The switching client can weigh the needs of multiple application clients m to select a server for switching. The switching client can send a request to the server requesting an assisted switching operation, and can send a subscription request to the server, and can also determine the success of the switching by monitoring the synchronization or migration of application states between edge application switching servers.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Provisional Patent Application No. 62 / 951,377, filed on December 20, 2019, entitled “Seamless Edge Application Handover,” the contents of which are incorporated herein by reference. Background Art

[0003] Machine-to-machine (M2M), Internet of Things (IoT), and Web of Things (WoT) network deployments may include various servers, gateways, and devices, such as those described in, for example, the following documents: 3GPP Application Layer Support for Vehicle-to-Everything (V2X) Services, 3GPP TS 23.286 v16.1.0; 3GPP Study on Enhancements to Application Layer Support for V2X Services, 3GPP TR 23.764, v0.2.0; 3GPP; Study on Application Architecture for 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 Protocol LWM2M, v 1.1. Summary of the invention

[0004] The edge application handover client (EAHC) functionality may be hosted on a UE that performs one or more of the following operations to assist an application client (AC) on the UE in performing handover between different instances of an edge application server (EAS) in the system.

[0005] The EAHC function on the UE may be a new dedicated function, or it may be a sub-function of an existing function such as 3GPP edge enabler client, 3GPP V2X application enabler client, oneM2M public service entity (CSE), oneM2M AE or LWM2M client.

[0006] EAHC may support capabilities to be configured using EAH policies. EAH policies may include criteria for determining what EAH operations EAHC will perform and under what conditions it will perform these operations. EAH policies may contain rules depending on the following:

[0007] ■Type of service requested

[0008] ■Users, Subscribers and / or AC

[0009] ■Network and / or service provider

[0010] QoS / QoE level

[0011] ■UE location

[0012] ■UE’s designated or expected route

[0013] ■Edge or local area data network instance to which the UE is connected

[0014] ■The status or availability of edge nodes

[0015] ■Deployment status of the requested service

[0016] EAHC may support the ability to connect to ACs hosted on UEs to enable ACs to share their past, present, or future application service requirements and context information with EAHC. EAHC may store and process such information locally to assist in seamless edge application switching of ACs between EASs. EAHC may determine whether / when switching of ACs from one EAS to another EAS is required taking into account such context. EAHC may also share such information with EAHS in the network to assist ACs in managing seamless edge application switching between EASs.

[0017] By connecting with the AC on the UE, the EAHC may also support the capability to allow 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 is able to receive such requests from the AC and assist the AC by performing EAH operations on their behalf.

[0018] EAHC can support the ability to analyze service requirements and contextual information related to AC, EAS, and (one or more) networks interconnecting AC and EAS. Based on this analysis and EAH policy, EAHC can determine whether EAH is needed / when EAH is needed. EAHC can trigger AC to perform EAH operations. Alternatively, EAHC can perform EAH operations on behalf of AC to assist it in performing EAH.

[0019] Since the EAHC may be privately aware of the service requirements and context information of all ACs hosted on the UE, the EAHC may aggregate such information to make EAH decisions that are optimized across all ACs on the UE. For example, if a single edge node in the network supports all EAS required by different ACs on the UE, the EAHC may determine that EAH operations are needed to enable the ACs to use the EAS hosted on this single edge node in order to enable the UE to operate in a more efficient manner (e.g., the UE only requires a single PDU session with a single edge node).

[0020] The EAHC may issue a request to one or more EAHSs in the network to assist the EAH operation. One type of request may include a request for obtaining information about available EASs in the current vicinity of the UE (e.g., within the same LADN), and the available EASs are the best candidate EASs to which the AC will switch.

[0021] The EAHC may issue (one or more) subscription requests to the EAHS in the network to receive notifications from the EAHS. One type of subscription may be to receive notifications when the EAHS determines that the AC should be handed over from one EAS to another.

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

[0023] When EAH occurs, EAHC can perform EAS FQDN resolution assistance operations. In order to minimize the impact of EAH on the AC and allow the AC to continue to use the same EAS FQDN before and after EAH occurs, EAHC can perform EAS FQDN resolution operations on behalf of the AC. This enables the AC to use the same EAS FQDN to communicate with EAS even after EAH has occurred. Therefore, the AC is not burdened with managing lower-level EAS contact point information (e.g., IP addresses, ports, URIs) that can become stale after EAH occurs. Instead, EAHC can handle this burden on behalf of the AC.

[0024] The EAHC may perform the establishment and teardown of secure sessions on behalf of the AC in an EAH-aware manner. These operations may be performed by the EAHC when the EAHC triggers the EAH or in response to an EAH request received by the EAHC from the AC or EAHS.

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

[0026] While EAH operations are being performed, the EAHC can buffer outgoing requests from the AC toward the EAS (e.g., refreshing DNS query results, migrating state information to the new EAS, etc.) When the EAH operations are complete and the new EAS is accessible, the EAHC can forward these requests to the new EAS for processing.

[0027] The Edge Application Switching Server (EAHS) function may perform one or more of the following operations to assist an Application Client (AC) hosted on a UE in performing seamless switching between different instances of an Edge Application Server (EAS) in the system.

[0028] EAHS can be a standalone function or a sub-function of an existing EAHS (such as a V2X application enabler server, SEAL server, edge enabler server, edge data network configuration server, oneM2M CSE or LWM2M server).

[0029] EAHS may support capabilities to be configured using EAH policies. EAH policies may include rules for determining what EAH operations EAHS will perform and under what conditions it will perform these operations. EAH policies may contain rules depending on the following:

[0030] ■Type of service requested

[0031] ■Users, Subscribers and / or AC

[0032] ■Network and / or service provider

[0033] QoS / QoE level

[0034] ■UE location

[0035] ■UE’s designated or expected route

[0036] ■Edge or local area data network instance to which the UE is connected

[0037] ■The status or availability of edge nodes

[0038] ■Deployment status of the requested service

[0039] EAHS policy rules may be contingent on contextual information related to information such as the current location of the UE, the planned or intended route of the UE, and condition information related to the network (eg, congestion levels).

[0040] EAHS can connect to various entities in the 3GPP system and receive context information from these entities, including but not limited to core network functions, application clients, edge enabler clients, edge application switching clients, V2X application enabler servers, SEAL servers, edge enabler servers, edge data network configuration servers, oneM2MCSE or LWM2M servers.

[0041] Based on the EAH policy, the EAHC may analyze context information and service requirements from entities in the system and determine if / when EAH is needed. The EAHS may trigger the EAHC to perform EAH operations on behalf of the AC to assist it in performing EAH.

[0042] The EAHS may receive (one or more) subscription requests from the EAHC hosted on the UE for receiving notifications from the EAHS. One type of subscription may be to receive notifications when the EAHS determines that the AC should be handed over from one EAS to another EAS.

[0043] 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 for the EAHC to perform EAH operations for one or more specified ACs.

[0044] The EAHS may connect to management function(s) in the system to query and discover available edge nodes that host (or are capable of hosting) one or more specified types of EAS.

[0045] The EAHS may further specify the queried edge nodes as being located near the specified UE and / or on the expected route of the UE.

[0046] Based on the EAH policy and relevant context information, the EAHS may determine whether / when an edge node needs to perform an EAS management operation (eg, an edge node near the current location of the AC or along an expected route).

[0047] The EAHS may be connected to management function(s) in the system to manage the deployment of EAS and installed instances of EAS on available edge nodes (eg, edge nodes near the current location of the AC or along an expected route).

[0048] The EAHS may assist the management function(s) in the system by sharing EAH-related contextual information and / or executing the EAH as needed by the management function(s).

[0049] EAHS may assist management function(s) in the system to interact with the service provider to trigger management actions (e.g., deploy new EAS, install / activate EAS). EAHS may connect to 3GPP network functions to configure and reserve connectivity-centric resources (e.g., QoS sessions) in the 3GPP network between the AC on the UE and an EAS near the UE's current location or along an expected route.

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

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

[0052] When EAH occurs, EAHS can assist the EAS involved in the handover to each other to establish a trust relationship so that they can safely perform handover operations, such as secure synchronization / migration of application states. When the AC switch occurs to the new EAS, EAHS can share the credentials of the old EAS with the new EAS, and vice versa.

[0053] When EAH occurs, EAHS can trigger and monitor the application state synchronization or migration operation between EAS during EAH. Based on the status of application state synchronization or migration, EAHS can determine whether EAH is successful or another EAH is needed.

[0054] Using the context information, a predicted route may be calculated by the EAHS and subsequently used to select the next EAS(s) to which the AC(s) hosted on the UE is handed over. The EAHS may monitor the current location of the UE(s) relative to the different waypoints defined by the route and track the movement of the UE along the route and any unexpected deviations.

[0055] EAHS may share the intended route information of one or more UEs with the 3GPP network to enable the network to configure and optimize its network resources to ensure that the requirements (eg, QoS) of the UE(s) are met while traveling along the route.

[0056] EAHS may request the 3GPP network to track the movement of UE(s) along the intended route on its behalf and send it notifications about the movement of UE(s) along the route, such as when the UE reaches a designated waypoint along the route or when the UE deviates from the route.

[0057] This Summary is provided to introduce a selection of concepts that are further described below in the Detailed Description in a simplified form. 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. Additionally, the claimed subject matter is not limited to limitations that solve any or all disadvantages noted in any part of this disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0059] Figure 1 is a block diagram of an example of usage of edge and cloud V2X application servers by a V2X application client on a user equipment (UE).

[0060] Figure 2 is a block diagram of an exemplary 3GPP architecture for implementing edge applications.

[0061] Figure 3 is a block diagram of an exemplary 3GPP defined architecture for implementing V2X applications. See TS 23.286.

[0062] Figure 4 An exemplary protocol stack supporting the service layer is shown.

[0063] Figure 5 is a block diagram of an exemplary IoT service layer (SL) deployed on various types of connected network nodes.

[0064] Figure 6 is a block diagram of exemplary edge application switching client and server functionality.

[0065] Figure 7 is a call flow of an exemplary IEAHC-AC function.

[0066] Figure 8 FIG. 4 is a call flow of an exemplary IEAHS-EAS function.

[0067] Fig. 9 is a calling flow of an exemplary IEAHS-EAHC function.

[0068] Fig.10 FIG. 4 is a calling flow of an exemplary IEAHS-3GPP function.

[0069] Fig.11 is the calling flow of an exemplary IEAHS-MF function.

[0070] Fig.12 FIG. 4 is a call flow of an exemplary EAH policy function.

[0071] Fig.13A and 13B Shows the call flow for an exemplary EAH-aware FQDN resolution.

[0072] Fig.14A and 14B An exemplary EAH-aware session teardown and establishment call flow is shown.

[0073] Fig.15A and 15B An exemplary EAH-aware state synchronization / migration call flow is shown.

[0074] Fig.16A and 16B An exemplary EAH-aware request buffering call flow is shown.

[0075] Fig.17A , 17B and 17C show an exemplary EAH-aware session QoS continuity call flow.

[0076] Fig.18A and 18B A call flow showing various exemplary scenarios of the EAH-aware management process.

[0077] Fig.19A and 19B Call flows showing two exemplary scenarios of EAH-aware edge computing service provider interactions.

[0078] Fig. 20A and 20B An example call flow showing the route assist EAH.

[0079] Fig.21 It is a block diagram of the 3GPP SA6 EDGEAPP example.

[0080] Fig. 22 Figure 1 is a block diagram of the 3GPP SA6 V2X example.

[0081] Fig.23 is a block diagram of the oneM2M example.

[0082] Fig.24 is a block diagram of the LWM2M example.

[0083] Fig.25 An exemplary graphical user interface (GUI) for configuring EAH policies is shown.

[0084] Fig.26A An exemplary communication system is shown in which the methods and apparatus described and claimed herein may be implemented;

[0085] Fig.26Bis a block diagram of an exemplary device or apparatus configured for wireless communication;

[0086] Fig.26C is a system diagram of an exemplary radio access network (RAN) and core network;

[0087] Fig.26D is a system diagram of another exemplary RAN and core network;

[0088] Fig.26E is a system diagram of another exemplary RAN and core network;

[0089] Fig.26F is a block diagram of an exemplary computing system; and

[0090] Figure 26G is a block diagram of another exemplary communication system. DETAILED DESCRIPTION

[0091] Table 0.1 of the Appendix contains explanations of selected abbreviations used herein. Table 0.2 contains explanations of selected terms.

[0092] Edge application deployment

[0093] The benefits of deploying application servers (AS) at the edge of 3GPP systems 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 the deployment of ASs at the edge of their networks, because this deployment model can allow them to distribute load in their networks and reduce congestion levels (e.g., by enabling localized communication between ACs and ASs).

[0094] For example, Figure 1 Represents autonomous vehicle usage. The vehicle hosts the UE, and the V2X AC used by the vehicle's autonomous driving control system is hosted on the UE. The V2X AC communicates with V2X services (e.g., platooning services, cooperative driving services, conflict avoidance services, etc.) deployed in the 3GPP system. The V2X services are deployed on the system in a distributed manner as a combination of V2X AS deployed on edge nodes (e.g., roadside units, cellular towers, etc.) and deployed in the cloud.

[0095] For enhanced performance (e.g., reduced access latency and higher reliability), the preferred method for accessing V2X services by the V2X AC is to access the V2X services 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 is able to utilize more timely and reliable information about other vehicles and the conditions of roads and traffic. As a result, the vehicle is able to travel at a higher speed and at a closer distance to other vehicles. The vehicle is also able to change lanes more frequently and efficiently without sacrificing safety. In contrast, when accessing the V2X AS in the cloud, the vehicle must fall back to a more conservative operating mode due to the reduced availability of timely information. This typically results in a reduction in the speed of the vehicle, an increase in the distance between the vehicle and other vehicles, and suboptimal lane changes.

[0096] As the vehicle travels along the road, the switching of V2X AC between the V2X AS hosted on different edge nodes closest to the vehicle must be coordinated. Similarly, for situations where the edge network coverage fades in and out during the vehicle's journey, the switching of V2X AC between the V2X AS hosted on the edge node and the V2X AS hosted in the cloud must also be coordinated. For all of these scenarios, seamless (e.g., low latency and reliable) V2X AC switching between AS hosted on the edge node and hosted in the cloud is critical and necessary for the successful deployment of this type of V2X use case and other types of use cases with similar requirements as V2X.

[0097] 3GPP Architecture for Implementing Edge Applications

[0098] Figure 2 The 3GPP defined architecture for implementing edge applications is shown. See TR 23.758. The framework for implementing edge applications includes an edge enabler client and (one or more) application clients hosted on the UE and an edge enabler server and (one or more) edge application servers hosted in the edge data network. The edge data network configuration server is used to configure the edge enabler client and edge enabler server. The edge enabler client and server provide edge-centric capabilities to the application client and server, respectively. The edge enabler server and edge data network configuration server can also interact with the 3GPP network.

[0099] 3GPP architecture for implementing V2X applications

[0100] Figure 33GPP-defined architecture for implementing V2X applications is shown. See TS23.286. The V2X Application Enablement (VAE) layer includes a VAE client hosted on the UE and a VAE server hosted in the network. The VAE client and server provide VAE-centric capabilities to the V2X application clients and servers. The VAE client and server are connected to more general (e.g., non-V2X-specific) services provided by the Service Enabler Architecture Layer (SEAL) client and server, respectively. SEAL services include location management, group management, configuration management, identity management, key management, and network resource management.

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

[0102] IoT Service Layer (SL)

[0103] The IoT Service Layer (SL) is a technology specifically designed to provide value-added services for IoT devices, IoT applications, and IoT data. Recently, several industry standard bodies have been developing IoT SL to address the challenges associated with combining IoT devices, applications, and data in deployments that utilize the 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.286v16.1.0; 3GPP Study on Enhancements to Application Layer Support for V2X Services, 3GPP TR 23.764, v0.2.0; oneM2M TR 23.758; oneM2M 3GPP Interworking, oneM2M TS-0026, v4.2.0; and Open Mobile Alliance (OMA) Lightweight Machine-to-Machine Protocol LWM2M, v 1.1.

[0104] IoT SL can provide applications and devices with access to a range of IoT-oriented capabilities. Some examples include security, charging, data management, device management, discovery, provisioning, and connectivity management. These capabilities are available to devices and applications using the message formats, resource structures, and resource representation APIs supported by IoT SL.

[0105] From a protocol stack perspective, SLs are usually located above the application protocol layer and provide value-added services to the applications they support. Therefore, SLs are often classified as "middleware" services. Figure 4 Shows an example service layer between application protocols and applications.

[0106] From a deployment perspective, IoT SL can be deployed on various types of network nodes (including IoT servers, gateways, and devices), such as Figure 5 as shown in .

[0107] Example Challenges

[0108] 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 3GPP systems in a manner that has minimal impact on application clients (ACs) hosted on UEs. However, for use cases involving ACs hosted on UEs that require frequent switching between EASs, the current 5G edge application architecture does not yet define sufficient support for seamless switching of ACs from one EAS to another. Wherein seamless switching of ACs from one EAS to another EAS means maintaining the service level experienced by the AC, and there is no significant service degradation or service interruption. The frequency of switching is determined by the service level required by the AC (e.g., latency) and the service coverage area of ​​the available EASs.

[0109] 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., formation) that can be deployed on a 3GPP system. However, the current 5G V2X application architecture does not yet define sufficient support for seamless switching of V2X ACs between V2X EAS.

[0110] To support such Figure 1 The use case of the V2X example shown in FIG. 4 requires the ability to seamlessly transition (e.g., handover) an AC from one EAS to another EAS with low latency and high reliability. The following is a summary of some of the unique challenges involved in achieving seamless handover of ACs between EASs. These challenges have not yet been adequately addressed by the 5G edge application architecture or the 5G V2X application architecture.

[0111] Determining which EAS in the system is the best EAS to use at a given point in time and when the AC needs to be transitioned to use that EAS to ensure that continuity of service is maintained can be challenging because the conditions that need to be considered can be numerous, highly variable, and can originate from several different entities in the system. For example, the status and context of the UE and its AC, the health and availability of the EASs in the vicinity of the UE, and the health and availability of the network connecting the AC and the EASs can all be highly variable. Relying on the AC to make the best decision about which EAS to use and when a switch to a different EAS needs to be performed is neither realistic nor optimal in a real deployment.

[0112] EAS will usually be deployed on different edge nodes in the system. Each EAS will have a unique (one or more) contact point, which includes (one or more) IP addresses, (one or more) ports and (one or more) URI paths of the services and resources they provide. Accessing a given EAS requires the AC to send a request to the contact point of the EAS. If / when a switch to a new EAS occurs, a change in the contact point information will occur. Changes in the contact point information of the EAS can have a significant impact on the AC. It is not uncommon for the contact point information of the EAS to be directly configured and / or encoded into the AC. Therefore, if the contact point information of the EAS changes, this will usually require the AC to be aware of this change. The AC must then stop its communication with the old EAS, initiate the removal 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 removal and re-establishment of various types of sessions requires that the new session be configured in a manner consistent with the previous one so that the switch occurs seamlessly. This also needs to occur in a timely manner so that no disruption of service occurs for the AC.

[0113] While ensuring that the service requirements of the AC are still met, it is also possible to ensure that the optimal use of the limited edge nodes and edge network resources in the system can be challenging and directly compete with each other. Edge nodes will usually be deployed with a fixed / limited amount of resources (e.g., CPU, memory, storage device). Unlike cloud deployments that usually support the ability to be dynamically adjusted via cloud adjustment technology, once the resources of the edge node are consumed, additional resources cannot usually be easily added. Similarly, edge nodes will usually be deployed in edge networks (e.g., 3GPP LADN), which will have a fixed / limited amount of resources (e.g., bandwidth) compared to the core network. Given these fixed / limited resources, it may not be possible to deploy EAS to edge nodes in a static or pre-provisioned manner before the AC needs EAS. For this reason, a more dynamic method may be needed to intelligently manage the EAS on the edge nodes in the system so that the resources on the edge nodes are efficiently used and the service requirements of the AC are still met. For example, deploying EAS to edge nodes may first require removing or disabling other EAS to release edge node resources for the new EAS. This may require coordination between entities in the system to determine which EAS are being actively used by the AC and which EAS are not being actively used by the AC so that candidate EAS for removal or deactivation can be determined. For example, V2X use cases typically involve V2X ACs hosted on vehicles that move in and out of the vicinity of different edge nodes of the system at a high frequency. For these use cases, the V2X AC needs to use the V2X EAS during a short duration when the V2X AC is located near an edge node hosting the V2X EAS. Once the vehicle and its V2X AC leave the vicinity of the edge node hosting the V2X EAS and enter the vicinity of other edge nodes, methods are needed to ensure that the required (one or more) types of V2X EAS are available and accessible on the appropriate edge nodes located near the V2X AC. These methods must ensure that the required (one or more) instances of the V2X EAS are installed, running and securely accessible by the V2X AC so that the transition occurs seamlessly and does not interrupt the service continuity of the V2X AC. Managing different V2X EAS hosted on different edge nodes in the system to enable seamless edge application handover to occur can be very challenging depending on the speed at which the vehicle is traveling and the service requirements of its V2X AC (e.g., latency, reliability, etc.). Ensuring that instances of the required EAS are available on the right edge node, at the right location, and within the right time window when the AC needs to access them can be a challenging task to manage.

[0114] Example Solutions

[0115] Figure 6Represents: Edge application switching client and server functionality. Here, several concepts are provided to address the shortcomings of existing 5G edge application architecture and 5G V2X application architecture related to insufficient support for seamless switching of UE application clients (AC) between edge application servers (EAS) and / or vertical application servers (such as VAE application servers in 3GPP systems). See, for example, TS23.286, TR 23.758, and TR 23.764. Here, unless explicitly specified, EAS may include or imply a vertical application server, such as a VAE application server defined in 3GPP SA6 or other standards.

[0116] The techniques described herein for assisting AC switching between EASs may also be applied to assist AC switching between EASs and cloud application servers, for example, as Figure 1 The same is true in the usage case.

[0117] Assisted edge application switching framework

[0118] In order to enable seamless handover of AC between EASs in the system (e.g., when a UE moves out of the vicinity of one EAS and moves into the vicinity of another EAS), an edge application handover (EAH) framework is described, which provides assisted handover capabilities to AC and EAS. The EAH framework can be deployed in a distributed manner, including an edge application handover client (EAHC) and an edge application handover server (EAHS), such as Figure 6 as shown in .

[0119] The edge application handover client (EAHC) and the edge application handover server (EAHS) are connected to various other entities in the system, such as one or more application clients (AC), edge application servers (EAS), management functions (MF) and 3GPP networks as shown in the figure, via IEAHC-AC, IEAHS-EAS, IEAHS-MF and IEAHS-3GPP reference points, respectively. EAHC and EAHS can also be connected to each other via the IEAHS-EAHC reference point.

[0120] The EAHC function can be hosted on a UE in the system and interact with the EAHS function to assist in seamless switching of ACs between EASs. The EAHC can 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 can also be deployed as a sub-function of an existing non-3GPP-defined function (such as oneM2M CSE or LWM2M client). When assisting edge application switching, the EAHC can connect to and interact with various other functions in the system. This may involve the EAHC 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 document.

[0121] The EAHS function is defined so that it can be deployed outside the UE within the system. EAHS can be deployed as an independent function in the system, or as a sub-function of an existing function (such as a 3GPP V2X application enabler server, a SEAL server, an edge enabler server, an edge data network configuration server, or an SCS / AS). EAHS can also be deployed as a sub-function of an existing non-3GPP defined function (such as oneM2M CSE or LWM2M server). EAHC interacts with the EAHS function to assist in the seamless switching of ACs between EAS. The EAHS function can be deployed within an edge data network, within a cloud network, or within a 3GPP network. When assisting edge application switching, EAHS can also connect to and interact with various other functions in the system. This may involve 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 article.

[0122] The management function (MF) function is defined so that it can be deployed outside the UE within the system. The MF can be deployed as an independent 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 can also be deployed as a sub-function of an existing non-3GPP defined function (such as oneM2M CSE or LWM2M server). The MF interacts with the EAHS function to receive information about the capabilities and instantiation of the EAHS. The MF interacts with the EAHC to send the EAH policy to the EAHC. The MF function can be deployed within the edge data network, within the cloud network, or within the 3GPP network. When assisting edge application switching, the MF can also connect to and interact with various other functions in the system. This may involve 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 article.

[0123] Auxiliary edge application switching reference point

[0124] IEAHC-AC Reference Point

[0125] like Figure 7 As shown in FIG. 1 , EAHC may support a reference point (IEAHC-AC) for AC hosted on a UE. Via IEAHC-AC, EAHC may support various types of EAH-centric operations between itself and AC, such as, but not limited to, those described in Table 1 of the Appendix and in Figure 7 It should be noted that the EAH operations may be performed in an order different from the order shown, and the operations may be performed independently of each other.

[0126] Additional details of the exemplary IEAHC-AC operation defined in Table 1 of the Appendix are described below.

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

[0128] Since the EAHC may be privately aware of the service requirements and context information of all ACs hosted on the UE, the EAHC may support the ability to aggregate such information to make EAH decisions that are optimized across all ACs on the UE. For example, if a single edge node in the network supports all EAS required by different ACs on the UE, the EAHC may determine that EAH operations are needed to enable the ACs to use the EAS hosted on this single edge node in order to enable the UE to operate in a more efficient manner (e.g., the UE only requires a single PDU session with a single edge node).

[0129] The EAHC may receive prioritization information. The prioritization information may come 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, and the EAHC may use such information when determining what edge data network and EAS to connect to. For example, the EAHC may decide not to perform a handoff action and cause one application client to lose connectivity in order to avoid disrupting the connection of another application client. Alternatively, the EAHC may decide to perform a handoff action and cause one application client to lose connectivity in order to avoid disrupting the connection of another application client.

[0130] IEAHS-EAS Reference Points

[0131] like Figure 8As shown in , EAHS can support a reference point (IEAHS-EAS) to communicate with EAS in the system. Through IEAHS-EAS, EAHS can support various types of EAH-centric operations between itself and EAS, such as but not limited to the operations in Table 2 of the Appendix. It should be noted that Figure 8 The operations shown in the drawings may be performed in an order different from that shown, and the operations may be performed independently of other operations.

[0132] The IEAHS-EAS reference point may support various operations, such as but not limited to the operations in Table 2 of the Appendix.

[0133] IEAHS-EAHC Reference Points

[0134] like Fig. 9 As shown in , 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 connect to the EAHS to share information about the AC with the EAHS so that the EAHS can help assist the EAHC in performing EAH operations on behalf of the AC. It should be noted that Fig. 9 The operations shown in the drawings may be performed in an order different from that shown, and some operations may be performed independently of other operations.

[0135] IEAHS-EAHC may support various operations, such as but not limited to the operations in Table 3 of the Appendix.

[0136] IEAHS-3GPP reference point

[0137] Fig.10 Indicates IEAHS-3GPP function. Fig.10 As shown in , EAHS can support a reference point (IEAHS-3GPP) to communicate with 3GPP networks and their various functions (e.g., NEF). Via IEAHS-3GPP, EAHS can support the exchange of various types of EAH-centric operations with 3GPP networks. For example, EAHS can send a request to the 3GPP network to trigger a single UE (e.g., a vehicle) or a group of UEs (e.g., a fleet) to connect to a specified edge data network (e.g., 3GPP LADN) that EAHS has determined to be located nearby the UE (s). The 3GPP network can then trigger the UE (s) to connect to the edge data network. It should be noted that Fig.10 The operations shown in the may be performed in an order different from that shown, and the operations may be performed independently of other operations. The IEAHS-3GPP reference point may support various operations, such as but not limited to the operations in Table 4 of the Appendix.

[0138] IEAHS-MF and IEAHC-MF reference points

[0139] Fig.11 Indicates the IEAHS-MF function. Fig.11 As shown in , EAHS can support a reference point (IEAHS-MF) to communicate with a management function (MF) in the system. The MF in the system may have the responsibility to manage the EAS deployed in the system. For example, the installation / uninstallation, activation / deactivation, configuration / reconfiguration of the EAS hosted on the edge node within the edge network of the system. Via the IEAHS-MF, EAHS can support communication with the MF to assist in the management of the EAS and ensure that edge application switching occurs in a seamless manner. For example, EAHS can support the ability to connect to the MF to request the installation, configuration and / or activation of the EAS on the edge node within a specified edge network to which the UE has just been connected or is about to be connected. By connecting to the MF and assisting in the management, EAHS can help ensure that the AC hosted on the UE can transition to the new EAS with little / no interruption. It should be noted that Fig.11 The operations shown in the table may be performed in an order different from that shown, and the operations may be performed independently of other operations. The IEAHS-MF reference point may support various operations, such as but not limited to the operations in Table 5 of the Appendix.

[0140] In addition, but in Fig.11 Not shown in Table 5 of the Appendix, EAHC can support being configured with EAH policies or being instructed to perform EAH related operations via MF via the IEAHC-MF reference point. EAHC can also send a request to MF to perform EAH related operations via IEAHC-MF.

[0141] Assist edge application switching process

[0142] In the following subclauses, procedures are defined that enable EAHC and EAHS to assist AC and EAS in performing edge application switching. These procedures utilize the operations defined by each of the aforementioned EAHC and EAHS reference points.

[0143] EAH policy configuration

[0144] Fig.12 Indicates the EAH policy function. Fig.12As shown in steps 1a and 1b, both the EAHS and EAHC in the system may be configured using EAH policies. EAH policies may include criteria for determining what EAH operations the EAHS or EAHC is to perform and under what conditions it is to perform these operations. 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 switching clients, V2X application enabler servers, SEAL servers, edge enabler servers, edge data network configuration servers, and SCS / AS in the system. These entities may issue requests to the EAHS or EAHC to configure its EAH policies. Alternatively, the EAHS or EAHC may obtain EAH policies from these entities, or subscribe to these entities to receive notifications if / when changes to the EAH policies are needed ( Fig.12 not shown).

[0145] EAH policies may include EAH rules, such as but not limited to the EAH rules defined in Table 6. These rules may be stored and used by an EAHS or EAHC to control what EAH operations it performs and under what conditions it performs EAH operations ( Fig.12 Steps 2a and 2b). The information in Table 6 of the Appendix can be provided per EAS or EAS type.

[0146] EAH policy rules may rely on various types of EAH related context information available in the system, such as but not limited to the types defined in Table 7 of the Appendix. Such context information may be generated 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 SCS / AS. Fig.12 As shown in steps 3a and 3b, these entities may make a request to the EAHS or EAHC to share EAH-related context information. Alternatively, the EAHS or EAHC may obtain the EAH-related context from these entities, or subscribe to these entities to receive notifications if / when the context information of interest becomes available ( Fig.12 EAH-related context information may be made available to EAHSs and EAHCs in the system so that they can evaluate the EAH-related context information and specified rules defined within the EAH policy to determine what EAH actions to perform and under what conditions. Fig.12 Steps 4a and 4b.

[0147] EAH-aware FQDN resolution

[0148] To minimize the complexity and overhead of the AC's EAH, the EAHC and EAHS may support functionality that allows the AC to continue to use the same EAS FQDN they used before the EAH after the EAH. The functionality involves the EAHC and EAHS managing the lower-level contact point information (e.g., IP addresses, ports, URI paths, identifiers, security credentials, and / or service description information) of the EAS on behalf of the AC and performing EAS FQDN resolution operations. By doing so, the EAHC and EAHS are able to offload the burden of performing these operations to the AC, even knowing that these operations are being performed on their behalf.

[0149] The functionality involves the EAHC supporting enhanced DNS client functionality that is also aware of when edge application handoffs occur. This allows the EAHC to correctly resolve the EAS FQDN to the correct EAS contact point even when the UE is connecting to / from a different edge network and a runtime edge application handoff is occurring. The EAHC may also support an API that allows the AC to make requests to the EAHC to resolve the EAS FQDN on their behalf and receive EAS contact point information as needed.

[0150] Fig.13A and 13B : represents an example of EAH-aware FQDN resolution functionality. To enable EAHC to perform this functionality, EAHC may support configuring this capability using contact point information of (one or more) DNS servers ( Fig.13AStep 1). One or more) DNS servers host the DNS records of the EAS (e.g., EAS#1) currently available to the AC. When the UE connects to a different network domain (core or edge network domain), it can be configured using this contact point information of the (one or more) DNS servers. The entity that uses this DNS server contact point information to configure the UE's EAHC can be an EAHS as shown in step 1 or 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 contact points may be provided to the UE. Each contact point may be associated with an S-NSSAI and a DNN. The EAS may be associated with a specific network slice. For example, the UE uses a specific 3GPP PDU session associated with a specific network slice to access a given EAS. For this reason, a given DNS server can be associated with a specific edge data network and / or a specific 3GPP network slice. It should be noted that the SMF may provide a DNS server contact point for the UE during PDU session establishment. EAHC may give higher priority to the DNS server contact points supplied by the edge data network configuration server, SEAL server, edge enabler server or SCS / AS, and use the DNS server contact points provided by SMF only when the contact points supplied by the edge data network configuration server, SEAL server, edge enabler server or SCS / AS cannot resolve the FQDN.

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

[0152] In the event / when the EAH of one or more ACs is triggered by the AC, EAHC or EAHS (step 11), the EAHC is able to detect the occurrence of the EAH, determine the affected ACs and EASs (step 12a), and mark any cached DNS query results of these affected ACs and EASs as invalid / stale so that they are no longer used (step 12b). In addition, if the UE is connected to a different edge network with different DNS servers (one or more) that bind the EAS FQDN to different contact points, the EAHC may also receive (one or more) updated DNS server contact points ( Fig. 13B 13a). Alternatively, if a handoff occurs to a different EAS in the same edge network, the EAHS may alternatively update the DNS server records on the DNS server so that the EAS FQDN contact point information is updated to reflect the new EAS that should be accessed rather than the old EAS (step 13b). The updated DNS information may be sent from the EAHS to the EAHC within an EAH notify request. After updating the DNS servers, the EAHS may notify the EAHC(s) so that the EAHC(s) know to refresh any cached DNS results associated with the updated DNS server(s) (step 13c). After the EAH, and in the event / when the EAHC receives its next request from the AC to resolve the EAS FQDN (step 14), the EAHC is able to perform a new DNS query and obtain the latest EAS contact point information (steps 15 and 16). The EAHC may return this contact point information to the AC and cache it until another EAH is triggered (steps 17 and 18). The AC can then use the EAS contact point information to access the new EAS (step 19).

[0153] Alternatively, but not in Fig.13A and 13B, EAHC can alternatively act as a message broker between the AC and EAS, rather than the AC issuing an EAS FQDN resolution request to the EAHC and having it return EAS contact point information to the AC. When acting as a proxy, the AC can forward its requests targeting EAS to the EAHC to proxy on its behalf. Within the request, the AC can use the FQDN of the target EAS rather than the resolved contact point information of the EAS. Upon receiving the request from the AC, the EAHC can then perform EAS FQDN resolution in an EAH-aware manner and replace the FQDN with the appropriate EAS contact point information before forwarding the request to the EAS. By doing so, the AC does not need to know the EAS contact point information. The EAHC can hide the EAS contact point information from the AC and perform EAS FQDN resolution on behalf of the AC.

[0154] EAH-aware secure session teardown and establishment

[0155] Depending on the use case requirements, secure communications between the AC and EAS may be required. When secure communications are required, the AC and EAS must be configured with the appropriate credentials required to allow the AC and EAS to authenticate each other and establish a secure and trusted communication session (e.g., using a secure protocol (such as TLS) to perform a two-way authentication handshake). In order to enable seamless switching of AC between different EAS in the system, EAHC and EAHS can provide assistance to the AC and EAS to help manage credentials and assist in the establishment and teardown of secure communication sessions between the AC and EAS. By doing so, EAHC and EAHS are able to offload the burden of performing these operations from the AC and EAS themselves.

[0156] Fig.14A and 14B An example of functionality involving EAHC and EAHS assisting in the setup and teardown of secure communication sessions between AC and EAS when edge application switching occurs is shown. EAHC and EAHS may leverage existing trust relationships established between different paired entities in the system, such as AC and EAHC, EAHC and EAHS, EAS and EAHS, or EAHS and security functions in the network (e.g., AAA servers, certificate authorities, etc.). These pairwise trust relationships may be established using existing and well-known security methods (e.g., TLS sessions).

[0157] Once these pairwise trust relationships have been established, EAHC and EAHS can overlay additional security functionality on top of these pairwise trust relationships. This additional functionality can help the AC establish runtime trust relationships with EAS in the system, and assist EAS in establishing runtime trust relationships with other EAS (e.g., enabling EAS to securely synchronize or migrate edge application state during edge application switching). This functionality can be particularly useful when frequent edge application switching occurs, as the overhead of managing security credentials between AC and EAS can be high.

[0158] Use them to know when edge application switching occurs and their trust relationships with individual ACs and EASs ( Fig.14A In step 0), in the event / when EAH occurs, EAHC and EAHS are able to perform credential management operations to securely configure AC and EAS using each other's public credential information (e.g., PSK, certificates, etc.). AC is able to securely transmit (e.g., in an encrypted manner) their credential information to EAHC via a secure communication session between EAHC and AC (step 1). Similarly, EAS is able to securely transmit their credential information to EAHS via a secure communication session between EAHS and EAS (step 2). When the switching of AC occurs to a new EAS (step 3), EAHC is able to securely transmit the credential information of AC to EAHS via a secure communication session between EAHC and EAHS (step 4). EAHS is able to securely transmit the credentials of AC to the new EAS via a secure communication session between EAHS and EAS (step 5). Similarly, EAHS is able to securely transmit the credentials of EAS to EAHC via a secure communication session between EAHS and EAHC (step 6). The EAHC can then securely transmit 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, if new / updated credentials are required, the EAHS can also communicate with security functions in the network ( Fig.14A and 14B Once the AC and EAS have been 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, which they can use to securely exchange application layer messages with each other (step 12a).

[0159] In a similar manner, EAHS can also assist EAS involved in handover with each other and help them establish trust relationships with each other so that they can securely perform handover operations, such as secure synchronization / migration of application states. When the AC switch occurs to the new EAS, EAHS can securely transfer the credentials of the old EAS to the new EAS, and vice versa ( Fig.14AStep 8 and Fig. 14B This can be accomplished via a secure communication session between the EAHS and each EAS. During this process, if new / updated credentials are required, the EAHS may also communicate with security functions in the network ( Fig.14A and 14B Once the EASs have been 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 (step 10), which they can then use to securely synchronize / migrate application layer state with each other (step 11).

[0160] In addition to assisting with credential management, EAHC and / or EAHS may also assist in establishing and / or dismantling secure communication sessions between AC and EAS. Since EAHC is hosted on the same UE with the same IP address as AC, EAHC is well arranged to act as a security agent on behalf of AC. EAHC may establish (step 12b) a secure communication session with EAS and / or dismantle a secure communication session with EAS on behalf of AC (step 13). This can offload the burden of having to perform such operations on the AC itself and free them to perform other application-centric operations more efficiently. In addition, EAHC may be able to perform these operations in a more efficient manner because EAHC may know that EAH operations are occurring faster than AC. Therefore, EAHC may be able to start establishing or dismantling secure communication sessions faster than AC would be able to start establishing or dismantling secure communication sessions. This can help reduce EAH latency and improve overall system performance. For example, if the EAHC and EAHS are performing EAH operations (such as migrating / synchronizing state between ESAs during EAH), the EAHC and EAHS know when a secure communication session with the ESA is no longer needed and can tear down secure communications between the AC and EAS in an efficient and timely manner.

[0161] EAH-aware application state synchronization / migration

[0162] Depending on the use case requirements, 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 over may be required.

[0163] In order to achieve seamless switching of AC between different EAS in the system, EAHC and EAHS can help AC and EAS to help manage efficient synchronization or migration of application states between EAS. By doing so, EAHC and EAHS can offload the burden of performing these operations to AC.

[0164] Fig.15A and 15BIndicates that EAHC and / or EAHS trigger application state synchronization or migration operations to occur during EAH ( Fig.15A 1). These triggers can optionally be sent to the AC to cause the AC to initiate and / or perform a synchronization or migration operation (step 2a). Alternatively, the trigger can be sent from the EAHS or EAHC to the old EAS (EAS#1) (step 2b) and / or the new EAS (EAS#2) involved in the EAH (step 2c) or both. When the EAHC and / or EAHS detects that an EAH is needed and other necessary EAH operations have been completed (e.g., discovery of the selection of a new EAS, provisioning of EAS credentials for the EAS involved in the handover), the EAHC and / or EAHS may trigger an application state synchronization or migration operation. After triggering the application state synchronization or migration operation, the EAHC and / or EAHC may monitor whether the operation was successfully completed (step 2c). Fig. 15B 4). The EAHC and / or EAHS may receive status updates 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 perform additional operations, such as identifying a new EAS and triggering a new EAH (step 6b).

[0165] EAHC and EAHS can be well arranged to perform such triggering in a better manner than AC, using their knowledge of when edge application switching is initiated. This can offload the burden of AC having to initiate such operation itself.

[0166] EAH-aware request buffering

[0167] To enable seamless switching of an AC between different EASs in the system, the EAHC may store and forward outgoing requests from the AC to the EAS(s) until the EAH operation has completed and the AC is able to communicate with its new EAS(s).

[0168] Fig.16A and 16B An example of a function in which EAH is triggered in the system ( Fig.16A The AC continues to issue requests to access the EAS while the EAH is being processed (step 2). The EAHC buffers these requests while EAH operations are being performed by the EAHC and / or EAHS. For example, EAH operations such as EAH-aware FQDN resolution, EAH-aware session teardown and establishment, and EAH state synchronization / migration (step 4). When all EAS handover operations are successfully completed ( Fig. 16B 5), the EAHC can forward the buffered request to the "new" EAS (EAS#2) involved in the handover (step 6), and the response can flow back to the AC (step 7). When forwarding the buffered request, the EAHC can ensure that the target EAS FQDN specified in the buffered request is correctly resolved to the refreshed contact point information of the "new" EAS to which the AC has been handed over.

[0169] EAH-aware session QoS continuity

[0170] In order to enable seamless switching of ACs between different EASs in the system, EAHC or EAHS may support the ability to support EAH-aware session QoS continuity functions. This function requires EAHC or EAHS to ensure that: when EAH switching occurs, the configuration of (one or more) 3GPP network QoS flows established between (one or more) ACs hosted on the UE and (one or more) corresponding EASs hosted on (one or more) edge nodes remain consistent. When EAH switching occurs, EAHC or EAHS may assist in the establishment of (one or more) new QoS flows between (one or more) ACs and (one or more) new EASs to which they are handed over. When EAHC or EAHS assists in the establishment of session QoS flows existing between (one or more) ACs and (one or more) EASs, EAHC or EAHS is able to track the configuration of the session QoS flows. In the case / when EAH is triggered, EAHC or EAHS is able to configure the session QoS flows between (one or more) ACs and (one or more) new EASs so that they are consistent with the existing flows established between (one or more) ACs and (one or more) current EASs that the AC is accessing.

[0171] Fig.17A -C represents an example where AC can share its QoS requirements with EAHC ( Fig.17AStep 1). The 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 EAS#1 that meets 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 EAS#1 (step 3b). The 3GPP network returns a response, which includes a flow identifier, such as 5QI (5GQoS identifier), which is used to identify the session QoS flow (step 3c). The EAHS maintains the session QoS flow information, which includes the flow identifier and the applicable AC and EAS (step 4). The AC starts communicating with EAS#1 and accesses its provided services (step 5). During this communication, the 3GPP network ensures that the QoS requirements of the AC are met.

[0172] At some later point, another EAH is triggered, and EAS#2 is identified as the target EAS for the handover (step 6). The EAHS performs the EAH-aware session QoS continuity function. One method that the EAHS can use to perform the EAH-aware session QoS continuity is to first send a new session QoS establishment request to the 3GPP network to establish a session QoS flow between the AC and EAS#2, the session QoS flow having the same QoS requirements as defined by the AC and maintained by the EAHS ( Fig. 17B EAHS sends another request to end the session QoS flow between AC and EAS#1 (step 8a). The 3GPP network receives and processes the request, and tears down the QoS flow between AC and EAS#1 (step 8b). The 3GPP network returns a response (step 8c). EAHS maintains session QoS flow information, which includes the flow identifier and the applicable AC and EAS (step 4). AC starts communicating with EAS#1 and accesses its provided services (step 5). During this communication, the 3GPP network ensures that the QoS requirements of the AC are met.

[0173] Another method that EAHS can use to perform EAH-aware session QoS continuity is to issue a session QoS handover request ( Fig. 17C9a). In such a request, EAHS may include the QoS flow identifier of the existing session QoS flow between AC and EAS#1 and the identifier of the target EAS for the handover (EAS#2). The 3GPP network receives and processes the request and establishes a session QoS flow between AC and EAS#2, which has the same QoS requirements as the flow between AC and EAS#1 (step 9b). In this way, the QoS flow identifier of the existing session is used to identify the expected QoS properties of the new session with the target EAS. After establishing this session QoS flow, the 3GPP network then tears down the session QoS flow between AC and EAS#1 (step 9c). The 3GPP network then returns a response to EAHS, which includes a flow identifier for identifying the new session QoS flow (step 9d). EAHS maintains the session QoS flow information, which includes the flow identifier and the applicable AC and EAS (step 10). AC begins communicating with EAS#2 and accesses its provided services (step 11). During such communication, the 3GPP network ensures that the QoS requirements of the AC are met.

[0174] EAH Perception Management Process

[0175] In order to achieve seamless switching of AC between different EAS in the system, EAHC or EAHS can be connected to various management functions in the system and assist them in performing different types of management operations. Conversely, the management function can also assist EAHC or EAHS in performing edge application switching.

[0176] Fig.18A and 18B , which represents an example in which an EAHC or EAHS may provide EAH-related context information to management functions in the system, such as but not limited to the types of contexts defined in Table 7 of the Appendix ( Fig.18A Step 1). The management function can decide whether to perform certain management operations / when to perform certain management operations (steps 2 and 3) taking into account such information. For example, EAHC or EAHS can provide EAH-related context about where EAS can be deployed (e.g., deployed on a set of edge nodes so that load balancing or performance adjustment can be performed by managing the EAS status on these nodes), when EAH is needed (e.g., immediately or at a specified time or schedule in the future), where EAH is needed (e.g., within a specified geographic location or area, within an area of ​​a specified network (such as within a specified edge network) or along a specified route), who needs EAH (e.g., which UE, AC, EAS, edge node), and why EAH is needed (e.g., the UE has changed location, the AC does not meet the level of service from the current EAS, the 3GPP network has notified of a problem (such as network congestion)).

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

[0178] Some types of management operations that may benefit from EAHC or EAHS assistance may include, but are not limited to, the following:

[0179] ● Which edge networks and edge nodes in the system are the best candidates for deployment of a certain EAS

[0180] ● Which edge networks and edge nodes in the system are the best candidates for installation of new instances of EAS or activation of already installed EAS

[0181] ● Which edge networks, edge nodes, and existing EASs in the system are the best candidates for access by a particular AC

[0182] Detect if / when there is a service availability problem in the system that either completely prevents the AC from accessing a certain EAS or degrades the level of service to the AC when accessing the EAS

[0183] ● Which existing EAS in the system are the best candidates for being disabled and / or uninstalled from the edge network and edge nodes when there is a shortage of available resources in the edge network or on the edge nodes

[0184] ● Determine the best timing for installing / activating / deactivating / modifying EAS

[0185] ● Determine the optimal schedule for activating and deactivating EAS

[0186] ● Reserve resources on edge nodes to host EAS

[0187] ● Adjust EAS status, such as EAS edge resource utilization

[0188] ● Configuration of access control policies in the system that determine which edge networks, edge nodes, edge servers, and edge application servers the AC is allowed to access.

[0189] Conversely, management functions in the system can assist the EAHC or EAHS by sharing management-related information with the EAHC or EAHS ( Fig.18BSome types of management-related information may be the status and / or availability of edge networks, edge nodes, or EASs in the system. The EAHC or EAHS may determine whether to trigger the EAH in light of such information (step 8). The EAHC or EAHS may then determine to initiate a handoff of the AC to a new EAS to alleviate an overload condition on the EAS that the AC is currently accessing (step 9).

[0190] The management function may also determine that an EAH is needed (step 10) and send a request to the EAHC or EAHS to trigger it to perform an EAH (step 11) to alleviate the problem detected by the management function. The EAHC or EAHS may then initiate a handoff of the AC to a new EAS to alleviate the overload condition on the EAS currently being accessed by the AC (step 12).

[0191] Fig.19A and 19B Figure 1 shows an exemplary EAH-aware edge computing service provider interaction. The edge computing service provider (ECSP) can also interact with the management function to trigger management operations, such as deploying new edge applications to the edge network, installing new EAS instances, or adjusting the current status of deployed or installed EAS. EAHS can assist the management function to interact with the ECSP to optimize the deployment and status of EAS by sharing EAH-related context information.

[0192] The management function may receive information about the deployment status or instance status of an existing EAS from the EAHS, based on which the management function may identify the need to deploy or install a new / additional EAS (e.g., a certain type of EAS is missing in the edge network, an existing EAS of a certain type is overloaded and a new instance is needed). The management function may determine the best action to take, including but not limited to: the type of EAS desired, the edge nodes and edge networks capable of hosting the desired EAS, when a new EAS is needed, whether an EAH is needed / when an EAH is needed, etc. This information may then be sent to the ECSP as a recommendation. After receiving the recommendation, the ECSP may decide whether to agree to the proposed action. If the ECSP agrees to the proposed action, the ECSP may send a request to the management function to trigger the recommended action, such as deploying the desired EAS to more edge nodes or installing more instances of the desired EAS.

[0193] The management function can receive queries about the deployment status and instance status of EAS from ECSP and collect the required information from EAHS. After receiving the response, ECSP can trigger management operations such as deploying new EAS, adjusting the status of deployed / installed EAS or executing EAH.

[0194] Route Assist EAH

[0195] To further optimize edge application switching involving use cases of mobile UEs, the UE's route information can be utilized to assist in managing edge application switching. Route-assisted edge application switching requires the use of route information to coordinate and manage which target EAS the AC is handed over to next. Route information may include a series of waypoints. Waypoints may be defined in terms of geographic coordinates, or represented in terms of other aspects, such as, but not limited to, identifiers of edge networks, edge nodes, and / or edge servers along the route.

[0196] Fig. 20A and 20B An example of a route assistance EAH functionality is shown. Route information may originate from several types of entities in the system, including but not limited to a user or AC that has explicitly defined a predetermined route in advance (step 1). For example, a trip is planned using defined start and end points and intermediate waypoints. If a predetermined route is not defined, the route may 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) coupled with historical context (such as the UE's commuting pattern), a predicted route may be calculated by the EAHS and used to assist in selecting the next EAS(s) to which the AC(s) hosted on the UE is handed over. Predictive analysis techniques may be used to assist in calculating the predicted route. The ability to allow a predetermined route to be specified and the ability to predict a UE's route using context information and predictive analysis are both functionalities that may be supported by EAHC or EAHS.

[0197] Once the route information is available, the desired EAS can be actively deployed to the edge nodes along the route. The EAS along the UE route can be pre-installed and pre-configured based on the UE's route information. Alternatively, the deployed EAS does not have to be installed or activated immediately, or remain active all the time. The timing of installation / activation / deactivation can be determined by the EAHC or EAHS based on the location of the UE (scenario #1 or #2 in Figure 18). The EAHC or EAHS can use the route information to monitor the current position of (one or more) UEs relative to the different waypoints defined by the route, and track the movement of the UE along the route and any unexpected deviations. In order to monitor and track the location of the UE along the route (step 7), the EAHC or EAHS can rely on updates to the current location of the UE. These updates can originate from the UE itself (step 3), from the positioning function in the 3GPP network (step 4), or from other entities in the system (e.g., SCS / AS).

[0198] The EAHC or EAHS may share the UE's expected route information with the 3GPP network to enable the network to configure and optimize its network resources to ensure that the UE's requirements (e.g., QoS) are met as the UE travels along the route (step 5). The EAHC or EAHS may also request the 3GPP network to track the UE's movement along the route on its behalf and send it notifications about the UE's movement along the route (step 6). For example, the notifications include, but are not limited to, when the UE reaches a designated waypoint along the route or when the UE deviates from the designated route.

[0199] Using the location information about the UE's movement along the route, the EAHC or EAHS can compare the UE's movement with the available edge networks, edge nodes, and / or EASs deployed along the same route and near the UE. Based on this comparison and any configured EAH policies, the EAHC or EAHS can decide if it should trigger the EAH / when it should trigger the EAH and which EAS(s) it should select as the target(s) of the EAH (step 8). If the EAHC or EAHS determines that an EAH is needed, it can trigger and assist other entities in the system to perform EAH operations (step 9).

[0200] Fig. 20A and 20B In addition to supporting route-assisted edge application switching for a single UE, EAHC or EAHC may also support route-assisted EAH functionality for a group of UEs traveling together (e.g., V2X formation). Fig. 20A and 20B This functionality is not captured in .

[0201] Except in Fig. 20A and 20BIn addition to the operations captured in , EAHS may also send one or more requests to edge or cloud nodes at specific locations or along specified routes to register AC and / or reserve existing EAS for use by AC so that EAS does not become overloaded. These requests may be sent in advance (e.g., when the trip is configured and the route is determined) before the AC is near the cloud / edge node. Alternatively, these requests may be sent in operation when EAHS detects that the location of the AC has changed and is to some extent near a given edge or cloud node. The request may include various information, such as the security credentials and identifier of the AC, the expected QoS / QoE service requirements (such as the required service availability schedule (e.g., the time window for the planned use of the application or service)), user profile or preference information (e.g., application settings), and / or service usage requirements (e.g., request rate, app request rate, data limit, etc.). These requests may be sent directly to the edge node or cloud hosting the service, or they may be sent to another function in the network that facilitates the registration and / or reservation of services hosted on the edge node or cloud.

[0202] Exemplary Service Tier Scenarios

[0203] The assisted edge application switching concept described herein can be applied to various service layer technologies, such as but not limited to 3GPP SA6, oneM2M and OMA LWM2M.

[0204] 3GPP SA6 EDGEAPP Example

[0205] Fig.21 An example of how the concepts described herein can be applied in the 3GPP SA6 defined architecture for implementing edge applications is shown. See, for example, TS 23.286.

[0206] The defined EAHC functionality may be implemented as a new functionality within an existing edge enabler client functionality. Alternatively, the EAHC may be implemented as a new independent functionality of the UE. In this case, new reference points (e.g., Edge-13 and Edge-14) may be defined to support interaction with the new independent EAHC.

[0207] The defined EAHS function can be implemented as a new function of the edge enabler server or edge data network configuration server function. Alternatively, EAHS can be implemented as a new independent function within the system. This new independent function can 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) can also be defined to support the new independent EAHS and EAS, edge enabler server, edge data network configuration server, UE and / or 3GPP core network interaction.

[0208] Table 8 of the Appendix provides an example of how the reference points of the SA6 EDGEAPP architecture can be aligned with and enhanced with the functionality defined for each of the reference points described herein.

[0209] 3GPP SA6 V2X Example

[0210] Fig. 22 An example of how the concepts described herein can be applied in the 3GPP SA6 V2X architecture is shown. See for example TS 23.286 and 3GPP TR 23.764.

[0211] 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, EAHC may be implemented as a new independent functionality of the UE ( Fig. 22 In this case, new reference points may be defined to support interaction with the new independent EAHC.

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

[0213] Table 9 of the Appendix provides an example of how the reference points of the SA6 V2X architecture can be aligned and enhanced with the functionality defined for each of the reference points described herein.

[0214] oneM2M Example

[0215] Fig.23 An example of how the functionality described herein can be applied in a oneM2M architecture is shown. See, for example, TS 23.286 and 3GPP TR 23.764.

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

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

[0218] LWM2M Example

[0219] Fig.24 represents an example of how the concepts described herein may be applied in the OMA LWM2M architecture. The EAHC defined functions may be implemented as new functions added to an existing LWM2M client hosted on a UE. The EAHS defined functions may be implemented as new functions added to an existing LWM2M server functions.

[0220] Graphical User Interface (GUI)

[0221] Fig.25 An exemplary GUI is shown that can be used by a person operating a cellular device to request configuration of EAH policy settings associated with the cellular device. These policies can be used by the EAHC and / or EAHS server functions described herein.

[0222] Example Environment

[0223] The 3rd Generation Partnership Project (3GPP) develops technical standards for cellular telecommunication 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 cellular technology called New Radio (NR), which is also referred to as "5G". 3GPP NR standard development is expected to include the definition of the next generation radio access technology (new RAT), which is expected to include providing new flexible radio access below 6 GHz and providing new ultra-mobile broadband radio access above 6 GHz. The flexible radio access is expected to include new non-backward compatible radio access in new spectrum below 6 GHz, and it is expected to include different operating modes that can be multiplexed together in the same spectrum to address a wide set of 3GPP NR use cases with different requirements. The ultra-mobile broadband is expected to include cmWave and mmWave spectrum, which will provide 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 radio access leveraging cmWave and mmWave specific design optimizations.

[0224] 3GPP has identified various use cases that NR is expected to support, resulting in various user experience requirements for data rate, latency and mobility. Use cases include the following general categories: enhanced mobile broadband (e.g., broadband access in dense areas, ultra-high broadband access indoors, broadband access in crowds, 50+Mbps everywhere, ultra-low-cost broadband access, mobile broadband in vehicles), critical communications, massive machine-type communications, network operations (e.g., network slicing, routing, migration and interworking, energy saving), and enhanced vehicle-to-everything (eV2X) communications, which may include any of vehicle-to-vehicle communications (V2V), vehicle-to-infrastructure communications (V2I), vehicle-to-network communications (V2N), vehicle-to-pedestrian communications (V2P), and vehicle communications with other entities. Specific services and applications in these categories include, for example, monitoring and sensor networks, device remote control, two-way remote control, personal cloud computing, video streaming, wireless cloud-based office, first responder connectivity, automotive automatic emergency call system (ecall), disaster warning, real-time gaming, multi-person video calls, autonomous driving, augmented reality, tactile Internet, and virtual reality. All of these use cases and others are contemplated here.

[0225] Fig.26A One embodiment of an exemplary communication system 100 is shown in which the methods and apparatus described and claimed herein may be implemented. As shown in the figure, the exemplary 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), a radio access network (RAN) 103 / 104 / 105 / 103b / 104b / 105b, a core network 106 / 107 / 109, a public switched telephone network (PSTN) 108, the Internet 110, other networks 112, and a V2X server (or ProSe function and server) 113, but 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 device or apparatus configured to operate and / or communicate in a wireless environment. Figures 26A-26EAlthough described as a handheld wireless communication device, it should be understood that for various use cases envisioned for 5G wireless communications, each WTRU may include or be implemented in any type of device or apparatus configured to send and / or receive wireless signals, including by way of example only a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular phone, a personal digital assistant (PDA), a smart phone, a laptop computer, a tablet computer, 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 equipment, a drone, a vehicle (such as a car, truck, train or airplane), etc.

[0226] 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 connect 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 wirelessly connect with at least one of the RRHs (remote radio heads) 118a, 118b, TRPs (transmit and receive points) 119a, 119b, and / or RSUs (roadside units) 120a and 120b to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, other networks 112, and / or V2X servers (or ProSe functions and servers) 113. The RRHs 118a, 118b may be any type of device configured to wirelessly connect with at least one WTRU 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 connect with at least one WTRU 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 connect to 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 base transceiver stations (BTS), Node-B, eNode B, Home Node B, Home eNode B, site controllers, access points (APs), wireless routers, and the like. Although each of the base stations 114a, 114b is depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0227] The base station 114a may be part of the RAN 103 / 104 / 105, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), a relay node, etc. The base station 114b may be part of the RAN 103b / 104b / 105b, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), a relay node, etc. The base station 114a may be configured to send and / or receive wireless signals in a specific geographic area, which may be referred to as a cell (not shown). The base station 114b may be configured to send and / or receive wired and / or wireless signals in a specific geographic area, which may be referred to as a cell (not shown). The cell 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 an embodiment, the base station 114a may include three transceivers, for example, one transceiver for each sector of the cell. In an embodiment, the base station 114a may employ multiple-input multiple-output (MIMO) technology and, therefore, may use multiple transceivers for each sector of the cell.

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

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

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

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

[0232] More specifically, as described 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), which may use Wideband CDMA (WCDMA) to establish the air interface 115 / 116 / 117 or 115c / 116c / 117c, respectively. 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).

[0233] In an 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 WTRUs 102c, 102d in the RAN 103b / 104b / 105b may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may use Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A) to establish an air interface 115 / 116 / 117 or 115c / 116c / 117c, respectively. 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 (such as direct link communications, etc.). 3GPP NR technologies include NR V2X technologies and interfaces (such as direct link communications, etc.).

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

[0235] Fig.26AThe base station 114c in may be, for example, a wireless router, a Home Node B, a Home eNode B, or an access point, and may use any suitable RAT to facilitate wireless connectivity in a local area (such as a business location, a home, a vehicle, a campus, etc.). In an 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 an 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 another embodiment, the base station 114c and the WTRU 102e may use a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish a picocell or a femtocell. Fig.26A As shown in FIG, base station 114b may have a direct connection to the Internet 110. Therefore, base station 114c may not need to access the Internet 110 via core network 106 / 107 / 109.

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

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

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

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

[0240] Fig.26B 1 is a block diagram of an exemplary device or apparatus (such as, for example, WTRU 102) configured for wireless communication according to the embodiments described herein. Fig.26BAs shown in FIG. 1 , an exemplary WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touch pad / indicator 128, a non-removable memory 130, a removable memory 132, a power supply 134, a global positioning system (GPS) chipset 136, and other peripherals 138. It will be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment. In addition, embodiments contemplate that the base stations 114a and 114b and / or the nodes that the base stations 114a and 114b may represent (such as, but not limited to, for example, a base 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 Fig.26B Some or all of the elements described in and described herein.

[0241] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, 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 The processor 118 and the transceiver 120 are depicted as separate components, but it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0242] The transmit / receive element 122 may be configured to transmit signals to a base station (e.g., base station 114a) or receive signals from a base station (e.g., base station 114a) via an air interface 115 / 116 / 117. For example, in an embodiment, the transmit / receive element 122 may be an antenna configured to transmit and / or receive RF signals. In an embodiment, for example, the transmit / receive element 122 may be an emitter / detector configured to transmit and / or receive IR, UV or visible light signals. In another embodiment, the transmit / receive element 122 may be configured to transmit and receive 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.

[0243] In addition, although the transmission / reception element 122 is Fig.26B Although depicted as a single element in the WTRU 102, the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in an embodiment, the WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals via the air interface 115 / 116 / 117.

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

[0245] The processor 118 of the WTRU 102 may be coupled to a speaker / microphone 124, a keypad 126, and / or a display / touch pad / indicator 128 (e.g., a liquid crystal display (LCD) display unit or an organic light emitting diode (OLED) display unit), and may receive user input data from the speaker / microphone 124, the keypad 126, and / or the display / touch pad / indicator 128. The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touch pad / 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 an embodiment, the processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

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

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

[0248] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include various sensors such as an accelerometer, a biometric (e.g., fingerprint) sensor, an electronic compass (e-compass), a satellite transceiver, a digital camera (for photos or videos), a universal serial bus (USB) port or other interconnect interface, a vibration device, a television transceiver, a hands-free headset, modules, frequency modulation (FM) radio units, digital music players, media players, video game player modules, internet browsers, etc.

[0249] The WTRU 102 may be implemented in other devices or apparatuses, such as sensors, consumer electronic devices, 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). The WTRU 102 may be connected to other components, modules, or systems of such devices or apparatuses via one or more interconnect interfaces (such as an interconnect interface that may include one of the peripheral devices 138).

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

[0251] like Fig.26C As shown in , Node-B 140a, 140b can communicate with RNC 142a. In addition, Node-B 140c can communicate with RNC 142b. Node-B 140a, 140b, 140c can communicate with each RNC 142a, 142b via Iub interface. RNC 142a, 142b can communicate with each other via Iur interface. Each of RNC 142a, 142b can be configured to control each Node-B 140a, 140b, 140c to which it is connected. In addition, each of RNC 142a, 142b can be configured to perform or support other functions, such as outer loop power control, load control, admission control, packet scheduling, switching control, macro diversity, security functions, data encryption, etc.

[0252] Fig.26C The core network 106 shown in FIG. 1 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 described as part of the core network 106, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the core network operator.

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

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

[0255] As described above, 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.

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

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

[0258] Each of the eNode-Bs 160a, 160b, and 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the uplink and / or downlink, etc. Fig.26D As shown in FIG, eNode-Bs 160a, 160b, 160c may communicate with each other via an X2 interface.

[0259] Fig.26D The core network 107 shown in FIG. 1 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 described as being part of the core network 107, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the core network operator.

[0260] The MME 162 may be connected to each of the eNode-Bs 160a, 160b, and 160c in the RAN 104 via an S1 interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, 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.

[0261] The serving gateway 164 may be connected to each of the eNode-Bs 160a, 160b, and 160c in the RAN 104 via an S1 interface. The serving gateway 164 may generally route and forward user 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-eNode B handovers, triggering paging when downlink data is available for the WTRUs 102a, 102b, 102c, managing and storing the contexts of the WTRUs 102a, 102b, 102c, and the like.

[0262] 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.

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

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

[0265] like Fig.26E As shown in the RAN 105, the RAN 105 may include base stations 180a, 180b, 180c and an ASN gateway 182, but it will be appreciated that the RAN 105 may include any number of base stations and ASN gateways while remaining consistent with the 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 via the air interface 117. In an embodiment, the base stations 180a, 180b, 180c may implement MIMO technology. Thus, the base station 180a, for example, may use multiple antennas to send wireless signals to the WTRU 102a and receive wireless signals from the WTRU 102a. The base stations 180a, 180b, 180c may also provide mobility management functions, such as handover triggering, tunnel establishment, radio resource management, traffic classification, quality of service (QoS) policy enforcement, and the like. The ASN gateway 182 may serve as a traffic aggregation point and may be responsible for paging, caching of subscriber profiles, routing to the core network 109, and the like.

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

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

[0268] like Fig.26E As shown in , 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, which includes protocols for facilitating, for example, data transfer and mobility management capabilities. The core network 109 may include a mobile IP home agent (MIP-HA) 184, an authentication, authorization, accounting (AAA) server 186, and a gateway 188. Although each of the foregoing elements is described as part of the core network 109, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the core network operator.

[0269] 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, and 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, and 102c and IP-enabled devices. The AAA server 186 may be responsible for user authentication and for supporting user services. The gateway 188 may facilitate interworking with other networks. For example, the gateway 188 may provide the WTRUs 102a, 102b, and 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, and 102c and traditional land-line communication devices. In addition, the gateway 188 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired or wireless networks that are owned and / or operated by other service providers.

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

[0271] Here it is described and Fig.26A , 26C The core network entities shown in 26D and 26E are identified by the names given to those entities in certain existing 3GPP specifications, but it should be understood that in the future, those entities and functions may be identified by other names, and that certain entities or functions may be combined in future specifications published by 3GPP (including future 3GPP NR specifications). Therefore, the core network entities shown in 26D and 26E are identified by the names given to those entities in certain existing 3GPP specifications, but it should be understood that in the future, those entities and functions may be identified by other names, and that certain entities or functions may be combined in future specifications published by 3GPP (including future 3GPP NR specifications). Fig.26A , 26B , 26C, 26D and 26E, and it should be understood that the subject matter disclosed and claimed herein may be included or implemented in any similar communication system, whether currently defined or in the future.

[0272] Fig.26F It is achievable Fig.26A , 26C, 26D and 26E are block diagrams of an exemplary computing system 90 of one or more devices of the communication network shown in FIG. 26A (such as certain nodes or functional entities in RAN 103 / 104 / 105, core network 106 / 107 / 109, PSTN 108, Internet 110 or other network 112). The computing system 90 may include a computer or server and may be controlled primarily by computer-readable instructions that may be in the form of software (regardless of where or by what means such software is stored or accessed). Such computer-readable instructions may be executed within a processor 91 to enable the computing system 90 to operate. The processor 91 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors 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 encoding, data processing, power control, input / output processing, and / or any other function that enables the computing system 90 to operate in a communication network. Coprocessor 81 is an optional processor distinct from main processor 91 that may perform additional functions or assist processor 91. Processor 91 and / or coprocessor 81 may receive, generate and process data related to the methods and apparatus disclosed herein.

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

[0274] The memory coupled to the system bus 80 includes a random access memory (RAM) 82 and a read-only memory (ROM) 93. Such memory includes circuits that allow information to be stored and retrieved. ROM 93 generally contains stored data that cannot be easily modified. The data stored in RAM 82 can be read or changed by a processor 91 or other hardware device. Access to RAM 82 and / or ROM 93 can be controlled by a memory controller 92. The memory controller 92 can provide an address conversion function when executing instructions, which converts virtual addresses into physical addresses. The memory controller 92 can also provide a memory protection function that isolates processes within the system and isolates system processes from user processes. Therefore, a program running in the first mode can only access memory mapped by its own process virtual address space; it cannot access memory within the virtual address space of another process unless memory sharing between processes has been set.

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

[0276] 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 using a CRT-based video display, an LCD-based flat panel display, a plasma-based flat panel display, or a touch panel. The display controller 96 includes the electronic components required to generate the video signal sent to the display 86.

[0277] Additionally, computing system 90 may include communications circuitry (such as, for example, network adapter 97) that may be used to connect computing system 90 to an external communications network (such as, for example, a network adapter 97). Fig.26A , 26B , RAN 103 / 104 / 105 of 26C, 26D and 26E, core network 106 / 107 / 109, PSTN 108, Internet 110 or other network 112) to enable computing system 90 to communicate with other nodes or functional entities of those networks. The communication circuit (alone or in conjunction with processor 91) can be used to perform the sending and receiving steps of certain devices, nodes or functional entities described herein.

[0278] Figure 26GOne embodiment of an exemplary communication system 111 in which the methods and apparatus described and claimed herein may be implemented is shown. As shown in the figure, the exemplary communication system 111 may include wireless transmit / receive units (WTRUs) A, B, C, D, E, F, base stations, V2X servers, and RSUs A and B, but 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 the WTRUs A, B, C, D, E may be outside the range of the network (e.g., shown as dashed lines outside the cell coverage boundary in the figure). WTRUs A, B, C form a V2X group, with WTRU A being the group leader and WTRUs B and C being group members. WTRUs A, B, C, D, E, F may communicate via a Uu interface or a direct link (PC5) interface.

[0279] It should be understood that any or all of the devices, systems, methods, and processes described herein may be implemented in the form of computer executable instructions (e.g., program code) stored on a computer-readable storage medium, and when the instructions are executed by a processor (such as, processor 118 or 91), the instructions cause the processor to execute and / or implement the systems, methods, and processes described herein. Specifically, any step, operation, or function described herein may be implemented in the form of such computer executable instructions, which are 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 media, and non-removable media for storing information implemented in any non-transient (e.g., tangible or physical) method or technology, but such computer-readable storage media do not include signals. Computer-readable storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical disk storage device, magnetic cassette, magnetic tape, magnetic disk storage device or other magnetic storage device, or any other tangible or physical medium that can be used to store the desired information and can be accessed by a computing system.

[0280] appendix

[0281] Table 0.1 - Abbreviations

[0282]

[0283]

[0284]

[0285] Table 0.2 - Selected terms

[0286]

[0287]

[0288] Table 1-I EAHC-AC operate

[0289]

[0290]

[0291]

[0292]

[0293]

[0294] Table 2-I EAHS-EAS operate

[0295]

[0296]

[0297]

[0298] Table 3 - IEAHS-EAHC Operations

[0299]

[0300]

[0301]

[0302]

[0303]

[0304] Table 4 - IEAHS-3GPP operations

[0305]

[0306]

[0307]

[0308]

[0309] Table 5 - IEAHS-MF Operations

[0310]

[0311]

[0312] Table 6-EAH policy rules

[0313]

[0314]

[0315] Table 7 EAH related context information

[0316]

[0317] Table 8-3GPP SA6 EDGEAPP reference point applicability

[0318] Reference Points SA6 EDGEAPP reference point <![CDATA[I EAHC-AC ]]> EDGE-5, EDGE-13 (new) <![CDATA[I EAHS-EAHC ]]> EDGE-1, EDGE-4, EDGE-8 (new) <![CDATA[I EAHS-3GPP ]]> EDGE-2, EDGE-11(new), EDGE-12(new) <![CDATA[I EAHS-MF ]]> EDGE-6 <![CDATA[I EAHS-EAS ]]> EDGE-3, EDGE-9 (new)

[0319] Table 9 - 3GPP SA6 V2X reference point applicability

[0320]

[0321] Table 10-oneM2M reference point applicability

[0322] Reference Points oneM2M Reference Point <![CDATA[I EAHC-AC ]]> Mca <![CDATA[I EAHS-EAHC ]]> Mcc <![CDATA[I EAHS-3GPP ]]> Mcn <![CDATA[I EAHS-MF ]]> Mcn <![CDATA[I EAHS-EAS ]]> Mca

Claims

1. A user equipment UE hosting an edge application switching 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 EAHC to: receiving a first request from an application client AC including AC context information, wherein the AC context information includes, for a service from a first edge application server EAS, an expected location or an expected route of the UE that will require the service, wherein the AC context information also includes a schedule of times when the service will be required; Based on the AC context information, sending a second request including the AC context information from the EAHC to the edge application switching server EAHS to assist the AC in performing seamless edge application switching between different EASs by using the EAHC and the EAHS; and An acknowledgement of the second request is received from the EAHS.

2. The UE according to claim 1, wherein: The AC context information also includes an identifier of the AC.

3. The UE according to claim 1, wherein: The AC context information also includes a required request rate.

4. The UE according to claim 1, wherein: The AC context information also includes the current location of the AC.

5. The UE according to claim 1, wherein: The AC context information further includes an identifier of a service of the first edge application server EAS.

6. The UE according to claim 1, wherein: The AC context information also includes service continuity requirements.

7. The UE according to claim 1, wherein: The service continuity requirement includes a service continuity mode.

8. A network device for hosting an edge application switching server EAHS, the device comprising a processor, a memory and a communication circuit, the device being connected to a first network via the communication circuit, the device further comprising computer executable instructions stored in the memory, the instructions, when executed by the processor, causing the EAHS to: receiving, from a first edge application switching client EAHC hosted on a first user equipment UE, a request including AC context information related to an application client AC, to perform seamless edge application switching between different edge application servers EAS by using the first edge application switching client EAHC and EAHS to assist the AC, wherein the AC context information includes an expected location or an expected route at which a service from the first EAS needs to be accessible to the AC, and wherein the AC context information also includes a schedule, the schedule including a time when the AC needs to access the service; Sending a response indicating receipt of the AC context information to the first edge application switching client EAHC; Based on the schedule and the desired location or the expected route, a handoff of the AC from the first EAS to a second EAS is triggered.

9. The network device of claim 8, wherein the instructions further cause the EAHS to: Support interfaces to 3GPP entities in the 3GPP system; receiving a current location of the first user equipment UE from the 3GPP entity; By comparing the current location of the first user equipment UE with the expected location or expected route, a timing for triggering a handover of the AC from the first EAS to the second EAS is determined.

10. The network device according to claim 8, wherein: The instruction further enables the EAHS to trigger the first edge application switching client EAHC to perform an edge application switching operation on behalf of the AC, so as to help the AC perform edge application switching.

11. The network device according to claim 8, wherein: The instructions also cause the EAHS to receive a subscription request from a second EAHC hosted on a second UE related to receiving notifications from the EAHS. 12 . The network device of claim 11 , wherein the instructions further cause the EAHS to send a notification to a second EAHC in response to the subscription request.

13. The network device of claim 8, wherein the instructions further cause the EAHS to support an interface to a management function and trigger the management function via the interface to instantiate the first EAS.

14. The network device of claim 8, wherein the instructions further cause the EAHS to: sending a request to a 3GPP network to request the 3GPP network to track the movement of the first user equipment UE along the expected route; and A notification of the movement of the first user equipment UE is received from the 3GPP network, the notification comprising an indication that the first user equipment UE has arrived near a waypoint along the expected route or an indication that the first user equipment UE has deviated from the expected route.

Images