Wi-Fi Site Survey Guide: Passive vs Active vs Predictive

A site survey is not a checkbox before installation. It is how you find out whether the design you drew on a floor plan survives contact with a building full of concrete, metal and other people's access points. Get the survey method wrong and you will install the right number of APs in the wrong places, then spend the next two years chasing coverage complaints that no amount of channel tuning will fix.

This guide covers the three survey methods, what each one is actually good at, the measurements worth recording, and the validation step that most projects skip.

The Three Methods

Most successful projects use all three in sequence: predictive to design, AP-on-a-stick or passive to confirm the design before cabling, and active to prove performance after install.

Requirements Before You Walk the Floor

The survey answers questions you have to ask first. Write these down:

• Applications and their tolerances. Voice needs low jitter and reliable roaming; a warehouse scanner needs coverage in odd places; video needs sustained throughput. Each implies different pass/fail thresholds.
• Capacity, not just coverage. A classroom with 40 students streaming is a completely different design from a corridor with the same RSSI.
• Client mix. The oldest client in the fleet sets the design ceiling - a 2.4 GHz-only legacy device forces you to keep 2.4 GHz coverage you would otherwise drop.
• Constraints. Where cabling may not go, where APs cannot be seen, listed-building restrictions, and ceiling types.
• Interference sources. Neighbouring tenants, microwave ovens, radar, warehouse automation, and - increasingly - someone else's high-density deployment on the other side of a wall.

Running a Passive Survey

Passive surveying means the device transmits nothing. It records what it hears, which makes it non-intrusive and safe to run in production at any time.

# a quick manual sanity check on Linux before importing a survey tool
sudo iw dev wlan0 scan | grep -E "SSID|signal|freq|DS Parameter"
nmcli -f IN-USE,SSID,CHAN,SIGNAL dev wifi list
# channel utilisation and interference on the AP itself
show ap auto-rf dot11 5ghz
show ap dot11 5ghz cleanair air-quality summary

Walk a deliberate path - perimeter first, then a serpentine grid across open areas - and take measurements dense enough that the heat map is not interpolated fiction. Record the noise floor as well as the signal, because SNR is the number that predicts performance and a strong signal next to a strong interferer is still a bad cell.

What passive surveys are good at: finding coverage holes, identifying co-channel and adjacent-channel overlap, discovering rogue or neighbouring APs on your channels, and confirming that the designed primary coverage is really primary.

Running an Active Survey

Active surveying associates and passes traffic. It answers the questions passive cannot: does the client actually get the throughput, does it roam cleanly, and does the application work?

# throughput and latency while roaming, from the client
iperf3 -c perf.example.com -t 60 -i 5 --timestamp   # walk during the run
ping -i 0.05 -D 10.0.0.1 | ts '%.s'                 # packet loss during roam

# verify which AP and band the client is on at each point
netsh wlan show interfaces        # Windows
sudo iw dev wlan0 link            # Linux

The pitfalls are real: results depend on the client chipset, on what other clients are doing at that moment, and on which AP the client happened to choose. Run active tests more than once, at different times of day, and treat a single bad run as a hypothesis rather than a finding.

The measurements that matter for real applications:

• Roaming. How long does the client lose connectivity during a transition? Voice needs this under about 50 ms with modern standards making this easier but not automatic.
• Throughput per client at the cell edge, not in the centre of the cell.
• Retry rate and MCS distribution from the AP side, which reveal a marginal cell long before the client complains.
• Air time consumed, which is the real capacity constraint and the reason channel utilisation predicts trouble better than client count.

AP-on-a-Stick and Predictive Modelling

For a new deployment, modelling the floor plan with your chosen AP model gives an AP count and placement. Treat that output as a proposal. Then mount a real AP on a tripod at one of the proposed positions and survey from it. The delta between the model and the measurement is what your survey is actually buying - walls are never quite where the CAD drawing says, and attenuation varies far more than vendor reference values suggest.

Useful pass/fail targets, adjusted for your application mix:

Post-Installation Validation

The survey that prevents the most trouble is the one nobody schedules: after deployment, re-run the passive survey and compare it against the design. Differencing two heat maps turns "the design assumes -65 dBm here" into "we measured -72 dBm here, the second AP never came up". The AP controller's own view helps here - on a Catalyst 9800 the RF and policy state is available per AP and per tag, and the tag structure described in this policy profile and policy tag guide is a good place to confirm that every AP actually received the intended settings. If clients authenticate with 802.1X, a wrong VLAN from a mismatch between the design and RADIUS attributes is easy to blame on RF; this WPA3-Enterprise and RADIUS configuration guide covers the checks on that side.

Common Mistakes

• Surveying an empty building and calling it done. People and furniture absorb RF. A design validated at 07:00 is not validated at 14:00.
• Chasing coverage at the expense of capacity. Turning power up to fill a hole raises co-channel interference everywhere else.
• Ignoring the 2.4 GHz band. If you cannot turn it off, it needs the same deliberate channel plan, not the leftovers.
• One-shot surveys. Buildings change. Re-survey after major fit-out, after a tenant moves in, and whenever complaint patterns shift.
• Reporting signal strength instead of application outcomes. Stakeholders care whether calls drop, not whether the heat map is green.

原文链接：https://www.ekahau.com/blog/wifi-survey-101/