Client balancing uses information about the state of the network and wireless client probes to steer the client to the best available access point. Steering the client to the best available AP improves download and upload performance while reducing loss and latency for mission-critical applications. Client Balancing is compatible with all client device types and uses a combination of Meraki-proprietary and industry-standard techniques to gather information and steer clients.
Client balancing is available in MR 25.X and more recent firmware and enabled by default in RF profiles. It was first introduced under the name AP Steering.
Several metrics are gathered by each AP to ensure that the best client and AP match is made. RF environment metrics and the algorithm's wireless clients heard by APs are factors. These measurements are captured in real-time and shared amongst nearby APs in the Meraki network.
Each AP has a local database that stores clients' metrics, both associated and not associated. This information is shared between each AP on the LAN via broadcast messages with an encrypted payload. Note that this message encryption is dynamically configured and secured by the Meraki cloud.
Note: Broadcast frames for this information use UDP port 61111 and are sent over the LAN infrastructure.
APs on the same LAN segment will automatically send and learn the information needed to make informed client balancing decisions. This feature was designed for nearby APs, which typically reside on the same LAN segment (for example, a floor or a building may all share a common management VLAN). Since Client Balancing information is sent via broadcasts, any existing network segregation will ensure that Client Balancing intelligence is kept within its relevant area.
Note: Since the feature relies on AP to AP communication, administrators need to ensure that inter-AP communication is allowed and port isolation is turned off.
Warning: If you use multiple management VLANs for APs in the same Meraki dashboard network, ensure they're correctly pruned. APs will acknowledge UDP 61111 traffic regardless of what VLAN it arrives on, which is necessary to avoid inaccurate load-balancing metrics.
Each AP measures the RSSI for management traffic sent by nearby clients. The Meraki RSSI is a combined measurement of noise floor and client signal strength, and it’s normalized across MR models. Each access point records client measurements in its local database and distributes the info to neighbor access points. The tables update in real-time as updates are triggered, allowing the APs to react more quickly when making steering decisions.
Each APs current load is also shared with its neighbors. The load metric is defined as the number of existing clients connected to the AP. The load metric determines a better possible AP for a client connection.
Client Balancing operates without cloud interaction and utilizes several robust features discussed below to make steering decisions.
Per-Client AP Resource Group
The Meraki APs create an AP resource group for each client. A resource group is made based on the notion that not every AP in a network is a good candidate for the client's next connection. Therefore, when multiple APs hear a given wireless client at 30dB or higher, those APs become a resource group for the client. The load algorithm then attempts to load APs within a client resource group evenly.
Note: If a client is not heard by any AP at an RSSI of 30 or higher, it will not be steered.
Roam-Through for VoWiFi/VoIP
Clients using real-time applications like VoIP or video collaboration roam from one AP to another using fast roaming technologies. For example, suppose a Meraki MR access point senses this roaming by detecting a re-association frame. In that case, the client will be permitted to join regardless of whether there is another preferred AP to ensure minimal roaming latency for these sensitive applications.
Client balancing only analyzes directed probe requests from clients for SSIDs configured on the AP when considering an AP in a particular AP resource group. This behavior ensures that client balancing will continue to make the most intelligent decisions even if the SSID availability feature is enabled or a radio on a particular AP is disabled.
Sleeping Client Detect times out data for mobile clients that are not actively roaming but physically moving. For example, a mobile device is in your pocket while in power-saving mode. Mobile devices tend to shut down radios to preserve battery life. When the mobile device leaves sleep mode, it will re-connect to the wireless network.
Many environments are designed with APs in distinct areas where the APs do not see clients in each area in other areas. If a client is measured in one area and then moves to a new location while in power save mode, the APs may not be able to track the roam. Measurement data for the client times out after 10 seconds to ensure that APs only within the physical area local to the device are used for steering decisions.
BSSID Block List Protect
For various environmental or wireless adapter driver reasons, a client may not always transition to a preferred AP as the client balancing feature offers. However, it will always be admitted if the client attempts to associate with the same AP a second time.
Note: This failsafe mechanism ensures that a client will only experience a brief delay when resending association frames (usually less than 5ms) and that the client does not block the BSSID. Clients occasionally employ BSSID blocklisting to prevent continuous connection failure.
Steering a Client via Association Rejections
During the association process, a client may be rejected with a reason code 17 message indicating that the AP is busy in order to guide the client to a different AP.
Event log reporting
Dashboard will report when Client Balancing is triggered for a client within the Event Log. Using the Event Log's built-in filtering, an administrator can filter on load balancing events and drill down to a particular access point or client if required. The event will report details about which AP is preferred for the client association.
- load - Number of current clients on the Client Balancing AP
- best_ap - IP address of most preferred AP for client to join
- best_ap_load - Number of clients connected to the most preferred AP
- best_ap_rssi - Client probe request signal strength measured by preferred AP