1. Multiple NAV Protection - Revisited
November 2004
doc.: IEEE /1093r3
January 2005
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
January 2005
DCF (IEEE ) can be used in multi-BSS systems because the NAV provides collision avoidance between stations regardless of BSS
TGe has changed the NAV rules; the new rules do not provide comparable NAV protection
An HC is allowed to reset its stations’ NAVs without regard for the NAV setting requests from other sources
Resetting the NAV causes problems for RTS/CTS
NAV protection is even more important to 11e stations than to legacy stations
The introduction of TXOPs by 11e stations will increase use of RTS/CTS
As a consequence, the performance of EDCA will suffer when HCCA is used in adjacent BSS
This will be problematic in public spaces (hotspots) and in the enterprise/ campus
High density VoWLAN will require use of HCCA in such locations
Mathilde Benveniste, Avaya Labs
Mathilde Benveniste, Avaya Labs

3. Problem Cause: NAV reset by HC
November 2004
doc.: IEEE /1093r3
Problem Cause: NAV reset by HC
January 2005
According to TGe D13, 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 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 in an adjacent BSS
If a station transmits when the HC resets NAVs, there can be a collision with transmissions in adjacent BSSs
EDCA transmissions in adjacent BSSs will experience collisions at the end of each HCCA polling cycle
Mathilde Benveniste, Avaya Labs
Mathilde Benveniste, Avaya Labs

4. Increased vulnerability to RTS/CTS failure
November 2004
doc.: IEEE /1093r3
January 2005
Increased vulnerability to RTS/CTS failure
802.11e introduces TXOPs (multiple frames transmitted after single contention) for EDCA
Much of the EDCA traffic will be transmitted through TXOPs
TXOPs will increase RTS/CTS use
Unlike with short, single frame, transmissions, use of RTS/CTS is efficient with TXOPs
EDCA transmissions are thus increasingly vulnerable to RTS/CTS failure
NAV resetting by HC causes CTS to fail, thus degrading EDCA performance
Mathilde Benveniste, Avaya Labs
Mathilde Benveniste, Avaya Labs

5. HCCA causes CTS failure in adjacent BSS
November 2004
doc.: IEEE /1093r3
January 2005
HCCA causes CTS failure in adjacent BSS
HC1
At the end of each polling cycle by HC1, EDCA transmissions in surrounding BSSs – HC2 and HC3 – experience collisions
HC2 S1 S2
HC3
navHC1
S1 receives a NAV request from HC1, sent while polling
TXOP from HC2
navS2
S1 receives CTS from S2 sent in response to RTS from HC2; HC2 starts TXOP to S2, which is not heard by S1 t1 X
HC1 resets NAVs after polling is complete at time t1
TX by S1
S1 transmits and interferes with TXOP received at S2
Mathilde Benveniste, Avaya Labs
Mathilde Benveniste, Avaya Labs

6. November 2004
doc.: IEEE /1093r3
Proposed Solution
January 2005
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
At most one NAV is set from within own BSS during polling
The HC will not start polling until all BSS transmissions are complete
The other NAV contains the longest NAV from all other BSSs
It will be the fall-back NAV setting for the station when the HC resets NAVs
Additional NAVs offer no advantage
Mathilde Benveniste, Avaya Labs
Mathilde Benveniste, Avaya Labs

7. Motion Move to accept the normative text changes in doc 04/1070r5
January 2005
Motion
Move to accept the normative text changes in doc 04/1070r5
Mathilde Benveniste, Avaya Labs

8. Illustrative implementation of 2 NAVs
January 2005
Illustrative implementation of 2 NAVs
Mathilde Benveniste, Avaya Labs

9. NAV Problem Solution January 2005
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

10. Example – 2 NAV values retained in ANAV; Reset requested - NAV cleared
January 2005
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

11. Different result from present NAV rules
January 2005
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

12. Different result from present NAV rules
January 2005
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

13. History of the “NAV Problem”
January 2005
History of the “NAV Problem”
The problem was identified initially in 2001
S. Choi, A. Soomro, and J DelPrado – See 01/272
In July 2003, comments to LB 51 pointed to the 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 LB 51 comments were addressed by “multiple NAV” solution
M. Benveniste - See 03/565r1
Normative text provided by M. Benveniste, M. Sherman, and C. Wright - See 03/594r1
Solution has been present in D5, D6, D7, D8 (SP 1)
The solution was removed at SP1 without any discussion in TGe
The request to remove was passed in a block of comments, as a non-controversial comment, escaping the group’s attention
The change gave rise to more “Negative” comments than it addressed
Low attendance in TGe has made it impossible to get sufficient votes to adopt a fix
Mathilde Benveniste, Avaya Labs