Digital Set-Tops and ITV: The Stirring Sequel

Publish date:
Updated on

Last time, we examined the signal paths to and from today's installed base of more than 10 million digital set-top boxes. This time, we'll attempt to connect the dots between those units (Motorola Inc.'s DCT-2000 line, Scientific-Atlanta Inc.'s Explorer 2010/2100 line and all clones), and the three general types of interactive applications.

Resolving which flavors of interactive applications will snap into which signal paths on the installed digital base necessitates a distillation of the types of interactive TV. Generally, there are three kinds of television interactivity, even though there are as many ITV suppliers as there are letters in the alphabet.

First are "set-top resident" applications, which means they live in the box. (Technologists sometimes call this a "rez app.") In today's world, this is prevalently the electronic programming guide. It consists of a user-navigation shell and the actual information about what show is on at what time.

In the Explorer 2010/2100 line, the current and next day's worth of guide data is sent to the box via the out-of-band path. The other days are carried in-band, to be retrieved quickly when requested. In the case of Motorola's DCT-2000, guide data is sent out-of-band.

In general, guide data comes in increments of days — two days, four days and so on. Each day's chunk directly affects how much set-top memory is left for any other interactive applications. More guide data, less room. Less guide data, more room.

Notably, there are two types of memory in today's boxes — DRAM (dynamic random-access memory, pronounced "dee-ram"), and Flash. Data goes in DRAM; usually, application code goes in flash. The difference arises when the power goes off.

Stuff in flash memory stays, and returns with the power. Stuff in DRAM needs to be re-retrieved.

The second type of interactive category, "program synchronous," is what happens when interactive things come along with a TV show or ad. The pointer to the interactive thing — be it a click-to-buy offer, contest, or show-related quiz — is sent inside the program and presented to the viewer as a clickable gizmo. Most commercials last a scant 30 seconds, so responsiveness matters. Indeed, most program-synchronous apps require real-time handling.

The third interactive category spans anything that is "session-based."

Session-based means the set-top works in alignment with servers located elsewhere in the network. In most cases, a software kernel roosts in the box. It has to be skinny or it won't fit in flash. (For dog people: Picture a greyhound with the retrieval passion of a Labrador retriever.) The kernel's job is to quickly get the navigational shell, or graphical user interface or whatever people call the thing that displays when the "menu" button is pushed.

The session begins the second a subscriber pushes the button to invoke something from the menu. If user Jane wants the Denver weather, and pushes a button to summon "local weather," for example, the message "rain again" isn't immediately at hand in the box. It needs to be fetched from a remote server, via a session.

It is precisely at this point that we enter part two of the signal-path translation (see "In Band, Out of Band, Whatever It Takes," May 28), because its performance affects both program-synchronous and session-based interactive services.

The in-band and out-of-band signal paths are seasoned with distinctive characteristics that, when harnessed to specific ITV types, bring out the best (and worst) in them. It's an inalienable truth: Some ITV types just don't blend well with existing digital boxes and signal paths.

Example: You're watching the Stanley Cup Finals. It's a blisteringly active game. You send an instant message to your hockey-aficionado friend: "Wow! Did you see that?!" It is ITV buzzkill in its purest form if your message arrives on your friend's TV four hours later.

Which brings us to another distinctive marking on the out-of-band path, beyond what was described previously. It involves timing, and specifically, whether the out-of-band path is real-time
or polled.
When doing anything on today's digital set-tops that requires immediacy — playing a twitch game (session-based), making a telephone call (session-based), sending an instant message (session-based or program synchronous), clicking to buy something nestled in an ad or TV show (program synchronous or session-based) — you want a real-time connection to the goods. You don't want the headend controller to collect your customers' interactive clicks in a round-robin, box-by-box interrogation. Polling is measured in hours, not in seconds.

If the box you're using contains a real-time, out-of-band path, you're reasonably outfitted to swiftly collect clicks from your subscribers' remote control or wireless keyboard and fling them upstream to the applicable server for handling. If not, and you want that, you'll need more equipment — in short, data-networking accoutrements that were born for session-based, networked communications.

The interim game is to synchronize the out-of-band path with the in-band path, to simulate a session-based environment in which subscriber clicks are immediately satisfied and delivered over a swift, downstream path.

It's the best that can be done until the hot-rod set-tops arrive on the scene.

Stumped by tech gibberish? Send translatables to, with "Translation Please" in the header.