Methods and apparatuses for enabling performance of a distributed learning process in a core network

Abstract

Embodiments described herein relate to methods and apparatuses for relate to methods and apparatuses for managing distributed learning in a network environment. A coordinating node is provided in a core network of a communications node for coordinating performance of one or more machine learning tasks by one or more respective client nodes, wherein the one or more ML tasks are part of a first ML process, wherein the first ML process comprises a distributed learning process. The method performed by the coordinating node comprises transmitting, to a first client node of the one or more client nodes, a request to perform the respective ML task; and transmitting to the first client node, one or more parameters relating to implementation of the respective ML task.

Description

[0001] METHODS AND APPARATUSES FOR ENABLING PERFORMANCE OF A DISTRIBUTED LEARNING PROCESS IN A CORE NETWORK

[0002] TECHNICAL FIELD

[0003] Embodiments described herein relate to methods and apparatuses for managing distributed learning in a network environment.

[0004] BACKGROUND

[0005] There are cases in utilising machine learning in which datasets cannot be moved, or it is desirable not to move them, from where they originate due to reasons including data privacy, data security, access rights, and large data size.

[0006] In these circumstances, distributed intelligence technologies such as split learning may be used. Split learning is a distributed learning technique that realizes vertical federated learning. In split learning the Machine Learning (ML) model to be trained is split into parts, where each part may reside close to the input data required for that part and may be rich in compute. For example, if particular data is utilised an input to a ML model part, then the node that collects that particular data may be a head node training that ML model part.

[0007] If input data for a second ML model part is an output of a first ML model part, then the node that holds second ML model part is a tail node.

[0008] A head node may take input data and send the output of the local model, a so called activation (or intermediate result), to a tail node. A tail node may then take the received activation(s) as an input to their local model, and then provide an output, e.g. an estimation. A tail node may then compare the output (e.g. estimated value) with its own original data (e.g. an output label), and obtain a loss value. The loss value may then be used to calculate the gradients of the local model at the tail node, and the tail node may then update the weights of its local model. The obtained gradients of the tail node local model may then be sent to the head node(s), so the head node(s) can also compute its local model gradients and update the weights of its local model. This would then conclude one round of model training. The head node(s) can then feed in another batch of data to their local model to commence the next round. Such training can be iterated until the loss value (which indicates the level of error in estimations against the ground truth labels) at the tail node is considered acceptable. As can be understood from the description above, the head nodes only share their outputs (e.g. activations), which addresses privacy concerns to some extent.

[0009] In current distributed learning techniques, the various nodes involved in the learning are generally preconfigured to perform the tasks they are responsible for in the distributed learning.

[0010] In a telecommunications environment, it is envisioned that network functions (NFs) e.g. within a core network, are likely to acquire artificial intelligence (Al) capabilities or in other words implement or complement their existing operation using Al processes.

[0011] SUMMARY

[0012] Management of an ML model in a centralized learning scenario is significantly easier than a distributed learning scenario since in centralised learning a single entity has control over the input data, the model parameters, and the output of the model. In a telecommunications environment for example, centralised learning may require a single network function to be capable of performing the machine learning process, whilst it may collect data according to known techniques from other network functions.

[0013] Horizonal federated learning may also be considered easier to manage than vertical federated learning since in horizontal federated learning since in horizontal federated learning, the trained global model is present and observable in a single logical function..

[0014] However, for example, management of the training process for distributed ML models, for example in a split neural network based vertical federated learning setting, is more demanding. For example, with split learning the complete neural network model is now split in different portions where these portions need to be in different places / nodes.

[0015] Each portion may have an input that is only observable in the local entity. For training and inference to happen dynamically and in an efficient way while securing high efficacy, certain methods to support management of split models may be required.

[0016] As it is envisioned that network functions (NFs) e.g. within a core network, are likely to acquire artificial intelligence (Al) capabilities it will be appreciated that they stand to benefit from input obtained by other models hosted in the core network and even in the radio access network. From the standardization aspect relating to multi-vendor settings in telecommunications, instructions and definitions for management of these AI / ML processes need to be standardized so that the responsibility of distributed entities when receiving a task and what to do with it is defined. For example, the ML tasks for performing an ML process may not depend on the properties of any existing frameworks or particular programming language. They may be kept generic and cover solely the low level basic tasks that the clients may be requested to do to assist the expected building blocks of an ML process.

[0017] According to some embodiments there is provided a method performed by a coordinating node in a core network of a communications network for coordinating performance of one or more machine learning, ML, tasks by one or more respective client nodes, wherein the one or more ML tasks are part of a first ML process. The first ML process comprises a distributed learning process. The method comprises transmitting, to a first client node of the one or more client nodes, a request to perform the respective ML task; and transmitting to the first client node, one or more parameters relating to implementation of the respective ML task.

[0018] According to some embodiments there is provided a method performed by a client node in a communications network for enabling performance of a machine learning task, wherein the ML tasks is part of a first ML process. The first ML process comprises a distributed learning process. The method comprises eceiving, from a coordinating node in a core network, a request to perform the ML task; and receiving from the coordinating node, one or more parameters relating to implementation of the ML task.

[0019] According to some embodiments there is provided a coordinating node in a core network of a communications node for coordinating performance of one or more machine learning tasks by one or more respective client nodes, wherein the one or more ML tasks are part of a first ML process. The first ML process comprises a distributed learning process. The coordinating node comprises processing circuitry and a memory, the memory containing instructions executable by the processing circuitry whereby the coordinating node is operable to: transmit, to a first client node of the one or more client nodes, a request to perform the respective ML task; and transmit to the first client node, one or more parameters relating to implementation of the respective ML task.

[0020] According to some embodiments there is provided a client node in a communications network for enabling performance of a machine learning task, wherein the ML task is part of a first ML process. The first ML process comprises a distributed learning process. The client node comprises processing circuitry and a memory, the memory containing instructions executable by the processing circuitry whereby the client node is operable to: receive, from a coordinating node in a core network, a request to perform the ML task; and receive from the coordinating node, one or more parameters relating to implementation of the ML task.

[0021] According to some embodiments there is provided a computer program, comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out any of the methods described above. According to some embodiments there is provided a computer-readable medium comprising instructions that, when executed on at least one processor, cause the at least one processor to perform any of the methods described above.

[0022] According to some embodiments there is provided a computer program product comprising non transitory computer readable media having stored thereon a computer program as described above.

[0023] BRIEF DESCRIPTION OF THE DRAWINGS

[0024] For a better understanding of the embodiments of the present disclosure, and to show how it may be put into effect, reference will now be made, by way of example only, to the accompanying drawings, in which:

[0025] Figure 1 is a system diagram illustrating how centralised learning may be utilised to predict E2E data volume transfer times;

[0026] Figure 2 is a system diagram illustrating how split learning based vertical federated learning may be utilised to predict E2E data volume transfer times according to some embodiments;

[0027] Figure 3 illustrates a method performed by a coordinating node in a core network of a communications network for coordinating performance of one or more machine learning, ML, tasks by one or more respective client nodes;

[0028] Figure 4 illustrates how samples at various client nodes may be aligned;

[0029] Figure 5 illustrates an example method for performing a sample alignment process to obtain the sample indication of step 303;

[0030] Figure 6 is a flowchart illustrating a method performed by a client node of a communications network for enabling performance of a machine learning task, wherein the ML task is part of a first ML process;

[0031] Figure 7 is a signalling diagram illustrating an example implementation of the method of Figures 3 and 6;

[0032] Figure 8 is a signalling diagram illustrating an example implementation of the method of Figure 5;

[0033] Figure 9 illustrates a coordinating node comprising processing circuitry (or logic); Figure 10 illustrates a client node comprising processing circuitry (or logic); and

[0034] Figure 11 is a block diagram illustrating a virtualization environment in which functions implemented by some embodiments may be virtualized.

[0035] DETAILED DESCRIPTION

[0036] Generally, all terms used herein are to be interpreted according to their ordinary meaning in the relevant technical field, unless a different meaning is clearly given and / or is implied from the context in which it is used. All references to a / an / the element, apparatus, component, means, step, etc. are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise. The steps of any methods disclosed herein do not have to be performed in the exact order disclosed, unless a step is explicitly described as following or preceding another step and / or where it is implicit that a step must follow or precede another step. Any feature of any of the embodiments disclosed herein may be applied to any other embodiment, wherever appropriate. Likewise, any advantage of any of the embodiments may apply to any other embodiments, and vice versa. Other objectives, features and advantages of the enclosed embodiments will be apparent from the following description

[0037] The following sets forth specific details, such as particular embodiments or examples for purposes of explanation and not limitation. It will be appreciated by one skilled in the art that other examples may be employed apart from these specific details. In some instances, detailed descriptions of well-known methods, nodes, interfaces, circuits, and devices are omitted so as not obscure the description with unnecessary detail. Those skilled in the art will appreciate that the functions described may be implemented in one or more nodes using hardware circuitry (e.g., analog and / or discrete logic gates interconnected to perform a specialized function, ASICs, PLAs, etc.) and / or using software programs and data in conjunction with one or more digital microprocessors or general purpose computers. Nodes that communicate using the air interface may have suitable radio communications circuitry. Moreover, where appropriate the technology can additionally be considered to be embodied entirely within any form of computer-readable memory, such as (ROM, EEPROM, Flash memory, a memory disc, RAM etc.) solid-state memory, magnetic disk, or optical disk containing an appropriate set of computer instructions that would cause a processor to carry out the techniques described herein.

[0038] Hardware implementation may include or encompass, without limitation, digital signal processor (DSP) hardware, a reduced instruction set processor, hardware (e.g., digital or analogue) circuitry including but not limited to application specific integrated circuit(s) (ASIC) and / or field programmable gate array(s) (FPGA(s)), and (where appropriate) state machines capable of performing such functions.

[0039] Certain aspects of the present disclosure and their embodiments may provide solutions to these or other challenges.

[0040] Particular embodiments are described more fully with reference to the accompanying drawings. Other embodiments, however, are contained within the scope of the subject matter disclosed herein. The disclosed subject matter should not be construed as limited to only the embodiments set forth herein; rather, these embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art.

[0041] For the purposes of the present disclosure, the term "ML model” encompasses within its scope the following concepts: machine Learning algorithms, comprising processes or instructions through which data may be used in a training process to generate a model artefact for performing a given task, or for representing a real world process or system; the model artefact that is created by such a training process, and which comprises the computational architecture that performs the task; and the process performed by the model artefact in order to complete the task.

[0042] One example of a use cause for distributed learning may be enabling a Network Data Analytics Function (NWDAF) to provide End to End (E2E) data volume transfer time analytics in the form of statistics or predictions as required by 3rdGeneration Partnership Project (3GPP) release 18 TS 23.288 (section 6.18) version v18.6.0. The E2E data volume transfer time refers to a time delay for completing the transmission of a specific data volume from user equipment (UE) to Application Function (AF), or from AF to UE. This use case may necessitate input from various network functions in order to predict the data volume transfer time.

[0043] By enabling a good prediction capability, a user of the analytics service is enabled to perform better planning for data transfer from UEs to a destination (e.g., uploading large sized recorded videos to a social media platform, or uploading large files to a cloud server platform). For example, a user may decide to postpone the transfer of data if a significant lower latency is predicted in the future. This way, it can save energy consumed during the transfer of dataset. In another example, a streaming-video application can use the predictions of the E2E data volume transfer time to better estimate the expected throughput for the duration of the video. This would avoid switching encoding quality up and down as the throughput fluctuates, something that is known to give a worse end-user experience. Instead, the streaming-video application could choose an encoding quality which has a high likelihood to be maintained during the entire transfer. The E2E data volume transfer time predictions may also be used to instruct a Policy Control Function (PCF) to allocate higher priority to a data transfer if the prediction is not what is desired. Finally, this use case can be applied in the context of federated learning with UEs to determine the selection of the participants in a federated learning training session. In that case, if a server predicts a high latency in the transfer of model parameters from / to certain clients, it can deselect those clients for a federation round to speed up the training round.

[0044] In order to predict the data volume transfer times, data that can be collected from network functions such as the Access and Mobility Management Function (AMF), the Session Management Function (SMF) (acting as front-end for the User Plane Function (UPF)), a Base station (gNB), and an AF (via Network Exposure Function (NEF)) to NWDAF may be required.

[0045] According to current specifications, the NWDAF may then train an ML model in centralized mannerwiVn the help of ML model training function (Model Training Logical Function (MTLF) in NWDAF).

[0046] Figure 1 is a system diagram illustrating how centralised learning may be utilised to predict E2E data volume transfer times.

[0047] Figure 1 illustrates a core network system comprises a gNB 101 , AMF 102, Network Data Analytics Function (NWDAF) 103, SMF 104, UPF 105, UDM 106, Network Exposure Function (NEF) 107. A UE 108 running an application may be acting as an NF consumer, and the data network, DN, may be providing an Application Function (AF) 109 and an application server 110.

[0048] The input data required, and the output analytics, may be found in the respective tables in TS 23.288 (sections 6.18.2 and 6.18.3) version v18.6.0.

[0049] Note that the labels (volume and duration of the end-to-end transfer) may be received from the Application Function (AF) 109. The dataset may be collected to perform inference or other statistics in different sampling rates depending on the use case. The collected data can be made available to the NWDAF for training when requested (data is provided by the NWDAF 103 as represented by the arrows). Data items from the different sources can be correlated to each other using a combination of timestamp and identities, where the identities come in the form of UE identities (like SUPI, Subscription Permanent Identifier) and session identities.

[0050] In the example of Figure 1 therefore an AI / ML model is trained centrally by the NWDAF 103 utilising data collected from the gNB 101, AMF 102, SMF 104 and AF 109. It will be appreciated that such a task could be performed using distributed learning. However, as described above, there is currently no mechanism by which the core network may automatically divide and distribute the various responsibilities for distributed learning.

[0051] From the standardization perspective relating to multi-vendor settings in telecommunications, the coordination of the client nodes performing distributed learning (e.g. by way of various instructions and definitions) may need to be standardized so that the responsibility of distributed entities when receiving a task and what to do with it is defined.

[0052] In some examples of embodiments described herein therefore, the E2E data volume transfer time analytics may be instead by performed by split learning. As described above split learning is a distributed learning technique that realizes vertical federated learning. When the input feature types (including the output label) located at the distributed nodes are different, then split learning enables training of a global model by a core network system as depicted in Figure 2.

[0053] In Figure 2, the procedure for training the distributed model to estimate the data volume transfer time may be as follows.

[0054] The gNB 101 , AMF 102, SMF 103 and AF 109 each collect local data and pass that data through their local models (e.g. forward propagation). The local models at the gNB 101 , AMF 102 and SMF 103 are called head nodes, while the local NN model at the AF 109 is called the tail node. The outputs of the local models at the head nodes, so called activations, are then sent to the AF 109. AF concatenates or aggregates the activations depending on the implementation and utilises the aggregation / concatenation as an input to its own local model.

[0055] In this example, the AF 109 has its own locally collected data and uses this as an output label for its local model. The AF 109 may then perform a forward propagation operation. For example, a forward propagation operation may comprise actions such as a cascaded matrix multiplication operation where the values at the input features are multiplied by the local model weights followed by nonlinear transformation (e.g. via the activation function of the local model)). The number of multiplication operation may depend on the number of layers and number of neurons at the local model.

[0056] In the embodiment illustrated in Figure 2, a coordinating node, in this example referred to as a distributed model coordination function (DMCF) 201 is introduced to perform the management of distributed models. In this example, the DCMF 200 is placed in the core network, however it will be appreciated that the DCMF 200 may be located anywhere suitable for communication with the client nodes (in this example, the gNB

[0057] 101 , AMF 102, SMF 103 and AF 109). In some examples the DCMF 200 is a logical function of an NWDAF.

[0058] The DMCF 200 may be capable of generic coordination capabilities that may be agnostic to the type of distributed intelligence technique being used. In the example of Figure 2 the DMCF 200 is the coordinating node of the vertical federated learning and it coordinates the ML model training and inference at a particular client node based on a task assigned particular client node. The steps to realize the training and inference necessitates coordination of distributed nodes in a vertical federated learning setting as the model needs to be trained in a split fashion. In some examples, Coordination of the client nodes involves defining and assigning ML tasks to the client nodes. The DMCF 200 server and the client nodes may comprise NWDAFs, and the interaction between them may be NWDAF-NWDAF interactions. The DMCF 200 may provide an instruction set to the client nodes, where this instruction set consists of instructions (or ML tasks) indicating what each client node should do.

[0059] It will be appreciated that in the future, new distributed learning technologies may be introduced that might potentially replace existing approaches. For this reason, the DMCF 200 may be able to assign tasks to distributed nodes without the distributed nodes needing to know which technology (e.g., split learning, federated learning, transfer learning, and many more) they are part of in training or inference. In particular, the DCMF may be configured to perform the method of Figure 3 described below in order to coordinate the client nodes to perform various ML tasks. The client nodes (which in the case of Figure 2 comprise the gNB 101 , AMF 102, SMF 103 and AF 109) may be configured to perform the method of Figure 6 described below in order to enable their coordination by a coordinating node such as the DCMF 200.

[0060] The system illustrated in Figure 2 provides an example application of the embodiments described herein to the specific use case of E2E volume transfer time analytics. However, it will be appreciated that embodiments described herein may be more generally applied to any ML process that requires coordination. Herein therefore embodiments refer to a coordinating node in a core network of a communications network for coordinating performance of one or more ML tasks by one or more respective client nodes in the core network. The DCMF 200 of Figure 2 is an example implementation of a coordinating node according to some embodiments.

[0061] A coordinating node may have several capabilities that can serve as services, some on-demand and some may be considered required for performance of the ML process. These capabilities may comprise planning of training and / or inference, where the planning may comprise any one or more of i) client node and ML model initialization and / or selection; ii) sample and feature alignment; and iii) ML task placement and scheduling. As a result of the planning, a generated instruction set may be constructed by the coordinating node and may be delivered to the client nodes. The client nodes may than execute the ML tasks requested by the coordinating node.

[0062] The ML tasks may also be customized and impacted by performance reports, indications of whether a model has converged or not (or for example can be inferred from the level of change in the received gradients), availabilities (if not available then when it can be available), computation and energy capabilities, correlation information, quality of the datasets, communication cost in between, and many more factors.

[0063] Figure 3 illustrates a method performed by a coordinating node in a core network of a communications network for coordinating performance (or execution) of one or more machine learning, ML, tasks by one or more respective client nodes. For example, there may be at least one ML task per client node. The one or more ML tasks are part of a first ML process. It will be appreciated that in some cases, the coordinating node may comprise one of the one or more client nodes.

[0064] The method of Figure 3 may be performed by any suitable core network node, which may comprise a physical or virtual node, and may be implemented in a computing device or server apparatus and / or in a virtualized environment, for example in a cloud, edge cloud or fog deployment.

[0065] There are many different types of first ML process to which the method of Figure 3 could be applied. The first ML process may for examples comprise one or more of: a centralized learning process, a distributed learning process (e.g. a federated learning process), supervised learning process, an unsupervised learning process, a reinforcement learning process, self-supervised learning, semi-supervised learning, and a transfer learning process. In other examples, the first ML process may be an inference process, utilizing models that have previously been trained. Regardless of the type of ML process being enabled, the coordinating node performing the method of Figure 3 may, by way of steps 301 to 303, manage the various client nodes involved to ensure the relevant ML tasks are carried out. It will be appreciated that step 301 to 303 may be performed for each of the one or more client nodes involved in the first ML process.

[0066] The one or more ML tasks may for example comprise one or more of: a forward propagation task; a loss computation task; a backward propagation task; a concatenation task; an aggregation task; an update weights task; a layer offload request; a compression or encoding task; a decompression or decoding task; an encryption task; a task to transmit or receive information or, for example in the case of centralized learning, a data collection task. It will be appreciated that many other types of ML task will exist, and will be created in the future. It will be appreciated that any ML task pertaining to the performance of any ML process may be managed and coordinated in the manner described with reference to Figure 3.

[0067] In step 301 , the method comprises transmitting, to a first client node of the one or more client nodes, a request to perform a first respective ML task.

[0068] In step 302, the method comprises transmitting to the first client node, one or more parameters relating to performance of the first respective ML task. In other words, the one or more parameters provide information to the first client node that enable the first client node to perform its respective ML task.

[0069] It will be appreciated that steps 301 and 302 may be performed as part of a single logical step. By performing the method of Figure 3, the coordinating node is able to dynamically configure the performance of the first ML process within the network.

[0070] The one or more parameters of step 302 relating to performance of the respective ML task may comprise one or more of: an input format to be used for the respective ML task; an output format to be used for the output of the respective ML task; an indication of a destination node to transmit the output of the respective ML task to; an indication of ground truth information to be used for the respective ML task; an indication of an aggregation method; an indication of a learning rate or batch size an indication of an optimizer type an indication of source node; a number of neurons to be decreased or increased; an indication of a number of epochs; and an indication of a model identification.

[0071] In some examples, the method of Figure 3 may further comprise step 300 which comprises assigning the one or more ML tasks to the respective one or more client nodes. The assignment of the one or more ML tasks to the respective one or more client nodes may be based on prior information obtained by the coordinating node. For example the prior information may be obtained from the Network Repository Function (NRF) but also from other monitoring functions located in the Data Infrastructure and Machine Learning Operations (MLOps) Tools. Dynamic (up-to-date) resource utilization information such as CPU utilization, available free memory, and storage at the various client nodes may be obtained from data infrastructure (e.g. a data plane or data observability layer responsible for collecting data). In addition, the coordinating node may will keep track of model IDs available at the various client nodes and the corresponding accuracy of the model ID. This latter information may alternatively stored in NRF.

[0072] Other information, e.g. static information, such as the addresses of NWDAFs, capabilities of NWDAFs (e.g, can they train or not), whether an NWDAF can serve or not, whether the NWDAF has the required data or not, whether an NWDAF has a required model or not, etc, may be stored in the NRF.

[0073] It will be appreciated, that in some examples, the assignment may be performed by a node other than the coordinating node, for example a node external to the core network such as an operator node.

[0074] In some examples the coordinating node is informed of which ML tasks are to be performed, and step 300 comprises the coordinating node determining which nodes (e.g. which NFs) should perform which ML tasks. The coordinating node may also determine the timing of the execution of a particular ML task. For example, when two NWDAF instances with the same capabilities are available, the one with the current lowest load may be chosen instead of the one with the higher load. Or if a head client node had previously sent a NACK with a future availability indication, the coordinating node may wait to start training until the time of the future availability indication.

[0075] In some examples, since new approaches for distributed intelligence can be introduced in the future, a capability feature may be stored in a Network Repository Function (NRF) or within the coordinating node which states which approaches are supported or not by the underlying infrastructure.

[0076] As an example, in a split learning setting, the request of step 301 may be a forward propagation request (or as simple as matrix multiplication along with transformation via non-linear functions, with the available input at the distributed nodes). The parameters of step 302 may then comprise an input format, and an output format (e.g. a matrix of activations), and a destination node (e.g. a tail node address). The distributed nodes do not need to reveal exactly which input features they use for the forward pass. Similarly, the coordinator node may ask a client node, which has the available labels (and as such may be considered a tail node), to perform loss computation and then perform backward propagation (which may also comprise a matrix multiplication) and send the computed gradients to distributed (head) nodes.

[0077] In a horizontal FL setting, the request of step 301 may for example be to request a client node to perform training which consists of iterative forward propagation and backward propagation steps on the local dataset. The parameters in this case may therefore be a number of iterations, an output format of the NN model weights, and a destination server to which to send the NN model weights. The destination server may then collect model weights from many clients and perform aggregation. There may be other supplementary information requested such as Hessian matrix to improve the efficiency of training (e.g. as in FedFisher: Leveraging Fisher Information for One-Shot Federated Learning https: / / arxiv.org / pdf / 2403.12329 ).

[0078] In some examples, the method of Figure 3 further comprises step 303 which comprises transmitting a sample indication to the first client node. The sample indication may indicate one or more allowed values for identifiers associated with data samples to be used in performing the respective ML tasks (for example for centralized or vertical federated learning). The sample indication may result from performing a sample alignment process (for example as described with reference to Figure 4).

[0079] For example, the sample indication may indicate (or be derived from e.g. using a key) values of various elements of correlation information (e.g. as described later with reference to correlation information). The sample indication may therefore, for example, indicate allowed values for a timestamp, e.g. any values in the range 3pm-5pm on a particular date GET. This example would mean that only samples having identifiers that indicated timestamps within that range would be allowed for use in performing the respective ML task. In particular, the same sample indication may be provided to each of the one or more client nodes involved in performing the first ML process, so that the samples utilized in performing the first ML process are "aligned”.

[0080] Sample alignment may be used regardless of whether the ML process is centralized or a distributed (e.g. vertical Federated Learning (vFL)) training. In both cases, the data that is collected from different client nodes (e.g. network functions) may be aligned based on correlation information. Correlation information for a particular client node may indicate values of parameters associated with training data samples available at the client node. For example, a particular client node may have access to data related to a UE, UE1 , in the timestamp range of 3pm-7pm. Parameters of the correlation information may for example comprise one or more of the following: a timestamp associated with a training data sample; a user equipment identification associated with a training data sample; a session identification associated with a training data sample; a subscriber identifier associated with a training data sample; Internet Protocol, IP, filter information assocaited with a training data sample; Access Network (AN) tunnel info assocaited with a training data sample; UE IP assocaited with a training data sample; and network slice selection assistance information, S-NSSAI, that identifies a network slice assocaited with a training data sample.

[0081] The correlation information from the various client nodes may then be used to generate the sample indication.

[0082] In embodiments utilising centralized learning, the client nodes (e.g. NFs), which have access to the corresponding relevant data sources, may send data to a destination node that aligns with the sample indication. For example, in centralized learning the node which is used to train a model may query every client node for the data that aligns with the sample indication.

[0083] Previously, in centralised learning, a client node (e.g. an NF) may have transmitted all the available training data to the node training the model, and the node training the model may have been required to filter the data to first determine sample aligned data. However, by having the data effectively filtered by means of the sample indication prior to transmission, this may reduce overhead in the network.

[0084] In distributed learning (e.g. vFL), the client nodes (e.g. gNB, AMF, SMF, and AF) may have data samples that would be considered to align with the sample indication (e.g. the same user and / or time), but the distributed learning may require these client nodes to operate (e.g by a forward propagation) on the samples locally. Therefore, in vFL, the network functions do not deliver the raw dataset as in centralized case.

[0085] Instead, based on the received sample indication, the client nodes required to operate on their respective data sets, may first filter the datasets to ensure that the data used in the respective ML task is has element values that align with the element values of the sample indication. As the activations are therefore produced based on aligned samples, the activations (i.e., extracted embeddings and features from the local raw dataset) received at the destination node, e.g. the tail end, will be aligned.

[0086] For horizontal federated learning, the sample indication may indicate an allowed feature space, and / or a feature space order. In this case therefore, correlation information received from the one or more client nodes may relate to the available feature space at the various client nodes. The sample indication may then indicate to the various client nodes which features to utilize for training, in which order.

[0087] Figure 4 illustrates how samples at various client nodes may be aligned. In this Figure, the x-axis here illustrates an element space, and for clarity only one axis is illustrated. It will be appreciated that there may be any number of axes.

[0088] In this example, client node 1 has available sample sets Xu,i and Xa,i; client node 2 has available sample sets Xu, 2 and Xa,2; client node 3 has available sample sets Xu,3 and Xa,3; and client node 4 has available sample sets (e.g. for use as ground truth labels), Yu,4 and Ya,4-

[0089] In this example, the samples that fall within the sample sets Xa.i, Xa,2, Xa,3, and Ya,4 are considered aligned (e.g. that are aligned on the x-axis which represents the element space for the correlation information). The other sample sets may therefore not be used to perform the respective ML tasks within the first ML process. Figure 5 illustrates an example method for performing a sample alignment process to obtain the sample indication of step 303. The method of Figure 5 may be performed when obtaining the sample indication in examples in which the first ML process comprises a vertical federated leaning process.

[0090] In step 501 the method comprises, for a plurality of client nodes in the one or more client nodes, obtaining correlation information, wherein the correlation information indicates values of elements (e.g. timestamp, UE ID, etc.) associated with training data samples available at the client node. In particular, step 501 may be performed for each of the one or more client nodes. The correlation information may be obtained from the plurality of client nodes in any suitable way. In the example of vFL, the head nodes may send their respective correlation information to the AF, and then AF may send the correlation informations received from the head nodes and its own correlation information to the server DMCF (e.g. the coordinating node). In another example, the correlation information may be directly sent to the coordinating node by all client nodes (e.g. the head nodes and the tail node(s)).

[0091] The correlation information of a client node comprises an indication of values for one or more of the following elements of the training data samples available at the client node: a timestamp associated with a training data sample; a user equipment identification associated with a training data sample; a session identification associated with a training data sample; a subscriber identifier associated with a training data sample;

[0092] Internet Protocol, IP, filter information associated with a training data sample;

[0093] Access Network (AN) tunnel info associated with a training data sample;

[0094] UE IP associated with a training data sample; and network slice selection assistance information, S-NSSAI, that identifies a network slice associated with a training data sample.

[0095] For example, the following correlation information may be received in step 501 :

[0096] Client node 1 : timestamp 3pm -8pm 22 / 09 / 2024, UE IDs: UE1 , UE3

[0097] Client node 2: timestamp 3pm -7pm 22 / 09 / 2024, UE IDs: UE1

[0098] Client node 3: timestamps 3pm-5pm 22 / 09 / 2024, UE ID: UE1, UE3.

[0099] It will be appreciated that in the above example only two elements of correlation information are utilized: timestamps and user equipment identifications. However, correlation information may comprise any number of elements. In step 502 the method of Figure 5 comprises obtaining one or more sample identifications, IDs. A sample ID comprises (or is derived from) correlation information that intersects with all of the obtained correlation information of the plurality of client nodes. In some examples, step 502 may comprise the coordinating node determining the one or more sample IDs. In other examples, the sample IDs may be determined elsewhere, and indicated to the coordinating node.

[0100] In the example above, the one or more sample IDs may indicate the intersection of the obtained correlation information, e.g the possible timestamps for the 3 - 5pm on 22 / 09 / 2024 in conjunction with the UE ID: UE1 .

[0101] In some examples, the sample indication comprises the one or more sample IDs.

[0102] In some cases, there may not be a clear mapping between the correlation information elements provided e.g., International Mobile Subscriber Identity (I MSI) to Subscriber Permanent Identifier (SUPI), hence such mapping may necessitate additional preprocessing in order to be able to compare the correlation information when determining the sample IDs.

[0103] In some examples, the method of Figure 5 further comprises obtaining one or more batch identifications, IDs, wherein a batch ID indicates a subset of the one or more sample IDs. For the example above therefore, the following batch IDs may be obtained:

[0104] Batch ID1 : 3 - 4pm 22 / 09 / 2024 in conjunction with the UE ID: UE1 ; Batch ID2: 4 - 5pm 22 / 09 / 2024 in conjunction with the UE ID: UE1 .

[0105] In some examples, the sample indication comprises a first batch ID of the one or more batch IDs.

[0106] In the training phase, assuming that the datasets were collected in advance of the training, this process of sample alignment can be performed for every batch or per set of batches prior to training.

[0107] In some examples therefore, the method of Figure 5 further comprises transmitting the plurality of batch IDs to the first client node; wherein the request of step 301 is a request to perform a respective plurality of rounds of the respective ML task. A round of the respective ML task is then to use data samples associated with allowed values for elements indicated by a respective one of the plurality of batch ID.

[0108] In other words, the first client node may be instructed to utilize one batch ID per round of the ML task (E.g. per round of training). In some examples, the method of Figure 5 comprises transmitting the plurality of batch IDs in an initiating process prior to commencement of the rounds of ML tasks. IN this was, the training would be sped up by the additional alignment process at the beginning of the training. The coordinating node (e.g. DMCF) (or alternatively AF) constructs a set of batch ids where each is associated with predefined number of sample IDs. The coordinating node (e.g. DMCF) (or alternatively AF) then asks every head and tail node to operate on these constructed batch ids sequentially. If no batch ids can be generated due to disjoint correlation information, then the training cannot start. If AF is instructed to generate batch Id by the coordinating node when there is disjoint correlation information, then it needs to notify DMCF with a NACK.

[0109] It will be appreciated that sample alignment may only be relevant in the forward-propagation and loss computation phases. Once the loss is computed at an aggregated level (e.g., mean squared error, etc.), the backward propagation may not require additional sample alignment.

[0110] If it is a concatenation based split learning, the first layer of the tail node may be partitioned in a way that some neurons receive activations only from a particular head node. In this example, the gradients obtained at the neurons are sent only the connected head node(s). This means that a mapping may be kept at the tail node (e.g. AF) to keep track of which gradients should be sent to which head node. If it is an aggregation based split learning (where the incoming activations are aggregated), then the gradients are broadcasted to all head nodes.

[0111] The following gives examples of how some ML tasks may be requested by the coordinating node (e.g. in step 301 of Figure 3). In these examples, the ML tasks are given the following format function(parameters). The function is the type of ML task requested, and the parameters are the parameters relating to implementation of the respective ML task, according to step 302 of Figure 3. It will be appreciated that there are many other custom functions that a coordinating node may also request the client nodes to perform (for example, one shot communication federated learning, contribution quantification, etc.),

[0112] A task to generate a sample ID may be requested as generafeSamp / eW(correlation_information_list). The parameter “correlationjnformationjist” may comprise the correlation information that has be obtained from the one or more client nodes performing the ML tasks of the first ML process. The output of this task may be: sample id (joint correlation information), which indicates a sample IDs that are common to the correlation information obtained from all clients. If no sample Id can be generated by performing the task to generate sample IDs, then training (or inference) may be unable to start. The task to generate the sample IDs may be, for example, executed either in a coordinating node (e.g. DMCF) or in an AF depending on the choice of the implementation. A task to generate a batch ID may be requested as: generatebatchld(joint_correlation_information_list). The parameter “joint_correlation_information_list” indicates the various Sample IDs that were output from the generateSamplelDQ ML task outlined above. The generatebactchlDQ task may instruct a node to select randomly or specified (from previously generated joint correlation information set) a batch IDs or a plurality of batch IDs, for example, corresponding to an area of interest (Aol) (in an NWDAF information is tagged per Aol to denote the physical area that information is collected from, e.g. from a particular base station), from the generated samplelDs. Each data sample is associated with a sample ID. The result of this task will be a batch ID and each batch ID comprises a plurality of sample IDs. The generatebatchlDQ ML task may be executed, for example, by either the AF or the DMCF. As previously described, the batch ID may be utilized as the sample characteristic indication for a particular round of training.

[0113] An ML task to perform forward propagation may be requested as: forward-propagation(input). The parameter "input” may comprise an input format parameter indicating the format of the input features to feed into the local NN model. The ML task forward-propagation() instructs the corresponding node to feed in the input to the local NN model, and obtain the output of the local NN model. In the case of a head node, the input may comprise input format may comprise input features; in the case of a tail node, the input format may comprise activations, i.e., output(s) of the head node(s).

[0114] An ML task to perform loss computation may be requested as: loss computation(output, actual output). The parameters "output” and "actual output” indicate the output of the local model and the ground truth labels (actual output). In a supervised learning scenario, this functions requests that the receiving client node calculated the error between the output of the model and the actual ground-truth labels based on a loss function. The client node may decide which loss function to use internally,

[0115] An ML task to perform backward propagation may be requested as: backward-propagation(enor or gradients). The parameter "error” or "gradients” represented the input that the client node should utilized to perform the back propagation. In a tail node for example, the backward propagation ML task may be used to compute the gradients, i.e., the level of change in the output of a model with respect to the error of the model. Loss computation may need to be performed before the backward propagation in order to calculated the "error” parameters. It will be appreciated that in a head node for example, the labels are not reachable (e.g. the ground truth), and so the head node may utilize the gradients received from the tail node to perform the backpropagation.

[0116] An ML task to perform concatenation may be requested as: concafenaf / n(activations, input). The parameters "activations” and "input” may relate to what should be concatenated (in this case the activations received at the tail node), and where the concatenation should occur (in this case at the input of the tail node). The concatenation ML task may instruct that the received activations at the tail node from network functions are concatenated at the input of the receiving node. These concatenated activations may then be provided as the input to the NN model at the tail node in the forward-propagation step,

[0117] An ML task to perform aggregation may be requested as aggregationfmodel weights and / or other model parameters, aggregation method). The parameters "model weights” or "model parameters” may indicate what is to be aggregated, and the parameter "aggregation method” indicated which aggregation method to use. The aggregation ML last may instruct the receiving node to aggregate the received models (or other model parameters) or a portion of the models with a selected aggregation method (e.g. for horizontal FL, the aggregation method may be FedAvg, FedAdam, FedMA, FedBoost, FedDist, etc.; and for vertical FL the aggregation method may be a weighted average of activations).

[0118] An ML task to perform compression may be requested as: compression(output). The parameter "output” indicated that the compression should be performed on the output of the local model. The compression ML task may instruct the receiving client node to perform compression or quantization (allowing quantization aware training) before sending the resulting output to another client node.

[0119] An ML task to perform weight updates may be requested as: we / g / ?tL / pdate(current_weights, gradients, additional parameters>). The parameter "current_weights” indicates the current weights of the mode, the parameter "gradients” indicated the gradients calculated according to the back propagation ML task. The weight updated ML task may instruct the receiving client node to perform a weight update to obtain new model weights by requesting to change the current weights of the model with respect to the computed gradients according to stochastic gradient descent or a-like. Additional parameters ("<additional_parameters”) may also be sent optionally by the coordinating node to speed up of the model training depending on the rate of convergence such as a learning rate, an optimizer type, a batch size (which may be embedded into the shared batch id information),

[0120] An ML task to offload NN layers to another client node may be requested as: / ayerOff / oadRequesf(body={nr_of_layers=N, weight_matrix=Z_}, dest=destination address / topic). The parameter "nr_of_layers” indicates the number of layers to offload, the parameter "weight_matrix” indicates the set of (matrix of) numerical values that correspond to the coefficients of the connections between neurons, where the weight of the connection stands for the level of impact of the output of pre-synaptic neuron on the overall output of the post synaptic neuron of a neural network model, and the parameter "dest” indicated the destination node to offload the layers to. The offload NN layers ML task may instruct the receiving client node to offload N layers to another client node. For example, the coordinating node may assign this task to the AF to offload its layers to the NWDAF in the AF (via NEF). How many layers to offload may be determined by the performance monitoring reports that include the computation and energy availabilities.

[0121] There may also be other tasks related to delivery such as :

[0122] An ML task to send information may be requested as: send(body=content, dest=destination address / topic). The parameter "content” indicates the information to be sent (e.g. activations), and the parameter "dest” indicates the destination to send the content to.

[0123] An ML task to listen to received information may be requested as: listen(body=content. src=source address / topic): The parameter "content” indicates the information to be received (e.g. activations), and the parameter "src” indicates the source the content will be received from or the topic the content will be received via (e.g., in Kafka).

[0124] An ML task to increase the number of neurons at a cut layer may be requested as: increase_neurons_at_cut_layer(p). This ML task may instruct the receiving client node to increase the number of neurons at the interfacing cut-layer of the corresponding node by n units. This ML task may be triggered when the error resulting at the local model is too high.

[0125] An ML task to decrease the number of neurons at a cute layer may be requested as: decrease_neurons_at_cut_layer(n). This ML task may instruct the receiving client node to decrease the number of neurons at the interfacing cut-layer of the corresponding node by n units. This ML task may be triggered when the communication cost is too high and resulting error at the local model is not expected to increase too much by reducing the neuron count at the cut-layer.

[0126] Certainly the implementation options for the various ML tasks above are just examples, and there may be many other implementation options. For example, another alternative would be to embed the delivery functions such as Hsten and send(), optionally within the other ML tasks such as:

[0127] • backwardPropagation(src=None, body=gradients_AMF, dest=AMF)

[0128] In the above ML task, the receiving client node of the ML task task such as a head AMF NWDAF client node may be expected to obtain the gradients via a backward propagation and send the results to AF. In that case source and destination fields may need to be kept empty for some functions if they are an (semi- )intermediate function, (meaning partially interfacing process with other nodes) and not directly processing on the received input, or if they are not sending the result of the function immediately after the requested task. • forwardPropagation(batchld, dest=AF)

[0129] Similarly, in the above ML task , the client node may be asked to perform forward propagation on the requested batchld, and then delivers the resulting activations to a destination AF.

[0130] Returning to the method of Figure 3, in some embodiments the requests for performing the respective one or more ML tasks may be transmitted to the one or more client nodes prior to commencement of any of the one or more ML tasks (e.g. prior to training). Table 1 gives an example of multiple requests transmitted to each of the head nodes and the tail node in a vFL process.

[0131] Table 1: ML tasks transmitted to head node(s) and a tail node in an example vFL process.

[0132] In some examples therefore, the coordinating node may transmit, to the first client node, an indication that the respective ML task is to be performed upon fulfilment of a condition.

[0133] This has advantages over the sequential way of transmitting ML tasks, as it may reduce signalling overhead at the NFs. Instead, a conditional instruction set may be utilised that can be delivered by the coordinating node to the one or more client nodes so that they perform the given tasks upon occurrence of relevant events.

[0134] An example of a condition for a tail node AF may be "wait until all activations are received, and if all activations are received then concatenate all activations and then perform forward propagation, loss computation and then backward propagation, update weights, and then send the gradients back to the clients, wait until new activations are received.” An example of a condition for a head node may be "Perform forward propagation on input data, send the activations to AF, and wait for gradients. If gradients are received, perform backward propagation, update weights, and perform forward propagation and send to AF, and wait for gradients.”

[0135] It is important to note that the clients that take part in training does not necessarily have to be the same clients that take part in inference, therefore the trained model may be broadcasted to other potential nodes for performing inference. This way, the clients are made ready for inference.

[0136] Figure 6 is a flowchart illustrating a method performed by a client node of a communications network for enabling performance of a machine learning task, wherein the ML task is part of a first ML process. The first ML process may be as described above with reference to Figure 3. The one or more ML tasks may be as described above with reference to Figure 3.

[0137] The method of Figure 6 may be performed by any suitable core network node, which may comprise a physical or virtual node, and may be implemented in a computing device or server apparatus and / or in a virtualized environment, for example in a cloud, edge cloud or fog deployment. It will be appreciated that the method of Figure 6 may be performed by an NWDAF that may be a logical part of another core network function (e.g. AMF, SMF). The method of Figure 6 may also be performed by an AF. In some embodiments the method may start at step 601 which comprises receiving, from a coordinating node, a request to perform the ML task. The coordinating node may be configured to perform the method as described with respect to Figures 3 and / or 5. Step 601 may be considered to correspond to step 301 of Figure 3.

[0138] In step 602, the method comprises receiving from the coordinating node, one or more parameters relating to implementation of the ML task. Step 602 may be considered to correspond to step 302 of Figure 3. The one or more parameters relating to implementation of the ML task may be as described above.

[0139] In some embodiments the method may then pass to Step 604, which comprises performing the ML task.

[0140] In some examples, the one or more parameters relating to performance of the respective ML task comprises an input format to be used for the ML task. In these examples, step 604 may comprise performing the ML task utilizing input data of the input format.

[0141] In some examples, the one or more parameters relating to performance of the respective ML task comprises an output format to be used for the output of the ML task. In these examples step 604 comprises performing the ML task to generate output data of the output format.

[0142] In some examples, the one or more parameters relating to performance of the respective ML task comprises: an indication of a destination node to transmit the output of the respective task to. In these examples, the method of Figure 6 may further comprise transmitting an output of the ML task to the destination node.

[0143] In some examples, for example where the first ML process comprises a vFL process, the method of Figure 6 may further comprise step 600 (which may occur prior to step 601) which comprises transmitting correlation information to the coordinating node (or to an AF), wherein the correlation information indicates values of elements associated with the training data samples that are available at the client node.

[0144] In these examples, the method may further comprise step 603 which comprises: receiving a sample indication from the coordination node, wherein the sample indication indicates one or more allowed values for elements associated with data samples. Step 604 may then comprises performing the ML task utilizing training data samples that conform with the sample indication.

[0145] It will be appreciated that steps 601 to 603 may be performed in a single logical step, or may be performed in any suitable order. In some examples, the sample indication comprises a first batch ID of a plurality of batch IDs. The method of Figure 6 may then comprise receiving the plurality of batch IDs (e.g in step 603), wherein the request of step 601 is a request to perform a respective plurality of rounds of the ML task. Step 604 may then comprise performing the plurality of rounds of the ML task, wherein a round of the ML task utilizes training data samples conforming to a respective one of the plurality of batch IDs.

[0146] The plurality of batch IDs (e.g. of step 603) may be received in an initiating process prior to performing the rounds of ML tasks.

[0147] In some examples, the method of Figure 6 comprises receiving, from the coordinating node, an indication that the ML task is to be performed upon fulfilment of a condition. Examples of various conditions are described above. In these examples, step 704 may be performed upon fulfillment of the relevant condition.

[0148] Figure 7 is a signaling diagram illustrating an example implementation of the method of Figures 3 and 6.

[0149] In this example, the client nodes comprise a first head node (the client NWDAF on the gNB) 751, a second head node (the client NWDAF on the AMF) 752, a third head node (the client NWDAF on the SMF) 753, and a tail node (the AF) 754. In this example, the head nodes and the tail node are client nodes of a vFL process.

[0150] In this embodiments the core network further comprises a DCMF located on a server NWDAF (e.g. a coordinating node) 755. The core network further comprises a NEF 756 enabling communication between the head nodes and the tail node.

[0151] In steps 701 to 703 DCMF 755 transmits the same listen(batchld, source=AF) task to the first to the third client nodes 751 to 753. This means that the corresponding head nodes should listen for batchlds from the fourth client node 754. After this point, all head nodes are in waiting state. Steps 701 to 703 each comprise example implementations of steps 301 and 302 of Figure 3 and steps 601 and 602 of Figure 6.

[0152] In step 704, the DMCF 705 sends the tail node 754 (via NEF 706) a series of ML tasks : (selectBatchld send(body=batchld, dest={AMF, SMF, gNB})), meaning that the AF is asked to generate a batch ID and send the batch ID to the head nodes 751 to 753. Step 704 comprises example implementations of steps 301 and 302 of Figure 3 and steps 601 and 602 of Figure 6. In steps 705-707, the tail node 754 selects a batch ID (batchld) from a previously generated a set of batch IDs (which may have been generated according to the method of Figure 5, and / or as described below with reference to Figure 8) and sends the batch ID to the corresponding head nodes 751 to 753. Step 705 to 707 comprise an example implementation of step 603 of Figure 6 (the head nodes receiving the sample indication, in this case the batch ID)

[0153] The tail node 754 may then goes to idle mode until it receives a new task from the DCMF 755. In steps 708-710, the head nodes 751 to 753 that are in the listening state, then receive the batch ID sent by the tail node 754, and then respond back with acknowledgements to the DCMF 755.

[0154] In step 711 , DCMF 755 then sends a new task to the tail node 754: / / sten(body=activations, source=(AMF, SMF, gNB)). This ML task means that the tail node 754 starts listening for activations that would be sent by the first to third head nodes 751 to 753. Step 711 comprises an example implementations of steps 301 and 302 of Figure 3 and steps 601 and 602 of Figure 6.

[0155] In steps 712-714, the DCMF 755 then sends ML tasks forwardPropagation(batchld) and send(body=[activations, batchld], dest=AF) to the head nodes 751 to 753. Steps 712 to 714 each comprise example implementations of steps 301 and 302 of Figure 3 and steps 601 and 602 of Figure 6.

[0156] The head nodes 751 to 753 then perform forward propagation on their local samples that correspond to the batchld utilising their local ML models. Steps 701 to 703 comprise example implementations of step 604 of Figure 6.

[0157] In steps 715-717, the head nodes 751 to 753 then send the activations and the corresponding batch ID to the tail node (as instructed in the send() of steps 701 to 703). Steps 715 to 717 comprise examples implementations of step 604 of Figure 6.

[0158] In step 718, the tail node 754 responds back with an acknowledgments.

[0159] This triggers DCMF 755, in steps 719-721 , to broadcast listen(body=gradients, src=AF), backwardPropagation(gradients) ML tasks to the head nodes 751 to 753 and the head nodes 751 to 753 start listening for gradients from the tail node 754 and performing backward propagation on the received gradients when received. Steps 719 to 721 each comprise example implementations of steps 301 and 302 of Figure 3 and steps 601 and 602 of Figure 6. In step 722, the DCMF 755 also sends a series of ML tasks to the tail node 754 to compute loss, backward propagation on the computed loss, send the gradients to AMF (NWDAF), SMF (NWDAF) and gNB (NWDAF), and then update local model weights. Step 722 comprises an example implementation of steps 301 and 302 of Figure 3 and steps 601 and 602 of Figure 6..

[0160] In steps 723-725, the tail node 754 sends the computed gradients to the head nodes 751 to 753. At this point, due to the ML tasks received by the head nodes 751 to 753 in steps 719 to 721, the head nodes perform backpropagation on their local ML models utilising the received gradients in steps 723 to 725.

[0161] The head nodes 751 to 753, in steps 726-728, respond back to the DCMF 755 with acknowledgments.

[0162] The DCMF 755 then sends a new ML task updateWeights(gradients) to the head nodes 751 to 753 in steps 729-731. Steps 729 to 731 each comprise an example implementation of of steps 301 and 302 of Figure 3 and steps 601 and 602 of Figure 6.

[0163] The head nodes 751 to 753 will then update the weights of their local models accordingly.

[0164] This completes one round of vFL training, and the training may continue until the DCMF 755 (or alternatively the tail node 754) stops the training, in steps 732-724, after detecting an indication of model convergence.

[0165] In step 735, the DCMF 755 may also notifies the NF consumer 757 about the completion of training. This indicated to the NF consumer 757 that the training is completed, and the models are ready for inference.

[0166] The head nodes 751 to 753 may then be asked to broadcast the trained model with other similar network nodes in steps 736-738.

[0167] It is may be that the receiver clients receive listen (or could be very well subscription to a topic where this topic contains messages destined to the receiving / listening client) task before the sender receives the send task.

[0168] The training may be ended when a desired condition is reached. Conditions may depend on the training budget, e.g., number of communication rounds, targeted accuracy value, etc.

[0169] Figure 8 is a signalling diagram illustrating an example implementation of the method of Figure 5.

[0170] The core network system of Figure 8 corresponds to the system described with reference to Figure 7. In steps 801 to 803 the DCMF 755 requests correlation information from each of the head nodes 751 to 753 and the tail node 754.

[0171] In steps 805 to 808 the head nodes and the tail node all respond with their respective correlation information. Steps 805 to 808 each comprise an example implementation of step 600 of Figure 6. Steps 805 and 808 also comprise an example implementation of step 501 of Figure 5.

[0172] In step 809 the DCMF generates the sample IDs. Step 809 comprises an example implementation of step 502 of Figure 5.

[0173] In step 810 the DCMF generates batch IDs from the sample IDs.

[0174] In step 811, 812 to 814 the DCMF 755 transmits the ML task send(body=activations(batchld), deest=AF) to each of the head nodes 751 to 753. Steps 811, 812 and 814 each comprise an example implementation of steps 301 and 302 of Figure 3 and 601 and 602 of Figure 6.

[0175] However, at step 815 a concept drift occurs at the head node 752. This means that the data distributed available for training at this head node has changes.

[0176] In steps 815 to 817 the head nodes 751 to 753 return the activations to the tail node (AF) 754 as requested in steps 811 , 812 and 814. However, the head node 752 also flags that there has been concept drift. The batch IDs utilized by the head nodes 751 to 753 to produce the activations are also included. The tail node 754 may check that the received batch IDs match.

[0177] In step 818 the DCMF 755 instructs the tail node 754 to perform the ML task of concatenating the received activations in steps 815 to 817 with the local activations.

[0178] In step 819 however, model performance degradation is detected, for example, due to the flagged concept drift received in step 816. In some examples, the input to the model may have gradually stopped affecting its output (different inputs starts producing the same output which means that the input data distribution has changed significantly).

[0179] In step 820 the tail node 754 flags to the DCMF 755 that there is a degradation in the performance of the sample IDs. In step 821 the DCMF 755 generates new sample IDs.

[0180] In step 822 the DCMF 755 then selects a new batch ID from the generated batch IDs in step 810.

[0181] Steps 811 , 812, 814, 815, 816, 817 and 818 are then repeated with the new batch ID as steps 823 to 829 (without the concept drift occurring).

[0182] Figure 9 illustrates a coordinating node 900 comprising processing circuitry (or logic) 901. The processing circuitry 901 controls the operation of the coordinating node 900 and can implement the method described herein in relation to a coordinating node 900. The processing circuitry 901 can comprise one or more processors, processing units, multi-core processors or modules that are configured or programmed to control the coordinating node 900 in the manner described herein. In particular implementations, the processing circuitry 901 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 coordinating node 900. It will be appreciated that the coordinating node 900 may comprise one or more virtual machines running different software and / or processes. The coordinating node 900 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.

[0183] Optionally, the coordinating node 900 may comprise a memory 903. In some embodiments, the memory 903 of the coordinating node 900 can be configured to store instructions (e.g. program code) executable by the processing circuitry 901 of the coordinating node 900 whereby the apparatus is operable the perform the method as described with reference to Figure 3 and / or Figure 5.

[0184] Alternatively or in addition, the memory 903 of the coordinating node 900, can be configured to store any requests, resources, information, data, signals, or similar that are described herein. The processing circuitry 901 of the coordinating node 900 may be configured to control the memory 903 of the coordinating node 900 to store any requests, resources, information, data, signals, or similar that are described herein

[0185] In some embodiments, the coordinating node 900 may optionally comprise a communications interface 902. The communications interface 902 of the coordinating node 900 can be for use in communicating with other nodes, such as other virtual nodes. For example, the communications interface 902 of the coordinating node 900 can be configured to transmit to and / or receive from other nodes requests, resources, information, data, signals, or similar. The processing circuitry 901 of coordinating node 900 may be configured to control the communications interface 902 of the coordinating node 900 to transmit to and / or receive from other nodes requests, resources, information, data, signals, or similar. The communications interface 902 can use any suitable communication technology.

[0186] The coordinating node 900 may be configured operate in the manner described herein in respect of a coordinating node or a DCMF.

[0187] Figure 10 illustrates a client node 1000 comprising processing circuitry (or logic) 1001. The processing circuitry 1001 controls the operation of the client node 1000 and can implement the method described herein in relation to a client node 1000. The processing circuitry 1001 can comprise one or more processors, processing units, multi-core processors or modules that are configured or programmed to control the client node 1000 in the manner described herein. In particular implementations, the processing circuitry 1001 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 client node 1000. It will be appreciated that the client node 1000 may comprise one or more virtual machines running different software and / or processes. The client node 1000 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.

[0188] Optionally, the client node 1000 may comprise a memory 1003. In some embodiments, the memory 1003 of the client node 1000 can be configured to store instructions (e.g. program code) executable by the processing circuitry 1001 of the client node 1000 whereby the apparatus is operable to perform the method as described with reference to Figure 6.

[0189] Alternatively or in addition, the memory 1003 of the client node 1000, can be configured to store any requests, resources, information, data, signals, or similar that are described herein. The processing circuitry 1001 of the client node 1000 may be configured to control the memory 1003 of the client node 1000 to store any requests, resources, information, data, signals, or similar that are described herein

[0190] In some embodiments, the client node 1000 may optionally comprise a communications interface 1002. The communications interface 1002 of the client node 1000 can be for use in communicating with other nodes, such as other virtual nodes. For example, the communications interface 1002 of the client node 1000 can be configured to transmit to and / or receive from other nodes requests, resources, information, data, signals, or similar. The processing circuitry 1001 of client node 1000 may be configured to control the communications interface 1002 of the client node 1000 to transmit to and / or receive from other nodes requests, resources, information, data, signals, or similar. The communications interface 1002 can use any suitable communication technology. The client node 1000 may be configured operate in the manner described herein in respect of an client node.

[0191] There is also provided a computer program comprising instructions which, when executed on a least one processor (such as the processing circuitry 1001 of the client node 1000 described earlier), cause the processor to carry out at least part of the method(s) described herein. According to some embodiments there is provided a carrier containing the computer program. In some embodiments, the carrier can be any one of an electronic signal, an optical signal, an electromagnetic signal, an electrical signal, a radio signal, a microwave signal, or a computer-readable medium. There is also provided a (for example, tangible and / or non-transient) computer-readable medium comprising instructions which, when executed by at least one processor, cause the at least one processor to perform at least part of the method(s) described herein.

[0192] Figure 11 is a block diagram illustrating a virtualization environment 1100 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 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 1100 hosted by one or more of hardware nodes, such as a hardware computing device that operates as a network node, UE, 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 1100 includes components defined by the O-RAN Alliance, such as an O-Cloud environment orchestrated by a Service Management and Orchestration Framework via an O-2 interface. Virtualization may facilitate distributed implementations of a network node, UE, core network node, or host.

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

[0194] Hardware 1104 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 1106 (also referred to as hypervisors or virtual machine monitors (VMMs)), provide VMs 1108a and 1108b (one or more of which may be generally referred to as VMs 1108), and / or perform any of the functions, features and / or benefits described in relation with some embodiments described herein. The virtualization layer 1106 may present a virtual operating platform that appears like networking hardware to the VMs 1108.

[0195] The VMs 1108 comprise virtual processing, virtual memory, virtual networking or interface and virtual storage, and may be run by a corresponding virtualization layer 1106. Different embodiments of the instance of a virtual appliance 1102 may be implemented on one or more of VMs 1108, 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.

[0196] In the context of NFV, a VM 1108 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 1108, and that part of hardware 1104 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 1108 on top of the hardware 1104 and corresponds to the application 1102.

[0197] Hardware 1104 may be implemented in a standalone network node with generic or specific components. Hardware 1104 may implement some functions via virtualization. Alternatively, hardware 1104 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 1110, which, among others, oversees lifecycle management of applications 1102. In some embodiments, hardware 1104 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 signaling can be provided with the use of a control system 1112 which may alternatively be used for communication between hardware nodes and radio units.

[0198] The proposed coordinating node (e.g. Distributed Model Coordination Function (DMCF)) enables automation to satisfy ML Key Performance Indicators KPIs such as efficacy (accuracy), communication cost, computation cost, memory and storage cost, energy consumption, privacy, robustness, and flexibility. Having the instruction set defined to realize coordination of clients in vFL enables embodiments described herein to automatically and clearly define the responsibilities of each client node. 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. The word "comprising” does not exclude the presence of elements or steps other than those listed in a claim, "a” or "an” does not exclude a plurality, and a single processor or other unit may fulfil the functions of several units recited in the claims. Any reference signs in the claims shall not be construed so as to limit their scope.

Claims

33CLAIMS1. A method performed by a coordinating node in a core network of a communications network for coordinating execution of one or more machine learning, ML, tasks to be executed by one or more respective client nodes, wherein the one or more ML tasks are parts of a first ML process, wherein the first ML process is a distributed learning process, the method comprising: transmitting (301), to a first client node of the one or more client nodes, a request to perform the respective ML task; and transmitting (302) to the first client node, one or more parameters relating to implementation of the respective ML task.

2. The method as claimed in claim 1 wherein the one or more parameters relating to performance of the respective ML task comprise one or more of: an input format to be used for the respective ML task; an output format to be used for the output of the respective ML task; an indication of a destination node to transmit the output of the respective ML task to; an indication of ground truth information to be used for the respective ML task; an indication of an aggregation method; an indication of a learning rate or batch size an indication of source node; a number of neurons to be decreased or increased; an indication of a number of epochs; and an indication of a model identification.

3. The method as claimed in claim 1 or 2, further comprising: assigning (300) the one or more ML tasks to the respective one or more client nodes.

4. The method as claimed in any one of claims 1 to 3, further comprising transmitting (303) a sample indication to the first client node, wherein the sample indication indicates one or more allowed values for elements associated with data samples to be used in performing the respective ML tasks.

5. The method as claimed in claim 4, wherein the first ML process comprises vertical federated learning, the method further comprising: for a plurality of client nodes in the one or more client nodes, obtaining (501) correlation information, wherein the correlation information indicates values of elements associated with training data samples available at the client node; and34 obtaining (502) one or more sample identifications, IDs, wherein a sample ID comprises correlation information that intersects with all of the obtained correlation information of the plurality of client nodes.

6. The method of claim 5 further comprising determining the one or more sample IDs.

7. The method as claimed in any one of claims 5 or 6, wherein the correlation information of a client node comprises an indication of values for one or more of the following elements of training data samples available at the client node: a timestamp associated with a training data sample; a user equipment, UE, identification associated with a training data sample; a session identification associated with a training data sample; a subscriber identifier associated with a training data sample;Internet Protocol, IP, filter information assocaited with a training data sample;AN tunnel info assocaited with a training data sample;UE IP assocaited with a training data sample; and network slice selection assistance information, S-NSSAI, that identifies a network slice assocaited with a training data sample.

8. The method as claimed in any one of claims 4 to 7, wherein the sample indication comprises the one or more sample IDs.

9. The method as claimed in any one of claims 4 to 7, further comprising obtaining one or more batch identifications, IDs, wherein a batch ID indicates a subset of the one or more sample IDs.

10. The method as claimed in claim 9 wherein the sample indication comprises a first batch ID of the one or more batch IDs.

11. The method as claimed in claim 10, further comprising: transmitting the plurality of batch IDs to the first client node; wherein the request is a request to perform a respective plurality of rounds of the respective ML task, wherein a round of the respective ML task is to use data samples associated with allowed values for parameters indicated by a respective one of the plurality of batch ID.

12. The method as claimed in claim 11 further comprising transmitting the plurality of batch IDs in an initiating process prior to commencement of the rounds of ML tasks.

13. The method as claimed in any ne of claims 1 to 12 further comprising: transmitting, to the first client node, an indication that the respective ML task is to be performed upon fulfilment of a condition.

14. The method as claimed in any one of claims 1 to 13, wherein the first ML process comprises one or more of:, a federated learning process, a reinforcement learning process, a supervised learning process, an unsupervised learning process, self-supervised learning, semi-supervised learning, transfer learning, or an inference process.

15. The method as claimed in any one of claims 1 to 14, wherein the one or more ML tasks may comprise one or more of: a forward propagation task; a loss computation task; a backward propagation task; a concatenation task; an aggregation task; an update weights task; a layer offload request; a compression or encoding task; and a decompression or decoding task; an encryption task; a task to transmit or receive information.

16. The method as claimed in any one of claims 1 to 15, wherein the coordinating node comprises a Distributed Model Coordination Function, DMCF, (200) in the core network.

17. The method as claimed in claim 16 wherein the DMCF is a logical function of an Network Data Analytics Function, NWDAF (103).

18. The method as claimed in any one of claims 1 to 17, wherein the first client node comprises one of: a Network Data Analytics Function, and an Application Function (109).

19. A method performed by a client node in a communications network for enabling execution of a machine learning task, wherein the ML tasks is part of a first ML process, wherein the first ML process is a distributed learning process, the method comprising: receiving (601), from a coordinating node in a core network, a request to perform the ML task; and receiving (602) from the coordinating node, one or more parameters relating to implementation of the ML task.

20. The method as claimed in claim 19 wherein the one or more parameters relating to performance of the respective ML task comprises an input format to be used for the ML task, and the method further comprising: performing the ML task utilizing input data of the input format.

21. The method as claimed in claim 19 or 20 wherein the one or more parameters relating to performance of the respective ML task comprises: an output format to be used for the output of the ML task, the method further comprising: performing the ML task to generate output data of the output format.

22. The method as claimed in claim any one of claims 19 to 21 wherein the one or more parameters relating to performance of the respective ML task comprises: an indication of a destination node to transmit the output of the respective task to; the method further comprising: transmitting an output of the ML task to the destination node.

23. The method as claimed in claim 19 to 22, wherein the one or more parameters relating to performance of the respective ML task comprise one or more of: an indication of ground truth information to be used for the respective ML task; an indication of an aggregation method; an indication of a learning rate or batch size; an indication of source node; a number of neurons to be decreased or increased; an indication of a number of epochs; and an indication of a model identification.

24. The method as claimed in claim 19 to 23, further comprising: receiving (603) a sample indication from the coordination node, wherein the sample indication indicates one or more allowed values for elements associated with data samples, and37 performing (604) the ML task utilizing training data samples that conform with the sample indication.

25. The method as claimed in claim 24 further comprising: transmitting (600) correlation information to the coordinating node, wherein the correlation information indicates values of elements associated with the training data samples that are available at the client node.

26. The method as claimed in 25 wherein the correlation information comprises an indication of values for one or more of the following elements associated with the available training data samples at the client node: a timestamp associated with a training data sample; a user equipment identification associated with a training data sample; a session identification associated with a training data sample; a subscriber identifier associated with a training data sample;Internet Protocol, IP, filter information assocaited with a training data sample;Access Newtork (AN) tunnel info assocaited with a training data sample;UE IP assocaited with a training data sample; and network slice selection assistance information, S-NSSAI, that identifies a network slice assocaited with a training data sample.

27. The method as claimed in claim 24 to 26, wherein the sample indication comprises a first batch ID of a plurality of batch IDs, the method comprising: receiving the plurality of batch IDs, wherein the request is a request to perform a respective plurality of rounds of the ML task, and performing the plurality of rounds of the ML task, wherein a round of the ML task utilizes training data samples conforming to a respective one of the plurality of batch IDs.

28. The method as claimed in claim 27 further comprising receiving the plurality of batch IDs in an initiating process prior to performing the rounds of ML tasks.

29. The method as claimed in any one of claims 19 to 28 further comprising: receiving, from the coordinating node, an indication that the ML task is to be performed upon fulfilment of a condition.3830. The method as claimed in any one of claims 19 to 29, wherein the first ML process comprises one or more of:, a federated learning process, a reinforcement learning process, a supervised learning process, an unsupervised learning process, self-supervised learning, semi-supervised learning, transfer learning, or an inference process.31 . The method as claimed in claim wherein the one or more ML tasks may comprise one or more of: a forward propagation task; a loss computation task; a backward propagation task; a concatenation task; an aggregation task; an update weights task; a layer offload request; a compression or encoding task; and a decompression or decoding task; an encryption task; and a task to transmit or receive information.

32. The method as claimed in any one of claims 19 to 31, wherein the coordinating node comprises a Distributed Model Coordination Function, DMCF, (200) in a core network.

33. The method as claimed in claim 32, wherein the DMCF is a logical function within a Network Data Analytics Function, NWDAF (103).

34. The method as claimed in any one of claims 19 to 33, wherein the client node comprises one of: a Network Data Analytics Function, and an Application Function.

35. A coordinating node (900, 200) in a core network of a communications node for coordinating execution of one or more machine learning tasks to be executed by one or more respective client nodes, wherein the one or more ML tasks are part of a first ML process, wherein the first ML process comprises a distributed learning process, the coordinating node comprising processing circuitry (901) and a memory (903), the memory containing instructions executable by the processing circuitry whereby the coordinating node is operable to: transmit (301), to a first client node of the one or more client nodes, a request to perform the respective ML task; and39 transmit (302) to the first client node, one or more parameters relating to implementation of the respective ML task.

36. The coordinating node as claimed in claim 35 wherein the memory further contains instructions executable by the processing circuitry whereby the coordinating node is operable to perform the method as claimed in any one of claims 2 to 18.

37. A client node (1000) in a communications network for enabling execution of a machine learning task, wherein the ML task is part of a first ML process, wherein the first ML process comprises a distributed learning process, the client node comprising processing circuitry (1001) and a memory (1003), the memory containing instructions executable by the processing circuitry whereby the client node is operable to: receive (601), from a coordinating node in a core network, a request to perform the ML task; and receive (602) from the coordinating node, one or more parameters relating to implementation of the ML task.

38. The coordinating node as claimed in claim 35 wherein the memory further contains instructions executable by the processing circuitry whereby the client node is operable to perform the method as claimed in any one of claims 20 to 34.

39. A computer program, comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out a method according to any of claims 1 to 34.

40. A computer-readable medium comprising instructions that, when executed on at least one processor, cause the at least one processor to perform the method according to any of claims 1 to 34.41 . A computer program product comprising non transitory computer readable media having stored thereon a computer program according to claim 39.

Images