NWDAF: the blessing 5G core needs to reach a data-driven network

3GPP and NWDAF: in a nutshell

3GPP took on the task of standardizing 5G core (5GC) analytics, by providing the necessary standard for areas where several vendors have to interact with each other. NWDAF was added to 3GPP SA2 standards to bring analytics capabilities to 5G Core (5GC) and define how other network functions (NFs) should interact with it.

NWDAF subscribes to NF data when needed and responds back with insights from that data to the requesting consumer. This is the basic concept where the output from NWDAF ranges from data, statistics, to predictions that can make use of machine learning (ML) models. It’s the new pair of eyes 5GC needs and, if correctly implemented, will help reach a self-regulating network where services can be automatically improved on both the individual subscriber and network level.

Why do we need NWDAF?

Without NWDAF, the way data acquisition and processing is done in most core networks is based on simple methods. The signaling interactions between NFs are tapped/ mirrored. The taps stream the data to correlators and load balancers, then to the brokers where filtering is done, before further streaming to probes where subscriber-based events are created. This is the meta data of the transaction between NFs.

Data is sometimes referred to as ‘gold’ because it can be monetized. However, the final output – the events – are ‘real gold’ because they are a refined product: formed from the massive amounts of data that is generally thrown away once events have been created. If we continue with this analogy, NWDAF creates ‘24K gold’ by retrieving events from the 5GC NF, similar to the types of events Ericsson has provided since 2008, with the Event Based Monitoring (EBM) feature in our Serving GPRS Support Node (SGSN) and Evolved Packet Gateway (EPG) Core products.

The taps, brokers and probes are normally provided by third party (3P) vendors, as shown to the left in figure 1.

Figure 1: What will NWDAF bring to 5G Core?

There are both pros and cons of data acquisition using the tap/mirror/probe method. These are:

Pros:

• The external solution can be independent from the underlaying core solution. In a multi-vendor deployment, CSPs have favored the idea that independent troubleshooting is needed, otherwise core vendors will blame each other if it’s difficult to determine who/what caused the signal failure. However, due to the high transparency grade we have today, I don’t believe this is a valid concern.

Cons:

• The lack of standards for data acquisition results in an integration nightmare in complex networks, where different tap, broker and probe vendors need to co-exist to provide a complete set of data to fulfil the complete suite of use cases: spanning from troubleshooting, monitoring to assurance. Integration projects take time and involve many parties.
• Mirroring up to 100 percent of traffic, 24/7 requires a massive amount of processing and memory capacity.
• Life cycle management (LCM) of this equipment is extensive, especially in networks that need elasticity as provided by cloud native node deployments
• The Total Cost of Ownership (TCO) created by these cons is extensive and eats into profit margins for the CSPs.
• When data is acquired, it needs to be stored to support any type of use case that a CSP might want to cover. However, there are limited possibilities to steer what kind of data should be mirrored in the core network, and what should be stored. It is an ‘all or nothing’ approach and no dynamicity or on-demand handling is supported. As a result, a ‘big data lake’ is created regardless of whether you need all this data.
• Very few vendors offer the complete stack: some are specialized in tapping and correlation, broker or probing, or providing use cases to deliver insights and statistics. Each vendor needs to cooperate and share interface specifications to be compatible with each other.

With NWDAF, the events – the 24K gold – are instead provided directly by the 5G Core (5GC) NF from the event exposure interface, which supports the data on request and omits the need to store unnecessary data. In the NF, the events are created when signaling procedures are processed per subscriber interaction e.g., when a subscriber moves to a new location it initiates a New Radio (NR) handover where information about this event is created per UE (User Equipment) and can be collected over the NWDAF Network Function Interface (Nnf). This allows you to collect what you need to support the use cases you have enabled in the NWDAF analytics function. An example is the capture and provide user plane events that require a deep packet inspection. In the Ericsson Packet Core Gateway (PCG), events are created in the packet inspection module in the process of classifying traffic for UE. It is very efficient to do the classification and to create the event simultaneously in the business logic. If the event needs to be provided externally, a new packet inspection process is needed on the same user data – thereby, performing double the amount of work and becoming resource heavy.

The tapping of interfaces is still greatly needed to fulfill troubleshooting use cases – and in some markets its regulatory to store all traffic for a certain period – but as we move forward, the need to refine this data source in probes won’t be necessary when NWDAF becomes a reality.

Of course, what you do with the data is ultimately what determines its final value, but the resources a use case consumes are also of the highest importance – especially when AI is used to realize it. If the NWDAF standard is adopted by all major core vendors we can get rid of these inefficient data collection methods, driving substantial changes to the tapping and probe business.

 How does Ericsson SW Probe relate to NWDAF?

With the software (SW) probe we provide two data sources: Virtual Tapping (vTap) and event reporting.

vTap is an important troubleshooting source and will remain so even when NWDAF is deployed. These data sources allow continuous tapping/mirroring of the signaling interfaces, providing RAW data in clear. This feature supports collection from all interfaces 24/7, but can also be configured to steer the tapping need. Troubleshooting use cases can be handled on a more ad hoc basis and aren’t needed to produce 100 percent of all the data, on all interfaces, at all times.

For the other data source provided by SW probe: the event reporting, we’ll benefit from all investments we’ve made in events being produced in the NF, when data becomes standardized in NWDAF event exposure – and we are very well positioned to add this new interface. These events have been provided in Packet Core nodes since 2008 when we launched the feature Event based Monitoring (EBM), and after that refined the SW probe feature.

These benefits include:

1. The event reporting data source is a continuation with refinement around the consumer interaction, content and interface capabilities
2. More events and details of the events has been added to enhance usage
3. Events can be streamed to multiple consumers with individual configuration of content, which is required from a publish/subscribe type of interface

 In SW probe development we've made sure to create an efficient way to subscribe to different events and stream them to multiple consumers, as well as including more powerful methods to broker or filter the data; this is necessary when providing the NWDAF event exposure interface. Core vendors that don’t have this data source available – and are instead relying on external probes – will be at a disadvantage. Today, event reporting is an open interface that any 3P could interact with and collect events instead of going the long and costly way to collect it from the external 3P probes. Ericsson Expert Analytics (EEA), Traffic Monitoring Application (TMA) and some other customer tools use event reporting data but, as yet, there are still very few 3P solutions. The main reason for this is proprietary, but this will change when aligning towards NWDAF. Consumers of event data in general (mainly 3P probe events) need to align towards NWDAF standard event exposure which could be a challenge for CSPs.

The challenge of a standard is not to define it, but to make vendors comply to it

Now let’s turn to standards – personally, I am in strong favor of standards as they give all vendors something to align around: they set clear targets when it comes to development and also interacting with each other's product. However, standards still have some drawbacks. NWDAF was initially immature in release 16 (Rel-16), before maturing in release 17 (Rel-17), thereby making it possible to build product compliance around. However, despite this update we are still seeing deviation in the market. The vendors that are the ‘loudest’ when it comes to NWDAF state compliance are the traditional 3P Probe vendors today – although all 3Ps are dependent on the NWDAF NF event data to be efficient. They won’t wait for the core vendors, but instead will rely on their own probes and provide other NWDAF values like analytics ID (use case) coverage and post statistics and insights. As a result, CSPs will not be able to benefit fully from the standard and the total cost of ownership (TCO) will still be remarkably high. The 3P NWDAF vendors have no incitement of pushing for NF event exposure because that would be a direct threat to their probing business. For core vendors it will be a challenge to provide event exposure as a new area, since it’s costly to implement the interface. In a multi core vendor deployment, all core NFs will need to provide events – if not, probes will still be needed in the network. There is a tipping point before all advantages from the standard becomes a reality. It’s up to CSPs to drive this request forward in their RFP (Request for Proposal) processes.

Ericsson’s approach for providing NWDAF

Watch this video to understand the value of Ericsson's NWDAF.

The NWDAF NF is described in 3GPP SA2 to be a separate NF which shall be providing network analytics information upon request from consumers such as other 5G Core NF e.g., Access and Mobility Management (AMF) Function, Session Management Function (SMF), Network Repository Function (NRF) and Policy and Control Function (PCF).

When we sketched out Ericsson’s NWDAF solution and the strategies around it, we had efficiency and a low footprint in mind. We also looked at which products in our portfolio already provide advanced analytics on a subscriber level and realized it was difficult to provide a compelling solution with how 3GPP had defined NWDAF as a single NF – this is because it would mean that all data needed to travel to the same location. Instead, we saw the need for some use cases that can be supported on the edge close to the other NF – as it would be very inefficient to send out data and get it back to the same NF to take the action. As a result, we came up with the solution of having several NWDAF instances that would have dedicated tasks but, in-between, could also cooperate to help with use cases that require a massive amount of data and still require a central aggregation on the network level. In 3GPP SA2 Rel-17, Ericsson enhanced the co-located NWDAF.

This approach allows customers to still choose whether they need flexibility or not. Use case model portability between NWDAF instances is important in this approach to avoid double use case development. Ericsson NWDAF NF architecture is built-up from common reusable micro services. The same building blocks are then used regardless of which Ericsson product the NWDAF NF is deployed in – see illustration of the NWDAF deployment relation in figure 2.

Figure 2. Ericsson’s NWDAF solution

In Ericsson’s NWDAF offering we provide co-located NWDAF deployment in selected core products. It will be available with four products: Packet Core Controller (PCC), Packet Core Gateway (PCG), Cloud Core Policy Controller (CCPC) and Cloud Core Resource Controller (CCRC).

The standalone located NWDAF is needed at the network wide aggregation of data and is  provided by Ericsson Expert Analytics (EEA). Technically – if it can get hold of the data it needs and the latency is acceptable – a centrally located NWDAF can support any kind of use case. Performance and footprint will be provided as declaration for use cases, so it will be easy to understand what impact the deployment aspect has.

When the NWDAF is co-located to NFs it makes use of data from the co-located sources and acts as a NWDAF in all aspects. This will make it possible to extract statistics and insights from it. One major advantage with a co-located NWDAF is that it can focus on supporting a specific NF. If a use case is supported in the co-located NWDAF – and all data needed to fulfill the use case comes from that NF – it is a large saving compared to transporting it out to a central NWDAF.

To support CSPs in best feasible way we have taken a use case-based approach

Analytics IDs defined in the 3GPP standard are evolved around use cases. During discussions with our customers, we hear that some defined use cases are highly needed, whereas others are regarded as ‘less interesting.’ When we started to sketch out the NWDAF strategy, we agreed to have a use case-based approach, meaning we want to carefully select use cases to develop based on the following principles:

• Aligned customer use case request and proven value to customers
• Efficient data handling to limit footprint of both analytics' platform in rest and low footprint per executed use case
• Use case model re-use and portability between NWDAF instances.
• The cost of developing a use case and the cost of execute and lifecycle must be in parity with the value it brings to the CSP
• Allow customers to configure and adjust provided use cases
• Allow customers to build their own use cases in the Software Development Kit (SDK) provided by the NWDAF solution
• Clear visibility of use case execution, statistics and insight

This gives CSPs the visibility they need and the ability to improve and maintain this function and use cases. Pure configuration flexibility is not always the best approach. Having the SDK to support adjustments and to build own use cases, together with the proper Graphical User Interface (GUI), is something we think is needed to ensure CSP trust and engagement around analytics and automation.

If NWDAF was a cake, the following would be the ingredients:  Firstly, we would start with the sponge cake – the competent and stable analytics services that are re-usable between deployments. This provides the base from where events and statistics could be extracted from the interface. We will then provide the cream – the addition of use cases – that prove the value of NWDAF analytics in field. To steer the function, it would be possible to adjust models over configuration with North Bound Interface (NBI), before following up with more advanced use cases that have the need for AI/ML services. Finally, SDK would provide the extended value – ‘the cherry on top’ – of Ericsson’s delicious NWDAF cake.

NWDAF is the enabler for automation

Finally, when NWDAF has provided insight, it needs to be consumed and used. This insight could be a report or statistics received by a NF, an application function (AF), or any consumer for that matter. The insight is the enabler for action and closed loop automation; therefore, it needs to be possible for it to be acted on.

There are several feasible options to consider, with the action you take dependent on who is the consumer of analytics. The necessary actions might require:  a re-configuration by the Operational Support System (OSS), the enforcement in NF when consumer is the NF itself, or having the policy steered or intent steered to cover the impact of changes. To gain the trust of CSPs good visibility and activation reports must be supported in all options.

For co-located NWDAF closed looping can be done within the node itself, therefore if automation is supported for a use case the closed looping is also part of that specific use case model. The action can also be a task for other NF in the Core.

For standalone NWDAF it is more valid to be able to align to the CSP selected automation framework. Here we acknowledge that there are several different solutions available such as Open Networking Automation Platform (ONAP), intent-based automation and Ansible, to mention a few. The closed loop is not covered by 3GPP in relation to NWDAF in Rel-17, However, in release 18 (Rel-18) Ericsson will further refine NWDAF and automation handling.

Do you want to read more about Ericsson NWDAF solution?

Read more:

Explore 5G.

Explore Cloud Native

Discover how 5G core unleashes a new era of scalable and service-rich cloud-native networks.

Explore 5G core solutions that make it possible for you to deploy, scale and evolve your operations across multiple deployment scenarios.