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

Detected Changes Across Releases

from 3GPP Change Requests

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

Studied in Rel-13, normative work from Rel-15.

Rel-15 11 changes

In Release 15, the DDN function was enhanced with new monitoring events, specifically "UE Reachability" and "Availability after DDN failure," to support efficient high latency communication for UEs in power saving states. This allowed an SCS/AS to request notifications, either one-time or repeated, to be informed when a UE becomes reachable for downlink data delivery. Furthermore, the notification configuration was expanded to include optional parameters like Maximum Latency, Maximum Response Time, and Suggested number of downlink packets for network buffering control.

  • Notification URI Consistency_ChargableParty TS 29.122CR0098
  • Notification URI for GMDviaMBMSbyMB2 API TS 29.122CR0099
  • Notification URI for GMDviaMBMSbyxMB API TS 29.122CR0100
  • Resource usage and Notification URI for NIDD API TS 29.122CR0101
  • Request the successful resource allocation notification TS 29.512CR0009
  • Corrections on the notification URIs defined for the UpdateNotify TS 29.512CR0047

+ 5 more changes

Rel-16 13 changes

In Release 16, the DDN (Downlink Data Notification) function was enhanced with new monitoring event types and notification capabilities. Specifically, it introduced explicit support for the "Availability after DDN failure" event as a trigger for notifications, allowing an SCS/AS to be notified when a UE becomes reachable following a failed downlink data delivery. Additionally, the release expanded notification procedures to include events like the "Number of UEs present in a geographical area" and refined parameters for high-latency communication, such as Maximum Latency and Suggested number of downlink packets, within these event configurations.

  • Notification of Downlink data delivery status and availability after DDN failure notification for multiple Afs TS 29.122CR0156
  • PFD management notification TS 29.122CR0171
  • BDT Warning Notification Support TS 29.122CR0175
  • Removal of a BDT warning notification request TS 29.122CR0189
  • PFD partial failure notification TS 29.122CR0212
  • Update of the DDD status event and availability of DDN failure event TS 29.122CR0220

+ 7 more changes

Rel-17 22 changes

In Release 17, the DDN (Downlink Data Notification) function was enhanced with improved notification control for QoS parameters and refined procedures for PDU session events. Specifically, it introduced support for QoS notification control related to requested alternative QoS parameters and provided corrections for the notification of PDU session establishment and termination events to the PCF. Additionally, updates were made to notification destination management via PATCH operations across several service APIs, including NIDD, AsSessionWithQoS, and ResourceManagementOfBdt.

  • Updates to support notification of GEM partial cancellation TS 29.122CR0439
  • Updates notification destination via PATCH operation in NIDD API TS 29.122CR0444
  • Clarification of direct notification TS 29.122CR0527
  • Duplicated notification TS 29.512CR0806
  • Indication of request of notification PDU session established/terminated events TS 29.512CR0856
  • Notification URI Correction for AsSessionWithQoS API TS 29.122CR0359

+ 16 more changes

Rel-18 8 changes

In Release 18, the DDN (Downlink Data Notification) function was enhanced to support the direct event notification of Time Sensitive Communication (TSC) management information, providing more efficient monitoring for latency-sensitive services. The release also introduced corrections and clarifications to the notification mechanism description and to the User Consent Revocation Notification definition, improving procedural reliability. Furthermore, updates were made to the network slice admission control notification for UEs with an established PDU session or PDN connection.

  • Support of Uplink Downlink transmission coordination to meet RT latency requirement TS 29.122CR0678
  • Network slice admission control notification update for UE with atleast one PDU session/PDN connection TS 29.122CR0732
  • Support of the direct event notification of TSC management information TS 29.512CR1071
  • Support of Uplink Downlink transmission coordination to meet RT latency requirement TS 29.512CR1073
  • Redundant steering mode Resource allocation notification to PCF TS 29.512CR1194
  • Corrections to the User Consent Revocation Notification definition TS 29.122CR0754

+ 2 more changes

Rel-19 5 changes

In Release 19, the Downlink Data Notification (DDN) function was enhanced to support reporting the QoS notification event with explicit direction information (UL and DL). Furthermore, corrections were made to the Policy Control procedures for DDN events and to the BAT offset notification mechanism.

  • Support of reporting the QoS notification event with direction information TS 29.122CR0969
  • QoS notification control in UL and DL direction information TS 29.512CR1376
  • Support of reporting the QoS notification event with direction information TS 29.512CR1416
  • Correction on Policy Control for DDN events TS 29.512CR1398
  • Correction to BAT offset notification TS 29.512CR1273

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