If you have ever sat one of my training classes, you'll know that the most important aspect I stress when doing wireless designs is to ensure client device compatibility. I always make a point to mention that desktop support should always be engaged during new deployments as well as upgrades, especially when going from older technology to newer technology. Why is this? Well clients hold the key to success with your deployments. You can build the best possible network ensuring proper coverage and SNR throughout your facility but if you have a sticky client or a client that can't understand the more complex beacon elements it doesn't matter. Chances are that device is in the hand of the most important user(s) as well. So how do we help those clients that are struggling to operate on our newly deployed networks? Especially if they are only sticky and not roaming. Well thankfully (maybe?) we have a set of tools that allows us to do that, these tools are called ClientMatch.
First let's take a look at the capabilities that make up ClientMatch, yes ClientMatch is a group of capabilities, not necessarily a specific feature. The first capability of ClientMatch is Band steering. Band steering is the ability to persuade the client to connect to 5GHz when it is detected as a dual band client connecting on 2.4GHz. This sounds like a great way of handling the frequency balancing instead of using two SSIDs: 1 for 2.4GHz and 1 for 5GHz. When a client that is capable of operating at 5GHz tries to connect to a 2.4GHz radio the network will delay its response to the 2.4GHz probe hopefully allowing the 5GHz response to be heard.
The second capability of ClientMatch is Client steering. First we tried to persuade a client to connect to 5GHz instead of 2.4GHz now we are going to try to persuade it to connect to a different AP than the one it chose to connect to. Behind the scenes the Aruba infrastructure maintains a database of how a client sees multiple APs and uses this to decide whether or not it should continue talking to a client or not. We currently have a standard that is being worked on, 802.11k, that is supposed to do this but we don't have that ability yet. This is where client steering comes into play. This doesn't need the clients to support 802.11k in order for it to work. Because the infrastructure is maintaining the information stores the clients don't need to support anything. Check out the patent information here: https://www.google.com/patents/US20130036188.
When you put these capabilities together what you end up with essentially is dynamic load balancing. The ability to make it so that 1 AP is not servicing 100 clients while the next closest AP is only servicing 20 for example. This seems like a great solution and you should enable all these features but what you need to remember when doing so is that these are features that don't fix bad designs. You need to already have a strong design in place that can support your high density of APs and clients. What we are trying to do here is not fix a bad design, we are trying to fix clients inabilities to choose wisely when given the choice of APs to connect to. At the end of the day though remember that the client is responsible for making the decision of what AP to connect to. If we decide to persuade it we need to be assured we are not impacting things like VoIP and other real time services. One should be reviewing the ClientMatch reports in AirWave to determine if you have an abnormal number of events occurring pointing to design issues. Until 802.11k is fully supported by all clients and infrastructure devices there isn't a reason why ClientMatch capabilities shouldn't be enabled on your network. But like anything out there a thorough review of all the data and reports should be done to ensure performance isn't negatively impacted.
Are you using ClientMatch capabilities on your network? What kind of experience have you seen with your older devices that typically make bad life choices?
