[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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]

Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/