[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [manet] Hiden- & exposed terminal problem in MANET

To: Sudarshan N Raghavan <snraghav@ieee.org>, "Mullen, John P. (Contractor)" <mullenjp.contractor@trac.wsmr.army.mil>, Jing Deng <jdeng01@ecs.syr.edu>
Subject: Re: [manet] Hiden- & exposed terminal problem in MANET
From: Sumeeth Nagaraj <snagaraj@cc.usu.edu>
Date: Thu, 19 Sep 2002 10:39:01 -0600
Cc: manet@ietf.org
List-help: <mailto:manet-request@ietf.org?subject=help>
List-id: Mobile Ad-hoc Networks <manet.ietf.org>
List-post: <mailto:manet@ietf.org>
List-subscribe: <https://www1.ietf.org/mailman/listinfo/manet>,<mailto:manet-request@ietf.org?subject=subscribe>
List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/manet>,<mailto:manet-request@ietf.org?subject=unsubscribe>
References: <02Sep19.090834mdt.117122@gw.trac.wsmr.army.mil><007601c25ff1$16f99e50$1a6c0198@ecew2k.ncsu.edu>
Sender: manet-admin@ietf.org

Hi Sudarshan,

The exposed node problem will not be solved if the links are
uni-directional. In all cases, the possibility of packet collision and
retransmission is very high if uni-directional links exists.

Best Regards,
Sumeeth

----- Original Message -----
From: "Sudarshan N Raghavan" <snraghav@unity.ncsu.edu>
To: "Mullen, John P. (Contractor)" <mullenjp.contractor@trac.wsmr.army.mil>;
"Jing Deng" <jdeng01@ecs.syr.edu>
Cc: <manet@ietf.org>
Sent: Thursday, September 19, 2002 9:27 AM
Subject: 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

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet

References:
- RE: [manet] Hiden- & exposed terminal problem in MANET
  - From: Mullen, John P. (Contractor)
- Re: [manet] Hiden- & exposed terminal problem in MANET
  - From: Sudarshan N Raghavan

Prev by Date: Re: [manet] Hiden- & exposed terminal problem in MANET
Next by Date: Re: [manet] Hiden- & exposed terminal problem in MANET
Previous by thread: Re: [manet] Hiden- & exposed terminal problem in MANET
Next by thread: RE: [manet] Hiden- & exposed terminal problem in MANET
Index(es):
- Date
- Thread