Meru Contention and Chromebooks

[dclark]

We are running about 30 Chromebooks per AP at our installation, with about 18 AP's total.  Our controller an MC 1500, AP's are 832i's.  Avg distance between AP = 75'.  About 70% of clients network wide are 802.11ac/5.2Ghz.  All Chromebooks are AC 5.2Ghz.

We have recurring problems, the most significant being station association.  When a classroom of Chromebooks log in simultaneously, it takes about 20 minutes for all station/AP associations to take place.  Chromebook logs show the station associates, then it disconnects, most likely because of a change in RSS.  Meru controller logs show disassociation.  Seems to me this could work much better.   A Meru engineer has tweaked and adjusted quite a bit, the solution seems to center around spreading out connections to more AP's (e.g. reducing TX to balance AP's better).  Does this make sense to others?  Wasn't virtual cell supposed to solve this kind of problem?

Do others of you have problems with high density installations?  Chromebooks?

[bandersen_FTNT]

Hi

The Virtual Cell will for sure take of "optimal" AP connection on behalf on the client device. Once that's said it could be that you need to optimize in terms of "how many AP's are seen from client" This relates to re-using the spectrum as best as possible. So reducing TX and/or change the base/supported rates in ESS is important for optimal usage of the spectrum (channel in use)

Typical we see with AP in each classroom, you can set for instance power to 14 (which often matches tablets, phones etc), and remove base/supported lower that 54 (some devices might require to see 24, then use 24) :)

Hopes this can get you further.

/Brian

[dclark]

Thanks for the reply.  Tweaking the TX has been ongoing and seems to help a little bit.

One thing we see is a rapid variation in RSS from -40 to -90.

The Chromebooks see the change in RSS (threshold is delta of 18) and as a result disconnect and re-associate.  This happens over 20 minutes or more when multiple stations are associating. 

Why are these AP's RSS varying so much?

[jjmfns]

The AP's are not varying.  The signal strength is detected by the beacon frames received by the stations and since virtual cell appears as one AP to the client what you are seeing is the beacons from other APs with a lower RSS. Since this is how the single channel architecture works it would be nice if there was mention of how it is detected by wireless network utilities but it has never been in the documentation (at least what I have read) in the 13 years I have been working with the product.

We have many K12 customers and have found that one of the biggest problems is with Chromebooks is when the SSID being broadcast in both bands. The stations continually bounce between the 2.4 and 5 GHz radios which is probably what you are experiencing. If you broadcast the SSID in 5 GHz only you will see more stable connections on the Chromebooks but you will have to deal with any clients that are 2.4 GHz only.  

[Jari]

a quick idea as a test might be to hide your preferred sssid via the ESSiD profile just to make the Chromebook wifi drivers more alert and also more participating.

Then I get a bit worried over your choice of controller model...there are no fresh software provided to that hardware platform and therefore let's hope that is a typo and that you have the 1550 in place. 

Nice choice of AP model...you might consider to you use both available radios in the 5GHz band in places where it suites optimal.

[JPBruwer]

Hi, Did you ever manage to solve this issue... I have Chromebooks losing connectivity randomly and it's very unstable.