A transit-hub capture shows an unusually high ratio of RTS/CTS relative to data frames. What expert interpretation should guide next steps?
Select an answer to reveal the explanation.
Short Explanation
RTS/CTS is the polite 'clear the intersection' dance before big deliveries—useful when someone is hidden around the corner, expensive when everyone does it all day. At the transit hub, treat a flood of those frames as protection or hidden-node behavior eating airtime.
Full Explanation
A transit-hub capture with an unusually high RTS/CTS-to-data ratio often indicates protection mode or hidden-node mitigation consuming airtime. Expert interpretation correlates RTS/CTS volume with PHY mix (legacy protection) and topology (hidden nodes) before blindly changing channels. RTS/CTS can be appropriate, but excessive overhead deserves design attention in busy civic hubs.
Claiming RTS/CTS storms always mean the DHCP pool is exhausted relocates an airtime symptom to Layer-3 addressing. Saying any RTS frame proves WPA3 SAE failed and the SSID must revert to WEP confuses protection frames with authentication and proposes an insecure fix. Asserting CTS frames are multicast only and never consume usable airtime understates medium occupancy of protection exchanges.
Exam caveat: high RTS/CTS is a clue—diagnose protection versus hidden node before channel churn. Operational check: measure RTS/CTS ratio on the transit-hub SSID, check for legacy rates forcing protection and for cell sizes creating hidden nodes, then adjust rates/cell design and remeasure airtime overhead. If protection overhead drops after raising minimum rates, keep that before/after airtime chart as the transit-hub standard for legacy pruning debates.