Simulation of Real Time Applications in Wireless Sensor Networks

1
Simulation of Real Time Applications in
WirelessSensor Networks

• Paolo Pagano (ReTiS Lab)

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

3
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 ).
4
Brief reminder on HARD SOFT

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

• 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 its usually designed
  for a family of applications.

5
Research and Development in WSNs
Nano-RK (Carnegie Mellon University)
http//doi.ieeecomputersociety.org/10.1109/RTSS.20
05.30
A Crossbow MicaZ mote

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

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

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

8
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/pro
  jects/glomosim/
• Scalable Network Technologies, Inc., Culver City,
  CA, USA
• The QualNet Simulator. http//www.scalable-network
  s.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

9
Selected package

• We selected NS-2 (USC-ISI)http//www.isi.edu/ns
  nam/ns/
• for 4 reasons
• diffusion in the scientific community
• open source nature
• C coded
• 802.15.4 MAC support.

Simulators NS-2 OPNET QualNet/GloMoSim
Tranport 75 18 7
Network 70 18 12
MAC PHY 42 26 22
10
Project phylosophy

• Integrate NS-2 with an OS simulator
  (cosimulation)
• OS Simulator of Choice RTSim (ReTiS Lab, Sant
  Anna).

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)
http//rtsim.sssup.it/
11
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
12
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.

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

14
The new Library added to NS-2
RT

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

15
OS instructions
FCFS

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

FP
Figures refer to Receive Instruction.
16
Computation and Network Load

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

17
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 terminalno 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)
18
Network Scenarios (2)

• Complicating the picture
• Introducing routing pathsand 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?

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

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

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

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