6.2.6 Enhanced Procedures for Data Collection

23.2883GPPArchitecture enhancements for 5G System (5GS) to support network data analytics servicesRelease 18TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

6.2.6.0 General

Data collection may be performed via DCCF, MFAF and ADRF, when such NFs are deployed, or via NWDAF (hosting DCCF and/or ADRF). The NF services used for DCCF, MFAF, ADRF and the NWDAF (hosting DCCF and/or ADRF) are listed in Table 6.2.6.0-1.

Table 6.2.6.0-1: NF Services for the enhanced data collection procedures

Service producer	Service	Reference
NWDAF	Nnwdaf_DataManagement	7.4
DCCF	Ndccf_DataManagement Ndccf_ContextManagement	8.2 8.3
MFAF	Nmfaf_3daDataManagement Nmfaf_3caDataManagement	9.2 9.3
ADRF	Nadrf_DataManagement	10.2

DCCF, MFAF and NWDAF hosting DCCF shall use the same services listed in clause 6.2.1 from OAM and NFs (including AFs directly or via NEF) to collect data. Additionally, the new services for data exposure from DCCF, MFAF, ADRF and NWDAF (hosting DCCF and/or ADRF) as specified in clause 8, 9, 10 and 7.4 may also be used for data collection.

The NWDAF, DCCF, ADRF shall obtain the proper information to perform data collection for a UE, a group of UEs or any UE following the principles of clause 6.2.1.

When NWDAF or DCCF need to discover the sources of data collection, they follow the principles defined in clause 6.2.2.1 in the case of data collection from NFs; in clause 5A.2 in the case of DCCF deployed in the network and requiring data from NWDAFs or ARDFs that independently collect data; clause 5.2 in the case of NWDAF (hosting DCCFs) and collecting data from other NWDAFs.

6.2.6.1 Bulked Data Collection

6.2.6.1.0 General

NWDAFs may provide bulked data to consumers as an alternative to providing individual events (i.e. subscription to multiple event IDs to obtain the data required for an analytics generation).

The bulked data is the set of data samples from the collected event notifications to be used for an Analytics ID for a consumer of NWDAF. A data sample may be a notification, in which case the bulked data may comprise a group of received notifications, or a data sample may be information extracted from a notification and processed, in which case the bulked data comprises the processed information. The bulked data can be used for the purpose of analytics inference or ML model training.

The bulked data is generated based on the set of data samples from event notifications collected from NFs/OAM and the properties for the selection of such data, Consumers of bulked data or operators may define different rules (e.g. aggregation formats or processes) for generation of bulked data for training or inference.

NFs capable to expose bulked data have the following capabilities:

– Exposing runtime collected data (e.g. data from NFs/AFs/OAM retrieved via notification mechanisms), or historical collected data (e.g. data from NFs/AFs/OAM that were at some point collected, then stored), or both;

– Applying selection processes of data samples or processing mechanisms for the generation of the bulked data according to bulked data formatting and processing instructions provided by consumers of the bulked data or defined by an operator. The bulked data formatting and processing instructions may include the formatting and processing instructions as specified in clause 5A.4 and further instructions as described in clause 6.2.6.1.1. Such instructions define the allowed and/or restricted properties and/or processes to be applied to the set of data from the collected event notifications to be used for the bulked data, the properties and processes being:

– The properties associated with the Bulked data formatting and processing are filters over the data to be associated with the bulked data. The properties for bulked data are defined as per Data Specification parameters in clause 6.2.6.1.1.

– The processes associated with the bulked data formatting and processing are mechanisms applied to the data to be associated with the bulked data and are defined according to the Formatting and Processing parameter defined in clause 5A.4 and the further instructions defined in clause 6.2.6.1.1. These processes may comprise: definition if data to be used for composing the bulked data is directly extracted from collected events, or the data is extracted from event notification of the same event type and pre-processed, or both; applying anonymization of data fields in the bulked data to avoid exposing undesired information, aggregation levels (i.e. per cell, per UEs, or temporal, e.g. per hours or days).

NOTE: Pre-process data from collected event notifications of the same event type refers to the usage of data manipulation processes in order to aggregate, concatenate, process data from multiple collected event notifications from the same event type that results in a single processed value.

– Having the mapping of the Service Operation that have to be used for collecting data of the bulked data associated with an Analytics ID.

6.2.6.1.1 Services for Bulked Data Collection

NWDAF may expose the Nnwdaf_DataManagement_Subscribe service operation with a request for bulked data including the following input parameters:

– Data Specification:

– Event ID(s) or Analytics ID(s);

– In the case of Event IDs, the Data Specification fields includes the fields Target of Event Reporting and Event Filter Information as defined in clause 4.15.1 of TS 23.502 [3] and Bulked Data Type parameter, which can be set to ”raw data samples” (i.e. data is directly extracted from collected events) or ”pre-processed data samples” (i.e. data from collected events is processed and the processed data is included in the bulked data) or a combination of both;

– If the Analytics ID(s), the Data Specification fields contain:

– Target of Reporting including a tuple with Analytics ID; Bulked Data Type, which can be set to ”raw data samples” (i.e. data is directly extracted from collected events) or ”pre-processed data samples” (i.e. data from collected events is processed and the processed data is included in the bulked data) or a combination of both;

– Filter Information may include fields related to the Analytics ID such as: Target of Analytics Information (e.g. any UE, list of UEs, groups of UEs); Analytics Filter Information (e.g. area of interest, DNN, Application, S-NSSAI). The Analytics ID also determines the Service Operation from NFs, OAM to be used and type of data (i.e. Event IDs, OAM measurements) to be collected and associated with the bulked data.

– Service Operation in the case of Event ID, defines the service operation to be used by NWDAF, DCCF, MFAF, or ADRF to request data (e.g. Namf_EventExposure_Subscribe or OAM Subscribe)

– Bulked Data Formatting and Processing: the parameters defined in clause 4.15.1 of TS 23.502 [3] for Event Reporting Information and Formatting and Processing instructions as defined in clause 5A.4.

– A Notification Target Address (+ Notification Correlation ID), where the Notification Correlation ID is the unique identification for the bulked data being generated for the requesting consumer.

– ADRF ID or NWDAF ID (or ADRF Set ID or NWDAF Set ID) storing historical data (optional). If known to the consumer, this may be specified to direct a DCCF or an NWDAF to the repository containing historical data.

– (Optional) ADRF information indicating whether the collected data for the generation of the bulked data are to be stored in an ADRF and optionally an ADRF ID.

– (Optional, in case the requested data is Event IDs) Data Source identification to collect the data, e.g. NF Instance (or NF Set) ID from which the data needs to be collected.

The output parameter of the Nnwdaf_DataManagement_Subscribe service operation comprise the subscription correlation ID, which identifies the requested bulked data.

The input parameters of Nnwdaf_DataManagement_Notify service operation shall contain the Notification Correlation ID and the generated bulked data when the fetch flag = false. When the fetch flag = true the notifications will contain the Notification Correlation ID, the Fetch Correlation ID and a target address where the generated bulked data may be retrieved. In the case of unsuccessful bulked data generation, the notification will contain an indication of an unsuccessful bulked data generation, optionally with expired bulked data deadline.

The input parameters for the service operation Nnwdaf_DataManagement_Fetch include: the Notification correlation ID (+list of Fetch Correlation ID), which identifies the requested bulked data.

The output parameters for the service operation Nnwdaf_DataManagement_Fetch include:

– the generated bulked data.

The generated bulked data exposed by the above listed service operations comprises:

– the dataset (i.e. the resulting set of data samples and/or set of pre-processed data samples from the collected event notifications) generated based on the parameters of bulked data request and Bulked Data Formatting and Processing;

– timestamp when the data sample is associated with a bulked data.

6.2.6.2 Procedure for Data Collection from NWDAF

The procedure in Figure 6.2.6.2-1 is used by NWDAF service consumer to invoke the data management services at NWDAFs in order to retrieve runtime and historical data.

Figure 6.2.6.2-1: Data Collection from NWDAF via Data Management Service

1. NWDAF service consumer (e.g. NWDAF, DCCF) identifies that further data from an NWDAF is required in order to perform some operation related to Analytics ID. The triggers for further data collection are related to:

a) the local policies of NWDAF or DCCF (e.g. preparation for future requests for Analytics ID as specified in clause 6.2.2.1);

b) a request for analytics generation requiring data not available or not directly reachable via the NWDAF service consumer (e.g. out of the serving area);

c) a request for model training;

d) a request for data collection that NWDAF service consumer cannot provide by itself.

NOTE 1: If the NWDAF service consumer is a DCCF, the discovery of the proper NWDAF is defined in clause 6.2.6.3.6. If the NWDAF service consumer is a NWDAF, the NWDAF service consumer can discover the appropriate NWDAF(s) as defined in clause 5.2.

2a. NWDAF service consumer invokes Nnwdaf_DataManagement_Subscribe service from NWDAF to request a required data. The request comprises the Data Specification as well as Data Formatting and Processing instructions as defined in clause 5A.4, Notification Target Address (+ Notification Correlation ID).

When the required data is Event IDs, the NWDAF service consumer may include the Data Source, e.g. NF Instance (or NF Set) ID from which the data needs to be collected.

The NWDAF service consumer may include ADRF information indicating whether the data are to be stored in an ADRF and optionally an ADRF ID.

The NWDAF service consumer may include ADRF ID or NWDAF ID (or ADRF Set ID or NWDAF Set ID) storing historical data (optional), directing NWDAF to the repository containing historical data.

The NWDAF checks if required data is related to a user, i.e. SUPI or GPSI, then, depending on local policy and regulations, as described in clause 6.2.9, the NWDAF checks or has checked the user consent by retrieving the user consent information from UDM using Nudm_SDM_Get including data type "User consent". If user consent is not granted, NWDAF sends a response to the NWDAF service consumer in step 2b, indicating that user consent for data collection was not granted and the data collection for this SUPI or GPSI stops here. If the user consent is granted, the NWDAF can provide the required data to the NWDAF service consumer by performing the following steps 2b-7 and the NWDAF subscribes to UDM to notifications of changes on subscription data type "User consent" for this user using Nudm_SDM_Subscribe. When receiving the notification that user consent has been revoked, the NWDAF shall provide a Termination Request in Nnwdaf_DataManagement_Notify to request the NWDAF service consumer to cancel the subscription to the required data.

2b. Based on the received request, NWDAF creates a new data for the requesting consumer. NWDAF sends Nnwdaf_DataManagement_Subscribe service response with a confirmation of successful request and the subscription correlation ID identifying the requested data.

NOTE 2: Subscription Correlation ID allows the NWDAF service consumer to request to NWDAF any changes in the generation of a requested data.

3. NWDAF determines whether the request data is available at such NWDAF.

NWDAF maintains a local association of requested Event IDs or Analytics IDs to the list of triggered event subscription identifications from data sources to generate the requested data. Based on this local association, the NWDAF checks if the data to be collected is available at itself. If the data is available, NWDAF uses such data to generate the requested data.

When data sources are NFs, the NWDAF discovers the proper NFs as defined in clause 6.2.2.1.

When the data sources are other NWDAFs, the NWDAF discovers the other NWDAFs as defined in clause 5.2.

When the data source is DCCF, the NWDAF discovers the proper DCCF as defined in clause 6.3.19 of TS 23.501 [2].

4a. (Optional) If NWDAF receives a request for data that is not available or not reachable by such NWDAF (e.g. out of serving area), NWDAF determines the sources for the data that is not available, if the information has not been included in the subscription to the requested data.

4b. (Optional) NWDAF may trigger further data collection using any of the available mechanisms in clause 6.2.2 (e.g. if the data subscribed in step 2a partially matches data that are already being collected by the NWDAF from a data source and a modification of the subscription to the data source would satisfy both the existing data collection as well as the newly requested data) and clause 6.2.6 (e.g. recursively using data collection services from other needed NWDAFs, DCCFs, ADRFs, NFs).

NWDAF updates its local association of the mapping of the requested data (Event ID or Analytics ID) to the identification of the request/subscription for data collection from the further data sources.

5. Based on the properties of the received request, NWDAF generates the requested data including the available or collected data (e.g. from other NWDAFs, DCCFs or ADRFs, NFs).

6a. If the fetch flag is set to true in step 2a, NWDAF waits until the requested data is ready and sends a Nnwdaf_DataManagement_Notify service message with fetch instructions.

The requested data is ready when the NWDAF has generated the data and completed processing and formatting as described in clause 5A.4.

6b. If the fetch flag is set to false in step 2a, NWDAF uses the Nnwdaf_DataManagement_Notify service to send the Notification Correlation ID and requested data to the NWDAF service consumer.

7(a.b). Alternatively, if the Nnwdaf_DataManagement_Notify service message with fetch instructions is received in step 6a, the NWDAF service consumer shall fetch the required data from NWDAF via Nnwdaf_DataManagement_Fetch service operation within the fetch deadline specified in the fetch instructions. The NWDAF service consumer invokes the Nnwdaf_DataManagement_Fetch service operation with the input parameters including the Fetch Correlation ID, that identifies the data to be fetched and receives a response with the requested data.

8. The NWDAF service consumer uses the requested data for performing further processing. If the NWDAF service consumer is an NWDAF the requested data can be used for analytics generation or model training or for further exposing such data to other NWDAFs. If the NWDAF service consumer is a DCCF, the requested data can be provided to a DCCF data consumer.

9. When the NWDAF service consumer determines that no more data is required or if receiving a Termination Request from the NWDAF, e.g. due to user consent revocation for the data collection related to a user, it unsubscribes to the requested data from NWDAF. If NWDAF had triggered further data collection in Step 3a and 3b, NWDAF also unsubscribe to all data sources.

NOTE 3: It is also possible that instead of providing the dataset of the generated data in steps 6a, 6b, 7b, the NWDAF provides a reference to where the dataset can be retrieved by the NWDAF service consumer.

6.2.6.3 Data Collection using DCCF

6.2.6.3.1 General

This clause specifies procedures for data collection using the DCCF described in clause 5A for cases other than obtaining analytics from an NWDAF (which is specified in clause 6.1.2). Two options are supported: data delivered via the DCCF, according to clauses 6.2.6.3.2 and 6.2.6.3.3 and data delivered via a messaging framework according to clauses 6.2.6.3.4 and 6.2.6.3.5. Which option to be used is determined by DCCF configuration.

6.2.6.3.2 Data Collection via DCCF

The procedure depicted in Figure 6.2.6.3.2-1 is used by a data consumer (e.g. NWDAF) to obtain data and be notified of events via the DCCF using Ndccf_DataManagement_Subscribe service operation. Whether the data consumer directly contacts the Data Source or goes via the DCCF is based on configuration of the data consumer.

Figure 6.2.6.3.2-1: Data Collection via DCCF

1. The data consumer subscribes to data via the DCCF by invoking the Ndccf_DataManagement_Subscribe (Service_Operation, Data Specification, Formatting Instructions, Processing Instructions, NF (or NF-Set) ID, ADRF Information) service operation as specified in clause 8.2.2. The data consumer may specify one or more notification endpoints. If data to be collected is subject to user consent: if the data consumer checked user consent, the data consumer shall provide user consent check information (i.e. an indication that it has checked user consent), otherwise, the data consumer shall provide a purpose for the data collection.

Service_Operation is the service operation to be used by the DCCF to request data (e.g. Namf_EventExposure_Subscribe or OAM Subscribe). Data Specification provides Service Operation-specific parameters (e.g. event IDs, UE-ID(s), target of event reporting) used to retrieve the data. Formatting and Processing Instructions are as defined in clause 5A.4. The data consumer may include the Data Source, e.g. NF Instance (or NF Set) ID from which the data needs to be collected. The data consumer may include ADRF information indicating whether the data are to be stored in an ADRF and optionally an ADRF ID.

2. The DCCF checks if data is to be collected for a user, i.e. SUPI or GPSI, then, depending on local policy and regulations, the DCCF checks the user consent by retrieving the user consent information from UDM using Nudm_SDM_Get including data type "User consent" and taking into account purpose for data collection as provided in step 1. If user consent is not granted, DCCF does not subscribe to event exposure for events related to this user, the data collection for this SUPI or GPSI stops here and DCCF sends a response to the data consumer indicating that user consent for data collection was not granted. If the user consent is granted, the DCCF subscribes to UDM to notifications of changes on subscription data type "User consent" for this user using Nudm_SDM_Subscribe.

If the data consumer is NWDAF and it provides user consent check information (i.e. an indication that it has checked user consent) in Ndccf_DataManagement_Subscribe in step 1, which has been obtained by the NWDAF from UDM before, then the DCCF can do data collection for a user based on the user consent information from the NWDAF and skip retrieving it from UDM.

3. The DCCF determine the NF type(s) and/or OAM to retrieve the data based on the Service Operation requested in step 1. If the NF instance or NF Set ID is not provided by the data consumer. the DCCF determines the NF instances that can provide data as described in clause 5A.2 and clause 6.2.2.2. If the consumer requested storage of data in an ADRF but the ADRF ID is not provided by the data consumer, or the collected data is to be stored in an ADRF according to configuration on the DCCF, the DCCF selects an ADRF to store the collected data.

4. The DCCF determines whether the data requested in step 1 are already being collected, as described in clause 5A.2.

If the data requested are already being collected from the Data Source by a data consumer, the DCCF adds the data consumer to the list of data consumers that are subscribed for these data, then the DCCF determines that no subscriptions to the Data Source need to be created or modified.

5. If the data subscribed in step 1 partially matches data that are already being collected by the DCCF from a Data Source and a modification of this subscription to the Data Source would satisfy both the existing data subscriptions as well as the newly requested data, the DCCF invokes Nnf_EventExposure_Subscribe (Subscription Correlation ID) with parameters indicating how to modify the previous subscription (as specified in clause 5A.2). The DCCF adds the data consumer to the list of data consumers that are subscribed for these data.

If the data requested at step 1 are not already available or not being collected yet, the DCCF subscribes to data from the NF using the Nnf_EventExposure_Subscribe service operation as specified in clause 5A.2 and clause 6.2.2.2, with DCCF indicated as Notification Target Address. The DCCF adds the data consumer to the list of data consumers that are subscribed for these data.

6. When new output data are available, the Data Source uses Nnf_EventExposure_Notify to send the data to the DCCF.

7. The DCCF uses Ndccf_DataManagement_Notify to send the data to all notification endpoints indicated in step 1. Data sent to notification endpoints may be processed and formatted by the DCCF so they conform to delivery requirements for each data consumer or notification endpoint as specified in clause 5A.4. The DCCF may store the information in ADRF if requested by the consumer or if required by DCCF configuration, using procedure as specified in clause 6.2B.3.

NOTE: According to Formatting Instructions provided by the data consumer, multiple notifications from a Data Source can be combined in a single Ndccf_DataManagement_Notify so many notifications from the Data Source result in fewer notifications (or one notification) to the data consumer. Alternatively, a notification can instruct the data notification endpoint to fetch the data from the DCCF before an expiry time.

8a. If DCCF needs to retrieve data from OAM, procedure for data collection from OAM as per steps 1-4 from clause 6.2.3.2 is used.

8b. The DCCF uses Ndccf_DataManagement_Notify to send the data to all notification endpoints indicated in step 1. Data sent to notification endpoints may be processed and formatted by the DCCF, so they conform to delivery requirements for each data consumer or notification endpoint as specified in clause 5A.4. The DCCF may store the information in ADRF if requested by the consumer or if required by DCCF configuration, using procedure as specified in clause 6.2B.3.

9. If a Ndccf_DataManagement_Notify contains a fetch instruction, the notification endpoint sends a Ndccf_DataManagement_Fetch request to fetch the data from the DCCF.

10. The DCCF delivers the data to the notification endpoint

11. The UDM may notify the DCCF on changes of user consent at any time after step 2. If user consent is no longer granted for a user for which data has been collected and there are no other consumers for the data, the DCCF shall unsubscribe to any Event ID to collect data for that SUPI or GPSI. The DCCF shall further update or terminate affected subscriptions of the Data Consumer. The DCCF may unsubscribe to be notified of user consent updates from UDM for each SUPI for which user consent has been revoked.

12. When the data consumer no longer wants data to be collected it invokes Ndccf_DataManagement_Unsubscribe (Subscription Correlation ID), using the Subscription Correlation Id received in response to its subscription in step 1. The DCCF removes the data consumer from the list of data consumers that are subscribed for these data.

13. If there are no other data consumers subscribed to the data, the DCCF unsubscribes with the Data Source.

6.2.6.3.3 Historical Data Collection via DCCF

The procedure depicted in figure 6.2.6.3.3-1 is used by data consumers (e.g. NWDAF) to obtain historical data, i.e. data related to past time period. The data consumer requests data using Ndccf_DataManagement_Subscribe service operation. Whether the data consumer uses this procedure or directly contacts the ADRF or NWDAF is based on configuration.

Figure 6.2.6.3.3-1: Historical Data Collection via DCCF

1. The data consumer requests data via DCCF by invoking the Ndccf_DataManagement_Subscribe (Service_Operation, Data Specification, Time Window, Formatting Instructions, Processing Instructions, ADRF ID or NWDAF ID (or ADRF Set ID or NWDAF Set ID) service operation as specified in clause 8.2.2. The data consumer may specify one or more notification endpoints to receive the data. If data to be collected is subject to user consent: if the data consumer checked user consent, the data consumer shall provide user consent check information (i.e. an indication that it has checked user consent), otherwise, the data consumer shall provide a purpose for the data collection.

"Service_Operation" is the service operation used to acquire the data from a data source. "Data Specification" provides Service_Operation-specific parameters (e.g. event IDs, UE-ID(s)) used to retrieve the data. "Time Window" specifies a past time period and comprises a start and stop time. "Formatting and Processing Instructions" are as defined in clause 5A4. The data consumer may optionally include the ADRF or NWDAF instance (or ADRF Set or NWDAF Set) ID where the stored data resides.

3. If an ADRF or NWDAF instance or ADRF Set ID or NWDAF Set ID is not provided by the data consumer, the DCCF determines if any ADRF or NWDAF instances might provide the data as described in clause 5B and 5A.2.

NOTE 1: An ADRF or NWDAF might have previously registered data it is collecting with the DCCF.

4. (conditional) If the DCCF determines that an ADRF instance might provide the data, or an ADRF instance or Set was supplied by the data consumer, the DCCF sends a request to the ADRF, using Nadrf_DataManagement_RetrievalSubscribe (Data Specification, Notification Target Address=DCCF) service operation as specified in clause 10.2. The ADRF responds to the DCCF with an Nadrf_DataManagement_RetrievalSubscribe response indicating if the ADRF can supply the data. If the data can be provided, the procedure continues with step 5.

5. (conditional) If the DCCF determines that an NWDAF instance might provide the data or an NWDAF instance or Set was supplied by the data consumer, the DCCF sends a request to the NWDAF using Nnwdaf_DataManagement_Subscribe (Data Specification, Notification Target Address=DCCF) as specified in clause 7.4.2.

6. The ADRF uses Nadrf_DataManagement_RetrievalNotify or the NWDAF uses Nnwdaf_DataManagement_Notify to send the requested data (e.g. one or more stored notifications archived from a data source) to the DCCF. The data may be sent in one or more notification messages.

7. The DCCF uses Ndccf_DataManagement_Notify to send data to all notification endpoints indicated in step 1. Notifications are sent to the Notification Target Address(es) using the data consumer Notification Correlation ID(s) received in step 1. Data sent to notification endpoints may be processed and formatted by the DCCF, so they conform to delivery requirements specified by the data consumer.

NOTE 2: According to Formatting Instructions provided by the data consumer, multiple notifications from an ADRF or NWDAF can be combined in a single Ndccf_DataManagement_Notify so many notifications from the ADRF or NWDAF results in fewer notifications (or one notification) to the data consumer. Alternatively, a Ndccf_DataManagement_Notify can instruct the data notification endpoint to fetch the data from the DCCF before an expiry time.

8. If a notification contains a fetch instruction, the notification endpoint sends a Ndccf_DataManagement_Fetch request to fetch the data from the DCCF.

9. The DCCF delivers the data to the notification endpoint.

10. The UDM may notify the DCCF on changes of user consent at any time after step 2. If user consent is no longer granted for a user for which data has been collected and if there are no other consumers for the data, the DCCF shall unsubscribe to any data collection for that SUPI or GPSI. The DCCF shall further update or terminate affected subscriptions of the Data Consumer. The DCCF may unsubscribe to be notified of user consent updates from UDM for each SUPI for which user consent has been revoked.

11. When the data consumer no longer wants data to be collected or has received all the data it needs, it invokes Ndccf_DataManagement_Unsubscribe (Subscription Correlation ID) as specified in clause 8.2.3, using the Subscription Correlation Id received in response to its subscription in step 1.

12. If the data are being provided by an ADRF and there are no other data consumers subscribed to the data, the DCCF unsubscribes with the ADRF using Nadrf_DataManagement_RetrievalUnsubscribe as specified in clause 10.2.7.

13. If the data are being provided by an NWDAF and there are no other data consumers subscribed to the data, the DCCF unsubscribes with the NWDAF using Nnwdaf_DataManagement_Unsubscribe as specified in clause 7.4.3.

6.2.6.3.4 Data Collection via Messaging Framework

This procedure depicted in Figure 6.2.6.3.4-1 is used by a data consumer (e.g. NWDAF) to obtain data and be notified of events using the DCCF and a Messaging Framework. The 3GPP DCCF Adaptor (3da) Data Management service and 3GPP Consumer Adaptor (3ca) Data Management service of the Messaging Framework Adaptor Function (MFAF) are used to interact with the 3GPP Network and the Messaging Framework. Whether the data consumer directly contacts the Data Source or goes via the DCCF is based on configuration.

Figure 6.2.6.3.4-1: Data Collection via Messaging Framework

1. The data consumer subscribes to data via the DCCF by invoking the Ndccf_DataManagement_Subscribe (Service_Operation, Data Specification, Formatting Instructions, Processing Instructions, NF (or NF-Set) ID, ADRF Information, Data Consumer Notification Target Address (+ Notification Correlation ID)) service operation as specified in clause 8.2.2. The data consumer may specify one or more notification endpoints and the NF or NF set to collect data from. If data to be collected is subject to user consent: if the data consumer checked user consent, the data consumer shall provide user consent check information (i.e. an indication that it has checked user consent), otherwise, the data consumer shall provide a purpose for the data collection.

Service_Operation is the service operation to be used by the DCCF to request data (e.g. Namf_EventExposure_Subscribe or OAM Subscribe). Data Specification provides Service_Operation-specific required parameters (e.g. event IDs, UE-ID(s), target of event reporting) and optional input parameters used to retrieve the data. Formatting and Processing Instructions are as defined in clause 5A.4. The data consumer may optionally include the Data Source NF Instance (or NF Set) ID. The data consumer may include ADRF information indicating whether the data are to be stored in an ADRF and, optionally, an ADRF ID.

NOTE 1: Data consumer requesting data to be stored in ADRF allows the collected data to be available to other data consumers in the future.

2. The DCCF checks if data is to be collected for a user, i.e. SUPI or GPSI, then, depending on local policy and regulations, the NWDAF checks the user consent by retrieving the user consent information from UDM using Nudm_SDM_Get including data type "User consent" and taking into account purpose for data collection as provided in step 1. If user consent is not granted, NWDAF does not subscribe to event exposure for events related to this user, the data collection for this SUPI or GPSI stops here and DCCF sends a response to the data consumer indicating that user consent for data collection was not granted. If the user consent is granted, the DCCF subscribes to UDM to notifications of changes on subscription data type "User consent" for this user using Nudm_SDM_Subscribe.

3. If the NF instance or NF Set ID is not provided by the data consumer, the DCCF determines the NF instances that can provide data as described in clause 5A.2 and clause 6.2.2.2. If the consumer requested storage of data in an ADRF, but the ADRF ID is not provided by the data consumer, or the collected data is to be stored in an ADRF according to configuration on the DCCF, the DCCF selects an ADRF to store the collected data.

4. The DCCF determines whether the data requested in step 1 are already being collected, as described in clause 5A.2.

5. The DCCF sends an Nmfaf_3daDataManagement_Configure (Data Consumer Information, MFAF Notification Information, Formatting Conditions, Processing Instructions) to configure the MFAF to map notifications received from the Data Source to outgoing notifications sent to endpoints and to instruct the MFAF how to format and process the outgoing notifications. The DCCF may also instruct the MFAF to store data into ADRF by providing an ADRF ID, if requested by the data consumer in step 1, together with the NF Id of the data source.

Data Consumer Information contains for each notification endpoint, the data consumer Notification Target Address (+ Data Consumer Notification Correlation ID to be used by the MFAF when sending notifications in step 9.

MFAF Notification Information is included if a Data Source is already sending the data to the MFAF. MFAF Notification Information identifies Event Notifications received from the Data Sources and comprises the MFAF Notification Target Address (+ MFAF Notification Correlation ID). If the MFAF does not receive MFAF Notification information from the DCCF, the MFAF selects a MFAF Notification Target Address (+ MFAF Notification Correlation ID) and sends the MFAF Notification Information, containing MFAF Notification Target Address (+ MFAF Notification Correlation ID), to the DCCF in the Nmfaf_3daDataManagement_Configure Response.

6. If the data subscribed in step 1 partially matches data that are already being collected by the DCCF from a Data Source and a modification of this subscription to the Data Source would satisfy both the existing data subscriptions as well as the newly requested data, the DCCF invokes Nnf_EventExposure_Subscribe (Subscription Correlation ID) with parameters indicating how to modify the previous subscription (as specified in clause 5A.2). The DCCF adds the data consumer to the list of data consumers that are subscribed for these data.

If the data requested at step 1 are not already available or not being collected yet, the DCCF subscribes to data from the NF using the Nnf_EventExposure_Subscribe (Data Specification, MFAF Notification Target Address (+ MFAF Notification Correlation ID)) service operation as specified in clause 5A.2 and clause 6.2.2.2, using the MFAF Notification Target Address (+ MFAF Notification Correlation ID) received in step 5. The DCCF adds the data consumer to the list of data consumers that are subscribed for these data.

7. When new output data are available, the Data Source uses Nnf_EventExposure_Notify to send the data to the MFAF. The Notification includes the MFAF Notification Correlation ID.

8. The MFAF uses Nmfaf_3caDataManagement_Notify to send the data to all notification endpoints indicated in step 6. Notifications are sent to the Notification Target Address(es) using the Data Consumer Notification Correlation ID(s) received in step 6. Data sent to notification endpoints may be processed and formatted by the MFAF, so they conform to delivery requirements specified by the data consumer. The MFAF may store the information in ADRF if requested by consumer or if required by DCCF configuration

NOTE 2: According to Formatting Instructions provided by the data consumer, multiple notifications from a Data Source can be combined in a single Nmfaf_3caDataManagement_Notify, so many notifications from the Data Source results in fewer notifications (or one notification) to the data consumer. Alternatively, a notification can instruct the data notification endpoint to fetch the data from the MFAF before an expiry time.

9. If a Nmfaf_3caDataManagement_Notify contains a fetch instruction, the notification endpoint sends a Nmfaf_3caDataManagement_Fetch request to fetch the data from the MFAF.

10. The MFAF delivers the data to the notification endpoint.

11. The UDM may notify the DCCF on changes of user consent at any time after step 2. If user consent is no longer granted for a user for which data has been collected and if there are no other consumers for the data, the DCCF shall unsubscribe to any Event ID to collect data for that SUPI or GPSI. The DCCF shall further update or terminate affected subscriptions of the Data Consumer. The DCCF may unsubscribe to be notified of user consent updates from UDM for each SUPI for which user consent has been revoked.

12. When the data consumer no longer wants data to be collected, it invokes Ndccf_DataManagement_Unsubscribe (Subscription Correlation ID), using the Subscription Correlation Id received in response to its subscription in step 1. The DCCF removes the data consumer from the list of data consumers that are subscribed for these data.

13. If there are no other data consumers subscribed to the data, the DCCF unsubscribes with the Data Source.

14. The DCCF de-configures the MFAF so it no longer maps notifications received from the Data Source to the notification endpoints configured in step 5.

6.2.6.3.5 Historical Data Collection via Messaging Framework

The procedure depicted in figure 6.2.6.3.5-1 is used by data consumers (e.g. NWDAF) to obtain historical data, i.e. data related to past time period. The data consumer obtains data using Ndccf_DataManagement_Subscribe service operation as specified in clause 8.2.2, where the subscription results in one or more notifications depending on how the data is retrieved from the ADRF or NWDAF and how the data is formatted. Whether the data consumer uses this procedure or directly contacts the ADRF or NWDAF is based on configuration.

Figure 6.2.6.3.5-1: Historical Data Collection via Messaging Framework

1. The data consumer requests data via DCCF by invoking the Ndccf_DataManagement_Subscribe (Service Operation, Data Specification, Time Window, Formatting Instructions, Processing Instructions, ADRF ID or NWDAF ID (or ADRF Set ID or NWDAF Set ID) service operation as specified in clause 8.2.2. The data consumer may specify one or more notification endpoints to receive the data. If data to be collected is subject to user consent: if the data consumer checked user consent, the data consumer shall provide user consent check information (i.e. an indication that it has checked user consent), otherwise, the data consumer shall provide a purpose for the data collection.

Service_Operation is the service operation used to acquire the data from a data source, Data Specification provides Service_Operation-specific required parameters (e.g. event IDs, UE-ID(s) and optional input parameters used to retrieve the data. Time Window specifies a past time period and comprises a start and stop time and Formatting and Processing Instructions are as defined in clause 5A4. The data consumer may optionally include the ADRF or NWDAF instance (or ADRF Set or NWDAF Set) ID where the stored data resides.

NOTE 1: An ADRF or NWDAF might have previously registered data it is collecting with the DCCF.

4. The DCCF sends an Nmfaf_3daDataManagement_Configure (Data Consumer Information, Formatting Conditions, Processing Instructions) to configure the MFAF to map notifications received from the ADRF or NWDAF to outgoing notifications sent to endpoints and to instruct the MFAF how to format and process the outgoing notifications.

"Data Consumer Information" contains for each notification endpoint, the data consumer Notification Target Address (+ Data Consumer Notification Correlation ID) to be used by the MFAF when sending notifications. The MFAF selects an MFAF Notification Target Address (+ MFAF Notification Correlation ID) and sends the MFAF Notification Information, containing MFAF Notification Target Address (+ MFAF Notification Correlation ID), to the DCCF in the Nmfaf_3daDataManagement_Configure Response.

5. (conditional) If the DCCF determines that an ADRF instance might provide the data, or an ADRF instance or Set was supplied by the data consumer, the DCCF sends a request to the ADRF, using Nadrf_DataManagement_RetrievalSubscribe (Data Specification, MFAF Notification Information) containing the MFAF Notification Target Address (+ MFAF Notification Correlation ID) received in step 4 as specified in clause 10.2.

6. The ADRF responds to the DCCF with an Nadrf_DataManagement_RetrievalSubscribe response indicating if the ADRF can supply the data. If the data can be provided, the procedure continues with step 9.

7. (conditional) If the DCCF determines that an NWDAF instance might provide the data, or an NWDAF instance or NWDAF Set was supplied by the data consumer, the DCCF sends a request to the NWDAF, using Nnwdaf_DataManagement_Subscribe (Data Specification, MFAF Notification Information) as specified in clause 7.4.2. MFAF Notification Information contains the MFAF Notification Target Address (+ MFAF Notification Correlation ID) received in step 4.

8. The NWDAF responds to the DCCF with an Nnwdaf_DataManagement_Subscribe response indicating if the NWDAF can supply the data.

9. The ADRF uses Nadrf_DataManagement_RetrievalNotify or the NWDAF uses Nnwdaf_DataManagement_Notify to send the requested data (e.g. one or more stored notifications archived from a data source) to the MFAF. The data may be sent in one or more notification messages.

10. The MFAF uses Nmfaf_3caDataManagement_Notify to send data to all notification endpoints indicated in step 4. Notifications are sent to the Notification Target Address(es) using the Data Consumer Notification Correlation ID(s) received in step 4. Data sent to notification endpoints may be processed and formatted by the MFAF, so they conform to delivery requirements specified by the data consumer.

NOTE 2: According to Formatting Instructions provided by the data consumer, multiple notifications from an ADRF or NWDAF can be combined in a single Nmfaf_3caDataManagement_Notify so many notifications from the ADRF or NWDAF results in fewer notifications (or one notification) to the data consumer. Alternatively, a Nmfaf_3caDataManagement_Notify can instruct the data notification endpoint to fetch the data from the MFAF before an expiry time.

11. If a notification contains a fetch instruction, the notification endpoint sends a Nmfaf_3caDataManagement_Fetch request as specified in clause 9.3.3 to fetch the data from the MFAF.

12. The MFAF delivers the data to the notification endpoint.

13. The UDM may notify the DCCF on changes of user consent at any time after step 2. If user consent is no longer granted for a user for which data has been collected and if there are no other consumers for the data, the DCCF shall unsubscribe to any data collection for that SUPI or GPSI. The DCCF shall further update or terminate affected subscriptions of the Data Consumer. The DCCF may unsubscribe to be notified of user consent updates from UDM for each SUPI for which user consent has been revoked.

14. When the data consumer no longer wants data to be collected or has received all the data it needs, it invokes Ndccf_DataManagement_Unsubscribe (Subscription Correlation ID), using the Subscription Correlation Id received in response to its subscription in step 1.

15. If the data are being provided by an ADRF and there are no other data consumers subscribed to the data, the DCCF unsubscribes with the ADRF using Nadrf_DataManagement_RetrievalUnsubscribe as specified in clause 10.2.7.

16. If the data are being provided by an NWDAF and there are no other data consumers subscribed to the data, the DCCF unsubscribes with the NWDAF using Nnwdaf_DataManagement_Unsubscribe as specified in clause 7.4.3.

17. The DCCF de-configures the MFAF so it no longer maps notifications received from the ADRF or NWDAF to the notification endpoints configured in step 4.

6.2.6.3.6 Data collection profile registration

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 ARDF 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

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

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.).

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

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

4. To obtain historical data and if the data consumer is configured to be 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.

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.