[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [manet] Hiden- & exposed terminal problem in MANET
Hello John,
I think, the hidden node and the exposed node problems can even be tackled
at the Physical layer, by using multiple codes, like the transmitter
directed codes?
Best Regards,
Sumeeth
----- Original Message -----
From: "Mullen, John P. (Contractor)"
<mullenjp.contractor@trac.wsmr.army.mil>
To: "Liaw, Yong Shyang - LIAYS001" <Yong.Liaw@postgrads.unisa.edu.au>
Cc: <manet@ietf.org>
Sent: Thursday, September 19, 2002 7:47 AM
Subject: RE: [manet] Hiden- & exposed terminal problem in MANET
> 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