SHARE

Is Wi-Fi Roaming Really Seamless?

One extremely beneficial aspect of Wi-Fi networks is mobility. For example, a person can walk through a facility while carrying on a conversation over a Wi-Fi phone or downloading a large file from a server. The Wi-Fi radio inside the user device automatically roams from one access point to another as needed to provide seamless […]

Written By

Jim Geier

Apr 24, 2006

Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More

One extremely beneficial aspect of Wi-Fi networks is mobility. For example, a person can walk through a facility while carrying on a conversation over a Wi-Fi phone or downloading a large file from a server. The Wi-Fi radio inside the user device automatically roams from one access point to another as needed to provide seamless connectivity. At least, that’s what we hope will happen!

In the past, I’ve experienced issues with roaming, so I decided to perform some testing to get an inside view of what’s really happening. I was especially curious about how fast roaming actually works, and whether or not it’s disruptive to wireless applications.

My test configuration included two standard access points, with one access point (AP-1) set to channel 1 and the other access point (AP-2) set to channel 6. Other settings were default values, such as beacon interval of 100 milliseconds, RTS/CTS disabled, etc. The access points were installed in a typical office facility in a manner that provided a minimum of 25dB signal-to-noise ratio throughout each access point’s radio cell, with about twenty percent overlap between cells. This is somewhat the industry standard for wireless voice applications. The roaming client in my case, though, was a laptop equipped with an internal Intel Centrino Wi-Fi radio (Intel 2915ABG).

While standing with the wireless client within a few feet of AP-1, I used AirMagnet Laptop Analyzer (via another Wi-Fi card inserted into the laptop’s PC Card slot) to ensure that that I was associated with AP-1. I then kicked off an FTP transfer of a large file from the server to the laptop and started measuring the 802.11 packet trace using AirMagnet. With the file downloading throughout the entire test, I walked toward AP-2 until I was directly next to it. With the packet trace, I was able to view the exchange of 802.11 frames, calculate the roaming delay, and see if there was any significant disruption to the FTP stream.

Once the client radio decided to re-associate, it issued several 802.11 disassociation frames to AP-1 to initiate the re-association process. The radio then broadcast an 802.11 probe request to get responses from access points within range of the wireless client. This is likely done to ensure that the client radio has up-to-date information (beacon signal strength) of candidate access points prior to deciding which one to re-associate with.

AP-2 responded with an 802.11 probe response. Because the only response was from AP-2, the client radio card decided to associate with AP-2. As expected, the association process with AP-2 consisted of the exchange of 802.11 authentication and association frames (based on 802.11 open system authentication).

The re-association process took 68 milliseconds, which is the time between the client radio issuing the first dissociation frame to AP-1 and the client receiving the final association frame (response) from AP-2. This is quite good, and I’ve found similar values with other vendor access points.

The entire roaming process, however, will interrupt wireless applications for a much longer period of time. For example, based on my tests, the FTP process halts for an average of five seconds prior to the radio card initiating the re-association process (i.e., issuing the first disassociation frame to AP-1). I measured 802.11 packet traces indicating that the client radio card re-retransmits data frames many times to AP-1 (due to weak signal levels) before giving up and initiating the re-association with AP-2. This substantial number of retransmissions disrupted the file download process, which makes the practical roaming delay in my tests an average of five seconds! Centrino is notorious for having this problem, but I’ve found this to be the case with most other radio cards as well.

Vendors are likely having WLAN client cards hold off on re-associations to avoid premature and excessive re-associations (access point hopping). Unfortunately, this disrupts some wireless applications. If you plan to deploy mobile wireless applications, be sure to test how roaming impacts the applications.

Every model of radio card will behave differently when roaming due to proprietary mechanisms, and some cards will do better than others. Just keep in mind that roaming may take much longer than expected, so take this into account when deploying wireless LAN applications, especially wireless voice, which is not tolerant to roaming delays exceeding 100 milliseconds.

Jim Geier is the principal of Wireless-Nets, Ltd, a consulting firm focusing on the implementation of wireless mobile solutions and training. He is the author of the books Deploying Voice over WLANs (Cisco Press), Wireless LANs (Sams) and Wireless Networks – First Step (Cisco Press).

This article was first published on WiFiPlanet.com.