The Network Data Analytics Function (NWDAF) is a 3GPP-standardized network function, introduced in Release 15, that collects data from across the 5G core, processes it into analytics, and exposes those insights back to other network functions so they can automate decisions such as policy setting, slice selection, and load-aware SMF or UPF selection. It is the mechanism by which the 5G core turns raw operational data into closed-loop automation—and 3GPP has deliberately standardized what data it examines and how analytics are exchanged, while leaving the internal algorithms themselves unstandardized.
What is the Network Data Analytics Function (NWDAF)?
NWDAF was specified from 5G's initial release, Release 15, and is designed to control the management of sophisticated network data, as set out in 3GPP TS 29.520. According to 3GPP's own description of the function, upon receiving an analytics request from a consumer, the NWDAF collects network data, service data, management data and/or UE performance data from dedicated data sources, then processes and generates analytics information to help the consumer improve user experience and optimize network performance.
The function's stated purpose is to enhance network performance, operational assurance and resource utilization, and to enable self-optimization and automated management. A study paper by India's Telecommunication Engineering Centre notes that 3GPP developed NWDAF as part of Release 15 to enable machine learning and to let operators monitor the status of a network slice or third-party application performance, making it the central point for analytics in the 5G core network.
Importantly, the standardization effort is deliberately bounded. The Telecommunication Engineering Centre's study paper records that 3GPP does not plan to standardize the algorithms the NWDAF uses, but rather the types of raw information it examines. This means two vendor implementations can differ substantially in how they compute analytics while remaining compliant—a point worth remembering when evaluating any NWDAF product claim.
NWDAF's Architecture in the 5G Service-Based Architecture (SBA)
The 5G core is built as a service-based architecture: control-plane functions such as the Access and Mobility Management Function (AMF), Session Management Function (SMF), Policy Control Function (PCF), Network Slice Selection Function (NSSF) and Unified Data Management (UDM) expose their capabilities to one another over HTTP-based APIs. The Telecommunication Engineering Centre's study paper describes this as a major shift in the telecom world toward stateless functions and API-based interfaces, replacing protocols like Diameter.
NWDAF fits into this architecture as one more service-based function. The ETSI-published version of TS 29.520 defines the Nnwdaf service-based interface—the set of services the NWDAF exhibits to the rest of the core. The specification's abbreviation list confirms the ecosystem it operates within: AMF, SMF, UPF, PCF, NSSF, NRF, NEF, OAM and Application Function all appear as named entities around the analytics function.
Within this ecosystem, NWDAF acts as a centralized analytics provider rather than distributing analytics capability across individual network functions. A NETSCOUT explainer describes NWDAF as a 3GPP standard method that collects data from user equipment, network functions, and operations, administration and maintenance (OAM) systems within the 5G core, cloud and edge networks, and uses that data for 5G analytics that enhance the end-user experience.
NWDAF's Role and Data Flow in the 5G Core
To see how the pieces connect, trace a single analytics request through the standardized data flow. The framework below maps each stage: which functions supply data, what NWDAF does with it, and which consumers act on the result.
| Stage | Entities involved | What happens | Evidence anchor |
|---|---|---|---|
| 1. Analytics request | Consumer NF (e.g., PCF, NSSF) | Consumer subscribes to or requests a specific analytics type, identified by an Analytics ID | 3GPP network automation overview; TS 29.520 Nnwdaf services |
| 2. Data collection | AMF, SMF, UPF, OAM, UE performance data | NWDAF gathers network, service, management and/or UE performance data from dedicated data sources | 3GPP network automation overview |
| 3. Analytics generation | NWDAF | Processes collected data and produces statistical (past) or predictive (future) analytics information | 3GPP network automation overview |
| 4. Analytics exposure | NWDAF → consumer NF | Insights delivered via the Nnwdaf service-based interface, as continuous subscription updates or on-demand responses | TS 29.520 (ETSI publication) |
| 5. Automated action | PCF, NSSF, AMF, SMF | Consumer uses insights for policy/QoS decisions, slice selection, or less-loaded NF selection | 3GPP network automation overview |
The reader use of this framework is straightforward: pick any analytics-driven decision in the 5G core and you can locate it at stage 5, then work backward through exposure, generation and collection to identify exactly which data sources feed it. The subscription mechanism is concrete: the TS 29.520 specification defines the Nnwdaf_EventsSubscription service as part of the Nnwdaf interface, meaning consumers can register for ongoing notifications rather than polling.
Data Collection and Analytics Generation
The analytics themselves are requested and exchanged through a standardized addressing scheme. Within TS 29.520, analytics types are identified by Analytics IDs, and the Nnwdaf services are used for the NWDAF to provide specific analytics information, as the ETSI-published Release 16 specification states. This gives network functions a common vocabulary: a consumer does not need to know how an insight was computed, only which Analytics ID it needs.
On the input side, 3GPP's description identifies four categories of raw material: network data, service data, management data and UE performance data, drawn from dedicated data sources. The NETSCOUT explainer adds user equipment and OAM systems to this picture. On the output side, 3GPP notes the analytics information can be either statistical events that happened in the past or predictive information about the future—a distinction that matters for consumers deciding between reactive policy adjustment and proactive resource allocation.
The specification also handles the practical mechanics of a service-based interface. A summary of TS 29.520 describes operations such as POST, GET and PATCH for each API, feature negotiation between NWDAF and consumers, and NWDAF-specific application errors such as invalid subscriptions or missing data. These are the working details that make analytics exchange reliable in a production core.
Key Use Cases for NWDAF Analytics
The original Release 15 use case, documented in a survey of NWDAF research published on arXiv, involved interaction with the Policy Control Function to provide information about the network slice load level. The service was detailed in 2018 in TS 29.520. 3GPP's own overview extends this: a consumer such as the PCF or NSSF may subscribe to network slice load level analytics to assist in deriving policy or Quality of Service decisions and performing network slice selection.
A second family of use cases targets network function efficiency. 3GPP records that some NFs can use NWDAF analytics to select less-loaded NFs—for example, SMF selection by the AMF, or UPF selection by the SMF—to improve network efficiency. Here the analytics consumer is not a policy function but a routing decision-maker inside the core.
The PCF's role deserves specific attention because the standard is explicit about its limits. The ETSI-published TS 29.520 states that the PCF supports taking NWDAF input into consideration for policies on assignment of network resources and for traffic steering policies, and then adds a note: how this information is used by the PCF is not standardized in that release of the specification. The boundary between standardized analytics delivery and operator-defined policy logic is thus drawn inside the standard itself.
Enabling Closed-Loop Automation and Optimization
What makes NWDAF architecturally significant is that it closes the loop. Data flows in from AMF, SMF, UPF and OAM sources; analytics flow back out to PCF, NSSF, AMF and SMF; and those consumers act—adjusting policy, steering traffic, selecting slices or choosing less-loaded functions. Nokia's product description of NWDAF captures the same cycle in vendor terms: a network function that collects data from 5G core functions, performs analytics, and provides insights with closed-loop automation to authorized data consumers.
This centralization is a design choice, not an accident. By concentrating analytics in one function with a standardized interface, 3GPP avoids every network function having to implement its own data collection and analysis. The arXiv survey notes that academic research has largely focused on a limited set of methods and use cases, driven by dataset availability—so the standardized framework is broader in practice than much of the published literature exploring it.
3GPP is not finished. Its network automation overview states that the organization is actively and continuously enhancing 5G network intelligence in Release 19, with specified use cases mainly focusing on optimizing network resource utilization and improving user experience.
Implementing NWDAF for Enhanced 5G Network Automation
Network operators should leverage the standardized NWDAF architecture to centralize data analytics and enable closed-loop automation for improved network performance and resource utilization. The evidence supports a specific adoption path: begin with the Release 15 anchor use cases—network slice load level analytics feeding PCF policy and NSSF slice selection, and load-aware SMF and UPF selection—because these are the interactions 3GPP has specified in the greatest detail, and expand from there as Release 19 enhancements mature.
The measurable indicator to watch is the integration of NWDAF with various 5G Core NFs and the utilization of its analytics services for specific automation use cases, such as dynamic load balancing or predictive resource allocation. An operator can verify progress concretely: count which core functions hold active Nnwdaf event subscriptions, and check whether analytics outputs are actually driving decisions—for instance, whether AMF SMF selection or SMF UPF selection responds to NWDAF load information. Until those subscriptions exist and those decisions change, NWDAF is deployed but not yet closing the loop it was standardized to close.
