13.3 CableLabs Open Cable Application Platform (OCAP)


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 Architecture

OCAP 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 Subsystems

OCAP 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.

  • Conditional Access (CA) : OCAP CA controls access to specific services that require subscription fees. It is the equivalent of analog de- scrambling for digital services.

  • Audio, video, and graphics processing : This subsystem is responsible for MPEG-2 decoding, AC3 audio decoding, and on-screen display generation. Following MHP, a multi-plane architecture is used consisting of a video plane and a graphics plane.

  • Inputs : The viewer interacts through devices such as InfraRed (IR) RC and keyboard. Other input options are Ethernet, USB, IEEE-1394 FireWire, audio and video signals.

  • Outputs : Output is presented in composite (or baseband) video and audio. Optional outputs include component video, S-Video, and the IEEE-1394 FireWire.

  • The Cable Network Interface (CNI) : This is the interface between the cable system and the set-top box. The CNI, based on SCTE 40, consists of the cable tuner, NTSC demodulator, QAM demodulator, and an Out-of- Band (OOB) receiver. This sub-system includes protocols and behavior to support cable networks. Network protocols include:

    • Application protocols for communicating between distributed application components ,

    • Cable network protocols for audio, video and data applications, and system information,

    • Host support for POD resources.

Figure 13.8. A simplified OCAP 1.0 software architecture.

graphics/13fig08.gif

13.3.2.1 OCAP Applications
  • Monitor application : The monitor application is the central control point that determines whether all other applications are able to run. It is the primary tool enabling cable operators to implement their content management policies. It governs the behavior of specialized remote keys, and controls the authorizations and permissions granted to all applications. It is further resource management and system-level error handling.

  • EPG : The EPG is a special application that provides with an interface for channel and data service selection. This application is written by, or for, the cable operators and reflects the look-and-feel of their user interface to the viewer.

  • Native application : Native applications do not rely on interpretation Java bytecode and often do not need to rely on the middleware APIs. They may need to be implemented when the performance of non-native application is not sufficient. Native applications may also be needed to support legacy functionality or to take advantage of hardware on a specific OCAP 1.0 host device that is not exposed by the execution engine APIs. Native applications are required to implement an OCAP 1.0 application front-end, to reserve shared OCAP resources and allow remote lifecycle management through the monitor application and the application manager.

13.3.2.2 Baseline Functionality

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

  • Executive : launches the monitor application or unbound applications,

  • Watch TV : minimal remote control support and clear-to-air channel tuning,

  • GUI : POD MMI,

  • Emergency alert system : mandated EAS, works before and after POD insertion,

  • Closed captioning : mandated closed captioning works, before and after POD insertion,

  • Copy protection : copy policy and digital rights management.

13.3.3 Deviations from DVB-MHP

OCAP 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.

  • Network Dependent Protocols : The network dependent protocols for CATV are as defined in SCTE DVS 131. The interaction (return) channel interface is specified by SCTE 54.

  • MPEG-2 Transport : The MPEG-2 transport stream is modified as specified in SCTE 7. DSM-CC User-to-User Object Carousel protocols are defined in ISO/IEC 13818-6 optionally with the restrictions and extensions defined in SCTE 80.

  • Multiprotocol Encapsulation : MPE as defined in SCTE 42 is used for the encapsulation of IP datagrams using MPEG-2 transport stream packets. SCTE 42 supports the DVB and ATSC formats for MPE using DSM-CC addressable sections.

  • Service Specific Protocols : OCAP 1.0 Service Information as defined in SCTE 65. Service specific protocols are proprietary. As opposed to MHP 1.0.1, OCAP does not provide a registry mechanism for new, proprietary broadcast protocols.

Beyond the MHP specification, OCAP supports the following:

  • Reverse data channel as specified in SCTE 55-1.

  • Forward data channel as specified in SCTE 55-2.

  • All transports required by SCTE 26

  • POD/Host communication as required by PHILA.

  • SNMP as specified in IETF RFC 1157.

13.3.4 Application Model

The 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 Applications

Unbound 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 Signaling

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

  • XAIT XML file, loaded during the bootstrap sequence, whose format is defined in a DTD.

  • Registrar APIs enabling the monitor application to create unbound applications.

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 Upgrades

To 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 Control

Each 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 Launch

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

  1. If there is an abstract service with an autostart application and the application can pass the validation mechanism for launching, then create one service context per abstract service. This is done using the javax.tv.service.selection API.

  2. Create the abstract service in the service context constructed in step 1. Use the method AbstractServiceCreator.createAbstractService() . If the abstract service creation is successful, it appears in the list of available services returned by SIManager.filterServices() . This list is valid when SIManager.filterServices() is passed an instance of ServiceTypeFilter constructed with OCAP_ABSTRACT_SERVICE or when SIManager.filterServices() is passed null to list all services.

  3. Register all autostart applications with the application manager using the method AppResitrar.registerApp() specifying which abstract service they are bound to.

  4. Either the monitor application or executive module launches autostart applications within each abstract service. The launch order is based on a launch sequence number associated with each application via the launchOrder attribute defined in the XAIT file.

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 Applications

The 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 Applications

OCAP 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 Security

Accurately 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 Access

OCAP 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 Responsibilities

OCAP 1.0 extends the MHP application manager's functional responsibilities as follows:

  • Resolve resource contention with the monitor application.

  • Store unbound application information in the applications database (e.g., name , state, priority).

  • Terminate unbound applications.

  • Use the application filter to validate applications.

13.3.4.11 Application Priority

A 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

Priority Range

Application Type

255

Monitor Application

128254

System Application

64127

Reserved

163

User Application

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)

Element

Attributes

Children

Description

XAIT

 

routing , service

The root element of the XAIT XML file.

routing

sourceID , tsid , ipver

route

Defines the portion of the document that lists the IP routing relations between IP addresses and MPEG-2 elementary streams.

route

componentTag address , port , mask

 

Defines a particular link between an IP address and certain MPEG-2 elementary stream.

service

version , serviceID

application

Defines an abstract service and provides the current version and its identifier.

application

version , lorder , type , monitor , priority , control , visibility

identifier , transport , access

Defines an unbound application.

identifier

 

title , appid , appdomain , icon

Specifies identification parameters for applications.

transport

protocol , sourceID , componentTag , alignment , uhttp , IPMaddress , tsid

url , proxy , DIIlocation , prefetch

This element defines the different transport protocols that may be used to carry unbound applications. It is similar to its AIT counterpart .

access

 

parameters , classPathExt , baseDir , url , initialClass , appIDvalues , initialPath , physicalRoot , label expression

This element identifies the portion of the document that defines access parameters necessary to run an application.

title

xml:lang

 

This element encloses text that defines the title of an application. The language encoding follows the rules defined in RFC 1766.

appID

applicationID , organizationID

 

This element provides the same functionality as the application identifier field in the AIT.

appDomain

domain

 

This element specifies a domain name that may be used instead of (or jointly with) applicationID and organizationID .

icon

locator , flags

url

This element provides the same functionality as the AIT application icons descriptor.

url

   

This element encapsulates text that defines a URL that complies with RFC 2396.

proxy

   

This element specifies the proxy server in dot-separated IP address notation.

DIIlocation

diiID , associationTag

 

This element provides similar functionality to the DII location descriptor of the AIT.

preFetch

module priority

 

This element provides similar functionality to the AIT prefetch descriptor.

appIDvalues

 

PCData containing a list of applicaionID values

This element contains text listing applicationID values that are applicable to ocap-html applications.

baseDir

   

This element specifies the base directory for OCAP applications.

boundExpression

   

This element encapsulates text that defines an expression for the boundaries of ocap-html applications. This element mirrors similar functionality that exists in the application boundary descriptor in the AIT.

boundLabel

   

This element defines a label for the boundaries of ocap-html applications; see the AIT application boundary descriptor.

classPathExt

   

This element defines the classpath extension for OCAP applications.

initialClass

   

This element defines the initial class for OCAP applications.

initialPath

   

This element encapsulates text that defines the initial path of ocap-html applications.

parameters

   

This element defines the start parameters passed to an application for running. The dvb-j and dvb-html application descriptors in the AIT define the meaning of this field.

physicalRoot

   

This element defines the physical root for ocap-html applications.

Table 13.12. The Format of the XAIT Descriptor Placed in the Virtual Channel Table

Field

Value

Description

OCAP_XAIT_descriptor() {

 

descriptor_tag

0xAD

The unique tag for this descriptor.

 

descriptor_length

8 uimsbf

Number of bytes following this field.

 

location_id

8 uimsbf

XAIT file location (Table 13.13).

 

if (location_id == 01) {

   

source_id

16 uimsbf

Identifies the DVB-SI source ID.

   

component_tag

8 uimsbf

Elementary stream of the DSI of the Object Carousel carrying the XAIT.

   

file_path_length

8 uimsbf

Number of bytes in the file_path field.

   

for (j=0; j<file_path_length; j++) {

     

file_path__byte

8 uimsbf

Relative path in the Object Carousel.

   

}

 

} // f (location_id == 01)

 

if (location_id == 02)

   

source_id

16 uimsbf

Identifies the DVB-SI source ID.

   

alignment_indicator

1 bslbf

Indicates the alignment that exists between the bytes of the datagram_section and the transport stream bytes.

   

reserved_future_use

7 bslbf

 
   

URL_length

8 uimsbf

Number of bytes in the URL.

   

for (j=0; j<URL_length; j++) {

     

URL_byte

8 uimsbf

A URL conforming to IETF RFC 2396.

   

}

 

} // if (location_id == 02)

 

if (location_id == 03) {

   

URL_length

8 uimsbf

Number of bytes in the URL.

   

for (j=0; j<URL_length; j++) {

     

URL_byte

8 uimsbf

A URL conforming to IETF RFC 2396.

   

}

 

}

 

if (location_id == 04) {

   

XML_length

8 uimsbf

Number of bytes in the XML file.

   

for (i=0; i<XML_length; i++) {

     

XML_byte

8 uimsbf

XAIT XML file content.

   

}

 

} // if (location_id == 04)

} // OCAP_XAIT_descriptor()

Table 13.13. Values for the location_id Field

Location_id Value

Description

0x00

Reserved

0x01

DVB-MHP Object Carousel

0x02

IP via MPEG multiprotocol encapsulation

0x03

IP two-way Interactive channel

0x04

Embedded XML, contained in the descriptor itself

0x05-0xFF

Reserved



ITV Handbook. Technologies and Standards
ITV Handbook: Technologies and Standards
ISBN: 0131003127
EAN: 2147483647
Year: 2003
Pages: 170

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net