Carrying on with my series of posts about the new features introduced in the recent 8.0 WLC code release is Optimised Roaming.
Not to be confused with “assisted roaming” introduced in 7.4 optimised roaming is a whole new feature. It is intended to help us solve the sticky client issue by forcing clients at the edge of a cell to move either to a new cell, or possibly onto 3G/4G connectivity.
I have been using optimised roaming with good results in high density networks recently, especially when coupled with RX-SOP.
Configuration & Logic:
Optimised roaming works by sending clients a deauth if they fall below a set of pre-defined thresholds, there are four globally configurable variables that influence the logic behind whether or not to send a client a deauth:
- Enable / Disable Optimised Roaming per-band
- Reporting Interval (seconds)
- Data Rate Threshold (mbps)
- RSSI Threshold (set via CHDM)
Let’s look at what these variables do individually:
Enable / Disable – Global config to turn on or off optimised roaming for either band.
Interval – This is how many seconds a client needs to have fallen below the defined acceptable thresholds before action will be taken, the configurable range is 5-90 seconds (90 default).
Data Rate – Works in tandem with the RSSI threshold and if set acts as a gating function, both thresholds must be violated in order for optimised roaming to send a deauth (default disabled).
Data RSSI – Follows the value configured for Data RSSI under RRM > Coverage at a global level and also can be configured at the RF-Profile level. This sets the RSSI level at which clients will be sent a deauth. If used with Client Low RSSI Check enabled the higher of the two values is used.
The following table shows when action would be taken depending on what options you have configured:
|Below Data RSSI?||Below Data Rate?||Action Taken?|
Optimised Roaming & Low RSSI Check:
Low RSSI check is a stand alone feature in its own right and specifies an RSSI threshold which a client has to be above in order to associate to the AP. The optimised roaming logic checks both values and they must both pass in order for a client to connect.
Optimised roaming has a 6dB hysteresis as part of its algorithm in order to help prevent a client flapping between access points after a deauth event.
For example, if the Data RSSI value was set to -75dBM a client that has been deuathed from an AP must improve its connection by at least 6dB in order to be able to reconnect, i.e. it must be able to connect at -69dBm.
Debugging & Monitoring:
There are no specific debug commands for optimised roaming at the moment, however you can check the number of clients that have been sent a deauth on the GUI under Monitor > Statistics > Optimised Roaming or on the CLI:
show advanced 802.11a/b optimized-roaming stats
You can also debug on a client and watch for reason 4 messages:
debug client xx:xx:xx:xx:xx:xx debug dot11 mobile enable debug dot11 state enable
Real World Configurations & Experiences:
As I mentioned at the start of this post I have been using this feature in the real world with good results and also combining it with RX-SOP in high-density deployments. I also use this feature alongside 802.11k. It seems there were also some bugs in the initial 8.0 code release although these have allegeldy been resolved in the recent 8.0 mr1 release (see CSCuq40682).
There is not a lot more to do with this other than turn it on and see how it works, I would say you need to have a good density of access points in your coverage areas as unlike features such as Aruba’s ClientMatch which considers where the client may be able to roam to and indeed helps direct it there by denying association where we do not want the client to connect optimised roaming is not (at least at the moment) that deterministic.
As I understand it optimised roaming is also not application aware and you would probably not want to enable this on a network with voice traffic or anything that may be upset by the deauth and the interruptions to connectivity whilst we wait for the client to reconnect.
I have found that using an interval of between 15-30 seconds works best for most of my deployments depending on how mobile the clients are, it would be really nice if we could configure this at the RF-Profile level too i.e. have a more frequent check for transit areas in a building vs locations where people may be less mobile.
Be careful not to set the Data RSSI too aggressively, you need to take it high enough to make the system actually take action but be even in networks where I have a great density of access points and good coverage from multiple radios I have often found this works best with a value aimed at removing the worst behaving clients from a given cell. Also consider the 6dB hysteresis when you are setting this value, if a client moves away from a cell and back again you need to make sure it can reconnect reasonably easily.
Typically I am running with a data RSSI value of between -73 and -76 and may configure a higher value such as -71 or above for an auditorium.
I’d love to hear from others who are using this in production networks, it is a very new feature and as such documentation and configuration guidelines are thin on the ground.