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

From: "DANIEL BYRNE" <[email-masked]>
Date: Thu, 4 May 2006 14:42:15 -0500

Just rebuild the routing tables every 3 seconds or so.  This eliminates
guessing, measuring signal strength, watching traffic etc.  You could
even make invalidating the tables user configurable.  If the user knows
he will be relatively stationary, ie. in Barnes and Noble, they could
set the protocol to the stationary model.  If the user is travelling
down the highway at 80 MPH or on a subway, then choose the roaming model
which invalidates and updates the routes at a faster pace.

-----Original Message-----
From: Kenneth Brayer [mailto:[email-masked]] 
Sent: Thursday, May 04, 2006 2:31 PM
To: Fred Baker
Cc: [email-masked]
Subject: Re: [manet] Re: MANET definition of a neighbor

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:

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

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

_______________________________________________
manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet

---

From: dazhi chen <[email-masked]>
Date: Fri, 05 May 2006 16:07:10 -0400 (EDT)

Just my two cents about the defintion of neighbors in MANET.

The most important thing is that at which protocol layer you will define
a neighbor for your protocol or algorithm. For example:

1. Physical neighbor

It depends on geographic locations of nodes.

2. Communication neigbhor
It can be defined as any node within the 
radio communication range of the sender or 
any receiver where the signal sent by the sender 
can be reliably recevied. Further, you can distingush
outing neighbors with incoming neighbors due to unidirectional links.

3. Routing neighbor
It can be defined as one node, from which group of nodes, can be selected as a 
next-hop node for a sender.

4. Application neighbor
Think about P2P applications. 

Note that nodes in MANET depend on wireless channel to communicate with each 
other and the status of a wireless channel ususally varies at the scale of a  
few milliseconds. However, such neigbhoring information is unstable 
and we do not need to update it at this scale at each node (either too costly 
or no demand). A simple MAC retransmission at the MAC layer can make this 
variability transparent to the upper protocol layers.

Instead, at the routing layer, coarse-grained routing 
maintains stable routes in the long time (e.g. tens of seconds or more). It 
may not be possible at this time scale due to node mobility.

Some recent work on wireless routing is to maintain some long-term (you can 
define how long for your own protocol) stable Routing neighbors while using 
short-term communication neigbhor in an opportunistic manner to achieve the 
better performance such as a high throughput.

These are just some thinkings in my mind. Hope this helps.

Best,

dazhi

---------------------------------------------------------
Dazhi Chen
Department of Electrical Engineering and Computer Science
371 Link Hall, Syracuse University, Syracuse NY USA 13244
Tel:+(1)-(315)428-8208
Email: [email-masked]  http://web.syr.edu/~dchen02/
---------------------------------------------------------

Quoting DANIEL BYRNE <[email-masked]>:

> see
> for

---------------------------------------------------------
Dazhi Chen
Department of Electrical Engineering and Computer Science
371 Link Hall, Syracuse University, Syracuse NY USA 13244
Tel:+(1)-(315)428-8208
Email: [email-masked]  http://web.syr.edu/~dchen02/
---------------------------------------------------------