Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Community Member

CSMA/CA NAV/Duration field and random backoff timer - Process

Hi guys,

Gotta a quick one for you.

Pls see text below

As a condition to accessing the medium, the MAC Layer checks the value of its network allocation vector (NAV), which is a counter resident at each station that represents the amount of time that the previous frame needs to send its frame. The NAV must be zero before a station can attempt to send a frame. Prior to transmitting a frame, a station calculates the amount of time necessary to send the frame based on the frame's length and data rate. The station places a value representing this time in the duration field in the header of the frame. When stations receive the frame, they examine this duration field value and use it as the basis for setting their corresponding NAVs. This process reserves the medium for the sending station.

An important aspect of the DCF is a random back off timer that a station uses if it detects a busy medium. If the channel is in use, the station must wait a random period of time before attempting to access the medium again. This ensures that multiple stations wanting to send data don't transmit at the same time. The random delay causes stations to wait different periods of time and avoids all of them sensing the medium at exactly the same time, finding the channel idle, transmitting, and colliding with each other. The back off timer significantly reduces the number of collisions and corresponding retransmissions, especially when the number of active users increases.

So, if all clients in a WLAN see a frame come from station A, and station A has set the duration field, all other stations set their NAV and wait until it expires.

THEN, i would expect all stations to start to contend for the medium at exactly the same time.

BUT you have the random backoff timer.

The question is does the NIC add a random number to the NAV field, ie, once it sees station As duration field value (lets say 300us) it adds 47us to this and the NAV is 347us? -- or do all stations decrement the NAV field to zero and then start a random backoff timer?

Many thx for the help,

Kind regards,

Ken

1 ACCEPTED SOLUTION

Accepted Solutions

Re: CSMA/CA NAV/Duration field and random backoff timer - Proces

That's exactly it Ken, and 5 for you too...

Just a last complement of information to make it perfect, machines count in slots, a slot can be 20 microseconds or 9 microseconds depending on if you use 802.11g/802.11a or 802.11b.

The rest of the process is exactly how you describe it. You pick up a number, say 16 (slots, so for example 320 us). countdown from that, checking the air at each slot.

Someone sends for 300 us, which is 15 slots, you add them and restart as you describe.

Thanks for getting to help people, the more we are, the clearer it all becomes!

Take care

Jerome

11 REPLIES

Re: CSMA/CA NAV/Duration field and random backoff timer - Proces

Hi Ken,

When a station wants to transmit, it picks up a random number, the backoff timer, from which it counts down before deciding to send.

Say you pick up 16. You count down from there (the speed of the countdown depends on if you use 802.11b, g or a).

Every time it decrements the counter, it listens to the air. If at that time a station is sending, it listens to the duration field, and increments its backoff timer accordingly.

So if, say when you counted down to 8 (8 slots to wait, suppose a slot is 20 microseconds, you have still 160 microseconds to wait), you hear a station send, for say your 300 microseconds, you just restart counting from 460, which is the same as waiting for the frame to be sent and resume the countdown.

Is this clear enough?

Kind regards

Jerome

Hall of Fame Super Silver

Re: CSMA/CA NAV/Duration field and random backoff timer - Proces

Good way to put it Jerome!

-Scott
*** Please rate helpful posts ***
Community Member

Re: CSMA/CA NAV/Duration field and random backoff timer - Proces

I think I have it.

Lets put it like this.

You say the random backoff is 16,

you count down to 15, it checks the air, you donot see a packet being transmitted.

you count down to 14, it check the air, you donot see a packet being transmitted.

you count down to 13, it checks the air, you donot see a packet being transmitted.

you count down to 12, it checks the ait, IT SEES a packet is being transmitted and the NAV 300us. NOW it sets is backoff time (is that correct, its the backoff timer it now sets) to 312us.

it now counts down to 311, it checks the air, and sees the same packet still being transmitted

it now counts down to 310, it checks the air, and sees the same packet still being transmitted

309, 308, 307 .............

gets down to 12us, checks the ait, NOW DOES NOT see a packet being transmitted.

you count down to 11, it check the air, you donot see a packet being transmitted.

you count down to 10, it check the air, you donot see a packet being transmitted.

9, 8, 7, 6, 5 ........

and if it gets to 0us (timer expired, it is able to transmit?

Would that be correct.

Im sorry for the long winded way I have put it, but if this is correct, I am a vey happy man indeed.

Im kinda getting used to this wireless stuff. Mainly thanks to you guys and everyone elses help.

Now its time for me to try any scan the posts and help other people if I can. Payback some of the experts help!!!

:)))))

Many kind regards,

Ken

Re: CSMA/CA NAV/Duration field and random backoff timer - Proces

That's exactly it Ken, and 5 for you too...

Just a last complement of information to make it perfect, machines count in slots, a slot can be 20 microseconds or 9 microseconds depending on if you use 802.11g/802.11a or 802.11b.

The rest of the process is exactly how you describe it. You pick up a number, say 16 (slots, so for example 320 us). countdown from that, checking the air at each slot.

Someone sends for 300 us, which is 15 slots, you add them and restart as you describe.

Thanks for getting to help people, the more we are, the clearer it all becomes!

Take care

Jerome

Community Member

Re: CSMA/CA NAV/Duration field and random backoff timer - Proces

Brill.. has completly resoved my issue mate :))

Take care dude

Ken

Bronze

Re: CSMA/CA NAV/Duration field and random backoff timer - Proces

Well done guys,

That's the DCF. Now add WMM and the EDCF cWMin/cWMax prioritized slot time ranges per the four QoS classes assigned to WLANs, and that's how the countdown crumbles. Except when there's devices that try to claim zero backoff (Spectralink phones) or infrastructures that set the NAV artificially high to favor time-sensitive traffic (Meru).

Also, from what I've been reading, the slot time for 802.11n is 4msec with the standard guard interval.

Community Member

Re: CSMA/CA NAV/Duration field and random backoff timer - Proces

Hi There.

Initially I thought wat? all these new terms and my head was hurting before I have even had my coffee.

Am now reading up on the following URL:

http://en.wikipedia.org/wiki/IEEE_802.11e

to help complete the understanding, so many thx for adding to the thread as this has got the brain ticking.

Any other good URLs would be fantastic.

Thx to all who are involved in this really interesting discussion :)

Kind regards,

Ken

Bronze

Re: CSMA/CA NAV/Duration field and random backoff timer - Proces

Hey,

Its one of those things -- while there are standards, there are still exceptions to the rules set out by the IEEE. It remains in question whether Meru's implementation is in violation of the spirit (DCF equal access) of the 802.11 MAC rules.

Spectralink's zero-backoff was part of their proprietary standard implementation of QoS (SVP, or Spectralink Voice Priority), before WMM existed.

BTW, I was incorrect in calling the WMM QoS enhancement EDCF. Its proper term is EDCA (Enhanced Distributed Channel Access). This flavor of QoS won out over HCCA (Hybrid Contrlled Channel Access), a poll-oriented

deterministic access control method (vs. the contention-based method of EDCA).

Her's a pretty good PDF discussing the two types.

http://www.iks.inf.ethz.ch/education/ss04/seminar/212.pdf

Re: CSMA/CA NAV/Duration field and random backoff timer - Proces

Hey Bruce,

A 4 for your nice link!

To me, Meru violates the rule... and ou can feel it when you try to have "normal" APs coexist with this kind of network...

HCCA is still in the IEEE 802.11e, right? It's just that, as PCF was never implemented, the WI-FI Alliance decided not to make it part of the WMM certificaiton... at least for now...

Bronze

Re: CSMA/CA NAV/Duration field and random backoff timer - Proces

Thanks,

My take is that the burden of implementing HCCA in the client OS has been too great. That and the risk of interactions similar to those indicated between the PCF-like Merus- of-the-world and everyone else has effectively squelched HCCA.

Re: CSMA/CA NAV/Duration field and random backoff timer - Proces

Sorry chaps, but I think you've got this wrong...

The whole point of a NAV being transmitted by the TX & RX ends is to stop hidden node issues - with both ends transmitting the NAV, you are guaranteeing that every 802.11 device within range of either end of the transaction is quiet for the duration of the NAV.

Lets say we have a TX (A) and an RX (B), and another device (C). Lets say that (A) can hear (B), and that (B) can hear (A) and (C). (A) and (C) cannot hear each other.

(A) <<>> (B) <<>> (C)

Applying that to your scenario...

<>

it now counts down to 310, it checks the air, and sees the same packet still being transmitted

309, 308, 307 .............

gets down to 12us, checks the ait, NOW DOES NOT see a packet being transmitted.

you count down to 11, it check the air, you donot see a packet being transmitted.

<>

The part where it jumps down from 312 to 11 is wrong. Just because (C) can't hear anything, doesn't mean that (B) isn't receiving something from (A).

What actually happens with NAV's is;

[Lets say (A) is transmitting to (B)]

1. (A) transmits NAV, value = "NAV-A"

2. (B) receives packet, along with everything else in range of (A), on the same channel as (A)

3. (B) responds to (A) with "NAV-B". "NAV B" = "NAV-A" [minus] "Elapsed Time"

4. (A) receives packet, along with everything in range of (B), on the same channel as (B)

At this point, every device on that channel will be silent for the duration of the NAV, regardless of whather or not they hear anything during the NAV countdown duration.

When the NAV expires, the Random Backoff Timer begins, and the lowest/ quickest client to get to zero then gets to transmit, and the whole process starts again.

Let me know what you think, but I'm pretty sure that's how it actually works.

Rgds,

Richard

5544
Views
19
Helpful
11
Replies
CreatePlease to create content