Just like DVB developed MHP as a common platform for interactive TV, organisations in the US also decided to develop a common interactive TV platform. One of the first organisations to start this work was CableLabs, a non-profit organisation set up by the US cable industry to develop common standards for cable TV systems. While standards from CableLabs are maybe not as far-reaching as DVB’s standards (mainly because the role filled by DVB in Europe is split between CableLabs and ATSC), they play a valuable part in the industry.
CableLabs originally developed the OpenCable family of standards to provide a common basis for digital cable TV systems in the US, although it doesn’t mention interactivity at all. For this reason, a new standard – the OpenCable Application Platform or OCAP – was developed. At the time, MHP was already well under development and rather than reinvent the wheel CableLabs decided to re-use elements of the MHP standard where it was appropriate.
Having standards that are so closely harmonised (and the ACAP and ARIB B23 standards are also aligned with MHP and OCAP) is good news for most of the industry, of course. The same economies of scale that apply to MHP over proprietary standards now apply to all of the related standards. STB manufacturers can produce a single STB with comparatively minor differences in middleware, and application developers can build applications that support both platforms.
When is version 1.0 not the same as version 1.0?
OCAP specification numbering may not be very clear if you are unfamiliar with it. OCAP defines two profiles – the OCAP 1.0 profile (which is the baseline OCAP specification) and the OCAP 2.0 profile which adds support for HTML applications.
Each of these two profiles may have several versions, identified by the specification number that can be found on the cover of the specification. At the time of writing, the specification number for the current version of the OCAP 1.0 profile is OC-SP-OCAP1.0-I15-050415. This identifies the OCAP 1.0 profile, version I15, published on April 14th 2005. Versions of the specification are usually referred to as ‘version I15’ or ‘version I14’ rather than by the profile number.
The OCAP 2.0 profile remains at version I01, while version I02 of the OCAP DVR specification is the most recent one.
The relationship between MHP, OCAP and ACAP
While much of OCAP is based on MHP (and indeed, the OCAP standard is mainly a document that explains which parts of the MHP standard are not used and what replaces them), there are some significant differences. Since US operators don’t use DVB standards, there is obviously no place for those parts of MHP which are specific to DVB systems such as the DVB SI API. US cable networks are run in a slightly different way to networks in other parts of the world, which also has on effect on how the STB is controlled and the relationship between the STB and the head-end. We’ll examine these differences in more detail later in this tutorial.
Although MHP is based on OCAP, the way that OCAP refers to MHP is sometimes confusing. Originally, OCAP was based on version 1.0.0 of the MHP specification. Since then, DVB released the Globally Executable MHP (GEM) specification to make it easier to use elements of MHP in other specifications. Recent versions of the OCAP specification use GEM instead of MHP as the foundation.
To make matters more complex, OCAP also refers to elements of MHP that are not included in the GEM specification. This means that it refers to some elements of MHP via GEM (which may impose some restrictions on certain APIs) while referring to other elements directly.
To confuse things even further, ATSC have recently announced the Advanced Common Application Platform (ACAP). This is supposed to be a common basis for all interactive TV systems in the US, be they cable, satellite or terrestrial. This is also based on GEM, and adds some elements from OCAP that are appropriate for the US market. Although it’s supposed to be a common bases for all iTV systems, OCAP does not currently refer to it and so there may be differences between the two standards. Exactly how these two standards will converge is not clear yet, and so it’s very much a case of caveat developer for the moment. There are a number of political issues that need clearing up before this can really be answered, and of course the FCC may decide to solve these political issues itself rather than waiting for OpenCable and ATSC to solve them on their own. Interesting times indeed…
A word about standards
In several parts of the OCAP specification, the standard SCTE DVS 234r2 is mentioned. This is now known as ANSI/SCTE 65, and while the OCAP specification specifically refers to SCTE DVS 234r2 the newer standard is probably mostly correct (checking this out costs money, and so unless someone’s willing to donate a copy of the exact reference, I won’t be able to do it).
Another advantage is that you can download ANSI/SCTE 65 free of charge from the Society of Cable Telecommunications Engineers – ATSC will charge you $50 for the same document.