Client/AP Stickiness

SOLVED
american_nisei
Getting noticed

Client/AP Stickiness

Hi there!

I support a couple of large shared space co-working locations (think of giant coffee shops on steroids). These locations can host over 200 people and the space is a combination of open floorplan, very large meeting rooms (host over 100 people) and 10 - 15 small to medium meeting rooms / offices (host 2 to 10 people). The space is about 5K sq ft and is located in a very RF busy environment.

 

We currently have a full Meraki stack (MX80, MS320, and 6 MR32 AP) and with band-steering, push as many devices to 5GHz.  However, I've had to really throttle the AP transmit power to help with client/AP stickiness issues as people roam about the space.  Before making changes, clients would connect to an AP on one side of the space and stick to that AP even though they roamed to the other side of the space. Their device had just enough signal strength to the far-away AP that they would flip to a much closer AP.

 

Now after the changes, the signal strength for anything but the closest AP is very low, which has helped most clients roam from one AP to another.  But now this has created a problem where in some of the meeting rooms, the signal strength of the closest AP is low, which causes drops, higher latency, and slow performance.  This is like a catch-22!!  

 

Any thoughts on this?

 

1 ACCEPTED SOLUTION

If you set the minimum bit rate to (say) 12Mb/s, clients will be forced to roam as their connection speed drops.  They will then roam (typically) to the next AP with the strongest RSSI.  By using this technique clients will always have a strong signal.  When you limit the transmit power you are forcing clients to use a weak signal.

 

Give it a try.  I think it will work well for you.

View solution in original post

6 REPLIES 6
PhilipDAth
Kind of a big deal
Kind of a big deal

Rather than limiting radio power configure a minimum connect speed. I would recommend 12 Mb/s. Then users will get a strong connection and roam when the connection slows.

Thanks for the response! I've not thought about this, so this looks promising. Minimum Bit Rate doesn't affect 802.11n/ac. Any thoughts on stickiness for those?

If you set the minimum bit rate to (say) 12Mb/s, clients will be forced to roam as their connection speed drops.  They will then roam (typically) to the next AP with the strongest RSSI.  By using this technique clients will always have a strong signal.  When you limit the transmit power you are forcing clients to use a weak signal.

 

Give it a try.  I think it will work well for you.

Ben
A model citizen

Hi,

We have exactly the same sort of network with a co-working space here in Belgium.  (about 1K sq meters and expanding 1st of October)

All our AP's are set to automatically manage their transmit power and the SSID's are set to a Bit Rate of 12Mbps.

 

In the beginning we had similar issues as you describe here and after we switched the Bit Rate up to 12 nobody complains anymore of losing their connectivity because they will roam to another AP much faster.

The default bitrate is 1mbps, so the clients will stick to the AP they are connected to until they cannot get 1Mbps anymore and then they will roam. 

 

Minimum Bit Rate doesn't affect 802.11n/ac. Any thoughts on stickiness for those?

Minimum Bit Rate of 12Mbps only affects 802.11b devices they are not supported. But 802.11n/ac are no problem at all!

 

If you have any other questions about our deployment in the co-working don't hesitate to ask! 

 

Cheers,

Ben

MijanurRahman
Getting noticed

In high density area sometime I suggest to increase the bitrate to more than 12Mbps for faster & effective roaming. Also leave the Radio Power to automatic. Encourage everyone to use 5GHz radio instead of 2.4Ghz if configurable from endpoints. 2.4Ghz imposes noise on wireless networks.

Thanks everyone for their responses.  I will give the Minimum BitRate a shot as soon as I get a maintenance window from the client.  

 

~Doug

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