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

From: "Mullen, John" <[email-masked]>
Date: Thu, 4 May 2006 13:07:24 -0600

Hi Ken,
 
Not really.  What I'm saying is that while the topology is changing and
we need to keep up with the changes, the information available to any
node is a random sample from an extremely variable random process.  Even
if the nodes are stationary, the effects I mentioned earlier will occur.
These effects cloud the issue when a node tries to determine its local
topology.  
 
Regardless of whether the protocol is reactive or proactive, each node
must determine, on the basis of what it can and cannot detect,  whether
or not to consider a link good.  That is, the node is constantly testing
the hypothisis that a link is good against the alternative that it is
not.  As with any such tests, there is both a Type I and a Type II error
and efforts to reduce the probability of one will tend to increase the
probability of the other.  Furthermore, both errors lead to a
significant decrease in performance.  This is an extremely difficult
problem in a MANET, not only because the topology is changing, but also
because the traffic patterns are changing and nodes will have differing
levels of information from different local transmitters.
 
Many of these problem do not exist in point-to-point satellite
communications.  For example, fading is not as great a factor and there
are fewer missing values.  Generally, one can use hefty power levels in
PTP and the beam is focused, but in MANETS, high power levels lead to
higher average interference levels and beaming is problemetic.  Finally,
in PTP, you expect transmissions from a  single transmitter, so you can
estimate average SNIR on the basis of signals that are too weak to
reliably decode, but in a MANET, a signal may be from any one of a
number of transmitters, so if it cannot be decoded, that information is
lost.
 
But, if was easy, ....
 
:-)
 
John P. Mullen, Ph.D.
(505) 646-2958
[email-masked]

________________________________

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

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:

	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

-- 
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: "Bush, Stephen F \(GE, Research\)" <[email-masked]>
Date: Thu, 4 May 2006 15:22:30 -0400

Perhaps MANET could benefit from some of the DTN concepts
and flash routes (http://www.research.ge.com/~bushsf/pdfpapers/bush_worldacademy.pdf).

Steve

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

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: "Mullen, John" <[email-masked]>
Date: Thu, 4 May 2006 13:40:55 -0600

Hi Fred,

You said:

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

-----------------

The problem is that this does not happen.  Instead, received signal
strength fluctualtes wildly and there is a very large interval over
which either UAV might be equally good or bad.  Some sort of integration
and filtering is needed.  The trick is to come up with a scheme that
will reliably switch to the new UAV when it should without unnecessarily
switching between the two. 

John Mullen

---

From: "Mullen, John" <[email-masked]>
Date: Thu, 4 May 2006 13:52:28 -0600

Hi Dan,

Easier said than done.

The problem is that the information available to the node does not
indicate clearly who are and who are not neighbors.  Gratutiously
rebuilding tables is as likely to make things worse than better.
Understand, too, that the degree to which a MANET is dynamic depends on
factors other than node mobility.  For example, if the local in-band and
near-band traffic level increases, so will interference, which could
render an otherwise useful link useless due to an unacceptably high
SNIR.  Also, even in B&N, people could be turning on or off their
computers, so the network topology could change drastically in a short
period of time even if none of the nodes move.

In other words, there is no way to eliminate guessing as long as the
MANET uses wireless links.

John P. Mullen, Ph.D.
(505) 646-2958
[email-masked]
 
-----Original Message-----
From: DANIEL BYRNE [mailto:[email-masked]] 
Sent: Thursday, May 04, 2006 1:42 PM
To: [email-masked]
Subject: [manet] Re: MANET definition of a neighbor

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:

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

--
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: "DANIEL BYRNE" <[email-masked]>
Date: Thu, 4 May 2006 15:10:49 -0500

John,
How would gratuitously rebuilding tables make things worse?  If as you
say the local in-band and near-band traffic level increases rendering an
otherwise useful link useless due to an unacceptably high SNIR, wouldn't
rebuilding the links make it better?  

Obviously the links would be rebuilt within a best available case
scenario.  I.e.. Pick the best link every time you rebuild.

Yes guessing is not eliminated, but extra processing overhead which may
or may not amount to anything is.

I guess what I'm afraid of is unnecessarily complicating algorithms by
trying to solve every conceivable problem with 100% accuracy.  Just make
everything best effort!  Correlating to the wired world -- it works for
Ethernet and complexity is killing ATM.  It'll make the hardware
cheaper, faster and more broadly accepted, and "most of the time" it'll
be more than adequate.  

I guess I'm thinking more like and engineer and less like a researcher.
Blame it on my job description. ;-)

-----Original Message-----
From: Mullen, John [mailto:[email-masked]] 
Sent: Thursday, May 04, 2006 2:52 PM
To: DANIEL BYRNE; [email-masked]
Subject: RE: [manet] Re: MANET definition of a neighbor

Hi Dan,

Easier said than done.

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

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

as far as

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

---

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

Hi Dan,

The problem is that the node doesn't know which links are good and must
make intelligent guesses.  If you rebuild your table without reason to
suspect a route is bad, you will increase the risk of excluding a good
route or including a bad one.

As a related example, in statistical quality control, one frequently
asks "has the situation changed?" When doing so, the null hypothesis is
that nothing has changed and one does not conclude there has been a
change without definite evidence.  In essence, the node's neighbor
problem is similar, except that in SQC, one may ask the question twice
an hour, but in a MANET, the node may ask it twice a minute.  Thus, the
risk of a Type I error is very high.  

If the interference level increases, one should reassess the links which
have marginal SNIRs, but there may be no need to reassess those with
high initial SNIRs, if the increase in interference doesn't lead to a
marginal SNIR.  It's like rocks in the bay.  They are more of a problem
at low tide than high tide, but if you are in a deep channel, the change
in tide levels doesn't matter that much.

You cannot be sure of picking the best links.  You can only pick the
links that appear best.  More than that, it is not at all clear what
"best" is.  A marginal link might be the best if the alternative is
network partition, but you won't know that without comparing notes with
other nodes.  You are not picking among alternate links to your
neighbors, but picking your neighbors.  Which links are chosen is the
result of a local decision, but has global consequences.

Failing to consider these problems can reduce your throughput by 80 or
90%.  This is not a second-order problem, but a central problem that
must be managed to have an acceptable MANET.

John P. Mullen, Ph.D.
(505) 646-2958
[email-masked]
 
-----Original Message-----
From: DANIEL BYRNE [mailto:[email-masked]] 
Sent: Thursday, May 04, 2006 2:11 PM
To: [email-masked]
Subject: RE: [manet] Re: MANET definition of a neighbor

John,

-----Original Message-----
From: Mullen, John [mailto:[email-masked]]
Sent: Thursday, May 04, 2006 2:52 PM
To: DANIEL BYRNE; [email-masked]
Subject: RE: [manet] Re: MANET definition of a neighbor

Hi Dan,

Easier said than done.

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

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

as far as

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

---

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

Think of it as a feedback system.  You iteratively arrive at an optimal
solution by periodically sampling the output and feeding it back to the
input. 

Think of a PLL, it constantly samples the output frequency and compares
it to the reference frequency.  The phase comparator constantly zeros in
on the targeted frequency by adjusting up and down over and over again.
If it jumps too high or too low, it is immediately fixed in the next few
clock cycles.  

Feedback always makes a system more stable.  Imagine if the PLL assumed
"nothing has changed and did not conclude there has been a change
without definite evidence".  The clock would be out of its desired range
very quickly, and there would be more adjusting needed to fix the
problem.

"If something has changed but it is not relevant to the communications I
am involved in, it is the proverbial tree falling in the forest -
whether I adapt to the change or not has no near term effect."

Your neighbors are always of prime importance in a MANET.  It is through
them that you pass all data.

-----Original Message-----
From: Fred Baker [mailto:[email-masked]] 
Sent: Thursday, May 04, 2006 3:47 PM
To: DANIEL BYRNE
Cc: [email-masked]
Subject: Re: [manet] Re: MANET definition of a neighbor

On May 4, 2006, at 1:28 PM, DANIEL BYRNE wrote:

> Rebuilding lists of reliable neighbor nodes every 3 seconds or so will

> increase the probability that the links in the list will be useful.

Not sure I buy the argument. If nothing has changed, rebuilding the
table will result in the same table and consume a lot of power and CPU
while doing so. If something has changed but it is not relevant to the
communications I am involved in, it is the proverbial tree falling in
the forest - whether I adapt to the change or not has no near term
effect. And if there has been a change that affects my communications
(as end point or relay), any routing protocol I am aware of will adapt
to it anyway.

Why, specifically, does this accomplish anything?

---

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

Hi Dan,

- If you accidently include a bad route, it will be weeded out in the
next cycle or two.  The trick is to update fast enough so that the bad
routes don't have a lasting impact.

---

From: "DANIEL BYRNE" <[email-masked]>
Date: Thu, 4 May 2006 16:03:00 -0500

It only has better long term reliability.  A manet packet doesn't take
60 seconds to transmit, so you are looking for a very small window of
opportunity.  Statistically the differnce between the two links is very
small when considering the transmission time of the manet packet.

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

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: "Mullen, John" <[email-masked]>
Date: Thu, 4 May 2006 15:14:18 -0600

Hi Daniel,

In a PLL you have access to the actual output frequency.  In a MANET,
you do not have access to the actual link condition.  The method you
propose would cause endless cycling as the node continually updates its
routing tables on the basis of the random error, rather than the actual
situation.

A better analog would be the AGC signal in a receiver, in which the
fluctuations in the received signal are averaged out through an
integrator.  The analog is not perfect, however, since the AGC works on
a single signal, while the MANET must estimate a link's condition on the
basis of occasional signals from the transmitter.  However, the task is
similar in that the only way to sort the signal out from the random
error is to take repeated measures and apply some sort of integrating
filter to the resulting data.

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

---

From: "DANIEL BYRNE" <[email-masked]>
Date: Thu, 4 May 2006 16:48:57 -0500

Yeah, I agree, an AGC is a better analog and better solution.  Basically
low pass the table through constant sampling. 

-----Original Message-----
From: Mullen, John [mailto:[email-masked]] 
Sent: Thursday, May 04, 2006 4:14 PM
To: DANIEL BYRNE
Cc: [email-masked]
Subject: RE: [manet] Re: MANET definition of a neighbor

Hi Daniel,

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

---

From: "Mullen, John" <[email-masked]>
Date: Fri, 5 May 2006 09:14:33 -0600

Hi Daniel,

Well, we agree.

I think that the best bet is to continually sample nodes in range and
use that to decide which nodes are, in fact, "good" neighbors.  This
definition is conditional.  When the MANET is dense, the node will want
to be picky, selecting only very good neighbors, but if the MANET is
sparse, the node might want to use dodgy neighbors, if this leads to
better overall performance and avoids partition.  In short, I think the
solution will involve some sort of cross layer design because there are
both local and global issues.

The low-pass filter is a good concept, but there are difficulties in
MANETs to be dealt with that the model does not consider.  The problem
is that a node will receive transimssions from numerous sources and
needs to track which signal came from where.  However, if the signal is
too weak to determine the address of the source, it cannot be used by
the receiver to update the estimate of servicability.  Because the only
data the receiver will get is that contained in messages strong enough
to decode, a straight low-pass and integration scheme will tend to
overestimate the SNIR, and that bias will increase as SNIR becomes
smaller.  The trick is to find a way to detect and account for the
missing transmissions.

That is the trick I'm working on.

http://web.nmsu.edu/~jomullen/MyPapers/Mullen_PE_WASUN05.pdf

:-)

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

-----Original Message-----
From: Mullen, John [mailto:[email-masked]]
Sent: Thursday, May 04, 2006 4:14 PM
To: DANIEL BYRNE
Cc: [email-masked]
Subject: RE: [manet] Re: MANET definition of a neighbor

Hi Daniel,

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

---

From: "DANIEL BYRNE" <[email-masked]>
Date: Fri, 5 May 2006 11:48:07 -0500

"The low-pass filter is a good concept, but there are difficulties in
MANETs to be dealt with that the model does not consider.  The problem
is that a node will receive transmissions from numerous sources and
needs to track which signal came from where.  However, if the signal is
too weak to determine the address of the source, it cannot be used by
the receiver to update the estimate of serviceability."

I think we are saying the same thing just in different words.  In case
we are not, here's my point.

Obviously you'd want to pick a algorithm that converges on the correct
solution, and using say a 10 tap FIR filter should smooth out the random
errors.  The tap weights should be algorithmic, as opposed to basing
them simply on signal strength.  Because of the problems you mentioned,
SINR isn't a good enough indicator by itself.  The MANET protocol for
example could use valid CRCs, parity checks, ping times, subnet
affiliation, signal strength, and/or whatever you as filtering criteria.
Place a weight of importance on each selection criteria  then add them
together and then store its combined weight with the route in a table.
When an entry gets too light, toss it.  Everyone's implementation can
and should be different based on the MANET deployment environment, but
the basic premise of CONSTANT sampling, and filtering out bad links
remains the same. 

"...The chances of selecting a bad link may, depending on the scheme you
pick, be higher than that of picking a good on.  In field trials, this
has turned out to be a major source of trouble.  Repeated attempts will
simply lead to repeated bad choices."

Constant sampling in itself isn't a problem.  If the sampling procedure
doesn't converge on an optimal list and constantly picks "bad" nodes
then the selection and filtering criteria is too blame and not the mere
act of sampling.

"This definition is conditional.  When the MANET is dense, the node will
want to be picky, selecting only very good neighbors, but if the MANET
is sparse..."

The FIR will be picky by nature without adjusting the algorithm.
Stronger nodes, as defined by the weighted selection criteria, will
swamp weaker nodes in a dense MANET; conversely weaker nodes will be
brought out in a quieter MANET.

---

From: "Mullen, John" <[email-masked]>
Date: Fri, 5 May 2006 11:09:38 -0600

Hi Daniel,

My replies are in line with --'s separating topics 

John P. Mullen, Ph.D.
(505) 646-2958
[email-masked]
 
-----Original Message-----
From: DANIEL BYRNE [mailto:[email-masked]] 
Sent: Friday, May 05, 2006 10:48 AM
To: [email-masked]
Subject: [manet] Re: MANET definition of a neighbor

Reply:

Certainly, we should use all we can, but we need to be aware that unless
we conpensate in some way for missing values, our figure of merit will
depend solely on signals strong enough to have, at least, the TX ID
decoded.  What happens is that the response curve based on available
information becomes very flat over a wide range.  A link could become
quite marginal, but the receiving node might not know it because the
transmitter's worst failures are not visible to it.  People have
compensated for this by using a fudge factor, but the fudge only works
in a limited context.  This implies a higher level of sophistication in
the filter techniques than I've seen so far.

------------------------------

Reply:

Not really.  Due to effects like multipath fading, the chance of
selecting a poor link are fairly high.  Better filtering can help, but
the deck is stacked against you.  Setting up a null hypothesis and
acting when the evidence is sufficient is a good way to reduce false
positives, which in turn, will reduce the risk of selecting a poor link.

--------------------------------

Reply:

This is not automatic.  For example, a node could have a high density to
the West and a low density to the East.  If the nodes needs to send a
packet East and there is a good path using the West side nodes, the
optimal solution may be to use the longer, but more reliable, route.
However, if the only viable path is to use the Eastern nodes, the
alternative to using that poor route is partition.  That is why I feel a
cross-layer approach will win out in the end.  The physical and link
layers will have information that is normally hidden from the routing
layer that will be needed to evaluate potential links, but the MANET
protocol will have the job of finding an optimal network solution.

John Mullen

---

From: "Bush, Stephen F \(GE, Research\)" <[email-masked]>
Date: Fri, 5 May 2006 16:53:05 -0400

The reason I mentioned DTN earlier is because:

1) Predictive connection/mobility algorithms are increasingly being employed

2) The concept of "unstable" links are taken to an extreme-- no end to end
path is required to exist at any single point time for information to be
routed. E2E connections may be dispersed in time.

Stephen F Bush (http://www.research.ge.com/~bushsf)

---

From: "DANIEL BYRNE" <[email-masked]>
Date: Mon, 8 May 2006 11:34:27 -0500

On Fri, May 05, 2006 at 09:00:59AM -0600, Mullen, John wrote:
> Hi Dan,
> 
> It doesn't work that way.  The chances of selecting a bad link may, 
> depending on the scheme you pick, be higher than that of picking a 
> good on.  In field trials, this has turned out to be a major source of

> trouble.  Repeated attempts will simply lead to repeated bad choices.

This statement simply doesn't make any sense.  If repeated attempts
produce repeated bad choices, then the decision making process behind
choosing is incorrect, not the sampling.  Choosing once and assuming all
is good just doesn't work.

Imagine if you plotted a trip with your family to Disney world.  You
figured gas, speed, and route to the best of your ability before you
started the trip.  If you didn't subsequently modify your careful
calculations to account for weather, traffic, stop lights, road
construction, pot holes, pedestrians, and any number of other
interferences, then you would wreck before you left your neighborhood.
Constant sampling always produces better results unless of course your 3
year old is driving.  In that case it is better to point the steering
wheel in the right direction, and just see how far he can get before
wrecking.  He will probably make it further this way then if you let him
run the controls all by himself. I.e.. The decision making person in
this process is the problem.

---

From: "Mullen, John" <[email-masked]>
Date: Mon, 8 May 2006 13:40:35 -0600

Hi Daniel,

The conditions under which you choose a new link and those under which
you decide to keep or toss an existing one are different.  For the new
link, you may only have hello messages, which can be related to packet
reception, but generally have a much higher success rate.  For an
existing link, you have hello messages, control packets, and data
packets.  Becaue you have much more information about a link in use than
one that is not in use, you are more likely to make a mistake when
choosing a new link than when evaluating an existing one.

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

---

From: "Mullen, John" <[email-masked]>
Date: Mon, 8 May 2006 13:48:33 -0600

"Maybe a new stack architecture is needed for MANETS where protocols can
still partition layer specific items yet share cross applicable
information."

I agree, but we may still be able to pull it off without having to mess
up the stack.

John Mullen 

John P. Mullen, Ph.D.
(505) 646-2958
[email-masked]
 
-----Original Message-----
From: DANIEL BYRNE [mailto:[email-masked]] 
Sent: Sunday, May 07, 2006 12:18 PM
To: Mullen, John; [email-masked]
Subject: RE: [manet] Re: MANET definition of a neighbor

"...That is why I feel a cross-layer approach will win out in the end.
The physical and link layers will have information that is normally
hidden from the routing layer that will be needed to evaluate potential
links, but the MANET protocol will have the job of finding an optimal
network solution."

True, the routing protocol could use information attained by lower
layers.  A mechanism to pass information up the stack is needed, or the
protocol needs to be multi-layer aware. However, the later causes
problems when there are changes in technologies.  Maybe a new stack
architecture is needed for MANETS where protocols can still partition
layer specific items yet share cross applicable information.

---

From: "Mullen, John" <[email-masked]>
Date: Mon, 8 May 2006 14:15:49 -0600

Hi David,

1) In a MANET, we assume limited power, which means we want just one
node to forward a packet. 

2) That is possible.  A good MANET design is one that works in most
conditions, but it is always possible to find a set of conditions under
which any particular MANET may not work.

3) Because a) both node power and the shared channel are scarce
resources, and b) a global solution to the routing problem can be
expected to be better than a local one. 

John P. Mullen, Ph.D.
(505) 646-2958
[email-masked]
 
-----Original Message-----
From: David Young [mailto:[email-masked]] 
Sent: Sunday, May 07, 2006 10:22 PM
To: Mullen, John
Cc: DANIEL BYRNE; [email-masked]
Subject: Re: [manet] Re: MANET definition of a neighbor

> trouble.  Repeated attempts will simply lead to repeated bad choices.

Three observations, and a question: (1) Any choice of a single receiver
may be a bad choice, most of the time.  (2) The link conditions may not
outlast the decision process.  (3) You will broadcast the packet at the
physical layer, anyway---i.e., more than one receiver will receive it.
So, why choose?  (It only occurs to me to ask because I have fallen
under the influence of the Roofnet ExOR[1] study.)

Dave

[1]
http://pdos.csail.mit.edu/papers/roofnet:exor-sigcomm05/roofnet_exor-sig
comm05.pdf

-- 
David Young             OJC Technologies
[email-masked]      Urbana, IL * (217) 278-3933