 | This article includes a list of references, related reading, or external links, but its sources remain unclear because it lacks inline citations. Please help improve this article by introducing more precise citations. (October 2014) (Learn how and when to remove this message) |
In computer networking and telecommunications, TDM over IP (TDMoIP) is the emulation of time-division multiplexing (TDM) over a packet-switched network (PSN). TDM refers to a T1, E1, T3 or E3 signal, while the PSN is based either on IP or MPLS or on raw Ethernet. A related technology is circuit emulation, which enables transport of TDM traffic over cell-based (ATM) networks.
TDMoIP is a type of pseudowire (PW). However, unlike other traffic types that can be carried over pseudowires (e.g. ATM, Frame Relay and Ethernet), TDM is a real-time bit stream, leading to TDMoIP having unique characteristics. In addition, conventional TDM networks have numerous special features, in particular those required in order to carry voice-grade telephony channels. These features imply signaling systems that support a wide range of telephony features, a rich standardization literature and well-developed Operations and Management (OAM) mechanisms. All of these factors must be taken into account when emulating TDM over PSNs.
One critical issue in implementing TDM PWs is clock recovery. In native TDM networks the physical layer carries highly accurate timing information along with the TDM data, but when emulating TDM over PSNs this synchronization is absent. TDM timing standards can be exacting and conformance with these may require innovative mechanisms to adaptively reproduce the TDM timing.
Another issue that must be addressed is TDMoIP packet loss concealment (PLC). Since TDM data is delivered at a constant rate over a dedicated channel, the native service may have bit errors but data is never lost in transit. All PSNs suffer to some degree from packet loss and this must be compensated when delivering TDM over a PSN.
In December 2007 TDMoIP was approved as an IETF RFC 5087 authored by Dr. Yaakov Stein, Ronen Shashua, Ron Insler, and Motti Anavi of RAD Data Communications.
Background
Communications service providers and enterprise customers are interested in deployment of voice and leased line services over efficient Ethernet, IP and MPLS infrastructures. While Voice over IP (VoIP) is maturing, its deployment requires an investment in new network infrastructure and customer premises equipment (CPE). TDMoIP presents a migration path, whereby modern packet switched networks can be used for transport, while the end-user equipment need not be immediately replaced.
TDMoIP was first developed in 1998 by RAD Data Communications (see U.S. patent number 6,731,649) and first deployed in Sweden in 1999 by Utfors (later acquired by Telenor). Utfors employed the first generation TDMoIP product (known as IPmux-4) to provide bundled services including TDM private lines, TDM leased lines and a variety of IP and Ethernet services. In 2001, the IETF set up the PWE3 working group, which was chartered to develop an architecture for edge-to-edge pseudowires, and to produce specifications for various services, including TDM. Other standardization forums, including the ITU and the MPLS - Frame Relay Alliance, are also active in producing standards and implementation agreements for pseudowires.
Handling TDM structure
Although TDM can be used to carry arbitrary bit streams at the rates defined in G.702, there are standardized methods of carrying bit streams in larger units each containing the same number of bits, called frames. TDM framing locks the frame rate to the sampling frequency of voice traffic, so that there are always 8000 frames per second; a T1 frame consists of 193 bits and an E1 frame of 256 bits.
Unlike unframed TDM for which all bits are available for payload, framed TDM requires dedicating of some number of bits per frame for synchronization and perhaps various other functions (e.g. 1 bit per T1 frame, 8 bits per E1 frame). Framed TDM is often used to multiplex multiple voice channels each consisting of 8000 8-bit samples per second in a sequence of timeslots recurring in each frame. When this is done we have "channelized TDM" and additional structure must be introduced.
In order to efficiently transport slowly varying channel associated signalling bits, second order structures known as multiframes or superframes are defined. For example, for E1 trunks the CAS signaling bits are updated once per multiframe of 16 frames (every 2 milliseconds) while for T1 ESF trunks the superframe is 24 frames (3 milliseconds). Other types of second order structures are also in common use. In GSM cellular networks, the Abis channel that connects the Base Transceiver Station (BTS) and Base Station Controller (BSC) is an E1 link with several framing alternatives, all of which have a basic superframe duration of 20 milliseconds.
The term "structured TDM" is used to refer to TDM with any level of structure, including 'framed TDM' and 'channelized TDM'.
TDMoIP transport is denoted "structured-agnostic" when the TDM is unframed, or when it is framed or even channelized, but the framing and channelization structure are completely disregarded by the transport mechanisms. In such cases all structural overhead must be transparently transported along with the payload data, and the encapsulation method employed provides no mechanisms for its location or utilization. Structure-aware TDM transport may explicitly safeguard TDM structure, in three conceptually distinct ways, which we shall call structure-locking, structure-indication, and structure-reassembly.
Structure-locking ensures that packets consist of entire TDM structures or multiples/fractions thereof. Structure-indication allows packets to contain arbitrary fragments of basic structures, but employs pointers to indicate where the following structure commences. In structure-reassembly components of the TDM structures may be extracted and reorganized at ingress, and the original structure reassembled from the received constituents at egress.
TDMoIP format
TDMoIP operates by segmenting, adapting and encapsulating the TDM traffic at PSN ingress and performing the inverse operations at PSN egress. 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. For the MPLS case, ITU-T Recommendation Y.1413 contains a complete description of the packet format.
In all cases a TDMoIP packet commences with PSN headers. These are the standard headers used by the PSN technology, e.g. the 20-byte header of UDP/IP, or the label-stack of MPLS. After these headers come the "PW label", a four-byte MPLS-like label that serves as to demultiplex different TDM PWs. After the PSN header comes the four-byte TDMoIP "control word". The control word contains a 16-bit packet sequence number (needed to detect packet re-ordering and packet loss), payload length, and flags indicating defect conditions.
After the control word comes the TDMoIP payload. For structure-agnostic transport (SAToP) this is simply a predetermined number of TDM octets, while for the structure-locked format the payload is an integer number of TDM frames. For structure-indication and structure-reassembly 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. 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.363.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), TDMoIP has a special adaptation that encapsulates stretches of non-idle data.
Delay
The telephony network severely constrains end-to-end delays. ITU-T G.114/G.131 states that one-way transmission times of up to 150 ms are universally acceptable, assuming adequate echo control is provided. These constraints are not problematic for TDM networks, where the major component of the end-to-end delay is electrical propagation time ("light speed delay"). By contrast, IP-based systems typically add various forms of delay, one of which is based on the time it takes to form packets (packetization delay), which is proportional to the packet size divided by the data rate. Packet sizes cannot be made too small or the packet header overhead will become overwhelming. The other form of delay introduced by IP systems is the playout delay, which needs to be added at the recipient to buffer packet delay variation and ensure a smooth playout. VoIP systems that try to be very bandwidth efficient may also add tens of milliseconds of algorithmic delay in the voice codec. Historically, bad implementations have added additional, operating-system induced delays, which together with the other delays in practice sometimes approach 100 ms even before taking propagation delays into account.
In contrast, TDMoIP maps TDM octets directly into the payload with no voice compression algorithms and no resultant algorithmic delay. The packetization latency added by TDMoIP depends on the number of cells per packet but is typically in the single millisecond range due to the higher data rate of a complete multiplex as compared to a single VoIP flow. Playout delay considerations do not differ materially between TDMoIP and VoIP, however, so both work best on paths with controlled packet delay variation (strong overprovisioning or "QoS").
Timing recovery
Native TDM networks rely on hierarchical distribution of timing. Somewhere in the network there is at least one extremely accurate primary reference clock with a long-term accuracy of 1 x 10^-11. This node, which offers Stratum 1 accuracy, provides the reference clock to secondary nodes with Stratum 2 accuracy. The secondary nodes then provide a time reference to Stratum 3 nodes. This hierarchy of time synchronization is essential for the proper functioning of the network as a whole.
Packets in the PSN reach their destination with delay that has a random component, known as packet delay variation (PDV). When emulating TDM transport on such a network, this randomness may be overcome by placing the TDM packets into a jitter buffer from which data can be read out at a constant rate for delivery to TDM end-user equipment. The problem is that the TDM source time reference is no longer available, and the precise rate at which the data are to be "clocked out" of the jitter buffer is unknown.
In certain cases timing may be derived from the TDM equipment at both ends of the PW. Since each of these clocks is highly accurate, they necessarily agree to high order. The problem arises when at most one side of the TDMoIP tunnel has a highly accurate time standard. For ATM networks, which define a physical layer that carries timing, the synchronous residual time stamp (SRTS) method may be used; IP/MPLS networks, however, do not define the physical layer and thus cannot specify the accuracy of its clock.
Hence, in many cases the only alternative is to attempt to recover the clock based exclusively on the TDMoIP traffic, a technology known as "adaptive clock recovery". This is possible since the source TDM device is producing bits at a constant rate determined by its clock, although this rate is hidden by the PDV. The task of clock recovery is thus an "averaging" process that negates the effect of the random PDV and captures the average rate of transmission of the original bit stream.
Packet loss
While proper application of traffic engineering and quality of service (QoS) is expected to minimize packet loss, packets will at times arrive at the egress out of order. They may also have been dropped altogether within the PSN. The TDMoIP control word described above includes a 16-bit sequence number for detecting and handling lost and mis-ordered packets. In the case of lost packets, TDMoIP requires insertion of interpolation packets to maintain TDM timing. Misordered packets may be either reordered or dropped and interpolated.
While the insertion of arbitrary packets may be sufficient to maintain the TDM timing, in voice applications packet loss can cause gaps or errors that result in choppy, annoying, or even unintelligible speech. The precise effect of packet loss on voice quality and the development of packet loss concealment algorithms have been the subject of detailed study in the VoIP community, but their results are not directly applicable to the TDMoIP case. This is because VoIP packets typically contain between 80 samples (10 ms) and 240 samples (30 ms) of the speech signal, while TDMoIP packets may contain only a small number of samples. Since TDMoIP packets are so small, it is acceptable to simply insert a constant value in place of any lost speech samples. Assuming that the input signal is zero-mean (i.e. contains no DC component), minimal distortion is attained when this constant is set to zero. Alternatively, more sophisticated approaches call for optimally predicting the values of missing samples.
External links
- TDMoIP
- Pseudo Wire Emulation Edge to Edge (pwe3) at the Wayback Machine (archived 2004-12-04)