Jason Hintersteiner presented at #WLPC Phoenix 2018 about the common constraints encountered in real-world Wi-Fi deployments and the ways in which these constraints can be mitigated or overcome.
It’s 2018 but the world still designing Wi-Fi like it’s 1999. The industry is invested over 20 years and telling people how easy it is to deploy Wi-Fi.
The demands on these networks have increased exponentially since we started deploying Wi-Fi in the late ’90s. The nice to have is now “mission-critical” and the design for coverage is now replaced with “design for capacity”.
Wi-Fi technology is much more complex, which means that you have increased sensitivity to bad settings, placement, and bad Wi-Fi. We used to be more robust to this in the early days, we’re not anymore.
Good Wi-Fi design becomes absolutely essential, but it’s not just out of ignorance that we’re deploying Wi-Fi the wrong way.
There’s no excuse for ignorant in this day and age. But we still deploy it the wrong way and even experts deploy it the wrong way from time to time. Why is that?
Sometimes we have to and we don’t have a choice, but why don’t we have a choice?
These are what the network has to achieve and these are the requirements on any network:
Usage: What kind of devices are using the network? How are they connecting? How are they getting authenticated?
Coverage: What are the areas of the facility that need to have a signal? What kind of signal strength do they need to have? What kind of overlap do they need to have?
Capacity: How many simultaneous devices do I have to be able to handle on the network or their areas of high client density versus lower client density?
Control: How am I going to monitor this network? How am I going to manage the network? How am I going to make sure it’s actually working overtime?
Integration: What’s providing power? What’s providing backhaul? Do I have to worry about my switches and my cabling if I’ve got to do point to point or point to multipoint backhaul?
Ideally, those should be independent of each other and also they should be solution neutral. They should not be dependent on the vendor or who actually do it.
Constraints are the things I have to workaround.
- Limited budget
- Limited time to implement
- External RF environment
- Limitations in being able to run Ethernet cabling to where I want to run it too.
- Dictates to use particular AP vendors and models.
Many times you have a lack of information about the facility and sometimes you have a lack of access to the facility.
These constraints are very solution dependent and they are highly coupled to each other and to the requirements.
What Happens When You Have Too Many Constraints?
- The constraints drive the design, not the requirements. You want the requirements to be driving your design.
- Satisfying the constraints becomes your design goal not satisfying the ultimate requirements, which is what you really are targeting.
- It may become impossible to satisfy all of your requirements especially simultaneously.
Designing with Over-Constraints
Here are four fundamental things that I have control over:
- I can pick what IP vendor I use along with what model. If it’s a model with external antennas, I have some choice to go to my antenna partners and talk about what antennas.
- I have control over where I put those APs in the facility.
- I have control over what channels. I use those APs on each band.
- I have control over the transmit power.
These parameters are not independent of each other and they require Iteration.
Common Over Constraints
1. Location. I can’t put the APs where I want. I might have a limitation and being able to run Ethernet cabling to where I want it to go. I might have aesthetics nobody liked seeing ApS.
- Use directional antennas to actually get the signal where I want it.
- Use capable APs for applications.
- Use wireless backhaul point to point and point to multipoint solutions for wireless.
2. Budget. The lack of access. You can’t do pre-deployment or post-deployment site surveys because nobody wants to pay for it. You might need to go with fewer APs or less expensive APs
- Predictive modeling. In many scenarios, predictive modeling is good enough. It’s not perfect, it’s based on many simplifying assumptions. But very often it actually can be sufficient.
- Be wary of the leading edge. For most deployments, 802.11n is actually quite sufficient in many design scenarios.
- Mix and match. Use higher end piece from one vendor in the high capacity areas. Use cheaper lower end piece from another vendor in the coverage areas.
3. Radio Resource Management. Lots of installers are perfectly happy to see half of their design knows about software. Let the AP’s figure out themselves with RRM.
RRM usually breaks down in very complex scenarios.
- Turn RRM off. Use static channels especially in the complex over constrained areas. Let the external networks adapt to you.
- Use static transmit power. Turn down the power and make sure there’s a power offset between 2.4GHz and 5GHz.
It Can Be Done!
We usually don’t have the luxury of deploying Wi-Fi completely the right way, but you can still create good Wi-Fi designs and it’s not an excuse.
- Understand your requirements and constraints.
- Think creatively, don’t over constrain yourself.
- Pick the right AP for the job.
- Use all the design knobs that are available to you.
- Acknowledge the right way that you have to apply in this scenario.
Jason D. Hintersteiner is a Director of Business Development at LigoWave. Certified Wireless Network Expert (CWNE #171). Networking & Wi-Fi Expert.
If you have more questions or feedback, connect with Jason via twitter.