End users don’t care if their voice call is carried over a circuit switched connection, like the Public Switched Telephone Network (PSTN), a packet switched connection, like a VoIP network, a cable television-based network, or two tins cans and some string—as long as the quality of that connection meets their expectations. And as we discussed in a previous tutorial, the Quality of Service (QoS) of the existing PSTN has set a very high standard, and few end users would be willing to make a change from their existing PSTN-based environment if they knew that the quality of their connection would degrade significantly.
Unfortunately, packet switched networks were originally designed to support data—which is non-real time information—and we are now asking that same network to support voice and video—which is real-time information. In other words, the delay or loss of some of the packets in a large file transfer can be recovered by retransmissions within the underlying protocols, without the end user even being aware that a problem existed. But real time traffic presents a bigger challenge—the communication occurs in real time, so if you miss part of the transmission, you just miss it. And unless you ask your buddy at the other end of the connection to repeat part of the conversation, or rewinding the video tape, the communication goes on, and you have to figure out some way to catch up.
So in order to keep all the troops happy (not to mention the bean counters that are writing the checks for the VoIP upgrade), we previously considered three impairments that affect the quality of a VoIP connection: packet delay or latency, packet jitter, and packet loss. To quickly review, the delay is the difference in time between when the signal is transmitted, and when it is received; the packet jitter measures the variation in arrival rates between individual packets, and the packet loss measures the number of packets from the original data stream that do not find their way to the destination. In general terms, the first two, delay and jitter, are impairments that we can design around. The third, packet loss, is keenly dependent upon the quality of the networking devices, such as routers and switches, plus the various transmission facilities, such as leased lines. These items need our attention when we purchase the equipment or sign the contract with the carrier, rather than after the network has been installed.
That being the case, we will turn our attention to delay and jitter, seeing how these two impairments can be optimized. But first, let’s recall how delay affects our conversation:
Suppose that you are conversing with a friend in a far away country, and that an underwater cables, satellites, and other connections are part of the transmission system. Furthermore, suppose that the transmission system is not electrically perfect, and that impedance mismatches occur along the way, causing some of the transmitted electrical energy to be reflected back to the source. If that electrical energy is in the voice spectrum it will be audible, and will manifest itself as an echo in the telephone earpiece of what you just spoke into the telephone mouthpiece. If the time delay between your spoken word and the echoed word is very short, your auditory system will likely filter it out, and it will not become an annoyance. As the delay increases, however, the annoyance increases, and before long, you get so confused by hearing yourself both coming and going that you stop talking—which benefits no one.
As a result of many years of telephony research, a benchmark for voice circuit delay was determined, and published by the International Telecommunications Union—Telecommunications Standardization Sector (ITU-T) in their recommendation G.114, titled One-way Transmission Time, and available at www.itu.int. The delay objective that has been accepted for many years has been 150 milliseconds per one-way transmission path, although longer times, in the mid-250 millisecond range, may provide end-user-acceptable results.
This delay budget can be divided across several components: the coder/decoder (codec), which is dependent on the codec selected; the framing and/or packetization delays, which are dependent upon the LAN congestion and the number of voice samples that are included in each frame; the delay in the wirebound and/or wireless environments, which are dependent upon the transmission system, number of router hops and and distance; plus delay in the jitter buffer which is correcting for the differences in inter-packet arrival times, and is typically adds half of its buffer time to the end-to-end network delay.
As you can see, there are many design variables here. Fortunately there are numerous charts and tables in the G.114 standard to assist the VoIP network engineer sort through all the options. In addition, many vendors have design tools to assist with the delay budget calculations, since after all, they have a vested interest in keeping the end users satisfied as well! A solid VoIP design begins with a good understanding of the delay budget, and some time spent studying the G.114 standard will move you toward the QoS objective that everyone is looking to achieve.
In our next tutorial, we will continue the discussion of QoS issues, and look at standards that have been developed for objective QoS measurements.
Copyright Acknowledgement: © 2005 DigiNet ® Corporation, All Rights Reserved
Author’s Biography
Mark A. Miller, P.E. is President of DigiNet ® Corporation, a Denver-based consulting engineering firm. He is the author of many books on networking technologies, including Voice over IP Technologies, and Internet Technologies Handbook, both published by John Wiley & Sons.
