Chris Bowick, a native Atlantan, is back at home these
days. Earlier this year, the former chief technical officer for Jones Intercable Inc. left
the Mile High City, opting to sign on with Cox Communications Inc. as vice president of
technology development. Under his watch is Cox's digital-video rollout, which differs
from those of other MSOs. Plus, Bowick is Cox's official "OpenCable guy,"
which even he acknowledged to be no easy task. Leslie Ellis, senior technology editor for Multichannel
News, conducted a telephone briefing with Bowick recently. An edited transcript
MCN: Cox is taking a different tack on digital rollouts
than other affiliates of Tele-Communications Inc.'s Headend in the Sky digital-video
feed. You're opting to do your own signal control and access, instead of buying that
service from TCI. How is that going?
Bowick: It brings a lot of its own interesting and very
complex problems. Local control has not been simple.
MCN: If you were to use national control, HITS would not
only send you the compressed tiers of programs, but it would also encrypt the stuff that
needs to be encrypted and handle the conditional-access portion, so that only those people
who pay for it get it. And all of that is unwrapped and unbundled at the set top, right?
Bowick: Right. With national control, of course,
you've got a central facility handling everything nationally, for multiple MSOs. Keep
in mind that we're collecting programming from various sources, and not just from
HITS. We do have some direct feeds from various programmers. We've got some
Viewer's Choice feeds that will be coming off HITS sometime soon.
MCN: The end of October, I think they said.
Bowick: Right. And of course, we also have HITS, and we
mix and match those.
MCN: And you do your own security, essentially. Is that on
a headend-by-headend basis?
Bowick: When you're dealing with local control, if
there are issues associated with software-revision levels, or headend interfaces between
the digital addressable controller and the OMs [operations management], the IRTs
[integrated receiver/transcoders], etcetera, then all of those issues get replicated from
system from system. We're replicating [access and control techniques] in each of our
MCN: How do you do it?
Bowick: Well, it works by means of a local addressable
control -- either a digital addressable controller from GI [General Instrument Corp.], or
what's called the DNCS [Digital Network Control System] from Scientific-Atlanta
[Inc.]. We're rolling out both in different markets.
MCN: What are the challenges associated with that?
Bowick: First, you have to have individuals at your
headend facilities who are well-versed in local-area networking, Ethernet and data in
general. It requires a level of complexity in the headend -- both for our people and in
the electronics itself -- that we haven't seen in the industry to date. It does
require a lot of training for our headend people, for our field-service personnel and for
our customer-service representatives.
MCN: All of that said, why did Cox opt to go that route?
Bowick: I wasn't here when the decisions were
made, so I really can't tell you. I do know that we prefer to be in control of our
own destiny, to a degree. Early on, one of the thoughts was that as we move toward more
advanced services, it would give us a better platform from which to launch and control our
MCN: You mentioned the need for training, in terms of
Ethernet and LANs, for headend techs. Why is that?
Bowick: If you take a look at the headend block diagram
now, the headend is no longer a set of independent, interconnected analog components. The
headend, at least from a digital perspective, is now a local-area network that is
interconnected on an Ethernet LAN.
In other words, the digital addressable controller is
connected via Ethernet to the IRTs, the out-of-band modulators, the add-drop multiplexers
and so on. They're all interconnected, and they all talk with each other constantly.
So, from a maintenance and repair standpoint, it takes an
individual who is well-versed on the digital aspects of things. It's a completely
different set of training requirements for us.
MCN: Given your deep history with headends, how different
are things in the headend these days?
Bowick: Very different. I've heard people long for
the good old days, when everything wasn't interconnected. When something failed, you
knew exactly what is was, and you could trace it down very easily.
It's a much more intricate, complicated
troubleshooting process today, because you don't necessarily know what is out of
communication at any given time.
I'm talking about more of the in-depth
protocol-discussion issues that come up from unit to unit. So it requires a lot of
training on local-area-network fundamentals and things like that.
The headend may be more complex, but it's also one
heck of a lot more flexible, in the long term. The difficulty that we face right now is
that we're on the leading edge. All of us MSOs are. And we are seeing continual
upgrades in software.
Keep in mind that each one of these components that
I'm talking about in the headend has its own software within it. And each one can be
revved --- and by that, I mean that you go to a new software revision -- individually.
MCN: Which could wreak havoc on the next component.
Bowick: Exactly. What you have to do is, before you
allow a vendor to hand you a software load and say, 'All is well. Here's your
new software. We're going to upload it to you tonight,' you have to see for
MCN: You're doing that?
Bowick: We have a system-verification and test facility
up in Windber, Pa. We run these new software patches through our facility there, looking
for bugs in the overall system.
[GI and S-A], of course, do that in their own labs, so this
is really just another gate to jump through before we allow these new software revs into
Because once you're live, with x-thousands of
customers on a digital platform, and you rev a given component ... if there is a problem
with that load of software, then you've got live customers that could possibly be
affected. We want to try to thwart that.
MCN: Has that happened? Did you open the Windber facility
out of personal experience?
Bowick: Oh, of course. As you launch any new product
like this, you're going to see situations where a software bug has affected a
customer. We've seen some situations like that. We're just trying to minimize
that impact as much as we possibly can.
MCN: From what you've seen so far with digital-video
rollouts at Cox, what's the one thing that just made you want to thump your head
against the wall?
Bowick: It's got to be software bugs. There's
an old axiom in the R&D [research-and-development] industry: Software is always 99
percent complete. Meaning that it's never done. We have seen, on occasion, software
bugs that have just driven us crazy, from an operational perspective. That's driven
us crazy the most. So, we're trying to be bug-finders.
MCN: Let's move on to OpenCable. What's your role
Bowick: Two things: I'm on an internal Cox team
and the OpenCable technical team that is external to Cox.
MCN: Doing what, in each?
Bowick: Internally, we're trying to understand
what OpenCable means to us in the long term. We've made the decision to launch the
current GI platform and the current S-A platform.
At some point in the future, we'll have some number of
those units out in the field. Then we want to make sure that we have a decent transition
strategy from where we'll be at that time to an OpenCable platform. And we certainly
would not want the platforms that we have in place to be obsolete, nor do we believe that
MCN: What does Cox want out of OpenCable?
Bowick: We want interoperability, meaning multiple
vendors within a system, wherever possible. We want affordability. That certainly includes
the retail availability of OpenCable-related widgets.
MCN: Status report, from the Cox point of view?
Bowick: We're pretty early in the defining stages
of strategy for OpenCable. But the timeline for OpenCable really spans from now to
mid-2000 or the third quarter of 2000.
We're where we need to be at this point in time, and
we're giving it some very serious thought. We have a multiple-discipline group within
Cox, consisting of business, finance, technical, marketing and so on, and together,
we're really giving it a hard look.
MCN: Along what parameters?
Bowick: What's going on in the industry, what are
the alliances being formed, who's doing what out there from the other MSOs'
perspective, what is the picture going to look like in two years for deployed digital
boxes, and what does that mean to us? What do we think the OpenCable architecture is going
to be? Because it's still an evolution right now.
We're trying to anticipate what that architecture is
truly going to be, and how it's going to wind up, and perhaps influence that, to a
degree. We're also trying to understand what the key drivers are going to be, from a
business standpoint. What major applications or features are we going to have, or do we
want to deploy, in the OpenCable arena?
MCN: It sounds like there are a lot of wrinkles that need
Bowick: There are more questions than answers, yes.
That's true of the entire OpenCable process. We still have a ways to go. We still
have a bunch of interfaces to more fully define. We hope to have the POD
[point-of-deployment] specification complete by year-end. That'll probably be voted
on in the SCTE [Society of Cable Telecommunications Engineers] in the next month or two.
But there are still a lot of interfaces under development.
MCN: You're confident that this won't get so
complicated that it will spin out of control?
Bowick: When you get a bunch of business, technical and
marketing people together to work out a major standard like this, you're going to
have bumps in the road. See, a lot of people think that OpenCable is a box. OpenCable is
not a box: It's defining an architecture, a brand and a process.
But the architecture is not just a box architecture:
It's an architecture that defines the interface between perhaps an OpenCable set-top
and consumer devices; between the OpenCable device and the POD; between the headend and
the OpenCable device; and between the headend and the network-operations center to look at
network status or telemetry information. Then you have to define the interface between the
headend and the programming arm. It's a very complex issue.