Electrical Engineering and Computer Science Department

Technical Report NWU-EECS-08-05 June, 2006 SIDnet-SWANS: A Simulator and Integrated Development Platform for Sensor Networks Applications
Oliviu Ghica, Goce Trajcevski, Peter Scheuermann, Zachary Bischoff, Nikolay Valtchanov

Abstract
We present SIDnet, an exploratory-design environment for various aspects of applications of wireless sensor networks. The main motivation for the work was to provide a simulation and proof-of-concept platform in which the end-users, the application/protocol developers and various phenomena monitored by that network interact in seamless manner. SIDnet is a Java-based visual tool designed to promote runtime interactions with the network. End-users can observe the behavior of a newly designed algorithm in the presence of unforseen and often hard to model conditions, such as phenomena fluctuations, or a sudden loss of service both at an individual node, as well as a collection of nodes in a certain area of the network. User can post queries in a language similar to TinySQL, at run-time, through built-in terminals, and fast-forward or pause the simulation as they desire. SIDnet incorporates a complete graphical user interface package built on top of the JiST-SWANS simulator which, in turn, guarantees the underlying performance and validity of the simulations. It is an extensible tool with a well defined, easy to learn API that developers can use to integrate their novel implementations and, together with the end-users of the application, perform various hypothetical reasoning in any pre-deployment stage.

Research supported by the Northrop Grumman Corp. grant PO 8200082518 Research supported by the NSF – IIS-0325144/03 Keywords: Wireless Sensor Networks, Simulation

1

SIDnet-SWANS: A Simulator and Integrated Development Platform for Sensor Networks Applications
Oliviu Ghica Goce Trajcevski† Peter Scheuermann‡ Zachary Bischoff Nikolay Valtchanov Department of EECS Northwestern University Evanston, Il, USA {ocg474,goce,peters,zbisc424,nvalt117}@eecs.northwestern.edu
ble. Hence, the researchers and developers need to rely on a model and a simulation(s) in order brings the model to life for the purpose of examining the desired properties of a given sensor network application. There are several simulators and emulators for wireless sensor networks (e.g., [1], [3], [4], [23]) whose validity for performing various evaluations has been recognized. However, most of the popular simulators are adaptations from the ad-hoc networks, and were not primarily designed for the scale that wireless sensor networks can reach. The JiST-SWANS[6] has addressed the scalability and computation power issues from its design stage. The main motivation for our work was to provide a simulation tool for exploratory analysis that can enable different types of participants, from domain-experts to network researchers, to reason about the properties of various components of a particular sensor network’s application by examining many (classes of) scenarios. Towards this end, we developed the SIDnet-SWANS (Simulator and Integrated Development Platform for Sensor Networks Applications) which allows the users to interact with (the models of) different dynamic phenomena, as well as various components of the network, at different levels of granularity (e.g., node, region, routing structure). At a glance, SIDnet represents a graphical user interface wrapper for the JiST-SWANS, designed for streamlining the user interaction with the network, post, pre, or during the simulation in an intuitive and simplistic manner (e.g., control the speed of the simulator, pause it, check the energy-level of a node or group of nodes) during ”run-time”. Although JiST-SWANS itself, as well as other simulators, incorporates basic debugging tools, such as loggers, it is still very difficult to reason about the evolution of the application by following interminable lists of logged material. A graphical-based alternative can definitely make a major difference. SIDnet proposes to fill in this gap, and in addition to the core JiST-SWANS, to add the following features, some of which are specific to wireless, battery powered sensor networks: • flexible graphical user interaction with the wireless sensor network • visual feedback of the sensor network’s state in realtime. • explicit control over the simulation’s speed.

Abstract—We present SIDnet, an exploratory-design environment for various aspects of applications of wireless sensor networks. The main motivation for the work was to provide a simulation and proof-of-concept platform in which the end-users, the application/protocol developers and various phenomena monitored by that network interact in seamless manner. SIDnet is a Java-based visual tool designed to promote run-time interactions with the network. End-users can observe the behavior of a newly designed algorithm in the presence of unforseen and often hard to model conditions, such as phenomena fluctuations, or a sudden loss of service both at an individual node, as well as a collection of nodes in a certain area of the network. User can post queries in a language similar to TinySQL, at run-time, through built-in terminals, and fast-forward or pause the simulation as they desire. SIDnet incorporates a complete graphical user interface package built on top of the JiSTSWANS simulator which, in turn, guarantees the underlying performance and validity of the simulations. It is an extensible tool with a well defined, easy to learn API that developers can use to integrate their novel implementations and, together with the end-users of the application, perform various hypothetical reasoning in any pre-deployment stage. Index Terms—Wireless sensor networks, Simulation

I. Introduction Sensor networks are composed of hundreds, possibly thousands, of tiny, low cost nodes (sensors) with limited power, memory and computational capacity, that can function autonomously and cooperate with each other for performing various tasks. Application domains of sensor networks are plentiful, ranging from short-lived rescue operations that have high degree of dynamics, to long-term scientific research projects that monitor an environment where the power-efficient execution of long-lived queries is paramount [14]. Successful sensor network designs draws on work in many fields and is an interdisciplinary activity, requiring contributions from the domain-experts, along with the networking, databases, and hardware design communities. Testing and analysis of large-scale sensor networks applications in real-life settings, before the actual deployment, is cost-prohibitive and sometimes (e.g., when monitoring phenomena in harsh physical environments) even impossi†Research supported by the Northrop Grumman Corp. grant PO 8200082518 ‡Research supported by the NSF – IIS-0325144/03

2

integrated energy consumption modelling and management. • modular design, allowing for user addition of various models of phenomena to be simulated (temperature dynamics, humidity, moving objects, etc) SIDnet1 is written in Java and provides well-defined APIs for its modules that implement various components: from the query specification GUI, through the routing structure selection, all the way to the models of phenomena fluctuations and nodes’ deployment. Thus, one of its salient features is the extensibility, and we believe that it can provide an environment in which the research community can incorporate libraries of different modules to be used for simulating particular applications’ settings. The rest of this paper is structured as follows. Section 2 presents an overview of the JiST and SWANS, as they are the foundations of the SIDnet. In Section 3 we discuss the basic architecture of SIDnet, and the modelling and management of the energy consumption. Section 4 illustrates in detail some of the features currently available in our simulator and Section 5 presents an actual example of using it for performing a comparative experimental study. In Section 6 we position our work with respect to the related literature, and we conclude the paper in Section 7.

number of nodes and still generate an accurate representation of the temporal evolution, without being affected by the processing-power starvation. The time-semantics is transparent to the observer, since the Java-coded applications are rewritten automatically, as part of the compilation process, in order to incorporate the simulation time primitives . JiST runs on top of an unmodified Java virtual machine, which is converted, at run-time, into a powerful simulation system that is very efficient, scales to large number of nodes and is easy to work with. It represents an enabling platform that does not require the user to gain in depth knowledge on the way it is designed in order to develop applications in SIDnet. B. SWANS SWANS (Scalable Wireless Ad hoc Network Simulator ) [6] is built on top of the JiST engine with functionality, similar to ns2 [3] and GloMoSim [23]. In a sense, it offers the best of the both worlds: linear, grid-based, and signal propagation models using hierarchical binning; as well as independent and additive radio noise models. In addition, it also implements Raleigh and Rician fading models, freespace and two-ray (with ground reflection) path-loss models, placement models, and two mobility models: static and random-waypoint. The radios can be configured by taking various parameters into account: e.g., frequency, transmission power, reception sensitivity and threshold, antenna gain, bandwidth, and error models (bit-error rate and signal-to-noise threshold).

II. Preliminaries We give an overview of the two fundamental components of the JiST-SWANS simulation engine, upon which we relied for the implementation of the SIDnet. A. JiST Engine JiST [2] (Java in Simulation Time) is the core eventsimulation engine which was designed as an attempt to offer a simulation tool that has the flexibility and transparency of the simulation kernels and efficiency of the dedicated simulation libraries. While there are other simulators that achieve high scalability, they mostly use specific programming languages and/or complex computing infrastructure, whereas JiST relies on Java – a widespread programming languages running on common infrastructure. As demonstrated in [2], up to one million of nodes can be simulated using JiST on a regular desktop PC. JiST does not implement a new simulation kernel, or a simulation library, nor does it rely on common processoriented approaches (e.g., threads and synchronization). Instead, it introduces a novel concept of bringing a simulation semantics to the virtual machine. The main motivation was to enable the developers to explicitly control the time-passage in a transparent manner, faithfully replacing the real-time with the simulation-time. This, in turn, gives the users’ the option to specify the amount of time a particular instruction takes – e.g., without user’s intervention, each instruction takes zero time-units to execute (default). As a consequence, the simulation can incorporate a large
1 The source code for SIDnet, along with the documentation is publicly available at http://www.eecs.northwestern.edu/˜ peters/sensors/SIDnet.html

Application Node Transport
(UDP)

Node

Node

Network
(IPv4)

Routing

MAC
(802.11b)

Radio

Mobility

Field

Field

Fig. 1. The Architecture of SWANS

As illustrated in Figure 1, SWANS implements all the standard OSI [19] networking layers. The actual simulator consists of a set of event-driven software modules, each of which models the desired functionality at a particular layer. The network stack of each individual nodes is executing in complete isolation, which gives a twofold advantage: (1) two instances of a code running at the same layer on distinct nodes cannot communicate directly; (2) users can simulate heterogeneous networks by allowing each node to be independently configured. Thus, the execution of the network stack has a potential of being parallelized with a

Node

SIDNET-SWANS: A SIMULATOR AND INTEGRATED DEVELOPMENT PLATFORM FOR SENSOR NETWORKS APPLICATIONS3

Batch Processing Tool

SIDnet GUI, Visualization Tools & Management

Sensorial Layer (Phenomenon Dynamics) Sensorial Layer (Phenomenon Dynamics)

Simulation Speed Controller Simulation Speed Controller

Plug-in, Run-time Tools Plug-in, Run-time (Energy Map, Tools Statistics, Topology (Energy Map, Viewer, etc) Statistics, Topology Viewer, etc)
GUI GUI

Terminal

T

T

T

Sensors Battery

"GPS"

SIDnet Node

Energy Modeling & Management Energy Modeling & Management

Simulation Manager Simulation Manager

SIDnet Node

SIDnet Node

SIDnet Node

Shared Environment

Terminal / Query Parser

Nodes (GUI) Mapping of Sensor Nodes

Network Node Stack MAC Node Stack Node Stack Node Stack

Wireless Ad-Hoc Network Stack (SWANS)

Radio

Fig. 2. Main components of the SIDnet simulator

Field

minimum of the synchronization cost2 . SWANS provides a detailed implementation of the IEEE 802.11b protocol [19], including complete DCF with retransmissions, NAV and backoff functionality. It does not include, however, the access-point, fragmentation and frequency hopping that is part of its specification. In addition to 802.11b, it also includes a dumb and wired -like Link layer protocols. A distinct feature of SWANS is that it can execute unmodified Java applications at the application layer. A comparative evaluation of SWANS with ns2 and GloMoSim can be found in [6]. III. SIDnet’s Modular Architecture SIDnet represents a collection of packages that increase the functionality of the original JiST-SWANS simulator, in a manner that is suitable for developing and testing applications of wireless sensor network. In this section, we present the main architectural components of the SIDnet and its relationship with the JiST-SWANS core-modules. We reiterate that one of the goals of our implementation was to make it extensible, in the sense that additional components can be easily incorporated. The basic architecture of the SIDnet is illustrated in Figure 2. The GUI component, which handles all the windows and menus functionalities allows the users to interact with different entities of the simulation (e.g., individual node, group of nodes, monitored phenomena, queries, etc.) The current version offers various visualization tools, such as: query specification; routing structures selection; topology visualization tools; energy map; statistics; etc. (c.f. Section 4). In the rest of this section, we describe how the representation of the nodes in SIDnet is integrated with their representation in the underlying SWANS engine, and we discuss the incorporation of a more versatile energy2 A parallel-version of JiST has also been consideration as a possible future extension, in order to aid the parallelization of applications such as SWANS [6]

Sensorial Layers

Fig. 3. The interaction of the SIDnet node with the SWANS network stack

management. A. SIDnet and SWANS Linking the JiST-SWANS and SIDnet is mainly achieved by mapping the network stacks corresponding to individual SWANS-nodes to their counter-part representation in SIDnet, which we will refer to as the SIDnet node. Figure 3 presents a detailed illustration of the logical connection between the SWANS node stack and SIDnet. Essentially, the SIDnet representation of a node can be viewed as a placeholder for various (hardware) components found in a sensor node, e.g., battery, GPS (Global Positioning System) and the other physical properties. In addition, the structure representing a SIDnet node also acts as an interface between the application layer of the SWANS stack and the different functions used by a particular instance of the SIDnet, offering the programmers a seamless integration of the entities to-be-observed for a particular application. This promotes a cross-layer design, allowing, for instance, Application, Network and Link layers to share various information of common interest, e.g., list of one-hop neighbors. As an illustrative example, the expanded view of a SIDnet node in the top part of Figure 3 shows how one can include the impact of the values of the physical phenomena (e.g., high temperature) into the properties of the battery of a given node (e.g., increased leakage). The GUI-mapping of the sensor nodes enables the users to access various visualization functions like, for example, whether a given node is transmitting or receiving, as opposed to sensing or processing data; what is the level of depletion of the nodes battery; which particular packet along the route that a node participates in, is currently

Subset of (SWANS) network stack

Terminal / Query Parser

SIDnet SIDnet (GUI) Mapping of Sensor

Pre-processing tools Pre-processing (Deployment) tools (Deployment)

Application

4

Fig. 4. Tracing packet across individual nodes
Energy Management

Fig. 6. Query specification in SIDnet

Application Network

Battery (Model)

Energy Consumpt ion Model

Battery (Stub)

Mac Link Physical

Sensorial

Fig. 5. Energy Modelling and Management

being transmitted, etc. For example, Figure 4 illustrates how the user can trace the route of a particular data-packet from a given source towards a given sink. The sensorial layer in Figure 3 represents the actual physical environment in which the individual nodes are deployed, and models the fluctuations of the different phenomena that are being sampled by the nodes, for a given application at hand. B. Integrated Energy Consumption Model Assessing the energy-costs for communication, sensing and processing in a simulator is, in general, a difficult and error-prone task, which may result in incorrect performance evaluations. One of the goals of SIDnet is to ensure the management of the energy consumption in a manner that will reflect the desired semantics, while guaranteeing consistent consumption patterns across executions of different instances of the simulation. As a particular simulation progresses, the correct amount of the energy consumed by a given node (in response to its tasks) will be automatically deducted. The model for energy management in SIDnet is illustrated in detail in Figure 5. As can be seen, our implementation separates the operational energy consumption from the battery drainage model, which gives an additional flexibility to the users, in terms of specifying the transient characteristics of the battery’s leakage (if needed for a specific application), say, due to humidity. For the purpose of correctness of the run-time performance, the software component implementing the energy management uses two ”batteries”: (1) the actual battery (model); and

(2) the virtual battery (stub). The stub acts as an interface for querying the energy level of a given node, which is subsequently transferred to the actual energy model for processing. This arrangement is also done for performance reason, but it may be changed at any time if the application requires a different consumption model. Note that different layers of the node-stack can access the energy management module in order to inquire about the energy level of a given battery. The current implementation handles three basic types of operational energy consumers: • Radio • CPU • Sensors Typically, the MAC/Link and the physical layer are seen as both CPU and Radio consumers while the Network and Application layers act as CPU consumers. The interaction between the network layers and the energy model is made through a dedicated API. We note that the energy consumption associated with performing a field measurement (sensing) is automatically accounted for whenever the node performs a sensing. In addition, the energy model accounts for: (1) both active and idle periods of the nodes, allowing the users to test the impact of different duty cycles in a given application scenario; and (2) the sleep periods of the radio device. The 802.11b MAC protocol has been pre-configured in the current implementation, in order to account for the energy consumption associated with the radio activity, in a manner transparent to the end-user. IV. Interactive Features of SIDnet In this section, we discuss in detail some of the features of the SIDnet that are integrated in the current version and illustrate the flexibility offered by Plug-In capabilities (c.f. Figure 2). Figure 6 illustrates how the terminal-mode of the SIDnet can be used to submit new queries to the network. Note that our system provides a graphical interface simultaneously accompanied with a textual one, in which various parameters of interest for the query can be specified in a

SIDNET-SWANS: A SIMULATOR AND INTEGRATED DEVELOPMENT PLATFORM FOR SENSOR NETWORKS APPLICATIONS5

Fig. 8. Menu for throttling the speed of the SIDnet

Fig. 7. Routing, phenomena fluctuation and nodes’ removal

high-level language which provides linguistics constructs that adhere to the syntax of the TinySQL [14]. Clearly, an important aspect of processing particular queries is the selection of a given routing structure, possibly combining the aggregation of the values measured by individual sensors. Towards this end, SIDnet provides a separate API that the developers can use to specify their chosen structure to-be-tested. However, an important component of each simulation is testing how the fluctuations of the given phenomena of interest impacts the overall behavior. To cater for this, one of the components of our simulator (c.f. Figure 2) is precisely dedicated to enabling users to specify different spatio-temporal patterns of the evolution of a particular value of interest, at various levels of granularity. The dynamics of the phenomena is implemented as a sensorial layer, and it can also be visualized, in real-time, overlapping with the sensor nodes and routing structures. We already illustrated in Section A how the users can interact with the SIDnet at a node-level for the purpose of tracking the route of a given packet. In addition to that, the internal status of any node can be accessed by means of a ”terminal” for the purpose of, e.g., checking its battery reserve, or even remove the currently-available reserves, relenting it inactive at any time, which can be useful when testing the resilience of a given routing structures to node failures. Moreover, at any point of the execution, the users can cause simultaneous cessations of a group of nodes, for the purpose of testing the network robustness in application scenarios such as fire-monitoring, in which a large number of nodes can be destroyed due to disastrous conditions. One of the main benefits of SIDnet is that the users, both domain-experts as well as application developers, can interact with the (state of the) wireless sensor network and receive visual feedback at any time during the simulation. We already illustrated in Section A how it can be done at a node-level for the purpose of tracking the route of a given packet.

Figure 7 gives a collective illustration of the fluctuation of the temperature in the region of interest (in the background), along with a k-short variant of a multi-path routing [17] between two (source, sink) pairs. In addition, it shows a menu which enables various interactions with the nodes at run-time. In this particular case, the group of the selected nodes (red-colored in the bottom-left portion of the Figure) was selected to be ”killed”. What completes the GUI are the run-time energy map component (illustrated in the top-right portion in Figure 7) along with the terminal-like component below it, displaying run-time statistics of the values of various parameters of interest, as specified by the user (e.g., energy consumed, average latency of packets, etc.). A. Throttling the SIDnet speed In general, simulators are expected to model a real-life application scenario in a manner that not only provides a faithful representation of all the aspects of interest at a negligible cost, but also provides fast execution. SIDnet is designed to trade-off the graphics representation offered to the user with the speed of the execution of a given instance of the simulation, without sacrificing the quality of the performances. The user can choose, at run time (aside from pausing the simulator) one of the following, preset speeds: • 1x, which corresponds to the real-time speed, in the sense that 1 second of simulation time roughly corresponds to one second of a wall clock; • 10x, a speed ten times faster than the ”real time” • 100x, • 1000x, • Accel • MAX All of the 1x to 1000x speeds are upper-bound specification of the speed that SIDnet can achieve, designed to ”slow down” whenever a visual inspection of any component of interest is desired. We note that the individual performance(s) will, of course, depend on the underlying machine used, as well as the complexity of the given instance of the simulation. In particular, the ”Accel” mode instructs the simulator to execute as fast as possible (given underlying machine capabilities), while maintaining the graphical primitives active. On the other hand, when a maximum speed of the execution is the goal, selecting the ”MAX” will disable all the graphical components. Figure 8 illustrates the ”zoom-in” portion of the variable-speed selections from Figure 7. Yet another way to control the speed of the simulation is to hard-code instructions that will cause the particular instance to accelerate over some

6

parts of the execution (e.g., MAX at the bootstrap and initialization sequences, such as initial node-discovery protocol) and, subsequently, slow down to visualize the evolution of the rest of application code. B. Deployment A specific plug-in that is not controlled by the Simulation Manager module (c.f. Figure 2), but can influence the course of a given simulation, is the deployment of the sensor nodes in a geographical region. The current version of the SIDnet supports three basic schemes for an initial deployment of the sensor nodes: 1. Single-node deployment: The users can choose to place manually each node in a given location. Clearly, this option is not quite efficient for sensor networks consisting of large number of nodes, however, it can be useful for some ”on-line” modifications when testing the effects that a re-deployment of a small amount can have on a particular implementation. 2. Random Deployment: At various levels of spatial granularity of the sub-regions of the region of interest, the users can select two options for populating them: uniform distribution, and bivariate normal distribution [22], where the latter is actually implemented as an intersection of the sub-region with the minimum enclosing rectangle. 3. Fly-By Deployment: This mode actually simulates a trajectory of an airplane flying over the region of interest, off of which the sensors are simply dispersed in various directions (relative to the flight) and at different discrete time-points. The trajectory of each individual node simulates the Newtonian motion of a horizontal shot, with a given initial velocity-vector and can incorporate the effects of a wind blowing at certain speed and direction. C. Batching of multiple executions As inherited from SWANS, an instance of a SIDnet execution is specified through a Driver, a Java-written configuration file. This approach offers some flexibility in the early development stage(s) of a given application, however, when a large volume of comparative experiments is needed, with many parameters whose impact needs to be tested, separate modifications of the driver file and recompilation before launching a particular instance of the application can be impractical. Hence, we provided a batching mechanism, which enables the users to specify all the ranges of the configurable parameters’ values by organizing them in a table and storing them locally in a .CSV (comma separated values) data file . The batching mechanism can read the data-file and automatically include the configuration arguments in various instances of SIDnet. Figure 9 illustrates the menu-item of SIDnet that allows the users to interact with the batch-mode of executing the experiments. We note that one can also select the set of values that are to be monitored across different executions (e.g., energy consumption, packet delivery latency, packet drop rate, etc.). Each SIDnet run logs the output of the

Fig. 9. Main control panel of SIDnet’s batching mechanism

monitored values at specified sampling intervals, with an option to safely interrupt a particular instance and, subsequently, resume its execution at any time. This enables obtaining run-time results of a large number of experiments in a more efficient manner. As an illustration, while comparing the benefits of multi path routing (c.f. [17]), we run instances in which 19 different parameters were being observed, in a total of two hundred and twenty simulations, each consisting of five hundred nodes, over a twenty-seven hours interval. The simulation completed in less than sixteen wall-clock hours on a dual-core machine with 1GB of heap memory available. V. Case Study: Tributaries and Deltas To demonstrate the usability of the SIDnet on an actual example, we implemented a variant of the TributaryDelta approach [16], which combines the advantages of the tree and multi-path approaches by running them simultaneously in different regions of the network. Our restricted version focused on comparing the energy-benefits of the multi-path routing (as opposed to a single-path) based on the k-shortest path (c.f. [5]) when the data to be sensed and aggregated was distributed in a polygonal region and the routing-tree was rooted at the point of the polygon (boundary) closest to the sink. Figure 10 presents comparative snapshots of the different energy-maps states after 24h and 48h of a particular execution of the single-path and multi-path routing outside the region of interest and towards the sink (darker areas represent higher degree of energy-depletion in the nodes). As an example of using the SIDnet in a batch mode, we executed 20 simulations of randomly-chosen (boundary polygon, sink) pairs, comparing the difference of the energy levels (i.e., discrepancy) of the nodes used for routing in the ”deltas” outside the query-polygon, with respect to the energy levels of their individual 2-hop neighbors in the network, when 10 non-braided k-short paths were used vs. 1 shortest path. Figure 11 illustrates the averaged values of the 20 simulations over the period of 48 hours. The x-axis denotes the time (in hours) and the y-axis denotes the average-percentage of the energy discrepancies of the nodes that participated in the routing along the

SIDNET-SWANS: A SIMULATOR AND INTEGRATED DEVELOPMENT PLATFORM FOR SENSOR NETWORKS APPLICATIONS7

24 hours
sink

48h hours
sink

sink

sink

Fig. 10. Energy Map for single vs. multi-path routing

Fig. 11. Quantitative experimental observations with SIDnet

”delta(s)”. This experiment enables a quantitative ”lookand-feel” data of the benefits, in terms of the level of the uniformity of the energy depletion in the network, when using multi-path routing. Using SIDnet batch-mode, we were able to complete all the 20 runs in less than 2 hours. VI. Related Work Based on the level of granularity used to model (and analyze) the impact of different parameters, sensor networks simulators can be classified in three major categories: coarse, medium and fine-grained. Coarse-level simulators model the interaction, at a topological level, between nodes that are being deployed in a field. These simulators do not consider a detailed radiocommunication model and, most commonly, they rely on some form of a graph data structure to illustrate the communication between nodes. For example, AlgoSenSim [7] is an non-stack, algorithmic-oriented simulator that is suitable for particular types of analysis, such as localization and flooding algorithms. Similarly, Shawn [8] emerges from

an algorithmic background. These approaches do not reproduce the ISO network stack, although Shawn does provide a slightly better, yet still simplistic MAC layer protocol. Since there is no explicit radio modelling, both AlgoSenSim and Shawn can simulate extremely large networks. The degree in which the results will faithfully represent the reality is very application-specific, but their advantage is that the development the applications is relatively easy. Medium-detail level simulators implement the lowest levels in a typical OSI network stack: Data Link and Physical Layers. Hence, it is common on these type of simulators to find implementations of 802.11b or newer MAC protocols and radio models that account for propagation, collision, fading, noise and wave diffraction. While the most popular wireline-targeted network simulator to date, ns2 [3], does not provide radio models specific to wireless sensor networks, a recent extension of it, Mannasim [9], attempts to fill this gap. Mannasim is a more detailed simulation framework that attempts to accurately model different sensor nodes. Mannasim, like SIDnet-SWANS, is written in Java which makes it platform independent, but the userlevel specification of different configurations’ values require additional efforts for writing on TCL scripts. GloMoSim [23] (now QualNet [10]) is another popular network simulator, written in PARSEC and relying on parallel computation in order to simulate high-fidelity communication models, while keeping the simulation time low. GloMoSim encodes, in a modular fashion, all the five network-stack components from the OSI model of the wireline networks, which allows the users to swap algorithms implemented at a particular layer independently of other layers which, in term helps achieve unbiased comparisons between various implementations. Both ns2 and Mannasim share an object-oriented architecture which, while easy to develop upon, negatively affects scalability of the network. A faster alternative, Castalia [11] which is based on the OMNet++ [15] platform is component-based designed, which also ensures better scalability. Castalia is also modular, allowing user to perform modifications to every stack layer. It provides realistic wireless channel and radio model, accentuating the behavior of a sensor node that attempts to access the radio. It also provides models for power consumption, clock drifts and physical phenomena. Sens [20] is a Java-based implementation of a simulator that relies, as Castalia on the component-based design principles. A distinct feature this simulator has is that it can execute application-layer code that was primarily written for a real sensor in a simulated environment by means of dedicated parsing libraries. It also includes a complex layout model with different types of surfaces that simulates the effects over the radio and sound signals. On the down side, Sens does not allow for changing of the low-level network stack protocols. High-detail targeted simulators take into account the computing power of a particular sensor’s hardware platform. Most often referred to as emulators, they model the CPU execution at the level of instructions or even cycles, achieving accurate estimates regarding both the time

Multi-Path Routing

Single-Path Routing

8

and memory demand of a given application. While these emulators can provide very accurate results, especially regarding timing analysis, they are also the most difficult to develop upon. Therefore, they are intended to be used as the last stage in an algorithmic design, just before predeployment, for debugging, fine tuning and validation of the expected behavior. TOSSIM [12] is the most representative, but not necessarily the most accurate, of the existing emulators. TOSSIM is specifically designed for the TinyOS/Mica Motes; applications codes, written for Mica motes can be used in TOSSIM without modification. However, due to performance reasons, TOSSIM considers all the nodes identical from the perspective on the code they execute, thus limiting the scope of the emulator to homogeneous when targeting the scalability. The communication between nodes is modelled through a probabilistic graph which, as side-effect, may reduce the overall accuracy of this tool. As opposed to TOSSIM, ATEMU [18] is an emulator that can run nodes with distinct application codes at the same time. For this reason, ATEMU is much more accurate, but its scalability is limited. AVRORA [21] is a newer Jave-based emulator that attempts to balance the pros and cons of the former two emulators. Being written in Java, it also benefits from the added portability across various computing platforms. Lastly, EmStar [4] relies on real sensors to collect environment data, lacking an environment model. Also, it performs partial emulation, partial simulation tasks and it can be used to develop code for Mica2 motes. What distinguishes the SIDnet from the simulators above is that its main target is to provide an extensible platform for simulation-based analysis of several parameters of interest for the evolution of a sensor network under a particular application scenario, at levels of granularity selected by the end-user. A simulator that is similar in spirit to SIDnet, but whose focus is, in a sense, complementary, is the VisualSense [1] – a modelling and simulation framework for wireless and sensor networks that builds on and leverages Ptolemy II. It provides an extensible visualization framework and the (customized) nodes and their behavior can be defined in Java. The framework supports a component-based construction of nodes, wireless communication channels, physical media such as acoustic channels, as well as wired subsystems. VII. Concluding Remarks We presented the SIDnet-SWANS – a Java-based extensible implementation of an application-centered exploratory simulator for wireless sensor networks, which enables various interactions between the end-users and different entities of interest in the network: from an individual packet/node, through the manipulation of the phenomena under observation and the deployment, through the high-level specifications of queries and routing structures. SIDnet-SWANS is built on top of the JiST-SWANS simulator, greatly enhancing its capabilities for performing various kinds of (hypothetical) reasoning about the evolution

of the entities of interest in a particular sensor networks’ application. There are several immediate extensions of the SIDnet that we are planning to address. Firstly, we will attempt to incorporate the Declarative Networking paradigm [13] as part of the simulator. Secondly, we are investigating the possibilities of integrating the SIDnet with some fine-grained simulation environment which provides a highlevel visual interaction tools for the users (c.f. [1]) References
[1] P. Baldwin, S. Kohli, E.A. Lee, X. Liu, and Y. Zhao. Visualsense: Visual modeling for wireless and sensor network systems. Technical Report UCB/ERL M05/25, University of California, Berkeley, 2005. http://ptolemy.berkeley.edu/visualsense/. [2] Rimon Barr, Zygmunt J. Haas, and Robbert van Renesse. Jist: an efficient approach to simulation using virtual machines. Softw., Pract. Exper., 35(6):539–576, 2005. [3] Ole-Johan Dahl and Kristen Nygaard. Simula - an algol-based simulation language. Commun. ACM, 9(9):671–678, 1966. [4] Lewis Girod, Jeremy Elson, Alberto Cerpa, Thanos Stathopoulos, Nithya Ramanathan, and Deborah Estrin. Emstar: A software environment for developing and deploying wireless sensor networks. In USENIX Annual Technical Conference, General Track, pages 283–296, 2004. [5] Abdelhakim Hafid, Abdelilah Maach, and Jawad Drissi. A distributed advance reservation system for interconnected slotted optical networks: Design and simulations. Computer Communications, 30(5):1142–1151, 2007. [6] http://jist.ece.cornell.edu/. [7] http://tcs.unige.ch/doku.php/code/algosensim/overview. [8] http://shawn.sourceforge.net/. [9] http://www.mannasim.dcc.ufmg.br/. [10] http://www.scalable-networks.com/. [11] http://castalia.npc.nicta.com.au/. [12] Philip Levis, Nelson Lee, Matt Welsh, and David E. Culler. Tossim: accurate and scalable simulation of entire tinyos applications. In SenSys, pages 126–137, 2003. [13] Boon Thau Loo. The Design and Implementation of Declarative Networks. PhD thesis, EECS Department, University of California, Berkeley, Dec 2006. [14] S. Madden, M.J. Franklin, J.M. Hellerstein, and W. Hong. Tinydb: An acquisitional query processing system for sensor networks. ACM TODS, 30(1), 2005. [15] C. Mallanda, A. Suri, V. Kunchakarra, S. S. Iyengar, R. Kannan, and A. Durresi. Simulating wireless sensor networks with omnet++. In 2nd International Conference on Mobile Technology, Applications and Systems, 2005. [16] Amit Manjhi, Suman Nath, and Phillip B. Gibbons. Tributaries and deltas: Efficient and robust aggregation in sensor network streams. In SIGMOD Conference, pages 287–298, 2005. [17] Peter Pham. Performance analysis of reactive shortest singlepath and multi-path routing mechanism with load balance. In INFOCOM, 2003. [18] Jonathan Polley, Dionysys Blazakis, Jonathan McGee, Dan Rusk, and John S. Baras. Atemu: A fine-grained sensor network simulator. In Proceedings of IEEE SECON’04, 2004. [19] W. Stallings. Wireless Communication and Networks. Pearson, Prentice Hall, 2005. [20] Sameer Sundresh, WooYoung Kim, and Gul Agha. Sens: A sensor, environment and network simulator. In Annual Simulation Symposium, pages 221–, 2004. [21] Ben Titzer, Daniel K. Lee, and Jens Palsberg. Avrora: scalable sensor network simulation with precise timing. In IPSN, pages 477–482, 2005. [22] R.S. Trivedi. Probability and Statistics with Reliability Queuing and Computer Science Applications. John Willey, 2002. [23] Xiang Zeng, Rajive Bagrodia, and Mario Gerla. Glomosim: A library for parallel simulation of large-scale wireless networks. In Workshop on Parallel and Distributed Simulation, pages 154– 161, 1998.