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

From: "Bose, Pratik" <[email-masked]>
Date: Wed, 11 Jan 2006 16:57:50 -0500

Forwarding Tom's response to earlier email on scenario updates which
seems to have not made it to the mailing list although he intended it to

  _____  

From: Henderson, Thomas R [mailto:[email-masked]] 
Sent: Tuesday, January 10, 2006 7:28 PM
To: Bose, Pratik; [email-masked]
Subject: RE: [Ospf-manet] Initial Scenario Description

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: "Bose, Pratik" <[email-masked]>
Date: Thu, 12 Jan 2006 12:09:38 -0500

Thoughts inline. Also need to understand better what all needs to
specified for 'a' scenario to crystalize these ideas better for the
software.... 

> -----Original Message-----
> From: Alvaro Retana [mailto:[email-masked]] 
> Grid Size /
> >      
> > 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.
> 
> 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. ;-)
> 
> 
I see what both of you are saying on keeping the no. of nodes
consistent. Do you think there is value in multiple test runs with a
different no. of nodes for all scenarios ? (E.g All-Scenarios-Run 1 -
Global parameter for No. Of nodes = XXX; All-Scenarios-Run 2 - Global
parameter - No. of nodes = YYY)

Tom: Can you elaborate on why you think that a sparse network may be
uninteresting ?. A dense network may not be always the worst case
scenario for sparse network. 

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

It is true that not all networks are 802.11 radios. I will take a look
at the directory cited by Tom to see whether different channel model
characteristics is an easy parametric exercise. Changing the channel
model, if/when deemed necessary can be a second step, taken up only if
we all feel its burning need. 

Some more thoughts on pause time increasing range.... This parameter
could be a second level factor which makes the range ratio a dynamic
variable creating an effect of the network switching between sparse
connectivity to dense connectivity and vice-versa during the network's
life. I remember a 802.15 like fixed wireless network which would behave
like this on clear mornings and later change when a lot of delivery
trucks parked around the network in the afternoon. Don't we need to
consider the effect of such changes on algorithm behavior....

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Fri, 13 Jan 2006 14:47:52 -0800

> Sent: Friday, January 13, 2006 8:26 AM
> To: Henderson, Thomas R
> Cc: Bose, Pratik; [email-masked]
> Subject: Re: [Ospf-manet] Initial Scenario Description
> 
> On 1/13/2006 2:12 AM, Henderson, Thomas R wrote:
> 
> Tom:
> 
> > I am not questioning the applicability of sparse networks, but was 
> > mainly reacting to the range of numbers that you proposed. For 
> > instance, if the range is 500/50 = 10 m, and you have ~100 nodes 
> > uniformly on the 500m^2 grid, no nodes can communicate.
> 
> Yes...but by the nature of the model, each node should chose 
> it's next position in the grid randomly -- the situation in 
> which all the nodes "randomly" chose a uniform distribution 
> shouldn't happen.  In fact, I remember reading somewhere that 
> random waypoint tends to concentrate the
>   nodes towards the center of the grid (??)...increasing the 
> probability of connectivity.
> 
> Even if the radio range is small and the probability of 
> complete connectivity is low, the model serves to look at the 
> behavior of
> (potentially) small groups as they come in touch with others 
> and their members move from one group to another...
> 
> Is there any prior agreement that keeps us from testing 
> scenarios with noncontiguous networks??  [Just asking...]

No, I think we are just debating how far one goes with testing
non-contiguous networks, and where they stop being interesting to look
at.  This also goes for mobility.  At what point does the link
availability and ability of the protocols (even under perfect oracle
knowledge) to converge and deliver packets make TCP/IP-based networks
unusable?  I am guessing that we are most interested in looking at cases
where the protocol has a chance to converge and where the networks are
at least often, if not perfectly connected.

I see that Richard has reposted an old post on this topic.

> 
> 
> > I think that what we want to do is to adjust the parameters 
> so that the
> > average physical degree of the nodes is reduced, to obtain sparser
> > networks, but if the connectivity gets too poor, it gets 
> uninteresting,
> > IMO.
> 
> Is there a variable in the model that can control the 
> physical degree?? 
>   Or are you suggesting that it be controlled by changing the radio 
> range, the size of the grid and the number of nodes in the network to 
> guarantee a certain meshiness??

We've been manipulating those parameters that you mentioned.

Tom

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Fri, 27 Jan 2006 09:10:34 -0800

Pratik,
Thanks for distilling your scenarios into something that we can try to
use. Questions below:

> Sent: Thursday, January 26, 2006 7:43 PM
> To: [email-masked]
> A first and quick glance at the software seems to indicate 
> that GTNetS does support the capability of specifying 
> different radio ranges and velocity for nodes. However the 
> current software does not incorporate this capability. We 
> should consider whether the software can be upgraded with 
> this functionality , if the effort is not 'too much'. We can 
> then simulate any desired real world scenario. 

I think that it is doable within reasonable effort.  Radio range should
be very easy to set on a per-node basis, although making range a
function of whether moving or pausing would be new; mobility will
require a little bit more work.

> 
> Having said that, the info below presents an actual 
> deployment scenario, followed by tailored extractions which 
> can be run on the software as it stands today without the 
> above modification. 
> 
> Thanks, 
> 
> Pratik
> 
> OSPF MANET Scenario Definitions
> 
> Real world deployment scenarios for OSPF-MANET are expected 
> to have different levels complexity. As per IETF-64 the 
> current scenario is defined as follows: 
> 
> Scenario ID: 1
> Grid Size = 500 m^2
> Radio Range = 250 m
> Velocity = 10 m/s
> Pause Time = 40 s
> 
> The following scenarios are proposed as additions to the 
> above scenario based on deployment models for different 
> ground and airborne wireless networks. However while defining 
> the scenario certain constraints of the current simulation 
> runs may require a 'tailoring' of the scenario. The scenarios 
> are thus presented here in two steps. The actual deployment 
> scenario is first described, which is then tailored to one or 
> more scenarios to match current simulation constraints. 
> 
> A typical Actual Ground Deployment Scenario
> 
> No. of Mobile Nodes = 300
> No. of Static Nodes = 800
> Grid Size = 300,000 m x 300,000 m
> Radio Range = 1000 m, 2000 m, 12000 m
> Velocity = 10 m/s
> Pause Time = 1 hour
> Radio Range during Pause = 12000 m
> 
> The above deployment scenario is tailored into the following 
> scenario based on analysis of each node's characteristics and 
> the 100 node limit for current scenarios: 
> 
> Scenario ID: 2
> No. of Nodes = 100
> Grid Size = 150,000 m x 150,000 m
> Radio Range = 1000 m
> Velocity = 10 m/s
> Pause Time = 1 hr
> Radio Range during Pause = 12000 m
> 
> Note: Scenario ID 2 is arrived by considering only a portion 
> of the mobile nodes in the Actual Deployment Scenario. It 
> also eliminates all static nodes from the scenario and picks 
> only a certain type of mobile nodes with one value of radio range.\

A few questions:
- are you comfortable with how the radio is modeled (see section 3.2 of
our technical report)?  For instance, the relationship between
carrier-sense threshold and receive threshold, as governed by the
parameter alpha?
- how about the MAC-- do you assume TDMA?
- we are not running simulations for multiple hours, so in effect, pause
time of 1 hour means a static node.  It seems to me that your model will
have most modes paused at any given instant, in any case.
- the density (100 nodes) in your grid size, along with the radio range,
seems to suggest that the network will be mostly disconnected.  Is that
intentional?

> 
> Actual Airborne Deployment Scenario
> No. of Airborne Nodes = 60
> No. of Ground Mobile Nodes = 300
> No. of Static Nodes = 800
> Grid Size = 200,000 m x 200,000 m
> Radio Range = 20,000 m to ground nodes
> Radio Range of Airborne Nodes (LOS) = 300,000 m Velocity = 
> 300 m/s Pause Time = N/A Radio Range during Pause = N/A
> 
> Tailoring of this scenario can be as Scenario ID 4 & 5 below. 
> But Scenario ID 4 requires a change to the capability that 
> different radio ranges/velocity are specified vehicles in a scenario
> 
> Scenario ID: 4
> No. of Airborne Nodes = 60
> No. of Ground Mobile Nodes = 40
> Grid Size = 200,000 x 200,000 m
> Radio Range = 20,000 for airborne nodes; 2000 m for ground 
> nodes Velocity = 300 m/s for airborne nodes; 10 m/s for 
> ground nodes Pause Time = 1 hour for ground nodes Radio Range 
> during Pause = 12000 m for ground nodes
> 
> 
> Note: Certain limitiation exist in this tailoring. First the 
> planes will sometimes not see each other which may often not 
> be the case with their LOS range of 300 km. But what this 
> scenario is trying to simulate is the communication between 
> ground nodes and airborne nodes.
> 
> Scenario ID: 5
> No. of Airborne Nodes = 60
> Grid Size = 200,000 x 200,000 m
> Radio Range = 300,000 m
> Velocity = 300 m/s for airborne nodes
> Pause Time = N/A
> Radio Range during Pause = N/A
> 
> Scenario 5 forms the other sliver of the actual deployment scenario.
> This scenario simulates only the planes talking to each 
> other. In comparion to Scenario 1 Scenario 5 constructs a 
> smaller grid/range ratio with faster moving vehicles

In the airborne case, I would be somewhat concerned that our radio/MAC
models are not adequate for good modeling.  Do you have assumptions on
those aspects?

Regards,
Tom

---

From: "Bose, Pratik" <[email-masked]>
Date: Mon, 30 Jan 2006 09:17:19 -0500

Tom, 

Will look into radio parameters and get back to the mailing list. On
your question on disconnectedness, the actual scenario has actual
trajectory of vehicles, so there might a difference of how much
connected the network is between the two different mobility models (i.e.
random vs. defined-trajectory), but the vehicles do move in a larger
grid area, and therefore can be subject to this behavior regardless. 

Also, what do you think about upgrading the software to support
different speeds or ranges for vehicles in a given scenario. Is that a
change that can be incoporated ? All the scenarios seem to be have this
key characteristic, and truthfully, different speeds and ranges will be
true for any real world deployment.....

Thanks, 

Pratik

> Sent: Friday, January 27, 2006 12:11 PM
> Thanks for distilling your scenarios into something that we 
> can try to use. Questions below:
> 
> that GTNetS 
> > does support the capability of specifying different radio 
> ranges and 
> > velocity for nodes. However the current software does not 
> incorporate 
> > this capability. We should consider whether the software can be 
> > upgraded with this functionality , if the effort is not 
> 'too much'. We 
> > can then simulate any desired real world scenario.
> 
> I think that it is doable within reasonable effort.  Radio 
> range should be very easy to set on a per-node basis, 
> although making range a function of whether moving or pausing 
> would be new; mobility will require a little bit more work.
> 
> > 
> > Having said that, the info below presents an actual deployment 
> > scenario, followed by tailored extractions which can be run on the 
> > software as it stands today without the above modification.
> > 
> > Thanks,
> > 
> > Pratik
> > 
> > Real world deployment scenarios for OSPF-MANET are expected to have 
> > different levels complexity. As per IETF-64 the current scenario is 
> > defined as follows:
> > 
> > Scenario ID: 1
> > Grid Size = 500 m^2
> > Radio Range = 250 m
> > Velocity = 10 m/s
> > Pause Time = 40 s
> > 
> > The following scenarios are proposed as additions to the above 
> > scenario based on deployment models for different ground 
> and airborne 
> > wireless networks. However while defining the scenario certain 
> > constraints of the current simulation runs may require a 
> 'tailoring' 
> > of the scenario. The scenarios are thus presented here in 
> two steps. 
> > The actual deployment scenario is first described, which is then 
> > tailored to one or more scenarios to match current simulation 
> > constraints.
> > 
> > The above deployment scenario is tailored into the 
> following scenario 
> > based on analysis of each node's characteristics and the 100 node 
> > limit for current scenarios:
> > 
> > Scenario ID: 2
> > No. of Nodes = 100
> > Note: Scenario ID 2 is arrived by considering only a portion of the 
> > mobile nodes in the Actual Deployment Scenario. It also 
> eliminates all 
> > static nodes from the scenario and picks only a certain 
> type of mobile 
> > nodes with one value of radio range.\
> 
> A few questions:
> - are you comfortable with how the radio is modeled (see 
> section 3.2 of our technical report)?  For instance, the 
> relationship between carrier-sense threshold and receive 
> threshold, as governed by the parameter alpha?
> - we are not running simulations for multiple hours, so in 
> effect, pause time of 1 hour means a static node.  It seems 
> to me that your model will have most modes paused at any 
> given instant, in any case.
> - the density (100 nodes) in your grid size, along with the 
> radio range, seems to suggest that the network will be mostly 
> disconnected.  Is that intentional?
> 
> 
> > 
> > Radio Range = 20,000 m to ground nodes Radio Range of 
> Airborne Nodes 
> > (LOS) = 300,000 m Velocity = 300 m/s Pause Time = N/A Radio Range 
> > during Pause = N/A
> > 
> different 
> > radio ranges/velocity are specified vehicles in a scenario
> > 
> > Scenario ID: 4
> > Radio Range = 20,000 for airborne nodes; 2000 m for ground nodes 
> > Velocity = 300 m/s for airborne nodes; 10 m/s for ground 
> nodes Pause 
> > Time = 1 hour for ground nodes Radio Range during Pause = 
> 12000 m for 
> > ground nodes
> > 
> > 
> > Note: Certain limitiation exist in this tailoring. First the planes 
> > will sometimes not see each other which may often not be 
> the case with 
> > their LOS range of 300 km. But what this scenario is trying to 
> > simulate is the communication between ground nodes and 
> airborne nodes.
> > 
> > Scenario ID: 5
> > This scenario simulates only the planes talking to each other. In 
> > comparion to Scenario 1 Scenario 5 constructs a smaller grid/range 
> > ratio with faster moving vehicles
> 
> In the airborne case, I would be somewhat concerned that our 
> radio/MAC models are not adequate for good modeling.  Do you 
> have assumptions on those aspects?
> 
> Regards,
> Tom
>

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Tue, 31 Jan 2006 07:50:50 -0800

> Sent: Monday, January 30, 2006 6:17 AM
> To: Henderson, Thomas R; [email-masked]
> Will look into radio parameters and get back to the mailing 
> list. On your question on disconnectedness, the actual 
> scenario has actual trajectory of vehicles, so there might a 
> difference of how much connected the network is between the 
> two different mobility models (i.e.
> random vs. defined-trajectory), but the vehicles do move in a 
> larger grid area, and therefore can be subject to this 
> behavior regardless. 
> 
> Also, what do you think about upgrading the software to 
> support different speeds or ranges for vehicles in a given 
> scenario. Is that a change that can be incoporated ? 

It is doable-- it will not be in the next code snapshot, though (posted
later this week).

Tom