1. N. Jain & H. Shahzad 1 May 2006
Abstract­ Future generation wireless networks
have been envisioned as the integration of
various wireless access networks, including
both wireless wide area networks and wireless
local area networks. In such a heterogeneous
network environment, seamless mobility is the
basis of providing uninterrupted wireless
service to mobile users roaming between
wireless access networks. Because of
transparency to lower layer characteristics,
ease of deployment, and greater scalability, the
application­layer based Session Initiation
Protocol (SIP) has been considered the right
candidate for handling mobility in
heterogeneous wireless networks. However, SIP
entails application­layer transport and
processing of messages, which may introduce
considerable delay. In this review paper, we
brief the current technology status of the
performance of mobility management
protocols in the heterogeneous wireless
networks and summarize research challenges
of VoIP over wireless networks.
1. Introduction
Wireless networks beyond 2G aim at
supporting real‐time applications such as
VoIP. Signaling protocols such as session
initiation protocol (SIP) are used to set up
VoIP calls. SIP is evolving as the dominant
protocol for voice call control in IP networks
and is expected to be widely deployed in the
near future. Using SIP for supporting mobility
in SIP based networks appears as a very
attractive option, taking advantage of existing
SIP infrastructure and signaling. The
integration of cellular and voice over WLAN
(VoWLAN) systems recently has attracted
considerable interest from both academia and
industry. A cellular/VoWLAN dual mode
system helps mobile users to access a low cost
voice over IP (VoIP) service in a WLAN area
and switch to a wide‐coverage cellular system
without WLANs. Figure X
VoWLAN is a new communication
technology by combining two popular
technologies ‐ VoIP and WiFi. In other words,
it is to achieving VoIP communication in the
WiFi network environment. The VoWLAN will
enable enterprise to facilitate the use of
existing WiFi infrastructure to provide voice
service to increases productivity and save
costs. Due to the low coverage of WiFi, it is
then necessarily to design a handoff between
VoWLAN and cellular in order to take
advantages of wide coverage of the cellular
network. This paper demonstrates the
handoff mechanism specifically designed for
roaming between VoWLAN and cellular
networks. It includes a comprehensive
technical review of the current handoff
technologies used in VoWLAN and cellular
network.
The explosive growth of mobile
phone users worldwide, along with the
increasing Internet penetration in human
populations, has led to the users’ need for
accessing high speed Internet data
applications via their mobile terminal, while
still being able to make high quality voice
calls. There have also been efforts [12, 14] for
supporting IP mobility at the application layer
using the Session Initiation Protocol (SIP), as
an alternative to network‐layer mobility.
This poses an opportunity as well as a
challenge for the wireless operators. With 3G
networks on the one hand and WLAN
technologies on the other, wireless operators
can integrate these complementary
technologies to their advantage [10, 19] while
providing the end user with a seamless
experience. Users can connect through a
WLAN when they are in a hotspot, like their
workplace or their home, but their calls can
be handed over to cellular networks as they
roam out of the hotspot. This is valuable to
users because it combines the freedom of
mobility with the low‐cost access of WLAN
while using a single end‐user mobile station.
It is also attractive to 3G service providers
because it extends the reach of their
networks.
However, the challenge here is the
problem of seamlessly handing over a call
from one air interface to another. Real‐time
applications, such as conversational voice or
multimedia over IP, are especially intolerant
of service interruption during handover.
Mobile IP, a layer 3 protocol,
SIP Based VoIP over Converged Wireless Access Networks
Jain, Nishant & Shahzad, Hamid
School of Information & Communication Technology
Royal Institute of Technology
Stockholm, Sweden

2. N. Jain & H. Shahzad 2 May 2006
maintains a data session across
heterogeneous air interfaces. Maintaining the
same IP address enables applications to be
ignorant to changes in the physical layer.
Although mobile IP maintains seamless
session management across distinct
networks, it does not ensure that the
switchover from one physical interface to
another is performed in a “make‐before‐
break” fashion to prevent packet loss during
the transition.
Session initiation protocol (SIP) has
been proposed as a layer 5 alternative for
mobile IP [14], but SIP cannot support
persistent transmission control protocol
(TCP) connections, and it is suitable neither
for micro‐mobility (mobility within a domain)
nor for macro‐mobility (mobility across
domains). Furthermore, the delay in obtaining
a new IP address and performing the
authentication process is excessive. For long‐
lived TCP connections, [12] suggests using
mobile IP as a more desirable protocol.
We begin the paper by providing an
overview of the SIP protocol and the various
types of mobility that have been defined in
this context in the literature. We follow it by
briefly describing the mobile IP architecture
and its components. We then describe the
central idea of the paper by addressing the
issue of seamless data session handover
between 3G and WLAN technologies. The
paper also discusses about the
cellular/VoWLAN service scenario which
involves a user with a dual mode mobile being
able to access VoWLAN in enterprise or hot
spot WLANs, and switch to a cellular system
without WLAN coverage; thus reducing the
cost of mobile telecommunication services,
while also achieving high mobility and wide
coverage [16].
2. SIP­Based VoIP
Mobility management protocols are in general
responsible for supporting services
seamlessly across heterogeneous access
networks that require connection migration
from one network to another. This is known
as the vertical handoff. Thus, in addition to
providing location transparency, the mobility
management protocols in this case also need
to provide network transparency. A number
of research works has been directed towards
solving the vertical handoff problem for IP
based networks [19, 20, 24]. Most of these
works are based on Mobile IP [7]. However,
Mobile IP suffers from the problem of
triangular routing which is detrimental to
real‐time traffic like streaming multimedia,
where the important issues are fast handoff,
low latency and minimal packet loss. Mobile
IP route optimization [6] has been proposed
to solve the problem particularly, but route
optimization again suffers from the following
drawbacks: the IP stack needs change to
implement route optimization and the home
agent can only initiate the route optimization
which introduces additional delay. Several
mobility protocols have been proposed as a
remedy to these problems [2, 4, 6, 9, 17, 27,
28]. Based on the layer of their operation,
these protocols can be broadly classified as
those operating in the network layer [6],
transport layer [2] and application layer [17].
The dependency of these mobility protocols
on the access networks reduces progressively
as we move up on the protocol stack [22].
Among them, Session Initiation Protocol (SIP)
[17] has been standardized by the Internet
Engineering Task Force (IETF) [29] as a
signaling protocol for multimedia session
setup in IP based networks. In addition, SIP is
capable of supporting not only personal
mobility but also terminal, session and service
mobility at the application layer. Application
layer protocols, however, are transparent to
the network (or lower layer) characteristics.
SIP has been accepted by the third
Generation Partnership Project (3GPP) as an
application layer signaling protocol for setting
up real‐time multimedia sessions. Thus, SIP
based mobility management could potentially
use a readily available operational
infrastructure, which would facilitate its fast
deployment. Therefore, SIP seems to be an
attractive candidate as an application layer

3. N. Jain & H. Shahzad 3 May 2006
mobility management protocol for vertical
handoff [22]. Although SIP based mobility
management solves the problem posed by
Mobile IP route optimization, for some cases it
introduces unacceptable handoff delays [21]
for multimedia applications with stringent
QoS requirements. Moreover, SIP entails
application layer processing of the messages
which may introduce additional delay.
Industry‐wide, SIP is being accepted
as the framework of choice for VoIP. In the
next few sections, we describe SIP protocol
along with the basic call flow that is used to
establish an end‐to‐end VoIP call. We also
describe the concept of mobility as used in
SIP.
2.1 SIP Overview
SIP [19] creates a flexible framework for
enabling IP endpoints, or user agents (UAs),
to create, modify, and terminate multimedia
sessions. It can be used for point‐to‐point calls
or multicast calls. It enables the creation of
proxy servers and SIP registrars to allow
endpoints to find each other and provides
other services as well. It may be used over
reliable networks (e.g., TCP) or unreliable
networks (e.g., user datagram protocol
[UDP]). SIP supports multiple IP media
streams that can include VoIP and other UDP
or TCP streaming applications.
SIP is access independent, so it is equally
applicable to wireless and wireline networks.
Designed with unreliable networks in mind, it
incorporates a scheme of retransmissions to
ensure delivery of SIP messages, making it
suitable for wireless networks that incur
over‐the‐air errors. The SIP suite of protocols
has been adopted by 3rd Generation
Partnership Project (3GPP) [33, 34, 35] and
3rd Generation Partnership Project 2 (3GPP2)
[5] as part of the all‐IP core network
architecture and the IP multimedia
subsystems. SIP is not a standalone protocol
for performing all aspects of call control;
rather, it leverages other protocols to provide
a complete solution. For example, in a typical
VoIP application, session description protocol
(SDP) is embedded in SIP messages for
negotiating bearer path attributes, such as the
media types that are supported, the IP
address and port for each media type, and the
protocol for delivering the media. Once the
parameters of the session are agreed upon,
the endpoints can start exchanging packets
over the bearer path. Real‐time protocol
(RTP) is typically used for VoIP. Once the
parameters of the session are negotiated by
the endpoints, the media session is
established. SIP does not play a role in the
media session itself, but it is used for
terminating or changing the parameters of the
session. Common telephony services, like call
waiting, call forwarding, and call hold, as well
as more advanced services, like picture caller
ID and multimedia conference calling, can all
be accomplished with SIP. SIP is based on a
request/response transaction model. The UA
that invokes the request is called the UA client
(UAC), and the UA that responds to the
request is the UA server (UAS). Each request
by the UAC invokes a function, or method, in
the UAS. SIP supports six basic methods:
〉 REGISTER, used by endpoints to identify
themselves to SIP registrars;
〉 INVITE, used for establishing calls or
modifying the parameters of an
established call;
〉 ACK, used to acknowledge final responses
to INVITES;
〉 BYE, used for tearing down established
calls;
〉 CANCEL, used for terminating call setups
before they are fully established; and
〉 OPTIONS, used for querying endpoints or
proxy servers as to their capabilities
without “ringing” them.
As shown in Figure 1, a SIP infrastructure
consists of
〉 user agents,
〉 registration servers,
〉 location servers and
〉 SIP proxies deployed across a network.
A user agent is a SIP endpoint that controls
session setup and media transfer. User agents
are identified by SIP URIs, which is a unique

4. N. Jain & H. Shahzad 4 May 2006
HTTP‐like URI of the form sip:user@domain.
All user agents REGISTER with a SIP registrar
server (which can be co‐located with a SIP
proxy) with their IP address (Figure 1). The
mapping of a URI to the IP address of a device
registered by the user is done using
intermediate SIP proxies, location and redirect
servers as part of the session setup process.
SIP defines a set of messages, such as INVITE,
REFER etc., as shown in Figure 2, to setup
sessions between user agents. These
messages are routed through SIP proxies that
are deployed in the network. DNS SRV records
help in finding SIP proxies responsible for the
destination domain.
2.2 Basic Call Flow
Figure 3 illustrates a typical SIP call flow
through SIP proxies. It depicts the request and
response transactions of SIP for establishing a
call. Prior to the call establishment, each user
is registered with his/her corresponding SIP
registrar. This permits a user to be reached by
his/her own unique network access identifier
(NAI)—e.g., <userA@kth.se>—regardless of
his/her location and point of attachment.
All requests from an originating user
agent such as an INVITE are routed by the
proxy to an appropriate destination user
agent based on the destination SIP URI
included in the INVITE message. The proxy
servers respond with a Trying response so that
originating user agent knows his/her message
was received and that further retransmissions of
the INVITE request are unnecessary. Proxies
may query location and redirect servers to
determine the current bindings of the SIP URI.
Signaling messages are exchanged between
user agents, proxies and redirect/location
servers to locate the appropriate endpoints
for media exchange. For reasons of scalability,
multiple proxies are used to distribute the
signaling load [31]. A session is setup between
two user agents through SIP signaling
messages comprising of an INVITE, an OK
response and an ACK to the response [17].
This is shown in Figure 2 where the call setup
is followed by media exchange using RTP. The
session is torn down through an exchange of
BYE and OK messages.
SIP distinguishes between the
process of session establishment and the
actual session. A basic principle of SIP is the
separation of signaling (control) from media.
Signaling messages are usually routed
through the proxies while the media path is
end‐to‐end. The session setup messages like
INVITE contain user parameters using Session
Description Protocol (SDP) [15] in the
message body. SDP provides information
about the session such as parameters for
media type, transport protocol, IP addresses
and port numbers of endpoints. The IP
address and port numbers exchanged through
SDP is used for the actual data transmission
(media path) for the session. Any of these
parameters can be changed during an ongoing
session through a RE‐INVITE message, which
is identical to the INVITE message except that
it can occur within an existing session. In
addition, a user agent can transfer an existing
session by using a REFER message. This
message instructs the other endpoint of an
existing session to initiate an INVITE/OK/ACK
exchange with a third user agent and
terminate the existing session (with the
sender of the REFER message).
2.3 Mobility: The Issue
Mobility is the most important feature of
wireless networks that makes continuous
service possible in pervasive/ubiquitous
environments. Seamless service is usually
achieved by supporting handoff. Handoff is
the process of changing parameters (e.g.,
endpoint address, channel etc.) associated
with the current connection. For UDP based
connections the major parameters are the
source and destination IP addresses, which
can be changed by the movement of a mobile
host (MH), either within a network or across
different networks. The former scenario
initiates horizontal handoff, whereas the
latter initiates vertical handoff. Handoff is
again divided into two broad categories: hard
and soft handoffs. They are also characterized

5. N. Jain & H. Shahzad 5 May 2006
by “break before make” and “make before
break.” In hard handoffs, current resources
are released before new resources are used
and in soft handoffs, both existing and new
resources are used during the handoff
process. For soft handoff the MH should be
capable of communicating through multiple
network interfaces. Usually, a mobility
management protocol, operating at the
control plane independent of the data plane
supports handoff.
As described earlier, SIP provides
vertical handoff support in IP centric
networks for multimedia applications.
Although the data plane protocols provide
Quality of Service (QoS) to the applications, it
is the responsibility of the mobility
management protocol to maintain the QoS
during the handoff period. For multimedia
streaming applications, the most important
QoS parameters are
(i) end‐to‐end delay,
(ii) delay jitter or variation of end‐to‐end
delay between the packets, and
(iii) packet loss.
Of these three parameters, the first two
depend on the network condition in the path
of the data traffic. Generally, the issues related
to these parameters can be resolved by
providing a playout and jitter buffer. The
handoff delay causes only a glitch as far as
these two parameters are concerned and has
no long‐term effect. However, large handoff
delays cause considerable packet loss which
seriously affects the quality of the multimedia
streaming applications.
Despite the advantages of SIP in
providing mobility support in IP based
heterogeneous networks, there are some
issues that need to be resolved for proper QoS
provisioning to multimedia applications. The
handoff delay in SIP based mobility is
essentially the time required by the re‐INVITE
message to reach the correspondent host
(CH) from the mobile host (MH), but several
different operations need to be completed
before the INVITE message could be
transported. These are:
(i) Detection of the new network by the MH.
This depends on the networking
technology (e.g., periodic beacons from
the access points are used in WLANs to
intimate a mobile device about the
presence of the network) as well as on the
operating system in the MH.
(ii) The MH needs to acquire an IP address by
a procedure specific to the access
network. This may be DHCP address
configuration for WLAN or Attach and
PDP Context Activation for 3G networks.
Analytical study [21] reveals that the handoff
delay can be more than 1 sec for low
bandwidth access network, for which hard
handoff has considerable effect on the
application quality. So, the mobility
management protocol needs to employ some
mechanism to counter the harmful effect of
the handoff delay.
2.4 Mobility Support Using SIP
Mobility is characterized as personal, terminal,
session, and service mobility where a persistent
IP address is not assumed.[14]
〉 Personal mobility is described as allowing a
single user located at different terminals and
to be addressed at each location by a unique
personal identity.
〉 Terminal mobility is described as allowing a
device to move between IP subnets.
Terminal mobility could affect SIP at three
different stages: at pre-call, at mid-call, and
upon recovery from movement across
network partitions. Except for mobility
before a call is placed, none of the other
stages of terminal mobility provide the
seamless experience to a user without any
packet loss.
〉 Session mobility is described as allowing a
user to maintain a SIP session while
changing devices, and
〉 Service mobility is described as allowing a
user to maintain access to his/her personal
services while changing devices and
networks.

6. N. Jain & H. Shahzad 6 May 2006
Personal mobility is embedded in SIP by having
a UA regularly update its registration
information to reflect the user’s current location.
The updates may occur prior to or during a call
on any IP network, independent of the device
being used to access the network. The elements
included in the SIP architecture that support
mobility are UAs, redirect servers, proxy servers,
location servers, and registrar servers. The SIP
servers facilitate user mobility, as they track the
user movement through new registrations. The
UA resides in the mobile node (MN), also
referred to as mobile host (MH), and in the
corresponding remote node, sometimes referred
to as a corresponding host (CH).
When a proxy server or redirect server
receives an INVITE message, it may consult the
location server for a route through which to
redirect the INVITE message (Figure 4). A
redirect server provides the calling party with an
alternate address for the callee, whereas a proxy
server will forward the call to the alternate
address on behalf of the caller. A user al-ways
belongs to a home network that maintains its
home SIP servers. The user re-registers with
his/her home network when changing his/her
point of attachment. A permanent or persistent IP
address is not assumed when the user relocates to
a new network. When the MN is moving
between locations, it is expected that long delays
will be introduced while the UA is obtaining a
new IP address and authenticating with the local
authentication, authorization, and accounting
(AAA) servers.
Session mobility enables the user to
maintain a session while changing terminals
located on the same or a different subnet. This
mobility can be achieved by involving a third-
party call control [8] where the third party is the
original participant that redirects the call to the
new device and stays engaged in the call until its
termination. Another approach for terminal
mobility without the involvement of a third party
can be achieved with the use of the SIP REFER
message [25]. The REFER message simply
directs the session to the new terminal location
where a new INVITE message will be
forwarded. To minimize delay, the device needs
to be authenticated prior to receipt of the
INVITE message.
Service mobility is described in [14] as one
of SIP’s attributes. It provides user with access
to his/her unique services even while he/she is
changing locations or devices. These user
services include speed dial lists, address books,
preference lists, and incoming call instructions,
to name a few.
Maintaining a unique IP address throughout
the session is facilitated through inclusion of the
mobile IP transport elements. The section below
introduces the mobile IP protocols and the
shortcomings of these existing protocols for
make-before-break handover.
This is followed by a discussion for
intelligent mobile IP to provide seamless
handover and an uninterrupted VoIP session
across disparate wireless networks.
3. Mobile IP Architecture
Mobile IP defines three network entities:
〉 the foreign agent (FA),
〉 the home agent (HA), and
〉 the mobile node (MN), which contains the
mobile IP client software.
The FA is a router supporting the mobile IP
protocol located in the foreign (visited)
network. The FA function is located in the
packet data service node (PDSN) for code
division multiple access (CDMA), in the
gateway GPRS support node (GGSN) for the
Universal Mobile Telecommunications System
(UMTS) [11], and in an edge router or WLAN
gateway for WLAN. The FA provides a care‐of
address (CoA) for the MN.
The HA is a router supporting mobile
IP located in the user’s “home” network.
Similarly, if the wireless service provider
(WSP) is the home network, the HA function
may be co‐located in the PDSN or adjacent to
it for CDMA or co‐located with the GGSN or
adjacent to it for UMTS. If the home network
is a third‐party data center, the HA may be
located behind the firewall and next to an

7. N. Jain & H. Shahzad 7 May 2006
edge router. The HA maintains the MN’s
current CoA location information and tunnels
data‐grams to the MN’s CoA (i.e., the FA)
when the MN is away from home, as
illustrated in Figure 5. [5]
For mobility support between
incongruent networks, mobile IP client
software resides in the user’s end terminal,
typically a laptop or PDA. The client is a key
element of the layer 3 integration. For
terminals that support a single air interface,
where a mobile IP client may not be present,
mobile IP‐based architecture may be achieved
with proxy mobile IP functionality embedded
within the network elements.
An MN can be in one of three possible
operating environments: its home network, a
foreign network that supports mobile IP, or a
foreign network that does not support mobile
IP. In all three of these scenarios, the MN uses
a previously assigned identification, either its
own static home IP address or its own
network access identifier (NAI), such as
<enduserA@kth.se>.
In the first operating environment,
the MN is in its home network. The MN
determines it is in its home network by
monitoring the mobility router
advertisements, also known as agent
advertisements. While at home, network
operation is the same as if mobile IP were not
running—i.e., packets are routed in a normal
fashion.
In the second operating environment,
the MN attaches to a foreign network that
contains an FA supporting mobile IP. The MN
first connects to the available access
technology. It determines that there is an FA
when it receives a mobile IP mobility
advertisement from it. The MN sends a
Registration Request message to the FA,
which forwards it onto the AAA infrastructure
and HA, where it is authenticated and
authorized.
In the third operating environment,
the MN attaches to a foreign network that
does not have an FA and does not support
mobile IP. The MN will nevertheless be able to
use mobile IP as long as it can acquire an IP
address (via domain host control protocol
[DHCP] or point‐to‐point protocol [PPP])
from the foreign network. The MN will use the
assigned IP address as its “mobile IP co‐
located CoA” and act as its own tunnel
endpoint. It will register directly with its HA
using the co‐located CoA and the registration
procedure previously described. The MN
sends packets out directly to their destination
(with the MN home ad‐dress as the source
address). All returning packets go to the MN’s
home address and are intercepted by the HA,
which tunnels the packets to the MN. When
reverse tunneling is established, all packets
destined to the CH are directed via the HA, as
illustrated in Figure 5. [5]
3.1 Schemes for Handover
Current mobile IP mechanisms, which detect
mobile movement from one network to the
other, are based on agent advertisement
lifetime and network prefixes [8]. Other
proposed mechanisms are based on end‐user
client criteria, such as signal
presence/strength of the available radio
interfaces.
3.1.1 Agent advertisement lifetime in
mobile IP
An inter‐net control message protocol (ICMP)
router advertisement in mobile IP contains
mobile IP agent advertisement that specifies a
lifetime for which the advertisement is valid.
If for some reason a mobile does not receive
another agent advertisement within this time
frame, it is assumed that the mobile has
moved out of the range of the current agent
and hence is a candidate for handover to
another agent from which it may have already
received an advertisement. This implies that a
mobile would not activate a handover
procedure to the new agent from which it had
received an advertisement earlier until the
advertisement lifetime of its current agent
expires. Typically, the advertisement life‐time
is on the order of tens of seconds. For any
VoIP application, such a long delay for

8. N. Jain & H. Shahzad 8 May 2006
handing over to another agent, being over two
orders of magnitude more than the desired
delay bounds, is unacceptable.
In CDMA2000, the delay in handover
could be even longer. As an implementation‐
dependent optimization in CDMA2000, the
number of advertisements transmitted over
the air interface is restricted—i.e., the agents
only respond to solicitations from the mobile.
The consequence is that the MN does not have
advertisements from new FAs prior to the
expiration of the old advertisement. This
creates additional delay in initiating a
handover to CDMA2000 networks, as a mobile
node must first wait until the advertisement
lifetime of the current agent expires before it
will solicit new advertisements so that it can
proceed with the mobile IP registration
through the new agent. . [5]
3.1.2 Network prefixes in mobile IP
There is an extension to mobile IP that
provides a mechanism for detecting
handovers to a new FA. The mechanism,
based on network prefixes, assumes that an
agent uses an extension called network prefix
extension within the agent advertisement.
This extension specifies the subnet prefix for
the network where the agent is located. Any
difference in the network prefix between the
currently stored value and the one received in
a new agent advertisement would indicate a
handover condition. Since network prefixes,
which are more frequent than the
advertisement lifetime, are specified in the
agent advertisement, this mechanism would
be better suited as a handover trigger.
However, this extension is not mandatory and
therefore cannot be relied upon unless both
the current agent and the new agent are using
it.
The above discussion makes it clear that
the current schemes for fast handover at best
leave a lot to be desired and at worst are
completely inadequate. . [5]
3.1.3 Signal strength.
Mobility management and movement
detection are inherent to the CDMA cellular
network. The proximity to a CDMA base
station can be characterized by the radio link
conditions and received signal strength
indication (RSSI) readings. Similarly,
movement detection from an associated
WLAN access point (AP) can be characterized
by signal strength readings indicated through
the WLAN card interface. Fast movement
detection across these disparate RF
technologies can be achieved by monitoring
these radio signal conditions on a regular
interval. When accessing a WLAN network,
priority is given to the WLAN signal reading,
and its diminishing value can be used as a
movement indication. Similarly, when
accessing a CDMA net‐work, priority is given
to the RSSI information. . [5]
3.1.4 Layer 3 Handover Between
Homogeneous vs. Heterogeneous
Interfaces
When a mobile IP client attempts a handover
between homogeneous air interfaces (such as
a handover from one WLAN AP to another), it
may need to tune to another radio frequency.
This may force the client to hold off
communication with its current point of
attachment or AP until it has been
authenticated using the new point of
attachment. On the other hand, in the case of a
handover between heterogeneous air
interfaces, the assumption is that MNs (such
as laptops and PDAs) are multimode—i.e., the
end‐points are capable of transmitting and
receiving net‐work and data link messages
simultaneously through the multiple air
interfaces. [5]
4. Intelligent “Make­Before­Break”
Handover
Real‐time applications have very stringent
delay constraints on the delivery of packets to
the remote end. A seamless mobility protocol
such as mobile IP ensures that there is

9. N. Jain & H. Shahzad 9 May 2006
continuity of the session management in
terms of both layer 3 (IP layer) and layer 4
(transport layer) between end points. It
does not, however, ensure that packets will
not be dropped as the mo‐bile performs a
handover from one network to another.
There exists a proposal for an intelligent
agent along with an MN client that can
simultaneously monitor wireless signal
strengths of multiple access technologies and
automatically perform access technology
handovers [5]. Assuming that the coverage of
the two disparate networks overlaps, service
disruption and packet loss are minimized as
the MN client either has both network
interfaces active or, based on the algorithm
described in the following sections, would
activate another interface so that it can use
that link in the background to set up the call
prior to handover.
The industry at large has also recognized
the importance of seamless handover for real‐
time applications between heterogeneous
networks. Toward this goal, the IEEE
standards body completed a task within a
study group—the P802 Handoff Executive
Committee Study Group (ECSG)—to
understand and define the problem of
handover between both wireless and wireline
heterogeneous networks. A new group is
currently being formed to address this
problem and facilitate appropriate
information flow in a timely manner for
individual interfaces between layer 1 and
layer 2 (PHY and MAC, respectively) and
higher layers (IP layer and beyond). This
would in effect help an entity such as an
intelligent agent to make fast handover
decisions.
Figure 6 depicts switching scenarios for
overlapped and non‐overlapped coverage.
Figure 6 (a) depicts a make‐before‐break
scenario where the client observes the WLAN
signal overtime. At time t1, when the signal
strength exceeds the threshold H, the client
attempts to use the WLAN interface. Similarly,
at time t2, when the signal strength drops
below the threshold L, the client reverts to the
3Gairlink. If the client sets up the call and
creates short‐lived simultaneous bindings
(dual mobile IP tunnels with both FAs) at the
HA [8] before losing the signal on the current
interface, the delays Δ1 and Δ2 are masked off
and handover appears instantaneous to the
client application. While the simultaneous
bindings are maintained, packets in transit
arrive at both the old and new interfaces and
are not lost. Outgoing packets are routed to
the new airlink immediately after switching,
minimizing packet loss.
In the absence of overlapped coverage,
service interruption is unavoidable because
one link is lost before the new link is
available. However, even in situations where
coverage is overlapped, a “break‐before‐
make” handover scenario may still occur due
to a sudden drop in signal strength, as
illustrated in Figure 6 (b). Here, WLAN is the
preferred interface; however, because its
signal drops so abruptly, there is no time to
connect the 3G call before the WLAN
connection is lost. Consequently, coverage
disruption occurs between t2 and t3 due to
the typical long 3G call set‐up processes (a
few seconds) followed by the t3 to t4 mobile
IP authentication delay.
If, on the other hand, the 3G call were
kept up continuously while connected to the
WLAN, then the switching time would be
determined by the performance of only the
network latency (t3 to t4) between the FA,
HA, and AAA network elements. Maintaining
dual connection is feasible only when volume‐
based charging is applied to the 3G
connections. In such cases (e.g., GPRS),
switching time is reduced and extra charges
are not incurred as a result of the prolonged
3G connectivity.
However, in a general case, keeping two
or more interfaces up simultaneously may not
be a practical approach from a user cost or
network utilization point of view. Moreover,
such an approach imposes a drain on the
battery life of a mobile terminal. All of this
again underscores the need for an intelligent

10. N. Jain & H. Shahzad 10 May 2006
agent, which can bring up a suitable interface
at an appropriate time. When make‐before‐
break handover is possible, the decision to
hand over the session is based on a pre‐
defined criteria matrix that weighs conditions,
such as available bandwidth, signal quality,
access cost, and service‐level agreements
(SLAs) between its mobile operator and the
visited network. The subsection below
describes this aspect of our handover
proposal in more detail.
4.1 Handover Decision Criteria
A scheme is discussed that would ensure a
smooth handover between heterogeneous
networks where an overlap in radio coverage
is available for the systems that are
participating in the handover. The following
are the main components of the System
Selection algorithm (SSA) for deciding when
the MN should hand over a call.
4.1.1 Continuous or periodic monitoring of
all the individual wireless interfaces
The intelligent MN monitors each wireless
interface in order to proactively maintain its
handover options. The following is a list of
conditions that may be monitored in order to
determine if handover is appropriate.
〉 Activity status of an interface. Although
the monitoring of an activity status
(active or inactive) may be applied to
wireless interfaces, it is more relevant to
handover possibility between a wireless
interface and a wireline interface such as
digital subscriber line, or Ethernet‐based
LAN. Specifically, a possible scenario is a
laptop or a PDA equipped with both
wireless and wireline interfaces and
being carried from a wireless
environment to a home or office
environment (or vice versa) such that a
wireline interface is activated.
〉 Viability of an interface in terms of radio
link conditions and RSSI. Note that to
obtain such information from the PHY
and MAC layers requires that there be
some fast coordination between these
layers and the client for exchange of this
information in a timely fashion.
〉 Network loading conditions. This
particular criterion is important from a
service provider point of view. A service
provider may determine that, under
certain circumstances (such as the
number of voice users vs. data users),
more voice users need to be on the
cellular network as compared to data
users when overlapping heterogeneous
networks are available. Under these
conditions, the operator could broadcast
information to all mobiles registered
through a particular cell such that
mobiles could take an intelligent decision
on handover to an alternate network.
Such network loading conditions could be
a function of the time of the day or the
day of the week.
〉 Cost of an interface. This could be set
statically at the time of an interface
becoming active, or, alternatively, it could
be broadcast dynamically to the mobiles.
〉 Service quality. Data bit rates available at
any given point in time determine the
type of service that can be sustained by a
particular air interface.
4.1.2 Threshold management for each
interface
Each interface maintains low watermark and
high watermark values. A handover is
initiated using an interface only if system
conditions satisfy a value above the high
watermark for that interface and precedence
rules allow handover (Tables I and II).
Similarly, the current interface is terminated
and handed off to another available interface
if the current system is below a low
watermark and precedence rules allow a
handover to another interface.
4.1.3 SLAs between different service
providers
An SLA can be a very important part of the
seamless interoperability between
heterogeneous networks, especially if there is

11. N. Jain & H. Shahzad 11 May 2006
a 3G service provider requirement to
authenticate their subscribers in a foreign
network only through its back office AAA
infrastructure. The intelligent client may
require to periodically download an up‐to‐
date SLA list.
4.1.4 Preference management of user and
service provider priorities
The service providers would typically want to
set certain preferences that determine which
interface a user should use to transmit
packets for a given set of circumstances. The
circumstances may include whether the
service provider has SLAs with other service
providers to satisfy some basic AAA
requirements or other considerations such as
cost of an interface and network loading. At
the same time, under certain circumstances,
where a user may have access to the Internet
independent of the current 3G service
provider, he/she may have preferences of
how the packets should flow to its
correspondent node if seamless mobility is
provided. A service provider can
communicate these preferences as a set of
rules whereas a user could indicate or add
additional preferences through a graphical
user interface (GUI) that is part of the MN
client.
Two examples (Table I & II) are given
herewith to illustrate, how a set of such rules
along with preferences entered through a GUI
could be converted into a decision matrix
used by the client software during handover.
The intelligent handover algorithm relies on
the decision matrix that is constructed by a
set of rules that are related to normalized
thresholds. Such thresholds can be derived
from such indices as signal strength reading,
loading conditions, available bit rate, and cost
of link.
Note that each of the examples in (Table I
& II) is shown with a two‐dimensional
decision matrix. Similarly, a multi‐
dimensional decision matrix would have to be
constructed if there were more than two
disparate interfaces simultaneously available
at the MN.
5. Cellular/VoWLAN Dual­Mode
System Architecture and Design
Figure 7 shows the system architecture of an
enterprise cellular/VoWLAN dual mode
service. A cellular/VoWLAN dual mode mobile
equipped with two radio interfaces, i.e. a
cellular interface and a WLAN interface, has
an MSISDN (Mobile Subscriber ISDN) number
for its cellular interface and a SIP (session
initiation protocol) URI (Uniform Resource
Identifier) for its WLAN interface. This study
uses SIP as the call initiation protocol for VoIP
services. A user with a dual mode mobile can
choose the network interface for making calls
based on their personal preferences, network
connectivity and so on. The proposed design
routes the incoming calls to the dual mode
mobile to either the cellular interface or the
WLAN interface, depending on the network
connectivity of the mobile. To provide service
continuity between cellular and VoWLAN
systems without the involvement of a cellular
operator, an enterprise and a dual mode
service provider are two possible
implementation examples.
An enterprise can reserve a range of
PSTN numbers or enterprise extension
numbers, and install a PSTN/VoIP gateway
between PSTN/cellular networks and an
enterprise IP network. These PSTN numbers
or extension numbers are assigned to dual
mode mobiles as their new dual mode service
numbers. For implementation using
enterprise extension numbers, the dual mode
service requires two step dialing, which
means callers must dial an enterprise number
first followed by dialing other extension
numbers. New dual mode SIP URIs that are
generated from these numbers are further
allocated to these dual mode mobiles.
Consequently, dual mode mobiles have new
dual mode numbers and new dual mode SIP
URIs that are used for dial‐in. Incoming calls
to the dual mode numbers or SIP URIs are
processed using the proposed procedures.

12. N. Jain & H. Shahzad 12 May 2006
Two solutions, “parallel fork” and
“wake‐up and register”, are proposed for
handling incoming calls to a dual mode
mobile. [26]
5.1 Incoming calls to the dual mode
number ­ parallel fork approach
First, the parallel fork approach is described.
Figure 8 illustrates the detailed procedures
for processing the incoming calls from a PSTN
or a cellular network to the dual mode
number. Since the dual mode number range
or the extension numbers are held by an
enterprise or a dual mode service provider,
the incoming calls are routed to the
PSTN/VoIP gateway using the standard call
routing procedure. Once the incoming call to
the dual mode number is received by the
PSTN/VoIP gateway, this gateway uses the
dual mode number as the key for querying the
database. If the dual mode mobile does not
register its WLAN account, the database can
only reply the cellular number of the dual
mode mobile. The PSTN/VoIP gateway then
dials the cellular number of the dual mode
mobile only. If the database replies both a
cellular number and a dual mode SIP URI to
the gateway, the gateway dials the cellular
number and also sends a SIP INVITE message
to the dual mode mobile in parallel. The dual
mode mobile receives incoming calls from its
cellular interface, but holds the phone ringing
for a short period. The mobile activates its
WLAN interface, obtains WLAN/IP
connectivity and tries to receive the SIP
INVITE message from its WLAN interface. If
the mobile does receive the SIP message, it
responds to the SIP proxy server using its
WLAN interface. Finally the dual mode mobile
rings and the user answer the incoming calls
via WLANs. If the dual mode mobile can not
receive the SIP INVITE message within a pre‐
configured time‐out value for any abnormal
cases, it rings the users to pick up the call via a
cellular interface. The cellular call to a dual
mode mobile is designed to wake up the
WLAN interface only, but it is actually not
picked up when VoWLAN services are
available.
This design facilitates the dual mode
user to be always reached by a single dual
mode number. Notably, the WLAN interface of
the dual mode mobile is completely off during
idle, and the design significantly reduces
WLAN power consumption in the idle mode.
One problem with this approach is that a SIP
proxy sends a SIP INVITE message to a SIP
user agent without getting a response, and the
SIP proxy will activate exponential backoffs
on SIP message retransmissions [4]. The
exponential backoff retransmission
mechanism of SIP messages is originally
designed for fixed networks to avoid network
congestion, but it introduces extra call
establishment delays. One approach could be
to just disable the exponential backoff
retransmission in the SIP proxy, or apply the
next proposed wake‐up and register method
to avoid the delay. [26]
5.2 Incoming calls to the dual mode
number ­ wake­up and register approach
The wake‐up and register method is proposed
to avoid delays associated with the
exponential backoff retransmission of SIP
messages. The idea of the wake‐up and
register method is that a cellular call is still
used to activate the WLAN interface, but the
dual mode mobile communicates with the SIP
proxy directly to poll SIP INVITE messages
instead of waiting for incoming packets. That
is, following WLAN is attached; the dual mode
mobile sends SIP REGISTER to the SIP proxy to
forward the incoming calls to its current
location. Unlike the parallel fork approach, the
wake up and register approach avoids the loss
and the exponential backoff retransmission of
the SIP INVITE message, but it requires
additional time for registering with the server.
To model the initial call setup latency
of the proposed methods, Figure 9 presents a
timing diagram for all possible conditions, and
illustrates a dual mode mobile that moves
between three different access points (APs).
The first two APs belong to the same

13. N. Jain & H. Shahzad 13 May 2006
subnetwork, but the third one belongs to
another subnetwork domain. The upper part
of the figure shows all of possible delays
introduced by the parallel fork approach,
while the lower part shows the delays
associated with the wake up and register case.
Three different situations can occur if
there is an incoming call to the mobile. One is
that the WLAN interface activates and finds it
can still access the same AP. This situation is
called a layer one update case. After the
mobile receives the cellular paging message
from a cellular network, it takes DL1 time to
activate WLAN interface and sense the
original channel using the WLAN Probe
Request and Probe Response messages. The
WLAN interface then can receive incoming
packets from WLANs. As noted above, since
the parallel fork approach sends SIP INVITE
messages and calls the dual mobile cellular
number in parallel, the first one or several SIP
INVITE messages may be dropped if the
WLAN interface has not yet switched on. The
SIP proxy server may trigger the exponential
backoff retransmission mechanism for
resending the next SIP INVITE. It is assumed
that the dual mode mobile finally receives the
ith SIP INVITE message from a SIP proxy. [26]
To avoid call loss, the parallel fork
and wake up and register approaches both set
a maximum waiting time. If a dual mode
mobile can not receive a SIP INVITE message
from the WLAN interface within the maximum
waiting time, the mobile rings and the user
can answer the cellular call. The maximal
waiting time is a manageable parameter for
users.
Another situation is that the WLAN
interface wakes up but cannot sense the
original channel. This situation is called the
layer two update case. The worse case is that
the WLAN interfaces wakes up, finds a new
AP, but this new AP is not in the same
network domain.
5.3 Periodical location update
The above approaches, although efficient in
reducing the power consumption of a WLAN
interface, they increase call setup delays,
particularly while a mobile activates and
situates in a new network. To reduce average
call setup latencies, periodic location update
procedures in idle mode are proposed. The
idea is that the WLAN must wake up
periodically to check whether it is still in the
same AP. If the user moves to a new AP, the
mobile performs either the layer two or layer
three updates. This updates reduce the
average call initial delay, but increase the
power consumption. The location update
period is a design parameter and the selection
of the value depends on network environment
and user mobility models.
6. WLAN­UMTS Interworking
Architecture
With the wide deployment of hotspots using
WLAN wireless access technologies and the
emergence of IP‐based data services provided
by mobile cellular networks, the integration
between wireless wide area networks
(WWANs ex. UMTS) and WLANs has received
a great deal of attention recently. The
proposed integration architectures can be
classified into two types: loosely coupled and
tightly coupled interworking. In the former
architecture, WWANs and WLANs are
connected through the Internet, and each is an
independent IP wireless access domain; in the
latter architecture, WLANs are incorporated
into WWANs as part of its radio access
subsystem. Although either approach has its
own merits and demerits, the loosely coupled
architecture is assumed in this study because
of its broader application. Figure 10 shows a
logical view of the WLAN‐UMTS interworking
architecture considered in this study. The
architecture is primarily focused on wireless
mobile multimedia networking and is
constructed around an IP core network (the
Internet) with two different types of access
networks: UMTS and WLANs. The UMTS
Release 5 (R5) multimedia architecture [26]
has been proposed to provide multimedia‐
based services in an all‐IP environment.
However, complete migration to UMTS

14. N. Jain & H. Shahzad 14 May 2006
networks may not be possible in the near
future, and a heterogeneous environment
could evolve with several existing access
technologies like IEEE 802.11‐based
broadband WLANs operating with emerging
core networks. This observation forms the
basis of our selection criteria for the
architecture to be studied. The UMTS R5
defines GPRS/Enhanced Data
Rates for GSM Evolution (EDGE)
radio access network (GERAN) as its access
technology. It is assumed that only GPRS
access network due to its wider acceptance.
GPRS networks are built on existing GSM
(Global System for Mobile Communications)
networks by adding a new class of network
nodes called the GPRS support nodes (GSN). A
serving GPRS support node (SGSN) is
responsible for mobility and link management
and delivering packets to a mobile host (MH)
under its service area. A gateway GPRS
support node (GGSN) acts as an interface
between the GPRS network and the external
packet data networks. Home Location
Register (HLR) and Visited Location Register
(VLR) are two databases used to keep user
location information for mobility
management. These databases are derived
from the legacy GSM architecture. A location
register in the SGSN keeps track of the current
VLR for a user. [26]
A salient feature of UMTS R5 is a new
subsystem, known as the IP multimedia
subsystem (IMS), which works in conjunction
with the packet switched core network (PS‐
CN) to support legacy telephony services as
well as new multimedia services.
SIP is the signaling protocol used
between the mobile handset (MH) or user
equipment (UE) and the IMS as well as with
its internal components. As far as SIP
signaling is concerned, the main component of
the IMS involved is the call session control
function (CSCF), which functions as a SIP
server. The CSCF plays three roles: the proxy
CSCF (P‐CSCF), interrogating CSCF (I‐CSCF),
and serving CSCF (S‐CSCF). PCSCF is the
mobile’s first point of contact with the IMS
network; I‐CSCF is responsible for selecting
the appropriate S‐CSCF based on load or
capability; and S‐CSCF is responsible for a
mobile’s session management. The other
access network technology considered is IEEE
802.11‐based WLANs. A WLAN access
network consists of several access points
(APs) providing radio access to the MH. The
APs are connected to the backbone IP
network with an Ethernet switch. A Dynamic
Host Configuration Protocol (DHCP) server is
used to assign an IP address to a visiting MH.
We assume that an MH moving between
UMTS networks and WLANs has separate
network interfaces to connect to these
networks. The MH, after moving to a UMTS
network or WLAN, switches to the respective
interface in order to attach to the
corresponding access network
infrastructures. The switchover instant is
identified by the reception of the GPRS pilot
signal in a UMTS network and the
characteristics beacon in a WLAN. . [26]
6.1 Vertical Handoff in a WLAN­UMTS
Internetwork
As an application‐layer protocol, SIP relies on
the protocols and mechanisms in the lower
layers to handle the physical network
connection. As far as SIP mid‐call mobility is
concerned, additional procedures are needed
to get the MHs attached to the wireless access
network infrastructure before the SIP re‐
INVITE message is sent. For example, an MH
attaches to the GPRS radio access network of a
UMTS network using the GPRS Attach and
Packet Data Protocol (PDP) Context
Activation procedures, while it uses DHCP to
attach to a WLAN. Therefore, the vertical
handoff delay mainly consists of the delay of
network attachment as well as that of SIP
location update. In the following sections we
describe the procedures of vertical handoff
and analyze the associated delays. In
particular, two cases of vertical handoff are of
interest: handoff from a WLAN to a UMTS
network, and vice versa. . [26]

15. N. Jain & H. Shahzad 15 May 2006
6.1.1 WLAN­to­UMTS Vertical Handoff
When an MH moves from a WLAN to a UMTS
network, it performs two key functions to
initiate a handoff.
a.) Data connection setup, including the
GPRS Attach and the PDP Context
Activation:
This establishes the data path required to
carry the SIP‐related messages to the Proxy‐
CSCF through the GGSN, which acts as the
gateway for the Proxy‐CSCF. The messages
involved in the GPRS Attach and PDP Context
Activation procedures are shown in Figure
11. As part of the GPRS Attach procedure, the
MH sends an Attach message (1) to the SGSN
(responsible for mobility management, logical
link management, and authentication and
charging functions in a UMTS network) with
the MH’s international subscriber identifier
(IMSI). The SGSN uses the IMSI to
authenticate (messages 2, 3, 4, and 5) the MH
with its HLR. Successful authentication is
followed by the SGSN sending a location
update to the HLR (messages 6 and 7). The
SGSN finally completes the Attach procedure
by sending an Attach Complete message (8) to
the MH. Thus, a logical association is
established between the MH and the SGSN.
Once an MH is attached to an SGSN, it must
activate a PDP address (or IP address) to
begin packet data communication. Activation
of a PDP address creates an association
between the MH’s current SGSN and the GGSN
(acting as the interface between the
GPRS/UMTS backbone network and the
Internet) that anchors the PDP address. A
record of such an association is known as the
PDP context. PDP context transfer is initiated
by the MH by sending a PDP Context
Activation message (9) to the SGSN. The
SGSN, after receiving this Activation message,
discovers the appropriate GGSN (messages 10
and 11). It selects a GGSN capable of
performing the functions required for SIP‐
related activities. The SGSN and GGSN create
special paths for the transfer of SIP messages
to the P‐CSCF, which is identified by the GGSN.
The corresponding IP address of the P‐CSCF is
sent along with the activation accept message
(messages 12–16). [26]
b.) SIP message exchange that re­
establishes the connection:
As shown in Fig. 2. the MH re‐invites the CH
to its new temporary address by sending a SIP
INVITE message (17) through the P‐CSCF, S‐
CSCF, and I‐CSCF servers. The INVITE
message uses the same call identifier as in the
original call setup and contains the IP address
at the new location in updated SDP
parameters. Once the CH gets the updated
information about the MH, it sends an OK
message (18) while starting to send data. .
[26]
6.1.2 UMTS­to­WLAN Vertical Handoff
When an MH moves from a UMTS network to
a WLAN it goes through the following major
steps to update its location with the CH.
a.) DHCP registration procedure:
Assigns a new IP address for MH’s new
location. The message exchanged in the
registration procedure is shown in Figure 12.
When the MH identifies the presence of a
WLAN after receiving the characteristics
beacons, it broadcasts a DHCP DISCOVER
message (1) to discover the DHCP server
willing to lend it registration service. The
appropriate DHCP server sends out a DHCP
OFFER message (2) to offer service to the
requesting MH. The MH on receiving this
OFFER message sends a DHCP REQUEST
message (3) to the DHCP server to confirm
the offer made. The DHCP server then sends
the MH a DHCP ACK message (4) with such
information as the new IP address to be
assigned to the MH. . [26]
b.) SIP message exchange:
Re‐establishes the connection similar to how
it’s done in UMTS networks, where the MH re‐
invites the CH to its new address by sending a

16. N. Jain & H. Shahzad 16 May 2006
SIP INVITE message (messages 5 and 6, Fig.
3) after acquiring the new IP address. [26]
6.2. Effective VoIP Call Routing
In UMTS‐WLAN integration, a dual‐mode
mobile station (MS) typically disables the
WLAN module for power saving. A major
problem is that for an incoming VoIP call (or
data session), the MS will not be able to
receive this call from the WLAN. It turns out
that the call is directed to the cellular
network. This section discusses a simple push
solution where an MS can accurately detect a
VoIP call from paging signaling of the cellular
network. Then the WLAN module of the MS is
turned on and the VoIP call is connected to
the MS through the relatively inexpensive
WLAN.
Figure 13 illustrates a WLAN and
cellular integration environment where the
MS typically attempts to access the WLAN
first for lower costs and higher bandwidth
connection. If the WLAN is not available, the
MS then tries to access the cellular network.
Due to large power consumption of the WLAN
module, the MS typically turns on the cellular
module and turns off the WLAN module. The
WLAN module is turned on only when the
user attempts to access the WLAN. A major
problem of this usage style is that, for
example, the MS cannot receive the incoming
Voice over IP (VoIP) calls from the WLAN
when the WLAN module is off.
In [18, 13], a push mechanism is
discussed for VoIP incoming calls to WLAN‐
UMTS dual mode MSs. This approach utilizes
Short Message Service (SMS) to alert the MS.
In [4], the SMS mechanism is replaced by the
normal cellular paging. Whenever the MS
receives an incoming cellular call, it always
attempts to connect to the WLAN first. If
successes, the call is connected through the
WLAN as a VoIP call. If fails, the MS accepts
the cellular call. One problem about this
approach is that the MS cannot distinguish a
normal cellular call (path (5) in Fig. 1) from a
VoIP call that is setup from the IP network
(path (1)→ (2) → (3)). Therefore, for a
normal cellular call, the call setup is delayed
because the MS always attempts to connect to
the WLAN first. The MS always experiences
the WLAN connection failure before
connecting to the cellular network.
To resolve this problem, a simple
approach is discussed where the MS can
detect the “originating network” of the calling
party. In a typical Internet and Public Switched
Telephone Network (PSTN) interworking
example illustrated in Figure 13, a Session
Initiation Protocol (SIP) User Agent (UA) is
connected to a SIP Call Server. The Call Server
then sets up the call to the PSTN through a
PSTN Gateway [1]. In a typical PSTN exercise,
a PSTN Gateway is assigned an SS7 number
(say, 46735xxx), or a group of leased lines
whose telephone numbers have the same
prefix (e.g., 46735). The push mechanism is
implemented in the Call Server as described in
[2], [3]. The resulting network node is called
Call Server with Push (CSP). The CSP
maintains a Dual­mode MS (DM) Table. This
table is used to track the call setup status of
dual‐mode MSs. The MS maintains a PSTN
Gateway Table. For every PSTN Gateway
connected to the CSP, the SS7 number of the
PSTN Gateway (e.g., 46735xxx) and the
corresponding fully qualified domain name of
the CSP (e.g., kth.se) are stored in an entry of
the table. The next section illustrates how the
DM table and the PSTN Gateway table can be
used to correctly activate an MS with turn‐off
WLAN module to receive an incoming VoIP
call. [32]
6.2.1 The Call Server with Push (CSP)
Approach
Consider the SIP call setup procedure from an
IP host (a UA) in the external data network
(e.g., Internet) to an MS. The UMTS phone
number of the MS is +46736776474 and the
fully qualified domain name of the CSP is
kth.se. Figure 14 illustrates the message flow
and is described as follows. [32]
Step 1. To set up a call to the MS, the UA sends
an INVITE message to the CSP (Fig. 1 (1)).
The INVITE message contains the SIP

17. N. Jain & H. Shahzad 17 May 2006
Universal Resource Identifier (URI) of the MS,
i.e., +46736776474@kth.se and the Session
Description Protocol (SDP) that describes the
Real­Time Transport Protocol (RTP)
information of the MS. The RTP information
includes the IP address and port number of
the UA.
Step 2. To resolve the SIP URI in the INVITE
message, the proxy function of the CSP
identifies the contact information of the MS.
(i) If the MS has registered to the CSP, the
CSP forwards the INVITE message to the
MS directly, and follows the normal SIP
call setup procedure to connect the call.
(ii) If not, the CSP routes the call to the PSTN
according to the phone number
+46736776474. Specifically, the CSP
forwards the INVITE message to the PSTN
Gateway (Fig. 1 (2)). The CSP also creates
a record (i.e., a DM record) in its DM table
for the MS to indicate that the call is set
up to the PSTN.
Step 3. The PSTN Gateway generates an SS7
Initial Address Message (IAM) containing the
caller ID 46735xxx (the SS7 number of the
PSTN Gateway). Since the destination number
+46736776474 is a UMTS MS Integrated
Services Digital Network (ISDN) number, the
IAM is sent to the UMTS network (Fig. 1 (3)).
Step 4. Finally, the UMTS Base Station (BS)
pages the MS. The message carries the caller
ID 46735xxx.
Step 5. The MS checks its PSTN Gateway table
to see if 46735xxx is found.
(i) If so, the corresponding fully qualified
domain name of the CSP (i.e., kth.se) is
retrieved.
Step 6 is executed.
(ii) If not, the MS answers the paging signal
from the UMTS BS, and follows the
normal UMTS procedure to connect the
call.
At Step 5, through the caller ID, the MS
accurately detects if the incoming call
signaling comes from path (5) (Step 5 (b)) or
from path (1)→ (2) → (3) (Step 5 (a)).
Step 6. The MS attempts to access the nearby
WLAN network. If successes, Step 7 is
executed. If no WLAN access is available, Step
5 (b) is executed.
Step 7. The MS registers its contact address to
the CSP (the registrar function) through a SIP
REGISTER message (Figure 13 (4)). The
registrar function updates the MS’s contact
address information, and returns a 200 OK
message to the MS. Since the DM record
indicates that the call is being set up for the
MS (see Step 2 (b)), the CSP determines that
the call should be re‐connected to the MS
through the WLAN.
Step 8. The CSP (the proxy function)
forwards the INVITE message to the MS.
Step 9. Upon receipt of the INVITE message,
the MS replies a 100 Trying message to
indicate that the call is in progress.
Step 10. The MS plays an audio ringing tone
to alarm the called user and sends a 180
Ringing message to the UA through the CSP.
Upon receipt of the 180 Ringing message, the
UA plays an audio ringback tone to the calling
user.
Step 11. When the called user picks up the
handset, the MS sends the final 200 OK
message to the UA. The 200 OK message
includes the SDP that describes the RTP
information of the MS.
Step 12. Upon receipt of the 200 OK message,
the UA sends an ACK message to acknowledge
the MS. The call is connected.
Step 13. After Step 12, the CSP cancels the call
setup procedure to the PSTN Gateway by
sending a CANCEL message. The PSTN
Gateway sends an SS7 Release message to the
UMTS network.
Step 14. The UMTS replies an SS7 Release
Complete message to the PSTN Gateway. The
PSTN Gateway replies a 200 OK message to
the CSP to indicate that the call is successfully
canceled.
At this point, the voice path is (1)↔(4). One
can note the following:
〉 If any one of Steps 7‐12 fails, the MS will
execute Step 5 (b) to accept the cellular
call (not shown in the call flow).
〉 For a non‐VoIP incoming call from UMTS,
the MS accepts the call immediately (Step

18. N. Jain & H. Shahzad 18 May 2006
5 (b)). Therefore the extra delay in [4] is
avoided.
〉 If the MS has already registered at the
CSP, then the call is set up through the
WLAN directly at Step 2 (a).
〉 If the MS cannot connect to any WLAN
access point, it accepts the cellular call at
Step 6.
〉 There may be several CSP‐PSTN Gateway
pairs in the MS’s PSTN Gateway table, and
the MS can detect the VoIP calls from
various PSTN Gateways.
7. Conclusion
Future‐generation wireless networks have
been envisioned as the integration of various
wireless access networks. Data and voice
services will be simultaneously available
through the same terminal. In such
environments today, multiple issues in
multiple layers still have to be resolved to
ensure acceptable voice quality through VoIP
in disparate wireless networks
Seamless mobility support is the
basis to provide uninterrupted wireless
services to mobile users in such a
heterogeneous network environment. This
paper presented also the mobility
management issues regarding VoIP services in
wireless access technologies convergence.
Mobile IP (network layer solution) and SIP
(application layer solution) were described in
terms of mobility management. Over the
years, several schemes have been proposed
for mobility management in IP networks. For
delay‐intolerant applications such as VoIP,
mobile IP still falls short in terms of providing
a means of fast handover with minimal or no
packet loss; although, as a layer 3 protocol for
seamless mobility across heterogeneous
networks, it has gained momentum in the
recent years. Through this paper we discussed
some layer 2 enhancements at the MN that
work in con‐junction with the mobile IP client
software to enable make‐before‐break
handover between heterogeneous networks.
On the other side, SIP, a widely
accepted signaling protocol, is capable of
providing mobility support at the application
layer, where there is the least amount of
dependence on the lower layers. In this paper,
we also discussed the scenarios of vertical
handoff delay in a WLAN‐UMTS inter‐network
using SIP as the terminal mobility
management protocol. Studies have shown
that the WLAN‐to‐UMTS handoff due to error‐
prone and bandwidth‐limited wireless links
incurs much larger delay than the UMTS‐to‐
WLAN handoff. In order to comply with the
maximum limit of the handoff delay for
supporting delay‐sensitive applications, soft
handoff techniques need to be applied for SIP‐
based terminal mobility management in
heterogeneous wireless IP networks.
One of the significant issues besides
mobility management in a WLAN and cellular
integrated network is that a dual‐mode MS
typically disables the WLAN module to reduce
the power consumption. Therefore, the
incoming VoIP calls to the MS cannot be
connected through the WLAN. To address this
issue, this paper also discussed a Caller Server
with Push (CSP) mechanism where the MS can
accurately detect the VoIP calls through
cellular paging, and then the CSP can re‐route
the call through the WLAN.
There are some successful stories for
VoIP in converged wireless access networks
but to enable large deployment of services in
public networks suffers from a number of
technical challenges. Research and
technologies development at both terminals
and networks are required urgently, and more
detail analysis and from different perspectives
will be very helpful. Besides that the protocol
between terminals and networks should be
standardized, opens issues such as how
terminals decide the always best connected
issues, always on issue, and power
consumption issues needs to be further
studied.

19. N. Jain & H. Shahzad 19 May 2006
References
1. A. Acharya, S. Berger and C.
Narayanaswami, “Unleashing the
Power of Wearable Devices in a SIP
Infrastructure”, Proceedings of the
3rd IEEE Int’l Conf. on Pervasive
Computing and Communications
(PerCom 2005), 2005
2. A. C. Snoeren and H. Balakrishnan,
“An End‐to‐End Approach to Host
Mobility”, Proceedings of the ACM
Mobicom, August 2000.
3. A. Dutta, F. Vakil, J.‐C. Chen, M. Tauil,
S. Baba, N. Nakajima, and H.
Schulzrinne, "Application layer
mobility management scheme for
wireless Internet", In Proc. of IEEE
International Conference on Third
Generation Wireless and Beyond
(3Gwireless'01), May 2001.
4. A. Grilo, P. Estrela, and M. Nunes,
“Terminal Independent Mobility for
IP (TIMIP)”, IEEE Communication
Magazine, 2001.
5. A. Rajkumar, P. Feder, S. Benno and T.
Janiszewski, “Seamless SIP‐Based
VoIP in Disparate Wireless Systems
and Networks”, Bell Labs Technical
Journal 9(1), Lucent Technologies
Inc., 2004
6. C. Perkins and D. Johnson, “Route
Optimization in Mobile IP”, IETF
Draft, September 2001,
<http://www.ietf.org/internet‐
drafts/draft‐ietf‐mobileip‐optim‐
11.txt>
7. C. E. Perkins, IP Mobility Support for
IPv4, RFC 3220, Jan. 2002.
8. C. Perkins (ed.), “IP Mobility Support
for IPv4,” IETF RFC 3344, August
2002,
<http://www.ietf.org/rfc/rfc3344.txt
?number=3344>.
9. C‐Y. Wan, A. T. Campbell, and A. G.
Valko, “Design, implementation and
Evaluation of Cellular IP”, IEEE
Personal Communications, Vol. 7, No.
4, August 2000.
10. D. Benenati, P. Feder, N. Lee, S.
Martin‐Leon, and R. Shapira, “A
Seamless Mobile IP VPN Data
Solution for CDMA, UMTS, and WLAN
Users,” Bell Labs Tech. J., 7:2, 2002
11. D. Vali and A. Greece, “An Efficient
Micro‐Mobility Solution for SIP
Networks”, IEEE Globecom, 2003
12. E. Wedlund, H. Schulzrinne, “Mobility
support using SIP”, 2nd ACM/IEEE
International Conference on Wireless
and Mobile Multimedia, August 1999
13. Feng, V. W.‐S., Wu., L.‐Y., Lin, Y.‐B.,
and Chen, W.‐E., “WGSN: WLAN based
GPRS Environment Support Node
with Push Mechanism”, The
Computer Journal, 47(4), 2004.
14. H. Schulzrinne, E. Wedlund,
“Application layer mobility using
SIP”, Mobile Computing and
Communications Review, Volume 4,
Number 3, 2001
15. Handley, M. and V. Jacobson, SDP:
Session Description Protocol, RFC
2327, IETF April 1998.
16. J. Ala‐Laurila and et al., “Wireless LAN
access network architecture for
mobile operators,” IEEE
Communications Magazine, Nov.
2001.

20. N. Jain & H. Shahzad 20 May 2006
17. 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.
18. Lin, Y.‐B., Lo, Y.‐C., and Rao, C.‐H. A
Push Mechanism for GPRS Supporting
Private IP Addresses. IEEE
Communications Letters, 5(1), 2003.
19. M. Buddhikot, G. Chandranmenon, S.
Han, Y. Lee, S. Miller, and L. Salgarelli,
“Integration of 802.11 and Third‐
Generation Wireless Data Networks,”
Proceedings of the IEEE Infocom, Vol.
1, 2003
20. M. Stemm and R. Katz, “Vertical
handoffs in wireless overlay
networks”, ACM Mobile Networks
and Applications (MONET), Vol. 3(4),
1998.
21. N. Banerjee, W. Wu, K. Basu, and S. K.
Das, “SIP Based Mobility Management
in 4G Wireless Networks”, Journal of
Computer Communications, special
issue on Research Directions in 4th
Generation Wireless Networks, Vol.
27/8, 2003.
22. N. Banerjee,W.Wu, S. K. Das, and S.
Dawkins, and J. Pathak, “Mobility
Support in Wireless Internet”, IEEE
Wireless Communications Magazine,
Vol. 10, No. 5, 2003.
23. N. Banerjee and S. K. Das, “SIP‐based
Mobility Architecture for Next
Generation Wireless Networks”,
Proceedings of the 3rd IEEE Int’l
Conf. on Pervasive Computing and
Communications (PerCom 2005),
2005
24. Q. Zhang, C. Guo, Z. Guo and W. Zhu,
“Efficient mobility management for
vertical handoff between WWAN and
WLAN”, IEEE Communications
Magazine, Vol. 41, No. 11, 2003.
25. R. Sparks, “The Session Initiation
Protocol (SIP) Refer Method,” IETF
RFC 3515, 2003,
<http://www.ietf.org/rfc/rfc3515.txt
?number=3515>.
26. Shiao‐Li Tsao and E‐Cheng Cheng,
“Reducing Idle Mode Power
Consumption of Cellular/VoWLAN
Dual Mode Mobiles”, IEEE Globecom
2005
27. S. Das, A. McCauley, A. Dutta, A. Misra,
K. Chakraborty and S. K. Das, “IDMP:
An Intra‐Domain Mobility
Management Protocol for Next‐
Generation Wireless Networks”, IEEE
Wireless Communications, Vol. 9, No.
3, June 2002.
28. T. La. Porta, R. Ramjee, L. Lee, L.
Salgerelli, and S. Thuel, “IP‐based
access network infrastructure for
next‐generation wireless data
networks” IEEE Personal
Communications, Vol. 7, No. 4, August
2000.
29. The Internet Engineering Task Force,
http://www.itef.org
30. W. Wu, N. Banerjee, K. Basu and S.K.
Das, ” SIP‐Based Vertical Handoff
Between WWANs and WLANs”, IEEE
Wireless Communications Magazine,
June 2005
31. W. Jiang, J. Lennox, H. Schulzrinne
and K. Singh. Towards Junking the
PBX: Deploying IP Telephony.
NOSSDAV, 2001

21. N. Jain & H. Shahzad 21 May 2006
32. Yi‐Bing Lin, Whai‐En Chen and Chai‐
Hien Gan, “Effective VoIP Call Routing
in WLAN and Cellular Integration”,
IEEE Communications Letters, Vol. 9,
No. 10, October 2005
33. 3rd Generation Partnership Project,
“Technical Specification Group
Services and Systems Aspects;
Network Architecture,” TS 23.002,
<http://www.3gpp.org/ftp/Specs/ht
ml‐info/23002.htm>.
34. 3rd Generation Partnership Project,
“Technical Specification Group
Service and Systems Aspects; IP
Multimedia Subsystem (IMS); Stage
2,” TS 23.228,
<http://www.3gpp.org/ftp/Specs/ht
ml‐info/23228.htm>.
35. 3rd Generation Partnership Project,
“Technical Specification Group Core
Network; IP Multimedia Call Control
Protocol based on Session Initiation
Protocol (SI) and Session Description
Protocol (SDP); Stage 3,” TS 24.229,
<http://www.3gpp.org/ftp/Specs/ht
ml‐info/24228.htm>

22. Figures and Tables
Figure 1. SIP Architecture
Figure 2. SIP Call Setup & Media Path

23.
Figure 3. Basic Call Flow

24.
Figure 4. Basic SIP Exchange
Figure 5. Mobile IP with Foreign Agent

25.
Figure 6. ”Make­before­break” switching for overlapped coverage and “break­before­make”
switching for non­overlapped coverage

27.
Figure 7. Design example of integrated VoWLAN/Celluar Service

28.
Figure 8. Routing of incoming calls to a duel mode mobile using parallel fork approach
Figure 9. Timing diagram of parallel fork, wake­up and register approaches

29.
Figure 10. WLAN­UMTS Interworking Architecture
Figure 11. Signaling for WLAN­to­UMTS Handoff

30.
Figure 12. Signaling for UMTS­to­WLAN Handoff
Figure 13. WLAN and Cellular integration environment

31.
Figure 14. Message Flow for an incoming call to the dual­mode mobile MS
Figure X. Illustration of future voice over converged wireless networks