Marvin Speculates on the MCA Big MAC

Marvin Speculates on the MCA Big MAC

By CWNP On 01/26/2009 - 14 Comments

I know, you're already wondering, "who is Marvin?"  A pseudonym for Marcus + Devin.  You can thank CWNE Round Table member and CWNT (instructor) Gene Hill, who came up with it, for the chuckle.  Marcus is my trusty lab engineer here in the Batcave.  We were bouncing ideas back and forth about some problems we were having here in the lab, and we came up with an idea that probably won't work...but you never know where it might lead.

We are having an issue where TxBF systems are becoming victims of their own success.  They provide such excellent SNR that clients won't let go of an AP (stickiness).  We've tested clients, like Intel's 4965agn, that have roaming aggressiveness settings, and after configuring them for maximum aggressiveness they still stick to an AP far too long.  If APs with TxBF capability aren't placed appropriately far apart, roaming can be a bit of a problem (because the client makes the decision).  I'm not pointing out a flaw in TxBF systems or necessarily the technology itself, but rather a flaw in the interaction between TxBF infrastructures and the various types of clients that connect to them.  The real flaw here is that clients make crappy and inconsistent roaming decisions.

As we were going through this testing, I remembered reading a Meru whitepaper that talked about the importance of maintaining a steady SNR during roaming.  I dug through their whitepapers until I found the picture that was stuck in my long-term memory (see below).  I think the picture says alot, and it's what we've been experiencing.



By having the controller make the handover decisions instead of the client, steady SNR is maintained yielding consistently high throughput.  This is exactly the problem we're having here in the CWNP Lab.  We have to tell manually our client to reconnect to get it to move to the AP where it can get the highest data rate.  While 78 Mbps is nice, 130 Mbps is better.  I want the controller to maximize the client's data rate to the system as a whole at all times as the client roams.  This isn't something that MCA systems do, and when you add TxBF, it can get worse if the system isn't deployed properly.  Again, this is NOT the fault of the infrastructure but rather the fault of the client devices due to their inability to make decent roaming decisions.  

OK, to the crux of this blog post...

What if we could have a Virtual Cell(R) like that of Meru while using an MCA architecture?  Sure, there are issues to solve (like how clients would handle finding the same AP on multiple channels while scanning), but there are also some standards-based tricks we could pull to make this function.  Vendors do it every day, no?  For example, what about using the Channel Switch Announcement as an instruction to each station to move to another channel?  The station would actually find a different AP with the same BSSID, but it would think that it's own AP moved to that channel (per the Channel Switch Announcement action frame's instruction).  Since that frame is unicast, it could be used to "bump" stations to the best AP all the time.  Since each AP would have the same BSSID, no roaming process (Reassociation, 4-Way Handshake, etc.) would be required.

Something along these lines would solve the stickiness problem, giving "control to the controller" (which is far better than where it is now), and would speed roaming.  In fact, vendors should consider this a challenge...nay, a dare.   Marvin says, "we bet you can't figure out how to do this!" ;)

Blog Disclaimer: The opinions expressed within these blog posts are solely the author’s and do not reflect the opinions and beliefs of the Certitrek, CWNP or its affiliates.