Single Node Architecture: Goals of This Chapter

Chapter 2: Single Node
Architecture
For use in conjunction with Protocols and Architectures for Wireless
Sensor Networks, by Holger Karl, Andreas Willig (http://www.wiley.
com)
Advanced Techniques of Mobile Ad Hoc and Wireless Sensor Networks
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
2
1
Outline
 Sensor node architecture
 Energy supply and consumption
 Runtime environments for sensor nodes
 Case study: TinyOS
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
4
2
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
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 (Field Programmable Gate Array) – 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
6
3
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
7
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  Gain? (signal amplification)
MHz – 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?)
8
4
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!)
9
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  RSSI, highly efficient power
mW amplifier
 Low CC1000
power consumption  Intelligent power down,
 Chipcon “self-polling” mechanism
 Range 300 to 1000 MHz,  Excellent blocking
programmable in 250 Hz steps performance
 FSK modulation
 Provides RSSI
10
5
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
1
1
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
1
2
6
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
1
4
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?
15
Outline
16
8
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)
1
7
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
18
9
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)
1
9
Advanced Techniques of Mobile Ad Hoc
and Wireless Sensor Networks
Energy scavenging – overview
20
10
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!
21
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
2
2
11
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
2
3
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: Esaved Eoverhead
Event-triggered
wake up from Pactive
sleep mode
 Scheduling problem Psleep
with uncertainty
time
(exercise) down tevent
up
24
t1
12
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
26
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 · R
code
) R nomial data rate, R coding
code
rate sleep mode
 To leave
 Time Tstart, average power Pstart
→ E =T P + n / (R · R
tx start start ) (PtxElec + amp + amp Ptx)
code
 Simplification: Modulation not considered
27
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 · )
code
R
 Receiver electronics needs PrxElec
 Plus: energy to decode n bits EdecBits
→ Erx = T P + n / (R · R
start start ) PrxElec + EdecBits ( R )
code
28
14
Some transceiver numbers
29
Comparison: GSM base station power consumption

Heat 602W
Heat 1920W
Heat 360W
 Overview DC power TRX RF power

AC power TOC RF
3200W 2400W 480W
3802W 120W
PS -48V
ACE
TRXs
84% Combining
Central Heat 800W

CE equipm.
BTS 800W Total Heat
3682W
AC Power Rack Com-

supply cabling
 Details 300W mon
mon
220V -48V -48V
85% 99%
3802W 3200W Fans (No active cooling)
3232W cooling
2400W 500W cooling
PAs consume
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 85%
Erlang 119W Bias
into perspective) Overall efficiency

(12*10W)/3802W=3.1%
efficiency 75%
9W Combiner Diplexer
DTX activity TOC

47% 110W
PA 10W
15W
40W
30
15
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
3
1
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, …
3
2
16
Outline
33
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
→ ???
3
4
17
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
35
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
→ Interrupts/asynchronous operation has data
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
communication protocol software, etc. received
packet
36
18
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
37
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
Senso event
r
event
Idle / Radio event
Regular handler
Sensor processing
event
handler
38
19
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!
39
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
40
20
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
4
1
Outline
42
21
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)
4
3
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
 Understand and emits
TimerComponent
commands & events Event
Tasks
 Hierarchically arranged handlers
 Events pass upward from
hardware to higher-level
components
 Commands are passed setRate fire
downward
44
22
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
4
5
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
46
23
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
47
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
complex component TimerComponent
Clock
Clock
HWClock
CompleteTimer
48
24
Defining modules and components in nesC
49
Wiring components to form a configuration
50
25
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
5
1
26

Single Node Architecture: Goals of This Chapter

Uploaded by

Document Informationclick to expand document information

Copyright:

Available Formats

Single Node Architecture: Goals of This Chapter

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Single Node Architecture: Goals of This Chapter

Uploaded by

Copyright:

Available Formats

Chapter 2: Single Node

Advanced Techniques of Mobile Ad Hoc and Wireless Sensor Networks

Goals of this chapter

 Note: The details of this chapter are quite specific to WSN;

Sensor node architecture

 Essentially: a laptop-class device

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

 Research issue: Wakeup receivers – can be woken via

Example radio transceivers

 When to switch on a receiver is not clear

 Desirable: Receiver that can (only) check for incoming

 Important parameter: Area of coverage

Energy scavenging – overview

Multiple power consumption modes

 Multiple modes possible, “deeper” sleep modes

Switching between modes

Memory power consumption

 FLASH writing/erasing is expensive

 Simplification: Modulation not considered

Receiver power/energy consumption for n bits

Comparison: GSM base station power consumption

 Overview DC power TRX RF power

Central Heat 800W

AC Power Rack Com-

 (just to put things

into perspective) Overall efficiency

DTX activity TOC

 Only limited applicability of techniques analogue to DVS

Computation vs. communication energy cost

Operating system challenges in WSN

Main issue: How to support concurrency

 One option: Components

API to an event-based protocol stack

 API is therefore also event-based

Building components out of simpler ones

Wiring components to form a configuration

You might also like