13.3 Validation Tools: Survey, Protocol and Spectrum

Objective 6.4 is about choosing tools that can prove a validation claim — and knowing what each tool is blind to. The same physical instruments appear again in Chapter 14 when the job is fault isolation (objective 6.5). This section stays on acceptance: after the install, which instrument produces evidence that coverage, capacity, roam behavior, or spectrum cleanliness met the design?

Four classes matter: throughput testers, wireless validation software (survey applications and scanners), protocol analyzers, and spectrum analyzers. A professional validation day often uses more than one. The exam trap is treating a single green display as proof of everything.

Throughput testers

Throughput testers are active traffic generators: iPerf/iPerf3, vendor Wi-Fi test utilities, dedicated handheld testers, and the active-test modules inside many survey packages. They answer one honest question: how many bits were delivered on this path, in this direction, for this duration, with these clients?

Used well, they are the capacity layer of the SLA. Used poorly, they are a speedtest theater. The rules from section 13.2 still apply: bidirectional flows, multiple representative clients, a LAN-side server, and notes for band, width, RSSI, SNR, retries, and MCS at the sample.

What a throughput tester can prove for validation:

• TCP or UDP goodput versus a written Mbps requirement at a mapped location.
• Rough symmetry or asymmetry between downlink and uplink.
• That adding a second and third client changes airtime the way the capacity plan expected — or does not.

What it cannot prove:

• Why goodput is low. The tester sees bytes, not the microwave, the adjacent-channel neighbor, the hidden node, or the saturated WAN firewall.
• Application MOS. A fat TCP pipe can coexist with a jittery voice stream if queues and access categories are wrong.
• Energy that never became an 802.11 frame. If the radio's clear-channel assessment kept backing off, iPerf only reports a disappointing number.
• Every client class. A tester laptop is not the scanner gun.

When throughput fails, keep the tester result as the failed requirement, then open a protocol or spectrum view to explain mechanism. Do not delete the failed iPerf run because a website later looked faster.

Wireless validation software: survey applications and scanners

Survey software ties measurements to a floor plan. You walk, the adapter samples, and the package draws RSSI, SNR, data-rate, and channel layers, plus requirement areas and a report. That location context is the difference between a professional validation artifact and a screenshot of a signal-bar widget.

Scanners (laptop or phone utilities that list BSSIDs, channels, security, and signal) are the lightweight cousin. They are excellent for a quick "who is on this channel?" check, for confirming an SSID appeared after a change, and for catching a rogue or mis-named network during the walk. They usually do not produce a requirement-based heat map or a roam-path report by themselves.

Together, this class can prove:

• Which BSSIDs were heard at each sample, on which channel, with what advertised security.
• Where received signal was strong or weak for the adapter you carried.
• That the intended ESS is visible in the requirement areas and that unexpected neighbors are documented.
• Walk-test active results if the survey package embeds ping, roam, or iPerf-like tests.

This class cannot prove:

• Application MOS or bidirectional multi-client goodput, unless you actually ran those tests and stored them — a green RSSI layer is not that proof.
• A full RF energy picture. Survey adapters report what the 802.11 NIC decoded plus whatever noise or utilization the driver invents. They do not draw a spectrum FFT.
• The complete retry and MCS story for every frame, unless the product is also capturing.
• Uplink quality as heard at the access point. Most survey kits measure the client side.

Adapter honesty is part of the method. Off-channel scanning is sampled, not continuous. Some adapters underestimate noise. Phone scanners often see a different band mix than the production fleet. Record the adapter model, driver, and survey-software version in the validation package so another engineer can reproduce the walk.

Protocol analyzers for validation

A protocol analyzer captures 802.11 frames in monitor mode, from a dedicated capture card, or from an access-point or sensor capture. For validation you are not hunting every fault in the building. You are asking whether the installed BSS behaves as designed.

Useful validation questions:

• Did probe, authenticate, associate, and the 4-way handshake (or 802.1X) complete at this location?
• What MCS did data frames use, and did that match the SNR you recorded?
• What fraction of data frames had the retry bit set?
• On a roam path, how long was the gap between the last data on BSSID A and the first data on BSSID B? Did the client reauthenticate from scratch?
• Are voice or video frames marked with the intended WMM user priority?

A protocol analyzer cannot show a microwave's analog energy, a poorly filtered DECT-like interferer, or a narrow-band tone that never decodes as 802.11. If the card wrote no frame, the decoder has nothing to say. It also cannot by itself produce a MOS score or an iPerf Mbps number, though those tests plus a capture together tell a complete story.

Save a short, well-labeled capture at a representative success point and at each failed requirement. Validation captures are evidence, not a fishing expedition. The longer fault-isolation workflow — filters, expert views, wired-side correlation — lives in Chapter 14.

Spectrum analyzers for validation

A spectrum analyzer looks at RF energy versus frequency and time: FFT traces, duty cycle, and waterfalls. Dedicated handhelds, USB spectrum adapters, and some access-point sensors belong in this class. Their superpower is seeing emitters that an 802.11 card never turns into a frame.

Wi-Fi NICs are decoders first. They report frames they can demodulate and, at best, a coarse noise or clear-channel sample. They are not calibrated spectrum instruments. A channel can look "empty" in a scanner — no BSSID list — and still be 80% occupied by a non-802.11 source. That is the exact failure a green RSSI-and-SSID report will miss and a spectrum duty-cycle plot will show.

What a spectrum analyzer can prove for validation:

• That the chosen channels sit in spectrum whose energy and duty cycle match the design's cleanliness assumption — or do not.
• That a complaint area has non-802.11 energy on the same frequencies the BSS uses.
• That an "unused" backup channel is not actually quiet.

What it cannot prove:

• Frame semantics: MCS, retry bit, 4-way handshake success, DHCP, or MOS.
• Which station is talking. Energy is not a MAC address.
• That capacity meets the SLA. High duty cycle is a clue, not an Mbps result.

Classifying that energy as co-channel 802.11 contention, overlapping-channel 802.11 interference, or a non-802.11 emitter — and then mitigating it — is objective 6.2 work. Do that analysis in Chapter 14. For 6.4, remember the validation role: spot-check the channel plan with a tool that can see energy the survey NIC missed, especially where users complain or where utilization looks mysterious.

What each tool can and cannot prove

A compact validation-day sequence:

1. Scanner / survey — map the ESS, channels, and RSSI/SNR layers.
2. Throughput tester — prove or fail the capacity points on a LAN path.
3. Protocol analyzer — sample association and roam exchanges at success and fail points; inspect retries and MCS where goodput disappointed.
4. Spectrum analyzer — sample channels that look busy without a matching BSSID list, plus a spot-check of the "clean" plan.
5. Document which tool produced each pass/fail line so a reviewer knows what was actually proven.

If you remember only one exam idea from this section, remember the mismatches. A throughput tester cannot see a microwave. A survey heat map cannot prove MOS. A protocol analyzer cannot plot energy it never decoded. A spectrum analyzer cannot tell you the 4-way handshake failed. Validation is the discipline of matching the claim to the instrument.