Do non-overlapping channels overlap?

We all know the “non-overlapping” channels 1/6/11 in 2.4GHz (5GHz matter is similar). Do they really not overlap? I keep bumping into this in conversations, and would like to create a point of reference (with pictures) instead of having to repeat same old over and over.

BW- 2m away from AP
Your typical “non-overlapping” 1/6/11 setup

Since we a dealing with broadband technology, the signal is in reality not 100% contained within the allocated 20Mhz band – we only see the tip of the iceberg. Here’s the official 802.11 20-Mhz OFDM channel spectral mask. Note that the “20Mz” channel actually goes up to 30Mhz in every direction (60Mhz total width), albeit up to -45dB weaker, than the central 20Mhz flat part.

Wi-Fi Spectral Mask - Single Channel
802.11 OFDM transmit spectral mask. Power levels are relative to the signal strength in the center.

Now, let’s combine the masks for all the “non-overlapping” together and enjoy the view.

Wi-Fi Spectral Mask - 1-6-11
Spectral masks combined together in 2.4GHz space. Can someone draw me picture with three icebergs please?

Of course, if the APs are spaced far enough, the effect of side bands will be negligible: if I already hear the AP’s central frequency at -87dBm, hearing the sidebands at another 20-26dB lower will do well below the sensitivity threshold. However, if this is not adhered to, here’s a spectrum analyzer capture of channels 1 and 11. Can you see the AP in channel one? What chances are for it to be heard?

Spectrum - 24GHz Ch1 Ch11 overlap
“Non-overlapping” channels 1 and 11.


  • Even non-overlapping channels overlap
  • Maintain separation. Either calculate using tools or use 3-5m as a rule of thumb (better use tools!)
  • Stacking APs on top of each other to provide triple density seems a good idea but only works if you are Xirrus, but even they stopped doing it, as far as I know.
  • 2.4GHz is dead, move all enterprise networks to 5.

Hope this clarifies the matter enough. If this useful enough to use as a point of reference when explaining the matters to others? Let me know your thoughts!


What 802.11ax is not

I normally do not publish the “link to” posts, preferring to share on LinkedIn, but Devin Akin well deserves it. Matches my perspective 98%+, especially the point on 802.11ac stillborn MU-MIMO.

Preamble: Aerohive has released the first 802.11ax APs (the official 802.11ax standard spec is not final yet) – so expect the marketing race.

TL DR: The only good thing is OFDMA sub-carrier allocation (think sub-channels) similar to what exists in GSM/LTE/WiMAX, but it would not work w/o client support and forget 2.4GHz.

Anyway, enjoy the article: and let me know your thoughts!

WING5 CLI Tip: Running config at-a-glance

Often you have to deal with existing AP/Controller and need to understand what’s configured on it. Of course, you can click 100500 times in the GUI all over the place, or read through 20+ pages of “show run” output (those who’ve been to my WING5 training should remember the little space-bar-thrashing exercise). For instance, the full config dump for the WING5 class is about 21KB ~= 29 pages.

Or you can do this to quickly :

mywing5device>sh run | include ^\\w

and get this:

version 2.1
ip access-list fw-acl-full
ip access-list fw-acl-limited
ip access-list fw-acl-verylimited
mac access-list 12-block-mint
mac access-list PERMIT-ARP-AND-IPv4
mac access-list l2-block-mint
firewall-policy default
firewall-policy lab-fw-wips
role-policy lab-rolepol
mint-policy global-default
wlan-qos-policy default
radio-qos-policy default
aaa-policy lab-aaapol
captive-portal lab-hotspot
wlan team6-eap
wlan team6-hotspot
wlan team6-psk1
wlan team6-psk2
smart-rf-policy lab-smartrf
wips-policy lab-wips-basic
advanced-wips-policy lab-wips-adv
auto-provisioning-policy lab-autopolicy
radius-group radgroup-fullusers
radius-group radgrp-hotspot
radius-user-pool-policy lab-radpool
radius-server-policy lab-radius
dhcp-server-policy ADSPLAB
dhcp-server-policy RFS2
management-policy default
management-policy lab-mgmt
l2tpv3 policy default
profile rfs4000 default-rfs4000
profile rfs4000 lab-rfs4000
profile ap71xx lab-7131
profile ap650 default-ap650
profile ap650 lab-ap650
profile ap6521 lab-6521
profile ap621 lab-621
rf-domain default
rf-domain lab-rfdomain
rfs4000 5C-0E-8B-1B-9B-44
ap650 5C-0E-8B-98-C5-44
ap6521 5C-0E-8B-E8-31-68
ap621 5C-0E-8B-97-C2-48
ap621 5C-0E-8B-97-DA-AA

Now you can see all the configured rf-domains, profiles, policies, ACLs, WLANs, devices etc in a nice quick overview.

Since WiNG5 controller contains the configuration for the entire network this thing can be very helpful – try fishing this out of the full dump when you have several hundred sites and thousands of devices!

<IMHO>Overall, the way the distributed configuration and reporting is implemented in WiNG5, and how many cool shortcuts and features are available for mass management/deployment/troubleshooting, deserves a dedicated series of articles. After I really don’t want to go back to previous generation UIs</IMHO>

So, what really happened?

show run… |include <regexp> only shows lines that include regexp.

The config (i.e. “pure” show run) looks like this (note the indentations):

! <header>
<section X>
<section Y>

Thus, essentially, we need to only show the lines that don’t have space or ‘!’ at the beginning to get all the section names. Alternatively, we could just say, that the line should begin with a letter.

The regexp for “letter” is ‘\w‘. The regexp for “line begins with” is ‘^‘. Thus we get ‘^\w‘ –  “begins with a letter“. However, because we’re using a backslash in the CLI, we need to escape it with another backslash, hence ‘^\\w‘. This is it!

P.S. Two pages on text to describe a one-liner… Was there a shorter way? What do you think?

How Android measures WLAN signal strength

Ever wondered how Android decides how many bars to show in the WLAN indicator? (Well, the “bars” are gone, but there’s still exactly the same number of levels) While going through Android source code  I’ve found this:


* RSSI levels as used by notification icon
* Level 4  -55 <= RSSI
* Level 3  -66 <= RSSI < -55
* Level 2  -77 <= RSSI < -67
* Level 1  -88 <= RSSI < -78
* Level 0         RSSI < -88


/** Anything worse than or equal to this will show 0 bars. */
private static final int MIN_RSSI = -100;

/** Anything better than or equal to this will show the max bars. */
private static final int MAX_RSSI = -55;

So, now you know! Of course, vendors may change these values, but let’s hope they don’t! 🙂

Why is this important? This the basis of Android’s Poor Link Detection Watchdog – the thing that causes your WLAN clients to switch to another WLAN profile or to WWAN entirely when you least expect it. But I haven’t grok’d all the code yet. Stay tuned…

A perspective on IoT and Wi-Fi coexistence (WLAN Professionals Conference EU 2015)

Yours trully unexpectedly ended up talking at WLAN Professionals Conference Europe 2015 on a subject of IoT and Wi-Fi. I heard good feedback after the session, so you might be interesting in watching 16-min video yourselves. (Disclaimer: presentation on my own behalf and may not reflect the official position of my employer). If you find some context in my video unclear, you might want to view the video of David Coleman, as my talk was largely provoked by his presentation (the current state of IoT allows for more than one perspective on things). Let me know, what’s your perspective on this matter in comments!

BTW, it was my second time there (and a second ad-hoc talk) at WLPC EU, and I absolutely enjoy it. If you reside in Europe and you are into Wi-Fi, you want to be there next time! There were many interesting sessions at the conference, you can view all the recordings here:

What is nSight?

One of the three key highlight of WiNG 5.8 release is nSight – a new WLAN monitoring, visualization and troubleshooting support solution. I am currently demonstrating nSight as part on our WLN2018 next-gen WING5 class, and students seem to like it a lot. This post briefly outlines the key high-level ideas behind nSight. I’m planning on posting something more detailed after WiNG 5.8.1 is released with more nSight enhancements.

What is it really?

A long time ago wise folks making AirDefence WIPS thought “Hey, we’re already gathering hundreds of WLAN stats to monitor security, can we use them for troubleshooting?” This is how AirDefense Network Assurance came to life. Over the years even more features were added and AirDefense WIPS evolved into AirDefense Services Platform (ADSP).

It turned out, however, that real-time performance monitoring and analysis puts much higher strain on platform internals. ADSP WIPS works well for huge networks (10 000s of APs), but with Network Assurance we started running into scaling issues. Instead of rewriting the whole ADSP from scratch (which still works well as WIPS), the decision was made to port the Network Assurance functionality to WiNG5 and integrate it even tighter. This is how nSight came to be.

Now, Engineering says that we have an insanely scalable engine with some interesting features such as automatic DB sync and failover across cluster, modern UI and much better scalability both in terms of the number of managed devices and adding new features. Hope so 🙂

Thus, technically, nSight is an enhanced port of ADSP Network Assurance to WiNG. With greater scalability, tighter integration (and attractive HTML5 UI!), which gives us ability to develop it further. Currently, it doesn’t have 100% of ADSP NA features, but you get ~85% right now, and more will come in subsequent releases.

Realistically, though, it’s troubleshooting tool that is really useful, since it’s much more intuitive and can be used right away, unlike ADSP that required lengthy setup and muddling through the UI.

What can it do?

Here I planned to write another page or two about nSight features, but turns out there’s this 3-minute video that explains it all and shows the UI, so please take some time watching it. Just bear in mind that not everything is implemented as of initial 5.8.0 release. Marketing… I will focus on important/interesting technical details instead.

Here’s I’ll list a few things I find interesting about nSight.

  • Heatmap visualizations for quick triage. Floorplans and heatmaps are already available in WING5 w/o any extra modules (just upload the floor plan images and enable SMART RF). With nSight, however, they become much more useful for quick triage and troubleshooting. First, you can adjust the filtering values (for example, if your application requires SNR or 10dB to work, just set the “min SNR” slider to 10 and see where you might expect problems with your application). Second, many of the elements are instantly clickable for drill-down, so you don’t have to wander in the GUI finding that specific stat for that specific client.
    Click on the picture below for a view of current nSight visualization filters. Some of these checkboxes hide dialogs with further selections. Selecting some options grays out others, takes a minute to sort things out the first time.

nSight visualization filters

  • DPI integration for Application-level visibility and control. DPI and AVC (Deep Packet Inspection, Application Visibility and Control) are another big highlight of WiNG5.8 release (deserving a post on their own). However, “plain” WING5 can only store stats for 24hrs and those stats are not really aggregated (well, that’s a lot of stats). With nSight your options are much broader. Now you can find out things like Top 10 Apps utilizing your network, or clients by app, etc. Time to see how much time those BYOD devices spend doing real work, and who’s hogging your bandwidth (and AVC feature allows you to apply proper traffic engineering to it) 🙂
    Click on a picture below for a larger view of a sample.

nSight DPI

  • Ease of configuration and Cluster support for peace of mind. nSight licenses are shared in the cluster, database is synchronized across the cluster, service will fail over automatically. All this is literally configured with 4 lines of config file.
  • Visibility scoping  for site admins and managed services providers. Many of our partners want to run WiNG-as-a-Service (as a Managed Service Provider, MSP). While this was possible before, it wasn’t part of WiNG. The problem is that any WiNG user can see the entire network. With nSight, however, you can create users that have only access to nSight monitoring UI (not WING5 configuration UI) and only to site(s) you let them see. Thus, hosting multiple tenants on the same system, or giving site admins insight into their own locations is now possible. What’s more, you can re-use dashboards across those sites, so you save yourself quite some time and effort. Ever considered creating dashboards for non-IT users? For example, a dashboard for warehouse manager to show the overall state of WLAN, status of their WLAN devices and application server availability – all they need, but nothing more than that – and generate a daily/weekly automatic report on how great their network performs 🙂nSight 01
  • Simple licensing for simple demos and pilots. nSight runs for 30 days without license – enough to play with it on your own demo VX9000 or pilot at a customer’s site. When the license expires, the data is still collected, just not displayed anymore (UI is shut down), which makes easy to move from pilot to production.

There’s more to nSight, but I think there’s already enough pages in this post. 🙂

What to do next?

nSight seems to excite people who see it a lot. However, I am not a big fan on “x.0” releases, so I’d focus on being able to understand it, talk about it and demo it right now (get that demo setup running!), and be ready to implement it with customers when 5.8.1 comes out (with additional features and many “x.0 release”
restrictions lifted
). When playing with nSight yourself, ensure you can feed more than one AP into it (3-4 at least on the same site) or it will make no sense 🙂

Was that useful? Write in the comments on what you want to know about nSight!