By Keith Parsons, CWNE #3
Heat map color does not measure performance. Vendor-supplied AP ratios are not engineering. And a pretty survey screenshot can hide a network that fails every requirement your customer actually cares about. Every WLAN decision — coverage, capacity, channel plan, AP selection, validation — must be grounded in defined requirements and measurable engineering. Start there, and the design work gets straightforward. Skip it, and you will be back on site fixing a network you already turned over.
Here are 10 rules I follow on every WLAN engagement. None of them are new. All of them get ignored, regularly.
Tip 1: Build the Wired Infrastructure First
The moment you power on an AP, every problem on the network becomes a wireless problem. Users will blame Wi-Fi for a misconfigured switch. Your customer will blame Wi-Fi for a broken DHCP scope. You will be chasing ghosts.
Build from the core out to the edge. Test everything — switching, routing, authentication, DHCP, DNS — before the first AP goes live. That way, when a problem appears after the APs come up, you have already ruled out most of the possible causes.
Tip 2: Delegate Everything Outside Your Design Scope
These are WLAN design tips. Cable pulls, conduit runs, ceiling tile coordination, structural mounting — delegate all of it to the right people. You are not a general contractor. Trying to manage every workstream in a large deployment divides your attention at exactly the moments that need it most. Know your lane. Work your lane.
Tip 3: Know the PHY
Every client device that hears an AP frame receives it differently. The radio tap header is added by the receiving NIC, not the transmitting AP. That means a single AP transmission produces a different received result for every client in the BSS — different spatial streams, different physical location, different antenna.
Channel width decisions follow from this directly. Going from a 20 MHz to an 80 MHz channel does not produce 4x the throughput. The arbitration overhead, the RTS/CTS exchange, the 802.11 overhead — none of it shrinks. Only the payload portion moves faster, and the payload is a small fraction of total airtime. You also lose 6 dB of SNR on that wider channel. Understand what you are actually trading before you make the call.
Capacity is about speed, not about adding APs. If clients transmit faster, each one consumes less airtime. Less airtime per client means more clients can share the medium. Add APs without fixing the throughput problem and you have added co-channel interference, not capacity.
Tip 4: Understand Co-Channel Interference
Wi-Fi is 100 times more sensitive to other Wi-Fi than it is to non-Wi-Fi interference. That is not an accident — it is built into the protocol. The distributed coordination function requires all devices sharing a channel to yield to each other. Two APs on the same channel, in range of each other, share the capacity of one AP. The second AP does not add capacity. It reduces it.
This is the number-one cause of remediation calls I have seen in my career. Design for it, validate for it, and minimize it before you count on any capacity number.
Tip 5: Know All Your Requirements
“We need Wi-Fi everywhere, fast” is not a requirement. It is a wish. You cannot design to it, and you cannot validate against it.
Requirements divide into 2 groups. The first group goes directly into your design and validation tools — consider the following:
- Primary coverage threshold (in dBm, not a color)
- Secondary coverage threshold, also in dBm; if you cannot measure it in dBm, do not put it in the spec
- Frequency band assignment (only 2.4-GHz-only devices belong in the 2.4 GHz band; a 5-GHz-capable device parked there wastes capacity it cannot recover elsewhere)
- Co-channel interference budget
- Device-to-radio ratios for any device type that specifies one
- Minimum data rate requirements
All of which must be measurable before they belong in your design specification.
The second group requires different measurement tools but is equally binding: jitter, latency, end-to-end QoS. These are still requirements, they just do not come out of your survey software.
Special density areas need explicit callouts. A stadium bowl is normal density for a stadium. The concourse tunnels are not. Design to the specific requirement in each zone, not to a one-size label.
Tip 6: Follow Best Practices, and Break Them Deliberately
Never hang an AP on a wall like a clock. Never put APs in hallways. These are best practices for good reasons, and following them will produce a functional design in most situations.
But there are legitimate reasons to break every rule. The discipline is: break a best practice only when you can show, with data, why breaking it produces a better outcome for this specific deployment. You put the AP on the wall because you tested both placements, measured the results, and the wall won. Not because it was convenient. Not because a photo on the internet made it look reasonable.
Wi-Fi is resilient enough that you can do it wrong and have it still work. Working is not the standard. Efficient is the standard.
Tip 7: Never Use Marketing Ratios for AP Placement
One AP per 2,500 square feet. One AP per 2,000 square meters in high-density areas. These numbers exist because they move product, not because they represent engineering.
Building a dog house requires almost no structural analysis — sketch it on a napkin and start cutting. Scale up to a barn and you need wind load calculations, snow load analysis, and a real decision between truss framing and steel. WLAN design scales the same way. At home scale, a rule of thumb works fine. At enterprise scale it will hurt you.
Use free-space loss math. Use real propagation modeling. Use the tools built for the job. Ratios are for salespeople; math is for engineers.
Tip 8: Always Validate
Validation is not optional. It is the only way to know that the design you specified is the design that got installed.
Run passive surveys first, always. Passive captures everything: your SSIDs, neighboring SSIDs, interference sources, the full RF picture. Active surveys, where your client associates to an AP and runs traffic, are useful, but they skew. Active data degrades as you walk away from the serving AP, drops at the roam point, then spikes as the next AP picks you up. That curve does not map to real user experience.
Use continuous survey mode. Stop-and-go discards everything collected while you are walking, which is most of the survey. Continuous captures every data point between your start and stop clicks. The difference in data density is not subtle.
Validate against the requirements you defined before the design started. Not against a heat map color setting.
Tip 9: Choose Your AP Before You Design
There is no generic AP. You cannot design against a placeholder, install a different product, and expect the propagation model to hold.
We ran this test on a high school football field. 2 APs at the same transmit power, the same installation height (1.4 meters off the ground), tested against a 4-device client mix — a MacBook, a laptop with an AX chipset, a Wi-Fi 6 iPad, and a Wi-Fi 6 iPhone. Throughput measured at 10, 25, 50, 75, and 100 meters. One AP had a 4-antenna array; the other had an 8-antenna array.
The heat map favored the 4-antenna AP. At every distance measurement, the 8-antenna AP outperformed it on actual throughput. The wider array focused energy differently, and the clients responded to it.
Green on a heat map does not equal performance. RSSI is a necessary condition, not a sufficient one. Choose your AP, test it under conditions close to your actual deployment, and design around what it actually does, not what the data sheet claims or what a heat map color implies.
Tip 10: Document Everything
Document requirements before you start designing. Document your channel plan. Document your AP selection rationale. Document your validation results. When a customer calls back 3 years later and says the network does not work, you pull up the documentation and ask: does the current state match the requirements we designed to? Usually the answer is: the requirements changed. New devices. New applications. Higher density than the original spec covered.
Documentation also handles the harder scenario — the customer who insists on a design you know will underperform.
When a customer pushes hard for something I know is going to hurt the network — APs in hallways, below-ceiling mounting, a channel plan built around co-channel interference — I stop arguing. I hand them a document. It reads:
“Yes, Keith, please design me a poorly performing network.”
I have had people sign it. What usually happens: they get a little gun-shy, put the pen down, and ask what they actually need to do to fix the problem. The document exists not to be signed. It exists to make the choice visible. Documentation forces the clarity that verbal negotiations avoid.
The verdict
Requirements first. Engineering always. Vendor ratios never. If you cannot measure it, do not put it in your design specification. That covers the entire list above, and it applies to every engagement, every site type, every client mix. Measure twice, cut once, then validate what you cut.