DDD

Downlink Data Delivery

Core Network →
Introduced in Rel-16

DDD is a 3GPP mechanism for efficiently delivering downlink data to User Equipment in power-saving states like RRC_INACTIVE or RRC_IDLE, optimizing resource usage by reducing signaling overhead and latency.

Category
Core Network
Introduced
Rel-16
Where
Core Network › 5G Core
Specifications
2 specs
DDD Description Purpose Detected Changes Specifications

Description

Downlink Data Delivery (DDD) is a sophisticated mechanism defined within the 5G Core Network (5GC) architecture, specifically within the Session Management Function (SMF) and User Plane Function (UPF) contexts. Its primary function is to manage the efficient delivery of downlink data packets to a UE that is not in an active Radio Resource Control (RRC) connected state (i.e., RRC_CONNECTED). When a UE transitions to RRC_INACTIVE or RRC_IDLE to conserve battery power, the Access and Mobility Management Function (AMF) and the SMF coordinate to maintain the UE's protocol data unit (PDU) session context. The UPF buffers incoming downlink data packets destined for the inactive UE. The DDD procedure is then triggered, which involves the network initiating a network-triggered service request to page the UE and re-establish the user plane path.

The architecture involves close interaction between the SMF, AMF, UPF, and the Radio Access Network (RAN). The SMF, as the central controller for PDU sessions, is responsible for determining DDD policies and instructing the UPF. The UPF acts as the anchor point, detecting downlink data arrival for a suspended PDU session and buffering the packets. It then notifies the SMF via an N4 session report. Upon receiving this notification, the SMF evaluates whether to trigger a DDD procedure. If triggered, the SMF sends a Namf_Communication_N1N2MessageTransfer request to the AMF, which includes the necessary NAS signaling to be forwarded to the UE and instructions for the RAN. The AMF then initiates paging to locate the UE and re-establish the RRC connection.

The procedure works by leveraging the UE's registration area and paging capabilities. Once the UE responds to the page, the RAN establishes an RRC connection and forwards the NAS message from the SMF. This message prompts the UE to initiate a service request procedure. Subsequently, the user plane path between the UPF and the RAN is re-activated, and the buffered downlink data is delivered to the UE. Key components include the buffering capability in the UPF, the event reporting mechanism on the N4 interface, and the service request procedure coordination between the SMF and AMF via the N11/Namf interface.

DDD's role in the network is pivotal for balancing UE power consumption with network reachability. It minimizes the need for UEs to periodically wake up and poll for data, thereby extending battery life for IoT and mobile devices. By buffering data at the UPF and triggering connection re-establishment only when data is available, it reduces unnecessary signaling over the radio interface and in the core network. This makes the network more scalable and efficient, particularly for massive Machine-Type Communication (mMTC) scenarios defined in 5G.

Purpose & Motivation

DDD was created to address the critical challenge of delivering downlink data to UEs that are in low-power states without compromising battery life. In previous cellular generations, a UE in idle mode had to periodically listen for paging messages or transition to connected state to check for data, which consumed significant energy. For IoT applications with infrequent downlink commands or updates, this was highly inefficient. DDD solves this by allowing the network to hold data and intelligently wake up the UE only when there is actual data to deliver, thereby solving the problem of downlink reachability for power-constrained devices.

The motivation stems from the 5G requirement to support massive IoT with ultra-low power consumption. Traditional approaches required either keeping the UE in a connected state (high power drain) or relying on long discontinuous reception (DRX) cycles in idle mode (causing high downlink latency). DDD provides an optimized middle ground. It was introduced as part of the 5G system's native support for RRC_INACTIVE state, which offers a quick connection resumption with stored context. DDD leverages this state to minimize signaling and delay compared to a full idle-to-active transition, addressing the limitations of earlier systems where downlink data arrival often triggered a lengthy service establishment procedure.

Historically, in 4G EPS, a similar concept existed called Downlink Data Notification (DDN) from the Serving Gateway (SGW) to the MME. However, DDD in 5G is more integrated and optimized. It is designed for the 5GC's service-based architecture, with clearer separation of control and user plane functions. It works seamlessly with the RRC_INACTIVE state introduced in 5G NR, which was not available in LTE. This allows for faster state transitions and more efficient resource usage, fulfilling the 5G goals of network efficiency and support for diverse service requirements.

Detected Changes Across Releases

from 3GPP Change Requests

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

Rel-16 8 changes

In Release 16, the Downlink Data Delivery (DDD) status event was formally introduced, enabling the SMF to determine and report whether downlink data for a PDU session was "BUFFERED", "DISCARDED", or "TRANSMITTED". This included support for the event on both the V-SMF and I-SMF, and defined specific procedures for the SMF to detect status changes based on reports from the UPF or its own buffering decisions. The release also specified the inclusion of associated data like traffic descriptors and a maximum wait time for buffered data in the event notification.

  • Downlink data delivery status event TS 29.508CR0039
  • Notification of downlink data delivery status TS 29.508CR0050
  • Update of the DDD status event TS 29.508CR0066
  • DDN Failure and Delivery Policy Control Request triggers TS 29.512CR0489
  • DDD status for I-SMF TS 29.508CR0072
  • Correction to the DDD status event TS 29.508CR0075

+ 2 more changes

Rel-17 5 changes

In Release 17, the enhancements to the Downlink Data Delivery (DDD) status function focused on corrections and refinements to its operational logic. Specifically, the release addressed the accurate determination of DDD status when the SMF buffers data, along with corrections to the event detection and subscription procedures for this status. Furthermore, it introduced and subsequently corrected the Policy and Charging Control (PCC) rules for managing DDD status and availability following Downlink Data Notification (DDN) failure events.

  • Correction to ddd status when the SMF buffers the data TS 29.508CR0107
  • Correction to DDD status event detection TS 29.508CR0121
  • Correction to DDD status event subscription TS 29.508CR0123
  • 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-18 4 changes

In Release 18, the key update for the Downlink Data Delivery (DDD) function was the correction of the official event name for downlink data delivery status to ensure consistency. This release also included corrections related to the delivery of multi-modal service and L4S (Low Latency, Low Loss, Scalable Throughput) to refine the reporting mechanisms. Furthermore, the specifications were enhanced to detail the procedures for the SMF to determine the subscribed event status—such as "BUFFERED," "DISCARDED," or "TRANSMITTED"—based on data handling by the UPF or SMF itself.

  • Support of Uplink Downlink transmission coordination to meet RT latency requirement TS 29.512CR1073
  • Support of failure report for UE Policy Container delivery via EPS TS 29.512CR1222
  • Correct the event name for downlink data delivery status TS 29.508CR0197
  • Corrections on delivery of multi-modal service and L4S TS 29.512CR1251

Explore further

Broader topics and technologies where DDD plays a role.

Defining Specifications

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

SpecificationTitleRelease
TS 29.508 vj40 5G Session Management Event Exposure Service Rel-19
TS 29.512 vj40 5G Session Management Policy Control Service Rel-19