Doc.: IEEE 802.11-01/372r0 A New Approach to the NAV June, 2001 Matthew Sherman, AT&T Labs - ResearchSlide 1 A New Approach to the NAV Author: Matthew

June, 2001

Matthew Sherman, AT&T Labs - ResearchSlide 1

doc.: IEEE 802.11-01/372r0

A New Approach to the NAV


Author:Matthew Sherman

AT&T Labs - Research180 Park Avenue

Florham Park, NJ 07932973-236-6925

[email protected]

Date: June 12, 2001

June, 2001


doc.: IEEE 802.11-01/372r0


What is the NAV• Mechanism for implementing Virtual Carrier Sense

– Allows STA to know channel is busy when CCA may not be triggered

• Presented conceptually as a count down timer – Counts down time till channel is idle again– Wireless Medium considered busy if NAV non-zero– See 802.11-1999 Clause 9.2.1

• Description of NAV and rules effecting it distributed throughout 802.11-1999– Can’t find all the rules in one section– Takes detailed reading to understand all effects and exceptions

June, 2001


doc.: IEEE 802.11-01/372r0


802.11-1999 NAV Rules• Set NAV at start of CFP if > current setting (9.3.2.2)

– CFP parameter values from Beacon or Probe Response– Must update NAV prior to first Tx in BSS– Originating PC does not set NAV– Recurring value (Automatic set every CFP)– Set regardless of which BSS Beacon CFP parameters are from

• Do they over write each other? -> YES!• Set NAV for Valid duration if > current settings (9.2.5.4)

– Don’t set NAV if frame addressed to STA– Implied don’t set NAV if source STA– Nonrecurring value

• Set NAV for Ack+SIFS if PS-Poll (7.2.1.4)• Auto reset when NAV expires (9.2.1)• Reset NAV if CF-End (9.3.2.2)

– Ignores address in CF-End • Reset NAV even if CF-End for another BSS!

– Reset even if NAV not set for CFP (set for frame sequence)• May be resetting NAV even it was set for a frame sequence!

• May Reset NAV if RTS with no CTS and no frame start after CTS time (9.2.5.4)• Ignore NAV to respond ACK (9.2.8)• Ignore NAV for Poll response (9.3.3.1)• Do not respond or TX for any other frame if NAV set (3.36)

June, 2001


doc.: IEEE 802.11-01/372r0


Some Observations• Affecting Mechanism

– CFP parameters– Duration field– Arrival / non arrival of some frame types

• Independent of duration field

• Both recurring, and non-recurring sets occur • Resets are “implied”

– Reset if “counter counts to zero”

• Resets can also be caused by events – Received frame– Did not receive frame

• NAV is ignored for some frame types

June, 2001


doc.: IEEE 802.11-01/372r0


Deficiencies in NAV• Not well suited for dealing with multiple PCF

parameter sets– Parameter set can interact, and be unstable

• May appear to be constantly changing if hear 2 PCFs with different parameter sets

• Never really sure which CFP parameter set will be obeyed

– CF_End from one BSS can reset CFP for another BSS

• Duration and CFP parameters mechanisms interact– CF_End may reset NAV during frame sequence

• Frame sequences may inappropriately ignore NAV– Not sensitive to context of NAV

June, 2001


doc.: IEEE 802.11-01/372r0


Additional HCF NAV Rules• CFB protected via duration values rather than CFP parameters (9.1.3)

– Protecting mini-CFP rather than specific frame sequence– Also uses CFP parameters (9.10.1)

• Within TXOP Respond to frames from TXsrc with NAV set (9.10.2.1)– TXsrc own TxOp

• Set as RA from first (+)CF-Poll of CFB if own BSSID• Clear if NAV=0, update NAV from different source, Container from TXsrc with Non-final=0,

Non-QoS data or Non Container Management received• Clear if CF-End from BSSID

– Same as existing rules?– Ignore NAV for RTS, Probe, Data (any type)

• Respond CTS if NAV set (7.2.1.1)– CFP only or CFB as well?– Respond even if NAV set for ongoing frame sequence

• Respond RR to CC if NAV not set (except for CC) (9.10.4.2)– What if set for CFP?

• Assumed NAV ignored for RR under CFP?• If NAV set, respond only QoS CF-Ack(no data) to QoS data types, even if (+)CF-

Poll (9.10.2.1)– This does not make sense since means can’t be polled by HC

June, 2001


doc.: IEEE 802.11-01/372r0


Undocumented HCF NAV Rules(From 01/308)

• If NAV set for TxOP, reset if – QoS data frame with NF=0

– Any management type frame.

– The TXOP expires

– WM idle for DIFS• TXOP extended by time borrowed by HC

– Means NAV setting must be updated as well

June, 2001


doc.: IEEE 802.11-01/372r0


NAV Usage During TXOP• This diagram shows the periods covered by the NAV, based on Duration field

values in the various frames of a TXOP during which the polled ESTA initiates several QoS Data frame exchanges.

S RTS CTSS S QoS Data

NF=1S QoSCF-Poll

QoSCF-Ack

TIME

NAV from RTS is Duration from CF-Poll less (RTS time + SIFS time) NAV from QoS Data is Duration from CTS/ACK less (Data time + SIFS time)

S

NAV from CTS is Duration from RTS less (CTS time + SIFS time)

TXOP Limit specified in (+)CF-Poll

S QoSCF-Ack

QoS DataNF=1 S

QoSCF-Ack

QoS DataNF=0

NAV from ACK is Duration from Data less (ACK time + SIFS time)

S S

NAV from (+)CF-Poll covers (TXOP limit + DIFS time) DIFS

HC may transmit

EDCF contention may resume at

end of NAVTaken from 01/308r0 by Michael Fischer

June, 2001


doc.: IEEE 802.11-01/372r0


So What Should the NAV Be?• Functionally it is a set of counters - not one counter• Each counter has a context

– Set of parameters describing what counter is counting• If counter is set, transmission is suppressed in some circumstances• Resets due to frames received / not received only affect specific

counters, not all counters, depending on context• If =0, counter does not suppress transmission• Many different realizations possible, and may only require one counter

with additional registers– Virtual (Software) NAVs

• This is a generalization of the existing NAV

June, 2001


doc.: IEEE 802.11-01/372r0


What is appropriate context?• Collection of parameters required to determine applicability of counter• Context may be explicit, or implicit

– Implicit if dedicated counter

• Prior to HCF, sufficient context would include– Event causing set (CFP or Duration)– Frame Type Causing set (if Duration)

• Need to know if RTS

– BSSID (if CFP)– CFP Parameters (if CFP)

• Additional context required for HFC

June, 2001


doc.: IEEE 802.11-01/372r0


Rules for Improved legacy NAV• Set dedicated CFP NAV counter at start of CFP for each BSSID

– Multiple CFP NAVs (Recommended 7 minimum)– CFP parameter values from Beacon or Probe Response

• If no counter assigned for BSSID set up new counter• If no counters available, overwrite BSSID (other than own) for least recently updated• May also filter on Beacon signal strength keeping strongest beacons

– Recurring value (Automatic set every CFP)– Must update NAV for own BSSID prior to first Tx in BSS– Originating PC does not set NAV

• Set Duration NAV for Valid duration if > current setting– One dedicated Duration NAV – no CFP sets or resets – Don’t set NAV if source or destination STA– Nonrecurring value

• Set NAV for Ack+SIFS if PS-Poll• Auto reset when NAV expires• If CF-End, Reset CFP NAV for corresponding BSSID• Reset Duration NAV if RTS with no CTS and no frame start after CTS time• Ignore All NAVs to respond with ACK or to Poll

– Respond only Ack or Null if NAV set for Duration or BSS CFP other than own– Set More Data bit if have data to respond with, but suppressed by NAV– Respond normally if only own BSS CFP NAV set

• Do not respond or transmit for any other frame if any NAV set

RED indicates changes from existing 802.11 1999 Rules!

June, 2001


doc.: IEEE 802.11-01/372r0


Block Diagram of NAV Function

…

...Other NAV

For implementation shown, CFP Counters are used to count time to next CFP as well, and use Set bit to differentiate between 2 counts

Own BSSCFP NAV

Set 0

Counter 0

Context 0

CFP NAV 2

Set 1

Counter 1

Context 1

Duration NAV

Counter N

DurationContext

Set N-1

CFP NAV N

Counter N-1

Context N-1

Full NAV

Counter Setsand Resetsnot Shown

June, 2001


doc.: IEEE 802.11-01/372r0


Additional HCF NAV Rules

• Ignore own BSS CFP NAV for responding to – RTS (Respond CTS)– Probe (Respond Probe Response)– CC (Respond RR as appropriate)

• Create CFB NAV– Set by Duration value– Non-recurring set

• Set CFB NAV on QoS Poll from HC– Set from Duration field in Poll

• Reset CFB NAV if New QoS Poll from HC– Set to new Duration field from Poll (Even if smaller)

• Reset CFB NAV if CF-End from Own BSS• Ignore CFB NAV for responding to

– RTS (Respond CTS)– Probe (Respond Probe Response)– CC (Respond RR as appropriate)

June, 2001


doc.: IEEE 802.11-01/372r0


New TxSup NAV Capability• Add new TX suppression (TxSup) NAVs • Customized to individual STA environment• Use Management Action Frame to Load context

– Allow Multicast & Broadcast Addressing

• Same parameters as CFP NAV• Same response rules as CFP NAV• Takes precedence over CFP NAVs

– (except Own BSS CFP)– If out of NAVs

• replace oldest CFP NAV with new TxSup NAV

• If multiple TxSup NAV’s always keep most recent

June, 2001


doc.: IEEE 802.11-01/372r0


Software NAV Realization• Single NAV Register

– Each bit in Register represents one NAV state

• Full NAV Mask defining Valid NAV’s• Other NAV Mask

– excludes own BSS CFP & CFB NAVs

• Each NAV has following Context– NAV Type (Duration, CFB, CFP, TxSup)– Frame Type of last set (Null if not set or CFP)– Time of last set– CF Period (Null if Duration or CFB)– CF Length (Null if Duration or CFB)– BSSID (Null if Duration or TxSup)

June, 2001


doc.: IEEE 802.11-01/372r0


Software NAV Realization Cont.

• Maintain Time ordered Pending Event list– Recommended minimum of 16 Events supported

• Event context– Time of Event

– NAV Number (Bit of NAV effected)

– Type of event (Set or Reset)

– Qualifiers• RTS Auto Reset

– Cancel if CTS or start of response frame detected

June, 2001


doc.: IEEE 802.11-01/372r0


Soft NAV Realization Cont. 2

• Timer set for Current Event

• If timer expires, implement event / set next event

• If frame received– Check if potential NAV impact– Process based on rules presented earlier in this

document

June, 2001


doc.: IEEE 802.11-01/372r0


Other Capabilities

• Make NAV state accessible via MIB– Include full NAV context

Documents

Doc.: IEEE 802.11-01/372r0 A New Approach to the NAV June, 2001 Matthew Sherman, AT&T Labs - ResearchSlide 1 A New Approach to the NAV Author: Matthew