Bugs & Issues in IEEE 802.11 MAC of ns-2

[ Back to Network Simulator 2 for Wireless ]

The discussion can be classified as two parts. 

  1. Part 1 is about the bugs and flaws of ns-2 802.11 code. This can be fixed.
  2. Part 2 comes from ambiguous understandings of the 802.11 standard or inherent 802.11 MAC problems. These need not to be fixed.

Part 1:

  1. Defer timer bug exposed in multi-rate settings
  2. Use Defer timer for backoff in send() and tx_resume()
  3. No direct access, always backoff
  4. Retransmission counter not reaching limits (ns-2.26)
Part 2:
  1. The physical channel rate to for ACK frames
  2. EIFS induced unfairness in 802.11 MAC

Bug leads to "EVENT UID Not Valid"

If we increase data rate and decrease packet size simulation with wireless
network, we will get an error message: "Scheduler: Event UID not valid!",

To remove this error,
Insert the following sentence before *every* tx_resume() function call:
if(mhDefer_.busy()) mhDefer_.stop();กก

A detailed analysis can be found in http://www.dei.unipd.it/wdyn/?IDsezione=2435

Use Defer timer for backoff in send() and tx_resume()

The backoff implementation in mac-802_11.cc does not comply with the standard. Basically, this is due to the introduction of a defer timer. The defertimer is set in send() and after a packet transmission finishes. The deferred time value is usually (DIFS+rTime) where rTime is as same as the selection of backoff timeslots from CW (Contention Window). However, the defertimer is never paused or resumed.

So, after a packet transmission, according to the IEEE 802.11 standard, the node should do backoff immediately. here in ns-code, the defertime is first set. And after timer out, in check_pktTx() function. if the channel is not idle, a backoff timer is set. Therefore, here exists a double backoff problem. 

To fix this problem, the defer timer usage shall be limited to only contain DIFS or EIFS, not extended to including backoffs.

MAC Access bug: No direct access, always backoff?

According to IEEE 802.11 standard, a node should access channel directly if it sense the channel idle and still idle after at least DIFS time. Here, in thte send() of ns-2 sourcecode, we can see that, by no means, the MAC will send the DATA or RTS frame directly without backoff. It deviates from the standard and adds an additional rTime before sending DATA or RTS.

The fix of this problem is not trivial. We have to add some memory in MAC to remember an extra Idle/Busy state variable. And if channel is idle after DIFS wait, the MAC shall check this variable again to determine if this node shall go to backoff or send the packet directly. 

I, personally, still prefer the design that there is always a backoff after DIFS-wait.  In this way, no nodes will take this advantage of direct access while other nodes are in backoff. It makes more sense, especially in a fair fashion.


 Blocking due to Retransmission Counter not reaching limits

In “Mac802_11::recvDATA” of ns-2.26


{.....
ssrc =0; //short retry-count set to 0
...
}

A<----->B---------------->C

From B to C, Infinite numbers of RTS get no response because SSRC cannot reach 7 (maximum allowed transmission times) because it was reset after a A-B DATA exchange

Update: This bug is fixed in new ns-2 versions.

ACK rate???

Excerpted from an ns-2 mail list discussion:

In NS-2 the ACK packet is always sent at basicRate_ (see file mac-802_11.cc). Typically this value is set to 1e6. In real world ACK
is sent at the same rate as the packet that triggered it ( the preceding DATA packet).
Is this true?

no one is denying that ACKs can be sent at 11Mbps - the only debate is whether they can be sent at 11Mbps when it is not one of the rates in the basic rate set.  Because the standard requires that ACK shall be sent in one of the basic rates.

So I'd have two questions about your measurements - (1) what is the basic rate set being advertised by a real AP? (2) Is it an 11g 802.11AP or STA? (As the rules for them are slightly different.)

It's possible that ACKs are being sent out at a non-basic rate.  It's a bad thing to do as it can lead to misaligned slots (and hence more
collisions) but the difference is probably not that noticeable in the real world.

I doubt that you'll find much of a difference in simulations as the ACK
frame is pretty short, and the transmission time is dominated by the PHY
headers.

EIFS-induced Unfairness

In the follwoing scenario, two flows A->B and B->C will have dramatically different throughput.
Suppose A can hear B, but can only sense C. In other words, C is within A's carrier-sensing range but out of the communication range.

A----->B---->C

The bandwidth sharing between A and B will be around 20%-80%. This is because C's ACK frame will be sensed by A, but not decoded. So, A will wait for EIFS after this before accessing the channel again. This gives B leverage to access the channel.

กก

กก

กก