The word IPTV can be used in several contexts, in posting user-generated video on the Web, such as on YouTube, or in billion-dollar investments by the telephone companies to create a competitor to satellite and cable broadcast TV. Whether the application is delivering a 30-second video clip over the Internet or broadcasting a feature-length HD digital movie, the technical basis of IPTV remains the same: the delivery of digital video data using IP.
IP forms a common international language that allows a range of devices to communicate anywhere in the world over a range of physical media, including telephone wires, two-way radios and optical fiber. It was not designed, however, to deliver time-critical data as would be required for real-time playback of digital video.
To make broadcast IPTV work, several additional protocols and a lot of bandwidth are added to IP networks. The use of IP provides more than just a method to deliver digital bit streams. It also forms the basis for command and control messages that allow consumers to select content and interact in a bidirectional manner with the service delivery system. While broadcast television is passive, IPTV can be interactive. Many believe that this interactivity gives IPTV the promise of changing the business of television.
This article will provide an introduction to the basis of the IP suite and how it delivers packets of media data between devices, as well as some of the pertinent and more advanced protocols that IPTV uses in creating a television service.
The IP suite
The IP suite is a set of communications protocols that form the foundation for network communications. The term protocol stack refers to a suite of networking protocols and the actual software that executes those protocols on a specific machine.
While these protocol stacks are developed or compiled specifically for each make of computer, they have a common set of protocols between layers. In this way, an Apple computer running OS X can communicate with an IBM server running Linux, or any other hundreds of combinations. The common IP language among these computers removes the differences in operating systems, network connections and hardware architectures, including central processing chips.
IP packets
To send a digital message between any two computers on a network, the data is broken up into packets. There are two IP addresses at the beginning of each packet in the IP header: the address of the source computer and the address of the destination computer. This simple requirement enables the movement of data through the network, from the source, through intermediate routers and finally to its destination. A good analogy for IP is sending a letter via a series of postcards. The letter is broken into small packets, and each packet has a source address and the destination address attached to it. The postcards are then sent individually. (See Figure 1.)
TCP and UDP
IP defines two protocols for sending messages within IP packets. Transmission Control Protocol (TCP) is a reliable, connection-oriented protocol that guarantees reception and in-order delivery of data from a sender to a receiver. For example, if a packet doesn't arrive in time and is assumed lost, the sender will receive a request to resend that packet. Using the postcard analogy, with IP, some postcards are duplicated, and some are lost. TCP puts the postcards back in order, throws away duplicates and requests the missing ones. This is important to the delivery of compressed digital video, where the loss of a single byte can affect video and audio quality.
User Datagram Protocol (UDP), on the other hand, is a connectionless protocol that provides a best effort in getting the data to its final destination. For many real-time, time-sensitive applications, such as streaming A/V, UDP is often used instead of TCP. UDP minimizes overhead and is not affected by network data loss or delays. However, unlike TCP, UDP is not a guaranteed transport mechanism. If a packet gets lost anywhere along the line, the destination application will simply never get that data.
Why would IPTV use UDP if packets can get lost? Broadcast IPTV services using IP multicast are a good example of how UDP might be preferred over TCP. A typical MPEG-2 compressed bit stream might deliver millions of bits per second, contained in thousands of IP packets. The sending device broadcasts these thousands of packets to potentially hundreds of devices in the multicast group simultaneously. If a packet gets lost and is not received by one of the viewers, it would not make sense to halt the transmission while a request is made to resend that missing packet.
Unicast vs. multicast
IP is primarily a unicast protocol. It was designed to convey messages from a single source device to a single destination device. IP, however, also defines multicast addresses: destination addresses that represent more than one destination device. Internet Group Management Protocol (IGMP) manages multicast data flows.
From an IPTV perspective, VOD is an example of a unicast application. Data is sent from a single source — the VOD server — to a single destination — a consumer's home. For each unicast VOD session, there is a separate stream of content on the network. Each stream could be 5Mb/s for SD or up to 15Mb/s for HD video. That could add up to a huge amount of bandwidth within the network.
Figure 2 shows a broadband network with three homes playing a VOD movie. Each home has an active unicast session with a VOD server in the headend. There are three separate video bit streams flowing from the headend/VOD server to each house, along with a back channel for trick mode support, such as pause, play, fast forward and rewind.
With multicast, a single source sends data to multiple destinations at a single time. Each broadcast television channel would have a unique IP multicast group, for example. Using IGMP protocol, clients can receive the broadcast packets and enable the routing of the broadcast stream to their network device through the network. Multicast saves much more network bandwidth than unicast, but there is no reliability mechanism so lost packets stay lost.
Figure 3 shows a broadband network with three homes currently playing the same broadcast video stream of the 2006 Winter Olympics. Each home has an active multicast session receiving the same video bit stream, which originates from the headend.
Multimedia over IP
Multimedia and networking is core to IPTV. Multimedia applications use various media types, such as text, graphics, animations, audio and video. There are many network-based multimedia applications today. Furthermore, there are many bright and imaginative minds working on ideas for applications intended for high-speed bidirectional networks.
Networked multimedia applications are important, so it is critical for the IPTV network architect or content creator to understand the issues associated with multimedia networking as well as understand what tools can enable effective and compelling new applications.
Within the network, multimedia data can be affected in the following ways: dropped packets, jitter between packet delivery times, delayed packets and data corruption. Even when the TCP protocol is used, the effectiveness of the IPTV service can be affected by the reliability and speed of the network.
The goal of quality of service (QoS) is to make sure the network can deliver end-to-end data with expected and predicted results. This includes latency, error rates, up-time, bandwidth and network traffic loads.
QoS can be extremely important to a successful IPTV service within a congested network. Only service operators that also own and manage the IP network to homes can guarantee QoS for the service. IPTV services that use the general Internet are not guaranteed the QoS necessary for a good user experience.
Real-time transport protocol
IP networks were not designed for real-time delivery of data and can have unpredictable jitter and delay. The multimedia data that travels on the IP networks must arrive on time and in the same order it was sent. Real-time Transport Protocol (RTP) addresses the time-critical requirement of multimedia bit streams. It provides a timestamp and sequence number to IP packets containing media data. These can be used by the receiving device to synchronize playback and manage buffers for network jitter.
Encapsulating media data into IP packets
Delivery of media bit streams over IP requires several layers of encapsulation. MPEG-2 transport streams, for example, consist of a series of 188-byte packets. These are grouped together and wrapped within an RTP packet. Finally, the RTP packet is encapsulated within a TCP or UDP datagram, forming an IP packet.
Figure 4 shows an RTP packet containing several MPEG-2 transport packets within its payload, all encapsulated using UDP in an IP packet. This diagram shows seven 188-byte transport packets that constitute the RTP payload.
Each encapsulation adds additional header data and therefore reduces the bandwidth efficiency. If the network has sufficient QoS, it is possible to deliver media packets without the overhead of RTP. The packets are instead inserted directly into UDP packets. Figure 5 shows how MPEG-2 transport stream packets can be encapsulated within a UDP/IP packet.
Sending MPEG-2 transport stream packets over UDP is used extensively within the private networks of cable and telephone companies to deliver MPEG-2 transport streams throughout the system. For general delivery over the unmanaged Internet without QoS guarantees, streaming protocols such as RTP need to be used, but even then, packets may be lost in delivery, resulting in artifacts in the media presentation.
There are other system layer standards besides MPEG-2 and next-generation compression methods such as AVC H.264. While the encapsulation methods may differ slightly, they all require either strong QoS or overhead to ensure timely delivery of media packets.
Summary
Delivering TV and movie services over IP promises to revolutionize almost every component of the television industry. Just as the Internet changed the way we shop, read the news and personally interact, television services over IP could change how we integrate television entertainment into our daily lives. Decades old business models may change as a result of this technological shift to IPTV.
The Internet and the protocols used within it were not designed for the real-time delivery of multimedia content. Assuring the required QoS over a network may require additional protocols and additional bandwidth to overcome the inherent limitations of IP.
Tom Newberry is product development manager for Thomson, and Joseph Weber, Ph. D., is director of product management for TiVo.
