|
Data networks weren't originally designed to carry real-time applications like voice and video. Consequently, for service providers contemplating a triple-play launch (voice, video, and data services), it's critical to understand what could happen when converged IP-based services go live without proper network testing and service management.
When examining quality issues, it's important to keep in mind that quality of service (QoS) measurements are only indicators of the subscriber’s experience. Subscribers expectations have been conditioned over decades by the public switched telephone network (PSTN) delivering toll-quality voice, of cable, broadcast. More recently, satellite networks have reinforced user expectations by delivering high quality video, and by private networks delivering videoconferencing services.
Paying subscribers have proved willing to accept some quality tradeoffs in exchange for mobility and other benefits. However, for lifeline voice and premium television services, providers should expect little tolerance for quality that fails to meet or exceed end-user expectations.
Data packet loss
Until now, Internet Protocol (IP) networks have delivered useful, popular, but non-real-time applications, including email, Web surfing, and file transfers. For email and Web traffic, a few lost packets present minimal user hiccups. As long as packet header information is in order, the packets will re-assemble themselves at the destination without any apparent change or perceptible loss to the user.
This scenario changes radically with the introduction of IP-based triple play services. Even a low level of packet loss can create unacceptable degradation of voice and video quality.
Packet loss can result in everything from garbled voices on a phone call to graininess and dropouts in a video signal, where a videoconference or TV show loses clarity or momentarily goes blank. If enough packets are lost, entire spoken words or phrases or video frames won't reach their destination.
In the worst case, severe packet loss can cause an entire communications session to be dropped by the network, meaning that a phone call gets disconnected or video session abruptly ends. Indeed, testing of packet loss must consider both packets carrying voice and video information and packets carrying the signaling information (such as Session Initiation Protocol or H.323 traffic) required to set up and tear down connections.
Voice and video jitter
The time it takes for packets to travel from point to point within a converged network is measured in delay or latency levels. Jitter is a variation of delay/latency levels over time, caused by actions like queuing and routing that affect a packet's path as it travels through the network. A congested network will generally have higher jitter levels, but proper QoS controls over queuing as well as jitter buffers, and bandwidth allocation can control the problem.
Voice tolerance for delay is notoriously low, requiring end-to-end delivery in fewer than 150 ms, whether over PSTN or IP infrastructure. At that point, the human ear begins to detect degradation in voice quality. The human ear also can detect too much variation in delay (jitter) as inconsistency in quality or simply something unnatural about the voice.
Video tolerances for jitter are even lower, given the demand for smooth motion in film, sports, or other TV applications. While great advances in video compression continue to squeeze more and more video information into less bandwidth, compression doesn't address issues that generate delay or jitter, such as congested router ports or malfunctioning buffers at any given point in the end-to-end path.
Transmission Control Protocol/Internet Protocol (TCP/IP) routing technologies such as Differentiated Services (DiffServ) and IP Precedence packet markings now instruct routers and gateways to give real-time applications priority treatment in a congested network. Most QoS solutions also include a jitter buffer, which adds small delays to received packets so they all appear to have equal and acceptable latencies. This buffer also ensures that packets are transmitted in the correct order.
Testing the performance of these QoS mechanisms, as well as testing application quality from the end-user’s perspective (i.e., from the origin and destination end-points), is essential to determine how much jitter a network will experience and how it should be handled.
Figure 1 shows the sources of triple-play data on the left and, most important, the the ideal test points in both the access and global networks used to transmit data to the end points on the right.
Click here for Figure 1
1. Pain points in the delivery of voice, data and video over IP.
Delay/latency
Exceeding the acceptable delay/latency levels for a voice application can force parties to pause each time they speak, waiting for the other party to hear what has been said. For video and IPTV applications, likely impairments can include "frozen" frames or "tilted" images. Likewise, videoconferencing veterans are by now familiar with words being out of sync with the speaker.
These problems can be solved by employing QoS measures that monitor and buffer packets as they travel across the network, ensuring that they're transmitted with acceptable delays and in the proper order. As an added dimension of complexity, thresholds for delay, jitter and dropped packets are at the mercy of ever changing traffic conditions. The number of concurrent users continually changes, as do the combinations of voice, video, and data applications and the network links in use.
The network must therefore be thoroughly tested under varying traffic scenarios and conditions to accurately determine the maximum latency level that can occur, and to properly configure capacity and QoS solutions to accommodate that level.
Voice echo
In a hybrid network, analog phones can be the source of echo, but an IP telephony configuration is also susceptible, as some calls will inevitably interface with Time Division Multiplexing (TDM) network elements at some point when they go "off net." Voice echo occurs when participants can hear their own voices coming from a phone's earpiece, and if extreme, can make a voice call completely intolerable. Factors such as the volume and length of the echo and the impact of hardware, such as handsets and routers, can contribute to the echo level.
There are generally acceptable levels of echo for IP telephony calls, and echo cancellation and suppression are the most common ways to keep echo at an appropriate level within a network. DSP-based echo cancellers are commonly used in media gateways, audio coder/decoders and other equipment to control echo levels. This means that providers must test both the echo itself and the performance of mechanisms like cancellers.
Clipping
Clipping within VoIP calls occurs when either the beginning or end of words, or whole words, seem to be cut off during a conversation. This can occur when voice activity detectors and other solutions that work in tandem with echo cancellers are thrown out of sync.
Echo cancellers deal with background noise and "double talk" in addition to echo. For instance, an absence of background noise during a call can confuse users into thinking a call has been dropped. Yet improper background noise levels can result in annoying voice clipping. A careful balance must be struck, ensuring that proper levels of latency, jitter, packet loss, and echo are maintained throughout the network at all times.
Triple-play network testing
In addition to negatively impacting a service provider’s overall network performance, each potential QoS issue can lead to significant subscriber churn. Several decades ago, before the advent of non-blocking PSTN switches, service providers engineered switch capacity for Mother’s Day, the peak-calling day each year.
With real-time IP applications, the traffic-engineering imperative has returned. The fundamental issue at hand is whether and how providers can properly engineer their infrastructure ahead of VoIP and IP video service launches and then proactively anticipate evolving demands to continually re-engineer in a way that assures on-going quality.
This triple play challenge effectively triples the old voice engineering challenge. Traffic scenarios—such as three simultaneous HDTV signals plus two IP telephony calls delivered to one home, or 100,000 simultaneous viewings of one TV show in a single market—will become far more complex and less easily predicted than Mother’s Day. Carriers therefore must anticipate multiple permutations of traffic loads and types and the associated network requirements, and then engineer capacity and device configurations accordingly.
If real-time IP QoS issues aren't uncovered during comprehensive lab testing or in pre-deployment network testing, network operators will undoubtedly be in for a shock when services go live. At the very least, dropped calls, unacceptable voice and video quality, bandwidth bottlenecks, and general chaos will ensue.
About the author
Bahaa Moukadam, vice-president of Spirent Communications' IP Telephony division, has more than 18 years of experience in the communications test and measurement industry. He holds an MSEE degree from the University of Kansas and BSEE degree from the University of Missouri. Moukadam can be reached at Bahaa.Moukadam@spirentcom.com.
|
