Description
The Data Network Access Identifier (DNAI) is a key enabler for edge computing and localized service access in the 5G System. It identifies a specific point where a PDU Session can access a Data Network, which often corresponds to a User Plane Function (UPF) instance deployed at a network edge location close to the user or the application server. The DNAI is not a network address but a logical identifier mapped by the 5G Core to the actual transport and UPF resources needed to reach a particular DN or service instance.
Architecturally, DNAI information is used within the Network Exposure Function (NEF) and the Session Management Function (SMF). An Application Function (AF), such as a video streaming server or an industrial IoT platform, can provide the DNAI to the 5G Core via the NEF to influence PDU Session routing. This is done through the AF influence on traffic routing service defined in TS 23.501. The AF request includes the DNAI and the desired traffic routing policy. The Core Network, specifically the SMF, then uses this DNAI, along with the UE's current location, to select a UPF that provides connectivity to the data network at the point identified by that DNAI. This may involve establishing a new PDU Session Anchor (PSA) UPF or relocating an existing one.
How it works involves close interaction between the application layer and the network layer. When a UE starts an application requiring edge resources, the AF signals the need for a connection via a specific DNAI. The SMF consults the Network Repository Function (NRF) and its local configuration to map the DNAI to a specific UPF instance (or set of instances) that can provide the required access. The SMF then manages the N4 session to the selected UPF and establishes the N6 connection to the DN. This dynamic steering allows the same logical service (identified by a Data Network Name, DNN) to be accessed through different physical points (identified by DNAIs) based on user mobility and application requirements, which is fundamental for ultra-reliable low-latency communication (URLLC) and mobile edge computing (MEC).
Purpose & Motivation
DNAI was created to solve the problem of static, suboptimal traffic routing in mobile networks, which was a major barrier to low-latency services like autonomous driving, industrial automation, and augmented reality. Prior to DNAI, a PDU Session to a Data Network (identified by a DNN) would typically egress the mobile core at a centralized location, adding significant latency for edge-based applications. There was no standardized way for an application to request a specific, geographically optimal access point.
Its introduction in Release 15 was motivated by the 5G requirement to support Edge Computing and network slicing with localized services. The DNAI provides the missing link between the application's awareness of where its service is hosted (e.g., at a specific edge data center) and the network's ability to route the user's traffic to that exact point. It addresses the limitation of the DNN, which only identifies *which* network to connect to, but not *where* to connect from within the mobile network's topology.
This capability unlocks new business models and technical possibilities. It allows operators to deploy multiple instances of the same service across their network and dynamically direct users to the closest one. It is essential for fulfilling the latency and bandwidth promises of 5G for vertical industries, enabling them to treat the mobile network as a distributed compute platform rather than just a connectivity pipe.
Release Timeline
Detected Changes Across Releases
from 3GPP Change RequestsSpecific changes extracted from the „Change history“ tables of 3GPP specifications (43 CRs across 4 releases). Complements the general historical overview above with the evidence-based evolution of this function.
In Release 15, the DNAI (Data Network Access Identifier) was formally defined as the identifier for a user plane access to one or more Data Networks. The introduction of the DNAI change notification type enabled the system to track and report changes in this access point. Furthermore, the DNAI became a key granularity for analytics and reporting, such as for UPF load analytics, predicted energy consumption, and predicted data volume, allowing for per-DNAI subscription and management of edge and network resources.
- DNAI change notification type TS 29.571CR0012
- Definition of DNAI TS 29.571CR0017
- DNAI change notification type TS 29.508CR0001
- Definition of DNAI TS 29.508CR0003
- Correct condition for DNAI in UP path change TS 29.508CR0037
- DNAI change notification type TS 29.514CR0001
+ 1 more changes
In Release 16, the DNAI (Data Network Access Identifier) function was enhanced to be explicitly included in analytics and reporting procedures. Specifically, the release introduced the inclusion of DNAI in Service and PDU Session Reporting and addressed the provisioning of DNAI lists. The technical groundwork was laid for performing key edge and energy consumption analytics per DNAI, enabling features like edge load analytics and energy efficiency predictions for specific data network access points.
In Release 17, the DNAI function was enhanced with new procedures for I-SMF discovery, selection, and removal based on DNAI, and with the capability to report DNAI information to external AAA servers. Furthermore, support was introduced for NWDAF-assisted DNAI and UPF selection at the SMF, integrating analytics for improved decision-making. The release also finalized and corrected several existing DNAI-based mechanisms to close related open issues.
- (I-)SMF discovery based on DNAI TS 29.502CR0431
- Downlink Tunnel Info of NG-RAN in I-SMF selection per DNAI TS 29.502CR0462
- I-SMF removal for target DNAI TS 29.502CR0491
- Reporting DNAI to RADIUS DN-AAA server TS 29.561CR0124
- Reporting DNAI to Diameter DN-AAA server TS 29.561CR0125
- NWDAF assisted DNAI and UPF selection at SMF TS 23.501CR2938
+ 5 more changes
In Release 18, the enhancements for DNAI primarily introduced support for a "common DNAI" and "common EAS" selection by the Application Function (AF) for a set of UEs, enabling more efficient edge traffic influence. This allows for edge relocation procedures using a common DNAI and the bundling of EAS availability change reports within the same DNAI. Furthermore, the release specified the storage of DNAI-EAS mapping data subsets in the UDR to support these new selection and influence capabilities.
- KI#4 23.501 AF traffic influence for common EAS, DNAI selection TS 23.501CR3788
- Common EAS/DNAI selection by AF TS 23.501CR3789
- KI#4 AF traffic influence for common EAS, DNAI selection TS 23.501CR3987
- Edge relocation with common DNAI TS 23.501CR4042
- AF obtaining DNAI associated to EAS TS 23.501CR4054
- Common EAS/DNAI determination for a set of UEs TS 23.501CR4686
+ 16 more changes
Explore further
Broader topics and technologies where DNAI plays a role.
Defining Specifications
3GPP specifications that define or reference DNAI, with the latest known release. Sourced from the 3GPP document catalog — see methodology.
| Specification | Title | Release |
|---|---|---|
| TS 23.436 vk00 | ADAEnabler Functional Architecture and Information Flows | Rel-20 |
| TS 23.501 vk00 | 5G System Architecture Stage 2 | Rel-20 |
| TS 23.558 vk00 | Architecture for Edge Applications | Rel-20 |
| TS 23.700 vk00 | XR Services Application Enablement Layer | Rel-20 |
| TR 23.758 vh00 | Study on Edge Application Architecture | Rel-17 |
| TS 24.229 vj50 | IMS call control protocol based on SIP and SDP | Rel-19 |
| TS 26.501 vj30 | 5G Media Streaming (5GMS) Architecture | Rel-19 |
| TR 26.803 vh00 | 5G Media Streaming Extensions for Edge Processing | Rel-17 |
| TS 26.891 vg00 | Media Distribution Services in 5G System | Rel-16 |
| TS 28.538 vj40 | Edge Computing Management (ECM) | Rel-19 |
| TR 28.844 vi00 | Technical Report on Charging Aspects of Satellite in 5GS | Rel-18 |
| TS 29.244 vj40 | PFCP Specification for Control/User Plane Separation | Rel-19 |
| TS 29.502 vj50 | 5G System; Nsmf Service Based Interface; Stage 3 | Rel-19 |
| TS 29.508 vj40 | 5G Session Management Event Exposure Service | Rel-19 |
| TS 29.514 vj40 | 5G System; Policy Authorization Service; Stage 3 | Rel-19 |
| TS 29.517 vj40 | 5G AF Event Exposure Service Stage 3 | Rel-19 |
| TS 29.519 vj40 | UDR Usage for Policy & Exposure Data | Rel-19 |
| TS 29.522 vj40 | 5G NEF Northbound APIs Stage 3 | Rel-19 |
| TS 29.549 vj40 | SEAL API Specification for Vertical Applications | Rel-19 |
| TS 29.558 vj40 | Enabling Edge Applications | Rel-19 |
| TS 29.561 vj30 | 5G Interworking with External Data Networks | Rel-19 |
| TS 29.571 vj50 | Common Data Types for 5G Service Based Interfaces | Rel-19 |
| TS 29.890 vg00 | CT3 5G System Technical Report | Rel-16 |
| TS 33.127 vj50 | Lawful Interception Architecture and Functions | Rel-19 |
| TS 33.128 vj50 | 3GPP TS 33.128: Lawful Interception Protocols | Rel-19 |
| TR 33.739 vi10 | Study on security enhancement of support for | Rel-18 |