How to Get Your WiFi Channels Right
There is a dirty little secret in the world of enterprise Wi-Fi: auto-channel selection doesn't work very well. Every wireless LAN vendor has it. Every wireless LAN vendor promotes it. But when the Wi-Fi gets busy or crowded of full of mobile devices, auto channels will leave users frustrated and admins confused.
What to do about enterprise auto-channel? Why, fix it, of course. Here are some tips for getting it fixed the right way.
First, the positive side of auto-channel: it saves you time. Auto-channel selection is one of the two primary parts of auto-RF protocols that are supported by enterprise controllers, APs and management systems. (The other part is auto-transmit power.) Auto-RF protocols automatically adjust channel numbers and transmit power levels on APs. Auto-RF protocols use information received by a large number of APs to decide when to adjust. What that means is that if an AP senses a microwave oven baking channel 11 every time Jessica re-heats her husband's delicious schnitzel in the break room, the AP can send that information back to the controller (or management system), and the controller (or management system) can move the AP to channel 1. Auto-RF saves you time both by making channel and transmit power changes when intermittent and/or unexpected problems like microwave ovens start interfering, but also by allowing you to avoid having to manually plan out channel maps when deploying a large wireless network. (Think about it. Do you really want to sit there in front of floor plans for hours on end trying to figure out where channels 1, 6 and 11 will work best? No. You want to sit in front of a floor plan for hours on end admiring the giant green blob you created when you did your site survey.)
One problem with auto-RF is that it's not perfect. But what is, right? Outback Steakhouse doesn't taste as good as Ruth's Chris. Outback probably flash-freezes their "beef", ships it a billion-jillion miles and lets it sit in a locker until some poor sucker drinks one too many Steveweisers and gets a hankerin' for "steak". Ruth's Chris is hand-made by professionals (I think). It pairs brilliantly with some (ostensibly) fresh asparagus and a (probably) locally grown baked potato. The point is that auto-RF is the Fast Food of Wi-Fi deployments. It gets the job done quickly, cheaply and poorly.
Sometimes, you can get away with auto-RF. If you have the budget to hang a lot of APs and if you have very few users (by today's standards, "relatively few" means 25 or fewer users per AP radio), then auto-RF will rarely fail. Most Wi-Fi networks, however, will see problems with auto-RF. Users' personal devices or neighboring offices or those pesky microwave ovens reheating Jessica's husband's delicious schnitzel will kill wireless performance. And though it's tempting to write a passive-aggressive note to the neighbors, tell your users to just use cellular or ask Jessica to just bring a ham sandwich, ultimately we are in the business of support. So, if you want to support Wi-Fi that is failing, you have to fix the channel assignments that auto-RF has given your APs.
Fixing auto-RF means manually configuring AP channels and transmit power, and the latter is the easy part. Enterprise WiFi deployments that support personal devices should have APs set to a transmit power between 12 dBm and 16 dBm. The goal is to set the transmit power of APs to the typical level of device transmit power, and I have found that starting at 14 dBm works well.
Configuring AP channels is where fixing auto-RF gets difficult. The fundamental flaw in auto-RF channel selection is that APs are only able to see RF that hits the AP. APs are unable to see RF that hits devices, because controllers and other management solutions do not have the ability to force devices to supply RF information. (Most likely, the reason is battery life. Transmitting causing a WiFi radio to consume more power than any other activity. Feeding RF information to a controller would cause a smartphone/tablet/laptop to transmit extra frames.) The problem is that it's not all that easy for wireless admins to see the RF that hits devices, either. To find out which APs are hitting my laptop and which channel those APs are on and which rates those APs support and how strong the signal is from those APs, I need to be looking at my laptop. Once I'm on my laptop, I can do it. To wit, here is what my laptop sees right now, as I sit in the meeting room of my friend's film production office:
Looking at that Scan from Wireless Diagnostics gives me information about which channel works best for the "Rough & Tumble" AP. The AP is on channel 11 and that makes sense. For the most part.
Actually, in looking at that Wireless Diagnostics scan, I'm not so sure that Channel 11 does make sense. There are no neighboring APs on channel 11, which is good. Channel 6 is lousy with APs, so I would surely want to avoid that channel. But what about channel 1?
In the picture above, channel 1 looks like it could be the best option. There is a TimeWarner Cable AP on channel 3 (from Ruckus Wireless, which I can tell both by the fact that I've been told that Ruckus provides APs for TWC's outdoor WiFi network in Los Angeles, and by the fact that the darned ChannelFly auto-RF protocol is setting the AP to channel 3... and, as a TWC customer, I can tell you that TWC's WiFi is poor... and, as a WiFi guy, I can tell you that one of the many reasons TWC's WiFi is poor is that ChannelFly is enabled... which is what I'm discussing in this blog post... which I'll resume, now), which could cause some amount of interference with channel 1. However, I know that TWC's WiFi has extraordinarily low user uptake (primarily because of the senseless captive portal that TWC uses for subscriber authentication), so it is unlikely to cause heavy interference. The AP on channel 7 (which could cause interference on channel 11), on the other hand, appears to not be a infrequently used guest wireless network. It appears to be normal, small business WiFi. So, on balance, I'd rather run the risk of interference from TWC's infrequently used guest WiFi than from a neighbor's possibly-frequently used small business WiFi.
The only problem is that the scan shown above only tells part of the story. Check out a Wireless Diagnostics scan I did while sitting at a Producer's desk, which is in an office that is further from the Rough & Tumble AP:
Look at the difference there, especially on channel 1. Channel 1 is crowded, all of a sudden. This is a scan done using the same MacBook in the same office space, but the nearby networks are very different. There are THREE access points on channel 1 that didn't even appear when scanning in the meeting room. That's what I mean by APs and devices being hit by different RF when in different locations. In the meeting room, channel 1 is arguably the best channel. In the Producers' office (correct punctuation; there are two Producers here) -- where the WiFi matters the most -- channel 11 is definitely the best channel.
***
Fixing auto-RF requires a bit of leg work. It is unrealistic to expect a wireless admin go to the location of every problem and run a Scan in Wireless Diagnostics. What can work, at least in my experience, is recruiting a helpful soul to assist in the effort. If an office manager or other member of the administrative staff is present on site, it may be possible to teach him or her a few simple steps for doing a channel scan:
STEP 1: Install a wireless scanner.
Every major operating system has one that is available for free:
-Mac OS X: Wireless Diagnostics (part of the operating system)
-Apple iOS: Airport Utility (the Scan function must be enabled in the app's Settings)
-Android: WiFi Analyzer (make sure you get the on from the developer, "farproc")
-Windows: Acrylic WiFi (the free version does adequate scanning)
STEP 2: Go to the location of the problem.
Radio frequency can change greatly when locations change. To identify the best channel for a specific area, the scan needs to be done from that area.
STEP 3: Get a screenshot of the scanner.
Every operating system has a way to get basic screenshots, from PrintScreen in Windows to Command-Shift-4 in Mac OS X to different button combinations on smartphones and tablets.
STEP 4: Email the screenshot to the wireless admin.
In some cases, multiple locations may have to be scanned. There are cases where changing a channel to solve a problem in one location can create a problem in another location.
My experience has been that office managers and other administrative staff get as frustrated by WiFi problems as anyone else. If the WiFi scan is presented as a simple task, then even non-technical people are often willing to help.
What to do about enterprise auto-channel? Why, fix it, of course. Here are some tips for getting it fixed the right way.
First, the positive side of auto-channel: it saves you time. Auto-channel selection is one of the two primary parts of auto-RF protocols that are supported by enterprise controllers, APs and management systems. (The other part is auto-transmit power.) Auto-RF protocols automatically adjust channel numbers and transmit power levels on APs. Auto-RF protocols use information received by a large number of APs to decide when to adjust. What that means is that if an AP senses a microwave oven baking channel 11 every time Jessica re-heats her husband's delicious schnitzel in the break room, the AP can send that information back to the controller (or management system), and the controller (or management system) can move the AP to channel 1. Auto-RF saves you time both by making channel and transmit power changes when intermittent and/or unexpected problems like microwave ovens start interfering, but also by allowing you to avoid having to manually plan out channel maps when deploying a large wireless network. (Think about it. Do you really want to sit there in front of floor plans for hours on end trying to figure out where channels 1, 6 and 11 will work best? No. You want to sit in front of a floor plan for hours on end admiring the giant green blob you created when you did your site survey.)
One problem with auto-RF is that it's not perfect. But what is, right? Outback Steakhouse doesn't taste as good as Ruth's Chris. Outback probably flash-freezes their "beef", ships it a billion-jillion miles and lets it sit in a locker until some poor sucker drinks one too many Steveweisers and gets a hankerin' for "steak". Ruth's Chris is hand-made by professionals (I think). It pairs brilliantly with some (ostensibly) fresh asparagus and a (probably) locally grown baked potato. The point is that auto-RF is the Fast Food of Wi-Fi deployments. It gets the job done quickly, cheaply and poorly.
Sometimes, you can get away with auto-RF. If you have the budget to hang a lot of APs and if you have very few users (by today's standards, "relatively few" means 25 or fewer users per AP radio), then auto-RF will rarely fail. Most Wi-Fi networks, however, will see problems with auto-RF. Users' personal devices or neighboring offices or those pesky microwave ovens reheating Jessica's husband's delicious schnitzel will kill wireless performance. And though it's tempting to write a passive-aggressive note to the neighbors, tell your users to just use cellular or ask Jessica to just bring a ham sandwich, ultimately we are in the business of support. So, if you want to support Wi-Fi that is failing, you have to fix the channel assignments that auto-RF has given your APs.
Fixing auto-RF means manually configuring AP channels and transmit power, and the latter is the easy part. Enterprise WiFi deployments that support personal devices should have APs set to a transmit power between 12 dBm and 16 dBm. The goal is to set the transmit power of APs to the typical level of device transmit power, and I have found that starting at 14 dBm works well.
Configuring AP channels is where fixing auto-RF gets difficult. The fundamental flaw in auto-RF channel selection is that APs are only able to see RF that hits the AP. APs are unable to see RF that hits devices, because controllers and other management solutions do not have the ability to force devices to supply RF information. (Most likely, the reason is battery life. Transmitting causing a WiFi radio to consume more power than any other activity. Feeding RF information to a controller would cause a smartphone/tablet/laptop to transmit extra frames.) The problem is that it's not all that easy for wireless admins to see the RF that hits devices, either. To find out which APs are hitting my laptop and which channel those APs are on and which rates those APs support and how strong the signal is from those APs, I need to be looking at my laptop. Once I'm on my laptop, I can do it. To wit, here is what my laptop sees right now, as I sit in the meeting room of my friend's film production office:
Looking at that Scan from Wireless Diagnostics gives me information about which channel works best for the "Rough & Tumble" AP. The AP is on channel 11 and that makes sense. For the most part.
Actually, in looking at that Wireless Diagnostics scan, I'm not so sure that Channel 11 does make sense. There are no neighboring APs on channel 11, which is good. Channel 6 is lousy with APs, so I would surely want to avoid that channel. But what about channel 1?
In the picture above, channel 1 looks like it could be the best option. There is a TimeWarner Cable AP on channel 3 (from Ruckus Wireless, which I can tell both by the fact that I've been told that Ruckus provides APs for TWC's outdoor WiFi network in Los Angeles, and by the fact that the darned ChannelFly auto-RF protocol is setting the AP to channel 3... and, as a TWC customer, I can tell you that TWC's WiFi is poor... and, as a WiFi guy, I can tell you that one of the many reasons TWC's WiFi is poor is that ChannelFly is enabled... which is what I'm discussing in this blog post... which I'll resume, now), which could cause some amount of interference with channel 1. However, I know that TWC's WiFi has extraordinarily low user uptake (primarily because of the senseless captive portal that TWC uses for subscriber authentication), so it is unlikely to cause heavy interference. The AP on channel 7 (which could cause interference on channel 11), on the other hand, appears to not be a infrequently used guest wireless network. It appears to be normal, small business WiFi. So, on balance, I'd rather run the risk of interference from TWC's infrequently used guest WiFi than from a neighbor's possibly-frequently used small business WiFi.
The only problem is that the scan shown above only tells part of the story. Check out a Wireless Diagnostics scan I did while sitting at a Producer's desk, which is in an office that is further from the Rough & Tumble AP:
Look at the difference there, especially on channel 1. Channel 1 is crowded, all of a sudden. This is a scan done using the same MacBook in the same office space, but the nearby networks are very different. There are THREE access points on channel 1 that didn't even appear when scanning in the meeting room. That's what I mean by APs and devices being hit by different RF when in different locations. In the meeting room, channel 1 is arguably the best channel. In the Producers' office (correct punctuation; there are two Producers here) -- where the WiFi matters the most -- channel 11 is definitely the best channel.
***
Fixing auto-RF requires a bit of leg work. It is unrealistic to expect a wireless admin go to the location of every problem and run a Scan in Wireless Diagnostics. What can work, at least in my experience, is recruiting a helpful soul to assist in the effort. If an office manager or other member of the administrative staff is present on site, it may be possible to teach him or her a few simple steps for doing a channel scan:
STEP 1: Install a wireless scanner.
Every major operating system has one that is available for free:
-Mac OS X: Wireless Diagnostics (part of the operating system)
-Apple iOS: Airport Utility (the Scan function must be enabled in the app's Settings)
-Android: WiFi Analyzer (make sure you get the on from the developer, "farproc")
-Windows: Acrylic WiFi (the free version does adequate scanning)
STEP 2: Go to the location of the problem.
Radio frequency can change greatly when locations change. To identify the best channel for a specific area, the scan needs to be done from that area.
STEP 3: Get a screenshot of the scanner.
Every operating system has a way to get basic screenshots, from PrintScreen in Windows to Command-Shift-4 in Mac OS X to different button combinations on smartphones and tablets.
STEP 4: Email the screenshot to the wireless admin.
In some cases, multiple locations may have to be scanned. There are cases where changing a channel to solve a problem in one location can create a problem in another location.
My experience has been that office managers and other administrative staff get as frustrated by WiFi problems as anyone else. If the WiFi scan is presented as a simple task, then even non-technical people are often willing to help.
***
If you like my blog, you can support it by shopping through my Amazon link. You can also donate via Paypal below, or by sending Bitcoin to 1N8m1o9phSkFXpa9VUrMVHx4LJWfratseU
ben at sniffwifi dot com
Ben,
ReplyDeleteAn interesting post, thanks! In my view, in a large environment, the static assignment of channels (and power levels for that matter) would be a last resort. My feeling is that it can lead to more complications in the future, when the environment changes, as it eventually will. What works today may be the source of another problem in a month or 3 years down the line. Maybe I am naive but I do see some positive results from DCA/EDRRM on Cisco controllers, I would never say it is fantastic, but I often see cases where it has done the 'right thing'.
Have you ever seen the need to statically assign 5Ghz channels on your radios, or is this typically a 2.4Ghz activity?
Regarding the radio power management, for me this is the biggest cause of problems. The out of the box TPC settings on Cisco WLCs really must be tuned for the RF environment, setting min/max EIRP to limit the scope of power that TPC can select. I've seen a lot of instances where radios are running at far too low or high a power. I like the idea of using RF profiles to do create a set of standardised configurations that cover common RF environments, to avoid tuning each radio individually.
I agree that 5 GHz often works fine with RRM/ARM/ChannelFly. I think your description of 2.4 GHz, however, is incorrect. 2.4 works better with static channels.
ReplyDeleteBen I think you should have compared Ruth's Chris with Sizzler or something like that. Everyone I talk to says the difference in taste between Outback and Ruth's Chris isn't enough for the 2-3 times price difference :-)
ReplyDelete