NAV Clearing: Problems and Proposed Remedy May 2006 NAV Clearing: Problems and Proposed Remedy Date: 2006-05-11 Authors: Notice: This document has been prepared to assist IEEE 802.11. 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 802.11. Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures <http:// 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 <stuart.kerry@philips.com> 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 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at <patcom@ieee.org>. M. Benveniste (Avaya Labs)

NAV Clearing: Problems and Proposed Remedy May 2006 NAV Clearing: Problems and Proposed Remedy Mathilde Benveniste benveniste@ieee.org M. Benveniste (Avaya Labs)

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)

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)

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)

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)

NAV clearing mechanisms May 2006 NAV clearing mechanisms IEEE 802.11s 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 802.11:9.2.5.4]. This allows reuse of the channel in case the 4-way handshake can not be completed. IEEE 802.11REVma D5.2 Clause 9.2.5.4 … 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)

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

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

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)

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)

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)

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

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)

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)

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)

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)

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)

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)

May 2006 Backup slides M. Benveniste (Avaya Labs)

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)

May 2006 IEEE 802.11n D1.0 Truncation of TXOP Clause 9.16.3 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)