A fleet of county tablets shows persistently low MCS despite excellent SNR and clean spectrum at the AP. Packet captures implicate the client driver. What is the most appropriate remediation focus?
Select an answer to reveal the explanation.
Short Explanation
When the air is clean and the AP looks fine but the tablet crawls, the bug is often in the client software. Patch the driver or image instead of cranking RF knobs forever.
Full Explanation
When a fleet of county tablets shows persistently low MCS despite excellent SNR and clean spectrum at the AP, and captures implicate the client driver, remediate the client driver or firmware image rather than only retuning RF. Client stacks can select poor rates or fail aggregation independently of RF cleanliness. Increasing AP transmit power until MCS rises does not fix a driver rate-control bug and may worsen CCI. Widening channels to 160 MHz on every AP changes reuse without addressing the client defect. Disabling A-MPDU so low MCS frames retry individually worsens efficiency. Exam caveat: RF-clean low MCS often points to client/driver issues—do not infinite-loop RF changes. Operational check: pilot a fixed driver image on a tablet subset, compare MCS and goodput, then push the municipal standard image fleet-wide. In municipal WLAN and IoT operations, record the chosen control and the rejected alternatives in the change ticket so on-call staff understand which failure modes were avoided for city services. Re-validate after the next maintenance window that the same control still holds under the current platform code, device mix, and civic event calendar used by the wireless team.