Data Collection Coordination and Delivery coordinates the collection and distribution of data requested by NF consumers. It prevents data sources from having to handle multiple subscriptions for the same data and send multiple notifications containing the same information due to uncoordinated requests from data consumers.
In this Release of the specification Data Collection Coordination and Delivery is applicable to:
NWDAFs that request data from a Data Source (e.g. for use in computing analytics).
NF consumers that request analytics from an NWDAF Data Source.
NF consumers that request data from an ADRF Data Source.
Data Collection Coordination is supported by a DCCF. The Data Consumer may use an NRF to perform NF discovery and selection to find a DCCF that can coordinate data collection (DCCF discovery principles are defined in clause 6.3.19 of TS 23.501). Data Consumers send requests for data to the DCCF rather than directly to the NF Data Source. Whether the data consumers directly contact the NF Data Source or goes via the DCCF is based on configuration of the data consumers. For the Data Consumer and each notification endpoint in a data request, the Data Consumer may specify Formatting and Processing Instructions that determine how the data is to be provided. Upon receiving a request from a Data Consumer, the selected DCCF determines the NF instance that can be a Data Source if the Data Source is not indicated in the Data Consumer's request. The DCCF may also select an ADRF if the data is to be stored in an ADRF and an ADRF endpoint is not indicated in the Data Consumer's request. To retrieve data for a specific UE, the NRF, UDM or BSF can provide the DCCF with the identity of the Data Source using the services indicated in Table 5A.2-1.
The DCCF keeps track of the data actively being collected from the Data Sources it is coordinating. It may do so by maintaining a record of the active prior requests it sends to each Data Source. If a NWDAF subscribes for data directly with a Data Source, or a Data Source has stored data in an ADRF, the NWDAF or ADRF may register the data collection profile with the DCCF. The data collection profile may include the following parameters:
"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.);
NWDAF ID or ADRF ID specifies the ADRF or NWDAF which registers data collection profile.
The DCCF may then determine certain historical data may be available in the NWDAF or ADRF and coordinate collection of data from the NWDAF or ADRF based on the data collection profile.
When the DCCF receives a request for data, it determines the status of data collection from the Data Source. If parameters in a request for data from a Data Consumer match those in a prior request or in a data collection profile registration, the DCCF may determine that the requested data is already being collected from a Data Source or that a prior subscription to a Data Source may be modified to in addition satisfy the requirements of the new data request from a Data Consumer. This status is used in clause 5A.3 to deliver data to the Data Consumer and notification endpoints.
For persisting event exposure subscriptions for long-lived data collection, the DCCF may subscribe to the UDM to receive event notifications even if a Data Source that serves a UE changes.
The DCCF may subscribe to the NRF to receive event notifications if a Data Source changes (e.g. because of a NF life-cycle event).
A DCCF may use the same mechanisms described in clause 184.108.40.206 to determine AMF and SMF to retrieve data related to "any UE".
If the data consumer requests to collect data for any UE in an area of interest, the data consumer shall first determine all DCCFs covering the area of interest and then contact these DCCFs to request for data collection.
Data Delivery via DCCF is shown in Figure 5A.3.1-1. Each Event Notification received from a Data Source NF is sent to the DCCF which propagates it to all Data Consumers / Notification Endpoints specified by the Data Consumers or determined by the DCCF. Each Data Consumer may specify in its request to the DCCF multiple notification endpoints, which may include the requesting Data Consumer, an ADRF or other NFs. The DCCF may also select an ADRF or other notification endpoint based on configuration. The DCCF supports formatting and processing for each Consumer / notification endpoint so notifications comply with the data requests received from each Consumer NF.
Upon the DCCF determining the status of data collection for a data request (see clause 5A.2):
If the requested data is not already being collected from a Data Source, the DCCF sends a new subscription/request towards the Data Source with the notification target specified as the DCCF.
If the requested data is partially covered by existing subscriptions with the Data Source, the DCCF sends the Data Source a request to modify the subscription.
When notifications are received by the DCCF, they are processed according the Formatting and Processing Instructions for each Consumer and notification endpoint. The DCCF subsequently sends notifications to Consumers and notification endpoints via a Ndccf_DataManagement service.
Data Delivery via a Messaging Framework is shown in Figure 5A.3.2-1. The Messaging Framework formats and processes data received from the Data Source NF and sends notifications to all Data Consumers and Notification Endpoints specified by Data Consumers or determined by the DCCF. Each Data Consumer may specify in its request to the DCCF multiple notification endpoints, which may include the requesting Data Consumer, an ADRF or other NFs. The DCCF may also select an ADRF or other notification endpoint based on configuration. While the Messaging Framework is not standardized by 3GPP, a Messaging Framework Adaptor NF (MFAF) offers 3GPP defined services that allow the 5GS to interact with the Messaging Framework. Internally, the Messaging Framework may for example support the pub-sub pattern, where received data are published to the Messaging Framework and requests from 3GPP Consumers result in Messaging Framework specific subscriptions. Alternatively, the Messaging Framework may support other protocols outside of the scope of 3GPP.
The Messaging Framework Adaptor NF offers services that enable the 5GS to interact with the Messaging Framework:
3GPP Consumer Adaptor (3CA) Data Management Service: Nmfaf_3caDataManagement Service delivers data to each Data Consumer or notification endpoint after formatting and processing of data received by the Messaging Framework.
3GPP DCCF Adaptor (3DA) Data Management Service: Nmfaf_3daDataManagement Service enables the DCCF to convey to the Messaging Framework, information about the data the Messaging Framework will receive from a Data Source, formatting and processing instructions and the Data Consumer and notification endpoints.
Upon the DCCF determining the status of data collection for a data request (see clause 5A.2):
If the requested data is not currently being collected from a Data Source, the DCCF sends a new subscription/request towards the Data Source with the notification target specified as the Messaging Framework.
If the requested data is partially covered by existing subscriptions with the Data Source, the DCCF sends a request to the Data Source to modify one or more subscriptions to accommodate both the previous requests for data and the new request for data.
The DCCF uses the Nmfaf_3daData Management service to convey information so:
the Messaging Framework can recognize data that are received from a Data Source.
the MFAF can obtain data received by the Messaging Framework, process and format the data according to processing and formatting instructions for each Consumer / notification endpoint and send notifications or responses to the Data Consumers.
When data are received by the Messaging Framework (e.g. because of an event notification) they are processed according the Formatting and Processing Instructions for each Consumer / notification endpoint before notifications are sent to the Data Consumer or Notification Endpoints. Notifications sent via the Nmfaf_3caDataManagement service have the same content as those sent via a Ndccf_DataManagement service for Data Delivery via the DCCF.
Formatting and/or Processing instructions may be provided in requests by Data Consumers via the Ndccf_DataManagement service. When using the Messaging Framework, the DCCF sends the formatting and/or processing instructions to the Messaging Framework via the Nmfaf_3daData_Management Service so the MFAF may format and/or process the data before sending notifications to the Data Consumers / notification endpoints. When using Data Delivery via the DCCF, the DCCF performs formatting and/or processing before sending notifications.
Formatting determines when a notification is sent to the Consumer. Formatting Instructions may indicate:
Notification Event clubbing: Buffering and sending of several notifications in one message.
Notification Time Window (example: notifications are buffered and sent between 2 and 3 AM).
Cross event reference-based notification: When a subscribing NF is subscribing to multiple events (e.g. event X and event Y) the notification for an Event-X is buffered and reported only when the Event-Y occurs.
Consumer triggered Notification: Notifications are buffered until the consumer requests delivery using Ndccf_DataManagement or Nmfaf_3caDataManagement Service.
Exact time-based Notification: Notifications are sent to the Consumer at an exact time, irrespective of whether the event occurs (example: every 30 min).
Increasing time window based notification: Notifications are sent to the Consumer at an increasing periodicity (example: the first notification is sent immediately, subsequent received notifications are sent after 5 min, then after 10 min, then after 15 min, etc.).
For an ADRF endpoint, Formatting Instructions sent to the messaging framework may further specify whether Nmfaf services are used to deliver notifications to an ADRF, or whether the data are sent to the ADRF using a Nadrf service.
Processing instructions allow summarizing of notifications to reduce the volume of data reported to the Data Consumer. The processing results in summarizing of information from multiple notifications into a common report. Processing of data for inclusion in each notification sent to consumers occurs over a Processing Interval specified in the Processing Instructions. Notifications sent to consumers may represent partial intervals if formatting instructions or Event Reporting Information (as specified in TS 23.502Table 4.15.1-1) require that a notification be sent to the consumer before the end of a processing interval. Processing Instructions are provided per Event ID and are applied to multiple notifications that result from the same subscription and for the same Event ID. Processing Instructions, in addition to the Processing Interval, may specify the parameter names, parameter values and the attributes to be determined and reported to the Consumer. The processed notifications may comprise the following depending on the Event and Processing Instructions:
List of Event Parameter Name(s), and for each Event Parameter Name, one Event Parameter Values and sets of the following attributes as indicated in the processing instructions:
Event Spacing: Average and variance of the time interval separating two consecutive occurrences of the same event and parameter value, or periodicity for periodic reporting;
Event Duration: Average and variance of the Time for which the parameter value applies;
Number of countable occurrences for the parameter (e.g.: Mobility Registration Update);
Average and variance of the parameter (e.g.: number of UEs in an AoI);
Maximum and minimum parameter values (e.g.: number of UEs in an AoI).
Event Parameter Names are Event specific and not all attributes are applicable for all parameter names. Examples of Event Parameter Names and Parameter values are provided in Table 5A.4-1.
When the DCCF receives a request for data that includes a period in the past and ADRF is deployed, the DCCF may obtain data from ADRF as the Data Source. The DCCF may also obtain historical data from an NWDAF. The data obtained from the ADRF or NWDAF is delivered to Consumers / Notification Endpoints according to a configured Delivery Option. The DCCF may determine that requested data may be available in an ADRF or NWDAF based on the data collection profile previously registered by the ADRF or NWDAF, and by querying the ADRF or NWDAF.
ADRF or NWDAF as a Data Recipient:
An ADRF or NWDAF may be a Consumer NF that initiates requests to the DCCF for data, the ADRF or NWDAF may be specified as a notification endpoint by another Consumer NF that wants to have data it requests archived, or the DCCF may be configured to archive certain data in a ADRF (e.g. all data from an AMF instance).
If the ADRF or NWDAF instance is not specified in a request for data by a Consumer NF, the DCCF may select the ADRF or NWDAF instance based on provisioned information or information received from the NRF.
Data is delivered to the ADRF or NWDAF according to a configured Delivery Option (via DCCF or Messaging Framework).
The ADRF offers services that enable a consumer to store and retrieve data and analytics. The analytics are produced by the NWDAF as described in clause 6.1, and data are collected as described in clause 6.2.
Data may be stored in the ADRF by:
a consumer sending the ADRF an Nadrf_DataManagement_StorageRequest containing the data or analytics to be stored. The ADRF response provides a result indication.
a consumer sending the ADRF an Nadrf_DataManagement_StorageSubscriptionRequest requesting that the ADRF subscribes to receive data or analytics for storage. The ADRF then subscribes to the NWDAF or DCCF for data or analytics, providing ADRF Notification Address (+Notification Correlation ID). Analytics or Data are subsequently provided as notifications using DCCF, NWDAF or MFAF services (Ndccf_DataManagementNnwdaf_DataManagement or Nmfaf_3caDataManagement service).
Data may be retrieved from the ADRF by:
a consumer sending an Nadrf_DataManagement_RetrievalRequest request to the ADRF to retrieve data or analytics for a specified data or analytics collection time window. The ADRF determines the availability of the data or analytics in its repository and sends in the response to the consumer either the data or analytics, or instructions for fetching the data or analytics.
a consumer sending an Nadrf_DataManagement_RetrievalSubscribe request to the ADRF to retrieve data or analytics for a specified data or analytics collection time window. If the time window includes the future and the ADRF has subscribed to receive the data or analytics, subsequent notifications received by the ADRF are sent by the ADRF to the notification endpoint.
The ADRF determines the availability of the data or analytics and sends a success/failure indication in the response to the consumer. The ADRF then sends one or more notifications using an Nadrf_DataManagement_RetrievalNotify to the Notification Address (+Notification Correlation ID) specified by the consumer. The notification(s) either provide the data or analytics or provide instructions to the endpoint to fetch the data or analytics using an Nadrf_DataManagement_RetrievalRequest.
Data may be deleted from the ADRF by:
a consumer sending an Nadrf_DataManagement_Delete request.
An ADRF may be configured to register the data it is collecting with a DCCF. The registration uses the Ndccf_ContextManagement service specified in clause 8.2.3. The registration may subsequently be used by the DCCF to obtain data from the ADRF as described in clause 220.127.116.11.6.