How to deploy 802.11ac: A Salt & Pepper Guide

So the cat has been out of the bag for some time now with the majority of the Wi-Fi vendors announcing and or making first generation 802.11ac access points (APs) available for purchase.
A lot of noise has been generated around these announcements and the wireless community (and I am referencing the bona fide professional community) reacted differently in the position on the real world impact of first generation 802.11ac to already deployed networks.
In this blog, I am going to explain why a “salt and pepper” approach to deploying 802.11ac is recommended. Deploy it in areas that need the extra speed today, and simply scale your network as your speed requirements become more pervasive.
The debate
On one hand, there is a group of professionals that are arguing that first generation 802.11ac products are redundant, especially with the second-generation of 802.11ac products widely expected in late 2014. First argument being that 80 MHz channels don't provide enough room for network wide capacity, especially in high-density areas so the designer will have to revert to 40 MHz or even 20 MHz to make it work.
The second argument is that 256QAM modulation is achieved only at close proximity of 802.11ac client to the AP.
The third being that the 802.11ac end client devices are still scarce and the adoption level low. It does take two to tango, right?
The last argument is that 802.11n products still cater for the majority of needs out there.  
The other group is advocating wide adoption of the 802.11ac standard for its overall contribution to performance and for future growth protection. Even in 40 MHz channel width, the 802.11ac-to-802.11ac significantly outperforms 802.11n* stations.
Contrary to the common interpretation, it is not necessary that the peak rate performance is the motivator behind the story, but the idea is that stations communicating at high data rates will occupy the channel less. Less channel utilization leads to better overall performance on dense networks, resulting in lower latency, less jitter and overall bigger smiles on the end user faces.
Secondly, there is measurable gain in distance-to-performance ratio in comparing to 802.11n. Also the 802.11ac chipsets are never, faster, more powerful and with overall better capability for providing additional AP functionalities. 
My take on the argument … Why a “salt and pepper" approach
  1. 802.11ac products, even in the first generation, are awesome and will perform better** than last generation 802.11n products***.
  2. A properly designed and maintained 802.11n-based network is able to cater for the vast majority of needs for years to come. 
Aerohive Networks' cooperative control architecture is uniquely capable for adding additional capacity on a per-needs basis.
You need extra capacity in your boardroom? Pop an AP370 there. Got high-density areas in your campus, like auditoriums with students brining in new Macbook PROs and Macbook Airs that could benefit from added capacity (and your network benefiting from less channel utilization)? Pop a couple of AP370s there as well. 
There is rarely the need to go and replace all of your 802.11n network unless you are hitting the end of your expected product life (that is rarely in sync for the whole network anyways). So upgrading your network on a per-needs basis is only sensible.
So what is so special about how we do it?
  • You need 3 APs? Buy 3 APs. Works the same with 17, 59 or any number you want. All the pricing, licenses and support are applied linearly. 
  • No limiting factors on size, growth or network performance. The network grows numbers and performance as you add APs. There is no need to replace any equipment to support your new 802.11ac APs. There is also no fear of older equipment being the limiting factor and the bottleneck for your new AP performance. The network will only get better as you add APs. 
  • No need for consolidation of software code. Take, for example, a retailer. To simplify, imagine a retailer catering for three distinctly different environments. The backend office building, the logistics, and the retail shops. All of them differ in importance and business requirements. For example, you don't want any downtime for your logistics as even minimal downtime can result in hundreds, if not thousands, in lost revenue. You have a setup, you know the code and you keep all the APs of that particular code. Period. At the same time in the retail shops you gain advantage of a certain feature, being available in newer code. And in the offices, you run our latest code because it's awesome (including custom application signatures). You can do all that running HiveManager. And we are only scratching the surface here as far as cooperative control capabilities, but that is the topic for another blog or rather a series of blogs.
  • Our 802.11ac APs run on the latest code. You don’t have to upgrade the rest of the network for cooperative control to work in between the devices. APs, even on different codes, will exchange control traffic, so your dynamic channelization and power, statefull firewall, load-balancing, etc., will continue to work. 
  • AP370/390 802.11ac will work if connected to normal PoE PSE devices. While you will get most of the performance when connected on PoE+ PSE, you will still get considerably better performance in comparison to last generation 802.11n devices. BTW, all of our switches support PoE+ and they are extremely popular as they are configured and managed by HiveManager using one network policy (yeah, for both switches and APs. No more double-checking VLANs, user policy attributes, etc. Set and forget!). 
And guess what. When the time comes for the second generation of 802.11ac products, introducing MU-MIMO and other cool stuff, you can bet on us supporting the same salt-and-pepper style of deployment, minimizing both your CAPEX and OPEX.

* Editor's note: For the sake of argument, the author is assuming equal capable stations when comparing 802.11ac and 802.11n products. 

** Editor's note: Nothing in this world is absolute (yes, I am aware of the oxymoron I just made but bare with me). Introducing new products, chipsets, and technology is also related to new bugs (in software or hardware) and certain unexpected behavior that may affect your network. Most customers will not be affected, but if you are running a mission critical network, please make sure you test and verify full compatibility before rolling out new products on your production network. 

***Editor's note: I understand and appreciate the need for comparing vendors. You know, pointing out the “we are good and they are bad facts.” I’ve decided on tackling the problem differently by only focusing on our strengths and leaving the other part of the equation to yourselves to figure out.

Leave a Reply