Example Plot (1/2)
Number of nodes n = 10
Delay + turnaround time = 1 ms
Message transm. time T
M= 5 ms
Preamble transm. times T
P= 25, 75, and 150 ms
Time used to check for preamble T
C= 1 ms
Transmission power consumption P
TX= 9 mW
Reception power consumption P = 1.8 mW
Example Plot (2/2)
P()
Plain
CSMA
Übersicht
Beispielanwendungen
Sensorhardware und Netzarchitektur
Herausforderungen und Methoden
MAC-Layer-Fallstudie IEEE 802.15.4
Energieeffiziente MAC-Layer
S-MAC und T-MAC
B-MAC
X-MAC und Wise-MAC
WSN-Programmierung
Problem: Sources of Energy Waste
S1
S2
S3
wakeup wakeup
wakeup wakeup
t1 t2
sleep again receive packet
Packet(s1)
Preamble
1
3 2
1 2
Useless reception of remaining preamble
3
Useless overhearing of preamble
Useless transmission of remaining preamble
X-MAC: Strobe Preamble Sampling (1/2)
S1
S2
S3
wakeup
wakeup
strobe(s1)
not for me, sleep again
receive packet
Data strobe(s1) strobe(s1)
ack for me, send ack
send packet Conceptually, if |strobe(s1)| 0 and |ack| 0, this looks like …
X-MAC: Strobe Preamble Sampling (2/2)
S1
S2
S3
wakeup
wakeup
receive
Data send Strobes for s1
sleep full sleep cycle again sleep again
wakeup
t
Problem: Source of Energy Waste
S1
S2
S3
wakeup
wakeup
receive
Data send
sleep full sleep cycle again sleep again
wakeup
t Strobes for s1
Strobes immediately before time t when s1 wakes up would be sufficient. But, how to know time t ?!?
WiseMAC: Announce Wakeup Schedule
S1
S2
S3
wakeup
wakeup
receive
data
sleep again
wakeup
t2 prb
Schedule list s1 : t2 = t1 + x
…
ack
Nextwakeup in x ms
t1 t2
data
Previous transmission Next transmission
Übersicht
Beispielanwendungen
Sensorhardware und Netzarchitektur
Herausforderungen und Methoden
MAC-Layer-Fallstudie IEEE 802.15.4
Energieeffiziente MAC-Layer
WSN-Programmierung
Laufzeitumgebungen
Fallstudie 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
Processes 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, sequential processing of tasks
Not satisfactory: Risk of missing data (e.g., from transceiver) when processing data, etc.
! Interrupts/asynchronous operation has to be supported
Why concurrency is needed
Sensor node’s CPU has to service the radio modem, the actual
sensors, perform computation for application, execute communication protocol software, etc.
Poll sensor
Process sensor
data
Poll transceiver
Process received
packet
Traditional concurrency: Processes
Traditional OS:
processes/threads
Based on interrupts, context switching
But: not available – memory overhead, execution overhead
Handle sensor process
Handle packet process
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
Idle / Regular processing
Radio event
Radio event handler Sensor
event
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
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
