10.3 Airtime Fairness, Band Steering and RRM

IEEE 802.11 specifies how stations contend, associate, and encode bits. It does not specify how a vendor should stop a single 802.11b barcode scanner from ruining a lecture hall, how dual-band phones should be nudged onto 5 GHz, or how a building full of APs should pick channels at 2 a.m. Those behaviors live in vendor WLAN features. CWNA-109 objective 4.4 expects you to understand what they do and what they cost, not to configure one company’s CLI. This independent OpenExamPrep section teaches airtime fairness, band steering, dynamic RF (RRM-class features), and the internal control conversations APs use to make those features work.

Airtime fairness

The distributed coordination function is roughly fair among frames, not fair among payload bytes per second. A station at a robust high MCS can deliver a 1,500-byte MSDU in a short airtime. A station stuck at 1 Mbps (legacy DSSS, or a client at the cell edge with retries) occupies the medium far longer for the same MSDU. Because everyone else must wait for that long transmission—and for the retries—one slow client can collapse BSS throughput even when RSSI looks “fine” on the AP.

Airtime fairness (vendor names vary: airtime fairness, airtime scheduling, client fair share) changes the scheduler so stations receive a more even share of channel time, not an equal share of megabits. A slow client still gets to talk; it simply cannot queue unbounded long frames that starve high-rate clients. Typical mechanisms:

• Track airtime used per client or per SSID and defer additional transmits from a hog.
• Prefer aggregation (A-MPDU) and appropriate MCS rather than letting a client retry a huge frame at the lowest rate forever.
• Sometimes isolate legacy rates (disable 1/2/5.5/11 Mbps) so the worst transmitter is less catastrophic—related, but not the same feature.

What airtime fairness is not:

• It is not a promise of equal throughput. A 6 GHz 80 MHz client will still move more bytes in its time slice than a 20 MHz 2.4 GHz IoT device.
• It is not IEEE 802.3 PoE classification.
• It cannot fix a design with one AP, 200 associated clients, and a 20 MHz overlapping 2.4 GHz channel. Scheduling cannot create spectrum.

When you enable it, watch for latency-sensitive scanners that were accidentally classified as hogs, and for mesh backhaul radios that must not be “fairness-throttled” the same way as clients. Test voice and roaming; a too-aggressive scheduler can delay a small VoIP frame behind a fairness deficit counter.

Band steering

Most phones and laptops are dual-band (2.4 GHz + 5 GHz) or tri-band with 6 GHz (Wi-Fi 6E). The 2.4 GHz band has only three usable 20 MHz channels in most regulatory domains, is crowded with Bluetooth and microwaves, and still attracts clients because it often shows a higher RSSI through walls. If every dual-band laptop camps on 2.4 GHz, you have built an interference-limited BSS on purpose.

Band steering (band select, prefer 5 GHz, 6 GHz steering) encourages capable clients onto the higher band:

• Ignore or delay probe responses on 2.4 GHz for clients that recently probed on 5 GHz.
• Respond first on 5 GHz / 6 GHz, or use 802.11v BSS transition management where clients honor it.
• Advertise slightly different neighbor reports so the client’s algorithm prefers the 5 GHz BSSID.

Steering must be honest about coverage. If 5 GHz does not reach the same seats as 2.4 GHz—because 5 GHz attenuates more through walls—steering creates a coverage hole: the phone shows full bars on 2.4, gets refused or delayed, then sticks on a distant 5 GHz AP at low MCS. That looks like “Wi-Fi is broken.” Design 5 GHz (and 6 GHz) first, then steer. Leave 2.4 GHz for IoT, printers, and the few single-band clients; do not steer those devices onto a band they cannot use.

6 GHz steering is the same idea with a stricter client capability check (6E device, preferred scanning channels, and often WPA3). Do not treat 6 GHz as a CWNA-109 PHY deep dive here; treat it as another band you may prefer when the client and regulatory domain allow it.

Dynamic power, dynamic channel, and RRM

Static channel and power plans still win in stadiums, high-density lecture halls, and any site where you measured every AP. Most offices instead run Radio Resource Management (RRM)-class features: the system measures the RF neighborhood and changes channel and transmit power so APs are not all on channel 36 at 20 dBm.

Teach the two core loops:

Dynamic channel assignment. APs report neighbors (other BSSs, sometimes off-channel scans). The controller or a distributed algorithm picks a channel that reduces co-channel and severe adjacent overlap, respecting DFS rules on 5 GHz. The system may change channels on a schedule (off-hours) or after a radar event. Flapping—channel changes every few minutes—destroys roaming and voice. Operators set hysteresis, sensitive thresholds, and “anchor” channels for APs that must not move.

Dynamic transmit power (TPC-like behavior in the ESS). If two APs hear each other at −50 dBm, they are over-powered for an office grid: clients roam late, CCI rises, and 5 GHz cells become huge. RRM lowers power toward a target coverage overlap. If an AP fails, coverage hole detection may raise neighbors’ power. Bounds matter: a floor of 8 dBm and a ceiling of 14 dBm often behaves better than “auto 0–20 dBm,” which can create microcells that drop voice or macrocells that reuse one channel across a floor.

RRM is only as good as what the AP hears. An AP on the ceiling hears other APs well and hears clients poorly. Client-aware RRM and additional sensors help, but they do not replace a validation survey. Freeze RRM after a good plan if the algorithm keeps picking a DFS channel that radar then vacates, or if one noisy neighbor (a non-802.11 interferer) makes the algorithm chase ghosts. Spectrum analysis (Domain 6) is how you tell CCI from a microwave; RRM cannot see energy the Wi-Fi radio’s CCA does not classify.

Related knobs often bundled with RRM: load-aware admission, RX-SOP / CCA thresholds (handle with care), and band/channel width changes (20/40/80). Changing width is a capacity versus reuse trade, not a free upgrade.

Internal wireless architecture communication

None of the features above work if APs are isolated radios. Objective 4.4 also wants awareness of how APs talk to controllers and to each other—not packet-by-packet decoding.

AP-to-controller (or AP-to-cloud) control protocols. Lightweight APs maintain a control session (CAPWAP and vendor equivalents, often DTLS-protected) for join, configuration, RF reports, client state, and RRM inputs. That session is the control plane from section 10.2. It is not the same as a user-data tunnel. An AP can locally switch employee traffic and still send neighbor RSSI, radar hits, and client steering hints to the controller every few seconds. If that control path dies, RRM and steering policy freeze at last known config.

AP-to-AP communication. Mesh APs form a backhaul that carries both control and, usually, user data toward a portal AP. Cooperative RF and some fast-roaming designs exchange neighbor information directly between APs (vendor proprietary), reducing controller round trips. Wireless bridges and workgroup bridges similarly use proprietary or 802.11-based links between infrastructure devices. You should recognize that “the WLAN has an internal fabric” without claiming every vendor uses the same Ethernet type.

Security note at awareness level: protect the control channel (DTLS, SSH/HTTPS to controllers, no telnet), restrict which APs may join (certificates), and do not confuse a mesh backhaul SSID with a guest SSID. Rogue APs do not participate in your RRM domain; they only appear as interferers if you measure them.

Feature interactions Harborline actually hits

Harborline enables band steering and airtime fairness on day one, then turns RRM to full auto. Laptops leave 2.4 GHz, which is good, but RRM then drops 5 GHz power so far that steering pushes phones onto APs they can barely decode. Slow edge clients retry, airtime fairness throttles them, and voice complaints spike. The fix is architectural, not a mystery CLI: raise the power floor, stop steering where 5 GHz coverage is thin, and use airtime fairness as a scheduler—not as a substitute for density. Vendor features amplify a good RF design and punish a bad one.

Study these as behaviors you can explain to a design reviewer. If a question names a vendor feature, map it back to airtime, band choice, channel, power, or control-path messaging.