Method, device and system for analyzing enhanced edge enabled layer service continuity

Abstract

Methods, devices, and systems for analyzing enhanced edge-enabled layer service continuity are described herein. In one aspect, a method can include receiving, by an analysis service, an analysis request to perform application context relocation (ACR) detection from an edge enabled layer (EEL) entity; collecting, by the analysis service, analysis information relating to the detection of the ACR; generating, by the analysis service, an ACR detection notification according to the collected analysis information; and sending, by the analytics service, the ACR detection notification to the one or more reporting targets.

Description

[0001] Cross - reference to related applications

[0002] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 382,182, filed on November 3, 2022, which is hereby incorporated by reference in its entirety. Background Art

[0003] Figure 1 Depicts the Edge Application Enabler Layer (EEL) architecture defined by the 3GPP SA6 working group. The EEL refers to the overall functionality provided by entities such as the Edge Enabler Client (EEC), Edge Enabler Server (EES), and Edge Configuration Server (ECS), which is necessary for enabling a UE Application Client (AC) to interact with an Edge Application Server (EAS) through the 3GPP network. For edge computing, the UE AC must be able to locate and connect to the most suitable EAS available within the Edge Data Network (EDN) where the UE is located. This depends on the requirements of the AC and the availability of EASs in the edge data network. The EEL supports a set of services and exposes these services via APIs defined for each EEL (e.g., EDGE - 1 to EDGE - 9).

[0004] Some of these supported services include: services for discovering the ECS and provisioning edge computing services based on UE location and service requirements; services for registering the EEC to the EES and registering the EAS to the EES; services for providing service continuity between the AC and the EAS (e.g., when the UE moves from one EDN to another); and exposing 5GC services for use by the EAS.

[0005] The EEL can provide features to support service continuity for the services used by the AC in the UE to minimize service interruption while replacing the S - EAS with the T - EAS. For service continuity, the following scenarios are supported: UE mobility, including predictive or anticipatory UE mobility; overload situations in the S - EAS or EDN; and maintenance aspects such as the normal shutdown of the EAS.

[0006] To support the requirements of ACR, the following entity roles are identified: a detection entity that detects or predicts the requirements of ACR; a decision entity that decides that ACR is needed; and an execution entity that executes ACR.

[0007] When information about the planned, predicted, or anticipated movement of the UE outside the service area of the serving EAS is available at the EEL, the EEL can also provide features of service continuity planning to support seamless service continuity.

[0008] Depending on whether the EEC participates in the decision-making phase, whether the T-EAS discovery is performed by the EEC or the S-EES, how the ACR request is sent, and how the application context is transmitted, the following scenarios have been identified: the EEC initiates the ACR using the regular EAS discovery; the EEC performs the ACR via the S-EES; the S-EAS decides the ACR scenario; the S-EES performs the ACR and the EEC performs the ACR via the T-EES.

[0009] The current EEL depends on the information provided by the EEC / AC to execute the service continuity plan. The EEC / AC can provide information about the planned or predicted UE mobility behavior (whether the UE moves to the expected / predicted location) and the detection of changes in the expected / predicted UE mobility, while the EES can monitor whether the UE has moved to the predicted / expected location. The plan only applies to the mobility-based service continuity scenario, and the non-mobility-based service continuity plan (e.g., the predicted workload on the EAS) has not been defined.

[0010] The EEL can utilize an analysis service (e.g., ADAES) to trigger EEL operations. For example, the EES can subscribe to edge load analysis and receive predictions of the EAS / EDN load. Based on the received analysis information, the EES or the EAS can generate trigger events and corresponding actions, such as ACR detection. Since the analysis service can integrate various analysis information of the network and generate more insights based on the analysis data, it will be more beneficial for the EEL to let the analysis service act as the ACR detection entity and provide advanced analysis support for the EEL service continuity. However, this feature is not yet supported in the current EEL.

[0011] Dynamic EAS instantiation is a feature provided by the EEL, which can be triggered by the EES due to service discovery requests, UE mobility, receiving an EEC registration request containing an AC profile, etc. In the current EEL, when the EES cannot discover and select an EAS that matches the UE location and the requested application characteristics due to the unavailability or non-instantiation of the EAS, dynamic EAS instantiation will be triggered. However, triggering the EAS instantiation after receiving the request and indicating the need for the EAS will cause a delay or even interruption of the service to the AC. The current EEL lacks the ability to support proactive EAS instantiation, which can make full use of the predictive information provided by the analysis service to proactively perform EAS instantiation.

[0012] In some use cases (such as real-time communication or multi-user sessions), multiple ACs may need to use the services from a single shared EAS to meet the latency requirements and avoid the need for synchronization between EASs. In the current EEL, the selection of the shared EAS is based on the information of the ACs that will receive services from the shared EAS and the EDN. However, the EEL lacks the ability to provide predictive selection of the shared EAS based on analysis information. SUMMARY OF THE INVENTION

[0013] The disclosure provided herein presents an enhancement to the service continuity process in the edge enabler layer by leveraging analytical services (such as ADAES) available at the service enabling layer. The proposed analytical enhanced service continuity functionality may include an analytical service (ADAES server / client) that can receive an analytical request from an EEL entity to perform ACR detection and provide recommendations for T-EES and / or T-EAS. In some cases, the request specifies a trigger event for ACR detection. In some cases, the request specifies when and how the analytical service should send a notification for ACR detection, to which entity the analytical service should report the ACR detection, and what analytical information the analytical service should provide in the notification. The analytical service can collect and generate analytical information related to the detection of ACR. The analytical service can receive a candidate list from which it can select / evaluate the proposed T-EES and / or T-EAS for ACR. In some cases, the candidate list may be received in the analytical request. In some cases, the candidate list may be retrieved from a list of entities specified in the analytical request. In some cases, the candidate list may be received before or after sending the ACR detection notification.

[0014] The analytical service can send an ACR detection notification to a reporting target. In some cases, the notification includes a predicted event time. In some cases, the notification may include the proposed T-EES and / or T-EAS. In some cases, the notification may indicate T-EAS as the common EAS for multiple ACs. The analytical service can send an active EAS instantiation notification to the predicted T-EES to trigger the instantiation of the predicted T-EAS. In some cases, the EAS instantiation notification and the corresponding ACR detection notification are jointly generated.

[0015] The proposed analytical enhanced service continuity functionality may include an EEL entity (EEC / EES / EAS) that can send an analytical request to the analytical service. In some cases, the request may specify a trigger event for ACR detection. In some cases, the request specifies when and how the analytical service should send a notification for ACR detection, to which entity the analytical service should report the ACR detection, and what analytical information the analytical service should provide in the notification.

[0016] The EEL entity can provide a candidate list to the analysis service, from which the analysis service can select / evaluate the proposed T-EES and / or T-EAS of the ACR. In some cases, the candidate list can be included in the analysis request. In some cases, the candidate list can be provided by a list of entities other than the entity determined by the ACR, where the list of entities is specified in the analysis request. In some cases, the candidate list can be provided before or after sending the ACR detection notification.

[0017] The EEL entity can receive the ACR detection notification from the analysis service. The EEL entity can send a notification to the analysis service after making the ACR decision.

[0018] The present invention content is provided to introduce some concepts in a simplified form, which will be further described in the following detailed implementation. The present invention content is neither intended to identify the key features or essential features of the claimed subject matter, nor intended to be used to limit the scope of the claimed subject matter. In addition, the claimed subject matter is not limited to features that solve any or all of the disadvantages pointed out in any part of this disclosure. Brief Description of the Drawings

[0019] Figure 1 The EEL architecture is depicted.

[0020] Figure 2 An overview of the analysis-enhanced ACR is depicted.

[0021] Figure 3 The ACR analysis subscription request and response are depicted.

[0022] Figure 4 The ACR decided by the EEC with analysis support is depicted.

[0023] Figure 5 The ACR decided by the S-EAS or S-EES with analysis support is depicted.

[0024] Figure 6 The ACR update / modification with analysis support is depicted.

[0025] Figure 7 The analysis-assisted active EAS instantiation is depicted.

[0026] Figure 8 The analysis-assisted shared EAS selection is depicted.

[0027] Figure 9 An example graphical user interface (GUI) for analysis service configuration is depicted.

[0028] Figure 10A An example communication system is depicted, where the methods and apparatuses described and claimed herein can be one aspect thereof;

[0029] Figure 10B A block diagram depicting an example apparatus or device configured for wireless communication;

[0030] Figure 10C A system diagram depicting an example radio access network (RAN) and core network;

[0031] Figure 10D A system diagram depicting another example RAN and core network;

[0032] Figure 10E A system diagram depicting another example RAN and core network;

[0033] Figure 10F A block diagram depicting an example computing system; and

[0034] Figure 10G A block diagram depicting another example communication system. Detailed Description

[0035] When different EASs become more suitable to serve the AC in the UE due to UE mobility, overload of EAS or EDN, maintenance of EAS or EES, or other dynamics in the edge network, the edge enabling layer provides service continuity support for the UE. To support service continuity, the application context associated with the AC and the EEC context associated with the EEC will be transferred from the S-EAS to the T-EAS. In ACR processing, the need for ACR will be detected or predicted by a detection entity, and a decision entity will make a decision that ACR is needed, followed by the execution of ACR.

[0036] Analytics services (e.g., ADAES, NWDAF) can be fully utilized by the edge enabling layer to enhance ACR processing by providing assistance at different stages of ACR. Figure 2 A high-level overview of analytics-enhanced ACR is shown.

[0037] Step 1: The EEL entity sends a request to the analytics service to assist in completing ACR processing. For example, the EEC / AC, S-EAS, or S-EES can send an ACR analytics subscription request to the analytics service to obtain predictive information about the edge network and / or events that can trigger ACR. The entity sending the request can also request a recommendation or evaluation of the T-EES or T-EAS, which the analytics service can generate based on the predictive information. Additionally, the entity sending the request can provide a list of candidate EES / EASs, and the analytics service can make a recommendation or generate a ranking of the candidates based on the list of candidate EES / EASs.

[0038] Analysis subscription requests can be sent to analytics services in different layers for different types of ACR triggers. For example, two separate requests can be generated, one for mobility-based ACR and another for non-mobility-based ACR. Alternatively, a single analytics subscription request can be sent to an analytics service which will generate / redirect the request(s) to other analytics services (e.g., NWDAF). The requester can also incorporate in the request data that the analytics service can utilize, such as information about the requester, application layer context information, etc.

[0039] Step 2: Based on the analytics subscription request, the analytics service can collect data from the edge network(s) and generate analytics results, such as predictions of ACR trigger events. The generated analytics results can be sent to the ACR detection and / or decision entity. The analytics service can provide analytics information to the detection entity to detect the need for ACR. Alternatively, the analytics service can itself detect / predict the need for ACR and send the detection result directly to the decision entity. The analytics service can detect it before the trigger event occurs based on data or prediction information that the analytics service collects or receives from network functions and services, which enables proactive ACR operations and service continuity planning. Recommendations or evaluations of T-EES or T-EAS can be sent along with the analytics / detection results.

[0040] Step 3: After receiving the analytics for ACR detection, the ACR decision entity determines that ACR is needed and can indicate the execution of ACR. The decision entity can be the EEC / AC (e.g., in scenarios where the EEC initiates using conventional EAS discovery, the EEC performs ACR via S-EES, the EEC performs ACR via T-EES), S-EAS (e.g., in scenarios where S-EAS decides on ACR), or S-EES (e.g., in scenarios where S-EES performs ACR). In particular, the edge enabling layer can decide to execute service continuity plans and proactive actions based on the predictive information provided by the analytics service.

[0041] Step 4: The decision entity can identify T-EES and T-EAS with the assistance of the analytics service. If the analytics service has provided such information in Step 2, then the recommended EES / EAS can be selected as T-EES / T-EAS. Otherwise, the decision entity can perform a service provisioning and discovery process to identify T-EES and T-EAS, during which the analytics service can provide support information and / or apply analytics results to assist in the selection.

[0042] Step 5: After identifying T-EES and T-EAS, the ACR process can be executed, such as relocating the EEC context from S-EES to T-EES, transferring application context between S-EAS and T-EAS, etc.

[0043] Step 6: After providing trigger event detection, the analytics service can continue to provide updated information to the decision entity or other entities participating in the ACR and assist in ACR update / modification processing (as requested in the original request in Step 1 or after receiving an updated request). The analytics service can notify the decision entity of the expected / predicted changes in information, based on which an ACR update decision can be made. If the T-EES and / or T-EAS also need to change due to the update, then the analytics service can provide updated recommendations / evaluations to assist in the re-selection of T-EES / T-EAS.

[0044] Step 7: The edge enabling layer performs post-ACR actions to complete and clean up the ACR process.

[0045] ACR Analysis Subscription Request

[0046] An ACR analytics subscription request is an analytics service request specific to the type of analytics for service continuity (ACR) provided to the edge enabling layer.

[0047] This request can be initiated by an EEL entity or an application layer entity for service continuity (ACR) support (such as EEC, EES, ECS, or EAS). For example, the EEC can initiate an ACR analytics subscription request after registering with a new EES or when establishing a new session between an associated AC and EAS (e.g., the AC connects to a new EAS). The EES (S-EES) can initiate an ACR analytics subscription request when receiving a registration request for service continuity support from the EEC or EAS. The EAS can initiate an ACR analytics subscription request after registering with the EES or connecting to a new AC. The ECS can initiate an ACR analytics subscription request so that the analytics service can actively monitor the status of the EDN and collect analytics data.

[0048] The requester can request the analytics service to provide predictive information (e.g., predictive workload schedules and busiest times for EAS), and the requester can perform ACR detection on its own based on the predictive information. Alternatively, the requester can offload ACR detection to the analytics service by specifying a trigger event to be detected (e.g., an EAS KPI drops below a defined threshold), such that the analytics service performs proactive detection based on the generated analysis results and informs the decision entity. The analysis results will be sent to the detection entity and / or the decision entity to initiate ACR processing. For example, the EEC can request the analytics service to provide a prediction of the workload of the S-EES currently serving the EEC, and also provide the workload of the EESs that can serve the EEC nearby. The EEC can also request the analytics service to detect potential overload of the S-EES and notify the EEC when it is predicted that the S-EES will be overloaded in the future. Then, based on the received information / notification, the EEC can make a decision to initiate or plan an ACR. The requester can specify more than one trigger event for the analytics service to detect.

[0049] In addition to detecting events, the requester can also request the analytics service to provide recommendations for T-EES / T-EAS, or evaluate the suitability of one or more EESs / EASs as T-EES / T-EAS based on the predicted information and analysis results. The requester can provide a list of candidates to the analytics service, and the analytics service can select a recommended entity from it or provide a ranking. For example, the requesting EEC can include a list of EESs (which can be the list of EESs in the service offer response received by the EEC) as candidate T-EESs in the analysis request and specify the predicted workload as the ranking criterion. Then, the analytics service can generate predictions and respond to the EEC with a ranked list of these EESs based on their predicted workloads. The list of candidates can also be provided to the analytics service by other relevant entities or retrieved by the analytics service. For example, the EEC on a UE with mobility can request the analytics service but may not have information about the EESs serving the target location. In this case, the analytics service can query the ECS to obtain a list of EESs serving the target location as the candidate list (the target location can also be predicted by the analytics service).

[0050] The requester can specify a reporting target other than itself to receive analysis notifications and results. In this case, the requester can notify the reporting target before or after sending the ACR analysis subscription request. For example, the S-EES can initiate an ACR analysis subscription request on behalf of the EEC that is requesting service continuity support. Then, the EEC will be able to receive ACR-related information (such as ACR detection notifications and recommended T-EESs) and determine whether / how to perform the ACR. Similarly, the EEC can initiate an ACR analysis subscription request on behalf of the AC, or the EES can initiate an ACR analysis subscription request on behalf of the EAS.

[0051] The requester can instruct the analysis service to send notifications to the predicted / recommended T-EESs and / or T-EASs. For example, the requester can ask the analysis service to select a T-EES based on the analysis information. When a trigger event is detected, the analysis service can select the recommended T-EES and notify both the requester and the selected T-EES. Then, the T-EES can perform proactive actions to prepare for ACR processing, such as reserving resources, dynamic EAS instantiation, etc.

[0052] The process for initiating an ACR analysis subscription request is shown in Figure 3 below.

[0053] Step 1: The requester sends an ACR analysis subscription request to the analysis service to obtain analysis assistance for the ACR process. This request can include the information shown in Table 1.

[0054] Table 1. ACR analysis subscription request

[0055]

[0056]

[0057]

[0058] The requester can also incorporate data that the analysis service can utilize in the request, such as information about the entity that issued the request (e.g., the EEC and the corresponding AC), application layer context information, etc.

[0059] Step 2: The analysis service processes the request and sends a response back to the requester. The analysis service can create an analysis subscription for this request.

[0060] Step 3: If no candidate list is specified in the request or additional information is needed, the analytics service can send requests to relevant entities (as specified in the relevant entity list) to obtain candidate information. The requests can include the identifier of the ACR analytics subscription or other identifiers (e.g., the identifier of the ACR analytics subscription requester, such as identifiers of EEC, EES, EAS) and the authorization provided by the ACR analytics requester (e.g., the identifier of the requester or an authorization token). For example, the analytics service can send a request to the ECS to retrieve a list of EESs that can be used as T-EESs for this ACR using the analytics subscription identifier and the EEC identifier.

[0061] Note that this step can be executed after generating the analysis results (Step 5). For example, the analytics service can determine the proposed T-EES based on the analysis results and send a request to the identified T-EES to retrieve / discovery information on EASs that can be used as T-EASs for this ACR.

[0062] Step 4: The information of the candidate entities is sent to the analytics service.

[0063] Step 5: The analytics service starts collecting data and generating analysis results to detect ACR trigger events and / or meet other requirements indicated in the analysis request. For example, if the ACR detection event is defined as the predicted workload of a certain EES exceeding a threshold, then the analytics service will continuously generate / update the prediction of the workload of the EES and compare the predicted value with the threshold. The analytics service can also generate the workloads of nearby EESs for comparison and to assist in the prediction or analysis output. Note that the analytics service can selectively perform the comparison when necessary, e.g., when the workload of the current EES is close to or exceeds the threshold value. The analytics service can also collect application-specific context (e.g., the user's schedule defined in the application, calendar events of meetings) to generate predictions.

[0064] Analytics-assisted ACR

[0065] The analytics service can assist the ACR process in detecting trigger events, selecting T-EESs and / or T-EASs, and updating or modifying the ACR.

[0066] In the ACR scenario of analytics-assisted EEC / AC decision, the ACR detection notification is sent to the EEC so that the EEC can make an ACR decision. In addition, the EEC can initiate the discovery of T-EESs and T-EASs. The ACR of EEC / AC decision applies to the following scenarios: initiated by the EEC using conventional EAS discovery; the EEC executes ACR via S-EES; and the EEC executes ACR via T-EES.

[0067] In the ACR for the analysis-assisted EEC / AC decision, the EEC will interact with the analysis service (either directly or indirectly via the S-EES) to obtain analysis support, such as Figure 4 as shown

[0068] Step 1: The EEC executes an ACR analysis subscription request, as Figure 3 shown, to obtain assistance from the analysis service in detecting ACR events. The analysis service detects that the detection events defined in the ACR analysis subscription request are expected to occur at some future time based on the generated analysis information. For example, when the analysis service generates a workload prediction exceeding a threshold, an ACR event is detected.

[0069] Step 2: According to the requirements defined in the notification settings in the ACR analysis subscription request, the analysis service sends an ACR detection notification to the EEC. The notification may include the information specified in Table 2. The notification may include the recommended T-EES and / or T-EAS for the ACR. Steps 1 and 2 can be used as the ACR detection phase in the service continuity process.

[0070] Table 2. ACR Detection Notification

[0071]

[0072] The ACR detection notification can be sent in multiple messages at different times. In this case, the analysis service can use the partial notification indicator in the notification message to indicate that further information will be provided in subsequent notification messages. For example, the analysis service can send a first notification when generating the analysis result indicating the detection event, where the notification may not include the event time or the recommended T-EES. A subsequent notification can be sent after collecting or generating sufficient analysis information to derive the event time and the T-EES recommendation.

[0073] Step 3: The EEC or the corresponding AC makes a decision to execute or plan the ACR based on the received notification.

[0074] Step 4: The EEC sends a notification to the analysis service indicating that an ACR decision has been made. The notification may include the identifiers of the T-EES and T-EAS selected by the EEC (if applicable). This information can be used by the analysis service to update the analysis information of the edge network (e.g., update the predicted workload of the S-EES / T-EES and S-EAS / T-EAS). In this notification, the EEC can indicate whether the analysis service should continue to provide updated analysis results for the ACR analysis subscription.

[0075] Step 5-1: If the ACR analysis subscription request asks for a recommended T-EES, but the analysis service has not provided the recommended T-EES in the (one or more) ACR detection notifications (e.g., due to lack of information in the candidate list and / or related entity list, or the analysis service is unable to retrieve the information), then the EEC performs service provisioning for the desired (one or more) T-EES by querying the ECS. In the service provisioning request, the EEC can specify that the request is associated with the analysis-enhanced ACR by including the analysis subscription identifier and / or the identifier of the analysis service in the provisioning request.

[0076] Step 5-2: After receiving a service provisioning request indicating support for analysis, the ECS first generates a list of EESs according to the requirements in the provisioning request (e.g., the AC profile), just as in a normal provisioning response. Then, the list of EESs is sent to the analysis service for filtering according to the analysis information.

[0077] Step 5-3: After receiving the list of EESs from the ECS, the analysis service identifies the corresponding ACR analysis subscription and updates the candidate T-EES list with the received list of EESs. Then, the analysis service will generate a recommendation / recommendation of T-EES according to the requirements in the ACR analysis subscription request. For example, if the request is to select the EES with the lowest predicted workload at the event time, then the analysis service can compare the predicted workloads of the EESs in the list and make a selection. If the request is to rank the EESs in the candidate list according to the reliability of the EESs, then the analysis service can evaluate the reliability of each EES in the candidate list (e.g., based on server downtime statistics) and generate an ordered list. The recommended (one or more) EESs or the ranked list of T-EESs will be sent back to the ECS or directly to the EEC.

[0078] Step 5-4: The ECS generates a service provisioning response with the list of EESs that have been analyzed and processed in Step 5-3 and sends the response to the EEC.

[0079] Step 6-1: If the ACR analysis subscription request asks for a recommended T-EAS, but the analysis service has not provided the information in the ACR detection notification (e.g., due to lack of information in the candidate list and / or related entity list, or the analysis service is unable to retrieve the information), then the EEC performs EAS discovery for the desired T-EAS by querying the T-EES identified in Step 2 or 5. In the discovery request, the EEC can specify that the request is associated with the analysis-enhanced ACR by including the analysis subscription identifier and / or the identifier of the analysis service in the discovery request.

[0080] Step 6-2: After receiving a T-EAS discovery request indicating support for analysis, T-EES first generates a list of EASs according to the filtering criteria in the discovery request, just as in a normal discovery response. Then, the list of EASs is sent to the analysis service for filtering according to the analysis information.

[0081] Step 6-3: After receiving the list of EASs from T-EES, the analysis service identifies the corresponding ACR analysis subscription and updates the candidate T-EAS list with the received list of EASs. Then, the analysis service will generate suggestions / recommendations for T-EASs according to the requirements in the ACR analysis subscription request. The suggested EAS(s) or the ranked list of T-EASs will be sent back to T-EES or directly to the EEC.

[0082] Step 6-4: T-EES uses the list of EASs that have been analyzed and processed obtained in Step 6-3 to generate a discovery response and sends the response to the EEC.

[0083] The analysis service can assist in making a joint selection of T-EES and T-EAS. In this case, the EEC can receive multiple suggested T-EESs and execute Step 6-1 with each suggested T-EES. Then, each suggested T-EES can execute Step 6-2 and provide the corresponding list of EASs to the analysis service. The analysis service can integrate the lists of EASs from multiple EECs associated with the same ACR analysis subscription and update the candidate list with T-EESs and T-EASs. Then, the analysis service will jointly generate suggestions / recommendations for T-EESs and T-EASs according to the requirements in the ACR analysis subscription request. The suggested T-EES and T-EAS pairs will be sent back to the corresponding T-EES(s) or directly to the EEC.

[0084] Step 7: The remaining part of the ACR process will be executed with the identified T-EESs and T-EASs. When generating an ACR request, the EEC can include information obtained from the analysis service, such as the predicted event time. After the entire ACR process is completed, the EEC can send a notification to the analysis service to update the ACR analysis subscription request or terminate the analysis subscription.

[0085] In the scenario of ACR with analysis-assisted S-EAS / S-EES decision, an ACR detection notification is sent to S-EAS / S-EES to make an ACR decision. In addition, S-EAS / S-EES can initiate the discovery of T-EES and T-EAS. The ACR decided by S-EAS / S-EES applies to the following scenarios: the S-EAS decides the ACR scenario; and the S-EES executes the ACR.

[0086] In the ACR for analytics-assisted S-EAS / S-EES decisions, S-EAS / S-EES will interact with the analytics service to obtain analytics support, such as Figure 5 as shown in

[0087] Step 1: Identical to Step 1 of Figure 4

[0088] Step 2: Similar to Step 2 in Figure 4 the analytics service sends an ACR detection notification to the decision entity (S-EAS or S-EES). This notification may include the information specified in Table 2. This notification may include the proposed T-EES and / or T-EAS for the ACR. Steps 1 and 2 can be used as the ACR detection phase in the service continuity process.

[0089] Step 3: S-EAS or S-EES makes a decision to execute or schedule the ACR based on the received notification.

[0090] Step 4: The decision entity (S-EAS or S-EES) sends a notification to the analytics service indicating that an ACR decision has been made. This information can be used by the analytics service to update the analytics information of the edge network (e.g., update the predicted workloads of S-EES / T-EES and S-EAS / T-EAS). In this notification, the decision entity can indicate whether the analytics service should continue to provide updated analytics results for the ACR analysis subscription.

[0091] Step 5-1: If the proposed T-EES is requested in the ACR analysis subscription request, but the analytics service has not provided the proposed T-EES in the (one or more) ACR detection notifications, then S-EAS / S-EES sends a request to retrieve T-EES information from the ECS. In the EES retrieval request, S-EAS / S-EES can specify that the request is associated with the analytics-enhanced ACR by including the analytics subscription identifier and / or the identifier of the analytics service in the EES retrieval request.

[0092] Step 5-2: Identical to Step 5-2 of Figure 4

[0093] Step 5-3: After receiving the list of EES from the ECS, the analytics service identifies the corresponding ACR analysis subscription and updates the candidate T-EES list with the received list of EES. Then, the analytics service will generate a recommendation / suggestion for the T-EES based on the requirements in the ACR analysis subscription request. The proposed (one or more) EES or the ranked list of T-EES will be sent back to the ECS or directly to S-EAS / S-EES.

[0094] ​​Step 5-4: The ECS generates an EES retrieval response using the analyzed and processed EES list obtained in Step 5-3 and sends the response to the S-EES. If a T-EES retrieval request is received from the S-EAS, then the S-EES responds to the S-EAS with the discovered T-EES information.

[0095] Step 6-1: If the ACR analysis subscription request requests a proposed T-EAS, but the analysis service has not provided the proposed T-EAS in the ACR detection notification, then the S-EAS / S-EES performs EAS discovery by querying the T-EES identified in the previous step to obtain the desired T-EAS. In the discovery request, the S-EAS / S-EES can specify that the request is associated with the analysis-enhanced ACR by including the analysis subscription identifier and / or the identifier of the analysis service in the discovery request.

[0096] Step 6-2: Same as Figure 4 Step 6-2 thereof.

[0097] Step 6-3: After receiving the list of EASs from the T-EES, the analysis service identifies the corresponding ACR analysis subscription and updates the candidate T-EAS list with the received list of EASs. Then, the analysis service will generate a proposal / recommendation for the T-EAS according to the requirements in the ACR analysis subscription request. The proposed (one or more) EASs or the ranked list of T-EASs will be sent back to the T-EES or directly to the S-EAS / S-EES.

[0098] Step 6-4: The T-EES generates a discovery response using the analyzed and processed EAS list obtained in Step 6-3 and sends the response to the S-EES. If a discovery request is received from the S-EAS, then the S-EES responds to the S-EAS with the discovered T-EAS information.

[0099] The analysis service can assist in the joint selection of T-EES and T-EAS. In this case, the S-EAS / S-EES can receive multiple proposed T-EESs and perform Step 6-1 with each proposed T-EES. Then, each proposed T-EES can perform Step 6-2 and provide the corresponding list of EASs to the analysis service. The analysis service can integrate the lists of EASs from multiple EESs associated with the same ACR analysis subscription and update the candidate list with T-EESs and T-EASs. Then, the analysis service will jointly generate a proposal / recommendation for the T-EES and T-EAS according to the requirements in the ACR analysis subscription request. The proposed (one or more) pairs of T-EES and T-EAS will be sent back to the corresponding (one or more) T-EESs or directly to the S-EAS / S-EES.

[0100] Step 7: The remainder of the ACR process will be executed with the identified T-EES and T-EAS. After the entire ACR processing is completed, S-EAS / S-EES may send a notification to update the ACR analysis subscription request or terminate the analysis subscription to the analysis service.

[0101] After the initial ACR detection notification containing prediction information is sent to the decision entity, the analysis service may continue to collect data of the analysis target and generate updated analysis results (as required in the ACR analysis subscription request via the continuous analysis indicator), which may trigger an ACR condition update / modification. For example, the proposed T-EES or the predicted event time may change as the analysis results are updated. In this case, the analysis service may send another notification to the corresponding EEC, EES, or EAS to trigger the ACR update or modification process, as Figure 6 shown.

[0102] Step 1: The analysis service detects changes in expected detection events, such as changes in the predicted event time, changes in the recommended T-EES / T-EAS, etc.

[0103] Step 2: The analysis service sends an ACR update detection notification to the decision entity (EEC, S-EAS, or S-EES) according to the requirements defined in the notification settings in the ACR analysis subscription request. The notification may include the updated information specified in Table 2, such as the updated event time, the updated relocation target, the updated analysis results, etc.

[0104] Step 3: Based on the notification received in Step 2, the decision entity identifies that one or more ACR updates / modifications are required.

[0105] Step 4: The decision entity sends a notification to the analysis service indicating that an ACR update decision has been made. This information can be used by the analysis service to update the analysis information of the edge network (e.g., update the predicted workloads of S-EES / T-EES and S-EAS / T-EAS). In this notification, the EEC may indicate whether the analysis service should further continue to provide the updated analysis results of the ACR analysis subscription.

[0106] Step 5: The decision entity interacts with other relevant EEL entities to execute the ACR modification process. After executing the ACR modification, the decision entity may send a notification to the analysis service to update the ACR analysis subscription request.

[0107] The analysis service can determine that it is more beneficial to use a specific ACR scenario (e.g., fewer notifications and status changes in the EEL) based on various factors such as AC service KPIs, scenarios supported by relevant entities, coordination requirements, analysis information of the ACR, etc. For example, in a specific deployment, trends may indicate that the ACR determined by the EEC is the best, and then such an ACR scenario can be determined. Depending on the determination, not only the ACR scenario used can change, but also some updates may be required, such as profiles indicating which scenarios are supported.

[0108] Analysis-assisted proactive EAS instantiation

[0109] If the EES is expected to become a T-EES, it can also initiate a proactive EAS instantiation analysis subscription request to obtain predictive event notifications from the analysis service, so that proactive actions can be taken to prepare for the upcoming ACR (such as dynamic EAS instantiation). In addition to service continuity (planning), the analysis service can also be applied to other scenarios where proactive EAS instantiation is beneficial, such as regular scheduling and load balancing, EAS discovery, etc. Figure 7 An exemplary process of analysis-assisted proactive EAS instantiation is shown.

[0110] Step 1: The requesting EES sends a proactive EAS instantiation analysis subscription request to the analysis service to obtain analysis assistance for proactive EAS instantiation. This request may include the information shown in Table 3.

[0111] Table 3. Proactive EAS instantiation analysis subscription request

[0112]

[0113]

[0114] Step 2: The analysis service processes the request and sends a response back to the requesting EES. The analysis service can create a proactive EAS instantiation analysis subscription for this request.

[0115] Step 3: The analysis service starts collecting data and generating analysis results to detect the trigger event. For example, if the trigger event is defined as the predicted number of ACs requiring this type of EAS exceeding a threshold, then the analysis service will continuously generate / update the prediction of the number of ACs and compare the predicted value with the threshold. If the trigger event is defined as the predicted workload of other EASs of the same type exceeding a threshold, then the analysis service will continuously generate / update the prediction of the EAS workload and compare the predicted value with the threshold.

[0116] The analysis service can also associate different analysis subscriptions (requested by different entities) and, if the analysis results from these subscriptions are relevant or interdependent, then jointly generate / export analyses across these subscriptions. For example, if the trigger event in the proactive EAS instantiation analysis subscription request is defined as the EAS being selected as the T-EAS, then the analysis service can identify the ACR analysis subscription whose candidate list can include this EAS. If the ACR analysis subscription results in a recommendation to make this EAS the T-EAS, then the analysis service can generate a proactive EAS instantiation notification and send it to the corresponding EES.

[0117] Step 4: The analysis service detects, based on the generated analysis information, that the trigger event defined in the proactive EAS instantiation analysis subscription request is expected to occur at some future time. For example, the trigger event is detected when the EES that issued the request and the instantiable EAS are respectively selected as the T-EES and T-EAS for an upcoming ACR. When the workload prediction of the instantiated EAS exceeds a threshold, the proactive instantiation of the same type of instantiable EAS can be triggered. When the expected number of ACs requiring a certain type of EAS exceeds a threshold, the proactive instantiation of the same type of instantiable EAS can be triggered.

[0118] Step 5: According to the requirements defined in the notification settings in the proactive EAS instantiation analysis subscription request, the analysis service sends a proactive instantiation notification to the EES. The notification can include the information specified in Table 4.

[0119] Table 4. Proactive EAS Instantiation Notification

[0120]

[0121]

[0122] The proactive EAS instantiation notification can be sent in multiple messages at different times. In this case, the analysis service can use the partial notification indicator in the notification message to indicate that further information will be provided in subsequent notification messages. For example, the analysis service can send the first notification when generating the analysis result indicating the trigger event, where the notification may not include the event time. A subsequent notification can be sent after collecting or generating sufficient analysis information to derive the event time.

[0123] Step 6: The EES makes a decision to perform dynamic EAS instantiation based on the received notification.

[0124] Step 7: The EES can send a notification to the analysis service indicating that one or more proactive EAS instantiations have been performed. This information can be used by the analysis service to update the analysis information of the corresponding EAS(s) and the edge network.

[0125] Analysis-Assisted Shared EAS Selection

[0126] For use cases involving real-time communication in a multi-user session, whether between an AC and an EAS or between different ACs via an EAS, it may be necessary or beneficial to use services from a single shared EAS to meet latency requirements and avoid the need for synchronization between EASs. An analysis service can assist in the selection of the shared EAS and provide trigger detection to help coordinate EEL operations for such scenarios. Figure 8 An exemplary process for analysis-assisted shared EAS selection is illustrated.

[0127] Step 1: A requester sends an analysis subscription request for shared EAS selection to the analysis service to obtain assistance in selecting a shared EAS. The requester can be one of the ACs that will receive services from the shared EAS, or it can be an EEC / EES / ECS associated with one or more of the ACs that will receive services from the shared EAS. The request can include the information shown in Table 5.

[0128] Table 5. Analysis Subscription Request for Shared EAS Selection

[0129]

[0130]

[0131] Step 2: The analysis service processes the request and sends a response back to the requester.

[0132] Step 3: The analysis service can send a notification to the AC for which a shared EAS will be selected and / or other EEL entities associated with the AC (e.g., EEC, EES, ECS). The notification can indicate that an analysis subscription for shared EAS selection has been created. If the information in Table 5 was not provided in Step 1, then the analysis service can also send an information retrieval request to the relevant entities specified in the analysis subscription request to obtain such information.

[0133] Step 4: The relevant entities provide additional information to the analysis service as requested in Step 3.

[0134] Step 5: The analysis service begins collecting data and generating analysis results to make a shared EAS selection. The analysis can be collected or generated based on information about the ACs that will receive services from the shared EAS, and the shared EAS will be determined based on selection criteria.

[0135] The analytics service can identify ACs that can benefit from sharing an EAS selection but are currently receiving services from different EASs (e.g., due to their location). The analytics service can generate predictive location / path information for each AC, and / or predictive information about the network, EAS load, link / session QoS. Based on the collected / generated analytics, the analytics service can identify a shared EAS (which can be different from any EAS currently serving the AC) and recommend that the AC connect to the shared EAS (via the ACR). For example, a UAV / V2X application can define a margin in its path / destination, where the path can be adjusted such that the associated AC can receive services from the shared EAS. The analytics service can help select a shared EAS for such applications by considering its path / destination and the margin.

[0136] The analytics service can associate different analytics subscriptions and jointly generate / export analytics. For example, if the analytics service also acts as an ACR detection entity and is responsible for predicting the need for ACR operations, then it can consider the result of the shared EAS selection and trigger an ACR detection notification if the selected EAS is different from the EAS currently serving the AC. In another example, if it is predicted that the shared EAS currently used by the AC will be overloaded, then the analytics service can share the prediction (ACR detection notification) with each affected AC / EEC in a coordinated manner. If the selected shared EAS is one of the EASs that can be instantiated in the active EAS instantiation analytics subscription, then the analytics service can generate an active EAS instantiation notification to the corresponding EES.

[0137] Step 6: The analytics service sends a notification to the reporting target, along with information about the selected shared EAS and other information required in the analytics subscription request. If the shared EAS selection request is associated with other analytics subscriptions, then the selection of the EAS can trigger other notifications, such as an ACR detection notification or an active EAS instantiation notification. In this case, the analytics service can integrate the notification messages and send them to the corresponding entities.

[0138] Step 7: The EEL entity can perform operations based on the received analysis results of the shared EAS, such as performing / planning an ACR or triggering an EAS instantiation.

[0139] Graphical User Interface

[0140] Figure 9 An example graphical user interface (GUI) is depicted for the EEL to configure the analytics service to achieve service continuity.

[0141] Example Communication System

[0142] The 3rd Generation Partnership Project (3GPP) develops technical standards for cellular telecommunications network technologies, including radio access, core transport networks, and service capabilities - including work on codecs, security, and quality of service. Recent radio access technology (RAT) standards include WCDMA (commonly known as 3G), LTE (commonly known as 4G), LTE-Advanced standards, and New Radio (NR) also known as "5G". The development of 3GPP NR standards is expected to continue and include the definition of the next generation radio access technology (new RAT), which is expected to include the provision of new flexible radio access below 7 GHz, as well as the provision of new ultra-mobile broadband radio access above 7 GHz. The flexible radio access is expected to include new, non-backward compatible radio access in new spectrum below 7 GHz, and 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 the cmWave and mmWave spectrums, which will provide opportunities for ultra-mobile broadband access for, e.g., indoor applications and hotspots. In particular, the ultra-mobile broadband is expected to share a common design framework with the flexible radio access below 7 GHz, with design optimizations specific to cmWave and mmWave.

[0143] 3GPP has identified the various use cases that NR is expected to support, leading to various user experience requirements for data rate, latency, and mobility. Use cases include the following general categories: enhanced mobile broadband (eMBB), ultra-reliable low latency communication (URLLC), massive machine type communication (mMTC), network operations (e.g., network slicing, routing, migration, and interworking, energy savings), and enhanced vehicle-to-everything (eV2X) communication, which can include vehicle-to-vehicle communication (V2V), vehicle-to-infrastructure communication (V2I), vehicle-to-network communication (V2N), vehicle-to-pedestrian communication (V2P), and vehicle communication with other entities. Specific services and applications in these categories include, for example, surveillance and sensor networks, device remote control, two-way remote control, personal cloud computing, video streaming, wireless cloud-based offices, first responder connectivity, automotive eCall, disaster alerts, real-time gaming, multi-person video calls, autonomous driving, augmented reality, tactile Internet, virtual reality, home automation, robotics, and aerial drones, among others. All of these use cases and others are contemplated herein.

[0144] Figure 10AFIG. illustrates an example communication system 100, in which the methods and apparatuses described and claimed herein can be an aspect thereof. As shown, the example communication system 100 can include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, 102e, 102f, and / or 102g (which can generally or collectively be referred to as WTRU 102), radio access networks (RANs) 103 / 104 / 105 / 103b / 104b / 105b, core networks 106 / 107 / 109, public switched telephone network (PSTN) 108, Internet 110, other networks 112, and V2X server (or ProSe function and server) 113, but it should be recognized that the disclosed examples contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d, 102e, 102f, 102g can be any type of device or apparatus configured to operate and / or communicate in a wireless environment. Although each of the WTRUs 102a, 102b, 102c, 102d, 102e, 102f, 102g is depicted in Figures 10A - 10E as a handheld wireless communication device, it should be understood that for the various use cases envisioned for 5G wireless communication, each WTRU can include or be implemented as any type of device or apparatus configured to transmit and / or receive wireless signals, and by way of example only, such devices or apparatuses include user equipment (UE), mobile station, fixed or mobile subscriber unit, pager, cellular phone, personal digital assistant (PDA), smart phone, laptop computer, tablet computer, netbook, notebook computer, personal computer, wireless sensor, consumer electronics, wearable devices (such as smart watches or smart clothing), medical or e-health devices, robots, industrial equipment, drones, vehicles (such as cars, trucks, trains, or airplanes, etc.).

[0145] The communication system 100 may also include base stations 114a and 114b. The base station 114a may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, and / or other networks 112. The base station 114b may be any type of device configured to wired and / or wirelessly interface with at least one of the RRHs (remote radio heads) 118a, 118b, the TRPs (transmission and reception points) 119a, 119b, and / or the RSUs (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 the V2X server (or ProSe function and server) 113. The RRHs 118a, 118b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102c to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, and / or other networks 112. The TRPs 119a, 119b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102d to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, and / or other networks 112. The RSUs 120a and 120b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102e or 102f to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, other networks 112, and / or the V2X server (or ProSe function and server) 113. By way of example, the base stations 114a, 114b may be base transceiver stations (BTSs), Node-Bs, eNode Bs, home Node Bs, home eNode Bs, site controllers, access points (APs), wireless routers, etc. Although the base stations 114a, 114b are each depicted as a single element, it should be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0146] Base station 114a may be part of 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. Base station 114b may be part of 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. Base station 114a may be configured to transmit and / or receive wireless signals within a specific geographical area, which may be referred to as a cell (not shown). Base station 114b may be configured to transmit and / or receive wired and / or wireless signals within a specific geographical area, which may be referred to as a cell (not shown). A cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Accordingly, base station 114a may include three transceivers, e.g., one transceiver for each sector of the cell. In some cases, base station 114a may employ multiple-input multiple-output (MIMO) technology and thus may use multiple transceivers for each sector of the cell.

[0147] Base station 114a may communicate with one or more of WTRUs 102a, 102b, 102c via air interfaces 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.). Any suitable radio access technology (RAT) may be used to establish air interfaces 115 / 116 / 117.

[0148] Base station 114b may communicate with one or more of RRHs 118a, 118b, TRPs 119a, 119b, and / or RSUs 120a and 120b via wired or air interfaces 115b / 116b / 117b, which may be any suitable wired (e.g., cable, fiber optic, etc.) or wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, cmWave, mmWave, etc.). Any suitable radio access technology (RAT) may be used to establish air interfaces 115b / 116b / 117b.

[0149] RRH 118a, 118b, TRP 119a, 119b, and / or RSU 120a, 120b may communicate with one or more WTRUs 102c, 102d, 102e, 102f via 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.). Any suitable radio access technology (RAT) may be used to establish air interface 115c / 116c / 117c.

[0150] WTRU 102a, 102b, 102c, 102d, 102e, 102f, and / or 102g may communicate with each other via air interface 115d / 116d / 117d (not shown in the figure), which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, cmWave, mmWave, etc.). Any suitable radio access technology (RAT) may be used to establish air interface 115d / 116d / 117d.

[0151] More specifically, as described above, communication system 100 may be a multi - access system and may employ one or more channel access schemes such as CDMA, TDMA, FDMA, OFDMA, SC - FDMA, etc. For example, base station 114a in RAN 103 / 104 / 105 and WTRU 102a, 102b, 102c or RRH 118a, 118b, TRP 119a, 119b, and RSU 120a, 120b in RAN 103b / 104b / 105b and WTRU 102c, 102d, 102e, 102f may implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may use Wideband CDMA (WCDMA) to establish air interfaces 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).

[0152] In some cases, the base station 114a in the RAN 103b / 104b / 105b and the RRHs 118a, 118b, TRPs 119a, 119b, and RSUs 120a, 120b in the RAN 103b / 104b / 105b and the WTRUs 102c, 102d can implement radio technologies, such as evolved UMTS terrestrial radio access (E-UTRA), which can establish the air interfaces 115 / 116 / 117 or 115c / 116c / 117c using Long-Term Evolution (LTE) and / or LTE-Advanced (LTE-A), respectively. In the future, the air interfaces 115 / 116 / 117 can implement 3GPP NR technologies. LTE and LTE-A technologies include LTE D2D and V2X technologies and interfaces (such as sidelink communication, etc.). 3GPP NR technologies include NR V2X technologies and interfaces (such as sidelink communication, etc.).

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

[0154] For example, Figure 10AThe base station 114c therein can be a wireless router, a home Node B, a home eNode B, or an access point, and can utilize any suitable RAT to facilitate wireless connectivity in a local area such as a business location, home, vehicle, campus, etc. In some cases, the base station 114c and the WTRU 102e can implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In some cases, the base station 114c and the WTRU 102d can implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In some cases, the base station 114c and the WTRU 102e can utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish a pico cell or a femto cell. As Figure 10A shown, the base station 114b can have a direct connection to the Internet 110. Thus, it may not be required for the base station 114c to access the Internet 110 via the core network 106 / 107 / 109.

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

[0156] Although not shown in Figure 10A it should be appreciated that the RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 105b and / or the core network 106 / 107 / 109 can communicate directly or indirectly with other RANs that employ the same RAT or a different RAT as the RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 105b. For example, in addition to being connected to the RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 105b that can utilize the E-UTRA radio technology, the core network 106 / 107 / 109 can also communicate with another RAN (not shown) that employs the GSM radio technology.

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

[0158] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communication system 100 can include multimode capabilities. For example, the WTRUs 102a, 102b, 102c, 102d, and 102e can include multiple transceivers for communicating with different wireless networks over different wireless links. For example, Figure 10A the WTRU 102e shown in can be configured to communicate with a base station 114a that can employ a cellular-based radio technology and with a base station 114c that can employ an IEEE 802 radio technology.

[0159] Figure 10B is a block diagram of an example apparatus or device (such as, for example, a WTRU 102) configured for wireless communication in accordance with the various aspects shown herein. As Figure 10B shown, the example WTRU 102 can include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 113, a display / touchpad / indicator 128, a non-removable memory 130, a removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136, and other peripheral devices 138. It should be appreciated that the WTRU 102 can include any sub-combination of the foregoing elements while remaining consistent with the example. Also, in some instances, the base stations 114a and 114b, and / or the nodes of the base stations 114a and 114b can represent, for example but not limited to, transceiver stations (BTSs), Node Bs, site controllers, access points (APs), Home Node-Bs, evolved Home Node-Bs (eNodeBs), Home evolved Node-B gateways, and proxy nodes, etc. can include Figure 10BA part of some or all of the elements described and described herein.

[0160] The processor 118 can be a general-purpose processor, a dedicated processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 can perform signal encoding, data processing, power control, input / output processing, and / or any other function that enables the WTRU 102 to operate in a wireless environment. The processor 118 can be coupled to the transceiver 120, and the transceiver 120 can be coupled to the transmit / receive element 122. Although Figure 10B the processor 118 and the transceiver 120 are depicted as separate components, it should be appreciated that the processor 118 and the transceiver 120 can be integrated together in an electronic package or chip.

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

[0162] In addition, although the transmit / receive element 122 is Figure 10B depicted as a single element in, the WTRU 102 can include any number of transmit / receive elements 122. More specifically, the WTRU 102 can employ MIMO technology. Thus, in some cases, the WTRU 102 can 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.

[0163] The transceiver 120 can be configured to modulate the signals to be transmitted by the transmit / receive element 122 and demodulate the signals received by the transmit / receive element 122. As described above, the WTRU 102 can have multi-mode capabilities. Thus, the transceiver 120 can include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs (e.g., such as UTRA and IEEE 802.11).

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

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

[0166] The processor 118 may also be coupled to a 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 instead of information from the GPS chipset 136, the WTRU 102 may receive location information via the air interface 115 / 116 / 117 from a base station (e.g., base stations 114a, 114b) and / or determine its location based on the timing of signals received from two or more nearby base stations. It should be appreciated that the WTRU 102 may obtain location information by any suitable location determination method while remaining consistent with the example.

[0167] The processor 118 may also be coupled to other peripheral devices 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 peripheral devices 138 may include various sensors, such as an accelerometer, a biometric (e.g., fingerprint) sensor, an electronic compass, a satellite transceiver, a digital camera (for photos or videos), a universal serial bus (USB) port or other interconnect interfaces, a vibration device, a television transceiver, a hands-free headset, Modules, FM radio units, digital music players, media players, video game player modules, Internet browsers, etc.

[0168] The WTRU 102 may be implemented in other devices or apparatuses, such as sensors, consumer electronics, wearable devices (such as smart watches or smart clothing), medical or e-health devices, robots, industrial equipment, drones, vehicles (such as cars, trucks, trains, or airplanes, etc.). 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 peripherals 138).

[0169] Figure 10C is a system diagram of the RAN 103 and the core network 106. As described above, the RAN 103 may communicate with the WTRU 102a, 102b, and 102c via the air interface 115 using UTRA radio technology. The RAN 103 may also communicate with the core network 106. As Figure 10C shown, the RAN 103 may include Node Bs 140a, 140b, 140c, and each Node B may include one or more transceivers for communicating with the WTRU 102a, 102b, 102c via the air interface 115. The Node Bs 140a, 140b, 140c may each be associated with a specific cell (not shown) within the RAN 103. The RAN 103 may also include RNCs 142a, 142b. It should be appreciated that the RAN 103 may include any number of Node Bs and RNCs while remaining consistent with aspects of the present disclosure.

[0170] As Figure 10C shown, the Node Bs 140a, 140b may communicate with the RNC 142a. In addition, the Node B 140c may communicate with the RNC 142b. The Node Bs 140a, 140b, 140c may communicate with the respective RNCs 142a, 142b via the Iub interface. The RNCs 142a, 142b may communicate with each other via the Iur interface. Each of the RNCs 142a, 142b may be configured to control the respective Node Bs 140a, 140b, 140c connected thereto. In addition, each of the RNCs 142a, 142b may be configured to perform or support other functions, such as outer loop power control, load control, admission control, packet scheduling, handover control, macro diversity, security functions, data encryption, etc.

[0171] Figure 10CThe core network 106 shown in FIG. 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 depicted as part of the core network 106, it should be appreciated that any of these elements may be owned and / or operated by an entity other than the core network operator.

[0172] The RNC 142a in the RAN 103 may be connected to the MSC 146 in the core network 106 via the 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 a circuit-switched network, such as the PSTN 108, to facilitate communication between the WTRUs 102a, 102b, 102c and traditional landline communication devices.

[0173] The RNC 142a in the RAN 103 may also be connected to the SGSN 148 in the core network 106 via the 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 a packet-switched network, such as the Internet 110, to facilitate communication between the WTRUs 102a, 102b, 102c and IP-enabled devices.

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

[0175] Figure 10D is a system diagram of the RAN 104 and the core network 107. As described above, the RAN 104 may communicate with the WTRUs 102a, 102b, and 102c via the air interface 116 using E-UTRA radio technology. The RAN 104 may also communicate with the core network 107.

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

[0177] 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. As Figure 10D shown, the eNode-Bs 160a, 160b, 160c may communicate with each other via the X2 interface.

[0178] Figure 10D The core network 107 shown 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 depicted as part of the core network 107, it should be appreciated that any of these elements may be owned and / or operated by an entity other than the core network operator.

[0179] The MME 162 may be connected to each of the eNode-Bs 160a, 160b, 160c in the RAN 104 via the 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 the initial attachment of the WTRUs 102a, 102b, 102c, etc. The MME 162 may also provide control plane functions for handover between the RAN 104 and other RANs (not shown) employing other radio technologies such as GSM or WCDMA.

[0180] The serving gateway 164 can be connected to each of the eNode-Bs 160a, 160b, and 160c in the RAN 104 via the S1 interface. The serving gateway 164 can generally route and forward user data packets to / from the WTRUs 102a, 102b, 102c. The serving gateway 164 can also perform other functions, such as anchoring the user plane during handovers between eNode Bs, triggering paging when downlink data is available for the WTRUs 102a, 102b, 102c, managing and storing the context of the WTRUs 102a, 102b, 102c, and so on.

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

[0182] The core network 107 can facilitate communication with other networks. For example, the core network 107 can provide the WTRUs 102a, 102b, 102c with access to a circuit-switched network (such as the PSTN 108) to facilitate communication between the WTRUs 102a, 102b, 102c and traditional landline communication devices. For example, the core network 107 can include 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 or can communicate with it. In addition, the core network 107 can provide the WTRUs 102a, 102b, 102c with access to the network 112, which can include other wired or wireless networks owned and / or operated by other service providers.

[0183] Figure 10E is a system diagram of the RAN 105 and the core network 109. The RAN 105 can be an Access Service Network (ASN) that communicates with the WTRUs 102a, 102b, and 102c via the air interface 117 using IEEE 802.16 radio technology. 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 can be defined as reference points.

[0184] As Figure 10EAs shown, RAN 105 may include base stations 180a, 180b, 180c and an ASN gateway 182. However, it should be recognized that RAN 105 may include any number of base stations and ASN gateways while remaining consistent with aspects of the present disclosure. Base stations 180a, 180b, 180c may each be associated with a specific cell in RAN 105 and may include one or more transceivers for communicating with WTRUs 102a, 102b, 102c via an air interface 117. In some cases, base stations 180a, 180b, 180c may implement MIMO technology. Thus, base station 180a, for example, may use multiple antennas to transmit wireless signals to WTRU 102a and receive wireless signals from WTRU 102a. 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, etc. The ASN gateway 182 may act as a traffic aggregation point and may be responsible for paging, caching of subscriber profiles, routing to the core network 109, etc.

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

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

[0187] As Figure 10EAs shown, the RAN 105 can be connected to the core network 109. The communication link between the RAN 105 and the core network 109 can be defined as the R3 reference point, and the R3 reference point includes protocols for facilitating data transfer and mobility management capabilities, for example. The core network 109 can 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 depicted as part of the core network 109, it should be appreciated that any of these elements can be owned and / or operated by an entity other than the core network operator.

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

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

[0190] Described herein and in Figure 10A 、 Figure 10C 、 Figure 10D and Figure 10EThe core network entities shown are identified by the names given to those entities in certain existing 3GPP specifications, but it should be recognized that in the future, those entities and functions may be identified by other names, and certain entities or functions may be combined in future specifications published by 3GPP, including future 3GPP NR specifications. Therefore, Figure 10A , Figure 10B , Figure 10C , Figure 10D and Figure 10E the specific network entities and functions described and shown are provided only as examples, and it should be understood that the subject matter disclosed and claimed herein may be implemented or realized in any similar communication system, whether currently defined or defined in the future.

[0191] Figure 10F is a block diagram of an exemplary computing system 90 in which one or more devices of the communication network shown in Figure 10A , Figure 10C , Figure 10D and Figure 10E can be implemented, 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 a server and may be primarily controlled by computer-readable instructions, which may be in the form of software, wherever and however such software is stored or accessed. Such computer-readable instructions may be executed within a processor 91 to cause the computing system 90 to operate. The processor 91 may be a general-purpose processor, a dedicated processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 91 may perform signal 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. The coprocessor 81 is an optional processor different from the main processor 91 that may perform additional functions or assist the processor 91. The processor 91 and / or the coprocessor 81 may receive, generate, and process data related to the methods and apparatuses disclosed herein.

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

[0193] The memory coupled to the system bus 80 includes random access memory (RAM) 82 and read-only memory (ROM) 93. This memory includes circuitry that allows for the storage and retrieval of information. The ROM 93 generally contains stored data that is not easily modified. The data stored in the RAM 82 can be read or changed by the processor 91 or other hardware devices. Access to the RAM 82 and / or ROM 93 can be controlled by the memory controller 92. The memory controller 92 can provide an address translation function that translates virtual addresses to physical addresses when executing instructions. The memory controller 92 can also provide a memory protection function that isolates processes within the system and separates system processes from user processes. Thus, a program running in the first mode can only access the memory mapped by its own process virtual address space; it cannot access the memory within another process's virtual address space unless memory sharing between processes has been set up.

[0194] In addition, the computing system 90 can include a peripheral device controller 83 that is responsible for transferring instructions from the processor 91 to peripheral devices such as a printer 94, a keyboard 84, a mouse 95, and a disk drive 85.

[0195] 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 can include text, graphics, animated graphics, and video. The visual output can be provided in the form of a graphical user interface (GUI). The display 86 can be implemented with a CRT-based video display, an LCD-based flat panel display, a gas plasma-based flat panel display, or a touchpad. The display controller 96 includes the electronic components required to generate the video signal sent to the display 86.

[0196] In addition, the computing system 90 can include communication circuitry such as a network adapter 97 that can be used to connect the computing system 90 to an external communication network (such as Figure 10A 、 Figure 10B 、 Figure 10C 、 Figure 10D and Figure 10ERAN 103 / 104 / 105, core network 106 / 107 / 109, PSTN 108, Internet 110, or other network 112) so that computing system 90 can communicate with other nodes or functional entities of those networks. Alone or in combination with processor 91, the communication circuitry can be used to perform the transmission and reception steps of certain devices, nodes, or functional entities described herein.

[0197] Figure 10G Illustrates an example communication system 111, in which the methods and apparatuses described and claimed herein can be an aspect thereof. As shown, the example communication system 111 can include wireless transmit / receive units (WTRUs) A, B, C, D, E, F, base stations, a V2X server, and RSUs A and B, but it will be appreciated that the present disclosure contemplates any number of WTRUs, base stations, networks, and / or network elements. One or several or all of WTRUs A, B, C, D, E may be out of network range (e.g., outside the cell coverage boundary shown by the dashed line in the figure). WTRUs A, B, C form a V2X group, where WTRU A is the group leader and WTRUs B and C are group members. WTRUs A, B, C, D, E, F can communicate via the Uu interface or the sidelink (PC5) interface.

[0198] It should be understood that any one or all of the apparatuses, systems, methods, and processes described herein can be implemented in the form of computer-executable instructions (e.g., program code) stored on a computer-readable storage medium, which when executed by a processor (such as processor 118 or 91) causes the processor to perform and / or implement the systems, methods, and processes described herein. Specifically, any step, operation, or function described herein can be implemented in the form of such computer-executable instructions executed on a processor of a device or computing system configured for wireless and / or wired network communication. The computer-readable storage medium includes volatile and non-volatile, removable and non-removable media implemented in any non-transitory (e.g., tangible or physical) method or technology for storing information, but such computer-readable storage medium does not include signals. The computer-readable storage medium includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disk (DVD) or other optical disk storage devices, magnetic tape cartridges, tapes, magnetic disk storage or other magnetic storage devices, or any other tangible or physical medium that can be used to store the desired information and can be accessed by a computing system.

[0199] Definitions

[0200] The following are definitions of abbreviations that appear in the body of the present disclosure.

[0201]

[0202]

Claims

1. A method performed by an Edge Enabler Server (EES) to support a user device receiving services from an Edge Application Server (EAS), comprising: Sending a first message indicating a request for predicting a service continuity event to an analysis service, wherein the first message includes a trigger condition of the service continuity event; Receiving a second message from the analysis service, the second message including a predicted timing of the service continuity event and analysis information of one or more target EESs or target EASs associated with the service continuity event; Selecting a target EES or EAS based on the received analysis information; And Sending a third message to the analysis service, the third message including a notification of the service continuity event and the selected target EES or EAS.

2. The method according to claim 1, wherein the trigger condition of the service continuity event is associated with the load of one or more EESs or EASs.

3. The method according to claim 1, wherein the first message further includes a list of candidate EESs or EASs that are targets of the service continuity event.

4. The method according to claim 1, wherein the second message further includes a list of proposed EESs or EASs that are targets of the service continuity event.

5. The method according to claim 1, further comprising: Receiving a fourth message from the analysis service, the fourth message including updated analysis information associated with the service continuity event; Determining one or more updates to a plan corresponding to the service continuity event based on the fourth message; And Sending a fifth message indicating the determination to the analysis service.

6. The method according to claim 1, further comprising: Sending a message including a request for discovering an EAS that is a target of the service continuity event to the selected target EES.

7. The method according to claim 1, further comprising: Sending a message including a request for instantiating an EAS as a target of the service continuity event to the selected target EES.

8. A device comprising an Edge Enabler Server (EES), the device further comprising: A processor; A memory; And Computer-executable instructions that, when executed by the processor, cause: Sending a first message indicating a request for predicting a service continuity event to an analysis service, wherein the first message includes a trigger condition of the service continuity event; Receiving a second message from the analysis service, the second message including a predicted timing of the service continuity event and analysis information of one or more target EESs or target EASs associated with the service continuity event; Selecting a target EES or EAS based on the received analysis information; And Sending a third message to the analysis service, the third message including a notification of the service continuity event and the selected target EES or EAS.

9. The device according to claim 8, wherein the trigger condition of the service continuity event is associated with the load of one or more EESs or EASs.

10. The device according to claim 8, wherein the first message further includes a list of candidate EESs or EASs that are targets of the service continuity event.

11. The apparatus according to claim 8, wherein the second message further includes a list of proposed EESs or EASs that are the targets of a service continuity event.

12. The apparatus according to claim 8, wherein the computer-executable instructions, when executed by the processor, further cause: Receiving a fourth message from an analytics service, the fourth message including updated analytics information associated with a service continuity event; Determining one or more updates to a plan corresponding to the service continuity event based on the fourth message; And Sending a fifth message indicating the determination to the analytics service.

13. The apparatus according to claim 8, wherein the computer-executable instructions, when executed by the processor, further cause: Sending a message including a request to discover an EAS that is the target of a service continuity event to a selected target EES.

14. The apparatus according to claim 8, wherein the computer-executable instructions, when executed by the processor, further cause: Sending a message including a request to instantiate an EAS that is the target of a service continuity event to a selected target EES.

15. A non-transitory computer-readable medium storing computer-executable instructions, the computer-executable instructions, when executed by a processor, cause: Sending a first message indicating a request to predict a service continuity event to an analytics service, wherein the first message includes a trigger condition of the service continuity event; Receiving a second message from the analytics service, the second message including a predicted timing of the service continuity event and analytics information of one or more target EESs or target EASs associated with the service continuity event; Selecting a target EES or EAS based on the received analytics information; and Sending a third message to the analytics service, the third message including a notification of the service continuity event and the selected target EES or EAS.

16. The non-transitory computer-readable medium according to claim 15, wherein the trigger condition of the service continuity event is associated with the load of one or more EESs or EASs.

17. The non-transitory computer-readable medium according to claim 15, wherein the first message further includes a list of candidate EESs or EASs that are the targets of the service continuity event.

18. The non-transitory computer-readable medium according to claim 15, wherein the second message further includes a list of proposed EESs or EASs that are the targets of the service continuity event.

19. The non-transitory computer-readable medium according to claim 15, wherein the computer-executable instructions, when executed by the processor, further cause: Receiving a fourth message from the analytics service, the fourth message including updated analytics information associated with the service continuity event; Determining one or more updates to a plan corresponding to the service continuity event based on the fourth message; And Sending a fifth message indicating the determination to the analytics service.

20. The apparatus according to claim 15, wherein the computer-executable instructions, when executed by the processor, further cause: Sending a message including a request to discover an EAS that is the target of a service continuity event to the selected target EES.

Images