EP4646674A1 - Method and apparatus for federated learning in a network - Google Patents

Abstract

Provided is a method for performing a federated learning process in a network. The method involves sending, by a first computing node to a plurality of client computing nodes, a request message for participation in the federated learning process. The method also involves the first computing node receiving at least one response message in response to the request message, selecting which client computing nodes to join the federated learning process based on the at least one response message, and informing the selected computing nodes to perform the federated learning process. The request message has a message type or flag indicating ML (Machine Learning) preparation phase. In accordance with an embodiment of the disclosure, the request message also has information indicating an available data requirement and/or an availability time requirement. This information can be useful for the client computing nodes to determine whether to join the federated learning process.

Description

METHOD AND APPARATUS FOR FEDERATED LEARNING IN A NETWORK

Related Application

[1] This patent application claims priority from United States provisional patent application no. 63/437,283 filed on January 5, 2023, the disclosure of which is incorporated by reference in its entirety.

Field of the Disclosure

[2] This disclosure relates to computing systems, and more particularly to FL (Federated Learning) in a network.

Background

[3] FL (Federated Learning) is an ML (Machine Learning) technique that is decentralized across multiple computing nodes (e.g. edge devices, servers, etc.) of a network which hold local data samples, normally without having to exchanging those local data samples. Federated learning is also known as collaborative learning and stands in contrast to traditional centralized machine learning techniques where all local datasets are located on one server, as well as other decentralized approaches in which local data samples are identically distributed amongst all computing nodes.

[4] Federated learning can enable multiple vendors to build a common machine learning model without sharing data, which may address issues such as data privacy, data security, data access rights, and access to heterogeneous data. Applications of federated learning are spread over a number of industries including defense, telecommunications, loT, and pharmaceutics for example.

[5] A network may include numerous computing nodes, but not all of these computing nodes may be suitable candidates for participating in a federated learning process. There exists a need to identify and select the suitable candidates to participate in a federated learning process. Summary of the Disclosure

[6] According to an aspect, there is provided a method for performing a federated learning process in a network. The method involves sending, by a first computing node to a plurality of client computing nodes, a request message for participation in the federated learning process. The method also involves receiving, by the first computing node, at least one response message in response to the request message. The method also involves selecting, by the first computing node, which computing nodes of the plurality of client computing nodes are to join the federated learning process based on the at least one response message. The method also involves informing, by the first computing node, the selected computing nodes to perform the federated learning process.

[7] The request message has a message type or flag indicating ML (Machine Learning) preparation phase. In accordance with an embodiment of the disclosure, the request message also includes information indicating an available data requirement and/or an availability time requirement. This information can be useful for the client computing nodes to determine whether to join the federated learning process. This information may also be useful for the client computing nodes to perform the federated learning process. In some implementations, the information from the request message indicates both the available data requirement and the availability time requirement.

[8] In some implementations, the request message also includes interoperability information, such that the information indicating the available data requirement and/or the availability time requirement is additional information which supplements the interoperability information. The combination of information provided to the client computing nodes can be useful for the client computing nodes to determine whether to join the federated learning process. This combination of information may also be useful for the client computing nodes to perform the federated learning process.

[9] In some implementations, the request message is sent and the selected computing nodes are informed using a same service. In this way, the service used to send the request message can be extended or re-used to inform the selected computing nodes to start executing FL training. The extending or re-using of the service can provide for various advantages in terms of efficiency.

[10] According to another aspect, there is provided a method for performing a federated learning process in a network. The method involves sending, by a first computing node to a plurality of client computing nodes, a request message for participation in the federated learning process. The method also involves receiving, by the first computing node, at least one response message in response to the request message. The method also involves selecting, by the first computing node, which computing nodes of the plurality of client computing nodes are to join the federated learning process based on the at least one response message. The method also involves informing, by the first computing node, the selected computing nodes to perform the federated learning process.

[11] The request message has a message type or flag indicating ML (Machine Learning) preparation phase. In accordance with an embodiment of the disclosure, the request message is sent and the selected computing nodes are informed using a same service. In this way, the service used to send the request message can be extended or reused to inform the selected computing nodes to start executing FL training. The extending or re-using of the service can provide for various advantages in terms of efficiency.

[12] 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.

[13] According to another aspect, there is provided a first computing node configured to perform a federated learning process in a network. The first computing node has a network interface configured to communicate with other computing nodes of the network, and federated learning circuitry coupled to the network interface. The federated learning circuitry is configured to send, via the network interface to a plurality of client computing nodes, a request message for participation in the federated learning process. The federated learning circuitry is also configured to receive, via the network interface, at least one response message in response to the request message. The federated learning circuitry is also configured to select which computing nodes of the plurality of client computing nodes are to join the federated learning process based on the at least one response message. The federated learning circuitry is also configured to inform, via the network interface, the selected computing nodes to perform the federated learning process.

[14] The request message has a message type or flag indicating ML (Machine Learning) preparation phase. In accordance with an embodiment of the disclosure, the request message also includes information indicating an available data requirement and/or an availability time requirement. This information can be useful for the client computing nodes to determine whether to join the federated learning process. This information may also be useful for the client computing nodes to perform the federated learning process. In some implementations, the information from the request message indicates both the available data requirement and the availability time requirement.

[15] According to another aspect, there is provided a first computing node configured to perform a federated learning process in a network. The first computing node has a network interface configured to communicate with other computing nodes of the network, and federated learning circuitry coupled to the network interface. The federated learning circuitry is configured to send, to a plurality of client computing nodes via the network interface, a request message for participation in the federated learning process. The federated learning circuitry is also configured to receive, via the network interface, at least one response message in response to the request message. The federated learning circuitry is also configured to select which computing nodes of the plurality of client computing nodes are to join the federated learning process based on the at least one response message. The federated learning circuitry is also configured to inform, via the network interface, the selected computing nodes to perform the federated learning process.

[16] The request message has a message type or flag indicating ML (Machine Learning) preparation phase. In accordance with an embodiment of the disclosure, the request message is sent and the selected computing nodes are informed using a same service. In this way, the service used to send the request message can be extended or re- used to inform the selected computing nodes to start executing FL training. The extending or re-using of the service can provide for various advantages in terms of efficiency.

[17] According to another aspect, there is provided a method for performing a federated learning process in a network. The method involves receiving, by a client computing node, a request message for participation in the federated learning process. The method also involves determining, by the client computing node, whether to join the federated learning process based on availability and capability of the client computing node in view of information provided by the request message. The method also involves sending, by the client computing node, a response message indicating whether to join the federated learning process.

[18] The request message has a message type or flag indicating ML (Machine Learning) preparation phase. In accordance with an embodiment of the disclosure, the request message also includes information indicating an available data requirement and/or an availability time requirement. This information can be useful for the client computing node to determine whether to join the federated learning process. This information may also be useful for the client computing node to perform the federated learning process. In some implementations, the information from the request message indicates both the available data requirement and the availability time requirement.

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

[20] 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 a method as summarized above. [21] According to another aspect, there is provided a client computing node configured to perform a federated learning process in a network. The client computing node has a network interface configured to communicate with other computing nodes of the network, and federated learning circuitry coupled to the network interface.. The federated learning circuitry is configured to receive, via the network interface, a request message for participation in the federated learning process, wherein the request message has a message type or flag indicating ML (Machine Learning) preparation phase. The federated learning circuitry is also configured to determine whether to join the federated learning process based on availability and capability of the client computing node in view of the information provided by the request message. The federated learning circuitry is also configured to send, via the network interface, a response message indicating whether to join the federated learning process.

[22] The request message has a message type or flag indicating ML (Machine Learning) preparation phase. In accordance with an embodiment of the disclosure, the request message also includes information indicating an available data requirement and/or an availability time requirement. This information can be useful for the client computing node to determine whether to join the federated learning process. This information may also be useful for the client computing node to perform the federated learning process. In some implementations, the information from the request message indicates both the available data requirement and the availability time requirement.

[23] Other aspects and features of the present disclosure will become apparent, to those ordinarily skilled in the art, upon review of the following description of the various embodiments of the disclosure.

Brief Description of the Drawings

[24] Embodiments will now be described with reference to the attached drawings in which:

Figure 1 is a block diagram of an example network having computing nodes for federated learning; Figure 2 is a sequence diagram of a method of performing a federated learning process in a network;

Figures 3A to 3D are block diagrams of a system with signalling shown for preparation request, preparation message in an ML preparation phase, preparation message in an ML execution phase, and an extended Nnwdaf_MLPreparation service, respectively;

Figure 4 is a sequence diagram of a process for federated learning training among multiple NWDAF (Network Data Analytics Function);

Figure 5 is a sequence diagram of a process for client NWDAF(s) selection in a federated learning preparation phase;

Figure 6 is a sequence diagram of a process for NWDAFs monitoring and reselection in a federated learning execution phase;

Figure 7 is a sequence diagram of a process for dynamic discovery of new NWDAFs in a federated learning execution phase when information about a server NWDAF is known at a new client NWDAF(s);

Figure 8 is a sequence diagram of a process for dynamic discovery of new NWDAFs in a federated learning execution phase when information about a server NWDAF is unknown at a new client NWDAF(s);

Figure 9 is a sequence diagram of a process for extending service in an FL preparation phase and an FL execution phase;

Figures 10A and 10B are sequence diagrams of another method of performing a federated learning process in a network;

Figure 11 is a sequence diagram of a method of subscribing and unsubscribing to an ML model for analytics; Figure 12 is a schematic of an example cellular communications system in which some embodiments of the present disclosure may be implemented; and

Figures 13 and 14 are block diagrams 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 Embodiments

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

Introduction

[26] Referring first to Figure 1 , shown is a block diagram of an example network 130 having computing nodes 140 and 150a-n for federated learning. The network 130 can have other components as well, but these are not shown for simplicity. In some implementations, the network 130 can be core network of a cellular communication system, for example a 5G core network. However, other implementations are possible and are within the scope of the disclosure. The computing nodes 140 and 150a-n include a first computing node 140 and client computing nodes 150a-n. The number of computing nodes 140 and 150a-n can vary and is implementation-specific.

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

[28] The client computing nodes 150a-n are shown with a configuration corresponding to that of the first computing node 140, thus similarly having a network interface 152 and federated learning circuitry 154. However, it is to be understood that the client computing nodes 150a-n can have different and varying configurations. Note that the computing nodes 140 and 150a-n can stem from different vendors and thus can vary in terms of configuration.

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

[30] At step 2-1 , the first computing node 140 sends a request message for participation 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 depicted or in other ways such as daisy chain for example. At step 2-2, each client computing node 150a-n receives the request message. It is possible that not all of the client computing nodes 150a-n are suitable candidates for participating in the federated learning process. Thus, at step 2-3, each client computing node 150a-n determines whether to join the federated learning process based on availability and capability of the client computing node in view of information provided by the request message

[31] At step 2-4, each client computing node 150a-n sends a response message. In some implementations, the response message indicates whether to join the federated learning process. More generally, the response message can include any useful information from which the first computing node 140 can determine which client computing nodes 150a-n are suitable candidates for participating in the federated learning process. The response message can be implemented using separate response messages as depicted or in other ways such as a single consolidated response message for example. At step 2-5, the first computing node 140 receives the response message(s).

[32] The request message sent at step 2-1 and received at step 2-2 has a message type or flag indicating ML preparation phase. For example, the request message can have a message type of “preparation” or a federated learning execution flag of “false”. As another example, the request message can have an ML preparation flag which identifies whether the request is for preparing federated learning or executing federated learning, and such flag can be set to identify preparation for federated learning (i.e. ML preparation phase). In accordance with an embodiment of the disclosure, the request message also includes information indicating an available data requirement and/or an availability time requirement. This information can be useful for the client computing nodes 150a-n to determine whether to join the federated learning process. This information may also be useful for the client computing nodes 150a-n to perform the federated learning process.

[33] The “available data requirement” refers to a requirement on the available local data at the client computing node for training local ML model of the FL process. In some implementations, the available data requirement includes a list of Event IDs of the local data for training, and may also include dataset statistical properties, a time window of data samples and a minimum number of data samples. The available data requirement can be used by a client computing node to judge whether its available data satisfy the requirement for the FL process. The “availability time requirement” refers to a requirement on the available time of the client computing node to participate the FL process. The availability time requirement can be used by a client computing node to determine its availability for the FL process.

[34] In some implementations, the information from the request message indicates both the available data requirement and the availability time requirement. The combination of this information can be particularly useful for the client computing nodes 150a-n to determine whether to join the federated learning process. In particular, the combination of this information can be much more useful than either the available data requirement or the availability time requirement by themselves, as it may be possible to select the most suitable candidates to participate in the federated learning process when considering the combination of the available data requirement and the availability time requirement.

[35] In some implementations, the request message also includes interoperability information, such that the information indicating the available data requirement and/or the availability time requirement is additional information which 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. Interoperability information is mainly about FL operations, e.g., the initial model provided by the first computing node can be trained at the client computing node, or the required operations for training ML model can be performed at both server and client computing nodes. This is different from the information indicating available data requirement and/or availability time requirement, which relate to requirements on data and time for a client node to train ML model.

[36] The combination of information (i.e. the interoperability information and the additional information which supplements the interoperability information) provided to the client computing nodes 150a-n can be useful for the client computing nodes 150a-n to determine whether to join 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 can also be used to judge whether the capability of the client computing node, e.g., computation and communication, satisfy the requirements for performing the FL process.

[37] In some specific implementations, the request message includes some or more of analytics ID, ML model interoperability information, ML model ID that identifies the provided ML model, ML model information, an ML model file, ML training information such as data availability requirement and time availability requirement, training reporting information, ML preparation flag, ML model accuracy check flag, ML correlation ID, termination request (when terminating federated learning identified by the ML correlation ID and optionally indicating the reason, e.g. FL client NWDAF is unselected by the FL server NWDAF for the FL process, or the FL process is suspended, etc.), training filter information, target of training reporting, and use case context.

[38] In some implementations, the response message(s) received at step 2-5 includes a response message from each client computing node 150a-n indicating whether the client computing nodes 150a-n can join 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 they can join the federated learning process. In other implementations, the response message(s) received at step 2-5 includes a response message from only each client computing node 150a-n that can join the federated learning process based on the interoperability information and the additional information. The first computing node 140 can for example interpret no response from a client computing node to mean that the client computing node is unable to join the federated learning process. Other implementations are possible.

[39] In some specific implementations, the response message includes some or more of an operation execution result indication when the request is accepted or an error response with cause code when the request is not accepted (e.g. NWDAF does not meet the ML training requirements, ML training is not complete, NWDAF overload, not available for the FL process anymore, etc.), ML model ID, analytics ID, ML model Information, ML correlation ID when for federated learning, corresponding use case context, global ML model accuracy (the model accuracy of the global ML model, which is calculate by the FL client NWDAF using the local training data as the testing dataset), status report of FL training: local ML model metric and training input data information (e.g. areas covered by the data set, sampling ratio, maximum/minimum of value of each dimension of data, etc.) as generated by the FL client NWDAF during FL procedure, delay event notification, global ML model metric. [40] At step 2-6, the first computing node 140 selects which client computing nodes 150a-n are to join the federated learning process based on the response message(s). In some implementations, the first computing node 140 selects all of the client computing nodes 150a-n that have indicated that they can join the federated learning process. In other implementations, the first computing node 140 selects a subset of the client computing nodes 150a-n that have indicated that they can join the federated learning process. The first computing node 140 might select a subset of the client computing nodes 150a-n for example if more client computing nodes 150a-n indicate that they can join the federated learning process than are needed or wanted. The first computing node 140 might also select a subset of the client computing nodes 150a-n for other reasons which might depend on the response message(s) for example.

[41] In the illustrated example, it is assumed that the first two client computing nodes 150a-b have been selected by the first computing node 140 for participation in the federated learning process. At step 2-7, the first computing node 140 informs the selected computing nodes 150a-b to perform the federated learning process. For example, an instructing message can be sent to the selected computing nodes 150a-b. This can be implemented in a multicast manner as depicted or in other ways such as daisy chain for example. In some implementations, the instructing message is sent only the selected computing nodes 150a-b as depicted. In other implementations, the instructing message is sent to all of the client computing nodes 150a-n regardless of whether they have been selected, such that the instructing message indicates which of the client computing nodes 150a-n have been selected (e.g. an identification of the first two client computing nodes 150a-b) such that each client computing node 150a-n can determine from such indication whether they have been selected. Other implementations are possible.

[42] Finally, at step 2-8 the federated learning process is executed by the first computing node 140 and the selected computing nodes 150a-b. Note that the other client computing nodes 150n which are not selected by the first computing node 140 do not participate in the federated learning process. In some implementations, the selected computing nodes 150a-b utilizes the additional information (i.e. available data requirement and/or availability time requirement) from the request message during the federated learning process. For example, according to the available data requirement, a client computing node uses the required local data to train local ML model for the FL process.

[43] In some implementations, 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. Particulars of the computing nodes 140 and 150a-b may depend on the network 130 and may be application-specific.

[44] In some implementations, the first computing node 140 informs the selected computing nodes 150a-b at step 2-7 using a same service that was used to send the request message at step 2-1 . In this way, the service used to send the request message at step 2-1 can be extended or re-used to inform the selected computing nodes 150a-b at step 2-7 to start executing FL training at step 2-8. The extending or re-using of the service can provide for various advantages in terms of efficiency and avoiding a different services to send the preparation message and inform client to start executing FL training. In other implementations, separate services are utilized for steps 2-1 and 2-7.

[45] Note that parameters provided in the preparation message of step 2-7 are normally different from that in the request message of step 2-1 . For example, in step 2-7, the parameters in the preparation message can include initial ML Model Information, message type (-‘execution”) or an FL execution flag (-‘true”) to indicate that this message is for informing the client NWDAF to start executing FL training, FL Correlation ID, guideline information (e.g., maximum response time for FL Client to provide interim local ML model information).

[46] There are many possibilities for the same service mentioned above. In some implementations, the same service is an Nnwdaf_MLPreparation_Request service, such that sending the request message involves invoking an Nnwdaf_MLPreparation_Request service operation with a message type or flag indicating ML preparation phase, and informing the selected computing nodes to perform the federated learning process involves invoking an Nnwdaf_MLPreparation_Request service operation with a message type or flag indicating ML execution phase. [47] In other implementations, the same service is an Nnwdaf_MLModelTraining_Subscribe service, such that sending the request message involves invoking an Nnwdaf_MLModelTraining_Subscribe service operation with a message type or flag indicating ML preparation phase, and informing the selected computing nodes to perform the federated learning process involves invoking an Nnwdaf_MLModelTraining_Subscribe service operation with a message type or flag indicating ML execution phase.

[48] In other implementations, the same service is an Nnwdaf_MLModelTraininglnfo_Request service, such that sending the request message involves invoking an Nnwdaf_MLModelTraininglnfo_Request service operation with a message type or flag indicating ML preparation phase, and informing the selected computing nodes to perform the federated learning process involves invoking an Nnwdaf_MLModelTraininglnfo_Request service operation with a message type or flag indicating ML execution phase.

[49] Other possibilities not specifically mentioned herein may be possible for the same service. In general, any suitable service with suitable message types or flags can be used. There are many possibilities for such message types and flags. Specific example details 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. Nnwdaf_MLModelTraining_Subscribe and Nnwdaf_MLModelTraininglnfo_Request services) are possible and are within the scope of the disclosure.

[50] According to another embodiment of the disclosure, there is provided a non- transitory computer readable medium having recorded thereon statements and instructions that, when executed by the processor 146 of the first computing node 140, implement a method as described herein. The non-transitory computer readable medium can be the computer readable medium 148 of the first computing node 140 shown in Figure 1 , or some other non-transitory computer readable medium. [51] According to another embodiment of the disclosure, there is provided a non- transitory computer readable medium having recorded thereon statements and instructions that, when executed by the processor 156 of the client computing node 150a, implement a method as described herein. The non-transitory computer readable medium can be the computer readable medium 158 of the client computing node 150a shown in Figure 1 , or some other non-transitory computer readable medium.

[52] Examples of a non-transitory computer readable medium include an SSD (Solid State Drive), a hard disk drive, a CD (Compact Disc), a DVD (Digital Video Disc), a BD (Blu-ray Disc), a memory stick, etc. Other non-transitory computer readable mediums are also possible.

[53] The illustrated examples described herein focus on software implementations. However, other implementations are possible and are within the scope of this disclosure. It is noted that other implementations can include additional or alternative hardware components, such as any appropriately configured FPGA (Field-Programmable Gate Array), ASIC (Application-Specific Integrated Circuit), and/or microcontroller, for example. Thus, the federated learning circuitry 144 of the first computing node 140 and the federated learning circuitry 154 of the client computing nodes 150a-n can instead be implemented with any suitable combination of hardware, software and/or firmware.

[54] Further example details are provided in the following sections. It is to be understood that the following sections are very specific and are provided merely for exemplary purposes, such that other implementations are possible and within the scope of the disclosure.

Overview of Example System & Signaling

[55] Figures 3A to 3D are block diagrams of a system with signalling shown for preparation reguest, preparation message in an ML preparation phase, and preparation message in an ML execution phase, and an extended Nnwdaf_MLPreparation service, respectively. These block diagrams are briefly described below. [56] As shown in Figure 3A, server NWDAF sends preparation request to client NWDAFs 1...X for client NWDAF(s) selection. The parameters/information in the preparation request include a message type (- ‘preparation”) or an FL execution flag (-’false”), interoperability information, available data requirement, availability time requirement, etc.

[57] The client NWDAF(s), which decides to join the ML process, sends response to the server NWDAF as shown in Figure 3B. Then the server NWDAF selects client NWDAF(s) from the ones which response to the preparation request.

[58] After client NWDAF(s) selection completed, the server NWDAF informs the selected client NWDAF(s) to execute ML training, as shown in Figure 3C. The parameters/information in the preparation message include initial ML Model Information, a message type (-‘execution”) or ML (e.g., federated learning) execution flag, ML (e.g., FL) Correlation ID, guideline information (e.g., maximum response time for client NWDAF(s) to provide interim local ML model information), etc.

[59] Figure 3D is a block diagram of a system with signalling shown for an extended Nnwdaf_MLPreparation service. In the ML Preparation Phase, the service Nnwdaf_Preparation is extended by adding new parameters to the preparation request for client NWDAF(s) selection. Server NWDAF sends preparation request to client NWDAF(s) by invoking Nnwdaf_Preparation_Request service operation. In the preparation request, the parameters/information include a message type (- ‘preparation”) or an FL execution flag (-‘false”), interoperability information, available data requirement, availability time requirement, etc. The client NWDAF(s) which decides to join the ML (e.g., FL) process, responds to the server NWDAF by invoking Nnwdaf_Preparation_Request response service operation indicating that it will join the ML (e.g., FL) procedure. Then, the Server performs selection from the client NWDAF(s).

[60] In the very beginning of the ML Execution Phase, the Server informs the selected client NWDAF(s) to perform ML (e.g., FL) operations by invoking Nnwdaf_MLPreparation_Request service operation. In the preparation message, the parameters/information include initial ML Model Information, a message type (-‘execution”) or ML (e.g., federated learning) execution flag, ML (e.g., FL) Correlation ID, guideline information (e.g., maximum response time for client NWDAF(s) to provide interim local ML model information), etc.

Federated Learning Among Multiple NWDAFs

[61] Some solutions to support federated learning among multiple NWDAFs in 5GC (5G Core Network) have been concluded in clause 8.8 of 3rd Generation Partnership Project, TR 23.700-81 Study of Enablers for Network Automation for 5G, Release 18, Version 2.0.0 (2022-11), hereinafter “TR 23.700-81”. Some description and procedures of federated learning among multiple NWDAFs have been added into clause 6.2C of 3rd Generation Partnership Project, TS 23.288 Architecture enhancements for 5G System (5GS) to support network data analytics services, Release 18, Version 18.0.0 (2022-12), hereinafter “TS 23.288”.

[62] An NWDAF containing MTLF (Model Training logical function) can leverage federated learning technigue to train an ML model, in which there is no need for input data transfer (e.g. centralized into one NWDAF) but instead involve cooperation among multiple NWDAFs (MTLF) distributed in different areas, i.e. sharing of ML model(s) and of the learning results among multiple NWDAFs (MTLF). Figure 4 is a seguence diagram of a process for federated learning training among multiple NWDAF. Various steps are briefly described below.

[63] At step 4-0, a consumer (NWDAF containing AnLF) sends a subscription reguest to NWDAF containing MTLF to retrieve a ML model, including Analytic ID and ML model filter information as described in TS 23.288, the NWDAF containing MTLF can be a FL server (server NWDAF) with FL server capability or a MTLF without FL server capability. Note that there are many possibilities for the procedure of MTLF registration and discovery with respect to FL. Also note that there are many possibilities for the definition of FL capability. [64] At step 4-1 , server NWDAF sends a request to the selected NWDAF containing MTLF (client NWDAF) that participates in the Federated learning to perform the local model training for federated learning.

[65] At step 4-2, each client NWDAF collects its local data by using the current mechanism in clause 6.2 of TS 23.288.

[66] At step 4-3, during federated learning training procedure, each client NWDAF further trains the retrieved ML model from the server NWDAF based on its own data, and reports interim local ML model information to the server NWDAF. The ML model information are exchanged between the client NWDAF(s) 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(s) and the server NWDAF. Also note that there are many possibilities for the services in step 4-1 , 4-3, 4-5a and 4-6 to enable FL based ML model training.

[67] At step 4-4, the server NWDAF aggregates all the local ML model information retrieved at step 4-3, to update the global ML model.

[68] At step 4-5a, based on the consumer request, the server NWDAF updates the training status (an accuracy level) to the consumer periodically (one or multiple rounds of training or every 10 min, etc.) or dynamically when some pre-determined status (e.g. some accuracy level) is achieved.

[69] Optionally at step 4-5b, Consumer decides whether the current model can fulfil various requirements, e.g. accuracy and time. The consumer modifies subscription if the current model can fulfil the various requirements. Note that the various requirements at step 4-5b are for the consumer and are different from the available data requirement and the availability time requirement described above for the client computing nodes. Note that there are many possibilities for providing the accuracy of FL model process.

[70] At step 4-5c, according to the request from the consumer, server NWDAF updates or terminates the current FL training process. [71] At step 4-6, if the FL procedure continues, server NWDAF sends the aggregated ML model information to each client NWDAF for next round model training.

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

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

Maintenance of Federated Learning in 5GC

[74] A solution for maintenance of FL process among multiple NWDAFs in 5GC has been given in TR 23.700-81 (i.e., Solution #51). This solution is proposed to address Key Issue #8: Supporting Federated Learning in 5GC. The study bullets of this Key Issues include:

• Study how to coordinate multiple NWDAFs including selection of participant NWDAF instances in the federated learning group, e.g. assistance information (if any) to perform the selection, and decision of role for the participant NWDAF.

• Study whether and how to perform performance (e.g. network performance and model performance) monitoring of the NWDAF federated learning operation.

[75] To address the challenges in the above bullets for supporting federated learning in 5GC, this solution focus on the NWDAF(s) selection in federated learning preparation phase, NWDAF(s) monitoring and maintenance in federated learning execution phase. A lot of factors influence client NWDAF(s) selection in federated learning preparation phase. For example, the capability of NWDAF(s), the interoperability and availability of client NWDAF(s) to join in federated learning.

[76] In federated learning execution phase, due to dynamic changes of federation network, current client NWDAF(s) may leave or join, the dynamic joining and leaving of client NWDAF(s) to a federated learning multi-round learning/training process in 5GC should be considered. In addition, methods may be applied for server NWDAF to monitoring the status changes (e.g. changes of capabilities and availability) of client NWDAF(s).

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

[78] At step 5-0, NWDAFs register into NRF with federated learning capability. Server NWDAF discovers client NWDAFs based on e.g. federated learning capability, Analytics ID, etc.

[79] At step 5-1 , server NWDAF sends federated learning preparation request to the client NWDAF(s) by invoking an Nnwdaf_MLPreparation_Request service operation with Interoperability information. In the preparation request, indication of the role for the NWDAF(s), i.e. act as client NWDAF(s), may be contained. Note that the Interoperability information indicates what abilities (e.g. able to run certain models) are needed or wanted for the client NWDAF to support this FL procedure, e.g. if the server NWDAF and the client NWDAF can share model and how to share model. The Interoperability information may be determined among different vendors.

[80] At step 5-2, client NWDAF(s) decides whether to join the federated learning process based on its availability, capability and Interoperability information.

[81] At step 5-3, client NWDAF(s) send the response to server NWDAF indicating if it wants to join the FL procedure.

[82] At step 5-4, the server NWDAF may send test tasks to the client NWDAF(s) that want to join the FL procedure. The client NWDAF(s) run the test tasks and send the results to the server NWDAF. Note that the test tasks may be micro computation or training tasks, the requirement for completing the micro tasks is the same as or is similar to the main tasks. The test task could be a small task to let the client NWDAF collect local data and sends the local model weights back to the server; or some test to make sure that the server and client NWDAF can communicate if they use the same FL framework or library. There are many ways to retrieve and run the test tasks.

[83] At step 5-5, server NWDAF selects the client NWDAF(s), the result of the test tasks may be taken into account by the server NWDAF for the selection of client NWDAF(s).

[84] In federated learning execution phase, server NWDAF monitors the status changes of client NWDAF(s). client NWDAF(s) may be re-selected based on the updated status, availability, and/or capability, etc. of the client NWDAF(s) for the FL tasks. Figure 6 is a sequence diagram of a process for NWDAFs monitoring and re-selection in a federated learning execution phase. Various steps are briefly described below.

[85] At step 6-1 , server NWDAF monitoring the status of client NWDAF(s) during the federated learning execution process, receives the updated status of the client NWDAF(s). Server NWDAF may perform monitoring and obtain the updated status of client NWDAF(s) directly and/or via NRF. Note that the status of client NWDAF could be the NF load, NF availability, its capability changes, e.g. it does not support FL anymore.

[86] At step 6-2, server NWDAF checks client NWDAF(s) status based on the received information, judges whether re-selection of client NWDAF(s) for the next round(s) of federated learning is warranted. The judgement is based on the updated status of the client NWDAF(s), including the availability, capability, etc.

[87] At step 6-3, if re-selection is warranted as judged in step 6-2, server NWDAF re-select client NWDAF(s) as in steps 5-1 to 5-5 in Figure 5. The procedure for discovery of new client NWDAF(s) in federated learning execution phase is given in clause 2.1.2.2.3 of TS 23.288. [88] At step 6-4, client NWDAF(s) terminates operations for the federated learning if it receives termination request from the server NWDAF.

[89] There are two possible cases for server NWDAF to get the information of the new client NWDAF(s), i.e. from the new client NWDAF(s) directly or via NRF. The two possible cases include (1) new client NWDAF(s) inform server NWDAF directly and (2) server NWDAF gets the information of new client NWDAF(s) via NRF. These two possible cases are described below.

[90] Figure 7 is a sequence diagram of a process for dynamic discovery of new NWDAFs in a federated learning execution phase when information about a server NWDAF is known at a new client NWDAF(s). Client NWDAFs 1 to N are selected by server NWDAF for participating the current round of federated learning. Client NWDAFs N+1 to N+X, which are the new ones, have the capability to join in the next rounds of training processes. New client NWDAF(s), which are available and/or have the capability to join in the federated learning processes, know the information about the server NWDAF and inform server NWDAF directly. Various steps are briefly described below.

[91] At step 7-0, server NWDAF registers into NRF about the federated learning procedure with the following parameters: federated learning (FL) Correlation ID, and Analytics ID. Note that FL Correlation ID is used to identify a specific FL procedure. For example, a server NWDAF or a client NWDAF can join different FL procedures at the same time, then when they receive messages or data from other NWDAF, they have to know the message or data is for which FL procedure.

[92] When a server NWDAF starts a FL procedure, it registers the FL procedure in the NRF with FL Correlation ID, Analytics ID. When later a client NWDAF wants to join a FL dynamically, e.g. it wants to update its local model using global information, it will query NRF if there is an ongoing FL for the analytics ID. Then NRF will provide the server NWDAF ID and FL Correlation ID to the client NWDAF, then the client NWDAF can contact the server NWDAF to join the FL procedure. Wth the FL correlation ID, the server NWDAF knows which FL procedure the client NWDAF wants to join and which model it should provide to the client. [93] At step 7-1 , if the information about the server NWDAF and the corresponding FL procedure is known via NRF, new client NWDAF(s) inform server NWDAF to the client NWDAF(s) by invoking an Nnwdaf_MLPreparation_Request service operation their interoperability and availability.

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

[95] Figure 8 is a sequence diagram of a process for dynamic discovery of new NWDAFs in a federated learning execution phase when information about a server NWDAF is unknown at a new client NWDAF(s). Client NWDAFs 1 to N are selected by server NWDAF for participating the current round of federated learning. Client NWDAFs N+1 to N+X, which are the new ones, have the capability to join in the next rounds of training processes. At step 8-0, server NWDAF registers into NRF about the federated learning procedure as similarly described above for Figure 7. At steps 8-1 , server NWDAF gets the information of the new client NWDAF(s) dynamically via NRF by either subscribing to the event that a new client NWDAF registers or discovering NRF when it wishes to reselect client NWDAFs at step 8-2.

[96] The ML (e.g., Distributed Machine Learning I FL) process can be divided into two phases, i.e. , ML Preparation Phase and ML Execution Phase. Some implementations described herein provide details on how parameter can be sent from the server NWDAF to the client NWDAF(s) for client NWDAF(s) selection in the ML Preparation Phase. Furthermore, which service can be used to inform the client NWDAF(s) to execute ML training in the ML Execution Phase. Thus, some implementations described herein provide details on how parameter can be sent from the server NWDAF to the client NWDAF(s) for client NWDAF(s) selection, and/or which service can be used to inform the client NWDAF to execute ML training.

[97] Some implementations described herein extend the Nnwdaf_MLPreparation service given in Solution #51 in TR 23.700-81. The extension can include Add new parameters to the preparation request sending from the server NWDAF to the client NWDAF(s) for client NWDAF(s) selection in the ML Preparation Phase.

• Reuse the Nnwdaf_MLPreparation with extended parameters to inform the client NWDAF(s) to execute ML training in the ML Execution Phase.

The procedures by using the extended service for sending preparation request in the ML Preparation Phase and preparation message in the ML Execution Phase are given.

[98] In some implementations, the Nnwdaf_MLPreparation service given in Solution #51 in TR 23.700-81 is extended by adding new parameters to the preparation request in the ML Preparation Phase, reused and extended in the ML Execution Phase. The preparation request is sent from the server NWDAF to the client NWDAF(s) for client NWDAF(s) selection in the ML Preparation Phase. In the ML Execution Phase, the extended Nnwdaf_MLPreparation service is used by the server NWDAF to inform the client NWDAF(s) to execute ML training.

[99] In some implementations, the ML Preparation Phase and ML Execution Phase are improved by extending and reusing the Nnwdaf_MLPreparation service. The extended Nnwdaf_MLPreparation service is used for sending preparation request in the ML Preparation Phase for client NWDAF(s) selection and informing the client NWDAF(s) to execute ML training in the ML Execution Phase.

Service for Preparation Parameters and/or Information Exchange

[100] A federated learning process is taken as an example, to illustrate how the extended Nnwdaf_MLPreparation service be used for preparation request and message be sending from the server NWDAF to the client NWDAF(s) in the FL Preparation Phase and the FL Execution Phase, respectively.

[101] Figure 9 is a sequence diagram of a process for extending service in an FL preparation phase and an FL execution phase. Various steps are briefly described below. [102] At step 9-0, server NWDAF discovers client NWDAFs via NRF. NRF provides list of client NWDAF(s) to the server NWDAF based on FL capability, Analytics ID, Interoperability Indicator, Time interval supporting FL, etc.

[103] At step 9-1 , server NWDAF sends federated learning preparation request to the client NWDAF(s) by invoking an Nnwdaf_MLPreparation_Request service operation with Interoperability information. In the preparation request, the following parameters may be added: available data requirement, availability time requirement, message type (-‘preparation”) or an FL execution flag (-‘false”) to indicate that this request is for preparation.

[104] At step 9-2, client NWDAF(s) decides whether to join the federated learning process based on its availability, computation and communication capability, and Interoperability information.

[105] At step 9-3, client NWDAF(s) sends response to server NWDAF by invoking an Nnwdaf_MLFTeparation_Request response service operation with an indication on join FL process to indicate that it will join the FL process.

[106] At step 9-4, server NWDAF conducts selection of client NWDAF(s).

[107] At step 9-5, server NWDAF informs the selected NWDAF containing MTLF (client NWDAF) to perform the federated learning by invoking an Nnwdaf_MLFTeparation_Request service operation with initial ML Model Information, message type (-‘execution”) or an FL execution flag (-‘true”) to indicate that this message is for informing the client NWDAF to start executing FL training. Server NWDAF also includes FL Correlation ID, guideline information (e.g., maximum response time for FL Client to provide interim local ML model information) in the preparation message.

[108] Either message type or FL execution flag can be used in steps 9-1 and 9-5 for indicating the purpose of the Nnwdaf_MLPreparation_Request, e.g., for sending preparation request in the FL Preparation Phase or for informing preparation message in the FL Execution Phase. [109] If 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 only contained in the preparation message sent from server NWDAF to client NWDAF(s) in the FL Execution Phase. If the FL execution flag is a required parameter, it will be set as FL execution flag=“false” in the preparation request in the FL Preparation Phase, and be set as FL execution flag=”true” in the preparation message in the FL Execution Phase. More generally, a message type or flag indicating ML preparation phase or ML execution phase can be utilized.

[110] At step 9-6, server NWDAF and client NWDAF(s) start to perform FL training operations for the FL process.

Another Federated Learning Process

[111] Figures 10A and 10B are sequence diagrams of another method of performing a federated learning process in a network. Various steps are briefly described below.

[112] At step 10-0a, NWDAFs register into NRF. At step 10-0b, the consumer (NWDAF containing AnLF) sends a subscription request to NWDAF containing MTLF to retrieve a ML model, including Analytic ID and ML model filter information as described in clause 7.5.2 of TS 23.288, the NWDAF containing MTLF can be a FL server (server NWDAF) with FL server capability or a MTLF without FL server capability. At step 10-0c, server NWDAF discovers client NWDAFs via NRF. NRF provides list of client NWDAF(s) to the server NWDAF based on FL capability, Analytics ID, Interoperability Indicator, Time interval supporting FL, etc. Note that there are many possibilities for the definition of FL capability.

[113] At step 10-1 , server NWDAF sends federated learning preparation request to the client NWDAF(s) by invoking an Nnwdaf_MLPreparation_Request service operation with Interoperability information. In the preparation request, the following parameters may be added: available data requirement, and availability time requirement. [114] At step 10-2, client NWDAF(s) decides whether to join the federated learning process based on its availability, computation and communication capability, and Interoperability information.

[115] In some implementations, the server NWDAF may use the request to check if an NWDAF can meet the ML model training requirement (e.g. ML Model Interoperability information, Analytics ID, Serving Area and/or availability of data and time). In such case, the FL server NWDAF includes an ML Preparation Flag. In some implementations, when the ML Preparation Flag presents in the request, the service provider NWDAF only checks if it can meet the ML model training requirement (e.g. ML Model Interoperability information, Analytics ID, Serving Area and/or availability of data and time) and/or can successfully download the model if the model information is provided.

[116] At step 10-3, client NWDAF(s) sends response to server NWDAF indicating if it will join the FL procedure. This can be based on whether the ML model training requirements can be met.

[117] At step 10-4, server NWDAF conducts selection of client NWDAF(s). Such selection is based on the responses received at step 10-3.

[118] At step 10-5, server NWDAF informs the selected NWDAF containing MTLF (client NWDAF) to perform the federated learning by invoking an Nnwdaf_MLPreparation_Request service operation with initial ML Model Information, an FL execution flag. Server NWDAF includes FL Correlation ID, guideline information (e.g., maximum response time for FL Client to provide interim local ML model information) in the preparation message. Server NWDAF and client NWDAF(s) subscribe to each other for exchanging ML model information as described in clause 6.2C.2.2 of in TS 23.288.

[119] At step 10-6, each client NWDAF collects its local data by using the current mechanism in clause 6.2 of TS 23.288.

[120] At step 10-7, during federated learning training procedure, each client NWDAF further trains the retrieved ML model from the server NWDAF based on its own data, and reports interim local ML model information to the server NWDAF as defined in clause 6.2C.2.2 of TS 23.288. The ML model information are exchanged between the client NWDAF(s) and the server NWDAF during the FL training process.

[121] At step 10-8, the server NWDAF aggregates all the local ML model information retrieved at step 10-7, to update the global ML model.

[122] At step 10-9a, based on the consumer request, the server NWDAF provides the training status (i.e., an accuracy level/information) to the consumer by invoking Nnwdaf_MLModelProvision_Notify service operation periodically (one or multiple rounds of training or every 10 min, etc.) or dynamically when some pre-determined status (e.g. some accuracy level) is achieved.

[123] Optionally, at step 10-9b, Consumer decides whether the current model can fulfil various requirements, e.g. accuracy and time. The consumer modifies ML model subscription if the current model can fulfil the various requirement. Note that the various requirements at step 10-9b are for the consumer and are different from the available data requirement and the availability time requirement described above for the client computing nodes. Note that there are many possibilities for providing the accuracy of FL model process.

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

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

[126] At step 10-11 , each client NWDAF updates its own ML model based on the aggregated ML model information distributed by the server NWDAF at step 10.

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

Model Information Exchange

[128] The Nnwdaf_MLModelProvision service is used for model sharing/parameter exchanging in the execution phase of a ML training process among multiple NWDAFs.

[129] Server NWDAF subscribes to client NWDAF(s) for getting local model information by invoking an Nnwdaf_MLModelProvision_Subscribe service operation, client NWDAF(s) subscribes to server NWDAF for getting global model information by invoking an Nnwdaf_MLModelProvision_Subscribe service operation as in 6.2A.1 with the following difference:

[130] The server NWDAF and client NWDAF(s) include the following parameters in the Nnwdaf_MLModelProvision_Subscribe request:

• Identity of the current ML process, i.e., FL Correlation ID.

[131] The server NWDAF and client NWDAF(s) include the following parameters in the Nnwdaf_MLModelProvision_Notify message:

• Identity of the current ML process, i.e., FL Correlation ID.

• Identity of the current iteration round, i.e., IR ID (e.g., IR ID = 1 , 2, 3, ...).

Note that whether server NWDAF and client NWDAFs sharing model or model parameters depending on the initial information in step 5 in clause 6.2C.2.1 of TS 23.288.

ML Model Subscribe/Unsubscribe

[132] Figure 11 is a sequence diagram of a method of subscribing and unsubscribing to an ML model for analytics. The procedure in Figure 11 is used by an NWDAF service consumer, i.e. an NWDAF containing AnLF or MTLF to subscribe/unsubscribe at another NWDAF, i.e. an NWDAF containing MTLF, to be notified when ML Model Information on the related Analytics becomes available or for model sharing/parameter exchanging in the execution phase of a federated learning training process among multiple NWDAFs, using Nnwdaf_MLModelProvision services as defined in clause 7.5 of TS 23.288. The ML Model Information is used by an NWDAF containing AnLF to derive analytics or by an NWDAF containing MTLF to update (global or local) model. The service is also used by an NWDAF to modify existing ML Model Subscription(s). An NWDAF can be at the same time a consumer of this service provided by other NWDAF(s) and a provider of this service to other NWDAF(s). Various steps are briefly described below.

[133] At step 11-1 , the NWDAF service consumer (i.e. an NWDAF containing AnLF or MTLF) subscribes to, modifies, or cancels subscription for a (set of) trained ML Model(s) associated with a/an (set of) Analytics ID(s) by invoking the Nnwdaf_MLModelProvision_Subscribe I Nnwdaf_MLModelProvision_Unsubscribe service operation. The parameters that can be provided by the NWDAF service consumer are listed in clause 6.2A.2 of TS 23.288. The service consumer optionally indicates its support for multiple ML models if available.

[134] When a subscription for a trained ML model associated with an Analytics ID is received, the NWDAF containing MTLF may:

• determine whether existing trained ML Model can be used for the subscription; or

• determine whether triggering further training for the existing trained ML models is needed or desired for the subscription.

[135] If the NWDAF containing MTLF determines that further training is warranted, this NWDAF may initiate data collection from NFs, (e.g. AMF/DCCF/ADRF), UE Application (via AF) or OAM as described in clause 6.2 of TS 23.288, to generate the ML model.

[136] If the service invocation is for a subscription modification or subscription cancelation, the NWDAF service consumer includes an identifier (Subscription Correlation ID) to be modified in the invocation of Nnwdaf_MLModelProvision_Subscribe. [137] If the service invocation is for model sharing/parameter exchanging in the execution phase of a federated learning training process among multiple NWDAFs, the NWDAF service consumer includes Identity of the current ML process (FL Correlation ID) in the invocation of Nnwdaf_MLModelProvision_Subscribe.

[138] At step 11-2, if the NWDAF service consumer subscribes to a (set of) trained ML model(s) associated to a (set of) Analytics ID(s), the NWDAF containing MTLF notifies the NWDAF service consumer with:

• the trained ML Model Information (containing a (set of) file address(es) of the trained ML model(s)), when multiple ML models is not supported by the consumer; or

• a set of pair of unique ML Model Identifier and ML Model Information associated with an Analytics ID, when multiple ML models is supported by the consumer.

Note that the structure and format of the ML Model identifier and its uniqueness are up to stage 3. Also note that parameters defined for Multiple models are for Analytics accuracy enhancement.

[139] By invoking Nnwdaf_MLModelProvision_Notify service operation. The content of trained ML Model Information that can be provided by the NWDAF containing MTLF is specified in clause 6.2A.2 of TS 23.288.

[140] The NWDAF containing MTLF also invokes the Nnwdaf_MLModelProvision_Notify service operation to notify an available re-trained ML model when the NWDAF containing MTLF determines that the previously provided trained ML Model should have re-training at step 11-1.

[141] When step 11-1 is for a subscription modification (i.e. including Subscription Correlation ID), the NWDAF containing MTLF may provide either a new trained ML model different to the previously provided one, or re-trained ML model by invoking Nnwdaf_MLModelProvision_Notify service operation. [142] When step 11-1 is for model sharing/parameter exchanging in the execution phase of a federated learning training process among multiple NWDAFs, FL Correlation ID and Identity of the current iteration round (IR ID (e.g., IR ID =1 , 2, ...)) should be contained in the Nnwdaf_MLModelProvision_Notify message.

Contents of ML Model Provisioning

[143] The consumers of the ML model provisioning services (i.e. an NWDAF containing AnLF or MTLF) as described in clauses 7.5 and 7.6 of TS 23.288 may provide the input parameters as listed below:

• Information of the analytics for which the requested ML model is to be used, including: o A list of Analytics ID(s): identifies the analytics for which the ML model is used. o [OPTIONAL] Use case context: indicates the context of use of the analytics to select the most relevant ML model. Note that the NWDAF containing MTLF can use the parameter “Use case context” to select the most relevant ML model, when several ML models are available for the requested Analytics ID(s). The values of this parameter are not standardized. o [OPTIONAL] ML Model Interoperability Information. This is vendor-specific information that conveys, e.g., requested model file format, model execution environment, etc. The encoding, format, and value of ML Model Interoperable Information is not specified since it is vendor specific information, and is agreed between vendors, if necessary for sharing purposes. o [OPTIONAL] ML Model Filter Information: enables to select which ML model for the analytics is requested, e.g. S-NSSAI, Area of Interest. Parameter types in the ML Model Filter Information are the same as parameter types in the Analytics Filter Information which are defined in procedures. o [OPTIONAL] Target of ML Model Reporting: indicates the object(s) for which ML model is requested, e.g. specific UEs, a group of UE(s) or any UE (i.e. all UEs). o ML Model Reporting Information with the following parameters: o (Only for Nnwdaf_MLModelProvision_Subscribe) ML Model Reporting Information Parameters as per Event Reporting Information Parameter defined in Table 4.15.1-1 of 3rd Generation Partnership Project, TS 23.502 Procedures for the 5G System (5GS), Release 18, Version 18.0.0 (2022-12), hereinafter “TS 23.502”. o [OPTIONAL] ML Model Target Period: indicates time interval [start, end] for which ML model for the Analytics is requested. The time interval is expressed with actual start time and actual end time (e.g. via UTC time). o A Notification Target Address (+ Notification Correlation ID) as defined in clause 4.15.1 of TS 23.502, allowing to correlate notifications received from the NWDAF containing MTLF with this subscription. o (Only for model sharing/parameter exchanging in the execution phase of a federated learning training process among multiple NWDAFs) Identity of the current ML process, i.e., FL Correlation ID. o [OPTIONAL] Indication of supporting multiple ML models. o [OPTIONAL] accuracy level of Interest.

Note that there are many possibilities whether and if additional parameters are utilized for multiple model provisioning.

[144] The NWDAF containing MTLF provides to the consumer of the ML model provisioning service operations as described in clauses 7.5 and 7.6 of TS 23.288, the output information as listed below: • (Only for Nnwdaf_MLModelProvision_Notify) The Notification Correlation Information.

• ML Model Information, which includes: o the ML model file address (e.g. URL or FQDN) for the Analytics I D(s), when multiple ML models is not supported; or o a set of pair of unique ML Model identifier and the ML model file address (e.g. URL or FQDN) for the Analytics I D(s), if multiple ML models is supported.

• Validity period: indicates time period when the provided ML Model Information applies.

• [OPTIONAL] Spatial validity: indicates Area where the provided ML Model Information applies. Note that spatial validity and Validity period are determined by MTLF internal logic and it is a subset of Aol if provided in ML Model Filter Information and of ML Model Target Period, respectively.

• (Only for model sharing/parameter exchanging in the execution phase of a federated learning training process among multiple NWDAFs) Identity of the current ML process, i.e. , FL Correlation ID.

• (Only for model sharing/parameter exchanging in the execution phase of a federated learning training process among multiple NWDAFs) Identity of the current iteration round (e.g., IR ID = 1 , 2, ... for Nnwdaf_MLModelProvision_Notify).

[145] Table 1 : Example NF services provided by NWDAF

[146] Table 2: Example Analytics information provided by NWDAF

[147] Example details of Nnwdaf_MLModelProvision_Subscribe service operation:

• Service operation name: Nnwdaf_MLModelProvision_Subscribe.

Description: Subscribes to NWDAF ML model provision with specific parameters. • Inputs, Exemplary: (set of) Analytics I D(s) defined in Table 7.1-2, Notification Target Address (+ Notification Correlation ID), FL Correlation ID (when for model sharing/parameter exchanging in the execution phase of a federated learning training process among multiple NWDAFs).

• Inputs, Optional: Subscription Correlation ID (in the case of modification of the ML model subscription), ML Model Filter Information to indicate the conditions for which ML model for the analytics is requested and Target of ML Model Reporting to indicate the object(s) for which ML model is requested (e.g. specific UEs, a group of UE(s) or any UE (i.e. all UEs)), ML Model Reporting Information (including e.g. ML Model Target Period), Expiry time, Use case context, indication of support for multiple ML models, multiple ML models Filter Information to indicate the conditions for which multiple ML models are requested.

• Outputs, Exemplary: When the subscription is accepted: Subscription Correlation ID (utilized for management of this subscription), Expiry time (utilized if the subscription can be expired based on the operator's policy).

• Outputs, Optional: None.

[148] Example details of Nnwdaf_MLModelProvision_Unsubscribe service operation:

• Service operation name: Nnwdaf_MLModelProvision_Unsubscribe.

• Description: unsubscribe to NWDAF ML model provision.

• Inputs, Exemplary: Subscription Correlation ID, FL Correlation ID (when for model sharing/parameter exchanging in the execution phase of a federated learning training process among multiple NWDAFs).

Inputs, Optional: FL Correlation ID (when for model sharing/parameter exchanging in the execution phase of a federated learning training process among multiple NWDAFs). Outputs, Exemplary: Operation execution result indication.

• Outputs, Optional: None.

[149] Example details of Nnwdaf_MLModelProvision_Notify service operation:

• Service operation name: Nnwdaf_MLModelProvision_Notify.

• Description: NWDAF notifies the ML model information to the consumer instance which has subscribed to the specific NWDAF service.

• Inputs, Exemplary: Notification Correlation Information, FL Correlation ID and Identity of the current iteration round (IR ID) when for model sharing/parameter exchanging in the execution phase of a federated learning training process among multiple NWDAFs, Set of o the tuple (Analytics ID, address (e.g. URL or FQDN) of Model file), when multiple ML models is not supported; or o The tuple (Analytics ID, one or more tuples of unique ML Model identifier and address (e.g. URL or FQDN) of Model file).

• Inputs, Optional: Validity period, Spatial validity, FL Correlation ID (when for model sharing/parameter exchanging in the execution phase of a federated learning training process among multiple NWDAFs).

• Outputs, Exemplary: Operation execution result indication.

• Outputs, Optional: None.

[150] Example details of Nnwdaf_MLPreparation service:

• Service description: this service enables the consumer to request NWDAF containing MTLF to prepare or perform ML Model Training. [151] Example details of Nnwdaf_MLPreparation_Request service operation:

• Service operation name: Nnwdaf_MLPreparation_Request

• Description: The consumer requests NWDAF to prepare or perform ML Model Training.

• Inputs, Exemplary:

• Interoperability information, available data requirement, and availability time requirement, when the federated learning execution is not provided.

• Initial ML Model Information (One of the following three types: ADRF ID with ML model identifier , or address (e.g., URL or FQDN) of Model file, or ML Model container when ML model container exists), FL Correlation ID, and guideline information (e.g., maximum response time for FL client to provide interim local ML model information), when the federated learning execution flag is provided.

• Inputs, Optional: FL execution flag.

• Outputs, Exemplary: None.

• Outputs, Optional: Indication of join federated learning when the FL execution flag is not provided.

[152] Referring now to Figure 12, shown is a schematic of an example cellular communications system 100 in which some embodiments of the present disclosure may be implemented. In the embodiments described herein, the cellular communications 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 the 5GS include NR base stations (gNBs) and optionally next generation eNBs (ng-eNBs) (e.g., LTE RAN nodes connected to the 5GC), controlling 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 station 102. Likewise, the (macro) cells 104-1 and 104-2 are generally referred to herein collectively as (macro) cells 104 and individually as (macro) cell 104. The RAN may also include a number of low power nodes 106-1 through 106-4 controlling corresponding small cells 108-1 through 108- 4. The low power nodes 106-1 through 106-4 can be small base stations (such as pico or femto base stations) or Remote Radio Heads (RRHs), or the like. Notably, while not illustrated, one or more of the small cells 108-1 through 108-4 may alternatively be provided by the base stations 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 node 106. Likewise, the small cells 108-1 through 108-4 are generally referred to herein collectively as small cells 108 and individually as small cell 108. The cellular communications system 100 also includes a core network 130A, which in the 5G System (5GS) is referred to as the 5GC. Note that the core network 130A is an example implementing of the network 130 depicted in Figure 1. The base stations 102 (and optionally the low power nodes 106) are connected to the core network 130A.

[153] The base stations 102 and the low power nodes 106 provide service to wireless communication devices 112-1 through 112-5 in the corresponding cells 104 and 108. The wireless communication devices 112-1 through 112-5 are generally referred to herein collectively as wireless communication devices 112 and individually as wireless communication device 112. In the following description, the wireless communication devices 112 are oftentimes UEs, but the present disclosure is not limited thereto.

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

[155] Seen from the access side the 5G network architecture shown in Figure 13 includes a plurality of UEs 112 connected to either a RAN 102 or an Access Network (AN) as well as an AMF 200. Typically, the R(AN) 102 comprises base stations, e.g. such as eNBs or gNBs or similar. Seen from the core network side, the 5GC NFs shown in Figure 13 include a NSSF 202, an AUSF 204, a UDM 206, the AMF 200, a SMF 208, a PCF 210, an Application Function (AF) 212, and an NWDAF 220. The NWDAF 220 can be used to implement server and client NWDAFs in an FL process.

[156] Reference point representations of the 5G network architecture are used to develop detailed call flows in the normative standardization. The N1 reference point is defined to carry signaling between the UE 112 and AMF 200. The reference points for connecting between the AN 102 and AMF 200 and between the AN 102 and UPF 214 are defined as N2 and N3, respectively. There is a reference point, N11 , between the AMF 200 and SMF 208, which implies that the SMF 208 is at least partly controlled by the AMF 200. N4 is used by the SMF 208 and UPF 214 so that the UPF 214 can be set using the control signal generated by the SMF 208, and the UPF 214 can report its state to the SMF 208. N9 is the reference point for the connection between different UPFs 214, and N14 is the reference point connecting between different AMFs 200, respectively. N15 and N7 are defined since the PCF 210 applies policy to the AMF 200 and SMF 208, respectively. N12 is utilized for the AMF 200 to perform authentication of the UE 112. N8 and N10 are defined because the subscription data of the UE 112 is utilized for the AMF 200 and SMF 208.

[157] The 5GC network aims at separating UP and CP. The UP carries user traffic while the CP carries signaling in the network. In Figure 13, the UPF 214 is in the UP and all other NFs, i.e., the AMF 200, SMF 208, PCF 210, AF 212, NSSF 202, AUSF 204, and UDM 206, are in the CP. Separating the UP and CP guarantees each plane resource to be scaled independently. It also allows UPFs to be deployed separately from CP functions in a distributed fashion. In this architecture, UPFs may be deployed very close to UEs to shorten the Round Trip Time (RTT) between UEs and data network for some applications involving low latency.

[158] The core 5G network architecture is composed of modularized functions. For example, the AMF 200 and SMF 208 are independent functions in the CP. Separated AMF 200 and SMF 208 allow independent evolution and scaling. Other CP functions like the PCF 210 and AUSF 204 can be separated as shown in Figure 13. Modularized function design enables the 5GC network to support various services flexibly.

[159] Each NF interacts with another NF directly. It is possible to use intermediate functions to route messages from one NF to another NF. In the CP, a set of interactions between two NFs is defined as service so that its reuse is possible. This service enables support for modularity. The UP supports interactions such as forwarding operations between different UPFs.

[160] Referring now to Figure 14, shown is a block diagram of a 5G network architecture using service-based interfaces between the NFs in the CP, instead of the point-to-point reference points/interfaces used in the 5G network architecture of Figure 13. However, the NFs described above with reference to Figure 14 correspond to the NFs shown in Figure 13. The service(s) etc. that a NF provides to other authorized NFs can be exposed to the authorized NFs through the service-based interface. In Figure 14, the service based interfaces are indicated by the letter “N” followed by the name of the NF, e.g. Namf for the service based interface of the AMF 200 and Nsmf for the service based interface of the SMF 208, etc. The NEF 300 and the NRF 302 in Figure 14 are not shown in Figure 13 discussed above. However, it should be clarified that all NFs depicted in Figure 13 can interact with the NEF 300 and the NRF 302 of Figure 14 as necessary, though not explicitly indicated in Figure 13.

[161] Some properties of the NFs shown in Figures 13 and 14 may be described in the following manner. The AMF 200 provides UE-based authentication, authorization, mobility management, etc. A UE 112 even using multiple access technologies is basically connected to a single AMF 200 because the AMF 200 is independent of the access technologies. The SMF 208 is responsible for session management and allocates Internet Protocol (IP) addresses to UEs. It also selects and controls the UPF 214 for data transfer. If a UE 112 has multiple sessions, different SMFs 208 may be allocated to each session to manage them individually and possibly provide different functionalities per session. The AF 212 provides information on the packet flow to the PCF 210 responsible for policy control in order to support QoS. Based on the information, the PCF 210 determines policies about mobility and session management to make the AMF 200 and SMF 208 operate properly. The AUSF 204 supports authentication function for UEs or similar and thus stores data for authentication of UEs or similar while the UDM 206 stores subscription data of the UE 112. The Data Network (DN), not part of the 5GC network, provides Internet access or operator services and similar.

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

[163] Any appropriate steps, methods, features, functions, or benefits disclosed herein may be performed through one or more functional units or modules of one or more virtual apparatuses. Each virtual apparatus may comprise a number of these functional units. These functional units may be implemented via processing circuitry, which may include one or more microprocessor or microcontrollers, as well as other digital hardware, which may include Digital Signal Processor (DSPs), special-purpose 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, etc. Program code stored in memory includes program instructions for executing one or more telecommunications and/or data communications protocols as well as instructions for carrying out one or more of the techniques described herein. In some implementations, the processing circuitry may be used to cause the respective functional unit to perform corresponding functions according one or more embodiments of the present disclosure.

[164] 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 disclosure may be practised otherwise than as specifically described herein.

Claims

We Claim:

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 for participation in the federated learning process, wherein the request message has a message type or flag indicating ML (Machine Learning) preparation phase, and wherein the request message comprises information indicating an available data requirement and/or an availability time requirement; 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 are to join the federated learning process based on the at least one response message; and informing, by the first computing node, the selected computing nodes to perform the federated learning process.

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

3. The method of claim 1 or claim 2, wherein the request message further comprises interoperability information, and wherein the information indicating the available data requirement and/or the availability time requirement is additional information which supplements the interoperability information.

4. The method of claim 3, wherein the at least one response message comprises a response message from each client computing node indicating whether the client computing node can join 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 comprises a response message from only each client computing node that can join the federated learning process based on the interoperability information and the additional information.

6. The method of claim 4 or claim 5, wherein selecting which computing nodes are to join the federated learning process comprises: selecting, by the first computing node, all of the client computing nodes that that can join the federated learning process.

7. The method of claim 4 or claim 5, wherein selecting which computing nodes are to join the federated learning process comprises: selecting, by the first computing node, a subset of the client computing nodes that that can join the federated learning process.

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

9. The method of any one of claims 1 to 8, wherein the request message is sent and the selected computing nodes are informed using a same service.

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

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. 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 for participation in the federated learning process, wherein the request message has a message type or flag indicating ML (Machine Learning) 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 computing nodes of the plurality of client computing nodes are to join the federated learning process based on the at least one response message; and informing, by the first computing node, the selected computing nodes to perform the federated learning process; wherein the request message is sent and the selected computing nodes are informed using a same service.

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

14. The method of claim 13, wherein for the ML execution phase, the service operation is invoked via the same service with at least some of ML Model Information, an 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 implement a method according to any one of claims 1 to 14.

16. A first computing node configured to perform a federated learning process in a network, comprising: a network interface configured to communicate with other computing nodes of the network; and federated learning circuitry coupled to the network interface and configured to: send, via the network interface to a plurality of client computing nodes, a request message for participation in the federated learning process, wherein the request message has a message type or flag indicating ML (Machine Learning) preparation phase, and wherein the request message comprises information indicating an available data requirement and/or an availability time requirement; receive, via the network interface, at least one response message in response to the request message; select which computing nodes of the plurality of client computing nodes are to join the federated learning process based on the at least one response message; and inform, via the network interface, the selected computing nodes to perform the federated learning process.

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

18. A first computing node configured to perform a federated learning process in a network, comprising: a network interface configured to communicate with other computing nodes of the network; and federated learning circuitry coupled to the network interface and configured to: send, to a plurality of client computing nodes via the network interface, a request message for participation in the federated learning process, wherein the request message has a message type or flag indicating ML (Machine Learning) preparation phase; receive, via the network interface, at least one response message in response to the request message; select which computing nodes of the plurality of client computing nodes to join the federated learning process based on the at least one response message; and inform, via the network interface, the selected computing nodes to perform the federated learning process; wherein the request message is sent and the selected computing nodes are informed using a same service.

19. The first computing node of claim 18, wherein the federated learning circuitry is further configured to implement the method of any one of claims 13 to 14.

20. 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, wherein the request message has a message type or flag indicating ML (Machine Learning) preparation phase, and wherein the request message comprises information indicating an available data requirement and/or an availability time requirement; determining, by the client computing node, whether to join the federated learning process based on availability and capability of the client computing node in view of the information provided by the request message; and sending, by the client computing node, a response message indicating whether to join the federated learning process.

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

22. The method of claim 20 or claim 21 , wherein the request message further comprises interoperability information, and wherein the information indicating the available data requirement and/or the availability time requirement is additional information which supplements the interoperability information, and wherein determining whether to join the federated learning process is based on the interoperability information and the additional information.

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 implement a method according to any one of claims 20 to 22.

24. A client computing node configured to perform a federated learning process in a network, comprising: a network interface configured to communicate with other computing nodes of the network; and federated learning circuitry coupled to the network interface and configured to:. receive, via the network interface, a request message for participation in the federated learning process, wherein the request message has a message type or flag indicating ML (Machine Learning) preparation phase, and wherein the request message comprises information indicating an available data requirement and/or an availability time requirement; determine whether to join the federated learning process based on availability and capability of the client computing node in view of the information provided by the request message; and send, via the network interface, a response message indicating whether to join the federated learning process.

25. The client computing node of claim 24, wherein the federated learning circuitry is further configured to implement the method of any one of claims 21 to 22.