Associated Delivery Procedure Description

Description

The Associated Delivery Procedure Description (ADPD) is a key component within the 3GPP Multimedia Broadcast/Multicast Service (MBMS) architecture, specifically defined for the delivery of File Delivery over Unidirectional Transport (FLUTE) and Dynamic Adaptive Streaming over HTTP (DASH) based services. It functions as a metadata container that describes the delivery method, timing, and relationship of associated content—such as subtitles, closed captions, audio descriptions, application data, or timed metadata—to a primary media presentation. The ADPD is typically carried within a Media Presentation Description (MPD) for DASH-based streaming or within the File Delivery Table (FDT) for FLUTE-based file delivery, providing the client with the necessary instructions to correctly acquire and synchronize the auxiliary data.

Architecturally, the ADPD operates within the application layer of the MBMS bearer service. It is generated by the service provider or Broadcast Multicast Service Center (BM-SC) and delivered to User Equipment (UE) as part of the service announcement or within the ongoing delivery session. The description itself is an XML-based structure that references the associated content's location (e.g., a URL or file identifier) and defines critical delivery parameters. These parameters include the delivery procedure type (e.g., DASH Segment, FLUTE File, or HTTP-URL), optional bandwidth information, and, most importantly, timing information that links the delivery and availability of the associated content to the media presentation timeline of the primary service.

The core technical operation involves the UE parsing the ADPD upon receiving the service description. Based on the procedure type, the client initiates the appropriate protocol stack—such as FLUTE or HTTP—to retrieve the described content objects. For synchronized delivery, the ADPD uses constructs like `availabilityStartTime` and `availabilityEndTime` aligned with the primary media's timeline, ensuring that subtitles or metadata are available precisely when needed for playback. This decouples the delivery of associated content from the real-time streaming of the main media, allowing for efficient carousel-based repetition in broadcast scenarios or on-demand fetching in unicast fallback modes, while maintaining strict synchronization requirements.

Its role in the network is to enable rich, accessible, and interactive broadcast/multicast services without burdening the primary media stream. By providing a standardized, declarative description, it allows diverse client implementations to uniformly handle auxiliary content. This simplifies service creation for providers and guarantees a consistent user experience. The ADPD is a foundational element for enabling services like accessible broadcasting (for users with disabilities), enhanced TV with synchronized applications, and delivery of service guide or emergency alert data in tandem with video and audio streams.

Purpose & Motivation

ADPD was created to address the growing need for delivering synchronized auxiliary content within 3GPP's evolving broadcast and multicast frameworks, primarily MBMS and its evolution into Enhanced Multimedia Broadcast Multicast Service (eMBMS). Prior to its standardization, delivering timed metadata, subtitles, or interactive application data alongside a primary media stream in a broadcast environment was often handled through proprietary or ad-hoc methods. This led to interoperability issues, increased client complexity, and inefficient use of broadcast resources, as the delivery logic for associated content was hard-coded or poorly defined.

The introduction of ADPD in Release 12 provided a standardized, flexible, and declarative solution. It was motivated by the industry's shift towards IP-based media delivery (like DASH) and the requirement for rich media services, including those mandated for accessibility (e.g., closed captions). The core problem it solves is the efficient and synchronized delivery of non-continuous, often bursty, associated data within a continuous broadcast or multicast stream. It allows service providers to describe *how* and *when* this auxiliary content is delivered separately from the main media, enabling clients to retrieve it just-in-time, thus optimizing bandwidth and storage on the UE.

Historically, without ADPD, associated content might be embedded within the media container (increasing complexity and limiting flexibility) or delivered on a separate, unsynchronized channel. ADPD's purpose is to decouple delivery description from the media encoding, providing a network-agile method. This was particularly critical for eMBMS deployments aiming to support mobile TV, public safety communications, and software updates over broadcast, where associated data (like emergency alerts or service metadata) must be reliably and timely delivered in sync with the primary content, regardless of network conditions or client state.