All-acks in the Multi-STA Block Ack¶
The entries¶
A Multi-STA Block Ack (BA type 11) answers the TB PPDUs of UL OFDMA with one Per AID TID Info per station: AID11, Ack Type and TID. Ack Type 0 carries a Starting Sequence Control and a bitmap. Ack Type 1 carries neither: with TID 0–7 it acknowledges a single MPDU of that TID, with TID 15 a management frame, with TID 14 every MPDU of the A-MPDU that elicited it, an all-ack. A client that can take all-acks says so with All Ack Support in its HE MAC Capabilities. The sensor does not decode the TB PPDU, so an all-ack does not say how many MPDUs it held; the sequence numbers the flow's next BA moves past do (definition).
The recordings on 2026-10-22¶
No recording has an entry with Ack Type 1. The 23 sessions hold 271 Multi-STA entries, every one with a bitmap; 255 of them are in testlab-co-channel, from the U7 of AP A (…:02:c1) to a second station on it (…:01:10, AID 5), not the session's client. The U7 sent the bitmap also when every MPDU arrived (0f00…, 3f00…), and it starts each BA, compressed or Multi-STA, at the first sequence number of the A-MPDU that elicited it, one after the end of the BA before, or behind it where the A-MPDU leads with a retransmission, with only that A-MPDU's MPDUs in the bitmap.
The station's uplink there: 14,290 compressed BAs on TID 0, 138 on TID 1, 100 on TID 6, and the 255 Multi-STA BAs on TID 0, after 563 Basic triggers that name AID 5 (1,130 BFRP, 5 BSRP).
Method¶
AllAckReplayTests replays the station's BAs from the AP through BlockAckTracker, as recorded and with every BA whose bits are set from the first up to the highest turned into an all-ack: only the Multi-STA BAs, what an AP that answers with all-acks would have sent for the same TB PPDUs, or every BA, as if the whole uplink went in TB PPDUs to such an AP. The recorded bitmaps are the truth. The rule before the estimate, each all-ack one MPDU, runs in the same replay as a single ack of a TID the station sends no data on, which no BA's gap holds; on the engine of ab40eeb that gives what the engine of 20e8710 gave with its all-acks.
cd app/LinksideKit
LINKSIDE_ALL_ACK=$PWD/../../testdata/sessions/testlab-co-channel/capA.pcap LINKSIDE_ALL_ACK_STATION=02:00:00:00:01:10 LINKSIDE_ALL_ACK_AID=5 swift test --filter AllAckReplayTests
Results¶
| BAs as all-acks | All-acks | Delivered | Failed | UL success, the estimate | Delivered, one MPDU each | UL success, one MPDU each |
|---|---|---|---|---|---|---|
| none, as recorded | 0 | 91,998 | 335 | 99.64 % | – | – |
| the Multi-STA BAs | 247 | 91,992 | 337 | 99.64 % | 90,785 | 99.63 % |
| every full BA | 14,514 | 77,787 | 376 | 99.52 % | 16,394 | 97.76 % |
With every full BA an all-ack, the estimate misses 14,211 of the 91,998 MPDUs, nearly all in two runs of all-acks:
- 14 s without a loss, 185.6 to 199.7 s: 1,902 all-acks of 12,981 MPDUs, more than three laps of 4096. The gap counts what is left after the laps, 1,038.
- 3.4 s up to a BA without an acknowledged bit at 247.3 s, the answer to a BAR of the station outside the capture: 492 all-acks of 3,343 MPDUs, which stay one MPDU each.
The rest, 467 MPDUs, lie outside the two runs; 354 of them are held by the 1,300 all-acks before a flow's first BA and after its last.
The failures more, 2 and 41, are MPDUs an all-ack held. At 213.8 s the U7 sent a BA from 3725, 17 behind the BA from 3742 before it, for an A-MPDU that led with a retransmission of 3725, with only that A-MPDU's MPDUs in the bitmap: its 0 bits include 3742. As recorded, the BA from 3742 acknowledged it and it keeps that outcome, the BA from 3725 being for an older window (definition); with the BA from 3742 an all-ack, no BA settled 3742, and the 0 bit counts it as lost. So at 21 BAs with every full BA an all-ack and at 2 with the Multi-STA BAs, each leading with a retransmission right after an all-ack that held MPDUs past its start. Before the older window, such a BA started the flow over and counted again what the BAs before it had settled: as recorded 215 MPDUs as lost and 86 as delivered, with every full BA an all-ack 166 and 184. The replays then read 550 failures as recorded, 550 and 542, and the estimate missed 98 MPDUs fewer.
What it shows¶
Where an AP answers the TB PPDUs with all-acks and the SU PPDUs with bitmaps, the sequence numbers place nearly every all-ack: 1,207 of the 1,213 MPDUs the rule before missed. Where every BA without a loss is an all-ack, the BAs with a loss come seldom on a clean link, and a run between two of them can be longer than a lap: the estimate then reads low, in this replay 0.1 point, against 1.9 points one MPDU each. A run is long where nothing is lost, so what the estimate misses never lies next to a loss within the run. Where a BA that leads with a retransmission follows an all-ack, what the all-ack held past the BA's start counts as lost: 41 MPDUs in this replay, 0.05 point.
Not tested: an AP that answers with all-acks, a client that gives up MPDUs under UL OFDMA, and a BAR of the client between all-acks (the plan, docs/status.md).