Distributed federal learning on digital twin model

Abstract

A control system and method are provided to support federated learning on a digital twin model, where respective set of devices may each perform training on a local model instance. Within each set, the training and model parameters may be distributed across the devices, with the distribution varying between sets. The control system and method may obtain information on the parameter distribution for a source set and a target set of devices, and determine a parameter mapping to link model parameters between the sets. The mapping may define data processing operations, such as splitting or merging model parameters. Upon completion of a training step by a source device, the control system and method may identify target device(s) for the transfer of model parameters and effect the transfer, which may include effecting data processing operations. The above measures may enable efficient transfer of model parameters while supporting federated learning across distributed devices.

Description

[0001] DISTRIBUTED FEDERAL LEARNING ON DIGITAL TWIN MODEL

[0002] TECHNICAL FIELD

[0003] The presently disclosed subject matter relates to a computer-implemented method and a control system for supporting federated learning on a digital twin model. The presently disclosed subject matter further relates to a transitory or non-transitory computer-readable medium comprising instructions, which when executed by a processor system, cause the processor system to perform the method.

[0004] BACKGROUND

[0005] The term ‘digital twin’ may refer to a digital replica model of a real-world system or object. Unlike static models, digital twins may be regularly or even continuously updated with data from their physical counterparts. Digital twins may allow for simulations, forecasts, and data analytics to be conducted in real time, enabling monitoring, control, and optimization of complex systems without disrupting the operations of these complex systems. This may offer various technical benefits, such as predictive maintenance, early fault detection, and system performance optimization.

[0006] Digital twin models may traditionally be trained in a centralized manner, for example by a cloud server. However, there is a growing need to enable digital twin models to be trained locally, for example within a local network or by a local edge, e.g., a geographically distributed portion of a network infrastructure which may be situated near a source of data generation or device activity. Localized training of digital twin models may offer advantages such as keeping training data local to enhance data security by minimizing transmission risks, ensuring compliance with data protection regulations, and making efficient use of network bandwidth and storage resources.

[0007] However, locally, servers capable of handling the computational demands of training digital twin models may not always be available. In such cases, it may be desirable to train digital twin models in a distributed manner across a set of devices. Individual devices may have limited computational resources which may be insufficient for training the entire model independently within a reasonable timeframe, but collectively, the devices may cooperate to perform the training. For example, the training of a neural network-based digital twin model may be distributed across devices by assigning different layers of the neural network to different devices. For example, the training of the neural network may be performed by a first device performing a first part of a forward pass through a first set of layers of the neural network, followed by a second device processing the next set of layers, and so on, until a full forward pass is completed. Similarly, a backward pass of training may also be distributed, with gradient updates being propagated back through the network across multiple devices. In such scenarios, intermediate activations and gradient updates may be shared between devices, while each device may maintain its own local set of model parameters for the layers or other model parts handled by the respective device. Model parameters may for example include weights, biases, hyperparameters, and state variables.

[0008] A potential disadvantage of entirely local training is that the local training data may be insufficient in scope or diversity, which may limit the performance and generalizability of the trained digital twin model. It may be desirable to benefit from training data available at multiple locations. Sharing training data, however, may cause concerns related to data privacy and may be restricted by regulatory or compliance requirements. Additionally, training data may be sizable and its transfer between different locations may increase bandwidth requirements and latency.

[0009] Federated Learning is a machine learning technique where multiple entities may collaborate in solving a machine learning problem without sharing their underlying data, thereby preserving privacy. In a typical federated learning scenario, a central coordinating server may send requests to local devices or servers to perform training iterations on their local data. The local devices may process the request and perform training independently. The coordinating server may then receive partial training results, such as model updates, from the local devices and aggregate these to obtain a global model. However, integrating federated learning with the distributed training of digital twin models across sets of devices presents challenges, particularly in supporting efficient communication between different sets of devices.

[0010] It is desirable to support federated learning where local model instances of a digital twin model are trained in a distributed manner by different sets of devices. It is known to support such federated learning by compressing the parameter data communicated between devices [1], However, further improvements are desirable.

[0011] References

[0012] [1] Federated Learning with Compression: Unified Analysis and Sharp Guarantees, Haddadpour et al., https: / / arxiv.org / abs / 2007.01154

[0013] SUMMARY

[0014] In accordance with a first aspect of the presently disclosed subject matter, a computer-implemented method is provided for supporting federated learning on a digital twin model, wherein the federated learning may comprise different sets of devices each training a local model instance of the digital twin model, wherein the training of each local model instance may be distributed across the devices within a respective set and the model parameters of the local model instance may be distributed across the devices, and wherein the distribution of the training and the model parameters may differ across the different sets of devices.

[0015] The method may comprise:

[0016] - for at least a source set of devices and a target set of devices, obtaining information indicative of the distribution of the model parameters across the devices, thereby obtaining parameter distribution information for the source set of devices and the target set of devices;

[0017] - based on the parameter distribution information for the source set of devices and the target set of devices, determining a parameter mapping that may identify how the model parameters distributed across source devices in the source set are linked to target devices in the target set, wherein the parameter mapping may further define data processing operations to support a transfer of the model parameters of a source device to a target device, wherein the data processing operations may comprise at least one of: a data split operation which may split model parameters of a source device into split model parameters for two or more target devices; a data merge operation which may merge model parameters of two or more source devices to obtain merged model parameters for a target device;

[0018] - upon completion of a training step by a source device, and based on the parameter mapping, identifying one or more target devices as recipient for the model parameters of the source device, and effecting the transfer of the model parameters from the source device to the identified one or more target devices, wherein the transfer may comprise executing the data processing operations defined by the parameter mapping.

[0019] In accordance with a second aspect of the presently disclosed subject matter, a control system is provided for supporting the federated learning on a digital twin model as defined above. The control system may comprise:

[0020] - a network interface for network access to the different sets of devices;

[0021] - a processor subsystem which may be configured to: for at least a source set of devices and a target set of devices, obtain information indicative of the distribution of the model parameters across the devices, thereby obtaining parameter distribution information for the source set of devices and the target set of devices; based on the parameter distribution information for the source set of devices and the target set of devices, determine a parameter mapping that may identify how the model parameters distributed across source devices in the source set are linked to target devices in the target set, wherein the parameter mapping may further define data processing operations to support a transfer of the model parameters of a source device to a target device, wherein the data processing operations may comprise at least one of: a data split operation which may split model parameters of a source device into split model parameters for two or more target devices; a data merge operation which may merge model parameters of two or more source devices to obtain merged model parameters for a target device; upon completion of a training step by a source device, and based on the parameter mapping, identify one or more target devices as recipient for the model parameters of the source device, and effect the transfer of the model parameters from the source device to the identified one or more target devices, wherein the transfer may comprise executing the data processing operations defined by the parameter mapping.

[0022] The above measures may support federated learning of a digital twin model, where instances of the digital twin model are locally trained by respective sets of devices. Here, 'local' may indicate geographical proximity of devices but may also refer to different types of locality, such as devices within a network infrastructure or logical groupings based on network topology or organizational boundaries. In the following, a local set of devices may also be referred to as being part of a local ‘site’. The digital twin model may generally be any type of machine-learnable model, such as a neural network, support vector machine, or decision tree, and may utilize architectures such as deep learning or graph neural networks, while being trained using techniques such as supervised learning, unsupervised learning, or reinforcement learning. The model instances may generally represent copies of the same model architecture but may be locally trained on different training data, for example data that is locally generated or locally accessible. Consequently, there may be differences in the local training data among the respective sets of devices, such as different samples (e.g., data points) and / or different features (e.g., attributes or variables describing a data point).

[0023] To enable benefiting from the scope and diversity in training data across different sets of devices, model parameters may be shared between the sets of devices during training after they have been updated. These shared model parameters may therefore also be referred to as ‘updated model parameters’. Traditionally, in federated learning, a participant, such as a local server, may train its model instance on local data and then periodically send the updated model parameters to a central server or aggregator. The central server may aggregate the received model parameters, e.g., by averaging them, to update a global model, which may then be distributed back to the participant for further training, for example to refine the local model using the updated global parameters and / or to continue with the next training iteration.

[0024] It may be desirable for participants in the federated learning to control their own data merging. This may be due to the need to examine and potentially reject incoming model parameters if they are judged to be unsafe or divergent. In this way, each participant may individually manage the influence of potentially malicious actors supplying parameters that may corrupt or manipulate the model. For example, participants may compare incoming model parameters from other clusters with their own parameters resulting from training on their local dataset or a 'gold-standard' dataset. Additional advantages of such local data merging may include not requiring a central orchestrator which is otherwise tasked with the data merging, thereby reducing potential bottlenecks and single points of failure at such a central orchestrator.

[0025] While data communication may be set up similarly to systems with a central orchestrator, such as waiting for a training epoch to complete before exchanging model parameters, the inventors have devised measures to enable and improve communication in federated learning when training is locally distributed across devices.

[0026] Namely, in the present context, local training may be distributed across devices within each set of devices, and therefore the distribution of model parameters across the local devices may differ between these sets, for example, to optimally exploit the availability of resources of the devices. Accordingly, different devices may operate on different subsets of model parameters. Therefore, a control system and corresponding method may be provided that may identify which model parameters are handled by each device locally. This information, which may also be referred to as 'parameter distribution information', may be obtained for different sets of devices, allowing a mapping to be identified between devices at different participating sites.

[0027] Since the distribution of parameters across devices may differ between participating sites, the mapping between parameters and devices may also differ between participating sites. For example, model parameters handled by device A1 at participating site A may correspond to parameters distributed across devices B1 and B2 at participating site B, requiring the parameters to be split before or during transfer. Similarly, model parameters handled by devices C1 and C2 at participating site C may correspond to parameters handled solely by device D1 at participating site D, which may necessitate the merging of parameters before, during, or after transfer.

[0028] The above-described measures may involve determining a parameter mapping that may identify device-to-device correspondences, accounting for situations where model parameters need to be split across multiple devices or merged from multiple sources. Based on this mapping, updated model parameters may be shared directly between sets of devices, e.g., from a single source device at a source site to one or more target devices at a target site or from one or more source devices to a single target device, without requiring a central entity to first receive all of the model parameters from the source site, redistribute the parameters to obtain distributed parameters, and then transfer the redistributed parameters to the target site. Instead, the merging or splitting of model parameters may be performed specifically for the relevant combinations of source and target devices. This may in some embodiments allow the devices themselves to handle the splitting and merging operations, for example in accordance with instructions provided by the method or control system.

[0029] The transfers may generally be executed by the method or control system by retrieving updated model parameters from a source device and sending them to the corresponding target device, or by instructing the devices to manage the transfer independently. Data processing operations, such as splitting or merging of model parameters, may occur either before the transfer by the sender device, as part of the transfer, e.g., by a network or cache node, or after the transfer by the receiving device.

[0030] Using the above-described measures, federated learning of a digital twin model with sets of devices, where training is distributed across devices, may be performed more efficiently. For example, data transfers between devices may be performed on an individual basis, based on specific combinations of source and target devices identified by the parameter mapping. This may offer advantages such as the ability to prioritize data transfers for certain devices depending on the importance of their model parameters or their completion time, which is not feasible when transferring model parameters collectively as in traditional methods. Additionally, specific communication between devices may reduce overall communication overhead. For example, it may not be necessary for all source devices to send their model parameters to a central entity for redistribution. Instead, direct communication between devices, possibly involving intermediary caches or network nodes, may be utilized. This approach may also be combined with data compression techniques [1], While the following embodiments refer to the computer-implemented method, they may also represent corresponding embodiments of the control system. For example, the processor subsystem of the control system may be configured to perform any of the described method steps.

[0031] In an embodiment, the method may further comprise determining whether the identified one or more target devices are ready to receive the model parameters, and may effect the transfer of the model parameters to the identified one or more target devices provided that said target devices are ready to receive the model parameters.

[0032] The above measures involve performing a readiness check at the target devices, which may comprise checking whether the target devices are ready to accept model parameters for their local model update. This readiness check may comprise determining if a device is still engaged in a training epoch or experiencing issues such as connectivity problems or resource constraints. By ensuring that the target devices are ready before initiating the transfer, inefficient data transfers may be avoided, such as sending model parameters to devices that are not capable of processing them.

[0033] In an embodiment, the method may further comprise managing readiness flags for respective devices, wherein the readiness flags may indicate:

[0034] - whether a source device has completed a training step and its model parameters are ready to be transferred; and

[0035] - whether a target device is ready to receive the model parameters from the source device; wherein the transfer may be executed subject to both the source device and the identified one or more target devices having a set readiness flag.

[0036] The 'readiness flags' may be data indicators that indicate whether a source device has completed a training step and its model parameters are ready for transfer, and whether a target device is ready to receive them. The transfer may occur only when both the source and target devices have their readiness flags set. By managing readiness flags, it may be ensured that model parameters are transferred only when both the source and target devices are prepared, which may reduce delays and prevent inefficient transfers. Additionally, this mechanism may contribute to better error handling, as devices experiencing issues such as connectivity problems or resource constraints may be flagged as not ready, preventing unnecessary transfer attempts.

[0037] In an embodiment, managing the readiness flags for the respective devices may comprise at least one of:

[0038] - querying the respective devices to determine their readiness status; and - receiving readiness signals from the respective devices indicating their readiness status.

[0039] Here, 'querying' may refer to actively checking the readiness of devices by sending requests for their status, while receiving readiness signals may refer to passively receiving updates from devices as they communicate their readiness. Querying may be useful when an immediate status check is needed, while readiness signals may allow for more efficient and proactive monitoring, enabling devices to inform the method and control system as soon as they are ready. In some examples, the method and control system may use both querying and receiving readiness signals, thereby combining the advantages of real-time checks with passive monitoring.

[0040] In an embodiment, the method may further comprise caching the model parameters during the transfer to enable asynchronous transfer of the model parameters from the source device to the identified one or more target devices.

[0041] Here, 'caching' may refer to temporarily storing the model parameters during the transfer process. Caching the model parameters during transfer may allow for asynchronous transfer from the source device to the target device. By temporarily storing the model parameters in a cache, the source device may complete its part of the transfer without having to wait for the target device to be immediately ready to receive the data. This may provide greater flexibility and improve overall transfer efficiency, as the sender device may complete its part of the transfer even if the target device is momentarily unavailable or occupied with other tasks. Furthermore, asynchronous transfer may reduce idle time for both source and target devices, leading to more efficient use of network and computational resources in federated learning.

[0042] In an embodiment, training of the local model instance may be performed by a set of devices using local area communication or device-to-device communication, wherein the transfer of model parameters between different sets of devices may be performed via a wide area network, wherein the wide area network may comprise one or more cache nodes for storing model parameters of source devices, and wherein the method may further comprise distributing cached model parameters from the source set of devices to different target sets of devices participating in the federated learning.

[0043] Here, 'local area communication' and 'device-to-device communication' may refer to methods of exchanging data within a limited range, enabling relatively direct communication between devices. A 'wide area network' may be a broader network that connects devices over long distances. The local model instance may be trained by a set of devices using local area or device-to-device communication, allowing these devices to collaborate efficiently within their proximity. When transferring model parameters between different sets of devices, the transfer may be carried out via a wide area network, which may include cache nodes that temporarily store parameters from source devices. An advantage of such caching is that the cached parameters may then be distributed to target devices at participating sites in the federated learning process. By enabling one-to-many transfers, caching may reduce communication overhead, as the same parameters can be sent to target devices at different participating sites without requiring repeated transmissions from the source device. This approach may enhance the scalability and efficiency of the transfer process, reduce latency, and improve the overall reliability of federated learning, for example in environments where immediate device availability cannot always be guaranteed.

[0044] In an embodiment, the wide area network may be a mobile telecommunications network that supports network slicing, and the method may further comprise using a dedicated network slice for communication between the different sets of devices participating in the federated learning. A dedicated network slice may be optimized for federated learning data transfers and may help ensure that these transfers are not affected by congestion or interference from other network traffic.

[0045] In an embodiment, the method may further comprise adjusting a timing of transfers between the source set of devices and the target set of devices to reduce traffic surges over the wide area network. 'Traffic surges' may denote periods of high data transmission activity, which can lead to network congestion and reduced performance. The above measures may involve adjusting the timing of transfers between source and target devices to reduce traffic surges over the wide area network. While source devices may complete their training at different times, for example due to performing earlier or later stages of the training process, or due to varying processing speeds or resource availability, multiple source devices may still exhibit (near) simultaneous readiness, causing a concentration of data transfers that may result in traffic surges. This simultaneous readiness may also occur at the receiver side with target devices, which may similarly lead to a concentration of data transfers if data becomes ready for transfer from the sender. To mitigate these concentrations, the method and control system may function as a scheduler by adjusting the timing of transfers to distribute transfers more evenly across the network. These adjustments may reduce bottlenecks, whether at the connection between a set of devices and the wide area network or within the wide area network itself. By spreading out data transfers, network efficiency may be improved, latency reduced, and communication between devices participating in the federated learning process enhanced. In an embodiment, the training of the local model instance may be distributed sequentially across the devices resulting in devices assigned to earlier stages in said sequence completing their training before devices assigned to later stages, wherein the method may further comprise prioritizing the transfer of model parameters associated with the earlier stages in the sequence over the transfer of model parameters associated with the later stages. The training of the local model instance may be distributed sequentially across devices, typically resulting in devices handling earlier stages completing their part of the training first. As a result, these source devices may be ready to transfer their model parameters earlier than devices responsible for later stages, and the corresponding target devices may be prepared to receive the updated model parameters sooner. To reduce latency in the overall training process and avoid a concentration of data transfers, the transfer of model parameters from the earlier stages may be prioritized. Accordingly, once the model parameters from an earlier stage are ready and the target devices or cache nodes are prepared to receive them, the transfer may be initiated. By allowing these transfers to occur progressively, rather than waiting for all devices to complete their training, the overall progress of federated learning may be accelerated, and network congestion reduced.

[0046] In an embodiment, the method may further comprise prioritizing a transfer of model parameters to target devices that are slower to complete their training step over target devices that are faster to complete their training step. Slower devices may represent a bottleneck in the overall training process and thereby delay the completion of federated learning. To address this problem, the transfer of model parameters to slower target devices may be prioritized to allow them to begin processing earlier, helping to balance the workload across devices and improve overall training efficiency.

[0047] In an embodiment, the method may further comprise prioritizing the transfer of updated model parameters between sets of devices in a federated learning system, for example by prioritizing a transfer of model parameters to a set of target devices that is slower to complete its training over a set of target devices that is faster to complete its training. Prioritization, as previously discussed for individual devices, may also be applied to entire sets of devices, such as a participating site. For example, when a set of source devices produces updated model parameters, these parameters may be transferred to a target set of devices that is slower in completing its training or is ready earlier to receive the parameters, compared to another set of target devices. Prioritizing the transfers of model parameters for entire sets of devices may help reduce bottlenecks and lead to a faster overall completion of the federated learning process. In an embodiment, the local model instances of the digital twin model may be updated after training by a respective set of devices by partial retraining of the local model instance, wherein the method may further comprise identifying which source devices of the source set of devices have updated model parameters and selectively effecting the transfer of the updated model parameters to one or more target devices in accordance with the parameter mapping. Here, 'updating a trained model' may refer to making adjustments to a model instance after its initial training, which may be done through retraining, including partial retraining where only specific parts of the model are refined using new data. In the context of digital twins, such updates may be needed to reflect changes in the physical entity being replicated. After training a local model instance, partial retraining may be used to keep the model accurate and up-to-date. This may comprise identifying source devices with updated model parameters and selectively transferring these updates to target devices based on a parameter mapping. Accordingly, the method and control system may support not only the initial training but also ongoing or periodic updates of the model, which may ensure that the digital twin remains aligned with the physical entity through refinement of relevant model parts.

[0048] In an embodiment, the method may further comprise determining the parameter distribution information for a respective set of devices by generating a graph that represents the devices within the respective set, the distribution of model parameters across the devices, and the data flows between the devices during the training of the local model instance. A graph, also referred to as graph structure, may be used to represent the parameter distribution information for a respective set of devices. For example, nodes of the graph may represent the individual devices within the set, while edges between nodes may represent the data flows during the training of the local model instance. The distribution of model parameters across the devices may be captured by assigning the relevant parameters to each node. The graph may also capture more complex interactions, such as cyclic dependencies between devices, where data or parameters move back and forth between devices during training. By modeling these relationships and data flows, the graph may provide an accurate representation of the parameter distribution across the devices within the set.

[0049] In an embodiment, the method may further comprise determining the parameter mapping by comparing the graph generated for the source set of devices with the graph generated for the target set of devices, wherein the parameter mapping may link the model parameters in the source set to corresponding model parameters in the target set based on the distribution and data flows represented in the respective graphs. By comparing the source graph and target graph, it may be determined how model parameters in the source set correspond to those in the target set. This comparison of graphs may simplify the process of establishing the parameter mapping.

[0050] In accordance with a further aspect of the presently disclosed subject matter, a telecommunications network is provided comprising the control system.

[0051] In an embodiment, the control system is embodied by at least one of:

[0052] - a Network Data Analytics Function (NWDAF);

[0053] - an Artificial Intelligence and Machine Learning server (AI / MLapp); and

[0054] - an Application Data Analytics Enablement Server (ADAES), of the telecommunications network.

[0055] In an embodiment, the telecommunications network may further comprise at least one of:

[0056] - one or more cache nodes configured to store the model parameters of the source devices; and

[0057] - one or more data processing nodes configured to execute the data processing operations defined by the parameter mapping.

[0058] In some examples, the functionality of a data processing node and the functionality of a cache node may be combined in one network node. For example, one or more network nodes may be provided which may be configured to temporarily store the model parameters of the source devices and to execute the data processing operations defined by the parameter mapping.

[0059] In an embodiment, a respective set of devices may comprise a set of edge devices, a set of cloud devices, a set of central network devices, or a set of user equipment, of the telecommunications network. A respective set of devices may comprise one or more of the following types of devices: edge devices, cloud devices, central network devices, and user equipment of the telecommunications network. In some examples, a respective set of devices may consist of only edge devices, only cloud devices, only central network devices, or only user equipment.

[0060] In accordance with a further aspect of the presently disclosed subject matter, a transitory or non-transitory computer-readable medium is provided comprising instructions, which when executed by a processor system, cause the processor system to perform any of the methods described in this specification.

[0061] In accordance with a further aspect of the presently disclosed subject matter, a device is provided for participating in distributed training of a local model instance of a digital twin model. The device may comprise a network interface to communicate with other devices participating in the distributed training of the local model instance of the digital twin model. The device may further comprise a processor subsystem which may be configured to perform a training step which is assigned to the device, and upon completion of the training step, send a readiness signal to a control system to indicate that the training step is complete. The readiness signal may for example indicate that model parameters are ready to be transferred to another device, or that the device is ready to receive model parameters from the other device.

[0062] It will be appreciated by those skilled in the art that two or more of the above-mentioned embodiments, implementations, and / or aspects of the invention may be combined in any way deemed useful.

[0063] Modifications and variations of any one of the above-mentioned entities (e.g., computer-implemented method, control system, telecommunications network, computer-readable medium), which correspond to the described modifications and variations of another one of these entities, may be carried out by a person skilled in the art on the basis of the present description.

[0064] BRIEF DESCRIPTION OF THE DRAWINGS

[0065] These and other aspects of the invention are apparent from and will be elucidated with reference to the embodiments described hereinafter. In the drawings, Fig. 1 shows different sets of devices, each set responsible for training a local model instance of a digital twin model, and for each set of devices, a graph representing data flows between the devices during distributed training where both the training tasks and model parameters are distributed across the devices in a set;

[0066] Fig. 2 shows, for each set of devices of Fig. 1 , the model parameters maintained by each device during training, and a mapping between the model parameters of a source set of devices and a target set of devices, which mapping is generated based on the respective parameter distributions in the graphs of each set;

[0067] Fig. 3 shows data transfers between a source set of devices and a target set of devices in accordance with a parameter mapping between both sets, the data transfers including the execution of split operations and merge operations;

[0068] Fig. 4 demonstrates data transfer between a source set of devices and a target set of devices across a wide area network, the wide area network including data processing nodes equipped with caching functionality to support the transfer and processing of model parameters during distributed training;

[0069] Fig. 5 shows a system which may be exemplary for a control system or other federated learning entity as described in this specification;

[0070] Fig. 6 shows a non-transitory computer-readable medium comprising data; Fig. 7 shows an exemplary data processing system. Reference signs list

[0071] The following list of references and abbreviations is provided for facilitating the interpretation of the drawings and shall not be construed as limiting the claims.

[0072] A-J model parameters

[0073] D1-D4 device

[0074] M1-M6 merge node

[0075] PN1-PN3 data processing node

[0076] S1-S6 split node

[0077] SD1-SD6 source device

[0078] TD1-TD5 target device

[0079] 1-4 graph node representing device

[0080] 100-106 set of devices

[0081] 120-126 graph representing data flows between devices

[0082] 140-146 graph representing data flows between devices and parameter distribution across devices

[0083] 150 activations

[0084] 152 gradients

[0085] 154 model parameters

[0086] 200 local area network

[0087] 220 wide area network

[0088] 222 data transfer

[0089] 240 control system

[0090] 300 system

[0091] 320 network interface

[0092] 322 received data

[0093] 324 sent data

[0094] 340 processor subsystem

[0095] 360 data storage

[0096] 400 non-transitory computer-readable medium

[0097] 410 stored data 1000 exemplary data processing system

[0098] 1002 processor

[0099] 1004 memory element

[0100] 1006 system bus

[0101] 1008 local memory

[0102] 1010 bulk storage device

[0103] 1012 input device

[0104] 1014 output device

[0105] 1016 network adapter

[0106] 1018 application

[0107] DESCRIPTION OF EMBODIMENTS

[0108] Fig. 1 shows different sets 100, 102, 104, 106, of devices. Each set may be responsible for training a local model instance of a digital twin model. The sets of devices may include, for example, a set of edge devices, a set of cloud devices, a set of central network devices, or a set of user equipment of a telecommunications network. Each set of devices may include multiple devices, with set 100 for example comprising devices D1, D2, and D3, while the devices in sets 102, 104, and 106 may not be separately labeled. Each set of devices may be represented as a respective graph 120, 122, 124, and 126. Each graph may represent data flows between the devices within the set during distributed training. For example, the devices in each set may be represented in the graph by nodes, which in Fig. 1 may be labeled 1-4 depending on the set. For example, graph 120 may include nodes 1-3 to represent devices D1-D3, graph 122 may include nodes 1-4 to represent its four devices, graph 124 may include nodes 1-2 to represent its two devices, and graph 126 may include nodes 1-3 to represent its three devices. Arrows between the nodes 1-4 in each graph 120-126 may indicate data flows between the devices during the training. Bidirectional arrows between nodes may capture cyclic or repeated operations during the training.

[0109] The training tasks and model parameters may be distributed across the devices within each set, and the distribution of the training may differ across the different sets of devices. Fig. 2 shows, for each set of devices of Fig. 1, the model parameters maintained by each device during training. In this example, the local model instance may be a neural network comprising five layers: A, B, C, D, and E. The figure illustrates the different distribution of these layers, and therefore the different distribution of the parameters of the model, across the devices. For example, graph 140 shows that in the first set, device 1 may be assigned layers A and B, device 2 may be assigned layers C and D, and device 3 may be assigned layer E. Another example is that graph 142 shows that in the second set, device 1 may be assigned layer A, device 2 may be assigned layer B, device 3 may be assigned layer C, and device 4 may be assigned layers D and E. Fig. 2 further shows a mapping of model parameters between the first set (represented by graph 140) and the second set (represented by graph 142). As illustrated, the model parameters of layers A and B from graph 140 may need to be split between devices 1 and 2 in graph 142. For this purpose, a splitting operation may be used, which is shown in Fig. 2 to be performed by split node S1, splitting the parameters AB into A for device 1 and B for device 2 in graph 142. Similarly, the model parameters of layers C and D from graph 140 may need to be split, which function may be performed by split node S2, resulting in C for device 3 and D for device 4 in graph 142. Lastly, the model parameters of layer E from graph 140 may be merged with the split parameter D from device 2 by merge node M1 , and then the merged parameters for layers D and E may be transferred to device 4 in graph 142.

[0110] In general, a mapping of the type illustrated in Fig. 2 may be generated by a control system and corresponding method to support federated learning on a digital twin model. For example, the control system and method may generate the graphs as shown in Fig. 2 or alternative parameter distribution information. To support the transfer of model parameters between a source set of devices, such as set 100 of Fig. 1 (represented by graph 140 in Fig. 2), and a target set of devices, such as set 102 of Fig. 1 (represented by graph 142 in Fig. 2), a parameter mapping may be determined. This parameter mapping may identify how the model parameters distributed across source devices in the source set are linked to target devices in the target set. The parameter mapping may further define data processing operations to facilitate the transfer of the model parameters from a source device to a target device. These data processing operations may include a data split operation, which may split model parameters of a source device into split model parameters for two or more target devices, and a data merge operation, which may merge model parameters from two or more source devices to obtain merged model parameters for a target device. The mapping illustrated in Fig. 2 shows use of two split operations S1, S2 and a merge operation M1 which may each be carried out by a respective data processing node.

[0111] Having determined a mapping of the type illustrated in Fig. 2, data may be transferred from a source set to a target set. For example, the transfer may comprise device 1 from the source set sending, at the request of the control system and method, the model parameters of layers A and B to split node S1. Split node S1 may then be instructed to split the parameters of layers A and B and send the parameters of layer A to device 1 in the target set and the parameters of layer B to device 2 in the target set, in accordance with the mapping. Similarly, device 2 from the source set may be instructed to send the model parameters of layers C and D to split node S2. Split node S2 may be instructed to split the parameters of layers C and D and send the parameters of layer C to device 3 and the parameters of layer D to merge node M1. For layer E, device 3 from the source set may be instructed to transfer the model parameters to merge node M1. Merge node M1 may be instructed to merge the parameters of layer E with the split parameter D received from split node S2, and the merged parameters for layers D and E may be transferred to device 4 in the target set.

[0112] Fig. 3 represents a more extensive example than Fig. 2, illustrating how model parameters for layers A-J are differently partitioned across a source set of devices SD1-SD6 and a target set of devices TD1-TD5. Specifically, the source set comprises source device SD1 which maintains the model parameters for layers A and B, source device SD2 which maintains the parameters for layer C, source device SD3 which maintains the parameters for layers D, E, and F, source device SD4 which maintains the parameters for layer G, source device SD5 which maintains the parameters for layer H, and source device SD6 which maintains the parameters for layers I and J. On the target side, the target device set comprises target device TD1 which maintains the parameters for layer A, target device TD2 which maintains the parameters for layer B, target device TD3 which maintains the parameters for layers C and D, target device TD4 which maintains the parameters for layers E, F, G, and H, and target device TD5 which maintains the parameters for layers I and J.

[0113] Fig. 3 illustrates an optional arrangement where model parameters from each source device in the source set are always passed through a respective split node, whether splitting is required or not. Accordingly, split nodes S1-S6 are provided for source devices SD1-SD6, respectively. Similarly, model parameters sent to a target device in the target set are always passed through a respective merge node, whether merging is required or not. Accordingly, merge nodes M1-M5 are provided for target devices TD1-TD5, respectively. In general, the use of split nodes and / or merge nodes may be optimized, with nodes provided only when necessary, depending on the specific parameter distribution and transfer operations. It will be appreciated that the split and merge nodes in Fig. 3 and previously in Fig. 2 may be logical nodes, representing operations rather than physical nodes. In practice, an implementation may involve fewer physical nodes, such as a single data processing node handling all the split and merge operations. Moreover, as discussed elsewhere, split nodes and / or merge nodes may be implemented in various ways. For example, they may be implemented by data processing nodes in a network, or splitting operations may be carried out by source devices and merging operations by target devices.

[0114] Fig. 3 shows exemplary data flows during the training of a model by the source set of devices SD1-SD6 and the target set of devices TD1-TD5. The data flows may include forward propagation of activations 150 between devices during a forward pass of the training, and backward propagation of gradients 152 between the devices during a backward pass of the training. During backward propagation through a respective device, the model parameters maintained by the respective device may be updated based on the computed gradients, thereby obtaining updated model parameters.

[0115] To illustrate the data transfer process of updated model parameters between the source set of devices SD1-SD6 and the target set of devices TD1-TD5, Fig. 3 shows that, upon instruction from the control system and method, source device SD1 may send the model parameters 154 for layers A and B to split node S1. Split node S1 may split these parameters, with the parameters for layer A being passed to target device TD1 via merge node M1 , and the parameters for layer B being passed to target device TD2 via merge node M2. Moreover, source device SD3 may send the parameters for layers D, E, and F to split node S3, where the parameters are split into parameters for layer D, which are passed to target device TD3, and parameters for layers E and F, which are passed to target device TD4. Before the parameters for layer D are passed to TD3, they may first be merged with the parameters for layer C, which are sent from source device SD2 via split node S2 and passed to merge node M3. Merge node M3 performs the merge operation to obtain the parameters for layers C and D, which are then transferred to target device TD3. For layers E and F, these parameters are merged at merge node M4 with the parameters for layer G, which are sent from source device SD4 via split node S4, and the parameters for layer H, which are sent from source device SD5 via split node S5. The merge operation performed by merge node M4 results in the combined parameters for layers E, F, G, and H, which are transferred to target device TD4. Lastly, source device SD6 may send the parameters for layers I and J via split node S6. These parameters are passed through merge node M5 and then transferred to target device TD5, which may be responsible for layers I and J.

[0116] Fig. 4 demonstrates data transfer between a source set of devices and a target set of devices across a wide area network (WAN) 200, such as a telecommunications network. The WAN may include data processing nodes PN1 , PN2, and PN3, which may be equipped with caching functionality to support the transfer and processing of model parameters during distributed training. These data processing nodes may further perform split and merge operations as described elsewhere in this specification to facilitate the distribution of model parameters across different devices. In this example, the source set of devices is set 100, which may include source devices SD1, SD2, and SD3. The source devices may communicate with each other during the training of a local model instance of a digital twin model using local area communication via a local area network (LAN) 200. The LAN 200 may be connected to the WAN 220, which facilitates communication between the different sets 100-106 of devices. All sets of devices participating in the federated learning process may be accessible via the WAN. The WAN 220 may further include a control system 240 that supports the overall federated learning process by managing the routing of model parameters between the source set and target sets of devices. The control system 240 may for example be implemented by one or more network nodes. In a specific example, the WAN 220 is a 5G, 6G, or later generation mobile telecommunications network, and the control system 240 may be embodied as or as part of a network function, such as a core network function of the WAN 220. For example, the control system 240 may be implemented by a Network Data Analytics Function (NWDAF), an Artificial Intelligence and Machine Learning server (AI / MLapp), or an Application Data Analytics Enablement Server (ADAES) of the telecommunications network.

[0117] In the example of Fig. 4, the target set of devices is set 106, which may include target devices TD1 , TD2, and TD3. The transfer of model parameters from the source set 100 to the target set 106 may occur via the WAN 220. The data transfer, which is shown as a dashed line 222, may proceed from LAN 200 of the source set 100 to WAN 220, passing through data processing node PN2, and eventually reaching the target set 106. The model parameters may be transferred on an individual basis, for example when individual source devices are ready to send and individual target devices are ready to receive parameters. To facilitate this process, the control system 240 may determine whether the source devices and the target devices are ready to proceed with the transfer. This determination may involve checking readiness flags, which may be managed by the control system 240. The readiness flags may indicate whether a source device, such as one of SD1-SD3, has completed a training step and is ready to transfer its parameters, as well as whether a target device, such as TD1- TD3, is ready to receive those parameters. In some examples, the transfer of model parameters may be effected only when both the source device and target devices have their readiness flags set. Managing readiness flags for the respective devices may involve querying the devices to determine their readiness status or receiving readiness signals from the devices. For example, the control system 240 may query source device SD1 to check if it has completed its training step, and it may query target device TD1 to determine if it is ready to receive parameters. Alternatively, readiness signals may be sent by the devices to the control system 240, indicating their current status. An example of a readiness flag is a binary indicator or a timestamp indicating when a respective device is ready. Another term for readiness flag may be readiness indicator.

[0118] As an alternative to transferring model parameters directly from the source device to the target device when both devices are ready, the transfer may be performed in stages, based on the readiness of either device. For this purpose, caches may be used to enable the temporary storage of model parameters during the transfer. This may allow for asynchronous transfers between the source devices and the target devices by allowing the transfer of parameters from the source device even if the target device is not immediately ready to receive the parameters. Cache functionality may be provided by the data processing nodes in the wide area network. For example, model parameters from source device SD1 in the source set 100 may be cached at the data processing node PN2 in the wide area network 220, and later distributed to target device TD1 when the target device is ready to receive the parameters, possibly after being split or merged with other parameters in accordance with the mapping determined by the control system 240. In some implementations, caches may also be deployed separately from the data processing nodes, for example as separate cache nodes. In general, the transfer of model parameters may occur either synchronously, where both the source and target devices are ready simultaneously, or asynchronously, where the source device may transfer the parameters to a cache once ready and the target device may retrieve the parameter from the cache once ready.

[0119] In general, the wide area network (WAN) 220 may cache and process model parameters, including performing operations such as splitting and merging. Caching may enable the efficient distribution of parameters to multiple target sets participating in federated learning. In the specific example of Fig. 4, after caching by data processing node PN2, the cached model parameters may be distributed not only to target set 106 but also to additional target sets, allowing for efficient distribution of the parameters across multiple sets of devices. In other examples, caching and / or data processing may not be performed in the wide area network 220 but elsewhere, such as at the source (sender) side, the target (receiver) side, or at both sides. For example, splitting may be performed at a source device, merging at a target device, with caching occurring at the source device when the target device is not ready, or at the target device when only part of the parameters for merging have been received. Fig. 4 shows the training of the local model instance within a set of devices being performed using LAN-based communication, for example using local wired or wireless communication. Alternatively, the training of the local model instance within a set of devices may be performed using device-to-device (D2D) communication. D2D communication may allow direct communication between devices within a set without relying on intermediate network infrastructure such as a LAN. Examples of D2D communication may include cellular D2D communication, e.g., in-band on cellular frequencies or out-band on unlicensed spectrum, Bluetooth, and Wi-Fi Direct.

[0120] Fig. 4 shows the cache nodes integrated with data processing nodes PN1- PN3. Alternatively, cache nodes configured to store the model parameters of the source devices may be separate entities from the data processing nodes responsible for executing the data processing operations defined by the parameter mapping. Furthermore, while Fig. 4 illustrates caching by data processing nodes within the wide area network 220, the caching of the model parameters during the transfer may also be performed elsewhere or by other entities. For example, caching may occur at the edge of the wide area network 220, for example closer to the source device or target device, or within cloud infrastructure, such as distributed caches across the internet.

[0121] Although not shown in Fig. 4, the wide area network may be a mobile telecommunications network that supports network slicing, for example a 5G, 6G or later generation telecommunications network adhering to one or more 3GPP standards. In such a telecommunications network, a dedicated network slice may be allocated for communication between the different sets of devices participating in the federated learning. For example, a dedicated slice may be allocated for devices in a smart factory communicating their model updates between each other, or for autonomous vehicles communicating their model updates between each other. The control system may allocate such a network slice, for example by interfacing with a Network Slice Selection Function (NSSF). Once the slice is allocated, the control system may interact with a Network Exposure Function (NEF) to monitor and optimize the performance of the network slice during the federated learning process, for example to adjust the allocation of resources in order to support the uninterrupted communication between the devices participating in the federated learning.

[0122] In general, the control system and method may adjust the timing of transfers between the source set of devices and the target set of devices, for example to reduce traffic surges over the wide area network. Such adjustment of timing may be effected by the control system and method by sending instructions at specific timestamps, or by instructing the devices to communicate at specific timestamps. For example, the control system may instruct devices in a smart factory to send model parameters at specific timestamps during periods of lower network traffic, or devices in an loT network may be scheduled to send updates overnight when typical network usage is low.

[0123] In general, the training of the local model instance may be distributed sequentially across the devices, or at least partially sequentially, resulting in devices assigned to earlier stages in the sequence completing their training before those assigned to later stages. For example, when training a neural network, one or more devices may may be assigned to process the initial layers of the model, such as feature extraction layers, while other devices may handle deeper layers, such as classification layers. Such distribution of the training across devices may be implemented to enable pipelining, which may increase or maximize parallelism and reduce or minimize wait times between stages of the model, which may allow each device to operate more efficiently. The control system may prioritize the transfer of parameters from devices processing the initial layers over those processing the deeper layers. Such prioritization may apply to either the source devices, the target devices, or both the source and target devices. For example, if several source devices have updated model parameters, the transfer of model parameters associated with initial layers of the model may be prioritized over the transfer of model parameters associated with deeper layers.

[0124] In general, the control system and method may prioritize the transfer of model parameters to target devices that are slower to complete their training steps over target devices that are faster to complete their steps. For example, devices running on older hardware may take longer to complete their training steps. The control system and method may prioritize transferring updated model parameters to such slower devices. For example, if several target devices are ready to receive updated model parameters, the transfer of updated model parameters to slower target devices may be prioritized over the transfer of updated model parameters to faster target devices.

[0125] In general, a local model instance of the digital twin may be trained by a set of devices using federated learning. During such training, updated model parameters may be shared between different sets of devices and used to update the local model parameters. After the training, a local model instance may be updated, for example to reflect changes in the modelled real-world system or object. These updates may be performed in several ways. For example, updates may be provided as new inputs to the digital twin model at inference time, where real-time data from the real-world system or object may be fed into the model to generate current predictions or simulations without altering the underlying model parameters. Alternatively, or additionally, such updates may comprise retraining the digital twin model, where the model parameters may be adjusted based on new training data. Retraining may for example be performed when there are significant changes in the behavior or structure of the real-world system or object, or when model performance degrades over time. The control system and method may support retraining by identifying which source devices within the source set of devices have updated model parameters and selectively initiating the transfer of these updated parameters to one or more target devices, as specified by the parameter mapping. Retraining may be selective, which may also be referred to as partial retraining, in that only specific portions of the model for which updates are available may be retrained, rather than the entire model.

[0126] It will be appreciated that while the previous examples referred to a neural network as the digital twin model, the model may vary. For example, the model may be a deeper neural network with more layers, a convolutional neural network (CNN), a recurrent neural network (RNN), or a non-neural model such as a decision tree, a random forest, or a support vector machine (SVM). Examples of parameter distribution for non-neural models may for example comprise splitting decision trees or forests by tree depth, where different devices handle specific levels of the tree. For example, a first device may handle the root and upper branches, while a second device and a third device may handle the lower branches and leaf nodes. For SVMs, parameters such as support vectors and weights may be distributed across devices, where a first device manages the kernel calculations and a second device handles the support vector selection. In general, parameter distribution may differ depending on device capabilities. For example, a first device may handle more computationally expensive tasks, while a second and third device balance the rest of the workload. Alternatively, parameters may be further split between devices, or certain devices may aggregate parameters from others. Instead of partitioning by layers, other strategies may include splitting by neurons, where each device trains specific neurons within a layer, or by channels in a CNN, where devices process different feature maps. In an RNN, parameters may be split by time steps, allowing a first device to handle earlier steps and a second device to manage later steps. Devices may also process different parts of input data, such as specific image region in a CNN. Partitioning may also occur by feature dimensions, where different devices may handle and train different feature sets.

[0127] The control system and method as presently disclosed may support federated training of digital twins in scenarios including, but not limited to, smart factories for optimizing production processes and predictive maintenance, autonomous vehicles for improving navigation and driving algorithms, healthcare for training patient models across multiple hospitals, energy grids for optimizing operations and load balancing, smart cities for real-time infrastructure management and traffic optimization, telecom networks for improving network performance and resource management, aerospace for optimizing aircraft maintenance and performance, supply chain management for monitoring and predicting logistics operations, etc.

[0128] Fig. 5 shows a system 300 which may represent or embody any of the entities described in this specification, such as the control system or a device participating in the training. The system 300 may comprise a network interface 320 for network data communication, e.g., to receive data 322 and to send data 324. The network interface 320 may for example be a wired communication interface, e.g., a fiberoptic interface or an Ethernet interface, or a wireless communication interface, e.g., a cellular radio interface. The system 300 may further comprise a processor subsystem 340 which may be configured, e.g., by hardware design or software, to perform the operations described in this specification pertaining to the embodied entity.

[0129] In general, the processor subsystem 340 may be embodied by a single Central Processing Unit (CPU), such as a x86 or ARM-based CPU, but also by a combination or system of such CPUs and / or other types of processing units. As also shown in Fig. 5, the system 300 may comprise a data storage 360, which may comprise non-volatile memory such as flash memory, a solid-state drive, etc., and which may be used for long-term storage of data. Although not shown in Fig. 5, the system 300 may further comprise volatile memory for temporary storage of data.

[0130] In general, each entity described in this specification may be embodied as, or in, a device or apparatus. The device or apparatus may comprise one or more (micro) processors which execute appropriate software. The processor(s) of a respective entity may be embodied by one or more of these (micro)processors. Software implementing the functionality of a respective entity may have been downloaded and / or stored in a corresponding memory or memories, e.g., in volatile memory such as RAM or in non-volatile memory such as Flash. Alternatively, the processor(s) of a respective entity may be implemented in the device or apparatus in the form of programmable logic, e.g., as a Field-Programmable Gate Array (FPGA). Any input and / or output interfaces may be implemented by respective interfaces of the device or apparatus. In general, each functional unit of a respective entity may be implemented in the form of a circuit or circuitry. A respective entity may also be implemented in a distributed manner, e.g., involving different devices or apparatus.

[0131] It is noted that any of the methods described in this specification, for example in any of the claims, may be implemented on a computer as a computer implemented method, as dedicated hardware, or as a combination of both. Instructions for the computer, e.g., executable code, may be stored on a computer-readable medium 400 as for example shown in Fig. 6, e.g., in the form of a series 410 of machine-readable physical marks and / or as a series of elements having different electrical, e.g., magnetic, or optical properties or values. The executable code may be stored in a transitory or non-transitory manner. Examples of computer-readable mediums include memory devices, optical storage devices, integrated circuits, servers, online software, etc. Fig. 6 shows by way of example a memory card 400.

[0132] Fig. 7 is a block diagram illustrating an exemplary data processing system 1000 that may be used in the embodiments described in this specification. Such data processing systems include data processing entities described in this specification, including but not limited to a control system or a device participating in the training or any other federated learning entity. The data processing system 1000 may include at least one processor 1002 coupled to memory elements 1004 through a system bus 1006. As such, the data processing system may store program code within memory elements 1004. Furthermore, processor 1002 may execute the program code accessed from memory elements 1004 via system bus 1006. In one aspect, data processing system may be implemented as a computer that is suitable for storing and / or executing program code. It should be appreciated, however, that data processing system 1000 may be implemented in the form of any system including a processor and memory that is capable of performing the functions described within this specification. The memory elements 1004 may include one or more physical memory devices such as, for example, local memory 1008 and one or more bulk storage devices 1010. Local memory may refer to random access memory or other non-persistent memory device(s) generally used during actual execution of the program code. A bulk storage device may be implemented as a hard drive, solid state disk or other persistent data storage device. The data processing system 1000 may also include one or more cache memories (not shown) that provide temporary storage of at least some program code in order to reduce the number of times program code is otherwise retrieved from bulk storage device 1010 during execution.

[0133] Input / output (I / O) devices depicted as input device 1012 and output device 1014 optionally can be coupled to the data processing system. Examples of input devices may include, but are not limited to, for example, a microphone, a keyboard, a pointing device such as a mouse, a game controller, a Bluetooth controller, a VR controller, and a gesture-based input device, or the like. Examples of output devices may include, but are not limited to, for example, a monitor or display, speakers, or the like. Input device and / or output device may be coupled to data processing system either directly or through intervening I / O controllers. A network adapter 1016 may also be coupled to data processing system to enable it to become coupled to other systems, computer systems, remote network devices, and / or remote storage devices through intervening non-public or public networks. The network adapter may comprise a data receiver for receiving data that is transmitted by said systems, devices and / or networks to said data and a data transmitter for transmitting data to said systems, devices and / or networks. Radios, modems, cable modems, and ethernet cards are examples of different types of network adapter that may be used with data processing system 1000.

[0134] As shown in Fig. 7, memory elements 1004 may store an application 1018. It should be appreciated that data processing system 1000 may further execute an operating system (not shown) that can facilitate execution of the application. The application, being implemented in the form of executable program code, can be executed by data processing system 1000, e.g., by processor 1002. Responsive to executing the application, the data processing system may be configured to perform one or more operations to be described herein in further detail.

[0135] For example, data processing system 1000 may represent a control system. In that case, application 1018 may represent an application that, when executed, configures data processing system 1000 to perform the functions described with reference to the control system. In another example, data processing system 1000 may represent a device participating in the training. In that case, application 1018 may represent an application that, when executed, configures data processing system 1000 to perform the functions described with reference to the device.

[0136] An abstract for the present specification may read as follows: A control system and method are provided to support federated learning on a digital twin model, where respective set of devices may each perform training on a local model instance. Within each set, the training and model parameters may be distributed across the devices, with the distribution varying between sets. The control system and method may obtain information on the parameter distribution for a source set and a target set of devices, and determine a parameter mapping to link model parameters between the sets. The mapping may define data processing operations, such as splitting or merging model parameters. Upon completion of a training step by a source device, the control system and method may identify target device(s) for the transfer of model parameters and effect the transfer, which may include effecting data processing operations. The above measures may enable efficient transfer of model parameters while supporting federated learning across distributed devices. It should be noted that the above-mentioned embodiments illustrate rather than limit the invention, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the appended claims.

[0137] In the claims, any reference signs placed between parentheses shall not be construed as limiting the claim. Use of the verb "comprise" and its conjugations does not exclude the presence of elements or stages other than those stated in a claim. The article "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. Expressions such as “at least one of” when preceding a list or group of elements represent a selection of all or of any subset of elements from the list or group. For example, the expression, “at least one of A, B, and C” should be understood as including only A, only B, only C, both A and B, both A and C, both B and C, or all of A, B, and C. The invention may be implemented by means of hardware comprising several distinct elements, and by means of a suitably programmed computer. In the device claim enumerating several means, several of these means may be embodied by one and the same item of hardware. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.

Claims

28CLAIMSClaim 1. A computer-implemented method for supporting federated learning on a digital twin model, wherein the federated learning comprises different sets of devices each training a local model instance of the digital twin model, wherein the training of each local model instance is distributed across the devices within a respective set and the model parameters of the local model instance are distributed across the devices, and wherein the distribution of the training and the model parameters differs across the different sets of devices, the method comprising: for at least a source set of devices and a target set of devices, obtaining information indicative of the distribution of the model parameters across the devices, thereby obtaining parameter distribution information for the source set of devices and the target set of devices; based on the parameter distribution information for the source set of devices and the target set of devices, determining a parameter mapping that identifies how the model parameters distributed across source devices in the source set are linked to target devices in the target set, the parameter mapping further defining data processing operations to support a transfer of the model parameters of a source device to a target device, the data processing operations comprising at least one of: a data split operation which splits model parameters of a source device into split model parameters for two or more target devices; a data merge operation which merges model parameters of two or more source devices to obtain merged model parameters for a target device; upon completion of a training step by a source device, and based on the parameter mapping, identifying one or more target devices as recipient for the model parameters of the source device, and effecting the transfer of the model parameters from the source device to the identified one or more target devices, the transfer comprising executing the data processing operations defined by the parameter mapping.Claim 2. The method according to claim 1, further comprising determining whether the identified one or more target devices are ready to receive the model parameters, and effect the transfer of the model parameters to the identified one ormore target devices provided that said target devices are ready to receive the model parameters.Claim 3. The method according to claim 1 or 2, further comprising managing readiness flags for respective devices, the readiness flags indicating: whether a source device has completed a training step and its model parameters are ready to be transferred; and whether a target device is ready to receive the model parameters from the source device; wherein the transfer is executed subject to both the source device and the identified one or more target devices having a set readiness flag.Claim 4. The method according to claim 3, wherein managing the readiness flags for the respective devices comprises at least one of: querying the respective devices to determine their readiness status; and receiving readiness signals from the respective devices indicating their readiness status.Claim 5. The method according to any one of claims 1 to 4, further comprising caching the model parameters during the transfer to enable asynchronous transfer of the model parameters from the source device to the identified one or more target devices.Claim 6. The method according to claim 5, wherein training of the local model instance is performed by a set of devices using local area communication or device-to- device communication, wherein the transfer of model parameters between different sets of devices is performed via a wide area network, wherein the wide area network comprises one or more cache nodes for storing model parameters of source devices, and wherein the method further comprises distributing cached model parameters from the source set of devices to different target sets of devices participating in the federated learning.Claim 7. The method according to claim 6, wherein the wide area network is a mobile telecommunications network that supports network slicing, and wherein the method further comprises using a dedicated network slice for communication between the different sets of devices participating in the federated learning.Claim 8. The method according to claim 6 or 7, further comprising adjusting a timing of transfers between the source set of devices and the target set of devices to reduce traffic surges over the wide area network.Claim 9. The method according to any one of claims 1 to 8, wherein the training of the local model instance is distributed sequentially across the devices resulting in devices assigned to earlier stages in said sequence completing their training before devices assigned to later stages, wherein the method further comprises prioritizing the transfer of model parameters associated with the earlier stages in the sequence over the transfer of model parameters associated with the later stages.Claim 10. The method according to any one of claims 1 to 9, further comprising prioritizing a transfer of model parameters to target devices that are slower to complete their training step over target devices that are faster to complete their training step.Claim 11. The method according to any one of claims 1 to 10, wherein the local model instances of the digital twin model are updated after training by a respective set of devices by partial retraining of the local model instance, the method further comprising identifying which source devices of the source set of devices have updated model parameters and selectively effecting the transfer of the updated model parameters to one or more target devices in accordance with the parameter mapping.Claim 12. A transitory or non-transitory computer-readable medium comprising instructions, which when executed by a processor system, cause the processor system to perform the method according to any one of claims 1 to 11.Claim 13. A control system for supporting federated learning on a digital twin model, wherein the federated learning comprises different sets of devices each training a local model instance of the digital twin model, wherein the training of each local model instance is distributed across the devices within a respective set and the model parameters of the local model instance are distributed across the devices, and wherein the distribution of the training and the model parameters differs across the different sets of devices, the control system comprising: a network interface for network access to the different sets of devices; a processor subsystem configured to:for at least a source set of devices and a target set of devices, obtain information indicative of the distribution of the model parameters across the devices, thereby obtaining parameter distribution information for the source set of devices and the target set of devices; based on the parameter distribution information for the source set of devices and the target set of devices, determine a parameter mapping that identifies how the model parameters distributed across source devices in the source set are linked to target devices in the target set, the parameter mapping further defining data processing operations to support a transfer of the model parameters of a source device to a target device, the data processing operations comprising at least one of: a data split operation which splits model parameters of a source device into split model parameters for two or more target devices; a data merge operation which merges model parameters of two or more source devices to obtain merged model parameters for a target device; upon completion of a training step by a source device, and based on the parameter mapping, identify one or more target devices as recipient for the model parameters of the source device, and effect the transfer of the model parameters from the source device to the identified one or more target devices, the transfer comprising executing the data processing operations defined by the parameter mapping.Claim 14. A telecommunications network comprising the control system according to claim 13.Claim 15. The telecommunications network according to claim 14, wherein the control system is embodied by at least one of: a Network Data Analytics Function (NWDAF); an Artificial Intelligence and Machine Learning server (AI / MLapp); and an Application Data Analytics Enablement Server (ADAES), of the telecommunications network.

Images