June 2001
S. Choi, Philips ResearchSlide 1
doc.: IEEE 802.11-01/272a
Submission
Problems with IEEE 802.11(e) Problems with IEEE 802.11(e) NAV Operation NAV Operation
and ONAV Proposaland ONAV Proposal
Javier del Prado, Sunghyun Choi, and Amjad Soomro
Philips Research-USABriarcliff Manor, New York
June 2001
S. Choi, Philips ResearchSlide 2
doc.: IEEE 802.11-01/272a
Submission
• Introduction• The Overlapping BSS problem• NAV rules under HCF • Limitations of NAV rules when OBSS• ONAV proposal
OutlineOutline
June 2001
S. Choi, Philips ResearchSlide 3
doc.: IEEE 802.11-01/272a
Submission
Introduction Introduction Importance of NAVThe OBSS problem
Overlapping NAV (ONAV)
June 2001
S. Choi, Philips ResearchSlide 4
doc.: IEEE 802.11-01/272a
Submission
HCF Relies on NAVHCF 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
June 2001
S. Choi, Philips ResearchSlide 5
doc.: IEEE 802.11-01/272a
Submission
The OBSS problemThe 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
June 2001
S. Choi, Philips ResearchSlide 6
doc.: IEEE 802.11-01/272a
Submission
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
June 2001
S. Choi, Philips ResearchSlide 7
doc.: IEEE 802.11-01/272a
Submission
The Network Allocation VectorThe Network Allocation Vector(NAV)(NAV)
NAV Rules under HCF(See document 01/373r0)
June 2001
S. Choi, Philips ResearchSlide 8
doc.: IEEE 802.11-01/272a
Submission
Setting NAV under HCFSetting 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
June 2001
S. Choi, Philips ResearchSlide 9
doc.: IEEE 802.11-01/272a
Submission
Resetting NAV under HCFResetting 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
June 2001
S. Choi, Philips ResearchSlide 10
doc.: IEEE 802.11-01/272a
Submission
Adjusting NAV under 802.11eAdjusting 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))]
June 2001
S. Choi, Philips ResearchSlide 11
doc.: IEEE 802.11-01/272a
Submission
NAV Problems in 802.11-1999NAV Problems in 802.11-1999when OBSS existswhen OBSS exists
RTS/CTSCF-END(+)
June 2001
S. Choi, Philips ResearchSlide 12
doc.: IEEE 802.11-01/272a
Submission
AP1 AP2
1STA ,12STA ,1
• STA1,2 is the 2nd STA in BSS 1.
1STA ,2
Overlapping BSS: ExampleOverlapping BSS: Example
June 2001
S. Choi, Philips ResearchSlide 13
doc.: IEEE 802.11-01/272a
Submission
Potential NAV Reset after RTSPotential 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.”
June 2001
S. Choi, Philips ResearchSlide 14
doc.: IEEE 802.11-01/272a
Submission
RTS Problem: ExampleRTS Problem: Example• STA1,2 reset NAV during CFP
U1 + ACK
STA1,2
Reception
Transmission
D1 + Poll AP1
STA2,1
RTS
NAV STA1,2
RTS duration
RESET NAV
CFP in BSS1
TBTT signaling aCFP in BSS1
B
2 x SIFS + CTS_Time + 2
x Slot
June 2001
S. Choi, Philips ResearchSlide 15
doc.: IEEE 802.11-01/272a
Submission
NAV Reset per CF-EndNAV Reset per CF-End
• The CF-END problem– Current rule: Reset NAV upon reception of
CF-END– CF-END can come from an OBSS
June 2001
S. Choi, Philips ResearchSlide 16
doc.: IEEE 802.11-01/272a
Submission
NAV Problems in 802.11e QoS Draft D1NAV Problems in 802.11e QoS Draft D1when OBSS existswhen OBSS exists
RTS/CTSCF-End
June 2001
S. Choi, Philips ResearchSlide 17
doc.: IEEE 802.11-01/272a
Submission
Inherited from 802.11-1999Inherited 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
June 2001
S. Choi, Philips ResearchSlide 18
doc.: IEEE 802.11-01/272a
Submission
NAV Invalidated by HCNAV 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
June 2001
S. Choi, Philips ResearchSlide 19
doc.: IEEE 802.11-01/272a
Submission
The Overlapping Network The Overlapping Network Allocation Vector (ONAV)Allocation Vector (ONAV)
Operation Rules under HCF
June 2001
S. Choi, Philips ResearchSlide 20
doc.: IEEE 802.11-01/272a
Submission
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
June 2001
S. Choi, Philips ResearchSlide 21
doc.: IEEE 802.11-01/272a
Submission
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.
June 2001
S. Choi, Philips ResearchSlide 22
doc.: IEEE 802.11-01/272a
Submission
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)
June 2001
S. Choi, Philips ResearchSlide 23
doc.: IEEE 802.11-01/272a
Submission
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
June 2001
S. Choi, Philips ResearchSlide 24
doc.: IEEE 802.11-01/272a
Submission
Resetting ONAVResetting 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)
June 2001
S. Choi, Philips ResearchSlide 25
doc.: IEEE 802.11-01/272a
Submission
Adjusting ONAVAdjusting 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))]
June 2001
S. Choi, Philips ResearchSlide 26
doc.: IEEE 802.11-01/272a
Submission
Limitations of the ONAVLimitations 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
June 2001
S. Choi, Philips ResearchSlide 27
doc.: IEEE 802.11-01/272a
Submission
Transmission Rules Using Transmission Rules Using NAV and ONAVNAV and ONAV
Operation rules using NAV and ONAV
Solving the NAV limitations
June 2001
S. Choi, Philips ResearchSlide 28
doc.: IEEE 802.11-01/272a
Submission
Using NAV and ONAVUsing 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
June 2001
S. Choi, Philips ResearchSlide 29
doc.: IEEE 802.11-01/272a
Submission
Rules using NAV and ONAVRules 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
June 2001
S. Choi, Philips ResearchSlide 30
doc.: IEEE 802.11-01/272a
Submission
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
June 2001
S. Choi, Philips ResearchSlide 31
doc.: IEEE 802.11-01/272a
Submission
Solving the RTS/CTS problemSolving the RTS/CTS problem
CFP in BSS1
TBTT signaling aCFP in BSS1
B
U1 + ACK
ESTA1,2
Reception
Transmission
D1 + Poll AP1
STA2,1
RTS
NAV ESTA1,2
RTS duration
Revert ONAV2 x SIFS +
CTS_Time + 2 x Slot
ONAV ESTA1,2
June 2001
S. Choi, Philips ResearchSlide 32
doc.: IEEE 802.11-01/272a
Submission
Solving the CF-END problemSolving the CF-END problem
CFP in BSS1
TBTT signaling aCFP in BSS1
BESTA1,2
Reception
Transmission
ESTA1,2
AP1 Poll OBSSCF-END
NAV ESTA1,2
ESTA RESET ONAV
AP1
CF-END
LEGACY RESET NAV
ESTA1,1
AP1 Poll
PIFS
(ONAV was set previously in the CP)
ONAV ESTA1,2
June 2001
S. Choi, Philips ResearchSlide 33
doc.: IEEE 802.11-01/272a
Submission
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
Top Related