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

From: "DANIEL BYRNE" <[email-masked]>
Date: Sun, 7 May 2006 13:11:06 -0500

Good points.  I agree.  Neighbor definitions should be qualified by the
adjective "layer".  So we should be talking about Layer Neighbors.

-----Original Message-----
From: dazhi chen [mailto:[email-masked]] 
Sent: Friday, May 05, 2006 3:07 PM
To: [email-masked]
Subject: my two cents Re: [manet] Re: MANET definition of a neighbor

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

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

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

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

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