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

From: "Mullen, John P. (Contractor)" <[email-masked]>
Date: Thu, 19 Sep 2002 11:32:02 -0600

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:[email-masked]]
Sent: Thursday, September 19, 2002 10:45 AM
To: Mullen, John P. (Contractor); Liaw, Yong Shyang - LIAYS001
Cc: [email-masked]
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)"
<[email-masked]>
To: "Liaw, Yong Shyang - LIAYS001" <[email-masked]>
Cc: <[email-masked]>
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:[email-masked]]
> Sent: Thursday, September 19, 2002 2:47 AM
> To: [email-masked]'
> 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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/manet
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/manet
_______________________________________________
manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet

---

From: Sumeeth Nagaraj <[email-masked]>
Date: Thu, 19 Sep 2002 12:01:44 -0600

Hello John,

Each node has a unique PN code in the network and transmits using its own PN
code. The transmitter senses the channel for the known PN codes, if the
receiver is idle(data not for this node) then the node switches to the
transmitter and transmits. The ACK can be for cumulatively sent for a set of
packets or for individual packet. Since the PN-codes are unique in the
network, the hidden node problem is addressed, the node need not be idle
till the completion of data transfer of neighboring nodes and this addresses
the exposed node problem. Am I missing something here?

Best Regards,
Sumeeth

----- Original Message -----
From: "Mullen, John P. (Contractor)"
<[email-masked]>
To: "Sumeeth Nagaraj" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, September 19, 2002 11:32 AM
Subject: RE: [manet] Hiden- & exposed terminal problem in MANET

---

From: Sumeeth Nagaraj <[email-masked]>
Date: Thu, 19 Sep 2002 12:01:44 -0600

Hello John,

Best Regards,
Sumeeth

---

From: [email-masked]
Date: Fri, 20 Sep 2002 02:09:25 +0530 (IST)

hi,

> the exposed node problem. Am I missing something here?

A better way is to use a set of codes.  A sender includes in its
RTS (sent over a common code) a preferred code (unused at
that time) and receiver sends CTS if the code is acceptable.
Then DATA-ACK takes over the selected code.

This could be similar to the Multichannel MAC protocol proposed by
Nasipuri et.al.

Infact Z.J. Haas's "DBTMA" is a very good solution for Ad hoc wireless
networks for Hidden and Exposed terminals.

-thanks

-bsm..

B.S.Manoj, Research Scholar, High Performance Computing and Networking Lab,
CSE Dept., IIT Madras, India,  Ph: 5330 (Internal calls only).
--------------------------------------------------------------------------

---

From: [email-masked]
Date: Fri, 20 Sep 2002 02:09:25 +0530 (IST)

hi,

-thanks

-bsm..

---

From: Sumeeth Nagaraj <[email-masked]>
Date: Thu, 19 Sep 2002 15:10:16 -0600

Hi Manoj,

> Then DATA-ACK takes over the selected code.

The idea of using multiple codes was to remove the RTS-CTS over head.
RTS-CTS can cause congestion problems for a netowork with high density of
nodes.

You can give a look at the channel access scheme proposed by Dr. Schlegel:
Here they have a common  header spread with a identical  code that uses the
basic aloha scheme and the data is spread by a random spreading code, that
is sent to the destinatioin in the header.
http://www2.elen.utah.edu/~schlegel/publications/KotSch01.pdf

and also, the MAC protocol proposed by Dr. Rabaey for the pico radio
project(BWRC).

Best Regards,
Sumeeth

---

From: Sumeeth Nagaraj <[email-masked]>
Date: Thu, 19 Sep 2002 15:10:16 -0600

Hi Manoj,

Best Regards,
Sumeeth