Home » Tutorials » An Introduction To OCAP » OCAP Application Signalling

OCAP Application Signalling

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:

Format of the application information table. Source: 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
}

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.

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
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:

Format of the unbound application descriptor. Source: OCAP 1.0 profile, version I15.
  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:

Format of the abstract service descriptor. Source: OCAP 1.0 profile, version I15.
  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.

Format of the privileged certificate descriptor. Source: OCAP 1.0 profile, version I15.
  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:

Format of the application storage descriptor. Source: OCAP 1.0 profile, version I15.
  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.