Network Kernel Architectures and Implementation 01204423 SingleNode Architectures

  • Slides: 67
Download presentation
Network Kernel Architectures and Implementation (01204423) Single-Node Architectures Materials taken from lecture slides by

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

Outline l Main components of a wireless sensor node Ø l l Energy supply

Outline l Main components of a wireless sensor node Ø l l Energy supply and consumption Operating systems and execution environments Ø Ø Ø l Processor, radio, sensors, batteries IWING's Mote. Lib Tiny. OS Contiki Sample implementations

Main Components Memory Communication Device Controller Power Supply Sensors/ Actuators

Main Components Memory Communication Device Controller Power Supply Sensors/ Actuators

Controller l Main options: Ø Ø Microcontroller – general purpose processor, optimized for embedded

Controller l 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

Microcontroller Examples l Texas Instruments MSP 430 Ø Ø l 16 -bit RISC core,

Microcontroller Examples l Texas Instruments MSP 430 Ø Ø l 16 -bit RISC core, 4 MHz Up to 120 KB flash 2 -10 KB RAM 12 ADCs, RT clock Atmel ATMega Ø Ø Ø 8 -bit controller, 8 MHz Up to 128 KB Flash 4 KB RAM

Communication Device l Medium options Ø Ø Ø Electromagnetic, RF Electromagnetic, optical Ultrasound bit

Communication Device l Medium options Ø Ø Ø Electromagnetic, RF Electromagnetic, optical Ultrasound bit stream Radio Transceiver radio wave

Transceiver Characteristics l l l l Service to upper layer: packet, byte, bit Power

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

Transceiver States l Transceivers can be put into different operational states, typically: Ø Ø

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

Wakeup Receivers l When to switch on a receiver is not clear Ø Ø

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

Optical Communication l l Optical communication can consume less energy Example: passive readout via

Optical Communication l l 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 “tilted” to stop reflecting Allows data to be sent back to 200 µm laser source

Sensors l Main categories Ø Passive, omnidirectional § Ø Passive, narrow-beam § Ø Example:

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

Outline l Main components of a wireless sensor node Ø l l Energy supply

Outline l Main components of a wireless sensor node Ø l l Energy supply and consumption Operating systems and execution environments Ø Ø Ø l Processor, radio, sensors, batteries IWING's Mote. Lib Tiny. OS Contiki Example implementations

Energy Supply l Goal: provide as much energy as possible at smallest cost/volume/weight/recharge time/longevity

Energy Supply l Goal: provide as much energy as possible at smallest cost/volume/weight/recharge time/longevity Ø l 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

Energy Supply - Requirements l l l Low self-discharge Long shelf life Capacity under

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

Battery Examples l Energy per volume (Joule/cc): Chemistry Energy (J/cm 3) Primary batteries Zinc-air

Battery Examples l Energy per volume (Joule/cc): Chemistry Energy (J/cm 3) Primary batteries Zinc-air Lithium 3780 2880 Alkaline 1200 Secondary batteries Lithium Ni. MH 1080 860 Ni. Cd 650 http: //en. wikipedia. org/wiki/Energy_density

Energy Harvesting l How to recharge a battery? Ø Ø l A laptop: easy,

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

Portable Solar Chargers l Foldable Solar Chargers Ø l http//: www. energyenv. co. uk/Foldable.

Portable Solar Chargers l Foldable Solar Chargers Ø l http//: www. energyenv. co. uk/Foldable. Chargers. asp Solargorilla Ø http: //powertraveller. com/iwantsome/primatepower/ solargorilla/

Multiple Power Consumption Modes l Do not run sensor node at full operation all

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

Energy Consumption Figures l TI MSP 430 (@ 1 MHz, 3 V): Ø Ø

Energy Consumption Figures l TI MSP 430 (@ 1 MHz, 3 V): Ø Ø Ø l Fully operation 1. 2 m. W 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 Ø Ø Ø Operational mode: 15 m. W active, 6 m. W idle Six modes of operations Sleep mode: 75 W

Switching Between Modes l l Simplest idea: Greedily switch to lower mode whenever possible

Switching Between Modes l l Simplest idea: Greedily switch to lower mode whenever possible Problem: Time and power consumption required to reach higher modes not negligible E E overhead saved Pactive Psleep t 1 tdown tevent tup time

Should We Switch? l Switching modes is beneficial if Eoverhead < Esaved which is

Should We Switch? l Switching modes is beneficial if Eoverhead < Esaved which is equivalent to

Computation vs. Communication Energy Cost l Sending one bit vs. running one instruction Ø

Computation vs. Communication Energy Cost l Sending one bit vs. running one instruction Ø Ø l l 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 Key technique – in-network processing Ø Exploit compression schemes, intelligent coding schemes, aggregate data, …

Outline l Main components of a wireless sensor node Ø l l Energy supply

Outline l Main components of a wireless sensor node Ø l l Energy supply and consumption Operating systems and execution environments Ø Ø Ø l Processor, radio, sensors, batteries IWING's Mote. Lib Tiny. OS Contiki Example implementations

Mica Motes l l By Crossbow, USA MCU: Ø l Atmel ATMega 128 L

Mica Motes l l By Crossbow, USA MCU: Ø l Atmel ATMega 128 L Comm: RFM TR 1000

EYES Nodes l l l By Infineon, EU MCU: TI MSP 430 Comm: Infineon

EYES Nodes l l l By Infineon, EU MCU: TI MSP 430 Comm: Infineon radio modem TDA 5250

Btnote l l By ETH Zurich MCU: Ø l Atmel ATMega 128 L Comm:

Btnote l l By ETH Zurich MCU: Ø l Atmel ATMega 128 L Comm: Ø Ø Bluetooth Chipcon CC 1000

Scatter. Web l l By Computer Systems & Telematics group, Freie Universitat Berlin MCU:

Scatter. Web l l By Computer Systems & Telematics group, Freie Universitat Berlin MCU: Ø l TI MSP 430 Comm: Ø Bluetooth, I 2 C, CAN

Tmote Sky l l By Sentilla (formerly Moteiv), USA MCU: Ø l TI MSP

Tmote Sky l l By Sentilla (formerly Moteiv), USA MCU: Ø l TI MSP 430 Comm: Ø Chipcon CC 2420 (IEEE 802. 15. 4)

IRIS Motes l l l By Crossbow, USA MCU: ATMega 128 L Comm: Atmel's

IRIS Motes l l l By Crossbow, USA MCU: ATMega 128 L Comm: Atmel's RF 230 (IEEE 802. 15. 4) 3 x radio range compared to Tmote "Postage-stamp" form factor costs as low as $29 per unit (when purchased in large volumes)

IMote 2 l l l By Intel Research MCU: PXA 271 XScale Comm: Chipcon

IMote 2 l l l By Intel Research MCU: PXA 271 XScale Comm: Chipcon CC 2420 (IEEE 802. 15. 4)

Other WSN-Capable Modules l Many low-cost, wireless So. C modules already available Hope. RF

Other WSN-Capable Modules l Many low-cost, wireless So. C modules already available Hope. RF 433 MHz module based on Silicon Labs's So. C (~6 USD/module) Synapse Wireless 2. 4 GHz module based on Atmel's So. C SNAP OS / embedded Python (~25 USD/module)

IWING-MRF Motes Analog/Digital sensor connectors UART Connector Radio transceiver USB Connector (for reprogramming and

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

IWING-MRF Motes l l Built from off-the-shelf components Built-in USB boot loader Ø l

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

IWING-MRF Mote l l Processor Ø 8 -bit AVR microcontroller ATMega 88/168/328, 12 MHz

IWING-MRF Mote l l Processor Ø 8 -bit AVR microcontroller ATMega 88/168/328, 12 MHz Ø 16 KB flash, 2 KB RAM RF transceiver Ø Microchip's MRF 24 J 40 A/B/C, 2. 4 GHz IEEE 802. 15. 4 Ø SPI interface External connectors Ø 6 ADC connectors (can also be used as TWI) Ø 1 UART Power options Ø 3 – 3. 6 VDC Ø USB or 2 AA batteries

IWING-JN Motes l l Built on JN 5168 wireless microcontroller 32 -bit RISC architecture

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

Outline l Main components of a wireless sensor node Ø l l Energy supply

Outline l Main components of a wireless sensor node Ø l l Energy supply and consumption Operating systems and execution environments Ø Ø Ø l Processor, radio, sensors, batteries IWING's Mote. Lib Tiny. OS Contiki Example implementations

Operating System Challenges l Usual operating system goals Ø Ø l Usual means Ø

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

Possible OS Options l Try to implement “as close to an operating system” on

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

Possible OS Options l Currently popular approach No OS, just a simple run-time environment

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

Concurrency Support l Simplest option: No concurrency, sequential processing of tasks Ø Ø Risk

Concurrency Support l 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

Processes/Threads l l Based on interrupts, context switching Difficulties Ø Handle packet process Too

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

Event-Based Concurrency l Event-based programming model Ø Ø Ø l Perform regular processing or

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

Components Instead of Processes l l An abstraction to group functionality Typically fulfill only

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

Event-based Protocol Stack l Usual networking API: sockets Ø Ø l Issue: blocking calls

Event-based Protocol Stack l Usual networking API: sockets Ø Ø l Issue: blocking calls to receive data Not match to event-based OS 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 Mote. Lib and Tiny. OS

Outline l Main components of a wireless sensor node Ø l l Energy supply

Outline l Main components of a wireless sensor node Ø l l Energy supply and consumption Operating systems and execution environments Ø IWING's Mote. Lib Ø Ø l Processor, radio, sensors, batteries Tiny. OS Contiki Example implementations

Case Study: IWING's Mote. Lib l l l Developed by IWING (CPE, KU) along

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

Mote. Lib Architecture and API Software Hardware

Mote. Lib Architecture and API Software Hardware

Example: Count and Send l l Node#0 runs a counter and broadcasts its value

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

Example: Count and Send #include <motelib/system. h> <motelib/timer. h> <motelib/radio. h> <motelib/led. h> Timer

Example: Count and Send #include <motelib/system. h> <motelib/timer. h> <motelib/radio. h> <motelib/led. h> Timer timer; uint 8_t counter; called when timer expires called when node receives a radio packet void timer. Fired(Timer *t) { counter++; radio. Request. Tx(BROADCAST_ADDR, 0, (char*)&counter, sizeof(counter), NULL); } void receive(Address source, Message. Type type, void *message, uint 8_t len) { led. Set. Value(((char*)message)[0]); } called when node booted void boot() { counter = 0; if (get. Address() == 0) { timer. Create(&timer); timer. Start(&timer, TIMER_PERIODIC, 500, timer. Fired); } else radio. Set. Rx. Handler(receive); }

Outline l Main components of a wireless sensor node Ø l l l Processor,

Outline l Main components of a wireless sensor node Ø l l l Processor, radio, sensors, batteries Energy supply and consumption Operating systems and execution environments Ø IWING's Mote. Lib Ø Tiny. OS Ø Contiki Example implementations

Case Study: Tiny. OS l l l Developed by UC Berkeley as runtime environment

Case Study: Tiny. OS l l l Developed by UC Berkeley as runtime environment for their motes nes. C (network embedded system C) as adjunct programming language Design aspects: Ø Ø Ø l 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

Tiny. OS Components l Components Ø Ø l Frame – state information Tasks –

Tiny. OS Components l Components Ø Ø l Frame – state information Tasks – normal execution program Command handlers Event handlers Hierarchically arranged Ø Ø Events are passed upward from hardware Commands are passed downward init start stop fired Command handlers Frame Timer. Component Event handlers Tasks set. Rate fire

Interfaces l l l Many commands/events can be grouped nes. C structures corresponding commands/events

Interfaces l l l Many commands/events can be grouped nes. C structures corresponding commands/events into interface types Example: Structure timer into three interfaces Ø Ø Ø l Std. Ctrl Timer Clock The Timer. Component Ø Ø Provides: Std. Ctrl, Timer Uses: Clock init start stop fired Std. Ctrl Timer. Component Clock set. Rate fire

Forming New Components init start stop fired Std. Ctrl Timer. Component "Clock" interface user

Forming New Components init start stop fired Std. Ctrl Timer. Component "Clock" interface user Clock HWClock "Clock" interface provider Complete. Timer

Sample nes. C Code configuration Complete. Timer { provides { interface Std. Ctrl; interface

Sample nes. C Code configuration Complete. Timer { provides { interface Std. Ctrl; interface Timer; } implementation { components Timer. Component, HWClock; Std. Ctrl = Timer. Component. Std. Ctrl; Timer = Timer. Component. Timer; Timer. Component. Clock -> HWClock; } }

application Sample App Configuration Route map router sensor app bit byte packet Active Messages

application Sample App Configuration Route map router sensor app bit byte packet Active Messages Radio Packet Radio byte RFM Serial Packet UART Temp photo ADC SW HW clocks

Handlers versus Tasks Sensor event handler Idle / Running task Radio event handler task

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

Split-Phase Operations Controller Sensor Request Ack Blocking Data Ready Read Data Synchronous Operation Asynchronous

Split-Phase Operations Controller Sensor Request Ack Blocking Data Ready Read Data Synchronous Operation Asynchronous Operation

Outline l Main components of a wireless sensor node Ø l l Energy supply

Outline l Main components of a wireless sensor node Ø l l Energy supply and consumption Operating systems and execution environments Ø Ø IWING's Mote. Lib Tiny. OS Contiki Example implementations Ø l Processor, radio, sensors, batteries

Case Study: Contiki l l l Multitasking OS developed by Swedish Institute of Computer

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

Problem with Multithreading l Four threads, each with its own stack Thread 1 Thread

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

Events Require One Stack l Four event handlers, one stack Stack is reused for

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

Problem with Event-based Model Events: unstructured code flow Threads: sequential code flow Very much

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

Protothreads l l Protothreads require only one stack E. g, four protothreads, each with

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

Contiki Processes l Contiki processes are protothreads PROCESS_THREAD(hello_world_process, ev, data) { PROCESS_BEGIN(); printf(“Hello, world!n”);

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

Contiki's Cooja Simulator

Contiki's Cooja Simulator

Summary l The need to build cheap, low-energy, (small) devices has various consequences Ø

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