1 / 10

Multiple NAV Protection - Revisited

Multiple NAV Protection - Revisited. Mathilde Benveniste Avaya Labs, Research October 2004. NAV protection. Current NAV protection is not adequate to provide reliable virtual carrier sensing The NAV of a station should be set or reset by considering all stations involved

havard
Download Presentation

Multiple NAV Protection - Revisited

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Multiple NAV Protection - Revisited Mathilde Benveniste Avaya Labs, Research October 2004

  2. NAV protection • Current NAV protection is not adequate to provide reliable virtual carrier sensing • The NAV of a station should be set or reset by considering all stations involved • The NAV rules do not protect QBSS properly when HCCA is used with overlapping BSS • This will be problematic for high-density VoWLAN, encountered in public spaces (hotspots) and the enterprise M. Benveniste -- Avaya Labs, Research

  3. HCF Polling (HCCA) NAV Reset • With HCCA, the HC overrules the NAV values • HC can reset NAV of QSTAs by sending CF-END • HC can reset NAV of QSTAs by sending QoS (+)CF-poll to itself with Dur/ID = 0 • The NAV of a QSTA, 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 (Q)STA in an adjacent BSS • If QSTA S1 cleared its NAV and transmitted when the HC resets NAVs, there would be a collision M. Benveniste -- Avaya Labs, Research

  4. Proposed Solution • Restore the ability to use multiple NAVs and make it optional • Stations that have not implemented at least 2 NAVs may not reset their NAV when an AP engaged in HCF polling resets the NAV for the BSS M. Benveniste -- Avaya Labs, Research

  5. Motion Move to accept the normative text changes in doc 04/1070r2 • Comment addressed by this motion: 15 (SB 2) M. Benveniste -- Avaya Labs, Research

  6. Sample implementation of multiple NAVs The following is the most conservative implementation of a NAV setting involving 2 NAV values. A simpler implementation would ignore the field DISCARDED.

  7. NAV Problem Solution Define NA: address TXOP holder causing NAV to be set • Keep a set of the n longest NAV values, ANAV. Discard the shorter NAV values. For each NAV retain the NA of the node 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 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 is retained among the n ANAV components if it exceeds the length of the shortest NAV retained, which it replaces. • Reset the ANAV component of the source requesting reset. Set a ANAV[NA]=0 when NA coincides with the address of a node responsible for NAV cancellation (i.e. the HC), unless at least one NAV value has been discarded and none of the non-discarded NAV values has since expired M. Benveniste -- Avaya Labs, Research

  8. +3 +1 +1 Time increment Time 1 4 5 Example – 2 NAV values retained in ANAV; NAV cleared Reset NAV NA=XA NAV value=3 NA=XC Time 0: NAV setting requests received from XA, XB, and XC Time 1: Discarded is set to T when ANAV[XB] is discarded Time 4: Discardedis reset to F when ANAV[XC] expires Time 5: XA requests NAV reset 5 time-units later, and the ANAV[XA] is cleared; the station NAV is also cleared as Discardedis F and all other NAV values have expired 10, XA 9, XA 6, XA 0, XA ANAV … 2, XB 3, XC 0, XC Discarded=F Discarded=T Discarded=F Discarded=F 0 M. Benveniste -- Avaya Labs, Research

  9. +3 +1 +1 Time increment Time 1 4 5 Example – 2 NAV values retained in ANAV; NAV not cleared Reset NAV NA=XA NAV value=5 NA=XC Time 0: NAV setting requests received from XA, XB, and XC Time 1: Discarded is set to T when ANAV[XB] is discarded Time 4: Discardedis reset to F when ANAV[XC] expires Time 5: XA requests NAV reset 5 time-units later, and the ANAV[XA] is cleared; the station NAV is notcleared as all other NAV values have not expired 10, XA 9, XA 6, XA 1, XC ANAV … 0, XA 2, XB 5, XC 2, XC Discarded=F Discarded=T Discarded=F Discarded=F 0 M. Benveniste -- Avaya Labs, Research

  10. 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 Comments to LB 51 were addressed by providing 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) M. Benveniste -- Avaya Labs, Research

More Related