Content for TS 23.288 Word version: 18.0.0

1… 4… 5… 5A… 6… 6.1.4… 6.1.4.4… 6.1A… 6.1B… 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.2A… 6.2B… 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… 7… 8… 9… 10…

6.2B Analytics Data Repository procedures 6.2B.1 General 6.2B.2 Historical Data and Analytics storage 6.2B.3 Historical Data and Analytics Storage via Notifications 6.2B.4 Data removal from an ADRF 6.2C Federated Learning among Multiple NWDAFs 6.2C.1 Description 6.2C.2 Procedures
...

6.2B Analytics Data Repository procedures |R17| p. 97

6.2B.1 General p. 97

Collected data and analytics may be stored in ADRF, using procedure as specified in clause 6.2B.2 and clause 6.2B.3. Collected data and analytics may be deleted from ADRF, using procedure as specified in clause 6.2B.4.

6.2B.2 Historical Data and Analytics storage p. 98

The procedure depicted in Figure 6.2B.2-1 is used by consumers (e.g. NWDAF, DCCF or MFAF) to store historical data and/or analytics, i.e. data and/or analytics related to past time period that has been obtained by the consumer. After the consumer obtains data and/or analytics, consumer may store historical data and/or analytics in an ADRF. Whether the consumer directly contacts the ADRF or goes via the DCCF or via the Messaging Framework is based on configuration.

Reproduction of 3GPP TS 23.288, Fig. 6.2B.2-1: Historical Data and Analytics storage

Figure 6.2B.2-1: Historical Data and Analytics storage

Step 1.

The consumer sends data and/or analytics to the ADRF by invoking the Nadrf_DataManagement_StorageRequest (collected data with timestamp, analytics with timestamp, Service Operation, Analytics Specification or Data Specification) service operation.

Step 2.

The ADRF stores the data and/or analytics sent by the consumer. The ADRF may, based on implementation, determines whether the same data and/or analytics is already stored or being stored based on the information sent in step 1 by the consumer NF and, if the data and/or analytics is already stored or being stored in the ADRF, the ADRF decides to not store again the data and/or analytics sent by the consumer.

Step 3.

The ADRF sends Nadrf_DataManagement_StorageRequest Response message to the consumer indicating that data and/or analytics is stored, including when the ADRF may have determined at step 2 that data or analytics is already stored.

6.2B.3 Historical Data and Analytics Storage via Notifications p. 98

The procedure depicted in Figure 6.2B.3-1 is used by consumers (NWDAF, DCCF) to store received notifications in the ADRF. The consumer requests the ADRF to initiate a subscription for data and/or analytics. Data and/or analytics provided in notifications as a result of the subsequent subscription by the ADRF are stored in the ADRF.

Reproduction of 3GPP TS 23.288, Fig. 6.2B.3-1: Historical Data and Analytics Storage via Notifications

Figure 6.2B.3-1: Historical Data and Analytics Storage via Notifications

Step 1a-d.

Based on provisioning or based on reception of a DataManagement subscription request (e.g. see clause 6.2.6.3.2), the DCCF or the NWDAF determines that notifications are to be stored in an ADRF.

Step 2a-b.

The DCCF or the NWDAF determines the ADRF where data and/or analytics needs to be stored and requests that the ADRF subscribes to receive notifications. The determination may be made based on configuration or information supplied by the data consumer as described in clauses 6.1.4 and 6.2.6.3. The request to the ADRF specifies the data and/or analytics to which the ADRF will subscribe by invoking the Nadrf_DataManagement_StorageSubscriptionRequest service operation.

Step 3.

[Optional] The ADRF may, based on implementation, determines whether the same data and/or analytics is already stored or being stored, based on the information sent in step 2 by the consumer.

Step 4.

[Optional] If the data and/or analytics is already stored and/or being stored in the ADRF, the ADRF sends Nadrf_DataManagement_StorageSubscriptionRequest Response message to the consumer indicating that data and/or analytics is stored.

Step 5a-b.

ADRF subscribes to the DCCF or the NWDAF to receive notifications, providing its notification endpoint address and a notification correlation ID.

Step 6.

The DCCF, the MFAF or the NWDAF sends Analytics or Data notifications containing the notification correlation ID provided by the ADRF to ADRF notification endpoint address. The Analytics or Data notifications shall contain timestamp. The ADRF stores the notifications.

Step 7a-b.

The DCCF or the NWDAF determines that notifications no longer need to be stored in the ADRF.

Step 8a-b.

The DCCF or the NWDAF requests that the ADRF unsubscribes to receive notifications.

Step 9a-b.

The ADRF sends a request to the DCCF or the NWDAF to unsubscribe to data notifications.

The NWDAF may interact with the Data Source and the DCCF may interact with the Data Source and/or MFAF. Delivery notifications from the DCCF/MFAF or NWDAF to the ADRF are subsequently halted.

6.2B.4 Data removal from an ADRF p. 100

The procedure depicted in Figure 6.2B.4-1 is used by consumers (DCCF, NWDAF) to remove data previously stored in an ADRF.

Reproduction of 3GPP TS 23.288, Fig. 6.2B.4-1: Data Removal from an ADRF

Figure 6.2B.4-1: Data Removal from an ADRF

Step 1.

A consumer requests that specified data be deleted from the ADRF using Nadrf_DataManagement_Delete request service operations.

Step 2.

The ADRF deletes all copies of the stored data.

Step 3.

The ADRF indicates the result (i.e. data deleted, data not found, data found but not deleted) using Nadrf_DataManagement_Delete response service operations.

6.2C Federated Learning among Multiple NWDAFs |R18| p. 100

6.2C.1 Description p. 100

This clause specifies how NWDAF containing MTLF can leverage Federated Learning technique to train an ML model, in which there is no need for input data transfer (e.g. centralized into one NWDAF) but only need for cooperation among multiple NWDAFs (MTLF) distributed in different areas i.e. sharing of ML model(s) and of the learning results among multiple NWDAFs (MTLF).

6.2C.2 Procedures p. 101

6.2C.2.1 General procedure for Federated Learning among Multiple NWDAF Instances p. 101

Reproduction of 3GPP TS 23.288, Fig. 6.2C.2.1-1: General procedure for Federated Learning among Multiple NWDAF

Figure 6.2C.2.1-1: General procedure for Federated Learning among Multiple NWDAF

Step 0.

The consumer (NWDAF containing AnLF) sends a subscription request to NWDAF containing MTLF to retrieve a ML model, including Analytic ID and ML model filter information as described in TS 23.288, the NWDAF containing MTLF can be a FL server (Server NWDAF) with FL server capability or a MTLF without FL server capability.

Step 1.

Server NWDAF sends a request to the selected NWDAF containing MTLF(Client NWDAF) that participates in the Federated learning to perform the local model training for Federated Learning.

Step 2.

Each Client NWDAF collects its local data by using the current mechanism in clause 6.2 of TS 23.288.

Step 3.

During Federated Learning training procedure, each Client NWDAF further trains the retrieved ML model from the server NWDAF based on its own data, and reports interim local ML model information to the Server NWDAF.

The ML model information are exchanged between the Client NWDAF(s) and the Server NWDAF during the FL training process.

Step 4.

The Server NWDAF aggregates all the local ML model information retrieved at step 3, to update the global ML model.

Step 5a.

Based on the consumer request, the Server NWDAF updates the training status (an accuracy level) to the consumer periodically (one or multiple rounds of training or every 10 min, etc.) or dynamically when some pre-determined status (e.g. some accuracy level) is achieved.

5b. [Optional] Consumer decides whether the current model can fulfil the requirement e.g. accuracy and time. The consumer modifies subscription if the current model can fulfil the requirement.

Step 5c.

According to the request from the consumer, Server NWDAF updates or terminates the current FL training process.

Step 6.

If the FL procedure continues, Server NWDAF sends the aggregated ML model information to each Client NWDAF for next round model training.

Step 7.

Each Client NWDAF updates its own ML model based on the aggregated ML model information distributed by the Server NWDAF at step 6.

After the training procedure is complete, the Server NWDAF may send the globally optimal ML model information to the consumer.