[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [manet] Hiden- & exposed terminal problem in MANET
RTS/CTS do not fully solve the problem.
Check out the paper:
"Ordered Packet Scheduling in Wireless
Ad Hoc Networks: Mechanisms and Performance Analysis,", Mobihoc 2002.
-Vikram
> 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
>
--
Department of ECE, Rice University | 713 348 3786 (O)| 713 664 5650(H)
WWW: http://www.ece.rice.edu/~kanodia
_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet