My clients aren't roaming. I heard about SmartRoam? Should I use it?


My clients aren't roaming. I heard about SmartRoam? Should I use it?

Customer Environment

ZD controlled APs, Apple or other Sticky clients, high density, need for load balancing

Root Cause

Clients don't roam even if they are physically moved to a new location. Not all clients have roaming aggressiveness setting to fine tune roaming. Apple devices cling to the AP they first learn an SSID on.

Troubleshooting Steps

Usually triggered by client reports of not roaming, troubleshoot from ZD Administer/Diagnostics
and enable Client Association and 802.11 components, then enter that client MAC in the focus box.

Collect ZD debug soon after the client reports not roaming or disconnect/reconnect, and analyze
Log.txt from collected ZD debug .zip file.  Determine client behavior from log msgs.



In a multi-AP environment, a client will always be looking for a best AP to connect to. It will remain connected to its current AP and roam to an adjacent AP once the signal level falls below a certain threshold. This behavior ensures best possible performance at all times.

To achieve this, a client must be doing background scanning to learn about its environment. Frequency of this background scan can determine the roaming behavior. Certain clients such as Windows clients allow roaming aggressiveness to be tweaked. "High" setting will make the client to perform background scanning more often to learn about available APs to connect. While the "Low" setting will make the client to do less frequent scanning. This setting can be found under the wireless adapter properties.

Unfortunately this tweaking is not readily available on all client types. For example, various smartphones and Apple clients don't provide this setting to encourage roaming.

For these type of clients, it is obvious to look towards infrastructure for help. In recent firmware (9.5 and above), Ruckus has added support to disconnect a client if its signal falls below user definable threshold. This feature is called SmartRoam. With this feature there will be an explicit disassociate message to kick-out the client.

Here is how to set this up from the ZD CLI:
ruckus(config)# wlan test
The WLAN service 'test' has been loaded. To save the WLAN service, type 'end' or 'exit'.
ruckus(config-wlan)# smart-roam 3
The command was executed successfully. To save the changes, type 'end' or 'exit'.
ruckus(config-wlan)# end
The WLAN service 'test' has been updated and saved.
Your changes have been saved.

This is a per SSID setting as illustrated above. "smart-roam" parameter takes values from 1 to 10. These are called roam factors and they map to a RSSI value in dB as per the list below:
1 -> 5
2 -> 10
3 -> 15
4 -> 17
5 -> 20
6 -> 23
7 -> 27
8 -> 32
9 -> 40
10 -> 60

There will be an explicit disconnect event under the ZD logs in case this is triggered. Here is an example:
2013/10/08  09:04:23 Low testuser User[testuser] disconnected by admin from WLAN[captivep] at AP[24:c9:a1:28:f0:80]

To disable SmartRoam, enter ZD CLI config mode, per WLAN "no smart-roam" command.

OK, this sounds good so far. Are there any caveats that I should be aware of?

During testing we found that Apple client don't like this type of disconnection coming from the AP. They will remain
disconnected and don't try to connect automatically. This requires user to click on the wireless icon at the top to reconnect
the client.

In order to avoid this we recommend testing first with a very conservative setting like a roam factor of 2 or 3.
QA testing suggests NOT to use a value greater than 5.

Article Number:

April 01, 2015 01:47 PM (over 6 years ago)

Performance, Configuration, Troubleshooting, Known Issues and Workarounds, ZoneDirector, ZoneFlex Indoor, ZoneFlex Outdoor


This article is:
not helpful

Working...Please wait

This is here to prevent you from accidentally submitting twice.

The page will automatically refresh.