Delivering Superior Quality of Service in IPTV Networks

Author: Dennis Lennie

Published 1st June 2009



To maintain differentiation in a competitive triple play market, the key operational challenge for telecommunications operators is how to efficiently deliver superior quality of service (QoS) levels. Intuitive use and simplified presentation of video quality and telecom transmission information are essential to win and keep customers. The video and IP crosslayer monitoring probe MTM400A provides Key Performance Indicator (KPI) tests to help operators maintain high network availability and superior video and audio performance.

Use of test equipment in this environment is essential, and correctly placed monitoring probes across the network can provide important data in the form of Key Performance Indicators (KPIs). This empowers operators and engineers to efficiently manage network systems in order to prevent degradation of signal quality which may result in errors which affect the end users’ experience. Using correctly configured test equipment to perform essential cross-layer monitoring, it is possible to predict system problems long before critical revenue earning services go off the air, rather than cure them after they have happened.
IPTV Headend Overview

The typical architecture for an IPTV based system includes broadcast video content and VoD services along with both voice and high speed data services. These linked technologies allow Telcos to balance the demise of their traditional fixed line business by reengineering their existing plant to carry IPTV, High Speed Data and Voice over IP (the so-called Triple Play Services). IPTV therefore represents the convergence of the broadcast and telecommunications worlds.

The focus of this article is the IP headend system. The primary functions of an IP headend are as follows:
  • Digital program acquisition: content from the satellite or terrestrial sources, and the preparation of that content for digital delivery (National or regional).

  • Digital program storage: storage and insertion of additional, non-live broadcast programming (e.g. local content, video-on-demand or advertising).

  • Digital program distribution and delivery: Encompasses program preparation and aggregation, rate-shaping, modulation, encapsulation (encoding), encryption and other technical processes for program delivery.


In these systems, ingest for the headend can be largely taken from various RF sources, whether they be cable, satellite or off-air terrestrial TV feeds and may also utilise SDI or IP feeds. Therefore, the secret to maintaining reliable and high quality IPTV services when using input formats such as IP, SDI and RF is to focus on critical factors that may compromise the integrity of the system. It is therefore essential to monitor QoS at the ingest, before signals are processed through the headend for output onto the Telco network.
What is QoS?

According to a Cisco Whitepaper from 2006, ‘Quality of Service’ (QoS) refers to the capability of a network to provide better service to selected network traffic over various technologies, including Frame Relay, Asynchronous Transfer Mode (ATM), Ethernet and 802.1 networks, SONET, and IP-routed networks that may use any or all of these underlying technologies.’

‘The primary goal of QoS is to provide priority including dedicated bandwidth, controlled jitter and latency…and improved loss characteristics.’

In network traffic engineering, QoS can be used to provide various priorities to differing data flows, or guarantee a certain level of performance to a data flow. In IPTV systems, this prioritisation is critical to achieve good quality video delivery.

Key Performance Indicators (KPIs)
Expanding on this definition, it becomes apparent that QoS therefore refers to the ability of a service provider to support users’ requirements with regard to at least 4 service categories;
  • Bandwidth: The capacity to support the users’ throughput requirements.
  • Latency or Delay: The time taken to send any packet from a given transmit node to a given receive node.
  • Jitter: The variation in the delay between the arrival of packets at the receive node.
  • Traffic or Packet Loss: How often are packets lost? How many packets are affected?



Key Monitoring Points


In order to monitor the KPIs outlined above, it is clear that we need to consider what is being output to the Core Network using suitably placed monitoring points.

In any environment, monitoring probe placement should be non-service impacting. This can be ensured on IP feeds by placing probes on router/switch mirror ports. A mirror port is a passive method which gives equivalent measurement to in-line measurement. Depending on the size of the network, it may be prudent to place probes at the IP output onto the core network, and then at any access network inputs. This gives comprehensive monitoring of the headend output and the output from the core network/input to the access network. Using this methodology, any degradation of the IP feed caused by the core network can be identified quickly.


Monitoring KPIs for IPTV

Assuming that the RF signal quality (incoming feed with Multi Program Transport Streams) into the plant is consistently of a good quality, the re-multiplexed Single Program Transport Streams must be measured to identify any issues arising from the IP network.

We have already categorized the 4 main KPIs which can be used to monitor QoS for the system. It could be argued that bandwidth is something that is managed during system design, as suitable provisioning and traffic management policies should be designed into the network at the outset. Any potential system overload could be predicted by monitoring other parameters which could be symptomatic of provisioning issues. These could include the 3 other KPIs mentioned earlier.

Latency/Delay and IP Jitter are inextricably linked and should be monitored across all sessions on the link. Any variation away from the ideal packet arrival time could cause buffer issues on any receiving device. A fixed variation can cause problems, but variable timing between IP packets (otherwise know as IP Jitter) can cause major issues if not diagnosed and rectified. A measurement probe should be capable of measuring and displaying Packet Inter-arrival Times (PIT) over extended periods to ensure that no underlying issue is degrading to a point where customers are affected.

The next KPI to consider is packet loss, which may not be an instantaneous event, but may be an effect of a gradual increase in traffic, maybe at a point in the early evening where prime-time TV comes online. If suitable traffic management and provisioning has not taken place or has been overwhelmed, packet losses could proliferate through the network and result in poor end user experience. It is therefore an essential feature of a network monitoring system to be able to detect both lost and out-of-order packets.

Media Delivery Index
Media Delivery Index (MDI) is defined as a single figure of merit used to quantify two IP transport impairments, namely Packet Jitter or Delay and Packet Loss. These two test parameters are:
  • Media Delay Factor (MDI-DF): indicates how long a data stream must be buffered (i.e. delayed) at its nominal bit rate to prevent packet loss.

  • Media Loss Rate (MDI-MLR): the number of packets lost during a period of 1 second


Whilst MDI has been broadly accepted by the industry as the ‘de-facto’ measurement for packet delay and loss, it is not without problems. One key issue is that MDI does not take into account the payload of the IP packet it measures. Therefore it treats audio, data and video in the same way. This comes to the fore when basic UDP (i.e. not RTP) traffic is being carried. Raw UDP protocol does not provide any means to detect packet loss. So for raw UDP, the packet loss portion of MDI has to be extrapolated from MPEG Continuity Count errors. Therefore any other error, such as Transport Stream syntax errors, cannot be detected by MDI.

The MDI Delay Factor (MDI-DF) is transport stream bit rate based, derived from the Transport Streams Program Clock References (PCRs) and is used to measure packet jitter on the network. However this relies on accurate PCR values, which may not be the case. Therefore, a bad PCR from a multiplexer could trigger an MDI error even though there is no network issue. It is therefore important to consider that, a good MDI does not mean a faultless IP transmission, and a bad MDI can be the result of non-IP related issues. MDI is not the answer – it simply complements other measurements.

Even maintaining correct PCR timing may not be enough to ensure good video quality. Whilst the system time clock can be synchronized from encoder to decoder by the PCRs, frame synchronization is typically accomplished through the Presentation Time Stamp (PTS) inserted in the Packet Elementary Stream (PES) header.

The PTS value (a 33-bit value in units of 90 kHz) indicates the time that the frame should be presented by the decoder. Since the PCR and PTS/DTS, keep the encoder and decoder in synchronization, any variation between these PCR and PTS values can cause buffer underflow or overflow issues, thereby causing decoding problems such as colour loss. Cross layer, time correlated timing measurements such as PIT, PCR and PTS timing can therefore prove valuable in tracing systematic timing problems.


Cross Layer Measurement

In terms of total QoS measurement, it is important to consider all aspects of the content being carried, whether it is Transport Stream over RF or IP carriers. The ability to monitor and measure across all these layers should be part of an overall monitoring strategy.

One example of how useful these cross layer measurements can be was shown when a Tektronix customer reported intermittent Set Top Box (STB) drop-outs on their IPTV system. Further analysis showed that only a certain model of STB was affected. Deeper investigation then proved that the cause was a combination of the 27MHz PCR clock drift (PCR_DR measurement) due to an overworked multiplexer. At the same time, the Packet Network entered a period of extreme delay (Packet Inter-arrival Time or PIT measurement) at the edge of the network - the STB would lose lock.

The STB was already being affected by a rapidly changing PCR_DR, and sudden network delay further deteriorated the signal causing the STB to lose lock. Independently these PCR_DR and PIT problems could be handled by the STB, but not simultaneously. In-depth PCR analysis with graphical results views using a Tektronix MTM400A transport stream monitor enable high accuracy timing and jitter measurements to be made to ensure correct operation of the network.

The ability to carry both IP and MPEG layer measurements on all sessions simultaneously from a single probe is a very powerful additional to the engineer’s toolkit whether they are maintaining system QoS or diagnosing system problems. Using multiple probes connected across the system can give operators and engineers the ability to access key information to enable signal quality to be maintained, along with the ability to respond quickly and diagnose a system failure.

Related Articles

Related News

Related Videos

© KitPlus (tv-bay limited). All trademarks recognised. Reproduction of this content is strictly prohibited without written consent.