This is a great and very common question, and one that I hear at least every week. It's also important to understand the answer, as controller implementation serves as a primary differentiation in enterprise-class systems (the other being management features). Let's start with the big picture. The purpose of a WLAN system is of course to move data in essentially the same manner as a wired LAN. But there's a much higher degree of variability in the architecture of WLAN systems and solutions, and we therefore have developed a model, based on the concept of planes, to describe the internal functions of a given WLAN architecture. These planes are as follows:

• Data Plane – This describes how data moves within the WLAN. The biggest question is whether data from an access point (AP) can be forwarded directly to its destination, or whether this data must flow through a separate physical element, called a controller.

• Management Plane – This describes how the system is configured, monitored, and how many other required functions are implemented. The management function is almost always centralized in a single location, even for large, distributed, and multi-vendor solutions. The point of residence can also be in a controller, or a separate appliance or server.

• Control Plane – This plane can be thought of as the “operating system” of the WLAN, executing policies defined by the Management Plane and optimizing the flow of data in the Data Plane. And, you guessed it, such functionality also often resides in a controller (which can even be virtual in some products), or can be distributed across the APs. Controller functionality can also move among elements in some implementations.

We can probably agree that the Data Plane should be as distributed as possible, and that the Management Plane must be centralized. So it's the Control Plane that presents the greatest opportunity for controversy, as it can be fully distributed and implemented in an AP, reside in a server, or, again, live in a separate box, the controller. While vendor arguments are plentiful and often persuasive, there's not enough empirical (based on appropriate benchmarks) or analytical (the results of mathematical models of system behavior given specific configuration and loading) to provide a definitive argument either way. One can certainly make the argument that a controller adds cost (and that additional or redundant controllers may be required to handle certain loads and/or provide fault tolerance), but one must consider the total cost of a given solution, not the cost of individual elements. And one can make the argument that a controller-based implementation provides a more global view of system condition and behavior, and thus could yield higher performance especially over time – but, again, there are no definitive studies (yet) one way or the other. The degree of architectural diversity around this question is indeed significant, and we expect to see additional architectural variability before any definitive solution is recognized as such. Do you need a controller? Much depends upon what your supplier proposes. Careful analysis of the arguments presented by vendors during the purchasing process and appropriate benchmarking tests based on local requirements are the only guides at present.