While television and the Internet have both reshaped the way we consume information, there has been very little interaction between the two.
Like seventh-grade boys and girls attending their first dance, these two dominant forms of mass communication have stood awkwardly apart at opposite sides of the dance floor. Knowing they are supposed to mix, knowing they eventually will mix, they nonetheless aren't quite sure how to mix.
We will examine the technical factors that have caused this segregation and the new and evolved tools that will make true integration of television and the Internet possible. We will explore what that new world of integration will look like, point out the winners and losers, and provide a road map for success. We will also ponder the revolutionary impact this integration will have on society.
Take a look at the cable box sitting beneath your TV. What do you see? Bulky, heavy, dated, and perhaps emanating an annoying buzz from the spinning hard drive of a DVR. Its appearance and operation, with the exception of the DVR functionality, seems largely unchanged from its predecessors of the '80s (watch 1980s Solid Gold). Now take a look at your mobile phone. Light, sleek, futuristic, like something straight out of Star Trek.
Now imagine your mobile phone as your cable box. I'm not talking just about grainy YouTube videos of someone's cat playing the piano, I mean really watching TV- NBC, ESPN, HBO. But instead of being limited to the 200 or so channels offered by your cable TV provider, you can connect your smartphone to your TV and watch your choice of hundreds of thousands, if not millions, of channels all delivered over the Internet.
Over the last decade and a half, we've seen all forms of media, information, entertainment and commerce migrate to the Internet. Yet television has been the lone holdout, principally because the technology to deliver television in a scalable and reliable way just wasn't mature enough ... until now. We now stand at a point in time where a nexus of enabling technologies are all available to deliver this vision. Will it happen? Recent history has shown that once the Internet becomes capable of carrying a particular medium, it inevitably becomes a dominant platform for that medium. It's not a question of if, but rather when.
The implications of this next generation of television - NextGenTV- go well beyond the absurdity of complaints that "there's nothing on TV." The impact of NextGenTV on societies across the globe will be seismic as this revolution will be televised.
A nexus of enabling technologies
The recent availability of new, as well as evolved technologies in consumer devices and networking capability, makes the long-theorized possibility of the NextGenTV truly a reality today. Let's examine each of the components that comprise this vision.
First, the availability of smartphones and other inexpensive Internet-connected consumer devices like Slingboxes have made it possible to deliver technical functionality that most had never dreamed of. The combination of low-cost hardware components, the ubiquity of Ethernet and Wi-Fi availability within most homes, plus common, open software platforms like the Android operating system, are accelerating the pace of innovation. The functionality found in a cable box is actually quite trivial compared to the computational flexibility that smartphones and other inexpensive consumer devices are delivering already. Outputting an Internet-based video stream can be done today without having these devices break a sweat.
The next barrier has always been the greatest - the last-mile of Internet access. In the days of dialup and low-speed DSL access, video of any decent quality was a pipe dream. However, current DSL and cable modem speeds routinely deliver 10M to 20Mbps for roughly $50 per month. Add to that the recent introduction of 4G wireless availability, and delivering one or two high-definition TV streams of reasonable quality is well within the realm of possibility for the typical consumer.
The lack of low-cost consumer video output devices and insufficient last-mile bandwidth masked another major deficiency that prevented the possibility of TV over the Internet: the Internet was not up to the task. The Internet, based on a delivery mechanism known as unicast, simply could not deliver a high-bandwidth video stream to millions of simultaneous viewers in an economical manner. However, recent protocol advancements, which simplify multicasting, have enabled the Internet infrastructure to support high-bandwidth content to arbitrarily large audiences at minimal cost to the content provider. To understand this critical component of NextGenTV, let's take a closer look at unicast, broadcast and multicast data delivery.
Unicast, broadcast, multicast
The majority of Internet traffic uses unicast data delivery. In unicast, a server transmits data directly to the client requesting it. Each client requesting data gets its own stream from the server. The cost of unicast delivery increases linearly with the audience size, as the source must be powerful enough to transmit a duplicate stream to every interested end device, and the links on the network must have enough bandwidth to handle all the duplicate streams.
By contrast, broadcast data delivery allows a server to send a single stream to the network, which will be received by all end users (whether they are interested in the data or not). For example, an old-fashioned over-the-air radio station broadcasts its signal to all radios within a given area. If a radio station were to use unicast delivery, it would transmit a separate signal to each interested listener. If there were 100 interested listeners, a "unicast" radio station would have to transmit 100 different signals. Instead, a radio station broadcasts a single signal that all radios receive.
The benefit of broadcasting traffic is most obvious for the owner of content - whether there is one listener or 1 million listeners, the cost to transmit remains the same. The disadvantage is that the traffic is sent to all users, whether they are interested or not. By comparison, unicast traffic is delivered only to users that explicitly request it. Unicast traffic will not be flooded to uninterested users.
Broadcast works well in limited geographic areas or on small networks. However, on the Internet, which connects millions of networks and billions of end devices, broadcasting traffic to all those end devices is simply not feasible. Hence, unicast is much better suited to the Internet, even if it is inefficient in delivering multi-destination traffic.
Between the two extremes of unicast and broadcast stands a third option: multicast. In multicast, the source transmits a single stream. However, the network intelligently determines where that content is desired and delivers the stream only to interested receivers. By delivering a single stream of data, a multicast source enjoys the same efficiency of broadcast in that the cost of transmission remains constant whether the audience consists of one person or a million people. And by delivering that content only to end users who are actually interested in the content, multicast enjoys a similar efficiency of unicast in that traffic is not flooded to end users who have no interest in the content. Multicast enjoys a "best of both worlds" by realizing the benefits of unicast and broadcast without suffering their deficiencies.
So what's the catch? Why isn't multicast deployed ubiquitously across the Internet? Unfortunately, multicast requires a rather complex set of protocols that determine where the interested receivers are and replicating traffic only to those end users.
In the late 1990s, there was much hope and hype surrounding multicast over the Internet. It was predicted that every dorm room could become a TV or radio station and audio/video streams would be as numerous as Web sites. Multicast advocates focused on "encouraging" service providers to deploy the protocols necessary to support multicast on their networks. Several very large service providers, such as Sprint and Level 3, deployed multicast on their Internet backbones. And on research and education networks, like Internet2, multicast became a crucial service offering. However, for various reasons, multicast deployment on downstream networks was sporadic and in most cases non-existent.
The biggest problem multicast presented was an "all or nothing" solution. Every link on the network, every router and firewall between source and receiver, required multicast protocols to be enabled. Additionally, the business model for multicast is abstract and is not an easy case to make. Multicast is an infrastructure capability that enables other services. From a business perspective, multicast resembles DNS and BGP, which are vital infrastructure protocols that are generally not billed directly. Consequently, those service providers who tried to bill for Internet multicast found disappointing results. Content providers were not interested in paying extra to transmit multicast streams that couldn't be received by many end users, and networks with many end users were unwilling to pay extra to receive multicast content that didn't exist. The result was a chicken-and-egg problem between content and audience.
It should be noted that multicast has enjoyed success in certain places. On financial networks, multicast is a vital service as applications such as stock quote data is delivered from one central market location to thousands of traders simultaneously. On some enterprise networks, multicast is equally indispensible as it is used for such purposes as transferring price lists from a central headquarters locations to thousands of local retail stores.
Additionally, multicast is often used on corporate networks to deliver live video of important corporate events, such as when the CEO speaks to thousands of remote employees. For these and many other applications, multicast has enjoyed tremendous growth in recent years on IP VPN networks. However, on the Internet, multicast deployment has been an undeniable disappointment. While roughly 10% of the Internet is enabled for multicast, given the "all or nothing" nature of multicast, in most cases that 10% might as well be 0%.
A new hope: AMT
As the efforts toward deploying multicast on Internet networks stalled, a new solution emerged. Multicast advocates began to recognize and accept the reality that "encouraging" all networks to deploy the protocols necessary to support multicast was simply not practical. These advocates then noticed that IPv6 shared the same "all or nothing" properties of multicast.
Like multicast, isolated pockets of IPv6-enabled networks existed like islands within the ocean of the (IPv4-only) Internet. IPv6 architects had spent considerable effort developing transition mechanisms that would allow these IPv6 "islands" to connect to one another across the abyss of v6-disconnectedness. Multicast architects decided to leverage/steal one such idea and apply it to the multicast problem. This solution became known as Automatic IP Multicast Without Explicit Tunnels, or AMT.
AMT has enjoyed wide popularity since its inception and is seen by multicast advocates as the last, best hope for Internet multicast. AMT accepts the reality that unicast-only networks do exist, and simply allows end users to "hop" over those networks. To accomplish this, AMT uses tunnels to connect users on unicast-only networks to content on multicast-enabled networks.
To support this model, multicast-enabled providers deploy AMT Relays at the edge of their networks. These relays act as the tunnel endpoints that "translate" native (untunneled) multicast content to users on unicast-only networks. An AMT Relay can be a standalone server, or more commonly, can be functionality added to existing edge routers on a multicast network.
Users on the unicast-only network sit behind AMT Gateways, which use an autodiscovery mechanism known as anycast to locate the nearest relay and then initiate a multicast tunnel to this relay. The gateway then requests a multicast stream of interest through the tunnel.
The relay receives the request and joins the multicast content using standard multicast routing protocols. The multicast stream is forwarded through the multicast-enabled network to the relay which forwards the stream over the tunnel to the gateway. The AMT gateway can be software run on the actual host PC or can be run on a home router which acts as gateway for all hosts at the home site (for example, if there are multiple computers in the home).
The result is that users on unicast-only networks receive multicast content. No action is needed by the end user's provider - the end user simply hops right over that uncooperative network to join the party on the multicast island. As a side benefit, the unicast-only network provider will begin to notice more of these AMT streams being tunneled over their network. This will be motivation to add multicast support to the network, as it will eliminate duplicate streams of tunneled (unicast) data and utilize the network more efficiently.