Compression of datasets in communication networks

Abstract

According to a first aspect, there is provided a computer-implemented method performed by a first node. The first node has a first dataset. The method comprises using (501) a trained autoencoder to compress the first dataset, wherein the trained autoencoder comprises an encoder that generates a first compressed dataset from the first dataset, and a decoder that decompresses the first compressed dataset to generate a first decompressed dataset; determining (503) a first actual compression performance of the autoencoder based on the first decompressed dataset relative to the first dataset; sending (505) an indication of the first actual compression performance to a second node; receiving (507), from the second node, a first target compression performance; and updating (509) the autoencoder according to the first target compression performance.

Description

[0001] Compression of datasets in communication networks

[0002] Technical Field

[0003] This disclosure relates to compression of datasets in communication networks.

[0004] Background

[0005] Machine Learning (ML) Model management in distributed environments: Training ML models in telecommunication networks can be challenging when the data is distributed across multiple locations. This is because the datasets may contain sensitive information (especially when they are collected directly from mobile terminals, User Equipments (UEs) that contain sensitive information about users and behaviours), and it can be hard to transfer them across different administrative boundaries and geographical zones.

[0006] One example is when a Communication Service Provider (CSP) deploys ML models at customer premises, but the model design and initial training is done at the CSPs premises, or when a CSP has regional branches that work autonomously. To address this issue, there are various approaches available for managing ML models with distributed data, including centralised federated learning (with decentralised nodes communicating over a central authority) and split learning. Centralised federated learning is described in “Federated Learning-Methods, Applications and beyond” by Heusinger, Moritz, et al., arXiv preprint arXiv:2212.11729 (2022), found at: https: / / doi.org / 10.14428 / esann / 2021 .ES2021-4. Split learning is described in “Split Learning vs Federated Learning and its Use Cases” by Basu, Sayantani, 20 Jan. 2021 , found at: https: / / piyubasu.medium.com / split-learning-vs-federated-learning-and-their-use-cases- fe96d5c1394a.

[0007] A high-level overview of these approaches and their respective advantages and limitations is provided below, focusing on scenarios without vertical splits of datasets (that is, where features of the datasets are not divided into separate subsets or partitions based on their sources), and where available features are standardised or, at least, specified. A generic terminology is used that distinguishes between edge sites where datasets are collected, and central sites where processing of data, models, or both is carried out.

[0008] In the centralised approach, data from the edge sites is transferred to a central location for model design and training. After training, the model is either transferred back to the edge sites or kept at the central location for inference. Fig. 1 illustrates the centralised approach, and shows a central site and four edge sites that communicate with the central site. In step 1 of Fig. 1 , raw data (which can include labels, where appropriate) is transferred from the edge sites to the central site. In step 2 of Fig. 1 , the ML model design and training takes place. While model deployment is not explicitly shown in Fig. 1 , it can be performed either at the central site or at the edge sites.

[0009] This approach is suitable for scenarios where edge devices have limited computational resources, and the datasets are relatively small. One advantage of this approach is that the central location can take advantage of more powerful hardware and advanced algorithms to perform training.

[0010] However, the centralised approach has some drawbacks. The transfer of data to the central site can be slow, costly, and may raise data security concerns. Additionally, the central site may not be able to access all the data due to legal or technical constraints, which can limit the performance of the model. Even it gets all the data, there is no guarantee that a decentralised node would perform better with a centralised model as compared to the scenario of training that node with only a subset of other similar nodes. In summary, one-fits-all basis models may not perform well and need personalisation to meet model efficacy requirements.

[0011] Federated Learning: In the federated learning (FL) approach, the model is designed in a central site and distributed to the edge sites for training. This eliminates the need to transfer raw data from the edge sites to a central location. Although this approach can be applied to scenarios where the edge devices have a large amount of data, it is particularly suitable for scenarios where there are many decentralised nodes, and each node has a small amount of sensitive data. When models are aggregated, they can learn from each other, resulting in improved model efficacy. Regardless of the scenario, legal or technical constraints prevent the central location from accessing all the data.

[0012] One benefit of the federated learning approach is that it preserves the security of the data at the edge sites, as the data never leaves the local devices. However, federated learning can be challenging to implement, as a certain degree of alignment in the versions of local models (and associated signalling) is needed to create a global model that performs well.

[0013] Split learning: In the split learning approach, the model is divided between the edge devices and a central location, typically with the edge devices holding the data and the initial layers of the model (head section) and the central location storing the last layers (tail section). This topology is particularly useful when edge sites have large amounts of data that the central location cannot access due to legal or technical constraints, like federated learning. Split learning also addresses scalability limitations by allowing computationally intensive tasks to be offloaded to the central location, making it suitable for distributed environments with multiple collaborating clients and large models that comprise multiple layers and neurons. To further enhance security of the data, alternative topologies may be used, such as having a small number of layers (even just one) at the edge nodes, the bulk of the model’s layers at the central location, and a final layer at the edge nodes. This approach offloads the heavy computation to the server while keeping the input and label data at the edge sites.

[0014] Split learning offers several benefits, including addressing data security concerns, reducing the computation overhead on client nodes, reducing the attack surface (i.e. if parameters shared between an edge and central node are compromised, the rest of the model is not affected as the other edge parameters are different), and being suitable for computation-limited Internet of Things (loT) devices. However, one drawback of split learning is the high communication cost during the training process. Even though each iteration of the training cycle (epoch) passes on smaller datasets, performing the entire training cycle requires multiple epochs, resulting in a significant amount of data transferred from the edge sites to the central site. As a result, the total amount of data transferred may be comparable or even greater than the original dataset.

[0015] Autoencoders: An Autoencoder (AE) is a type of artificial neural network that can learn how to compress and then decompress data. An autoencoder is made of an encoder and a decoder, which are both neural networks. The encoder compresses the input data into a lower-dimensional representation, while the decoder reconstructs the original data from this compressed representation.

[0016] Autoencoders are trained by minimising the difference between the input and the output of the network, typically using the Mean Squared Error (MSE) loss function. During training, the encoder learns to capture the most salient features of the input data, while the decoder learns to reconstruct the original data from the compressed representation.

[0017] Autoencoders have a wide range of applications, including data compression, image and video processing, anomaly detection, and feature extraction. They are particularly useful for unsupervised learning, where the goal is to learn a compact representation of the input data without the need for labelled examples.

[0018] Autoencoders are described in “Autoencoders in Deep Learning: Tutorial & Use Cases” by Bandyopadhyay, Hmrishav, 2 Mar. 2023, found at https: / / www.v7labs.com / blog / autoencoders- guide.

[0019] Summary

[0020] Both the federated learning and split learning approaches have been designed to address concerns surrounding the use of large datasets hosted by edge sites, where datasets cannot be transferred to a central site due to security and technical reasons (e.g., bandwidth limitations for large size data delivery). This is often the case where the central site is a telecommunications equipment supplier, and the edge sites are its customers (Communications Service Providers, CSPs).

[0021] However, both approaches have a significant precondition, namely that the ML model to be trained at the edge sites (in federated learning) or to be split between edge and central nodes (in split learning) has already been designed. This means that either at least one instance of edge datasets has been sent to the central site, or that edge sites have generated a synthetic version of their datasets that can be safely shared with the central site.

[0022] Unfortunately, these preconditions may not always be feasible. For example, the creation of a ML model for a given use case cannot always depend on the availability of data, as sharing customer data is a security concern. Alternatively, generating a Generative Adversarial Networks (GAN)-based model to create synthetic data requires cooperation and involvement from the edge sites, which may not be feasible.

[0023] There are additional drawbacks to consider when using distributed ML training technologies. Open Neural Network Exchange (ONNX) is an open-source format that enables interoperability between Deep Learning (DL) frameworks, allowing models to be trained in one framework and then easily transferred to another framework for inference. However, in federated learning, while neutral formats like ONNX can be utilised to exchange ML models between edge and central nodes, the translation from popular Deep Learning (DL) frameworks like Tensorflow / Keras or Pytorch to ONNX is not always smooth. Consequently, model sharing between edge and central nodes usually requires all nodes to use the same type of DL framework, which may not be suitable for all edge sites. For example, if the model generated by the central site is saved using the TensorFlow binary format, it might not be deployed for training in an edge site that only supports PyTorch.

[0024] In split learning, the drawbacks are different. Indeed, there are no dependencies between the DL frameworks used to implement the tail and head sections of the model, except for an agreement on the size of the cut layer. However, the total amount of data transferred back and forth between edge and central sites is not insignificant, and the communication process to train the model can be lengthy.

[0025] Thus, the existing approaches that overcome security constraints require a preliminary design of the ML model to train. Unfortunately, there are scenarios where this may not be possible, and new approaches will need to be designed to address these challenges.

[0026] Certain aspects of the disclosure and their embodiments may provide solutions to these or other challenges. The techniques described herein aim to provide any or all of energy-aware, network footprint-aware, and model efficacy-aware data compression for efficient machine learning model training on a dataset collected from distributed nodes.

[0027] According to a first aspect, there is provided a computer-implemented method performed by a first node. The first node has a first dataset. The method comprises using a trained autoencoder to compress the first dataset, wherein the trained autoencoder comprises an encoder that generates a first compressed dataset from the first dataset, and a decoder that decompresses the first compressed dataset to generate a first decompressed dataset; determining a first actual compression performance of the autoencoder based on the first decompressed dataset relative to the first dataset; sending an indication of the first actual compression performance to a second node; receiving, from the second node, a first target compression performance; and updating the autoencoder according to the first target compression performance.

[0028] According to a second aspect, there is provided a computer-implemented method performed by a second node. The method comprises: (i) receiving, from a first node, an indication of a first actual compression performance for a trained autoencoder, wherein the autoencoder has compressed a first dataset, and wherein the first actual compression performance represents the compression performance of a first decompressed dataset output by a decoder of the autoencoder relative to the first dataset; (ii) determining if the first compression performance meets a criterion; (iii) if the first compression performance does not meet the criterion, determining a first target compression performance; and (iv) sending an indication of the first target compression performance to the first node.

[0029] According to a third aspect, there is provided a computer program product comprising a computer readable medium having computer readable code embodied therein, the computer readable code being configured such that, on execution by a suitable computer or processor, the computer or processor is caused to perform the method according to the first aspect, the second aspect, or any embodiments thereof.

[0030] According to a fourth aspect, there is provided a node configured to perform the method according to the first aspect, the second aspect, or any embodiments thereof.

[0031] According to a fifth aspect, there is provided a node comprising a processor and a memory, said memory containing instructions executable by said processor whereby said node is operative to perform the method according to the first aspect, the second aspect, or any embodiments thereof.

[0032] Certain embodiments may provide one or more of the following technical advantage(s). For example, embodiments can address the ‘cold start’ problem with ML models. In particular, the techniques do not require a preliminary ML model to have been designed, and the techniques provide means for acquiring datasets to design and train the initial ML model.

[0033] Embodiments can address the challenges associated with security and transferring sensitive data. As datasets are compressed, they lose any information traceable to specific individuals.

[0034] When compared to centralised or split learning approaches, the techniques minimise the total amount of data required to be transferred from edge sites to a central site.

[0035] When compared to federated learning, the techniques loosen the iterative and frequent data exchange requirements for the DL frameworks used in edge and central sites.

[0036] Embodiments of the techniques provide more control over model tuning. In particular, the performance of the trained ML model is a function of both the performance of the autoencoder, and the trained model itself. The better the performance of the autoencoder, the less noise there is in the input data, and the better the learning is for the ML model. Improving hyper-parameters of the autoencoder can improve the overall ML model performance.

[0037] Certain embodiments can adaptively assign a node to be a server node in a server-less environment. The assignment of a node to be a server node can depend on the compression capabilities of the nodes, as well as the characteristics of the dataset.

[0038] Certain embodiments adaptively adjust the number of neurons at the bottleneck layer (or size of the latent space) of the respective autoencoders so that they are optimised to reduce network footprint, as well as maintaining a good level of model efficacy.

[0039] Brief Description of the Drawings

[0040] Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings, in which:

[0041] Fig. 1 illustrates a centralised approach to the training of a ML model in a distributed environment;

[0042] Fig. 2 is a simplified illustration of a single central model approach;

[0043] Fig. 3 is a simplified flow chart illustrating operations in a system according to the techniques described herein;

[0044] Fig. 4 is a diagram illustrating the training and retraining of an autoencoder according to various embodiments;

[0045] Fig. 5 is a flow chart illustrating a method performed by a first node in accordance with some embodiments;

[0046] Fig. 6 is a flow chart illustrating a method performed by a second node in accordance with some embodiments;

[0047] Fig. 7 is a block diagram of a node according to various embodiments; and Fig. 8 is a block diagram illustrating a virtualization environment in which functions implemented by some embodiments may be virtualized.

[0048] Detailed Description

[0049] Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. Embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art.

[0050] Fig. 2 illustrates an approach to the training of ML models that the techniques described herein can be applied to. In particular, Fig. 2 illustrates a ‘single central model’ approach. In this approach a central site / node 201 is responsible for training and / or maintaining a ML model that is used by one or more edge sites / nodes. Two edge sites are shown, Edge Site A 202 and Edge Site B 203. These edge sites 202, 203 have respective datasets that are to be shared in compressed form with the central site 201 , and used by the central site 201 to train the ML model. The central site 201 can share the trained ML model with the edge sites 202, 203, or the central site 201 can share the output of the trained ML model with the edge sites 202, 203. An orchestrator node 204 is also shown, that in certain embodiments can be used to coordinate the operations of the central site 201 and / or the edge sites 202, 203. The signalling between the central site 201 and the edge sites 202, 203 is shown in solid lines, and the signalling by the orchestrator node 204 to coordinate the operations of the central site 201 , and the edge sites 202, 203 is shown with dashed lines.

[0051] Based on the constraints outlined in the Background section, this disclosure aims to provide any or all of energy-aware, network footprint-aware, and model efficacy-aware data compression for efficient machine learning model training on a dataset collected from distributed nodes. This disclosure addresses two main scenarios: a) a single central model serving multiple edge sites as shown in Fig. 2; and b) multiple central models, each serving a single edge site or a group of similar edge sites. The scenario chosen depends on the degree of similarity between the edge datasets.

[0052] The techniques described herein envisage the use of an Autoencoder (AE) to compress and decompress edge datasets. An orchestrator (which can be, or be at, the central site, or it can be a separate node) can set several initial parameters that are communicated to all site(s) for appropriate autoencoder creation. These initial parameters can include any of: the exact set of input features, the size of the latent space, the loss function to be used by the autoencoder (e.g. reconstruction error based on Mean Squared Error, MSE), and the target loss function value. The size of the latent space (if specified) should be a small fraction of the feature space size, so that a significant saving in the size of the transferred dataset is carried out. The autoencoder can be implemented using any kind of DL framework (just as with the split learning approaches), following the constraints set by the central site.

[0053] After autoencoder training, the decoder section is discarded (or otherwise not used). An indication of the compression performance of the autoencoder (e.g. reconstruction loss values) and the dataset size (i.e. size of data at the output of the encoder bottleneck layer) are sent to the orchestrator. The orchestrator can assign the node with largest bottleneck layer data size and / or worst compression performance (e.g. highest reconstruction loss) as a central server node. The reason may be that this node has many samples that are not easy to compress. Instead, the other nodes, i.e. edge nodes, that have less compressed data at the bottleneck layer are requested to the send data to the assigned central node. Next, the edge site uses the encoder to compress the original dataset, and transfers the compressed dataset, along with the corresponding labels, to the central site. The central site (or data scientists at the central site) can use the compressed dataset and associated labels to design and train the actual ML model, as if the compressed dataset were a raw dataset. In a variation to the above, the central server / node / site may be pre-selected, in which case the orchestrator is not required to a select a node to be the central node.

[0054] The selection of the neuron count at the bottleneck layer of the AE may not be straightforward. On the one hand, it is preferred for this layer to be made as small as possible to reduce the size of the output data (hence reducing the potential network footprint when this output data is transferred to another node). On the other hand, the bottleneck layer should not be too small, giving enough room for learning a representation of the input data. Having too few neurons at the bottleneck layer may output compressed data that is not able to represent the original input dataset, and negatively impact the final ML model.

[0055] Therefore, embodiments provide a feedback mechanism where a node (e.g., a server or orchestrator) provides feedback to the local edge node so that the compression performance (e.g. bottleneck layer size) may be adjusted.

[0056] In some cases, or for some nodes, the data may not be easily compressed, and in those cases a ‘serverless approach’ may be of benefit, as outlined above. In this approach, the node with the largest-dimension input dataset that cannot be easily compressed with an AE model can be assigned a server role, and therefore receives compressed output data from the other local (edge) nodes. Therefore, embodiments may consist of a server selection phase based on the compression performance of the dataset by local nodes, then compression performance (e.g. bottleneck layer) optimisation with respect to the feedback received from the selected server node.

[0057] The type of approach (i.e. a single central ML model, or several central ML models) can depend on the statistical properties of the edge datasets. In an independent and identically distributed setting, the autoencoders in different edge sites might converge to similar weights, hence the activations (compressed data) might be similar and therefore a single central ML model could serve all the edge sites. However, in a non-independent and identically distributed setting, several central ML models would be needed (serving one edge site or a group of similar edge nodes together).

[0058] In a situation where new edge sites that have limited hardware capabilities join the system, it can be important to reduce the computation overhead at the edge nodes. One approach is to follow a transfer learning approach and enable a warm start for the training. In this approach, edge sites can send the autoencoder models to the central site and the central site can distribute the autoencoders (or an aggregation of similar autoencoders) to new edge sites (e.g. based on node data similarity) so that they start to train a new autoencoder from existing autoencoder(s). However, this variant has the same drawbacks regarding the exchange of ML models mentioned above in the FL approaches: all the sites are required to be able to deploy the autoencoder model sent from other sites. If it is possible, in certain embodiments the new edge site can further train the autoencoder received from the central site, compress its dataset(s) using the encoder section, and send the compressed data (which includes labels, if applicable) to the central site.

[0059] It will be appreciated that the above discussion is applicable to a ‘standard’ AE, with the compression performance adjustment performed via readjustment of the bottleneck layer. There are other variants of AE, such as a variational autoencoder (VAE). The functionality of a VAE is similar to a ‘standard’ AE. However, in the case of VAE, the bottleneck layer is replaced by a latent space, and hence the latent variable dimensionality will play a similar role (zO, z1 , ...) to the bottleneck layer size in an AE. In the VAE case, the data can be generated from random Gaussian noise, and hence no data transfer would be needed over the communication link at all. Instead, the decoder and the corresponding latent space will be transferred only once (in contrast to the data stream in the AE case). Still, the quality of the generated data would highly depend on the bottleneck layer size in the AE embodiments, and the latent space size in the VAE embodiments. Therefore, the proposed feedback mechanism can be applied to many AE variations.

[0060] As noted above, this disclosure provides solutions to avoid edge sites having to send raw datasets to a central site where there used to create or train a ML model. Instead, the edge sites train autoencoders and use the encoding section of the autoencoder to compress the dataset of the respective edge site. Feedback can be provided from an orchestrator or the server node to the edge sites to enable bottleneck layer tuning (or latent space tuning) of the local (V)AE models to enable a suitable level of compression of the dataset and / or a suitable level of compression performance (e.g. reconstruction loss). The compressed dataset is transferred to the central site and used to train one or many ML model(s). In some embodiments, autoencoders can be sent to the central node, and the autoencoders subsequently delivered to new edge sites joining the system.

[0061] As noted, certain embodiments provide an adaptive server node selection from among a number of nodes (for example a node where the compression impacts model efficacy). The feedback mechanism to determine the right level of compression (e.g. to reduce the volume of the transferred data and to increase the model efficacy) in between two or more decentralised ML nodes is therefore a useful feature of the disclosed techniques, as it reduces the size of data to be transmitted over the communication link.

[0062] The flow chart in Fig. 3 illustrates the operations in a system such as that shown in Fig. 2 according to embodiments of the techniques described herein. Five main steps or stages are shown in Fig. 3. The steps or stages are the Establishment stage 301 , the Node Data Compression stage 302, the Central Node Selection stage 303, the Compressed Data Transmission stage 304, and the Central Node Model Training stage 305.

[0063] Each of the edge nodes and the central node are considered to have a respective dataset that comprises a respective set of measurements (otherwise known as ‘observations’) of a plurality of features (e.g. operating parameters, Key Performance Indicators (KPIs), etc.). That is, each dataset has measurements of a shared set of features. The features and measurements are associated with a communication network. That is, the features, and the measurements thereof, were obtained in respect of one or more communication networks. The datasets may relate to the same communication network, or two or more of the datasets may relate to different communication networks. The features can relate to the performance of a communication network, or devices (e.g. mobile terminals, User Equipments (UEs)) using the communication network. In addition to the features measurements, the datasets can comprise one or more labels that are associated with one or more measurements and that provide an indication of the status of the communication network at the time that the measurements were obtained. These labels may have been provided by an expert user through manual analysis of the dataset, or automatically by an algorithm or model that is able to label data in a dataset.

[0064] In the Establishment stage 301 , the central node or orchestrator can provide instructions / parameters for training autoencoders to all of the edge nodes (and to the central node if applicable). These instructions can be considered to be part of a ‘Data Compression Contract’.

[0065] The instructions / parameters / Data Compression Contract provided to the edge nodes (and central node, if applicable) can include any one or more of the following types of information:

[0066] • A use case identifier. For example, a use case can be a KPI ‘ / V’ estimation / prediction task (supervised, unsupervised, or reinforcement based). / V can be throughput, delay, loss rate, etc., and it is useful to record each model per task so that similar tasks can be indexed and grouped, or suitable compression levels can be proactively selected per use case identifier based on historical data.

[0067] • The specific features that must be included in the dataset.

[0068] • The labels that are to be included, if relevant for the use case (noting that labels are not necessary in unsupervised learning scenarios).

[0069] • Maximum allowed uplink bandwidth for the dataset transmission (this provides an indication of how big / small the compressed dataset needs to be for transmission to the central node).

[0070] • Instructions on the transformations and normalisation processes (e.g. data 'cleaning’, data scaling, etc.) that the features and labels must undergo when the labels are built.

[0071] • Information on the temporal time span that the measurements in the dataset must belong to, if relevant to the use case.

[0072] • Optional maximum and minimum limits for the number of observations / measurements in the dataset.

[0073] • The desired size of bottleneck layer in the case of an autoencoder, or the desired size of the latent space in the case of a VAE. This desired size indicates the number of features that the compressed dataset should have and / or the size of the compressed dataset to transfer over the communication link.

[0074] • The loss function to be used by the autoencoder, and the target compression performance value (e.g. target reconstruction loss function value).

[0075] • An inference deployment mode, e.g., “central” if the central ML model is kept in the central node; “edge” if the central ML Model will be downloaded to the edge node. In the latter case, the instructions can include the format or frameworks that the central node supports (depending on the supported framework, the edge node might not support the “edge” inference model).

[0076] Thus, the instructions / parameters provide the edge nodes with information useful for subsequent upload of the compressed dataset and associated labels.

[0077] The edge node(s) can acknowledge the instructions provided by the central node or orchestrator in the Establishment stage 301 , and then each edge node implements the operations defined in the Node Data Compression stage 302.

[0078] In the Node Data Compression stage 302, each edge node implements the Data Ingestion and Refinement operations specified in the Data Compression Contract received in the Establishment stage 301. The result of the Node Data Compression stage 302 is that a compressed dataset is generated. Optionally in or prior to stage 302, an edge node can apply specified operations to generate labels.

[0079] The autoencoder training can be initialised by setting a bottleneck neuron count or latent space size to the value indicated in the received Data Compression Contract. For example, the bottleneck neuron count could be set to b=2. As described further below with reference to Fig. 4, it will be noted that initialisation with low b values, with (preferably monotonically) decreasing neuron count over the intermediate layers from input to output of the encoder, may avoid the need for retraining the autoencoder in the event that the compression level of the dataset needs to change. In particular, it is preferable to initially train the autoencoder to ‘overcompress’ the dataset (to a layer with a small number of neurons) so that ‘retraining’ can be performed by removing one or more final layers of the encoder if the compression level is to be reduced (and thereby increase the value of b). In parallel, if the K last layers of the encoder are removed, then the K first layers are removed from the decoder. By having multiple intermediate layers with a monotonically decreasing neuron count as shown in Fig. 4, the trained autoencoder is modular and allows for flexible ‘retraining’ of the autoencoder to provide a suitable compression level.

[0080] Next in the Node Data Compression stage 302, the edge node trains an autoencoder with the initialised bottleneck neuron count or latent space size (as appropriate for the type of autoencoder used by the edge node). The bottleneck neuron count or latent space size effectively indicates an amount of compression to be achieved by the trained autoencoder. The training of the autoencoder also takes into account the loss function and target reconstruction loss function value specified in the Data Compression Contract.

[0081] With reference to Step 0 of Fig. 4, in this initial training step, the autoencoder is trained so that a multi-layer encoder 401 compresses the dataset of the edge node to generate a compressed dataset, and a multi-layer decoder 402 is trained to decompress the compressed dataset to regenerate the initial dataset, or to regenerate the initial dataset within a permissible error indicated by the target compression performance (which in this illustrated embodiment is referred to as the target reconstruction loss). That is, the reconstruction loss relates to an amount of ‘error’ permitted in the reconstructed (decompressed) dataset relative to the initial dataset.

[0082] Once the initial training is complete, the edge node compresses the dataset using the trained multi-layer encoder (also referred to as the ‘Edge Encoder’), determines the reconstruction loss for the compressed dataset, and sends the reconstruction loss to the orchestrator node (or central node, if applicable). The edge node can also send an indication of the volume of data in the compressed dataset to the orchestrator node.

[0083] As noted in step 1 of Fig. 4, the edge node also sends the multi-layer decoder to the orchestrator node (or central node, if applicable). That is, the edge node sends information or data to the orchestrator node (or central node, if applicable) to enable the orchestrator node or central node to implement the trained multi-layer decoder itself. The version of the multi-layer decoder at the orchestrator node or central node is labelled 403.

[0084] The orchestrator (or central node, if applicable), evaluates the respective reconstruction loss values received from each of the edge nodes, and separately determines, for each edge node, if the reconstruction loss is acceptable. In determining this, the orchestrator can additionally take into account the volume of data in the compressed dataset (if the edge node provides this indication). In particular, the orchestrator can evaluate the volume of compressed data and the reconstruction loss required to achieve that volume of data, and determine whether the autoencoder of that edge node should be retrained with a different reconstruction loss target. The reconstruction loss can be evaluated with respect to a maximum tolerable reconstruction loss value.

[0085] For example, if the reconstruction loss is too high, the orchestrator can determine that a lower reconstruction loss target should be set for the edge node. However, if the reconstruction loss is acceptable but the volume of compressed data is too high, the orchestrator can set a higher reconstruction loss so that the edge node will retrain the autoencoder to generate a more compressed dataset.

[0086] The orchestrator node (or central node, if applicable) sends feedback to each edge node on whether the autoencoder has been trained adequately. In particular, the feedback can comprise a new target reconstruction loss value for the autoencoder.

[0087] The edge node can then retrain the autoencoder based on the new target reconstruction loss value.

[0088] Preferably, if the initial autoencoder was trained to ‘over compress’ the dataset, the feedback will indicate that the dataset should be compressed less. In this case, as shown in Step 2 of Fig. 4, the last bottleneck layer of the multi-layer encoder (which was originally initiated with a very low b value and includes 2 neurons in Fig. 4) is removed to produce a retrained multi-layer encoder 404. The same is applied to the multi-layer decoder at the orchestrator or central node to produce a retrained multi-layer decoder 405.

[0089] The edge node repeats the above steps using the retrained multi-layer encoder 404. That is, the edge node compresses the dataset with the retrained multi-layer encoder 404, determines the reconstruction loss for the compressed dataset, sends this to the orchestrator or central node, and awaits further feedback. If the feedback indicates further retraining is required (and specifically less compression is required), one or more further layers can be removed from the multi-layer encoder and multi-layer decoder. This is shown in Step 3 of Fig. 4 to generate multilayer encoder 406 and multi-layer decoder 407, and subsequently in Step 4 to generate multilayer encoder 408 and multi-layer decoder 409. If the feedback on the initial autoencoder was that the dataset was not compressed enough, the edge node will need to perform retraining of the autoencoder to increase the number of layers with a monotonically decreasing number of neurons in each layer in the encoder and decoder.

[0090] Once the autoencoders of the edge nodes have been sufficiently trained (i.e., the reconstruction loss and / or data volume is acceptable), the process can pass to the Central Node Selection stage 303 if the central node for the ML model training is not already determined, or the process can pass directly to the Compressed Data Transmission stage 304.

[0091] The Central Node Selection stage 303 is performed by the orchestrator node in order to select the edge node that is to be the central node. For this stage 303, the orchestrator node ranks each of the edge nodes according to the size of the compressed dataset (from the fully trained autoencoder for the edge node). The size of the compressed dataset can be given by the product of the number of bottleneck neurons (n_bottleneck_neuron) and the number of measurements (samples) in the dataset (n_samples). The orchestrator node also ranks each of the edge nodes according to the reconstruction loss of the decoded compressed dataset (for the fully trained autoencoder for the edge node).

[0092] The orchestrator node selects the edge node that has the highest reconstruction loss, the highest data size, orthe highest combined representation of the reconstruction loss and data size, to be the central node. By selecting the edge node with the highest reconstruction loss to be the central node, there is now no need to compress that edge node’s dataset, meaning that the reconstruction loss effectively becomes irrelevant. By selecting the edge node with the highest data size for the compressed dataset, there is now no need to transfer / communicate that (large) compressed dataset to another central node.

[0093] Further characteristics of the edge nodes that can be taken into account when selecting the node to be the central node (for example where several edge nodes have similar reconstruction losses and / or similar data sizes) can include hardware capabilities, computation and communication availabilities, an impact of the reconstruction loss on the efficacy of the ML model to be trained.

[0094] Once the orchestrator node has determined which edge node will be the central node, the orchestrator node informs the edge nodes of which node will be the central node.

[0095] Then, in Compressed Data Transmission stage 304, the (remaining) edge nodes use the trained multi-layer encoder of the autoencoder to compress their respective datasets, and they send the compressed datasets (effectively the output of the bottleneck layer of the autoencoder) to the central node. The sent compressed dataset can include the relevant labels for the status of the communication network(s), or the edge nodes can send the relevant labels to the central node with the compressed dataset. Effectively in the Compressed Data Transmission stage 304, the edge nodes discard the multi-layer decoder section of the trained autoencoder.

[0096] In some embodiments, the central node will train the ML model using the compressed (lower-dimensional) datasets received from the edge nodes. However, if the efficacy of the ML model obtained by training based on compressed datasets is too low, then it may be beneficial for the central node to decompress the received compressed datasets, and to train the ML model using the decompressed (higher dimensional) datasets. In these embodiments, the edge nodes can send their respective multi-layer decoders to the central node (or send information enabling the central node to regenerate the multi-layer decoders), so that the central node can decompress the datasets before model training.

[0097] In addition to sending the compressed dataset to the central node, the edge nodes can send the reconstruction loss to the central node. If a VAE-based autoencoder is used, a correlation matrix quantifying the pair-wise correlation between attributes in the dataset at the edge node may also be sent to the central node. This correlation matrix is expected to be of size / V* / V, where / V is the number of input attributes. This correlation matrix is provided for reference to assure the central node that the correlations between the attributes in the reconstructed dataset is sustained with the original dataset at the edge node.

[0098] Finally, in the Central Node Model T raining stage 305, one or more ML models are designed and / or trained by the central node using the datasets and labels (if provided) sent by the edge nodes in stage 304. The training also makes use of the dataset available at the central node. The model trained by the central node is referred to as the ‘Central Model’.

[0099] Once the efficacy of the ML model is deemed satisfactory, the ML model is available to be deployed and used for inference. The edge nodes can be notified by the central node or orchestrator that the ML model is ready for use. It will be noted that inference will require the use of a pipeline with two stages:

[0100] (i) Data Processing and Encoding: Data is subject to the data transformation operations (e.g. selecting attributes, data cleaning, data scaling, etc., and encoding by the encoder) implemented in the Node Data Compression stage 302; and then the edge node requiring the inference compresses the new dataset to be evaluated using the trained multi-layer encoder.

[0101] (ii) Inference. The resulting feature vector (the new compressed dataset) is used to query the Central Model.

[0102] There are many alternatives to implementing the inference pipeline. Depending on the alternative used, several procedures can be implemented:

[0103] • For example, if the Inference Deployment Mode described in the Establishment stage 301 is set to “edge”, and the edge node supports any of the deep learning framework supported by the central node, the Central Model can be sent to the edge node so that the whole inference pipeline is implemented at the edge node.

[0104] • If set to “central”; the Data Processing and Encoding stage remains in the edge node, while the Inference stage is implemented in the central node. To enable that, the notification sent from the central node to the edge node(s) includes details about the Application Programming Interface (API) needed to query the central model.

[0105] The efficacy of the trained model can be monitored by the orchestrator or central node. In the case of unsatisfactory model efficacy (for example due to degradation of the model efficacy over time), the central node can inform the orchestrator node, and the orchestrator node can adjust the Data Compression Contract parameters (e.g. the bottleneck layer size at the edge nodes, and optionally reselecting central node). As above, the orchestrator has the goal to minimise the product of bottleneck layer neuron count and the number of samples, node reconstruction loss of AE models at the edge (that is received from the edge nodes), and maximise the central model efficacy. However, the readjustment of the bottleneck layer and the sending of the new compressed dataset to the central node multiple times may result in the transmission of a large volume of data if the whole dataset is used. Thus, in some embodiments (which can be applied to the initial performance of stage 302), training the autoencoder and determining the ‘right’ compression level (i.e. based on the reconstruction loss and / or data volume of the compressed dataset) may only use a subset of the edge node’s dataset. This would reduce the amount of data transmitted between the edge node and central node until an equilibrium point is reached. Once this point has been reached, the edge node can compress the full available dataset and then send the full compressed dataset to the central node.

[0106] The techniques described herein can be used in various different scenarios.

[0107] One scenario is with a Data Ingestion Architecture, as described and illustrated in “Data ingestion architecture for telecom applications” by Anna-Karin Rbnnberg et al. in Ericsson Technology Review 03-2021 . In the Data Ingestion architecture, a Customer Network collects a dataset, and then sends it to an External Application Cluster only once. This has the benefit of reducing the communication overhead by avoiding retransmission of a dataset each time a new application needs to train on the dataset. However, the volume of the data that needs to be transmitted in a given time may still be large, and therefore the techniques described herein may help by compressing the dataset based on the requirements of the application. There is a Data Refinement Function in the Customer Network that applies policies to the dataset regarding what data needs to be transmitted, which attributes are sensitive and need obfuscation before sending, and also a set of data processing procedures. As an extension, the data compression (i.e. the autoencoder) can be implemented in the Data Refinement Helper Function component, and the data can be stored and transmitted over the Data Relay Gateway after a dataset is compressed. This also will necessitate the sending of the decoder to the other end as well.

[0108] While the dataset is meant to be sent over to the External Application Cluster only once, there may be cases where the compression function and feedback loop may be necessary in the case the internal dataset refinement in the Customer Network needs feedback from external applications to improve the data quality.

[0109] Another implementation option for the techniques described herein would be at the External Application Cluster. The Application Cluster may be running many different applications, and each may have different data requirements. These requirements are then fulfilled by the Global Data Catalogue (GDC) that consists of metadata on different datasets and applications. Helper Applications exist that define how to extract transfer and load (ETL) data to the repositories. The Helper Applications can also perform security protocols if some applications require extra security. The techniques described herein can also be implemented in a Helper Application when the dataset that needs to be transmitted to the applications are too large, and the techniques may provide compression that is just good enough while sustaining the overall model efficacy of the applications.

[0110] Another use case is in an edge node deployment. In reinforcement learning applications deployed at the edge nodes, the edge nodes may transfer state information through the data collection interface from edge nodes to a more centralised entity in a centralised training setting. The agents then transfer the local state information to the local trainer and or to the external trainer interfaces.

[0111] Another use case / implementation scenario is a communication network based on a 5thGeneration (5G) core cloud implementation. In this implementation, Network Data Analytics Functions (NWDAFs) have the role of the edge nodes as described above. When datasets are sent over a communication channel, the dataset may be compressed using an encoder. Consumers such as NWDAFs send data to Analytics Data Repository Functions (ADRF) via Nadrf_DataManagement_StorageRequest that consists of collected data and analytics. Then the ADRF stores the dataset. In this case, once the NWDAF optimises the best compression level, it encodes the dataset via the encoder and sends the compressed form of the dataset to the ADRF. This has two advantages: (i) less data will be stored at the ADRF, and (ii) less data will be transferred between the ADRF and the NWDAF (or other consumers). During the compression of the dataset, the NWDAF trains the autoencoder model at a Model Training Logical Function (MTLF). Depending on the historical model efficacy, the best compression levels can be stored. When there are multiple regional NWDAFs each with training capabilities (such as a MTLF) that are deployed in different physical locations, it may be beneficial for these regional NWDAFs to collaborate to train a global central model with the dataset that they obtain from their regional network functions. For this, an orchestrator agent can be deployed that initialises and then obtains statistics (hardware capabilities, communication capabilities, proximity, reconstruction loss, data size at the bottleneck layer of AE models, central model efficacy, etc.) from the regional NWDAFs. Based on the received information the orchestrator can assign a central NWDAF node (or keep the previously selected central NWDAF one). In addition, it can select the remaining nodes as edge NWDAF nodes. The orchestratorthen requests edge NWDAF nodes to compress dataset and send the compressed dataset to the central NWDAF node for use in performing the central model training. The central NWDAF node can inform the orchestrator regarding the efficacy of the central model and the orchestrator may request to readjust the hyper-parameters including central node selection as well as bottle neck layer size at the edge nodes.

[0112] Another use case / implementation scenario is in a communication network that is using an Open-Radio Access Network (O-RAN) configuration. Data collection from gNBs and eNBs to Service Management and Orchestration (SMO): In an O-RAN implementation, the dataset is collected at the SMO from the eNBs / gNBs via 01 interface. Before the dataset is transmitted, a Collector node at the SMO acting as an orchestrator node as described herein requests the dataset be compressed. Depending on the updated autoencoder performance at the SMO, the Collector node can recompute hyper-parameters (e.g. the bottleneck layer neuron count) and may request the edge nodes (eNBs / gNBs) retrain their autoencoder and send the new compressed dataset to the Collector (i.e. the compressed dataset is the dataset at the output of the bottleneck layer of the local encoder models). Moreover, the dataset collected at SMO can further be transferred to Application server or rApp(s). In that case, the SMO trains the autoencoder and may send the decoder to the Application server or rApps for Application servers and rApps can train ML models on the dataset that is decompressed via the received decoder.

[0113] Data collection from Near-Real-Time (Near-RT) RAN Intelligent Controller (RIC) to Non- Real-Time (Non-RT) RIC: Collected datasets need to be transferred to places where model training takes place. A training dataset is acquired by Data Management and Exposure (DME) services in Non-RT RIC to the rApps to train the ML model. Similarly, xApps in Near-RT RIC collect the dataset via Data pipeline to train the ML model.

[0114] In some cases, when the ML model performance degrades, retraining may be triggered in the Non-RT RIC or SMO. This would then require training data to be transmitted from the Near- RT RIC to the Non-RT RIC of the SMO. The near-RT RIC or xApp may request this data. The dataset that is transferred from the Data pipeline at near-RT RIC may consist of User Equipment (UE)-level measurements (e.g., throughput, delay per UE, traffic volume per UE, channel quality per UE, slice-level measurements (Physical Resource Block (prb) usage per slice), and cell-level measurements (prb usage per cell). This may be transferred via the 01 interface.

[0115] In a particular scenario, the non-RT RIC can be the RIC that trains the model, and the near- RT RIC can be an inferrer. New function calls can be added to the existing O-RAN signal flow between Non-RT RIC and Near-RT RIC in the context of model training. The Near-RT RIC can select the compression level (e.g., bottleneck layer), and compress / encode the dataset. The selection can be based on historical data (e.g., previous model efficacy, compression levels, and other data refinement parameters) and aims to select the bottleneck layer that would minimise the data volume and maximise the model efficacy.

[0116] Fig. 5 is a flow chart illustrating a computer-implemented method performed by a first node according to various embodiments. The first node can be an edge node, an edge node that can be configured / selected as a central node, or a central node. The first node may perform the method in response to executing suitably formulated computer readable code. The computer readable code may be embodied or stored on a computer readable medium, such as a memory chip, optical disc, or other storage medium. The computer readable medium may be part of a computer program product.

[0117] The first node has a first dataset. The first dataset may comprise one or more measurements of one or more parameters. The first dataset may also comprise labels associated with one or more measurements in the first dataset, with each label relating to a status of the communication network.

[0118] In step 501 the first node uses a trained autoencoder to compress the first dataset. In particular, the trained autoencoder comprises an encoder that generates a first compressed dataset from the first dataset, and a decoder that decompresses the first compressed dataset to generate a first decompressed dataset. In some embodiments, the autoencoder can be a variational autoencoder (VAE).

[0119] In step 503, the first node determines a first actual compression performance of the autoencoder based on the first decompressed dataset relative to the first dataset.

[0120] In step 505, the first node sends an indication of the first actual compression performance to a second node.

[0121] In step 507, the first node receives a first target compression performance from the second node.

[0122] In step 509, the first node updates the autoencoder according to the first target compression performance. Updating the autoencoder may comprise adding or removing one or more layers from the encoder and the decoder, as described above with reference to Fig. 4. Updating the autoencoder may comprise adding or removing one or more neurons from a bottleneck layer of the autoencoder, as described above with reference to Fig. 4.

[0123] If the first target compression performance received in step 507 is lower than the first actual compression performance determined in step 503, the autoencoder can be updated by removing one or more layers from the encoder and the decoder.

[0124] After step 509, the first node may compress the first dataset using the updated autoencoder to generate a second compressed dataset. The first node may then determine a second actual compression performance of the second decompressed dataset relative to the first dataset, and send an indication of the second actual compression performance to the second node.

[0125] The first node may receive an indication from the second node that indicates that the first node is to operate as a central node for training a ML model. The training of the ML model is to be performed using the first dataset, and one or more compressed datasets received from one or more further nodes. In this case, the first node can receive one or more compressed datasets from the one or more further nodes, and train the ML model using the first dataset and the received compressed datasets.

[0126] Alternatively, the first node is to operate as an edge node. In embodiments where the first node is an edge node, the first node may communicate the second compressed dataset to the second node or a third node for use in training a ML model. Subsequently, the first node may receive a trained ML model from the second node or third node. The first node may also send the decoder of the updated autoencoder to the second node or a third node. In embodiments where the autoencoder is a VAE, communicating the second compressed dataset may comprise the first node sending a latent space representation of the second compressed dataset (and the decoder) to the second node or third node.

[0127] The second node may be an orchestrator node, and the third node may be a central node, in which case the first node communicates the second compressed dataset to the central node. The central node uses the data in the first dataset to train a ML model. In these embodiments, the first node may have received an indication from the second node identifying the third node.

[0128] Alternatively, the second node is a central node, and the first node communicates the second compressed dataset to the central node.

[0129] After communicating the second compressed dataset to the second node or the third node (as appropriate), the first node may receive a second target compression performance from that node. The first node further updates the autoencoder according to the second target compression performance. As in step 509, updating the autoencoder may comprise adding or removing one or more layers from the encoder and the decoder, or adding or removing one or more neurons from a bottleneck layer of the autoencoder. The first node compresses the first dataset using the further updated autoencoder to generate a third compressed dataset, and communicates the third compressed dataset to the relevant node for use in (further) training the ML model.

[0130] Prior to step 501 , the first node may have received an initial target compression performance (referred to herein as a “third target compression performance”), and trained the autoencoder according to the initial target compression performance. The initial target compression performance may have been obtained from the second node.

[0131] Fig. 6 is a flow chart illustrating a computer-implemented method performed by a second node according to various embodiments. The second node can be a central node, or an orchestrator node. The second node may perform the method in response to executing suitably formulated computer readable code. The computer readable code may be embodied or stored on a computer readable medium, such as a memory chip, optical disc, or other storage medium. The computer readable medium may be part of a computer program product.

[0132] In step 601 , the second node receives an indication of a first actual compression performance for a trained autoencoder from a first node. The autoencoder has compressed a first dataset, and the first actual compression performance represents the compression performance of a first decompressed dataset output by a decoder of the autoencoder relative to the first dataset.

[0133] In step 603, the second node determines if the first compression performance meets a criterion. If the first compression performance does not meet the criterion, then in step 605 the second node determines a first target compression performance. The criterion can relate to one or both of the first target compression performance, and a size of the first compressed dataset.

[0134] The second node sends an indication of the first target compression performance to the first node in step 607.

[0135] The second node can repeat steps 601-607 for one or more further nodes that each have a respective dataset. The second node may then receive a respective second actual compression performance from the first node and the one or more further nodes. Each second actual compression performance represents the compression performance of a second decompressed dataset output by a respective updated decoder of the autoencoder relative to the respective dataset. The second node may select one of the first node and one or more further nodes to be a central node for training a ML model. The node to be the central node is selected based on the respective second actual compression performances. For example, the selected node can be the node that has the highest second actual compression performance. In some embodiments, the selection of the node to be the central node is based on a size of the respective second decompressed datasets. After step 607, the second node may receive an indication of a second actual compression performance from the first node. This second actual compression performance can represent the compression performance of a second decompressed dataset output by the autoencoder after the autoencoder has been retrained by the first node.

[0136] The second node may send an indication to the first node that identifies a third node (a central node) that the first node is to send a compressed dataset to.

[0137] Alternatively, the second node can send an indication to the first node that indicates that the first node is to operate as a central node for training a ML model using the first dataset. The indication can indicate that the first node will receive one or more compressed datasets from one or more further nodes.

[0138] In another alternative, the second node is to operate as a central node and train a ML model using datasets from the first node and one or more further nodes. In this case the second node can receive a compressed dataset from the first node. The second node may also receive a decoder of the trained autoencoder from the first node, and the second node uses the decoder to decompress the received compressed dataset. The second node may train a ML model using the received compressed dataset, or using a decompressed dataset.

[0139] The autoencoder used by the first node may be a variational autoencoder. In this case, the second node may receive a latent space representation of the compressed dataset and the decoder from the first node. The second node may reconstruct the dataset from the received latent space representation and the decoder. The ML model can then be trained using the reconstructed dataset.

[0140] Once the second node has trained the ML model, the second node can send the second node can send the trained ML model to the first node.

[0141] In some embodiments, the second node can determine an efficacy of the trained ML model, determine if the efficacy meets a criterion (e.g. are the predictions provided by the model accurate enough?), and if the efficacy does not meet the criterion, then the second node can determine a second target compression performance (e.g. determined based on the efficacy of the trained ML model). The second node sends an indication of the second target compression performance to the first node, so that the first node can retrain the autoencoder to provide a compressed dataset in line with the second target compression performance.

[0142] Prior to step 601 , the second node may have sent an initial target compression performance (referred to herein as a “third target compression performance”) to the first node. The first node may have trained the autoencoder according to the initial target compression performance.

[0143] The method performed by the second node may include determining the initial target compression performance. The second node may determine the third target compression performance from any one or more of: a previously-used target compression performance, a previously-used reconstruction loss, and a previous model efficacy of a trained ML model. The third target compression performance may also or alternatively be determined from any one or more of: a communication cost of communicating compressed datasets from the first node, an energy cost of retraining or updating the autoencoder, and a computation cost of retraining or updating the autoencoder.

[0144] Fig. 7 is a simplified block diagram of a node 700 according to various embodiments that can be used to implement one or more of the techniques described herein. The node 700 may be, or be part of, any of: an edge node, a central node, an edge node that be selected to operate as a central node, an orchestrator node.

[0145] The node 700 comprises processing circuitry (or logic) 701 . It will be appreciated that the node 700 may comprise one or more virtual machines running different software and / or processes. The node 700 may therefore comprise, or be implemented in or as one or more servers, switches and / or storage devices and / or may comprise cloud computing infrastructure that runs the software and / or processes.

[0146] The processing circuitry 701 controls the operation of the node 700 to implement the methods described herein. The processing circuitry 701 can comprise one or more processors, processing units, multi-core processors or modules that are configured or programmed to control the node 700 in the manner described herein. In particular implementations, the processing circuitry 701 can comprise a plurality of software and / or hardware modules that are each configured to perform, or are for performing, individual or multiple steps of the method described herein in relation to the node 700.

[0147] The node 700 also comprises a communications interface 702. The communications interface 702 is for use in enabling communications with other network nodes, computers, servers, etc. For example, the communications interface 702 can be configured to transmit to and / or receive from other nodes, requests, acknowledgements, information, data, signals, or similar. The communications interface 702 can use any suitable communication technology.

[0148] The processing circuitry 701 may be configured to control the communications interface 702 to transmit to and / or receive from other nodes, etc. requests, acknowledgements, information, data, signals, or similar, according to the methods described herein.

[0149] The node 700 may comprise a memory 703. In some embodiments, the memory 703 can be configured to store program code that can be executed by the processing circuitry 701 to perform the methods described herein in relation to the node 700. Alternatively or in addition, the memory 703 can be configured to store any requests, acknowledgements, information, data, signals, or similar that are described herein. The processing circuitry 701 may be configured to control the memory 703 to store such information therein.

[0150] Fig. 8 is a block diagram illustrating a virtualization environment 800 in which functions implemented by some embodiments may be virtualized. In the present context, virtualizing means creating virtual versions of apparatuses or devices which may include virtualizing hardware platforms, storage devices and networking resources. As used herein, virtualization can be applied to any device or node described herein, or components thereof, and relates to an implementation in which at least a portion of the functionality is implemented as one or more virtual components. Some or all of the functions described herein may be implemented as virtual components executed by one or more virtual machines (VMs) implemented in one or more virtual environments 800 hosted by one or more of hardware nodes, such as a hardware computing device that operates as an access network node, a wireless device / UE, a core network node, or host. Further, in embodiments in which the virtual node does not require radio connectivity (e.g. a core network node or host), then the node may be entirely virtualized. In some embodiments, the virtualization environment 800 includes components defined by the Open-RAN (O-RAN) Alliance, such as an O-Cloud environment orchestrated by a Service Management and Orchestration Framework via an 0-2 interface.

[0151] Applications 802 (which may alternatively be called software instances, virtual appliances, network functions, virtual nodes, virtual network functions, etc.) are run in the virtualization environment 800 to implement some of the features, functions, and / or benefits of some of the embodiments disclosed herein.

[0152] Hardware 804 includes processing circuitry, memory that stores software and / or instructions executable by hardware processing circuitry, and / or other hardware devices as described herein, such as a network interface, input / output interface, and so forth. Software may be executed by the processing circuitry to instantiate one or more virtualization layers 806 (also referred to as hypervisors or virtual machine monitors (VMMs)), provide VMs 808a and 808b (one or more of which may be generally referred to as VMs 808), and / or perform any of the functions, features and / or benefits described in relation with some embodiments described herein. The virtualization layer 806 may present a virtual operating platform that appears like networking hardware to the VMs 808.

[0153] The VMs 808 comprise virtual processing, virtual memory, virtual networking or interface and virtual storage, and may be run by a corresponding virtualization layer 806. Different embodiments of the instance of a virtual appliance 802 may be implemented on one or more of VMs 808, and the implementations may be made in different ways. Virtualization of the hardware is in some contexts referred to as network function virtualization (NFV). NFV may be used to consolidate many network equipment types onto industry standard high volume server hardware, physical switches, and physical storage, which can be located in data centers, and customer premise equipment.

[0154] In the context of NFV, a VM 808 may be a software implementation of a physical machine that runs programs as if they were executing on a physical, non-virtualized machine. Each of the VMs 808, and that part of hardware 804 that executes that VM, be it hardware dedicated to that VM and / or hardware shared by that VM with others of the VMs, forms separate virtual network elements. Still in the context of NFV, a virtual network function is responsible for handling specific network functions that run in one or more VMs 808 on top of the hardware 804 and corresponds to the application 802.

[0155] Hardware 804 may be implemented in a standalone network node with generic or specific components. Hardware 804 may implement some functions via virtualization. Alternatively, hardware 804 may be part of a larger cluster of hardware (e.g. such as in a data center or CPE) where many hardware nodes work together and are managed via management and orchestration 810, which, among others, oversees lifecycle management of applications 802. In some embodiments, hardware 804 is coupled to one or more radio units that each include one or more transmitters and one or more receivers that may be coupled to one or more antennas. Radio units may communicate directly with other hardware nodes via one or more appropriate network interfaces and may be used in combination with the virtual components to provide a virtual node with radio capabilities, such as a radio access node or a base station. In some embodiments, some signalling can be provided with the use of a control system 812 which may alternatively be used for communication between hardware nodes and radio units.

[0156] Although the computing devices described herein (e.g. edge nodes, central nodes, orchestrator nodes) may include the illustrated combination of hardware components, other embodiments may comprise computing devices with different combinations of components. It is to be understood that these computing devices may comprise any suitable combination of hardware and / or software needed to perform the tasks, features, functions and methods disclosed herein. Determining, calculating, obtaining or similar operations described herein may be performed by processing circuitry, which may process information by, for example, converting the obtained information into other information, comparing the obtained information or converted information to information stored in the network node, and / or performing one or more operations based on the obtained information or converted information, and as a result of said processing making a determination. Moreover, while components are depicted as single boxes located within a larger box, or nested within multiple boxes, in practice, computing devices may comprise multiple different physical components that make up a single illustrated component, and functionality may be partitioned between separate components. For example, a communication interface may be configured to include any of the components described herein, and / or the functionality of the components may be partitioned between the processing circuitry and the communication interface. In another example, non-computationally intensive functions of any of such components may be implemented in software or firmware and computationally intensive functions may be implemented in hardware.

[0157] In certain embodiments, some or all of the functionality described herein may be provided by processing circuitry executing instructions stored on in memory, which in certain embodiments may be a computer program product in the form of a non-transitory computer-readable storage medium. In alternative embodiments, some or all of the functionality may be provided by the processing circuitry without executing instructions stored on a separate or discrete device- readable storage medium, such as in a hard-wired manner. In any of those particular embodiments, whether executing instructions stored on a non-transitory computer-readable storage medium or not, the processing circuitry can be configured to perform the described functionality. The benefits provided by such functionality are not limited to the processing circuitry alone or to other components of the computing device, but are enjoyed by the computing device as a whole, and / or by end users and a wireless network generally.

[0158] The foregoing merely illustrates the principles of the disclosure. Various modifications and alterations to the described embodiments will be apparent to those skilled in the art in view of the teachings herein. It will thus be appreciated that those skilled in the art will be able to devise numerous systems, arrangements, and procedures that, although not explicitly shown or described herein, embody the principles of the disclosure and can be thus within the scope of the disclosure. Various exemplary embodiments can be used together with one another, as well as interchangeably therewith, as should be understood by those having ordinary skill in the art.

Claims

Claims1 . A computer-implemented method performed by a first node, wherein the first node has a first dataset, the method comprising: using (501) a trained autoencoder to compress the first dataset, wherein the trained autoencoder comprises an encoder that generates a first compressed dataset from the first dataset, and a decoder that decompresses the first compressed dataset to generate a first decompressed dataset; determining (503) a first actual compression performance of the autoencoder based on the first decompressed dataset relative to the first dataset; sending (505) an indication of the first actual compression performance to a second node; receiving (507), from the second node, a first target compression performance; and updating (509) the autoencoder according to the first target compression performance.

2. The method as claimed in claim 1 , wherein the step of updating (509) the autoencoder comprises adding or removing one or more layers from the encoder and the decoder.

3. The method as claimed in claim 1 , wherein the step of updating (509) the autoencoder comprises adding or removing one or more neurons from a bottleneck layer of the autoencoder.

4. The method as claimed in any of claims 1-3, wherein the received first target compression performance is lower than the first actual compression performance, and wherein the step of updating (509) the autoencoder comprises removing one or more layers from the encoder and the decoder.

5. The method as claimed in any of claims 1-4, wherein the method further comprises: compressing the first dataset using the updated autoencoder to generate a second compressed dataset.

6. The method as claimed in claim 5, wherein the method further comprises: determining a second actual compression performance of the second decompressed dataset relative to the first dataset; and sending an indication of the second actual compression performance to the second node.

7. The method as claimed in claim 5 or 6, wherein the method further comprises:communicating the second compressed dataset to the second node or a third node for use in training a machine learning, ML, model.

8. The method as claimed in claim 7, wherein the second node is an orchestrator node, the third node is a central node, and the second compressed dataset is communicated to the central node.

9. The method as claimed in claim 7 or 8, wherein the method further comprises: receiving an indication from the second node that identifies the third node, and wherein the second compressed dataset is communicated to the identified third node.

10. The method as claimed in any of claims 7-9, wherein the method further comprises: receiving a trained ML model from the second node or third node.

11. The method as claimed in claim 7, wherein the second node is a central node, and the second compressed dataset is communicated to the central node.

12. The method as claimed in any of claims 7-11 , wherein, after communicating the second compressed dataset to the second node or the third node, the method further comprises: receiving, from the node the second compressed dataset was sent to a second target compression performance; further updating the autoencoder according to the received second target compression performance; compressing the first dataset using the further updated autoencoder to generate a third compressed dataset; and communicating the third compressed dataset to the second node or the third node for use in training the ML model.

13. The method as claimed in any of claims 1 -6, wherein the method further comprises: receiving an indication from the second node that indicates that the first node is to operate as a central node for training a machine learning, ML, model using the first dataset, and one or more compressed datasets received from one or more further nodes.

14. The method as claimed in claim 13, wherein the method further comprises: receiving one or more compressed datasets from the one or more further nodes; andtraining the ML model using the first dataset and the received compressed datasets.

15. The method as claimed in any of claims 1-14, wherein the method further comprises: prior to the step of using the trained autoencoder, obtaining a third target compression performance; and wherein the method further comprises training the autoencoder according to the third target compression performance.

16. The method as claimed in claim 15, wherein the third target compression performance is obtained from the second node.

17. The method as claimed in any of claims 1-16, wherein the method further comprises: sending the decoder of the updated autoencoder to the second node or a third node.

18. The method as claimed in any of claims 1-17, wherein the autoencoder is a variational autoencoder.

19. The method as claimed in claim 18, wherein the step of communicating the second compressed dataset comprises sending a latent space representation of the second compressed dataset and sending the decoder.

20. The method as claimed in any of claims 1-19, wherein the first dataset further comprises labels associated with one or more measurements in the first dataset, and wherein each label relates to a status of the communication network.21 . A computer-implemented method performed by a second node, the method comprising:(i) receiving (601), from a first node, an indication of a first actual compression performance for a trained autoencoder, wherein the autoencoder has compressed a first dataset, and wherein the first actual compression performance represents the compression performance of a first decompressed dataset output by a decoder of the autoencoder relative to the first dataset;(ii) determining (603) if the first compression performance meets a criterion;(iii) if the first compression performance does not meet the criterion, determining (605) a first target compression performance; and(iv) sending (607) an indication of the first target compression performance to the first node.

22. The method as claimed in claim 21 , wherein the criterion relates to one or more of: the first target compression performance, and a size of the first compressed dataset.

23. The method as claimed in claim 21 or 22, wherein the method further comprises: repeating steps (i)-(iv) for one or more further nodes that each have a respective dataset.

24. The method as claimed in claim 23, wherein the method further comprises: receiving a respective second actual compression performance from the first node and the one or more further nodes, wherein each second actual compression performance represents the compression performance of a second decompressed dataset output by an updated decoder of the autoencoder relative to the respective dataset.

25. The method as claimed in claim 24, wherein the method further comprises: selecting one of the first node and one or more further nodes to be a central node fortraining a machine learning, ML, model using the respective datasets, wherein the central node is selected based on the respective second actual compression performances.

26. The method as claimed in claim 25, wherein the central node is selected as the node that has the highest second actual compression performance.

27. The method as claimed in claim 26, wherein the central node is further selected based on a size of the respective second decompressed datasets.

28. The method as claimed in any of claims 21-27, wherein the method further comprises: receiving an indication of a second actual compression performance from the first node.

29. The method as claimed in any of claims 21-28, wherein the method further comprises: sending an indication to the first node that identifies a third node that the first node is to send a compressed dataset to.

30. The method as claimed in any of claims 21-28, wherein the method further comprises: sending an indication to the first node that indicates that the first node is to operate as a central node for training a machine learning, ML, model using the first dataset, and one or more compressed datasets that will be received from one or more further nodes.31 . The method as claimed in any of claims 21-28, wherein the method further comprises: receiving, from the first node, a compressed dataset.

32. The method as claimed in claim 31 , wherein the method further comprises: receiving a decoder of the trained autoencoder from the first node; and using the decoder to decompress the received compressed dataset.

33. The method as claimed in claim 31 or 32, wherein the method further comprises: training a machine learning, ML, model using the compressed or decompressed dataset.

34. The method as claimed in any of claims 21-30, wherein the autoencoder is a variational autoencoder.

35. The method as claimed in claim 34, wherein the method further comprises: receiving, from the first node, a latent space representation of the compressed dataset and the decoder.

36. The method as claimed in claim 35, wherein the method further comprises: reconstructing the dataset from the received latent space representation and the decoder; and training a machine learning, ML, model using the reconstructed dataset.

37. The method as claimed in claim 33 or 36, wherein the method further comprises: sending the trained ML model to the first node.

38. The method as claimed in claim 33, 36 or 37, wherein the method further comprises: determining an efficacy of the trained ML model; determining if the efficacy meets a criterion; if the efficacy does not meet the criterion, determining a second target compression performance; and sending an indication of the second target compression performance to the first node.

39. The method as claimed in claim 38, wherein the second target compression performance is determined based on the efficacy of the trained ML model.

40. The method as claimed in any of claims 21-39, wherein the method further comprises: prior to step (i), sending, to the first node, a third target compression performance that is to be used by the first node to train the autoencoder.41 . The method as claimed in claim 40, wherein the method further comprises: determining the third target compression performance.

42. The method as claimed in claim 41 , wherein the third target compression performance is determined from any one or more of: a previously-used target compression performance, a previously-used reconstruction loss, and a previous model efficacy of a trained machine learning, ML, model.

43. The method as claimed in claim 41 or 42, wherein the third target compression performance is determined from any one or more of: a communication cost of communicating compressed datasets from the first node, an energy cost of retraining or updating the autoencoder, and a computation cost of retraining or updating the autoencoder.

44. A computer program product comprising a computer readable medium having computer readable code embodied therein, the computer readable code being configured such that, on execution by a suitable computer or processor, the computer or processor is caused to perform the method of any of claims 1-43.

45. A node configured to perform the method of any of claims 1-43.

46. A node comprising a processor and a memory, said memory containing instructions executable by said processor whereby said node is operative to perform the method of any of claims 1-43.

Images