In the Wireless LAN world we still worship at the False God of dB. The false god is the single signal-strength number, the RSSI reading on your survey map, treated as if one signal metric could tell you whether a Wi-Fi network is any good. It cannot. Signal strength is mandatory. Without it nothing works. But a lone dB number is nowhere near sufficient, and designing or validating a network from that number alone is how you end up with Wi-Fi that passes the survey and fails the users.
Why we worship the number
Signal is easy to measure, easy to map, and easy to color red-yellow-green. Books, study guides, and design manuals have leaned on RSSI so heavily that a generation of engineers learned to treat one reading as the whole verdict. Walk the building, color the heatmap green, declare victory. The number feels like proof because it is the one thing every tool reports the same way.
That is the trap. A measurement you can take everywhere is not the same as the measurement that tells you whether the network does its job.
Let me be clear about what I am NOT saying. RSSI is critical. It is required. It is the base level requirement, and without enough signal you have nothing to build on. I have never argued otherwise and I am not arguing it now. What I am arguing is the difference between a floor and a finished building.
What connectivity is to a Cat6 cable
RSSI is to a Wireless LAN what continuity is to a Cat6 cable. It is the base requirement. Without it, nothing works. With it, you have proven almost nothing.
“Cat6” does not mean a cable that conducts electricity. It means a cable that meets the Category 6 physical requirements defined by the TIA, and those requirements go far past continuity: near-end crosstalk, far-end crosstalk, return loss, insertion loss, propagation delay, pinouts, and pair-twist ratios. A cable run can be perfectly continuous from end to end and still fail certification on any one of those.
No cable installer would pull barbed wire to every desk. Barbed wire easily meets the continuity goal. It meets none of the others. We all understand why that is absurd for copper. We somehow forgive ourselves for doing the wireless equivalent when we design a WLAN for “coverage” and nothing else.
The gap I described in 2010 is narrower now, not closed
When I first wrote this, the industry had no group defining what a “Voice-Grade,” “Video-Grade,” or even a generic “Data-Grade” Wireless LAN actually required. Every vendor wrote its own specs.
That gap has narrowed. Application-grade requirement frameworks exist now in forms practitioners actually use. There are widely circulated voice targets, SNR floors, loss and latency budgets for Voice over Wi-Fi, vendor deployment guides for real-time traffic and location services. Modern validation survey practice already measures signal plus SNR, co-channel interference and channel utilization, data rates, retry rates, roaming behavior, and capacity. The “many more categories” I pointed at back then are now things competent engineers measure as a matter of course.
What still does not exist is a single neutral, measurable, codified WLAN service-grade standard you can certify against the way you certify a Cat6 run. The targets that circulate are fragmented and use-case specific, not canonical. So treat any single RSSI or SNR figure for what it is: a use-case target you must measure and verify against a stated requirement, never a universal pass mark.
I took a run at this problem myself a while back, cataloging vendor design specifications with a few other CWNEs, and quickly found close to a hundred distinct parameters once you got past the first one. The first one is always RSSI. It is always merely the baseline. On top of signal strength sit overlap requirements, specific co-channel interference levels, data-rate support, devices-per-AP limits, minimum MCS, and a long list more. Some belong to the clients. Some belong to the Access Points and cabling. All of them have to be met together before you can honestly say the network delivers.
So two questions for you. Do you know the design specs your client devices actually require? And how would you tell whether your Wireless LAN meets them?
The truck, the sports car, and the minivan
Picture yourself as an automobile designer. Your bosses ask for a “vehicle,” defined loosely as wheels, an engine, seats, a frame, and a shell.
First request: carry two adults, hit freeway speeds, haul a 2200 lb payload. Easy. You build a truck. Everyone is happy.
Next request: 0 to 60 in under 5 seconds, sharp cornering, low drag. You build a light, high-powered sports car. Everyone is happy.
Last request: seven adults plus luggage, cup holders everywhere, easy in and out. You build a minivan. Everyone is happy.
The trouble starts when the truck owner decides that because he already owns a vehicle, it ought to run 0 to 60 in 4.2 seconds. Almost as an afterthought, he asks you to turn his truck into a racecar. Sure, it is possible. Rip out the engine, drop in a stronger one, then replace the heavy suspension and the dual-I-beam frame with carbon fiber because the truck was built to carry weight, not to corner. Spend all that money and you still end up with a poor truck and a poor racecar.
A Wireless LAN designed and validated for data will not transparently become a voice-grade network. Same physics, same lesson. The requirements are not just different, they are partly contradictory, and you cannot bolt one onto the other after the fact for free.
Certified Social Media Readers
Sometimes the boss is the boss from the vehicle story. He read something in a social media post about Wi-Fi doing voice, or video, or location tracking, and now he wants you to simply “add” that feature to the network you already built. Call them the Certified Social Media Readers, the CSMRs: people who collect opinions from articles without ever doing the hands-on work.
Many of these services demand mutually exclusive design goals.
- Voice carries almost no payload, yet it is brutally sensitive to latency, jitter, and loss for the little data it does carry. It is the racecar.
- Web browsing and large file transfers care about the size of the pipe and shrug off retries and brief dips in quality. That is the truck.
- Wi-Fi location tracking, the real-time location services that triangulate a client across many Access Points, needs lots of APs in specific spots. Those extra APs raise co-channel interference and grow the contention domain, which drags throughput down for everyone. That is the minivan.
All of which means the same building, designed three different ways, gives you three different networks. Just because your boss read about another company’s racecar does not make your truck a good drag car.
Know your design requirements
My clients still amaze me when I ask them to define the design requirements for their own WLAN devices. They do not know what the requirements are.
If you do not know what you are designing your Wireless LAN for, how can you possibly know when you have achieved a proper design?
No automobile engineer would take the job of designing a “vehicle” without knowing the rest of the characteristics. No cable installer would start pulling barbed wire to the desktops. Yet in the wireless world we let ourselves do exactly that. We design for coverage, for RSSI, for one green number, and then we act surprised when the network does not work.
If you do not know the specific parameters your client stations need, your Wireless LAN will NEVER meet them. You cannot specify what you cannot measure, and you cannot measure what you never bothered to define.
Stop worshipping the number
Yes, RSSI is important. It is required, mandatory, the floor everything else stands on. It is also the beginning of the design, not the end of it.
You do not run barbed wire to the desktops and call it a network. Stop designing your Wireless LANs with only RSSI. Define every requirement your clients actually need, measure across all of them, and verify the finished network against the full set. That is the only honest way to hand a Wi-Fi network to the people who have to live on it.