Noname manuscript No.
(will be inserted by the editor)
MOMOSE
A Mobility Model Simulation Environment for Mobile Wireless
Ad-hoc Networks
Stefano Boschi · Pilu Crescenzi · Miriam Di
Ianni · Carlo Nocentini · Gianluca Rossi ·
Paola Vocca
14 December 2008
Abstract This paper describes MOMOSE, a highly flexible and easily extensible environment for the simulation of mobility models. MOMOSE not only allows a programmer
to easily integrate a new mobility model into the set of models already included in
its distribution, but it also allows the user to let the nodes of the MANET move in
different ways by associating any mobility model to any subset of the nodes themselves.
The environment allows the user to define and to subsequently use configuration windows, whose content depends on the mobility model, and its GUI includes a simulation
window that allows the user to manage and control the execution of a simulation.
Moreover, MOMOSE allows the user to simulate the movement of the nodes within a
“realistic” environment, where obstacles (such as buildings and barriers) are present
This work was partially supported by the EU under the EU/IST Project 15964 AEOLUS.
Stefano Boschi
Dipartimento di Sistemi e Informatica, Università degli Studi di Firenze, Viale Morgagni 65,
50134 Firenze, Italy,
E-mail: boschis@gmail.com
Pilu Crescenzi
Dipartimento di Sistemi e Informatica, Università degli Studi di Firenze, Viale Morgagni 65,
50134 Firenze, Italy
Miriam Di Ianni
Dipartimento di Matematica, Università degli Studi di Roma II, Viale della Ricerca Scientifica,
00133 Roma, Italy,
E-mail: diianni@mat.uniroma2.it
Carlo Nocentini
Dipartimento di Sistemi e Informatica, Università degli Studi di Firenze, Viale Morgagni 65,
50134 Firenze, Italy,
E-mail: nocentini@dsi.unifi.it
Gianluca Rossi
Dipartimento di Matematica, Università degli Studi di Roma II, Viale della Ricerca Scientifica,
00133 Roma, Italy,
E-mail: gianluca.rossi@uniroma2.it
Paola Vocca
Dipartimento di Matematica, Università del Salento, Via per Arnesano, 73100 Lecce, Italy,
E-mail: paola.vocca@unile.it
2
and limit the movement of the nodes. Finally, MOMOSE can be easily adapted in order
to record, during the simulation time, all the data necessary for the evaluation of the
performance of any communication protocol or of any MANET-based application. As
far as we know, MOMOSE is the only mobility model simulation environment that has all
these features and which is currently available as a free software project.
Keywords MANET · mobility model · network simulator · simulation environment
1 Introduction
A mobile wireless ad hoc network (in short, MANET ) is a computer network in which
no pre-existing communication infrastructure exists, communication links are wireless,
and nodes are free to move and organize themselves in an arbitrary fashion. These
networks are expected to have several applications because of the minimal configuration
and the quick deployment they require: natural or human-induced disasters, intervehicular communication, law enforcement, military conflicts, and emergency medical
situations are just a few examples of application areas in which MANETs are expected
to play an important role.
Since the nodes of a MANET are mobile, the network topology may change rapidly
and unpredictably over time. It is then important, in order to evaluate the performance
of any communication protocol or of any MANET-based application, to be able to
accurately simulate the mobility traces of the nodes that will eventually utilize the
protocol or the application. To this aim, we need a mobility model that describes the
movement pattern of mobile users, and how their location, velocity and acceleration
change over time.
We can distinguish two basic approaches in order to obtain a mobility model. The
first approach consists of constructing the mobility model on the ground of accurate information about the mobility traces of users: however, obtaining real mobility traces is
usually a great challenge. For this reason, various researchers proposed different kinds
of mobility models that are not trace-driven and that are called synthetic mobility models. A great variety of such mobility models have been proposed in the literature, which
differ according to at least one of the following criteria [12]: the geographic constraints
that a mobile node has to deal with, the scale the model is designed to work for, and
the individuality which is determined by the node aggregation level of the model. Some
examples of mobility models that have been proposed in the past are1 the random
walk model [17, 20, 31, 32], the random waypoint model and its many variations [25],
the random direction model and its many variations [6, 33], the boundless simulation
area model [11], the Gauss-Markov model [11], the city section model [11], the exponential correlated random model [19], the column model [34], the nomadic community
model [34], the pursue model [34], the reference point group model [19], and, more recently, the real-world environment model [23], the virtual track group model [41], the
ripple model [13], the clustered model [26], the social model [28], and the TCP-based
worm spread model [1].
In this paper we describe the MOMOSE tool, which is a highly flexible and easily
extensible environment for the simulation of mobility models. Indeed, MOMOSE not only
1 This list is certainly not exhaustive: our goal, however, is just to give a flavor of the huge
quantity of mobility models that have been proposed in the literature and of how important
the mobility simulation topic is within the MANET research area.
3
allows a programmer to easily integrate a new mobility model into the set of models
already included in its distribution, but it also allows the user to let the nodes of the
MANET move in different ways by associating any mobility model to any subset of the
nodes themselves. Moreover, MOMOSE can be easily adapted in order to record, during
the simulation time, all the data necessary for the evaluation of the performance of any
communication protocol or of any MANET-based application.
The paper is structured as follows. In the rest of this section we introduce our
simulation tool and the technical motivations behind our primary design choices. In
Section 2, we describe the software architecture of MOMOSE and we briefly explain how
a programmer can use MOMOSE in order to develop a new mobility model and/or a new
data recorder. In Section 3 we present the experiments that we have executed in order
to evaluate the performance differences between the two simulation engines included
in MOMOSE. In Section 4 we summarize some of the tools that, according to our opinion,
are the most related to our application and we present some experimental performance
comparisons. In Section 5 we briefly describe three case studies, while we conclude in
Section 6 by presenting some research directions.
1.1 A Description of MOMOSE Features
While developing MOMOSE we have taken into account the following basic principles.
Extensibility. Within the MOMOSE framework, a programmer can easily implement
new mobility models: we believe this is an interesting feature of the framework, since
research on mobility models is still very active and new models are continuously
introduced in the literature (see, for example, [14]). Observe that there are basically
no limits on the complexity of the mobility model the user wants to implement:
for example, it is not difficult to implement models with more complex trajectories
(the authors have already implemented a variation of the random waypoint model
in which the trajectory followed by the nodes is a Bezier curve) or in which the
nodes follow external mobility traces obtained by any trace repository. The user
can also define and easily implement appropriate data recorders, that is, sets of
data structures and methods, in order to collect, during the simulation, the data
necessary for the evaluation of a mobility model or of a specific protocol. Observe
that this feature does not really make MOMOSE a network simulator (such as the ones
cited in Section 4), since many aspects of the simulation of a computer network
mainly related to the lower levels of the network architecture are not taken into
account by the MOMOSE framework.
Adaptability. Two kinds of adaptability features have been mainly considered. On
one hand, we believed it was important to allow different mobility patterns to be
used within the same simulation and that it was not plausible to assume all nodes
moving according to the same mobility model. For this reason, by using MOMOSE
and without writing any line of code, the user can easily simulate the movement
of a set of nodes by using any combination of the mobility models included in
the MOMOSE distribution and of the newly implemented mobility models. On the
other hand, we believed that the same simulation should have been used in order
to analyze different aspects and consequences of the node mobility. For this reason,
during a simulation, one or more data recorders can be used, which allow the user
to collect the interesting data (see Figure 1). For example, a data recorder could
4
Fig. 1 The MOMOSE flow diagram
compute the distribution of the nodes during the simulation time in a given area,
while another data recorder could compute the degree of each node (that is, the
number of active connections for each node): both data recorders could store this
information into the same output file, which could be subsequently used in order
to produce statistics or reports. The current distribution of MOMOSE includes a data
recorder that produces trace files compatible with the ns-2 network simulation
environment [16], which is one of the most popular network simulators within the
research community. As far as we know, the mobility modules produced for this
simulator include only very simple mobility models, such as the random waypoint
model [21] and the random walk model [27]: MOMOSE can hence be used in order to
produce more realistic mobility patterns, which can be subsequently used by ns-2
while simulating and evaluating any network protocol.
Efficiency. This is quite an obvious requisite of any simulation tool. Even in this case,
two different kinds of efficiency have been identified. On one hand, while evaluating the characteristics of a mobility model, we have considered very important to
visually and efficiently analyze the behavior of a set of nodes moving according to
the model itself. The graphical user interface (in short, GUI) of MOMOSE is based on
the Java Swing classes and on the OpenGL standard [38]: as we will state in a later
section, using the OpenGL libraries makes our framework extremely performant
for what concerns the visualization of a simulation. On the other hand, an efficient
simulation engine turns out to be useful whenever massive simulations have to be
performed in order to collect sufficient data for successive elaborations. The MOMOSE
simulation engine has been developed both in Java and in C++ (see Figure 1): the
former one is deeply integrated with the GUI and allows the user to interactively
control the simulation and its visualization, while the latter is optimized from a
performance point of view and is accessible only by means of command lines. The
reason why we decided to include two different simulation engines is strictly connected to the main characteristics of the two programming languages. Java is highly
portable and the Swing classes behave essentially in the same way, independently
from the used processor/operating system platform: on the contrary, several different graphical libraries have been developed in C++, and it does not seem that
any of them can be considered as the standard one. Hence, the Java version of
5
Fig. 2 The simulation and mobility model configuration windows
the simulation engine is particularly appropriate during the development phase of
a mobility model and/or of a data recorder: in this case, indeed, the GUI allows
the user to easily configure the simulation parameters and to observe in real-time
the node movement and the evolution of the simulation itself. On the other hand,
the C++ engine, which has to be compiled for any possible platform/operating system platform, has the advantage of being significantly faster than the Java engine:
hence, this version of the engine is more appropriate for the execution of simulations with a long simulation time and/or with a huge number of nodes (as we will
see in a later section, its efficiency outperforms or at least compares with the one
of similar mobility model simulation tools).
Mobility model and data recorder configurability. During each simulation, the
set of the nodes of the network is partitioned into an arbitrary number of subsets,
each one corresponding to the specific mobility model governing the movement of
the nodes in the subset: however, since each node has an own logic unit which
is independent from the other nodes, different nodes in the same subset are allowed to play different roles within the same mobility model (for example, in the
PursueModel [19] it is necessary to allow one node to act as the leader of the
subset). The behavior of a mobility model is typically determined by the value
of some model-specific parameters: for example, in the case of the Gauss-Markov
mobility model [35] the parameter α which determines the randomness degree of
the model has to be specified, while in several other models typical parameters
are the acceleration value or the angular velocity value [7]. In general, a unique
set of parameters which can be used for any mobility model does not exist: for
this reason, MOMOSE allows the user to define and to subsequently use configuration
6
Fig. 3 The simulation window
windows whose content depends on the mobility model (see the foreground window
of Figure 2). In this way, it is very easy to tune all the parameters of a specific
model, both the parameters common to all mobility models (such as the number of
nodes moving according to the model or the maximum node transmission range)
and the parameters which are meaningful for that specific model only (such as the
attraction degree in the case of the nomadic model [35]): moreover, this parameter
tuning can be saved in appropriate files, which can be successively reloaded. A
similar approach can be also followed in the case of data recorders whose behavior
depends on the value of specific parameters: even in this case the user can define
and subsequently use specific configuration windows in order to set up parameters
such as the name of the file into which the collected data will be written.
Simulation configurability. By means of the MOMOSE GUI, the user can control any
aspect of a simulation both before its beginning, by interacting with its configuration window, and during its execution, by interacting with the simulation window.
The configuration window (see the background windows of Figure 2) allows the user
to set up the simulation time and the simulation scenario (which can range from
an empty area to any environment specified in an appropriate file). It also allows
the user to select and configure the mobility models and the data recorders to be
used during the simulation. Starting from the simulation configuration window, the
user can directly start the simulation itself or can save the current configuration
into an appropriate file, which can be subsequently used by one of the two engines
previously described in order to execute the simulation and collect the required
data (clearly, a configuration file can be reloaded and modified at any subsequent
moment).
7
Fig. 4 The OpenGL player
User friendly interface. The simulation window (see Figure 3) allows the user to
manage and control the execution of a simulation: in particular, at any moment
the user can pause and restart the execution, can stop it, can see log messages produced by the simulation engine, and can activate a graphical window which shows,
in real-time, the movement of all the nodes within the specified scenario (along
with other informations related to the simulation). Moreover, MOMOSE includes an
OpenGL player which allows the user to visualize and graphically analyze the evolution of a simulation, which was previously saved into appropriate files by a default
data recorder included in the MOMOSE distribution. Within the main drawing area of
the player, the simulation scenario and the movement of the nodes are shown (see
Figure 4): on the left of this area, some basic information about the scenario and
the simulation time is given together with some tools for controlling the simulation
itself (as with any other player, the user is also allowed to pause and restart the simulation and to fast advance it both forward and backward). During the simulation,
some additional information can be visualized within the drawing area, such as the
node IDs, the node transmission ranges, and the communication graph. Since long
simulations with a large number of nodes might produce huge trace files, MOMOSE
allows the user to save these files in a compressed form (in particular, by using the
gzip standard): these compressed files can be directly loaded and visualized by the
player.
Adherence to reality. MOMOSE allows the user to simulate the movement of the nodes
within a “realistic” environment, where obstacles (such as buildings and barriers)
8
are present and limit the movement of the nodes.2 The definition of a scenario is
flexible enough to allow the user to define significantly different situations, ranging
from people moving within a building or a campus to robots moving within a
disaster recovery environment or to vehicles moving within an urban environment.
Indeed, a scenario is defined by means of an XML file which contains the list
of obstacles that are present in the simulation area. Each obstacle is formed by
one or more polygons (in particular, squares, rectangles and/or circles): for each
polygon, the XML code specifies its position, its rotation angle, its color, its name
and its attenuation factor (which is a number between 0 and 1). A scenario can
also contain a set of hot-spots, that is, specific points of the simulation area which
are of particular interest for the nodes: by means of this feature, it is possible to
define within the scenario a graph, which can be used by a mobility model while
deciding the movement of a node (such as in the case of the pathway model [37]).
The XML standard allows the user to easily define new scenarios: however, MOMOSE
includes the possibility of generating a scenario starting from a Scalable Vector
Graphics (in short, SVG) file. Hence, the user can create the scenario by using any
drawing program, in order to subsequently export it in the SVG format and, hence,
to translate it into the XML code required by the MOMOSE simulation engine.
Portability. As we already noticed, choosing Java and C++ as development languages,
makes MOMOSE easily portable both in terms of user interface and in terms of simulation engines. It is also worth noting that, since the simulation configuration files,
the scenario definition files and the player trace files are written by using the XML
technology and they are all independent from each other, they can be immediately ported on different processor/operating system platforms, provided that an
instance of MOMOSE has been installed.
2 The Software Architecture and the Simulation Execution Flow
Apart from the GUI, the main software components of MOMOSE are the simulation
engine,3 the models, the nodes and the data recorders. Each of the latter three components is represented by means of an abstract Java class. The MOMOSE distribution
includes several template classes that can be extended by the programmer in order to
develop personalized mobility models and data recorders.
The simulation engine contains several components managing the following different
aspects of a simulation.
– The mobility model manager is in charge of the nodes and of the mobility models
during the simulation.
– The physical engine manager computes the collisions between the nodes and the
obstacles which are present into the scenario and, hence, moves the nodes within
the simulation area.
2 Even though this is not strictly related to the simulation of mobility models, MOMOSE also allows the user to let the obstacles attenuate the transmission signals sent by the communication
units: this features can be useful for developing specific data recorders.
3 From a functional point of view, the Java and the C++ simulation engines are equivalent:
all the classes that represent the different simulator components have the same interface and
do the same task. In this way, the programmer can switch from one engine to the other without
having to modify a single line of the code.
9
– The scenario manager is in charge of the logical representation of the simulated
environment and of all the objects which are contained in the environment itself.
– The data recorder manager allows the data recorders to store the data collected
during the simulation.
– The time manager is in charge of the advance of the simulation clock.
A simulation execution is divided into three phases: the simulation setup phase,
the simulation cycle phase, and the simulation end phase. During the setup phase all
the data structures necessary for the simulation execution are initialized: the behavior
of this phase is determined by the information read from the simulation configuration
file, produced by means of the GUI or directly written by the user. The different
components of the simulation engine are initialized one after the other starting from the
time manager data structures and, subsequently, the scenario and all the objects that
are contained within it. Successively, the mobility models and the node generation are
initialized: during this step, each model can setup its own data structures and create
the nodes that will move into the simulation area. The nodes have some common
properties (such as the ID, the transmission range, and the velocity vector); moreover,
each node can be defined as a physical object, so that it can collide with other nodes.
During their generation, the nodes are also assigned an initial position: to this aim, the
mobility model can analyze the scenario, if necessary (for example, in order to position
a node onto an hot-spot or to avoid to position a node onto a wall). At the end of
this step, all the information concerning the models and the nodes are passed to the
initialization step of the mobility model manager and of the physical engine manager.
The last step of the setup phase consists of the initialization of the data recorders
and of their manager: similarly to the mobility model initialization, each data recorder
setup its own data structures (such as the output file or counter variables).
Once the setup phase is done, the simulation cycle starts. At each cycle, the time
manager updates the internal clock of the simulator and checks for the ending conditions. If the simulation is not ended up, the mobility model manager makes each node
and model choose the next operation to be performed. Both models and nodes may
perform any required operation: for instance, a model may generate a new target for
its nodes, may change the role of some or of all its nodes and may interact with other
models, while a node may switch on or off its own transmission device, may change
its own role, may change its speed and direction, and may modify its transmission
range (notice that, by modifying the transmission range, energy saving arguments can
be also taken into account). While such operations are performed, the simulator keeps
models and nodes informed about the simulation time, the scenario and the states of
the other nodes in order to let them take the correct decisions. For instance, a node
may need information about the scenario in order to determine whether collisions may
occur while moving at a given speed and direction, or it may need information about
the hot-spot list in order to choose its next target destination. After the mobility model
manager step, the physical engine manager gets the simulation control and computes
the new node positions, taking into consideration the collisions between nodes and
scenario objects and among nodes. In order to speed up these operations, the physical
engine manager represents the simulation area by a BSP tree:4 such a tree is built during the setup phase and it allows the physical engine manager to save computational
time, since only the collisions between a node and its surrounding physical objects are
4 The Binary Space Partitioning [18] technique is a recursive partitioning of the space into
convex sub-spaces, which is described by means of a binary tree (called BSP tree).
10
considered. At the end of any simulation cycle, each data recorder collects the required
data and records system information at current time. Data recorders may access all
simulation data (such as time, scenario, and system state) and may access all the information about models and nodes involved in the simulation: for instance, one data
recorder might compute the communication graph and draw its diameter, the node
degrees, and the number of connected components, while another data recorder might
write the logs of node positions and states at the current simulation cycle.
The last phase of a simulation is the simulation end, during which a procedure is
invoked for any data recorder that allows it to execute some final tasks. For example,
it is possible to close the open files, to evaluate some performance values by using the
collected data, or to create reports and the similar. During this phase, the simulation
engine erases all temporary data structures. Finally, the simulation ends and the output
files created by the data recorders can be used for the analysis or can be exploited by
other tools.
2.1 Extending MOMOSE
As previously stated, MOMOSE allows the programmer to create new mobility models
and new data recorders starting from a set of template classes. In order to develop a
new mobility model, the programmer has to implement three classes, which manage
the creation of the model, represent the model itself, and represent a node moving
according to the model, respectively. Optionally, the programmer can implement two
additional classes, which represent the model configuration window and whose task is
reading all the necessary information starting from a configuration file, respectively:
these two classes should allow the user to easily manage the model parameters. The
structure of the classes that implement a data recorder is quite similar to the one of the
classes that implement a mobility model. In particular, the programmer has to define
two classes, which manage the creation of the data recorder, and actually implement
the data recorder itself, respectively. Optionally, the programmer can implement a configuration window class and a class which collects the data recorder set up information
starting from a configuration file. More details concerning the extension of the MOMOSE
framework can be found in [9].
3 Java and C++ Performance Comparison
In this section a performance comparison is presented between the Java and the C++
simulation engines. The analysis is performed by comparing the running times of the
two engines when executing on the same simulation framework (that is, the same simulation time and the same number of nodes). In order to evaluate the real performances,
all additional I/O components have been removed. The simulations have been executed
on a Intel Pentium 4 2.4 GHz processor, with 512 MB of RAM running a Linux (kernel
version 2.6.17-10) operating system.
The first comparison focuses on the number n of nodes. Ten different values of n
have been considered: for each of them, twenty simulations have been executed and
the average execution time has been computed. In particular, for each execution the
simulation time has been set equal to 10800 seconds, while the n nodes have been
partitioned into three equally sized sets moving according to the random waypoint,
11
250
4000
Java engine
C++ engine
3500
Execution time (s)
Execution time (s)
200
150
100
50
Java engine
C++ engine
3000
2500
2000
1500
1000
500
0
0
0
200 400 600 800 1000 1200 1400 1600 1800
Number of nodes
104
105
Simulation time (s)
Fig. 5 A comparison of the average execution time of the Java and the C++ engines with
respect to the number of nodes (on the left) and with respect to the simulation time (on the
right, in a logarithmic scale).
the random walk, and the nomadic mobility model, respectively: in the left part of
Figure 5, the average execution time is shown. It is evident that the C++ engine is
significantly more performing than the Java engine: it also seems that this better
performance does not depend on the number of nodes.
However, one might think that the execution time is too short and that the initial
overhead, that a Java program has usually to pay for,5 cannot be compensated in such
short execution times. For this reason, we have performed a second kind of comparison
which focuses on the simulation time t. Ten different values of t have been considered:
for each of them, twenty simulations have been executed and the average execution
time has been computed. In particular, for each execution 900 nodes have been simulated, partitioned in a way similar to the previously described one: in the right part
of Figure 5, the average execution time is shown (in a logarithmic scale). Even in this
case, the better performance of the C++ engine is quite evident. Even though the performance relative difference slightly decreases while the simulation time increases, it
seems that asymptotically this difference tends to a value close to 40%.
Both the Java and the C++ engine can deal with a very large number of nodes:
indeed, we have experimented up to 100 000 nodes. Clearly, the simulation execution
time depends on the complexity of the used mobility models and of the used data
recorders. Moreover, this time also depends on the number of obstacles which are
present in a scenario: however, we have experimentally verified that the ratio between
the execution time with no obstacles and the execution time with obstacles does not
depend on the number of nodes (for instance, in the case of the scenario represented
in Figure 8, this ratio is approximately equal to 0.1).
4 Related Work and Performance Comparison
Several network simulators are available on the web and most of them include tools for
the generation of node mobility patterns. Four popular examples of such simulators are
ns-2 [48], the GloMoSim environment [42], GTNetS [43], and OMNeT++ along with
its mobility framework [49, 45]. Within these frameworks the node mobility support is
5 For instance, the Java interpreter usually performs a code validity check, which is done
only the first time a method is invoked.
12
90
1.2
Ratio
MOMOSE
80 CanuMoboSim
70
MOMOSE/Sinalgo
1.1
400
50
40
Seconds
Seconds
60
30
20
300
200
10
100
0
0
10
15
20
25
Number of nodes
30
35
40
MOMOSE
Sinalgo
500 1000
2000
3000
4000
5000
Number of nodes
Fig. 6 A comparison of CanuMoboSim, Sinalgo, and MOMOSE with respect to the simulation
execution time (7200 simulated seconds and increasing number of nodes)
only one of their several features and not even the most important one: indeed, these
tools are mostly devoted to the simulation of network protocols and they take into
account many aspects of a protocol execution, starting from the physical layer up to
the application one. Clearly, this makes these tools much “heavier” than a simulator
like MOMOSE, which is mainly focused on the development and the analysis of mobility
models and whose goal is allowing a user to quickly determine the characteristics of a
specific mobility pattern: this is true even in terms of the size of the software needed to
be installed (basically, MOMOSE is two orders of magnitude lighter than the previously
mentioned tools). Moreover, the complexity of these simulators usually makes harder
the task of developing and testing new mobility models, both from a programming
point of view and from a final user point of view.
For all these reasons, we believe that the natural main competitors of MOMOSE are
CanuMoboSim, a framework for user mobility modeling [36], and Sinalgo, one of the
most recent network simulator developed in Java [50].
The CanuMoboSim framework includes a number of mobility models and parsers of
geographic data in various formats, and it is based on the notion of extension module.
In particular, a group of nodes can be extended by specifying the mobility model
according to which all nodes in the group move during the simulation. Moreover, a
simulation can be extended by specifying its spatial environment (which can also be
loaded from a GDF file [22] and from which points of interests can be extracted)
or the graph representation of the movement area (which can be used in the case
of a graph-based mobility model). Several other extension modules are available in
the CanuMoboSim framework: these modules, for instance, allow the user to produce
different kinds of output (similarly to the data recorders of MOMOSE) and to visualize
the simulation (similarly to the player of MOMOSE). The parameters determining the
simulation behavior and the characteristics of a mobility model are specified within
a XML file and no configuration window is available to the final user. Moreover, the
simulation window seems to be quite basic and no control buttons are available within
it. Finally, as far as we can see, the node have no communication range associated and
the engine does not manage the collision between the nodes and the obstacles which
are present in the simulation area (even though, clearly, these features can be added
to the framework by defining suitable extension modules). Most importantly, MOMOSE
significantly outperforms CanuMoboSim in terms of execution time, as we will show at
the end of this section.
A more recent simulation framework for testing and validating network algorithms
is Sinalgo, which, in order to guarantee easy extensibility, offers a set of extension
Seconds
13
200
150
100
50
9
8
7
6
5
4
3
2
600
CanuMoboSim
MOMOSE
Sinalgo
1200
1800
2400
3000
3600
Number of simulated seconds
Fig. 7 A comparison of CanuMoboSim, Sinalgo, and MOMOSE with respect to the simulation
execution time (increasing simulated time and 200 nodes)
points, called models: among the models included in its distribution, the framework
contains the mobility model, that describes how the nodes change their position over
time. As in the case of MOMOSE, more than one mobility model can be used during each
simulation. Moreover, the programmer can create new mobility models by implementing a subclass of the class MobilityModel, which must define the method getNextPos:
the movement of the nodes during the simulation is shown within a simulation window,
which allows the visualization of the simulation area that is either a two-dimensional
or a three-dimensional rectangle. The framework also allows the programmer to refer
to a simulation scenario containing obstacles by means of images representing maps:
however, it is left to the mobility model to decide how these obstacles interfere with
the movement of the nodes. In other words, there is nothing analogous to the physical engine manager of MOMOSE (which computes the collisions between the nodes and
the obstacles which are present into the scenario) and, instead, this management is
delegated to the specific mobility model. Moreover, the parameters determining the
characteristics of a mobility model are specified within a XML file and no configuration window is available to the final user. Finally, Sinalgo does not allow the user to use
multiple data recorders during one simulation, unless new code is written implementing
all the desired recorders.
We conclude this section by presenting some experimental results concerning the
performances of MOMOSE (with the C++ engine), CanuMoboSim, and Sinalgo: these results are, in our opinion, particularly valuable whenever massive simulation data have
to be collected. In particular, we have realized the following three experiments.
1. For a number of nodes ranging between 100 and 5000 (in the case of MOMOSE versus
Sinalgo) and between 10 and 40 (in the case of MOMOSE versus CanuMoboSim),
we let all the nodes move according to the random waypoint mobility model for
7200 seconds: the positions of the nodes have been recorded into a file according
to the ns-2 syntax. The results of this first experiment are shown in Figure 6
14
(the values represent the average over 10 experiment executions):6 it is evident
that both MOMOSE and Sinalgo outperform CanuMoboSim by at least one order of
magnitude (observe that we were not able to deal with a much larger number of
nodes with CanuMoboSim). On the other hand, MOMOSE and Sinalgo seem to have
similar performances as it can be seen in the upper plot of the right part of the
figure: indeed, the ratio between the performances of MOMOSE and of Sinalgo tends
to be a value lower than 1.1 (by computing the linear regression for both value
series, it turns out that this ratio is equal to 1.05).
2. For a simulation time ranging between 600 and 3600 seconds, we let 200 nodes
move according to the random waypoint mobility model: the results of this second
experiment are shown in Figure 7 (once again, the values represent the average
over 10 experiment executions). Even in this case, both MOMOSE and Sinalgo clearly
outperform CanuMoboSim: moreover, it seems that for short simulation periods
(that is, shorter than 40 minutes), MOMOSE performs better than Sinalgo.
3. For a number of nodes ranging between 100 and 200, we let all nodes move according to the random waypoint mobility model and we used MOMOSE and Sinalgo
to visualize the entire simulation. In this third experiment, MOMOSE clearly outperforms Sinalgo: indeed, during the same execution time MOMOSE is able to visualize
a simulation time which is at least two orders of magnitude greater than the one
visualized by Sinalgo. Hence, MOMOSE is able to visualize the simulation at a refresh
rate much lower than real-time even in the case of a large number of nodes. We
believe that this result is mainly due to the fact that MOMOSE uses the OpenGL
libraries in order to implement the visualization.
5 Three Case Studies
In the first case study we have replicated the experiments described in [5] concerning
a localization algorithm based on the estimate of the received signal power: the localization problem is one of the most important research topic within the field of sensor
networks, and it is strictly related to routing protocols and energy consumption. In
order to replicate these experiments, we used the random waypoint model (which was
already included in MOMOSE) and we designed a new parametric data recorder, which
computes, during the simulation, the real position of a sensor, the position computed by
the algorithm proposed in [5], and the error between these two values. Our experimental results strongly agree with the ones presented in [5], thus validating the correctness
of our simulation tool and proving the easiness of using it in order to design and realize
a new set of experiments.
The goal of the second case study has been to evaluate the connectivity performance of part of the Blue pleiades protocol proposed in [15] in order to more efficiently
perform the device discovery phase of the Bluetooth standard [24]. In particular, during this phase each Bluetooth device attempts at discovering other devices contained
within its visibility range and at establishing reliable communication channels with
them: however, since requiring each device to discover all of its neighbors is too time
consuming [4], the Blue pleiades protocol forces each device to stop the device discovery phase as soon as a constant number of neighbors has been detected (typically,
6 As one might expect, the variance of all the experiments turns out to be very low and it
is not shown.
15
Fig. 8 The Florence’s historic centre scenario used while evaluating the Blue pleiades protocol
7). We have then implemented this protocol and we have evaluated its connectivity
performance when used for a MANET formed by thousands of devices moving around
the historic centre of Florence, Italy (see Figure 8). According to our experiments, if
the number of selected neighbors is at least 5, the number of connected components
produced by the Blue pleiades protocol does not increase too much with respect to the
case in which all the neighbors are selected.
The third and last case study has concerned the development of a new mobility
model. Considering that different nodes may move according to different mobility models and that the mobility behavior of a node may vary during time because of changes
of its environment, we let the nodes of a network move according to mobility models
that are determined by the roles played by the nodes themselves: these roles, in turn,
can be determined by computing colorings of the graph induced by the communication
network [10]. Observe that prior applications of social network analysis to the development of MANET mobility models assume that the structure of the social network is
known a priori and that this structure does not change over time [28, 29]: in the role
assignment based approach, instead, the social network structure is determined by the
topology of the MANET, which in turn changes over time due to the movement of
the nodes. Our experiments show that the combination of a role assignment algorithm
(called ecological [8])7 with a simple mobility model (that is, the random waypoint
model) produce movement patterns with significantly higher mobility “values” with
respect to some mobility metric [39] than the original mobility model itself. For example, let us consider the Topology Change Rate (in short, TCR) measure [30], according
to which the number of link changes during a simulation is taken into account: a mo7 Informally, an ecological role assignment of a graph is a coloring of the nodes of the graph
such that the colors present in a particular node’s neighborhood determine the color of that
node.
16
r = 15%
14
r = 20%
Ecological Random Waypoint
Random Waypoint
12
8
TCR
TCR
10
6
4
2
0
25
50
75
100 125 150 175 200 225 250 275 300
Number of nodes
18
16
14
12
10
8
6
4
2
0
25
Ecological Random Waypoint
Random Waypoint
50
75
100 125 150 175 200 225 250 275 300
Number of nodes
Fig. 9 Experimental results on the topology change rate of two different mobility models
bility model is considered as more mobile as such a number is larger. Moreover, let us
assume that different nodes may move according to different instances of the random
waypoint mobility model and the instance associated to each node may vary during
time, where an instance of the mobility model consists only of the region within which
the target point is chosen (in other words, we assume that all nodes have the same
speed characteristics). In this case, the experiments show that, for several values r of
the communication range, there exists a threshold value nr such that the pure random
waypoint model model is “more mobile” when the number of nodes is at most equal
to nr , while its combination with the ecological role assignment is “more mobile” in
the other case. Figure 9 summarizes these results in the case in which the communication range is equal to 15% and 25% of the side of a square simulation area (in
the experiments, the role assignment algorithm use four roles and a quadrant of the
simulation area is associated to each role). Note that these experiments allowed us
to confirm the easiness of designing and developing new mobility models within the
MOMOSE framework.
6 Conclusion and further research
In this paper we have described MOMOSE, a new environment for the development and
simulation of mobility models for mobile wireless ad-hoc networks, whose main characteristics are flexibility and extensibility. MOMOSE has already been applied in three
interesting and non trivial case studies, thus showing how it can be used while analyzing different aspects of MANETs. These case studies seem to confirm the flexibility
and extensibility of MOMOSE: for this reason, we believe that our framework can become
a very useful tool for evaluating the effects of mobility on the performance of a protocol
for MANETs and we hope that a wide use of the tool itself will allow us to further
improve it.
The current distribution of MOMOSE [46] includes an implementation of the random
walk model, of the random waypoint model, of the nomadic community model, of the
pursue model, and of all the models necessary to analyze the two last case studies
described in the previous section: a first natural further step will be to integrate the
distribution with the implementation of all the mobility models referred to the introduction. The distribution also includes a debug data-recorder, a ns-2 data-recorder,
a real-time visualizer data-recorder, a player data-recorder, and all the data recorders
necessary to analyze the case studies described in the previous section: a second fur-
17
ther step will be to develop a GloMoSim data-recorder and a data-recorder that can be
used for simulations implemented within the Sinalgo framework. Moreover, we intend
to improve the SVG parser (which is currently limited to a subset of possible figures)
and to develop one or more parsers which would allow the user to import geographic
data files (such as the GDF files). Finally, as a result of the performance comparison
between MOMOSE and Sinalgo, it seems that there is space for some improvement of our
framework in terms of simulation execution time.
References
1. M. Abdelhafez, G. F. Riley, R. G. Cole, and N. Phamdo. Modeling and Simulations of
TCP MANET Worms, Proc. 21st International Workshop on Principles of Advanced and
Distributed Simulation, 123–130, 2007.
2. R. Bagrodia, R. Meyer, M. Takai, Y. Chen, X. Zeng, J. Martin, and H. Y. Song. PARSEC: A Parallel Simulation Environment for Complex Systems, IEEE Computer, 77–85,
October 1998.
3. F. Bai, N. Sadagopan, and A. Helmy. User Manual for IMPORTANT Mobility Tool Generators in ns-2 Simulator, University of Southern California, February 2004.
4. S. Basagni, R. Bruno, G. Mambrini, and C. Petrioli. Comparative performance evaluation
of scatternet formation protocols for networks of Bluetooth devices, Wireless Networks,
10, 197–213, 2004.
5. P. Bergamo and G. Mazzini. Localization in sensor networks with fading and mobility,
Proc. 13th IEEE International Symposium on Personal, Indoor and Mobile Radio Communications, 750–754, 2002.
6. C. Bettstetter. Mobility modeling in wireless networks: Categorization, smooth movement,
border effects, ACM Mobile Computing and Communication Review, 3, 55–67, 2001.
7. C. Bettstetter. Smooth is Better than Sharp: A Random Mobility Model for Simulation of
Wireless Networks, Proc. ACM Intern. Workshop on Modeling, Analysis, and Simulation
of Wireless and Mobile Systems, 19–27, 2001.
8. S. P. Borgatti and M. G. Everett. Ecological and perfect colorings, Social Networks, 16,
43–55, 1994.
9. S. Boschi, P. Crescenzi, M. Di lanni, G. Rossi, and P. Vocca. MOMOSE: a mobility model
simulation environment for mobile wireless ad-hoc networks, Proc. 1st International Conference on Simulation Tools and Techniques for Communications, Networks and Systems,
2008.
10. U. Brandes and T. Erlebach, Eds. Network Analysis: Methodological Foundations, Lecture
Notes in Computer Science, Vol. 3418, 2005.
11. T. Camp, J. Boleng, and V. Davies. A Survey of Mobility Models for Ad Hoc Network
Research, Wireless Communication and Mobile Computing, 2, 483–502, 2002.
12. J. Capka and R. R. Boutaba. A mobility management tool-the realistic mobility model,
Proc. IEEE International Conference on Wireless and Mobile Computing, Networking and
Communications, 242–246, 2005.
13. C.-H. Chen, H.-T. Wu, and K.-W. Ke. Flexible mobility models towards uniform nodal
spatial distribution and adjustable average speed, Proc. IEEE Vehicular Technology Conference, 2292–2296, 2005.
14. C.-H. Chen, H.-T. Wu, and K.-W. Ke. General Ripple Mobility Model: A Novel Mobility
Model of Uniform Spatial Distribution and Diverse Average Speed, IEICE Transactions
on Communications, E91-B, 2224–2233, 2008.
15. D. Dubhashi, O. Häggström, G. Mambrini, A. Panconesi, and C. Petrioli. Blue pleiades,
a new solution for device discovery and scatternet formation in multi-hop Bluetooth networks, Wireless Networks, 13, 107–125, 2007.
16. K. Fall and K. Varadhan. The ns Manual, University of California at Berkeley, 2007.
17. W. Feller. An Introduction to Probability Theory and its Applications, Volume 1, Wiley,
1968.
18. H. Fuchs, Z.M Kedem and B.F. Naylor. On Visible Surface Generation by A Priori Tree
Structures, Proc. 7th annual conference on Computer graphics and interactive techniques,
124–133, 1980.
18
19. X. Hong, M. Gerla, G. Pei, and C. Chiang. A group mobility model for ad hoc wireless
networks, Proc. ACM Intern. Workshop on Modeling, Analysis, and Simulation of Wireless
and Mobile Systems, 53–60, 1999.
20. B. D. Hughes. Random walks and random environments, Oxford University Press, 1995.
21. E. Hyytiä, H. Koskinen, P. Lassila, A. Penttinen, J. Roszik, and J. Virtamo. Random
Waypoint Model in Wireless Networks, Networks and Algorithms: complexity in Physics
and Computer Science, Helsinki, June 2005.
22. International Organisation for Standardization. Intelligent transport systems - Geographic
Data Files (GDF) - Overall data specification, ISO 14825:2004, 2004.
23. A. Jardosh, E. M. Belding-Royer, K. C. Almeroth, and S. Suri. Real world environment
models for mobile ad hoc networks, IEEE Journal on Selected Areas in Communications,
23, 2005.
24. P. Johansson, M. Kazantzidis, R. Kapoor, M. Gerla. Bluetooth: an enabler of personal
area networking, IEEE Network, 15, 28–37, 2001.
25. D. B. Johnson and D. A. Maltz. Dynamic source routing in ad hoc wireless networks, in
Mobile Computing, Kluwer Academic Publishers, 1996.
26. S. Lim, C. Yu, and C. R. Das. Clustered mobility model for scale-free wireless networks,
Proc. IEEE Conference on Local Computer Networks, 231–238, 2006.
27. G. Lin, G. Noubir, and R. Rajaraman. Mobility Models for Ad Hoc Network Simulation,
Proc. of IEEE Information Communications Conference, 454–463, 2004.
28. M. Musolesi, S. Hailes, and C. Mascolo. An ad hoc mobility model founded on social
network theory, Proc. 7th ACM international symposium on Modeling, analysis and simulation of wireless and mobile systems, 20–24, 2004.
29. M. Musolesi and C. Mascolo. Designing Mobility Models based on Social Network Theory,
ACM SIGMOBILE Mobile Computing and Communications Review, 11, 59–70, 2007.
30. X. Pérez-Costa, C. Bettstetter, and H. Hartenstein. Toward a mobility metric for comparable & reproducible results in ad hoc networks research, SIGMOBILE Mobile Computing
and Communications Review, 7, 58–60, 2003.
31. S. Pólya. Über eine Aufgabe der Wahrscheinlichkeitstheorie betreffend die Irrfahrt im
Strassennetz, Mathematische Annalen, 84, 149–160, 1921.
32. P. Révész. Random walk in random and non-random environments, World Scientific, 1990.
33. E. Royer, P. Melliar-Smith, and L. Moser. An analysis of the optimum node density for ad
hoc mobile networks, Proc. IEEE International Conference on Communications, 857–861,
2001.
34. M. Sanchez and P. Manzoni. A java-based ad hoc networks simulator, SCS Western Multiconference Web-based Simulation Track, San Francisco, January 1999.
35. D. Shukla. Mobility models in ad-hoc networks, KReSIT-IIT Bombay, November 2001.
36. I. Stepanov, J. Hahner, C. Becker, J. Tian, and K. Rothermel. A meta-model and framework for user mobility in mobile networks, Proc. 11th IEEE International Conference on
Networks, 231–238, 2003.
37. J. Tian, J. Hahner, C. Becker, I. Stepanov, and K. Rothermel. Graph-based Mobility Model
for Mobile Ad Hoc Network Simulation, Proc. of 35th Annual Simulation Symposium, 337,
2002.
38. M. Woo, J. Neider, and T. Davis, OpenGL Programming Guide: The official guide to
learning OpenGL, Addison Wesley, 2003.
39. S. Xu, K. L. Blackmore, and H. M. Jones. An analysis framework for mobility metrics in
mobile ad hoc networks, EURASIP Journal on Wireless Communications and Networking,
2007.
40. J. Yoon, M. Liu, and B. Noble. Random Waypoint Considered Harmful, Proc. 22nd Annual
Joint Conference of the IEEE Computer and Communications Societies, 1312–1321, 2003.
41. B. Zhou, K. Xu, and M. Gerla. Group and swarm mobility models for ad hoc network
scenarios using virtual tracks, Proc. Military Communications Conference, 289–294, 2004.
42. Global
Mobile
Information
Systems
Simulation
Library,
http://pcl.cs.ucla.edu/projects/glomosim/.
43. Georgia Tech Network Simulator, http://www.ece.gatech.edu/research/labs/MANIACS/GTNetS/.
44. MobiGen, http://www.soe.ucsc.edu/~mmosko/mobigen/.
45. Mobility framework for OMNeT++, http://mobility-fw.sourceforge.net/.
46. Momose, http://sourceforge.net/projects/momose/.
47. The Rice University Monarch Project, http://www.monarch.cs.rice.edu/.
48. The network simulator ns-2, http://www.isi.edu/nsnam/ns/.
49. OMNeT++, http://www.omnetpp.org/index.php.
50. Sinalgo - Simulator for Network Algorithms, http://dcg.ethz.ch/projects/sinalgo/.