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

[kfarrington]

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

[Jerome Henry]

Hey Johnny,

Haven't been following this old thread for a while, but in short, the NAV is an internal process to a station ready to transmit (it is not exchanged over the air between stations, imaging how impractical this scheme would be in a cell at CiscoLIve with 150 stations on an AP :)). It is used only to determine how long the station ends up having to wait before a transmission effectively occurs. So it is not used to "receive" traffic.

However, when a station sends, the header contains the duration of the transmission. So a station counting down can read another station's frame read the duration field, add that value to its counter, and doze for that duration (instead of counting down and hearing at each step what it already knows, i.e. that the other station is still transmitting, just like it said it would).

Hope this helps

Jerome

[Johnny.Ores]

@Jerome Henry

Thank you for your reply. 

During downlink transmission from AP to clients, does AP broadcast data to all associated clients and gets ACK only from destination device while other devices just discard it?

[Jerome Henry]

Hi Johnny,

The sender (the AP) constructs a frame which header has 3 MAC addresses. The first is the intended destination (the client) MAC< the second is the sender, (the AP, identified by its MAC address for that SSID, called the BSSID), and the third address is the original source of the frame (if the AP is relaying the frame from the wire, for example).

All stations in the cell detecting the transmission will read the frame header to understand who the destination is, then all stations except the intended receiver will ignore the frame once they read the first MAC address. The intended receiver will read the whole frame, verify that the checksum is okay, then send an ACK frame back to the AP.

You can read more on these address structures in many documents, for example here: https://mrncciew.com/2014/09/28/cwap-mac-headeraddresses/

hth

Jerome

[Johnny.Ores]

@Jerome Henry

Thank you, you have helped a lot. Just one more thing - is RTS/CTS part of any medium access techniques such as DCF, or it can be observed as a supplement to them?

[Jerome Henry]

Not sure I follow what you mean, please ask again if the answer is not what you are looking for:

RTS/CTS are control frames, they are part of the normal frames defined by 802.11 and expected in a cell.

However, 802.11 does not specify cases where you 'must' or 'should never' use them. They are optional.

Some clients start using RTS/CTS when the AP load is high (AP advertises the load in the beacons); some clients start using RTS/CTS if they experience a lot of collisions (frames sent and not acknowledged, even when the data rate is low - this is commonly caused to collisions with other clients on the other side of the cell that the local client cannot hear, and this phenomenon is called the 'hidden node problem', because the other client (or 'node') is hidden to (not detected by) the local client); some clients start using RTS/CTS when their buffer get full (to increase the chance of collision less transmission), etc.

Take care

Jerome 

[Johnny.Ores]

@Jerome Henry

Thanks a lot. Now I have clearer picture about it.

[Richard Atkin]

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