[Cu-wireless] 802.11 & multihop networks

[Zachary C. Miller]

Sascha Meinrath wrote:
> Is it possible to modify the RTS/CTS protocol so that (as in your example
> below) when node B gets a RTS from A it says to other nodes "talk amongst
> yourselves" and they don't communicate with B for the requisite time (but
> can still commmunicate with each other)?  Or is the problem more
> complicated, for example, if B doesn't have any ability to filter out the
> noise from C when it's talking with D?

It is more complicated for the reason you said. 

Only one radio can have signal on the medium at a time. If 2 radio
transmit on the same medium at the same time then neither of their
signals get through.

Y
     A    B    C    D
Z

So the problem is not with D talking to C because it is imperative
that C not talk back so D would probably fail talking to C. The
problem is with Z talking to Y (where Z and Y are neighbors of A but
neither are neighbors of B). Z and Y _should_ be allowed to talk
because they won't interfere with the receiver at B but there is no
way for the network to know that.

I haven't read the papers but it seems like the solution would be to
change the meanings of the two messages to be "I'm talking to B so if
you planned on talking to me or B you should shut up." and "I'm being
talked to by A so if you aren't A and you can hear this shut up." Then
C would shut up and Z and Y would know not to talk to A. D (neighbor
to C but not B) could send to C but C couldn't reply. 

I'm guessing changing this would mean hacking the firmware on all the
radios in the network. Not really something that is going to happen
outside the domain of theory...so I'd think we'd just have to live
with it and keep our pods small as we already knew we had to. (Or we
could change to a heirarchical design with directional antennas... :)

> On Wed, 16 Apr 2003, David Young wrote:
> 
> > Here is my explanation of RTS/CTS packets in 802.11, and some references
> > to research concerning 802.11 in multihop networks such as C-U Wireless
> > is building. The research results are either cause for despair, if you're
> > into that kind of thing, or cause for some creative problem-solving.
> >
> > Stations in an 802.11 network may use RTS/CTS to quiet their neighbors
> > before transmitting or receiving, respectively. The 802.11 committee
> > intended RTS/CTS to improve performance in networks where every station
> > cannot hear every other, but there are so-called "hidden nodes". Just
> > for an example, say we have nodes A, B, and C:
> >
> >    [A]         [B]          [C]
> >
> > A and B are in radio range. A and C are not in radio range, however B
> > and C are. Say that both A and C have packets queued for B. Suppose for
> > simplicity's sake say that A senses the medium before C, and detects that
> > it is quiet. A begins its transmission to B. Before A's transmission
> > finishes, C also senses the medium, detects that it is quiet, and
> > begins to transmit.  A's and C's packets collide at B, so B does not
> > send an acknowledgement to either. Both A's and C's packets have to be
> > re-sent. In this way, a lot of precious bandwidth can be wasted.
> >
> > RTS and CTS are short messages that help coordinate hidden nodes to
> > conserve bandwidth.  When A detects that the medium is quiet, it sends B
> > an RTS. The content of the RTS is "I'm talking to B for X microseconds,
> > all y'all shut up." If B receives the RTS, B sends back a CTS whose
> > content is "A is talking to me for X microseconds; all y'all shut
> > up." This shuts-up B's neighbors, including C, until A sends the Data
> > packet and B sends an ACK.
> >
> > Great, huh? Well, sort of. Remember that A's neighbors are shut up
> > for the duration of A's CTS/Data/ACK transaction with B. In that
> > time, none of A's neighbors could have transmitted to A, however,
> > they could have transmitted to other stations in the network
> > while A sent a Data packet to B. The paper called "Solution ot
> > the Exposed Node Problem of 802.11 in Wireless Ad-Hoc Networks"
> > <http://www.cs.iastate.edu/~vel/research/E-MAC.pdf> describes a
> > backwards-compatible modification to 802.11 that solves the problem
> > in simulations.
> >
> > Another deficiency of RTS/CTS is that with its use, network throughput
> > does not settle to a maximum figure as network load approaches infinity,
> > but it actually drops to zero!  The paper "RTS/CTS-Induced Congestion
> > in Ad Hoc Wireless LANs" <http://people.bu.edu/staro/wcnc-ray.pdf>
> > discusses the problem and describes a backwards-compatible modification
> > to 802.11 that solves it in simulations.
> >
> > TCP/IP and 802.11 wireless do not always get along.  In simulations,
> > when two TCP streams are channeled into the same 802.11 receiver, one
> > will dominate all of the bandwidth under certain conditions. A paper
> > on this is called "Does IEEE 802.11 MAC Protocol Work Well in Multihop
> > Wireless Ad Hoc Networks"; search for the title with Google.
> >
> > Dave
> >
> >
> 
> _______________________________________________
> Cu-wireless mailing list
> Cu-wireless at lists.groogroo.com
> http://lists.cu.groogroo.com/cgi-bin/listinfo/cu-wireless
> Project Page: http://cuwireless.ucimc.org
> 

-- 
Zachary C. Miller - @= - http://wolfgang.groogroo.com/
IMSA 1995 - UIUC 2000 - Just Another Leftist Muppet - Ya Basta!
 Social Justice, Community, Nonviolence, Decentralization, Feminism,
 Sustainability, Responsibility, Diversity, Democracy, Ecology