[Cu-wireless] 802.11 & multihop networks

[Sascha Meinrath]

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?

--Sascha

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
>
>