Macroprogramming for Wireless Sensor Networks Athanassios Boulis Networks and Pervasive Computing pr

1
Macro-programming forWireless Sensor
NetworksAthanassios Boulis Networks and
Pervasive Computing programNational ICT
AustraliaJune 2005
2
Wireless Sensor Networks

• Advantages
• Proximity ? high SNR
• Dense instrumentation in space and time
• Resilience through inherent redundancy
• Operate unattended ? Low cost
• Vision a new look into the physical phenomena
• First client Science (new instruments to
  measure and understand the world around us)

3
Abstracted View of Sensor Networks
Deer at (x,y) moving NW at 5mph
4
Design Themes
We need Long-lived systems that can be
untethered and unattended

• Low duty-cycle operation with bounded latency
• Exploit redundancy
• Leverage data processing inside the network
• Exploit computation near data to reduce
  communication
• Exploit energy-accuracy-delay trade-offs
• Achieve desired global behavior with adaptive
  distributed localized algorithms

5
What has been done?

• Explosion of research groups in the area the past
  5 years
• new conferences/workshops/journals focusing in
  WSN
• (too many to list)
• old conferences changing focus
• NSF-funded research centers
• Output?
• Generic problems tackled
• Application-specific algorithms created
• Testbeds created
• Real applications developed

6
What has been done? (contd.)
Utility, relevance to WSN less relevant more
relevant
size of work
app algorithms
Localization, Time Sync
programming platforms
7
Why so few Real Systems Real Applications?

• Difficulties identifying real (economically
  attractive) applications.
• despite proliferation of vague ideas, real market
  analysis is something that engineers hate/ignore.
  
• Difficulties deploying WSN
• need to deploy meaningfully in the physical world
• Difficulties programming
• merging of embedded and distributed programming
  in a wireless medium and very limited resources

8
Programmability Issues

• WSN are complex distributed systems they dont
  just send back data. Remember?.... In-Network
  processing
• How do we task a dynamic sensor network to
  conduct complex, long-lived queries and tasks ??
• What constructs does the query/task language need
  to support?
• What sorts of mechanisms need to be running in
  the background in order to make tasking efficient?

9
Programmability Issues

• Several platforms use existing (embedded) OS
• eCOS, µC/OS
• powerful stargate platform uses Linux
• Berkeley Motes use a module-based OS TinyOS

Module
10
Node-level Programmability

• Build executable images for each type of task and
  download them to nodes
• Tedious! Even worse after deployment!
• Use the Network to transfer the executables
• Gets rid of the tediousness
• Inefficient!
• WSN not sharable among multiple users.

programming
deployment
Programmer
11
Database Model Programmability

• WSN seen as a distributed database
• Cornells Cougar,
• Berkeleys TinyDB

SELECT room_id, avg(light) FROM sensors GROUP
room_id SAMPLE PERIOD 1h
12
Database Model Programmability (contd.)

• Forms of queries
• Tell me periodically what you see. Try to
  maximize reward for a given node energy supply.
• Do you currently see X?
• Did you see X in the past timer T?
• Inform me when you see X.
• Problem remote user is in the interactive loop
• Researchers started looking for a more
  information-driven user-out-of-the-loop
  programmability models/strategies

13
Mobile-Agent (or Active Sensor) Models

• Abstract the nodes run-time environment
• Make tasks autonomously mobile

services
Language ties services into tasks
14
Macro-Programming

• Programming in the aggregate
• No more node-level programming Dont handle
  individual nodes, handle the network
• Specify tasks in a higher level, hide embedded
  system details and node communication protocols.
• For efficiency macro-programming should result
  in
• Estimation algorithms that inherently expose
  accuracy/energy/delay trade-offs
• Robust algorithms by use general algorithmic
  techniques that exploit the inherent redundancy
  of WSN

15
The Kairos Platform (USC)

• Goals (at least for now)
• Small, yet expressive set of abstractions
• Abstractions for facilitating expressivity rather
  than performance tuning
• Three constructs
• Addressing arbitrary nodes
• Iterating through one-hop neighbors of a node
• Reading remote variables at arbitrary nodes
• Eventual consistency semantics

material from Ramki Gummadi
16
Kairos Abstractions

• Abstractions implemented as programming
  primitives
• First-class extensions to host language,
  language-agnostic
• Nodes logically named using integer identifiers
• node datatype with operators for equality,
  ordering, type testing, etc.
• node_list iterator data type for manipulating
  sets of nodes
• One-hop neighbors using a get_neighbors()call at
  runtime
• Can construct arbitrary topologies by iteration

material from Ramki Gummadi
17
Kairos Abstractions (contd.)

• Remote data access ability
• variable_at_node notation
• No restrictions on which remote variables may be
  read where and when, modulo language scoping,
  lifetime, and access rules
• Effectively, a shared-memory abstraction across
  nodes
• Only remote reads, not remote writes
• Eliminates a large class of subtle distributed
  programming bugs due to locking, race conditions,
  etc.

material from Ramki Gummadi
18
Regiment (Harvard)

• Regiment Functional Macroprogramming Language
• Based on functional reactive programming concepts
• Functional languages pure, no input no output
• cannot manipulate program state
• allows the compiler to decide how and where the
  program state is kept in the volatile mesh of
  sensor nodes
• Basic data abstraction region streams
• A time-varying collection of node state
• e.g., All sensor nodes within area R form a
  region
• The set of their periodic data samples form a
  region stream

material from Matt Welsh
19
Regiment Example Simple Target Tracking

• let aboveThresh(p,x) p gt THRESHOLD
• read node (read_sensor node,
• get_location node)
• in compute_centroid
• (rfilter aboveThresh (smap read world))
• Vehicle tracking system implemented in a few
  lines of code
• Simple primitives for declaring, filtering and
  aggregating sensor streams
• Compiles down to efficient node-level programs

material from Matt Welsh
20
Market Based Macroprogramming (Harvard)

• Basic model
• Nodes act as agents that sell goods (such as
  sensor readings or routed msgs)
• Each good is produced by an associated action
  that produces it
• Nodes attempt to maximize their profit, subject
  to energy constraints
• Each good has an associated price
• Network is programmed by setting prices for
  each good
• Each action has an associated energy cost
• e.g., Cost to sample a sensor ltlt Cost to transmit
  a radio message

material from Matt Welsh
21
How are we Programming in MBM ?

• First step Set the price(s)
• use one of many efficient dissemination protocols
• update prices as need by the overall application
  goal
• Nodes select actions based on a utility function
• Utility depends on
• Price
• Advertised by base station
• Energy availability
• Taking an action must stay within energy budget
• Other dependencies
• Cannot aggregate data until multiple samples have
  been received
• Cannot transmit if nothing in local buffer

material from Matt Welsh
22
Learning Expected Profits
The utility function is the expected profit for
taking an action a.
b(a)price(a) if the action's dependencies have
been met
u(a)
0 otherwise

• b(a) is the estimated probability of payment for
  action a
• An action is only profitable if it is useful
• e.g., Only get paid to transmit if another node
  is listening
• b(a) is learned using an exponentially weighted
  moving average
• Action selection uses e-greedy reinforcement
  learning
• Node usually takes action with highest expected
  profit
• However, node takes random action with (small)
  probability e

material from Matt Welsh
23
Utility functions
Utility functions vary depending on node's
position in network Nodes near target have high
utility for sampling Nodes along routing path
have high utilities for listening and sending
material from Matt Welsh
24
Design Issues

• Nodes operate using a very simple program
• Uses only local knowledge energy state, samples,
• Network automatically adapts to changing
  conditions
• Nodes take actions that they individually find to
  be
• Learning strategy for utility function allows
  runtime
• Payments lead to a natural equilibrium
• Example Fraction of nodes transmitting and
  listening
• Prices yield control over network-wide behavior
• But, some question about how general this is...

material from Matt Welsh
25
Something New from NICTA?

• Keep the positive but make it more manageable
  than MBM
• act locally, affect globally
• simple node interactions and internal processes
• adapt automatically to changes (mind the
  volatility and uncertainty)
• Key ideas
• central entity is state (usually estimated
  state)
• language constructs to direct handling of state
  globally or locally
• no routing ! very simple communication
  capabilities
• broadcast state
• pheromone-like state diffusion
• probabilistic nature of results, leverage the
  uncertainty

26
Example Desired Solution Aggregation
Snapshot Aggregation (e.g. find once the
max/min/avg)
Request by User floods the SN
Result is aggregated as it flows up the tree
Periodic Aggregation User needs aggregate at
periodic intervals. Conventional solution
Run snapshot aggregation periodically
27
Can We Save More Energy?
We have to move in other problem dimensions.
E.g. Accuracy
Curve derived by some strategy
Energy spent
Allowable error ( 1/Accuracy)
28
Spatio-temporal Correlation
A dynamic physical process
Time
Find techniques to exploit the spatial and
temporal correlation
29
Initial Approaches

• Allow variable update rates. Compute optimum
  rates.
• Centralized computation power of nodes
• Distributed not fully used
• Node takes decision locally to send data or not
• Based on partial local info no global
  view
• Based on user-sent global aggregate prediction
  not robust
• To overcome above shortcomings we propose the
  Intrinsically Distributed Estimation Algorithm
  (IDEA)

30
IDEA Main Properties

• Estimation
• Each node keeps an estimate of the global
  aggregate in the form (estimate_mean,
  estimate_variance)
• Local values and global estimates are fused to
  produce new global estimate
• Distributed
• Nodes exchange global estimates. Global estimates
  are fused at each node
• Localized
• Nodes only communicate with immediate neighbors.
• Knowledge of neighbors is not necessary

31
Basic Operations
Current Estimate
Local Measurement
Estimate from neighbor
New Estimate
Transmit new estimate to neighbors
Do Not transmit new estimate
32
IDEA Main Results
Results for 2 physical processes shown (i.e., 2
curves for IDEA)
Allowed error
IDEA
Total energy spent (J)
Error at user node ()
periodic snapshots
IDEA
periodic snapshots
Threshold ()
Threshold ()
33
Robustness of IDEA
periodic snapshots with tree reconstruction
periodic snapshots
Total energy spent (J)
IDEA
of dead nodes
34
Key Points of the IDEA

• Exposes the energy-accuracy trade-off
• considerable savings for allowing small errors
• Fully distributed and localized
• not even a routing protocol needed.
• Adaptive/versatile
• performs well across different scenarios
• Robust to node and link failures
• aware of the uncertainty of the wireless channel
• exploit inherent redundancy

35
Macro-Programming Advantages

• Save the programmer the effort of decomposing
  distributed tasks
• apart from the obvious alleviation of embedded
  programming
• Force the programmer to think in terms of
  trade-offs
• energy vs. accuracy. vs. delay
• Produce robust algorithm based on generic
  methodologies

36
Opportunities for Formal Methods

• Macro-programming methods could be amenable to
  analysis
• global rules automatically produce low-level
  interactions which in turn produce results.
  Analyze this!
• challenge some methods can use probabilistic
  techniques.
• attractive since the impact of an effective
  macro-programming framework surpasses any singe
  protocol.

37
Protocols Architecture or Mess?
App
EnviroTrack
Hood
TinyDB
Regions
FTSP
Dir.Diffusion
SPIN
Transport
TTDD
Trickle
Deluge
Drip
MMRP
Routing
Arrive
TORA
Ascent
MintRoute
CGSR
GPSR
AODV
ARA
DSR
GSR
GRAD
DBF
DSDV
TBRPF
Scheduling
Resynch
SPAN
FPS
GAF
ReORg
Topology
PC
Yao
SMAC
WooMac
PAMAS
BMAC
TMAC
Link
WiseMAC
Pico
802.15.4
Bluetooth
Phy
eyes
RadioMetrix
CC1000
nordic
RFM
38
Opportunities for Formal Methods (contd.)

• But you will not just analyze.
• the framework is not given (as a protocol is)
• the framework is developing and can take
  different paths according to cues of what is
  analytically tractable and what not. Synthesize
  this!
• ideally there should be a co-evolution of the
  design/synthesis of framework and its analysis

39
Thank You!

• Questions/Comments?