Hood and Snack

1
Hood and Snack

• Presented by Ben Greenstein
• For CS-213 Deborah Estrin
• March 2, 2004

2
Hood A Neighborhood Abstraction for Sensor
Networks

• Kamin Whitehouse, Cory Sharp,
• Eric Brewer, David Culler
• University of California at Berkeley

3
Jargon

• Attribute
• Element of a nodes state that can be shared with
  neighbors
• Mirror
• Local view of a neighbors state
• Reflection
• Cached version of a neighbors attribute
• Scribble
• Local annotations about a neighbor
• Neighbor list
• Locally maintained membership list of neighboring
  nodes
• Filter
• Membership is determined by a filter, which uses
  the mirrors to accept or reject new nodes

4
Claims

• Neighborhood-based algorithms are easier to
  design, implement, and modify with Hood than with
  traditional primitives alone
• Case study of an application implemented with and
  without Hood
• Quality of the implementation using Hood is
  better
• Comparitive analysis of implementations with and
  without hood
• Hood captures the essence of many distributed
  sensor network algorithms
• Analysis of different usages of neighborhood
  concepts in 16 existing applications

5
Object Tracking Application (OTA)

• Remote control car driven through field of
  magnetometers. Sensors report location to a
  camera
• Claim largest TinyOS application to date.
• Components
• Localization
• Stores nodes location and reports location when
  it changes
• Tracking
• Monitors magnetometer and reports when
  significant change
• Routing
• Uses geographic routing but only considers those
  nodes that report location and that are in a
  user-defined routing neighborhood

6
Problems

• Localization should not be for arbitrary
  neighbors, but should be for the neighbors that
  are on the routing and tracking neighbor lists
• This sort of coupling is difficult to accomplish
  if each service maintains its own neighbor list.

7
Solution

• Merge all data caches into a single component
• Separate neighbor lists from their parent
  components and the data cache

8
Declaring a Hood

• LightHood new Hood(LightThreshold, 5)
• Generates LightHood nesC module with an array for
  holding up to five node ids.
• Interface Hood command nodeID
  getNeighbors() command bool isNeighbor( nodeID
  id) event void removingNeighbor( nodeID
  id) event void addedNeighbor( nodeID id)
• The Hood interface is used to access the
  neighbor list

9
Declaring an Attributeand a Reflection

• LightAttribute new Attribute(int)
• These commands generate the following interfaces
  which are provided by the data cache
• Interface LightAttribute command int
  get() command void set ( int value ) command
  void push() event void updated( int value
  )interface LightReflection command int
  get( nodeID id) command void scribble( nodeID
  id, int value) command void pull( nodeID
  id) event void updated( nodeID id, int
  value)
• LightReflection new Reflection(LightHood,
  LightAttribute)
• Associates an attribute with a neighbor list

10
OTA in Hood

• MagHood new Hood(GeographicRadius,
  8)RoutingHood new Hood(ClosestToDestination,
  8)
• Generate MagHood and RoutingHood components with
  their respective filters
• What about cache replacement when the 9th node
  passes the filter?
• MagAttribute new Attribute(int)LocationAttribu
  te new Attribute(location_t)
• Generate the attribute interfaces which are
  provided by the data cache
• MagReflection new Reflection(MagHood,
  MagAttribute)LocationReflection new
  Reflection(MagHood, LocationAttribute)LocationRe
  flection new Reflection(RoutingHood,
  LocationAttribute)
• Generate reflection interfaces which are provided
  by the data cache.
• Tie the attribute reflection messages to the
  filters of the two neighbor lists.
• LinkEstimator1 new Scribble(RoutingHood,
  int)LinkEstimator2 new Scribble(RoutingHood,
  int)
• Same as reflection commands except they take a
  type instead of an attribute.

11
Results

• 33 reduction in non-Hood code
• The Hood code is, of course, flawless ?
• Reduction in non-Hood state machine
• Many existing applications could benefit from
  Hood
• Many are single-hop
• They have neighbor lists, shared attributes,
  reflected attributes, and local scribbles

12
SNACK

• Sensor Network Application Construction Kit
• Ben Greenstein, Eddie Kohler, Deborah Estrin
• March 2, 2004

13
Why SNACK?

• Make it easy for scientists (i.e.,
  non-programmers) to rapidly develop efficient
  sensor network applications

14
Do nesC and TinyOS meet this goal?

• Most common complaint about TinyOS/nesC You
  have to be a genius to program in it
• Almost correct you only have to be an
  experienced systems developer to program in it.
• The goal of TinyOS has largely been one of
  efficiency. Very little effort has been focused
  on making application development easy
• Note TinyDB and Tiny Diffusion can handle a
  variety of queries, but the application itself,
  namely TinyDB or Tiny Diffusion, is always the
  same.

15
Consequences of Flexible Hardware/ Software
Interface in TinyOS

• No function pointers
• No callbacks
• No component instances (changing)
• Funky state maintenance
• No dynamic memory
• Static allocation of messages
• Pointer swaps
• Guards

16
Unformatted packets

• Design Choice
• Monolithic TOS_Msg with 29 byte payload
• Consequence
• Doesnt work well for layered systems, because 29
  bytes isnt enough room to encapsulate
• Flat data block not well suited to dynamically
  sized and typed content
• Examples
• Every data type gets its own packet
• Complex structures of unions of structures

17
Proposed Solution

• A library of application services comprised of
  nesc components
• A nesc-like configuration language to snap
  services together
• A compiler to optimize a configuration to produce
  an efficient implementation

18
Service Library Design

• Instantiatable components
• Nesc parameterized interface/state copies
• Code duplication
• Attribute/Length/value message format
• Data-flow oriented
• Call chains for messages
• Disjoint paths for data
• Soft-state consistency
• Dynamic memory
• Split-phase avoidance
• Hand-off data passing model

19
An example

• Sample temperature over the network.
• Construct homogenous regions in which temperature
  is uniformly above a defined threshold
• If the area of any such region is large enough to
  merit further study, turn on more power-hungry
  sensors like magnetomers, seismometers, and
  cameras or actuators like sprinklers, air
  conditioners, etc.

20
Application Structure
Temperature Sampler
EWMA
Threshold
Push
Push
Edge Switch
Local Area Estimator
Push
FromChild
Sum Aggregator
Spanning Tree
UART to DB
ToRoot
ToTree
AtRoot
Threshold
Expensive Sampler
Rooted Tree
ToRoot
Edge Switch
21
The configuration language

• Features
• Instance labeling
• Component constraints
• my for uniqueness and initialization parameters
• Interface constraints
• _at_leastonce, _at_mostonce, _at_once, _at_any
• Default wirings

22
Are there instances in nesc?

• Not as part of the language, but instance
  functionality can be achieved via
• Code duplication
• Parameterized instances and arrays of state

EWMA
EWMA_1
EWMA_2
,
0
EWMA state_t s3
1
2
23
Why bother with instances?

• Example 1 A buffer component that holds my data
• Example 2 Processing component that is uniquely
  initialized for my needs
• Ewma
• Low/high pass filters, wavelet compression, etc.
• Example 3 Unique data flow paths through a
  component
• A1 -gt EWMA -gt A2, B1 -gt EWMA -gt B2

24
A closer look at Dataflow TimerC

• interface Timer command result_t start(char
  type, uint32_t interval) command result_t
  stop() event result_t fired()
• Allows you to do something like
• What if you wanted

start
Timer
A
fired
start
Ain
fired
Aout
start
Timer
Timer
A
B
OR
start
fired
Bin
Bout
fired
25
Do instances make life easier?

• Nescs parameterized interfaces provide
• Caller differentiation,
• but no built-in mechanism matching array of state
  to callers.
• An instantiatable component
• All of a nesc components interfaces are
  parameterized
• state is specified as an array of structs
• Use requires hand setting the parameters for the
  interfaces in the wiring and the size of the
  array
• Snack provides instance semantics
• A programmer specifies an instance and lets the
  compiler determine the paramters
• A programmer can think in terms of instances
  instead of monolithic components that may or may
  not have the mechanism to differentiate users.
• Compiler support for such instantiation is
  particularly useful when multiple separate
  datapaths go through an instantiatable component.

26
Changing the way we thing about constraints

• Suppose we have an application with the following
  services
• Link Quality Estimator (LQE) that expects to hear
  from its neighbors at least every 20 seconds,
  snoops all packets and produces connectivity
  measurements
• Tree that builds a routing tree
• Triangulator that build a local view of the
  Delaunay triangulation of the connectivity graph

27
Application design
Periodic Src
LQE
Tree
Triangulator
If the tree and triangulator dont have any
broadcast messages to send, LQE sends its
own beacon
Triangulator
Tree
Network
LQE
How does the LQE know if another service has sent
a broadcasted message in the last 20 seconds?
Network
28
Message chaining

• How do you specify the send call chain?
• Periodic Src ..gt Triangulator ..gt Network
• Periodic Src ..gt Tree ..gt Network
• Periodic Src ( period lt 20s) ..gt LQE -gt Network
• The interface is a MsgRcv with an _at_mostonce
  constraint
• Benefits
• Aggregation of task, i.e., can take advantage of
  other components generating messages
• Packet generation only in Periodic Src
• Packet-related timers only in Periodic Src.

Periodic Src
Triangulator
Tree
LQE
Network
29
Putting it all togetherTreeS, an example service
Parameterized services

• service TreeS (atype, bperiod, croot)
• my treeTreeM(period b, root c)
• srcPeriodicSrcS(period lt b)
• APPInitTreeM _at_once -gt tree
• APPToggle _at_any -gt Toggle _at_least src
  Ready _at_any -gt ?
• ? Get16 -gt Lookup _at_any tree
• treeSignal _at_once
• -gt Signal _at_any src OutMsgRcv
  _at_once
• ..gt tree
• ..gt NetworkS In _at_once
• ..gt tree
• treeStamp _at_once -gt Stamp _at_any AttrS
  
• treeExtract _at_once -gt Extract _at_any
  AttrS
• treeAccess64 _at_once -gt Access64 _at_any
  my NodeStore64

Value constraints on initializations
Do not share qualifier
Default wirings
Interface constraints
Precedence wirings
30
Compiler
Generates
Understands

• my
• ..gt
• _at_

• Instances by code duplication
• Instances by interface parameterization

Solves

• Satisfies my, value and wiring constraints
  while minimizing the number of instances of each
  component type

31
Constraint Satisfaction

• Value constraints on components and services
• My constraints
• Link constraints

32
My constraints
A
A

C
B
B
C
D
E
C
D
E
E
D
Sharable
MY
33
My constraints
A
A

C
B
B
C
D
E
C
D
E
E
D
Sharable
MY
34
My constraints
A
A

C
C
B
B
D
E
D
E
C
C
E
D
E
Sharable
MY
35
Value constraints
p lt 10 s 6
p lt 10 s gt 5
A
A
p 5
p gt Ap

p 2 s 6
C
p lt 2 s gt As
C
B
B
C
p gt Bp
36
Value constraints
p lt 10 s 6
p gt 10 s gt 5
A
A
p 11
p gt Ap

p 2 s 6
C
p lt 2 s gt As
C
B
B
C
p 2
C
p lt Bp
37
Wiring constraints
_at_any
A
A
C
C

_at_any
B
B
C
_at_mostonce
A
A
C
C

_at_mostonce
B
B
C
C
38
Wiring constraints
A
C

A
C
B
B
C
39
Conclusion

• Library of services
• Trees, Spanning Trees, Data Samplers, Link
  Quality Estimator, Filters
• Configuration Language
• Instances, my, initialization parameters,
  wiring constriaints, default connections
• Optimization
• Reduce specification to smallest number of
  instances and convert initialization constraints
  into acceptable initialization parameters.

40

• The End