While validating vendor multi-user features on a council-chamber WLAN, which frames indicate sounding for MU-MIMO or transmit beamforming?
Select an answer to reveal the explanation.
Short Explanation
Beamforming and MU-MIMO need a quick channel 'sonar ping' before the big multi-user send—that’s the NDP sounding sequence. Spot those announcement/NDP frames in the chamber capture and you know the multi-user feature path is actually awake.
Full Explanation
Validating vendor multi-user features on a council-chamber WLAN, frames that indicate sounding for MU-MIMO or transmit beamforming are NDP announcement / Null Data Packet sounding-related frames used for channel sounding before MU-MIMO or TxBF. Sounding estimates the channel so the AP can steer or schedule multi-user spatial streams. Expert validation hunts NDP sequences, not DHCP or TIM bits, as MU sounding proof.
Claiming only DHCP Discover frames prove MU-MIMO because it is negotiated exclusively at Layer 3 relocates a PHY feature to DHCP. Saying Probe Responses with TIM set prove sounding and that sounding never uses NDPs is incorrect. Asserting CTS-to-self alone proves MU-MIMO regardless of any NDP sequence confuses protection with sounding.
Exam caveat: NDP sounding sequences are the air signature of TxBF/MU-MIMO readiness. Operational check: enable MU features on the council-chamber WLAN, capture during multi-client load, confirm NDP announcement/NDP sounding frames, and correlate with vendor MU statistics before accepting the feature. Attach NDP sequence screenshots to the council-chamber MU feature acceptance form alongside vendor dashboard MU counters. If NDP sounding is absent while MU counters claim activity, treat the vendor dashboard as unverified until the council-chamber air capture agrees.