1 / 12

Clarification on Some HCF Frame Exchange Rules

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. Outline. Response depending on frame subtypes ACK or not ACK vs. QoS CF-ACK

Download Presentation

Clarification on Some HCF Frame Exchange Rules

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. 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

  2. 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

  3. 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

  4. 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. • Only 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

  5. 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

  6. 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

  7. 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

  8. 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

  9. 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

  10. 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

  11. 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

  12. 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

More Related