Re: [ns] Accuracy of wireless simulation with nodes sending dataathigh rate.

[Vikram Kanodia <kanodia@ece.rice.edu>]

 Hi,

There is a well documented starvation problem with 802.11 specially with
overlapping broadcast regions.......consider the topology:

              3
1------->2    |
	      |
              4

1 is sending to 2 and 3 to 4....2 is within the transmission range all the
other 3 nodes but 3 and 4 cannot hear 1 (can do carrier sense though)....

Now if both 1 and 3 have a hight traffic load (always
backlogged)...consider that 3 gets the channel....and 1 tries at the same
time....since 2 defers to 1-->3 transmission, 1 repeatedly doubles its
backoff window (RTS timeout as collission at 2).....that means once 3
finishes its transmission it backsoff again but for CWmin only before
trying again....so 1 again loses out and so on.....thus starving out
1....1 does sometimes get lucky and gets a packet through...but this does
not have that big an effect on 3-->4 flow as 4 can receive 3's RTS
correctly..it just can't reply right then as it is defering to 2's
CTS...the larger data packet from 1-->2 does not really affect flow 3-->4
(except for an EIFS defer.....4 hears 1's data but only in form of carrier
sense...)...typically EIFS_ is much smaller than the data packet time....


This behavior has been borne out by simulations and has been observed in
many papers (see mobicom 00,99 papers).......

Thus the RTS/CTS although solves the hidden terminal problem (that is data
does not collide only RTS's do)...it does not eliminate the unfairness
introduced as aresult....


-Vikram

> Thanks for your answer.
> 
> But in fact, the RTS/CTS mechanism is already in use in my simulation.
> And the problem doesn't appear as long as the nodes are in the direct
> transmission range of their respective neighbors.
> I think the RTS/CTS mechanism is doing is job well as long as a node can
> receive the RTS and send back a CTS ... but in my simulation, beyond the
> fifth second, they are too far away, and only get noise.
> 
> However, I think the RTS/CTS mechanim is involve in the problem I have. In
> fact, in the range where problem appears, the central pair of node seems to
> be unable to send *any*  RTS/CTS ! (or only on or two, from time to time)
> It's quite clear when using MAC trace and nam, as we can see the
> corresponding broadcast. Meanwhile, the other pairs of node are sending their
> RTS/CTS in a perfectly normal way.
> 
> As I said, I suspect a problem with a non-random behavior of the senders (at
> the lowest level ?), but I don't know what to try ...
> 
> I hope real 802.11 cards doesn't behave this way... (I should add that this
> problem doesn't appear (or is hidden by something else ?) in most of the
> simulations I ran. The case I have presented is the most representative I
> have founded).
> 
> "Ratish J. Punnoose" wrote:
> 
> > This particular behavior could be in part due to the hidden terminal
> > problem that RTS/CTS should help with.
> >
> > As (a,b) get farther from (e,f).  They cannot hear each other and can
> > operate at the same time.  However (c,d) can hear both of these and
> > therefore defer transmissions.  Therefore they will not have an equal
> > share of the media.
> >
> > This would be one explanation.  Not sure if there are other factors
> > contributing to your problem.
> >
> > > I'm a PhD student interested in wireless ad-hoc networks, and I have
> > > done some simulation whith ns2.
> > > But the results I got seems quite strange to me, and as I do not have
> > > any real 802.11 card, I have no way to be sure these results are
> > > accurate. (considering what I got, I hope they are not, or that I have
> > > done some mistake )
> > >
> > > Could someone give me some advice on the following :
> > >
> > > I simulated 3 pair of nodes (a,b),(c,d) and (e,f).
> > >
> > > - a is sending data to b, c to d and e to f.
> > > - Each sender try to send as much data as possible (using CBR).
> > > - I haven't done any modification to ns-allinone 2.1b7a which I use
> > > - The following happens whatever wireless routing protocol I use
> > > - I use the two-ray ground reflection radio propagation model
> > > - The problem appears only if I use most of the bandwith
> > >
> > > During the simulation, the two nodes of a pair stay very close to the
> > > each other. (5 length units)
> > > At the beginning of the simulation, the 3 pairs are very close.
> > >
> > > One pair will stay at it's starting position, one will go away at a
> > > speed s, and the third will go away in the same direction at a speed 2s.
> > >
> > > we obtain something like this, the distance between each pair increasing
> > > slowly.
> > > (a)->(b)                              (c)->(d)
> > > (e)->(f)
> > >
> > > At the beginning, as all nodes are close, the three data streams are
> > > fairly sharing the available bandwith.
> > >
> > > We would have expected that at some point, each pair would have (more or
> > > less suddently) gain access to the full bandwith, as the interferences
> > > with the others pairs get lower and lower.
> > > In the end, it effectively happens, but the problem is that there is an
> > > intermediate state where the sender of the central pair cannot send data
> > > to it's receiver anymore ! (c cannot send to d, which is only 5 length
> > > units away !)
> > >
> > > [as I wasn't sure it is permited to attach pictures to mails on this
> > > mailing list, here is a link to a small graph :
> > > http://www.ens-lyon.fr/~ddhoutau/images/ns_pb.gif ]
> > >
> > > this graph show the data rate for each stream (in bit per second),
> > > depending on time (in second).
> > > Moreover, the *problem* is happening when the distance between the pairs
> > > is between 1 and 2 times the maximum transmission range of a node !
> > > (after 5 seconds, the central pair is out of the direct transmission
> > > range of the others pairs (but of course is not yet out of their
> > > interference range))
> > >
> > > The red curve show what happens to the central pair (c)->(d) ... And
> > > there I don't known what to do ....
> > >
> > > I suspect a problem with some "not realy independant" random behavior of
> > > my senders.
> > > But I don't know where I should look ....
> > >
> > >
> 
> 

-- 

Department of ECE, Rice University | 713 348 3786 (O)| 713 664 5650(H)
WWW: http://www.ece.rice.edu/~kanodia