Technology Blog

Client Roaming Triggers

Guest Blogger

Thirteen years ago, a wireless network was nice to have and not a generally accepted network strategy. Earlier adopters of wireless often gauged wireless success by connecting to the network, checking email, browsing the web and maybe transferring a file or two without any issues. Most wireless client drivers at the time lacked robust roaming algorithms and had a tendency to be sticky. This was even more noticeable with consumer grade products, which is still true today. 

 

As wireless emerged and became part of the network strategy, user acceptance began to increase. Chip manufactures paid closer attention to roaming and the roaming triggers. Wireless vendors published best practice guides to help facilitate client roaming referencing cell size, overlap and transmit power. At the time most folks really did not understand how clients roamed. Since there is no 802.11 standard specific to client roaming, client vendors have a free pass to build the roaming triggers as they see fit.   

 

Let me say that again, “Since there is no 802.11 standard specific to client roaming, client vendors have a free pass to build the roaming triggers as they see fit.”  

 

What are triggers ? I am glad you asked.  

 

Think for a moment that YOU are the wireless NIC. You are connected to an access point and happily sending and received your 802.11 frames. All of a sudden, you get picked up and are on the move. The access point you are connected to is getting weaker and weaker by the moment. You need to find a closer access point to associate to. At what point you start to look for this new access point is the trigger I reference.    WiFi client manufactures reference different triggers, if they publish any at all. These include but are not limited to RSSI, SNR, noise, and error bit rate. Lets look at a hypothetical example:  

 

CLIENT NIC#1 - 

Trigger#1 RSSI: -73 dBm

Trigger#2 SNR: -16 dBm  

 

In the above example, the client will start to probe for neighboring access points (start the roaming process) when the connection to the currently associated access point is at -73 or higher. Or when SNR drops to -16 dBm or lower.    WiFi client manufactures rarely publish the exact triggers. In fact, triggers are sometimes modified during driver updates. Some vendors allow you to loosely modify the roaming triggers.

 

Intel has the roaming aggressiveness value section. It allows you to choose from:  

 

 

0: No Roaming

1-3: Allow Roaming

2: Default. Balances between not roaming and performance.

4. Maximum roaming.  

 

intel.png

 

What does this really change in the background? Your guess is as good as mine.

 

Remember this is vendor secret sauce here.  Client roaming is heavily dependent on vendor implementation. You are taking a leap of faith that the vendor of your wireless NIC will do right by you. The best way to figure out your clients roaming triggers is to test it. Analyze the layer 2 frames. Watch at different distances and radio reception when the client triggers probes. Introduce interference and watch closely how the client reacts.

 

It should be noted, wireless infrastructure vendors have implemented methods to “enhance” client roaming by ignoring probe request and steering clients with the use of reason code 17. Unfortunately most clients ignore this reason code. 802.11r should not be confused with client roaming triggers, rather the 802.11r standard stream lines the association process from access point to access point, especially when advance security is used. 

 

Enjoy! I appreciate any feed back and experience you may have with client triggers! 

Comments
Guru Elite

Excellent way to summarize the elephant in the room, Gstefanik!

MVP

Thanks man good info!!!

Contributor I

Triggers and how they are controlled by vendors is something I have tried to explain to end users but it can be very difficult.  Thanks for the post.  I might use a ew comments to explain in the future.

Guest Blogger

PJERRY,

 

Thanks for stopping by and sharing your experience. I have to agree, some customers have a hard time understanding and will often point a finger at the infrastructure. Do you often recommend customers standardize on a client and driver when deploying large networks? 

 

Super Contributor II

I believe it depends on how mission critical the outage would be. If it is a healthcare environment I recommend testing locking down clients and testing each client, with each driver, on each ap type, on each controller type, on each controller code.

 

Also I would have to say it is also a business decision. Lets say you wanted to update your controller code and you did not want to test. If the risk of a device not working with that code outweighs the cost of testing, then that is your business requirement. In a world where money is no problem we could test everything! But some companies find it hard to even come up with the money to buy the WLAN infrastructure.

 

 

Cost of testing VS the cost of NOT testing.

Occasional Contributor II

It has always been a pain observing sticky clients. Unfortunately some drivers don't change almost anything once roaming is moved from medium to aggressive. Best I've seen is the client sending probe requests more often...but...was still sticky !

So...if you really want a good driver to roam when it's the correct moment, get a sw company to write an open source driver. They did it for a subway: quick scanning only for 3 channels on the 2.4GHz and they set the trigger for signal power. Result: works perfect and we know why because we decided how to.

That's life for the moment.

 

Search Airheads
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements
Read all about it! If it’s happening now, it’s in the community.

Check out the latest blogs from your community team, the community experts and other industry sources.
Labels