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

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!

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