Seventh International Conference on Networking

Proactive Handover in Heterogeneous Networks using SIPs

Elin Sundby Boysen Hkon Eyde Kjuus

Norwegian Defence Research Establishment (FFI) UniK - University Graduate Center
Kjeller, Norway Kjeller, Norway
Email: [email protected] Email: [email protected]
Torleiv Maseng
Norwegian Defence Research Establishment (FFI)
Kjeller, Norway
Email: [email protected]

Abstract We also assume that the capacity is sufficient to support the

services requested.
In some areas, overlapping networks provide alternative When a user is changing network while downloading a
wireless links like WLAN, GSM, 3G etc. Ideally, the user web page it might be annoying but not critical if there is a
should be connected to the most attractive network any time delay while changing access point and packets lost during
according to predefined priorities. This is accomplished the change must be resent. This is not the case when consid-
with automatic handover. The most likely commercial ap- ering real-time voice or video. Too long delays will give a
plication of this type is designed for speech, and is using poor user experience or in the worst case interrupt the whole
SIP to set up VoIP calls through WLAN networks or mobile session. Hence, with session continuity as the ultimate goal,
networks. To make the handover time as short as possi- an important task is to reduce the time it takes to complete
ble is essential to make it attractive. This is best done by a handover - the handover delay to prevent packet loss and
preparing the alternative networks before the handover is keep jitter at a minimum.
needed. This is called proactive handover. This paper sug- Handover can be initiated by the mobile node (MN) or
gests changes to some of the basic SIP messages that open from centralized management in the network. The latter is
for proactive handover in SIP and help reduce the delays the case in the GSM system where the base stations initiate
when roaming. the handover. The lack of centralized management in the In-
ternet makes this more complicated. Still, the MN can make
some measurement of link quality and send it to a central-
1. Introduction ized server that makes the decision of when to initiate the
handover. This requires some extra signalling compared to
The differences between mobile phones and computers a decentralized solution where the MNs themselves decide
are becoming less obvious. As laptop computers are in- when to do the handover. The decentralized solution will
creasingly widespread and mobile phones no longer are just require more intelligent MNs, and one objection is that the
phones but handheld computers, mobility support for In- link management will increase the power consumption of
ternet access has become more and more interesting. New the mobile device.
handheld devices are equipped with several interfaces to In heterogeneous networks we differ between vertical
support wireless access through 2G/2,5G/3G cellular, Blue- and horizontal handover. Horizontal handover is between
tooth, 802.11 (WiFi) and soon also mobile WiMAX and two access points of the same kind, for example WiFi to
other technologies. This will enable the mobile node to WiFi handover. The rest of this paper will focus on vertical
choose the preferred wireless access, either from price or handover - the handover between access points of different
from which carrier has the best characteristics suited for the types like for example Bluetooth and WiFi. When perform-
current application. ing vertical handovers the mobility management protocol
We assume in the following that the roaming mobile must not only provide location transparency, but also net-
users are equipped with the subscriptions and the privileges work transparency.
to establish alternative sessions in the networks considered. The two main approaches to obtain session continuity

978-0-7695-3106-9/08 $25.00 © 2008 IEEE 719

DOI 10.1109/ICN.2008.111

Authorized licensed use limited to: National Ilan Univ.. Downloaded on March 04,2021 at 15:18:07 UTC from IEEE Xplore. Restrictions apply.
are on the network layer with Mobile IP and on the ap- each time it changes IP-subnet. When a correspondent node
plication layer with augmented existing protocols for VoIP (CN) tries to reach the mobile node, the call will either be
such as H.323 or Session Initiation Protocol (SIP). Both ap- routed through a ”middle man” in the home network or the
proaches have advantages and drawbacks, and the one does CN will receive a response message describing the current
not necessarily exclude the other. We have chosen to focus address of the node. In the latter case the CN initiates the
on the application-layer approach because of its flexibility session with the MN directly at the MN’s current address.
and ease of implementation. Mid-call mobility is the ability to move while a session is
active. The MN must update the CN of its new location
2. Mobile VoIP with SIP during the session.

In this section we will give a short introduction to SIP 2.2. Related work
and present some related work on handover using SIP.
The need to perform a handover can rise from two situa-
2.1. Introduction to SIP tions, either as recovery after link breakage or as a planned
handover due to observed degradation of the link quality or
SIP has been standardized by the Internet Engineering the discovery of a new link option with better qualities or
Task Force (IETF) and is accepted as a 3rd Generation Part- lower cost. A typical situation for link breakage is when
nership Project (3GPP) signalling protocol and a permanent an ethernet cable is suddenly unplugged from a laptop com-
element in IP Multimedia Subsystem (IMS). It is an appli- puter and a new connection is made through for instance
cation layer signalling protocol used to establish, maintain WiFi. We differ between soft (”make-before-break”) and
and tear down sessions. It is independent of the underlying hard (”break-before-make”) handover. In the hard handover
network technology. Signalling in SIP is composed of text- all resources in the first connection are released before es-
based messages. The main logical entities in SIP consist tablishing a new connection. During soft handover, the
of user agents (UA), registrars, proxy servers and redirect equipment is able to communicate over multiple interfaces
servers. User agents initiate and terminate sessions. The and thus using resources in both networks simultaneously.
UAs register their current network location with a regis- To promote the success of terminal mobility with SIP,
trar. A proxy server can be stateless or stateful. A state- four points are of importance:
less proxy server will only forward incoming requests and
responses. A stateful proxy on the other hand will maintain 1. Delay: The handoff delay must be short enough not to
a state for each transaction, -that is which requests and re- break an ongoing session or to introduce serious degra-
sponses belong to that transaction. Redirect servers receives dation of user experience during the handover. This is
requests and responds to the requestor where it should send especially important for voice calls.
its request. A back-to-back user agent (B2BUA) is a logi-
2. Packet loss and jitter: The packet loss and delay dur-
cal entity that receives a request and processes it as a user
ing the handover should be minimized. In addition to
agent server on one side. On the other side it acts like a
a degraded user experience, too high packet loss or jit-
user agent client and generates requests. It maintains dialog
ter can make it impossible for a streaming session to
state and must participate in all requests sent on the dialog
synchronize and thus interrupt the whole session.
it has established. A B2BUA can also terminate and bridge
the media stream and thus have full control over the whole 3. Recovery capabilities: A good handover scheme
session. This makes B2BUAs well suited for transcoding should in the case of sudden link loss recover fast
between two call legs, to hide network internals, and for enough to prevent sessions from collapsing.
network interworking as it can have protocol adaptation.
SIP inherently supports personal mobility. This means 4. Ease of deployment: To ease deployment of a han-
that a user can be found using a single identifier regard- dover scheme, the possibility of gradually deployment
less of which location or device (such as PCs, PDAs or should be supported.
phones) he or she is currently at [5]. Terminal mobility
is more relevant when introducing wireless access and is One of the first introductions to SIP-based mobility was
the topic of this paper. Terminal mobility allows the user presented by Wedlund and Schulzrinne in [7] and further
to move around with the device, and the device will roam elaborated in [6]. In the proposed handover solution a new
between different IP subnets. We differ between pre-call INVITE message is sent from the MN to the CN with the
mobility and mid-call mobility or in-session mobility. Pre- terminal’s new IP-address and updated session parameters
call mobility is the easiest part, as the MN will only need in the message’s Session Description Protocol (SDP) part.
to re-register its new IP-address with the home registrar As soon as the CN receives the INVITE message it will

720

Authorized licensed use limited to: National Ilan Univ.. Downloaded on March 04,2021 at 15:18:07 UTC from IEEE Xplore. Restrictions apply.
 Figure 1. Handover from Wedlund and Figure 2. Handover from Banerjee et al [1]
Schulzrinne [7]

send data to the new location. Then a new REGISTER mes-

sage is sent from the MN to the home registrar (the regis-
trar in the home network of the MN). This is illustrated in
Fig. 1. This is a hard handover scenario, and at first glance
it seems that the handoff-delay is the time required to send
and process the re-INVITE message. What is somewhat
hidden here is the time it takes to a) discover that the device
has changed location or lost connection at its first location
and b) acquire a new IP address in the new network. The
respective delays depend on the current networking tech-
nology. In WiFi a) may be the time between the periodic
beacons sent from the access points and b) the delay intro-
duced by a DHCP server. Banerjee et al suggest in [1] that Figure 3. Handover from Bellavista et al [3]
this handoff delay can be up to 1 second. As real-time ap-
plications require max handoff delays in the range between
50 ms and 200 ms to avoid serious degradation of service[4] The B2BUA is coupled with a media gateway that perform
this is clearly not good enough. RTP packet forwarding, and during the handoff also packet
Chahbour et al[4] recognize address acquisition as the duplication and packet filtering. Handoff is initiated by
main contributor to degraded service quality during hand- the MN and involves duplication and transmission of RTP
off. They suggest Predictive Address Reservation (PAR) packets over both interface in the old B2BUA, RTP packet
in combination with Hierarchical Mobile SIP (HMSIP) to filtering in the MN, and communication between the old
reduce the handoff delay. Address reservation and regis- and the new base station. After the handover is completed a
tration procedure is performed prior to the handoff in par- REGISTER message is sent to the home registrar to update
allel with the existing SIP session. The PAR scheme uses the MN’s location information. This is illustrated in Fig 2.
link layer information to make decisions on when to start It is an interesting architecture that can prevent packet loss
searching for a new access point and to initiate the handover and delays during handover, but it requires that all access
with PAR. The main objective in this solution is to reduce points implement the SIP B2BUAs with ability to negotiate
handover delay. It does not guarantee a handover with no with each other during handover.
packet loss. Bellavista et al[3] have another approach to handover in-
A solution for vertical soft handover is described by troducing application-layer middleware to support session
Banerjee et al in [1]. The MN is equipped with differ- continuity. Their Mobile agent-based Ubiquitous multime-
ent communication interfaces and can use each of these dia Middleware (MUM) described in [3] and [2] consists
simultaneously. In each network the MN communicates of a Proxy Switch (PS) at the ingress of each domain and
through base stations (BS) which include a SIP B2BUA. a Proxy Buffer in each subnet. A Handover Agent Activa-

721

Authorized licensed use limited to: National Ilan Univ.. Downloaded on March 04,2021 at 15:18:07 UTC from IEEE Xplore. Restrictions apply.
tor (HAA) present in each subnet can activate a Handover
Agent (HA) in conjunction with a B2BUA in the Proxy
Buffer when a MN enters the subnet. A handover scenario
is illustrated in Fig 3. Some steps are omitted for simplicity.
The solution supports both vertical and horizontal handover
and is currently targeted at data streaming. Packets are be-
ing buffered in both the old and the new domain ensuring
that no packets are lost while the MN is disconnected dur-
ing the actual handover. While this solution ensures zero
packet-loss, the disconnection period will still be too long
and introduce problems for voice calls. The scheme also
requires all subnets to be equipped with a HA and HAA.
Four handover architectures have been presented of
which only one supports soft handover. The solution in [7]
does not use any link information for prediction to prepare
a coming handover. This is done in [4] by Predicitve Ad-
dress Registration to reduce the handover delay. In both the Figure 4. Handover scenario with gradually
solutions described in [1] and [3], the use of B2BUAs is degrading link
recognized as an effective way to provide better and faster
handoff, and both solutions require deployment of entities
in each domain or subnet that interact to support the han-
the user agent is valid. When the registrar receives a REG-
dover. [1] describes a soft-handover solution where packets
ISTER request it will also return a parameter ”if no” in the
are duplicated, while [3] describe a hard-handover where
200 OK respond, telling the MN how many interfaces are
packets are buffered to avoid packet loss during handover.
currently registered. If the MN is registering with a SIP
Solutions described in [4] and [1] requires that two commu-
server that does not support proactive handover, the ”if q=”
nication interfaces can operate simultaneously. Properties
and ”ua id=” parameters will just be ignored and the REG-
of the different handover schemes are summed up in Table
ISTER request will be treated as any other registration mes-
1.
sage in SIP. A SIP server that does not support proactive
handover will not return the ”if no” parameter in the 200
3. Proactive handover OK respond. This tells the UA that it should not send any
backup registrations as these would only overwrite the main
We suppose that the device has more than one interface, registration.
wireless or not. If more than one interface can be used, When the MN wishes to initiate a session it sends an
one is chosen as main interface while the others are consid- INVITE message over the main interface. But as soon as the
ered backup interfaces. It will be up to each MN to decide session is set up the normal way, it also sends an INVITE
whether it needs more than one backup interface. Each in- with the same call ID over the first backup interface. The
terface will try to connect to a network and obtain an IP B2BUA sees that the call ID is the same as in the on-going
address as soon as it sees that it is within the reach of a session and that the message is marked in SDP as send-
wireless access point. only, and puts the invitation directly on hold. To prevent
The home registrar is implemented on a B2BUA that also timeout on the backup interface, the send-only invitation to
bridges calls between the mobile node and any correspon- the current session is regularly resent, but there is no data
dent nodes and thus controls the media stream. traffic over the backup interface.
When the MN registers with the home registrar it will As described earlier, the handover procedure is initiated
register all the interfaces with the registrar and choose a pri- either as a result of gradual degradation of the link or due
ority amongst them. This is done by adding a new param- to sudden link loss, and the handover procedure will differ
eter ”if q=” in the Contact header field of the REGISTER accordingly. Both cases depend on a middleware inform-
request. To signal that the different registration messages ing the user agent of the state of the link, where link state
are indeed from the same device through different interfaces parameters can be packet-loss ratios and/or signal-to-noise
and that it is not a user that has moved from one device to ratio or other. In the case of gradual link degradation, a
another, the Contact field is also provided with the param- threshold value on the link state parameters has been set.
eter ”ua id=”, user agent identification. This is a random When the value drops below the threshold, a new INVITE
number provided by the user agent when first registering is sent over the backup interface. Through SDP in the IN-
with the registrar and it is kept as long as the registration of VITE request, the B2BUA is informed that a handover is

722

Authorized licensed use limited to: National Ilan Univ.. Downloaded on March 04,2021 at 15:18:07 UTC from IEEE Xplore. Restrictions apply.
 Table 1. Summary of handover characteristics
Handover Handover delay Deployment
type
Wedlund & Hard tDetect link loss + No new entities required
Schulzrinne[7] tAcq new ip address + in the network
tSIP re−invite
Chahbour et Hard tDetect link loss + No new entities required
al[4] tSIP re−invite in the network
Banerjee et Soft None New entities required in
al[1] networks
Bellavista et Hybrid tAcq new ip address + New entities required in
al[3] tSIP re−invite networks
Boysen & Soft None Small changes required
Kjuus in Home Registrar /
(gradually B2BUA
degraded link)
Boysen & Hard tDetect link loss + Small changes required
Kjuus (primary tSIP re−invite in Home Registrar /
link suddenly B2BUA
broken)

initiated and that packets should be duplicated for a cer-

tain period. The original path is still kept open and the data
stream is sent over both interfaces. This requires packet
duplication in the B2BUA and packet filtering mechanisms
in the UA, and allows the UA to synchronize the incoming
packets and smooth out jitter before the original path is re-
leased. When the handover is completed, the priority of the
registered interfaces is rearranged; the interface that used to
be main interface becomes the primary backup interface and
vice versa. This is done automatically both in the B2BUA
and in the UA. Should the MN have more than one backup
interface and one of the other interfaces is more suited to
be the primary backup interface, a new REGISTER request
marked with the desired priority is sent. This gives the MN
the possibility to move in and out of the same zone without
having to actively re-register the backup interface. The new Figure 5. Handover scenario with broken pri-
backup interface must in either case send a new directly-on- mary link
hold INVITE to function as backup to the ongoing session
over the main interface. See Fig 4.
3.1. Testresults, evaluation and future work

The architecture has been implemented and tested for the

case of sudden link loss. We have used an Asterisk B2BUA
In the event of a link breakage, UA will send a new IN- and a SIP Communicator user agent. Both are open source
VITE request via the backup interface as soon as the link software that we have modified to meet our requirements. In
loss has been detected. The session is then continued imme- the different presented handover solutions concerning link
diately. In this case the SIP server is informed through SDP loss, the total handover time is given by Eq( 1),
in the INVITE request that a breakage has occurred and that
tHandover = tDetect link loss + tAcq new ip address
the path should be switched and packets do not need to be
duplicated. See Fig 5. + tSIP re−invite (1)

723

Authorized licensed use limited to: National Ilan Univ.. Downloaded on March 04,2021 at 15:18:07 UTC from IEEE Xplore. Restrictions apply.
where tDetect link loss is the time from the link is broken higher load on the B2BUA with respect to handover time.
until this is detected by the user agent. tAcq new ip address As the B2BUA is acting as a home registrar as well as a
is the time required to acquire a new IP address and bridge for the calls between MN and CN, it can become a
tSIP re−invite is the time needed to send a new INVITE hot spot. To reduce the load on the home registrar handover
message. All this should be done within 200 ms. To detect between subnetworks could be controlled by local registrars
the link loss, a lower-layer mechanism is needed to inform in the visited network. In this way Hierarchical Mobile SIP
the higher layers that the link is lost and some action has can be combined with the architecture suggested here.
to be taken. As in the other mentioned solutions, we also
keep the implementation of such a mechanism out of the References
scope of this study and focus on reducing the time needed
for the other parts of Eq( 1). We have already shown that we
[1] N. Banerjee, S. K. Das, and A. Acharya. SIP-based Mo-
can omit tAcq new ip address by using the proactive handover bility Architecture for Next Generation Wireless Networks.
scheme. Our preliminary testresults show that the handover In Pervasive Computing and Communications, 2005. PerCom
time tSIP re−invite , which is the time from the new INVITE 2005. Third IEEE International Conference on, pages 181–
message is sent until the new interface receives its first pack- 190, University of Texas at Arlington, March 2005. IEEE
ages, is less than 40 ms. It is already clear that this time can Computer Society.
be further reduced through code optimization. [2] P. Bellavista, A. Corradi, and L. Foschini. Application-Level
The tests were performed within a local network where Middleware to Proactively Manage Handoff in Wireless In-
ternet Multimedia. In Management of Multimedia Networks
the roundtrip time for the new INVITE message is around
and Services (MMNS), volume 3754, pages 156–167, Berlin /
1 ms. In a lare-scale network this roundtrip time will be Heidelberg, October 2005. Springer.
higher, but still in a range where it is neglectable. Thus, our [3] P. Bellavista, A. Corradi, and L. Foschini. SIP-based Proac-
results are well within the limit of 200ms described earlier tive Handoff Management for Session Continuity in the Wire-
and also leave time to discover the link breakage. less Internet. In 26th IEEE International Conference on Dis-
The presented solution fulfils the four requirements pre- tributed Computing Systems Workshops 2006, (ICDCSW06),
sented above. In the case of a handover due to degraded link pages 69–69, Universit di Bologna, Italy, July 2006. IEEE
quality the use of two interfaces simultaneously ensures that Computer Society.
[4] F. Chahbour, N. Nouali, and K. Zeraoulia. Fast Handoff for
no packets are lost and that jitter can be smoothed out. It
Hierarchical Mobile SIP Networks. International Journal
introduces no handover delay. Zero packet loss cannot be of Applied Science, Engineering and Technology, 5:34–37,
promised in the case of a link breakage, but the handover 2005.
delay is reduced to the time it takes to discover the link loss [5] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston,
and send the new INVITE message. The implementation J. Peterson, R. Sparks, M. Handley, and E. Schooler. IETF
does not require all subnets to support the proactive han- RFC3261, SIP: Session Initiation Protocol, 2002.
dover. As long as the MN is able to create a path to its [6] H. Schulzrinne and E. Wedlund. Application-Layer Mobil-
home registrar/B2BUA via a backup interface, it is capable ity using SIP. SIGMOBILE Mob. Comput. Commun. Rev.,
of performing a fast handoff whenever required. 4(3):47–57, 2000.
[7] E. Wedlund and H. Schulzrinne. Mobility Support using SIP.
As in the solution presented by Chahbour et al and by In WOWMOM ’99: Proceedings of the 2nd ACM interna-
Banerjee et al, we also suggest to use to two communca- tional workshop on Wireless mobile multimedia, pages 76–82,
tion interfaces concurrently. This is essential to provide soft New York, NY, USA, 1999. ACM Press.
handover. But while the mentioned solutions activate and
acquire an IP-address for its new interface just before the
handover takes place, we suggest a more permanent reg-
istration. This enables fast recovery after link breakage.
There are two drawbacks to this. First, the MN needs two
IP-addresses over a longer period of time. Second, it re-
quires the backup interface to be active and send regular
messages to keep the connection alive. Even though no data
is sent over the interface while in backup-mode, this still
will consume more power. One possible solution to this is
to allow the user to decide if the backup interface should
be active at all times or only when the main link is of poor
quality.
The scalability of the architecture is subject to future
study. Load tests will be performed to study the effects of

724

Authorized licensed use limited to: National Ilan Univ.. Downloaded on March 04,2021 at 15:18:07 UTC from IEEE Xplore. Restrictions apply.