| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
| --- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
Hi All, I am initiating this email discussion to solicit feedback (if any) on my REVme contribution which resolves CID 3014: https://mentor.ieee.org/802.11/dcn/22/11-22-2206-03-000m-lb270-resolution-for-cid-3014.docx To give a brief background: Today, in baseline spec, ADDBA Request frame is overloaded. It can be used to setup a new block ack agreement, modify the parameters of an existing agreement, and when the negotiated BA
is a protected BA agreement, used to advance the WinStartR & WinStartB (since BAR is not protected). This overloading of ADDBA Request creates an ambiguity at the receiver when the ADDBA Request frame is receiving for an existing protected BA agreement - i.e.,
whether it is being sent for advancing the windows or to modifying the parameters of the BA agreement.
TGm had considered this topic during the previous round (while discussing one my contributions on protected BA) and the high-level consensus was to define a new Action frame. As a follow-up, I had submitted a comment
against REVme D2.0 (CID 3014) to fix this issue. The above contribution defines a new Action frame dedicated to advance the window at the recipient (and replaces the role of ADDBA Request frame for this purpose). I’d greatly appreciate any feedback or suggestions to improve the contribution. Regards, To unsubscribe from the STDS-802-11-TGM list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM&A=1 |