AP Signal weaker than other APs further away.

Ching023
Here to help

AP Signal weaker than other APs further away.

We have 6 MR53 APs in office, ceiling mounts, all of them are about 11' above the ground. The Office is around 6k square feet. all in 1 floor, has a brink wall in the middle to session out the area.

There is 1 AP (let call it AP1) signal seems weaker than other APs, a laptop would still connect to other AP where is was connected to, even the laptop is now right under that AP1. And the signal strength of AP1 showing in my.meraki.com is weaker than all other APs even those were behind the brink session wall.

 

To make the frustration more, if the laptop was turned on around that AP1, then it would connect to AP1 with no problem, and would showing with strong signal.

 

A little more detail on our wifi setting.

We are using 802.11ac, Layer 3 roaming, 5GHz only, Minimum bitrate is set to 48Mpbs.

We are in a very noisy building. some very strong 802.11n signals are detected from other companies upstair.

 

Anyone has any idea how to trouble shoot this AP issue?

 

Thanks a lot,

15 REPLIES 15
PhilipDAth
Kind of a big deal
Kind of a big deal

It could be interference.  If you go:

Wireless/RF Spectrum

Does "Avg. channel utilization (5 GHz)" show plenty of capacity available, or is it quite congested?

 

Hi Philip,

Thanks for jumping into it.

I just checked.

it shows 9% - very low.

 

thanks,

PhilipDAth
Kind of a big deal
Kind of a big deal

Does it show it is running on 802.3at power?

Hi Philip,

 

Where to check if that is running 802.3at power?

I don't see it in the RF spectrum screen.

 

thanks,

PhilipDAth
Kind of a big deal
Kind of a big deal

Check the power at:

Wireless/Access points/[Click on AP]
The scroll down to power.  Here is an example from an MR42.  You wont to see that it has 802.3at power available.

 

Screenshot from 2017-10-26 11-20-46.png

thank you Philip,

 

I saw that now.

it's showing around 9W to 13W running PoE 802.3at

 

thanks,

Mr_IT_Guy
A model citizen

We actually had an issue similar to this. When I swapped out the troublesome AP with another AP of the same model, it resolved the issue.
Found this helpful? Give me some Kudos! (click on the little up-arrow below)
Adam
Kind of a big deal

May also be worth going to Wireless>Radio Settings to check the transmit power.  If set to auto it could be lower if it detects stronger AP's nearby.  

Adam R MS | CISSP, CISM, VCP, MCITP, CCNP, ITILv3, CMNO
If this was helpful click the Kudo button below
If my reply solved your issue, please mark it as a solution.

Hi Adam,

 

from the Radio Setting screen, it does shows Auto, and that AP1 is showing lower dBm than other APs,

others are 20+dBm and that AP1 is showing 15dBm.

 

Thanks,

PhilipDAth
Kind of a big deal
Kind of a big deal

Then it looks like the Meraki system has deliberately retarded the power.  This is usually a good sign.

 

It implies you have quite a bit of coverage overlap.  Reducing the power levels allows it to re-use the limited number of channels more frequently.

I guess, we might need to manually tune this AP to higher power.

since our CEO is sitting close to that AP, and his connection was having issue. got quite high in Latency.

tested from the Meraki portal -> Client, ping. the average latency was over 200ms

PhilipDAth
Kind of a big deal
Kind of a big deal

You could also try changing the power from automatic back to maximum as well.

Adam
Kind of a big deal

Probably not a best practice but we keep ours at "Always use 100% power" for the Radio Power settings. We had similar issues to you in the past.

One other issue we observed due to our overlap in our wifi is if someone walks with their laptop from one part of the building to another. Sometimes their computer will try to hold on to its connection to the farther AP since it still has some signal, albeit weak, rather than switching to the closer AP. Usually they just have to turn off wireless and then turn it back on and it'll connect to the stronger/closer AP. But it doesn't sound like this is your CEO isn't moving.
Adam R MS | CISSP, CISM, VCP, MCITP, CCNP, ITILv3, CMNO
If this was helpful click the Kudo button below
If my reply solved your issue, please mark it as a solution.

Hi Mr,

 

I was suspecting the same, but want to eliminate other possible issues first. and not sure if Meraki would replace the AP or not.

 

Thanks,

MerakiDave
Meraki Employee
Meraki Employee

One other best-practice that comes to mind if it might help with your fine tuning...  As a rule of thumb you want to at least disable the lowest two data rates in each band.  Selecting 12 or 18Mbps is a common practice.  You can do this SSID-by-SSID on the Access Control page.  This also has the (usually desirable) effect of disallowing very old legacy 802.11b devices from associating and avoids the protection mechanisms (and associated performance impacts) for backward compatibility.  

 

The default setting of 1Mbps creates the largest possible coverage circle, allowing clients to stay associated to APs very far away (despite other APs being closer) and staying connected with lower signal-to-noise ratios, therefore at lower data rates.  Lower data rates will impact channel utilization since the data will be modulated onto the RF carrier that much slower.  This causes a very high duty cycle (slower clients take longer to transmit the same amount of information) and impacts performance for every other nearby client.

 

It's a half-duplex shared medium, channel utilization is a critical factor, and there is a large impact on the time it takes to modulate a signal into the air at 1Mbps versus 12 or 18Mbps.  The faster a client can get on and off the air, the better.  Using 12Mbps as a minimum bit rate improves channel utilization and encourages better roaming behavior.

 

What we do NOT want to do is try to artificially force all clients to the higher data rates (like 48 or 54Mbps), as this can also create client problems.  Remember, the CLIENTS, not the APs, ultimately make the roaming decisions, and we cannot control the clients, but we want to get them behaving well, by making it as easy as possible for devices to access the medium on a reasonable data rate with a good SNR.  Thus the best practice is to size your coverage cells (resulting from a site survey) to allow the proper cell overlap (for example 15 to 20% overlap with -67dBm edges) to allow the elimination of lower data rates <12Mbps.

 

If you find that you MUST support 802.11b data rates (those use cases still exist), consider using AP tags and SSID availability to only broadcast a legacy SSID at the 11Mbps rate from specific access points for example.

 

Also, to reiterate what @Adam said, use automatic power reduction and don't run all APs at 100% transmit power.  Since many of the APs will “hear” one another, especially in relatively open spaces, and in many designs you might plan for roughly 20% cell overlap, you can end up with lots of APs within range of one another.  If all APs are set to use maximum transmit power, all the APs are just screaming at one another and you end up with far too much cell overlap, far too many APs within range of one another, and too much co-channel interference.  Needless to say that will contribute to wacky roaming behavior.  And remember that while APs might top out at 30dBm (1 full watt of Tx power, that's a lot) many client devices, especially handhelds, might only top out at 15dBm, because for them it's all about battery life.  And those are dBm's so that 15dBm isn't half the power, it's more like 30 milliwatts for the client versus 1000 milliwatts for the AP.

 

Using Automatic Power Reduction will allow all of the APs to not only properly balance their channel settings, but more importantly their transmit power settings.  After Automatic Power Reduction has been running for some time, and perhaps after running an Update Auto Channels overnight, look back at the Transmit Power column on the Radio Settings page to make sure the way everything "settled" makes sense.

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.
Labels