Blogs

As network demands and client density go up, proper design becomes increasingly crucial. The problem is that I often get called in to fix a network that’s having issues and am faced with the dreaded “the network was slow so we added more APs.” Although that seems like a logical fix to an expanding user base and business needs, unless it has been well planned it often leads to painful amounts of co-channel interference.

The name “co-channel interference”, or CCI, is a bit deceiving since it’s not interference in the traditional sense. CCI is actually the 802.11 protocol doing what it does best, serving clients to the best of its ability and surviving. In my friend and all-around Wi-Fi expert Andrew von Nagy’s blog post titled “10 Wi-Fi Terms You've Probably Been Using Incorrectly” he offers the term co-channel contention, or CCC, instead of co-channel interference. While more accurate, the Wi-Fi industry has for the most part accepted the term as-is.

Nice Guys Finish Last

802.11 is like the best kind of friend, it does what we wish our parents all did, it’s an incredibly polite protocol. The resiliency and ability of Wi-Fi to adapt to ever-changing environments owes a great deal to the simple approach it uses for all communications - listen first, then talk.

“Keep silence for the most part, and speak only when you must, and then briefly.”

~ Epictetus

To put it fairly simply and without going too deep, the way this works is that when you have a BSS (a single AP and associated clients), each device follows the 802.11 protocol specified RF assessment and timers to contend for the medium. Before attempting to send a frame a device will assess the RF to ensure that there are no other transmitters that have reserved the air and any non-Wi-Fi energy detected is at an acceptably low level. If the air is clear and clean, the device will announce it is beginning its transmission and reserve the air for the period of time required to send its data. When the medium is busy (another transmission is occurring), each the device will listen and wait quietly for its turn, periodically checking back to see if all the other devices have finished. All the while everything just works beautifully.

Co-channel interference, and the issues it brings with it, occurs when you add in other BSSes (BSSs? BSS-i? BSS-ae?) on the same channel, whether part of the same distributed system or not. Since all devices are required to use the same listen-then-talk method (whether the device is an AP or a client), instead of adding capacity to the network you’ve introduced more overhead. In a somewhat counter-intuitive way, additional APs actually hurt the network. The medium gets busier and each device ends up waiting longer for that little slice of time to transmit its data.

This is a major problem in wireless networks. It’s a silent killer of productivity and usability that sneaks up on unsuspecting administrators. It may only show up intermittently during peak usage periods.CCI presents itself in many ways such as reduced WLAN capacity or periodically unstable WLAN performance. It may stay hidden even with large groups of clients until someone starts streaming a video. As the need to move data increases, the medium contention becomes more and more apparent.

How Do I Avoid CCI?

While it will be a difficult task depending on the requirements, client device capabilities, and available equipment, the best way to avoid CCI is through careful planning and design. The trick to designing a network with little or no CCI is to maximize spectrum reuse while minimizing overlap. To do this, be sure to account for as much signal propagation as possible. Your cell edge may only be designed to -67dBm with nearly no overlap but the frames will still register much further out. This area that exists outside of your cell but is still within range to be decoded is the danger zone. The image below is a great representation (source: http://www.wlanpros.com) of what this might look like.

Here are a few tips to get you started:

1. Reduce your channel width - If you’re running out of 40MHz channels and simply can’t get enough separation between APs, running at a lower channel width (20MHz) will help a lot by doubling the amount of available channels. Don’t use 80MHz channels in a deployment with more than a few APs and if you must, make sure to only use them in areas where you can eliminate any overlap. By configuring 80MHz channels you reduce your available channels down to 5. 40MHz offers a much more manageable 12 channels while 20MHz channels gives you 25 channels to play with. Just say no to 160MHz. Better to have lower data rates than reduced capacity.
2. Use as many non-overlapping channels as needed (see #1) - This means stick to 1, 6, and 11 in 2.4GHz. In 5GHz, if you aren’t near an airport and your clients support it, enable those DFS channels!
3. Control your power levels - Remember, just because an AP’s signal can reach a client doesn’t mean the client’s can reach back. If your power is too high, the AP’s frames will cause CCI even though it can’t serve all the clients that can hear it - use sane power settings. If you don’t want an AP to be heard across the building or 2 floors up, turn it down! Automated radio management is a great thing but sometimes you will have to tune it so you don’t get a runaway power setting. If absolutely necessary you can also disable it and manually design your power level plan.
4. Use the environment to shape your RF - When designing a Wi-Fi network, use walls and other obstructions to your benefit. Also be sure to avoid areas that will work against you by allowing signal to travel great distances if possible - APs in hallways should be approached with caution.
5. Avoid cookie cutter methods - Every network is different; each with unique applications, unique client base, and unique environments. On top of that, every one of those things could change at any time. Taking a cookie cutter approach doesn’t account for any of the existing uniqueness and definitely doesn’t create a solution that can adapt to changing needs. It’s a great way to set yourself and your network up for failure. Gary Busey once said, “If you take shortcuts, you get cut short.” When designing a network you have to actually design it. If you don’t test, adjust, and validate, and then go back to perform periodic maintenance, how can you be sure the network isn’t going to fall on its face under load?