180 likes | 200 Views
This document provides clarification on some HCF frame exchange rules in the 802.11e/D1.3 and D1.4 standards, including response depending on frame subtypes, error handling, and the usage of ACK and QoS.CF-ACK frames.
E N D
Clarification on Some HCF Frame Exchange Rules Sunghyun Choi and Javier del Prado Philips Research USA sunghyun.choi@philips.com Srinivas Kandala and Ken Nakashima Sharp Labs srini@sharplabs.com S. Choi, Philips & S. Kandala, Sharp
Outline • Response depending on frame subtypes • ACK or not • ACK vs. QoS CF-ACK • Error handling • SIFS or PIFS • RTS/CTS during CFP and CFB S. Choi, Philips & S. Kandala, Sharp
Changes from 546r0 • 546r0 was based on 802.11e/D1.2 • 546r1 is based on 802.11e/D1.3 and D1.4 S. Choi, Philips & S. Kandala, Sharp
ACK or Not? • Whether different subtypes of Data frames require an acknowledgement is not explicitly specified. • It was more true with 802.11-1999, but we have “No Ack” bit in QoS control field with 802.11e. • Resolution: Clarify that • A data type frame of any subtype with “No Ack” bit set to zero will require an acknowledgement. • QoS CF-Poll and QoS CF-ACK+CF-Poll frames shall always have “No Ack” bit set to one. S. Choi, Philips & S. Kandala, Sharp
QoS CF-ACK & Null requiring ACK ACK QoS CF-Poll QoS Null with No Ack=0 ACK QoS Data + CF-Poll QoS CF-ACK with No Ack=0 S. Choi, Philips & S. Kandala, Sharp
Motion 546-1 • Empower the TGe editor to revise the draft to incorporate the clarification in slide 4 of 546r4. S. Choi, Philips & S. Kandala, Sharp
Usage of NF Bit? • It seems that NF bit is meaningful only if the sender of the QoS Data type frame is the TXOP holder. • However, it is not stated so in D1.3. S. Choi, Philips & S. Kandala, Sharp
Usage of NF Bit? • Resolution: In Table 3.5, specify that • NF bit ‘resv (0)’ for the corresponding cases when the sender is the HC. • The case “QoS Null frames sent by WSTAs” is subdivided into “QoS Null subtype frames sent by TXOP holders”, where the fields are the same as the current content, and “QoS Null subtype frames sent by non-TXOP holders”, where NF bit ‘resv (0)’ and Bits 0-8 ‘reserved (0)’ S. Choi, Philips & S. Kandala, Sharp
Motion 546-2 • Empower the TGe editor to revise the draft to incorporate the modification in slide 7 of 546r3. S. Choi, Philips & S. Kandala, Sharp
QoS CF-ACK or ACK? • Which of QoS CF-ACK or ACK should be used to acknowledge a QoS data reception is not clear. • QoS CF-ACK is a data type with 30 bytes typically, and ACK is a control type with 14 bytes. • As described in 9.10.3.1 of D 1.3, QoS CF-ACK can request a longer TXOP and update the queue status for a TC with HC. • Per 802.11-1999, ACK is used under DCF and CF-ACK is supposed to be used for CF-pollable STAs under PCF. S. Choi, Philips & S. Kandala, Sharp
QoS CF-ACK or ACK? (Cont.) • NF bit of QoS CF-ACK is meaningful only when the sender is the TXOP holder • If sender is not TXOP holder, ACK is equivalent to QoS CF-ACK w/ NF=0 (resv) & No Ack = 1, and either of them can be used. • If sender is TXOP holder, ACK is not equivalent to QoS CF-ACK, so ACK shall not be used. • Resolution: • Clarify the above facts in relevant place(s). S. Choi, Philips & S. Kandala, Sharp
Motion 546-3 • Empower the TGe editor to revise the draft to incorporate the clarification in slide 10 of 546r3. • Passed S. Choi, Philips & S. Kandala, Sharp
PIFS or SIFS after Error? • When an ESTA (including HC) in charge of channel recovery does not start receiving an expected frame within PIFS, it will recover by transmitting a frame after PIFS. • What happens when an erroneous frame is received by such an ESTA is not clear. • An erroneous frame is determined by PHY-RXSTART.indication & PHY-RXEND.indication & FCS check error. S. Choi, Philips & S. Kandala, Sharp
PIFS or SIFS after Error? • Resolution: add the following in 9.10.1.2. • If an erroneous frame determined by an FCS check error after PHY-RXSTART.indicate and PHY-RXEND.indicate is received at the ESTA, which expects a response to its transmission, the ESTA may initiate the recovery by transmitting a frame after SIFS from the end of the last reception. S. Choi, Philips & S. Kandala, Sharp
Motion 546-4 • Empower the TGe editor to revise the draft as instructed in slide 13 of 546r3. • Passed S. Choi, Philips & S. Kandala, Sharp
RTS/CTS during CFP/CFB • RTS/CTS exchange is allowed during both CP and CFP. • However, what happens if the RTS/CTS exchange is not successful under HCFshould be clearly stated. • Apparently, we don’t want the HC or the TXOP holder to go to the back-off when it does not receive a CTS successfully. S. Choi, Philips & S. Kandala, Sharp
RTS/CTS during CFP/CFB (Cont.) • Resolution: add the following in 9.10.3.2. • The HC and TXOP holder after transmitting RTS may recover from the failure of the successful CTS reception by transmitting a frame (1) within PIFS from the end of the RTS transmission if the PHY-CCA-indicate(busy) does not occur, and (2) within SIFS from the end of the last frame reception if the frame after the RTS transmission is received in error determined by an FCS check error after PHY-RXSTART.indicate and PHY-RXEND.indicate. S. Choi, Philips & S. Kandala, Sharp
Motion 546-5 • Empower the TGe editor to revise the draft as instructed in slide 16 of 546r3. • Passed S. Choi, Philips & S. Kandala, Sharp