1. NAV Clearing: Problems and Proposed Remedy
May 2006
NAV Clearing: Problems and Proposed Remedy
Date:
Authors:
Notice: This document has been prepared to assist IEEE It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.
Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE
Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures < ieee802.org/guides/bylaws/sb-bylaws.pdf>, including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE Working Group. If you have questions, contact the IEEE Patent Committee Administrator at
M. Benveniste (Avaya Labs)

2. NAV Clearing: Problems and Proposed Remedy
May 2006
NAV Clearing: Problems and Proposed Remedy
Mathilde Benveniste
M. Benveniste (Avaya Labs)

3. May 2006
Abstract
Wireless mesh networks experience both collisions and channel capture when the NAV is cleared due to channel inactivity
In an isolated BSS [without OBSS], where stations communicate only with the AP, there is no collision problem when resetting the NAV, but there is ‘channel capture’
We propose a remedy to both problems
M. Benveniste (Avaya Labs)

4. Full NAV Frame-by-Frame NAV NAV Setting Methods May 2006
RTS
CTS
DATA
ACK
SIFS
Source
Others
NAV
Frame-by-Frame NAV
RTS
CTS
DATA
ACK
SIFS
Source
Destination
time
Others
NAV
Full NAV
Two options for setting the NAV for a TXOP
Frame-by-frame NAV: NAV is extended with each Frame/Ack
Full NAV: RTS/CTS indicate entire TXOP duration
M. Benveniste (Avaya Labs)

5. Full NAV helps with ‘hidden node’ problem
May 2006
Full NAV helps with ‘hidden node’ problem
Long spatial separation of mesh points makes hidden node problem harder to address
hidden nodes are within the interference range of destination node but outside its Tx range
To protect against hidden nodes, RTS/CTS can be sent at more robust PHY mode than data frames, for TXOP duration
RTS/CTS can be decoded at the interference
range of mesh traffic
Mesh traffic is transmitted at lower energy and
is decoded at a shorter range
Full NAV should be used
Cannot rely on individual frames to extend
reservation, as their Tx range is shorter
Interference
Range
Tx Range 1 4 5 2 6 3
Notes
A hidden node is one that, if it transmits, can cause interference to the receiver of another transmission from a node the hidden node cannot hear
Interference range of node 1 is the range within which existing communications of nodes can be disrupted by a transmission from node 1
Tx Range of node 1 is the range within which all nodes can hear a transmission from node 1 and is able to decode the packet
M. Benveniste (Avaya Labs)

6. NAV Clearing in Draft 11s D0.01
May 2006
NAV Clearing in Draft 11s D0.01
If the reserved time is not needed/fully used, it should be released
RTS
CTS
DATA
ACK
SIFS
Source
Destination
Time
Others
NAV
The 11s D0.01 draft suggest NAV clearing as follows:
If a MP used information from an RTS frame as the most recent basis to update its NAV and there is no signal detected for specified time interval, the NAV may be cleared
M. Benveniste (Avaya Labs)

7. NAV clearing mechanisms
May 2006
NAV clearing mechanisms
IEEE s D0.01 Clause 11A.6.1
The NAV clearing mechanism, shown in Figure s78 c, is an optional mechanism in the standard which allows a station to clear its NAV if the station used information from an RTS frame as the most recent basis to update its NAV and there is no signal detected for 2 SIFS + CTS_duration + 2 SlotTime [IEEE : ]. This allows reuse of the channel in case the 4-way handshake can not be completed.
IEEE REVma D5.2 Clause
… When Dual CTS Protection is not required by the AP of a BSS, then a STA that used information from an RTS frame as the most recent basis to update its NAV setting is permitted to reset its NAV if no PHY-RXSTART.indication is detected from the PHY during a period with a duration of (2 × aSIFSTime) + (CTS_Time) + aPHY-RX-START-Delay + (2 × aSlotTime) starting at the PHY-RXEND.indication corresponding to the detection of the RTS frame. The “CTS_Time” shall be calculated using the length of the CTS frame and the data rate at which the RTS frame used for the most recent NAV update was received. …
M. Benveniste (Avaya Labs)

8. Problems with NAV clearing
May 2006
Problems with NAV clearing
Collisions
Channel Capture
M. Benveniste (Avaya Labs)

9. Problems with NAV clearing
May 2006
Problems with NAV clearing
Collisions
Channel Capture
M. Benveniste (Avaya Labs)

10. Collision following NAV clearing
May 2006
Collision following NAV clearing 3
MP 2 is receiving a transmission from 3 that is not audible to the nearby MP 1
An RTS from 4 causes the NAV at 1 to be reset
Thus, the CTS from 2 will not have caused the NAV at 1 to be last updated
MP 1 clears its NAV when the NAV-setting transmission from 4 ends while MP 3 is still transmitting; if MP 1 transmits , it will cause a collision at 2
RTS1
RTS1 updates NAV at MP 1
CTS0
RTS0/CTS0 set NAV at MP 1
RTS2
RTS2 causes collision at MP 2 X 2 5
RTS1 reservation cancelled, causing NAV to clear at MP 1 1 4
M. Benveniste (Avaya Labs)

11. Procedure: Avoiding collisions caused by NAV clearing
May 2006
Procedure: Avoiding collisions caused by NAV clearing
A station remembers whether the duration of a CTS has expired. If not, we say that a CTS is ‘pending’
A flag CTS_PENDING is set when a new CTS arrives with non-zero Duration field
The flag is cleared when the NAV expires
A station will clear its NAV, if the channel is idle for specified time interval, and the flag CTS_PENDING is clear
If the flag CTS_PENDING is set, the station does not clear the NAV
M. Benveniste (Avaya Labs)

12. Collision prevention example
May 2006
Collision prevention example 3
MP 1 remembers that its NAV was set by a CTS.
A subsequent RTS (from 4) causes the NAV at 1 to be updated
Although the new RTS from 4 will be the last updating the NAV at MP 1, the CTS_PENDING flag is still set at MP 1
MP (1) does not clear its NAV when the NAV-setting transmission from 4 ends early because CTS_PENDING is set; hence MP 1 will cause not transmit
CTS0
RTS0/CTS0 set NAV and CTS_PENDING at MP 1
RTS1
RTS1 updates NAV at MP 1 2 5
Cancellation of the RTS1 reservation does not cause NAV to clear at MP 1 1 4
MP 1 does not transmit, as its NAV is set. No collision!
M. Benveniste (Avaya Labs)

13. Problems with NAV clearing
May 2006
Problems with NAV clearing
Collisions
Channel Capture
M. Benveniste (Avaya Labs)

14. Channel capture caused by NAV clearing
May 2006
Channel capture caused by NAV clearing
According to present rules:
Only the MPs that set their NAV as a result of a RTS will reset their NAVs
The MPs that updated their NAVs by the CTS will not have a way to know that the reservation was shortened
The latter MPs [further away] will have their NAVs set needlessly
The neighbors of transmitting MPs will thus be able to gain access to the channel more readily
RTS
Channel capture arises when a subset of the eligible stations gain access to the channel with greater probability than other BSS members with traffic of comparable access priority
M. Benveniste (Avaya Labs)

15. May 2006
Procedure: Avoiding collisions & channel capture caused by NAV clearing
A station remembers whether, and how many, CTS may still be pending
A counter CTS_PENDING is incremented when a new CTS arrives with non-zero Duration field
The counter is decremented when notice is received of the cancellation of a reservation [e.g. CF-End]
The counter is cleared when the NAV expires
A station remembers whether it is the destination of a RTS that may still be pending
A flag RTS_RECEIVED is set to 1 when a station is the destination of a RTS
The flag is cleared when a CF-End is sent, or when the NAV expires
M. Benveniste (Avaya Labs)

16. Avoiding collisions & channel capture caused by NAV clearing -- 2
May 2006
Avoiding collisions & channel capture caused by NAV clearing -- 2
A station that sent out a CTS in response to receiving an RTS, will notify its neighbors that the RTS reservation is cancelled if the channel is idle for a specified time interval
If a station has a non-zero RTS_RECEIVED flag, it will send a CF-End in order to indicate NAV cancellation
A station will reset its NAV, if
the channel is idle for a specified time interval, and
the counter CTS_PENDING is clear
If the counter CTS_PENDING is set, the station does not reset the NAV
M. Benveniste (Avaya Labs)

17. Channel capture in ad hoc network caused by NAV resetting
May 2006
Channel capture in ad hoc network caused by NAV resetting
time
xx00
xx01
xx02
xx03
RTS0
RTS1
Cancel RTS0
Cancel RTS1
RTS0 sets NAV of node 3 at time xx00
CTS_PENDING is clear at time xx01+
RTS0 is cancelled at time xx02 and resets NAV as CTS-PENDING is clear 5 3
CTS1
CTS0 2 1 4
RTS0 sets NAV of node 1 at time xx00
CTS1 sets CTS_PENDING to 1 at time xx01+
RTS0 is cancelled at time xx02 but does not reset NAV as CTS-PENDING is set
Node 1 becomes ‘exposed’ when RTS1 is cancelled at time xx03 but does not reset NAV, as node 1 gets no notice
CTS0 sets NAV of node 2 and sets CTS_PENDING at time xx00+
RTS1 sets NAV at time xx01
Node 2 becomes ‘exposed’ when RTS1 is cancelled at time xx03 but does not clear NAV, as CTS-PENDING is set
M. Benveniste (Avaya Labs)

18. Avoiding collisions and channel capture caused by NAV resetting
May 2006
Avoiding collisions and channel capture caused by NAV resetting
time
xx00
xx01
xx02
xx03
RTS0
RTS1
Cancel RTS0
Cancel RTS1
RTS0 sets NAV of node 3 at time xx00
CTS_PENDING is clear at time xx01+
RTS0 is cancelled at time xx02 and resets NAV as CTS-PENDING is clear
time
xx00
xx01
xx02
xx03
RTS0
RTS1
Cancel RTS0
Cancel RTS1 3
CTS1
CTS0 1 2
RTS0 sets NAV of node 1 at time xx00
CTS1 increments CTS_PENDING by 1 at time xx01+
RTS0 is cancelled at time xx02 but does not reset NAV as CTS-PENDING is set
Receipt of CF-End decrements CTS_PENDING by 1 (and clears it) and NAV is reset at time xx03++
CTS0 sets NAV of node 2 at time xx00+
RTS1 sets RTS_RECEIVED at time xx01
RTS1 is cancelled at time xx03 resets NAV as CTS-PENDING is clear
CF-End is sent and RTS_RECEIVED is cleared at time xx03+
M. Benveniste (Avaya Labs)

19. May 2006
Summary
Collisions and channel capture are possible when mesh points reset the NAV in mesh networks
Collisions caused by resetting the NAV can be avoided if a station remembers whether there are any CTS pending
Channel capture caused by resetting the NAV can be avoided if the destination of the cancelled RTS notifies its neighbors of the cancellation
M. Benveniste (Avaya Labs)

20. May 2006
Backup slides
M. Benveniste (Avaya Labs)

21. Example: BSS channel capture due to NAV resetting
May 2006
Example: BSS channel capture due to NAV resetting
RTS0/CTS0 cause NAV to be set at station 1
RTS0 reservation is ‘cancelled’ – i.e., Tx completes before reservation expires
All BSS stations that heard the CTS0 but not the RTS0 (in shaded area) become ‘exposed’ – i.e., refrain from Tx needlessly
Stations that heard the RTS0 (in non-shaded area of BSS) ‘capture’ the channel
CTS0 AP 1
M. Benveniste (Avaya Labs)

22. May 2006
IEEE n D1.0
Truncation of TXOP
Clause
In the case when a STA gains access to the channel using EDCA and uses Long NAV to protect a duration value, and then runs out of frames to transmit, the STA may transmit a CF-End provided that the remaining duration is long enough to transmit this frame. By transmitting the CF-End frame, the STA is explicitly indicating the completion of its TXOP.
This shall be interpreted by HT STAs and is interpreted by non-HT STAs as a NAV reset – i.e. they reset their NAV timer to zero at the end of the PPDU containing this frame. After receiving a CF-End with a matching BSSID, an AP may respond with a CF-End after SIFS.
M. Benveniste (Avaya Labs)