The largest area of technical debate in IPTV is just what IP infrastructure’s role would be. There are two basic approaches. The first is an IP metro infrastructure and the second is a tunnel-based metro infrastructure. In the former, which is currently championed by Alcatel-Lucent, the customers premises are actually on an IP network, assigned an address by a Dynamic Host Configuration Protocol (DHCP) process. This IP network supports multicasting, and broadcast channels are multicast using the standard IGPM join/prune architecture. In the second, which most other vendors seem to support, a broadband remote access server (BRAS) — usually placed well forward, even into the central office — performs the channel assignment process. In both cases, the customers have some predetermined number of “slots” into which broadcast or VoD programming can be inserted.
The challenge posed by any data-delivered broadcast architecture is the traffic management, which means metro aggregation must be carefully planned. Any form of streaming video is highly sensitive to jitter and even more sensitive to packet loss, since loss of frames in MPEG coding can create noticeable pixelization. In rough terms, a hundred broadcast channels will require about 1 Gbps of transport. A key question is the size of a central office (CO) in terms of the number of households served. A typical CO of 20 thousand households will likely consume about 30-50 active channels at a time, and the variability of the load will be relatively small. Larger COs are even more likely to have relatively predictable traffic patterns, but small COs may show heavy swings in load as viewing patterns change. Major live events will also influence viewing patterns and thus traffic.
Video compression is normally used for delivering video payloads over any data protocol, and there are trade-offs associated with compression technology. As noted below, data loss in compressed video has a significant impact on quality and thus networks using compressed video must guard against packet loss, if possible through a combination of traffic engineering and hold-back buffering. Take a look at https://insightiptv.com/home.html to get for info on this topic. It is also important to look closely at the insertion delay associated with the code/decode process and to insure that video compression doesn’t cause problems with details like audio track synchronization. A careful analysis of compression standards and options is in order, but the industry is zeroing in on MPEG-4 compression for HD programming, and networks should be designed to assume that. There wills still be variability in the way that various MPEG-4 coders and decoders perform, so testing the combinations will be important before any major decisions are based on compression assumptions.
It’s also important to plan for transition to a greater percentage of VoD traffic over time. Some research shows that customers are becoming more “on-demand” oriented as a result of their experience with the Internet in general and with Internet video in particular. This shift in viewing patterns can create a major problem in traffic management, since VoD streams are not likely to be suitable for multi-household distribution. A CO of 20,000 homes might require only about 450 Mbps of broadcast bandwidth but would consume a staggering 200 Gbps if only one VoD per household were watched at a time.