Simulation in Sensor Networks

Presented by:Gunjan Juyal (200301156)

DA-IICT, Gandhinagar.

Need for Simulation in Sensor Networks

3

Need for Simulation in Sensor Networks (1/2)

Test system configurations that are difficult/impossible to construct

Observe system performance and interactions difficult to observe in actual deployment environment (WildCense)

Test the quality and reliability of algorithms for SN (data processing, routing)

4

Need for Simulation in Sensor Networks (2/2)

Compare different design strategies to choose the best one

Accurate and scalable simulation brings down cost and time of development, thus accelerating pace of research in that area.

In short, simulation for SN allows for savings on time, money and human effort.

An Ideal Sensor Network Simulator

6

Ideal Sensor Network Simulator (1/2)

Scalability: Ability to efficiently handle large networks (1000s of nodes) in a wide range of configurations.Fidelity: Must capture a fine-grained behaviour of the network, thus should reveal unanticipated interactions between components also (i.e. should be accurate and not too approximate).Completeness: Should cover as many system interactions as possible with sufficient accuracy:-

Not just algorithm and routing protocol simulation, but all other interactions between components in an application Should support different wireless transmission channel models and battery models

7

Ideal Sensor Network Simulator (2/2)

Bridging: The simulator must bridge the gap between algorithm conception and actual field implementation –should allow developers to test and verify the code that will run on real hardware with minimum changes.Reusability: The simulator should allow code for one SN simulation to be used in another (similar) SN simulation with minimal changes and complexity.Also: Availability of sufficient technical support/help/documentation/tutorials – helps shortening the learning curve and accelerate development process.

General Purpose Network Simulators

9

General Purpose Network Simulators

Examples: NS2, GloMoSim, OMNeT++, JavaSim, SSFNet-Java and SSFNet-C++.Different simulators have different offerings and USPs(in-built libraries, channel models etc), no single winner.Different simulators might have different simulation environment, libraries and/or use different programming languages. Therefore a code to be simulated has to be re-written for that simulator.Usually require learning a new programming language (OTcl for NS2 and NED for OMNeT++)

10

Problems in Simulating Sensor Networks with Generic Simulators

Generic simulators usually designed for smaller number of nodes (SNs might have thousands)Converting actual application code to simulation code might bring in anomalies or bugsGeneric simulators not optimized for SN scenarios – SNshave additional constraints like limited resources, decentralized operation and fault tolerance, therefore greater complexity.Interaction between nodes, network stack and environment difficult to simulate in these.

11

Some Generic Network Simulators (1/5)

NS2:-A discrete-event network simulatorVery popular for multicast and routing protocols simulation.Control <-> Data separationOriginally built for wired, later extended to wireless.More useful for getting statistics for lower-level protocols.Built in C++; simulation interface through the language OTcl.

12

Some Generic Network Simulators (2/5)

OMNeT++:-A componenet based, modular discrete event simulator with strong GUI environment.Primary application area is simulation of communication networks, but beacause of its flexibility and generic architecture has also been applied in simulation of business processes, queuing networks, hardware architectures etc.Basic modules written in C++; larger structures formed using the NED high-level language.

13

Some Generic Network Simulators (3/5)

Lots of differences between OMNeT++ and NS2 (visit: http://ctieware.eng.monash.edu.au/twiki/bin/view/Simulation/OMNeTppComparison)In short:

NS2 older than OMNeT++, therefore much more protocols and algorithms have been coded for it.In most cases it is easier/faster to code in OMNeT++ and the code is easily reusable due to its hierarchical structure.NS2 has scalability problems with large networks.

14

Some Generic Network Simulators (4/5)

GloMoSim:-Specific for mobile wireless networks (no support for wired)Layered architecture, and each layer can be modeled separately according to the required complexityBuilt-in statistics-collection at each layerHas only fixed protocol layers, cannot add/delete any new layers.No longer under active development.Coding in Parsec and C languages.

15

GloMoSim LibraryGloMoSim Library

Modular, extensible library for network modelsModel each layer using abstract or detailed modelBuilt-in statistics collection at each layer

Cons :Fixed protocol layers.

Application Processing

Free space, TIREM

EPLRS, WaveLAN, ...

IEEE 802.11, 802.3, …

OSPF, AODV, …

IP

TCP, UDP, RSVPRTP Wrapper

Packet Store/Forward

Data Plane

Figure: The GloMoSim Architecture

16

Some Generic Network Simulators (5/5)

JavaSim:-Very modular, easy to useAvailable only for wired networks (no wireless support) Coding in java high level language.Much slower in execution in general than most other simulators.

Sensor Network Simulators

18

Some Sensor Network Simulators (1/3)

SensorSim:-An extension to NS2, comes bundled with it.Provides a lightweight protocol stack.Provides battery, radio propagation and sensor channel models.Currently at initial stages of development – lots of hard-coding, works only for a single base-station, no good documentation.Inherits the benefits of NS2 (large code base) as well as its drawbacks – relatively tough coding, doesn’t work well for large topologies etc.

19

Some Sensor Network Simulators (2/3)

MobilityFramework:-An extension to OMNeT++, set of APIs.Provides a wireless channel model, mobility and connection management.Hierarchical and modular structure – programmer can add/modify existing modules in their project.Is in initial stages of development –documentation available but no tutorials.Inherits the benefits of OMNeT++ (easier coding, hierarchical and modular) as well as its drawbacks – new simulator, therefore not much code made available to the developer community.

20Figure: A sample network configuration being simulated in the MobilityFramework

21

Some Sensor Network Simulators (3/3)

SENSE:-An extensible, reusable and scalable simulator built to overcome some of the problems while simulating sensor networks in NS2.Limited availability of additional modules for SENSE.

SENSIM – built over OMNeT++EM* (EM Star)TOSSIM (TinyOS Simulator)ATEMU (Atmel Emulator)

TOSSIM

23

TOSSIM

TOSSIM – TinyOS Simulator:-A discrete event simulator developed at UC, Berkeley.Simulates a TinyOS mote.Very popular for simulating sensor network applications.Replaces hardware with software components (through a hardware resource abstraction layer).Hardware interrupts are modeled as simulator events.

24

TOSSIM Architecture

Component basedTOSSIM provides PC versions of hardware componentsEvent-driven runtimeFigure: The TOSSIM Architecture

25

TOSSIM Hardware Emulation

TOSSIM hardware emulation:-TinyOS abstracts each hardware resource as a component for the applications.TOSSIM replaces a few such components which then emulate the underlying raw hardware.E.g. ADC, Clock, EEPROM, Radio stack and Boot sequence.

Has an external radio model.

26

TOSSIM (1/3)

Advantages of using TOSSIM:-Ease of use – Compiles directly from TinyOSsource code, thus reduced efforts and bugs.Fidelity – Emulates hardware at component level and simulates network at bit level (fine-grained), thus accurate.Scalability – Scales to thousands of nodes.Completeness – Captures complete system behaviour and all interactions between individual components

27

TOSSIM (2/3)

Advantages of using TOSSIM (contd.):-Compile application code for actual hardware or TOSSIM as required.No change required to the application.Deployment can immediately follow testing on TOSSIM.Very fine-grained simulation of TinyOS networking stack at bit-level.Thus, allows one to do everything on simulator that one can do on mica.

28

TOSSIM (3/3)

Drawbacks / Possible enhancements:-Does not include energy modeling.Can be improved to run multiple applications at a time.Applicable only for TinyOS platform applications.

Power TOSSIM

30

Power TOSSIMNeed for Power TOSSIM:-

To predict the lifetime of a sensor node we need to simulate power consumption pattern.

To obtain CPU energy consumption, we need number of cycles in active mode. Two approaches:-

Count high-level events only (e.g. radio messages). Very fast, easy, simple but can be highly inaccurate; orSimulate at the bit/cycle level. Extremely accurate but very slow and impractical for large topologies.

31

Power TOSSIM Architecture (1/2)

Figure: The TOSSIM Architecture (for comparison with Power TOSSIM Architecture)

32

Power TOSSIM Architecture (2/2)

Figure: The Power TOSSIM Architecture

33

Power TOSSIM – Methodology (1/4)

TOSSIM compiles application code into native PC binaries; thus no accurate way of determining the exact number of CPU cycles used on the mote.Options:–

Simulate at the AVR instruction level (very slow);Count the number of times each basic block is executed, and map each basic block to number of cycles used on AVR (low overhead).

Power TOSSIM uses the latter approach.

34

Power TOSSIM – Methodology (2/4)

Step 1: Insert per-mote counters into each basic block (one counter per block per mote)

35

Power TOSSIM – Methodology (3/4)

Step 2: Compute CPU cycles needed for each block

36

Power TOSSIM – Methodology (4/4)

Step 3: Compute actual CPU cycles by using Step 1 and Step 2 data collected during a particular execution of the application.

Potential inaccuracies / future scope:-Basic-block-to-assembly mapping can be inaccurate in case of compound C lines.Some low-level components have no mapping.No battery model in existing version.Can be extended to new node platforms (new radios, different sensors)

ATEMU

38

ATEMUATEMU – Atmel Emulator:-

Simulates/Emulates Atmel microprocessorSimulates large scale and heterogeneous sensor network (different sensor nodes can run different programs)Currently supports only Mica2 board components (partial support, for radio components only)

39

ATEMU CPU Emulation

Complete emulation of AVR instruction set.For the same instruction set different hardware platforms may use different AtmelCPUs.Such per-node configurations to be specified by user, including:-

SRAM and flash memory sizeProgram counter sizesSymbolic names for all attached IO peripherals

40

ATEMUAdvantages of ATEMU:-

Good graphical debugging environment – Support for arbitrary number of breakpoints and memory watchpoints.Supports multiple sensor nodes in a network, and each node can have different configurations and run different programs.

Possibility to add other hardware platforms in the future.

41

References (1/2)

http://en.wikipedia.org/wiki/Sensor_network : General information on sensor networks.http://mobilesummit2006.telecom.ece.ntua.gr:8080/cruise/Public%20documents/wp123-wsn-simulation-tool-knowledgebase/simulation-tool-comparison-matrix/ : Table comparing simulation tools for wireless sensor networks.http://intranet.daiict.ac.in/~ranjan/sn/presentations/sensor_network_simulation.pdf : Mr. Udayan Kumar’s presentation on the same topic.Levis P., Lee N., Welsh M., Culler D., “TOSSIM: accurate and scalable simulation of entire tinyOS applications”, Proceedings of the 1st international conference on Embedded networked sensor systems, 2003, pp. 126-137.

42

References (2/2)

http://www.eecs.harvard.edu/~shnayder/slides/sensys04talk.pdf : Slides on Power TOSSIMhttp://pcl.cs.ucla.edu/projects/glomosim/ : Project site of GloMoSimhttp://mobility-fw.sourceforge.net/hp/index.html : MobilityFrameworkhome pagehttp://www.ita.cs.rpi.edu/sense/index.html : SENSE home pagehttp://javasim.ncl.ac.uk/ : JavaSim home pagehttp://csc.lsu.edu/sensor_web/sensim.html : SENSIM home pageJ. Polley, D. Blazakis, J. McGee, D. Rusk, and J. Baras, “ATEMU: A Fine-grained Sensor Network Simulator,” IEEE International Conference on Ad Hoc Communications and Networks (SECON 2004), October 2004.