The ARM client match feature continually monitors a client's RF neighborhood to provide ongoing client bandsteering and load balancing, and enhanced AP reassignment for roaming mobile clients. This feature is recommended over the legacy bandsteering and spectrum load balancing features, which, unlike client match, do not trigger AP changes for clients already associated to an AP.
|
|
Legacy 802.11a/b/g devices do not support the client match feature. When you enable client match on 802.11n-capable devices, the client match feature overrides any settings configured for the legacy bandsteering, station handoff assist or load balancing features. 802.11ac-capable devices do not support the legacy bandsteering, station hand off or load balancing settings, so these APs must be managed on using client match. |
When you enable this feature on an AP, that AP is responsible for measuring the RF health of its associated clients. The AP receives and collects information about clients in its neighborhood, and periodically sends this information to the controller. The controller aggregates information it receives from all APs using client match, and maintains information for all associated clients in a database. The controller shares this database with the APs (for their associated clients), and the APs use the information to compute the client-based RF neighborhood and determine which APs should be considered candidate APs for each client. When the controller receives a client steer request from an AP, the controller identifies the optimal AP candidate and manages the client’s relocation to the desired radio. This is an improvement from previous releases, where the ARM feature was managed exclusively by APs, without the larger perspective of the client's RF neighborhood.
The following client/AP mismatch conditions are managed by the client match feature:
| | : Client match balances clients across APs on different channels, based upon the client load on the APs and the SNR levels that the client detects from an underused AP. If an AP radio can support additional clients, the AP will participate in client match load balancing and clients can be directed to that AP radio, subject to predefined SNR thresholds. |
| | : The client match feature also helps mobile clients that tend to stay associated to an AP despite low signal levels. APs using client match continually monitor the client's RSSI as it roams between APs, and moves the client to an AP when a better radio match is found. This prevents mobile clients from remaining associated to an APs with less than ideal RSSI, which can cause poor connectivity and reduce performance for other clients associated with that AP. |
| | : APs using the client match feature monitor the RSSI for clients that advertise a dual-band capability. If a client is currently associated to a 2.4 GHz radio and the AP detects that the client has a good RSSI from the 5 Ghz radio, the controller attempts to steer the client to the 5 Ghz radio, as long as the 5 Ghz RSSI is not significantly worse than the 2.4 GHz RSSI, and the AP retains a suitable distribution of clients on each of it's radios. |
|
|
The client match feature is enabled through the AP's ARM profile. Although default client match settings are recommended for most users, advanced client match settings can be configured using commands in the command-line interface. |
The BSS Transition Management Support feature allows Client Match to steer devices using 802.11v BSS transition management standards for continuous wireless connectivity. This feature provides a seamless standards compatible method of device steering in wireless networks, as 802.11v BSS transition management support has become increasingly common in wireless devices.
When Client Match attempts to steer the client to a more optimal AP, it sends out an 802.11v BSS transition management request to the 11v capable station and waits for a response.
| 1. | Client Match begins a timeout session for the BSS transition management response or new association request to the desired AP. |
| 2. | If the request is rejected or the timeout session expires, Client Match is notified of the failed attempt and reinitiates the steer using the 802.11v BSS transition management request. |
| | If the client steer fails the maximum number of timeout attempts (default: 5), Client Match marks the client as 11v unsupported and falls back to using deauths to steer. |
| | If the client steer fails due to request rejection, Client Match does not mark the client as 11v unsupported and continues to attempt to steer using the 802.11v BSS transition management request. |
Client Match offers a tighter integration with multiple media-aware ALGs to provide better call quality for programs like Skype for Business (Skype4b) and Facetime. With Client Match’s ability to understand various media protocols, clients are not steered to different APs in the middle of an active media session.
When a client participates in a call, the controller learns about the media session and sends this information to the AP that the client is currently associated to, as part of the variable bitrate (VBR) update. When the AP learns that the client is in a call, it will not attempt to steer the client to another AP until the controller indicates that the call has ended, allowing calls to run more smoothly without any disruptions to the ongoing media flow.
Multi-user MIMO, or MU-MIMO Steering, groups multi-user-capable (MU-capable) clients to maximize the likelihood of MIMO transmissions, which increases downstream throughput performance in 802.11ac Wave 2 (gen 2) APs. MU-MIMO runs on MU-capable clients with traffic flows and PHY channels compatible for multi-user transmissions. Client Match steers and aligns MU-MIMO-capable clients with MU-MIMO-capable radios using SNR values. Multiple MU-MIMO-capable clients can be grouped together on a MU-MIMO-capable radio.
Successful MU-MIMO transmissions depend on the following:
| | Traffic streams that can be multiplexed for MIMO transmissions. This is dependent on packet length and traffic flow rates (packet arrival rates) from APs to the devices. |
| | MU-MIMO-capable clients associated to the same radio, whose PHY channel matrices are compatible for simultaneous multi-user transmissions |
In an 802.11ac AP deployment, clients indicate VHT capabilities for probe requests and association requests, including MU-MIMO support. The APs and controllers use this information to determine whether the client is MU-MIMO-capable.
After the MU-MIMO-capable clients are located, they are steered to an appropriate MU-MIMO-capable radio. MU-MIMO Steering ensures that steers are compatible with existing trigger thresholds, such as sticky clients and load-balancing. The multi-user SNR threshold of the target radio must be greater than the sticky client SNR threshold, and radios that exceed the client threshold are avoided to prevent the need for load-balancing.
Client Match has shifted its dependency on probe requests to the AM data feed for virtual beacon report (VBR) data. Instead of relying solely on client background scans during probe requests, which can cause limitations due to low scanning frequency, Client Match uses AM data feeds to gain more continuous, comprehensive client RSSI feeds. Along with probe requests, AM data feeds collect client information during AP scanning using the following frames:
| | Block ACK |
| | Management frames |
| | NULL data frames |
| | Data frames with rates no higher than 36Mbps |
| | Control frames |