Monthly Archives: October 2000
“Integration Issues” – the goblins of interactive TV (and so many other things)
If nothing else was contributed to the technical lexicon this summer, it was one pair of words — “integration issues” — to describe the tortuously difficult work of getting interactive TV running.
What happened with AT&T Broadband, Microsoft, Motorola, Sun and TVGuide? Integration issues. Why did PowerTV buy integrator Presara Technologies? For experience in solving integration issues.
Some vendors learned about integration issues the hard way last year. Diva is one example: It discovered that it wasn’t enough to get a nod from Motorola to run VOD on its DCT-2000 box. It also had to hitch up to TVGuide, the primary resident application on most Motorola set-tops.
William Strunk Jr. would take one look at this word pairing, grimace, and handcuff it as a “refuge of vagueness.” Strunk and E. B. White (Strunk’s student, and later, co-author of “The Elements of Style“) had little time for abstruse descriptions.
Yet how else does one describe intangible complexities spanning technology, politics, and scheduling? “Integration issues” is a phrase here to stay. So let’s get specific about it. What does “integration issues” mean?
Integration issues are obstacles, usually in software, and usually related to making different types of software work cooperatively. Because it’s mostly software-related, an “integration issue” is not something you can pick up with your hands, examine, diagnose, and fix.
An example: The guide must be a good neighbor to other services like e-mail, Web-browsing and anything clickable. None can hog available processing power or memory. All have to harmoniously co-exist. One bad neighbor, and the box locks up. Having to tell the cable customer to recycle power on the box — to reboot — not good.
Integration issues are the reason interactive TV is so hard now. Think back to the mid’90s, when cable first started installing digital set-top boxes. Recall what those boxes did: Squeezed 10x or more channels into the space of one analog channel, and offered an electronic guide to help subscribers navigate. We didn’t hear much about integration issues then, because there wasn’t much software required.
Over the past five years, the digital boxes got beefier. Maybe this didn’t happen as quickly as some would like. I’m thinking of a keynote delivered to CTAM’s Broadband Opportunity Conference earlier this month by Jonathan Taplin, CEO of Intertainer. Taplin’s fervor was deliciously provocative: Evangalizing for faster digital set-top microprocessors that cost $45-$60 per box, he thumped incumbents Motorola and Scientific-Atlanta as “too cheap” to stay technologically current.
I played out Taplin’s request in my mind, and found myself feeling sorry for the poor chump who had to traipse in to corporate, hand outstretched, to request that silicon upgrade. For some MSOs, like AT&T Broadband and Time Warner, adding $45-$60 more per box sums to around $100 mil. in unanticipated, incremental cost — each — based on ’01 set-top order levels.
The ants in Taplin’s pants are understandable, and I commend his swashbuckling insistance on better chips. More is better, true. The problem is, more doesn’t happen overnight. The industry’s two biggest set-top makers, S-A and Motorola, are building about a million boxes each quarter. That’s a big ship to turn.
And it’s a ship that’s already turning. Look at the progression of what’s been under the hood of cable’s digital boxes. From the DCT-1000 and DCT-1200 in the mid’90s, to the DCT-2000, through to its advanced DCT-5000, Motorola increased processing power, memory, and graphics capabilities. Scientific-Atlanta did, too. Today, S-A’s Explorer 2010 boxes use a 130 MHz processor, and can be populated with double-digit RAM, in some cases as much as 50 Megabytes.
Seems like a long time since the big issue in the industry was whether or not to add another megabyte of memory — for a total of 2 Megabytes — to decode the b-frame portion of a TV picture compressed with MPEG-2. (That, too, was a $45/box decision. One megabyte of memory cost about as much back then. Cable did it, but added about a year to the digital launch timetable.)
More muscle under the hood of the digital boxes means lots more software. There’s the operating system, like Microsoft’s WinCE and PowerTV, needed to tell the chips what to do. There’s middleware on top of that (translated in in the October 2, 2000 edition of Multichannel News). And, there’s the applications: The guide, e-mail, web browsing, clickable ads, clickable content that correlates with the show that’s airing.
Part of “integration issues” are those individual software modules — the OS, the middleware, and the applications. Each has to run perfectly in isolation. Each also has to work perfectly with one another. That’s the technological to-do list comprising integration.
Integration also involves scheduling and organization. Take the case of AT&T Broadband, struggling to make an interactive TV business that runs on Motorola’s DCT-5000, loaded with Microsoft’s WinCE and Sun’s Java TV environment. Somebody had to know precisely where each partner was on the path to launch. Somebody had to mind the list of known bugs for each participant.
But what happens when that somebody is the customer – AT&T? Enter the politics portion of “integration issues.” It’s politically difficult (and I’m putting it mildly) to expose the number and location of your blemishes to your customer, no matter who you are, or what business you’re in.
Stitching together various pieces of software, under tight deadlines that involve competitors, is hard. We’ll be hearing about integration issues from now on, probably. That’s the bad news. The good news is, there are smart people working on it, and they learn more daily. This takes time. Try to respect the journey.
This column originally appeared in the Broadband Week section of Multichannel News
DOCSIS 1.1: What It Is, and What It Isn’t
With little fanfare, the first batch of DOCSIS 1.1-based cable modems entered CableLabs’ test queue late last month – the week after Diversity Week, to be exact. The testing milemarker seemed like a sensible-enough reason to translate what those boxes will and will not be able to do for cable.
There are three main areas where the new, 1.1-based modems differ from the millions of 1.0-based cable modems deployed in the U.S. as of June 30. Those three areas are Quality of Service [QoS], data fragmentation, and enhanced security.
Let’s look at quality of service first. It’s abbreviated “QoS,” and spoken “Q-oh-S.” [Some hard-core data people say it as a word: “kwoss.”] Really, QoS is the high-speed data equivalent of basic and premium TV differentiation. It lets you add “grades,” or “tiers,” of data services, characterized by speed or transit timeliness.
In today’s cable modems, MSOs generally cap the downstream (headend to home) and upstream (home to headend) speeds at the time of installation, or before. Technologists call this “rate limiting,” and use it to preserve bandwidth, which is especially precious in the upstream signal path.
As explained in the Sept. 18 edition of this column, bandwidth isn’t unlimited, and needs to be monitored carefully. Most MSOs set a maximum of between 1.5-2 Mbps downstream, and about 384 kbps upstream. It’s a best-effort thing: First come, first served. Last on, you get what you get. Usually, the capping works to ensure everyone gets speedy services.
With 1.1 and QoS, operators can vary maximum data rates, on the fly. Technologists call this “committed information rate,” meaning they can nail-up different data rates to different customers, depending on their needs (and willingness to pay).
Example: User Jane wants to watch a movie on her PC. She clicks to stream it. With QoS, the modem sees that Jane is streaming video, and pops her up to a sustained and higher bandwidth for a certain amount of time. If the equipment spoke, it’d say, “Oh, Jane’s watching a movie. I’ll fix her at 1.5 Mbps while she needs it.”
They can do this because DOCSIS 1.1 comes with 16 different “service identifiers,” or “SIDs” (pronounced “sihds”). SIDs are a way of striping packets that flow to and from a modem, to make each different and distinct from another.
There’s a second part to QoS, called “data fragmentation.” It helps services like voice, which are intrinsically isochronous. Isochronous is just a fancy way of saying “equally timed to and from destination, without delays.” Think of it this way: When you’re talking on the phone, it matters more that the packets get there without hiccups, than it does that they get there over a fat, dedicated pipe.
Think of it as the converse of e-mail. You write a note. You hit “send.” The note gets broken up into small pieces; oftentimes, the pieces are sent over different routes. It doesn’t matter, because everything gets reassembled at the other end. If one packet is a few milliseconds late, it’s not the end of the world. Your note still arrives.
Voice has to work differently. If a packet is a few seconds late, and you’re talking live, it’s the equivalent potential of you saying “This ridiculous is.”
What really matters in voice is that packets travel smoothly and without delays. That’s what the data fragmentation portion of DOCSIS 1.1 does.
The third thing DOCSIS 1.1 brings is better security — which is not to say that existing 1.0 gear is vulnerable. DOCSIS 1.0 uses what’s called “link layer” encryption to secure all communications between the cable modem and the headend. CableLabs licenses the technique from RSA, and it’s not yet been cracked in a cable modem environment.
DOCSIS 1.1 builds on that with a mililtary-grade type of encryption known as “triple DES” (pronounced “triple dehz”) – generally acknowledged to be impenetratable. Spies use triple-DES.
In addition to QoS and privacy, DOCSIS 1.1 is notable for one other reason: It’s the foundation for PacketCable. PacketCable, the third leg of CableLabs’ major project trio, is building up lots of other packet-style services, starting with lifeline telephony and streaming media.
DOCSIS 1.1 is not a cure-all for the myriad technical and operational issues comprising open access. While 1.1-based equipment does help, it isn’t the total answer. It helps because MSOs can use some of the SIDs to identify outside ISPs — although this usage is debated in engineering circles.
It’ll likely be another couple of testing rounds before CableLabs certifies any 1.1-based cable modems, or qualifies any 1.1-based headend gear (known as “Cable Modem Termination Systems,” or “CMTS.”) After that, upgrades begin.
Silicon suppliers and equipment suppliers have promised operators that they can shift from 1.0 to 1.1 with software downloads. However, some MSOs are already starting to wonder if that remains true should they want to provide “carrier class” telephony services. Going to carrier-class means a lot of software and systems in the back office (the stuff of PacketCable), and resolution of plant issues, like how to juice a modem/phone when utility power is out. Which requires a whole other set of translations…
This column originally appeared in the Broadband Week section of Multichannel News.
Middleware: Above the Operating System, Under the Apps
Middleware. A term so stretched with multiple meanings, it’s as shapeless as a wet sock.
Let’s start with the word itself. “Middle” means between. “Ware” is a shortcut to “software.” In the case of advanced digital set-tops, middleware is software that sits between the operating system, and the interactive applications above it.
Middleware is a bridge. It connects the hardware and its operating system to the ITV goodies. It wasn’t needed in early digital boxes, because those boxes did a limited number of things. They took a digital signal in, translated it back to analog, and sent it to the TV. They tuned channels. The most interactive thing was the electronic program guide.
To add chat, e-mail, clickable ads, and the rest ITV’s harvest, the boxes need more stuff. They still need an operating system, to tell the chips what to do: Tune this channel. Descramble that one. Get the guide. To do more than that, and in a non-proprietary way, they need that middleware bridge to the apps.
The term entered the cable lexicon around 1997. Remember when CableLabs escorted cable’s top CEOs around Seattle and Silicon Valley? That trip, organized to ascertain the Internet’s impact on set-tops, ultimately lightened Microsoft by $6 bil.: $1 bil to Comcast, and $5 bil. to AT&T, a few years later. (And that’s just the domestic investments.)
Yet Microsoft’s zeal in those ground zero days of set-top software is what prompted cable to start pondering control. It didn’t hurt that Navio, now Liberate (and Network Computer Inc., in between), was on the scene pitching a “middleware” alternative to Microsoft’s operating system.
From the beginning, cable wanted middleware for two reasons: Portability, and control. Portability to assuage the FCC’s mandate for retail set-tops. That means set-tops you can buy at a store, no matter who makes them, what operating system, or who scrambles premium channels. It also means that you can move to another city, served by another cable operator, take that box you bought with you, and it’ll still work.
Middleware control ensures that ITV apps writers came to cable for distribution, not an outside software company — like whomever produced the operating system. Plus, middleware is intrinsically based on open standards, say its proponents, theoretically speeding deployment and shunting proprietary locks.
Here’s why control is an issue. With or without middleware, applications providers — makers of games, email, chat, clickable ads — need to know how to write software that runs on various set-tops, with various operating systems. They need to know how fast the processor is, how much memory is available, how to place items on the TV screen. They write applications using a specific set of guidelines, called “APIs” (Application Program Interfaces). Without middleware, the APIs are controlled by the operating system supplier.
Think of the operating system you use now, on your PC. Probably Windows. Think of what you do the most. Probably Word, Excel, Access. While scores of software writers can access Windows’ APIs, Microsoft had first access to them. Because they make Windows, they knew best how to write applications for it.
As one MSO engineer said to me years ago: “If one software company were to provide the operating system and the interactive APIs, I’d be left with one piece of control: The keys to the headend.”
CableLabs stemmed this concern by placing middleware at the heart of its OpenCable specification. Last month, to sidestep (or intensify, depending on the point of view) the confusion around the word “middleware,” it renamed that effort “OpenCable Application Platform.”
CableLabs also split the project into two layers: 1) The execution environment, where interactive applications actually run, which will be written by Sun, and 2) The presentation environment, which stipulates where and how interactive icons are placed on the TV screen. Microsoft and Liberate will co-write this spec. Canal+, OpenTV and PowerTV will assist and act as watchdogs, a critically important role.
In the PC world, middleware is analogous to Netscape, or Internet Explorer, or any other browser. It runs on any operating system. The execution environment is the plug-ins you download to listen to music, or watch a video, or play a game. The presentation enviornment is HTML. Applications developers write code without having to know what kind of equipment people use.
In TV, middleware is Canal+, Liberate, OpenTV, and WorldGate (among many others), who created an industry around it; Microsoft and PowerTV do both operating system and middleware.
Middleware providers sell MSOs two things: A “client” that sits in the set-top, on top of the operating system, and a “server” that doles everything out, and usually located at the headend. Most middleware companies provide a suite of get-started ITV apps: A branded first-screen, that links to e-mail, community info, the guide, the weather. This is the stuff you’ve seen at trade shows.
To apps writers, middleware companies provide tools that enable the “write once, run anywhere” mantra we so often hear.
What makes this all so confusing is that suppliers approach middleware in different ways. Some bind it to their own operating system. Others don’t. But this is nothing new – almost all equipment used in cable is feature-differentiated.
Over time, through deployments and the OpenCable process, middleware will gain shape. MSOs will put boundaries around features. Apps will start rolling in. It’ll be hard, but the alternative is subscriber churn, to the interactive features DBS offers.
This column originally appeared in the Broadband Week section of Multichannel News.