13.1 Post-Implementation Validation Surveys

A post-implementation validation survey is the measurement walk you perform after access points are installed, powered, and configured as the project intended. Its purpose is to verify and document that the live WLAN meets the written design requirements — typically coverage, throughput, roaming, and connectivity. This OpenExamPrep chapter teaches those verification skills as independent study material for CWNA-109 Domain 6 (RF Validation and Remediation, 20% of the official table). It is not a CWNP publication, and it does not speak for the exam sponsor.

Validation is an evidence step. It compares what the building actually does to what the design and the service-level agreement (SLA) promised. It is not a first-time design method, and it is not a substitute for a predictive model. Teams that skip modeling, hang access points by eye, then "validate" until a heat map looks green are not validating a design. They are exploring. The next chapter covers interference types, troubleshooting-tool workflows, and common WLAN faults (objectives 6.2, 6.5, and 6.6). This section stays on proving the install.

Validation versus design

Predictive work happens before brackets go on the ceiling. You import a scaled floor plan, assign attenuation to walls and racks, place virtual access points with the intended antennas and heights, and iterate until the model meets the requirement areas. The output is a design hypothesis: predicted RSSI, estimated SNR, and a channel-and-power plan. That hypothesis is cheap to change in software. It cannot prove that the installer used the specified antenna, that a concrete stair core matches the CAD label, or that Monday-morning occupancy will leave the noise floor where the model assumed.

Post-implementation validation happens after the install. You walk the same requirement areas with survey software, collect RF and client measurements, and produce a pass/fail package against the written requirements. If the predictive map was optimistic, validation finds the gap. If an installer moved an access point two bays to dodge a sprinkler, validation either confirms the as-built still meets the SLA or forces a remediation. Shipping a pretty predictive PDF after the job is not validation.

AP-on-a-stick (APoS) sits between those extremes. You raise a temporary access point — often on a pole — at the proposed mounting height and measure real energy from that location in the real building. APoS is valuable when wall materials are unknown, when warehouse racking will dominate attenuation, or when a historic ceiling will not accept the modeled antenna. It remains a design-time measurement. One temporary access point does not recreate the finished channel plan, the full neighbor list, or the production SSID and security path. Do not treat APoS as post-implementation validation of the completed extended service set (ESS).

Four survey methods you must keep separate

Passive and active are adapter behaviors, not calendar labels. You can run a passive scan in a finished building to map every BSSID. You can run a limited active test to a temporary SSID during APoS. Post-implementation validation of an enterprise WLAN almost always uses both: passive layers to show what was heard, active layers to show what a client could actually do.

A passive survey is efficient. The adapter records SSID, BSSID, channel, security advertisement, and received signal for frames it decodes — typically beacons and probe responses. It does not complete 802.11 authentication or association. That speed is why passive maps are excellent for discovering unexpected neighbors, checking that the intended BSSIDs appear where they should, and producing a first RSSI layer. The trap is treating beacon RSSI as user experience. Beacons are sent at a robust management rate. Data frames use different modulation and coding scheme (MCS) indexes, sometimes different radio chains, and they must survive retries in both directions. Hearing a beacon does not prove a client can join, get an address, or hold a call.

An active survey associates the test client to the WLAN and exercises the path. Typical active checks include association and the 4-way handshake (or 802.1X, if that is the design), DHCP and DNS, ICMP or HTTP reachability to a named service, iPerf-style throughput, and roam timing while walking. Active tests take longer and inherit the adapter, driver, and operating system you brought. Whenever the fleet is voice handsets or older scanners, a laptop-only active survey can lie by being too capable. Use representative clients for the applications the SLA names.

Heat maps: RSSI, SNR, and data rate

Survey software paints color on the floor plan. The color is only as honest as the layer underneath.

An RSSI heat map plots received signal strength, usually in dBm, at each sample. It answers a narrow question: how strong was the decoded 802.11 energy at this adapter? It does not answer whether that energy was usable. A client can show a respectable RSSI and still fail if the noise floor is high, if the access point cannot hear the client's weaker uplink, or if retries consume the air.

An SNR heat map plots signal minus noise. Modulation and coding depend on how far the signal sits above noise, not on an absolute dBm figure alone, so SNR is the more honest coverage layer for performance. Treat it as a decision layer, not a laboratory instrument: many survey adapters estimate noise poorly or report a synthetic floor.

A data-rate (PHY rate / MCS) heat map plots the rates used for data, not the access point's advertised capability. This layer sits closer to user experience than RSSI, but it is still not goodput. A client can select a high MCS and then retry until TCP collapses. Throughput, when the design requires it, is a measured active result, not a color inferred from RSSI.

Typical enterprise starting points — engineering practice, not CWNP-published CWNA numbers — often include about -67 dBm or stronger for data-oriented cells and about -65 dBm with richer secondary coverage for voice. High MCS commonly wants SNR in the mid-20 dB range or better. Channel width, band (2.4, 5, or 6 GHz), client radios, and the written SLA all move those numbers. The exam skill is measuring against the documented requirement, not memorizing one vendor's color legend.

Coverage, throughput, roaming, and connectivity

Coverage is the geographic claim: at this location, in this band, the design's minimum RSSI or SNR — and often a minimum count of usable overlapping BSSIDs — is met. Validate each band the design uses. A beautiful 5 GHz map does not excuse a 2.4 GHz handheld that still has to work.

Throughput is the capacity claim: at sample points, a defined test meets a minimum Mbps. A green RSSI blob is not a throughput result. Section 13.2 covers how to run those tests. For objective 6.1, remember that if the design promised capacity, the validation package must record capacity, not only coverage.

Roaming is a path claim, not a desk claim. Walk the corridors, stairwells, warehouse aisles, and clinical routes that devices actually travel. Document the BSSID before and after each roam, the time to complete the roam, and whether the application session survived. Sticky behavior — a client that clings to the first access point until SNR collapses — is a validation finding even when static desk RSSI looks excellent. Secondary coverage must exist so the next access point is usable before the first one dies. Fast secure roaming features (if the design specified them) are confirmed on the path, not assumed from a controller checkbox.

Connectivity is the service claim: the client associated to the correct SSID, completed the security handshake, received a usable address, resolved names, and reached the applications the SLA named. Beacon audibility is not connectivity. A guest splash page that never loads, a voice VLAN with no DHCP pool, or a clinical SSID that lands on the wrong VLAN are validation failures even when the RSSI heat map is green.

What you document

A complete validation package includes as-built access-point locations (update the drawing if hardware moved), heat maps for RSSI, SNR, and data rate (plus channel as needed), a table of sample points versus the SLA, roaming-path traces, a configuration snapshot (channels, transmit power, SSIDs, bands), adapter and software versions, date and occupancy notes, and an exception list with owners. Measure when the building looks like production: an empty floor at 02:00 is a different RF environment than a Monday clinic.

Common failures include validating only from a cart in the hallway, shipping RSSI-only maps, treating the predictive plot as post-install proof, using one Internet speedtest as the WLAN certificate, skipping roam paths, and never recording which adapter collected the data. If validation fails, remediate and walk again. A failed survey that is honestly documented is still a professional artifact. An undocumented "it looked fine" walk is not.