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

2. Outline Introduction NAV-related issues in Draft D1
June 2001
Outline
Introduction
NAV-related issues in Draft D1
Proposed NAV rules under HCF

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

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

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

6. 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 h
May result in more hidden (E)STAs

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

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

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

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

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

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

13. Issue 4: Reset NAV after RTS
June 2001
Issue 4: Reset NAV after RTS
This is rooted from
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. Proposed NAV Rules Operation Rules Using NAV
June 2001
NAV Rules under HCF
Proposed NAV Rules
Operation Rules Using NAV

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

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

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

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

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

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