[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [manet] Hiden- & exposed terminal problem in MANET
Hi,
The solutions that have been proposed for solving the hidden terminal
problem in various MACs like 802.11, MACA etc. assume bi-directional links
so that RTS CTS packets can be exchanged. But what happens if the links are
unidirectional due to nodes with asymmetric ranges ??? In this case the MAC
cannot do much about the problem and packet loss has to be handled at the
higher layers. And in most cases, the exposed terminal problem will be
implicitly solved if the links are unidirectional. Correct me if I am wrong.
Regards,
Sudarshan N Raghavan
MS, Computer Science
NC State University
----- Original Message -----
From: "Mullen, John P. (Contractor)"
<mullenjp.contractor@trac.wsmr.army.mil>
To: "Jing Deng" <jdeng01@ecs.syr.edu>
Cc: <manet@ietf.org>
Sent: Thursday, September 19, 2002 11:08 AM
Subject: RE: [manet] Hiden- & exposed terminal problem in MANET
> Hi Jing,
>
> I agree that solving the exposed terminal problem will increase
throughput,
> but I don't see how to do this without introducing some sort of signaling,
> which will lead to consequent delay and overhead. Certainly, a MAC that
> solves this problem would improve the performance of an actual network.
> However, it would still have some additional delay and/or loss of
bandwidth,
> compared to the "perfect" MAC Liaw was considering.
>
> :-)
>
> John Mullen
>
> -----Original Message-----
> From: Jing Deng [mailto:jdeng01@ecs.syr.edu]
> Sent: Thursday, September 19, 2002 8:48 AM
> To: 'manet@ietf.org'
> Subject: RE: [manet] Hiden- & exposed terminal problem in MANET
>
>
> Hi John,
>
> I have a slightly different view regarding to the hidden/exposed terminal
> problem. While the hidden terminal problem may degrade the transmission
> throughput and increase the overall delay (so we need to solve it), the
> exposed terminal problem is actually "beneficial" if it is solved.
>
> The reason is that exposed terminals should re-use the channel, but they
> will not be allowed to do so if the MAC layer protocol is not designed
> carefully.
>
> By solving the exposed terminal problem, we can actually improve the
> throughput and delay performance because of the space reuse of the
> shared channel.
>
> So solving the problem does not introduce "extra waiting". On the
> contrary, it shortens the unnecessary waiting.
>
> Best Regards,
>
> Jing
>
>
> ----------------------------------------------------
> Dr. Jing Deng Email: jdeng01@ecs.syr.edu
> 2-191 CST, CASE Center Phone: (315) 443-3029 (O)
> Syracuse University
> Syracuse, NY 13244
> ---------------------- @_@ -------------------------
>
>
> On Thu, 19 Sep 2002, Mullen, John P. (Contractor) wrote:
>
> > Hi Liaw,
> >
> > You will probably get several answers on this. Here is my view.
> >
> > 1. The hidden and exposed terminal problems can be alleviated at the
MAC
> > level, but will impact the MANET protocol. That is, the MAC's job is to
> > manage the problem, but the MANET protocol should make allowances for it
> > because "solve" may mean waiting until the condition goes away. I'm not
> > aware of any MANET protocols that attempt to solve these problems, but
> they
> > are generally designed with those possibilities in mind.
> >
> > 2. It depends what you mean by "perfect." The goal of the MAC layer is
> to
> > manage things in order to get the best performance possible out of the
> > media. The hidden and exposed terminal problems are situations that can
> be
> > handled, but the handling is likely to introduce some delay. Other
media
> > problems might lead to corrupted packets, which will have to be resent.
> > There is also a matter of control packets, such as RTS and CTS. So, if
> your
> > "perfect" model provides for a loss of bandwidth due to overhead and
delay
> > in some way, you will have a realistic simulation. However, if by
> "perfect"
> > you mean that every packet is sent the first time without delay, you
will
> > have something that is not realistic. This is not to say you cannot do
> > this. In fact, most people start with such an ideal MAC to simplify
> > debugging of their higher-layer models. However, if you do not later
> > introduce a more realistic MAC model, your results will be overly
> optimistic
> > and you may miss conditions that could arise from MAC overhead and
delay.
> >
> > I recently worked with a student who was comparing protocols for
satellite
> > communications. When he had a noise-free channel, there were very large
> > differences among the alternatives. However, when he introduced noise,
> the
> > differences became much smaller and, what had looked like the best
> > alternative in the noise-free model became one of the worst in the more
> > realistic one.
> >
> > 3. Again, you should allow for the impact of the solution on bandwidth
> and
> > delay. MAC protocols are effective, but they cannot do magic.
> >
> > 4. This is hard to say. If the multipath fans out and areas of
activity
> > end up being far enough from each other that there is no mutual
> > interference, the impact could be minimal. It is possible that the MAC
> > could make multipath very efficient. It is also typical that the MANET
> and
> > MAC protocols would make multipath more efficient than the alternative
of
> > sending the packets to each of the intended destinations, one at a time.
> >
> > When a node transmits a packet, all nodes within range can hear it.
When
> > there is a single path, only one of those nodes will rebroadcast in
order
> to
> > forward the packet. In multipath, several may do so. The MAC can
reduce
> > interference if it "knows" who has heard each broadcast and minimizes
the
> > number of nodes that rebroadcast to a set that will propagate the
multiple
> > paths.
> >
> > This could be considered a MANET task, in which case, the MAC will
provide
> > the MANET protocol with a table of nodes that are expected receive each
> > broadcast and the MANET protocol will choose which ones will
rebroadcast.
> > On the other hand, the problem could be handled directly in the MAC.
For
> > example, the MANET protocol could specify that nodes a, b, c, and d are
on
> > the multipath, but the MAC suppresses c, knowing that if a, b, and d
> > rebroadcast, all nodes covered by c would have already received the
> packet.
> > I don't think the division of tasks at this point has been finalized (I
> > could be wrong on this).
> >
> > Good luck in your research. This is an interesting and significant
> problem
> > to study. However, just remember what Einstein said:
> >
> > Things should be made as simple as possible,
> > But, no simpler.
> >
> > :-)
> >
> > John Mullen
> >
> >
> > -----Original Message-----
> > From: Liaw, Yong Shyang - LIAYS001
> > [mailto:Yong.Liaw@postgrads.unisa.edu.au]
> > Sent: Thursday, September 19, 2002 2:47 AM
> > To: 'manet@ietf.org'
> > Subject: [manet] Hiden- & exposed terminal problem in MANET
> >
> >
> > Hi,
> >
> > I had read a few papers that described hiden-terminal & exposed terminal
> > problem in MAC that severely hinder the transmission of data packets in
> > multihop (i.e. MANET) environment. For example, it can causes "false"
> link
> > failure by ad-hoc routing protocol suchb as DSR, to initiate a route
> > discovery.
> > I have few questions and would appreciate if you can help me:
> >
> > 1. The hidden-terminal and exposed terminal problems are MAC layer
> problem,
> > hence they should be solved in the MAC layer. Is this a fair statement?
> >
> > 2. If it is, does that mean that I can design an ad-hoc routing protocol
> (or
> > higher protocol) without any consideration for the MAC charateristics?
Or
> in
> > another word, can I assume that I have a "perfect" MAC layer (i.e.
without
> > the
> > hidden- & exposed-terminal problems), and simulate my ad-hoc
> > routing/transport
> > with this assumption?
> >
> > 3. I would like to argue that the above 2 problems in MAC will probably
be
> > solved in the future by new MAC, such as the Dual Busy Tone Multiple
> Access
> > (DBTMA), and hence the above assumption is reasonable. (assuming that I
am
> > only
> > interested in the ad-hoc routing protocol). Is this a weak arguement?
Are
> > there any other MACs that address the above 2 MAC problems?
> >
> > 4. More specifically, I'm particularly interested in the multipath
routing
> > in
> > MANET. My concern is that multipath may allow us to inject more traffic
> > into
> > the MANET, and excite more nodes simultaneously. This will likely to
mean
> > that
> > there are more MAC contention problems due to hidden-terminal, and
> > exposed-terminal problem. Am I right?
> >
> > I would appreciate if you can help me, or point me to works that address
> the
> > problem. Thank you.
> > _______________________________________________
> > manet mailing list
> > manet@ietf.org
> > https://www1.ietf.org/mailman/listinfo/manet
> > _______________________________________________
> > manet mailing list
> > manet@ietf.org
> > https://www1.ietf.org/mailman/listinfo/manet
> >
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www1.ietf.org/mailman/listinfo/manet
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www1.ietf.org/mailman/listinfo/manet
>
_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet