[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [manet] Hiden- & exposed terminal problem in MANET
Hi,
> Why can't we use RTS/CTS handshaking to get rid of the hidden node
problem.
yeah, RTS-CTS exchange is used to aviod hidden node problem.
> Can anyone explain the exposed node problem?
Consider 4 nodes, 1, 2, 3, 4: Node 1 cannot hear node 3 and 4 and same holds
good the other way too. node 3 can hear node 2 and 4, but node 2 and node
4 cannot hear each other.
1 2 3 4
When node 2 has data packet to send to node 1, node 3 on hearing the RTS
packet(though data packet is meant for node 1), node 3 refrains from sending
data packet to node 4. Here node 3 is exposed to node 2's transmission.
result is poor resource utilization.
Hope I am clear 8-)
Best Regards,
Sumeeth
> Thanks,
> Shweta
>
> University of Colorado at Boulder.
>
> Phillip Neumiller wrote:
> > Multiple spreading codes that are pseudo-orthogonal (or completely
> > orthogonal in the case of a synchronous system) can be used to
> > provide multiple channels in the same bandwidth. That could help
> > alleviate the hidden node problem, but is difficult to acheive
> > in a pure ad hoc system without very expensive clocks.
> >
> > The solution to hidden nodes is MUCH easier. Get rid of the omni
> > antennas and hidden node, exposed node, self-interference all go
> > away. This is easier said than done. This is the "real" solution
> > since it gets rid of the problem rather than dancing around it
> > at the MAC layer with RTS CTS handshaking.
> >
> > It is far better to do the root cause analysis here. If you think
> > about this long enough, you will realize that using omnis in an
> > ad hoc network is the "Easy way out" and only a few folks have thought
> > carefully about the alternatives.
> >
> >
> > Best regards,
> >
> > Phil
> >
> > -----Original Message-----
> > From: Mullen, John P. (Contractor)
> > [mailto:mullenjp.contractor@trac.wsmr.army.mil]
> > Sent: Thursday, September 19, 2002 1:32 PM
> > To: Sumeeth Nagaraj
> > Cc: manet@ietf.org
> > Subject: RE: [manet] Hiden- & exposed terminal problem in MANET
> >
> >
> > Hi Sumeeth,
> >
> > I'm not sure what you mean by "multiple codes." Could you expand on
this?
> >
> > Thanks,
> >
> > John Mullen
> >
> >
> >
> > -----Original Message-----
> > From: Sumeeth Nagaraj [mailto:snagaraj@cc.usu.edu]
> > Sent: Thursday, September 19, 2002 10:45 AM
> > To: Mullen, John P. (Contractor); Liaw, Yong Shyang - LIAYS001
> > Cc: manet@ietf.org
> > Subject: 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
> >
****************************************************************************
> > This e-mail is intended only for the addressee named above and may
contain
> > confidential, proprietary or privileged information. If you are not the
> > named addressee or the person responsible for delivering the message to
the
> > named addressee, please inform us promptly by reply e-mail, then delete
the
> > e-mail and destroy any printed copy. The contents should not be
disclosed to
> > anyone and no copies should be made. We take reasonable precautions to
> > ensure that our emails are virus free. However we accept no
responsibility
> > for any virus transmitted by us and recommend that you subject any
incoming
> > e-mail to your own virus checking procedures.
> > _______________________________________________
> > 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