What’s a DVB-MHP, and Why Does It Matter to Cable?
by Leslie Ellis // November 19 2001
In last week’s batch of technology clippings was a CableLabs item, stating that OpenCable will adopt a set of European interactive TV specifications, known in the lingo as “DVB-MHP.” That’s short for “Digital Video Broadcast – Multimedia Home Platform.”
On the surface, the development parallels a widely-held belief that European cable and satellite TV providers are farther along with interactive TV than are U.S. video providers. Translation: Join ’em.
And then there’s the stuff not directly stated in the release. It turns out that in the technological goo that embodies the 1,153-page DVB-MHP specification, Sun Microsystems’ Java set-top software is a binding element. A key component of that software suite is the “Java Virtual Machine,” or “JVM” – an acronym that’s already been cropping up with increasing regularity among set-top software providers.
Several translations are suddenly in order, starting with DVB. Based in Geneva, DVB is a consortium of some 300 companies, from 35 countries, with a mission to forge interoperability among digital TV services, regardless of distribution method (satellite, cable, or terrestrial.)
MHP is a subset of the larger DVB. Its mission: To write the framework for advanced interactive TV applications on digital, MPEG-2-based video networks. Again, MHP doesn’t care who carries the interactive stuff – be it cable, terrestrial or satellite. It just defines how to do it.
The notion of a virtual machine, though, is a tougher translation. We’ll start at the beginning: Usually, when you buy any sort of machine, it does what you bought it to do, and only that. A chipper/shredder chips and shreds. A blender blends. A dryer dries.
But along with automation and software, a new-ish type of machine – the “virtual” machine – entered the foreground. It is “newish” in that it is new to cable. But at its technical core, the notion of the virtual machine isn’t all that new. Rather, its decades old.
Virtual machines allow a grouping of chips, governed by software, to do other things than what they were originally intended to do. Where a typewriter does one thing – makes words on paper – a word processor makes words or pictures, on paper or on a screen. In a sense, then, all PC software is a sort of virtual machine. As it gets updated, it allows the machinery of the application do new and different things.
If you’ve heard of a virtual machine before, you’ve probably heard it with a specific prefix: Java. Java technologies are an invention of Sun Microsystems. There is the Java “platform,” which is all of it. There is the Java programming language, which is widely taught by computer science colleges around the world. Translation: Piles of computer programmers who know how to write in Java.
Then, there is the Java virtual machine, or JVM, which is a combination of an interpreter – the part that reads the code – and the Java language, or the code itself. Think of it as middleware’s engine – but be sure to check with your potential middleware providers to see if JVM is indeed their engine. Up until now, the middleware camp was divided. Some pursued JVM, and did the legwork to get their Java licenses in order. Others pursued the Internet’s HTML, or Hypertext Markup Language. Still others went with their own, home-grown (read: proprietary) approach.
As it turns out, JVM is already fairly pervasive. If you use a newer Palm Pilot, or a high-end cell phone with a menu of options, you’re probably already using a JVM.
On a set-top level, technologies like JVM matter because they theoretically provide a cushion of control when dealing with interactive applications providers.
Say, for example, you’re tied to a guide provider that nestles its code inside your set-tops. Say you’re thinking that provider has too much say over how you proceed with set-top resource management — how much processing power and memory gets used by which interactive applications.
With a JVM as the “engine” within DVB-MHP, and by extension, OpenCable, and with a large and growing base of software coders who write in the Java language, suddenly there’s a path toward moving the guide, or any other application, on top of the JVM. Translation: Control.
Plus, all Java-based technologies are community-governed, meaning they are at least more “open” than other, more proprietary options.
Still, though, for the U.S. to quicken its pace in ITV – which necessarily means attracting the content that will get things going — it probably makes sense to consider what DVB did, and attract all distribution platforms to one method.
Sure, that’s a tough pill to swallow, competitively. But it’s probably necessary to reach the original goal of set-top middleware: A “write once, run everywhere” environment for the content community. OpenCable and DVB-MHP is a logical start.
This column originally appeared in the Broadband Week section of Multichannel News.
Cable’s Trouble with Microsoft Windows XP
by Leslie Ellis // November 05 2001
While the musician Sting wooed New Yorkers on October 25, singing the start of a $1 bil. marketing campaign by Microsoft Corp. for its new, XP operating system, cable technologists were bracing for a different kind of sting: Service calls from unhappy cable modem customers.
As it turns out, there’s a good chance that high-speed Internet customers using cable modems that latch to the personal computer with a USB (Universal Serial Bus) connector, and who upgrade to Windows XP, could get a pretty spooky error message.
The message, in part: “Continuing your installation of this software may impair or destabilize the correct operation of your system, either immediately or in the future … Microsoft strongly recommends that you stop this installation now and contact the hardware vendor for software that has passed Windows Logo testing.”
It’s bad news either way. Aborting the upgrade means customers don’t get whichever XP features they found useful enough to initiate the upgrade in the first place. Continuing means that, after completion, XP refuses to acknowledge the USB-connected cable modem, making it behave as though it were suddenly dead – even though it responds normally when “pinged” from the headend.
At the root of it is the software driver loaded on the installation disks of USB cable modems. Drivers are electronic lists that describe any device trying to attach to a computer. They say: This is who I am (a cable modem made by so-and-so); This is the port I’m connecting on (USB); This is what I do (attach to the Internet.)
All “peripheral” hardware – “peripheral” meaning it didn’t necessarily come with the PC — has a software driver. That includes printers, video monitors, joysticks, scanners, cable modems, DSL modems, phone modems. (This means USB cable modems aren’t the only things affected. Your friends on the DSL side are having similar woes.)
Here’s the thing: Most, if not all, drivers for USB cable modems were written to run on residential-use PC operating systems, which means they speak in 16-bit, “unprotected” mode. XP, on the other hand, is the first residential-use PC operating system to speak in 32-bit “protected” mode – and that mode refuses to acknowledge the earlier one.
What’s being “protected” in Windows XP’s 32-bit mode is the PC’s memory, and how it gets used. Surely you’ve been in this situation, somewhere along the way: You’re running Word, Excel, a graphics program, and e-mail. You do something, and suddenly your PC goes kaflooey. Nothing works. You have to turn it off and back on again.
XP’s 32-bit “protected mode” fixes this. Each application is given a fixed amount of memory, and isn’t allowed to know or move beyond those boundaries. A rogue application can’t bring down your entire system – and all the work you may have open (and, as Murphy’s Law dictates, probably unsaved.)
So there’s your treasured high-speed Internet customer, trying to upgrade to XP, and using a USB cable modem. When XP tries to read the USB driver, it sees only a 16-bit version. XP says no. Maybe it prompts your customer to load the CD-ROM that holds the drivers for the USB cable modem, to see if there’s a 32-bit version on board.
But in most, if not all cases, there isn’t. In a fairly understandable oversight, cable modem manufacturers believed, at the time USB drivers were created, that anyone running a 32-bit operating system would be a corporate user, and that corporate users would go with Ethernet connectivity, not USB. (Ethernet-connected cable modems work just fine with XP.)
Here’s what has to happen for this whole situation to be resolved: Cable modem manufacturers must send their 32-bit drivers to Microsoft for certification. (Most have done so.) Then, the modem suppliers send those new drivers to cable MSOs, for use in instances just such as this.
Ordinarily, a customer could visit the Web site of the manufacturer to download the new driver. But that’s sort of hard to do if the only device capable of connecting to the Internet is behaving as though it is dead.
Alternative number two: The MSO hand-delivers or mails a new installation disk to the USB cable modem user, so that the approved, 32-bit USB driver can be loaded and recognized as good by XP.
The good news is, there really aren’t that many USB cable modems out there right now. And, XP is expected to be more momentous with new PC sales, not upgrades to existing PCs. So the call volume for affected cable modem customers is likely to be fairly small. But nonetheless, forewarned is forearmed.
This column originally appeared in the Broadband Week section of Multichannel News.