Attività

Taking an Inside Look at TDMoIP: A Tutorial

Service providers are presently seeking to increase their profits through low cost deployment of voice and leased line services over more efficient Ethernet and IP infrastructures. At the same time enterprises are looking for ways to take advantage of the promise of convergence by integrating their voice and data networks while preserving their investment in traditional PBX and TDM equipment. The voice-over-IP (VoIP) approach is maturing, but its deployment requires a certain level of investment in new network infrastructure and/or customer premises equipment (CPE).

TDM-over-IP (TDMoIP) is a technology that enables voice and leased-line services such as video and data to be offered inexpensively over service provider IP networks while retaining the reliability and quality of the public switched telephone network (PSTN). In this article, we'll discuss the technical challenges inherent in transporting TDM circuits over IP networks, how TDMoIP technology meets those challenges, and the standards shaping TDMoIP and related technologies.

Challenges of Transporting TDMConventional TDM networks are highly deterministic. A source device transmits one or more octets to a destination device via a dedicated-bandwidth channel every 125 μs. The circuit delay through a TDM network is predictably low and constant throughout the life of a connection. Timing is delivered along with the data, and the permitted variability (jitter and wander) of TDM clocks is tightly defined. In addition, the infrastructure supports a rich set of user features via a vast set of signaling protocols.

Packet-switched networks (PSNs), such as IP/multi-protocol label switching (MPLS) systems, are more efficient than TDM networks due to bandwidth sharing. However, this sharing leads to PSNs being inherently non-deterministic.

Packets entering and transiting the network must compete for bandwidth and switch/router ports, leading to packet delay variation (PDV) and lost packets. A source device may inject packets into the network at regular intervals, but the network offers no guarantee that these packets will arrive at the destination edge device spaced at the same intervals, in the same order, or even that they will arrive at all.

In addition, IP networks were designed for transport of arbitrary data. Thus, TDM-related signaling is not supported.

There are two main ways that designers are trying to integrate TDM services into IP-based networks. On one hand, designers can completely replace the TDM network and end-user equipment with a new infrastructure that provides innovative mechanisms for voice transport and signaling. The other approach leaves the end-user equipment and protocols intact, tunneling TDM data through the packet network.

In the end, this second approach could provide an easier and most cost-effective migration path for carriers and equipment vendors. With that in mind, let's dive into how TDMoIP works.

Diving into TDMoIPTDMoIP emulates T1, E1, T3, E3, and N*64K links by adapting and encapsulating the TDM traffic at the network ingress. Adaptation denotes mechanisms that modify the payload to enable its proper restoration at the PSN egress. By using proper adaptation, the TDM signaling and timing can be recovered, and a certain amount of packet loss can be accommodated.

Encapsulation signifies placing the adapted payload into packets of the format required by the underlying PSN technology. TDMoIP encapsulations are presently defined for user datagram protocol (UDP)/IP, MPLS, and Layer 2 tunneling protocol (L2TP)/IP networks, and even pure Ethernet can be utilized with minimal adjustments. Let's take a closer look at adaptation and encapsulation.

How Adaptation WorksTDMoIP can utilize several different adaptation techniques, depending on the TDM traffic characteristics. Whenever possible, TDMoIP draws on proven adaptation mechanisms originally developed for ATM. A side benefit of this choice of payload types is simplified interworking with circuit emulation services carried over ATM networks.

For statically allocated, constant bit-rate (CBR) TDM links, TDMoIP employs ATM adaptation layer 1 (AAL1). This mechanism, defined in ITU-T standard I.363.1 and ATM Forum specification atm-vtoa-0078, was developed for carrying CBR services over ATM.

AAL1 operates by segmenting the continuous stream of TDM data into small 48-byte cells and inserting sequencing, timing, error recovery, and synchronization information into them. For example, if the original TDM stream consisted of a DS1 with channel associated signaling (CAS), the AAL1 adaptation inserts a pointer to the beginning of the next superframe. Thus, even if cells are lost, the pointer will enable recovery from the next superframe.

TDMoIP allows concatenation of any number of AAL1 cells into a packet (note that these are AAL1 cells and not ATM cells, i.e. they do not include the five-byte “cell tax”). By allowing multiple cells per packet, TDMoIP facilitates flexible tradeoffs of buffering delay (which decreases with fewer cells per packet) for bandwidth efficiency (which increases with more cells per packet, due to the per packet overhead).

For dynamically allocated TDM links, whether the information rate varies due to activation of time slots or due to voice activity detection, TDMoIP employs ATM adaptation layer 2 (AAL2). This mechanism, defined in ITU-T standard I.366.2, was developed for carrying variable bit rate (VBR) services over ATM.

AAL2 operates by buffering each TDM time slot into short minicells, inserting the time slot identifier and length indication, sequencing, and then sending this minicell only if it carries valid information. TDMoIP concatenates the minicells from all active time slots into a single packet.

For time slots carrying high-level data link control (HDLC) data, such as data for common channel signaling (CCS), a special adaptation is provided that spots areas of non-idle data, which can then be directly encapsulated.

Encapsulating TDM DataIn TDMoIP packets, payload information is immediately preceded by a control word. This 32-bit control word, shown in Figure 1 , contains the packet sequence number (needed to detect packet re-ordering and packet loss), the payload type, payload length, and alarm indications.