TIA IP Telephony QoS Recommendations

The TIA has done extensive research and analysis to understand IP telephony voice quality. It used the ITU-T recommendation G.107 E-model to develop its own recommendations for optimizing IP telephony QoS levels, categorizing them by sources of potential speech impairment: delay, speech compression, packet loss, tandeming, and loss plan. The E-model consists of several models that relate specific speech impairment factors and their interactions with end-to-end performance.

The specific recommendations, as summarized in TIA/EIA/TSB116, are:

• Delay recommendation 1—Use G.711 end to end because it has the lowest Ie value (equipment impair value) and therefore allows more delay for a given voice quality level.

• Delay recommendation 2—Minimize the speech frame size and the number of frames per packet.

• Delay recommendation 3—Actively minimize jitter buffer delay.

• Delay recommendation 4—Actively minimize one-way delay.

• Delay recommendation 5—Accept the [TIA’s] E-model results, which permit longer delays for low Ie codecs, like G.711, for a given R value (transmission rating factor).

• Delay recommendation 6—Use priority scheduling for voice-class traffic, RTP header compression, and data packet fragmentation on slow links to minimize the contribution of this variable delay source.

• Delay recommendation 7—Avoid using slow serial links.

• Speech compression recommendation 1—Use G.711 unless the link speed demands compression.

• Speech compression recommendation 2—Speech compression codecs for wireless networks and packet networks must be rationalized to minimize transcoding issues.

• Packet loss recommendation 1—Keep (random) packet loss well below 1 percent.

• Packet loss recommendation 2—Use packet loss concealment (PLC) with G.711.

• Packet loss recommendation 3—If other codecs are used, then use codecs that have built-in or add-on PLCs.

• Packet loss recommendation 4—New PLCs should be optmized for less than 1 percent of (random) packet loss.

• Transcoding recommendation 1—Avoid transcoding where possible.

• Transcoding recommendation 2—For interoperability, IP gateways must support wireless codecs or IP must implement unified transcoder-free operations with wireless.

• Tandeming recommendation 1—Avoid asynchronous tandeming, if possible.

• Tandeming recommendation 2—Synchronous tandeming of G.726 is generally permissible. Impairment depends on delay, so long-delay digital circuit multiplication equipment (DCME) equipment should be avoided.

• Loss Plan recommendation 1—Use TIA/EIA/TSB122-A, the voice gateway loss and level plan.

Following the Cisco Systems and TIA recommendations and guidelines may prove to be a difficult task if aging network infrastructure is installed that cannot support most, if not all, of these QoS control mechanisms. It is obvious from the material covered in this chapter that a close working relationship between voice and data communications personnel is required to successfully implement and operate an IP-PBX systems. If IP telephony QoS is not comparable to the experience station users have grown accustomed to with their circuit switched PBX system, the new technology may be rejected as an enterprise communications solution, even if it offers potential cost savings and the benefit of new applications support. A green field location offers the best bet for a large IP-PBX system installation because it is easier to begin from scratch than to attempt a network upgrade while continuing to support ongoing communications operations.

The DiffServ model divides traffic into a small numbers of classes. One way to deploy DiffServ is simply to divide traffic into two classes. Such an approach makes good sense. If you consider the difficulty that network operators experience just trying to keep a best-effort network running smoothly, it is logical to add QoS capabilities to the network in small increments.

Suppose that a network operator has decided to enhance a network by adding just one new service class, designated as “premium.” Clearly, the operator needs some way to distinguish premium (high-priority) packets from best-effort (lower-priority) packets. Setting a bit in the packet header as a one could indicate that the packet is a premium packet; if its a zero, the packet receives best-effort treatment. With this in mind, two questions arise:

• Where is this bit set and under what circumstances?

• What does a router do differently when it sees a packet with the bit set?

A common approach is to set the bit at an administrative boundary, such as at the edge of an Internet service provider’s (ISP’s) network for some specified subset of customer traffic. Another logical place would be in a VoIP gateway, which could set the bit only on VoIP packets.

What do the routers that encounter marked packets do with them? Here again there are many answers. The DiffServ working group of the IETF has standardized a set of router behaviors to be applied to marked packets, which are the PHBs. PHBs define the behavior of individual routers rather than of end-to-end services. Because there is more than one new behavior, there is a need for more than one bit in the packet header to tell the routers which behavior to apply. The IETF has decided to take the ToS byte from the IP header, which has not been widely used in a standard way, and redefine it. Six bits of this byte have been allocated for DSCPs. Each DSCP is a 6-bit value that identifies a particular PHB to be applied to a packet. Current releases of Cisco IOS software use only 3 bits of the ToS byte for DiffServ support. This is adequate for most applications, allowing up to eight classes of traffic. Full 6-bit DSCP support is under development.

One of the simplest PHBs, and one that is a good match for VoIP, is EF. Packets marked for EF treatment should be forwarded with minimal delay and loss at each hop. The only way that a router can guarantee this to all EF packets is if the arrival rate of EF packets at the router is limited strictly to less than the rate at which the router can forward EF packets. For example, a router with a 256-kbps interface needs to have an arrival rate of EF packets destined for an interface that is less than 256 kbps. In fact, the rate must be significantly below 256 kbps to deal with bursts of arriving traffic and to ensure that the router has some ability to send other packets.

The rate limiting of EF packets may be achieved by configuring the devices that set the EF mark (e.g., VoIP gateways) to limit the maximum arrival rate of EF packets into the network. A simple, albeit conservative, approach would be to ensure that the sum of the rates of all EF packets entering the network is less than the bandwidth of the slowest link in the domain. This would ensure that, even in the worst case, where all EF packets converge on the slowest link, the link is not overloaded and the correct behavior results.

In fact, the need to limit the arrival rate of EF packets at a bottleneck link, especially when the topology of the network is complex, turns out to be one of the greatest challenges of using only DiffServ to meet the needs of VoIP. For this reason, an approach based on integrated service and the RSVP is appropriate in those situations where it is not possible to guarantee that the offered load of voice traffic will always be significantly less than link capacity for all bottleneck links.