Offload IP-based video from the CMTS to provide economic benefit.
Despite market pressures to reduce service costs, there are new opportunities for service providers to implement software and incremental technologies into existing video delivery platforms and enable new services. By efficiently managing IP service traffic, incumbent service providers can gain operational efficiencies and quickly develop new services.
Internet traffic in the U.S., and globally, continues to grow at a rate between 50 to 60 percent annually, which strains high-speed data networks with congestion. This is particularly true of the DOCSIS cable modem termination system (CMTS), initially designed for high-speed Internet (HSI) service and adapted to work with VoIP services.
This congestion risk means that the CMTS, in particular, has the potential to be overloaded by IPTV traffic. Adding new CMTS equipment to handle the growth in IPTV is both expensive and has technical limitations, and in many cases it's impractical because of the lack of space at the distribution hub to accommodate expansion.
Figure 1: Re-routing IP video = significant financial advantages.
While DOCSIS has been a huge success in HSI for service providers, there are intrinsic issues with CMTS architectures and implementations that make them ill-suited for IPTV. The CMTS was designed for a set of traffic patterns associated with HSI and VoIP, but IPTV presents a completely different set of traffic patterns. Introducing IPTV onto the CMTS could threaten to disrupt cable's existing CMTS-based service revenue, and could require massive capital upgrades.
This article proposes an alternative that offloads IP-based video from the CMTS, to provide both an economic benefit to the operator, as well as a better technical solution for IPTV delivery to customers.
IPTV TRAFFIC PATTERNS
IPTV traffic will dwarf today's CMTS traffic, which consists of HSI and voice.
Qualitatively, consider the example of how QAMs are allocated on a typical 750 MHz HFC service group today. For DOCSIS services, there are generally two DOCSIS QAMs; over the next couple of years, with the advent of DOCSIS 3.0, this will grow to six to eight DOCSIS QAMs. On that same service group today, there are about 30 digital video QAMs to deliver digital simulcast, on-demand and switched digital video (SDV).
Over the next couple of years, with the continued reclamation of analog and the addition of more HD content and long-tail programming, this will grow to about 70 digital video QAMs. As can be seen in this transition, the ratio of video QAMs to DOCSIS QAMs stays around 10 to 1; in other words, there will likely be 10 times as much digital video traffic as there is DOCSIS traffic today. This ratio is expected to remain in place, even with the conversion to IPTV over HFC.
Quantitatively, consider the following example, which uses the assumption of all MPEG-4 programming in an IPTV environment. For data consumption, assume 500 homes passed, a 65 percent take rate of a 100 Mbps data service, and a peak concurrency of 0.5 percent. This results in a peak data rate of 162.5 Mbps (500 x 0.65 x 0.005 x 100 Mbps), or enough data to use four DOCSIS carriers operating at 256 QAM.
Compare this to unicast IPTV using the same service group of 500 homes passed, a 65 percent cable take rate, 50 percent peak viewing, and an average of 10 Mbps of MPEG-4 video consumption (one HD, one SD program) at peak rates. This works out to a peak delivered bit rate to that service group of 500 x 0.65 x 0.5 x 10 Mbps = 1.6 Gbps, or enough digital video to use up 42 carriers operating at 256 QAM. In this example, at peak rates, the IPTV service will require 10 times the QAM capacity of the 100 Mbps HSI service.
The concurrency between IPTV and HSI is what makes for the great discrepancy in bandwidth usage. IPTV services require continuous use and dedication of CMTS resources for the duration of the video, where with HSI services, CMTS resource usage is bursty.
Figure 2: CMTS offload strategy requires no new equipment.
IPTV IS ABOUT VIDEO, NOT DATA
IPTV delivery can be optimized because it is inherently one-way in nature. A CMTS is inherently a two-way device, and putting massive amounts of one-way IPTV traffic through a two-way CMTS is a non-optimal use of CMTS resources. IPTV traffic can be handed off directly to a low-cost, IPTV-capable edgeQAM without the need to encumber expensive CMTS resources with this traffic.
Additionally, there are two key issues that deal with how a CMTS performs multicast stream replication for linear IPTV programming. First, existing video networking solutions have proven that program replication can be done in a low-cost edgeQAM. This is an alternative approach to using expensive CMTS resources to replicate the massive amounts of IPTV programming traffic. This function can also be accomplished in a low-cost, SDV-capable edgeQAM.
The second key issue involves the fidelity of program replication. The CMTS includes an IP router and handles a litany of functions, including necessary DOCSIS subscriber management functions. As a result, the CMTS is designed to occasionally drop packets when other processes need resources, or when congestion occurs. Dropping packets is a normal occurrence in a CMTS, and with Web surfing or e-mail, higher layer protocols in the IP stack retransmit lost packets so the user does not notice. Digital voice customers don't notice this packet loss because customer premises equipment is designed to conceal occasional packet loss.
However, with unidirectional, high-bandwidth IPTV traffic, neither retransmission nor concealment is available. A dropped video packet means macroblocking on the TV screen at a minimum, and several seconds of black screen at worst. As IPTV traffic increases, the effects of dropped video packets will multiply, causing operational issues.
EdgeQAMs are excellent at stream replication and have been performing this function for years. It is more efficient and economical for an edgeQAM to put an IPTV header on the unidirectional IPTV flows than a CMTS.
M-CMTS IS NOT NECESSARILY THE ANSWER
The modular CMTS (M-CMTS) specifications were written to enable the use of low-cost edgeQAMs as DOCSIS downstreams for wideband HSI delivery. However, the M-CMTS specs don't address the issues related to IPTV delivery.
Furthermore, with M-CMTS, the multicast program replication and DOCSIS header encapsulation still take place in the M-CMTS core, not in the edgeQAMs. Centralizing all of the processing, and thus increasing the load in the M-CMTS core, increases the probability of IPTV packet drops that impact the customer experience. The M-CMTS specifications may address wideband data, but they do not address the issues associated with IPTV delivery – either from an economic or video quality standpoint.
IPTV DELIVERY USING DIGITAL VIDEO NETWORKING
There is more than one way to implement an IPTV strategy, and using proven video networking infrastructure is a cost-effective approach.
Implementing an IPTV solution on top of existing video networking platforms makes sense because of the similarities between video networking and IP. Key to both solutions is the replication of a linear program for delivery to multiple QAM service groups, and video networking does this much more economically, and with better fidelity.
Delivering IPTV using an existing video control plane, with simple modifications to support IPTV, is a lower-risk and more scalable approach as compared with using a CMTS. By extending the existing video control plane, the technology leverages proven solutions that can enhance the customer experience with features like fast channel changes. IP-based video can be delivered at a lower total cost of ownership by leveraging existing network components. For example, in a switched environment, IP video delivery can be implemented simply with a software upgrade.
Designed to provide massive scalability with the highest levels of reliability and the most open platform for third-party interoperability, video networking solutions provide cable operators with tools to increase competitive service differentiation, improve subscriber satisfaction and maximize profitability.
E-mail: email@example.com