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

3. June 2001
References
IEEE e/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/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
June 2001
NAV-Related Issues in e/D1

9. Issue 1: CFB Ending per Non-Recovery
June 2001
Issue 1: CFB Ending per Non-Recovery
Clause 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)
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 e/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 was proposed in 01/109r2, and look very desirable, but was not found in /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
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. Issue 5: TXOP Holder Address
June 2001
Issue 5: TXOP Holder Address
Clause of e/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. Proposed NAV Rules Operation Rules Using NAV
June 2001
NAV Rules under HCF
Proposed NAV Rules
Operation Rules Using NAV

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

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

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

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

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