Understanding HbbTV DSM-CC Data Carousel Signalling in DVB Transport Streams

High-level architecture

A typical HbbTV service combines linear TV delivery with a broadcast application path. The PMT identifies the AIT PID and the DSM-CC carousel PID. The AIT points receivers to the application entry point. The carousel then supplies the actual files that make up the app.

PAT
 └─ PMT
     ├─ AIT PID
     └─ DSM-CC carousel PID
          ├─ DSI
          ├─ DII
          └─ DDB
               └─ BIOP filesystem
                    └─ HbbTV application

PMT signalling

The first step is declaring the DSM-CC Object Carousel in the Programme Map Table. A carousel stream typically appears as a DSM-CC elementary stream with a carousel identifier descriptor so the receiver can associate the PID with a specific carousel instance.

PID 0x0500
stream_type = 0x0B

carousel_identifier_descriptor
{
    carousel_id = 0x00000001
}

The PMT may also signal the Application Information Table on a dedicated PID, using the application signalling descriptor to indicate that the service carries HbbTV application metadata.

Application Information Table

The AIT describes the application, its identifiers, and how it should launch. What it does not carry is the carousel identification itself. The AIT says that an application exists and where its entry path lives; the carousel signalling tells the receiver how the files are transported.

Application
{
    organisation_id = 0x12345678
    application_id  = 0x1001
    control_code    = AUTOSTART

    transport_protocol_descriptor
    {
        protocol_id = OBJECT_CAROUSEL
    }

    application_location_descriptor
    {
        base_directory = "/"
        initial_path   = "index.html"
    }
}

That distinction matters in operations: the AIT advertises the service-facing intent, while the DSM-CC layer carries the filesystem that the receiver must reconstruct.

DSI, DII and DDB

A DSM-CC Object Carousel is built from three message types. The DSI introduces the carousel and identifies the Service Gateway object. The DII describes the modules that can be downloaded. The DDB messages carry the block payload for each module.

• DSI announces the carousel and its root object.
• DII describes modules, sizes, versions, block sizes and module metadata.
• DDB transports the data blocks that reconstruct the modules.

The receiver must collect the messages in that order of dependency, even though they are cyclically repeated in the transport stream.

BIOP object location

The DSI points to a Service Gateway object through a BIOP IOR. Inside that IOR, the BIOP::ObjectLocation says where the object lives in carousel terms: carousel ID, module ID and object key. That is the authoritative location of the gateway object inside the broadcast filesystem.

BIOP::ObjectLocation
{
    carousel_id = 0x00000001
    module_id   = 0x0001
    object_key  = 0x123456...
}

The carousel ID appears in both the PMT and the object location, but it serves different purposes. The PMT tells the receiver which stream carries the carousel; BIOP::ObjectLocation tells it which object inside that carousel should be opened.

ConnBinder and module metadata

A DSM::ConnBinder usually accompanies the object reference and describes how the receiver should access the object. In practice, the association tag is one of the most important values because it links the object reference to the correct DSM-CC transport path.

The DII adds another crucial layer: BIOP::ModuleInfo. Its user_info field is profile-specific and may carry the module-specific data used by the receiver to interpret the downloaded structure, linking the download mechanism with the filesystem the receiver will rebuild.

From modules to a filesystem

Once the receiver has enough DDB blocks to reconstruct the modules, it starts interpreting the BIOP objects. Typical objects include the Service Gateway, directories, files and streams. The result is a virtual filesystem that behaves like local storage from the application's point of view.

/
├── index.html
├── app.js
├── style.css
└── images
    └── logo.png

The receiver resolves the application's initial path from the AIT, then loads the referenced JavaScript, CSS and image files from the reconstructed carousel filesystem.

What makes multiplexing difficult

DSM-CC carousels require much tighter internal consistency than video or audio streams. PMT carousel identifiers must match the actual carousel content. Association tags must point to the right path. DSI must reference a valid Service Gateway. DII module descriptions must match the payload. Module versions and block numbers must stay in sync as files change.

A mismatch anywhere in that chain can leave a service perfectly signalled but impossible for a receiver to load. That is why carousel generation is usually handled by dedicated tooling rather than ad hoc multiplexer logic.

Takeaway

HbbTV application delivery is layered: the PMT identifies the broadcast paths, the AIT advertises the app, DSM-CC carries the files, and BIOP rebuilds the filesystem.