NAV Operation Rules under HCF June 2001 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 June 2001 Outline Introduction NAV-related issues in 802.11e/D1 Proposed NAV rules under HCF

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

What is NAV for? NAV in HCF June 2001 Introduction to NAV What is NAV for? NAV in HCF

Network Allocation Vector (NAV) June 2001 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)

More Hidden Transactions under HCF June 2001 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

Therefore, ... NAV operation is very important with HCF However, June 2001 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

NAV-Related Issues in 802.11e/D1 June 2001 NAV-Related Issues in 802.11e/D1

Issue 1: CFB Ending per Non-Recovery June 2001 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

Issue 1: CFB Ending per Non-Recovery (II) June 2001 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.

Issue 2: Non-Zero NAV when Data Reception June 2001 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.

June 2001 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

Issue 4: Reset NAV after RTS June 2001 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))]

Issue 5: TXOP Holder Address June 2001 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.

Proposed NAV Rules Operation Rules Using NAV June 2001 NAV Rules under HCF Proposed NAV Rules Operation Rules Using NAV

NAV Rules Proposal Not a new proposal, but ... June 2001 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

Setting NAV under HCF No change from the current rules June 2001 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

Resetting NAV under HCF June 2001 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

Adjusting NAV under 802.11e During the CP/CFB/CFP June 2001 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))]

Operation Rules (I) During the non-CFB Contention Period June 2001 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

Operation Rules (II) During the CFB/CFP June 2001 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