Cisco Optimised Roaming

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?
Yes Disabled (default) Deauth!
Yes No None
Yes Yes Deauth!

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.

3 thoughts on “Cisco Optimised Roaming”

  1. Excellent article William!

    It got me thinking though, in regards to how to ensure that these configurations are working ‘together’ correctly.

    For example, If you have RX-SOP configured to -75, wouldn’t this ‘take priority / overwrite’ any configurations you have for Optimized Roaming if they are ‘weaker’ than -75 (say -79) ? A client would never get to that -79 threshold to trigger the deauth, because RX-SOP already spat him out back at -75 right?

    Or how about the lowest mandatory data rate?

    The RSSI value that is tied to 24Mbps is -89 according to the 2702i datasheet. If Optimized Roaming requires both RSSI and Data Rate to be violated, would you have to ensure that when you configure the RSSI value in the CHD section, that it matches up with the data rate value associated to it ? I would think that its based on per-access point model and not a general link between the two.

    Would those values essentially be bypassed or ignored since your RX-SOP is set to a stricter threshold ?

    I wonder if you have to ensure that they are all ‘lined up’ for RX-SOP and Optimized Roaming to work together cohesively.

    I look forward to your reply !


    1. Hi Nolan,

      Sorry I’ve neglected to reply to your comment, I haven’t paid the blog much attention in the last few weeks due to work being rather busy and for some reason I also didn’t get a notification there was a comment pending!

      Anyway, in response to your comment – RX-SOP is a brick wall filter, so yes if it is set higher than optimised roaming you will find you have ignored the clients before you get to the point of CHDM/OR taking action, yes you need to think about how the two features interact with each other but don’t overthink it, if you are below RX-SOP the client will be ignored by that radio, if you violate the min-RSSI value for OR the system will deauth the client, just make sure they happen in the right order! 🙂 – This gets harder in high density / very high density, but some feature enhancements to optimised roaming are on the cards to help with this, and remember you can also use RF-Profiles to set CHDM thresholds for specific groups of APs.

      Minimum data rate is something I need to look up a bit more I think, but again in a clean environment an AP may be able to demodulate 24Mbps @ -89, out in the real world I’m not sure it would. I don’t normally make use of the minimum data rate option when using optimised roaming, but discussing the feature with some folks from Cisco a few weeks ago on an event I learned they were normally setting this at the minimum supported rate of the network, i.e. if you get down that low you should either be outside our intended coverage area or well at the intended edge of a given cell.

  2. hi Will,

    I’ve implemented Optimized Roaming in my network to deal with sticky clients, but it didn’t work as expected. As it appears CHD Data RSSI values in RF profiles doesn’t count and RSSI threshold from Global CHD config is taken. This info I received from TAC engineer, I have and I’m not sure whether behaviour changed in recent software versions.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.