Subject: [manet] IEEE 802.11 MAC collision implementation in NS2

From: "sabeel ansari" <[email-masked]>
Date: 30 Jul 2002 18:51:29 -0000

Hi
I was going through the IEEE 802.11 MAC source code in the NS2. 
Here, it says that when a collision takes place,
check the two packets and discard the packet which is going to end 
earlier. Shouldnt it be the other way around.

void
Mac802_11::collision(Packet *p)
{
 	switch(rx_state_) {
 	case MAC_RECV:
 		SET_RX_STATE(MAC_COLL);
 		/* fall through */
 	case MAC_COLL:
 		assert(pktRx_);
 		assert(mhRecv_.busy());
 		/*
 		 *  Since a collision has occurred, figure out
  		 *  which packet that caused the collision will
  		 *  "last" the longest.  Make this packet,
  		 *  pktRx_ and reset the Recv Timer if necessary.
  		 */
 		if(TX_Time(p) > mhRecv_.expire()) {
 			mhRecv_.stop();
 			discard(pktRx_, DROP_MAC_COLLISION);
 			pktRx_ = p;
 			mhRecv_.start(TX_Time(pktRx_));
 		}
 		else {
 			discard(p, DROP_MAC_COLLISION);
 		}
 		break;
 	default:
 		assert(0);
 	}
}

sabeel

_______________________________________________
manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet

---

From: "Sorav Bansal" <[email-masked]>
Date: Wed, 31 Jul 2002 10:47:06 +0530

Hi Mineo,

    I had a chance to go through your paper and I agree with both the
points you have mentioned. In one of my works, in case of a collision, I
kept a pointer to the packet that lasts longer and also set the receive
power of that packet to the sum of the receive powers of the two packets.
This is a conservative approach (Though this implementation is not
absolutely correct, I chose this just due to the ease of implementation).

    I would like to point to another issue in the MAC implementation. As
you mention, each receiver can receive a packet only if there was no
interference or Ps/Pi was always above a certain threshold (10 dB by
default) during the packet reception. If the packet with the higher power
(Ps) arrives later than the packet with rxpower Pi, the second packet is
dropped even though it is 100 times stronger than the first signal. This
seems like an implementation bug. After talking to a few people, I gathered
that it is because if the receiver is tuned to the chip rate of the first
packet, it cannot decipher the second packet no matter how strong the
second packet signal is. Even if this is true, the problem however is:
      If the first packet (Pi) is only being carrier-sensed (not being
received), then it makes no sense to "capture" the second packet if Ps/Pi >
10dB (since the first packet is not actually being received-it is just
acting as noise for the receiver).

      It would be great if this could be corrected (assuming this is a
valid error) by the ns people (I would be glad to volunteer to make these
changes in ns).

Regards,
Sorav

PS: Please let me know if this is not the right place to be discussing
this. As Mineo said, I believe many people on this list use ns-2

                      Mineo Takai                                                                                              
                      <[email-masked]        To:       sabeel ansari <[email-masked]>                          
                      u>                       cc:       [email-masked]                                                        
                      Sent by:                 Subject:  Re: [manet] IEEE 802.11 MAC collision implementation in NS2           
                      manet-admin@ietf.                                                                                        
                      org                                                                                                      

                      07/31/02 03:33 AM                                                                                        

Hello Sabeel,

This question may be more appropriate for the ns-2 users mailing list,
but I am describing what that piece of ns-2 code does because I know
many people on this list use ns-2. When a collision happens at a node,
the model keeps a pointer to the packet that lasts longer than the other
in order to use its power (Pi) as the basis of interference. When
another signal (packet) comes in, it checks the power of the new signal
(Ps), and computes Ps/Pi. Each node can receive each packet only when
there was no interference, or Ps/Pi was always above a certain threshold
(I think it is 10 dB by default) during the packet reception.

The model keeps a pointer to the packet whose transmission lasts longer
because it may interfere with more forthcoming packets. However, there
are many problems with it:
- It does not consider the power value. The model simply chooses the
packet that lasts longer even if the reception power of the other packet
whose transmission ends sooner by 1 nanosecond is 100 times stronger.
- The actual interference is cumulative. When multiple signals other
than the signal of interest are present, SIR (Signal to Interference
Ratio) must be calculated using power from all signals currently on the
channel. The model abstracts out this effect, and is inaccurate when
there are multiple interference sources (transmitters or jammers) in the
network. There is no consideration of noise in the model either.

One of my papers may be useful to understand these issues:

Effects of Wireless Physical Layer Modeling in Mobile Ad Hoc Networks
Mineo Takai, Jay Martin and Rajive Bagrodia
Proceedings of the 2001 ACM International Symposium on Mobile Ad Hoc
Networking & Computing (MobiHoc 2001), pp. 87-94, October 2001.
(ftp://pcl.cs.ucla.edu/pub/papers/mobihoc.ps)

After this publication, I noticed ns folks fixed another problem pointed
out in the paper (preamble length), but this interference modeling have
not been fixed yet. It is much harder to fix it than the other, and the
modification may significantly slow down ns-2. However, in my opinion,
it should be worth fixing.

Regards,

Mineo

---

From: "Sorav Bansal" <[email-masked]>
Date: Wed, 31 Jul 2002 10:47:06 +0530

Hi Mineo,

Regards,
Sorav

                                                                                                                               
                      Mineo Takai                                                                                              

                      07/31/02 03:33 AM                                                                                        

Hello Sabeel,

Regards,

Mineo