13.2 Application and Performance Testing

Objective 6.3 asks you to test whether the installed WLAN actually delivers the network and the applications the design promised. Coverage maps from section 13.1 tell you whether a signal arrived. This section is about availability and quality: can a real client reach the service, and does that service stay usable under the delay, loss, and capacity the project named? OpenExamPrep treats the numeric voice and throughput examples below as engineering practice. CWNP does not publish those figures as official CWNA-109 cut scores, and you should not memorize them as if they were exam law. The exam skill is choosing the right test and comparing it to the written SLA.

Deep interference classification, full troubleshooting-tool playbooks, and the catalog of common WLAN faults belong in Chapter 14. Use this section to design the proof, not to chase every root cause.

Network and service availability

Coverage means an adapter heard a beacon or reported a minimum RSSI. Connectivity means the client completed association and the security handshake. Availability is stricter: the service the user came for is reachable and usable when the SLA says it must be.

A practical availability sequence looks like this:

1. Associate to the correct SSID on the correct band.
2. Complete Open System plus the 4-way handshake, or 802.1X if that is the design.
3. Receive a usable address on the intended VLAN (DHCP or the intended static policy).
4. Resolve the names the application needs (DNS).
5. Open the transport path to the named service (TCP or UDP to the PBX, electronic-record system, file server, or captive-portal controller).
6. Authenticate to the application if the SLA includes that step.
7. Repeat after a roam and after an idle period, because many failures appear only then.

If any step fails, the WLAN is not available for that service even if the RSSI heat map is green. Classic examples: a voice SSID that associates but has no DHCP pool on the voice VLAN; a guest network whose splash page never loads; a clinical SSID that lands on the data VLAN; a laptop that works while a barcode scanner cannot complete DHCP before its short timer expires.

Availability testing is therefore a service list, not a single ping. Write the services into the validation plan before you walk: voice registration, medication-cabinet reachability, badge-in time clocks, guest Internet, and so on. Test them from the client class that actually uses them. A Windows laptop with a current Intel radio is a poor proxy for a dated Android voice handset or a 2.4 GHz scanner.

Also separate network availability (the 802.11 BSS and the local IP path are up) from service availability (the application or WAN destination is up). A perfect WLAN cannot make a down private-branch exchange answer. Your report should say which layer failed. Otherwise the wireless team inherits every outage in the building.

VoIP testing: MOS, latency, jitter, and loss

Voice over IP is the usual real-time proving ground because talkers notice delay and chop long before a file copy looks slow. Validate voice with four related measurements, not with RSSI alone.

MOS (Mean Opinion Score) is a 1-to-5 quality scale that began as human listening tests. Modern survey and monitoring tools estimate MOS from delay, loss, jitter, and codec behavior (often an E-model / ITU-T G.107 family estimate). As engineering practice, many teams treat about 4.0 or higher as good, about 3.5 as a common enterprise floor, and scores near 3.0 or below as poor. Those bands are project conventions. They are not CWNP official CWNA numbers.

Latency for voice is one-way mouth-to-ear delay, not a casual round-trip ping. ITU-T G.114 describes one-way delay below about 150 ms as essentially transparent for most conversations and treats about 400 ms as a planning limit where interactivity degrades into walkie-talkie turn-taking. The WLAN hop must consume only a fraction of that end-to-end budget. Codec packetization, jitter buffers, WAN circuits, and the far-end handset all spend from the same 150 ms. A 120 ms average ping across the Internet does not prove the wireless hop is healthy, and it is the wrong direction of proof if the SLA is on-campus calling.

Jitter is variation in packet inter-arrival time, not the average delay. A path with a steady 80 ms delay and almost no jitter can sound fine. A path that averages 20 ms but swings from 5 ms to 80 ms will glitch when the jitter buffer overflows or underflows. Many WLAN voice designs target roughly 30 ms of jitter or less, with some teams preferring about 15 ms on the wireless segment. Again: engineering practice, not a CWNP official figure. Jitter buffers trade extra delay for smoothness, so "fixing" jitter by growing the buffer can push you over the latency budget.

Loss is the percentage of voice packets that never arrive in time to be played. Voice codecs conceal tiny random loss and fall apart on bursts. Many designs target under 1% loss, sometimes 0.5%, with burst loss treated more severely than the same average spread out. Uplink retries on the WLAN are a common hidden source: the handset is the weaker transmitter, so the access point's retry counters tell a story a downlink-only test will miss.

How you collect those numbers matters. Options include a dedicated voice handset with its own statistics, survey software in a voice or real-time mode, a synthetic MOS generator, or a real call walked along the roam path. The last option is the most honest for sticky-client and roam-drop failures. Mark voice frames with the intended WMM access category and confirm the DSCP/UP marking survives onto the wired QoS policy. A perfect RF cell with voice dumped into the best-effort queue will still sound like a best-effort network.

Do not declare voice validated because a data RSSI heat map met -67 dBm. Voice usually wants richer secondary coverage, faster roam completion, and stricter loss than a laptop download.

Real-time application testing

Voice is one real-time family. Others include video conferencing, push-to-talk, telemetry, clinical alarms, and interactive collaboration. They share a property: delay variation and loss destroy usefulness before average throughput looks bad.

Video adds uplink camera load and a larger bandwidth floor. A hallway that passes a 64 kbps voice MOS test can still freeze a 1.5 Mbps camera stream. Test both directions. Many complaints are one-way: you hear the far end, they do not hear you, which points at uplink airtime, client power, or a one-way ACL — not at "the Wi-Fi is down."

Collaboration tools multiplex voice, video, and desktop share. Validate the media the SLA named. A slide share that works while the microphone chops is a real-time failure, not a pass.

For any real-time application, match the test to the traffic:

• Packet size and interval close to the codec or app.
• Bidirectional flows, not only server-to-client.
• The same QoS markings the production clients use.
• The roam paths and room types in the design (not only the conference table next to an access point).
• A duration long enough to catch periodic scans, power-save quirks, and neighbor busy seconds.

Capture what failed in user language and in metrics: setup time, one-way audio, frozen video, roam drop, or application re-registration. Those notes become the acceptance record.

Throughput testing that actually proves the WLAN

PHY data rate is not throughput. A client can show 400 Mbps MCS and deliver 40 Mbps of TCP goodput once retries, contention, and TCP overhead finish with it. Goodput is what the SLA should name.

An iPerf-style test — iPerf, iPerf3, or a vendor equivalent — sends TCP or UDP between a client and a known server for a defined time. For WLAN validation:

• Test both directions. The access point often hears clients less well than clients hear the access point. Downlink-only tests hide weak uplinks.
• Use multiple clients. One laptop beside the AP proves almost nothing about cell-edge airtime or a high-density room. Two to several representative stations in the requirement area show contention the design claimed to support.
• Place the server on the LAN (same VLAN or a known wired hop). That isolates the wireless cell plus a short, controlled wired path.
• Run TCP for application-like goodput and UDP when you also need loss and jitter numbers.
• Record RSSI, SNR, retry percentage, MCS, band, and channel width at each test point so a low Mbps result can be interpreted later.

A project manager who holds up a phone in the lobby and shows 180 Mbps on a public speedtest has not validated the WLAN. That number includes the WAN circuit, the Internet path, and a content-delivery server you do not control. It also samples one client in the strongest part of one cell. The design's promise was almost certainly "N Mbps at these locations with these client counts," which is a different experiment.

Duration and timing matter. A three-second burst can miss a microwave cycle, a neighbor scan, or a roam. Run long enough for the SLA's averaging window, and retest during occupied hours if the design assumed occupied hours. Keep the test adapter honest: a 6 GHz-capable laptop is not a 2.4 GHz handheld fleet. If the SLA names both, test both.

When throughput fails, this chapter's job is to record the failure against the requirement. Protocol captures and spectrum views (section 13.3) explain mechanism. Wired bottlenecks, Power over Ethernet starvation, and WAN congestion are common non-RF causes — Chapter 14 catalogs those faults. Do not "fix" a failed capacity test by pointing the laptop at a website that happens to be faster.

Application and performance testing is how you convert a pretty heat map into an acceptance decision. Availability proves the service path exists. Voice and other real-time tests prove that path stays conversational. Throughput tests prove the capacity the design sold. None of those proofs is a single Internet speedtest.