Method to enable federated learning deployment service

Abstract

Systems and methods for implementing federated learning deployment services are disclosed, including receiving a message containing deployment configuration information of a trained ML model, wherein the deployment configuration information includes a strategy for retraining the trained ML model. A request to deploy the trained ML model at a first group of client devices can be sent, and a request to receive a response containing deployment information associated with the deployment of the trained ML model can be sent. A response including deployment information can be received from at least one of the first group of client devices. Based on one or more strategies for retraining the ML model and the received deployment information, a determination to trigger retraining of the ML model can be made. The method may include sending a request to retrain the ML model to a second group of client devices.

Description

[0001] Cross-references to related applications This application claims the benefit of U.S. Patent Application No. 63 / 589,83, filed on October 12, 2023. Background Technology

[0002] Currently, existing federated learning (FL) service frameworks have limited capability sets and only provide basic services to assist in training machine learning (ML) models in a federated manner. The available functionality level is suitable for proof-of-concept level implementations. However, FL frameworks currently lack the key functionalities required for large-scale deployment and management of FL-based systems in commercial settings. For FL to become a mainstream technology, these FL service frameworks must first be enhanced with additional capabilities to alleviate complexity and improve the robustness of FL, making the technology and its deployment feasible. Summary of the Invention

[0003] This summary provides a simplified overview of the concept choices further described in the following detailed description. This summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to addressing any or all of the shortcomings noted in any part of this disclosure.

[0004] This disclosure generally defines deployment-centric capabilities for federated learning (FL) services, enabling FL deployment services to be deployed on systems requiring high levels of scalability and robustness. This disclosure defines functions that enable FL deployment services to: receive FL deployment configurations from FL users; process and manage the deployment of ML models on behalf of FL users via interaction with FL clients; and update FL users with the state of the deployment process while the ML models are being used by FL clients.

[0005] This disclosure specifically describes an FL deployment service capable of: 1) receiving messages from FL users including one or more types of FL deployment configuration information; 2) performing one or more operations based on the received deployment configuration information; 3) sending messages of deployment configuration information including one or more types of information to FL clients; 4) receiving messages of deployment reports including one or more types of information from FL clients; 5) determining, based on information received from FL clients, whether to trigger model retraining and perform one or more operations; 6) sending messages to FL users including one or more types of information; and 7) sending messages to FL clients containing updated deployment configuration information including one or more types of information. Attached Figure Description

[0006] Figure 1An example system is shown.

[0007] Figure 2 An example system is shown.

[0008] Figure 3 An example system is shown.

[0009] Figure 4 An example method is shown.

[0010] Figure 5 An example method is shown.

[0011] Figure 6 An example method is shown.

[0012] Figure 7 An example method is shown.

[0013] Figure 8 An example system is shown.

[0014] Figure 9 An example system is shown.

[0015] Figure 10 An example system is shown.

[0016] Figure 11A An example communication system is shown.

[0017] Figure 11B An example device configured for wireless communication is shown.

[0018] Figure 11C An example system is shown.

[0019] Figure 11D An example system is shown.

[0020] Figure 11E An example system is shown.

[0021] Figure 11F An example system is shown.

[0022] Figure 11G An example system is shown. Detailed Implementation

[0023] This article describes methods and apparatus for implementing federated learning deployment services.

[0024] This article may use the following abbreviations: API Application Programming Interface CPU Central Processing Unit EDA Exploratory data analysis FL Collaborative learning GUI Graphical User Interface JSON JavaScript object representation ML Machine Learning YAML Yet another markup language

[0025] The following definitions may be used in this article: Federation learning users (FL users) are user devices (e.g., computers, smartphones, tablets) that host computing, storage, and network connectivity resources and host user application software (e.g., web browsers, apps). Users can use these applications to perform FL-centric operations using FL deployment services. For example, FL users can configure FL deployment services with FL deployment requirements, such as FL clustering and ML model selection and configuration strategies.

[0026] Federation learning client (FL client): A network device (e.g., a device, gateway, or server) that hosts computing, memory, and network connectivity resources, and is capable of hosting FL client software (e.g., an FL client application) and local data. The FL client can use the FL client software and local data to perform operations, such as training an ML model in a federated manner or performing inference using the trained ML model.

[0027] Federation-based deployment service (FL deployment service): A network device (e.g., a device, gateway, or server) that hosts compute, storage, and network connectivity resources and is able to host FL deployment service software that can perform FL management operations, such as training ML models across FL clients in a federated manner.

[0028] Federation learning training round (FL round): A training iteration performed on an ML model in a federated manner by an FL client, where training is managed by the FL deployment service.

[0029] Joint Learning Task (FL Task): A set of instructions and requirements sent by the FL Deployment Service to multiple FL clients for jointly training an ML model. The FL Deployment Service can generate FL Tasks for each round of joint training performed on the ML model. FL Tasks can be specified by the FL user or the FL Deployment Service.

[0030] Collaborative learning The rapid development and expansion of increasingly powerful smartphones, the Internet of Things (IoT), and similar devices have led to an exponential increase in the amount of data generated at the network edge. This presents new challenges to conventional cloud-based centralized data analytics methods, as their scalability or efficiency is insufficient to handle the massive amounts of data generated by numerous edge client devices. Additionally, these methods raise privacy concerns, as data collected from edge devices may be shared with third parties.

[0031] To address these challenges, federated learning (FL) has recently emerged as a frontier solution for the need for distributed solutions that protect privacy in data-driven learning and inference-based application processes, enhancing efficiency and addressing privacy concerns. FL is gaining interest in use cases such as healthcare, finance, and transportation. In FL, the training of machine learning (ML) models for data-driven applications is a collaborative effort among distributed clients, eliminating the need for centralized client data. This helps protect user privacy and improves the efficiency and scalability of data analytics. The decentralized and collaborative nature of federated learning is essentially fully aligned with the network edge, where each device can act as an independent client. Furthermore, because the raw data collected by each client / device is not shared with other clients / devices, FL provides an effective way to protect user privacy, where client devices can directly collect data including sensitive personal information.

[0032] Federation learning (FL) is a machine learning (ML) approach that enables the creation of models on data distributed across multiple clients or locations without the need for data aggregation and storage in a central location. During ML training and / or inference, an FL service manages multiple FL clients, and the data remains private and stored locally on individual FL clients. During training, one or more ML models and their associated parameters are exchanged between the FL service and the FL clients. The FL service aggregates the model parameters (e.g., weights) in each round of federated training, and FL training iterates through many rounds. This approach has become increasingly popular in recent years as more organizations seek the ability to leverage large datasets without compromising the privacy of individual users and / or data sources, while also gaining the added benefits of reduced data movement and improved scalability.

[0033] Currently, existing FL service frameworks have limited capability sets and only provide basic services to assist in training ML models in a federated manner. This level of functionality is suitable for proof-of-concept implementations. However, FL frameworks currently lack the key functionalities required for large-scale deployment and management of FL-based systems in commercial settings. For FL to become a mainstream technology, these FL service frameworks must first be enhanced with additional capabilities to alleviate complexity and improve FL's robustness, making the technology and its deployment feasible.

[0034] Before FL can be widely adopted and deployed at scale, existing FL service frameworks may need to address several challenges and shortcomings. This disclosure addresses the following challenges: 1) Variation of bandwidth (BW) availability for FL deployments at the edge: Network bandwidth available at the edge is often limited but can also be variable across FL clients. Limited and / or variable network bandwidth can make it difficult to deploy a single, one-size-fits-all "master" FL model to all clients. This is because different ML algorithms with different parameter sets, hyperparameters, and / or software dependencies may consume different levels of network resources when passing model parameters.

[0035] 2) Diversity of FL Client Data: The diversity of FL client data can present many challenges to FL. For example, clients with different data distributions may make it difficult to train a global model that is well-suited for all clients. Clients may also have different biases or different levels of noise or uncertainty in their data, which can further complicate the training of a reliable global model.

[0036] 3) Diversity of available FL client resources (also known as heterogeneity): Similar to BW availability, FL clients can exhibit a wide range of available computing resources. FL clients may have different hardware and / or software (dependencies), which can make it difficult to design FL algorithms that are equally efficient and scalable for all FL clients.

[0037] 4) Intermittent FL client connectivity and availability: FL clients may frequently disconnect from the network, or new FL clients may join / leave intermittently. This variability in FL client availability needs to be managed by a central entity.

[0038] 5) Post-deployment data dynamics (also known as drift): The data distribution on FL clients may change over time, leading to data drift. Generally, drift in ML refers to changes in data distribution over time. This can occur for a variety of reasons, such as changes in the target population, data collection methods, or data processing methods. Drift can negatively impact the performance of trained machine learning models. This is because the model is trained on a specific data distribution, and if the data distribution changes, the model may no longer be able to accurately predict outcomes. Therefore, drift can make it difficult to maintain the accuracy of FL models. Of course, an additional dimension in FL is the variety and number of clients, meaning that data from different (groups of) clients may also vary.

[0039] This invention defines deployment-centric capabilities for federated learning (FL) services, enabling FL deployment services to be deployed in systems requiring high levels of scalability and robustness. This disclosure defines functions that enable FL deployment services to: receive FL deployment configurations from FL users; process and manage the deployment of ML models on behalf of FL users via interaction with FL clients; and update FL users with the status of the deployment process while the ML models are being used by FL clients.

[0040] Specifically, this disclosure defines: FL deployment service can: 1) Receive messages from FL users that include one or more of the following types of FL deployment configuration information: a) Requirements / goals and use cases for FL deployment; b) Characteristics and typical algorithms associated with FL deployment and the outcome variables / entities to be predicted; c) A list of FL clients used for deployment, and information for each FL client, such as: i. Identifier of FL client ii. Device / Entity Type of FL Client iii. Client support roles (training, inference, or both) iv. Functionality supported at the FL client level, such as data processing / preparation, the ability to collect ground truth, and model performance measurement / evaluation. v. Information about data that is available or may be available at the FL client, such as metadata and / or statistics about the data. vi. Information on available resources and capabilities for FL deployment at the FL client, such as the status and / or scheduling of computing resources, (battery) power, memory / storage, network / communication bandwidth, mobility, etc. d) Requirements and / or filtering criteria for the model to be deployed, such as: i. Model identifier ii. Model requirements / expected performance iii. The required / preferred ML algorithm and / or hyperparameters associated with the model. e) Model usage policy, indicating when FL clients are allowed to use the deployed ML model. f) Evaluation methods or performance metrics for the deployed ML models g) Instructions to FL clients regarding what information they should track and / or report to the FL deployment service. h) Instructions regarding what information the FL deployment service should track and / or report to FL users. i) Clustering strategies for FL clients, such as when / how to perform clustering, the algorithms used to build clusters, and the criteria for clustering. j) Model retraining strategy, indicating when the FL deployment service should trigger model retraining, and what actions the FL deployment service will take when model retraining is triggered. 2) Based on the received deployment configuration information, perform one or more of the following operations: a) Perform FL client clustering based on the FL client's supporting role (willingness), data nature, device / entity nature (computing power, network resources, power constraints, mobility), or a combination thereof. b) Discovering pre-trained ML models based on model requirements and filtering criteria. c) Determine the deployment configuration for each FL client or each client cluster. 3) Send a message containing deployment configuration information to the FL client. This message includes one or more of the following types of information: a) Identifiers of the discovered pre-trained ML models to be deployed on the client. b) The identifier of the cluster to which the client belongs (and the role assigned to the client). c) Model usage strategy d) Evaluation methods or performance metrics for the deployed model e) Instructions regarding what information should be tracked and / or reported to the FL deployment service, and corresponding reporting schedules. f) An indicator indicating whether model retraining can be triggered by the client; if so, the corresponding triggering conditions and the actions the client should take when retraining is triggered. 4) Receive deployment report messages from the FL client, which include one or more of the following types of information: a) Statistical information / metadata / characteristics of the data at the FL client (used for training or inference) b) Performance evaluation of the ML model deployed to the FL client c) Using the resource or time consumption information of the ML model at the FL client. d) Deployment-related events detected at the FL client (e.g., data / model drift, resource shortage). 5) Based on the information received from the FL client, determine whether to trigger model retraining and perform one or more of the following operations: a) Determine whether model retraining should be triggered for a single FL client. b) Aggregate the information received from FL clients in FL clustering and determine whether model retraining should be triggered for FL clustering. c) Aggregate information received from more than one FL client and determine whether model retraining should be triggered. d) Determine whether the existing ML model should be retrained / updated, replaced by another pre-trained model, or replaced by a new model that has not yet been trained. e) Update the clustering of the L client. 6) Send messages to FL users, which include one or more of the following types of information: a) Aggregated information from FL clients b) Notifications that trigger model retraining and corresponding actions performed by the FL deployment service or FL client. c) Require FL users to determine whether a request to retrain the model should be triggered. d) Updated clustering information from the FL client e) Requests from FL users to update FL client clustering 7) Send a message to the FL client with updated deployment configuration information. This message includes one or more of the following types of information: a) The identifier of the updated / new ML model to be deployed on the client. b) The updated identifier of the cluster to which the client belongs (and the updated role assigned to the client). c) Requests to train / update the ML model deployed on the client. d) The updated model uses strategies, evaluation methods, reporting instructions, etc.

[0041] This disclosure defines advanced features of the FL deployment service for enabling more scalable and robust FL deployments, including FL clients with heterogeneous data and compute / networking capabilities.

[0042] FL client clustering A key aspect of this disclosure is that clusters of FL clients can be dynamically formed due to client heterogeneity during FL deployment and across multiple dimensions of FL deployment. These "clusters" can be formed via features supported by the FL deployment service to address heterogeneity such as participation agreements, data characteristics, computational and network capabilities, power constraints, mobility states, and time scheduling among different FL clients. Furthermore, separate algorithms and / or features (as in vertical FL) can be managed by the FL deployment service on a per-cluster basis. For example, in horizontal FL, selected portions of data from different clients (if applicable, within each client cluster) can complement each other during training.

[0043] To address the potential dynamic heterogeneity of FL clients, the FL Deployment Service can support multiple clustering techniques to partition FL clients into distinct clusters across one or more dimensions. For example, different ML algorithms or models may have unique requirements for data, computation, and / or network resources. Clusters with low computational resources or limited network bandwidth may be better suited for simpler, less computationally intensive models, such as logistic regression or decision trees. Conversely, clusters with high computational resources and good network connectivity may be able to handle more complex models, such as deep neural networks. Furthermore, not all clients have the resources to train models. Some clients may only be able to host models for inference purposes. In this case, the FL Deployment Service can support a hybrid approach, where some clients (typically those with more computational resources) are assigned to train models, while others are assigned to use those trained models for inference purposes. Additionally, to distribute training and inference clients as evenly as possible across clusters, the FL Deployment Service can use load balancing strategies. This strategy ensures a fair distribution of both types of clients within each cluster. Load balancing performed by the FL Deployment Service can consider various factors, such as each client's computational load, network usage, and data similarity.

[0044] FL Deployment Service may support one or more of the following FL clustering management functions: 1) Filtering clients based on participation agreements: There may be willingness identifiers that can be determined by the FL client (or by the FL client's end users or automatically by the FL client). Willing identifiers can take effect during the FL deployment initiation phase, but identifiers can also change dynamically during iterations, as described in further steps of the process flow.

[0045] 2) Filtering clients based on power and mobility: Power constraints and mobility status can help determine whether a client can operate during the FL process or for how long.

[0046] 3) Clustering Clients Based on Data Characteristics: Clusters of FL clients can be created based on data statistics, metadata, and other information related to the data of FL users and / or FL clients of interest in the current ML use case. These FL client clusters can be referred to as "data clusters" (DCs). Managing these clusters allows for the identification of ML algorithms, data preparation, and other relevant ML pipeline steps and / or components for each client within an FL cluster.

[0047] 4) Clustering clients based on computing power, network capabilities, power constraints, mobility, etc.: Computing and network capabilities can determine whether a client can be assigned to a training cluster or an inference cluster.

[0048] 5) Clustering clients based on use cases and / or client time or scheduling: For example, clusters can be formed / reformed at different times of the year based on the seasonal nature of the current use cases (sales, finance, etc.).

[0049] Figure 1 This illustrates an example of how the filtering and partitioning process is generally demonstrated by the FL Deployment Service. FL client clusters can be formed based on requirements from a specific deployment, and therefore by a specific ML model. Using these requirements, the FL Deployment Service can evaluate FL clients according to various clustering criteria, such as... Figure 1 As shown in the example, FL client cluster 1 is formed based on data characteristics, computing and network capabilities, and available scheduling for the FL deployment. On the other hand, FL client cluster 2 may require a different set of clustering criteria, primarily based on data characteristics, networking capabilities, power constraints, and location and mobility. Clustering criteria can be executed in any order, and the priority of the criteria can depend on the requirements of the FL deployment.

[0050] At the heart of any clustering mechanism is the need to align the characteristics of the data available on the FL client with the requirements of the ML model. This matching is essential to ensuring that FL deployments use data suitable for the ML model. Other clustering criteria can also be considered to ensure seamless FL deployments, such as the compute and networking capabilities of the FL client, power constraints, location and mobility, and time and scheduling availability. Note that additional clustering criteria can also be envisioned to support the wide variety of FL deployments that may be encountered.

[0051] One criterion to consider is the "willingness" of FL clients to participate in FL deployment. Some FL clients may have their willingness "off" by default, while others may change their decision on a specific (ad-hoc) basis. Therefore, client participation can be a dynamic property provided by the FL deployment service (or by FL clients and / or FL users). Clients can be filtered based on their power constraints and mobility state. The FL deployment service can take into account the client's power supply and determine which FL clients are capable of performing the required FL tasks. For example, FL clients with battery power may only be available for a limited duration, and therefore, the FL deployment service may schedule only one or two rounds of FL training, or cluster FL clients only for inference. Similar decisions can be made based on the FL client's mobility state, including the FL client's location. By analyzing the client's position, acceleration, velocity, and direction of motion, the FL server can determine whether a client can participate in the FL process and to what extent.

[0052] Figure 2The diagram illustrates a scenario where a series of filtering and clustering steps can be implemented to concretely illustrate the concepts, wherein (a) shows a sample scenario where FL client clustering occurs in a cascading manner according to data statistics and metadata, as well as computational and network capabilities, and (b) shows a detailed view of the distribution of data-based (sub)clustering to training and inference clusters in this scenario during CNC-based clustering. Figure 2 In (a), once the initial filtering based on the participation agreements, power resources, and mobility states of all clients in the network has been completed, and the participating and qualified FL clients have been identified in each iteration, a clustering process based on data statistics, which the FL deployment service can support, can begin. This process can be based solely on statistics and metadata of the FL client data. This partitioning of clients determines the type of algorithm to choose and the data preparation steps appropriate for a given client cluster. Therefore, there may be multiple “master” models for FL deployments suitable for different “data clusters” (DCs) (e.g., DC 1, DC 2, etc.).

[0053] As a final clustering step, "Computational and Network Capabilities" (CNC) clustering can be applied to clients previously placed in different data clusters. In this step, computational capabilities, such as CPU, storage, memory, and / or network bandwidth and speed, can determine the extent to which FL clients are capable of participating in FL deployment. Figure 2 In this scenario, the choice is shown as a binary decision (training and inference), but other approaches can also be followed, where different clusters can be created by the FL deployment service based on the computational capabilities of the FL clients. For example, Level 1 could specify "inference-only" clustering for FL clients with limited computational capabilities, since training typically consumes more computational resources than inference. As the computational capabilities of the FL clients increase, the level of involvement in training may also increase. FL clients at the highest computational capability level could be used solely for ML training (or for both training and inference).

[0054] Continue Figure 2 In the binary choice scenario depicted, it's important to note that computationally capable clients will be able to perform both training and inference. Since training is generally a more computationally demanding process, clients deemed capable of training will also be able to participate in the inference process. Furthermore, it's crucial to recognize that there must be a one-to-one correspondence between DCs in the training and inference clusters (as sub-clusters), and that a certain proportion of representation should be present in each cluster. Figure 2In (a), a scenario is shown where, in the training cluster, DC 1 has 100 clients, DC 2 has 80 clients, and DC N (the Nth DC) has 40 clients. In terms of the stated proportions, an ideal inference clustering configuration could involve DC 1 with 120 FL clients, DC 2 with 96 FL clients, and DC N with 48 FL clients (each DC in the inference cluster is 6 / 5 times the number of its corresponding DC in the training cluster in terms of the number of FL clients). Figure 2 (b) illustrates the distribution of DC clients during the CNC clustering process in more detail. Essentially, "strong" clients, or those more capable in computation and networking within each DC, are grouped into sub-clusters under the same DC label in the training clusters. "Weak" FL clients are similarly grouped into the inference clusters.

[0055] Therefore, it is worth emphasizing that the computational and networking capabilities of FL clients are generally independent of the characteristics of the data of interest in the ML use cases they are generating and / or storing. Thus, different “data clusters” can be proportionally distributed between training and inference clusters by the FL deployment service, so each data cluster can be represented equally in both training and inference clusters. Different sets of ML processes and entities (data preparation, cleaning, algorithms, etc.) can be used by different clients in different data clusters. For example, an ML model trained on an FL client in the training cluster (achieved through computational and networking properties) and also belonging to the sub-cluster “data cluster 1” (achieved through data properties) must be deployed to clients in the inference cluster that are also part of the same data cluster 1. This is as follows: Figure 3 As shown. The reasons are likely multifaceted. First, the inference process may include the same data transformation steps as the ML training process, which are determined by the proposed data clustering process. Furthermore, different ML algorithms can be considered suitable for the client data in different data clusters, and there must be a matching of data sub-clusters between the clients in the training and inference clusters. On the other hand, if a data sub-cluster in the training cluster cannot form in the inference cluster (or vice versa) due to the lack of clients with the same data characteristics as that FL cluster in the training / inference cluster, these clients can be excluded from the FL process. Alternatively, clients can be merged with another "similar" data cluster, which may be available in other cases and is similarly represented in each training and inference cluster.

[0056] FL Deployment Service Process The general method for deploying FL services is as follows: Figure 4 The call flow diagram is shown. This method describes an FL deployment service that manages FL client clustering during FL deployment for ML model training and inference. Note that... Figure 4 The internal clustering structure of the FL client is not shown (this can be found in...). Figure 1 , Figure 2 or Figure 3 (Find it in [the diagram]). Note that the steps and methods described may be performed in a different order than shown in the diagram.

[0057] 1) FL Deployment Service Configuration: FL users can define requirements for FL deployment. This can be anything, from disease detection to personalized recommendations based on mobile phone location. Users can also specify features and typical algorithms to achieve the goals of FL deployment. FL users can then initiate FL deployment by interacting with the FL Deployment Service (e.g., via a GUI or API) and can specify a list of FL clients. This list can be defined as FL clients within a specific deployment / cluster. This step can also involve communication between the FL Deployment Service and FL clients in the overall system regarding their willingness to participate in FL deployment, which can filter out unwanted FL clients in the system. The FL Deployment Service can also recommend which FL clients are best suited for FL deployment among those willing to participate.

[0058] One or more FL users can provide FL client information to the FL Deployment Service, allowing FL clients to be grouped into appropriate FL client clusters for model deployment. Table 1 shows examples of FL client information that can be provided by FL users to the FL Deployment Service.

[0059] Table 1 FL Client Information

[0060] One or more FL users can provide deployment configuration information to the FL deployment service, such as the requirements / preferred models to be deployed (filtering criteria for model discovery), and the triggering conditions for model retraining. Alternatively, the model discovery process can be initiated by one or more FL clients / clusters (such as those described below). Figure 5 (As described in the document). Table 2 shows an example of FL deployment configuration information that can be provided by FL users to the FL deployment service.

[0061] Table 2 FL Deployment Configuration

[0062] The FL deployment service can use information from Tables 1 and 2 to group FL clients into training and inference clusters. Depending on the available deployment configuration, the clusters can be general or specific. For example, the FL deployment service can initially group FL clients into global training and inference clusters based on received FL client information, and then form more specific training and inference sub-clusters based on model and data requirements, FL client scheduling and availability, and the FL computing power specified in the FL deployment configuration.

[0063] 2) The FL deployment service may combine assistance from the ML service and, with or without the participation of FL users, may determine / locate initial, pre-trained(one or more) FL / ML models for one or more participating FL clients. The(one or more) models may be determined based on information provided by the(one or more) FL users, such as FL client information (Table 1) and FL deployment configuration (Table 2).

[0064] 3) The initial FL / ML model can be deployed to one or more FL clients / clusters. This can initiate FL operations because, in each real-world use case, the client may expect to begin using the ML model for inference tasks immediately from the start of the process.

[0065] If step 1 does not perform FL client clustering, the FL deployment service (and / or FL users) can determine the initial clustering of FL clients based on FL client information (e.g., the client's support role). The model can then be deployed to FL clients in the inference cluster to perform the inference process and generate inference results. Alternatively, the model can be deployed to FL clients that perform both training and inference processes, where the clients can consume the model to generate inference results while simultaneously aiding in model training.

[0066] The FL Deployment Service can determine the deployment configuration for each client and send this information to the FL client when deploying the model. The per-client deployment configuration can be determined / derived based on information provided by one or more FL users, such as FL client information (Table 1) and / or FL deployment configuration (Table 2). For example, the per-client deployment configuration can send instructions to the FL client regarding what information should be tracked and reported to the FL Deployment Service, whether the FL client is allowed to trigger model retraining, etc. Deployment configurations can also be specified by cluster, and information about the configuration can be sent to FL clients within that cluster, similar to the per-client scenario.

[0067] FL Deployment Loop: Steps 4 through 10 can be performed iteratively and / or periodically. The number of cycles involved in this process may depend on factors such as FL deployment configuration, frequency of data availability, dynamics in the training / inference data, model performance, inference results, and the state of the FL client.

[0068] 4) This step may include FL training and inference. These operations can occur simultaneously, not necessarily sequentially. Training can occur in FL clients capable of supporting computationally demanding training processes and has been assigned to FL training clusters / sub-clusters by the FL deployment service. Training can be performed by each FL client based on the conditions and requirements associated with the clusters created as part of the FL deployment configuration. FL clients in the training clusters can send updated model parameters to the FL deployment service based on the completion of their local training (as in regular FL operations, but according to their ML sub-clusters). Depending on the different clusters that may have been identified, each cluster may have a separate set of updates grouped together. Authorization requests for aggregated FL models (one or more) can be sent from the FL deployment service to (one or more) FL users, and responses (not shown) can be received by the FL deployment service from (one or more) users. Model parameter aggregation can be performed for each FL cluster. The FL aggregation algorithm can be configured in step 1, and this algorithm can be dynamically modified due to different client clusters and / or modifications during the process. If a new FL and clustering configuration was implemented in steps 7-10, step 4 may also require "deploying" the initial model (per FL cluster / sub-cluster). In this case, the updated ML model can be deployed to both the training and inference clusters for each FL cluster / sub-cluster. Local training can continue in the training cluster client using the aggregated model, which can also be deployed to the FL clients in the inference cluster to produce inference results. FL inference can be performed at the FL clients in the inference cluster (and the training cluster, which can also be performed in the training cluster client due to the smaller computational cost of inference) based on their FL cluster / sub-cluster labels. This may include evaluating the ML model for each FL cluster.

[0069] 5) Model evaluation and performance reports can be passed from the inference clustering client to the FL deployment service. Reports can send the requested information indicated in the “Client Reporting Instructions” defined in Table 2. Reports can be sent periodically based on a schedule, on demand upon request, or in an event-based manner. In the event-based case, the triggering of report sending by the FL client in inference clustering can depend on model accuracy. If the model accuracy drops below a preset threshold, a model evaluation report can be sent to the FL deployment service. The FL deployment service can then send the model evaluation report or a subset thereof to one or more FL users. The FL deployment service can present continuously / periodically updated dashboards to one or more users, and users can also request more detailed reports from each client showing previously acceptable model accuracy values ​​and how the model has evolved over time. The dashboard can also include updates to FL client information (data statistics, metadata, compute resources, network statistics). Report triggering can also be via some predefined or adaptive thresholds depending on the FL information package for the next step. Furthermore, the "timeliness" of model evaluation results may depend on the speed at which baseline real values ​​for the current FL deployment use cases are generated at the inference client (and sent by the inference client).

[0070] Due to the data characteristics independent of the FL client, the computational efficiency of the model may also change over time. Therefore, computation time, as well as the number of iterations required for the model to converge and the time per iteration, can also be part of the model evaluation report. Due to the inherent mathematical optimization nature of any machine learning process, and various related parameters (such as the optimization algorithm, learning rate, the number and type of layers in the neural network algorithm, or other hyperparameters), convergence may take longer in some cases. There may even be instances where convergence is never achieved. In such cases, the FL deployment service can use threshold-based strategies. For example, the FL deployment service can utilize strategies based on the time elapsed per run or the number of iterations to prematurely stop or terminate some training processes and modify the model.

[0071] 6) As part of the iterative process, the FL deployment service can request relevant data statistics, metadata, and information about the client's computational and network resources from the FL client, and the client can respond with the requested information. Based on the received information, the FL deployment service can update the FL client information (as shown in Table 1). Updates can be performed at the same frequency as the model inference results or less / more frequently. As part of this communication, the FL client can also turn its participation on / off. Therefore, new clients may appear on the FL deployment and / or existing clients may leave the FL deployment. Details of the data communication in step 6 will be discussed in step 7. Information about the computational and network capabilities associated with the FL client may also be included.

[0072] The operations in steps 4 through 6 can also be performed as described below in the FL Client Reports section.

[0073] 7) Model retraining and client-side clustering management: Based on the information received from steps 5 and 6, and the model retraining strategy provided by the FL user, the FL deployment service can determine whether model retraining should be triggered and what action to take. Alternatively, the FL deployment service can aggregate information reported from FL clients and send the information to one or more FL users to determine whether model retraining should be triggered.

[0074] For example, if a global trigger is defined as "trigger model retraining when at least 80% of inference clients detect data / model drift," the FL deployment service can log the occurrence of data / model drift, which can be reported by FL clients or detected by the FL deployment service based on reports from FL clients. Model retraining can be triggered when the number of clients with data / model drift exceeds 80% of the total number of clients.

[0075] As another example, a threshold can be specified so that model retraining can be triggered when a certain number of FL clients report performance issues with the ML model. FL deployment configurations can specify that model retraining should be triggered if 10% of FL clients report model performance below 95%. The threshold can be specified based on specific client clustering or the ML model.

[0076] Based on information received in previous steps and / or detections triggered by model retraining, one or more FL users and / or FL deployment services can determine the re-clustering of FL clients. For example, data / model drift detected at one or more FL clients in an inference cluster can indicate that the data at one or more clients may have patterns that are new to the existing model. In this case, one or more clients can be moved / added to the training cluster, allowing the client to contribute its data to improve the model. In another example, a client can participate in both training and inference. If the model performs poorly at a client but performs well at other inference clients, the data at that client may be an outlier, and that client can be removed from the training cluster.

[0077] If some clients lack sufficient computational and / or network resources, it may be impossible to move such clients into the training cluster. Instead, clients belonging to the same sub-clusters from the training cluster can be analyzed to see if they exhibit similar changes in their data patterns. If so, the cluster can be "retrained" (new algorithm, new features, new data preparation steps, etc.). If not, other FL clusters can be analyzed to see if the new data patterns in these inference clients fit into one of the other FL clusters, so that the FL cluster labels of these inference clients can be changed to those FL cluster labels. Alternatively, new clusters can be formed from scratch.

[0078] During this step, the FL Deployment Service can reconfigure client clusters based on the client's data, compute, and network characteristics. This reconfiguration can be based on information provided to the FL Deployment Service by FL users. Furthermore, FL client cluster management can be a dynamic process that can be modified based on changes in participation, data, and / or network patterns. The FL Deployment Service can determine that certain clusters or individual FL client models are performing poorly. This determination can be based on changes in the data or compute / network resource patterns associated with those clusters and / or clients. As a result, some clients may be assigned to different clusters, or removed entirely from the FL system due to inherent defects, or new / replacement clients may be added to the FL system. During the FL deployment lifecycle, FL clients can also change their participation status (by themselves or their corresponding FL users). Alternatively, new FL clusters can be added by the FL Deployment Service and / or FL users. For example, if some clients change their behavior due to "systematic" changes in their data, compute, or network resources.

[0079] In some cases, if an updated version of the ML model (per cluster) does not produce satisfactory ML results for some clients, model retraining can be reversed (i.e., rolled back) by the FL deployment service, allowing such clients to continue using the previous version of the model for their FL clusters, while other clients receive the updated version. The model can be the same algorithm but with different model parameters and / or hyperparameters. If a sufficient number of clients belong to the same category, these individual differences may evolve into collective differences and could eventually lead to the formation of new clusters by the FL deployment service.

[0080] It is also worth mentioning that the methods that may achieve clustering may differ in the following ways: a) Full User Involvement (Manual): In this scenario, one or more FL users can be fully involved in determining the training / inference and FL clustering for the FL client. The FL deployment service can share FL client information received from the FL deployment with one or more FL users. One or more users can make specific decisions or apply pre-built schemes to create FL clusters.

[0081] b) Pre-defined clustering strategies based on client characteristics (rule-based, automatic): Alternatively, FL users can configure strategies within the FL Deployment Service or within another service that interfaces with the FL Deployment Service (e.g., the Policy Engine (PE) service, not shown in the process diagram). These strategies can be used to manage the automatic assignment of FL clients to FL clusters.

[0082] c) ML-based processes (intelligent, automated): Clustering for FL clients can be performed using FL clustering algorithms. These algorithms can be provided as part of the initialization of the FL deployment service. Alternatively, the algorithms can be modified by FL users on a specific basis. The FL deployment service and / or FL users can also leverage one or more ML services to make dynamic recommendations regarding clustering decisions based on changes in FL client data and / or other characteristics.

[0083] Based on the results from the model evaluation report and updated client information, model and / or data drift (on the basis of FL clustering) can be detected, as previously described. This determination can be made by the FL deployment service and / or (one or more) FL users. Therefore, clients may be assigned to different clusters and / or new clusters may emerge as described. In the latter case, new data preparation and / or ML algorithm requirements can be determined by the FL deployment service and / or (one or more) users.

[0084] 8) If the FL deployment service does not detect model / data drift or other changes in the data pattern that alter clustering, and no new clustering and / or new ML model is created / utilized as part of step 7, then a simple model validation response can follow from the FL deployment service to the FL client, after which the iterative process can return to step 4.

[0085] On the other hand, if model / data drift is detected and a new cluster is formed through one of the aforementioned methods, the new cluster assignment can be sent to the FL client, and the new clustering operation can be implemented. Cluster assignments can be sent to the FL client as part of the FL clustering (and / or ML pipeline steps performed by FL clustering) management process. Therefore, FL training and inference clusters with FL sub-clusters can also be constructed accordingly. FL clustering formation and management can be dynamically controlled by the FL deployment service, resulting in changes to the FL client's assignment to FL clusters throughout the FL deployment's lifecycle.

[0086] If model retraining is triggered at step 7, the FL deployment service can determine whether a new model is required (e.g., training a new model from scratch, or switching to another model based on a similarity metric) or whether an existing model should be updated (e.g., resuming the FL training process associated with the model, training the model with updated training data, adding a fine-tuning process, applying transfer learning to the model, etc.). Based on the result, the FL deployment service can perform actions such as those defined in pre-configured global actions. For example, the FL deployment service can request a new or updated model from the ML service or instruct FL clients in the training cluster to train / update the model. The updated model can be deployed to FL clients. Depending on the configuration, the updated model can be deployed to FL clients in the inference cluster. Alternatively, the updated model can be deployed only to FL clients that have experienced data / model drift, while the remaining clients can continue using the older version of the model. The FL deployment service can track model deployment information (e.g., which FL client is using which version of the model) and keep this information up-to-date.

[0087] 9) After the different FL training / inference clusters have been updated and their corresponding client assignments and any ML pipeline steps to be executed have been determined, the FL deployment service can also communicate with (one or more) ML services for the relevant ML algorithms and other ML pipeline steps / components required by the specified FL deployment use case and suitable for each FL cluster. (One or more) ML services can also communicate with storage services ( Figure 4(Not shown in the diagram) Communication is used to locate a pre-trained model, which can be determined based on a similarity measure between the client characteristics of the corresponding FL cluster of the pre-trained model and the client characteristics of existing clusters. If a pre-trained model is available, the ML service can send relevant information to the FL deployment service. If the relevant pre-trained ML model does not exist, the FL deployment service can send a request to the ML service to create a "vanilla" ML algorithm with randomly initialized parameters and hyperparameters. In either case, the ML service can also send data preparation and dependency requirements to the FL deployment service. The ML service can also have recommendations related to features, data preparation, or algorithms based on ML use case / client characteristics.

[0088] 10) If steps 7-9 involve the formation of new clusters, the new initial (“normal” FL model or the model to be updated / retrained can be downloaded to the updated training cluster client (based on their updated FL clusters / sub-clusters). The FL deployment service may send authorization requests for ML models (not shown) to(one or more) FL users and receive responses from(one or more) FL users to initially download the model to the FL client in the training cluster. The FL deployment service may send information related to(one or more) authorized ML models to the FL client in the training cluster, as well as steps to satisfy dependencies, data preparation requirements, and the training process. The information sent may include model specification parameters, such as location at the ML service, algorithm, model ID, version, training instructions with model parameters, HPO, and computational environment specifications (language, OS, etc.). This step may also include model accuracy parameters (and the process used to calculate them) and their acceptable ranges for local training that is later considered converged during the process. This step may be implemented with the participation of FL users via a GUI, a CLI editor connected to the FL deployment service, or a deployment script (e.g., a YAML or JSON file). Based on these results, the iterative process can return to step 4, and the updated ML model can be deployed to both the training and inference clusters for each FL sub-cluster. Local training can continue in the training cluster client using the aggregate master model, which can also be deployed to the inference cluster client to continue generating inference results.

[0089] The operations in steps 8 to 10 can also be implemented as described in the model retraining section below.

[0090] Steps 4-10 can be repeated until the model has converged, meaning it no longer changes significantly. However, even in the case of complete convergence (at least for some unknown period), joint learning is generally an iterative process because frequent / continuous local training may occur on the FL client, which could significantly modify the model parameter aggregation results or lead to possible model / data drift (step 7), potentially resulting in new cluster arrangements. Furthermore, the iterations for each cluster and / or client may differ depending on client information, data patterns, computational and network resources, participant selection, and updates to user requests.

[0091] This paper proposes systems and methods for implementing federated learning deployment services. For example, Figure 4 The method described herein may include receiving from a user device a message including deployment configuration information for a trained ML model, wherein the deployment configuration information includes one or more policies for retraining the trained ML model. The method may also include sending a request to a first group of client devices to deploy the trained ML model at the first group of client devices and a request to receive a response containing deployment information associated with the deployment of the trained ML model. The method may also include receiving a response including deployment information from at least one of the first group of client devices. The method may further include determining whether to trigger retraining of the ML model based on one or more policies for retraining the ML model and the received deployment information. The method may further include sending a request to a second group of client devices to retrain the ML model.

[0092] Figure 4 The method described herein may further include, wherein the user device is a federated learning user, and wherein the client device is a federated learning client.

[0093] Figure 4 The method described herein may further include, wherein the strategy for retraining the ML model includes one or more triggering conditions for model retraining, and wherein the strategy for retraining the ML model includes performing one or more actions to be taken by the ML model deployment service based on the satisfied triggering conditions.

[0094] Figure 4 The method described herein may further include, wherein one or more triggering conditions include at least one of detecting data drift associated with the ML model by a first threshold number of the first group of client devices or detecting model drift associated with the ML model by a second threshold number of the first group of client devices.

[0095] Figure 4 The method described herein may further include one or more actions including adding the first group of client devices to the second group of client devices.

[0096] Figure 4 The method described herein may further include, wherein the deployment information includes one or more of the following: statistical information of the inferred data, performance information of the deployed ML model, information related to the resource consumption of using the deployed ML model, or information related to the time consumption of using the deployed ML model.

[0097] Figure 4 The method described herein may further include determining a first group of client devices and a second group of client devices based on a client clustering strategy associated with deployment configuration information. For example, Figure 4 The system described herein may include means comprising a processor and memory, the means further including computer-executable instructions stored in the memory of the means, which, when executed by the processor of the means, cause the means to perform operations. Operations may include receiving a request from a service provider and at a first client device in a first group of client devices to deploy a trained ML model at the first group of client devices and sending deployment information associated with the deployment of the trained ML model, wherein the request includes one or more policies associated with retraining the ML model. Operations may also include sending a response including deployment information by the first client device, wherein the service provider is configured to determine whether to trigger retraining of the ML model based on one or more policies for retraining the ML model and the sent deployment information. Operations may also include receiving a request to retrain the ML model by the first client device and a second group of client devices, wherein the first client device is associated with the second group of client devices.

[0098] Figure 4 The apparatus described herein may further include, wherein the first client device is a federated learning client.

[0099] Figure 4 The apparatus described herein may further include, wherein the strategy for retraining the ML model includes one or more triggering conditions for model retraining, and wherein the strategy for retraining the ML model includes performing one or more actions to be taken to retrain the ML model based on the satisfied triggering conditions.

[0100] Figure 4 The apparatus described herein may further include, wherein one or more triggering conditions include at least one of detecting data drift associated with the ML model by a first threshold number of the first set of client devices or detecting model drift associated with the ML model by a second threshold number of the first set of client devices.

[0101] Figure 4The apparatus described herein may further include one or more actions including adding a client device from the first group of client devices to the second group of client devices.

[0102] Figure 4 The apparatus described herein may further include, wherein the deployment information includes one or more of the following: statistical information of inferred data, performance information of the deployed ML model, information related to resource consumption of using the deployed ML model, or information related to time consumption of using the deployed ML model.

[0103] Figure 4 The apparatus described herein may further include, wherein the first group of client devices and the second group of client devices are determined based on a client clustering strategy associated with deployment configuration information.

[0104] FL deployment process details. The following process provides... Figure 4 More details or alternatives to the process shown: 1) FL model findings Joint learning model deployment involves using one or more pre-trained ML models, with the FL client participating in the training and / or inference of these models, which the FL client may have discovered from the FL Deployment Service or the ML Service. This section describes the process by which the FL client initiates a request to use an ML model, which may have already been trained during joint learning training (or via other training methods). Figure 4 This is a supplementary / alternative method to the relevant processes defined in steps 1 to 3. The FL client can instruct the client to participate as a federated learning client and provide information about the data that can be used to train the ML model. The FL client can send a discovery request to the FL deployment service for machine learning models that may be related to datasets available to the FL client. The FL deployment service can process the request to see if there is a machine learning model that matches the discovery requirements specified by the FL client, and optionally can send a notification to the FL user that may grant the FL client the necessary permission to receive the matching model and / or participate in the training process of the matching model. The FL deployment service can provide the FL client with one or more matching models and associated strategies that define the metrics (such as the information defined in the "Client Reporting Instructions" in Table 2) that need to be collected by the FL client. Metrics capture statistical information about the data on which the deployed model is applied. Statistical information may include characteristics of the input data, prediction results, and accuracy results, etc.

[0105] Figure 5 Describes client-initiated model discovery Step 1: The FL client can issue an ML model discovery request to the FL deployment service to query available ML models for training and / or inference. The discovery request may include: the FL client identifier, FL client type, ML application type, ML model requirements, client capabilities, client scheduling and availability, available data and information about the data, and the client's willingness to train and / or infer (or other information about the client and / or model as defined in Tables 1 and 2). If the FL client is involved in model training and has the model and associated monitoring policies locally (such as the information defined in "Client Reporting Instructions" in Table 2), steps 1-3 can be skipped.

[0106] Step 2: When the FL Deployment Service receives a model discovery request from an FL client, the FL Deployment Service may first send a notification to one or more FL users, providing information about the FL client and the model discovery filter (which was received in the request in Step 1) in the notification.

[0107] Step 3: The FL user can return a response regarding whether to authorize the FL client to access the requested ML model. The response may also include usage policies for when the FL client is allowed to use the ML model (e.g., "Model Usage Policy" in Table 2), what information the FL client needs to provide during the use of the ML model (e.g., "Client Reporting Instructions" in Table 2, information defined in Table 3), etc.

[0108] Step 4: When the FL Deployment Service determines that the FL client has authorization to retrieve the model through explicit approval from the FL user or a policy accessible to the FL Deployment Service, the FL Deployment Service can provide the FL client with the machine learning model and the associated policy. The policy associated with the model may have the same information elements as shown in Step 1.

[0109] If the client can participate in the training / inference of the machine learning model, the model discovery response can include the model usage strategy, the expected performance characteristics of the model, and the characteristics of the inference data that the client should monitor when deploying the model. The strategy can also include specifications for the input data of the machine learning model, which should be collected by the FL client for potential use in future training. Table 3 shows examples of information that can be defined in the strategy, which could be another embodiment of the parameters described in Table 2.

[0110] Table 3: Joint Learning Data Measurement Strategies

[0111] Step 5: When the machine learning model is deployed to the FL client, the strategies specified in Table 3 can indicate the input data, output data, and baseline data metrics that the FL client should record or compute. The FL client also stores new input data when the input data meets the criteria specified in the strategy.

[0112] 2) FL Client Report This section describes the FL client reporting process, which may be... Figure 4 Supplemental / alternative methods to the relevant processes defined in steps 4 through 6. The FL client can download machine learning models and associated deployment strategies, and the models can be deployed on the client. The downloaded strategy describes the data collection process that will be used to monitor the performance of the machine learning model on new data, including collecting statistics about the data (e.g., generating EDA results) and evaluating the model's performance. When data collection requirements are met, the FL client may periodically report information about the collected data without sharing the actual data. Figure 5 As shown, the FL deployment service can also send requests to FL clients to retrieve report information as needed.

[0113] like Figure 6 As described, the FL deployment service can aggregate these reports collected from some or all FL clients to determine when or whether the ML model should be retrained. Alternatively, the FL client can determine that the model performance is insufficient to meet the client's needs and send a model retraining / update request or evaluation report.

[0114] Data collection reports may include statistics on the overall dataset available to the client, or only statistics on newly collected data that was not used during model training. Alternatively, reports may include statistics on both new data and the complete dataset. Reports may also include information on model performance, resource or time consumption when using the model, etc.

[0115] Step 1: FL users can send messages specifying conditions that indicate the model should be retrained (or a model retraining strategy as defined in Table 2). For example, if the baseline true metric indicates that predictions are incorrect 5% of the time, the FL deployment service can be signaled to trigger the retraining process. Table 4 shows examples of information that FL users can provide to the FL deployment service regarding model retraining conditions.

[0116] Table 4 – FL User Retraining Conditions

[0117] Step 2 (Optional): When an FL client is working with a machine learning model that has already been trained (e.g., using a federated learning process), the client may not have the ability to retrain the model itself because it may not have access to all the data used for training. This process includes a message that the FL client can send to the FL Deployment Service to indicate that the FL client wants to initiate a retraining process. This request message may appear earlier in the call flow, so the FL Deployment Service may need to execute Step 1 again to get a refreshed report from other clients.

[0118] Step 3: The FL deployment service can send messages to all FL clients to request reports of information / data collected at the client. Alternatively, the client may have been configured to send the report automatically based on a specific event or at periodic intervals. FL users can also initiate a process to request a client report (not shown in the diagram).

[0119] Step 4: When the FL client is required to report to the FL Deployment Service, the FL client prepares the report based on a configured event or an explicit request from the FL Deployment Service. The report may include input data metrics, output data metrics, baseline real metrics, and feature data storage metrics, as shown in Table 5.

[0120] Table 5: Sample Information That May Be Provided in Client Reports

[0121] Step 5: The FL client can report information to the FL deployment service (similar to...). Figure 4 (Step 5). The information shown in Table 5 can be sent to the FL Deployment Service in separate messages and at separate intervals. Each client can send a report to the FL Deployment Service; however, some clients may not respond or may not respond within the time frame required by the FL Deployment Service (as shown in steps 5.1 and 5.2).

[0122] Step 6: When the FL Deployment Service receives reports from clients, it can analyze each message individually and / or in an aggregated manner. The FL Deployment Service can store information from these messages in a way that allows for retrieval or access at later times, by referencing the report ID, model ID, FL client ID, or a combination of these identifiers.

[0123] When the FL Deployment Service analyzes the input data metrics in its report, it checks to ensure that the input data distribution is similar to the input data used for training the current model. However, in a federated learning deployment, each client may not have the same distribution of input data represented by the combined model trained jointly. The FL Deployment Service can compare the current input data metric with previous input data metrics from the same client to determine whether to trigger / indicate retraining.

[0124] When the FL Deployment Service analyzes the output data metrics reported in the collected data reports, it can check to ensure that the output data distribution is similar to the output data used for training the current model. However, in a federated learning deployment, each client may not have the same distribution of output data represented by the combined model trained jointly. The FL Deployment Service can compare the current output data metric with previous output data metrics from the same client to determine whether to trigger / indicate retraining.

[0125] When the FL Deployment Service analyzes the collected data reports benchmark metrics, it can examine correct and incorrect predictions to determine if model performance is adequate. The determination of retraining requirements is use-use dependent and can be configured by the FL user.

[0126] Step 7: It's possible that some clients may fail to report to the FL Deployment Service successfully or in a timely manner. The FL Deployment Service may perform aggregate analysis using only a subset of the information from the FL clients. The number of FL client reports that need to be processed can be specified by the FL user in the retraining conditional message in Step 1. Once the FL Deployment Service receives the requested reports, it can combine the information from each client to calculate the global effectiveness of the machine learning model deployed on the FL client. This may indicate that a retraining process should be triggered / started.

[0127] Step 8: The FL Deployment Service can notify FL users of information reported from the FL client.

[0128] 3) Model retraining The next section describes the process of triggering model retraining, which can be... Figure 4Supplemental / alternative methods to the relevant processes defined in steps 8 through 10. If model retraining is signaled via an FL client request or by the FL deployment service analyzing reports from the FL client, an authorization request to the FL user may be required before the retraining process continues. The retraining signal may be issued periodically by the FL deployment service or based on analysis of reports from the FL client. The retraining configuration message from the FL deployment service to the FL client may include a description of the subset of data that should be used for retraining. The model retraining request may optionally be sent to a subset of the client.

[0129] Figure 7 A flowchart is shown to illustrate an example method for retraining an FL model.

[0130] When the FL Deployment Service aggregates and analyzes data from clients participating in the FL learning and training process, it can determine that the aggregation of data from all clients has resulted in an imbalanced dataset. In this case, a common practice is to balance the dataset by removing overrepresented data or artificially generating underrepresented data. The process described in this section defines messaging to instruct each client in the client pool which data they should use for training or retraining, to achieve the required statistical properties of the dataset across clients.

[0131] Step 1: The FL client retraining process begins with a signal indicating that retraining is required. This can be initiated by the FL user, the FL service, or the FL client.

[0132] Step 2: The process can be configured to notify interested entities (such as FL users or FL clients) that the (re)training process has been triggered / instructed.

[0133] Step 3: The process may require authorization to continue the (re)training process.

[0134] Step 4: Based on the aggregated statistical analysis completed in Section 5.2, the FL Deployment Service may have identified, or been provided from external sources (such as from FL users), the datasets required for retraining and the overall statistics of the clients with these datasets. For example, if three clients have imbalanced datasets of three classes of images for which machine learning models are being trained, the FL Deployment Service can configure these three clients to balance the overall dataset. This process may involve configuring each client to provide a subset of data while excluding other data, or it may include having the FL clients downsample the number of samples for a specific target classification. Additionally, FL clients may be configured to use data from a specific time period for machine learning training. Table 6 shows examples of information that can be sent from the FL Deployment Service to FL clients for configuring the retraining process.

[0135] Table 6 – FL Client Retraining Configuration

[0136] Step 5: The FL deployment service sends a retraining configuration message to each FL client. FL clients can participate in the joint learning process to retrain / update the model.

[0137] The aforementioned management functionality for deploying FL / ML models to different client clusters can be implemented in several ways. Examples of RESTful API, publish / subscribe (Pub / Sub) API, and GUI API are defined in the following sections.

[0138] RESTful API One method to implement the aforementioned FL Deployment Service functionality is through the RESTful API supported by the FL Deployment Service. The RESTful API can include one or more different types of resources hosted and stored by the FL Deployment Service, which are accessed by FL clients and FL users via RESTful operations commonly referred to as methods (e.g., PUT, POST, GET, DELETE). Each type of resource defined for the API can include a defined set of informational elements, commonly referred to as attributes. These resource types and their corresponding attributes provide the FL Deployment Service with a means to receive information from FL clients and FL users using RESTful protocols (such as HTTP), process the information by performing FL Deployment Service-specific tasks, and provide the results of these operations back to the FL clients and FL users. Therefore, FL clients and FL users interface with the FL Deployment Service using the RESTful API and access the capabilities supported by the FL Deployment Service in a RESTful manner.

[0139] The FL Deployment Service's RESTful API can support one or more types of resources centered around the FL Deployment Service. These FL Deployment Resources can include attributes, such as, but not limited to, those defined in the tables and procedures mentioned above. These attributes can be represented and stored in these resources using representation formats such as JSON and XML, as well as other formats. The FL Deployment Service can support the instantiation of these resources upon receiving requests from FL users and FL clients.

[0140] Here are some examples of RESTful APIs that FL Deployment Service can support: Example 1 – Client Registration API .

[0141] This API can be used to register clients and their device specifications and data characteristics.

[0142] Example 2 – Clustering Creation API .

[0143] This API will be used to create client-side clusters based on client-side computing and network resources, parent cluster, and FL cluster type ID.

[0144] Example 3 – Clustering Configuration API .

[0145] This API will be used to configure clusters based on the cluster type, parent cluster, and FL cluster type ID.

[0146] Example 4 – Clustering Assignment API .

[0147] This API will be used to assign clients to clusters based on device specifications and data characteristics. There may be several types of cluster classifications, such as task_cluster (for training and inference based on compute and network resources) and ml_cluster (related to data heterogeneity).

[0148] The "student" client will use this API to make predictions using the trained model.

[0149] Example 5 – Cluster Reassignment API .

[0150] This API will be used to reassign clients to new clusters based on updated device specifications and data characteristics.

[0151] Example 6 – Model Update API .

[0152] The "teacher" client will use this API to update the model based on new training data or changes in data distribution.

[0153] Publish / Subscribe (Pub / Sub) API Another way to implement the aforementioned FL Deployment Service functionality is through the Publish / Subscribe (Pub / Sub) API supported by the FL Deployment Service. The Pub / Sub API can include one or more different types of topics hosted and stored by the FL Deployment Service, accessible to FL clients and FL users via publish and subscribe operations. Each type of topic defined for the API can include a defined set of information elements, often referred to as attributes. These topics and their corresponding attributes provide the FL Deployment Service with a means to receive information from FL clients and FL users using Pub / Sub protocols (such as MQTT and AMQP), process the information by performing FL Deployment Service-specific tasks, and provide the results of these operations back to the FL clients and FL users. Therefore, FL clients and FL users can use the Pub / Sub API to interact with the FL Deployment Service and access its supported capabilities in a Pub / Sub manner.

[0154] The Pub / Sub API of the FL Deployment Service can support one or more types of topics centered around the FL Deployment Service. These FL Deployment topics can include properties, such as, but not limited to, those defined in the tables and procedures mentioned above. These properties can be represented and stored in these topics using representation formats such as JSON and XML, among others. The FL Deployment Service can support the instantiation of these topics upon receiving requests from FL users and FL clients.

[0155] Here are some examples of Pub / Sub APIs that the FL deployment service may support: Example 1 – Client registration topic: Clients will publish their device specifications and data characteristics to the `client_registration` topic. The payload might look like this: .

[0156] The server-side subscriber (FL Deployment Service in this example) will listen to the topic, handle client registrations, and assign them to clusters.

[0157] Example 2 – Clustering to create topics: Users or servers can publish clustering configurations to the `cluster_configuration` topic. The message might look like this: .

[0158] Subscribers will listen to this topic to receive updates on clustering configurations.

[0159] Example 3 - Clustering configuration theme: Users or the FL deployment service can publish clustering configurations to the `cluster_configuration` topic. The message might look like this: .

[0160] Subscribers will listen to this topic to receive updates on clustering configurations.

[0161] Example 4 - Clustering Assignment of Topics: The server will publish cluster assignments to the `cluster_assignment` topic. The message might look like this: .

[0162] The client will subscribe to the topic to receive its clustering assignments.

[0163] Example 5 - Model Training Topic: The "teacher" client for each ML sub-cluster (the client in the training cluster) will publish the trained model to the `model_training` topic. This message might look something like this: .

[0164] Other "teacher" clients in the same cluster can subscribe to the topic to receive updates about the trained model.

[0165] Example 6 - Model Inference Topic: The "student" client (the client in the inference cluster) of each ML sub-cluster will publish inference data to the model_inference topic and receive predictions from the "teacher" client. This message might look something like this: .

[0166] The "Teacher" client will subscribe to the topic to receive inference data, perform predictions, and publish results.

[0167] Example 7 - Clustering to Reassign Topics: The client will publish the updated device specifications and data characteristics to the `cluster_reassignment` topic. This message might look like the following: .

[0168] FL deployment services and / or users can listen to this topic, process updated client information, and reassign them to new clusters.

[0169] Example 8 - Model Update Topic: The "Teacher" client will publish the updated model to the `model_update` topic. The message might look like this: .

[0170] Other "teacher" clients in the same cluster can subscribe to the topic to receive updates about the model.

[0171] GUI Another method to implement the aforementioned FL Deployment Service functionality is through a graphical user interface (GUI)-centric API supported by the FL Deployment Service. The GUI API can include one or more different types of GUI features supported by the FL Deployment Service, which FL clients and users access via GUI operations. The GUI API can include a defined set of information elements. Features and information elements provide the FL Deployment Service with a means to receive information from FL clients and FL users using GUI operations, process the information by performing FL Deployment Service-specific tasks, and provide the results of these operations back to the FL clients and FL users. Therefore, FL clients and FL users can use the GUI API to interact with the FL Deployment Service and access its supported capabilities in a GUI-based manner.

[0172] The FL Deployment Service's GUI API can support one or more types of FL Deployment Service-centric features (e.g., panels, menus, canvases, etc.). These FL Deployment features can include informational elements, such as, but not limited to, those defined in the aforementioned tables and procedures. These informational elements can be represented using representation formats such as JSON and XML, among others.

[0173] Here are some examples of GUI APIs that the FL Deployment Service may support: Example 1 - Client Registration Panel: This panel allows clients to input and submit their device specifications and data characteristics. The panel may include form fields for CPU information, RAM information, network information, data volume, and data type.

[0174] Example 2 - Client-side clustering creation panel: This panel allows users to input options to create client clusters based on the client's computing and network resources and their data characteristics.

[0175] Example 3 - Clustering Configuration API This control panel displays options for configuring client-side clustering. Several clustering types are possible, such as `task_cluster` (for training and inference based on compute and network resources) and `ml_cluster` (related to data heterogeneity). The panel allows users to enter and submit clustering configurations. It may include form fields for cluster type, parent cluster, and FL cluster type ID. Drop-down menus may be available to select whether clustering is used for training or inference.

[0176] Example 4 - Cluster Assignment Control Panel: The dashboard displays the cluster assignments of the clients. It can show a list or table of clients with their respective assigned clusters. A refresh button is available to update the dashboard when a client is reassigned to a different cluster.

[0177] Example 5 - Cluster Reassignment Panel: This panel allows clients to update their device specifications and data characteristics, triggering a reassignment to a new cluster. The panel can include form fields similar to those in a client registration panel, with buttons for submitting the updated information.

[0178] Example 6 - Model Update Module: Similar to the model training module, this module may only be accessible to the "teacher" client. The model training module allows the "teacher" client to upload updated models, which can then be shared with the "student" clients.

[0179] Example 7 - Monitoring and Logs Panel: This panel displays logs and metrics related to system operations. This can include cluster assignment updates, model training processes, inference results, and more.

[0180] Example 8 - Notification Area: This area displays notifications to users about important events, such as successful model training and cluster reassignment.

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

[0182] Communication system 100 may also include base station 114a and base station 114b. Base station 114a may be any type of device configured to wirelessly interface with at least one of WTRUs 102a, 102b, 102c to facilitate access to one or more communication networks such as core networks 106 / 107 / 109, the Internet 110, and / or other networks 112. Base station 114b may be any type of device configured to wired and / or wirelessly interface with at least one of RRHs (Remote Radio Headers) 118a, 118b, TRPs (Transmit and Receive Points) 119a, 119b, and / or RSUs (Roadside Units) 120a and 120b to facilitate access to one or more communication networks such as core networks 106 / 107 / 109, the Internet 110, other networks 112, and / or V2X servers (or ProSe functions and servers) 113. RRH 118a and 118b can be any type of device configured to wirelessly interface with at least one WTRU 102c to facilitate access to one or more communication networks, such as core networks 106 / 107 / 109, the Internet 110, and / or other networks 112. TRP 119a and 119b can be any type of device configured to wirelessly interface with at least one WTRU 102d to facilitate access to one or more communication networks, such as core networks 106 / 107 / 109, the Internet 110, and / or other networks 112. RSU 120a and 120b can be any type of device configured to wirelessly interface with at least one of WTRU 102e or 102f to facilitate access to one or more communication networks, such as core networks 106 / 107 / 109, the Internet 110, other networks 112, and / or a V2X server (or ProSe function and server) 113. By way of example, base stations 114a and 114b can be basic transceiver stations (BTS), Node-B, eNode B, home Node B, home eNode B, site controllers, access points (APs), wireless routers, etc. Although base stations 114a and 114b are each depicted as a single element, it will be understood that base stations 114a and 114b can include any number of interconnected base stations and / or network elements.

[0183] Base station 114a may be part of RAN 103 / 104 / 105, which may also include other base stations and / or network elements (not shown), such as Base Station Controller (BSC), Radio Network Controller (RNC), relay nodes, etc. Base station 114b may be part of RAN 103b / 104b / 105b, which may also include other base stations and / or network elements (not shown), such as Base Station Controller (BSC), Radio Network Controller (RNC), relay nodes, etc. Base station 114a may be configured to transmit and / or receive radio signals within a specific geographical area, which may be referred to as a cell (not shown). Base station 114b may be configured to transmit and / or receive wired and / or radio signals within a specific geographical area, which may be referred to as a cell (not shown). Cells may also be divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Therefore, in an embodiment, base station 114a may include three transceivers, for example, one transceiver for each sector of the cell. In an embodiment, base station 114a may employ multiple-input multiple-output (MIMO) technology, and thus can therefore use multiple transceivers for each sector of the cell.

[0184] Base station 114a can communicate with one or more of WTRUs 102a, 102b, and 102c via air interfaces 115 / 116 / 117. Air interfaces 115 / 116 / 117 can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, cmWave, mmWave, etc.). Air interfaces 115 / 116 / 117 can be established using any suitable radio access technology (RAT).

[0185] Base station 114b can communicate with one or more of RRH 118a, 118b, TRP 119a, 119b and / or RSU 120a and 120b via wired or air interfaces 115b / 116b / 117b. Air interfaces 115b / 116b / 117b can be any suitable wired (e.g., cable, fiber optic, etc.) or wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, cmWave, mmWave, etc.). Air interfaces 115b / 116b / 117b can be established using any suitable radio access technology (RAT).

[0186] RRH 118a, 118b, TRPs 119a, 119b and / or RSU 120a, 120b can communicate with one or more of WTRU 102c, 102d, 102e, 102f via air interface 115c / 116c / 117c. Air interface 115c / 116c / 117c can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, cmWave, mmWave, etc.). Air interface 115c / 116c / 117c can be established using any suitable radio access technology (RAT).

[0187] WTRUs 102a, 102b, 102c, 102d, 102e, 102f, and / or 102g can communicate with each other via air interfaces 115d / 116d / 117d (not shown in the figure), which can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, cmWave, mmWave, etc.). Air interfaces 115d / 116d / 117d can be established using any suitable radio access technology (RAT).

[0188] More specifically, as noted above, the communication system 100 can be a multiple access system and can employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, base stations 114a and WTRUs 102a, 102b, and 102c in RAN 103 / 104 / 105, or RRHs 118a, 118b, TRPs 119a and 119b, RSUs 120a and 120bb, and WTRUs 102c, 102d, 102e, and 102f in RAN 103b / 104b / 105b, can implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which can each establish air interfaces 115 / 116 / 117 or 115c / 116c / 117c 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).

[0189] In this embodiment, base station 114a and WTRUs 102a, 102b, 102c or RANs 103b / 104b / 105b, specifically RRH118a, 118b, TRP 119a, 119b and / or RSUs 120a, 120b and WTRUs 102c, 102d, can implement wireless technologies such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which can each establish air interfaces 115 / 116 / 117 or 115c / 116c / 117c using Long Term Evolution (LTE) and / or LTE-A Advanced (LTE-A). In the future, air interfaces 115 / 116 / 117 can implement 3GPP NR technology. LTE and LTE-A technologies include LTE D2D and V2X technologies and interfaces (such as sidelink communication). 3GPP NR technology includes NR V2X technologies and interfaces (such as sidelink communication).

[0190] In the embodiments, base stations 114a and WTRUs 102a, 102b, 102c in RAN 103 / 104 / 105, or RRHs 118a, 118b, TRPs 119a, 119b and / or RSUs 120a, 120b and WTRUs 102c, 102d, 102e, 102f in RAN 103b / 104b / 105b can implement radio technologies such as IEEE 802.16 (e.g., Global Microwave Access Interoperability (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced GSM Evolution Data Rate (EDGE), GSMEDGE (GERAN), etc.

[0191] Figure 11A Base station 114c can be, for example, a wireless router, a home Node B, a home eNode B, or an access point, and can utilize any suitable RAT to facilitate wireless connectivity in a local area, such as a business premises, residence, vehicle, campus, etc. In one embodiment, base station 114c and WTRU 102e can implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, base station 114c and WTRU 102d can implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, base station 114c and WTRU 102e can utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish a picocell or femtocell. Figure 11A As illustrated, base station 114b can have a direct connection to the Internet 110. Therefore, base station 114c is not required to access the Internet 110 via core network 106 / 107 / 109.

[0192] RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b can communicate with core networks 106 / 107 / 109, which can be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRU 102a, 102b, 102c, and 102d. For example, core networks 106 / 107 / 109 can provide call control, billing services, location-based services, prepaid calling, internet connectivity, video distribution, and / or perform advanced security functions such as user authentication.

[0193] Although not in Figure 11A As shown, but will be understood, RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b and / or core network 106 / 107 / 109 can communicate directly or indirectly with other RANs, which may use the same RAT or a different RAT as RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b. For example, in addition to being connected to RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b, which may be utilizing E-UTRA radio technology, core network 106 / 107 / 109 can also communicate with another RAN (not shown) using GSM radio technology.

[0194] Core networks 106 / 107 / 109 may also act as gateways for WTRUs 102a, 102b, 102c, 102d, 102e to access PSTN 108, the Internet 110, and / or other networks 112. PSTN 108 may include a circuit-switched telephone network providing Common Old-Style Telephone Service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and Internet Protocol (IP) from the TCP / IP Internet Protocol suite. Network 112 may include wired or wireless communication networks owned and / or operated by other service providers. For example, network 112 may include another core network connected to one or more RANs, which may use the same RAT as or a different RAT than RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b.

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

[0196] Figure 11B This is a block diagram of an example apparatus or device configured for wireless communication according to the embodiments shown herein, such as, for example, WTRU 102. Figure 11B As shown, 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 / indicator 128, non-removable memory 130, removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136, and other peripheral devices 138. It will be appreciated that WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with the embodiments. Furthermore, the embodiments envision base stations 114a and 114b, and / or base stations 114a and 114b may represent nodes such as, but not limited to, transceiver stations (BTS), Node-B, site controllers, access points (APs), home node-B, evolved home node-B (eNodeB), home evolved node-B (HeNB), home evolved node-B gateways, and proxy nodes, etc., and may include... Figure 11B Some or all of the elements depicted in and described herein.

[0197] Processor 118 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. Processor 118 may perform signal encoding / decoding, data processing, power control, input / output processing, and / or any other functions that enable WTRU 102 to operate in a wireless environment. Processor 118 may be coupled to transceiver 120, and transceiver 120 may be coupled to transmitting / receiving element 122. Although... Figure 11B The processor 118 and transceiver 120 are depicted as separate components, but it will be understood that the processor 118 and transceiver 120 can be integrated together into an electronic package or chip.

[0198] Transmitting / receiving element 122 can be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) via air interface 115 / 116 / 117. For example, in one embodiment, transmitting / receiving element 122 can be an antenna configured to transmit and / or receive RF signals. In another embodiment, transmitting / receiving element 122 can be a transmitter / detector configured to transmit and / or receive, for example, IR, UV, or visible light signals. In yet another embodiment, transmitting / receiving element 122 can be configured to transmit and receive both RF signals and optical signals. It will be appreciated that transmitting / receiving element 122 can be configured to transmit and / or receive any combination of wireless signals.

[0199] Furthermore, although the transmitting / receiving element 122 is in Figure 11B While depicted as a single element, WTRU 102 may include any number of transmit / receive elements 122. More specifically, WTRU 102 may employ MIMO technology. Therefore, in embodiments, WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals via air interfaces 115 / 116 / 117.

[0200] Transceiver 120 can be configured to modulate signals to be transmitted by transmitting / receiving element 122 and demodulate signals received by transmitting / receiving element 122. As noted above, WTRU 102 can have multi-mode capability. Thus, for example, transceiver 120 can include multiple transceivers for enabling WTRU 102 to communicate via multiple RATs such as UTRA and IEEE 802.11.

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

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

[0203] 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) about the current location of the WTRU 102. In addition to, or alternatively to, the information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via air interfaces 115 / 116 / 117, and / or determine its location based on the timing of signals received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information using any suitable location determination method, while remaining consistent with the embodiments.

[0204] The processor 118 may be further coupled to other peripheral devices 138, which may include one or more software and / or hardware modules that provide additional features, functions, and / or wired or wireless connectivity. For example, peripheral devices 138 may include various sensors such as accelerometers, biometric (e.g., fingerprint) sensors, electronic compasses, satellite transceivers, digital cameras (for photos or videos), Universal Serial Bus (USB) ports or other interconnect interfaces, vibration devices, television transceivers, hands-free headsets, Bluetooth® modules, FM radio units, digital music players, media players, video game player modules, internet browsers, etc.

[0205] WTRU 102 can be incorporated into other devices or equipment, such as sensors, consumer electronics, wearable devices such as smartwatches or smart clothing, medical or electronic healthcare devices, robots, industrial equipment, drones, or vehicles such as cars, trucks, trains, or airplanes. WTRU 102 can be connected to other components, modules, or systems of such devices or equipment via one or more interconnect interfaces, such as an interconnect interface that may include one of the peripheral devices 138.

[0206] Figure 11C This is a system diagram of RAN 103 and core network 106 according to an embodiment. As noted above, RAN 103 can employ UTRA radio technology to communicate with WTRUs 102a, 102b, and 102c via air interface 115. RAN 103 can also communicate with core network 106. Figure 11C As shown, RAN 103 may include Node-Bs 140a, 140b, and 140c, each Node-B including one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 115. Node-Bs 140a, 140b, and 140c may each be associated with a specific cell (not shown) within RAN 103. RAN 103 may also include RNCs 142a and 142b. It will be appreciated that RAN 103 may include any number of Node-Bs and RNCs while remaining consistent with the embodiments.

[0207] like Figure 11CAs shown, Node-B 140a and 140b can communicate with RNC 142a. Additionally, Node-B 140c can communicate with RNC 142b. Node-B 140a, 140b, and 140c can communicate with their respective RNCs 142a and 142b via the Iub interface. RNCs 142a and 142b can communicate with each other via the Iur interface. Each of RNCs 142a and 142b can be configured to control the corresponding Node-B 140a, 140b, or 140c to which it is connected. Furthermore, each of RNCs 142a and 142b can be configured to implement or support other functions, such as outer-loop power control, load control, admission control, packet scheduling, handover control, macro diversity, security functions, and data encryption.

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

[0209] RNC 142a in RAN 103 can be connected to MSC 146 in core network 106 via the IuCS interface. MSC 146 can be connected to MGW 144. MSC 146 and MGW 144 can provide WTRU 102a, 102b, and 102c with access to circuit-switched networks such as PSTN 108 to facilitate communication between WTRU 102a, 102b, and 102c and legacy landline communication equipment.

[0210] RNC 142a in RAN 103 can also be connected to SGSN 148 in core network 106 via IuPS interface. SGSN 148 can be connected to GGSN 150. SGSN 148 and GGSN 150 can provide WTRU 102a, 102b, and 102c with access to packet-switched networks such as Internet 110, facilitating communication between WTRU 102a, 102b, 102c and IP-enabled devices.

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

[0212] Figure 11DThis is a system diagram of RAN 104 and core network 107 according to an embodiment. As noted above, RAN 104 may employ E-UTRA radio technology to communicate with WTRUs 102a, 102b, and 102c via air interface 116. RAN 104 may also communicate with core network 107.

[0213] RAN 104 may include eNode-Bs 160a, 160b, and 160c; however, it will be understood that RAN 104 may include any number of eNode-Bs while remaining consistent with the embodiments. eNode-Bs 160a, 160b, and 160c may each include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In the embodiments, eNode-Bs 160a, 160b, and 160c may implement MIMO technology. Therefore, for example, eNode-B 160a may use multiple antennas to transmit radio signals to and receive radio signals from WTRU 102a.

[0214] Each of the eNode-B 160a, 160b, and 160c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in the uplink and / or downlink, etc. Figure 11D As shown, eNode-B 160a, 160b, and 160c can communicate with each other via the X2 interface.

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

[0216] The MME 162 can connect to each of the eNode-Bs 160a, 160b, and 160c in RAN 104 via the S1 interface and can act as a control node. For example, the MME 162 can be responsible for authenticating users of WTRUs 102a, 102b, and 102c, bearer activation / deactivation, and selecting specific serving gateways during the initial attachment of WTRUs 102a, 102b, and 102c. The MME 162 can also provide control plane functions for handover between RAN 104 and other RANs (not shown) employing other radio technologies such as GSM or WCDMA.

[0217] Serving Gateway 164 can connect to each of the eNode-Bs 160a, 160b, and 160c in RAN 104 via the S1 interface. Serving Gateway 164 can generally route and forward user data packets to / from WTRUs 102a, 102b, and 102c. Serving Gateway 164 can also perform other functions, such as anchoring the user plane during inter-eNode B handover, triggering paging when downlink data is available to WTRUs 102a, 102b, and 102c, and managing and storing the context of WTRUs 102a, 102b, and 102c.

[0218] Service gateway 164 can also be connected to PDN gateway 166, which can provide WTRU 102a, 102b, 102c with access to packet-switched networks (such as Internet 110) to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices.

[0219] Core network 107 can facilitate communication with other networks. For example, core network 107 can provide WTRUs 102a, 102b, and 102c with access to circuit-switched networks such as PSTN 108 to facilitate communication between WTRUs 102a, 102b, and 102c and traditional landline communication equipment. For example, core network 107 may include, or be able to communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between core network 107 and PSTN 108. Furthermore, core network 107 can provide WTRUs 102a, 102b, and 102c with access to network 112, which may include other wired or wireless networks owned and / or operated by other service providers.

[0220] Figure 11E This is a system diagram of RAN 105 and core network 109 according to an embodiment. RAN 105 may be an access service network (ASN) that uses IEEE 802.16 radio technology to communicate with WTRUs 102a, 102b, and 102c via air interface 117. As will be further discussed below, communication links between different functional entities of WTRUs 102a, 102b, 102c, RAN 105, and core network 109 can be defined as reference points.

[0221] like Figure 11EAs shown, RAN 105 may include base stations 180a, 180b, 180c and ASN gateway 182; however, it will be understood that RAN 105 may include any number of base stations and ASN gateways while remaining consistent with the embodiment. Base stations 180a, 180b, and 180c may each be associated with a specific cell in RAN 105 and may include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 117. In the embodiment, base stations 180a, 180b, and 180c may implement MIMO technology. Therefore, for example, base station 180a may use multiple antennas to transmit radio signals to and receive radio signals from WTRU 102a. Base stations 180a, 180b, and 180c may also provide mobility management functions such as handover triggering, tunnel establishment, radio resource management, traffic classification, and Quality of Service (QoS) policy enforcement. ASN Gateway 182 can act as a traffic aggregation point and can be responsible for paging, caching subscriber profiles, and routing to the core network 109, etc.

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

[0223] The communication link between each of base stations 180a, 180b, and 180c can be defined as an R8 reference point, which includes protocols for facilitating WTRU handover and data transmission between the base stations. The communication link between base stations 180a, 180b, 180c, and ASN gateway 182 can 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 WTRUs 102a, 102b, and 102c.

[0224] like Figure 11EAs shown, RAN 105 can be connected to core network 109. The communication link between RAN 105 and core network 109 can be defined as an R3 reference point, which includes, for example, protocols for facilitating data transmission and mobility management capabilities. Core network 109 may include a Mobile IP Home Agent (MIP-HA) 184, an Authentication, Authorization, and Accounting (AAA) server 186, and a gateway 188. While each of the foregoing elements is depicted as part of core network 109, it will be understood that any of these elements may be owned and / or operated by an entity other than the core network operator.

[0225] MIP-HA manages IP addresses and enables WTRU 102a, 102b, and 102c to roam between different ASNs and / or different core networks. MIP-HA 184 provides WTRU 102a, 102b, and 102c with access to packet-switched networks such as Internet 110, facilitating communication between WTRU 102a, 102b, and 102c and IP-enabled devices. AAA Server 186 handles user authentication and support services. Gateway 188 facilitates interoperability with other networks. For example, Gateway 188 provides WTRU 102a, 102b, and 102c with access to circuit-switched networks such as PSTN 108, facilitating communication between WTRU 102a, 102b, and 102c and legacy landline communication equipment. In addition, gateway 188 can provide WTRU 102a, 102b, 102c with access to network 112, which may include other wired or wireless networks owned and / or operated by other service providers.

[0226] Although not in Figure 11E As shown, but to be understood, RAN 105 can connect to other ASNs, and core network 109 can connect to other core networks. The communication link between RAN 105 and other ASNs can be defined as an R4 reference point, which may include protocols for coordinating the mobility of WTRUs 102a, 102b, and 102c between RAN 105 and other ASNs. The communication link between core network 109 and other core networks can be defined as an R5 reference, which may include protocols for facilitating interoperability between the home core network and the visited core network.

[0227] The description in this article and in Figure 11A , Figure 11C , Figure 11D and Figure 11EThe core network entities shown are identified by the names given to these entities in certain existing 3GPP specifications; however, it should be understood that these entities and functions may be identified by other names in the future, and certain entities or functions may be combined in future specifications released by 3GPP (including future 3GPP NR specifications). Therefore, Figure 11A , Figure 11B , Figure 11C , Figure 11D and Figure 11E The specific network entities and functions described and illustrated herein are provided by way of example only, and it should be understood that the subject matter disclosed and claimed herein can be embodied or implemented in any similar communication system, whether currently defined or to be defined in the future.

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

[0229] In operation, processor 91 fetches, decodes, and executes instructions, and transfers information to and from other resources via the main data transfer path of the computing system, namely system bus 80. This system bus connects components within the 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 the operating system bus. An example of such a system bus 80 is the PCI (Peripheral Component Interconnect) bus.

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

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

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

[0233] Furthermore, the computing system 90 may include communication circuitry, such as, for example, a network adapter 97, which can be used to connect the computing system 90 to external communication networks, such as RAN 103 / 104 / 105, core network 106 / 107 / 109, PSTN 108, Internet 110, or... Figure 11A , Figure 11B , Figure 11C , Figure 11D and Figure 11E Other networks 112 enable the computing system 90 to communicate with other nodes or functional entities in these networks. Communication circuitry may be used, alone or in combination with the processor 91, to perform the transmit and receive steps of certain means, nodes, or functional entities described herein.

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

[0235] It should be 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, when executed by a processor (such as processor 118 or 91), cause the processor to perform and / or implement the systems, methods, and processes described herein. Specifically, any step, operation, or function described herein may be implemented in the form of such computer-executable instructions, which execute on a processor of an apparatus or computing system configured for wireless and / or wired network communication. Computer-readable storage media include volatile and non-volatile, removable and non-removable media implemented in any non-transitory (e.g., tangible or physical) method or technique for storing 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 storage technologies, CD-ROM, digital versatile disc (DVD) or other optical disc storage, magnetic tape, magnetic tape, disk storage or other magnetic storage devices, or any other tangible or physical medium that may be used to store desired information and can be accessed by a computing system.

Claims

1. A method performed by a machine learning (ML) model deployment service, comprising: Receive a message from the user equipment including deployment configuration information for the trained ML model, wherein the deployment configuration information includes one or more strategies for retraining the trained ML model; Send a request to the first group of client devices to deploy a trained ML model on the first group of client devices and a response to receive deployment information associated with the deployment of the trained ML model; Receive a response including deployment information from at least one of the first group of client devices; Based on one or more strategies for retraining the ML model and the received deployment information, determine the trigger for retraining the ML model. as well as Send a request to the second group of client devices to retrain the ML model.

2. The method of claim 1, wherein the user device is a federated learning user, and wherein the client device is a federated learning client.

3. The method of claim 1, wherein the strategy for retraining the ML model includes one or more triggering conditions for model retraining, and wherein the strategy for retraining the ML model includes performing one or more actions to be taken by the ML model deployment service based on the satisfied triggering conditions.

4. The method according to claim 3, wherein, One or more triggering conditions include at least one of the following: data drift associated with the ML model is detected by a first threshold number of the first group of client devices, or model drift associated with the ML model is detected by a second threshold number of the first group of client devices.

5. The method according to claim 3, wherein, One or more actions include adding client devices from the first group to the second group of client devices.

6. The method according to claim 1, wherein, Deployment information includes one or more of the following: statistical information on inferred data, performance information on the deployed ML model, information related to the resource consumption of using the deployed ML model, or information related to the time consumption of using the deployed ML model.

7. The method of claim 1, wherein the first group of client devices and the second group of client devices are determined based on a client clustering strategy associated with deployment configuration information.

8. An apparatus including a processor and a memory, the apparatus further including computer-executable instructions stored in the memory of the apparatus, wherein, when executed by the processor of the apparatus, the instructions cause the apparatus to perform the following operations: The request is received from the service provider and from the first client device in the first group of client devices for deploying a trained ML model on the first group of client devices and for sending deployment information associated with the deployment of the trained ML model, wherein the request includes one or more strategies associated with retraining the ML model; The first client device sends a response including deployment information, wherein the service provider is configured to determine whether to trigger retraining of the ML model based on one or more policies for retraining the ML model and the sent deployment information; as well as A request to retrain an ML model is received by a first client device and a second group of client devices, wherein the first client device is associated with the second group of client devices.

9. The apparatus according to claim 8, wherein, The first client device is a federated learning client.

10. The apparatus of claim 8, wherein the strategy for retraining the ML model includes one or more triggering conditions for model retraining, and wherein the strategy for retraining the ML model includes performing one or more actions to be taken to retrain the ML model based on the satisfied triggering conditions.

11. The apparatus according to claim 10, wherein, One or more triggering conditions include at least one of the following: data drift associated with the ML model is detected by a first threshold number of the first group of client devices, or model drift associated with the ML model is detected by a second threshold number of the first group of client devices.

12. The apparatus of claim 10, wherein one or more actions include adding a client device from the first group of client devices to the second group of client devices.

13. The apparatus according to claim 8, wherein, Deployment information includes one or more of the following: statistical information on inferred data, performance information on the deployed ML model, information related to the resource consumption of using the deployed ML model, or information related to the time consumption of using the deployed ML model.

14. The apparatus of claim 8, wherein the first group of client devices and the second group of client devices are determined based on a client clustering strategy associated with deployment configuration information.

Images