Devices and methods for a link-aware federated learning system

Abstract

A federated learning, FL, client device (110) and a FL server device (120) for a FL system (100) for training a global machine learning, ML, model (125a) are disclosed. The FL client device (110) is configured to train a local ML model (115a) for generating local ML model data and determine a training progress of training the local ML model (115a). If the training progress is larger than a first threshold value and smaller than a second threshold value, the FL client device (110) is further configured to upload the local ML model data to the FL server device (120), if link conditions between the FL client device (110) and the FL server device (120) are sufficient and predicted to degrade. Otherwise, the FL client device (110) is configured to continue training the local ML model (115a).

Description

[0001] DEVICES AND METHODS FOR A LINK-AWARE FEDERATED LEARNING SYSTEM

[0002] TECHNICAL FIELD

[0003] The present invention relates to machine learning technology. More specifically, the present invention relates to devices and methods for a link-aware federated learning system.

[0004] BACKGROUND

[0005] Federated learning (FL) is a promising technique for machine learning (ML) applications where the data for training models are distributed on a plurality of FL client devices, which may, for instance, be edge devices. The client devices perform local model training and then share their locally-trained models with a FL server device and maybe other devices. The FL server device aggregates the received locally-trained models to obtain a global machine learning model. This process is repeated multiple times until the global ML model achieves the desired performance. In this way, the knowledge that a model learned through local data may be shared with other devices, contributing to a global machine learning model capable of performing tasks on each of the participating devices.

[0006] When deploying FL, for instance, in an industrial environment, due to a non-uniform data distribution, dynamic computational resources and communication conditions, the participating FL client devices may undergo different duration of training and data uploading, with the consequence that the data from the FL client devices may arrive at the FL server device at substantially different times and with different frequencies. Such a behavior poses challenges for the two most popular FL schemes, namely synchronous and asynchronous FL.

[0007] In conventional synchronous FL, the FL server device usually has to wait for receiving model updates from all FL client devices so as to perform model aggregation. Under heterogeneous conditions, such as cooperative robots operating in an industrial environment, the FL server device implementing synchronous FL has to make a trade-off between resource utilization and inclusiveness of information. For example, when the FL server device spends longer time waiting to receive the local models from the FL client devices, fast FL client devices will stay idle after uploading, leading to low utilization of their computational resources. When the waiting time is short, the FL server device will only receive the local model data from fast FL client devices, thus ignoring the knowledge from the slow FL client devices. Asynchronous FL relaxes the time constraints for the FL client devices in that the FL server device may perform aggregation upon receiving a single update. The local model data uploaded by slow FL client devices is referred to as “stale”, which may jeopardize the stability of the global ML model since the local models of the slow FL client devices are trained based on older versions of the global model. Conventional asynchronous FL schemes deal with the problem of the staleness of local model data by using attenuation functions for decreasing the contribution of stale updates. However, these attenuation functions often require a timeconsuming fine-tuning. Moreover, using attenuation functions aims more at reducing the negative impact of stale models, rather than making use of the contribution from slow FL client devices.

[0008] SUMMARY

[0009] It is an objective of the present disclosure to provide improved devices and methods for a link- aware federated learning system.

[0010] The foregoing and other objectives are achieved by the subject matter of the independent claims. Further implementation forms are apparent from the dependent claims, the description and the figures.

[0011] According to a first aspect a federated learning, FL, client device for a FL system for training a global machine learning, ML, model is provided. The FL client device is configured to train a local ML model for generating local ML model data and to determine a training progress of training the local ML model. If the training progress is larger than a first threshold value and smaller than a second threshold value, the FL client device is configured to upload the local ML model data via a communication link to a FL server device, if link conditions of the communication link between the FL client device and the FL server device are sufficient and predicted to degrade. Otherwise, the FL client device is configured to continue training the local ML model.

[0012] The FL client device according to the first aspect allows implementing a FL scheme that both from the perspective of the FL client device as well as from the perspective of the FL server device enables the FL client device to fully contribute to the learning task, even in case of very dynamic communication conditions. The flexibility of the actions of the FL client device is based on detecting and predicting the conditions of the communication link between the FL server device and the FL client device, which allows responding to dynamic link conditions in a timely manner and using beneficial opportunities for uploading the local ML model data via the communication link to the FL server device. This is because, the FL client device according to the first aspect is configured to upload its local ML model data, e.g. the trained local ML model when its training progress lies in an acceptable range (i.e. between the first and second threshold value) and when the link condition at the best during this time period (by postponing upload when the link conditions improve until the link conditions are going to degrade again).

[0013] In a further possible implementation form, the FL client device is configured to determine the training progress of training the local ML model with a target granularity. In an implementation form, the FL client device may be configured to determine the training progress of training the local ML model with a target granularity of low, medium, and high training progress. This allows determining the training progress with a granularity best matched for a given application scenario.

[0014] In a further possible implementation form, the FL client device is configured to upload the local ML model data to the FL server device irrespective of the link conditions, if the training progress is larger than the second threshold value. This allows reducing staleness of the FL client device.

[0015] In a further possible implementation form, the FL client device is configured to continue training the local ML model irrespective of the link conditions, if the training progress is smaller than the first threshold value. This ensures that the FL client device only uploads local ML model data, if this data can make a meaningful contribution to the global ML model.

[0016] In a further possible implementation form, the FL client device is configured to estimate and / or predict the link conditions based on one or more measurements of one or more link metrics. This allows the FL client to efficiently estimate and / or predict the link conditions.

[0017] In a further possible implementation form, the FL client device is configured to measure the one or more link metrics for obtaining the measurements of the one or more link metrics and / or wherein the FL client device is configured to receive the one or more measurements of the one or more link metrics from a further entity and / or wherein the FL client device is configured to receive an estimate and / or a prediction of the link conditions from a further entity. This allows the FL client to efficiently obtain information about the link conditions. In a further possible implementation form, the FL client device is further configured to upload metadata about training the local ML model for generating the local ML model data. This allows the FL server device to apply a weight to the local ML model data provided by the FL client device.

[0018] In a further possible implementation form, the local ML model data comprises one or more local ML model parameters and / or the local ML model. In other words, in an implementation form, the local ML model data may comprise parts of the local ML model or the whole ML model. This allows the FL client device to efficiently provide the local ML model data to the FL server device.

[0019] In a further possible implementation form, the metadata comprises information about a number of training optimizations performed by the FL client device for training the local ML model, information about time spent by the FL client device for training the local ML model and / or information about the size of training data used for training the local ML model. This allows the FL server device to efficiently determine the weight for weighting the local ML model data provided by the FL client device based on the metadata.

[0020] In a further possible implementation form, in response to uploading the local ML model data to the FL server device, the FL client device is configured to receive global ML model data from the FL server device and update the local ML model based on the global ML model data. This allows the FL client device to indirectly receive knowledge from other FL client devices.

[0021] In a further possible implementation form, the FL client device is further configured to receive weighting information from the FL server device and to adjust computational resources of the FL client device for training the local ML model based on the weighting information. This allows adjusting the computational resources used by the FL client device to the computational resources used by the other FL client and thereby make the FL process more efficient and reduce staleness.

[0022] According to a second aspect a method of operating a federated learning, FL, client device for a FL system for training a global machine learning, ML, model is provided. The method comprises the steps of: training a local ML model for generating local ML model data; determining a training progress of training the local ML model; if the training progress is larger than a first threshold value and smaller than a second threshold value, uploading the local ML model data to a FL server device via a communication link, if link conditions of the communication link between the FL client device and the FL server device are sufficient and predicted to degrade, or otherwise continuing training the local ML model.

[0023] The method according to the second aspect of the present disclosure can be performed by the FL client device according to the first aspect of the present disclosure. Thus, further features of the method according to the second aspect of the present disclosure result directly from the functionality of the FL client device according to the first aspect of the present disclosure as well as its different implementation forms and embodiments described above and below.

[0024] According to a third aspect a federated learning, FL, server device for a FL system for training a global machine learning, ML, model is provided. The FL server device is configured to receive from each of a plurality of FL client devices local ML model data and metadata about training a local ML model for generating the local ML model data. Moreover, the FL server device is configured to apply a respective weight based on the metadata to the local ML model data of each FL client device for obtaining weighted local ML model data. The FL server device is further configured to update the global ML model based on the weighted local ML model data from each client device for obtaining updated global ML model data. This allows the FL server device according to the third aspect to aggregate the local ML model data from the plurality of FL client devices.

[0025] In a further possible implementation form, the metadata of each FL client device comprises information about a number of training optimizations performed by respective the FL client device for training the respective local ML model, information about the time spent by the respective FL client device for training the respective local ML model and / or information about the size of training data used for training the local ML model by the respective FL client device. This allows the FL server device to efficiently determine the weight for weighting the local ML model data provided by the FL client device based on the metadata.

[0026] In a further possible implementation form, the FL server device is further configured to share the updated global ML model data with each of the plurality of FL client devices. This allows the sharing of knowledge among FL client devices.

[0027] In a further possible implementation form, the FL server device is further configured to share weighting information with each of the plurality of FL client devices for adjusting computational resources of the respective FL client device for training the respective local ML model based on the weighting information. This allows adjusting the computational resources used by the FL client device to the computational resources used by the other FL client and thereby make the FL process more efficient and reduce staleness.

[0028] According to a fourth aspect a method of operating a federated learning, FL, server device for a FL system for training a global machine learning, ML, model is provided. The method comprises the steps of: receiving from each of a plurality of FL client devices local ML model data and metadata about training a local ML model for generating the local ML model data; applying a weight based on the metadata to the local ML model data of each FL client device for obtaining weighted local ML model data; and updating the global ML model based on the weighted local ML model data for obtaining updated global ML model data.

[0029] The method according to the fourth aspect of the present disclosure can be performed by the FL server device according to the third aspect of the present disclosure. Thus, further features of the method according to the fourth aspect of the present disclosure result directly from the functionality of the FL server device according to the third aspect of the present disclosure as well as its different implementation forms and embodiments described above and below.

[0030] According to a fifth aspect a computer program product is provided, comprising a computer- readable storage medium for storing program code which causes a computer or a processor to perform the method according to the second aspect or the method according to the fourth aspect, when the program code is executed by the computer or the processor.

[0031] Details of one or more embodiments are set forth in the accompanying drawings and the description below. Other features, objects, and advantages will be apparent from the description, drawings, and claims.

[0032] BRIEF DESCRIPTION OF THE DRAWINGS

[0033] In the following, embodiments of the present disclosure are described in more detail with reference to the attached figures and drawings, in which: Fig. 1a shows a federated learning, FL, system according to an embodiment comprising a plurality of FL client devices according to an embodiment and a FL server device according to an embodiment;

[0034] Fig. 1 b shows a federated learning, FL, system according to an embodiment comprising a plurality of FL client devices according to an embodiment and a FL server device according to an embodiment;

[0035] Fig. 2 shows a table illustrating operations implemented by a FL client device according to an embodiment;

[0036] Fig. 3 shows a flow diagram illustrating operations implemented by a FL client device according to an embodiment;

[0037] Fig. 4 shows a flow diagram illustrating operations implemented by a FL server device according to an embodiment;

[0038] Fig. 5 shows a schematic diagram illustrating the different uploading time of FL client devices and the FL server device logging the metadata, for instance, the number of optimizations performed by the FL client devices to obtain local ML model data, provided by the FL client devices;

[0039] Fig. 6 shows a diagram illustrating the adaptation of computational resources of a FL client device according to an embodiment by a FL server device according to an embodiment;

[0040] Figs. 7a-d show signaling diagrams illustrating different embodiments of the interaction between a FL client device and a FL server device in a FL system implemented in a 5G network;

[0041] Fig. 8 shows a flow diagram illustrating a method of operating a FL client device according to an embodiment; and

[0042] Fig. 9 shows a flow diagram illustrating a method of operating a FL server device according to an embodiment. In the following, identical reference signs refer to identical or at least functionally equivalent features.

[0043] DETAILED DESCRIPTION OF THE EMBODIMENTS

[0044] In the following description, reference is made to the accompanying figures, which form part of the disclosure, and which show, by way of illustration, specific aspects of embodiments of the present disclosure or specific aspects in which embodiments of the present disclosure may be used. It is understood that embodiments of the present disclosure may be used in other aspects and comprise structural or logical changes not depicted in the figures. The following detailed description, therefore, is not to be taken in a limiting sense, and the scope of the present disclosure is defined by the appended claims.

[0045] For instance, it is to be understood that a disclosure in connection with a described method may also hold true for a corresponding device or system configured to perform the method and vice versa. For example, if one or a plurality of specific method steps are described, a corresponding device may include one or a plurality of units, e.g. functional units, to perform the described one or plurality of method steps (e.g. one unit performing the one or plurality of steps, or a plurality of units each performing one or more of the plurality of steps), even if such one or more units are not explicitly described or illustrated in the figures. On the other hand, for example, if a specific apparatus is described based on one or a plurality of units, e.g. functional units, a corresponding method may include one step to perform the functionality of the one or plurality of units (e.g. one step performing the functionality of the one or plurality of units, or a plurality of steps each performing the functionality of one or more of the plurality of units), even if such one or plurality of steps are not explicitly described or illustrated in the figures. Further, it is understood that the features of the various exemplary embodiments and / or aspects described herein may be combined with each other, unless specifically noted otherwise.

[0046] Figure 1a shows a federated learning, FL, system 100 for comprising a plurality of FL client devices 110 according to an embodiment in communication with a FL server device 120 according to an embodiment. The FL server device 120 and the plurality of FL client devices 110 are configured to train a global machine learning, ML, model 125a. A further embodiment of the FL system 100 with the FL server device 120 and the plurality of FL client devices 110 in the form of cooperating robot devices 110 in a dynamic industrial environment is illustrated in figure 1b. As illustrated in figure 1a, each FL client device 110 may comprise a processing circuitry 111 and a communication interface 113 for wirelessly communicating with the FL server device 120 via a respective communication link 130. The processing circuitry 111 may be implemented in hardware and / or software and may comprise digital circuitry, or both analog and digital circuitry. Digital circuitry may comprise components such as application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), or general-purpose processors. The FL client device 110 may further comprise a memory 115 configured to store executable program code which, when executed by the processing circuitry 111 , causes the FL client device 110 to perform the functions and methods described herein. As will be described in more detail below, the memory 115 may be further configured to store a local ML model 115a.

[0047] Likewise, the FL server device 120 may comprise a processing circuitry 121 and a communication interface 123 for wirelessly communicating with each of the FL client devices 110 via a respective communication link 130. The processing circuitry 121 may be implemented in hardware and / or software and may comprise digital circuitry, or both analog and digital circuitry. Digital circuitry may comprise components such as application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), or general-purpose processors. The FL server device 120 may further comprise a memory 125 memory configured to store executable program code which, when executed by the processing circuitry 121 , causes the FL server device 120 to perform the functions and methods described herein. The memory 125 may be further configured to store the global ML model 125a as well as the local ML model data received from the plurality of FL client devices 110.

[0048] As will be described in more detail below, each FL client device 110 is configured to train a local ML model 115a, which, as already mentioned above, may be stored in the memory 115, for generating local ML model data and to determine a training progress of training the local ML model 115a.

[0049] If the training progress is larger than a first threshold value (herein also referred to as Emin) and smaller than a second threshold value (herein referred to as Emax), the FL client device 110 is configured to upload the local ML model data via the communication link 130 to the FL server device 120, if the link conditions of the communication link 130 between the FL client device 110 and the FL server device 120 are sufficient and predicted to degrade. Otherwise, i.e. if the link conditions of the communication link 130 between the FL client device 110 and the FL server device 120 are not sufficient or predicted not to degrade, the FL client device 110 is configured to continue training the local ML model. This conditional behavior implemented by each FL client device 110 is illustrated as part of the table shown in figure 2. As further illustrated in figure 2, in an embodiment, each FL client device 110 may be configured to upload the local ML model data to the FL server device 120 irrespective of the link conditions of the respective communication link 130, if the training progress is larger than the second threshold value, i.e. larger than as Emax. In a further embodiment, also illustrated in figure 2, each FL client device 110 is further configured to continue training the local ML model 115a irrespective of the link conditions of the respective communication link, if the training progress is smaller than the first threshold value, i.e. smaller than Eminand, therefore, insufficient for providing a meaningful update of the global ML model 125a.

[0050] In an embodiment, the FL client device 110 is configured to estimate and / or predict the link conditions of the communication link 130 between the FL client device 110 and the FL server device 120 based on one or more measurements of one or more communication link metrics, such as a received signal quality, a packet reception ratio, a SNR, a SI NR, a CQI, a delay, or the like. In an embodiment, the FL client device 110 is configured to measure the one or more link metrics itself for obtaining the measurements of the one or more link metrics. Additionally or alternatively, the FL client device 110 may be configured to receive the one or more measurements of the one or more link metrics from a further entity of the FL system 100, e.g., from one of the other FL client devices 110 or from the FL server device 120. Additionally or alternatively, the FL client device 110 may be configured to receive an estimate and / or a prediction of the link conditions from a further entity (such as the NWDAF 701 in the embodiment of figure 7a) of the FL system 100, e.g., the FL server device 120. More specifically, as will be described in more detail below, in the embodiment shown in figure 7a the NWDAF 701 notifies the application server, i.e. the FL server device 120 (through the NEF) with the predicted link quality. Then, the application server, i.e. the FL server device 120 forwards the predictions to the FL client devices 110. As will be appreciated, in further embodiments, the application server and the FL server device 120 may be implemented as separate entities.

[0051] As will be appreciated and described in more detail in the following, embodiments disclosed herein provide a FL scheme that both from the perspective of the FL client devices 110 as well as from the perspective of the FL server device 120 enables the FL client devices 110 to fully contribute to the learning task, even in case of very dynamic communication conditions. The flexibility of the actions of each FL client device 110 is based on detecting and predicting the conditions of the respective communication link 130 between the FL server device 120 and the respective FL client device 110, which allows responding to dynamic link conditions in a timely manner and using beneficial opportunities for uploading the local ML model data via the respective communication link 130 to the FL server device 120. This is because, as already described above, the FL client device 110 is configured to upload its local ML model data, e.g. the trained local ML model when its training progress lies in an acceptable range (i.e. between the first and second threshold value) and when the link condition is at the best during this time period (by postponing upload when the link conditions improve until the link conditions are going to degrade again).

[0052] Figure 3 shows a flow diagram illustrating operations (some of which already have been described above) implemented by each FL client device 110 according to an embodiment. In a stage 301 the FL client device 110 registers with the FL server device 120 to participate in the FL scheme. In a stage 303 the FL client device 110 starts training its local ML model 115a and generating local ML model data (which in an embodiment may be the local ML model 115a itself).

[0053] In a stage 305 the FL client device 110 is configured to determine in a quantitative manner the training progress and to verify whether the training progress is larger than the first threshold value Emin. If this is the case, the FL client device 110 is configured to proceed with stage 307 or otherwise continue training the local ML model 115a in stage 303 of figure 3.

[0054] In the stage 307 of figure 3 the FL client device 110 is configured to determine whether the training progress is also larger than the second threshold value Emax(which is larger than the first threshold value Emin, i.e. Emax> Emin). If this is the case, the FL client device 110 is configured to proceed with stage 309. Otherwise, the FL client device 110 is configured to check in a stage 310 whether it is a good time for uploading the local ML model data to the FL server device 120, whether the link conditions of the communication link 130 between the FL client device 110 and the FL server device 120 are sufficient and predicted to degrade. If this is the case, the FL client device 110 is configured to proceed with stage 309 or otherwise continue training the local ML model 115a in stage 303 of figure 3.

[0055] In stage 309 of figure 3 the FL client device 110 is configured to upload the local ML model data to the FL server device 120. In response thereto, in a stage 311 of figure 3 the FL client device 110 receives aggregated updated global ML model data from the FL server device 120. As will be described in more detail below, in an embodiment, the FL client device 110 may further receive from the FL server device 120 weighting information, e.g., weight indicators, which is checked by the FL client device 110 in a stage 313 of figure 3. If these weight indicators are not available, the FL client device 110 will return to stage 303 and train the local ML model data taking into account the aggregated updated global ML model data from the FL server device 120. If the weight indicators are available in stage 313 of figure 3, the FL client device 110 may adapt its computational resources and / or its pattern of communication with the FL server device 120 based on these weight indicators in a stage 315 of figure 3 (as will be described in more detail below) and then proceed with training the local ML model data taking into account the aggregated updated global ML model data from the FL server device 120.

[0056] As will be described in the following in the context of figure 4, the FL server device 120 is configured to receive in addition to the local ML model data from each of a plurality of FL client devices 110 metadata about training the respective local ML model 115a for generating the received local ML model data. Based on this metadata the FL server device 110 is configured to determine and apply a weight to the local ML model data of each FL client device 110 for obtaining weighted local ML model data. The FL server device 120 is further configured to update the global ML model 125a based on the weighted local ML model data from each of the FL client devices 110 for obtaining an updated global ML model 125a, i.e. updated global ML model data.

[0057] More specifically, after an initialization stage 401 the FL server device 120 is configured in a stage 403 of figure 4 to receive from the FL client devices 110 the local ML model data together with the metadata about the training, e.g. one or more parameters associated with the training. In an embodiment, the metadata provided by the respective FL client device 110 may comprise information about a number of training optimizations performed by the FL client device 110 for training the local ML model 115a, information about the time spent by the FL client device 110 for training the local ML model 115a and / or information about the size of training data used for training the local ML model 115a by the FL client device 110.

[0058] In a stage 405 of figure 4 the FL server device 120 is configured to determine a respective weight for the local ML model data of each FL client device 110, as will be described in more detail further below. In a stage 407 of figure 4 the FL server device 120 is configured to aggregate the local ML model data from the plurality of FL client devices based on the weights and to update the global ML model 125a based on the aggregated local ML model data.

[0059] In a stage 409 of figure 4 the FL server device 120 decides whether to share the weights determined in stage 405 and used for the aggregation in stage 407 as weighting information with the FL client devices 110. If this is the case, the FL server device 120 is configured to add the weighting information to the updated global ML model data to be returned to the FL client device 110 in a stage 411 of figure 4. Otherwise, the FL server device 120 will in a stage 412 of figure 4 return the updated global ML model data to the FL client device 110 without the weighting information and return to stage 403 of figure 4.

[0060] In an embodiment, the FL client device 110 is configured to determine whether the conditions of the communication link 130 between the FL client device 110 and the FL server device 120 are sufficient in the following way. The FL client device 110 may set the size of the local ML model data to be transmitted as m and may have obtained the predictions of the uplink 130 throughput during the next T time steps (c1;..., cT) of duration D seconds. In this embodiment, the processing circuitry 111 of the FL client device 110 may determine the conditions of the communication link 130 to be sufficient, if the following conditions holds:

[0061] Z[=i ctD > m.

[0062] As already described above, in an embodiment, the FL client device 110 is further configured to determine an optimal transmission window for uploading the local ML model data to the FL server device 120. The completion time of transmission Trtstarting at time step t may be defined as follows:

[0063] For a foreseeable time period {t, t + 1, 1, t + T}, the processing circuitry 111 of the FL client device 110 may be configured to determine t* as the temporal optimal transmission time based on the following equation: t* = arg min TrT. =t,...,t+T In an embodiment, the FL client device 110 is configured to determine the first threshold value (herein referred to as Emin) and the second threshold value (herein referred to as Emax) for determining the training process in the following way. As will be appreciated, in a conventional FL scheme often one parameter (referred to as parameter E) is used defining the number of training iterations a FL client device should perform over local ML model data for optimization. More general than that the FL client device 110 according to an embodiment makes use of a range of values bounded, for instance, by the minimum and maximum number of acceptable iterations. In other words, in an embodiment the first threshold value Eminand the second threshold value Emaxmay be defined as the minimum and maximum number of acceptable iterations. For example, in an embodiment, the first threshold value Eminand the second threshold value Emaxmay be defined as follows: Emin= 0.5 ■ E and Emax= 2 ■ E, wherein, as already mentioned above, E denotes the number of training iterations the FL client device 110 should perform over the local ML model data for training.

[0064] In the following a more detailed embodiment will be described of how the FL server device 120 may determine the weights for weighting and aggregating the local ML model data from each of the FL client devices 110.

[0065] In an embodiment, the processing circuitry 121 of the FL server device 120 may determine the weights based on the computational resources spent by the respective FL client device 110 for training the local ML model and generating the local ML model data based on the following equation: wherein n denotes the total number of FL client devices 110, i.e. the number of devices 110 participating the in the FL scheme, Ptdenotes the number of training optimizations performed by the respective FL client device 110 for generating the uploaded local ML model data and OP denotes the number of training optimizations of uploaded model from the j-th FL client device 110 during the interval of last upload and the current upload of the i-th FL client device 110, as illustrated in figure 5.

[0066] In an embodiment, the FL server device 120 may be configured to determine OP / in the way illustrated in figure 5. More specifically, by way of example, four FL client devices 110 are reporting P (number of optimizations performed to obtain the uploaded model) at each communication. Upon receiving P the server device 120 also registers OP- <- Ptfor all FL client devices j which does not upload at the exact same time. After computing wprogress= — — — ■ for FL client device i, the FL server device 120 resets the registry of OP for FL client device i OP^ <- 0, V; #= i.

[0067] In a further embodiment, the processing circuitry 121 of the FL server device 120 may determine the weight for each FL client device 110 based on the staleness of each FL client device (i.e. how often the respective FL client device 110 is communicating with the FL server device 120 for uploading the local ML model data) based on the following equation:

[0068] ... -Qimtime v" n ’ wherein Qtdenotes the interaction frequency of the i-th FL client device 110 (which is inversely proportional to the training time and uploading time spent by the respective FL client device 110) with the FL server device 120. The interaction frequency may be computed as , h where is the updating interval of the i-th FL client device 110.

[0069] In an embodiment, the FL server device 120 may be configured to use one of the weights described above for performing the model aggregation. In further embodiments, the FL server device 120 may be configured to use combinations of the weights described above also with further weights for determining the final weight used for aggregating the local ML model data uploaded by a respective FL client device 110. For instance, in an embodiment, the FL server device 120 is configured to determine the weight as an average based on the following equation: wherein wdatadenotes a weight based on the size Dtof the local dataset on the i-th FL client device 110 in the following form: Thus, as will be appreciated, embodiments disclosed herein may alleviate the negative impact of staleness and non-optimal usage of resources of the FL client devices 110. For addressing staleness, in an embodiment the weight may be designed purely dependent on the time the FL client device 110 spent on training and communicating with the FL server device 120. When the FL client device 110 spent more time on training or uploading, the weight assigned to the FL client device 110 by the FL server device 120, according to staleness, may be smaller so as to reduce the negative impact of the respective FL client device 110 on the global model 125a, since the respective FL client device 110 has not received updated information from the FL server device 120 for a relatively long time. As will be appreciated, this type of weight (wtime) allows dealing with heterogeneous uploading times caused by unstable communication conditions.

[0070] With respect to an optimized usage of resources by the FL client device 110 the weight may be designed to reflect the training performed by the FL client device 110 to generate the uploaded model. For example, the more time the FL client device 110 spent on training or the more computation actions were performed to optimize the model, the more weight should be assigned to the model provided by that FL client device 110 during aggregation. As will be appreciated, this type of weight (wprogress) allows dealing with the varying computational resources allocated locally at the FL client devices 110 due to the varying resource availability and priority level.

[0071] As already described above in the context of stages 313 and 315 of figure 3, in an embodiment, each FL client device 110 is configured to receive weighting information from the FL server device 120 and to adjust computational resources of the FL client device 110 for training the local ML model 115a based on the weighting information received from the FL server device 120. In an embodiment, before starting the next round of training based on the updated data received from the FL server device 120, the FL client device is configured to compare its contribution to the latest uploaded model (as indicated by the weighting information received from the FL server device 120) and its weight based on share of data (as wdatamentioned above) and adapt its computational resources assigned to the training task respectively. In an embodiment, the FL client device is configured to speed up its training, i.e. increase the computational resources for the training byWdata~Wreceived, if wreceived< wdata, and to slow wreceived down training, i.e. decrease the computational resources for training byWreceived~Wdatajf wreceivedwreceived >wdata,asillustrated by the example in figure 6. Figures 7a-d show signaling diagrams illustrating different embodiments of the interaction between the FL client device 110 and the FL server device 120 for a 5G network implementation of the FL system 100. In figures 7a-d, the link conditions of the communication link 130 between the FL client device 110 and the FL server device 120 is predicted by telecommunication network component NWDAF 701. In figure 7a, the FL server device 120 is outside of the telecommunication network. In figure 7b, the FL server device 120 is integrated as a component of the telecommunication network. In figures 7c and 7d, both options (FL server device 120 integrated in telecommunication network or not) are depicted.

[0072] When starting the FL task, the FL server device 120 requests in a stage 712 subscription to the “Notification on QoS Sustainability Analytics” service to the NWDAF 701 . When joining the FL task, the FL client device 110 sends a participation request to the corresponding FL server device 120 in a stage 711. The FL server device 120 confirms the participation of the FL client device 110 by sending back an acknowledgement in a stage 713 including descriptions of the FL task and task parameters such as Eminand Emax. The FL client device 110 will train the local ML model 115a and also monitor the link quality (see stage 714). When the decision of uploading is made, the FL client device 110 will upload the local ML model data to the FL server device in a stage 717. Thereafter, the FL server device 120 will send back the aggregated global model to the FL client device 110 (see 718), optionally aggregated with weight information.

[0073] Regarding the FL client device 110 obtaining information about the condition of the link 130, three possible implementations are provided in figures 7a-d. In figures 7a and 7b, the link condition is measured or predicted by the entity NWDAF 701 and forwarded to the FL server device 120 periodically (see 715). The FL server device 120 then forwards the link measurements for one or more channel metrics to the FL client device 110 (see 716). In figure 7c, another telecommunication network component DCAF 703 is available and the FL server device 120 can request in a stage 721 the managing component NWDAF 701 to send notifications in a stage 723 to the DCAF 703 so as to enable periodic link condition notifications (see 716) to be sent directly from the telecommunication network to the FL client device 110. In figure 7d, the network managing component NWDAF 701 is equipped with a decision function 733, which takes link conditions to determine transmission action of the FL client device 110. In this case, the FL server device 120 firstly registers with the NWDAF 701 for the subscription of transmission command notification (see 731). The NWDAF 701 then sends the transmission command based on link conditions directly to FL client device 110 (see 735). Figure 8 shows a flow diagram illustrating a method 800 of operating the FL client device 110 of the FL system 100 for training the global ML model 125a. The method 800 comprises a step 801 of training the local ML model for generating local ML model data: moreover, the method 800 comprises a step 803 of determining a training progress of training the local ML model 115a. If the training progress is larger than a first threshold value and smaller than a second threshold value, the method comprises a further step 805a of uploading the local ML model data to the FL server device 120, if the link conditions of the communication link 130 between the FL client device 110 and the FL server device 120 are sufficient and predicted to degrade. Otherwise, i.e. if the link conditions of the communication link 130 between the FL client device 110 and the FL server device 120 are insufficient or predicted not to degrade, the method 800 comprises a further step 805b of continuing training the local ML model 115a.

[0074] As the method 800 can be implemented by each FL client device 110, further features of the method 800 result directly from the functionality of the FL client device 110 and its different embodiments and implementation forms described above and below.

[0075] Figure 9 shows a flow diagram illustrating a method 900 of operating the FL server device 120 for training the global ML model 125a. The method 900 comprises a step 901 of receiving from each of the plurality of FL client devices 110 local ML model data and metadata about training a local ML model 115a for generating the local ML model data. Moreover, the method 900 comprises a step 903 of applying a weight based on the metadata to the local ML model data of each FL client device 110 for obtaining weighted local ML model data. The method 900 further comprises a step 905 of updating the global ML model 125a based on the weighted local ML model data for obtaining updated global ML model data.

[0076] As the method 900 can be implemented by the FL server device 120, further features of the method 900 result directly from the functionality of the FL server device 120 and its different embodiments and implementation forms described above and below.

[0077] The person skilled in the art will understand that the "blocks" ("units") of the various figures (method and apparatus) represent or describe functionalities of embodiments of the present disclosure (rather than necessarily individual "units" in hardware or software) and thus describe equally functions or features of apparatus embodiments as well as method embodiments (unit = step). In the several embodiments provided in the present application, it should be understood that the disclosed system, apparatus, and method may be implemented in other manners. For example, the described embodiment of an apparatus is merely exemplary. For example, the unit division is merely logical function division and may be another division in an actual implementation. For example, a plurality of units or components may be combined or integrated into another system, or some features may be ignored or not performed. In addition, the displayed or discussed mutual couplings or direct couplings or communication connections may be implemented by using some interfaces. The indirect couplings or communication connections between the apparatuses or units may be implemented in electronic, mechanical, or other forms.

[0078] The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one position, or may be distributed on a plurality of network units. Some or all of the units may be selected according to actual needs to achieve the objectives of the solutions of the embodiments.

[0079] In addition, functional units in the embodiments of the invention may be integrated into one processing unit, or each of the units may exist alone physically, or two or more units are integrated into one unit.

Claims

CLAIMS1. A federated learning, FL, client device (110) for a FL system (100) for training a global machine learning, ML, model (125a), wherein the FL client device (110) is configured to: train a local ML model (115a) for generating local ML model data; determine a training progress of training the local ML model (115a); if the training progress is larger than a first threshold value and smaller than a second threshold value, upload the local ML model data to a FL server device (120), if link conditions between the FL client device (110) and the FL server device (120) are sufficient and predicted to degrade, or otherwise, continue training the local ML model (115a).

2. The FL client device (110) of claim 1 , wherein the FL client device (110) is configured to determine the training progress of training the local ML model (115a) with a target granularity.

3. The FL client device (110) of any one of the preceding claims, wherein the FL client device (110) is configured to upload the local ML model data to the FL server device (120) irrespective of the link conditions, if the training progress is larger than the second threshold value.

4. The FL client device (110) of any one of the preceding claims, wherein the FL client device (110) is configured to continue training the local ML model irrespective of the link conditions, if the training progress is smaller than the first threshold value.

5. The FL client device (110) of any one of the preceding claims, wherein the FL client device (110) is configured to estimate and / or predict the link conditions based on one or more measurements of one or more link metrics.

6. The FL client device (110) of claim 5, wherein the FL client device (110) is configured to measure the one or more link metrics for obtaining the measurements of the one or more link metrics and / or wherein the FL client device (110) is configured to receive the one or more measurements of the one or more link metrics from a further entity and / or wherein the FL clientdevice (110) is configured to receive an estimate and / or a prediction of the link conditions from a further entity (701 , 703).

7. The FL client device (110) of any one of the preceding claims, wherein the FL client device (110) is further configured to upload metadata about training the local ML model (115a) for generating the local ML model data.

8. The FL client device (110) of claim 7, wherein the local ML model data comprises one or more local ML model parameters and / or the local ML model (115a).

9. The FL client device (110) of claim 7 or 8, wherein the metadata comprises information about a number of training optimizations performed by the FL client device (110) for training the local ML model (115a), information about the time spent by the FL client device (110) for training the local ML model (115a) and / or information about the size of training data used for training the local ML model (115a).

10. The FL client device (110) of any one of the preceding claims, wherein, in response to uploading the local ML model data to the FL server device (120), the FL client device (110) is configured to receive global ML model data from the FL server device (120) and update the local ML model (115a) based on the global ML model data.

11. The FL client device (110) of claim 10, wherein the FL client device (110) is further configured to receive weighting information from the FL server device (120) and to adjust computational resources of the FL client device (110) for training the local ML model (115a) based on the weighting information.

12. A method (800) of operating a federated learning, FL, client device (110) for a FL system (100) for training a global machine learning, ML, model (125a), wherein the method (800) comprises: training (801) a local ML model (115a) for generating local ML model data; determining (803) a training progress of training the local ML model (115a); if the training progress is larger than a first threshold value and smaller than a second threshold value, uploading (805a) the local ML model data to a FL server device (120), if link conditionsbetween the FL client device (110) and the FL server device (120) are sufficient and predicted to degrade, or otherwise continuing (805b) training the local ML model (115a).

13. A federated learning, FL, server device (120) for a FL system (100) for training a global machine learning, ML, model (125a), wherein the FL server device (120) is configured to: receive from each of a plurality of FL client devices (110) local ML model data and metadata about training a local ML model (115a) for generating the local ML model data; apply a weight based on the metadata to the local ML model data of each FL client device (110) for obtaining weighted local ML model data; and update the global ML model (125a) based on the weighted local ML model data for obtaining updated global ML model data.

14. The FL server device (120) of claim 13, wherein the metadata comprises information about a number of training optimizations performed by the FL client device (110) for training the local ML model (115a), information about the time spent by the FL client device (110) for training the local ML model (115a) and / or information about the size of training data used for training the local ML model (115a) by the respective FL client device (110).

15. The FL server device (120) of claim 13 or 14, wherein the FL server device (120) is further configured to share the updated global ML model data with each of the plurality of FL client devices (110).

16. The FL server device (120) of claim 15, wherein the FL server device (120) is further configured to share weighting information with each of the plurality of FL client devices (110) for adjusting computational resources of the respective FL client device (110) for training the local ML model (115a) based on the weighting information.

17. A method (900) of operating a federated learning, FL, server device (120) for a FL system (100) for training a global machine learning, ML, model (125a), wherein the method (900) comprises: receiving (901) from each of a plurality of FL client devices (110) local ML model data and metadata about training a local ML model (115a) for generating the local ML model data;applying (903) a weight based on the metadata to the local ML model data of each FL client device (110) for obtaining weighted local ML model data; and updating (905) the global ML model (125a) based on the weighted local ML model data for obtaining updated global ML model data.

18. A computer program comprising a computer-readable storage medium for storing program code which causes a computer or a processor to perform the method (800) of claim 12 or the method (900) of claim 17, when the program code is executed by the computer or the processor.

Images