WLAN Channel Management F1 Style: Part 1 of 3

We keep saying that overlapping channels are not good – they create unnecessary interference, contention, or both (depending on the distance between the APs). It is a general recommendation to stick to non-overlapping channels and actively hunt and eradicate anyone who overlaps. However, are overlapping channels always bad?

A typical example of a channel that overlaps with every other!

In this 3-part series I’ll be talking about some channel tuning techniques that may allow cramming more channels in the RF plan, have them overlap – and still get overall better network performance. A valuable LinkedIn member Eduard Garcia-Villegas (who is doing some interesting research in WLANs) had recently provided me with some interesting papers that offer theoretical foundations and practical proof behind this. What does it have to do with F1? Let’s find out!

What’s the problem?

Consider this example:

A day in life of an enterprise network. Never mind the DSSS channels – this is a test lab.

You can see (and if you can’t – click the image) that despite all enterprise efforts there are some stray WLANs that do live on other channels and cause havok (well, this is a test lab).

Conclusion 1: No matter how you try to keep your channels from overlapping, there will be someone else (unless there really isn’t anyone around, not even with a SoftAP on a smartphone) to mess it up. Resistance is futile.

Plus, ‘Enterprise’ channels 1,6,11 are packed quite densely, there are 8-10 APs heard on each channel, which means lots of CCI CCC (co-channel contention).

Conclusion 2: while trying to avoid (the unavoidable) overlap we increase the size of the collision domain.

Click to see where I stole this pic from
Click to see where I stole this pic from

Is the glass half-full or half-empty?

Let’s see what happens when the receiver hears an ‘overlapping’ frame.

  • IftheRSSI is enough to decode a frame – we get the previous scenario and both overlapping cells end up in the same collision domain.
    • Normally STAs try to filter out everything that is not on their channel, so, I would guess, the frames from the partially overlapping channels may still not get decoded (for example, not all OFDM subcarriers were heard clear enough). Please correct me if my guess is wrong.
  • Otherwise – we got ourselves some interference, and the SIR between this interference and the signal on our channel will determine if this interference is tolerable.
    •  If the interference level is above the Energy Detection threshold, as required by the 802.11 standard, this interference will block communications regardless of SNR (Medium is deemed busy). The standard says that ED is 20dB above the lowest decodable datarate (which is defined at -82dBm in the spec), thus is should be -62dBm. In reality, the Rx sensitivity of devices varies, so does the threshold.

So, based on the distance between the APs and the actual channel separation (i.e. what is the ‘distance’ in Hz between the channels) we either suffer from CCC or from high interference. Or do we?

Hi, Troy Martin!
Hi, Troy Martin!

Conclusion 3: with enough SNR we can set up channel overlap to maintain decent rates while avoiding CCC (breaking the collision domain), which may be preferred compared to suffering from collisions.

I spent a lot of time trying to calculate the actual attenuation between channels, but I’m not that smart and I have totally forgotten how to use MATLAB. However, just recently I’ve found this table here [1].


As you can see, even between channels 1-5 (2-6, etc) there’s sometimes enough attenuation to prevent decoding. This instantly allows squeezing in another channel in the 13-channel EU/ETSI frequency space and explains how (and when) the popular 1-5-9-13 scheme works.

And this is pure relative attenuation due to frequency difference (and 802.11 standard Adjacent Channel Rejection spec). Add path loss, attenuation due to walls and obstacles, enhanced AP Rx filtering (beyond standard ACR) – and it will become much higher making even channels 1 and 2 sometimes effectively non-overlapping.

Every moment counts.

OK, that’s one trick, but it’s still somewhat limited. Is there anything else?

One factor that most RF planning tools don’t take into account is channel utilization. What’s bad in having interference from someone who only transmits 1% of a time? Or what’s bad even in sharing collision domain with them? Time domain adds another dimension to RF planning decisions.

Sounds attractive, but how can one quantify it? This is where the aforementioned research comes into play. Without getting too much into math (I will not pretend that I have fully understood it anyway) let me just say this:

  • Most of automatic RF planning algorithms, be it RF planning tool or auto RF management code in WLAN controller/AP, mainly care about dBs.
  • The researchers have created an RF planning algorithm that additionally takes into account parameters such as channel utilization and certain packet counters, and tries to build a channel plan that has minimal overall packet error rate.
  • I.e. instead of building cool-looking RF heatmaps they’re trying to build a network with a better overall performance baseline.
  • They have tested the algorithm on their own university network under load and It showed pretty impressive results!

…which we will discuss in the next part. It’s pretty long.

[1]  Garcia-Villegas, E, Vidal-Ferré, R. and Paradells, J. (2009), Frequency assignments in IEEE 802.11 WLANs with efficient spectrum sharing. Wirel. Commun. Mob. Comput., 9: 1125–1140. doi: 10.1002/wcm.670


8 thoughts on “WLAN Channel Management F1 Style: Part 1 of 3

Add yours

  1. Interesting article Arsen, I’m intrigued to see where you’re headed with this.
    I agreed with your point of view on utilisation planning. I’ve criticised Ekahau’s current implementation as basically pants on my blog. I was pleased that they did acknowledge the algorithms need work. I’m going to suggest a model based on “effective capacity” would be good – showing the effective realistic throughput given that a bunch of APs will be sharing channels. (Assuming non-overlapping, mind you).


    1. Hi, Jon. Thanks for your comment.

      There are two approaches I’ve seen.

      1.Average RF levels across time, just like they do with utilization.
      Example: if I know that the AP transmits at 20dBm with utilization of 50%, it will affect my aggregated throughput as if it were doing 10dBm at all times. The research paper I’m citing shows some math for this, depending of the load of neighboring networks.

      The problem with this approach is that is doesn’t take contention into consideration. Truth be told, if the APs are far enough, (5m+ FSPL) you should not be able to decode up the frames from overlapping channels, unless the APs are on the same channel.

      This is where the 2nd approach might be handy.

      2.It is possible to say that under load the contention caused by neighbouring APs causes your effective throughput to fall, as if you have lower SNR due to interference. I.e. “this guys eats 50% of my airtime, let’s assume I get half the data rate for throughput simulation purposes”. Maybe, this is why CCI was called “interference” and not “contention”. This would explain your example with SNR falling down with increasing the network load (however, it would not explain why it falls to zero).

      It is quite possible that ESS is trying to do one of the two or both, attempting to bring everything into a single cozy “RF heatmap” plane for ease of planning.
      Of course, all this is just speculation, as we don’t know the implementation specifics. Care to reach out to Timo to validate? 🙂


  2. Very well done article.

    I have used non-standard channel plans in niche cases particularly on companies in large buildings that can’t control their upstairs neighbors.

    Additionally I would be curious how using the RX defer threshold would impact data rates by tightening up the receivers of the AP’s.


  3. Nice starting point. Depending on the actual deployment I’ve found using ALL 2,4 channels can help with overall capacity as you can mitigate preamble detection to a great extent. Like everything, it can always backfire. Plan, deploy, VERIFY.


  4. [This has been edited by moderator to look less like a copy-paste of a press-release].
    Ruckus Wireless have been employing similar technology for years under the badge of “Channel Fly”
    Channel Fly assesses L2 information in addition to mere RF measurements, attempting to maximize network capacity. It has been successfully trialed on large-scale carrier networks and shown improvements [however, nothing was presented to support this claim].


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Create a free website or blog at WordPress.com.

Up ↑

%d bloggers like this: