A New Approach to the NAV

1. A New Approach to the NAV Author: Matthew Sherman AT&T Labs - Research 180 Park Avenue Florham Park, NJ 07932 973-236-6925 mjsherman@att.com Date: June 12, 2001 Matthew Sherman, AT&T Labs - Research

2. 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 Matthew Sherman, AT&T Labs - Research

3. 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) Matthew Sherman, AT&T Labs - Research

4. 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 Matthew Sherman, AT&T Labs - Research

5. 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 Matthew Sherman, AT&T Labs - Research

6. 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 Matthew Sherman, AT&T Labs - Research

7. 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 Matthew Sherman, AT&T Labs - Research

8. 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. Taken from 01/308r0 by Michael Fischer Matthew Sherman, AT&T Labs - Research

9. 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 Matthew Sherman, AT&T Labs - Research

10. 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 Matthew Sherman, AT&T Labs - Research

11. 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! Matthew Sherman, AT&T Labs - Research

12. Own BSS CFP NAV CFP NAV 2 CFP NAV N Duration NAV Context 0 Context 1 Context N-1 Duration Context Counter 0 Set 0 Counter 1 Set 1 Counter N-1 Set N-1 Counter N Block Diagram of NAV Function Counter Sets and Resets not Shown … Other NAV . . . Full 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 Matthew Sherman, AT&T Labs - Research

13. 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) Matthew Sherman, AT&T Labs - Research

14. 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 Matthew Sherman, AT&T Labs - Research

15. 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) Matthew Sherman, AT&T Labs - Research

16. 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 Matthew Sherman, AT&T Labs - Research

17. 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 Matthew Sherman, AT&T Labs - Research

18. Other Capabilities • Make NAV state accessible via MIB • Include full NAV context Matthew Sherman, AT&T Labs - Research