There’s a lot of talk about wireless roaming, and the challenges when roaming across, or even within an IP subnet (see WLAN roaming - the basics). But there’s a lot more to moving between access points that has to happen before you have to worry about changing IP addresses and updating switch MAC tables. You need to understand why a client decides to move from one AP to another. It’s not specified in the standard, so different vendors will implement different algorithms, with different levels of configuration options, which you may need to tune to suit your environment.

When to roam
The good news is that vendors do carry out interoperability trials to make sure that clients and APs will work together. But the decision making process varies. It’s always the client that decides when to start looking for a new AP — but how it makes that decision depends on the vendor.

The parameters typically used include those listed below. In most enterprise systems, you should be able to change these — chances are the default options are pretty reasonable, but you may need to change some of them, depending on your topology. It’s a bit like old fashioned shared Ethernet (which in effect this is) — a collision rate that’s the norm in one network may be an indication of a major problem in another, so it’s best to get the feel of the normal operation of your wireless network, to determine if you should be changing any of these parameters for better service. Be careful not to tune too aggressively, though if you want to keep a relatively stable client base.

  • Signal Strength — if the signal drops below say 50 per cent, do you want to start looking for a new AP? To prevent your client constantly re-associating, this is often combined with a time period. In these systems, you would have had to be connected to one AP for a specified minimum time before looking for a new one.


  • Loss of Beacons — Beacon packets are sent from the AP to the client at regular intervals. The default for 802.11b APs is 100 ms, but this may be configurable within your system. If, say, half a dozen beacons are lost, then it’s time for the client to start looking for a new home. If you shorten this time, then you may speed up roaming time, at the expense of extra traffic on the airwaves. If you decrease the number of beacons that can be lost, then again roaming will start earlier, but since beacons can be lost due to collisions rather than going out of range, this may get you roaming when it’s not appropriate.


  • Data Retry Count — Several non-acknowledged frames will also likely trigger a roam. Since the client can’t tell if the frames have been lost due to collisions or lack of range, different client cards may have different settings. For instance, a PCI wireless NIC, designed for use in a desktop PC, is likely to be stationary, and not move out of range of an access point. It is better in this case to have a higher setting, and just to keep trying for longer when frames are not acknowledged. In an environment with mobile clients, if the WLAN is typically pretty congested, you may want to look at changing this setting if you can.


  • Drop in DataRate — If the speed at which the client is communicating with an AP has to be dropped, the client may look to roam to a better AP. This may be configurable as to how many steps down in rate can be tolerated before taking action.

Where to roam to
There are two ways for a client to find which AP to roam to. Either it can constantly scan for alternatives, so it has the information ready for when it needs to move, or it can wait until it has to roam and do a search then.

The first of these, pre-emptive discovery, will result in the fastest roam time, but takes up most resources. While a client is scanning for other APs, it’s temporarily out of communication with its own, as it must check the other available channels. The second option, discovery just at roam time, may provide more up to date information, will not effect normal transmission and reception, but is likely to take more time to discover a new AP from the time the decision was made to roam. Many vendors’ implementations use this latter method.

These are vendor choices, as is the decision to use active scanning (the client sending probes out on all its channels looking for APs), or passive scanning, where the client listens for AP beacons. Again, the first is more resource-intensive; the second more likely to miss a possible AP. PC-based clients are more likely to use the first option.

Which AP to choose
When a client has a list of possible APs, it must decide which one to roam to. This choice, again, is vendor-dependant, based on the client’s capabilities, and it’s unlikely you’ll be able to change the decision-making process here. However it’s worth knowing how that decision is made — signal strength, transmitter load, number of clients — as that information may help you design your WLAN layout.

Many users will never change the default settings discussed here; however it’s worth testing to see what differences you might get by tuning settings to suit your environment—as always with the caveat to trial this in a pilot before full-scale deployment!