Voice over an
IP-based network was once a novelty, suited only for those willing to
endure poor voice quality in exchange for a few dollars in savings. Today,
reality has finally caught up to the hype.
Businesses are
increasingly migrating circuit-switched voice services to their data
networks to realize communications as well network infrastructure and
maintenance savings. Service providers are now announcing significant
investments in IP telephony.
One of the most
common technologies used to transport voice over packet is Voice over IP
(VoIP). However, it is not the only solution. Circuit Emulation Services
over Packet (CESoP) takes a fundamentally different and less complex
approach to transport voice and circuit-switched traffic over packet-based
networks, while at the same time supporting a broader range of
applications than VoIP
CIRCUIT TO
PACKET
Adopting the same approach
as circuit emulation for ATM -- now a widely deployed technique -- CESoP
provides a transparent mechanism to trunk circuit-switched services across
a packet network. TDM circuit traffic, including both the data and
signaling, is packetized as either unstructured leased-line data or
structured Nx64 Kbps voice channels. These packets are then transported
across an Ethernet, IP or MPLS packet network. At the far-end the ingress
packets are smoothed using a receive jitter buffer, TDM circuits are then
extracted from the packets and played out onto the TDM interface.
In contrast, VoIP relies on comparatively older
technology to transport TDM voice channels across the IP network, using
gateways to terminate PSTN (public switched telephone network) signaling
and voice traffic. The gateway then individually negotiates a
single-channel connection across the IP network, while at the far end
another gateway converts the voice packets back to TDM.
Figure 1: Circuit Emulation Across
A Packet Switched Network

KEEP IT SIMPLE
The efficiency of the two solutions can be compared based on the
required software and hardware to support the VoIP or CESoP interworking
function (IWF). A generic IWF
includes three main functions:
Voice Processing: Includes echo
cancellation, compression, tone detection and generation, as well as voice
activity detection (VAD) and comfort noise generation (CNG) for silence
detection and suppression.
Packet Processing: Consists of
conversion between TDM and packets (packetization), implementing the
packet network protocol stack, providing a jitter buffer to compensate for
packet delay variation and clock recovery.
Control and signaling: Includes
telephony functions, such as channel associated signaling (CAS) and common
channel signaling (CCS), and packet network call control, such as H.323
and SIP.
A generic VoIP solution demands all three functions,
whereas a CESoP solution simplifies the complexity of the solution by
eliminating voice processing requirements. Moreover, call control and
signaling demands are greatly reduced in a CESoP solution.
A VoIP solution terminates the PSTN signaling at each
IWF and performs the equivalent call control setup between the two IWFs,
involving a complete signaling stack between two IWFs or gateways using
control protocols such as H.323 or SIP.
In comparison, a CESoP solution generally does not
terminate the PSTN signaling, but instead “tunnels” the CAS or CCS
transparently through the packet switched network. The PSTN call control
is still performed in the existing TDM equipment boxes, and no additional
complex stacks are required between the CESoP IWFs. A CESoP connection is
not visible to, and does not interfere with, the PSTN signaling.
A VoIP solution will typically perform compression to
minimize packet network bandwidth. Rather than compress voice traffic,
with CESoP, bandwidth savings are achieved through trunking multiple TDM
channels in a single packet connection. VoIP may also implement VAD/CNG
for silence detection and suppression, whereas a CESoP solution does not
need to implement these bandwidth-saving mechanisms.
A VoIP solution also requires voice echo
cancellation. A CESoP solution, with its low packetization delay, does not
necessarily require echo cancellation when the end-to-end delays are kept
under the 25 millisecond (ms) mark, as specified in ITU-T G.131
"Control of Talker Echo."
Figure 2:
Comparing The Interworking Function Between CESoP And VoIP
MAINTAINING VOICE QUALITY
The success of any circuit-over-packet solution relies primarily on
the ability to provide voice services of the same quality and reliability
as a traditionally delivered service. Along with the usual quality
concerns caused by delay, compression and echo, an IP-based network also
introduces factors such as packet loss and jitter buffer slips.
The most significant quality factor is the delay
penalty incurred from packetizing the voice channels. The VoIP solution
traditionally implements one channel per connection with a packetization
size between 10 ms and 40 ms. A CESoP solution implements multiple
channels per connection with a packetization size of only 125 microseconds
to one ms.
Given the goal of meeting a one-way latency under 25
ms to avoid the use of echo cancellers as per G.131, or under 150 ms to
provide high-quality voice service as per ITU-T G.114 "One-Way
Transmission Time," the CESoP solution introduces significantly less
delay than the VoIP solution.
Another issue is that with VoIP, timing
synchronization is usually not treated as critical, resulting in jitter
buffer slips that may yield "clicking" sounds. Timing
synchronization in a CESoP solution, because it is also targeted to
support data, is critical. A CESoP solution will utilize either adaptive
or differential clock recovery to ensure the TDM circuits remain
synchronized with no buffer slips.
CONSIDER THE PACKET NETWORK
While a VoIP solution is targeted to use IP as the layer 3 protocol, a
CESoP solution runs equally well over
an IP, MPLS or Ethernet network, with the unmatched flexibility to support
voice, fax, modem and data over IP or MPLS.
A VoIP solution
is best suited for a bandwidth-limited environment where compression and
VAD/CNG is required to keep the packet bandwidth to an absolute minimum. A
CESoP solution achieves bandwidth reduction through the use of Nx64
trunking. Compared to multiple G.729 eight Kbps VoIP connections, a
CESoP connection providing G.711 Nx64 channel trunking can achieve
equivalent or superior bandwidth savings.
Since it places little restriction on the quality of
the network, a VoIP solution may be implemented in a managed or unmanaged
network -- even the Internet -- but allows for no voice quality
guarantees. A CESoP solution requires a managed packet network to ensure a
performance level that is adequate for either data or voice traffic that
may be present on the emulated TDM circuit.
MINIMIZE COST
A CESoP solution costs less to implement than VoIP; consider such
factors as developing an IWF and the migration of existing TDM-based
equipment. For CESoP IWF development, eliminating voice processing
functions reduces hardware requirements and licensing royalties. Signaling
transparency to CAS and CCS with CESoP reduces the amount of software
signaling stacks required for the IWF when compared with a VoIP solution,
which utilizes H.323 and SIP call control.
For the end customer with a considerable network
investment, this same transparency allows continued use of existing
TDM-based equipment. CESoP delivers the true add-on functionality needed
to migrate the TDM traffic across a packet network, without requiring
replacement or a substantial upgrade of existing TDM-based equipment.
Both CESoP and VoIP are capable solutions
aimed at exploiting packet switched networks to carry voice and
circuit-switched traffic. However, CESoP is easier to implement, supports
a wider variety of applications across any managed network, and guarantees
the voice quality necessary to ensure indistinguishable services for end
users.
Peter Meyer is a member of the Applications
Engineering Department supporting packet processors, with Zarlink
Semiconductor. For more information on CESoP, visit http://cesop.zarlink.com/
Respond to this article in our forums! |