Many Wi-Fi requirements include a target such as “-67 dBm or better.” The number is not arbitrary: -67 dBm has long appeared in vendor voice-over-Wi-Fi design guidance, commonly alongside an SNR target around 25 dB. The problem is not the threshold. The problem is treating that single threshold as a complete definition of a working wireless network.
Here is what the number leaves out.
RSSI describes one link, in one direction, at one instant
Received signal strength is what a specific receiver reports about a specific transmitter, on a specific band, using a specific antenna, at whatever height and orientation the measurement happened to be taken. Change any of those and the number changes.
RSSI is also not calibrated across the industry. Chipsets and drivers differ in how they measure and report it, so two adapters standing in the same spot can disagree. That is fine for engineering work as long as the methodology is consistent and documented — and it is a reason a requirement should specify what measures compliance, not just what the target is.
A specification that says “-67 dBm” without saying on which band, at what height, from a primary AP or any AP, and measured with what, has four unresolved variables in a single sentence.
Signal strength without noise is half the picture
Radios do not decode signal strength. They decode signal relative to everything else the receiver hears. -67 dBm over a quiet -95 dBm noise floor is a healthy link. The same -67 dBm in an environment with an elevated noise floor, persistent non-Wi-Fi energy, or adjacent-channel interference may provide substantially less usable margin.
Channel width also belongs in the design criteria. Thermal noise power increases by roughly 3 dB each time channel bandwidth doubles. When total transmit power is fixed, that can reduce available link margin as channels widen. In power-spectral-density-limited environments such as 6 GHz low-power indoor operation, permitted transmit power can also increase with bandwidth, offsetting some of that effect. Either way, wider channels change spectrum reuse, noise, and capacity, so channel width should be selected deliberately rather than treated as free throughput.
Uplink and downlink are not symmetrical
An access point may transmit at higher EIRP than a battery-powered client and often has more receive chains and antenna gain. A client can therefore report a strong downlink RSSI while the return path has a different link margin. Whether the uplink is actually weaker depends on client transmit power, AP transmit power, antenna characteristics, and receiver performance, which is why both directions matter in the link budget.
This gap matters most with the devices that matter most in industrial and healthcare environments — single-stream handhelds, wearables, medical telemetry and battery-conscious IoT — which are precisely the devices least likely to appear in a laptop-based verification walk. On 6 GHz, link balance deserves additional attention because client and AP power limits differ and depend on the applicable 6 GHz power class. Actual configured AP power, client capability, antenna characteristics, and AP receive gain determine whether a meaningful uplink/downlink imbalance exists.
Signal strength says nothing about airtime
Wi-Fi is a shared medium governed by CSMA/CA. When clients and overlapping BSSs on the same channel can hear one another, they share airtime and must defer and back off before transmitting. As the contention domain becomes busier, each device has fewer opportunities to transmit. That is co-channel contention, and it is an airtime problem, not a signal-strength problem.
Signal strength maps cannot show this. A floor can be uniformly green at -60 dBm and still deliver poor real-world performance because the airtime is oversubscribed. That is the core argument for designing for capacity rather than coverage: the number of APs and the way their cells are shaped is a capacity decision first.
The client mix sets the real floor
A design threshold is only meaningful in relation to the devices that have to meet it. A modern laptop with multiple spatial streams and capable antennas may perform very differently from a single-stream handheld scanner with a compact antenna and a different transmit-power profile. If the requirement is written for the best client in the building and validated with the best client in the building, the network will be signed off and will still fail on the floor.
The design threshold should be set by the least capable business-critical client.
What a complete requirement looks like
Instead of a single number, a defensible design requirement specifies:
- Signal strength target, per band, with the measurement height and the reference client or adapter stated
- Minimum SNR — which forces the noise environment to be considered rather than treating RSSI in isolation
- Secondary coverage — where roaming or resiliency requires it, the level at which an additional AP should be usable so a client has an appropriate alternative cell
- Co-channel limits — how many APs on the same channel may be heard above a stated threshold at any point
- Capacity assumptions — expected concurrent devices per area and per-device throughput
- Channel widths per band, chosen against the capacity and margin trade-off
- Application tolerances — latency, jitter and loss limits for voice, video and real-time location
- Roaming behavior — required handoff performance and any client/infrastructure roaming mechanisms, such as 802.11k/v/r, that are applicable to the device population
Each of those items can be documented explicitly, and many can be validated directly after deployment. Together they describe a network requirement that can be engineered and assessed; -67 dBm alone describes a condition that a failing network can still satisfy.
The practical takeaway
Keep -67 dBm if it suits your applications. It is a sensible design threshold and it gives an installer something concrete to build to. Just stop treating it as the requirement. It is one line in a specification that needs several, and the remaining lines are the ones that determine whether the network holds up under load. If you would like help turning application needs into a testable specification before anyone models a floor plan, that requirements stage is where our enterprise Wi-Fi design work starts.