13.3 CableLabs' Open Cable Application Platform (OCAP)The North American cable industry views the use standards as a long term strategy for lowering the cost of delivering higher quality innovative television to viewers [SCTE]. Efforts in digital and interactive TV are well underway, but they tend to be somewhat localized and fractured. This localization is understandable, because the standardization bodies are geographical. Some of the key standards, such as MPEG, have garnered wide acceptance and form the basis for deployments of digital video around the world. Other standards have been regionally adopted, and provide for interpretability within their purview. Additional standards are being defined to allow for more advanced interactive services, however, these standards provide overlapping features and are vying for acceptance. The OCAP is a port of the DVB MHP specification to fit the needs of the north american cable market [OCAP] developed by Cable Labs [CableLabs]. The standard organization that approves and renders OCAP official is SCTE. Like MHP, the OCAP 1.0 software has access to streams of video, audio, data, and other media assets. Because OCAP is a cable industry specification, these streams are distributed over a cable operator's network. Applications process the streams and present content to the viewer. The platform receives input from the viewer via input devices such as a remote control or keyboard. In response to viewer input, the platform presents visual output to a screen or television and audio output to speakers . 13.3.1 ArchitectureOCAP is designed to allow cable operators to deploy a wide variety of interactive television services. The range of services extends from simple broadcast enhancements to complex interactive environments. Applications may be written by cable operators, content providers, CE manufacturers or some combination of the three. The host device subsystem described in the OCAP Specification represents the set-top box hardware, and the operating middleware subsystem encapsulates an application execution environment essentially acting as an operating system [OCAP]. 13.3.2 Host Device SubsystemsOCAP 1.0 is designed for advanced hybrid analog and digital set-top box. The set-top box supports all existing analog services as well as the new digital services, and is portable to a variety of hardware engines. Figure 13.8 depicts a simplification of the software architecture adopted by the OCAP 1.0 standard.
Figure 13.8. A simplified OCAP 1.0 software architecture.
13.3.2.1 OCAP Applications
13.3.2.2 Baseline FunctionalityThe baseline functionality needs to be available under all circumstances, including in situation with the CA subsystem is not present or not initialized . The baseline functionality is as follows :
13.3.3 Deviations from DVB-MHPOCAP uses DVB-MHP as its baseline. Deviations from the MHP specification are mostly concerned with Conditional Access TV (CATV) network configurations as well as compliance with the existing infrastructure of cable standards.
Beyond the MHP specification, OCAP supports the following:
13.3.4 Application ModelThe OCAP application model adopts the basic MHP application lifecycle control. However, it extends the DVB-MHP service bound application model to include unbound and monitor applications that may not be fully controlled by broadcasters. 13.3.4.1 Unbound ApplicationsUnbound applications are broadcast service independent. The service context is used as a container for an abstract service; each application is associated with an abstract service. Abstract services are a mechanism to group a set of related unbound applications where some aggregator has taken the responsibility to ensure that the set of related applications work together. This is a generalization of a broadcast service to support applications not related to any broadcast TV service. For example, Email and chat applications could be bundled together and authorized using an abstract service. Unbound applications are initiated and controlled by specific API calls from a monitor application or other unbound application. Unbound applications may also be initiated and controlled via the eXtended Application Information Table (XAIT) file being signaled in the XAIT descriptor, whose format is given by a DTD. Unbound applications may be delivered or obtained through a variety of transports including IP connection to a server and broadcast carousel. An unbound application with appropriate privileges may choose any delivery and download method to obtain valid unbound applications, that are not defined in the XAIT file signaled in the XAIT descriptor. An unbound application may choose to use the XAIT file format to initiate and download other unbound applications. There are no requirements on how an unbound application may choose to download this file. A monitor application is a special unbound application that has access to a privileged API set used to manage the execution of applications in the OCAP terminal. The monitor application is signaled to the set-top box from the Headend via the XAIT file in the XAIT descriptor. Once the monitor application has started, it searches the XAIT for other autostart applications and start them as well. The monitor application's primary responsibility is to act as the policy enforcer over all applications. The monitor application uses the org.ocap.application APIs to manage the lifecycle of unbound applications. An OCAP 1.0 compliant set-top box implementation contains an executive module that is responsible for loading, authenticating, and starting the appropriate monitor application, if signaled in the XAIT. In addition, the executive module, in the absence of a signaled monitor application, authenticates and starts unbounded applications signaled as autostart in the XAIT. Among other requirements, the executive module must ensure that at any given time, there is only one active monitor application. 13.3.4.2 SignalingSignalling is used in OCAP 1.0, like DVB-MHP, to affect the lifecycle of service bound applications. OCAP 1.0 supports multiple forms of signaling to support service bound and unbound applications. As a response to this signaling the set-top box creates or updates entries in the application database used by the application manager to support the Application Lifecycle APIs. There are three forms of signaling in OCAP 1.0: one for service bound and two for unbound applications. Service bound application signaling include AIT signaling in the PSI of an in-band transport. Unbound application signaling includes the following:
These three forms of signaling use different encoding of essentially the same abstract data structure, the AIT. DVB-MHP uses a binary encoding of the AIT as an extension of the PMT in the PSI. The service to which the AIT belongs is the service under which the application runs. At boot time, the OCAP application manager needs to know which application(s) to start, in particular which monitor application to start. This information is carried in the XAIT. On reboot of the set-top box, the OCAP implementation locates the XAIT descriptor and load the XAIT file from the out-of-band network and resolve unbound application signaling. The OCAP implementation contains a system module, referred to as the executive module, that loads, authenticates, and starts unbound and monitor applications on a conditional basis. When a monitor application is signaled and started, it starts any unbound application signaled in the XAIT file as autostart. When no monitor application is signaled in the XAIT, the executive module starts the unbound applications. 13.3.4.3 System UpgradesTo enable upgrades, the OCAP 1.0 set-top implementation monitors the changes made in the XAIT file signaled in the XAIT descriptor for unbound and monitor applications. On the receipt of a change to the XAIT file, all applications that registered interest receive notification. If there are no registered interests from the monitor application, the set-top box implementation handles the upgrade. The upgrade process is not standardized and is implementation dependent. When an update to the XAIT is detected , the middleware checks to see if there are any registered monitor applications or unbound applications that are interested in this event. If there are interested applications, the middleware notifies those applications of the revision change. It is the responsibility of the registered monitor application to maintain the application registry based on the modifications to the XAIT; when appropriate, it may initiate a reboot call for an upgrade to take effect. If there are no registered applications or modules interested in the XAIT notification event, the middleware handles the upgrade as defined in the previous section. How the upgrade process occurs is implementation dependent. OCAP applications may select services or abstract services using the service selection API. It is the responsibility of the executive module to load and upgrade unbound applications flagged as autostart after a successful boot process. After the boot process is complete, the OCAP 1.0 implementation verifies the version of the XAIT file in the XAIT descriptor. If it is a more recent version, the OCAP 1.0 implementation retrieves the XAIT file. The executive module is informed of these changes and creates a service context for each abstract service with autostart applications in them. All signaled autostart unbound applications should be available at all times. However, it is possible that some autostart applications may not be available if one of its code or data files is not accessible (e.g.,due to network access or memory problems). In such a case, the monitor application, if available, determines the appropriate action. 13.3.4.4 Application Registration and ControlEach unbound application execute as part of an abstract services which are created and managed through the org.ocap.application API. The monitor application uses references abstract services created when registering unbound applications. OCAP 1.0 employs an application listing and launching API that allows a monitor application to create and launch an unbound application. This API allows management of the application database, containing, for each application instance, its abstract service model. That model is an application description file used to create storage for an application. The application database API, however, does not allow, and the specification prohibits, promoting a service-bound application to an unbound application. 13.3.4.5 Application LaunchOnce loaded, starting unbound applications is similar to starting service bound applications. The middleware adds the abstract service of that application to the list of available services. An autostart unbound application is launched by performing the following steps:
It is the responsibility of the monitor application, executive module, or other unbound applications, to start other unbound applications that were not signaled with the autostart flag set. As part of this responsibility the launching application or module creates the service context and abstract service for these new applications if they have not yet been created. For example, if there were no autostart applications within an abstract service, it is the responsibility of the initiating application or module to create a service context and the associated abstract services. In addition, the initiating application or module registers and launches those applications. 13.3.4.6 Stopping Unbound ApplicationsThe cable service operator may request a set-top box to stop an unbound application using the control codes in the XAIT file. An unbound application may voluntarily stop itself. Further, an unbound application may request to stop another unbound application it created or launched. The monitor applications, if it registers interest, can handle the execution state of unbound applications signaled in the XAIT file of the XAIT descriptor. If the monitor application has not registered interest, it is the responsibility of the middleware module or the application that initiated other applications to handle their execution state. 13.3.4.7 Multiple Concurrent Unbound and Service ApplicationsOCAP 1.0 extends DVB-MHP to include support for execution of multiple simultaneous abstract services, and it allows multiple applications within an abstract service to be executed and presented concurrently. In addition, multiple bound services and unbound abstract services, along with any associated applications, can be executed concurrently. When concurrently executing applications is not possible, perhaps due to lack of resources, then the behavior is constrained by application priority and resource management. For new services selected replacing a previously selected one, OCAP 1.0 extends DVB-MHP to include the ability to replace abstract services. When a new abstract service is selected and it is in the same service context as the previously selected abstract service, applications from the former abstract service that are signaled in the newly selected service continue to execute. The cable service operator may choose to use the abstract service flag in the application descriptor to determine whether this application needs to be restarted or should continue its execution. 13.3.4.8 SecurityAccurately determining which applications have the right to execute with monitor application privilege is very important. It is not sufficient, for example, to identify applications that are granted monitor application status by placing a simple element in the permission request file, which would permit any signed application to grant itself any and all privileges. The privileged operation access is a resource owned by, and can be granted by, the MSO. However, MSOs are allowed to contract out the authoring of monitor applications. Additionally, OCAP does not require that the MSO sign the application, nor that the MSO give its private key to the company that designs and implements the monitor application. What is required is that the MSO obtains a specialized certificate from the certificate authority, stating that it is an MSO. This certificate is then used by the MSO to generate a voucher, which contains the application ID of the monitor application along with the MSO's certificate. The MSO provides the voucher to the monitor application provider. The monitor application provider then inserts the voucher into the signed monitor application permission request file that accompanies the monitor application. The entire monitor application is also signed by the monitor application provider. For a voucher to be authenticated, it contains an MSO ID, is signed by the private key of the entity corresponding to the MSO ID, and the associated public key is contained in a special, MSO-identifying X.509 certificate chain that constitutes the final component of the voucher. As all certificate chains, this chain consists of one or more certificates. Each certificate contains an entry in the extension key usage field of MSO and is flagged as critical. Additionally, all of the other certificates in the chain prior to (but excluding) the final certificate, have the key usage field bit corresponding to keyCertSign set, as well as the key usage field flagged as critical. 13.3.4.9 Native AccessOCAP 1.0 applications may access functionality outside the OCAP API, known as native APIs. These native APIs may be packages that are part of the execution engine, or they may be part of an environment that is proprietary to the Host device. Applications that access such APIs use the JNI. If calling such a native interface causes threads or other processes to be created in a proprietary environment, it is the responsibility of the calling OCAP application to relay lifecycle and resource management commands from the application manager, such that the native threads adhere to the behavior dictated by the execution engine. 13.3.4.10 Application Manager ResponsibilitiesOCAP 1.0 extends the MHP application manager's functional responsibilities as follows:
13.3.4.11 Application PriorityA priority system is provided to control the probability that applications gain access to shared OCAP resources. Three types of applications are identified for the purposes of priority assignment; monitor, system, and user. These application types are implied by the priority they are assigned. The priority ranges are described in Table 13.10. Table 13.10. Priority Ranges for Application Types
13.3.5 eXtended Application Information Table (XAIT)The XAIT is used for launching and managing the lifecycle of unbound applications. The XAIT identifies the initial set of unbound applications, including the monitor application, that are launched at boot time in the OCAP 1.0 environment. Table 13.11 presents a short overview of the XAIT's content; for the actual detailed specification, see the OCAP specification. Its design is based on the AIT used by MHP to signal service-bound applications. An XAIT descriptor (see Table 13.12) pointing to the XAIT file is delivered with the MPEG transport stream as defined in SCTE 65. Table 13.11. The eXtended Application Information Table (XAIT)
Table 13.12. The Format of the XAIT Descriptor Placed in the Virtual Channel Table
Table 13.13. Values for the location_id Field
|