Nothing like a new year to tackle an intricate set-top/cable-modem combo topic: A-DSG.
“A-DSG” stands for “Advanced DOCSIS Set-top Gateway.” It travels with terms like “MAC multicast addressing,” “digital channel descriptors” and, my personal favorite, “the whole hub-straddling thing.”
Before we even get into what’s advanced about it, know that DSG alone matters for lots of reasons. It’s the first major technical juncture between traditional “MPEG” video transport [people and gear] and the cable-modem/broadband realm [ditto].
That’s because it defines how set-tops talk not only to traditional headend controllers, but also to the CMTS [Cable Modem Termination System] controllers of the broadband domain.
Plus, DSG is a big part of how OCAP stuff moves to boxes.
The original DSG spec [sans the “A”] was released by CableLabs in 2003 as an alternative “out-of-band” signal path to and from digital set-tops.
Refresher: “Out-of-band” means data sent to and from a box, without any correlation to a specific channel or TV show. Guide data, conditional-access markers and software patches are examples of data types that travel best in a tunnel not correlated to particular show.
Think of it this way: If you change the channel while next week’s guide data is flowing into your box, that flow stops until the next time you tune that channel.
The “in-band” transit passageway sends data within a channel or TV show. EBIF triggers are an example. Using the remote to vote someone off a show, or to be pointed to more, stored VOD content about a show, works best if that trigger is correlated with the show you’re watching.
In “regular” DSG, each set-top is pre-configured with a “well-known MAC multicast address” for out-of-band signaling.
Let’s unpack that a bit.
“Well-known” in this sense means mutually acknowledged by both MSO recipient and set-top manufacturer. Technically, it means each box is hard-coded at the factory to know where to “join” a particular multicast stream of out-of-band traffic.
“MAC” stands for “Media Access Control.” It’s an identifier.
“Multicast” is a way of sending a “one-to-many” stream of packets over an IP network. It’s not as wide as broadcast, reach-wise, and not as narrow as unicast.
Note: “MAC Multicast address” is conversationally synonymous with the term “DSG tunnel.”
Why on earth would a set-top need a MAC multicast address? Turns out it was more a desire for calamity avoidance than for IP video. If a set-top’s upstream path went kaflooey, and couldn’t talk to the CMTS controller, there had to be a way to still send it critical out-of-band messages that could be understood and enacted.
Engineers ultimately realized they needed a more elbow room in how DSG addresses are handled. They needed tunnels they could change on their own, on the fly, without having to go back to manufacturers: One for conditional access stuff, another for OCAP stuff, another for guide stuff, and so on.
Enter the “A” in “A-DSG.”
Example: You’re a cable operator, wanting to deploy an unbound or OCAP application. It requires an out-of-band signal path. Before A-DSG, your option was to contact your supplier to change that well-known address.
In “advanced” DSG, that well known DSG tunnel can be changed as needed, by modifying a thing called the “downstream channel descriptor,” or DSD.
Now let’s say that application, delivered over the DSG path, is streaming out to boxes that are geographically scattered. Technically, let’s say its plant with hubs that straddle county borders. [This happens.]
The app, in this example, is the guide data, flowing over existing hubs to Counties A and B. But each county happens to have channel differences. So, two types of guide data are needed. Welcome to “the whole hub straddling issue.”
With A-DSG, set-tops in County A can be told (via that downstream channel descriptor) to watch for a specific tunnel that contains multicast data, including tuning information. Likewise for County B, but on a different tunnel.
Voila: The hub straddling issue is … no longer an issue.
That’s a quick overview of A-DSG. Chances are high that this will serve as a big background topic in cable’s engine rooms this year, for two reasons: One, it’s tightly linked to OCAP. Two, it’s the first real blending of old (MPEG) and new (IP) transport.
Stumped by gibberish? Visit Leslie Ellis atwww.translation-please.com.
