Method and apparatus for enabling federated learning job management services

Abstract

Federated Learning (FL) can be deployed as a service through the definition of FL job management functionality. An FL service may have the ability to receive FL job specifications from an FL user, process and manage FL jobs on behalf of the FL user through interaction with FL clients, and update the FL user based on the status of the FL job as being processed.

Description

Background Art

[0001] Cross-reference of related applications This application claims the priority of U.S. Patent Provisional Application No. 63 / 507,131, filed on June 9, 2023, which is hereby incorporated by reference in its entirety.

[0002] Background technology 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 an important aspect of federated learning, and thus, data is stored locally at individual clients. As a result, the confidentiality of the data is maintained at individual clients, while the desired machine learning applications can still be achieved by training the model by the federated learning clients. FL training is performed in multiple rounds, in which the ML model, model parameters, and related training parameters are transmitted from the FL server to the FL clients at the start of each round, and after the training of that round is completed, the FL clients provide model updates (including updated model parameters) to the FL server. The FL server aggregates the model parameters, updates the global model, and the training repeats for the next round using those model updates.

Summary of the Invention

[0003] Disclosed herein are methods and apparatuses for enabling federated learning (FL) to be deployed as a service by definition of an FL job management function. Methods and apparatuses are disclosed for enabling an FL service with such capabilities to receive FL job specifications from FL users, process and manage these FL jobs on behalf of the FL users through interaction with FL clients, and update the FL users according to the status of the FL jobs while they are being processed.

[0004] This summary is provided to introduce, in a simplified form, selected concepts from those further described below in “Modes for Carrying Out the Invention.” This summary is not intended to identify any material or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to features that resolve some or all of the defects described in any part of this disclosure.

[0005] A more detailed understanding can be obtained from the following explanation, which is given as an example along with the attached drawings. [Brief explanation of the drawing]

[0006] [Figure 1] This figure shows an example of an FL training round. [Figure 2] This is a diagram illustrating an example of the FL job service. [Figure 3] This diagram illustrates an exemplary FL job specification procedure. [Figure 4] A schematic diagram illustrating an exemplary FL job management procedure. [Figure 5] This diagram illustrates an example of the FL job status procedure. [Figure 6] This figure shows an exemplary FL job-end-to-end embodiment. [Figure 7] This figure shows an exemplary FL job graphic user interface (GUI) embodiment. [Figure 8A] This is a diagram illustrating an exemplary communication system. [Figure 8B] This is an exemplary system diagram of the RAN and core network. [Figure 8C] This is an exemplary system diagram of the RAN and core network. [Figure 8D] This is an exemplary system diagram of the RAN and core network. [Figure 8E] This diagram illustrates another exemplary communication system. [Figure 8F]This is a block diagram of an exemplary device or apparatus, such as a WTRU. [Figure 8G] This is a block diagram of an exemplary computing system. [Modes for carrying out the invention]

[0007] The following abbreviations have the following meanings throughout the entire text. 3GPP Third Generation Partnership Project 5GS 5G system API Application Programming Interface CSP Cloud Service Provider FL Associative Learning ML (Machine Learning) The following terms may have the following meanings:

[0008] The term “Federation Learning User (FL User)” may refer to a user device (e.g., a computer, smartphone, or tablet) that hosts computing resources, memory resources, and network connectivity resources capable of hosting user application software (e.g., a web browser or application) that the user uses to perform FL-centric operations using FL services. One such type of operation as defined in the context of this disclosure involves an FL user configuring FL services with FL jobs to be performed on behalf of the FL user.

[0009] The term "Federal Learning Client (FL Client)" may refer to FL client software (e.g., an FL client application) used by the FL client to perform actions such as training ML models in a federated manner, as well as network equipment (e.g., a device, gateway, or server) that hosts computing resources, memory resources, and network connectivity resources capable of hosting local data.

[0010] The term "Federal Learning Service (FL Service)" may refer to a network device (e.g., a device, gateway, or server) that hosts computing, memory, and network connectivity resources capable of hosting FL service software that performs FL management operations, such as receiving FL jobs that an FL server uses to train ML models federated across FL clients.

[0011] The term "federated learning job (FL job)" sometimes refers to a set of FL user-defined instructions and requirements for training an ML model in a federated manner. FL users configure FL services with FL jobs so that the FL service can offload and train ML models in a federated manner on behalf of the FL user.

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

[0013] The term "federated learning task (FL task)" can refer to a set of instructions and requirements sent by an FL service to multiple FL clients to train an ML model in a federated manner. An FL task contains client-specific configurations required to train the ML model to meet the conditions specified by an FL job. An FL task may be generated by the FL service for each round of federated training performed on the ML model. An FL task may be specified by an FL user or an FL service.

[0014] 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 an important aspect of federated learning, and thus, data is stored locally at individual clients. As a result, the confidentiality of the data is maintained at the individual clients, while desirable machine learning applications can still be achieved through the training of the model by federated learning clients. FL training is carried out in multiple rounds, where in each round, the ML model, model parameters, and related training parameters are transmitted from the FL server to the FL clients at the start of the round, and after the training in that round is completed, the FL clients provide the model updates (including the updated model parameters) to the FL server. The FL server aggregates the model parameters, updates the global model, and the training repeats for the next round using those model updates.

[0015] Figure 1 shows an example 10 of a federated learning training round between an FL server and multiple FL clients. In each training round, the FL server provides the ML model to each FL client along with the relevant model parameters and training parameters. The FL clients train the ML model using local data and send the updated model parameters to the FL server for aggregation. The training repeats until the performance goal is achieved.

[0016] 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 the training parameters to one or more FL clients and start training one or more FL clients. In step 3, one or more FL clients can send the updated model weights to the FL server.

[0017] In federative learning, FL users and FL clients are isolated from each other and may not even communicate directly. FL users are domain experts of ML applications, possessing deep knowledge of the requirements of ML algorithms, but lacking access to the data used to train those algorithms. Conversely, FL clients possess the data used to train ML algorithms, but cannot control the training of those algorithms during the federative learning process. Due to this isolation between FL users and FL clients, FL clients may not be aware of the existence of other FL clients and may not receive requests from FL users.

[0018] This specification discloses methods and apparatus for enabling federated learning (FL) to be deployed as a service by defining an FL job management function. Disclosed are methods and apparatus for enabling an FL service having this capability to receive FL job specifications from FL users, process and manage these FL jobs on behalf of the FL users through interaction with FL clients, and update FL users by the status of the FL jobs as they are being processed.

[0019] Specifically, the following FL services will be disclosed: • Receiving FL job creation or update requests from FL users along with FL job information that includes one or more of the following types of information elements: FL job start and stop conditions Prioritizing FL jobs Types of ML models that should be trained using the federated method 〇Types of problems, such as object classification, that the FL service can determine one or more candidate machine learning algorithms for creating an "experiment" 〇Types of data that FL clients should use in FL training rounds ○ Displaying multi-model training mode Hyperparameter settings ○ Functions or scripts for evaluating model performance FL training environment requirements, such as the minimum number of data instances for FL clients in the training round. 〇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 data validity period) Based on the received FL job information, perform one or more of the following actions: ○ Determine whether the FL user has FL job privileges and is permitted to execute FL jobs. ○ The FL service stores FL job information so that it can access and use the information while the FL job is being executed. Select an FL client that meets the FL training requirements for the FL job. To train an ML model in a federated manner, determine one or more FL tasks to delegate to an FL client. Decide whether to start the FL job and when to start it. • Send back FL job creation / update responses to FL users who have information such as FL job ID and FL job status. • Send an FL task request to an FL client that has FL task information containing one or more of the following types of information: 〇The ID of the FL task and / or the ID of the FL job to which that task is associated Prioritizing FL tasks Number of FL rounds associated with FL tasks Conditions for starting or stopping FL tasks FL Task Function Required FL client configuration settings that the FL client should use to meet training requirements. 〇ML algorithm, corresponding version, and initial model parameters Hyperparameters of the ML training process 〇Data Filter - Send an FL task subscription or retrieval request to the FL client to obtain the results and status information of the FL task. • Receive FL task results and status information from an FL client that has the following information: ○ Changes in FL task status (e.g., started, paused, resumed, canceled, completed) Training / performance thresholds for ML models that have reached a specific level Changes in FL client status (e.g., availability, error conditions, completed FL tasks) Updated model parameters ○ Model training results (e.g., model accuracy and performance results) Based on the information received from the FL client, determine whether to conduct additional FL training rounds by aggregating the information and comparing it to the ML requirements specified by the FL user within the FL job. • Receive FL job subscriptions or retrieval requests from FL users and retrieve FL job results and status information of interest to the FL users. • Send FL job results and status information to FL users who have one or more of the following types of information: 〇 Changes in FL job status (e.g., started, paused, resumed, canceled, completed) ○ Indicates that the training / performance threshold of the ML model has reached a specific level. Changes in FL client status (e.g., availability, error conditions, completed FL tasks) As described herein, the FL service can assist FL users in training machine learning models in a federated manner using FL clients on a network hosting local data that must remain local (for example, for privacy or ownership reasons). The FL service can provide interfaces and corresponding services to both FL users and FL clients. Through the FL user interface, FL users can configure the FL service with FL jobs. FL jobs may contain user-defined instructions and requirements that the FL service can use to manage the training of ML models in a service-based federated manner on behalf of the FL user. 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 while they are being handled by the FL service. To execute an FL job, the FL service can interface with FL clients and instruct these FL clients to perform federated training operations. When interface with FL clients, the FL service can configure FL clients with FL tasks. FL tasks can be configured from a set of configurations and / or instructions that FL clients use to train ML models in a federated manner. Joint training may involve multiple training rounds, in which case the FL client performs ML model training operations, shares the training results with the FL service, receives the updated ML model from the FL service, and then performs additional training rounds. Training rounds may continue until the FL service determines that the ML model has reached the required training level (e.g., a specific model accuracy defined by the FL user within the FL job). FL tasks shared by the FL server with FL clients can be specified at the level of granularity of individual FL training rounds or at the level of granularity of multiple training rounds.

[0020] Figure 2 presents a high-level example 200 illustrating the various procedures involved in configuring an FL service with an FL job, namely, the job specification procedure, the job management procedure, and the job status procedure. Using the information defined within the FL job, the FL service can coordinate FL training rounds with FL clients to train ML models in a federated manner that meets the requirements of the FL user. The FL service can provide the FL user with FL job status information over the duration of the FL job. As a result, 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 to the FL job.

[0021] Specifying an FL job involves an FL user providing the FL service with the requirements for their ML application. As part of the requirements, the FL user may specify the need to utilize federated learning to train a particular algorithm using data that may be available in the FL client. The FL service can use the requirements provided by the FL user to manage its behavior when training machine learning models federated across the entire set of FL clients. The information specified by an FL job can include various elements, such as one or more machine learning algorithms or models, the hyperparameters of the associated models, and a stopping criterion that defines when the model is sufficiently trained.

[0022] In the example, a device associated with an FL service may receive a request from an FL user to create or update an FL job. This request may include FL job information that displays one or more machine learning (ML) requirements and one or more FL training requirements. One or more ML requirements may specify 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 rounds, minimum number of FL clients, or minimum number of total data instances. One or more FL training requirements may include at least one of the following: a 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, or maximum data lifespan. The FL job information may further indicate an FL client configuration that shows at least one of the following: a list of FL client IDs, one or more FL client training requirements, or an FL client data filter based on the FL job information. The device may perform at least one of the following: determine whether an FL user is permitted to perform the FL job; select one or more FL clients that satisfy one or more FL training requirements; or determine one or more FL tasks associated with the FL job that should be performed by one or more FL clients. The device may send a response to the FL user containing the FL job ID and FL request status information. The device may send one or more FL task requests containing FL task information to one or more FL clients. The device may receive FL task status information from one or more FL clients. Based on the received FL task status information, the device may decide whether to perform one or more FL training rounds.The decision of whether to conduct one or more FL training rounds can be based on aggregating the received FL task status information and comparing it with the ML requirements specified by the FL user within the FL job. The 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, started, paused, resumed, stopped, canceled, or completed, or the current number of FL rounds.

[0023] In another example, a device associated with a FL (Fielding Unit) may receive one or more FL task requests from the FL service, each containing FL task information, which includes one or more machine learning (ML) requirements and one or more FL training requirements. Based on these requests, the device may perform one or more FL tasks. The device may also send one or more notifications to the FL service containing FL task status information.

[0024] Figure 3 shows an exemplary 300FL job specification procedure, which includes the creation and updating of FL jobs initiated by an FL user for the FL service. An FL job can be created to begin training an ML model in a federated manner, and the FL user can also update the FL job to provide additional FL job information to the FL service.

[0025] In Step 1, an FL user can create and configure an FL job by issuing one or more requests to the FL service. In one or more requests, the FL user can specify FL job information, including but not limited to the information defined in Table 1. Note that the FL user may only be able to provide the configuration information listed in Table 1, and may not be able to provide other information that the FL service can provide to the FL user in return, such as the FL job status, FL job results, and FL client ID list. For example, a request may include the type of model to be trained in a federated manner, along with performance criteria for determining when training should be stopped. A request may also include the type of problem, such as object classification, so that the FL service can determine one or more candidate machine learning algorithms to create an "experiment". A request may also include the type of data that the FL client should use for an FL training round. For example, if the FL client has images of cars, trucks, and motorcycles, the FL user may specify that only motorcycle images are needed for training. A request may also include FL client requirements for training an ML algorithm. Examples of FL client training requirements may include the required operating environment, FL framework, algorithm name and version, runtime requirements, processor and memory requirements, minimum number of sample data, and maximum data lifetime. Other high-level FL configurations, such as the minimum number of training rounds, the minimum number of FL clients (per training round and for the entire FL process), and the minimum total number of data instances, may also be provided by the FL user.

[0026] [Table 1-1]

[0027] [Table 1-2]

[0028] [Table 1-3]

[0029] In Step 2, upon receiving a request, the FL service can verify that the FL client is authorized to access the FL service and then create an FL job. To perform this verification, the FL service can check whether the FL user has the FL job creation privilege defined in the FL service's access control policy. In addition, the FL service can also check one or more individual information elements configured in the FL job request to determine whether the FL user has the necessary privileges. For example, whether the FL user has the privilege to perform FL training operations on a specified FL client, or the privilege to access and use a 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 so that it can be accessed by the FL service. The FL job information may be stored locally in the FL service, or it may be stored in another service that the FL service can interconnect with (e.g., a storage service). In addition, the FL service can also determine whether it needs to perform any FL job-centric operations, such as starting the processing of the FL job. This determination may be made using specified FL job start conditions.

[0030] The FL service can also use FL job information received from FL users to determine and select FL clients that can provide the requested dataset for FL training. The FL job information may require the FL service to select a minimum number of FL clients and to determine whether the aggregated data instances from all FL clients meet the minimum number of data instances for each individual FL client and the entire FL process.

[0031] In step 3, the FL service can send a response back to the FL user. The response may contain one or more informational elements as defined in Table 1. For example, the FL service may assign an FL job ID and include that identifier in the response. The response may also contain additional information, such as a status code indicating whether or not the FL job was created. If the FL service was unable to create the FL job, an error code may accompany the response's status to indicate why the FL service was unable to create the FL job. Examples of error codes may include insufficient FL client discovery, insufficient number of data instances discovered, an unavailable ML algorithm, an unavailable aggregation algorithm, or the data exceeding its maximum lifespan.

[0032] In Step 4, once an FL job is created, the FL user can send subsequent requests to the FL service to update the FL job. An update request may include one or more informational elements, but are not limited to those defined in Table 1. For example, if a user does not define FL job start conditions—when to create an FL job—the FL user can manually trigger the FL service by sending an FL job update request to start the FL job associated with the FL job ID (e.g., by configuring the FL job control informational elements). In another example, during the FL training process, the FL user might decide that parameters of an FL job or FL task require modification (e.g., selecting or deselecting a specific FL client, updating stop criteria, changing the ML algorithm / model, etc.).

[0033] In step 5, upon receiving an FL job update request, the FL service can verify that the FL job ID refers to a valid FL job and that the FL user is authorized to access the FL service and update this FL job. To perform this verification, the FL service can use a similar verification as defined in step 2. If authorization is successful, the FL service can update the FL job by updating the FL job information with one or more information elements specified in the request. In addition, the FL service can also determine if any FL job-centric actions need to be performed, such as starting, pausing, resuming, or stopping the processing of the FL job.

[0034] In step 6, the FL service can send a response back to the FL user. The response may consist of one or more information elements as defined in Table 1. For example, the response may include information elements that were successfully updated, along with their values. The response may also include additional information, such as a status code indicating whether or not the FL job was updated.

[0035] Figure 4 shows an exemplary FL job management procedure 400. Once an FL service is configured with an FL job by an FL user, the FL service can process and manage the FL job on behalf of the FL user. While processing an FL job, the FL service can perform one or more actions, including but not limited to the actions defined in Figure 4. For example, the FL service can decide whether to start, pause, resume, and end an FL job, and when to start, pause, resume, and end it. The FL service can decide on one or more ML algorithms / models for federated training, hyperparameters to use, FL clients to perform FL training, and individual FL tasks in which the FL service configures individual FL clients for training.

[0036] In Step 1, based on the information configured within the specified FL job, the FL service can determine whether and when to start the FL job. For example, the FL service may monitor whether and when a condition is specified in the “FL Job Start Condition” information element defined in Table 1, such as a specified relative, absolute time value, or specified condition expression. The condition expression may consist of one or more conditions that the FL service monitors. The condition may consist of the name and / or reference code of a resource accessible to the FL service, such as the URI of the FL service's resource (e.g., FL client digital twin resource). The condition may also consist of operators (e.g., <, >, =, <=, =>) and comparison values ​​such as thresholds. Alternatively, the FL service may receive an explicit request from an FL user to trigger the FL service to start an FL job. For example, the FL service may receive a request to update the “FL Job Control” information element defined in Table 1, which triggers the FL service to start an FL job.

[0037] In Step 2, the FL service can send a request to the FL client to create an FL task used to coordinate and manage the training of ML algorithms / models in a federated manner. The FL service can create one or more FL tasks for each FL client. Each FL task may contain information such as, but is not limited to, the information elements defined in Table 2. For example, an FL task may contain required FL client configuration settings that the FL client should use to satisfy the training requirements. Some exemplary settings may include the FL client configuration, the ML algorithm and its corresponding version, initial model parameters, and hyperparameters for the ML training process. To determine what information to include in a given FL task for a given FL client, the FL service may rely on information specified by the FL user in the FL job information defined in Table 1, information from other sources such as pre-provisioned FL service policies, or interactions that the FL service performs with other services in the system, as well as / or information about the FL client that the FL service has obtained and / or provisioned. The FL service can configure FL clients with FL tasks at different times during the processing of FL jobs. For example, an FL service can conduct multiple rounds of federated training to train an ML algorithm / model 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 tasks for that round to be performed.

[0038] An alternative form of the FL service that sends requests to FL clients to create FL tasks is for the FL service to instead add the FL tasks to an FL client task queue (not shown in Figure 4) that is stored and maintained by the FL service. 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 respective FL client. The notification may contain FL task information. The FL client can return a response to the FL service to indicate that it has received the FL task information. The response may contain information such as an estimate of the time required to complete the FL training task. The FL client task queue can store multiple FL tasks for an FL client. For example, separate tasks can be queued for different ML algorithms / models that the FL service wants the FL client to train. The FL service can order FL tasks in the queue based on priority (e.g., by leveraging priority information defined by the FL user within an FL job, or by leveraging internal FL service policies). If the FL client has sufficient resources to do so, the client can process multiple FL tasks in parallel.

[0039] [Table 2-1]

[0040] [Table 2-2]

[0041] [Table 2-3]

[0042] [Table 2-4]

[0043] Before an FL service creates an FL task for an 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 certificates, FL client capabilities, including but not limited to those defined in Table 3, may also be provided by the FL client to the FL service when the connection is established. For example, the FL client ID, environment and resources, supported ML algorithms, and dataset information may be provided by the FL client.

[0044] [Table 3]

[0045] In Step 3, upon receiving a request, the FL client can verify that the FL service is authorized to access the FL client and then create an FL task. To perform this verification, the FL client can check whether the FL service has the FL task creation privilege defined within the FL client's access control policy. In addition, the FL client can also 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 privileges. For example, whether the FL service has the privilege to configure the FL client with the specified ML algorithm / model and / or FL task function. If authorization is successful, the FL client can create the FL task by storing the specified FL task information so that it can be accessed by the FL client. The FL task information may be stored locally on the FL client or in another service (e.g., a storage service) to which the FL client is interconnected. In addition, the FL client can also determine whether it needs to perform any FL task-centric actions, such as initiating processing of the FL task. This decision may be made using specified FL task initiation conditions.

[0046] In step 4, the FL client can send a response back to the FL service. The response may contain one or more information elements as defined in Table 2, for example, an FL task ID. The response may also contain additional information, such as a status code indicating whether or not the FL task was created.

[0047] In Step 5, once an FL task is created, the FL service can send subsequent requests to FL clients to update the FL task. These update requests may include one or more informational elements, but are not limited to those defined in Table 2. For example, if the FL service does not define the conditions for when to create an FL task, it can start the FL task by sending an FL task update request to manually trigger the FL client (for example, by configuring FL task control informational elements).

[0048] In step 6, upon receiving an FL update request, the FL client can verify that the FL job ID and / or FL task ID in the request refer to a valid FL job and / or FL task, and that the FL service is authorized to access the FL client and update this FL task. To perform this verification, the FL client can use a similar verification as defined in step 3. If authorization is successful, the FL client can update the FL task by updating the FL task information with one or more information elements specified in the request. In addition, the FL client can also determine if it needs to perform any FL task-centric actions, such as starting, pausing, resuming, or stopping the processing of the FL task.

[0049] In step 7, the FL client can send a response back to the FL service. The response may consist of one or more information elements as defined in Table 2. For example, the response may include information elements that were successfully updated along with their values. The response may also include additional information, such as a status code indicating whether or not the FL task was updated.

[0050] 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 execute other FL tasks it needs to perform. 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 allows the FL client to request access to and / or download functions / scripts from a 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 initial model parameters configured in the FL task information to the ML algorithm / model. The FL client can apply data filters to the training data it uses to train the ML algorithm / model. The FL client can determine when to stop training using FL task stop conditions and / or FL task control information configured in the FL task information. The FL client can also update the FL task state information in the FL task information while processing the FL task.

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

[0052] In step 10, upon receiving an FL task ingestion request, the FL client can respond using the requested FL task information. For example, the FL client can respond using the entire FL task information, or using a subset of the 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.

[0053] In step 11, instead of, or in addition to, retrieving FL task information from the FL client, the FL service can send a subscription request to the FL service to subscribe to an FL task and receive notifications from the FL client when / when the notification criteria associated with the FL task are met. The subscription request may include notification criteria. Notification criteria may consist of one or more conditions. These conditions may refer to information elements defined within the FL task information. For example, notification criteria may include a condition for when the FL task state becomes equivalent to complete.

[0054] In step 12, upon receiving an FL task subscription request, the FL client can create an FL task subscription by storing the subscription information so that it can be accessed by the FL client. The FL task subscription may be stored locally on the FL client or in another service (e.g., a storage service) to which the FL client is interconnected. In addition, the FL client can begin monitoring specified notification criteria to determine whether and when those criteria are met.

[0055] In step 13, the FL client can send a response back to the FL service. The response may include an FL task subscription ID. The response may also include additional information, such as a status code indicating whether the FL task subscription was created successfully or not.

[0056] In step 14, when an FL client detects that the notification conditions defined within the FL task subscription have been met, the FL client can generate an FL task notification to send 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 as defined in Table 2.

[0057] In step 15, the FL service may send a response back 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.

[0058] It should be noted that steps 2 through 15 may be repeated for each FL training round (for the selected FL client) until the FL task termination conditions are met. In subsequent FL training rounds, if the FL task configuration of the FL client remains unchanged, the FL service may 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 may choose to perform steps 9 and 10, or steps 11 through 15. Although not shown in the diagram, the FL client may instead initiate a message to the FL service to share FL status and results. For example, the FL service may provide the FL client with contact information that the FL client uses to target the request (e.g., within the FL task information).

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

[0060] [Table 4-1]

[0061] [Table 4-2]

[0062] Figure 5 shows an exemplary FL job status procedure 500. As shown in Figure 5, the FL service can provide status information about an FL job to an FL user. The FL service can provide the FL job status during the active processing and execution of the FL job, or upon the successful or unsuccessful completion of the FL job. The FL job status can be shared with the FL user by the FL user who retrieves the status from the FL service. Alternatively, the FL user can subscribe to receive FL job notifications from the FL service when an FL job-related event of interest to the FL user occurs.

[0063] When a client starts an FL task, it can provide a status update for each FL task it performs. The FL service can optionally unify and / or forward FL task status updates to the FL user. FL task updates can be monitored by the FL service for each FL task and FL job so that the FL user can monitor the progress of the FL job. When an FL client executes an FL task that supports an FL job, the user can monitor the status of the FL job or the supporting FL tasks. Leveraging this information, the FL user can obtain information that can be used to decide whether to modify pending FL jobs and tasks for a particular FL client, whether to remove an FL client from an FL job, whether to add a new FL client to an FL job, or whether to exclude results from the FL client, i.e., model parameters, while the FL client continues to participate in the FL process.

[0064] In Step 1, the FL service updates the status of the FL job. This status may include changes in the status of the FL job, such as the FL job starting, pausing, resuming, stopping, or completing. The status may include FL job results, such as whether the FL job completed successfully, whether errors occurred, whether the model accuracy level or performance was achieved, whether a training round or task was completed, or whether the trained model and / or model parameters are ready for the FL user. The status may include changes in the status of 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 in the status of an FL task associated with an FL client, such as the FL task starting, pausing, resuming, stopping, or completing. The status may include FL task results, such as whether the FL task completed successfully or whether errors occurred. The status may indicate changes in the configuration, resources, or availability of an FL client.

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

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

[0067] In step 4, instead of retrieving FL job information from the FL service, FL users can subscribe to FL jobs by sending a subscription request to the FL service and receive notifications from the FL service when / when the notification criteria associated with the FL job are met. A subscription request may include notification criteria. Notification criteria may consist of one or more conditions. These conditions may refer to information elements defined within the FL job. For example, a notification criterion may include a condition for when the FL job status changes value.

[0068] In step 5, upon receiving an FL job subscription request, the FL service can create an FL job subscription by storing the subscription information so that it can be accessed by the FL service. The FL job subscription may be stored locally by the FL service or in another service interconnected with the FL service (e.g., a storage service). In addition, the FL service can begin monitoring specified notification criteria to determine whether and when those criteria are met.

[0069] In step 6, the FL service can send a response back to the FL user. The response may include an FL job subscription ID. The response may also include additional information, such as a status code indicating whether the FL job subscription was created successfully or not.

[0070] In Step 7, when the FL service detects that the notification conditions defined within the FL job subscription have been met, the FL service may generate an FL job notification to send 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 FL job information, including but not limited to the information defined in Table 1.

[0071] In step 8, the FL service may send a response back 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.

[0072] It should be noted that steps 1 through 8 may occur at different times during the FL job lifecycle. For example, an FL service may receive these requests while it is actively processing an 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.

[0073] Figure 6 shows an exemplary end-to-end embodiment 600 involving an FL user, an FL service, and an FL client. In this embodiment, the operations defined in the previously described procedure are shown together as an example. Note that this embodiment is an example of how the previously described procedure can interact with each other. Other embodiments may be similarly conceived.

[0074] Steps 1-3 correspond to steps 1-3 in Figure 3. An FL user may have an ML training application that can benefit from FL training and may make a request to the FL service to manage federated training. The FL user may provide the information shown in Table 1 for an FL job. If successful, the FL service can create the FL job and assign an FL ID to it.

[0075] Steps 4-6 correspond to steps 4-6 in Figure 5. FL users may want to receive notifications from the FL service about the progress of their FL jobs. Therefore, FL users may send a subscription request to the FL service along with the FL job ID. The subscription request can specify the notification criteria for when to notify the FL user.

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

[0077] Steps 8-10 correspond to steps 2-4 in Figure 4. The FL service can create FL-specific tasks for each FL client participating in FL training. These tasks can be configured to coordinate and manage the training of ML algorithms / models in a federated manner. FL task information can be specified as shown in Table 2.

[0078] Steps 11-13 correspond to steps 8-10 in Figure 4. Each FL client can perform the FL task specified by the task information configured by the FL service. The FL service can retrieve FL status information from the FL clients to monitor the progress of the training task.

[0079] Steps 14-15 correspond to steps 7-8 in Figure 5. The FL service can send notifications to FL users to provide updates on task progress. Subscription criteria may require the FL service to notify FL users of task status updates.

[0080] Steps 16-18 correspond to steps 4-6 in Figure 3. For example, in response to an FL job notification, an FL user might want to update the FL job information to modify the start or stop conditions for 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 rounds, modify the minimum number of FL clients, modify the minimum number of total data instances, or change the configuration of the FL client.

[0081] Steps 19-20 correspond to steps 11-13 in Figure 4. The FL service subscribes to FL clients so that specific notification criteria are met. For example, the FL service may subscribe to FL clients to detect whether and when updates have been made to the task status of an FL client, such as when the FL client starts, pauses, resumes, cancels, or completes an FL task.

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

[0083] In step 24, each FL client can perform the task specified by the task update received from the FL service.

[0084] Steps 25-26 correspond to steps 14-15 in Figure 4. In an instance some time later, an event is triggered, and one or more FL clients can send a notification to the FL service if the event matches a notification criterion event specified at the time of subscription.

[0085] In step 27, the FL service can update the job status based on receiving notifications from FL clients.

[0086] Steps 28-29 correspond to steps 2-3 in Figure 5. At any time while the FL job is running, the FL user can submit an import request to obtain updates on the status of the FL job. The FL user may want to check the job status or import information about the FL job.

[0087] One method for realizing the aforementioned FL service data preparation functionality is through a RESTful API supported by the FL service. A RESTful API may comprise one or more different types of resources hosted and stored by the FL service, accessed by FL clients and FL users via RESTful operations (e.g., PUT, POST, GET, DELETE) generally referred to as methods. Each type of resource defined for the API may comprise a defined set of informational elements generally referred to as attributes. These resource types and their respective attributes provide a means for the FL service to receive information from FL clients and FL 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 FL users. Therefore, the RESTful API is used by FL clients and FL users to interface with the FL service and access the supported capabilities of the FL service in a RESTful manner.

[0088] The RESTful API for the FL service can support FL job resource types. These FL job resources may have attributes such as those defined in Table 1, but are not limited to these. Other high-level FL configurations, such as the minimum number of training rounds, the minimum number of FL clients (per training round and across the entire FL process), and the minimum total number of data instances, may also be provided by the FL user.

[0089] FL services can also support FL task resource types. These FL task resources may have attributes such as the information elements defined in Table 2, but are not limited to these.

[0090] FL services can also support FL client resource types. These FL client resources may have attributes such as those defined in Table 3, but are not limited to these.

[0091] The FL service can also support the ML model parameter repository resource type. This ML model parameter repository resource may have attributes such as the information elements defined in Table 4, but is not limited to these.

[0092] FL services can also support additional resource types. For example, an FL service may support a resource type used by FL clients to queue and receive FL tasks from the FL service. This resource may be separate from the aforementioned FL client or FL task resource types.

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

[0094] Figure 7 shows an exemplary embodiment of the FL Job GUI 700. FL users can interact with FL services through this GUI to perform the operations defined in the present invention. For example, FL users can configure FL services with FL jobs through this GUI and monitor and track the status of FL jobs as they are executed by the FL services.

[0095] Exemplary communication system The Third Generation Partnership Project (3GPP) develops technical standards for cellular communication network technologies, including radio access, core transport networks, and service capabilities (including work on codecs, security, and quality of service). Recent radio access technology (RAT) standards include WCDMA (commonly known as 3G), LTE (commonly known as 4G), LTE Advanced Standards, and New Radio (NR), also known as "5G". 3GPP NR standards development is expected to continue and include the definition of next-generation radio access technology (New RAT), which is expected to include the provision of new flexible radio access below 7 GHz and 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 it is also expected to include different operating modes that can be multiplexed within the same spectrum to address a wide range of requirements for a broad set of 3GPP NR use cases. Ultra-mobile broadband is expected to include cm and mm spectrum, which can provide opportunities for ultra-mobile broadband access for indoor applications and hotspots, for example. In particular, ultra-mobile broadband is expected to share a common design framework with flexible radio access below 7 GHz, along with design optimizations specific to cm and mm spectrum.

[0096] 3GPP has identified a variety of use cases that NR is expected to support, resulting in a wide range of user experience requirements regarding data rate, latency, and mobility. These use cases include the following common categories: Enhanced Mobile Broadband (eMBB) Ultra-High Reliability 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, where eV2X communications may include any of the following: Vehicle-to-Vehicle Communications (V2V), Vehicle-to-Infrastructure Communications (V2I), Vehicle-to-Network Communications (V2N), Vehicle-to-Pedestrian Communications (V2P), and Vehicle Communications with Other Entities. Specific services and applications within these categories include, to name a few, surveillance and sensor networks, device remote control, two-way remote control, personal cloud computing, video streaming, wireless cloud-based offices, emergency responder connectivity, automotive e-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, as well as others, are intended in this specification.

[0097] Figure 8A shows an exemplary communication system 100 in which the systems, methods, and apparatus described herein and claimed may be used. The communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, 102e, 102f, and / or 102g, which may be commonly or collectively referred to as WTRU 102. The communication system 100 may include a radio access network (RAN) 103 / 104 / 105 / 103b / 104b / 105b, a core network 106 / 107 / 109, a public switched telephone network (PSTN) 108, the Internet 110, other networks 112, and network services 113. Network services 113 may include, for example, a V2X server, V2X functionality, a ProSe server, ProSe functionality, IoT services, video streaming, and / or edge computing.

[0098] It should be recognized that the concepts disclosed herein may be used by any number of WTRUs, base stations, networks, and / or network elements. Each WTRU 102 may be any type of device or apparatus configured to operate and / or communicate in a wireless environment. In the example in Figure 8A, each WTRU 102 is depicted in Figures 8A–8E as a handheld wireless communication device. With the wide variety of use cases intended for wireless communication, each WTRU is understood to include, or may include, any type of device or apparatus configured to transmit and / or receive wireless signals, including, but not limited to, user equipment (UEs), mobile stations, fixed or mobile subscriber units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, tablets, netbooks, notebook computers, personal computers, wireless sensors, consumer electronics, wearable devices such as smartwatches or smart clothing, medical devices or electronic health devices, robots, industrial equipment, drones, automobiles, buses or trucks, trains or aircraft and other vehicles, and the like.

[0099] The communication system 100 may also include base stations 114a and 114b. In the example in Figure 8A, each base station 114a and 114b is shown 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 wirelessly interface with at least one of WTRUs 102a, 102b, and 102c to facilitate access to one or more communication networks such as core networks 106 / 107 / 109, the Internet 110, network services 113, and / or other networks 112. Similarly, base station 114b may be any type of device configured to interface wired and / or wirelessly with at least one of remote radio heads (RRHs) 118a, 118b, transmit and receive points (TRPs) 119a, 119b, and / or roadside units (RSUs) 120a and 120b to facilitate access to one or more communication networks such as core networks 106 / 107 / 109, the Internet 110, other networks 112, and / or network services 113. RRHs 118a, 118b may be any type of device configured to interface wirelessly with at least one of WTRUs 102, for example WTRU 102c, to facilitate access to one or more communication networks such as core networks 106 / 107 / 109, the Internet 110, network services 113, and / or other networks 112.

[0100] TRPs 119a and 119b may be any type of device configured to wirelessly interface with at least one WTRU 102d to facilitate access to one or more communication networks such as core networks 106 / 107 / 109, the Internet 110, network services 113, and / or other networks 112. RSUs 120a and 120b may be any type of device configured to wirelessly interface with at least one WTRU 102e or 102f to facilitate access to one or more communication networks such as core networks 106 / 107 / 109, the Internet 110, other networks 112, and / or network services 113. For example, base stations 114a and 114b may be base transceiver stations (BTS), node B, enode B, home node B, home enode B, next-generation node B (gnode B), satellites, site controllers, access points (APs), wireless routers, and similar.

[0101] Base station 114a may be part of RAN 103 / 104 / 105, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), and relay nodes. 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 a BSC, RNC, and relay nodes. Base station 114a may be configured to transmit and / or receive wireless signals within a specific geographic area, which may be called a cell (not shown). Similarly, base station 114b may be configured to transmit and / or receive wired and / or wireless signals within a specific geographic area, which may also be called a cell (not shown). A cell may be further divided into cell sectors. For example, a cell associated with base station 114a may be divided into three sectors. That is, for example, base station 114a may include three transceivers (e.g., one for each sector of the cell). The base station 114a can employ multi-input multi-output (MIMO) technology, and therefore, for example, multiple transceivers can be used for each sector of the cell.

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

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

[0104] RRH 118a, 118b, TRP 119a, 119b and / or RSU 120a, 120b may communicate with one or more WTRU 102c, 102d, 102e, 102f via air interface 115c / 116c / 117c, which may be any suitable wireless communication link (e.g., RF, microwave, IR, ultraviolet UV, visible light, cm wave, mm wave, etc.). Air interface 115c / 116c / 117c may be established using any suitable RAT.

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

[0106] The communication system 100 may be a multiple access system and may employ one or more channel access schemes such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, base stations 114a in RAN 103 / 104 / 105 and WTRUs 102a, 102b, 102c, or RRHs 118a, 118b, TRPs 119a, 119b and / or RSUs 120a and 120b and WTRUs 102c, 102d, 102e, and 102f in RAN 103b / 104b / 105b may implement radio technology such as Universal Mobile Communications System (UMTS) Terrestrial Radio Access (UTRA), which may use broadband CDMA (WCDMA) to establish air interfaces 115 / 116 / 117 and / or 115c / 116c / 117c, respectively. WCDMA may include communication protocols such as High Speed ​​Packet Access (HSPA) and / or Advanced HSPA (HSPA+). HSPA may include High Speed ​​Downlink Packet Access (HSDPA) and / or High Speed ​​Uplink Packet Access (HSUPA).

[0107] Base stations 114a and WTRUs 102a, 102b, 102c, and 102g within RAN 103 / 104 / 105, or RRHs 118a and 118b, TRPs 119a and 119b and / or RSUs 120a and 120b and WTRUs 102c and 102d within RAN 103b / 104b / 105b, can implement radio technologies such as Advanced UMTS Terrestrial Radio Access (E-UTRA), which can establish air interfaces 115 / 116 / 117 or 115c / 116c / 117c, respectively, using, for example, Long-Term Evolution (LTE) and / or LTE Advanced (LTE-A). 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).

[0108] Base stations 114a and WTRUs 102a, 102b, 102c, 102g within RAN 103 / 104 / 105, or RRHs 118a, 118b, TRPs 119a, 119b and / or RSUs 120a, 120b and WTRUs 102c, 102d, 102e, and 102f within RAN 103b / 104b / 105b, are compatible with IEEE 802.16 (e.g., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, and CDMA2000. Wireless technologies such as 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 for GSM Evolution (EDGE), GSM EDGE (GERAN), and similar technologies can be implemented.

[0109] The base station 114c in Figure 8A may 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 such as businesses, homes, vehicles, trains, antennas, satellites, factories, campuses, and similar locations. The base station 114c and WTRU 102, e.g., WTRU 102e, may implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). Similarly, the base station 114c and WTRU 102, e.g., WTRU 102d, may implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). The base station 114c and WTRU 102, e.g., WTRU 102e, may utilize cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, NR, etc.) to establish picocells or femtocells. As shown in Figure 8A, base station 114c may have a direct connection to the internet 110. Therefore, base station 114c may not need to access the internet 110 via the core network 106 / 107 / 109.

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

[0111] Although not shown in Figure 8A, it should be recognized that RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b and / or core network 106 / 107 / 109 may communicate directly or indirectly with other RANs employing the same RAT as RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b, or different RATs. For example, in addition to being connected to RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b, which may be using E-UTRA radio technology, core network 106 / 107 / 109 may also be communicating with another RAN (not shown) employing GSM or NR radio technology.

[0112] Core networks 106 / 107 / 109 can also function as gateways for WTRU 102 to access PSTN 108, the Internet 110, and / or other networks 112. PSTN 108 may include circuit-switched telephone networks providing legacy telephone services (POTS). The Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols such as Transmit Control Protocol (TCP), User Datagram Protocol (UDP), and Internet Protocol (IP) of the TCP / IP 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 packet data networks (e.g., IEEE 802.3 Ethernet networks) or any type of other core network connected to one or more RANs, which may employ the same or a different RAT as RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b.

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

[0114] Although not shown in Figure 8A, it may be assumed that user equipment can make a wired connection to the gateway. The gateway may be a residential gateway (RG). The RG can provide connectivity to the core network 106 / 107 / 109. It may be assumed that many of the concepts contained herein can be applied equally to UEs that are WTRUs and to UEs that use wired connections to connect to the network. For example, concepts that apply to wireless interfaces 115, 116, 117 and 115c / 116c / 117c can be applied equally to wired connections.

[0115] Figure 8B is a system diagram of an exemplary RAN 103 and core network 106. As described above, RAN 103 may employ UTRA radio technology to communicate with WTRU 102a, 102b, and 102c via the air interface 115. RAN 103 may also communicate with the core network 106. As shown in Figure 8B, RAN 103 may include nodes B 140a, 140b, and 140c, each of which may include one or more transceivers to communicate with WTRU 102a, 102b, and 102c via the air interface 115. Nodes B 140a, 140b, and 140c may each be associated with a specific cell (not shown) within RAN 103. RAN 103 may also include RNCs 142a and 142b. It may be recognized that RAN 103 may include any number of node Bs and radio network controllers (RNCs).

[0116] As shown in Figure 8B, nodes B 140a and 140b may communicate with RNC 142a. In addition, node B 140c may communicate with RNC 142b. Nodes B 140a, 140b, and 140c can communicate with their respective RNCs 142a and 142b via the Iub interface. RNCs 142a and 142b may communicate with each other via the Iur interface. Each of RNCs 142a and 142b may be configured to control their respective nodes B 140a, 140b, and 140c to which it is connected. In addition, each of RNCs 142a and 142b may be configured to perform or support other functions such as outer loop power control, load control, admission control, packet scheduling, handover control, macro diversity, security functions, data encryption, and the like.

[0117] The core network 106 shown in Figure 8B 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 aforementioned elements is depicted as part of the core network 106, it should be recognized that any one of these elements may be owned and / or operated by an entity other than the core network operator.

[0118] The RNC 142a in RAN 103 may be connected to the MSC 146 in the core network 106 via the IuCS interface. The MSC 146 may be connected to the MGW 144. The MSC 146 and MGW 144 may provide the WTRUs 102a, 102b, and 102c with access to a circuit-switched network such as the PSTN 108 to facilitate communication between the WTRUs 102a, 102b, and 102c and conventional fixed telephone line communication devices.

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

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

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

[0122] RAN 104 may include e-nodes B 160a, 160b, and 160c, but it may be recognized that RAN 104 may include any number of e-nodes B. Each of e-nodes B 160a, 160b, and 160c may include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via the air interface 116. For example, e-nodes B 160a, 160b, and 160c can implement MIMO technology. Thus, for example, e-node B 160a can use multiple antennas to transmit a wireless signal to WTRU 102a and to receive a wireless signal from WTRU 102a.

[0123] Each of the e-nodes B 160a, 160b, and 160c may be associated with a specific cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, user scheduling on uplink and / or downlink, and similar matters. As shown in Figure 8C, the e-nodes B 160a, 160b, and 160c can communicate with each other via the X2 interface.

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

[0125] MME 162 may be connected via the S1 interface to each of the eNode-B 160a, 160b, and 160c within RAN 104 and can function as a control node. For example, MME 162 may be responsible for authenticating users of WTRU 102a, 102b, and 102c, bearer activation / deactivation, selecting a specific serving gateway during the initial attachment of WTRU 102a, 102b, and 102c, and similar tasks. MME 162 may also provide control plane functionality for switching between RAN 104 and other RANs (not shown) employing other radio technologies such as GSM or WCDMA.

[0126] Serving gateway 164 may be connected to eNode B 160a, 160b, and 160c in RAN 104 via the S1 interface. Serving gateway 164 can generally route and forward user data packets to and from WTRU 102a, 102b, and 102c. Serving gateway 164 can also perform other functions, such as anchoring the user plane during inter-eNode B handovers, triggering paging when downlink data is available to WTRU 102a, 102b, and 102c, managing and remembering the context of WTRU 102a, 102b, and 102c, and similar functions.

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

[0128] The core network 107 can facilitate communication with other networks. For example, the core network 107 can provide WTRUs 102a, 102b, and 102c with access to a circuit-switched network such as the PSTN 108 to facilitate communication between WTRUs 102a, 102b, and 102c and conventional fixed telephone line communication devices. For example, the 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 the core network 107 and the PSTN 108. In addition, the core network 107 may also 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.

[0129] Figure 8D is a system diagram of an exemplary RAN 105 and core network 109. RAN 105 may employ NR radio technology to communicate with WTRUs 102a and 102b via air interface 117. RAN 105 may also communicate with core network 109. Non-3GPP interworking function (N3IWF) 199 may employ non-3GPP radio technology to communicate with WTRU 102c via air interface 198. N3IWF 199 may also communicate with core network 109.

[0130] RAN 105 may include g-node B 180a and 180b. It may be recognized that RAN 105 may include any number of g-node B. Each of g-node B 180a and 180b may include one or more transceivers for communicating with WTRU 102a and 102b via air interface 117. When aggregation access and backhaul connectivity are used, the same air interface may be used between the WTRU and the g-node B, which may be the core network 109 via one or more g-node Bs. g-node B 180a and 180b may implement MIMO, MU-MIMO, and / or digital beamforming technologies. For example, g-node B 180a may use multiple antennas to transmit wireless signals to and receive wireless signals from WTRU 102a. It should be recognized that RAN 105 may employ other types of base stations, such as e-node B. It may be recognized that RAN 105 can employ multiple types of base stations. For example, RAN may employ e-node B and g-node B.

[0131] N3IWF 199 may include non-3GPP access points 180c. It may be recognized that N3IWF 199 may include any number of non-3GPP access points. A non-3GPP access point 180c may include one or more transceivers for communicating with WTRU 102c via air interface 198. A non-3GPP access point 180c may use the 802.11 protocol to communicate with WTRU 102c via air interface 198.

[0132] Each of the g-nodes B 180a and 180b may be associated with a specific cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, user scheduling on uplink and / or downlink, and similar matters. As shown in Figure 8D, g-nodes B 180a and 180b can communicate with each other, for example, via the Xn interface.

[0133] The core network 109 shown in Figure 8D may be a 5G core network (5GC). The core network 109 can provide numerous communication services to customers interconnected by a wireless access network. The core network 109 comprises several entities that perform the functions of the core network. 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. Such core network entities may be logical entities implemented in the form of computer executable instructions (software) stored in the memory of a device configured for wireless and / or network communications, or in the memory of a computer system such as system 90 shown in Figure 8G and executed on its processor.

[0134] In the example in Figure 8D, the 5G core network 109 may include an Access and Mobility Management Function (AMF) 172, a Session Management Function (SMF) 174, User Plane Functions (UPF) 176a and 176b, a User Data Management Function (UDM) 197, an Authentication Server Function (AUSF) 190, a Network Exposure Function (NEF) 196, a Policy Control Function (PCF) 184, a Non-3GPP Interworking Function (N3IWF) 199, and a User Data Repository (UDR) 178. While each of the aforementioned elements is depicted as part of the 5G core network 109, it should be recognized that any one of these elements may be owned and / or operated by an entity other than the core network operator. It should also be recognized that the 5G core network may not consist of all of these elements, may consist of additional elements, and may consist of multiple instances of each of these elements. Figure 8D shows that network functions are directly connected to each other, but it should be noted that they can communicate via routing agents such as the Diameter Routing Agent or via a message bus.

[0135] In the example in Figure 8D, connectivity between network functions is achieved through a set of interfaces or reference points. Network functions may be perceived as being modeled, described, or implemented as a set of services that are invoked or called by other network functions or services. Invocation of network function services may be achieved by direct connections between network functions, exchange of messages on a message bus, calling software functions, etc.

[0136] The AMF 172 may be connected to the RAN 105 via the N2 interface and can function as a control node. For example, the AMF 172 can be responsible for registration management, connection management, reachability management, access authentication, and access permission. The AMF may be responsible for forwarding user plane tunnel configuration information to the 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 can generally route and forward NAS packets to and from WTRUs 102a, 102b, and 102c via the N1 interface. The N1 interface is not shown in Figure 8D.

[0137] SMF 174 may be connected to AMF 172 via the N11 interface. Similarly, SMF may be connected to PCF 184 via the N7 interface, and to UPF 176a and 176b via the N4 interface. SMF 174 can function as a control node. For example, SMF 174 can be responsible for session management, IP address allocation to WTRU 102a, 102b, and 102c, management and configuration of traffic steering rules in UPF 176a and UPF 176b, and generation of downlink data notifications to AMF 172.

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

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

[0140] PCF 184 may be connected to SMF 174 via the N7 interface, to AMF 172 via the N15 interface, and to Application Function (AF) 188 via the N5 interface. The N15 and N5 interfaces are not shown in Figure 8D. PCF 184 may provide policy rules to control plane nodes such as AMF 172 and SMF 174 so that the control plane nodes can enforce these rules. PCF 184 may send policies to AMF 172 toward WTRUs 102a, 102b, and 102c so that AMF can distribute the policies to WTRUs 102a, 102b, and 102c via the N1 interface. The policies can then be enforced or applied in WTRUs 102a, 102b, and 102c.

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

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

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

[0144] NEF 196 exposes the capabilities and services of the 5G core network 109 to application function (AF) 188. Exposure can be performed via the N33 API interface. NEF can connect to AF 188 via the N33 interface, which can then connect to other network functions to expose the capabilities and services of the 5G core network 109.

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

[0146] Network slicing is a mechanism that can be used by mobile network operators 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 allows operators to create customized networks that provide optimized solutions for different market scenarios demanding various requirements in the areas of functionality, performance, and isolation.

[0147] 3GPP is designing the 5G core network to support network slicing. Network slicing is a good tool that network operators can use to support a wide range of 5G use cases (e.g., large-scale IoT, critical communications, V2X, and enhanced mobile broadband) that demand highly diverse and sometimes extreme requirements. Without network slicing techniques, the network architecture may not be flexible and scalable enough to efficiently support the wide range of use cases required when each use case has its own specific set of performance requirements, scalability requirements, and availability requirements. Furthermore, the introduction of new network services should be more efficient.

[0148] Referring again to Figure 8D, in a network slicing scenario, WTRU 102a, 102b, or 102c can be connected to AMF 172 via the N1 interface. The AMF can be logically part of one or more slices. The AMF can coordinate the connection or communication between WTRU 102a, 102b, or 102c and one or more UPF 176a and 176b, SMF 174, and other network functions. Each of the UPF 176a, 176b, SMF 174, and other network functions can be part of the same slice or different slices. When they are part of different slices, they can be isolated from each other in the sense that they can utilize different computing resources, security authentication certificates, etc.

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

[0150] The core network entities described herein and illustrated in Figures 8A, 8C, 8D, and 8E are identified by the names assigned to them in certain existing 3GPP specifications, but it is understood that in the future, these entities and functionalities may be identified by other names, and that certain entities or functionalities may be combined in future specifications issued by 3GPP, including future 3GPP NR specifications. Accordingly, the certain network entities and functionalities described and illustrated in Figures 8A, 8B, 8C, 8D, and 8E are provided merely as examples, 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 future defined.

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

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

[0153] WTRUs A, B, C, D, E, and F can communicate with RSU 123a or 123b via vehicle-to-network (V2N) 133 or side-link 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.

[0154] Figure 8F is a block diagram of an exemplary apparatus or device WTRU 102 that can be configured for wireless communication and operation by the systems, methods, and apparatus described herein, such as WTRU 102 in Figures 8A, 8B, 8C, 8D, or 8E. As shown in Figure 8F, the exemplary WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad / indicator 128, a non-removable memory 130, a removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136, and other peripherals 138. It may be recognized that WTRU 102 may include any subcombination of the aforementioned elements. Furthermore, base stations 114a and 114b, and / or, but not limited to, nodes that base stations 114a and 114b may represent, such as transceiver stations (BTS), node B, site controllers, access points (AP), home node B, evolved home node B (e node B), home evolved node B (HeNB), home evolved node B gateway, next-generation node B (g node B), and proxy nodes, may include some or all of the elements depicted in Figure 8F and described herein.

[0155] The processor 118 may be a general-purpose processor, a dedicated processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors coupled 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, and the like. The processor 118 can perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to a transceiver 120 which may be coupled to a transmit / receive element 122. Although Figure 8F depicts the processor 118 and the transceiver 120 as separate configuration elements, it may be recognized that the processor 118 and the transceiver 120 can be aggregated together in an electronic package or chip.

[0156] The transmit / receive element 122 of the UE may be configured to transmit a signal to a base station (e.g., base station 114a in Figure 8A) or to another UE via air interfaces 115d / 116d / 117d, or to receive a signal from another UE via air interfaces 115d / 116d / 117d. For example, the transmit / receive element 122 may be an antenna configured to transmit and / or receive RF signals. The transmit / receive element 122 may be an emitter / detector configured to transmit and / or receive IR, UV, or visible light signals, for example. The transmit / receive element 122 may be configured to transmit and / or receive both RF and optical signals. The transmit / receive element 122 may be configured to transmit and / or receive any combination of wireless or wired signals.

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

[0158] The transceiver 120 can be configured to modulate the signal to be transmitted by the transmit / receive element 122 and to demodulate the signal received by the transmit / receive element 122. As described above, the WTRU 102 may have multimode capability. Therefore, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate using multiple RATs, e.g., NR and IEEE 802.11 or NR and E-UTRA, or to enable communication using the same RAT over multiple beams to different RRHs, TRPs, RSUs, or nodes.

[0159] The processor 118 of WTRU 102 can be coupled to a speaker / microphone 124, a keypad 126, and / or a display / touchpad / indicator 128 (for example, a liquid crystal display (LCD) display unit or an organic light-emitting diode (OLED) display unit, and can receive user input data from these). The processor 118 can also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad / indicator 128. In addition, the processor 118 can provide any type of memory such as non-removable memory 130 and / or removable memory 132. The processor 118 can access information from appropriate memory and store data in any type of appropriate memory. Non-removable memory 130 may include random access memory (RAM), read-only memory (ROM), hard disk, or any other type of memory storage device. Removable memory 132 may include subscriber identification module (SIM) cards, memory sticks, secure digital (SD) memory cards, and similar. The processor 118 can access information from memory not physically located on the WTRU 102, such as on a server hosted in the cloud, on an edge computing platform, or on a home computer (not shown), and can store data in memory.

[0160] The processor 118 can receive power from the power supply 134 and may be configured to distribute and / or control power to other configuration elements of the WTRU 102. The power supply 134 may be any suitable device for supplying power to the WTRU 102. For example, the power supply 134 may include one or more dry cell batteries, solar cells, fuel cells, and the like.

[0161] The processor 118 may also be coupled to a GPS chipset 136 which can be configured to provide location information (e.g., longitude and latitude) about the current location of the WTRU 102. In addition to, or instead of, information from the GPS chipset 136, the WTRU 102 may receive location information 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. The WTRU 102 may be recognized as being able to acquire location information by any suitable location determination method.

[0162] The processor 118 may also be coupled to other peripherals 138, which may include one or more software modules and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, peripherals 138 may include a variety of sensors such as accelerometers, biometric (e.g., fingerprint) sensors, electronic compasses, satellite transceivers, digital cameras (for photography or video), Universal Serial Bus (USB) ports or other interconnection interfaces, vibration devices, television transceivers, hands-free headsets, Bluetooth® modules, frequency modulation (FM) radio units, digital music players, media players, video game player modules, internet browsers, and the like.

[0163] WTRU 102 may be included in other devices or equipment such as sensors, consumer electronics, wearable devices such as smartwatches or smart clothing, medical devices or electronic health devices, robots, industrial equipment, drones, automobiles, trucks, trains or aircraft, etc. WTRU 102 may be connected to other configuration elements, modules, or systems of such devices or equipment via one or more interconnect interfaces, such as an interconnect interface which may include one of the peripherals 138.

[0164] Figure 8G is a block diagram of an exemplary computing system 90, such as a specific node or functional entity in RAN 103 / 104 / 105, core networks 106 / 107 / 109, PSTN 108, the Internet 110, other networks 112, or network services 113, in which one or more devices of the communication networks illustrated in Figures 8A, 8C, 8D, and 8E may be realized. The computing system 90 may comprise a computer or server and may be controlled primarily by computer-readable instructions, which may be in the form of software, wherever or by any means such software is stored or accessed. Such computer-readable instructions are executed within a processor 91 to cause the computing system 90 to perform tasks. The processor 91 may be a general-purpose processor, a dedicated processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors coupled 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, and the like. The processor 91 can perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the computing system 90 to operate on a communication network. The coprocessor 81 is an optional processor separate from the main processor 91 that can perform additional functions or assist the processor 91. The processor 91 and / or coprocessor 81 can receive, generate, and process data related to the methods and apparatus disclosed herein.

[0165] During operation, the processor 91 fetches, decodes, and executes instructions, and transfers information to and from other resources via the system bus 80, which is the primary data transfer path of the computing system. Such a system bus connects the configuration elements of the computing system 90 and defines the medium for data exchange. The system bus 80 typically includes data lines for sending data, address lines for sending addresses, and control lines for sending interrupts and for operating the system bus. An example of such a system bus 80 is the PCI (Peripheral Interconnect) bus.

[0166] The memory coupled to the system bus 80 includes random access memory (RAM) 82 and read-only memory (ROM) 93. Such memory includes circuitry that enables information to be stored and retrieved. ROM 93 generally contains stored data that cannot be 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 can provide address translation functionality, which translates virtual addresses to physical addresses when instructions are executed. The memory controller 92 can also provide memory protection functionality, which isolates processes within the system and separates system processes from user processes. Thus, a program operating in the first mode can only access memory mapped by its own process virtual address space, and it cannot access memory in the virtual address space of another process unless inter-process memory sharing is configured.

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

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

[0169] Furthermore, the computing system 90 may also include communication circuits, 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, such as the RAN 103 / 104 / 105, core network 106 / 107 / 109, PSTN 108, the Internet 110, WTRU 102, or other network 112 in Figures 8A, 8B, 8C, 8D, and 8E, in order to enable the computing system 90 to communicate with other nodes or functional entities in those networks. The communication circuits may be used alone or in combination with the processor 91 to perform the transmission and reception steps of the specific devices, nodes, or functional entities described herein.

[0170] Any or all of the devices, 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, such instructions, when executed by a processor such as processor 118 or 91, are understood to cause the processor to perform and / or implement the systems, methods, and processes described herein. Specifically, any of the steps, operations, or functions described herein may be implemented in the form of such computer-executable instructions and executed on a processor of a device or computing system configured for wireless and / or wired network communication. Computer-readable storage medium includes volatile and non-volatile, removable and inremovable media implemented by any non-temporary (e.g., tangible or physical) method or technique for storing information, but such computer-readable storage medium does not contain signals. Computer-readable storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disk (DVD) or other optical disk storage, magnetic cassette, magnetic tape, magnetic 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. A device associated with associative learning (FL) services, One or more processors, When executed by the one or more processors, The system receives requests from FL users to create or update FL jobs, and such requests include FL job information indicating one or more machine learning (ML) requirements and one or more FL training requirements. Based on the aforementioned FL job information, To determine whether the aforementioned FL user is authorized to perform the aforementioned FL job, Select one or more FL clients that meet one or more FL training requirements, or To determine one or more FL tasks associated with the FL job and to be performed by one or more FL clients, Perform at least one of the following: A response including the FL job ID and FL request status information is sent to the FL user. Send one or more FL task requests containing FL task information to the one or more FL clients: The FL task status information is received from one or more FL clients. Based on the received FL task status information, a decision is made as to whether to conduct one or more FL training rounds. Send FL job status information to the aforementioned FL user. A memory that stores instructions to cause the device to do the above An apparatus characterized by being equipped with

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

3. The apparatus according to 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, or a maximum length of data.

4. The apparatus according to claim 1, wherein the FL job information further indicates an FL client configuration that shows at least one of an FL client ID list, one or more FL client training requirements, or an FL client data filter.

5. The apparatus according to claim 1, characterized in that the FL job status information indicates at least one of the following: whether the FL job has not started, started, paused, resumed, stopped, canceled, or completed, or the current FL round number.

6. The apparatus according to claim 1, characterized in that the one or more ML requirements represent at least one of the following: one or more ML algorithms, ML problem types, multi-model training modes, one or more hyperparameters, a model evaluation function, a model initialization, an aggregation algorithm, a minimum number of FL training rounds, a minimum number of FL clients, or a minimum number of total data instances.

7. When the instruction is executed by one or more processors, Determine whether or not to start the aforementioned FL job, and when to start it. The apparatus according to claim 1, characterized in that it further causes the apparatus to do the above.

8. When the instruction is executed by one or more processors, Send an FL task subscription or retrieval request to one or more of the aforementioned FL clients in order to obtain the FL task results and the FL task status information. The apparatus according to claim 1, characterized in that it further causes the apparatus to do the above.

9. When the instruction is executed by one or more processors, The system receives FL job subscriptions or retrieval requests from one or more FL users to obtain FL job results and status information of interest to those users. The apparatus according to claim 1, characterized in that it further causes the apparatus to do the above.

10. When the instruction is executed by one or more processors, Send a notification to the aforementioned FL user indicating FL-related events. The apparatus according to claim 1, characterized in that it further causes the apparatus to do the above.

11. A device associated with a federative learning (FL) client, One or more processors, When executed by the one or more processors, The FL service receives one or more FL task requests containing FL task information, and the FL task information indicates one or more machine learning (ML) requirements and one or more FL training requirements. Based on the one or more FL task requests, perform one or more FL tasks. Send one or more notifications containing FL task status information to the FL service. A memory that stores instructions to cause the device to do the above An apparatus characterized by being equipped with

12. The apparatus according to claim 11, wherein the one or more FL training requirements include at least one of 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, or a maximum length of data.

13. The apparatus according to claim 11, wherein the FL job information further indicates an FL client configuration that shows at least one of an FL client ID list, one or more FL client training requirements, or an FL client data filter.

14. The apparatus according to claim 11, characterized in that the FL job status information indicates at least one of the following: whether the FL job has not started, started, paused, resumed, stopped, canceled, or completed, or the current FL round number.

15. Receiving requests from federated learning (FL) users to create or update FL jobs, wherein the requests include FL job information indicating one or more machine learning (ML) requirements and one or more FL training requirements. Based on the aforementioned FL job information, To determine whether the aforementioned FL user is authorized to perform the aforementioned FL job, Select one or more FL clients that meet one or more FL training requirements, or To determine one or more FL tasks associated with the FL job and to be performed by one or more FL clients, To do at least one of the following, Send a response to the aforementioned FL user, including the FL job ID and FL request status information. Sending one or more FL task requests containing FL task information to one or more of the aforementioned FL clients, Receiving FL task status information from one or more FL clients, Based on the received FL task status information, it is determined whether to perform one or more FL training rounds. Sending FL job status information to the aforementioned FL user A method characterized by comprising:

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

17. The method according to 15, wherein the one or more FL training requirements include at least one of 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, or a maximum length of data.

18. The method according to 15, wherein the FL job information further indicates an FL client configuration that shows at least one of an FL client ID list, one or more FL client training requirements, or an FL client data filter.

19. The method according to 15, characterized in that the FL job status information indicates at least one of the following: whether the FL job has not started, started, paused, resumed, stopped, canceled, or completed, or the current FL round number.

20. The method according to 15, characterized in that the one or more ML requirements include at least one of the following: one or more ML algorithms, an ML problem type, a multi-model training mode, one or more hyperparameters, a model evaluation function, a model initialization, an aggregation algorithm, a minimum number of training rounds, a minimum number of FL clients, or a minimum number of total data instances.

Images