1 / 96

What to expect when programming a WSN

What to expect when programming a WSN. Dr. Antonio Ruzzelli The CLARITY centre School of Computer Science and Informatics University College Dublin Ruzzelli@ucd.ie clarity-centre.com. SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli.

ulf
Download Presentation

What to expect when programming a WSN

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. What to expect when programming a WSN Dr. Antonio Ruzzelli The CLARITY centre School of Computer Science and Informatics University College Dublin Ruzzelli@ucd.ie clarity-centre.com SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli

  2. 1st partOpen Issues and programming environments SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli

  3. Summary • Typical WSN applications • Emerging WSN applications • New issues and system requirements • Summer School student statistics • Overview of WSN simulators • WSN operating systems • Medium access control in WSNs • A closer look at TinyOS • Component-based programming • How to make a new module SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli

  4. Typical WSN applications • Started with military applications • Smart dust • Environmental monitoring • Fire detection • Precision agriculture • Detection of • Temperature • Humidity • Light SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli

  5. Such applications require protocols that differ from traditional ones • Protocols for ad hoc networks to (e.g. WiFi) are aimed to obtain: • High bandwidth Utilization • Good fairness • Low latency of packets • High throughput These are generally the primary concerns in traditional wireless voice and data networks but in a typical sensor network they are secondary! SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli

  6. Typical challenges • Energy-efficiency at all layers • Network scalability • Self-organising routing • Time synchronization • Node localisation • Data aggregation • Node placements • Data mining/visualisation Senzation’08 - WSN Summer School in Ljubljana - Author Ruzzelli

  7. Emerging applications • Audio/Video over WSNs • Medical applications • Building automation • Sensor networks actuators • Traffic/pollution monitoring • WSN/mesh networks/RFID/Mobile integration The emerging applications are causing a convergence between sensor and ad-hoc/mesh networks Senzation’08 - WSN Summer School in Ljubljana - Author Ruzzelli

  8. Emerging requirements • Data rate much higher than in initial apps • Medical apps, • Real-time or near real-time transmission • voice over WSNs • Combination of more sensorial data • Mobility in sensor networks • Wearable sensor networks • Vehicular sensor networks • Good tools for network behaviour visibility and control Senzation’08 - WSN Summer School in Ljubljana - Author Ruzzelli

  9. Emerging Issues • Deadlines on packet delivery is hard • E.g. medical application, video/audio sensor networks • Network congestion in duty-cycled networks • Higher local data processing • Network programmability • Middleware • Network control • User interface • Integration between sensor, RFID and ad-hoc networks • Industrial/commercial applicaitons Are these issues studied also by the people attending to this school? Senzation’08 - WSN Summer School in Ljubljana - Author Ruzzelli

  10. Student statistics (1) • 22/43 replied to my email ~ 51% :( • Topics studied (some students are focusing on more than 1 topic): • Industrial apps: 5 people (22%) • Medical apps: 2 people (10%) • Routing: 6 people (30%) • Real time systems: 3 people (15%) • Localisation: 2 people (10%) • Looking for good topic: 2 people (10%) • Middleware: 2 people (10%) • Optimal deployment, image transmission, link quality sink mobility, wearable sensors: 1 person (10%) Senzation’08 - WSN Summer School in Ljubljana - Author Ruzzelli

  11. Student statistics (2) • Using TinyOS: 11 people 50% Simulators: • Matlab 5 people (~22%) • OmNet++ 3 people (~15%) • Ns2 2 people (~10%) • Tossim 4 people (~20%) • Students using only simulations: > 5 people (~25%) • Advise: Simulations on WSNs are not enough for a good PhD due to communication irregularities and system instability Senzation’08 - WSN Summer School in Ljubljana - Author Ruzzelli

  12. General PhD guidelines • Use a well known simulator for WSNs to help your work recognition; • Perform field tests: A PhD thesis should be supported by real results. • Simulations are important but studies demonstrated that real deployments often do not follow expectations • Some universities have open testbeds connected online that can be reserved for a certain time and used to test your algorithm • http://motelab.eecs.harvard.edu/ • Focus on a fundamental research that is useful for many and that has an industry value • Consult with your supervisor, mailing lists and experts in the related area as much as you can. Let’s have a look at specific tools needed for your PhD Senzation’08 - WSN Summer School in Ljubljana - Author Ruzzelli

  13. WSN Simulators • What specific features are we looking for? • Wireless transmissions and battery models • Easy to use • A simulator is a tool for your target not the target itself • Scalable: networks consist of >100 nodes • It should support long simulation time • Good technical support and documentation • It is better if well known communication protocols are already implemented • You want to concentrate on implementing your work and possibly without implementing some other works to compare against Senzation’08 - WSN Summer School in Ljubljana - Author Ruzzelli

  14. WSN Simulators • NS2/NS3 • Pros: Well-known simulator, -active mailing list -good development help -extensive documentation -large amount of contributing code. • Cons: -Limited GUI support -often complex to debug -not a component-based architecture • WSN frameworks: Mannasim, 802.15.4. • OmNet++ • Pros: Well-known WSN simulator, active mailing list, good GUI support, Component-based architecture. • Cons: Some scalability problems noticed for large-scale networks. • WSN frameworks: Castalia, Consensus, Mobility, NesCT. • JSIM • Pros: component-oriented architecture; extensibility; Platform indipendent mailing list; supports several protocols for WSNs (GPRS or AODV). • Cons: Less known to the research community than ns2 or OmNet++; Senzation’08 - WSN Summer School in Ljubljana - Author Ruzzelli

  15. WSN Simulators • Tossim • Pros: 1-Scalable to hundreds or thousands of motes 2-Code can be uploaded onto the Tinyos-based motes 3-Bit-level simulator • Cons: 1-Only known inside the WSNs research sphere 2-Can simulate on TinyOS only 3-No battery and CPU execution time models (unless recently added) 4-Cannot simulate different binaries running on different motes. • Qualnet (ex Glomosim) • Pros: 1-Good wireless models 2-easy to use, scalable 3-layered architecture 4- plug-in capability. • Cons: 1- not an open source 2-basic technical support by a community forum 3-some people experienced delay in the forum-based technical support 4- advanced support to purchase. Senzation’08 - WSN Summer School in Ljubljana - Author Ruzzelli

  16. WSN Operating systems Do we need an OS running onto the nodes? • No if a node run one application only. • Yes if a node is required to • Schedule parallel application executions • Meet deadlines (Real-time OS) • Prioritize some tasks Senzation’08 - WSN Summer School in Ljubljana - Author Ruzzelli

  17. RTOS for sensor networks • Q: Do we need a real time OS for WSNs? • In theory it would useful for real time applications (e.g. voice over WSNs), however: • RTOS not suitable for current WSN hardware • e.g. task preemption is very memory costly • The RT execution of a task (e.g. a deadline of packet transmission scheduling) may be nullified by MAC latency, collision and node duty-cycle As Zach Shelby said: “it is like putting a Ferrari engine on a Fiat 500” Senzation’08 - WSN Summer School in Ljubljana - Author Ruzzelli

  18. Programming environment • TinyOS • Contiki • Mantis • SOS • FreeRTOS • Nano-RK • BTnut • AmbientRT SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli

  19. TinyOS: a closer look Most advanced MAC used in TinyOS • XMAC (with LPL) over CC2420/2430 radios Routing in TinyOS: • Upstream: Collection Tree Protocol (CTP) based on Expected Transmissions (ETX) • Downstream: Dissemination protocol Latest version TinyOS 2.1 • FTSP time synchronization • SafeTinyOS • 802.15.4-2006 MAC implementation • support for 802.15.4 T-frame and I-frame • TOSThreads • Support for Iris and Shimmer platforms SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli

  20. Component-Oriented Programming • Object-Oriented • Concentrate on objects, methods and class relationships combined into an executable • Component-Oriented • Interchangeable code modules (files) that work independently and can be used through interfaces SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli

  21. Component-Oriented Programming • 3 file types in TinyOS: • Module (suffixed with P.nc) • Configuration (suffixed with C.nc) • Interface (suffixed with .nc) • A component is a combination of Configuration and a Module SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli

  22. msg_rec(type, data) msg_send_done) Tiny OS Concepts • Component has: • Internal state (storage) • Tasks: computation • Interface: • Command • Event • Internal state: static storage model - compile time memory allocation • Command and events are function calls Commands Events send_msg(addr, type, data) power(mode) init Messaging Component Internal tasks Internal State TX_packet(buf) Power(mode) RX_packet_done (buffer) init TX_packet_done (success) SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli

  23. TOS Component //AM.comp// TOS_MODULE AM; <ACCEPT COMMAND>{ char AM_SEND_MSG(char addr, char type, char* data); void AM_POWER(char mode); char AM_INIT(); }; <SIGNAL EVENT>{ char AM_MSG_REC(char type, char* data); char AM_MSG_SEND_DONE(char success); }; <HANDLE EVENT>{ char AM_TX_PACKET_DONE(char success); char AM_RX_PACKET_DONE(char* packet); }; <USE COMMAND >{ char AM_SUB_TX_PACKET(char* data); void AM_SUB_POWER(char mode); char AM_SUB_INIT(); }; AM_SEND_MSG AM_POWER AM_INIT AM_MSG_SEND_DONE AM_MSG_REC Messaging Component Internal State Internal Tasks AM_SUB_POWER AM_TX_PACKET_DONE AM_RX_PACKET_DONE AM_SUB_TX_PACKET AM_SUB_INIT Commands Events SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli

  24. Tasks Preempt POST FIFO events commands commands Interrupts Time Hardware TinyOS Two-level Scheduling • Tasks do computations • Events handle concurrent dataflows Events generated by interrupts preempt tasks Tasks do not preempt tasks Both essential process state transitions SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli

  25. Component-Oriented Programming Modules (componentNameP.nc) • Implement the core functionalities of the module (commands) • Provide interfaces to other modules. • Use interfaces from other modules. //E.g. Energy module to calculate the node energy consumption by software #include "Energy.h” module EnergyP { provides { interface Energy; } uses{ interface Leds; interface Timer<Tmilli> as General; interface Timer<Tmilli> as TimerLed; interface Counter<TMicro, uint16_t> as AwakeTimer; … } } Implementation { … SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli

  26. Component-Oriented Programming Configurations (componentNameC.nc) • Wire interfaces from several modules together. • May forward interfaces from external modules to internal modules. • May contain sub-configurations. //E.g. Energy module to calculate the node energy consumption by software configuration EnergyC { provides interface Energy; } implementation { components EnergyP, LedsC, new TimerMilliC(), Msp430CounterMicroC; Energy = EnergyP; EnergyP.Leds -> LedsC; EnergyP.General -> TimerMilliC; EnergyP.TimerLed -> TimerMilliC; EnergyP.Timer -> Msp430CounterMicroC; EnergyP.Msp430CounterMicro -> Msp430CounterMicroC; } SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli

  27. Component-Oriented Programming Interfaces (componentName.nc) • Define the interactions between modules • Commands • Implemented by the module providing the interface • Called by the module using the interface • Events • Signaled by the module providing the interface • Captured by the module using the interface //E.g. Energy module to calculate the node energy consumption by software interface Energy { command uint32_t getPartialEnergy(uint16_t awakeDutyCycle); command uint32_t getTotalEnergy(uint16_t awakeDutyCycle); command uint32_t getRadioEnergy(uint16_t awakeDutyCycle); command uint32_t getMcuEnergy(uint16_t awakeDutyCycle); command uint32_t getLedEnergy(); async command void startSend(); async command void stopSend(); command void startTimer();command void stopTimer(); event void scaleVariation(uint16_t val, uint16_t valMcu, uint16_t valTotal); . . . } SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli

  28. A Complete Application sensing application application Routing Layer routing Messaging Layer messaging Radio Packet packet Radio byte (MAC) Temp byte photo SW HW RFM ADC i2c bit clocks SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli

  29. Component connections Generated with graphviz within TinyOS: make telosb docs SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli

  30. TinyOS in summary • Small memory footprint  • Non-preemptable FIFO task scheduling • Power efficient  • Put microcontroller and radio to sleep • Efficient modularity  • Function call (event, command) interface between components • Concurrency-intensive operations  • Event-driven architecture • Efficient interrupts/events handling (function calls, no user/kernel boundary) • Real-time  • Non-preemptable FIFO task scheduling • NO real-time guarantees or overload protection SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli

  31. How to use the energy module in TinyOS • Download the bundle file of the software-based energy tracking from http://www.cs.ucd.ie/octopus • The module can timestamp activity of the radio and further hardware components • It requires that the energy command is called in few appropriate components -->Only a couple of lines modification • Follow the steps in the readme.txt instructions in the bundle file • Include the energy interface in your application file to obtain the live estimation of the energy consumed by the node. SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli

  32. Compiling a TinyOS app TinyOS nesC GCC SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli

  33. A look at MAC issues in WSNs SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli

  34. WSNs introduced a new concept of access control • To reduce the energy consumption, MAC protocols tailored for WSNs have introduced a novel concept: • The node duty Cycle and Wakeup concepts • nodes alternate periods of radio activity to periods inactivity Listening period Sleep period Wakeup period Time SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli

  35. Issues in Duty-cycled MAC • Transmission Latency --> Low throughput • A transmitter must wait for the receiver to wake-up • A packet should be transmitted when the receiver is awake • Node synchronization/beacons (802.15.4) • Carrier Sense/long preamble (BMAC/XMAC) SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli

  36. One PAN coordinator Zero or more coordinators Zero or more end devices First device starts the network as PAN coordinator A new device can detect all coordinators (both the PAN coordinator and coordinators) A device can join the network by associating with any coordinator in range After joining a device can volunteer as coordinator PAN coordinator Coordinator End device 802.15.4 Network formation SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli

  37. Device starts network scan (MLME_SCAN) Detects no network Starts new network as PAN coordinator (MLME_START with PANCoordinator=TRUE) If PANCoord then other devices in range can discover device 1 by means of a network scan PAN coordinator Coordinator FFD End device RFD Step 1: Starting a new network 1 SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli

  38. Device 2 starts network scan (MLME_SCAN) Detects PAN coordinator device 1 Sends association request to device 1 (MLME_ASSOCIATE) Node2 is now and End device  Other devices cannot discover device 2 by means of a network scan PAN coordinator Coordinator FFD End device RFD Step 2: a device joins the network 1 2 range SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli

  39. Device 2 starts serving as a coordinator of the existing network (MLME_START with PANCoordinator=FALSE, PANId & channel parameters are ignored) Node2 is now Other devices in range can now discover device 2 by means of a network scan PAN coordinator Coordinator FFD End device RFD Step 3: Device 2 becomes a coordinator 1 2 SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli

  40. Device 3 starts network scan (MLME_SCAN) Detects coordinator device 2(assuming device 1 is not in range of device 3) Sends association request to device 2 (MLME_ASSOCIATE) Note: Other devices cannot discover device 3 by means of a network scan PAN coordinator Coordinator FFD End device RFD Step 4: Device 3 joins the network 1 2 3 range SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli

  41. Device 4 starts network scan (MLME_SCAN) Detects two coordinators: device 1 and device 2(assuming device 1 and device 2 are in range of device 4) Sends association request to device 1 (MLME_ASSOCIATE)(alternatively it could join the network also through device 2) Note: Other devices cannot discover device 4 by means of a network scan PAN coordinator Coordinator FFD End device RFD Step 5: Device 4 joins the network 1 4 range 2 3 SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli

  42. Device 4 starts serving as a coordinator of the existing network (MLME_START with PANCoordinator=FALSE, PANId & channel parameters are ignored) Note: Other devices in range can now discover device 4 by means of a network scan PAN coordinator Coordinator FFD End device RFD Step 6: Device 4 becomes a coordinator 1 4 2 3 SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli

  43. 802.15.4 short unique addressing not handled IEEE 802.15.4 does not define network-wide unique short MAC addresses assigned by coordinators. Extended MAC addresses can be used instead of short addresses but with High packet overhead PAN coordinator Coordinator FFD End device RFD Other devices can join in the same way 5 6 1 4 2 range 7 8 3 SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli

  44. Beacons are prone to collide as transmitted without CSMA If a beacon collides then all RFD children are isolated. FFDs are 100% likely to be the time active as they have to relay information Issue 1: Beacons are weak and uncoordinated 1 4 Beacon 9 2 7 Tx Beacon Beacon 8 10 3 11 SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli

  45. No coordination between FFDs is provided End devices (RFDs) can talk to its coordinator only  packet collisions might occur 1) Eg. Node9 transmitting to node2 might generate collision at node8 that is receiving from node11. 2) Eg. node7 transmission might prevent correct neighbouring node 10 reception PAN coordinator Coordinator FFD End device RFD Issue 2: The hidden association problem 5 6 1 4 9 2 range 7 8 10 3 11 SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli

  46. Devices are of two types: Base station (the gateway to the PC) Motes Motes form a peer-to peer Network  All motes are full functional Can route packets Can sense the channel Can send to any neighbour PAN coordinator Coordinator FFD End device RFD Standard networking in TinyOS 5 6 1 4 9 2 range 7 8 10 3 11 SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli

  47. The long-preamble approach in TinyOS • The long preamble and low power listening adopted in duty-cycled MAC protocols such as BMAC and XMAC (with a variation of the preamble for the CC2420 radio) • Pros: Avoids synchronizing the nodes • Cons: It creates congestion for high data rate scenario Long preamble Packet Carrier Sense Transmitter Receiver Low power listening period Time SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli

  48. End of the 1st part Thanks for your attention Any questions? SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli

  49. 2nd part:The Octopus Dashboard As applications get more demanding, There is a strong need for tools that empower developers and users to interact and control a sensor network …Towards the evolution of a GUI for Sensor Networks SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli

  50. Why a visual control tool for WSN • To help developers in: • Network debugging • Network assessment • Understanding routing patterns • Gaining an insight of network topology • To empower users with a user-friendly tool to: • Formulate multiple application queries • Tune parameters according to user needs • Localise nodes on a floor map SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli

More Related