Internet Engineering Task Force Muhammad Niswar
Internet Draft Shigeru Kashihara
Expires: June 2010 Kazuya Tsukamoto
Youki Kadobayashi
Suguru Yamaguchi
December 2009
Inter-domain WLAN handover management for Multi-homed Mobile Node
<draft-niswar-wlan-multihomed-handover-00.txt>
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your
rights and restrictions with respect to this document.
Niswar, et al. Expires - June 2010 [Page 1]
<draft-niswar-wlan-multihomed-handover-00.txt> December 2009
Abstract
This document discusses inter-domain WLAN handover management for
multi-homed mobile node (MN) in order to maintain Voice over IP
(VoIP) quality during handover (HO). Switching a communication path
from one Access Point (AP) to another in inter-domain WLANs is a
critical challenge for real-time applications such as VoIP because
communication quality during HO is more likely to be deteriorated. To
maintain VoIP quality during HO, we need to solve many problems. In
particular, in bidirectional communication such as VoIP, an AP
becomes a bottleneck with the increase of VoIP calls. As a result,
packets queued in the AP buffer may experience a large queuing delay
or packet losses due to increase in queue length or buffer overflow,
thereby causing the degradation of VoIP quality for the MNs side. To
avoid this degradation, MNs need to appropriately and autonomously
execute HO in response to the changes in wireless network condition,
i.e., the deterioration of wireless link quality and the congestion
state at the AP. We then propose an HO management considering all of
frame retries, AP queue length, and transmission rate at an MN for
maintaining VoIP quality during HO.
Table of Contents
1.Introduction....................................................3
2.Existing Studies of Handover Strategy...........................3
3.Handover Decision Criterion.....................................5
3.1 Number of RTS Retries......................................5
3.2 AP Queue Length........................................... 6
3.3 Transmission Rate......................................... 6
4.Handover Management for Multi-homed Mobile Node................ 7
4.1 Architecture of Handover Management........................7
4.2 Handover Mechanism.........................................7
4.2.1 Single-Path and Multi-Path Transmission Modes ........7
4.2.2 Dealing with Ping-Pong Effect........................10
4.2.3 Elimination of Redundant Probe Packet................12
4.3 Considered Handover Scenarios............................15
5.Conclusion.................................................... 15
References.......................................................15
Acknowledgments..................................................16
Author's Addresses...............................................16
Niswar, et al. Expires - June 2010 [Page 2]
<draft-niswar-wlan-multihomed-handover-00.txt> December 2009
1. Introduction
Wireless LAN (WLAN, IEEE802.11a/b/g/n) has been the dominant wireless
technology and is extensively deployed today. Meanwhile, there is a
huge demand for Voice over IP (VoIP) service over WLANs. However,
delivering VoIP over WLANs (VoWLANs) has many challenges because VoIP
is a delay and packet loss sensitive application. In some
metropolitan areas, WLANs (Wi-Fi hotspots) have already provided the
broadband Internet connectivity to mobile nodes (MNs) in many
locations. In such an environment, the MNs are likely to traverse
several WLANs with different IP subnets during VoIP calls because the
coverage of an individual WLAN is relatively small. Consequently,
VoWLAN quality could be drastically degraded due to the severe
changes of wireless network condition caused by the movement and
increase of MNs. Therefore, to maintain VoWLAN quality, MNs need to
appropriately and autonomously execute handovers (HOs) in response to
the wireless network condition.
In such a mobile environment, typically, two main factors degrade
VoWLAN quality: (1) degradation of wireless link quality and (2)
congestion at an AP. First, as an MN freely moves across WLANs, the
communication quality degrades due to the fluctuation of wireless
link condition (fading and shadowing). Second, as VoIP is a bi-
directional communication, an access point (AP) becomes a bottleneck
with the increase of VoIP calls. That is, VoIP packets transmiited
from Correspondent Nodes (CNs) to MNs are liable to experience large
queuing delay or packet loss due to increase in queue length or
buffer overflow in the AP buffer because each MN and AP has almost
the same priority level of frame transmission by following the
CSMA/CA scheme. In addition, in multi-rate WLANs, although a rate
adaptation function automatically changes the transmission rate in
response to wireless link condition, a low transmission rate occupies
a larger amount of wireless resources than that of a high
transmission rate. Thus, compared with a high transmission rate, a
low transmission rate tends to cause congestion at an AP. Therefore,
to maintain VoWLAN quality, we propose a new HO strategy method
considering wireless network conditions, i.e., wireless link quality,
AP queue length, and transmission rate.
2. Existing Studies of Handover Strategy
Many HO strategies have been studied for various layers of the
protocol stack where network and transport layers are most widely
studied. Mobile IP [1] is a network layer scheme utilizing and
relying on network infrastructures including Router advertisement,
Home Agent (HA) and Foreign Agent (FA). However, an HO process in
Mobile IP takes a significant time period including the period for
acquisition of the IP address in a new WLAN and registration request
Niswar, et al. Expires - June 2010 [Page 3]
<draft-niswar-wlan-multihomed-handover-00.txt> December 2009
to an HA and a CN. Although FMIPv6 [2] and HMIPv6 [3] have been
proposed to reduce the handover processing period, they are difficult
to deploy in WLANs administrated by different organizations. This is
because they require additional network element such as the HA that
introduce a burdensome administration and require additional cost.
Then, we consider the end-to-end basis approach, which is not
required any change of the existing network infrastructure.
On the transport layer approach, mobile Stream Control Transmission
Protocol (mSCTP) [4], which is a mobility extension of SCTP, has been
proposed. Although mSCTP supports multi-homing and dynamic address
reconfiguration for mobility, the issue of the HO decision is not
discussed in detail. Authors in [5] proposed an SCTP-based HO scheme
for VoIP using a Mean Opinion Score (MOS) [6] as an HO decision
metric. The HO mechanism also employs a probe message called a
heartbeat in order to estimate a Round Trip Time (RTT) and then
calculates MOS value based on the RTT. However, since upper layer
(above layer 3) information such as packet loss, RTT, and MOS
indicate end-to-end communication quality, the information is varied
with the change in condition of both the wireless and wired networks.
Therefore, the existing studies could cause unnecessary HOs due to
temporal congestions in wired networks.
In a mobile environment, MNs need to promptly and reliably detect
wireless link condition. Our practical experiments in [7] proved that
the number of frame retries on the MAC layer has the potential to
detect the wireless link degradation during movement because a packet
over WLAN inevitably experiences frame retries before being treated
as packet loss. Reference [8] proposed an HO mechanism employing the
number of frame retries as an HO decision metric through analytical
study. This method, however, only considers the frame retransmission
caused by the collision with frames transmitted from other MNs in a
non interference environment. On the other hand, we proposed an HO
strategy method considering the number of data frame retries on the
MAC layer [9,10,11] considering in an interference environment through
simulation study. This strategy employs multi-homing enabling to
execute multi-path transmission mode for supporting inter-domain
soft-HO between two WLANs with different IP subnets. However,
although our previous method can detect the degradation of wireless
link condition due to both movement of MN and radio interference, it
cannot detect congestion at both serving AP and target-HO AP.
As a result, in our previous method, an MN could execute an HO to a
congested AP as well as lead to imbalanced traffic load among APs,
thus, VoIP quality would be degraded. We need an HO management
considering congestion of AP and the load balancing among the APs. We
then consider an HO management based on end-to-end basis for real-
time application and the HO management aims no modification of
network infrastructure such as AP.
Niswar, et al. Expires - June 2010 [Page 4]
<draft-niswar-wlan-multihomed-handover-00.txt> December 2009
3. Handover Decision Metrics
We discuss HO decision metrics that can precisely indicate wireless
network condition. In particular, many HO technologies employ the
received signal strength (RSS) on PHY layer as an HO decision metric.
However, our previous research [7] showed that RSS is very difficult
to properly detect deterioration in communication quality because it
fluctuates abruptly due to the increase in the distance and the
existence of interfering objects. It also cannot detect the
degradation due to radio interference. Furthermore, in [7], we showed
that the information on the MAC layer, i.e., frame retry has a
potential to serve as a significant metric. However, it cannot
satisfactorily detect the wireless network condition. In this section,
we then describe the following three HO metrics employed in our new
proposed method.
3.1 Number of RTS Retries
In the IEEE802.11 standard, a sender confirms a successful
transmission by receiving an ACK frame in response to the transmitted
data frame. When a data or ACK frame is lost, the sender periodically
retransmits the same data frame until achieving a successful
transmission or reaching a predetermined retry limit. The standard
supports two retry limits: long-frame and short-frame retry limits.
If Request-to-Send (RTS)/Clear-to-Send (CTS) function is applied, a
long-frame retry limit of four is applied, otherwise, a short-frame
retry limit of seven is applied. When frame retries reach the retry
limit, the sender treats the data frame as a lost packet. That is, we
can detect the occurrence of packet loss in advance by utilizing the
frame retries. Moreover, unlike the RSS, frame retries can promptly
and reliably detect the wireless link degradation due to not only
reduction of signal strength but also radio interference and
collisions [7]. Therefore, frame retry allows an MN to detect
wireless link condition promptly and reliably.
In [9], we employed data frame retry as an HO decision metric in
WLANs with a fixed transmission rate (11 Mb/s). However, in a real
environment, almost all WLANs employ a multi-rate function that can
change the transmission rate according to wireless link condition. If
the transmission rate is dropped by the multi-rate function, a more
robust modulation type is selected and thus data frame retries are
further decreased. As a result, an MN cannot properly detect the
degradation of wireless link quality only from data frame retries in
multi-rate WLANs. Therefore, we consider an RTS frame as an
alternative metric of data frame retries. Note that, as an RTS frame
is always transmitted at the lowest rate (e.g., 6 Mb/s in 802.11a/g
and 1 Mb/s in 802.11b), an MN can appropriately detect the change of
wireless link quality. Moreover, RTS frame is basically employed to
Niswar, et al. Expires - June 2010 [Page 5]
<draft-niswar-wlan-multihomed-handover-00.txt> December 2009
prevent collisions in wireless network due to hidden nodes. However,
according to the IEEE802.11 standard, as RTS threshold is 2347 bytes
by default, thus, RTS is not sent in case of VoIP packet size (160
bytes). Therefore, in our proposal, all MNs must set RTS threshold to
0 in order to enable the MNs send the RTS frame. Furthermore, in our
proposal, RTS retry ratio is employed instead of the frequency of RTS
retries. The RTS retry ratio is calculated as follows:
Number of RTS Frame Retries
RTS Retry Ratio = ---------------------------------
Total Transmitted Frames.
According to our evaluation [12], RTS retry ratio should be kept
under 0.6 to maintain the adequate VoIP quality.
3.2 AP Queue Length
With the increase of VoIP calls in a WLAN, the AP queue length
increases. Then, each packet routed to MN and queued in the AP buffer
may experience a large queuing delay or packet loss due to increase
in queue length or buffer overflow. Consequently, the queuing delay
and the packet loss severely affect the VoIP quality of MNs. However,
the IEEE802.11 (a/b/g/n) standard unfortunately does not provide a
mechanism that can inform MNs of the AP queue length. Therefore, to
maintain VoIP quality, an MN needs to detect the congestion of the AP
by itself. We then propose a method to estimate AP queue length based
on RTT between MN and AP (W-RTT). The MN periodically sends a probe
packet (ICMP message) to an AP and then calculates W-RTT. The W-RTT
increases in response to the increase of AP queuing delay because a
probe response packet experiences queuing delay in the AP buffer.
Therefore, the W-RTT can be used to derive information about AP
queuing delay. According to our evaluation [12], the W-RTT should be
kept under 200 ms to satisfy adequate VoIP quality. Therefore, in our
proposed method, we also employ W-RTT to estimate AP queue length and
set the W-RTT threshold (W-RTT_thr) of 200 ms to maintain the adequate
VoIP quality.
3.3 Transmission Rate
IEEE 802.11 supports a rate adaptation function that can dynamically
and automatically change the transmission rate based on wireless link
condition. In the case where wireless link quality degrades, as the
transmission rate decreases caused by the change of the modulation
type, the wireless resource is more occupied because of the long
transmission delay. As a result, the lower transmission rate is
likely to cause congestion of an AP. Therefore, to alleviate
congestion of an AP, the transmission rate can also be treated as a
potential HO decision metric.
Niswar, et al. Expires - June 2010 [Page 6]
<draft-niswar-wlan-multihomed-handover-00.txt> December 2009
4. Handover Management for Multi-homed Mobile Node
In this section, we describe the details of our proposed HO
management. First, we describe the architecture of HO management and
follow by HO mechanism explaining how HO management switches the
transmission modes based on HO decision metrics. Finally, we describe
three considered HO scenarios for evaluation of our proposed HO
management.
+--------------+
| Application |
+--------------+
| Transport |
| +--------+ |
+----> | HM | <-----+
| +--+--------+--+ |
| | IP | |
| +--------------+ |
+---|MAC| |MAC|----+
+---+ +---+
|PHY| |PHY|
+---+ +---+
WLAN-IF1 WLAN-IF2
Fig.1 Handover Management Architecture
4.1 Architecture of Handover Management
We propose an end-to-end HO management (HM) implemented on transport
layer of MN. The HM controls HO based on the HO decision metrics,
i.e., RTS frame retry, estimation of AP queue length (W-RTT), and
transmission rate, obtained from lower layer through cross layer
approach (as illustrated in Fig.1). Our HO management takes a multi-
homing approach where an MN has two WLAN interfaces (IFs) connected
to two WLANs with different IP subnets.
4.2 Handover Mechanism
4.2.1 Single-Path and Multi-Path Transmission Modes
HM can switch between single-path and multi-path transmission modes
in response to wireless network condition. Single-path transmission
mode means that an MN communicates with the CN using only one IF.
Multi-path transmission, on the other hand, means that an MN sends
duplicated packets to a CN through two IFs. Multi-path transmission
introduce redundant packet transmissions but it is one possible
alternative to supporting soft-HO.
Niswar, et al. Expires - June 2010 [Page 7]
<draft-niswar-wlan-multihomed-handover-00.txt> December 2009
+------------+
+------>|Single-Path |<----------------------+
| +------------+ |
| | | No
| V |
| /--------------------\ /------------------\
| / W-RTT AP1 < W-RTT_thr \ Yes / \
| / && \---> / IF Retry > R_Sthr \
| \ W-RTT AP2 < W-RTT_Thr / \ /
| \ / \ /
| \--------------------/ \------------------ /
| | No | Yes
| +-------- V
| |
| V
| /--------------------\
| = / \ < +--------------------+
| +---- / W-RTT AP1 : W-RTT AP2 \---> | Single-Path to IF1 |
| | \ / +--------------------+
| | \ /
| | \--------------------/
| | | >
| | V
| | +---------------------+
| | | Single-Path to IF2 |
| | +---------------------+
| +---------+
| |
| V
| No /--------------------\ Yes +------------+
+--- / IF Retry > R_Sthr \----->| Multi-Path |
\ / +------------+
\--------------------/
Fig.2 Switching to single/multi-path transmission
Figure 2 shows an algorithm of switching to single/multi-path
transmission when an MN is located in an overlap area of two APs. An
MN associated with two APs (AP1 and AP2) transmits a probe packet at
every 500 ms intervals to estimate AP queue length of each AP. If
both W-RTTs for AP1 and AP2 are below an W-RTT threshold (W-RTT_thr: 200
ms), an MN detects that both APs are not congested. Then, the MN
investigates RTS frame retry ratio of the current active IF. If the
RTS frame retry ratio reaches a retry ratio threshold of single-path
(R_Sthr: 0.6), the HM switches to multi-path mode to investigate
wireless link condition of these two IFs as well as supporting soft-
Niswar, et al. Expires - June 2010 [Page 8]
<draft-niswar-wlan-multihomed-handover-00.txt> December 2009
HO. On the other hand, if the W-RTT of AP1 reaches W-RTT_thr, i.e., AP1
is congested, the MN switches to the AP2 directly without switching
to multi-path mode, thereby avoiding a serious congestion in the AP1.
If both measured W-RTTs reach W-RTT_thr, the MN then investigates the
wireless link condition by using the RTS frame retry ratio of the
current active IF. In a multi-path transmission, to maintain VoIP
quality, the MN sends duplicate data packets through two WLAN IFs,
hence, the MN needs to switch back to single-path transmission as
soon to prevent unnecessary network overload.
+------------+
| Multi-Path |
+------------+
|
V
/---------------------\
/ W-RTT AP1 < W-RTT_thr \ Yes +-----------------------+
/ && \---> | Comparing Retry Ratio |
\ W-RTT AP2 < W-RTT_thr / +-----------------------+
\ /
\---------------------/
| No
V
/------------------- \
/ \ Yes +--------------------+
/ W-RTT AP1 > W-RTT AP2 \---> | Single-Path to IF2 |
\ / +--------------------+
\ /
\--------------------/
| No
V
/--------------------\
/ \ Yes +--------------------+
/ W-RTT AP1 < W-RTT AP2 \---> | Single-Path to IF1 |
\ / +--------------------+
\ /
\--------------------/
| No
V
+-----------------------+
| Comparing Retry Ratio |
+-----------------------+
Fig.3 Switching from multi-path to single-path transmission
As shown in Fig.3, an algorithm of switching from multi-path to
single-path transmission works as follows. First, an MN measures W-
RTTs of both APs. If either of the W-RTTs is below the W-RTT_thr, the MN
Niswar, et al. Expires - June 2010 [Page 9]
<draft-niswar-wlan-multihomed-handover-00.txt> December 2009
switches to an IF with a smaller W-RTT. If both W-RTTs are
simultaneously below the W-RTT_thr, the MN then compares the RTS frame
retry ratio of both IFs. Figure 4 shows an algorithm for the
comparison of the RTS frame retry ratio obtained from both IFs. If
both RTS frame retry ratios of the IFs are equal, the MN continues
multi-path mode. On the other hand, if either of the frame retries is
below the retry threshold of multi-path (R_Mthr: 0.4), the MN
switches to single-path mode through the IF with a small retry ratio.
+----------------------+
|Comparing Retry ratio |
+----------------------+
|
V
/----------------------\ = +------------+
/ IF1 Retry : IF2 Retry \---> | Multi-Path |
\ / +------------+
\----------------------/
< | >
+-----------------------+
| |
V V
No /-----------\ /-------------\ No
+----- / IF1 Retry \ / IF2 Retry \------+
| \ < R_Mthr / \ < R_Mthr / |
| \-----------/ \-------------/ |
V | Yes | Yes V
+------------+ V V +------------+
| Multi-Path |+-------------+ +-------------+| Multi-Path |
+------------+| Single-Path | | Single-Path |+------------+
| to IF1 | | to IF2 |
+-------------+ +-------------+
Fig.4 Handover based on RTS frame retry ratio
4.2.2 Deal with Ping-Pong Effect
If all MNs send probe packets to measure the W-RTT between MN and AP,
the MNs may unfortunately detect congestion of the serving AP
(e.g.,AP1) at nearly the same time. Then, all MNs may switch the
communication to a neighbor AP (e.g., AP2) and leave the AP1
simultaneously. As a result, neighbor AP2's queue length is
drastically increased, and then, all MNs detect the congestion at the
AP2 and switch back to the AP1 again. This phenomena is typically
Niswar, et al. Expires - June 2010 [Page 10]
<draft-niswar-wlan-multihomed-handover-00.txt> December 2009
called ping-pong effect and leads to degradation of VoIP quality due
to fluctuation of both APs queue length.
+-----------------+
+-------------------> | Calculate W-RTT | ARF_thr=0 : 6Mbps
| +-----------------+ ARF_thr=1 : 9Mbps
| | ARF_thr=2 : 12Mbps
| V ARF_thr=3 : 18Mbps
| /-----------------\ ARF_thr=4 : 24Mbps
| +-------------+ No / W-RTT > W-RTT_thr \ ARF_thr=5 : 36Mbps
|--| ARF_thr = 0 |<---\ / ARF_thr=6 : 48Mbps
| +-------------+ \-----------------/ ARF_thr=7 : 54Mbps
| | Yes
| V
| No /-------------------\
|-------------------/ CurrTime - LastTime \
| \ > Time_thr /
| \-------------------/
| | Yes
| V
| +---------------------+
| | LastTime = CurrTime |
| +---------------------+
| | Yes
| V
| /-------------------\ Yes +-------------+
| / Transmission Rate \---->| Handover to |
| \ <= ARF_thr / | another AP |
| \-------------------/ +-------------+
| | No |
| V |
| +------------+ |
+------------------------| ARF_thr ++ |<-----------------+
+------------+
Fig.5 Handover based on transmission rate
To avoid the ping-pong effect, we extend the mechanism where all MNs
first examine their own current transmission rate before executing HO.
Fig. 5 shows an algorithm of HO based on transmission rate. A WLAN
provides a multi-rate function that can change the transmission rate
dynamically based on wireless link condition. As mentioned earlier,
since an MN with lower transmission rate occupies more wireless
resources, the MN is liable to lead to congestion of an AP. Moreover,
as MNs with the lowest transmission rate typically are far away from
the connected AP, that is, near the edge of its coverage, they have
to execute handover as soon as possible to maintain their
communication quality. Therefore, in the proposed scheme, MNs with
Niswar, et al. Expires - June 2010 [Page 11]
<draft-niswar-wlan-multihomed-handover-00.txt> December 2009
the lowest transmission rate (6 Mb/s) first execute HO. Then, if the
AP queue length is still high even after Time_thr (CurrTime - LastT
ime) of 2 seconds expires, MNs with the next lowest transmission rate
(9 Mb/s) starts to execute HOs. Note that an MN does not need to know
the transmission rate of other MNs because we assume that every MN
automatically follows this algorithm to deal with the issue of
synchronization of all MNs transmission rates.
+------------------+
+-------------------->| Captured Packet |<-------------------------+
| +------------------+ |
| | |
| V |
| /------------------\ No |
| / ProbePktSize == \------------------------|
| \ CapturedPktSize / |
| \------------------/ |
| | Yes |
| V |
| +-----------------+ |
| | ProbeLastTime = | |
| | CurrTime | |
| +-----------------+ |
| | |
| V |
| Yes /----------------\ No |
| +---------/ Probe Reply ? \---------+ |
| | \ / | |
| | \----------------/ V |
| +------------------+ +-----------------+ |
| | ProbeReplyTime = | | ProbeReqTime = |-------+
| | CurrTime | | CurrTime |
| +------------------+ +-----------------+
| |
| V
| +-------------------------------+
+--| W-RTT = |
| ProbeReplyTime - ProbeReqTime |
+-------------------------------+
Fig.6 Calculate W-RTT from existing probe packet
4.2.3 Elimination of Redundant Probe Packet
If every MN measures W-RTT by using probe packets, these probe packets
may aggravate congestion in a WLAN. To eliminate the redundant probe
packets, we also extend the HO mechanism, in which one representative
MN sends a probe packet to the AP and all MNs including the
Niswar, et al. Expires - June 2010 [Page 12]
<draft-niswar-wlan-multihomed-handover-00.txt> December 2009
representative MN measure W-RTT by capturing the probe request and
probe reply packets.
This method works as follows (see Fig. 6). Each MN first monitors all
packets over a wireless link before sending a probe packet. If it
finds a probe packet sent by another MN, it cancels sending a probe
packet and measures W-RTT by using the probe request and probe reply
packet sent by another MN and AP. As each MN captures the header of
all received packets, it can identify whether a captured packet is a
probe request/reply packets or not by observing the frame length of
the ICMP message (64 bytes). Furthermore, an MN can also identify
whether a probe packet is for request (ICMP Request) or for reply
(ICMP Response) by observing the MAC address of the probe packet.
More specifically, because all MNs connected to an AP can identify
the MAC address of the AP, each MN can judge the packet as a probe
request packet transmitted from another MN when destination MAC
address of the captured packet is that of the AP. On the other hand,
if the source MAC address is an AP's one, then each MN judges the
packet as a probe reply packet transmitted from the AP.
In Fig.6, probeReqTime and probeReplyTime indicate the receiving time
of the probe request (transmitted from another MN) and the probe
reply (transmitted from the AP), respectively. As every MN can
identify whether a captured packet is a probe request or probe reply,
it can calculate the W-RTT (probeReqTime - probeReplyTime) properly.
This method can eliminate the redundant probe packets because only
one representative MN sends probe packets and all MNs measure the W-RTT
by capturing existing probe packets over a wireless link.
If the representative MN leaves a WLAN, one of the remaining MNs
needs to start periodical transmission of probe packets as a next
representative MN. Here, we describe how an MN obtains the right to
send probe packets in Fig.7. First, all MNs always examine the
difference between the last receiving time of a probe packet
(ProbeLastTime) and the current time (CurrTime).If the difference is
greater than probeAbsenceTime, that is, a probe packet cannot be
captured for a while, First, MNs with the lowest transmission rate in
a WLAN try to send a probe packet. This is because a probe packet
sent at the lowest transmission rate can be captured by almost all
MNs in a WLAN due to its inherently longer transmission range. The
timing to send a probe packet among MNs is determined based on
WaitingTime. Basically, an MN with the smallest WaitingTime, will be
a representative MN because WaitingTime is calculated based on
datarate_Weight, which indicates its weight of transmission rate (see
Fig 7). Thus, if the datarate_Weight is lower, then WaitingTime gets
small. If several MNs with the same transmission rate exist, then
random value in WaitingTime helps to distinguish who will be the
representative MN among them.
Niswar, et al. Expires - June 2010 [Page 13]
<draft-niswar-wlan-multihomed-handover-00.txt> December 2009
+----------------------+
+---------------------> | Waiting for ProbePkt |<------------------+
| +----------------------+ |
| | |
| V |
| No /----------------------\ |
+----------------------/CurrTime - ProbeLastTime\ |
\ > ProbeAbsenceTime / |
\----------------------/ |
| Yes |
V |
+--------------------------------------+ |
| WaitingTime = | |
| datarate_Weight x probeInterval/10 + | |
| random[0,problemInterval/10] | |
+--------------------------------------+ |
| Yes |
V |
+--------------------------+ |
| SendFirstTime = CurrTime | |
+--------------------------+ |
| Yes |
V |
/-----------------------\ No |
/CurrTime - SendFirstTime \-----------------+
\ > WaitingTime /
\-----------------------/
| Yes
V
+-------------------+
| Send ProbePkt |
+-------------------+
datarate_Weight=0 : 6Mbps
datarate_Weight=1 : 9Mbps
datarate_Weight=2 : 12Mbps
datarate_Weight=3 : 18Mbps
datarate_Weight=4 : 24Mbps
datarate_Weight=5 : 36Mbps
datarate_Weight=6 : 48Mbps
datarate_Weight=7 : 54Mbps
Fig.7 Obtaining a right to send the probe packet
Niswar, et al. Expires - June 2010 [Page 14]
<draft-niswar-wlan-multihomed-handover-00.txt> December 2009
4.3 Considered Handover Scenarios
We have evaluated the effectiveness of our proposed HO management
through simulation study. We conducted simulation experiments in
three simulation scenarios.
First, an MN with two WLAN IFs moves from AP1 to AP2 at the speed of
1 m/s. AP2 is assumed to be congested due to existence of fixed 15
MNs establishing VoIP calls. This scenario aims to validate whether
MN can detect the congestion in AP2 and avoid to HO to AP2.
Second, 20 MNs are randomly located within an overlap area between
AP1 and AP2. This scenario aims to validate whether MN can select the
best AP based on W-RTT and transmission rate as well as avoiding ping-
pong effect.
Third, the 15 MNs randomly move between two AP coverage areas at a
speed of 1 m/s. This scenario aims to validate whether MN can select
the best AP based on W-RTT and transmission rate and maintain VoIP
quality when MN randomly moves between two APs.
Our proposed HO management can maintain VoIP quality when those
scenarios are applied. Reference [12] presents the detail of
simulation results.
5. Conclusion
In this document, we proposed an MN-centric HO management considering
estimation of AP queue length to detect the congestion at the AP and
exploiting RTS frame retry and transmission rate of MN to detect the
deterioration of wireless communication quality due to the movement
of the MN. According to simulation study [12], we have demonstrated
that our proposed HO management can maintain VoIP quality during HO.
References
[1] C. Perkins (Ed.), "IP Mobility Support for IPv4," IETF RFC3344,
Aug. 2002.
[2] R. Koodli, "Fast Handovers for Mobile IPv6, " IETF RFC4068, Jul.
2005.
[3] H. Soliman et al., "Hierarchical Mobile IPv6 Mobility Management
(HMIPv6)," IETF RFC4140, Aug. 2005.
[4] S. J. Koh et al., "Mobile SCTP for Transport Layer Mobility,"
draft-reigel-sjkoh-sctp-mobility-05.txt, Internet draft, IETF,
Jul. 2005.
[5]John Fitzpatrick et al., "An Approach to Transport Layer Handover
of VoIP over WLAN," Proc. of IEEE CCNC, Jan.2006.
[6] ITU-T:"G.107", http://www.itu.int/rec/T-REC-G.107/en.
Niswar, et al. Expires - June 2010 [Page 15]
<draft-niswar-wlan-multihomed-handover-00.txt> December 2009
[7] K. Tsukamoto, et al., "Experimental Evaluation of Decision
Criteria for WLAN handover: Signal Strength and Frame
Retransmission," IEICE Trans. on Communications, Vol.E90-B, No.
12, pp. 3579-3590, Dec. 2007.
[8] H. Velayos and G. Karlsson, "Techniques to reduce the IEEE802.11b
handover time," Proc. of IEEE ICC, vol. 7, pp. 3844-3848, Jun.
2004.
[9] S. Kashihara and Y. Oie, "Handover Management based on the number
of data frame retransmissions for VoWLAN," Elsevier Computer
Communications, vol. 30, no. 17, pp.3257-3269, Nov. 2007.
[10] S. Kashihara et al.,"Service-oriented mobility management
architecture for seamless handover in ubiquitous networks," IEEE
Wireless Communications, Vol. 14, No. 2, pp. 28-34, Apr. 2007.
[11] Y. Taenaka, et al.,"Design and Implementation of Cross-layer
Architecture for Seamless VoIP Handover," Proc. Of IEEE MHWMN,
Oct. 2007.
[12] M. Niswar, et al., "Handover Management for VoWLAN based on
Estimation of AP Queue Length and Frame Retries,EIEICE Trans. on
Information and System, Vol.E92-D, No. 10, pp. 1847-1856, Dec.
2009.
Acknowledgments
This work was supported by the Kinki Mobile Radio Centre Inc., and
the Japan Society for the Promotion of Science, Grant-in-Aid for
Young Scientists (B)
Author's Addresses
Muhammad Niswar
Graduate School of Information Science,
Nara Institute of Science and Technology (NAIST)
8916-5 Takayama, Ikoma, 630-0192, Japan
Phone: +81-743-72-5216
Email: <niswar-m@is.naist.jp>
Shigeru Kashihara
Graduate School of Information Science,
Nara Institute of Science and Technology (NAIST)
8916-5 Takayama, Ikoma, 630-0192, Japan
Phone: +81-743-72-5216
Email: shigeru@is.naist.jp
<Niswar, et al.> Expires - June 2010 [Page 16]
<draft-niswar-wlan-multihomed-handover-00.txt> December 2009
Kazuya Tsukamoto
Department of Computer Science and Electronics,
Kyushu Institute of Technology (KIT)
Kawazu 680-4, Iizuka, 820-8502, Japan
Phone: +81-948-29-7687
Email: tsukamoto@cse.kyutech.ac.jp
Youki Kadobayashi
Graduate School of Information Science,
Nara Institute of Science and Technology (NAIST)
8916-5 Takayama, Ikoma, 630-0192, Japan
Phone: +81-743-72-5216
Email: youki-k@is.naist.jp
Suguru Yamaguchi
Graduate School of Information Science,
Nara Institute of Science and Technology (NAIST)
8916-5 Takayama, Ikoma, 630-0192, Japan
Phone: +81-743-72-5216
Email: suguru@is.naist.jp
Niswar, et al. Expires - June 2010 [Page 17]