1 / 21

NAV Operation Rules under HCF

NAV Operation Rules under HCF. Javier del Prado, Sunghyun Choi and Amjad Soomro Philips Research-USA Briarcliff Manor, New York sunghyun.choi@philips.com. Outline. Introduction NAV-related issues in 802.11e/D1 Proposed NAV rules under HCF. References. IEEE 802.11e/D1

emlyn
Download Presentation

NAV Operation Rules under HCF

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. NAV Operation Rules under HCF Javier del Prado, Sunghyun Choi and Amjad Soomro Philips Research-USA Briarcliff Manor, New York sunghyun.choi@philips.com

  2. Outline • Introduction • NAV-related issues in 802.11e/D1 • Proposed NAV rules under HCF

  3. References • IEEE 802.11e/D1 • IEEE 802.11-01/109r2: “Hybrid Coordination Function (HCF): Frame exchange and NAV details” by Michael Fischer

  4. Introduction to NAV What is NAV for? NAV in HCF

  5. Network Allocation Vector (NAV) • Virtual Carrier Sensing • To protect frame exchanges from hidden (E)STAs • PCF and HCF relies on NAV operation • (E)STAs may not hear from TxOP holding ESTA (i.e., TxOP holder) under HCF • HCF relies on NAV even more (See why in next)

  6. More Hidden Transactions under HCF • Hidden transaction • Frame exchange not visible from certain (E)STAs • Multiple reasons for new hidden transactions under HCF: • Direct ESTA-to-ESTA transmissions • May result in more hidden transactions since HC (visible from every ESTA in QBSS) is not involved during the frame exchanges • Multiple frame exchanges during a TxOP • May extend hidden transaction periods • Power control will be possible per 802.11h • May result in more hidden (E)STAs

  7. Therefore, ... • NAV operation is very important with HCF • A complete and clear rule definition needed • However, • We identified a number of vague and problematic rules around NAV in 802.11e/D1 • 802.11e/D1 doesn’t specify all the rules • Some inconsistencies in D1 about NAV operation related issues • So, we propose to fix these in the followings

  8. NAV-Related Issues in 802.11e/D1

  9. Issue 1: CFB Ending per Non-Recovery • Clause 9.10.1.2 of D1 reads: “ If, following a non-response during the CP, neither the TXOP holder nor the HC initiate recovery, the CFB ends and {E}DCF contention resumes after DIFS” • DIFS from when? Two possible interpretation! • DIFS after the recovery is not initiated (i.e., 2 x DIFS after the last transmission) • DIFS after the original TxOP expires

  10. Issue 1: CFB Ending per Non-Recovery (II) • The first should not be the case since under HCF, because of the possibility of Hidden Transactions, only the HC and TxOP holder should be allowed to judge if the medium is idle or not using PHY sensing • We insist that this operation rule should be eliminated since the first should not be the case, and if it meant the second, it is redundant to be described.

  11. Issue 2: Non-Zero NAV when Data Reception • Clause 9.10.2.1 of 802.11e/D1 reads: “If the NAV is set when an ESTA receives a QoS data type frame which requires acknowledgement, the response after SIFS shall be a QoS CF-Ack (no data) frame,even if the frame being acknowledged was of a subtype including CF-Poll. In this manner the responding ESTA indicates that it is unable to accept the TXOP conveyed by the (+)CF-Poll” • But, this rule is only reasonable during the CP. During the CFP the NAV is always set.

  12. Issue 3: NAV Reset Rules • The following was proposed in 01/109r2, and look very desirable, but was not found in 802.11/D1 • During CFB, reset NAV upon reception of QoS CF-Poll addressed to the HC with Duration/ID field equal to 0 • Reset NAV upon reception of a data frame with the NF bit equal to 0 and with the SA equal to TxOP holder address

  13. Issue 4: Reset NAV after RTS • This is rooted from 802.11-1999 • If no PHY-RXSTART.indication is detected from the PHY during a period with a duration of (2 x aSIFSTime) + (CTS_Time) + (2 x aSlotTime) starting at the PHY-RXEND.indication corresponding to the detection of the RTS frame, the STA may reset the NAV. • The NAV should not be reset but to be set to max [0, old NAV value – ((2 x aSIFSTime) + (CTS_Time) + (2 x aSlotTime))]

  14. Issue 5: TXOP Holder Address • Clause 9.10.2.1 of 802.11e/D1 reads: “When an ESTA updates its NAV setting due to receipt of a larger duration value than the present NAV setting, using the duration value from a (+)CF-Poll containing the BSSID of this QBSS, that ESTA also saves the MAC address from the RA field of the frame containing the (+)CF-Poll. If, prior to expiration of this NAV setting, ...” • This operation is needed, but the underlined condition is not problematic. • Since they cannot be true during CFP.

  15. NAV Rules under HCF Proposed NAV Rules Operation Rules Using NAV

  16. NAV Rules Proposal • Not a new proposal, but ... • This fixes up identified problems with • Document 01/109r2 • 802.11e/D1 • Our proposal to fix identified problems in D1 • Underlined parts are changes from D1

  17. Setting NAV under HCF • No change from the current rules • Including the followings • During CP/CFB/CFP • Update NAV with the Duration/ID field from a QoS (+)CF-Poll if the new NAV value is larger than the old value • During CFP • Non-HC ESTAs preset NAV to CFPMaxDuration at TBTT in which a CFP starts • Non-HC ESTAs shall update their NAV using the CFPDurRemaining value

  18. Resetting NAV under HCF • During CFB in CP • Reset upon reception of QoS CF-Poll addressed to the HC with Duration/ID field equal to 0 • Reset NAV upon reception of a data frame with the NF bit equal to 0 and with the SA equal to TxOP holder address according to the ACK policy • During CFP • Upon reception of a CF-END coming from its own BSS

  19. Adjusting NAV under 802.11e • During the CP/CFB/CFP • ESTA that uses the Dur/ID field from an RTS frame to update its NAV may save the previous value of NAV. If no PHY-CCA.indicate(busy) is detected from the PHY during a period with a duration of (2 x aSIFSTime) + (CTS_Time) + (2 x aSlotTime) starting at the PHY-RXEND.indication corresponding to the detection of the RTS frame, the ESTA may set the NAV with the following value: max [0, saved old NAV value – ((2 x aSIFSTime) + (CTS_Time) + (2 x aSlotTime))]

  20. Operation Rules (I) • During the non-CFB Contention Period • ESTA can contend for the channel only when it has zero NAV • If the ESTA receives a QoS (+)CF-Poll and its NAV is non-zero, the ESTA shall not respond with QoS Data(+) other than QoS CF-ACK • That is, even with non-zero NAV, always generate QoS CF-ACK frame upon successful reception of a QoS Data(+) frame that requires acknowledgement

  21. Operation Rules (II) • During the CFB/CFP • Note that every ESTA shall have non-zero NAV in these periods • The ESTA shall respond to QoS (+)CF-Poll from the HC and to RTS from the TxOP holder • Always generate QoS (+)CF-ACK frame upon successful reception of a frame that requires acknowledgement

More Related