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 Draft D1 June 2001 Outline Introduction NAV-related issues in Draft D1 Proposed NAV rules under HCF

References IEEE 802.11e QoS draft D1 June 2001 References IEEE 802.11e QoS draft 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 Draft D1 Draft D1 doesn’t specify all the rules Some inconsistencies in the Draft about NAV operation related issues So, we propose to fix these in the followings

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

Issue 1: CFB Ending per Non-Recovery June 2001 Issue 1: CFB Ending per Non-Recovery Clause 9.10.1.2 of Draft 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 Draft 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 two were proposed in 01/109r2, and look very desirable, but were not found in Draft D1 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))]

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 Draft D1 Our proposal to fix identified problems in Draft 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 upon reception of a data frame with the NF bit equal to 0 and with the SA equal to TxOP holder address as well as the subsequent QoS CF-ACK if the normal ACK policy is used. 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-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 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 irrespective of the NAV value upon successful reception of a frame that requires acknowledgement