11.1 Data, Voice, Video and Legacy Client Design
Key Takeaways
- Coverage asks whether a station can maintain a usable RF link; capacity asks whether that BSS still has airtime left after client count, retries, protection, and application bitrate
- Voice over WLAN is commonly engineered for higher SNR, lower retries, and more cell overlap than bulk data so a roam finishes inside a talkspurt; CWNP does not publish official SNR or overlap SLAs on CWNA-109
- Interactive video behaves like a delay-sensitive stream on WMM AC_VI; buffered signage is mostly an airtime problem, and multicast video often transmits at a basic rate
- A legacy 802.11b/g station taxes every neighbor: slow PHY frames occupy the medium longer, and ERP protection adds CTS-to-Self or RTS/CTS at DSSS/CCK rates
- Airtime fairness schedules equal time rather than equal frame counts; disabling 802.11b rates and raising basic rates shrinks the tax, but only after coverage at those rates is verified
Northbridge Medical Group is replacing clinic Wi-Fi. The same ESS must carry EHR laptops, voice badges at the nurses’ station, a telehealth cart, waiting-room signage, and a few 802.11g barcode scanners in the pharmacy. CWNA-109 Objective 4.3.1 is how RF and MAC design change when the application changes. Objective 4.3.3 is what happens when a slower PHY still shares that medium. Coverage, roaming, and throughput are the three lenses the objective names; this section teaches how to use them together.
This OpenExamPrep section is independent CWNA-109 study material by OpenExamPrep. It does not claim CWNP approval, partnership, or exact equivalence with CWNP training.
Coverage is not capacity
Coverage answers: can the station hear an AP, and can the AP hear the station, with enough signal-to-noise ratio (SNR) to associate and keep exchanging frames? You walk the floor with a survey tool, look at RSSI and SNR, and fill holes. Uplink matters as much as downlink. A ceiling AP at 20 dBm EIRP can look loud on a laptop heatmap while a 15 dBm voice badge still fails to reach the AP from the far exam room.
Capacity answers: once those stations associate, is there enough airtime for the offered load? Airtime is the scarce resource. It is consumed by client count on a channel (including neighboring BSSs — co-channel contention), PHY rate, retransmissions, management frames, protection frames, and the application’s packet rate. A coverage-only design uses few APs at high power. The heatmap is green. At noon, eighty laptops join one BSS, retries climb, and the help desk hears “Wi-Fi is down.” The radio is up. Capacity is gone.
A capacity design uses more APs, lower transmit power, smaller cells, and a channel reuse plan so each BSS serves fewer stations. You still cannot starve SNR to chase capacity. You size the cell for load, then confirm the SNR floor inside that smaller cell.
| Question | Coverage-first design | Capacity-first design |
|---|---|---|
| Primary metric | RSSI / SNR floor on the map | Airtime, clients per BSS, retry %, application success |
| Typical AP count | Fewer, larger cells | More, smaller cells |
| Typical AP power | Higher, to paint walls | Lower, to contain the cell |
| Classic failure | Hole in the map, failed association | Green map, terrible throughput |
| Who it serves | Low-density offices, coverage-first storage | Clinics, classrooms, open offices |
Trap: raising AP power to fix slowness. Higher power enlarges the cell, pulls more clients onto one BSSID, increases overlap with same-channel neighbors, and often raises retries. Power is a coverage knob. Density is a cell-size and reuse problem. High-density tactics belong in section 11.2; the same trap already appears in mixed application design.
Data, voice, and video want different RF quality
IEEE 802.11 does not define one SNR that “passes the exam,” and CWNP does not publish official numeric SNR, RSSI, retry, or overlap SLAs in the CWNA-109 objectives. Objective 4.3.1 asks you to describe design considerations for data, voice, and video — coverage, roaming, and throughput — not to recite an unpublished score table. The figures below are common engineering practice used by WLAN designers and vendors. Treat them as rules of thumb you can defend in a design review, not as CWNP official cut scores.
Data (best effort)
EHR queries, file sync, email, and web are bursty. TCP retransmits hide some loss. A one-second roam stall is annoying, not a dropped call. Common practice is a cell-edge SNR around 20 dB and an RSSI floor near −70 dBm on 5 GHz, with retry rates allowed to run higher than voice as long as the application still meets the business need. Overlap can be lower than a voice design because a short roam gap is usually survivable. The meeting point of coverage and capacity is the minimum data rate you will permit. If the cell edge falls to 6 Mbps OFDM, each TCP segment occupies a long airtime even though the heatmap still looks associated.
Voice
Voice over WLAN is bidirectional, delay-sensitive, and jitter-sensitive. Codec packets (often every 20 ms) ride WMM AC_VO. A lost burst is a click. A slow roam is a dropped call. Common engineering practice — again, not a CWNP-published SLA — includes cell-edge SNR around 25 dB, RSSI near −65 dBm on the bands the handset actually uses, retransmission rates often held under about 10% (many voice designs aim lower), and cell overlap of about 20% or more so the handset hears the next BSSID before the current SNR collapses. Fast roam features (802.11r / 802.11k / 802.11v, opportunistic key caching) must exist on both infrastructure and handsets; the client still decides to roam. Keep the voice SSID on the same subnet across APs when you can. A Layer 3 roam that waits on DHCP can blow the delay budget even when RF looks perfect. Power-save must not delay downlink talkspurts; voice handsets typically need U-APSD / WMM-PS, not a long DTIM sleep.
ITU-T G.114’s well-known about 150 ms one-way delay budget is telephony practice, not a CWNP exam constant. Use it only to explain why roam plus codec plus jitter buffer has no spare seconds.
Video
One-way digital signage can buffer. Interactive telehealth cannot. Treat interactive video closer to voice: WMM AC_VI, cleaner SNR, controlled jitter, and enough overlap for a camera cart rolling between rooms. Treat buffered video closer to high-throughput data, but remember large frames still burn airtime. Multicast video is a special tax: group frames often go at a basic rate, so one stream can occupy the cell like a legacy client. Many designs unicast the stream or use a vendor multicast-to-unicast conversion.
| Application | Delay / loss tolerance | Typical WMM AC | RF quality vs bulk data | Overlap vs data | Common-practice cell edge (not CWNP official) |
|---|---|---|---|---|---|
| Bulk data | High (TCP recovers) | AC_BE | Baseline | Lower | ~20 dB SNR, ~−70 dBm |
| Buffered video | Medium | AC_VI or AC_BE | Medium–high (airtime) | Medium | Throughput-limited |
| Interactive video | Low | AC_VI | Higher | Higher | Often near voice |
| Voice | Very low | AC_VO | Highest | Highest (~20%+ overlap) | ~25 dB SNR, ~−65 dBm |
Northbridge’s EHR laptops can live on a data-grade cell. The voice badges cannot. If you survey only for −70 dBm data coverage, the badges roam late on the same APs.
Cell overlap and roaming
Overlap is the region where a station hears two viable BSSIDs. Too little overlap: the station holds a dying AP (sticky client) or drops before the next AP is a candidate. Too much overlap on the same channel: two APs hear each other and contend. Voice designs commonly use more overlap than data (the 20%+ rule of thumb) because the roam must finish inside a talkspurt. Overlap is AP placement, antenna pattern, and power set so the next cell appears before this cell dies — not “turn every AP to maximum.” Matching SSID and security across the ESS is required or the client starts a new network selection instead of a roam.
Roam quality is also a client problem. Two badges from different vendors will leave at different RSSI values. Validate the actual handset, not a laptop survey adapter, before you call the RF design finished.
Supporting legacy 802.11 devices (Objective 4.3.3)
A legacy station is any client whose PHY is older or slower than the BSS majority: original DSSS, HR-DSSS 802.11b, ERP 802.11g, or even an HT scanner stuck on 2.4 GHz with 20 MHz and one spatial stream. They hurt in two mechanical ways.
Slow PHY occupies the medium. Airtime is roughly frame size divided by PHY rate. An 802.11b frame at 1 Mbps occupies on the order of ten times the airtime of a 6 Mbps OFDM frame of similar size, and far more than a Wi-Fi 6 A-MPDU. Beacons and probe responses sent at a 1 or 2 Mbps basic rate tax every client in the BSS, not only the scanner.
Protection. When OFDM (802.11g/n/ax) shares 2.4 GHz with DSSS/CCK, ERP protection turns on. RTS/CTS or CTS-to-Self at a legacy rate sets NAV so the 802.11b radio does not transmit on top of an OFDM PPDU it cannot decode. Those control frames are themselves slow. One pharmacy scanner can put an entire clinic 2.4 GHz cell into protection mode. HT/VHT mixed-mode protection repeats the same idea for later PHYs: a legacy-readable reservation before a frame older radios cannot demodulate.
Airtime fairness (a common proprietary scheduler; Objective 4.4 covers the feature family) gives stations equal time, not equal frame counts. Without it, the slow client’s long frames starve fast clients. With it, the scanner still gets a share, but laptops keep most of the airtime. Airtime fairness is mitigation, not a reason to leave 802.11b enabled everywhere.
Design moves for mixed clients
- Disable 802.11b rates (1 / 2 / 5.5 / 11 Mbps) when remaining devices do not need them.
- Raise minimum mandatory / basic rates (for example 12 or 24 Mbps OFDM) so management frames shrink and the usable cell edge moves in — only after you verify coverage at that rate.
- Prefer 5 GHz and 6 GHz for capable clients; reserve 2.4 GHz for genuine legacy IoT if you must.
- Put irreplaceable scanners on a separate SSID and VLAN with its own rate set so protection does not tax the EHR SSID.
- Do not confuse “backward compatible” with “free.” Compatibility is paid in airtime.
Worked airtime sketch (illustrative, not a CWNP formula)
A 1500-byte MSDU is 12 000 bits. At 6 Mbps the payload occupies about 2 ms before preamble and ACK. At 1 Mbps the same payload occupies about 12 ms. Add a CTS-to-Self at 2 Mbps and you have spent more time protecting the frame than a Wi-Fi 6 client would spend sending several aggregated MPDUs. That is why one leftover 802.11b client can collapse a busy 2.4 GHz BSS even when “only one old device” is associated.
On the exam
- Coverage ≠ capacity. Green RSSI with high retries is a capacity miss.
- Voice wants better SNR, lower retries, more overlap, and faster roams than bulk data. If you quote 25 dB or 20% overlap, label them common engineering practice, not CWNP official numbers.
- Interactive video is closer to voice; buffered video is an airtime problem; multicast at a basic rate is a hidden legacy tax.
- Legacy design is slow PHY plus protection overhead. Airtime fairness and disabled b-rates are the usual controls.
- Sticky clients and DHCP-on-roam are application killers even when the heatmap is green.
Key Takeaways
- Design the cell for the hardest application on that SSID, not for the average laptop.
- Overlap is a roam budget; AP power is not a substitute for placement.
- Every legacy rate you leave enabled is a tax on every newer station that shares the channel.
Northbridge’s clinic heatmap is green at about −65 dBm, yet EHR laptops feel slow at noon when eighty devices share one BSS. What design mistake does that pattern indicate?
A voice-badge pilot fails with dropped calls during walks between exam rooms, while laptops on the same APs are only briefly sluggish. Which design change matches common voice engineering practice, and how must those numbers be treated on CWNA-109?
Pharmacy 802.11b scanners remain on the clinic 2.4 GHz SSID. After they associate, Wi-Fi 6 laptops on the same BSS lose throughput even though only two scanners are present. What is the primary airtime mechanism, and what mitigation should you expect?