04 sensornetze.ppt [kompatibilitätsmodus]unikorn/lehre/drako/ws12/04 sensornetze.pdf · 76.8 153.6...

Drahtlose Kommunikation

Sensornetze

Übersicht Beispielanwendungen Sensorhardware und Netzarchitektur Herausforderungen und Methoden MAC-Layer-Fallstudie IEEE 802.15.4 Energieeffiziente MAC-Layer WSN-Programmierung

2

3

Environmental Monitoring

Example: Great Duck Island, Berkeley, Culler et al.

4

Precision Agriculture Example: LOFAR project

Fighting Phytophtora using micro-climate Temperature and relative humidity

5

Forest-Fire Detection

6

Exploration of Unknown Territory

Example: CotsBots, Berkeley, Pister et al.

7

Traffic Telematics

Image source: www.whnet.com/4x4/telematics.html

8

More ScenariosBuilding Automation

Home Automation

Industrial Automation

Logistics


9

10

Sensor Node Hierarchy

11

Components of a Sensor Node

Power unit

Sensor ADCProcessorStorage

Transceiverunit

Location finding system Mobilizer

Sensing unitProcessing

unit

Powergenerator

12

Example: Tmote Sky Sensor Module

13

Example: Tmote Sky Sensor Module

14

But there are much more … BEAN BTnode COTS Dot Ember Eyes FireFly Fleck IMote Imote2 KMote Mica Mica2 Mica2Dot MicaZ Mulle Nymph

Particles Rene ScatterWeb Sensinode SHIMMER SquidBee SunSPOT Telos TinyNode 584 T-Mote Sky T-Nodes WeBee weC XYZ WINS WiseNet …

15

Example Generic Sensor Hardware

BTNode

Mica2

Mica2Dot

Tmote Sky

ImoteSource: http://www.btnode.ethz.ch/Projects/SensorNetworkMuseum

Serial attached Flash in kB

Internal RAM in kB

Flash RAM in kB

16

Example Sensor Network TransceiversCC1000 CC1021 CC2420 TR1000 XE1205

Bit Rate[kbps]

76.8 153.6 250 115.2 1.2 - 152.3

Sleep Mode[uA]

0.2 - 1 (osc. core off)

1.8 (core off) 1 0.7 0.2

RX [mA] 9.3 (433MHz) / 11.8 (868MHz)

19.9 19.7 3.8 (115.2kbps)

14

TX Min [mA] 8.6 (-20dBm) 14.5 (-20dBm)

8.5 (-25dBm) 33 (+5dBm)

TX Max [mA] 25.4 (+5dBm)

25.1 (+5dBm)

17.4 (0dBm) 12 (+1.5dBm)

62 (+15dBm)

Source: http://www.btnode.ethz.ch/Projects/SensorNetworkMuseum

17

How much is 250 kbps? 250 kbit transmit bit rate can serve

Two 128 kbit 320 x 240 thumbnail video streams Four 64 kBit digital high quality audio streams 250 * 1000 / 8 32000 8 bit samples per second

Can we use 250 kbps? Error correcting codes Retransmissions Shared media

SA

B

A B S

Parallel stream transmissions

Serial stream transmission

18

Network Architecture

B

CAD

Sink

Sensor Field

Sensor Nodes

Internet andsatellite

Task managernode

User

19

Deployment options for WSN Dropped from aircraft ! Random deployment

Usually uniform random distribution for nodes over finite area is assumed

Well planned, fixed ! Regular deployment E.g., in preventive maintenance or similar Not necessarily geometric structure, but that is often a

convenient assumption

Mobile sensor nodes Can move to compensate for deployment shortcomings Can be passively moved around by some external force

(wind, water) Can actively seek out “interesting” areas

Übersicht Beispielanwendungen Sensorhardware 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

20

21

Limiting Factor: Battery Capacity

22

Batteries: Joule and Ah (1/2)1 Ah means one can draw current of 1A for 1 hourLifetime of 2000 mAh Battery under 1 A current consumption?

1 Joule means the amount of energy stored in a batteryLifetime of Battery storing 7.2 kJ Energy used to run a 1 W electricity?

23

Batteries: Joule and Ah (2/2)Lifetime of a 2000 mAh 1.5V battery used to run a 2 W electricity

24

Battery examples

Non-RechargeableChemistry Zinc-air Lithium AlkalineEnergy (J/cm3)

3780 2880 1200

RechargeableChemistry Lithium NiMHd NiCdEnergy (J/cm3)

1080 860 650

And how fast?How many apples?

Übersicht Beispielanwendungen Sensorhardware und Netzarchitektur Herausforderungen und Methoden



25

26

How long do they last?

Tmote sky product description Processor: 500 uA Radio TX: 17.4 mA

Standard AA Alkaline Battery Single battery: 2200 mAh

Tmote battery pack: 2 Batteries

Sensor GatewayConstant data stream

while(true) {

x = read sensor;

transmit x;

}

Sensor node’s lifetime L:

27

How to extend the lifetime?

Idea: sample periodically Tmote sky product description Processor: 500 uA Radio TX: 17.4 mA Radio on: 365 uA

250 * 1024 Bits per second16 BitsSensor Gateway

while(true) {

x = read sensor;

transmit x;

await next sec;

}

Lifetime L for one 16 bit sample per second; idealized channel:

28

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

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:

30

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/s16 Bit

Wakeup 62.5 usTransmit 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

Idle10^6 – (6 + 580 + 62.5) us

MCU6 us

Radio580 us

TX62.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


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

32

33

Where to Process the Data? Example determine max value

How to reduce communication load on S3?

S3Sink: computemax(d1,d2,d3)

S1

S2

send(d1)

send(d2)

send(d3)

34

Data Aggregation

S3 Sink

S1

S2

send(d1)

send(d2)

computem = max(d1,d2,d3)

send(m)

Additional: data processing in the event source

Übersicht Beispielanwendungen Sensor-Hardware und Netzarchitektur Herausforderungen und Methoden



35

36

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

Sign

al S

tren

gth

38

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

40

Case Study: IEEE 802.15.4 (1/3)

PAN Coordinator

Guaranteed time slots (GTS)

Super frame

Other things

Star topology

v1

v2 v3

v4

v5

v1v4 v5 v2

ts tnext

sl2 : v4

sl4 : v1

sl5 : v5

sl7 : v2

Beacon

But how will v3 beable to send data?

not possible

41


PAN Coordinator

Contention Access Period (CAP)

Super frame

Star topology

v1

v2 v3

v4

v5

tnext

Beacon

Slotted CSMAwith randombackoff in CAP

GTSv2needsGTS

v3needsGTS

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

42


PAN Coordinator

CAP

Super frame

Star topology

v1

v2 v3

v4

v5

tnext

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


WSN-Programmierung

43

44

Idle Listening Wastes Energy

Psleep

Pactive

t

P“Traditional” MAC schemes:

Psleep

Pactive

t

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

Psleep

Pactive

t

PIdea: periodic listen and sleep cycles

Power Consumption Power Savings

TX/RX TX/RX TX/RX

active sleeping …

TX/RX

active sleep

Power Savings:

46


S1

T1

…

?

Just follow own sleep cycle? Clock drift problem!

47


S1

T1

…

Idea: synchronizer and follower node

SYNC SYNC

48

The S-MAC Approach (4/8)Multihop: (1) Who follows whom? (2) Avoid Synchronization Islands.

SYNCSYNC

s1 s2

49

The S-MAC Approach (5/8)(1) Who follows whom?: Contention scheme

SYNC

s1 s2

50

The S-MAC Approach (6/8)(2) Avoid Synchronization Islands: Follow all known synchronizers

SYNC(t2)SYNC(t1)

s1 s2

Wakeup Schedule(v)s1 t1

s2 t2

v

51

The S-MAC Approach (7/8)Question: How can u and v communicate? Additional Requirement?

SYNC(t2)SYNC(t1)

s1 s2

v

u

52

The S-MAC Approach (8/8)Solution: When becoming a follower resend SYNC once

SYNC(t2)SYNC(t1)

s1 s2

v

u

Neighbor Table (v)u t1

… …

Neighbor Table (u)v t2

… …

From S-MAC to T-MAC Further Reducing Energy Consumption in S-

MAC: the T-MAC approach

54

wakeup period

Communication in S-MAC: RTS/CTS

s

f1

f2

f3

data

sleep period

no data

no data

no data

data for f1

t1 t3t2

Problem: energy waste at Contention period Contention period

55

wakeup period

Sleeping after overhearing CTS

s

f1

f2

f3

data

sleep period

no data

no data

no data

data for f1

t1 t3t2

sleep

sleep

wakeup

wakeup

Problem: energy waste at Contention period Contention period

56

wakeup period

Solution: Adaptive Duty Cycle of T-MAC

s

f1

f2

f3

data

sleep period

no data

no data

no data

data for f1

t1 t3t2Contention period Contention period

wakeup

sleep wakeup

sleep

sleep

sleep

sleep

sleep

No activity in contention period ! sleep again Does this always work?

57

wakeup period

The Early Sleeping Problem

f1

f2

s

f3

data

sleep period


sleep

sleep ???

wakeup

58

wakeup period

Solution: Future Request to Send

f1

f2

s

f3

data

sleep 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


WSN-Programmierung

59

60

B-MAC: Preamble Sampling (1/3)

S1

S2

S3

wakeup/sleep w/s

w/s

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

w/s w/s w/s

61


S1

S2

S3

wakeup/sleep w/s

w/s

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

w/s w/s w/s

Packet for s1How to wake up s1?

t1

62


S1

S2

S3

wakeup wakeup

wakeupwakeup

Preamble

t1 t2

sleep again

receive packet

Packet(s1)

63notes: bmac_power_consumption.pdf

Question: Power over Offered Load

packetarrivals

Power [mW]

one packetper packettime

CSMA + preamble sampling ???

Benefits over plain CSMA?

64

Example Plot (1/2) Number of nodes n = 10

Delay + turnaround time = 1 ms

Message transm. time TM = 5 ms

Preamble transm. times TP = 25, 75, and 150 ms

Time used to check for preamble TC = 1 ms

Transmission power consumption PTX = 9 mW

Reception power consumption PRX = 1.8 mW

65

Example Plot (2/2)

P()

PlainCSMA

Übersicht Beispielanwendungen Sensorhardware und Netzarchitektur Herausforderungen und Methoden MAC-Layer-Fallstudie IEEE 802.15.4 Energieeffiziente MAC-Layer


WSN-Programmierung

66

67

Problem: Sources of Energy Waste

S1

S2

S3

wakeup wakeup

wakeupwakeup

t1 t2

sleep again

receive packet

Packet(s1)

Preamble

1

3

2

1

2Useless reception of remaining preamble

3Useless overhearing of preambleUseless transmission of remaining preamble

68

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

S1

S2

S3

wakeup

wakeup

strobe(s1)

not for me,sleep again

receive packet

Datastrobe(s1) strobe(s1)

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)

S1

S2

S3

wakeup

wakeup

receive

Data

send

Strobes for s1

sleep full sleep cycle again

sleep again

wakeup

t

70

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 wakesup would be sufficient. But, how to know time t ?!?

71

WiseMAC: Announce Wakeup Schedule

S1

S2

S3

wakeup

wakeup

receive

data

sleep again

wakeup

t2

prb

Schedule lists1 : t2 = t1 + x…

ack

Nextwakeupin x ms

t1 t2

data

Previous transmission Next transmission


Laufzeitumgebungen Fallstudie TinyOS

72

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

! ???

74

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

76

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-mediatedprocess 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 / Regularprocessing

Radioevent

Radioevent handler

Sensorevent

Sensor eventhandler

78

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

80

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)

82

TinyOS components Components

Frame – state information Tasks – normal execution

program Command handlers Event handlers

Handlers Must run to completion Form a component’s

interface Understand and emits

commands & events Hierarchically arranged

Events pass upward from hardware to higher-level components

Commands are passed downward

TimerComponent

setRate fire

init start stop fired

Eventhandlers

Commandhandlers Frame

Tasks

83

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

84

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 Buffers can only be freed when completion event is received

85

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

86CompleteTimer

TimerComponent

TimerStdCtrl

Clock

HWClock

Clock

TimerStdCtrl

Building components out of simpler ones

Wire together components to form more complex components out of simpler ones

New interfaces for the complex component

87

Defining modules and components in nesC

88

Wiring components to form a configuration

StdCtrl;

89

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 VMPlayerVMRemovable DevicesUSB Devices:

Future Technology Devices USB device (Port 1)

90

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 XubuntosPlug 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

91

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

92

93

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.

04 sensornetze.ppt [kompatibilitätsmodus]unikorn/lehre/drako/ws12/04 sensornetze.pdf · 76.8 153.6...

Documents