Content uploaded by Iraj Saniee
Author content
All content in this area was uploaded by Iraj Saniee on Feb 02, 2019
Content may be subject to copyright.
◆
Intelligent Media Gateway Selection
in Carrier-Grade VoIP Networks
Adiseshu Hari, Volker Hilt, Markus Hofmann, Debasis Mitra,
Iraj Saniee, Anwar Walid, and Indra Widjaja
Service providers face new challenges in designing and managing voice
over IP (VoIP) networks with the quality, reliability, and scalability that
have been the hallmark of conventional circuit-switched telephony.
As carriers evolve their networks, these challenges come to the fore in
the inter-networking of the emerging VoIP network segment with the
public switched telephone network (PSTN). In this paper, we propose a
measurement infrastructure and admission and routing algorithms for
efficient and reliable operation of carrier-grade hybrid VoIP and PSTN
networks. © 2006 Lucent Technologies Inc.
telephone network (PSTN) segment assumes a signif-
icant role. In this paper, we describe mechanisms for
efficient, reliable, and scalable operation of hybrid
VoIP and circuit-switched networks. Specifically,
we make use of the emerging IP Multimedia Sub-
system (IMS) architecture to enable admission con-
trol, routing, and quality of service (QoS) assurance
for VoIP-to-PSTN interoperation.
The IMS Architecture
An emerging reference model for VoIP network
architecture that is gaining wide acceptance among
service providers is the IMS [1], which is being de-
veloped and standardized by the 3rd Generation
Partnership Project (3GPP) [2] and 3rd Generation
Partnership Project 2 (3GPP2) [3] organizations. The
IMS model defines a core network architecture based
on the Session Initiation Protocol (SIP) [3, 11]. Access
networks connect to the core network using stan-
dardized interfaces. Thus, the core network is inde-
pendent of the type of access network used to connect
Introduction
Voice over IP (VoIP) promises service provider
(SPs) significant savings in capital and operational
costs through convergence with data services. How-
ever, SPs face new challenges in designing VoIP
networks with the quality, reliability, security, and
scalability that have been the hallmark of conven-
tional carrier-grade circuit-switched telephony. While
it is relatively simple to create basic VoIP networks
using the public Internet and off-the-shelf VoIP clients
and servers, implementing carrier-grade VoIP poses
new requirements at different layers of the network.
For example, a carrier-grade VoIP network must
provide mechanisms to handle user authentication
(in the session layer), to prioritize and efficiently
schedule voice packets to meet QoS delay require-
ments in a bursty traffic environment (in the data
layer), and to respond dynamically to network
outages (in the control layer) in the presence of mul-
tivendor components and heterogeneous access tech-
nologies. As carriers begin to evolve their networks
toward VoIP, interfacing VoIP with the public switched
Bell Labs Technical Journal 10(4), 133–150 (2006) © 2006 Lucent Technologies Inc. • DOI: 10.1002/bltj.20130
134 Bell Labs Technical Journal DOI: 10.1002/bltj
Panel 1. Abbreviations, Acronyms, and Terms
3GPP—3rd Generation Partnership Project
3GPP2—3rd Generation Partnership Project 2
API—Application programming interface
AS—Application server
BGCF—Breakout gateway control function
CSCF—Call session control function
DSL—Digital subscriber line
ENUM—Telephone Number Mapping Working
Group
HLR—Home location register
HSS—Home subscriber server
I-CSCF—Interrogating CSCF
IMS—IP Multimedia Subsystem
IN—Intelligent network
IP—Internet Protocol
IPTEL—IP telephony
ISDN—Integrated services digital network
ISUP—ISDN User Part
ITU-T—International Telecommunication
Union-Telecommunication Standardization
Sector
IXC—Interexchange carrier
MGCF—Media gateway control function
MG—Media gateway
MPLS—Multiprotocol Label Switching
MSC—Mobile switching center
NIST—National Institute of Standards and
Technology
LATA—Local access and transport area
LNP—Local number portability
PPP—Point-to-Point Protocol
PSTN—Public switched telephone network
QoS—Quality of service
RFC—Request for comments
RTCP—Real-Time Transport Control Protocol
RTP—Real-Time Transport Protocol
S-CSCF—Serving CSCF
SIP—Session Initiation Protocol
SLA—Service level agreement
SNMP—Simple Network Management
Protocol
TDM—Time division multiplexing
TLDN—Temporary local directory number
TRIP—Telephony routing over IP
UDP—User Datagram Protocol
URI—Uniform resource identifier
VoIP—Voice over IP
Wi-FI*—Wireless Fidelity
WLPN—Wireless LPN
WNP—Wireless number portability
to it and provides the foundation for seamless com-
munications across heterogeneous access technolo-
gies (e.g., Ethernet, cable, digital subscriber line [DSL],
third-generation [3G] cellular, and Wireless Fidelity
[Wi-Fi*]).
It is expected that there will be a gradual migra-
tion from PSTN to VoIP networks; therefore, the IMS
architecture facilitates this integration using a key
PSTN-VoIP interface component called the break-
out gateway control function (BGCF), as shown in
Figure 1. The functionality of the BGCF and other
IMS components is explained in greater detail in the
next section. A key function of the BGCF is to deter-
mine how best to route a VoIP call through the PSTN.
In the IMS architecture, the BGCF receives all VoIP
calls destined to the PSTN. It selects a suitable media
gateway control function (MGCF) for each call. The
MGCF in turn selects a suitable media gateway (MG)
for the call from the set of MGs under its control.
Thus, it can be seen that gateway selection algorithms
can be easily embedded in the MGCF. In this paper,
we adopt an approach in which the MG selection
function is embedded in the BGCF. As argued in [5],
this approach allows for better gateway selection, be-
cause the BGCF is able to select across all gateways in
the network, while the MGCF is able to select only
from those gateways under its control. When each
MG is associated with a single MGCF, the BGCF is
effectively doing MG selection under the existing IMS
standards. When multiple MGs are under the control
of a single MGCF, we associate a logical MGCF with
each MG, as in [5]. As a result, it is possible to do
gateway selection at the BGCF.
Smart BGCF
A carrier-grade VoIP network must provide high-
quality connectivity to the PSTN. Criteria for gate-
way selection include minimizing monetary costs,
DOI: 10.1002/bltj Bell Labs Technical Journal 135
maximizing revenue, and selecting the highest qual-
ity paths. Conventional BGCF implementations rely
on static routing tables to determine the appropriate
gateway for each call. Static routing tables may be en-
hanced with policy information regarding preferred
gateways for a given destination. While this approach
can serve to prune the candidate list of MGs for a
given call, it does not take into account the current
state of the network and cannot provide the highest
quality paths, because static routing tables ignore
dynamic load conditions and bursty traffic in the net-
work. Thus, there is considerable scope for improving
the quality of a session by using intelligent algorithms
that take link states and load information into account.
This is particularly important when the network is
designed to handle heavy call-traffic volumes. These
algorithms should maximize call volume subject
to QoS by using the least-loaded routes and gateways.
In this paper, we present such algorithms and use
simulations to benchmark their performance under a
variety of networking and load scenarios. We also
describe a testbed that has been set up to experiment
with both static and dynamic BGCF routing imple-
mentations. We refer to a BGCF that incorporates
intelligent algorithms as a smart BGCF.
Organization of Paper
This paper is organized as follows. The next
section describes the smart BGCF design and shows
how it is incorporated in the IMS architecture. The
following section describes detailed simulation exper-
iments that were carried out to quantify the per-
formance improvements provided by the smart BGCF.
The subsequent sections describe the implementation
architecture of the smart BGCF and an experimental
testbed. Finally, the concluding section provides a
summary of our observations on the smart BGCF and
directions for future work.
I-CSCF
S-CSCF
MGCF
BGCF
HSS
AS
IMS network
PSTN
Switch
PSTN
signaling
Signaling
Bearer
AS—Application server
BGCF—Breakout gateway control function
HSS—Home subscriber server
I-CSCF—Interrogating call session control function
IMS—IP Multimedia Subsystem
IP—Internet Protocol
MGCF—Media gateway control function
MGW—Media gateway
PSTN—Public switched telephone network
S-CSCF—Serving call session control function
MGW
Figure 1.
IMS network architecture.
136 Bell Labs Technical Journal DOI: 10.1002/bltj
Smart BGCF and the IMS Core Network
The main building blocks of the core network are
shown in Figure 1. The interrogating call session con-
trol function (I-CSCF) is the logical interface respon-
sible for interfacing with entities external to the core
network, such as the access networks and other core
networks. It is responsible for directing incoming call
requests to the appropriate serving call session control
function (S-CSCF). The S-CSCF is the call routing
engine responsible for determining the appropriate
VoIP endpoint for any incoming request. To help
with the routing decision, the S-CSCF can consult
network databases such as ENUM [4] or application
servers. The databases needed by the IMS network
for user information and location are stored in the
home subscriber server (HSS) entity. It is possible
to modify call routing and provide advanced services
by hooking application servers into the S-CSCF so
that one or more application servers are consulted for
each call.
It may happen that a call is destined to a PSTN
endpoint rather than to a VoIP endpoint. In such a
case, the call is handed from the S-CSCF to the BGCF,
which is the call routing engine for calls destined to
the PSTN. The BGCF determines an appropriate MG
to terminate the call and hands the call over to the
MGCF responsible for the MG. The MGCF provides
the signaling interworking between the SIP proto-
col used by the IMS network and protocols like ISDN
User Part (ISUP) used by the PSTN network and is
used to control the MG. The MG provides the
bearer-path connectivity between the Real-Time
Transport Protocol (RTP) bearer stream from the
VoIP endpoint and the time division multiplex (TDM)
bearer from the PSTN. It is important to note that
the CSCFs, the BGCF, and the MGCF are only sig-
naling entities and do not take part in any bearer
traffic, while the MG deals only with the bearer traf-
fic and is not concerned with the signaling within
the IMS domain.
Measurements
We use the term ingress router to refer to the access
router through which the bearer data of a call en-
ters the IMS network. Since the IMS network is access
independent, the VoIP call can enter the IMS network
through any type of access network (e.g., cable, DSL,
and Wi-Fi). Because our focus is purely on path
selection within the IMS network, we abstract the
details of the various access networks and technolo-
gies and simply focus on the path selection between
an ingress router and the egress point, which is an
MG in our case. In the static implementation of BGCF,
each ingress router is associated with a set of MGs.
Typically, selection of the MGs on this list is performed
sequentially until a gateway with available capacity is
found, and the call is routed to it. If there is no gate-
way on the list with sufficient capacity, the call is
blocked. This approach is readily seen to work well
as long as the network does not experience large load
conditions. However, in large load conditions, the pre-
selected set of gateways for a given ingress router
may be precisely those that are experiencing large
loads. This means that all calls from that ingress router
will be blocked under the static regime. However,
this need not be the case if other gateways with avail-
able capacity can be made available. Alternatively, the
load condition in the network and available gateway
capacities can be effectively used to implement a
dynamic gateway selection procedure.
In the sections “Implementation Architecture”
and “Experimental Testbed” we shall quantify the
benefits of such a scheme compared to the static
procedure. However, it is important to understand
what additional gateway or network state is required
to perform such a dynamic protocol. These additional
measurements enhance BGCF routing at a rela-
tively small cost. For example, path-delay measure-
ments to a super set of candidate gateways for each
ingress router can be obtained either at pre-specified
frequency or measured prior to a call processing
request. Such path-delay measurements may be
obtained through path probing or from the network
management system. In the former case, either active
probing or RTP data at the gateway may be used
with arbitrary update frequency. In the latter case,
Simple Network Management Protocol (SNMP)
measurements may be readily collected from the
individual elements, but with limited frequency
updates.
DOI: 10.1002/bltj Bell Labs Technical Journal 137
Modeling Approach
In this section, we present the modeling approach
used to obtain performance measures of interest
under different gateway-selection algorithms. In par-
ticular, we quantify the gain due to smart BGCF com-
pared to static BGCF in typical networks through
simulation. To simplify the exposition, we focus on
the case where calls between the SIP user agents
(UAs) and MGs are routed through a single IMS core
network. However, our methodology can easily be
extended to cases in which calls from UAs traverse
multiple IMS domains before reaching a PSTN.
Network Model
The IMS core network implementing Internet
Protocol (IP)/Multiprotocol Label Switching (MPLS) is
described as a graph G(N, L), where Nis the set of
nodes and Lis the set of links with given capacities Cl
and propagation delays pl,lHL. Each node nHNis
either a router or an MG. Some of the routers also
serve as ingress routers, which collect traffic from UAs,
while other routers act solely as intermediate routers,
on which there is no exogenous VoIP traffic. We
assume that a call from an ingress router (also referred
to as a source node) to a particular PSTN geographic
area must be routed through an MG (destination
node) that is directly connected to that geographic
area. It is possible that multiple MGs may be con-
nected to a single PSTN geographic area. In such a
case, it is convenient to extend Gto G(N,L) by
creating additional nodes representing the geographic
areas (the destination nodes) and additional links
(with zero propagation delay and infinite capacity)
representing the connections between the MGs and
their corresponding geographic areas. It is important
to note that, once a destination IP address has been
selected, the path through the IMS network follows
some predetermined, static route (e.g., the shortest
path) and cannot be controlled by a BGCF. Hence,
multiple paths between a source and a destination
exist because of the presence of multiple interfaces
(with multiple IP addresses) on the MG or of multiple
MGs connected to a single PSTN geographic area. To
have a BGCF with broad applicability, we assume that
the network topology need not be visible to the BGCF
(e.g., the IP transport layer belongs to one organiza-
tion, while the SIP-based call control layer belongs to
another).
Traffic Model
We assume that VoIP calls in the IMS network
arrive at ingress routers and are to be routed to the
appropriate MGs (or MG interfaces) by the BGCF. Calls
that originate in the PSTN do not invoke the BGCF and
thus are not accounted for in our study. The traffic
model consists of a source-destination call load matrix,
in which a source represents an ingress router and
a destination represents a PSTN geographic area.
The call process is described by its call inter-arrival
time and holding time distributions. Once a call has
been accepted, its packet process is described by its
packet inter-arrival time and packet transmission time
distributions.
Objectives
In general, a smart BGCF may select the “best”
gateway based on many criteria (e.g., minimum mon-
etary cost, highest quality path, and largest total
revenue). In this paper, we focus on call blocking
probability as an important metric to compare various
gateway selection algorithms. Unfortunately, using
only call blocking does not reflect the overall service
received by end users, because an accepted call may
not meet its QoS. For this reason, we also use the
probability that an accepted call is “bad” (i.e., does
not meet its QoS) as another metric. In this paper, we
separate the function of routing from that of call
admission to allow for distinct call admission algo-
rithms independent of the criterion for the selection of
gateways.
Measurement
The QoS of a VoIP call can be subjectively char-
acterized by a quantity referred to as the mean opin-
ion score (MOS), which, in turn, can be objectively
predicted using the International Telecommunication
Union- Telecommunication Standardization Sector
(ITU-T) standardized Emodel [7]. Briefly, voice qual-
ity may be degraded by many factors, including path
delay and path loss impairments. Thus, a measure-
ment system is needed to monitor these quantities
end-to-end. In an IMS environment, the measurement
138 Bell Labs Technical Journal DOI: 10.1002/bltj
is performed between ingress routers and MGs and
generally cannot be made available to the BGCF
instantaneously. We assume that the BGCF has access
to the measurement information every Tseconds.
Specifically, we assume that a fresh path mean delay
matrix Q(t) is available to the BGCF at time t0,
T, 2T, . . . . We assume the use of round-trip rather
than one-way delay throughout this paper, because it
is more commonly used; however, our approach is
completely applicable when one-way delay is used
instead. A call is said to meet its QoS if and only if its
path delay is below a given threshold uduring the call,
where uis the delay budget allocated in an IMS core
network.
Call Admission Control
A BGCF may choose to accept a VoIP call if there
is an available circuit for the new call at the MG.
In this case, however, an accepted call may not
meet its QoS if the IMS network itself is congested.
Alternatively, a BGCF may decide to accept a call
only if a circuit is available and the presumed QoS
along the path is deemed acceptable. Even though
the presumed QoS of a call is deemed acceptable at
admission, the actual QoS may be unsatisfactory,
because the presumed QoS may be based on meas-
urement information that is obsolete. Furthermore,
even if the actual QoS is acceptable at admission, it
may degrade during mid-call due to path interfer-
ence with other new calls, because call admission
does not reserve any per-call bandwidth in an IMS
network.
Gateway-Selection and Routing Algorithms
There are several possible BGCF gateway-selection
(or routing) algorithms that can be implemented in an
IMS network core. For each new call with a given
source-destination pair, we consider the following
algorithms:
•Static: Selects a static route based on, for example,
the shortest path.
•Equalized delay (ED): Selects a route that has the
least mean path delay, with the objective of de-
terministically equalizing delays on the routes
of the same source-destination pair. Because
measurement information can be stale, the ED
algorithm typically selects the same route repeat-
edly. This strategy tends to lead to greedy behav-
ior that can cause oscillation.
•Thinning and randomization (TR): Thins the routes
by discarding those that exceed the QoS and ran-
domly chooses one from the thinned set.
•Power-of-two (P2): Randomly picks two routes from
the set of all possible routes and then selects the
one with the least delay [9].
•Equalized delay with stabilization (EDS): Improves
the ED algorithm so that path delays do not change
appreciably from one measurement update to
the next. In particular, a new call for a given
source-destination pair swith K(s) available
paths will be routed to path k(k1, 2, . . ., K(s))
with probability qk(s). At each measurement
update, qk(s)’s are adjusted, so delays among active
paths for each source-destination pair are equali-
zed in the long term. (The adjustment process is
described below.)
•Dynamic power-of-two (DP2): Combines the P2 and
EDS algorithms by employing the P2 algorithm
with probability et兾b,where tis the elapsed
time since the last measurement update and bis
a time constant; otherwise, it employs the EDS al-
gorithm. This algorithm was developed because
ED, like P2, tends to be greedy when the number
of available paths for each source-destination pair
is relatively small, which is believed to be typical
in an IMS network and because the P2 algorithm
does not take into account non-uniform charac-
teristics among multiple paths.
We now describe a method for updating the rout-
ing probabilities qk(s) at each measurement update.
Each path has two states: active when its routing prob-
ability is non-zero and inactive otherwise. All paths
are initially active. For each source-destination pair s,
first compute the mean delay E[D] among the active
paths. An inactive path Pkwill transition to the active
state if its mean delay DkkE[D], where 0 k1.
Then, update E[D] to include the delays of newly
activated paths. Next, sort the active paths in non-
decreasing order of delay {P1, P2, . . . , PK(s)}. Divide
the set into two subsets, SU{P1, P2, . . . , Pm*1} and
DOI: 10.1002/bltj Bell Labs Technical Journal 139
SO{Pm*,P
m*1, . . . , PK(s)}, consisting of those paths
that are in the underload condition and those that are
in the overload condition, respectively. Here, the par-
tition is chosen so that m* argmaxm{Dm: DmE[D]}.
For each path PiHSO,decrease its routing probability
by qidqi vi,where vimin{qi,d(Di E[D])兾E[D]},
for some suitably chosen constant d. If the resulting
routing probability qie, transition path Pito the
inactive state and adjust the following variables:
vidviqiand qid0. Let
ivi.For each path
PjHSU, increase its routing probability by qjdqj hj,
where hj(E[D] Dj)兾k(E[D] Dk)). Because
of possible round-off errors in the above computa-
tion, it is important to check the result and make
any adjustment necessary to ensure that kqk(s) 1,
for all s.
Simulation and Performance Results
In this section, we present the results of a BGCF
performance study and compare the various routing
algorithms previously described. In order to have a
more scalable system, we use a hybrid approach with
an analytical model to determine packet-level per-
formance and a simulation model to determine call-
level performance. This approach allows us to reduce
the number of events to be scheduled in the simula-
tor by a factor of 10,000 (roughly the average number
of packets per call).
For the packet-level performance, we compute
the queuing delay d(l) on each link lHL. We assume
that UAs use G.711 codec and that voice packets of a
given call are transmitted periodically every 20 msec.
Thus, the length of each voice packet is 206 bytes
(160 bytes for payload and 46 bytes for RTP, User
Datagram Protocol [UDP], IP and Point-to-Point
Protocol [PPP] headers). (We note that the results of
this study remain qualitatively valid for codecs other
than G. 711.) Throughout the simulation, we use an
M/D/1 formula d(l) (1 rl兾2)兾((1 rl)ml) for the
link queuing delay, where rlll兾ml,llis the total
voice-packet arrival rate and 1兾mlis the voice-packet
service time on link l. The total arrival rate can be eas-
ily obtained from the number of calls in progress. The
M/D/1 model is a good approximation of an nD/D/1
model for very large n, which is the case in our study.
We approximate finite buffer size by setting the delay
to a large value when the mean queue length exceeds
a certain threshold (assumed to be 25 msec worth of
data in the simulation results reported). Using the
independence assumption, a path delay is the sum
of the link queuing and propagation delays along
the path. The output of the packet-level analysis is
the Q(t) matrix that is updated at each measurement
interval T. The link delay is computed by using the
average number of calls in progress during each
interval T. In other words, we assume a passive meas-
urement system, the output of which is collected at
the BGCF every Tseconds.
For the call-level performance, we assume that
the call arrival process is Poisson and that the call-
holding time is an independent and identically dis-
tributed (iid) exponential with a mean of 180 seconds.
A call is accepted if the designated gateway has at
least one circuit available and the path delay obtained
from the Q(t) matrix is less than u,which is set to be
50 msec. We assume that a call is always accepted
by the PSTN side to enable us to focus on the IMS
side. For a compact representation, we combine
blocked call and bad call into a single metric given
by the probability that a call is blocked or accepted
but bad and denoted by Pc.Since the simulation is at
the call level, we cannot use packet performance
throughout a call to determine whether an accepted
call violates its QoS. To this end, we monitor the in-
stantaneous mean path delay of a call at the begin-
ning of the call, at a random point in time during
the call, and at the end of the call. An accepted call is
declared bad if its QoS is violated at any of those
monitoring points.
Simple Network
We first consider a simple but realistic network
(see Figure 2) that has multiple paths due to multiple
interfaces at each gateway. For example, the paths
from nodes 1 to 13 are (1, 5, 9, 13), (1, 6, 10, 13) and
(1, 7, 11, 13). The network also includes interaction—
at the links between the core routers—among dif-
ferent source-destination pairs. In this example, we
assume that pl1 msec for each l, except that p(5,9)
2 msec, and Cl25 Mbits/sec for each l, except that
140 Bell Labs Technical Journal DOI: 10.1002/bltj
C(5,9) 30 Mbits/sec, C(6,10) 30 Mbits/sec, C(7,11)
60 Mbits/sec, and C(8,12) 60 Mbits/sec. The call load
is given by (1,13)
(2,14)
(3,15)
(4,16) 100 a
Erlangs, where ais the overall load multiplier. To
achieve a balanced allocation between packet and
TDM resources, the gateway capacity is set to 500 cir-
cuits. This balance is determined by roughly equaliz-
ing the call-blocking rates due to inadequate QoS in
the IMS network and the unavailable circuits at the
MG and by using the ED algorithm with T 0.
Figure 3 shows Pcwith respect to total offered
load (in Erlangs) for different BGCF gateway selec-
tion (i.e., routing) algorithms and different measure-
ment update intervals T. We use d0.01, k0.99,
and e0.01 for EDS and DP2, and b10 for DP2.
Our experiments indicate that the choice of bis
insensitive across a reasonably wide range of values.
Notice that static routing is extremely poor for all
update intervals, because each source-destination pair
always chooses one path (which is highly congested)
even though other paths are underused. Greedy
algorithms such as ED and P2 perform well for small
values of T, but degrade markedly for large T(e.g.,
T 100 sec or 1000 sec). This is verified (though not
shown in the results) by the oscillating behavior
of the link loading with respect to time. The TR algo-
rithm is much less sensitive to T, but never offers
satisfactory performance for any value of T, because
uniform load balancing is not effective when paths
are asymmetric. On the other hand, both EDS and
DP2 perform well over all measurement update
intervals, with DP2 clearly outperforming EDS in
almost all cases except those in which Tis very
large.
To illustrate the effectiveness of EDS, in Figure 4
we plot the routing probabilities qkfor a given
offered load as a function of update time in 4(a),
where T 10 sec. Here, Path1 (1, 5, 9, 13), Path2
(1, 5, 10, 13) and Path3 (1, 7, 11, 13). Initially, the
respective routing probabilities (q1,q2,q3)(1兾3, 1兾3,
1兾3) and new calls are uniformly distributed among
the three paths. Observe that Path1 eventually be-
comes inactive when q1becomes 0, so the traffic from
node 1 to node 13 will be distributed only through
Path2 and Path3. Further, q2q3since C(6,10) C(7,11).
In 4(b), observe that the delays become equalized
only between Path2 and Path3, demonstrating that
the algorithm eventually eliminates Path1 from con-
sideration. It is worth noting that, in general, a path
may dynamically transition from active to inactive
state and vice versa during the operation of the net-
work, especially when traffic load changes.
Regional Network
We next consider a more realistic regional net-
work (see Figure 5). We assume that pl1 msec
and Cl45 Mbits/sec for each l. We use the same
values of d,k,e,and bas before. The call load is
almost uniform from ingress routers (shaded circles)
to PSTN geographic areas (e.g., local access and trans-
port areas [LATAs]). To achieve a balanced alloca-
tion of TDM and packet resources, each gateway
capacity is set to 450 circuits. Every set of three gate-
ways (denoted by a, b, and c) belongs to a geographic
area. Thus, the objective is for the BGCF to select
the best gateway to the PSTN geographic area for
each call.
Figure 6 shows the performance results for var-
ious measurement update intervals T. Note that the
performance of TR is worse than that of static. As a re-
sult, (almost) uniform load balancing among multiple
paths may be harmful, when the path characteristics
Access
routers
Core
routers
Media
gateways
13
15
14
16
1
2
4
3
8
6
7
59
10
11
12
Figure 2.
Topology of a simple network.
DOI: 10.1002/bltj Bell Labs Technical Journal 141
are appreciably different. As can be seen, ED, P2, DP2,
and EDS perform significantly better than static or TR
for almost all values of Tup to about 100 seconds,
indicating that intelligent load balancing using some
measurement information can still be useful. For
example (although it is not shown in the results),
the gateway selection algorithm for EDS between
node 2 and area 6, which starts with uniform routing
probabilities (i.e., 1兾3, 1兾3, 1兾3), converges to routing
probabilities (0.59, 0. 0.41) when the total offered
load is 3300 Erlangs. The path delays between the
two active paths also become equalized. As expected,
ED and P2 deteriorate for very large values of T(e.g.,
T1000, as in [6d]), for the same reason as before.
However, DP2 and EDS remain essentially unaffected
even for very large T, thus demonstrating the robust-
ness of both algorithms with respect to measurement
update interval.
1
0.1
0.01
0.001
1200 1400 1600 1800
Total offered load (Erlangs)
(a)
Pr{blocked or bad call}
2000 2200
1
0.1
0.01
0.001
1200 1400 1600 1800 2000 2200
1
0.1
0.01
0.001
1200 1400 1600 1800 2000 2200
1
0.1
0.01
0.001
1200 1400 1600 1800
Total offered load (Erlangs)
(b)
Pr{blocked or bad call}
2000 2200
Total offered load (Erlangs)
(d)
Pr{blocked or bad call}
Total offered load (Erlangs)
(c)
Pr{blocked or bad call}
Static, T 1
ED, T 1
TR, T 1
P2, T 1
EDS, T 1
DP2, T 1
Static, T 100
ED, T 100
TR, T 100
P2, T 100
EDS, T 100
DP2, T 100
Static, T 1000
ED, T 1000
TR, T 1000
P2, T 1000
EDS, T 1000
DP2, T 1000
Static, T 10
ED, T 10
TR, T 10
P2, T 10
EDS, T 10
DP2, T 10
Figure 3.
Performance results with a simple network for different measurement update intervals.
142 Bell Labs Technical Journal DOI: 10.1002/bltj
Implementation Architecture
The overall implementation architecture is divided
into a smart BGCF implementation and a measurement
infrastructure implementation. The smart BGCF im-
plementation architecture, which is shown in Figure 7,
has two main components. One component is the
BGCF application shown on the right side of the fig-
ure. This is the entity responsible for processing SIP
INVITE requests from the S-CSCF, as discussed in
“Smart BGCF and the IMS Core Network.” The BGCF
application is layered on top of a SIP core that receives
SIP messages, processes SIP transactions, and provides
proxying services. Each time an INVITE request arrives,
the BGCF application is notified by the proxy layer
of the SIP core. The BGCF relies on a route database
to map incoming call requests to the appropriate MGs.
The BGCF uses the results of the route lookup to
return a target set to the SIP core. The target set consists
of an ordered list of SIP uniform resource indicators
(URIs) corresponding to the MGCFs associated with
the selected MGs. The SIP core serially forwards the
SIP INVITE message to each element in the target set
until the message is successfully accepted.
The route database provides a standard interface
module in which the measurement server modifies
the entries, the BGCF application retrieves entries,
and the provisioning interface adds entries. The meas-
urement server (shown on the left in Figure 7) con-
verts the BGCF from a conventional table-driven
BGCF to a smart BGCF. The measurement server
serves as a platform for implementing the intelligent
routing algorithms described in the previous sec-
tions. It is responsible for using the current network
0.7
0.6
0.5
0.4
0.3
0.2
0.1
00 500 1000 1500
Time
(a)
Routing probabilities
2000 2500
10
9
8
7
6
50 500 1000 1500
Time
(b)
Path delays
2000 2500
Path 1
Path 2
Path 3
Path 1
Path 2
Path 3
Figure 4.
Sample paths for the routing probabilities and the corresponding delays.
1
5
8
13c 15a
14c
16a
9
12a
17c
12c
12b
Area 3
13b
13a
14a
14b
15c
15b
16c
16b
17b
17a
3
2
Area 1
Area 2
4
Area 5
11
Area 6
7
Area 4
6
10
Figure 5.
Topology of a regional network.
DOI: 10.1002/bltj Bell Labs Technical Journal 143
measurements to modify the routing database, thereby
ensuring that the BGCF application always uses the
best MG for each call, based on current network
conditions. The measurement server is layered on top
of both an application framework that provides timer,
socket, and event loop management and an embed-
ded Web server. The Web server is used to upload
and download data, as well as to monitor and config-
ure the measurement server using authentication.
The measurement server relies on a measurement
application programming interface (API) to commu-
nicate with the network measurement infrastructure.
The measurement API is used to retrieve a path QoS
matrix that lists the current QoS of each path in the
network from each ingress node to each egress node.
Defining a common measurement API allows the
measurement server to work with different types
of measurement systems, such as HP OpenView* [6]
1
0.1
0.01
0.001
2000 2500 3000 3500
Total offered load (Erlangs)
(a)
Pr{blocked or bad call}
4000 4500
1
0.1
0.01
0.001
2000 2500 3000 3500
Total offered load (Erlangs)
(b)
Pr{blocked or bad call}
4000 4500
1
0.1
0.01
0.001
2000 2500 3000 3500
Total offered load (Erlangs)
(d)
Pr{blocked or bad call}
4000 4500
1
0.1
0.01
0.001
2000 2500 3000 3500
Total offered load (Erlangs)
(c)
Pr{blocked or bad call}
4000 4500
Static, T 1
ED, T 1
TR, T 1
P2, T 1
EDS, T 1
DP2, T 1
Static, T 100
ED, T 100
TR, T 100
P2, T 100
EDS, T 100
DP2, T 100
Static, T 1000
ED, T 1000
TR, T 1000
P2, T 1000
EDS, T 1000
DP2, T 1000
Static, T 10
ED, T 10
TR, T 10
P2, T 10
EDS, T 10
DP2, T 10
Figure 6.
Performance results with a regional network for different measurement update intervals.
144 Bell Labs Technical Journal DOI: 10.1002/bltj
and Lucent’s VitalSuite®[8] range of network man-
agement and monitoring systems. The common
measurement API supports both polled-mode and
event-driven queries of network path QoS and allows
a wide range of QoS parameters (e.g., delay, jitter,
and loss) to be retrieved from selected paths. How-
ever, for the purposes of the algorithms presented in
this paper, we need only the round-trip delay along
each path.
As a proof of concept, we have implemented
our own measurement and monitoring infrastructure
to interface with the common measurement API.
Figure 8 shows the implementation of our measure-
ment infrastructure. It consists of a two-layered sys-
tem. At the lower layer are the local aggregators. The
local aggregators are placed at each ingress point in
the network and are responsible for determining the
path QoS from that ingress point to each egress
point. The global aggregator aggregates the results of
each local collector to build up the path QoS matrix,
which is then input to the measurement server. For
example, assuming that one to three probe packets
are needed each way for each measurement, and as-
suming a processing limit of 50–150 probe packets
per second at each local aggregator, our measurement
infrastructure can support an IMS network with 500
ingress and egress points, assuming measurements
are taken every 10 seconds. It is important to note
that while the local aggregators do the measurements
periodically, the global aggregator reports the meas-
urements back to the measurement server using an
event-driven interface. In the normal case (i.e., there
is no change in the QoS of a path), no events are
reported back to the measurement server. As a result,
Route database
Routing
table
SIP API
• Contains current routing table,
reflecting call-independent
dynamic information.
• Provides local/remote access.
Transport
Transaction
Provisioning
Proxy layer Target Set
sip:+17323326432@gateway1.att.com
sip:+17323326432@gateway2.att.com
sip:+17323326432@gw.verizon.com
Timer
mgmt
Measurement server
Application framework
Socket
mgmt
Web
server
BGCF application
Measurement API
API—Application programming interface
BGCF—Breakout gateway control function
SIP—Session Initiation Protocol
Figure 7.
Smart BGCF architecture.
DOI: 10.1002/bltj Bell Labs Technical Journal 145
it is possible to monitor a large network efficiently,
with minimal overhead.
Experimental Testbed
Figure 9 shows the architecture of the BGCF test
network. The test network consists of a smart BGCF
that also serves as a CSCF for purposes of registering
SIP subscribers and receiving incoming call requests.
There are two SIP-PSTN intelligent MGs with built in
signaling support. Incoming SIP calls are sent by the
BGCF to either of the two MGs, with the selection
based on the current priority assigned to each gateway.
As shown in Figure 9, the MGs are placed behind a
network condition emulator. The network condition
emulator is used to vary the path characteristics (e.g.,
delay, jitter, and loss) of the IP path to each MG. The
network condition emulator is based on the NIST Net
package [10]. The NIST Net network emulator is a
general-purpose tool for emulating performance
dynamics in IP networks. NIST Net allows a single
Linux PC set up as a router to emulate a wide variety
of network conditions. The test network also has a
local aggregator and a global aggregator (not shown in
the figure) for measuring the path QoS matrix from the
ingress to each MG and reporting it to the measure-
ment server. The measurement server component of
Measrm.srv
PSTN GW 1 PSTN GW 2
BGCF
SIP
proxy core
Voice (RTP)
IP network
PSTN
Signaling (SIP)
Active
measrmn
Probe collector 2
Passive
measrmn
Local aggregator
API—Application programming interface
BGCF—Breakout gateway control function
GW—Gateway
IP—Internet Protocol
Routing
table
Active
measrmn
Local aggregator
Probe collector 1
Passive
measrmn
BGCF
interface
Global
aggregator
Routing
algorithms
Measurement API
PSTN—Public switched telephone network
RTP—Real-Time Transport Protocol
SIP—Session Initiation Protocol
Figure 8.
BGCF measurement infrastructure.
146 Bell Labs Technical Journal DOI: 10.1002/bltj
the smart BGCF is responsible for assigning gateway
priorities in the routing database dynamically, based
on current network conditions.
By varying the delay of the path to each MG, we
can emulate an operational network and study the
behavior of the smart BGCF in such a setup. Figure 10
graphs the behavior of the smart BGCF in such a sce-
nario. The X-axis shows the time in seconds, while
the Y-axis shows the delays of each path (as meas-
ured by the local collector) in milliseconds. There are
two different curves, labeled Path-Delay-Gateway 0 and
Path-Delay-Gateway 1, showing the delays to gateways
0 and 1, respectively, from the ingress point. As can be
seen, in the time intervals between approximately 21 s
and 50 s and approximately 210 s and 240 s, the path
to gateway 0 experienced heavy delay and jitter.
Similarly, the path to gateway 1 experienced heavy
loss and jitter in the time intervals between approxi-
mately 140 s and 210 s, and 260 s and 320 s.
The Y-axis also shows a third curve that repre-
sents the routing table modification performed by the
measurement server in response to incoming network
measurements. This curve, labeled Selected Gateway, is
either 0 or 100, depending on whether gateway 0 or
gateway 1 is the selected gateway. The selected gate-
way is the one that is assigned a higher priority in the
routing database and is, therefore, the default selec-
tion. As can be seen from the graph, the selected gate-
way is always the gateway that has the lower delay;
this ensures optimum session quality.
There are two points to note with respect to the
graph in Figure 10. The first is that there is a time dif-
ference between the increase in the current selected
path delay, as seen by the local collector, and the time
a new path is selected by the measurement server.
For example, the path to gateway 0 started experi-
encing high delays from time t 21 s onward, but the
selected gateway changed to gateway 1 only at time
t30 s. This delay of 9 seconds is caused by nature of
the polling of the measurement API. The measure-
ment server polls the global collector for the path QoS
matrix, while the global collector polls the local col-
lectors. For this experiment, both poll intervals were
fixed at 5 seconds, which gives an upper bound of
10 s for measurements to propagate from the local
collector to the global collector to the measurement
server. It is possible to decrease this delay either by
increasing the polling frequency or by using an event-
driven measurement API. Event-driven APIs are sig-
nificantly more complex than simple polling APIs and
place a greater burden on the system supplying the
information; therefore, they were not used in this
BGCF
Network
condition
emulator
(NISTnet)
SIP signaling
RTP audio
PSTN
gateway 1
PSTN
phone
SIP
phone
IP network PSTN
BGCF—Breakout gateway control function
IP—Internet Protocol
NIST—National Institute of Standards and Technology
PSTN
gateway 2
PSTN—Public switched telephone network
RTP—Real-Time Transport Protocol
SIP—Session Initiation Protocol
Figure 9.
Smart BGCF implementation setup.
DOI: 10.1002/bltj Bell Labs Technical Journal 147
implementation. This measurement delay also ex-
plains the lag between the subsequent changes in the
path delay and the selected gateway. This delay is a
network tunable parameter that the network operator
can tune to achieve the requisite level of responsive-
ness. (There is a correspondingly greater overhead for
a smaller lag.)
The second point to note is that the measurement
server incorporates hysteresis into the gateway selec-
tion in order to dampen route oscillations. A path to
an unselected gateway must have significantly better
QoS than the current path before there is a shift from
the current selected gateway to the new one. For
example, in Figure 10, it is seen that the initially se-
lected gateway was 0, which shifted to gateway 1 at
time t 30 s, when the path to gateway 0 started
experiencing high delays. However, when gateway 0
stopped experiencing high delays, starting with time
t 50 s, the selected gateway remained gateway 1,
because the difference between the delays to the two
gateways was insignificant; the difference did not
exceed the threshold required to cause the selected
gateway to revert to gateway 0.
Conclusions
In this paper, we presented an architecture and
new mechanisms for efficient and reliable operation
of carrier-grade VoIP networks between an IMS net-
work and the PSTN. In particular, we employed IMS
BGCF functionality to devise efficient admission
control and routing of VoIP calls to the PSTN. These
algorithms use light measurements to adapt dynami-
cally to the changing load conditions in the IP net-
work. Through extensive simulations, we showed that
the proposed mechanisms result in significant im-
provements in call throughput and QoS over static,
600
500
400
300
200
100
00 50 100 150
Time (in s)
Path delay (in ms), Selected gateway
200 250 300 350 400
Path delay- Gateway 0
Path delay- Gateway 1
Selected gateway
BGCF—Breakout gateway control function
Figure 10.
Performance of testbed-smart BGCF.
148 Bell Labs Technical Journal DOI: 10.1002/bltj
table-driven procedures, when the network experi-
ences high load conditions. We also described an ex-
perimental testbed for measurement infrastructure
and dynamic BGCF gate selection.
Though the focus of this study was on IP-to-PSTN
call routing, the gateway selection algorithms pre-
sented in the “Modeling Approach” section extend
naturally to efficient IP-to-IP and other multimedia
call routing. In the next phase of our effort, we will
integrate these algorithms into the testbed and extend
the study to heterogeneous codecs and multiclass
calls.
*Trademarks
HP OpenView is a trademark of the Hewlett-Packard
Company.
Linux is a trademark of Linus Torvalds.
OpenView is a registered trademark of the Hewlett-
Packard Company.
Wi-Fi is a registered trademark of the Wi-Fi Alliance.
References
[1] 3rd Generation Partnership Project, <http://
www.3gpp.org>.
[2] 3rd Generation Partnership Project 2, <http://
www.3gpp2.org>.
[3] 3rd Generation Partnership Project, “Technical
Specification, Group Services and System
Aspects,” IP Multimedia Subsystem (IMS),
Stage 2, Rel. 5, 3GPP TS 23.228, Mar. 2004,
<http://ww.3gppp.org/ftp/Specs/html-info/
23228.htm>.
[4] P. Faltstrom, “E.164 number and DNS,” IETF
RFC 2916, Sept. 2000, <http://www.ietf.org/
rfc/rfc2916.txt>.
[5] A. Hari, V. Hilt, and M. Hofmann, “Intelligent
Media Gateway Selection in a VoIP Network,”
Bell Labs Tech. J., 10:1 (2005), 47–57.
[6] HP Management Software, <http://www.
managementsoftware.hp.com>.
[7] International Telecommunication Union,
Telecommunication Standardization Sector,
“The E-Model: A Computational Model for Use
in Transmission Planning,” ITU-T Rec. G.107,
Dec. 1998, <http://www.itu.int/rec/
recommendation.asp?type=product&lang=
e&parent=T-REC-G>.
[8] Lucent Technologies Solutions and Products,
<http://www.lucent.com/solutions>.
[9] M. Mitzenmacher, “The Power of Two
Choices in Randomized Load Balancing,”
IEEE Trans. Parallel Distrib. Syst., 12:10 (2001),
1094–1104.
[10] NIST net home page, <http://www-x.antd.
nist.gov/nistnet>.
[11] J. Rosenberg, H. Schulzrinne, G. Camarillo,
A. Johnston, J. Peterson, R. Sparks, M. Handley,
and E. Schooler, “SIP: Session Initiation
Protocol,” IETF RFC 3261, June 2002,
<http://www.ietf.org/rfc/rfc3261.txt?
number=3261>.
(Manuscript approved August 2005)
ADISESHU HARI is a member of the technical staff
at Bell Labs in Holmdel, New Jersey. He
holds a B.Tech. in electrical engineering
from the Indian Institute of Technology
in Bombay, an M.E. in electrical
communication engineering from the
Indian Institute of Science in Bangalore, and a D.Sc.
in computer science from Washington University in
St. Louis. Dr. Hari is currently investigating research
issues involving PSTN-VoIP integration.
VOLKER HILT is a member of technical staff at Bell Labs
in Holmdel, New Jersey. He is currently
engaged in research projects in the area
of VoIP, including SIP, 3GPP/IMS, and
multimedia services and applications. He
holds both an M.S. in computer science
and business administration and a Ph.D. in computer
science from the University of Mannheim in Germany.
Dr. Hilt’s research interests are multimedia networks,
including signaling protocols, real-time data
transmission, and networked multimedia
applications and services.
MARKUS HOFMANN is the director of Services
Infrastructure Research at Bell Labs in
Holmdel, New Jersey. He is known for his
pioneering work on reliable multicasting
over the Internet and for defining and
shaping fundamental principles of content
networking. His work also extends into the areas of
VoIP and converged communications. He holds
M.S. and Ph.D. degrees in computer engineering from
the University of Karlsruhe in Germany. Dr. Hofmann
is the chair of the IETF Open Pluggable Edge Services
Working Group as well as the chair and an officer of
the Internet Technical Committee. He serves on the
editorial board of the Computer Communications
DOI: 10.1002/bltj Bell Labs Technical Journal 149
Journal and has served as co-chair of various
conferences and workshops, including the IEEE Global
Internet, Network Group Communication and the
Global Internet Workshop. He has been on the advisory
board of the Content Distribution Networking
conference and served as guest editor of a recent issue
of the Computer Networks Journal. Over the last
few years, he has given several invited tutorials at
conferences and graduate lectures on content
networking at different universities.
DEBASIS MITRA is vice president of Mathematical
Sciences Research at Bell Labs. He received
the Ph.D. degree in electrical engineering
from London University in the United
Kingdom and joined Bell Laboratories as
a member of technical staff. During the
fall semester of 1984 he was Visiting
McKay Professor at the University of California,
Berkeley. As head of Bell Labs’ Math Center, he
directs research in fundamental mathematics,
mathematics of networks and systems, statistics and
data mining, information and communications theory,
and industrial mathematics. His personal research
interests are currently in optical networking, IP/optical
convergence, stochastic traffic engineering, network
economics, and network revenue management.
Dr. Mitra is a member of the National Academy of
Engineering, a Bell Labs Fellow, and a Fellow of
the IEEE. He is a co-recipient of the 1998 IEEE Eric E.
Sumner Award, with the citation, “For the conception
and development of voice echo cancellers.” He is the
recipient of the 1993 Steven O. Rice Prize Paper
Award and the 1982 Guillemin-Cauer Prize Paper
Award of the IEEE. He is also the recipient of awards
from the 1995 ACM Sigmetrics/Performance
Conference, the Institution of Electrical Engineers (UK),
and the Bell System Technical Journal. He has been a
member of the editorial boards of the IEEE/ACM
Transactions on Networking, the IEEE Transactions of
Communications, the IEEE Transactions on Circuits, and
Systems and Queueing Systems (QUESTA). He is
currently the area editor of Operations Research for
Telecommunications and Networking. He serves on the
Air Force Science and Technology Board of the National
Academies. In 2003, he served as the Chair of the
Telecom review panel of the New Jersey Commission
on Jobs Growth and Economic Development and as
the Albert Winsemius Professor at the Nanyang
Technical University in Singapore. In 2005, he is a
visiting professor at the Indian Institute of Science
in Bangalore.
IRAJ SANIEE is the director of Mathematics of Networks
and Systems Research Department in the
Mathematical Sciences Research Center at
Bell Labs in Murray Hill, New Jersey. He
received his B.A. and M.A. degrees with
honors in mathematics and his Ph.D. in
operations research and control theory, all from the
University of Cambridge in the United Kingdom. At
Bell Labs, the emphasis of research in his department
has been on network design and mathematical
modeling, analysis, and optimization of emerging
processes in wireless, optical, and data networks. Recent
joint projects with Lucent product groups include new
schemes for scheduling and network routing algorithms.
His personal research interests are currently in new
modes of optical networking, randomized resource
allocation and distributed optimization. Prior to Bell
Labs he was a director in the Applied Research Area
of Bell Communications Research in Morristown, New
Jersey. Dr. Saniee is past chair of the Telecom Section
at INFORMS and a member of the IEEE and the IFIP
Working Group 7.3 on Computer Performance Modeling
and Analysis and is currently an associate editor of
Operations Research. He led the 1994 runner-up team in
the INFORMS’ Edelman International Prize in Operations
Research and has published numerous articles in the
IEEE, INFORMS, and SIAM journals and proceedings.
ANWAR WALID is a distinguished member of technical
staff in the Mathematics of Networks and
Systems Research Department of the
Mathematical Sciences Research Center at
Lucent Technologies in Murray Hill, New
Jersey. He received the B.S. degree in
electrical engineering from Polytechnic Institute of
New York in Brooklyn and the Ph.D. degree in electrical
engineering from Columbia University in New York
City. He has developed theory and algorithms for
network resource management and QoS support for
several Lucent products, and he holds several patents
on congestion control, scheduling, and routing in ATM
and IP/MPLS networks. For his work on multimedia
traffic modeling, he received the Best Paper Award in
ACM Sigmetrics in 1995. He has contributed to the IETF
and has RFCs in the MPLS and Traffic Engineering
Working Groups. He has served on the executive and
technical program committees of IEEE and MPLS
conferences. His current research interests are in VoIP,
IMS, broadband access, and data/optical convergence.
Dr. Walid is a member of Tau Beta Pi (the National
Engineering Honor Society) and the IFIP Working
Group 7.3 and a senior member of the IEEE.
150 Bell Labs Technical Journal DOI: 10.1002/bltj
INDRA WIDJAJA is a member of technical staff
at Bell Labs in Murray Hill, New Jersey,
where he focuses on SIP-based (IMS)
network performance enhancements,
VoIP routing issues, and novel data and
optical network architectures. He holds the
B.A.Sc. degree from the University of British Columbia
in Canada, the M.S. degree from Columbia University
in New York City, and the Ph.D. degree in electrical
engineering from the University of Toronto in
Canada. Dr. Widjaja is also coauthor of a textbook
Communication Networks: Fundamental Concepts
and Key Architectures. ◆
