Understanding the PLCP Length field and how it relates to the NAV
Last Post: January 23, 2012:
-
After reading Marcus Burton's 802.11Arbitration White Paper for the ump-teenth time, and trying to find an answer in the 802.11 spec, I have come up against a wall.
In Fig. 4 of the WP it shows that the length field in the PLCP header defines the length of the [u]first[/u] frame including the MAC header, the MPDU, and the FCS.
However, the "duration" in that first MAC header describes the duration of the [u]subsequent frame, SIFS, or TXOP[/u]. Which is used to update/fill-in the NAV (of the listening stations).
Is there no [u]Virtual protection[/u] for the first frame? It would seem like the "length" should also be updating the NAV. That is unless the PLCP Length Field used to redefine the the CCA mechanism (timer) function. So that it is actually CCA that is holding off any interuptions ? After-all, the NAV doesn't get a chance to participate unless CCA is clear to begin with.
I don't know if this is one of the "details" omitted to make the WP easier to read, but it sure is hard to understand exactly what is going on here.
If anyone, especially Marcus, has an answer I sure would like to hear it.
Thanks,
Wlanman
-
Hi Wilanman
Not sure if this is what you are meaning or not:
As mentioned, the NAV will give an estimate of the amount of time remaining in the frame sequence ( assuming no interference etc?..i.e. under ideal conditions ). In the example shown, that would be the amount of time for one IFS plus an ack. Any station receiving that value would know how much time it has to wait prior to attempting to gain access to the medium, after the end of the frame in which it saw that particular value of NAV.
But what about the first frame, as you mentioned ? Depending upon the PHY in use, the PLCP header will either give a direct value in microseconds for how long that frame will last ( i.e. the first frame in the sequence ) or it will give it indirectly, via length and data rate information ( time = length/divided by data rate ). A microprocessor in the STA will calculate that value and load it into a register/counter. Data rate info is often given in the Sig field for example. Each PHY has it?s own methods, either a direct time indication or indirect calculation via length and rate.
So now, that STA as well as any others now know the total amount of time for the first frame and the remaining frame sequence ( in other words, the total amount of time from beginning to end of the entire sequence including the first frame ). There are a number of timers built into 802.11 devices. The device will take the value ( direct or calculated ) and will not allow access to the medium from the time of decoding the frame length until the end of the first frame, in microseconds. In other words, it will prevent access attempts until the end of that frame. On top of all that, it now knows the NAV value for the remaining sequence. Once a timer in the STA has completed ( in terms of the length time of the first frame ) , the NAV value will be loaded and the regular countdown will begin until the NAV reaches zero. At that point, contention for the media can begin again. So, two things:
1. Don?t attempt media access until the end of the frame that you are looking at.
2. Once that frame has completed ( in terms of time duration ), load a counter with the NAV and again, don?t try to access the media until the NAV value has counted down to zero.
So, the time to to transmit the first frame gives the 802.11 STA a form of ?first virtual carrier sense? before the ?real or more commonly known? NAV value starts it?s countdown.
I don?t know if that is what you were asking.Dave
-
Dave,
That is the conclusion I had come to, but I hadn't read anything on it, and the fact that it wasn't mentioned in Marcus's document, left me perplexed.
On further inspection of the 802.11 standard I found refences to the PLCP CS/CCA Timer, the CCA Timer, and a CCAreset.request Primitive. But still no single paragraph explaining it all.
I generally love state machines, but I just don't have time to puzzle this one out.
I am hoping that maybe Marcus has a fairly succint explanation.
- 1