Single node architecture

Dr. Rahim Khan

Assistant Professor
Department of Comptuer Science
Abdul Wali Khan University Mardan
Outline
· Sensor node architecture
· Energy supply and consumption
· Runtime environments for sensor nodes
· Case study: TinyOS
Wireless Sensor Networks
· Group of sensor nodes
· Organize themselves to form a network
· Collaboratively detect physical environment/phenomena
· Report to destination (Gateway)
· Via Wireless Transmission
· Sensor nodes are
· Low power
· Low cost
· Limited resources
Typical WSNs Scenario
WSN for Agriculture
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
 Wasp-mote agriculture board

Temperature and
Humidity Sensor
Soil
Moisture
Sensor

Soil
Temperature
Sensor
Leaf
Wetness
Sensor
Libelium. (Wireless Sensor Networks - ZigBee - Mesh Networks - Bluetooth. [Online].
ttp://www.libelium.com/support/waspmote
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

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
Transceiver characteristics
· Radio
Capabilities
performance
· Interface:
Modulation?bit,(ASK,
byte, packet
FSK, …?)level?
· Noise
Supported
figure?
frequency
NF = SNRrange?
I/SNRO

· Gain?· Typically,
Ratio ofsomewhere in 433
output signal MHz to
power – 2.4 GHz, ISM band
input(signal amplification)
·· Multiple channels?
Out of band emissions
·· Data rates?
Carrier sensing & RSSI characteristics
·· Range?
Frequency(power, antenna,
stability environment,
(e.g., towards carrier changes)
temperature frequency and modulation)
· Energy characteristics
· Voltage range
· Power consumption to send/receive data?
· Time and energy consumption to change between different states?
· Transmission power control?
· Power efficiency? (ratio of out signal power to the overall power consumed by
amplifier)
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!)
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
· ASK or FSK modulation
power
· RSSI, highly efficient power
· Maximum power about 1.4 mW
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
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
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
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?
Outline
· Sensor node architecture
· Energy supply and consumption
· Runtime environments for sensor nodes
· Case study: TinyOS
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)
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 sleep/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
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
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
(exercise) t1 tevent time
tdown tup
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
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, …
Outline
· Sensor node architecture
· Energy supply and consumption
· Runtime environments for sensor nodes
· Case study: TinyOS
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

! ???
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
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
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
· Only one application anyway OS-mediated
process switching
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
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!
Outline
· Sensor node architecture
· Energy supply and consumption
· Runtime environments for sensor nodes
· Case study: TinyOS
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)
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