Integrating Environment Simulators with Network Simulators - CiteSeerX

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 {asridhar, marcozun, bkrishna}@usc.edu

Abstract— We present a challenge that is unique to sensor network simulations, that of integrating environment and network 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 field 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 first present a survey of the existing network simulators and environmental simulators, to highlight the deficiency in the current research based on simulations. Further we present a case study on integrating a specific 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. I NTRODUCTION 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 configuration 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 credence 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 specific 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 parameterizing each device and fine 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 communication with the environment. In traditional networks a strict layering separates the content of the data from networking related concerns. Therefore network protocols could be evaluated purely on the basis of protocol characteristics and some network parameters such as topology, traffic rates (but not the traffic content).With the coming of sensor networks this design philosophy has undergone a complete change, with the traffic 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 defining the performance and the interaction of the application/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 benchmarks for the behavior and performance of the data sensitive protocols we believe it is imperative to incorporate interaction 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 defining 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 (Environment Simulators) can feed inputs into the NS (Network 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 S URVEY

OF

N ETWORK AND E NVIRONMENT S IMULATORS

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 specific 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 specifically 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 specifically designed to support wireless networks and hence has very good propagation models. Opnet is an industrial standard commercial simulator comparable to ns2. 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 modified 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 specifically for sensor networks and a module for the simulation to interact with actual sensors, forming a hybrid simulation. Emstar [14] and TOSSIM [9] were the first 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 running 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 systems. It provides different levels of simulation environments

4

Simulators NS2 GLOMOSIM OPNET SensorSim TOSSIM EmStar SENS MANTIS SIESTA Prowler JProwler

Availability √ √ X √ √ √ √ √ √ √ √

Scalability √ √ √ √ X √ √ X √ √ √

Programming Language C++ C++ C++ C++ nesC nesC/C++ C++ C JAVA MATLAB JAVA

Sensor Modules X X X √ √ √ √ √ √

Wireless√Models √ √ √ √ √ √

X X

X X √ √

Event/Time Event Event Event Event Event Event/Time Event Time Time Event 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 operation 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 final 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 configuration 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 MANTIS 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 sensor networks. Application can be integrated with propagation models to provide different sensor net scenarios. JProwler is the JAVA version of Prowler. SIESTA [18] is a sensor network simulator from Vanderbilt University. Its targeted towards testing and simulating middleware 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 environment measurements. There are numerous data sets that are available on the internet. [20] gives data sets for meteorological 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 specified 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 specific 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 fx (x). The value of data at point (x,y) is than given by:  1 1 with probability Nα(1)   X1 + Z   ..    .    N (1)  1  X + Z with probability Nα(1)  1   2  with probability Nα(2)  X21 + Z    ..    .  N (2) 2 X(x, y) = X2 + Z with probability Nα(2)    ..   .    1 h  X with probability Nα(h)  h+Z    ..    .    N (h)  h  + Z with probability Nα(h) Xh    Y with probability β

Xdk 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) = 2 ω2 ΦY (jω) −σz 1 − (1 − β)e[ 2 ]

The inputs to this model are the variance of the random variable Z, σz2 , the distribution of the random variable X, fX (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 Z0∗ , the estimate of the actual value Z0 of the data at the point of interest where X Z0∗ = λi Z i i

where Zi are the set of known values, based on the constraints E[(Z0∗ − Z0 )2 ] is a minimum and X

λi = 1

i

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 specific 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: ∂ 2T ∂T =k 2 ∂t ∂x A more generic model for diffusion in 1-D used in [29] can be represented using partial differential equations as follows: ∂ 2 x(t, ζ) ∂x(t, ζ) ∂x(t, ζ) = θ1 + θ2 + x(t, ζ) ∂t ∂ζ 2 ∂ζ 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 = I0 e−Ks Where I is the light intensity and K is the extinction coefficient.

6

(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 difficult. 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 first 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 specific case study and our solution to the problems posed. The target structural simulator is the control tool box provided by MATLAB for structural simulations. The control tool box uses a finite element model to simulate vibrations within a structure. The network simulator chosen was TOSSIM, the Tiny OS simulator. 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 fields have PDE models, but it is very difficult to obtain analytical expressions to these models. Therefore computational techniques are used to solve these models to get approximations to the solutions. An example of such an approximation technique is the finite element model [30]. In this method the domain under observation is divided into a finite 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 finite element model to simulate vibrations within a structure. III. C ASE S TUDY: I NTEGRATING THE MATLAB TOOL BOX AND TOSSIM

CONTROL

In this section we look at integrating a specific environment simulator, namely a structural simulator with a network simulator. The utility of this integration lies in the application of sensor networks to the field 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 field 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

A. MATLAB The environment being simulated is a building, which is modeled as a MIMO (multiple input, multiple output) statespace system in MATLAB. State-space models are defined by the following equations: dx = Ax + Buy = Cx + Du dt 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 x0 , which represents the undamaged structure. And the output vector reflects 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 simulation function. lsim allows simulation in the continuous and discrete time domains. Due to the interaction with the network simulator, where nodes sample at a specific rate, the discrete time option is more efficient, 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 specific user plugins can be added to suite specific 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 modification to the existing simulator to suffice 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 modification 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 specific 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 specific example of TOSSIM is that the sensor network devices targeted for actual deployment are the mica 2 motes and TOSSIM implements TinyOS to very fine 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 simulate 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 first

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 specific 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 = −∞ that has generated a response y(t). y(t) being a discrete quantity can be thought of as being composed of samples Y1 , Y2 , . . .. To integrate such a system with network simulator is than a simple process. Every sample Yi 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 explained 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 = −∞ 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 (x1 , x2 , . . .) 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 − t1 )) = y1 (t) S(δ(t − t1 ) + δ(t − t2 )) = y2 (t) S(δ(t − t1 ) + δ(t − t2 ) + δ(t − t3 )) = y3 (t) .. . S(δ(t − t1 ) + δ(t − t2 ) + · · · + δ(t − tn )) = yn (t) An external actuation or an actuation generated by the network into the structural simulator at a time tn could be thought of as an impulse δ(t − tn ), thus the the input function at any time tn would be the summation of all the impulses till this point. In other words xn (t) = δ(t − t1 ) + δ(t − t2 ) + · · · + δ(t − tn ) The response of the systems at time tn would than be yn (t). Now the fact that yn (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 ti , store all the actuations to the structure till the point ti . • If an actuation occurs at time ti , stop the network simulator. Use the structural simulator to find yi (t) using: S(δ(t − t1 ) + δ(t − t2 ) + · · · + δ(t − ti )) = yi (t) Discard samples Y1 . . . Yi−1 , from the time series response of yi (t) • Store the remaining samples of yi (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 yn (t).

Fig. 5. Block Diagram of the client/server architecture used to implement the integration of TOSSIM and MATLAB 15

10

5

•

D. Implementation A new plugin was developed for Tinyviz to act as a mediator 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, MATLAB 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

0

−5

−10

−15

Fig. 6.

0

200

400

600

800

1000

1200

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 files. 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 first sample from the data structure specific to the requesting mote and sends it to TOSSIM. This sequence of actions defines 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

40

zero it is interrupted by another actuation. This plot clearly captures the bidirectional nature of the multishot mode.

30 20

IV. C ONCLUSION

10 0 −10 −20 −30 −40 −50 −60

Fig. 7.

0

200

400

600

800

1000

1200

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 reestablishes 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 satisfies the equation S(xn (t)) = yn (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 file. The format of the input file is provided and is loaded directly from the plugin developed in Tinyviz, the input file should contain the following information: • 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 fine resolution, a longer time step will provide a coarse resolution. • system object: is the object of the structure to be simulated. • 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

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 fill the void between them. We have also presented a case study involving the integration of a specific 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 flow 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 specific 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 fit 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. R EFERENCES [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 Efficient Querying in Sensor Networks.” IEEE International 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.” Proceedings of the first 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 Volgyesi, Miklos Maroti, Akos Ledeczi. Simulationbased optimization of communication protocols for large-scale wireless sensor networks. Proc. of the IEEE Aerospace Conference, March 2003 [18] Gyula Simon, Peter Volgyesi, Miklos Maroti, Akos Ledeczi. Simulationbased optimization of communication protocols for large-scale wireless sensor networks. Proc. of the IEEE Aerospace Conference, March 2003 [19] Global Mobile Information Systems Simulation Library,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 Pacific 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 Equation.” From MathWorld–A 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.scientific-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