It’s not enough to simply broadcast DSM-CC carousels or streams as part of your service – a receiver needs to know what that data is, and how it can find it. To this end, DSM-CC has defined a number of additions to service information that are used to describe the data that is being broadcast.
A note regarding standards versions: If you are studying this in a DVB or in an MHP/OCAP context, please not that some of the service information relating to data broadcasting – specifically, that related to IP data encapsulated in DSM-CC – was changed a recent version of the DVB data broadcasting specification. This changed between MHP 1.0.2 and MHP 1.0.3, and so MHP 1.0.3 refers to the newer version of the specification.
The current OCAP specification refers to version 1.0.2 of the MHP standard, and so OCAP receivers must follow the old version of the data broadcasting specification for now. Given the scope of the changes between the old and new versions of the data broadcasting standards, this is not a big problem.
Descriptors and other parts of service information referring to the transport of IP over DSM-CC are described in the section of this tutorial covering multi-protocol encapsulation.
DSM-CC streams and the PMT
Just like any other stream in a service, DSM-CC streams must be listed in the PMT. For streams containing object or data carousels, the stream type must be set to 0x0B. Other DSM-CC streams have different stream types. Multi-protocol encapsulation streams can have a stream type of 0x0A, for instance, while DSM-CC descriptors such as those used for NPT have a stream type of 0x0C.
DSM-CC streams can also use the stream type 0x0D. This is not limited to a particular type of DSM-CC data, and so streams of this type can carry object carousels, data carousels, descriptors or any other type of DSM-CC data, including private sections. A receiver therefore needs to check streams with a type of 0x0D to see what kind of DSM-CC data they contain.
Descriptors defined by MPEG
The DSM-CC specification defines several descriptors that are used by the receiver and the DSM-CC implementation to resolve references within DSM-CC and to make it easier for the receiver to associate an object carousel with a particular service.
The carousel identifier descriptor
The carousel identifier descriptor is carried in the PMT for the service containing the object carousel, and helps the receiver to associate a particular carousel with that service.
| Syntax | Bits | Type | Value | Comment |
|---|---|---|---|---|
| carousel_identifier_descriptor () { | ||||
| descriptor_tag | 8 | uimsbf | 0x13 | |
| descriptor_length | 8 | uimsbf | ||
| carousel_id | 32 | uimsbf | ||
| formatId | 8 | uimsbf | Registered Identifier of the FormatSpecifier | |
| FormatSpecifier () { | ||||
| FormatSpecifier_byte | 8 | uimsbf | See TR 101 202 v1.2.1, table 4.17a N2 bytes |
|
| } | ||||
| for (i = 0; i < N; i++) { | ||||
| private_data_byte | 8 bits | uimsbf | ||
| } | ||||
| } |
In DVB and OCAP systems, the formatSpecifier field will have the following structure, depending on the value of the formatId field:
| FormatId value | Format Specifier definition | length (bits) | Comment |
|---|---|---|---|
| 0x00 | no FormatSpecifier | A value of 0x00 indicates the absence of a FormatSpecifier. Thus the location of the ServiceGateway is only possible through the "standard" way interpreting the DSI and DII messages. |
|
| 0x01 | FormatSpecifier () { |
This FormatSpecifier is an aggregation of the fields NOTE: All field types are "uimsbf". |
|
| ModuleVersion | 8 | ||
| ModuleId | 16 | ||
| BlockSize | 16 | ||
| ModuleSize | 32 | ||
| CompressionMethod | 8 | ||
| OriginalSize | 32 | ||
| TimeOut | 8 | Timeout in seconds | |
| ObjectKeyLength | 8 | ||
| for(i = 0; j < N1; i++) { | |||
| ObjectKeyData | 8 | Object key of the service gateway object. | |
| } | |||
| } | |||
| 0x02…0x7F | Reserved for future use | The format Id values from 0x02 to 0x7F are reserved for future use of DVB. | |
| 0x80…0xFF | Reserved for private use | The format Id values from 0x80 to 0xFF are reserved for private use. |
The object key must be less than 4 bytes long for DVB and OCAP systems.
The association tag descriptor
As you will know if you have read the object carousel tutorial, association tags are used by DSM-CC to identify streams in a way that is not DVB-specific (like component tags) or which may change during re-multiplexing (like PIDs can). An association tag is linked to a stream by including an association tag descriptor in the descriptor loop of the stream’s PMT entry.
The association tag descriptor has the following format:
| Syntax | Bits | Type | Value | Comment |
|---|---|---|---|---|
| association_tag_descriptor () { | ||||
| descriptor_tag | 8 | uimsbf | 0x14 | |
| descriptor_length | 8 | uimsbf | + | |
| association_tag | 16 | uimsbf | + | |
| use | 16 | uimsbf | 0x0000 | DSI with IOR of SGW |
| 0x0100 – 0x1FFF | DVB reserved | |||
| 0x2000 – 0xFFFF | user private | |||
| if (use == 0x0000) { | ||||
| selector_length | 8 | uimsbf | 0x08 | |
| transaction_id | 32 | uimsbf | + | transaction_id of DSI |
| timeout | 32 | uimsbf | + | timeout for DSI |
| } else if (use == 0x0001) { | ||||
| selector_length | 8 | uimsbf | 0x00 | |
| } else { | ||||
| selector_length | 8 | uimsbf | N1 | |
| for (i = 0; i < N1; i++) { | ||||
| selector _byte | 8 | uimsbf | ||
| } | ||||
| } | ||||
| for (i = 0; i < N2; i++) { | ||||
| private_data_byte | 8 | uimsbf | private data | |
| } | ||||
| } |
If the use field contains the value 0x00 then the selector contains the transaction ID of the DSI message for the carousel. A value of 0x01 indicates that the stream is carrying object carousel data (which may include a service gateway message). Values in the range 0x0100 to 0x1FFF are reserved by DVB, while ISO got there first and reserved the values 0x02 to 0xFF. By default, the value of the use field will be 0x100, which means that the selector may contain the transaction ID of the DSI message for the carousel, but does not have to do so.
As you may have noticed, the length of the private data field is not explicitly specified. In this case, the length of the private data is determined by the descriptor length: subtract the size of all other fields from the size of the descriptor and you have the size of your private data.
The deferred association tags descriptor
An object carousel can use (or refer to) elementary streams that are not part of the current service or transport stream. In this case, receivers may have problems mapping an association tag that refers to that stream to the stream itself. The deferred association tags descriptor defines which association tags are referred to by a given object carousel, and tells the receiver where they are. This allows the receiver to access those streams much more efficiently.
Each descriptor can contain a mapping for more than one association tag, although each of the association tags in the same deferred association tags descriptor must be present in the same MPEG-2 program. To get round the problem of association tags that refer to elementary streams in different programs, a PMT can contain more than one deferred association tags descriptor.
The descriptor has the following structure:
| Syntax | Bits | Type | Value | Comment |
|---|---|---|---|---|
| deferred_association_tags_descriptor () { | ||||
| descriptor_tag | 8 | uimsbf | 0x15 | |
| descriptor_length | 8 | uimsbf | + | |
| association_tags_loop_length | 8 | uimsbf | 2*N1 | length in bytes |
| for (i = 0; i < N1; i++) { | ||||
| association tag | 16 | uimsbf | + | |
| } | ||||
| transport_stream_id | 16 bits | uimsbf | + | |
| program_number | 16 bits | uimsbf | + | |
| org_network_id | 16 | + | ||
| for (j = 0; j < M; j++) { | ||||
| private data | 8 bits | uimsbf | + | |
| } | ||||
| } |
Descriptors defined by DVB
As well as the standard descriptors that are defined as part of the MPEG specification for DSM-CC, DVB has also defined a number of descriptors that are used with DSM-CC data carousels.
Some of these desriptors are carried in the SDT or EIT of the service or event that the carousel is associated with. Others are lower-level deswcriptors, and are carried in the ModuleInfo and GroupInfo structures that are part of DII and DSI messages. Some of these descriptors re-use descriptor tags that are used by other MPEG descriptors, however, so they must not be used outside of a DVB or OCAP system. If they are, a receiver could get VERY confused.
The data broadcast descriptor
The data broadcast descriptor is a means of describing the format and type of data that is encoded in an elementary stream that doesn’t contain audio, video or SI data. As well as describing the type of stream, the data broadcast descriptor lets the broadcaster assign a textual description to it.
This descriptor can be carried in the SDT (in the descriptor loop for a particular service entry) or in the EIT (in the descriptor loop for a given event entry). Since it relies on optional tables (and on tables which are not present in ATSC service information), the data broadcast ID descriptor is often used in its place.
While this descriptor is defined in EN 300 468 (the DVB SI specification), some more detail that is specific to DSM-CC streams is added in EN 301 192.
| Syntax | No. of bits | Mnemonic |
|---|---|---|
| data_broadcast_descriptor () { | ||
| descriptor_tag | 8 | uimsbf |
| descriptor_length | 8 | uimsbf |
| data_broadcast_id | 16 | uimsbf |
| component_tag | 8 | uimsbf |
| selector_length | 8 | uimsbf |
| for (i = 0; i < selector_length; i++) { | ||
| selector_byte | 8 | uimsbf |
| } | ||
| ISO639-2[3]_language_code | 24 | bslbf |
| text_length | 8 | uimsbf |
| for (j = 0; j < text_length; j++) { | ||
| text_char | 8 | uimsbf |
| } | ||
| } |
For a data broadcast descriptor that refers to a DSM-CC data carousel, the data broadcast ID must have the value 0x0006. In this case, the rest of the descriptor is taken up by the following structure:
| Syntax | No. of bits | Mnemonic |
|---|---|---|
| data_carousel_info () { | ||
| carousel_type_id | 2 bits | bslbf |
| reserved | 6 bits | bslbf |
| transaction_id | 32 bits | uimsbf |
| time_out_value_DSI | 32 bits | uimsbf |
| time_out_value_DII | 32 bits | uimsbf |
| reserved | 2 bits | bslbf |
| leak_rate | 22 bits | bslbf |
| } |
The carousel ID gives a description of the carousel so that the receiver knows what type of message to look for. a value of 0x01 means that the descriptor is describing a one-layer carousel, while a value of 0x02 means it’s describing a two layer carousel (and the receiver should therefore look for a DSI message for that carousel).
For object carousels, the data broadcast ID must have the value 0x0007. In this case, the descriptor contains an object_carousel_info structure:
| Syntax | No. of bits | Mnemonic |
|---|---|---|
| object_carousel_info () { | ||
| carousel_type_id | 2 | bslbf |
| reserved | 6 | bslbf |
| transaction_id | 32 | uimsbf |
| time_out_value_DSI | 32 | uimsbf |
| time_out_value_DII | 32 | uimsbf |
| reserved | 2 | bslbf |
| leak_rate | 22 | bslbf |
| for (i = 0; i < N; i++) { | ||
| ISO639-2[3]_language_code | 24 | bslbf |
| object_name_length | 8 | uimsbf |
| for (j = 0; j < object_name_length; j++) { | ||
| object_name_char | 8 | uimsbf |
| } | ||
| } | ||
| } |
The data broadcast ID descriptor
The data broadcast ID descriptor is a shorter version of the data broadcast descriptor that doesn’t include a textual description of the stream. Unlike the data broadcast descriptor, this descriptor is carried in the descriptor loop of the stream’s entry in the PMT. For this reason, it’s slightly more widely used that the data broadcast descriptor.
| Syntax | No. of bits | Mnemonic |
|---|---|---|
| data broadcast ID descriptor () { | ||
| descriptor_tag | 8 | uimsbf |
| descriptor_length | 8 | uimsbf |
| data_broadcast_id | 16 | uimsbf |
| for(i = 0; i < N; i++) { | ||
| id_selector _byte | 8 | uimsbf |
| } |
MHP (and therefore also OCAP) can use a slightly different version of this descriptor. Additional data broadcast ID values have been defined for MHP object carousels (0xF0) and MHP-specific multi-protocol encapsulation streams (0xF1). For either of these data broadcast ID values, the selector will be 16 bits long and will identify the types of any MHP or OCAP applications that are signalled as auto-start (Java or HTML applications). This is designed to give receivers more information so that they can choose which data streams to connect to first.
The name descriptor
This descriptor allows the broadcaster to seta human-readable name for a module or group of modules. In cases where there are complex data carousels, this lets the broadcaster ‘annotate’ the carousel so that the receiver can use this information to provide some more friendly information to the user. While the users may not care (do you care what a module is called?), it may sometimes be useful.
Since this descriptor can be used to name modules or groups of modules, it can be carried in either the DII ModuleInfo structure or the DSI GroupInfo structure within the data carousel that is carrying the object carousel.
| Syntax | No. of bytes | Value |
|---|---|---|
| name_descriptor () { | ||
| descriptor_tag | 1 | 0x02 |
| descriptor_length | 1 | |
| for (i = 0; i < N; i++) { | ||
| text_char | 1 | Name of the module, e.g. "index" |
| } | ||
| } |
The type descriptor
This descriptor identifies the MIME type of data contained in a specific module or group. This may be carried either in the DII ModuleInfo structure or in the DSI GroupInfo structure.
| Syntax | No. of bytes | Value |
|---|---|---|
| type_descriptor () { | ||
| descriptor_tag | 1 | 0x01 |
| descriptor_length | 1 | |
| for (i = 0; i < N; i++) { | ||
| type | 1 | Text string, e,g, "text/plain" |
| } | ||
| } |
The compressed module descriptor
Data carousel modules may be compressed to save space in the transport stream. This descriptor indicates that the module has been compressed using the ‘zlib’ compression scheme. Since this descriptor only referrs to modules, it can only be carried in the DII ModuleInfo.
| Syntax | No. of bytes | Value |
|---|---|---|
| compressed_module_descriptor () { | ||
| descriptor_tag | 1 | 0x09 |
| descriptor_length | 1 | |
| compression_method | 1 | |
| original_size | 4 | |
| } |
The estimated download time descriptor
This descriptor gives the receiver some indication of how long it will take to download the module or group. This is useful for several reasons. First of all, the receiver can tell the user how long they will have to wait before the data they want is loaded. Second, a clever application can use this information to know how far in advance it should begin pre-fetching a module. This allows it to have the data that it needs before it actually has to have it. Given the latency involved n getting data from a data carousel, this can be extremely useful.
Like the type descriptor and the name descriptor, the estimated download time may be carried either in the DII ModuleInfo structure or in the DSI GroupInfo structure.
| Syntax | No. of bytes | Value |
|---|---|---|
| estimated_download_time_descriptor () { |
||
| descriptor_tag | 1 | 0x07 |
| descriptor_length | 1 | |
| est_download_time | 4 | |
| } |