802.11k: The Final Nail in the Coffin for RRM and ARM
Auto-channel selection protocols have been an increasingly common source of controversy for enterprise Wi-Fi administrators. Aruba's ARM, Cisco's RRM, Ruckus's ChannelFly and Aerohive's ACSP all allow a centralize management entity -- either controller or software -- to automatically set the channels of access points (APs). These protocols can be big time savers during the surveying and implementation stages, but also can cause big headaches once the Wi-Fi is up and running.
The argument over whether to use auto-channel selection protocols may be coming to an end, however. 802.11k is becoming more widely supported in Wi-Fi devices, and when smartphones, tablets and other devices support 802.11k, the decision is a no-brainer: auto-channel should be avoided because it makes roaming worse.
To understand the impact that 802.11k (radio resource measurement) has on Wi-Fi devices, one first must understand a fundamental fact about Wi-Fi: devices control connections. Smartphones, laptops and other Wi-Fi devices get to choose which AP to connect to, when to start looking for new APs, which AP to choose when roaming and when to disconnect from Wi-Fi altogether and try to use cellular (if applicable). The 802.11v (wireless network management) protocol has features that may allow APs, controllers or network management software to control Wi-Fi device connections in the future, but today 802.11v is merely a suggestion of how the network wants devices to behave.
The fact that Wi-Fi devices control connections has long been a source of frustration for network administrators and other Wi-Fi professionals, but it makes sense. The device knows its radio frequency (RF) environment. The APs don't. And without accurate knowledge of a device's RF environment, poor connection decisions are likely to be made.
Another thing that must be understood in order to gauge the impact of 802.11k is how the Wi-Fi roaming process works. When a device makes the decision to roam (usually based on low received signal [RSSI], but possibly taking missed AP Beacons into account as well), the device enters Discovery. A device in Discovery will scan the environment; looking for a new AP that is using the same SSID.
The problem is that Discovery can take a long time. Since a Wi-Fi radio (device or AP) can only operate on one channel at a time, devices may have to waste time scanning channels that do not have any available APs.
Where 802.11k fits in is that it speeds up Discovery. 802.11k allows devices, in the words of Apple Support, to "speed up [their] search for nearby APs that are available as roaming targets by creating an optimized list of channels". 802.11k devices use something called "neighbor reports" to store lists of nearby BSSIDs (which are just APs' MAC addresses) along with each BSSID's channel. 802.11k-enabled Wi-Fi devices then use those neighbor reports to begin Discovery on channels that have (or, in some cases, had) APs on them.
When ARM or RRM or ChannelFly or ACSP or any other auto-channel protocol is used, APs may change channels. In fact, they often do change channels. And as soon as an auto-channel protocol forces an AP to change channels, nearby Wi-Fi devices' 802.11k neighbor reports become invalid. For example, a roaming smartphone may "remember" that an available AP was on channel 36, but Aruba's ARM may have already moved that AP off of channel 36. The 802.11k-supporting device would then waste valuable Discovery time looking for an AP that has moved to a different channel.
All Apple iOS devices support 802.11k, as do all devices certified by the Wi-Fi Alliance as Voice-Enterprise. If a Wi-Fi network supports any 802.11k devices, then Cisco RRM, Aruba ARM, Ruckus ChannelFly, Aerohive ACSP and any other similar protocol will negatively affect mobile devices. If the goal is to have the best possible Wi-Fi, then 802.11k should be the final nail in the coffin for those auto-channel protocols.
***
The argument over whether to use auto-channel selection protocols may be coming to an end, however. 802.11k is becoming more widely supported in Wi-Fi devices, and when smartphones, tablets and other devices support 802.11k, the decision is a no-brainer: auto-channel should be avoided because it makes roaming worse.
To understand the impact that 802.11k (radio resource measurement) has on Wi-Fi devices, one first must understand a fundamental fact about Wi-Fi: devices control connections. Smartphones, laptops and other Wi-Fi devices get to choose which AP to connect to, when to start looking for new APs, which AP to choose when roaming and when to disconnect from Wi-Fi altogether and try to use cellular (if applicable). The 802.11v (wireless network management) protocol has features that may allow APs, controllers or network management software to control Wi-Fi device connections in the future, but today 802.11v is merely a suggestion of how the network wants devices to behave.
The fact that Wi-Fi devices control connections has long been a source of frustration for network administrators and other Wi-Fi professionals, but it makes sense. The device knows its radio frequency (RF) environment. The APs don't. And without accurate knowledge of a device's RF environment, poor connection decisions are likely to be made.
Another thing that must be understood in order to gauge the impact of 802.11k is how the Wi-Fi roaming process works. When a device makes the decision to roam (usually based on low received signal [RSSI], but possibly taking missed AP Beacons into account as well), the device enters Discovery. A device in Discovery will scan the environment; looking for a new AP that is using the same SSID.
The problem is that Discovery can take a long time. Since a Wi-Fi radio (device or AP) can only operate on one channel at a time, devices may have to waste time scanning channels that do not have any available APs.
Where 802.11k fits in is that it speeds up Discovery. 802.11k allows devices, in the words of Apple Support, to "speed up [their] search for nearby APs that are available as roaming targets by creating an optimized list of channels". 802.11k devices use something called "neighbor reports" to store lists of nearby BSSIDs (which are just APs' MAC addresses) along with each BSSID's channel. 802.11k-enabled Wi-Fi devices then use those neighbor reports to begin Discovery on channels that have (or, in some cases, had) APs on them.
When ARM or RRM or ChannelFly or ACSP or any other auto-channel protocol is used, APs may change channels. In fact, they often do change channels. And as soon as an auto-channel protocol forces an AP to change channels, nearby Wi-Fi devices' 802.11k neighbor reports become invalid. For example, a roaming smartphone may "remember" that an available AP was on channel 36, but Aruba's ARM may have already moved that AP off of channel 36. The 802.11k-supporting device would then waste valuable Discovery time looking for an AP that has moved to a different channel.
All Apple iOS devices support 802.11k, as do all devices certified by the Wi-Fi Alliance as Voice-Enterprise. If a Wi-Fi network supports any 802.11k devices, then Cisco RRM, Aruba ARM, Ruckus ChannelFly, Aerohive ACSP and any other similar protocol will negatively affect mobile devices. If the goal is to have the best possible Wi-Fi, then 802.11k should be the final nail in the coffin for those auto-channel protocols.
***
If you like my blog, you can support it by shopping through my Amazon link. You can also donate Bitcoin to 1N8m1o9phSkFXpa9VUrMVHx4LJWfratseU
Twitter: @Ben_SniffWiFi
Twitter: @Ben_SniffWiFi
ben at sniffwifi dot com
Ben,
ReplyDeleteThought provoking as always, but I'll bite on this one...typical response from a vendor guy, I know.
First, historically, mobile devices don't proactively build neighbor lists with 11k when they first associate to an AP. They do it when they've reached some threshold near roaming, or even when the roam trigger occurs. So they wouldn't be hanging on to a stale list for many hours, or even many minutes. They do a neighbor request, get a neighbor report, and go a'scanning.
Second, I don't understand why some extra scanning delay for a limited sample of client devices makes auto channel assignment somehow moot. If we have to pick and choose (I find this to be a false dichotomy anyway), I would much rather have clients scan a little longer (or, POSSIBLY scan a little longer) for a very brief span of time and still have an infrastructure that can auto-adjust for capacity or avoid interference.
Third, AP neighbors will update their own neighbor lists every 10 minutes or less (on 5 GHz, based on some normal default background scan intervals across vendors), so even if an AP does change channels, you're talking about a small window of potential impact. And many solutions also have control channels by which APs can be informed about neighbor APs operating channels, so this gap of outdated neighbor lists on the AP becomes seconds instead of minutes.
Fourth and finally, channel changes should not be that common in an enterprise environment. Admittedly, ChannelFly can be the most aggressive (i.e. most channel changes) algorithm out there (and it's not the right choice for many controlled environments), but even ChannelFly will change maybe once a day. I've sampled many higher ed deployments (with many different vendors) in the past and found that channel change events happen very infrequently...campuses of 1,000+ APs were reporting 50 or less total channel change events monthly. So we're talking about a severely minor amount of disruption; and "disruption" is an extreme over-statement of the impact.
Marcus,
DeleteAll fair points, but the overarching conclusion remains that auto-channel does more harm than good to Wi-Fi quality.
First, keep in mind that my primary criticism of ChannelFly, et al. is that they choose bad channels. With an enterprise riddled with APs on sub-optimal channels and with too many AP radios enabled, you get bad Wi-Fi 99% of the time in exchange for the 1% possibility that auto-channel will help you if a transient interference source pops up. The problem of auto-channel messing up 802.11k by changing channels is secondary.
Secondly, I've noticed a distinct pattern in iOS devices where they begin discovery on channels that are known to be occupied by APs that are using the same SSID. This happens even after the iOS device's first association. I've also noticed a distinct improvement in how smooth the roam is if iOS devices are roaming in an environment where known APs are still on the same channel that they were on when the iOS device was associated to them.
The fact that APs can inform other APs of channel changes is nice and could mitigate 802.11k roaming problems in some cases. The problem is that not only would the APs have to send an update, but devices would have to be awake to listen to it. I have not seen devices, including iOS devices, be particularly active in requesting neighbor reports. And if the device doesn't request the neighbor report, then there is a definite possibility that the device will miss the channel updates if an AP sends an unrequested neighbor report.
This makes sense in many environments but if used in a distribution/manufacturing facility which has RF impacts from changing materials in bins, stack heights, and vehicles loading/unloading then the auto channel is actually pretty important. Granted I'm a strong advocate of good channel planning and RF design lessening the need for this kind of band aid but in many of my customers environments this is a highly requested and used feature that is helpful in their 24/7 usage world.
DeleteObviously I've never been to these facilities, but I'm skeptical. Though I'll concede the point that RRM/ARM is far more damaging in 'carpeted' spaces.
DeleteAs far as I know, when AP is about to change channel it sends an announcement. Clients should be able make use of it. Mifht be proprietary Zebra/Motorola thing, though, or I completely misuderstood.
ReplyDeleteA,
DeleteClient devices need to be able to hear the channel switch announcement in order to use it. If my iPhone has roamed to a new AP on a different channel, then my iPhone would not hear the channel switch announcement that the old AP sends.