Method and apparatus for federated learning in a network

Abstract

A method for performing a federated learning process in a network is provided. The method includes transmitting, by a first computing node, a request message to a plurality of client computing nodes to participate in the federated learning process. The method also includes receiving, by the first computing node, at least one response message in response to the request message; selecting, based on the at least one response message, which client computing nodes will participate in the federated learning process; and notifying the selected computing nodes to perform the federated learning process. The request message has a message type or flag indicating an ML (machine learning) preparation phase. According to one embodiment of the present disclosure, the request message also includes information indicating available data requirements and / or available time requirements. This information may be useful for the client computing nodes to determine whether to participate in the federated learning process.

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This patent application claims priority to U.S. Provisional Patent Application No. 63 / 437,283, filed January 5, 2023, the disclosure of which is incorporated by reference in its entirety.

[0002] (Technical field) The present disclosure relates to computing systems, and more particularly to federated learning (FL) in networks. [Background technology]

[0003] Federated learning (FL) is a machine learning (ML) technique in which local data samples are distributed across multiple computing nodes (e.g., edge devices, servers, etc.) in a network, typically without the need to exchange local data samples. Federated learning, also known as collaborative learning, contrasts with traditional centralized machine learning techniques in which all local datasets are located on a single server, as well as other distributed approaches in which local data samples are identically distributed across all computing nodes.

[0004] Federated learning can enable multiple vendors to build common machine learning models without sharing data, which can address issues such as data privacy, data security, data access rights, and access to disparate data. Applications of federated learning are widespread across many industries, including defense, telecommunications, IoT, and medicine.

[0005] A network may include many computing nodes, but not all of these computing nodes may be suitable candidates for participating in a federated learning process. A need exists for identifying and selecting suitable candidates for participating in a federated learning process. Summary of the Invention

[0006] According to one aspect, a method is provided for performing a federated learning process in a network. The method includes transmitting, by a first computing node, to a plurality of client computing nodes a request message to participate in the federated learning process. The method also includes receiving, by the first computing node, at least one response message in response to the request message. The method also includes selecting, by the first computing node, which computing nodes of the plurality of client computing nodes to participate in the federated learning process based on the at least one response message. The method also includes notifying, by the first computing node, the selected computing nodes to perform the federated learning process.

[0007] The request message has a message type or flag indicating an ML (Machine Learning) preparation phase. According to one embodiment of the present disclosure, the request message also includes information indicating available data requirements and / or available time requirements. This information may be useful for the client computing node to decide whether to participate in the federated learning process. This information may also be useful for the client computing node to perform the federated learning process. In some embodiments, the information from the request message indicates both available data requirements and available time requirements.

[0008] In some embodiments, the request message also includes interoperability information, where information indicating available data requirements and / or available time requirements is additional information that supplements the interoperability information. The combination of information provided to the client computing node may be useful for the client computing node to determine whether to participate in a federated learning process. This combination of information may also be useful for the client computing node to perform the federated learning process.

[0009] In some embodiments, the request message is sent and the selected computing nodes are notified using the same service. In this way, the service used to send the request message can be extended or reused to notify the selected computing nodes to begin running FL training. The extension or reuse of the service can provide various advantages in terms of efficiency.

[0010] According to another aspect, a method is provided for performing a federated learning process in a network. The method includes transmitting, by a first computing node, to a plurality of client computing nodes a request message to participate in the federated learning process. The method also includes receiving, by the first computing node, at least one response message in response to the request message. The method also includes selecting, by the first computing node, which computing nodes of the plurality of client computing nodes to participate in the federated learning process based on the at least one response message. The method also includes notifying, by the first computing node, the selected computing nodes to perform the federated learning process.

[0011] The request message has a message type or flag indicating a machine learning (ML) preparation phase. According to one embodiment of the present disclosure, the request message is sent and the selected computing nodes are notified using the same service. In this way, the service used to send the request message can be extended or reused to notify the selected computing nodes to begin running FL training. The extension or reuse of the service can provide various advantages in terms of efficiency.

[0012] According to another aspect, there is provided a non-transitory computer-readable medium having recorded thereon statements and instructions that, when executed by a processor of a first computing node, configure the processor to implement a method as summarized above.

[0013] According to another aspect, a first computing node configured to perform a federated learning process in a network is provided. The first computing node has a network interface configured to communicate with other computing nodes in the network and a federated learning circuit coupled to the network interface. The federated learning circuit is configured to send, via the network interface, request messages to a plurality of client computing nodes to participate in the federated learning process. The federated learning circuit is also configured to receive, via the network interface, at least one response message in response to the request messages. The federated learning circuit is also configured to select which computing nodes of the plurality of client computing nodes will participate in the federated learning process based on the at least one response message. The federated learning circuit is also configured to notify, via the network interface, the selected computing nodes to perform the federated learning process.

[0014] The request message has a message type or flag indicating an ML (machine learning) preparation phase. According to one embodiment of the present disclosure, the request message also includes information indicating available data requirements and / or available time requirements. This information may be useful for the client computing node to decide whether to participate in the federated learning process. This information may also be useful for the client computing node to execute the federated learning process. In some embodiments, the information from the request message indicates both available data requirements and available time requirements.

[0015] According to another aspect, a first computing node configured to perform a federated learning process in a network is provided. The first computing node has a network interface configured to communicate with other computing nodes in the network and a federated learning circuit coupled to the network interface. The federated learning circuit is configured to send request messages to a plurality of client computing nodes via the network interface to participate in the federated learning process. The federated learning circuit is also configured to receive at least one response message via the network interface in response to the request messages. The federated learning circuit is also configured to select which computing nodes of the plurality of client computing nodes will participate in the federated learning process based on the at least one response message. The federated learning circuit is also configured to notify the selected computing nodes via the network interface to perform the federated learning process.

[0016] The request message has a message type or flag indicating a machine learning (ML) preparation phase. According to one embodiment of the present disclosure, the request message is sent and the selected computing nodes are notified using the same service. In this way, the service used to send the request message can be extended or reused to notify the selected computing nodes to begin running FL training. The extension or reuse of the service can provide various advantages in terms of efficiency.

[0017] According to another aspect, a method is provided for performing a federated learning process in a network. The method includes receiving, by a client computing node, a request message to participate in the federated learning process. The method also includes determining, by the client computing node, whether to participate in the federated learning process based on the availability and capabilities of the client computing node, taking into account information provided in the request message. The method also includes transmitting, by the client computing node, a response message indicating whether to participate in the federated learning process.

[0018] The request message has a message type or flag indicating an ML (machine learning) preparation phase. According to one embodiment of the present disclosure, the request message also includes information indicating available data requirements and / or available time requirements. This information may be useful for the client computing node to determine whether to participate in the federated learning process. This information may also be useful for the client computing node to execute the federated learning process. In some implementations, the information from the request message indicates both available data requirements and available time requirements.

[0019] In some implementations, the request message also includes interoperability information, such that information indicating available data requirements and / or available time requirements is additional information that supplements the interoperability information. The combination of information provided to the client computing node may be useful for the client computing node to determine whether to participate in a federated learning process. This combination of information may also be useful for the client computing node to perform the federated learning process.

[0020] According to another aspect, there is provided a non-transitory computer-readable medium having recorded thereon statements and instructions that, when executed by a processor of a client computing node, configure the processor to implement the method summarized above.

[0021] According to another aspect, a client computing node configured to perform a federated learning process in a network is provided. The client computing node has a network interface configured to communicate with other computing nodes in the network and a federated learning circuit coupled to the network interface. The federated learning circuit is configured to receive, via the network interface, a request message to participate in the federated learning process, the request message having a message type or flag indicating an ML (machine learning) preparation phase. The federated learning circuit is also configured to determine whether to participate in the federated learning process based on the availability and capabilities of the client computing node, taking into account information provided by the request message. The federated learning circuit is also configured to transmit, via the network interface, a response message indicating whether to participate in the federated learning process.

[0022] The request message has a message type or flag indicating an ML (machine learning) preparation phase. According to one embodiment of the present disclosure, the request message also includes information indicating available data requirements and / or available time requirements. This information may be useful for the client computing node to determine whether to participate in the federated learning process. This information may also be useful for the client computing node to execute the federated learning process. In some implementations, the information from the request message indicates both available data requirements and available time requirements.

[0023] Other aspects and features of the present disclosure will become apparent to those of ordinary skill in the art upon review of the following description of various embodiments of the present disclosure. [Brief explanation of the drawings]

[0024] Hereinafter, embodiments will be described with reference to the accompanying drawings. [Figure 1] FIG. 1 is a block diagram of an example network with computing nodes for federated learning. [Figure 2] FIG. 10 is a sequence diagram of a method for performing federated learning processing in a network. [Figure 3A] FIG. 1 is a block diagram of a system with signaling shown for a provisioning request. [Figure 3B] FIG. 1 is a block diagram of a system with signaling shown for preparation messages in an ML preparation phase. [Figure 3C] FIG. 1 is a block diagram of a system with signaling shown for preparation messages in the ML execution phase. [Figure 3D] FIG. 1 is a block diagram of a system with signaling shown for the extended Nnwdaf_MLPreparation service. [Figure 4] FIG. 1 is a sequence diagram of a process for federated learning training among multiple NWDAFs (Network Data Analytics Functions). [Figure 5] FIG. 1 is a sequence diagram of the process for client NWDAF(s) selection in the federated learning preparation phase. [Figure 6] FIG. 10 is a sequence diagram of the process for NWDAF monitoring and reselection during the federated learning execution phase. [Figure 7] FIG. 10 is a sequence diagram of a process for dynamic discovery of a new NWDAF in the federated learning execution phase when information about the server NWDAF is known at the new client NWDAF. [Figure 8]FIG. 10 is a sequence diagram of a process for dynamic discovery of a new NWDAF in the federated learning execution phase when information about the server NWDAF is unknown at the new client NWDAF. [Figure 9] FIG. 1 is a sequence diagram of a process for extending a service in the FL preparation phase and the FL execution phase. [Figure 10A] FIG. 10 is a sequence diagram of another method for performing a federated learning process in a network. [Figure 10B] FIG. 10 is a sequence diagram of another method for performing a federated learning process in a network. [Figure 11] FIG. 1 is a sequence diagram of a method for subscribing and unsubscribing to an ML model for analysis. [Figure 12] 1 is a schematic diagram of an example cellular communication system in which some embodiments of the present disclosure may be implemented. [Figure 13] 1 is a block diagram of a wireless communication system, represented as a 5G network architecture, in which some embodiments of the present disclosure may be implemented. [Figure 14] 1 is a block diagram of a wireless communication system, represented as a 5G network architecture, in which some embodiments of the present disclosure may be implemented. DETAILED DESCRIPTION OF THE INVENTION

[0025] First, while exemplary implementations of one or more embodiments of the present disclosure are provided below, it should be understood that the disclosed systems and / or methods may be implemented using any number of techniques. The present disclosure should in no way be limited to the exemplary implementations, drawings, and techniques illustrated below, including the exemplary designs and implementations shown and described herein, but may be modified within the scope of the appended claims, along with the full scope of equivalents.

[0026] (introduction) Referring initially to FIG. 1 , a block diagram of an exemplary network 130 having computing nodes 140 and 150a-n for federated learning is shown. Network 130 may have other components as well, which are not shown for simplicity. In some implementations, network 130 may be a core network of a cellular communication system, e.g., a 5G core network. However, other implementations are possible and within the scope of this disclosure. Computing nodes 140 and 150a-n include first computing node 140 and client computing nodes 150a-n. The number of computing nodes 140 and 150a-n may vary and is implementation specific.

[0027] The first computing node 140 has a network interface 142 configured to communicate with other computing nodes of the network 130, such as client computing nodes 150a-n. The first computing node 140 also has a federated learning circuit 144 coupled to the network interface 142. In some implementations, the federated learning circuit 144 includes a processor 146 that executes software that may be derived from a CRM (computer-readable medium) 148. However, other implementations are possible and within the scope of this disclosure. The first computing node 140 may have additional components, which are not shown for simplicity.

[0028] The client computing nodes 150a-n are shown with a configuration corresponding to that of the first computing node 140, and thus similarly have a network interface 152 and a federated learning circuit 154. However, it should be understood that the client computing nodes 150a-n can have a variety of different configurations. Note that the computing nodes 140 and 150a-n may be from different vendors and therefore may vary in configuration.

[0029] The first computing node 140 and the federated learning circuit 144 of the client computing nodes 150a-n operate to implement a method for performing a federated learning process in the network 130. Such operation is described below with reference to FIG. 2, which is a flowchart of a method for performing a federated learning process in a network. Although the method of FIG. 2 is described below with reference to the computing nodes 140 and 150a-n in the network 130 shown in FIG. 1, it should be understood that the method of FIG. 2 is applicable to other communication systems. In general, the method of FIG. 2 is applicable to computing nodes in any suitably configured network.

[0030] In step 2-1, the first computing node 140 sends a request message to participate in the federated learning process. The request message is sent to the client computing nodes 150a-n. This can be implemented in a multicast manner as shown, or in other manners, such as daisy chaining. In step 2-2, each client computing node 150a-n receives the request message. Not all of the client computing nodes 150a-n may be suitable candidates for participating in the federated learning process. Therefore, in step 2-3, each client computing node 150a-n considers the information provided by the request message and determines whether to participate in the federated learning process based on the availability and capabilities of the client computing node.

[0031] In steps 2-4, each client computing node 150a-n transmits a response message. In some implementations, the response message indicates whether or not to participate in the federated learning process. More generally, the response message may include any useful information that enables the first computing node 140 to determine which client computing nodes 150a-n are suitable candidates for participating in the federated learning process. The response messages may be implemented using separate response messages as shown, or in other ways, such as a single concatenated response message. In steps 2-5, the first computing node 140 receives the response message.

[0032] The request message sent in step 2-1 and received in step 2-2 has a message type or flag indicating the ML preparation phase. For example, the request message may have a message type of "prepare" or a federated learning execution flag of "false." As another example, the request message may have an ML preparation flag that identifies whether the request is preparing for federated learning or executing federated learning, and such flag may be set to identify preparation for federated learning (i.e., the ML preparation phase). According to one embodiment of the present disclosure, the request message also includes information indicating available data requirements and / or available time requirements. This information may be useful for the client computing nodes 150a-n to decide whether to participate in the federated learning process. This information may also be useful for the client computing nodes 150a-n to execute the federated learning process.

[0033] "Available data requirements" refer to requirements regarding available local data at a client computing node for training a local ML model for an FL process. In some implementations, the available data requirements include a list of event IDs of the local data for training and may also include dataset statistical characteristics, a time window for data samples, and a minimum number of data samples. The available data requirements may be used by a client computing node to determine whether its available data meets the requirements of the FL process. "Availability time requirements" refer to requirements regarding the availability time of a client computing node to participate in an FL process. The availability time requirements may be used by a client computing node to determine its availability for FL processing.

[0034] In some embodiments, information from the request message indicates both available data requirements and available time requirements. This combination of information may be particularly useful for determining whether client computing nodes 150a-n should participate in the federated learning process. In particular, this combination of information may be more useful than either the available data requirement or the available time requirement alone, because when considering the combination of available data requirement and available time requirement, it may be possible to select the most appropriate candidate to participate in the federated learning process.

[0035] In some embodiments, the request message also includes interoperability information, such that information indicating available data requirements and / or available time requirements is additional information that supplements the interoperability information. The interoperability information provided by the request message can be used to compare with interoperability information stored locally at the client computing node. The interoperability information primarily relates to FL operations; for example, an initial model provided by a first computing node may be trained at the client computing node, or operations required for training an ML model may be performed at both the server computing node and the client computing node. This differs from the information indicating available data requirements and / or available time requirements, which relate to the data and time requirements for the client node to train an ML model.

[0036] The combination of information provided to the client computing nodes 150a-n (i.e., the interoperability information and additional information supplementing the interoperability information) may be useful for the client computing nodes 150a-n to determine whether to participate in the federated learning process. This combination of information may also be useful for the client computing nodes 150a-n to perform the federated learning process. Other parameters related to the FL provided by the request message may also be used to determine whether the capabilities of the client computing nodes, e.g., computation and communication, meet the requirements for performing FL processing.

[0037] In some particular embodiments, the request message includes some or more of: an analytics ID (analysis ID), ML model interoperability information, an ML model ID identifying the provided ML model, ML model information, an ML model file, ML training information such as data availability requirements and time availability requirements, training report information, an ML readiness flag, an ML model accuracy check flag, an ML correlation ID, a termination request (optionally indicating a reason for terminating the federated learning identified by the ML correlation ID, for example, if the FL client NWDAF is not selected by the FL server NWDAF for the FL process or if the FL process is interrupted), training filter information, a target value for the training report, and a use case context.

[0038] In some embodiments, the response message received in step 2-5 includes a response message from each client computing node 150a-n indicating whether the client computing node 150a-n can participate in the federated learning process based on the interoperability information and the additional information. Thus, each client computing node 150a-n sends a response regardless of whether it can participate in the federated learning process. In other embodiments, the response message received in step 2-5 includes a response message from only each client computing node 150a-n that can participate in the federated learning process based on the interoperability information and the additional information. For example, the first computing node 140 can interpret the absence of a response from a client computing node to mean that the client computing node cannot participate in the federated learning process. Other implementations are possible.

[0039] In some particular embodiments, the response message includes an operation execution result when the request is accepted, or an error response with a cause code when the request is not accepted (e.g., when the NWDAF does not meet the ML training requirements, when ML training is not complete, when ML training is not complete, when the NWDAF is overloaded, when it is not available for FL processing, etc.), an ML model ID, an analytics ID, ML model information, an ML correlation ID in case of federated learning, a corresponding use case context, a global ML model accuracy (the model accuracy of the global ML model calculated by the FL client NWDAF using the local training data as a test dataset), a status report of FL training: local ML model metrics, and training input data information generated by the FL client NWDAF during the FL procedure (e.g., the area covered by the dataset, the sampling rate, the maximum / minimum values ​​of each dimension of the data, etc.), a delay event notification, and global ML model metrics.

[0040] In steps 2-6, the first computing node 140 selects which client computing nodes 150a-n will participate in the federated learning process based on the response message. In some embodiments, the first computing node 140 selects all of the client computing nodes 150a-n that indicated they can participate in the federated learning process. In other embodiments, the first computing node 140 selects a subset of the client computing nodes 150a-n that indicated they can participate in the federated learning process. The first computing node 140 may select the subset of client computing nodes 150a-n, for example, if more client computing nodes 150a-n indicate they can participate in the federated learning process than needed or desired. The first computing node 140 may also select the subset of client computing nodes 150a-n for other reasons that may depend, for example, on the response message.

[0041] In the illustrated example, assume that the first two client computing nodes 150a-b are selected by the first computing node 140 to participate in the federated learning process. In steps 2-7, the first computing node 140 notifies the selected computing nodes 150a-b to perform the federated learning process. For example, an instruction message may be sent to the selected computing nodes 150a-b. This can be implemented in a multicast manner as shown, or in other manners, such as daisy chaining. In some embodiments, the instruction message is sent only to the selected computing nodes 150a-b, as shown. In other embodiments, the instruction message is sent to all of the client computing nodes 150a-n, regardless of whether they were selected, so that the instruction message indicates which of the client computing nodes 150a-n were selected (e.g., the identity of the first two client computing nodes 150a-b), and each client computing node 150a-n can therefore determine from such indication whether they were selected. Other implementations are possible.

[0042] Finally, in steps 2-8, the first computing node 140 and the selected computing nodes 150a-b execute a federated learning process. Note that other client computing nodes 150n not selected by the first computing node 140 are not involved in the federated learning process. In some implementations, the selected computing nodes 150a-b use additional information (i.e., available data requirements and / or available time requirements) from the request message during the federated learning process. For example, according to the available data requirements, the client computing nodes use the required local data to train a local ML model for FL processing.

[0043] In some embodiments, the first computing node 140 is a server NWDAF (Network Data Analytics Function), and each client computing node 150a-b is a client NWDAF. Other implementations are possible. The details of the computing nodes 140 and 150a-b may depend on the network 130 and may be application specific.

[0044] In some implementations, the first computing node 140 notifies the selected computing nodes 150a-b in step 2-7 using the same service used to send the request message in step 2-1. In this way, the service used to send the request message in step 2-1 can be extended or reused to notify the selected computing nodes 150a-b in step 2-7 to begin running the FL training in step 2-8. Extending or reusing a service can provide various advantages in terms of efficiency, avoiding having different services send prepare messages and notify clients to begin running the FL training. In other implementations, separate services are utilized for steps 2-1 and 2-7.

[0045] Note that the parameters provided in the prepare message in step 2-7 are usually different from the request message in step 2-1. For example, in step 2-7, the parameters in the prepare message may include initial ML model information, a message type (="run"), or an FL run flag (="true"), indicating that this message is to notify the client NWDAF to start running FL training, an FL correlation ID, and guideline information (e.g., the maximum response time for an FL client to provide intermediate local ML model information).

[0046] There are many possibilities for the same service described above: In some embodiments, the same service is a Nnwdaf_MLPreparation_Request service, such that sending a request message involves invoking a Nnwdaf_MLPreparation_Request service operation with a message type or flag indicating the ML preparation phase, and notifying selected computing nodes to perform a federated learning process involves invoking a Nnwdaf_MLPreparation_Request service operation with a message type or flag indicating the ML execution phase.

[0047] In another embodiment, the same service is a Nnwdaf_MLModelTraining_Subscribe service, such that sending the request message includes invoking a Nnwdaf_MLModelTraining_Subscribe service operation with a message type or flag indicating the ML preparation phase, and notifying the computing nodes selected to perform the federated learning process includes invoking a Nnwdaf_MLModelTraining_Subscribe service operation with a message type or flag indicating the ML execution phase.

[0048] In another embodiment, the same service is a Nnwdaf_MLModelTrainingInfo_Request service, such that sending the request message includes invoking a Nnwdaf_MLModelTrainingInfo_Request service operation with a message type or flag indicating the ML preparation phase, and notifying the selected computing nodes to perform the federated learning process includes invoking a Nnwdaf_MLModelTrainingInfo_Request service operation with a message type or flag indicating the ML execution phase.

[0049] Other possibilities not specifically mentioned herein may be possible for the same service. In general, any suitable service with an appropriate message type or flag can be used. There are many possibilities for such message types and flags. Details of specific examples of invoking service operations using various flags are provided in subsequent sections. Many of these examples focus on a specific service, namely, the Nnwdaf_MLPreparation_Request service. However, as noted above, other services (e.g., the Nnwdaf_MLModelTraining_Subscribe and Nnwdaf_MLModelTrainingInfo_Request services) are possible and within the scope of this disclosure.

[0050] According to another embodiment of the present disclosure, a non-transitory computer-readable medium having recorded thereon statements and instructions that, when executed by processor 146 of first computing node 140, implement the methods described herein. The non-transitory computer-readable medium may be computer-readable medium 148 of first computing node 140 shown in FIG. 1 or some other non-transitory computer-readable medium.

[0051] According to another embodiment of the present disclosure, a non-transitory computer-readable medium having recorded thereon statements and instructions that, when executed by processor 156 of client computing node 150a, perform the methods described herein. The non-transitory computer-readable medium may be computer-readable medium 158 of client computing node 150a shown in FIG. 1 or some other non-transitory computer-readable medium.

[0052] Examples of non-transitory computer readable media include SSDs (solid state drives), hard disk drives, CDs (compact discs), DVDs (digital video drives), BDs (Blu-ray discs), memory sticks, etc. Other non-transitory computer readable media are possible.

[0053] The illustrated examples described herein focus on software implementations. However, other implementations are possible and within the scope of this disclosure. Note that other implementations may include additional or alternative hardware components, such as, for example, any appropriately configured FPGA (field programmable gate array), ASIC (application-specific integrated circuit), and / or microcontroller. Accordingly, the federated learning circuit 144 of the first computing node 140 and the federated learning circuit 154 of the client computing nodes 150a-n may instead be implemented using any suitable combination of hardware, software, and / or firmware.

[0054] Further exemplary details are provided in the following sections: It should be understood that the following sections are very specific and are provided for illustrative purposes only, as other implementations are possible and within the scope of this disclosure.

[0055] System and signaling example overview 3A-3D are block diagrams of a system with signals shown for the preparation request, the preparation message in the ML preparation phase, the preparation message in the ML execution phase, and the extended Nnwdaf_MLPreparation service, respectively. A brief description of these block diagrams follows.

[0056] As shown in Figure 3A, the server NWDAF sends a prepare request to the clients NWDAF1...X to select a client NWDAF. The parameters / information in the prepare request include message type (="prepare") or FL execution flag (="false"), interoperability information, available data requirements, available time requirements, etc.

[0057] The client NWDAF that decides to participate in the ML process sends a response to the server NWDAF, as shown in Figure 3B. The server NWDAF then selects a client NWDAF to respond to the preparation request.

[0058] Once the client NWDAF selection is complete, the server NWDAF notifies the selected client NWDAF to perform ML training, as shown in Figure 3C. The parameters / information in the prepare message include initial ML model information, a message type (="execute") or an ML (e.g., federated learning) execution flag, an ML (e.g., FL) correlation ID, guideline information (e.g., maximum response time of the client NWDAF for providing intermediate local ML model information), etc.

[0059] Figure 3D is a block diagram of a system with signals shown for the extended Nnwdaf_MLPreparation service. In the ML preparation phase, the service Nnwdaf_Preparation is extended by adding a new parameter to the preparation request for client NWDAF(s) selection. The server NWDAF sends a preparation request to the client NWDAF by invoking the Nnwdaf_Preparation_Request service operation. In the preparation request, parameters / information include the message type (="prepared") or FL execution flag (="false"), interoperability information, available data requirements, available time requirements, etc. A client NWDAF that decides to participate in the ML (e.g., FL) process responds to the server NWDAF by invoking the Nnwdaf_Preparation_Request response service operation indicating that it will participate in the ML (e.g., FL) procedure. The server then performs the selection from the client NWDAF(s).

[0060] At the very beginning of the ML execution phase, the server notifies the selected client NWDAF to perform an ML (e.g., FL) operation by invoking the Nnwdaf_MLPreparation_Request service operation. In the preparation message, parameters / information include initial ML model information, message type (="execute") or ML (e.g., federated learning) execution flag, ML (e.g., FL) correlation ID, guideline information (e.g., maximum response time of client NWDAF for providing intermediate local ML model information), etc.

[0061] Federated learning among multiple NWDAFs Several solutions to support federated learning among multiple NWDAFs in the 5G Core Network (5GC) were concluded in Section 8.8 of the 3rd Generation Partnership Project, TR 23.700-81, "Study of Enablers for Network Automation for 5G," Release 18, Version 2.0.0 (2022-11), hereafter referred to as "TR 23.700-81." Some descriptions and procedures for federated learning among multiple NWDAFs were added to Section 6.2C of the 3rd Generation Partnership Project, TS 23.288 Architecture Extensions for 5G Systems (5GS), to support Network Data Analysis Services, Release 18, Version 18.0.0 (2022-12), hereafter referred to as "TS 23.288."

[0062] NWDAFs that include an MTLF (Model Training logical function) may eliminate the need for input data transfer (e.g., centralized in one NWDAF) and instead leverage federated learning techniques to train ML models, which involves collaboration between multiple NWDAFs (MTLFs) distributed in different areas, i.e., sharing of ML models and learning results between multiple NWDAFs (MTLFs). Figure 4 is a sequence diagram of the process for federated learning training between multiple NWDAFs. The various steps are briefly described below.

[0063] In step 4-0, the consumer (NWDAF including AnLF) sends a subscription request to the NWDAF including MTLF to search for ML models including analytics IDs and ML model filter information, as described in TS 23.288. The NWDAF including MTLF can be an FL server (server NWDAF) with FL server capabilities or an MTLF without FL server capabilities. Note that there are many possibilities for the MTLF registration and discovery procedures for FLs. Also, note that there are many possibilities for the definition of FL capabilities.

[0064] In step 4-1, the server NWDAF sends a request to selected NWDAFs, including MTLFs (client NWDAFs) that will participate in the federated learning, to perform training of a local model for federated learning.

[0065] In step 4-2, each client NWDAF collects local data using the current mechanisms in clause 6.2 of TS 23.288.

[0066] In step 4-3, during the training procedure of federated learning, each client NWDAF further trains the ML model retrieved from the server NWDAF based on its own data and reports intermediate local ML model information to the server NWDAF. ML model information is exchanged between the client NWDAF and the server NWDAF during the FL training process. Note that there are many possibilities for the ML model information exchanged between the client NWDAF and the server NWDAF. Also, note that there are many possibilities for the services in steps 4-1, 4-3, 4-5a, and 4-6 to enable FL-based ML model training.

[0067] In step 4-4, the server NWDAF aggregates all the local ML model information retrieved in step 4-3 and updates the global ML model.

[0068] In step 4-5a, based on the consumer's request, the server NWDAF updates the training status (accuracy level) to the consumer periodically (e.g., after one or more training sessions or every 10 minutes) or dynamically when some predetermined status (e.g., some accuracy level) is achieved.

[0069] Optionally, in steps 4-5b, the consumer determines whether the current model can meet various requirements, such as accuracy and time. The consumer modifies the subscription if the current model can meet the various requirements. Note that the various requirements in steps 4-5b are consumer-oriented and are different from the available data requirements and available time requirements described above for the client computing node. Note that there are many possibilities for providing accuracy for the FL model process.

[0070] In step 4-5c, according to the request from the consumer, the server NWDAF updates or terminates the current FL training process.

[0071] In steps 4-6, if the FL procedure continues, the server NWDAF sends the aggregated ML model information to each client NWDAF for the next round of model training.

[0072] In step 4-7, each client NWDAF updates its own ML model based on the aggregated ML model information distributed by the server NWDAF in step 4-6.

[0073] Note that steps 4-2 to 4-7 should be repeated until the training termination condition (e.g., the maximum number of iterations or the loss function result is lower than a threshold) is met. After the training procedure is completed, the server NWDAF can send the globally optimal ML model information to the consumer.

[0074] Sustaining Associative Learning in 5GC A solution for maintaining FL processes among multiple NWDAFs in 5GC is presented in TR 23.700-81 (i.e., Solution #51). This solution is proposed to address Key Issue #8 regarding supporting federated learning in 5GC. The study items for this Key Issue are: Consider how to coordinate multiple NWDAFs, including the selection of participant NWDAF instances within a federated learning group, including, for example, the supporting information (if any) for carrying out the selection, and the determination of the roles of participant NWDAFs. Consider whether and how to monitor the performance of NWDAF federated learning operations (e.g., network performance and model performance).

[0075] To address the challenges mentioned above for supporting federated learning in the 5GC, this solution focuses on NWDAF(s) selection during the federated learning preparation phase and NWDAF(s) monitoring and maintenance during the federated learning execution phase. During the federated learning preparation phase, many factors influence the selection of a client NWDAF, such as the capabilities of the NWDAF(s), the interoperability, and availability of the client NWDAF(s) participating in federated learning.

[0076] During the federated learning execution phase, due to dynamic changes in the federated network, the current client NWDAF should consider the dynamic participation and withdrawal of client NWDAFs in the federated learning multi-round learning / training process in 5GC. In addition, a method may be applied for the server NWDAF to monitor state changes (e.g., changes in capability and availability) of client NWDAFs.

[0077] In the federated learning preparation phase, the server and (potential) client NWDAFs are discovered via the NRF (Network Repository Function) and a client NWDAF is selected by a method for a handshake pattern. The selection of the client NWDAF(s) is based on availability, capabilities, etc. Figure 5 is a sequence diagram of the process for client NWDAF(s) selection in the federated learning preparation phase. The various steps are briefly described below.

[0078] In step 5-0, the NWDAF registers with an NRF that has federated learning capabilities. The server NWDAF discovers client NWDAFs based on their federated learning capabilities, analytics IDs, etc.

[0079] In step 5-1, the server NWDAF sends a federated learning preparation request to the client NWDAF by invoking the Nnwdaf_MLPreparation_request service operation with interoperability information. The preparation request may include an indication of the role of the NWDAF(s), i.e., their operation as client NWDAF(s). Note that the interoperability information indicates what capabilities (e.g., being able to execute a particular model) are necessary or desired for the client NWDAF to support this FL procedure (e.g., if the server NWDAF and client NWDAF can share models and how to share the models). The interoperability information may be determined between different vendors.

[0080] In step 5-2, the client NWDAF decides whether to participate in the federated learning process based on its availability, capabilities, and interoperability information.

[0081] In step 5-3, the client NWDAF sends a response to the server NWDAF indicating whether it wishes to participate in the FL procedure.

[0082] In step 5-4, the server NWDAF can send a test task to the client NWDAF that wishes to participate in the FL procedure. The client NWDAF executes the test task and sends the results to the server NWDAF. Note that the test task can be a micro-computation or training task, and the requirements for completing the micro-task are the same as or similar to the main task. The test task can be a small task that allows the client NWDAF to collect local data and send local model weights back to the server, or some kind of test to ensure that the server and client NWDAF can communicate if they use the same FL framework or library. There are many ways to obtain and execute a test task.

[0083] In step 5-5, the server NWDAF selects a client NWDAF, and the results of the test task may be taken into account by the server NWDAF for the selection of the client NWDAF.

[0084] During the federated learning execution phase, the server NWDAF monitors the status changes of the client NWDAFs. The client NWDAFs can be reselected based on the updated status, availability, and / or capabilities of the client NWDAFs for FL tasks. Figure 6 is a sequence diagram of the process for NWDAF monitoring and reselection during the federated learning execution phase. The various steps are briefly described below.

[0085] In step 6-1, the server NWDAF monitors the status of the client NWDAF during the federated learning execution process and receives the updated status of the client NWDAF. The server NWDAF performs the monitoring and can obtain the updated status of the client NWDAF directly and / or via the NRF. Note that the status of the client NWDAF may be due to changes in NF load, NF availability, or its capabilities, such as no longer supporting FL.

[0086] In step 6-2, the server NWDAF checks the client NWDAF status based on the received information and determines whether reselection of the client NWDAF for the next round of federated learning is warranted. The decision is based on the updated status of the client NWDAF(s), including availability, capabilities, etc.

[0087] In step 6-3, if step 6-2 determines that reselection is justified, the server NWDAF reselects a client NWDAF as in steps 5-1 to 5-5 in Figure 5. The discovery procedure for a new client NWDAF during the federated learning execution phase is described in section 2.1.2.2.3 of TS 23.288.

[0088] In step 6-4, if the client NWDAF receives a termination request from the server NWDAF, it terminates the operation for federated learning.

[0089] There are two possible cases for the server NWDAF to obtain information about new client NWDAFs: directly from the new client NWDAFs or via the NRF. The two possible cases include (1) the new client NWDAF(s) notifying the server NWDAF directly, and (2) the server NWDAF obtaining information about the new client NWDAF(s) via the NRF. These two possible cases are described below.

[0090] Figure 7 is a sequence diagram of the process of dynamically discovering new NWDAFs in the federated learning execution phase when information about the server NWDAF is known at the new client NWDAF. Client NWDAFs 1 to N are selected by the server NWDAF to participate in the current round of federated learning. New client NWDAFs N+1 to N+X have the ability to participate in the training process in the next round. New client NWDAF(s) that are available and / or have the ability to participate in the federated learning process learn about the server NWDAF and notify the server NWDAF directly. The various steps are briefly described below.

[0091] In step 7-0, the server NWDAF registers with the NRF for the federated learning procedure using the following parameters: a federated learning (FL) correlation ID, and an analysis ID. Note that the FL correlation ID is used to identify a specific FL procedure. For example, a server NWDAF or a client NWDAF may participate in different FL procedures simultaneously, and then, when they receive a message or data from another NWDAF, they need to know which FL procedure the message or data is for.

[0092] When the server NWDAF initiates an FL procedure, it registers the FL procedure with the NRF along with an FL correlation ID and an analysis ID. Later, when a client NWDAF wants to dynamically participate in an FL, for example, when it wants to update its local model using global information, it queries the NRF if there is an ongoing FL for the analysis ID. The NRF then provides the server NWDAF ID and the FL correlation ID to the client NWDAF, which can then contact the server NWDAF to participate in the FL procedure. Using the FL correlation ID, the server NWDAF knows which FL procedure the client NWDAF wants to participate in and which model to provide to the client.

[0093] In step 7-1, if information about the server NWDAF and the corresponding FL procedures is known via the NRF, the new client NWDAF notifies the client NWDAF of their interoperability and availability to the server NWDAF by invoking the Nnwdaf_MLPreparation_Request service operation.

[0094] In step 7-2, before starting the next training round, the server NWDAF selects client NWDAFs from NWDAF1 to N+X based on the updated information of the client NWDAFs. The procedure is the same as steps 4-1 to 4-5 in Figure 4.

[0095] Figure 8 is a sequence diagram of the process of dynamically discovering a new NWDAF during the federated learning execution phase when the new client NWDAF does not have information about the server NWDAF. Client NWDAFs 1 to N are selected by the server NWDAF to participate in the current round of federated learning. New client NWDAFs N+1 to N+X have the ability to participate in the training process in the next round. In step 8-0, the server NWDAF registers with the NRF for the federated learning procedure as described above in Figure 7. In step 8-1, when the server NWDAF wants to reselect a client NWDAF in step 8-2, it dynamically obtains information about the new client NWDAF via the NRF by subscribing to events that the new client NWDAF registers for or by discovering the NRF.

[0096] The ML (e.g., Distributed Machine Learning / FL) process can be divided into two phases: an ML preparation phase and an ML execution phase. Some implementations described herein provide details on how parameters can be sent from a server NWDAF to a client NWDAF for client NWDAF selection in the ML preparation phase. Additionally, which services can be used to notify the client NWDAF to perform ML training in the ML execution phase. Thus, some embodiments described herein provide details on how parameters can be sent from a server NWDAF to a client NWDAF for client NWDAF selection and / or which services can be used to notify the client NWDAF to perform ML training.

[0097] Some implementations described herein extend the Nnwdaf_MLPreparation service given in Solution #51 of TR 23.700-81. The extensions may include: Add a new parameter to the preparation request sent from the server NWDAF to the client NWDAF to select the client NWDAF during the ML Preparation Phase. Reuse Nnwdaf_MLPreparation with extended parameters to notify the client NWDAF to perform ML training in the ML Execution Phase. The procedure using the extended service for the transmission preparation request in the ML preparation phase and the preparation message in the ML execution phase are shown.

[0098] In some implementations, the Nnwdaf_MLPreparation service provided in Solution #51 of TR 23.700-81 is extended by adding new parameters to the preparation request in the ML preparation phase and reused and extended in the ML execution phase. The preparation request is sent from the server NWDAF to the client NWDAF, and the client NWDAF is selected in the ML preparation phase. In the ML execution phase, the extended Nnwdaf_MLPreparation service is used by the server NWDAF to notify the client NWDAF to perform ML training.

[0099] In some implementations, the ML preparation phase and the ML execution phase are improved by extending and reusing the Nnwdaf_MLPreparation service, which is used to send a preparation request in the ML preparation phase for client NWDAF selection and to notify the client NWDAF to perform ML training in the ML execution phase.

[0100] Provisioning parameters and / or services for sending and receiving information As an example, a federated learning process is employed to show how the extended Nnwdaf_MLPreparation service is used for preparation requests and messages sent from the server NWDAF to the client NWDAF(s) in the FL preparation phase and the FL execution phase, respectively.

[0101] Figure 9 is a sequence diagram of the process for extending a service in the FL preparation and FL execution phases. The different steps are briefly described below.

[0102] In step 9-0, the server NWDAF discovers the client NWDAFs via the NRF, which provides the server NWDAF with a list of client NWDAFs based on FL capabilities, analytics IDs, interoperability indicators, time intervals for which FL is supported, etc.

[0103] In step 9-1, the server NWDAF sends a federated learning preparation request to the client NWDAF by invoking the Nnwdaf_MLPreparation_request service operation with the interoperability information. In the preparation request, the following parameters can be added to indicate that this request is for preparation: available data requirements, available time requirements, message type (="preparation"), or FL execution flag (="false").

[0104] In step 9-2, the client NWDAF decides whether to participate in the federated learning process based on its availability, computing and communication capabilities, and interoperability information.

[0105] In step 9-3, the client NWDAF sends a response to the server NWDAF by calling the Nnwdaf_MLPreparation_Request response service operation with an indication on the participating FL process to indicate that it will participate in the FL process.

[0106] In step 9-4, the server NWDAF selects the client NWDAF(s).

[0107] In step 9-5, the server NWDAF notifies the selected NWDAF (client NWDAF), including the MTLF (client NWDAF), to perform federated learning by invoking the Nnwdaf_MLPreparation_Request service operation with initial ML model information, a message type (="execute"), or an FL execution flag (="true"), indicating that this message is to notify the client NWDAF to start performing FL training. The server NWDAF also includes an FL correlation ID, guideline information (e.g., a maximum response time for an FL client to provide provisional local ML model information) in the preparation message.

[0108] To indicate the purpose of the Nnwdaf_MLPreparation_Request, for example, to send a preparation request in the FL preparation phase or to notify a preparation message in the FL execution phase, either the message type or the FL execution flag can be used in steps 9-1 and 9-5.

[0109] If the FL execution flag is used in steps 9-1 and 9-5, the FL execution flag can be either an optional parameter or a required parameter. If the FL execution flag is an optional parameter, it is included only in the prepare message sent from the server NWDAF to the client NWDAF in the FL execution phase. If the FL execution flag is a required parameter, it is set to FL execution flag="false" in the prepare request in the FL preparation phase and set to FL execution flag="true" in the prepare message in the FL execution phase. More generally, a message type or flag indicating the ML preparation phase or the ML execution phase can be utilized.

[0110] In step 9-6, the server NWDAF and the client NWDAF begin performing FL training operations for FL processing.

[0111] (Another associative learning process) 10A and 10B are a sequence diagram of another method for performing a federated learning process in a network. The various steps are briefly described below.

[0112] In step 10-0a, the NWDAF registers with the NRF. In step 10-0b, the consumer (NWDAF including the AnLF) sends a subscription request to the NWDAF including the MTLF to search for ML models including the analytics ID and ML model filter information, as described in Section 7.5.2 of TS 23.288. The NWDAF including the MTLF may be an FL server with FL server capabilities (server NWDAF) or an MTLF without FL server capabilities. In step 10-0c, the server NWDAF discovers client NWDAFs via the NRF. The NRF provides the server NWDAF with a list of client NWDAFs based on FL capabilities, analytics IDs, interoperability indicators, time intervals for which FL is supported, etc. Note that there are many possibilities for defining FL capabilities.

[0113] In step 10-1, the server NWDAF sends a federated learning preparation request to the client NWDAF(s) by invoking the Nnwdaf_MLPreparation_Request service operation with the interoperability information. In the preparation request, the following parameters can be added: requirements for available data, and requirements for available time.

[0114] In step 10-2, the client NWDAF decides whether to participate in the federated learning process based on its availability, computing and communication capabilities, and interoperability information.

[0115] In some embodiments, the server NWDAF can use the request to check whether the NWDAF can fulfill the ML model training requirements (e.g., ML model interoperability information, analytics ID, serving area, and / or data and time availability). In such a case, the FL server NWDAF includes an ML ready flag. In some embodiments, when the ML ready flag is presented in the request, the service provider NWDAF only checks whether it can fulfill the ML model training requirements (e.g., ML model interoperability information, analytics ID, serving area, and / or data and time availability) and / or whether it can correctly download the model if the model information is provided.

[0116] In step 10-3, the client NWDAF sends a response to the server NWDAF indicating whether it will participate in the FL procedure, which may be based on whether it can meet the ML model training requirements.

[0117] In step 10-4, the server NWDAF makes a selection of a client NWDAF, such selection being based on the response received in step 10-3.

[0118] In step 10-5, the server NWDAF notifies the selected NWDAFs, including the MTLF (client NWDAF), to perform federated learning by invoking the Nnwdaf_MLPreparation_Request service operation with the initial ML model information and the FL execution flag. The server NWDAF includes the FL correlation ID and guideline information (e.g., maximum response time for an FL client to provide provisional local ML model information) in the preparation message. The server NWDAF and client NWDAF subscribe to each other to exchange ML model information as described in Section 6.2C.2.2 of TS 23.288.

[0119] In step 10-6, each client NWDAF collects its local data by using the current mechanisms in section 6.2 of TS 23.288.

[0120] In step 10-7, during the training procedure of federated learning, each client NWDAF further trains the ML model retrieved from the server NWDAF based on its own data and reports intermediate local ML model information to the server NWDAF as defined in section 6.2C.2.2 of TS 23.288. ML model information is exchanged between the client NWDAF and the server NWDAF during the FL training process.

[0121] In step 10-8, the server NWDAF aggregates all the local ML model information retrieved in step 10-7 to update the global ML model.

[0122] In step 10-9a, based on the consumer's request, the server NWDAF provides the training status (i.e., accuracy level / information) to the consumer by calling the Nnwdaf_MLModelProvision_Notify service operation periodically (e.g., after one or more rounds of training or every 10 minutes), or dynamically when some predetermined status (e.g., a certain accuracy level) is achieved.

[0123] Optionally, in step 10-9b, the consumer determines whether the current model can meet various requirements, such as accuracy and time. If the current model can meet the various requirements, the consumer modifies the ML model subscription. Note that the various requirements in step 10-9b are for the consumer and are different from the available data requirements and available time requirements described above for the client computing node. Note that there are many possibilities for providing accuracy for the FL model process.

[0124] In step 10-9c, according to the request from the consumer, the server NWDAF updates or terminates the current FL training process.

[0125] In step 10-10, if the FL procedure continues, the server NWDAF sends the aggregated ML model information or ML model container to each client NWDAF for the next round of model training as defined in section 6.2C.2.2 of TS 23.288.

[0126] In steps 10-11, each client NWDAF updates its own ML model based on the aggregated ML model information distributed by the server NWDAF in step 10.

[0127] Note that steps 10-7 to 10-11 should be repeated until a training termination condition is reached (e.g., the maximum number of iterations, or the loss function result is lower than a threshold). After the training procedure is completed, the server NWDAF can send the globally optimal ML model information to the consumer.

[0128] Model information transmission and reception The Nnwdaf_MLModelProvision service is used to share models / parameters between multiple NWDAFs during the execution phase of the ML training process.

[0129] The server NWDAF subscribes to the client NWDAF to obtain local model information by invoking the Nnwdaf_MLModelProvision_Subscribe service operation, and the client NWDAF subscribes to the server NWDAF to obtain global model information by invoking the Nnwdaf_MLModelProvision_Subscribe service operation as in 6.2A.1, with the following differences:

[0130] The server NWDAF and client NWDAF include the following parameters in the Nnwdaf_MLModelProvision_Subscribe request: · The identity of the current ML process, i.e., the FL correlation ID.

[0131] The server NWDAF and client NWDAF include the following parameters in the Nnwdaf_MLModelProvision_Notify message: · The identity of the current ML process, i.e., the FL correlation ID. · The identity of the current iteration round, i.e., IR ID (e.g., IR ID=1, 2, 3, ...). Note whether the server NWDAF and the client NWDAF share models or model parameters, depending on the initial information in step 5 of TS 23.288, section 6.2C.2.1.

[0132] Subscribing / Unsubscribing to ML Models Figure 11 is a sequence diagram of a method for subscribing to and unsubscribing from an ML model for analysis. The procedure in Figure 11 is used by an NWDAF service consumer, i.e., an AnLF or an NWDAF including an MTLF, to subscribe / unsubscribe to another NWDAF, i.e., an NWDAF including an MTLF, to be notified when ML model information for related analytics becomes available, or by an NWDAF service consumer for model sharing / parameter exchange during the execution phase of a federated learning training process among multiple NWDAFs using the Nnwdaf_MLModelProvision service defined in Section 7.5 of TS 23.288. ML model information is used by an NWDAF including an AnLF to derive analytics or by an NWDAF including an MTLF to update models (global or local). This service is also used by an NWDAF to modify existing ML model subscriptions. An NWDAF can simultaneously be both a consumer of this service provided by other NWDAFs and a provider of this service to other NWDAFs. The various steps are briefly described below.

[0133] In step 11-1, an NWDAF service consumer (i.e., an NWDAF including an AnLF or MTLF) subscribes to, modifies, or cancels a subscription to a (set of) trained ML models associated with a (set of) analysis IDs by calling the Nnwdaf_MLModelProvision_Subscribe / Nnwdaf_MLModelProvision_Unsubscribe service operation. The parameters that an NWDAF service consumer can provide are listed in clause 6.2A.2 of TS 23.288. The service consumer optionally indicates support for multiple ML models if they are available.

[0134] When a subscription is received for a trained ML model associated with an analysis ID, the NWDAF containing the MTLF: Determine whether an existing trained ML model is available for your subscription Determine whether triggering further training for existing trained ML models is required or desired for the subscription.

[0135] If the NWDAF including the MTLF determines that further training is warranted, the NWDAF may initiate data collection from the NF (e.g., AMF / DCCF / ADRF), UE application (via the AF), or OAM, as described in Section 6.2 of TS 23.288, to generate an ML model.

[0136] If the service call is for subscription modification or subscription cancellation, the NWDAF service consumer includes the identifier (subscription correlation ID) to be modified in the call to Nnwdaf_MLModelProvision_Subscribe.

[0137] If the service call is for model sharing / parameter exchange during the execution phase of a federated learning training process between multiple NWDAFs, the NWDAF service consumer includes the identity of the current ML process (FL correlation ID) in the call to Nnwdaf_MLModelProvision_Subscribe.

[0138] In step 11-2, when an NWDAF service consumer subscribes to a (set of) trained ML models associated with a (set of) analysis IDs, the NWDAF including the MTLF notifies the NWDAF service consumer of: If multiple ML models are not supported by the consumer, the trained ML model information (including the (set of) file addresses of the trained ML models) If multiple ML models are supported by the consumer, a set of unique ML model identifier and ML model information pairs associated with the analysis ID. Please note that the structure and format of the ML model identifier and its uniqueness are up to stage 3. Also, please note that the parameters defined for multiple models are for improving the accuracy of the analysis.

[0139] By calling the Nnwdaf_MLModelProvision_Notify service operation. The content of the trained ML model information that can be provided by the NWDAF, including the MTLF, is specified in TS 23.288, clause 6.2A.2.

[0140] The NWDAF including the MTLF also invokes the Nnwdaf_MLModelProvision_Notify service operation to notify of an available retrained ML model when the NWDAF including the MTLF determines that the previously provisioned trained ML model in step 11-1 should be retrained.

[0141] When step 11-1 is for a subscription modification (i.e., including a subscription correlation ID), the NWDAF including the MTLF can provide a new trained ML model that is different from the one previously provided, or can provide a retrained ML model by calling the Nnwdaf_MLModelProvision_Notify service operation.

[0142] If step 11-1 is for model sharing / parameter exchange in the execution phase of the federated learning training process among multiple NWDAFs, the FL correlation ID and identity (IR ID (e.g., IR ID=1, 2, ···)) of the current iteration round should be included in the Nnwdaf_MLModelProvision_Notify message.

[0143] What is ML model provisioning? A consumer of the ML model provisioning service (i.e., an NWDAF including AnLF or MTLF) described in TS 23.288, clauses 7.5 and 7.6, can provide input parameters as listed below: Analytics information in which the requested ML model will be used, including: - List of Analytics IDs: Identifies the analytics in which the ML model will be used. - [Optional] Use case context: Indicates the context of the analytics usage for selecting the most relevant ML model. For NWDAFs including MTLF, if multiple ML models are available for the requested analysis ID, the parameter "Use case context" can be used to select the most relevant ML model. The value of this parameter is not standardized. - [Optional] ML Model Interoperability Information. This is vendor-specific information that conveys, for example, the required model file format, model execution environment, etc. The encoding, format, and values ​​of the ML Model Interoperability Information are not specified, as it is vendor-specific information, and may be agreed upon between vendors as needed for sharing purposes. - [Optional] ML Model Filter Information: Select the ML model (S-NSSAI, Region of Interest, etc.) required for analysis. The parameter type of the ML Model Filter Information is the same as the parameter type of the Analysis Filter Information defined in the procedure. [Optional] Target of ML Model Reporting: Indicates the object(s) for which the ML model is requested, e.g., a specific UE, a group of UEs, or any UE (i.e., all UEs). - ML Model Reporting Information with the following parameters: - (For Nnwdaf_MLModelProvision_Subscribe only) The ML model reporting information parameters according to the event reporting information parameters defined in Table 4.15.1-1 of the 3rd Generation Partnership Project, TS 23.502 Procedures for 5G Systems (5GS), Release 18, Version 18.0.0 (2022-12), hereinafter "TS 23.502". - [Optional] ML Model Target Period: Indicates the time interval [start, end] for which the analytics ML model is required. The time interval is expressed as actual start time and actual end time (e.g., via UTC time). - The Notification Target Address (+ Notification Correlation ID) defined in TS 23.502 clause 4.15.1 allows to correlate notifications received from the NWDAF, including the MTLF, with this subscription. - (Only for model sharing / parameter sending / receiving during the execution phase of a federated learning training process among multiple NWDAFs) Identifier of the current ML process, i.e., FL correlation ID. - [Optional] Indicates support for multiple ML models. - [Optional] The accuracy level of interest. It should be noted that there are many possibilities as to whether and if additional parameters are utilized for multiple model provisioning.

[0144] The NWDAF, including the MTLF, provides the following output information to the consumer of the ML model provisioning service operation, as described in TS 23.288, clauses 7.5 and 7.6: (Nnwdaf_MLModelProvision_Notify only) Notification Correlation Information. ML Model Information, including: - If multiple ML models are not supported, the ML model file address (e.g. URL or FQDN) for the analysis ID - If multiple ML models are supported, a set of pairs of a unique ML model identifier and the ML model file address (e.g., URL or FQDN) for the analysis ID. Validity Period: Indicates the period for which the provided ML model information applies. [Optional] Spatial validity: Indicates the area to which the provided ML model information applies. Note that spatial validity and validity period are determined by the MTLF internal logic, which are subsets of AoI if provided in ML model filter information and ML model target period, respectively. (Only for model sharing / parameter exchange during the execution phase of a federated learning training process between multiple NWDAFs) Identifier of the current ML process, i.e., FL correlation ID. (Only for model sharing / parameter exchange during the execution phase of the federated learning training process among multiple NWDAFs) Identifier of the current iteration round (e.g., IR ID = 1, 2, ... in Nnwdaf_MLModelProvision_Notify).

[0145] Table 1: Examples of NF services provided by NWDAF TIFF2026504020000002.tif33167TIFF2026504020000003.tif212166

[0146] Table 2: Examples of analytical information provided by NWDAF TIFF2026504020000004.tif206166TIFF2026504020000005.tif176166

[0147] A detailed example of Nnwdaf_MLModelProvision_Subscribe service operation: Service behavior name: Nnwdaf_MLModelProvision_Subscribe. Description: Subscribes to NWDAF ML model provisioning with specific parameters. Input, e.g., (a series of) analysis IDs and FL correlation IDs defined in Table 7.1-2 "Notification Target Address (+ Notification Correlation ID)" (when sharing models / sending / receiving parameters in the execution phase of the federated learning training process between multiple NWDAFs). Input, optional: subscription correlation ID (in case of modifying an ML model subscription), ML model filter information to indicate the conditions under which an ML model is required for analysis, and ML model report target value to indicate the object for which the ML model is required (e.g., a specific UE, a group of UEs, or any UE (i.e., all UEs)), ML model report information (e.g., including the ML model target value period), expiration date, use case context, indication of support for multiple ML models, multiple ML model filter information to indicate the conditions under which multiple ML models are required. Output, example: When a subscription is accepted: Subscription correlation ID (used for managing this subscription), Expiry date (used if the subscription can expire based on the operator's policy). Output, options: None.

[0148] A detailed example of the Nnwdaf_MLModelProvision_Unsubscribe service operation: Service behavior name: Nnwdaf_MLModelProvision_Unsubscribe. Description: Unsubscribe from NWDAF ML model provisioning. Input, e.g., subscription correlation ID, FL correlation ID (in case of model sharing / parameter exchange during the execution phase of the federated learning training process between multiple NWDAFs). Input, optional: FL correlation ID (for model sharing / parameter exchange during the execution phase of the federated learning training process among multiple NWDAFs). Output, e.g., an indication of the result of the operation execution. Output, options: None.

[0149] A detailed example of Nnwdaf_MLModelProvision_Notify service operation: Service Action Name: Nnwdaf_MLModelProvision_Notify. Description: NWDAF notifies ML model information to consumer instances that are subscribed to a specific NWDAF service. Input, e.g., notification correlation information of the current iteration round (IR ID), FL correlation ID, and a set of identities for model sharing / parameter exchange in the execution phase of the federated learning training process among multiple NWDAFs. - If multiple ML models are not supported, a tuple of model files (analysis ID, address (e.g. URL or FQDN)) - A tuple (one or more tuples of an analysis ID, a unique ML model identifier, and the address of the model file (e.g., URL or FQDN)). Input, optional: validity period, spatial validity, FL correlation ID (for model sharing / parameter sending / receiving during the execution phase of the federated learning training process between multiple NWDAFs). Output, e.g., an indication of the result of an action being performed. Output, options: None.

[0150] Example details for the Nnwdaf_MLPreparation service: Service Description: This service allows consumers to request NWDAFs containing MTLFs to prepare or perform ML model training.

[0151] Detailed example of Nnwdaf_MLPreparation_Request service operation: Service Action Name: Nnwdaf_MLPreparation_Request Description: The consumer requests the NWDAF to prepare or perform ML model training. Input, e.g.: · If federated learning runs are not provided, interoperability information, available data requirements, and availability time requirements. Initial ML model information (one of three types: ADRF ID with ML model identifier, or address (e.g., URL or FQDN) of the model file, or ML model container if an ML model container exists), FL correlation ID, and guideline information (e.g., maximum response time for FL client to provide provisional local ML model information) are provided when the federated learning execution flag is provided. · Input, optional: FL execution flag. · Output, e.g.: None. Output, optional: Indication of participation in federated learning if FL execution flag is not provided.

[0152] Examples of communication systems Referring now to FIG. 12 , a schematic diagram of an exemplary cellular communication system 100 in which some embodiments of the present disclosure may be implemented is shown. In the embodiments described herein, the cellular communication system 100 is a 5G system (5GS) including a Next Generation RAN (NG-RAN) and a 5G Core (5GC). In this example, the RAN includes base stations 102-1 and 102-2, which in 5GS include NR base stations (gNBs) and optionally Next Generation eNBs (ng-eNBs) (e.g., LTE RAN nodes connected to 5GC) that control corresponding (macro) cells 104-1 and 104-2. The base stations 102-1 and 102-2 are generally referred to herein collectively as base stations 102 and individually as base stations 102. Similarly, the (macro) cells 104-1 and 104-2 are generally referred to herein collectively as (macro) cells 104 and individually as (macro) cells 104. The RAN may also include several low-power nodes 106-1 through 106-4 that control corresponding small cells 108-1 through 108-4. The low-power nodes 106-1 through 106-4 may be small base stations (such as pico or femto base stations) or remote radio heads (RRHs), etc. Notably, although not shown, one or more of the small cells 108-1 through 108-4 may alternatively be provided by the base station 102. The low-power nodes 106-1 through 106-4 are generally referred to herein collectively as low-power nodes 106 and individually as low-power nodes 106. Similarly, the small cells 108-1 through 108-4 are generally referred to herein collectively as small cells 108 and individually as small cells 108. The cellular communication system 100 also includes a core network 130A, referred to as 5GC in 5G systems (5GS). It should be noted that core network 130A is one example of implementing network 130 shown in Figure 1. Base stations 102 (and optionally low power nodes 106) are connected to core network 130A.

[0153] Base station 102 and low power node 106 serve wireless communication devices 112-1 through 112-5 within corresponding cells 104 and 108. Wireless communication devices 112-1 through 112-5 are generally referred to herein collectively as wireless communication devices 112 and individually as wireless communication devices 112. In the following description, wireless communication devices 112 are often UEs, although the disclosure is not limited thereto.

[0154] Referring now to Figure 13, a block diagram of a wireless communication system represented as a 5G network architecture consisting of core network functions (NFs), where interaction between any two NFs is represented by a point-to-point reference point / interface, can be seen as one particular implementation of the system 100 of Figure 12.

[0155] The 5G network architecture shown in Figure 13 includes, from the access side, either a RAN 102 or an access network (AN) and multiple UEs 112 connected to an AMF 200. Typically, the RAN 102 comprises a base station, such as an eNB or gNB, or the like. From the core network side, the 5GC NF shown in Figure 13 includes an NSSF 202, an AUSF 204, a UDM 206, an AMF 200, an SMF 208, a PCF 210, an application function (AF) 212, and an NWDAF 220. The NWDAF 220 can be used to implement the NWDAF of the server and client in the FL process.

[0156] Reference point representations of 5G network architectures are used to develop detailed call flows in normative standardization. The N1 reference point is defined to carry signaling between the UE 112 and the AMF 200. Reference points for connecting between the AN 102 and the AMF 200 and between the AN 102 and the UPF 214 are defined as N2 and N3, respectively. There is a reference point N11 between the AMF 200 and the SMF 208, which means that the SMF 208 is at least partially controlled by the AMF 200. N4 is used by the SMF 208 and the UPF 214, so that the UPF 214 can be configured using control signals generated by the SMF 208 and the UPF 214 can report its status to the SMF 208. N9 is a reference point for connections between different UPFs 214, and N14 is a reference point for connecting between different AMFs 200. N15 and N7 are defined because the PCF 210 applies policies to the AMF 200 and the SMF 208, respectively. N12 is used by the AMF 200 to authenticate the UE 112. N8 and N10 are defined because subscription data of the UE 112 is used for the AMF 200 and the SMF 208.

[0157] The 5GC network aims to separate the UP and CP. The UP carries user traffic, while the CP carries signaling in the network. In Figure 13, the UPF 214 is located in the UP, and all other NFs, namely the AMF 200, SMF 208, PCF 210, AF 212, NSSF 202, AUSF 204, and UDM 206, are located in the CP. Separating the UP and CP ensures that each plane resource is scaled independently. It is also possible to deploy the UPF separately from the CP functions. In this architecture, the UPF can be deployed very close to the UE to reduce the round-trip time (RTT) between the UE and the data network for some applications requiring low latency.

[0158] The core 5G network architecture consists of modularized functions. For example, the AMF200 and SMF208 are independent functions in the CP. The separated AMF200 and SMF208 enable independent evolution and scaling. As shown in Figure 13, other CP functions such as the PCF210 and AUSF204 can be separated. The modularized function design allows the 5G network to flexibly support various services.

[0159] Each NF interacts directly with another NF. It is possible to route messages from one NF to another using intermediate functions. In a CP, a set of interactions between two NFs is defined as a service, which can be reused. This service allows for modularity support. A UP supports interactions such as forwarding operations between different UPFs.

[0160] Referring now to FIG. 14, a block diagram of a 5G network architecture is shown that uses a service-based interface between NFs within a CP instead of the point-to-point reference point / interface used in the 5G network architecture of FIG. 13. However, the NFs described above with reference to FIG. 14 correspond to the NFs shown in FIG. 13. Services, etc., that an NF provides to other authorized NFs can be exposed to authorized NFs via the service-based interface. In FIG. 14, the service-based interface is indicated by the letter "N" followed by the name of the NF, e.g., Namf for the service-based interface of the AMF 200, Nsmf for the service-based interface of the SMF 208, etc. The NEF 300 and NRF 302 in FIG. 14 are not shown in FIG. 13, as discussed above. However, it should be clear that, although not explicitly shown in FIG. 13, all NFs shown in FIG. 13 can interact with the NEF 300 and NRF 302 in FIG. 14 as needed.

[0161] Some characteristics of the NFs shown in Figures 13 and 14 can be explained in the following way: The AMF 200 provides UE-based authentication, authorization, mobility management, etc. The UE 112 is essentially connected to a single AMF 200, even if multiple access technologies are used, because the AMF 200 is independent of the radio access technology. The SMF 208 is responsible for session management and assigns an Internet Protocol (IP) address to the UE. It also selects and controls the UPF 214 for data forwarding. If the UE 112 has multiple sessions, a different SMF 208 can be assigned to each session to manage them separately and possibly provide different functions for each session. To support QoS, the AF 212 provides information about packet flows to the PCF 210, which is responsible for policy control. Based on this information, the PCF 210 determines policies regarding mobility and session management for the AMF 200 and SMF 208 to operate appropriately. The AUSF 204 supports authentication functions for the UE or the like and therefore stores data for authenticating the UE or the like, while the UDM 206 stores subscription data for the UE 112. A data network (DN) is not part of the 5GC network and provides internet access or operator services and the like.

[0162] An NF may be implemented as a network element on dedicated hardware, as a software instance running on dedicated hardware, or as a virtualized function instantiated on a suitable platform, e.g., a cloud infrastructure.

[0163] Any suitable step, method, feature, function, or benefit disclosed herein may be performed through one or more functional units or modules of one or more virtual devices. Each virtual device may comprise several of these functional units. These functional units may be implemented via processing circuitry, which may include one or more microprocessors or microcontrollers and other digital hardware, which may include digital signal processors (DSPs), dedicated digital logic, and the like. The processing circuitry may be configured to execute program code stored in memory, which may include one or several types of memory, such as read-only memory (ROM), random access memory (RAM), cache memory, flash memory devices, optical storage devices, and the like. The program code stored in memory includes program instructions for implementing one or more telecommunications and / or data communication protocols and instructions for executing one or more of the techniques described herein. In some implementations, the processing circuitry may be used to cause each functional unit to perform corresponding functions according to one or more embodiments of the present disclosure.

[0164] Numerous modifications and variations of the present disclosure are possible in light of the above teachings. It is therefore to be understood that, within the scope of the appended claims, the present disclosure may be practiced other than as specifically described herein.

Claims

1. 1. A method for performing a federated learning process in a network, comprising: sending, by a first computing node to a plurality of client computing nodes, a request message to participate in a federated learning process, the request message having a message type or flag indicating a machine learning (ML) preparation phase, the request message comprising information indicating available data requirements and / or available time requirements; receiving, by the first computing node, at least one response message in response to the request message; selecting, by the first computing node, which computing nodes of the plurality of client computing nodes to participate in the federated learning process based on the at least one response message; notifying the selected computing node by the first computing node to perform the federated learning process; A method comprising:

2. The method of claim 1 , wherein the information from the request message indicates both the available data requirements and the available time requirements.

3. The method according to claim 1 or 2, wherein the request message further comprises interoperability information, and the information indicating the available data requirements and / or the available time requirements is additional information that complements the interoperability information.

4. 4. The method of claim 3, wherein the at least one response message includes a response message from each client computing node indicating whether the client computing node can participate in the federated learning process based on the interoperability information and the additional information.

5. The method of claim 3 , wherein the at least one response message includes a response message from only each client computing node that can participate in the federated learning process based on the interoperability information and the additional information.

6. Selecting which computing nodes to participate in the federated learning process includes: selecting, by the first computing node, all of the client computing nodes that can participate in the federated learning process; The method of claim 4 or 5, comprising:

7. Selecting which computing nodes to participate in the federated learning process includes: selecting, by the first computing node, a subset of the client computing nodes that can participate in the federated learning process; The method of claim 4 or 5, comprising:

8. 8. The method of claim 1, wherein the first computing node is a server Network Data Analytics Function (NWDAF) and each client computing node is a client NWDAF.

9. The method of claim 1 , wherein the request message is sent and the selected computing node is notified using the same service.

10. The same service is a Nnwdaf_MLModelTraining_Subscribe or Nnwdaf_MLModelTrainingInfo_Request service, sending the request message includes invoking a service operation via the same service with a message type or flag indicating an ML preparation phase; 10. The method of claim 9, wherein notifying the computing nodes selected to perform the federated learning process includes invoking a service operation via the same service with a message type or flag indicating an ML execution phase.

11. 11. The method of claim 10, wherein for the ML execution phase, the service operation is invoked with at least some of ML Model Information, an FL Correlation ID, and guideline information.

12. 1. A method for performing a federated learning process in a network, comprising: sending, by a first computing node to a plurality of client computing nodes, a request message to participate in a federated learning process, the request message having a message type or flag indicating a machine learning (ML) preparation phase; receiving, by the first computing node, at least one response message in response to the request message; selecting, by the first computing node, which of the plurality of client computing nodes to participate in the federated learning process based on the at least one response message; notifying, by the first computing node, the selected computing node to perform the federated learning process; wherein the request message is sent and the selected computing node is notified using the same service.

13. The same service is a Nnwdaf_MLModelTraining_Subscribe or Nnwdaf_MLModelTrainingInfo_Request service, sending the request message includes invoking a service operation via the same service with a message type or flag indicating an ML preparation phase; 13. The method of claim 12, wherein notifying the computing nodes selected to perform the federated learning process includes invoking a service operation via the same service with a message type or flag indicating an ML execution phase.

14. 14. The method of claim 13, wherein for the ML execution phase, the service operation is invoked via the same service having at least some of ML Model Information, FL Correlation ID, and guideline information.

15. A non-transitory computer-readable medium having recorded thereon statements and instructions that, when executed by a processor of a first computing node, configure the processor to perform the method of any one of claims 1 to 14.

16. a first computing node configured to perform a federated learning process in a network, the first computing node comprising: a network interface configured to communicate with other computing nodes in the network; an associative learning circuit coupled to the network interface, sending, via the network interface to a plurality of client computing nodes, request messages to participate in the federated learning process, the request messages having a message type or flag indicating a machine learning (ML) preparation phase and including information indicating available data requirements and / or available time requirements; receiving at least one response message via the network interface in response to the request message; selecting which of the plurality of client computing nodes to participate in the federated learning process based on the at least one response message; notifying the selected computing nodes via the network interface to perform the federated learning process; The associative learning circuit configured as follows: a first computing node comprising:

17. 17. The first computing node of claim 16, wherein the federated learning circuitry is further configured to perform a method according to any one of claims 2 to 11.

18. a first computing node configured to perform a federated learning process in a network, the first computing node comprising: a network interface configured to communicate with other computing nodes in the network; an associative learning circuit coupled to the network interface, sending, via the network interface to a plurality of client computing nodes, request messages to participate in the federated learning process, the request messages having a message type or flag indicating a machine learning (ML) preparation phase; receiving at least one response message via the network interface in response to the request message; selecting, based on the at least one response message, which of the plurality of client computing nodes to participate in the federated learning process; notifying the selected computing nodes via the network interface to perform the federated learning process; an associative learning circuit configured as follows: wherein the request message is sent and notified to the selected computing node using the same service.

19. 19. The first computing node of claim 18, wherein the associative learning circuitry is further configured to perform the method of claim 13 or 14.

20. 1. A method for performing a federated learning process in a network, comprising: receiving, by a client computing node, a request message for participation in the federated learning process, the request message having a message type or flag indicating a machine learning (ML) preparation phase, and the request message including information indicating available data requirements and / or available time requirements; determining, by the client computing node, whether to participate in the federated learning process based on the availability and capabilities of the client computing node, taking into account the information provided in the request message; sending, by the client computing node, a response message indicating whether or not to participate in the federated learning process; A method comprising:

21. 21. The method of claim 20, wherein the information from the request message indicates both the available data requirements and the available time requirements.

22. The method of claim 20 or 21, wherein the request message further comprises interoperability information, and the information indicating the available data requirements and / or the available time requirements is additional information that supplements the interoperability information, and the decision whether to participate in the federated learning process is based on the interoperability information and the additional information.

23. 23. A non-transitory computer readable medium having recorded thereon statements and instructions that, when executed by a processor of a client computing node, configure the processor to perform the method of any one of claims 20 to 22.

24. a client computing node configured to perform a federated learning process in a network, a network interface configured to communicate with other computing nodes in the network; an associative learning circuit coupled to the network interface, receiving, via the network interface, a request message for participation in the federated learning process, the request message having a message type or flag indicating a machine learning (ML) preparation phase and including information indicating available data requirements and / or available time requirements; determining whether to participate in the federated learning process based on the availability and capabilities of the client computing node, taking into account the information provided by the request message; sending a response message via the network interface indicating whether or not to participate in the federated learning process; The associative learning circuit configured as follows: A client computing node comprising:

25. 25. A client computing node according to claim 24, wherein the federated learning circuitry is further configured to perform the method of claim 21 or 22.

Images