idnits 2.17.1 draft-yuzo-ap-selection-considering-wlan-condition-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 3 longer pages, the longest (page 3) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 4 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (Febrary 8, 2010) is 5252 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '2-4' on line 101 -- Looks like a reference, but probably isn't: '6-10' on line 141 -- Looks like a reference, but probably isn't: '6-9' on line 145 == Unused Reference: '3' is defined on line 375, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 380, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 389, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 394, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 399, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 403, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' Summary: 4 errors (**), 0 flaws (~~), 9 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Yuzo Taenaka 2 Internet Draft Shigeru Kashihara 3 Expires: August 8, 2010 Kazuya Tsukamoto 4 Suguru Yamaguchi 5 Yuji Oie 7 Febrary 8, 2010 9 AP selection method considering WLAN condition 10 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with 15 the provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on August 8, 2010. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with 43 respect to this document. 45 Abstract 47 This document discusses AP selection method utilizing the number of 48 frame retransmissions in addition to received signal strength (RSSI). 49 In a real environment, WLANs are congested by lots of mobile nodes, 50 and sometimes influenced by other WLAN devices. They result in 51 deterioration of communication quality. In such environment, 52 each mobile node has to select an AP with better performance for 53 keeping its own communication stable. To enable this, we employ 54 the number of frame retransmissions and RSSI as selection indexes. 55 We then describe an architecture design and implementation for our 56 proposed scheme. 58 Table of Contents 60 1. Introduction....................................................2 61 2. AP Selection Method.............................................4 62 2.1 Concept of the proposed AP selection........................4 63 2.2 Details of the AP Selection Method..........................5 64 3. Conclusion......................................................8 65 4. Acknowledgements................................................8 66 5. References......................................................8 67 6. Author's Addresses..............................................9 69 1. Introduction 71 Wireless LANs (WLANs) based on the IEEE 802.11 specification [1] 72 provide high data transmission and simple, low-cost installation. 73 For this reason, WLANs have been spreading rapidly in both private 74 and public spaces, so that these WLANs will overlap to provide 75 continuous and wide coverage as the underlying basis of ubiquitous 76 networks. In such ubiquitous WLANs, mobile nodes (MNs) can access 77 the Internet from everywhere and at anytime. 79 In WLANs, an MN requires not only permanent access to the Internet, 80 but also seamless movement between access points (APs) without 81 degradation of communication quality, i.e., seamless mobility is 82 essential. Furthermore, in such ubiquitous WLANs, each AP will 83 independently provide wireless Internet connectivity based on 84 IEEE 802.11 technology. That is, the WLAN coverage consists of 85 different IP subnets due to independent management by different 86 organizations and operators. In such a situation, even if a mobility 87 support technology applying to AP is developed and standardized, 88 from now on, it will be difficult to replace all APs, which have been 89 spreading, with new APs that support mobility technology. Moreover, 90 since existing APs may not be able to accept such technologies 91 due to restrictions such as lower CPU performance or less memory, 92 update of APs' software for supporting mobility technology is also 93 not realistic. Therefore, it is desirable to provide a seamless 94 mobility technology without modification of APs. 96 To achieve such seamless mobility, the following two requirements 97 must be satisfied: (1) selection of an AP with better performance 98 from among multiple candidate APs and (2) preservation of 99 communication quality during handover. For (2), we proposed 100 a handover management scheme based on the number of frame 101 retransmissions [2-4]. In the proposed scheme, an MN is assumed to 102 move between WLANs with different IP subnets. In [2], we first 103 employed multi-homing architecture to prevent a disruption period 104 due to handover processes. That is, since an MN with two WLAN 105 interfaces (a multi-homing MN) can connect to two APs simultaneously 106 before starting handover, an MN never experiences a disruption 107 period due to handover processes. Next, to properly switch the two 108 associating APs based on each wireless link quality, the number of 109 frame retransmissions was introduced as an indicator for detecting 110 the wireless link condition. Although the Received Signal Strength 111 Indicator (RSSI) is generally used as an indicator of a wireless 112 link quality, we showed that the RSSI is insufficient to detect 113 wireless link condition precisely because it is incapable of 114 detecting the degradation of communication quality due to radio 115 interference [5]. On the other hand, we showed that the number of 116 frame retransmissions could promptly and reliably detect 117 the performance degradation due to reduction of the RSSI and radio 118 interference. Therefore, the proposed handover management method 119 based on the number of frame retransmissions can preserve 120 communication quality during a handover. 122 Selection of an AP with better performance from among multiple 123 candidate APs, however, remains unresolved. For example, in the 124 method proposed in [2], even if an MN has two WLAN interfaces to 125 eliminate a disruption period due to handover process, there is no 126 guarantee that the MN can select an AP with better performance for 127 a handover. In ubiquitous WLANs, the MN may find multiple candidate 128 APs at one time and needs to select an appropriate AP from among 129 them. At this time, if an AP with better performance is not selected 130 appropriately, the communication quality may degrade after a 131 handover. In the current general AP selection, an MN selects an AP 132 with the strongest RSSI. However, since numerous APs and MNs will 133 exist in high-density ubiquitous WLANs, radio interference, which 134 degrades communication quality, occurs frequently due to both the 135 lack of the number of channels and heavy traffic in the AP. Thus, 136 an AP selection method considering not only RSSI reduction but also 137 radio interference caused by other WLAN devices is essential for 138 achieving seamless mobility. 140 So far, there have been numerous discussions on AP selection for 141 improving the communication performance of MNs in WLANs[6-10]. 142 In ubiquitous WLANs, since an MN must be able to freely connect 143 with all APs for an inter-domain handover, it is desirable that 144 an AP is not modified in order to maintain compatibility with 145 existing APs. Almost all existing AP selection methods [6-9], 146 however, necessitate some modifications of APs, e.g., additional 147 information should be inserted in the beacon frame transmitted from 148 the AP. Moreover, the modification needs to be implemented in both 149 an AP and an MN. On the other hand, [10] explained that the effects 150 from hidden mobile nodes affect throughput degradation. 152 In the method proposed herein, although modification of an AP is 153 unnecessary, the method is applied to only IEEE 802.11e, which has 154 not yet become widespread. Therefore, in this article, we focus 155 a new proactive AP selection method based on RSSI and frame 156 retransmissions. Since we have showed that the number of frame 157 retransmissions is useful to detect radio interference in [5], 158 this article describes how to utilize the number of 159 frame retransmissions to AP selection method achieved in end-to-end. 160 The proposed AP selection method enables an MN to select an AP with 161 better performance taking radio interference into consideration by 162 exploiting the number of frame retransmissions in addition to 163 the RSSI. 165 2. AP Selection Method 167 Here, we describe the proposed AP selection method. We first describe 168 the concept of the proposed method in Section 2.1. In Section 2.2, 169 we describe the proposed method with flowcharts. 171 2.1 Concept of the proposed AP selection 173 This article focuses on a proactive AP selection for a radio 174 interference environment. In the handover method, we proposed in a 175 previous study [11], a multi-homed MN appropriately switches WLAN 176 interfaces (WIFs) according to wireless link condition. 177 Figure 1 shows an overview of operation between a handover and an 178 AP selection on an MN. An AP selection is performed on the WIF2 179 during communicating through the WIF1. On the other hand, after 180 a handover, since the communication switched to the WIF2, 181 the AP selection is next executed on the WIF1. That is, the AP 182 selection is always executed on an idle interface. 184 +-------------------------------------------------------+ 185 | Application | 186 +-------------------------------------------------------+ 187 | +---------------+ 188 +-|-----------+ | AP selection | +-------------+ 189 | | IP Layer | +---------------+ | IP Layer | 190 +-|-----------+ | +-------------+ 191 | | MAC Layer | +------>| MAC Layer | 192 +-|-----------+ control +-------------+ 193 | | PHY Layer | | PHY Layer | 194 +-|-----------+ +-------------+ 195 | communication 196 V A 197 | 198 | handover 199 | 200 V 202 +-------------------------------------------------------+ 203 | Application | 204 +-------------------------------------------------------+ 205 +---------------+ | 206 +-------------+ | AP selection | +-----------|-+ 207 | IP Layer | +---------------+ | IP Layer | | 208 +-------------+ | +-----------|-+ 209 | MAC Layer |<------+ | MAC Layer | | 210 +-------------+ control +-----------|-+ 211 | PHY Layer | | PHY Layer | | 212 +-------------+ +-----------|-+ 213 communication | 214 V 216 Fig.1: A handover and an AP selection on an MN 218 2.2 Details of the AP Selection Method 220 In this section, we describe the proposed AP selection method. 221 The AP selection method is divided into two main parts: the AP 222 selection procedure and the AP search procedure, as shown in 223 Figures 2 and 3, respectively. In both figures, words in CAPITAL 224 denote the system parameters in the proposed AP selection method. 225 In the AP selection procedure, an MN periodically investigates 226 the wireless link condition of an associating AP and decides whether 227 the wireless link has sufficient wireless link quality. On the other 228 hand, in the AP search procedure, an MN scans candidate APs and 229 selects an AP with better performance from among them. 230 Hence, MN starts the AP search procedure only when it detects the 231 degradation of the communication quality on the current interface 232 by exploiting the number of frame retries. That is, MN does not 233 start the AP search procedure even when the RSSI degrades unless 234 the frame retries increases. 236 start 237 | 238 V 239 send PPC probe packets at PPI ms interval 240 | 241 V 242 obtain retry count at each probe packet 243 | 244 V no 245 # of packets with more than frame retries >= RCT ---+ 246 | yes | 247 V | 248 execute procedure of AP search | 249 | | 250 V | 251 update network configuration | 252 | | 253 V | 254 end <-------------------------+ 256 Fig.2 Flowchart of AP selection procedure 258 start 259 | 260 V 261 make an AP list 262 | 263 V 264 remove the APs that were associated with 265 immediately preceding WIF1/WIF2 266 | 267 no V 268 +--- is there one or more available AP in the list? <---+ 269 | | yes | 270 | V | 271 | associate with an AP in order of strong RSSI | 272 | | | 273 | V | 274 | send PPC probe packets at PPI ms interval | 275 | | | 276 | V no| 277 | # of packets with more than ERC frame retries < RCT --+ 278 | | yes 279 | V 280 +----------------------> end 282 Fig.3 Flowchart of the AP search procedure 284 In this section, in order to clarify the proposed AP selection 285 method, we assume that an MN with two WIFs (the WIF1 and the WIF2) 286 first communicates through the WIF1, and the WIF2 associates with 287 an AP with better performance at this time. Hence, the AP selection 288 procedure is executed on the WIF2. Initially, the MN starts a timer 289 to control the AP selection procedure, i.e., the AP selection 290 procedure is periodically executed at each AP Selection Execution 291 Interval of APSEI seconds based on the timer. This is because an MN 292 needs to periodically investigate the wireless link condition of 293 the associating AP in order to detect changes in the wireless link 294 quality due to the movement of the MN and radio interference. 295 If the AP selection method is not periodically executed, an MN 296 unfortunately maintains the association with the AP until its 297 wireless link quality clearly degrades, similarly to an AP selection 298 based on the RSSI. This causes severe degradation of 299 the communication quality at handover. When the AP selection 300 procedure is executed, the WIF2 sends probe packets to the AP 301 at constant intervals. The Probe Packet Count (PPC) denotes 302 the number of probe packets for one AP, and the Probe Packet Interval 303 (PPI) indicates the sending interval of probe packets. After sending 304 all of the probe packets, the MN obtains the number of frame 305 retransmissions for each probe packet. If the number of probe packets 306 experiencing more than Experienced Retransmission Count (ERC) 307 retransmissions is less than the Retransmission Count 308 Threshold (RCT), the MN decides that the AP has good wireless 309 link condition and maintains the connection with the AP. 310 After selecting an AP with better performance, the procedure 311 terminates and then the MN executes the AP selection procedure 312 every APSEI seconds. 314 In contrast, if the number of probe packets that experience 315 more than ERC frame retransmissions exceeds RCT, i.e., the AP 316 associated with the WIF2 is not an AP with better performance, 317 an AP search procedure is executed. As shown in Fig. 3, in the AP 318 search procedure, the MN first makes a list of all candidate APs 319 detected by the WIF2, and removes the APs currently associated by 320 the WIF1/2 from the list. In our approach, to efficiently find 321 an AP with better performance, our proposed method first checks 322 the RSSI of candidate APs because the RSSI can be easily and 323 passively obtained than the number of frame retransmissions. 324 That is, it does not need both establishment of the association 325 with APs and the packet transmission of probe packets. 326 Therefore in our proposed scheme, after temporary sorting 327 the candidate APs based on the strength of the RSSI, the MN 328 investigates the APs by exploiting the number of 329 frame retransmissions in order of high RSSI. If not sorting, 330 the MN may transmit unnecessary packets to an AP with 331 low performance (low RSSI), not to an AP with good performance 332 (high RSSI). Hence, creation of an AP list based on RSSI prevents 333 the unnecessary packet transmissions and shortens the detection time 334 as much as possible. In the flowchart, if the number of packets 335 experiencing more than ERC-times frame retries exceeds RCT, 336 our proposed scheme detects the degradation in the wireless condition 337 of the selected AP degrades and then the investigation is repeated 338 in order of high RSSI until finding an AP with better performance. 339 If an AP with better quality cannot be found, the MN retries the AP 340 search at the next AP selection, i.e., after APSEI seconds. 342 After finishing these procedures, the MN can select an AP with low 343 radio interference and strong RSSI. 345 3. Conclusion 346 In this article, in order to select an AP with better performance 347 from among multiple candidate APs in ubiquitous WLANs, we discussed 348 a proactive AP selection method based on frame retransmissions and 349 the RSSI. In an AP selection based on only the RSSI, an MN cannot 350 always select an AP with better performance in ubiquitous WLANs, 351 because the RSSI alone cannot detect the degradation of wireless link 352 quality due to radio interference. We therefore used the number of 353 frame retransmissions as an index for detecting radio interference 354 in addition to the RSSI and then proposed an AP selection method for 355 the proposed handover management system. 357 4. Acknowledgements 359 This work was supported in part by the Kinki Mobile Radio Center 360 Inc., the Japan Society for the Promotion of Science, Grant-in-Aid 361 for Scientific Research(B)(No. 20700064), and the NEC C&C Foundation, 362 Japan. 364 5. References 366 [1] "Wireless LAN Medium Access Control (MAC) and Physical Layer 367 (PHY) Specifications", ANSI/IEEE Std 802.11, 1999 Edition, 368 Available at 369 http://standards.ieee.org/getieee802/download/802.11-1999.pdf 371 [2] S. Kashihara, K. Tsukamoto, and Y. Oie. Service-oriented mobility 372 management architecture for seamless handover in ubiquitous 373 networks. IEEE Wireless Communications, 14(2):28-34, April 2007. 375 [3] K. Tsukamoto, S. Kashihara, and Y. Oie. Unified Handover 376 Management Scheme Based on Frame Retransmissions for TCP over 377 WLANs. IEICE Transactions on Communications, E91-B(4):1034-1046, 378 April 2008. 380 [4] S. Kashihara and Y. Oie. Handover Management based on the Number 381 of Data Frame Retransmissions for VoWLANs. Elsevier Computer 382 Communications, 30(17):3257-3269, November 2007. 384 [5] K. Tsukamoto, T. Yamaguchi, S. Kashihara, and Y. Oie. Experimental 385 Evaluation of Decision Criteria for WLAN handover: Signal Strength 386 and Frame Retransmis- sion. IEICE Transactions on Communications, 387 E90-B(12):3579-3590, December 2007. 389 [6] M. Abusubaih, J. Gross, S. Wiethoelter, and A. Wolisz. On Access 390 Point Selection in IEEE 802.11 Wireless Local Area Networks. 391 In proceedings of the sixth International workshop on Wireless 392 Local Networks (WLN2006), November 2006. 394 [7] K. Sundaresan and K. Papagiannaki. The Need for Cross-Layer 395 Information in Access Point Selection Algorithm. In Proceedings of 396 the 6th ACM SIGCOMM conference on Internet Measurement (IMC'06), 397 pages 257-262, October 2006. 399 [8] Y. Fukuda, J. Fukuda, and Y. Oie. Decentralized Access Point 400 Architecture for Wireless LANs. In Proceedings of IEEE Vehicular 401 Technology Conference 2004-fall (VTC 2004-Fall), September 2004. 403 [9] Y.Fukuda,M.Honjo,andY.Oie. Development of Access Point Selection 404 Architecture with Avoiding Interference for WLANs. In Proceedings 405 of the 17th international symposium on Personal, Indoor and Mobile 406 Radio Communications (PIMRC' 06), pages 1-5, September 2006. 408 [10] L. Du, Y. Bai, and L. Chen. Access Point Selection Strategy for 409 Large-Scale Wireless Local Area Networks. In Proceedings of 410 IEEE Wireless Communications and Networking Conference 411 (WCNC 2007), pages 2161-2166, March 2007. 413 [11] Y. Taenaka, S. Kashihara, K. Tshukamoto, Y. Kadobayashi, , and 414 Y. Oie. Design and Implementation of Cross-layer Architecture 415 for Seamless VoIP Handover. In Proceedings of The Third IEEE 416 International Workshop on Heterogeneous Multi-Hop Wireless and 417 Mobile Networks 2007 (IEEE MHWMN' 07), October 2007. 419 6. Author's Addresses 421 Yuzo Taenaka 422 Graduate School of Information Science, 423 Nara Institute of Science and Technology (NAIST) 424 8916-5 Takayama, Ikoma, 630-0192, Japan 425 Phone: +81-743-72-5216 426 Email: yuzo-t@is.naist.jp 428 Shigeru Kashihara 429 Graduate School of Information Science, 430 Nara Institute of Science and Technology (NAIST) 431 8916-5 Takayama, Ikoma, 630-0192, Japan 432 Phone: +81-743-72-5213 433 Email: shigeru@is.naist.jp 435 Kazuya Tsukamoto 436 Department of Computer Science and Electronics, 437 Kyushu Institute of Technology (KIT) 438 680-4 Kawazu, Iizuka, 820-8502, Japan. 439 Tel: +81-948-29-7687, Fax: +81-948-29-7652 440 E-mail: tsukamoto@cse.kyutech.ac.jp 441 Suguru Yamaguchi 442 Graduate School of Information Science, 443 Nara Institute of Science and Technology (NAIST) 444 8916-5 Takayama, Ikoma, 630-0192, Japan 445 Phone: +81-743-72-5216 446 Email: suguru@is.naist.jp 448 Yuji Oie 449 Department of Computer Science and Electronics, 450 Kyushu Institute of Technology (KIT) 451 680-4 Kawazu, Iizuka, 820-8502, Japan. 452 Tel: +81-948-29-7687, Fax: +81-948-29-7652 453 E-mail: oie@cse.kyutech.ac.jp