高速以太网

IPTV - What to Test

作者:

IPTV is on the rise, more quickly in some places than in others.

IPTV is on the rise, more quickly in some places than in others. While some areas have already hit double-digit market penetration, others, like the US, are still in single digits. Growth rates vary by region from 20% to over 100%. More than half of the video rights holders and distributors surveyed said they are distributing video online today, and only 10 percent said they had no plans to do so1.

As the new kid on the pedestal, IPTV must deal with viewer expectations set by decades of broadcast and cable television. It has to prove itself, offering similar or better quality of experience (QoE) while enhancing the value proposition with more features. That’s why testing has been such an important part of the development and rollout of IPTV offerings, like the test EANTC did of Cisco IP Video Infrastructure solutions.

The true litmus test of an IPTV service is QoE, but there are a lot of components that contribute to this metric, and there can be no weak links in this chain.

When it comes to testing IPTV, throughput performance is the most obvious place to start. If the system can’t support the throughput required without issues such as congestion and link or node failure, there’s no point in testing further.

Cable and broadcast TV have the luxury of dedicated wavelengths to guarantee throughput. IPTV, on the other hand, must deal with packet forwarding and contention, making it more difficult to achieve the level of throughput required to deliver standard definition TV, much less high definition. Packet latency, packet loss and packet delay variation all conspire to sabotage service quality. For video, packet loss must typically be zero for an acceptable service. RFC-based throughput testing is the key to verifying that a system or service can deliver the throughput required for high QoE.

IPTV is typically deployed in a multiplay environment. Television video traffic will coexist with VoIP and internet traffic. Some of the traffic may come from high bandwidth applications such as online gaming, file transfers, and P2P sharing. To assure that the solution delivers high video QoE even in the presence of congestion, packet classification and prioritization mechanisms are tested, independently and together. The metrics of interest here are packet latency and packet loss.

Resiliency indicates the ability to maintain service even in the face of a link (the connection between two points of presence) failure or node (entire device) failure. For such failures, it’s not a question of if, but rather a question of when. Redundancy is a method of enforcing resiliency. Regardless of the method of redundancy implemented, for example, redundant headends or redundant video streams, testing is required to verify the response time of the method and its effect on QoE.

The metric of interest for testing a resiliency mechanism is the out-of-service time (OoST). One method of calculating OoST is to count the number of lost frames during a failure event. A more accurate method is to continuously sample the received frame rate for very short intervals and report the duration between falling below an acceptable frame rate and returning to that rate.

That’s an overview of what to test and why when it comes to IPTV. To do the testing you will need a test system that can:

  • Generate and track stateless and stateful traffic at line rate

  • Integrate unicast and multicast traffic streams within a single test

  • Perform video analysis on live traffic is imperative

  • Collect key metrics such as packet delay, packet delay variations and packet loss in a single test run

  • Create realistic multi-protocol stacking scenarios, such as HTTP over PPPoE over MPLS

1Source: Lightreading.com

喜欢我们的内容吗?

在这里订阅我们的博客

博客订阅

标签Ethernet+IP
Brett Wolmarans

Brett Wolmarans is a product manager with Spirent Communications. He has worked in various roles in South Africa, Canada, Japan and the United States as a developer, IT technician, network engineer, entrepreneur and systems engineer over the last 20 years. Brett participates in IETF meetings in between helping testers everywhere find better solutions.