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:
| 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.
| 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.
| 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.
| 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.
| 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.
| 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.
| 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.
| 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.
| 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.
| 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.
| 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.
| 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.
| 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.
| 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.
| 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.
| No. of Bits | Mnemonic | |
|---|---|---|
| ip_signalling_descriptor() { | ||
| descriptor_tag | 8 | uimsbf |
| descriptor_length | 8 | uimsbf |
| platform_id | 24 | uimsbf |
| } |