Ad hoc and Sensor Networks Chapter 2 Single

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

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 SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 2

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

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

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 SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 5

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 MSP 430 · 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 MSP 430, slower SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 6

Custom single-purpose processor basic model … … external control inputs … external data inputs … controller datapath control inputs … datapath control outputs external control outputs controller datapath … registers state register datapath next-state and control logic functional units external data outputs … controller and datapath SS 05 … a view inside the controller and datapath Ad hoc & sensor networs - Ch 2: Single node architecture 7

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 SS 05 (a) black-box view !1 1: 1 !(!go_i) (c) state diagram 2: go_i x_i y_i !go_i 2 -J: GCD 3: (b) desired functionality 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; } x = x_i 4: d_o y = y_i !(x!=y) 5: x!=y 6: x

State diagram templates Assignment statement Loop statement while (cond) { loop-bodystatements } next statement a=b Branch statement !cond C: if (c 1) c 1 stmts else if c 2 stmts else other stmts next statement C: c 1 cond loop-bodystatements next statement c 2 stmts !c 1*!c 2 others J: next statement SS 05 c 1 stmts !c 1*c 2 next statement Ad hoc & sensor networs - Ch 2: Single node architecture 9

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 1 !(!go_i) 2: x_i !go_i y_i Datapath 2 -J: x_sel 3: x = x_i 4: y = y_i n-bit 2 x 1 7: 0: x · for each datapath component control input and output 0: y y_ld !(x!=y) 5: x!=y 6: x

Creating the controller’s FSM go_i !1 1: Controller 1 0000 1: 0001 !(!go_i) !1 2: !go_i 2 -J: 0010 2 -J: 3: x = x_i 4: y = y_i 0011 y_sel = 0 4: y_ld = 1 !(x!=y) 5: x!=y 6: 0101 0110 x

Splitting into a controller and datapath go_i Controller implementation model go_i Controller 0000 1 x_sel Combinational logic y_sel 0001 2: x_neq_y x_lt_y d_ld 0100 Q 3 Q 2 Q 1 Q 0 State register I 2 I 1 I 0 n-bit 2 x 1 0: x x_ld 0: y y_ld y_sel = 0 4: y_ld = 1 != x_neq_y=0 5: 0110 n-bit 2 x 1 y_sel x_sel = 0 3: x_ld = 1 0101 y_i (b) Datapath x_sel 0010 2 -J: 0011 x_i !(!go_i) !go_i x_ld y_ld I 3 !1 1: 6: x_neq_y=1 x_lt_y=1 7: y_sel = 1 y_ld = 1 x_lt_y=0 x_sel = 1 8: x_ld = 1 0111 5: x!=y x_neq_y < subtractor 6: x

Controller state table for the GCD example Inputs Q 3 Q 2 Q 1 Q 0 0 0 0 Outputs x_lt_ y * go_i I 3 I 2 I 1 I 0 x_sel y_sel x_ld y_ld d_ld 0 x_neq _y * * 0 0 0 1 X X 0 0 1 * * 0 0 0 1 0 X X 0 0 0 1 * * 1 0 0 1 1 X X 0 0 0 1 0 * * * 0 0 0 1 X X 0 0 0 1 1 * * * 0 1 0 0 0 X 1 0 0 0 1 0 0 * * * 0 1 X 0 0 1 0 1 0 * * 1 0 1 1 X X 0 0 1 0 1 1 * * 0 1 1 0 X X 0 0 1 1 0 * 1 0 0 0 X X 0 0 1 1 0 * 1 * 0 1 1 1 X X 0 0 1 1 1 * * * 1 0 0 1 X 1 0 1 0 0 0 * * * 1 0 0 1 1 X 1 0 0 1 * * * 1 0 X X 0 0 0 1 0 * * * 0 1 X X 0 0 0 1 1 * * * 1 1 0 0 X X 0 0 1 1 1 0 0 * * * 0 0 X X 0 0 0 1 1 0 1 * * * 0 0 X X 0 0 0 1 1 1 0 * * * 0 0 X X 0 0 0 1 1 * * * 0 0 X X 0 0 0 SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 13

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

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 SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 15

Transceiver characteristics · Capabilities · Radio performance · 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? ) SS 05 · · · · · Modulation? (ASK, FSK, …? ) Noise figure? NF = SNRI/SNRO Gain? (signal amplification) Receiver sensitivity? (minimum S to achieve a given Eb/N 0) Blocking performance (achieved BER in presence of frequencyoffset interferer) Out of band emissions Carrier sensing & RSSI characteristics Frequency stability (e. g. , towards temperature changes) Voltage range Ad hoc & sensor networs - Ch 2: Single node architecture 16

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!) SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 17

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

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 (100 s of meters possible, typical 10 s of meters at higher data rates) · Works reasonably well (but certainly not perfect) in mobile environments · Problem: expensive equipment, quite power hungry SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 19

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 SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 20

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 SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 21

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 SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 22

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? SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 23

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

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 · · · SS 05 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) Ad hoc & sensor networs - Ch 2: Single node architecture 25

Battery examples · Energy per volume (Joule per cubic centimeter): Primary batteries Chemistry Zinc-air Lithium Alkaline Energy (J/cm 3) 3780 2880 1200 Secondary batteries Chemistry Lithium Ni. MHd Ni. Cd Energy (J/cm 3) 1080 860 650 SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 26

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 m. W/cm 2 Temperature gradients – 80 W/cm 2 @ 1 V from 5 K 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) SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 27

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

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

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 SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 30

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

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) SS 05 Eoverhead Esaved Pactive Psleep t 1 tdown tevent tup Ad hoc & sensor networs - Ch 2: Single node architecture time 32

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 SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 33

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 n. Ah per byte · Writing: ¼ 83. 3 n. Ah per byte SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 34

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 Ptx. Elec · 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) (Ptx. Elec + amp Ptx) · Simplification: Modulation not considered SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 35

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 Prx. Elec · Plus: energy to decode n bits Edec. Bits ! Erx = Tstart Pstart + n / (R ¢ Rcode) Prx. Elec + Edec. Bits ( R ) SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 36

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

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

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 SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 39

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, … SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 40

WSN Platforms: Hardware & Software Murat Demirbas Computer Networks Group Lecture uses some slides from tutorials prepared Universität Paderborn by authors of these platforms

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 SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 42

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

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 SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 44

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

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 SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 46

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

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

Mica 2 and Mica 2 Dot · ATmega 128 CPU 1 inch · Self-programming · Chipcon CC 1000 · FSK · Manchester encoding · Tunable frequency · Low power consumption · 2 AA battery = 3 V SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 49

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

Mica Sensor Board · Light (Photo) · Temperature · Acceleration · 2 axis · Resolution: ± 2 mg · Magnetometer · Resolution: 134 G · Microphone · Tone Detector · Sounder · 4. 5 k. Hz SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 51

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

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

Mica Weather Board Revision 1. 5 · Total Solar Radiation · Photosynthetically Active Radiation · Resolution: 0. 3 A/W · Relative Humidity · Accuracy: ± 2% · Barometric Pressure · Accuracy: ± 1. 5 mbar · Temperature · Accuracy: ± 0. 01 o. C · Acceleration · 2 axis · Resolution: ± 2 mg SS 05 Revision 1. 0 · Designed by UCB w/ Crossbow and UCLA Ad hoc & sensor networs - Ch 2: Single node architecture 54

Mica. Dot Sensor Boards “Dot” sensorboards (1”diameter) Honey. Dot: Magnetometer Resolution: 134 m. Gauss Ultrasonic Transceiver Weather Station SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 55

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

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

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

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

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

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

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

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

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

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

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 ! ? ? ? SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 66

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 SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 67

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

Traditional concurrency: Processes · Traditional OS: processes/threads Handle sensor process Handle packet process · 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 SS 05 OS-mediated process switching Ad hoc & sensor networs - Ch 2: Single node architecture 69

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

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 Tiny. OS · 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! SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 71

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 Tiny. OS example discussion below SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 72

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 SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 73

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

Case study embedded OS: Tiny. OS & nes. C · Tiny. OS developed by UC Berkely as runtime environment for their “motes” · nes. C 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) SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 75

Tiny. OS components · Components · Frame – state information · Tasks – normal execution program · Command handlers · Event handlers · Handlers · Must run to completion · Form a component’s interface · Understand emits commands & events · Hierarchically arranged · Events pass upward from hardware to higher-level components · Commands are passed downward SS 05 init start stop fired Command handlers Frame Timer. Component Event handlers Tasks set. Rate fire Ad hoc & sensor networs - Ch 2: Single node architecture 76

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 multitasking is implemented · But can be interrupted by handlers ! No need for stack management, tasks are atomic with respect to each other SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 77

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 SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 78

Structuring commands/events into interfaces · Many commands/events can add up · nes. C solution: Structure corresponding commands/events into interface types · Example: Structure timer into three interfaces · Std. Ctrl · Timer · Clock init · Build configurations by wiring together corresponding interfaces Std. Ctrl stop fired start Timer. Component Clock set. Rate fire SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 79

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

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

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

Tiny. OS · 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 SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 83

Tiny. OS · 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 SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 84

Benefits of using Tiny. OS · Separation of concerns · Tiny. OS 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 · Tiny. OS 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 100 msec, 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. SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 85

Benefits of Tiny. OS · Modularity · Tiny. OS’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 Tiny. OS and numerous groups are actively contributing code to the public domain SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 86

Tiny. OS · 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 SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 87

Tiny. OS Concepts · Scheduler + Graph of Components · frame per component, shared stack, no heap internal thread · Very lean multithreading · Efficient Layering SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture msg_rec(type, data) msg_send_done) Internal State RX_packet_done (buffer) · Constrained Storage Model Messaging Component TX_packet_done (success) Commands Event Handlers Frame (storage) Tasks (concurrency) init Power(mode) TX_packet(buf) · · init · Component: Events send_msg (addr, type, data) Commands power(mode) · constrained two-level scheduling model: threads + events 88

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

TOS Execution Model · commands request action · ack/nack at every boundary · call command or post task message-event driven · events notify occurrence · tasks provide logical concurrency · preempted by events SS 05 packet event-driven packet-pump Radio Packet crc event-driven byte-pump byte HW interrupt at lowest level may signal events call commands post tasks active message Radio byte encode/decode event-driven bit-pump bit · · data processing application comp RFM Ad hoc & sensor networs - Ch 2: Single node architecture 90

Event-Driven Sensor Access Pattern command result_t Std. Control. start() { return call Timer. start(TIMER_REPEAT, 200); } SENSE event result_t Timer. fired() { return call sensor. get. Data(); } event result_t sensor. data. Ready(uint 16_t data) { display(data) return SUCCESS; } Timer Photo LED · 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 SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 91

Tiny. OS Commands and Events {. . . status = call Cmd. Name(args). . . } event Evt. Name(args) {. . . return status; } command Cmd. Name(args) {. . . return status; } {. . . status = signal Evt. Name(args). . . } SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 92

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

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

Typical Application Use of Tasks · event driven data acquisition · schedule task to do computational portion event result_t sensor. data. Ready(uint 16_t data) { putdata(data); post process. Data(); return SUCCESS; } task void process. Data() { int 16_t i, sum=0; for (i=0; i ‹ maxdata; i++) sum += (rdata[i] ›› 7); display(sum ›› shiftdata); } SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 95

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 SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 96

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 SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 97

The Complete Application Sense. To. Rfm generic comm Int. To. Rfm AMStandard packet Radio. CRCPacket UARTno. CRCPacket CRCfilter no. CRCPacket Timer photo byte Mica. High. Speed. Radio. M Sec. Ded. Encode Channel. Mon bit SPIByte. FIFO SS 05 phototemp Radio. Timing Random. LFSR SW UART Clock. C ADC HW Slave. Pin Ad hoc & sensor networs - Ch 2: Single node architecture 98

Programming Syntax · Tiny. OS 2. 0 is written in an extension of C, called nes. C · Applications are too · just additional components composed with OS components · Provides syntax for Tiny. OS 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 SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 99

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 Std. Control provides interface Std. Control; interface Timer: uses interface Clock SS 05 Timer provides Timer Component Clock Ad hoc & sensor networs - Ch 2: Single node architecture uses 100

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

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 SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 102

Example 1 · Blink application Blink Main configuration Blink { } implementation { components Main, Blink. M, Timer. C, Leds. C; Main. Std. Control -> Timer. C. Std. Control; Main. Std. Control -> Blink. M. Std. Control; } Blink. M. Timer -> Timer. C. Timer[unique("Timer")]; Blink. M. Leds -> Leds. C; Blink. nc Timer. C SS 05 Leds. C Ad hoc & sensor networs - Ch 2: Single node architecture 103

Example 1 · Blink. M module: module Blink. M { provides interface Std. Control; uses interface Timer; uses interface Leds; } command result_t Std. Control. start() { return call Timer. start(TIMER_REPEAT, 1000); } command result_t Std. Control. stop() { return call Timer. stop(); } implementation { command result_t Std. Control. init() { call Leds. init(); return SUCCESS; } } event result_t Clock. fire() { call Leds. red. Toggle(); return SUCCESS; } Blink. nc SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture Blink. nc 104

Example 2 configuration Sense. To. Rfm { } implementation { components Main, Sense. To. Int, Int. To. Rfm, Timer. C, Photo as Sensor; Main. Std. Control -> Sense. To. Int; Main. Std. Control -> Int. To. Rfm; Sense. To. Int. Timer -> Timer. C. Timer[unique”Timer”]; Sense. To. Int. ADC -> Sensor; Sense. To. Int. ADCControl -> Sensor; Sense. To. Int. Output -> Int. To. Rfm; Main Std. Control Sense. To. Int Timer } ADCControl Timer. C Photo SS 05 Int. Output Int. To. Rfm Ad hoc & sensor networs - Ch 2: Single node architecture 105

Nested Configuration includes Int. Msg; configuration Int. To. Rfm { provides { Std. Control interface Int. Output; Int. Output Int. To. Rfm. M interface Std. Control; } Sub. Control Send. Msg[AM_INTMSG]; } implementation Generic. Comm { components Int. To. Rfm. M, Generic. Comm as Comm; Int. Output = Int. To. Rfm. M; Std. Control = Int. To. Rfm. M; Int. To. Rfm. M. Send -> Comm. Send. Msg[AM_INTMSG]; Int. To. Rfm. M. Sub. Control -> Comm; } SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 106

Int. To. Rfm Module command result_t Std. Control. start() includes Int. Msg; { return call Sub. Control. start(); } module Int. To. Rfm. M { uses { interface Std. Control as Sub. Control; interface Send. Msg as Send; } provides { interface Int. Output; interface Std. Control; } } implementation { bool pending; struct TOS_Msg data; command result_t Std. Control. init() { pending = FALSE; return call Sub. Control. init(); } SS 05 command result_t Std. Control. stop() { return call Sub. Control. stop(); } command result_t Int. Output. output(uint 16_t value) {. . . if (call Send. send(TOS_BCAST_ADDR, sizeof(Int. Msg), &data) return SUCCESS; . . . } event result_t Send. send. Done(TOS_Msg. Ptr msg, result_t success) {. . . } } Ad hoc & sensor networs - Ch 2: Single node architecture 107

Atomicity Support in nes. C · 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) · nes. C 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 SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 108

Supporting HW Evolution · Distribution broken into · apps: · tos: top-level applications · lib: · system: · platform: shared application components hardware independent system components hardware dependent system components · includes HPLs and hardware. h · interfaces · tools: · contrib · beta development support tools · 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 I 2 C protocol to a sensor board with digital sensor or ADC · HW/SW boundary can move up and down with minimal changes SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 109

Sending a Message bool pending; struct TOS_Msg data; command result_t Int. Output. output(uint 16_t value) { Int. Msg *message = (Int. Msg *)data; if (!pending) { pending = TRUE; message->val = value; message->src = TOS_LOCAL_ADDRESS; if (call Send. send(TOS_BCAST_ADDR, sizeof(Int. Msg), &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 SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 110

Send done Event event result_t Int. Output. send. Done(TOS_Msg. Ptr msg, result_t success) { if (pending && msg == &data) { pending = FALSE; signal Int. Output. output. Complete(success); } return SUCCESS; } } · 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 SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 111

Receive Event event TOS_Msg. Ptr Receive. Int. Msg. receive(TOS_Msg. Ptr m) { Int. Msg *message = (Int. Msg *)m->data; call Int. Output. output(message->val); return m; } · 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 SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 112

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 SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 113

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 SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 114

Tiny. OS tools · TOSSIM: a simulator for tinyos programs · Listen. Raw, Serial. Forwarder: 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, Tiny. DB SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 115

Tiny. OS 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 · nes. C offers only some types of checking SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 116

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: Tiny. OS SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 117

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