Subscribe

Subscribers to the boundless digital magazine will receive a regular digest of the most recently posted content.


How band steering fixed a university Wi-Fi problem

By Jeff Haydel in · HiveMind Blog · April 23, 2015
Wi-Fi is such a new and emerging technology that there are features out there that can be contentious. I think most of us will agree that this is one of the many reasons that we find this wireless industry so intriguing and interesting.
 
I find that band steering, the practice of pushing clients selectively to the 2.4Ghz or 5Ghz band, to be one of those contentious features. It's a feature that can become unnecessary with a perfectly configured Wi-Fi network, but then, does such a thing really exist with the ever changing mobile environment that Wi-Fi promotes?
 
I come down on the side of band steering is good, especially for companies that cannot afford a full time wireless engineer, and I will use two user success stories to explain why, sharing the first example here and the other story in a subsequent post.
 
Wi-Fi complaints from university students 
 
The first story comes from a large university that had a well-established Aerohive installation. The main campus for this university is in a medium-sized metropolitan area where a local ISP had decided to experiment with becoming a WiSP (Wireless ISP). The problems started when this WiSP received permission from the city to place their APs on all of the light poles in town, including the poles that followed city roads through the center of campus.
 
The campus IT team started to receive complaints of poor WI-Fi performance and, try as they might, they couldn't figure out what the problem was until they investigated the "rogue AP" report. There they noticed that the WiSP APs were all configured for channels 2 or 9. This was a clear source of interference that the campus IT team had no control over. 
 
When I was requested to come on campus, they explained the problem to me and asked, "What can Aerohive do to help here?" I investigated in HiveManager, Aerohive's Network Management System, and it became quickly apparent that a majority of their users were relying on the 2.4Ghz spectrum for communications. Of their concurrent 4000 users, around 90% were on the 2.4Ghz band.
 
Now, certainly, there was going to be some percentage of devices on campus that were 2.4Ghz only but I suspected that most of these clients were dual band (capable of supporting 2.4Ghz and 5Ghz) and just choosing to use the 2.4Ghz band due to driver preference, settings, or signal strength. 
 
I explained the concept of band steering to the IT team, explaining that Aerohive allows the configuration to encourage or even require that dual band users use a specific band based upon the preset configured criteria. I suggested that we turn this on and go to lunch to let the setting take effect and they agreed. 
 
WARNING - SCIENCE CONTENT:  A critical reader will have just asked, "Wait a second, why did you have to go to lunch to let the setting take effect? Isn't this an instantaneous thing?" That is an excellent question that has an excellent, and technical answer. The truth of the answer lies in the fact that the client device has 100% control over the roaming process and when a device will swap radios or APs. So, in order to steer a client to a specific band, the only time such an action can be taken can be upon association to an AP or roaming to another AP (roaming can be seen as a special type of association.) So no, band steering is not an instantaneously effective technology on a deployed system as it can only be enacted when a device roams or first associates. 
 
Band steering in an Urge configuration works, by ignoring association requests on the non-preferred band for a certain number of requests. If, after the configured number of ignored requests the client is still not attached, the AP will then respond on the non-preferred band in case the device is particularly stubborn and really wants to use the non-preferred band.
 
 If an AP is configured in an Enforce configuration then it will simply ignore all probes on the non-preferred band from any dual band client. I personally do not suggest an Enforce configuration because I have seen too many poorly done device drivers that just don't configure the hardware properly. 
 
Back at our university, when we got back from lunch we noticed a decidedly different band dispersion percentage. We had configured Aerohive's Balanced Band Use configuration before lunch with an ideal percentage of 70% of clients on 5Ghz (and the other 30% on 2.4Ghz.). This percentage is calculated and worked towards by each AP individually.
 
After lunch we discovered that roughly 2000 of their users were on 5Ghz after only one hour of the configuration in place. This put us nearly at a 50/50 split of 5Ghz to 2.4Ghz. This was a site better than the 10/90 split we had before lunch but not quite our desired split of 70/30. If you consider the dirty and polluted 2.4Ghz situation at this campus, this was even better and the students and staff confirmed this over the coming days and weeks. From the student and staff perspective it appeared that the campus IT had installed an entirely new Wi-Fi system when all they did was nudge the clients to the unused portions of what was already there. 
 
Stay tuned for my next blog on band steering highlighting a private K-12 school that was in the middle of an all Apple deployment, with iPads for each student K-12 and MacBooks as well for all of the high school students. 
Jeff Haydel (@cajundop)

Jeff Haydel (CWNE #163) is a Principal Systems Engineer with Aerohive covering the Mid-South. He has worked in the wireless and networking industry for over 15 years and has been with Aerohive, preaching the goodness of controller-less wifi, for over 3 years.