Determining the Suitability of a Packet Network for TDMoIP Traffic and Ensuring Quality of Service (QoS)

TDMoIP is a pseudowire emulation protocol that encapsulates TDM-based voice, video and data into IP for transport across packet networks. In order for the TDM circuit to be reliable, it is critical that the underlying infrastructure be equally reliable. Therefore if the network drops a packet, the TDM circuit will experience a burst of errors. Similarly the latency across the TDM circuit is directly affected by the latency of the underlying infrastructure and the latency of TDMoIP gateways. i.e:

Latency [TDM circuit] = Max. Latency [underlying infrastructure] + Latency [TDMoIP gateways] 

If you compare TDMoIP pseudowires with VoIP, you will see many similarities. For example, both are real-time protocols that use UDP/IP (and not TCP/IP) because they cannot afford the added latency of retransmission. TDMoIP pseudowires differs from VoIP by providing a transport solution (circuit emulation) that is transparent to protocols and signaling for voice, video and data applications. TDMoIP pseudowires also maintain synchronization over IP. VoIP is a much more complex protocol that is not transparent to signaling and therefore does not fully support existing PBX features. VoIP gateways also introduce much higher latency than TDMoIP pseudowire gateways and therefore voice quality is compromised. (Latency introduced by TDMoIP gateways starts at under 2 ms, whereas VoIP gateways introduce at least 45 ms of latency and frequently much more – see Appendix A for a comparison of TDMoIP pseudowire and VoIP latency and interactive voice quality).

In this Abstract, we will review the infrastructure elements, bandwidth requirements and Quality of Service (QoS) parameters necessary to control the consistency of the link (i.e. packet loss, maximum delay, maximum jitter).

The first question to ask in order to avoid any post-deployment surprises is: In what kind of shape is my existing network? Real-time traffic, especially voice, will be affected by any bottleneck on the network. A delay of 1 second in retrieving a data file from a server because of congestion might be barely noticeable to the user, but add just 50 milliseconds of delay to a phone call and it’s the difference between high-quality and poor-quality voice communications.

Before deploying TDMoIP pseudowire gateways, you should perform a network audit that includes two primary considerations:

· Utilization and network statistics

· Review of infrastructure elements

Utilization and network statistics

Maximum, minimum and average metrics for bandwidth consumption, latency, jitter and packet loss should be included in your audit.

In the case of bandwidth utilization, the hotspot for potential bottlenecks lies in the inter-switch links that make up your network. These links should have sufficient bandwidth and packet per second (PPS) processing power to support all the TDMoIP pseudowire traffic reliably and consistently.

Latency, jitter and packet loss could be the result of antiquated equipment (such as hubs [always half-duplex], 10 Mbps Ethernet switches or switches with low memory capacities) or silly mistakes. Examples would be a switch with its auto-negotiation algorithm disabled, forcing all switch ports to default to 10 Mbps half-duplex communications; or a swath of Ethernet cable that’s a lot longer than 328 feet, the maximum supported Category 5 cable length for Ethernet.

Be especially careful when deploying routers with limited packet per second (PPS) processing power. For example, deploying multiple E1s /T1s of TDMoIP traffic across Cisco routers may require that the Cisco Express Forwarding (CEF) feature be enabled to increase the PPS capability. Always avoid using the public Internet because there are no QoS guarantees. (The Internet only provides “best effort” resulting in high latency, jitter and packet loss.) Also avoid using 802.11b wireless Ethernet bridges because they do not have the symmetrical bandwidth necessary to carry a full E1/T1 of TDMoIP pseudowire traffic (note that there are many other wireless bridges that are capable of carrying one or more E1/T1s of traffic). Check that your network latency and jitter is low and your packet loss should be zero. The complete White Paper document “Determining the Suitability of a Packet Network for TDMoIP Pseudowire Traffic and Ensuring Quality of Service (QoS)” (and the IPmux operating manuals) include formulae and tables showing bandwidth and performance (PPS) requirements that must be met in order for the TDM circuits to be reliable.

Review of infrastructure elements

The gear that powers the network should be reviewed for necessary feature support and correct configurations. Ethernet switches that will be touched by TDMoIP pseudowire traffic should have VLAN support. This will allow segmentation and isolation of your TDM traffic across the data network.

IP-based quality of service (QoS) – such as Type of Service (TOS) or Differentiated Services (Diff-Serv) – should be supported in a routed environment with multiple subnets. In a large TDMoIP deployment, this allows prioritization of packetized TDM traffic over more delay-tolerant traffic.

What type of application will use this TDM circuit?

IF voice, then how sensitive is the voice to latency? For example:

When voice channels pass through a 2-wire to 4-wire hybrid (typical with analog channel banks), you will often create echo; and echo is noticeable if not cancelled or when the latency exceeds about 25 ms.

Voice compression equipment usually includes echo cancellation. Therefore it will be less sensitive to latency.

Uncompressed voice between PBXs that support 4-wire digital phone sets will usually be less sensitive to latency than their analog counterparts (because there is no 2-wire to 4-wire hybrid).

IF signaling (e.g. SS7) is carried on the TDM circuit, then timeout parameters should take network latency into consideration.

IF ATM or Frame Relay is carried on the TDM circuits, then the network latency needs to be lower than that required by the application. 

What is the type of TDM circuit (unframed, full/fractional, full/fractional with CAS)?

IF unframed, then is the circuit E1, T1, E3 or T3?

Unframed is useful when the circuit needs to be transparent to framing. Equipment at either end of the TDM circuit will synchronize with one another and not with the TDMoIP gateways.

Fractional and channelized services are not possible.

IF full/fractional, then how many timeslots?

How many of these TDM circuits need to be supported?

TDM bytes per frame [TDM bytes/frame] is a configurable parameter that controls the number of TDM bytes encapsulated in one UDP/IP/Ethernet frame. For maximum flexibility, it can be configured per bundle. You can configure TDM bytes/frame in multiples of 48 bytes (n x 48) per frame where n is an integer between 1 and 9 for E1/T1, and between 5 and 30 for E3/T3. As you increase the number of TDM bytes in an UDP/IP/Ethernet frame, so you reduce the overhead per packet and therefore the amount of bandwidth and packets per second required. 

On the other hand, packetization delay and intrinsic packet delay variation (PDVT) also increase as you increase the number of TDM bytes/frame and this contributes to higher end-to-end delay. This effect is negligible when a full E1/T1 or E3/T3 is transferred, but the delay can be very significant when only a few E1/T1 timeslots are transferred. If only a few timeslots are being packetized, it will take longer to fill a larger frame and therefore the packetization delay, and the intrinsic PDV can be very large and may exceed the maximum PDVT (jitter) buffer on the receiving end.

In order to calculate how much bandwidth (bps) and processing power (PPS) the packet network must provide the TDM application, and to calculate the added latency introduced to the TDM circuit, the following is required:

1) Select how many TDM bytes will be carried in each frame.

2) Calculate the bandwidth (Ethernet load) and performance in frames/second (PPS) required of the packet network.

3) Calculate the intrinsic PDV. 

4) Determine the configuration setting for the jitter buffer depth.

5) Calculate end-to-end and round-trip delay.

* Interactive ratings are the average of at least six individual rating made by each of at least three experienced Miercom VoIP lab testers. The testers, in rotation, conduct real-time, two-way conversations and special tests, over separate connections, between identical analog phones connected via the VoIP gateway under test. The interactive (or conversational) quality of each connection is then rated, based on: the effect of latency; clarity, including background noises; and bidirectionality.

** One-way latency, including network delays, in milliseconds.

Source: Business Communications Review/Sept 2001