First things first: the venerable set-top box, on its way out in the cable world, will make a resurgence in IPTV systems. The box will connect to the home DSL line and i
…s responsible for reassembling the packets into a coherent video stream and then decoding the contents. Your computer could do the same job, but most people still don't have an always-on PC sitting beside the TV, so the box will make a comeback. Where will the box pull its picture from? To answer that question, let's start at the source. Most video enters the system at the telco's national headend, where network feeds are pulled from satellites and encoded if necessary (often in MPEG-2, though H.264 and Windows Media are also possibilities). The video stream is broken up into IP packets and dumped into the telco's core network, which is a massive IP network that handles all sorts of other traffic (data, voice, etc.) in addition to the video. Here the advantages of owning the entire network from stem to stern (as the telcos do) really come into play, since quality of service (QoS) tools can prioritize the video traffic to prevent delay or fragmentation of the signal. Without control of the network, this would be dicey, since QoS requests are not often recognized between operators. With end-to-end control, the telcos can guarantee enough bandwidth for their signal at all times, which is key to providing the "just works" reliability consumers have come to expect from their television sets. The video streams are received by a local office, which has the job of getting them out to the folks on the couch. This office is the place that local content (such as TV stations, advertising, and video on demand) is added to the mix, but it's also the spot where the IPTV middleware is housed. This software stack handles user authentication, channel change requests, billing, VoD requests, etc.-basically, all of the boring but necessary infrastructure. All the channels in the lineup are multicast from the national headend to local offices at the same time, but at the local office, a bottleneck becomes apparent. That bottleneck is the local DSL loop, which has nowhere near the capacity to stream all of the channels at once. Cable systems can do this, since their bandwidth can be in the neighborhood of 4.5Gbps, but even the newest ADSL2+ technology tops out at around 25Mbps (and this speed drops quickly as distance from the DSLAM [DSL Access Multiplier] grows). So how do you send hundreds of channels out to an IPTV subscriber with a DSL line? Simple: you only send a few at a time. When a user changes the channel on their set-top box, the box does not "tune" a channel like a cable system. (There is in fact no such thing as "tuning" anymore-the box is simply an IP receiver.) What happens instead is that the box switches channels by using the IP Group Membership Protocol (IGMP) v2 to join a new multicast group. When the local office receives this request, it checks to make sure that the user is authorized to view the new channel, then directs the routers in the local office to add that particular user to the channel's distribution list. In this way, only signals that are currently being watched are actually being sent from the local office to the DSLAM and on to the user. No matter how well-designed a network may be or how rigorous its QoS controls are, there is always the possibility of errors creeping into the video stream. For unicast streams, this is less of an issue; the set-top box can simply request that the server resend lost or corrupted packets. With multicast streams, it is much more important to ensure that the network is well-engineered from beginning to end, as the user's set-top box only subscribes to the stream-it can make no requests for additional information. To overcome this problem, multicast streams incorporate a variety of error correction measures such as forward error correction (FEC), in which redundant packets are transmitted as part of the stream. Again, this is a case where owning the entire network is important since it allows a company to do everything in its power to guarantee the safe delivery of streams from one end of the network to the other without relying on third parties or the public Internet. Though multicast technology provides the answer to the problem of pumping the same content out to millions of subscribers at the same time, it does not help with features such as video on demand, which require a unique stream to the user's home. To support VoD and other services, the local office can also generate a unicast stream that targets a particular home and draws from the content on the local VoD server. This stream is typically controlled by the Real Time Streaming Protocol (RTSP), which enables DVD-style control over a multimedia stream and allows users to play, pause, and stop the program they are watching. The actual number of simultaneous video streams sent from the local office to the consumer varies by network, but is rarely more than four. The reason is bandwidth. A Windows Media-encoded stream, for instance, takes up 1.0 to 1.5Mbps for SDTV, which is no problem; ten channels could be sent at once with bandwidth left over for voice and data. But when HDTV enters the picture, it's a different story, and the 20-25Mbps capacity of the line gets eaten up fast. At 1080i, HDTV bit rates using Windows Media are in the 7 to 8 Mbps range (rates for H.264 are similar). A quick calculation tells you that a couple of channels are all that can be supported. The bandwidth situation is even worse when you consider MPEG-2, which has lower compression ratios. MPEG-2 streams will require almost twice the space (3.5 Mbps for SDTV, 18-20 Mbps for HDTV), and the increased compression found in the newer codecs is one reason that AT&T will not use MPEG-2 in the rollout of its IPTV service dubbed "U-verse." Simultaneous delivery of channels is necessary to keep IPTV competitive with cable. Obviously, multiple streams are needed to support picture-in-picture, but they're also needed by DVRs, which can record one show while a user is watching another. For IPTV to become a viable whole-house solution, it will also need to support enough simultaneous channels to allow televisions in different rooms to display different content, and juggling resulting bandwidth issues is one of the trickiest parts of implementing an IPTV network that will be attractive to consumers. (MORE) 
