The 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 may include feature negotiation if the VFL Server did not learn the supported FeatureIDs from each VFL Client using the discovery phase, alternatively the VFL Server may know the supported FeatureIDs by a VFL Client based on configuration. The 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 or offline procedures.
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.
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.
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.
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.
This clause specifies the preparation (including sample alignment) procedure for untrusted AF-initiated VFL scenarios between AF and NWDAF(s) within a single PLMN.
The untrusted AF as VFL server first determines the VFL client(s) of VFL process(es), NEF ID and external NWDAF ID(s) of all selected VFL Client(s) for each VFL process and uses it subsequent interactions with the NEF.
The untrusted AF as VFL server sends VFL preparation requests to each of the candidate VFL client(s), using Nnef_VFLTrainingRequest_Request to check if the VFL client(s) can meet the ML Model training requirement (which includes the Analytics ID, list of sample IDs, and optionally Feature ID, etc.). The external NWDAF IDs obtained in the discovery procedure (see clause 6.2H.2.1.1) is included to indicate the target NWDAFs. The suggested VFL Interoperability Information to negotiate the intermediate resuls that will be used in training.
The NEF maps the external NWDAF and GPSI(s) to the internal NWDAF and SUPI(s). The NEF send VFL preparation request to the corresponding candidate internal NWDAF ID using Nnwdaf_VFLTraining_Request service with the same information as provided in step 1 in clause 6.2H.2.2.1.
An NWDAF VFL client that aggregates the results of other VFL clients may determine to sends VFL preparation requests to the other VFL clients during the preparation procedure.
An NWDAF VFL client that interacted with additional NWDAF VFL client(s) in step 2 receives responses from each of those client(s) and aggregates the response(s) and own information to complete the response to the VFL server.
The NEF maps the internal NWDAF and SUPI(s) to the external NWDAF and GPSI(s). The NEF sends the Nnef_VFLTraining_Request Response to the VFL Server with the same information as provided in step 4.