1. Multiple NAV Protection - Revisited
November 2004
doc.: IEEE /1093r3
November 2004
Multiple NAV Protection - Revisited
Date:
Authors:
Name
Company
Address
Phone
233 Mt. Airy Road
Basking Ridge, NJ USA
Mathilde Benveniste
Avaya Labs
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
Mathilde Benveniste, Avaya Labs
Mathilde Benveniste, Avaya Labs

2. Inadequate NAV protection
November 2004
doc.: IEEE /1093r3
Inadequate NAV protection
November 2004
Current NAV rules do not provide reliable virtual carrier sensing
An HC is allowed to reset its stations’ NAVs without regard for the NAV setting requests from other sources
The NAV of a station should be reset only if all other NAV requests have expired
DCF (IEEE ) can be used in multi-BSS systems because the NAV provided collision avoidance between stations in different BSS
Comparable protection is not provided when HCCA and EDCA are used in different BSS
This will be problematic for high density VoWLAN in public spaces (hotspots) and in the enterprise/campus
Mathilde Benveniste, Avaya Labs
Mathilde Benveniste, Avaya Labs

3. Problem Cause: HC NAV Reset
November 2004
doc.: IEEE /1093r3
Problem Cause: HC NAV Reset
November 2004
According to TGe D11, the HC overrules the NAV setting
HC can reset NAV of its stations by sending CF-END
HC can reset NAV of its QSTAs by sending QoS (+)CF-poll to itself with Dur/ID = 0
The NAV of a station, S1, may have been set as a result of two NAV setting events:
a poll to a QSTA in the BSS and
a RTS/CTS from a station, S2, in an adjacent BSS
If the HC resets NAVs, and station S1 clears its NAV and transmits, there will be a collision with station S2 from the adjacent BSS
Mathilde Benveniste, Avaya Labs
Mathilde Benveniste, Avaya Labs

4. November 2004
doc.: IEEE /1093r3
Proposed Solution
November 2004
Allow a station to retain the 2 longest NAVs; make the second NAV optional
Stations that have not implemented 2 NAVs shall not reset their NAV when their HC resets the NAV
Observation
Two NAVs are adequate to deal with the case of multiple BSS
Since only HCs can reset their station’s NAVs, two possibilities exist
If the first (longest) NAV was set by own HC, the second NAV contains the longest NAV from all other sources and will be the fall-back value
If the first (longest) NAV was not set by own HC, an HC’s request to reset the NAV causes no resetting
Additional NAVs offer no advantage
Mathilde Benveniste, Avaya Labs
Mathilde Benveniste, Avaya Labs

5. Motion Move to accept the normative text changes in doc 04/1070r4
November 2004
Motion
Move to accept the normative text changes in doc 04/1070r4
Mathilde Benveniste, Avaya Labs

6. Illustrative implementation of 2 NAVs
November 2004
Illustrative implementation of 2 NAVs
Mathilde Benveniste, Avaya Labs

7. NAV Problem Solution November 2004
Define NA: BSSID of frame causing NAV to be set
Keep the 2 longest NAV values in ANAV[.]. For each NAV retain the NA of the frame setting it.
When an HC sets the NAV, the NA is the address of the HC
When the NAV is set through an RTS/CTS, the NA is the address of the BSSID of station sending the RTS/CTS
In general, a station will refrain from transmitting if a ANAV component >0
When a component of ANAV expires it becomes 0
A new NAV value replaces one of the two ANAV components if it exceeds the shortest NAV retained.
When an HC, HC1, requests NAV resetting, a station served by HC1 resets the ANAV component corresponding to HC1’s BSSID, if there is such a component.
A station does not reset an ANAV value if the station is not served by HC1, or if neither NA value is the BSSID of HC1.
Mathilde Benveniste, Avaya Labs

8. Example – 2 NAV values retained in ANAV; Reset requested - NAV cleared
November 2004
Example – 2 NAV values retained in ANAV; Reset requested - NAV cleared
NAV value=3 NA=XB
Reset NAV NA=XA
10, XA
9, XA
6, XA
0, XA
ANAV …
2, XB
3, XB
0, XB
Station
NAV 10 9 6
The same result as present NAV rules +1 +3
Time increment
Time 1 4 5
Time 0: NAV setting requests received from BSSIDs XA (station’s BSSID) and XB
Time 1: A different NAV setting request received from BSSID XB replaces the ANAV[2] value, while NA[2] remains set to XB
Time 4: ANAV[2] expires
Time 5: XA requests NAV reset, and the ANAV[1] is cleared; the station’s NAV is also cleared as the other NAV value is 0
Mathilde Benveniste, Avaya Labs

9. Different result from present NAV rules
November 2004
Example – 2 NAV values retained in ANAV; Reset requested - NAV not cleared or changed
NAV value=6 NA=XB
Reset NAV NA=XA
6, XA
6, XB
3, XB
2, XB
ANAV …
3, XB
5, XA
2, XA
0, XA
Station
NAV 6 6 3 2
Different result from present NAV rules +1 +3
Time increment
Time 1 4 5
Time 0: NAV setting requests received from BSSIDs XA (station’s BSSID) and XB
Time 1: A new NAV setting request received from BSSID XB displaces the entry in (ANAV[1], NA[1]) and places the new NAV from XB in the first ANAV component
Time 5: XA requests NAV reset, and (ANAV[2], NA[2]) is cleared; the station NAV remains unchanged as ANAV[1] is not 0
Mathilde Benveniste, Avaya Labs

10. Different result from present NAV rules
November 2004
Example – 2 NAV values retained in ANAV; Reset requested - NAV changed but not cleared
NAV value=5 NA=XB
Reset NAV NA=XA
10, XA
9, XA
6, XA
1, XB
ANAV …
2, XB
5, XB
2, XB
0, XA
Station
NAV 10 9 6 1
Different result from present NAV rules +1 +3
Time increment
Time 1 4 5
Time 0: NAV setting requests received from BSSIDs XA (station’s BSSID) and XB
Time 1: A different NAV setting request received from BSSID XB replaces ANAV[2] component
Time 5: XA requests NAV reset, and (ANAV[1], NA[1]) is cleared. The entry in (ANAV[2], NA[2]) is moved to (ANAV[1], NA[1]) as it provides the longer NAV value. The station NAV changes, but is not cleared.
Mathilde Benveniste, Avaya Labs

11. History of the “NAV Problem”
November 2004
History of the “NAV Problem”
In July 2003 comments to LB 51 raised the following problem:
Several sources of NAV setting; the NAV should be set always to the longest value.
The problem arises when NAV must be reset because a source requests so. How can we know which source set the NAV in order to cancel it?
The Problem was identified initially in 2001 by
S. Choi, A. Soomro, and J DelPrado – See 01/272
Several comments on LB 51 were addressed by providing as a solution an optional feature, proposed by
M. Benveniste - See 03/565r1
Normative text provided by
M. Benveniste, M. Sherman, and C. Wright - See 03/594r1
The solution has been present in D5, D6, D7, D8 (SP 1)
Mathilde Benveniste, Avaya Labs