Abstract

The DS34T10x and DS34S10x TDM-over-Packet (TDMoP) devices utilize jitter buffers to compensate for the packet-delay variation (PDV) that is present in packet networks. This application note explains PDV and how it affects communication quality. The function and types of jitter buffers are discussed. The article also describes how to set the jitter buffer controller’s parameters in TDMoP devices to minimize the effects of PDV.

Introduction

The DS34T10x and DS34S10x families of TDM-over-Packet (TDMoP) devices use jitter buffers to compensate for the packet-delay variation (PDV) that is present in packet networks. These buffers are independently configurable on a per-bundle or per-connection basis. Additionally, they are dynamically adjustable, allowing them to be adapted in real-time to changes in the performance characteristics of the packet network. This application note discusses the jitter buffer controller and how to set its parameters to minimize the effects of PDV during TDM clock recovery.

DS34T10x comprises the DS34T101, DS34T102, DS34T104, and DS34T108; DS34S10x comprises the DS34S101, DS34S102, DS34S104, and DS34S108.

Timing in a TDM Network

TDM networks have a single-clock source used by all devices in the network. Destination TDM devices derive the clock from incoming data and use it for transmitting data (loopback timing), as shown in Figure 1.

Figure 1. Loopback timing in a TDM network.

Variations in packet arrival time, called jitter, occur because of network congestion, timing drift, or route changes. Thus, when replacing the physical TDM connection with an IP/MPLS network and two TDMoP devices (as shown in Figure 2), the receiving TDMoP device (slave) receives TDMoP packets with variable delays in arrival time.

After processing the packets, the device should send TDM data to the TDM side at the constant rate of the TDM network to minimize the effects of this jitter. To achieve this constant data rate, the device works in clock-recovery mode to reconstruct the source TDM clock so that the destination TDM device can still work in loopback timing mode.

Figure 2. Timing in a TDM-over-Packet network.

Jitter Buffers

The DS34T10x/DS34S10x utilize jitter buffers to minimize the effects of PDV on communication quality. A jitter buffer is a shared memory area where TDM packets can be collected, stored, and sent to the circuit emulation engine in evenly spaced intervals. Located at the sending and receiving ends of the TDM connection, the jitter buffer intentionally delays the arriving packets so that the end user experiences a clear connection with very little to no sound distortion.

There are two kinds of jitter buffers: static and dynamic. The static jitter buffer is hardware-based and is configured by the manufacturer. The dynamic jitter buffer is software-based and can be configured by a network administrator to adapt to changes in the network's delay and PDV.

The DS34T10x/DS34S10x feature dynamic jitter buffers, located in the SDRAM. These jitter buffers have two main roles:

• Compensating for packet-delay variation
• Reconstructing the far-end TDM clock on a TDMoP slave device

For TDMoP protocols (CESoPSN, SAToP, and TDMoIP), bundles can comprise any number of 64kbps timeslots originating from a single E1 or T1. Bundles are single-direction streams, frequently coupled with bundles in the opposite direction to enable full-duplex communications. More than one bundle can be transmitted between two TDMoP edge devices.

The DS34T10x/DS34S10x provide large jitter buffers (up to 64 bundles) that are configurable on a per-bundle basis to compensate for the delay variation introduced by the IP/MPLS/Ethernet network. Each bundle can be assigned to any TDM port on a payload-type machine or CPU. All bundles feature the following independently configurable functions:

• Transmit and receive queues
• Receive-jitter-buffer depth
• Optional connection-level redundancy (for both SAToP and CESoPSN)

The resolution of SAToP and CESoP jitter buffers is different. For SAToP, precision is in bytes, so the variables can be sized in increments around 4µs for E1 and 5µs for T1. For CESoP, precision is in frames, so the variables can be sized by 125µs increments for both E1 and T1. Because the entire packet must be stored before determining whether or not the packet is good, the minimum precision for the jitter buffer is a function of packet size. If it is a small packet (1 byte), then the minimum is 1 byte. If it is a large CES packet (1500 frames), then the minimum is 187.5ms, regardless of PDV.

Configuring the DS34T10x/DS34S10x Jitter Buffers

Configuring the jitter buffer's parameters correctly avoids underrun and overrun situations. Underrun occurs when the jitter buffer is empty (the entering rate is lower than the exiting one). When an underrun event occurs, the chip transmits conditioning data instead of actual data to the TDM interface. Overrun occurs when the jitter buffer is full and there is no room for new data to enter (the entering rate exceeds the exiting one). Underrun and overrun require special treatment from the IC's hardware, depending on the bundle type.

The DS34T10x/DS34S10x allocate separate areas in the external SDRAM for data and for signaling.

• In 8-port low-speed mode, both data and signaling areas are divided into eight identical sections, one for each E1/T1/Nx64 interface.
  • In E1/T1 structured mode, each data section contains the data of 32 timeslots for E1 or 24 timeslots for T1; a single E1/T1 timeslot is allocated a maximum of 4kB of space. There is a total of 256 timeslots and 1024kB of space for all eight interfaces.
  • Each signaling section is divided into multiframe sectors, with each multiframe sector containing the signaling nibbles of up to 32 timeslots. There is a total of 64kB for all eight interfaces.
  • In serial or E1/T1 unstructured mode, there is no per-timeslot allocation. The jitter buffer is divided into eight identical sections, one for each interface. Each section is 512kB per HDLC bundle, or 128kB otherwise.
• For high-speed mode (E3/T3, STS-1), the jitter buffer acts as one large buffer, without division into sections and with a total of 512kB.

• E1: up to 256ms
• T1 unframed: up to 340ms
• T1 framed: up to 256ms
• T1 framed with CAS: up to 192ms

½ × Buffer area per interface x (8 / Rate)(Eq. 1)

where:

The jitter buffer's depth is defined by the Rx_max_buff_size parameter found in the Bundle Configuration tables. When the jitter buffer level reaches the value of Rx_max_buff_size, an overrun situation is declared.

The Rx_pdvt parameter (also found in the Bundle Configuration tables) defines the amount of data to be stored in the jitter buffer to compensate for network-delay variation. Figure 3 shows the jitter buffer parameters. The Rx_pdvt parameter has two implications:

• Rx_pdvt defines the IC's immunity to the Ethernet network-delay variation
• The data arriving from the network is delayed by Rx_pdvt before it is sent to the TDM line

Figure 3. Jitter buffer parameters.

The jitter buffer controller (JBC) uses a 64-bit by 32-bit Bundle Timeslots table to identify the assigned timeslots of each active bundle. The index to the table is the bundle number. The software must configure each active bundle entry. For unstructured bundles, the whole bundle entry (32 bits) must be set—setting a bit means that the corresponding timeslot is assigned to this bundle.

JBC statistics are stored in a 128-entry table. Each TDM port has 32 dedicated entries—one per timeslot. The Jitter Buffer Status table stores the statistics of an active jitter buffer for each active bundle. A configurable parameter called Jitter_buffer_index (located in the TSA tables) defines the entry in the table in which jitter buffer statistics are stored, and from which they are read.

The software accesses the Jitter Buffer Status table according to the Jitter_buffer_index. The status table contains the current jitter buffer status, such as the jitter buffer level and state (e.g. ok, underrun, or overrun). It also contains two variables, which report the jitter buffer minimum and maximum levels. These variables provide information about network characteristics for the user. For example, using these values, the user can calculate the margins from the top (Rx_max_buff_size) and the bottom of the jitter buffer. If there is spare capacity, the user may want to reduce Rx_pdvt to limit the latency added by the jitter buffer to the incoming data.

The user should define the value of the Jitter_buffer_index as follows:

• For AAL1/HDLC/RAW structured bundles, the Jitter_buffer_index is the concatenation of the interface number (2 Msbits) and the number of the lowest timeslot in the bundle. For example, if the bundle consists of timeslots 2, 4, and 17 on the third interface, the Jitter_buffer_index is 10_00010[bin], i.e., 42[hex].
• For unstructured bundles, the jitter_buffer_index is the concatenation of the interface number (2 Msbits) and five '0's.
• For AAL2 bundles, each timeslot data is stored in its own jitter buffer; therefore, the Jitter_buffer_index is the concatenation of the interface number (2 Msbits) and the timeslot number. For example, if the bundle consists of timeslots 2, 4, and 17 on the first interface, there are three jitter buffers—one for each timeslot—and the Jitter_buffer_index values are 2[hex], 4[hex] and 11[hex], respectively.

If a packet is misordered in a RAW bundle—for example, the packet with the sequence number N arrives after the packet with sequence number N+1—it is reordered by the RAW payload-type machine. The packet's data is inserted into the appropriate location in the jitter buffer, assuming that the data in this location has not been transmitted to the TDM domain yet.

Conclusion

A jitter buffer temporarily stores arriving packets to minimize delay variations. If packets arrive too late, then they are discarded. Sometimes jitter buffers are misconfigured so that they are either too small or too large. If a jitter buffer is too small, then an excessive number of packets may be discarded, which can lead to call quality degradation. If a jitter buffer is too large, then the additional delay can lead to conversational difficulty. Configuring the jitter buffer parameters correctly avoids these underrun and overrun situations.

If you have further questions on TDMoP products or any other aspect of using Maxim's telecom products, please contact the Telecom Products applications support team by email at or by phone at 01-972-371-6555.