BackgroundCo-channel interference (CCI), co-channel contention (CCC)...whatever you want to call it (I'm growing quite fond of the term "Co-channel Chatter"), is a blight in many WiFi networks. In all but the most isolated and carefully designed of wireless LANs, it lurks, waiting to disrupt the efficient operation of our WiFi network.
As the number of WiFi networks rises, AP channel-widths increase (with newer WiFi standards) and the population of WiFi devices explodes, the growing spectre of CCI/CCC increases steadily over time. In simple terms, if you deploy a wireless access point on a particular channel, it contends for access to the channel with any other access points (and clients) assigned to the same channel that are within "hearing range" of the AP. (Here's a linkto a very useful articlethat gives more background on this subject).
In an ideal world, each AP we deploy on a WLAN is assigned to a unique channel and is isolated sufficiently (from an RF perspective) so that it cannot "hear" any other APs on the same channel. This will ensure that they are at a sufficiently low level that they not will impinge on the AP's clear channel assessment (CCA) process. In this ideal scenario, our AP will not have to contend with any other APs for access to the RF channel. Therefore, it will be able to service the needs of its associated clients with all of the bandwidth (air-time) that is theoretically available, within the limitations of the client and AP standard support.
However, the real world is rarely like this. All too often, APs from neighboring networks or even APs on our own network will operate on the same channel that a particular AP may be using. APs on the same channel may "hear" each other and will have to contend for (i.e. share) access to the RF channel that they are all using. This limits the potential data throughput that may be offered by each AP.
(Note: this is something of a simplified explanation, as there are additional CCC effects from WLAN clients. However this will suffice for the point I am trying to demonstrate.)
Channel Utilization StatisticsFor a while, I have been troubled by the question: "how does the world (well, channel) look from an AP's point of view?" If an AP is assigned to a channel, how busy does that channel look from its perspective? I'm not talking about data the AP may itself be passing over the channel, but the level of traffic it perceives, including "chatter" from other APs and clients on the same channel.
Understanding how busy the channel is by considering all sources tells us how often the AP has an opportunity to use the channel. It mayalso give us a indication of how much co-channel contention (CCI/CCC) our AP may be exposed to. Once we know how busy a channel is, we can decide whether using this channel is viable for our AP.
In the Cisco AireOS solution (traditional 5508/2504 controller solution), each AP has a set of statistics available from the WLC GUI that show the AP's channel utilization. The screen shot below shows the AP channel statistics ("Load Statistics") available. Theses are available from GUI option:
Monitor > Access Points > Radios > 802.11x/y/z > AP Name
|Figure 1 - AP Channel Utilization Stats|
The "Rx Utilization" and "Tx Utilization" figure indicate the level of traffic (%) sent and received by the AP itself.
Channel Utilization indicates how much 802.11 traffic the AP can "hear" on its channel, from all sources. The statistic is a percentage figure (15% in the example shown). This will include all 802.11 frames that the AP can hear from all APs and clients in the vicinity. It indicates the amount of time that the AP considers the channel to be busy.
High Channel UtilizationThis is incredibly useful. For one thing, we can see when our channel is "full". Once we hit 100%, no amount of additional APs is going to improve things and allow us to accommodate more traffic - all air-time (i.e. opportunities to transmit) is being used up. The utilization may be caused by our own AP, by nearby clients or by nearby APs using the same channel. Whatever the reason, having the ability to detect a highly utilized channel means that we can come up with a strategy to try to fix the situation.
A typical concern in new WLANs is the effect of APs in our own WLAN network that are using the same channel. We have a finite number of channels to use, so channel re-use is inevitable in all but the simplest of networks. Although we may have planned our network channels carefully, just how "clear" or "available" is the channel we have chosen for each AP? The channel utilization statistic give us an excellent view of this aspect of a channel, from the AP's viewpoint. If we choose a channel and the channel utilization statistic is low, we're probably in pretty good shape.
I recently installed a new wireless network which required a fairly dense deployment of access points. Co-channel interference was unavoidable in some areas and had to be minimized as far as possible. In some areas of the network, the Channel Utilization statistic revealed that the channel used by some APs was being heavily utilized (around 60%). The question I had was: "Is this due to client traffic, or the effect of co-channel interference from other APs nearby?" By waiting until the end of day, I saw that the channel utilization did, in fact, fall down to much lower levels once all users (and their clients) had gone home for the day. The majority of the channel utilization was down to real client traffic, rather than CCI from nearby APs (which was a relief).
Lab TestTo demonstrate the effect of CCI on the Channel Utilization statistic, I ran up some APs in my home lab and placed them on the same channel to deliberately cause AP CCI. I used the 2.4GHz band, created several SSIDs and configured the AP radios to support rates down to 1Mbps to chew up some air-time. By varying the number of APs on the channel and the number of SSIDs being broadcast, we can see the effect on the channel utilization from the point of view of our test AP.
Here are the results:
1. The first test had 3 SSIDS, with 1 AP enabled. I also had a neighbor's home network using the same channel which was adding to the channel utilization observed. The channel used (channel 11) was running at around 16% utilization:
|Figure 2 - 1AP, 3SSIDs|
|Figure 3 - 2 APs, 3SSIDs|
3. Next, I added a third AP, again running the same 3 SSIDs on channel 11. This bumped the channel utilization up to 33% with the additional beacon traffic.
|Figure 4 - 3 AP, 3 SSIDs|
4. Finally, I doubled the number of SSIDs to 6 across all 3 APs. This again bumped up the beacon traffic and increased utilization to 54%:
|Figure 5 - 3 APs, 6 SSIDs|
Note that in all cases, only new SSIDs and APs were being added to the equation - little or no client traffic was being generated to cause this effect. This was due to the CCI/CCC being added by the beacons being broadcast by the APs on the same channel.
Although in the real world, not all channel utilization is caused by AP CCC/CCI, channel utilization can be a useful indication, particularly if you compare levels in-hours and out-of-hours (when client numbers are very low).
(Note: channel utilization statistics update around every minute or so - they are not dynamic)
CLI Utilization Stats
If you're a 'CLI' sort of person, you may prefer to look at this information from the CLI of your WLC. You can pull the same information using the commands:
show ap auto-rf 802.11b <ap name>
show ap auto-rf 802.11a <ap name>
You'll get an output similar to the output shown below when you run the command.The channel utilization information is highlighted below in the example using red text:
(Note: channel utilization stats update around every minute or so - they are not dynamic)
Number Of Slots.................................. 2
AP Name.......................................... AP2600
MAC Address...................................... 44:2b:03:9a:xx:xx
Slot ID........................................ 0
Radio Type..................................... RADIO_TYPE_80211b/g
Sub-band Type.................................. All
Noise Profile................................ PASSED
Channel 1.................................... -95 dBm
Channel 2.................................... -94 dBm
Channel 3.................................... -76 dBm
Channel 4.................................... -85 dBm
Channel 5.................................... -93 dBm
Channel 6.................................... -78 dBm
Channel 7.................................... -88 dBm
Channel 8.................................... -91 dBm
Channel 9.................................... -92 dBm
Channel 10................................... -93 dBm
Channel 11................................... -93 dBm
Channel 12................................... -92 dBm
Channel 13................................... -92 dBm
Interference Profile......................... PASSED
Channel 1.................................... -77 dBm @ 7 % busy
Channel 2.................................... -128 dBm @ 0 % busy
Channel 3.................................... -128 dBm @ 0 % busy
Channel 4.................................... -128 dBm @ 0 % busy
Channel 5.................................... -128 dBm @ 0 % busy
Channel 6.................................... -83 dBm @ 2 % busy
Channel 7.................................... -81 dBm @ 7 % busy
Channel 8.................................... -128 dBm @ 0 % busy
Channel 9.................................... -128 dBm @ 0 % busy
Channel 10................................... -128 dBm @ 0 % busy
Channel 11................................... -128 dBm @ 0 % busy
Channel 12................................... -128 dBm @ 0 % busy
Channel 13................................... -128 dBm @ 0 % busy
Load Profile................................. PASSED
Receive Utilization.......................... 0 %
Transmit Utilization......................... 4 %
Channel Utilization.......................... 66 %
Attached Clients............................. 0 clients
Another great way to assess channel utilization is to use the WLC Configuration Analysis (WLCCA) tool from Cisco.
Briefly, the tool is a Windows application available for free from Cisco and provides an analysis of a WLC configuration. You simply load in the output of the show 'run-config' command from the WLC CLI. You can get it from : https://supportforums.cisco.com/document/7711/wlc-config-analyzer (access request required)
It does plenty more than showing AP channel utilization, but it provides a nice report showing both 2.4 and 5GHz channel utilization per AP. Here are the results from my lab:
|Figure 6 - WLLC AP Channel Utilization|
One other way of viewing AP channel utilization is to use the Cisco Prime Infrastructure management application.
If you have set up building and floor maps of your wireless LAN within CPI, one of the available maps views for access points is channel utilization. I don't have a graphic to add in to this article, but I'm sure you will be able to find it with a little experimentation.
How Do We Fix High Utilization?
Although my fixation with CCI/CCC has been the main focus of this article, high channel utilization will not necessarily be caused by CCI/CCC.
Here are a number of suggestions for sources of high channel utilization. By attending to one or more of these possible causes, we may cut down the levels of utilization observed, and improve the performance of our WLAN:
- WLAN support for low basic rate speeds: if your AP radios are configured to support lower, legacy basic-rate connection speeds, then much of the management traffic (e.g. beacons) that is exchanged will use the lowest available connection speeds. This causes the traffic to occupy more of the available air-time and takes longer to transmit (increasing channel utilization).
Support for lower speeds also provides wireless clients the opportunity to rate shift to use lower connection speeds as they move away from an AP and consume more air-time (increasing channel utilization).
- Channel planning: have a look at your WLAN channel planning. Do you have APs on the same channel that are perhaps contending to use the same channel (i.e. CCC/CCI)? This will be most obvious once users have gone home for the day and channel utilization levels remain high. Try adjusting channel allocations to avoid APs in close proximity using the same channel.
- Cell size adjustment: you might also try adjusting AP transmit power to reduce AP cell sizes (and hence how well APs can "hear" each other). One caveat of this approach is that it may affect the coverage experienced by clients in a negative way. You need to be very careful with this approach, or you may get calls about users who suddenly can't connect in a particular area. You might need to get the survey gear out for this one.
- Neighboring networks: high channel utilization may be caused by access points (or their clients) on neighboring WiFi networks. Check you rogue AP lists and see if they are operating on the same channel as your own WLAN APs.You may need to change your AP channel to avoid the neighboring network.
- Client traffic levels: it may be that a high level of channel utilization is simply due to a high level of client traffic. This might be caused by the number of clients connecting to an AP, or perhaps the type of traffic that some clients are imposing on the network (e.g. HD video). This would need careful analysis, with perhaps some attempts to more evenly distribute clients across APs or perhaps rate-limit specific applications.
In this article, we've taken a brief stroll through the Channel Utilization statistic available for Cisco APs. Hopefully it has provided some useful information to assess how busy an AP's channel appears from a channel availability perspective.
We've seen that it shows us the air-time utilization of a channel that an AP may be using. This can be very useful to understand whether a channel is appropriate for use. If it's too busy, we may be well-advised to select an alternative.
We also looked at how we might get an indication of CCC/CCI by comparing utilization levels in and out of hours.
We explored the various methods we can use to look at utilization figures, which included: the WLC GUI, WLC CLI, WLCCA and Prime Infrastructure.
Finally, we took a quick look at possible causes of high channel utilization and possible remediation of the issue.
What do we mean by Airtime Utilization? Free airtime describes how much time is available on a channel for data transmissions. Any time a device communicates with another device or an access point (AP) it uses airtime. Airtime Utilization is a per-channel statistic that defines what percentage of the channel is currently being used, and what percentage is therefore free. Airtime usage can come from:
- Data traffic to and from client devices
- Interference from WiFi and non-WiFi sources
- Management overhead from APs and client devices
WiFi is a shared medium, so the Airtime Utilization of a channel impacts all the devices currently connected to that specific channel. If Airtime Utilization is high, you might receive complaints about low WiFi speeds, or other issues. Since many factors can impact Utilization, it’s important to know what is causing the high usage. To do this, first determine if the high Utilization is periodic or consistent.
Periodic moments of high Utilization can be caused by an influx of devices connecting to the network all at the same time. This might happen during a conference or presentation when a larger-than-average number of devices crowd the network. Having historical data to monitor these trends is extremely valuable for understanding how to optimize the network design to support these situations.
However, if baseline Utilization is high, that’s a sign of another issue. It could be caused by a number of factors, including having too many SSIDs advertised; too many APs on the same channel; or non-WiFi interference from a microwave, Bluetooth, or other source. In order to resolve the issue, you must know what is causing it.
Wyebot’s Wireless Intelligence Platform™ (WIP) provides complete wireless ecosystem visibility, making it possible to easily discern where the issue lies and how it can best be resolved. WIP’s RF Analytics provide detailed information on Airtime Utilization, Non-WiFi Interference, and the Noise Floor (level of background noise). Data includes historical charts.
Whether Airtime Utilization has been high for months, or whether something happened in the last week, WIP’s client monitoring, RF Analytics, and real-time and historic data analysis provides insight into the health of the entire network, and the platform presents actionable steps for quick resolution.
I wish Wyze would officially address this, because if you go to the Ubiquiti section of reddit and ask about Wyze Cams, many many people have issues with multiple simultaneous streams saturating the 2.4ghz radio and bringing down the network.
As soon as I open more than 2 streams my 2.4ghz channel is at 100% utilization. If I connect my old router to my Ubiquiti AC LR. And then I connect the Wyze cams to the router, I can watch 4 streams at once with about 50-60% channel utilization. This issue seems to be Wyze Cams and Ubiquiti APs. I also have 32 devices connected to my AP. Without Wyze on my network 2.4ghz channel utilization hovers at 15-20%.
I won’t argue that all Ubiquiti AP users are affected, it could be that you are in a less congested area. Please test for yourself. See how many simultaneous streams you can open. 4? 5? 6? Are you just doing a little better than us Ubiquiti users or is your performance vastly better? Because if it is vastly better maybe you can share your AP settings so that we can figure it out? Monitor the channel utilization in the Ubiquiti controller to get a better idea of how saturated your 2.4ghz radio is as you open each additional stream.
I've released unifi-poiler version 1.3.0. This update provides a new feature that allows you to print out the json payload from the Unifi controller. This is definitely not a solution to your missing data, but it may help us figure out "where" it is. To run the app in this mode, pass on the cli. Something like this:
If you have more than one site, it will help to specify only a single site in the up.conf config. Dumping data for multiple sites at a time is probably too much. These json payloads are large.
I'd recommend piping it through and into a file, so you can inspect it more closely:
Once you have this data, you have a few options:
- Figure out where your client counter is. On my APs it's called .
- Look for and try to figure out if they're empty or missing or renamed.
- Remove any personal info from the file and put it in a gist you can share with me, or attach it to this issue.
I'm sorry I don't have any real concrete advice for you. I've not had the opportunity yet to troubleshoot missing data like this. I'm just at a bit of a loss, and I'm hopeful it's an easy fix once I see your json. It may not be easy to understand this file if you're not familiar with Golang but I'll point out that it shows all the being stored in Influx from the UAPs. Compare these fields with the data returned by your controller to determine if things are missing or renamed. https://github.com/golift/unifi/blob/master/uap_influx.go
Looking forward to your update. Good luck!
Unifi channel utilization
Official Release Notes
I love Ubiquiti, even their security gateway. But there is a big even in there. While most UniFi equipment is a breeze to setup, the UniFi Security Gateway (USG, USG-PRO-4) can be a nightmare. One issue that arises is when a USG has an older version of the UniFi firmware and you need to upgrade it. Here are the steps I’ve learned to take when upgrading a UniFi Security Gateway.
- Download from Ubiquiti’s site the latest available firmware for the USG.
- Rename the file upgrade.tar.
- Run an ethernet cable between the LAN port on the USG and your workstation.
- Configure a static IP address in the same subnet as the USG – by default USG’s are configured with the IP 192.168.1.1 with a subnet of 255.255.0.0.
- Use WinSCP (or your favorite SCP client) to connect to the USG.
- Enter your username and password for the USG – by default the username and password are both ubnt.
- Upload the upgrade.tar into the home directory for the admin user (this, for me, has always been the default folder that opens when connecting via SSH/SCP).
- Exit your session in WinSCP.
- Use PuTTY (or your favorite SSH client) to connect to the USG.
- Again, enter your username and password.
- At the command line type: sudosyswrapper.sh upgrade upgrade.tar
- The system will spit out information about the install and then reboot itself.
- When the system comes back up (solid white or blue light) you can connect to the USG again to verify that the firmware took.
- Use the command info to view the current firmware from the USG command line.
At this juncture you should have a successfully updated USG.
Note: I didn’t come up with this on my own, see the Ubiquiti forum thread, “Can’t upgrade USG to newer firmware.” ilkevinli provides the meat of this solution, I’ve just added window dressing and taken away (what I sometimes find to be) the confusing conversation around the solution.
There is another discussion on this topic, “USG Cloud Controller Adoption – could it be more difficult???” but I recommend against using this thread as the accepted solution isn’t quite correct.
What I’ve learned from nearly three years of enterprise Wi-Fi at home
Surveying the signal
I’ve elected not to include detailed iPerf-based client bandwidth testing in this review—if you want that, you can hit the previous review because the numbers won’t have changed all that much.
Single-client bandwidth isn’t where these devices excel—as noted in the previous review, a years-old Apple Airport Extreme beats a Unifi AC-Pro in a multi-stream iPerf test without breaking a sweat. If you’re looking to buy Unifi APs so you can dominate benchmarks, you’re buying the wrong gear—go buy one of these crazy-ass things and call it a day.
Anecdotally—and, in my opinion, far more usefully—I’ve had absolutely no problem with wireless coverage or speeds, even with a dozen house guests all simultaneously streaming video and playing games. Unifi APs err on the side of providing consistent and reliable connections for lots of devices rather than allowing single clients to dominate, which is typically what you want even in a family home. Devices roam from AP to AP as needed without dropping off the WLAN; everything just works, which is exactly how you want Wi-Fi to be.
The most interesting thing about the above coverage heat-maps—which were generated using a copy of NetSpot Pro, courtesy of the NetSpot folks—is how dramatically they differ from the Unifi controller’s predictive map (included in the gallery for comparison). This is a blatant reminder that while automated predictive tools can help with your planning, there’s just no substitute for a good ol’ site survey.
Again, the biggest thing I was trying to achieve was having a uniform, strong 5GHz signal everywhere—something that requires multiple APs to do well (unless you live in a studio apartment and have only one room).
I’m happy with how things have shaken out, but getting to that state can take a bit of effort, and the specific things that worked for me might not work for you. There’s no magic bullet—but there are some helpful knobs to twiddle.
Configuration tweaks for whole-house 5GHz satisfaction
From a perspective of strategy, you start by making gross adjustments to your WLAN by tweaking your access points’ channel selections, channel widths, and transmit power. The idea is to ensure that your APs are each using separate channels with low noise and low interference; the traditional 2.4GHz advice of “always use channel 1, 6, or 11” fits in with this strategy. But that’s only the beginning.Advertisement
Before we begin, though, let’s talk about “auto.” Unifi APs do indeed have an “auto” setting for both power and channel selection, and you should never use either of them. The transmit-power “auto” selection is misleading—it simply locks the AP’s radio at its highest power setting, which is almost certainly not what you want. Having a too-strong AP can lead to a situation where a distant client locks onto that AP because it’s receiving a strong signal, but it doesn’t have the power to transmit back to the AP. You want your transmit power set as low as it’s possible to get and still cover the area you want, and no higher than that. As much as you might want to piss off your neighbors, you’re only screwing yourself.
Setting the channel to “auto” should similarly be avoided, in spite of how tempting it is. The issue is that the Unifi APs don’t work with each other when they auto-select channels, and this frequently leads to a situation in which your access points (and your neighbors’ APs, too) constantly stampede across the spectrum, chasing an ever-moving chunk of unused air and constantly interfering with each other. Manual channel selection stakes a claim on some spectrum for each AP, and it should result in more consistent connectivity and a more evenly distributed use of the available spectrum (especially if your neighbors keep their stuff set on auto).
If having to go hands-on like this sounds intimidating, there’s a reason—it kind of is. However, starting with the company’s newer controller revisions (I believe 5.8, but it might be in 5.7), there’s a “please do this for me” button that will lock all of your Unifi APs onto what the controller believes is the best channel and transmit power for them. It’s the “Auto channels” button on the Unifi map screen, and it looks like this:
You specify a band and channel width, and the controller polls each AP about its RF environment and makes suggestions. You can then apply them all at the same time, if you like what it’s telling you.Advertisement
I’ve found the suggestions are typically solid and work reliably, though whatever algorithm Ubiquiti is using doesn’t always deliver the same results—multiple clicks of the “Auto channels” button results in different suggestions each time (or sometimes a repeat of the same three or four layouts). I assume this is because the spectrum in my area isn’t super saturated, since I’m in the suburbs and not in a dense urban environment, and the algorithm can arrive at a few different layouts that are all roughly the same level of “optimal.” Regardless, all of the suggestions appear to work well.
Major caveats to the tool are that it’s not dynamic and it doesn’t update itself in the background—you trigger it and you do the assignments manually. On one hand, this is probably desirable behavior—if you’ve found a channel configuration that works very well, you don’t want it changing without a very good reason. On the other hand, if you get a neighbor who plunks down a new Linksys router set to its screaming maximum and it eats spectrum you were happily using, your Unifi controller won’t reassess and fix itself. You have to go trigger a reallocation yourself.
If you don’t want to trust the health of your network to automatic tools, you can take things into your own hands. Briefly, the workbook for figuring out what’s right for you starts by doing a detailed RF scan. Unifi APs can peek at their surrounding environment and give you a fair amount of information on which to base your channel number and width. You end up with something that looks like this:
This’ll tell you at a glance which channels are utilized and which aren’t, and you can hover over each channel for more information. From this, you can suss out how busy things are and what channel width is right for you, because there are several options. If you’re in a very noisy RF environment, you likely want to pick narrower Wi-Fi channels, since the narrower a channel is, the less spectrum it crosses and the lower the likelihood is of encountering interference. The trade-off is that narrower channels mean less bandwidth per client.
After you’ve picked a channel and a channel width for both 2.4GHz and 5GHz, you can set a transmit power. General guidance here would be to set your 2.4GHz radio to “medium” and your 5GHz radio to “high” if you’re in a house or “low” and “medium” respectively if you’re in an apartment; however, this should be validated by at least walking around with a site-survey application on your phone or laptop so you can actually observe the effect of the different power levels before committing to a choice. (If you really know what you’re doing, you can manually lock the transmission power to a specific setting.)
- Floor plant target
- Uvb bulb
- 9th edition deathwatch
- Trex seating
- Plastic paint pail
- 10mm 12 point
- Dst glass cutter
- Scba baseball
WiFiman is here to save your network from sluggish surfing, endless buffering, and congested data channels. With this free-to-use (and ad-free) app, you can:
* Detect available WiFi networks and Bluetooth LE devices instantly.
* Scan network subnets for additional details on detected devices, such as Bonjour, SNMP, NetBIOS, and Ubiquiti discovery protocols.
* Conduct download/upload speed tests, store results, compare network performance, and share insights with others.
* Relocate your access points (APs) to nearby data channels to instantly increase signal strength and reduce traffic volume.
* Test the connection speed between your UniFi Dream Machine or UDM Pro and mobile devices.
* See enhanced details about all of the Ubiquiti devices on your network (UniFi, AmpliFi, AirMAX, EdgeMAX, EdgeRouter, EdgeSwitch, UISP, AirCube, AirFiber).
What information does WiFiman show?
You'll see IP address, netmask, gateway, DNS server, SSID, BSSID, signal strength, wireless channel, ping latency, and packet loss information.
WiFiman's network tools include:
* A network analyzer with WiFi 6 support and a signal strength meter.
* WiFi speed testing.
* Detailed network cell information.
* A network scanner for device discovery.
* A port scanner.