Apparatus and methods for coordination of joint model training in mobile communication networks

Abstract

Described is an entity for executing joint model training of at least two machine learning, ML, models comprised in at least two respective entities configured to generate network analytics information in a mobile communication network. The first entity comprises a first ML model and is configured to execute joint model training of the first ML model and a second ML model comprised within a second entity. The first and second ML models share a model objective, and the first and second ML models are different. The first entity executes the joint model training by: training the first ML model to obtain the first training output; providing a training-start indication to the second entity to initiate local training of the second ML model; receiving a second training output from the second entity; and analysing the first and second training outputs to generate updated first ML model information and updated second ML model information for updating the first and second ML models.

Description

APPARATUS AND METHODS FOR COORDINATION OF JOINT MODEL TRAINING IN MOBILE COMMUNICATION NETWORKSFIELD OF THE INVENTION

[0001] The present disclosure relates to the field of mobile communication networks, in particular, to 5th or 6th generation (5G, 5GS, and 6G) mobile or cellular communication systems and networks. In particular, the disclosure relates to coordinating joint machine learning (ML) model training across separate network data analytics functions (NWDAFs) across one or more mobile communication networks.BACKGROUND

[0002] TS 23.288 defines the analytics framework for the 3rd generation partnership project (3GPP) 5GS in release 16 (R16) . TS 23.288 specifies that a Network Function (NF) , Application Functions (AFs) and Operations, Administration, and Maintenance (OAM) are allowed to consume analytics information (e.g., analytics identifications (IDs) ) from a Network Data Analytics Function NWDAF. In TS 23.288 R16, the mechanisms and services for the analytics consumption are defined, as well as types of analytics IDs that can be generated by the NWDAF to support the analytics consumers (e.g., NF, AFs or OAM) to perform their tasks and to improve the performance of their target tasks.

[0003] Release 18 (R18) of 3GPP provided a definition of the NWDAF architectural enhancements for the supporting Horizontal Federated Learning, HFL, (TS 23.288 Clause 5.3) . Certain assumptions of HFL provide that each training entity collaborating in the training of a machine learning (ML) model has the same ML model. The different entities may have different data sets which are not exposed to the other entities of the training process. Thus, this type of collaboration is suitable for scenarios where the training entities can share the same ML Model.

[0004] Certain networking scenarios, however, preclude the possibility of making use of the HFL defined in 3GPP R18. For example, NWDAFs from different vendors without any interoperability support are not allowed to share their ML Models with NWDAFs from other vendors. Another example, are NWDAFs cooperating for roaming analytics generation that cannot perform HFL for improving the ML Model used in the generation of the roaming analytics, especially in the case of home routed roaming, because R18 prevents NWDAFs from different mobile operators to exchange any information related to ML model selection or ML model training. Examples such as this immediately precludes such entities from making use of the data and the training information learnt from other entities under the currently defined HFL that is supported by R18.

[0005] The present disclosure is therefore aimed towards providing methods and systems for solving at least the afore-mentioned problems.SUMMARY

[0006] In view of the scenarios above, improved coordination is needed between different the training of MLs across non-cooperative entities, such as entities of different network vendors or entities in disparate geographical locations. This is advantageous because providing joint training of ML across different entities mitigates waste of network resources spent gathering and analysing data, and also reduces imprecise policy decisions. In particular, improving or obtaining training cooperation non-cooperative addresses the problem of low accuracy data produced by entities in home routed roaming (HRR) scenarios, by provides means to align the inference capabilities of non-cooperative entities.

[0007] A first aspect of the present disclosure provides a first entity configured to generate network analytics information in a mobile communication network, wherein the first entity comprises a first machine learning, ML, model, the first entity being configured to execute joint model training of the first ML model and a second ML model comprised within a second entity, the second entity being configured to generate network analytics information in a mobile communication network, the joint model training characterised in that:

[0008] the first ML model and the second ML model have the same model objective, and wherein the first ML model is a different ML model to the second ML model;

[0009] wherein the first entity is configured to execute the joint model training by:

[0010] training the first ML model locally at the first entity to obtain a first training output;

[0011] providing a joint model training indication to the second entity, wherein the joint model training indication is an indication to initiate local training of the second ML model at the second entity and / or is an indication for the second entity to associate the second ML model at the second entity with the first ML model at the first entity;

[0012] receiving, from the second entity, a second training output obtained at the second entity;

[0013] generating updated first ML model information for updating the first ML model and updated second ML model information for updating the second ML model based on analysis, by the first entity, of the first training output and the second training output.

[0014] In other words, the analysis, performed by the first entity, of the first training output and the second training output results in the generation of the updated first ML model information for updating the first ML model and updated second ML model information for updating the second ML model.

[0015] In an implementation of the first aspect, the first entity is further configured to associate a joint training ML identification, ID, to the first ML model and to the at least one second ML model.

[0016] In an implementation of the first aspect, the first entity is further configured to execute the joint model training with an active role, wherein the active role defines that an entity that is associated with: the first ML model, the first training output, the second ML model, the second training output, and information to evaluate a performance of the joint model training.

[0017] In an implementation of the first aspect, the joint model training indication is an indication for the second entity to associate the second ML model at the second entity to the first ML model at the first entity, and further indicates a request for the second entity to participate in the joint model training.

[0018] In an implementation of the first aspect, the first entity is further configured to determine the joint model training indication based on a joint model training configuration available at the first entity, wherein the joint model training configuration defines parameters for the first entity for executing the joint model training.

[0019] In an implementation of the first aspect, the parameters for executing joint model training comprise any one or more of the following:

[0020] - information defining which roles the first entity and / or the second entity are allowed to have and / or restricted from having in the joint model training; and

[0021] - one or more machine learning requirements allowed and / or restricted to be associated with the first ML model and / or second ML model in the joint model training; and

[0022] - one or more alignment information allowed and / or restricted for the joint model training.

[0023] In an implementation of the first aspect, the joint model training indication further comprises any one or more of the following:

[0024] - a flag indicating a type of training defining the joint model training;

[0025] - role information of the first entity and / or second entity in the joint model training;

[0026] - joint training ML ID;

[0027] - identification of the first ML model and / or identification of second ML model;

[0028] - a flag indicating a preparation of the joint model training;

[0029] - a flag indicating to start the joint model training;

[0030] - one or more machine learning requirements to be used in the joint model training of the first ML model and / or second ML model;

[0031] - one or more alignment information to be used for the joint model training;

[0032] - information about second ML model or partial set of information about ML model;

[0033] - information about first ML model.

[0034] In an implementation of the first aspect, the first entity is further configured to obtain a participation confirmation from the second entity indicating either: that the first entity can execute the joint model training of the first ML model and the second ML model.

[0035] In an implementation of the first aspect, the first entity is further configured to map joint training ML ID to information defining the joint model training.

[0036] In an implementation of the first aspect, the information defining the joint model training comprises any one or more of the following:

[0037] - information defining parameters and entities involved in the joint model training executed by the first entity;

[0038] - identification of the first ML model and / or identification of second ML model;

[0039] - one or more alignment information to be used for the joint model training;

[0040] - information defining the second ML model or a subset of information defining the ML model;

[0041] - information defining the first ML model.

[0042] In an implementation of the first aspect, the first entity is further configured to update the information defining the joint model training based on the updated first ML model information and / or the updated second ML model information.

[0043] In an implementation of the first aspect, the first entity is configured to determine a conclusion of the joint model training of the first ML model and the second ML based on analysing the first training output and the second training output and / or based on local configurations of the first entity and / or the second entity.

[0044] In an implementation of the first aspect, the first entity is configured to determine the conclusion of the joint model training based on calculating an objective loss using: i) the first training output; ii) the second training output and iii) training labels configured to allow evaluation of ML models. Preferably the training labels comprise ground truth labels.

[0045] In an implementation of the first aspect, the first entity is configured to provide a terminate-training indication to the second entity to initiate termination of local training of the second ML model at the second entity. The first entity may also be configured to terminate local training of the first ML model at the first entity.

[0046] In an implementation of the first aspect, the first entity is configured to provide i) the updated second ML model information and ii) a model-update indication to the second entity to initiate updating of the second model at the second entity using the updated second ML model information.

[0047] In an implementation of the first aspect, the joint model training of the first and second ML models executed by the first entity comprises vertical federated learning, VFL.

[0048] In an implementation of the first aspect, the first entity and the second entity belong to the same mobile communication network, and wherein the first entity is associated with a first network vendor and the second entity is associated with a second network vendor. In some examples the first and second vendors are not allowed to share or exchange information of their respective ML models.

[0049] In an implementation of the first aspect, the first entity and the second entity belong to the same mobile communication network, and wherein the first entity manages network communications for a first region and the second entity manages network communications in a second region different to the first region.

[0050] In an implementation of the first aspect, the first entity belongs to a first mobile communication network and the second entity belongs to a different, second, mobile communication network, wherein the first ML model is configured to predict a service experience for a user equipment, UE, performing HRR between the first and second mobile communication network. Thus, the joint training is preferably configured to improve the ability of at least the first ML model to predict a service experience for a UE performing HRR.

[0051] In an implementation of the first aspect, each of the first entity and the second entity is a network data analytics function, NWDAF, comprising a model training logical function, MTLF.

[0052] In an implementation of the first aspect, a first feature space of first data used to train the first ML model overlaps at least to an extent with a second feature space of second data used to train the second ML model. In other words, in some examples the first and second ML models are each trained on a respective set of features (e.g., overall data type collected for processes related to the jointly trained ML Model) where there exists a subset of features that is shared between the first and second ML models.

[0053] In an implementation of the first aspect, the first entity is configured to generate the updated first ML model information and the updated second ML model information based on the calculated objective loss.

[0054] In an implementation of the first aspect, the first entity is configured to execute the joint model training of the first ML model, the second ML model, and at least one further ML model comprised in a respective at least one further entity configured to generate network analytics information in a mobile communication network, wherein each further entity shares the model objective, and wherein the first entity is an active entity and the second entity and the at least one further entities are passive entities.

[0055] In an implementation of the first aspect the first entity is further configured to execute the joint model training by:

[0056] providing a joint model training indication to each of the at least one further entity to initiate local training of each at least one further ML model at each at least one further entity;

[0057] receiving, from each of the at least one further entity, further training output obtained at the at last one further entity;

[0058] analysing the first training output, the second training output, and each at least one further training output to generate updated further ML model information for updating each at least one further ML model.

[0059] In an implementation of the first aspect the first entity is configured to be denied permission to access information defining ML model configurations from any of the passive entities, and is configured to be denied permission to transfer information defining a configuration of the first ML model to any of the passive entities.

[0060] In an implementation of the first aspect the model objective defines a metric pertaining to service experience data deriving from user equipment, UE, performing home routed roaming, HRR.

[0061] In an implementation of the first aspect, the first entity is configured to determine whether it can execute joint training with the second entity by:

[0062] obtaining interoperability information comprising at least parameters defining a methodology of the joint model training;

[0063] providing a participation indication to the second entity comprising at least part of the interoperability information; and

[0064] receiving a participation confirmation from the second entity indicating that the first entity can execute joint training of the first ML model and the second ML model.

[0065] A second aspect of the present disclosure provides a method of joint model training performed by a first entity, the first entity configured to generate network analytics information in a mobile communication network, the first entity comprising a first machine learning, ML, model, and the first entity being configured to execute joint model training of the first ML model and a second ML model comprised within a second entity, the second entity being configured to generate network analytics information in a mobile communication network, the method comprising:

[0066] training the first ML model locally at the first entity to obtain a first training output;

[0067] providing a joint model training indication to the second entity, wherein the joint model training indication is an indication to initiate local training of the second ML model at the second entity and / or is an indication for the second entity to associate the second ML model at the second entity with the first ML model at the first entity;

[0068] receiving, from the second entity, a second training output obtained at the second entity;

[0069] generating updated first ML model information for updating the first ML model and updated second ML model information for updating the second ML model based on analysing the first training output and the second training output,

[0070] wherein the first ML model and the second ML model have the same model objective and wherein the first ML model is a different ML model to the second ML model.

[0071] A third aspect of the present disclosure provides a second entity configured to generate network analytics information in a mobile communication network, the second entity comprising a second machine learning, ML, model, the second entity being configured to participate in joint model training of the second ML model and a first ML model comprised within a first entity, the first entity being configured to generate network analytics information in a mobile communication network, the joint model training characterised in that:

[0072] the first ML model and the second ML model have the same model objective, and wherein the first ML model is a different ML model to the second ML model;

[0073] wherein the second entity is configured to participate in the joint model training by:

[0074] receiving a joint model training indication from the first entity, wherein the joint model training indication is an indication to initiate local training of the second ML model at the second entity and / or is an  indication for the second entity to associate the second ML model at the second entity to the first ML model at the first entity;

[0075] based on the joint model training indication, initiating local training of the second ML model at the second entity to obtain a second training output;

[0076] providing the second training output to the first entity.

[0077] In an implementation of the third aspect the second entity determines it can participate in the joint model training based on the obtained joint model training indication and / or based on joint model training configuration available at the second entity, where the joint model training configuration defines parameters for the second entity to participate in the joint model training.

[0078] In an implementation of the third aspect the parameters for executing joint model training comprise any one or more of the following:

[0079] - information defining which roles the second entity is allowed to have in the joint model training; and

[0080] - one or more machine learning requirements allowed and / or not allowed to be associated with second ML model in the joint model training; and

[0081] - one or more alignment information allowed and / or restricted for the joint model training. The machine learning requirements may comprise and / or be representative of characteristics and / or a machine learning methodology.

[0082] In an implementation of the third aspect the joint model training indication further comprises any one or more of the following:

[0083] - a flag indicating a type of training defining the joint model training;

[0084] - role information of the first entity and / or second entity in the joint model training;

[0085] - joint training ML ID;

[0086] - identification of the first ML model and / or identification of second ML model;

[0087] - a flag indicating a preparation of the joint model training;

[0088] - a flag indicating to start the joint model training;

[0089] - one or more machine learning requirements to be used in the joint model training of the first ML model and / or second ML model;

[0090] - one or more alignment information to be used for the joint model training;

[0091] - information about second ML model or partial set of information about ML model;

[0092] - information about first ML model.

[0093] In an implementation of the third aspect the joint model training indication comprises joint training ML identification, ID, and wherein the second entity associates the second ML model to the joint model training associated with the first ML model by mapping the obtained joint training ML ID to an identification of the second ML model at the second entity.

[0094] In an implementation of the third aspect the second entity is further configured to map the obtained joint training ML ID to local information defining the second ML model at the second entity.

[0095] In an implementation of the third aspect the second entity is further configured to receive from the first entity updated second ML model information for updating the second ML model and / or a model-update indication indicating that the second entity should update the second ML model.

[0096] In an implementation of the third aspect the second entity is configured to update parameters of the second ML model using the updated second ML model information.

[0097] In an implementation of the third aspect the second entity is configured to receive, from the first entity, a terminate-training indication and based on the terminate-training indication to terminate local training of the second ML model.

[0098] In an implementation of the third aspect the joint model training of the first ML model and the second ML model entity comprises vertical federated learning, VFL.

[0099] A fourth aspect of the present disclosure provides method of joint model training being performed by a second entity, the second entity configured to generate network analytics information in a mobile communication network, the second entity comprising a second machine learning, ML, model, and the second entity being configured to participate in joint model training of the second ML model and a first ML model comprised within a first entity, the first entity being configured to generate network analytics information in a mobile communication network, the method comprising:

[0100] receiving a joint model training indication from the first entity, wherein the joint model training indication is an indication to initiate local training of the second ML model at the second entity and / or is an indication for the second entity to associate the second ML model at the second entity to the first ML model at the first entity;

[0101] based on receiving the joint model training indication, initiating local training of the second ML model at the second entity to obtain a second training output;

[0102] providing the second training output to the first entity; and

[0103] receiving, from the first entity, updated second ML model information for updating the second ML model,

[0104] wherein the first ML model and the second ML model have the same model objective and wherein the first ML model is a different ML model to the second ML model.

[0105] In an implementation of the fourth aspect the participating in the joint training by the second entity is performed without accessing information defining the first ML model configuration and without transferring information defining a configuration of the second ML model to the first entity.

[0106] A fifth aspect of the present disclosure provides a method of executing joint model training of a first machine learning, ML, model at an active entity with one or more further ML models at one or more respective passive entities, wherein the active entity and the one or more passive entities are configured to generate network analytics information in one or more mobile communication networks, the method comprising:

[0107] training the first ML model locally at the active entity to obtain a first training output;

[0108] providing a joint model training indication to the one or more passive entities to initiate local training of respective one or more further ML models at the respective one or more passive entities;

[0109] receiving, from the one or more passive entities, one or more further training outputs obtained at the respective one or more passive entities;

[0110] generating updated first ML model information for updating the first ML model and one or more updated further ML model information for updating the one or more further ML models based on analysing, at the active entity, the first training output and the one or more further training outputs,

[0111] wherein the first ML model and the one or more further ML models have the same model objective, and wherein the first ML model is a different ML model to each of the one or more further ML models.

[0112] In an implementation of the fifth aspect the execution of the joint model training is performed without the active entity sharing information defining the first ML model configuration with any of the one or more ML models and without the active entity accessing information defining configurations of any of the one or more further ML models.

[0113] In an implementation of the fifth aspect, the method further comprising updating, at the active entity, parameters of the first ML model using the updated first ML model information.

[0114] In an implementation of the fifth aspect the active entity is configured to evaluate a progression of the joint model training based on calculating an objective loss using: i) the first training output; ii) the one or more further training output and iii) training labels configured to allow evaluation of ML models.

[0115] In an implementation of the fifth aspect the active entity is configured to determine a conclusion of the joint model training based on an evaluated progression of the joint model training, and to provide a terminate-training indication to the one or more further entities to initiate termination of local training of the further ML models at each of the one or more further entities.

[0116] A sixth aspect of the present disclosure a computer program comprising a program code for performing the method according to any of the second, fourth or fifth aspects when executed on a computer.BRIEF DESCRIPTION OF THE DRAWINGS

[0117] The present disclosure is described by way of example, with reference to the accompanying drawings, in which:

[0118] Figure 1 shows an example of home routed roaming as known in the art;

[0119] Figure 2 shows an example of a mobile network configuration as known in the art;

[0120] Figure 3 shows an overview of examples of the mobile network configurations according to present embodiments;

[0121] Figure 4 shows a logical schematic illustrating how support is provided for Inter-PLMN ML training according to present embodiments;

[0122] Figure 5 shows another logical schematic illustrating how support is provided for Inter-PLMN ML training according to present embodiments;

[0123] Figure 6 illustrates a flow diagram for a vertical federated learning, VFL, machine learning method according to present embodiments;

[0124] Figure 7 shows a logical schematic illustrating how support is provided for Inter-PLMN ML training using a broker entity according to present embodiments;

[0125] Figure 8 shows a detailed logical schematic for the preparation phase of figure 7;

[0126] Figure 9 shows a detailed logical schematic for the training phase of figure 7;

[0127] Figure 10 shows a detailed logical schematic for the conclusion phase of figure 7;

[0128] Figure 11 shows a detailed logical schematic for the preparation phase relating to an embodiment for providing Inter-PLMN ML training support using two broker entities;

[0129] Figure 12 shows a detailed logical schematic for the training phase relating to an embodiment for providing Inter-PLMN ML training support using two broker entities.

[0130] Figure 13 shows a detailed logical schematic for the conclusion phase relating to an embodiment for providing Inter-PLMN ML training support using two broker entities.DETAILED DESCRIPTION

[0131] In order to create new possibilities for collaborative training in the NWDAF architecture defined in 3GPP R18 and thus to solve the aforementioned problems associated with non-cooperating NWDAFs, the present disclosure provides methods for performing Vertical Federated Learning (VFL) across multiple entities. In particular, the present disclosure provides methods for performing joint model training, e.g., VFL, across multiple NWDAFs that do not typically share data or collaborate in training their respective ML models, e.g., NWDAFs belonging to different vendors, different geographical regions or different public land mobile networks (PLMNs) .

[0132] Currently, one problematic scenario for collaboration between entities is home routed roaming (HRR) , i.e., where a data session of user equipment (UE) is ‘anchored’ in a home network while the UE roams in a different, visitor, network. Figure 1 illustrates an example of HRR for UE roaming in a visitor PLMN (V-PLMN) operated that is a different PLMN to the home network. This figure has been extracted from TS 23.501 Clause 4.4.3 and shows the 5G support for home routed roaming with IMS services.

[0133] Currently, EU “Roam Like at Home” regulations require network operators to provide services and quality of service for roaming users in the same way operators do for home users. Part of this service is provided by Roaming-Exchange NWDAFs (RE-NWDAFs) . RE-NWDAFs are configured to provide analytics support during roaming, i.e., providing quality of service (QoS) indications and support for Slice Selection. RE-NWDAFs are also configured to exchange collected data, but only to the extent that is permitted based on the privacy requirements of the vendor of the PLMN in which the RE-NWDAFs belong.

[0134] The home RE-NWDAF (H-RE-NWDAF) in the H-PLMN may request or subscribe to access analytics from the visiting PLMN (V-PLMN) to be accessed from the visiting RE-NWDAF (V-RE-NWDAF) . These analytics can thus be leveraged by the 5GC network function (NF) in the HMPLN at which the HRR session is anchored. Analytics may include information such as service experience analytics, slice load level analytics and the like, and generally other data that may affect QoS decision. These data may be leveraged by the home policy control function (H-PCF) for QoS control of the Protocol Data Unit (PDU) session. The dashed-dotted line in figure 1 named ‘media plane’ indicates the control pathway used by the HRR PDU session. This HRR PDU session illustrated in figure 1 supports roaming defined in 5GS TS 23.501 / 502 for multiple service of 5GS.

[0135] However, the configuration enabled by the HRR session shown in figure 1 does not allow HFL to take place. Thus, NWDAFs capable of performing training of a machine learning model, i.e., an NWDAF with Model Training Logical Function capability (MTLF-NWDAF) , cannot collaborate to perform joint training. Thus, inference of a ML model performed during a HRR routed scenario will not be representative of the true QoS experienced by the roaming UE because data acquired by entities in the V-MPLN cannot be used to train the ML models of the H-MPLN.

[0136] Figure 2 further illustrates in more detail the problems that are encountered during the HRR scenario illustrated in figure 1. The entities illustrated include: HRR UEs (200) using H-AF applications; V-RAN + V-CN HRR serving entities (202v) ; data sources belonging to the visitor PLMN (204v -RAN, CN, AF) ; V-NWDAF-MTLF (s) (206v) , i.e., one or more V-NWDAFs configured to perform training and inference with a ML model; V-RE-NWDAF (208v) ; H-RE-NWDAF (208h) ; H-NWDAF-MTLF (s) (206h) , i.e., one or more V-NWDAFs configured to perform training and inference with a ML model; data sources belonging to the home PLMN (204h -RAN, CN, AF) ; H-RAN + H-CN HRR serving entities (202h) ; and H-PCF (210h) .

[0137] As mentioned, figure 2 pertains to the HRR scenario. Specifically, The HRR scenario is the case where the RAN part of the data used for an analytics generation and part of the core network data is in the VPLMN, whereas part of the core network data and any AF related data actually belongs to the HPLMN, to which the data traffic is anchored. Block 212 in figure 2 indicates the level of existing support for carrying out training of ML models. In summary, ML model training across  different PLMNs (i.e., inter-PLMN ML model training for short) is not possible. The roaming interface provided by the RE-NWDAFs of the respective home and visiting networks are, as mentioned, configured for analytics requests and inference data collection. However, the V-RE-NWDAF is prevented from requesting data (shown hypothetically block 214) about the V-leg of HRR PDU sessions of roaming UEs. Specifically, the V-RE-NWDAF is configured (or permitted) only to request analytics of inference data from the corresponding H-RE-NWDAF, as defined by the EU “Roam Like at Home” regulations. The V-RE-NWDAF is blocked from exposure to other NWDAFs within the H-PLMN, meaning that the V-RE-NWDAF cannot collect data from the H-NWDAF-MLTF (s) 206h.

[0138] Consequently, as illustrated in figure 2, ML models may only be trained within the confines of each respective PLMN. In other words, only intra-PLMN model training is possible with the currently-defined HFL regime (and, as described below, intra-PLMN model training is only possible under certain circumstances) .

[0139] For similar reasons, federated learning between MTLFs of the home and visiting PLMNs is not permitted (indicated hypothetically in block 216) , even via the RE-NWDAFs. The prevention is due to a lack of ML training service support for RE-NWDAFs between respective RE-NWDAFs. Separately, by virtue of the type of federated learning currently supported (i.e., horizontal federated learning, HFL) which necessarily shares certain data between the multiple ML models, joint training in inter-PLMN scenarios is not possible. This is because of the lack of privacy preservation that is inherent in the current HFL regime. More specifically, NWDAFs from different vendors and / or from different PLMNs without any interoperability support are not allowed to share their ML Models with NWDAFs from other vendors. Thus, HFL is not possible under the current regime.

[0140] Thus, ML models may only be trained internally. This has the disadvantage that the training of ML models is based only on data on home UEs, perhaps with partial information of the HRR PDU session leg obtained via the limited exchange of analytics permitted by the H-RE-NWDAF and the V-RE-NWDAF. The result is an under-trained model for HRR roaming scenarios, because insufficient (or zero) analytics data pertaining to HRR activities are assimilated into the intra-PLMN training. The under-trained models are nevertheless used for inference of HRR roaming UEs despite the fact that the inference is based on insufficient training data.

[0141] Consequently, the possibilities to utilise the MTFL functionality of NWDAFs is limited. In one example, only the H-PLMN provides an analytics output for UEs in roaming. Specifically, a RE-NWDAF may receive subscription from a NF consumer of analytics ID, such as a H-PCF (for simplicity the present disclosure refers to H-PCF as the consumer of analytics, but this is not intended to be limiting: any other suitable NF may also be a consumer of analytics for roaming cases. There is also no restriction that only one type of analytics ID, e.g., service experience analytics ID, may be used in the roaming scenario) , and identify that related UEs are outbound roaming UEs, and in response generate analytics only with HPLMN information.

[0142] In another example, only the V-PLMN provides an analytics output for UEs in roaming in response to an analytics subscription from the H-RE-NWDAF to the V-R-NWDAF. Specifically, the RE-NWDAF that receives subscription from H-PCF identifies that the related UEs are outbound roaming UEs and in response requests the VPLMN to send analytics related to those roaming UEs.

[0143] In another example, the analytics output of the V-NWDAF-MLTF of the V-PLMN and the analytics output of the H-NWDAF-MLTF of the H-PLMN can be aggregated. Specifically, the RE-NWDAF that receives subscription from H-PCF identifies that the related UEs are outbound roaming UEs and in response requests the VPLMN to send the analytics related to those UEs. The H-PCF subsequently generates for itself the analytics related to the UEs, and forms a single, aggregated, analytics output based on the combination of the analytics output from the HPLMN and the VPLMN (TS 23.288 Clause 6.1.5) .

[0144] However, all of these options are sub-optimal because the QoS policy modification triggered by the PCF are based on incomplete data. One problem is that the inference dataset distributions do not match the training dataset distributions. This disparity is due to the fact that 5GS has no support for H-MTLF to request H-RE-NWDAF to collect data from V-RE-NWDAF for ML training purposes. Moreover, in HRR scenarios, this poses the issue that RAN data is in the control of one PLMN (i.e., a VPLMN) , while the ’ ground truth’ data (e.g., in the case of generating service experience analytics) is under control of the HPLMN (e.g., the actual mean opinion score (MOS) experienced by the application when generating service experience analytics) . Thus, when the HPLMN or VPLMN selects a ML Model to be used for analytics generation, the trained ML Model is based on a completely different distribution from the data that is being used for inference process. This is because the HPLMN has no access to the RAN data from VPLMN, and instead has access only to its own CN data and its own AF. Similarly, the VPLMN has no access to the CN data for the part of the PDU session that is anchored in the HPLMN, nor does the VPLMN have the data related to AF that has an agreement with the HPLMN for data exchange.

[0145] Consequently, inference of the ML models may be used to impose policy changes that affect roaming UEs, but the training of the ML models is not permitted to be trained on roaming data for the reasons explained above, even when the V-PLMN and H-PLMN data is aggregated. The problem is therefore that there is no information exchange, and no mechanism for allowing such an exchange, in the NWDAF architecture to allow alignment of inter-PLMN models trained for HRR. This results in analytics outputs that have low accuracy. In detail, the generation of analytics in any of the three examples summarised above are very likely to fall into the ‘Out-of-Distribution’ problem known in ML processes: the discrepancy between data distribution of a trained model versus the inference data distribution used with the trained model. Out-of-Distribution datasets result in low-accuracy outputs. The low-accuracy outputs are consumed by the NF consumers of analytics output, for instance by the H-PCF, belonging to the network at which the HRR is be anchored, which is used to inform QoS policies. However, the decision taken by the NFs consuming the low accuracy analytics, such as QoS policies changes, will be of low quality or imprecise because of the disparity between inference dataset distributions do not match the training dataset distributions.

[0146] To give an example, imprecise decisions by the NF consumers of analytics ID for roaming scenarios, such as H-PCF, can lead to a chain of signaling in PDU sessions of UEs, for instance. Repeated reconfiguration can lead to service latency and worsening unavailability experienced by roaming UEs.

[0147] As explained above, 5GS has no support for exposing ML training interfaces between PLMNs. Thus, even if an MTLF knows the UEs are roaming, the MTLF has no access to data distributions representing usage of HRR services. This, in effect, means that there is no support for ML models trained for HRR scenarios. This leads to yet another problem of the current systems, which is that a great amount of network resources may be wasted, since data collected (during HRR) by entities of one network cannot be used by entities of another network to train their ML model resources because of interoperability and privacy restrictions. Specifically, the H-PCF disregards certain analytics when making policy change decisions due to the fact that data used for the ML Model training is not aligned with the distribution of data used for inference. This results in a waste of computation and signaling in HPLMN and VPLMN. Specifically, when H-PCFs disregard analytics output data, it incurs wasted energy and bandwidth is in transmitting volumes of data that cannot ultimately be used. Furthermore, H-PCF can incur wasted energy and processing power used to compute large volumes of data for inference at the NWDAF, despite the fact that the data distribution of the inference data is mismatched with the training data meaning that the results of inference are imprecise and of low value (or, in the worst case, as mentioned can worsen latency and unavailability) .

[0148] A solution, provided by embodiments of the present disclosure, is to allow more collaborative ML training, in particular that support joint training across multiple NWDAFs, and also including the case of NWDAFs across PLMNs and thus supporting  HRR scenarios. One great benefit of collaborative ML techniques is the potential reduction of resources used by the mobile operator (e.g., less data transmission of collected data, which in turn reduces a number of epochs (training cycles) used in the learning process) . The result is more accurate (and thus better performing) ML models to be used in networks.

[0149] Embodiments of the present disclosure therefore provide an architecture in which a first entity, such as a NWDAF, executes local ML model training where that first entity is configured to align the local ML model with one or more other ML models of one or more further entities (e.g., of or more NWDAFs) . The alignment of the ML Model can be performed, for instance, via Vertical Federated Learning (VFL) . In order to provide such a regime using VFL, the ML model of each entity is configured such that:

[0150] i. each ML model has the same training objective (e.g., the same objective function is used to update the local model parameters of each ML model) ;

[0151] ii. each ML model is trained on dataset samples that are not the same;

[0152] iii. each ML model is trained using a feature space (e.g., a set of inpude data types) that overlap at least to an extent (i.e., the dataset used to train the ML model of the first entity has at least one feature type that is common to the dataset used to train the one or ML models of the other entities) ;

[0153] iv. the ground truth label (e.g., the training labels arranged to allow evaluation of ML models) are available only to one entity (e.g., one NWDAF acts as the “active” entity, and only the active entity may access the ground truth labels and thus calculate loss values using a loss function) .

[0154] Vertical Federated Learning (VFL) is a Machine Learning technique with a higher degree of privacy. In VFL, the training entities collaborating to jointly one or more ML models can maintain both the isolation of data used for the training and isolation of each local ML model itself used in the training process. Thus, in present embodiments, the first entity and the one or more further entities train local ML models joints. Thus, the entities can exchange messages and outputs indicating progress until one entity (the ‘active’ entity which has access to the training labels  / ground truth data) determines when the ML training of all ML models across all entities has completed.

[0155] The result of this is an entity (which, in some examples may be a RE-NWDAF in one PLMN) capable of exchanging information and keeping mappings with another entity (e.g., another RE-NWDAF in a different PLMN) where the information and mappings pertain to information needed to jointly train the ML models local to both entities. Moreover, the joint ML model training involves training of different ML models each in PLMN that share the same ML model objective (e.g., the shared objective may define that both ML models are configured to predict the service experience in case of home routed roaming) and a sub-set of features (e.g., the overall data type collected for processes related to the joint trained ML Model are disjoint, but there exist an intersection between the feature space) .

[0156] Figure 3 shows examples of embodiments related to the present disclosure. The embodiments fall into two categories: the first category 300A represents direct interactions among training entities participating in joint ML Model training based on VFL. In other words, entities such as NWDAFs may interact directly with one another, despite privacy and interoperability restrictions that may apply, to jointly train different their respective local ML models.

[0157] The second category of examples 300B relevant to the present disclosure represents indirect interactions among training entities participating in joint ML model training based on VFL. In other words, the result of the joint training is the same as for 300A embodiment, but the communication is indirect and is mediated by a third entity such as a broker entity.

[0158] The first category comprises at least three types of scenarios. Each of these scenarios share the common attributes as listed above. Generally, in each scenario, there is an ‘active’ entity that communicates directly with a second, ‘passive’ , entity. The  first and second entities are characterised in that they have some interoperability restriction, or some other privacy imposed their communications. The three main examples are as follows:

[0159] 1) Intra-PLMN with different vendors 302A. In this case, one PLMN may comprise two separate vendors. Each operates an entity having ML capability, i.e., a Model Training Logical Function (MTLF) . The entities may be NWDAFs or RE-NWDAFs, for example. The entities of the two (or more) vendors do not have ML model interoperability support i.e., entities belonging to different vendors are not allowed to share and / or exchange their own ML models. Entities therefore have likely use different ML models and cannot observe the nature of the other entities’ ML models. Therefore, the entities of different vendors cannot cooperate on training their own models despite the fact that belong within the same PLMN.

[0160] 2) Intra-PLMN in different geographical regions 304A. In this case, two entities may belong to the same PLMN (i.e., same mobile operator) and may even be run by the same vendor but lack ML model interoperability support. However, the MTLFs are geographically or logically isolated meaning that they reside in different regions of the network. Thus, the isolated MTLFs are forbidden from sharing -or not physically able to share -information. Such restrictions may be imposed due to privacy laws, e.g., that do not allow data from different countries to be moved even if the PLMN / mobile network operator is the same one operating in the two countries.

[0161] 3) Inter-PLMN training with two different PLMNs. In this case, current 3GPP R18 support for roaming scenario prevents any ML model related information to be shared among PLMNs, i.e., as explained above in respect of figures 1 and 2.

[0162] Generally, in all three examples above, present embodiments provide VFL-based training such that MTLFs can interact in a collaborative training process without needing to share their ML models. Present embodiments also obviate the need share data collected by respective entities to serve as input for their models; in other words, the data collected by each entity remains local to that entity and is used only to train the local ML model of that entity.

[0163] The second category of examples 300B defines the scenarios in which the MTLFs are prevented from directly interacting with each other. In this case, the VFL broker capability is defined in present examples, which allows an NF of the 3GPP architecture (e.g., the NEF, or NWDAF or RE-NWDAF) to serve as an intermediary entity that can interact the non-cooperative MTLFs. In intra-PLMN scenarios 302B a single NF with VFL Broker Capability could be used, as indicated. In more complex scenarios such as inter-region in a PLMN 304B or inter-PLMN 306B two NF entities with VFL Broker Capability may be used to maintain the isolation among the different parts / regions of the PLMN or between the PLMNs. In order to allow MTLFs that are prevented from sharing their ML models as well as the input data for such models, we provide a solution based on Vertical Federated Learning. Figure 2 illustrate the core points of the present disclosure as well as the main entities and their enhanced capabilities.

[0164] It will be appreciated that the term “entity” used in the present disclosure can to any suitable entity with ML capability, i.e., an MLTF entity, and which has some interoperability restriction with another entity such that the HFL defined by current 3GGP R18 is not suitable. Preferably the entity is an NWDAF. The NWDAF may be a software product offer by a Mobile Network Vendor, or a mobile network integration company specialized in customizing mobile network vendor solutions to the needs of mobile operators. Embodiments of the present disclosure consider the 5G network architecture defined by 3GPP and documented in TS 23.501. Specifically, the embodiments are focused on the extensions related to the NWDAF Network Function, which is defined in the 3GPP TS 23.288 specification.

[0165] Entities according to present embodiments are therefore general ‘VFL capable’ . An entity with VFL capability is defined by an entity with support for joint ML model training with other entities that have support for joint ML model training. In the  present disclosure, joint ML model training generally involves training of different ML models (i.e., one ML model per entity) where each ML model shares the same ML model objective (e.g., both models are designed to predict the same target, e.g., service experience in case of home routed roaming) and each ML Model has a set of features (e.g., overall data type collected for processes related to the joint trained ML Model) where there exists a subset of features that is shared between the two ML models. IN other words, the feature space of data used by the two entities is not the same but has an intersection.

[0166] Figure 4 illustrates logical schematic illustrating how support is provided for Inter-PLMN ML training according to the 306A embodiment. The schematic is generally applicable to all 300A embodiments, however. The interactions are described between a first entity 406 and a second entity 408. In this example, the entities belong to different PLMN networks and so cannot perform HFL since there is no interoperability support for this. Each entity has its own ML model. Only the first entity in this example has access to the ‘ground truth’ data, i.e., the training labels. Thus, the first entity has oversight of the training progress and has the power to i) initiate local training of the ML model belonging to the second entity, at the second entity ii) calculate the loss of the combined training of the ML models of both entity using the training labels and iii) determine that training has sufficiently progress and iv) signal that training may stop. In the context of VFL the first entity is considered the ‘active’ entity and the second entity is considered the ‘passive’ entity.

[0167] The first stage is a preparation stage 400, during which the first entity 406 contacts the second entity 408 to determine whether it can partake in a joint ML training using VFL. The first step S100 comprises sending a request to the second entity, from the first entity, for VFL ML model training preparation. Sending the request in step S100 may involve sending preparation information. The request is also referred to as a ’ participation indication’ . Preparation information may define one or more parameters for configuring and / or setting up the joint training methodology. In this disclosure, the preparation information may also be called ‘interoperability information’ . The preparation information may also define parameters for setting up the public algorithm data (i.e., the data that is non-private and that available to both entities) and / or meta-information related to the different ML models belonging to the two entities. At most one ML model will be deemed the ‘Active VFL ML model’ , in this case belonging to the first entity. All other ML models will be deemed ‘passive VFL ML models’ . The passive ML models are related to the same objective as the active ML model, e.g., support the inference of the same analytics information (also called ‘analytics ID’ ) . Further details of what may be comprised within the ‘preparation information’ is provided below.

[0168] At step S102 the second entity receives the request for training preparation and determines whether it can verify that it can support joint training, using VFL, with the first entity in dependence on the parameters and meta-information of the preparation information. Thus the second entity either responds, according to S104 to accept the VFL preparation, or rejects the VFL participation request S106 either based on non-supported VFL or non-supported VFL parametrisation. Since the first entity does not necessarily know (and indeed has no requirement to know) what ML model the second entity has access to in its MTLF, the first entity cannot predetermine whether or not the parametrisation needed by the VFL can be supported by the second entity’s ML model.

[0169] The training stage 402 may then commence in response to the first entity receiving acceptance of the VFL preparation at S104.

[0170] At S108 an indication is sent from the first entity to the second entity to commence training. In other words, the first entity provides a training-start indication to the second entity to initiate local training of the second ML model at the second entity. The second entity commences training at S110.

[0171] At S112 the first entity performs the local part of ML model training, i.e., training the first ML model, with a particular model objective. In response to training the first ML model, the first entity generates an output that may be referred to as a  first training output (or Active VFL ML Model Output Reporting) . At S114, the second entity performs local training of its own ML with the same model objective. As indicated at S116, in response to training the second ML model the second entity produces a training output, e.g., a ‘second training output’ (or Passive VFL ML Model Output Reporting) , and reports this second training output to the first entity.

[0172] At S118 the first entity analyses the first and second training outputs, using an objective loss function and training labels (where the training labels are preferably some form of ground truth data) , to generate updated ML information. Specifically, updated model information is generated for each separate ML model: i.e., in this case updated first ML model information for updating the first ML model (or Active VFL ML Model) and updated second ML model information (or Passive VFL ML Model) for updating the second ML model is generated. At step S120, the updated second ML model information for updating the second ML model is provided to the second ML model. In response to receiving the updating the second ML model, the second entity may update the parameters of its ML model using the updated second ML model information. Similarly, the first entity may update the parameters of its own first ML model using the updated first ML model information.

[0173] Only the first entity has access to the training labels since it is the active entity. Since the second entity is a passive entity it does not have access to the training labels, thus the second entity (and any other passive entities) cannot compute an objective loss and thus cannot generate updated ML model information. The second entity thus relies on the first entity to generate the updated ML model information.

[0174] As indicated in figure 4, steps S112, S114, S116, S118, and S120 are iterated as many times as needed to iteratively update the parameters of the first and second ML models. Phase 404 indicates the conclusion stage that takes place once the training is complete, including the steps taken to determine when the training is complete.

[0175] S122 comprises determining, at the first entity, that training is complete. Only the active entity has the capability to determine that training is complete since only the first entity has access to the training outputs of all passive entities (though in this case the second entity is the only passive entity) . Generally, determining whether training is complete comprises monitoring and / or evaluating a training progression. Evaluate the progression of the joint model training is generally based on calculating an objective loss using: i) the first training output; ii) the second training output (and any other training outputs from any other passive models partaking in the joint model training) and iii) training labels (e.g., ground truth data) configured to allow evaluation of ML models. In response to determining that the training progression of the joint model training meets a training completion threshold, the first entity may provide, at S124, a terminate-training indication to the second entity to initiate termination of local training of the second ML model at the second entity. In other words, the terminate-training indication confirms that the second entity may halt training of its second ML model, such that the ML model may be used for inference application based on the parameters that have been trained during the training stage 402.

[0176] Figure 5 illustrates a more detailed example of the 300A embodiment. Figure 5 illustrates an inter-PLMN training 306A between an active entity 506 and a passive entity 508. Only these two entities are shown, though it should be appreciated that, in general, at least one passive entity and at most one active entity may be involved in the joint model training. Thus, an arbitrary number of passive entities may simultaneously participate in the joint model training. Again, preferably and for the sake of the example in figure 5, the active entity and passive entity are NWDAFs. The embodiment described in 5 is based on extensions of the Nnwdaf_MLModelTraining service defined in TS 23.288 V18.3.0. In a different embodiment, it is possible that a new service is defined for the NWDAF only for carrying on the interactions among the MTLFs with VLF Capability defined in this disclosure to perform the exchange of information also defined in Figure 6.

[0177] Figure 5 does not describe the details of how the NWDAF (with MTLF) determines how it performs VFL-based model training and how it identifies other NWDAFs with MTLFs (i.e., other passive entities) that should participate in the joint model training. These details are out of the scope of this description: the figure 5 embodiment begins from the point where a MTLF with VFL Capability is aware that it will perform VFL-based model training with at least one other passive MTLF also having VFL Capability. As before, three phases are shown: the preparation phase 500, training phase 502, and the conclusion phase 504. It will be understood that ‘VFL-based training’ and ‘joint model training’ are used interchangeably in meaning throughout this specification and in the example of figure 5, and furthermore that “MTLF” may be used interchangeable with the term ‘entity’ throughout the specification and in respect of figure 5.

[0178] S200: The active entity 506, i.e., the NWDAF-MTLF with VFL Capability, is aware of the one or more MTLFs with VFL Capability and passive role to participate in the VFL-based training. The procedure in 5 shows only one MTLF (the passive entity 508) with passive role for simplicity.

[0179] In step S200, the active MTLF entity 506 ( ‘active MTLF entity’ or ‘active entity’ being a simplification for the term “NWDAF containing MTLF with VFL Capability and Active Role” ) determines and / or generates and / or obtains the one or more information related to the VFL ML model training preparation information to be used in the joint model training between the active 506 and (one or more) passive MTLFs 508. Preparation information is elsewhere referred to as ‘interoperability information’ . Examples of information that are related to the VFL ML model training preparation information are listed below (though not an exhaustive list) . This information may be determined by and / or available at the active MTLF 506 and / or obtained by the active MTLF entity 506 via interactions with other entities (NB: ‘passive MTLF’ or ‘passive entity’ is a simplification of the term “NWDAF containing MTLF with VFL capability and passive role” ) . S200 may comprise the following sub-steps (a) , (b) , (c) , and (d) :

[0180] (a) : The Active MTLF determines the VFL ML model unique identifier related to the Active VFL ML model information and (the one or more) passive VFL ML model information to be associated with the VFL training process between Active MTLF and Passive MTLF (s) . The active MTLF 506 can use the VFL related configuration for the given scenario of the VFL-based model training (e.g., intra-PLMN multi-vendor, inter-PLMN, intra-region as illustrated in figure 3) in order to determine the appropriate active VFL ML model information and passive VFL ML model information.

[0181] It is also possible that the active MTLF 506 obtains further identifiers for each specific active and passive ML models that are related to the same VFL-based training process. In this sense, the active MTLF 506 may determine the active ML model unique identifier and / or the passive ML model unique identifier. The active MTLF 506 keeps the mapping of the VFL ML model unique identifier to the active ML model unique identifier and the passive ML model unique identifier. In the case that more than one passive MTLF 508 is involved in the VFL-based joint training process, the active MTLF 506 also keeps the mapping of the VFL ML model unique identifier to the passive ML Model identifier and associated passive MTLF 508 identification.

[0182] It is possible that the Active MTLF does not determine the passive ML Model identifier, but obtains it via interactions with the passive MTLF 508 (for simplicity we abbreviate the term “one or more Passive MTLFs” ) as illustrated in S208 of figure 5.

[0183] In summary, the described embodiments allow for:

[0184] ● a single VFL ML model unique identifier to be associated with at least two different ML models comprising the VFL ML training process, i.e., the active ML Model and at least one passive ML model, or

[0185] ● a single VFL ML model unique identifier to be associated with an active ML model unique identifier -e.g., further associated with the active ML model -and (one or more) passive ML model unique identifier (s) –e.g., further associated with the (one or more) passive ML model (s) .

[0186] (b) : The active MTLF 506 determines and / or obtain and / or generates the Active Role Information and the Passive Role Information for the MTLFs (i.e., entities) participating in the VFL-based joint model training. According to different scenarios as described in figure 3, different VFL Role information will be more relevant to be associated with the active role information and one or more passive role information. For instance, if the solution is being applied to a multi-vendor VFL-based training, the vendor related information may be mandatory. If the inter-region in a single PLMN scenario is considered, the region related information associated with the MTLF may be mandatory. If the VFL-based training is being performed in an inter-PLMN scenario, the PLMN related information may then be mandatory.

[0187] The active MTLF 506 can use the VFL related configuration for the given scenario of the VFL-based model training (e.g., one of intra-PLMN multi-vendor, inter-PLMN, intra-region as illustrated in figure 3) in order to determine the appropriated active role information and passive role information.

[0188] It is also possible that the Active MTLF does not have the whole information related to the passive role information associated with at least one passive MTLF 508. In this case, it is possible that the active entity 506 defines only a subset of fields and / or information related to the passive role information and obtains the remaining information via interactions with the passive entity 508 (e.g., as illustrated in step S208) .

[0189] (c) The Active MTLF also defines and / or determine the VFL ML model requirements, e.g., the parameters defining the joint model training methodology, and / or the VFL ML model information to be associated with the VFL models (e.g., active VFL ML model and at least one passive ML model VFL) to be generated and / or resulting in the VFL-based training processes. The active MTLF can use the VFL related configuration for the given scenario of the VFL-based model training (e.g., intra-PLMN multi-vendor, inter-PLMN, intra-region as illustrated in figure 3) in order to determine the appropriated VFL ML model requirements and / or the VFL ML model information.

[0190] (d) It is possible that the MTLF with VFL Capability, in this case the active entity 506, is configured with a VFL-related configuration such as allowed and / or restricted: VFL ML model requirements and / or the VFL ML model information to be associated with the VFL Models and / or VFL ML model unique identifier, given the VFL Roles to be assumed by the MTLF with the VFL Capability and any other identified (passive) MTLFs taking part in the joint model training.

[0191] The following shows some examples of the VFL related configuration that the MTLFs with VFL Capability may use to determine the VFL ML model requirements and / or the VFL ML model information to be associated with the VFL Models, based on the VFL roles to be assumed by the MTLF with the VFL Capability and any other identified (passive) MTLFs taking part in the joint model training:

[0192] ● allowed and / or restricted analytics ID, with a given MTLF vendor and / or PLMN and / or PLMN region, with VFL ML model requirements and / or the VFL ML Model information;

[0193] ● allowed and / or restricted analytics ID analytics ID, with a given MTLF vendor and / or PLMN and / or PLMN Region, enable Active Role only, with VFL ML model requirements and / or the VFL ML model information;

[0194] ● allowed and / or restricted analytics ID, with a given MTLF vendor and / or PLMN and / or PLMN Region, use passive role only with VFL ML model requirements and / or the VFL ML model information;

[0195] ● allowed and / or restricted analytics ID, with a given MTLF vendor and / or PLMN and / or PLMN Region, use active and / or passive role with VFL ML model requirements and / or the VFL ML Model information.

[0196] It should be appreciated that the list of possible combinations of VFL-related configurations provided here is not exhausted. For example, further combinations of further configurations can be created when we consider for instance: fixing the MTLF vendor and / or PLMN and / or PLMN region and combing the possible roles for any analytics ID; fixing the role and combining possible MTLF vendor and / or PLMN and / or PLMN region for any analytics ID; fixing the VFL ML model requirements and combining it with possible MTLF vendor and / or PLMN and / or PLMN region.

[0197] In summary, the descried embodiment enables the active MTLF to keep the mapping of and / or the association of a VFL ML model unique identifier to one or more of the following information (e.g., VFL Training Context Information) :

[0198] ● VFL ML model requirements;

[0199] ● VFL ML model information;

[0200] ● active ML model unique identifier and / or at least one passive ML model unique identifier;

[0201] ● active role Information;

[0202] ● (list of) passive role information;

[0203] ● active ML model information;

[0204] ● subset of passive ML model information or passive ML model information.

[0205] S202: The MTLF with VFL capability and active role the active MTLF entity 506) provides the Nnwdaf_MLModelTraining_Subscribe request service operation to the NWDAF with VFL Capability and passive role i.e., the passive MTLF entity 508 (or invoke the service of all the involved passive entities) , including the VFL ML model training preparation indication (elsewhere called a ‘participation indication’ in this specification) . The VFL ML model training preparation indication is for instance a list of parameters related to the VFL information to be used by active and passive MTLF (s) . Such parameters can be based on the VFL ML model training preparation information determined by the active MTLF as well as further parameters that support the passive MTLF (s) to determine that the ML model training request is related to the VFL methodology for training. The VFL ML model training preparation indication can indicate a request for another MTLF to participate in the VFL-based training with the active MTLF.

[0206] In one possible embodiment, the VFL ML model training preparation indication comprises any one or more attribute selected from the following: ML Training methodology set to “VFL” , active role information (or parts of active role information) , passive role information, VFL preparation phase flag, VFL ML model unique identifier, VFL ML model requirements, VFL ML model information, active VFL ML model unique identifier, and optionally the passive ML model unique identifier associated with the passive MTLF.

[0207] When the active MTLF 506 does not include the passive ML model identifier in the invoked service, it is possible that the passive MTLF 508 will determine such identifier (as per S204) and provide it to the active MTLF 506, for instance as part of the response confirming the acceptance to participate in the VFL-based training (e.g., as indicated in S208) .

[0208] S204: The passive entity 508, based on the obtained VFL ML model training preparation indication and / or the VFL related configuration available at the passive MTLF, the passive MTLF verifies and / or determines whether it can accept the indication for participating in a VFL-based model training with the active MTLF.

[0209] As follows, one possible example is shown of how the passive MTLF determines whether it can accept the indication to participate in the VFL-based ML training based on the obtained information from the active entity and its own VFL-related configuration. The passive MTLF 508 checks the active role information received from the active MTLF 506 and the roles that it can assume when interacting with the MTLF defined in the VFL related configuration. If there is a match (e.g., if the entity that received the indication can perform the Passive role with the other MTLF as active) then the passive MTLF can accept the indication to participate in the VFL-based training. Further checks that can be performed are related to the VFL  ML model requirements and / or VFL ML model information, if the VFL ML model requirements and / or VFL ML model information defined in the VFL related configuration do not match the VFL ML model requirements and / or VFL ML model information indicated in the VFL ML model training preparation indication, the passive MTLF can reject the indication to participate in the VFL-based model training (shown in optional step S206) .

[0210] S208: The passive MTLF 508 using the Nnwdaf_MLModelTraining_Subscribe response service operation provides the response to the Active MTLF 506.

[0211] (optional) S206: In case the passive MTLF verified it cannot support VFL training methodology (e.g., it does not have the VFL Capability) or that it cannot support the requested parameters in the received indication from the first entity in S202, the passive MTLF includes in the response a rejection with the cause set to no VFL support or no support for requested VFL ML model training preparation indication. Optionally, the passive MTLF 508 could send to the active MTLF the exact one or more parameters of the request that are not supported by the passive MTLF.

[0212] S208: In case the passive MTLF verified it can support VFL training methodology (e.g., it has the VFL Capability) or that it can support the requested parameters in the received indication in S202, the passive MTLF includes in the response a confirmation of support for VFL request (or VFL-based training indication or VFL-based training request) .

[0213] When passive MTLF is able to determine the passive ML Model unique identifier, the passive MTLF can optionally provide it to the active MTLF, for instance as part of the response confirming the acceptance to participate in the VFL-based training.

[0214] Steps S202, S204, and S206 / S208 comprise the VFL preparation phase 500 in the VFL-based ML training.

[0215] S210: The preparation phase does not immediately trigger the MTLFs participating in the VFL-based training to actually start the training of the active ML model and at least the one passive ML Model. This is achieved with an indication from the active MTLF to one or more passive MTLFs associated with the same VFL ML model unique identifier. As S210, when the active entity 506 determines that the VFL-based model training should start, the active MTLF invokes the Nnwdaf_MLModelTraining_Subscribe request service operation from the passive MTLF including the VFL training-start indication.

[0216] S212: Based on the VFL training start indication received from the active MTLF 506, the passive MTLF 508 becomes aware that it should start the training processes for the passive ML Model associated with the VFL ML model unique identifier included in the received indication. The passive MTLF send a response using the Nnwdaf_MLModelTraining_Subscribe response service operation to the active MTLF including a VFL training start confirmation indication.

[0217] S214: Based on the VFL training start confirmation indication and the VFL training start indication, respectively, the active MTLF and the passive MTLF start the model training of the active ML Model and passive ML Model associated to the same VFL ML model unique identifier.

[0218] The actual computation executed by each entity (e.g., S2146a at the active MTLF 506 and S216 at the passive MTLF 508) in order to determine, respectively, the active VFL ML model output reporting (elsewhere called the ‘updated first ML model information’ ) and passive VFL ML model output reporting (elsewhere called the ‘updated second ML model information’ ) is based on respectively the active VFL ML model information and the passive VFL ML model information obtained by each MTLF / entity. The active and passive MTLFs will each execute their ML training process using the obtained information to generate the result or ML model output associated with, respectively, the active ML Model information and passive ML Model information.

[0219] S218: The passive MTLF provides to the active MTLF the passive VFL ML model output reporting using the Nnwdaf_MLModelTraining_Notify service operation.

[0220] S220: Based on Active VFL ML model output reporting and at least one passive VFL ML model output reporting, the active MTLF 506 determines that the VFL-based model training is not concluded and updates the active VFL ML Model information to be used by the active MTLF 506 and / or at least one passive VFL ML model information (or parts of the passive VFL ML model information) related to at least one other passive MTLF.

[0221] The active MTLF 506 may identify a different set of parameters that should be used in the next round of training for the active VFL ML model and / or the passive VFL ML model. The active MTLF determine which parameters of the active VFL ML model and / or passive VFL ML model should be changed.

[0222] For example, the active MTLF identify that different gradient values should be used by both models, or that a different partitioning of the input data should be applied. As a consequence, the active MTLF generates the updated active VFL ML model information and / or the updated passive VFL ML model information (or parts of the updated passive VFL ML model information) . It is considered in this example that the active MTLF 506 defines only parts of the passive VFL ML model information (or parts of updated passive VFL ML model information) , because the passive VFL ML model information, that the active MTLF is aware of, does not contain e.g., the information about the exact passive ML model configuration nor the reference point to retrieve such ML model being used by the passive MTLF.

[0223] S222: The Active MTLF provides to the Passive MTLF the updated Passive VFL ML Model Information using the Nnwdaf_MLModelTraining_Subscribe request service operation.

[0224] S224: The active MTLF stores the updated active VFL ML model information associated with the VFL ML model unique identifier as the newest information to be used for the next round of training of the active VFL model.

[0225] S226: The passive MTLF stores the updated passive VFL ML model information associated with the VFL ML model unique identifier as the newest information to be used for the next round of training of the passive VFL model.

[0226] It should be noted that S210 to S226 comprise the VFL training phase 502 in the VFL-based ML training. Additionally, steps S214, S216, S218, S220, S222, S224, and S226 may be repeatedly executed until the active MTLF 506 determines that the performance of the model training is sufficient to stop the training: in other words, when the active entity 506 determines that the progression of the joint model training has reached (e.g., is equal or has exceeded) a training completion threshold.

[0227] S228: The active MTLF determines that the joint model training is completed and that the active VFL Model and the passive VFL model have been sufficiently trained (e.g., to a training completion threshold) . One possible embodiment for such a determination is that the active MTLF computes the loss function related to the combined results and / or using the results of active VFL ML model output reporting and passive VFL ML model output reporting, and compares the results with the ground truth. When the performance of the model compared to the ground truth is considered adequate (e.g., the differences between combined results and / or both results aggregated and / or both results calculated together versus ground truth are within a satisfactory range of deviation) , the active MTLF determines that the VFL training is completed.

[0228] S230: The active MTLF provides to the passive MTLF the VFL training conclusion indication using the Nnwdaf_MLModelTraining_Subscribe request service operation.

[0229] S232: The active MTLF stores the latest active VFL ML model information and latest passive VFL ML model information associated with the VFL ML model unique identifier as the final parametrization associated with the generated active VFL ML model and associated passive VFL ML model generated by the passive MTLF.

[0230] S234: The passive MTLF stores the latest passive VFL ML model information associated with the VFL ML model unique identifier as the final parametrization associated with the generated passive VFL ML model.

[0231] The ‘preparation information’ , also called ‘interoperability information’ , sent by the first entity at step S100, for VFL ML model training preparation may comprise any one or more attribute or meta-information selected from the following:

[0232] a) VFL ML Model unique identifier;

[0233] b) Active VFL ML model unique identifier;

[0234] c) Passive VFL ML model unique identifier;

[0235] d) VFL ML model requirements;

[0236] e) VFL ML model information;

[0237] f) VFL Preparation Flag

[0238] g) Active role information;

[0239] h) (list of) passive role information for each passive entity participant.

[0240] These definitions may have the following characteristics:

[0241] VFL Preparation Flag is a flag indicating that the exchange of information between Active and Passive MTLFs is related to the configuration and / or definition of the parametrization for performing the VFL-based training.

[0242] VFL Role Information defines information about a VFL participant in the VFL-based training process. It may comprise one or more attributes selected from the following list: VFL Role Type (e.g., Active or Passive or Broker or Active Broker or Passive Broker) ; NF identification (e.g., NF ID of the NWDAF with MTLF participating in the VFL-based training process) ; NF Set identification (e.g., NF Set ID of the NWDAF with MTLF) ; Mobile network identification (e.g., PLMN ID) ; Identification of region in mobile network (e.g., Intra-region PLMN ID) where the NWDAF is located; NWDAF Location information (e.g., identification or spatial description the area where the NWDAF is located and / or deployed) ; NWDAF Serving Area Information (e.g., information identifying the area or location in the mobile network that is served by the NWDAF) ; NWDAF provider or Vendor identification of MTLF (e.g., Vendor ID) ; Vendor information (e.g., Name Description, and / or Description of NWDAF product, and / or Supported 3GPP Release) .

[0243] Active Role Information defines the VFL Role Information for a MTLF associated with the Active VFL Role type (e.g., the first entity) .

[0244] Passive Role Information defines the VFL Role Information for a MTLF associated with the Passive VFL Role type (e.g., the second entity)

[0245] VFL ML model Requirements defines the one or more attributes indicating the characteristics and / or methodology to be used for the joint training of the active ML Model and the at least one passive ML model. It can be also understood as the information to be used by the at least one passive MTLF to enable the active ML model and passive ML model to have their output aggregated. The VFL ML model requirements may comprise either or both of the following attributes: ML Model cooperation indication (i.e., differentiable ML Model so that the Active / passive NWDAF know that each could operate over  different parts of the ML Model for the joint training) ; Type of output (integer –e.g., result of classification; continuous –e.g., result of regression) .

[0246] VFL ML Model information defines the ‘meta-information’ associated with the various ML models (i.e., the one active VFL ML model and the at least one passive VFL ML model) where the ML models are related to the same analytics ID being jointly trained by the active and passive entities. This meta-information may also define the objective to be used by both ML models (e.g., the analytics ID and / or filter information and / or target information to be considered by both models) and / or the alignment information that defines the responsibilities of each model related to the joint model training. VFL ML Model information may comprise one or more attributes selected from the following list: analytics ID; ML Model Filter Information; ML Model Target or Reporting; Gradients information; Partitioning of ‘analytics ID input data’ between the Active MTLF and at least one Passive MTLF (where the analytics ID input data indicates the expected ML model partitioning, e.g., defining which feature types may be shared) ; Alignment Information for Analytics ID associated with both ML models related to the VFL participants (e.g., application related information, identification of UEs, Data Network related information, slice information, QoS related information, and the like) .

[0247] Figure 6 shows a schematic of the VFL process. Figure 6 illustrates which data elements and which functions belong to which entity. The subscripts ‘H’ and ‘V’ are used to denote home and visiting entities in a HRR scenario. Thus, elements and features with an ‘H’ subscript are private to the ‘home’ entity and elements and features with a ‘V’ subscript are private to the visiting entity. The left-hand processes 600 denote the ‘forward pass’ in which the objective loss is computed. The right-hand processes 602 denote the ‘backward pass’ in which the updated model information is generated and the respective models locally update their parameters. The following table describes the meaning of each element and function.

[0248] Figure 7 illustrates an overview related to the 300B set of embodiments, and in particular relates to the 302B embodiment. Here, the NWDAFs with VFL capability cannot directly exchange information necessary to perform the joint model training of the ML models. Thus, the entities instead use an NF with a further entity that performs a mediator role: the mediator entity having VFL Broker Capability. Additionally, this embodiment also considers that a single NF with VFL Broker Capability is used between the NWDAFs with VFL Capability. Depending on the scenario the actual NF that is extended with the VFL Broker Capability can change depending on circumstances. For instance, in a scenario of multi-vendor NWDAFs within the same operator, the operator may decide to enhance the NEF with the VFL Broker Capability. In scenarios where analytics aggregation is expected, the NF enhanced with VFL Broker Capability can be a NWDAF.

[0249] The steps of the 300B set of embodiments can be partitioned into the preparation phase 706, the training phase 708, and the conclusion phase 710. The entities involved in the 302B set of embodiments involve a first entity 700 (NWDAF-MTLF With VFL Capability and Active VFL Role) , a second entity 702 (NWDAF with VFL Capability and Passive VFL Role) and a broker entity 704 (NF with VFL Broker Capability (e.g., NEF, NWDAF) ) .

[0250] Most of the steps related to the NWDAF with VFL Capability and Active VFL Role and the NWDAF with VFL Capability and Passive VFL Role are equivalent to the steps of the preparation phase described in the 300A embodiments. For simplicity we refer to the foregoing description when applicable and in the following part of the present disclosure new details related to the NF with VFL Broker Capability are considered.

[0251] Although it is not shown, the same procedure, interactions, and information exchange can be applied for the following combination of entities performing VFL in mobile networks:

[0252] ● NWDAF with MTLF with active role; NEF or NWDAF with VFL Broker Capability; AF (s) with passive role

[0253] ● AF with active role; NEF or NWDAF with VFL Broker Capability; NWDAF with passive role;

[0254] Figure 8 shows in more detail the preparation phase 706 of the 302B embodiment in which NWDAFs with VFL capability cannot directly exchange information necessary to perform the joint model training of the ML models.

[0255] S300: The MTLF with VFL Capability and active role 700 is aware of the one or more MTLFs with VFL Capability and passive role to participate in the VFL-based training. The procedure in figure 8 shows only one MTLF with passive role 702 for simplicity. In the present disclosure it is assumed that the MTLF with VFL Capability and active role 700 is aware that it cannot directly interact with the other (s) MTLF (s) with VFL Capability and passive role 702 and that instead it should interact via a NF with VFL Broker Capability 704. We also assume that the MTLF with active VFL role (aka, MTLF with VFL Capability and active role) is aware of which NF with VFL Broker Capability should be used in the procedure (e.g., it discovered the appropriated NF with VFL Broker Capability associated with the one or more MTLFs with passive VFL roles) .

[0256] S302: instead of invoking the Nnwdaf_MLModelTraining_Subscribe request service operation from the NWDAF with VFL Capability and passive role –Passive MTLF –the Active MTLF (e.g., The MTLF with VFL Capability and Active Role) invoke the service exposed by the NF with VFL Broker Capability.

[0257] Figure 8 presents one possible embodiment of this service called Nnwdaf_BrokerTraining considering the NWDAF with a VFL Broker Capability. However, if NEF would be the NF with VFL Broker Capability, it is possible that the service to be  invoked is called Nnef_BrokerTraining. In another embodiment, if the interaction among the training entities involved NWDAFs from different operators for supporting roaming scenarios, it is possible that the service is called Nnwdaf_RoamingTraining. Despite the different names and entities (e.g., NFs) that may have the VFL Broker Capability, the same information exchanged in S202 of figure 5 is also exchanged in this step.

[0258] S304: The NF with VFL Broker Capability 704 based on the obtained VFL ML Model Training Preparation indication and / or the VFL Broker related configuration available at the NF with VFL Broker Capability, verifies and / or determines whether it can accept the indication for participating as an intermediary entity between the active and one or more entities performing VFL-based model training. The NF with VFL Broker Capability can be configured with the VFL Broker related configuration, such as allowed and / or restricted: VFL ML model Requirements and / or the VFL ML Model information to be associated with the VFL Models and / or VFL ML model unique identifier, given the VFL Roles of the MTLF (s) with the VFL Capability involved in the joint training process to be intermediated by NF with VFL Broker Capability. Similarly, to the VFL related configurations, the VFL Broker related configuration can be implemented in different ways where the NF with VFL Broker capability may have a VFL interoperability List and / or VFL Inter-PLMN list and / or VFL Intra-Region list definition between which NFs with VFL Capability that such NF with VFL Broker Capability is allowed to support in the joint ML model training. In case the NF with VFL Broker Capability identifies it cannot support the interaction among the entities with active and passive roles in the joint model training, the NF with VFL Broker Capability can send a rejection message with the indication of no support for the requested interaction indicated in the message of S302. The NF with VFL Broker Capability follows the same logic described in S204 of Figure 5 to determine if it can accept to be the intermediary entity among NFs performing joint model training.

[0259] S306: (Optional) The NF with VFL Broker Capability 704 may be configured to perform some processing over the obtained VFL ML Model Training Preparation indication before further interacting with the one or more passive entities in the VFL and / or joint model training. For instance, the NF with VFL Broker Capability may be configured to perform mapping of information and / or anonymization of information. For instance, if the scenario is inter-PLMN VFL (e.g., in case of preparing ML models for supporting the analytics for roaming scenarios) the NF with VFL Broker Capability may map information received from the NWDAF-MTLF with active VFL role into information that is understood by the NWDAF-MTLF with passive VFL role in a different PLMN. For instance, it can map the slice identification (e.g., S-NSSAI) received in the information comprised in the VFL ML Model Training Preparation indication into the mapped slice identification associated with the PLMN where the NWDAF-MTLF with passive role belongs.

[0260] S308: The NF with VFL Broker Capability 704 determines the proper NWDAF-MTLF with passive VFL role to interact based on local policies (e.g., that could also be comprised and / or related to the VFL Broker related configuration) and / or based on the VFL ML Model Training Preparation indication. The NF with VFL Broker Capability invokes the Nnwdaf_MLModelTraining_Subscribe request service operation from the NWDAF with VFL Capability and passive role –Passive MTLF - (or invoke the service of all the involved Passive MTLFs) , including the VFL ML Model Training Preparation indication. The subscription can include either the exact information comprised in VFL ML Model Training Preparation indication received from the Active MTLF (e.g., MTLF with VFL Capability and Active Role) –in this case the NF with VFL Broker Capability forwards the information to the Passive MTLF –or it can include a processed and / or updated VFL ML Model Training Preparation indication received from the Active MTLF, for instance, if any mapping of information have been executed.

[0261] S310: Based on the obtained VFL ML Model Training Preparation indication and / or the VFL related configuration available at the Passive MTLF, the Passive MTLF verifies and / or determines whether it can accept the indication for  participating in a VFL-based model training (aka, joint model training) with the indicated Active MTLF and / or NF with VFL Broker Capability. The Passive MTLF can use the same logic described in S204 of Figure 5.

[0262] S312: 7 (a) In case the Passive MTLF verified and / or determined it cannot support VFL training Methodology (e.g., it does not have the VFL Capability) or that it cannot support the requested parameters in the received indication in Step 5, the Passive MTLF includes in the response a rejection with the cause set to no VFL Support or no support for requested VFL ML Model Training Preparation indication. Optionally, the passive MTLF could send to the NF with VFL broker capability the exact one or more parameters of the request that are not supported by the passive MTLF.

[0263] S314: 7 (b) The NF with VFL Broker Capability forward the rejection indication to the Active MTLF using the Nnwdaf_BrokerTraining_Subscribe Response service to inform the Active MTLF about the decision of the one or more Passive MTLFs. It is possible that the rejection is also stored at the NF with VFL Broker Capability.

[0264] S316: 8 (a) In case the Passive MTLF verified it can support VFL training Methodology (e.g., it has the VFL Capability) or that it can support the requested parameters in the received indication in Step 5, the Passive MTLF includes in the response a confirmation of support for VFL request (or VFL-based training indication or VFL-based training request) .

[0265] S318: 8 (b) The NF with VFL Broker Capability forward the indication to the Active MTLF using the Nnwdaf_BrokerTraining_Subscribe Response service to inform the Active MTLF about the decision of the one or more Passive MTLFs. Additionally, the NF with VFL Broker Capability also stores the mapping of the Passive MTLFs that are actively participating in the joint model training with the Active MTLF. For example, the NF VFL Broker Capability may define a specific identifier that is provided to all the entities participating in the same joint model training, as the mechanism for establishing and / or managing and / or maintaining such mapping.

[0266] Figure 9 shows Steps for performing the training phase 708 illustrated in Figure 7. In this case, the NF with VFL Broker Capability acts as a forwarder of information and / or an intermediary entity exchanging the information between the Active MTLF and the one or more Passive MTLFs associated with the same joint model training process.

[0267] S400: The preparation phase does not immediately trigger the MTLFs participating in the VFL-based training to actually start the joint training of the Active ML model and at least the one Passive ML Model. This is achieved with an indication from the Active MTLF to one or more Passive MTLFs associated with the same VFL ML model unique identifier. When Active MTLF determines that the VFL-based model training should start, the Active MTLF invokes the Nnwdaf_brokerTraining_Subscribe request service operation from the NF with VFL Broker Capability including the VFL Training Start Indication.

[0268] S402: The NF with VFL Broker Capability, based on the received VFL Training Start Indication and / or the local information associating the one or more Passive MTLFs to the same Active MTLF, identify the Passive MTLFs that it needs to forward the information received from the Active MTLF. The NF with VFL Broker Capability invokes the Nnwdaf_MLModelTraining_Subscribe request service operation from the associated Passive MTLF including the received VFL Training Start Indication.

[0269] S404: Based on the VFL Training Start Indication received from the NF with VFL Broker Capability, the Passive MTLF becomes aware that it should start the training processes for the Passive ML Model associated with the VFL ML Model unique identifier included in the received indication. The Passive MTLF send a response using the  Nnwdaf_MLModelTraining_Subscribe response service operation to the NF with VFL Broker Capability including a VFL Training Start Confirmation Indication.

[0270] S406: The NF with VFL Broker Capability forward the received VFL Training Start Confirmation Indication to the Active MTLF.

[0271] S408: Based on the VFL Training Start Confirmation Indication and the VFL Training Start Indication, respectively, the Active MTLF and the Passive MTLF start the model training of the Active ML Model and Passive ML Model associated to the same VFL ML model unique identifier. The actual computation executed by each MTLF (e.g., step S408 in Active MTLF and step S410 in Passive MTLF) in order to determine, respectively, the Active VFL ML Model Output Reporting and Passive VFL ML Model Output Reporting is based on respectively the Active VFL ML Model Information and the Passive VFL ML Model Information obtained by each MTLF. The Active and Passive MTLFs will each execute their ML training process using the obtained information to generate the result or ML model output associated with, respectively the Active ML Model information and Passive ML Model information.

[0272] S412: The Passive MTLF provides to the NF with VFL Broker Capability the Passive VFL ML Model Output Reporting using the Nnwdaf_MLModelTraining_Notify service operation.

[0273] S414: The NF with VFL Broker Capability provides to the Active MTLF the Passive VFL ML Model Output Reporting received from the Passive MTLF using the Nnwdaf_BrokerTraining_Notify service operation.

[0274] S416: Based on Active VFL ML Model Output Reporting and at least one Passive VFL ML Model Output Reporting, the Active MTLF determine that the VFL-based model training is not concluded and updates the Active VFL ML Model information to be used by the Active MTLF and / or at least one Passive VFL ML Model information (or parts of the Passive VFL ML Model Information) related to at least one other Passive MTLF.

[0275] S418: The Active MTLF provides to the NF with VFL Broker Capability the updated Passive VFL ML Model Information using the Nnwdaf_BrokerTraining_Subscribe request service operation.

[0276] S420: The NF with VFL Broker Capability provides to the Passive MTLF the updated Passive VFL ML Model Information using the Nnwdaf_MLModelTraining_Subscribe request service operation.

[0277] S422: 11 (a) The Active MTLF stores the updated Active VFL ML Model Information associated with the VFL ML Model unique identifier as the newest information to be used for the next round of training of the Active VFL Model.

[0278] S424: 11 (b) The Passive MTLF stores the updated Passive VFL ML Model Information associated with the VFL ML Model unique identifier as the newest information to be used for the next round of training of the Passive VFL Model.

[0279] Figure 10 describes in detail the Steps for performing the Conclusion Phase illustrated in Figure 7. In this example, the NF with VFL Broker Capability also acts as a forwarder of information and / or an intermediary entity exchanging the information between the Active MTLF and the one or more Passive MTLFs associated with the same joint model training process.

[0280] S500: The Active MTLF determines that the VFL Training (e.g., joint model training) is Completed.

[0281] S502: The Active MTLF provides to NF with VFL Broker Capability the VFL Training Conclusion Indication using the Nnwdaf_BrokerTraining_Subscribe request service operation.

[0282] S504: The NF with VFL Broker Capability provides to the Passive MTLF the received VFL Training Conclusion Indication using the Nnwdaf_MLModelTraining_Subscribe request service operation.

[0283] S506: 4 (a) The Active MTLF stores the latest Active VFL ML Model Information and latest Passive VFL ML Model Information associated with the VFL ML Model unique identifier as the final parametrization associated with the generated Active VFL ML Model and associated Passive VFL ML Model generated by the Passive MTLF.

[0284] S508: 4 (b) The Passive MTLF stores the latest Passive VFL ML Model Information associated with the VFL ML Model unique identifier as the final parametrization associated with the generated Passive VFL ML Model.

[0285] Although it is not explicitly detailed mention in the present disclosure, except for forwarding and / or sending the information between the Active MTLF and one or more Passive MTLFs, the NF with VFL Broker Capability generally checks the mapping of the participants of the same joint model training and forwards and / or send the information to the entities participating in the same joint model training process.

[0286] Figures 11, 12, and 13 pertain to embodiments in which the NWDAFs with VFL Capability cannot directly communicate (e.g., exchange the information necessary to perform the joint training of the ML models) and use instead a NF with the VFL Broker Capability. Such examples are outlined in figure 3 as embodiments 304B and 306B. Furthermore, the 304B and 306B also consider the case where a single NF with VFL Broker is not possible to be used. For instance, one scenario where a single VFL Broker cannot be used is the one in roaming analytics. As per TS 23.288 R18, only RE-NWDAFs are able to communicate with each other for carrying on analytics related actions. Therefore, following the principles of architecture in NWDAF, the joint model training among NWDAF-MTLFs from different operators would require that each NWDAF-MTLF to interact with a RE-NWDAF with VFL Broker Capability and the RE-NWDAFs with VFL Broker Capability from each operator would then interact in order to exchange and / or forward the joint model training messages between the Active and Passive MTLFs.

[0287] Figures 11, 12, and 13 illustrate the procedures respectively for preparation phase, training phase, conclusion phase. The actions and / or tasks executed in each step are equivalent to the similar steps already described in the 302B example with a single VFL Broker. The difference of this embodiment is the existence of one NF with VFL Broker Capability associated with the Active MTLF (for simplicity we refer to NF with Active VFL Broker Capability) and another NF with VFL Broker associated with the Passive MTLF (for simplicity we refer to NF with Passive VFL Broker Capability) .

[0288] Figure 11 shows in detail the steps for performing the preparation phase for the 304B and 306B examples.

[0289] S600, S602, S604, S606: The same as steps S300, S302, S304, S306 in figure 8.

[0290] S608: This is the same as step S308 in Figure 8, with the difference that the NF with VFL Broker Capability determines the proper NF with VFL Broker Capability and passive VFL role to interact based on local policies (e.g., that could also be comprised and / or related to the VFL Broker related configuration) and / or based on the VFL ML Model Training Preparation indication.

[0291] S610 and S612: The same as S304 and S306 in figure 8 with the difference that the entity performing the actions is the NF with VFL Broker Capability and passive VFL role.

[0292] S614 and S616: The same as S308 and S310 in figure 8, with the difference that the entity is the NF with VFL Broker Capability and Passive Role interacting with the Passive MTLF.

[0293] S618, S620, S622, S624, S626, S628: Illustrate the forwarding of the information generated by the Passive MTLF until the Active MTLF through the intermediary entities.

[0294] Figure 12 describes in detail the steps for performing the training phase 708 for the 304B and 306B examples.

[0295] All the steps of this method (S700, S702, S704, S706, S708, S710, S712, S714, S716, S718, S720, S722, S724, S726, S728, S730) are the same as the steps described in respect of figure 9. The only difference is that in steps S402, S406, S414, and S420 of figure 9 there is another level of forwarding in figure 12 between the two NF with VFL Broker Capability.

[0296] Figure 13 describes in detail the steps for performing the conclusion phase for the 304B and 306B examples.

[0297] S800, S802, S804, S806, S808, S810: The steps are the same as S500, S502, S504, S506, S508, in Figure 10. The difference is that in S502 of figure 10 there is another level of forwarding in figure 13 (i.e., S802 and S804) between the two NF with VFL Broker Capability.

[0298] Definitions

Claims

1.A first entity configured to generate network analytics information in a mobile communication network, wherein the first entity comprises a first machine learning, ML, model, the first entity being configured to execute joint model training of the first ML model and a second ML model comprised within a second entity, the second entity being configured to generate network analytics information in a mobile communication network, the joint model training characterised in that:the first ML model and the second ML model have the same model objective, and wherein the first ML model is a different ML model to the second ML model;wherein the first entity is configured to execute the joint model training by:training the first ML model locally at the first entity to obtain a first training output;providing a joint model training indication to the second entity, wherein the joint model training indication is an indication to initiate local training of the second ML model at the second entity and / or is an indication for the second entity to associate the second ML model at the second entity with the first ML model at the first entity;receiving, from the second entity, a second training output obtained at the second entity;generating updated first ML model information for updating the first ML model and updated second ML model information for updating the second ML model based on analysis, by the first entity, of the first training output and the second training output.2.The first entity as claimed in claim 1, wherein the first entity is further configured to associate a joint training ML identification, ID, to the first ML model and to the at least one second ML model.3.The first entity according to any preceding claim, wherein the first entity is further configured to execute the joint model training with an active role, wherein the active role defines that an entity that is associated with: the first ML model, the first training output, the second ML model, the second training output, and information to evaluate a performance of the joint model training.4.The first entity according to any preceding claim, wherein the joint model training indication is an indication for the second entity to associate the second ML model at the second entity to the first ML model at the first entity, and further indicates a request for the second entity to participate in the joint model training.5.The first entity as claimed in any preceding claim, wherein the first entity is further configured to determine the joint model training indication based on a joint model training configuration available at the first entity, wherein the joint model training configuration defines parameters for the first entity for executing the joint model training.6.The first entity according to claim 5, wherein the parameters for executing joint model training comprise any one or more of the following:- information defining which roles the first entity and / or the second entity are allowed to have and / or restricted from having in the joint model training; and- one or more machine learning requirements allowed and / or restricted to be associated with the first ML model and / or second ML model in the joint model training; and- one or more alignment information allowed and / or restricted for the joint model training.7.The first entity according to any preceding claim, wherein the joint model training indication further comprises any one or more of the following:- a flag indicating a type of training defining the joint model training;- role information of the first entity and / or second entity in the joint model training;- joint training ML ID;- identification of the first ML model and / or identification of second ML model;- a flag indicating a preparation of the joint model training;- a flag indicating to start the joint model training;- one or more machine learning requirements to be used in the joint model training of the first ML model and / or second ML model;- one or more alignment information to be used for the joint model training;- information about second ML model or partial set of information about ML model;- information about first ML model.8.The first entity as claimed in any preceding claim, wherein the first entity is further configured to obtain a participation confirmation from the second entity indicating either: that the first entity can execute the joint model training of the first ML model and the second ML model.9.The first entity as claimed in any preceding claim, wherein the first entity is further configured to map joint training ML ID to information defining the joint model training.10.The first entity as claimed in claim 9, wherein the information defining the joint model training comprises any one or more of the following:- information defining parameters and entities involved in the joint model training executed by the first entity;- identification of the first ML model and / or identification of second ML model;- one or more alignment information to be used for the joint model training;- information defining the second ML model or a subset of information defining the ML model;- information defining the first ML model.11.The first entity as claimed in claim 9 or 10, wherein the first entity is further configured to update the information defining the joint model training based on the updated first ML model information and / or the updated second ML model information.12.The first entity as claimed in any preceding claim, wherein the first entity is configured to determine a conclusion of the joint model training of the first ML model and the second ML based on analysing the first training output and the second training output and / or based on local configurations of the first entity and / or the second entity.13.The first entity as claimed in claim 12, wherein the first entity is configured to determine the conclusion of the joint model training based on calculating an objective loss using: i) the first training output; ii) the second training output and iii) training labels configured to allow evaluation of ML models.14.The first entity as claimed in any preceding of claim, wherein the first entity is configured to provide a terminate-training indication to the second entity to initiate termination of local training of the second ML model at the second entity.15.The first entity as claimed in any preceding claim, wherein the first entity is configured to provide i) the updated second ML model information and ii) a model-update indication to the second entity to initiate updating of the second model at the second entity using the updated second ML model information.16.The first entity as claimed in any preceding claim, wherein the joint model training of the first and second ML models executed by the first entity comprises vertical federated learning, VFL.17.The first entity as claimed in any preceding claim, wherein the first entity and the second entity belong to the same mobile communication network, and wherein the first entity is associated with a first network vendor and the second entity is associated with a second network vendor.18.The first entity as claimed in any preceding claim, wherein the first entity and the second entity belong to the same mobile communication network, and wherein the first entity manages network communications for a first region and the second entity manages network communications in a second region different to the first region.19.The first entity as claimed in any of claims 1 to 16, wherein the first entity belongs to a first mobile communication network and the second entity belongs to a different, second, mobile communication network, wherein the first ML model is configured to predict a service experience for a user equipment, UE, performing HRR between the first and second mobile communication network.20.The first entity as claimed in any preceding claim, wherein each of the first entity and the second entity is a network data analytics function, NWDAF, comprising a model training logical function, MTLF.21.A method of joint model training performed by a first entity, the first entity configured to generate network analytics information in a mobile communication network, the first entity comprising a first machine learning, ML, model, and the first entity being configured to execute joint model training of the first ML model and a second ML model comprised within a second entity, the second entity being configured to generate network analytics information in a mobile communication network, the method comprising:training the first ML model locally at the first entity to obtain a first training output;providing a joint model training indication to the second entity, wherein the joint model training indication is an indication to initiate local training of the second ML model at the second entity and / or is an indication for the second entity to associate the second ML model at the second entity with the first ML model at the first entity;receiving, from the second entity, a second training output obtained at the second entity;generating updated first ML model information for updating the first ML model and updated second ML model information for updating the second ML model based on analysing the first training output and the second training output,wherein the first ML model and the second ML model have the same model objective and wherein the first ML model is a different ML model to the second ML model.22.A second entity configured to generate network analytics information in a mobile communication network, the second entity comprising a second machine learning, ML, model, the second entity being configured to participate in joint model training of the second ML model and a first ML model comprised within a first entity, the first entity being configured to generate network analytics information in a mobile communication network, the joint model training characterised in that:the first ML model and the second ML model have the same model objective, and wherein the first ML model is a different ML model to the second ML model;wherein the second entity is configured to participate in the joint model training by:receiving a joint model training indication from the first entity, wherein the joint model training indication is an indication to initiate local training of the second ML model at the second entity and / or is an indication for the second entity to associate the second ML model at the second entity to the first ML model at the first entity;based on the joint model training indication, initiating local training of the second ML model at the second entity to obtain a second training output;providing the second training output to the first entity.23.The second entity as claimed in claim 22, wherein the second entity determines it can participate in the joint model training based on the obtained joint model training indication and / or based on joint model training configuration available at the second entity, where the joint model training configuration defines parameters for the second entity to participate in the joint model training.24.The second entity according to claim 23, wherein the parameters for executing joint model training comprise any one or more of the following:- information defining which roles the second entity is allowed to have in the joint model training; and- one or more machine learning requirements allowed and / or not allowed to be associated with second ML model in the joint model training; and- one or more alignment information allowed and / or restricted for the joint model training.25.The second entity according to any of claims 22 to 24, wherein the joint model training indication further comprises any one or more of the following:- a flag indicating a type of training defining the joint model training;- role information of the first entity and / or second entity in the joint model training;- joint training ML ID;- identification of the first ML model and / or identification of second ML model;- a flag indicating a preparation of the joint model training;- a flag indicating to start the joint model training;- one or more machine learning requirements to be used in the joint model training of the first ML model and / or second ML model;- one or more alignment information to be used for the joint model training;- information about second ML model or partial set of information about ML model;- information about first ML model.26.The second entity as claimed in any of claims 22 to 25, wherein the joint model training indication comprises joint training ML identification, ID, and wherein the second entity associates the second ML model to the joint model training associated with the first ML model by mapping the obtained joint training ML ID to an identification of the second ML model at the second entity.27.The second entity as claimed in claim 26, wherein the second entity is further configured to map the obtained joint training ML ID to local information defining the second ML model at the second entity.28.The second entity as claimed in any of claims 22 to 27, wherein the second entity is further configured to receive from the first entity updated second ML model information for updating the second ML model and / or a model-update indication indicating that the second entity should update the second ML model.29.The second entity as claimed in claim 28, wherein the second entity is configured to update parameters of the second ML model using the updated second ML model information.30.The second entity as claimed in any of claims 22 to 29, wherein the second entity is configured to receive, from the first entity, a terminate-training indication and based on the terminate-training indication to terminate local training of the second ML model.31.The second entity as claimed in any of claims 22 to 30, wherein the joint model training of the first ML model and the second ML model entity comprises vertical federated learning, VFL.32.A method of joint model training being performed by a second entity, the second entity configured to generate network analytics information in a mobile communication network, the second entity comprising a second machine learning, ML, model, and the second entity being configured to participate in joint model training of the second ML model and a first ML model comprised within a first entity, the first entity being configured to generate network analytics information in a mobile communication network, the method comprising:receiving a joint model training indication from the first entity, wherein the joint model training indication is an indication to initiate local training of the second ML model at the second entity and / or is an indication for the second entity to associate the second ML model at the second entity to the first ML model at the first entity;based on receiving the joint model training indication, initiating local training of the second ML model at the second entity to obtain a second training output;providing the second training output to the first entity; andreceiving, from the first entity, updated second ML model information for updating the second ML model,wherein the first ML model and the second ML model have the same model objective and wherein the first ML model is a different ML model to the second ML model.33.The method of claim 32, wherein the participating in the joint training by the second entity is performed without accessing information defining the first ML model configuration and without transferring information defining a configuration of the second ML model to the first entity.34.A method of executing joint model training of a first machine learning, ML, model at an active entity with one or more further ML models at one or more respective passive entities, wherein the active entity and the one or more passive entities are configured to generate network analytics information in one or more mobile communication networks, the method comprising:training the first ML model locally at the active entity to obtain a first training output;providing a joint model training indication to the one or more passive entities to initiate local training of respective one or more further ML models at the respective one or more passive entities;receiving, from the one or more passive entities, one or more further training outputs obtained at the respective one or more passive entities;generating updated first ML model information for updating the first ML model and one or more updated further ML model information for updating the one or more further ML models based on analysing, at the active entity, the first training output and the one or more further training outputs,wherein the first ML model and the one or more further ML models have the same model objective, and wherein the first ML model is a different ML model to each of the one or more further ML models.35.The method of claim 34, wherein the execution of the joint model training is performed without the active entity sharing information defining the first ML model configuration with any of the one or more ML models and without the active entity accessing information defining configurations of any of the one or more further ML models.36.The method of claim 34 or 35, further comprising updating, at the active entity, parameters of the first ML model using the updated first ML model information.37.The method of any of claims 34 to 36, wherein the active entity is configured to evaluate a progression of the joint model training based on calculating an objective loss using: i) the first training output; ii) the one or more further training output and iii) training labels configured to allow evaluation of ML models.38.The method as claimed in claim 37, wherein the active entity is configured to determine a conclusion of the joint model training based on an evaluated progression of the joint model training, and to provide a terminate-training indication to the one or more further entities to initiate termination of local training of the further ML models at each of the one or more further entities.39.A computer program comprising a program code for performing the method according to any of claims, 21, and 32 to 38, when executed on a computer.

Images