Internet Engineering Task Force Shigeru Kashihara
Internet Draft Yuzo Taenaka
Expires: May 14, 2008 Kazuya Tsukamoto
Youki Kadobayashi
Suguru Yamaguchi
Yuji Oie
November 12, 2007
Handover management scheme for different IP WLAN subnets
<draft-shigeru-wlan-handover-management-00.txt>
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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 May 14, 2008.
Abstract
This document discusses handover management scheme for WLAN handover
across different IP subnets. To achieve seamless handover, the
following three requirements should be satisfied. (I) prompt and
reliable detection of degradation in wireless link quality,
(II) elimination of handover processing delay on layer 2 and 3,
(III) selection of a better WLAN. We then describe our proposed
handover management scheme satisfying these requirements, and
explain an architecture design and implementation for our proposed
scheme.
Kashihara, et al. Expires: May 14, 2008 [Page 1]
draft-shigeru-wlan-handover-management-00.txt November 2007
Table of Contents
1. Introduction....................................................2
2. Concept of handover management scheme...........................3
3. WLAN handover trigger: the number of frame retransmissions......4
3.1 Handover trigger on upper and lower layers..................4
3.2 Frame retransmission mechanism of IEEE 802.11...............5
3.3 Advantages of frame retransmissions.........................5
3.4 Disadvantages of frame retransmissions......................6
3.5 Consideration...............................................6
4. Handover management scheme based on the number of frame
retransmissions.................................................7
4.1 Proposed method.............................................7
4.2 Architecture design.........................................8
4.3 Implementation.............................................10
5. Conclusion.....................................................14
6. Acknowledgements...............................................15
7. References.....................................................15
8. Author's Addresses.............................................16
1. Introduction
Wireless LANs (WLANs) based on the IEEE 802.11 specifications [1]
are spreading widely due to their low cost, simplicity of
installation and broadband connectivity. WLANs are being set up not
only in private spaces such as the home and workplace, but also in
public spaces such as waiting areas and coffee shops as hotspots.
As a result, WLANs that are independently managed by different IP
subnets (e.g., ISP and FON[2]) are starting to complementarily cover
wide areas such an entire city. In the near future, WLANs will
continue to spread until they overlap to provide continuous coverage
over a wide area, and they will then be the underlying basis of
ubiquitous networks.
In ubiquitous networks consisting of such WLANs (ubiquitous WLANs),
mobile nodes (MNs) can access the Internet through access points
(APs) at any location. MNs are very likely to traverse multiple
WLANs divided into different IP subnets during communications,
because the coverage of an individual WLAN is relatively small.
As a result, the communication is disconnected due to the change in
IP address of the MN required for handover.
To achieve continuous communication during handover, many mobility
management schemes such as Mobile IP [3,4], mobile Stream Control
Transmission Protocol (mSCTP) [5], and others [6,7,8] have been
proposed. These schemes principally employ handover trigger based
on signal strength. However, in ubiquitous WLANs, the communication
quality is often degraded due to both (i) reduction of signal
strength due to the MN's movement and intervening objects and (ii)
radio interference with other WLANs. Acutally, in [9], we showed
that the handover trigger results in the degradation of
communication quality in ubiquitous WLANs., Then, we proposed the
Kashihara, et al. Expires: May 14, 2008 [Page 2]
draft-shigeru-wlan-handover-management-00.txt November 2007
number of frame retransmissions as a new handover trigger. In this
article, we focus on an architecture design and implementation for
seamless handover. We first describe our concept of handover
management scheme, explain the advantage and disadvantage of our new
handover trigger, and propose our handover management scheme using
frame retransmissions. Finally, we show our architecture design and
implementation for our proposed method.
2. Concept of handover management scheme
To achieve seamless handover in ubiquitous WLANs, the following
three requirements should be satisfied. (I) prompt and reliable
detection of degradation in wireless link quality, (II) elimination
of handover processing delay on layer 2 and 3, (III) selection of a
better WLAN.
As described in Section 1, MNs will freely move between WLANs with
different IP subnets. In such a wireless environment, wireless link
quality frequently fluctuates according to the change in time and
spaces. As a result, the degradation of wireless link quality
directly leads to that of an application quality. Particularly, in
real-time application such as voice over IP (VoIP), the detection
delay for the degradation of wireless link quality causes serious
degradation of application quality. Therefore, to achieve (I), an
MN needs to promptly and reliably detect the degradation of wireless
link quality.
Next, when an MN with single WLAN interface moves between different
IP WLAN subnets, the MN invariably experiences a period during which
it is unable to send and receive packets due to both link-switching
delays and IP protocol operations. The necessary process for
handover between different IP WLAN subnets is as follows: (1)
channel scan to search for a new access point (AP); (2) association
with the new AP; (3) acquisition of an IP address in the new WLAN;
and (4) notification of the new IP address to a corresponding node
(CN). These handover processes can be divided into two parts: a
layer 2 handover process (1,2) and a layer 3 handover process (3,4).
In an empirical study, Mishra et al. [10], reported that the layer 2
handover period is 50-400 ms. In addition, considering acquisition
of an IP address from DHCP (300ms [12]) and notification of the new
IP address to CN (one-way delay) during layer 3 handover, it is
clear that the disruption period caused by layer 2 and 3 handover
processes severely impacts the communication quality of real-time
application. Therefore, in (2), it is essential to remove the
disruption period in handover.
In ubiquitous WLANs, an MN needs to execute handover to a better AP.
However, as the MN freely moves between WLANs with relatively small
coverage, the link quality of WLAN frequently fluctuates.
Therefore, in (3), an MN needs to select a better AP than the
current AP at handover according to wireless link quality.
Kashihara, et al. Expires: May 14, 2008 [Page 3]
draft-shigeru-wlan-handover-management-00.txt November 2007
3. WLAN handover trigger: the number of frame retransmissions
Handover triggers employed by existing mobility management
technologies can be classified by the information measured on
upper/lower layers. An upper layer is Layer 3 or above, and a lower
layer is Layer 2 or below. In [9], we investigated the impact of
existing handover triggers on communication quality at handover
initiation. From the results, we showed that the number of frame
retransmissions is appropriate as a new handover trigger to reliably
and promptly detect degradation of communication quality due to both
(i) reduction of signal strength and (ii) radio interference. In
this section, we clarify characteristics of the existing handover
triggers on upper/lower layers, and explain the advantage and the
disadvantage of our proposed handover trigger.
3.1 Handover triggers on upper and lower layers
Packet loss (including data/signaling packets) and RTT are commonly
employed as a handover trigger in existing handover technologies
[3,4,7,8,12]. In [9], through simulation and empirical experiments,
we showed that the communication quality has already been degraded
even when an MN starts the handover process just after detecting the
occurrence of a packet loss or an increase of RTT. In a WLAN,
communication quality is degraded due to deterioration in the
wireless link condition even if packet loss does not occur or RTT
does not seriously increase. Therefore, these handover triggers on
upper layers cannot detect abrupt fluctuations of wireless link
condition reliably and promptly. To avoid degradation of
communication quality at handover initiation, it is essential to
promptly and reliably detect deterioration in the wireless link
condition.
Wireless signal strength is principally considered as a handover
trigger on lower layers [5,13]. Signal strength can be employed as
the information about a wireless link condition directly obtained
from the physical layer. However, properly detecting deterioration
in communication quality caused by fluctuations of signal strength
is very difficult for an MN, because the signal strength may
fluctuate abruptly due to the distance from an AP and any
interfering objects located between the MN and the AP.
Furthermore, in ubiquitous WLANs, degradation of communication
quality due to radio interference is common. However, MNs cannot
detect this type of degradation by assessing the signal strength.
Thus, to maintain communication quality during handover, an MN
should be able to promptly and reliably detect both the reduction of
signal strength and the radio interference.
In addition, it is very difficult for signal strength to set a
threshold for a handover trigger, because the allowable range of
signal strength (Received Signal Strength Indicator: RSSI) depends
on each vendor, e.g., Cisco chooses 100 as RSSI-max while the
Kashihara, et al. Expires: May 14, 2008 [Page 4]
draft-shigeru-wlan-handover-management-00.txt November 2007
Atheros chipset chooses 60 [14]. Therefore, monitoring signal
strength is insufficient to avoid degradation in communication
quality at handover initiation. From above reasons, we proposed the
number of frame retransmissions as a new handover trigger.
3.2 Frame retransmission mechanism of IEEE 802.11
We will outline the frame retransmission mechanism of IEEE 802.11.
In the IEEE 802.11 specifications [1], when a data or an ACK frame
is lost over a WLAN, the sender (e.g., an MN) retransmits the same
data frame to the receiver (e.g., an AP) until the number of frame
retransmissions reaches a predetermined retry limit. If RTS
(Request To Send)/CTS (Clear To Send) is applied, the retry limit is
set to four; otherwise, it is seven. In fact, these values actually
depend on each vendor. Therefore, a data frame can be retransmitted
a maximum of four or seven times (the initial transmission and
three/six retransmissions), if necessary. If the MN does not
receive an ACK frame within the retry limit, it treats the data
frame as a lost packet. In addition, RTT increases due to
retransmissions over a WLAN. Therefore, we can see that a data
frame inherently experiences retransmissions over a WLAN before the
occurrence of packet loss or the increase of RTT, irrespective of
the RTS/CTS.
3.3 Advantages of frame retransmissions
Use of the number of frame retransmissions has the following three
advantages: (i) detection of signal strength reduction, (ii)
collision detection due to radio interference, and (iii) ease of
setting of the threshold triggering the handover processes. First,
when an MN moves during communication, the wireless link condition
is degraded due to the distance from the AP and any interfering
objects located between the MN and the AP. As described in
Section 3.2, a data frame will experience retransmissions due to the
degradation of the wireless link condition before the occurrence of
packet loss or the increase of RTT. Thus, if the number of frame
retransmissions is used as a handover trigger, the MN can detect the
degradation of wireless link condition due to its own movement and
intervening objects before the communication quality is actually
degraded.
Next, in radio interference environments, the number of frame
retransmissions has another advantage that the signal strength
criterion can never imitate. For instance, with signal strength,
the MN cannot detect the degradation of the communication quality
due to the radio interference, because signal strength is not
influenced by radio interference at all. However, in radio
interference environments, frame retransmissions frequently occur
due to collisions between transmitted frames. As a result, the
communication quality is degraded. Therefore, using the number of
frame retransmissions, the MN can detect degradation of
communication quality due to radio interference.
Kashihara, et al. Expires: May 14, 2008 [Page 5]
draft-shigeru-wlan-handover-management-00.txt November 2007
Lastly, ease of determination of the threshold triggering the
handover processes should be noted here. As mentioned earlier,
signal strength is measured in different ways by each vendor, so
that it is necessary to set a different suitable threshold for each
WLAN card. The determination of an appropriate threshold, thus,
depends upon vendors' implementation. On the other hand, as frame
retransmissions can be handled in the same manner in all WLAN cards,
we can set the same threshold for every WLAN card, unlike the signal
strength. In addition, we can simply set the threshold by plain
numbers (e.g., 1, 2, 3,..., n).
3.4 Disadvantages of frame retransmissions
Although we described the advantages of the number of frame
retransmissions in the previous section, it also has some
disadvantages. These disadvantages are as follows. An MN cannot
detect change in wireless link condition without transmission of
data frames, and then cross-layer architecture is indispensable to
notify the existing mobility management technologies on upper layers
of the number of frame retransmissions.
First, the number of frame retransmissions cannot be measured until
data frames are sent. For instance, the MN cannot estimate the
wireless link condition of a new AP by the number of frame
retransmissions before associating with the new AP. In this case,
another criterion, e.g., signal strength, is necessary to estimate
the wireless link condition. Therefore, an MN needs to utilize
signal strength to roughly detect wireless link quality when it has
no transmission data. Next, to introduce this heuristic into the
existing mobility management technologies, as the information held
in each layer cannot be accessed from different layers due to the
concept of the traditional layered architecture, a cross-layer
architecture is necessary for achieving accessibility from different
layers.
3.5 Consideration
The number of frame retransmissions has a potential to properly
indicate wireless link condition influenced by signal strength
reduction or radio interference. However, it is still insufficient
to achieve a seamless handover. Common WLANs employ a function of
auto rate fallback (ARF). A method of ARF is not specified in [1],
and its implementation way depends on vendors. When frame
retransmissions occur, a sender decreases the transfer speed of WLAN
to adapt the change in the communication quality, thereby preventing
the frame retransmissions. As a result, when the number of frame
retransmissions becomes large, the transfer speed has already been
the lowest value, e.g., 1 Mb/s in 802.11b, at starting a handover.
In non real-time applications, the degradation in communication
quality, i.e., throughput, becomes significant problem. Therefore,
to maintain the communication quality, the transfer speed controlled
Kashihara, et al. Expires: May 14, 2008 [Page 6]
draft-shigeru-wlan-handover-management-00.txt November 2007
by ARF is also necessary to be considered with the number of frame
retransmissions.
In WLANs, MNs share the common wireless media. When many MNs exist
in a WLAN, waiting time to send frames in the WLAN becomes larger.
In real-time applications, such as VoIP, an application layer passes
data packets to a WLAN interface at fixed rate. At this time, when
the sending speed of application is faster than waiting time to send
frames, the queue length of a WLAN interface buffer increases. As a
result, as RTT or jitter becomes large, communication quality may
not be maintained. Therefore, the queue length of interface buffer
is also useful information as an additional indicator to maintain
communication quality in real-time applications.
4. Handover management scheme based on the number of frame
retransmissions
In [15, 16], we proposed a handover management scheme based on the
number of frame retransmissions. We then implemented our handover
management scheme using the number of frame retransmissions on Linux
Kernel [17,18]. In Section 4.1, we briefly introduce our handover
management mechanism using the number of frame retransmissions. We
then describe our architecture design and implementation for our
handover management scheme in Section 4.2 and 4.3, respectively.
4.1 Proposed method
Our handover management scheme takes a multi-homing and a
cross-layer approach in which the transport layer uses Layer 2
information (i.e., the number of frame retransmissions). In our
proposed scheme, an MN has two WLAN interfaces, and the handover
manager (HM) on transport layer controls the handover process
considering the number of frame retransmissions. As illustrated in
Fig.1, we assume that an MN with two WLAN interfaces (IF1, IF2)
connects with two different IP WLAN carriers (AP1, AP2), and
initially communicates with the CN through IF1.
In our proposed scheme, an MN can flexibly select an better WLAN
considering the wireless link condition. We outline the operation
of handover management scheme. The MN associates with two APs by
using two WLAN interfaces before handover in advance, i.e., the MN
has two different IP addresses. When the wireless link condition of
AP1 through IF1 is getting worse, the HM switches to multi-path
transmission to prevent packet loss during handover and to
investigate the condition of another wireless link (AP2). However,
the HM should return to single-path transmission on a stable
wireless link as quick as possible, because the network load is
doubled by multi-path transmission in which the same data are sent
through both interfaces. Therefore, in multi-path transmission, if
the condition of either wireless link is getting better, the HM
immediately returns to single-path transmission through the WLAN
Kashihara, et al. Expires: May 14, 2008 [Page 7]
draft-shigeru-wlan-handover-management-00.txt November 2007
interface with good condition. In our scheme, we employ the number
of retransmissions to detect the change in a wireless link condition.
The MAC layer on each interface informs the HM of the number of
frame retransmissions, and the HM determines the wireless link
condition for each interface from this number. In this way, the HM
selects either single-path or multi-path transmission based on the
wireless link condition, i.e., the number of frame retransmissions.
As a result, the HM can maintain communication quality while
properly switching between single-path and multi-path transmission
during handover. See reference [15] about detail evaluation.
+----+
+----- wired -----| CN |
| +----+
+------------+
+--| Internet |--+
| +------------+ |
| |
+-----+ +-----+
| AP1 | | AP2 |
+-----+ +-----+
/ \ / \
/ \ / \
/ \ / \
| |
+|--|+
| MN | - - - - - - >
+----+
Fig.1: Outline of WLAN handover
4.2 Architecture design
In our proposed method, the handover manager (HM) on transport layer
controls handovers according to the number of frame retransmissions.
That is, the key concept of the proposed method is a cross-layer
architecture to pass information obtained on one layer to another
layer. In this section, we explain how to pass the information on
the MAC layer to an HM on the transport layer.
In our architecture design, we employ a shared memory to store the
information from MAC layer. As illustrated in Fig.2, the MAC layer
writes the number of frame retransmissions in the shared memory, and
the HM reads the information from the shared memory. That is, the
MAC layer asynchronously passes the information to the HM through
the shared memory. If the MAC layer passes the information to the
HM directly, the kernel performance is severely degraded due to
frequent interruption. Therefore, a shared memory can be used to
avoid degradation of the kernel performance.
Kashihara, et al. Expires: May 14, 2008 [Page 8]
draft-shigeru-wlan-handover-management-00.txt November 2007
[User Land] VoIP application
|
-----------------------------|----------------------------------
[Kernel Land] V
+-----------------------+
Transport Layer | UDP |
| | |
| V |
+---| Handover Manager (HM) |---+
| +-----------------------+ |
| | |
| | READ |
V V V
+-----------+ +---------------+ +-----------+
| IP Layer | | Shared Memory | | IP Layer |
+-----------+ +---------------+ +-----------+
| LLC Layer | A A | LLC Layer |
+-----------+ | | +-----------+
| MAC Layer |-------+ +-------| MAC Layer |
+-----------+ WRITE WRITE +-----------+
| PHY Layer | | PHY Layer |
+-----------+ +-----------+
WLAN 1 WLAN 2
Fig.2: Design of cross-layer architecture
Fig.3 illustrates the structure of a shared memory. The shared
memory consists of the following four regions: (1) index region,
(2) retry count region, (3) packet loss region, and (4) received
signal strength indicator (RSSI) region. Whenever a data frame is a
successfully transmitted, i.e., whenever an MN receives an ACK
frame, the WLAN driver writes the number of frame retransmissions in
(2) retry count region. The retry count region consists of an array
of size 100 and is allocated to save the number of frame
retransmissions. The WLAN driver then writes the array number and
the value of RSSI in (1) index region and (4) RSSI region,
respectively. If the number of frame retransmissions exceeds the
retry limit, the data frame is treated as a lost packet. Then,
seven is set to (2) retry count region, and the value of (3) packet
loss region is increased by one. When a frame transmission is
finished, the WLAN driver writes the information into the shared
memory. Note that (3) and (4) are used for a log. This cross-layer
architecture exploiting the shared memory is one approach to share
the information between different layers.
Kashihara, et al. Expires: May 14, 2008 [Page 9]
draft-shigeru-wlan-handover-management-00.txt November 2007
0 7 8 F
0x000h+--------------------------------+
| (1) index |
| |
0x004h+--------------------------------+
| (2) retry count |
| array of 100 |
0x008h+--------------------------------+
| ........... |
| |
+--------------------------------+
| Reserved |
| |
+--------------------------------+
| (3) packet loss |
| |
+---------------+----------------+
| (4) RSSI | Reserved |
+--------------------------------+
| Reserved |
0x200h+--------------------------------+
Fig.3: Structure of shared memory
4.3 Implementation
In our proposed scheme, an MN achieves a seamless handover while
switching multi-path or single-path transmissions according to the
number of frame retransmissions. An MN usually communicates through
single-path transmission. However, if the number of frame
retransmissions exceeds the Multi-Path Threshold (MPT) in an HM, an
HM switches to multi-path transmission in order to prevent packet
loss and to investigate each wireless link condition. In multi-path
transmission, an MN sends the same packets through two WLANs
simultaneously.
Here, to implement our proposed method, we employ MONA [19] as a
base architecture, enabling it to handle multiple IP addresses at
end nodes (the MN and the CN). The MONA can prevent a communication
termination due to handover between WLANs with different IP subnets.
Note that, the MONA is implemented between IP layer and Transport
layer in both the MN and the CN, and is therefore called Layer 3.5.
In the MONA, an additional header (basic/optional header) is
inserted between IP header and TCP header: The basic header is used
to handle multiple IP addresses, and the optional header is used to
adapt the dynamic events. For example, when an IP address is added
or deleted, address information is recorded in the optional header
and exchanged between end nodes. In this way, location management
can be achieved. In addition to this, we utilize both Multi-Path
(MP) flag and interface flag that are included in the basic header
in order to control bi-directional path switching. If the MN sets
the MP flag based on the wireless link quality, data transmission is
Kashihara, et al. Expires: May 14, 2008 [Page 10]
draft-shigeru-wlan-handover-management-00.txt November 2007
performed through both interfaces, that is, by multi-path
transmission. From the MP flag, the CN can detect that the
bi-directional multi-path transmission is performed even though CN
cannot obtain the number of frame retransmissions directly. On the
other hand, the interface flag indicates the interface currently
used for communication. That is, the MN under the single-path
transmission informs the IP address that is currently used for
communication to the CN.
Fig.4 depicts a flowchart of switching to multi-path transmission.
The flowchart is divided into two processes: (a) reading the
information from the shared memory, and (b) estimation of wireless
link quality and switching to multi-path transmission. Whenever a
data frame is sent, the flowchart is executed. In the flowchart,
there are two types of variables. One is the global variable, and
the other is the variable to read the information in the shared
memory, we call the latter variable the shared memory variable. In
the present paper, $var$ indicates the global variable and #var#
indicates the shared memory variable.
START
|
V
calculate the frequency
of reading information
($get_cnt$))
(a) |
------------ | ------------------------------------
(b) V
start loop
$get_cnt$ times
|
V
read retry count from shared memory
|
NO V YES
+----- #retry_count# >= MPT -----+
| |
V V
end loop end loop
| |
V V
update update
$start_index$ $start_index$
| |
V V
single-path multi-path
transmission transmission
Fig4: Switching to multi-path transmission
Kashihara, et al. Expires: May 14, 2008 [Page 11]
draft-shigeru-wlan-handover-management-00.txt November 2007
In process (a), since the operation by an HM and that by the MAC
layer are asynchronous, an HM needs to check the information written
in shared memory before passing a packet to the IP layer. An HM
first calculates the frequency to read information from shared
memory ($get_cnt$). The frequency indicates the number of sent
frames after the last check. An HM estimates wireless link
condition according to the frame retransmission count registered in
the shared memory. This calculation process is shown in Fig.5.
This process first checks whether this process is being run for the
first time. If so, then $start_index$ is set to 0. Otherwise, then
$start_index$ is set to the value that is the latest array number in
the last process, therefore, it is a start number in this process.
$end_index$ is set to (1) the index region in shared memory, i.e.,
the latest array number. As the size of the array of (2) the retry
count region is 100, when the index value exceeds 100, it returns to
0. That is, since we employ a ring buffer, an HM can calculate
$get_cnt$, even if $start_index$ exceeds $end_index$.
START
|
V YES
Is this process run -----> $start_index$ is set to 0
for the first time? |
| |
NO |<--------------------------+
V
$end_index$ is set to #index#
|
NO V YES
+----- $end_index$ < $start_index$ -----+
| |
V V
$get_cnt$ = +---------------------------------+
$end_index$ - $start_index$ | $get_cnt$= |
| | sizeofarray(#retry_count#)- |
| | $start_index$ |
|<--------------------------| | |
| | V |
| | $get_cnt$=$get_cnt$+$end_index$ |
| +---------------------------------+
V
retrun $get_cnt$
Fig5: Calculation of the frequency of reading the information
In process (b), an HM executes a loop to compare the retry count
with the MPT $get_cnt$ times. In this comparison, if the number of
frame retransmissions exceeds MPT, an HM escapes from the loop and
switches to multi-path transmission. Then, in order to execute the
next process, $start_index$ is set to $end_index$ + 1.
Kashihara, et al. Expires: May 14, 2008 [Page 12]
draft-shigeru-wlan-handover-management-00.txt November 2007
In multi-path transmission, since an MN sends the same data frames
through multiple WLANs, the network traffic load increases. Thus,
an MN needs to return single-path transmission and select a better
WLAN as soon as possible in order to reduce the extra network
traffic. In order to investigate each wireless link quality in
multi-path transmission, an HM utilizes the number of frame
retransmissions as in the case of single-path transmission. An HM
compares the number of frame retransmissions on each WLAN interface
with the Stability Count Threshold (SC_TH). If the number of frame
retransmissions is smaller than SC_TH, the Stability Counter of its
WLAN interface (SC_IF) is incremented by one. On the other hand, if
the number of frame retransmissions is larger than SC_TH, then SC_IF
is reset to 0. Then, if SC_IF exceeds the Single Path Threshold
(SPT), an HM decides that the wireless link quality is stable for
communication and switches to single-path transmission of the WLAN.
Fig.6 shows an operation how to switch to single-path transmission.
In process (a), an HM first calculates the frequency of reading
information from shared memory, in the same way as in the case of
the operation of single-path transmission. An HM then executes a
loop to read information from shared memory $get_cnt$ times. In
this loop, an HM continuously compares the number of frame
retransmissions with the SC_TH $get_cnt$ times. At this time, if
the number of frame retransmissions is smaller than SC_TH, $SC_IF$
is incremented by one. Otherwise, $SC_IF$ is reset to 0. After the
loop, an HM updates $start_index$ for the next process and compares
$SC_IF$ with SPT. If $SC_IF$ exceeds SPT, the HM switches to
single-path transmission. Otherwise, the HM continues multi-path
transmission.
Kashihara, et al. Expires: May 14, 2008 [Page 13]
draft-shigeru-wlan-handover-management-00.txt November 2007
START
|
V
calculate the frequency
of reading information
($get_cnt$))
(a) |
------------ | ------------------------------------
(b) V
start loop
$get_cnt$ times
|
V
read retry count from shared memory
|
NO V YES
+----- #retry_count# >= SC_TH -----+
| |
V V
$SC_IF$ is $SC_IF$ is increased
set to 0 by one
| |
+---------+------------------------+
|
V
end loop
|
V
update $start_index$
|
NO V YES
+----- $SC_IF$ >= SPT -----+
| |
V V
multi-path single-path
transmission transmission
Fig.6: Switching to single-path transmission
5. Conclusion
In this article, we have discussed our handover management
architecture for seamless handover between different IP WLANs. We
first mentioned that the degradation of communication quality at
handover initiation becomes a critical issue. To seamlessly move
across multiple WLANs divided into different IP subnets, an MN
should execute the handover process while reliably and promptly
detecting degradation of the wireless link condition before
deterioration of communication quality actually occurs. We then
proposed the number of frame retransmissions as a new handover
trigger. Next, we explained our handover management scheme using
the new handover trigger. Our proposed scheme can flexibly select a
Kashihara, et al. Expires: May 14, 2008 [Page 14]
draft-shigeru-wlan-handover-management-00.txt November 2007
better WLAN according to the wireless link condition (i.e., the
number of frame retransmissions), while properly switching between
single-path and multi-path transmission during handover. However,
our proposed method needs to pass the information from one layer to
another layer. We then introduced cross-layer architecture using a
shared memory. Using the shared memory, our proposed scheme can
achieve seamless handover without degradation of the kernel
performance. Finally, we showed one example of implementation for
our proposed method. We also think concept of our proposed scheme
enable to be applied to not only MONA but also another approaches
such as MIP and mSCTP.
6. Acknowledgements
This work was supported in part by the Kinki Mobile Radio Center
Inc., in part by the Telecommunications Advancement Foundation, in
part by the Japan Society for the Promotion of Science, Grant-in-Aid
for Scientific Research(S)(18000001), and in part by the Ministry of
Internal Affairs and Communications (MIC), Japan.
7. References
[1] "Wireless LAN Medium Access Control (MAC) and Physical Layer
(PHY) Specifications", ANSI/IEEE Std 802.11, 1999 Edition,
Available at
http://standards.ieee.org/getieee802/download/802.11-1999.pdf
[2] FON, http://www.fon.com/jp
[3] C. Perkins (Ed.), "IP Mobility Support for IPv4, revised,"
draft-ietf-mip4-rfc3344bis-02.txt, October 2005.
[4] D. Johnson, C. Perkins, and J. Arkko, "Mobility Support in
IPv6," RFC3775, June 2004.
[5] M. Riegel and M. Tuexen, "Mobile SCTP,"
draft-riegel-tuexen-mobile-sctp-09.txt, November 2007.
[6] K. Tsukamoto, Y. Hori, and Y. Oie, "Transport Layer Mobility
Management across Heterogeneous Wireless Access Networks," IEICE
Transactions on Communications, Vol.E90-B No.5 pp.1122-1131,
May 2007.
[7] S. Kashihara, K. Iida, H. Koga, Y. Kadobayashi, and S.
Yamaguchi, "Multi-Path Transmission Algorithm for End-to-End
Seamless Handover across Heterogeneous Wireless Access
Networks," IEICE Transactions on Communications, Vol.E87-B,
No.3, pp.490-496, September 2004.
[8] S. Kashihara, T. Nishiyama, K. Iida, H. Koga, Y. Kadobayashi,
and S. Yamaguchi, "Path selection using active measurement in
multi-homed wireless networks", Proc. of IEEE/IPSJ 2004
International Symposium on Applications and the Internet
(SAINT2004), pp.273-276, January 2004.
[9] K. Tsukamoto, T. Yamaguchi, S. Kashihara, and Y. Oie,
"Experimental Evaluation of Decision Criteria for WLAN handover:
Signal Strength and Frame Retransmission," IEICE Transactions on
Communications, December 2007. (In press)
Kashihara, et al. Expires: May 14, 2008 [Page 15]
draft-shigeru-wlan-handover-management-00.txt November 2007
[10] A. Mishra, M. Shin, and W. Arbaugh, "An Empirical Analysis of
the IEEE 802.11 MAC Layer Handoff Process," ACM SIGCOMM
Computer Communication Review, Vol.33, Issue 2, April 2003.
[11] A. Dutta, F. Vakil, J. Chen, M. Tauil, S. Baba, N. Nakajima,
and H. Schulzrinne, "Application Layer Mobility Management
Scheme for Wireless Internet," Proc. of IEEE 3G Wireless 2001,
May 2001.
[12] K. El Malki (Ed.), "Low Latency Handoffs in Mobile IPv4,"
draft-ietf-mobileip-lowlatency-handoffs-v4-11.txt, October 2005.
[13] M. Chang, M. Lee, and S. Koh, "Transport Layer Mobility Support
Utilizing Link Signal Strength Information," IEICE Transactions
on Communications, Vol.E87-B, No.9, pp.2548-2556,
September 2004.
[14] K. Muthukrishnan, N. Meratnia, M. Lijding, G. Kopringkov, and
P. Havinga, "WLAN location sharing through a privacy observant
architecture," Proc. of First International Conference on
Communication System Software and Middleware (COMSWARE),
January 2006.
[15] S. Kashihara and Y. Oie, "Handover Management based on the
Number of Data Frame Retransmissions for VoWLANs," Elsevier
Computer Communications, Volume 30, Issue 17, pp.3257-3269,
30 November 2007.
[16] S. Kashihara, K. Tsukamoto, and Y.Oie, "Service-oriented
Mobility Management Architecture for Seamless Handover in
Ubiquitous Networks," IEEE Wireless Communications, Vol.14,
No.2, pp.28-34, April 2007.
[17] S. Kashihara, K. Tsukamoto, H. Koga, and Y. Oie, "Handover
management based on the number of frame retransmissions for
VoWLANs," In The 7th ACM International Symposium on Mobile
AdHoc Networking and Computing (MobiHoc 2006), Demo Sessions,
May 2006.
[18] Y. Taenaka, S. Kashihara, K. Tsukamoto, Y. Kadobayashi, and Y.
Oie, "Design and Implementation of Cross-layer Architecture for
Seamless VoIP Handover," The Third IEEE International Workshop
on Heterogeneous Multi-Hop Wireless and Mobile Networks 2007
(IEEE MHWMN'07), October 2007.
[19] H. Koga, H. Haraguchi, K. Iida, and Y. Oie, "A Framework for
Network Media Optimization in Multihomed QoS Networks," Proc.
of ACM First International Workshop on Dynamic Interconnection
of Networks (DIN2005), pp.38-42, September 2005.
8. Author's Addresses
Shigeru Kashihara, Yuzo Taenaka, Youki Kadobayashi, Suguru Yamaguchi
Graduate School of Information Science,
Nara Institute of Science and Technology (NAIST)
8916-5 Takayama, Ikoma, 630-0192, Japan.
Tel: +81-743-72-5213, Fax: +81-743-72-5219
E-mail: {shigeru, yuzo-t, youki-k, suguru}@is.naist.jp
Kashihara, et al. Expires: May 14, 2008 [Page 16]
draft-shigeru-wlan-handover-management-00.txt November 2007
Kazuya Tsukamoto, Yuji Oie
Department of Computer Science and Electronics,
Kyushu Institute of Technology (KIT)
680-4 Kawazu, Iizuka, 820-8502, Japan.
Tel: +81-948-29-7687, Fax: +81-948-29-7652
E-mail: {tsukamoto, oie}@cse.kyutech.ac.jp
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Kashihara, et al. Expires: May 14, 2008 [Page 17]