DDN

Downlink Data Notification

Core Network →
Introduced in Rel-13

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.

Category
Core Network
Introduced
Rel-13
Where
Core Network › 5G Core
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

Release Timeline

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

In Release 16, the DDN function was enhanced by introducing the "Availability after DDN failure" as a formal monitoring event, allowing an SCS/AS to subscribe to repeated notifications of UE reachability specifically following a downlink data delivery failure. This enables the network to set a "Notify-on-available-after-DDN-failure" flag upon failure and subsequently alert the SCS/AS when the UE next becomes available, optimizing for infrequent mobile-terminated communication. The release also clarified procedures for combining this event with idle status indications and extended its application to support scenarios involving eDRX.

  • 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

In Release 17, the enhancements for the Downlink Data Notification (DDN) function introduced PCC (Policy and Charging Control) rules specifically for managing the DDD (Downlink Data Delivery) status and UE availability following DDN failure events. This allowed for more refined network-triggered service restoration by enabling the SCS/AS to subscribe to repeated "Availability after DDN failure" monitoring events. The serving node (MME/SGSN) could then set a "Notify-on-available-after-DDN-failure" flag upon a failure, ensuring the application server is notified only when the UE becomes reachable again after such an event.

  • 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

In Release 19, the primary enhancement for the Downlink Data Notification (DDN) function was a correction on the policy control for DDN events. This refinement specifically pertains to the existing "Availability after DDN failure" monitoring event, which allows an application server to be notified when a UE becomes reachable again following a failed downlink data notification, supporting more efficient infrequent mobile-terminated communication.

  • 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 3GPP TS 23682: MTC Architecture Enhancements Rel-19
TS 29.122 vj40 T8 Reference Point for Northbound APIs Rel-19
TS 29.512 vj40 5G Session Management Policy Control Service Rel-19
Patrick Zandl

About the author: Patrick Zandl (b. 1974)

Telecommunications specialist, technology journalist (founder of the Mobil server), and developer who has been running since 2025 — the largest Czech-language resource on AI-assisted programming. Formerly Chief Wizard Architect at Prusa3D and head of development for Turris at CZ.NIC; currently a consultant and instructor on AI implementation in companies.