【转载】Fixed Bugs: 与NS2 timer中bugFix_timer_相关的文章解释

NS2.27-> Scheduler: Event UID not valid

Problem:
Sometimes, when we run simple TCL scripts involving the 802.11 wireless node, with original NS2 implementations (=no source code modified), NS returns errors of type

Scheduler: Event UID not valid

This error is returned during the simulation runs and depends on some mac 802.11 internal features combined with the intensity of the offered traffic.

Causes:
The send procedure of Mac 802.11 implemented in NS2 appears to contain the logical error described in the following.

The send procedure begins with the 'send' method of the class 'Mac802_11' in 'mac-802_11.cc' file. First, send checks whether the medium is idle and no previous backoff procedure is pending. If the response is true, send calls the internal DeferTimer procedure, which should simulate the random backoff stage described by the IEEE 802.11 standard. Notice that, despite what dictated by the standard concerning the backoff stage the internal DeferTimer procedure DOES NOT freeze the timer contdown if the channel becomes busy, since the channel sensing procedure is not considered. For this reason, in the following we will refer to this backoff procedure as PSEUDO BACKOFF.

The scenario when the send procedure fails is as follows.
Let us assume node A starts the send procedure for a packet adopting the internal DeferTimer, since
a) the post-backoff of the previous packet expired
b) the channel was sensed idle.

Meanwhile, node B starts transmitting a packet to node A. The packet may be either a RTS or a DATA packet. We call

• t0 the instant at which node A starts the send procedure
• rtime the random backoff time calculated by the node A (this means that the internal defer timer has been initialized with difs+rtime)
• t1 the time at which node A starts receiving the packet from node B
• D the B packet's transmission time;

We distinguish two possible cases:

1) Node A completes the reception of the B's packet before the pseudo backoff procedure is completed (t0+difs+rtime > t1+D).

In this case, the mac802_11 recv_timer method is called at the end of the receive procedure and, after some controls, it calls the recvRTS or the recvData method, according to the type B's packet. In the following we distinguish the two cases.

Case a): node B sends a DATA PACKET

The recvData method is invoked at node A. Hence, recvData calls the tx_resume method which, in turns, calls the internal DeferTimer in order to contdown a SIFS period before sending the ACK. Unfortunately, the DeferTimer was already in use by the pseudo backoff procedure. Therefore, the DeferTimer's start method tries to schedule an event that is already scheduled, and this ends up with the scheduler error of the kind 'Scheduler: Event UID not valid!' (as explained in the manual).

Case b): node B sends a RTS PACKET

The bug, in this case, seems to have been already fixed. Indeed, the recvRTS method checks whether the internal defer timer is in use, and in this case, it stops and restarts the defer timer, setting it to a SIFS. Hence, in the case of RTS/CTS the recvRTS method does not cause any scheduler error. Nevertheless, this patch does not appear completely compliant with the standard. In fact, when node A receives the ACK from B (at the end of the receveing procedure), A restarts the backoff procedure selecting a new random number (without incrementing the contention windows and the retry counter) and using the internal DeferTimer.

2) Node A DOES NOT complete the reception of the B's packet before the pseudo backoff procedure is completed (t0+difs+rtime < t1+D).

The standard requires the backoff procedure to freeze, but the 802.11 MAC class handles this event doubling the contention window as required by the backoff procedure after a collision. However the retry count is not incremented. This is probably due to previous attempts to fix code bugs.

Proposed Solution:

Case 1) and 2) can be both fixed with the following.

We modified the MAC802_11 class implemented in mac-802.cc in order to always use the backoff timer when it must start a transmission, regardless the medium is sensed idle or busy. We also changed the send method and the tx_resume method accordingly.

In order to use the backoff timer only, we needed to overcome a limitation of the backoff timer's start method. In fact, the DIFS value was used only in the resume method, i.e. when the medium becomes idle (see mac-timers.cc and mac-timers.h)
Thus, when the MAC initially senses the medium idle, there was no mean to wait for a DIFS before starting the backoff procedure, since simply the DIFS value is not there. Then, we have modified the BackoffTimer's start method adding a optional parameter saying if it is going to wait only a DIFS or not:

• original declaration:
  void start(int cw, int idle);
• modified declaration:
  void start(int cw, int idle, double difs = 0.0);

The parameter is optional, so we don't change the syntax of the mac802_11 class call.

Conclusion:

If our understanding is correct, we believe that such kind of sofware errors are typical when a module has been implemented incrementaly from more persons. In plain ns-2.27, with the basic access mode, the error is still there, causing the scheduler error in object. On the contrary, the error does not appear with RTS/CTS mode since a correction has been made to fix the bug. However, we believe that such a correction was not completely compliant with the procedure described in the standard and, therefore, it might potentially lead to altered statistics

 

文章出处： http://www.dei.unipd.it/wdyn/?IDsezione=2435