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 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]