Subject: RE: [Ospf-manet] Initial Scenario Description

From: "Henderson, Thomas R" <[email-masked]>
Date: Tue, 10 Jan 2006 16:27:39 -0800

Pratik, thanks for this valuable input, which I'd like to work into a
set of scenarios.  Comments below:

________________________________

	From: Bose, Pratik [mailto:[email-masked]] 
	Sent: Tuesday, January 10, 2006 8:49 AM
	To: [email-masked]
	Subject: RE: [Ospf-manet] Initial Scenario Description

	Hi, 

	I finally got a chance to peruse through the information that
Tom cited below. After analyzing the wealth of information, I have the
following suggestions for OSPF-MANET scenarios for this mailing list to
consider. The motivation behind my comments is to consider the
requirements of a wider, more complete set of deployments for
OSPF-MANET. The current scenario is a great first step, we also need to
address the requirements of other networks whose characteristics can be
different from the current scenario. I try to cover nodes with different
mobility characteristics of multiple vehicle type (air, land and water)
and I think we all will notice that these can be so different that
algorithm evaluation should be subject to this variety: 
	 
	- Grid size and radio range: These two factors are clearly
related. The current scenario has 500 m^2 grid size and a radio range of
250 m. This forms I think the spectrum of agile land based manet nodes
with limited mobility. It would help if the scenario allows these two
parameters to be specified as a ratio in metres for Grid Size / Range,
with the current scenario having a value of 2. At least a few more
values of this ratio is required such as 10, 50, 150 etc. This will
cover cases where long range radios can cover large grid sizes (some of
which go into kilometres - think large land vehicles, ships, planes). A
corresponding number of nodes would also apply to each case. 

Can you clarify what you mean by the last sentence?  Do you mean a
corresponding density of nodes or number of nodes?  If the latter, then
the range of ratio values that you cite may be uninteresting because the
network will be too sparsely connected (i.e. largely disconnected).  If
the former, then we may run into scalability problems with the total
number of nodes in the simulation (also, total number of OSPF routers in
an area).  We will have to be careful with this parameter, I think.

	- Velocity: The current scenario specifies 10 m/s . This is
again typical for certain land based vehicles only. In addition other
mobile node speeds need to be considered. Typical maritime speeds are
double the current number and airborne vehicle speeds begin at an order
of maginute greater upto Mach-1 speeds. 

I think that you have some specific radios (different than 802.11-based)
in mind.  I'd like to explore whether we can capture the essential
aspects of them (for our purposes) without too much additional detailed
physical layer modeling.
 
We have implemented an abstracted channel model called LinkMatrix that
could be extended to provide an abstract model of different radio types
and mobility profiles.  We would need to get more details about how the
different radios are able to provide channels between nodes as a factor
of range and mobility.  See the ietf/link_matrix_manet/ directory.
Would you be able to help us parameterize the radios in a manner that
they could be adequately represented by such an abstracted channel
model?

	- Pause Time: A pause time of 40 seconds in the current scenario
is sufficient for land vehicles for certain quick stationary activity.
Both shorter (air-vehicles) and larger (for both maritime and land
vehicles) pause time should also be considered ranging from the
millisecond to hour range. This can be done in discrete steps such that
at least one order of magnitude (millisecond, second, hour) is captured.
Another aspect of pause time implications which I could not find (maybe
I missed it) in the current scenario is that for most radios, the moment
they pause their radio range increases significantly. This is an
important aspect to consider, especially for large pause times.  

We did not model such an effect with our 802.11-based radio model. 

	Although the above detail may seem involved, my guess is that
all of the above can be condensed to a handful of scenarios. The reason
why I think this is important is that the above characteristics are so
different that it seems moot that we as a group incorporate them in our
evaluation while we ponder on OSPF-MANET.  
	 
	Thanks, 
	 
	Pratik

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

---

From: Alvaro Retana <[email-masked]>
Date: Thu, 12 Jan 2006 10:18:00 -0500

On 1/10/2006 7:27 PM, Henderson, Thomas R wrote:

Tom:

>     *From:* Bose, Pratik [mailto:[email-masked]]
>
>     I finally got a chance to peruse through the information that Tom
>     cited below. After analyzing the wealth of information, I have the
>     following suggestions for OSPF-MANET scenarios for this mailing list
>     to consider. The motivation behind my comments is to consider the
>     OSPF-MANET. The current scenario is a great first step, we also need
>     to address the requirements of other networks whose
>     characteristics can be different from the current scenario. I try to
>     cover nodes with different mobility characteristics of multiple
>     vehicle type (air, land and water) and I think we all will notice
>     that these can be so different that algorithm evaluation should be
>     subject to this variety:
>      
>     - Grid size and radio range: These two factors are clearly related.
>     The current scenario has 500 m^2 grid size and a radio range of 250
>     m. This forms I think the spectrum of agile land based manet nodes
>     with limited mobility. It would help if the scenario allows these
>     two parameters to be specified as a ratio in metres for Grid Size /
>     Range, with the current scenario having a value of 2. At least a few
>     more values of this ratio is required such as 10, 50, 150 etc. This
>     will cover cases where long range radios can cover large grid sizes
>     (some of which go into kilometres - think large land vehicles,
>     ships, planes). A corresponding number of nodes would also apply to
>     each case.
>      

I'm not trying to put words in Pratik's mouth...but I would think that 
we want to keep the number of nodes constant while varying the ratio 
(which would avoid your scalability concern).

OTOH, the large ratios will produce a sparse network, but I believe that 
is precisely the point: there are networks that will be sparsely 
connected!  In the worst case, knowledge of the behavior under these 
potentially extreme circumstances is important to understand and later 
select the best *overall* solution.  If these networks are real (which 
is what Pratik is pointing out), then the results should be interesting 
to the people deploying them. ;-)

>     - Velocity: The current scenario specifies 10 m/s . This is again
>     typical for certain land based vehicles only. In addition other
>     mobile node speeds need to be considered. Typical maritime speeds
>     are double the current number and airborne vehicle speeds begin at
>     an order of maginute greater upto Mach-1 speeds.
>      
> 

I'll be the first to admit not understanding all the details behind the 
different radio technologies.

It is true that different networks/deployments will use different radio 
types (maybe not a lot of 802.11...??), but for the purposes of the 
evaluation, can the 802.11-based model support different mobility 
speeds??  If it supports 10m/s, I would assume 20-30 m/s may be 
possible, maybe even 50-100ms...  Maybe it isn't possible, that's why 
I'm asking.

Going to Pratik's point, I agree that changing the speed is important 
(sounds like you do too??).  Do you think that potentially integrating 
other radio models in the tests will require running all the other 
scenarios with those models as well??  My gut answer would be yes.

My point here is that by adding different radio models we would be 
increasing the number of scenarios/data to make the final evaluation 
with -- which is a good thing.  But we would also be adding at least one 
more dimension to the problem -- which may delay the results, but be 
necessary to reflect a wide range of deployments.

Thanks!

Alvaro.