Freeminded.org

IEEE 802.11p is designed for use in the V2V / V2I context. It uses an OFDM physical layer largely based on IEEE 802.11a. Some values are directly reused, others are modified. The slottime (often denoted with the Greek ‘sigma’ or aSlotTime) is one of those values which are unclear.

As a result, NS-2 and NS-3 erroneously use a wrong 802.11p slotTime of 13 microseconds. Scientific works using these simulators should carefully check sensitivity to this bug – results may be off!

802.11a uses a slotTime of 13 microseconds (as denoted in IEEE802.11-2007, it was 9 microseconds in IEEE802.11a-1999). An earlier draft version of 802.11p (D3.0 if I remember correctly) used 16 microseconds. The ‘final’ 802.11p standard IEEE 802.11p-2010 does not mention slottime at all. Many scientific works – even now in 2011 when IEEE 802.11p has matured to an accepted standard – still use either 13 or 16 microseconds. So which one is correct?

For one, there was a bug in NS-3 bug 1142. The funny thing is, the code contained a line saying SetSlot(Microseconds(16)); which was absolutely correct, though it was filed as a bug and then changed back to 13 microseconds; basically back to the 802.11a value. This could be considered ‘correct’ if one is to blatantly assume that “802.11p is based on 802.11a”. Indeed, it is based on it, with some very subtle differences. Duration of the slottime is one of them!

The 802.11 standard is very powerful, in that many MAC timing variables are derived from PHY specifics to allow the same MAC to run on different physical layers.

Many NS-2 simulation studies also use the 13 (e.g. this paper published in June 2011). Basically, any research using NS-2 (2.34 but also others) has this flaw, unless of course fixed by the researchers (yeay for Open Source software!).

Quoting the standard (IEEE 802.11-2007, 9.2.10 DCF timing relations):

aSlotTime = aCCATime + aRxTxTurnaroundTime + aAirPropagationTime + aMACProcessingDelay.

For 802.11a OFDM (10MHz channel spacing), using values found in the same document yield:

aCCATime = < 8 us 
aRxTxTurnaroundTime = < 2 us 
aAirPropagationTime = << 1 us
aMACProcessingDelay = < 2 us

And there's your 13 !

Now let's look at how this works for IEEE 802.11p OFDM, 10MHz channel spacing (values derived from the standard IEEE 802.11p-2010):

aCCATime = < 8 us
aRxTxTurnaroundTime = < 2 us
aAirPropagationTime = << 4 us (to work with TX ranges of ~1000m!)
aMACProcessingDelay = < 2 us

Voila, there's the 16 , primarily to accommodate for the larger airPropagationTime due to the larger range. Now let's no longer erroneously use 13 when doing simulation / analysis of IEEE 802.11p!