1. Network Kernel Architectures and Implementation (01204423) Single-Node Architectures Chaiporn Jaikaeo chaiporn.j@ku.ac.th Department of Computer Engineering Kasetsart University Materials taken from lecture slides by Karl and Willig Contiki materials taken from slides by Adam Dunkels

2. Outline Main components of a wireless sensor node Main components of a wireless sensor node  Processor, radio, sensors, batteries Energy supply and consumption Energy supply and consumption Operating systems and execution environments Operating systems and execution environments  IWING's MoteLib  TinyOS  Contiki Sample implementations Sample implementations

3. Main Components Communication Device Controller Sensors/ Actuators Power Supply Memory

4. Controller Main options: Main options:  Microcontroller – general purpose processor, optimized for embedded applications, low power consumption  DSP – optimized for signal processing tasks, not suitable here  FPGA – may be good for testing  ASIC – only when peak performance is needed, no flexibility

5. Microcontroller Examples Texas Instruments MSP430 Texas Instruments MSP430  16-bit RISC core, 4 MHz  Up to 120 KB flash  2-10 KB RAM  12 ADCs, RT clock Atmel ATMega Atmel ATMega  8-bit controller, 8 MHz  Up to 128KB Flash  4 KB RAM

6. Communication Device Medium options Medium options  Electromagnetic, RF  Electromagnetic, optical  Ultrasound Radio Transceiver radio wave bit stream

7. Transceiver Characteristics Service to upper layer: packet, byte, bit Service to upper layer: packet, byte, bit Power consumption Power consumption Supported frequency, multiple channels Supported frequency, multiple channels Data rate Data rate Modulation Modulation Power control Power control Communication range Communication range etc. etc.

8. Transceiver States Transceivers can be put into different operational states, typically: Transceivers can be put into different operational states, typically:  Transmit  Receive  Idle – ready to receive, but not doing so  Sleep – significant parts of the transceiver are switched off RxTxIdle Sleep

9. Wakeup Receivers When to switch on a receiver is not clear 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 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

10. Optical Communication Optical communication can consume less energy Optical communication can consume less energy Example: passive readout via corner cube reflector Example: passive readout via corner cube reflector  Laser is reflected back directly to source if mirrors are at right angles  Mirrors can be “tilted” to stop reflecting  Allows data to be sent back to laser source 200 µm

11. Ultra Wideband Communication Use a large bandwidth, do not modulate, simply emit a “burst” of power Use a large bandwidth, do not modulate, simply emit a “burst” of power Advantages Advantages  Pretty resilient to multi-path propagation  Very good ranging capabilities  Good wall penetration http://www.soumu.go.jp/joho_tsusin/eng/Releases/NewsLet ter/Vol15/Vol15_01/2-UWB-1.jpg http://www.ixbt.com/comm/images/uwb/uwb1.png

12. Sensors Main categories Main categories  Passive, omnidirectional  Examples: light, thermometer, microphones, hygrometer, …  Passive, narrow-beam  Example: Camera  Active sensors  Example: Radar Important parameter: Area of coverage Important parameter: Area of coverage  Which region is adequately covered by a given sensor?

13. Outline Main components of a wireless sensor node Main components of a wireless sensor node  Processor, radio, sensors, batteries Energy supply and consumption Energy supply and consumption Operating systems and execution environments Operating systems and execution environments  IWING's MoteLib  TinyOS  Contiki Example implementations Example implementations

14. Energy Supply Goal: provide as much energy as possible at smallest cost/volume/weight/recharge time/longevity 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 Options  Primary batteries – not rechargeable  Secondary batteries – rechargeable, only makes sense in combination with some form of energy harvesting

15. Energy Supply - Requirements Low self-discharge Low self-discharge Long shelf life Long shelf life Capacity under load Capacity under load Efficient recharging at low current Efficient recharging at low current Good relaxation properties (seeming self- recharging) Good relaxation properties (seeming self- recharging) Voltage stability (to avoid DC-DC conversion) Voltage stability (to avoid DC-DC conversion)

16. Battery Examples Energy per volume (Joule/cc): Energy per volume (Joule/cc): Primary batteries ChemistryZinc-airLithiumAlkaline Energy (J/cm 3 ) 378028801200 Secondary batteries ChemistryLithiumNiMHNiCd Energy (J/cm 3 ) 1080860650 http://en.wikipedia.org/wiki/Energy_density

17. Energy Harvesting How to recharge a battery? 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 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)

18. Portable Solar Chargers Foldable Solar Chargers Foldable Solar Chargers  http://www.energyenv.co.uk/FoldableChargers.asp http://www.energyenv.co.uk/FoldableChargers.asp http://www.energyenv.co.uk/FoldableChargers.asp Solargorilla Solargorilla  http://powertraveller.com/iwantsome/primatepower/ solargorilla/ http://powertraveller.com/iwantsome/primatepower/ solargorilla/ http://powertraveller.com/iwantsome/primatepower/ solargorilla/

19. Energy Supply - Comparison

20. Energy Consumption Rough estimation Rough 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 = 24x60x60 = 86400 s  1 Ws / 86400s  11.5  W as max sustained power consumption!

21. Multiple Power Consumption Modes Do not run sensor node at full operation all the time Do not run sensor node at full operation all the time  If nothing to do, switch to power safe mode Typical modes Typical modes  Controller: Active, idle, sleep  Radio mode: Turn on/off transmitter/receiver, both  Strongly depends on hardware Questions: Questions:  When to throttle down?  How to wake up again?

22. Energy Consumption Figures TI MSP 430 (@ 1 MHz, 3V): TI MSP 430 (@ 1 MHz, 3V):  Fully operation 1.2 mW  One fully operational mode + four sleep modes  Deepest sleep mode 0.3  W – only woken up by external interrupts (not even timer is running any more) Atmel ATMega Atmel ATMega  Operational mode: 15 mW active, 6 mW idle  Six modes of operations  Sleep mode: 75  W

23. Switching Between Modes Simplest idea: Greedily switch to lower mode whenever possible Simplest idea: Greedily switch to lower mode whenever possible Problem: Time and power consumption required to reach higher modes not negligible Problem: Time and power consumption required to reach higher modes not negligible P active P sleep timet event t1t1 E saved  down  up E overhead

24. Should We Switch? Switching modes is beneficial if Switching modes is beneficial if which is equivalent to E overhead < E saved

25. Dynamic Voltage Scaling (DVS) Rationale: 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 But: execution takes longer

26. Memory Power Consumption Crucial part: FLASH memory Crucial part: FLASH memory  Power for RAM almost negligible FLASH writing/erasing is expensive FLASH writing/erasing is expensive  Example: FLASH on Mica motes  Reading:  1.1 nAh per byte  Writing:  83.3 nAh per byte Write energy varies greatly Write energy varies greatly  Difference ratio up to 900:1 between different types

27. Computation vs. Communication Energy Cost Sending one bit vs. running one instruction Sending one bit vs. running one instruction  Energy ratio up to 2900:1  I.e., send & receive one KB = running three million instruction So, try to compute instead of communicate whenever possible So, try to compute instead of communicate whenever possible Key technique – in-network processing Key technique – in-network processing  Exploit compression schemes, intelligent coding schemes, aggregate data, …

28. Outline Main components of a wireless sensor node Main components of a wireless sensor node  Processor, radio, sensors, batteries Energy supply and consumption Energy supply and consumption Operating systems and execution environments Operating systems and execution environments  IWING's MoteLib  TinyOS  Contiki Example implementations Example implementations

29. Mica Motes By Crossbow, USA By Crossbow, USA MCU: MCU:  Atmel ATMega128L Comm: RFM TR1000 Comm: RFM TR1000

30. EYES Nodes By Infineon, EU By Infineon, EU MCU: TI MSP430 MCU: TI MSP430 Comm: Infineon radio modem TDA5250 Comm: Infineon radio modem TDA5250

31. Btnote By ETH Zurich By ETH Zurich MCU: MCU:  Atmel ATMega128L Comm: Comm:  Bluetooth  Chipcon CC1000

32. ScatterWeb By Computer Systems & Telematics group, Freie Universitat Berlin By Computer Systems & Telematics group, Freie Universitat Berlin MCU: MCU:  TI MSP 430 Comm: Comm:  Bluetooth, I 2 C, CAN

33. Tmote Sky By Sentilla (formerly Moteiv), USA By Sentilla (formerly Moteiv), USA MCU: MCU:  TI MSP430 Comm: Comm:  Chipcon CC2420 (IEEE 802.15.4)

34. IRIS Motes By Crossbow, USA By Crossbow, USA MCU: ATMega128L MCU: ATMega128L Comm: Atmel's RF230 (IEEE 802.15.4) Comm: Atmel's RF230 (IEEE 802.15.4) 3x radio range compared to Tmote 3x radio range compared to Tmote "Postage-stamp" form factor costs as low as $29 per unit (when purchased in large volumes) "Postage-stamp" form factor costs as low as $29 per unit (when purchased in large volumes)

35. IMote2 By Intel Research By Intel Research MCU: PXA271 XScale MCU: PXA271 XScale Comm: Chipcon CC2420 (IEEE802.15.4) Comm: Chipcon CC2420 (IEEE802.15.4)

36. Other WSN-Capable Modules Many low-cost, wireless SoC modules already available Many low-cost, wireless SoC modules already available HopeRF 433 MHz module based on Silicon Labs's SoC (~6 USD/module) Synapse Wireless 2.4 GHz module based on Atmel's SoC SNAP OS / embedded Python (~25 USD/module)

37. IWING-MRF Motes Radio transceiver 8-bit AVR Microcontroller USB Connector (for reprogramming and power) Analog/Digital sensor connectors External battery connector UART Connector Morakot Saravanee, Chaiporn Jaikaeo, 2010. Intelligent Wireless Network Group (IWING), KU

38. IWING-MRF Motes Built from off-the-shelf components Built from off-the-shelf components Built-in USB boot loader Built-in USB boot loader  Reprogrammed via USB Easy to modify and extend hardware Easy to modify and extend hardware

39. IWING-MRF Mote Processor Processor  8-bit AVR microcontroller ATMega88/168/328, 12 MHz  16KB flash, 2KB RAM RF transceiver RF transceiver  Microchip's MRF24J40A/B/C, 2.4GHz IEEE 802.15.4  SPI interface External connectors External connectors  6 ADC connectors (can also be used as TWI)  1 UART Power options Power options  3 – 3.6 VDC  USB or 2 AA batteries

40. IWING-JN Motes Built on JN5168 wireless microcontroller Built on JN5168 wireless microcontroller 32-bit RISC architecture 32-bit RISC architecture  Operating at 32 MHz  256 KB flash, 32 KB RAM IEEE 802.15.4 RF transceiver IEEE 802.15.4 RF transceiver 4 ADC channels (10-bit) 4 ADC channels (10-bit) ~20 general-purpose digital I/O ~20 general-purpose digital I/O 2 UART interfaces 2 UART interfaces Hardware access via C-language API Hardware access via C-language API

41. Outline Main components of a wireless sensor node Main components of a wireless sensor node  Processor, radio, sensors, batteries Energy supply and consumption Energy supply and consumption Operating systems and execution environments Operating systems and execution environments  IWING's MoteLib  TinyOS  Contiki Example implementations Example implementations

42. Operating System Challenges Usual operating system goals Usual operating system goals  Make access to device resources abstract (virtualization)  Protect resources from concurrent access Usual means Usual means  Protected operation modes of the CPU  Process with separate address spaces These are not available in microcontrollers These are not available in microcontrollers  No separate protection modes, no MMU  Would make devices more expensive, more power- hungry

43. Possible OS Options Try to implement “as close to an operating system” on WSN nodes Try to implement “as close to an operating system” on WSN nodes  Support for processes!  Possible, but relatively high overhead Stay away with operating system Stay away with operating system  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

44. Possible OS Options Currently popular approach Currently popular approach  No OS, just a simple run-time environment  Enough to abstract away hardware access details  Biggest impact: Unusual programming model

45. Concurrency Support Simplest option: No concurrency, sequential processing of tasks Simplest option: No concurrency, sequential processing of tasks  Risk of missing data  Should support interrupts/asynchronous operations Poll sensor Process sensor data Poll transceiver Process received packet

46. Processes/Threads Based on interrupts, context switching Based on interrupts, context switching Difficulties Difficulties  Too many context switches  Most tasks are short anyway  Each process required its own stack Handle sensor process Handle packet process OS-mediated process switching

47. Event-Based Concurrency Event-based programming model Event-based programming model  Perform regular processing or be idle  React to events when they happen immediately  Basically: interrupt handler Must not remain in interrupt handler too long Must not remain in interrupt handler too long  Danger of loosing events Idle/regular processing Radio event handler Sensor event handler

48. Components Instead of Processes An abstraction to group functionality An abstraction to group functionality Typically fulfill only a single, well-defined function Typically fulfill only a single, well-defined function  E.g., individual functions of a networking protocol Main difference to processes: Main difference to processes:  Component does not have an execution  Components access same address space, no protection against each other

49. Event-based Protocol Stack Usual networking API: sockets Usual networking API: sockets  Issue: blocking calls to receive data  Not match to event-based OS API is therefore also event-based 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 IWING's MoteLib and TinyOS

50. Outline Main components of a wireless sensor node Main components of a wireless sensor node  Processor, radio, sensors, batteries Energy supply and consumption Energy supply and consumption Operating systems and execution environments Operating systems and execution environments  IWING's MoteLib  TinyOS  Contiki Example implementations Example implementations

51. Case Study: IWING's MoteLib Developed by IWING (CPE, KU) along with IWING motes Developed by IWING (CPE, KU) along with IWING motes Provides hardware abstraction and virtualization in standard C interfaces Provides hardware abstraction and virtualization in standard C interfaces Follows event-based programming model Follows event-based programming model

52. MoteLib Architecture and API Software Hardware

53. Example: Count and Send Node#0 runs a counter and broadcasts its value Node#0 runs a counter and broadcasts its value Other nodes display received values on LEDs Other nodes display received values on LEDs

54. #include Timer timer; uint8_t counter; void timerFired(Timer *t) { counter++; radioRequestTx(BROADCAST_ADDR, 0, (char*)&counter, sizeof(counter), NULL); } void receive(Address source, MessageType type, void *message, uint8_t len) { ledSetValue(((char*)message)[0]); } void boot() { counter = 0; if (getAddress() == 0) { timerCreate(&timer); timerStart(&timer, TIMER_PERIODIC, 500, timerFired); } else radioSetRxHandler(receive); } Example: Count and Send called when node receives a radio packet called when timer expires called when node booted

55. Outline Main components of a wireless sensor node Main components of a wireless sensor node  Processor, radio, sensors, batteries Energy supply and consumption Energy supply and consumption Operating systems and execution environments Operating systems and execution environments  IWING's MoteLib  TinyOS  Contiki Example implementations Example implementations

56. Case Study: TinyOS Developed by UC Berkeley as runtime environment for their motes Developed by UC Berkeley as runtime environment for their motes nesC (network embedded system C) as adjunct programming language nesC (network embedded system C) as adjunct programming language Design aspects: 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) Website http://www.tinyos.net Website http://www.tinyos.nethttp://www.tinyos.net

57. TinyOS Components Components Components  Frame – state information  Tasks – normal execution program  Command handlers  Event handlers Hierarchically arranged Hierarchically arranged  Events are passed upward from hardware  Commands are passed downward TimerComponent setRate fire initstart stopfired Event handlers Command handlers Frame Tasks

58. Interfaces Many commands/events can be grouped Many commands/events can be grouped nesC structures corresponding commands/events into interface types nesC structures corresponding commands/events into interface types Example: Structure timer into three interfaces Example: Structure timer into three interfaces  StdCtrl  Timer  Clock The TimerComponent The TimerComponent  Provides: StdCtrl, Timer  Uses: Clock Clock setRate fire initstart stopfiredTimerStdCtrl TimerComponent

59. Forming New Components Clock HWClock Clock TimerStdCtrl TimerComponent "Clock" interface provider "Clock" interface user initStdCtrl start stopfiredTimer CompleteTimer

60. Sample nesC Code configuration CompleteTimer { provides { interface StdCtrl; interface Timer; } implementation { components TimerComponent, HWClock; StdCtrl = TimerComponent.StdCtrl; Timer = TimerComponent.Timer; TimerComponent.Clock -> HWClock.Clock; }

61. Active Messages Route map routersensor app Sample App Configuration RFM Radio byte Radio Packet UART Serial Packet ADC Tempphoto clocks bit byte packet application HW SW

62. Command/event handlers must run to completion Command/event handlers must run to completion  Must not wait an indeterminate amount of time  Only a request to perform some action Tasks can perform arbitrary, long computation Tasks can perform arbitrary, long computation  Can be interrupted by handlers  Also have to be run to completion  Preemptive multitasking not implemented Handlers versus Tasks Idle / Running task task queue Sensor event handler Radio event handler

63. Split-Phase Operations Request Data Blocking SensorController Synchronous Operation Asynchronous Operation SensorController Request Ready Ack Read Data

64. Outline Main components of a wireless sensor node Main components of a wireless sensor node  Processor, radio, sensors, batteries Energy supply and consumption Energy supply and consumption Operating systems and execution environments Operating systems and execution environments  IWING's MoteLib  TinyOS  Contiki Example implementations Example implementations

65. Case Study: Contiki Multitasking OS developed by Swedish Institute of Computer Science (SICS) Multitasking OS developed by Swedish Institute of Computer Science (SICS) The kernel is event driven The kernel is event driven Processes are protothreads Processes are protothreads  Very light weight threads  Provide a linear, thread-like programming model Comes with various communication stacks: uIP, uIPv6, Rime Comes with various communication stacks: uIP, uIPv6, Rime Website http://www.contiki-os.org/ Website http://www.contiki-os.org/http://www.contiki-os.org/

66. Problem with Multithreading Four threads, each with its own stack Four threads, each with its own stack Thread 1Thread 2Thread 3Thread 4

67. Events Require One Stack Four event handlers, one stack Four event handlers, one stack Eventhandler 1Eventhandler 2Eventhandler 3 Stack is reused for every event handler Eventhandler 4

68. Problem with Event-based Model Threads: sequential code flowEvents: unstructured code flow Very much like programming with GOTOs

69. Protothreads Protothreads require only one stack Protothreads require only one stack E.g, four protothreads, each with its own stack E.g, four protothreads, each with its own stack Events require one stack Protothread 1 Protothread 2Protothread 3Protothread 4 Just like events

70. PROCESS_THREAD(hello_world_process, ev, data) { PROCESS_BEGIN(); PROCESS_BEGIN(); printf(“Hello, world!\n”); printf(“Hello, world!\n”); while(1) { while(1) { PROCESS_WAIT_EVENT(); PROCESS_WAIT_EVENT(); } PROCESS_END(); PROCESS_END();} Contiki Processes Contiki processes are protothreads Contiki processes are protothreads

71. Contiki's Cooja Simulator

72. Summary The need to build cheap, low-energy, (small) devices has various consequences The need to build cheap, low-energy, (small) devices has various consequences  Much simpler radio frontends and controllers  Energy supply and scavenging are a premium resource  Power management is crucial Unique programming challenges of embedded systems Unique programming challenges of embedded systems  Concurrency without support, protection  De facto standard:  Event-based programming model: TinyOS  Multithreaded programming model: Contiki