5G Network Data Analytics

Since our last blog on this area, the 3GPP standards supporting 5G network data analytics have moved on quite considerably so it’s worth pausing for a moment to see what’s changed. If you didn’t know before reading this, network analytics is set to transform the way 5G networks and beyond will operate, offering features such as self-healing, autonomous network optimization, predictive fault diagnosis and user experience optimization.

When the concept of analytics was introduced to 5G by the 3GPP, the list of capabilities was pretty underwhelming; essentially, if you were interested in Network Slice Load Level, fantastic. Otherwise, there wasn’t really anything else to get excited about. However, in Release 16 and Release 17 of the 3GPP specifications, both the suite of potential analytics use cases and the architecture supporting network analytics has evolved considerably.

To begin with, what’s changed about the architecture? Originally, we had the NWDAF (Network Data Analytics Function), the critical component of the analytics architecture which will harvest the raw data, process it and produce meaningful analytical data. Along the way, ML (Machine Learning) trained models can be generated by the NWDAF and utilized by other NWDAFs in the network, with a view to eventually having full closed loop automation to assist with a wide range of network optimization tasks. From an architectural perspective, the NWDAF remains the main analytics function, but we now have support from three additional functions, as outlined in Figure 2.

These functions are detailed as follows:

• DCCF (Data Collection Coordination Function) – in a particularly complicated analytics deployment, multiple NWDAFs may need the same raw data (the input to the NWDAF). Moreover, multiple network functions may need the same analytics data (the output of the NWDAF). To avoid duplicate requests for the same data and hence avoid identical raw data or analytics data being generated, requests for data can be coordinated by the DCCF. That is, all requests will first of all be sent to the DCCF, which will then arrange the delivery of the requested data (without data producers receiving duplicated requests). Note that use of the DCCF is not mandatory.
• MFAF (Messaging Framework Adapter Function) – a Messaging Framework is a means by which analytics or event notifications (carrying raw data for the NWDAF to process) can be distributed around the network. The operation of the Messaging Framework is not standardized by the 3GPP and such, an MFAF can be deployed to offer a standard set of services to the likes of the NWDAF and DCCF, without either of these functions being exposed to the Messaging Framework directly.
• ADRF (Analytics Data Repository Function) – one or more ADRF instances can be deployed in the network to store raw data or associated analytics that have been performed on that data. The NWDAF, DCCF or MFAF can store, access and delete data and analytics as required. In addition, the ADRF can be instructed to subscribe to event notifications to allow data or analytics to be automatically harvested by the ADRF.

All of these functions are considered to be part of the SBA (Service Based Architecture) and as such, the 3GPP have defined each of their Service Based Interfaces. For example, the Nadrf SBI defines the exact format a request to store analytics data should follow. Alternatively, the Nnwdaf SBI defines the exact way in which a network function can subscribe to the delivery of specific analytics data, amongst many other capabilities.

As can be seen in Figure 3, the 3GPP have now standardized a much wider range of network analytics use cases, moving way beyond the original Slice Load level requirement.

The various use cases can briefly be described as follows:

• Slice Load Level – monitoring total number of registered devices and PDU Sessions on a network slice.
• Observed Service Experience – using estimated MOS (Mean Opinion Score) to evaluate the way in which a user is experiencing their service.
• NF (Network Function Load) – utilising data from the NRF (Network Repository Function) and cloud management to monitor NF load and capacity.
• Network Performance – focusing on RAN utilization and performance, relative to a specific coverage area.
• UE Related (various) – this can cover analytics related to UE mobility and UE communication (the number of PDU Sessions a UE is utilizing), including on a predictive basis. In addition, abnormal UE behaviour also falls under this category.
• User Data Congestion – monitoring congestion within the RAN.
• QoS Sustainability – ensuring that QoS levels associated with a QoS Flow are being maintained.
• Dispersion – tracks the traffic offload patterns for either a single device or group of devices within a specific geographical area.
• WLAN Performance – performance data relative to a specific SSID (Service Set Identifier).
• SMCC (Session Management Congestion Control) Experience – ensures that when SMCC is in operation, backoff timers for congestion control are distributed fairly (there’s no one specific device that is experiencing significantly longer wait times than other devices).
• Redundant Transmission Experience – determines whether high reliability for specific services should be activated or deactivated.
• DN Performance – particularly relevant to monitoring the performance of a local data network as part of MEC (Multi access Edge Computing) based service delivery.

In all of the above cases, analytics data can be generated by the NWDAF on a statistical basis (historical or present), as well as a predictive basis. Moreover, different combinations of analytics can be used together e.g. based on historical usage of a particular cell and the device’s predicted mobility, the network can forecast that in 10mins time, the device’s QoS may diminish and as such preventative action can be taken to protect the user’s service experience.

At the time of writing, we’re some way off seeing these analytics in live 5G networks, particularly when areas such as network slicing are in their infancy. However, it’s clear that the impact these analytics can have on many different facets of the network is significant. Although we may not see all of these use cases as a commercial reality, there’s a huge amount of interest from vendors and service providers alike; hopefully, there’s enough interest to see analytics move beyond what we see here, with ML and AI unlocking the door to a huge range of new network analytics features.

For more information on this topic, check out our latest course “5G Network Data Analytics” or our other 5G training courses.

2025 Update

Since writing this article, we’ve seen the final version of the Release 18 specifications for network data analytics, as well as the almost final version of Release 19. As expected, additional services have been introduced, which are outlined in the following list of “observed events” that can be reported by the NWDAF:

• PDU Session traffic – it’s possible to set up a PDU session with a traffic filter (termed a traffic descriptor), to ensure that a specific type of traffic (filtered by elements such as IP and port) uses that PDU session. This particular analytics type will report on the volume of traffic that has been sent over the PDU that fits the traffic descriptor, as well as the volume of traffic that doesn’t fit the traffic descriptor.
• Movement Behaviour – this analytics type will provide information on the number of UEs, their direction and their velocity within a specific target area, during a set time period. This can include predictive behaviour and may also be tied in to the congestion level for a particular area.
• Location Accuracy – Location Services use different techniques to determine the position of a device. This analytics type will determine, for a given area, how accurate a particular positioning technique is horizontally, as well as vertically (although the latter is optional).
• Relative Proximity – for this analytics type, a group of UEs can be placed into a cluster and the NWDAF can report on their proximity to one another. By understanding when UEs are in the proximity of other UEs, location accuracy can be improved e.g. UE location information with finer granularity than a Tracking Area can be provided by the NWDAF, without having to use Location Services.
• Signalling Storm – this analytics type relates to the detection, mitigation and prevention of network abnormalities such as signalling storms, whereby the network would be experiencing abnormal signalling rates (which can be statistical or predictive).

This blog was updated on 7th April 2025 by Gavin Mitchell.