chapter05 sensor networks

Chapter05 Sensor Networks

8/30/2002 CS537S Sensor Networks 2

5.1 Introduction

• What are sensor networks?

• “Challenge of the century”

• New paradigm for distributed computing!

• Class– Student responsibilities– Vote for times: make-up; final presentation


What are they?• Smart sensor = Micro-sensors + on-board processing +

low-power wireless interfaces – All feasible at very small scale

• Berkeley Smart Dust


Mica Mote• Two Board Sandwich

– CPU/Radio board– Sensor Board

• Size– Mote: 11 in– Pocket PC: 5.23.1 in

• CPU– Mote: 4 MHz, 8 bit– Pocket PC: 133 MHz, 32 bit

• Memory– Mote: 4KB SRAM– Pocket PC: 32 MB RAM

• Radio– Mote: 50 kbps– Bluetooth: 433.8 kbps; Wireless LAN: 10 Mbps


Applications• Smart sensors

massively distributed in environments for sensing and control

• Enable spatially and temporally dense environmental monitoring

• Embedded Networked Sensing will reveal previously unobservable phenomena

Seismic Structure response

Contaminant Transport

Marine Microorganisms

Ecosystems, Biocomplexity

Modified from Deborah Estrin, SIGMETRICS keynote,http://lecs.cs.ucla.edu/~estrin/talks/Sigmetrics-June02.ppt

http://lecs.cs.ucla.edu/~estrin/talks/Sigmetrics-June02.ppt


Acoustic Tracking

Berkeley moteModified from Lui Sha et. al.,,MURI presentation

http://www.kawartha.net/~jleonard/tank.JPG



Large Scale

• Number of nodes• Diameter of networks• Density

> 10 nodes/R

Diameter: 100*R100K nodesRadio radius R 30 m

Surveillance over 9 km2


Severe Resource Constraints

• Bandwidth, CPU, memory, and storage• Energy

– Batteries, solar cells– Long life time

• Bird habitat monitoring: 9 months• Bridges: years

• Need power management!


Unpredictability

• Wireless– Environmental noises– Terrain– High fault rates– Unknown and changing

topologies

169 motes, 13x13 grid, 2 ft spacing, open area, RFM radio, simple CSMA

Probability of receiving packets vs. distance

Deborah Estrin, SIGMETRICS keynote,http://lecs.cs.ucla.edu/~estrin/talks/Sigmetrics-June02.ppt

http://lecs.cs.ucla.edu/~estrin/talks/Sigmetrics-June02.ppt


Unpredictability

Berkeley mote

When/where/how-many targetsMobile targetsSensors leave/join/move




Real-Time Requirements

Timing constraints: locate/report targets within 30 sec Berkeley mote




Security

• Physically exposed to potential hackers• Wireless communication• Resource-constrained


Sensor network is the

“challenge of the century”!


Aggregate performance >>> individual node

Berkeley mote

“Where are the targets in the south?” vs.

“What is the sound reading of sensor 191.12.1.0?”




New Computing Paradigms

• Aggregate performance >>> individual node– Location-based queries– Nodes w/o global ID– Group coordination … …

• Goal: reliable aggregate services on top of thousands of unreliable nodes


Data-Centric Communication

• Maximize information about physical events– NOT raw data throughput (as in traditional networks)– High redundancy in raw data– In-network data aggregation instead of sending

everything to base stations


Acoustic Tracking

Berkeley mote

“Where are the targets in the south?” vs.

“What is the sound reading of sensor 191.12.1.0?”

In-network aggregation

send positions (not

individual sound)




Decentralized Control

• Self-adaptation to handle unpredictabilities– Routing: avoid hot spots– Power management: optimal topology and lifetime– data caching/placement– Fault-tolerance

• Scalability: cannot depend on global information• Decentralized control

– Only depend on neighborhood information– Need to guarantee aggregate stability!

5.2 MAC


MAC

TDMA (bluetooth)• Energy-efficient

– Less contention– Allow nodes to sleep in

others’ slots

• Less efficient in dynamic, multihop networks– Centralized coordinator– Schedule broadcasting

among nodes

CSMA• Less energy efficient

– More contention, esp. in heavy load

• Robust in dynamic networks– Naturally decentralized– Less synchronization

needed


Characteristics

Wireless LAN• Packet size: 512 B• Symmetric• Power: not a concern• Single hop: only

between base station and nodes

• Random traffic

Sensor Net• Packet size: 30 B• Asymmetric• Power: dominant issue• Multi-hop: “reversed

multi-cast” topology• Synchronized periodic

traffic


More Assumptions

• All traffic from nodes to base stations– No inter-sensor communication (aggregation)

• All streams are equally important• No QoS (latency, rate) requirement

– Rate can be regulated arbitrarily

Symmetric links


Goals

MACAW/802.11• Single-hop fairness: even

distribution of bandwidth• Maximize single-cell

throughput

Berkeley MAC• Multi-hop fairness: avoid

starving far-away sensors• Maximize yield: multi-hop

throughput per energy


ApproachesMACAW/802.11• Single-hop fairness

– Separate backoff counter per receiver

– Overhearing: Copy backoff counters through overhearing

• Maximize throughput– Based on CSMA/CA– Sync packet transmission

by adding overhead packets

Berkeley MAC• Multi-hop fairness

– Adaptive rate control on originated and route-thru traffic

– Give preference to route-thru traffic

• Maximize Yield– Based on CSMA/CA– Remove overhead packets– Desynchronize periodic

traffic via phase shifting– Less overhearing: Sleep

during backoff


802.11: CSMA/CA Collision detection

Virtual collision Hardware-sensed collision

Collision Avoidance (CA) Channel idle wait for rand()A

Contention Collision (No CTS or No ACK) backoff-time = rand()2kS

Idle

Timerand()A

ContentionExponential Backoff

TransmissionAvoidance

rand()[2kS]*

AcquireChannel


Problems

Cannot handle synchrony Repeat collision between synchronous traffic Slightly early stream captures channel

Active listening during backoff


Break Synchrony

Repeat collision between synchronous traffic Slightly early stream captures channel

Break the synchrony: Random delay before listening: similar to CA Phase shift at source sensor

The phase of sensor’s sampling interval is shifted by a random amount in response to transmission failure

Lead to “aperiodic” sensing


802.11/DCF: RTS/CTS/DATA/ACK

• Problem: Cost of overhead packets when data are small– Control packet: 3 B, data packet: 30 B 30% overhead– Every control packet needs CSMA/CA

A B C DRTSRTS

A B C DCTS

CTS defer send

CTS

A B C D

RTS, !CTSOK to send DATA

A B C DACK


The Inherent Hidden Terminal

The “unsolvable” by MACAW is common between a node (A) and its grandparent (C)

B DCDATA

ARTS

Don’t know about CD

To Base Station


Remove RTS/CTS/ACK (1)

Take advantage of multi-hop pipeline overhead-free collision avoidance bw. grandparents and grandsons A overhears B transmit at t C will transmit at t+ProcTime A avoids transmitting until t+ProcTime+TxTime

But, A is overhearing (possibly in backoff) …

B DCDATA

ADATA To Base StationDATA

t t+ProcTime+TxTime

t-ProcTime-TxTime


Remove RTS/CTS/ACK (2)

• Remove ACK Overhear parent relay your packet implicit ACK – But, depend on symmetry– But, A is overhearing (possibly in backoff) …

• Collision reduced by Phase offset Random delay before listen Adaptive Rate Control

B DCDATA

ADATA To Base StationDATA


Adaptive Rate Control

• Goals– Achieve multi-hop fairness: sensor net cannot scale if no remote

sensors can report data to base station!– Avoid overload link toward base station

• Rationale– Rate should be throttled when transmission fails to avoid

overloading link and excessive collisions– Separate rate control applies to the packets originated from

sensor itself and route-thru packets– Route-thru traffic should be given preference because they

already consumed more bandwidth


Adaptive Rate Control (ARC)

• Given demanded rate S, the actual transmission rate is S*p (0 < p < 1)

• Linear increase, multiplicative decrease– Successful transmission p = p + – Failed transmission p = p*β (0 < β < 1) : reward for successful transmission– β: penalty for failure

• Tuning , β always a headache …


Balance Originated and Route-thru traffic

• Route-thru traffic given preference because – dropping them lead to more wasted bandwidth– traffic from far-away more vulnerable to dropping

• Hence, – Route-thru has less penalty: βroute = 1.5βorigin

– Route-thru increase faster: route = (n+1)origin where n is the number of children sending traffic

• n really should be the number of sending descendants

– More tuning to do …


Evaluation Setup

• Error-free simulation and rene-mote implementation Implementation: always

listening when not sending

• Single-cell and multi-hop


Key Evaluation Results: Single Hop

• CSMA– Random delay before listening key to robustness– Backoff mechanism is irrelevant random backoff is

sufficient– Sleep during backoff key to energy saving

• Single-hop fairness– 802.11: slightly early sender capture whole channel– Application-level phase shifting significantly improve

single-hop fairness


Key Evaluation Results: Multi Hop

• Multi-hop fairness: data delivered to base station– CSMA:

• remote sensors starve• sensors close to base station dominate

– ARC• remote sensors not starved• fairer, but not entirely• improved yield for remote sensors, but still not as high as

close sensors


Critiques Break synchrony among traffic

Random delay before listening: similar to CA Phase shift at source sensor

Remove RTS/CTS/ACK by taking advantage of multi-hop pipelining Collision avoidance bw. grandparents and grandsons

through overhearing Implicit ACK by overhearing parent Depends on overhearing Heavily depend on symmetric links


More Critiques Adaptive Rate Control

Rate throttled when transmission fails to avoid overloading link Separate rate control applies to the packets originated from

sensor itself and route-thru packets Route-thru traffic given preference to improve fairness Localized algorithm Difficult tuning Assume No inter-sensor communication (aggregation) All streams are equally important No QoS (latency, rate) requirement

Rate can be regulated arbitrarily


An Energy-Efficient MAC Protocol for Wireless Sensor Networks


Outline

• What is S-MAC ?• Requirements (Specific to Sensor Networks)• Goals of S-MAC • Techniques & Implementation• Experiments• Limitations• Future Plans


S-MAC

• A MAC (Medium Access Control) protocol for wireless sensor networks

• Different from traditional wireless MACs (e.g. IEEE 802.11)• Energy conservation and self configuration of primary

importance• Inspired by PAMAS (based on MACA but uses a separate

signalling channel), but uses in-channel signalling

• Applies message passing for applications requiring data store & forward


Requirements

• Energy Efficiency - reduced power consumption for prolonged life of the nodes (Battery-powered nodes energy efficiency )

• Scalability - to easily accommodate network changes ( changes in network size, node density and topology) self-organization)

• Collision Avoidance• Throughput• Bandwidth utilization• Latency • Fairness


Assumptions

• Most of the communication between peers and not with the base station

• Requirement for self configuration • Sensor networks are dedicated to a single application

or a few collaborative applications• Applications have long idle periods and can tolerate

some latency• Requirement for in-network data processing


S-MAC Goals

• Primary - Achieve energy efficiency • Bonus - capable of good scalability and collision

avoidance• Secondary - Throughput and bandwidth

utilization• Cost - may lead to reduced per-hop fairness and

latency


Sources of Energy Waste

• Collision - due to follow-on transmissions on collisions• Overhearing - node picks up packets meant for another

destination• Control Packet Overhead

• Idle listening - listening to receive possible traffic that is not sent (consumes 50%- 100% of energy spent for receiving)

Dominant in sensor nets


Minimize Energy Waste -Ways and Means

• Avoid collisions - uses CSMA/CA (basic 802.11)

• Avoid overhearing - puts a node to sleep when the neighbouring nodes are transmitting

• Control overhead - Applies message passing• Avoid idle listening - periodic listen and sleep


Periodic Sleep and Listen

• Every node sleeps periodically (radio switch-off)• Sets a timer to awake itself after the designated sleep

time• Sleep time can be application specific • Periodic sleep time same for all the nodes• Latency increased - latency requirement places a

limit on the sleep time of the nodes

Listen ListenSleep Sleep


Periodic Sleep and Listen

• Nodes free to choose listen/sleep schedules • Neighbouring nodes preferred to have same

schedules• Nodes exchange their schedules by broadcasting

them to their immediate neighbours• Nodes maintain a schedule table to store the

schedules of their neighbours

B C DA

Schedule 1 Schedule 2


Periodic Sleep and Listen - contd.

• Choosing Schedules– Node listens for a certain amount of time. If it does not receive

any other schedule, randomly chooses a sleep time, broadcasts it in a SYNC message - synchronizer

– If a node receives a schedule, it sets it schedule to be the same and broadcasts that in a SYNC message - follower

– If a node receives a schedule after it has broadcasted its schedule, it adopts this second schedule too and wakes up at both the schedules.sleep after t secs sleep after (t - td)secs

A B

Sync Sync

C

Node Sleep time Synchronization


Periodic Sleep and Listen - contd.

• Cases of bordering nodes between schedules• Bordering nodes may follow multiple schedules• Consume higher energy due to higher awake time

Border nodes: two schedules broadcast twiceSchedule 2

Schedule 1


Periodic sleep and listen - contd.

Schedule Synchronization• Remember neighbours’ schedules • Each node broadcasts its schedule every few

periods of sleeping and listening • Uses a SYNC packet which has the address and

the time of it’s next sleep• Re-sync when receiving a schedule update• Schedule packets also serve as beacons for new

nodes to join a neighborhood


• Listen period divided into two parts to receive SYNC and Data packets

• Each slot further divided for CS

Periodic sleep and listen - contd.

Receiver

For SYNC For RTS

Listen

Sleep

Sender

CS CS

SYNC RTS

Send Data if RTS is Received ..


Collision Avoidance

• Multiple senders want to talk• Options - Contention vs. TDMA• Solution: Similar to IEEE 802.11 ad hoc mode

– Virtual Carrier Sense : A node records the value of the transmission period from each transmitted packet into a NAV (Network Allocation Vector) and sets a timer for it. Every time the timer fires, the NAV is decremented and data can be transmitted only when NAV = 0

– Physical carrier sense : When the receiver starts listening, the sender starts carrier sense and randomly selects a time slot to finish carrier sense. If no transmission is detected in that period, it gets the medium to start the transmission


Collision Avoidance - contd.

– Randomized backoff time– RTS/CTS for hidden terminal problem

– RTS/CTS/DATA/ACK sequence

Node BNode A Node C

RTSCTS CTS


Overhearing Avoidance

• Overhearing - Receive packets destined to others• Sleep when neighbors talk/transmit data• All immediate neighbors of sender and receiver should

sleep

• The duration field in each packet informs other nodes the sleep interval

A B DCE F


Message Passing

• Sensor net in-network processing requires entire message

• One long message - higher cost ofor re-transmitting on corruption

• Fragmented message - higher control overhead due to RTS and CTS for each packet and longer delay too

• S-MAC approach


Message Passing

• Different messages are not interleaved– Long message is fragmented & sent in burst– RTS/CTS reserve medium for entire message– Fragment-level error recovery — ACK

— extend Tx time and re-transmit immediately — also meant to avoid the hidden terminal problem

• Other nodes sleep for whole message time• Each data and ACK packet has duration field in it• Stresses on application level fairness and lesser latency for entire

message• No limit on extensions on failure - What if the node is dead ?


Message Passing• Medium Reservation

F1 | F2 | F3 | …………..|FnMessage

A BC

F1

My address Reserved Time = t(f2+f3+…fn) + t_ack(f1+f2+…fn)+t_ack

Listens & sleeps for the reserved Time

D

Ack

Wakes up, gets the time

reservation and goes back to sleep

Hidden Terminal


S-MAC Vs 802.11 Fragmentation

IEEE 802.11 Fragmentation

– RTS and CTS reserve the medium only for one data fragment and ACK

– Neighbouring nodes’ transmission period awareness limited to one data transmission period

– If ACK not received, needs to re-contend for the medium

– Promotes per-node fairness

S-MAC Fragmentation

– RTS and CTS reserve the medium for entire msg duration + Acks

– Neighbouring nodes’ transmission period awareness extended to one message transmission period

– If ACK not received, extends Tx time and re-transmits

– Promotes per-message fairness


Implementation on Testbed Nodes

• Platform• Motes (UC Berkeley)

• 8-bit CPU at 4MHz,• 8KB flash, 512B RAM• 916MHz radio

• TinyOS: event-driven


Implementation on Testbed Nodes

• Compared MAC modules• IEEE 802.11-like protocol w/o sleeping - radio is

either in listen/receive mode or transmit mode• Message passing with overhearing avoidance - does

not include periodic listen and sleep mode• S-MAC (2 + periodic listen/sleep)


Experiments

• Topology and measured energy consumption on source nodes• Each source node sends 10 messages each in 10 fragments• Messages sent at varying time-interval• Energy consumed

= Ttransmit* Powertransmit+ Treceive* Powerreceive+Tlisten* Powerlisten

Source 1

Source 2

Sink 1

Sink 2

A

B

C

E

D


Experiments

Results for energy consumption


Experiments

0 2 4 6 8 10

200

400

600

800

1000

1200

1400

1600

1800Average energy consumption in the source nodes

Message inter-arrival period (second)

Ene

rgy

cons

umpt

ion

(mJ)

802.11-like protocol Overhearing avoidanceS-MAC


Experiments - contd.

• Overhearing avoidance sleep mode time reduces as the inter arrival period of the messages increases

• S-MAC tries to maintain the sleep mode time

Percentage Sleep Time


Experiments - contd.

Measured Energy consumption in the intermediate node

• In heavy traffic S-MAC seems to consume more power than 802.11 due to overhead of SYNC transmissions/receptions

• Also it introduces more latency and uses more time to pass the same amount of data


Conclusions

• S-MAC offers significant energy efficiency over always-listening MAC protocols

• The periodic sleep/listen scheme does not benefit for heavy loads

• Reduced duty cycle

FairnessEnergy

Msg-level latency

Packet Level

LatencyEnergy


Future Plans

• Measurement of throughput and latency• Experiments on large testbeds with differing

system complexity• ~100 Motes, ~30 embedded PCs w/ MoteNIC


URLs of Interest

• S-MAC: http://www.isi.edu/scadds/• PAMAS

-http://citeseer.nj.nec.com/cache/papers/cs/23136/http:zSzzSzpacman.usc.eduzSzpamas.pdf/pamas-power-aware-multi.pdf

5.3 Location

5.3.1 Static Location Services


What is location data?• It can be divided into three basic

categories:• Absolute Physical (20”N by 15”W) -

technically a special case of relative physical (relative to the earth)

• Relative Physical (50m north of cupples II)• (3D vs. 2D)• Symbolic (in the basement)


Which types are useful for sensor nets?

• Relative Physical is the most useful (all sensors relative to a fixed point, or all sensor relative to their neighbors), and is assumed by practically all sensor-nets apps, and many protocols

• Symbolic can be useful for data-centric communication, and context-dependent behavior: e.g., “Give me acoustic reading for all nodes in bird’s nests”

• Absolute Physical is useful as a special case of Relative Physical, for the same purpose(s)


Where does location data come from in sensor nets?

• Any of the types can be hard-wired (e.g., Great Duck island)

• Specialized hardware (e.g., GPS) can provide absolute/relative physical

• Interactions between nodes can provide relative physical (e.g., “Organizing a Global Coordinate System from Local Information on an Amorphous Computer”) and symbolic (who are neighbors?)

• Visual/Aural/etc.. sensor readings can provide relative physical and/or symbolic (e.g., “I hear running water, so I must be near a lake”)


Which are practical?

Hard-coding is impractical for most apps

Specialized hardware is too expensive/big/power-hungry, or limited to rigid architectures: super-motes/base stations can solve this to some extent

Neighbor-based algorithms are feasible...

Vision/sound are computationally expensive and inaccurate in most cases (although they may be useful in application-specific contexts)


Practical Localization for Sensor Nets

• Nirupama Bulusu, John Heidemann, and Deborah Estrin. GPS-less low cost outdoor localization for very small devices. IEEE Personal Communications, 7(5):28-34, October 2000. Special Issue on Smart Spaces and Environments.

• Lance Doherty, Kristofer S. J. Pister, and Laurent El Ghaoui. Convex position estimation in wireless sensor networks. In Proceedings of IEEE Infocom 2001, volume 3, pages 1655-1663. IEEE, IEEE Computer Society Press, April 2001.

• Radihika Nagpal, Organizing a Global Coordinate System from Local Information on an Amorphous Computer. MIT AI Memo 1666, August 1999.


GPS-less low cost outdoor localization for very small devices

• Putting a GPS on every mote is impractical:

• Size• Power• Cost

• How can we get around this while still taking advantage of GPS?


The Algorithm

A regular grid of reference points sends out beacon signals at fixed intervals. Nodes listen for beacons for a fixed period of time, and then decide on location.


Pros Cons

Connectivity-basedapproach (i.e., onlylocal interaction)

Accuracy can befine-tuned forapplication needsby changing thedensity of the grid

Designed using anidealized radio modelwith perfect sphericalradio propagationAssumes a regular gridof nodes with knownlocations to serve asreference points,covering the entirenetwork


Convex position estimation in wireless sensor networks

• Unlike the previous paper, no fixed grid (e.g., motes may be dropped from an airplane)

• “[assume that] only a few nodes have known positions (perhaps equipped with GPS or placed deliberately)”

• Remaining node positions are computed from knowledge about communication links.


The Algorithm

All nodes beacon to find out neighbors

Neighbors, along with known node positions, define a (possibly under-constrained) constraint-satisfaction problem, which can be solved to obtain approximate node locations


Pros Cons

Only a few nodeslocations areneeded

Those nodes whoselocations areknown can berandomly scattered

Designed using anidealized radio modelwith perfect sphericalradio propagationNon-local computation!Assumes the allconstraints areforwarded to a centralPC, which computes allnode locations, andforwards the informationback to the nodes


Organizing a Global Coordinate System from Local Information on an Amorphous

Computer• A “biologically inspired” algorithm

• Uses the “amorphous computing” model, which is similar to sensor nets, but with an important difference:a fixed communication radius r is assumed for all nodes, and communication is assumed to be 100% reliable


Biologically Inspired Computation

Ant Colony System used to solve TSP and other optimization problems

Artificial Neural Nets can be “trained” to play games, drive, recognize text, etc...

Localization algorithm based on the way embryos differentiate


The Algorithm

Three anchor processors are chosen, as far apart from each other as possible.

Anchors send beacons are sent with count=0, which are flooded through the network, incrementing count at each step.

The lowest valued beacon a node receives from a given anchor is its distance from that anchor, and triangulation gives location.

When computing the distance, accuracy can be improved by “smoothing” (averaging with neighboring values):

Why -0.5? Because neighbors are on average r/2 further away from the source (in an idealized scenario)


Pros Cons

Only a few nodeslocations areneeded

Those nodes whoselocations areknown can berandomly scattered

Entirely localizedalgorithm

Designed using anidealized radio modelwith perfect sphericalradio propagation

How critical will this bein determining real-world performance?


More on Radio Transmission

• It should be possible to eliminate long links by using a MAC protocol

• Effects of non-circular radii will be averaged out over long distances

• Voids present a problem...


VOID

Voids are problematic, sincenodes on the other side will receive inaccurately high counts. No simple solution...

Anchor 1

Anchor 2

Node

5.3.2 RAP


Outline

• I-EDF vs SPEED vs RAP

• RAP: Real-time locAtion-based Protocols– Architecture and API’s– Velocity Monotonic Scheduling

• Evaluation Results


I-EDF vs. SPEED vs. RAP

• Hard real-time– Absolute guarantee

• Engineered network• Static traffic• Heterogeneous platform

– Sophisticated router node

• MAC scheduling• Prioritization (EDF/RR)

• Soft real-time– No guarantees

• Ad hoc deployment• Dynamic traffic• Homogeneous platform

– Implemented on motes

• Routing, MAC rate control• No prioritization

• Soft real-time– No guarantees

• Ad hoc deployment• Dynamic traffic• Homogeneous platform

– Possible on motes

• MAC scheduling• Prioritization (VMS)


Design Requirements

• Real-time requirements

Minimize end-to-end deadline miss ratio • Support distributed microsensing

High-level service API’s• Large scale, high density

Scalability is key• Extreme resource constraints: bandwidth, energy

Minimum protocol overhead


Location-based Communication

ID-based• From ID to ID• What is the reading of

sensor 125.111.1.5?• Rely on (unreliable)

individual sensors

Location-based• From location to location• What is the virus density in

south terminal of airport?• Individual sensors NOT

important

• Local coordination: Sensors in interested area aggregate data

• Sensor-base comm.: Send aggregated result to base station


RAP: Real-time locAtion-based Protocols

Velocity Monotonic Scheduling

Prioritized MAC

Query/Event Service

Coordination Service

Location-Addressed Protocol

Sensing/Control Application

Query/Event Service APIs

Geographic Routing


Query/Event API

• High-level abstraction for programming distributed microsensing applications

register_event {virusFound(0,0,100,100), // area to post eventquery { // query to be triggered

virus.count, // attributearea=(x-1,y-1,x+1,y+1), // query areaperiod=1.5, deadline=5, // timing infobase=(100,100) // base station location

}}


Prioritized MAC

Query/Event Service



Geographic Forwarding


Geographic Routing

Local state Scalability Dense network Efficient greedy forwarding works well Dense network #hop proportional to distance Location-based comm. No location directory service


Prioritized MAC

Query/Event Service




A C

Closest to C

E


Velocity

• Timing constraint: deadline• Location constraint: distance to destination• Requested Velocity

– Embody both constraints– Reflect local urgency

Velocity Monotonic Scheduling (VMS):

Priority = Requested Velocity


Prioritized MAC

Query/Event Service





Example

dis = 60 m; D = 2 sV = 30 m/sLOW Priority

dis = 90 m; D = 2 sV = 45 m/sHIGH Priority

A

B

D

C



Static VMS• Fixed velocity on each hop• V = dis(x0,y0,xd,yd)/D

– Source location: (x0,y0)– Destination location: (xd,yd)– End-to-end deadline: D

Dynamic VMS• Adapt velocity at intermediate node based on progress• Vi = dis(xi,yi,xd,yd)/Si

– Velocity at node: Vi – Location of node i: (xi,yi)– Slack: Si = D – elapseTime


Prioritized MAC

• Collision Avoidance (CA)– Channel idle wait for randDIFSPrio

• Contention– Collision (No CTS or No ACK)CW = CW*(2+(Prio-1)/MAX_Prio)

• Similar to 802.11’s EDCF

Idle

TimerandDIFSPrio

ContentionExponential Backoff

TransmissionAvoidance

CW

AcquireChannel


Prioritized MAC

Query/Event Service





Simulation: Biometric Sensing

• 100 nodes on 136X136 m2 (4.5X4.5 radius2)

• Periodic query count on 31 nodes; detail on 15 nodes

Base Station

Hot Regions(sources)

FAR


Workload

• Network (roughly approximate MICA mote)– Communication range: 30.5 m– Packet size: 32B (count), 160 B (detail)– Bandwidth: 200 kbps (> MICA)

• Protocols– Routing: DSR (Dynamic Source Routing), GF

(Geographic Forwarding)– Scheduling: FIFO, DS (Deadline-based), SVM, DVM– MAC: 802.11, extended 802.11 w. prioritization


Deadline Miss RatioOverall

GlomoSim simulation (deadline: detail: 5 s, count: 10 s)


Deadline Miss RatioFAR hot region

GlomoSim simulation (deadline: detail: 5 s, count: 10 s)


Distance Fairness

• SVM provides “fairer” service to remote sensors– Critical for scalability of sensor networks!

0.00

0.10

0.200.30

0.40

0.50

0.60

0.700.80

0.90

1.00

0 50 100 150 200

distance from base station (m)

mis

s ra

tio FIFO

SVM

DS


Conclusion

• Velocity Monotonic Scheduling

Reduce end-to-end deadline miss ratio

Fair service to remote sensors• Event/query service API’s

High-level abstraction for distributed microsensing

• Location-based protocol stack

Scalable

Small protocol overhead


Critique• VMS

– DVM– No schedulability analysis or admission control No guarantee – Is velocity the right trade-off between distance and time?– Distance = #hop? in-doors, obstacles, void, long links

• No routing or congestion control to handle congestion: RAP+SPEED+?

• Lack support for– Coordination services– Areamulticast– Mobility

• It’s a whole (or three) PhD thesis ahead!

5.4 Berkeley Mote & TinyOS


Class Issues• Motes arrived

– 5 programming board– 25 mica CPU/radio boards– 10 rene sensor boards: light, temperature– 5 mica sensor board: light, temperature, acoustic– Did not get: accelerometer, magnetometer

• Slides finally online• Sample project to appear later this week

(promise!)• 24 days to proposal due date• Free food: ACM BBQ @ 11-1p Friday Lopata Courtyard

http://www.cse.wustl.edu/~lu/cs537s/cs537s_schedule.htm


Hardware Constraints

• Severe constraints in power, size, and cost translated to:• Slow CPU• Short-distance, low-bandwidth radio• Small memory• Limited hardware parallelisms

– CPU hit by many interrupts!

• Support sleep mode in hw components


Mote• CPU: 4 MHz, 8 bit

– NO kernel/user protection– Raw peripherals a lot work for CPU:

• Collect data from sensors• Process every bit to/from radio• Arbitrate bus

• Radio: 900 Hz– Rene: 19.2 kbps– Mica: 50 kbps (max), 200 feet (power adjustable)– NO byte level processing

• Memory– Rene: 512 B data; 8K code– Mica: 4 KB data; 128 KB code

• Two AA battery– 3 days of continuous active operation

• Sleep modes: idle/power-down/power-save


Software Challenges• Small memory footprint• Efficient in power and computation• Lack hardware parallelism OS provides

concurrency-intensive operation• Real-time• Robust• Diversity in applications and design

– Efficient modularity– Reconfigurable hardware– Software & hardware codesign


How about a traditional embedded OS?

• Multi-threaded architecture– Large number of threads large memory– Context switch overhead

• I/O model– Blocking I/O (stop and go): waste memory on blocked threads– Polling (busy-wait): waste CPU cycles and power

• Protection between applications and kernel– Overhead for crossing kernel/user boundary & interrupt handling

• Pros– Clean & simple programming model– Priority-based scheduling support– Robust (protect kernel)


Example: Existing embedded OS

1. Thread 1 (high prio) runs– read from socket 1– block

2. Thread 2 (medium prio) runs– read from socket 2– block

3. Thread 3 (low prio) runs4. Thread 2 unblocked, preempt thread 35. Thread 1 unblocked, preempt thread 26. Threads 1,2,3 complete in order

3 TCB’s, 6 context switches, 7 kernel/user switch


TinyOS Solutions• Support concurrency: event-driven architecture• Modularity: application = scheduler + graph of components

– Compiled into one executable • Efficiency: Get done quickly and sleep

– Event = function calls– Less context switch: FIFO/non-preemptable scheduling– No kernel/application boundary

CommunicationActuating Sensing Communication

Application (User Components)

Main (includes Scheduler)

Hardware Abstractions

Modified from D. Culler et. Al., TinyOS boot camp presentation, Feb 2001


TinyOS component model

• Component has:– Frame (memory)– Tasks: thread (computation)– Interface:

• Command

• Event

• Frame: static storage model – compile-time allocation • Command and events = function calls• Clean (hw-like) interface

– No shared memory or global variables– Replace hw with sw and vice versa

Messaging Component

Internal StateInternal Tasks

Commands Events


TOS Component//AM.comp//

TOS_MODULE AM;ACCEPTS{ char AM_SEND_MSG(char addr, char

type, char* data); void AM_POWER(char mode); char AM_INIT();};SIGNALS{ char AM_MSG_REC(char type,

char* data); char AM_MSG_SEND_DONE(char success);};HANDLES{ char AM_TX_PACKET_DONE(char success); char AM_RX_PACKET_DONE(char* packet);};USES{ char AM_SUB_TX_PACKET(char* data); void AM_SUB_POWER(char mode); char AM_SUB_INIT();};

Messaging Component

AM_SUB_INIT

AM_SUB_POWER

AM_SUB_TX_PACKET

AM_TX_PACKET

_DONE

AM_RX_PACKET

_DONE

Internal State

AM_INIT

AM_POWER

AM_SEND_MSG

AM_MSG_REC

AM_MSG_SEND_DONE

Internal Tasks

Commands Events


A Complete Application

RFM

Radio byte (MAC)

Radio Packet

i2c

Tempphoto

Messaging Layer

clocksbit

byte

packet

Routing Layer

sensing applicationapplication

HW

SW

ADC

messaging

routing

D. Culler et. Al., TinyOS boot camp presentation, Feb 2001


TinyOS Two-level Scheduling• Tasks do computations

– Unpreemptable FIFO scheduling– Bounded number of pending tasks

• Events handle interrupts– Interrupts trigger lowest level events

– Events can signal events, call commands, or post tasks

• Two priorities– Event/command– Tasks

Hardware

Interrupts

eve

nts

commands

FIFO

TasksPOST

Preempt

Time

commands


How to handle multiple data flows?

• Data/interrupt are handled by– Respond to it quickly: A sequence of non-blocking

event/command (function calls) through the component graph

• e.g., get bit out of radio hw before it gets lost

– Post tasks for long computations• e.g., encoding

– Assumption: long computation are not emergent

• Preempting tasks to handle new data


Receiving a message

Timing diagram of event propagation


How should network msg be handled?

• Socket/TCP/IP?– Too much memory for buffering and threads

• Data are buffered in network stack until application threads read it

• Application threads blocked until data is available

– Transmit too many bits (sequence #, ack, re-transmission)– Tied with multi-threaded architecture

• TinyOS solution: active messages


Active Message• Every message contains the name of an event handler• Sender

– Declaring buffer storage in a frame– Naming a handler– Requesting Transmission; exit– Done completion signal

• Receiver– The event handler is fired automatically in a target node

No blocked or waiting threads on sender or receiver Behaves like any other events Single buffering


Send Messagechar TOS_COMMAND(INT_TO_RFM_OUTPUT)(int val){

int_to_led_msg* message = (int_to_led_msg*)VAR(msg).data;

if (!VAR(pending)) {

message->val = val;

if (TOS_COMMAND(INT_TO_RFM_SUB_SEND_MSG)(TOS_MSG_BCAST, AM_MSG(INT_READING), &VAR(msg))) {

VAR(pending) = 1;

return 1;

}

}

return 0;

}

msg buffer

access appln msg buffer

cast to defined format

mark busy

application specific ready check

build msg

request transmission

destination identifier

get handler identifier


Analysis and Evaluation

• Let’s take apart Space, Power and Time


Space Breakdown…

Code size for ad hoc networkingapplication

0

500

1000

1500

2000

2500

3000

3500

Byt

es

InterruptsMessage DispatchInitilizationC-RuntimeLight SensorClockSchedulerLed ControlMessaging LayerPacket LayerRadio InterfaceRouting ApplicationRadio Byte Encoder

Scheduler: 144 Bytes codeTotals: 3430 Bytes code

226 Bytes data

D. Culler et. Al., TinyOS boot camp presentation, Feb 2001


Power Breakdown…

– Lithium Battery runs for 35 hours at peak load and years at minimum load!

• That’s three orders of magnitude difference!– A one byte transmission uses the same energy as approx

11000 cycles of computation.

Active Idle Sleep

CPU 5 mA 2 mA 5 μA

Radio 7 mA (TX) 4.5 mA (RX) 5 μA

EE-Prom 3 mA 0 0

LED’s 4 mA 0 0

Photo Diode 200 μA 0 0

Temperature 200 μA 0 0

Panasonic CR2354

560 mAh


Time Breakdown…

• 50 cycle thread overhead (6 byte copies)• 10 cycle event overhead (1.25 byte copes)

ComponentsPacket reception work breakdown CPU Utilization Energy (nj/Bit)

AM 0.05% 0.20% 0.33

Packet 1.12% 0.51% 7.58

Ratio handler 26.87% 12.16% 182.38

Radio decode thread 5.48% 2.48% 37.2

RFM 66.48% 30.08% 451.17

Radio Reception - - 1350

Idle - 54.75% -

Total 100.00% 100.00% 2028.66


Applications

• Multi-hop routing

• Active badge

• Vehicle sensing

• Air-to-ground communication

• Habita monitoring @ Great Duck Island


Routing• Each node needs to determine it’s parent and its

depth in the tree• Each node broadcasts out <identity, depth, data>

when parent is known• At start, Base Station knows it is at depth 0

– It send out <Base ID, 0, **>• Individuals listen for minimum depth parent

0Base

1

1

2

2

3


• 16 motes deployed on 4th floor Soda Hall

• 10 round motes as office landmarks

• 2 base stations around corners of the building

• 4 Rene motes as active badges for location tracking

• AA batteries (3 weeks)

• Tracking precision +/- one office

http://nighthawk.cs.berkeley.edu:8080/tracking

Active badge


Vehicle sensing

• Unmanned airplane dropped motes from an unmanned airplane

• Motes automatically forms a network• Motes detect passing vehicles through

magnetic sensors• Unmanned airplane sends a query to motes

to get the passing time of the vehicle


TinyOS: Pros• Small memory footprint

– Non-preemptable FIFO task scheduling

• Power efficient– Put microcontroller and radio to sleep

• Efficient modularity– Clean function call (event, command) interface

between components

• Concurrency-intensive operations– Event/command + tasks– Efficient interrupts/events handling (function calls, no

user/kernel boundary)


TinyOS: Cons• Messy/difficult programming model

– Explicit negotiation for data/resource– No “long-running” things in command/event handlers– No kernel/user protection NOT robust

• An infinite loop in application: all dead!– Zero compatibility implement everything from scratch

• No overload protection– “Livelock”: interruptions/events consume all CPU cycles NO

real-work get done

• No real-time support/analysis– Non-preemptable FIFO task scheduling– How do we know the performance?

• Over constraining the platform?


TinyOS: Extensions

• Virtual machine: Mate– Higher-level programming model– Protection– Code mobility

• A project:– Preemptable, priority-based scheduling (RM, EDF,

proportional share)– Timing analysis– Avoid “live lock”– Overload protection


Pointers

• Brian: Virtual machine (Thursday)• Xiaorui: TinyOS internals (Next Thursday)

– No critique required

• http://today.cs.berkeley.edu/tos/• http://www.xbow.com/Products/Wireless_Sensor

_Networks.htm

http://today.cs.berkeley.edu/tos/

http://www.xbow.com/Products/Wireless_Sensor_Networks.htm

http://www.xbow.com/Products/Wireless_Sensor_Networks.htm

chapter05 sensor networks

Documents

network aggregation

locatereport targets

sigmetrics keynote

distributed computing

inpocket pc

srampocket pc

bitpocket pc

yearsneed power management