By Craig J. Mathias, Principal with the Farpoint Group
I’ve been writing this piece for two years – literally. That’s how controversial this topic is. But this hotly-debated subject is one we need to consider: Is the WLAN controller, long a fixture in many enterprise-class WLANs, still a good idea?
It’s looking much less likely that it is, although let me say up front that architecture alone, and that’s what we’re debating here, WLAN system architecture, isn’t the only variable in selecting what is almost always a vital, mission-critical element in the organizational IT arsenal. There are many, many other considerations in any given purchase (price, management features, and scalability, just to name a few), but as most of the vendors in the enterprise-class WLAN system space have chosen system architecture as a key point of differentiation, this topic is of more than passing interest.
Sadly, I need to begin by disappointing you just a little. I would love to present a definitive argument here, but let me say up front that that’s not going happen today.
It’s impossible at present to directly evaluate WLAN system architectures analytically, as building truly representative models would be, again, impossible without a very detailed knowledge of a given system’s implementation details, which the vendors would be loath to release, and which would regardless be costly to create indeed.
It is also impossible to evaluate architectures empirically via some form of benchmark testing, as real-world freespace testing on an appropriate scale is inherently difficult to do, and the variable nature of both LAN loads and especially the radio channel would once again force high costs here as well. We could also try using RF chambers, but large-scale testing of this form would also be expensive and would be accompanied by endless arguments over whether a (given or otherwise) chamber can really emulate the real world (RF channel models and such). And, of course, any analytical model would need to be verified empirically, bringing the challenge full circle and back to Square One.
Roots of the WLAN controller
Instead, let’s go to a different Square One, to the roots of the WLAN controller: the WLAN switch, introduced by Symbol Technologies, now part of Motorola Solutions, more than a decade ago. The idea was simple and brilliant: move complexity, cost, and intelligence out of the “fat” AP and into a wireless switch, make APs “thin” and cheap, and everyone goes home happy. And essentially everyone did; this strategy was, as I pointed out at the time, to become the most influential (and, really, dominant) trend in the WLAN industry for almost a decade. Many leading second-generation startups, most now successful companies (or acquisitions), adopted this approach, which directly evolved into the controller-based architectures of today. The controller is gatekeeper, enforcer, traffic cop, and not necessarily a single point of failure assuming redundant configurations, which all vendors with controllers offer.
But as 802.11n came along with a corresponding jump in throughput, and as microprocessors suitable for use in APs got so much more powerful and cheap (along with WLAN chips and chipsets are well), the WLAN controller began to look like a bottleneck and candidate for regular fork-lift upgrades (for more on this, see my interview with Wi-Fi pioneer Bob O’Hara here.)
Today’s controllers, depending upon implementation, do not always require AP traffic to flow through them (we call this a direct-forwarding architecture), as was the case with the switch, and can provide a broad range of other services, including, depending upon implementation, traffic management, global resource allocation and optimization, and more. Some vendors have even virtualized their controllers, reducing them to software running like any other application on a virtual machine. This brings up an important point – all WLANs have a control function (often called the control plane); the real question is reduced to whether this is centralized in a controller or distributed among APs, and whether this function requires dedicated hardware, or whether software alone is sufficient. The answer is becoming, I think, clear.
Many vendors who previously sold only controller-based solutions are offering distributed-control or virtualized-controller products today, and/or adaptive architectures that allow either centralized or distributed control depending upon workload or customer preference. Direct-forwarding architectures are becoming dominant; as data doesn’t need to flow through the controller, the data rate required of a controller drops, and the controller itself starts to look redundant. Note we’re not talking about old-fashioned “fat” APs here, but rather truly distributed, network-centric processing. This is as modern and contemporary as it gets.
The controller as we know it will largely disappear over the next few years
My guess is that, as we jump to 802.11ac-based gigabit-class WLANs, the controller as we know it will largely disappear over the next few years, replaced by some combination of management appliances, (virtualized) application servers, cloud-based services - or even completely controller-less architectures like Aerohive’s.
This trend is already obvious, so there’s no big prediction here. But we still have a lot of work to do in the performance-evaluation arena, as, no matter what, there will continue to be big differences in system performance among the vendors, and performance remains a key element in the success of any given installation in any given organization.
And, as we move into that era of gigabit-class wireless LANs, it will be interesting to see how the vendors continue to use architecture to differentiate their offerings. The possibilities here remain enormous.
