Content for TS 23.288 Word version: 18.4.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.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… 7… 7.4… 7.7… 7.9… 8… 9… 10…

6.2.6.3.6 Data collection profile registration 6.2.6.3.7 DCCF (re-)selection initiated by consumer 6.2.6.3.8 DCCF and MFAF relocation initiated by DCCF
...

6.2.6.3.6 Data collection profile registration p. 98

In some cases data consumers (e.g. NWDAF or ADRF) collect data from data source NF directly, e.g. when NWDAF is co-located with 5GC NF.

To enable data consumers can get the data which has been collected by NWDAF or ADRF directly (i.e. not via DCCF), the NWDAF or ADRF may register/update the data collection profile to the DCCF during/after the procedure of data collection. DCCF can then determine some requested data is available in NWDAF or ADRF and can coordinate data collection based on the data collection profile.

The procedure depicted in Figure 6.2.6.3.6-1 is used by data source (e.g. NWDAF or ADRF) to register data profile to DCCF.

Figure 6.2.6.3.6-1: Procedure for the NWDAF or ADRF register data profile to DCCF

Step 1.

An ADRF or NWDAF instance is collecting or has collected data directly, e.g. from collocated NF.

Step 2.

The ADRF or NWDAF requests to register/update data collection profile (Service Operation, Analytics/Data Specification, ADRF ID or NWDAF ID) to DCCF by invoking the Ndccf_ContextManagement_Register or Ndccf_ContextManagement_Update. The registration/ update request can be triggered by the acceptation of subscription for data collection responded by the data source (e.g. collocated NF), it can be before the start of data collection or after the completion of data collection. DCCF determines the data collection status of NWDAF or ADRF based on the Analytics/Data Specification, i.e. DCCF determines whether the required data is being collected or has been collected.

"Service Operation" identifies the service used to collect the data or analytics from a Data Source (e.g.: Namf_EventExposure_Subscribe or Nnwdaf_AnalyticsSubscription_Subscribe).

"Analytics/Data Specification" is the "Service Operation" specific parameters that identify the collected data (i.e.: Analytics ID(s) / Event ID (s), Target of Analytics Reporting or Target of Event Reporting, Analytics Filter or Event Filter, etc.).

ADRF ID or NWDAF ID specify the ADRF or NWDAF which registers data collection profile.

Step 3.

The DCCF responds to the ADRF or NWDAF with a Ndccf_ContextManagement_Register Response or Ndccf_ContextManagement_Update Response.

Step 4.

To obtain historical data and if the data consumer is configured to collect data via the DCCF using Ndccf_DataManagement_Subscribe service operation, the data consumer uses the procedures described in clause 6.2.6.3.2 or clause 6.2.6.3.3.

Step 5.

The ADRF or NWDAF requests to delete a registration of data collection or analytics collection to the DCCF by invoking the Ndccf_ContextManagement_Deregister, triggered for instance by a request of the service consumer or by a storage life-time expiry of related data.

6.2.6.3.7 DCCF (re-)selection initiated by consumer |R18| p. 99

The procedure depicted in Figure 6.2.6.3.7-1 is used by a data consumer (e.g. NWDAF or central DCCF) to obtain UE(s) data, be notified by the DCCF when the DCCF can no longer serve the UE(s) and reselect the DCCF.

Reproduction of 3GPP TS 23.288, Fig. 6.2.6.3.7-1: Procedure for DCCF relocation initiated by consumer

Figure 6.2.6.3.7-1: Procedure for DCCF relocation initiated by consumer

Step 0.

The data consumer subscribes to source DCCF.

Step 1.

Source DCCF may notify the data consumer that it cannot serve the subscription anymore, e.g. when location of UE(s) falls outside the serving area of the DCCF. A cause code is added with the notification (e.g. UE(s) moved outside DCCF serving area). The DCCF may send pending data to the data consumer.

Step 2.

The data consumer for the DCCF determines to select a new instance of DCCF. The data consumer discovers and selects the target DCCF as described in clause 6.3.19 of TS 23.501. The data consumer may perform the DCCF selection due to internal triggers, notification of a UE mobility event or by receiving the notification from the source DCCF in step 1.

Step 3.

The data consumer sends a subscription request to the target DCCF using Ndccf_DataManagement_Subscribe request.

Step 4.

The data consumer may unsubscribe from the source DCCF.

Step 5.

Target DCCF may subscribe to relevant data source(s), if not yet subscribed.

6.2.6.3.8 DCCF and MFAF relocation initiated by DCCF |R18| p. 100

The procedure depicted in Figure 6.2.6.3.8-1 is used by a data consumer (e.g. NWDAF or central DCCF) to obtain UE data and to support DCCF and MFAF reselection when the DCCF or MFAF can no longer serve the UE.

Reproduction of 3GPP TS 23.288, Fig. 6.2.6.3.8-1: Procedure for DCCF relocation initiated by DCCF

Figure 6.2.6.3.8-1: Procedure for DCCF relocation initiated by DCCF

Step 0.

The data consumer subscribes to source DCCF. The data consumer may indicate in the subscription request with an indicator that the DCCF may execute the relocation procedure.

Step 1.

Source DCCF subscribes UE mobility events from AMF. The UE ID is provided by the data consumer in step 0.

Step 2.

If UE moves out of the service area of the source DCCF, source DCCF determines UE DCCF subscription context to be transferred to target DCCF, e.g., triggered by a UE mobility event notification from AMF. If UE moves out of the service area of the source MFAF, source DCCF determines UE MFAF data subscription to be transferred to target MFAF.

Step 3.

Source DCCF may query the NRF to discover and select the target DCCF and/or MFAF, e.g. based on the UE location information received from AMF.

Conditional on MFAF transfer:

Step 4.

Source DCCF uses the Nmfaf_3daDataManagement service to request transfer of UE MFAF data subscription context to the target MFAF.

Step 5.

Target MFAF retrieves MFAF subscription context from Source MFAF.

Step 6.

Target MFAF accepts the data subscription(s) context transfer.

Step 7.

Target MFAF responds to the DCCF indicating the transfer is complete. The response may contain a Transaction Reference ID from the Target MFAF.

Conditional on DCCF transfer:

Step 8.

Source DCCF using Ndccf_DataManagement_Transfer Request service operation to transfer of UE data subscription context to the target DCCF.

Step 9.

Target DCCF accepts the data subscription(s) context transfer.

Step 10.

If an MFAF is being used, the Target DCCF uses the Nmfaf_3daDataManagement_Configure service to configure the target MFAF.

Step 11.

Target DCCF confirms UE data subscription context transfer to the source DCCF. The confirmation includes the Subscription Correlation ID used by the Target DCCF.

For DCCF or MFAF transfer:

Step 12.

[Optional] Target DCCF subscribes to the relevant data source(s), if it is not yet subscribed to the data source(s) for the data required for the data subscription context and repeat step 1 to subscribes for UE mobility events from AMF.

Step 13.

Source DCCF informs the data consumer about the successful UE DCCF or MFAF data subscription context transfer using a Ndccf_DataManagement_Notify message. The notification may contain a Subscription Correlation ID provided by the target DCCF.

Step 14.

[Optional] Source DCCF unsubscribes with the data source(s) that are no longer needed for the remaining UE data subscriptions.

Step 15-17.

Target DCCF or MFAF collects data from the data source(s) and notifies the data consumer using a Ndccf_DataManagement_Notify message.