scuola superiore sant’anna simulation of real time applications in wireless sensor networks paolo...

Scuola Superiore Sant’Anna

Simulation of Real Time Applications in Wireless

Sensor NetworksPaolo Pagano (ReTiS Lab)

November 17th [email protected] 2

Outline

• The Wireless Sensors application domain• Wireless Sensors

– Brief reminder on Hardware & Software

– State of the Art for RT-OS

• Simulating WSN activities– The NS-2 network simulator

– The RTSim RT-systems simulator

– The integrated framework

• Simulated metrics in WSN activities• Conclusions & Outlook


Wireless Sensor Networks generalities

• In smart environments1 data come from multiple sensors (of different nature) in distributed locations;

• WSNs consist of data acquisition and data dissemination networks controlled by a management center.

[1] “a physical world that is richly and invisibly interwoven with sensors, actuators, displays, and computational elements, embedded seamlessly in the everyday objects of our lives, and connected through a continuous network” (Mark Weiser, Xerox PARC, father of Ubiquitous computing ).


Brief reminder on HARD & SOFT

HW of a microcontroller:• Embeds multiple functionality onto

a single chip, minimizing:– Size of the entire system;– Power consumption;– Interconnectivity complexity

among system components;– Number of internal-external

connections (e.g. analog lines);

• Has simple CPU (usually 8 bits but also 32 bits);

• Has a minimum degree of flexibility and HW reconfigurability because it’s usually designed for a family of applications.

Embedded Operating Systems• Application-specific – just use

features you need to save resources;

• Manage Sensors, Serial port, Radio, Memory, Power;

• Concurrency:– Input/output - API for talking to

devices, buffering;– Interrupt handling (with I/O

devices);– Events to be handled by user code

e.g. to trigger new tasks (reactivity);– Real-time issues:

guarantee an interrupt will be handled within a certain time;

priority or deadline driven scheduling of tasks.


A Crossbow MicaZ mote

Research and Development in WSNs

AVR ATMega128 microcontroller:- 8-bit ISA w/ 1 MIPS per Mhz (16 Mhz max) maximum throughput;- 128 KByte Flash memory;- 4 KByte SRAM;- 4 KByte EEPROM ;- 2-stage pipelining;- 32 general registries accessed from the CPU; - 6 power save modes;- several interruption sources.

Nano-RK (Carnegie Mellon University): http://doi.ieeecomputersociety.org/10.1109/RTSS.2005.30


Simulation in WSNs (1)

• Simulation is an important analysis tool:– in the development of distributed systems;– in testing new network protocols;– for assessing the performance of protocols;– it complements off-line mathematical analysis tools

especially for large and complex systems with hundreds of nodes.

• Network and OS simulations sit in two different worlds, separated in so far even in the composition of the scientific communities;

• Network Simulators don’t describe the latency due to the OS activities relying on the assumptions:– these delays are an order of magnitude smaller than those induced by

the network stack;– in WSNs the services are provided at “the best effort”.


Simulation in WSNs (2)

• Networks are becoming faster and software complexity in a node higher, thus increasing the vagueness of simulation because of assumption of events within a node occuring in zero time:– accurate tools are needed to reduce the gap between the simulation

and the final implementation; especially for simulating applications which need a very high level of accuracy in timing;

– need to consider detailed time usage within and outside a node.

• Citing H. Karl and A. Willig with respect to the challenges for WSNs we say :– “[...] there are cases where very high reliability requirements exist. In

yet other cases, delay is important when actuators are to be controlled in a real time fashion by the sensor network. The packet delivery ratio is an insufficient metric; what is relevant is the amount and quality of information that can be extracted at given sinks about the observed objects or area. [...]”.


Existing network simulation engines

• Several packages exist for discrete, event-driven network simulation;

• They can also describe dynamic systems like Mobile Ad-hoc Networks (MANETs) and WSNs:– OPNET Technologies, Inc., Bethesda, MD, USA:

• The OPNET Simulator. http://www.opnet.com/– UCLA Computing Laboratory:

• The GloMoSim simulator. http://pcl.cs.ucla.edu/projects/glomosim/– Scalable Network Technologies, Inc., Culver City, CA, USA:

• The QualNet Simulator. http://www.scalable-networks.com/– The OMNeT++ Discrete Event Simulation System

• http://www.omnetpp.org/– UIUC Illinois Network Design and Experimentation Group,

• The J-Sim Simulator. http://www.j-sim.org/– UC Berkeley:

• The TOSSIM simulator. http://www.cs.berkeley.edu/~pal/research/tossim.html

OS


Selected package

• We selected NS-2 (USC-ISI):http://www.isi.edu/nsnam/ns/

for 4 reasons:– diffusion in the scientific

community;– open source nature;– C++ coded;– 802.15.4 MAC support.

OTcl C++OTcl script describing simulation

Tcl

CL

OS

Simulators NS-2 OPNET QualNet/GloMoSim

Tranport 75% 18% 7%

Network 70% 18% 12%

MAC & PHY 42% 26% 22%


Project phylosophy

• Integrate NS-2 with an OS simulator (cosimulation):

– OS Simulator of Choice: RTSim (ReTiS Lab, Sant’ Anna).

http://rtsim.sssup.it/

“OS imitation must be present to give an opportunity to model delays that come up from task processing and to model interference of services that share one processor, RAM, OS and so on.In more detailed version it may be used to insert real applications to test their performance and experiment with their settings (I imply we can have several OS modules on one real workstation).It must be planned to use several OS modules of different abstraction” (I.Batov, NS-3 developer)


The RTSim project

• RTSIM consists of 4 components:– Metasim: a generic library for

simulation of discrete event systems. This library is also released separately, see http://metasim.sssup.it

– RTLib: based on Metasim, it is library for simulating scheduling algorithms and real-time tasks;

– CTRlib (optional): it is a library for simulating real-time control systems. It requires the “octave” library;

– JTracer (optional): it is a java based tool for visualisation of schedule traces produced by a rtlib program.

Only a subset of classes are presently linked with

NS-2


NS-2 Architecture

• Application:– Standard network applications like FTP,

Telnet or various Traffic Generators like CBR, Exponential ...

• Agent:– Represent endpoints where network-

layer packets are constructed or consumed, and are used in implementing protocols;

• Node:– Represents a basic node in the network.

Can be configured to adopt various routing, MAC, LL, and PHY layer protocols.


Expectations from new Architecture

• Simulation Time Accountancy for latency in:

– Periodic and Aperiodic Task Set– Interrupt processing

• Ability to use existing NS-2 agents:– e.g. UDP for unreliable transfer

protocol; • Ability to use existing NS-2 MAC

and PHY layers: – 802.15.4-based WPANs supported

starting from release 2.29.• Transparency:

– no major change in NS-2 user interface;

– user provided by APIs accessible through the TCL front-end.

• Support for heterogeneous environments i.e. ability to simulate different CPU as well as OS profiles on various nodes in a simulation.


The new Library added to NS-2

• RTSim library is accessed by a newly defined NS-2 Application:– Simple and easy to do;– Minor modification to RTSim.

• A new kind of event is used to synchronize the MetaSim and NS-2 event queues.

RT


OS instructions

• The RT-Application is now in charge of: – scheduling packet

transmission;– handle packet reception.

• Send and Receive instructions have been added to RTSim (thanks to Giuseppe);

• FCFS (~TinyOS) and FP scheduling policies are simulated.

Figures refer to Receive Instruction.

FCFS

FP


• Simulate from light to heavy load in the node through a set of Dummy Periodic Tasks: – tuning the number of tasks;– tuning the task parameters (C,T,U) to obtain different loads.

• Calculating the OS induced and the total (source to destination) delay as a function of the packet and checking the impact of the scheduling policies in time sensitive applications;

• Network load tuned acting on transmission schedules and concurrent access.

Computation and Network Load


Network Scenarios (1)

• Starting from simple scenarios:– 4 nodes located at the

edges of a square communicating to a sink placed at the center of mass; no hidden terminal;no network structure (single cluster); no routing; the sink plays the role of WPAN coordinator.

• To re-obtain the governing laws of RT-computing. Screenshot of the Network

AniMator (NAM)


Network Scenarios (2)

• Complicating the picture:– Introducing routing paths

and data streams;– Nodes connecting different

clusters fetch and forward the readings coming from other clusters.

• How do RT-issues influence the reactivity of such nodes?

Screenshot of the Network AniMator (NAM)


Selection of relevant metrics

• By simulation we evaluate:– the maximum, mean and

minimum latency observed in sending and receiving the packets;

– the time propagation through the sender and recipient network stacks (including re-transmissions done at low layers);

– the packet probability of being delivered.

• Applications can be sensitive to one, more or all these metrics.


Results for scenario 1

• the FP scheduling policy is insensitive to CPU activity;

• the FCFS scheduling policy is conformant only to moderate CPU loads in presence of RT-issues; with medium-to-high CPU loads a FP scheduling must be preferred;

• the delays are inversely proportional on the repetition time of the packet transmission by the node; for sufficiently sporadic transmissions ( 1/ν ≥ 0.4 s) this effect is reasonably small;

• the dependence on the number of tasks is moderate;

• with standard PHY, MAC, and LL settings, the packet loss is negligible.


Submitting this work to WPDRTS…

• We wrote an article to propose our framework to the communities involved in telecommunications among RT systems;

• We propose the WSN as a domain where correctly simulating RT applications is very promising.


Outlook and Conclusions

• NS-2 and RTSim have been integrated to take into account RT-issues in wireless telecommunications;

• In WSNs these issues play a role whenever any QoS must be guaranteed by the nodes;

• FCFS and FP scheduling policies have been implemented and are being compared within certain network and CPU load conditions;

• Simple scenarios have been simulated to evaluate selected metrics:– the FCFS scheduling policy is conformant only to moderate CPU

loads in presence of RT issues; – in presence of medium-to-high CPU loads a real-time scheduler,

as FP, must be preferred.• Results for more realistic scenarios and transmissions

are coming...

scuola superiore sant’anna simulation of real time applications in wireless sensor networks paolo...

Documents

network stack

os activities

testing new network

complex systems

data dissemination networks

distributed locations

rtsim rtsystems simulator

continuous network mark