Edge-aware AIML enabler service for distributed and split learning

Abstract

Methods are described herein for an edge-aware AIML enabler service to support distributed or splitting AIML tasks. An AIML task for distributed or split learning may be distributed to multiple participants (e.g., servers or devices) where each of the participant performs a portion of the required AIML operations. An application acting as an AIML task requestor may offload the management of the participants to an AIML enabler service. When the AIML task participants are using services in edge data networks (EDNs), the AIML enabler services may be enhanced to support edge-aware AIML task distribution and aggregation. The edge-aware AIML enabler service may support the following features: AIML task participant and EDN information collection and aggregation; edge-aware AIML task distribution and configuration; edge-aware AIML task execution management; and edge-aware AIML task reporting and aggregation.

Description

EDGE- AW ARE AIML ENABLER SERVICE FOR DISTRIBUTED AND SPLIT LEARNINGCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 575.366, filed April 5, 2024, which is hereby incorporated by reference in its entirety.BACKGROUND

[0002] An artificial intelligence / machine learning (AIML) task may be distributed to multiple entities where each entity performs a portion of the operations. Accordingly, there is a need for improved coordination and management of the AIML operations to ensure seamless learning.SUMMARY

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

[0004] Methods are described herein for an edge-aware AIML enabler service to support distributed or splitting AIML tasks. An AIML task for distributed or split learning may be distributed to multiple participants (e.g. servers or devices) where each of the participant performs a portion of the required AIML operations. As a result, coordination and management of the AIML operation is required to ensure seamless learning. An application acting as an AIML task requestor may offload the management of the participants to an AIML enabler sendee. Such service may be provided using servers hosted in the cloud, in edge deployments, or both. When the AIML task participants are using services in edge data networks (EDNs), the AIML enabler services may be enhanced to support edge-aware AIML task distribution and aggregation. The edge-aware AIML enabler sen ice may support the following features: AIML task participant and EDN information collection and aggregation; edge-aware AIMLtask distribution and configuration; edge-aware AIML task execution management; and edge- aware AIML task reporting and aggregation.BRIEF DESCRIPTION OF THE DRAWINGS

[0005] In order to facilitate a more robust understanding of the application, reference is now made to the accompanying drawings, in which like elements are referenced with like numerals. These drawings should not be construed to limit the application and are intended only to be illustrative.

[0006] FIG. 1 is a system diagram of an example machine-to-machine (M2M), Internet of Things (loT), or Web of Things (WoT) communication system in which one or more disclosed embodiments may be implemented;

[0007] FIG. 2 is a system diagram of an example architecture that may be used within the M2M / IoT / W oT communications system illustrated in FIG. 1 ;

[0008] FIG. 3 is a system diagram of an example communication network node, such as an M2M / IoT / WoT device, gateway, or server that may be used within the communications system illustrated in FIGs. 1 and 2;

[0009] FIG. 4 is a block diagram of an example computing system in which a node of the communication system of FIG. 1 and 2 may be embodied;

[0010] FIG. 5 shows an example ML Workflow;

[0011] FIG. 6 shows an example of split learning (inferencing);

[0012] FIG. 7 shows an example edge enabler layer architecture;

[0013] FIG. 8 show s an example AIML enabler service as standalone service;

[0014] FIG. 9 shows an example AIML enabler service as part / enhancement of EEL;

[0015] FIG. 10 shows an example overview of edge-aware AIML enabler service;

[0016] FIG. 11 show s an example of participant aggregation;

[0017] FIG. 12 shows an example of participant augmentation;

[0018] FIG. 13 shows an example of AIML task request and distribution;

[0019] FIG. 14 shows an example of management of AIML operations;

[0020] FIG. 15 show s an example of task reporting and aggregation; and

[0021] FIG. 16 shows an example graphical user interface.DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

[0022] Methods are described herein for an edge-aware AIML enabler service to support distributed or splitting AIML tasks.

[0023] The following abbreviations and definitions are described herein:Table 1 - AbbreviationsTable 2 - Terms

[0024] FIG. 1 is a diagram of an example machine-to machine (M2M), Internet of Things (loT), or Web of Things (WoT) communication system 100 in which one or more disclosed embodiments may be implemented. Generally, M2M technologies provide building blocks for the I0T / W0T, and any M2M device, M2M gateway, M2M server, or M2M service platform may be a component or node of the IOT / WOT as well as an IOT / WOT Service Layer, etc. Any of the client, proxy, or server devices illustrated in any of FIGs. 5-16 may comprise anode of a communication system, such as the ones illustrated in FIGs. 5-16.

[0025] The service layer may be a functional layer within a network service architecture. Service layers are typically situated above the application protocol layer such as HTTP, CoAP or MQTT and provide value added services to client applications. The service layer also provides an interface to core networks at a lower resource layer, such as for example, a control layer and transport / access layer. The service layer supports multiple categories of (service) capabilities or functionalities including a service definition, service runtime enablement, policy management, access control, and service clustering. Recently, several industry standards bodies, e.g., oneM2M, have been developing M2M service layers to address the challenges associated with the integration of M2M types of devices and applications into deployments such as the Intemet / Web, cellular, enterprise, and home networks. A M2M service layer can provide applications and / or various devices with access to a collection of or a set of the above mentioned capabilities or functionalities, supported by the service layer, which can be referred to as a CSE or SCL. A few examples include but are not limited to security, charging, data management, device management, discovery, provisioning, andconnectivity management which can be commonly used by various applications. These capabilities or functionalities are made available to such various applications via APIs which make use of message formats, resource structures and resource representations defined by the M2M service layer. The CSE or SCL is a functional entity that may be implemented by hardware and / or software and that provides (service) capabilities or functionalities exposed to various applications and / or devices (i.e., functional interfaces between such functional entities) in order for them to use such capabilities or functionalities.

[0026] As shown in FIG. I, the M2M / I0T / W0T communication system 100 includes a communication network 12. The communication network 12 may be a fixed network (e.g., Ethernet, Fiber, ISDN, PLC, or the like) or a wireless network (e.g., WLAN, cellular, or the like) or a network of heterogeneous networks. For example, the communication network 12 may be comprised of multiple access networks that provide content such as voice, data, video, messaging, broadcast, or the like to multiple users. For example, the communication network 12 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), and the like. Further, the communication network 12 may comprise other networks such as a core network, the Internet, a sensor network, an industrial control network, a personal area network, a fused personal network, a satellite network, a home network, or an enterprise network for example.

[0027] As shown in FIG. 1, the M2M / IOT / WOT communication system 100 may include the Infrastructure Domain and the Field Domain. The Infrastructure Domain refers to the network side of the end-to-end M2M deployment, and the Field Domain refers to the area networks, usually behind an M2M gateway. The Field Domain and Infrastructure Domain may both comprise a variety' of different nodes (e.g., serv ers, gateways, device, and the like) of the network. For example, the Field Domain may include M2M gateways 14 and devices 18. It will be appreciated that any number of M2M gateway devices 14 and M2M devices 18 may be included in the M2M / IoT / WoT communication system 100 as desired. Each of the M2M gatew ay devices 14 and M2M devices 18 are configured to transmit and receive signals, using communications circuitry, via the communication network 12 or direct radio link. A M2M gateway 14 allows wireless M2M devices (e.g.. cellular and non-cellular) as well as fixed network M2M devices (e g., PLC) to communicate either through operator networks, such as the communication network 12 or direct radio link. For example, the M2M devices 18 maycollect data and send the data, via the communication network 12 or direct radio link, to an M2M application 20 or other M2M devices 18. The M2M devices 18 may also receive data from the M2M application 20 or an M2M device 18. Further, data and signals may be sent to and received from the M2M application 20 via an M2M Service Layer 22, as described below. M2M devices 18 and gateways 14 may communicate via various networks including, cellular, WLAN, WPAN (e.g., Zigbee, 6L0WPAN, Bluetooth), direct radio link, and wireline for example. Exemplary M2M devices include, but are not limited to, tablets, smart phones, medical devices, temperature and weather monitors, connected cars, smart meters, game consoles, personal digital assistants, health and fitness monitors, lights, thermostats, appliances, garage doors and other actuator-based devices, security devices, and smart outlets.

[0028] Referring to FIG. 2, the example architecture 200 shows an M2M Sendee Layer 22 in the field domain provides services for the M2M application 20, M2M gateways 14, and M2M devices 18 and the communication network 12. It will be understood that the M2M Service Layer 22 may communicate with any number of M2M applications, M2M gateways 14, M2M devices 18, and communication networks 12 as desired. The M2M Service Layer 22 may be implemented by one or more nodes of the network, which may comprise servers, computers, devices, or the like. The M2M Service Layer 22 provides service capabilities that apply to M2M devices 18, M2M gateways 14, and M2M applications 20. The functions of the M2M Se ice Layer 22 may be implemented in a variety of ways, for example as a web server, in the cellular core network, in the cloud, etc.

[0029] Similar to the illustrated M2M Service Layer 22, there is the M2M Sen ice Layer 22’ in the Infrastructure Domain. M2M Service Layer 22’ provides services for the M2M application 20’ and the underlying communication network 12 in the infrastructure domain. M2M Service Layer 22’ also provides services for the M2M gateways 14 and M2M devices 18 in the field domain. It will be understood that the M2M Service Layer 22’ may communicate with any number of M2M applications, M2M gateways and M2M devices. The M2M Sendee Layer 22’ may interact with a Service Layer by a different service provider. The M2M Service Layer 22’ may be implemented by one or more nodes of the network, which may comprise servers, computers, devices, virtual machines (e.g., cloud computing / storage farms, etc.) or the like.

[0030] Referring also to FIG. 2, the M2M Service Layers 22 and 22’ provide a core set of sendee delivery capabilities that diverse applications and verticals may leverage. Theseservice capabilities enable M2M applications 20 and 20’ to interact with devices and perform functions such as data collection, data analysis, device management, security, billing, service / device discovery, etc. Essentially, these service capabilities free the applications of the burden of implementing these functionalities, thus simplifying application development and reducing cost and time to market. The Service Layers 22 and 22’ also enable M2M applications 20 and 20’ to communicate through various networks such as network 12 in connection with the services that the Service Layers 22 and 22’ provide.

[0031] The M2M applications 20 and 20’ may include applications in various industries such as, without limitation, transportation, health and wellness, connected home, energy management, asset tracking, and security and surveillance. As mentioned above, the M2M Service Layer, running across the devices, gateways, servers and other nodes of the system, supports functions such as, for example, data collection, device management, security, billing, location tracking / geofencing, device / service discovery’, and legacy systems integration, and provides these functions as sendees to the M2M applications 20 and 20’.

[0032] Generally, a Service Layer, such as the Service Layers 22 and 22’ illustrated in FIG. 2, defines a software middleware layer that supports value-added service capabilities through a set of Application Programming Interfaces (APIs) and underlying networking interfaces. Both the ETSI M2M and oneM2M architectures define a Service Layer. ETSI M2M’s Service Layer is referred to as the Service Capability’ Layer (SCL). The SCL may be implemented in a variety of different nodes of the ETSI M2M architecture. For example, an instance of the Service Layer may be implemented within an M2M device (where it is referred to as a device SCL (DSCL)), a gateway (where it is referred to as a gateway SCL (GSCL)) and / or a network node (where it is referred to as a network SCL (NSCL)). The oneM2M Service Layer supports a set of Common Service Functions (CSFs) (i.e., service capabilities). An instantiation of a set of one or more particular types of CSFs is referred to as a Common Services Entity (CSE) which may be hosted on different types of network nodes (e.g., infrastructure node, middle node, application-specific node). The Third Generation Partnership Project (3GPP) has also defined an architecture for machine-ty pe communications (MTC). In that architecture, the Service Layer, and the service capabilities it provides, are implemented as part of a Service Capability Server (SCS). Whether embodied in a DSCL. GSCL. or NSCL of the ETSI M2M architecture, in a Service Capability Server (SCS) of the 3GPP MTC architecture, in a CSF or CSE of the oneM2M architecture, or in some other node of a network,an instance of the Service Layer may be implemented as a logical entity (e.g., software, computer-executable instructions, and the like) executing either on one or more standalone nodes in the network, including servers, computers, and other computing devices or nodes, or as part of one or more existing nodes. As an example, an instance of a Service Layer or component thereof may be implemented in the form of software running on a network node (e.g., sen' er, computer, gateway, device or the like) having the general architecture illustrated in FIG. 3 or FIG. 4 described below.

[0033] Further, the methods and functionalities described herein may be implemented as part of an M2M network that uses a Sendee Oriented Architecture (SOA) and / or a Resource- Oriented Architecture (ROA) to access services.

[0034] FIG. 3 is a block diagram of an example hardware / software architecture 300 of a node of a network, such as one of the clients, servers, or proxies illustrated in FIGs. 5-16, which may operate as an M2M server, gateway, device, or other node in an M2M network such as that illustrated in FIGs. 5-16. As shown in FIG. 3, the node 30 may include a processor 32, non-removable memory 44, removable memory 46. a speaker / microphone 38, a keypad 40, a display, touchpad, and / or indicators 42, a power source 48, a global positioning system (GPS) chipset 50, and other peripherals 52. The node 30 may also include communication circuitry, such as a transceiver 34 and a transmit / receive element 36. It will be appreciated that the node 30 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment. This node may be a node that implements the methods described herein, e.g., in relation to the methods described in reference to FIGs. 5-16 or the data structures of FIGs. 5-16, the Tables, or in a claim.

[0035] The processor 32 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. In general, the processor 32 may execute computer-executable instructions stored in the memory (e.g., memory’ 44 and / or memory 46) of the node in order to perform the various required functions of the node. For example, the processor 32 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the node 30 to operate in a wireless or wired environment. The processor 32 may runapplication-layer programs (e.g., browsers) and / or radio access-layer (RAN) programs and / or other communications programs. The processor 32 may also perform security' operations such as authentication, security key agreement, and / or cryptographic operations, such as at the access-layer and / or application layer for example.

[0036] As shown in FIG. 3, the processor 32 is coupled to its communication circuitry (e.g., transceiver 34 and transmit / receive element 36). The processor 32, through the execution of computer executable instructions, may control the communication circuitry in order to cause the node 30 to communicate with other nodes via the network to which it is connected. In particular, the processor 32 may control the communication circuitry in order to perform the methods described herein, e.g., in relation to FIGs. 5-16, or in a claim. While FIG. 3 depicts the processor 32 and the transceiver 34 as separate components, it will be appreciated that the processor 32 and the transceiver 34 may be integrated together in an electronic package or chip.

[0037] The transmit / receive element 36 may be configured to transmit signals to, or receive signals from, other nodes, including M2M servers, gateways, device, and the like. For example, in an embodiment, the transmit / receive element 36 may be an antenna configured to transmit and / or receive RF signals. The transmit / receive element 36 may support various networks and air interfaces, such as WLAN, WPAN, cellular, and the like. In an embodiment, the transmit / receive element 36 may be an emitter / detector configured to transmit and / or receive IR, UV, or visible light signals, for example. In yet another embodiment, the transmit / receive element 36 may be configured to transmit and receive both RF and light signals. It will be appreciated that the transmit / receive element 36 may be configured to transmit and / or receive any combination of wireless or wired signals.

[0038] In addition, although the transmit / receive element 36 is depicted in FIG. 3 as a single element, the node 30 may include any number of transmit / receive elements 36. More specifically, the node 30 may employ MIMO technology. Thus, in an embodiment, the node 30 may include two or more transmit / receive elements 36 (e.g., multiple antennas) for transmitting and receiving wireless signals.

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

[0040] The processor 32 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 44 and / or the removable memory 46. For example, the processor 32 may store session context in its memory, as described above. The non-removable memory 44 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 46 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 32 may access information from, and store data in, memory that is not physically located on the node 30. such as on a server or a home computer. The processor 32 may be configured to control lighting patterns, images, or colors on the display or indicators 42.

[0041] The processor 32 may receive power from the power source 48, and may be configured to distribute and / or control the power to the other components in the node 30. The power source 48 may be any suitable device for powering the node 30. For example, the power source 48 may include one or more dry' cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn). nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like.

[0042] The processor 32 may also be coupled to the GPS chipset 50, which is configured to provide location information (e.g., longitude and latitude) regarding the current location of the node 30. It will be appreciated that the node 30 may acquire location information by w ay of any suitable location-determination method while remaining consistent with an embodiment.

[0043] The processor 32 may further be coupled to other peripherals 52, witich 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 52 may include various sensors such as an accelerometer, biometrics (e.g., finger print) sensors, an e- compass, a satellite transceiver, a sensor, 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.

[0044] The node 30 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, amedical or eHealth device, a robot, industrial equipment, a drone, a vehicle such as a car, truck, train, or airplane. The node 30 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 52.

[0045] FIG. 4 is a block diagram of an exemplary computing system 400 which may also be used to implement one or more nodes of a network, such as the clients, servers, or proxies illustrated in FIGs. 5-16, which may operate as an M2M server, gateway, device, or other node in an M2M network such as that illustrated in FIGs. 5-16.

[0046] Computing system 400 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, such as central processing unit (CPU) 91, to cause computing system 400 to do work. In many known workstations, servers, and personal computers, central processing unit 91 is implemented by a single-chip CPU called a microprocessor. In other machines, the central processing unit 91 may comprise multiple processors. Coprocessor 81 is an optional processor, distinct from main CPU 91, that performs additional functions or assists CPU 91. CPU 91 and / or coprocessor 81 may receive, generate, and process data related to the disclosed systems and methods for E2E M2M Service Layer sessions, such as receiving session credentials or authenticating based on session credentials.

[0047] In operation, CPU 91 fetches, decodes, and executes instructions, and transfers information to and from other resources via the computer’s main data-transfer path, system bus 80. Such a system bus connects the components in computing system 400 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 intermpts and for operating the system bus. An example of such a system bus 80 is the PCI (Peripheral Component Interconnect) bus.

[0048] Memories coupled to system bus 80 include random access memory (RAM) 82 and read only memory (ROM) 93. Such memories include circuitry that allows information to be stored and retrieved. ROMs 93 generally contain stored data that cannot easily be modified. Data stored in RAM 82 may be read or changed by CPU 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 virtualaddresses 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.

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

[0050] Display 86, which is controlled by display controller 96, is used to display visual output generated by computing system 400. Such visual output may include text, graphics, animated graphics, and video. 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.

[0051] Further, computing system 400 may contain communication circuitry, such as for example a network adaptor 97, that may be used to connect computing system 400 to an external communications network, such as network 12 of FIGs. 1-4, to enable the computing system 400 to communicate with other nodes of the network.

[0052] 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 includes operations such as determination of ML requirements, data collection, data preparation, model building / training, model evaluation, model deployment, monitoring and update, etc.

[0053] FIG. 5 shows an example machine learning workflow 500. Distributed learning and federated learning: Distributed learning leverages parallelization of computing power to train a single model on multiple entities (servers or devices / UEs). Each entity' may train a portion of the model (model parallelism) or train the model with a portion of the training data (data parallelism). Particularly, federated learning (FL) enables multiple devices (clients) to collaboratively train a model while ensuring data privacy (as opposed to centrally stored data as in distributed learning). A cloud server may maintain a global model by aggregating local model parameters partially trained by each device.

[0054] Split leaming / inferencing: An AIML operation or model can be split into multiple parts according to the task and environment. Each part of the AIML operation may be performed by different devices or entities.

[0055] FIG. 6 shows an example of split learning 600. The ML model (a convolutional neural network) may be split into two parts according to the AIML task. The intention may be to offload the computation-intensive, energy intensive parts to the network server, whereas leave the privacy -sensitive and delay-sensitive parts at the end device. The device executes the inference up to a specific model layer and sends the intermediate data to the network server. The network server runs through the remaining model layers.

[0056] 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 [1],

[0057] FIG. 7 shows the Edge Application Enabler Layer (EEL) architecture 700 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, UE ACs may be able to locate and connect with the most suitable EASs available within the Edge Data Networks (EDNs) that the UEs are located in. This may be dependent on the needs of the ACs and the availability of EASs in edge data networks. 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).

[0058] Some of the services include:

[0059] Sendees for discovery of ECSs and provisioning of edge computing services based on a UEs location and service requirements;

[0060] Sendees for registration of EECs to EESs and EASs to EESs;

[0061] Sendees for providing continuity of service between ACs and EASs (e.g., when a UE moves from one EDN to another EDN); and

[0062] Exposure of 5GC services for use by EASs.

[0063] An AIML task (e.g. distributed learning / inferencing, or split learning / inferencing) may be distributed to multiple entities (servers or devices / UEs) where each entity performs a portion of the required AIML operations. As a result, coordination and management of the AIML operation may be required to ensure seamless learning. An application acting as an AIML task requestor may offload the management of the participant devices / UEs to an AIML enabler service hosted by a central / cloud server. General-purpose applications may employ AIML functionality by leveraging specialized AIML task support, especially when the tasks are distributed to multiple servers or devices / UEs. Such support may be provided by an AIML enabler service, using servers hosted in the cloud, in edge deployments, or both. When participants are using application services in different EDNs, AIML enabler sendees need to be enhanced to support edge-aware AIML task distribution and aggregation.

[0064] An edge-aware AIML enabler service to support distributed and split AIML tasks is described herein, which support the following features:

[0065] Participant and EDN information collection and aggregation;

[0066] Edge-aware AIML task distribution and configuration;

[0067] Edge-aware AIML task execution management; and

[0068] Edge-aware AIML task reporting and aggregation.

[0069] A method for an AMES to:

[0070] Receive and maintain information of an AIML task participant and the corresponding edge data network,

[0071] wherein the information may include capabilities of the participant, supported operations, availability of the participant, access policy, AIML data information, service KPIs, associated applications, energy' information, collaboration support, etc.

[0072] wherein the information may be received from the AMEC associated with the participant, or an AMES, or an EEL entity, etc.

[0073] wherein the AMES may aggregate multiple participants that support collaboration.

[0074] wherein the AMES may augment a participant with additional capabilities or resources provided by the AME service.

[0075] wherein an E-AMES may aggregate the information of participants within its edge service area and send to the C-AMES.

[0076] wherein the received information is exposed to an AIML task requestor.

[0077] wherein the information of the AIML task participant and the edge data network may be predictive information.

[0078] Receive an AIML task request from a requestor,

[0079] wherein the requestor may be an application server hosted in the cloud or one the edge, or application client hosted on one of the participants.

[0080] wherein the request may include required AIML operations to be performed by the participants, required schedule of the operations, requirements of the operations, input data and information for the operations, required output of the operations, task reporting requirements, operation scripts, containerized operations, etc.

[0081] wherein the request may be received by an AMEC and forwarded to an AMES.

[0082] Determine an AIML task configuration for an AIML task participant and send a task configuration request to the participant,

[0083] wherein the task configuration may be in a hierarchical structure consisting of per-edge task configurations and per-client task configurations.

[0084] wherein the task configuration may be determined by splitting / distributing the AIML task into multiple per-edge task configurations, each consisting of a subset / portion of the required operations in the AIML task request to be performed by the participants in an edge sendee area associated with an E-AMES.

[0085] wherein the task configuration may be determined by splitting / distributing the per-edge task configuration into multiple per-client task configurations, each consisting of a subset / portion of the required operations in the per-edge task configuration to be performed by a participant.

[0086] wherein the task configuration may be determined based on the information of the participants and EDNs.

[0087] wherein the task configuration may specify instructions of performing the required AIML operations, including where / how to obtain the input data / information for each operation and where / how to send / report the output data / information for each operation.

[0088] wherein the task configuration may be determined for an aggregated or augmented participant and then split / distributed into each participant.

[0089] Receive and maintain AIML task context for each AIML ask participant,

[0090] wherein the task context may include task and operation status, task and operation progress, task output, context information of the output, etc.

[0091] wherein the AMES may instruct the AMEC to activate, pause or terminate the task on the participant by updating the task status in the task context.

[0092] wherein the AMES may forward the task output from one participant to another.

[0093] wherein the AMES may update the task configuration based on the task context.

[0094] Send a report consisting of AIML task outputs to the notification target,

[0095] wherein the reported task output is generated by the E-AMES aggregating task outputs reported by the participants within the corresponding edge service area.

[0096] wherein the reported task output is generated by the C-AMES aggregating task outputs reported by the E-AMESs associated with one or more edge service areas.

[0097] wherein the reported task output is generated based on the operation context associated with the outputs.

[0098] A method for an AMEC to:

[0099] Send information of the associated participant to an AMES,

[0100] wherein the information may include capabilities of the participant, supported operations, availability7of the participant, access policy, AIML data information, service KPIs, associated applications, energy information, collaboration support, etc.

[0101] Receive an AIML task request from a requestor,

[0102] wherein the request is forwarded to an AMES that is managing the AMEC.

[0103] wherein the request may include information as described above (in the AMES method).

[0104] Receive a per-client task configuration from an AMES,

[0105] wherein the task configuration may include information as described above (in the AMES method).

[0106] Receive and maintain AIML task context associated with a per-client task configuration,

[0107] wherein the task context may include information as described above (in the AMES method)

[0108] wherein the AMEC may update the AIML task context based on the status of the task performed by the participant and the output generated by the participant.

[0109] Receive operation input from the managing AMES and send operation output to the managing AMES,

[0110] wherein the operation input may be forwarded by the AMES from the participant performing the preceding operation.

[0111] wherein the operation output may be forwarded by the AMES to the participant performing the succeeding operation.

[0112] Send a report consisting of AIML task outputs and the corresponding context information to the managing AMES.

[0113] An AIML task consists of a set of AIML operations to be performed by one or more entities (e.g. servers, 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. For example, an AIML task can be defined to train an image recognition model in a federated learning manner with devices / UEs spread across a certain geographical area. In another example, an AIML task can be defined to perform inferencing with a large ML model based on data collected by a device / UE where the model is partially hosted on the device / UE and partially hosted on an edge or central / cloud server. An AIML task participant is an entity that participates (or w ill participate) in an AIML task by performing the required AIML operations as indicated by the task. The participant may be a device / UE or a server hosted on the cloud or the edge. Particularly, a device / UE may participate in the AIML task as a participant device / UE. A person having ordinary skill in the art may be able to apply the procedures for a participant device / UE defined in this paper to other types of participants.

[0114] 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 participants, distribution of AIML tasks to participants, collection and / or aggregation of data, information, outputs / results from participants, reporting to task requestors or notification targets, etc. An AIML enabler sendee 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 edge service area. The AIML enabler servers may communicate with and manage the participants directly, or via AIML enabler clients (AMECs) hosted on the participants. Particularly, a participant device / UE, aparticipant cloud server, a participant edge server may be managed via D-AMEC, C-AMEC, E-AMEC, respectively. An E-AMES and an E-AMEC may be the same edge server or colocated on the same edge server.

[0115] FIG. 8 shows an E-AMES implemented as a standalone functional entity in an application enablement layer 800. In this case the E-AMES may leverage the services provided by the edge enabler layer (EEL) as an edge application server (EAS).

[0116] FIG. 9 shows an E-AMES implemented as an enhancement to the EEL service provided by an edge enabler server (EES) 900. In such cases, the northbound 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 (not shown in the figure), such as SEAL, AD AES, etc. Similarly, E-AMES services may be implemented within the application requesting the AIML task.

[0117] FIG. 10 shows an example procedure performed by the AIML enabler sendee and the relevant entities. Note that the numbering of the steps may not represent the order of performing such steps.

[0118] At step 1, AIML enabler servers (including C-AMES and E-AMESs) may collect (and aggregate) information of participants that may participate in AIML tasks, such as their capabilities and availability. Information of locations where the participants are located may also be collected by the AMESs or obtained from a location service. Information of the participants and locations may be collected from the AMECs associated with the participants and the EEL. The participant and location information may be collected and / or updated before and during the execution of AIML tasks. The information may be reported to the AIML task requestor (or notification target), and / or be used to determine or update the task distribution among the participants.

[0119] At step 2, the C-AMES may receive an AIML task request from a requestor, such as an application server. The C-AMES may determine the appropriate edge service areas or EDN(s) (and hence one or more E-AMES) to manage the AIML task and distributes peredge task configurations to each E-AMES. Each E-AMES may further determine the per-client task configurations and distribute to each participant via the corresponding AMEC. The task configurations may be determined based on the task request and the collected participant and EDN information. The task configurations may specify information of the required AIMLoperations to be performed by the participants, as well as instructions on how to report the task outputs. The AMES may determine the task configurations for different types of participants and distribute the task to them accordingly.

[0120] At step 3, the E-AMESs may manage the participants via the corresponding AMECs to execute the AIML tasks. Participants that are without EDN coverage or suitable E- AMES may be managed by the C-AMES. A task context may be generated for each participant to track the status and output of the task, which may be maintained by the AIML enabler serv ice (including the C-AMES, E-AMES and the AMEC). The AMESs may update the task configurations dynamically based on the updated participant and location information and the task contexts.

[0121] At step 4, The AMECs associated with participants may report task status or outputs to the AMESs. The AMESs may aggregate the reports and send the information to the notification target or share with other AMESs.

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

[0123] The AIML enabler service may collect information of participants distributed in different edge sen-ice areas that may potentially participate in AIML tasks. The collected information may be discovered by or sent to AIML task requestors, and / or used by the AIML enabler servers to determine the configuration of AIML tasks to be distributed to the participants. The AIML enabler service may also collect information of other types of participants (such as cloud or edge servers) as well as information of the network and EDN(s) where the participants are located in. The information may be collected before receiving an AIML task, after receiving an AIML task but before distributing the task to participants, or after the task is distributed to participants. The E-AMES and C-AMES may continue to receive and update participant and EDN information after the initial collection.

[0124] Table 3 shows example information of an AIML task participant that can be collected for AIML task purposes. The AIML enabler service may generate an AIML task participant profile to maintain the information.Table 3. AIML task participant information (profile)

[0125] Table 4 shows example information of an edge service area or an EDN associated with an E-AMES that can be collected for AIML task purposes.Table 4. Edge service area or EDN information

[0126] The E-AMES may receive information of a participant device / UE from the corresponding D-AMEC. or receive information of a participant edge server from the corresponding E-AMEC. The participant information that can be sent from the AMEC to the E-AMES may include: participant’s capability in supporting AIML tasks (e.g. compute,storage, energy ), participant's availability in performing AIML tasks (e.g. device / UE / server’s schedule, available period), information of data that is available or will be available at the participant which can be used for AIML tasks, application user information, list of associated applications available at the participant, types of supported or authorized AIML models, workloads or tasks permitted to run on the device / UE, and other information as shown in Table 1.

[0127] The information can be sent to the E-AMES from the AMEC via a registration procedure. For example, the AMEC may register to the E-AMES and include participant information in the registration message. The AMEC may also send (updated) information to the E-AMES with a registration update request. Alternatively, the participant information may be requested or retrieved by the E-AMES. For example, the E-AMES may receive a participant / AMEC discovery request from the C-AMES. which may trigger the E- AMES to request or retrieve participant information from the AMEC. The information can be sent to the E-AMES individually (e.g. as an AMEC profile, or participant profile), or it can be contained or partially contained in another message sent from the AMEC to the E-AMES.

[0128] The E-AMES may also receive information of a participant device / UE or participant EAS from an EES associated with the participant. For example, when the EEC associated with the participant device / UE or the participant EAS registers (or updates registration) with the EES, information of the participant UE / EAS can be included in the registration message and shared with the EES. The information may be then shared to the E- AMES by the EES (e.g. via information exposure procedure).

[0129] The E-AMES may also receive information of the associated edge service area or EDN. The EDN information may include: data network name of the EDN, data network access identifier, service area, identifier of the associated EES and ECS. statistics or prediction related to the edge performance / load for the edge platform or EES / EAS in the edge sendee area, and other information as shown in Table 2.

[0130] Note that the information collection at E-AMES may consist of collection of predictive values in addition to or instead of the types of data detailed so far. The collection may include data provided based on user consent or may be derived from other available data via anonymization.

[0131] The E-AMES may send / forward information about the participants within its managed / associated edge sendee area to the C-AMES. The E-AMES may send theparticipant information to the C-AMES as it may be (e.g. as individual AMEC or participant profile), or process / aggregate the information before sending to the C-AMES. The processed / aggregated information may include: total / sum of participant capabilities in the edge service area, maximum / minimum participant capability in the edge service area, average participant capability, common / overlapping availability period of participants, application user information, list of associated applications available at the device / UE, etc. Alternatively, the processing and aggregation can be performed by the C-AMES after receiving the information from one or more E-AMESs. The aggregation can be performed over participants of a certain ty pe within a certain edge sendee area, or across multiple edge sen ice areas.

[0132] The information can be sent to the C-AMES from the E-AMES via a registration procedure. For example, the E-AMES may register to the C-AMES and include participant information in the registration message. The E-AMES may also send (updated) participant information to the C-AMES with a registration update request. Alternatively, the participant information may be requested or retrieved by the C-AMES. For example, the C- AMES may receive a request from the AIML task requestor to discover participants to perform an AIML task, which may trigger the E-AMES to request or retrieve participant information from the corresponding E-AMES(s). The information can be sent to the C-AMES individually (e.g. as an E-AMES profile, or AMEC profiles, or participant profiles), or it can be contained or partially contained in another message sent from the E-AMES to the C-AMES.

[0133] The C-AMES may also receive information of participant devices / UEs from an EES or ECS associated with the participant. For example, when the EEC associated with the device / UE sends a provisioning request to the ECS, information of the device / UE can be included in the request message and shared with the ECS, and further shared to the C-AMES by the ECS. In another example, when the EES associated with the device / UE(s) registers (or updates registration) with the ECS. information of the devices / UEs can be included in the registration message and shared with the ECS. The information may be then shared to the C- AMES by the ECS.

[0134] The C-AMES may also receive information of the participants without the assistance of an E-AMES. For example, the C-AMES may receive information of a participant from the D-AMEC directly, or receive information of a participant cloud server from the C- AMEC or the associated enabler server.

[0135] Note that the information collection at C-AMES may consist of a collection of predictive values in addition to or instead of the ty pes of data detailed so far. The collection may include data provided based on user consent or may be derived from other available data via anonymization.

[0136] FIG. 1 1 shows an example of participant aggregation 1100.

[0137] FIG. 12 shows an example of participant augmentation 1200.

[0138] The AMES may aggregate or augment participant information (profile) for participants with collaboration support. The aggregation can be performed by combining the participant information of multiple participants that are capable of collaborating with each other (as shown in FIG. 11), while the augmentation can be performed by complementing / supplementing the capabilities of a participant with capabilities or resources external to the participant, such as capabilities provided by the AMES (as shown in FIG. 12).

[0139] The AMES may aggregate multiple participants into a collective aggregated participant to support performing a split AIML task that each participant UE contributes to. For example, there may be participant devices / UEs with limited availability' where some of them are available only during the daytime and the others are available only during the nighttime. Such participants may not be selected for certain AIML tasks that require constant operations throughout the day as their availabilities may not satisfy the requirement. However, the AMES may combine participant devices / UEs with different availabilities to generate an aggregated participant (if they support collaboration with each other), which ill combine their availabilities as to support AIML operations throughout the day. The aggregated participant, which may be the combination of tw o or more participant devices / UEs, may be exposed to an AIML task requestor and discovered / selected by the requestor as a whole with extended available period.

[0140] In another example, participants with limited computation or storage capability may not be able to host or perform AIML operation for an entire ML model. Such participants may7be excluded from AIML tasks requiring large models. Ho ever, if such a participant supports split learning, then the AMES may augment its capabilities by supplementing capabilities that can be provided by the AMES so that the participant may only need to handle a portion of the ML model and offload the rest of the task to the AMES. The augmented participant information can be exposed to AIML task requestors so that the participant with limited capabilities may be able to contribute to AIML tasks w ith large models.

[0141] The procedures defined for an AIML task participant throughout this disclosure may also be applicable to an aggregated or augmented participant.

[0142] Based on the information of participants that has been collected by the AIML enabler service, the participants of an AIML task can be selected by either the task requestor or the AIML enabler service (C-AMES or E-AMES). The AIML task can be split and distributed to the selected participants, e.g. to support distributed or split AIML leaming / inferencing. The AIML task requestor may offload the management of task participants and the coordination of task execution to the AIML enabler service by sending an AIML task request to the C-AMES and / or E-AMES. The AIML task may then be distributed to the participants by the AIML enabler service. The C-AMES may determine a per-edge task configuration for each edge service area and send the configuration to the corresponding E- AMES. The C / E-AMES may determine a per-client task configuration for each participant (e.g. devices / UEs, servers) and send the configuration to the AMEC associated with the participant.

[0143] FIG. 13 illustrates an example AIML task request and distribution 1300. An AIML task of distributed or split learning may be composed of a list of various AIML operations that need to be performed by multiple participants. The AIML task request and task configurations provide information about what AIML operation should be performed by each participant and how to perform the operation.

[0144] Table 5 shows example information of an AIML operation. An AIML operation may be defined at various levels of granularity, which may be a general step in the AIML workflow (e.g. data collection, data preparation, training), or a specific step / procedure (e.g. data normalization, model evaluation, model aggregation). The AIML operation information may be provided by the requestor, and / or it may be specified / updated by the AMES when configuring the tasks.Table 5. AIML operation information

[0145] The C-AMES may receive one or more AIML task requests from the requestor. The requests may include:Table 6. AIML task request

[0146] The AIML task request may be received by the C-AMES from an application server in the cloud. The request may be received directly from the application server or via the C-AMEC associated with the application server. The AIML task request may also be received by the E-AMES from an application server on the edge network (EAS). The request may be received directly from an edge application server or via the E-AMEC associated with the edge application server. If the task can be completed within the current edge service area or edge network, then the E-AMES may determine the per-client task configurations. If the task needs to be completed with participants outside the cunent edge service area or edge network, then the E-AMES may forward the request to the C-AMES or another E-AMES. The AIML task request may also be received by the AMEC from an application client on the device / UE. The AMEC may forw ard the request to the corresponding E-AMES or the C-AMES.

[0147] In the AIML task request, the requestor may not specify all the required participants or specify the required AIML operation for each specific participant. For example, the requestor may require AIML operations of data collection and training a model based on the collected data, but does not specify which participant will be performing data collection, or which participant will be performing model training. Moreover, a single AIML operation may be performed on multiple participants in parallel (e.g. training operation in federated / distributed learning) or successively (e g. split inferencing). The requestor may onlyspecify the AIML operation to be performed but not specify how to distribute or split the operation to multiple participants. In these cases, the AIML enabler service may assist the distribution or splitting of AIML tasks and operations, as described in the following sections.

[0148] The AIML task requestor may not request for an AIML task with the entire or complete workflow. For example, the requestor may request the AME service for managing data processing procedure only, or request for managing the deployment and monitoring of a ML model that has already been trained, etc.

[0149] The C-AMES may generate a task configuration based on the AIML task request, which specifies the required actions to be performed by the AIML enabler service, including C-AMES, E-AMESs and AMECs (for participant UEs and cloud servers). The task requestor may not specify all the required AIML participants, or the operations to be performed by each specific participant, in which case the AIML enabler service may determine such information based on the other information provided in the task request and on information of participants and EDNs.

[0150] The C-AMES may split the AIML task and determine the per-edge task configuration for each E-AMES that will participate in the task based on the AIML task request and the collected information of participants and EDNs. For example, if the AIML task is required to be completed within a given time limit, the C-AMES may set higher participant capability requirement (e.g. faster computing speed) for the edge service area with network congestion to offset the longer communication latency.

[0151] An AIML task may need to be completed jointly by participants managed by E-AMES (e g. devices / UEs in EDN, EAS) and participants that are not managed by any E- AMES (e.g. cloud application server, devices / UEs managed by C-AMES). In this case, the C- AMES may split the task and determine the per-edge task configuration for the E-AMES as well as the configurations for the rest of the participants.

[0152] The C-AMES may send one or more per-edge task configuration requests to each E-AMES. The task configuration request(s) may include information of the per-edge task configuration (Table 7) and other information that the C-AMES receives in the AIML task request.Table 7. Per-edge task configuration information

[0153] After receiving the per-edge task configuration, the E-AMES may further split the per-edge task and determine the task configuration for each participant in the edge service area. The E-AMES may determine the per-client task configuration for each D-AMEC (device / UE) based on the per-edge task configuration and the collected information of participants and EDNs. For example, the E-AMES may configure participants with lower computation or storage capability7to perform a smaller portion of split learning task while the rest of the task can be completed by a participant server, the E-AMES. or another more capable participant. For the participants that are not managed by an E-AMES, the C-AMES may determine the task configuration for the participant.

[0154] For participants with collaboration capability7or for aggregated / augmented participants, the E-AMES or C-AMES may first determine the task configuration for the aggregated / augmented participant and then determine the task splitting or distribution for each individual / original participant. For example, for an aggregated participant which consist of multiple participants, the AMES may determine the per-client task configuration for each of the participant based on their individual capability7information. For an augmented participant where the AMES supplements a participant’s capability with AMES’s capability, the AMES may determine the portion of AIML operations to be performed by the participant and assign the remaining operations to the AMES (itself or another AMES).

[0155] The E-AMES may send one or more per-client task configuration requests to the AMEC associated with each participant. Alternatively, the C-AMES may generate per- client configuration request(s) and send it directly to a participant which may be in an area without EDN coverage or in an area in which a suitable E-AMES is not present or available.

[0156] The per-client task configuration request(s) may include information of the per-client task configuration (Table 8) and other information that the E-AMES receives in the per-edge task configuration request.Table 8. Per-client task configuration information

[0157] If a participant is not found in any edge service area or network or there is no suitable E-AMES associated with the participant, the C-AMES may determine the per-client task configuration for the participant and send the configuration request to the corresponding AMEC directly.

[0158] In addition to devices / UEs and AMESs, a server such as a cloud application server, edge application server, and other application enablement layer server (e.g. EES, SEAL server) may also participate in the AIML task by performing AIML operations such as data collection, training, inference, etc. Participant servers may be configured in a similar way as the participant devices / UEs where the AMES may send per-client task configuration requests to the corresponding AMECs (e.g. C-AMEC, E-AMEC). A person having ordinary skill in the art may be able to apply the above procedures to any participant serv er.

[0159] The task configurations can be generated in an online manner as the task progresses. For example, the AMESs may specify the AIML operations for the current time window (e.g. hour by hour, day by day, which may be specified in the operation schedule), and continue to specify' the next AIML operations for the next time window when the current time window' expires. In another example, the AMESs may specify the AIML operations for a certain set of participants, and continue to configure another set of participants after the first set of participants completed their tasks (as the second set of participants may take the task outputs from the first set of participants as inputs).

[0160] The AMES may trigger edge server instantiation when distributing or configuring the AIML task to provide additional resources or capabilities to support the AIML task. The newly instantiated server may be an E-AMES or an edge application server (as a participant). For example, an E-AMES may augment the capabilities of the participants withinit edge service area by supplementing additional capabilities from the E-AMES. The E-AMES may receive per-edge task configuration(s) that requires support from multiple augmented participants. In this case, the E-AMES may need to supplement multiple participants with AIML capabilities, which may exceed the E-AMES ’s capability. The E-AMES may trigger or request the instantiation of additional edge servers (e.g. E-AMES) to provide the required capability. If additional E-AMES is instantiated, the new E-AMES may also assist the original E-AMES with the management of participants in the edge service area.

[0161] After configuration, the participants may perform the required AIML operations. The C-AMES and / or E-AMES may monitor the participants and track the progress of the AIML operations by creating and maintaining task context for the participants. Task context may include information as shown in Table 9.Table 9. AIML task context

[0162] In an example, a cloud server may receive information associated with a plurality of artificial intelligence / machine learning (AIML) task participants. The plurality of AIML task participants may be located in a plurality of edge service areas. The information may indicates one or more capabilities of each AIML task participant of the plurality of AIML task participants. The cloud server may receive, from a requestor, an AIML task request. The cloud server may determine, based on the AIML task request and the information associated with the plurality of AIML task participants, an AIML task configuration. The AIML task configuration may comprise a task configuration for each edge service area of the plurality of edge service areas. The cloud server may send, to at least one AIML task participant, of the plurality of AIML task participants in each edge service area, and based on the determined AIML task configuration, a task configuration request. The cloud server may receive, from the at least one AIML task participant in each edge service area, AIML task output information. The cloud server may send, to the requestor, a notification comprising aggregated AIML task output information.

[0163] FIG. 14 shows an example procedure 1400 in which the C / E-AMES may direct the input and output of the AIML operations between the participants to assist theexecution of successive operations in the AIML workflow. Note that the steps may be performed in an order different than the one shown in the figure.

[0164] At step 1, the C / E-AMES (which is managing the participant) may send a (per-client) task configuration request to the AMEC associated with the participant, specifying the required AIML operations to be performed by the participant (as shown in Table 1 and Table 6). In the configuration request, the C / E-AMES may specify' where to obtain the operation input (e.g. identifier / address of the C / E-AMES, identifier / address of the preceding participant) and / or where to send the operation output (e.g. identifier / address of the C / E- AMES, identifier / address of the succeeding participant) for each required operation. Note the C / E-AMES may send individual task configuration requests to multiple participants to achieve the requirements of the AIML task, e.g. as part of distributive, federated, or split AIML model operations.

[0165] At step 2, the AMEC may send a (per-client) task configuration response to the C / E-AMES indicating the participant accepts (or declines) the task configuration and possibly include an expected completion time (e.g. by specifying “operation schedule’' for the required AIML operation in the task configuration). The C / E-AMES may use the expected completion time to schedule a succeeding participant to continue the AIML task upon the completion of the operation by the current participant.

[0166] At step 3, the C-AMES, E-AMES and / or the AMEC may maintain task context for each participant to track the progress of AIML task execution on the participant. The task context can be created by the AMEC or the C / E-AMES managing the AMEC, and a task context creation request may be integrated in the task configuration request or response. The task context may include information shown in Table 7.

[0167] At step 4, for each AIML operation, the C / E-AMES may assist the transfer of operation output from a preceding participant (which is also the operation input for the current participant) to the current participant. The AMEC may receive or retrieve the operation output directly from the preceding participant (if the preceding participant was configured to do so). Alternatively, the E / C-AMES may forward the operation output from the preceding participant to the AMEC.

[0168] At step 5, the task context may be updated as the participant performs the required AIML operations. The task context can be viewed as part of participant information and shared between AMEC, E-AMES, C-AMES and the task requestor (as described in theParticipant and EDN information collection procedures). The E-AMES and C-AMES may process or aggregate the task contexts of the participants before sharing with the other entities. For example, task contexts of participants within an edge service area may be aggregated to reflect the per-edge task progress, and further aggregated to reflect the overall task status (which can be reported to the task requestor).

[0169] At step 6, after (or during) performing the required AIML operation, the C / E- AMES may assist the transfer of operation output from the participant to a succeeding participant. The AMEC may transfer the operation output directly to the succeeding participant (as specified in the operation output). Alternatively, the E / C-AMES may forward the operation output from the AMEC to the succeeding participant. Step 4 to 6 may be repeated for each required AIML operation.

[0170] At step 7, after the participant completes all the required AIML operations, the task output (which may be the operation output of the last-step AIML operation) may be transferred from the participant to the C / E-AMES or the designated target.

[0171] The C-AMES and / or E-AMESs may dynamically update different levels of task configurations and the task contexts according to the status of participants and EDNs. This updating may comprise one or more requests exchanged between the C-AMES, E-AMESs and / or AMECs. The requests may comprise one or more updated information elements such as but not limited to the aforementioned information elements.

[0172] The C-AMES may update the per-edge task configuration according to the status of the EDNs. For example, if the load of the EES associated with an edge service area or edge network is predicted to significantly increase during the next hour, the C-AMES may update the per-edge task configuration to reduce the required number of participants from that area and increase the number for the other areas.

[0173] The E-AMES may update the per-client task configuration according to the status of the participants. For example, if a device / UE participating in split learning is to run a computationally intensive application with higher priority, the E-AMES may update the per- client configuration to reduce the portion of AIML operations to be performed by the device / UE and offload the operations to the other participants or the E-AMES. The AMEC may inform the AMES halfway through the task execution that the participant is no longer able to fully support the task and request the AMES to provide support (e.g. through participant aggregation or augmentation).

[0174] The AMES may update the task status in the task context to pause the task execution when re-configuring the tasks so that the re-configuration would not disrupt the task execution. In addition, the AMES may update the configuration of a lower-level task if the task context of a higher-level task has changed. For example, if a per-edge task is paused, the operation schedule of the associated per-client tasks (which are derived from this per-edge task) may be updated to accommodate the delay caused by the pause.

[0175] The AMES may update the task configuration based on the task context generated by the participant. For example, if the operation context indicates the participant is not performing well in a certain operation or task (e.g. due to overloading or poor communication quality), then the AMES may update the per-client task configuration for this participant to pause the task and resume the task when conditions get better (e.g. by receiving updated participant or EDN information). Alternatively, the AMES may terminate the task on the participant and send the remaining task to another participant by defining a new per-client task configuration (which may include the list of operations that have not been completed).

[0176] The AMEC and AMES may report task status or outputs at any time after receiving the task request based on the reporting requirements specified in the request. The report may include task status and / or task output, which may be generated based on the task context. The D-AMEC may report the status and outputs of the corresponding per-client task to the associated E-AMES or C-AMES. The E-AMES may aggregate reports from the AMECs and report to the C-AMES. The reports from different edge service areas may or may not be synchronized. The C-AMES may report to the requestor or a designated notification target. If the notification target is located in a specific edge service area that is associated with an E- AMES (e.g. the notification target is an EAS), the E-AMES may report directly to the notification target instead of the C-AMES.

[0177] Particularly, when the AIML task is completed, the AMESs may report the results (AIML task outputs) to the AIML requestor or the designated notification target according to the AIML task request and configuration. If the task request does not require any processing or aggregation performed by the AIML enabler service, the AIML task results reported by the AMECs may be forwarded / sent to the notification target without being processed by the AMES. Otherwise, the C-AMES and / or E-AMES may perform processing or aggregation on the task results.

[0178] FIG. 15 shows an example procedure 1500 for task reporting and aggregation. Note that the numbering of the steps may not represent the order of performing such steps.

[0179] At step 1, the AMEC (e.g. D-AMEC) associated with a participant may report the status and / or outputs of the assigned AIML task (e.g. per-client task) to the corresponding E-AMES (step 1-a) or C-AMES (step 1-b). The AMEC may also send the report to the AMEC of another participant (not shown in figure) as configured by the AMES in the Reporting requirements. The report may include information of the task context (Table 7). Particularly, if the participant has completed the required AIML operations as specified in the task configuration request (e.g. the task progress is 100%), the AMEC may indicate the completion of the task in the report sent to the AMES with the final task results (which may be included in the operation output). For AIML tasks that require iterative operations, the participant may report the completion of one round and reset the progress of the operations to start a new round. Alternatively, the E / C-AMES may update the per-client task configuration to instruct the participant to start the next round of operation after receiving the report indicating the completion of one round.

[0180] At step 2, the E-AMES may aggregate and process the task reports received from AMECs and other AMESs. The E-AMES may combine the reports from multiple participants that are in the same per-edge task and generate / update the task context for the peredge task. Particularly, the task outputs may be aggregated by the E-AMES based on the task request / configuration and the operation context. For example, the E-AMES may assign different aggregation weights to the outputs according to the corresponding training / inferencing performance of each participant. The E-AMES may also process the outputs such as to apply filter criteria and remove invalid outputs based on the operation context.

[0181] At step 3, the E-AMES associated with an edge service area may report the status and / or outputs of the per-edge task to the C-AMES (step 3-a). The E-AMES may also send the status and / or outputs of one or more per-client tasks or per-edge task to another E- AMES (step 3-c) or the C-AMES. The report may include information of the per-edge task context or per-client task context (Table 7). The reporting procedure between E-AMESs can also be performed via the C-AMES. If the notification target is located in a specific edge servicearea where an E-AMES is available (e.g. an edge server or a device / UE in the edge sendee area), the E-AMES may directly report to the notification target (step 3-b).

[0182] At step 4, the C-AMES may aggregate and process the task reports from E- AMESs and AMECs. The processing or aggregation may be performed based on the task request and the task context associated with the results, such as which area the participant is located. For example, task results from different areas may be assigned different weights for aggregation, which may be specified in the task request (AIML task input and required AIML operations). The C-AMES may determine which weight should be applied to the results when aggregating the results.

[0183] At step 5, the C-AMES may report the status and / or outputs of the AIML task to the notification target. If the notification target is located in a specific edge service area where an E-AMES is available (e.g. an edge server or a device / UE in the edge service area), the C-AMES may report to the E-AMES (not shown in figure) and the E-AMES may forward the report to the notification target.

[0184] FIG. 16 shows an example graphical user interface (GUI) 1600 that may be exposed to an AIML task requestor to configure an AIML task request. The GUI may provide the ability to specify a list of AIML operations to be performed in the task and the corresponding requirements, a list of AIML task participants required for the task or for each AIML operation, requirements regarding the reporting of task outputs and results, etc.

Claims

What is claimed:

1. An apparatus comprising one or more processors and memory storing instructions which, when executed by the one or more processors, cause the apparatus to: receive information associated with a plurality of artificial intelligence / machine learning (AIML) task participants located in a plurality of edge service areas, wherein the information indicates one or more capabilities of each AIML task participant of the plurality of AIML task participants; receive, from a requestor, an AIML task request; determine, based on the AIML task request and the information associated with the plurality of AIML task participants, an AIML task configuration, wherein the AIML task configuration comprises a task configuration for each edge service area of the plurality of edge service areas; send, to at least one AIML task participant, of the plurality7of AIML task participants in each edge service area, and based on the determined AIML task configuration, a task configuration request; receive, from the at least one AIML task participant in each edge service area, AIML task output information; and send, to the requestor, a notification comprising aggregated AIML task output information.

2. The apparatus of claim 1, wherein the at least one AIML task participant is an edge server.

3. The apparatus of claim 1, wherein the at least one AIML task participant is a device.

4. The apparatus of claim 1, w herein the information associated with the plurality of AIML task participants further comprises information associated with the edge service area w here each AIML task participant, of the plurality' of AIML task participants, is located.

5. The apparatus of claim 1, wherein the AIML task request comprises a list of one or more required AIML operations.

6. The apparatus of claim 1 , wherein the task configuration for each edge service area, of the plurality of edge service areas, comprises a list of one or more required AIML operations which is a subset of AIML operations required by in the AIML task request.

7. The apparatus of claim 1, wherein the instructions, when executed by the one or more processors, further cause the apparatus to: forward the AIML task output information from one participant, of the plurality of AIML task participants, to another participant, of the plurality of AIML task participants.

8. The apparatus of claim 1, wherein the instructions, when executed by the one or more processors, further cause the apparatus to: update AIML task configuration when detecting changes in the information associated with the plurality' of AIML task participants.

9. A method comprising: receiving information associated with a plurality of artificial intelligence / machine learning (AIML) task participants located in a plurality of edge sendee areas, wherein the information indicates one or more capabilities of each AIML task participant of the plurality' of AIML task participants; receiving, from a requestor, an AIML task request; determining, based on the AIML task request and the information associated with the plurality of AIML task participants, an AIML task configuration, wherein the AIML task configuration comprises a task configuration for each edge service area of the plurality of edge service areas; sending, to at least one AIML task participant, of the plurality of AIML task participants in each edge sendee area, and based on the determined AIML task configuration, a task configuration request; receiving, from the at least one AIML task participant in each edge service area, AIML task output information; and sending, to the requestor, a notification comprising aggregated AIML task output information.

10. The method of claim 9, wherein the at least one AIML task participant is an edge server.

11. The method of claim 9, wherein the at least one AIML task participant is a device.

12. The method of claim 9. wherein the information associated with the plurality of AIML task participants further comprises information associated with the edge service area where each AIML task participant, of the plurality of AIML task participants, is located.

13. The method of claim 9, wherein the AIML task request comprises a list of one or more required AIML operations.

14. The method of claim 9, wherein the task configuration for each edge sendee area, of the plurality of edge service areas, comprises a list of one or more required AIML operations which is a subset of AIML operations required by in the AIML task request.

15. The method of claim 9, further comprising: forwarding the AIML task output information from one participant, of the plurality of AIML task participants, to another participant, of the plurality of AIML task participants.

16. The method of claim 9, further comprising: updating AIML task configuration when detecting changes in the information associated with the plurality of AIML task participants.

17. An apparatus comprising one or more processors and memory storing instructions which, when executed by the one or more processors, cause the apparatus to: send, to a cloud server, information indicating one or more capabilities for an AIML; receive, based on the AIML task request and the information, a task configuration request, wherein the task configuration request is associated with an edge service area of a plurality of edge service areas; andsend, to the cloud server, AIML task output information to cause aggregation of AIML task output information by the cloud server.

18. The apparatus of claim 17, wherein the apparatus is an edge server.

19. The apparatus of claim 17, wherein the apparatus a device.

20. The apparatus of claim 17. wherein the information further comprises information associated with the edge service area where the apparatus is located.

Images