For traditional bi-directional Internet communication, the Hypertext Transfer Protocol (HTTP) defines how data is transferred at the application level. But because one can’t have a two-way connection over a broadcast medium, we require a unidirectional application-level protocol for data delivery. ATVEF defines this protocol to be the Unidirectional Hypertext Transfer Protocol (UHTTP). UHTTP is based on UDP, as opposed to TCP. This makes sense, of course, because UDP is a connectionless protocol suitable for a broadcast network.

Like HTTP, UHTTP uses traditional URL naming schemes to reference content. Therefore, content creators can reference enhancement pages using the standard “http:” and “ftp:” naming schemes. To this, ATVEF adds the “lid:” or local identifier URL naming scheme. The “lid:” naming scheme allows content creators to reference content that exists locally (on the receiver’s memory or disk drive, for example) rather than the Web.

With HTTP, as well as with many other Internet application protocols, the TCP layer provides error detection and re-transmission facilities. But for a unidirectional protocol, there is no possibility for retransmission requests. Thus, UHTTP must implement error correction without retransmission, sometimes called Forward Error Correction (FEC). Using sophisticated FEC algorithms, if the data is not too badly corrupted, it can be regenerated with only the received information. With their emphasis on error correction instead of detection, the coding schemes used in unidirectional communications are more similar to the algorithms used in data storage like digital tapes and CD-ROMs, than those used in traditional bi-directional communications.

Bindings

How ATVEF data is delivered over a particular network—from the network layer protocol down to the physical layer—is called the binding. In order for ATVEF to provide interoperability between broadcast networks and receivers, it’s important that each physical network have only one binding. And it is equally important that each binding provide a fully comprehensive definition of the interface between the broadcast network specification and the ATVEF specification.

At this point, ATVEF has defined bindings for delivering data over IP multicast as well over NTSC. Because the transmission of IP is defined (or can be) for virtually every type of television broadcast network, the binding to IP is considered the reference binding. So, defining an ATVEF binding for a new network could be as easy as describing how to run IP over that network. Figure 1 illustrates the protocol stack for the reference binding.

ATVEF over NTSC

NTSC is the standard for analog television broadcasts in the U.S. Unless you have an HDTV set already, the televisions in your home are nothing but NTSC receivers. Part of the NTSC standard defines a frame (image) as consisting of 525 horizontal lines, each line drawn (or scanned) left to right. During a screen scan, only every other line is drawn; therefore, it takes two full screen scans to draw a single frame.

Each time the electron gun in the television’s cathode ray tube finishes scanning a half-frame, it must return to the upper left-hand corner of the television screen to prepare for the next half-frame. This takes a non-trivial amount of time, so each movement of the electron gun must be re-synchronized with the incoming signal. This is done by adding a set of unused lines of data to the end of each screen scan, giving the electron gun time to return to its starting position. These 21 extra “lines” make up what is called the vertical blanking interval (VBI). (If you want to see the VBI for yourself, fiddle with the vertical hold knob on your TV and look for a horizontal black stripe across your screen.)

As it turns out, only the first nine lines of the VBI are actually required to reposition the cathode ray. This leaves 12 more lines that can be used to broadcast data. In fact, in the U.S., closed captioning data has been broadcast on line 21 for many years. Each line of the VBI has a transmit rate of about 17K/sec. So in theory, the VBI associated with each NTSC-encoded television channel could carry up to 204K/sec (12 lines at 17K/sec per line) of piggy-backed data. However, after taking into account the overhead associated with the various protocol layers and the need to prevent conflicts with closed captioning and other data already broadcast within the VBI space, the maximum achievable rate for ATVEF data transmission is somewhat lower than this—probably around 100K/sec.

Transport Type A . The Type A transport binding for NTSC is easy to describe. ATVEF triggers are simply broadcast in line 21 of the VBI. For purposes of data integrity, the NTSC binding for Transport Type A requires that each trigger contain a checksum. The binding also recommends that the trigger length not exceed 25% of the total bandwidth of the line, in order to avoid conflicts between triggers, closed captioning data, and data from any future services that might also use line 21.

While ATVEF triggers could have been placed on some other line of the VBI, placing them on line 21 has advantages for receiver manufacturers. For example, most standard NTSC video decoder chips already have the ability to extract line 21 of the VBI (for closed captioning support). By placing triggers in that same line, hardware manufacturers are not forced to upgrade to more expensive decoders that support data extraction in other lines of the VBI.

Transport Type B . In addition to sending triggers on line 21 of the VBI, the Transport Type B NTSC binding includes a mechanism for delivering IP datagrams over the other VBI lines. IP over VBI (IP/VBI) is an Internet Draft of the Internet Engineering Task Force (IETF). As such, IP/VBI is not yet a standard, just a work in progress. Therefore, some details of some of the encapsulation, compression, and error detection schemes may change, but the architecture is unlikely to change radically. Figure 2 illustrates the protocol stack defined by ATVEF down to the IP layer, and defined by IP/VBI below that.

Figure 2

At the bottom of the stack is the NTSC television standard. At the lowest level, the television signal transports NABTS (North American Basic Teletext Standard) packets. NABTS is a method of modulating data onto the VBI. A typical NABTS packet gets encoded onto a single VBI line. NABTS, by way of its own forward error correction, supports correction of all single-bit, double-bit, and single-byte errors, as well as the ability to regenerate an entire missing packet. The NABTS packets are removed from the VBI to form a sequential data stream. This data stream—encapsulated in a SLIP-like protocol—is unframed to produce IP packets, which are handled equivalently across all ATVEF network types that implement the IP reference binding.

As you can see, a specific network binding is not complicated, but is detailed enough (the full IP/VBI draft standard is obviously much more detailed than what we’ve presented) that anyone creating a broadcast network or building an ATVEF receiver has enough information to make their design ATVEF-compliant. And, while we’ve only presented the NTSC binding here, there are—or soon will be—well defined ATVEF bindings to every other major video network standard, including PAL and SECAM (the European counterparts to NTSC), ATSC (digital terrestrial broadcast), cable, and satellite.

Design issues

Even for those intimately familiar with the specification, implementing an ATVEF receiver is not a trivial chore. Because the specification is flexible with respect to many of the implementation details, the embedded software developers—and, in some cases, the hardware designers—have to determine exactly how the receiver will be integrated with the television or the rest of the set-top box.

The first major decision when designing an ATVEF receiver is whether to support Transport Type A or B. Often, this decision is driven by the type of network the receiver will be connected to. For a satellite television set-top box that provides no backchannel to the Internet, the obvious decision is to support Type B. But for a cable television set-top box that doubles as a cable modem with dedicated Internet access, it may be okay to support only Type A. Of course, choosing to support a high-bandwidth option like Transport B will also require additional hardware and/or software performance.

As a typical example, let’s suppose that we were building a set-top box that would serve as an NTSC receiver with ATVEF support. Assuming the standard NTSC binding for Type B—NABTS encoding of the data in the VBI—we must decide how we will decode this data when received. The most obvious choice is to use an NTSC video decoder that will parse all VBI lines in hardware. But, as we mentioned earlier, while some of the higher-end decoders support this functionality, these decoders tend to be a little more expensive; when building millions of set-top boxes, every penny saved can make a big difference in the bottom line.

The other option is to do the NABTS decoding in software. Unfortunately, software decoding is processor intensive. In fact, some benchmarks have indicated typical VBI decoding requires up to 2% of a Pentium-class 166MHz processor per VBI line. For full decoding of VBI lines 10 through 20, this would require about 20% of that same processor’s time. Of course, these specific issues are only related to NTSC receivers. ATVEF receivers on digital—or non-NTSC analog—networks have a whole set of different issues that must be addressed.

Another major design issue that developers must consider is user interface. By design, the ATVEF specification puts no restriction on how triggers and data are presented to the user. Implementers must decide how these things are done. For example, it seems reasonable that the user should be able to decide if he would like to receive indication of incoming content or not. But nothing in the specification dictates that implementers must allow users to turn off enhancements.

So what?

So now you’re wondering, “What is this enhanced TV stuff going to do for me?” The most obvious answer, unfortunately, is that it is going to try to entice you to spend money. For decades, the television has been used to solicit your hard-earned cash through a seemingly endless stream of commercials. But, despite the annoying jingles that we can’t get out of our heads, the slogans that pervade pop-culture, and the famous spokespersons who just won’t go away, television advertising has always lacked the ability to “complete the transaction.” Never before has television advertising had the means to allow the viewer to make a spontaneous purchase, to buy with the click of a button. Now it does.

That doesn’t just mean that every commercial will include a “BUY ME NOW” button. It also means that you’ll be able to make purchases during your favorite shows. Clicking on Dan Marino’s football jersey during Monday Night Football may pop up a description of the collectible garment, with an opportunity to purchase one right away. Or, during that same Monday Night Football game, the network may offer you the option to receive alternate camera footage, live from the home team’s clubhouse or from the camera on the referee’s shirt—for a fee, of course.

But let’s not just focus on the advertising; enhanced television has the ability to improve your viewing experience as well. Imagine interactive game shows, where the contestants are chosen during the show to participate directly from their living rooms. Or you’re watching MTV, and with the click of a button, are finally able to get the lyrics to that ridiculous song you can’t stop humming. Imagine choose-your-own-ending television shows where viewers have the option to vote on which of a variety of outcomes will happen.

And not only will television provide enhanced content, it will also have the means to provide personalized content. Take regular NTSC broadcasts, for example. VBI data (and hence ATVEF data) can be added to an NTSC signal at any point, and even more than one point, in the path the signal travels from the broadcaster to the receiver. Therefore, a broadcaster could insert ATVEF content on a national scale, a local cable operator could add ATVEF content relating to local markets, and an automated profiler in your receiver can figure out which specific content would most appeal to you, and display it. National news broadcasters will now have the ability to provide local headlines, or better yet, headlines that appeal specifically to you.

Industry support and competing standards

Enhanced television is not a new idea. For decades, companies have built visions of enhanced television and tried to sell their visions to advertisers and consumer electronics manufacturers. However, none of these proprietary systems has caught on. Enhanced television has a “chicken and egg problem”—broadcasters are reluctant to invest in enhanced television content and infrastructures before the consumer electronics companies can guarantee a reasonably sized audience. And the consumer electronics companies find it difficult to sell enhanced TV receivers without the support of the broadcasters, who must provide enhanced content.

Today, two main standards compete in the area of enhanced television: ATVEF and Broadcast HTML. Broadcast HTML was created from ATSC-related work to develop the DTV Application Software Environ-ment (DASE). It’s a combination of an XML-based subset of HTML 4.0, along with a Java Virtual Machine and Sun’s PersonalJava API.

Both standards have significant industry support, and neither is likely to disappear soon. That leaves broadcasters, hoping to avoid a prolonged “VHS vs. Beta” fight, worried. Many are looking to the ATVEF and DASE members to reconcile their differences, or provide a minimum level of interoperability between the two standards.

Some companies are not waiting for the standards to settle. CNN, Discovery Channel, and HBO are among a handful of broadcasters already delivering enhanced content on a regular or semi-regular basis. In fact, each week over 1,000 hours of network, syndicated, and cable TV programming include content enhancements. Consumer electronics companies are designing their next-generation set-top boxes to comply with enhanced television specifications. And embedded web browser companies are already providing enhanced television support in their browsers. You can be sure that enhanced television is coming.

Jason Steinhorn is an embedded software engineer at Hughes Network Systems in Gaithersburg, MD. He is currently designing and developing a Web-enabled satellite television set-top box. Jason can be reached at jsteinhorn@hns.com.

Mark Kohler develops software for broadband network equipment at Nomadix, in Santa Monica, CA. He can be reached at mkohler@nomadix.com.

Acknowledgments

The authors wish to thank David Mott of Liberate Technologies for reviewing this article for technical accuracy. David has served on the ATVEF Technical Working Group since its inception. He can be reached at mott@liberate.com.