Proposed Modifications to 802.11e-D4.2 Block ACK

1. Proposed Modifications to 802.11e-D4.2 Block ACK • Carlos Rios • RiosTek LLC

2. D4.2 Block ACK Summary • Block ACK per 802.11e-D4.2 is a relatively involved protocol to allow a QSTA to burst transmissions to another QSTA while deferring any and all associated ACKs until after a later (Block) ACK request. • Upon association, sender gleans from (Association frame) Capabilities Info field that candidate receiver is capable of Block ACK (BA) • Block ACK is set up, characterized and torn down with Action Frames:Sender transmits ADDBA Request to set up BA with receiverReceiver responds with ADDBA Response to announce its BA capabilities • Sender and Receiver define Tx, Rx Buffer sizes and otherwise prep for BA DELBA Request lets the sender tear down previously established BA capability • Once BA is set up, sender advertises any transmitted frames subject to BA by setting an appropriate flag in the packet MAC Header Frame Control field • Keeps track of all buffer sizes, etc so to not send too many packets, etc • BA-able frames are burst transmitted, separated by SIFS if within one TXOP • Done transmitting the burst, Sender issues BlockACK Request Control frame • Receiver immediately responds with a Block ACK or an ACK • The ACK lets him mark time until he’s done preparing a real Block ACK • Real Block ACK ready, receiver transmits it ASAP (during his own TXOP) • Sender needs to ACK this Group ACK • Sender can then initiate another burst at his convenience

3. Unbundle Block ACK from QoS • BA functionality should be available to all stations, not just QSTAs • Block ACKs should be allowed under DCF rules • Reclassify ADDBA Request, ADDBA Response and DELBA Request as new category “BA Action Frames” • Remove them from the QOS Action Frame class • As TXOPs don’t apply in DCF, finesse the SIFS interframe spacing issue • Use SIFS to separate GA-able packets whenever possible • If don’t/can’t use SIFS, accept possibility of losing medium access to DCF contender

4. Proposed Block ACK Modifications • Modified Block ACK is a relatively involved protocol to allow a STA to burst transmissions to another STA while deferring any and all corresponding ACKs until after a later (Block) ACK request. • Upon association, sender gleans from (Association frame) Capabilities Info field that candidate receiver is capable of Block ACK • Block ACK is set up, characterized and torn down with Action Frames:Sender transmits ADDBA Request to set up BA with receiver Receiver responds with ADDBA Response to announce its BA capabilities • Sender and Receiver define Tx, Rx Buffer sizes and otherwise prep for BA DELBA Request lets the sender tear down previously established BA capability • Once BA is set up, sender advertises any transmitted frames subject to BA by setting an appropriate flag in the packet MAC Header Frame Control field • Keeps track of all buffer sizes, etc so to not send too many packets, etc • Block ACKable frames are transmitted, separated at a minimumby SIFS • Done transmitting the burst, Sender issues Block ACK Req Control frame • Receiver immediately responds with a Block ACK or an ACK • The ACK lets him mark time until he’s done preparing a real Block ACK • Real Block ACK ready, receiver transmits it as soon as possible • Sender needs to ACK this Block ACK • Sender can then initiate another burst at his convenience

5. Proposed Block ACK Modifications Summary • The modified BA remains a complicated protocol, but now allows non-QoS STAs to burst transmissions to each other. • Candidate normative text revisions to 802.11e-D4.2 are contained in document 03/052r3 • “QSTA” replaced by “STA” throughout • Additions, clarifications regarding BA under DCF • BA frames moved from the “QoS action” category to a new “BA action” category • Substantial revisions made to section 7, 9.11, 10.3.16 and 11.5

6. Motion • “Move to instruct the Technical Editor to work with the author and the interested parties to incorporate modifications contained in document 03/52r3 into the successor to 802.11e-D4.2”