WSNGE: A Platform for Simulating Complex Wireless Sensor NetworksSupporting Rich Network Visualization and Online Interactivity1

Marios Karagiannis 2, Ioannis Chatzigiannakis 3 and Jose Rolim 2

2 Centre Universitaire d’ Informatique, Geneva, Switzerland. E-mail: {marios.karagiannis,jose.rolim}@unige.ch3 Research Academic Computer Technology Institute (CTI) and University of Patras, Greece. E-mail: ichatz@cti.gr

Keywords: Wireless Sensor Networks, Multiprotocol simu-lation, Network Visualization

AbstractIn this paper we describe a new simulation platform for com-plex wireless sensor networks that operate a collection of dis-tributed algorithms and network protocols. Simulating suchsystems is complicated because of the need to coordinate dif-ferent network layers and debug protocol stacks, often withvery different interfaces, options, and fidelities. Our platform(which we call WSNGE) is a flexible and extensible environ-ment that provides a highly scalable simulator with uniquecharacteristics. It focuses on user friendliness, providing ev-ery function in both scriptable and visual way, allowing theresearcher to define simulations and view results in an easyto use graphical environment. Unlike other solutions, WS-NGE does not distinguish between different scenario types,allowing multiple different protocols to run at the same time.It enables rich online interaction with running simulations,allowing parameters, topologies or the whole scenario to bealtered at any point in time.

1. INTRODUCTIONA particularly promising and hot research area has been

the design and analysis of wireless sensor networks (WSN),which has attracted researchers from very different back-grounds, such as hardware, software, algorithms, and datastructures, as well as researchers from various application ar-eas. Advancements have been made in the physical hardwarelevel, embedded software in the sensor devices, systems forfuture sensing applications and fundamental research in newcommunication and networking paradigms. Although theseresearch attempts have been conducted in parallel, in mostcases they were also done in isolation, making it difficult toconverge towards a unified global framework. We envisionthat future research on wireless sensor networks will exploitits theoretical and practical dimensions in parallel.

From a practical point of view, a joint approach of con-ducting research that combines both theory and practice mustovercome considerable difficulties. Still, even if all skills

1This work has been partially supported by the IST Programme of the Eu-ropean Union under contract number IST-2005-15964 (AEOLUS) and ICT-2008-224460 (WISEBED)

from all diverse specialties are acquired, the cost of settingup and maintaining an experimental facility of significantsize can be very high. Deploying the experimental networkinto a realistic environment requires iteratively reprogram-ming dozens of nodes, positioning them throughout an arealarge enough to produce an interesting radio topology, and in-strumenting them to extract performance data. This may havecontributed to the fact that only few of these networks haveyet been deployed [23, 19, 13].

An alternative to experimenting with actual sensor net-works in order to validate and evaluate the performance of ap-plications is software simulation. Simulators provide a num-ber of advantages over real world deployments, such as, e.g.,the ability to test a great variety of parameters in protocolsand deployment settings, including repeatable scenarios, iso-lation of parameters, exploration of a variety of metrics andease of development by leaving out all the details of deploy-ing a real testbed. Currently, a number of simulators havebeen developed, most notable examples are ns-2 [14], OM-NeT++ [15], OPNET Modeler [3], GTNetS [2], YANS [12]and Shawn [10].

Even though most simulators provide the basic frameworkrequired to simulate a generic wireless network, in the contextof wireless sensor networks, more facilities are required toproduce realistic simulation scenarios that capture real worlduses of these networks. For example, in real world scenariosit is uncommon for nodes to communicate without restric-tions inside the network area, but still obstacle modeling andsimulation is absent from most simulators. Even when con-sidering wireless sensor networks, where several models as-sume nodes are prone to errors and hardware failures, there isusually no clearly defined functionality to model failures. Wenote that the largest part of the research papers which dealwith such networks, and use simulation as an analysis tool,make a lot of simplifying assumptions to reduce the overallsimulation complexity, be it in the simulation setup, the sim-ulation scenarios, or the simulator used itself. Such oversim-plifications are often required in order to conduct experimentswith a great number of nodes in reasonable time, but most fre-quently they are imposed by the lack of functionality in thesimulation tools. In this way the credibility of such researchworks is weakened. An analytic and meaningful discussion ofcommon pitfalls and shortcomings in the simulation of wire-less networks in general is included in [9] and [11].

1.1. Motivation & Our ContributionIn this paper we present WSNGE, a simulation platform,

for the implementation, simulation, and evaluation of com-plex wireless sensor networks. WSNGE allows the simula-tion of multiple distributed algorithms that are executed con-currently on the nodes of the system and that are combinedin order to implement the desired application. It focuses onproviding a rich interface to monitor the execution of the sys-tem and interact with the system state during the simulation.The design goals of the WSNGE environment are to allow theprotocol designer to create his own environment, to programin a natural style, very similar to the style of programmingfor the final real-world application, to be of substantial helpto the application designer by providing means to monitor theexecution of the system and to extract detailed statistical in-formation, to be used both as a tool for experimental analysisand for demonstration or educational purposes, be easy to ex-tend or integrate in other systems, to be efficient and easy touse and, finally, to be able to produce realistic simulation sce-narios for wireless sensor networks.

Many systems (e.g., ns, Shawn) provide animations of thesimulated system based on system traces extracted during thesimulation. They are only animated visualizers and don’t pro-vide simulation capabilities. For this purpose WSNGE in-cludes a GUI that can be used to monitor aspects of the sim-ulation in real time. This feature is quite important since itallows to pause the simulation, make changes and resume thesimulation in order to measure the effect of certain events onthe robustness of the algorithm. The protocol designer is ableto interact with the simulation while the experiment is stillongoing, introducing obstacles, packets, new topologies andnew properties. To the extent of our knowledge, the existingsolutions provide poor or no interaction with running simu-lations whatsoever. The GUI includes modules for designingthe topology, constructing scenarios and viewing statistics. Apowerful feature of WSNGE is that it provides multiple view-ports of the same simulation with customizable informationdisplayed on each, both to avoid clutter and to focus on cer-tain aspects of the execution, making it an ideal platform fordemonstration or educational purposes.

Another limitation of most of the available systems is thatthey offer a generic simulation environment, while our so-lution focuses on Wireless Sensor Network simulation. WS-NGE provides a set of tools that make WSN simulation eas-ier. It also provides WSN specific features like communica-tion obstacles or battery life by default. We note that veryfew simulation platforms exist that are specialized in wirelesssensor networks, most notable examples are AlgoSenSim [1]and TRAILS [4].

Another primary concern is to provide an open systemthat can be used as a scenario editor, online monitoring andpresentation tool for other platforms. To support these func-

Simulator Type Size (# Nodes) Visualizationns-2/NAM Generic 103 OfflineShawn Generic 106 OfflineOMNeT++ Generic 102 OfflineDAP/ADAPT Generic 103 OnlineWSNGE WSN 105 Online

Table 1. Simulator characteristics

tionalities, WSNGE has a very flexible modular architecturewhere components have very low coupling so that they canbe easily removed and replaced by external ones in order tocome up with customized simulation platforms.

The use of WSNGE is rather intuitive and does not distractthe developer from the main task, which is the design, devel-opment and testing of the algorithm.

2. PREVIOUS WORKIn this section we review four, of what we believe to be

important representatives, software solutions that provide vi-sualization for network topologies. Each network visualizerapproaches the task with interesting ideas and innovations butat the same time retains its own philosophy. In Table 1 we at-tempt to classify these simulators based on their characteris-tics and capabilities.

2.1. Nam, the VINT Network AnimatorNAM’s [8] philosophy is to provide a detailed animation

of the execution of the algorithm in test. It uses the tracefiles provided by other simulation environments (such as NS)to render a fully interactive animated representation of dataflows, connections and network layout. NAM is only an an-imated visualizer and does not provide any simulation capa-bilities. It does however include tools for constructing sim-ulation scenarios and extract them so that external tools canrun them.

By using the time-indexed events from the trace files, NAMcan provide offline re-runs of simulations. Online visualiza-tion is also possible using UNIX pipes as input. By tak-ing advantage of the network properties descriptions, NAMprovides its core feature, which is packet animation. Usinggraph layout drawing algorithms, it represents the physicalproperties, such as latency and bandwidth of links, and an-imates packets on the edges. The resulting animated graphscan be interacted with, providing extra information and statis-tics about their elements (packets, edges, nodes etc.).

Nam’s scenario creation and editing capabilities consist ofthe scenario input facility which produces ns scripts for ns toexecute and the usage of Nam as a visualizer during NS’s sce-nario generation. The thing to note here is that Nam’s visual-ization capabilities are restricted to relatively small scenarios

(roughly up to 100 nodes) while support for large networktopologies scenarios is future work.

2.2. ShawnShawn [10, 18] is a discrete event simulator that focuses

on large scale network simulations. Its philosophy is to usea higher level simulation model, that focuses on the algo-rithmic interesting part of a simulation, which is the effectsof the execution of the algorithm as opposed to simulatingall the mechanisms that lead to this effect. Shawn uses ab-stract and exchangeable models for lower level effects, likecommunication and transmission models instead of simulat-ing every such effect in the most realistic way. This techniqueallows Shawn to run large scale experiments in a fraction ofthe time that would take similar simulators for the same ex-periments. By simulating the effects, Shawn allows the re-searcher to easily prototype algorithms rapidly, by develop-ing the higher level functionality. By exchanging the lowerlevel models, behaviour can be tested for different but similarcases.

Shawn’s visualization features are plain. It mainly uses anexternal tool called Vis [22] to provide visualizations of dis-creet time instances of the simulation, including drawing ofnodes and edges. Each visualized instance is recorded to PNGor PDF files. The nodes are the main component and repre-sent the network processors. They have a customizable ap-pearance in color, size and are generated automatically uponexecution. Edges represent the communication connectionsbetween nodes and are not generated automatically.

2.3. OMNeT++OMNeT++ [15, 21] is a discreet event simulator. Because

of its open architecture, OMNeT++ has been used not onlyfor network simulations but also for IT systems, queuing net-works, hardware architectures and business processes. It pro-vides an extensive GUI as well as command line options.OMNeT++’s philosophy is to provide a highly distinctiveseparation between the components of the simulation envi-ronment, so that frameworks for a very broad spectrum ofapplications can be introduced. Following this, OMNeT++is being comprised by the simulation kernel, a compiler forit’s own topology description language (NED) [20], GUI andcommand line interfaces, vector plotting and scalars visual-ization tools, model documentation tools and other miscella-neous utilities.

NED is OMNeT++’s topology description language whichcan describe parameterized regular structures, using for ex-ample multiple or conditional connections. In this way, OM-NeT++ can provide structures that are not characterized byfixed interconnection or fixed number of elements. Using thisproperty, the system can avoid executing multiple simulation

runs for similar model topologies. NED also offers the flexi-bility to describe the topology using parameters.

The system’s vector plotting and scalars visualization toolsconsist of Plove[16] and Scalars[17]. Plove is a tool to plotand analyze OMNeT++ output vector files. It provides plot-ting specific options like drawing style and smoothing an canoutput in various image format files. Scalars is a tool that alsouses OMNeT++ output scalar files to draw bar charts and x-yplots. It also supports output in various image format files.

2.4. DAP/ADAPTDAP/ADAPT [5, 6, 7] stands for Advanced Distributed Al-

gorithms Platform and Testbed. Its main goals are to providea platform which allows the user to develop algorithms in acommon and well known programming language, algorithmswhich can be used in both simulation and real-world deploy-ment, to support heterogeneous simulation environments andto be open and extensible for new application domains. InADAPT every simulated process is actually implemented asa “real”, in the operating system sense, process. Each processcommunicates through the ADAPT client library to a centralcore, called Engine that manages the simulation and providesthe relevant functionality.

The Engine performs the simulation processing itself. Itfollows the discreet event simulation model thus its centralmodule is an event queue handler. All actions are transformedto discreet events by the system and then fed to the queuefor handling. Actions can originate from the processes or theGUI. The Engine also handles metrics and statistics.

The GUI that is provided with the system allows real timemonitoring of the simulations, and is a completely differentexecutable than the Engine itself, communicating with it us-ing TCP/IP. This allows running the simulations in powerfulmachines while monitoring from one or more less powerfulones. ADAPT supports the creation of customized environ-ments and complex simulation scenarios involving dynamicevents (e.g., node failures, obstruction of node movement,etc.). Scenarios definitions in the mobility, obstacles and fail-ures domain can be defined with time-specific actions that canbe replayed at any time in the exact same way. The same pro-tocol is used for scenarios that come from the GUI or fromscenario files that can be loaded at any time.

3. ARCHITECTUREHere we describe the architecture of WSNGE in greater

detail. Its main functional components are its graphical userinterface, the scripting engine and its internal simulation en-gine. Figure 1 shows the general architecture design and theinteraction of the components. The choice of the optional ex-ternal simulation engine or the integrated internal simulationengine is up to the researcher, depending if one wants to useWSNGE as merely a scenario editor, online manipulation and

monitoring tool for an external simulation framework (suchas Shawn) or as a complete simulation package.

Figure 1. The High-level Architecture

In the integrated internal simulation engine, the communi-cation between nodes takes place using data buffers. The sim-ulation engine uses discreet time units, which we call epochs,to distinguish time slots where actions take place. Epochsare essentially iterations (i.e., rounds), which are completedwhen all active nodes in a network complete their respectiveactions. These actions can be queue processing for receivingdata packets sent in the previous epoch, environment sensingor timed events. Within each epoch, each node processes itsown data buffer queue until it is emptied. For each data packetinjection, and depending on the algorithm used, none, oneor more transmissions may occur from this node. The act oftransmitting is equivalent to filling one slot of the destinationnode’s packets buffer with a data packet. Apart from packetqueue processing, events like sensing take place within eachnode’s turn in the epoch. The simulator uses precalculatedcommunication graphs, while applying real-time failures cal-culations, in order to speed up the simulation process.

Nodes attach themselves to predefined communicationmodels (depending on the physical layer we wish to sim-ulate) during the construction of the communication graph.Communication models include the Unit Disc Graph withfixed radius R or more realistic irrational graphs with the ra-dius R varying randomly from R1 to R2 where R1 < R2. Inthe same way, each node can attach to a mobility model thatenables its location to be altered each epoch following themodel’s behavior. While the default model is a dummy staticmodel, other models can include random walk, circular or spi-ral walks or predefined paths.

3.1. Internal data abstractionEach node is equipped with a packet buffer which can fill

up with data packets that are either received by neighboringnodes or injected by the user. Each data packet is generic andcan contain information about different functionality. For ex-ample, localization packets contain information about the an-chor’s location and localization algorithm while a geographicrouting packet may contain the destination location. Packets

Figure 2. Two Interacting Simulated Entities

can be injected at any time using any of the available meth-ods. Using the GUI it’s also possible to view the buffer of anynode at any given moment. The system does not distinguishbetween different scenario types while running the simula-tions. This means that at any time, just like in real testbeds,different kind of packets can be moving through the network,without them having to have any sort of compatibility be-tween them, assuming that the software on the nodes knowshow to handle each of them. In practice, this approach pro-vides the researcher with a valuable tool, namely the abilityto run multiple protocols on the same network at the sametime, in order to directly compare their performances. Forexample, a number of different geographic routing protocolswhich share the same source and destination can be executedon the network and allowed to run step by step, allowing inturn the researcher to examine the difference in their behav-ior, without having to run the same simulation multiple timesfor each protocol. This is particularly useful, when used withthe multiple views system (described in more details in thenext section), for demonstration and presentation purposes.

3.2. Obstacles and faultsWe feel that an important part of wireless sensor network

simulation is shaping the network topology in a more naturalway by introducing obstacles. Obstacles are categorized intwo main categories. The first category is network areas thatcontain few or no nodes at all. These areas act like obstaclesonly when their border nodes have communication rangesthat do not allow them to transmit over the gap. The secondcategory is explicit obstacles that consist of line segmentsand can form various shapes like lines, triangles or circles.This type of obstacles do not allow communications to passthrough them, so any part of the communication graph thatcrosses these lines segments is discarded. They also supportmobility and toggling. Another important feature of WSNGEis the ability to fine tune the effect of faults both in commu-nications and in other functions of the nodes, such as sensingcapabilities, power leakage or total failure. This is optional,

so algorithms can be tested in an ideally functioning environ-ment, or in a more realistic one which includes the possibilityof failures. Failures are normally expressed by a probability[0 . . .1] for each action that represents the success rate. Theprobability can be set in the beginning to a fixed value andcan change during the course of the simulation, in order tosimulate effects like gradually failing nodes.

4. THE GUI AS A MONITOR AND AN ON-LINE INTERACTOR

A central goal of WSNGE is to provide the researcher away to interact with the experiment online and directly. Alloperations are easy to control and initiate by simple combina-tions of keyboard and/or the mouse. Having this in mind, thesystem provides easy to use ways to manipulate the simulatedenvironment, both during the setup and while the simulationis evolving. In fact, our system does not even distinguishesthese phases.

Defining the topology of the network is simple and can bedone with many different ways, depending on the situation.Individual nodes can be inserted in specific positions by usingthe mouse and keyboard shortcuts. If automatic deployment iswhat the user requires, uniform deployment of a given num-ber of nodes in the whole area or in a specified area (againusing intuitive GUI) is as easy as choosing the correspondingaction from a menu.

The GUI of our system can be used in conjunction withthe internal provided simulation engine or with external sim-ulation solutions. In the later case, the GUI can be used asa powerful topology and scenario editor for simulating ex-periments in third party frameworks, like Shawn and Algo-SenSim. The interface can be either on-line or off-line (us-ing exported Shawn scripts). The functionality that is avail-able for each external simulation engine depends on the en-gine itself. Engines that do not support obstacles within theirsimulation, obviously will not benefit from the obstacles pro-vided by WSNGE. A certain level of compatibility must existbetween our platform and the external simulator, with spe-cific elements being omitted when data cannot be exchanged(for example, if the external simulation does not support ob-stacles). The GUI provides a way to open multiple views ofthe running network. Each view window can provide differ-ent kind of information about the current network state, likeGabriel planarized subgraphs or connection subgraphs. Whilethe main view is used for interaction, the other views can beused to examine the behavior of protocols or to focus on spe-cific data.

5. SCRIPTINGWSNGE provides more than the GUI method to perform

actions. Every single action can be performed in two moreways. The first way is using the GUI command line, which

can accept command by command a description of eachaction. For example, instead of inserting a node using themouse, the user can insert the command InsertAt 0.50.5 effectively inserting a node at the desired position. Thesame goes for all functionality of the GUI. Commands can beentered at any time during the simulation lifetime. The sec-ond way is using script files. These are simple text files thatconsist of commands and comments. The commands are ex-ecuted sequentially until the end of file. An important func-tionality option is that a command can execute an externalscript file, both at the command line and within scripts, pro-viding a way to better organize scripting. In this way, onescript file can be about deployment while a second one whicheffectively can include the first one can be the simulation sce-nario description and execution. Organization is up to the re-searcher, so separating obstacles placement and node place-ment for example in different files, so that each can be reusedseparately, is perfectly possible. Because every aspect of thenetwork description and scenario can be defined using scriptcommands, exporting the situation status is being done us-ing the scripting system itself. The system allows exportingin script files, which consist of commands that when rerun,will restore simulation state. This way, the researcher can editthese files to fine tune the scenarios, or create similar scenar-ios.

6. CASE STUDYTo demonstrate the capabilities of the WSNGE, we now

show how easy and straightforward it is to simulate a wirelesssensor network comprised of 5000 nodes. We wish to simu-late an indoor network where nodes will use a localizationalgorithm to acquire positioning information and use a datapropagation protocol that utilizes the virtual coordinates.

In order to develop a new protocol, the researcher must de-velop a function that implements the core functionality of thealgorithm as well as its supporting data structures (e.g., nodedata structure) and link it to the GUI. Within the function,packet sends can take place if needed, since the function hasaccess to the global data structures of the network. For ourcase study, in order to develop a new localization algorithm,the node data structure must be altered to include incominglocalization packets count, and the function must describe themechanism according to which localization packets will begenerated and sent when each node becomes an anchor, oreven before that (depending on the algorithm).

For the setup of the network we will use a simple script file,namely network-simple.txt (see listing 1). It creates anetwork of 5000 nodes, with size 1 x 1 units, using a specificrandom seed (making the process repeatable) and creates thecommunication graph for the network using a communicationrange of 0.1 units.

To initiate an algorithm, the researcher must inject the ap-

Figure 3. The Main Simulation Window

propriate packets or set up the conditions for the algorithmto begin. Based on the controls of Figure 4, in order to ini-tiate a Greedy geographic routing algorithm, the steps thatmust be followed are: select the Geo tab, select Greedy algo-rithm from the Geographic Routing drop down menu, selectthe source node (by using the mouse to select the actual nodefrom the network), click source, select the destination (againby selecting the actual node from the network), click destina-tion and click init.

Listing 1. Script for simple network definitions eed 1024 / / Change t h e random seedi n s e r t 5000 / / P o s i t i o n 5000 nodes u n i f o r m l ys e l e c t a l lr a d i u s 0 . 1 / / S e t communica t ion ranged i s c o v e r / / Cr ea t e communica t ion graph

At this moment, a greedy geographic routing packet hasbeen injected to the source node, that contains all the neces-sary information to run the algorithm as well as some statis-tics(source node, destination location, hop count). By click-ing Next Epoch the algorithm will forward all relevant packetsand increase the epoch. By clicking Run Until Completion,the algorithm will run until all packets have been delivered tothe destination or they fail to do so.

To run a localization algorithm, the researcher does notneed to inject packets, because a newly localized node willdecide, depending on the algorithm, to generate its own lo-calization packets. The steps one must follow are: select Lo-cal tab, select Greedy algorithm from the Localization Algo-rithms drop down menu, select anchor node(s) (by selectingthe actual nodes from the network), and finally click Local-ize. At this moment, by pressing Next Epoch or Run Until

Completion, the anchor nodes will generate the respective lo-calization packets and broadcast them. Each newly localizedanchor node will repeat this procedure until a set number ofepochs is reached, all nodes are localized or there are no morelocalization packets to send.

Figure 4. Controls for Controlling the Simulation

In order to insert obstacle segments by using the GUI, theresearcher must follow those steps: use the menu system toselect Obstacles, clock insert single (for a single line seg-ment) and drag the mouse to set the position of the obstacle.Alternatively, the researcher can use the console by inputing:obstacle 0.5 0.5 1 1 to create an obstacle between points(0.5,0.5) and (1,1).

An alternative to setup the scenario using the GUI is todefine a more detailed script file. We here use two scriptfiles, namely network-detailed.txt (see listing 2) andobstacles.txt (see listing 3) to describe some elementsof the network. These configuration file insert 3 nodes at spe-cific locations that are being localized, effectively makingthem the anchors for our localization algorithm testing. In thesecond file, 3 obstacles are introduced at specific locations.Finally, the first file resumes and creates the communicationgraph for the final network. The above procedure results inthe network shown in Figure 3.

Listing 2. Script for detailed network definitions eed 1024 / / Change t h e random seedi n s e r t 5000 / / P o s i t i o n 5000 nodes u n i f o r m l yi n s e r t a t 0 . 1 0 . 4 5 / / P o s i t i o n nodesi n s e r t a t 0 . 0 5 0 . 5 3 / / a t f i x e d p o i n t si n s e r t a t 0 . 1 5 0 . 5 3

l o c a l i z e 5000l o c a l i z e 5001l o c a l i z e 5002s e l e c t a l lr a d i u s 0 . 1s c r i p t o b s t a c l e s . t x t / / O b s t a c l e s s c r i p td i s c o v e r / / Cr ea t e communica t ion graph

Listing 3. Script for obstacle definitiono b s t a c l e 0 0 . 2 5 0 . 7 0 . 2 5

o b s t a c l e 1 0 . 5 0 . 3 0 . 5o b s t a c l e 0 0 . 7 5 0 . 7 0 . 7 5

The above simulation was run step by step observing ateach step the newly localized nodes for the purpose of thisexample. Alternatively, it could be run for a number of times,while providing little or no feedback. Notice that the same ob-stacles or network file can be reused separately, providing atool for testing algorithms in a very controlled configuration.The above screenshot shows the network after 11 epochs run-ning a simple greedy localization algorithm. In features twodisplays, one showing the full communication graph whilethe other shows a Gabriel Planarized subgraph.

Figure 5. Auxiliary Display showing a stage of localization

For demonstration purposes (e.g., in a classroom) we canhave multiple windows showing different information relatedto the execution of the simulation. For example, Figure 3shows a Gabriel Planarized subgraph of the network after 11epochs running a simple greedy localization algorithm. Thefull communication graph of the newly created anchors is dis-played in Figure 5.

In fact, the user is not limited to controling the simula-tor with one of the two methods; both can be combined. InFigure 6 we continue the scenario by introducing 4 obsta-cles (line segments) and extracted the Gabriel Planarized sub-graph of the network to allow the use of a geographic routingalgorithm that only works on planar graphs.

In Figure 7 we can view an instance of the network thatruns 8 geographic routing protocols at the same time. In thiscase, the protocols shared the same sink node. This is a simpleexample of how easy it is to compare different algorithms’behaviors on the exact same network, step by step.

Regarding the ability of WSNGE to simulate large in-stances of wireless sensor networks, we have repeated the

Figure 6. Gabriel subgraph of a network with obstacles

Figure 7. Executing 8 instances of the routing protocol

above experiment with larger number of nodes. In Table 2we include the execution time and memory usage of our sim-ulator when executed on a Quad core Q6600 (2.6 GHz) with64KB L1 cache, 8MB L2 cache and 4 GB of memory op-erating Windows Vista. It is evident that even for extremelylarge networks ([104 . . .105]) the execution time is less than aminute while the memory usage is less than 100 MB.

Size (nodes) Memory (KB) Time (ms) Mean Conn.1000 4948 514 28.8442000 5968 1061 29.9665000 9388 2449 30.7096

10000 14160 4712 27.597220000 23976 9781 24.661350000 57668 28096 30.38832100000 107200 54304 25.26202

Table 2. Running times and Memory usage of WSNGE

7. CONCLUSIONS AND FUTURE WORKWe presented the design and implementation issues of a

novel software platform, that especially enables the simula-tion of realistic application scenarios for wireless sensor net-works. The primary goal of our simulator is to allow the pro-tocol designer to interact with the simulation through a richgraphical interface. We strongly believe that this is a valuabletool that will help reduce the development cycle of applica-tions for such networks.

Currently, we are in the process of integrating our simulatorwith AlgoSenSim [1] and Shawn [10]. Furthermore, we planto refine the architecture of our framework, improve its gen-erality and enrich the library of implemented modules withmore realistic models.

REFERENCES[1] AlgoSenSim. URL: http://tcs.unige.ch/doku.php/algosensim.

[2] The Georgia Tech Network Simulator (GTNetS). URL:http://www.ece.gatech.edu/research/labs/MANIACS/GTNetS/.

[3] OPNET modeller, OPNET technologies, inc.http://www.opnet.com.

[4] Ioannis Chatzigiannakis, Athanasios Kinalis, Georgios My-lonas, Sotiris Nikoletseas, Grigorios Prasinos, and ChristosZaroliagis. Trails, a toolkit for efficient, realistic and evolvingmodels of mobility, faults and obstacles in wireless networks.In 41th Annual ACM/IEEE Simulation Symposium (ANSS’08),pages 23–32. ACM/IEEE, SCS, April 2008.

[5] Ioannis Chatzigiannakis, Athanasios Kinalis, A. Poulakidas,G. Prasinos, and C. Zaroliagis. DAP: A generic platform forthe simulation of distributed algorithms. In 37th Annual Sim-ulation Symposium (ANSS 2004), pages 166–177, 2004. IEEEPress.

[6] Ioannis Chatzigiannakis, Christos Koninis, Grigorios Prasinos,and Christos Zaroliagis. Distributed simulation of heteroge-neous systems of small programmable objects and traditionalprocessors. In 6th ACM Workshop on Mobility Managementand Wireless Access (MOBIWAC 08), pages 133–140. ACM,ACM, October 2008.

[7] Distributed algorithms platform homepage. http://ru1. cti.gr/LEP-DAP/.

[8] D. Estrin, M. Handley, J. Heidemann, S. McCanne, and H. Yu.Network visualization with Nam, the VINT network animator.IEEE Computer, 33(11):63–68, November 2000.

[9] D. Kotz, C. Newport, R. Gray, J. Liu, Y. Yuan, and C. El-liott. Experimental evaluation of wireless simulation assump-tions. In Proceedings of the ACM/IEEE International Sympo-sium on Modeling, Analysis and Simulation of Wireless andMobile Systems (MSWiM), 2004, pages 78–89, 2004.

[10] Alexander Kroller, Dennis Pfisterer, Carsten Buschmann,Sandor P. Fekete, and Stefan Fischer. Shawn: A new approachto simulating wireless sensor networks. In Design, Analysis,and Simulation of Distributed Systems (DASD05), pages 117–124, 2005.

[11] S. Kurkowski, T. Camp, and M. Colagrosso. MANET simula-tion studies: The incredibles. Mobile Computing and Commu-nications Review, 9(4):50–61, 2006.

[12] Mathieu Lacage and Thomas R. Henderson. Yet another net-work simulator. In WNS2 ’06: Proceeding from the 2006 work-shop on ns-2: the IP network simulator, page 12, New York,NY, USA, 2006. ACM Press.

[13] Koen Langendoen, Aline Baggio, and Otto Visser. Murphyloves potatoes: experiences from a pilot sensor network de-ployment in precision agriculture. In 20th International Par-allel and Distributed Processing Symposium IPDPS, page 8,2006.

[14] The network simulator – ns2. http://www. isi. edu/nsnam/ns/.

[15] The OMNeT++ simulation system. http://www.omnetpp.org/.

[16] Plove vector plotting tool.http://www.omnetpp.org/external/plove.php.

[17] Scalars visualization tool. http://www.omnetpp.org/external/scalars.php.

[18] Shawn. http://shawn.sf.net.

[19] Robert Szewczyk, Alan Mainwaring, Joseph Polastre, JohnAnderson, and David Culler. An analysis of a large scale habi-tat monitoring application. In 2nd international conference onEmbedded networked sensor systems SENSYS’04, pages 214–226, New York, NY, USA, 2004. ACM.

[20] Andras Varga. Parameterized topologies for simulation pro-grams. In Proceedings of the Western Multiconference on Sim-ulation(WMC’98) Communication Networks and DistributedSystems (CNDS’98), San Diego, CA, 1998.

[21] Andras Varga. The omnet++ discrete event simulation system.In Proceedings of the European Simulation Multiconference(ESM’2001), Prague, Czech Republic, June 2001.

[22] Vis. http://shawnwiki.coalesenses.com/index.php?title=Visualization.

[23] Pei Zhang, Christopher M. Sadler, Stephen A. Lyon, and Mar-garet Martonosi. Hardware design experiences in zebranet.In 2nd international conference on Embedded networked sen-sor systems SENSYS’04, pages 227–238, New York, NY, USA,2004. ACM.