AIML task continuity support

Abstract

Methods and devices for AIML task continuity support are described herein. An AIML task may be distributed to multiple entities (servers or devices (UEs)) spread across different (edge) service areas. The AIML enabler (AME) service may assist the distribution of the task and the management of participants in different areas. Due to mobility or other events, the participants in AIML tasks may switch from one service area to another, or from one edge data network (EDN) to another with service continuity support. The existing mechanisms for service continuity provided by edge enablers are not aware of the associated AIML tasks or their configuration and context information at the cloud, edge and / or devices. This disclosure proposes a service to support AIML task continuity, which may assist with transfer and completion of ongoing and / or scheduled AIML tasks if / when the AIML tasks are relocated to different servers or devices / UEs.

Description

AIML TASK CONTINUITY SUPPORTINCORPORATION BY REFERENCE

[0001] This application claims priority to U.S. Patent Application No. 63 / 574,972 filed April 5, 2024 (titled ‘‘AIML Task Continuity Support”), the contents of which is hereby incorporated by reference in its entirety or any and all purposes.BACKGROUND

[0002] Machine Learning (ML) is a complex process in which mathematical algorithms are trained with curated data to generalize predictions of future data based upon the training. The machine learning workflow typically include operations such as the determination of ML requirements, data collection, data preparation, model building / training, model evaluation, model deployment, monitoring and update, etc. Figure 1 shows an example machine learning workflow.

[0003] Edge Computing is a network architecture concept that enables computing capabilities and service environments to be deployed closer to devices / UEs. It promises several benefits such as lower latency, higher bandwidth, reduced backhaul traffic and prospects for new services compared to the cloud environments. 3GPP defined an edge enabler layer that provides services for enabling edge applications over 3GPP networks.

[0004] Figure 2 shows the Edge Application Enabler Layer (EEL) architecture defined by the 3GPP SA6 working group. EEL refers to the overall functionality provided by the entities such as Edge Enabler Clients (EECs), Edge Enabler Servers (EESs) and Edge Configuration Servers (ECSs), necessary for enabling UE Application Clients (ACs) to interact with Edge Application Servers (EASs) over 3GPP networks. For edge computing, it is essential that UE ACs are able to locate and connect with the most suitable EASs available within the Edge Data Netw orks (EDNs) that the UEs are located in. This is dependent on the needs of the ACs and the availability of EASs in edge data netw orks. The EEL supports a set of services and exposes these services via APIs defined for each of the EEL defined reference points (e.g.. EDGE-1 thru EDGE-9).

[0005] Some of the services include: services for discovery7of ECSs and provisioning of edge computing services based on a UEs location and service requirements; services for registration of EECs to EESs and EASs to EESs; services for providing continuity of service between ACs and EASs (e.g., when a UE moves from one EDN to another EDN); and exposure of 5GC services for use by EASs

[0006] When a UE moves to a new location, different edge application servers (EASs) can be more suitable for serving the UE. When no suitable EAS can be found for serving the UE, the service session may transition to a cloud application server (CAS). Such transitions can result from a non-mobility event also, and require support from the edge enabler layer to maintain the service continuity for the application. Support for service continuity' provides several features for minimizing the application layer service interruption by replacing the source EAS connected to the AC in the UE, with a target EAS or CAS.

[0007] The EEL provides features that support service continuity for ACs in the UE to minimize service interruption while replacing the S-EAS with a T-EAS. The following scenarios are supported for sendee continuity: UE mobility, including predictive or expected UE mobility; overload situations in S-EAS or EDN; and maintenance aspects such as graceful shutdown of an EAS.

[0008] To support the need of ACR, the following entity roles are identified: detection entity', detecting or predicting the need of ACR; decision-making entity, deciding that the ACR is required; and execution entity , executing ACR.

[0009] The EEL further provides the feature of service continuity planning to support seamless service continuity, when information about planned, projected, or anticipated movement of the UE outside the service area of the serving EAS is available at the EEL.

[0010] Depending on whether the EEC is involved in the decision phase, whether the T- EAS discovery is performed by the EEC or S-EES, how the ACR request is sent and how the application context is transferred, the following scenarios have been identified: initiation of ACR by EEC using regular EAS discovery; EEC executed ACR via S-EES; S-EAS decided ACR scenario; S-EES executed ACR; and EEC executed ACR via T-EES.

[0011] An AIML task may be distributed to multiple entities (servers or devices (UEs)) spread across different (edge) service areas. The AIML enabler (AME) service may assist the distribution of the task and the management of participants in different areas. Due to mobility or other events (e.g., lack of sufficient compute, storage, or network resources), the participants in AIML tasks may switch from one service area to another, or from one edge data network (EDN) to another with service continuity support.

[0012] Existing service continuity in EDNs enables seamless access to application communication services, e.g. for the application employing AIML. The edge application servers (EASs) provide services to application clients (ACs) on the devices (UEs) accordingto the ACs’ requirements. Service continuity may be accomplished by identifying a target EAS which can provide services identical to the source EAS so that the AC on the device may continue to receive the same services from the target EAS after transitioning from the source EAS. However, for AIML enabler service deployed on the edge, the participants (devices) perform AIML operations to complete the task according to the task configuration assigned by the managing AMES (acting as EAS). In a transition event, the target AMES (EAS) may pertain to a different task configuration for managing the task participants than the source EAS, which may affect the task execution on the transitioned participant. In this case, either the task configuration or the task execution may need to be adapted to ensure the participant may continue to perform AIML operations and execute the task seamlessly. As a results, the AIML enabler service provided by the source AMES and the target AMES need to be coordinated to support AIML task continuity.

[0013] Moreover, an AIML task participant may report outputs of task execution to the managing AMES (EAS), and the transition from a source AMES to a target AMES may affect how the outputs are reported and perceived by the AMES. Correspondingly, the target AMES may need to coordinate with the source AMES to process the task outputs even after the transition is completed, which is different from the general service continuity scenario where the source EAS becomes irrelevant after the transition is completed.

[0014] In summary, AIML task continuity is different than service continuity provided by existing edge enablers, as the existing mechanisms are not aware of the associated AIML tasks or their configuration and context information at the cloud, edge and / or devices. Existing service continuity may need to be complemented by AIML task continuity support to ensure smooth transitions for AIML applications.SUMMARY

[0015] A service supporting AIML task continuity which support the following features: AIML task continuity aware task configuration; AIML task context maintenance and transition history tracking; transition aware AIML task and operation management; transition aware AIML task output reporting and processing; assistance to AIML task participant handover, or a combination thereof.

[0016] In one aspect of the present disclosure, a method for an AMES may include: receiving and maintaining information of an AIML task participant and the correspondingedge data network. In some cases, the information may include location information, scheduled or predicted movement behavior or path / trajectory of the participants, current or predicted service load of the EDNs and / or the servers in the EDNs, congestion conditions in the network, etc.

[0017] The method may also include receiving an AIML task request from a requestor. The request may include task continuity7requirements or policies that specify what actions should be taken by the AME service and / or the participants at transition events.

[0018] The method may also include sending a task configuration request to the participant. In some cases, the task configuration may be determined by the AMES or received from another AMES. In some cases, the task configuration may be specified for a single participant or a group / set of participants. In some cases, the task configuration may be determined based on the information of the participants and EDNs. In some cases, the task configuration may include an indicator that AIML task continuity is required. In some cases, the task configuration may include a schedule for the task and / or operations, which is determined based on (predictive) information of the timing of the transition event. In some cases, the task configuration may specify a list of events and / or conditions to be monitored or detected by the participant, which may be used to detect the transition event. In some cases, the task configuration may specify a list of data and / or information to be captured and maintained in the AIML task context. In some cases, the task configuration may include one or more task reporting policies which may specify what information should be reported and where to send the information. In some cases, the task configuration may include one or more task continuity policies which may specify the trigger conditions or transition events and the corresponding actions to be performed by the participant. In some cases, an updated task configuration may be determined by the AMES before, during, or after a transition event. In some cases, the determined or updated task configuration may be sent to another AMES.

[0019] The method may also include receiving and maintaining AIML task context for each AIML task participant. In some cases, the task context may include task and operation status, task output, context information of the output, etc. In some cases, the task context may include identifiers of a list of AMES which have previously been associated with the participant. In some cases, the task context may include identifiers of a list of AMES which may be associated with the participant at a future time. In some cases, the task context may be received from an AMEC associated with a participant. In some cases, the task context maybe received from another AMES that has been previously associated with the participant. In some cases, the task context may be received from a withdrawing participant based on the request from the AMES.

[0020] The method may also include sending a message with updated AIML task context. In some cases, the updated task context is sent to an AMEC or another AMES. In some cases, the updated task context may indicate a request to an AMEC to pause, terminate, activate a task or operation. In some cases, the task context may be updated by the AMES before, during, or after a transition event. In some cases, the task context may be sent to a replacement participant that is replacing a withdrawing participant.

[0021] The method may also include receiving a report consisting of AIML task outputs. In some cases, the report may be received from an AMEC associated with a participant. In some cases, the report may be received from another AMES. In some cases, the report may be forwarded to another AMES based on the task context associated with the report. In some cases, the reported task outputs may be processed by the AMES.

[0022] The method may also include sending processed AIML task outputs to a notification target. In some cases, the task outputs may include the outputs from a participant that has undergone a transition event and may be associated with different context information.

[0023] In another aspect of the present disclosure, a method for an AMEC may include: Receive an AIML task configuration from an AMES. In some cases, the task configuration may include information as described above (e.g., in the AMES method).

[0024] The method may also include receiving and maintaining AIML task context associated with an assigned AIML task. In some cases, the task context may include information as described above (e.g., in the AMES method). In some cases, the task context may be received from the managing AMES. In some cases, the task context may be received from another AMEC that is withdrawing from the task.

[0025] The method may also include sending AIML task context to the managing AMES. In some cases, sending the task context may include reporting task outputs. In some cases, the at least part of the task context may be associated with another AMES which may be indicated in the task context. In some cases, the task context may be sent to the AMES when the AMEC is withdrawing from the AIML task. In some cases, the task context may be sent based on receiving a context transfer request from the AMES.

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

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

[0028] FIG. 1 depicts an example ML workflow.

[0029] FIG. 2 depicts an EEL architecture.

[0030] FIG. 3 depicts an Edge-enabled AIML task continuity management.

[0031] FIG. 4 depicts AIML task remaining active during transition.

[0032] FIG. 5 depicts AIML task paused during transition.

[0033] FIG. 6 depicts AIML task terminated during transition.

[0034] FIG. 7 depicts an AIML task output management procedure.

[0035] FIG. 8 depicts a transition flow between participants.

[0036] FIG. 9 depicts a graphical user interface (GUI) for AIML task request with AIML task continuity support..

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

[0038] FIG. 10B depicts a block diagram of an example apparatus or device configured for wireless communications.

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

[0040] FIG. 10D depicts a system diagram of another example RAN and core network.

[0041] FIG. 10E depicts a system diagram of another example RAN and core network.

[0042] FIG. 10F depicts a block diagram of an example computing system.

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

[0044] An AIML task consists of a set of AIML operations to be performed by one or more entities (e.g. cloud servers, edge servers, or devices / UEs) and the corresponding parameters, targets and / or requirements. AIML tasks can be distributed to multiple entities where each may perform a subset of the required operations. A participant is an entity (e.g. server, device / UE) that participates (or will participate) in an AIML task by performing the required AIML operations as indicated by the task.

[0045] An AIML enabler service is a service that assists with the execution of AIML tasks. An AIML enabler service may support configuration and management of the participants, distribution of the AIML task to the participants, collection and / or aggregation of the data, information, outputs / results from the participants, reporting to the task requestor or notification target, etc. An AIML enabler service can be provided by a central / cloud-based AIML enabler server (C-AMES) or an edge-based AIML enabler server (E-AMES). Each E- AMES may be associated with an edge service area and may manage participants within the area. The AIML enabler servers may communicate with and manage the participants directly, or via AIML enabler clients (AMECs) hosted on the participants.

[0046] An E-AMES can be implemented as a standalone functional entity in the application enablement layer. In this case the E-AMES may leverage the services provided by the edge enabler layer (EEL) as an edge application server (EAS). The E-AMES can also be implemented as an enhancement to the EEL sendee provided by an edge enabler server (EES). In such cases, the north-bound EEL interface(s) may be augmented to provide AME services, or separate interface(s) may be exposed to the application specific layer (e.g. application server). The E-AMES can also be implemented as an enhancement to other application enablement layer services, such as SEAL, AD AES, etc. Similarly, E-AMES sen ices may be implemented within the application requesting the AIML task.

[0047] AIML task continuity’ refers to mechanisms provided by AIML enabler services to assist with transfer and completion of ongoing and / or scheduled AIML tasks (e.g. for split AIML leaming / inferencing) if / when the AIML tasks are relocated to different servers or devices / UEs. It can be appreciated by those skilled in the art that mechanisms disclosed may apply to computational tasks other than AIML-specific tasks.

[0048] When a participant with an ongoing AIML task moves to a new location, the participant may need to be managed by a different AMES. Such transitions may also result from a non-mobility event (e.g. maintenance of AMES, load balancing among AMESs),requiring support from the AIML enabler service to maintain the AIML task continuity for task execution.

[0049] For example, the completion and availability of individual FL client (participant) training results in edge-enabled federated learning may require AIML task continuity' support such that the results in each edge service area can be aggregated correctly when FL clients transition from one area to another. In another example, a split learning participant may require AIML task continuity support to assist the transfer of intermediate results if the participant has left the service area where the learning task is initially split. The following features may be supported by the AIML enabler service to support AIML task continuity7:

[0050] The AME service may perform transition-aware task configurations and scheduling on the participants. For example, the AME service may collect predictive information of the participant’s mobility and movement behavior and schedule the AIML operations to be performed by the participant such that the operations will not be disrupted by a transition event (e.g. by scheduling connectivity-sensitive operations to be performed outside the predicted transition period and scheduling local operations to be performed during the transition period).

[0051] The AME service may maintain a task context to track the transition history for each participant. A transition record may be used to identify the context information of the task outputs, determine the validity or applicability of the task outputs, and direct the task outputs to the appropriate target. For example, the task output of a transitioned mobile participant may be generated based on input data that is not obtained from the current service area. The AME service may identify the service area of the input data sources and associate the output with the applicable sendee area.

[0052] The AME service may control the process of AIML tasks and / or operations during transition events based on the task configuration and context, such as to pause an operation prior to a transition event and resume the operation after the transition, or to terminate an operation before a transition and restart the operation after the transition.

[0053] The AME service may process the task output of a transitioned participant. Particularly, an AMES may interact with one or more other AMESs to retrieve data and / or information needed for processing the output, and redirect the task output to the appropriate target based on the task context to ensure the validity and applicability of the task output.

[0054] The AME service may assist the task context transfer from a participant withdrawing from a task / operation with a replacement participant.

[0055] Functionalities provided by the edge enabler layer (EEL) may be leveraged by the AIML enabler service to support the AIML task transitions. AIML task continuity service may be provided on top of the EEL service continuity7procedure, especially with specifying the context transfer and management. AIML task continuity service may also be provided independent of EEL service continuity procedure (e.g. for non-edge scenario) which may further specify the detection of transition event, identifying target AMES, etc.Procedure

[0056] A participant with an ongoing AIML task may move from one edge sendee area to another, each associated with a different E-AMES, i.e. source AMES and target AMES. Correspondingly, the management of the participant will be transferred from the source AMES to the target AMES. When a participant managed by an E-AMES (source AMES) moves from one edge sendee area to an area without EDN coverage or no suitable E-AMES is found, the AMEC may connect to the C-AMES (target AMES) directly to continue the AIML task. On the other hand, a participant directly managed by a C-AMES (source AMES) may move to an edge service area with an E-AMES that supports the AIML task. In this case, the participant may switch to being managed by the E-AMES (target AMES) to continue the AIML task. The aforementioned transition may also happen in general data networks without EDN deployment.

[0057] During a transition event where a participant managed by a first AMES (i.e., source AMES) switches to a second AMES (i.e., target AMES), the source and / or target AMESs may perform AIML task continuity operations on behalf of the participant. The source and / or target AMESs may handle the update of task configuration, the transfer of task context, and the processing of reports from the participants that have undergone AMES transition events, and perform other required AIML operations accordingly.

[0058] Figure 3 shows an overview of an edge-enabled AIML task continuity management procedure. It can be appreciated by those skilled in the art that this procedure may apply to scenarios other than edge-enabled ones. Note that the numbering of the steps may not represent the order of performing such steps.

[0059] Step 1: The AME service (C-AMES, E-AMES, AMEC) may collect information of the participants and the EDNs that the participants are located in. Particularly, the AMEservice may collect information that is related to potential transition events, such as the location information of the participants, scheduled / predicted movement behavior or path / trajectory of the participants, current / predicted service load of the EDNs and / or the servers in the EDNs, congestion conditions in the network, etc.

[0060] Step 2: The AME service may receive an AIML task request from a requestor which may indicate requirements for AIML task continuity support. The task request may include task continuity requirements or policies that specify what actions should be taken by the AME service and / or participants at transition events (similar to the task continuity policies described in Table 1). Based on the AIML task request and the information of the participants and networks, the AME service may determine how to distribute the task to the participants by specifying task configuration(s). The task configuration may be specified in a hierarchical structure. For example, the C-AMES may determine the task configuration for each E-AMES and the corresponding edge service area, and the E-AMES may further determine the task configuration for each participant within its edge service area. The task configurations may include information of the task to be assigned to participant(s) and instructions for supporting AIML task continuity, as shown in Table 1. Based on this information, AMESs may determine how to update an AIML task configuration in the event of an AIML task transition, how to configure and update AIML task status in the event of AIML task transition, how to handle the task context during transition, how to aggregate and report task outputs associated with the participant(s), etc. The task configuration may be specified for a single participant or for a group / set of participants that may jointly work on a task.Table 1. AIML task configuration to support task continuity

[0061] When determining the required A1ML operations for a participant, the source or target AMES may take into consideration the potential transition event of the participant. For example, if an analytics function predicts the participant may leave the current edge service area and enter another area with a certain confidence level, then the AMES may initiate the schedule of AIML task operations for the participant such that the upload and download operations (which may require continuous communication between the AMES and the AMEC) are performed outside the transition period. The configuration may be dynamically updated as the AMES receives updated information of the participant and / or the network. The re-configuration may be triggered when the participant is transitioning between different AMESs to support AIML task continuity.

[0062] Step 3: After the (source) AMES determines the task configuration for each participant it is managing, the (source) AMES may send an AIML task configuration request to the AMEC associated with each participant, and receive a response from each AMEC indicating the participant has accepted (or declined) the assigned task.

[0063] Step 4: If a participant accepts the task configuration, the AMES may manage the task execution on the participant and maintain AIML task context for the participant. The task context associated with a participant may be created by either the AMES or the AMEC, and updated by both.

[0064] The AIML task context may include information in Table 2.Table 2. AIML task context

[0065] Step 5: A transition event (as specified in “event monitoring" and “task continuity’ policies” in Table 1) may be detected by the AME service (e.g. source AMES, target AMES, AMEC). The AME service may also receive notifications of transition events from the EEL (source EES, target EES, EEC). The transition may also be planned proactively if predictive information of the participant and / or the network / EDN is available.

[0066] Step 6: The source AMES or the corresponding source EES may initiate the discovery of target AMES. The discovery may be performed by first retrieving the target EES from the ECS and then sending an EAS discovery' request to the target EES (if an AMES is viewed as an EAS). The discovery filter may include information of the AIML task and / or task context of the participant. An E-AMES (or C-AMES) may be managing more than one AIML task at a time, therefore an identifier of the task may be used to discover the target AMES and ensure it may support the AIML task associated with the one or more participants and AMECs. Once the target AMES is determined, the task context may be updated to add the identifier of the target AMES. If no suitable E-AMES is found, the target AMES can be set to the C-AMES.

[0067] If the transition is triggered by the target AMES or if the target AMES is known to the source AMES or the AMEC(s), then the source AMES or the AMEC(s) may update the task context and notify the EEL.

[0068] The EEL service continuity’ procedure may’ be performed accordingly by the associated EEL entities such as source EES (CES), target EES (CES), ECS and EEC.

[0069] Step 7 : The source AMES and / or the AMEC may send the task context associated with the participant(s) and the ongoing task to the target AMES. The transferred task context may include previously generated task outputs. The context information may be sent by the source AMES using application context transfer procedure provided by the EEL, or by the AMEC(s), or both. If the AME service is implemented as part of EEL, then the context information associated with a participant can be viewed as part of the EEC context. Then the context information may also be transferred with EEC context relocation procedure.

[0070] Not all task context information may be transferred to the target AMES. For example, the source AMES may maintain information of operations that have beencompleted by the participant. For a participant that may be traversing multiple edge service areas, instead of transmitting all the context information from one AMES to another, the source AMES may selectively transmit context information that is relevant to an ongoing operation and maintain the rest of the context information locally until it receives a request for retrieving such information from another AMES.

[0071] Step 8: After receiving the task context associated with the participant(s), the target AMES may update the task configuration of the participant(s) and send it to the AMEC(s). The target AMES may notify and / or share the updated task configuration with the source AMES and / or other AMES (e.g. the AMES which has generated a high-level task configuration). The following actions may be taken by the target AMES in updating the task configuration:

[0072] Updating the AMES identifier to the identifier of the target AMES.

[0073] Updating required AIML operation: For example, the required performance for the task / operation may differ in different edge service areas, the target AMES may update the requirements for the task / operations of the transitioned participant based on local configuration.

[0074] Updating task / operation schedule: For example, the AIML operations may be synchronized locally within each edge service area. The target AMES may update the task schedule of the transitioned participant(s) to align with the other participants in its service area.

[0075] Updating task input: For example, different edge areas may be using different ML models for an inference task. The target AMES may send the new model to the transitioned participant(s) by updating the task input in the task configuration. Updating other configuration information (as shown in Table 1) as needed.

[0076] Step 9: The task context associated with the participant(s) may be updated during the transition process to reflect the change of task configuration, which can be done before being transferred to the target AMES (step 7), after the update of task configuration (step 8), or both. The updates can be performed by the source AMES, target AMES, AMEC(s), C- AMES or a combination of them. The following actions may be taken by the target AMES and / or AMEC(s) in updating the task context:

[0077] The action may include updating the current AMES identifier, previous AMES, future AMES. The action may include updating task configuration information. The action may include updating task status: which is elaborated hereinafter.

[0078] The action may include updating output context. As the participant(s) move to a new service area or associates with a new AMES, the output context may be updated, which may affect how the task output is reported or processed. The reporting and processing of task output for a transitioned participant is elaborated in the following section. The action may include updating other task context information (as shown in Table 2) as needed.

[0079] Step 10: After the transition, the target AMES may manage the task execution on the participant(s) and maintain AIML task context for the participant(s). If needed, the target AMES may forward task configuration and / or task context (e g. task input, task output) between the source AMES and the AMEC(s). For example, if the transitioned participant is collaborating with another participant (in the previous edge service area) associated with the source AMES to perform split learning, the target AMES may assist the transfer of task input / output from the other participant to the transitioned participant, or assist the transfer of task input / output from the transitioned participant to the other participant.

[0080] Step 11 : The AMEC(s) may send task report(s) (including task output and other information in the task context) to the target AMES and the target AMES may process the task reports received from managed participants. The target AMES may communicate with the source AMES or other AMESs that have previously managed the AMEC(s) / participant(s) when processing the task reports.

[0081] For participants which has been previously associated with another AMES, the target AMES may determine whether the results from the participants should be merged / aggregated to the task results generated by local participants or forwarded to another AMES (previous AMES or the AMES which has generated a high-level task configuration). Details of the management of task reporting are elaborated in the following section.

[0082] The above steps may be performed iteratively or in a different order than shown in the figure.

[0083] The transition may be a result of non-mobility events. For example, an E-AMES is shut down for maintenance and a backup E-AMES takes over the management. The abovedescribed procedure may still be applicable. The source AMES may transfer any taskconfiguration and context information it is maintaining to the target AMES (i.e., backup E- AMES).Task Status Management

[0084] Depending on the task configuration, the status of an AIML task on a participant may remain active or be paused / terminated during a transition event.

[0085] Scenario 1: continuous task execution: In this scenario, the task operations may be performed on the participant continuously without pausing or terminating, regardless of the changing of edge service area or AMES. Figure 4 shows an example of this scenario.

[0086] For example, a participant in a FL task has downloaded model parameters from the source AMES and collected training data to update the model parameters before the transition. The participant may perform FL training locally during the transition. Since the local training process does not require communication with the AMES, the AIML operation will not be interrupted by the transition. After the transition, the updated model parameters may be uploaded to the target AMES. In this case, the task status in the context may remain “active”. Note that the participant may indicate in the task context that the model is updated with data sourced from an edge service area different from the current one.

[0087] In another example, a participant of split inferencing task has downloaded a partial model from the source AMES, and is performing inferencing with local data. The generated results will be reported (to AMES) in batch when all the inference data has been processed. The participant may continue to perform inferencing during the transition, and upload the results after arriving in the new area and connecting with the target AMES. Note that the participant may indicate in the task context where the data used for inferencing is sourced since the data may be from different edge service areas and may affect the inferencing results.

[0088] To ensure the task can remain active during transition, the AMES may specify the schedule of operations to avoid disruption of task when configuring the task. For example, the AMES may obtain predictive information of the participant’s movement behavior and predict the timing of the transition (or obtain such information from the EEL or other service enablement layer functions). For AIML operations that require communication with the AMES, the AMES may schedule such operations to be performed outside the time period w hen a transition may happen. For AIML operations that do not require communication with the AMES, the AMES may schedule such operations to be performed during the transition period.

[0089] Scenario 2: pausing a task: In this scenario, the task on a participant may be paused during the transition. Figure 5 shows an example of this scenario.

[0090] For example, the participant is about to upload output of AIML operations to the AMES when the transition is triggered. The upload requires continuous connection with the same AMES for a certain period of time and should not be interrupted. Therefore, the task on the participant can be paused and resumed after the participant connects to the target AMES. The source AMES may configure the AMEC to pause the task during the transition (in “task continuity policies”), or notify the AMEC to pause the task at the beginning of the transition.

[0091] Scenario 3: terminating a task: In this scenario, the task on the participant may be terminated when transition is triggered. Figure 6 shows an example of this scenario.

[0092] The source AMES may notify the AMEC to terminate the task at the beginning of the transition, or configure the AMEC to terminate the task when transition is triggered, or configure the AMEC to terminate the task after completing any ongoing AIML operations. The E-AMES may further specify in the configuration whether the AMEC should discard any task outputs associated wi th the terminated task, or upload the outputs to the target AMES after the participant connects with the target AMES. The operation may be restarted after the transition.

[0093] The task may be completely terminated if the participant is no longer eligible or the results generated by the participant is no longer valid after the transition. In this case, the unfinished task may be sent to a replacement participant, which is elaborated in a later section.Task Output Management

[0094] To support AIML task continuity, AMESs and / or AMECs may update task context to associate task outputs with the correct (edge) service area or AMES. For example, when a participant moves to a new edge service area, the participant may be still performing AIML operations based on data or task input that is only applicable to the previous edge service area. The corresponding task output may specify such information to associate the output with the correct / applicable service area or AMES.

[0095] For example, the task context of a participant in FL task may specify the edge service area or the E-AMES associated with the training data, based on which the model is trained / updated. The information may be used by the AMES when aggregating the results (updated model parameters), such as whether the results of a transitioned participant shouldbe associated with the source or target edge area, or to determine the aggregation weight to be assigned to the results.

[0096] In another example, the participant may collect training data in the previous edge area and perform training on the collected data after transitioning to the new area. The training results (AIML task output) are reported to the E-AMES in the new area, and the E- AMES may determine to merge the results with local participants’ reports if the data patterns (as indicated by AIML task output in the task context) from the transitioned participant are similar to the local ones. Otherwise, the training results can be sent to the previous E-AMES.

[0097] In another example, a participant may be performing a split learning task where the first half of a ML model is hosted on the participant and the rest of the model hosted on the E-AMES or other participant(s) in the same edge service area. When the participant transitions to a new area, the results generated by the participant may be based on the ML model from the previous area, therefore such information may be indicated in the task context (task output). Based on this information, the target AMES may forward the task results to the source AMES to continue the AIML operations with the rest of the ML model.

[0098] Figure 7 shows a general procedure for managing and reporting the AIML task output from a transitioned participant. Note that the numbering of the steps may not represent the order of performing such steps.

[0099] Step 1 : After transition, the AMEC of a participant may report the task output to the AMES that is currently managing the participant (the target AMES in the transition). The task output may be generated before, during, or after the transition, thus it may have different validity or applicability than the task output reported by a non-transitioned participant managed by the AMES.

[0100] Step 2: In order to determine how to process the output reported by a transitioned participant, the AMES may request additional information from one or more AMESs that are previously managing the transitioned participant. For example, information of the operations that was completed before the transition may be maintained at a previous AMES and may not be transferred to the current AMES. If such information is needed, the current AMES may send a request to the previous AMES to retrieve the information. The current AMES may identify the one or more pervious AMESs which it may need to contact based on the “previous AMES” information in the task context. The current AMES may retrieve context information associated with the output (if it has not been included in the output context) fromthe previous AMESs or other entities. For example, if location information of where an operation was performed (before transition) has not been recorded in the output context, the current AMES may identify the corresponding AMES and obtain the location information (e.g. service area information of the identified AMES).

[0101] Step 3: Based on the task context and information retrieved from the previous AMES(s), the current AMES may determine how to process the task output reported by the transitioned participant, such as whether the output should be associated with or processed by the current AMES or a previous AMES. For example, the task output may be generated based on data collected from a previous edge service area, which may be indicated in the “output context” in the task context. The current AMES may compare the characteristics (e.g. distribution, pattern) of the data with that of the current edge service area. If there is no dissimilarity, then the task output may be processed at the current AMES. Otherwise, the task output may be sent to the previous AMES to be processed. Alternatively, the task request and / or task configuration may specify which entity should process the task output for the transitioned participant.

[0102] Depending on which entity should process the task output, the following cases may apply:

[0103] Case 1 : If the task output needs to be processed by a previous AMES, then step 4 to step 6 may follow. If the task output needs to be processed by more than one previous AMES, then step 4 to step 6 may be repeated for each previous AMES.

[0104] Case 2: If the task output needs to be processed by the current AMES, then step 7 to step 9 may follow.

[0105] A combination of case 1 and case 2 may be performed if the task output needs to be processed by both the current AMES and at least one previous AMES.

[0106] Step 4: If the current AMES determines that the task output reported by the transitioned participant needs to be processed by a previous AMES associated with the participant, it may forward the task output (task context) to the previous AMES. The current AMES may also forward the task output to a previous AMES as requested by the AMEC / parti cipant. For example, the AMEC is configured to send the task output to an AMES which is no longer accessible (e.g. a previous AMES in a different edge service area), the AMEC may request the current AMES to forward the task output to the desired target.

[0107] Step 5: After receiving the forwarded task output, the previous AMES may process the output. For example, the task output may be used as the input for another task to be performed by the previous AMES or another participant managed by the previous AMES. In another example, the previous AMES may merge the task output of the transitioned participant with the outputs from the local participants. The processed task output may be sent back to the AMES from which the report was forwarded.

[0108] Step 6: The previous AMES may report the processed output to the notification target.

[0109] Step 7: If the current AMES determines that the task output reported by the transitioned participant needs to be processed by the current AMES, it may request additional task output from one or more previous AMESs. For example, the AMEC may have uploaded part of the task output to a previous AMES and the output has not been transferred to the current AMES. The current AMES may also retrieve context information associated with the output (if it has not been included in the output context) from the previous AMESs or other entities. The current AMES may request the previous AMES(s) to send the task output associated with the transitioned participant to the current AMES.

[0110] Step 8: The current AMES may process the task output, such as merging the output of the transitioned participant with the outputs from the other local participants. The AMES may add an indicator to the output generated by the transitioned participant that the output is associated with a different (edge) service area than the current AMES.

[0111] Step 9: The current AMES may report the processed output to the notification target.Transition Between Participants

[0112] An AIML task participant may withdraw from a task or become unable / disqualified to perform the assigned task due to a transition or changes of its capability / availability. In this case, the managing AMES may find another participant (which may be the AMES itself) to replace the withdrawing participant. The task context associated with the withdrawing participant may be transferred to and / or associated with the replacement participant.

[0113] Figure 8 shows a general procedure for managing the transition from a withdrawing participant to a replacement participant. Note that the numbering of the steps may not represent the order of performing such steps.

[0114] Step 1 : The AMES may identify that a participant is withdrawing from a task. The AMES may be receiving a message from the AMEC indicating the participant is withdrawing. Alternatively, the AMES may determine the participant is no longer qualified for the task based on updated information of the participant (received from the participant or another AMES), and send a notification to the AMEC that the participant may withdraw^ from the task.

[0115] Step 2: The AMES may identify’ a participant to replace the withdrawing participant and complete the task assigned to the withdrawing participant. The replacement participant may also be specified by the withdrawing participant (e.g. indicated in the message sent from the AMEC in step 1).

[0116] Step 3: The AMES may determine the task configuration for the replacement participant and send a configuration request to the AMEC associated with the replacement participant. The task configuration may be the same as the one sent to the withdrawing participant (e.g. if the task needs to be restarted at the replacement participant). Alternatively, the AMES may subtract operations that have been completed by the withdrawing participant from the “required AIML operations” and only include the remaining task / operations in the task configuration for the replacement participant.

[0117] Step 4: If there is task context information that is maintained only at the AMEC, then the AMES may send a request to the AMEC of the w ithdraw ing participant to retrieve the task context. Alternatively, the AMES may request the AMEC to send the task context directly to the replacement participant if the withdrawing participant is capable of doing so.

[0118] Step 5a: According to the task configuration (e.g. “task continuity policies” may require the AMEC to transfer locally maintained task context to the AMES when transition is triggered) or upon receiving a context transfer request from the AMES (step 4), the AMEC of the withdrawing participant may transfer task context to the AMES.

[0119] Step 5b: The AMES may create or request the AMEC of the replacement participant to create a task context. The task context for the replacement participant may be generated based on the context of the withdrawing participant. The AMES may forward the task context received from the withdrawing participant to the replacement participant or update the task context for the replacement participant with the information of the task context from the w ithdrawing participant.

[0120] Step 5c: If the withdrawing participant is capable of directly communicating with the replacement participant, the AMEC of the withdrawing participant may send the task context to the replacement participant.

[0121] Step 6: The AMES may send a notification message to the notification target (e.g. AIML task requestor) indicating the change of participant.

[0122] Step 7: The AMES may manage the task execution on the replacement participant.

[0123] Step 8: As the replacement participant continues to complete the assigned task, the AMES may receive task output from the replacement participant.

[0124] Step 9: The AMES may process the task output received from the replacement participant. For example, the AMEC may combine the output generated by the replacement participant and the output previously generated by the withdrawing participant.

[0125] Step 10: The AMES may report the processed output to the notification target.When reporting, the AMES may specify which part of the output is generated / originated from which participant.

[0126] The transition between participants may also be performed on an AIML operation level. For example, a participant may fail to perform one operation in the task and a replacement participant may be found to perform the failed operation while the rest operations in the task are still performed by the original participant. It can be appreciated by those skilled in the art that the above-described task-level transition procedure may apply to the operation-level transition.GUI

[0127] Figure 9 shows an example graphical user interface that may be exposed to an AIML task requestor to configure an AIML task request including AIML task continuity support. Particularly, the GUI may provide the ability to specify' a list of task continuity policies for the AME service.Example Communications System

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0186] Provided herein are abbreviations for terms found within the body of the disclosure.

Claims

What is claimed:

1. A method performed by a first edge server in a first edge area, the method comprising: sending an artificial intelligence / machine learning (AIML) task configuration to a task participant in the first edge area; receiving task output from the task participant; determining the task participant has moved to a second edge area; and sending task context to a second edge server in the second edge area, wherein the task context comprises at least a portion of the task output received from the task participant.

2. The method of claim 1, wherein the task configuration comprises instructions to the task participant to pause the AIML task when the participant is moving to a different edge area.

3. The method of claim 1, wherein the task context comprises status information of the AIML task.

4. The method of claim 1, wherein the task context comprises an identifier of the first edge server.

5. The method of claim 1, wherein the task context comprises an identifier of a third edge server that configured the task participant.

6. The method of claim 1, wherein the task context comprises applicability information of the task output.

7. The method of claim 1, further comprising receiving additional task output generated by the task participant and from the second edge server.

8. An apparatus comprising a first edge server in a first edge area, the apparatus further comprising: one or more processors;memory: and a set of instructions stored in the memory' that, when executed by the one or more processors, cause: sending an artificial intelligence / machine learning (AIML) task configuration to a task participant in the first edge area; receiving task output from the task participant; determining the task participant has moved to a second edge area; and sending task context to a second edge server in the second edge area, wherein the task context comprises at least a portion of the task output received from the task participant.

9. The apparatus of claim 8, wherein the task configuration comprises instructions to the task participant to pause the AIML task when the participant is moving to a different edge area.

10. The apparatus of claim 8, wherein the task context comprises status information of the AIML task.

11. The apparatus of claim 8, wherein the task context comprises an identifier of the first edge server.

12. The apparatus of claim 8, wherein the task context comprises an identifier of a third edge server that configured the task participant.

13. The apparatus of claim 8, wherein the task context comprises applicability information of the task output.

14. The apparatus of claim 8, further comprising receiving additional task output generated by the task participant and from the second edge server.

15. A non-transitoiy, computer-readable medium comprising a set of computerexecutable instructions that, when executed by one or more processors, cause:sending, by a first edge server in a first edge area, an artificial intelligence / machine learning (AIML) task configuration to a task participant in the first edge area; receiving task output from the task participant; determining the task participant has moved to a second edge area; and sending task context to a second edge server in the second edge area, wherein the task context comprises at least a portion of the task output received from the task participant.

16. The non-transitory. computer-readable medium of claim 15. wherein the task configuration comprises instructions to the task participant to pause the AIML task when the participant is moving to a different edge area.

17. The non-transitory. computer-readable medium of claim 15, wherein the task context comprises status information of the AIML task.

18. The non-transitory, computer-readable medium of claim 15. wherein the task context comprises an identifier of the first edge server.

19. The non-transitory, computer-readable medium of claim 15, wherein the task context comprises an identifier of a third edge server that configured the task participant.

20. The non-transitory. computer-readable medium of claim 15, wherein the task context comprises applicability information of the task output.

Images