cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
12324
Views
29
Helpful
21
Replies

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

kfarrington
Level 3
Level 3

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

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

View solution in original post

21 Replies 21

jeromehenry_2
Level 3
Level 3

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

Good way to put it Jerome!

-Scott
*** Please rate helpful posts ***

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

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

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

Take care dude

Ken

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.

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

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

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...

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.

@jeromehenry_2

 

Hi,

 

Is the NAV value used when access points needs to send data to clients? In other words, time period specified by NAV value can be used by clients not only for transmitting but also for receiving data?

Hi Johnny,

 

"Is the NAV value used when access points needs to send data to clients?", > yes, inside the AP. The AP is just like the other stations in most cases, so it counts down etc just like the others, it just happens to send quite more than a single client, but its contention mechanism is the same (again, "in most cases", there are 2 cases described in 802.11, called PCF and HCCA, where the AP may use different rules, but these cases are not implemented in 'normal' networks).

 

"time period specified by NAV value can be used by clients not only for transmitting but also for receiving data?" > no, the clients have no idea about the other stations', or the AP's internal NAV (please read my reply to your other question, the station can use the beginning of a transmission to re-adjust its NAV, but NAVs are not sent across to various stations).

 

hth

Jerome 

@jeromehenry_2

 

Is NAV value used by clients for receiving data from access points not only for transmitting data? If not, how is medium access managed when access point needs to send data to clients.

 

Thank you in advance.

@jeromehenry_2

 

Is NAV value used by clients for receiving data from access points not only for transmitting data? If not, how is medium access managed when access point needs to send data to clients.

 

Thank you in advance.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: