May 2006 doc IEEE 802 11 060632 r

May 2006 doc. : IEEE 802. 11 -06/0632 r 1 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: // ieee 802. 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>. Submission 1 M. Benveniste (Avaya Labs)

May 2006 doc. : IEEE 802. 11 -06/0632 r 1 NAV Clearing: Problems and Proposed Remedy Mathilde Benveniste benveniste@ieee. org Submission 2 M. Benveniste (Avaya Labs)

May 2006 doc. : IEEE 802. 11 -06/0632 r 1 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 Submission 3 M. Benveniste (Avaya Labs)

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

May 2006 doc. : IEEE 802. 11 -06/0632 r 1 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 3 Full NAV should be used – Cannot rely on individual frames to extend reservation, as their Tx range is shorter 5 4 Interference Range 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 2 1 Tx Range 6 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 Submission 5 M. Benveniste (Avaya Labs)

May 2006 doc. : IEEE 802. 11 -06/0632 r 1 NAV Clearing in Draft 11 s D 0. 01 • If the reserved time is not needed/fully used, it should be released SIFS Source Destination SIFS RTS SIFS DATA Time DATA CTS ACK Others NAV The 11 s D 0. 01 draft suggests 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 Submission 6 M. Benveniste (Avaya Labs)

May 2006 doc. : IEEE 802. 11 -06/0632 r 1 NAV clearing mechanisms IEEE 802. 11 s D 0. 01 Clause 11 A. 6. 1 The NAV clearing mechanism, shown in Figure s 78 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 Slot. Time [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. 11 REVma D 5. 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 × a. SIFSTime) + (CTS_Time) + a. PHY-RX-START-Delay + (2 × a. Slot. Time) 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. … Submission 7 M. Benveniste (Avaya Labs)

May 2006 doc. : IEEE 802. 11 -06/0632 r 1 Problems with NAV clearing 1. 2. Submission Collisions Channel Capture 8 M. Benveniste (Avaya Labs)

May 2006 doc. : IEEE 802. 11 -06/0632 r 1 Problems with NAV clearing 1. 2. Submission Collisions Channel Capture 9 M. Benveniste (Avaya Labs)

May 2006 doc. : IEEE 802. 11 -06/0632 r 1 Collision following NAV clearing 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 3 CTS 0 X 2 RTS 2 1 RTS 1 4 RTS 0/CTS 0 set NAV at MP 1 RTS 1 updates NAV at MP 1 RTS 1 reservation cancelled, causing NAV to clear at MP 1 RTS 2 causes collision at MP 2 Submission 10 M. Benveniste (Avaya Labs) 5

May 2006 doc. : IEEE 802. 11 -06/0632 r 1 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 Submission 11 M. Benveniste (Avaya Labs)

May 2006 doc. : IEEE 802. 11 -06/0632 r 1 Collision prevention example MP 1 remembers that its NAV was set by a CTS. 3 CTS 0 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 NAVsetting transmission from 4 ends early because CTS_PENDING is set; hence MP 1 will not transmit 2 RTS 1 1 4 RTS 0/CTS 0 set NAV and CTS_PENDING at MP 1 RTS 1 updates NAV at MP 1 Cancellation of the RTS 1 reservation does not cause NAV to clear at MP 1 does not transmit, as its NAV is set. No collision! Submission 12 M. Benveniste (Avaya Labs) 5

May 2006 doc. : IEEE 802. 11 -06/0632 r 1 Problems with NAV clearing 1. 2. Submission Collisions Channel Capture 13 M. Benveniste (Avaya Labs)

May 2006 doc. : IEEE 802. 11 -06/0632 r 1 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 RTS 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 Channel capture arises when a subset of the eligible nodes gain access to the channel with greater probability than other members of the set of eligible nodes with traffic of comparable access priority Submission 14 M. Benveniste (Avaya Labs)

May 2006 doc. : IEEE 802. 11 -06/0632 r 1 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 nonzero 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 – – Submission 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 15 M. Benveniste (Avaya Labs)

May 2006 doc. : IEEE 802. 11 -06/0632 r 1 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 – • A station will reset its NAV, if 1. 2. • If a station has a non-zero RTS_RECEIVED flag, it will send a CF-End in order to indicate NAV cancellation 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 Submission 16 M. Benveniste (Avaya Labs)

May 2006 doc. : IEEE 802. 11 -06/0632 r 1 Channel capture in ad hoc network caused by NAV resetting • RTS 0 sets NAV of node 3 at time xx 00 • CTS_PENDING is clear at time xx 01+ • RTS 0 is cancelled at time xx 02 and resets NAV as CTS-PENDING is clear 5 3 CTS 0 4 CTS 1 1 2 • RTS 0 sets NAV of node 1 at time xx 00 • CTS 1 sets CTS_PENDING to 1 at time xx 01+ • RTS 0 is cancelled at time xx 02 but does not reset NAV as CTS-PENDING is set • Node 1 becomes ‘exposed’ when RTS 1 is cancelled at time xx 03 but does not reset NAV, as node 1 gets no notice Submission xx 00 RTS 0 xx 01 RTS 1 xx 02 Cancel RTS 0 xx 03 Cancel RTS 1 time • CTS 0 sets NAV of node 2 and sets CTS_PENDING at time xx 00+ • RTS 1 sets NAV at time xx 01 • Node 2 becomes ‘exposed’ when RTS 1 is cancelled at time xx 03 but does not clear NAV, as CTS-PENDING is set 17 M. Benveniste (Avaya Labs)

May 2006 doc. : IEEE 802. 11 -06/0632 r 1 Avoiding collisions and channel capture caused by NAV resetting • RTS 0 sets NAV of node 3 at time xx 00 • CTS_PENDING is clear at time xx 01+ • RTS 0 is cancelled at time xx 02 and resets NAV as CTS-PENDING is clear 3 CTS 0 CTS 1 1 2 • RTS 0 sets NAV and RTS_RECEIVED of node 1 at time xx 00 • CTS 1 increments CTS_PENDING by 1 at time xx 01+ • RTS 0 is cancelled at time xx 02 but does not reset NAV as CTS-PENDING is set • CF-End is sent and RTS_RECEIVED is cleared at time xx 02+ • Receipt of CF-End decrements CTS_PENDING by 1 (and clears it) and NAV is reset at time xx 03++ Submission 18 xx 00 RTS 0 xx 01 RTS 1 xx 02 Cancel RTS 0 xx 03 Cancel RTS 1 time • CTS 0 sets NAV and increments CTS_PENDING of node 2 at time xx 00+ • RTS 1 sets RTS_RECEIVED at time xx 01 • Receipt of CF-End decrements CTS_PENDING by 2 (and clears it) and NAV is reset at time xx 02++ • RTS 1 is cancelled at time xx 03 resets NAV as CTS-PENDING is clear • CF-End is sent and RTS_RECEIVED is cleared at time xx 03+ M. Benveniste (Avaya Labs)

May 2006 doc. : IEEE 802. 11 -06/0632 r 1 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 whethere 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 Submission 19 M. Benveniste (Avaya Labs)

May 2006 doc. : IEEE 802. 11 -06/0632 r 1 Backup slides Submission 20 M. Benveniste (Avaya Labs)

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

May 2006 doc. : IEEE 802. 11 -06/0632 r 1 IEEE 802. 11 n D 1. 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. Submission 22 M. Benveniste (Avaya Labs)