Wireless Sensor Networks

Chapter 2: Single node architecture

António Grilo

Courtesy: Holger Karl, UPB

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

Wireless Sensor Networks: Single Node Architecture 2

Outline
• Sensor node architecture
• Energy supply and consumption
• Runtime environments for sensor nodes
• Case study: TinyOS

Wireless Sensor Networks: Single Node Architecture 3

Sensor node architecture
• Main components of a WSN node
• Controller
• Communication device(s)
• Sensors/actuators
• Memory
• Power supply

Memory

Communication Sensor(s)/
Controller
device actuator(s)

Power supply

Wireless Sensor Networks: 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

Wireless Sensor Networks: 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 MSP430
• 16-bit RISC core, up to 4 MHz, versions with 2-10 kbytes RAM,
several DACs, RT clock, prices start at 0.49 US$
• Atmel ATMega
• 8-bit controller, larger memory than MSP430, slower

Wireless Sensor Networks: Single Node Architecture 6

Example Controllers

In: P. Baronti et al., “Wireless sensor networks: A survey ...”

Wireless Sensor Networks: Single Node Architecture 7

Communication device
• Which transmission medium?
• Electromagnetic at radio frequencies? 9
• Electromagnetic, light?
• Ultrasound?

• Radio transceivers transmit a bit- or byte stream as radio

wave
• Receive it, convert it back into bit-/byte stream

Wireless Sensor Networks: Single Node Architecture 8

Transceiver characteristics
• Capabilities • Radio performance
• Interface: bit, byte, packet level? • Modulation? (ASK, FSK, …?)
• Supported frequency range? • Noise figure? NF = SNRI/SNRO
• Typically, somewhere in 433 MHz • Gain? (signal amplification)
– 2.4 GHz, ISM band
• Receiver sensitivity? (minimum S to
• Multiple channels? achieve a given Eb/N0)
• Data rates? • Blocking performance (achieved
• Range? BER in presence of frequency-
offset interferer)
• Energy characteristics • Out of band emissions
• Power consumption to send/receive • Carrier sensing & RSSI
data? characteristics
• Time and energy consumption to • Frequency stability (e.g., towards
change between different states? temperature changes)
• Transmission power control? • Voltage range
• Power efficiency (which percentage
of consumed power is radiated?)

Wireless Sensor Networks: Single Node Architecture 9

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!)

Wireless Sensor Networks: Single Node Architecture 10

Example radio transceivers
• Almost boundless variety available • Chipcon CC 2400
• Some examples • Implements 802.15.4
• 2.4 GHz, DSSS modem
• RFM TR1000 family
• 250 kbps
• 916 or 868 MHz
• Higher power consumption
• 400 kHz bandwidth
than above transceivers
• Up to 115,2 kbps
• Infineon TDA 525x family
• On/off keying or ASK
• E.g., 5250: 868 MHz
• Dynamically tuneable output
power • ASK or FSK modulation
• Maximum power about 1.4 mW • RSSI, highly efficient power
amplifier
• Low power consumption
• Intelligent power down,
• Chipcon CC1000 “self-polling” mechanism
• Range 300 to 1000 MHz, • Excellent blocking
programmable in 250 Hz steps performance
• FSK modulation
• Provides RSSI

Wireless Sensor Networks: Single Node Architecture 11

Example radio transceivers for ad hoc networks
• Ad hoc networks: Usually, higher data rates are required
• Typical: IEEE 802.11 b/g/a is considered
• Up to 54 MBit/s
• Relatively long distance (100s of meters possible, typical 10s of
meters at higher data rates)
• Works reasonably well (but certainly not perfect) in mobile
environments
• Problem: expensive equipment, quite power hungry

• WLAN technology is not cost-effective in WSN applications (more

about this later on)

Wireless Sensor Networks: Single Node Architecture 12

Wakeup WSN 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 and
limited scalability, somewhat inflexible (more of a problem in
MANETs)

• 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

Wireless Sensor Networks: Single Node Architecture 13

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

Wireless Sensor Networks: Single Node Architecture 15

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, movement IR sensor
• Active sensors
• Example: Radar

• Important parameter: Area of coverage

• Which region is adequately covered by a given sensor?

Wireless Sensor Networks: Single Node Architecture 16

Outline
• Sensor node architecture
• Energy supply and consumption
• Runtime environments for sensor nodes
• Case study: TinyOS

Wireless Sensor Networks: Single Node Architecture 17

Energy supply of mobile/sensor nodes
• Goal: provide as much energy as possible at smallest
cost/volume/weight/recharge time/longevity
• In WSN, recharging may or may not be an option
• Options
• Primary batteries – not rechargeable
• Secondary batteries – rechargeable, only makes sense in
combination with some form of energy harvesting
• Requirements include
• Low self-discharge
• Long shelf live
• Capacity under load
• Efficient recharging at low current
• Good relaxation properties (seeming self-recharging)
• Voltage stability (to avoid DC-DC conversion)

Wireless Sensor Networks: Single Node Architecture 18

Battery examples
• Energy per volume (Joule per cubic centimeter):

Primary batteries
Chemistry Zinc-air Lithium Alkaline
Energy (J/cm3) 3780 2880 1200
Secondary batteries
Chemistry Lithium NiMHd NiCd
Energy (J/cm3) 1080 860 650

Wireless Sensor Networks: Single Node Architecture 19

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/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)

Wireless Sensor Networks: Single Node Architecture 20

Energy scavenging – overview

Wireless Sensor Networks: Single Node Architecture 21

Energy consumption
• A “back of the envelope” estimation

• Number of instructions
• Energy per instruction: 1 nJ
• Small battery (“smart dust”): 1 J = 1 Ws
• Corresponds: 109 instructions!

• Lifetime
• Or: Require a single day operational lifetime = 24*60*60 =86400 s
• 1 Ws / 86400s ¼ 11.5 μW as max. sustained power consumption!

• Not feasible!

Wireless Sensor Networks: Single Node Architecture 22

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

Wireless Sensor Networks: Single Node Architecture 23

Some energy consumption figures
• Microcontroller
• TI MSP 430 (@ 1 MHz, 3V):
• Fully operation 1.2 mW
• Deepest sleep mode 0.3 μW – only woken up by external interrupts
(not even timer is running any more)
• Atmel ATMega
• Operational mode: 15 mW active, 6 mW idle
• Sleep mode: 75 μW

Wireless Sensor Networks: Single Node Architecture 24

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
• Does switching pay off?
• Example: Esaved Eoverhead
Event-triggered
wake up from Pactive
sleep mode
• Scheduling problem Psleep
with uncertainty
t1 tevent time
τdown τup

Wireless Sensor Networks: Single Node Architecture 25

 Switching between modes: Does it pay off?
• A. Sinha et al., “Dynamic Power
Management in Wireless Sensor
Networks”

⎛ P0 + Pk ⎞
E save, k = P0 ⋅ t i − ⎜ ⎟ ⋅ (τ d , k + τ u , k ) − Pk ⋅ (ti − τ d , k )
⎝ 2 ⎠
E save, k > 0 ⇔ t i > Tth, k
1 ⎡ ⎛ P0 + Pk ⎞ ⎤
Tth, k = ⋅ ⎢τ d , k + ⎜⎜ ⎟ ⋅τ u , k ⎥
⎟
2 ⎢⎣ ⎝ P0 − Pk ⎠ ⎥⎦
Wireless Sensor Networks: Single Node Architecture 26
 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 V2
• Lower clock allows
lower supply voltage
• Easy to switch to higher clock
• But: execution takes longer
Memory power consumption
• Crucial part: FLASH memory
• Power for RAM almost negligible

• FLASH writing/erasing is expensive

• Example: FLASH on Mica motes
• Reading: ¼ 1.1 nAh per byte
• Writing: ¼ 83.3 nAh per byte

Wireless Sensor Networks: Single Node Architecture 28

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 PtxElec
• Time to transmit n bits: n / (R * Rcode)
• R nominal data rate, Rcode coding rate
• To leave sleep mode
• Time Tstart, average power Pstart

! Etx = Tstart Pstart + n / (R * Rcode) (PtxElec + αamp + βamp Ptx)

• Simplification: Modulation not considered

Wireless Sensor Networks: Single Node Architecture 29

Receiver power/energy consumption for n bits
• Receiver also has startup costs
• Time Tstart, average power P
start
• Time for n bits is the same n / (R * Rcode)
• Receiver electronics needs PrxElec
• Plus: energy to decode n bits EdecBits

! Erx = Tstart Pstart + n / (R * Rcode) PrxElec + EdecBits ( R )

Wireless Sensor Networks: Single Node Architecture 30

Some transceiver numbers

Wireless Sensor Networks: Single Node Architecture 31

Comparison: GSM base station power consumption
Heat 602W Heat 1920W Heat 360W

• Overview
DC power RF power
AC power TRX TOC RF
3200W 480W
3802W 2400W 120W
PS -48V
TRXs ACE
84% Combining

Central Heat 800W

CE equipm.
BTS 800W Total Heat
3682W

AC Power Rack Com-

• Details
supply cabling mon
300W
220V -48V -48V
85% 99%
3802W 3232W 3200W Fans (No active cooling)
500W cooling
PAs consume 2400W
dominant part of power
12 transceivers
(12*140W)/2400W=70%
200W
idle
140W 60W
Usable PA efficiency Converter

• (just to put things 40W/140W=28% 85%

-48V/+27V
119W Bias
Erlang
into perspective) Overall efficiency
(12*10W)/3802W=3.1%
efficiency 75%
9W Combiner
Diplexer
TOC
DTX activity
47% 110W
PA 10W
15W
40W

Wireless Sensor Networks: Single Node Architecture 32

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

Wireless Sensor Networks: Single Node Architecture 33

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, data
aggregation schemes…

Wireless Sensor Networks: Single Node Architecture 34

Outline
• Sensor node architecture
• Energy supply and consumption
• Runtime environments for sensor nodes
• Case study: TinyOS

Wireless Sensor Networks: Single Node Architecture 35

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

! ???

Wireless Sensor Networks: Single Node Architecture 36

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

Wireless Sensor Networks: Single Node Architecture 37

Main issue: How to support concurrency
• Simplest option: No concurrency, Poll sensor
sequential processing of tasks
• Not satisfactory: Risk of missing data
(e.g., from transceiver) when processing Process
data, etc. sensor
data
! Interrupts/asynchronous operation has to
be supported

Poll transceiver
• Why concurrency is needed
• Sensor node’s CPU has to service the
radio modem, the actual sensors, perform Process
computation for application, execute received
communication protocol software, etc. packet

Wireless Sensor Networks: Single Node Architecture 38

Traditional concurrency: Processes
• Traditional OS: Handle sensor Handle packet
process process
processes/threads
• Based on interrupts, context
switching
• But: not available – memory
overhead, execution overhead
• But: concurrency mismatch
• One process per protocol entails
too many context switches
• Many tasks in WSN small with
respect to context switching
overhead
• And: protection between
processes not needed in WSN
OS-mediated
• Only one application anyway
process switching

Wireless Sensor Networks: Single Node Architecture 39

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
Sensor event
event

Idle / Regular Radio event handler

processing
Sensor event
handler
Wireless Sensor Networks: Single Node Architecture 40
Components instead of processes
• Need an abstraction to group functionality
• Replacing “processes” for this purpose
• E.g.: individual functions of a networking protocol

• One option: Components

• Here: In the sense of TinyOS
• Typically fulfill only a single, well-defined function
• Main difference to processes:
• Component does not have an execution
• Components access same address space, no protection against each
other
• NOT to be confused with component-based programming!

Wireless Sensor Networks: Single Node Architecture 41

API to an event-based protocol stack
• Usual networking API: sockets
• Issue: blocking calls to receive data
• Ill-matched to event-based OS
• Also: networking semantics in WSNs not necessarily well matched
to/by socket semantics

• API is therefore also event-based

• E.g.: Tell some component that some other component wants to be
informed if and when data has arrived
• Component will be posted an event once this condition is met
• Details: see TinyOS example discussion below

Wireless Sensor Networks: Single Node Architecture 42

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 to the required speed from 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

Wireless Sensor Networks: Single Node Architecture 43

Outline
• Sensor node architecture
• Energy supply and consumption
• Runtime environments for sensor nodes
• Case study: TinyOS

Wireless Sensor Networks: Single Node Architecture 44

Case study embedded OS: TinyOS & nesC
• TinyOS developed by UC Berkely as runtime environment
for their “motes”
• nesC as adjunct “programming language”
• Goal: Small memory footprint
• Sacrifices made e.g. in ease of use, portability
• Portability somewhat improved in newer version
• Most important design aspects
• Component-based system
• Components interact by exchanging asynchronous events
• Components form a program by wiring them together (akin to
VHDL – hardware description language)

Wireless Sensor Networks: Single Node Architecture 45

TinyOS components
• Components
• Frame – state information
• Tasks – normal execution init start stop fired
program
• Command handlers
• Event handlers
• Handlers Command
Frame
handlers
• Must run to completion
• Form a component’s interface
TimerComponent
• Understand and emits
commands & events Event
Tasks
• Hierarchically arranged handlers
• Events pass upward from
hardware to higher-level
components
• Commands are passed setRate fire
downward

Wireless Sensor Networks: Single Node Architecture 46

Handlers versus tasks
• Command handlers and events must run to completion
• Must not wait an indeterminate amount of time
• Only a request to perform some action
• Tasks, on the other hand, can perform arbitrary, long
computation
• Also have to be run to completion since no non-cooperative multi-
tasking is implemented
• But can be interrupted by handlers
! No need for stack management, tasks are atomic with respect to
each other

Wireless Sensor Networks: Single Node Architecture 47

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

Wireless Sensor Networks: Single Node Architecture 48

Structuring commands/events into interfaces
• Many commands/events can add up
• nesC solution: Structure corresponding commands/events
into interface types
• Example: Structure timer into three interfaces
• StdCtrl
init start stop fired
• Timer
• Clock
StdCtrl Timer
• Build configurations by
TimerComponent
wiring together
corresponding interfaces Clock

setRate fire

Wireless Sensor Networks: Single Node Architecture 49

Building components out of simpler ones
• Wire together
StdCtrl Timer
components to form more
complex components out
of simpler ones
StdCtrl Timer
• New interfaces for the
TimerComponent
complex component
Clock

Clock

HWClock

CompleteTimer

Wireless Sensor Networks: Single Node Architecture 50

Defining modules and components in nesC

Wireless Sensor Networks: Single Node Architecture 51

Wiring components to form a configuration

Wireless Sensor Networks: Single Node Architecture 52

Summary
• For WSN, the need to build cheap, low-energy, (small)
devices has various consequences for system design
• Radio frontends and controllers are much simpler than in
conventional mobile networks
• Energy supply and scavenging are still (and for the foreseeable
future) a premium resource
• Power management (switching off or throttling down devices)
crucial
• Unique programming challenges of embedded systems
• Concurrency without support, protection
• De facto standard: TinyOS

Wireless Sensor Networks: Single Node Architecture 53