Copyright ©2014, Aerohive Networks, Inc. 1
2014
WLAN Buyer’s Guide
The definitive guide for evaluating enterprise WLAN networks

Copyright ©2014, Aerohive Networks, Inc. 2
Introduction
Only ten years ago, the idea of Wi-Fi as the primary access technology was little more than a vision. The WLANs
of that period were designed primarily as convenience networks and were not well-suited for the operation of
mission-critical applications and access. Over time, WLANs became increasingly pervasive and architectures
evolved to better manage and contain WLAN traffic. For these convenience networks a model of centralized
control and distinct points of presence via WLAN controllers eased the task of managing the increasing number of
access points without overwhelming IT resources. This model was adequate for 802.11a/b/g deployments that
really didn’t provide the robust network bandwidth and reliability to be a viable Ethernet replacement. The
relatively low throughput of 802.11a/b/g networks also served to keep the centralized controller from being
overwhelmed. The resulting centralized control model proved an effective way of “sandboxing” the wireless traffic
and preventing it from disturbing traffic on the “main,” wired network.
With the advent of the 802.11n standard the wireless LAN has became firmly planted as a viable alternative for
Ethernet, even in the case of mission-critical applications. 802.11n introduced high throughput, enhanced
methods to overcome interference, and the level of reliability needed to make Wi-Fi into a foundation-layer
infrastructure technology. WLANs had become required everywhere in organizations. The pervasive nature of
802.11n, however, caused the centralized “point-of-presence” controller model to break down for several reasons.
One issue is the cost of deploying a centralized control over a distributed network. Other problems include the
limitations on bandwidth that the controller introduced, as it creates a bottleneck from both a device and WAN
backhaul perspective.
With today’s iEverything Enterprise, dominated by BYOD and the consumerization of IT, the barrier posed by
centralized architectures that were intended to manage and secure WLANs of convenience is becoming
increasingly intolerable. These trends provide compelling CapEx savings, but pose a challenge to a Wi-Fi
network. Interestingly, as the endpoint devices become less sophisticated from a network intelligence standpoint,
the onus of performing sophisticated services and security functions shifts to the network infrastructure. In other
words, as devices get less intelligent about network services, the infrastructure must become more intelligent and
automated to ensure that the simpler devices don’t become an administrative nightmare.
- 2014 is the year of Gigabit Wi-Fi -
The 802.11ac standard has arrived, promising throughput of up to 1Gb per device. No longer can it be assumed
that a centralized control model with distinct points-of-presence is suitable for WLANs running at high speed. If
every client operates at up to 1Gbps, there is a high risk of significant bottlenecks that can impact any part of the
network. The presence of a central control device, be it software or hardware based, in this scenario would be
akin to introducing a traffic light into an eight-lane highway – all productivity would be dependent on the single
device’s capacity to process data. When there are dozens of devices per access point running hundreds of
megabits per second each across a dozens of access points, that capacity is reached very quickly.

Copyright ©2014, Aerohive Networks, Inc. 3
Table Of Contents
Things To Consider ................................................................................................................. 4
Key Requirements.................................................................................................................. 6
Architectural Conclusions..................................................................................................... 9
10 Things A WLAN Must Do ................................................................................................. 11
Using The RFP Process To Select A WLAN......................................................................... 17

Copyright ©2014, Aerohive Networks, Inc. 4
Things To Consider
The evaluation of a Wi-Fi network requires that enterprises carefully consider the changes happening in the user
population. While consumerization of IT and BYOD may be an overused term in networking today, it is
unquestionably a driving factor in the Wi-Fi world. These phenomena drive the enterprise to deploy a wireless
infrastructure, since many consumer devices don’t even have an Ethernet port. Additionally, three converging
trends – cloud, mobility, and virtualization –allow business-critical work to be done just about anywhere on any
device. That is a fundamental change that impacts IT first and foremost.
- Work has become a thing you do, not a place you go -
Architecturally, as the shift to wireless as a foundation-layer technology is made, one must consider future trends
and their impact to the network. 802.11ac, capable today of speeds of up to 1.3Gbps, has a potential within a
short timeframe to reach 3.5Gbps data rates. We will soon see mass adoption of the new standard within the
next 2-3 years and therefore we must recognize and prepare for the changing traffic patterns on a network. As
wired Ethernet progressed from 10Mbps to 100Mbps to 1Gbps to 10Gbps, the leaps in traffic were predictable
and generally easy to calculate as endpoints were relatively static and the traffic increase was simply a factor of
10. Mobility with high data rates changes this on two vectors.
First is the sheer volume of data, which becomes an exponential. By upgrading a single access point to support
the higher 802.11ac data rates you must now consider all the “upstream” links to this traffic. Where the data is
forwarded to and from becomes critical. You cannot have point-to-point data forwarded to a central control point; it
absolutely must be locally forwarded, and policy must be enforced locally as well. Switching infrastructure can be
upgraded to support dozens of potentially multi-gigabit AP links, but the bottleneck imposed by a central controller
would be untenable. Therefore the intelligence, policy enforcement, and network services need to be locally
enforced, not centrally.
Second is the fact that these high-speed clients are, in fact, mobile. This makes load balancing across the
infrastructure paramount. If you architect a network to forward data to a central control point, as it is in the
controller-based model, there is no way to balance multiple Gbps of data across the controllers. The architecture’s
inherent limitations will leave you with little choice but to re-architect the network and invest large amounts of time
and money. The fact is that even though 802.11ac is in the future, it must be architected for today in order to
handle both mobility and high bandwidth clients.
With BYOD a primary factor in networks deployed today there are many important considerations that should be
reviewed. These considerations can generally be categorized and analyzed in two distinct parts:
Onboarding of devices: this encompasses how devices are brought on to the network and how policy is applied.
This includes authentication, device type identification, enterprise access policy and the application of context,
such as device-type, user ID and location of the policy that is applied to that particular device.

Copyright ©2014, Aerohive Networks, Inc. 5
Providing service to the device once it’s onboard: this includes how the devices, which are neither owned
nor managed by the IT department, access corporate network services like file sharing, printing, video
conferencing, etc.
BYOD is about more than “onboarding” mobile devices. It must include a means to make them useful and
productive members of the corporate community. Once safely and securely on the network, you must consider
how to enable added value.
As with any IT investment there is the consideration of WLAN cost predictability. IT must be able to compare
“apples-to-apples” when generating comparisons between wireless vendors, and it is important to understand
how much comparisons vary depending on feature set. In many cases, this means that IT should review not only
the cost of the hardware, but the cost of any licenses that are needed to make the WLAN perform as specified.
Cost considerations should also include “soft” costs, such as the cost of operating the solution. Most enterprises
do not have a Wi-Fi expert on staff; in many branches, there is not even an in-house IT staff. WLAN management
should mirror security and access policies in use on the wired network, and should provide for easy, seamless
upgrades; all without requiring RF expertise.
Another important element of cost is scalability. Few people could have foreseen the iEverything explosion when
considering their initial Wi-Fi network. Any Wi-Fi network under consideration today should take into account the
fact that the deployment will be required to scale to accommodate more devices, more users, more heavy
applications, and, of course, newer, faster WLAN technology. It is clearly untenable to put in a Wi-Fi solution that
is “maxed out” at 802.11ac.

Copyright ©2014, Aerohive Networks, Inc. 6
Key Requirements
There are a number of requirements that must be closely examined when considering a WLAN purchase. As
Wi-Fi moves to the primary access method, consumerization of IT and BYOD drive the demand for reliable, high-
performance access, and contextual policies become the norm, it is not sufficient to consider a WLAN vendor that
is doing “business as usual” Wireless gear that was included at low or no cost as part of a larger networking
equipment buy was understandable when the WLAN was a convenience-only addition to the wired network. No
enterprise, however, will find this reasoning acceptable as Wi-Fi becomes the primary means of accessing
corporate resources, and the carrier of mission-critical applications.
Architectural Considerations
The fundamental architecture of wired networks has probably not been considered by most IT professionals since
the advent of Fast Ethernet. While there have certainly been advances in how to get the most out of the wired
network, the underlying technology is very well understood. This is not the case in wireless networking, where
many of today’s leading vendors base their implementations upon the usage expectations of legacy convenience
networks that were prevalent a decade ago. While Wi-Fi technology has advanced exponentially since 2001, it is
important to consider whether WLAN vendors have actually changed their architecture to be more seamlessly
integrated into well-known network architectures (core, distribution, access) and their traffic flows, or if they have
an expectation that the network architecture will change to accommodate their WLAN solution.
Three Planes
Any consideration of WLAN technology necessarily begins with a brief discussion of the architectures derived
from the traffic components themselves, since it is from them that the Wi-Fi network is built. Wireless traffic is
commonly abstracted into three planes, which include:
The Control Plane
The need to handle control plane traffic was the basis upon which many WLAN vendors built their
underlying architecture over the last decade. In general, control plane traffic is anything that is needed to
get wireless functioning in a coordinated, multi-AP network; it can be considered the “signaling” of the
network. Control plane packets are destined for, or originated by, the WLAN equipment itself.
Vendors introduced the concept of a centralized control devices, or controllers, to handle control plane
traffic in 2001. It is important to note that this architecture was not necessarily based on the fact that a
centralized model was the optimal method to handle all traffic including control packets; rather, it was the
most effective way to enable processing in a wireless network while still keeping it affordable given the
technology of the time. Ten years of processor development have led to processors that are far more
powerful while at the same time exponentially less expensive, so it is now possible to enable control
plane processing in a distributed model. Interestingly, many vendors continue to advocate a central
controller architecture in one form or the other. This is primarily a legacy issue, as it would require a
complete system redesign for these vendors to move to a distributed control model (see below). Other

Copyright ©2014, Aerohive Networks, Inc. 7
vendors have designed their systems from the ground up for pervasive, high-speed Wi-Fi and have found
ways to use advanced processing capabilities to create a new, completely distributed architecture that
closely resembles the control plane common among routing architectures. In this model, control
information, including link and user state, is passed from AP to AP, without the need for a central control
point in any form.
The Data Plane
The data plane, sometimes referred to as the data forwarding plane, is basically the traffic that goes
through a WLAN device but not to those devices. The data plane is generally distributed, however in a
central control architecture many policy decisions are handled by the central control device; therefore the
data plane is often required to go through the controller in order to have policy enforced, including
application visibility and control (AVC), QoS, deep packet inspection, flow classification, etc.
The Management Plane
Management plane traffic carries the operations and administration traffic required for network
management. It is most effective to centralize management to enable easy, consistent policy application.
Management plane traffic has no functional impact on real-time operation of the network.
These elements of WLAN traffic have spawned several different architectures, including:
• Central controller
• Central controller with distributed forwarding
• Distributed control and forwarding
Figure 1 - Legacy Centralized and Modern Distributed Intelligence WLAN Architectures

Copyright ©2014, Aerohive Networks, Inc. 8
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
power in 2001.”
The industry is coming to understand the inherent limitations of a centralized controller model, including cost,
latency, and 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 the data 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.

Copyright ©2014, Aerohive Networks, Inc. 9
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.
“By 2015, 80 percent of newly installed wireless networks will be obsolete because of poor
planning - Gartner”
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 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.

Copyright ©2014, Aerohive Networks, Inc. 10
1 - http://forwardthinking.pcmag.com/none/289313-gartner-why-enterprise-wireless-is-not-ready-for-the-mobile-explosion

Copyright ©2014, Aerohive Networks, Inc. 11
10 Things A WLAN Must Do
The combination of the iEverything explosion with the speed and reliability of 802.11ac has created a compelling
case for Wi-Fi as the primary access layer. Unfortunately for the WLAN buyer, there is no longer a single
architectural model from which to choose, and legacy vendors may obscure underlying issues as they seek to
retain their revenue base. In order to make the right decision for your network, you should consider the following
areas to ensure that the WLAN you choose will satisfy immediate requirements while enabling you to be prepared
for the future:
• Integrating BYOD and company-owned consumer devices has become a vital part of every network,
from corporate office to primary school campus. Securing these devices as they come on to the network
and making them productive tools as part of the network are the keys to taming the iEverything explosion.
• Deployment, installation and maintenance, which includes the initial setup and deployment, as well as
the day-to-day issues of management, both in the corporate office as well as in branches.
• Cost, which includes the price of the hardware, operating expenses and feature licenses.
• Security, which is vital for a primary access method running mission critical applications. Security must
be ensured for all user, device and application types, in all locations.
• Performance, which must be optimal for a variety of clients, users, application types and protocols –
including heavy applications like voice/video and virtualized or cloud-based apps.
• Scalability, which is a key requirement as client loads increase, new sites are opened and new
applications are developed.
Management and Deployment of BYOD and Company-owned Consumer Devices
Your WLAN must be able to enforce corporate policy based on user identity and fingerprint of their device
• Business case: Although consumer-level devices used to be thought of as exactly that – consumer
level – public and private cloud computing as well as technologies like desktop virtualization have
enabled these devices to become productivity tools for corporate operations. Onboarding these to the
network needs to be as straightforward as a login from any corporate laptop, and policy enforcement
needs to be automatic so as to ease any operational headaches or unnecessary support calls to the
helpdesk. Additionally, if a guest device or a device of a non-employee is allowed on the network it is
important that their communication be secured. Examples include students in a school that require
privacy, or a contractor in an enterprise that, while not an employee, still deals with sensitive, company
confidential information.

Copyright ©2014, Aerohive Networks, Inc. 12
• Requirement: The optimal WLAN will have the inherent capability to tie to corporate LDAP services and
automatically fingerprint the device coming on the network. Security and quality of service (QoS) policies
should be established based on the users’ context (identity, device type, location, and application) and
not solely on the type of connection (wired, wireless, SSID, etc.). Further, dynamic, configurable pre-
shared keys that are unique to each guest and can be configured to expire should protect guest
connections. These features together will provide context-aware policy enforcement and safely onboard
devices to the network. Determine the services required for your BYOD environment, as you may want to
extend guest management capabilities even further.
Your WLAN should provide service to BYOD devices once onboarded
• Business case: Once a BYOD device is onboard your network, the key question is what the user
community will do with that device. Having the ability to surf the Internet and retrieve email provides little
return on investment (ROI) for your BYOD initiative. In order to provide true ROI for BYOD you need to
make these devices into productive corporate tools. At a minimum, employees should be able to print and
project presentations, share files and use collaboration software. Without these basic capabilities the
investment in a BYOD initiative boils down to giving an iPad user access to the Internet or other cloud
services for quick reference, but does not alleviate the responsibility of giving an employee the tools
needed to replace the corporate laptop with a personally owned tablet; hence, it doesn’t allow you to
benefit from the CapEx savings promised by BYOD. One problem to avoid is the need to configure every
device, because this will immediately erode all BYOD benefits via costly helpdesk calls.
• Requirement: The optimal WLAN should be “service-aware”; that is, it should have an understanding of
network services available to BYOD devices and provide a means of making those services usable by
BYOD devices without “hands-on” configuration. The vast majority of employee-owned devices that are
intended to be used on the company or school networks are based on Apple iOS. Therefore creating a
way to enable Apple’s “Zero-Configuration Networking,” or Bonjour, available corporate-wide in an
efficient, predictable manner is critical to a successful WLAN deployment.
Deployment, Installation and Maintenance
Your WLAN should have a single consistent architecture that scales in both capital and operational costs
• Business case: As discussed above, different WLAN approaches have different implications on how
data forwarding and control traffic are handled. The impact of how the architecture is implemented can
very quickly increase the cost of deployment and maintenance. Some vendors offer as many as three
different architectures – large controller, virtual controller, and small APs – that simply bridge traffic
blindly. The problem is the cost of implementation and maintenance varies based on the size and
geographic location of each site. Which do I use where? Controller? Virtual Controller? How large a
controller to buy? If each site has a different architecture, what will licenses cost at each site? When the
IT admins troubleshoot a problem at a site all the same questions must be asked every time, because
each architecture will require a different methodology for problem isolation and resolution based on the
network deployed.
• Requirements: The optimal WLAN will use a single network architecture regardless of size and still
provide reasonable costs. Whether the deployment features a single AP at a small site, 10 APs at a

Copyright ©2014, Aerohive Networks, Inc. 13
medium site, or 1000 APs at a large site, the basic underlying architecture should be the same. This
allows the advantages and ROI of repeatability of network deployment and maintenance.
Your WLAN must be easy for IT to manage, maintain and upgrade
• Business case: In networking, change is the only thing that stays the same. As new deployments come
on line, new security or access policies are developed and new applications become available, it must be
easy to enable the Wi-Fi network to keep pace. This quality is essential as WLAN moves to the primary
access method. To ensure consistency, WLAN management should be a centralized function, and ideally
should operate identically whether housed in the cloud or on the premises.
• Requirements: The optimal WLAN should be easy to manage, maintain and upgrade. This is true not
only in the corporate headquarters, but in remote or branch offices as well, to ensure consistent security
and policy. Management actions and commands should be written in language that is easy for a non-RF
expert to understand.
Your WLAN must facilitate easy troubleshooting
• Business case: Particularly in the era of BYOD, it is vital that the WLAN be easy to troubleshoot. In
many cases, consumer mobile devices are optimized for battery life, not for radio transmission – but the
end user will not be aware of that. All they will see is that the wireless network isn’t working! It is important
to be able to visualize the problem without RF expertise and to quickly track down the primary issue.
• Requirements: The optimal WLAN will be one in which it is easy to see the cause of a problem without
having to troll through heaps of incomprehensible, RF-centric logs. AP and user performance should be
easy to find quickly and should enable the speedy pinpointing of the issue, which may not be related to
the wireless network at all. It is important that the WLAN provide a means to view a problem all the way
down to client-level statistics for faster, more accurate problem isolation even at remote locations.
Cost
Your WLAN must feature predictable capital expenditure
• Business case: When considering capital expenditures, it is tempting to look at only the cost of the
access points, but this is not the whole story. If a central controller is part of your considerations, examine
what it will cost to enable your current deployment. Then consider how the same equipment will fare if
you double your user count, increase your traffic load or move to more space. Is a larger controller
required? If so, is it still cost effective? Also consider the number of sites your organization has. If
considering a controller-based WLAN, does each site need a controller? If so, what size and what if that
site grows or moves? What about redundancy? Don’t forget to double your controller count. Another
consideration is that of feature licenses. Often the base hardware solution does not actually enable the
firewall, security, QoS or policy features that you actually need.
• Requirements: Ask for a full list of equipment and licenses required to handle your Wi-Fi networking
needs today. Then double the deployment and see what hardware and licenses would need to be added.
If there is a controller and there is a point at which the controller you are looking at will need to be
amended, find out what that point is.

Copyright ©2014, Aerohive Networks, Inc. 14
Your WLAN must minimalize operating expense
• Business case: As most networking professionals know, the highest cost element in most deployments
isn’t the capital expenditures; it’s what is required to keep the network running. Consider these factors:
- What is the management interface like?
- What are the steps required to specify a deployment?
- What are the steps required to deploy the solution?
- How easy is it to visualize a user problem?
- What would I need to do in order to expand this WLAN to more floors/offices if I purchased it?
- Can I deploy the same architecture in my branch office? If not, why not?
- What is the company’s history in WLAN upgrades and advances? Have they ever introduced
upgrades that are not fully backward compatible?
• Requirements: The ideal WLAN must have a low operating expense. This includes both how easy it is to
get a full list of equipment required; the requirements for a deployment both in corporate offices and in
branch office; the ease of maintenance and upgrades; and the ability to troubleshoot the system both in
branch offices and headquarters without the need for RF engineers to be dispatched to every location. It
is important to understand how this is achieved.
Security
Your WLAN must feature enterprise class security
• Business case: The iEverything explosion has enabled incredible business productivity, but it has also
created a myriad of new openings for network security threats. In order to be truly enterprise-class, your
WLAN must have comparable security to that found in your wired network. Advanced security is
considered a feature by some vendors and licensing for it comes at a cost; you must ensure that these
features are included in your initial estimate, along with any costs for upgrades and expansion.
• Requirements: The ideal solution must enforce advanced security features, and these features must be
included in the initial cost overview.
- Wireless Privacy and Key Management – using keys to encrypt and secure traffic transmitted
across the air.
- Authentication – identifying users as they come on the network. This means authenticating
employees as well as guests and contractors. Also determining whether RADIUS, Active
Directory or LDAP is used for authentication. Your WLAN solution must ensure consistent
security at all times.

Copyright ©2014, Aerohive Networks, Inc. 15
- Identity Based Access Control – using the identity of a client to provide access to the correct
VLAN, and allow or deny access to specific applications or resources.
- Device Physical Security and Data Storage – ensuring the networking platform itself is securely
implemented so that it cannot be compromised – even if stolen.
- Application Visibility and Control – having complete layer 7 awareness at the edge of the network
ensures that mobile devices utilize productive applications only
• Business case: No one knows where the next network threat could come from, or when it will hit. Your
WLAN must therefore have security enabled at all times, and for all traffic types security must remain
consistent and in place even if the WAN is down. It should not be sacrificed for the appearance of a
lower cost.
• Requirements: Ensure that any solution under consideration provides consistent security at all times. If
the vendor is pitching distributed or local forwarding, make sure that you understand what security
features, if any, are omitted when traffic bypasses the controller. If a branch or cloud-based controller
solution is dependent upon the WAN for security applications, be sure to fully consider what features will
fail if the WAN does.
High Performance
Your WLAN must provide high performance throughput
• Business case: The WLAN is now being considered as a primary access method largely because of the
throughput provided by 802.11ac. The consumerization of IT means that users are intolerant of latency,
even when it may be a factor of a lower powered battery in their mobile device. Users are also becoming
more and more dependent upon high bandwidth applications, like voice or video, and low throughput or
high latency solutions are simply not up to the task of handling these “heavy” applications.
• Requirements: The WLAN solution must be able to ensure Quality of Service for VoIP, video or other
heavy application traffic, restrict unwanted applications such as torrents, and handle legacy clients as well
as 802.11ac clients. Many vendors will charge for the licenses you need, so be sure that they are
included in any solution that is considered.
Scalability
Your WLAN must grow with your organization without barriers
• Business case: When WLANs were considered a convenience network, scalability was not a large factor
in choosing the right equipment. As Wi-Fi moves into the primary access method, however, the WLAN
must scale. Consideration of scalability applies both to increasing the coverage of a deployment and
increasing the load on that deployment. You should also look at what is necessary to deploy remote or
branch locations. If this requires the deployment of a new controller, or makes the branch subject to
variability in the WAN connection, it may not be the best solution for you. It is also important to consider
feature licenses as part of the cost and complexity; as a solution scales it could complicate operations
significantly.

Copyright ©2014, Aerohive Networks, Inc. 16
• Requirements: The WLAN should scale predictably, including hardware and software. New deployments
should offer consistent features. You should also examine what is required to scale a deployment up in
terms of operating expenses.

Copyright ©2014, Aerohive Networks, Inc. 17
Using The RFP Process
To Select A WLAN
Most companies will use the RFP as a way to narrow the list of possible WLAN vendors to consider. In the last
section we overviewed 10 things a WLAN must do. In this section, we’ll show how to use those requirements as
part of an RFP process. The majority of these considerations should be included under the Scope of Work
section, in which the RFP requests a detailed list of the business and technical requirements. This section will
give you a starting point for your WLAN RFP and initial “things to think about” while building your RFP.
Overview of Proposed Solution – Architecture
This is a good place to ask the vendor to outline the architectural model that they are proposing. This is also an
appropriate section to request a complete parts list for the solution under discussion.
• Look for controllers – This gear may be on premise hardware, cloud-based, or can even be located in
a corporate office deployment if the proposal is for branch networks. If a controller is listed, pay close
attention to how the vendor answers these later questions:
- Scalability – Does the use of a controller also bring with it a “stair step” cost model? If the
deployment expands, at what point would you need to add another controller?
- WAN Outage – If the vendor uses a cloud-based controller, or relies on a corporate controller to
power branch WLANs, ask what features are disabled in the case of a WAN outage. Do end
users need to reauthenticate in such an instance?
• Look for feature licenses – Some vendors’ base systems are virtually useless without features that are
enabled via license. If licenses exist, they may be included at no charge with the base system. In such
cases, be sure to ask how the cost changes if the deployment grows.
Technical Specifications
Capacity and Scalability
In this section, look for the number of access points specified for each site under consideration. They should also
call out the client capacities of each AP/deployment. You may request that the deployment be specified for
headquarters and branch locations. You can also look for:
• Wi-Fi Planning Tool – some vendors will provide a Wi-Fi planning tool, either at no charge or as part of
purchase. This tool will enable you to see the reasoning behind the gear that the vendor is specifying, and
how that can change if your requirements change.

Copyright ©2014, Aerohive Networks, Inc. 18
• Feature Licenses – In many cases, functionality is enabled via license. Are these licenses included with
the gear? What if a site is added?
Outage Management
This section should describe how the system functions in the case of an outage, whether of the outage involves a
piece of the WLAN gear or the WAN, and could include:
• WLAN Controller Outage – What happens if a WLAN controller fails? If a system is billed as resilient,
look to see if this claim is supported by a backup controller.
• Access Point Outage – What happens if an access point fails? Is traffic dropped? Are there any “self-
healing” capabilities in the system?
• WAN Outage – This area is significant if the WLAN architecture is dependent upon a cloud-based
controller, or if a branch deployment relies on a controller in HQ. Does the WLAN continue to pass traffic
in the case of a WAN outage? If yes, what features are disabled? Consider how important these features
are to your business and whether you are comfortable without them. What happens when the WAN
connection is restored? Are sessions maintained? Do users need to reauthenticate?
Protocol Support and Radio Frequency (RF) Management
This section should call out which protocols are supported as well as what elements of RF management are
supported by the system. Additional areas to consider include:
• Wireless standard support – Any WLAN under consideration should support 802.11ac/n/a/b/g.
Additional questions include:
- System functionality in a mixed client environment – This is a very important consideration
for several reasons. 802.11ac clients can “drown out” n/a/b/g clients in some situations.
Conversely, an .11a/b/g/n client can also functionally dominate the air because of the greater time
required to pass traffic in comparison to .11ac clients. In either situation, there will be a
percentage of users that are unhappy, so how they are handled should be examined.
• Client Band Steering – Any WLAN under consideration, particularly those with BYOD initiatives, should
be able to dynamically balance clients to their ideal frequency band.
- Frequency band steering in the unlicensed spectrum – Moving user traffic to the 5 GHz radio
band (802.11ac and 802.11na) is a long-standing technique to increase total throughput on an
802.11 network. Total area throughput is limited by the number of channels that can be
saturated, so the greater the number of non-overlapping channels available, the greater the
possible throughput. Furthermore, the noise floor on 5 GHz channels is often lower due to the
smaller number of unlicensed devices.
Power Management

Copyright ©2014, Aerohive Networks, Inc. 19
This section should describe the features and controls required for power management of the WLAN access
points. Specific details here may include access points that are capable of operating at both Power over Ethernet
(PoE) modes, 802.3af (low) and 802.3at (high).
Quality of Service (QoS)
This section should describe overall enterprise QoS requirements for business applications (e.g. Voice over
WLAN, video conferencing, etc.).
Security
This section should describe how the WLAN provides security, as well as how it will interact with existing network
security specifications. Be sure that responses address any regulatory compliance requirements, including
HIPAA, PCI-DSS and more. Details could include firewalling, Application Visibility and Control (AVC), Wireless
Intrusion Detection (WIDS), network access control, security event management, authentication methodology,
identity-based access controls, and rogue AP detection. Additional considerations include:
• Security features enabled via license – Are any of the security capabilities described by the vendor
enabled via licenses? If yes, what are the costs? If the license cost is included with the base system, how
is it enabled if the deployment expands?
BYOD support
BYOD support is a relatively new requirement, but must be considered for any new Wi-Fi network under
consideration. Specific elements to look at include:
• How is a BYOD device onboarded onto the network?
• Does the system enable a means to ensure policy consistency across user-owned devices?
• How do BYOD participants print, share files, or use projectors?
Deployment and Configuration
In this section, the vendor should specify the steps required to deploy the WLAN. This should include any
preplanning capabilities. In addition to consideration of how to deploy the WLAN at Corporate or HQ, it is vital to
consider:
• LDAP Integration – Does the system integrate consistently with corporate identity services? If so, how?
• Branch deployment – how does the solution scale? How are branches connected to HQ?
• Technical expertise – What level of technical expertise is required to set up the WLAN, particularly in
branch locations? What does the person installing the system need to know about networking in general
and about RF in particular? If there are problems, how easy is the deployment to troubleshoot?
Systems Management

Copyright ©2014, Aerohive Networks, Inc. 20
It is crucial to thoroughly understand the systems management capabilities of any WLAN being considered, since
this will be the largest ongoing expense of the overall deployment. The vendor should list and clearly describe
every element of the central management system required. Additional considerations include:
• Web interface – Can the management UI be accessed via the Web?
• Management capabilities via license – In some situations, vendors will integrate basic management
functionality but charge for additional capabilities. Make sure you know what is available as part of the
system and what will cost more. Also consider what additional licenses, if any, are required when scaling
the WLAN or extending it to branch locations.
• Management device flexibility – If management is handled via a centralized device, is an additional
device required for branch locations? Is there a cloud offering for management?
• RF expertise required – Consider what level of RF expertise is required to work with the management
interface. Could someone with a general understanding of networking operate the system?
Quality of Service/Service Level Agreement
As WLAN becomes the primary access layer, it must support rich applications, many of which have strong QoS
requirements. To what degree does the management interface support the separation and prioritization of this
traffic? Is it possible to enable an enforceable SLA with this system? If yes, how does the process function? Is it
automatic, or does it require end user intervention?
Troubleshooting
WLAN is subject to a variety of issues that are unique to RF. For the WLAN to be useful, it must be easy to
pinpoint problems as they come up, sometimes by user. Consider:
• Per-user throughput/issues – Does the management interface allow you to see throughput and
performance by user? If there is a problem, how easy is it to see the nature of the issue; that is, can you
quickly and easily determine if the problem is the network overall, the application itself, or the WLAN?
How easy is it to make prioritization changes?
• RF expertise required – While RF faces unique challenges, it is very unlikely that each office/branch will
have an RF expert onsite. What level of RF expertise is required to understand issues? To what degree
would an administrator need to sort through RF-based logs to understand a reported problem?

Copyright ©2014, Aerohive Networks, Inc. 21
About Aerohive
Aerohive Networks reduces the cost and complexity of today’s networks with cloud-enabled,
distributed Wi-Fi and routing solutions for enterprises and medium sized companies including
branch offices and teleworkers. Aerohive’s award-winning cooperative control Wi-Fi
architecture, public or private cloud-enabled network management, routing and VPN solutions
eliminate costly controllers and single points of failure. This gives its customers mission critical
reliability with granular security and policy enforcement and the ability to start small and expand
without limitations. Aerohive was founded in 2006 and is headquartered in Sunnyvale, Calif. The
company’s investors include Kleiner Perkins Caufield & Byers, Lightspeed Venture Partners,
Northern Light Venture Capital and New Enterprise Associates, Inc. (NEA).
Corporate Headquarters
Aerohive Networks, Inc.
330 Gibraltar Drive
Sunnyvale, California 94089 USA
Phone: 408.510.6100
Toll Free: 1.866.918.9918
Fax: 408.510.6199
info@aerohive.com
www.aerohive.com
International Headquarters
Aerohive Networks Europe LTD
The Courtyard
16-18 West Street
Surrey, UK GU9 7DR
+44 (0)1252 736590
Fax: +44 (0) 1252711901