Clarification on Some HCF Frame Exchange Rules Month 1998 doc.: IEEE 802.11-98/xxx October 2001 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 Error handling Month 1998 doc.: IEEE 802.11-98/xxx October 2001 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

October 2001 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. A detailed usage of QoS control field should be reflected in Figure 14.5. S. Choi, Philips & S. Kandala, Sharp

October 2001 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. QoS CF-ACK can update the queue status with HC. (assuming that “QoS null frames” in Figure 14.5 of IEEE 802.11e/D1.2 include “QoS CF-ACK”.) 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.) October 2001 QoS CF-ACK or ACK? (Cont.) In terms of the function, ACK is equivalent to QoS CF-ACK w/ NF=1 & No Ack = 1. Resolution: Clarify that ACK and QoS CF-ACK w/ NF=1 & No Ack = 1 are equivalent, and either of them can be used for relevant situations. Clarify that ACK cannot be used instead of QoS CF-ACK w/ either or both of NF & No Ack bits set to zero. S. Choi, Philips & S. Kandala, Sharp

PIFS or SIFS after Error? October 2001 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. Resolution: add the following in 9.10.1.2. If an erroneous frame 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

RTS/CTS during CFP/CFB October 2001 RTS/CTS during CFP/CFB Per 802.11e/D1.2, RTS/CTS exchange is allowed during CFP and CFB However, what happens if the RTS/CTS exchange is not successful should be clearly stated. Apparently, we don’t want the TXOP holder or the HC to go to the back-off in this case. S. Choi, Philips & S. Kandala, Sharp

RTS/CTS during CFP/CFB (Cont.) October 2001 RTS/CTS during CFP/CFB (Cont.) Resolution: add the following in 9.10.3.2. The RTS sender can 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. S. Choi, Philips & S. Kandala, Sharp