Municipal fleet tablets show low throughput despite high RSSI, and captures show missing or failed Block Ack sessions. What is the most likely protocol root cause to investigate?
Select an answer to reveal the explanation.
Short Explanation
Strong bars with slow apps is the classic 'loud radio, broken handshake' story—like shouting across a quiet street but never getting a signed receipt for the package. Fix the Block Ack session that makes aggregation work, not the RSSI meter.
Full Explanation
Municipal fleet tablets showing low throughput despite high RSSI, with captures showing missing or failed Block Ack sessions, most likely point to failed or missing Block Ack undermining A-MPDU efficiency even though RF signal strength looks strong. High RSSI does not guarantee aggregation health; without BA, large aggregates cannot complete efficiently and airtime efficiency collapses. Expert root-cause work inspects BA setup/teardown and retry patterns before blaming AAA or DFS.
Claiming high RSSI always means the RADIUS shared secret is wrong and EAP must be disabled confuses RF/aggregation with authentication. Saying missing Block Ack proves DFS radar and requires abandoning 5 GHz citywide invents a regulatory conclusion from an aggregation symptom. Asserting throughput at high RSSI can only fail if the default gateway MTU is below 64 bytes ignores air-side aggregation failure modes.
Exam caveat: separate RF adequacy (RSSI/SNR) from protocol efficiency (BA/A-MPDU) on civic fleet performance tickets. Operational check: filter tablet captures for ADDBA/BA failures, compare good versus bad tablets’ NSS and BA state, and remediate client/AP BA interoperability before changing RADIUS or abandoning 5 GHz.