Content

Video Quality in Service Provider IPTV Deployments – Cisco Visual Quality Experience (VQE)

by Mihail Guguvčevski, CCSI, Instructor at NIL Data Communications Ltd

Introduction

This article describes many of the issues with service provider Internet Protocol television (IPTV) deployments and how Cisco combats these issues with a state-of-the-art solution: Visual Quality Experience (VQE). The core function of Cisco VQE is maintaining the quality that former analog or cable TV consumers expect from the new IPTV method of content delivery. Cisco VQE is targeted mainly to wireline IPTV service providers. In the following discussion, you’ll learn about the problems that IPTV wireline service providers face, and the Cisco way of solving them quickly, successfully and with minimal overhead. You’ll also find out more about the Cisco VQE solution, its core features and benefits and the inner workings of its architecture.

IPTV Delivery Challenges – Network Anomalies

The set of issues resulting from delivery challenges so firmly nested in the IPTV starts with the combination of two incompatible technologies: real-time video delivery and IP. Putting every type of traffic on top of IP is an excellent and advanced idea when considered from aspects such as capital expenditure, operating expenditure, compatibility, simplicity, ease of management, fast churn time and many others. Unfortunately, most engineers ignore one very important fact: IP was not designed for reliable and real-time delivery of data, regardless of what that data actually represents.

When you take video into consideration, these delivery challenges deepen and widen even more. Video is intolerant of network factors such as jitter, delay and especially packet loss, because a single IP packet carries up to seven MPEG transport frames. Therefore, IP networks require additional functionality in order to deliver the video quality expected by subscribers. The accepted industry benchmark for quality is to deliver a maximum of one video "artifact" (perceived distortion) during the viewing of a one-hour movie. This level of quality translates into a network-layer requirement of a loss of fewer than 7.8E-7 video packets.

You can easily see the issue: a fairly small number of access networks are designed for such performance.

The complete glass-to-glass delivery of video consists of video packet flow through different parts of the network, using a set of different Layer 1 and Layer 2 technologies. Network anomalies in the core network leading to high video-packet losses are correlated events that impact many subscribers.

Correlated events – impact many subscribers:

- Link or node failures
   - APS convergence event
   - MPLS Fast Reroute
   - IGP Fast Convergence
- Multiple IPTV packet losses
- Typically low-frequency events

Given the bandwidth requirements of an MPEG2 Standard Definition video stream at 3.75 Mb/s, the actual packet rate is approximately 333 packets per second. An APS convergence event, for example, will result in a 50 ms interruption of flow, representing a loss of a minimum of 17 video packets. Network anomalies in the access network leading to low video-packet losses are uncorrelated events that impact few subscribers.

Uncorrelated events – impact few subscribers:

- Impulse noise on transmission lines
- Poor-quality internal wiring
- Single or multiple IPTV packet-loss events
- Typically high-frequency events

Figure 1:

Network anomalies – correlated and uncorrelated events

The Cisco VQE solution addresses the challenges of uncorrelated error events in the access portion of the network, using two approaches and technologies:

Low-overhead Application-Level Forward Error Correction (AL FEC)

Selective Real-Time Transport Protocol (RTP) retransmission

IPTV Delivery Challenges – Channel Change Time

A second issue that affects IPTV video quality is channel change time (CCT). Consumers have become used to the current CCT—which is less than two seconds—offered by digital cable and digital satellite services. Several factors can contribute to longer IPTV channel change times, including Internet Group Management Protocol (IGMP) delays, MPEG decoding delays and I-frame acquisition time. Non-optimized IPTV channel change times can take several seconds. Channel change times as long as five seconds have also been observed.

Figure 2:

Channel change latency factors


Cisco VQE Solution Positioning

VQE addresses the issue of video quality from both network infrastructure and video technology perspectives. First, VQE provides the linkage to optimize video delivery over next-generation carrier networks. Second, VQE is based on industry standards, including Real-Time Transport Protocol (RTP) and RTP Control Protocol (RTCP). Cisco VQE provides the following mechanisms to help in delivering entertainment-grade services to subscribers:

Unicast Retransmission—Optimized, selective retransmission of dropped IPTV packets caused by noisy DSL lines or errors in the home network caused by poor-quality wiring. From the set-top box (STB) receiver, the VQE client (VQE-C) sends NACK packets to the VQE server (VQE-S) to request retransmission of the lost packets.

Forward error correction (FEC)—Extra information is sent along with the video data at the application layer. The additional information is used by the VQE-C on the STB to detect and correct lost packets.

Rapid channel change (RCC)—When the subscriber requests a channel change, the VQE-C on the STB sends the VQE-S a request for the new channel's IPTV packets. The VQE-S sends the VQE-C an optimized unicast burst of IPTV packets and other channel information from the VQE-Ses' cached video data for the new channel. This design greatly reduces the time needed to display the new channel.

IPTV packet-loss monitoring—Facilities such as the VQE server's RTCP Exporter help operators measure, baseline and pinpoint problem areas of the video infrastructure, including transmission lines and home networks.

The two error-repair options, Unicast Retransmission and FEC, can be used separately or together (forming Hybrid Error Repair). Each repair mechanism has advantages and limitations. Whether Unicast Retransmission, FEC or a combination of both is used, the subscriber does not detect the error repair and no video artifact results.

Figure 3:

Visual Quality Experience network diagram

Two major VQE software components implement Unicast Retransmission, FEC, RCC and IPTV packet-loss monitoring:

VQE-C—Software embedded in the subscriber's customer premises equipment (CPE)—typically a set-top box. The VQE-C provides the CPE interface to the VQE-S to support Unicast Retransmission, RCC and IPTV packet-loss monitoring statistics. The VQE-C receives the primary media data packets and, if FEC is enabled, one or two streams with FEC packets. When the VQE-C software detects packet loss on a channel that is configured for FEC and Unicast Retransmission, the following occurs:

If there are packet losses in the primary media stream, the VQE-C first tries to repair the lost packets by using the FEC streams.

If some packet losses cannot be corrected by FEC, the VQE-C requests a Unicast Retransmission of the missing packets from the VQE-S.

VQE-S—Software that runs on a Linux-based Cisco Content Delivery Engine 110 (CDE110) appliance located in the intelligent edge of the service provider's network. For Unicast Retransmission and RCC, the VQE-S caches primary video packets from an encoder or other headend device.

For Unicast Retransmission, working with the VQE-C, the VQE-S monitors the subscriber's reception of video packets and uses its cached video data to service Unicast Retransmission requests from the VQE-C on the STB.

For RCC, when the subscriber requests a channel change, the VQE-C on the STB sends a request for a new channel to the VQE-S. To service the RCC request, the VQE-S sends the VQE-C a unicast burst of video packets from its cached video data for the channel and also sends some MPEG priming information to facilitate immediate decoding.

With both Unicast Retransmission and FEC, the missing packets are re-sequenced by the STB without interruption.

The VQE-C is available on Cisco STBs running Scientific Atlanta IPTV Layer (SAIL) 1.x and 2.x. The VQE-C can also be integrated into an STB from third-party vendors. The VQE-C code and Software Development Kit (SDK) are available through an open-source program.

Cisco VQE Error-Repair Technique

Cisco VQE technology uses selective retransmission of requested packets to implement error repair for video packets. Whether FEC is implemented or not, a prerequisite for error repair with selective retransmission is the encapsulation of multicast packets transmitted from the source in RTP.

Each IPTV packet has a unique RTP sequence number. The VQE-C on the STB checks the RTP sequence numbers of each incoming packet, looking for missing RTP sequence numbers in the de-jitter buffer. If a packet gets corrupted during transmission over a noisy DSL line, the VQE-C identifies it as a missing sequence number in the de-jitter buffer. The VQE-C on the STB communicates with the VQE-S by using RTCP messages, requesting retransmission of missing packets. The VQE-C can request up to 17 packets in a single transaction. After the VQE-C receives the missing video packets from the dedicated VQE-S, the packets are spliced into an appropriate position in the jitter buffer. The process of error repair occurs prior to the point when the video packets are transmitted to the MPEG demultiplexing stage. The process of retransmission for error repair is completely transparent to the subscriber.

Figure 4:

Cisco VQE error-repair process


Cisco VQE Rapid Channel Change Technique

The goal of RCC is to reduce or eliminate the main sources of channel change delay. With RCC, the resulting channel-change delay is similar to or better than the delay observed in a typical digital broadcast.

The main challenges that the Cisco VQE solution faces when implementing rapid channel change are congestion avoidance and excellent operation in low-bandwidth environments. Cisco's solution is to send unicast data from the VQE-S in two-phase, carefully shaped bursts so as not to congest the access network:

Phase 1: The unicast burst starts at an increased rate, up to a configured excess rate.

Phase 2: The unicast burst rate is decreased before the start of the multicast stream coming from the headend.

The final result is that, at any given point, the multicast and unicast streams' combined rate does not exceed the available bandwidth for video.

For RCC, the VQE-S caches multicast IPTV packets corresponding to each channel. Each cache holds a few GOPs (Group of Pictures) of video data as well as PAT (Program Association Table), PMT (Program Map Table), ECM (Entitlement Control Message), PCR (Program Clock Reference) and sequence information.

Each channel change request is considered as a special case of retransmission. Instead of a few packets, the STB is requesting a whole set of “lost” or new packets for the new channel.

The VQE-C sends an RTCP standard message, NACK-PLI (Packet Loss Indication), which initiates a channel change. After it has sent the RTCP message, the VQE client issues an IGMP join for the new channel at an optimal point in time.

On receiving the NACK-PLI message, the VQE-S sends the decoder priming information, and unicasts everything from the previous I-frame onward at a speed faster than real-time.

Figure 5:

Managing bandwidth for rapid channel change


VQE Browser-Based Tools

The Cisco VQE solution is usually part of the middleware in IPTV network deployments. For many new opportunities, integrating the complete set of configuration and monitoring tools into existing middleware could be a time-consuming and overwhelming task. This is why Cisco offers three browser-based tools: the VQE Channel Provisioning Tool (VCPT), the VQE-S Application Monitoring Tool (AMT) and the VQE Client Configuration Delivery Server (VCDS) AMT.

The VCPT is an optional channel-provisioning utility to aid with the channel lineup configuration required by both the VQE-S and the VQE-C. The channel information is in Session Description Protocol (SDP) format. The VCPT sends the channel information to the VQE-Ses and VCDSes. The VCDSes provide the channel lineup or network configuration to the VQE-Cs on the STBs.

The VQE-S AMT is a browser-based GUI that displays configuration, status and statistics on the VQE-S processes, the channel lineup, Unicast Retransmission, RCC, Ethernet interfaces and VQE-S RTCP Exporter. The VQE-S AMT also allows you to configure debugging and logging facilities.

The VCDS AMT is a browser-based GUI that displays configuration, status and statistics on the VCDS and VQE Tools server. The VCDS AMT also allows you to configure debugging and logging facilities.

Figure 6:

VQE-S AMT displaying statistics for VQE-S

The VQE-S and the VCPT are bundled software and hardware solutions. The VQE-S and the VCPT run on separate Cisco CDE110 appliances. A typical network consists of multiple CDE110s hosting the VQE-S and one or two CDE110s hosting the VCPT, VCDS AMT and VCDS.

The VCPT GUI has a clone capability to simplify and expedite channel information. When the service provider uses the VCPT to define the set of the VQE-Ses that receive the channel information, the VQE-Ses can be grouped based on channel lineups. Using separate VCPT configuration files makes it possible to manage multiple deployments. For example, one VCPT configuration file might be for the channel lineup in one metro region, and another VCPT configuration file might be for the channel lineup in another metro region.

Figure 7:

VCPT channel definition

When the user completes channel, server and channel-lineup configuration and initiates the VCPT send operation, the VCPT sends the channel information in SDP format to the set of VQE-Ses, the VCDS or a remote server.

Figure 8:

VCPT sending channel information to VQE servers and VCDSes


Content Delivery Engine 110

Cisco VQE-S runs on one Cisco Content Delivery Engine 110. If the VCPT and the VCDS are used, another Cisco CDE110 hosts those two facilities. The Cisco CDE110 comes with the Red Hat Enterprise Linux 5.1 operating system and either the VQE-S or the VCPT and the VCDS software installed.

Figure 9:

Cisco Content Delivery Engine 110


Conclusion

Cisco VQE provides the following benefits to the service provider:

Supports Hybrid Error Repair, allowing the use of Unicast Retransmission, FEC or both.

Addresses noise issues associated with lossy DSL lines and home network wiring.

Reduces or eliminates the need for outside plant optimization, such as pair swapping, joint renewals and drop-cable reruns.

Increases the addressable market consumer base: Hybrid Error Repair technology enables video service over noisier transmission lines, thus extending the available footprint.

Reduces or eliminates the need to fragment video service into subscribers that can/cannot receive service based on line-quality attributes.

Supports RCC to reduce or eliminate the main sources of channel change delay.

Employs much of the same infrastructure and the same technology (RTCP) for Unicast Retransmission and RCC, thereby reducing service-provider training time.

Reduces or eliminates quality-related service-center calls.

Establishes a video quality baseline for all consumers with granularity per STB.

Provides an end-to-end view of network characteristics from an IPTV delivery perspective.

Uses open, standards-based protocols.

Cisco VQE also provides the subscriber with an enhanced video experience with better and more consistent visual and audio quality. Subscribers with noisier transmission lines or longer loop lengths can take advantage of the service provider's video offerings, bundles and unique content.

Right sidebar