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

[Rex Buddenberg <budden@nps.navy.mil>]

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

Would like to start here:

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

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

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
_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet