Single Channel Architecture and Virtual Cell and its Effect on Co-Channel Contention

Before you go ripping me, hear me out.

I was recently called out to a high school who had put in a trouble incident indicating that they were experiencing slow wireless performance and client disconnections in a particular area of the building.  When I arrived I found that there was a high concentration of clients in the cafeteria which numbered around 200, 150 of those on a single Meru AP832  (clients were primarily on one side).  Currently we employ AP832s (3×3 AC) in high density areas unless it is recent construction in which case the whole school is done with the AP832.  The cafeteria in this high school along with all other high schools in the district qualify as high density areas and are outfitted accordingly.  I fired up MetaGeek inSSIDer for a quick glance to make sure everything looked ok.  I quickly noticed that I had two BSSIDs on the same channel very close in dBm on both bands, which we all know is cause for concern.  My man Rowell Dionicio explains this issue well in a recent blog post at Network Computing.  You might be thinking, “Wait a tick #MeruMitch!  Isn’t that what single channel architecture is?”  Not really.  In this particular instance I experienced a bug where a handful of AP1020s (2×2 N) thought that one of two radios inside were a radio from an AP832.

Single Meru AP1020. 2.4 GHz radio
Single Meru AP1020. The 2.4 GHz radio thinks it is in an AP832, where the 5 GHz radio is correct

This effectively broke my virtual cell (virtual BSSID) which in turn created co-channel contention.  For those not in the know, a virtual cell is a virtual BSSID that Meru groups all of it’s physical BSSIDs behind to create it’s “special sauce single channel architecture“.  Watch the video and… DON’T SHOOT THE MESSENGER!

At the time I did not capture any further information so for the sake of this blog post I re-created the scenario at my house.  Going forward please pretend that 5NINER-Meru = LCPS.  Also the “Shed” AP was actually moved into my house for the purpose of this dramatic re-creation.



Broken virtual cell. Two AP832s on 1/100 and one AP1020 on 1/100. The AP832s retain their virtual BSSID, but the AP1020 being on the same channel creates another virtual cell which is causing co-channel contention.

There were a total of seven AP1020s which suffered from this bug and a few of them were within hearing distance of where this high concentration of clients was located.  I checked the controller and found the channel utilization through the roof in this area.  I removed the corrupted APs from the controller and added them back.  I set all AP1020 radios back to 11/44 and AP832 radios back to 1/149.  You did read that correctly…ALL.  Both virtual cells were back in business.


Two unique properly configured virtual cells. Same APs as before. Two AP832s on 1/100 and a single AP1020 on 11/44.

Ok, now pick yourself back up off the floor and/or clean up the brain matter that exploded all over the wall just now when your head exploded.  Brain matter on the wall is unbecoming.  I digress.  Once the physical radios were all back behind the virtual BSSIDs created by the ESS profile, the client’s performance dramatically improved and everyone was happy again.

You may argue that this would be simply a one off issue due to the AP radio corruption that took place.  In fact, it is not.  It would be very easy to have a problem like this occur with the APs working as they should in an improperly designed network.  To properly design a Meru single channel wireless network you should group like model APs in their own virtual cell when in a mixed model environment.  A group of AP832 AP’s virtual cell will have a different virtual BSSID from a group of AP1020 APs which in turn means each virtual cell should be assigned unique channels.  They can all happily co-exist in the same ESS profile though.

Same ESS profile. Broken virtual cell causing CCC.
Same ESS profile. Proper channel assignment creating two unique virtual cells.

I understand the controversial side of single channel architecture but the fact of the matter is that it works great when it is designed and installed CORRECTLY!  All the same RF fundamentals, designing, deploying, etc are relevant when using single channel architecture.  Poor marketing among other things give it a bad name.  Taking it out of the box, racking the equipment, throwing everything on the same channel, and letting it rip WILL yield poor performance.  Counter to some marketing I have read, single channel architecture is NOT for the network group that “doesn’t have time to worry about maintaining the wireless network” or “doesn’t have time to properly survey.”  That is real folks!  I have read or heard that garbage before.  So please…I ask from my little single channel heart, give me and my precious FortiRu a chance.  We definitely deserve a spot “in the ballpark” among the big boys.

Yours in loving single channel goodness,


PS – There will be a Whiskey and Wireless podcast in the near future where I talk about my single channel adventures.  Keep an eye on the Whiskey and Wireless Twitter feed.



7 thoughts on “Single Channel Architecture and Virtual Cell and its Effect on Co-Channel Contention

  1. Great troubleshooting post! I’ll admit, I need to educate myself more on SCA but you make it sound interesting. Thanks for the shout out!


    1. Very Nice post Mitch. Definitely that one AP1020 out of virtual cell (on diff BSSID) going to cause CCC/CCI. And since the virtual cell is broken there already and if client decides to move across these two AP(Broadcasting same ssid) they are going to face poor performance and connectivity problems. By default PMK caching is disabled in Vcell(since all APs are suppose to broadcast in same bssid only). So if you are on a Dot1x ssid and client moving between these Bssid, yes ping-pong. you know what will happen after that!!.

      Seriously you are a True Meruvian!!


  2. MANY thanks Mitch, you save my soul !!! we have old AP1020e, AP1020e and “new” AP822i mixed together and clients were crazy, claiming irregular disconnections… I wrote SOS questions to the FORTINET support team
    Q: “can models (AP1020 and AP1020e and AP822i ) work togetther ? or are there some limits ? ”
    A: “No, since AP10xx and AP8xx are 2 different AP models they can not be connected on same floor, as client will be handed off between 2 different AP models and there will be a disconnection and reconnections every time they move between these models, unless the ssid is not configured to NATIVE CELL. ”
    BUT we have a lot of old AP1020 which are at end of production and will buy new models and in real world ther will be spaces with mixed APs models …
    so THANKS to your advice I have just reconfigured APs via FORTINET WLAN controller to FeatureGroup
    AP1020 1/20MHz and 36/40MHz
    AP822i 11/20MHz and 132/20MHz
    +testing and clients are happy now. THANKS to your blog I understand a little bit more the WiFi “underground” 😉
    Mitch be happy in your life


Leave a Reply

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

You are commenting using your 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