A Guide to Testing IPTV: Technologies and Challenges Part 5

Author: Dennis Lennie

Published 1st December 2009



Throughout this article series we have seen that IPTV network operators face many challenges and explained that effective test and measurement is key to overcoming these challenges. The majority of IPTV networks are still in the early stages of development and operators are therefore primarily concerned with optimising QoS parameters in order to get their IPTV systems working.

In this final article, we will look at some of the tools and technologies used to test IPTV systems, focusing on QoS monitoring (such as jitter, packet loss and network congestion) and cross layer measurements.

Test Tools and Technologies

Layer-specific Probes
Operators need to use different probe types for quality control at different layers. At the Formatting layer, digital waveform monitors (such as the WFM8300 or WFM7120) help operators detect many quality problems essentially checking adherence to broadcast and colorimetry standards. At the Distribution layer, operators need probes to detect quality problems in a wide variety of distribution and transmission channels. In IPTV systems this group includes probes for monitoring information sent through either telecommunication Core or Access networks (such as the IPM400A).

Basic confidence monitoring probes track a small set of key quality parameters. They act as an “indicator light,” telling the operator when something has gone wrong. While these basic probes can enhance an operators’ ability to react to a quality problem, they do not offer the information needed to proactively address system degradation before it becomes a quality problem. Extended confidence monitoring probes use more sophisticated analysis to make additional measurements of quality parameters. They act as “indicator gauges” telling the operator when something is going wrong.

Monitoring Jitter and Packet Loss Using Cross Layer IP-MPEG Tests
Earlier in this series we explained how MPEG encoding can be used to alleviate bandwidth limitations and avoid “bursty” video delivery. While encoding offers many benefits, it can render video streams more susceptible to dropped packets.

MPEG tests can be used to detect timing impairments at the Transport Stream layer and to detect lost or out of order packets using Continuity Counter tests. However, for a more complete solution, it is better to perform these in conjunction with IP tests, throughout the network. Cross layer testing can be employed in both the IP and MPEG domains, to trace and track performance degradation, so that action may be taken before the problem gets too serious.

Graphical plots, such as those in Figure 8, correlate events over time as they happen on one layer, and can show whether this has an effect on the other layer. This can help to isolate the root cause to a specific layer, allowing a fault to be traced and then corrective action taken. During fault situations, alarms, tracer files and fault logs can be time stamped allowing intermittent faults to be tracked to see if an MPEG stream had a Transport Stream layer fault, or if it was related to an IP event.

Cross-layer IP-MPEG testing (using IPM400A and MTS430) can also be used to flag network jitter and identify the source. Most MPEG streams contain a built-in timing packet (Programmable Clock Reference or PCR). Graphing of these parameters gives a good indicator of a stream suffering timing distortions due to packet bunching or network jitter. These measurements are so useful that some operators are re-establishing PCR feeds in MPEG-4 transports (which don’t strictly need PCR) as they take up little bandwidth and give fast indication of timing health.

As there are no standards for IP interval or jitter, these parameters are user defined and test equipment should allow user limits to be set to aid fault diagnosis.

Cross-layer testing can extend to RF layers, where off-air content is acquired for delivery over IP networks. Test probes at the RF layer can not only give indications of RF signal quality, but can also demodulate the signal and perform MPEG tests to detect any issues already present on the down link.

Measuring Packet Jitter/Delay, Packet Loss and Network Congestion Using MDI

Media Delivery Index is used to quantify two IP transport impairments, namely Packet Jitter or Delay and Packet Loss. These two test parameters are defined as Media Delay Factor (MDI-DF) and Media Loss Rate (MDI-MLR). Instruments such as IPM400A and MTS430 are used to measure MDI. MDI is expressed as a ratio:

“Delay Factor : Media Loss Rate”, e.g. “MDI = 150:14”

The Media Loss Rate is the number of packets lost during a period of 1 second; the example above shows a Delay Factor of 150 ms and 14 packets lost per second

The Delay Factor indicates how long a data stream must be buffered (i.e. delayed) at its nominal bit rate to prevent packet loss. It captures impairments on the IP layer, and will give you a general idea of network jitter.

However, there are two important points to note; firstly, MDI is not payload aware. That is, it cannot separate video traffic from other data and VoIP packets. Secondly, as we discussed earlier in the series, the raw UDP protocol does not provide any means to detect packet loss, so for raw UDP, the packet loss portion of MDI is not measured directly, it must be extrapolated using the MPEG Continuity Count error counts.

The MDI-DF can also give a measure of congestion in a network, by showing utilisation level, and detect if queuing is happening in network components, however it does not indicate how much of this is due to video packet bunching.

A good MDI does not mean a faultless IP transmission, and a bad MDI can be the result of non-IP related issues. A more complete solution is to use MDI in conjunction with MPEG layer protocol test, i.e. cross-layer measurements.

Quality Control for Stored File Based Content
Earlier in the series we mentioned that corruption of stored video on servers prior to playout can lead to the propagation of poor video through the system. It is difficult to detect these errors during transmission, and it is therefore better to prevent coding errors from being transmitted or correct them at source. Modern broadcast networks make extensive use of server technology for archive and playout purposes. There is a new breed of test tools that provide automated quality control capabilities for file based video, on the video file server before it is broadcast.

Conclusion

The long-term vision of IPTV service providers is to offer a system which can offer converged video, voice and data services over a single IP network. Comprehensive, cross-layer test and measurement systems, will play a vital role in the successful design and rollout of these IPTV networks.
Most IPTV providers are currently focusing on getting their networks working, but as full IPTV system deployment occurs the focus will shift towards 24/7 real time monitoring capability and service assurance. These monitoring solutions will be required to provide operators with wide visibility and information about their systems. As IPTV networks mature, the focus is also likely to shift from measurement of QoS parameters to monitoring and optimisation of control plane (QoE) parameters (such as IGMP and RTSP).

IPTV represents the convergence of the broadcast and telecommunications worlds and successful deployment will require tools and expertise from both worlds. Effective test and measurement will remain key to success throughout the IPTV technology lifecycle; a service provider may or may not know there is problem, but the subscriber will, and reputation, quality and business will suffer with persistent problems.

Related Articles

Related News

Related Videos

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