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