Ad hoc and Sensor Networks Chapter 2: Single node architecture

1. Ad hoc and Sensor NetworksChapter 2: Single node architecture Holger Karl

2. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 2 Goals of this chapter Survey the main components of the composition of a node for a wireless sensor network Controller, radio modem, sensors, batteries Understand energy consumption aspects for these components Putting into perspective different operational modes and what different energy/power consumption means for protocol design Operating system support for sensor nodes Some example nodes Note: The details of this chapter are quite specific to WSN; energy consumption principles carry over to MANET as well

3. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 3 Outline Sensor node architecture Energy supply and consumption Runtime environments for sensor nodes Case study: TinyOS

4. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 4 Sensor node architecture Main components of a WSN node Controller Communication device(s) Sensors/actuators Memory Power supply

5. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 5 Ad hoc node architecture Core: essentially the same But: Much more additional equipment Hard disk, display, keyboard, voice interface, camera, � Essentially: a laptop-class device

6. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 6 Controller Main options: Microcontroller � general purpose processor, optimized for embedded applications, low power consumption DSPs � optimized for signal processing tasks, not suitable here FPGAs � may be good for testing ASICs � only when peak performance is needed, no flexibility Example microcontrollers Texas Instruments MSP430 16-bit RISC core, up to 4 MHz, versions with 2-10 kbytes RAM, several DACs, RT clock, prices start at 0.49 US$ Atmel ATMega 8-bit controller, larger memory than MSP430, slower

7. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 7 Custom single-purpose processor basic model

8. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 8 Example: greatest common divisor First create algorithm Convert algorithm to �complex� state machine Known as FSMD: finite-state machine with datapath Can use templates to perform such conversion

9. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 9 State diagram templates

10. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 10 Creating the datapath Create a register for any declared variable Create a functional unit for each arithmetic operation Connect the ports, registers and functional units Based on reads and writes Use multiplexors for multiple sources Create unique identifier for each datapath component control input and output

11. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 11 Creating the controller�s FSM Same structure as FSMD Replace complex actions/conditions with datapath configurations

12. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 12 Splitting into a controller and datapath

13. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 13 Controller state table for the GCD example

14. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 14 Completing the GCD custom single-purpose processor design We finished the datapath We have a state table for the next state and control logic All that�s left is combinational logic design This is not an optimized design, but we see the basic steps

15. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 15 Communication device Which transmission medium? Electromagnetic at radio frequencies? Electromagnetic, light? Ultrasound? Radio transceivers transmit a bit- or byte stream as radio wave Receive it, convert it back into bit-/byte stream

16. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 16 Transceiver characteristics Capabilities Interface: bit, byte, packet level? Supported frequency range? Typically, somewhere in 433 MHz � 2.4 GHz, ISM band Multiple channels? Data rates? Range? Energy characteristics Power consumption to send/receive data? Time and energy consumption to change between different states? Transmission power control? Power efficiency (which percentage of consumed power is radiated?) Radio performance Modulation? (ASK, FSK, �?) Noise figure? NF = SNRI/SNRO Gain? (signal amplification) Receiver sensitivity? (minimum S to achieve a given Eb/N0) Blocking performance (achieved BER in presence of frequency-offset interferer) Out of band emissions Carrier sensing & RSSI characteristics Frequency stability (e.g., towards temperature changes) Voltage range

17. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 17 Transceiver states Transceivers can be put into different operational states, typically: Transmit Receive Idle � ready to receive, but not doing so Some functions in hardware can be switched off, reducing energy consumption a little Sleep � significant parts of the transceiver are switched off Not able to immediately receive something Recovery time and startup energy to leave sleep state can be significant Research issue: Wakeup receivers � can be woken via radio when in sleep state (seeming contradiction!)

18. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 18 Example radio transceivers Almost boundless variety available Some examples RFM TR1000 family 916 or 868 MHz 400 kHz bandwidth Up to 115,2 kbps On/off keying or ASK Dynamically tuneable output power Maximum power about 1.4 mW Low power consumption Chipcon CC1000 Range 300 to 1000 MHz, programmable in 250 Hz steps FSK modulation Provides RSSI Chipcon CC 2400 Implements 802.15.4 2.4 GHz, DSSS modem 250 kbps Higher power consumption than above transceivers Infineon TDA 525x family E.g., 5250: 868 MHz ASK or FSK modulation RSSI, highly efficient power amplifier Intelligent power down, �self-polling� mechanism Excellent blocking performance

19. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 19 Example radio transceivers for ad hoc networks Ad hoc networks: Usually, higher data rates are required Typical: IEEE 802.11 b/g/a is considered Up to 54 MBit/s Relatively long distance (100s of meters possible, typical 10s of meters at higher data rates) Works reasonably well (but certainly not perfect) in mobile environments Problem: expensive equipment, quite power hungry

20. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 20 Wakeup receivers Major energy problem: RECEIVING Idling and being ready to receive consumes considerable amounts of power When to switch on a receiver is not clear Contention-based MAC protocols: Receiver is always on TDMA-based MAC protocols: Synchronization overhead, inflexible Desirable: Receiver that can (only) check for incoming messages When signal detected, wake up main receiver for actual reception Ideally: Wakeup receiver can already process simple addresses Not clear whether they can be actually built, however

21. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 21 Optical communication Optical communication can consume less energy Example: passive readout via corner cube reflector Laser is reflected back directly to source if mirrors are at right angles Mirrors can be �titled� to stop reflecting ! Allows data to be sent back to laser source

22. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 22 Ultra-wideband communication Standard radio transceivers: Modulate a signal onto a carrier wave Requires relatively small amount of bandwidth Alternative approach: Use a large bandwidth, do not modulate, simply emit a �burst� of power Forms almost rectangular pulses Pulses are very short Information is encoded in the presence/absence of pulses Requires tight time synchronization of receiver Relatively short range (typically) Advantages Pretty resilient to multi-path propagation Very good ranging capabilities Good wall penetration

23. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 23 Sensors as such Main categories Any energy radiated? Passive vs. active sensors Sense of direction? Omidirectional? Passive, omnidirectional Examples: light, thermometer, microphones, hygrometer, � Passive, narrow-beam Example: Camera Active sensors Example: Radar Important parameter: Area of coverage Which region is adequately covered by a given sensor?

24. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 24 Outline Sensor node architecture Energy supply and consumption Runtime environments for sensor nodes Case study: TinyOS

25. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 25 Energy supply of mobile/sensor nodes Goal: provide as much energy as possible at smallest cost/volume/weight/recharge time/longevity In WSN, recharging may or may not be an option Options Primary batteries � not rechargeable Secondary batteries � rechargeable, only makes sense in combination with some form of energy harvesting Requirements include Low self-discharge Long shelf live Capacity under load Efficient recharging at low current Good relaxation properties (seeming self-recharging) Voltage stability (to avoid DC-DC conversion)

26. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 26 Battery examples Energy per volume (Joule per cubic centimeter):

27. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 27 Energy scavenging How to recharge a battery? A laptop: easy, plug into wall socket in the evening A sensor node? � Try to scavenge energy from environment Ambient energy sources Light ! solar cells � between 10 ?W/cm2 and 15 mW/cm2 Temperature gradients � 80 ? W/cm2 @ 1 V from 5K difference Vibrations � between 0.1 and 10000 ? W/cm3 Pressure variation (piezo-electric) � 330 ? W/cm2 from the heel of a shoe Air/liquid flow (MEMS gas turbines)

28. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 28 Energy scavenging � overview

29. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 29 Energy consumption A �back of the envelope� estimation Number of instructions Energy per instruction: 1 nJ Small battery (�smart dust�): 1 J = 1 Ws Corresponds: 109 instructions! Lifetime Or: Require a single day operational lifetime = 24�60�60 =86400 s 1 Ws / 86400s � 11.5 ?W as max. sustained power consumption! Not feasible!

30. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 30 Multiple power consumption modes Way out: Do not run sensor node at full operation all the time If nothing to do, switch to power safe mode Question: When to throttle down? How to wake up again? Typical modes Controller: Active, idle, sleep Radio mode: Turn on/off transmitter/receiver, both Multiple modes possible, �deeper� sleep modes Strongly depends on hardware TI MSP 430, e.g.: four different sleep modes Atmel ATMega: six different modes

31. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 31 Some energy consumption figures Microcontroller TI MSP 430 (@ 1 MHz, 3V): Fully operation 1.2 mW Deepest sleep mode 0.3 ?W � only woken up by external interrupts (not even timer is running any more) Atmel ATMega Operational mode: 15 mW active, 6 mW idle Sleep mode: 75 ?W

32. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 32 Switching between modes Simplest idea: Greedily switch to lower mode whenever possible Problem: Time and power consumption required to reach higher modes not negligible Introduces overhead Switching only pays off if Esaved > Eoverhead Example: Event-triggered wake up from sleep mode Scheduling problem with uncertainty (exercise)

33. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 33 Alternative: Dynamic voltage scaling Switching modes complicated by uncertainty how long a sleep time is available Alternative: Low supply voltage & clock Dynamic voltage scaling (DVS) Rationale: Power consumption P depends on Clock frequency Square of supply voltage P / f V2 Lower clock allows lower supply voltage Easy to switch to higher clock But: execution takes longer

34. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 34 Memory power consumption Crucial part: FLASH memory Power for RAM almost negligible FLASH writing/erasing is expensive Example: FLASH on Mica motes Reading: � 1.1 nAh per byte Writing: � 83.3 nAh per byte

35. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 35 Transmitter power/energy consumption for n bits Amplifier power: Pamp = ?amp + ?amp Ptx Ptx radiated power ?amp, ?amp constants depending on model Highest efficiency (? = Ptx / Pamp ) at maximum output power In addition: transmitter electronics needs power PtxElec Time to transmit n bits: n / (R � Rcode) R nomial data rate, Rcode coding rate To leave sleep mode Time Tstart, average power Pstart ! Etx = Tstart Pstart + n / (R � Rcode) (PtxElec + ?amp + ?amp Ptx) Simplification: Modulation not considered A = 174, beta= 4 -> berechne effizienz A = 174, beta= 4 -> berechne effizienz

36. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 36 Receiver power/energy consumption for n bits Receiver also has startup costs Time Tstart, average power Pstart Time for n bits is the same n / (R � Rcode) Receiver electronics needs PrxElec Plus: energy to decode n bits EdecBits ! Erx = Tstart Pstart + n / (R � Rcode) PrxElec + EdecBits ( R )

37. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 37 Some transceiver numbers

38. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 38 Comparison: GSM base station power consumption Overview Details (just to put things into perspective)

39. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 39 Controlling transceivers Similar to controller, low duty cycle is necessary Easy to do for transmitter � similar problem to controller: when is it worthwhile to switch off Difficult for receiver: Not only time when to wake up not known, it also depends on remote partners ! Dependence between MAC protocols and power consumption is strong! Only limited applicability of techniques analogue to DVS Dynamic Modulation Scaling (DSM): Switch to modulation best suited to communication � depends on channel gain Dynamic Coding Scaling � vary coding rate according to channel gain Combinations

40. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 40 Computation vs. communication energy cost Tradeoff? Directly comparing computation/communication energy cost not possible But: put them into perspective! Energy ratio of �sending one bit� vs. �computing one instruction�: Anything between 220 and 2900 in the literature To communicate (send & receive) one kilobyte = computing three million instructions! Hence: try to compute instead of communicate whenever possible Key technique in WSN � in-network processing! Exploit compression schemes, intelligent coding schemes, �

41. WSN Platforms: Hardware & Software Murat Demirbas Lecture uses some slides from tutorials prepared by authors of these platforms

42. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 42 Why use a WSN? Ease of deployment Wireless communication means no need for a communication infrastructure setup Drop and play Low-cost of deployment Nodes are built using off-the-shelf cheap components Fine grain monitoring Feasible to deploy nodes densely for fine grain monitoring

43. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 43 Outline Hardware RFID, Spec Mica2, XSM, Telos Stargate Software TinyOS Simulation TOSSIM Prowler

44. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 44 Types of sensor platforms RFID equipped sensors Smart-dust tags typically act as data-collectors or �trip-wires� limited processing and communications Mote/Stargate-scale nodes more flexible processing and communications More powerful gateway nodes, potentially using wall power

45. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 45 Popular Nodes Overview

46. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 46 Grain-sized nodes Powered by inductive coupling to a transmission from a reader device to transmit a message back Available commercially at very low prices Computation power is severely limited Can only trasmit stored unique id and variable Hard to add any interesting sensing capability

47. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 47 Spec Mote (3/6/2003) size: 2x2.5mm, AVR RISC core, 3KB memory, FSK radio (CC1000), encrypted communication hardware support, memory-mapped active messages

48. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 48 Matchbox-sized nodes Mica series, XSM node, Telos 8-bit microprocessor, 4MHz CPU ATMEGA 128, ATMEL 8535, or Motorola HCS08 ~4Kb RAM holds run-time state (values of the variables) of the program ~128Kb programmable Flash memory holds the application program Downloaded via a programmer-board or wirelessly Additional Flash memory storage space up to 512Kb.

49. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 49 Mica2 and Mica2Dot ATmega128 CPU Self-programming Chipcon CC1000 FSK Manchester encoding Tunable frequency Low power consumption 2 AA battery = 3V

50. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 50 Basic Sensor Board Light (Photo) Temperature Prototyping space for new hardware designs

51. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 51 Mica Sensor Board Light (Photo) Temperature Acceleration 2 axis Resolution: �2mg Magnetometer Resolution: 134mG Microphone Tone Detector Sounder 4.5kHz

52. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 52 PNI Magnetometer/Compass Resolution: 400 mGauss Three axis, under $15 in large quantities

53. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 53 Ultrasonic Transceiver Used for ranging Up to 2.5m range 6cm accuracy Dedicated microprocessor 25kHz element

54. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 54 Mica Weather Board Total Solar Radiation Photosynthetically Active Radiation Resolution: 0.3A/W Relative Humidity Accuracy: �2% Barometric Pressure Accuracy: �1.5mbar Temperature Accuracy: �0.01oC Acceleration 2 axis Resolution: �2mg Designed by UCB w/ Crossbow and UCLA

55. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 55 MicaDot Sensor Boards

56. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 56 XSM node platform Derived from Mica2 mote Better sensor & actuator range 4 Passive Infrared: ~ 25m for SUV Sounder: ~10m Microphone: ~ 50m for ATV Magnetometer: ~ 7m for SUV Better radio range ~30m Other features: Grenade timer Wakeup circuits (Mic, PIR) Adjustable frequency sounder Integrated Mag Set/Reset

57. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 57 Telos Platform Low Power Minimal port leakage Hardware isolation and buffering Robust Hardware flash write protection Integrated antenna (50m-125m) Standard IDC connectors Standards Based USB IEEE 802.15.4 (CC2420 radio) High Performance 10kB RAM, 16-bit core, extensive double buffering 12-bit ADC and DAC (200ksamples/sec) DMA transfers while CPU off

58. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 58 TelosMeeting the Low Power Goal

59. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 59 Telos Performance 200ksamples/sec sampling rate, DMA transfers, DAC Increased performance & functionality over existing designs New �link quality indicator� predicts average packet loss

60. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 60 Brick-sized node: Stargate Mini Linux computers communicating via 802.11 radios Computationally powerful High bandwidth Requires more energy (AA infeasible) Used as a gateway between the Internet and WSN

61. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 61 Stargate

62. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 62 Manufacturers of Sensor Nodes Crossbow (www.xbow.com) Mica2 mote, Micaz, Dot mote and Stargate Platform Intel Research Stargate, iMote Moteiv � Telos Mote Dust Inc Smart Dust Cogent Computer (www.cogcomp.com) XYZ Node (CSB502) in collaboration with ENALAB@Yale Sensoria Corporation (www.sensoria.com) WINS NG Nodes Millenial Net (www.millenial.com) iBean sensor nodes Ember (www.ember.com) Integrated IEEE 802.15.4 stack and radio on a single chip

63. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 63 Challenges in sensor networks Energy constraint Unreliable communication Unreliable sensors Ad hoc deployment Large scale networks Limited computation power Distributed execution Nodes are battery powered Radio broadcast, limited bandwidth, bursty traffic False positives Pre-configuration inapplicable Algorithms should scale well Centralized algorithms inapplicable Difficult to debug & get it right

64. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 64 Opportunities in sensor networks Precise clock at each node Atomic broadcast primitive Geometry New applications Timers, synchronized clocks All recipients hear the same message at the same time Dense nodes over 2D plane Tracking, spatial querying, geographic routing, localization, network reprogramming, etc. In response to a bcast, the nodes that receive a non null value receive the same value.In response to a bcast, the nodes that receive a non null value receive the same value.

65. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 65 Outline Sensor node architecture Energy supply and consumption Runtime environments for sensor nodes Case study: TinyOS

66. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 66 Operating system challenges in WSN Usual operating system goals Make access to device resources abstract (virtualization) Protect resources from concurrent access Usual means Protected operation modes of the CPU � hardware access only in these modes Process with separate address spaces Support by a memory management unit Problem: These are not available in microcontrollers No separate protection modes, no memory management unit Would make devices more expensive, more power-hungry ! ???

67. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 67 Operating system challenges in WSN Possible options Try to implement �as close to an operating system� on WSN nodes In particular, try to provide a known programming interface Namely: support for processes! Sacrifice protection of different processes from each other ! Possible, but relatively high overhead Do (more or less) away with operating system After all, there is only a single �application� running on a WSN node No need to protect malicious software parts from each other Direct hardware control by application might improve efficiency Currently popular verdict: no OS, just a simple run-time environment Enough to abstract away hardware access details Biggest impact: Unusual programming model

68. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 68 Main issue: How to support concurrency Simplest option: No concurrency, sequential processing of tasks Not satisfactory: Risk of missing data (e.g., from transceiver) when processing data, etc. ! Interrupts/asynchronous operation has to be supported Why concurrency is needed Sensor node�s CPU has to service the radio modem, the actual sensors, perform computation for application, execute communication protocol software, etc.

69. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 69 Traditional concurrency: Processes Traditional OS: processes/threads Based on interrupts, context switching But: not available � memory overhead, execution overhead But: concurrency mismatch One process per protocol entails too many context switches Many tasks in WSN small with respect to context switching overhead And: protection between processes not needed in WSN Only one application anyway

70. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 70 Event-based concurrency Alternative: Switch to event-based programming model Perform regular processing or be idle React to events when they happen immediately Basically: interrupt handler Problem: must not remain in interrupt handler too long Danger of loosing events Only save data, post information that event has happened, then return ! Run-to-completion principle Two contexts: one for handlers, one for regular execution

71. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 71 Components instead of processes Need an abstraction to group functionality Replacing �processes� for this purpose E.g.: individual functions of a networking protocol One option: Components Here: In the sense of TinyOS Typically fulfill only a single, well-defined function Main difference to processes: Component does not have an execution Components access same address space, no protection against each other NOT to be confused with component-based programming!

72. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 72 API to an event-based protocol stack Usual networking API: sockets Issue: blocking calls to receive data Ill-matched to event-based OS Also: networking semantics in WSNs not necessarily well matched to/by socket semantics API is therefore also event-based E.g.: Tell some component that some other component wants to be informed if and when data has arrived Component will be posted an event once this condition is met Details: see TinyOS example discussion below

73. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 73 Dynamic power management Exploiting multiple operation modes is promising Question: When to switch in power-safe mode? Problem: Time & energy overhead associated with wakeup; greedy sleeping is not beneficial (see exercise) Scheduling approach Question: How to control dynamic voltage scaling? More aggressive; stepping up voltage/frequency is easier Deadlines usually bound the required speed form below Or: Trading off fidelity vs. energy consumption! If more energy is available, compute more accurate results Example: Polynomial approximation Start from high or low exponents depending where the polynomial is to be evaluated

74. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 74 Outline Sensor node architecture Energy supply and consumption Runtime environments for sensor nodes Case study: TinyOS

75. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 75 Case study embedded OS: TinyOS & nesC TinyOS developed by UC Berkely as runtime environment for their �motes� nesC as adjunct �programming language� Goal: Small memory footprint Sacrifices made e.g. in ease of use, portability Portability somewhat improved in newer version Most important design aspects Component-based system Components interact by exchanging asynchronous events Components form a program by wiring them together (akin to VHDL � hardware description language)

76. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 76 TinyOS components Components Frame � state information Tasks � normal execution program Command handlers Event handlers Handlers Must run to completion Form a component�s interface Understand and emits commands & events Hierarchically arranged Events pass upward from hardware to higher-level components Commands are passed downward

77. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 77 Handlers versus tasks Command handlers and events must run to completion Must not wait an indeterminate amount of time Only a request to perform some action Tasks, on the other hand, can perform arbitrary, long computation Also have to be run to completion since no non-cooperative multi-tasking is implemented But can be interrupted by handlers ! No need for stack management, tasks are atomic with respect to each other

78. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 78 Split-phase programming Handler/task characteristics and separation has consequences on programming model How to implement a blocking call to another component? Example: Order another component to send a packet Blocking function calls are not an option ! Split-phase programming First phase: Issue the command to another component Receiving command handler will only receive the command, post it to a task for actual execution and returns immediately Returning from a command invocation does not mean that the command has been executed! Second phase: Invoked component notifies invoker by event that command has been executed Consequences e.g. for buffer handling Buffers can only be freed when completion event is received

79. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 79 Structuring commands/events into interfaces Many commands/events can add up nesC solution: Structure corresponding commands/events into interface types Example: Structure timer into three interfaces StdCtrl Timer Clock

80. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 80 Building components out of simpler ones Wire together components to form more complex components out of simpler ones New interfaces for the complex component

81. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 81 Defining modules and components in nesC

82. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 82 Wiring components to form a configuration

83. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 83 TinyOS most popular operating system for WSN developed by UC Berkeley features a component-based architecture software is written in modular pieces called components Each component denotes the interfaces that it provides An interface declares a set of functions called commands that the interface provider implements and another set of functions called events that the interface user should be ready to handle Easy to link components together by �wiring� their interfaces to form larger components similar to using Lego blocks

84. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 84 TinyOS provides a component library that includes network protocols, services, and sensor drivers An application consists of a component written by the application developer and the library components that are used by the components in (1) An application developer writes only the application component that describes the sensors used in the application, the middleware services configured with the appropriate parameters based on the needs of the application

85. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 85 Benefits of using TinyOS Separation of concerns TinyOS provides a proper networking stack for wireless communication that abstracts away the underlying problems and complexity of message transfer from the application developer E.g., MAC layer Concurrency control TinyOS provides a scheduler that achieves efficient concurrency control An interrupt-driven execution model is needed to achieve a quick response time for the events and capture the data For example, a message transmission may take up to 100msec, and without an interrupt-driven approach the node would miss sensing and processing of interesting data in this period Scheduler takes care of the intricacies of interrupt-driven execution and provides concurrency in a safe manner by scheduling the execution in small threads.

86. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 86 Benefits of TinyOS Modularity TinyOS�s component model facilitates reuse and reconfigurability since software is written in small functional modules. Several middleware services are available as well-documented components Over 500 research groups and companies are using TinyOS and numerous groups are actively contributing code to the public domain

87. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 87 TinyOS Microthreaded OS (lightweight thread support) and efficient network interfaces Two level scheduling structure Long running tasks that can be interrupted by hardware events Small, tightly integrated design that allows crossover of software components into hardware

88. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 88 TinyOS Concepts Scheduler + Graph of Components constrained two-level scheduling model: threads + events Component: Commands Event Handlers Frame (storage) Tasks (concurrency) Constrained Storage Model frame per component, shared stack, no heap Very lean multithreading Efficient Layering

89. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 89 Application = Graph of Components

90. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 90 TOS Execution Model commands request action ack/nack at every boundary call command or post task events notify occurrence HW interrupt at lowest level may signal events call commands post tasks tasks provide logical concurrency preempted by events

91. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 91 Event-Driven Sensor Access Pattern clock event handler initiates data collection sensor signals data ready event data event handler calls output command device sleeps or handles other activity while waiting conservative send/ack at component boundary

92. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 92 TinyOS Commands and Events

93. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 93 TinyOS Execution Contexts Events generated by interrupts preempt tasks Tasks do not preempt tasks Both essential process state transitions

94. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 94 Tasks provide concurrency internal to a component longer running operations are preempted by events able to perform operations beyond event context may call commands may signal events not preempted by tasks

95. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 95 Typical Application Use of Tasks event driven data acquisition schedule task to do computational portion

96. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 96 Task Scheduling Currently simple fifo scheduler Bounded number of pending tasks When idle, shuts down node except clock Uses non-blocking task queue data structure Simple event-driven structure + control over complete application/system graph instead of complex task priorities

97. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 97 Maintaining Scheduling Agility Need logical concurrency at many levels of the graph While meeting hard timing constraints sample the radio in every bit window Retain event-driven structure throughout application Tasks extend processing outside event window All operations are non-blocking

98. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 98 The Complete Application

99. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 99 Programming Syntax TinyOS 2.0 is written in an extension of C, called nesC Applications are too just additional components composed with OS components Provides syntax for TinyOS concurrency and storage model commands, events, tasks local frame variable Compositional support separation of definition and linkage robustness through narrow interfaces and reuse Interpositioning Whole system analysis and optimization

100. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 100 Components A component specifies a set of interfaces by which it is connected to other components provides a set of interfaces to others uses a set of interfaces provided by others Interfaces are bidirectional include commands and events Interface methods are the external namespace of the component

101. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 101 Component Interface logically related set of commands and events

102. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 102 Component Types Configurations link together components to compose new component configurations can be nested complete �main� application is always a configuration Modules provides code that implements one or more interfaces and internal behavior

103. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 103 Example1 Blink application

104. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 104 Example1 BlinkM module:

105. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 105 Example2

106. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 106 Nested Configuration

107. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 107 IntToRfm Module

108. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 108 Atomicity Support in nesC Split phase operations require care to deal with pending operations Race conditions may occur when shared state is accessed by premptible executions, e.g. when an event accesses a shared state, or when a task updates state (premptible by an event which then uses that state) nesC supports atomic block implemented by turning of interrupts for efficiency, no calls are allowed in block access to shared variable outside atomic block is not allowed

109. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 109 Supporting HW Evolution Distribution broken into apps: top-level applications tos: lib: shared application components system: hardware independent system components platform: hardware dependent system components includes HPLs and hardware.h interfaces tools: development support tools contrib beta Component design so HW and SW look the same example: temp component may abstract particular channel of ADC on the microcontroller may be a SW I2C protocol to a sensor board with digital sensor or ADC HW/SW boundary can move up and down with minimal changes

110. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 110 Sending a Message

111. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 111 Send done Event Send done event fans out to all potential senders Originator determined by match free buffer on success, retry or fail on failure Others use the event to schedule pending communication

112. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 112 Receive Event Active message automatically dispatched to associated handler knows format, no run-time parsing performs action on message event Must return free buffer to the system typically the incoming buffer if processing complete

113. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 113 Tiny Active Messages Sending declare buffer storage in a frame request transmission name a handler handle completion signal Receiving declare a handler firing a handler: automatic Buffer management strict ownership exchange tx: send done event ? reuse rx: must return a buffer

114. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 114 Tasks in Low-level Operation transmit packet send command schedules task to calculate CRC task initiates byte-level data pump events keep the pump flowing receive packet receive event schedules task to check CRC task signals packet ready if OK byte-level tx/rx task scheduled to encode/decode each complete byte must take less time that byte data transfer

115. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 115 TinyOS tools TOSSIM: a simulator for tinyos programs ListenRaw, SerialForwarder: java tools to receive raw packets on PC from base node Oscilloscope: java tool to visualize (sensor) data in real time Memory usage: breaks down memory usage per component (in contrib) Peacekeeper: detect RAM corruption due to stack overflows (in lib) Stopwatch: tool to measure execution time of code block by timestamping at entry and exit (in osu CVS server) Makedoc and graphviz: generate and visualize component hierarchy Surge, Deluge, SNMS, TinyDB

116. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 116 TinyOS Limitations Static allocation allows for compile-time analysis, but can make programming harder No support for heterogeneity Support for other platforms (e.g. stargate) Support for high data rate apps (e.g. acoustic beamforming) Interoperability with other software frameworks and languages Limited visibility Debugging Intra-node fault tolerance Robustness solved in the details of implementation nesC offers only some types of checking

117. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 117 Summary For WSN, the need to build cheap, low-energy, (small) devices has various consequences for system design Radio frontends and controllers are much simpler than in conventional mobile networks Energy supply and scavenging are still (and for the foreseeable future) a premium resource Power management (switching off or throttling down devices) crucial Unique programming challenges of embedded systems Concurrency without support, protection De facto standard: TinyOS

118. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 118 Acknowledgements Notes on TinyOS rely heavily on Murat Demirbas� course CSE 646 Wireless Sensor Networks Suny Buffalo