Wireless clients are not distributed eventually.

[Sayem]

Hi,

 I have some MR42 in my organization floor. i noticed that wireless clients are not distributed eventually. Like one AP has 60 clients another AP has only 20 clients. Some users are connecting to a AP which is far way though there is AP near to client.
My scenario is: MX100<===>MS210-24P<===>MR42

What is the client load balance settings

--

Sayem

[PacerX]

Hello @Sayem, Not sure if this will help but here is what I found in the Meraki Documentation: https://documentation.meraki.com/MR/Other_Topics/Client_Balancing

[Sayem]

I will try this but can not test this right now due to current pandemic covid-19 office is closed.  I'll post here once i do get a result.

[NolanHerring]

Client Balancing is more of a suggestion, and it tends to hurt more than help when it comes to roaming. However if you don't have any voice/real-time apps being used you can give it a shot.

You might be better off checking the access points locations and power settings. The best way to shape a cell size is via power so see what it is running at and you might want to lower it.

[PhilipDAth]

I like using the "minimum connection speed" to help with this case.  At a minimum, I would set the minimum connection speed to 12Mb/s.

[JohnD]

If you so choose, shrinking the coverage radius (either via setting a bss minrate, reducing transmit power, or using RX-SOP) is the most natural and universal way of forcing a client to use a closer AP.

However, most clients tend to have roaming algorithms these days that will choose the most favorable AP, so you'll have to consider a few things:

• Is there something about the channel assignment? For example, is the nearby AP on a DFS channel and the client doesn't support DFS?
• Is there something in common about the client? Modern iOS/Android/Windows devices do a fairly decent job of roaming on their own
• Meraki APs advertise the QBSS load element correctly, which describes how busy the AP is as well as how crowded the currently selected channels are. Could your clients be realizing that the overloaded AP is undesirable and as a result be trying to spread themselves out?

How unreasonable are the far away AP associations? What kind of RSSI is the AP seeing for the clients that you think connected to the wrong AP? From the client side, most clients think APs above around an RSSI of mid-70's or better are basically equivalent. It could just be that your floorplan and AP configuration is making it look like there's a lot of usable APs from certain client locations. That's not necessarily a bad thing unless co-channel interference is getting in the way -- having that kind of resiliency is good in the event that one of your APs fails for whatever reason, you still have some overlapping coverage.

[MerakiDave]

Hi @Sayem and welcome to the Meraki Community.

Here is a lengthy answer but touches on the main points regarding roaming behavior & balancing and includes a couple tips I spotted in the other answers.  This is where some of my colleagues like to accuse me of getting paid by the word, but I assure you I'm here on a volunteer basis, LOL. 😁

With all that follows below, the key thing to remember is that it will never result in a perfectly even distribution of clients across all APs in a deployment. There are MANY input variables, some of which are constantly changing.

For starters, consider running the latest stable 26.6.1 firmware if you're not already.  You could check with Meraki Support first to scrub your config and confirm 26.6.1 is a good choice, just in case there's a known issue specific to your environment or AP models and features you're using.

Remember that it's ALWAYS the client's (not the APs) that ultimately make the roaming decisions, and it varies wildly by device vendor, by operating system, and by device driver versions on similar devices from the same manufacturer. I've seen devices cling for dear life to an AP 50 feet away when it's right underneath another AP. It's very device-dependent.

So we cannot control the clients, but we try to get them behaving well via best practice settings. And even then, they don't always behave well, and still varies by device type, OS and driver version. And don't forget that every RF environment is going to be different, and in a given RF environment, every client is going to have a different perception of it. Different vendors and different operating systems will use different methods, often based on RSSI, which is typically proprietary and different phone/laptop/tablet manufacturers implement in different ways.

It can also depend on if and which 5GHz channels may or may not be supported by the client, there are still many clients/radios/drivers that don't support all of the 5GHz channels. This raises the definite possibility that some clients will not roam to an AP only a few feet away because they cannot "hear" it if they don't support the channel the AP is using, so they stay associated to an AP 100 feet away.  That type of issue usually gets addressed during design time and planning for the least-capable but significantly-present clients.

Even if clients DO support all the same channels the AP is using, it is entirely possible that client devices can stay "sticky" to an AP (even through a ceiling or floor) even with another AP in the same room. Obviously there's going to be signal attenuation through a ceiling/floor, but there could still be enough signal strength to keep the client happily associated at a reasonable data rate.

Newer clients that support 802.11k, 11v, 11r (all of which were there since r25 firmware) can leverage neighbor reports to interact with APs to make optimal roaming decisions, and APs can assist with client balancing (11v) and advise the client the best AP to roam to based on AP load. But still, it's the client who makes the decision and initiates the roam. And that decision process is a dynamic one with constantly changing variables, such as people (attenuators) moving around.

I've observed various roaming behaviors in my own home, with a basement office AP and an AP in a 2nd floor bedroom. Some devices will consistently roam from AP1 to AP2 when I get within 15 feet of the AP, while other devices will stay associated to AP1 no matter how close I get to AP2.

Always implement standard best practices, like setting minimum bit rates (to 12Mbps for example), using automatic power reduction, band steering to 5GHz, minimizing the number of SSIDs, using an appropriate channel width, including DFS channels if appropriate, etc. For a large deployment I'd suggest an active post-deployment site survey to best understand the RF environment and review your channel plan and power levels, determine you coverage cell size and overlap, etc. and then review that against your typical client devices.

And of course you can always get with Meraki Support to take a closer look at your specific APs and clients where you might be seeing roaming issues. Many "roaming issues" can actually be normal behavior given client dependencies and so many variables. Still, Support has additional tools on the back-end to get some insight on how the APs are behaving and communicating regarding client roaming, balancing, band steering, etc.

Hope that helps!

More info
https://documentation.meraki.com/MR/Other_Topics/Client_Balancing 
https://documentation.meraki.com/MR/WiFi_Basics_and_Best_Practices/802.11k_and_802.11r_Overview 
https://documentation.meraki.com/MR/WiFi_Basics_and_Best_Practices/Roaming_Technologies 

[JohnD]

Really awesome post by @MerakiDave!

One more thing I'd add about some of these peculiar roaming decisions.... Apple details some of their algorithms here: https://support.apple.com/en-us/HT203068

Importantly, one thing worth mentioning is that they have a "trigger threshold", if your network strength is better than the trigger threshold, the client device is unlikely to roam unless it's being forced to via 802.11v or another mechanism. If your cells are generously overlapping, this can explain some of the behaviors of modern clients being sticky. Sure there might be an even closer AP, but the client feels its current AP is good enough that it's not worth the effort to roam.

The same concepts apply to a lot of vendors but not all vendors go into technical detail about how their roaming behaviors work. Roaming behaviors also tend to be data dependent. If your client starts a Webex call and then starts walking to a different floor, the client tends to be more reluctant to attempt to roam unless the current AP's connection quality is really poor. Meanwhile if the client is idle, it might be more proactive roaming since there's no risk of user-visible wifi issues if for whatever reason roaming took longer than expected.

Some of this needs to be factored into a network design and AP placement, but it's also worth just stopping to consider whether or not a distant client is actually presenting a problem or not.

[GIdenJoe]

Natural load balancing can also come from not using omni directional antennas.
You have to think about the logic of a client.

Assume you have an entryway into an office and the clients first connect to that AP.
Then they go a little further in the office but still have plenty strength towards the first AP so they will never roam.

The only way a client will actually join the AP right on top of it is if the user disables and re-enables the WiFi.

So yes you have roaming suggestions from the AP's through 802.11v.  But in some spaces you might want to go MR42E with a patch antenna pointing straight down causing a more downtilt signal and a less spread out signal.  This will cause the clients to drop off one AP and connect to the next.