Subject: RE: [manet] Re: MANET definition of a neighbor

From: "Mullen, John" <[email-masked]>
Date: Thu, 4 May 2006 12:33:02 -0600

Hi Ken,
 
Well, that is a good functional definition, but a bit tricky in
practice.  As Jim pointed out, wireless communications is a random
process and it may not be clear whether or not you can set up a link.
For example, due to fading, you may receive an especially hot packet and
assume, incorrectly, that there is a reliable link.  The same randomness
could cause a packet to be dropped due to a chance low-powered signal.
Also, there are the effects of shadowing, fluctuating interference
levels and the possibility of a data collision.  A buffer could overflow
on a heavily-used node and we could infur, incorrectly, that the link is
bad.  Finally, MANETs are, by definition, mobile, so any data table you
have now is likely to be in error in a few minutes or less.
 
You are correct in that if we knew who our neighbors are, we could set
up the network.  The problem is that in practice, we know nothing and
need to proceed on the basis of intelligent guesses.  I think that a
bigger problem is that so much work is done in MANET protocol design
that completely ignores this problem.

John P. Mullen, Ph.D.
(505) 646-2958
[email-masked]

________________________________

From: Kenneth Brayer [mailto:[email-masked]] 
Sent: Thursday, May 04, 2006 12:16 PM
To: [email-masked]
Subject: Re: [manet] Re: MANET definition of a neighbor

It strikes me that a neighbor of Node A is any node that A can setup a
link to, whether it be next door or 300 miles away. A node that the
second node can setup a link to but that A cannot setup a link to is a
neighbor once removed, etc. Once you know who the neighbors are you can
build a network routing table.

See
Packet switching for mobile earth stations via low-orbit satellite
network
Brayer, K.;
Proceedings of the IEEE
<http://ieeexplore.ieee.org/xpl/RecentIssue.jsp?punumber=5> 
Volume 72,  Issue 11,  Nov. 1984 Page(s):1627 - 1636 

Available online in IEEE XPLORE

Ken

-- 
Kenneth Brayer
Fellow of the IEEE
M/S M370
The MITRE Corporation
202 Burlington Road
Bedford, MA 01730

e-mail: [email-masked]
tele: 781-271-5254
fax: 781-271-2841
_______________________________________________
manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet

---

From: Kenneth Brayer <[email-masked]>
Date: Thu, 04 May 2006 14:47:22 -0400

John
What you are saying is that the topology is , for many reasons, 
variable. Your neighbors are constantly changing. So you also need a 
means to track who your neighbors are as a function of time. So now you 
are into reactive and proactive protocols.

So the real question is who are your neighbors as a function of time in 
a MANET. A MANET protocol should try to determine this so it can deliver 
messages when they are presented to the network.

My paper deals with point to point satellites, but you have the never 
ending list of protocols, DSR, ABR, ZRP, OLSR, etc. all of which try to 
deal with this problem, how to track topology changes.

Ken

Mullen, John wrote:

> For example, due to fading, you may receive an especially hot packet 
> and assume, incorrectly, that there is a reliable link.  The same 
> randomness could cause a packet to be dropped due to a chance 
> low-powered signal.  Also, there are the effects of 
> shadowing, fluctuating interference levels and the possibility of a 
> data collision.  A buffer could overflow on a heavily-used node and we 
> could infur, incorrectly, that the link is bad.  Finally, MANETs are, 
> by definition, mobile, so any data table you have now is likely to be 
> in error in a few minutes or less.
>  
> ------------------------------------------------------------------------
> neighbor once removed, etc. Once you know who the neighbors are you 
> can build a network routing table.
>
> See
> Packet switching for mobile earth stations via low-orbit satellite network
> Brayer, K.;
> Proceedings of the IEEE 

-- 
Kenneth Brayer
Fellow of the IEEE
M/S M370
The MITRE Corporation
202 Burlington Road
Bedford, MA 01730

e-mail: [email-masked]
tele: 781-271-5254
fax: 781-271-2841

---

From: Fred Baker <[email-masked]>
Date: Thu, 4 May 2006 12:09:05 -0700

On May 4, 2006, at 11:47 AM, Kenneth Brayer wrote:
> So the real question is who are your neighbors as a function of  
> time in a MANET. A MANET protocol should try to determine this so  
> it can deliver messages when they are presented to the network.

It is "at a point in time" even in a wired and highly reliable  
network. Things go bump in the night in the most stable networks.

I have argued along the lines, though, that the most important metric  
for a path in a manet network is not its speed or degree of  
congestion (although those are very interesting second-order  
metrics), but the probability that it will be useful at the time I  
want to use it.

In many scenarios, mobility is well described as "brownian motion",  
in which things moving approximately together but bump in and out of  
sight of each other, or using the word "zoom". If one thinks, for  
example, of cars on a highway, I might try to use cars traveling in  
the opposite direction as links ("zoom"), cars on orthogonal roads  
("zoom" to the point of "blip" in many cases), routers on light poles  
("zoom" at half the speed), routers in other cars I happen to be  
traveling with for a few exits (relatively stable during the  
interval, but blipping in and out around corners/tunnels/etc), and  
the occasional router on a hill (which it will be able to see for a  
long time as it passes the hill). Which is the tres cool route? The  
one that has the highest probability of working when the route is  
needed...

So for example if one has a pair of UAVs in orbit over a domain, one  
should be able to watch the characteristics of the radio signal and  
see that one's signal is slowly degrading while the other's is slowly  
improving. At some point, one wants to bring up the approaching UAV,  
shift routes to it, and then shut down the now-unused departing UAV  
for a smooth switchover, rather than saying "ohmygoshwhatdoidonow"  
when the UAV one is using suddenly goes out of sight. The sudden mass  
change model is a leftover from wired concepts...

---

From: Kenneth Brayer <[email-masked]>
Date: Thu, 04 May 2006 15:30:55 -0400

Fred
I agree with the following:
"I have argued along the lines, though, that the most important metric  
for a path in a manet network is not its speed or degree of  congestion 
(although those are very interesting second-order  metrics), but the 
probability that it will be useful at the time I  want to use it."

When you get a message to deliver you need to know what to do. I am 
interested in delivering messages rapidly.

as far as
"So for example if one has a pair of UAVs in orbit over a domain, one  
should be able to watch the characteristics of the radio signal and  see 
that one's signal is slowly degrading while the other's is slowly  
improving. At some point, one wants to bring up the approaching UAV,  
shift routes to it, and then shut down the now-unused departing UAV  for 
a smooth switchover, rather than saying "ohmygoshwhatdoidonow"  when the 
UAV one is using suddenly goes out of sight."

For all of the reasons that John stated this is very hard. Just because 
the signal is degrading doesn't mean it will continue to degrade. It is 
even harder to determine when a signal will improve. I made Fellow of 
the IEEE in Fading Channels, like HF Radio, and signal quality 
prediction and its direction is very difficult. Some real world MANETS 
deal with this by trying to eliminate the problem through coding. THey 
give up usable channel capacity to reduce the error rate and increase 
channel reliability.

Ken

Fred Baker wrote:

>> So the real question is who are your neighbors as a function of  time 
>> in a MANET. A MANET protocol should try to determine this so  it can 
>> deliver messages when they are presented to the network.
>
>

-- 
Kenneth Brayer
Fellow of the IEEE
M/S M370
The MITRE Corporation
202 Burlington Road
Bedford, MA 01730

e-mail: [email-masked]
tele: 781-271-5254
fax: 781-271-2841

---

From: Fred Baker <[email-masked]>
Date: Thu, 4 May 2006 13:42:20 -0700

On May 4, 2006, at 12:30 PM, Kenneth Brayer wrote:

> Some real world MANETS deal with this by trying to eliminate the  
> problem through coding. THey give up usable channel capacity to  
> reduce the error rate and increase channel reliability.

I think they all do. Even 802.11 does that.

But there are longer term issues. A link that goes in and out every  
60 seconds may have wonderful channel characteristics while it is in.  
If I have the option of one that has been stable for ten minutes and  
is otherwise comparable, though, I will opt for the latter ten times  
out of ten. It has a greater probability of being useful at the time  
I want to use it.

---

From: Kenneth Brayer <[email-masked]>
Date: Thu, 04 May 2006 16:56:08 -0400

Fred
You need to look at the link over a long period of time. Ten minutes 
stable may be the fluke.
Ken

-- 
Kenneth Brayer
Fellow of the IEEE
M/S M370
The MITRE Corporation
202 Burlington Road
Bedford, MA 01730

e-mail: [email-masked]
tele: 781-271-5254
fax: 781-271-2841