Updating federated deep neural networks

Abstract

Federated machine learning systems and techniques efficiently schedule communications for both training and updating neural network models. A computer implemented method, performed by a computing system, includes assigning a plurality of user equipments, UEs, to a federated learning group for a neural network and selecting a subgroup of one or more of the UEs of the federated learning group to provide update information. The method further includes scheduling, for each selected UE of the subgroup, uplink resources for the UEs to provide the update information and receiving, from one or more of the selected UEs of the subgroup using the scheduled uplink resources, respective update information. The method also includes updating, based on the update information, parameters of the neural network and sending, to the plurality of UEs in the federated learning group, an update indication of the updated parameters of the neural network.

Description

UPDATING FEDERATED DEEP NEURAL NETWORKSBACKGROUND AND TECHNICAL PROBLEM

[0001] For 5G advanced and 6G, machine learning (ML) and artificial intelligence (Al), in particular the use of deep neural networks (DNNs), are expected to play an important role. For example, DNNs can render images to support extended reality (XR) use cases, such as virtual reality (VR) and augmented reality (AR).

[0002] Federated learning uses communication between user equipment (UE) executing such applications and the network side, such as the base station and core network, in order facilitate training and updating of the DNNs. Managing these communications effectively can help avoid scheduling conflicts and utilise network bandwidth efficiently, while also retaining the benefits of federated learning. Moreover, a UE can also have data privacy constraints that federated learning can address.SUMMARY

[0003] In a first aspect, the present disclosure provides a computer implemented method, performed by a computing system, the method comprising: assigning a plurality of user equipments, UEs, to a federated learning group for a neural network; selecting a subgroup of one or more of the UEs of the federated learning group to provide update information; scheduling, for each selected UE of the subgroup, uplink resources for the UEs to provide the update information; receiving, from one or more of the selected UEs of the subgroup using the scheduled uplink resources, respective update information; updating, based on the update information, parameters of the neural network; and sending, to the plurality of UEs in the federated learning group, an update indication of the updated parameters of the neural network.

[0004] In some implementations, the update information comprises one or more updated parameter values of the neural network and / or one or more changes of parameter values of the neural network.

[0005] In some implementations, the update information comprises one or more updated parameter values of the neural network and / or one or more changes of parameter values of the neural network.

[0006] In some implementations, the update information comprises one or more gradients of an objective function with respect to parameters of the neural network.

[0007] In some implementations, the method further comprises transmitting a configuration message to the UEs in the federated learning group, wherein, for the subgroup of one or more of the UEs, the configuration message comprises scheduling information allocating the scheduled uplink resources.

[0008] In some implementations, the configuration message provides an identifier associated with the group. In some implementations, the identifier is a radio network temporary identifier, RNTI. In some implementations, sending, to the plurality of UEs in the federated learning group, an update indication comprises carrying out a multi-cast transmission incorporating the identifier.

[0009] In some implementations, the method further comprises receiving, from each of the UEs and prior to the step of assigning, a request to participate in federated learning for the neural network. In some implementations, the request to participate in federated learning comprises UE capability information and / or UE assistance information. In some implementations, assigning the UE to a federated learning group comprises: determining that capability data for the UE and / or local conditions for the UE falls within a range of capabilities and / or local conditions associated with the federated learning group. In some implementations, selecting one or more of the UEs of the federated leaning group to provide update information comprises: selecting UEs based on their capability data and / or local conditions.

[0010] In some implementations, the computing system is a cellular network entity.

[0011] In some implementations, the respective update information is obtained from a respective local update procedure at a selected UE.

[0012] In a further aspect, the present disclosure provides a computer implemented method performed by a user equipment, UE, the method comprising: transmitting, to a network entity, a request to participate in federated learning for a neural network; receiving, in response to the request, a configuration message for a federated learning group, the configuration message comprising an identifier for the federated learning group; using the identifier to identify, from a message received from the network entity, an update indication of updated parameters of the neural network ; utilising the neural network with the updated parameters; and, when the configuration message incorporates uplink scheduling information, transmitting update information to the network entity according to the scheduling information.

[0013] In some implementations, the method further comprises: transmitting, to a network entity, a request to participate in federated learning for a neural network, wherein the configuration message is received in response to the request.

[0014] In some implementations, using the identifier to identify comprises: identifying the update indication in a multicast transmission using the identifier.

[0015] In some implementations, the request for a neural network configuration comprises UE capability information and / or UE assistance information.

[0016] Further aspects of the present disclosure provide systems, apparatus and computer readable media for implementing any of the methods described herein. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] FIG. 1 shows an example system for performing any of the methods described herein;

[0018] FIG. 2 shows a signalling diagram for handling requests for a UE to participate in federated learning;

[0019] FIG. 3 shows a signalling diagram for providing initial update information regarding a DNN operated at a UE;

[0020] FIG. 4 shows a signalling diagram for updating local and federated DNNs;

[0021] FIG. 5 shows a flow diagram of an example network-side method for performing federated learning;

[0022] Fig. 6 shows a flow diagram of an example UE-side method for performing federated learning;

[0023] FIG. 7 shows an example system for performing any of the methods described; and

[0024] FIG. 8 shows an example computer readable medium.DETAILED DESCRIPTION

[0025] This specification describes systems, methods, and apparatus that provide techniques for federated machine learning (FML) which efficiently schedule communications for both training and updating DNN models. Example techniques furthermore address privacy and power constraints, taking into account user equipment (UE) status during the scheduling process. In particular, in example implementations, a group of UEs participate in a federatedlearning process in which not all members of the group provide local updates (thereby reducing usage of uplink bandwidth). Furthermore, in such implementations, the selection of UEs for local update procedures facilitates the scheduling of resources in such a way as to reduce scheduling conflicts while efficiently utilising network capacity. Moreover, in some implementations, when updates are aggregated at the network side, the resulting improvements are multi-cast to the UEs to allow each UE to appropriately implement the improvements at a local DNN operating on that UE; using multi-cast transmission for this state efficiently uses network resources. In general, in some implementations, a network entity directly provides updates to DNNs operating on UEs of a group, but the UEs that provide local updates to the network entity are a proper subgroup of the group. Accordingly, in some implementations the group of UEs are all directly updated by the network entity but do not all provide local updates to the network entity.

[0026] FIG. 1 shows an overview of an example system 100 for implementing federated machine learning (FML) in line with the techniques of the present disclosure. The system includes a plurality of UEs 102A-F, each operating a local DNN model 104A-F. The illustrated system also includes a plurality of network entities 106A, 106B, such as a base station or edge device. Each UE 102A-F is in communication with one of the network entities 106A, 106B, such that the UEs are divided into groups 108A, 108B defined by the network entity 106A, 106B (e.g. cellular network entity) to which they are currently connected. In dual connectivity situations, the Main Node (MN) may define the groups 108 or [ask inventors for alternatives for a DC situation],

[0027] UEs may take various forms and have various capabilities. Examples of UE capabilities include hardware specifications of the UE, such as a processor speed and / or a memory size. Moreover, each UE operates under its own local conditions. Examples of such conditions include one or more of: a current processor and / or memory availability / usage; a current power level / usage; a signal strength at the UE location; and / or a UE temperature.

[0028] Each network entity 106A, 106B maintains a federated DNN 110A, 110B. The network entities 106A, 106B may update DNN 110A, 110B using data from UEs within the group 108A, 108B associated with the particular network entity 106A, 106B. The federated DNN 110A, 110B thereby benefits from updates from multiple UEs, with such updates aggregated and applied to the federated DNNs. During this process, since the UEs 102A-F are provided with local DNNs 104A, 104B, it is not necessary for the individual UEs 102A-F to share data utilised in the training process with the network entities 106A, 106B, thereby protecting privacy and reducing the usage of network resources. That is, each UE 102A-Fcan operate its local DNN 104A-F to obtain inferences without sharing the input data (or output data) with the network entity 106A, 106B. Moreover, in some implementations, the federated DNN 110A are used to provide updates to each local DNN 104A-C in due course.

[0029] The system 100 also includes core network 1 12 in communication with network entities 106A, 106B. The core network maintains and updates a core DNN model 1 14 based on the data provided by the network entities 106A, 106B. In a similar manner to the relationship between the federated DNNs 1 10A, 11 OB and local DNNs 104A-F, the core DNN 1 14 may receive updates from multiple federated DNNs, and may then aggregate the updates and share the results with each individual federated DNN. In particular, the network entities 106A, 106B report federated updates to the federated DNN models 1 10A, 1 10B and those network entities 106A, 106B report their federated updates the core network 112. The core network 1 12 aggregates the updates received from the network entities 106A, 106B to obtain a global update to the global model 114. The core network 112 then provides this global update to the core DNN model 1 14 to the network entities 106A, 106B to further update the federated DNN models 110A, 1 10B. Changes to the federated models 1 10A, 1 10B arising from this process are then transmitted to the UEs 102A-F, which then update local DNN models 104A-F. Many further UEs and network entities which are not shown are also in communication with the core network 1 12 and may implement this procedure for updating federated DNNs. Additional layers of federation may also be implemented (e.g., at a data network, at edge servers, at multiple instances of an application).

[0030] FIG. 2 is a signalling diagram illustrating a process for managing federated learning between a network entity and UEs 102A-C. At a first stage 200, UEs 102 register with at least one network entity 106 to form at least one group 108 (such as group 108A illustrated in FIG. 2) for participating in a federated learning process. A federated DNN configuration is then distributed at stage 300 (illustrated in more detail in Figure 3), updates are received during stage 400 at the network entity from selected UEs 102A, 102B (illustrated in more detail in Figure 4) before these are then redistributed through a further iteration of stage 300. Although 6 UEs are shown in FIG. 1 , FIG. 2 focuses on UEs 102A-C and the teachings can apply to other UEs and additional groups. In some implementations, one or more of the UEs 102A-C are operating multiple local DNNs at a given time. The groups for such DNNs overlap partially, completely, or not at all. As such, a given UE participates, in some examples, simultaneously in a number of groups and / or multiple processes of the kind illustrated in Figure 2.

[0031] Each UE 102A-C transmits a request 220A-C to the network entity 106A to participate in a federated learning process. In the illustrated example, the requests 220A-C aretransmitted as part of a physical uplink shared channel (PUSCH) transmission previously scheduled by the network entity 106A, thereby avoiding conflicts. In other implementations, the requests 220A-C are, for example, transmitted as a message in the non-access stratum (NAS) layer of the protocol stack, for example as information elements (lEs).

[0032] One or more messages may form the basis for a request, and a request may include any of several parameters such as: an explicit request, current DNN-specific capabilities of the UE 102A-C, or DNN-specific parameters, perhaps providing an implicit request.

[0033] In some implementations, the requests 220A-C identify a particular local DNN 104A-C operating at the UE 102A-C, e.g., the request contains an identifier for a particular DNN for which the UE 102A-C wishes to engage in federated learning. In alternatives, the UE 102A-C may identify in the request 220A-C a DNN model which does not yet have a local implementation in place at the UE 102A-C. Alternatively, the requests 220A-C identify a function that a UE 102A-C is requesting, e.g., an image / audio classification function, an image / audio generation function, a network resource prediction function, an augmented reality function, an image / video / audio enhancement function (such as super-resolution and / or denoising), a structure-from-video function, or the like. Based on the identified function, the network entity 106A selects a particular DNN to use from a plurality of available DNNs (for example, the particular DNN may be a federated DNN 110A which the network entity 106A indicates in a transmission to the UE 102A-C to use as a local DNN 104A-C).

[0034] In some examples, each UE 102A-C transmits requests 220A-C according to a local assessment of the parameter or behaviour of an application hosted by the UE. A request 220A-C from a UE 102A-C is triggered, for example, when one or more conditions are satisfied. For example, a request 220A-C can be triggered when a UE 102A-C determines that a local DNN 104A-C is not meeting performance requirements, for example, due to a change in local conditions. For example, if an application running at a given UE 102A-C utilises a local DNN 104A-C and that UE 102A-C recognises that performance of the local DNN 104A-C does not meet requirements, it transmits a request 220A-C to take part in federated learning. In other examples, such requests depend additionally or alternatively on other factors, or may be automatic. Each UE 102A-C may operate independently in assessing its own performance and requesting a local DNN 104A-C running at that device. Alternatively or additionally, when one or more UEs 102A-C report performance issues, the network entity 106A and or core network 112 may operate to inform other UEs of potential issues.

[0035] Alternatively or additionally, a request 220A-C from a UE 102A-C is triggered when a UE that was previously served by another network cell joins a cell of the network entity 106A.

[0036] In some implementations, requests 220A-C to participate in federated learning include UE capability information or UE assistance information as defined by 3GPP indicating one or more capabilities of the requesting UE 102A-C. In some implementations, one or more UEs 102A-C provide UE capability information or UE assistance information separately from a request 220A-C as part of another message, i.e., a non-DNN-specific message. Examples of capability information include UE network and radio capabilities. In some implementations, UEs alternatively or additionally provide information regarding current UE operating conditions in requests 220A-C or as part of an additional message. Such operating conditions include, for example, hardware specifications of the UE, such as a processor speed and / or a memory size.

[0037] Network entity 106A decides whether to accept requests 220A-C to incorporate UEs 102A-C into group 108A at steps 222A-C. In the example shown in Figure 2, network entity 106A accepts all UEs 102A-C into group 108A. Network entity 106A may also reject one or more requests (not shown), and if so each UE 102A-C which has its request refused continues to use its local DNN 104A-C without participating in federated learning. In making this decision, the network entity 106A in some examples assesses the capabilities and / or operating conditions of the UE 102A-C transmitting requests 220A-C. For example, in some implementations, the network entity 106A determines whether the capability data for the UE and / or local conditions for the UE falls within a range of capabilities and / or local conditions associated with the federated learning group 108A and assigns a UE 102A-C to the group 108A if this criteria is met. In implementations such as that shown in Figure 2, the network entity 106A decides individually on each request 220A-C. The network entity 106A may take into account decisions made on previous requests. In other implementations, the network entity 106A consider a group of two or more requests together in order to, for example, prioritize UEs 102A-C with a greater need.

[0038] The network entity 106A associates group 108A with an identifier. In the described embodiments, the identifier is a radio network temporary identifier (RNTI) used for the federated learning process (this will be referred to hereinafter as the “FL_RNTI”).

[0039] The network entity 106A handles further requests from additional UEs (not shown) to join the group 108A at a later time, and recognises when existing UEs leave the group 108A. Thus, the group 108A is dynamic and the FL_RNTI value can be appropriately distributed to each member UE of the dynamic group.

[0040] At step 224 the network entity 106A determines scheduling information for receiving local updates from the UEs 102A-C which have been selected to be part of group 108A. In some implementations, the network entity 106A determines that only a proper subgroup of one or more of the UEs within the group 108A will contribute to the updating of the federated DNN 110A (and thus participate in the process of federated learning which updates local DNNs 104A-C), and thus only this subgroup will be provided with scheduling information for local updates. In the example shown, the network entity assigns 224A, 224B scheduling information to only two UEs 102A and 102B of the three illustrated in group 108A. It therefore does not assign scheduling information to the third UE 102C. For some implementations, regardless of the size of group 108A, the network entity 106A only assigns scheduling information to a strict subgroup of the group 108A. This reduces the potential for scheduling conflicts between UEs 102A-C in the group and / or reduces the overall resources allocated to this scheduling. Nevertheless, UEs without scheduling information may still benefit from the improvements to its local DNN obtained via federated learning.

[0041] In some embodiments, identifying the UEs which will provide local updates (and thus receive uplink scheduling information) includes random selection but in some embodiments such random selection is subject to one or more constraints. In examples, constraints include one or more of: current UE conditions (e.g., battery status); UE type (e.g., static or mobile); and / or user preferences. In some implementations, constraints enforce a suitable variety of such parameters to reduce risk that local updates provided by the selected UEs are biased by the selection process. After identifying a suitable initial set of UEs to comply with the constraints (all UEs within the group 108A can be part of the initial set, for example), the network entity 106A in some implementations applies random selection to select a sub-group with a smaller number of UEs.

[0042] The core network 112 may also provide instructions to the network entity 106A for identifying those UEs which are to take part in providing local updates, or federated learning more generally. In some examples, core network 112 monitors the UEs providing local updates across a number of network entities 106A, 106B. In this way, core network 112 improves the balance of UE information reported for federated learning. For example, core network 112 may instruct network entity 108 to obtain updates from UEs of a particular type or which are engaged with a particular type of traffic (such as UEs with extended Reality & Media (XRM), UEs with a satellite connection, Internet-of-Things (loT) UEs).

[0043] In preferred examples, the scheduling information transmitted to the UEs 102A, 102B provides for these UEs to transmit uplink local model DNN updates via frequency domain multiplexed (FDM), time domain multiplexed (TDM), code domain multiplexed (CDM) and / orspatial domain multiplexed (SDM) techniques including modulations such as OFDM and OTFS. For example, where the same time and frequency resource is used for each UE 102A, 102B to provide updates, the scheduling information provides each UE 102A, 102B with a different scrambling code to allow differentiation. Moreover, in examples, the network entity 106A takes into account transmission scheduling when grouping UEs 102A-C into group 108A, with one approach being to select UEs for a group according to their spatial separation. Selecting UEs for the group 108A with wide spatial separation (in comparison with other UEs in contact with the same network entity 106A) can be implemented to facilitate multi-user multiple input multiple output (MU-MIMO) operation in the provision of local updates from the UEs of the group 108A (or sub-group within the group) to the network entity 106A.

[0044] Network entity 106A transmits configuration messages 226A-C to the UEs 102A-C in group 108A. The network entity 106A, in some implementations, transmits the configuration message 226A-C as part of a radio resource control (RRC) or other layer 3 protocol message. The configuration message 226A-C provides the identifier (e.g., FL_RNTI) associated with the group 108A to which the UE 102A-C has been assigned.

[0045] The configuration message 226A-C may also provide scheduling information for the subgroup of UEs 102A, 102B for which scheduling information was assigned at step 224A-C. In the example shown, UEs 102A and 102B receive configuration messages 226A and 226B that provide scheduling information. The scheduling information allocates uplink resources to the receiving UEs 102A, 102B to provide federated learning updates in due course. Example scheduling information includes the physical uplink shared channel (PUSCH) information used by the UE to provide federated learning updates. Examples of information that can be provided for this purpose include time slots, frequency allocations, configured grant parameters, codes (e.g., scrambling or spreading codes), and antenna ports.

[0046] In some examples, the configuration messages 226A-C also provide update criteria. In some examples, the update criteria define criteria for UEs 102A, 102B to transmit update information to the network entity 106A. For instance, UEs 102A, 102B in some examples transmit update information only if a threshold is satisfied for the significance of the updated parameter values. The threshold, in some examples, defines a value or percentage change in weights which would trigger the transmission of update information. The configuration messages 226A, 226B can provide the threshold to UEs 102A, 102B.

[0047] Moreover, in some examples, update criteria additionally or alternatively apply to the application of updates the network entity 106A transmits to the UEs 102A-C. In suchexamples, the update criteria can indicate circumstances in which the UEs 102A-C may ignore updates received from the network entity 106A (for example, such circumstances may relate to battery level or other local conditions).

[0048] FIG. 3 provides a signalling diagram for a process of providing an initial DNN to the UEs 102A-C. At steps 328A-C, each UE 102A-C provides an indication of current conditions. For example, each UE 102A-C provides a channel quality indicator (CQI) update or performs channel state information (CSI) reporting. This can be performed according to the process defined in 3GPP TS 38.214.

[0049] At step 330, the network entity transmits an update indication to each UE 102A-C. The update indication allows the UE 102A-C to identify the relevant parameters and other details to operate the local DNN 104A-C. On the first occasion this happens, the update indication can be understood as an initial DNN update. This is a multi-cast message using the FL_RNTI described earlier. Since each UE 102A-C has the relevant FL-RNTI from the configuration messages 226A-C, the UEs 102A-C can identify and extract the data in the update indication 330. The network entity 106A performs multi-cast transmission of the update indication 330 based on the CQI / CSI data gathered at steps 328A-C. For example, the network entity 106A performs the multi-cast DNN update 330 according to an assessment of the most challenging current conditions of a UE 102A-C in the group 108A to which the network entity 106A transmits the multi-cast. Where the network entity 106A uses CQI information, the network entity 106A performs multi-cast transmission according to the lowest value of the CQI received from the UEs 102-A in the group 108A. In implementations, network entity 106A controls parameters of the multi-cast transmission based on the CQI / CSI data, and in some implementations such parameters include one or more of: total transmit power, transport block size (TBS), modulation coding scheme (MCS), and code rate.

[0050] In some implementations, the update indication 330 includes an explicit indication of the network structure for the local DNN 104A-C to be executed by the UEs 102A-C. For example, in such implementations the update indication 330 indicates a type and / or structure of each layer of the local DNNs 104A-C, parameter values (i.e., weights and / or biases) for nodes in the local DNNs 104A-C, and / or activation functions used in the local DNNs 104A-C. In some implementations, the update indication 330 includes references to pre-defined DNN layers stored in a memory of the UEs 102A-C. In some such implementations, the update indication 330 includes instructions to modify the pre-defined DNN layers, e.g., updates to weights and / or biases of the predefined layers stored at the UEs 102A-C. The form and structure of the update indication, in some examples, changes in dependence on whether it is an initial DNN update or a subsequent iteration of a DNN update.

[0051] Having received the multi-cast update indication 330, each UE 102A-C updates or establishes its local DNN 104A-C at steps 332A-C to match the federated DNN 110A held by the network entity 106A. The process of updating the local DNNs 104A-C may depend upon the form of update provided at step 330. In some examples, the DNN provided at step 330 replaces an existing local DNN 104A-C or represents the first iteration of a DNN stored by the UE 102A-C as a local DNN 104A-C. In other examples, changes or “deltas” are applied to modify an existing local DNN 104A-C stored at the UE 102A-C.

[0052] FIG. 4 provides a signalling diagram for the operation and updating of the DNN.Having received the update indication 330, each UE may operate the DNN at step 434A-C to carry out local application tasks. Performance of the DNN at step 434A-C is monitored locally.

[0053] Recalling that at step 224A-C, the network entity 106A selected a subgroup of UEs 102A-C to perform federated learning, subsequent local update procedures 436A, 436B at UEs 102A and 102B participate in the remaining process, but any equivalent process at UE 102C which was not selected for federated learning does not take part in providing updates for federated learning. Nevertheless, the skilled person will understand that local update procedures ill also take place at UE 102C in some implementations (illustrated as 436C in Figure 4); with the results of these not being reported to the network entity 106A.

[0054] UEs 102A, 102B and optionally 102C operate local update procedures 436 based on respective output data generated at that UE 102A, 102B (optionally 102C) in operating theDNN at step 434. In some implementations, the update procedure 436 at each UE includes determining gradients of an objective function with respect to parameters (i.e., weights and / or biases) of the local DNNs 104A-C, for example using backpropagation of gradients. In some implementations, the local update procedure 436 includes applying an optimisation routine, such as stochastic gradient descent, to an objective function to determine updates to values of the parameters of the local DNN. The local update procedure 436 is, in some examples, a supervised learning procedure (e.g., based on an objective function comparing DNN outputs to corresponding ground truth data, i.e., a labelled training dataset), a semi-supervised learning procedure (e.g., using a mix of labelled training data and unlabelled training data), or an unsupervised learning procedure (e.g., using unlabelled training data).

[0055] In some implementations, each UE performs local update procedures 436 on the basis not only of the scheduling information provided by the network entity 106A, but also of current conditions. For example, a UE may have thermal or battery constraints that prohibit or make less desirable the running of local update procedure 436 currently. Compute andmemory constraints can change dynamically based on UE current local conditions and so may also influence performance of local update procedure 436 (for example, connectivity between UE and other local peripherals may affect current capabilities). In examples, fixed compute and memory constraints have been taken into account by network entity 106A in previous scheduling.

[0056] UEs generate respective update information from performing local update processes 436. At step 438, each UE 102A, 102B with uplink scheduling information transmits the update information it has generated to the network entity 106A. In particular, UE 102A transmits its update information at step 438A while UE 102B transmits its update information at step 438B. UEs 102A, 102B carry out the transmission of the update information 438 according to the uplink grant scheduling provided in configuration messages 226A, 226B. In some implementations, UE 102A, 102B controls the timing of transmissions at step 438 (e.g., by delaying transmissions) based on one or more predetermined factors such as current conditions. Current conditions include, in examples, conditions at the UE (for example, low battery power or overheating) and / or related to network connectivity.

[0057] In some implementations, the update information transmitted at step 438 includes updated parameter values of the local DNN 104A, 104B obtained at steps 436A, 436B. In other alternative implementations, the update information includes differences between the previous DNN parameters (for example, as provided in step 330) and the updated values, i.e. , the “deltas” determined by the local update procedures 436. In some implementations, the update information includes the local gradients of the objective function with respect to the parameters of the local DNN 104A, 104B.

[0058] In some implementations, the UE 102A, 102B transmits update information only if a threshold is satisfied for the significance of the updated parameter values. The threshold, in some examples, defines a value or percentage change in weights which would trigger the transmission of update information.

[0059] The network entity 106A periodically requests the reporting of update information (i.e., requests the UE to carry out steps 438A, 438B) in some examples. In other examples, the network entity may submit dynamic requests for updates from the UEs 102A, 102B. In still further examples, the UEs 102A, 102B report updates according to a pre-determined schedule (or, in examples, configuration message 226A, 226B schedules reporting of update information by the UEs 102A, 102B) and / or each UE assesses conditions for providing update information (based on local UE conditions such as UE power level).

[0060] UEs 102A-C, in some examples, monitor performance of the DNN in performing tasks and may report any issues encountered. This can be part of the update process though steps 438A, 438B but may also include further messaging focussed on reporting one or more metrics of performance. The further messaging does not directly update the DNN but serves to allow network entity 106A, and its core network 112, to monitor performance levels across the larger system.

[0061] At step 440, the network entity 106A combines the update information from the UEs, for example by averaging them, to determine and apply updates to the federated DNN 110A. In some implementations, a weighted average of the update information from the UEs is utilised, whether the weighting applied to updates from each UE 102A, 102B depends on UE conditions or UE type or how many non-reporting UEs a reporting UE represents, for example. In some implementations application of the updates to the federated DNN 110A comprises replacing the existing parameters of the federated DNN 110A with the (weighted) average parameter values in the update information. In other implementations, previous parameter values of the federated DNN 110A are also included in the generation of a(weighted) average from the received update information. In this way, greater stability of the federated DNN 110A may be achieved in order to minimise the risk of over-fitting the circumstances of one or more UEs which are providing updates.

[0062] Where the update information includes gradients of the loss / objective function, the network entity 106A can average the gradient values over the received sets of update information, and use the average gradient values to determine parameter updates for federated DNN 110A. In some examples, the network entity 106A backpropagates the average gradient values through the federated DNN 110A to determine gradients of the loss function with respect to the parameters of the federated DNN 110A, and uses these gradients to perform an update to the federated DNN 110A parameters, e.g., using a gradient ascent or descent process.

[0063] After the performance of stage 400, stage 300 may repeat, thereby providing a further update indication 330 to each UE 102A-C in order that each local DNN 104A-C benefits from updates to federated DNN 110A. As noted above, the form and structure of the update indication, in some examples, changes in dependence on whether it is an initial DNN update or a subsequent iteration of a DNN update.

[0064] In some implementations, stages 300 and 400 are repeated on multiple occasions, further refining the operation of the local DNNs 104A-C and any other local DNNs 104 for UEs which may have subsequently joined group 108A. At any stage, additional UEs maymake further requests 220 to be considered for the federated learning group and the network entity may assess these in line with the process described with relation to step 222 above. As such, new UEs may become operational within group 108A, some of which, according to the selection of the network entity 106A may report local update information in further iterations of steps 436 and 438. UEs 102A-C may also leave group 108A. For example, a UE 102 may move out of the service area of the network entity 106A or may cease performing tasks associated with the local DNN 104.

[0065] FIG. 5 shows a flow diagram of an example network-side method for performing federated learning. In some implementations, the method is performed by a network entity, such as the network entity 106A described in relation to FIGs. 1 to 4. In general, the operations of the method may be carried out by a computer system.

[0066] At operation 522, the computer system assigns a plurality of UEs to a federated learning group for a neural network and selects a subgroup of one or more of the UEs of the federated learning group to provide update information receives a request for a neural network configuration from a UE. Operation 522 corresponds, in some examples, to the combined effect of steps 222A-C of FIG. 2.

[0067] At operation 524, the computer system schedules, for each selected UE of the subgroup, uplink resources for the UEs to provide the update information. Operation 524 corresponds, in some examples, to the combined effect of steps 224A-C of FIG. 2.

[0068] At operation 538, the computer system receives, from one or more of the selectedUEs of the subgroup using the scheduled uplink resources, respective update information. Operation 538 corresponds, in some examples, to steps 438A-B of FIG. 4.

[0069] At operation 540, the computer system updates, based on the update information, parameters of the neural network. Operation 540 corresponds, in some examples, to step 440 of FIG. 4.

[0070] At operation 530, the computer system sends, to the plurality of UEs in the federated learning group, an update indication of the updated parameters of the neural network. Operation 530 corresponds, in some examples, to step 330 of Figure 3 particularly after the performance of stage 400.

[0071] FIG. 6 shows a flow diagram of an example UE-side method for performing federated learning. The method is performed by a UE, such as the UE described in relation to FIGs. 1 to 4.

[0072] At operation 620, the UE transmits, to a network entity, a request to participate in federated learning for a neural network. Operation 620 corresponds, in some examples, to steps 220A-C of FIG. 2.

[0073] At operation 626, the UE receives, in response to the request, a configuration message for a federated learning group, the configuration message comprising an identifier for the federated learning group. Operation 626 corresponds, in some examples, to steps 226A-C of FIG. 2.

[0074] At operation 630, the UE uses the identifier to identify, from a message received from the network entity, an update indication of updated parameters of the neural network. Operation 630 corresponds, in some examples, to step 330 of FIG. 3.

[0075] At operation 634, the UE utilises the neural network with the updated parameters. Operation 634 corresponds, in some examples, to steps 434A-C of FIG. 4.

[0076] If the configuration message received by the UE incorporated uplink scheduling information, at operation 638 the UE transmits update information to the network entity according to the scheduling information. Operation 638 corresponds, in some examples, steps 438A and 438B of FIG. 4.

[0077] FIG. 7 illustrates a schematic example of a computing system / apparatus 700 for performing any of the methods, operations or processes described and / or for implementing any of the systems, units and / or apparatus as described. The computing system / apparatus 700 shown is an example of a computing device or platform. It will be appreciated by the skilled person that other types of computing devices / systems / platforms can alternatively be used to implement the methods described, such as a distributed computing system. The computing system / apparatus 700 is, in some examples, a UE, a subsystem of a UE, a network node / entity, and / or a subsystem of a network node / entity.

[0078] The apparatus (or system) 700 includes one or more processors 702 (e.g., CPUs).The one or more processors 702 control operation of other components of the system / apparatus 700. The system / apparatus 700 can be part of a computing device, computing system, distributed computing system, cloud computing platform and the like for implementing the functionality of the systems / apparatus and / or one or more methods / operations / processes as described. The one or more processors 702, for example, include a general-purpose processor. The one or more processors 702 can be a single core device or a multiple core device. The one or more processors 702 can include a Central Processing Unit (CPU) or a graphical processing unit (GPU). Alternatively, the one or moreprocessors 702 include specialized processing hardware, for instance a RISC processor or programmable hardware with embedded firmware. In some examples, multiple processors are included. In some embodiments, the one or more processors 702 are part of a distributed computing system such as a cloud computing system and / or cloud computing platform.

[0079] The system / apparatus includes memory system or memory 704 including a working or volatile memory 706. The one or more processors access the volatile memory 706 in order to process data and control the storage of data in memory. The volatile memory 706 can include RAM of any type, for example, Static RAM (SRAM), Dynamic RAM (DRAM), or include Flash memory, such as an SD-Card. In some embodiments, the memory 704 and / or one or more volatile memories 706 include a plurality of memories 704 forming part of the distributed computing system such as the cloud computing system and / or cloud computing platform and the like.

[0080] The system / apparatus includes a non-volatile memory 708. The non-volatile memory 708 stores a set of operation or operating system instructions 709A for controlling the operation of the processors 702 in the form of computer readable instructions and / or software instructions 709B in the form of computer readable instructions, which when executed on the one or more processors 702 cause the processors to implement the methods, processes, operations and / or functionality described. The non-volatile memory 708 can be a memory of any kind such as a Read Only Memory (ROM), a Flash memory, SD drive, a magnetic drive memory or magnetic disc drive memory and the like as the application demands. In some embodiments, the non-volatile memory 708 includes a plurality of non-volatile memories 708 forming part of the distributed computing system such as the cloud computing system and / or cloud computing platform and the like.

[0081] The one or more processors 702 are configured to execute operating instructions 709A and / or software instructions 709B to cause the system / apparatus to perform any of the methods or processes described. The operating instructions 709A include, for example, code (i.e., drivers) relating to the hardware components of the system / apparatus 700, as well as code relating to the basic operation of the system / apparatus 700. Generally speaking, the one or more processors 702 execute one or more instructions of the operating instructions 709A and / or software instructions 709B, which are stored permanently or semi-permanently in the non-volatile memory 708, using the volatile memory 706 to store temporarily data generated during execution of said operating instructions 709A and / or software instructions 709B.

[0082] In some implementations, the one or more processors 702 are connected to a network interface 710 including a transmitter (TX) and a receiver (RX) for communicating over a network with other apparatus and systems. The one or more processors 702 are, in some examples, connected with a user interface (Ul) 712 for user or operator input for instructing or using the computing system and / or for outputting data therefrom. The one or more processors 702 are, in some examples, connected with a display 714 for displaying output to a user or operator. The at least one processor 702, with the at least one memory 704 and the computer program code 709A, 709B are arranged to cause the computing system 700 to at least perform at least the operations, methods, and / or processes, for example as disclosed in relation to the schematic diagrams, flow diagrams or operations as described with any of FIGs 1 to 6 and related features thereof.

[0083] FIG. 8 shows an example non-transitory computer readable medium 800 according to some implementations. The non-transitory medium 800 includes a computer readable storage medium 802 and / or input / output mechanism 804 for enabling a computing system 700 to access said computer-readable medium 802. Although in this example the non- transitory medium is USB stick, this is by way of example only and the disclosure is not so limited, the skilled person would appreciate the non-transitory media 800 could be any other type of computer readable media or medium such as, for example, a CD, a DVD, a USB stick, a blue ray disk, flash drive etc. and / or any other computer readable medium as the application demands. The non-transitory medium 800 stores computer program code, causing an apparatus to perform one or more of the methods, operations, processors of any preceding process for example as disclosed in relation to the flow diagrams and schematic diagrams of Figures 1 to 6 and related features thereof.

[0084] Implementations of the methods or processes described may be realized as in digital electronic circuitry, integrated circuitry, specially designed ASICs (application specific integrated circuits), computer hardware, firmware, software, and / or combinations thereof. These may include computer program products (such as software stored on e.g., magnetic discs, optical disks, memory, Programmable Logic Devices) including computer readable instructions that, when executed by a computer, such as that described in relation to Figure 7, cause the computer to perform one or more of the methods described.

[0085] Any system feature as described may also be provided as a method or process feature, and vice versa. As used herein, means plus function features may be expressed alternatively in terms of their corresponding structure. In particular, method aspects may be applied to system aspects, and vice versa.

[0086] Furthermore, any, some and / or all features in one aspect can be applied to any, some and / or all features in any other aspect, in any appropriate combination. It will also be appreciated that particular combinations of the various features described and defined in any aspects of the disclosure can be implemented and / or supplied and / or used independently.

[0087] Although several embodiments have been shown and described, it would be appreciated by those skilled in the art that changes may be made in these embodiments without departing from the principles of this disclosure, the scope of which is defined in the claims and their equivalents.

Claims

CLAIMS1 . A computer implemented method, performed by a computing system, the method comprising: assigning a plurality of user equipments, UEs, to a federated learning group for a neural network; selecting a subgroup of one or more of the UEs of the federated learning group to provide update information; scheduling, for each selected UE of the subgroup, uplink resources for the UEs to provide the update information; receiving, from one or more of the selected UEs of the subgroup using the scheduled uplink resources, respective update information; updating, based on the update information, parameters of the neural network; and sending, to the plurality of UEs in the federated learning group, an update indication of the updated parameters of the neural network.

2. The method of claim 1 , wherein the update information comprises one or more updated parameter values of the neural network and / or one or more changes of parameter values of the neural network.

3. The method of claim 1 or claim 2, wherein the update information comprises one or more gradients of an objective function with respect to parameters of the neural network.

4. The method of any one of the preceding claims, further comprising transmitting a configuration message to the UEs in the federated learning group, wherein, for the subgroup of one or more of the UEs, the configuration message comprises scheduling information allocating the scheduled uplink resources.

5. The method of claim 4, wherein the configuration message provides an identifier associated with the group.

6. The method of claim 5, wherein the identifier is a radio network temporary identifier, RNTI.

7. The method of claim 5 or claim 6, wherein sending, to the plurality of UEs in the federated learning group, an update indication comprises:carrying out a multi-cast transmission incorporating the identifier.

8. The method of any one of the preceding claims comprising: receiving, from each of the UEs and prior to the step of assigning, a request to participate in federated learning for the neural network.

9. The method of claim 8, wherein: the request to participate in federated learning comprises UE capability information and / or UE assistance information.

10. The method of claim 9, wherein the assigning the UE to a federated learning group comprises: determining that capability data for the UE and / or local conditions for the UE falls within a range of capabilities and / or local conditions associated with the federated learning group.11 . The method of claim 9 or claim 10, wherein the selecting one or more of the UEs of the federated leaning group to provide update information comprises: selecting UEs based on their capability data and / or local conditions.

12. The method of any preceding claim, wherein the computing system is a cellular network entity.

13. The method of any preceding claim, wherein the respective update information is obtained from a respective local update procedure at a selected UE.

14. A computer implemented method performed by a user equipment, UE, the method comprising: transmitting, to a network entity, a request to participate in federated learning for a neural network; receiving, in response to the request, a configuration message for a federated learning group, the configuration message comprising an identifier for the federated learning group; using the identifier to identify, from a message received from the network entity, an update indication of updated parameters of the neural network; utilising the neural network with the updated parameters; andwhen the configuration message incorporates uplink scheduling information, transmitting update information to the network entity according to the scheduling information.

15. The method of claim 14, further comprising: transmitting, to a network entity, a request to participate in federated learning for a neural network, wherein the configuration message is received in response to the request.

16. The method of claim 14 or 15, wherein the using the identifier to identify comprises: identifying the update indication in a multicast transmission using the identifier.

17. The method of any one of claims 14 to 16, wherein the request for a neural network configuration comprises UE capability information and / or UE assistance information.

18. A device comprising: a network interface; one or more processors coupled to the network interface; and a memory storing computer readable instructions that, when executed by the one or more processors, cause the device to perform the method of any of claims 1 to 13.

19. A user equipment comprising: one or more antennae; one or more processors; and a memory, the memory storing computer readable instructions that, when executed by the one or more processors, cause the user equipment to perform the method of any of claims 14 to 17.

20. A computer program product comprising computer readable instructions that, when executed by device comprising a network interface and one or more processors coupled to the network interface, cause the device to perform the method of any of claims 1 to 17.

Images