Mobility Model Question

[Phillip]

Hi there,

I'm new to ns-3 and I'd first like to say that I'm a huge fan of how
ns-3's code is written, documented, and integrated with Python. Now
that I'm able to run some basic simulations, I have a question
regarding mobility models:

GTNetS (the simulator I used previously) had a nice waypoint mobility
model that let users define lists of (time,location) tuples and it
would handle determining the actual location at times in between the
waypoints (in a linear fashion). I know ns-3 will allow me to schedule
location updates for a node say, every second, but as far as I can
tell it won't calculate new positions in between time steps (such as
when packets are received). Is this something that I'd be better off
implementing as my own mobility model, or is there a way to do it
already that I'm missing? It seems that I might be able to craft
something from my data using the constant velocity model, but I feel
like there might be a better tool for the job.

Cheers,

Phillip

[Mathieu Lacage]

Did you look at the RandomWaypointMobilityModel ? (see
src/mobility/random-waypoint-mobility-model.cc/h)

samples/main-random-walk.cc shows how to setup a RandomWalk mobility
model but you should be able to setup a random waypoint model
similarly if you set the right attributes.

Mathieu

--
Mathieu Lacage <mathieu...@gmail.com>

[francesco]

> tell it won't calculate new positions in between time steps (such as
> when packets are received). Is this something that I'd be better off
> implementing as my own mobility model, or is there a way to do it
> already that I'm missing?

As far as I remember, the MobilityModel class (and subclasses, of
course) has a GetPosition method that does the trick -- returning the
_current_ position of a point. Of course, when implementing your model
you need to implement this method too. Looking at
RandomWaypointMobilityModel is a good suggestion. It does schedule
some events (when the agent changes its direction/speed), but the
actual positions are calculated in GetPosition.

[Phillip]

Thanks for your input, Mathieu & Francesco.

After some deeper investigation over the weekend, I came to understand
how using RandomWaypointMobilityModel is capable of fulfilling my
needs, but I still feel that my situation is a common use case that
could be optimized (and I provide a solution here). To be specific
about my scenario, I'm working with vehicle movement data and I am
interested in continuous mobility between waypoints at a 1-second
interval. Just to make sure I've got this right, here's what I see
that I'd have to do in order to implement it:

For each node:
Add my waypoints to a ListPositionAllocator
Install the mobility on the node with the proper start/stop times
Schedule a speed update event that happens *just before before* each
position update event
(because my velocity changes every second)

There are some issues I see with this. Every time GetPosition() is
called, it unconditionally updates the position of the node (via
ConstantVelocityHelper). It might be better to check against
m_lastUpdate. Also, there are a number of events that could be avoided
depending on when node positions are needed.

I ended up creating my own "SpecificWaypointMobilityModel" and a data
type "Waypoint" to do all of this a little more efficiently. Because
some simulations can be looking at hundreds of thousands of waypoints
for a large number of nodes, I created the requirement that each
waypoint occur after the previous, so the previous can be thrown out
as soon as possible. This seems reasonable because we don't often see
the simulation moving backwards. The position of each node is only
updated when queried, and updating is optimized for some common
scenarios; e.g. when the time is between two waypoints, only a few
operations are required and the position is cached until the time
changes.

This lets me have a constant velocity between every two waypoints, and
a low-cost semi-continuous mobility model. The only problem (if it is
actually a problem) is that calls to NotifyCourseChange() are not made
at each waypoint unless the position is easily queried at each
waypoint, but this is something that could be configured if necessary
(e.g. an UpdateAtWaypoints attribute).

This is something I'd be very happy to contribute, as I've noticed
other ns-3 users are also interested in MANET simulation. There might
be some logic to iron out, but it integrates well and I've been using
it for a few days now without any complications. I know it might not
be a high priority feature, so I am willing to document and maintain
this feature as well.

I'd love to get some feedback from maintainers and others doing VANET-
type simulations alike.

Cheers,

Phillip

[Michael]

Phillip,

I am also trying to do VANET simulations with ns3. I haven't gotten
too far, as I'm still trying to figure out how to write the networking
side still. Do you have some models of the networking part that you
would be willing to share? If you have the mobility part, that would
be great too! I have read that there is a way to import mobility
traces (from a mobility/traffic simulator) very similar to the way ns2
imports traces, but like I said, I haven't gotten that far along yet.

My difficulty now is trying to figure out how to switch back and forth
between the control channel and the service channel every 50
milliseconds. Part of that problem is figuring out how to change the
PHY frequency (using SetChannelNumber). I can't seem to find any
examples of doing either of those things.

Thanks!
Michael

[patriciaruiz]

Hi!
I also work on VANETs. The problem I found up to now is that I would
like to use 802.11 p which is not implemented in ns3 yet....

[Mathieu Lacage]

On Tue, Oct 20, 2009 at 7:21 PM, Phillip <phillip...@gmail.com> wrote:
> After some deeper investigation over the weekend, I came to understand
> how using RandomWaypointMobilityModel is capable of fulfilling my
> needs, but I still feel that my situation is a common use case that
> could be optimized (and I provide a solution here). To be specific
> about my scenario, I'm working with vehicle movement data and I am
> interested in continuous mobility between waypoints at a 1-second
> interval. Just to make sure I've got this right, here's what I see
> that I'd have to do in order to implement it:

I feel that the way to go would be to use
ConstantVelocityMobilityModel and schedule a set of events for each
change when you start the simulation. Yes, this will create HUGE
numbers of events but, is it a problem in practice ? i.e., did you
notice something especially problematice from a memory or speed
perspective ? If so, how many events are we talking about ? (number of
vehicules, duration of trace data, etc.)

Mathieu
--
Mathieu Lacage <mathieu...@gmail.com>

[Phillip]

It's going to be a little while before I can get my "real" simulations
up and running with ns-3, but your questions got me curious so I
whipped up a test script, in which every node follows the same path
and fires off some packets during its trip. While these results are
relatively anecdotal (and can be considered worst-case), they helped
provide me with some insight on (1) the code difference between
scheduling velocity-change events and just adding waypoints (to my own
model), and (2) the memory usage requirements of scheduling a large
number of events.

My test was pretty basic, and I played with the parameters a bit but
most of the results follow a trend. I simulated 50 vehicles traveling
along the same path consisting of 3600 waypoints over the course of
3600 seconds. The method of movement was the only thing that changed:
velocity update events vs. the automatic updates from my custom
mobility model. During each vehicle's trip, 1000 L3 broadcasts are
sent at random times (and verified as received, but that's less
important). Most parameters were left as default, with a
ConstantRateWifiManager and an AdhocWifiMac (no internet stack was set
up for these runs). I do mostly understand the implications of this
setup (I grok source code as a hobby!), but as I said this is a basic
test and I might have time for more detail in the coming months. If
there is anything really simple that would help this experiment that I
missed, feel free to point it out.

As far as speed goes, my mobility model provided only a 0-2% speed
increase (parameter-dependent), which is much less than I expected,
but I also haven't looked much into any optimization possibilities.
The lack of improvement there led me to do some memory profiling to
see if there was any significant benefit at all, which made me feel
better about caring about this issue in the first place :)

Here are some massif graphs that I hope will come out okay in their
default format.

First, the memory usage (compared to total) for the event-based method
using existing mobility models:

--------------------------------------------------------------------------------
Command: ./build/optimized/scratch/mobile-wireless -c
Massif arguments: --time-unit=B
ms_print arguments: massif.out.c3
--------------------------------------------------------------------------------


MB
27.63^#..
|#::::.
|#::::: ::..
|#::::: :::: :..
|#::::: :::: ::::.
|#::::: :::: ::::: :: .
|#::::: :::: ::::: :: ::..
|#::::: :::: ::::: :: :::: :,..
|#::::: :::: ::::: :: :::: :@:::..
|#::::: :::: ::::: :: :::: :@:::::::..
|#::::: :::: ::::: :: :::: :@::::::::::@ .
|#::::: :::: ::::: :: :::: :@::::::::::@ ::@..
|#::::: :::: ::::: :: :::: :@::::::::::@ ::@:::..
|#::::: :::: ::::: :: :::: :@::::::::::@ ::@::::::.,.
|#::::: :::: ::::: :: :::: :@::::::::::@ ::@:::::::@::..
|#::::: :::: ::::: :: :::: :@::::::::::@ ::@:::::::@::::::,.
|#::::: :::: ::::: :: :::: :@::::::::::@ ::@:::::::@::::::@::..
|
#::::: :::: ::::: :: :::: :@::::::::::@ ::@:::::::@::::::@:::::@..
|
#::::: :::: ::::: :: :::: :@::::::::::@ ::@:::::::@::::::@:::::@:::...
|
#::::: :::: ::::: :: :::: :@::::::::::@ ::@:::::::@::::::@:::::@::::::@.
0
+-----------------------------------------------------------------------
>GB

0
3.261

Number of snapshots: 83
Detailed snapshots: [1 (peak), 24, 36, 40, 50, 60, 70, 80]

--------------------------------------------------------------------------------
n time(B) total(B) useful-heap(B) extra-heap(B)
stacks(B)
--------------------------------------------------------------------------------
0 0 0 0
0 0
1 29,215,328 28,971,312 25,226,619
3,744,693 0



Now, with the SpecificWaypointMobilityModel (mine):

--------------------------------------------------------------------------------
Command: ./build/optimized/scratch/mobile-wireless -w
Massif arguments: --time-unit=B
ms_print arguments: massif.out.w3
--------------------------------------------------------------------------------


MB
15.85^#.
|#::: ..
|#::: ::: ..
|#::: ::: ::::.
|#::: ::: :::::::: .
|#::: ::: :::::::: : .,
|#::: ::: :::::::: : :@::..
|#::: ::: :::::::: : :@:::::: ..
|#::: ::: :::::::: : :@:::::: :: ..
|#::: ::: :::::::: : :@:::::: :: ::@ ..
|#::: ::: :::::::: : :@:::::: :: ::@ :: :..
|#::: ::: :::::::: : :@:::::: :: ::@ :: ::::: .
|#::: ::: :::::::: : :@:::::: :: ::@ :: ::::: :@.
|#::: ::: :::::::: : :@:::::: :: ::@ :: ::::: :@: :: .
|#::: ::: :::::::: : :@:::::: :: ::@ :: ::::: :@: :: : :@.
|#::: ::: :::::::: : :@:::::: :: ::@ :: ::::: :@: :: : :@:::.,
|
#::: ::: :::::::: : :@:::::: :: ::@ :: ::::: :@: :: : :@::::@::..
|
#::: ::: :::::::: : :@:::::: :: ::@ :: ::::: :@: :: : :@::::@::::::,.
|
#::: ::: :::::::: : :@:::::: :: ::@ :: ::::: :@: :: : :@::::@::::::@::..
|
#::: ::: :::::::: : :@:::::: :: ::@ :: ::::: :@: :: : :@::::@::::::@::::
0
+-----------------------------------------------------------------------
>GB

0
3.246

Number of snapshots: 74
Detailed snapshots: [1 (peak), 20, 32, 41, 48, 56, 66]

--------------------------------------------------------------------------------
n time(B) total(B) useful-heap(B) extra-heap(B)
stacks(B)
--------------------------------------------------------------------------------
0 0 0 0
0 0
1 19,911,408 16,623,264 15,555,907
1,067,357 0



So, despite the lack of a huge speed increase, there is a tangible
memory usage benefit. Also, the code is a bit more simple to set up a
VANET-type simulation where paths are expressed as waypoints. Let's
pretend we have a waypoint type set up, which is a struct containing a
time (t) and position (p). The code for a
ConstantVelocityWaypointModel might look something like this (with a
previously set up deque of waypoints):

for ( std::deque<Waypoint>::const_iterator i = waypoints.begin ();
i != waypoints.end (); ++i )
{
if ( i == waypoints.begin() )
{
lastWaypoint = (*i);
nodeMobility->SetPosition (lastWaypoint.p);
continue;
}

span = ((*i).t - lastWaypoint.t).GetSeconds ();
currentVelocity.x = ((*i).p.x - lastWaypoint.p.x) / span;
currentVelocity.y = ((*i).p.y - lastWaypoint.p.y) / span;
currentVelocity.z = ((*i).p.z - lastWaypoint.p.z) / span;

Simulator::Schedule (lastWaypoint.t, UpdateVelocity,
nodeMobility, currentVelocity);
lastWaypoint = (*i);
}

Simulator::Schedule (lastWaypoint.t, UpdateVelocity, nodeMobility,
Vector (0,0,0));

--

Whereas a waypoint-based mobility model would simplify it to this:

for ( std::deque<Waypoint>::const_iterator i = waypoints.begin();
i != waypoints.end(); ++i )
nodeMobility->AddWaypoint(*i);

(and no UpdateVelocity event handler would be required)

--

This is assuming there is a "Waypoint" type and we have a mobility
model that would accept it, of course. I feel that myself and other
VANET simulation users look at mobility in a way that would be better
expressed as waypoints during a trip rather than velocity changes at
specific times.

Hopefully this sheds some light on the current situation, and I'll do
my best to provide any other test results/traces if necessary.
Currently, I'll setter with either implementation but I of course
prefer lower memory usage to promote simulation scalability. After
some time with ns-3, I'm seeing that my efforts might be better spent
on figuring out how to remove nodes from a very long running
simulation, which would also benefit many like-minded MANET/VANET
researchers.

Cheers,

- Phillip

On Oct 23, 12:46 am, Mathieu Lacage <mathieu.lac...@gmail.com> wrote:

> Mathieu Lacage <mathieu.lac...@gmail.com>

[Mathieu Lacage]

On Sun, Oct 25, 2009 at 8:08 AM, Phillip <phillip...@gmail.com> wrote:

[detailed analysis elided]

> So, despite the lack of a huge speed increase, there is a tangible
> memory usage benefit. Also, the code is a bit more simple to set up a

ok.

> This is assuming there is a "Waypoint" type and we have a mobility
> model that would accept it, of course. I feel that myself and other
> VANET simulation users look at mobility in a way that would be better
> expressed as waypoints during a trip rather than velocity changes at
> specific times.

This sounds like a good rationale for such a model. If you have it
already working, it probably would make sense to try to submit it for
inclusion in the next release, independently from your other work.
Early and small merges/contributions are easier to handle for
everyone. The above rationale would also be a great start for the
associated doxygen documentation :)

> Hopefully this sheds some light on the current situation, and I'll do
> my best to provide any other test results/traces if necessary.

I would be curious to see what a typical trace file looks like (say,
format, size, number of node, simulation duration in simulation time,
etc.). Getting information about how users use the simulator is really
hard and always interesting/surprising to me.

> Currently, I'll setter with either implementation but I of course
> prefer lower memory usage to promote simulation scalability. After
> some time with ns-3, I'm seeing that my efforts might be better spent
> on figuring out how to remove nodes from a very long running
> simulation, which would also benefit many like-minded MANET/VANET
> researchers.

The latter is going to be much more complex to do. Right now, the
src/node models in ns-3 were not designed to allow
node disappearance during the simulation. The opposite assumption in
hardcoded in a number of locations (say, the nodeid is immutable and
is a direct index into the NodeList array). The main reason is that
supporting this would have added considerable complexity to our
lifetime management code. (say, what happens to the links connected to
a node which is destroyed ?) I don't think that anyone would object to
adding support for this specific feature but I guess that it will be
quite a bit of work.

[Phillip]

First off, thanks to Michael & Patricia for showing your interest -
hopefully there will be a "ns-3 VANET club" of sorts in the near
future :)

> This sounds like a good rationale for such a model. If you have it
> already working, it probably would make sense to try to submit it for
> inclusion in the next release, independently from your other work.
> Early and small merges/contributions are easier to handle for
> everyone. The above rationale would also be a great start for the
> associated doxygen documentation :)

Ok, I should have my mobility model and waypoint code files documented
and ready to go in the next week or so. It'll be a little longer
before I can craft some examples and tests, but this will give you &
other core devs a chance to review the API. It's relatively simple,
but I know there are some semantics that could be shuffled around if
necessary to match the ns-3 way of doing things.

> I would be curious to see what a typical trace file looks like (say,
> format, size, number of node, simulation duration in simulation time,
> etc.). Getting information about how users use the simulator is really
> hard and always interesting/surprising to me.

For your curiosities :) -

I have a homebrew setup that imports vehicle simulation data into a
database, and this lets me do all sorts of fancy things with it. A
snippet of the more important trace would look like this for my
"index" table, which holds IDs and trip info for all vehicles:

select id,s_time,e_time,d_first,d_last,d_count from axn.sub1 limit 5;

id | s_time | e_time | d_first | d_last | d_count
----------+--------+--------+---------+--------+---------
36170401 | 75393 | 76117 | 75409 | 75712 | 304
36170501 | 29055 | 31040 | 29071 | 29451 | 381
36170601 | 52336 | 53139 | 52352 | 52620 | 269
36170701 | 49289 | 49993 | 49305 | 49577 | 273
36170801 | 58249 | 59218 | 58265 | 58676 | 412
(5 rows)

With that information, I could select trace info for any vehicle from
the data table. Although it gets massive, table partitions and time
indexes make searches based on info from the index table fast.

select time,x,y,acc,lane from axn.sub1_data where id=36170401 and time
between 75393 and 76117;

time | x | y | acc | lane
-------+------------------+------------------+------+------
75409 | 322309.52214079 | 4300896.38136679 | 0 | 3
75410 | 322317.302414227 | 4300868.27199179 | 0 | 3
75411 | 322325.333664227 | 4300840.16261679 | 0 | 3
...
75711 | 320612.643131543 | 4298808.22499472 | 0 | 1
75712 | 320608.627506543 | 4298808.22499472 | 7.5 | 1
(304 rows)

For VANET simulations, data organization of this sort is pretty
common, as are fields like location, lane, speed, direction, and
acceleration.

A typical simulation for me involves about 5000 cars, traveling on
specific trips from A->B with an average trip time of 15 minutes, and
the simulation time is usually 1 or 2 hours. I have the ability to
generate and store 5 million trips over a 24 hour simulation period,
but I think it's going to be quite some time before I find a simulator
that can handle such a scale in a reasonable amount of time.

> The latter is going to be much more complex to do. Right now, the
> src/node models in ns-3 were not designed to allow
> node disappearance during the simulation. The opposite assumption in
> hardcoded in a number of locations (say, the nodeid is immutable and
> is a direct index into the NodeList array). The main reason is that
> supporting this would have added considerable complexity to our
> lifetime management code. (say, what happens to the links connected to
> a node which is destroyed ?) I don't think that anyone would object to
> adding support for this specific feature but I guess that it will be
> quite a bit of work.
>

I was afraid of this, but simulation longevity is important enough to
me that I might tackle it someday- when the time comes, I might pick
your brain a bit for guidance/ideas.

Cheers,

Phillip

[GAURAV JAIN]

Hi Philip,
I know this post is quite old, however I have a very unusual request to make.
Could you please share your codes of mobility model as soon as possible
Thank You

[xavier ashish]

hi everyone

can anybody help me in implementing two set of mobility model in a network.

what i mean is this,

if i deploy three nodes

i assign one node with RWP mobility and rest of the two nodes will be stationary ( constant position mobility model).