Competition is brewing in the PC and broadcast industries over a data network everyone has access to but very few people even know to exist: broadcast television. TV broadcasts include a little known medium-bandwidth, unidirectional data pipe known as the vertical blanking interval, or "VBI". A small portion of the VBI is already in use today to broadcast FCC-mandated closed captioning for the hearing impaired in the U.S., and with the convergence of computing and television devices accelerating, additional uses for this bandwidth are being aggressively pursued.

This paper compares and contrasts two similar technologies seeking to utilize the VBI for transmission of Internet content: Intel Intercast, and Microsoft’s recent IP/NABTS proposal. At the time of this writing, this very analysis is being pursued by Hollywood producers, TV networks, and local TV broadcasters, who are all being wooed by Intel and Microsoft to endorse and adopt their respective architectures. They must decide which design offers the best potential for them to execute on their short and long-term goals to enhance programming with associated data content. This analysis requires not just an understanding of how data bits are transmitted and in what data formats, but also a variety of end-to-end considerations that impact the viability of one system over the other, such as tool availability, installed client base, market penetration, guaranteed data bandwidth, etc.

It is concluded that broadcasters and producers that believe in the concept of simul-casting Internet VBI data with video broadcasts to enhance TV programming should jump in now using Intel Intercast, because it is a functional system with readily available tools. Should IP/NABTS or some other system come along later, a transition would not be difficult, since the real investment is not in the data transmission protocols, but rather the authoring process that is sufficiently similar on both platforms.

As televisions and TV set-top boxes integrate more computing capabilities, and PCs incorporate TV reception capabilities, the VBI is increasingly viewed in the computer, consumer electronics, and broadcasting industries as a valuable resource enabling delivery of value-added information and entertainment services into the home. For example, companies like StarSight and Gemstar are now using the VBI to transmit television program guide information via VBI. In Europe and the U.K., the TeleText system transmits news and information across the VBI.

A natural challenge/opportunity arising from the so-called "digital convergence" of computing devices and TVs is how to leverage the VBI for the Internet, and vice versa. Towards this end, the two PC industry heavyweights Intel and Microsoft have quietly engaged in competition over how the VBI and Internet will come together, or more specifically, who will define the required data protocols and deliver authoring and transmission tools for them.

For the past year, Intel has promoted its proprietary "Intercast" technology for transmitting HTML via the VBI, and is currently operational with several major television networks such as MTV, NBC, and QVC, each broadcasting web pages related to their programming in a subset of their key television markets. In a competing move, last month Microsoft called for a more open architecture based on existing Internet network protocol standards, and publicly submitted an RFC to the IETF for an open transmission standard. Microsoft buttressed this move by pre-announcing support for this design in future versions of Windows and Windows NT. Surprisingly, Microsoft’s broadcast data architecture has no marketing name associated, so for purposes of this paper it will be referred to as "IP/NABTS", a description of the two key data protocols it implements.

The following sections present fundamental technical information required to compare and contrast the competing Intel and Microsoft approaches.

In the United States and some other countries, television video broadcast signals are encoded in a format defined by the original "National Television System Committee", hence the name "NTSC" by which this broadcast format has become known. In the NTSC signal, video frames are sent one line at a time, in an interlaced sequence. That is, the CRT gun draws even lines first (the "even field"), top down and left-to-right starting with line 0. When it reaches the bottom of the screen, the gun returns to the top left corner of the display to draw the "odd field", i.e. odd lines starting with line 1. Upon drawing the last odd line, the gun again returns to the top left of the screen to begin painting even lines again. This process is repeated 30 times per second ("frames"), such that the gun jumps from bottom-right to top-left 60 times per second ("fields").

The time interval during which the gun movies from the screen bottom to top is called the vertical blanking interval, or VBI. During the VBI, about 21 lines of NTSC scan line data is transmitted, but since this signal cannot be displayed on the screen, a portion of this bandwidth is available for data transmission.

Specifically, the first 9 lines are not available for data, but lines 10 thru 21 are. Line 21 is reserved for closed captioning (per the FCC), leaving 11 lines available for other data transmissions.

The industry-accepted method of modulating data into the VBI of an NTSC signal is defined by the North American Basic Teletext Standard (NABTS), standardized by the Electronics Industry Association as EIA-516.

Details of the NABTS modulation scheme are beyond the scope of this document. However, the data format it supports is relevant. NABTS enables a 36-byte data structure to be encoded onto each horizontal scan line of an NTSC signal:

Since each line is refreshed 60 times per second, the raw data bandwidth provided by NABTS is 17,280 bits per second. The receiving VBI client strips the NABTS headers and performs error correction either in hardware or software. The NABTS headers introduce 36.8% overhead, for an effective asynchronous serial data stream of 10,920 bits per second (bps). Multiplied across all 11 VBI lines available for data transmission yields a total of 120 Kbps, nearly that of a full ISDN data connection, or about four 28.8 modems.

The packet group address field distinguishes services originating from the same source, such that multiple unrelated data services can be carried (one per line) in the VBI. The more lines used by a single service, the greater that service’s bandwidth. For example, a service utilizing 4 VBI lines has an effective bandwidth of about 43 Kbps, while a service utilizing 8 VBI lines has twice that, or about 86 Kbps.

The forward error correction (FEC) suffix is necessary to ensure the integrity of data at the receiver, since the unidirectional nature of VBI data transport does not enable packet retransmission to correct errors. The two FEC bytes appended to each data packet are used in conjunction with 2 full FEC packets transmitted for every 14 data packets. This algorithm can correct single byte errors or single and double byte erasures within a sequential 16 packet transmission. Further details of this FEC algorithm are documented in Microsoft's IETF submission (see References, below).

A VBI data stream is added to an NTSC broadcast signal via a device called a VBI encoder. Norpak Corporation is the primary vendor of VBI encoders, which are currently used nationwide to insert closed captioning data onto VBI line 21.

The NABTS data transmission system begs a number of interesting questions: How are packet group addresses assigned? Who owns the 11 lines of data bandwidth? How are lines allocated? How do receiving clients know which lines to decode for their particular data service?

Interestingly, at this time there is no official governing body, e.g. the FCC, addressing these concerns. To date, the problem has been managed thru informal cooperation between the small number of VBI data providers in operation, but it is likely to become a source of contention as demand for VBI bandwidth (lines) grows.

As far as who decides what VBI lines can be used by whom, there are several possibilities: the program content originator (e.g. the TV show producer), the TV broadcast network, the local network affiliate, the cable or satellite system company, etc. In fact, there is indeed contention over this right now, with instances reported of data lines inserted by "upstream" providers (e.g. the network) being overwritten by data lines of "downstream" providers (e.g. the cable company).

Intel rolled out its architecture for transmitting data over VBI/NABTS in 1995. Named "Intercast", this VBI-based data service defines a data format for encoding web pages into NABTS data lines, specifically HTML text files and graphics files (GIF, JPEG) can be transmitted. Intercast is designed to run on Windows-based PCs, and requires a TV tuner adapter capable of receiving and decoding VBI data as well as broadcast video and sound.

Intel's Intercast application program decodes and displays the HTML and graphics data transmitted in Intercast VBI data lines. The Intercast viewer enables users to view a TV program and its associated web pages that are broadcast across the VBI simultaneously. A screen shot of the Intercast program is shown below:

Intercast HTML and graphics data is decoded by the application and stored in a hard disk cache, and their arrival is indicated to the user in the selection pane. Web pages are displayed in the bottom portion of the window as the user selects them in the top right pane. Also, pages may be automatically displayed based on the incoming data packets from the TV program, such that pages updates can be synchronized with the program content.

At the National Association of Broadcasters (NAB) convention in Las Vegas last month, Microsoft proposed an alternate open industry specification for encoding Internet data in NABTS VBI data packets. However, instead of encoding HTML web pages into NABTS packets, as in the Intercast format, the Microsoft specification calls for encoding of multicast IP packets, with UDP headers for process routing on client computers.

That is, in terms of the OSI layered networking model, Microsoft is proposing that a standard Internet network layer (IP) and transport (UDP) layer be inserted on top of the link layer NABTS provides. Application data such as Intercast, HTML, etc. can then be built on top in a network independent fashion, just as they are today on the Internet.

In the IP/NABTS model, client applications can be isolated from the fact that their data was streamed in from a TV adapter, as opposed to from modem, ISDN, LAN, etc. For example, applications designed to receive "push model" web pages via multicast IP can have their HTML cache populated via TV broadcasts as well as standard network connections, and they may or may not even know the difference.

Microsoft has announced that it is building IP/NABTS client support into future versions of Windows in the form of a "TV Explorer" application. Similar to Intel's Intercast application, TV Explorer will receive and display HTML based web pages designed by producers to enhance their TV programs. However, there are some key differences between Microsoft's planned TV Explorer and Intel's Intercast design, discussed in the next section.

Intel's Intercast application relies on extended (i.e. non-Microsoft supported and documented) interfaces in the software driver for the installed TV adapter in order to change channels, and receive audio/video and VBI data from the device. It examines all of the incoming VBI data received by the adapter to "discover" which lines contain Intercast data, based on the NABTS packet group address.

In contrast to Intel's design, in which the Intercast application is the immediate client of the NABTS serial data stream, in the IP/NABTS model the lowest level VBI client is a network adapter driver, operating within the Network Device Interface Specification (NDIS) driver stack. This driver interfaces with the TV adapter driver to receive and decode IP packets filtered from NABTS data lines. These packets are forwarded into the network protocol stack, thru IP to UDP, and ultimately to client applications via high-level Internet APIs such as the Windows Sockets interface ("WinSock").

In IP/NABTS, each TV adapter does not have a unique IP address. Instead, IP packets are transmitted to standard multicast IP addresses, rather than unicast addresses. High level applications such as Microsoft's TV Explorer are designed to take advantage of the IP/NABTS pipe similar to how they would within today's Internet programming model for multicasting. That is, applications monitor well-known IP and port addresses to receive announcements of current and future IP multicasts they support, and receive any/all of those multicasts thru standard Internet programming interfaces.

As with Intercast, the TV adapter must be tuned to the proper channel on which applications are expecting to receive their multicast data. In most cases of "live" interactive operation with the user, incoming data is "real time", i.e. immediately relevant to the program (or advertisement) being watched, so this is not a concern. There is, however, the issue of scheduled data broadcasts, e.g. update your web cache in the middle of the night via PBS, in which case the application would require the ability to programmatically change the TV channel in the background.

Authoring HTML content for either Intercast or TV Explorer is easy. Existing web page authoring tools can be used to create pages. However, the data objects that compose Intercast pages are limited to what Intel's software can encode, decode, and display, namely basic HTML layout and graphics. Intercast cannot transmit enhanced web pages, frames, or other types of data objects commonly found on modern web pages, including audio and video clips, ActiveX objects, Java applets, RealAudio links, Macromedia "Shockwave" objects, other types of plug-ins, etc.

In contrast, Microsoft's TV Explorer application will be built on the current version of Microsoft's Internet Explorer, providing full compatibility with current and future HTML tags and all types of embedded objects, links, etc. This is enabled by the IP/NABTS design, which treats the VBI data stream no differently than any other Internet connection, so no artificial constraints are placed on transmitted data.

An advantage to using the standard Web browser for VBI delivered content is that the user stays in a single integrated application environment. That is, as discussed above, if the user clicks on a link that refers to a non-local web page or object, the user's default web browser is invoked. For Intercast, this means that the user is switched out of the Intercast application, into their web browser. In the TV Explorer model, the non-local object is displayed in-place, i.e. in the same window and/or frame as the local VBI-based content is rendered.

A related issue is flexibility of content design. Intercast fixes the TV video within a specific pane of its application window, and HTML content is relegated to the bottom pane. Microsoft's TV Explorer design lets the TV show producer decide what the screen layout should be, ranging from full-screen video with overlaid text and graphics, to nearly full-screen text and graphics with only a small TV window, placed anywhere they like, or perhaps nowhere at all.

In a very extreme case, a TV station may choose to broadcast no video at all, rather just data! On local stations, it is not uncommon for video to go dead for several hour periods overnight. The IP/NABTS model enables the full screen bandwidth to be utilized during this period -- over 650 kilobytes per second! A TV station might use this as a revenue opportunity, selling this data bandwidth to content providers that seek to blast bits to homes for whatever reason.

Although VBI data transmission is necessarily unidirectional by design, both Intel Intercast and Microsoft TV Explorer HTML pages may contain links to non-local objects or pages. If the user selects one of these, both applications will attempt to make the connection via standard Internet "back channel", e.g. modem, LAN, ISDN, etc. The link will not succeed if the PC cannot reach the Internet at that time.

This begs the question, if an Internet connection is required for back channel in the first place, why bother with HTML transmission via VBI at all? The answer is that it is believed that TV program content can be enhanced significantly fully thru the VBI data push model, and that only advanced functions will require non-local links. Examples of this include real-time chats about a TV program, product purchases, etc. Arguably, because the IP/NABTS model enables more advanced objects to be sent down the pipe in the first place, it may require back channel links less often than Intercast.

As mentioned above, Microsoft is producing an IP/NABTS client application similar to Intercast which also sends related HTML content along with TV programming. This begs the question, if HTML is going to be the primary application data format used anyway, why not just use Intercast, which encodes HTML and graphics directly into NABTS packets without data overhead introduced by packet framing and unused UDP/IP fields? For example, at least 13 bytes fields can be identified in UDP and IP packets that seem to have no purpose in IP/NABTS transmission, including type of service, or TOS (1 byte), time to live, or TTL (1 byte), protocol (1 byte), checksum (2 bytes), source address (4 bytes), UDP source port (2 bytes), and UDP checksum (2 byte). The answer is, framing and UDP/IP overhead ends up being very significant in IP/NABTS implementation, thanks to header compression.

In an RFC document submitted to the IETF, Microsoft proposes that NABTS data packets transmit UDP/IP packets encapsulated in a SLIP style serial data stream, framed using END (0xc0) and ESC (0xdb) special characters. On average, this introduces less than two bytes per packet to overhead, or around 1.07%.

The overhead of UDP/IP header data is reduced through use of Van-Jacobsen style header compression, such that average packet header length is only 11.5 bytes. So, the total overhead added to the data transmission due to framing and UDP/IP is only 3.07% (NABTS itself added 36.8% overhead), yielding an effective bandwidth 10,380 bps per NABTS line.

Given this, those 13 questionable bytes translate to less than 0.3% overhead! Hardly enough to be concerned about, relative to the flexibility benefits of UDP/IP encapsulation described above. Unfortunately, because Intel's Intercast data format is proprietary and unpublished, we are unable to compare its overhead and effective bandwidth to the IP/NABTS format described above.

In addition to the client application software, Intel provides a set of tools for content developers and broadcasters. These tools convert web pages created using standard web authoring packages into Intercast encoded data streams, and provide manual and automatic interfaces to VBI encoder devices for insertion of these streams into broadcast signals.

Microsoft has said publicly it will also provide software tools supporting IP/NABTS encoding, but there is no clear date when these will be made available.

In a nutshell, Intercast is here today -- that is, it is already delivering "eyeballs" to content producers and broadcasters. Several major broadcast networks such as MTV, QVC, and NBC are already using it in key markets to enhance their programming content. Intel is continuing to sign-up PC system vendors and TV adapter manufactures to include Intercast client support.

In contrast, Microsoft's IP/NABTS design is only at the IETF RFC stage, with no public indication by Microsoft on its expectations for availability of encoding tools, client software, etc. So, it has no "eyeballs" today, and no clear date on the horizon for when they will arrive. That said, Microsoft's statements that it will incorporate IP/NABTS client software into future versions of Windows and Windows NT, both due out within the next year, should not be taken lightly. By mid-'98, this could drive the number of IP/NABTS capable clients well ahead of Intel Intercast, depending on how good a job Intel is able to do pushing Intercast in the next year or so. This is similar to the Microsoft Internet Explorer vs. Netscape Navigator situation: every new Windows customer gets IE for free, but it takes effort to obtain and install Netscape, it is clearly evident that this situation is cutting into Navigator's market share.

The table below summarizes some of the key pros and cons of each solution identified in the previous section:

So as a content producer or broadcaster, which architecture will ultimately deliver more eyeballs in the long run, e.g. by end of '98? Should I invest design resources into Intercast now, or wait for IP/NABTS clients and tools to arrive? Moreover, what is the penalty if I choose Intercast today instead of waiting for IP/NABTS? Would the changeover be so difficult if and when IP/NABTS were to achieve the dominant client base?

Given the similarities between the fundamental content authoring requirements on either system, i.e. HTML layout, it's hard to see how this would be a very painful transition to make for producers and broadcasters. Any HTML content authored for Intercast ports easily over to IP/NABTS transmission, all that must be added to page layouts is the TV video window object. Beyond that, it is a matter of installing and learning the IP/NABTS encoding software, which will interface to the exact same VBI encoder hardware that was used for Intercast.

Given this reasoning, it would seem that the more important criteria that broadcasters and producers should use in deciding whether and when to jump into program enhancement via VBI data broadcasting is, when will there be enough VBI-capable clients to justify the investment? In fact, will there ever really be a sufficient installed base? Perhaps it's important to consider that analog TV broadcast has recently had a warrant for its execution signed by the FCC, in an effort to cause digital TV transmission to predominate no later than 2010. So clearly, analog VBI infrastructure does not have long-term viability, it is ultimately on its way out the door. This fact is arguably an advantage for IP/NABTS, in that it does not tie its client software and content format to the transmission medium. That is, the same Internet content broadcast across VBI can be transmitted via digital TV bandwidth, satellite, or the standard wired Internet, for that matter.

It is hard to argue that broadcasters and producers who believe in the fundamental concept of simul-casting Internet data along with TV programming should ignore Intercast and wait for IP/NABTS. Intercast provides a functioning platform today that enables providers to "get their feet wet" with little throwaway investment should IP/NABTS or some other format and medium prevail in the long term. The true investment here is not in the transmission medium and encoding tools, rather it is in developing the process and concepts sufficiently to deliver value-added content that TV viewers really want, and will pay money for. Intercast enables this today, and if the video/data programming concept is sound, then those who invest now will be in the best position to leverage advanced transmission protocols, networks, broadcasting schemes, etc. as they evolve.