Very wide topic, I'll try to provide a few useful pieces of info on the subject. Most of this information is general in nature, based on field experience, and does not benefit from input from any given manufacturer of such 802.11 clients. Details of model, firmware may vary - all appropriate disclaimers apply.
Looking at the data provided, a few items that stand out:
- 802.11d/h not enabled
- too many 5Ghz channels
- High number of neighboring APs
- VHT disabled in 5Ghz
- band steering - use balance-band only if coverage is very carefully calculated - recommend "prefer 5Ghz"
- AP power levels at default,
1. If the devices can use 5Ghz, and there is sufficient coverage in 5Ghz to provide the usual ~ -63dBm primary coverage, lock the SSID to 5Ghz only.
If 5Ghz coverage cannot be achieved, lock the SSID to 2.4ghz to at least elminate band-hopping.
2. Limit the number of channels to a maxumum of 8 channels. If the deployment is indoor, recommend non-DFS channels 36-48 if possible.
consider the newly allowed UNI-III non-DFS channels which are limited to ~13dBm power levels, but this might be acceptable depending on AP mounting and coverage.
Some devices can only handle the 1st 8 (approximately) APs heard to build their potential AP table. This means if the device hears 16 APs, it may take the optimal close APs, may not. Ideal is good primary, secondary and tertiary coverage. a few good choices, instead of many potentially sub-optimal choices.
In any case, reducing the number of channels in 5ghz may help.
3. 20Mhz wide (this is done)
4,. Enable 802.11d/h - this is required for DFS channels, and will help the device know the correct channels and allowed power levels. Will also provide the client with a bit more info with which to make sensible decisions. Some scanning devices require 802.11d
5. if 2.4Ghz will be used , recommend non-overlapping channels, 20Mhz wide
1,6,11
1,6,13
etc..
1,6,11,13 - yes, this is not overlapping, but can be a good choice during initial deployment to
decide whether to use 1,6,11 or 1,6,13 if 13 is allowed in the region.
If ARM sets APs on 13 instead of 11, take a look and see why 11 is not a good choice.
6. check actual ARM-directed power levels, the APs should settle at reasonable values between 9 and 127 EIRP
Use the IAP dashboard, sort on "channel busy" or "utilization" if high radio utilization is seen despite no clients, the power is likely too high.
At the same time, APs busy with high TX rates might be unecessarily flooding broadcast and multicast - check the SSID "broadcast-filter arp" parameter. set multicast-optimize on (DMO only if required)
Based on the AP mounting scheme, a typical power setting for APs that are around 10m apart (path loss around 90, 12-15 EIRP
2.4Ghz should be 6dBm lower than 5Ghz
7. Many summit and other chipsets struggle with 11n and spatial diversity
recommend a careful test using csd-override - this will mean frames will be sent to such clients on one chain. test, change, and test again.
rf dot11a-radio-profile
csd-override
8. Ensure device drivers are up to date
9. Ensure device configurations are uniform and consistent
- do not fix channels, rely on 802.11d (world mode?)
- if configurable, set sensitivity levels reasonable based on coverage.
10. look carefully at coverage/data rate balances - some scanner devices nearly require lower data rates. this is really a design question - the Aruba "small cell" design with high density of AP mounting, low power levels and only high data rates may not be optimal for this environment.
My advise - set the device on a table within good range of an AP, test
continuous frames to/from the client over a period of time, frame loss and 802.11 retries/drops should be reasonable for an SNR > 35.
If this test looks bad, roaming will likely not work well either.
If disconnects can be reproduced stationary, the following data is helpful:
show ap debug client-table
show client
show ap association
show ap debug radio-stats
Important is to differentiate between 802.11/RF issues and higher layer problems such as DHCP, or even IP connectivity.
Hope this helps.