|
For service providers and enterprises alike, the
potential for lowered costs and improved business
functionality is a strong reason to deploy VoIP.
However, there are a number of quality, reliability,
network infrastructure, and bandwidth-related issues
that must be thoroughly assessed to ensure an efficient
and successful VoIP deployment.
It is essential to utilize the appropriate tools and
methodologies to test for network readiness before
deployment of VoIP applications for two key reasons:
First, to make sure that voice quality for newly
deployed VoIP is acceptable; and second, to make sure
the network can support VoIP calls with no performance
degradation of other data applications already in use.
TEST CONSIDERATIONS
Every VoIP call needs the support of signaling protocols
for call setup and teardown, dial tone, and the like. To
initiate a call, a VoIP end-point goes off hook and
informs a gateway or a gatekeeper about the new call,
obtains a dial tone and dials the destination number.
Once a call has been established, the VoIP gear at the
two end-points of the conversation negotiates the
parameters, such as the codec, to be used during the
conversation. During the conversation itself, voice is
sampled at a constant rate, and the sampled bits are
packed in RTP (real-time transport) packets that are
then sent over the IP network using UDP (User Datagram
Protocol). It is essential to test each segment of the
VoIP call process to adequately assess the network
readiness for the new application.
Testing the signaling portion of a call involves the
measurement of the time it takes to establish a new
call, the rate at which new calls can be generated, and
the success ratio of completed calls. Testing the packet
transmission portion of the call involves the
measurement of key parameters such as latency, jitter,
and loss that affect the quality of the voice call.
Latency
Call packet latency is a major consideration in
implementing VoIP. With VoIP traffic, a packet that
arrives late might as well have not been transmitted at
all. Retransmissions are of no value (hence the use of
UDP), since VoIP is real-time traffic. If the delays in
voice packet delivery are too long, speech is not
recognizable. Several factors contribute to the delay in
VoIP networking. These include the generation and
compression of the voice packet, the propagation delay,
the transmission delay, and the queuing delay in the
network. Typically, people can tolerate delays from one
end to another of no more than 200 milliseconds. The
conversation becomes annoying with larger delays, and in
the range of 400 milliseconds and up, becomes
impractical.
Jitter
Another important consideration is the packet jitter
that reflects the variations in latencies of VoIP
packets. In VoIP, packets are transmitted at a constant
spacing, but due to the nature of IP networks, packets
do not necessarily arrive at the destination in constant
spacing, yielding packet jitter. Network components, and
more profoundly, the gateway itself, compensate for
jitter with the use of buffers that store incoming
packets and send them in a more constant stream. The
size of a jitter buffer affects both jitter and latency.
Increasing the jitter buffer reduces the jitter, but
does so at the expense of increasing the latency.
Loss
Yet another consideration in testing VoIP transmission
is measurement of packet loss. When more than 0.25
percent of the packets on a VoIP connection are lost,
users will notice degradation in the voice quality. The
pattern of the lost packets is also important. Packets
that are lost in bursts degrade voice quality more than
packets that are lost sporadically.
It is important to test the existing network
infrastructure to make sure all network components can
support VoIP along with data, and meet the acceptance
criteria set for jitter, latency, and delay. Testing
should be extended to any new equipment being introduced
into the existing infrastructure to enable VoIP
applications, to ensure interoperability and performance
requirements are met.
TESTING FOR VoIP SUCCESS
Testing for network readiness for VoIP is no small
undertaking. A key goal is to test as comprehensively
and as thoroughly as possible, with a minimum of time
and resource usage.
A recommended option is to use a centrally
controlled, distributed software test system that can
emulate simultaneous VoIP calls from different segments
of the network, and carry the required measurements
without the need for actual VoIP deployment.
Distributed testing platforms allow measurements of
the key variables that affect VoIP quality, i.e., delay,
jitter, and loss, by installing traffic agents that are
capable of generating voice calls at the segments of
interest in the network. Typically, a single test
between several end locations will measure all three
variables. The generated traffic can reflect the output
of one of many codecs (e.g., G.711, G.729a, G.729b
etc.). One should start with the generation of a single
call between end locations and measure the delay,
jitter, and loss. The jitter will give an indication on
how to configure the jitter buffer. Too many losses, or
too large a delay, indicate that the links used either
do not have enough bandwidth to carry a voice call, or
are too loaded. In that case, one can try to identify
the bottlenecks and allocate bandwidth specifically for
VoIP traffic using some QoS mechanisms. If a single
voice call can be carried, then the number of calls
between various end locations should be increased, as
long as the measured variables are below a set
threshold. Thus one can determine how many simultaneous
voice calls can be carried in the network.
A distributed test system can also be used to run
tests to ensure successful integration of new network
components into an existing homogeneous network. Tests
can be run to emulate the process of dialing from one
point to another, with traffic agents acting as IP
phones, to prove out integration.
TESTING VoIP IMPACT ON OTHER APPS
VoIP deployment may negatively impact other data
applications in the network. One reason is the low
efficiency of VoIP traffic. RTP packets that contain the
sampled voice have 12-byte headers. They ride on top of
UDP packets, which in turn carry 8-byte headers. These
are mounted on top of IP packets, having 20-byte
headers. This brings the total packet overhead to 40
bytes (14 more bytes are necessary for the Ethernet
header when packets are transmitted over an Ethernet).
When packetizing G.729 calls, the payload size comes up
to 20 bytes every 20 millisecond (8Kbits/sec). Adding up
the 40 bytes overhead implies that each VoIP call needs
about 24Kbits/sec. The key issue related to this
detailed description of packet header breakdowns
translates to how little bandwidth may remain for the
useful payload. VoIP applications may therefore have
higher bandwidth requirements than initially
anticipated. Checking the resulting impact on other
networked applications is very important.
VoIP traffic can adversely affect existing
applications such as file transfer, Web browsing,
database transactions, and such. Therefore, tests of the
performance of these applications from various segments
of the network must also be conducted. First, such tests
are carried with no VoIP traffic to establish a baseline
for such data points as response time. Then, the same
tests are carried while VoIP traffic is generated, and
the application response time is measured again to see
how much it was deteriorated, if at all.
Test systems should be capable of testing key data
applications in this type of manner, so the impact of
VoIP on these applications can be assessed before
VoIP deployment to protect against degradation to the
existing applications on the network.
CRITICAL ARCHITECTURE
It is critical that network architect teams carry out
the due diligence of thoroughly assessing all test
requirements unique to their existing network
architecture, systems, and designated traffic and
quality needs, and then determine the best
resource-effective tools and methodologies for
conducting these tests. A well-thought out and executed
test plan to ensure VoIP readiness makes all the
difference in ensuring a successful VoIP deployment.
Moshe Sidi is chief scientist at Omegon
Networks, Ltd. Omegon is a global provider of active
network diagnostic and testing software. The company
provides enterprises, service providers, and
e-businesses with a framework for comprehensive
real-time active network testing and diagnostic
capabilities that encompass fault and performance
management, real time troubleshooting, service level
management (SLM) and auditing, policy management, and
quality of service (QoS) auditing.
[ Return
To The September 2001 Table Of Contents ]
|
|
Staying
Ahead Of The VoIP Growth Curve
BY ANIL UBEROI
Genuity is an
Internet infrastructure services provider with a 17,700
mile Tier-1 Global Network Infrastructure (GNI). With
the GNI, Genuity deployed one of the world's largest
Voice-over-IP (VoIP) networks. Prior to launching its
first wholesale VoIP service in 1999, Genuity needed to
develop a scalable billing solution. The company needed
a system that could both accurately measure VoIP
customer traffic on the network, and scale to meet rapid
growth in demand for services. Originally, Genuity
planned for a strong growth of VoIP calls per day, but
quickly ramped to several times its projected minutes
per day. The billing solution needed to provide the same
level of scalability that the underlying infrastructure
delivered.
THE PROBLEM OF COMPLEXITY
Genuity upgraded to a carrier-grade billing system to
handle the increased traffic, but that was just the
start. Billing systems for circuit-switched networks
create bills based on Call Data Records (CDRs) that
include a number of parameters (such as the time a voice
circuit is activated and closed) that typically come
from a single location. IP networks are far more complex
than circuit-switched networks, and the parameters
needed to create CDRs are found in different pieces of
equipment, such as authentication servers and routers,
that are scattered throughout the network. Plus, because
VoIP traffic is mixed with other IP traffic, it is far
more difficult to extract the parameters. Genuity needed
to be able to look into its IP backbone and
simultaneously track every individual VoIP session
across all network devices.
To extract IP data from its large network of routers
and VoIP gateways, Genuity turned to XACCT
Technologies and their Network-to-Business (N2B)
platform, an intelligent business infrastructure
solution for IP networks. The N2B platform collects data
from all layers of Genuity's network, from the physical
layer up through the session and transaction layers, to
the application layer, in real time.
A MULTILAYERED ARCHITECTURE
For Genuity's billing application, specialized
Information Source Modules (ISMs; the lowest layer of
XACCT's multilayered architecture) collect Remote
Authentication Dial-In User Service (RADIUS) accounting
data from the gateways. ISMs also collect call history
tables from the gateways' Management Information Base (MIB).
Another type of ISM merges all information from the
RADIUS and MIB ISMs. The merged record is enhanced by an
IP Range Matching ISM to create gateway cluster names.
COLLECTING, GATHERING, AGGREGATING
All of this raw billing data is forwarded to N2B
elements (called Gatherers) that run on powerful
workstations and can process millions of IP sessions in
a single day. Gatherers filter, aggregate, enhance, and
synthesize the data into individual usage records. For
security reasons and to avoid inaccurate bills, Genuity
uses two Gatherers, running on two separate
workstations, to collect VoIP data from each gateway and
then merges these records with the help of the Gatherer
that runs the VoIP Merger ISM. This Gatherer runs on a
third machine, getting a direct feed off the
call-originating and call-receiving gateways.
Multiple Gatherers in turn feed their records into a
larger aggregation system called the Central Event
Manager (CEM), which produces XACCT Data Records (XDRs),
the IP equivalent of CDRs. Genuity can either feed the
XDRs directly into its existing billing infrastructure,
or store them in the XACCT central database. Genuity now
knows who is making VoIP calls on its network, where
they are located, and how long the calls last.
SIMPLE & SCALABLE
XACCT's N2B platform fulfilled the requirement of
collecting accurate VoIP call information. But could it
scale to handle Genuity's rapidly growing volume of VoIP
calls? When Genuity started its VoIP service, it was
logging significant call minutes each day, or 0.533
calls per second per gateway. Soon volume was up, and
within a few months increased by more than ten-fold.
Today, Genuity is completely equipped to handle the
exploding popularity of its two flagship VoIP products,
Global VoIP Direct and ESP Direct. Its business
infrastructure platform empowers the company to support
the rapidly expanding needs of its wholesale VoIP
telephony customers, including carriers, Internet
telephony service providers, enhanced service providers,
and telecommunications companies.
Because Genuity is precisely aware of how its network
is used, it is able to maintain its competitive edge in
a challenging business environment. And Genuity knows
that it can remain competitive with a business
infrastructure that can scale to handle rapid growth in
VoIP traffic.
Anil Uberoi is senior vice president of marketing
and business development for XACCT
Technologies.
[ Return
To The September 2001 Table Of Contents ]
|
SUBSCRIPTIONS
TMCnet LOGIN
WEBINARS
