The flexibility to execute in multiple network environments is key

With the recent FCC mandate for separable security in full force, all in the industry are fully aware set-tops must now be deployed with CableCARDs (with the exception of the small handful of operators with rare FCC waivers). But that doesn’t mean the situation is entirely clear.

There remains some confusion as to the connection of today’s current environment – the “native” environment – with tomorrow’s OpenCable environment, encompassing the OpenCable Application Platform (aka OCAP) software environment. There certainly isn’t much clarity on when and how an operator should change from one to the other.

Having to deploy CableCARDs does not dictate an immediate move to OpenCable. But that leaves open a set of questions about the requirements for entirely new software stacks, electronic program guides (EPGs), video-on-demand (VOD) client applications, network servers, carousels, DOCSIS Set-top Gateway (DSG) infrastructure, and in some cases, new set-tops.

Although most of these changes are necessary for OpenCable set-top deployments, the CableCARD does not force all of these changes.

Figure 1
Figure 1: Operating modes via software download.

Transition complexity
Cable operators have made a tremendous investment in today’s cable infrastructure. Currently, set-tops have security integrated; the FCC mandate requires that new CableCARD set-tops work in today’s environments, but does not require a transition to OpenCable.

CableCARD set-tops that do not run OCAP, that still work in native environments, are best termed native hosts. Native host devices that run in existing networks represent a first stepping stone for a gradual transition to OpenCable. Most set-tops in this class follow CableLabs’ OpenCable Host (OCH 2.0) specifications, and are able to execute the OCAP software stack.

Although it is important to transition to future technology initiatives like OCH/OCAP, many cable operators are taking a systematic and methodical approach in adopting such changes.

For example, there is no question the benefits of DSG, which makes use of the data channel for two-way communication between the set-top and the headend, far outweigh the out-of-band (OOB) return path traditionally used. Yet, switching over from OOB to DSG is quite a challenge - both logistically and financially - for the operator.

Now add in the new infrastructure necessary to support the transition to OpenCable, new host software (e.g. OCAP), and new applications (e.g. Java environment), and it becomes clear that doing the whole transition to OCAP in one shot is an overwhelming task for even the largest of operators.

Protecting the investment
To find the optimal transition strategy, consider starting at the end of the delivery-chain and working upstream. In cable, the set-top can be the starting point and catalyst for change upstream.

The CableCARD helped open the door for an influx of set-top suppliers. Many of them targeted the market based on the assumption that their customers will have made the transition to the OpenCable Platform, or that upon deploying their set-tops, their customers will immediately make the transition – a “flash cut” change.

Experience suggests the flash cut approach of a total and complete switch-over to OpenCable environments can be fraught with peril.

Pace is convinced the best approach for supporting operators is to support the option of a gradual transition. That means building CableCARD platforms with the flexibility to execute in native or OCH execution modes, thus easing the transition for the operator while also providing a choice of operating modes.

Selecting set-tops
Because the most sensible and safest transition is a gradual one, the best choice of platforms would be those that can operate in either environment – like a dual personality. From a set-top vendor perspective, one way to accomplish this is to (a) design the set-top hardware with this goal from the start, and (b) allow for the set-top to accept an over-the-cable software download of either software image necessary to execute in native or OpenCable environments.

Many set-tops today (even some of the newer ones) do not have this dual personality; thus, the operator has no way to transition from native to OpenCable via over-the-cable software downloads. Many of the older legacy set-tops are not designed for OCH mode. Some of the new-to-market set-tops can only execute in the OCH mode because they were not designed to have this dual personality; thus, to deploy these set-tops, all of the infrastructure must be in place and operationally bug-free.

Figure 2
Figure 2: The flexible transition environment.

In addition to the benefit of being able to flip from one set-top operating environment to the next, these flexible platforms also provide expense relief for the operators because no new set-top investments are needed for OCH transitions, which leads to additional savings from not having to do truck rolls to swap out native set-tops.

Certain technologies are prerequisites for operating in either native or OCH environments. For native set-tops, the platform must have an out-of-band (OOB) tuner with a QPSK demodulator for downstream communication, and an upstream QPSK modulator for the return path.

Intelligent software is then required to allow the set-top to utilize this OOB hardware such that either the DVS-178 or DVS-167 message protocol is followed to achieve two-way communication.

Furthermore, Motorola and Scientific Atlanta (Cisco) networks each have additional messaging requirements to process specific network and conditional access messages; thus, the set-top must be able to process these messages as well.

Native mode also has specific software requirements at the application level where there are specific EPG and VOD clients that must be ported to the set-top to complete the set-top’s native software execution image.

For OpenCable environments, the set-top must be designed to adopt the technologies that are spelled out in the OCH hardware specifications. Such additional technologies include DSG as another mechanism for two-way communication (in place of the OOB communication used in native mode).

As mentioned earlier, DSG offers superior bandwidth and communication advantages, yet the benefits come with a cost of incorporating a DOCSIS cable modem, additional memory, an additional tuner and a 16-QAM modulator. Similarly, the overall OCH platform must have more memory and CPU processing capability (as opposed to native execution mode) to support the OpenCable software environment, which includes a Java Virtual Machine and Java applications.

Going a step further, a flexible set-top design should also include an intermediate step to OpenCable with the ability to again flip execution environments – this time, to an On-Ramp environment. Some in the industry refer to On-Ramp as a stepping stone to OpenCable, as it has many attributes of the OpenCable software requirements, yet with some concessions to allow less-capable platforms to retain the look-and-feel of the same applications executing on OCH platforms. Here again, it’s about providing choice to operators of which environment they wish to execute without the set-top dictating the way.

One can start to see that supporting a dual-personality platform requires much upfront set-top design and not an after-thought of loading a new software image on the set-top. These are just some of the concepts operators must consider when making their set-top selection.

Set-top vendors must have design philosophies where they provide the operator with flexibility and choice – it’s the best contingency plan an operator can have. And given today’s changing environments, operators can take comfort in knowing their set-tops have what it takes to be a catalyst for future change regardless of its timing and direction. Flexible equipment suitable for any contingency is the basis for a solid return on investment. And that is what makes a win-win situation for both operators and set-top vendors.