Circuit Emulation Provides Viable Alternative to VoIP -

Circuit Emulation Provides Viable Alternative to VoIP

Despite the industry attention it has received, voice-over-IP (VoIP) is not the only way to send voice across a packet-switched network. In fact, it may not even be the best approach for some applications. There is an alternative—circuit emulation services over packet (CESoP).

Circuit emulation has come a long way from its original ATM roots. Circuit emulation service over ATM—now a widely deployed technology—did not take the industry by storm, primarily because of the additional overhead required to carry a TDM circuit over an ATM network. Today, however, there are cost and efficiency benefits that favor a more rapid adoption of circuit emulation service for transporting voice services over packet networks.

This article examines the basics of making circuit emulation services work. The article will also compare CESoP to VoIP to demonstrate the strengths of both technologies and how these different capabilities may be best exploited.

CESoP: What's It All About?
The concept of CESoP is straightforward. The basic idea is to “tunnel” a TDM circuit (such as a T1 or E1) through a packet-switched network, so that the TDM equipment at either end is unaware that they are connected by anything other than a TDM network. The packet-switched network is being used to emulate the behavior of a TDM circuit; hence the term “circuit emulation” (Figure 1) .

Figure 1: Circuit emulation service across a packet-switched network

Circuit emulation requires an interworking function at both ends of the packet-switched network. The interworking function converts the TDM data into a series of packets on ingress into the packet-switched network, and re-creates the TDM circuit on egress.

There are two basic approaches to this interworking function:

  1. Structured emulation
  2. Unstructured emulation or structure-agnostic

The structured approach (Figure 2 below) uses the timeslot structure inherent in TDM circuits. The framing structure (e.g. the F bit in a DS1) is first stripped from the data stream. Then each timeslot is added to the packet payload in turn, followed by the same timeslots from the next frame, and so on. When the payload is complete, a packet header is added, and the packet dispatched into the packet-switched network. The payload will typically contain around eight frames of TDM data (192 octets for a DS1). On the egress from the packet network, the TDM data stream is re-created, and a new framing structure imposed.

Unstructured transport (also called structure-agnostic transport) ignores any structure that may be present in the TDM circuit, and treats it as pure bit-stream at a given data rate. The packet payload is made up of a series of octets taken in series from the TDM bit stream. The number of octets chosen to make up each packet payload is arbitrary, and any alignment of these octets with the underlying timeslots is coincidental and not guaranteed. Typically, the length of the payload is chosen to make the packet formation time around 1 ms. For a T1 circuit, this length is 193 octets (Figure 2).

Figure 2: Structured circuit emulation service and unstructured circuit emulation service.

Packet Network Considerations
A packet network exhibits significantly different characteristics from those in TDM networks; these differences affect the performance and fidelity of any circuit emulation system. The principal characteristics that must be considered are packet loss, packet re-ordering, and variation in packet delay.

Packet loss causes a short-interval break in the TDM data stream. This must be compensated for, or the end-to-end delay through the emulated system will change. Normally, a CESoP interworking function will insert a quantity of data into the outgoing TDM stream that is the same length as the data that has been lost.

The content of this data is arbitrary, and may be varied to suit the application. For example, if the emulated circuit is carrying voice traffic, interpolation methods could be used to estimate the contents of the timeslots. However, if the circuit is carrying data, interpolation methods are invalid and a fixed value could be used.

Packets can also be re-ordered within the network. If some packets take a faster alternative route through the network, for example, they will come in ahead of packets that were originally transmitted first. A CESoP interworking function requires the ability to put the packets back into the correct sequence before re-creating the TDM data stream.

Finally, even if the packets all take the same route through the network, there will still be some variation in the time taken to reach the egress interworking function. This is known as “packet delay variation” or “packet jitter”. Since TDM circuits are constant bit rate, fast arriving packets must be buffered before being played out, thus equalizing the delay with other, slower arriving packets. This buffer is called a “jitter buffer”.

Timing Recovery
One of the most critical issues for any circuit-over-packet technology is timing recovery. For example, with a private leased line between two customer sites connected by an emulated link across a carrier's packet network, the TDM service frequency fservice at the customer premises must be exactly reproduced at the egress of the packet network. A long-term mismatch in frequency results in a queue at packet network egress that will either fill up or empty, depending on whether the regenerated clock is slower or faster than the original. Both cause loss of data and degradation of the service.

In a packet network, packets are discontinuous in time, so the connection between the ingress and egress frequency will be broken. Therefore, unless there is an external means of clock distribution, the interworking function at packet egress will be required to recover the frequency of the original TDM service clock by some means (Figure 3) .

Figure 3: Emulated TDM service with clock recovery functionality.

Clock recovery is the process of inferring the frequency of the original clock fservice from the varied arrival rate of the packets. However, TDM networks have very strict requirements on the stability of clocks, as defined by the ITU-T's G.823 and G.824 standards. As a result, the arrival rate needs to be filtered to remove effects caused by packet delay variation. This is not a trivial exercise, since the packet delay variation may contain extremely low-frequency components.

For example, a packet network may be more heavily utilized during the day than at night, resulting in congestion and longer transit delays. This causes a variation in packet delay on a 24-hour cycle that may feed into the frequency of the recovered clock.

CESoP: Definitely Not VoIP
CESoP is a powerful alternative to VoIP. Analysis shows that CESoP is less costly, less complex, easier to implement, and supports more applications over a wider range of packet networks, while guaranteeing carrier-quality services for end users. Let's look at five of the key benefits the technology provides.

1. Simplicity
Since CESoP is a tunneling technology, it requires no special signaling functions other than those already provided by the packet-switched network. TDM control signaling and control are simply tunneled along with the data to the remote TDM equipment. In contrast, VoIP requires a complete signaling stack and gatekeeper functionality based on H.248 (Megaco) or the session initiation protocol (SIP).

2. Granularity
CES is a more coarse-grained technology than VoIP. Essentially, instead of switching at the individual channel level, CES switches at the circuit level, where the circuit can be T1/E1, T3/E3 or even OC3/STM-1 or higher. This results in increased network management and control efficiencies.

By comparison, VoIP offers much greater control over the destinations of the individual channels. These are switched individually, meaning each channel can be routed to a different destination node in the packet network. Circuit emulation is best used where there are multiple channels to be switched together between the same two end points.

3. Latency and Bandwidth
The latency of an emulated circuit is generally lower, since a large packet can be built-up over a much shorter period of time. For example, a T1 connection consists of 24 channels, so building a payload of 192 octets takes eight frames (1 ms). To create the same-sized payload in conventional VoIP will take 192 frames, or 24 ms. This packetization delay must be added to the end-to-end latency of the connection, which means a VoIP connection will almost certainly require echo cancellation.

However, while the CES bandwidth overhead is low, VoIP bandwidth efficiency may be better due to the larger packet sizes relative to the header overhead. This is because working at the individual voice-channel level allows the use of bandwidth-saving techniques such as silence suppression or other compression solutions (ADPCM, CS-ACELP). In comparison, CES is still constant bit rate and does not exploit the statistical multiplexing capabilities of packet networks (i.e. the statistical likelihood that peaks of activity in different packet streams will not occur at the same time).

4. Flexibility
Circuit emulation makes no assumptions about the type of traffic being carried across the network—it could be voice, video, or packet data. The bits are carried transparently, and the re-creation of the TDM link at the far end is as faithful as possible to the original data. This makes CES a very flexible data-handling technology.

VoIP assumes that the data being carried comprises voice samples. Voice echo cancellation and compression techniques particular to voice may be applied to reduce bandwidth, destroying other types of data traffic and resulting in degraded service for the end user.

5. Timing
As described earlier, the main technical hurdle for any circuit-over-packet technology is timing and synchronization. The bits must be played out of the packet network at the same rate as which they entered, otherwise the jitter buffer at the destination node will either fill up or empty. Unless a common clock can be distributed to either end by an alternative means, then clock recovery is required, or the net result is loss of data integrity.

With a circuit emulation approach, synchronization is “built in” to the network. TDM circuits carry the clock, and either adaptive or differential clock recovery at the destination node ensures the TDM circuits remain synchronized with no buffer slips.

VoIP is also a constant bit rate service, so similar timing and synchronization considerations apply. In practice, however, VoIP occasionally drops or inserts a single sample of voice data. Providing the clocks are similar enough, this has a negligible effect on voice quality. Use of the same technique with data traffic has a more severe impact, causing re-transmission of the underlying packet and a resultant drop in the effective data rate.

Carrier/Enterprise Applications for CESoP
The primary carrier application for CESoP is the continued support of customers' TDM services. For example, service providers operating an Ethernet-based metropolitan access network will still want to support customers operating TDM connections to maintain the high-margin revenues generated by these legacy services. By implementing CESoP, customers do not have to upgrade their own equipment in order to implement packet-based services. Likewise, the carrier avoids upgrading the connection medium over the last mile (or last few feet) between their point of presence and the customer (Figure 4) .

Figure 4: Diagram of a circuit emulated access network.

These services take two main forms: private leased line, used to connect directly between two customer sites; and access lines, where the link is used to connect the customer site to the central office.

In some cases, for example service of a multi-tenant building or campus, a remote concentrator may be installed close to the customers. The remote concentrator aggregates the TDM and/or packet services provided to customers within that building, and uses circuit emulation to transport the services back over a point-to-point link to the nearest metropolitan network access point.

Circuit emulation can also be used within the enterprise to reduce operating costs. When an organization has a head office and remote locations connected by a packet network, they could replace the telephone links between the sites by “circuit emulating” the voice services across the packet network connection. The limitation of this toll bypass application is that the voice quality may degrade unless there is adequate quality of service over the packet network. Where an external service provider is operating the packet network, a higher-grade service level agreement may need to be negotiated.

CESoP also has an application in the wireless domain. When a cellular phone operator is leasing a T1/E1 circuit from an incumbent wireline supplier to link the base station and radio network controller, a CES link over a packet network from an alternative service provider may be a more cost-effective alternative.

A Standardized Approach
The ATM Forum standardized circuit emulation in the mid-1990s for the ATM world. Recently, standards organizations such as IETF, the ITU-T, Metro Ethernet Forum, and the MPLS Frame Relay Alliance have started considering circuit emulation for the packet switched world.

The main CESoP standards are being set by the IETF's Pseudo-Wire Emulation Edge to Edge (PWE3) working group which is chartered to develop methods for carrying Layer 1 and Layer 2 technologies across an IP or MPLS packet switched network. The Metro Ethernet Forum is considering extending the work of the PWE3 group to make it applicable to a metropolitan Ethernet context. Similarly, the MPLS Frame Relay Alliance and the ITU-T (Study Group 13 Question 5) are also looking at the same standards for MPLS networks.

About the Author
Tim Frost is a system architect with Zarlink Semiconductor, responsible for technical definition of the voice-over-packet product line. He is the editor of the Metro Ethernet Forum's Circuit Emulation work item, as well as a contributing author to three Internet Drafts in the circuit emulation area. Tim can be contacted at .

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.