Sensor Network Application Construction Kit SNACK

1
Sensor Network Application Construction Kit
(SNACK)

• Ben Greenstein
• Eddie Kohler
• Deborah Estrin
• November 5, 2004

2
Mote networks are too hard to program

• Want reusable application services in TinyOS
• Want to port knowledge from one app to the next
• Speed up development
• Found app services dont exist
• System components shared often, application
  components rarely
• So why is it so hard?
• Tight coupling requirements
• Resource constraints
• Cant afford inefficiency, abstraction
  boundaries
• Can we solve this problem with a programming
  methodology?

1000 100 10 1
Service Reuse?
App References
24
Components / Configurations
3
Before SNACK Inefficient Service Combination

• Two samplers, two sampling periods
• Result interference and inefficiency
• Small changes to periods can reduce costs
• Reduce sleep time, data aggregation
• Sampling periods a cross-service concern
• Each component must be aware of the others

5s
time
5.1s
4
After SNACK Service Cooperation
time

• Two independently-specified services
• One tightly integrated program
• Result increased sleep time
• No explicit user involvement! Compiler figures
  out how to combine

5
Solution Overview

• Programming language support for development of
  cooperating application services
• Service level configuration
• Cooperating services
• Library of smart application-level services
• Developed with this language support
• Configuration language compiler
• Weaves together services
• Shares components as much as possible
• Produces an efficient program

6
Contributions

• Language
• Transitive Connections
• Loose Parameters
• Library Components
• Core Components MsgSrc, TimeSrc, Network,
  MemoryPool
• Sensing, aggregation, routing tree formation,
  link quality estimation, query processing, etc.
• TLV Messaging Format
• Compiler Algorithms
• Search for smallest valid configuration
• Our app find result after 28 tests (not gt 1036)
• Practical value
• Runs on motes, ESS2

7
Outline

• Language and Library Features
• Compilation
• Performance Comparison
• Concluding Remarks

8
Landscape nesC and Instantiation

• Build on nesC
• Familiarity, availability of low-level components
• Add new component composition language, new
  component library
• Instances Program with objects, not units
• Multiple instances gt multiple copies of any
  internal state
• Better encapsulation makes libraries easier
• Implement using code duplication (as in nesC 1.2
  generics)
• Code bloat?
• Compiler therefore detects opportunities to share
  instances

Service SmoothedLight LightSampler -gt EWMA -gt
... // EWMA state private to SmoothedLight
9
LandscapeCompilation Goals

• Shares instances as much as possible
• Heed language constraints
• Sharing really helps!
• Sample application had 166 component instances in
  all
• Compiler reduced this to 23 instances of 20
  components!

a1 A a2 A
a1_and_a2 A
Can a1 and a2 be shared?
compiler
10
Combined Message Paths

• Want multiple services to share packets
• Lowers energy
• Separate service-specific processing from general
  message tasks
• Generate outgoing messages MsgSrc
• Receive and send messages Network
• Consume incoming messages MsgSink
• Add or read service-specific data
  TreeDispatch16, etc.

11
Idea Transitive Connections

• Transitive connections (..gt).
• Connects two components via some path using a
  named interface
• Contrast conventional connections
• Services dont need to know about each other
• specify full message paths
• Indicate where other services might weave
  themselves in
• Independent declarations result in cooperating
  execution paths

service LinkEstimator (...) //... MsgSrc
(...) outbound ..gt LinkEstimatorM ..gt
Network service TreeBuilder (...) //...
MsgSrc (...) outbound ..gt TreeBuilderM ..gt
Network
LinkEstimator TreeBuilder
compiler resolves partial ordering
MsgSrc (...) outbound -gt TreeBuilderM -gt
LinkEstimatorM -gt Network
12
SNACK Messages

• Type-length-value packet format
• Benefits
• flexible packet format
• Drawbacks
• type/length overhead
• Linear-time extraction
• Overhead in flexibility far outweighed by savings
  in Preamble, Sync, and CRC transmission

MsgSrc
MsgSink
Header
TreeDispatch16
Header
Header
Data1
TreeBuilderM
Header
Header
Data1
Tree
LinkEstimatorM
Header
Header
Data1
Tree
Link
Network

Header
Sync
CRC
Header
Preamble
Data1
Tree
Link
Shared Overhead
13
Parameterized Services

• SNACK services and components expose specific
  tunable initialization knobs to the service user
• How can unrelated services agree on the
  parameters of shared components?

service LinkEstimator (period max uint32_t p
5000) MsgSrc (period p) outbound ..gt
LinkEstimatorM // Could also multiply by a
constant period 2 p
14
Idea Loose Parameters

• Service may want one in a range of parameter
  values
• Solution loose parameter settings
• Becomes
• Parameter values become a system of linear
  inequalities

service LinkEstimator(...) //...
MsgSrc(period lt 5000) outbound ..gt
LinkEstimatorM ..gt Network service
TreeBuilder(...) //... MsgSrc(period lt 10000)
outbound ..gt TreeBuilderM ..gt Network
MsgSrc(period 5000) outbound -gt TreeBuilderM
-gt LinkEstimatorM -gt Network
15
Connectedness Constraints

• Interfaces usage may restrict sharing
• Routing information should come from exactly one
  source
• at least once
• any
• at most once
• Compiler must consider and preserve constraints
• x1 and x2 cannot share an instance of X

TreeDispatchM lookupGet16 _at_once -gt
TreeBuilderM
Main -gt StdControl _at_least Network
MsgSrc -gt Memory _at_any MemoryPoolM
Network inboundMsgRcv _at_most ..gt
LinkEstimatorM
x1X I _at_once -gt Y x2 XI _at_once -gt Z
16
Explicitly Controlled Sharing

• The SNACK compiler searches for sharing
  opportunities
• The programmer may want explicit control over
  sharing
• To demand sharing, use one instance
• To demand exclusivity, mark an instance as my

a A LightSensorPut16 -gt a -gt ...
TempSensorPut16 -gt a -gt ...
LightSensorPut16 -gt my A -gt ... TempSensor
Put16 -gt my A -gt ...
17
Compilation

• Generate fully specified input program
• Resolve services to underlying components
• Every component reference gets unique instance
• Reduce to a minimum number of component
  instances
• Share component instances
• Input component instances map to reduction
• Connect shared instances
• Input connections map to reduction

18
Minimum Instance Program

• The minimal program must pass four tests
• Interface constraints No _at_once or _at_most
  interface may be directly connected more than
  once
• Parameters Linear system has a solution
• my constraints Share only if enclosing service
  is shared
• Transitive connections a valid ordering exists

19
SNACK Compilation (1)
Application Description
RoutingTree
LightSense
TempSense
RoutingTree

• Sample light and temperature, send both up a
  routing tree
• LightSense -gt collectPut16
  RoutingTreeTempSense -gt collectPut16
  RoutingTree
• Pretty simple!

20
SNACK Compilation (2)
Full specification
RoutingTree
LightSense
RoutingTree
TempSense
TimeSrc
TimeSrc
MsgSink
MsgSrc
MsgSink
MsgSrc
Photo
Sense
Temp
Sense
NullFwd16
TreeDispatch16
NullFwd16
TreeDispatch16
TimeSink
TimeSink
Network
Network
TreeBuilder
TreeBuilder
LinkEstimator
LinkEstimator
MsgSink
MsgSrc
MsgSink
MsgSrc
MsgSink
MsgSrc
MsgSink
MsgSrc
LinkEstimatorM
TreeBuilderM
TreeBuilderM
LinkEstimatorM
Network
Network
Network
Network
21
SNACK Compilation (3)
Post Compilation Merged Services
MsgSink
MsgSrc
TimeSrc
NullFwd16 1
TreeDispatch16 1
Sense 1
Temp
NullFwd16 2
TreeDispatch16 2
Sense 2
Photo
TreeBuilderM
TimeSink
LinkEstimatorM
Network

• contracts to a minimal, efficient program!

22
Compiler Algorithms Exhaustive Search

• Consider each possible sharing of instances
• Component type with n instances Bn sharings, Bn
  a Bell Number
• Our app 62 Main instances B62 4 x 1062
• Whole app has 20 types
• Need smallest (in total number of instances)
  valid sharing
• Order search by total number of instances, take
  first valid result

a1
a1
a2
a3
a3
a2
a1, a2, a3 A
a2
a1
a1
a2
a1
a3
a3
a3
a2
23
Compiler Algorithms Search Space Reduction

• Remember component subsets with no obvious
  problems
• When an invalid expansion is found, the search
  advances to the next expansion that might affect
  the problem
• The result found after 28 tests, not 1036 of the
  4x10113 possible

Fails because a1 and a2 are shared
Compiler skips to here
Increasingnumber ofinstances
a1, a2 A constraint a1 ? a2
Expansions that dont change sharing status of
A components
24
Performance Comparison

• Performance hypothesis
• Roughly same RAM allocation as a hand-crafted
  nesC application
• Less energy consumption in transmitting messages
• Compare SNACK and conventional nesC
• Surge Sample light and temperature, forward to
  root
• SnackForwarder, or SF same in SNACK
• SF-NoTransitive SF without transitive connections

25
ROM and RAM

• Application resource allocation (bytes)
• Snack Forwarder uses 30 more ROM than Surge,
  but 3 less RAM
• All values are well within the Mica2s operating
  constraints

26
Energy

• SF transmits considerably fewer bytes than Surge
  because of shared message paths
• SF-NoTransitive transmits about twice the bytes
  of SF

• Bytes transmitted indicator of energy consumed
• Simulation topologies from 4 to 49 nodes
• 100 duty cycle
• Worst case for SNACK

27
Related Work

• SNACK built atop nesC and TinyOS
• Units composition models
• Nesc, Knit, Flux OSKit
• OO composition models
• Click, Scout, x-kernel
• High-level abstractions
• Hood, Abstract Regions

28
Future Work

• Expand service library
• Write more applications
• Deploy application at James Reserve
• SNACK version of ESS
• Language Extensions
• Multi-binary application support
• passing services as parameters

29
Conclusions

• Language support for creating cooperating
  application services
• Application services designed to reduce energy
  consumption by sharing execution paths
• Compiler that generates applications with
• As few instances as possible
• For more information see
• http//lecs.cs.ucla.edu/ben/snack

30
Thank You