Maybe this has happened to you (and if it hasn’t, it will). You’re talking to someone about what it takes to do an OpenCable Applications Platform launch. You’re pretty sure you were paying attention the whole time. But the next thing you know, the conversation has swerved into the July 1, 2007, deadline that bans operators from deploying digital set-top boxes with embedded security.
Or vice versa: You’re talking to someone about what it takes to meet the July 2007 separable security deadline. Within three sentences, you’ve careened into OCAP.
Here’s an example from my notes of a technical session at the recent SCTE Cable Tec Expo: “Some initial steps in getting ready to support leased boxes with CableCARDs involved understanding the headend upgrades needed for OCAP.”
What does a deadline for digital-cable boxes equipped with CableCARD slots have to do with a promise to the Federal Communications Commission that a middleware layer would start rolling out this year, and continue over the next two or so years?
The range of responses I got to this query, over the past few weeks, perhaps shows how confusing it gets when technology and policy collide.
Here’s a sampling:
“What happened was, as the [July ’07] deadline got closer, people got used to saying that OCAP is a requirement. It’s not. It’s a social requirement.”
“We must provide separable security, and everyone I’ve talked to has chosen to use OCAP as the method for doing that.”
“You need an OCAP environment to run DCAS [downloadable conditional access systems].”
Boil it down, and it’s sort of like when you’re planning a major project that will take two years — but part of it has to be ready next summer. The part that unfolds over two years impacts the part that’s due next summer, so you might as cram both into the short-term to-do list.
TWO DEADLINES COMING
There are two federal deadlines at work here.
One is self-imposed: Three months from now, in October, cable’s larger operators will begin deploying network support for a handful of systems to run OCAP, just as they promised the FCC they’d do.
They made this pledge to show their unity around one middleware platform for cable-specific hardware and services. (OCAP brings the “and services” part.)
The second deadline is FCC-imposed. It stipulates that by next July, multichannel video providers — that means telcos, too, so watch for exemption requests — can no longer deploy digital boxes with embedded security.
Instead, they need to deploy boxes that use separable security — meaning boxes equipped with a CableCARD slot, for now, until DCAS is ready.
The two seemingly unrelated projects come together where all major video technology efforts begin: In the headend gear.
Headend units need a software upgrade to do OCAP, and they need a software upgrade to enable renewable security on two-way, digital-cable ready units (boxes or TVs).
And it turns out that those two software tasks will emerge in the same major software release. So that, in part, is why OCAP and separable security travel as a pack.
GEARING UP FOR OCAP
There are two camps, when it comes to discussing OCAP field preparations.
The first camp holds the “no problem, minor, don’t worry about it” people.
The second group, which usually involves those already getting test labs ready, is more serious about the challenge. They describe it as a series of steps.
First, as noted, is a software update to the headend controllers that manage and distribute digital video to receiving devices.
In Motorola Inc. speak, they’re called “DAC,” for “Digital Addressable Controller.” In Scientific Atlanta Inc.’s lingo, they go by “DNCS,” for “Digital Network Control System.”
In practice, they work very differently, but as a generalization, they tackle the same tasks.
(Muddying step one for some operators, namely Comcast Corp. and Time Warner Cable, is the addition of the forthcoming Adelphia Communications Corp. systems into their mix. Comcast, which was 90-ish percent Motorola, becomes 25-ish percent Scientific Atlanta. Time Warner, which, in its digital video deployments uses mostly SA or SA clones, widens its Motorola properties to about a quarter to a third of its total footprint. This means both operators need to bulk up on human resources necessary to understand and ready “the other system.”)
The remaining steps vary fairly significantly from one system (Motorola) to the next (Scientific Atlanta), and as such will be covered in a later column.
All the while, none of the OCAP preparations can disrupt the operations of the legacy devices, already in the field, and incapable, from a resources perspective, of running OCAP.
The good news is, I haven’t yet heard anyone wearily describe the effort as a disaster in the making, or anything equally draconian.
If nothing else, expect to hear a lot more talk about OCAP, squished together with the separable security, as the year advances.
Stumped by gibberish? Visit Leslie Ellis at www.translation-please.com.