1. Computer Networks Group Universität Paderborn Ad hoc and Sensor Networks Chapter 2: Single node architecture Holger Karl

2. SS 05Ad hoc & sensor networs - Ch 2: Single node architecture2 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 05Ad hoc & sensor networs - Ch 2: Single node architecture3 Outline  Sensor node architecture  Energy supply and consumption  Runtime environments for sensor nodes  Case study: TinyOS

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

5. SS 05Ad hoc & sensor networs - Ch 2: Single node architecture5 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 05Ad hoc & sensor networs - Ch 2: Single node architecture6 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 05Ad hoc & sensor networs - Ch 2: Single node architecture7 Custom single-purpose processor basic model controller and datapath controllerdatapath … … external control inputs external control outputs … external data inputs … external data outputs datapath control inputs datapath control outputs … … a view inside the controller and datapath controllerdatapath … … state register next-state and control logic registers functional units

8. SS 05Ad hoc & sensor networs - Ch 2: Single node architecture8 Example: greatest common divisor GCD (a) black-box view x_i y_i d_o go_i 0: int x, y; 1: while (1) { 2: while (!go_i); 3: x = x_i; 4: y = y_i; 5: while (x != y) { 6: if (x < y) 7: y = y - x; else 8: x = x - y; } 9: d_o = x; } (b) desired functionality y = y -x 7: x = x - y 8: 6-J: x!=y 5: !(x!=y) x<y!(x<y) 6: 5-J: 1: 1 !1 x = x_i 3: y = y_i 4: 2: 2-J: !go_i !(!go_i) d_o = x 1-J: 9: (c) state diagram  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 05Ad hoc & sensor networs - Ch 2: Single node architecture9 State diagram templates Assignment statement a = b next statement a = b next statement Loop statement while (cond) { loop-body- statements } next statement loop-body- statements cond next statement !cond J: C: Branch statement if (c1) c1 stmts else if c2 c2 stmts else other stmts next statement c1 c2 stmts !c1*c2 !c1*!c2 next statement othersc1 stmts J: C:

10. SS 05Ad hoc & sensor networs - Ch 2: Single node architecture10 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 y = y -x 7: x = x - y 8: 6-J: x!=y 5: !(x!=y) x<y!(x<y) 6: 5-J: 1: 1 !1 x = x_i 3: y = y_i 4: 2: 2-J: !go_i !(!go_i) d_o = x 1-J: 9: subtractor 7: y-x8: x-y5: x!=y6: x<y x_iy_i d_o 0: x0: y 9: d n-bit 2x1 x_sel y_sel x_ld y_ld x_neq_y x_lt_y d_ld < 5: x!=y != Datapath

11. SS 05Ad hoc & sensor networs - Ch 2: Single node architecture11 Creating the controller’s FSM  Same structure as FSMD  Replace complex actions/conditions with datapath configurations y = y -x 7: x = x - y 8: 6-J: x!=y 5: !(x!=y) x<y!(x<y) 6: 5-J: 1: 1 !1 x = x_i 3: y = y_i 4: 2: 2-J: !go_i !(!go_i) d_o = x 1-J: 9: y_sel = 1 y_ld = 1 7: x_sel = 1 x_ld = 1 8: 6-J: x_neq_y 5: !x_neq_y x_lt_y!x_lt_y 6: 5-J: d_ld = 1 1-J: 9: x_sel = 0 x_ld = 1 3: y_sel = 0 y_ld = 1 4: 1: 1 !1 2: 2-J: !go_i !(!go_i) go_i 0000 0001 0010 0011 0100 0101 0110 01111000 1001 1010 1011 1100 Controller subtractor 7: y-x8: x-y5: x!=y6: x<y x_iy_i d_o 0: x0: y 9: d n-bit 2x1 x_sel y_sel x_ld y_ld x_neq_y x_lt_y d_ld < 5: x!=y != Datapath

12. SS 05Ad hoc & sensor networs - Ch 2: Single node architecture12 Splitting into a controller and datapath y_sel = 1 y_ld = 1 7: x_sel = 1 x_ld = 1 8: 6-J: x_neq_y=1 5: x_neq_y=0 x_lt_y=1x_lt_y=0 6: 5-J: d_ld = 1 1-J: 9: x_sel = 0 x_ld = 1 3: y_sel = 0 y_ld = 1 4: 1: 1 !1 2: 2-J: !go_i !(!go_i) go_i 0000 0001 0010 0011 0100 0101 0110 01111000 1001 1010 1011 1100 Controller Controller implementation model y_sel x_sel Combinational logic Q3Q0 State register go_i x_neq_y x_lt_y x_ld y_ld d_ld Q2Q1 I3I0I2I1 subtractor 7: y-x8: x-y5: x!=y6: x<y x_iy_i d_o 0: x0: y 9: d n-bit 2x1 x_sel y_sel x_ld y_ld x_neq_y x_lt_y d_ld < 5: x!=y != (b) Datapath

13. SS 05Ad hoc & sensor networs - Ch 2: Single node architecture13 Controller state table for the GCD example InputsOutputs Q3Q2Q1Q0x_neq _y x_lt_ y go_iI3I2I1I0x_sely_selx_ldy_ldd_ld 0000***0001XX000 0001**00010XX000 0001**10011XX000 0010***0001XX000 0011***01000X100 0100***0101X0010 01010**1011XX000 01011**0110XX000 0110*0*1000XX000 0110*1*0111XX000 0111***1001X1010 1000***10011X100 1001***1010XX000 1010***0101XX000 1011***1100XX001 1100***0000XX000 1101***0000XX000 1110***0000XX000 1111***0000XX000

14. SS 05Ad hoc & sensor networs - Ch 2: Single node architecture14 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 … … a view inside the controller and datapath controllerdatapath … … state register next-state and control logic registers functional units

15. SS 05Ad hoc & sensor networs - Ch 2: Single node architecture15 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 05Ad hoc & sensor networs - Ch 2: Single node architecture16 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 = SNR I /SNR O  Gain? (signal amplification)  Receiver sensitivity? (minimum S to achieve a given E b /N 0 )  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 05Ad hoc & sensor networs - Ch 2: Single node architecture17 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 05Ad hoc & sensor networs - Ch 2: Single node architecture18 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 05Ad hoc & sensor networs - Ch 2: Single node architecture19 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 05Ad hoc & sensor networs - Ch 2: Single node architecture20 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 05Ad hoc & sensor networs - Ch 2: Single node architecture21 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 05Ad hoc & sensor networs - Ch 2: Single node architecture22 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 05Ad hoc & sensor networs - Ch 2: Single node architecture23 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 05Ad hoc & sensor networs - Ch 2: Single node architecture24 Outline  Sensor node architecture  Energy supply and consumption  Runtime environments for sensor nodes  Case study: TinyOS

25. SS 05Ad hoc & sensor networs - Ch 2: Single node architecture25 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 05Ad hoc & sensor networs - Ch 2: Single node architecture26 Battery examples  Energy per volume (Joule per cubic centimeter): Primary batteries ChemistryZinc-airLithiumAlkaline Energy (J/cm 3 )378028801200 Secondary batteries ChemistryLithiumNiMHdNiCd Energy (J/cm 3 )1080860650

27. SS 05Ad hoc & sensor networs - Ch 2: Single node architecture27 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/cm 2 and 15 mW/cm 2  Temperature gradients – 80  W/cm 2 @ 1 V from 5K difference  Vibrations – between 0.1 and 10000  W/cm 3  Pressure variation (piezo-electric) – 330  W/cm 2 from the heel of a shoe  Air/liquid flow (MEMS gas turbines)

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

29. SS 05Ad hoc & sensor networs - Ch 2: Single node architecture29 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: 10 9 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 05Ad hoc & sensor networs - Ch 2: Single node architecture30 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 05Ad hoc & sensor networs - Ch 2: Single node architecture31 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 05Ad hoc & sensor networs - Ch 2: Single node architecture32 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 E saved > E overhead  Example: Event-triggered wake up from sleep mode  Scheduling problem with uncertainty (exercise) P active P sleep timet event t1t1 E saved E overhead  down  up

33. SS 05Ad hoc & sensor networs - Ch 2: Single node architecture33 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 V 2  Lower clock allows lower supply voltage  Easy to switch to higher clock  But: execution takes longer

34. SS 05Ad hoc & sensor networs - Ch 2: Single node architecture34 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 05Ad hoc & sensor networs - Ch 2: Single node architecture35 Transmitter power/energy consumption for n bits  Amplifier power: P amp =  amp +  amp P tx  P tx radiated power  amp,  amp constants depending on model  Highest efficiency (  = P tx / P amp ) at maximum output power  In addition: transmitter electronics needs power P txElec  Time to transmit n bits: n / (R ¢ R code )  R nomial data rate, R code coding rate  To leave sleep mode  Time T start, average power P start ! E tx = T start P start + n / (R ¢ R code ) (P txElec +  amp +  amp P tx )  Simplification: Modulation not considered

36. SS 05Ad hoc & sensor networs - Ch 2: Single node architecture36 Receiver power/energy consumption for n bits  Receiver also has startup costs  Time T start, average power P start  Time for n bits is the same n / (R ¢ R code )  Receiver electronics needs P rxElec  Plus: energy to decode n bits E decBits ! E rx = T start P start + n / (R ¢ R code ) P rxElec + E decBits ( R )

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

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

39. SS 05Ad hoc & sensor networs - Ch 2: Single node architecture39 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 05Ad hoc & sensor networs - Ch 2: Single node architecture40 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. Computer Networks Group Universität Paderborn WSN Platforms: Hardware & Software Murat Demirbas Lecture uses some slides from tutorials prepared by authors of these platforms

42. SS 05Ad hoc & sensor networs - Ch 2: Single node architecture42 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 05Ad hoc & sensor networs - Ch 2: Single node architecture43 Outline  Hardware  RFID, Spec  Mica2, XSM, Telos  Stargate  Software  TinyOS  Simulation  TOSSIM  Prowler

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

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

46. SS 05Ad hoc & sensor networs - Ch 2: Single node architecture46 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 05Ad hoc & sensor networs - Ch 2: Single node architecture47 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 05Ad hoc & sensor networs - Ch 2: Single node architecture48 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 05Ad hoc & sensor networs - Ch 2: Single node architecture49 Mica2 and Mica2Dot  ATmega128 CPU  Self-programming Self-programming  Chipcon CC1000  FSK  Manchester encoding  Tunable frequency  Low power consumption  2 AA battery = 3V 1 inch

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

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

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

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

54. SS 05Ad hoc & sensor networs - Ch 2: Single node architecture54 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.01 o C  Acceleration  2 axis  Resolution: ±2mg  Designed by UCB w/ Crossbow and UCLA Revision 1.5 Revision 1.0

55. SS 05Ad hoc & sensor networs - Ch 2: Single node architecture55 MicaDot Sensor Boards “Dot” sensorboards (1”diameter) HoneyDot: Magnetometer Resolution: 134 mGauss Ultrasonic Transceiver Weather Station

56. SS 05Ad hoc & sensor networs - Ch 2: Single node architecture56 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 05Ad hoc & sensor networs - Ch 2: Single node architecture57 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 05Ad hoc & sensor networs - Ch 2: Single node architecture58 Telos Meeting the Low Power Goal All values measured at room temperature (approximately 25 o C) at 3V supply voltage Source: “Telos: Enabling Low Power Wireless Sensor Network Research” To appear, IPSN/SPOTS, April 2005

59. SS 05Ad hoc & sensor networs - Ch 2: Single node architecture59 Telos Performance  200ksamples/sec sampling rate, DMA transfers, DAC  Increased performance & functionality over existing designs  New “link quality indicator” predicts average packet loss Distance (ft) Packet Success Average LQI RSSI Flat field range test @ 4” off ground (125m @ 1m elevation)

60. SS 05Ad hoc & sensor networs - Ch 2: Single node architecture60 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 05Ad hoc & sensor networs - Ch 2: Single node architecture61 Stargate

62. SS 05Ad hoc & sensor networs - Ch 2: Single node architecture62 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 05Ad hoc & sensor networs - Ch 2: Single node architecture63 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 05Ad hoc & sensor networs - Ch 2: Single node architecture64 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.

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

66. SS 05Ad hoc & sensor networs - Ch 2: Single node architecture66 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 05Ad hoc & sensor networs - Ch 2: Single node architecture67 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 05Ad hoc & sensor networs - Ch 2: Single node architecture68 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. Poll sensor Process sensor data Poll transceiver Process received packet

69. SS 05Ad hoc & sensor networs - Ch 2: Single node architecture69 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 Handle sensor process Handle packet process OS-mediated process switching

70. SS 05Ad hoc & sensor networs - Ch 2: Single node architecture70 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 Idle/Regular processing Radio event Radioeventhandler Sensor event Sensorevent handler

71. SS 05Ad hoc & sensor networs - Ch 2: Single node architecture71 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 05Ad hoc & sensor networs - Ch 2: Single node architecture72 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 05Ad hoc & sensor networs - Ch 2: Single node architecture73 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 05Ad hoc & sensor networs - Ch 2: Single node architecture74 Outline  Sensor node architecture  Energy supply and consumption  Runtime environments for sensor nodes  Case study: TinyOS

75. SS 05Ad hoc & sensor networs - Ch 2: Single node architecture75 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 05Ad hoc & sensor networs - Ch 2: Single node architecture76 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 TimerComponent setRate fire initstart stopfired Event handlers Command handlers Frame Tasks

77. SS 05Ad hoc & sensor networs - Ch 2: Single node architecture77 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 05Ad hoc & sensor networs - Ch 2: Single node architecture78 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 05Ad hoc & sensor networs - Ch 2: Single node architecture79 TimerComponent start stopfired Timer init StdCtrl setRate fire Clock 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  Build configurations by wiring together corresponding interfaces

80. SS 05Ad hoc & sensor networs - Ch 2: Single node architecture80 CompleteTimer TimerComponent Timer StdCtrl Clock HWClock Clock Timer StdCtrl 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 05Ad hoc & sensor networs - Ch 2: Single node architecture81 Defining modules and components in nesC

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

83. SS 05Ad hoc & sensor networs - Ch 2: Single node architecture83 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 05Ad hoc & sensor networs - Ch 2: Single node architecture84 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 05Ad hoc & sensor networs - Ch 2: Single node architecture85 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 05Ad hoc & sensor networs - Ch 2: Single node architecture86 Benefits of TinyOS  Modularity  TinyOS’s component model facilitates reuse and reconfigurability since softwareis 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 05Ad hoc & sensor networs - Ch 2: Single node architecture87 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 05Ad hoc & sensor networs - Ch 2: Single node architecture88 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 Messaging Component init Power(mode) TX_packet(buf) TX_packet_done (success) RX_packet_done (buffer) Internal State init power(mode) send_msg (addr, type, data) msg_rec(type, data) msg_send_done) internal thread Commands Events

89. SS 05Ad hoc & sensor networs - Ch 2: Single node architecture89 Application = Graph of Components RFM Radio byte Radio Packet UART Serial Packet ADC TempPhoto Active Messages clock bit byte packet Route map RouterSensor Appln application HW SW Example: ad hoc, multi-hop routing of photo sensor readings 3450 B code 226 B data Graph of cooperating state machines on shared stack

90. SS 05Ad hoc & sensor networs - Ch 2: Single node architecture90 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 RFM Radio byte Radio Packet bit byte packet event-driven bit-pump event-driven byte-pump event-driven packet-pump message-event driven active message application comp encode/decode crc data processing

91. SS 05Ad hoc & sensor networs - Ch 2: Single node architecture91 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 command result_t StdControl.start() { return call Timer.start(TIMER_REPEAT, 200); } event result_t Timer.fired() { return call sensor.getData(); } event result_t sensor.dataReady(uint16_t data) { display(data) return SUCCESS; } SENSE Timer Photo LED

92. SS 05Ad hoc & sensor networs - Ch 2: Single node architecture92 TinyOS Commands and Events {... status = call CmdName(args)... } command CmdName(args) {... return status; } {... status = signal EvtName(args)... } event EvtName(args) {... return status; }

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

94. SS 05Ad hoc & sensor networs - Ch 2: Single node architecture94 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 {... post TskName();... } task void TskName {... }

95. SS 05Ad hoc & sensor networs - Ch 2: Single node architecture95 Typical Application Use of Tasks  event driven data acquisition  schedule task to do computational portion event result_t sensor.dataReady(uint16_t data) { putdata(data); post processData(); return SUCCESS; } task void processData() { int16_t i, sum=0; for (i=0; i ‹ maxdata; i++) sum += (rdata[i] ›› 7); display(sum ›› shiftdata); }

96. SS 05Ad hoc & sensor networs - Ch 2: Single node architecture96 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 05Ad hoc & sensor networs - Ch 2: Single node architecture97 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 05Ad hoc & sensor networs - Ch 2: Single node architecture98 RadioTiming SecDedEncode The Complete Application RadioCRCPacket UART UARTnoCRCPacket ADC phototemp AMStandard ClockC bit byte packet SenseToRfm HW SW IntToRfm MicaHighSpeedRadioM RandomLFSRSPIByteFIFO SlavePin noCRCPacket Timer photo ChannelMon generic comm CRCfilter

99. SS 05Ad hoc & sensor networs - Ch 2: Single node architecture99 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 05Ad hoc & sensor networs - Ch 2: Single node architecture100 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 Timer Component StdControl Timer Clock provides uses provides interface StdControl; interface Timer: uses interface Clock

101. SS 05Ad hoc & sensor networs - Ch 2: Single node architecture101 Component Interface  logically related set of commands and events StdControl.nc interface StdControl { command result_t init(); command result_t start(); command result_t stop(); } Clock.nc interface Clock { command result_t setRate(char interval, char scale); event result_t fire(); }

102. SS 05Ad hoc & sensor networs - Ch 2: Single node architecture102 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 05Ad hoc & sensor networs - Ch 2: Single node architecture103 Example1  Blink application configuration Blink { } implementation { components Main, BlinkM, TimerC, LedsC; Main.StdControl -> TimerC.StdControl; Main.StdControl -> BlinkM.StdControl; BlinkM.Timer -> TimerC.Timer[unique("Timer")]; BlinkM.Leds -> LedsC; } TimerCLedsC Main Blink BlinkM Blink.nc

104. SS 05Ad hoc & sensor networs - Ch 2: Single node architecture104 Example1  BlinkM module: module BlinkM { provides interface StdControl; uses interface Timer; uses interface Leds; } implementation { command result_t StdControl.init() { call Leds.init(); return SUCCESS; } Blink.nc command result_t StdControl.start() { return call Timer.start(TIMER_REPEAT, 1000); } command result_t StdControl.stop() { return call Timer.stop(); } event result_t Clock.fire() { call Leds.redToggle(); return SUCCESS; } } Blink.nc

105. SS 05Ad hoc & sensor networs - Ch 2: Single node architecture105 Example2 configuration SenseToRfm { } implementation { components Main, SenseToInt, IntToRfm, TimerC, Photo as Sensor; Main.StdControl -> SenseToInt; Main.StdControl -> IntToRfm; SenseToInt.Timer -> TimerC.Timer[unique”Timer”]; SenseToInt.ADC -> Sensor; SenseToInt.ADCControl -> Sensor; SenseToInt.IntOutput -> IntToRfm; } SenseToInt TimerCPhoto Main StdControl ADCControl IntOutput Timer ADC IntToRfm

106. SS 05Ad hoc & sensor networs - Ch 2: Single node architecture106 Nested Configuration includes IntMsg; configuration IntToRfm { provides { interface IntOutput; interface StdControl; } implementation { components IntToRfmM, GenericComm as Comm; IntOutput = IntToRfmM; StdControl = IntToRfmM; IntToRfmM.Send -> Comm.SendMsg[AM_INTMSG]; IntToRfmM.SubControl -> Comm; } IntToRfmM GenericComm StdControl IntOutput SubControl SendMsg[AM_INTMSG];

107. SS 05Ad hoc & sensor networs - Ch 2: Single node architecture107 IntToRfm Module includes IntMsg; module IntToRfmM { uses { interface StdControl as SubControl; interface SendMsg as Send; } provides { interface IntOutput; interface StdControl; } implementation { bool pending; struct TOS_Msg data; command result_t StdControl.init() { pending = FALSE; return call SubControl.init(); } command result_t StdControl.start() { return call SubControl.start(); } command result_t StdControl.stop() { return call SubControl.stop(); } command result_t IntOutput.output(uint16_t value) {... if (call Send.send(TOS_BCAST_ADDR,sizeof(IntMsg), &data) return SUCCESS;... } event result_t Send.sendDone(TOS_MsgPtr msg, result_t success) {... }

108. SS 05Ad hoc & sensor networs - Ch 2: Single node architecture108 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 05Ad hoc & sensor networs - Ch 2: Single node architecture109 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 05Ad hoc & sensor networs - Ch 2: Single node architecture110 Sending a Message bool pending; struct TOS_Msg data; command result_t IntOutput.output(uint16_t value) { IntMsg *message = (IntMsg *)data.data; if (!pending) { pending = TRUE; message->val = value; message->src = TOS_ LOCAL _ADDRESS; if (call Send.send(TOS_BCAST_ADDR, sizeof(IntMsg), &data)) return SUCCESS; pending = FALSE; } return FAIL; } destination length Refuses to accept command if buffer is still full or network refuses to accept send command User component provide structured msg storage

111. SS 05Ad hoc & sensor networs - Ch 2: Single node architecture111 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 event result_t IntOutput.sendDone(TOS_MsgPtr msg, result_t success) { if (pending && msg == &data) { pending = FALSE; signal IntOutput.outputComplete(success); } return SUCCESS; }

112. SS 05Ad hoc & sensor networs - Ch 2: Single node architecture112 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 event TOS_MsgPtr ReceiveIntMsg.receive(TOS_MsgPtr m) { IntMsg *message = (IntMsg *)m->data; call IntOutput.output(message->val); return m; }

113. SS 05Ad hoc & sensor networs - Ch 2: Single node architecture113 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 05Ad hoc & sensor networs - Ch 2: Single node architecture114 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 05Ad hoc & sensor networs - Ch 2: Single node architecture115 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 05Ad hoc & sensor networs - Ch 2: Single node architecture116 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 05Ad hoc & sensor networs - Ch 2: Single node architecture117 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 05Ad hoc & sensor networs - Ch 2: Single node architecture118 Acknowledgements  Notes on TinyOS rely heavily on Murat Demirbas’ course CSE 646 Wireless Sensor Networks Suny Buffalo