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
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
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.
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:
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.
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!
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.