Wireless Access

last person joined: yesterday 

Access network design for branch, remote, outdoor, and campus locations with HPE Aruba Networking access points and mobility controllers.
Expand all | Collapse all

Channel bonding, 802.11 alphabet soup, and that kind of thing

This thread has been viewed 2 times
  • 1.  Channel bonding, 802.11 alphabet soup, and that kind of thing

    Posted Nov 11, 2015 03:14 PM

    In a dense deployment, 40/80MHz channels are usually not a good thing.  So I log into my controller and find there are TWO distinct places to disable it:

     

    Wireless LAN > RF Management > 802.11[a,g] radio > Allowed bands for 40MHz channels

    Wireless LAN > RF Management > 802.11[a,g] radio > 80MHz support

    Wireless LAN > Virtual AP > SSID > High-throughput SSID > 40MHz channel usage

    Wireless LAN > Virtual AP > SSID > High-throughput SSID > 80MHz channel usage (VHT)

     

    Can I assume the intention here is to provide per-SSID advertisement of HT/VHT support (is that a thing?), or a per-radio (or per-band, as the case may be) knob that affects all SSIDs?

     

    While we're here, I'd like to optimize AP roaming.  Use case is highly mobile employees using laptops, tablets, phones, and WiFi enabled socks.  Goal is to walk through a facility with some nearly 30 APs, and preferably not stay attached to the one AP mounted in the boiler room by the main entrance the entire time.

     

    The IEEE has drafted an array of wonderful extensions that should make roaming a non-issue for any card developed since 2008.  Naturally, WiFi card driver developers are doing everything they can to ensure that enabling these features results in zero connectivity for anyone.  Understood.

     

    However... use of a good portion of the 5GHz band is contingent on DFS, which as I understand, requires 802.11d and/or 802.11h to function.  Nonetheless, we're still able to selectively enable this at:

     

    Wireless LAN > RF Management > 802.11[a,g] radio > Advertise 802.11d and 802.11h Capabilities

     

    I will assume that this switch is exactly what it says:  ADVERTISE capabilities.  I'm a little unclear whether it has any effect on the 5GHz band, since it kinda has to be there for DFS to work, right?  I'll assume it's an option for 2.4GHz, and is only listed in the [g] radio config because ArubaOS doesn't distinguish between radio bands when attaching profiles.  Is this reasonable?

     

    Likewise, in the same page, we have "Enable CSA".  I would really love to turn this on, because ARM is a bit twitchy at the location in question.  Is this switch independent of the 802.11d/h avertisement?  (I.e., can CSA be enabled with d/h advertisement disabled?  Is that a good idea, a bad idea, or rather irrelevant?)



  • 2.  RE: Channel bonding, 802.11 alphabet soup, and that kind of thing
    Best Answer

    EMPLOYEE
    Posted Nov 11, 2015 03:25 PM

    You should break your post up into multiple posts so that it can get answered succintly, but here goes:

     

    The ARM profile is the master switch that determines whether you are using 20 mhz, 40mhz or 80 mhz (default).  To do 40mhz, uncheck 80 mhz support in the ARM profile.  To do 20 mhz, uncheck 80 mhz support and make "Allowed channels for 40mhz" to "None" in the ARM profile.  To enable/disable channels, that is done in the regulatory domain profile.  20mhz channels, 40mhz channels and 80 mhz channels all have a separate section that are only relevant to whether you are doing 20, 40 or 80mhz channels.  If you uncheck channel 144 for the 20mhz section, it has no effect on what channels are selected when you are doing 40mhz channels;  you would have to uncheck the channel pair in the 40mhz channel section in the regulatory domain profile to allow/disallow channels when you are doing 40mhz channels.  Ditto for 80 mhz channels.  Don't bother with the other profiles you mentioned.

     

    With regards to roaming, there is a Roaming and RF optimization VRD at the link here:  http://community.arubanetworks.com/t5/Validated-Reference-Design/tkb-p/Aruba-VRDs  That will have detailed explanations on what to do.  tl;dr - power is the greatest determining factor about whether a client roams or not.

     

    The IEEE can draft whatever they want; power is the single greatest determining factor with regards to roaming.  There are some standards like 802.11r that work with some clients, but cause problems with other clients, so there's that...

     UPDATE 6/2018 -  The updated RF and Roaming Optimization Validated Reference Design Guide (VRD) has been published and has updated recommendations about enabling 802.11v, k and r in user networks.  The VRD can be found here: http://community.arubanetworks.com/t5/Validated-Reference-Design/RF-and-Roaming-Optimization-for-Aruba-802-11ac-Networks/ta-p/432994

    You can enable 802.11d if you want.  Things will work with or without it.  Some clients require it, however, but they are in the minority (symbol handheld scanners?).

     

    CSA= Channel Switch announcement that some clients support and some don't.  Supposedly it announces to clients when an AP is switching channels so it can follow it.  Realistically, clients are scanning off-channel all the time to select another AP, so in practice, you can leave it off with little penalty.

     

     

     



  • 3.  RE: Channel bonding, 802.11 alphabet soup, and that kind of thing

    Posted Nov 11, 2015 03:57 PM

    Very helpful, thank you.

     

    I'm happy to see the VRD confirm many of my initial thoughts on how to tune ARM for this particular deployment, but there were a few surprises in there as well.  Always nice to gain that insight, and a few new tips and tricks.