Signalling MHP Applications

Before the application manager in the receiver can actually run an application, several things have to happen. First of all, the receiver has to know that an application actually exists. Second, it has to know that the user is allowed to run it at the current time. Finally, it has to be able to access everything that it actually needs to run the application, such as class files and data files or assets.

The first and second parts, and some of the third part, are handled by the same mechanism. MHP defines an extra service information table called the Application Information Table (AIT). This table is broadcast for every service that contains an MHP application, and it contains an entry for every MHP application that's valid for that service. Thus, if a service has two applications associated with it, this table will contain two entries.

The AIT contains all the information that the receiver will need to run the application and to tell the user what applications are available in a meaningful way. This includes elements such as the name of the application, the location of its files and any arguments that should be passed to the application when it starts.

Each application that is broadcast is given a unique identifier, which is also stored in the AIT. This identifier allows other parts of the system to actually be able to refer to an application uniquely, since the name or other attributes may not be unique. Each identifier consists of two parts - a 32 bit organization ID, which is unique to every organization that produces MHP applications, and a 16 bit application ID. This application ID does not have to be unique, but no two applications signalled in the same AIT can have the same organization ID and application ID. Given the size of the ID range, it's good practice not to re-use application ID's where possible.

Applications may be started or stopped automatically by the receiver, based on a control code signalled in the AIT. This control code shows whether the application should be started automatically when the service is selected, whether the application should be killed automatically by the receiver if it is running, or whether the user can start it by hand. This allows a broadcaster to specify that applications which are time-critical can only be run in a given time period, and that if a user selects that service within that time period then they will always see that application.

The diagram below shows the structure of the AIT:

Format of the application information table. Source: TS 101 812 v1.3.1 (MHP 1.0.3 specification).
Syntax No. of bits Identifier
application_information_section () {
table_id 8 uimsbf
section_syntax_indicator 1 bslbf
reserved_future_use 1 bslbf
reserved 2 bslbf
section_length 12 uimsbf
test_application_flag 1 bslbf
application_type 15 uimsbf
reserved 2 bslbf
version_number 5 uimsbf
current_next_indicator 1 bslbf
section_number 8 uimsbf
last_section_number 8 uimsbf
reserved_future_use 4 bslbf
common_descriptors_length 12 uimsbf
for (i = 0; i < N; i++) {
descriptor()
}
reserved_future_use 4 bslbf
application_loop_length 12 uimsbf
for (i = 0; i < N; i++) {
application_identifier()
application_control_code 8 uimsbf
reserved_future_use 4 bslbf
application_descriptors_loop_length 12 uimsbf
for (j = 0; j < N; j++) {
descriptor()
}
}
CRC_32 32 rpchof
}

The AIT is split into a number of sub-tables, each containing applications of only one type. At the moment, only two types of application are supported - DVB-J applications and DVB-HTML applications. The type of applications described by a particular AIT sub-table is given y the application_type field.

Identifying an application

The application_identifer structure consists of a 32-bit organization ID that identifies the company responsible for the application (either the developer or the content provider) and a 16-bit application ID. This application ID need not be unique within the company that produced the application, but it must be unique within the scope of the current service. Keeping it unique on a wider scope makes it easier for the content provider to avoid problems, and so this is generally recommended.

The application ID is split in to several ranges in order to make life easier for the receiver. Application IDs between 1 and 0x3FFF may only be used by applications that have not been digitally signed by the broadcaster. Applications which have been signed will use an application ID between 0x4000 and 0x7FFF.

Application IDs 0xFFFF and 0xFFFE are wildcards that are used to identify all applications with the same organisation ID (0xFFFF) and all all signed applications with the same organisation ID (0xFFFE). These can not be used in the application_identifier structure in the application loop of the AIT but they can be used in some descriptors within the AIT.

All other application ID values have been reserved by DVB and should not be used by applications that are being broadcast today.

Describing an application

The AIT contains two descriptor loops that describe the applications within the AIT. The common descriptor loop contains descriptors that apply to all applications within the AIT, while the application descriptor loop will contain descriptors that apply to a particular application.

Descriptors and their location in the AIT.
Descriptor Mandatory Location
application descriptor mandatory application descriptor loop
application name descriptor mandatory application descriptor loop
application icons descriptor optional application descriptor loop
DVB-J application descriptor mandatory for DVB_J application application descriptor loop
DVB-J application location descriptor mandatory for DVB_J application application descriptor loop
DVB-HTML application descriptor mandatory for DVB_HTML application application descriptor loop
DVB-HTML application location descriptor mandatory for DVB_HTML application application descriptor loop
DVB-HTML application boundary descriptor mandatory for DVB_HTML application application descriptor loop
external application authorization descriptor optional common descriptor loop
IP routing descriptor optional, multiple instances allowed common descriptor loop
transport protocol descriptor optional common descriptor loop or application descriptor loop
pre-fetch descriptor optional application descriptor loop
DII location descriptor optional ommon descriptor loop or application descriptor loop

An entry for an application will contain the following descriptors as a minimum:

  • an application descriptor. This contains the basic description of the application and its state.
  • an application name descriptor. This gives the name of the application that is shown to the user.
  • EITHER a DVB-J application descriptor OR a DVB-HTML application descriptor. These describe those elements that are specific to DVB-J or DVB-HTML applications respectively.
  • EITHER a DVB-J application location descriptor OR a DVB-HTML application location descriptor. These tell the receiver where to find the files associated with the application
  • a DVB-HTML application boundary descriptor, if the application is a DVB-HTML application

An entry for an application may also include a transport protocol descriptor. This gives the receiver more specific information about how to load the files needed by an application. The application location descriptors give a high-level view of this, telling the receiver where in the filesystem to find the files. In the case of a DVB-J application location descriptor will include the name of the main class, the classpath that should be used and the base directory of the application.

The transport protocol descriptor contains lower-level information that tells the receiver where this filesystem is located: how to access the object carousel that contains it, or the remote server on which it should search for the files. We will look at this descriptor and the information it contains in more detail in the next tutorial, which covers application loading. For now it's enough to say that transport protocol descriptors may be placed either in the common descriptor loop (where they will apply to every entry in the AIT) or in the application descriptor loop (where they will only apply to that application, and will override any transport protocol descriptors found in the common descriptor loop). Every application must be within the scope of at least one transport protocol descriptor.

Each of the descriptors in the AIT are described in detail below.

A detailed look at AIT descriptors.

Now that we've seen the basic structure of the AIT and seen the descriptors that w will find there, let's take a more detailed look at the format of those descriptors.

The application descriptor

The application descriptor gives a description of the basic information that the receiver needs to know about the application. This includes the version and profile of MHP that is needed to run the application, the priority of the application and other similar information. The application descriptor will be broadcast in the appears in the application loop of each AIT entry. Each application will have exactly one application descriptor.

Format of the application descriptor. Source: TS 101 812 v1.3.1 (MHP 1.0.3 specification).
No. of Bits Identifier Value
application_descriptor() {
descriptor_tag 8 uimsbf
descriptor_length 8 uimsbf
application_profiles_length 8 uimsbf
for (i = 0; i < N, i++) {
application_profile 16 uimsbf
version.major 8 uimsbf
version.minor 8 uimsbf
version.micro 8 uimsbf
}
service_bound_flag 1 bslbf
visibility 2 bslbf
reserved_future_use 5 bslbf
application_priority 8 uimsbf
for (i = 0; i < N; i++) {
transport_protocol_label 8 uimsbf
}
}

The visibility field tells the receiver whether the application is visible to users (i.e. whether it appears in the list of startable applications), to applications (i.e. it can be controlled via the application listing and launching API) or both.

The service_bound_flag field is used ot identify those applications that are bound to a particular service and which will always be killed when the user switches to a new service. This takes place before the receiver has switched to the new service, and so even if the application is signalled on the new service, any applications marked as service bound will be killed.

The transport_protocol_label field is a reference to the transport protocol descriptor that is applicable for this application.

The application name descriptor

The application name descriptor contains the name of the application in one or more languages. Like the application descriptor, this will appear exactly once in the application descriptor loop of each AIT entry.

Format of the application name descriptor. Source: TS 101 812 v1.3.1 (MHP 1.0.3 specification).
No. of Bits Identifier Value
application_name_descriptor {
descriptor_tag 8 uimsbf
descriptor_length 8 uimsbf
for (i = 0; i < N; i++) {
ISO_639_language_code 24 bslbf
application_name_length 8 uimsbf
for (i = 0; i < N; i++) {
application_name_char 8 uimsbf
}
}
}

The application icons descriptor

The application icons descriptor is an optional descriptor that may appear in the application loop of an AIT entry. This descriptor contains an image that may be used by the receiver as an icon for that application.
Not every receiver will use this information, depending on how they display the list of available applications.

There will be either zero or one instance of this descriptor present for any application.

Format of the application icons descriptor. Source: TS 101 812 v1.3.1 (MHP 1.0.3 specification).
No. of Bits Identifier Value
application_icons_descriptor() {
descriptor_tag 8 uimsbf
descriptor_length 8 uimsbf
icon_locator_length 8 uimsbf
for (i = 0; i < N; i++) {
icon_locator_byte 8 uimsbf
}
icon_flags 16 bslbf
for (i = 0; i < N; i++) {
reserved_future_use 8 bslbf
}
}

Descriptors specific to DVB-J applications

DVB-J applications will have the following two descriptors in the application loop of their AIT entry. The first is the DVB-J application descriptor. This tells the receiver about the parameters that should be passed to the DVB-J application when it starts.

Format of the DVB-J application descriptor. Source: TS 101 812 v1.3.1 (MHP 1.0.3 specification).
No. of Bits Identifier Value
dvb_j_application_descriptor() {
descriptor_tag 8 uimsbf
descriptor_length 8 uimsbf
for (i = 0; i < N; i++) { 8
parameter_length uimsbf
for (j = 0; j < parameter_length; j++) { 8
parameter bytes 8 uimsbf
}
}
}

The second descriptor is the DVB-J application location descriptor.
This tells the receiver the base directory for the application, the main class for the application and the classpath that should be searched for application classes.

Format of the DVB-J application location descriptor. Source: TS 101 812 v1.3.1 (MHP 1.0.3 specification).
No. of Bits Identifier Value
dvb_j_application_location_descriptor {
descriptor_tag 8 bits uimsbf
descriptor_length 8 bits uimsbf
base_directory_length 8 bits uimsbf
for (i = 0; i < base_directory_length; i++) {
base_directory_byte 8 uimsbf
}
classpath_extension_length 8 uimsbf
for (i = 0; i < classpath_extension_length; i++) {
classpath_extension_byte 8 uimsbf
}
for (i = 0; i < N; i++) {
initial_class_byte 8 uimsbf
}
}

Descriptors specific to DVB-HTML applications.

As for DVB-J applications, each AIT entry for a DVB-HTML application will also some descriptors that are specific to that type of application.
For DVB-HTML applications, there are three such descriptors. The first of these is the DVB-HTML application descriptor.

Format of the DVB-HTML application descriptor. Source: TS 101 812 v1.3.1 (MHP 1.0.3 specification).
No. of Bits Identifier Value
dvb_html_application_descriptor {
descriptor_tag 8 bits uimsbf
descriptor_length 8 bits uimsbf
appid_set_length 8 bits uimsbf N1
for (i = 0; i < N1; i++) {
application_id 16 bslbf
}
for (i = 0; i < N; i++) {
parameter_byte 8 uimsbf
}
}

The second descriptor is the DVB-HTML application location descriptor.
Like the corresponding descriptor for DVB-J applications, it tells the receiver where it can find the initial HTML page for the application.

Format of the DVB-HTML application location descriptor. Source: TS 101 812 v1.3.1 (MHP 1.0.3 specification).
No. of Bits Identifier Value
dvb_html_application_location_descriptor() {
descriptor_tag 8 uimsbf
descriptor_length 8 uimsbf
physical_root_length 8 uimsbf N1
for (i = 0; i < N1; i++) {
physical_root_byte 8 uimsbf
}
for (i = 0; i < N; i++) {
initial_path_bytes 8 uimsbf
}
}

The third descriptor is the DVB-HTML application boundary descriptor.
This defines the set of pages that makes up the application.

Format of the DVB-HTML application boundary descriptor. Source: TS 101 812 v1.3.1 (MHP 1.0.3 specification).
No. of Bits Identifier Value
dvb_html_application_boundary_descriptor() {
descriptor_tag 8 bits
descriptor_length 8 bits
label_length 8 bits N1
for (i = 0; i < N1; i++) {
label_bytes 8 uimsbf
}
for (i = 0; i < N; i++) {
regular_expression_bytes 8 uimsbf
}
}

The external application authorization descriptor

An external application authorization descriptor may appear in the common descriptor loop of the AIT. This is an optional descriptor that tells the receiver about an application that may not be started, but if instances of it are already running then they will not be killed when the user changes to this service.

Format of the external application authorization descriptor. Source: TS 101 812 v1.3.1 (MHP 1.0.3 specification).
No. of Bits Identifier Value
external_application_authorization_descriptor() {
descriptor_tag 8 uimsbf
descriptor_length 8 uimsbf
for (i = 0; i < N; i++) {
application_identifier()
application_priority 8 uimsbf
}
}

The transport protocol descriptor

As with the external application authorization descriptor, the transport protocol descriptor is an optional descriptor. It may appear in the common descriptor loop, in which case it applies to all applications, or in the inner (application) loop. In the latter case, it only applies to that application, overriding any descriptor in the common descriptor loop.

Format of the transport protocol descriptor. Source: TS 101 812 v1.3.1 (MHP 1.0.3 specification).
No. of Bits Identifier Value
transport_protocol_descriptor() {
descriptor_tag 8 uimsbf
descriptor_length 8 uimsbf
protocol_id 16 uimsbf
transport_protocol_label 8 uimsbf
for (i = 0; i < N; i++) {
selector_byte 8 uimsbf N1
}
}

The selector bytes tell the receiver how to access the files that make up the application. The exact syntax of these depends on the transport protocol, given by the protocol_id field. More information about the transport protocol descriptor, the syntax of the selector bytes and the role of this descriptor in loading applications can be found in the tutorial on application loading.

The pre-fetch descriptor

The pre-fetch descriptor is an optional descriptor that may appear in the application loop of the AIT. This provides hints to the receiver about which parts of an application should be pre-fetched in order to reduce loading times, for applications loaded from a DSM-CC object carousel. Receivers may or may not follow these hints, depending on their caching strategy.

Format of the pre-fetch descriptor. Source: TS 101 812 v1.3.1 (MHP 1.0.3 specification).
No. of bits Mnemonic
prefetch_descriptor() {
descriptor_tag 8 uimsbf
descriptor_length 8 uimsbf
transport_protocol_label 8 uimsbf
for (i = 0; i < N; i++) {
label_length 8 uimsbf
for (i = 0; i < N; i++) {
label_char 8 uimsbf
}
}
prefetch_priority 8 uimsbf
}

The transport_protocol_label field is a reference to the transport protocol descriptor that this pre-fetch descriptor refers to.
Each label identifies one or more modules in the DSM-CC object carousel with the corresponding label, and the prefetch_priority field tells the receiver what priority should be given to pre-fetching the modules identified by that label. Each label may have a priority value between 1(the lowest) and 100 (the highest).

The DII location descriptor

For applications carried in a DSM-CC object carousel, the DII location descriptor can be used in conjunction with the pre-fetch descriptor.
The DII location descriptor tells the receiver which DSM-CC DownloadInfoIndication messages contain the descriptions of any modules that are identified by the labels in the pre-fetch descriptor for that application or service (via the DII_information field).
The association_tag field identifies the elementary stream that contains the object carousel in question. More information about DownloadInfoIndication messages and the role they play in DSM-CC object carousels is available in our DSM-CC tutorial.

Format of the DII location descriptor. Source: TS 101 812 v1.3.1 (MHP 1.0.3 specification).
No. of bits Mnemonic
DII_location_descriptor() {
descriptor_tag 8 uimsbf
descriptor_length 8 uimsbf
transport_protocol_label 8 uimsbf
for (i = 0; i < N; i++) {
reserved_future_use 1 bslbf
DII_identification 15 uimsbf
association_tag 16 uimsbf
}
}

As with the pre-fetch descriptor, the transport_protocol_label field is a reference to the transport protocol descriptor that this pre-fetch descriptor refers to.

The IP routing descriptor

The IP routing descriptor may be present in the common descriptor loop of the AIT if any of the services use multicast IP as their transport mechanism. More than one IP routing descriptor may be present in any AIT. This tells the receiver which elementary stream contains packets from a given set of IP addresses and ports.

The IP routing descriptor is only used in MHP 1.0.2 systems (including GEM) or earlier and MHP 1.1. MHP 1.0.3 and MHP 1.1.1 and later uses the IP signalling descriptor (see below) and IP/MAC notification table instead.

Format of the IPv4 routing descriptor. Source: TS 101 812 v1.2.1 (MHP 1.0.2 specification).
No. of Bits Mnemonic
routing_descriptor_ip4() {
descriptor_tag 8 uimsbf
descriptor_length 8 uimsbf
for (i = 0; i < N; i++) {
component_tag 8 uimsbf
address 32 uimsbf
port_number 16 uimsbf
address_mask 32 uimsbf
}
}

There are actually two different IP routing descriptors, one for IP version 4 routing and one for IP version 6 routing - we have shown the IPv4 version here. These descriptors will have different descriptor tags, and the size of the address and address_mask fields will be different for the two protocols (these fields will be 128 bits long in the IPv6 routing descriptor),but all other fields are identical.

The IP signalling descriptor

The IP signalling descriptor may be present in the common descriptor loop of the AIT if any of the services use multicast IP as their transport mechanism, and is used in conjunction with the IP/MAC Notification Table (INT) to determine which set of IP routing rules apply to the receiver. This descriptor is only used in MHP 1.0.3 and MHP 1.1.1 or later - other versions of MHP (including GEM) use the IP routing descriptor described above.

Format of the IP signalling descriptor. Source: TS 101 812 v1.3.1 (MHP 1.0.3 specification).
No. of Bits Mnemonic
ip_signalling_descriptor() {
descriptor_tag 8 uimsbf
descriptor_length 8 uimsbf
platform_id 24 uimsbf
}