Coordinating a distributed inference process

Abstract

A method is performed by a coordinating node (1200), for coordinating execution of one or more machine learning (ML) tasks to be executed by one or more respective client nodes (1300). The one or more ML tasks generate intermediate outputs and comprise first parts of a distributed inference process. A second part of the distributed inference process is executed by a server node and comprises using the intermediate outputs to generate an output of the distributed inference process. The method comprises: identifying (302) a first client node of the one or more client nodes by determining that the first client node has access to input data relevant to an analytics request; requesting (304) the first client node to generate at least one intermediate output by executing, using the input data, the respective ML task of the one or more ML tasks; and receiving (306), from the server node, an output of the distributed inference process.

Description

[0001] COORDINATING A DISTRIBUTED INFERENCE PROCESS

[0002] Technical field

[0003] Embodiments of the present disclosure relate to distributed inference processes, and particularly to methods, apparatus, and machine-readable medium relating to the coordination of distributed inference processes.

[0004] Background

[0005] There are cases of Machine Learning (ML) in which datasets and models cannot be moved, or it is not desirable 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 distributed learning (e.g., split learning) may be used. For example, split learning is an ML technique that realizes vertical Federated Learning (FL).

[0007] In split learning, an ML model is split into at least two parts (or sub-models), where each part (or sub-model) may reside at a node close to the input data required for that part and may be rich in compute. To preserve privacy of the input data, the split parts only share their output (e.g., activations or gradients) with the other split parts. These outputs may be referred to herein as “intermediate outputs”, “intermediate results”, “intermediate variables”, etc. If a node hosting one of the split parts runs out of compute, the layers of the part residing at that node could be moved to other nodes / parts, thus offloading the affected node.

[0008] If input data for a second ML model part is an output of a first ML model part, then the node that holds the first ML model part is referred to as the head node, and the node that holds the second ML model part is referred to as the tail node. A head node does not hold labels for the distributed model, whilst a tail node does hold labels for the distributed model.

[0009] The head node may take input data and send the output of the local model, a so called activation (or intermediate result), to the tail node. The tail node may then take the received activation(s) in addition to its local data as an input to its local model, and then provide an output, e.g. an estimation. During training, the tail node may compare the output (e.g. an 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 obtainedgradients 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. Once training is complete, the head and tail nodes may use their trained ML model parts (local models) with their input data to conduct inference.

[0010] As can be understood from the description above, the head nodes only share their intermediate outputs (e.g. activations (or “representations”)) with tail nodes, which (in addition to other protocols and mechanisms) helps address privacy concerns. This is beneficial, for example, in scenarios where the head and tail nodes are owned by different vendors.

[0011] 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.

[0012] To illustrate the benefits of distributed inference, Figure 1 is a schematic diagram of architecture for performing centralized inference. The architecture comprises a Radio Access Network (RAN) comprising a gNB 101, and a Core Network (CN) comprising an Access and Mobility Management Function (AMF) 102, a Network Data Analytics Function (NWDAF) 103, a Session Management Function (SMF) 104, a User Plane Function (UPF) 105, a Unified data Management (UDM) 106, and a Network Exposure Function (NEF) 107. A UE 108 running an application acts as a Network Function (NF) consumer, and the data network (DN) provides an Application Function (AF) 109 and an application server 110.

[0013] The architecture of Figure 1 is discussed below for the use case of E2E data volume transfer time analytics. The input data required for this use case, and the output analytics, can be found in the respective tables in 3rdGeneration Partnership Project (3GPP) TS 23.288 (sections 6.18.2 and 6.18.3).

[0014] As illustrated in Figure 1, the NWDAF 103 receives the labels for training (volume and duration of the end-to-end transfer) from the AF 109. The NWDAF 103 also receives data (which may also be referred to herein as “datasets” or “data items”) from various datasources including the gNB 101, the AMF 102, and the SMF 104. Data provided to the NWDAF 103 is represented by the arrows. The NWDAF 103 may receive the data at different sampling rates, depending on the parameters of the data transfer.

[0015] The datasets may be collected to perform training of an AI / ML model when requested. The datasets may also be used to perform inference or other statistics analysis. Collected data items from different sources may be correlated to each other by using, for example, a combination of timestamps and identities (e.g., UE identities such as Subscription Permanent Identifiers (SUPIs)) and session identities).

[0016] However, due to reasons such as privacy, data security, access rights, and large data sizes, it may not be desirable for the NWDAF 103 to collect datasets from other NFs in order to train the AI / ML model and / or to perform inference using the trained AI / ML model. Consequently, analytics tasks such as E2E data volume transfer time analytics may be trained with horizontal FL, which is discussed in relation to Figure 2.

[0017] For horizontal FL, all participants (i.e., the nodes hosting local versions of a global model) have the same feature space but have access to different data samples. In contrast, for vertical FL, all participants (i.e., the nodes hosting respective parts of a global model) may have different feature spaces but have access to the same data samples.

[0018] Figure 2 is a schematic diagram of architecture for performing horizontal federated inference. The architecture comprises regions A, B, and C, wherein each region includes a RAN comprising a gNB 201 and a CN comprising an AMF 202, a NWDAF client 203, an SMF 204, a UPF 205, a UDM 206, an NEF 207, and a NWDAF server 208. A UE 209 running an application may be acting as an NF consumer, and a DN may be providing an AF 210 and an application server 211.

[0019] The NWDAF client 203 is a node that has access to regional data and training capabilities. The NWDAF client 203 sends updated model weights to the NWDAF server 208 which is in charge of model aggregation, and sends the aggregated model (‘global model’) back to the NWDAF client 203 of each region. An NWDAF can be client or server or both. If the NWDAF server 208 has no input data, it is not capable of doing inference and will not register for an Analytics ID. The detailed procedure of capability registration is described in 3GPP TS 23.22 section 6.2C.2.1.The training procedure for the architecture of Figure 2 is defined in 3GPP TS 23.288 section 6.2C.2.2. The assumption is that, for horizontal FL, the federation comprises regions of a country (e.g., region A, B, and C in Figure 2), wherein data cannot be moved outside of the region in which it is stored or located (e.g., in a regional datacenter). Within a region, data from different NFs can be collected and stored at regional NWDAFs in the core network (ON) (e.g., similarly to centralized learning). Then, each (ON) NWDAF client 203 trains a model per region, and the model weights obtained at different regional NWDAF clients 203 are sent to the server NWDAF 208 for aggregation.

[0020] For inference to be performed, an analytics request or subscription is sent to an NWDAF client 203, as in 3GPP TS 23.288 section 6.18.4. For a model trained with FL, there is an underlying assumption that data cannot be sent between regions. Therefore, in order to ensure that the analytics request or subscription arrives at the appropriate NWDAF client 203 for handling the analytics request / subscription, optional arguments (as specified in 3GPP TS 23.288 section 6.18.1) may be included in the request / subscription that help the request / subscription end up at the right location (i.e., a suitable NWDAF client). For example, an area of interest (AOI) may be used to restrict the scope of an E2E data volume transfer time analytics request / subscription to focusing on a provided area. As such, the request / subscription may be directed towards an NWDAF client 203 which has access to the relevant input data.

[0021] Therefore, whilst horizontal federated learning can be used to help protect data privacy, ensure data security, avoid the issue of access rights, and avoid the need for the transmission of large data sizes, it requires each client node to train a (local) ML model and utilise said model for performing inference. This consumes a large amount of resources at the client node.

[0022] Summary

[0023] Given the advantages of distributed learning, it is a goal for 3GPP standards to support inference using a distributed ML model. Inference procedures for vertical FL are specified in section 6.2H.2.4 of TS 23.288 V19.1.0, 2024-12 (“TS 23.288”). This section defines two procedures for inference. In the first procedure, an NWDAF is operable to act as a coordinator. In the second procedure, the AF is operable to act as the coordinator. The first procedure has the disadvantage that the NWDAF server needs to perform result aggregation. The second procedure has the disadvantage that the AF needs to perform client selection (as described in the training procedure 6.2H.2.3.1).Furthermore, the procedures defined in section 6.2H.2.4 do not consider the effect that mobility may have on the client selection process.

[0024] Embodiments of the present disclosure address these and other issues by defining procedures and information exchanges between coordinating nodes (also referred to herein as a “coordinator”, “coordinating server”, “coordinator node”, and “coordinator server”), server nodes, and client nodes, which allow the coordinating node and coordinating function to be decoupled from the head and tail nodes, and consequently from data ownership and result aggregation functionality. In other words, embodiments of the present disclosure enable a coordinator to simply coordinate execution of the distributed inference process, whilst result inference and result aggregation is performed in a different tail node (e.g., the AF). This is beneficial for deployments because it avoids the need to provide additional functionality in one or other of the NWDAF (which may otherwise be required to perform result aggregation), or in the tail node AF (which would otherwise need to perform client selection, and may require additional signaling to access the necessary information).

[0025] Furthermore, in embodiments of the present disclosure, methods are disclosed for performing client selection which take mobility aspects into account. This is beneficial, as it ensures that any inference for an analytics request for, e.g., a wireless device, accounts for potential changes in serving nodes for the wireless device (e.g., as a result of mobility procedures, handover, etc).

[0026] In a first aspect, a method is performed by a coordinating node in a communications network, for coordinating execution of one or more ML tasks to be executed by one or more respective client nodes. The one or more ML tasks generate intermediate outputs and comprise first parts of a distributed inference process. A second part of the distributed inference process is executed by a server node and comprises using the intermediate outputs to generate an output of the distributed inference process. The method comprises identifying a first client node of the one or more client nodes by determining that the first client node has access to input data relevant to an analytics request; requesting the first client node to generate at least one intermediate output by executing, using the input data, the respective ML task of the one or more ML tasks; and receiving, from the server node, an output of the distributed inference process.In a second aspect, a method is performed by a first client node in a communications network, the first client node being operable to execute a first ML task. The first ML task generates at least one intermediate output and is a first part of a distributed inference process. A second part of the distributed inference process is executed by a server node and comprises using the at least one intermediate output to generate an output of the distributed inference process. The first client node has access to input data. The method comprises: receiving, from a coordinating node, a request that the first client node generates the at least one intermediate output by executing, using the input data, the first ML task; and transmitting, to the server node, the at least one intermediate output.

[0027] In a third aspect, a method is performed by a server node in a communications network. The server node is operable to execute a second ML task. The second ML task is a second part of a distributed inference process. A first part of a distributed inference process is executed by one or more client nodes, generates at least one intermediate output for the second part of the distributed inference process, and is executed responsive to a request from a coordinating node. The method comprises: receiving, from at least one of the one or more client nodes, the at least one intermediate output; executing the second ML task using the at least one intermediate output to generate an output for the distributed inference process; and transmitting the output to the coordinating node.

[0028] In a fourth aspect, there is provided a coordinating node for a communications network. The coordinating node is for coordinating execution of one or more ML tasks to be executed by one or more respective client nodes. The one or more ML tasks generate intermediate outputs and comprise first parts of a distributed inference process. A second part of the distributed inference process is executed by a server node and comprises using the intermediate outputs to generate an output of the distributed inference process. The coordinating node comprising processing circuitry and a memory, the memory containing instructions executable by the processing circuitry whereby the coordinating node is operable to: identify a first client node of the one or more client nodes by determining that the first client node has access to input data relevant to an analytics request; request the first client node to generate at least one intermediate output by executing, using the input data, the respective ML task of the one or more ML tasks; and receive, from the server node, an output of the distributed inference process.

[0029] In a fifth aspect of the disclosure, there is provided a first client node for a communications network. The first client node is operable to execute a first ML task. The first ML taskgenerates at least one intermediate output and is a first part of a distributed inference process. A second part of the distributed inference process is executed by a server node and comprises using the at least one intermediate output to generate an output of the distributed inference process. The first client node has access to input data. The first client node comprises processing circuitry and a memory, the memory containing instructions executable by the processing circuitry whereby the first client node is operable to: receive, from a coordinating node, a request that the first client node generates the at least one intermediate output by executing, using the input data, the first ML task; and transmit, to the server node, the at least one intermediate output.

[0030] In a sixth aspect, there is provided a server node for a communications network. The server node is operable to execute a second ML task. The second ML task is a second part of a distributed inference process. A first part of a distributed inference process is executed by one or more client nodes, generates at least one intermediate output for the second part of the distributed inference process, and is executed responsive to a request from a coordinating node. The server node comprises processing circuitry and a memory, the memory containing instructions executable by the processing circuitry whereby the server node is operable to: receive, from at least one of the one or more client nodes, the at least one intermediate output; execute the second ML task using the at least one intermediate output to generate an output for the distributed inference process; and transmit the output to the coordinating node.

[0031] In a seventh aspect, 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 a method according to an embodiment of any one of the first aspect, second aspect, and third aspect.

[0032] In an eighth aspect, 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 a method according to an embodiment of any one of the first aspect, second aspect, and third aspect.

[0033] BRIEF DESCRIPTION OF THE DRAWINGS

[0034] For a better understanding of examples of the present disclosure, and to show more clearly how the examples may be carried into effect, reference will now be made, by way of example only, to the following drawings in which:Figure 1 is a schematic diagram of a centralized inference procedure;

[0035] Figure 2 is a schematic diagram of a horizontal federated inference procedure; Figure 3 is a flow chart illustrating a method according to embodiments of the present disclosure;

[0036] Figures 4a and 4b are schematic diagrams illustrating an example ML model used for the distributed inference process;

[0037] Figures 5a and 5b are schematic diagrams illustrating architecture for performing a distributed inference procedure according to embodiments of the present disclosure; Figure 6 is a flow chart illustrating the method of Figure 3 in further detail;

[0038] Figure 7 is a flow chart illustrating the methods of Figures 3 and 6 in further detail; Figures 8a is a signalling flow for an inference procedure according to embodiments of the present disclosure;

[0039] Figures 8b is a signalling flow for an inference procedure according to embodiments of the present disclosure, wherein the inference procedure comprises mobility handling;

[0040] Figures 9-11 are flow charts illustrating methods according to embodiments of the present disclosure;

[0041] Figure 12 illustrates a coordinating node according to embodiments of the present disclosure;

[0042] Figure 13 illustrates a client node according to embodiments of the present disclosure; and

[0043] Figure 14 illustrates a server node according to embodiments of the present disclosure.

[0044] DETAILED DESCRIPTION

[0045] 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 toany other embodiments, and vice versa. Other objectives, features and advantages of the enclosed embodimentswill be apparent from the following description

[0046] 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.

[0047] 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.

[0048] 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.

[0049] For the purposes of the present disclosure, the term “ML model” encompasses within its scope the following concepts: ML 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 architecturethat performs the task; and the process performed by the model artefact in orderto complete the task.

[0050] For the purposes of the present disclosure, the term “ML task” may refer to one or more parts of the ML algorithm (discussed above) that are executed by (a part of) an ML model. Examples of ML tasks include forward propagation, back propagation, result aggregation, activation function execution, gradient function execution, model training, model optimisation, etc.

[0051] For the purposes of the present disclosure, a “head node” (also referred to herein as a client node) is a node which executes an ML task (e.g., forward propagation) comprising a first part of a distributed inference process, and outputs intermediate results (e.g., activations) for a second part of the distributed inference process executed at a tail node. Head nodes are operable to output one or more intermediate results to one or more of the tail nodes. For example, an ML model may be distributed over multiple head nodes, each having different feature spaces and access to the same sample data, which output their intermediate results to a single tail node, which concatenates the intermediate results into an input for the part of the ML model hosted by the tail node. For this function, head nodes may directly store, or otherwise have access to, data needed to perform the relevant ML task of the first part of the distributed inference process.

[0052] It should be appreciated that, where an output of a head node is described in embodiments of the disclosure as being an “activation”, such outputs could additionally or alternatively be described as “intermediate outputs”, “intermediate results”, “intermediate variables”, etc. That is, an activation is an example of an intermediate output, particularly from a head node. However, the skilled person would understand that embodiments of the disclosure could also be implemented for other examples of intermediate outputs.

[0053] For the purposes of the present disclosure, a “tail node” (which may be referred to herein as a server node) is a node which executes an ML task (e.g., result aggregation) comprising a second part of the distributed inference process. The second part of the distributed inference process comprises using the intermediate results to generate an output of the distributed inference process. For this function, tail nodes may directly store, or otherwise have access to, data needed to perform the ML task of the second part of the distributed inference process.For the purposes of the present disclosure, the term “analytics request” may refer to any request, subscription, and / or message that requests performance of one or more analytics services. The analytics service may be any service defined in TS 23.288, which is incorporated herein by reference in its entirety. For example, the analytics request may be a request for an analytics service associated with any one or more of: traffic; mobility; location; performance; load for one or more nodes; devices; network parts; and network slices. In particular, the analytics request may be for any one or more of: a duration of data transfer to or from a fourth node (e.g., a prediction of an End-to-End (E2E) data volume transfer time), wherein the fourth node is a wireless device or a base station; slice load level related network data analytics for a network slice; an observed service experience related network data analytics for a fourth node, wherein the fourth node is a wireless device or base station (e.g., to obtain a prediction or estimation of Quality of Experience (QoE) metric(s) observed at UE(s)); Network Function (NF) load analytics for a fourth node, wherein the fourth node comprises a NF; network performance analytics for a network and / or a network slice; UE-related analytics for a fourth node, wherein the fourth node is a wireless device; user data congestion analytics for a fourth node, wherein the fourth node is a wireless device or base station; Quality of Service (QoS) sustainability analytics for a network, network slice, and / or a fourth node, wherein the fourth node is a wireless device or base station; dispersion analytics for a fourth node, wherein the fourth node is a wireless device; Wireless Local Area Network (WLAN) performance analytics for WLAN; session management congestion control experience analytics for a network; redundant transmission experience related analytics for a fourth node, wherein the fourth node is a wireless device or base station; data network performance analytics for a network; Packet Flow Description (PFD) determination analytics for a network; location accuracy analytics for a fourth node, wherein the fourth node is a wireless device or base station; Protocol Data Unit (PDU) session traffic analytics for a network; relative proximity analytics for a fourth node, wherein the fourth node is a wireless device or base station; movement behaviour analytics for a fourth node, wherein the fourth node is a wireless device; signalling storm analytics, wherein the fourth node is a wireless device or base station; and QoS and policy assistance analytics for a network.

[0054] In one example use case, distributed inference may be used to enable the provision of E2E data volume transfer time analytics (e.g., by NWDAFs) in the form of statistics or predictions, as per section 6.18 of 3GPP TS 23.288 V18.6.0. The E2E data volume transfer time refers to a time delay for completing the transmission of a specific data volume from a User Equipment (UE) to an Application Function (AF), or from an AF to a UE. This maynecessitate input from various network functions (e.g., AMFs, SMFs, gNBs) in order to predict the data volume transfer time.

[0055] By enabling good predications for E2E data volume transfer time analytics, a user of the analytics service is enabled to perform better planning for data transfer between UEs (also referred to herein as “wireless devices”) and other nodes or destinations (e.g., uploading large sized recorded videos to a social media platform, or uploading large files to OneDrive). 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 datasets. In another example, a streaming-video application may use the predictions of the E2E data volume transfer time to better estimate an expected throughput for the duration of a video. This would avoid switching encoding quality up and down as the throughput fluctuates, which is known to degrade end-user experience. Instead, the video application could choose an encoding quality which has a high likelihood of being maintained for the duration of the data transfer. The E2E data volume transfer time predictions can also be used to instruct a Policy Control Function (PCF) to allocate a higher priority for a given data transfer if the prediction is not what is desired.

[0056] E2E data volume transfer time predications can also be used for federated learning. UEs can use the predicted transfer time to determine a selection of the participants in a federated learning training session from (or to) which model parameters are to be transferred (or not transferred). For example, if a server predicts a high latency in the transfer of model parameters from (or to) certain client nodes, it can deselect those client nodes for a federation training round to speed up the training process.

[0057] In order to predict the data volume transfer times, an NWDAF (or other suitable network nodes) may utilise data from network functions such as: access and mobility management entities (e.g., AMFs); session management entities (e.g., SMFs), those acting as a frontend for a user plane entity (e.g., a UPF); gNBs; and AFs (e.g., via network exposure entities (e.g., NEFs).

[0058] The skilled person will understand that E2E data volume transfer time is merely one example use case for the methods disclosed herein, and whilst embodiments of the present disclosure may be described with reference to E2E data volume transfer time analytics, such embodiments are not limited thereto and may additionally or alternatively be used to implement other examples of distributed inference.Some embodiments of the present disclosure are directed to actions at a coordinating node, wherein the coordinating node is a separate logical entity to the server node and client nodes of a distributed inference process. The coordinating node selects appropriate client nodes for executing ML tasks of a first part of the distributed inference process in order to respond to an analytics request. The coordinating node receives an output of a second part of the distributed inference process from the server node, which may enable the coordinating node to respond to the analytics request. These embodiments have the advantage of decoupling the coordination aspects of a distributed inference process from the server node that executes a second part of the distributed inference process.

[0059] Figure 3 illustrates a method performed by a coordinating node in a communications network, wherein the coordinating node is for coordinating execution of one or more ML tasks to be executed by one or more respective client nodes. The one or more ML tasks generate activations, i.e., intermediate outputs, and comprise first parts of a distributed inference process. A second part of the distributed inference process is executed by a server node and comprises using the activations to generate an output of the distributed inference process. The coordinating node is de-coupled from the server node. For example, the coordinating node and server node may be implemented by, hosted at, and / or located at distinct logical entities.

[0060] The method of Figure 3 may be performed by a core network node of the communication network, and 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.

[0061] An example of the distributed inference process that may be coordinated via the method of Figure 3 is a split inference process, which may be an implementation of vertical federated learning, and is discussed below with reference to Figures 4a and 4b.

[0062] For example, taking the use case of E2E data volume transfer time analytics, the distributed inference process may utilise a Neural Network (NN) model that is split between participating network functions and an AF. The NN model may be a single, trained distributed global model that does not require the input data to be available in a centralized NWDAF. Furthermore, sharing of the NN model between the participating network functions (e.g., NWDAF clients) is also not needed.The distributed inference process may utilise parallel split learning (which is a variant of vertical federated learning). Parallel split learning has several advantages. First, raw data does not need to be transferred to a centralized NWDAF. Instead, aggregated and transformed representation data in the form of activations and gradients are sent between parts of a distributed model. A second advantage is that input features to a part of the model do not need to be known by other parts of the model. This implies that a gNB vendor may use vendor-specific input features (e.g., for training or inference) at a part of the model executed by its gNBs, which improve the overall importance. These input features can be kept private from other vendors who use other parts of the distributed model.

[0063] Figure 4a is a schematic diagram of an ML model for split inference. This figure shows an ML model that is split between head nodes 402, 404, 406 and tail nodes 408. One or more of the head nodes 402, 404, 406 may function as the one or more client nodes of the method of Figure 3, and one or more of the tail nodes 408 may function as the server node of the method of Figure 3. The head nodes 402, 404, 406 are in a single layer, and each head node is communicatively coupled to each tail node.

[0064] In the example of Figure 4a, the head nodes comprise CN NFs (which may also be referred to herein as “CN elements”), e.g., AMFs and SMFs, and RAN NFs (which may also be referred to herein as “RAN elements”), e.g., gNBs. The head nodes comprise first head nodes 402, second head nodes 404, and third head nodes 406. The first head nodes 402 have access to data stored and / or located at a gNB. The second head 404 nodes have access to data stored and / or located at an AMF. The third head 406 nodes have access to data stored and / or located at an SMF.

[0065] In the example of Figure 4a, the tail nodes 408 are AFs, as the AF comprises the labels needed fortraining of the ML model, and / or input data for the second part of the distributed ML model. Whilst Figure 4a illustrates the ML model comprising multiple tail nodes, it should be appreciated that the ML model is not limited thereto.

[0066] The ML model is trained such that execution of the second part of the distributed inference, using the activations generated by the head nodes, outputs information for responding to an analytics request which can be made available for consumption by a consumer. Training of the ML model may be performed in accordance with known methods, and are outside the scope of the present disclosure.Figure 4b illustrates an alternative configuration of the head nodes 402, 404, 406 and tail nodes 408 of the ML model of Figure 4a. In this alternative configuration, rather than being in a single layer, the head nodes 402, 404, 406 reside in multiple layers. In particular, a first layer comprises the second head nodes 404 and third head nodes 406, and each of the head nodes in the first layer are communicatively coupled with each of the tail nodes 408. A second layer comprises the first head nodes 402, and each of the first head nodes 402 are communicatively coupled with each of the tail nodes 408 via one of the second head nodes 404 (i.e., a second head node acts as an intermediate node or relay node for a first head node).

[0067] The schematic diagrams of Figures 4a and 4b further illustrate a coordinating node 410 in the form of a Distributed Model Coordination Function (DMCF), or coordinator, which is operable to coordinate execution of the first and second parts of the distributed inference process in accordance with the method of Figure 3 (as discussed in detail below).

[0068] Returning now to Figure 3, at step 302 of the method 300, the coordinating node identifies a first client node of the one or more client nodes by determining that the first client node has access to input data relevant to an analytics request. For example, the data may be stored and / or located at one or more second network nodes with which the first client node is communicatively coupled, as discussed in more detail with reference to Figure 6. That is, the one or more second network nodes may be considered to be holders of the input data for responding to the analytics request. The one or more second network nodes may be any network node (e.g., NF or AF) specified in TS 23.288 as holding input data for responding to the analytics request. For example, the one or more second network nodes may comprise any one or more of an AMF, an MME, an SMF, an eNB, a gNB, a Network Slice Selection Function (NSSF), a Network Repository Function (NRF), and an Analytics Data Repository Function (ADRF).

[0069] At step 304, the method comprises requesting the first client node to generate at least one activation by executing, using the input data, the respective ML task of the one or more ML tasks. This requesting step may implicitly or explicitly instruct the first client node to transmit, to the server node, the least one activation. For example, the first client node may have been configured during a training phase of the ML tasks to transmit its activations, once generated, to a particular server node during inference, without requiring an explicit instruction to do so.In one example, requesting the first client node to generate the at least one activation may comprise transmitting, to the first client node, a first message comprising a request that the first client node generates the at least one activation. In such embodiments, the first message may further include an identifier of the analytics request for inclusion in one or more second messages transmitted, by the first client node, to the server node, the one or more second messages comprising the at least one activation.

[0070] In other examples, the first client node may be configured to interpret the request to generate the at least one activation as being an implicit instruction that the first client node is to transmit, to the server node, the least one activation.

[0071] At step 306, the method comprises receiving, from the server node, an output of the distributed inference process. As discussed with reference to Figures 4a and 4b, the output of the distributed inference process may comprise information for responding to the analytics request.

[0072] To illustrate an example implementation of the method of Figure 3, Figure 5a shows a schematic diagram of architecture comprising a coordinating node 501 operable to act in accordance with embodiments of the present disclosure. For example, the coordinating node 501 may be operable to perform a method according to embodiments of Figures 3, 6, 7, 8a, and 8b. In the example of Figure 5a, an NWDAF (also referred to herein as an NWDAF instance) is communicatively coupled with (e.g., by comprising, hosting, and / or acting as) the coordinating node 501, illustrated in the Figures as the DMCF coordinator. However, it should be appreciated that the coordinating node 501 is not limited thereto, and any suitable core network node may comprise, host, and / or act as the coordinating node 501.

[0073] Furthermore it will be appreciated that, whilst in the architecture of Figure 5a, the NWDAF with which the coordinating node 501 is communicatively coupled (e.g., by being co-located with or in close proximity to) is not involved in training or inference, the coordinating node 501 may instead be associated with an NWDAF that is involved with training and / or inference of the distributed inference process. Alternatively, the coordinating node 501 may be placed in the OAM, and thus not associated with any NWDAF instance.The architecture of Figure 5a further comprises RAN NFs and CN NFs. In particular, the architecture includes a gNB 502, an AMF 503, an SMF 504, a UPF 505, a UDM 506, a NRF 507, and a NEF 508. One or more of the NFs illustrated in Figure 5a may correspond to the architecture defined for the use case of E2E data volume transfer time analytics in TS 23.288.

[0074] The architecture of Figure 5a further comprises a mobile device 509. The mobile device 509 comprises a UE and runs an application. The mobile device 509 may be acting as an NF consumer. For example, the analytics request discussed in relation to Figure 3 may originate at the mobile device 509. However, it should be appreciated that in other embodiments of the disclosure, the NF consumer may be a base station or another network node that consumes analytics services.

[0075] The NFs (e.g., the gNB 502, AMF 503, and SMF 504) are associated with respective NWDAFs for performing training and inference based on data stored and / or located at the NFs. In other words, the NWDAFs may be operable to act as, or comprise, the one or more client nodes referred to in the method of Figure 3. For example, each NWDAF may have Model Training Logical Function (MTLF) capability, Analytics Logical Function (AnLF) capability, or both in order to perform training and / or inference.

[0076] In orderto perform the method of Figure 3 (e.g., to facilitate execution of the first part of the distributed inference process at (NWDAF clients associated with) the NFs of Figure 5a), data stored and / or located at respective NFs may be accessible to their associated NWDAFs. For example, data stored and / or located at the gNB 502 may be accessible to an NWDAF associated with the gNB 502, data stored and / or located at the AMF 503 may be accessible to an NWDAF associated with the AMF 503, and data stored and / or located at the SMF 504 may be accessible to an NWDAF associated with the SMF 504.

[0077] Such access may be realised by having the NWDAFs be communicatively coupled to the associated NFs by being, for example, deployed in close proximity to the NF or co-located (e.g, in the same product or logical entity) with the NF. Interfaces between the NWDAFs and NFs (defined by 3GPP) may be used to enable the NWDAFs to access (i.e., collect) the data stored at the NFs.

[0078] To facilitate this data collection, the NWDAFs associated with RAN NFs may utilise Analytics Data Repository Functions (ADRFs). These ADRFs may be located in closeproximity to the NWDAFs associated with RAN NFs. In this way, such NWDAFs may be “lowered” to operate in the respective RAN elements. For example, the gNB 502 may be operable to collect and store data using well defined processes, and the associated NWDAF AnLF may be used to access or collect said data when performing training or inference. This avoids the introduction of further interfaces to the 3GPP specifications.

[0079] The distributed NWDAF instances interact to realize training and inference (i.e., by acting as, or utilising, client nodes and / or head nodes). For example, the NWDAF associated with the gNB 502 may be visible in the CN, and the Service Base Interface (SBI) may be extended to encompass the gNB 502 such that the gNB 502 can communicate with the NFs of the CN and other entities via the SBI and the NWDAF interfaces.

[0080] The training of the NWDAF instances is not discussed herein but may be performed according to known methods. The NWDAFs may perform inference by executing ML tasks, which comprise a first part of a distributed inference process. The executed ML tasks generate activations for the second part of the distributed inference process. For example, the NWDAFs may each support a first part of the distributed inference process for one or more of the analytics services defined in 3GPP specifications (e.g., E2E data volume transfer time analytics services).

[0081] More information regarding the NWDAF instances can be found in 3GPP TS 23.288 section 5.1, which describes how different NWDAF instances may be present in the 5GC, with possible specializations per type of analytics, and states that the capabilities of a NWDAF instance are described in the NWDAF profile stored in the NRF 507.

[0082] The architecture of Figure 5a also comprises a DN hosting a server which provides an AF 510 (comprising a tail node) and an Application Server 511. The AF 510 and / or the tail node may correspond to the tail nodes of Figures 4a and 4b. As illustrated in Figure 5a, the AF 510 (in particular, the tail node) receives activations from each of the NWDAFs associated with the NFs (i.e., the head nodes). The AF 510 (in particular, the tail node) performs inference for the second part of the distributed inference process by executing one or more ML tasks utilising the activations received from the tail nodes. Execution of the one or more ML tasks generates an output of the distributed inference process. For example, the AF 510 may support a second part of a distributed inference process for one or more of the analytics services defined in 3GPP specifications (e.g., E2E data volume transfer time analytics services).Figure 5b shows a schematic diagram of a variation of the architecture illustrated in Figure 5a. In particular, rather than having the NWDAF associated with the gNB 502 send activations to the AF 510 directly, the NWDAF associated with the AMF 503 acts as a proxy (or an intermediate node) between the NWDAF associated with the gNB 502 and the AF (e.g., as per the ML model in Figure 4b). As such, in embodiments of Figure 5b, it may be that no NWDAFs are associated with the gNBs 502. That is, as illustrated in Figure 5b, the NWDAF associated with the AMF 503 acts as a proxy for the gNB 502 by receiving, from the head node of the gNB 502, its activations. For example, the NWDAF associated with the AMF 503 may collect the activations from the gNB 502 via the Operations, Administration and Maintenance (OAM) (as shown in Figure 5b) or via extensions to the gNB-AMF (N2) interface.

[0083] Sending activations via the OAM may function in a similar manner to the way current 3GPP specifications define the collection of data via the OAM. However, in contrast to these current specifications, signalling between the NWDAF associated with the AMF 503 and the gNB 502 of Figure 5b, via the OAM, occurs bi-directionally. In other words, the OAM may receive activations from the gNB 502 and forward the activations to (the NWDAF associated with) the AMF 503, and it may also receive gradients from (the NWDAF associated with) the AMF 503 and forward the gradients to the gNB 502.

[0084] Whilst embodiments of the present disclosure may be discussed with reference to the architecture of Figure 5a, it should be appreciated that the architecture of Figure 5b may also be used to implement embodiments of the present disclosure. The former may be preferred, as it results in a lesser load being placed on the OAM, which can be undesirable as it may require increasing the dimensioning of the underlying software and hardware which supports this function.

[0085] In the architecture of Figures 5a and 5b, the client nodes may interact with each other and the server node via the standard interfaces for NWDAFs. As such, the client nodes may interact according to known standards. This is desirable, as it does not require new interfaces to be designed, standardized, and implemented for distributed inference. However, it should be appreciated that the architecture of Figures 5a and 5b may be implemented without the use of NWDAFs. That is, in some embodiments, the client nodes in the different NFs may communicate directly with each other, without the use of NWDAFs, via interfaces that have yet to be designed, standardized, and implemented.Figure 6 illustrates a flow chart that expands upon the method disclosed in Figure 3. For example, Figure 6 illustrates (step 602) that the coordinating node may further determine (e.g., prior to step 302 of Figure 3) that, based on the analytics request, the input data is relevant to the analytics request by determining at least one type of input data for responding to the analytics request. The at least one type may indicate that the data is located and / or stored at a RAN NF and / or a CN NF (e.g., the RAN NFs and / or CN NFs of Figure 5a). For example, the at least one type may comprise any one or more of: AMF data (i.e., data stored and / or located at an AMF 503); SMF data (i.e., data stored and / or located at an SMF 504); and gNB data (i.e., data stored and / or located at a gNB 502), etc.

[0086] Figure 6 also illustrates that the method of Figure 3 may further comprise the coordinating node identifying (at step 604) one or more second network nodes at which input data of the at least one type is stored and / or located. For example, the one or more second network nodes may comprise any one or more of: an analytics and mobility network entity (e.g., an AMF), a session management entity (e.g., an SMF), and a base station (e.g., a gNB). Additionally or alternatively, the one or more second network nodes may serve a fourth node (e.g., a wireless device or a base station) to which the analytics request relates and / or for which the analytics service is requested.

[0087] Step 604 may be facilitated by configuring (or otherwise providing) the coordinating node with a mapping between analytics IDs and the type of data needed for responding to the corresponding analytics request (e.g., a mapping between the analytics IDs and core network nodes or entities that store the type of data needed).

[0088] For example, step 604 may involve the coordinating node querying (at step 606) a network entity in a core network of the communications network, such as an analytics and mobility network entity (e.g., an AMF) and / or a unified data management entity (e.g., a UDM). In embodiments in which the analytics request relates to a network slice, the queried network entity may be a NSSF. In other embodiments, the queried network entity may be an NRF or other entity. Further details regarding such queries are provided with reference to steps 808-810 of Figures 8a and 8b. As a result of the queries, the coordinating node may receive, from the network entity, an indication of the identities of the one or more second network nodes (e.g., an AMF, SMF, and / or gNB serving the fourth node).As illustrated by step 608, the coordinating node may then determine that the first client node has access to the input data relevant to the analytics request by determining that the first client node has access to data stored and / or located at the one or more second network nodes (e.g., the AMF 502, SMF 504, and gNB 502 of Figures 5a and 5b). For example, the coordinating node may determine that the one or more second nodes are capable of provisioning data to the first client node and / or that the first client node is deployed in close proximity to, co-located with, or communicatively coupled with the one or more second network nodes.

[0089] In some embodiments, the analytics request may be time-dependent in that it may identify a time period during which the analytics service is requested. For example, if the analytics request is for E2E data volume transfer time analytics, the time period may indicate a time at which the data is to be transferred.

[0090] However, in embodiments in which the analytics request further identifies a wireless device for which an analytics service is requested, the one or more second network nodes serving the wireless device during the time period may change (e.g., due to mobility procedures performed for the wireless device). Furthermore, it may be that no second network node is serving the wireless device when the coordinating node receives the analytics request (e.g., if the wireless device is in an idle state).

[0091] To overcome these and other issues, step 604 of Figure 6 may further comprise determining (at step 610) that the one or more second network nodes are predicted to serve a wireless device (identified by the analytics request) during a time period (identified by the analytics request) for which an analytics service is requested. For example, this identifying step may comprise the coordinating node requesting, from a CN NF (e.g., an NWDAF, AMF, MME, etc.), an indication of any one or more of: a trajectory prediction of the wireless device; and a predicted mobility procedure for the wireless device (e.g., a target node towards which the wireless is expected to be handed over). Further details regarding step 610 are discussed later in the present disclosure with reference to step 810a-810c of Figure 8b.

[0092] Figure 7 illustrates a flow chart that further expands upon the methods of Figures 3 and Figure 6. As illustrated by step 702, prior to performance of the method steps of Figure 3 and, optionally, Figure 6, the coordinating node may receive the analytics request from a third node. The third node may be a consumer (i.e. the originator of the analytics request), such as a wireless device or base station, or it may be a client node (e.g., any one of theNWDAFs in Figure 5a) that has registered itself and consequently receives the analytics request from the consumer and forwards the request to the coordinating node.

[0093] In step 704, during performance of the steps of Figure 3 and, optionally, Figure 6, the coordinating node may indicate to the server node that the server node is to receive the at least one activation from the first client node. This step may be performed in order to prepare and / or warn the server node of the likely arrival of the at least one activation. Additionally or alternatively, step 704 may comprise the coordinating node requesting the server node (implicitly or explicitly) to execute the second part using the at least one activation to generate the output for the distributed inference process. This request may optionally request (implicitly or explicitly) that the server node uses data accessible to the server node for executing the second part of the distributed inference process (e.g., data stored at an AF). Step 704 may occur before or after step 304, and before step 306.

[0094] The third node may, in some examples, be the same logical entity (i.e., same node) as the fourth node (i.e., the node from which the analytics request is received / for which the analytics service is requested). For example, the analytics request could relate to the wireless device from which the analytics request is received by the coordinating node.

[0095] At step 706, after performance of the method steps of Figure 3 and, optionally, Figure 6, the coordinating node may transmit, to the third node, a response to the analytics request. The response may be based on, and / or may comprise, the output of the distributed inference process. For example, if the analytics request is for an E2E data volume transfer time, the output of the second part of the distributed inference process may provide a prediction and / or estimation of the E2E data volume transfer time, which may be included in the response.

[0096] Figure 8a is a signalling flow for a distributed inference procedure according to embodiments of the present disclosure. The distributed inference procedure may be an extension of the existing procedure in section 6.18.4 of 3GPP TS 23.288.

[0097] The signalling flow involves a consumer, a gNB, an NWDAF client that has access to data stored and / or located at the gNB (referred to as the “NWDAF for gNB data”), an AMF, an NWDAF client that has access to data stored and / or located at the AMF (referred to as “the NWDAF for AMF data”), an SMF, an NWDAF client that has access to data stored and / or located at the SMF (referred to as “the NWDAF for SMF data”), an NWDAF coordinator(which may be referred to as the NWDAF server, not to be confused with the AF (i.e., the tail node, also referred to as a server node)), an NRF, an NEF, and an AF.

[0098] The NWDAF coordinator comprises and / or acts as the coordinating node discussed in relation to Figures 3-7, performing examples of the methods discussed above. The NWDAF for gNB data, the NWDAF for AMF data, and the NWDAF for SMF data comprise and / or act as the client nodes discussed in relation to Figures 3-7.

[0099] The AF is the tail node, and thus comprises the labels for prior training of the distributed inference procedure, and may comprise input for the second part of the distributed inference procedure. The AF comprises and / or acts as the server node discussed in relation to Figures 3-7.

[0100] In step 801, training and deployment of the different parts of the split model is performed.

[0101] In step 802, the consumer queries the NRF to find an NWDAF supporting a given analytics ID, such that the consumer can send an analytics request to an NWDAF that supports distributed inference for the analytics service identified by the analytics ID. This step may be performed according to existing procedures in 3GPP TS 23.501 section 6.3.13.

[0102] In step 803, the consumer receives a reply to the query. The reply comprises an NWDAF address.

[0103] In step 804, the consumer transmits the request to the NWDAF address received in step 3. This step may correspond to step 702. The request may comprise any one or more of: an analytics ID (e.g., “E2E data volume transfer time”); a UE identifier (e.g., a SUPI); an AF ID; a DNN; and an S-NSSAI. In embodiments in which the distributed inference process is used for predicting E2E data volume transfer times, the request may further comprise a parameter indicating any one or more of: identities of the UE and NF between which the data transfer will take place; a volume of (e.g., DL and / or UL) data to be transferred; and a time at which the transmission of data will take place (e.g., time of day).

[0104] If the NWDAF coordinator is registered at the NRF as supporting the given analytics ID, the reply may comprise an address of the NWDAF coordinator, and the request may be sent to the NWDAF coordinator using the NWDAF coordinator address.Alternatively, if an NWDAF that is not the NWDAF coordinator (e.g., one of the NWDAF clients) is registered at the NRF as supporting the given analytics ID, the reply received in step 803 may comprise an address of the NWDAF client. In this case, instead of performing step 804, the consumer performs step sequence 805 (which may also correspond to step 702), which comprises sending, in step 806, the request to the NWDAF client using the NWDAF client address. Since the NWDAF client cannot handle the request alone, the step sequence 805 further comprises the NWDAF client forwarding, in step 807, the request to the NWDAF coordinator using the NWDAF coordinator address. Each NWDAF client may have been made aware of the NWDAF coordinator address during the deployment of the ML model parts to the NWDAF clients (e.g., in step 801).

[0105] As a result of step 804 (or, alternatively, step sequence 805), the request ends up at the NWDAF coordinator together with parameters for the request.

[0106] For example, if the request identifies a node (e.g., a UE or base station) for which the request is to be performed, the NWDAF coordinator may discover which AMF and / or SMF serves this node. This step may be performed responsive to step 602 and / or as part of step 604 and / or 606. This discovery step may be performed according to the existing procedure defined in section 6.2.7 of 3GPP TS 23.501. For example, the NWDAF coordinator may send, to the UDM, a query comprising a UE ID. In response, the UDM may return an indication of the serving AMF and / or the serving SMF to the NWDAF server.

[0107] In steps 809 and 810, the AMF may be queried to find the gNB and / or SMF serving the node. This step may also comprise part of step 604 and / or 606.

[0108] Steps 808-810 may utilise additional query filters, such as DNN and S-NSSAI, if relevant.

[0109] Once the AMF, gNB, and / or SMF are known, the NWDAF coordinator finds the NWDAF clients that have access to the data stored or located at these nodes. This step is not shown in the figure, but may be performed through NRF queries. This step may correspond to step 302 and / or step 608.

[0110] In step 811 , the NWDAF coordinator informs the AF that is to receive activations from the NWDAF clients. This step may correspond to step 704. For example, this step may comprise the NWDAF coordinator forwarding the analytics request to the AF.In step sequences 812, 815, and 818, the NWDAF coordinator instructs the gNB, AMF, and SMF to provide input to the AF, for the second part of the distributed inference process. These step sequences may be performed as part of step 304 and / or step 902 of Figure 9 (discussed in more detail below). In other words, the NWDAF coordinator transmits, to the NWDAF clients, indications that the NWDAF clients are to transmit activations to the AF. This step may occur once it is concluded that all required NWDAF clients are ready to serve an inference request.

[0111] For step sequences 812, 815, and 818, one or more of the NWDAF clients may need to acquire data from the node to which they have access (e.g., the gNB, SMF, or AMF). For all these exchanges, the NWDAF coordinator may provide a unique request ID, such that the AF receiving the activations can correlate the activations coming from the different NWDAF clients.

[0112] In one example, step sequence 812 is performed to enable the AF to receive activations for the second part of the distributed inference process obtained using gNB data. Step sequence 812 comprises step 813, in which the NWDAF coordinator transmits, to the NWDAF client for gNB data, an indication that the NWDAF client for gNB data is to provide an activation for the request to the AF. The NWDAF client for gNB data exchanges messages with the gNB in orderto obtain the necessary data for determining the activations. The NWDAF client for gNB data then executes its ML task to obtain the activations (i.e., performs the first part of the distributed inference process). In step 814, the NWDAF client for gNB data transmits the activations to the AF via the NEF. This step may correspond to step 904 of Figure 9 and / or step 1002 of Figure 10 (which are both discussed in more detail below).

[0113] Similarly, step sequence 815 is performed to enable the AF to receive activations for the second part of the distributed inference process obtained using AMF data. Step sequence 815 comprises step 816, in which the NWDAF coordinator transmits, to the NWDAF client for AMF data, an indication that the NWDAF client for AMF data is to provide an activation for the request to the AF. The NWDAF client for AMF data exchanges messages with the AMF in order to obtain the necessary data for determining the activations. The NWDAF client for AMF data then executes its ML task to obtain the activations (i.e., performs the first part of the distributed inference process). In step 817, the NWDAF client for AMF data transmits the activations to the AF via the NEF. This step may correspond to step 904 of Figure 9 and / or step 1002 of Figure 10 (which are both discussed in more detail below).Similarly, step sequence 818 is performed to enable the AF to receive activations for the second part of the distributed inference process obtained using SMF data. Step sequence 818 comprises step 819, in which the NWDAF coordinator transmits, to the NWDAF client for SMF data, an indication that the NWDAF client for SMF data is to provide an activation for the request to the AF. The NWDAF client for SMF data exchanges messages with the SMF in order to obtain the necessary data for determining the activations. The NWDAF client for SMF data then executes its ML task to obtain the activations (i.e., performs the first part of the distributed inference process). In step 820, the NWDAF client for SMF data transmits the activations to the AF via the NEF. This step may correspond to step 904 of Figure 9 and / or step 1002 of Figure 10 (which are both discussed in more detail below).

[0114] In step 821, the AF executes the ML task for the second part of the distributed inference process using the received activations. This step may correspond to step 1004 of Figure 10, discussed in more detail below. Executing the ML task for the second part of the distributed learning process may comprise the AF using its own input data / data it has access to for executing the second part of the distributed ML model (in addition to using the activations) to generate the output of the distributed learning process (e.g., in response to a request received from the coordinating node and / or the first client node).

[0115] As a result, the AF obtains one or more labels for the analytics request. In step 822, the label is sent to the NWDAF coordinator (e.g., in a step corresponding to step 306 and / or step 1006 of Figure 10, discussed in more detail below) via the NEF, which forwards the label to the consumer in step 823 (e.g., in a step corresponding to step 706). Whilst not shown in the figure, the label may be transmitted via an NWDAF client, if the analytics request arrived at the NWDAF coordinator from that NWDAF client in step sequence 805.

[0116] As discussed with reference to step 610 of Figure 6, it may not be correct to assume that the one or more second network nodes serving a UE indicated in the analytics request do not change during a time period (indicated in the analytics request) for which an analytics service is requested. For example, the analytics request may indicate a time period at which data is to be transferred. That is, the analytics request may indicate a transfer starting in, e.g., 10 minutes from a reference time. During this time period, the UE may be handed over to one or more other gNBs (and possibly even another SMF and AMF).In these and other cases, it would be beneficial to take the mobility and / or status of the UE into account when performing distributed inference for the UE.

[0117] Figure 8b illustrates a variation of the signalling flow of Figure 8a, wherein UE mobility and UE status are taken into account. In particular, Figure 8b illustrates additional steps that may be included in the signalling flow of Figure 8a. For simplicity, Figure 8b only shows parts of the signalling flow, steps 808 to 810 with the additional steps for supporting mobility. For steps 801 to 807 and 811 to 823 please see Figure 8a and corresponding text.

[0118] In Figure 8b, at step 809a, the AMF is triggered to perform a paging request. This step may be useful in scenarios in which the UE is in an idle state when the NWDAF coordinator receives the analytics request.

[0119] Additionally or alternatively, Figure 8b illustrates that the signalling flow in Figure 8a may be adapted such that, when the NWDAF coordinator receives the analytics request, it performs a step corresponding to step 610 discussed above. For example, at step 810a, the NWDAF coordinator is illustrated as requesting a predicted trajectory of the UE from an NWDAF (e.g., an NWDAF support a service such as “UE mobility analytics” (see 3GPP TS 23.288, section 6.7.2)) for a time period of the requested data transfer. Once the NWDAF coordinator receives, at step 810b, the predicted trajectory, the NWDAF coordinator can map the predicted trajectory to nodes and NFs (e.g., gNBs, SMFs, AMFs) in the communication network. The NWDAF may determine (e.g., a list of) nodes or NFs that the UE will likely visit for a certain period of time. In this way, at step 810c, the NWDAF can deduce predicted nodes and NFs in the communication network that will serve the UE during the requested data transfer time. In other words, the predicted nodes / entities deduced in step 810c are the nodes / entities that are instructed to provide input data to their associated NWDAFs (or from which the associated NWDAFs collect input data) during step sequences 812, 815 and 818 (i.e., they correspond to the one or more second network nodes discussed above).

[0120] Figure 9 is a flow chart for a method according to embodiments of the present disclosure. The method is performed by a first client node in a communications network. The first client node may be any of the client nodes discussed in relation to Figures 3-8b.

[0121] The method of Figure 9 may be performed by a core network node of the communication network, and may comprise a physical or virtual node, and may be implemented in acomputing device or server apparatus and / or in a virtualized environment, for example in a cloud, edge cloud or fog deployment.

[0122] The first client node is operable to execute a first ML task, wherein the first ML task generates at least one activation, and is a first part of a distributed inference process. A second part of the distributed inference process is executed by a server node and comprises using the at least one activation to generate an output of the distributed inference process. The first client node has access to input data (e.g., stored at the one or more second network nodes as discussed above).

[0123] The method begins at step 902, with the first client node receiving, from a coordinating node, a request that the first client node generates the at least one activation by executing, using the input data, the first ML task. This step may correspond to step 304 of Figure 3. The request may implicitly or explicitly instruct the first client node to transmit, to the server node, the least one activation.

[0124] For example, the request may be included in a first message. Additionally, the first message may further include an identifier of the analytics request for inclusion in one or more second messages transmitted, by the first client node, to the server node which comprises the at least one activation.

[0125] In other embodiments, the first client node may be configured to interpret the request as being an implicit instruction that the first client node is to transmit, to the server node, the at least one activation.

[0126] At step 904, the first client node transmits, to the server node, the at least one activation (e.g., in one or more second messages). The one or more second messages may further include the identifier.

[0127] Figure 10 is a flow chart for a method according to embodiment of the present disclosure. The method is performed by a server node in a communications network. The server node may be any of the server nodes discussed in relation to Figures 3-8b.

[0128] The method of Figure 10 may be performed by a core network node of the communication network, and may comprise a physical or virtual node, and may be implemented in acomputing device or server apparatus and / or in a virtualized environment, for example in a cloud, edge cloud or fog deployment.

[0129] The server node is operable to execute a second ML task, wherein the second ML task is a second part of a distributed inference process. A first part of the distributed inference process is executed by one or more client nodes, generates at least one activation for the second part of the distributed inference process, and is executed responsive to a request from a coordinating node.

[0130] The method begins at step 1002, with the server node receiving, from at least one of the one or more client nodes, the at least one activation (e.g., in one or more second messages). The one or more second messages may comprise an identifier, which allows the server node to associate the at least one activation with an analytics request. This step may correspond to step 904 of Figure 9.

[0131] At step 1004, the method comprises executing the second ML task using the at least one activation to generate an output for the distributed inference process.

[0132] At step 1006, the method comprises transmitting the output to the coordinating node. This step may correspond to step 306 of Figure 3.

[0133] It should be appreciated that, in the methods of Figures 9 and 10, the coordinating node from which the request for generating the at least one activation is received, and the server node to which the at least one activation is transmitted, are separate logical entities. This means that the coordinating node is not the same node that performs result aggregation and generates an output prediction for the distributed inference process. This is instead performed at a separate server node.

[0134] Embodiments of the present disclosure may also be directed to a method in which appropriate client nodes for handling an analytics request are selected taking UE mobility into account. The method may be performed by a server node (which performs the coordination and aggregates the results as in the existing TS) or in a dedicated coordinating node (i.e., a separate logical entity).

[0135] Figure 11 is a flow chart for a method according to embodiments of the present disclosure. The method is performed by a node in a communications network for coordinating executionof one or more ML tasks to be executed by one or more respective client nodes. The one or more ML tasks generate activations, and comprise first parts of a distributed inference process. A second part of the distributed inference process is executed by a server node and comprises using the activations to generate an output of the distributed inference process.

[0136] The node may be a dedicated coordinating node (e.g., the coordinating node discussed in relation to Figures 3-8b). Alternatively, the node may be a server node (i.e., the server node may perform both coordination of the distributed inference process and result aggregation).

[0137] The method of Figure 11 may be performed by a core network node of the communication network, and 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.

[0138] The method begins at step 1102, with the node determining at least one type of input data relevant to an analytics request received by the node, wherein the analytics request identifies a wireless device and a time period during which an analytics service is requested for the wireless device.

[0139] At step 1104, the node determines one or more fifth network nodes which store the at least one type of input data.

[0140] At step 1106, the node identifies one or more second network nodes from the one or more fifth network nodes, wherein the one or more second network nodes are predicted to serve the wireless devices during the time period;

[0141] At step 1108, the node identifies a first client node of the one or more respective client nodes, wherein the first client node has access to data located and / or stored at the one or more second network nodes; and

[0142] At step 1110, the node initiates transmission, to the first client node, of a request that the first client node generates at least one activation by executing, using the input data of the at least one type stored at the one or more second network nodes, the respective ML task of the one or more respective ML tasks.If the node is a coordinating node, the method may further comprise receiving, from the server node, an output of the distributed inference process.

[0143] As indicated above with reference to the steps of Figure 8b, the signalling flow of Figure 8b may be considered an example of the method of Figure 11.

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

[0145] Optionally, the coordinating node 1200 may comprise a memory 1203. In some embodiments, the memory 1203 of the coordinating node 1200 can be configured to store instructions (e.g. program code) executable by the processing circuitry 1201 of the coordinating node 1200 whereby the apparatus is operable the perform the method as described with reference to any one of Figures 3, 6, 7, and 11.

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

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

[0148] The coordinating node 1200 may be configured to operate in the manner described herein in respect of a coordinating node.

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

[0150] Optionally, the client node 1300 may comprise a memory 1303. In some embodiments, the memory 1303 of the client node 1300 can be configured to store instructions (e.g. program code) executable by the processing circuitry 1301 of the client node 1300 whereby the apparatus is operable to perform the method as described with reference to Figure 9 or 11.

[0151] Alternatively or in addition, the memory 1303 of the client node 1300, can be configured to store any requests, resources, information, data, signals, or similar that are described herein. The processing circuitry 1301 of the client node 1300 may be configured to control the memory 1303 of the client node 1300 to store any requests, resources, information, data, signals, or similar that are described hereinIn some embodiments, the client node 1300 may optionally comprise a communications interface 1302. The communications interface 1302 of the client node 1300 can be for use in communicating with other nodes, such as other virtual nodes. For example, the communications interface 1302 of the client node 1300 can be configured to transmit to and / or receive from other nodes requests, resources, information, data, signals, or similar. The processing circuitry 1301 of client node 1300 may be configured to control the communications interface 1302 of the client node 1300 to transmit to and / or receive from other nodes requests, resources, information, data, signals, or similar. The communications interface 1302 can use any suitable communication technology.

[0152] The client node 1300 may be configured to operate in the manner described herein in respect of a client node.

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

[0154] Optionally, the server node 1400 may comprise a memory 1403. In some embodiments, the memory 1403 of the server node 1400 can be configured to store instructions (e.g. program code) executable by the processing circuitry 1401 of the server node 1400 whereby the apparatus is operable to perform the method as described with reference to Figure 10 or 11.

[0155] Alternatively or in addition, the memory 1403 of the server node 1400, can be configured to store any requests, resources, information, data, signals, or similar that are described herein. The processing circuitry 1401 of the server node 1400 may be configured to controlthe memory 1403 of the server node 1400 to store any requests, resources, information, data, signals, or similar that are described herein

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

[0157] The server node 1400 may be configured to operate in the manner described herein in respect of a server node.

[0158] There is also provided a computer program comprising instructions which, when executed on a least one processor (such as the processing circuitry 1201 of the coordinating node 1200, the processing circuitry 1301 of the client node 1300, the processing circuitry 1401 of the server node 1400 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.

[0159] Functions implemented by some embodiments may be virtualized a virtualization environment. 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 environmentshosted 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 includes components defined by the O-RAN Alliance, such as an O-Cloud environment orchestrated by a Service Management and Orchestration Framework via an 0-2 interface. Virtualization may facilitate distributed implementations of a network node, UE, core network node, or host.

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

[0161] 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 FL enables embodiments described herein to automatically and clearly define the responsibilities of each client node.

[0162] 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

CLAIMS1. A method, performed by a coordinating node (1200) in a communications network, for coordinating execution of one or more machine learning, ML, tasks to be executed by one or more respective client nodes (1300), wherein the one or more ML tasks generate intermediate outputs, and comprise first parts of a distributed inference process, and wherein a second part of the distributed inference process is executed by a server node (1400) and comprises using the intermediate outputs to generate an output of the distributed inference process, the method comprising:identifying (302) a first client node of the one or more client nodes by determining that the first client node has access to input data relevant to an analytics request;requesting (304) the first client node to generate at least one intermediate output by executing, using the input data, the respective ML task of the one or more ML tasks; andreceiving (306), from the server node, an output of the distributed inference process.

2. The method of claim 1, further comprising determining, based on the analytics request, that the input data is relevant to the analytics request by determining (602) at least one type of input data for responding to the analytics request.

3. The method of claim 2, further comprising identifying (604) one or more second network nodes at which input data of the at least one type is stored and / or located.

4. The method of claim 3, wherein determining that the first client node has access to the input data relevant to the analytics request comprises determining (608) that the first client node has access to data stored and / or located at the one or more second network nodes.

5. The method of claim 3 or 4, wherein identifying the one or more second network nodes comprises querying (606) a network entity in a core network of the communications network.

6. The method of any of claims 3-5, wherein the analytics request identifies a wireless device and a time period during which an analytics service is requested for the wireless device, and wherein identifying the one or more second network nodes comprises determining (610) that the one or more second network nodes are predicted to serve the wireless device during the time period.

7. The method of any of claims 3-6, wherein the one or more second network nodes comprise any one or more of: an analytics and mobility network entity, a session management entity, and a base station.

8. The method of any preceding claim, the method further comprising:indicating (704), to the server node, that the server node is to receive the at least one intermediate output from the first client node; and / or requesting the server node to execute the second part using the at least one intermediate output to generate the output for the distributed inference process.

9. The method of any preceding claim, the method further comprising:receiving (702), from a third node, the analytics request.

10. The method of claim 9, further comprising:- transmitting (706), to the third node, a response to the analytics request comprising the output of the distributed inference process.

11. The method of any preceding claim, wherein the analytics request is a request for an analytics service associated with any one or more of: traffic; mobility; location; performance; load for one or more nodes; devices; network parts; and network slices.

12. The method of any preceding claim, wherein requesting the first client node to generate the at least one intermediate output comprises implicitly or explicitly instructing the first client node to transmit, to the server node, the at least one intermediate output.

13. The method of any preceding claim, wherein requesting the first client node to generate the at least one intermediate output comprises transmitting a request that the first client node generates the at least one intermediate output in a first message,and the at least one intermediate output is transmitted by the first client node to the server node in one or more second messages, and wherein the first message further includes an identifier of the analytics request for inclusion in the one or more second messages.

14. A method performed by a first client node (1300) in a communications network, the first client node operable to execute a first machine learning, ML, task, wherein the first ML task generates at least one intermediate output, and is a first part of a distributed inference process, and wherein a second part of the distributed inference process is executed by a server node (1400) and comprises using the at least one intermediate output to generate an output of the distributed inference process, wherein the first client node has access to input data, the method comprising: receiving (902), from a coordinating node (1200), a request that the first client node generates the at least one intermediate output by executing, using the input data, the first ML task; and- transmitting (904), to the server node, the at least one intermediate output.

15. A method performed by a server node (1400) in a communications network, the server node operable to execute a second machine learning, ML, task, wherein the second ML task is a second part of a distributed inference process, wherein a first part of a distributed inference process is executed by one or more client nodes (1300), generates at least one intermediate output for the second part of the distributed inference process, and is executed responsive to a request from a coordinating node (1200), the method comprising:receiving (1002), from at least one of the one or more client nodes, the at least one intermediate output;- executing (1004) the second ML task using the at least one intermediate output to generate an output for the distributed inference process; and - transmitting (1006) the output to the coordinating node.

16. A coordinating node (1200) for a communications network, wherein the coordinating node is for coordinating execution of one or more machine learning, ML, tasks to be executed by one or more respective client nodes (1300), wherein the one or more ML tasks generate intermediate outputs, and comprise first parts of a distributed inference process, and wherein a second part of the distributed inference process is executed by a server node (1400) and comprises using the intermediate outputsto generate an output of the distributed inference process, the coordinating node comprising processing circuitry (1201) and a memory (1203), the memory containing instructions executable by the processing circuitry whereby the coordinating node is operable to:identify (302) a first client node of the one or more client nodes by determining that the first client node has access to input data relevant to an analytics request;request (304) the first client node to generate at least one intermediate output by executing, using the input data, the respective ML task of the one or more ML tasks; andreceive (306), from the server node, an output of the distributed inference process.

17. The coordinating node as claimed in claim 16, 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 13.

18. A first client node (1300) for a communications network, wherein the first client node is operable to execute a first machine learning, ML, task, wherein the first ML task generates at least one intermediate output, and is a first part of a distributed inference process, and wherein a second part of the distributed inference process is executed by a server node (1400) and comprises using the at least one intermediate output to generate an output of the distributed inference process, wherein the first client node has access to input data, the first client node comprising processing circuitry (1301) and a memory (1303), the memory containing instructions executable by the processing circuitry whereby the first client node is operable to:receive (902), from a coordinating node (1200), a request that the first client node generates the at least one intermediate output by executing, using the input data, the first ML task; andtransmit (904), to the server node, the at least one intermediate output.

19. A server node (1400) for a communications network, wherein the server node operable to execute a second machine learning, ML, task, wherein the second ML task is a second part of a distributed inference process, wherein a first part of a distributed inference process is executed by one or more client nodes (1300),generates at least one intermediate output for the second part of the distributed inference process, and is executed responsive to a request from a coordinating node (1200), the server node comprising processing circuitry (1401) and a memory (1403), the memory containing instructions executable by the processing circuitry whereby the server node is operable to:receive (1002), from at least one of the one or more client nodes, the at least one intermediate output;execute (1004) the second ML task using the at least one intermediate output to generate an output for the distributed inference process; and transmit (1006) the output to the coordinating node.

20. 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 15.

21. 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 15.

22. A computer program product comprising non transitory computer readable media having stored thereon a computer program according to claim 21.

Images