Content for TS 23.288 Word version: 19.1.0

1… 4… 5… 5A… 6… 6.1.3 6.1.4… 6.1.4.4… 6.1.5… 6.1A… 6.1B… 6.1B.2.3… 6.1C 6.2… 6.2.3… 6.2.6… 6.2.6.2 6.2.6.3… 6.2.6.3.3 6.2.6.3.4 6.2.6.3.5 6.2.6.3.6… 6.2.7… 6.2.8… 6.2.9… 6.2.13… 6.2A… 6.2B… 6.2B.3 6.2B.4… 6.2C… 6.2D… 6.2E… 6.2F… 6.2H… 6.2H.2.2… 6.2H.2.3… 6.2H.2.4… 6.3… 6.4… 6.5… 6.6… 6.7… 6.7.3… 6.7.4… 6.7.5… 6.8… 6.9… 6.10… 6.11… 6.12… 6.13… 6.14… 6.16… 6.17… 6.18… 6.19… 6.20… 6.21… 6.22… 6.23… 7… 7.4… 7.7… 7.9… 8… 9… 10…

6.2H Vertical Federated Learning among NWDAFs and AFs 6.2H.1 General 6.2H.2 Procedures 6.2H.2.1 Registration and Discovery procedure for Vertical Federated Learning 6.2H.2.1.1 Registration and Discovery procedure for Vertical Federated Learning when NWDAF is acting as the VFL server 6.2H.2.1.2 Registration and Discovery procedure for Vertical Federated Learning when untrusted AF is acting as the VFL server
...

6.2H Vertical Federated Learning among NWDAFs and AFs |R19| p. 161

6.2H.1 General p. 161

This clause specifies procedures for Vertical Federated learning where AFs and NWDAF can can either act as VFL servers or VFL clients. Procedures for registration and discovery, for VFL training preparation, for VFL training, and for VFL inference are covered.

Both the VFL server and VFL client store the VFL model after finishing the VFL training process and use the same VFL local model to perform the VFL inference later based on the VFL correlation ID. The differences between the VFL training and inference are that for the inference there is no check of the labels, nor any server intermediate results are sent and as such only client intermediate results are sent to the server.

6.2H.2 Procedures p. 162

6.2H.2.1 Registration and Discovery procedure for Vertical Federated Learning p. 162

6.2H.2.1.1 Registration and Discovery procedure for Vertical Federated Learning when NWDAF is acting as the VFL server p. 162

Reproduction of 3GPP TS 23.288, Fig. 6.2H.2.1.1-1: Registration and Discovery procedure for Vertical Federated Learning when NWDAF is acting as VFL server and NWDAF(s) and/or AF(s) are the VFL clients

Figure 6.2H.2.1.1-1: Registration and Discovery procedure for Vertical Federated Learning when NWDAF is acting as VFL server and NWDAF(s) and/or AF(s) are the VFL clients

Steps 1 to 3 are the NWDAF and AF Registration procedures when the VFL server is NWDAF.

Step 1a.

VFL Server NWDAF registers to NRF with its NF profile, which includes NF Type (i.e. NWDAF type), Analytics ID(s), service area if available, VFL capability information per analytics ID and VFL interoperability indicator and optional supported feature IDs, as described in clause 5.2.

Step 1b.

NWDAF as VFL client registers to NRF with its NF profile, which includes NF Type (i.e. NWDAF type), Analytics ID(s), service area if available, VFL capability information per analytics ID and VFL interoperability indicator and optional supported feature IDs, as defined in clause 5.2.

Step 1c.

When untrusted AF as VFL client, it shall register to the NEF via OAM configuration: Analyics ID(s) and its VFL capability information per supported analytics ID and VFL interoperability indicator and optional supported feature IDs, as defined in clause 5.5. Then NEF updates NEF profile to NRF including associated AF ID and AF's VFL capability information and VFL interoperability indicator and optional supported feature IDs.

Step 1d.

When trusted AF as VFL client, it registers to NRF with its NF profile, which includes NF Type (i.e. AF type), analytics ID(s), service area if available, VFL capability information per analytics ID and VFL interoperability indicator and optional supported feature IDs, as defined in clause 5.5.

Step 2.

The NRF receives the registrations from VFL server and VFL client(s), and stores their NF profile.

Step 3.

The NRF sends registration response to VFL server and VFL client(s).

Steps 4 to 6 are the NWDAF and AF Discovery procedures when the VFL server is NWDAF.

Step 4-6.

NWDAF as the VFL server determines that the ML Model requires VFL based on e.g. operator policy, Analytics ID, and Service Area.

If the NWDAF can not perform as VFL Server, it first discovers and selects another VFL Server NWDAF from NRF by invoking the Nnrf_NFDiscovery_Request service operation. The following criteria might be used: Analytics ID, VFL capability type as VFL server, Time Period of Interest and optional Service Area.

Once the VFL Server is determined, the VFL Server discovers other NWDAF(s) and/or AF(s) as VFL Client from NRF by invoking the Nnrf_NFDiscovery_Request service operation. The following criteria might be used: NF type (i.e. NWDAF type, AF type, or NEF type), Analytics ID, VFL capability type (i.e.VFL client), VFL interoperability indicator, Time Period of Interest, optional feature IDs and optional Service Area.

6.2H.2.1.2 Registration and Discovery procedure for Vertical Federated Learning when untrusted AF is acting as the VFL server p. 163

The procedure below shows registration and discovery for VFL training and inference when the untrusted AF is the VFL server. There can be multiple NWDAFs as VFL clients.

Reproduction of 3GPP TS 23.288, Fig. 6.2H.2.1.2-1: Registration and Discovery procedure for Vertical Federated Learning when AF is acting as VFL server and NWDAF(s) are the VFL clients

Figure 6.2H.2.1.2-1: Registration and Discovery procedure for Vertical Federated Learning when AF is acting as VFL server and NWDAF(s) are the VFL clients

Steps 1 to 3 are the NWDAF and AF Registration procedures when the VFL server is untrusted AF.

Step 1.

Same as the step 1b, in clause 6.2H.2.1, NWDAF as VFL client registers to NRF with its NF profile, it may include those analytics IDs on which it supports to do VFL with AF as VFL server.

Step 2-3.

Same as the steps 2-3, in clause 6.2H.2.1.

Steps 4-10 are the NWDAF Discovery procedures when the VFL server is an untrusted AF.

Step 4.

Untrusted AF acting as the VFL server determines that VFL operations are required and the NWDAF(s) as VFL client(s) are required. The AF sends a Nnef_NFDiscovery_Request for the VFL client(s) to the NEF and provides selection criteria: analytics ID, required NF type (i.e. NWDAF type), VFL capability type (i.e. VFL client), VFL interoperability indicator, Time Period of Interest, optional required feature IDs, and optional Service Area.

Step 5.

The NEF checks based on configured policies whether the AF is entitled to request a VFL client for the analytics ID.

Step 6-7.

The NEF discovers VFL client (i.e. NWDAF) on behalf of the AF from the NRF by invoking the Nnrf_NFDiscovery_Request using the selection criteria provided by the AF as defined in step 4.

Step 8.

The NEF selects an NWDAFs capable as acting as VFL clients and matching the received selection criteria. The NEF anonymizes NWDAF instances ID(s) and assigns external NWDAF ID(s) for each selected NWDAF intance as VFL client. The NEF stores the external NWDAF ID(s) together with information how to reach the NWDAFs.

Step 9.

The NEF sends Nnef_NFDiscovery_Request response including the external NWDAF ID(s) to the untrusted AF.

Step 10.

The AF stores the received external NWDAF ID(s) and uses it subsequent interactions with the NEF to indicate the target VFL client.

The AF may indicate to the NEF that the AF will no longer use the VFL process identified by VFL Correlation ID (external NWDAF IDs are no longer required). If the NEF receives this indication, it shall remove the stored external NWDAF ID(s) associated with the VFL correlation ID allocated to the AF. Then, the NEF responds to the AF.