On the surface, OCAP has an application model very similar to MHP’s. Applications implement JavaTV’s Xlet interface in order to give the receiver a way to start and stop them, and to give the application an interface to information about how it was stated and any properties that it needs to know about. Like MHP, the receiver uses signaling from the network to decide which applications are available to be started and what priority those applications have. There are a number of differences as well, however, that we need to examine.
OCAP 1.0 supports applications written in Java (known as OCAP-J applications). OCAP 2.0 extends this, and includes support for applications written in HTML. These are known as OCAP-HTML applications. One thing for MHP developers to note is that OCAP-J and OCAP-HTML applications may not be the same as DVB-J and DVB-HTML applications. Although there is a lot of overlap between MHP and OCAP, there are also a lot of differences and these can affect the behaviour of an application. The biggest difference is the number of different types of application that can be run in an OCAP receiver. These are all basically the same – either Java or HTML applications that follow the same basic lifecycle and have the same interface, but which have different lifecycles and possibly different capabilities.
OCAP Application Types
On the surface, OCAP has an application model very similar to MHP’s. Applications implement JavaTV’s Xlet interface (or in the case of HTML applications, simply have a well-defined structure) in order to give the receiver a way to start and stop them, and to give the application an interface to information about how it was stated and any properties that it needs to know about. Like MHP, the receiver uses signalling from the network to decide which applications are available to be started and what priority those applications have. There are a number of differences as well, however.
Service-bound applications
Just like MHP, OCAP supports service-bound applications. These are can run only on the services that they are signalled to run on. Typically, any application associated with a specific service or TV show will be a service-bound application. When the receiver selects a different service, it must check to see which of the service-bound applications that are currently running are signalled on the new service. Any applications that are signalled will continue to run, but those applications that are not signalled will be stopped. This makes sure that a CNN news ticker only runs while the user is actually watching CNN. This allows the network operator to be more confident that all of the applications that the viewer can run will actually run together, and this kind of reliability is important in the broadcasting world. Since only limited sets of applications can run simultaneously (i.e. those that are signalled for a given service), the amount of testing that’s needed to verify that they’ll play nicely together is reduced.
Since these are covered in a fair amount of detail in the MHP tutorial, we won’t cover them in too much detail here. In short, an additional SI table called the Application Information Table (AIT) carries information about which applications are available for a given service. Each service containing service-bound OCAP applications will have an AIT associated with it. 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. More information about the AIT can be found in the section below on application signalling.
In an MHP system, all applications are bound to a specific service or set of services. That set of services may include every service offered by the network operator, but that’s a moot point – a service must still explicitly allow an application to run, or the application will be killed. This is not the case with OCAP, however.
Unbound applications
Unlike MHP, OCAP also supports unbound applications – applications which are not tied to a specific service and which can be started no matter what service is currently being presented.
Unbound applications are typically provided by the network operator as a way of generating extra revenue through value-added services. These may be VOD or NVOD services, games or other premium interactive services.
While unbound applications may seem like a small change at first, it has some important side effects that need to be considered. These unbound applications can run at any time, coexisting with any service. While this doesn’t in theory offer anything new over MHP (except ease of use for the network operator- signalling the same application on every service can be a pain), there are some issues that need to be considered when using unbound applications.
Unbound applications can have an effect on the predictability of a system which uses them. In an MHP receiver, it’s pretty clear which applications will be running. When you add unbound applications to this, however, the network operator has a few more scenarios when testing that applications coexist with one another. This is not necessarily hard – after all, it’s no different to having the unbound applications signalled as bound applications on every service. Since the applications are not signalled in the same way, though, it’s easier to forget that unbound applications have to coexist with service-bound applications.
The monitor application
In any interactive TV receiver, there are a number of core functions that must get carried out as part of the general housekeeping within the receiver. These include things like resource management; parsing application signalling and launching or killing applications; and managing security functions by updating certificates and checking permissions. While these functions may not be glamorous (how many times have you impressed someone by telling them you wrote an application manager?), they do contribute to the user’s experience with the receiver.
In an MHP system, these functions would be built into the firmware of the receiver as the ‘Navigator’, and their behaviour is largely determined by the receiver manufacturer. In US cable systems, this model doesn’t apply – instead, the monitor application carries out these tasks. A monitor application is an unbound application which has special privileges in the receiver, and which is provided by the network operator. Typically, only one monitor application is available on the at a time.
Since the monitor application is such an important part of the overall user experience, it’s covered in more detail in the discussion of the software architecture of an OCAP receiver.
System applications
An OCAP receiver can contain several special applications which carry out various functions within the system. The monitor application is one example of this which we’ve already seen, but there are others. The most common of these will probably be the application that handles messages from the Emergency Alert System. This is a system that is required in US digital cable systems for transmitting information to viewers during national or regional emergencies such as natural disasters. This may either display messages as an overlay on the screen, or it may force tuning to a specific service in order to display the messages.
Given that every receiver must support this service, this functionality may be included in the monitor application. By default, handling of Emergency Alert System messages is carried out by a module in the Execution Engine that can be replaced by other applications. See the discussion of the OCAP software architecture for more details of this.
Native applications
While MHP acknowledges native applications, they are handled completely separately from downloaded applications. Even built-in MHP applications are effectively considered native, and while the application manager may be able to start them, a downloaded application probably won’t even know that they are there.
The differences in an OCAP receiver – especially the presence of a monitor application – mean that interoperable applications must be able to manipulate and control native applications. Since there is no navigator software than can know about built-in applications, they can only be started via the monitor application. This means that native applications must have an OCAP-compatible interface, so that they can be controlled from the monitor application. It also means that any changes in their state (such as terminating) must be reflected back to the monitor application.
This can be handled by having a simple OCAP application that acts a a Java wrapper for the underlying native application.
Application Signalling
In order for a receiver to know about any applications that can be run, it somehow needs to be told that they are there. One way of doing this is to use an additional service information table called the Application Information Table (AIT). This provides a way for receivers to find out about applications that are bound to the current service and which can be started.
As we have seen, an OCAP receiver can also run applications which are stored in the local storage of the receiver or which are not bound to any service (stored applications and unbound applications, respectively). In this case, information about those applications can’t be broadcast as part of a service, because the applications themselves aren’t part of a service. To get round this problem, OCAP defines an additional way of delivering information about applications – the Extended Application Information Table (XAIT). This is an XML file that can be delivered to the receiver in a number of ways, either over the broadcast channel or over the return channel, and which describes applications that are not bound to a given service. The XAIT contains information about unbound applications, system applications and the monitor application.
Application signalling is a complex topic, and we’ll study it more in the application signalling tutorial.
The lifecycle of an OCAP application
Like MHP, the OCAP middleware in the receiver contains a component called the application manager that is responsible for monitoring the current services and starting or stopping applications. Unlike an MHP receiver, however, this application manager does not have complete control over what happens to applications in the system.
The application manager in an OCAP receiver manages a database of all available applications – including native applications, stored applications and those which are not bound to any service. When the receiver notices that application signalling has changed (or in some cases, when applications have been registered – see the application signalling tutorial for details of how and when this happens), any new applications are loaded into the application database and any applications not present in the current signalling are removed.
Applications are given a control code as part of the signalling. This tells the receiver what action should be taken for that application. The three most common and useful control codes that we are likely to encounter are:
- auto-start – start the application automatically, without any action by the user
- available -inform the user that an application is available and may be started, but don’t start it automatically
- kill – kill the application if it is running, and do not allow the user to restart it.
There are some other control codes, but they are not as common.
The application manager uses these control codes to decide what to do with an application. If an application is signalled as auto-start, or if the user chooses to start an application, the application manager will query the monitor application (if one is registered) to see whether that application is allowed to run. If the monitor application allows the application to be run, then the application manager starts it and manages its state as it runs.
In the case that application signalling tells the receiver to kill an application, the application manager is the one to do that. In this case, the monitor application has no influence – it can not stop a particular application (even itself) from being killed.
The monitor application does have one final way to influence the application manager, however. It can choose to register new unbound applications with the application database. Once registered, these applications can be started and controlled just like any other application. The monitor application can also unregister applications that it has registered, removing them from the application database as if their signalling had been removed (which, in effect, it is).
Once an application is entered into the application database, it will go through a number of states. These are shown in the state diagram below:
The lifecycle of an OCAP-J application.
OCAP applications begin in the ‘unloaded’ state – the OCAP receiver knows about their existence (through the application signalling), but has not loaded any of the files. When the application is started (either because it is signalled as auto-start, or because the user has chosen to start it), it first enters the ‘paused’ state. At this point all of the necessary classes to start the application have been loaded, and the main class of the application has been created and initialised, but the application is not actually running yet.
At last, the application actually starts and at this point it enters the ‘started’ state. An application in this state is running normally and is interacting with the user and may be using scarce resources.
When an application terminates, it goes back to the ‘unloaded’ state. All of the class files and content associated with the application are removed from memory, any scarce resources are reclaimed and the application is back where it started from.
MHP developers may think that this is pretty familiar stuff. However, there is one difference that may not look important at first, but which OCAP implementers need to be aware of. When a DVB-J application terminates, it moves to the ‘destroyed’ state. From here, there is no way back to any other state. While this may look like an oversight on the part of the MHP standards authors, it’s been left alone through three (four, if you count MHP 1.1) revisions of the standard and so we can assume that it should be this way. Exactly what happens when a user starts another copy of an application that has run and been killed isn’t specified. We can make some sensible assumptions, but it’s not clear whether an application should re-use any cached copies of classes used by that application, or whether it should reload all of them.
OCAP receivers on the other hand, have a different state model. As you can see above, when an OCAP application terminates, it moves back to the ‘unloaded’ state. This means that any memory used by application classes or assets is freed, but the application may be terminated and then restarted.
So now we’ve seen what happens when you select a service that contains an OCAP application. Well, kind of. Of course, when you select a service, you’re normally switching from another service. And that service might also contain an OCAP application. It might even contain the same OCAP application. Confused yet? And we haven’t even started considering unbound applications.
This isn’t actually as scary as it sounds. Basically, what happens is this: when you select a new service, the receiver watches for an AIT for that service. If it finds one, it compares the list of signalled applications with the applications that are currently running. Any applications that are running and which aren’t signalled as being allowed to run in the new AIT get killed, and any applications in the new AIT that are signalled to start automatically get started.
One potential problem with the AIT is that any applications that are explicitly signalled in it are either signalled as being available to start, or as being automatically killed. The AIT also allows broadcasters to take a neutral stance on some external applications, however. The external application authorization descriptor is a descriptor that may appear in the AIT that allows the broadcaster to indicate that an application may continue running if it is already started, although a new copy of it may not be started.
For example, a news ticker application from CNN may be known not to interfere with any applications broadcast on ESPN, and so it may be listed in the external application authorization descriptor for ESPN and will continue running. However, there may be a known conflict with an application being broadcast on MTV, and so the news ticker will not be listed in the external application authorization descriptor for MTV.
Why do we need this functionality? Why not just signal it in the AIT? Well, the control codes that are possible in the AIT either explicitly kill or start an application, or say that it is available for starting. There is no control code which says that "this application may be allowed to continue if it’s currently running, but no more copies can be started."
Arguably, this is an oversight and it would have been simpler to include an extra control code instead of adding the external application authorization descriptor, but for now we have to use the external application authorization descriptor.
This is all made marginally more complex by the fact that some applications can be signalled in the AIT as being bound to the current service. This adds another step to the process, where any applications that are signalled as being service bound get killed before anything else happens. What this means is that the final process that occurs when an OCAP receiver switches to a new service is something like this:
- The application manager examines the current set of applications. Any which are signalled as being service bound are killed immediately.
- The application manager examines every application that is signalled on the new service. Any applications that are signalled as auto-start are loaded and started.
- Any applications that were already running and are not signalled directly in the AIT are compared against the application identifiers listed in the external application authorization descriptors.
- Any already running applications that is not signalled, and is not listed in these descriptors is killed.
So how do unbound applications fit into this? Basically, they don’t – as their name suggests, they are not bound to any particular service, and so they are not affected by selecting a new service. They are only affected by changes to the XAIT.
Application priority and the launch order
Like MHP, OCAP applications have an associated priority that is used for resolving resource conflicts and other similar situations. Unlike MHP, however, OCAP applications have fixed priority ranges. MHP doesn’t really need these, since system applications such as the navigator are built into the middleware stack and can implicitly be given higher priority. In OCAP, systems applications are just like any other application, and so they must be identified in a different way.
The following table shows the allowable priority values for the different classes of application:
| Application class | Priority |
|---|---|
| Monitor applications | 255 |
| System applications | 128-254 |
| User applications | 1 – 63 |
The priority values 64-127 are reserved, and should not be used. Similarly, a priority of 0 should not be used although it’s not expressly forbidden in the OCAP standard.
Stored applications also have an additional parameter that influences this: the launch order. This value tells the receiver what should happen when it has two applications with the same application ID and the same priority – in other words, two versions of the same application. The launch order is a value between 0 and 255, and the application with the highest launch order will be the one that actually gets launched.
Loading an application
The files that make up an application and its associated assets (e.g. images, audio clips or text files) can be loaded in to the receiver in a number of ways. Some applications may be stored in the receivers local storage when it is manufactured. Others are downloaded later, through one of two mechanisms.
In the first mechanism, the files are broadcast as part of the MPEG-2 transport stream, using a DSM-CC object carousel to provide a broadcast filesystem. 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 interactive TV applications. There is nothing particularly special about the object carousels used by OCAP, and so almost any object carousel generator can be used. Given the complexity of DSM-CC, we won’t go into a detailed discussion of it here. If you’re interested in knowing more about how DSM-CC actually works, a technical introduction to DSM-CC is available elsewhere on this site.
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.
Application management – differences from MHP
- OCAP adds support for unbound applications as well as service-bound applications.
- The monitor application, an unbound application provided by the network operator, plays an important part in managing the receiver and in controlling other applications.
- To help support unbound applications and the monitor application, OCAP uses additional application signalling called the XAIT. This is an XML file that can be made available to receivers either in an object carousel, via the return channel or embedded in service information.
- OCAP receivers can contain native applications as well as downloaded applications. These native applications must have an OCAP-compatible wrapper written in Java, so that they can be controlled by the monitor application.