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]