The World Wide Web
In addition to video services, the second market driver for RBB networking is access to the World Wide Web.
According to Matrix Information and Directory Services and Network Wizards , two authoritative sources of Internet statistics, the Internet consisted of 43,230,000 "advertised" connected computers (hosts) in 214 countries and territories as of January 1999. Because of the unknown numbers of multiuser computers and network or application gateways, it is not possible to correlate the number of hosts with the number of end users. However, market surveys estimate the number of active Internet users at well over 100,000,000 worldwide. (See the MIDS estimates at www.mids.org. ) The current Internet annual host growth rate is 46 percent, which extrapolates to 100 million hosts by the second quarter of 2001.
Anecdotes abound, but an interesting set comes from the Olympic Games. IBM has been the official Web host for recent Olympic games. In 1996, the Olympic Web site for the Atlanta summer games registered 187 million hits. During the 1998 winter Olympic games in Japan , the Web site registered 650 million hits over 16 days. More than 2 billion hits are expected for the 2000 summer games in Sydney, Australia.
Furthermore, electronic commerce (e-commerce) is firmly established as a viable retail alternative for mass-market consumers. Consumers are less fearful of security, which is, after all, no worse than giving your credit card to a waiter in a restaurant and having that person disappear with it for a few minutes. Also, the mere hint of a retailer selling goods and services over the Internet sends its stock price soaring. Major examples are Amazon.com (books, videos, and CDs), eBay (auctions), RightStart (infant merchandise), Ticketmaster (tickets), and dozens of others. Online services provide retailers other benefits, such as chat rooms, where people can discuss their purchases, pointers to background information, and comparison pricing. The Internet is completely revising retailing because of convenience, interactivity, and selection (and, in part, because of the exemption of online sales from sales tax).
As Web content becomes more tailored to fast networks—for example, by including more audio and video—we need to consider some practical obstacles to further scaling the Web to consumer market proportions (see Table 1-6).
| U.S. Households (millions) | Computer Households | Internet Households | |
|---|---|---|---|
| 1997 | 99.9 | 42.0 | 25.1 |
| 1998 | 100.9 | 45.0 | 33.5 |
| 1999 | 102.0 | 48.0 | 40.7 |
| 2000 | 103.1 | 50.0 | 47.8 |
| Source: Veronis, Suhler, and Associates |
Key Issues of the Web
While millions of users browse the Internet, concerns exist as to its scalability to substantially larger audiences. Among the concerns are congested Web servers, long holding times, and high signaling rates. An approach to server congestion known as Web caching is discussed in Chapter 8, "Evolving to RBB: Systems Issues, Approaches, and Prognoses."
Holding Times
Holding time is the duration of a connection, during which resources (such as buffers), bandwidth, and control variables (such as indexes into databases) are held for the exclusive use of the client. Long holding times negatively impact the number of users that can be serviced simultaneously by the end-to-end system.
Web sessions tend to be longer in duration than voice sessions. This creates problems for telephone companies, which provide transit for data calls from modems or ISDN connections. These calls go through voice telephony switches. Call lengths have increased from about 3 minutes per voice call to more than 20 minutes per data call. Longer holding times through the voice switch increase the blocking probability per call (measured in probability of a busy signal) and eventually force the telephone company to buy additional voice switches to maintain grades of service mandated by their respective public utility commissions (PUC). Voice switches are much more expensive than data switches, so telephone companies have a strong incentive to offload the data calls from voice switches to data switches or routers.
The solution is to have a new class of access networks, such as cable TV (see Chapter 3, "Cable TV Networks" ) or the new generation of digital subscriber line technologies (see Chapter 4, "xDSL Access Networks" ), which do not need the services of voice switches for data traffic.
Signaling Rates
Signaling refers to mechanisms by which one entity, such as a user application, communicates with another entity, such as a network, for control purposes. Examples of signaling are connection setup (such as picking up a phone to make a voice call), connection release (hanging up the phone in the voice scenario), or requests for some service characteristic, such as resource reservation.
Signaling is difficult and slow. Signaling rates, such as connection setups per second, are measured in dozens per second. For example, state-of-the-art ATM switches can do no more than a hundred or so call setups per second. These numbers compare unfavorably with a router, which has no call setup process for many applications and can move hundreds of thousands of packets per second.
Web access imposes strong signaling requirements on networking systems. Some experts predict a signaling crisis in networking systems because of the incapability of networks of all types to support signaling events calibrated in the hundreds or thousands per second, the scale required of RBB systems. Mechanisms must be found to reduce signaling rates for RBB to scale.
Convergence of Digital Television and the Internet
Computer issues may have been taken into account late in the process of the Grand Alliance's planning, but today they are omnipresent. In particular, the Internet's tremendous growth is already influencing digital TV.
From the point of view of viewer experience, current thinking on convergence of DTV and the Internet is to embed NTSC-quality or higher-quality video streams inside Web pages, much like JPEG images are part of Web pages. The controlling software for the viewer is the browser, just as it is for the Web today. The author of the Web page displays a motion picture at a specific pixel position on the screen of a certain size. A set of control protocols must be embedded in the Web page, which organizes the display of the video. Proprietary schemes exist to do this today, such as WebTV, recently purchased by Microsoft. But WebTV is a proprietary platform, and there are movements afoot to standardize the display video in Web content.
Issues of Convergence
Current digital boxes do not have the memory and programming capability to run Web browser software. The set top box in the home must be replaced in those home that have an analog descrambler. In homes in which there is no set top box (for example, homes with cable-ready televisions and homes that don't pay for premium channels), a new box must be obtained by the consumer. The commercial question arises as to whether the network operator provides the new set top box or whether the consumer buys it at retail.
Web site images transfer poorly to TV because TV is designed to display a relatively low resolution image. Conversely, computers display high resolution, so the crisp images one is accustomed to seeing on a PC monitor will seem fuzzy on a lower-resolution TV monitor.
The Internet is full of software bugs and viruses because applets are part and parcel of the Web experience. Internet service providers are not generally taken to task by the consumer if problems are caused in the home computer by a virus. But TV broadcasters and cable operators will probably not be as fortunate.
To addresses these problems, two camps are looking at the problem: ATSC (mentioned previously) and the Advanced TV Enhancement Forum (ATVEF; www.atvef.com ). ATSC has three working groups:
S13, focused on the packaging of data in the downstream path
S16, focused on the reverse path
S17, focused on content development and authoring tools
ATVEF is less ambitious and, some would say, more realistic. This group is focusing on content authoring and will use S13 and S16 work from ATSC for the networking.
ATSC Specifications
Before proceeding with discussions of these protocols, let's first describe system assumptions for the ATSC data broadcasting specification. The ATSC Data broadcast system diagram is shown in Figure 1-6.
Figure 1-6. ATSC Data Broadcast System Diagram Head-End and Intermediate Diagram/Assumption
Head-end and intermediate entities need to (re)generate the channel multiplex. For example, a network may multiplex two shows and a stock ticker onto one channel, and local stations often will need to replace portions of the national feed with local material. This must be accomplished within the throughput latency and data rate limits of all components of the national broadcast passed through. End-to-end system latency is one of the key constraints of system design, especially when local content (emergency broadcasts, secondary audio such as language dubbing, and local advertising) are spliced in.
Receiver Diagram/Assumptions
Receivers are assumed to vary greatly in the number of services they are capable of presenting and their capability to store data or process it in some meaningful way. Some may decode and present several audio/video broadcasts along with multiple data services. Others may be designed to perform a single function (such as delivering a stock ticker) as inexpensively as possible. The buffering requirements in the residential gateway must accommodate both environments.
S13 Issues Addressed (Unidirectional Service)
S13 has defined four profiles for the delivery of data. These are summarized in Table 1-7. Opportunistic bit rate takes advantage of spare bandwidth left over from the variable bit rate MPEG streams, and therefore latency cannot be specified.
| Profile Name | G1 | G2 | G3 | A1 |
|---|---|---|---|---|
| Maximum bit rate | 384 Kbps | 3.84 Mbps | 19.39 Mbps | 19.39 Mbps |
| Maximum latency | 5 seconds | 10 seconds | 10 seconds | unspecified |
| Bit rate guarantee | yes | yes | yes | no |
In addition to speed and latency, S13 defines a flow-control mechanism between the Broadcast System Provider and the Interactive System Provider, an encapsulation protocol, and a fragmentation protocol.
Synchronous and Synchronized Streaming Data
The ATSC supports synchronous and synchronized data. Synchronous data streaming enforces timing requirements within a single stream. Synchronous data streams are characterized by a periodic interval between consecutive packets so that both the maximum and minimum delay jitter between packets is bounded in a manner such that data is continuous. Synchronization is achieved by regenerating data and clock at the receiver. Synchronous data streams have no strong timing association with other data streams.
On the other hand, synchronized data streaming has the same intrastream timing requirements as does synchronous data streaming, with the additional requirement that the datastream be synchronized with the bits on a different stream.
Differences Between Streaming and File Transfer
Computer people tend to use the term file transfer when characterizing an application in which a file of information moves from one computer to another. In fact, the major protocol for doing so is called the File Transfer Protocol (FTP), first codified as RFC 765 (Jon Postel, 1980) and RFC 959 (Postel and Joyce Reynolds, 1985). This protocol goes back a ways, and the concept is well understood.
Digital media professionals use the term streaming when characterizing video feeds from a server or camera to a viewer. Both file transfer and streaming refer roughly to the same capability—the bulk transfer of bits from one hardware device to another—but key differences impact the networking tabulated in Table 1-8.
| File Transfers | Streams | |
|---|---|---|
| One-way/two-way | Requires a bidirectional network; one direction is used to request the transfer. | Can be used over a unidirectional network. Streams can emanate from the source without client request. |
| Completeness | The receiver cannot jump into the middle of a file transfer and have anything useful. To use the file, the receiver must wait until the last bit is received and then use the data from the stored medium. | The receiver can jump into the middle of the stream. The receiver will miss the earlier content, but the remaining bits will make sense. |
| Real-time | Not required. A receiver can request a file now and begin receiving it later, and view or use the file at a later time. | Always in real-time. The stream is flowing now, and the receiver must receive it now. If not, the stream must be stored for later viewing, in which it looks much like file transfer. |
| Jitter tolerance | Relatively high. File transfer can experience variable delay because the file is stored before use. | Relatively low. Timing jitter will make the picture or audio quality degrade. If jitter is high, the stream must be stored for later viewing. |
| Synchronization | File transfers are autonomous entities, normally unrelated to other file transfers. | Often required. This means that a given stream must be synchronized with another, as in the case of a video stream synchronized with a corresponding audio stream (lip sync). |
S16 Issues Addressed (Interactive Mode)
The problems for defining an effective standard for interactive service protocol can be highlighted by key questions as posed by S16's charter:
How can broadcast receivers discover interactive services?
For the forward channel, how will interactive services identify items of information, and how will information be organized?
Given the likely range of lower-functioning receivers/set tops in the early years, what interactive services protocol is needed near term that can scale as higher-functioning receivers become available?
For the return channel, what signaling protocols and what return path media will be used?
How will hyperlinking work across multiple streams? What is the URL for a video stream? What is the URL for a TV program or a composite piece (for example, the video stream or the secondary audio stream) of the program?
Figure 1-7. ATSC S16 Schematic
S17 Issues to Be Addressed (Authoring)
The controversial work of ATSC is done in S17, which addresses some of the previous issues, such as characterizing URLs for video streams. Authoring and software development environment is the locus of disagreement with ATVEF. The basic question is how to create TV images using Web tools. Can the author of DTV content use variations of HTML and expect the set top to render TV images in Java, JavaScript, Shockwave, Realmedia, and other plug-ins?
Two major approaches exist supported by two strong groups: the ATSC Digital Television Applications Software Environment (DASE; www.toocan.philabs.research.philips.com ) and the Advanced TV Enhancement Forum (ATVEF; www.atvef.com ). ATVEF is supported by Microsoft, Intel, and several content developers, such as Time Warner.
DASE
DASE is the S17 subcommittee of ATSC and was the first U.S. standards organization to look at DTV authoring.
The requirements addressed are listed here:
Support for synchronous and synchronized streaming and file transfer.
Identification of new typed objects for TV controls and video streams.
Support for either triggered or self-timed objects. That is, without the intervention of the viewer, the source should send objects based on some event, such as a timer.
Receiver that knows when to start decoding and when to present data.
Content that can be prepackaged or locally inserted, or a combination.
Concepts that can be reused over IP transport (authored content that can be reused on Web pages).
End-to-end transfer of bits that exhibits deterministic behavior.
Pixel accurate placement of objects on interlaced and proscan monitors.
Images that provide the identical look as TV; this means alpha blending, or the capability to view dissolves and fades and exhibit translucency.
Tight control of the stream by the sender. This means that when a stream containing links is initiated, the viewer is constrained as to the hyperlinks she can use. This is very different from the Internet. Advertisers and broadcasters want viewer control. Certainly, the viewer can tune to another channel, but when a viewer is on a channel, her latitude is restricted to the URL options made available by the broadcaster/service provider.
To fulfill these requirements, the DASE group specified an execution environment in the set top box. It assumes a Java Virtual Machine (JVM) exists in the set top and that the programmer will transmit Java commands for the set top to execute. This approach also enhances the Hypertext Markup Language (HTML), now used to author Web pages, to create a new markup language called Broadband HTML (BHTML) with specific hooks for TV. The features of would be these:
Is based on HTML 4.0, but compatible with HTML 3.2
Leverages use of Extended Markup Language (XML)
Offers lots of new semantics for video
Has tight integration with Java and operates as a plug-in
Integrates with VRML and MPEG-4
Uses a small footprint, less than 100 KB
Renders pixel-accurate placement of images on interlaced and progressive scanned monitors
A BHTML author should be able to connect hyperlinks to TV functions such as channel selection (as well as connecting hyperlinks, such as crossover links, to browser functions). These and other TV functions are suggested. Accordingly, the HTML player runs on a set top TV or digital TV, not a PC.
The problem with the DASE approach is that it does not leverage the existing base of HTML documents and authoring tools. There will be a major retooling of the Web development environment to use BHTML.
ATVEF
The criticism of DASE is that it is overambitious and does not adequately leverage the current Web-authoring environment. In particular, Intel and Microsoft, along with content companies, worry that the DASE process has gone to far in specifying content authoring. Rather than having an execution environment in the set top box, they prefer to have only a presentation environment, namely HTML. They believe that all that is needed for standardization is a set of application program interfaces for standard tools. Therefore, a rival organization was established to use more off-the-shelf components rather than enhancing HTML.
ATVEF's proposal uses JavaScript, Cascade Style Sheet, and HTML in lieu of BHTML. Certain improvements for video will be accomplished with enhancements to HTML, called Dynamic HTML (DHTML), which is viewed as less disruptive than BHTML.
DASE proponents counter that ATVEF is deficient in a number of respects:
ATVEF fails to offer pixel-accurate positioning on the monitor.
ATVEF cannot validate content. Broken HTML links cannot be determined a priori.
Worse yet, broadcasters purportedly require that viewers do not have carte blanche surfing capability. This is for two reasons: to prevent kids from watching pornography, and to make sure that viewers are watching Web pages linked to the TV broadcast. Viewer control is key.
ATVEF does not provide for tight timing synchronization among video and text due to the absence of end-to-end timing markers, which can be decoded in the set top box.
The reason for the discussion of authoring and rendering in the DTV world is to provide an understanding of what will be perhaps the key software struggle of RBB. That is, what will the software environment be for the digital set top and the residential networking gateway? Microsoft has clearly won the desktop. The set top represents the next battle. It's Microsoft versus Japan versus U.S. cable set top manufacturers versus embedded systems in the struggle for consumer applications over TV. It makes for good theater, and to the winners will go tremendous market value.