Wireless Access

Reply
Occasional Contributor I

Heat map quirky behavior

I'm VERY new to Aruba and Wireless....so please be gentle! :)

 

While deploying new AP 105's at a new site, I've noticed that the Layered SNR heat map for ALL newly deployed APs show an area of reduced signal quality immediately to the top of the AP (with "top" meaning towards the top of the diagram).  I understand that the AP 105's are omnidirectional.....and also realize that many factors can impact the SNR values shown.  However - regardless of the location within the building the new APs are deployed, the "dead" space is ALWAYS showing up in the same spot for ALL APs (all are directly "above" the AP on the heat map).  

 

Just to play "devil's advocate", I physically spun one of the APs 180 degrees - no change.  I'm convinced that this perceived dead space is not accurate, since the building I'm working on now is rather large, and the APs are deployed in several locations (there is nothing in the building/structure that would cause reduced coverage as shown on the heat map).

 

Is this simply a characteristic of the Aruba OS/app?  Any ideas/suggestions would be very much appreciated!

Moderator

Re: Heat map quirky behavior

Dan, 

 

Are their any other APs on this floor or the floor above or below?  The way the heatmap is rendered in the Aruba controller is based on how the "other" Aruba APs hear this AP.  If you have an AP deployed on the map that cannot hear (or hears this AP at a very low signal) that is towards the top of this map (on this floor or the floors above or below) this would explain what you are seeing.  It does not mean that the AP is not propagating in that direction well, it just means that we cannot tell whether it is or not because of the real-time information that is being provided by other APs in that direction.  This map is really accurate when you have a good density of APs (again on the same floor or above and below since this data is 3 dimensional).  Hope this helps.

 

Regards, 


Austin

Occasional Contributor I

Re: Heat map quirky behavior

This office in particular has several APs that have been deployed for a while....and 3 new ones that were just recently deployed.  ALL APs are showing the same basic pattern - even those that are in close proximity to other APs.

 

It just doesn't make sense that ALL of the "bad" spots are towards the top of the diagram regardless of the APs actual location.

Moderator

Re: Heat map quirky behavior

Dan, 

 

Agree, this does look strange, have not seen this before, sorry, TAC may be able to assist if noone on the forum can.

 

Regards, 


Austin

Aruba Employee

Re: Heat map quirky behavior

How long has it been since you deployed the APs on the map?  There is a default predictive coverage that will be shown until AMP has polled the controller that terminates the AP and has gathered enough info to build a valid coverage pattern.

Aruba Employee

Re: Heat map quirky behavior

Oops.. sorry.  Dont know why I was thinking you were talking about Airwave.... :(

 

Anyway, the same is true for the controllers heat map.  You have to give it some time for the all of the information to be gathered, processed and updated before you will get valid coverage patterns.

 

 

Occasional Contributor I

Re: Heat map quirky behavior

All of the APs along the top and right side....as well as the 2 in the lower-left corner...have been there for over a year.  The 3 along the bottom center/right are only a few days old.

Aruba Employee

Re: Heat map quirky behavior

Is ARM enabled?  If so, do you have power-save aware scanning turned on?  If you do, ARM may be able to go off-channel and scan, so it doesn't know about the other APs.

 

Check the commands:

 

show ap monitor ap-list ap-name xxxx (where xxxx is one of the APs) - does it show the other APs around it?  Do they have good (> 30 RSSI)?

 

show ap arm scan-times ap-name xxxx - does Scans Attempted = Scans Rejected?

Occasional Contributor I

Re: Heat map quirky behavior

From the AP in the upper-right corner:

 

Some of the RSSI values are >30, some are not.  In NO instance is the scan attempts/rejects the same.

 

chanap-typephy-typedosmtitload-balancenstasavg-rssicurr-rssiwired-macs
----------------------------------------------------------------------
44valid80211adisable32052870disable13030256
44valid80211adisable32052870disable030300
11valid80211b/gdisable32050660disable0151532
11valid80211b/gdisable32050660disable0151526
44unsecure80211a-HT-40disable982820disable182323256
44valid80211a-HT-40disable471360disable1232361
1valid80211b/gdisable69761disable33131230
6valid80211b/gdisable27910disable00350
6valid80211b/gdisable27910disable1034248
1valid80211b/gdisable12181disable0313111
1valid80211b/gdisable12141disable0161544
1valid80211b/gdisable12141disable21615254
11unsecure80211b/g-HT-20disable452disable011924
11valid80211b/gdisable450disable027250
11valid80211b/gdisable450disable2272487
11unsecure80211b/g-HT-20disable450disable1191550
11valid80211b/g-HT-20disable450disable019170
11valid80211b/gdisable370disable01092
11valid80211b/g-HT-20disable360disable01180
11unsecure80211b/g-HT-20disable280disable0537

 

ChannelScan Time     
-----------------     
channelassign-timescans-attemptedscans-rejecteddos-scansflagstimer-tick
-----------------------------------------------------------------------
36022854226380DVCT3205402
40022854226340DVCT3205413
443205446000DVACT3205447
48022855226400DVCT3205420
52022855226350DC3205434
56022854226390DC3205310
60022854226360DC3205324
64022854226380DC3205334
149022854226370DVCT3205342
153022854226350DVCT3205356
157022854226420DVCT3205370
161022854226330DVCT3205378
165022854226350DVCT3205395
1129161516428155570DVACT3205388
2027439261560DC3205401
3027439261530DC3205412
4027439261510DC3205422
5027439261520DC3205437
686496920073190690DVACT3205340
7027439261530DC3205355
8027439261550DC3205365
9027439261560DC3205372
10027439261570DAC3205379
11104886218508178100DVACT3205447

 

Aruba Employee

Re: Heat map quirky behavior

The Scans rejected should be a small percentage of the Scans attempted.  What is happening is that your APs are trying to go off channel (they do this every 10 seconds by default) to scan other channels.  They do this to try to pick the best channel.  When they attempt to go off channel, something is causing them to not be able to (that is why the Scans rejected number is so high).

 

In your ARM profile, do you have power save aware checked?  If so, you should turn that off (monitor closely, though, just in case you have very old clients that don't handle power save well).  That is probably what is causing the rejects.  This happens when the AP wants to scan another channel but there is at least one client in power-save mode and AP can't go scan. 

 

Not being able to scan also can cause performance issues due to ARM not being able to pick the best power and channel for each AP.

Search Airheads
cancel
Showing results for 
Search instead for 
Did you mean: