Network Kernel Architectures and Implementation (01204423) - - PowerPoint PPT Presentation

network kernel architectures
SMART_READER_LITE
LIVE PREVIEW

Network Kernel Architectures and Implementation (01204423) - - PowerPoint PPT Presentation

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


slide-1
SLIDE 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

slide-2
SLIDE 2

Outline

Main components of a wireless sensor node

  • Processor, radio, sensors, batteries

Energy supply and consumption

Operating systems and execution environments

  • IWING's MoteLib
  • TinyOS
  • Contiki

Sample implementations

slide-3
SLIDE 3

Main Components

Communication Device Controller Sensors/ Actuators Power Supply Memory

slide-4
SLIDE 4

Controller

Main options:

  • Micr

croc

  • cont
  • ntro

roll ller er – general purpose processor,

  • ptimized for embedded applications, low

power consumption

  • DSP – optimized for signal processing tasks,

not suitable here

  • FPGA – may be good for testing
  • AS

ASIC – only when peak performance is needed, no flexibility

slide-5
SLIDE 5

Microcontroller Examples

Texas Instruments MSP430

  • 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 128KB Flash
  • 4 KB RAM
slide-6
SLIDE 6

Communication Device

Medium options

  • Electromagnetic, RF
  • Electromagnetic, optical
  • Ultrasound

Radio Transceiver

radio wave bit stream

slide-7
SLIDE 7

Transceiver Characteristics

Service to upper layer: packet, byte, bit

Power consumption

Supported frequency, multiple channels

Data rate

Modulation

Power control

Communication range

etc.

slide-8
SLIDE 8

Transceiver States

 Transceivers can be put into different

  • perational st

state tes, typically:

  • Transmit

ansmit

  • Receiv

ive

  • Idle

le – ready to receive, but not doing so

  • Sle

leep ep – significant parts

  • f the transceiver are

switched off Rx Tx Idle Sleep

slide-9
SLIDE 9

Wakeup Receivers

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 re

receive ver can already process simple addresses

  • Not clear whether they can be actually built, however
slide-10
SLIDE 10

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 “tilted”

to stop reflecting

  • Allows data to be

sent back to laser source

200 µm

slide-11
SLIDE 11

Sensors

Main categories

  • 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?

slide-12
SLIDE 12

Outline

Main components of a wireless sensor node

  • Processor, radio, sensors, batteries

Energy supply and consumption

Operating systems and execution environments

  • IWING's MoteLib
  • TinyOS
  • Contiki

Example implementations

slide-13
SLIDE 13

Energy Supply

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

  • In WSN, recharging may or may not be an
  • ption

Options

  • Primary batteries – not rechargeable
  • Secondary batteries – rechargeable, only

makes sense in combination with some form

  • f energy harvesting
slide-14
SLIDE 14

Energy Supply - Requirements

Low self-discharge

Long shelf life

Capacity under load

Efficient recharging at low current

Good relaxation properties (seeming self- recharging)

Voltage stability (to avoid DC-DC conversion)

slide-15
SLIDE 15

Battery Examples

Energy per volume (Joule/cc):

Pri rimar mary y ba batterie ries Chemistry Zinc-air Lithium Alkaline Energy (J/cm3) 3780 2880 1200 Secondar dary y ba batterie ries Chemistry Lithium NiMH NiCd Energy (J/cm3) 1080 860 650

http://en.wikipedia.org/wiki/Energy_density

slide-16
SLIDE 16

Energy Harvesting

How to recharge a battery?

  • A laptop: easy, plug into wall socket in the evening
  • A sensor node? – Try to scavenge energy from environment

Ambient energy sources

  • Light ! solar cells – between 10 W/cm2 and 15 mW/cm2
  • Temperature gradients – 80 W/cm2 @ 1 V from 5K difference
  • Vibrations – between 0.1 and 10000 W/cm3
  • Pressure variation (piezo-electric) – 330 W/cm2 from the heel of

a shoe

  • Air/liquid flow

(MEMS gas turbines)

slide-17
SLIDE 17

Portable Solar Chargers

Foldable Solar Chargers

  • http://www.energyenv.co.uk/FoldableChargers.asp

Solargorilla

  • http://powertraveller.com/iwantsome/primatepower/

solargorilla/

slide-18
SLIDE 18

Multiple Power Consumption Modes

Do not run sensor node at full operation all the time

  • If nothing to do, switch to power safe mode

Typical modes

  • 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?
slide-19
SLIDE 19

Energy Consumption Figures

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

  • Operational mode: 15 mW active, 6 mW idle
  • Six modes of operations
  • Sleep mode: 75 W
slide-20
SLIDE 20

Switching Between Modes

Simplest idea: Greedily switch to lower mode whenever possible

Problem: Time and power consumption required to reach higher modes not negligible

Pactive Psleep time tevent t1 Esaved tdown tup Eoverhead

slide-21
SLIDE 21

Should We Switch?

Switching modes is beneficial if which is equivalent to Eoverhead < Esaved

            

up sleep active sleep active down event

P P P P t t t t 2 1 ) (

1

slide-22
SLIDE 22

Computation vs. Communication Energy Cost

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

Key technique – in in-ne network

  • rk processing

ssing

  • Exploit compression schemes, intelligent

coding schemes, aggregate data, …

slide-23
SLIDE 23

Outline

Main components of a wireless sensor node

  • Processor, radio, sensors, batteries

Energy supply and consumption

Operating systems and execution environments

  • IWING's MoteLib
  • TinyOS
  • Contiki

Example implementations

slide-24
SLIDE 24

Mica Motes

By Crossbow, USA

MCU:

  • Atmel ATMega128L

Comm: RFM TR1000

slide-25
SLIDE 25

EYES Nodes

By Infineon, EU

MCU: TI MSP430

Comm: Infineon radio modem TDA5250

slide-26
SLIDE 26

Btnote

By ETH Zurich

MCU:

  • Atmel ATMega128L

Comm:

  • Bluetooth
  • Chipcon CC1000
slide-27
SLIDE 27

ScatterWeb

By Computer Systems & Telematics group, Freie Universitat Berlin

MCU:

  • TI MSP 430

Comm:

  • Bluetooth, I2C, CAN
slide-28
SLIDE 28

Tmote Sky

By Sentilla (formerly Moteiv), USA

MCU:

  • TI MSP430

Comm:

  • Chipcon CC2420

(IEEE 802.15.4)

slide-29
SLIDE 29

IRIS Motes

By Crossbow, USA

MCU: ATMega128L

Comm: Atmel's RF230 (IEEE 802.15.4)

3x radio range compared to Tmote

"Postage-stamp" form factor costs as low as $29 per unit (when purchased in large volumes)

slide-30
SLIDE 30

IMote2

By Intel Research

MCU: PXA271 XScale

Comm: Chipcon CC2420 (IEEE802.15.4)

slide-31
SLIDE 31

Other WSN-Capable Modules

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)

slide-32
SLIDE 32

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

slide-33
SLIDE 33

IWING-MRF Motes

Built from off-the-shelf components

Built-in USB boot loader

  • Reprogrammed via USB

Easy to modify and extend hardware

slide-34
SLIDE 34

IWING-MRF Mote

Processor

  • 8-bit AVR microcontroller ATMega88/168/328, 12

MHz

  • 16KB flash, 2KB RAM

RF transceiver

  • Microchip's MRF24J40A/B/C, 2.4GHz 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
slide-35
SLIDE 35

IWING-JN Motes

Built on JN5168 wireless microcontroller

32-bit RISC architecture

  • 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

slide-36
SLIDE 36

Outline

Main components of a wireless sensor node

  • Processor, radio, sensors, batteries

Energy supply and consumption

Operating systems and execution environments

  • IWING's MoteLib
  • TinyOS
  • Contiki

Example implementations

slide-37
SLIDE 37

Operating System Challenges

Usual operating system goals

  • Make access to device resources abstract

(virtualization)

  • Protect resources from concurrent access

Usual means

  • 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 power-

hungry

slide-38
SLIDE 38

Possible OS Options

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

  • There is only a single “application” running on a WSN

node

  • No need to protect malicious software parts from each
  • ther
  • Direct hardware control by application might improve

efficiency

slide-39
SLIDE 39

Possible OS Options

Currently popular approach

 No OS, just a simple run-time environment

  • Enough to abstract away hardware access

details

  • Biggest impact: Unusual programming model
slide-40
SLIDE 40

Concurrency Support

Simplest option: No concurrency, sequential processing of tasks

  • Risk of missing data
  • Should support

interrupts/asynchronous

  • perations

Poll sensor Process sensor data Poll transceiver Process received packet

slide-41
SLIDE 41

Processes/Threads

Based on interrupts, context switching

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

slide-42
SLIDE 42

Event-Based Concurrency

Event nt-bas based ed prog

  • grammi

mming ng mod

  • del
  • 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

Idle/regular processing

Radio event handler Sensor event handler

slide-43
SLIDE 43

Components Instead of Processes

An abstraction to group functionality

Typically fulfill only a single, well-defined function

  • 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

slide-44
SLIDE 44

Event-based Protocol Stack

Usual networking API: sockets

  • 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 MoteLib and TinyOS
slide-45
SLIDE 45

Outline

Main components of a wireless sensor node

  • Processor, radio, sensors, batteries

Energy supply and consumption

Operating systems and execution environments

  • IWING's MoteLib
  • TinyOS
  • Contiki

Example implementations

slide-46
SLIDE 46

Case Study: IWING's MoteLib

Developed by IWING (CPE, KU) along with IWING motes

Provides hardware abstraction and virtualization in standard C interfaces

Follows event-based programming model

slide-47
SLIDE 47

MoteLib Architecture and API

Software Hardware

slide-48
SLIDE 48

Example: Count and Send

Node#0 runs a counter and broadcasts its value

Other nodes display received values on LEDs

slide-49
SLIDE 49

#include <motelib/system.h> #include <motelib/timer.h> #include <motelib/radio.h> #include <motelib/led.h> 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

slide-50
SLIDE 50

Outline

Main components of a wireless sensor node

  • Processor, radio, sensors, batteries

Energy supply and consumption

Operating systems and execution environments

  • IWING's MoteLib
  • TinyOS
  • Contiki

Example implementations

slide-51
SLIDE 51

Case Study: TinyOS

Developed by UC Berkeley as runtime environment for their motes

nesC (network embedded system C) as adjunct programming language

Design aspects:

  • Component-based system
  • Components interact by exchanging asynchronous

events

  • Components form a program by wiri

ring them together (akin to VHDL – hardware description language)

Website http://www.tinyos.net

slide-52
SLIDE 52

TinyOS Components

Components

  • Frame – state information
  • Tasks – normal execution

program

  • Command handlers
  • Event handlers

Hierarchically arranged

  • Events are passed upward

from hardware

  • Commands are passed

downward

TimerComponent

setRate fire init start stop fired

Event handlers Command handlers Frame Tasks

slide-53
SLIDE 53

Interfaces

Many commands/events can be grouped

nesC structures corresponding commands/events into interf rface ace types s

Example: Structure timer into three interfaces

  • StdCtrl
  • Timer
  • Clock

The TimerComponent

  • Provides: StdCtrl, Timer
  • Uses: Clock

Clock

setRate fire init start stop fired

Timer StdCtrl

TimerComponent

slide-54
SLIDE 54

Forming New Components

Clock

HWClock

Clock Timer StdCtrl

TimerComponent

"Clock" interface provider "Clock" interface user

init

StdCtrl

start stop fired

Timer

CompleteTimer

slide-55
SLIDE 55

Sample nesC Code

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

slide-56
SLIDE 56

Active Messages Route map router sensor app

Sample App Configuration

RFM Radio byte Radio Packet UART Serial Packet ADC Temp photo clocks bit byte packet application

HW SW

slide-57
SLIDE 57

Command/event handlers must run to completion

  • Must not wait an indeterminate amount of time
  • Only a re

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

Handlers versus Tasks

Idle / Running task

task queue

Sensor event handler Radio event handler

slide-58
SLIDE 58

Split-Phase Operations

Request Data Blocking Sensor Controller

Synchronous Operation Asynchronous Operation

Sensor Controller Request Ready Ack Read Data

slide-59
SLIDE 59

Outline

Main components of a wireless sensor node

  • Processor, radio, sensors, batteries

Energy supply and consumption

Operating systems and execution environments

  • IWING's MoteLib
  • TinyOS
  • Contiki

Example implementations

slide-60
SLIDE 60

Case Study: Contiki

Multitasking OS developed by Swedish Institute of Computer Science (SICS)

The kernel is event driven

Processes are protothreads

  • Very light weight threads
  • Provide a linear, thread-like programming

model

Comes with various communication stacks: uIP, uIPv6, Rime

Website http://www.contiki-os.org/

slide-61
SLIDE 61

Problem with Multithreading

Four threads, each with its own stack

Thread 1 Thread 2 Thread 3 Thread 4

slide-62
SLIDE 62

Events Require One Stack

Four event handlers, one stack

Eventhandler 1 Eventhandler 2 Eventhandler 3

Stack is reused for every event handler

Eventhandler 4

slide-63
SLIDE 63

Problem with Event-based Model

Threads: sequential code flow Events: unstructured code flow

Very much like programming with GOTOs

slide-64
SLIDE 64

Protothreads

Protothreads require only one stack

E.g, four protothreads, each with its own stack

Events require one stack

Protothread 1 Protothread 2 Protothread 3 Protothread 4

Just like events

slide-65
SLIDE 65

PROCESS_THREAD(hello_world_process, ev, data) { PROCESS_BEGIN(); printf(“Hello, world!\n”); while(1) { PROCESS_WAIT_EVENT(); } PROCESS_END(); }

Contiki Processes

Contiki processes are protothreads

slide-66
SLIDE 66

Contiki's Cooja Simulator

slide-67
SLIDE 67

Summary

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

  • Concurrency without support, protection
  • De facto standard:
  • Event-based programming model: TinyOS
  • Multithreaded programming model: Contiki