50 likes | 165 Views
Proposed Modifications to 802.11e-D4.0 Group ACK. Carlos Rios RiosTek LLC. D4.0 Group ACK Summary.
E N D
Proposed Modifications to 802.11e-D4.0 Group ACK • Carlos Rios • RiosTek LLC
D4.0 Group ACK Summary • Group ACK per 802.11e-D4.0 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 (Group) ACK request. • Upon association, sender gleans from (Association frame) Capabilities Info field that candidate receiver is capable of Group ACK • Group ACK is set up, characterized and torn down with Action Frames:Sender transmits ADDGA Request to set up GA with receiverReceiver responds with ADDGA Response to announce its GA capabilities • Sender and Receiver define Tx, Rx Buffer sizes and otherwise prep for GA DELGA Request lets the sender tear down previously established GA capability • Once GA is set up, sender advertises any transmitted frames subject to GA by setting an appropriate flag in the packet MAC Header QOS Control field • Keeps track of all buffer sizes, etc so to not send too many packets, etc • GA-able frames are burst transmitted, separated by SIFS if within one TXOP • Done transmitting the burst, Sender issues GroupACK Request Control frame • Receiver immediately responds with a Group ACK or an ACK • The ACK lets him mark time until he’s done preparing a real Group ACK • Real Group 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
Unbundle Group ACK from QoS • GA functionality should be available to all stations, not just QSTAs • Group ACKs should be allowed under DCF rules • Don’t use QOS Control field to advertise GA parameters • Replace “Order” bit (B15) in MAC Header Frame Control field with a “GA” bit set upon a Group ACK-able packet transmission • Reclassify ADDGA Request, ADDGA Response and DELGA Request as new category “GA 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
Proposed Group ACK Modifications • Modified Group 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 (Group) ACK request. • Upon association, sender gleans from (Association frame) Capabilities Info field that candidate receiver is capable of Group ACK • Group ACK is set up, characterized and torn down with Action Frames:Sender transmits ADDGA Request to set up GA with receiver Receiver responds with ADDGA Response to announce its GA capabilities • Sender and Receiver define Tx, Rx Buffer sizes and otherwise prep for GA DELGA Request lets the sender tear down previously established GA capability • Once GA is set up, sender advertises any transmitted frames subject to GA 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 • Group ACKable frames are transmitted, separated at a minimumby SIFS • Done transmitting the burst, Sender issues GroupACK Request Control frame • Receiver immediately responds with a Group ACK or an ACK • The ACK lets him mark time until he’s done preparing a real Group ACK • Real Group ACK ready, receiver transmits it as soon as possible • Sender needs to ACK this Group ACK • Sender can then initiate another burst at his convenience
Proposed Group ACK Modifications Summary • The modified GA remains a complicated protocol, but now allows non-QoS STAs to burst transmissions to each other. • Candidate normative text revisions to 802.11e-D4.0 are contained in document 03/052r0