5 Network Data Analytics Functional Description

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

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

5.1 General

The NWDAF provides analytics to 5GC NFs and OAM as defined in clause 7. An NWDAF may contain the following logical functions:

– Analytics logical function (AnLF): A logical function in NWDAF, which performs inference, derives analytics information (i.e. derives statistics and/or predictions based on Analytics Consumer request) and exposes analytics service i.e. Nnwdaf_AnalyticsSubscription or Nnwdaf_AnalyticsInfo.

– Model Training logical function (MTLF): A logical function in NWDAF, which trains Machine Learning (ML) models and exposes new training services (e.g. providing trained ML model) as defined in clause 7.5 and clause 7.6.

NOTE 1: NWDAF can contain an MTLF or an AnLF or both logical functions.

NOTE 2: Pre-trained ML model storage and provisioning to NWDAF is out of the scope of 3GPP.

Analytics information are either statistical information of the past events, or predictive information.

Different NWDAF instances may be present in the 5GC, with possible specializations per type of analytics. The capabilities of a NWDAF instance are described in the NWDAF profile stored in the NRF.

To guarantee the accuracy of analytics output for an Analytics ID, based on the UE abnormal behaviour analytics from itself or other NWDAF including abnormal UE list and the observed time window, the NWDAF is to detect and may delete the input data from the abnormal UE(s) and then may generate a new ML model and/or analytics outputs for the Analytics ID without the input data related to abnormal UE list during the observed time window and then send/update the ML Model Information and/or analytics outputs to the subscribed NWDAF service consumer.

In order to support NFs to discover and select an NWDAF instance containing MTLF, AnLF, or both, that is able to provide the required service (e.g. analytics exposure or ML model provisioning) for the required type of analytics, each NWDAF instance should provide the list of supported Analytics ID(s) (possibly per supported service) when registering to the NRF, in addition to other NRF registration elements of the NF profile. NFs requiring the discovery of an NWDAF instance that provides support for some specific service(s) for a specific type of analytics may query the NRF for NWDAFs supporting the required service(s) and the required Analytics ID(s).

The consumers, i.e. 5GC NFs and OAM, decide how to use the data analytics provided by NWDAF.

The interactions between 5GC NF(s) and the NWDAF take place within a PLMN.

The NWDAF has no knowledge about NF application logic. The NWDAF may use subscription data but only for statistical purpose.

The NWDAF architecture allows for arranging multiple NWDAF instances in a hierarchy/tree with a flexible number of layers/branches. The number and organisation of the hierarchy layers, as well as the capabilities of each NWDAF instance remain deployment choices.

In a hierarchical deployment, NWDAFs may provide data collection exposure capability for generating analytics based on the data collected by other NWDAFs, when DCCF, MFAF are not present in the network.

In order to make NWDAF discoverable in some network deployments, NWDAF may be configured (e.g. for UE mobility analytics) to register in UDM (Nudm_UECM_Registration service operation) for the UE(s) it is serving and for the related Analytics ID(s). Registration in UDM should take place at the time the NWDAF starts serving the UE(s) or collecting data for the UE(s). Deregistration in UDM takes place when NWDAF deletes the analytics context for the UE(s) (see clause 6.1B.4) for a related Analytics ID.

NOTE 3: The procedures for data collection for UE related analytics need to take user consent into account. The user consent for analytics is defined in clause 6.2.9.

5.2 NWDAF Discovery and Selection

The NWDAF service consumer selects an NWDAF that supports requested analytics information and required analytics capabilities and/or requested ML Model Information by using the NWDAF discovery principles defined in clause 6.3.13 of TS 23.501 [2].

Different deployments may require different discovery and selection parameters. Different ways to perform discovery and selection mechanisms depend on different types of analytics/data (NF related analytics/data and UE related analytics/data). NF related refers to analytics/data that do not require a SUPI nor group of SUPIs (e.g. NF load analytics). UE related refers to analytics/data that requires SUPI or group of SUPIs (e.g. UE mobility analytics).

In order to discover an NWDAF containing AnLF using the NRF:

– If the analytics is related to NF(s) and the NWDAF service consumer (other than an NWDAF) cannot provide an Area of Interest for the requested data analytics, the NWDAF service consumer may select an NWDAF with large serving area from the candidate NWDAFs from discovery response. Alternatively, in case the consumer receives NWDAF(s) with aggregation capability, the consumer preferably selects an NWDAF with aggregation capability with large serving area.

NOTE 1: If the selected NWDAF cannot provide the requested data analytics, e.g. due to the NF(s) to be contacted being out of serving area of the NWDAF, the selected NWDAF might reject the analytics request/subscription or it might query the NRF with the service area of the NF to be contacted to determine another target NWDAF.

– If the analytics is related to UE(s) and the NWDAF service consumer (other than an NWDAF) cannot provide an Area of Interest for the requested data analytics, the NWDAF service consumer may select an NWDAF with large serving area from the candidate NWDAFs from discovery response. Alternatively, in case the consumer receives NWDAF(s) with aggregation capability, the consumer preferably selects an NWDAF with aggregation capability with large serving area.

NOTE 2: If a selected NWDAF cannot provide analytics for the requested UE(s) (e.g. the NWDAF serves a different serving area), the selected NWDAF might reject the analytics request/subscription or it might determine the AMF serving the UE as specified in clause 6.2.2.1, request UE location information from the AMF and query the NRF with the tracking area where the UE is located to discover another target NWDAF serving the area where the UE(s) is located.

If the NWDAF service consumer needs to discover an NWDAF that is able to collect data from particular data sources identified by their NF Set IDs or NF types, the consumer may query NRF providing the NF Set IDs or NF types in the discovery request.

NOTE 3: The NF Set ID or NF Type of a data source serving a particular UE, can be determined as indicated in Table 5A.2-1.

In order to discover an NWDAF that has registered in UDM for a given UE:

– NWDAF service consumers or other NWDAFs interested in UE related data or analytics, if supported, may make a query to UDM to discover an NWDAF instance that is already serving the given UE.

If an NWDAF service consumer needs to discover NWDAFs with data collection exposure capability, the NWDAF service consumer may discover via NRF the NWDAF(s) that provide the Nnwdaf_DataManagement service and their associated NF type of data sources or their associated NF Set ID of data sources as defined in clause 6.3.13 of TS 23.501 [2].

In order to discover an NWDAF containing MTLF via NRF:

– an NWDAF containing MTLF shall include the ML model provisioning services (i.e. Nnwdaf_MLModelProvision, Nnwdaf_MLModelInfo) as one of the supported services during the registration in NRF when trained ML models are available for one or more Analytics ID(s). The NWDAF containing MTLF may provide to the NRF a (list of) Analytics ID(s) corresponding to the trained ML models and possibly the ML Model Filter Information for the trained ML model per Analytics ID(s), if available. In this Release of the specification, only the S-NSSAI(s) and Area(s) of Interest from the ML Model Filter Information for the trained ML model per Analytics ID(s) may be registered into the NRF during the NWDAF containing MTLF registration. For each Analytics ID, the NWDAF containing MTLF may also include, in the registration to the NRF, an ML Model Interoperability indicator.

– The ML Model Interoperability indicator comprises a list of NWDAF providers (vendors) that are allowed to retrieve ML models from this NWDAF containing MTLF. It also indicates that the NWDAF containing MTLF supports the interoperable ML models requested by the NWDAFs from the vendors in the list.

Editor’s note: It is FFS if the ML Model Interoperability indicator is per Analytics ID.

NOTE 4: The S-NSSAI(s) and Area(s) of Interest from the ML Model Filter Information are within the indicated S-NSSAI and NWDAF Serving Area information in the NF profile of the NWDAF containing MTLF, respectively.

– During the discovery of NWDAF containing MTLF, a consumer (i.e. an NWDAF containing AnLF) may include in the request the target NF type (i.e. NWDAF), the Analytics ID(s), the S-NSSAI(s), Area(s) of Interest of the Trained ML Model required and NF consumer information. The NRF returns one or more candidate for instances of NWDAF containing MTLF to the NF consumer and each candidate for instance of NWDAF containing MTLF includes the Analytics ID(s) and possibly the ML Model Filter Information for the available trained ML models, if available.

NOTE 5: NF consumer information such as Vendor ID is defined in stage 3.

A PCF may learn which NWDAFs being used by AMF, SMF and UPF for a specific UE, via signalling described in clause 4.16 of TS 23.502 [3]. This enables a PCF to select the same NWDAF instance that is already being used for a specific UE.