Vertical federated learning feature and sample alignment

Abstract

A method for vertical federated learning (VFL) in a wireless communications system, the system comprising a VFL server and one or more VFL clients (e.g. AFs or NWDAFs), the method comprising: transmit

Description

Field Certain examples of the present disclosure provide various techniques relating to Vertical Federated Learning feature and sample alignment, for example within 3rd Generation Partnership Project (3GPP) 5th Generation (5G) New Radio (NR) and NR-based relay networks. BACKGROUND Description of the Related Art FL Support at NWDAF In current SA2 specifications, the Federated Learning (FL) among multiple NWDAFs (so called Horizontal Federated Learning (HFL)) has been supported since 3GPP Rel-18. High-level and detailed descriptions of supporting FL among multiple NWDAFs are mainly documented in clause 5.3 and clause 6.2c of TS 23.288. In Rel-16, a single instance or multiple instances of NWDAF may be deployed in a Public Land mobile network (PLMN). In a case where multiple NWDAF instances are deployed, the architecture supports deploying the NWDAF as a central Network Function (NF), as a collection of distributed NFs, or as a combination of both. When multiple NWDAFs exist, not all of them need to be able to provide the same type of analytics results. However, no specific requirement has been defined regarding how different NWDAFs could cooperate in Rel-16. In Rel-16, each NWDAF acts independently from the other NWDAFs. In reality, some of the NWDAFs in one network may be providing the same type of analytics, and so may help each other, for example specific analytics for specific target User Equipments (UEs) or specific analytics for a specific area of interest. Although some of these NWDAFs may be providing different type of analytics, they may still be able to help each other if, e.g., the analytics are somehow related: one example is for expected UE behavioural parameters related network data analytics, which have a tight relationship with UE mobility analytics and UE communication analytics. In another example, in orderto build abnormal behaviour related network data analytics, the NWDAF would need to collect similar types of data to the data needed to build analytics for UE mobility patterns and for UE communication patterns. In order to address the coordination among multiple NWDAFs for FL, Rel-18 study and normative work were carried out by SA2. This is documented in clause 5.3 of TS 23.288: FL among multiple NWDAFs is a machine learning technique in a core network that trains an Machine Learning (ML) model across multiple decentralized entities holding local data sets, without exchanging / sharing the local data sets. This approach stands in contrast to traditional centralized machine learning techniques where all the local datasets are uploaded to one server, thus addressing critical issues such as data privacy, data security, data access rights. For FL supported by multiple NWDAFs containing MTLF (Model Training logical function) there is one NWDAF containing MTLF acting as a FL server (called FL server NWDAF for short) and multiple NWDAFs containing MTLF acting as a FL client (called FL client NWDAF for short). The FL server NWDAF and FL client NWDAF have different functionalities (in clause 5.3 of TS 23.288): FL server NWDAF: - discovers and selects FL client NWDAFs to participant in an FL procedure. - requests FL client NWDAFs to do local model training and to report local model information. - generates global ML model by aggregating local model information from FL client NWDAFs. - sends the global ML model back to the FL client NWDAFs and repeats training iteration if needed. FL client NWDAF: - locally trains ML model that is tasked by the FL server NWDAF with an available local data set, which includes the data that it is not allowed to share with others due to e.g. data privacy, data security, data access rights. - reports the trained local ML model information to the FL server NWDAF. - receives the global ML model feedback from the FL server NWDAF and repeats training iteration if needed. Either a NWDAF containing a MTLF or a NWDAF containing an AnLF (Analytical Logical Function) can trigger the ML model training, as a consumer. The NWDAF containing MTLF determines training of an ML model either based on local configuration or, when it receives the request from an NWDAF, containing AnLF. The NWDAF containing MTLF may further determine whether the ML model should be trained via a FL mechanism based on different aspects, e.g. Analytic ID, Service Area / DNAI or data that cannot be obtained directly from a data producer NF (e.g. due to data privacy, data security). However, the NWDAF containing AnLF is not aware of whether the ML model training is based on FL or not. In order to perform a FL procedure among multiple NWDAFs, before a FL procedure is initiated, appropriate NWDAFs containing MTLF, that can act as an FL serverand FL clients, should be discovered and chosen based on specified criteria and interactions between the FL server and the FL clients. When starting a FL procedure, the FL server NWDAF provides an initial model to each FL client NWDAF and then each FL client NWDAF performs local model training using its local data set based on the request from the FL server NWDAF. During the FL procedure execution phase, in order to maintain a FL process, considering performance and capability of FL client NWDAF(s), the FL server NWDAF may trigger reselection, addition, or removal of one or more FL client NWDAFs, discovery of one or more new FL client NWDAFs via NRF (Network Repository Function) and one or more FL client NWDAFs may join or leave the FL process dynamically. The detailed procedures of a registration and discovery procedure for FL, a general procedure for FL among multiple NWDAF instances, procedures for maintaining FL processes are documented in clause 6.2C.2.1,6.2C.2.2 and 6.2C.2.3 of TS 23.288. Registration and Discovery Procedure for FL As mentioned above, before a FL procedure is initiated, an appropriate FL server NWDAF and appropriate FL client NWDAFs are discovered and chosen based on specified criteria, according to the procedures in Figure 1 and in clause 6.2C.2.1 of TS 23.288: Steps 1 to 3 detail the NWDAF registration procedure. 1-3. An NWDAF containing MTLF as a FL server NWDAF or a FL client NWDAF registers with a NRF with its NF profile, which includes NWDAF NF Type, Analytics ID(s), Address information of NWDAF, Service Area, FL capability type information (i.e. FL server or FL client) and Time interval supporting FL as described in clause 5.2. Steps 4 to 6 detail the NWDAF discovery procedure. 4-6. The NWDAF containing MTLF determines that a ML model requires FL based on operator policy (e.g. pre-configured list of ML models), Analytic ID, Service Area / DNAI or data can not be obtained directly from data producer NF (e.g. due to privacy reasons). If the NWDAF containing MTLF can not perform as a FL server NWDAF, the MTLF first discovers and selects a FL server NWDAF from the NRF by invoking the Nnrf_NFDiscovery_Request service operation. The following criteria might be used: Analytic ID of the ML model required, model filter information as defined in TS 23.288 [5], FL capability Type (i.e. FL server), Time Period of Interest, Service Area. Once the FL server NWDAF (the requested or the selected one) is determined, the FL server NWDAF discovers and selects other NWDAF(s) containing MTLF as FL client NWDAF(s) from the NRF by invoking the Nnrf_NFDiscovery_Request service operation. The following criteria might be used: Analytic ID of the ML model required, FL capability Type (i.e. FL client), Service Area, NF type(s) of data sources from which the FL Client NWDAF is able to collect data for local model training, Time Period of Interest, ML model Interoperability Indicator. 7. The FL server NWDAF sends a FL preparation request to the FL client NWDAF(s) using Nnwdaf_MLModelTraining_Subscribe or Nnwdaf_MLModelTraininglnfo_Request service with the ML Preparation Flag, to check if the FL client NWDAF(s) can meet the ML model training requirement (e.g. Analytics ID, ML model Interoperability information, available data requirement, availability time requirement (time span needed for the FL process), etc.). The available data requirement includes a list of Event IDs of the local data for training, and may also include the dataset statistical properties, the time window of the data samples and the minimum number of data samples. NOTE: The FL preparation procedure (i.e. steps 7-9) can be skipped if the FL server NWDAF can decide that the FL client NWDAF(s) supports the FL procedure to be performed, e.g. based on information acquired from previous FL procedures or from the NRF, or based on local configuration. 8. The FL client NWDAF(s) checks if it can meet the ML model training requirement and / or can successfully download the model if the model information is provided in the request and decides whether to join the FL process based on operator policy (e.g. a pre-configured list of ML models) and / or implementation. Example criteria used by a FL client NWDAF(s) may be based on its data availability and time availability, computation and communication capability and ML model Interoperability Information. 9. The FL client NWDAF(s) invokes Nnwdaf_MLModelTraining_Notify or Nnwdaf_MLModelTraining_Subscribe response service operation or Nnwdaf_MLModelTraininglnfo_Request response service operation to indicate to the FL server NWDAF whether it will join the FL procedure and may include the reason in the response message if it cannot join the FL process. 10. The FL server NWDAF determines a final list of FL client NWDAF(s) to be involved in the FL procedure based on the information received in step 6 and other information received in step 9 (if available). General Procedure for FL among multiple NWDAF Instances The general procedure for FL among multiple NWDAFs is shown in Figure 2 as documented in clause 6.2C.2.2 of TS 23.288: 0. The consumer (NWDAF containing AnLF or NWDAF containing MTLF) sends a subscription request to a FL server NWDAF to retrieve an ML model, using Nnwdaf_MLModelProvision service, as defined in clause 7.5, including Analytics ID, ML model metric (e.g., ML model accuracy), accuracy reporting interval, pre-determined status (ML model accuracy threshold or time when the ML model is needed). If the consumer (i.e. the NWDAF containing AnLF or NWDAF containing MTLF) provides the time when the ML model is needed, the FL server NWDAF can take this information into account when deciding the maximum response time for its FL client NWDAF(s). 1. the FL server NWDAF selects NWDAF(s) containing MTLF (FL client NWDAF(s)) as described in clause 6.2C.2.1. 2. The FL server NWDAF sends a Nnwdaf_MLModelTraining_Subscribe or Nnwdaf_MLModelTraininglnfo_Request to the selected NWDAF(s) containing MTLF (FL client NWDAF(s)), which participates in the FL to perform local model training and determine interim local ML model information based on the input parameter in the request from the FL server NWDAF. The request includes a ML model metric and an initial ML model and also includes the maximum response time that a FL client NWDAF has to report the interim local ML model information to the FL server NWDAF before the maximum response time elapses. 3. [Optional] The or each FL client NWDAF collects its local data by using the current mechanism in clause 6.2, if the FL client NWDAF does not have local data available already. 4. During the FL training procedure, the or each FL client NWDAF further trains the ML model provided by the FL server NWDAF based on its own data and reports the interim local ML model information to the FL server NWDAF in Nnwdaf_MLModelTraining_Notify or Nnwdaf_MLModelTraininglnfo_Request response. The Nnwdaf_MLModelTraining_Notify or Nnwdaf_MLModelTraininglnfo_Request response may also include a status report of FL training that includes a local ML model metric computed by the or each FL client NWDAF and Training Input Data Information (e.g. areas covered by the data set, sampling ratio, maximum / minimum value of each dimension of data, etc.) in the FL client NWDAF. The Nnwdaf_MLModelTraining_Notify or Nnwdaf_MLModelTraininglnfo_Response also includes the global ML model accuracy when the ML Model Accuracy Check Flag has been included in the Nnwdaf_MLModelTraining_Subscribe or Nnwdaf_MLModelTraininglnfo_Request (as described in step 7). The global ML Model Accuracy is calculated by the or each FL client NWDAF using local training data as the testing dataset. The local ML model, which is sent from the or each FL client NWDAF to the FL server NWDAF during the FL training process, is the information needed by the FL server NWDAF to build an aggregated model. If a FL client NWDAF is not able to complete the training of the interim local ML model within the maximum response time provided by the FL server NWDAF, the FL client NWDAF shall send a Delay Event Notification that includes a delay event indication, an optional cause code (e.g. local ML model training failure, more time necessary for local ML model training) and an expected time to complete the training if available, to the FL server NWDAF before the maximum response time elapses. 4a. [Optional] If the FL server NWDAF receives a notification / response that a FL client NWDAF is not able to complete the training within the maximum response time, the FL server NWDAF may send to the FL client NWDAF a new maximum response time in Nnwdaf_MLModelTraining_Subscribe or Nnwdaf_MLModelTraininglnfo_Request, before which the FL client NWDAF has to report the interim local ML model information to the FL server NWDAF. Otherwise, the FL server NWDAF may indicate to the FL client NWDAF to skip reporting for this iteration. The FL server NWDAF includes a current iteration round ID in the message to indicate that the request is to modify the training parameters of the current iteration round. Alternatively, the FL server NWDAF may inform the FL client NWDAF to cease the ML model training by sending a termination request and to report back the current local ML model updates. 5. The FL server NWDAF aggregates all the local ML model information retrieved at step 4, to update the global ML model. The FL server NWDAF may also compute a global ML model metric, e.g. based on the local ML model metric(s) or by applying the global model on the validation dataset (if available). The FL server NWDAF may update the global ML model each time a FL client NWDAF provides updated local ML model information, or the FL server NWDAF may decide to wait for local ML model information from all FL client NWDAFs before updating the global ML model. If the FL server NWDAF provides a maximum response time for the FL client NWDAF(s) to provide the interim local ML model information in step 2, or a new maximum response time in step 4a, the FL server NWDAF decides either to wait for the FL client NWDAF(s) which have not yet provided their interim local ML model within the new maximum response time or to aggregate only the retrieved local ML model information instances to update global ML model. The FL server NWDAF makes this decision, with consideration of notification(s) / response(s) from the FL client NWDAF(s) or, if a notification is not received, based on local configuration. 6a. [Optional] Based on the consumer request in step 0, the FL server NWDAF sends a Nnwdaf_MLModelProvision_Notify message to update the ML model metric to the consumer periodically (e.g. a certain number of training rounds or every 10 min) or dynamically when some pre-determined status is achieved (e.g. a ML Model Accuracy Threshold is achieved or a training time expires). 6b. [Optional] The consumer decides whether the current model can fulfil its requirement, e.g. the global ML model metric is satisfactory for the consumer and determines to stop or continue the training process. The consumer re-invokes Nnwdaf_MLModelProvision_Subscribe service operation as used in step 0 to continue the training process or invokes Nnwdaf_MLModelProvision_Unsubscribe service operation to stop the training process. 6c. [Optional] Based on the subscription request sent from the consumer in step 6b, the FL server NWDAF updates or terminates the current FL training process. If the FL server NWDAF receives a request in step 6b to stop the Federated training process, steps 7 and 8 are skipped. 7. If the FL procedure continues, the FL server NWDAF may determine a FL client NWDAF as described in clause 6.2C.2.3 and send a Nnwdaf_MLModelTraining_Subscribe or a Nnwdaf_MLModelTraininglnfo_Requestthat includes the aggregated ML model information to selected FL client NWDAF(s) for a next round of Federated training. The request may also include the ML Model Accuracy Check Flag, that indicates to the FL client NWDAF(s) to use their local training data as the testing dataset to calculate the Model Accuracy of the global ML model provided by the FL server NWDAF. 8. The or each FL client NWDAF updates its own ML model based on the aggregated ML model information distributed by the FL server NWDAF at step 7. When the federated training procedure is complete, the FL server NWDAF requests the FL client NWDAF(s) to terminate the FL procedure by invoking a Nnwdaf_MLModelTraining_Unsubscribe service with a cause code that the FL process has finished and optionally with the final aggregated ML model information. Then the FL client NWDAF(s) terminate the local model training and if the final aggregated ML model information is received from the FL server NWDAF, the FL client NWDAF(s) can store it for further use. 9. After the federated training process is complete, the FL server NWDAF may send Nnwdaf_MLModelProvision_Notify that includes the globally optimal ML model information to the consumer. Procedures for Maintaining FL Processes In order to maintain a FL process during a FL execution phase, the FL server NWDAF may trigger reselection, addition, or removal of FL client NWDAF(s), discover new FL client NWDAF(s) via NRF and FL client NWDAF(s) join or leave the FL process dynamically, considering the performance and capability of FL client NWDAF(s). The detailed procedures are shown in Figure 3 and described in 6.2C.2.3 of TS 23.288: 1 a. The FL server NWDAF may get an updated status of current FL client NWDAF(s) via the NRF by using Nnrf_NFManagement service (as in clause 5.2.7.2 of TS 23.502 [3]) in the FL execution phase. The FL Server NWDAF may subscribe to the NRF for notifications of status changes of the current NWDAF(s) (FL client NWDAFs 1...N) by invoking an Nnrf_NFManagement_NFStatusSubscribe service operation. The NRF notifies the FL server NWDAF of the status changes of the current FL client NWDAF(s) by invoking Nnrf_NFManagement_NFStatusNotify service operation(s). The status of a current FL client NWDAF could be availability changes, capability changes (e.g. it will not support FL anymore, etc.). 1 b. The current FL client NWDAF(s) may inform the FL server NWDAF that it is leaving the FL process by invoking Nnwdaf_MLModelTraining_Notify service operation with a Termination Request and cause code (reason for leaving, e.g. high NF load, time availability changes). 1c. The FL server NWDAF may get information of new FL client NWDAF(s) dynamically via the NRF by subscribing to an event that a new FL client NWDAF has registered (Nnrf_NFManagement_NFStatusSubscribe service as in clause 5.2.7.2 of TS 23.502 [3]). 1 d. The FL server NWDAF may subscribe for NF load analytics of the FL client NWDAF(s). 1 e. The FL client NWDAF(s) may send a status report of FL training and global ML Model Accuracy Information by invoking Nnwdaf_MLModelTraining_Notify service. 2. The FL server NWDAF checks the FL client NWDAF(s) status based on the received information and may determine whether reselection of one or more FL client NWDAFs for the next round(s) of FL is needed, based on the received information from step 1. 3. [If re-selection is needed as judged in step 2] If step 1c is not performed, the FL server NWDAF may discover new candidate FL client NWDAF(s) via the NRF by using Nnrf_NFDiscovery services, as in clause 5.2.7.3 of TS 23.502 [3], The FL server NWDAF reselects FL client NWDAF(s) from the current FL client NWDAF(s) and the new candidate FL client NWDAF(s) (found in steps 1c or 3). For the new candidate FL client NWDAF(s), the interaction between the FL server NWDAF and the FL client NWDAF(s) is the same as the selection procedure described in clause 6.2C.2.1. The adding / deleting of FL client NWDAF(s) may happen at the end of each iteration. 4. The FL server NWDAF sends a termination request by invoking Nnwdaf_MLModelTraining_Unsubscribe service operation or Nnwdaf_MLModelTraininglnfo_Request service operation with Correlation Termination Flag to the FL client NWDAF(s), optionally indicating the reason, e.g. a FL client NWDAF is unselected by the FL server NWDAF for the FL process, or the FL process is suspended, etc. The FL server NWDAF may also send the updated global ML model information to the unselected FL client NWDAF. The FL client NWDAF(s) terminates operations for the FL process if it receives a termination request from the FL server NWDAF and may perform a further action to be qualified to participate in FL training in the next cycles. Vertical Federated Learning (VFL) A new SID on Core Network Enhanced Support for Artificial Intelligence (Al) / Machine Learning (ML) was approved in SP-231800 in TSG SA Meeting #102 (Dec 2023). In WT#2 in the SID in SP-231800: WT2: Study whether and what potential enhancements are needed to enable a 5G system to assist in a collaborative AI / ML operation involving 5GC / NWDAF and / or AF for “Vertical Federated Learning (VFL)”. The work will be based only on, and limited to, the scope of justified use cases. NOTE 7: RAN and UE aspects are out of scope. Solutions based on interactions between the application client and 5GS are out of scope. The necessary communication between a AF and a UE application client to support the collaborative AI / ML operation is understood to have no normative procedure impact. Horizontal FL procedures, defined in R18, should be taken into account and reused whenever possible. NOTE 8: Coordination with SA6 is required. In WG SA2 Meeting #160-Ad Hoc-e meeting (Jan 2024), the Key Issue (KI) description of WT#2 was agreed in S2-2401830 as Kl#2. The detailed description of Kl#2: 5GC Support for VFL was documented in clause 5.2.2 of TR 23.700-84. The issues to be addressed for Kl#2 by SA2 during Rel-19 study phase include in S2-2401830: the key issue aims to provide solutions for enabling 5GC support for (VFL involving a NWDAF and / or AF, where no raw data need be exchanged but some level of coordination is still required when training and inference are performed on local models. In particular, datasets used for each local model need to share the same samples while holding different features. In Rel-18, ML model sharing between NWDAFs has been studied as a part of HFL. However, federated learning between NWDAF and AF has not been studied (e.g. when the NWDAFs and / or AFs are in different domains, locations, regions etc). VFL can be considered as an alternative mechanism for distributed functionalities of an ML model. Note that, as scoped in Rel-19, a NWDAF and / or a AF may be involved for VFL. This Key Issue aims to study architecture enhancement to support VFL, which allows the cooperative AI / ML training and inference with the following aspects: - Identify VFL use cases and under which conditions, and for which entities these VFL use cases show that VFL is justified to train ML models. - Whether and how to support architecture enhancement for supporting VFL for model training and / or inference. - In particular: - Whether and how the existing NF discovery and selection needs to be enhanced. - Whether and how ML model training and / or inference related procedures need to be enhanced to support VFL - Whether and how to do performance monitoring for the ML model trained via VFL. - Whether and how to provide ML models to the participants in the VFL training process. - How to support sample and feature alignment among the participating network entities when performing VFL. NOTE 1: Application layer-based VFL requiring communication between AFs and / or UEs application client, is out of scope. NOTE 2: During the study on this KI, consultation with SA3 is required for handling security aspects. NOTE 3: RAN and UE aspects are out of scope. In order to clarify scenarios of using VFL, VFL use cases are to be identified. One possible use case of implementing VFL is to deploy NWDAF to Support for Sample and Feature Alignment in VFL. It is well known in the AI / ML literature that VFL is a federated learning setting where multiple parties perform training on data sets that share the same sample space but differ in feature space. Because of this, an alignment in sample and feature spaces among participating entities is usually required before applying VFL. VFL further allows performing of joint training without exposing raw data or model parameters, the latter being a way in which VFL differs from HFL. TS 23.288 [X] provides NWDAF specification support for HFL but no VFL support is available. This use case proposes NWDAF support for VFL in analytics derivation by means of sample and feature alignment between the entities participating in VFL, where the main entity facilitating the VFL operation is NWDAF and other entities may be other NWDAF instances and / or AF(s). The motivation forthis use case is mainly two-fold: i) in a multi-vendor scenario, VFL may be more suitable than HFL for multiple NWDAF deployments since such accuracy increase may be achieved without the need to share model parameters among the participating NWDAFs from different vendors, and ii) VFL allows an enhanced accuracy of the NWDAF predictions as models trained via VFL usually generalize better by learning from a broader feature set. In PLMNs where multiple NWDAFs are deployed, each NWDAF instance may perform data collection locally according to their suitable data sources. Depending on the Analytics ID, the different NWDAF instances may share the sample ID space (e.g. S-NSSAI) ortrain on different sample ID spaces (e.g. UE IDs within their corresponding Area of Interest). Furthermore, the NWDAF instances are not all obliged to collect the same input data for the same Analytics ID as most input data is optional, thus their feature spaces may range from full to little overlap. Finally, while an AF may also participate in VFL supported by NWDAF, an alignment of samples would still be needed between the two entities, and feature alignment may also prove beneficial. Depending on the range of overlap in sample and feature spaces of the participating entities, VFL may be a more or less suitable technique to combine models at a NWDAF. Hence, support for sample and feature alignment would allow the VFL supported by NWDAF to be more effective forthose scenarios that are suitable. Based on the above background information and analysis of the given use case, compared to HFL, VFL is able to increase the accuracy of FL without sharing model parameters among the participating NWDAF from different vendors and also allows an enhanced accuracy of the NWDAF predictions as models. In SA2 163 meeting (May 2024), the following conclusions have been documented in clause 8.2 of TR 23.700-84: P#2.4.1: Either the NWDAF or the AF can act as a VFL server and initiate a VFL training process with VFL client(s). P#2.4.2: If an untrusted AF is involved in the VFL training process, its interactions with the NWDAF(s) are via a NEF. When the NWDAF acts as a VFL server, the NWDAF can receive labels from an AF. P#2.4.3: An identifier is allocated by the VFL server, which is used to correlate the participants during the VFL training process and subsequent VFL inference processes and it is associated with distributed ML models in the VFL joint model training process. P#2.4.4: VFL clients compute intermediate results for their local ML models involved in the VFL training process and provide reports with the intermediate results to the AF or NWDAF acting as the VFL server. P#2.4.5: The VFL clients may also provide intermediate results (e.g. gradient information, loss information) to other VFL clients as instructed by the VFL server. P#2.4.6: An AF or NWDAF acting as the VFL server aggregates intermediate results from the VFL clients, trains a local model, computes intermediate results based on its local ML model, and sends the intermediate results to other VFL clients involved in the joint VFL training process. P#2.4.7: The VFL server may compute different intermediate training information (e.g. gradient information, loss information) for updating its own local model and the models of VFL clients during the VFL training process. After processing the received intermediate results (that may include convergence reports), the VFL server sends the updates to the VFL clients, and the VFL server / clients update their local ML model based on the received information. The VFL server determines when the VFL training process terminates, and then informs the VFL clients that the training has ended. As it has been agreed by SA2, the following issues should be addressed during the SA2 Rel-19 study to support VFL: in S2-2401830: The Key Issue aims to study architecture enhancement to support VFL, which allows cooperative AI / ML training and inference with the following aspects: - Identify VFL use cases and under which conditions, and for which entities these VFL use cases show that VFL is justified to train ML models. - Whether and how to support architecture enhancement for supporting VFL for model training and / or inference. - In particular: - Whether and how the existing NF discovery and selection needs to be enhanced. - Whether and how ML model training and / or inference related procedures need to be enhanced to support VFL. - Whether and how to do performance monitoring for the ML model trained via VFL. It has also been concluded in the SA2 163 meeting and document in clause 8.2 of TR 23.70084: P#2.3: For sample alignment for VFL: P#2.3.1: For a NWDAF acting as a VFL server, the NWDAF triggers sample alignment, may query NWDAFs or AFs acting as VFL clients to query availability of samples, and generates the interclause of samples. P#2.3.2 When a NWDAF acts as a VFL server and a AF acts as a VFL client, a NEF may be involved in sample alignment with mapping of information (e.g. internal versus external information), then the NWDAF acting as the VFL server will determine a final list of participants supporting samples for VFL training. P#2.3.3: For an AF acting as a VFL server and NWDAFs acting as VFL clients, the AF performs sample alignment, selects samples to be used in the training process and generates the interclause of samples. P#2.3.4: Feature description information may be registered to the NRF or locally configured in the NWDAF or the AF, negotiated between a VFL server and a VFL client when performing feature alignment. Feature alignment is optional in a VFL process. NOTE 2: Whether and how the feature alignment is supported will be determined in normative phase. NOTE 3: The procedure of performing sample alignment is not agreed yet, i.e. it can be done in a standalone procedure or part of the preparation phase, which will be determined in normative phase. NOTE 4: How a NEF assists sample alignment in P#2.3.3 will be determined in normative phase. NOTE 5: For P#2.3.2 and P#2.3.3, whether and how a NEF supports involvement in generating an intersection of candidate samples is to be discussed in normative phase. Statement of Problem Sample alignment is mandatory for VFL processes to function mathematically. In order to support VFL in 3GPP specifications, the procedures between a VFL server and client(s) for sample alignment and the parameters indicated between the VFL server and client(s) needs to be specified. In order to ensure the efficiency and accuracy of a VFL process, supporting the procedure for feature alignment between a VFL server and client(s) in 3GPP specifications will be beneficial, e.g. will help the VFL server to avoid feature intersection among VFL clients. Currently, the procedure for sample and / or feature alignment between a VFL server and client(s) is not supported in 3GPP specifications. The above information is presented as background information only to assist with an understanding of the present disclosure. No determination has been made, and no assertion is made, as to whether any of the above might be applicable as prior art with respect to the present invention. SUMMARY It is an aim of certain examples of the present disclosure to address, solve and / or mitigate, at least partly, at least one of the problems and / or disadvantages associated with the related art, for example at least one of the problems and / or disadvantages described herein. It is an aim of certain examples of the present disclosure to provide at least one advantage over the related art, for example at least one of the advantages described herein. In accordance with a first aspect of the present disclosure, there is provided a method for vertical federated learning (VFL) in a wireless communications system, the wireless communications system comprising a VFL server and one or more VFL clients, the method comprising: transmitting, from the VFL serverto the one or more VFL clients, a request forthe VFL clients to indicate support information for a VFL process; determining, by the VFL clients, respective support information for the VFL process; transmitting, from the VFL clients to the VFL server, the respective support information forthe VFL process; and determining, by the VFL server, parameters of the VFL process based on the received support information. In an example, the support information forthe VFL process includes an indication of sample IDs and / or feature IDs supported by the respective VFL client. In an example, if the request does not include an indication of one or more sample IDs associated with the VFL process and / or feature IDs associated with the VFL process, the support information includes an indication of all sample IDs and / or feature IDs supported by the VFL client. In an example, if the request includes an indication of one or more of: sample IDs associated with the VFL process, feature IDs associated with the VFL process, and a time window associated with the sample IDs and / or feature IDs, the support information includes an indication of the one or more sample IDs and / or feature IDs associated with the VFL process supported by the VFL client. In an example, the determining parameters of the VFL process includes determining one or more of: the VFL clients to include in the VFL process, the sample ID(s) to be used in the VFL process, and the feature ID(s) to be used in the VFL process per VFL client. In an example, if a VFL client cannot join the VFL process, the VFL includes an indication that the VFL client cannot join the VFL process in the support information. In an example, the indication that the VFL client cannot join the VFL process includes a cause code. In an example, the cause of the VFL client not being able to join the VFL process includes one or more of limited capability, overload, higher priority tasks, VFL client does not meet sample and / or feature alignment requirements, VFL client cannot support sample and / or feature alignment requirements, VFL client cannot perform further training or inference, and VFL client is not available for the VFL process. In an example, each of the VFL server and VFL clients is a trusted or an untrusted application function (AF) or network data analytics function (NWDAF). In an example, if the VFL server is an untrusted AF or an untrusted NWDAF, the request and the support information are transmitted via a network exposure function (NEF). In an example, if a VFL client is an untrusted AF or an untrusted NWDAF, the request and the support information is transmitted via an NEF. In an example, the NEF maps the sample IDs from an internal ID to an external ID. In an example, the internal ID is a subscription permanent identifier (SUPI) and the external ID is a generic public subscription identified (GPSI). In an example, the NEF determines an intersection between support information provided by the VFL clients, and provides an indication of the intersection to the VFL server. In an example, the request is a sample and / or feature alignment request. In an example, the request includes an analytics ID associated with the VFL process, and the determining of the support information is based on the analytics ID. In an example, the request forthe VFL clients to indicate support information for a VFL process is a NWDAF information request service operation. In an example, the respective support information forthe VFL process is included in a NWDAF information response service operation. In an example, the method is performed as part of a VFL preparation phase. In accordance with a second aspect of the present disclosure, there is provided a method for a VFL server in a wireless communications system comprising the VFL server and one or more VFL clients , the method comprising: transmitting, to the one or more VFL clients, a request for the VFL clients to indicate support information for a VFL process; receiving, from the VFL clients, respective support information forthe VFL process; and determining, by the VFL server, parameters of the VFL process based on the received support information. In accordance with a third aspect of the present disclosure, there is provided a method for a VFL client in a wireless communications system comprising a VFL server and one or more VFL clients, the method comprising: receiving, from the VFL server, a request for the VFL clients to indicate support information for a VFL process; determining support information for the VFL process; and transmitting, to the VFL server, the support information for the VFL process. In accordance with a fourth aspect of the present disclosure, there is provided a wireless communications system comprising a VFL server and one or more VFL clients, wherein the wireless communications system is configured to perform the method of any of the aspects and / or examples set out above. In accordance with a fifth aspect of the present disclosure, there is provided a VFL server for a wireless communication system, wherein the VFL server is configured to perform the method for a VFL server set out above. In accordance with a sixth aspect of the present disclosure, there is provided a VFL client for a wireless communications system, wherein the VFL client is configured to perform the method for a VFL client set out above. Other aspects, advantages, and salient features of the disclosure will become apparent to those skilled in the art from the following detailed description taken in conjunction with the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS Figure 1 illustrates a registration and discovery procedure for FL; Figure 2 illustrates a general procedure for FL among multiple NWDAF; Figure 3 illustrates a procedure for FL server NWDAF reselectsFL client NWDASF(s), FL client NWDAF(s) join or leave FL process dynamically in FL execution phase; Figure 4 illustrates a procedure for sample and / or feature alignment; Figure 5 illustrates a procedure for VFL sample and / or feature alignment; Figure 6 illustrates a procedure for sample and / or feature alignment when an AF is the VFL server; Figure 7 illustrates a procedure for sample and / or feature alignment when an NWDAF is the VFL server; Figure 8 illustrates a preparation procedure for vertical federated learning when an NWDAF is the VFL server; Figure 9 illustrates a preparation procedure for vertical federated learning when an untrusted AF is the VFL server; and Figure 10 illustrates a network entity in accordance with the present disclosure. DETAILED DESCRIPTION The following description of examples of the present disclosure, with reference to the accompanying drawings, is provided to assist in a comprehensive understanding of the present invention, as defined by the claims. The description includes various specific details to assist in that understanding but these are to be regarded as merely exemplary. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the examples described herein can be made. The following examples are applicable to, and use terminology associated with, 3GPP 5G. However, the skilled person will appreciate that the techniques disclosed herein are not limited to these examples orto 3GPP 5G, and may be applied in any suitable system or standard, for example one or more existing and / or future generation wireless communication systems or standards. The skilled person will appreciate that the techniques disclosed herein may be applied in any existing or future releases of 3GPP 5G NR or any other relevant standard. For example, the functionality of the various network entities and other features disclosed herein may be applied to corresponding or equivalent entities or features in other communication systems or standards. Corresponding or equivalent entities or features may be regarded as entities or features that perform the same or similar role, function, operation or purpose within the network. For example, the functionality of an IAB node in the examples below may be applied to any other suitable type of entity performing functions of a network node. The skilled person will appreciate that the present invention is not limited to the specific examples disclosed herein. For example: • The techniques disclosed herein are not limited to 3GPP 5G. • One or more entities in the examples disclosed herein may be replaced with one or more alternative entities performing equivalent or corresponding functions, processes or operations. • One or more of the messages in the examples disclosed herein may be replaced with one or more alternative messages, signals or other type of information carriers that communicate equivalent or corresponding information. • One or more further elements, entities and / or messages may be added to the examples disclosed herein. • One or more non-essential elements, entities and / or messages may be omitted in certain examples. • The functions, processes or operations of a particular entity in one example may be divided between two or more separate entities in an alternative example. • The functions, processes or operations of two or more separate entities in one example may be performed by a single entity in an alternative example. • Information carried by a particular message in one example may be carried by two or more separate messages in an alternative example. • Information carried by two or more separate messages in one example may be carried by a single message in an alternative example. • The order in which operations are performed may be modified, if possible, in alternative examples. • The transmission of information between network entities is not limited to the specific form, type and / or order of messages described in relation to the examples disclosed herein. To satisfy extremely high data rate requirements, the 3GPP 5G NR standard utilises communication frequencies in a relatively high range, from 30 GHz to 300 GHz, corresponding to wavelengths in the millimetre (mm) range (mmWave communication). Such mmWave communication provides a large available bandwidth and high transmission speeds. However, problems with mmWave communication include severe signal path loss and low penetration, resulting in a relatively short transmission range. This in turn requires a greater density of base stations deployment. Certain examples of the present disclosure provide a network or wireless communication system comprising a first network entity and a second network entity according to any example, embodiment, aspect and / or claim disclosed herein. Certain examples of the present disclosure provide a computer program comprising instructions which, when the program is executed by a computer or processor, cause the computer or processor to carry out a method according to any example, embodiment, aspect and / or claim disclosed herein. Certain examples of the present disclosure provide a computer or processor-readable data carrier having stored thereon a computer program according to the preceding examples. Certain examples of the present disclosure may be provided in the form of an apparatus / device / network entity configured to perform one or more defined network functions and / or a method therefor. Such an apparatus / device / network entity may comprise one or more elements, for example one or more of receivers, transmitters, transceivers, processors, controllers, modules, units, and the like, each element configured to perform one or more corresponding processes, operations and / or method steps for implementing the techniques described herein. For example, an operation / funotion of X may be performed by a module configured to perform X (or an X-module). Certain examples of the present disclosure may be provided in the form of a system (e.g. a network) comprising one or more such apparatuses / devices / network entities, and / or a method therefor. For example, in the following examples, a network may include one or more IAB nodes. It will be appreciated that examples of the present disclosure may be realized in the form of hardware, software or a combination of hardware and software. Certain examples of the present disclosure may provide a computer program comprising instructions or code which, when executed, implement a method, system and / or apparatus in accordance with any aspect, claim, example and / or embodiment disclosed herein. Certain embodiments of the present disclosure provide a machine-readable storage storing such a program. The same or similar components may be designated by the same or similar reference numerals, although they may be illustrated in different drawings. Detailed descriptions of techniques, structures, constructions, functions or processes known in the art may be omitted for clarity and conciseness, and to avoid obscuring the subject matter of the present disclosure. Certain examples of the present disclosure are presented below. In this disclosure, examples of detailed procedures and parameters to enable VFL sample and / or feature alignment are introduced to support different scenarios. The scenarios may comprise considering a AF or a NWDAF as a VFL server, considering a AF or a NWDAF as a VFL client. Overview of Sample and / or Feature Alignment Based on the nature of VFL algorithms, before VFL training is actually initiated by a VFL server and / or at VFL clients, sample and / or feature alignment should be performed. There may be a need to make sure that a VFL operation (VFL model training and / or inference) can be supported by VFL clients that are to participate I already participate in the VFL operation. There may be a need to make sure that samples / entities associated with a VFL model are supported by the VFL clients, e.g. if the samples are certain UEs, the VFL server need to choose VFL clients that can support VFL model training and / or inference for the certain UEs (IDs). In addition, the VFL server may also need to make sure that all required features for the VFL model training and / or inference for certain samples IDs I sample ID can be supported by the VFL clients. Furthermore, to improve VFL efficiency, the VFL server may determine how to allocate the VFL model training and / or inference on certain features to different VFL clients. This may comprise ensuring there is no overlap between the features at different VFL clients or controlled I acknowledged overlap of features among different VFL clients. For the above purposes, sample and / or feature alignment procedures are needed between VFL clients and the VFL server(s), to help the VFL server to understand the samples and / or features that can be supported by the VFL clients and, therefore, to choose the VFL clients that can support the requirements for participation in a VFL operation (VFL model training and / or inference). The sample and / or feature alignment procedures can also help the VFL clients to understand the requirements, e.g. on the samples and / or features to be supported by the VFL operation (VFL model training and / or inference). The VFL clients may determine whether they can support the required samples and / or features. This may be, e.g., based on local data (fresh or previously collected data), capability, etc. A VFL client may decide whether it will join the VFL operation based on information indicated in a sample and / or feature alignment request from the VFL server. The VFL client may then notify samples and / or features it can support and / or those it cannot support. An associated supported or not supported flag may be used (e.g. if samples and / or features are supported, the VFL client may associate a support flag with the supported samples and / or features; and / or if samples and / or features cannot be supported, the VFL client may associate a un-support flag with the unsupported samples and / or features. The VFL server can thereby understand which samples and / or features are supported and / or not supported, for VFL configuration justification, whether the VFL client will join the VFL operation (VFL model training and / or inference), etc. If the VFL client will not join the VFL operation, it may send a cause value to indicate a reason for not joining. Sample and / or feature alignment may be performed at different stages of a VFL process: 1) Together with a discovery procedure, e.g. a discovery procedure for a NWDAF containing AnLF to discover a NWDAF or a AF that can act as a VFL server. The VFL server discovers VFL clients based on requirements (e.g. based on analytics ID, sample IDs (e.g. UE ID, NF instance ID, slice ID, etc.), VFL capability requirements, latency / delay requirements, etc.). o In this case, the VFL clients and the VFL server may have registered the sample IDs and features that can be supported to a NRF during registration (update) procedures. 2) During a VFL operation (e.g. VFL model training and / or inference) preparation stage, e.g. after a VFL client discovery procedure but before the VFL server triggers a first iteration of VFL model training. The VFL server may initiate procedures for sample and / or feature alignment to understand which sample IDs and / or feature (space) can be supported by the VFL clients. o The VFL clients may be discovered by the VFL server by invoking a VFL client discovery procedure. 3) Initiated together with the VFL operation (VFL model training and / or inference). The VFL server may initiate sample and / or feature alignment together with VFL model training (e.g. in a first iteration of VFL model training) and / or inference. In this disclosure, a VFL server could be a NWDAF, a (trusted) AF, an untrusted AF. A VFL client could be a NWDAF, a (trusted) AF, an untrusted AF. For VFL training related processes I procedures, a NWDAF may represent a NWDAF containing MTLF. For VFL inference related processes I procedures, a NWDAF may represent a NWDAF containing AnLF. In this disclosure, VFL sample and / or feature requirement information (in a VFL server request for VFL sample and / or feature alignment) may include one or more of the following: - IDs of selected VFL client(s), e.g. any of NWDAF ID(s) NF (instance) ID(s), AF ID(s), o The client ID(s), the client AF ID(s), the client NWDAF ID(s) and / or NF (instance) ID(s) may be internal ID(s) or external ID(s). A NEF may understand mapping between internal NWDAF ID(s) and or NF (instance) ID(s) and external NWDAF ID(s) NF(instance) ID(s). If an ID is to be transmitted to a (trusted) AF, untrusted AF from a 5GC, the NEF may translate this internal ID into an external ID. If an ID to be transmitted to a 5GC from a (trusted) AF, untrusted AF, the NEF may translate this external ID into an internal ID. o The VFL client IDs may be a group ID, e.g. an ID representing a group of entities. A VFL client group may contain multiple VFL clients (e.g. that may be grouped based on capability, supporting sample IDs and features). A NWDAF group ID may contain multiple NWDAFs (e.g. that may be grouped based on location I area that analytics can be provided for, supporting sample IDs and features). - An analytics ID, as defined in TS 23.288, e.g. provided by an analytics consumer who triggers the VFL process. The analytics consumer may contact the NWDAF containing AnLF, the NWDAF containing AnLF may determine to trigger a VFL process for a required analytics ID (e.g. VFL model (re-)training and / or inference; if the NWDAF containing AnLF cannot act as a VFL server). The NWDAF containing AnLF may discover a VFL server capable NWDAF and or AF to act as a VFL server to perform the VFL model (re-)training and / or inference)). - One or more target VFL samples, e.g. any of UE IDs, UE group ID (which may link to one or more UEs in a group), NF (instance) IDs, NF set IDs, slice IDs, etc.), if feature alignment and / or sample alignment is triggered. o Sample ID(s) may be external ID(s) if VFL feature alignment and / or sample alignment is triggered by an (untrusted) AF and / or if information is carried by a service operation invoked by the (untrusted) AF. o Sample ID(s) may be internal ID(s) if VFL feature alignment and / or sample alignment is triggered by a (trusted) AF and / or a NWDAF, and / or if information is carried by a service operation invoked by the (trusted) AF and / or the NWDAF. - One or more feature profile / container / context (e.g. including features per sample), if feature alignment is triggered. o e.g. indicating which features the VFL server can provide (e.g. a list of features supported by the VFL server) o which features are needed and / or required for performing the VFL model training and / or inference (e.g. a list of required features for VFL training from the VFL client side), features that the VFL server expects and / or requires the VFL clients to support. o A VFL client may support one or more individual features in the feature profile / container / context, or part of the feature profile / container / context, not the full / entire features profile / container / context. A VFL client may indicate a feature that it can support to one or more other VFL clients. o A feature required by the VFL server to run the VFL operation (VFL model training and / or inference) may be associated with an analytics ID or may vary with an analytics ID. This may be according to input and output parameters of each analytics ID, defined in TS 23.288. For Observed Service Experience related network data analytics, features could be any of Service Experience, RAT Type, etc. (based on the output Table 6.4.3-1: Service Experience statistics in TS 23.288). o Detailed content of a feature container / context / profile may not be defined in the specification. Features may be carried by a feature container / context / profile. The content of the container / context / profile and / or the type of features might be outside 3GPP scope, e.g. can be defined based on agreements / SLA / protocols between operators and 3rd party / service providers. o Different feature profiles or feature containers / context may be indicated to different VFL clients by the VFL server. This may be based on the VFL server’s priory knowledge. The VFL server may also indicate partial I part / subset of overall features needed for the VFL operation to certain VFL clients. - An area of interest (AOI). This may bean area that the VFL server is interested. This may be an area in which the VFL server expects the VFL clients to support the corresponding sample ID(s) and / or the features. - A time window or a time duration associated with other information in sample and / or feature requirement information. This may be the time window ortime duration in which the VFL server expects the VFL clients to support the VFL operation (VFL training and / or inference) for the required sample IDs and / or features. VFL sample and feature alignment may occur together or separately, e.g. in Figure 4. - 1b. One service operation can trigger both VFL sample and feature alignment for the same VFL procedure. This may include necessary information for feature alignment. - 1 a. The VFL server triggers sample alignment. This may include necessary information for sample alignment. Then 2a. The VFL server triggers feature alignment after the VFL server completes the VFL sample alignment. This may include necessary information for feature alignment. - 1c VFL sample alignment and 2c feature alignment, may overlap. This may be based on the triggers sent by the VFL server. Procedure for VFL Sample and / or Feature Alignment The different options in Figure 4 can be supported by the procedure in Figure 5. Figure 5 details: 0. The VFL server discovers and selects VFL clients to perform a VFL operation (VFL model training and / or VFL inference). - If the VFL server is a NWDAF, the VFL clients could be any of a NWDAF, NWDAF containing MTLF, a (trusted) AF, an untrusted AF. - If the VFL Server is a AF, the procedure covers the scenario when the NWDAF (containing MTLF) is VFL client(s). (Trusted) AF, untrusted AF could be also be chosen as VFL clients, but the interactions between AF are outwith 3GPP scope. 1. The VFL server initiates the VFL sample and / or feature alignment procedure towards the VFL clients. This may be based on internal logic of the server, triggered by an analytics ID consumer, triggered by the needs of the VFL model re-training (e.g. due to model accuracy being low, the NWDAF containing MTLF or AnLF may require model (re-)training, update of VFL clients condition I capability (e.g. VFL clients updates of NF profiles at a NRF, VFL clients capability updates, VFL clients cannot support certain Analytic ID / UE ID / features, etc.)). - if the VFL server is a AF, • if the VFL server is an untrusted AF, the untrusted AF VFL server sends one or more VFL sample and / or feature alignment request(s) to the NEF, the NEF forwards the request to the (corresponding) VFL clients, e.g. o the untrusted AF VFL server may include one or more of the following VFL sample and / or feature requirement information in the NEF service operation for VFL sample and / or feature alignment (e.g. step 1 c1 in the figure): the (selected) VFL client NWDAF ID(s), Analytics ID(s), target samples (i.e. external UE IDs), and, optionally, the feature profile (including features per each sample) indicates what features the AF can provide (i.e. a list of VFL server AF supported features) and what features are needed for performing the VFL model training (i.e. a list of required features for VFL training). o the NEF forwards the above sample and / or feature requirement information in the VFL sample and / or feature alignment service operation to the NWDAF VFL clients (e.g. step 1c4 in the figure): e.g. by invoking NWDAF service operation for the VFL sample and / or feature alignment request. • if the VFL server is a (trusted) AF, the (trusted) AF VFL server may send the VFL sample and / or feature alignment request directly to the VFL NWDAF clients or via the NEF. If the request is via the NEF, the NEF forwards the request to the VFL NWDAF clients (same as above condition for an untrusted AF VFL server). If the (trusted) AF VFL server is able to send the feature alignment request directly to the VFL NWDAF clients (e.g. step 1a in the figure), e.g. o the (trusted) AF VFL server may include all or some of the information in the VFL sample and / or feature requirement information in the NWDAF service operation for the VFL sample and / or feature alignment request. - If the VFL server is a NWDAF, the NWDAF VFL server sends the VFL sample and / or feature alignment request to the VFL clients (e.g. NWDAFs, (trusted) AFs, untrusted AFs) e.g. o if the VFL client is a NWDAF, the NWDAF VFL server may include all or some of the information in the VFL sample and / or feature requirement information in the NWDAF service operation (e.g. step 1a in the figure) forthe VFL sample and / orfeature alignment request. o If the client is a (trusted) AF the NWDAF VFL server may include all or some of the information in the VFL sample and / orfeature requirement information in the AF service operation (e.g. step 1b in the figure) forthe VFL sample and / orfeature alignment request or the NWDAF VFL server may include all or some of the information in the VFL sample and / orfeature requirement information in the NEF service operation forthe VFL sample and / or feature alignment request towards the NEF, the NEF invokes one or more AF service for VFL sample and / or feature alignment request and includes all or some of the information in the VFL sample and / orfeature requirement information indicated by the NWDAF VFL server. o If the VFL client is an untrusted AF, the NWDAF VFL server may include all or some of the information in the VFL sample and / orfeature requirement information in the NEF service operation for the VFL sample and / or feature alignment request towards the NEF, the NEF invokes one or more AF service forthe VFL sample and / or feature alignment request and includes all or some of the information in the VFL sample and / or feature requirement information indicated by the NWDAF VFL server (e.g. step 1 c1 and then 1c3 in the figure). 1c3. Optional, may happen between 1 c1 and 1c3 / 1c4. If the request for VFL sample and / or feature alignment goes through NEF, NEF maps the external IDs into internal IDs, or NEF maps the internal IDs into external IDs. - the IDs to be mapped by the NEF could be UE IDs, NWDAF ID(s), NF (instance) IDs, slice IDs, VFL client group ID, sample IDs, feature IDs, etc., to protect user and 5GC / 5GS privacy, or translate the external information into 5GS IDs / terminologies for 5GS to understand the request / information if the information is from AF / outside 5GC. E.g. the NEF maps the external UE ID into the internal UE IDs (e.g. GPSI to SUPI), therefore 5GC can understand which UEs / sample are indicated by the AF. - the NEF may be extended to support the candidate VFL client selection, e.g. the AF may send the required sample and / or feature for the VFL, the NEF choose the VFL client (NWDAF) for the AF based on the VFL sample and / or feature requirement information provided by the VFL server. Then the NEF indicates the candidate VFL clients to the VFL server. The server will make the final selection / decision on the VFL clients that can participate in VFL process (VFL model training and / or inference). - The AF VFL server could be (trusted) AF and / or untrusted AF. If the AF VFL server is (trusted) AF, to require the NEF to perform candidate VFL client selection, the (trusted) AF sends the VFL sample and / or feature alignment request to NEF. - In the above candidate VFL client selection procedure, the NEF can be replaced by NWDAF. In this case, the untrusted AF VFL server may send request to the NWDAF that is extended to support candidate VFL client selection via NEF; the (trusted) AF VFL server may send request to the NWDAF that is extended to support candidate VFL client selection directly, not via NEF. 2. Upon receiving the VFL sample and / or feature Request from VFL server, each VFL client NWDAF may collect input data, e.g. based on the analytics ID, sample ID(s), features and other information indicated by the VFL server, if the VFL clients determines that the local data is not currently available / not efficient to perform VFL sample and / or feature alignment at the VFL Client. 3. Based on local data at the VFL client, each VFL Client may determine the samples and / or the features it can support. One or more of the following options are possible: Option 1: The VFL client may determine all of the samples and / or features it can support, then match the supported samples and / or features into those indicated by the VFL server. Then decide the overlap between the samples and / or features it can support and those in the VFL server request. The overlapping information on samples and / or features might be sent to the VFL server. Option 2: The VFL client may only check whether the samples and / or the features provide by the VFL server it can support or not. In this case, the VFL client may collect less than data than the above option 1. E.g. the VFL client may only collect data associated to the required samples and / or the features provided by the VFL server; if the data is available for certain required samples and / or the features, that means the certain required samples and / or the features can be supported by the VFL client. The VFL client may indicate the certain samples and / or the features to the VFL server. Option 3: the VFL client may indicate to the VFL server about the samples and / orthe features it can support but in the VFL samples and / orthe features alignment request. Therefore, the VFL server will have better knowledge of the samples and / or the features that can be supported by the VFL client which is beneficial for future VFL process. 4. VFL client indicates the samples and / or the features to the VFL serve. - if the VFL server is AF, • If the AF is untrusted AF server, the VFL client is NWDAF: the VFL client sends the VFL sample and / or feature alignment response to the NEF, the NEF forwards the response to VFL server, e.g. oE.g. step 4c4, then 4c2, then 4c3. oFor step 4c2, if the response for VFL sample and / or feature alignment goes through NEF, NEF maps the internal IDs into external IDs. the IDs to be mapped by the NEF could be UE IDs, NWDAF ID(s), NF (instance) IDs, slice IDs, VFL client group ID, sample IDs, feature IDs, etc., to protect user and 5GC / 5GS privacy. o If the NEF is extended to support the candidate VFL client selection, the NEF chooses the VFL client (NWDAF) for the AF based on the VFL sample and / or feature requirement information provided by the VFL server. Then the NEF indicates the candidate VFL clients that can fulfil the VFL server requirements to the VFL server. The server will make the final selection / decision on the VFL clients that can participate in VFL process (VFL model training and / or inference). oThe AF VFL server could be (trusted) AF and / or untrusted AF. If the AF VFL server is (trusted) AF, to require the NEF to perform candidate VFL client selection, the (trusted) AF sends the VFL sample and / or feature alignment request to NEF. oln the above candidate VFL client selection procedure, the NEF can be replaced by NWDAF. • If the server is AF (trusted), the VFL NWDAF clients send the response to VFL server, e.g. by invoking NWDAF service operation for response, oE.g. step 4a - If the server is NWDAF, e.g. o If the client is NWDAF, the VFL client responds via step 4a. o If the client is (trusted) AF, the VFL client responds via step 4b. o If the client is (untrusted) AF, the VFL client responds via step 4c1,4c2, 4c3 5 - 7. The VFL server consolidates the samples and / or features that can be supported by each VFL clients, based on the information provided by VFL clients, the VFL server may: - determine the final samples and / or features to be supported / used by the VFL process, e.g. VFL model training and / or inference; and inform the decision to VFL clients. - determine the final list of VFL clients that are selected to participate in the VFL process, e.g. VFL model training and / or inference, for the determined final samples and / or features, and inform the decision to VFL clients. - determine the feature(s) that are to be supported by certain VFL client(s), of the associated sample(s). and inform the decision to VFL clients. E.g. VFL client 1 needs to support part of the features, VFL client 2 needs to support the remaining features. oThe features supported by different VFL clients may have overlapping / the same. It is up to VFL server decision. oThe VFL server may separate / allocate different features to different VFL clients, and make sure there is not overlapping between features allocated to different VFL clients. 8. If the VFL server determines that there is not sufficient amount of samples and / or features can be supported by the VFL clients, it may terminate the sample and / or feature alignment procedure or the future VFL (model training and / or inference) procedure. And inform the decision to VFL clients. The VFL server may determine to (re)initiate a new sample and / or feature alignment, e.g. by adjusting the sample and / or feature requirements for the VFL clients, or the sample and / or features are expected to be supported by the request sample and / or feature alignment. The VFL server may determine to update the VFL clients, e.g. during the VFL (model training and / or inference) process. The VFL server may trigger / (re)initiate sample and / or feature alignment towards all of the VFL clients, or only the new clients, or the new clients and some selected old clients that are participating the VFL process. Procedure for Sample and / or Feature Alignment when AF is the VFL Server Figure 6 and the description of the steps below detail the procedure for the sample and / or feature alignment when an AF is the VFL server. However, the VFL server in this procedure can be also replaced with a NWDAF (e.g. containing MTLF). The VFL server could be: a trusted AF, an untrusted AF, an NWDAF (e.g. containing MTLF). The VFL clients could be NWDAF (e.g. containing MTLF), trusted AF, untrusted AF. The interaction between AFs are out of 3GPP scope; therefore, will not be detailed in this example. In Figure 6 and the following description, a trusted AF / untrusted AF will be used as an example of the VFL server. 0. The VFL server determines to trigger VFL preparation, e.g. including sample alignment and / or feature alignment. This may be triggered by the VFL server internal logics, due to model accuracy requirements / reasons (to improve the accuracy of VFL model training and / or inference results), analytics consumer required analytics from NWDAF then the NWDAF determines to perform VFL model training, etc. 1. The VFL server sends a VFL preparation request to the candidate VFL client(s) via NEF with the ML Preparation Flag to check if the VFL client(s) can meet the ML Model training requirement (e.g. Analytics ID, Sample alignment requirement, VFL Availability time requirement (time span needed for the VFL process), etc.). Sample alignment requirement includes a list of sample IDs targeted for VFL training as defined by the AF. The VFL server sends the VFL preparation request to the NEF for VFL preparation, e.g. for sample alignment and / or feature alignment, by invoking enhanced Nnwdaf_MLModelTraining_Subscribe service operation or Nnwdaf_MLModelTraininglnfo_Request service operation, or a new service operation for VFL preparation (e.g. for sample alignment and / or feature alignment), as detailed under Service (operations) to support VFL sample and / or feature alignment. The input information of the preparation request is also detailed under Service (operations) to support VFL sample and / or feature alignment. The VFL server may optionally include the sample IDs and / or feature related information (including one or more of feature IDs, feature profile, feature context, feature container) into the VFL preparation request, and associated VFL correlation ID (an ID can correlate between the different procedures for a VFL process (e.g. VFL correlation / process ID, VFL ID, VFL model ID, etc.)). 2. The NEF optionally maps the external UE IDs (e.g. GPSIs) received in step 1 to the internal UE IDs (e.g. SUPIs), if the external UE IDs (e.g. GPSIs) are included in step 1. The NEF may store / keep the external UE IDs (e.g. GPSIs) if received in step 1 and / or the mapped internal UE IDs (e.g. SUPIs) for the following steps, e.g. the NEF may use the stored / received information to calculate the intersection of sample IDs among VFL server and VFL clients or among VFL clients only. The NEF may store / keep the feature related information, if received in step 1 for the following steps, e.g. the NEF may use the stored / received information to calculate the intersection of feature related information among VFL server and VFL clients or among VFL clients only. 3. The NEF may send / forward the VFL preparation request to each candidate VFL client (NWDAF) using Nnwdaf_MLModelTraining_Subscribe or Nnwdaf_MLModelTraininglnfo_Request service when multiple candidate VFL clients are involved, the information included by the NEF is detailed under NEF and AF / NWDAF service (operation) for sample and / or feature alignment. However, the Service (Operations) to support VFL Sample and / or Feature Alignment include all service operations. In the NEF VFL preparation request to the VFL clients, the NEF may optionally include a list of sample IDs (e.g. all or part of the mapped internal UE IDs (e.g. SUPIs) in step 1), Analytics ID and optionally required Feature IDs / feature related information, associated VFL correlation ID (a ID can correlate the different procedures for a VFL process (e.g. VFL correlation / process ID, VFL ID, VFL model ID, etc.)). The NEF may invoke the enhanced Nnwdaf_MLModelTraining_Subscribe or Nnwdaf_MLModelTraininglnfo_Request service, may include a flag to indicate the VFL / ML Preparation (e.g. including feature alignment and / or sample alignment). - The existing ML Preparation Flag in TS 23.288 might be reused, e.g. if the sample ID and / or feature related information is include in the VFL preparation request, together with the ML Preparation Flag, the VFL client will interpret the request as VFL preparation (e.g. including feature alignment and / or sample alignment). - Introducing a new indication / flag for VFL preparation (e.g. including feature alignment and / or sample alignment) explicitly, e.g. VFL preparation flag, VFL feature alignment and / or sample alignment flag, etc. 4. Each VFL Client checks if it can meet the ML Model training requirement. If it cannot meet the requirements for any reason, it may decide which requirements it can agree to. The VFL Client determines the sample ID and / or feature ID / feature related information that can be supported by itself, e.g. based on the its local data previously stored or newly collected upon receiving the VFL preparation request. If the sample IDs and / or feature ID / feature related information are included in step 3, the VFL client may compare the given sample IDs and / or feature ID / feature related information in step 3 and the sample IDs and / or feature ID / feature related information it can support, determine - the intersection of the sample IDs and / or feature ID / feature related information - whether it will join the VFL or not, e.g. based on the sample IDs and / or feature ID / feature related information it can support, (current, future) load, capability of VFL training and / or inference, computation resources, etc. 5. Each VFL Client invokes Nnwdaf_MLModelTraining_Notify or Nnwdaf_MLModelTraining_Subscribe response or Nnwdaf_MLModelTraininglnfo_Request response service operation to indicate to the VFL Server whether it accepts the requirements, whether it requests new requirements or whether it will not join. The client includes the requirements it can accept or may add a reason if it cannot join the FL process. The VFL client includes the sample IDs and / or feature ID / feature related information that it can support and / or cannot support, in the VFL preparation response to NEF and VFL server, the associated VFL correlation ID (a ID can correlate the different procedures for a VFL process (e.g. VFL correlation / process ID, VFL ID, VFL model ID, etc.)). If the sample IDs and / or feature ID / feature related information are included in the NEF request in step 3, the VFL client may only send the sample IDs and / or feature ID / feature it can support and / or cannot support within the given list of sample IDs and / or feature ID / feature in step 3. The VFL clients may also include the NF instance ID / NWDAF ID / VFL client ID to the response. Therefore, the NEF can understand which VFL clients can support which sample IDs and / or feature ID / feature related information, e.g. for the purpose of further VFL client refinement and / or selection. 6. The NEF may determine the intersection of sample IDs and / or feature ID / feature related information. - The NEF may determine the intersection among VFL clients NWDAF only. In this case, the NEF consolidate all the VFL preparation response from VFL clients, and determines the intersection of sample IDs and / or feature ID / feature among the VFL clients. Then the NEF informs the intersection to the VFL server AF. The VFL server does not need to include the required sample IDs and / or feature ID / feature for VFL progress in the VFL preparation request in step 1. - The NEF may determine the intersection among VFL clients NWDAF and also the VFL server AF. In this case, the NEF consolidates all the VFL preparation response from VFL clients and also the sample IDs and / or feature ID / feature provided by the VFL server in the VFL preparation request in step 1. The VFL server should include the required sample IDs and / or feature ID / feature for VFL progress in the VFL preparation request in step 1. Optionally, the NEF maps the determined intersected Sample IDs, e.g. internal UE IDs / SUPIs, into external UE IDs / GPSIs. Then sends the external UE IDs / sample IDs to VFL server in VFL preparation response in step 7. The NEF may store the Sample IDs and / or / or feature ID / feature related information can be supported by each VFL client and also the associated VF client IDs. Based on the intersection of Sample IDs and / or / or feature ID / feature related information, the NEF may also determine the VFL clients that can support all of the intersected sample IDs. the overlapping on feature ID / feature related information might be also considered by the NEF, e.g. determined VFL clients may have no or limited overlapping on feature ID / feature related information can be supported. The NEF stores the IDs of the determined VFL clients (external IDs and / or internal IDs). Optionally, the NEF maps the (determined) internal NWDAF ID / NF (instance) ID of the VFL clients to external / mask / protected NF instance / NWDAF ID. Then sends each external NWDAF ID optionally associated with the (intersected) external UE IDs / sample IDs and / or feature ID / feature related information it can and / or cannot support to the VFL server in VFL preparation response in step 7. 7. The NEF sends the VFL preparation response to the VFL server AF, e.g. by invoking enhanced Nnwdaf_MLModelTraining_Notify or Nnwdaf_MLModelTraininglnfo_Response, ora new NEF service operation for VFL preparation response (e.g. for sample alignment and / or feature alignment), as detailed under NEF and AF / NWDAF service (operation) for sample and / or feature alignment. The information of the preparation response is also detailed in NEF and AF / NWDAF service (operation) for sample and / or feature alignment. The NEF may include the intersection of sample IDs and / or feature ID / feature related information determined in step 6 to VFL server AF, and the associated VFL correlation ID (a ID can correlate the different procedures for a VFL process (e.g. VFL correlation / process ID, VFL ID, VFL model ID, etc.)). If the server is an untrusted AF, in the VFL preparation response, the NEF may: - not include the intersected sample ID(s) (e.g. external UE IDs / GPSIs) to VFL server, - include intersected feature ID / feature related information determined in step 6, - not include the internal / external ID of VFL clients (e.g. NWDAF ID) When multiple candidate VFL clients are involved, the NEF may aggregate the response from each candidate VFL client and send a VFL Preparation response message to the untrusted AF. If the notify or response includes new requested requirements, procedure from step 1 is repeated. When multiple candidate VFL clients are involved, the NEF may aggregate the response from each candidate VFL client and send a VFL Preparation response message to the untrusted AF. 8. The VFL server determines the final intersection of sample IDs and / or feature ID / feature related information among all candidate VFL clients and VFL server based on the information provided by NEF. The VFL server chooses the sample IDs and / or feature ID / feature related information for VFL process / VFL model training and / or inference. The chosen sample IDs and / or feature ID / feature related information might be a subset of the final intersection or the same as the final intersection. 9. The VFL server may determine to refine the VFL clients for VFL process / VFL model training and / or inference, e.g. based on the chosen sample IDs and / or feature ID / feature related information (in step 8), the VFL server needs to choose / determine the VFL clients that support all of the chosen sample IDs, but to minimize the overlapping on feature ID / feature related information supported by each candidate VFL clients, or make sure there is no overlapping on feature ID / feature related information supported by candidate each VFL clients. This step may be performed together with VFL model training, e.g. together with 1st iteration of VFL model training, before 1st iteration by upon the VFL model training is triggered by the server. The NEF invokes a request to NEF or to VFL clients via NEF. The VFL server AF may invoke the service operation used in step 1 or service operation for VFL model training to trigger the VFL client refinement, including the determined the sample ID and / or feature ID / feature related information for the following VFL training and / or inference, an ID can correlate the different procedures for a VFL process (e.g. VFL correlation / process ID, VFL ID, VFL model ID, etc.), candidate VFL clients list for refinement, etc. 10. The NEF may be enhanced to determine the VFL clients based on the given sample ID and / or feature ID / feature related information determined by VFL server in step 8. The NEF may be aware of the sample ID and / or feature ID / feature related information of the corresponding VFL process / VFL correlation ID, to avoid or minimize the overlapping on feature ID / feature related information of different candidate VFL clients, etc. Then step 3-8 might be repeated. Procedure for Sample and / or Feature Alignment when NWDAF is the VFL Server Figure 7 and the description of the steps below detail the procedure for the sample and / or feature alignment when NWDAF is the VFL server. However, the VFL server in this procedure can be also replaced AF, e.g. untrusted AF or trusted AF. The VFL server could be: a trusted AF, an NWDAF (e.g. containing MTLF). The VFL clients could be an NWDAF (e.g. containing MTLF), a trusted AF, an untrusted AF. In the following procedure, NWDAF will be used as an example for the VFL server. 0. The VFL server NWDAF determines to trigger VFL preparation, e.g. including sample alignment and / or feature alignment. This may trigger by the VFL server internal logics, due to model accuracy requirements / reasons (to improve the accuracy of VFL model training and / or inference results), analytics consumer required analytics from NWDAF then the NWDAF determines to perform VFL model training, etc. Due to security and privacy issues, the VFL server NWDAF and VFL clients NWDAF will not exposure too much internal information to the AF, in particular in the case of untrusted AF. 1. The VFL Server sends a Federated Learning preparation request to each of the VFL Client(s), to check if the VFL client(s) can meet the ML Model training requirement. Same as step 1 and 3 in described with reference to Figure 6 under Procedure for sample and / or feature alignment when AF is the VFL server. The request may include (e.g. Analytics ID, Sample alignment requirement, VFL Availability time requirement (time span needed for the VFL process), etc.). Sample alignment requirement includes a list of sample IDs targeted for VFL training, Analytics ID and optionally Feature ID / feature related information, and associated VFL correlation ID (a ID can correlate the different procedures for a VFL process (e.g. VFL correlation / process ID, VFL ID, VFL model ID, etc.)). - 1.1, For the VFL client NWDAF, the VFL server use Nnwdaf_MLModelTraining_Subscribe or Nnwdaf_MLModelTraininglnfo_Request service as preparation request, or a new NWDAF service operation for preparation subscription or one-shot request. - 1.2, For the VFL client AF, if the AF is trusted AF, the VFL server may use the corresponding AF or NWDAF service for the preparation subscription or one-shot request, e.g. Naf_MLModelTraining_Subscribe or Naf_MLModelTraininglnfo_Request, as detailed in NEF and AF subscribe service operation and NEF and AF information request and response service operation. - 1.3, For the VFL client AF (e.g. if the AF is untrusted AF): o 1.3.1: the VFL server NWDAF sends the VFL preparation, using NEF service operation for preparation request, e.g. Nnef_VFLalignment_Subscribe / Nnef_MLModelTraining_Subscribe or Nnef_VFLalignment_Request / Nnef_MLModelTraininglnfo_Request as detailed in as detailed in NEF and AF subscribe service operation and NEF and AF information request and response service. The VFL server may or may not include the sample IDs in this step, up to VFL server determination. o 1.3.2: optional, if the VFL server include the sample IDs, the NEF stores / keeps the sample IDs. Optional, The NEF may translates the sample IDs, if the IDs are UE IDs, from internal ID (e.g. SUPIs) into external UE IDs (e.g. GPSIs). Optional, the NEF may transfer the external sample / UE IDs (e.g. GPSIs) to VFL client for sample alignment in 1.3.3. In order to protect 5GC and user privacy, the NEF may not transfer any sample IDs to VFL clients untrusted AF. o 1,3.3:Then the NEF forwards the VFL request to the VFL client (untrusted) AF, e.g. using AF services Naf_MLModelTraining_Subscribe or Naf_MLModelTraininglnfo_Request, as detailed in clause NEF and AF subscribe service operation and NEF and AF information request and response service. In the VFL preparation request, - The existing ML Preparation Flag in TS 23.288 might be reused, e.g. if the sample ID and / or feature related information is include in the VFL preparation request, together with the ML Preparation Flag, the VFL client will interpret the request as VFL preparation (e.g. including feature alignment and / or sample alignment). - Introducing a new indication / flag for VFL preparation (e.g. including feature alignment and / or sample alignment) explicitly, e.g. VFL preparation flag, VFL feature alignment and / or sample alignment flag, etc. 2. Each VFL Client checks if it can meet the ML Model training requirement. If it cannot meet the requirements for any reason, it may decide which requirements it can agree to. The same as step 4 is described with reference to Figure 6 under Procedure for sample and / or feature alignment when AF is the VFL server. 3. Each VFL Client to indicate to the VFL Server whether it accepts the requirements, whether it requests new requirements or whether it will not join. The client includes the requirements it can accept or may add a reason if it cannot join the FL process. The same as step 5 and step 7 in described with reference to Figure 6 under Procedure for sample and / or feature alignment when AF is the VFL server. - 3.1, For the VFL client NWDAF, the VFL client use Nnwdaf_MLModelTraining_notify or Nnwdaf_MLModelTraininglnfo_Response service as preparation response, or a new NWDAF service operation for preparation notify or one-shot response, depending on the service operation used in step 1.1. - 3.2, For the VFL client AF, if the AF is trusted AF, the VFL server may use the corresponding AF or NWDAF service for the preparation notify or one-shot response, e.g. Naf_MLModelTraining_Notify or Naf_MLModelTraininglnfo_Response, as detailed under NEF and AF notify service operation and NEF and AF information request and response service operation. - 3.3, For the VFL client AF (e.g. if the AF is untrusted AF): o 3.3.1: the VFL client sends the VFL preparation response, using NEF service operation for preparation response, e.g. Nnef_VFLalignment_Notify / Nnef_MLModelTraining_Notify or Nnef_VFLalignment_Response / Nnef_MLModelTraininglnfo_Response as detailed in as detailed under NEF and AF notify service operation and NEF and AF information request and response service operation. The VFL client include the sample IDs and / or feature ID / feature related information that can be supported by itself. o 3.3.2: the NEF may determine the intersection of sample IDs and / or feature ID / feature related information among VFL client (untrusted) AFs, if more than one VFL client (untrusted) AFs are involved. ■ Optional, if the VFL server include the sample IDs in step 1.3.1, the NEF may determine the intersection among VFL client (untrusted) AFs and VFL server. ■ The NEF may determine the intersection of sample IDs using external IDs and / or internal IDs. e.g. the NEF may translate the sample IDs indicated by VFL server into external IDs (e.g. in step 1.3.2) to the calculate the intersection; then the NEF translates the interested sample IDs into internal IDs and send back to VFL server NWDAF. Or, the NEF may translate the supported sample IDs of each VFL clients (untrusted) AF from external IDs into internal IDs to calculate the intersection; then the NEF transfer the intersected sample IDs to VFL server. This may be based on NEF implementation. o 3.3.3:Then the NEF forwards the VFL response to the VFL server, e.g. using NEF services Nnef_MLModelTraining_Notify or Nnef_MLModelTraininglnfo_Response, as detailed under NEF and AF notify service operation and NEF and AF information request and response service operation. If the notify or response includes new requested requirements, procedure from step 1 is repeated. 4. The VFL Server NWDAF determines the VFL Client(s) to be involved in the FL procedures based on the information received in previous step and other information / requirements. The same as step 8 described with reference to Figure 6 under Procedure for sample and / or feature alignment when AF is the VFL server. For UEs as samples, IDs of register and / or registered UEs can be considered as sample IDs. If the UEs are registered, the network may require / trigger UE registration, if needed, e.g. for UE related data collection purpose for VFL sample and / or feature alignment, VFL model training, VFL inference. Before determining the sample IDs for the VFL procedure, e.g. determined by the VFL server / VFL consumer / analytics consumer, the information of the interested UEs might be checked from 5GC NF (e.g. from AMF, NRF, UDM / UDR, etc.), e.g. the registration status, mobility information, capabilities, UE type etc. If unregistered UEs were chosen as sample IDs, the network may determine to require / trigger UE registration. Or the unregistered UEs will not be chosen as sample IDs. After determining the sample IDs for the VFL procedure, e.g. determined by the VFL server / VFL consumer / analytics consumer, the information of the interested UEs might be checked from 5GC NF (e.g. from AMF, NRF, UDM / UDR, etc.), e.g. the registration status, mobility information, capabilities, UE type etc. If unregistered UEs were chosen as sample IDs, the network may determine to require / trigger UE registration. Or the unregistered UEs will be taken out of the determined sample IDs; then the VFL server may perform the VFL preparation procedure again for VFL sample ID refinement. Service (Operations') to support VFL Sample and / or Feature Alignment In the procedure described above, AF, NWDAF and NEF service and service operations are needed to enable the sample and / or feature alignment subscription and notify, information request and response, unsubscribe, etc. - Subscribe-Notify model: VFL sample and / or feature alignment subscription (request) service operation is to initiate / trigger the VFL sample and / or feature alignment at VFL client (or NEF) by the VFL server (via NEF). The Notify service operation is to notify the outcome / output information from the VFL client based on VFL request for sample and / or feature alignment. o The notify service operation might be also used by the VFL server to inform the VFL client of the behaviours / decision, intermediate results / output / computational results. E.g. the VFL client may notify the VFL server that it terminates / quits the VFL sample and / or feature alignment operation, with cause code (e.g. limited capability / ability, overloaded, have more urgent / higher priority tasks, etc.) - Request-Response model: VFL sample and / or feature alignment information request service operation is to initiate / trigger the VFL sample and / or feature alignment at VFL client (or NEF) by the VFL server (via NEF). The information response (service operation) is to report / inform / send the outcome / output information from the VFL client based on VFL request for sample and / or feature alignment. - Unsubscribe service (operation) might be used by the VFL server to terminate the sample and / or feature alignment related operations at the VFL client NWDAF Service (Operation) for Sample and / or Feature Alignment NWDAF service (operation) for sample and / or feature alignment include one or more of the following: - subscription and notify service operation - information request and response service operation - unsubscribe service operation The above NWDAF service (operation) for sample and / or feature alignment allows the VFL server (via NEF if the VFL server is (untrusted) AF) to request the VFL client NWDAF to perform the required VFL sample and / or feature alignment. NWDAF Subscribe Service Operation The NWDAF subscription service operation enables the VFL server (via NEF if the VFL server is (untrusted) AF) to subscribe to the VFL NWDAF client with specific parameter for sample and / or feature alignment. The NWDAF subscription service operation might be a new service specified in 3GPP specifications, e.g. Nnwdaf_VFLalignment_Subscribe service operation; or may reuse existing service operation with enhancements, e.g. reuse existing Nnwdaf_MLModelTraining_Subscribe service operation etc. Inputs: one or more of the following (provided by the VFL server to VFL clients) - one or more of the required parameters in VFL sample and / or feature requirement information that is detailed above. - Analytics ID - the VFL client ID(s), e.g. (internal or external) NWDAF (instance) ID - Notification Target Address, Notification Correlation ID, VFL (process) ID, VFL Correlation ID (to Correlated the VFL server, clients, model, etc. Related to VFL process (e.g. model training and / or inference)). - Indication(s) / flags for VFL feature alignment and / or sample alignment. This indication may be indicated together with Indication(s) / flags for VFL preparation, or can be indicated separately in the subscription request. - Indication(s) / flags for VFL preparation. This indication may use together with -Indication(s) / flags for VFL feature alignment and / or sample alignment. The Indication(s) / flags for VFL preparation can be also used to indicate the VFL preparation including feature alignment and / or sample alignment. - ML Preparation Flag: the existing ML Preparation Flag in TS 23.288 might be reused, e.g. if the sample ID and / or feature related information and other VFL preparation related information is include in the VFL preparation request, together with the ML Preparation Flag, the VFL client will interpret the request as VFL preparation (e.g. including feature alignment and / or sample alignment). - If sample alignment is initiated, sample ID(s), e.g. UE IDs, UE group ID (which links to one or more UEs in the group), NF (instance) IDs, NF set IDs, slices IDs, etc.) o The sample IDs might be grouped based on priority or the necessity that to be supported by the VFL process. o E.g. some samples are must to be supported (in higher priority), some samples are optionally supported (in medium priority), some sample are in lower priority, etc. o In different priorities of the samples are indicated, in VFL client’s response, the VFL client may group the sample(s) it can and / or cannot support in the same way. E.g. sample ID 1,2,3 in higher priority can be supported, or sample ID 4, 5 in higher priority cannot be supported; sample ID 7,8 in medium priority can be supported, and / or sample ID 10., 11 in medium priority cannot be supported, etc. - If feature alignment is triggered, feature ID(s) / feature profile / container / context, or features associated to the (output of the) analytics ID might be provided. The provided features could be o the overall features to be supported by the VFL process, e.g. the feature collection of all VFL clients. Same features provided to all VFL clients; o Different features provided to different VFL clients, e.g. based on discovery and other priory knowledge of VFL server, the server roughly understand the features that can be supported by each VFL clients. Therefore, the VFL server associates different expected VFL features to different VFL clients / VFL client IDs. o The content of feature profile / container / context may not be specified by 3GPP. Outputs: one or more of the following (provided to the VFL server by VFL clients): - Subscription Correlation ID, VFL (process) ID, VFL Correlation ID (required for management of this subscription / VFL process / VFL model, etc.). - When the request is accepted: Subscription Correlation ID, VFL (process) ID, VFL Correlation ID (required for management of this subscription / VFL process / VFL model, etc.). - When the request is not accepted, an error response with cause code (e.g. NWDAF does not meet the VFL sample and / or feature alignment requirement, cannot support the sample and / or feature alignment requirement, cannot perform further VFL training requirements and / or inference associated to the sample and / or feature alignment, VFL model training / inference / sample and / or feature alignment is not complete, VFL client is overloaded, not available for the VFL process anymore (due to operator configuration), etc.). NWDAF Unsubscribe Service Operation The NWDAF unsubscribe service operation enables the VFL server (via NEF if the VFL server is (untrusted) AF) to unsubscribe to or terminate the sample and / or feature alignment at the VFL NWDAF client. The NWDAF unsubscribe service operation might be a new service specified in 3GPP specifications, e.g. Nnwdaf_VFLalignment_Unsubscribe service operation; or may reuse existing service operation with enhancements, e.g. reuse existing Nnwdaf_MLModelTraining_Unsubscribe service operation etc. Inputs: one or more of the following (provided by the VFL server to VFL clients) - Subscription Correlation ID, Notification Correlation ID, VFL (process) ID, VFL Correlation ID which can correlated the subscription (request), VFL server, clients, VFL model, model training process, inference process etc. Outputs: one or more of the following (provided to the VFL server by VFL clients): - Operation execution result indication. - Cause code, e.g. o VFL Client NWDAF is unselected by the VFL Server NWDAF for the VFL related process o VFL sample and / or feature alignment, VFL model training process, VFL inference process) o The VFL (sample and / or feature alignment) process is suspended or finished, etc.). o Final aggregated VFL sample and / or feature alignment, Model training and / or inference information (if VFL has finished) or updated aggregated ML Model information (e.g., if VFL process is suspended). NWDAF Notify Service Operation The NWDAF notify operation enables the VFL client NWDAF to notify the VFL server (via NEF if the server is untrusted AF) that has subscribed to specific NWDAF services (e.g. subscription for VFL sample and / or feature alignment). The NWDAF can also use this service to indicate to consumer / VFL server it will terminate the VFL sample and / or feature alignment. The NWDAF notify service operation might be a new service specified in 3GPP specifications, e.g. Nnwdaf_VFLalignment_Notify service operation; or may reuse existing service operation with enhancements, e.g. reuse existing Nnwdaf_MLModelTraining_Notify service operation etc. Inputs: one or more of the following (provided to the VFL server by VFL clients): - Notification Correlation Information: this parameter indicates the Notification Correlation ID that has been assigned by the consumer e.g. during VFL sample and / or feature alignment, associated VFL Model training and / or inference. - Subscription Correlation ID, Notification Correlation ID, VFL (process) ID, VFL Correlation ID which can correlated the subscription (request), VFL server, clients, VFL model, model training process, inference process etc. - Analytics ID, the one provided in the subscribe service operation. - Sample IDs and / or associated ‘supported’ / ’not supported’ indication: include one or more of the following: o Sample IDs that can be supported by the VFL client NWDAF, and / or associated indication to clarify the samples are supported, e.g. list of samples IDs associated to ‘supported’ flag o Sample IDs that cannot be supported by the VFL client NWDAF, and / or associated indication to clarify the samples are not supported, e.g. list of samples IDs associated to ‘not supported’ flag o If different priorities / groups of the samples are indicated in the associated subscribe service operation, the VFL client provide the supported and / or not supported samples based on the / associated to the each given priorities / groups. - The feature ID / feature profile / context / container to indicate the features can and / or cannot be supported by the VFL client NWDAF, including one or more of the following: o Supported feature profile / context / container and / or associated indication to clarify the feature are supported, e.g. feature profile / context / container associated to ‘supported’ flag; o Not supported feature profile / context / container and / or associated indication to clarify the feature are not supported, e.g. feature profile / context / container associated to ‘not supported’ flag; - Termination Request: this parameter indicates that VFL client NWDAF requests to terminate the sample and / or feature alignment, e.g. VFL client NWDAF will not provide further sample and / or feature alignment related notifications for this subscription / request, with cause code Outputs: Operation execution result indication. NWDAF Information Request and Response Service Operation The NWDAF information request and response service operations enables the VFL server (via NEF if the VFL server is (untrusted) AF) to request information from the VFL NWDAF client with specific parameter for sample and / or feature alignment. Inputs: one or more of the following (provided by the VFL server to VFL clients) - one or more of the required parameters in VFL sample and / or feature requirement information that is detailed above. - Analytics ID - the VFL client ID(s), e.g. (internal or external) NWDAF (instance) ID - Notification Target Address, Notification Correlation ID, VFL (process) ID, VFL Correlation ID (to Correlated the VFL server, clients, model, etc. Related to VFL process (e.g. model training and / or inference)). - Indication(s) / flags for VFL feature alignment and / or sample alignment. This indication may be indicated together with Indication(s) / flags for VFL preparation, or can be indicated separately in the subscription request. - Indication(s) / flags for VFL preparation. This indication may use together with -Indication(s) / flags for VFL feature alignment and / or sample alignment. The Indication(s) / flags for VFL preparation can be also used to indicate the VFL preparation including feature alignment and / or sample alignment. - If sample alignment is initiated, sample ID(s), e.g. UE IDs, UE group ID (which links to one or more UEs in the group), NF (instance) IDs, NF set IDs, slices IDs, etc.) o The sample IDs might be grouped based on priority or the necessity that to be supported by the VFL process. o E.g. some samples are must to be supported (in higher priority), some samples are optionally supported (in medium priority), some sample are in lower priority, etc. o In different priorities of the samples are indicated, in VFL client’s response, the VFL client may group the sample(s) it can and / or cannot support in the same way. E.g. sample ID 1,2,3 in higher priority can be supported, or sample ID 4, 5 in higher priority cannot be supported; sample ID 7,8 in medium priority can be supported, and / or sample ID 10., 11 in medium priority cannot be supported, etc. - If feature alignment is triggered, feature ID(s) / feature profile / container / context, or features associated to the (output of the) analytics ID might be provided. The provided features could be o the overall features to be supported by the VFL process, e.g. the feature collection of all VFL clients. Same features provided to all VFL clients; o Different features provided to different VFL clients, e.g. based on discovery and other priory knowledge of VFL server, the server roughly understand the features that can be supported by each VFL clients. Therefore, the VFL server associates different expected VFL features to different VFL clients / VFL client IDs. o The content of feature profile / container / context may not be specified by 3GPP. Outputs: one or more of the following (provided to the VFL server by VFL clients): - Subscription Correlation ID, VFL (process) ID, VFL Correlation ID (required for management of this subscription / VFL process / VFL model, etc.). - When the request is accepted: Subscription Correlation ID, VFL (process) ID, VFL Correlation ID (required for management of this subscription / VFL process / VFL model, etc.). - When the request is not accepted, an error response with cause code (e.g. NWDAF does not meet the VFL sample and / or feature alignment requirement, cannot support the sample and / or feature alignment requirement, cannot perform further VFL training requirements and / or inference associated to the sample and / or feature alignment, VFL model training / inference / sample and / or feature alignment is not complete, VFL client is overloaded, not available for the VFL process anymore (due to operator configuration), etc.). - The sample IDs that can be supported and / or cannot be supported by the VFL client / VFL server. - The feature ID / feature profile / context / container to indicate the features can and / or cannot be supported by the VFL client NWDAF. NEF and AF Service (Operation) for Sample and / or Feature Alignment NEF and AF Subscribe Service Operation The NEF and AF subscription service operation enables the VFL server subscribe to the VFL clients with specific parameter for sample and / or feature alignment. The NEF and AF subscription service operation might be new services specified in 3GPP specifications, e.g. Nnef_VFLalignment_Subscribe / Nnef_MLModelTraining_Subscribe, Naf_VFLalignment_Subscribe / Naf_MLModelTraining_Subscribe service operations; or may reuse existing service operation with enhancements, e.g. reuse existing Nnef_event exposure_Subscribe Naf_event exposure_Subscribe service operation etc. AF subscription service operation is used when the VFL client is AF: - For untrusted AF, the VFL client receives the AF subscribe service request from NEF, e.g. step 1c3 in Figure 5. - For (trusted) AF, the VFL client may receive the AF subscribe service request from NEF, e.g. step 1c3 in Figure 5; or receive the AF subscribe service request from VFL server (e.g. NWDAF), e.g. 1b in Figure 5. NEF subscription service operation is used when the VFL server is (untrusted) AF or the VFL client is untrusted) AF: - If the VFL server is (untrusted) AF, the NEF receives the NEF subscribe service request from the VFL server (untrusted) AF, e.g. step 1 c1 in Figure 5. The NEF invokes NWDAF subscribe service for sample and / or feature alignment towards the NWDAF VFL clients, e.g. step 1c4 Figure 5. - If the VFL client is (untrusted) AF, the NEF receives the NEF subscribe service request from the VFL server (e.g. (trusted) AF or NWDAF), e.g. step 1 c1 in Figure 5. Then the NEF invokes the AF subscribe service for sample and / or feature alignment towards the VFL client (untrusted) AF, e.g. step1c3 in Figure 5. In inputs and outputs of the NEF and AF subscribe service operation for VFL sample and / or feature alignment are the same as those above for NWDAF subscribe service operation. NEF and AF Unsubscribe Service Operation The NEF and AF unsubscribe service operation enables the VFL to unsubscribe to or terminate the sample and / or feature alignment at the VFL client (e.g. (trusted) AF and / or untrusted AF). The NEF and AF unsubscribe service operation might be new services specified in 3GPP specifications, e.g. Nnef_VFLalignment_Unsubscribe, Naf_VFLalignment_Unsubscribe service operations; or may reuse existing service operation with enhancements, e.g. reuse existing Nnef_event exposure_Unsubscribe Naf_event exposure_Unsubscribe service operation etc. AF unsubscribe service operation is used when the VFL client is AF: - For untrusted AF, the VFL client receives the AF unsubscribe service request from NEF, e.g. step 1c3 in Figure 5. - For (trusted) AF, the VFL client may receive the AF unsubscribe service request from NEF, e.g. step 1c3 in Figure 5; or receive the AF subscribe service request from VFL server (e.g. NWDAF), e.g. 1b in Figure 5. NEF unsubscribe service operation is used when the VFL server is (untrusted) AF or the VFL client is (untrusted) AF: - If the VFL server is (untrusted) AF, the NEF receives the NEF unsubscribe service request from the VFL server (untrusted) AF, e.g. step 1 c1 in Figure 5. The NEF invokes NWDAF unsubscribe service for sample and / or feature alignment towards the NWDAF VFL clients, e.g. step 1c4 in Figure 5. - If the VFL client is (untrusted) AF, the NEF receives the NEF unsubscribe service request from the VFL server (e.g. (trusted) AF or NWDAF), e.g. step 1 c1 in Figure 5. Then the NEF invokes the AF unsubscribe service for sample and / or feature alignment towards the VFL client (untrusted) AF, e.g. step1c3 in Figure 5. In inputs and outputs of the NEF and AF unsubscribe service operation for VFL sample and / or feature alignment are the same as those above for NWDAF unsubscribe service operation. NEF and AF Notify Service Operation The NEF and AF notify operation enables the VFL client to notify the VFL server (e.g. (trusted and / or untrusted) AF that has subscribed to specific AF services (e.g. subscription for VFL sample and / or feature alignment). The AF or NEF may also use this service to indicate to consumer / VFL server it will terminate the VFL sample and / or feature alignment. The NEF and AF notify service operation might be a new service specified in 3GPP specifications, e.g. Naf_VFLalignment_Notify / Naf_MLModelTraining_Notify, Nnef_VFLalignment_Notify / Nnef_MLModelTraining_Notify service operation; or may reuse existing service operation with enhancements, e.g. reuse existing Nnef_event exposure_Notify, Naf_event exposure_Notify service operation, etc. AF and / or NEF notify service operations ae used by VFL clients, e.g. - For untrusted AF VFL clients, the VFL client sends the NEF notify to NEF, e.g. step 4c1 in Figure 5. The NEF invokes AF notify service operation towards the VFL server, e.g. step 4c3 in Figure 5. - For (trusted) AF, the VFL client may invoke the NEF notify service request to NEF, e.g. step 4c1 then 4c3 in Figure 5; or invokes AF notify service request towards VFL server (e.g. NWDAF), e.g. step 4b in Figure 5. In inputs and outputs of the NEF and AF notify service operation for VFL sample and / or feature alignment are the same as those above for NWDAF notify service operation. NEF and AF Information Request and Response Service Operation The NEF and AF information request enables the VFL server to request the VFL clients to enable VFL sample and / or feature alignment and / or provide the request information related to VFL sample and / or feature alignment. The NEF and AF information request service operation might be a new service specified in 3GPP specifications, e.g. Naf_VFLalignment_Request / Naf_MLModelTraininglnfo_Request, Nnef_VFLalignment_Request / Nnef_MLModelTraininglnfo_Request service operation; or may reuse existing service operation with enhancements. In inputs and outputs of the NEF and AF information request and response service operation for VFL sample and / or feature alignment are the same as those above for NWDAF information request and response service operation. Further Examples Figures 8 and 9 provide further examples of the procedures described above. Preparation Procedure for Vertical Federated Learning Preparation procedure is used to check if the VFL Client(s) can meet the ML Model training requirement. The procedure includes the negotiation, between server and client(s) to enable interoperability, sample alignment and optionally feature alignment. NOTE 1: Features can be non-specified, privacy protected and in this case feature alignment is a simple alignment using info registered in NRF, e.g. data sources info or proprietary Feature ID). NOTE 2: Vertical Federated Learning preparation procedure can be skipped if the VFL Server can decide which VFL Client(s) support the VFL procedure to be performed, e.g. based on local configuration. Figure 8 illustrates a preparation procedure for vertical federated learning when an NWDAF is the VFL server and its steps are described below. 1. The VFL Server sends a Federated Learning preparation request to each of the VFL Client(s) with a VFL Preparation Flag. The Server may add a list of sample IDs, Analytics ID and optionally Feature ID. For the VFL client NWDAF or VFL client AF, the VFL server invokes Nnwdaf_MLModelTraining_Subscribe or Nnwdaf_MLModelTraininglnfo_Request service. For the VFL client untrusted AF, the VFL server sends the Federated Learning preparation request via NEF. The NEF may maps the internal IDs of the samples into external IDs before sending the Federated Learning preparation request to the untrusted AF VFL client. 2. Each VFL Client checks if it can meet the ML Model training requirement. If it cannot meet the requirements for any reason, it may decide which requirements it can agree to. 3. Each VFL Client sends Federated Learning preparation response to indicate to the VFL Server whether it accepts the requirements, whether it requests new requirements or whether it will not join. The client includes the requirements it can accept or may add a reason if it cannot join the FL process. The VFL Client also includes the sample ID(s) and optionally Feature ID(s) it can support. For the VFL client NWDAF or VFL client AF, the VFL client invokes invokes Nnwdaf_MLModelTraining_Notify or Nnwdaf_MLModelTraininglnfo_Request response service operation, based on the service operation used in step 1. For the VFL client untrusted AF, the VFL client sends the Federated Learning preparation response to the VFL server via NEF. The NEF may maps the external IDs of the samples into internal IDs before sending the Federated Learning preparation response to the VFL server NWDAF. If the notify or response includes new requested requirements, procedure from step 1 is repeated. 4. The VFL Server NWDAF determines the VFL Client(s) to be involved in the VFL procedures based on the information received in step 6 in Figure 6.2H.2.1-1 (if performed) and other information (e.g. sample IDs and optional the feature IDs can be supported by each VFL client) received in step 3 (if available). Preparation Procedure for Vertical Federated Learning when an Untrusted AF is the VFL Server This example specifies the preparation (including sample alignment) procedure for untrusted-AF-initiated VFL scenarios between untrusted AF and NWDAF(s) within a single PLMN. Figure 9 illustrates a preparation procedure for vertical federated learning when an untrusted AF is the VFL server. 1- The untrusted AF as VFL server sends VFL preparation request to the candidate VFL client(s) NWDAF via NEF with a VFL Preparation Flag to check if the VFL client(s) can meet the ML Model training requirement (e.g. Analytics ID, Sample alignment requirement, VFL Availability time requirement (time span needed for the VFL process), optional feature requirement, etc.). Sample alignment requirement and feature alignment requirement (if any) include a list of sample IDs and feature IDs targeted for VFL training as defined by the AF, respectively. 2- The NEF maps the external UE IDs (e.g. GPSIs) to the internal UE IDs (e.g. SUPIs). The NEF sends VFL preparation request to each candidate VFL client using Nnwdaf_MLModelTraining_Subscribe or Nnwdaf_MLModelTraininglnfo_Request service when multiple candidate VFL clients are involved with the same information as provided in step 1 in Figure 9. 3- Same as step 1 in Figure 9. 4- Same as step 2 in Figure 9. 5- Same as step 3 in Figure 9. 6- When multiple candidate VFL clients are involved, the NEF may aggregate the response from each candidate VFL client The NEF determines the sample ID intersection among the VFL clients (if more than one VFL clients are involved) based on the information received in step 5. Then the NEF only maps the intersected sample IDs from internal IDs into external IDs and include the interested sample IDs into VFL Preparation response message to the untrusted AF.. 7- The NEF sends VFL preparation response to VFL server to indicate the intersect sample IDs among the VFL clients and other received information. 8- The VFL Server AF determines the VFL Client(s) to be involved in the VFL procedures. Figure 10 is a block diagram of an exemplary network entity that may be used in examples of the present disclosure. For example, the UE, AMF, SMF, UPF, NWDAF, AF and / or other NFs may be provided in the form of the network entity illustrated in Figure 10. The skilled person will appreciate that the network entity illustrated in Figure 10 may be implemented, for example, as a network element on a dedicated hardware, as a software instance running on a dedicated hardware, or as a virtualised function instantiated on an appropriate platform, e.g. on a cloud infrastructure. The entity 1000 comprises a processor (or controller) 1001, a transmitter 1003 and a receiver 1005. The receiver 1005 is configured for receiving one or more messages or signals from one or more other network entities. The transmitter 1003 is configured for transmitting one or more messages or signals to one or more other network entities. The processor 1001 is configured for performing one or more operations and / or functions as described above. For example, the processor 1001 may be configured for performing the operations of an UE, AMF, SMF, UPF, NWDAF, AF and / or other NFs. The terms and words used herein are not limited to the bibliographical or standard meanings, but, are merely used to enable a clear and consistent understanding of the examples disclosed herein. Throughout the description and claims, the words “comprise”, “contain” and “include”, and variations thereof, for example “comprising”, “containing” and “including”, means “including but not limited to”, and is not intended to (and does not) exclude other features, elements, components, integers, steps, processes, functions, characteristics, and the like. Throughout the description and claims, the singular form, for example “a”, “an” and “the”, encompasses the plural unless the context otherwise requires. For example, reference to “an object” includes reference to one or more of such objects. Throughout the description and claims, language in the general form of “X for Y” (where Y is some action, process, function, activity or step and X is some means for carrying out that action, process, function, activity or step) encompasses means X adapted, configured or arranged specifically, but not necessarily exclusively, to do Y. Features, elements, components, integers, steps, processes, functions, characteristics, and the like, described in conjunction with a particular aspect, embodiment, example or claim are to be understood to be applicable to any other aspect, embodiment, example or claim disclosed herein unless incompatible therewith. Furthermore, one or more of the steps of the methods described herein may be omitted or reordered, and / or further steps may be introduced. While the invention has been shown and described with reference to certain examples, it will be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the scope of the invention, as defined by the appended claims.

Claims

1. A method for vertical federated learning (VFL) in a wireless communications system, the wireless communications system comprising a VFL server and one or more VFL clients, the method comprising:transmitting, from the VFL server to the one or more VFL clients, a request for the VFL clients to indicate support information for a VFL process;determining, by the VFL clients, respective support information for the VFL process;transmitting, from the VFL clients to the VFL server, the respective support information for the VFL process; anddetermining, by the VFL server, parameters of the VFL process based on the received support information.

2. The method of claim 1, wherein the support information for the VFL process includes an indication of sample IDs and / or feature IDs supported by the respective VFL client.

3. The method of any preceding claim, wherein, if the request does not include an indication of one or more sample IDs associated with the VFL process and / or feature IDs associated with the VFL process, the support information includes an indication of all sample IDs and / or feature IDs supported by the VFL client.

4. The method of any preceding claim, wherein, if the request includes an indication of one or more of: sample IDs associated with the VFL process, feature IDs associated with the VFL process, and a time window associated with the sample IDs and / or feature IDs, the support information includes an indication of the one or more sample IDs and / or feature IDs associated with the VFL process supported by the VFL client.

5. The method of any preceding claim, wherein the determining parameters of the VFL process includes determining one or more of: the VFL clients to include in the VFL process, the sample ID(s) to be used in the VFL process, and the feature ID(s) to be used in the VFL process per VFL client.

6. The method of any preceding claim, wherein, if a VFL client cannot join the VFL process, the VFL includes an indication that the VFL client cannot join the VFL process in the support information.

7. The method of claim 6, wherein the indication that the VFL client cannot join the VFL process includes a cause code.

8. The method of claims 6 or 7, wherein the cause of the VFL client not being able to join the VFL process includes one or more of limited capability, overload, higher priority tasks, VFL client does not meet sample and / or feature alignment requirements, VFL client cannot support sample and / or feature alignment requirements, VFL client cannot perform further training or inference, and VFL client is not available for the VFL process.

9. The method of any preceding claim, wherein each of the VFL server and VFL clients is a trusted or an untrusted application function (AF) or network data analytics function (NWDAF).

10. The method of any preceding claim, wherein, if the VFL server is an untrusted AF or an untrusted NWDAF, the request and the support information are transmitted via a network exposure function (NEF).

11. The method of any preceding claim, wherein if a VFL client is an untrusted AF or an untrusted NWDAF, the request and the support information is transmitted via an NEF.

12. The method of claims 10 or 11, wherein, the NEF maps the sample IDs from an internal ID to an external ID.

13. The method of claim 12, wherein the internal ID is a subscription permanent identifier (SUPI) and the external ID is a generic public subscription identified (GPSI).

14. The method of any of claims 10 to 13, wherein the NEF determines an intersection between support information provided by the VFL clients, and provides an indication of the intersection to the VFL server.

15. The method of any preceding claim, wherein the request is a sample and / or feature alignment request.

16. The method of any preceding claim, wherein the request includes an analytics ID associated with the VFL process, and the determining of the support information is based on the analytics ID.

17. The method of any preceding claim, wherein the request for the VFL clients to indicate support information fora VFL process is a NWDAF information request service operation.

18. The method of any preceding claim, wherein the respective support information for the VFL process is included in a NWDAF information response service operation.

19. The method of any preceding claim, wherein the method is performed as part of a VFL preparation phase.

20. A method for a VFL server in a wireless communications system comprising the VFL server and one or more VFL clients , the method comprising:transmitting, to the one or more VFL clients, a request for the VFL clients to indicate support information for a VFL process;receiving, from the VFL clients, respective support information for the VFL process; anddetermining, by the VFL server, parameters of the VFL process based on the received support information.

21. A method for a VFL client in a wireless communications system comprising a VFL server and one or more VFL clients, the method comprising:receiving, from the VFL server, a request for the VFL clients to indicate support information for a VFL process;determining support information for the VFL process; andtransmitting, to the VFL server, the support information for the VFL process.

22. A wireless communications system comprising a VFL server and one or more VFL clients, wherein the wireless communications system is configured to perform the method of any of claims 1 to 19.

23. A VFL server for a wireless communication system, wherein the VFL server is configured to perform the method of claim 20.

24. A VFL client for a wireless communications system, wherein the VFL client is configured to perform the method of claim 21.

Images