Most wireless client’s aren’t smart, at least when it comes to picking what AP to join in crowded Wi-Fi spaces.
Most devices connect to the first AP they discover advertising the intended SSID to join. If you have enough of these kinds of devices all entering a building or room through a common path, you might find all the clients connecting to the same access point unintentionally.
More astute wireless clients attempt to first calculate the signal-to-noise ratio of the available APs around them and pick the one with the best result. The problem is the same entryway AP still often wins out due to proximity. This tends to lead to the same uneven per-AP client distribution.
More clients associated to a shared AP means more contention for airtime fairness between clients. If the client count really starts to climb, latency and network performance can suffer unnecessarily.
Enter Meraki AP Steering.
Meraki AP Steering Explained
Cisco Meraki’s added some magic to the association decision process by inferring wireless client signal strength accross all APs on the network and (in real-time) steering clients to the access point best suited to service the device.
The best part? It does so automatically; literally zero configuration.
Optimized by default.
AP steering is compatible with all client device types and uses a combination of Meraki-proprietary and industry-standard techniques to gather information and steer clients appropriately.
Every Wi-Fi client broadcasts active probe requests when looking to join an SSID. Those requests scan each channel in the frequency band, allowing every Meraki access point in the environment to identify the client’s MAC address and relative signal strength (RSSI).
Every Meraki access point keeps a live, local database of all associated and unassociated clients it sees including RSSI metrics. The APs broadcast that database information via an encrypted message exchange process over UDP 61111. Since the DB exchange occurs as a L2 broadcast, only APs with management IP addresses on a common segment will participate. This keeps the process local to the relevant floor or building depending on the network design.
Included in the metric exchange is a client count value – enabling every AP to have a real-time picture of the client distribution.
Also interesting is the fact that this process occurs completely independent of the cloud controller. AP steering is a distributed protocol that runs on a local control plane model.
In order to understand how the APs select the most appropriate AP/client pair, we need to first discuss resource groups.
Every AP that hears a given wireless client at 30dB or higher automatically joins a resource group for that client. APs that hear the client at levels below 30dB will not join the group and will not be candidates for steering the client. This prevents unsuitable access points from participating in the client’s group.
APs within a client resource group then algorithmically distribute the load within the group by steering the client to associate with the least loaded access point that also offers strong relative signal-to-noise characteristics.
SSID Blacklist and Resource Group Timeouts
If a client does not move to the AP it is steered to but instead repeats an association attempt to the same AP a second time, it will be permitted to join its desired access point. This fail-safe mechanism prevents clients from blacklisting Meraki SSIDs due to an AP not participating in the client’s association process.
If a mobile client is in low power mode, it is common for the device to temporarily power down the Wi-Fi radios when not in use to extend battery life. If the device physically moves to another area before waking up, APs in it’s original proximity no longer need to retain its RSSI state and resource group membership details. For this reason client steer data ages out after 10 seconds to keep only current and locally relevant information.
There are two different methods used by Meraki APs to help steer the client to the load-appropriate access point,  802.11v BSS-TM exchange and  generic association rejection messages.
802.11v Transition Management
Modern wireless clients that support 802.11v Basic Service Set Transition Management support sharing of network information between APs and clients.
During the association process, a Meraki access point will attempt a 802.11v BSS-TM exchange with a joining client. If the client participates in the exchange, the AP will send a 802.11v BSS-TM frame indicating the more preferred AP it should connect to.
The AP’s BSS-TM frame also includes a list of neighbors and a their current loads. This reduces subsequent client scan times making faster and more graceful steered roams.
If the client doesn’t support 802.11v BSS-TM, a less preferred AP can send a association reject with a reason code 17 message indicating that the AP is busy in order to steer the client to a different, lower-load AP.
Note that this method is far more crude and lacks the specific access point recommendation that the first BSS-TM option contains. While less ideal, this capability preserves steering support for older clients on modern Meraki wireless networks.
Logging Steering Events
Dashboard’s network-wide event log includes AP steering event information. When an AP steering action is triggered, an event will be generated.
Steering events can be found quickly by typing load balancing in the event type include dropdown selection.
Steering events will be logged with the following detail: