Study guide
13.1 Post-Implementation Validation Surveys
CWNA Certified Wireless Network Administrator CWNA-109
Track your progress as you read
Finished sections get a check mark.
1 Introduction & Exam Overview
1.1 Current Exam Facts 1.2 CWNA-109 Knowledge Domains and Study Strategy
2 RF Fundamentals
2.1 RF Waves, Propagation, Gain and Loss 2.2 Reflection, Multipath, VSWR and Free-Space Path Loss 2.3 RF Units and the Rule of 10s and 3s
3 RF Measurement and Antenna Systems
3.1 Noise Floor, SNR, RSSI and EIRP 3.2 Line of Sight, Fresnel Zone, Polarization and MIMO 3.3 Antenna Types, Charts, Cables and Lightning Protection
4 Industry Bodies and Legacy PHY
4.1 Industry Organizations and OSI Layers 4.2 Legacy 802.11 PHY Standards 4.3 Spread Spectrum, Modulation and MCS
5 Modern 802.11 PHY and Channel Concepts
5.1 Wi-Fi 4 HT and Wi-Fi 5 VHT 5.2 Wi-Fi 6 and Wi-Fi 6E High Efficiency 5.3 Primary Channels, OBSS, Throughput and Guard Interval
6 Spectrum Rules and WLAN Use Cases
6.1 Frequency Bands, DFS and Transmit Power Control 6.2 WLAN, Bridging, Peer-to-Peer and Mesh
7 802.11 Service Sets and Framing
7.1 Stations, BSS, ESS and the Distribution System 7.2 MSDU, MPDU, PSDU, PPDU and Aggregation 7.3 MAC Frame Format and Addressing
8 Frame Types, Discovery, and Association
8.1 Management, Control and Data Frames 8.2 Scanning, Authentication and Association
9 Channel Access, MAC Operations, and Devices
9.1 DCF, EDCA, RTS/CTS and Interframe Spaces 9.2 Roaming, Power Save and Protection Mechanisms 9.3 Access Points, Controllers and Client Devices
10 PoE, Architectures, and Proprietary Features
10.1 Power over Ethernet, PSE and Power Budgets 10.2 Centralized vs Distributed Forwarding and Network Planes 10.3 Airtime Fairness, Band Steering and RRM
11 WLAN Design and Supporting Services
11.1 Data, Voice, Video and Legacy Client Design 11.2 High-Density, Location Services and Guest Access 11.3 DHCP, DNS, Time, VLANs and AAA
12 WLAN Security
12.1 Weak and Deprecated WLAN Security 12.2 AES, WPA2-Personal and WPA2-Enterprise 12.3 WPA3, SAE and Opportunistic Wireless Encryption 12.4 PMF, Fast Roaming, WIPS and Secure Management
13 RF Validation Surveys and Tools
13.1 Post-Implementation Validation Surveys 13.2 Application and Performance Testing 13.3 Validation Tools: Survey, Protocol and Spectrum
14 Interference, Troubleshooting, and Common Faults
14.1 Co-Channel Contention vs Adjacent Channel Interference 14.2 Protocol Analyzers, Spectrum Analyzers and Monitoring 14.3 Common WLAN Faults and Hidden Nodes
13.1 Post-Implementation Validation Surveys
Key Takeaways Explain This Topic AI
A post-implementation validation survey measures the installed WLAN against the written design and SLA for coverage, throughput, roaming, and connectivity.
Predictive modeling and AP-on-a-stick measurements support design; they do not replace after-install proof of the production ESS.
Passive surveys listen to beacons without joining; active surveys associate and test connectivity, rates, throughput, and roams.
RSSI, SNR, and data-rate heat maps answer different questions; a green RSSI layer is not proof of usable performance.
Roaming is documented on the walking paths clients actually use, not only at static desk samples.
Last updated: September 2026
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 ExamFinch 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
Method When you use it What the station does What a good result can support What it cannot replace
Predictive Before install No live RF; software models loss and antennas Iterating access-point count, power, and channel ideas Proof that the installed network meets the SLA
AP-on-a-stick On site during design Measures a temporary access point at a candidate location Real-building loss from that mounting point A finished multi-AP validation of the production ESS
Passive Spot-checks or post-install mapping Listens to beacons (and other frames it can decode) without joining Heard BSSIDs, channels, and beacon RSSI on a floor plan Association, addressing, throughput, or roam success
Active Especially post-install proof Associates and sends test traffic Connectivity, selected data rates, retries, measured throughput, roam events A spectrum picture of energy the 802.11 card never decoded
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.
- Heat-map layer Plots Supports Does not prove
- RSSI Received power That a signal arrived at the adapter Usable SNR, selected MCS, or application success
- SNR Signal above noise That a higher rate is plausible Uplink symmetry or free airtime
- Data rate Selected PHY/MCS What the link attempted Application goodput after loss and contention
- Throughput (active test) Measured goodput Bits delivered in that test Every client at every hour
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.