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