Note – Lighthouse image was used with permission from Ranveig Marie Photography. Check out her stuff here: Instagram, Facebook, and Flickr.
This is part three of a multi-part post describing the tuning of Single Channel Architecture/Virtual Cell and taming ChromeOS roaming behaviors. Part one can be found here. Part two can be found here.
We are very densely populated with access points to accommodate at least 50-60 devices per classroom at any given time. Because of this AP density it is necessary to make adjustments to the network on occasion.
As indicated in part two, pcaps determined that we were decoding beacon frames with valid FCS into the high -80s dBm, all with the same BSSID (Virtual Cell). Even though there were several different devices consuming wifi in the area, Chromebooks were hyper sensitive to the fluctuating SNR and were the only device type continuously performing four way handshakes due to a triggered roam (SNR <=18).
Since we are so densely populated with access points (to meet requirements), the only way to tune away the issue was to increase the minimum base transmit rate even further (from 24 Mbps).
TX power is already reduced to a level that provides proper overlap between classrooms to satisfy requirements. Increasing the minimum base transmit rate to 36 Mbps was done first but did not yield the results that I wanted to see. I then increased the minimum base transmit rate to 48 Mbps (also leaving the supported rates of 24 and 36 Mbps) and ran another pcap.
This time I was receiving most beacons with valid FCS in the mid -70s dBm. Further testing with the Chromebooks showed the results I wanted to see.
Unnecessary (triggered) roams were dramatically reduced and performance was much better. Beacon overhead was decreased by 50% which is indicative of moving from 24 to 48 Mbps minimum base rate.
We ended up testing this configuration change at a couple of our high schools of similar layout, design, and requirements with very good results.