Spend more than a few minutes looking into the subject of Internet-protocol television, and you’ll probably stumble into two terms: “Multicast” and “unicast.”
When cable technologists think about multicast and unicast, they’re usually mulling one of two things.
One is how to move video over a new path — the IP path — to digital set-tops and TVs, as well as any future storage or display devices attached to them.
The second is how to best link broadband-equipped PCs to quality video. The easy way out, translation-wise, is to tag both terms as new, digital lingo for existing video transmission methods.
“Unicast,” for example, is the sending of one digital video stream to one requesting device (i.e. set-top). That makes it very comparable to how today’s on- demand systems work.
“Multicast” is the sending of one digital video stream to many requesting devices. Last I checked, that’s what we know as broadcasting, either through the air or over a wire.
There are differences, though, particularly between multicast and traditional broadcast (analog or digital).
INVOLVEMENT KEY
The biggest distinction seems to be how involved people are (or aren’t) in receiving video.
In traditional broadcast — as TV viewers all know — all the channels are there for viewing, all the time.
In multicast, receiving a show involves joining a “multicast group.” He who knows to extend his cup, so to speak, can fill it up with bits. Content is “pulled,” not “pushed,” to revisit that boom-era concept.
All of this makes multicast more analogous to switched digital video than traditional, everybody-gets-it broadcasts.
Security is also different.
In multicast, after people say they want to receive a multicast show, they’re sent a key to decrypt the program when it arrives. Skeptics say: If a million people sign up, how many minutes is it before there’s a “heresthekey.com?”
Cable’s existing digital video systems, by contrast, send two messages to set-tops or CableCARD receivers: An Entitlement Control Message (ECM) and an Entitlement Management Message.
One rides with the program, and the other travels a separate, out-of-band path.
The messages convey authorization information — are you entitled to receive the tier or premium? — and a key, which is exchanged with an embedded key, triggering decryption.
They also map back to provisioning, subscriber management and billing systems, for business handling.
The guts of security systems, both multicast and traditional, are well beyond the scope of this column.
Suffice it to say that the existing authorization and encryption methods for cable’s digital video offerings are known, deployed, and, so far, sufficient protection.
The authorization and security methods for multicast, known in that camp as “Multicast Internet Key Exchange,” or “MIKE,” will also work — but perhaps not as quickly, and without as much cultural trust by “broadcasting people.”
Those details, in part, explain why multicast will likely tiptoe into cable, while it trots into telco digital subscriber line environments.
The differences in gait are fairly understandable. Telephone companies, for the most part, are starting anew (again) with their video-delivery decisions.
Out the telco window, they see green fields. They don’t see deployed set-tops and supporting gear in the double-digit millions, or any other legacy bindweed.
Cable providers, on the other hand, have about 30 million rectangular reasons to give serious thought to multicast, as a component of IPTV.
MPEG TRANSPORT
For starters, those fielded boxes don’t yet know how to use multicast. Instead, they use a transmission method known to engineers as “MPEG [Moving Pictures Expert Group] transport” (translated in the July 28, 2003 edition).
MPEG transport already handles digital video and IP traffic in contemporary cable systems. The bits to and from cable modems and voice over IP devices, specifically, use MPEG transport.
This is precisely what people mean when they use terms like “IP encapsulation” — that IP packets, which can vary widely in size, are chunked to 188 bytes. That’s the size stipulated in MPEG transport.
For cable technology people, the multicast discussion usually comes down to a variation on “if it ain’t broke, don’t fix it.” Or, more specifically, examining which is less expensive to implement.
So far, the answer is MPEG transport.
Here’s why. Say you wanted to send digital video to set-top boxes, using the IP path. This assumes set-tops with a built-in cable modem, which is beginning to happen, but is far from widespread.
Right now, the cost to deliver IP video through the CMTS (cable-modem termination system) is at least 10 times the cost of sending it conventionally, observers say. Conventionally means moving traffic in IP to the “edge” of the network, dropping off at the QAM (quadrature amplitude modulation) modulators.
COST ARGUMENT
From the edge quadrature-amplitude modulation systems to homes, MPEG transport is way less expensive, and performs the same tasks. So, the reasoning goes, why not use it until costs retreat on video-capable CMTS units that can handle things like multicast?
Multicast protagonists argue that, over time, the technique does make cable’s IP path more efficient. A video stream is sent, once. The CMTS duplicates its packets only to the downstream, neighborhood nodes that contain people who’ve requested the multicast show.
The bottom line is this: As long as IP technologies continue pushing deeper into cable networks, techniques like multicast and unicast will likely follow. Cable, ultimately, can do both. So that’s good.
Plus, telco video competitors will likely be big multicasters. That probably qualifies multicast as something to keep an eye on.
Stumped by gibberish? Visit Leslie Ellis at www.translation-please.com.
