Académique Documents
Professionnel Documents
Culture Documents
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
3
Need
(2/2)
for Simulation in Sensor Networks
Compare different design strategies to
choose the best one
4
An Ideal Sensor Network
Simulator
Ideal Sensor Network Simulator (1/2)
6
Ideal Sensor Network Simulator (2/2)
7
General Purpose Network
Simulators
General Purpose Network Simulators
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
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)
26
TOSSIM (2/3)
27
TOSSIM (3/3)
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)
32
Power TOSSIM – Methodology (1/4)
33
Power TOSSIM – Methodology (2/4)
34
Power TOSSIM – Methodology (3/4)
35
Power TOSSIM – Methodology (4/4)
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)
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