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.