If you’re familiar with application signalling as it’s used in MHP, you may be in for a surprise when you look at OCAP’s application signaling. There are some significant changes to what you’ll be used to. Some of these changes are caused by the different SI mechanism used in ATSC cable systems, while others are caused by the changes to the application model.
The AIT
Before an OCAP receiver can actually run an application, several things have to happen. First of all, the receiver has to know that the 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 are handled by the same mechanism. MHP defines an extra service information table called the Application Information Table (AIT), which is also used by OCAP. This table is broadcast for every service that contains an OCAP application, and it contains an entry for every 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 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 |
| } |
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 0x5FFF. Applications which want to use features that are only available to the monitor application must have an applicaiton ID between 0x6000 and 0x7FFF.
All other application ID values are reserved 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 |
| pre-fetch descriptor | optional | application descriptor loop |
| OCAP-J application descriptor | mandatory for OCAP-J application | application descriptor loop |
| OCAP-J application location descriptor | mandatory for OCAP-J application | application descriptor loop |
| OCAP-HTML application descriptor | mandatory for OCAP-HTML application | application descriptor loop |
| OCAP-HTML application location descriptor | mandatory for OCAP-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 |
Application files
The application files themselves are broadcast as part of the MPEG-2 transport stream, in a DSM-CC object carousel. Many developers (especially receiver developers) are not big fans of DSM-CC because it’s big and complex. At the same time, it is probably the best existing format for the job, and allows things like dynamic updates that are very useful for DTV applications. MHP and OCAP impose a few restrictions on the format of the object carousel, so it’s worth checking that your object carousel generator is compatible with OCAP.
Of course, having the object carousel containing the application files is only a part of the issue – the receiver still has to actually find it. Each entry in the AIT has an application location descriptor (which will have slightly different formats for OCAP-J and OCAP-HTML applications) that will identify the object carousel that contains the application, as well as the path within that object carousel since an object carousel can contain more than one application.
The XAIT
The AIT provides a good way of signaling service-bound applications, but it’s less useful for signaling applications that are not bound to a service. Since each AIT must be broadcast as part of a service, the limitations become pretty obvious when you try to signal unbound apps. Even broadcasting AIT entries for unbound applications on every service is not enough, since they may actually run when no other services are being presented.
In addition to the AIT, OCAP systems use additional application signaling called the XAIT (the Extended Application Information Table). This follows a similar structure to the AIT (up to and including the same table ID), but is extended to include a couple of extra descriptors that are not present in the AIT. The XAIT is transmitted on PID 0x1FFC, contained in an Extended Channel MPEG section flow, thus enabling the receiver to identify this as an XAIT rather than just another AIT.
Each XAIT entry must include an unbound application descriptor. This tells the receiver which abstract service the application is part of. This descriptor has the following format:
| No. of Bits | Identifier | Value | |
|---|---|---|---|
| unbound_application_descriptor() { | |||
| descriptor_tag | 8 | uimsbf | 0xAF |
| descriptor_length | 8 | uimsbf | |
| service_id | 24 | uimsbf | |
| version_number | 32 | uimsbf | |
| } |
The version number in this case is the version number of the application.
Each XAIT must also include an abstract service descriptor in the common descriptor loop. The abstract service descriptor describes an abstract service which contains one or more of the applications described in that XAIT. An abstract service descriptor looks like this:
| No. of Bits | Identifier | Value | |
|---|---|---|---|
| abstract_service_descriptor() { | |||
| descriptor_tag | 8 | uimsbf | 0xAE |
| descriptor_length | 8 | uimsbf | |
| service_id | 8 | uimsbf | |
| reserved | 7 | uimsbf | |
| auto_select | 1 | bslbf | |
| for (i = 0; i < N; i++) { | |||
| service_name_byte | uimsbf | ||
| } | |||
| } |
The service ID field is used to identify the abstract service in question. Abstract services defined by the receiver manufacturer will be in the range 0x010000 to 0x01FFFF, while those defined by the network operator will be in the range 0x020000 to 0xFFFFFF.
We’ll take a closer look at how abstract services are used in a later section in this tutorial.
The common descriptor loop must also include a privileged certificate descriptor. This is used to help authenticate any applications that want to use functionality reserved for the monitor application, and it contains the SHA-1 hashes for the certificates used to sign those applications.
| No. of Bits | Identifier | Value | |
|---|---|---|---|
| privileged_certificate_descriptor() { | |||
| descriptor_tag | 8 | uimsbf | 0xB1 |
| descriptor_length | 8 | uimsbf | |
| for (i = 0; i < N; i++) { | |||
| for (j = 0; j < 20; j++) { | |||
| certificate_identifier_byte | 8 | uimsbf | SHA-1 hash |
| } | |||
| } | |||
| } |
The other new descriptor used by the XAIT is the application storage descriptor. This tells the receiver whether an application should be stored in its local storage, so that it can be quickly started later. This is commonly used with applications such as the monitor application to make sure that they are always stored in the receiver where possible.
The application storage descriptor has the following format:
| No. of Bits | Identifier | Value | |
|---|---|---|---|
| application_storage_descriptor() { | |||
| descriptor_tag | 8 | uimsbf | 0xB0 |
| descriptor_length | 8 | uimsbf | |
| storage_priority | 16 | uimsbf | |
| launch_order | 8 | uimsbf | |
| } |
Again, we’ll take a closer look at how this descriptor is used (and why) in a later section.