A fun story that happened to me at a university:

They did as you propose.  2.4GHz only and 5GHz only separate SSIDs.  first week 
of school they had ~80% of clients on 5GHz.

About three weeks before the end of the semester, Wi-Fi complaints have gone 
up, and the percentage of clients on 2.4GHz had grown to 50%.  This is when i 
got a call to come look at it.

Over the course of the semester, a DHCP outage and internet circuit outage led 
folks to try “to see if the other network was working.”  But, when students 
arrived on campus every morning, they picked up the 2.4GHz only network first.  
Then they spend all day, because client won’t leave the 2.4GHz SSID while it’s 
present.

I asked for a 2 minute outage for the 2.4GHz network.  I disabled it for 2 
minute and then re-enabled.  10 minutes later it was back to 80% 5GHz and 20% 
2.4GHz.

The moral of the story: you can’t out engineer people’s behavior.  When things 
break, when they experience issues, they will try to work around it.  As much 
as some folks might imagine their networks are perfect, I’ve yet to find one 
that is.

The best way to overcome this, have a 5GHz only SSID and a Dual Band SSID.  
That way if students do choose to connect to the other SSID, they have a way 
for their device to make a better choice most of the time.  This also ensures 
that you can do the Apple Watch with a 2.4GHz radio without dramatically 
hurting their iPhone’s connectivity.

In summary:
Use dual band instead of a 2.4 GHz only network
Make sure 5GHz is 6db greater than 2.4GHz in transmit power.

I would also add, make sure you don’t use band steering on either network.

Jake Snyder



Sent from my iPad

>> On Jan 31, 2020, at 4:13 PM, Seddon, James 
>> <00000159faeb9fd9-dmarc-requ...@listserv.educause.edu> wrote:
> 
> Happy Friday, everyone!
>  
>                 In high density areas of our campus (library, center of 
> campus food courts, large lecture halls, etc), we often turn off some 2.4Ghz 
> radios to help avoid co-channel interference issues.
>  
> We think we’re seeing behavior where client devices in motion attach to an AP 
> in 2.4, then stubbornly hang on to that frequency (and sometimes AP), even if 
> they end up in a location with a much stronger 5 Ghz signal from a closer AP. 
>   And of course, with the messy nature of the 2.4 band, they’re even more 
> susceptible to interference using a weak signal from a distant AP.
>  
> We do have Cisco’s band steering already in play, but we think it might be of 
> limited benefit in situations like this.  Our general advice is for clients 
> to prefer 5.0GHz when they can.  But we think most users are just letting 
> their devices do what they want, and we really have no control over that.
>  
> We’re considering converting our main SSIDs to offer 5 GHz only.   And then 
> creating a new SSID that offers 2.4 service (MainSSID2-4, or Legacy2-4, or 
> something).
>  
> Because we believe we have good 5.0GHz coverage, we think this change would 
> be invisible to most users who have 5 GHz capable devices.   Their devices 
> are already configured to connect to our main SSID, and they would just do so 
> in 5Ghz from then on.  They’d see the 2.4 SSID offered if they looked, of 
> course.
>  
> Clients that are 2.4 only would see our SSID disappear, and need 
> reconfiguration/reattachment, accept the cert…all the usual onboarding stuff. 
>   Because of this, we’d only make this change after an extensive 
> communication period to include our support teams, campus partners, and 
> customers.
>  
> Most of our campuses IOT-kinda-stuff (which tend both to be 2.4 and need more 
> attention/configuration) are already on a separate SSID that we wouldn’t be 
> touching.  So nothing would change for them.
>  
> Questions:
>  
> 1.       Have other large campuses done this?  We have ~400 buildings and 
> ~7,300 access points.  We have upwards of 60,000 peak concurrent WiFi 
> connections, with maybe 14,000 of those in 2.4.  We don’t know how to tell 
> how many of those can ONLY do 2.4, and how many are 5Ghz capable, but just 
> aren’t for some reason.
> 2.       How did it work?
> 3.       What were the lessons learned/gotchas, either from a technical or 
> non-technical/communication perspective?
>  
> Other advice?
>  
> Best Regards,
>  
> James Seddon
> Enterprise Network Operations - Voice and Data
> Information Technology Services (ITS)
> UC San Diego
> 858-822-4040
> jsed...@ucsd.edu
>  
> **********
> Replies to EDUCAUSE Community Group emails are sent to the entire community 
> list. If you want to reply only to the person who sent the message, copy and 
> paste their email address and forward the email reply. Additional 
> participation and subscription information can be found at 
> https://www.educause.edu/community

**********
Replies to EDUCAUSE Community Group emails are sent to the entire community 
list. If you want to reply only to the person who sent the message, copy and 
paste their email address and forward the email reply. Additional participation 
and subscription information can be found at https://www.educause.edu/community

Reply via email to