In order to make a viable WLAN purchase decision, knowledge of a growing list of success requirements is crucial. No longer is the WLAN just a convenience but an absolute necessity for business success in today’s 
fast paced world.
The following will provide you with a list of architectural considerations that should be supported by a competitive Wi-Fi solution.
Architectural Consideration
Just like it is important to lay a strong foundation for your house, it is equally important to select a strong foundation (architecture) when selecting a WLAN solution and network architectural variants are often a key differentiation between vendors.
In general, many vendors have propagated solution designs that existed when WLANs were just a mere business convenience. However, considering the explosion of high-speed devices and the BYOD phenomenon,what a WLAN must intrinsically do depends more heavily on its base architecture in order to meet these demands.
The three planes
When you look at what needs to be accomplished by the WLAN architecture, there are three macro level functional categories that need to be addressed: Wireless traffic is commonly abstracted into three planes, which include:
- How to instruct the network elements in what explicit functions need to be performed. Such a function falls under a “control” category or plane.
- How to move the application data within the network. Such a function falls under the “data” category or plane.
- How to monitor the status, analytics, and dynamics of network activities. Such a function falls under a “management” category or plane.
All WLAN networks, regardless of architecture, must provide these functional elements. However, “how” these three capabilities are implemented is where the vendor uniqueness can be found.
Central Control Model
The concept of a central controller is derived from a lack of sufficient, affordable processing power to handle both control and data functions at the AP.
According to industry veteran Bob O’Hara, one of the originators of this architecture, "Centralized controllers were never the ‘right’ way to handle control traffic. They were created because that was one of the only ways to handle the problem given the balance between cost and processing."
The industry is coming to understand the inherent limitations of a centralized controller model, including:
- Cost
- Latency
- Single point of failure because of modern day realities such as BYOD and high-speed, low cost consumer devices supporting cloud connected applications.
Some vendors who have architected their system around a central control model have come up with less expensive ways of delivering controller functions which include:
Cloud-based control
One method for disguising a central controller is to put it in the cloud. In this situation, there is no need to put a controller into thedata center, or to manage a physical piece of hardware. Control packets responsible for functions such as roaming, session state across APs and subnets, etc., are sent to and from the cloud via an Internet connection.
Regardless of where the controller is located, however, it is important to realize that it is still there, and that any disturbance in getting traffic to the device will affect overall WLAN traffic and network capability.
Central control and distributed traffic forwarding
In a distributed forwarding model, local traffic (i.e., traffic originated and destined for a local resource) is forwarded between APs and not back to the controller. The important thing to remember, however, is that the fundamental architecture – that is, the centralized controller running control plane functions is unchanged in this model.
Traffic that is forwarded between APs is therefore not subject to features that are only garnered via a trip through the controller. Some examples of features not employed in a distributed traffic forwarding model could include policy enforcement, authentication, deep packet inspection, or Quality of Service.
Distributed Control and Forwarding Model
Still another type of architecture takes advantage of the exponential increase in processing speed/power and the attendant decrease in cost to put both the data plane and control plane functions on the AP, removing the central controller altogether.
The resulting architecture looks more like the Internet, with no central point of failure and a completely distributed control plane coordinating the communication and exchanging state with advanced protocols. If a problem occurs, the APs in this model are able to dynamically route around it maintaining full state and operation.
This makes the architecture extremely resilient and flexible, while at the same time making it more affordable because there is no additional equipment beyond the APs. Because a WLAN with distributed control and intelligence functions more like a grid computer, it can also act on an extremely high volume of control and policy decisions made at the edge of the network without having to forward everything to be processed by a separate device. This increases overall network performance and enables true QoS.
Architectural Conclusions
This quick examination of Wi-Fi network architectures highlights several considerations. First, the data plane must be distributed. Considering the explosion of high-speed devices and the BYOD phenomenon, this is a given in any network.
The second is that management must be centralized to enable easy, consistent views of network operations for more efficient problem resolution and minimal interruption of service; central 
management is largely also considered a given. The fact that management is centralized, however, does not necessarily imply that it must be located on premise, in a piece of hardware.
Because management traffic is out-of-band, a management device can easily be located in the cloud and still be completely effective.
The majority of differences between Wi-Fi architectures today concern the control plane. Legacy models feature a central controller, housed in hardware. Newer models have put this central controller into the cloud; it's important to realize, however, that unlike management traffic, control plane information must be constant and uninterrupted as it has direct functional impact on the WLAN.
Therefore, while a cloud-based controller could lower overall costs, it can still be a liability to resilience and performance. Some legacy controller vendors have implemented distributed forwarding, in which traffic is passed directly from AP to AP, without the benefit of control plane information. While this model may work in some situations, it falls short in many others where security and QoS features (among others) are essential and require higher level, compute-intensive functions that are performed by a central controller.
Finally, some vendors have taken advantage of low-cost processing power to pass control plane information from AP to AP. This approach enables higher speed clients to be supported, distributes processing for increased capacity, future-proofs the network, and provides full functionality without any single point of failure.
~~~
Other blogs in this series:
WLAN Buyer's Guide Part 2: Architectural Considerations
Next up:10 Things A WLAN Must Do
~~~~
Richard Watson has worked as a senior product marketing manager and product manager with 18+ years’ experience in the Wi-Fi market. He has worked for major networking and wireless companies including Meru, 3Com, Motorola, and Symbol Technologies where he contributed to development and release of numerous wireless solutions. He authored a book on FMC, has contributed to trade journals writing on leading edge topics on wireless VoIP and participated on panels at industry shows.