Method and device for realizing federal learning homework management service

Abstract

Federated learning (FL) may be deployed as a service by defining FL job management functionality. The FL service may have the ability to receive FL job specifications from the FL user, process and manage these FL jobs on behalf of the FL user through interaction with the FL client, and update the state of the FL jobs to the FL user during the processing of the FL jobs.

Description

Cross-references to related applications

[0001] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 507,131, filed June 9, 2023, the entire contents of which are incorporated herein by reference. Background Technology

[0002] Federated learning (FL) is a machine learning approach where an FL server manages the training of a machine learning model by utilizing multiple FL clients. Data privacy is a key aspect of federated learning, so data is stored locally on each client. The result is that data confidentiality is maintained across clients, yet the desired machine learning application can still be implemented by training the model using the federated learning clients. FL training is conducted in multiple rounds, where at the beginning of each round, the ML model, model parameters, and associated training parameters are transferred from the FL server to the FL clients, and after completing that round of training, the FL clients provide the FL server with model updates (including the updated model parameters). The FL server aggregates the model parameters, updates the global model, and uses the model updates to repeat training for the next round. Summary of the Invention

[0003] This paper discloses methods and apparatuses for enabling Federated Learning (FL) to be deployed as a service by defining FL job management functions. Methods and apparatuses for implementing an FL service are disclosed, which has the following capabilities: receiving FL job specifications from FL users, processing and managing these FL jobs on behalf of FL users through interaction with FL clients, and updating the status of FL jobs to FL users during FL job processing.

[0004] This overview is intended to present a set of ideas in a simplified form, which will be further described in the detailed embodiments below. This overview 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 features that address any or all of the shortcomings pointed out in any part of this disclosure. Attached Figure Description

[0005] A more detailed understanding can be obtained from the following description, provided in conjunction with the accompanying drawings in an exemplary manner.

[0006] Figure 1 An example of FL training rounds is shown; Figure 2 An overview of an exemplary FL job service is shown; Figure 3 An exemplary FL (Flexible Reading) work procedure is shown; Figure 4 An exemplary FL job management process is shown; Figure 5An exemplary FL job status process is shown; Figure 6 An exemplary end-to-end embodiment of a FL job is shown; Figure 7 An exemplary FL job graphical user interface (GUI) embodiment is shown; Figure 8A An exemplary communication system is illustrated; Figure 8B , 8C 8D is an exemplary system diagram of the RAN and core network; Figure 8E Another exemplary communication system is illustrated; Figure 8F This is a block diagram of an exemplary device or apparatus (e.g., a WTRU); and Figure 8G This is a block diagram of an exemplary computing system. Detailed Implementation

[0007] The following abbreviations have the following meanings: 3GPP: Third Generation Partnership Project 5GS: 5G system API: Application Programming Interface CSP: Cloud Service Provider FL: Federated Learning ML: Machine Learning The following terms may have the following meanings: The term "Federated Learning User (FL User)" can refer to a user device (e.g., computer, smartphone, tablet) equipped with computing, storage, and network connectivity resources capable of hosting user application software (e.g., web browser, application (app)) in order to perform FL-centric operations with the FL service. One such operation, as defined in the context of this disclosure, involves the FL user configuring the FL service to perform FL jobs on behalf of the FL user.

[0008] The term "Federated Learning Client (FL Client)" can refer to a network device (e.g., a device, gateway, or server) equipped with computing, storage, and network connectivity resources capable of hosting FL Client software (e.g., an FL Client application) and local data, whereby the FL Client uses the FL Client software and local data to perform operations such as training ML models in a federated manner.

[0009] The term "Federated Learning Service (FL Service)" can refer to a network device (e.g., a device, gateway, or server) equipped with computing, memory, and network connectivity resources capable of hosting FL Service software, where the FL Service software performs FL management operations such as receiving FL jobs, which the FL server uses to train ML models in a federated manner across FL clients.

[0010] The term "Federated Learning Job (FL Job)" can refer to a set of instructions and requirements defined by an FL user for training an ML model in a federated manner. FL users configure FL jobs on the FL service so that the FL service can offload and train ML models on behalf of the FL user in a federated manner.

[0011] The term "Federated Learning Training Round (FL Round)" can refer to a training iteration performed on an ML model in a federated manner by an FL client, where the training is managed by the FL service.

[0012] The term "Federated Learning Task (FL Task)" refers to a set of instructions and requirements sent by the FL service to multiple FL clients for training an ML model in a federated manner. An FL Task contains the client-specific configuration required to train the ML model to meet the conditions specified by the FL task. The FL service can generate FL Tasks for each round of federated training performed on the ML model. FL Tasks can be specified by the FL user or the FL service.

[0013] Federated Learning (FL) is a machine learning approach where an FL server manages the training of a machine learning model by utilizing multiple FL clients. Data privacy is a key aspect of federated learning, so data is stored locally on each client. The result is that data confidentiality is maintained across clients, yet the desired machine learning application can still be implemented by training the model using the federated learning clients. FL training is conducted in multiple rounds. At the beginning of each round, the ML model, model parameters, and associated training parameters are transferred from the FL server to the FL clients. After completing that round of training, the FL clients provide the FL server with model updates (including the updated model parameters). The FL server aggregates the model parameters, updates the global model, and uses the model updates to repeat training for the next round.

[0014] Figure 1 An example of federated learning training epochs 10 between an FL server and multiple FL clients is shown. In each training epoch, the FL server provides each FL client with an ML model, along with associated model parameters and training parameters. The FL clients use local data to train the ML model and send the updated model parameters to the FL server for aggregation. Training is repeated until a performance target is met.

[0015] For example, in step 1, the FL server can send the model and weights to one or more FL clients. In step 2, the FL server can send training parameters to one or more FL clients and begin training one or more FL clients. In step 3, one or more FL clients can send the updated model weights to the FL server.

[0016] In federated learning, FL users and FL clients are decoupled from each other and may not even communicate directly. FL users are experts in the ML application domain, possessing in-depth knowledge of the requirements of ML algorithms, but lack access to the data used to train those algorithms. On the other hand, FL clients possess the data used to train the ML algorithms but cannot manage the training of those algorithms throughout the federated learning process. FL clients may be unaware of the existence of other FL clients and, due to this decoupling, may be unable to receive requests from FL users.

[0017] This paper discloses methods and apparatuses for enabling Federated Learning (FL) to be deployed as a service by defining FL job management functions. Methods and apparatuses for implementing an FL service are disclosed, which has the following capabilities: receiving FL job specifications from FL users, processing and managing these FL jobs on behalf of FL users through interaction with FL clients, and updating the status of FL jobs to FL users during FL job processing.

[0018] Specifically, an FL service capable of performing the following operations is disclosed: • Receive an FL job creation or update request from an FL user containing FL job information, which includes one or more of the following types of information elements: oFL start and stop conditions oFL job priority o Types of ML models to be trained in a federated manner The type of problem (e.g., object classification) allows the FL service to identify one or more candidate machine learning algorithms to create an "experiment". The oFL client should be used for the data types of FL training rounds. o Multi-model training mode indication o Hyperparameter settings o Functions or scripts used to evaluate model performance oFL training environment requirements, such as the number of training rounds, FL client, and minimum number of data instances. o FL client configuration requirements for training ML algorithms (e.g., required operating environment, FL framework, algorithm name and version, runtime requirements, processor and memory requirements, minimum number of sample data, and maximum age of data) • Based on the received FL job information, perform one or more of the following operations: o Determine if the FL user has FL job permissions and is authorized to execute the FL job. Store FL job information so that the FL service can access and use this information when executing FL jobs. o Select an FL client that meets the FL assignment and FL training requirements. o Identify one or more FL tasks to be delegated to FL clients for federated training of ML models. o Determine whether / when to start the FL job • Send FL job creation / update responses to FL users, containing information such as the FL job ID and FL job status. • Send an FL task request containing FL task information to the FL client. This FL task information includes one or more of the following types of information: oFL task ID and / or the FL job ID associated with that task. oFL task priority o FL round number associated with FL task oFL task start or stop conditions oFL task function The oFL client requires the necessary FL client configuration settings to meet training requirements. oML algorithm, corresponding version, and initial model parameters o Hyperparameters used in the ML training process o Data Filter • Send FL task subscription or retrieval requests to FL clients to obtain FL task results and status information. • Receive FL task results and status information from the FL client, including information such as: Changes in the oFL task status (e.g., started, paused, resumed, canceled, completed). The training / performance threshold of the oML model reaches a certain level. Changes in the state of the oFL client (e.g., availability, error conditions, FL task completion). o Updated model parameters o Model training results (e.g., model accuracy and performance results) • Based on information received from the FL client, determine whether to perform additional FL training rounds by aggregating the information and comparing it with the ML requirements specified by the FL user in the FL job. • Receive FL job subscription or retrieval requests from FL users to obtain FL job results and status information of interest to FL users. • Send FL job results and status information to FL users, containing one or more of the following types of information: Changes in the status of oFL jobs (e.g., started, paused, resumed, canceled, completed). An indication that the training / performance threshold of an oML model has reached a certain level. Changes in the state of the oFL client (e.g., availability, error conditions, FL task completion). As described in this document, the FL service assists FL users in using FL clients that carry local data that must remain locally (e.g., for privacy or ownership reasons) to train machine learning models in a federated manner. The FL service provides interfaces and corresponding services to FL users and FL clients. Through the FL user interface, FL users can configure FL jobs on the FL service. FL jobs can include user-defined instructions and requirements that the FL service can use to manage federated training of ML models on behalf of FL users in a service-based manner. The FL user interface also supports the ability of FL users to check the status of FL jobs and, if necessary, modify the configuration of FL jobs during FL service processing. To execute FL jobs, the FL service can interface with FL clients and instruct these clients to perform federated training operations. When interfacing with FL clients, the FL service can configure FL tasks for the FL clients. FL tasks can include configurations and / or sets of instructions used by the FL client to train ML models in a federated manner. Federated training can involve multiple rounds of training, where the FL client performs ML model training operations, shares training results with the FL service, receives updated ML models from the FL service, and then performs additional training rounds. Training epochs can continue until the FL service determines that the ML model has reached the required training level (e.g., reaching a specific model accuracy defined by the FL user within the FL job). FL tasks shared between the FL server and FL clients can be specified at the granularity of a single FL training epoch or at the granularity of multiple training epochs.

[0019] Figure 2 A high-level example 200 is provided, illustrating the various processes involved in an FL user configuring an FL job with the FL service: job specification, job management, and job status processes. Using information defined within the FL job, the FL service can coordinate FL training epochs with the FL client to train an ML model in a federated manner that meets the FL user's requirements. The FL service can provide FL job status information to the FL user throughout the FL job's duration. Therefore, the FL user can monitor the progress of the FL job and / or take actions such as updating the FL job to notify the FL service of changes.

[0020] Specifying an FL job involves FL users providing requirements for their ML applications to the FL service. As part of these requirements, FL users can specify the need to utilize federated learning to train a particular algorithm using data that may be available at the FL client. The FL service can use these requirements to manage the federated training of machine learning models across a collection of FL clients. The information specified in an FL job can include various elements, such as one or more machine learning algorithms or models, hyperparameters used for the relevant models, and stopping criteria defining when a model is sufficiently trained.

[0021] In the example, a device associated with the FL service can receive requests from FL users to create or update FL jobs. This request may contain FL job information indicating one or more machine learning (ML) requirements and one or more FL training requirements. The one or more ML requirements may indicate at least one of the following: one or more ML algorithms, ML problem type, multi-model training mode, one or more hyperparameters, model evaluation function, model initialization, aggregation algorithm, minimum number of FL training epochs, minimum number of FL clients, and minimum number of total data instances. The one or more FL training requirements may include at least one of the following: specified operating environment, FL framework, algorithm name and version, one or more runtime requirements, one or more processor and memory requirements, minimum number of sample data, and maximum data age. The FL job information may also indicate FL client configuration, which indicates at least one of the following: a list of FL client IDs, one or more FL client training requirements, and FL client data filters. Based on the FL job information, the device may perform at least one of the following: determining whether the FL user is authorized to execute the FL job, selecting one or more FL clients that meet one or more FL training requirements, and determining one or more FL tasks associated with the FL job to be executed by one or more FL clients. This device can send a response containing the FL job ID and FL request status information to the FL user. This device can send one or more FL task requests containing FL task information to one or more FL clients. This device can receive FL task status information from one or more FL clients. This device can determine whether to execute one or more FL training rounds based on the received FL task status information. It can determine whether to execute one or more FL training rounds by aggregating the received FL task status information and comparing it with the ML requirements specified by the FL user in the FL job. This device can send FL job status information to the FL user. The FL job status information can indicate at least one of the following: whether the FL job has not started, has started, has been paused, has been resumed, has been stopped, has been canceled, or has been completed; and the current FL round number.

[0022] In another example, a device associated with FL can receive one or more FL task requests containing FL task information from the FL service, wherein the FL task information indicates one or more machine learning (ML) requirements and one or more FL training requirements. The device can execute one or more FL tasks based on the one or more FL task requests. The device can send one or more notifications containing FL task status information to the FL service.

[0023] Figure 3 Example 300 of the FL job specification process is shown, which includes the creation and updating of FL jobs initiated by FL users to the FL service. FL jobs can be created to begin training ML models in a federated manner, and FL users can also update FL jobs to provide additional FL job information to the FL service.

[0024] In step 1, an FL user can issue one or more requests to the FL service to create and configure an FL job. Within these requests, the FL user can specify FL job information, such as, but not limited to, the information defined in Table 1. Note that the FL user can only provide the configuration information listed in Table 1 and cannot provide other information that the FL service can return to the FL user, such as the FL job status, FL job results, and a list of FL client IDs. For example, the request may include the type of model to be trained in a federated manner and performance criteria for determining when to stop training. The request may also include the problem type (e.g., object classification) so that the FL service can identify one or more candidate machine learning algorithms to create an "experiment." The request may also include the data type that the FL client should use for FL training epochs. For example, if the FL client has images of cars, trucks, and motorcycles, the FL user can specify that only motorcycle images are needed for training. The request may also include FL client requirements for training the ML algorithm. Examples of training requirements for the FL client could be: required operating environment, FL framework, algorithm name and version, runtime requirements, processor and memory requirements, minimum number of sample data, and maximum age of the data. Other high-level FL configurations, such as the minimum number of training epochs, the minimum number of FL clients (for each training epoch and for the entire FL process), and the minimum number of total data instances, can also be provided by the FL user.

[0025]

[0026] In step 2, upon receiving a request, the FL service can check whether the FL client is authorized to access the FL service and create an FL job. To perform this check, the FL service can check whether the FL user has the FL job creation permissions defined in the FL service's access control policy. Additionally, the FL service can check one or more individual information elements configured in the FL job request to determine if the FL user has the necessary permissions. For example, whether the FL user has permission to perform FL training operations on the specified FL client, or permission to access and use the specified ML algorithm. If authorization is successful, the FL service can create the FL job by storing the FL job information defined in Table 1, making it accessible to the FL service. The FL job information can be stored locally on the FL service or in another service interconnected with the FL service (e.g., a storage service). Furthermore, the FL service can determine whether any FL job-centric operations need to be performed, such as initiating FL job processing. This determination can be made using specified FL job initiation conditions.

[0027] The FL service can also use FL job information received from FL users to determine and select FL clients capable of providing the datasets required for FL training. FL job information can instruct the FL service to select a minimum number of FL clients and determine whether the aggregated data instances from all FL clients meet the minimum number of data instances required for a single FL client and for the entire FL process.

[0028] In step 3, the FL service may return a response to the FL user. This response may include one or more information elements defined in Table 1. For example, the FL service may have assigned an FL job ID and include that identifier in the response. The response may also include additional information, such as a status code indicating whether the FL job has been created. If the FL service fails to create the FL job, an error code may accompany the response status to indicate why the FL service failed to create the FL job. Examples of error codes may include: insufficient FL clients found, insufficient number of data instances found, ML algorithm unavailable, aggregation algorithm unavailable, data exceeding maximum age, etc.

[0029] In step 4, once an FL job is created, the FL user can send a follow-up request to the FL service to update the FL job. The update request may include one or more information elements, such as, but not limited to, those defined in Table 1. For example, if the FL job start conditions were not defined when the user created the FL job, the FL user can send an FL job update request to manually trigger the FL service to start the FL job associated with the FL job ID (e.g., by configuring FL job control information elements). In another example, the FL user may determine during FL training that parameters of the FL job or FL task need to be modified (e.g., selecting or deselecting certain FL clients, updating stopping criteria, changing the ML algorithm / model, etc.).

[0030] In step 5, upon receiving an FL job update request, the FL service can check whether the FL job ID references a valid FL job and whether the FL user is authorized to access the FL service and update this FL job. To perform this check, the FL service can use a similar check as defined in step 2. If authorization is successful, the FL service can update the FL job information using one or more information elements specified in the request, thereby updating the FL job. Furthermore, the FL service can determine whether any FL job-centric operations need to be performed, such as starting, pausing, restarting, or stopping the FL job's processing.

[0031] In step 6, the FL service can return a response to the FL user. This response may include one or more information elements defined in Table 1. For example, the response may contain information elements indicating successful updates and their values. The response may also include additional information, such as a status code indicating whether the FL job has been updated.

[0032] Figure 4 An example of an FL job management process 400 is shown. Once an FL user configures an FL job for the FL service, the FL service can process and manage the FL job on behalf of the FL user. During FL job processing, the FL service can perform one or more operations, such as, but not limited to, […]. Figure 4 The operations defined in the documentation. For example, the FL service can determine whether / when to start, pause, restart, and terminate an FL job. The FL service can determine one or more ML algorithms / models to be trained in a federated manner, the hyperparameters to be used, the FL clients to perform FL training, and the individual FL tasks configured by the FL service for each FL client to perform the training.

[0033] In step 1, based on information configured within the specified FL job, the FL service can determine whether / when to start the FL job. For example, the FL service can monitor whether / when conditions specified in the "FL Job Start Conditions" information element defined in Table 1 are met, such as specified relative time, absolute time values, or specified condition expressions. Condition expressions can include one or more conditions monitored by the FL service. Conditions can include the name and / or reference of resources accessible to the FL service, such as the URI of an FL service resource (e.g., an FL client digital twin resource). Conditions can also include operators (e.g., <, >, =, <=, =>) and comparison values ​​(e.g., thresholds). Alternatively, the FL service can receive explicit requests from FL users to trigger the FL service to start the FL job. For example, the FL service can receive a request to update the "FL Job Control" information element defined in Table 1, which triggers the FL service to start the FL job.

[0034] In step 2, the FL service can send a request to the FL client to create FL tasks for coordinating and managing the federated training of ML algorithms / models. The FL service can create one or more FL tasks on each FL client. Each FL task can include information such as, but not limited to, the information elements defined in Table 2. For example, an FL task can include the required FL client configuration settings that the FL client will use to meet training requirements. Some example settings may include FL client configuration, ML algorithm and its corresponding version, initial model parameters, and hyperparameters used for the ML training process. To determine the information to be included in a given FL task for a given FL client, the FL service can rely on information specified by the FL user in the FL job information defined in Table 1, information from other sources (such as pre-configured FL service policies or interactions performed by the FL service with other services in the system), and / or information about the FL client that the FL service has obtained and / or configured. The FL service can configure FL tasks for FL clients at different times during FL job processing. For example, the FL service can perform multiple rounds of federated training to train ML algorithms / models in a federated manner. At the start of each federated training round, the FL service can send a request to each FL client to create the FL task that the FL client will execute in that round.

[0035] Instead of the FL service sending a request to the FL client to create an FL task, the FL service adds the FL task to the FL client task queue, which is stored and maintained by the FL service. Figure 4(Not shown in the text). FL clients can subscribe to these FL client task queues maintained by the FL service. When a new FL task is added to the queue, the FL service can send a notification to the corresponding FL client. The notification can contain FL task information. The FL client can return a response to the FL service to confirm receipt of the FL task information. The response can contain information such as the estimated time to complete the FL training task. FL client task queues can store multiple FL tasks for a single FL client. For example, separate tasks can be placed in the queue for different ML algorithms / models for which the FL service wants the FL client to perform training operations. The FL service can sort FL tasks in the queue based on priority (e.g., using priority information defined by the FL user in the FL job, or using internal FL service policies). If the FL client has sufficient resources, it can process multiple FL tasks in parallel.

[0036]

[0037] Before the FL service creates an FL task on the FL client, the FL client and the FL service can establish a connection with each other. This connection can be initiated by either the FL client or the FL service. In addition to exchanging connection-related information (such as unique network addresses and authentication credentials), FL client capabilities (such as, but not limited to, those defined in Table 3) can also be provided to the FL service by the FL client when the connection is established. For example, the FL client ID, environment and resources, supported ML algorithms, and dataset information can be provided by the FL client.

[0038]

[0039] In step 3, upon receiving the request, the FL client can check whether the FL service is authorized to access the FL client and create an FL task. To perform this check, the FL client can check whether the FL service has the FL task creation permissions defined in the FL client's access control policy. Additionally, the FL client can check one or more individual information elements configured in the FL task information included in the request to determine whether the FL service has the necessary permissions. For example, whether the FL service has permission to configure the specified ML algorithm / model and / or FL task function for the FL client. If authorization is successful, the FL client can create an FL task by storing the specified FL task information, making it accessible to the FL client. The FL task information can be stored locally on the FL client or in another service interconnected with the FL client (e.g., a storage service). Furthermore, the FL client can determine whether any FL task-centric operations need to be performed, such as initiating FL task processing. This determination can be made using specified FL task initiation conditions.

[0040] In step 4, the FL client can return a response to the FL service. This response may include one or more information elements defined in Table 2, such as the FL task ID. The response may also include additional information, such as a status code indicating whether the FL task has been created.

[0041] In step 5, once an FL task is created, the FL service can send a follow-up request to the FL client to update the FL task. The update request may include one or more information elements, such as, but not limited to, those defined in Table 2. For example, if the FL task start conditions are not defined when the FL service creates the FL task, the FL service can send an FL task update request to manually trigger the FL client to start the FL task (e.g., by configuring FL task control information elements).

[0042] In step 6, upon receiving an FL update request, the FL client can check whether the FL job ID and / or FL task ID in the request references a valid FL job and / or FL task, and whether the FL service is authorized to access the FL client and update this FL task. To perform this check, the FL client can use a similar check as defined in step 3. If authorization is successful, the FL client can use one or more information elements specified in the request to update the FL task information, thereby updating the FL task. Furthermore, the FL client can determine whether any FL task-centric operations need to be performed, such as starting, pausing, restarting, or stopping processing of the FL task.

[0043] In step 7, the FL client can return a response to the FL service. This response may include one or more information elements defined in Table 2. For example, the response may contain an information element indicating successful update and its value. The response may also include additional information, such as a status code indicating whether the FL task has been updated.

[0044] In step 8, the FL client executes the FL task specified by the FL service. When executing an FL task, the FL client can check the priority defined in the FL task information to determine the order in which it should be executed relative to other FL tasks that need to be executed. The FL client can also process and execute one or more FL functions (e.g., scripts) defined by the FL service in the FL task information. This may require the FL client to access and / or download the function / script from the location (URI / URL) configured in the FL task information. The FL client can also download and / or select one or more ML algorithms / models based on information configured in the FL task information (e.g., ML algorithm / model type, identifier, and / or location (e.g., URI / URL)). The FL client can apply the initial model parameters configured in the FL task information to the ML algorithm / model. The FL client can apply data filters to its training data used to train the ML algorithm / model. The FL client can use the FL task stop conditions and / or FL task control information configured in the FL task information to determine when to stop training. The FL client can also update the FL task status information within the FL task information during FL task processing.

[0045] In step 9, the FL service can send an FL task retrieval request to the FL client to retrieve FL task information. For example, the FL service can retrieve FL status information from the FL client to determine FL training results and / or progress information.

[0046] In step 10, upon receiving an FL task retrieval request, the FL client can respond with the requested FL task information. For example, the FL client can respond with the entire FL task information or a subset of information elements within the FL task information, such as the FL client ID, FL task ID, FL job ID, FL round number, and FL task status.

[0047] In step 11, as an alternative to or supplement to retrieving FL task information from the FL client, the FL service may send a subscription request to the FL service to subscribe to FL tasks and receive notifications from the FL client if / when notification criteria associated with the FL task are met. The subscription request may include notification criteria. Notification criteria may include one or more conditions. Conditions may refer to information elements defined within the FL task information. For example, notification criteria may include a condition when the FL task status is equal to "completed".

[0048] In step 12, upon receiving an FL task subscription request, the FL client can create an FL task subscription by storing subscription information that makes it accessible to other FL clients. The FL task subscription can be stored locally on the FL client or in another service interconnected with the FL client (e.g., a storage service). Furthermore, the FL client can begin monitoring specified notification criteria to determine whether / when the criteria are met.

[0049] In step 13, the FL client can return a response to the FL service. This response may contain the FL task subscription ID. The response may also include additional information, such as a status code indicating whether the FL task subscription was successfully created.

[0050] In step 14, if / when the FL client detects that the notification criteria defined within the FL task subscription have been met, the FL client can generate an FL task notification and send it to the FL service. The notification may include the FL service ID, FL client ID, FL job ID, FL task ID, FL round number, FL task status, and / or FL task subscription ID. The notification may also include additional information, such as the FL task information defined in Table 2.

[0051] In step 15, the FL service can return a response to the FL client, indicating that the notification has been received. The response may include the FL service ID and / or the FL task subscription ID. The response may also include additional information, such as a status code indicating whether the FL task notification was successfully received and processed.

[0052] Note that steps 2 through 15 can be repeated for each FL training epoch (for the selected FL client) until the FL task stopping condition is met. In subsequent FL training epochs, if the FL task configuration used for the FL client remains unchanged, the FL service can send an FL task update request to the FL client without creating a new FL task (skipping steps 2 through 4). Depending on whether the FL service prefers to retrieve FL status and results from the FL client, the FL service can choose to perform steps 9 and 10, or steps 11 through 15. Although not shown in the diagram, the FL client can instead send messages to the FL service to share FL status and results. For example, the FL service can provide the FL client with contact information (e.g., within the FL task information), which the FL client uses to direct the request.

[0053] During FL job processing, the FL service may perform additional FL job management operations not described in steps 1 through 15. For example, before combining the model parameters received by the FL service from the FL client in each FL training round, the FL service may perform some analysis on the parameters to evaluate the quality of the updated parameters. The model parameters from the FL client can then be selected based on the analysis evaluation and aggregated using a dynamic or user-defined algorithm that produces a single global model. The FL service may also maintain a model repository to which the FL client can send updated model parameters. This model repository may also be used by the FL service to store the initial global model used in the FL process, intermediate models from the FL client, and / or the aggregated global model from each FL training round. The model repository may require appropriate authentication for FL client access, ensuring that the FL client can only access the global model and not intermediate model updates generated by other FL clients. The FL service may also allow FL users to specify policies and criteria for accepting and analyzing model parameters returned from the FL client. For example, policies and scripts specified by the FL user can be used by the FL service to process model parameters provided by the FL client. The model repository may contain information such as, but not limited to, that captured in Table 4.

[0054]

[0055] Figure 5 An exemplary FL job status process 500 is shown. For example... Figure 5 As shown, the FL service can provide FL users with status information about FL jobs. The FL service can provide FL job status during the active processing and execution of an FL job, or when an FL job completes successfully or unsuccessfully. The status of an FL job can be shared with FL users by allowing them to retrieve the status from the FL service. Alternatively, FL users can subscribe to receive FL job notifications from the FL service if / when an event related to the FL job that is of interest to them occurs.

[0056] When a client starts an FL task, it can provide status updates for each FL task it executes. The FL service can selectively consolidate and / or forward FL task status updates to FL users. The FL service can monitor FL task updates for each FL task and FL job, allowing FL users to monitor the progress of FL jobs. As FL clients execute FL tasks that support FL jobs, users can monitor the status of FL jobs or supporting FL tasks. Using this information, FL users can understand the situation and use it to determine whether to modify FL jobs and pending tasks for a specific FL client, remove FL clients from FL jobs, add new FL clients to FL jobs, or exclude results (i.e., model parameters) from a particular FL client that continues to participate in the FL process.

[0057] In step 1, the FL service updates the status of the FL job. The status can include changes to the FL job's status, such as whether the FL job has started, been paused, resumed, stopped, or completed. The status can include FL job results, such as whether the FL job completed successfully, encountered an error, reached a certain model accuracy or performance level, completed a training epoch or task, or that the trained model and / or model parameters are ready for FL users. The status can include changes related to one or more FL clients associated with the FL job or one or more FL tasks associated with these FL clients and the FL job. For example, changes to the status of FL tasks associated with FL clients, such as whether the FL task has started, been paused, resumed, stopped, or completed. The status can include FL task results, such as whether the FL task completed successfully or encountered an error. The status can indicate changes to the configuration, resources, or availability of the FL client.

[0058] In step 2, FL users can send an FL job retrieval request to the FL service to retrieve FL job information. For example, FL users can retrieve FL job status and result information from the FL service to determine FL training results and / or progress information.

[0059] In step 3, upon receiving an FL job retrieval request, the FL service can respond with the requested FL job information. For example, the FL service can respond with the entire FL job or a subset of information elements within the FL job, such as the FL job ID, FL job status, and / or FL job results.

[0060] In step 4, instead of retrieving FL job information from the FL service, the FL user can send a subscription request to the FL service to subscribe to FL jobs and receive notifications from the FL service if / when notification criteria associated with the FL job are met. The subscription request may include notification criteria. Notification criteria may include one or more conditions. Conditions may refer to information elements defined within the FL job. For example, notification criteria may include conditions when the FL job status value changes.

[0061] In step 5, upon receiving an FL job subscription request, the FL service can create an FL job subscription by storing subscription information that makes it accessible to other FL services. The FL job subscription can be stored locally on the FL service or in another service interconnected with the FL service (e.g., a storage service). Furthermore, the FL service can begin monitoring specified notification criteria to determine whether / when the criteria are met.

[0062] In step 6, the FL service can return a response to the FL user. This response may contain the FL job subscription ID. The response may also include additional information, such as a status code indicating whether the FL job subscription was successfully created.

[0063] In step 7, if / when the FL service detects that the notification criteria defined within the FL job subscription have been met, the FL service may generate an FL job notification and send it to the FL user. The notification may include the FL service ID, FL job ID, FL round number, FL job status, and / or FL job subscription ID. The notification may also include additional information, such as, but not limited to, the FL job information defined in Table 1.

[0064] In step 8, the FL service can return a response to the FL client, indicating that the notification has been received. The response may include the FL service ID and / or the FL task subscription ID. The response may also include additional information, such as a status code indicating whether the FL task notification was successfully received and processed.

[0065] It should be noted that steps 1 through 8 can occur at different times in the FL job lifecycle. For example, the FL service may receive these requests while it is actively processing the FL job. Alternatively, these steps may occur when the FL service has finished processing the FL job. Depending on whether the FL user prefers to retrieve the FL status and results from the FL service, the FL user may choose to perform steps 2 and 3, or steps 4 through 8.

[0066] Figure 6 An exemplary end-to-end embodiment 600 involving FL users, FL services, and FL clients is illustrated. In this embodiment, the operations defined in the above procedures are shown together in the example. It should be noted that this embodiment is an example of how the above procedures interact with each other. Other embodiments are also conceivable.

[0067] Steps 1 to 3 correspond Figure 3 Steps 1 through 3. FL users can have ML training applications that can benefit from FL training and can make requests to the FL service to manage federated training. FL users can provide the information shown in Table 1 for FL jobs. If successful, the FL service can create an FL job and assign an FL ID to it.

[0068] Steps 4 to 6 correspond Figure 5 Steps 4 through 6. FL users may want to receive notifications from the FL service regarding the progress of FL jobs. Therefore, FL users can send a subscription request to the FL service with the FL job ID. The subscription request can specify the notification criteria for when FL users should be notified.

[0069] In step 7, if the FL job start condition IE is configured, the FL job can start automatically or can be started by an explicit request from the FL user. In this example, the FL job starts based on the conditions specified in the FL job start condition IE.

[0070] Steps 8 to 10 correspond to Figure 4 Steps 2 through 4. The FL service can create FL-specific tasks on each FL client participating in FL training. Tasks can be configured to coordinate and manage ML algorithm / model training in a federated manner. FL task information can be specified as shown in Table 2.

[0071] Steps 11 to 13 correspond to Figure 4 Steps 8 through 10. Each FL client can execute the FL task specified by the task information configured by the FL service. The FL service can retrieve FL status information from the FL client to check the progress of the training task.

[0072] Steps 14 and 15 correspond to Figure 5 Steps 7 and 8. The FL service can send notifications to FL users to provide task progress updates. Subscription conditions can request the FL service to notify FL users of task status updates.

[0073] Steps 16 to 18 correspond to Figure 3 Steps 4 through 6. For example, in response to an FL job notification, an FL user may want to update FL job information to modify the start or stop conditions of the FL job, modify the priority of the FL job relative to other FL jobs, switch the ML algorithm associated with the FL job, modify the hyperparameters of the FL job, modify the aggregation algorithm, modify the minimum number of training epochs, modify the minimum number of FL clients, modify the minimum number of total data instances, or change the configuration of the FL clients.

[0074] Steps 19 to 20 correspond to Figure 4Steps 11 through 13. The FL service subscribes to certain notification guidelines from the FL client. For example, the FL service can subscribe to the FL client to detect whether / when updates to the FL client's task status occur, such as when the FL client starts, pauses, resumes, cancels, or completes an FL task.

[0075] Steps 21 to 23 correspond to Figure 4 Steps 5 through 7. For example, in response to receiving an FL job information update from an FL user (as shown in steps 16 through 18), the FL service can update the corresponding task to the FL client. For example, if the FL user modifies the minimum number of data instances and / or the FL client configuration, the FL service can update the FL client accordingly.

[0076] In step 24, each FL client can execute the task update specified from the task received from the FL service.

[0077] Steps 25 and 26 correspond to Figure 4 Steps 14 and 15. At a later point in time, the event is triggered, and if the event matches the notification criteria event specified in the subscription, one or more FL clients can send a notification to the FL service.

[0078] In step 27, the FL service can update the job status based on the notification received from the FL client.

[0079] Steps 28 and 29 correspond to Figure 5 Steps 2 and 3. At any time during the FL job operation, the FL user can issue a retrieval request to obtain updates on the FL job status. The FL user may wish to check the job status or retrieve information about the FL job.

[0080] One method to implement the aforementioned FL service data preparation functionality is through the RESTful API supported by the FL service. This RESTful API can include one or more different types of resources provided and stored by the FL service, accessible to FL clients and users through RESTful operations commonly referred to as methods (e.g., PUT, POST, GET, DELETE). Each resource type defined for the API can include a set of defined information elements (commonly referred to as attributes). These resource types and their respective attributes provide the FL service with a means to receive information from FL clients and users using RESTful protocols (such as HTTP), process the information by performing FL service-specific tasks, and return the results of these operations to the FL clients and users. Therefore, the RESTful API is used by FL clients and users to interact with the FL service in a RESTful manner and access the functionality supported by the FL service.

[0081] The RESTful API of the FL service can support FL job resource types. These FL job resources can include, but are not limited to, attributes defined in Table 1. Other high-level FL configurations, such as the minimum number of training epochs, the minimum number of FL clients (for each training epoch and for the entire FL process), and the minimum number of total data instances, can also be provided by the FL user.

[0082] The FL service can also support FL task resource types. These FL task resources can include attributes such as, but not limited to, the information elements defined in Table 2.

[0083] The FL service can also support FL client resource types. These FL client resources can include, but are not limited to, the attributes defined in Table 3.

[0084] The FL service can also support ML model parameter repository resource types. This ML model parameter repository resource can include attributes such as, but not limited to, the information elements defined in Table 4.

[0085] The FL service can also support additional resource types. For example, the FL service can support resource types that FL clients can use to queue and receive FL tasks from the FL service. This resource can be separate from the FL client or FL task resource types mentioned above.

[0086] The FL job, FL task, FL client, and FL model parameter related information elements defined in Tables 1, 2, 3, and / or 4 above can be incorporated into the GUI. One or more of these information elements can be incorporated.

[0087] Figure 7 An example of an FL job GUI implementation 700 is shown. FL users can interact with the FL service through this GUI to perform the operations defined above in this invention. For example, FL users can use this GUI to configure FL jobs for the FL service and monitor and track the status of the FL job while it is being executed.

[0088] Exemplary communication system The 3rd Generation Partnership Project (3GPP) develops technical standards for cellular telecommunications networks, encompassing radio access, core transport networks, and service capabilities—including codecs, security, and quality of service. Recent Radio Access Technology (RAT) standards include WCDMA (commonly referred to as 3G), LTE (commonly referred to as 4G), LTE-Advanced, and New Radio (NR), also known as "5G." 3GPP NR standard development is expected to continue and include the definition of next-generation radio access technologies (new RATs), anticipated to include new flexible radio access below 7 GHz and new ultra-mobile broadband radio access above 7 GHz. Flexible radio access is expected to consist of new, non-backward-compatible radio access in the new spectrum below 7 GHz and is expected to include different operating modes that can be multiplexed together in the same spectrum to address a wide range of 3GPP NR use cases with varying requirements. Ultra-mobile broadband is expected to include centimeter-wave and millimeter-wave spectrum, providing opportunities for ultra-mobile broadband access for applications such as indoor spaces and hotspots. In particular, ultra-mobile broadband is expected to share a common design framework with flexible radio access below 7 GHz and will have centimeter-wave and millimeter-wave-specific design optimizations.

[0089] 3GPP has identified a variety of use cases that NR is expected to support, resulting in diverse user experience requirements regarding data rates, latency, and mobility. These use cases fall into the following general categories: enhanced mobile broadband (eMBB), ultra-reliable low-latency communications (URLLC), massive machine-type communications (mMTC), network operations (e.g., network slicing, routing, migration and interworking, energy saving), and enhanced vehicle-to-everything (eV2X) communications, which can include vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), vehicle-to-network (V2N), vehicle-to-pedestrian (V2P), and vehicle-to-other-entities communications. Specific services and applications within these categories include, for example, monitoring and sensor networks, remote device control, two-way remote control, personal cloud computing, video streaming, wireless cloud-based office, first responder connectivity, car emergency calls, disaster alerts, real-time gaming, multi-person video calls, autonomous driving, augmented reality, haptic internet, virtual reality, home automation, robotics, and aerial drones. All of these use cases, and others, are covered in this document.

[0090] Figure 8AAn exemplary communication system 100 is illustrated, in which the described and claimed systems, methods, and apparatuses can be used. Communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, 102e, 102f, and / or 102g, generally or collectively referred to as WTRU 102 or WTRU 102. Communication system 100 may include 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 network services 113. Network services 113 may include, for example, V2X servers, V2X functions, ProSe servers, ProSe functions, IoT services, video streaming, and / or edge computing, etc.

[0091] It is understood that the concepts disclosed herein can be used with any number of WTRUs, base stations, networks, and / or network elements. Each WTRU 102 can be any type of device or apparatus configured to operate and / or communicate in a wireless environment. Figure 8A In the example, each WTRU 102 in Figures 8A to 8E The device is described as a handheld wireless communication device. It should be understood that, given the wide range of use cases for wireless communication, each WTRU may include or be included in any type of device or apparatus configured to transmit and / or receive wireless signals, which, by way of example only, includes 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 e-health devices, robots, industrial equipment, drones, vehicles (such as cars, buses or trucks), trains or airplanes, etc.

[0092] The communication system 100 may also include base station 114a and base station 114b. Figure 8AIn the example, each base station 114a and 114b is depicted as a single element. In practice, base stations 114a and 114b may include any number of interconnected base stations and / or network elements. Base station 114a may be any type of device configured to connect to at least one of the WTRUs 102a, 102b, and 102c via a wireless interface to facilitate access to one or more communication networks (e.g., core network 106 / 107 / 109, Internet 110, network service 113, and / or other network 112). Similarly, base station 114b may be any type of device configured to connect via wired and / or wireless interfaces to at least one of the Remote Radio Headers (RRHs) 118a and 118b, Transmit and Receive Points (TRPs) 119a and 119b, and / or Roadside Units (RSUs) 120a and 120b to facilitate access to one or more communication networks (e.g., core network 106 / 107 / 109, Internet 110, other network 112, and / or network service 113). RRH 118a, 118b can be any type of device configured to connect to at least one wireless interface in WTRU 102 (e.g., WTRU 102c) to facilitate access to one or more communication networks (e.g., core network 106 / 107 / 109, Internet 110, network service 113 and / or other network 112).

[0093] TRPs 119a and 119b can be any type of device configured to connect to at least one radio interface of WTRU 102d to facilitate access to one or more communication networks (e.g., core network 106 / 107 / 109, Internet 110, network service 113, and / or other network 112). RSUs 120a and 120b can be any type of device configured to connect to at least one radio interface of WTRU 102e or 102f to facilitate access to one or more communication networks (e.g., core network 106 / 107 / 109, Internet 110, other network 112, and / or network service 113). For example, base stations 114a and 114b can be base transceiver stations (BTS), Node-B, eNode B, home Node B, home eNode B, next-generation Node-B (gNode B), satellite, site controller, access point (AP), wireless router, etc.

[0094] 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. Similarly, 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 BSC, 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 called a cell (not shown). Similarly, base station 114b may be configured to transmit and / or receive wired and / or radio signals within a specific geographical area, which may be called a cell (not shown). A cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Therefore, for example, base station 114a may include three transceivers, such as one transceiver per cell sector. Base station 114a may employ multiple-input multiple-output (MIMO) technology, thus, for example, multiple transceivers may be used for each sector of the cell.

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

[0096] Base station 114b can communicate with one or more of RRH 118a and 118b, TRP 119a and 119b, and / or RSU 120a and 120b via wired or air interfaces 115b / 116b / 117b. The wired or air interfaces 115b / 116b / 117b can be any suitable wired (e.g., cable, fiber optic, etc.) or wireless communication link (e.g., RF, microwave, IR, UV, visible light, centimeter wave, millimeter wave, etc.). Air interfaces 115b / 116b / 117b can be established using any suitable RAT.

[0097] RRH 118a, 118b, TRP 119a, 119b and / or RSU 120a, 120b can communicate with one or more 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., RF, microwave, IR, UV, visible light, centimeter wave, millimeter wave, etc.). Air interface 115c / 116c / 117c can be established using any suitable RAT.

[0098] WTRU 102 can communicate with each other via direct air interfaces 115d / 116d / 117d, such as sidelink communication, which can be any suitable wireless communication link (e.g., RF, microwave, IR, UV, visible light, centimeter wave, millimeter wave, etc.). Air interfaces 115d / 116d / 117d can be established using any suitable RAT.

[0099] 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 station 114a in RAN 103 / 104 / 105 and WTRU 102a, 102b, 102c, or RRH 118a, 118b, TRP 119a, 119b and / or RSU 120a and 120b with WTRU 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), and UTRA can respectively use Wideband CDMA (WCDMA) to establish air interfaces 115 / 116 / 117 and / or 115c / 116c / 117c. 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).

[0100] Base station 114a in RAN 103 / 104 / 105 and WTRU 102a, 102b, 102c and 102g, or RRH 118a and 118b, TRP 119a and 119b, and / or RSU 120a and 120b and WTRU 102c and 102d in RAN 103b / 104b / 105b, can implement radio technologies such as Evolved UMTS Terrestrial Radio Access (E-UTRA). E-UTRA can, for example, use Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A) to establish air interfaces 115 / 116 / 117 or 115c / 116c / 117c, respectively. Air interfaces 115 / 116 / 117 or 115c / 116c / 117c can implement 3GPP NR technology. LTE and LTE-A technologies may include LTE D2D and / or V2X technologies and interfaces (such as sidelink communication). Similarly, 3GPP NR technologies may include NR V2X technologies and interfaces (such as sidelink communication).

[0101] Base station 114a in RAN 103 / 104 / 105 with WTRU 102a, 102b, 102c and 102g or RRH 118a and 118b, TRP 119a and 119b in RAN 103b / 104b / 105b, and / or RSU 120a and 120b with WTRU 102c, 102d, 102e and 102f 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 Data Rate GSM Evolution (EDGE), GSMEDGE (GERAN) and others.

[0102] Figure 8ABase station 114c can be, for example, a wireless router, home Node B, home eNode B, or access point, and can utilize any suitable RAT to facilitate wireless connectivity in local areas (e.g., business premises, homes, vehicles, trains, air, satellite, factories, campuses, etc.). Base station 114c and WTRU 102 (e.g., WTRU 102e) can implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). Similarly, base station 114c and WTRU 102 (e.g., WTRU 102d) can implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). Base station 114c and WTRU 102 (e.g., WTRU 102e) can utilize cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, NR, etc.) to establish picocells or femtocells. Figure 8A As shown, base station 114c can directly connect to the Internet 110. Therefore, base station 114c does not need to access the Internet 110 through the core network 106 / 107 / 109.

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

[0104] although Figure 8A Although not shown, it is understood that 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 that 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 use E-UTRA radio technology, core network 106 / 107 / 109 can also communicate with another RAN (not shown) that uses GSM or NR radio technology.

[0105] Core networks 106 / 107 / 109 can also act as gateways for WTRU 102 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) / Internet Protocol (IP) (TCP, User Datagram Protocol (UDP), and IP from the Internet Protocol suite). Other networks 112 may include wired or wireless communication networks owned and / or operated by other service providers. For example, network 112 may include any type of packet data network (e.g., an IEEE 802.3 Ethernet network) or another core network connected to one or more RANs using the same or different RATs as RAN103 / 104 / 105 and / or RAN 103b / 104b / 105b.

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

[0107] although Figure 8A Not shown, but understood, user equipment can make wired connections to the gateway. The gateway can be a residential gateway (RG). The RG can provide connectivity to the core network 106 / 107 / 109. It is understood that many of the ideas contained herein also apply to UEs acting as WTRUs and UEs connected to the network via wired connections. For example, ideas applicable to radio interfaces 115, 116, 117, and 115c / 116c / 117c also apply to wired connections.

[0108] Figure 8B This is a system diagram of example RAN 103 and core network 106. As described above, RAN 103 can communicate with WTRUs 102a, 102b, and 102c via air interface 115 using UTRA radio technology. RAN 103 can also communicate with core network 106. Figure 8BAs shown, RAN 103 may include Node-Bs 140a, 140b, and 140c, each Node-B may include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 115. Node-Bs 140a, 140b, and 140c may be associated with specific cells (not shown) within RAN 103. RAN 103 may also include RNCs 142a and 142b. It is understood that RAN 103 may include any number of Node-Bs and Radio Network Controllers (RNCs).

[0109] like Figure 8B As 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 RNC 142a and 142b can be configured to control its connected Node-B 140a, 140b, and 140c. Furthermore, each RNC 142a and 142b can be configured to perform or support other functions, such as outer-loop power control, load control, admission control, packet scheduling, handover control, macro diversity, security functions, and data encryption.

[0110] Figure 8B 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. Although each of the foregoing elements is depicted as part of the core network 106, it is understood that any one of these elements may be owned and / or operated by an entity other than the core network operator.

[0111] RNC 142a in RAN 103 can connect to MSC 146 in core network 106 via the IuCS interface. MSC 146 can connect 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 wired communication equipment.

[0112] RNC 142a in RAN 103 can also connect to SGSN 148 in core network 106 via the IuPS interface. SGSN 148 can connect 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) to facilitate communication between WTRU 102a, 102b, and 102c and IP-enabled devices.

[0113] The core network 106 can also be connected to other networks 112, which may include other wired or wireless networks owned and / or operated by other service providers.

[0114] Figure 8C This is a system diagram of an exemplary RAN 104 and core network 107. As described above, RAN 104 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using E-UTRA radio technology. RAN 104 can also communicate with core network 107.

[0115] RAN 104 may include eNode-B 160a, 160b, and 160c, but it is understood that RAN 104 may include any number of eNode-Bs. eNode-B 160a, 160b, and 160c may each include one or more transceivers for communicating with WTRU 102a, 102b, and 102c via air interface 116. For example, eNode-B 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.

[0116] Each 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. For example... Figure 8C As shown, eNode-B 160a, 160b and 160c can communicate with each other via the X2 interface.

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

[0118] The MME 162 can connect to each eNode-B 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 user authentication, bearer activation / deactivation, and selection of specific serving gateways for WTRUs 102a, 102b, and 102c 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.

[0119] Service Gateway 164 can connect to each eNode-B 160a, 160b, and 160c in RAN 104 via the S1 interface. Service Gateway 164 typically routes and forwards user data packets to / from WTRUs 102a, 102b, and 102c. Service 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 for WTRUs 102a, 102b, and 102c, and managing and storing the context of WTRUs 102a, 102b, and 102c.

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

[0121] 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 legacy wired communication equipment. For example, core network 107 may include or 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.

[0122] Figure 8DThis is a system diagram of example RAN 105 and core network 109. RAN 105 can communicate with WTRU 102a and 102b via air interface 117 using NR radio technology. RAN 105 can also communicate with core network 109. Non-3GPP Interoperability Function (N3IWF) 199 can communicate with WTRU 102c via air interface 198 using non-3GPP radio technology. N3IWF 199 can also communicate with core network 109.

[0123] RAN 105 may include gNode-B 180a and 180b. It is understood that RAN 105 may include any number of gNode-Bs. gNode-B 180a and 180b may each include one or more transceivers for communicating with WTRU 102a and 102b via air interface 117. When using integrated access and backhaul connections, the same air interface can be used between the WTRU and the gNode-B, which can be connected to the core network 109 via one or more gNBs. gNode-B 180a and 180b may implement MIMO, MU-MIMO, and / or digital beamforming technologies. Therefore, for example, gNode-B 180a may use multiple antennas to transmit radio signals to and receive radio signals from WTRU 102a. It should be understood that RAN 105 may employ other types of base stations, such as eNode-B. It is also understood that RAN 105 may employ multiple types of base stations. For example, RAN may employ eNode-B and gNode-B.

[0124] N3IWF 199 may include a non-3GPP access point 180c. It is understood that N3IWF 199 may include any number of non-3GPP access points. The non-3GPP access point 180c may include one or more transceivers for communicating with WTRU102c via air interface 198. The non-3GPP access point 180c may communicate with WTRU102c via air interface 198 using the 802.11 protocol.

[0125] Each gNode-B 180a and 180b 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. For example... Figure 8D As shown, gNode-B 180a and 180b can communicate with each other via the Xn interface.

[0126] Figure 8DThe core network 109 shown may be a 5G core network (5GC). Core network 109 can provide numerous communication services to customers interconnected via a radio access network. Core network 109 includes multiple entities that perform core network functions. As used herein, the terms "core network entity" or "network function" refer to any entity that performs one or more functions of the core network. It is understood that such core network entities may be logical entities implemented in the form of computer-executable instructions (software) stored in a device or computer system configured for wireless and / or network communications (e.g., [example device]). Figure 8G The system 90 shown is stored in its memory and executed on its processor.

[0127] exist Figure 8D In the example, the 5G core network 109 may include Access and Mobility Management Functions (AMF) 172, Session Management Functions (SMF) 174, User Plane Functions (UPF) 176a and 176b, User Data Management Functions (UDM) 197, Authentication Server Functions (AUSF) 190, Network Opening Functions (NEF) 196, Policy Control Functions (PCF) 184, Non-3GPP Interoperability Functions (N3IWF) 199, and User Data Repository (UDR) 178. While each of the foregoing elements is depicted as part of the 5G core network 109, it is understood that any one of these elements may be owned and / or operated by an entity other than the core network operator. It is also understood that the 5G core network may not contain all of these elements, may contain additional elements, and may contain multiple instances of each of these elements. Figure 8D While network functions are directly interconnected, it should be understood that they can communicate via routing agents (such as diameter routing agents) or message buses.

[0128] exist Figure 8D In the example, connectivity between network functions is achieved through a set of interfaces or reference points. It can be understood that a network function can be modeled, described, or implemented as a set of services invoked or called by other network functions or services. Invocation of network function services can be achieved through direct connections between network functions, exchanging messages on a message bus, or invoking software functions.

[0129] The AMF 172 can connect to RAN 105 via the N2 interface and can function as a control node. For example, the AMF 172 can handle registration management, connection management, reachability management, access authentication, and access authorization. The AMF can forward user plane tunnel configuration information to RAN 105 via the N2 interface. The AMF 172 can receive user plane tunnel configuration information from the SMF via the N11 interface. The AMF 172 typically routes and forwards NAS packets to / from WTRUs 102a, 102b, and 102c via the N1 interface. Figure 8D The N1 interface is not shown.

[0130] The SMF 174 can connect to the AMF 172 via the N11 interface. Similarly, the SMF can connect to the PCF184 via the N7 interface and to the UPF 176a and 176b via the N4 interface. The SMF 174 can act as a control node. For example, the SMF 174 can be responsible for session management, assigning IP addresses to WTRU 102a, 102b, and 102c, managing and configuring traffic redirection rules in UPF 176a and UPF 176b, and generating downlink data notifications to the AMF 172.

[0131] UPF 176a and UPF 176b can provide WTRU 102a, 102b, and 102c with access to packet data networks (PDNs) (such as the Internet 110) to facilitate communication between WTRU 102a, 102b, and 102c and other devices. UPF 176a and UPF 176b can also provide WTRU 102a, 102b, and 102c with access to other types of packet data networks. For example, other networks 112 can be Ethernet networks or any type of network that switches data packets. UPF 176a and UPF 176b can receive traffic redirection rules from SMF 174 via the N4 interface. UPF 176a and UPF 176b can connect to packet data networks via the N6 interface, or connect to each other and other UPFs via the N9 interface, providing access to packet data networks. In addition to providing access to packet data networks, UPF 176 can be responsible for packet routing and forwarding, policy rule enforcement, quality of service processing for user plane traffic flows, and downlink packet buffering.

[0132] The AMF 172 can also connect to the N3IWF 199, for example, via the N2 interface. The N3IWF facilitates connectivity between the WTRU 102c and the 5G core network 170, for example, via radio interface technologies not defined by 3GPP. The AMF can interact with the N3IWF 199 in the same or similar manner as the RAN 105.

[0133] PCF 184 can be connected to SMF 174 via N7 interface, to AMF 172 via N15 interface, and to Application Function (AF) 188 via N5 interface. Figure 8DThe N15 and N5 interfaces are not shown. The PCF 184 can provide policy rules to control plane nodes (such as AMF 172 and SMF 174), allowing these rules to be executed. The PCF 184 can send policies for WTRUs 102a, 102b, and 102c to the AMF 172, so that the AMF can transmit these policies to WTRUs 102a, 102b, and 102c via the N1 interface. The policies can then be executed or applied at WTRUs 102a, 102b, and 102c.

[0134] UDR 178 can act as a repository for authentication credentials and subscription information. The UDR can connect to network functions so that these functions can add, read, and modify data in the repository. For example, UDR 178 can connect to PCF 184 via the N36 interface. Similarly, UDR 178 can connect to NEF 196 via the N37 interface, and UDR 178 can connect to UDM 197 via the N35 interface.

[0135] The UDM 197 can act as an interface between the UDR 178 and other network functions. The UDM 197 can authorize network functions to access the UDR 178. For example, the UDM 197 can connect to the AMF 172 via interface N8, and to the SMF 174 via interface N10. Similarly, the UDM 197 can connect to the AUSF 190 via interface N13. The UDR 178 and UDM 197 can be tightly integrated.

[0136] The AUSF 190 performs authentication-related operations and connects to the UDM 178 via the N13 interface and to the AMF 172 via the N12 interface.

[0137] The NEF 196 exposes the capabilities and services of the 5G core network 109 to the Application Function (AF) 188. This exposure can be achieved through the N33 API interface. The NEF can connect to the AF 188 via the N33 interface, and it can connect to other network functions to expose the capabilities and services of the 5G core network 109.

[0138] Application function 188 can interact with network functions in the 5G core network 109. Interaction between application function 188 and network functions can be performed via a direct interface or via NEF 196. Application function 188 can be considered part of the 5G core network 109, or it can reside outside the 5G core network 109 and be deployed by an enterprise with business relationships with mobile network operators.

[0139] Network slicing is a mechanism that mobile network operators can use to support one or more "virtual" core networks behind the operator's air interface. This involves "slicing" the core network into one or more virtual networks to support different RANs or different service types operating across a single RAN. Network slicing enables operators to create customized networks that provide optimized solutions for different market scenarios that require diverse requirements, such as in terms of functionality, performance, and isolation.

[0140] 3GPP designed the 5G core network to support network slicing. Network slicing is a powerful tool for network operators to support a diverse set of 5G use cases, such as massive IoT, critical communications, V2X, and enhanced mobile broadband, which have highly varied and sometimes extreme requirements. Without network slicing, the network architecture may not be flexible and scalable enough to effectively support a wider range of use case requirements when each use case has its own specific performance, scalability, and availability requirements. Furthermore, the introduction of new network services should be more efficient.

[0141] Refer again Figure 8D In a network slicing scenario, WTRU 102a, 102b, or 102c can connect to AMF 172 via the N1 interface. AMF can logically be part of one or more slices. AMF can coordinate connections or communication between WTRU 102a, 102b, or 102c and one or more UPF 176a and 176b, SMF 174, and other network functions. UPF 176a and 176b, SMF 174, and other network functions can each be part of the same slice or different slices. When they belong to different slices, they can be isolated from each other because they can use different computing resources, security credentials, etc.

[0142] Core network 109 can facilitate communication with other networks. For example, core network 109 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between 5G core network 109 and PSTN 108. For example, core network 109 may include or communicate with a Short Message Service (SMS) service center that facilitates communication via SMS service. For example, 5G core network 109 can facilitate the exchange of non-IP data packets between WTRUs 102a, 102b, and 102c and server or application function 188. Furthermore, core network 170 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.

[0143] This article describes and Figure 8A , 8CThe core network entities described in 3GPP 8D and 8E are identified by names given to these entities in certain existing 3GPP specifications. However, it is understood that these entities and functions may be identified by other names in the future, and some entities or functions may be incorporated into future 3GPP specifications (including future 3GPP NR specifications). Therefore, Figure 8A , 8B The specific network entities and functions described and illustrated in 8C, 8D and 8E are merely exemplary, and it is understood that the subject matter disclosed and claimed herein may be embodied or implemented in any similar communication system, whether currently defined or in the future.

[0144] Figure 8E An exemplary communication system 111 is illustrated, in which the systems, methods, and apparatuses described herein can be used. Communication system 111 may include wireless transmit / receive units (WTRUs) A, B, C, D, E, and F, a base station gNB 121, a V2X server 124, and roadside units (RSUs) 123a and 123b. In practice, the concepts presented herein can be applied to any number of WTRUs, base station gNBs, V2X networks, and / or other network elements. One or more or all WTRUs A, B, C, D, E, and F may be outside the access network coverage area 131. WTRUs A, B, and C form a V2X group, where WTRU A is the group leader, and WTRUs B and C are group members.

[0145] If WTRUs A, B, C, D, E, and F are within the access network coverage area 131, they can communicate with each other via gNB 121 through Uu interface 129. Figure 8E In the example, WTRUs B and F are shown within access network coverage 131. Regardless of whether they are within or outside access network coverage 131, WTRUs A, B, C, D, E, and F can communicate directly with each other via side link interfaces (e.g., PC5 or NR PC5) such as interfaces 125a, 125b, or 128. For example, in Figure 8E In the example, WRTU D, which is outside the coverage area 131, communicates with WTRU F, which is inside the coverage area 131.

[0146] WTRUs A, B, C, D, E, and F can communicate with RSUs 123a or 123b via Vehicle-to-Network (V2N) 133 or sidelink interface 125b. WTRUs A, B, C, D, E, and F can communicate with V2X server 124 via Vehicle-to-Infrastructure (V2I) interface 127. WTRUs A, B, C, D, E, and F can communicate with another UE via Vehicle-to-Person (V2P) interface 128.

[0147] Figure 8FThis is a block diagram of an exemplary device or apparatus WTRU 102, which can be configured for wireless communication and operation according to the systems, methods, and apparatus described herein, for example... Figure 8A , 8B WTRU 102 in 8C, 8D, or 8E. For example... Figure 8F As shown, the exemplary WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keyboard 126, 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 is understood that the WTRU 102 may include any sub-combination of the aforementioned elements. Furthermore, base stations 114a and 114b, and / or the nodes that base stations 114a and 114b may represent (e.g., but not limited to, base transceiver stations (BTS), Node-B, site controllers, access points (APs), home Node-B, evolved home Node-B (eNodeB), evolved home Node-B (HeNB), evolved home Node-B gateway, next-generation Node-B (gNode-B), and proxy nodes, etc.) may include... Figure 8F Some or all of the elements depicted in the text and described herein.

[0148] Processor 118 can 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 can perform signal encoding, data processing, power control, input / output processing, and / or any other functions that enable WTRU 102 to operate in a wireless environment. Processor 118 can be coupled to transceiver 120, and transceiver 120 can be coupled to transmitting / receiving element 122. Although Figure 8F While the processor 118 and transceiver 120 are depicted as separate components, it is understood that the processor 118 and transceiver 120 may be integrated into an electronic package or chip.

[0149] The UE's transmit / receive element 122 can be configured to transmit data to a base station (e.g., via air interface 115 / 116 / 117). Figure 8AThe base station 114a) transmits signals, or receives signals from the base station, or transmits signals to or receives signals from another UE via air interface 115d / 116d / 117d. For example, the transmitting / receiving element 122 may be an antenna configured to transmit and / or receive RF signals. The transmitting / receiving element 122 may be a transmitter / detector configured to transmit and / or receive IR, UV, or visible light signals. The transmitting / receiving element 122 may be configured to transmit and receive both RF and optical signals. It is understood that the transmitting / receiving element 122 may be configured to transmit and / or receive any combination of wireless or wired signals.

[0150] In addition, although Figure 8F While the transmitting / receiving element 122 is depicted as a single element, the WTRU 102 may include any number of transmitting / receiving elements 122. More specifically, the WTRU 102 may employ MIMO technology. Therefore, the WTRU 102 may include two or more transmitting / receiving elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals via air interfaces 115 / 116 / 117.

[0151] Transceiver 120 can be configured to modulate signals transmitted by transmitting / receiving element 122 and demodulate signals received by transmitting / receiving element 122. As described above, WTRU 102 can have multi-mode capability. Therefore, transceiver 120 can include multiple transceivers to enable WTRU 102 to communicate via multiple RATs (e.g., NR and IEEE 802.11 or NR and E-UTRA), or to communicate with different RRHs, TRPs, RSUs, or nodes using the same RAT via different beams.

[0152] The processor 118 of WTRU 102 can be coupled to and receive user input data from speakers / microphones 124, keyboards 126, and / or displays / touchpads / indicators 128 (e.g., liquid crystal display (LCD) units or organic light-emitting diode (OLED) display units). The processor 118 can also output user data to speakers / microphones 124, keyboards 126, and / or displays / touchpads / indicators 128. Furthermore, the processor 118 can access and store information in any type of suitable memory (e.g., non-removable memory 130 and / or removable memory 132). Non-removable memory 130 can include random access memory (RAM), read-only memory (ROM), hard disks, or any other type of memory storage device. Removable memory 132 can include a Subscriber Identity Module (SIM) card, memory stick, secure digital storage (SD) card, etc. The processor 118 can also access and store information in memory that is not physically located on WTRU 102 (e.g., a server hosted in the cloud or on an edge computing platform or a home computer (not shown).

[0153] The processor 118 can receive power from the power supply 134 and can be configured to distribute power to and / or control 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 batteries, solar cells, fuel cells, etc.

[0154] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) about the current location of the WTRU 102. As an addition to or alternative 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 is understood that the WTRU 102 may acquire location information using any suitable location determination method.

[0155] The processor 118 can also be coupled to other peripheral devices 138, which may include one or more software and / or hardware modules that provide one or more additional features, functions, and / or wired or wireless connectivity. For example, peripheral devices 138 may include various sensors (e.g., accelerometers, biometric sensors (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.

[0156] WTRU 102 may be included in other devices or equipment, such as sensors, consumer electronics, wearable devices (such as smartwatches or smart clothing), medical or e-health devices, robots, industrial equipment, drones, or vehicles (such as cars, trucks, trains, or airplanes). WTRU 102 may be connected to other components, modules, or systems of such devices or equipment via one or more interconnect interfaces (such as the interconnect interface that may include one of the peripheral devices 138).

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

[0158] During operation, processor 91 fetches, decodes, and executes instructions, and transfers information between resources via system bus 80, the main data transfer path of the computing system. This type of 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 operating system buses. An example of such a system bus 80 is the PCI (Peripheral Component Interconnect) bus.

[0159] The memory coupled to the system bus 80 includes random access memory (RAM) 82 and read-only memory (ROM) 93. This type of memory includes circuitry that allows information to be stored and retrieved. ROM 93 typically contains stored data that is not easily modified. Data stored in RAM 82 can be read or modified 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 provides address translation functionality, which translates virtual addresses into physical addresses during instruction execution. The memory controller 92 also provides memory protection functionality, isolating processes within the system and separating system processes from user processes. Therefore, a program running in first mode can only access memory mapped by its own process's virtual address space; it cannot access memory within another process's virtual address space unless inter-process memory sharing is configured.

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

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

[0162] Furthermore, the computing system 90 may include communication circuitry, such as a wireless or wired network adapter 97, which can be used to connect the computing system 90 to an external communication network or device, for example... Figure 8A , 8BThe computing system 90 can communicate with other nodes or functional entities in those networks, including RAN 103 / 104 / 105, core network 106 / 107 / 109, PSTN 108, Internet 110, WTRU 102, and other networks 112, of the 8C, 8D, and 8E. The communication circuitry, alone or in combination with the processor 91, can be used to perform the transmit and receive steps of certain means, nodes, or functional entities described herein.

[0163] It is understood that any or all of the apparatuses, systems, methods, and processes described herein may be embodied in the form of computer-executable instructions (e.g., program code) stored on a computer-readable storage medium, which, when executed by a processor (e.g., 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, executed 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 using any non-transitory (e.g., tangible or physical) method or technology for information storage, but such computer-readable storage media do not include signals. Computer-readable storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical disc storage, cassette tape, magnetic tape, disk storage or other magnetic storage devices, or any other tangible or physical media that can be used to store desired information and can be accessed by a computing system.

Claims

1. An apparatus associated with a Federated Learning (FL) service, the apparatus comprising one or more processors and a memory storing instructions that, when executed by the one or more processors, cause the apparatus to: Receive a request from an FL user to create or update an FL job, wherein the request contains FL job information indicating one or more machine learning (ML) requirements and one or more FL training requirements; Based on the FL job information, perform at least one of the following: determine whether the FL user is authorized to execute the FL job, select one or more FL clients that meet one or more FL training requirements, and determine one or more FL tasks associated with the FL job to be executed by the one or more FL clients; Send a response containing the FL job ID and FL request status information to the FL user; Send one or more FL task requests containing FL task information to the one or more FL clients; Receive FL task status information from the one or more FL clients; Based on the received FL task status information, determine whether to execute one or more FL training rounds; as well as Send FL job status information to the FL user.

2. The apparatus of claim 1, wherein determining whether to perform one or more FL training rounds is based on aggregating received FL task status information and comparing it with the ML requirements specified by the FL user in the FL job.

3. The apparatus of claim 1, wherein the one or more FL training requirements include at least one of the following: a specified operating environment, an FL framework, an algorithm name and version, one or more runtime requirements, one or more processor and memory requirements, a minimum number of sample data, and a maximum age of the data.

4. The apparatus of claim 1, wherein the FL job information further indicates FL client configuration, which indicates at least one of the following: a list of FL client IDs, one or more FL client training requirements, and FL client data filters.

5. The apparatus of claim 1, wherein the FL job status information indicates at least one of the following: indicating whether the FL job has not started, has started, has been paused, has been resumed, has been stopped, has been canceled, or has been completed; and the current FL round number.

6. The apparatus of claim 1, wherein the one or more ML requirements indicate at least one of the following: one or more ML algorithms, ML problem types, multi-model training modes, one or more hyperparameters, model evaluation functions, model initialization, aggregation algorithms, a minimum number of FL training epochs, a minimum number of FL clients, and a minimum number of total data instances.

7. The apparatus of claim 1, wherein the instructions, when executed by the one or more processors, further cause the apparatus to: Determine whether or when to start the FL job.

8. The apparatus of claim 1, wherein the instructions, when executed by the one or more processors, further cause the apparatus to: Send FL task subscription or retrieval requests to one or more FL clients to obtain FL task results and FL task status information.

9. The apparatus of claim 1, wherein the instructions, when executed by the one or more processors, further cause the apparatus to: Receive FL job subscription or retrieval requests from one or more FL users to obtain FL job results and status information of interest to the FL users.

10. The apparatus of claim 1, wherein the instructions, when executed by the one or more processors, further cause the apparatus to: Send a notification to the FL user indicating FL-related events.

11. An apparatus associated with a federated learning (FL) client, the apparatus comprising one or more processors and a memory storing instructions that, when executed by the one or more processors, cause the apparatus to: Receive one or more FL task requests from the FL service, which contain FL task information indicating one or more machine learning (ML) requirements and one or more FL training requirements; Execute one or more FL tasks based on the one or more FL task requests; Send one or more notifications containing FL task status information to the FL service.

12. The apparatus of claim 11, wherein the one or more FL training requirements include at least one of the following: a specified operating environment, an FL framework, an algorithm name and version, one or more runtime requirements, one or more processor and memory requirements, a minimum number of sample data, and a maximum age of the data.

13. The apparatus of claim 11, wherein the FL job information further indicates FL client configuration, which indicates at least one of the following: a list of FL client IDs, one or more FL client training requirements, and FL client data filters.

14. The apparatus of claim 11, wherein the FL job status information indicates at least one of the following: indicating whether the FL job has not started, has started, has been paused, has been resumed, has been stopped, has been canceled, or has been completed; and the current FL round number.

15. A method comprising: Receive requests from Federated Learning (FL) users to create or update FL jobs, wherein the requests contain FL job information indicating one or more machine learning (ML) requirements and one or more FL training requirements; Based on the FL job information, perform at least one of the following: determine whether the FL user is authorized to execute the FL job, select one or more FL clients that meet one or more FL training requirements, and determine one or more FL tasks associated with the FL job to be executed by the one or more FL clients; Send a response containing the FL job ID and FL request status information to the FL user; Send one or more FL task requests containing FL task information to the one or more FL clients; Receive FL task status information from the one or more FL clients; Based on the received FL task status information, determine whether to execute one or more FL training rounds; as well as Send FL job status information to the FL user.

16. The method of claim 15, wherein determining whether to perform one or more FL training rounds is based on aggregating received FL task status information and comparing it with the ML requirements specified by the FL user in the FL job.

17. The method of claim 15, wherein the one or more FL training requirements include at least one of the following: a specified operating environment, an FL framework, an algorithm name and version, one or more runtime requirements, one or more processor and memory requirements, a minimum number of sample data, and a maximum age of the data.

18. The method of claim 15, wherein the FL job information further indicates FL client configuration, which indicates at least one of the following: a list of FL client IDs, one or more FL client training requirements, and FL client data filters.

19. The method of claim 15, wherein the FL job status information indicates at least one of the following: indicating whether the FL job has not started, has started, has been paused, has been resumed, has been stopped, has been canceled, or has been completed; and the current FL round number.

20. The method of claim 15, wherein the one or more ML requirements indicate at least one of the following: one or more ML algorithms, ML problem types, multi-model training modes, one or more hyperparameters, model evaluation functions, model initialization, aggregation algorithms, a minimum number of training epochs, a minimum number of FL clients, and a minimum number of total data instances.

Images