Computer Science Technical Report Archive

USC Computer Science Technical Reports, no. 836 (2004)

(USC DC Other)

USC Computer Science Technical Reports, no. 836 (2004)

PDF

Download a page range

Download transcript

Copy asset link

Request this asset

Transcript (if available)

Content 1
Integrating Environment Simulators with Network
Simulators
Avinash Sridharan, Marco Zuniga and Bhaskar Krishnamachari
Department of Electrical Engineering - Systems
University of Southern California, Los Angeles, CA 90089-0781
fasridhar, marcozun, bkrishnag@usc.edu
Abstract We present a challenge that is unique to sensor
network simulations, that of integrating environment and net-
work simulators. The content and the characteristics of the
data being sensed play a vital role in the performance of
various algorithms and protocols that have been proposed by
the research community. This point has been emphasized in
numerous literatures that have been published in the context
of wireless sensor networks research. Yet the range of simulators
that have been targeted towards this new eld of research
concentrate primarily in simulating the network characteristics,
such as the wireless channel the nodes themselves and various
topological scenarios for the node, although some simulators
such as TOSSIM [9] and EmStar [14] do provide simulation
of interfaces on the nodes to feed data into the network . The
simulation of the behavior of the network in the presence of
the data that is being sensed has not received considerable
attention. In order to breach this gap we need to integrate
network and environment simulators. The purpose of this work
is to rst present a survey of the existing network simulators
and environmental simulators, to highlight the deciency in the
current research based on simulations. Further we present a case
study on integrating a specic network simulator (TOSSIM [9])
with a structural simulator (MATLAB structural control tool
box), to present the general challenges that might exist when
such integrations are performed.
I. INTRODUCTION
Sensor nets have revolutionized sensing technologies around
the world. The nature of sensor networks which allows the
deployment of a large number of miniaturized sensing devices
across a given environment, gives researchers unprecedented
granularity and volume in terms of the data that they could
collect. This could help researchers study environments they
have been involved with at a much more detailed level than
they have been able to until now.
The size of the sensing devices, that is so critical to achieve
the advantage described above, also imposes a huge constraint
on the ability of these devices. Building applications for these
devices is thus a challenging task. The severe constraints
imposed by the lack of resources in these devices have led
to cross-layer optimization and closely tying many network
conguration and operation tasks with the content of the
data. For this reason, the performance of sensor networking
protocols cannot be evaluated without taking into account the
saptio-temporal characteristics of the environmental data and
sensor measurements.
Research in the area of sensor networks has given cre-
dence to the above argument that the content of the data
plays an important role in optimizing the performance of
the network protocols in sensor nets. Directed Diffusion [1]
uses attribute based naming for querying data in order to
build gradients from sink to the source. Based on feedback
for the named data specic gradients are reinforced, giving
multiple paths from the source to the sink and incurring
considerable energy savings compared to IP style address
based communication. [2] builds an analytical model for data
centric routing in sensor networks and compares it with end to
end address centric routing schemes. [3] uses classical source
coding techniques on multihop WSN and achieves optimum
compression using the spatial and temporal correlation in the
data being sensed. [4] proposes a simple clustering scheme that
can achieve near optimal routing with compression over a wide
range of spatial correlations. [5] views calibration in sensor
nets as a macro calibration problem, where the objective is
to calibrate the overall system response rather than individual
devices within the system. Macro calibration is achieved by pa-
rameterizing each device and ne tuning the parameters using
data collected from the network. [8] uses spatial correlation
in the sensed data to formulate Bayesian algorithms that detect
measurement faults which are inherently uncorrelated during
event detection in sensor networks. TAG [7] proposes a frame
work for performing in network data aggregation in order to
support aggregate data queries. ACQUIRE [6] uses temporal
correlation in the data to optimize single shot queries in WSN.
Sensor networks has thus introduced a complete paradigm
shift in networks from inter-personal communication to com-
munication with the environment. In traditional networks a
strict layering separates the content of the data from network-
ing related concerns. Therefore network protocols could be
evaluated purely on the basis of protocol characteristics and
some network parameters such as topology, trafc rates (but
not the trafc content).With the coming of sensor networks this
design philosophy has undergone a complete change, with the
trafc content playing an integral role in deciding the design
and affecting the performance of a network.
Figure 1 depicts the disparity between real world systems
implementation and simulations. For wireless sensor networks,
the non-idealities of the channel play an important role in
dening the performance and the interaction of the applica-
tion/network layers with the sensed data. To elaborate, the
packet loses that might occur due to the non-idealities of the
channel might affect the characteristics of the data as perceived
by the application/network layer, which in turn might affect
2
(a) Various components involved in a
real life sensor network system and their
interaction with each other.
(b) The components that are simulated during research.
Fig. 1. A comparison of the real life deployments and simulations that are done in research, to highlight the missing component that might affect the end
results.
its behavior and overall performance. However as depicted
by Figure 1(b) during simulations the non-idealities of the
channels is completely neglected and only the interactions of
the application/network with the sensed data are simulated.
Since the non-idealities play a role in altering the view that the
network/application perceives of the underlying environment
there might be a large difference in terms of performance
results from simulation results and actual systems.
In order to make simulations in sensor networks true bench-
marks for the behavior and performance of the data sensitive
protocols we believe it is imperative to incorporate interac-
tion of the layers of the network (application,network,data
link,physical) along with the data. This implies an integration
of Environmental simulators/Data sets with existing network
simulators.
The task of integrating environment and network simulators
is however not trivial. There are numerous challenges that
exist, to list a few:
The spectrum of applications that sensor networks can
spawn is unlimited, thus the environments that need to be
simulated are also numerous. Should a network simulator
be simply enhanced with several models, or should there
be code written for each pair of network simulator and
environment simulator, or is it feasible to aim towards a
very general interface between any pair?
A generic implementation taking care of integration to
a wide variety of ES (Environment Simulators) leads to
the question of modularity of code. Should the network
simulators simulate the sensing devices themselves or
should they provide API's as hooks for various ES'es
to be hooked up into the Network Simulator(NS)?
For ES that are simply data sets, is there a possibility
of dening a common format that all network simulators
understand?
What is the granularity at which we should simulate
the environment? This would in turn correspond to the
number of nodes that can be simulated by the network
simulator. The argument here is that the granularity of the
environment simulation would be directly proportional
to number of events that need to be simulated by the
network simulator, which in turn will affect the speed of
the simulation.
Sensing is a unidirectional activity where the ES (Envi-
ronment Simulators) can feed inputs into the NS (Net-
work Simulators). But how do we simulate sensing and
actuation, since now the activity is bidirectional ? This
leads to the problem of synchronization between ES and
NS.
At times the ES might simply be a data set (when the
activity only involves sensing), in such situations what
happens when data points are not available at the exact
times when the NS wants to simulate sensing? This might
incorporate extrapolation of data points from the existing
data sets.
The objective of this paper is to elaborate on the above
points in order to give the reader a complete picture about the
challenges and propose possible solutions to these problems.
The rest of the paper is arranged as follows: Section II gives
a description as to the different network simulators and the
environment simulators/datasets that are existing. Section III
presents a case study on integrating MATLAB structural
simulator and TOSSIM a sensor network simulator to give an
intuition to possible solutions to some the challenges posed in
this paper.
II. A SURVEY OF NETWORK AND ENVIRONMENT
SIMULATORS
A. Network Simulators
The two components of any network simulator are the nodes
that form the network and the links that transfer data between
these nodes. The simulation of the nodes or the links can be
either event driven or time driven.
In event driven simulation, the life time of network activity
is discretized into events. The simulation than involves gener-
3
ating a series of events that the network would have stepped
through when a specic input is given to the network. Time in
event driven simulators is not absolute but a virtual quantity
maintained as a variable within the simulator. Event generation
is done by taking a previously queued event and feeding it to
one of the two components, the node or the link. The logic
implemented in either of these two components generates a
new event. The scheduling(mapping of the event to a virtual
time) of the new event depends on the distribution of the
service time of the entity to which this event was fed. Since
time is a virtual quantity in event driven simulations, it is very
fast. However the accuracy of the simulation largely depends
on the assumption of the distribution of the service times.
In time driven simulations the time is absolute. Each node
in the network is a separate process. Since each node is a
separate process the total time to run a simulation is the actual
network life time. Time driven simulations can be thought of
as emulations of the actual network.
Table I gives a listing of the existing network simulators
that have been used for research in sensor networks. ns-2 [11],
Glomosim [19] and Opnet [12] are the internet era simulators
that were designed specically to simulate the layered network
stacks that are the basis for traditional network design. Cross
layer optimization can be implemented in such simulators by
adding interfaces to the various layers of the network stack.
ns-2 originally did not support wireless networks but there are
extensions available that are able to add wireless capability.
Glomosim was specically designed to support wireless net-
works and hence has very good propagation models. Opnet is
an industrial standard commercial simulator comparable to ns-
2. It is known for its robustness and ability to perform very fast
large scale simulations. Opnet comes with a wireless module
that simulates RF propagation, interference and transmitter
receiver characteristics. However, due to their bias towards
the traditional network design principles they do not support
sensor networks directly but can be modied to do so.
UCLA's SensorSim extends ns-2 by adding modules for
modeling sensing activity, battery models (to model power
consumption in sensor nodes), a light weight protocol stack
specically for sensor networks and a module for the sim-
ulation to interact with actual sensors, forming a hybrid
simulation.
Emstar [14] and TOSSIM [9] were the rst simulators
purely targeted towards sensor networks and thus have gained
wide recognition and acceptance. TOSSIM [9] was designed to
simulate the execution of nesC code on the berkley motes run-
ning the TinyOS platform. Its ability to simulate networking at
the bit level has attracted attention of quiet a few researchers.
Although the bit level simulation makes it very slow and not
suited for large scale simulations (> 100 nodes). TOSSIM also
simulates the sensing channels on the motes and provides a
mechanism to feed data into the motes from external sources.
Figure 2 gives a block schematic of the TOSSIM architecture.
TOSSIM provides a good empirical radio propagation
model. It provides a tool called the lossy builder that can
generate link probabilities for a given set of node coordinates.
It uses Woo.et.al's [10] data to designate an error probability
to a particular link based on the length of the link. TOSSIM
Fig. 2. The architure of TOSSIM. The block diagram represents the various
components of TinyOS and the network simulated by TOSSIM.
Fig. 3. This block diagram shows the various components involved during
the simulator phase of EmStar. EmSim is the main process that controls all
the emrun processes which in turn control all the application processes on a
per node basis.
comes with a visualization tool called TinyViz. TinyViz and
TOSSIM share a common event bus, this helps TinyViz to
listen to all the events that are generated during a TOSSIM
simulation. This provides TinyViz the ability to perform real
time visualization of the simulation. The event bus shared
between TinyViz and TOSSIM is a bidirectional event bus.
This gives TinyViz not only the ability to listen to TOSSIM
events, but also the ability to control the execution of TOSSIM,
by starting and stopping TOSSIM based on application level
requirements.
EmStar [14] is a software framework for linux based sys-
tems. It provides different levels of simulation environments
4
Simulators Availability Scalability Programming Language Sensor Modules Wireless Models Event/Time
NS2
p p
C++ X
p
Event
GLOMOSIM
p p
C++ X
p
Event
OPNET X
p
C++ X
p
Event
SensorSim
p p
C++
p p
Event
TOSSIM
p
X nesC
p p
Event
EmStar
p p
nesC/C++
p p
Event/Time
SENS
p p
C++
p p
Event
MANTIS
p
X C
p
X Time
SIESTA
p p
JA V A
p
X Time
Prowler
p p
MATLAB X
p
Event
JProwler
p p
JA V A X
p
Event
TABLE I
A LISTING OF ALL THE KNOWN NETWORK SIMULATORS THAT HAVE CAPABILITIES FOR SIMULATING APPLICATIONS IN SENSOR NETWORKS.
starting from a pure simulation environment on a single PC
to a real life deployment scenario where the EmStar stack
is deployed and run on IPaq class devices. At the core of
the EmStar stack is a process manager called EmRun. All
processes in a single instance of an EmStar stack are controlled
by the EmRun process. Figure 3 gives a block schematic of
the deployment of the EmStar stack on a sensing device for a
beam forming application.
The different modes of simulation/emulation provided by
EmStar embody a trade off between the scale of deployment
and the reality of the simulation. There are four modes of op-
eration that are possible. Pure simualtion is the most scalable.
The execution environment is called emsim. In emsim every
node is simulated by a separate process, running the same
EmStar stack. The processes communicate with each other, as
real nodes would through an entity called the environment,
which tries to capture the channel characteristics of a live
deployment. In Ceiling array mode of simulation, the nodes
are still represented by seperate processes, the difference is
that they do not talk to each other through the environment,
rather they communicate using actual mote transmitters and
receivers. This mode of execution is called emcee. In this
mode, a ceiling array of motes is hooked up via serial port
to emcee which acts as the serial array controller. As is
evident emcee is very similar to emsim, except for the channel,
which instead of being simulated has been provided as a
real physical channel. Real deployment of EmStar involves
the deployment of EmStar stack on IPaq class devices. This
would be done at the nal stage of application development.
EmStar also proposes a fourth mode of operation that has
not yet been developed, called Data Replay. This mode of
operation embodies some of the fundamental ideas that we
are proposing here, although it lacks coverage of all scenarios.
In the data replay mode, actual sensor data such as a time
series of seismic readings, can be fed into emsim or emcee
depending on the conguration of operation of EmStar. This
mode represents one of the basic mechanisms of interfacing
the sensed environment with the network simulator.
SENS [15] is a relatively new simulator from
UIUC(University of Illinois Urbana-Champaign). It models
the sensor as three different components, application (the
internals of a sensor node),network (the communication
stack) and physical(the sensing modalities, sensors and
actuators). Apart from the node the simulator also models
the wireless environment in which the sensor is supposed to
work. The wireless environment provides propagation models
for different terrains to make the simulation dependent on the
propagation affects of the environment in which the nodes
are to be deployed.
MANTIS [16] is an operating system built to run on
the Nymph nodes (developed by the University of Colorado
Bolder) as well the MICA2 motes from CrossBow. The MAN-
TIS system comes with an emulator, where each MANTIS
node is emulated as a separate process. Each of the emulated
nodes can communicate with themselves as well as with actual
sensor nodes. The emulation environment is mainly provided
as a development tool, but could be thought of as a time driven
simulator.
Prowler [17] is a simulation tool provided by ISIS that runs
under MATLAB. Its main feature is its ability to simulate
transmission/propagation/reception including collision in sen-
sor networks. Application can be integrated with propagation
models to provide different sensor net scenarios. JProwler is
the JA V A version of Prowler.
SIESTA [18] is a sensor network simulator from Vanderbilt
University. Its targeted towards testing and simulating mid-
dleware platforms in sensor networks. It has four different
components, application, middleware, hardware( the actual
sensor nodes and the communication between the sensor node)
and the physical environment that the sensor nodes are sensing.
The physical environment is more of an interface through
which data could be fed into the simulator rather than a
simulation of the sensed environment itself.
B. Environment Simulators
Environment simulators can be divided into the following
four categories.
1) Raw Data Sets:: This mainly consist of actual envi-
ronment measurements. There are numerous data sets that
are available on the internet. [20] gives data sets for me-
teorological data for the great lakes. The time granularity
of this data set is 5 minutes. [21] provides real data for
monitoring water quality in periods of 5 minutes to 1 hour. [22]
provides spatial rainfall precipitation data with a granularity
of 50 km. However the data sets are a very coarse collection
5
for usage with sensor networks. Reason being that a single
data set represents the sensed activity for a very large area.
This is contrary to the kind of sensing activity for which
sensor networks would be designed. For sensor networks a
large number of sensors would be sensing data within a
specied region. Thus to simulate the behavior of a particular
sensor network we would require data sets that show spatial
correlation and are representative of the complete region over
which the sensing activity is planned instead of a few specic
points. The knowledge of the availability of such data sets is
still important since these data sets could be used to produce
computer generated datasets using interpolation techniques
such as the Kriging technique.
Sensor networks research has matured over the past few
years and hence there have been some real deployments
of sensor networks. An example of such a data set is the
Great Duck island habitat monitoring experiment [23]: This
experiment performed by Intel Research Lab in collaboration
with UC Berkley and the College of Atlantic in Bar Harbor
involves a live sensor network deployment to monitor micro
climate environments around the nesting burrows.
2) Computer Generated Data Sets:: These are data sets
that are formulated by doing interpolation techniques (such
as the Kriging technique) on a raw set of data or have been
formulated using mathematical modelling to generate data sets
with statistical properties.
One example of synthetically generated data sets is [24],
which provides a technique to generate synthetic data for
arbitrary correlation patterns. Here the authors provide a model
to generate spatially correlated data for a grid deployment of
source nodes. In this model the data value at a point (x,y) can
be represented by a stationary random process X(x; y) having
a pdf f
x
(x). The value of data at point (x,y) is than given by:
X(x; y) =
8
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
<
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
:
X
1
1
+ Z with probability
1
N(1)
.
.
.
X
N(1)
1
+ Z with probability
1
N(1)
X
1
2
+ Z with probability
2
N(2)
.
.
.
X
N(2)
2
+ Z with probability
2
N(2)
.
.
.
X
1
h
+ Z with probability

h
N(h)
.
.
.
X
N(h)
h
+ Z with probability

h
N(h)
Y with probability
X
k
d
denotes the kth node that is d hops away from (x,y)
such that 1 k N(d). Z and Y are independent random
variables that are independent of X as well. Z captures the
small variations that occur between the spatially correlated
nodes. The characteristic function of Y and X are related as
follows:

X
(jw) =

1 (1 )e
[

2
z
!
2
2
]

Y
(j!)
The inputs to this model are the variance of the random
variable Z,
2
z
, the distribution of the random variable X,
f
X
(x) , the maximum number of hops h and the probability
of the random variable Y affecting the value of X(x; y), .
Another example is the Kriging Technique [25]. It is a
well known technique for interpolation of existing data sets
to generate a spatially correlated synthetic data set. It uses
a weighted linear combination of existing points in a data
set to generate the missing data set, with the objective of
minimizing the estimation error. The weights used are obtained
from a variogram function that represents the spatial variation
in the data set. More formally it consists of calculating Z

0
,
the estimate of the actual value Z
0
of the data at the point of
interest where
Z

0
=
X
i

i
Z
i
where Z
i
are the set of known values, based on the constraints
E[(Z

0
Z
0
)
2
] is a minimum
and
X
i

i
= 1
An example for the utility of the Kriging technique is
[26]. [26] uses the Kriging technique to generate rainfall
precipitation data for the Australian continent based on a raw
data set from 4000 collection points across the continent.
Such techniques for developing synthetic data sets that are
known to have a specic statistical property are very useful
when the granularity of raw data sets might not be enough to
simulate the sensing activity in a limited region that is typical
of sensor networks.
3) Closed form mathematical models:: There might be
environments that could be modeled accurately using closed
form expressions. For e.g conduction of heat in 1-D space can
be represented by the following PDE model:
@T
@t
= k
@
2
T
@x
2
A more generic model for diffusion in 1-D used in [29] can
be represented using partial differential equations as follows:
@x(t; )
@t
=
1
@
2
x(t; )
@
2
+
2
@x(t; )
@
+ x(t; )
Where represents the 1-D space in which the phenomena
is propagating.
Another example for closed form expressions for modeling
physical phenomenon is Lamberts law [28] for modeling the
variation in light intensity with distance:
I = I
0
e
Ks
Where I is the light intensity and K is the extinction
coefcient.
6
Fig. 4. An illustration of the application of sensor networks in Structural
Health Monitoring Applications
4) Approximate models:: Some physical phenomenon such
as vibration in structures or transient electromagnetic elds
have PDE models, but it is very difcult to obtain analytical
expressions to these models. Therefore computational tech-
niques are used to solve these models to get approximations to
the solutions. An example of such an approximation technique
is the nite element model [30]. In this method the domain
under observation is divided into a nite number of cells. The
PDE is than solved for each of these cells leading to a linear
system of equations. The solution of these equations is than
an approximation to the original PDE. [31] and [32] use the
nite element model to simulate vibrations within a structure.
III. CASE STUDY: INTEGRATING THE MATLAB CONTROL
TOOL BOX AND TOSSIM
In this section we look at integrating a specic environment
simulator, namely a structural simulator with a network sim-
ulator. The utility of this integration lies in the application of
sensor networks to the eld of Structural Health Monitoring.
The objective of Structural Health Monitoring is to assess the
health of a structure by observing the response (vibrations) of
the structure to external forces. Before the advent of sensor
networks civil engineers suffered from a lack of data due
to restrictive nature of the sensors that could be deployed,
in terms of the size as well as the connectivity. Due to the
small size and the wireless connectivity provided by devices
forming the sensor network this constraint no longer exists.
Engineers can think about deploying hundreds of nodes across
a structure, increasing the granularity of the response data
that could be collected thereby increasing the accuracy in the
prediction. Figure 4 depicts the application of sensor network
in the eld of structural health monitoring.
Although the advantages of combining sensor networks
and Structural Health Monitoring are clearly evident, the
environment under which the devices need to be deployed
(namely a structure) and the nature of distributed algorithms
that are so characteristic of sensor networks makes the job of
a developer all the more difcult. Thus it becomes imperative
to provide developers with a simulation environment to test
their algorithms before deploying it on an actual test bed.
Before we head into the description for the implementation
of the integration of these two simulators we would like to rst
present a description of the two components, the structural
simulator and the network simulator in terms of the feature
set provided by these entities that would aid us to perform
the integration. We would than present the challenges related
to this specic case study and our solution to the problems
posed.
The target structural simulator is the control tool box pro-
vided by MATLAB for structural simulations. The control tool
box uses a nite element model to simulate vibrations within
a structure. The network simulator chosen was TOSSIM, the
Tiny OS simulator.
A. MATLAB
The environment being simulated is a building, which is
modeled as a MIMO (multiple input, multiple output) state-
space system in MATLAB. State-space models are dened by
the following equations:
dx
dt
= Ax + Buy = Cx + Du
Where x is the state vector, u is the input and y the output.
Matrices A, B, C and D are provided by the model. Our
scenario has 240 states (x), 111 inputs (x) and 108 outputs
(y). The initial vector state x is set to x
0
, which represents
the undamaged structure. And the output vector reects the
acceleration created by a given input vector.
The matlab object SY S is used to obtain the state-space
model, and the function lsim is used as the general sim-
ulation function. lsim allows simulation in the continuous
and discrete time domains. Due to the interaction with the
network simulator, where nodes sample at a specic rate,
the discrete time option is more efcient, since it avoids
unnecessary oversampling of the structure, which translates
to shorter simulation times.
B. TOSSIM and TinyViz
The devices that are envisioned to be deployed as wireless
sensors in the Structural Health Monitoring application are
the Berkley motes which run the TinyOS operating system.
TOSSIM was chosen as the target network simulator due to its
ability to simulate the TinyOS operating system at a granular
level. There were also some features provided by TOSSIM that
we believed would help in simplifying the integration process
. We would like to describe some of these features here to give
the user a better understanding of the implementation details.
TOSSIM has the ability to simulate the ADC channels in
the motes. This helped in modularizing the code during the
integration of the structural and network simulators. Moreover
TinyViz the visualization tool of TOSSIM has the ability to
stop and start TOSSIM based on simulation requirements, an
7
important functionality required by our algorithm. TinyViz is
not just a visualization tool but a software framework to which
application specic user plugins can be added to suite specic
simulation requirements. The software framework provides
an event bus that is shared between TOSSIM and TinyViz.
Any debug message that is thrown out by TOSSIM can
be listened to on this event bus. Thus this event bus acts
as a means for generating actuations in TOSSIM that can
be heard by an external entity (in this case the structural
simulator). Apart from the event bus TOSSIM maintains a
communication channel with TOSSIM through which it can
send either commands (such as stopping and starting of the
simulation) or data (the actual values that are to be fed into
the ADC channels). Due to the features described above any
modication to the existing simulator to sufce the objective of
integrating environment and network simulator was made by
adding a new plugin to TinyViz. This ensured that the changes
made were incremental and can be merged into any version
of TOSSIM supporting TinyViz.
C. Challenges in the integration of Structural simulator and
Network Simulator
One of the challenges presented to us in this problem
was the maintainance of modularity of the code. That is an
application developer should be required to make as little
modication to his code as possible when he needs to plug
in his code into the simulator instead of the actual hardware.
As cited earlier the solution to this problem has been provided
in TOSSIM [9]. We would however like to state here that this
solution is not something very specic to TOSSIM and has
been implemented in other sensor network simulators such as
EmStar and SENS to name a few. As mentioned earlier the
reason for taking the specic example of TOSSIM is that the
sensor network devices targeted for actual deployment are the
mica 2 motes and TOSSIM implements TinyOS to very ne
granularity and has the ability to run the actual nesC code.
For modularity the solution provided is to abstract the sensing
device from the user level code. The actual implementation of
this abstraction depends on the context under which the code
is running. If the code is running on actual sensing hardware
the abstraction could be wired to the sensor drivers, however
if the code is running under simulation environments the code
could be tied to an interface that would be used to maintain
communication between different instances of the nodes, such
as sockets, shared buffers or user space devices.
A tougher problem that the integration presented was the
requirement that the integrated simulator should not only simu-
late sensing but actuation as well. The integrated simulator can
be thought of as being able to operate in two modes, a single
shot mode and a multi shot mode. In the single shot mode there
can be only sensing operations, where as in the multi shot
mode there can be sensing as well as actuation. Physically
single shot mode represents the scenario where an external
actuation say an earthquake has resulted in the generation of
vibrations in the structure of interest and the only operation
the nodes are performing is that of sensing. A multi shot
mode represents a closed loop scenario where the nodes rst
sense the response of the structure to an external actuation and
than during the lifetime of the experiment generate localized
actuation themselves to further ascertain the health of the
structure.
As would be evident the single shot mode is easy to
implement. The samples provided by the structural simulator
can be envisioned as a stream of events that are being fed
to the network simulator. The integration would than involve
inserting these events into the event queue maintained by the
network simulator. The multi shot mode is however a more
challenging problem. Since now based on the events being
fed into the network simulator a specic node might generate
an actuation, which would make all the events that have been
fed into the network simulator from the point of actuation,
void. The network simulator would than have to be stopped,
and a new input would require to be fed into the structural
simulator, the current actuation plus the original input. The
new response generated would than require to be fed into
the network simulator, after discarding all the samples of
the response till the point of actuation. We now proceed to
give a more formal presentation to the above problem and its
solution.
The structural simulator could be thought of as a system
with a response function of S. For any input to this system x(t)
we have a response y(t). Since sensors in sensor nets domain
are digital sensors x(t) and y(t) are descrete quantities. More
formally:
S(x(t)) = y(t) (1)
In the single shot mode the structural simulator could be
thought of as a system to which an impulse was given at
t = 1 that has generated a response y(t). y(t) being a
discrete quantity can be thought of as being composed of
samples Y
1
; Y
2
; : : :. To integrate such a system with network
simulator is than a simple process. Every sample Y
i
has an
associated time stamp with it. For event driven simulators than
the solution would be to simply insert these samples as events
in the event queue of the simulator. In the single shot mode
this can be done on a one time basis, at the begining of the
simulation.
The multi shot mode as mentioned earlier is however more
complex. Since the communication is bidirectional as ex-
plained earlier. The multi shot mode has very similar properties
to the single shot mode as one could assume this mode to have
a system function S that generates a response y(t) for an input
x(t). As above y(t) and x(t) are discrete functions. However
the important difference here would be that x(t) would not
be an impulse given to the system at t =1 but a series of
inputs that would compose the signal x(t).
The problem in integrating the above description of the
multi shot mode is that the input samples (x
1
; x
2
; : : :) are
not known before hand. There might be components within
the network that might actually generate some of the samples
that are part of the input. Hence the solution proposed for
integrating structural simulator in the single shot mode to
network simulators would not work.
A possible solution to the above problem could be to think
about ( 1 ) as a set of n equations.
8
S((t t
1
)) = y
1
(t)
S((t t
1
) + (t t
2
)) = y
2
(t)
S((t t
1
) + (t t
2
) + (t t
3
)) = y
3
(t)
.
.
.
S((t t
1
) + (t t
2
) + + (t t
n
)) = y
n
(t)
An external actuation or an actuation generated by the
network into the structural simulator at a time t
n
could be
thought of as an impulse (tt
n
), thus the the input function
at any time t
n
would be the summation of all the impulses till
this point. In other words
x
n
(t) = (t t
1
) + (t t
2
) + + (t t
n
)
The response of the systems at time t
n
would than be y
n
(t).
Now the fact that y
n
(t) is a discrete time function could
be used to develop an algorithm to integrate the structural
simulator in the multi shot mode with network simulators as
follows.
At any time t
i
, store all the actuations to the structure till
the point t
i
.
If an actuation occurs at time t
i
, stop the network
simulator. Use the structural simulator to nd y
i
(t) using:
S((t t
1
) + (t t
2
) + + (t t
i
)) = y
i
(t)
Discard samples Y
1
: : : Y
i1
, from the time series re-
sponse of y
i
(t)
Store the remaining samples of y
i
(t) in a FIFO queue.
Pop a sample whenever requested by the simulated sensor
in the network simulator
The above algorithm would ensure that at the end of n
actuations the simulator would be seeing the response y
n
(t).
D. Implementation
A new plugin was developed for Tinyviz to act as a me-
diator between MATLAB and TOSSIM. The communication
followed a client/server architecture between MATLAB and
Tinyviz, as shown in Figure5. The client was incorporated in
Tinyviz and the server in MATLAB.
The implementation of the single shot and the multishot
mode were the same. The single shot mode could be thought
of as a subset of the multishot mode. The multishot mode
behaves as a single shot mode when all the inputs except the
initial input to the structural simulator are zero. We therefore
describe the workings of the implementation for the multishot
mode assuming that the inference for the single shot mode is
a trivial exercise.
During initialization, MATLAB runs a TCP/IP server that
blocks waiting for an initial input vector. The plugin launches a
TCP/IP client to talk to MATLAB. Once the communication is
established, the client informs the server about the availability
of initial sequence, and enters a loop waiting for the response.
When the blocked server receives the input it terminates, MAT-
LAB than processes the information
1
, generates a response
1
the logic in the script assumes that after the server terminates inside the
MATLAB script, it processes the new input sequence
Fig. 5. Block Diagram of the client/server architecture used to implement
the integration of TOSSIM and MATLAB
0 200 400 600 800 1000 1200
−15
−10
−5
0
5
10
15
Fig. 6. Plot obtained for the single shot case
and restarts the server. The server immediately receives a
connection from the client (which has been polling for the
server) and informs Tinyviz that the time series response
is ready. The input sequence and the time series response
are both matrices and are exchanged between MATLAB and
Tinyviz through les. Tinyviz , through the plugin, reads the
response and maintains data structures to store the time series
on a per mote basis, and starts TOSSIM. Whenever a mote
in TOSSIM asks for a sample, the requirement is directed to
Tinyviz in the form of an event. Upon reception of the event,
Tinyviz reads the rst sample from the data structure specic
to the requesting mote and sends it to TOSSIM. This sequence
of actions denes the behavior of the integrated simulator
when only an external excitation is present.
Further, when Tinyviz receives an actuation event, it pauses
TOSSIM and generates a new input sequence by concatenating
the new actuation along with the old input sequence. It then
launches a TCP/IP client in a separate thread, informs the
9
0 200 400 600 800 1000 1200
−60
−50
−40
−30
−20
−10
0
10
20
30
40
Fig. 7. Plot obtained for the multi shot case
blocked server about the new input sequence and waits until
the server restarts. Upon reception of the request the server
terminates and MATLAB processes the new input sequence.
When MATLAB concludes, it restarts the server and informs
the client that the new data is ready. When the plugin reestab-
lishes a connection it discards the samples that have already
been given to TOSSIM (past time) and repopulates the data
structures with the remaining time series responses (future
time). At this point the implementation satises the equation
S(x
n
(t)) = y
n
(t)
E. Operation
A user willing to use the integrated simulator, needs to
install the MATLAB Control Toolbox and TOSSIM, and will
need to provide an input le. The format of the input le is
provided and is loaded directly from the plugin developed in
Tinyviz, the input le should contain the following informa-
tion:
simulation time: the desired time of simulations.
time step: this should correspond to the sampling time
on the sensing device , a smaller time step will provide a
ne resolution, a longer time step will provide a coarse
resolution.
system object: is the object of the structure to be simu-
lated.
input vector: it is the initial input actuation.
Figures 6 and 7 shows the plots obtained for the single
and multi shot cases respectively. In this scenario the structure
had 111 inputs and 108 outputs, the simulation time was 10
seconds and the time step was set to 0.01 s. In Figure 6 as can
be observed there is only a single actuation at t = 0. This is
represented by a spike in the sensed data at t = 0. Since this
is the only actuation, the vibrations would slowly decay over
time, also captured by the leading edge of the plot. Figure 7
being multishot mode has multiple spikes at t = 0,t = 200s
and t = 400s. These correspond to times when the motes were
instructed to generate an actuation. After each actuation the
vibrations slowly decay but before the phenomenon can go to
zero it is interrupted by another actuation. This plot clearly
captures the bidirectional nature of the multishot mode.
IV. CONCLUSION
In this work we have presented the motivation for the
problem of integrating environment and network simulators.
The importance of this integration is highlighted in sensor
network applications whose performance is heavily dependent
on the correlated nature of the sensed data. The work presents
a survey of existing network and environment simulators as a
disjoint set highlighting the need to ll the void between them.
We have also presented a case study involving the integration
of a specic environmental simulator namely, the structural
simulator control tool box in MATLAB and the Tiny OS
simulator TOSSIM. The case study gives insights into possible
solutions for the challenges posed during the integration of
the structural simulator and the network simulator. One of the
core problems that has been tackled in this case study is the
multishot mode of operation for the integration where there is
a bidirectional ow of data between the structural simulator
and network simulator.
An insight that has been presented by this case study and
is a possible direction for our future work, is the need for
a middleware that could act as a common bridge for all
network simulators and environment simulators. In this case
study we have built upon existing framework provided by
the specic network simulator at hand. What if a network
simulator does not provide such a framework? Also should all
network simulators provide such an elaborate framework? By
providing a middleware, the necessity for such a framework
could be removed. Network simulator developers could simply
develop plugins to t their sensing modules into the common
interface presented by this middleware. The communication to
the environment simulator could than be completely abstracted
and made independent of the network simulator. A similar
abstraction could be carried out at the environment simulator
end. However our belief is that tackling the same problem at
the environment simulator end would be much harder simply
due to the expanse covered by this category of simulators.
REFERENCES
[1] Chalermek Intanagonwiwat, Ramesh Govindan and Deborah Estrin,
Directed diffusion: A scalable and robust communication paradigm
for sensor networks, In Proceedings of the Sixth Annual International
Conference on Mobile Computing and Networking (MobiCOM '00),
August 2000, Boston, Massachussetts.
[2] B. Krishnamachari, D. Estrin, and S. Wicker,Modelling Data-Centric
Routing in Wireless Sensor Networks.USC Computer Engineering
Technical Report CENG 02-14, 2002
[3] A. Scaglione, S. D. Servetto,On the Interdependence of Routing and
Data Compression in Multi-Hop Sensor Networks., In the Proceedings
of the 8th ACM International Conference on Mobile Computing and
Networking (MobiCom), Atlanta, GA, September 2002.
[4] Sundeep Pattem, Bhaskar Krishnamachari and Ramesh Govindan,The
Impact of Spatial Correlation on Routing with Compression in Wireless
Sensor Networks, ACM/IEEE International Symposium on Information
Processing in Sensor Networks (IPSN), April 26-27, Berkeley, CA 2004b
[5] K. Whitehouse and D. Culler, Calibration as Parameter Estimation
in Sensor Networks, In Proceedings of The First ACM International
Workshop on Wireless Sensor Networks and Applications (WSNA'02).
Atlanta, Georgia, September 28, 2002. ACM Press.
10
[6] N. Sadagopan, B. Krishnamachari, and A. Helmy, The ACQUIRE
Mechanism for Efcient Querying in Sensor Networks. IEEE In-
ternational Workshop on Sensor Network Protocols and Applications
(SNPA'03),held in conjunction(ICC 2003).
[7] S. Madden, M.J. Franklin, J.M. Hellerstein, W. Hong. TAG: a Tiny
AGgregation Service for Ad-Hoc Sensor Networks. 5th Symposium
on Operating System Design and Implementation (OSDI 2002), Boston,
Massachusetts, USA. USENIX Association. December 9-11, 2002
[8] B. Krishnamachari and S. Iyengar,Distributed Bayesian Algorithms for
Fault-tolerant Event Region Detection in Wireless Sensor Networks.
IEEE Transactions on Computers, vol. 53, No. 3, March 2004.
[9] Philip Levis,Nelson Lee, Matt Welsh, and David Culler, TOSSIM:
Accurate and Scalable Simulation of Entier TinyOS Applications. Pro-
ceedings of the rst international conference on Embedded networked
sensor systems, Sensys'03
[10] D. Ganesan, B. Krishnamachari, A. Woo, D. Culler, D. Estrin, and S.
Wicker. An Empirical Study of Epidemic Algorithms in Large Scale
Multihop Wireless Networks, February 2002.
[11] The Network Simulator- ns-2, http://www.isi.edu/nsnam/ns/
[12] http://www.opnet.com/
[13] Sung Park, Andreas Savvides, and Mani B. Srivastava, SensorSim: A
Simulation Framework for Sensor Networks, Proceedings of the 3rd
ACM international workshop on Modeling, analysis and simulation of
wireless and mobile systems, Boston, MA, 2000.
[14] L. Girod, J. Elson, A. Cerpa, T. Stathopoulos, N. Ramanathan, D.
Estrin, EmStar: a Software Environment for Developing and Deploying
Wireless Sensor Networks, in the Proceedings of USENIX General
Track 2004.
[15] Sameer Sundresh, Wooyoung Kim, and Gul Agha, SENS: A Sensor,
Environment and Network Simulator , In Proceedings of 37th Annual
Simulation Symposium, pages 221-230, 2004
[16] H. Abrach, S. Bhatti, J. Carlson, H. Dai, J. Rose, A. Sheth, B. Shucker, J.
Deng, R. Han, MANTIS: System Support For MultimodAl NeTworks
of In-situ Sensors, 2nd ACM International Workshop on Wireless
Sensor Networks and Applications (WSNA) 2003, pp. 50-59.
[17] Gyula Simon, Peter V olgyesi, Miklos Maroti, Akos Ledeczi. Simulation-
based optimization of communication protocols for large-scale wireless
sensor networks. Proc. of the IEEE Aerospace Conference, March 2003
[18] Gyula Simon, Peter V olgyesi, Miklos Maroti, Akos Ledeczi. Simulation-
based optimization of communication protocols for large-scale wireless
sensor networks. Proc. of the IEEE Aerospace Conference, March 2003
[19] Global Mobile Information Systems Simulation Li-
brary,http://pcl.cs.ucla.edu/projects/glomosim/
[20] http://www.glerl.noaa.gov/metdata/
[21] http://waterdata.usgs.gov/nwis/qw
[22] M. Widmann and C.bretherton, 50 km resolution daily precipitation for
the Pacic Northwest, 1949-94, Climate Data Archive, JOint Institute
for the Study of the Atmosphere and the Ocean, 1999. Online data-set
located at http://www.jisao.washington.edu/data sets/widmann
[23] http://www.greatduckisland.net/index.php
[24] Modelling Spatially Correlated Sensor Network Data, A. Jindal and K.
Psounis. Technical report, CENG-2004-10, USC.
[25] http://www.geomin.unibo.it/orgv/hydro/music/reports/D7.1 BlockKriging.pdf
[26] http://www.dhpc.adelaide.edu.au/projects/kriging/
[27] Eric W. Weisstein. Heat Conduction Equa-
tion. From MathWorldA Wolfram Web Resource.
http://mathworld.wolfram.com/HeatConductionEquation.html
[28] http://scienceworld.wolfram.com/physics/LambertsLaw.html
[29] Lorenzo Rossi, Bhaskar Krishnamachari, C.-C. Jay Kuo, Modeling of
Diffusion Processes with PDE Models in Wireless Sensor Networks,
SPIE Defense & Security Symposium, April 2004
[30] http://www.scientic-computing.co.uk/numerme/fem.htm
[31] http://www.mscsoftware.com/support/prod support/nastran/biblio/optaps.cfm
[32] Mathew Roberts, Luciana R.Barroso, and Loren D.Lutes.A
Non Linear Finite Element Toolbox For Structural Control.
http://nlfet.sourceforge.net/docs/3wcsc.pdf

Linked assets

Computer Science Technical Report Archive

Conceptually similar

PDF

USC Computer Science Technical Reports, no. 792 (2003)

PDF

USC Computer Science Technical Reports, no. 823 (2004)

PDF

USC Computer Science Technical Reports, no. 830 (2004)

PDF

USC Computer Science Technical Reports, no. 795 (2003)

PDF

USC Computer Science Technical Reports, no. 864 (2005)

PDF

USC Computer Science Technical Reports, no. 791 (2003)

PDF

USC Computer Science Technical Reports, no. 862 (2005)

PDF

USC Computer Science Technical Reports, no. 639 (1996)

PDF

USC Computer Science Technical Reports, no. 778 (2002)

PDF

USC Computer Science Technical Reports, no. 863 (2005)

PDF

USC Computer Science Technical Reports, no. 604 (1995)

PDF

USC Computer Science Technical Reports, no. 837 (2004)

PDF

USC Computer Science Technical Reports, no. 814 (2004)

PDF

USC Computer Science Technical Reports, no. 839 (2004)

PDF

USC Computer Science Technical Reports, no. 715 (1999)

PDF

USC Computer Science Technical Reports, no. 624 (1996)

PDF

USC Computer Science Technical Reports, no. 963 (2015)

PDF

USC Computer Science Technical Reports, no. 804 (2003)

PDF

USC Computer Science Technical Reports, no. 749 (2001)

PDF

USC Computer Science Technical Reports, no. 774 (2002)

Description

Avinash Sridharan, Marco Zuniga, Bhaskar Krishnamachari. "Integrating environment simulators with network simulators." Computer Science Technical Reports (Los Angeles, California, USA: University of Southern California. Department of Computer Science) no. 836 (2004).

Asset Metadata

Creator Krishnamachari, Bhaskar (author), Sridharan, Avinash (author), Zuniga, Marco (author)

Core Title USC Computer Science Technical Reports, no. 836 (2004)

Alternative Title Integrating environment simulators with network simulators (title)

Publisher Department of Computer Science,USC Viterbi School of Engineering, University of Southern California, 3650 McClintock Avenue, Los Angeles, California, 90089, USA (publisher)

Tag OAI-PMH Harvest

Format 10 pages (extent), technical reports (aat)

Language English

Unique identifier UC16269922

Identifier 04-836 Integrating Environment Simulators with Network Simulators (filename)

Legacy Identifier usc-cstr-04-836

Format 10 pages (extent),technical reports (aat)

Rights Department of Computer Science (University of Southern California) and the author(s).

Internet Media Type application/pdf

Source 20180426-rozan-cstechreports-shoaf (batch), Computer Science Technical Report Archive (collection), University of Southern California. Department of Computer Science. Technical Reports (series)

Access Conditions The author(s) retain rights to their work according to U.S. copyright law. Electronic access is being provided by the USC Libraries, but does not grant the reader permission to use the work if the desired use is covered by copyright. It is the author, as rights holder, who must provide use permission if such use is covered by copyright.

Repository Name USC Viterbi School of Engineering Department of Computer Science

Repository Location Department of Computer Science. USC Viterbi School of Engineering. Los Angeles\, CA\, 90089

Repository Email csdept@usc.edu

Inherited Values

Title Computer Science Technical Report Archive

Description Archive of computer science technical reports published by the USC Department of Computer Science from 1991 - 2017.

Coverage Temporal 1991/2017

Repository Email csdept@usc.edu

Repository Name USC Viterbi School of Engineering Department of Computer Science

Repository Location Department of Computer Science. USC Viterbi School of Engineering. Los Angeles\, CA\, 90089

Publisher Department of Computer Science,USC Viterbi School of Engineering, University of Southern California, 3650 McClintock Avenue, Los Angeles, California, 90089, USA (publisher)