If you’ve been working in the IT world for awhile, you’ve likely encountered so-called “sticky client syndrome.”  A sticky client remains connected to an AP even as the device roams further and further away from the AP. Users can get frustrated because their device shows a low signal, even as they may be standing directly underneath an AP.  The device won’t roam to the new AP and the low signal from the original AP causes apps and the Internet work slowly, if at all. Sticky clients can also cause significant performance degradation for other devices, since WiFi is a shared medium and all devices on the channel are competing for airtime.  As the sticky client resorts to using lower data rates and suffers from more re-transmissions, all other devices must wait longer to transmit their own data.

Roaming decision by client device:

Wireless devices normally monitor or should monitor their wireless connection health such as receive signal strength indicator (RSSI), signal to noise ratio etc. Once connection health degrades it should start looking or probing for alternate best options available in the environment and sooner it finds better option (access point). It should start transition from old access point to new access point with better connection.

In reality it does not happen the way it should and devices have sticky behaviour. There are a few reasons for this behaviour, Number 1 there is no standardisation where you expect a client device to behave in a cretin way and secondly WiFi chip vendors sell their radios to companies that put them into a variety of products ranging from phones and tablets to light bulbs and thermostats.

The roaming characteristics of these devices varies greatly. An IoT device like a video camera is typically fixed in one location and shouldn’t expect to roam, whereas phones are extremely mobile.  The firmware running on all radios has software algorithms that control roaming behaviour. These algorithms can be configured to prize connectivity (however bad) over the disruption caused by roaming.  It’s up to the device manufacturer to tune these algorithms to perform well for the specific device.

While there do exist standards to improve client roaming behaviour,  the device is ultimately responsible for determining when to roam and where to connect.  This creates challenging management issues for IT professionals. How do you design a network to best encourage clients to roam?  What can be done to mitigate the sticky client issue?

Sticky client Mitigation:

There are few options available to in order to reduce sticky client behaviour:

• Encourage devices to connect to best option (access point) available
• Discourage devices to connect to low data rates
• Deauth devices

First mitigation approach is probably best the option where we encourage the devices to connect to best access point available in the environment by enabling 802.11 protocols such as 802.11k and 802.11v. Only catch in this approach is your devices must support same protocols. I have come across the situations where we enabled these protocols and mostly devices were working beautifully and then other devices does not understand this extra information in 802.11 communication. Devices who does not understand these protocols might not even make connection with WiFi network.

Second option is to discourage devices connecting to the APs further away. Sooner the devices move away from the access point the health indicators such as RSSI and SNR etc will also drop. When network health goes down devices might keep the connection and drop data rate in order to keep connectivity but this will result in poor connection and high percentage of retries. In order to discourage this behaviour is to disable lower data rates on the access point which will kick start the process of roaming to another access point available.

3rd option is the brutal option to kick the clients out if they do not match some certain criteria such as RSSI threshold. This might feel discomfort for maybe some client devices but it will help overall network performance. You do not want clients to connect with lower data rates and with poor network health which will cause issues for other devices as well in same cell. If client device falls under particular  RSSI threshold AP sends out De-auth to the client. This option is good option when you are aware of your WiFi RF design and you know that whole area is covered properly. Imagine you kick out the device because it drops from certain RSSI threshold and device has no other AP to connect to so now you have created trouble for your self.

Final thoughts:

I believe non of the options explained above are good or bad to use. It totally depends on given scenario, design and situation that what particular option you want to use. If you are using voice over Wi-Fi type applications and you use last option to kick out devices depending on RSSI threshold. Its going to be bit of night mare because clients devices will be disconnected while in use. So in this case maybe you want to use first option where you encourage devices to move themselves when a better connectivity option is available.
Discouraging devices and kicking them out should be used with care because this could fireback, so as I said only use it when you know what you want to achieve and how its going to effect overall whole network performance.