IPTV represents the convergence of the broadcast and telecommunications worlds. Successful deployment requires tools and expertise from both worlds.

IP networks offer two-way, interactive capabilities which traditional TV technologies lack. This type of interactivity will enable one-to-one distribution, allowing individual viewers control of their chosen content along with so called “trick mode” facilities like live pause, fast forward, and rewind. This interactivity can also be used to provide targeted advertising, one-to-one marketing that could include instantaneous end-user feedback and other services coupled to programming such as online shopping (for articles actually shown in the program), gaming, etc.

The two-way nature of these networks enable Video on Demand (VoD) and network digital video recording (NDRV), which are two of the most popular differentiators provided by IPTV systems over the traditional unidirectional broadcast system where programming is pushed to the consumer rather than pulled when required.

Challenges in Delivering IPTV Services
Video, voice, and data are all IP data services, but each has its own Quality of Service (QoS) requirements when being transported across IP networks.

In order to be successfully decoded at the STB, the Transport Stream carrying the video needs to arrive at a known and constant bit rate, in sequence with minimal jitter or delay. The requirements for the successful delivery of voice or data are just as important but less stringent than those needed by video. The differing characteristics of these services all contribute to the complexity of designing, deploying and maintaining networks required to deliver high quality services to the consumer.

By their very nature, IP networks are “Best Effort” networks initially developed for the transport of data. As a consequence, these networks are susceptible to lost or dropped packets as bandwidth becomes scarce and jitter increases. In the vast majority of cases this problem has no significant impact on data services which can cope with packet resends and packets arriving out of order as they get routed along different paths through networks. Video is completely intolerant to the vagaries of a best effort network.

QoS for video services requires:

• High availability and sufficient guaranteed bandwidth to allow the successful delivery of the service. Without this, video delivery will be bursty which will cause issues at the Set-Top Box (STB) which expects its data at a constant bit rate and in the correct sequence.
• Low transmission delay through the network. This impacts quality of experience as it will impact the response time to requests from the user’s remote control.
• Low network jitter. Jitter affects the variability of packet arrival through the network. This variability can lead to buffer under and overflows at the receiving equipment (STB). Jitter canimpact the way packets are handled at various network elements. If the jitter is too high, packet loss will increase as queuing software tries to load balance traffic at network elements.
• Low Packet Loss. Lost packets have the greatest impact on the quality of received video and will generally lead to highly visible blocking errors. If lost packets contain I-frame Video the impact will be more pronounced as the STB has to wait for the next I-frame to arrive to allow it to reset itself. This problem is aggravated by the use of H.264 which uses a longer GOP (Group of Pictures) structure (increasing the chances of lost frames), and because of the increased compression ratio each frame contains more information. Consequently, the loss of a single H.264 frame is likely to have a greater impact on the picture quality.

From a pure bandwidth perspective, video requires more bandwidth than voice or data. In order to ensure quality of service, effective network management policies in tandem with a well designed, robust network are essential. A standard video signal using MPEG-2 encoding uses approximately 3.75 Mbps of bandwidth over an IP network. A high-definition MPEG-2 signal may require 12-15 Mbps. By adding a mix of services together such as Video on Demand (VoD), standard- and high-definition channels (along with voice and data services), it is easy to see that the bandwidth budget of most access technologies can quickly become restrictive.

Today’s broadcast systems have set current user expectations about a television experience. To be successful, any IPTV service will have to be at least as good as the next best alternative, be that traditional broadcast, cable, or satellite services, and probably better. Quality of Experience (QoE) (i.e., is the subscriber receiving content adequately?) has become a critical element to IPTV services. QoE needs to consider items such as:

• Is the subscriber consuming more bandwidth than is provisioned?
• Are all promised capabilities being delivered (e.g., the Electronic Program Guide (EPG), the right program, etc.)?
• What is the subscriber experiencing at this moment (e.g., picture quality, channel change times, etc.)?
• QoS (i.e., is the network delivering content adequately?) at the packet level is as important as QoE. Good QoS provides the foundation from which high QoE expectations are more likely to be met. QoS focuses on the performance of the network and its ability to deliver content to the required standard. Examples of quantifiable QoS measures could be:
• Where in the network is congestion occurring?
• Are there adequate VoD content servers in appropriate markets?
• Are interactions between voice, data, and video causing problems within the network?
• How many IP packets are being lost, and is there excessive jitter on the physical layer?

A Test That’s More Than a TEST
Given that QoS and QoE are vital pointers to whether subscribers will receive a quality end product, the ability to test monitor and measure the parameters that impact these is essential.

IPTV systems consist of a number of key components (often referred to as the Ecosystem) all of which can have an impact on the QoE and QoS. Some of the most important components are:

• Middleware: The software and hardware infrastructure that connects the IPTV components together. It normally includes subscriber-facing EPG, application control, back office/billing, etc.
• STB (Set-Top Box): The Consumer Premise Equipment (CPE) used to interface with the user and the IPTV services provided by the network.
• Video Encoder/Transcoder/Stream Processor: Responsible for the transformation of an input stream that can be of various formats into a digital compressed stream targeting the CPE.
• Core Network Elements: The key elements used to make up the Next Generation core network capable of prioritizing Video, Voice, and Data through the network.
• Access Network Technologies: Access technologies capable of providing the bandwidth required to deliver TV services to the home or receiving equipment (e.g., ADSL2, FTTx, WiMAX, DVB-H).
• Video Servers: Computer based multi-stream playout devices connected to large storage systems.
• CAS/DRM: A Conditional Access System (CAS) allows for the secure delivery of content. Digital Rights Management (DRM) controls subscriber usage of the delivered content (for example: view once, unlimited view during calendar window, etc.).

IPTV Test Methodology
Figure 1 shows an IPTV network reduced to its simplest form. In effect these systems consist of 2 key subsystems:

Figure 1. This illustration shows an IPTV network reduced to its simplest form.

1. The video headend, where video is ingested and made ready for transmission to…
2. The IP network, the transmission system used to distribute the video along with voice and data services.

There is a continuum along which the deployment of IPTV is moving. This goes from design and manufacturing to full deployment. At each stage the test objectives and needs are different, and in order to move efficiently and cost-effectively through each stage the need for testing and the selection of the right test equipment is essential.

Design requires in-depth tests for standards compliance and interoperability of video and network infrastructure equipment. Manufacturing requires consistent, rapid and repeatable functional test and results logging. Early deployment and trials requires tools that provide rapid fault identification and diagnosis of IP, video and voice faults. This requires best-in-class point-monitoring and analysis solutions that can look at the content (User Plane), control and setup (Control Plane), and physical layer.

For full deployment and ongoing system management the emphasis will shift from monitoring and testing parts of the network to 24/7 real-time monitoring of the whole network (which could be global).

3 Steps to the Test
There are 3 key steps that need to occur during varied stages of deployment.

Step 1. Can the "IP Pathway" be reliably set up and torn down? A Triple Play network needs to assure availability of network resources and bandwidth to deliver video services. However, video is bandwidth intensive, so it is equally important to ensure that pathways that are no longer needed can be torn down successfully. This requires test equipment capable of establishing and testing the IP pathway and providing statistics on network jitter and packet loss. These needs also apply to the provision of Voice over IP (VoIP) services.

Step 2. Is the video right at the source and destination? Once the
IP pathway is established it is then essential that the video data pushed into and received from the pathway is correct. This requires the monitoring and analysis of the Transport Streams at the output of encoders, multiplexers at the headend. At the receiver end, similar monitoring and analysis is required to ensure there has been no degradation of the video as it passes through the system.

Two areas often overlooked when discussing IPTV are the ingest and storage facilities within the Headend. Significant amounts of content to be distributed through the system are ingested over RF downlinks (e.g., QPSK for Satellite, and COFDM or 8VSB for terrestrial broadcasts). The integrity of these links is as important as any other in the chain. Being at the front end of the transmission chain, any errors introduced at this stage will be propagated throughout the system.

Much of the video content is stored on servers prior to playout into the system (be it Broadcast TV or VoD). Corruption of the stored video can similarly lead to the propagation of poor video through the system.

Step 3. Is it a great subscriber experience? The final stage of the early deployment phase is to configure the system to deliver a high QoE. This requires the optimization of Control Plane (IGMP and RTSP) parameters. Engineers are required to ensure that the requested channels are actually delivered and there is access to the EPG, etc.

This can be an iterative process and will have to be repeated as new services are added, and the system scales up to cater for larger numbers of subscribers. Throughout these stages engineers require test equipment that brings the broadcast and telecom's worlds together. The equipment is required to perform comprehensive Quality of Service (QoS) (e.g., network jitter, lost packet), and QoE Control Plane and User Plane (e.g., IGMP response, PCR jitter) measurements.

To aid rapid fault isolation and diagnosis the ability to see and correlate errors across the different layers of the network is essential. Not all the errors that occur on the IP layer cause video errors. It's important to understand which do and which don't.

Distributed Multi-layer Monitoring Tools
As IPTV deployments mature and move into the Operate and Manage phase of the deployment lifecycle the test emphasis will shift from deep analysis and diagnostics to one of 24/7 monitoring.

These monitoring solutions are required to provide operators with wide visibility and information about their systems. These monitoring systems should have a combination of the following characteristics:

• Layer-specific probes that detect the different types of errors seen in digital television systems.
• Extended monitoring capability to give operators advanced notification of system degradations before they become quality problems.
• Multi-layer monitoring that lets operators quickly isolate the root cause of a quality problem.

To have confidence their facilities are performing correctly and efficiently, operators will generally need to probe at multiple layers in their systems. Probing at only one layer can give a misleading picture of system health.

Watching a broadcast on a picture monitor is a simple example of this methodology. In this case, operators are probing quality at the Formatting layer. While this offers significant information on system health in an analog system, it offers little information in digital systems. Similarly, monitoring just the MPEG protocol or the RF transmission will only yield partial information. To gain a complete picture of system quality, and to quickly detect and isolate quality problems, operators will need multi-layer monitoring solutions.

A small sample of test/monitoring opportunities is shown in Figure 2.

Figure 2. Examples of Multi-Layer Test Points.

Picture Quality and Quality
When it comes down to it, picture quality may be the clearest metric to determine that the provider is delivering the promised service to the end user.

There are three types of tests providers can use to determine that they are meeting their goal with regard to picture quality.

Test Type A: Subjective and PQ Tests
Mean Opinion scores (MOS) for VoIP are in common use in telecommunications systems and therefore there is a natural expectation that the video MOS should be made available.

However, audio is Pulse-Code Modulated (PCM), and degradation parameters for video are quite different. Objective measurements must be designed to correlate directly with a real subjective test database to be of any value. In audio this was done with deployment scenarios such as multiple languages, cultural groups, and Codecs. There is no video equivalent for these scenarios.

True Picture Quality Analysis (PQA) can be expensive to implement and the more meaningful double-ended test (the received picture is compared to an unimpaired reference) has the problem of how the reference stream is routed to the point of test, often requiring a dedicated test feed.

Single-ended MOS tests may be more attractive, but there is no ideal algorithm available for this. To be successful, these systems need to apply combinations of algorithms since they are very dependent on external factors such as the STB decoders, the number of dropped packets, encoder type, and bit rate.

However PQ tests require the picture to be "in the clear". If the operator is using encryption technologies such Conditional Access (CA) or Digital Rights Management (DRM), MOS will not work. It should also be noted that these PQ metrics tell you when something has already gone wrong and, although they can give some indication of the cause (some TR 101 290 tests), they do not provide a complete test methodology.

Test Type B: Quality Control for Stored File Based Content
MPEG or IP transport monitoring is unlikely to pick up lower layer elementary stream coding artifacts. Picture Quality tests may detect the issues but cannot fix them. It is 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 QC (quality control) capabilities for file based video, on the video file server before it is broadcast. Here, checks can be carried out on encoding profiles and baseline payload quality all in a wide variety of formats (SD-SDI, H.264 etc).

Test Type C: QoS Measurement Using MDI
Media Delivery Index (MDI) is defined by IETF RFC 4445. It 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 defined as Media Delay Factor (MDI-DF) and Media Loss Rate (MDI-MLR).

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 does capture impairments on the IP layer, and will give you a general idea of network jitter from the DF measurement.

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, 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 by using the MPEG Continuity Count error counts. For RTP flows, DF is measured using the timestamps from the received packets. The presence of RTP sequence numbers also allows RTP packet loss to be measured and displayed as part of the MDI.

The MDI-DF can give a measure of congestion in a network, by showing utilization level, and detect if queuing is happening in network components, but does not indicate how much of this is due to video packet bunching. The MPEG buffer model is not as simple as MDI assumes.

The Media Loss Rate is the number of packets lost during a period of 1 second. MDI is expressed as a ratio: "Delay Factor : Media Loss Rate", e.g., "MDI = 150:14" (This example shows a Delay Factor of 150 ms and 14 packets lost per second.) 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).

Testing carried out at ingest can ensure good content is entering the network before being handed off onto the IP network. These video streams are then encapsulated and passed into the Core network along with the VoIP and high-speed data traffic. Owning the entire network provides major advantages at this point, since QoS tools and network management protocols (e.g., PIM) can be used to prioritize the video traffic to prevent delay or fragmentation.

Conclusion
As full IPTV system deployment occurs, the focus of operators will shift from diagnostic tools toward 24/7 real time monitoring capability and service assurance.

Consistency of measurement across many layers and phases of IPTV deployment is important as it allows engineers more time to diagnose the real fault rather than trying to explain differences in measurement results between diagnostic and monitoring equipment.

About the Author
Steve Foy is Senior Applications Engineer, Tektronix, and has worked in the video industry for 13 years. He began work in video for the Cambridge start-up Symbionics Instruments in 1996. Symbionics Instruments was rebranded as Adherent Systems in 1997 and was acquired by Tektronix in 2001. Since then, Steve has worked with Tektronix customers around the world in various roles including MPEG Customer Support, Systems Integration, Project Management and Technical Training for both Tektronix employees and customers.  For more information visit www.tecktronix.com.

About the Company
Tektronix has broad application experience and deep domain knowledge in both video and telecommunications network management and diagnostics. Their expertise is focused on helping communications providers today bring the right test methodologies and solutions to help bring Triple Play, including IPTV, to the masses. For more information visit www.tecktronix.com.

What is your experience with this? Tell your fellow readers now!