1: \documentclass[12pt]{IEEEtran}
2: \usepackage{a4wide}
3: \usepackage{graphicx}
4: \usepackage{url}
5:
6: \begin{document}
7:
8: \title{Shawn: A new approach to simulating wireless sensor networks}
9:
10: \author{
11: \authorblockN{
12: A.~Kr{\"o}ller\authorrefmark{1},
13: D.~Pfisterer\authorrefmark{2},
14: C.~Buschmann\authorrefmark{2}},
15: S.~P.~Fekete\authorrefmark{1},
16: S.~Fischer\authorrefmark{2}
17: \\[1ex]
18: \authorblockA{\authorrefmark{1}
19: Institute of Mathematical Optimization,\\
20: Braunschweig University of Technology,\\
21: D-38106 Braunschweig, Germany,\\
22: E-Mail: \{a.kroeller,s.fekete\}@tu-bs.de\\[1ex]
23: }
24: \authorblockA{\authorrefmark{2}
25: Institute for Telematics,\\
26: University of L{\"u}beck,\\
27: D-23538 L{\"u}beck, Germany,\\
28: E-Mail: \{pfisterer,buschmann,fischer\}@itm.uni-luebeck.de
29: }
30: }
31:
32: \date{January 31, 2005}
33:
34: \maketitle
35:
36: \begin{abstract}
37: We consider the simulation of wireless sensor networks (WSN) using a
38: new approach. We present Shawn, an open-source discrete event
39: simulator that has considerable differences to all other
40: existing simulators. Shawn is very powerful
41: in simulating large scale networks with an abstract point of view.
42: It is, to the best of our knowledge, the first simulator to
43: support generic high-level algorithms as well as distributed protocols
44: on exactly the same underlying networks.
45: \end{abstract}
46:
47: \section{Introduction}
48: \label{sec:intro}
49: %
50: In recent times, the study of wireless sensor networks (WSN) has become
51: a rapidly developing research area that offers fascinating
52: perspectives for combining technical progress with new applications of
53: distributed computing. Typical scenarios involve a large swarm of
54: small and inexpensive sensor nodes, each providing limited computing
55: and wireless communication capabilities that are distributed in some
56: geometric region. From an algorithmic point of view, the
57: characteristics of sensor networks require the shift to a new paradigm
58: that is different from classical models of computation: The absence of
59: centralized control, limited capabilities of nodes and low bandwidth
60: communication between nodes require developing new algorithmic ideas
61: that combine methods of distributed computing and network protocols
62: with traditional centralized network algorithms.
63:
64: To acquire a deeper understanding of these networks, three
65: fundamentally different approaches exist: Analytical methods, computer
66: simulation, and physical experiments. Designing algorithms for sensor
67: networks can be inherently complex. Many aspects such as energy
68: efficiency, limited resources, decentralized collaboration, fault
69: tolerance, and the study of the global behavior emerging from local
70: interactions have to be tackled.
71:
72: In principle, experimenting with actual sensor networks would be a
73: good way of demonstrating that a system is able to achieve certain
74: objectives, even under real-world conditions. However, this approach
75: poses a number of practical difficulties. First of all, it is
76: difficult to operate and debug such systems. This may have
77: contributed to the fact that only very few of these networks have yet
78: been deployed \cite{mainwaring-habitat,analysisgdi2,zebranet}.
79: Real-world systems typically consist of roughly a few dozen sensor
80: nodes, whereas future scenarios anticipate networks of several
81: thousands to millions of nodes~\cite{estrinembed,atomiccomputing}.
82: Using intricate tools for simulating a multitude of parameters, it may
83: be possible to increase the real-world numbers by a couple of orders
84: of magnitude. However, the difficulty of pursuing this approach
85: obfuscates and misses another, much more crucial issue: Designing
86: highly complicated simulation tools for individual sensor nodes
87: resembles constructing a working model for individual brain cells.
88: However, like a brain is much more than just a cluster of cells,
89: realizing the vision of an efficient, decentralized and
90: self-organizing network cannot be achieved by simply putting together
91: a large enough number of sensor nodes. Instead, coming up with the
92: right functional structure is the grand scientific challenge for
93: realizing the vision of sensor networks. Understanding and designing
94: these structures poses a great number of algorithmic tasks, one level
95: above the technical details of individual nodes. As this understanding
96: progresses, new requirements may emerge for the capabilities of
97: individual nodes; moreover, it is to be expected that the technical
98: process and progress of miniaturization may impose new parameters and
99: properties for a micro- simulation.
100:
101:
102: \subsection{Motivation of this work}
103: \label{sec:motivation}
104: %
105: Consider the situation of developing localization algorithms.
106: Usually one is interested in the quality of the solution that is
107: produced by a specific algorithm. There is certainly some influence of
108: communication characteristics, e.g., because they may affect
109: transmission times and hence communication paths and loss. From the
110: algorithm's point of view, there is no difference between a complete
111: simulation of the physical environment (or lower-level networking
112: protocols) and the alternative approach of simply using well-chosen
113: random distributions on message delay and loss. This means that
114: using a detailed simulation may lead to the strange situation in which
115: the simulator spends much processing time on producing results that are of no
116: interest at all, thereby actually hindering productive research on the
117: algorithm.
118:
119: This is the central idea of the proposed simulation framework: By
120: replacing low-level effects with abstract and exchangeable models, the
121: simulation can be used for huge networks in reasonable time.
122: Section~\ref{sec:casestudy} shows the speedup that we achieve by
123: replacing the popular simulator Ns-2~\cite{ns-2} with our own
124: simulator Shawn~\cite{shawn}.
125:
126: Shawn is licensed under the GNU General Public License. It is
127: available for download at \url{http://www.swarmnet.de/shawn}.
128:
129: The rest of the paper is organized as follows:
130: Section~\ref{sec:related} categorizes available simulation tools that
131: cover the simulation of sensor networks. Section~\ref{sec:goals}
132: discusses the differences to the Shawn simulator presented in this
133: paper. The overall architecture of Shawn is presented in
134: Section~\ref{sec:arch}. Section~\ref{sec:casestudy} serves as an
135: example on how users can benefit from Shawn. In
136: Section~\ref{sec:conclusion} we summarize the scientific contributions
137: of our approach and the conclusions that can be drawn. In
138: Section~\ref{sec:future} we discuss our plans for further development
139: of the Shawn project.
140: %
141: %
142: %
143: \section{Related Work}
144: \label{sec:related}
145: %
146: The range of applications for simulation is rather broad and many
147: simulators have been developed in the past. Each of them targets a
148: specific application domain in which it can deliver best results. The
149: semantics of what is actually meant by the term ``simulation'' varies
150: heavily among researchers and publications, depending on the goals of
151: the simulations in question.
152:
153: This often results in the simulation of physical phenomena such as
154: radio signal propagation characteristics and ISO/OSI layer protocols,
155: e.g., media access control (MAC). Other approaches focus on algorithmic
156: aspects and they abstract from lower layers. The first approach delivers a
157: precise image of what happens in real networks and how the protocols
158: interact with each other at the cost of resource-demanding simulations,
159: leading to scalability problems. The latter type employs abstract
160: models of the real world, instead of simulating it down to the bit
161: level. Important questions are the analysis of the network structure
162: as well as the design and evaluation of algorithms (and not
163: protocols). We have coarsely categorized some of the most prominent
164: simulation frameworks according to the criteria of scalability and
165: abstraction level. Figure~\ref{fig:class} classifies the application area of these
166: simulators along two axes, showing abstraction level and number of
167: network nodes. Note that this does not express the maximal feasible
168: network sizes, but rather reflects the typical application domain. For
169: example, nearly every simulator can handle huge networks if the
170: connectivity is kept near zero, which does not help in choosing the
171: appropriate simulator for a given task.
172: \begin{figure*}[t]
173: \centering
174: \includegraphics[width=.6\textwidth]{fig-class}
175: \caption{Intended application area of simulators.}
176: \label{fig:class}
177: \end{figure*}
178:
179: We now give an overview of different simulators that are commonly used
180: for sensor networks.
181:
182: \paragraph{Ns-2~\cite{ns-2}}
183: The ``Network Simulator-2'' is a discrete event simulator targeted at
184: network research. It is probably the most prominent network simulator.
185: It includes a huge number of protocols, traffic generators and tools
186: to simulate TCP, routing, and multicast protocols over wired and
187: wireless (local and satellite) networks. Its main focus is the ISO/OSI
188: model simulation, including phenomena on the physical layer and energy
189: consumption models. Ns-2 features detailed simulation tracing and
190: comes with the simulation tool ``network animator'' (nam) for later
191: playback. It is available for free under an open source license.
192: Support for sensor network simulations has also been integrated
193: recently \cite{ns2sensors,sensorsim}, including sensing channels,
194: sensor models, battery models, lightweight protocol stacks for
195: wireless micro sensors, hybrid simulation support and scenario
196: generation tools. The highly detailed packet level simulations lead
197: to a runtime behavior closely coupled with the number of packets that are
198: exchanged, making it virtually impossible to simulate really large
199: networks. In principle, Ns-2 is capable of handling up to
200: 16,000 nodes, but the level of detail of its simulations
201: leads to a runtime that makes it hopeless to deal with more than 1,000
202: nodes. Ns-2's long
203: development path since 1989 has led to a vast repository for network
204: simulations but also reflects its downside: It has a steep learning
205: curve and requires advanced skills to perform a meaningful and
206: repeatable simulation. The diverse distributions of Ns-2 that are used by
207: research groups around the world complicate the comparability of
208: achieved results.
209:
210: \paragraph{OMNeT++ \cite{omnet++}}
211: The ``Objective Modular Network Testbed in C++'' is an object-oriented
212: modular discrete event simulator. Like Ns-2, it also targets the
213: ISO/OSI model. It can handle thousands of nodes and features a
214: graphical network editor and a visualizer for the network and the data
215: flow. The simulator is written in C++ for high performance and comes
216: with a homegrown configuration language ``NED''. OMNeT's main
217: objective is to provide a component architecture through which
218: simulations can be composed very flexibly. Components are programmed
219: in C++ and then assembled into larger components using NED. It is free
220: for academic purposes, a commercial license is also available.
221:
222: \paragraph{GloMoSim \cite{GloMoSim}}
223: The ``Global Mobile Information Systems Simulation Library'' is a
224: scalable simulation environment for wireless and wired network
225: systems. It is modeled on the ISO/OSI principle using a layered
226: design. Standard APIs are used between the different simulation
227: layers (Application, Transport, Network, Data Link, Packet Reception
228: Models, Radio Model, Radio Propagation and Mobility). Though
229: potentially designed for simulations with 100,000 nodes, just 5,000
230: nodes already lead to runtimes of about an hour on a single machine.
231: However, support for parallel execution is provided. The simulator is
232: built on top of Parsec~\cite{Parsec}, which provides the parallel
233: discrete event simulation capabilities. Though also designed for
234: wired networks, GloMoSim currently supports only protocols for the
235: simulation of purely wireless networks.
236:
237: \paragraph{SENSE \cite{SENSE}}
238: This is a simulator specifically developed for the simulation of
239: sensor networks. It offers different battery models, simple network
240: and application layers and a IEEE 802.11 implementation. With regard
241: to scalability, the authors plan to enable SENSE to allow for
242: parallelization in the future. In its current version, SENSE comes
243: with a sequential simulation engine that can cope with around 5,000
244: nodes, but depending on the communication pattern of the network this
245: number may drop to 500. The authors identify extensibility,
246: reusability and scalability as the key factors they address with
247: SENSE. Extensibility is tackled by avoiding a tight coupling of
248: objects by introducing a component-port model, which removes the
249: interdependency of objects that is often found in object-oriented
250: architectures. This is achieved by their proposed ``simulation
251: component classifications''. These are essentially interfaces, which
252: allows exchanging implementations without the need of changing the
253: actual code. Reusability on the code level is a direct consequence of
254: the component-port model.
255:
256: \paragraph{TOSSIM \cite{TOSSIM}}
257: The ``TinyOS mote simulator'' simulates TinyOS~\cite{TinyOS} motes at
258: the bit level and is hence a platform-specific simulator/emulator. It
259: directly compiles code written for TinyOS to an executable file that
260: can be run on standard PC equipment. Using this technique, developers
261: can test their implementation without having to deploy it on real
262: sensor network hardware. TOSSIM can run simulations with a few
263: thousand virtual TinyOS nodes. It ships with a GUI (``TinyViz'')
264: that can visualize and interact with running simulations. Just
265: recently, PowerTOSSIM~\cite{PowerTOSSIM}, a power modeling extension,
266: has been integrated into TOSSIM. PowerTOSSIM models the power consumed
267: by TinyOS applications and includes a detailed model of the power
268: consumption of the Mica2~\cite{Mica2Mote} motes.
269:
270: \paragraph{BOIDS}
271: In the context of the BOIDS project~\cite{boidsproject}, a number of
272: simulation and visualization tools have been developed. BOIDS reaches
273: back to 1987 and studies the global behavior of a group of mobile
274: individuals emerging from their local interaction. The authors model
275: reciprocity as so-called steering behaviors \cite{reynolds99steering},
276: an abstract concept similar to attractive and repelling forces.
277: However, these tools must be considered visualizers for bio-inspired
278: agent behavior, rather than full-scale network simulators.
279:
280: The crucial point of the above listing is that each of the
281: simulators has its area of expertise in which it excels.
282: Unfortunately, none of these areas happens to be high-level protocols
283: and abstract algorithms in combination with the speed to handle large
284: networks. This is the gap that is filled by Shawn.
285:
286: \section{Shawn Design Goals}
287: \label{sec:goals}
288: %
289: Shawn differs in various ways from the other simulators. The most
290: notable difference is the focus of interest that is covered. Shawn does
291: not try to compete with the other simulators in the area of network
292: stack simulation: As already described, we do not believe that this is
293: a fruitful approach for the evaluation of protocols and algorithms for
294: wireless sensor networks. The behavior of the network as
295: a whole should be modeled in a way that allows for the needed
296: performance and development speed. Our main focus is to support the
297: steps that are necessary in order to achieve a complete protocol
298: implementation. For this purpose, various algorithmic
299: preliminary considerations are necessary.
300:
301: The following subsections discuss several aspects in which Shawn
302: differs significantly from other existing simulation frameworks by
303: pointing out the main design paradigms of Shawn.
304:
305: \subsection{Simulating the effects}
306: \label{sec:simeffects}
307: %
308: One central approach of Shawn is to simulate the effect caused by a
309: phenomenon, not the phenomenon itself. For example, instead of
310: simulating a complete MAC layer including the radio propagation model,
311: its effects (i.e., packet loss and corruption) are modeled in Shawn.
312: This has several implications for simulations: They get more
313: predictable and meaningful, and there is a huge performance gain,
314: because such a model can often be implemented very efficiently. This
315: also results in the inability to come up with the detail level that,
316: say, Ns-2 provides with respect to physical layer or packet level
317: phenomena.
318:
319: We are convinced that modeling network characteristics,
320: such as increased packet loss triggered by high traffic, yields
321: equivalent results compared to calculating possible congestion for
322: single packets, while offering a number of advantages.
323: For example, when using a simplified communication model in
324: simulations of a localization algorithm, the quality of solutions is
325: only slightly affected. On the other hand, running times are not
326: comparable at all.
327:
328: This distinction is the underlying paradigm of our large-scale
329: high-speed simulation environment: It makes sense to simplify the
330: structure of some low-level parameters: Their time-consuming
331: computation can be replaced by fast simulation, as long as the
332: interest in the large-scale behavior of the macro-system focuses on
333: unaffected properties.
334:
335:
336:
337:
338: \subsection{Simulation of huge networks}
339: \label{sec:hugenets}
340: %
341: One direct benefit of the above paradigm is superior
342: scalability. Visionary scenarios anticipate networks with a huge
343: number of individual nodes. It is to be expected that these networks will
344: consist of potentially millions of nodes
345: \cite{estrinembed,atomiccomputing}, so a simulator must be capable
346: of operating with that many nodes. One critical issue in
347: designing Shawn was to support node numbers orders of magnitudes higher
348: than the currently existing simulators. We have successfully
349: run simulations on standard PC equipment with more than 100,000 nodes.
350:
351: \subsection{Supporting a development cycle}
352: \label{sec:/dev/cycle}
353: %
354: Shawn inherently supports the development process with a complete development
355: cycle, beginning at the initial idea, ultimately leading to a fully
356: distributed protocol. In the following the complete development cycle
357: of simulations using Shawn is depicted, with
358: each step being optional.
359:
360: Given a first idea for an algorithm, it is natural to assume that the
361: next step is not to design some protocol, but to perform a structural
362: analysis of the problem at hand. To get a better understanding of the
363: problem in this first phase, it may be helpful to look at some example
364: networks and analyze the network structure and underlying graph
365: representation.
366:
367: In order to achieve a rapid prototype version, the next step is to
368: implement a first centralized version of the algorithm. A centralized
369: algorithm has full access to all nodes and has a global, flat view of
370: the network. This provides a simple means to get results and a first
371: impression of the overall performance of the examined algorithm. The
372: results emerging from this process can provide optimization feedback
373: for the algorithm design.
374:
375: Once a satisfactory state of the centralized version has been
376: achieved, the feasibility of its distributed implementation can be
377: investigated in depth. Only a simplified communication model between
378: individual sensor nodes is utilized at this point in time. Because the
379: goal of this step is to prove that the algorithm can be transformed to
380: a distributed implementation, the messages exchanged between the nodes
381: are simple data structures passed in memory. This allows for a very
382: efficient and fast implementation, leading to meaningful results.
383:
384: Having arrived at a fully distributed and working implementation, the
385: remaining task is to define the actual protocol and rules for the
386: nodes to run the distributed algorithm. Messages that have been
387: in-memory data structures that are passed as references may now be
388: represented in form of individual data packets. With the protocol and
389: data structures in place, the performance of the distributed
390: implementation can be evaluated. Interesting questions that can be
391: explored are, e.g., the number of messages, energy consumption,
392: run-time, resilience to message loss and environmental effects.
393:
394: \section{Architecture}
395: \label{sec:arch}
396: %
397: Conceptually, Shawn consists of three major parts: Simulation
398: environment, Sequencer, and Models. The simulation environment contains
399: the simulated items and their properties, while the sequencer and the
400: models influence the behavior of the simulation environment.
401: Figure~\ref{fig:arch} shows a high-level overview of the architecture
402: of Shawn.
403: \begin{figure*}[t]
404: \centering
405: \includegraphics[width=.8\textwidth]{f-arch}
406: \caption{Architectural overview of Shawn's core components.}
407: \label{fig:arch}
408: \end{figure*}
409:
410:
411: \subsection{Models}
412: \label{sec:models}
413:
414: To achieve reusability, extensibility and flexibility, exchangeable
415: models are used wherever possible in Shawn. A thorough distinction
416: between models and their respective implementations supports these
417: goals. Shawn maintains a very flexible and powerful repository of
418: model implementations that can be used to compose simulation setups
419: simply by selecting the desired behaviors through model identifiers at
420: runtime.
421:
422: Some models shape the behavior of the virtual world, while others
423: provide more specialized data. Models that form the foundation
424: of Shawn are the {\em Communication Model}, the {\em Edge Model} and
425: the {\em Transmission Model}.
426:
427: The {\em Communication Model} determines for a pair of nodes whether
428: they can communicate. There may be models representing unit disk
429: graphs for graph-theoretical studies, models based on radio
430: propagation physics, or models that resort to a predefined
431: connectivity scenario.
432:
433: The {\em Edge Model} uses the {\em Communication Model} for providing a
434: graph representation of the network by giving access to the direct
435: neighbors of a node. This has two major implications. First, it allows
436: for simple centralized algorithms that need information on the
437: communication graph. In this, Shawn differs from Ns-2 and other
438: simulators, for which the check for connectivity must be based on sending
439: test messages. The second point is the exchangeability of edge models:
440: Simulations of relatively small networks may allow storing the
441: complete neighborhood of each node in memory and will thus provide
442: extremely fast answers to queries. However, huge networks will impose
443: impractical demands for memory; therefore, an alternative edge model
444: trades memory for runtime by recalculating the neighborhood on each
445: request, or only caches a certain number of neighborhoods.
446:
447: While the {\em Communication Model} decides whether two nodes can
448: communicate as a matter of principle, the {\em Transmission Model}
449: determines the properties of an individual message transmission. It
450: can arbitrarily delay, drop or alter messages. This means that
451: when the runtime of
452: algorithms is not in question, a simple transmission model without
453: delays is sufficient. A more sophisticated model may account for contention,
454: transmission time and errors.
455:
456: Different implementations of these models can significantly alter the
457: behavior of the simulation. This can either mean changing the
458: behavior of the virtual world or modifying the requirements of the
459: simulation. An example of a change to the virtual world is the use of
460: a different {\em Transmission Model}, e.g., using random message
461: dropping. Depending on the size of the simulated world, a change in
462: the implementations of e.g. the {\em Edge Model} may substantially
463: alter the performance and the requirements of the simulation.
464:
465: More specialized models provide data for simulations. Currently Shawn
466: ships with {\em Random Variable} and {\em Node Distance Estimate}
467: models. Random variables are needed very often in simulations for modeling
468: the real-world behavior. With the introduction of random
469: variable as models, algorithms can be tested with different underlying
470: random variables without the need of being aware of the change. {\em Node
471: Distance Estimate} implementations are used to mimic distance
472: measurements for, say, localization algorithms.
473:
474: \subsection{Sequencer}
475: \label{sec:seq}
476: %
477: The sequencer is the central coordinating unit in Shawn. It configures
478: the simulation, executes tasks sequentially and drives the simulation.
479: It consists of the Simulation Controller, the Event Scheduler and the
480: straightforward, yet powerful, concept of Simulation Tasks.
481:
482: The purpose of the Simulation Controller is to act as the central
483: repository for all available model implementations and to drive the
484: simulation by transforming the configuration input into parameterized
485: calls of Simulation Tasks. These are arbitrary pieces of code
486: that can be configured and run from the simulation's setup files.
487: Because they have full access to the whole simulation, they are able to
488: perform a wide range of jobs. Example uses are the steering of
489: simulations, gathering data from individual nodes or running
490: centralized algorithms. Finally, the Event Scheduler triggers the
491: execution of events that can be scheduled for arbitrary discrete
492: points in time.
493:
494: \subsection{Simulation environment}
495: \label{sec:env}
496: %
497: The simulation environment is the home for the virtual world in which
498: the simulation objects reside. All nodes of a simulation run are
499: contained in a single world instance. The nodes themselves serve as a
500: container for so-called Processors, which are the real work horses of
501: the simulations; they process incoming messages, run algorithms and
502: emit messages.
503:
504: Shawn features persistence and decoupling of the simulation
505: environment by introducing the concept of {\em Tags}. They attach both
506: persistent and volatile data to individual nodes and the world. They
507: decouple state variables from member variables, thus allowing for an
508: easy implementation of persistence. Another benefit is that parts of a
509: potentially complicated protocol can be replaced without modifying
510: code, because the internal state is stored in tags and not in a special
511: node implementation.
512:
513: \section{Case Study}
514: \label{sec:casestudy}
515: %
516: To demonstrate Shawn's performance gain, we now present a comparison to
517: Ns-2. We ran a number of simulations of a subroutine that is used in
518: certain time synchronization protocols. Here every node periodically
519: broadcasts a message containing time stamps that is converted at the
520: receiving node. Meanwhile, overhead induced by the time stamps is
521: measured. A total of 380 messages is sent by each node. This provides
522: insight on the simulator's ability to dispatch a large amount of
523: traffic.
524:
525: The result of this comparison is not surprising, because Ns-2 does a
526: lot more detailed computations than Shawn to arrive at the same
527: results. This shows that Ns-2 and others cannot compete with Shawn in
528: its domain.
529:
530: Table~\ref{tab:results} shows the runtime and memory consumption of
531: Ns-2 and Shawn in different setups. The environment consists of a
532: square area whose size is the specified multiple of the nodes'
533: communication range. The node density describes the average number of
534: nodes within a broadcast area.
535:
536: The first thing to notice is that Ns-2 hits the one-day barrier for instances
537: that Shawn finishes in less than one minute with considerably
538: smaller memory footprint. The fifth line refers to a simulation run
539: using the ``Simple'' edge model in which neighborhoods are not cached at
540: all and hence the simulation uses more time and less memory. In all
541: other runs, the ``List'' edge model is used, which completely caches
542: all neighborhoods. This is one example for which the choice of model can
543: trade memory versus runtime. The last three lines show networks of
544: huge size, respectively, huge neighborhoods, that only Shawn can handle
545: in reasonable time.
546:
547: \begin{table*}
548: \noindent
549: \begin{tabular}{|r|r|r|rr|rrl|}
550: \hline
551:
552: &
553: &
554: & \multicolumn{ 2}{|c}{{\bf Ns-2}}
555: & \multicolumn{ 3}{|c|}{{\bf Shawn}} \\
556: %
557: \multicolumn{1}{|p{1.5cm}}{Number of Nodes}
558: & \multicolumn{1}{|p{1.5cm}}{Environment Size}
559: & \multicolumn{1}{|p{1.5cm}}{Node Density}
560: & \multicolumn{1}{|p{1.5cm}}{CPU Time (H:M:S)}
561: & \multicolumn{1}{p{1.5cm}|}{Memory Usage (MBytes) }
562: & \multicolumn{1}{p{1.5cm}}{CPU Time (H:M:S) }
563: & \multicolumn{1}{p{1.5cm}}{Memory Usage (MBytes)}
564: & \multicolumn{1}{p{1.5cm}|}{Edge Model} \\
565: \hline
566: 100 & 10x10 & 3.1 & 00:00:15 & 14.8 & 00:00:01 & 1.9 & List \\
567: \hline
568: 500 & 10x10 & 15.7 & 00:22:59 & 53.9 & 00:00:01 & 2.9 & List \\
569: \hline
570: 1,000 & 10x10 & 31.4 & 01:59:36 & 106.0 & 00:00:04 & 4.5 & List \\
571: \hline
572: 2,000 & 10x10 & 62.8 & 25:36:13 & 224.0 & 00:00:19 & 8.6 & List \\
573: \hline
574: 25,000 & 10x10 & 785.4 & & & 19:45:48 & 122.9 & Simple \\
575: \hline
576: 30,000 & 10x10 & 942.5 & & & 01:34:47 & 757.6 & List \\
577: \hline
578: 200,000 & 80x80 & 78.5 & & & 03:27:49 & 891.0 & List \\
579: \hline
580: 300,000 & 173.2x173.2 & 31.4 & & & 04:47:46 & 855.5 & List \\
581: \hline
582: \end{tabular}
583: \caption{Comparison of running time and memory usage between Shawn and Ns-2.}
584: \label{tab:results}
585: \end{table*}
586:
587: \section{Conclusions}
588: \label{sec:conclusion}
589: %
590: We have presented Shawn, an open-source discrete event simulator for
591: sensor networks with huge numbers of nodes. By reviewing existing
592: simulators, we have identified a previously uncovered gap in
593: simulation domains. By means of a simple case study we have
594: demonstrated what Shawn's strengths are and how it fills the described
595: gap. We have described the differences between Shawn and its
596: competitors, its unique features and how users can benefit from its
597: application.
598:
599: \section{Future work}
600: \label{sec:future}
601: %
602: A crucial point in the future will be to provide more model
603: implementations. Our current plans are to supply different mobility
604: models and fine-grained communication and transmission models. We
605: strongly encourage the open-source community to participate in this
606: process and to enhance Shawn by contributing to its growth.
607:
608: Another planned improvement is a better interface for discrete
609: combinatorics. Existing libraries such as CGAL~\cite{CGAL} and BOOST
610: Graph~\cite{BOOST} provide sophisticated data structures and
611: algorithms for computational geometry and graph theory. By making
612: Shawn's internal network structure visible to these libraries we can
613: immediately leverage their code base. Furthermore, we want to support
614: the data formats of Ns-2 in order to be able to process existing
615: scenarios.
616:
617: \section{Acknowledgements}
618: \label{sec:ack}
619: %
620: This work is part of the SwarmNet project
621: (\url{http://www.swarmnet.de}) and funded by the German Research
622: Foundation (DFG) under grants Fe 407/9-1 and Fi 605/8-1. We thank
623: Tobias Baumgartner and Andr{\'e} Steinert for their commitment in the
624: preparation of this paper.
625:
626: \bibliographystyle{IEEEtran}
627: \bibliography{references}
628:
629: \end{document}
630: