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 Paolo.Pagano@sssup.it

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 ). Paolo.Pagano@sssup.it

4. 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. Brief reminder on HARD & SOFT Paolo.Pagano@sssup.it

5. Research and Development in WSNs Nano-RK (Carnegie Mellon University): http://doi.ieeecomputersociety.org/10.1109/RTSS.2005.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. Paolo.Pagano@sssup.it

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 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”. Paolo.Pagano@sssup.it

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. [...]”. Paolo.Pagano@sssup.it

8. OS 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 Paolo.Pagano@sssup.it

9. TclCL OTcl scriptdescribing simulation OTcl C++ 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. Paolo.Pagano@sssup.it

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/ Paolo.Pagano@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 Paolo.Pagano@sssup.it

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. Paolo.Pagano@sssup.it

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. Paolo.Pagano@sssup.it

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. Paolo.Pagano@sssup.it

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. Paolo.Pagano@sssup.it

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. Paolo.Pagano@sssup.it

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 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) Paolo.Pagano@sssup.it

18. Screenshot of the Network AniMator (NAM) 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? Paolo.Pagano@sssup.it

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. Paolo.Pagano@sssup.it

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. Paolo.Pagano@sssup.it

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. Paolo.Pagano@sssup.it

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... Paolo.Pagano@sssup.it