Planning is crucial for a good WiFi deployment. While the wireless process is always cyclical in nature, comprehensive planning will set an optimally performing WiFi network apart from a poor one. As Abraham Lincoln said, “Give me six hours to chop down a tree and I will spend the first four sharpening the axe."
The WLAN planning phase should consume most of your project time as you gather information for your design. Getting as much information up front will serve as the foundation for a solid deployment and user expectations will be closely met, upon further verification and optimization.
Planning should involve three steps: Gathering requirements, speaking with the right people, and auditing the network infrastructure.
Gathering requirements may be the most difficult part of deploying WiFi networks. When asking stakeholders about their WiFi requirements, don’t settle for the following responses: “WiFi everywhere," "I just want it to work” or “I don’t know." By asking the stakeholders more questions, you can get to the actual requirements. Start by asking how they expect to use WiFi. For example, the actual deployment for “light email and web usage” will differ from an all- wireless office.
Find out how many devices will be using WiFi. By gathering this requirement, you can get an accurate number of access points to support the devices, eliminating the guessing game. The number of devices will determine airtime utilization and association per access point based on the required throughput per device.
In addition, finding out what kind of devices will be using WiFi will help tune the access points to provide better capabilities. For example, do these devices have dual-band radios or are there 2.4 GHz-only radios? What are the device capabilities, such as 802.11b vs 802.11ac support, transmit power capabilities, 802.11r and 802.11k support, and MIMO support.
This information would tell you which data rates to disable and support, whether to design for 2.4 GHz or 5 GHz, and what transmit power you’ll set the access points to for cell sizing. Knowing more about the devices can help you determine data rates and approximate throughput ability.
You may need to sit down with some users to find out what kind of applications will be utilizing the air space. This helps determine if there are applications sensitive to latency or jitter, which could affect how dense your access point deployment may be.
An application also may require a specific amount of throughput, which will become a factor in how many devices are using WiFi and how many access points are deployed.
Another factor to consider when supporting applications over WiFi is coverage. Will the application require roaming, such as voice-over-WiFi phones? Maybe you’re working with doctors who require connectivity in the stairwells between building floors. Are there requirements to have WiFi outdoors between buildings?
While coverage is a given in WiFi deployments, many miss the capacity portion. Proper planning will ensure capacity is met based on the requirements given during the questioning portion of planning. Find out how many devices must be supported at any given time, with what type of application, and what type of peak usage. Having these details will help you determine how many 2.4 GHz and 5 GHz radios are needed.
Speak with the right people
To obtain accurate WLAN requirements, you must speak to the right people. Sometimes no one person can provide all the answers. Start with the stakeholders, such as CIOs and IT directors; these are the visionaries. How do they expect users to use WiFi? The stakeholder provides insight on abstracts using non-technical terms, but with your expertise, you can say what is possible or not possible and how much it would cost.
For example, a stakeholder may say: “I envision our users to use wireless phones to speak to other doctors while walking from their office to the surgery room. Users should be able to take their laptop from their office to the conference room and display a PowerPoint on the screen without the use of any cables." These aren’t technical requirements. but they do lay out what end users need to be able to do their jobs.
One detail that's important to some people are access point aesthetics. This discussion is the best time to present the technical disadvantages when access points are placed in locations that aren’t ideal. Access points should have line of sight to the devices. If access points are required to be hidden or blend in with the surroundings, then they may require special mounts or enclosures, which will add to WLAN costs.
Technical staff members can help you identify devices on the network while end users can explain how they use the applications.
If you’re unable to gather the number of devices, you may be able to get a head count from human resources. In large BYOD environments, it may be impossible to determine the types of devices. A network management system can identify trends about the types of devices connecting and their capabilities.
When planning to deploy the latest WLAN hardware, you need to review the current network infrastructure. For example, when upgrading from an older 2.4 GHz deployment to a mostly 5 GHz deployment, will the wiring accommodate more access points?
Wiring will be required for each access point. What kind of cabling already exists and at what cost will it be to run new wires? This information will determine budget requirements.
Additionally, consider whether the wiring will meet the distance limitations to the nearest closets. Within each closet, take inventory of the switches the access points plug into. Will each switch be able to provide power for each access point using the 802.3at standards? You'll need to figure out budget requirements for Power over Ethernet (PoE) and whether the switches need to be upgraded. If new switches aren’t in the budget, then consider using PoE injectors.
In my next blog, I'll examine the next step in a WiFi deployment: Conducting a wireless site survey.
Rowell is a network engineer at a large teaching and research university in the Bay Area. He has 10 years of technical experience from many levels of IT ranging from non-profit to private enterprise and higher education. Read his blog at Packet6 and listen to his Clear To Send podcast.