problems with ieee 802 11 e nav operation and onav proposal n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Problems with IEEE 802.11(e) NAV Operation and ONAV Proposal PowerPoint Presentation
Download Presentation
Problems with IEEE 802.11(e) NAV Operation and ONAV Proposal

Loading in 2 Seconds...

play fullscreen
1 / 33

Problems with IEEE 802.11(e) NAV Operation and ONAV Proposal - PowerPoint PPT Presentation


  • 127 Views
  • Uploaded on

Problems with IEEE 802.11(e) NAV Operation and ONAV Proposal. Javier del Prado, Sunghyun Choi, and Amjad Soomro Philips Research-USA Briarcliff Manor, New York sunghyun.choi@philips.com. Outline. Introduction The Overlapping BSS problem NAV rules under HCF

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Problems with IEEE 802.11(e) NAV Operation and ONAV Proposal' - ula


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
problems with ieee 802 11 e nav operation and onav proposal
Problems with IEEE 802.11(e) NAV Operation and ONAV Proposal

Javier del Prado, Sunghyun Choi, and Amjad Soomro

Philips Research-USA

Briarcliff Manor, New York

sunghyun.choi@philips.com

S. Choi, Philips Research

outline
Outline
  • Introduction
  • The Overlapping BSS problem
  • NAV rules under HCF
  • Limitations of NAV rules when OBSS
  • ONAV proposal

S. Choi, Philips Research

introduction

Introduction

Importance of NAV

The OBSS problem

Overlapping NAV (ONAV)

S. Choi, Philips Research

hcf relies on nav
HCF Relies on NAV
  • The CFB and CFP are protected by NAV
  • NAV even more important under HCF due to:
    • Direct ESTA-to-ESTA transmissions
    • Multiple frame exchanges during TxOP
    • Power control will be possible per 802.11h
  • Problem
    • NAV does not protect QBSS properly when OBSS exists

S. Choi, Philips Research

the obss problem
The OBSS problem
  • The presence of an OBSS can result in collisions even under HCF
  • NAV should work for this purpose
  • But, the current rules present some limitations when there are OBSSs

S. Choi, Philips Research

we need another counter
We need another counter...
  • We need to solve the NAV limitations when there are OBSSs
  • We also need to protect the QBSS from OBSSs, especially under HCF

ONAV: The Overlapping Network

Allocation Vector under HCF

S. Choi, Philips Research

the network allocation vector nav

The Network Allocation Vector(NAV)

NAV Rules under HCF

(See document 01/373r0)

S. Choi, Philips Research

setting nav under hcf
Setting NAV under HCF
  • No change from the current rules
    • Including the followings
  • During the CP/CFB/CFP
    • Update NAV with the Duration/ID field from a QoS (+)CF-Poll if the new NAV value is larger than the old value
  • During the CFP
    • Non-HC ESTAs preset NAV to CFPMaxDuration at TBTT in which a CFP starts
    • Non-HC ESTAs shall update their NAV using the CFPDurRemaining value

S. Choi, Philips Research

resetting nav under hcf
Resetting NAV under HCF
  • During a CFB in the CP
    • Reset upon reception of QoS (+)CF-Poll addressed to the HC with Duration/ID field equal to 0
    • Reset upon reception of a data frame with the NF bit equal to 0 and with the SA equal to TxOP holder address as well as the subsequent QoS CF-ACK if the normal ACK policy is used.
  • During the CFP
    • Upon reception of a CF-END coming from its own BSS

S. Choi, Philips Research

adjusting nav under 802 11e
Adjusting NAV under 802.11e
  • During the CP/CFB/CFP
    • ESTA that uses the Dur/ID field from an RTS frame to update its NAV may save the previous value of NAV. If no PHY-RXSTART.indication is detected from the PHY during a period with a duration of (2 x aSIFSTime) + (CTS_Time) + (2 x aSlotTime) starting at the PHY-RXEND.indication corresponding to the detection of the RTS frame, the ESTA may set the NAV with the following value:

max [0, old NAV value – ((2 x aSIFSTime) + (CTS_Time) + (2 x aSlotTime))]

S. Choi, Philips Research

nav problems in 802 11 1999 when obss exists

NAV Problems in 802.11-1999when OBSS exists

RTS/CTS

CF-END(+)

S. Choi, Philips Research

overlapping bss example

STA

1

,2

AP

AP

1

2

STA

2

,1

STA

1

,1

Overlapping BSS: Example
  • STA1,2 is the 2nd STA in BSS 1.

S. Choi, Philips Research

potential nav reset after rts
Potential NAV Reset after RTS
  • Clause 9.2.5.4 of 802.11-1999 reads:

“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) + (2 ´ aSlotTime) starting at the PHY-RXEND.indication corresponding to the detection of the RTS frame.”

S. Choi, Philips Research

rts problem example

TBTT signaling a

CFP in BSS1

STA2,1

B

AP1

RTS

D1 + Poll

U1 + ACK

CFP in BSS1

RTS duration

2 x SIFS + CTS_Time + 2 x Slot

RESET NAV

RTS Problem: Example
  • STA1,2 reset NAV during CFP

STA1,2

Reception

Transmission

NAV STA1,2

S. Choi, Philips Research

nav reset per cf end
NAV Reset per CF-End
  • The CF-END problem
    • Current rule: Reset NAV upon reception of CF-END
    • CF-END can come from an OBSS

S. Choi, Philips Research

nav problems in 802 11e qos draft d1 when obss exists

NAV Problems in 802.11e QoS Draft D1when OBSS exists

RTS/CTS

CF-End

S. Choi, Philips Research

inherited from 802 11 1999
Inherited from 802.11-1999
  • NAV reset after RTS still possible
    • This is fixed by 01/373r0 though
  • Reset NAV per CF-End still problematic
    • CF-End from the same QBSS reset NAV
    • But, this could result in collisions with OBSS

S. Choi, Philips Research

nav invalidated by hc
NAV Invalidated by HC
  • HC overrules the NAV values
    • ESTA shall respond to QoS (+)CF-Poll during CFB/CFP even with non-zero NAV
    • HC can reset NAV of ESTAs by sending QoS (+)CF-poll to itself with Dur/ID = 0
  • By having OBSS running HCF, a QBSS is not protected by NAV
    • ESTAs in OBSS may work independent of the NAV value per its HC ruling found above

S. Choi, Philips Research

the overlapping network allocation vector onav

The Overlapping Network Allocation Vector (ONAV)

Operation Rules under HCF

S. Choi, Philips Research

setting onav
Setting ONAV
  • Transition from CP to CFB/CFP
    • If an ESTA receives a QoS (+)CF-Poll and its NAV or ONAV is non-zero, save the value of max(NAV, ONAV) in the ONAV counter, and set the NAV using the Duration/ID field specified in the QoS (+)CF-Poll frame.
    • At TBTT when a CFP is scheduled to start, if an ESTA has non-zero NAV, the ESTA shall save the value of max(NAV, ONAV) in the ONAV counter, and set the NAV to dot11CFPMaxDuration

S. Choi, Philips Research

setting onav ii
Setting ONAV (II)
  • During CFB/CFP
    • Upon reception of a valid frame, which has been determined to come from an OBSS, the ESTA shall update their ONAV using the Duration/ID field, but only when the new ONAV value is greater than the current ONAV. When an ESTA updates its ONAV, that ESTA also saves the MAC address from the BSSID field if it is present in the frame.
    • For a frame reception, either NAV or ONAV (not both) may be updated.

S. Choi, Philips Research

frames from obss
Frames from OBSS?
  • Can check via BSSID in frames
  • Problem: RTS, CTS and ACK frames don’t carry BSSID
  • We need a rule to detect where the frame is coming from (see next)

S. Choi, Philips Research

frames from obss ii
Frames from OBSS? (II)
  • TXsrc: Tx Source address
    • TXsrc = MAC address of HC by default
    • TXsrc = DA of a QoS (+)CF-Poll received
    • TXsrc reverts to HC address when NAV becomes 0
  • For each frame without BSSID field
    • If RTS: compare the SA of the RTS with TXsrc
    • If CTS or ACK: compare the DA of the CTS or ACK with TXsrc

If SARTS or DACTS,ACK = TXsrc The frame is coming

from the own QBSS

S. Choi, Philips Research

resetting onav
Resetting ONAV
  • Upon reception of one of the following frames that arrived from the OBSS that last updates the ONAV:
    • QoS CF-Poll addressed to the HC with a Duration/ID field equal to 0
    • QoS Data(+) frame with the NF bit equal to 0 or
    • CF-END

(If the ONAV was last updated with an RTS, CTS or ACK frame, the ESTA does not know which OBSS last updated the ONAV. In this case, the ESTA shall reset the ONAV when it receives one of the frames listed above that has arrived from any alien BSS, irrespective of the value of the BSSID)

S. Choi, Philips Research

adjusting onav
Adjusting ONAV
  • ESTA that uses the Dur/ID field from an RTS frame to update its ONAV may save the previous value of ONAV. If no PHY-RXSTART.indication is detected from the PHY during a period with a duration of (2 x aSIFSTime) + (CTS_Time) + (2 x aSlotTime) starting at the PHY-RXEND.indication corresponding to the detection of the RTS frame, the ESTA may set the ONAV with the following value:

max [0, old ONAV value – ((2 x aSIFSTime) + (CTS_Time) + (2 x aSlotTime))]

S. Choi, Philips Research

limitations of the onav
Limitations of the ONAV
  • More than one overlapping BSS
    • ONAV can only track the OBSSs if the BSSID is received in the frame that updates it.
    • If ONAV updated and saved BSSID, reset ONAV when a CF-Poll with the Dur/ID equal to 0, Data with NF=0 or CF-END is received from the OBSS
    • IF ONAV updated with RTS,CTS or ACK, reset ONAV whenever a CF-Poll with the Dur/ID field equal to 0, Data with NF=0 or CF-END is received from any OBSS

S. Choi, Philips Research

transmission rules using nav and onav

Transmission Rules Using NAV and ONAV

Operation rules using NAV and ONAV

Solving the NAV limitations

S. Choi, Philips Research

using nav and onav
Using NAV and ONAV
  • Conditions:
    • Operation under HCF(ONAV not updated during non-CFB Contention Period)
    • All the ESTAs can hear from the HC
  • NAV updated ONLY with frames coming from its BSS
  • ONAV updated with frames coming from an OBSS
  • Contention allowed only when both counters are 0

S. Choi, Philips Research

rules using nav and onav
Rules using NAV and ONAV
  • In the non-CFB Contention Period
    • An ESTA can contend for the medium and respond to RTS only if both NAV and ONAV are zero
    • If ESTA receives QoS (+)CF-Poll frame, only respond with QoS Data(+) to the Poll if NAV and ONAV are zero.
    • However, always generate QoS CF-ACK frame upon successful reception of a frame that requires acknowledgement irrespective of NAV/ONAV values

S. Choi, Philips Research

rules using nav and onav ii
Rules using NAV and ONAV (II)
  • In the CFB/CFP
    • Respond to QoS (+)CF-Poll and RTS from the TxOP holder only when the ONAV is zero
    • Always generate QoS CF-ACK frame upon successful reception of a frame that requires acknowledgement

S. Choi, Philips Research

solving the rts cts problem

TBTT signaling a

CFP in BSS1

STA2,1

B

RTS

AP1

D1 + Poll

U1 + ACK

CFP in BSS1

RTS duration

Revert ONAV

2 x SIFS + CTS_Time + 2 x Slot

Solving the RTS/CTS problem

Reception

ESTA1,2

Transmission

NAV ESTA1,2

ONAV ESTA1,2

S. Choi, Philips Research

solving the cf end problem

TBTT signaling a

CFP in BSS1

AP1 Poll

AP1 Poll

OBSS

AP1

B

ESTA1,2

ESTA1,1

CF-END

CF-END

PIFS

CFP in BSS1

LEGACY RESET NAV

ESTA RESET ONAV

Solving the CF-END problem

Reception

ESTA1,2

Transmission

NAV ESTA1,2

ONAV ESTA1,2

(ONAV was set previously in the CP)

S. Choi, Philips Research

moreover
Moreover...
  • ONAV can be a good solution for avoiding unnecessary collisions with OBSSs
    • It protects my QBSS from OBSSs
    • When ESTAs in OBSSs use ONAV, my QBSS is protected
    • To be fair to OBSSs, my ESTAs should use ONAV as well
  • And provides fairness to the OBSSs
    • Enables fair bandwidth share among OBSSs

S. Choi, Philips Research