Dr. Dobb's Journal June, 2004
For years, North American cable operators have been enslaved by closed networks and proprietary APIs. Fortunately, U.S. cable vendors believe that the OpenCable Application Platform (OCAP) will emancipate them from their dependence on closed technology. OCAP not only leverages Java-based APIs and uses open networking standards, but also promises to foster competition and reduce costs. In this article, I examine why OCAP is a massive improvement over proprietary solutions and delve into the OCAP architecture. In a follow-up article, I'll show how you can use Java to exploit the capabilities of OCAP-based set-top boxes that soon will be connected to High-Definition TVs.
In this age of open-source software, you'd probably be shocked to hear that the U.S. cable market is mired in a proprietary quagmire. For a variety of reasons, the closed nature of U.S. cable platforms arose by necessity, not necessarily by the design. To explain: Cable vendors were eager to transition from analog to digital networks. As a result, they selected proprietary solutions from either General Instruments (later bought by Motorola) or Scientific Atlanta because these products were the quickest means of completing this transition. Once deployed, these networks became so entrenched that it is now very costly for cable providers to switch to open architectures.
There are two core aspects to any closed cable solution—Conditional Access (CA) and software APIs. CA is the technology that encrypts and secures content. DigiCipher II is the CA for Motorola platforms and PowerKEY is used in Scientific Atlanta environments. Given that such technology is constantly under siege by pirates, it is doubtful that CA technology will ever be based on an open standard.
Besides CA, closed solutions utilize proprietary APIs that are tailored for the embedded cable market and tightly coupled to the CA. While this may result in efficient software, the development environment is breathtakingly expensive. Consequently, there aren't hordes of software vendors competing in this arena.
While the American cable market was entangled in a web of proprietary solutions, Europeans developed ambitious plans to incorporate Internet and Java-based standards into their digital television products for cable, satellite, and terrestrial (off-air) markets.
This effort, called the "Multimedia Home Platform" (MHP), was spearheaded by the Digital Video Broadcasting Project and eventually adopted as a standard by the European Telecommunications Standards Institute. The core of MHP is a Java Virtual Machine and Java-based subsystems such as AWT, JavaTV, and Java Media Framework. These Java APIs leverage MPEG-2 for digital video and Digital Storage Media for Command and Control for file I/O, plus they offer custom interfaces for the interactive TV market. Since the Java APIs in MHP let applications access low-level multimedia drivers in a device-independent manner, it is categorized as "middleware" (that is, software that acts as a conduit to digital video features and functionality); see Figure 1.
Although MHP middleware was oozing with potential, skeptics noted that the processing requirements of the platform would make the machines too expensive to deploy. However, while MHP machines may not have been cost-effective in 2001, these concerns have evaporated due to the stunning advances in embedded hardware. Today's 32-bit embedded processors not only offer more MIPS, but are capable of running advanced operating systems (such as Linux).
During this same timeframe, CableLabs (a consortium sponsored by leading American cable companies; see http://www .cablelabs.com/) was given the charter to create OpenCable. This charter is threefold:
To achieve these goals, CableLabs published a series of specifications. While most of these specifications are U.S. centric, CableLabs realized that most MHPs could be reused in OCAP's mission to provide a middleware API that is operating system, hardware, and network neutral. Like MHP, OCAP revolves around a JVM and Java APIs. However, many Java classes have been enhanced with U.S.-specific functionality.
The most noticeable architectural difference between MHP and OCAP is the Conditional Access infrastructure. In OpenCable, CA is done via the CableCARD. Traditional CA technologies like PowerKey and Digicipher II are closely integrated with cable set-top boxes for security purposes. As a result, it's impossible to deploy a Scientific Atlanta set-top box on a Motorola network. By contrast, each CableCARD is a self-contained Conditional Access subsystem in a PCMCIA form factor—you simply insert it into the cable card slot in the set-top box and the CableCARD handles CA processing. Since CableCARD-compatible set-tops aren't bound to a proprietary CA technology, these set-top boxes can be sold anywhere in the U.S.—one of the major goals of OCAP/OpenCable.
OCAP also differs from MHP in its use of a monitor application. In MHP, applications are launched and terminated based on the services (or network video features) that they are manipulating. If multiple applications try to simultaneously access a resource like a video tuner, MHP uses a priority-based arbitration scheme to resolve the conflict (the resource is granted to the higher priority application).
Due to the complexities of the American cable environment, OCAP has enhanced MHP's priority-based approach with a monitor. This monitor architecture consists of two layers (see Figure 2). The lower layer contains privileged APIs to handle resource conflicts, respond to emergency messages, and manipulate the CableCARD.
The upper portion of the architecture is the monitor application and other applications that have been authorized to access monitor functionality. This application is specific to the Multiple Service Operator (MSO) and tailored to its particular requirements (MSO roughly equates to a cable company). For instance, one cable vendor's monitor application may grant video-on-demand applications higher priority when resource conflicts occur because video-on-demand apps generate more revenue for that MSO. By contrast, another MSO may grant preferential treatment to interactive games because their clientele demands it.
If the MSO declines to write a custom monitor application, the lower-level privileged APIs default to a priority-based resource management scheme. However, this default scheme may not be adequate for the intricate environment that a particular MSO must serve. For instance, FCC Rule 47 requires that captions and emergency alerts always be visible and not overlap each other. A simple MHP-like priority-based resource sharing algorithm may not comply with such rigorous requirements.
Another reason to implement a monitor is to prevent rogue applications from running on the MSO network. A robust monitor rejects attempts by intruders to load unauthorized applications onto the set-top box. While this has the side effect of preventing you from trying your favorite Java apps on your cable set-top box, it stops intruders from creating havoc on specific boxes or even bringing down the network.
A third fundamental difference between OCAP and MHP involves application capabilities. Java applications that conform to MHP requirements are referred to as "MHP-J," whereas OCAP-compliant applications are labeled "OCAP-J." Both middleware platforms have rigorous certification requirements and are finicky about which applications are considered compliant (for instance, while your PC-based Java Media Framework application may theoretically run on a particular OCAP middleware platform, it probably uses classes and interfaces not available on all OCAP systems and, therefore, can't earn the OCAP-J moniker).
In MHP, applications are bound to a particular channel (or service). A service describes content available for a particular stream and it may encompass more than just digital video (it could be an interactive game stream, for instance). When you tune away from that channel, the application associated with the service dies.
By contrast, OCAP applications may be bound or unbound. Bound applications are identical to MHP, while unbound applications may persist across channel changes. The most powerful unbound OCAP application is the monitor. It is created during the OCAP boot process and manages systems resources until the machine reboots or is powered down.
OCAP relies on the Extended Application Information Table (XAIT) to manage application lifecycle and facilitate communication with unbound applications. XAIT is similar in concept to MHP's Application Information Table (AIT). MHP's AIT is transmitted in an MPEG-2 transport stream (see Table 1). The presence of the AIT signals (or alerts) the set-top when it should launch or terminate an application. Furthermore, the AIT tells it where to find the application and what data the application requires to operate.
Because AIT information is transmitted in-band (in the MPEG-2 transport stream), it isn't viable for unbound applications because the content of the MPEG-2 stream changes between services. Consequently, XAIT is signaled to an unbound application via the Extended Channel MPEG Section flow (or out of band). Out-of-band communication is not tied to a particular service and enables the cable headend to communicate with unbound applications regardless of which in-band service is active (see Figure 3).
Besides the use of out-of-band communication, XAIT also introduces the concept of an Abstract Service. An Abstract Service is a logical grouping of related unbound applications (an office suite or a game trilogy, for instance) and offers a convenient means of signaling categories of applications rather than sequentially signaling individual signals to multiple applications. To accommodate new features such as XAIT and Abstract Services, OCAP has defined several new descriptors for the Extended Channel MPEG Section flow (see Table 2).
The creation of unbound applications also forced OCAP architects to enhance the MHP resource management schemes. In the MHP world, service providers control application lifecycles. Consequently, they know beforehand what resources each application requires and can minimize potential resource conflicts. By contrast, the unbound application concept greatly complicates resource management. To explain, an MSO may permit users to load custom unbound applications on their personal set-top box. In this scenario, the MSO can't know what resource(s) the unbound application is utilizing. Therefore, a resource management handler (the monitor application or another monitor class application, for instance) is required to arbitrate scarce resources such as the TV tuner or graphics display.
Both the CableCARD and Monitor application are built on top of the OCAP Baseline (see Figure 4). The OCAP Baseline is a core set of features that you know will exist when you write your OCAP application. These features include:
As I pointed out in "Digital, Analog, and High-Definition TV" (DDJ, November 2002), the U.S. HDTV market is transitioning from analog component video outputs to digital interfaces such as DVI and 1394 (Firewire). One significant impediment to completing this transition has been security. Movie studios have been reluctant to release their content in HD format until they are guaranteed that it is protected from piracy. Consequently, OpenCable mandates the use of High Bandwidth Digital Content Protection (HDCP) for DVI and Digital Transmission Content Protection (DTCP) for Firewire.
Since Europeans aren't in the midst of an HDTV transition, MHP has no explicit requirements for digital video interfaces. By contrast, in America, new HDTV cable and satellite boxes are essentially worthless without DVI and/or 1394 connectors. Therefore, OpenCable mandates 1394 and DVI outputs and provides an OCAP interface to control these digital interfaces.
These OCAP interfaces give you basic controls to manipulate DVI and 1394 devices. For example, you can enable/disable the DVI port and query the HDCP capabilities of a display. Similarly, the 1394 Java classes let you determine if a device is DTCP capable. Furthermore, you can use these classes to select which 1394 device (a display, Digital VHS, or whatever) receives the video output from the set-top box.
While OCAP is a big improvement over the closed, proprietary solutions that currently dominate the existing American cable environment, it does have some minor flaws. For instance, because video-on-demand and pay-per-view are the primary generators of incremental revenue for cable operators, software developers will naturally gravitate to these areas. Alas, the first revision of OCAP shuns the topic of video-on-demand and pay-per-view, relying on each MSO to provide proprietary APIs for their respective networks. Consequently, you can't write a single OCAP-J video-on-demand binary that runs anywhere in North America. Rather, you must individually tweak it for each MSO.
Despite these warts, OCAP has provided a solid platform for transitioning the U.S. cable market from the closed, proprietary world to an open, standards-based architecture of Java-based applications that can leverage the capabilities of CableCARD, 1394 and DVI. Over the next several months, you will see a gradual shift from proprietary technology to OCAP-capable cable boxes.
DDJ