Deploying video services over Gigabit Ethernet presents service providers with a new set of testing challenges. In particular, the proper provision of IP television (IPTV) and video-on-demand (VoD) requires simultaneous testing of both the transport system and the multicast video signals, such as MPEG-2.
In this context, MPEG analyzers or Ethernet test sets alone can no longer provide adequate testing and troubleshooting. Many problems within the MPEG layer are the result of lower-level factors, such as latency, jitter, throughput, or utilization. As with any troubleshooting technique, it is critical to find the root cause of the problem.
This article will review the advantages of Gigabit Ethernet as a transport protocol, new testing challenges posed by the MPEG-2 transport stream, and how the challenges are met by new Gigabit Ethernet test sets.
The use of Ethernet as a transport protocol for video provides several advantages. Probably the greatest advantage lies in its ability to transport the entire triple-play package-voice, video, and data-over the same infrastructure, which lowers the cost and complexity of the transport network. This, in turn, requires the use of the same test equipment for Layer 2 testing, with some advanced features for upper layer testing-including MPEG testing in Layer 3.
Ethernet is relatively easy to install and maintain, and offers one of the most efficient transport methods available today. Enormous amounts of capacity are available for transporting today’s bandwidth-hungry services, particularly MPEG video. Ethernet and IP are “best effort” services, also known as “asynchronous” services, and there is no guarantee that packets will be delivered without jitter, if delivered at all. This level of service, however, is accepted because of its lower operating costs.
Digital video/audio signals are compressed into elementary streams and then packetized. The packetized elementary streams (PES) contain both the payload and header (see figure). Each payload contains a single frame of audio or video and becomes part of an MPEG-2 Transport Stream further packetized in 188-byte packets. A packet identifier (PID) in the header of each transport packet associates the packet to the program to which the packet belongs using information signaled in MPEG-2 PSI (PAT and PMT).Also placed within the packets periodically are program clock reference (PCR) values to closely synchronize the encoder and the decoder clocks. Both the PID and PCR are important measurement parameters within the transport stream. The PID in the header of each transport packet not only identifies the program to which the packet belongs, but also enables determination of bandwidth allocation between programs.
“PCR jitter” refers to the difference between the actual and expected value of a PCR. One cause of PCR jitter is network jitter or variation in the interarrival time of packets. The allowable limits for PCR jitter reflect the capabilities of the clock recovery circuits-exceeding the limit causes the receiver clock to drift. The accuracy of the PCRs is very important to the overall quality of the video, and any timing errors are magnified and can result in a complete loss of the video signal. The PCR jitter measurement includes any transmission arrival-time errors that are often related to the network latency.
In multicasting, high-bandwidth applications such as video MPEG-2 are simultaneously delivered to multiple users over the same bandwidth. This eases the bandwidth burden for the service provider by delivering the same packetized signals to a select multicast group. Internet Group Multicast Protocol (IGMP) enables a user to join a particular multicast group and allows the “host” to receive the multicast packets. IGMP hosts send out periodic requests to join a particular multicast group, enabling them to receive the video traffic of interest.
When testing a video service such as VoD using IGMP, it obviously is necessary for the test equipment to receive the video signals. If the technician cannot join the multicast group via IGMP, the test equipment cannot receive any video to test. Although a multicast “join” can also be achieved by mirroring or spanning a port, this method requires a technician to log into a switch and change the switch’s configuration. This procedure requires additional equipment and, more important, is time-consuming.
Current test methods ensure that IP packets get to their destination at the proper time, but once video is added to the mix, the testing complexity increases. With video, technicians must also be concerned with the exact contents of each packet. This requires testing at the MPEG level.
As video traverses the network, it is manipulated by many layers and paths before reaching its destination. Only proper testing at all levels can ensure the video service will perform properly for each user.
For example, a typical network designed to deliver high-end video services usually consists of a multilayer architecture. At the lowest level, the fiber layer divides the network into individual wavelengths using DWDM technology. Each wavelength, or channel, uses Gigabit Ethernet as a transport protocol.
The Ethernet layer is further broken down into IP streams and divided into user datagram protocol (UDP) ports. Finally, each UDP port contains an MPEG-2 transport stream, typically with up to 16 MPEG programs.
If a problem occurs with video and MPEG, any lower layer could be suspect. Therefore, service providers have the complex task of managing a very complex multilayer network against any number of potential problems in any number of network layers.
For example, in some of the lower layers of the network, service providers can face challenges such as audio or video buffer underflow or overflow. The receiver must have the capability to buffer audio and video frame data until the presentation time. If the data appears too late in the transport stream, then buffer underflow will result. Conversely, if the data appears too early, a buffer overflow occurs. In either case, the result is performance degradation, such as garbled play or incorrect synchronization.
Incorrect audio and video synchronization is another challenge to performance. Since audio and video signals are encoded independently, they must be synchronized for proper play. PCR values appear at specific intervals in adaptation fields of video transport stream packets to allow replicating the original time base. Synchronization is achieved by providing presentation time stamp (PTS) values in the PES packet headers for each video and audio frame relative to the PCR timeline. Excessive jitter in PCR values or bad PTS values will lead to issues such as lip-sync problems or blocking due to buffer issues.
Today’s video test equipment must offer the means for technicians to not only capture and decode Ethernet frames from a network, but also filter out an MPEG-2 transport stream. The MPEG-2 stream can then be fully analyzed, either in the field or played back to the Gigabit Ethernet test module by using an MPEG-2 player.
By incorporating this MPEG-2 option into the Gigabit Ethernet field-test module, field engineers and technicians can not only test the Ethernet network, but also the video services being delivered. Issues such as loss of synchronization between video and audio or an overly pixelated video stream can be viewed and analyzed (see photo).
The ability to easily and cost-effectively test the quality of the video stream is essential to the successful rollout of an Ethernet-based video transport system. Whether providing VoD or IPTV services, using Gigabit Ethernet as the transport protocol requires the addition of MPEG-2 analysis capability to any Ethernet test set.
In addition to testing the throughput, frame loss, and latency of the Ethernet transport protocol, such enhanced test sets provide the additional benefit of MPEG-2 video analysis. With this additional capability, field personnel can install, troubleshoot, and verify the quality of MPEG-2 video transport streams.
An additional feature incorporated into the MPEG-2 testing capability is the support of IGMP to enable a “join” onto multicast IP addresses. This feature enables technicians to analyze the video streams directly from a switch or router without the need to mirror or span a port.
Since VoD systems use IGMP as an essential method of maximizing bandwidth through multicasting, the ability of the Gigabit Ethernet test module to act as a host on an IGMP multicast system is necessary for easy, efficient MPEG-2 analysis. A router or switch in a VoD or IPTV network sends out periodic messages to connected hosts to determine if they are a member of a multicast group. If not, the host will not receive the multicast stream. If the host is a member, it receives, or continues to receive, the video stream.
Through the use of IGMP, the test set can participate as a member host of a multicast group to receive and analyze the video stream without the need to mirror or span a switch port in the field-which greatly simplifies video testing efforts.
In today’s triple-play architectures, delivering high-end video services is a critical differentiator among service providers. Maintaining the performance of these services will require providers to have every tool available to them. With that in mind, they must meet the unique testing challenges of transporting video over Ethernet-based systems.
The ability to add features to test sets that enable the analysis of MPEG-2 video streams will help providers to maintain the quality of service their customers demand. In turn, these testing capabilities will ensure that potential problems are identified quickly at every layer of the transport network.Jason Thomas is a product specialist at Anritsu (Utica, NY; www.anritsu.com), formerly NetTest.
Rich Chernock is the director of technology at Triveni Digital (Princeton Junction, NJ; www.trivenidigital.com).