Glossary term · Core Network

DDN

Downlink Data Notification

Core Network →

DDN is a signaling message from a Serving Gateway to inform the MME/SGSN of arrived downlink data for an idle UE, triggering the paging and bearer re-establishment procedure.

Introduced
Rel-13
Specifications
3 specs
Category
Core Network
Introduced
Rel-13
Specifications
3 specs
DDN Description Purpose Related Classification Detected Changes Specifications

Description

Downlink Data Notification (DDN) is a critical control plane procedure within the 3GPP Evolved Packet Core (EPC) and 5G Core (5GC) architectures. It operates when a User Equipment (UE) is in an idle state—specifically ECM-IDLE in LTE/EPC or CM-IDLE in 5G/5GC. In this state, the UE's radio connection is released to conserve battery, and the network only maintains the UE's context at the core network level (e.g., in the MME or AMF). When downlink data packets arrive from a Packet Data Network (PDN) Gateway (PGW) or User Plane Function (UPF) at the Serving Gateway (SGW) or Session Management Function (SMF), and the corresponding UE is idle, the SGW cannot forward the data because the user plane bearers are inactive. The SGW must therefore signal to the Mobility Management Entity (MME) in 4G or the Access and Mobility Management Function (AMF) in 5G to initiate the re-establishment of these bearers.

The DDN message is sent from the SGW to the MME over the S11 interface in 4G or from the SMF to the AMF over the N11 interface in 5G. This message contains identifiers such as the EPS Bearer ID or PDU Session ID and the UE's IP address to uniquely identify the session for which data is pending. Upon receiving the DDN, the MME/AMF checks the UE's mobility and subscription context. If the UE is permitted to be paged and is registered in the tracking area, the MME/AMF triggers the network-initiated service request procedure. This involves sending a paging message to all evolved NodeBs (eNBs) or gNBs within the UE's registered tracking area(s) to locate the UE and instruct it to transition to a connected state (ECM-CONNECTED or CM-CONNECTED).

Once the UE responds to the page and performs the random access procedure, the MME/AMF coordinates with the SGW and eNB/gNB to re-activate the suspended user plane bearers or PDU session resources. This includes establishing the S1-U or N3 user plane tunnel between the eNB/gNB and the SGW/UPF. Only after this bearer establishment is complete does the SGW forward the buffered downlink data packets to the eNB/gNB for transmission to the UE. The DDN mechanism is tightly integrated with other core network functions like the Home Subscriber Server (HSS) or Unified Data Management (UDM) for subscription verification and with policy control via the Policy and Charging Rules Function (PCRF) or Policy Control Function (PCF) to ensure QoS policies are applied during bearer reactivation.

In architectural evolution towards 5G, while the fundamental concept remains, the implementation details shift. In 5GC, the SMF (which combines some SGW control plane functions) may trigger a notification towards the AMF, analogous to the DDN, when downlink data arrives at the UPF for an idle UE. The 5GC system uses the N11 interface for this SMF-AMF signaling. Furthermore, enhancements in 5G, such as support for network slicing and more granular power saving modes, influence how and when DDN-like notifications are generated and processed, ensuring they align with the slice characteristics and UE power saving preferences.

Purpose & Motivation

The Downlink Data Notification mechanism was created to solve a fundamental conflict in mobile network design: enabling User Equipment (UE) to conserve battery power by entering idle states with no active radio connection, while simultaneously ensuring the network can deliver downlink data to the UE with minimal delay when such data arrives. Without DDN, a network would either have to keep UEs in a connected state continuously—draining their batteries rapidly—or risk losing downlink data because the network has no way to locate and wake up an idle UE when data is pending for it.

Historically, in pre-3GPP packet-switched systems, similar mechanisms existed but were less optimized. The DDN, as standardized in 3GPP, provides a standardized, efficient, and scalable signaling procedure between the gateway nodes (SGW, SMF) and the mobility management nodes (MME, AMF). It addresses the limitations of earlier approaches by decoupling the data plane detection (at the gateway) from the mobility and paging control (at the MME/AMF), allowing for specialized network functions and optimized signaling flows. This separation is a key tenet of the EPC and 5GC architectures.

The creation and refinement of DDN were motivated by the exponential growth of mobile data traffic and always-on applications (like push email, instant messaging, and IoT sensor commands) that generate sporadic downlink data. DDN ensures these applications work seamlessly without requiring constant UE connectivity. It is a cornerstone for enabling advanced power saving features like Power Saving Mode (PSM) and extended Discontinuous Reception (eDRX), as it provides the guaranteed wake-up mechanism the network needs to reach the UE. In essence, DDN makes the trade-off between UE power efficiency and network reachability manageable and reliable.

Classification

Part ofMME
Related approachesSGW

Detected Changes Across Releases

from 3GPP Change Requests

Specific changes extracted from the „Change history“ tables of 3GPP specifications (7 CRs across 3 releases). Complements the general historical overview above with the evidence-based evolution of this function.

Rel-16 4 changes
  • Notification of Downlink data delivery status and availability after DDN failure notification for multiple Afs TS 29.122CR0156
  • Update of the DDD status event and availability of DDN failure event TS 29.122CR0220
  • DDN Failure and Delivery Policy Control Request triggers TS 29.512CR0489
  • Availability after DDN notification for eDRX TS 23.682CR0443
Rel-17 2 changes
  • PCC control for DDD status and availability after DDN failure events TS 29.512CR0655
  • Correction to PCC control for DDD status and availability after DDN failure events TS 29.512CR0757
Rel-19 1 change
  • Correction on Policy Control for DDN events TS 29.512CR1398

Explore further

Broader topics and technologies where DDN plays a role.

Defining Specifications

3GPP specifications that define or reference DDN, with the latest known release. Sourced from the 3GPP document catalog — see methodology.

SpecificationTitleRelease
TS 23.682 vj30 Architecture for MTC and SCEF Enhancements Rel-19
TS 29.122 vk00 T8 Reference Point Protocol for SCEF and SCS/AS Rel-20
TS 29.512 vk00 Session Management Policy Control Service Rel-20