Simulation in Sensor Networks

Presented by:
Gunjan Juyal (200301156)
DA-IICT, Gandhinagar.
Need for Simulation in Sensor
Networks
Need
(1/2)
for Simulation in Sensor Networks
„ 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)

3
Need
(2/2)
for Simulation in Sensor Networks
„ 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.

4
An Ideal Sensor Network
Simulator
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

6
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.

7
General Purpose Network
Simulators
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++)

9
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 bugs
„ Generic simulators not optimized for SN scenarios – SNs
have 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.

10
Some Generic Network Simulators
(1/5)

„ NS2:-
‰ A discrete-event network simulator
‰ Very popular for multicast and routing protocols
simulation.
‰ Control <-> Data separation
‰ Originally 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.

11
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.

12
Some
(3/5)
Generic Network Simulators
„ Lots of differences between OMNeT++ and
NS2 (visit:
http://ctieware.eng.monash.edu.au/twiki/bin/view/Simulation/OMNeT
ppComparison)
„ 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.

13
Some
(4/5)
Generic Network Simulators
„ GloMoSim:-
‰ Specific for mobile wireless networks (no support
for wired)
‰ Layered architecture, and each layer can be
modeled separately according to the required
complexity
‰ Built-in statistics-collection at each layer
‰ Has only fixed protocol layers, cannot add/delete
any new layers.
‰ No longer under active development.
‰ Coding in Parsec and C languages.

14
 Data Plane
GloMoSim Library
Application Processing

Modular, extensible library for RTP Wrapper

network models TCP, UDP, RSVP
Model each layer using
abstract or detailed model IP

Built-in statistics collection at

OSPF, AODV, …
each layer
Packet Store/Forward
Cons : IEEE 802.11, 802.3, …
Fixed protocol layers.
EPLRS, WaveLAN, ...

Free space, TIREM

Figure: The GloMoSim Architecture

15
Some
(5/5)
Generic Network Simulators
„ JavaSim:-
‰ Very modular, easy to use
‰ Available only for wired networks (no wireless
support)
‰ Coding in java high level language.
‰ Much slower in execution in general than most
other simulators.

16
Sensor Network Simulators
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.

18
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.

19
Figure: A sample network configuration being simulated in the MobilityFramework
20
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)

21
TOSSIM
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.

23
TOSSIM Architecture
„ Component
based
„ TOSSIM
provides PC
versions of
hardware
components
„ Event-driven
Figure: The TOSSIM Architecture runtime

24
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.

25
TOSSIM (1/3)

„ Advantages of using TOSSIM:-

‰ Ease of use – Compiles directly from TinyOS
source 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

26
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.

27
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.

28
Power TOSSIM
Power TOSSIM
„ Need 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; or
‰ Simulate at the bit/cycle level. Extremely accurate
but very slow and impractical for large topologies.

30
 Power TOSSIM Architecture (1/2)

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

31
Power TOSSIM Architecture (2/2)

Figure: The Power TOSSIM Architecture

32
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.

33
Power TOSSIM – Methodology (2/4)

„ Step 1: Insert per-mote counters into each

basic block (one counter per block per mote)

34
Power TOSSIM – Methodology (3/4)

„ Step 2: Compute CPU cycles needed for

each block

35
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)

36
ATEMU
ATEMU
„ ATEMU – Atmel Emulator:-
‰ Simulates/Emulates Atmel microprocessor
‰ Simulates 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)

38
ATEMU CPU Emulation
„ Complete emulation of AVR instruction set.
„ For the same instruction set different
hardware platforms may use different Atmel
CPUs.
„ Such per-node configurations to be specified
by user, including:-
‰ SRAM and flash memory size
‰ Program counter sizes
‰ Symbolic names for all attached IO peripherals

39
ATEMU
„ Advantages 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.

40
References (1/2)

„ http://en.wikipedia.org/wiki/Sensor_network : General information on

sensor networks.
„ http://mobilesummit2006.telecom.ece.ntua.gr:8080/cruise/Public%2
0documents/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.

41
References (2/2)

„ http://www.eecs.harvard.edu/~shnayder/slides/sensys04talk.pdf :
Slides on Power TOSSIM
„ http://pcl.cs.ucla.edu/projects/glomosim/ : Project site of GloMoSim
„ http://mobility-fw.sourceforge.net/hp/index.html : MobilityFramework
home page
„ http://www.ita.cs.rpi.edu/sense/index.html : SENSE home page
„ http://javasim.ncl.ac.uk/ : JavaSim home page
„ http://csc.lsu.edu/sensor_web/sensim.html : SENSIM home page
„ J. 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.

42