Understanding RSSI and Signal Strength for Optimal Channel Planning

Understanding RSSI and Signal Strength for Optimal Channel Planning A Purple WiFi Intelligence Briefing [INTRODUCTION & CONTEXT — approximately 1 minute] Welcome to the Purple WiFi Intelligence Briefing. I'm your host, and today we're getting into the fundamentals that underpin every high-performing wireless network: RSSI, signal strength, and how they drive optimal channel planning. If you're an IT manager, network architect, or venue operations director, you've almost certainly encountered the frustration of a Wi-Fi network that looks fine on paper but performs poorly in practice. Guests complaining about dropped connections. Handheld scanners losing signal mid-transaction. Video calls breaking up in the boardroom. The root cause, more often than not, comes back to a misunderstanding of what RSSI actually tells you — and more importantly, what it doesn't. In the next ten minutes, I want to give you a clear, practical framework for understanding these metrics and translating them into better channel planning decisions. This isn't academic theory. This is the kind of briefing I'd give a client before a major deployment. Let's get into it. [TECHNICAL DEEP-DIVE — approximately 5 minutes] So, what is RSSI? RSSI stands for Received Signal Strength Indicator. It's a relative measurement of the power level of a radio frequency signal as received by a client device. It's expressed in negative decibels relative to a milliwatt — so negative dBm. The closer to zero, the stronger the signal. Minus 30 dBm is excellent. Minus 90 dBm is effectively unusable. But here's the critical point that many deployments get wrong: RSSI alone does not tell you whether a connection is good. It tells you how loud the signal is. It does not tell you how clear it is. That's where Signal-to-Noise Ratio — SNR — comes in. SNR is the difference in decibels between your received signal and the ambient noise floor. If your RSSI is minus 65 dBm and your noise floor is minus 90 dBm, your SNR is 25 dB. That's the minimum you need for the high-order modulation schemes — things like 256-QAM — that deliver real throughput in 802.11ac and 802.11ax networks. Think of it this way. Imagine you're in a quiet library. Someone whispers to you from across the room. You can hear them clearly — that's a good SNR. Now imagine you're at a stadium during a match. Someone shouts at you from the same distance. The signal is louder, but the noise is also much higher. You might struggle to understand them. That's exactly what happens in a noisy RF environment. Now, why does this matter for channel planning? Wi-Fi is a shared medium. Every device on the same channel has to take turns transmitting, governed by a protocol called CSMA/CA — Carrier-Sense Multiple Access with Collision Avoidance. Before transmitting, every device listens to check if the channel is clear. If it hears another device, it backs off and waits.Co-Channel Interference — CCI — occurs when multiple access points on the same channel can hear each other. They all back off. They all wait. Channel utilisation goes through the roof, and latency spikes, even when actual client traffic is low. This is one of the most common performance killers in enterprise deployments, and it's entirely avoidable with proper channel planning. Adjacent Channel Interference — ACI — is a different problem. In the 2.4 GHz band, channels are only 5 MHz apart but each channel is 22 MHz wide. So they overlap. If you put an AP on channel 3 next to an AP on channel 1, the RF energy from channel 3 bleeds into channel 1, raising the noise floor and degrading SNR. The solution in 2.4 GHz is to use only channels 1, 6, and 11 — the three non-overlapping channels. In the 5 GHz band, you have far more spectrum to work with. You can use DFS channels — Dynamic Frequency Selection — to expand your available channel set, though you need to be aware that radar detection can force a channel change, which causes a brief disruption. Now, a word on channel widths. There's a temptation to use wider channels — 40, 80, or even 160 MHz — because they offer higher theoretical throughput. And in a low-density environment, that's fine. But in a high-density venue — a hotel, a stadium, a conference centre — wider channels mean fewer non-overlapping options, which means more CCI. In those environments, 20 MHz channels in 2.4 GHz and 20 or 40 MHz in 5 GHz is almost always the right call. Let me talk about AP placement and power tuning, because this is where I see the most mistakes in the field. There's a common misconception that more transmit power equals better coverage equals better performance. It's wrong. Setting AP transmit power too high creates what we call an asymmetric link. The AP can shout loudly, and the client can hear it clearly from a long distance. But the client — a smartphone, a laptop, a handheld scanner — has a much weaker transmitter. It can't shout back with the same power. So the AP can't hear the client reliably. This also creates the "sticky client" problem. A device in a far corner of the building can still hear the AP at minus 70 or minus 75 dBm. It decides the connection is acceptable and stays put, even when it moves physically closer to a different AP. The client doesn't roam. Performance degrades. The fix is to tune AP transmit power down — typically to 10 to 14 dBm — to match the client's capabilities, and to ensure sufficient AP density so that clients are always close to an AP. To facilitate seamless roaming, you should implement the 802.11k, 802.11v, and 802.11r protocols. 802.11k provides clients with a neighbour report — a list of nearby APs they could roam to. 802.11v allows the network to suggest that a client roam to a better AP. And 802.11r enables fast BSS transition, dramatically reducing the time it takes to re-authenticate when roaming. Together, these protocols ensure that roaming decisions are driven by RSSI thresholds rather than client inertia. [IMPLEMENTATION RECOMMENDATIONS & PITFALLS — approximately 2 minutes] Right. Let's talk about implementation. Here are the key steps I'd walk through with any client. First, define your requirements before you touch any hardware. What is the minimum RSSI you need to support your most demanding application? For voice over Wi-Fi, you need minus 65 dBm or better. For high-throughput data, minus 70 dBm. For basic connectivity, minus 75 dBm. And critically, identify your Least Capable, Most Important device — the device with the weakest radio that absolutely must work reliably. Design for that device. Second, conduct a proper site survey. Not just a predictive survey using software, but an active survey with real hardware in the real environment. Measure RSSI and SNR. Use a spectrum analyser to identify non-Wi-Fi interference sources — microwave ovens, Bluetooth devices, DECT phones, even some industrial equipment. These raise the noise floor and degrade SNR without showing up on a standard Wi-Fi scan. Third, plan your channels before you deploy. In 2.4 GHz, stick to 1, 6, and 11. In 5 GHz, create a channel reuse plan that maximises the physical separation between APs on the same channel. Use 20 MHz channels in dense environments. Fourth, tune your transmit power down. Match it to your client devices. Ensure 15 to 20 per cent cell overlap to support seamless roaming. Fifth, set minimum mandatory data rates. Disable the legacy rates — 1, 2, 5.5, and 11 Mbps in 2.4 GHz. This forces clients to roam sooner when RSSI degrades, rather than clinging to a distant AP at a low data rate. Now, the pitfalls. The most common one I see is over-reliance on automatic channel assignment. Most enterprise AP vendors offer automatic radio resource management — it sounds great in theory. In practice, in complex environments, it can make poor decisions. Always validate the channel plan manually after deployment. The second pitfall is ignoring the noise floor. A network can look fine on an RSSI heatmap but perform terribly because the noise floor is elevated. Always measure SNR, not just RSSI. The third pitfall is deploying a guest Wi-Fi solution without thinking about the RF implications. Captive portals, analytics platforms, and location services all depend on a well-architected RF environment. If the RF is broken, the analytics will be inaccurate and the guest experience will be poor. [RAPID-FIRE Q&A — approximately 1 minute] Let me run through a few quick questions I hear regularly. What RSSI do I need for a reliable connection? Minus 65 dBm or better for primary coverage. Minus 70 dBm for roaming overlap zones. Should I use 80 MHz channels in a stadium? Almost never. The reduction in available non-overlapping channels causes CCI that far outweighs the throughput benefit. My site survey shows good RSSI but performance is still poor. What's wrong? Check your SNR. Check your channel utilisation. Check for sticky clients. One of these three is almost certainly the culprit. Is 2.4 GHz still worth deploying? Yes, for legacy device compatibility and penetration through walls. But limit it to channels 1, 6, and 11, and consider disabling it on every other AP in dense environments to reduce CCI. [SUMMARY & NEXT STEPS — approximately 1 minute] Let me wrap up with the key takeaways. RSSI tells you signal strength. SNR tells you signal quality. Always optimise for SNR, not just RSSI. Design for capacity, not coverage. More APs at lower power beats fewer APs at high power in any dense environment. Use non-overlapping channels. In 2.4 GHz, that's channels 1, 6, and 11. In 5 GHz, build a proper channel reuse plan. Implement 802.11k, v, and r to ensure roaming is driven by RF conditions, not client stubbornness. Validate with a real active site survey. Software predictions are a starting point, not a final answer. And finally, remember that your RF architecture is the foundation for everything else — your guest Wi-Fi experience, your analytics, your location services, your operational efficiency. Get the RF right, and everything else becomes much easier. If you want to go deeper on channel width selection, check out the Purple guide on 20 MHz versus 40 MHz versus 80 MHz. And if you're looking at deploying guest Wi-Fi with analytics at scale, the Purple platform is hardware-agnostic and integrates with your existing infrastructure. Thanks for listening. Until next time.