Step 1.
An NWDAF as VFL Server may send a Vertical Federated Learning preparation request including the Analytics ID to each of the NWDAF VFL Client(s), using
Nnwdaf_VFLTraining_Request and to each of the AF VFL Clients(s), using
Naf_VFLTraining_Request possibly via NEF when the VFL Client is an untrusted AF. An AF as VFL Server may send a Vertical Federated Learning preparation request including the Analytics ID to each of the NWDAF VFL Client(s), using
Nnwdaf_VFLTraining_Request. The NWDAF or trusted AF as a VFL Server may also provide, the suggested VFL Interoperability Information to negotiate the intermediate results that will be used in VFL process (e.g, VFL training and/or VFL inference), the suggested list of sample IDs (e.g, SUPI(s), GPSI(s)) expected to be used in the VFL process. Optionally the feature ID(s) together with VFL Interoperability indicator expected to be used in VFL process for each VFL Client, and as additional criteria for sample alignment, time window of the data samples, and required minimum sample size. When a Trusted AF is acting as a VFL Server, the VFL Client can only be an NWDAF.
Step 2.
Each VFL Client checks if it can meet the ML Model training requirement. Each VFL Client checks the list of sample IDs and required criteria for sample alignment suggested by the VFL Server and then provides to the VFL Server the list of sample IDs that it can accept within the sample IDs suggested by the VFL Server and satisfying the required criteria for sample alignment. If the suggested list of sample IDs is not provided by the VFL Server, the VFL Client provides the list of supported sample IDs to the VFL Server. Each VFL Client checks the VFL Interoperability Information and determines which VFL Interoperability information that the VFL Client supports. The VFL Client determines whether it supports the feature ID(s) that will be used in VFL process when the feature ID(s) was provided by the VFL Server; alternatively, the VFL Clients may provide the list of supported feature ID(s), which is associated to the VFL Interoperability information, to the VFL Server, or VFL Server may know the supported featureID(s) for a VFL Client based on configuration.
Step 3.
Each NWDAF VFL Client invokes Nnwdaf_VFLTraining_Response or and each AF VFL Client invokes Naf_VFLTrainingRequest_Response, possibly via NEF when the AF is untrusted, to indicate to the VFL Server whether it accepts the ML Model training requirements, the VFL Client can also indicate that it cannot join the FL process. When NEF is involved in the procedure, if the NEF receives the SUPI as sample ID(s) from NWDAF, the NEF shall map the SUPI(s) to GPSI(s) before sending to the AF.
Step 4.
The VFL Server determines the final list of samples ID(s) that all selected VFL Client(s) support as the samples to be used in the VFL process. If the VFL Server is NWDAF, it may map the sample ID(s) in different types (e.g, SUPI, GPSI) from the VFL Client(s) into same format (i.e SUPI) as described in
clause 6.2.8.2.4.4 before determining the final list of sample ID(s). The VFL Server also determines the feature ID(s) per VFL Client and VFL Interoperability Information to be used in VFL process and provides them to the selected VFL Client(s) at the start of the training phase, as described in
clause 6.2H.2.3.1.