ClientMatch

The ClientMatch service continuously gathers RF performance metrics from mobile devices and uses this information to intelligently improve the client’s experience. Proactive and deterministic, ClientMatch dynamically optimizes Wi-Fi client performance, even while users roam and RF conditions change. If a mobile device moves out of range of an AP or RF interference impedes performance, ClientMatch steers the device to a better AP to maximize Wi-Fi performance.

ClientMatch is aware of each client’s capabilities while also being aware of the Wi-Fi environment, this puts ClientMatch in the best position to maximize the user experience of each device as we know which radio each station is most likely to have the best experience on. In doing so, ClientMatch is also able to improve the experience of the entire system as slow clients on an access point also affect the experience of other users.

ClientMatch does this by maintaining a list of radios each station can see which is basically a database that states which access point radio that has been able to see the client’s device, and at which signal level. This information is then used, with a list of rulesets, to enhance the user’s experience.

The main difference between AOS8 and AOS10 regarding ClientMatch is that the orchestration of this feature is now handled by Central in the cloud instead of on a Mobility Conductor.

Move Types

There are two types of moves, deauth moves and BSS Transition Message moves, also known as 802.11v message moves.

Deauth moves function by sending a de-authentication frame to a connected station and then not letting this station associate anywhere but to the desired radio for a duration of time after the frame is sent.

802.11v or BSS Transition Messages are an Action Frame sent out by the AP to the station suggesting that they should instead be moving to that BSSID. Keep in mind that these frames are not mandatorily obeyed by the station and are sometimes ignored or rejected. If that happens 5 or more times, ClientMatch will then trigger a deauth move instead.

Band Steer

When ClientMatch sees an authentication being attempted by a station on the 2.4 GHz radio and he station is known to be 5 GHz or even 6 GHz capable, ClientMatch will then not let the client device connect to the 2.4 GHz band, effectively forcing them up to the more efficient bands.

ClientMatch will only attempt to move clients on 2.4 GHz with a worse signal then -45 dBm onto a target radio with a RSSI on 5 or 6 GHz that is better than -65 dBm.

6 GHz band steering can be disabled using the REST API.

Sticky steer

This feature comes into play in a scenario such as when a station associates to an access point while within the prime coverage area and then moves away to the edge of the coverage of the radio but the station does not roam voluntarily. ClientMatch is then aware that there is an access point that would be a better option for the station and as such is able to tell the client to move to the better candidate.

Load Balancing steer

This is a feature that is more frequently used in high density environments such as auditoriums. Load balancing aims to balance out the number of clients on a per-radio basis as to make sure not all clients are connected to the same radio and that instead the load is split across the network.

This move type only uses 802.11v moves and does not attempt to do deauth moves as the clients do not fully understand the load component involved in the computation and might see a degradation in signal strength as a negative outcome.

This specific move type can be disabled using the REST API.

MU-MIMO steer

The goal of this is to move stations that are MU-MIMO capable so that they are on the same radios so that the AP can leverage the MU-MIMO function as two stations of appropriate types are necessary for an access point to be able to do MU-MIMO.

Un-steerable clients

Some stations refuse to cooperate with ClientMatch and as such will be put into an un-steerable station list for 48 hours if there has been three unsuccessful deauth steer attempts or for 24 hours if the client device ignores more than five consecutive 802.11v moves.

This list of un-steerable clients can be viewed using the REST API. Client devices known to not support being steered by ClientMatch can be added permanently to the un-steerable list by

using the REST API.

Disabling ClientMatch

Should ClientMatch be suspected of causing issues in the network, or if there is a desire or requirement to allow the devices to choose the connected access point without attempts for steering, then ClientMatch can be disabled using the REST API.

ClientMatch Monitoring

In the Network Operations app, set the filter to Global.

1. Under Alerts & Events, click Events. The Events page is displayed.

2. Click on the CLICK HERE FOR ADVANCED FILTERING toggle to bring down the filtering options.

3. Click the ClientMatch Steer option.

4. Click the Filter button on the right.