Removing the Bottleneck in Wireless

By cjoseph posted May 24, 2013 08:49 PM




In wired as well as wireless networks, there is a great deal of oversubscription.  That email server with a single a dual gigabit connection could not possibly serve all of those wired clients in that organization, can it?…but it does.  Everyone who has been in the business long enough remembers having a very sub-par connection to the internet, and somehow it still served everyone who needed access to it.  Today, we still have the same issue, where the resources that serve users is much lower than the aggregate user need in both wired and wireless networks.  Wireless networks need different consideration.


In most circumstances, there is some sort of time slicing mechanism that gives each user some of what they need and to the user, it appears that he/she has good access to their resources.  In wired networks it is somewhat predictable to understand what clients are where and what resources they will need because they are for the post part immobile.  Traffic patterns can be modeled fairly easily.  Switches arbitrate traffic between clients and buffer traffic to be delivered in a predictable fashion.  In a wireless network your clients can show up anywhere, so planning is much more difficult and there are issues like contention and interference that will rob you of time slices that you could give to your clients to provide better service. The key  to providing consistent service is to remove alot of the things that could cause you issues ahead of time, so if there is something that you CANNOT remove, you will at least have enough headroom to deal with issues you must accept. Here are a few things that you can do to make sure you reserve enough headroom for your clients:


- When planning a site, try to do a spectrum analysis to determine if any device that interfere with your wireless frequencies exist.  Non-wifi compliant interfering devices do not know the rules of the road, so they will not attempt to play nice or share the spectrum with your wifi clients and access points.  That can impose a serious penalty on the available throughput in the medium.  Frequently, people who do not run the wireless like security and building service people will put up wireless devices, not knowing that it punishes the user experience.  Start off on the right foot by identifying these issues and then dealing with them.  Turn on hybrid spectrum analysis on ArubaOS once in a while when you have any suspicions to determine of a mystery  interferer has taken up residence.  

How to turn on Spectrum Analysis in Instant

How to turn on Spectrum in Controller-Based APs (Requires the RF Protect License)


- Use The Right Encryption Type and only choose and purchase clients that support them - The only encryption types that support 802.11n speeds are Open and AES (WPA-AES, WPA2-AES  and Open Encryption allow full speed).  Anything in between like the flavors of WEP and TKIP support a maximum association rate of 54megs an realistically that is cut in half, due to overhead.  Those clients with the wrong encryption type will drag your WLAN down to the least common denominator and will hurt the performance of every client within earshot.  How would you like it if the highway was only a single right lane? 


- Correctly Space Your Access Points - Most office environments that use regular drywall work best with a spacing of one 802.11n access point for every 50 or 60 feet for coverage in open areas.  If you make it closer than that, you run the risk of introducing contention which puts 2.4ghz access points near each other and into each other's broadcast domain if they share the same channel.  This will drag down your performance even in an 802.11n network because clients have to see, hear and wait on each other.  In a high density environment it could be necessary to put them closer, so please adhere to the high density VRD for instructions on how to deploy in those scenarios.  There are some circumstances, where the most efficient way to deploy is an access point every other room or every room due to density.  Survey before your deploy to understand how your RF propagates.  It will still not hurt to first survey at every 50 or 60 feet to give yourself an idea of coverage and AP density.


- Deploy Your Access Points Closest to your Users - If you are planning a deployment and you have areas like a conference room where users congregate, deploy access points to those areas first in your plan.  Clients have much better performance and maintain higher rates when they are closest to the access point they are connected to.  If you have areas where users gather and need wifi, place access points in those high density areas on the floor first, then go back and fill in other areas where you only need coverage.  If your clients in a conference room also have to connect to their nearest access point through a wall, it will decrease performance and increase issues like hidden node:


- Keep access points of different phy types (a/n/ac) access points separate from each other if possible - Access points within earshot of each other that have different phy types will can provide uneven roaming.  At maximum your clients will favor 802.11n/ac access points, even though a non-802.11n/ac access point is closer and could possibly cause performance issues.  It also will make your RF less predictable.  Try to keep your deployment areas uniform to avoid such issues.

- Pay Attention to Floors Above and Below - RF operates in 3 dimensions and there are few floors that absolutely block all RF unless they are concrete.  Access points right above or below each other create contention domains, so be sure to make a conscious effort to stagger your access points from floor to floor, so that you get them as close to the every 60 feet rule as possible.

- Enable as few SSIDs and BSSIDs as possible - Every WLAN that you broadcast has to send out beacons every second, so the more you broadcast, the more management traffic you send out and the less data you can support.  Anything more than 4 SSIDs and you are punishing your data traffic by putting too much management traffic in the air.

If  clients can use the same encryption, for example WPA2-PSK, you can use a user derivation rule to differentiate by manufacturer OID to place clients that associate into different roles/VLANs so that you don't have to bring up a separate SSID for different devices.  If you know that devices will not support 802.11a, do not broadcast the SSID on that band, to free up airtime for 802.11a clients.  If you are using 802.1x and need to put different clients on different VLANs or roles, use your radius server to send back different attributes to the controller, which can in turn segregate your traffic without having to enable another separate SSID for different users.

- Enable Drop Broadcast and Multicast on all of your Virtual APs - Broadcast and multicast traffic punish wireless and are very rarely used for current applications today.  In addition, Airgroup (on by default) can forward and proxy mDNS and DLNA discovery packets with "drop broadcast and multicast" on to maintain performance.  This is the main reason users say that their wireless works one day and without any changes, it gets worse and worse.  In Aruba Instant it is setting the "Broadcast Filtering" parameter to ALL, under Advanced.  Dropping broadcast and multicast results in a huge improvement in performance and reduces phantom performance issues generated by devices that send out random broadcasts.

For Controller-Based Access Points, you drop the Broadcasts at the Virtual AP level - broadcast and multicast

For Instant APs, you Enable Broadcast Filter Arp - ssid-profile.htm?Highlight=broadcast filter arp


- Start by Setting Set the ARM Min and Max TX power to 12 and 18 respecitvely - The #1 reason for sporadic disconnects and roaming issues is that the power on access points are too high.  If the power on an access point is at 19 or greater, clients will hold onto that access point longer, because they believe they have a great connection and will not attempt to roam to other access points.  By the time the power falls off, the client is 3 floors away from the access point, but has been slowing down the performance of all the other clients on that AP, the whole time.  Clientmatch can kick in eventually and move that user, but setting the power on the AP properly will avoid the performance issue between when the client has moved far out of coverage and when ClientMatch can kick in to put it on the closest AP (sticky move).  ARM min and max TX power is in dbm which is logarithmic, so every 3 db increase results in a doubling of power:  By the time you get to above 18dBm the access point's power will be almost double that of most devices, so clients will be able to hear access points, when access points cannot hear them as well.  That will result in (1) clients hanging on to APs longer, because they think that they can speak to them as well as they hear them (2) disconnects due to clients missing beacons due to distance (3) excessive clientmatch moves due to the access point disagreeing with the client's perspective of the network:


  • 0dBm = 1mW
  • 10dBm = 10mW
  • 12dBm = 15mW
  • 18dBm = 63mW
  • 20dBm = 100mW
  • 21dBm = 125mW
  • 22dBm = 158mW
  • 23dBm = 199mW
  • 24dBm = 251mW

 As a reference iphone5 = 13dbm (20mw) max output

In Controller-Based APS, the Minimum and Maximum Transmit Power is Set in the ARM Profile - profile tx

In Instant APs, the minimum and Maximum Transmit power are set under RF> Show Advanced.


- Make sure your 802.11n/AC access points are on gigabit ethernet ports so that your physical interface does not become the bottleneck.



- Do not enable "Local Probe Request Threshold" with Clientmatch. - ClientMatch should fully replace the functionality of local probe request threshold in the SSID profile.  Enabling lprt unfortunately, will have access points ignoring clients that it should be servicing, unfortunately when ClientMatch is enabled.  Leave it at zero (the default).  


- Make sure your wired uplinks are correctly subscribed - A good ballpark calculation for controllers is to have one gigabit ethernet port for every 100 access points that terminate on it.  That will give you enough headroom for the burst that is not always seen when measuring interfaces using management software.  Random congestion can cause client issues.  Access points that rebootstrap with missed heartbeats is a symptom of possible oversubscription.

- Make sure all of your access points and controllers negotiate properly on wired interfaces and that your access points are not bootstrapping - Access points that do not negotiate properly and have errors on their wired interface is a common and silent cause of network degradation.  It can also cause mystery "coverage holes" due to access points being unavailable.  Periodically check your interface for errors and your access points and logs for rebootstraps (show ap debug counters) to deal with this silent but important issue.


- 80 mhz channels are enabled by default and it does not give enough channels for separation in high density.  You should go to 40mhz channels by disabling 80 mhz support in the ARM profile.  You could even go all the way to 20mhz channels if you are still having issues by making sure "allowed bands for 40mhz" is set to "none" in the ARM profile.  That will give you the most channels to work with without enabling DFS.

In Controller-Based APs, you can set devices to 40mhz channels in the ARM profile by unchecking 80 mhz channels and make sure "allowed band for 40mhz" is for 5ghz only.  You can enable 20 mhz in Controller-Based by making "allowed band for 40mhz" to "none".

In Instant APs, you can enable 40 mhz channels by going to RF> Advanced and making sure that 80mhz channels is unchecked.  You can enable 20 mhz channels by making sure that "Wide Channel Bands" is also set to "none".


Lastly, do not run 802.11r on an SSID in a mixed client environment.  There are some clients that like it, others that do not, and others that show intermittent connectivity issues.  Don't bother, because it is not required for good roaming performance, but it can cause issues.

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:



Well, that is all for now.  There are quite a few other things that can be checked to ensure you have good performance, but those are most of the big ones.  See you next time...



Jun 17, 2015 06:48 AM


A must-read for all WLAN engineers!!!

May 27, 2013 10:24 AM

Thanks for the response

May 26, 2013 11:57 AM



Load balancing in general is designed to even out the number of devices on an access point, or channel.  Spectrum load balancing is designed to provide evenness beyond numbers and extend it to the medium, as well.  Depending on your environment this can improve things.  In some  environments the impact is not as big.  One thing that is lacking is tools to specificially measure the impact of spectrum load balancing as well as how to tune it.  That tool should allow you to determine, based on measurements, whether spectrum load balancing is for your environment or not.


I do not have specific details on ARM 3.0 and Client match but it is being designed to take a closer look at client health as part of the metric in determining where a client should be.  Since this is a new approach, you can safely say that it will not "work the same way as before".  There will also be new ways to measure what ARM is doing to give you more insight as to what decisions are being made and determine if it is right for your environment and your clients.  No feature is a benefit in every situation.  "x feature does not work" should be rewritten to say "x feature is not appropriate for your environment", because every feature has a target configuratoin.  Client match should allow you to evaluate and determine if that is the case.


Most features that are in an Aruba controller assume a good physical and RF enviroment that could  use a little help with a little tuning.  It will not turn something that is very bad, into something that is good.




May 26, 2013 11:33 AM


Nice article Colin.


The only thing I am a little bit confused is about using the spectrum load balancing feature , based on my own experience and experiences shared here in the forum it seems that load balancing could sometimes bring more issues to the environment since some devices don't respond very well to the way load balancing works (based on the association response). 


Now that load balancing is part of the new ARM 3.0/ Client Match  I am wondering if it will work the same way as before.



May 25, 2013 12:35 AM

The article mentions 60 feet for areas that are NOT high density. The high density VRD mentions how to deal with those scenarios.

May 24, 2013 11:51 PM

Excellent article Collin!


I just got one question regarding the spacing... and its on Hight density areas.. where is not possible to space that much the APS... what would you do in that kind of situation?


For example on an auditorium where putting the APS down of the floor is not possible guess you can put it on a cage down of the chairs.. but they wont be spacing 60 feets....hopefullly the crowd can do enought RF absortion?


Also what about in schools where you got 40 kids in one small classrooms...

i would need to put 1 AP every 3 classrooms to maybe acomplish the 60 feet rule... but  that would be like 120 kids in one AP

What would you recommend in this kind of situation....

We are managing some schools and they demand us to handle all students even if they are all connected... so  i must assume they are all connected.  In this deployment i was not able to do that... i was putting 1 AP every 2 classrooms... and im sure its less than 60 feet sadly....

But as  a good notice we have not hear any complain about that deployment, they actually recomend us and also aruba to another school as the owners knows each other...


But even if that was successfull  i would liek to deploy WLAN in the best best manner so i would like to hear what do you recommend in those situation, and how we should manage the 60 feet in situaitons like this or similars.