Updating federated deep neural networks
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- GOOGLE LLC
- Filing Date
- 2025-01-23
- Publication Date
- 2026-08-07
Smart Images
Figure CN122535902A_ABST
Abstract
Description
Background Technology
[0001] For 5G Advanced and 6G, the use of machine learning (ML) and artificial intelligence (AI), especially deep neural networks (DNNs), is expected to play a significant 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 utilizes communication between user equipment (UE) performing such applications and network-side components (such as base stations and the core network) to facilitate the training and updating of DNNs. Effectively managing these communications helps avoid scheduling conflicts and efficiently utilizes network bandwidth while preserving the benefits of federated learning. Furthermore, UEs can also address data privacy constraints that federated learning can resolve. Summary of the Invention
[0003] In a first aspect, this disclosure provides a computer-implemented method executed by a computing system, the method comprising: assigning a plurality of user equipment (UEs) to a federated learning group for a neural network; selecting a subgroup of one or more UEs in the federated learning group to provide update information; scheduling uplink resources for each selected UE in the subgroup so that the UE provides update information; receiving corresponding update information from one or more selected UEs in the subgroup using the scheduled uplink resources; updating the parameters of the neural network based on the update information; and issuing an update instruction for the updated parameters of the neural network to the plurality of UEs in the federated learning group.
[0004] In some implementations, the update information includes one or more updated parameter values of the neural network and / or one or more changes in the parameter values of the neural network.
[0005] In some implementations, the update information includes one or more updated parameter values of the neural network and / or one or more changes in the parameter values of the neural network.
[0006] In some implementations, the update information includes one or more gradients of the objective function with respect to the parameters of the neural network.
[0007] In some implementations, the method further includes sending a configuration message to the UEs in the federated learning group, wherein, for a subgroup of one or more UEs, the configuration message includes scheduling information for 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, issuing update instructions to multiple UEs in a federated learning group includes implementing multicast transmissions with identifiers.
[0009] In some implementations, the method further includes receiving a request from each UE in the UE group to participate in federated learning for the neural network before the assignment step. In some implementations, the request to participate in federated learning includes UE capability information and / or UE auxiliary information. In some implementations, assigning a UE to a federated learning group includes determining that the UE's capability data and / or the UE's local conditions fall within the range of capabilities and / or local conditions associated with the federated learning group. In some implementations, selecting one or more UEs in the federated learning group to provide updated information includes selecting a UE based on the UE's capability data and / or local conditions.
[0010] In some implementations, the computing system is a cellular network entity.
[0011] In some implementations, the update information is obtained from the corresponding local update procedure at the selected UE.
[0012] In a further aspect, this disclosure provides a computer-implemented method executed by a user equipment (UE), the method comprising: sending a request to a network entity to participate in federated learning for a neural network; receiving a configuration message for a federated learning group in response to the request, the configuration message including an identifier for the federated learning group; using the identifier to identify an update indication of updated parameters of the neural network from a message received from the network entity; utilizing the neural network having the updated parameters; and when the configuration message incorporates uplink scheduling information, sending update information to the network entity based on the scheduling information.
[0013] In some implementations, the method further includes sending a request to a network entity to participate in federated learning for a neural network, wherein a configuration message is received in response to the request.
[0014] In some implementations, using identifiers for identification includes using identifiers to identify update indications in multicast transmissions.
[0015] In some implementations, the request for neural network configuration includes UE capability information and / or UE assistance information.
[0016] Further aspects of this disclosure provide systems, apparatus, and computer-readable media for implementing any of the methods described herein. Attached Figure Description
[0017] Figure 1 An example system is shown for performing any of the methods described herein; Figure 2 The signaling diagram for processing UE requests to participate in federated learning is shown; Figure 3 A signaling diagram is shown for providing initial update information about the DNN operating at the UE; Figure 4 The signaling diagram for updating local and federated DNNs is shown; Figure 5 A flowchart of an example network-side method for performing federated learning is shown; Figure 6 A flowchart of an example UE-side method for performing federated learning is shown; Figure 7 An example system for performing any of the described methods is shown; and Figure 8 An example computer-readable medium is shown. Detailed Implementation
[0018] This specification describes systems, methods, and apparatuses for providing techniques for federated machine learning (FML) that efficiently schedule communication for both training and updating DNN models. Furthermore, the example techniques address privacy and power constraints while taking into account the user equipment (UE) state during the scheduling process. Specifically, in the example implementation, a group of UEs participates in a federated learning process in which not all members of the group provide local updates (thus reducing uplink bandwidth usage). Moreover, in such an implementation, selecting UEs for the local update process facilitates resource scheduling in a way that reduces scheduling conflicts while efficiently utilizing network capacity. Additionally, in some implementations, when updates are aggregated on the network side, the resulting improvements are multicast to the UEs to allow each UE to appropriately implement the improvements at its local DNN; using multicast transmission for this purpose can efficiently utilize network resources. Generally, in some implementations, the network entity directly provides updates to the DNNs operating on UEs within the group, but the UEs providing local updates to the network entity are appropriate subgroups of the group. Therefore, in some implementations, all UEs in this group are updated directly by the network entity, but not all of them are provided with local updates to the network entity.
[0019] Figure 1An overview of an example system 100 for implementing Federated Machine Learning (FML) according to the technology of this disclosure is shown. The system includes multiple UEs 102A-F, each operating a local DNN model 104A-F. The system shown also includes multiple network entities 106A, 106B, such as base stations or edge devices. Each UE 102A-F communicates with one of the network entities 106A, 106B, such that the UEs are divided into groups 108A, 108B defined by the network entities 106A, 106B to which they are currently connected (e.g., cellular network entities). In the case of dual connectivity, the master node (MN) may define group 108 or [inquire with the inventors for alternatives to the DC case].
[0020] UEs can take various forms and have a variety of capabilities. Examples of UE capabilities include the UE's hardware specifications, such as processor speed and / or memory size. Furthermore, each UE operates under its own local conditions. Examples of such conditions include one or more of the following: current processor and / or memory availability / usage; current power level / usage; signal strength at the UE's location; and / or UE temperature.
[0021] Each network entity 106A, 106B maintains a federated DNN 110A, 110B. Network entities 106A, 106B can use data from UEs within groups 108A, 108B associated with a specific network entity 106A, 106B to update DNNs 110A, 110B. The federated DNNs 110A, 110B thus benefit from updates from multiple UEs, where these updates are aggregated and applied to the federated DNN. During this process, since UEs 102A-F are provided with local DNNs 104A, 104B, each UE 102A-F does not need to share the data used during training with network entities 106A, 106B, thereby protecting privacy and reducing network resource usage. In other words, each UE 102A-F can operate its local DNN 104A-F to obtain inferences without sharing input (or output) data with network entities 106A, 106B. In addition, in some implementations, the federated DNN 110A is used to provide updates to each local DNN 104A-C when appropriate.
[0022] System 100 also includes a core network 112 that communicates with network entities 106A and 106B. The core network maintains and updates a core DNN model 114 based on data provided by network entities 106A and 106B. In a manner similar to the relationship between federated DNNs 110A and 110B and local DNNs 104A-F, the core DNN 114 can receive updates from multiple federated DNNs, and can then aggregate the updates and share the results with each individual federated DNN. Specifically, network entities 106A and 106B report federated updates to federated DNN models 110A and 110B, and those network entities 106A and 106B report their federated updates to the core network 112. The core network 112 aggregates the updates received from network entities 106A and 106B to obtain a global update to the global model 114. Then, core network 112 provides this global update of core DNN model 114 to network entities 106A and 106B to further update federated DNN models 110A and 110B. The changes to federated models 110A and 110B resulting from this process are then sent to UEs 102A-F, which then update their local DNN models 104A-F. Numerous further UEs and network entities (not shown) also communicate with core network 112 and can implement this process for updating the federated DNN. Additional federation layers can also be implemented (e.g., at the data network, at the edge server, or at multiple instances of the application).
[0023] Figure 2 This is a signaling diagram illustrating the process for managing federated learning between network entities and UE 102A-C. In the first phase 200, UE 102 registers with at least one network entity 106 to form at least one group 108 (such as...) for participating in the federated learning process. Figure 2 Group 108A is shown in the diagram. Then, the federated DNN configuration is distributed at stage 300 (in...). Figure 3 (As shown in more detail below), during phase 400, updates are received at the network entity from selected UEs 102A and 102B before these updates are redistributed through further iterations of phase 300. Figure 4 (As shown in more detail below). Although Figure 1 Six UEs are shown, but Figure 2 Focusing on UE 102A-C, these teachings can be applied to other UEs and additional groups. In some implementations, one or more UEs in UE 102A-C operate multiple local DNNs at a given time. The groups used for these DNNs partially overlap, completely overlap, or do not overlap at all. Therefore, in some examples, a given UE participates in multiple groups simultaneously and / or Figure 2 The types of processes shown are multiple.
[0024] Each UE 102A-C sends a request 220A-C to network entity 106A to participate in the federated learning process. In the example shown, request 220A-C is sent as part of a Physical Uplink Shared Channel (PUSCH) transmission previously scheduled by network entity 106A, thereby avoiding collisions. In other implementations, request 220A-C may be sent, for example, as a message in the Non-Access Stratum (NAS) layer of the protocol stack, such as as an Information Element (IE).
[0025] One or more messages may form the basis of a request, and the request may include any of the following parameters: explicit request, current DNN-specific capability of UE 102A-C, or DNN-specific parameters, which may provide an implicit request.
[0026] In some implementations, Request 220A-C identifies a specific local DNN 104A-C operating at UE 102A-C, for example, requesting an identifier for a specific DNN that UE 102A-C wishes to participate in federated learning. Alternatively, Request 220A-C may identify in Request 220A-C a DNN model for which there is not yet a suitable local implementation. Alternatively, Request 220A-C identifies the functionality requested by UE 102A-C, such as image / audio classification, image / audio generation, network resource prediction, augmented reality, image / video / audio enhancement (e.g., super-resolution and / or denoising), structure-from-video recovery, etc. Based on the identified functions, network entity 106A selects a specific DNN to use from multiple available DNNs (e.g., the specific DNN may be federated DNN 110A, which network entity 106A instructs to be used as local DNN 104A-C in the transmission to UE 102A-C).
[0027] In some examples, each UE 102A-C sends request 220A-C based on a local evaluation of the parameters or behavior of the applications hosted by the UE. For example, request 220A-C is triggered from UE 102A-C when one or more conditions are met. For instance, request 220A-C may be triggered when UE 102A-C determines that the local DNN 104A-C does not meet performance requirements (e.g., due to changes in local conditions). For example, if an application running at a given UE 102A-C utilizes the local DNN 104A-C, and this UE 102A-C recognizes that the performance of the local DNN 104A-C is not meeting requirements, it sends request 220A-C to participate in federated learning. In other examples, such requests may additionally or alternatively depend on other factors, or may be automatic. Each UE 102A-C may operate independently in evaluating its own performance and requesting the local DNN 104A-C running at this device. Alternatively or additionally, when one or more UEs 102A-C report a performance problem, network entity 106A and / or core network 112 may operate to notify other UEs of the potential problem.
[0028] Alternatively or additionally, when a UE previously served by another network cell joins the cell of network entity 106A, request 220A-C from UE 102A-C is triggered.
[0029] In some implementations, the request 220A-C for participating in federated learning includes UE capability information or UE auxiliary information, as defined by 3GPP, indicating one or more capabilities of the UE 102A-C making the request. In some implementations, one or more UE 102A-Cs provide UE capability information or UE auxiliary information separately from the 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, the UE alternatively or additionally provides information about its current operating condition in the request 220A-C or as part of an additional message. This operating condition includes, for example, the UE's hardware specifications, such as processor speed and / or memory size.
[0030] At steps 222A-C, network entity 106A decides whether to accept request 220A-C to incorporate UE 102A-C into group 108A. Figure 2In the example shown, network entity 106A accepts all UEs 102A-C into group 108A. Network entity 106A can also reject one or more requests (not shown), and if so, each UE 102A-C whose request is rejected continues to use its local DNN 104A-C without participating in federated learning. In making this decision, in some examples, network entity 106A evaluates the capabilities and / or operating conditions of the UE 102A-C that sent request 220A-C. For example, in some implementations, network entity 106A determines whether the capability data and / or local conditions for the UE fall within the range of capabilities and / or local conditions associated with federated learning group 108A, and if this criterion is met, assigns UE 102A-C to group 108A. In cases such as... Figure 2 In the implementation shown, network entity 106A makes a decision on each request 220A-C individually. Network entity 106A may consider decisions made on previous requests. In other implementations, network entity 106A considers a group of two or more requests together, for example, prioritizing UEs 102A-C with greater needs.
[0031] Network entity 106A associates group 108A with an identifier. In the described embodiment, the identifier is a Radio Network Temporary Identifier (RNTI) used for the federated learning process (hereafter referred to as "FL_RNTI").
[0032] Network entity 106A handles further requests from additional UEs (not shown) to join group 108A later and identifies when existing UEs leave group 108A. Therefore, group 108A is dynamic and FL_RNTI values can be appropriately distributed to each member UE of the dynamic group.
[0033] At step 224, network entity 106A determines scheduling information for receiving local updates from UEs 102A-C, which have been selected as part of group 108A. In some implementations, network entity 106A determines that only appropriate subgroups of one or more UEs within group 108A will contribute to the update of the federated DNN 110A (and thus participate in the federated learning process of updating the local DNN 104A-C), and therefore only this subgroup will be provided with scheduling information for local updates. In the example shown, the network entity assigns scheduling information 224A and 224B to only two of the three UEs shown in group 108A, UEs 102A and 102B. Therefore, it does not assign scheduling information to the third UE 102C. In some implementations, regardless of the size of group 108A, network entity 106A only assigns scheduling information to strict subgroups of group 108A. This reduces the likelihood of scheduling conflicts between UEs 102A-C in the group and / or reduces the total resources allocated to this scheduling. However, UEs without scheduling information can still benefit from improvements to their local DNNs obtained through federated learning.
[0034] In some embodiments, identifying the UE that will provide local updates (and thus receive uplink scheduling information) involves random selection; however, in some embodiments, this random selection is subject to one or more constraints. In examples, constraints include one or more of the following: current UE conditions (e.g., battery state); UE type (e.g., static or mobile); and / or user preferences. In some implementations, constraints enforce appropriate multiple such parameters to reduce the risk of bias in the local updates provided by the selected UEs due to the selection process. After identifying a suitable initial group of UEs that meet the constraints (e.g., all UEs within group 108A may be part of the initial group), in some implementations, network entity 106A applies random selection to select a subgroup with a smaller number of UEs.
[0035] Core network 112 can also provide instructions to network entity 106A to identify which UEs will participate in providing local updates or, more generally, in federated learning. In some examples, core network 112 monitors UEs providing local updates across multiple network entities 106A, 106B. In this way, core network 112 improves the balance of UE information for federated learning reports. For example, core network 112 can instruct network entity 108 to obtain updates from specific types of UEs or UEs participating in specific types of services (such as UEs with Extended Reality and Media (XRM), UEs with satellite connectivity, and Internet of Things (IoT) UEs).
[0036] In a preferred example, the scheduling information sent to UEs 102A and 102B provides these UEs with the means to transmit uplink local model DNN updates via frequency domain multiplexing (FDM), time domain multiplexing (TDM), code domain multiplexing (CDM), and / or spatial domain multiplexing (SDM) techniques, including modulation such as OFDM and OTFS. For example, if the same time and frequency resources are used for each UE 102A and 102B to provide updates, the scheduling information provides different scrambling codes to each UE 102A and 102B to allow for differentiation. Furthermore, in the example, when UEs 102A-C are grouped into group 108A, network entity 106A considers transmission scheduling, one approach being to select UEs for the group based on their spatial separation. Selecting a UE with a wide spatial spacing for group 108A (compared to other UEs in contact with the same network entity 106A) can be implemented to facilitate multi-user multiple-input multiple-output (MU-MIMO) operations in local updates from UEs in group 108A (or subgroups within the group) to network entity 106A.
[0037] Network entity 106A sends configuration message 226A-C to UE 102A-C in group 108A. In some implementations, network entity 106A sends configuration message 226A-C as part of a Radio Resource Control (RRC) or other Layer 3 protocol message. Configuration message 226A-C provides an identifier (e.g., FL_RNTI) associated with the group 108A to which UE 102A-C has been assigned.
[0038] Configuration messages 226A-C can also provide scheduling information to subgroups of UEs 102A and 102B for which scheduling information was assigned in steps 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 receiving UEs 102A and 102B to provide federated learning updates when appropriate. Example scheduling information includes 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 codes or spreading codes), and antenna ports.
[0039] In some examples, configuration messages 226A-C also provide update criteria. In some examples, the update criteria define the standards used by UEs 102A and 102B to send update information to network entity 106A. For example, in some examples, UEs 102A and 102B only send update information if the importance of the updated parameter value meets a threshold. In some examples, the threshold defines a weighted value or percentage change that triggers the transmission of update information. Configuration messages 226A and 226B can provide the threshold to UEs 102A and 102B.
[0040] Furthermore, in some examples, the update standard is applied alternatively or in lieu of updates sent by network entity 106A to UE 102A-C. In such examples, the update standard may indicate situations where UE 102A-C may ignore updates received from network entity 106A (e.g., such situations may be related to battery level or other local conditions).
[0041] Figure 3 A signaling diagram is provided for the procedure of providing the initial DNN to UE 102A-C. At step 328A-C, each UE 102A-C provides an indication of the current conditions. For example, each UE 102A-C provides a Channel Quality Indicator (CQI) update or performs a Channel State Information (CSI) report. This can be performed according to the procedure defined in 3GPP TS 38.214.
[0042] At step 330, the network entity sends an update indication to each UE 102A-C. The update indication allows UE 102A-C to identify relevant parameters and other details to operate the local DNN 104A-C. Upon first occurrence, the update indication can be interpreted as an initial DNN update. This is a multicast message using the FL_RNTI described earlier. Since each UE 102A-C has a relevant FL_RNTI from configuration messages 226A-C, UE 102A-C can identify and extract the data in update indication 330. Network entity 106A performs the multicast transmission of update indication 330 based on the CQI / CSI data collected at steps 328A-C. For example, network entity 106A performs multicast DNN update 330 based on an assessment of the most challenging current conditions for UE 102A-C in group 108A to which network entity 106A is sending multicasts. When network entity 106A uses CQI information, it performs multicast transmission based on the lowest CQI value received from UE 102-A in group 108A. In some implementations, network entity 106A controls multicast transmission parameters based on CQI / CSI data, and in some implementations, these parameters include one or more of the following: total transmit power, transport block size (TBS), modulation and coding scheme (MCS), and code rate.
[0043] In some implementations, update instruction 330 includes an explicit indication of the network structure of the local DNN 104A-C to be performed by UE 102A-C. For example, in such implementations, update instruction 330 indicates the type and / or structure of each layer of the local DNN 104A-C, the parameter values (i.e., weights and / or biases) for nodes in the local DNN 104A-C, and / or the activation function used in the local DNN 104A-C. In some implementations, update instruction 330 includes a reference to a predefined DNN layer stored in the memory of UE 102A-C. In some such implementations, update instruction 330 includes instructions to modify the predefined DNN layer, such as updating the weights and / or biases of a predefined layer stored at UE 102A-C. In some examples, the form and structure of the update instruction change depending on whether it is an initial DNN update or a subsequent iteration of a DNN update.
[0044] Upon receiving a multicast update instruction 330, each UE 102A-C updates or builds its local DNN 104A-C at step 332A-C to match the federal DNN 110A held by network entity 106A. The process of updating the local DNN 104A-C may depend on the form of the update provided at step 330. In some examples, the DNN provided at step 330 replaces the existing local DNN 104A-C, or the first iteration of the DNN stored by UE 102A-C is represented as the local DNN 104A-C. In other examples, a change or "increment" is applied to modify the existing local DNN 104A-C stored at UE 102A-C.
[0045] Figure 4 A signaling diagram for DNN operation and updates is provided. Upon receiving update instruction 330, each UE can operate the DNN at steps 434A-C to implement local application tasks. Local monitoring of DNN performance at steps 434A-C is performed.
[0046] Recalling steps 224A-C, network entity 106A selected a subgroup of UE 102C to perform federated learning. Subsequent local update procedures 436A and 436B at UEs 102A and 102B participate in the remaining procedures, but any equivalent procedures at UE 102C that were not selected for federated learning do not participate in providing updates for federated learning. However, those skilled in the art will understand that in some implementations, the local update procedure will also occur at UE 102C (in...). Figure 4 The results are shown as 436C; however, these results were not reported to network entity 106A.
[0047] UEs 102A, 102B, and optionally 102C operate the local update process 436 based on the corresponding output data generated at each UE 102A, 102B (optionally 102C) when operating the DNN at step 434. In some implementations, the update process 436 at each UE includes determining the gradient of the objective function with respect to the parameters (i.e., weights and / or biases) of the local DNN 104A-C, for example, using backpropagation of gradients. In some implementations, the local update process 436 includes applying optimization routines, such as stochastic gradient descent, to the objective function to determine updates to the values of the parameters of the local DNN. In some examples, the local update process 436 is a supervised learning process (e.g., based on an objective function that compares the DNN output with corresponding ground truth data (i.e., labeled training dataset), a semi-supervised learning process (e.g., using a mixture of labeled and unlabeled training data), or an unsupervised learning process (e.g., using unlabeled training data).
[0048] In some implementations, each UE performs the local update procedure 436 not only based on the scheduling information provided by network entity 106A, but also on its current conditions. For example, a UE may have thermal constraints or battery constraints that prevent the current execution of the local update procedure 436 or make its execution undesirable. Computational and memory constraints can change dynamically based on the UE's current local conditions and can therefore also affect the performance of the local update procedure 436 (e.g., connectivity between the UE and other local peripherals can affect current capabilities). In this example, fixed computational and memory constraints have already been considered by network entity 106A in a previous scheduling.
[0049] The UE generates corresponding update information according to the execution of local update procedure 436. At step 438, each UE 102A, 102B with uplink scheduling information sends its generated update information to network entity 106A. Specifically, UE 102A sends its update information at step 438A, while UE 102B sends its update information at step 438B. UE 102A, 102B implement the transmission of update information 438 according to the uplink grant scheduling provided in configuration messages 226A, 226B. In some implementations, at step 438, UE 102A, 102B controls the timing of the transmission based on one or more predetermined factors such as current conditions (e.g., by delaying transmission). In the example, current conditions include conditions at the UE (e.g., low battery or overheating) and / or conditions related to network connectivity.
[0050] In some implementations, the update information sent at step 438 includes updated parameter values of the local DNNs 104A and 104B obtained at steps 436A and 436B. In other alternative implementations, the update information includes the difference between the previous DNN parameters (e.g., as provided in step 330) and the updated values, i.e., the "increment" determined by the local update process 436. In some implementations, the update information includes the local gradient of the objective function with respect to the parameters of the local DNNs 104A and 104B.
[0051] In some implementations, UE102A and 102B only send update information if the importance of the updated parameter value meets a threshold. In some examples, the threshold defines a weighted value or percentage change that triggers the transmission of update information.
[0052] In some examples, network entity 106A periodically requests reports of update information (i.e., requests the UE to perform steps 438A, 438B). In other examples, the network entity may submit dynamic requests for updates from UEs 102A, 102B. In a further example, UEs 102A, 102B report updates according to a predetermined schedule (or, in this example, configuration messages 226A, 226B schedule the reporting of update information by UEs 102A, 102B), and / or each UE evaluates the conditions used to provide update information (based on local UE conditions, such as UE power level).
[0053] In some examples, UE 102A-C monitors the performance of the DNN while performing tasks and can report any problems encountered. This can be part of the update process performed via steps 438A and 438B, but can also further include further messaging focused on reporting one or more performance metrics. This further messaging does not directly update the DNN, but is used to allow network entity 106A and its core network 112 to monitor performance levels on the larger system.
[0054] At step 440, network entity 106A combines update information, for example, by averaging update information from UEs, to determine and apply updates to federated DNN 110A. In some implementations, a weighted average of update information from UEs is used, for example, depending on 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. In some implementations, applying updates to federated DNN 110A includes replacing existing parameters of federated DNN 110A with (weighted) average parameter values from the update information. In other implementations, previous parameter values of federated DNN 110A are also included in the (weighted) average generated based on the received update information. In this way, greater stability of federated DNN 110A can be achieved to minimize the risk of overfitting the environment of one or more UEs providing updates.
[0055] When the update information includes the gradients of the loss / objective function, network entity 106A can average the gradient values over multiple sets of received update information and use the average gradient values to determine the parameter updates for the federated DNN 110A. In some examples, network entity 106A backpropagates the average gradient values through the federated DNN 110A to determine the gradients of the loss function with respect to the parameters of the federated DNN 110A, and uses these gradients to perform updates to the parameters of the federated DNN 110A, for example, using gradient ascent or descent processes.
[0056] After execution phase 400, phase 300 can be repeated, thereby providing each UE 102A-C with further update instructions 330 so that each local DNN 104A-C benefits from the update of the federated DNN 110A. As mentioned above, in some examples, the form and structure of the update instructions change depending on whether it is the initial DNN update or a subsequent iteration of the DNN update.
[0057] In some implementations, stages 300 and 400 are repeated at multiple points to further refine the operation of local DNNs 104A-C and any other local DNNs 104 for UEs that may subsequently join group 108A. At any stage, an additional UE may make a further request 220 to be considered for use in the federated learning group, and the network entity may evaluate these requests according to the process described above regarding step 222. Thus, a new UE may become operational within group 108A, and some of the new UEs may report local update information in further iterations of steps 436 and 438, depending on the selection of network entity 106A. UEs 102A-C may also leave group 108A. For example, UE 102 may be moved out of the service area of network entity 106A, or may cease performing tasks associated with local DNN 104.
[0058] Figure 5 A flowchart of an example network-side method for performing federated learning is shown. In some implementations, the method consists of, for example, [details about...]. Figures 1 to 4 The network entity described in network entity 106A is used to execute the method. Generally, the operation of the method can be implemented by a computer system.
[0059] At operation 522, the computer system assigns multiple UEs to a federated learning group for the neural network and selects one or more subgroups of UEs within the federated learning group to provide update information and receive requests for neural network configuration from the UEs. In some examples, operation 522 is related to... Figure 2 The combined effect of steps 222A-C corresponds to this.
[0060] At operation 524, the computer system schedules uplink resources for each selected UE in the subgroup so that the UE can provide updated information. In some examples, operation 524 is related to... Figure 2 The combined effect of steps 224A-C corresponds to this.
[0061] At operation 538, the computer system uses the scheduled uplink resources to receive appropriate update information from one or more of the selected UEs in the subgroup. In some examples, operation 538 is related to... Figure 4 Steps 438A-B correspond to each other.
[0062] At operation 540, the computer system updates the parameters of the neural network based on the updated information. In some examples, operation 540 is related to... Figure 4 This corresponds to step 440.
[0063] At operation 530, the computer system issues updated parameters of the neural network to multiple UEs in the federated learning group. In some examples, operation 530 is specifically after the execution of phase 400. Figure 3 This corresponds to step 330.
[0064] Figure 6 A flowchart of an example UE-side method for performing federated learning is shown. This method is performed by the UE (such as regarding...). Figures 1 to 4 The UE described is executed.
[0065] At operation 620, the UE sends a request to the network entity to participate in federated learning for the neural network. In some examples, operation 620 is related to... Figure 2 The steps 220A-C correspond to each other.
[0066] At operation 626, the UE receives a configuration message for the federated learning group in response to a request. This configuration message includes an identifier for the federated learning group. In some examples, operation 626 is related to... Figure 2 The steps 226A-C correspond to each other.
[0067] At operation 630, the UE uses an identifier to identify an update indication of the updated parameters of the neural network from messages received from network entities. In some examples, operation 630 is related to... Figure 3 This corresponds to step 330.
[0068] At operation 634, the UE utilizes a neural network with updated parameters. In some examples, operation 634 is... Figure 4 The steps 434A-C correspond to each other.
[0069] If the configuration message received by the UE includes uplink scheduling information, then at operation 638, the UE sends update information to the network entity based on the scheduling information. In some examples, operation 638 and... Figure 4 Steps 438A and 438B correspond to each other.
[0070] Figure 7A schematic example of a computing system / equipment 700 is shown for performing any of the described methods, operations, or processes and / or for implementing any of the systems, units, and / or apparatuses as described. The computing system / equipment 700 shown is an example of a computing device or platform. Those skilled in the art will understand that other types of computing devices / systems / platforms can be used alternatively to implement the described methods, such as distributed computing systems. In some examples, the computing system / equipment 700 is a UE, a subsystem of the UE, a network node / entity, and / or a subsystem of a network node / entity.
[0071] Equipment (or system) 700 includes one or more processors 702 (e.g., CPUs). The one or more processors 702 control the operation of other components of the system / equipment 700. The system / equipment 700 may be part of a computing device, computing system, distributed computing system, cloud computing platform, etc., for implementing the functionality of the system / equipment and / or one or more methods / operations / processes as described. For example, the one or more processors 702 include general-purpose processors. The one or more processors 702 may be single-core or multi-core devices. The one or more processors 702 may include a central processing unit (CPU) or a graphics processing unit (GPU). Alternatively, the one or more processors 702 include dedicated processing hardware, such as 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.
[0072] The system / equipment includes a memory system or memory 704, which includes working memory or volatile memory 706. One or more processors access the volatile memory 706 to process data and control the storage of data in the memory. The volatile memory 706 may include any type of RAM, such as static RAM (SRAM), dynamic RAM (DRAM), or may include flash memory, such as an SD card. In some embodiments, memory 704 and / or one or more volatile memories 706 comprise a plurality of memories 704 forming part of a distributed computing system such as a cloud computing system and / or a cloud computing platform.
[0073] The system / equipment includes non-volatile memory 708. Non-volatile memory 708 stores computer-readable instructions in the form of an operating or operating system instruction set 709A for controlling the operation of processor 702 and / or computer-readable instructions 709B for causing the processor to implement the described methods, processes, operations, and / or functionalities when executed on one or more processors 702. Depending on the application requirements, non-volatile memory 708 can be any type of memory, such as read-only memory (ROM), flash memory, SD drive, magnetic drive memory, or disk drive memory. In some embodiments, non-volatile memory 708 includes multiple non-volatile memories 708 forming part of a distributed computing system such as a cloud computing system and / or cloud computing platform.
[0074] One or more processors 702 are configured to execute operation instructions 709A and / or software instructions 709B to cause the system / equipment to perform any of the described methods or processes. Operation instructions 709A include, for example, code related to hardware components of the system / equipment 700 (i.e., drivers), and code related to the basic operation of the system / equipment 700. Generally, one or more processors 702 execute one or more of the operation instructions 709A and / or software instructions 709B, which are persistently or semi-persistently stored in non-volatile memory 708, using volatile memory 706 to temporarily store data generated during the execution of the operation instructions 709A and / or software instructions 709B.
[0075] In some implementations, one or more processors 702 are connected to a network interface 710, which includes a transmitter (TX) and a receiver (RX) for communicating with other equipment and systems over a network. In some examples, one or more processors 702 are connected to a user interface (UI) 712 for user or operator input to instruct or use the computing system and / or output data therefrom. In some examples, one or more processors 702 are connected to a display 714 for displaying output to a user or operator. At least one processor 702, along with at least one memory 704 and computer program code 709A, 709B, are arranged to cause the computing system 700 to perform at least at least one operation, method, and / or process, for example, as per [reference to...]. Figures 1 to 6 The diagrams, flowcharts, or operations described in any of the above and their related features are disclosed.
[0076] Figure 8An example non-transitory computer-readable medium 800 according to some implementations is shown. The non-transitory medium 800 includes a computer-readable storage medium 802 and / or an input / output mechanism 804 to enable a computing system 700 to access the computer-readable medium 802. Although in this example the non-transitory medium is a USB stick, this is merely an example, and this disclosure is not limited thereto. Those skilled in the art will understand that the non-transitory medium 800 can be any other type of computer-readable medium or medium, such as a CD, DVD, USB stick, Blu-ray disc, flash drive, etc., and / or any other computer-readable medium as required by the application. The non-transitory medium 800 stores computer program code, thereby enabling the device to perform, for example, [actions related to...]. Figures 1 to 6 The flowcharts and diagrams and their associated features disclose one or more of the methods, operations, or processors of any prior process.
[0077] The described methods or processes can be implemented as digital electronic circuit systems, integrated circuit systems, 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, for example, disks, optical discs, memory, programmable logic devices), which include computer-readable instructions, which are configured by means of, for example, information about… Figure 7 When the computer is executed, it causes the computer to perform one or more of the methods described.
[0078] Any system feature described can also be provided as a method or process feature, and vice versa. As used herein, apparatus plus functional features can alternatively be expressed according to their corresponding structures. In particular, method aspects can be applied to system aspects, and vice versa.
[0079] Furthermore, any, some, and / or all features of one aspect may be applied in any appropriate combination to any, some, and / or all features of any other aspect. It should also be understood that specific combinations of the various features described and defined in any aspect of this disclosure may be independently implemented and / or supplied and / or used.
[0080] Although several embodiments have been shown and described, those skilled in the art will understand that changes may be made to these embodiments without departing from the principles of this disclosure, the scope of which is defined in the claims and their equivalents.
Claims
1. A computer-implemented method executed by a computing system, the method comprising: Assign multiple user equipment (UEs) to federated learning groups for neural networks; Select a subgroup of one or more UEs from the federated learning group to provide updated information; Uplink resources are scheduled for each selected UE in the subgroup so that the UE can provide the update information; The scheduled uplink resources are used to receive corresponding update information from one or more of the selected UEs in the subgroup; The parameters of the neural network are updated based on the updated information; as well as The updated parameters of the neural network are sent to the plurality of UEs in the federated learning group.
2. The method of claim 1, wherein the update information includes one or more updated parameter values of the neural network and / or one or more changes in the parameter values of the neural network.
3. The method of claim 1 or claim 2, wherein the update information includes one or more gradients of the objective function with respect to the parameters of the neural network.
4. The method as described in any of the preceding claims, further comprising sending a configuration message to the UEs in the federated learning group, wherein, for the subgroup of one or more UEs, the configuration message includes scheduling information for allocating 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 issuing update instructions to the plurality of UEs in the federated learning group comprises: Implement multicast transmission with the aforementioned identifier.
8. The method as described in any of the preceding claims, comprising: Prior to the assignment step, a request to participate in the federated learning for the neural network is received from each of the UEs.
9. The method of claim 8, wherein: The requests to participate in federated learning include UE capability information and / or UE assistance information.
10. The method of claim 9, wherein assigning the UE to a federated learning group comprises: Determine that the UE's capability data and / or the UE's local conditions fall within the range of capabilities and / or local conditions associated with the federated learning group.
11. The method of claim 9 or claim 10, wherein selecting one or more UEs from the federated learning group to provide updated information comprises: The UE is selected based on its capability data and / or local conditions.
12. The method of any of the preceding claims, wherein the computing system is a cellular network entity.
13. The method of any of the preceding claims, wherein the corresponding update information is obtained from the corresponding local update procedure at the selected UE.
14. A computer-implemented method executed by a user equipment (UE), the method comprising: Send requests to network entities to participate in federated learning for neural networks; In response to the request, a configuration message for a federated learning group is received, the configuration message including an identifier for the federated learning group; The identifier is used to identify an update indication of the updated parameters of the neural network from messages received from the network entity; Using the neural network with the updated parameters; as well as When the configuration message includes uplink scheduling information, update information is sent to the network entity according to the scheduling information.
15. The method of claim 14, further comprising: Send requests to network entities to participate in federated learning for neural networks. The configuration message mentioned therein is received in response to the request.
16. The method of claim 14 or 15, wherein using the identifier for identification comprises: The identifier is used to identify the update indication in a multicast transmission.
17. The method of any one of claims 14 to 16, wherein the request for neural network configuration includes UE capability information and / or UE assistance information.
18. An apparatus comprising: Network interface; One or more processors, said one or more processors being coupled to the network interface; as well as A memory that stores computer-readable instructions that, when executed by the one or more processors, cause the device to perform the method as described in any one of claims 1 to 13.
19. A user equipment, comprising: One or more antennas; One or more processors; as well as A memory that stores computer-readable instructions that, when executed by the one or more processors, cause the user equipment to perform the method as described in any one of claims 14 to 17.
20. A computer program product comprising computer-readable instructions that, when executed by a means including a network interface and one or more processors coupled to the network interface, cause the means to perform the method as described in any one of claims 1 to 17.