Freeminded.org

I’ve spent some time comparing MiXiM simulation results with some
analytical work with IEEE802.11-2007 in hand, and I wonder if Mac80211 as implemented in MiXiM 2.1
contains an error. I have posted on the Google groups and made a bugreport, but no replies. I have a fix for this bug (see below).

In short, the standard says (9.1.1):

• Sense channel for DIFS
• if idle, transmit immediately
• if busy, defer (e.g. perform random backoff)

If the channel is sensed idle (channel.isIdle() performs instantaneous CCA at a single moment) Mac80211 sets a timer (senseChannelWhileIdle) for currentIFS (DIFS). Upon expiration, the Signal is transmitted.
This is conform the standard.

But if the contention is interrupted by a transmission from a different node, the backoff is suspended and later resumed for DIFS. This still satisfies the standard’s requirement that contiguous frames
should be separated by a ‘minimum specified duration’, but it should have performed a random backoff in stead (the medium turned busy during the CCA).

The result is that many transmission attempts do not go through random backoff but only a deterministic ‘one IFS’ backoff, resulting in many simultaneous backoff counter expirations and subsequent collisions.

The problem increases with an increasing number of nodes – the probability of another node transmitting during an IFS increases (assuming Poisson arrivals and 0 remainingBackoff). As the number of nodes increases further, the medium is more often determined to be busy by channel.isIdle() and random backoff is performed.

1. Does anyone have the same experience?
2. Am I reading the standard correctly? (would like some discussions on this)
3. I am going to provide a fix for this, compare it with my analytical work and see if results coincide. I will get back to the group with results.

ps. I am using a modified Mac80211 – where I use AIFS in stead of DIFS. AIFS for low-priority traffic (as per 802.11e) is SIFS+9*ST, so my IFS durations are longer than the DIFS (SIFS+2*ST) in the original
model. However, the same occurs in the original Mac80211 (with the most recent MiXiM from the Git repository).

Fixing the bug

In suspendContention(), we check if(quietTime < currentIFS). This is where you get the "EV << "suspended during D/EIFS (no backoff)" << endl;" message. This is ok if it was part of a backoff, but not if it was part of the CCA! So we keep a bool "txImmediately". If this is true, we were interrupted during our CCA and perform remainingBackoff=backoff();, this fixes the problem. We set txImmediately to true in beginNewCycle(), in if(!contention->isScheduled()) and if(channel.isIdle())’s else clause, when remainingBackoff==0.

References
Sourceforge bugreport:

Google Groups message: http://groups.google.com/group/omnetpp/browse_thread/thread/294d15e70f436b9a

Recently, I have also found another error in the implementation of the backoff mechanism: Bug in Mac80211 in MiXiM backoff when channel busy.