Seamless Handoff in Personal Area Networks
UCLA Computer Science Department
CS 218
December 12, 2003
Benjamin Cheung
Duke Nguyen
Abstract
Computer users nowadays demand an internet connection wherever they go. Mobile
applications that are delay sensitive and are run in real-time must also be connected to the
internet constantly. This demand has resulted in the emergence of the seamless handoff
solution. Seamless handoff provides end-to-end IP continuity without failures in the
midst of a download activity due to link outages or handovers. Both horizontal and
vertical handoff architectures are the basis for ensuring this lossless Quality-of-Service
guarantee during a handoff. With the emergence of numerous different technologies
ranging from Bluetooth to 802.11 to 1xRTT, the need to be able to transparently switch
from one technology to the next becomes readily apparent. Furthermore, just as
computers and devices are freed loose from wires by using wireless technologies, an
internet connection should also be free of this restriction and be allowed to roam across
different providers and access points. This paper will present the ideas behind the
handoff solution, as well as provide performance results and analysis from various
handoff scenarios that have been tested using this emerging technology.
Introduction
The internet is ever-changing with new technologies emerging almost daily. People
everyday are finding new ways to connect to the internet, whether it be from their cellular
phone, desktop, or hotel television while on vacation. However, many technologies that
can be used to connect to the internet that exist today are restricted in such a way that one
must be connected to one and only one technology at any given time. It is practically
impossible to be able to have the freedom to roam across different technologies, while at
the same time maintaining a constant internet connection. With so many new and
exciting methods to access the internet and the idea of the world becoming more and
more wireless, shouldn’t it be possible to use more than one technology at the same time,
and for that matter, at any location? Seamless handoff aims to provide the solution to this
problem by allowing a mobile user or application to be constantly connected to the
internet, regardless of physical location or access point availability.
Personal Area Networks
Before delving into the details of seamless handoff, it helps to understand what a personal
area network is. A personal area network (PAN) is a computer network used for
communication among computer devices close to one person. An example of a PAN is a
room full of laptops connected to each other or a PDA connected to a desktop. The
device may or may not belong to the person in question. A key capability for a PAN is to
enable devices to autonomously detect and acquire one another. For example, when
someone enters a room with a PDA, a person using a laptop in that same room should be
able to automatically discover that PDA, and be able to share files with it and perform
other activities.
Wireless PANs can be made possible with network technologies such as IrDA,
Bluetooth, and 802.11. These technologies should allow a person to create an ad-hoc
network by grouping together a series of devices that will allow for communication
between the devices.
The idea behind PANs is important because it raises the issue of the effect on the network
if a device was to leave the network or even when the network as a whole was to move
entirely to a new location. Surely, it would not be ideal for the PAN to have to
disassemble and reconnect. There needs to be a solution that would allow a PAN to
continue operation seamlessly and transparently, such that communication and transfer
activities were lossless and did not cause serious interruptions. This problem gives rise to
the solution provided by a seamless handoff architecture.
Seamless Handoff
Seamless handoff provides end-to-end IP continuity without failures in the midst of a
download activity due to link outages or handovers. What this means is that a user or
application that is connected to a handoff server could seamlessly and transparently
switch back and forth between different internet technologies, without compromising any
communication activity. Seamless handoff ensures successful data transfer even when
the underlying link connections are damaged or disrupted due to device mobility.
Furthermore, it guarantees this lossless Quality-of-Service when a mobile user or
application passes through different alternative technologies.
Seamless Handoff Applications
Seamless handoff can be used in a variety of applications. For example, many consumers
now are able to purchase internet-enabled cellular phones and similar handheld devices.
These devices can be used to transfer video, audio, and other large delay sensitive types
of media. With seamless handoff, the quality of transmission improves considerably.
Music delivery over cellular networks is also possible [2]. A wireless entry point to
music delivery networks (e.g. wireless music portals) may represent an innovative and
value-added service offered by cellular carriers to those mobile customers wishing to use
their 2.5/3G enabled cellular phones for playing out songs, as well as other multimedia
objects [2]. There are many areas where seamless handoff can be applied, with emphasis
in mobile applications that are delay sensitive, run in real-time and must be connected to
the internet constantly.
Goals of Seamless Handoff
The goals of seamless handoff are the following:




Continuous connectivity
Low latency
Minimum packet loss
Minimum infrastructural modifications
The continuous connectivity goal requires that the user or application not be aware of any
interruptions in the connection. To a user downloading a large 30 GB file, the switch
from one technology to the next should be transparent, such that the user is completely
unaware. Furthermore, continuous connectivity should not only ensure that a connection
is established, but also that the best connection is established. Given the choice between
two different methods to be connected to the internet, the seamless handoff architecture
should be able to choose which method will provide the highest throughput and Qualityof-Service, and be able to perform this test and conversion transparently to the user or
application.
Low latency requires that a switch be completed almost instantaneously. Service
interruption should be minimized to provide the illusion of continuous connectivity. In
the event of absolute connection failure, the architecture should attempt to re-connect as
soon as service becomes available.
Packet loss must be avoided in order to ensure the transfer is completed successfully.
During the switching process, packet transfer must be frozen in the session layer to
ensure that packets are not lost if an interruption lasts longer than anticipated. In order to
be transparent to the user or application a lossless Quality-of-Service must be guaranteed
despite device mobility and downtime.
In order for seamless handoff to be successful, it must require minimum infrastructural
modifications. What this means is that seamless handoff should use what exists today
without requiring huge modifications to existing protocols, standards, or technologies.
The architecture for seamless handoff should be able to plug-in and be retrofitted onto
existing networks and internet topologies. Any modification should be transparent to
existing technologies and should be completely independent.
Horizontal and Vertical Handoffs
Seamless handoff is performed in two ways, namely, horizontal and vertical handoffs.
Whether a handoff is deemed horizontal or vertical should be transparent to a user or
application. The goals of seamless handoff remain the same in either case.
A horizontal handoff is a handoff between two network access points that are based on
the same wireless link technology. An example of a horizontal handoff could be when a
user moves out of a network and into a different network all while using the same 802.11
wireless connection. In a horizontal handoff scenario, the connection is disrupted solely
due to device mobility. When a person leaves the Computer Science network and enters
the Electrical Engineering network, the person is performing a horizontal handoff from
one network to the next. The physical location is the primary factor in horizontal
handoffs.
A vertical handoff is a handoff between two network access points that are based on
different wireless technologies. An example of a vertical handoff could be when a user
moves out of a network and into a different network, but switches from 802.11 to 1xRTT
in the process. In a vertical handoff scenario, the connection is disrupted by moving to an
area that is covered by a different wireless technology. Furthermore, when a choice is
made by the seamless handoff server as to which technology to choose based on
throughput and Quality-of-Service, it is considered a vertical handoff, since the choice is
between alternative wireless technologies. When a person is using a laptop with both an
802.11 card and a 1xRTT card, and the handoff server decides to switch from the 1xRTT
interface to the 802.11 interface because of the relative strengths of the signal that is
defined as a vertical handoff. Note that the switch could also be made based on location
as opposed to signal strength or durability. For example, a person could be connected to
the internet using 802.11 while indoors, but when he steps outside he is seamless handed
off to a 1xRTT connection automatically.
The figure below [1] provides a graphical representation of the difference between
horizontal and vertical handoffs:
Figure 1: Horizontal and Vertical Handoffs
There are numerous challenges that arise when dealing with vertical handoffs [1]. First
of all, because there are more devices active at one time, power becomes an issue. Power
drain must be minimized when running multiple active network interfaces.
Measurements of commercially available wireless network interfaces show that keeping
an IBM Infrared and WaveLan RF interface on all of the time consumes approximately
1.5 watts. This power drain is approximately 20% of a total power drain of a typical
laptop computer [1].
In addition to power, the addition of more devices increases network traffic and
bandwidth in the handoff architecture. The handoff server must be aware of the
additional devices causing more messages and packets being sent [1].
Both horizontal and vertical handoffs work together to provide the goals of seamless
handoff. The handoff server is responsible for handling both scenarios with disregard as
to which exact scenario is currently being used. Having the ability to perform both
horizontal and vertical handoffs brings up the issues mentioned previously. The solutions
that can be used to address these issues will obviously have some trade-offs. For
example, in order to have very low latency one may consider using all the interfaces at
once and for every single packet sent into the network [1]. This is a solution, however, it
is a very inefficient one because bandwidth use is large and power is drained.
Example Scenarios
The following provides real-world examples of both horizontal and vertical handoffs and
the applicability of the seamless handoff solution.
Example 1 (Horizontal Handoff):
Joe Shmoe is downloading a large 30 GB video to his laptop in Boelter Hall. Joe’s laptop
is equipped with only a single standard 802.11 wireless card. During the transfer, he
decides to grab lunch in North Campus. He doesn’t want to stop the download, and at the
same time, he doesn’t want to leave his laptop behind for security reasons. What does he
do?
To address this problem, Joe Shmoe connects his laptop to a handoff server using his
802.11 wireless card. Because of the fact that his laptop is now connected the handoff
server, Joe is free to roam across different networks, whether it be the Engineering or
Humanities network. Now, he can bring his laptop with him to North Campus, and the
download will be continuous and it will seem as if Joe never left his desk in Boelter Hall.
How is this done?
The handoff server freezes the download activity at the session layer when horizontal
and/or vertical handoffs are detected. This permits the download to continue as if it were
constantly connected to the Internet, despite roaming across different wireless networks.
The handoff server detects when a connection is damaged and is able to freeze the
transfer so packets are not lost and the continuous connectivity is provided.
Example 2 (Vertical Handoff):
Joe Shmoe decides to upgrade his computer and install a 1xRTT card in the open
PCMCIA slot. Joe is in the Engineering computer lab transferring a large file, when
suddenly his classmates in the lab complain that the wireless connection to the internet is
down! As everyone else begins to panic, Joe continues on as if nothing happened with a
smile on his face as the progress bar on his download continues without hesitation. Why
is Joe smiling?
Joe is smiling because his transfer was completely uninterrupted due to the fact that a
vertical handoff was performed on his behalf when a connection was detected to be
faulty. The handoff server detected that Joe’s 802.11 connection was no longer present,
thus promptly switched his laptop over to use his new 1xRTT connection, without Joe
even knowing. The action was completely transparent to Joe, because the transfer
continued without interruption. In this scenario Joe remained in the same network but
was able to seamless switch from one technology to the next without manually
intervening. The handoff server detected the downtime, froze the download activity at
the session layer, established the connection to the 1xRTT interface, and resumed the
download.
Handoff Diagrams
The following are some diagrams that provide a high-level view of the seamless handoff
architecture and the various scenarios that can be used with it.
Figure 2: Laptop using a Handoff Server as an access point
In Figure 2, a laptop is connected to a handoff server using a virtual private network
(VPN) connection. The handoff server maintains the internet connection, and will be
responsible for providing the laptop with both horizontal and vertical handoffs should the
need arise.
Figure 3: PDA connected to a Laptop via Bluetooth
In Figure 3, a PDA is connected via a Bluetooth adapter to the laptop. The laptop is
connected to a handoff server using a virtual private network (VPN) connection. The
handoff server maintains the internet connection, and will be responsible for providing
the laptop with both horizontal and vertical handoffs should the need arise.
It can be seen that numerous chaining possibilities are possible in the seamless handoff
architecture. The architecture is very flexible since the handoff server provides a
centralized architecture where connecting clients can connect in an ad-hoc manner.
Seamless Handoff Test Scenarios Performance and Analysis
Numerous scenarios were designed to test the performance of the seamless handoff
architecture and to determine if the aforementioned goals were adequately met. The
following 6 scenarios were designed and tested:


Horizontal Handoff
o Static IP -> Dynamic IP (DHCP) using 802.11
o Dynamic IP -> Static IP using 802.11
Vertical Handoff
o
o
o
o
1xRTT -> 802.11
802.11 -> 1xRTT
Wired Ethernet -> Bluetooth
Bluetooth -> Wired Ethernet
The environment for the tests were conducted with a laptop running the Redhat Linux 9
operating system. A single file transfer was initiated using “wget” and the file was a 68
MB file. The command to initiate the transfer of the file was the following:
wget http://download.microsoft.com/download/speechSDK/SDK/5.1/WXP/ENUS/speechsdk51.exe
This file was used in all the test scenarios to test the bandwidth and delay of the
respective interfaces.
Scenario 1 (Horizontal Handoff: Static IP -> Dynamic IP)
This scenario would test the transfer of the file while initially being on a static IP address,
and then switching to a dynamic IP address all while using the 802.11 network. The
following table displays the results:
Still User, 1 interruption, 802.11 static -> dynamic IP different network/subnet (Avg
throughput = 549.39 KB/s), switch at 60s
Trial
Run
Duration (s)
Delay (s) Throughput KB/s
1
123.6
2.6
550.16
2
122.4
2.5
555.56
3
124.5
2.6
546.18
4
121.6
2.7
559.21
5
126.9
2.4
535.86
The throughput remained very high, with the delay of roughly ~2.5s. This delay is
mostly attributed to the fact that DHCP must first search for an IP address. It will be seen
that in the next scenario, where the switch is reversed, the delay is reduced since an IP
address does not need to be searched by DHCP.
Scenario 2 (Horizontal Handoff: Dynamic IP -> Static IP)
Still User, 1 interruption, 802.11 dynamic -> static IP different network/subnet (Avg
throughput = 553.74 KB/s), switch at 60s
Trial
Run
Duration (s)
Delay (s) Throughput KB/s
1
121.9
0.9
557.83
2
120.9
1.1
562.45
3
124.5
1.0
546.18
4
124.6
1.1
545.75
5
122.2
1.1
556.46
In this scenario, the throughput continued to remain high, but notice the reduced delay.
This is attributed to the fact that the switch was performed from a dynamic IP address to
a static IP address. In the earlier scenario, requesting a dynamic IP address entails
issuing a request to the server, and waiting for a reply with a given IP address from the
server. This can cause delays depending on the network.
Scenario 3 (Vertical Handoff: 1xRTT -> 802.11)
Still User, 1 interruption, 1xRTT-> 802.11 different network/subnet (Avg throughput =
291.98 KB/s), switch at 60s
Trial
Run
Duration (s) 1xRTT
Throughput
KB/s
Delay (s)
802.11 Throughput
KB/s
1
181.32
37.21
0.8
542.12
2
180.29
38.21
1.3
546.23
3
178.41
37.65
1.3
555.21
4
179.00
36.11
1.2
553.21
5
182.18
33.89
1.1
539.91
Notice here that the delay is almost negligent because the switch simply requires a
switching of the gateway in the kernel’s IP routing table. Both of the interfaces are
already initiated and connected before the transfer takes place. There is no setup time
required to bring up or bring down an interface. Remember that this may not be an ideal
situation in real-life considering the extra power drain on the laptop as well as the
increase in network traffic that is incurred because of additional devices being active at
the same time. The 1xRTT throughput greatly depends on location and will vary based
on many environmental conditions. We also analyzed the ‘tcpdump’ by listening on both
the ppp0 and eth0 interfaces. The output itself is several pages long, so here is a snippet
of the output:
tcpdump listening on ppp0:
16:47:07.051658 arp who-has 192.168.1.1 tell Accessp12.CS.UCLA.EDU
16:47:07.108029 210.74.232.170.http > 192.168.1.1.1135: P 1:336(335) ack 312 win
65223 (DF)
16:47:07.112505 192.168.1.1.1135 > 210.74.232.170.http: P 312:622(310) ack 336 win
16225 (DF)
16:47:07.217018 ns2.myvzw.com.domain > Cs-33-128.CS.UCLA.EDU.1077: 35117
NXDomain 0/1/0 (110) (DF)
16:47:07.217855 Cs-33-128.CS.UCLA.EDU.1077 > ns2.myvzw.com.domain: 35118+
PTR? 128.33.179.131.in-addr.arpa. (45) (DF)
16:47:07.248772 ns2.myvzw.com.domain > Cs-33-128.CS.UCLA.EDU.1077: 35118
1/4/0 (152) (DF)
16:47:07.249462 Cs-33-128.CS.UCLA.EDU.1077 > ns2.myvzw.com.domain: 35119+
PTR? 7.6.174.66.in-addr.arpa. (41) (DF)
16:47:07.256366 0:4:de:61:6:10 1:0:c:cc:cc:cc 2004 43:
0100 0100 0843 5344 0000 0200 0504 0003
0005 4000 0400 0a00 04de 6106 10
16:47:07.257405 0:4:de:61:6:10 sap 80 > 1:0:c:0:0:0 sap 01 I (s=0,r=0,C) len=68
16:47:07.265740 ns2.myvzw.com.domain > Cs-33-128.CS.UCLA.EDU.1077: 35119*
1/4/4 PTR[|domain] (DF)
16:47:07.266601 Cs-33-128.CS.UCLA.EDU.1077 > ns2.myvzw.com.domain: 35120+
PTR? 4.32.179.131.in-addr.arpa. (43) (DF)
16:47:07.296879 210.74.232.170.http > 192.168.1.1.1135: . 336:1716(1380) ack 622 win
64913 (DF)
16:47:07.298524 210.74.232.170.http > 192.168.1.1.1135: . 1716:3096(1380) ack 622
win 64913 (DF)
16:47:07.300283 210.74.232.170.http > 192.168.1.1.1135: . 3096:4476(1380) ack 622
win 64913 (DF)
16:47:07.300414 192.168.1.1.1135 > 210.74.232.170.http: . ack 3096 win 16560 (DF)
16:47:07.301701 210.74.232.170.http > 192.168.1.1.1135: P 4476:5200(724) ack 622
win 64913 (DF)
16:47:07.302414 ns2.myvzw.com.domain > Cs-33-128.CS.UCLA.EDU.1077: 35120
1/4/0 (150) (DF)
Using the dump, the packet loss and congestion window can be viewed and monitored. It
can be seen that no packets are lost and the congestion window drops to 1 at the
switching point. In this scenario, the throughput for the 802.11 interface continued to
remain high.
Scenario 4 (Vertical Handoff: 802.11 -> 1xRTT)
Still User, 1 interruption, 802.11 -> 1xRTT different network/subnet (Avg throughput =
66.08 KB/s), switch at 60s
Trial
Run
Duration (s) 802.11
Throughput
KB/s
Delay (s)
1xRTT Throughput
KB/s
1
1051.99
544.42
0.7
35.62
2
1182.08
512.26
0.8
33.21
3
1179.32
532.26
0.8
32.22
4
1229.24
522.21
0.8
31.36
5
1092.21
510.22
1.0
36.22
Again, the delay here is almost negligent since both interfaces are active before the file
transfer begins. The minimal delay is crucial to providing a transparent experience to the
user. The following is a snippet of the tcpdump on eth0:
16:47:53.660959 unknown.Level3.net.http > Cs-33-128.CS.UCLA.EDU.1104: .
11690213:11691581(1368) ack 162 win 5792 <nop,nop,timestamp 1318500647 829949>
(DF)
16:47:53.661079 192.168.1.1.1104 > unknown.Level3.net.http: . ack 11691581 win
62928 <nop,nop,timestamp 829962 1318500641> (DF)
16:47:53.664430 unknown.Level3.net.http > 192.168.1.1.1104: .
11691581:11692949(1368) ack 162 win 5792 <nop,nop,timestamp 1318500647 829949>
(DF)
16:47:53.667942 unknown.Level3.net.http > 192.168.1.1.1104: .
11692949:11694317(1368) ack 162 win 5792 <nop,nop,timestamp 1318500656 829949>
(DF)
16:47:53.668087 192.168.1.1.1104 > unknown.Level3.net.http: . ack 11694317 win
62928 <nop,nop,timestamp 829963 1318500647> (DF)
16:47:53.670702 unknown.Level3.net.http > 192.168.1.1.1104: .
11694317:11695685(1368) ack 162 win 5792 <nop,nop,timestamp 1318500656 829949>
(DF)
Scenario 5 (Vertical Handoff: Wired Ethernet -> Bluetooth)
Still User, 1 interruption, Wired Ethernet -> Bluetooth (Avg Throughput = 197 KB/s)
switch at 180s.
Trial
Run
Duration (s) Wired Ethernet Delay (s)
Throughput
KB/s
Bluetooth
Throughput KB/s
1
321.54
342.22
1.1
45.22
2
315.19
343.26
0.9
45.96
3
242.21
362.53
0.8
44.12
4
271.04
355.55
0.9
43.95
5
291.21
348.95
1.2
46.66
Here, Bluetooth maintained a healthy average of about 45 KBps. Again, the delay was
almost negligible because both interfaces were already active.
Scenario 6 (Vertical Handoff: Bluetooth -> Wired Ethernet)
Still User, 1 interruption, Bluetooth -> Wired Ethernet (Avg Throughput = 190 KB/s)
switch at 180s.
Trial
Run
Duration (s) Bluetooth
Throughput
KB/s
Delay (s)
Wired Ethernet
Throughput KB/s
1
358.54
44.16
0.9
336.35
2
359.05
46.96
0.9
332.58
3
356.01
45.32
0.7
339.99
4
353.14
44.48
0.6
346.51
5
369.01
49.56
0.7
312.56
Here again, Bluetooth maintained a healthy average of about 45 KBps. Again, the delay
was almost negligible because both interfaces were already active.
Performance Analysis
From the scenarios that were designed it could be seen that many of the goals of seamless
handoff were adequately met. Handoffs were transparent to the file transfer utility.
Delays were minimal and practically insignificant. The congestion window dropped to 1
when a handoff took place. This is because TCP sensed a disruption and took appropriate
measures. The throughput remained relatively consistent across different interfaces. Of
course, a throughput of ~500 KBps cannot be expected to be had on the Bluetooth
interface. File integrity was also properly maintained. Packets were not lost and the
complete file was successfully transferred.
Conclusion
The scenarios designed were successfully tested to show the capability of seamless
handoff first-hand. Many of the goals of seamless handoff were adequately met. For
example, the delay in the scenarios was for the most part negligent, helping achieve the
goal of continuous connectivity, as well as low latency. Furthermore, the build-out of
each of the scenarios was relatively simple, in that there were no major modifications to
existing technologies. Packet loss as also avoided as evidenced by the complete file
being transferred.
The scenarios provided put the seamless handoff theory into practice and allowed us to
study the results. There is still much room for optimization, such as the power issue that
was discussed earlier when having multiple devices active at all times. Overall, the
seamless handoff architecture has many real-world applications and has potential to be an
architecture that is utilized many wireless infrastructures.
References
[1] Mark Stemm, Randy H. Katz, " Vertical Handoffs in Wireless Overlay Networks,"
Mobile Networks and Applications, 1996,
http://www.cs.ucla.edu/classes/fall03/cs218/paper/stemm96vertical.pdf.
[2] V. Ghini, G. Pau, P. Salomoni, M. Roccetti, M. Gerla, " Smart Download on the Go:
A Wireless Internet Application for Music Distribution over Heterogeneous Networks, "
Submitted to ICC2004, Paris,
http://www.cs.ucla.edu/classes/fall03/cs218/paper/SmartDownload.pdf
[3] R. Hsieh, Zhe Guang Zhou, A. Seneviratne, " S-MIP: a seamless handoff architecture
for mobile IP," In Proceedings of IEEE INFOCOM 2003,
http://www.ieee-infocom.org/2003/papers/43_04.PDF
[4] Pangalos, P.A.; Boukis, K.; Burness, L.; Brookland, A.; Beauchamps, C.; Aghvami,
A.H., " End-to-end SIP based real time application adaptation during unplanned vertical
handovers, " Global Telecommunications Conference, 2001. GLOBECOM '01. IEEE ,
Volume: 6 , 25-29 Nov. 2001 Page(s): 3488 -3493,