In the world of Wi-Fi, I have observed countless occasions where administrators have deployed poor designs and configurations. I am here to argue that it’s not their fault, because Wi-Fi makes no sense.

Specifically, I think that the more logical you are with your Wi-Fi deployment, the more problems you are likely to run into, because Wi-Fi logic does not pair well with general logic.

I would suggest that Wi-Fi’s biggest strength is also its biggest weakness. Resilience. Wi-Fi is incredibly robust and able to handle all sorts of poor deployment factors. Until it can’t handle those factors. That resilience leads the uninitiated to assume they have done a “good” job deploying, because it works!

Let’s run through some examples (read: pitfalls) that I see done all the time in Wi-Fi deployments.

Number 1 – Physical Design

This is where we want to place APs, and in most users’ experience, it doesn’t matter where they put it at home. One device at the corner of their house where the cable comes in is enough and that works! So why would it matter if I put APs above ceiling tiles? Or behind the fridge? Or wherever it’s easiest to get a cable in the corner?

Because we want to cover as much as possible. Perhaps we put it in the middle of the corridor, so it evenly covers everything. I also want the power as high as allowed, because I want the signal to go as far as possible. And if you use a Wi-Fi simulation tool, then you can make it all look green, so it’s great!

Typical logic would show all of these decisions to make complete sense.

…but Wi-Fi makes no sense.

Wi-Fi logic actually explains that placement is incredibly important, and design should consider how cells overlap. How clients make decisions to connect and roam. How contention affects devices further away.

So, without going too technical, what are the pro tips for someone when physically designing placement? All of these have caveats that experts can argue, but to have the highest likelihood of a successful deployment without in depth knowledge, here are the tips to follow.

1. Put the Wi-Fi where you need Wi-Fi. The simplest way to provide service is to keep the AP close to the user.
2. Keep the power below maximum. We want to control where the signal goes as much as we can. You don’t shout in every conversation you have, and in Wi-Fi, the clients are limited in their ability to shout back.
3. Don’t use corridors – the users are in the rooms, put the Wi-Fi where they are.
4. Don’t overdo the AP numbers. We often think adding APs solves Wi-Fi problems, but it rarely does. Are you adding numbers for a specific, capacity reason, or are you just adding Wi-Fi in the vain hope it improves something?
5. Try not to hide APs. We think they’re unsightly and put them behind ceiling tiles or anywhere out of sight. Consider the criticality of the service they’re offering for the organisation. You must put lights and sprinklers in particular places, or they don’t work. Wi-Fi is no different.
6. Wi-Fi is complicated, consult in specialist cases. There’s a whole community out there, and getting high density and specialised Wi-Fi requirements right is very difficult. Don’t be afraid to ask.

Number 2 – Expectations

Wi-Fi marketing is a wonderful thing. We can get 1.21 Gigawatts of throughput with the latest Wi-Fi hardware. It’s better than wires! It cures ailments.

Administrators and users alike have an unrealistic expectation of what to expect in an enterprise wireless space, and the best way I can think to describe this is to think about cars.

Your car, for the road, be it electric or combustion, is designed for anyone with a basic knowledge of cars to get in and drive. It has easy buttons, it is not configurable, and it just works. This is your home Wi-Fi.

Then we look at a Formula 1 car. The steering wheel is a puzzle of buttons, everything is configurable. There are tens of engineers to run it and hundreds that design it. Its capability is drastically more, but the practicality and universal usability disappears. This is enterprise Wi-Fi.

So if we then come in with the incorrect expectations of how easy it is to set up and deploy, or what outcome we’ll get on use, then it’s easy to mistake something that is operating as expected to actually seem inferior to what I have at home.

The universal example, the speed test. Speed testing is synonymous with network performance. Internet is advertised in speeds. The different standards tout their expected “speeds”. Consumer devices advertise their capability and show downloads measured in speed. It’s a simple to understand, universal number. Bigger number > better network.

So, at home I go and run a speed test and I hit 600Mbps+ on my iPhone.

I go into the office, I’m getting 100Mbps, that is objectively worse.

Therefore, enterprise Wi-Fi deployment is worse than my home Wi-Fi.

I completely understand the logic, the F1 car should be faster, but Wi-Fi makes no sense.

When we do this test, we measure the wrong thing. In enterprise, we’re having to design a wireless network in an uncontrolled ecosystem, with many more devices connecting. This means we have to compromise headline throughput numbers on individual devices for stability and consistency. The F1 car is still restricted if it’s on the motorway with all the other traffic in rush hour.

We put in narrower channels; we disable certain features. We ultimately share the same Internet pipe with everyone on the network, so there are more opportunities for bottlenecks.

But the point is, does it work? Do the applications you need to use function? Because that’s what it needs to be designed to. Consistent network connectivity delivered to hundreds or thousands of devices, with room for growth.

Long story short, speed test is not a measurement of your network quality, set that expectation.

Number 3 – Features

One common challenge I get to overcome is discussing how we turn off features. Enterprise Wi-Fi solutions have hundreds of extra features. Some standardised, some proprietary. But the universal truth is that they have a specific use case, and that use case isn’t for every single deployment.

I understand. The features sound wonderful, and you paid for these very capable APs. As vendors we can be guilty of marketing the features in their best light. In actuality, you often enable features that actively hinder the network performance.

Let’s quick fire through examples:

Load balancing

Sounds great, balance your clients across the network! But Wi-Fi makes no sense…

Practically, this almost always breaks EVERYTHING. There are very few situations where clients need to be balanced. This feature is typically specifically designed for open areas with static clients where we need to move people off the AP by the entrance. Commonly a lecture hall, for example.

Outside of that, we are going to push clients to less busy APs without any context, confusing the client that doesn’t want to move, because it’s picked the best AP. In a correct design, they’ll naturally balance to the closest APs most of the time anyway, so this is unnecessary.

Transmit Beamforming – standards-based signal focusing

Who doesn’t want extra signal? Well, me…

The idea of TxBF is to be able to increase signal strength, which on the surface sounds great. But Wi-Fi makes no sense.

The overheads and impact on the airtime for such a nominal gain just don’t make this worthwhile. Add to this that it does actually need additional antennas beyond what you are using to even make it work, and if you don’t have any spare, on a smaller 2×2 AP for example, the trade-off becomes drastic. If you’re relying on TxBF for good coverage, you’ve likely made compromises in the design that should be reconsidered.

Zero wait DFS – return to DFS channels quicker

This can be a great feature… but Wi-Fi makes no sense. When your AP hears radar in particular parts of the 5GHz spectrum, it has to move to another part of the spectrum. If where it moves to is subject to the rules of DFS, it has to listen for a full minute (or even 10 minutes depending on the channel) before it can start using that channel. Zero wait DFS removes that wait, but it does this by actively listening to those channels before they are used. That radio may have been better served for data.

Rate Limiting – Restrict bandwidth, especially for guests or untrusted users.

Objectively, this sounds like a great idea. Protect your internal traffic from those pesky guests that hog all the bandwidth. But Wi-Fi makes no sense…

Rate limiting doesn’t reduce how much people download; it just makes it take longer. So now, rather than getting people on and off the Wi-Fi as quickly as we can, we instead increase the airtime they use. This affects all connections, and has the opposite effect to the intent, worsening everyone’s experience. This is true at the AP and even at the WAN, so just don’t rate limit anywhere.

Summary

So, does Wi-Fi actually make sense?

There are many more examples of this, and I’ll probably expand on these in a later article, but the key takeaway is: Wi-Fi makes no sense… until you learn its internal logic.

Wi-Fi remains incredibly resilient, and it will keep trucking along through all the poor decisions, features and designs that get thrown at it. But it always has a breaking point, and that typically comes when it’s under the highest load. It works under testing conditions, but when everyone turns up Monday morning it fails.

If you want to learn more on specific topics, review my regular articles and getting started guides. If you have an idea for a topic, don’t hesitate to reach out!