Signal Strength

29

Can they Survive a whole Year?

 Idea: switch off unnecessary current consumers

 Tmote sky product description

 Processor: 500 uA

 Radio TX: 17.4 mA

 Radio power down: 1 uA

while(true) {

turn on consumers;

x = read sensor;

transmit x;

turn off consumers;

await next sec;

}

Example: one 16 bit sample per second; idealized channel:

Can they Survive for many Years?

 Idea: set MCU in sleep mode

 Example: one 16 bit sample per second; idealized channel

 Transmission time = 16/(250*1024) s = 62.5 us

 Duty cycling

250 * 1024 Bit/s 16 Bit

Wakeup 62.5 us

Transmit Sleep

31

Can they Survive for many Years?

 Tmote sky product description

 Processor: 500 uA

 Processor sleep@32kHz: 2.6 uA

 Radio TX: 17.4 mA

 Radio Idle: 365 uA

 Radio power down: 1 uA

 Processor wakeup: 6 us

 Radio oscillator startup: 580 us

10^6 – (6 + 580 + 62.5) usIdle MCU6 us Radio

580 us TX

62.5 us

500 uA

+ 1 uA 500 uA + 365 uA 500 uA

+ 17.4 mA 2.6 uA + 1 uA

 Current consumption: Y = 6/10^6 * (500+1) + 580/10^6 * (500+365) +

62.5/10^6 * (500+17400) +

(10^6-6-580-62.5)/10^6 * (2.6+1)

 Y = 5.22 uA

 Lifetime: 4400 mAh / 0.00522 mA ≈ 842912 h ≈ 35121days ≈ 96years

In practice lifetime of a few years:

• More sources of power dissipation

• Synchronization of communication nodes

• Battery looses current

Übersicht

 Beispielanwendungen

 Sensor-Hardware und Netzarchitektur

 Herausforderungen und Methoden

 Limitierender Faktor Batterie

 Schlafzyklen

 In-Network-Processing

 Multihop-Kommunikation

 MAC-Layer-Fallstudie IEEE 802.15.4

 Energieeffiziente MAC-Layer

 S-MAC und T-MAC

 B-MAC

 X-MAC und Wise-MAC

 WSN-Programmierung

 Laufzeitumgebungen

 Fallstudie TinyOS

 MAC-Layer-Programmierung mit der MLA

33

Where to Process the Data?



Example determine max value



How to reduce communication load on S3?

S3 Sink: compute

max(d1,d2,d3) S1

S2

send(d1)

send(d2)

send(d3)

Data Aggregation

S3 Sink

S1

S2

send(d1)

send(d2)

compute

m = max(d1,d2,d3) send(m)

Additional: data processing in the event source

Übersicht



Beispielanwendungen



Sensor-Hardware und Netzarchitektur



Herausforderungen und Methoden



Limitierender Faktor Batterie



Schlafzyklen



In-Network-Processing



Multihop-Kommunikation



MAC-Layer-Fallstudie IEEE 802.15.4



Energieeffiziente MAC-Layer



WSN-Programmierung

35

Observation: Energy Efficiency

100 m 100 nJoule/Bit

37

Observation: Energy Efficiency

10 m 1 nJoule/Bit

…

Bluetooth Example

 100m in one hop: 100nJ/Bit

 100m in ten hops: 10nJ/Bit

Distance

Signal Strength

Broadcast Property

Sender Receiver

Übersicht



Beispielanwendungen



Sensor-Hardware und Netzarchitektur



Herausforderungen und Methoden



MAC-Layer-Fallstudie IEEE 802.15.4



Energieeffiziente MAC-Layer



WSN-Programmierung

39

Case Study: IEEE 802.15.4 (1/3)

PAN Coordinator

Guaranteed time slots (GTS) Other things

Star topology

v₁

v₂ v₃

v₄ v₅

v₁

v₄ v₅ v₂

t_s t_next

sl₂ : v₄ sl₄ : v₁ sl₅ : v₅ sl₇ : v₂

Beacon

But how will v₃ be able to send data?

not possible

41

Case Study: IEEE 802.15.4 (2/3)

PAN Coordinator

Contention Access Period (CAP) Super frame Star topology

v₁

v₂ v₃

v₄ v₅

t_next Beacon

Slotted CSMA with random backoff in CAP

v₂ GTS

needs GTS

v₃ needs GTS

(Remark: CAP can also be used to send data directly)

Case Study: IEEE 802.15.4 (3/3)

PAN Coordinator

CAP

Star topology v₁

v₂ v₃

v₄ v₅

t_next Beacon GTS And what happens here?Nothing ?!?

Active period Inactive period

Übersicht



Beispielanwendungen



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

43

Idle Listening Wastes Energy

P_sleep P_active

t P

“Traditional” MAC schemes:

P_sleep P_active

t P

An ideal power minimizing MAC scheme:

Power Consumption

Power Consumption

Power Savings

TX/RX TX/RX TX/RX

TX/RX TX/RX TX/RX

45

The S-MAC Approach (1/8)

P_sleep P_active

t P

Idea: periodic listen and sleep cycles

Power Consumption Power Savings

TX/RX TX/RX TX/RX

active sleeping …

TX/RX

_active _sleep

Power Savings:

The S-MAC Approach (2/8)

S₁

T₁

…

?

Just follow own sleep cycle? Clock drift problem!

47

The S-MAC Approach (3/8)

S₁

T₁

…



Idea: synchronizer and follower node

SYNC SYNC

The S-MAC Approach (4/8)

Multihop: (1) Who follows whom? (2) Avoid Synchronization Islands.

SYNC SYNC

s₁ s₂

49

The S-MAC Approach (5/8)

(1) Who follows whom?: Contention scheme

SYNC

s₁ s₂

The S-MAC Approach (6/8)

(2) Avoid Synchronization Islands: Follow all known synchronizers

SYNC(t₂) SYNC(t₁)

s₁ s₂

Wakeup Schedule(v)

s₁ t₁

v

51

The S-MAC Approach (7/8)

Question: How can u and v communicate? Additional Requirement?

SYNC(t₂) SYNC(t₁)

s₁ s₂

v u

The S-MAC Approach (8/8)

Solution: When becoming a follower resend SYNC once

SYNC(t₂) SYNC(t₁)

s₁ s₂

v u

Neighbor Table (v)

u t₁

Neighbor Table (u)

v t₂

… …

From S-MAC to T-MAC



Further Reducing Energy Consumption in S-

MAC: the T-MAC approach

wakeup period

Communication in S-MAC: RTS/CTS

s

f₁

f₂

f₃

data

sleep period

no data

no data

no data data for f₁

t₁ t₂ t₃

Problem: energy waste at

Contention period Contention period

55

wakeup period

Sleeping after overhearing CTS

s

f₁

f₂

f₃

data

sleep period

no data

no data

no data data for f₁

t₁ t₂ t₃

sleep

sleep

wakeup

wakeup

Problem: energy waste at

Contention period Contention period

wakeup period

Solution: Adaptive Duty Cycle of T-MAC

s

f₁

f₂

f₃

data

sleep period

no data

no data

no data data for f₁

t₁ t₂ t₃

Contention period Contention period wakeup

sleep wakeup

sleep

sleep

sleep

sleep

sleep

57

wakeup period

The Early Sleeping Problem

f₁

f₂

s

f₃

data

sleep period

t₁ t₂ t₃

Contention period Contention period sleep

sleep ???

wakeup

wakeup period

Solution: Future Request to Send

f₁

f₂

s

f₃

data

sleep period

t₁ t₂ t₃

Contention period Contention period sleep

sleep

wakeup

wakeup data

Übersicht



Beispielanwendungen



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

59

B-MAC: Preamble Sampling (1/3)

S₁

S₂

S₃

wakeup/sleep w/s



w/s

w/s w/s w/s w/s

w/s w/s w/s

61

B-MAC: Preamble Sampling (2/3)

S₁

S₂

S₃

wakeup/sleep w/s



w/s

w/s w/s w/s w/s

w/s w/s w/s

Packet for s₁ How to wake up s₁?

t₁

B-MAC: Preamble Sampling (3/3)

S₁

S₂

S₃

wakeup wakeup

wakeup wakeup

Preamble



t₁ t₂

sleep again receive packet

Packet(s₁)



notes: bmac_power_consumption.pdf 63

Question: Power over Offered Load

packet arrivals Power [mW]

one packet per packet time

CSMA + preamble sampling ???

Benefits over plain CSMA?

Example Plot (1/2)



Number of nodes n = 10



Delay + turnaround time  = 1 ms



Message transm. time T

= 5 ms



Preamble transm. times T

= 25, 75, and 150 ms



Time used to check for preamble T

= 1 ms



Transmission power consumption P

= 9 mW



Reception power consumption P = 1.8 mW

65

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

67

Problem: Sources of Energy Waste

S₁

S₂

S₃

wakeup wakeup

wakeup wakeup



t₁ t₂

sleep again receive packet

Packet(s₁)

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

S₁

S₂

S₃

wakeup

wakeup

strobe(s₁)

not for me, sleep again

receive packet

Data strobe(s₁) strobe(s₁)

ack for me, send ack

send packet Conceptually, if |strobe(s1)|  0 and |ack|  0, this looks like …

69

X-MAC: Strobe Preamble Sampling (2/2)

S₁

S₂

S₃

wakeup

wakeup

receive

Data send Strobes for s₁

sleep full sleep cycle again sleep again

wakeup



t

Problem: Source of Energy Waste

S₁

S₂

S₃

wakeup

wakeup

receive

Data send

sleep full sleep cycle again sleep again

wakeup



t Strobes for s₁

Strobes immediately before time t when s₁ wakes up would be sufficient. But, how to know time t ?!?

71

WiseMAC: Announce Wakeup Schedule

S₁

S₂

S₃

wakeup

wakeup

receive

data

sleep again

wakeup

t₂ prb

Schedule list s₁ : t₂ = t₁ + x

…

ack

Nextwakeup in x ms

t₁ t₂ 

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

73

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

75

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

77

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

79

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

Übersicht



Beispielanwendungen



Sensor-Hardware und Netzarchitektur



Herausforderungen und Methoden



MAC-Layer-Fallstudie IEEE 802.15.4



Energieeffiziente MAC-Layer



WSN-Programmierung



Laufzeitumgebungen



Fallstudie TinyOS

81

Case study embedded OS: TinyOS & nesC



TinyOS developed by UC Berkeley 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)

TinyOS components

 Components

 Frame – state information

 Tasks – normal execution program

 Command handlers

 Event handlers

 Handlers

 Form a component’s interface

 Understand and emit commands & events

 Hierarchically arranged

 Events pass upward from hardware to higher-level components

 Commands are passed downward

TimerComponent

setRate fire

init start stop fired

Event handlers Command

handlers Frame

Tasks

Concurrency



Tasks perform arbitrary, long computation



Have to be run to completion since no non- cooperative multi-tasking is implemented



No need for stack management, tasks are atomic with respect to each other



However, we need a way to handle interrupts by preemption



NesC allows the definition of functions that can run preemptively (to handle interrupts)



Typically such function must not execute an indeterminate amount of time



Only post a regular task to perform further action

83

Sync and Async

 By default functions (i.e. commands and events) are sync (e.g. can’t be preempted)

 Only functions labeled async can run preemptively Example:

async command void led0On();

 For example all interrupt handlers must be async

 Async functions can only call async commands and signal async events

 How to call a sync function from within an async one?

 post a task to call these functions

 posting a task is async; tasks themselves are always sync

 So why use tasks at all? Why not labeling everything async?

 sync functions can’t lead to race conditions

 async can lead the system into inconsistent states E.g. concurrent access to a variable

Atomic



However, concurrent access to a code fragment can be made atomic



Example:

command bool increment() { atomic {

a++;

b = a + 1;

} }



So why not sprinkling the code with atomic blocks?

 Atomic blocks have a CPU cost

 You should minimize how many atomic blocks you have

85

Split-phase programming



Handler/task characteristics and separation has consequences for 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

87

TimerComponent start stop fired

Timer init

StdCtrl

setRate fire Clock

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

 Timer

 Clock



Build configurations by wiring together corresponding

interfaces

TimerComponent Timer StdCtrl

Clock HWClock Clock

Timer StdCtrl

Building components out of simpler ones



Wire together components to

form more complex components out of simpler ones



New interfaces for the complex

component

89

Defining modules and components in nesC

Wiring components to form a configuration

StdCtrl;

91

A TinyOS Demonstration (1/2)



Some supported methods (Windows & Linux)

 Manually (Windows: cygwin & RPM, Linux: RPM)

 Virtual machine image (VMWare, VirtualBox)



Example: starting the Xubuntos 2.1 VMWare image

 Plug in Sensor node first!

 Start XubunTOS image

 Login: user = xubuntos, password = tinyos

 y $ z! setxkbmap de

 VMPlayerVMRemovable DevicesUSB Devices:

Future Technology Devices USB device (Port 1)

A TinyOS Demonstration (2/2)



“Hello World”



Call motelist



Call cd /opt/tinyos-2.1-0/apps/Blink



Call make telosb install



Look at BlinkAppC.nc and BlinkC.nc



“The” resource: www.tinyos.net !!!



Demo:

Start Xubuntos

Plug in USB device

Zusammenfassung und Literatur



Beispielanwendungen



Sensor-Hardware und Netzarchitektur



Herausforderungen und Methoden



MAC-Layer-Fallstudie IEEE 802.15.4



Energieeffiziente MAC-Layer



WSN-Programmierung

93

Zusammenfassung

 Herausforderungen

 Energieeffizienz

 Geringe Rechen- und Speicherkapazität

 Geringe Kommunikationsbandbreite

 Erfordert neue Ansätze auf den einzelnen Protokollschichten: z.B.

energieeffiziente MAC-Layer

 Aufweichen von striktem Protokoll-Layering: „Cross-Layer- Optimierungen“

 Geräte sind in der Regel keiner Person direkt zugeordnet

 Neue Sichtweise auf Kommunikation

 ID-Zentrisch versus Datenzentrisch

 Maschine-zu-Maschine-Kommunikation

95

Literatur

 Holger Karl and Andreas Willig, „Protocols and Architectures for Wireless Sensor Networks”, John Wiley & Sons, 2005.

 Jason Hill, Robert Szewczyk, Alec Woo, Seth Hollar, David E.

Culler and Kristofer S. J. Pister, “System Architecture Directions for Networked Sensors”, Proceedings of the 9th International ACM Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS), 2000.

 Philip Buonadonna, Jason Hill and David Culler, “Active Message Communication for Tiny Networked Sensors”, Proceedings of the 20th Annual Joint Conference of the IEEE Computer and

Communications Societies (INFOCOM), 2001.

 David Gay, Philip Levis, Robert von Behren, Matt Welsh, Eric

Brewer and David Culler, “The nesC language: A holistic approach to networked embedded systems”, Proceedings of the ACM

Conference on Programming Language Design and Implementation (PLDI), 2003.