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

From: "Liaw, Yong Shyang - LIAYS001" <[email-masked]>
Date: Thu, 19 Sep 2002 18:16:43 +0930

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

---

From: Rex Buddenberg <[email-masked]>
Date: Thu, 19 Sep 2002 08:44:01 -0700

On Thursday 19 September 2002 01:46 am, Liaw, Yong Shyang - LIAYS001 wrote:

Would like to start here:

> (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?
>
CSMA and variants (802.3 and 802.11) assume that everybody in a segment can 
hear everybody else.  If the assumption goes away (silent host), then carrier 
sense simply doesn't work any more.  The collision detection and collision 
avoidence algorithms don't change the assumption but provide a safety net ... 
which isn't very efficient.  

Token MACs (FDDI, 802.5) assume that everybody can hear nearest neighbor in 
both directions, so nodes can pass tokens.  Again, this assumption disappears 
in the presence of silent hosts.  (with somewhat more severe results in token 
systems than CSMA ones).  

> hence they should be solved in the MAC layer.  Is this a fair statement?

To about 90%, yes.  Redesigned MACs would probably be based on scheduling or 
polling algorithms.  Both work on the assumption that all nodes in a segment 
can hear a central controller (who either does the polling or issues the 
schedule) but eliminate the requirement for everybody to hear each other.  
Polling works in high-interactivity environments but gets problematic in 
low-interactivity situations like the 300msec propagation delays in GEO 
satellite throws.  Scheduling should work in all situations, but you trade 
off some interactivity to gain efficiency.  

There are a couple things that need to get 'mirrored' through from the 
network layer (IP) to the MAC layer ... we've had a couple discussions on 
this list in that vein.  Both QoS control and multicast need to be understood 
at the MAC and understood in the same way that IP understands them.  For 
instance, arrival of an urgent packet (with appropriate DSCP in the DS byte) 
at the controller should influence the schedule to enqueue that packet early; 
conversely, origination of an urgent packet from a leaf node should trigger 
the MAC to allow priority access for that node as well.  Multicast needs 
similar treatment -- multicast at the network layer is defined as delivery to 
multiple destinations for price of single router transit; at the data link 
layer, the definition is delivery to multiple destinations for price of 
single RF transit which means that the MAC addressing scheme needs to work in 
harmony with IP multicast.  None of this requires rework at IP but we need a 
defined interface between net and datalink layers.  That's the 10%, IMHO.
>
> 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?
>
I'd say yes.  

> 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?

Clearly a complex MANET may have multiple routes to any given host in the 
network.  That's no different than in today's internet, except that the 
routing topology is more volatile.  If the routing algorithms are dependent 
on this or that MAC characteristics, we've screwed up the modularity of the 
design.  Right track?
-- 
b

---

From: Rex Buddenberg <[email-masked]>
Date: Thu, 19 Sep 2002 08:44:01 -0700

I'd say yes.