SNACK Sensor Network Application Construction Kit otherwise known as TinyMeal

1
SNACK Sensor Network Application Construction
Kit(otherwise known as TinyMeal)

• Ben Greenstein
• Eddie Kohler
• Deborah Estrin
• CENS Technical Seminar
• January 9, 2004

TinyOS work with David Culler at Intel Research,
Berkeley
Name courtesy of Tom Schoellhammer
2
Goals of SNACK

• Make it easy for scientists (i.e.,
  non-programmers) to rapidly develop efficient
  sensor network applications
• Write a library of components and a configuration
  language that are
• Easy to use for both non-programmers and
  experienced systems developers
• Expressive but not cluttered
• Construct a compiler that
• Optimizes a configuration to produce an efficient
  implementation

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

4
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

5
Component Autonomy

• Principle
• Components should function irrespective of what
  is using them
• Consequence
• Timers in more components than need to be
• Examples
• Larger footprint
• Handlers everywhere
• Actions that should be temporally coupled are not

6
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

7
Not to mention

• Scheduling restrictions
• Split-phase operations
• Poor data passing semantics
• Restrictions on using the usual things we use to
  develop applications
• Preprocessing directives
• Header files

8
Solutions within TinyOS
9
A timer eliminator MinRate

• Collapses the timers into one timer event
• Generates packets at a minimum rate
• Drives soft state mechanisms of various services
• Advantages
• Fewer timers
• Fewer header bytes sent
• Reduced duplication of attributes
• Issues of soft state
• Soft state can drown a network, particularly in
  TOSSIM
• Eventual consistency isnt always timely

MinRate
SpanningStamp
DelaunayStamp
LocationStamp
SourceStamp
AM
10
Tag/length/value packet format

• Add as many attributes as needed or as can fit in
  data portion of TOS_Msg structure
• Limited to 8 different types of attributes in
  system
• Constant time inserts, tests for inclusion,
  linear reads
• putAttr() and getAttr() provided as inline for
  write and read
• Byte 0 of data portion contains bit field for
  test
• 1c bytes of overhead for c attributes

See also Robert Braden, Ted Faber, and Mark
Handley, From Protocol Stack to Protocol Heap -
Role-Based Architecture, Proceedings of the
First Workshop on Hot Topics in Networking
(Hotnets-I), ACM SIGCOMM, Princeton, NJ (October
2002).
11
TOS_Msg memory manager

• Sits directly above the AM layer
• Buffer Pool
• Buffer allocation and guards handled in memory
  layer instead of in every component
• alloc(), free(), copyAlloc()
• Implicit Deallocation
• When SendMsg.send () fails and immediately after
  upcalls to SendMsg.sendDone() and
  ReceiveMsg.receive()
• Queued Send absorbs bursts (thanks, Phil B.)

12
An application constructed with these
enhancements

• A fire is localized to one square meter in a
  meadow. It is probably a campfire, so do nothing

• A fire has grown larger locate any sprinklers
  nearby and turn them on. If there are no
  sprinklers, alert a human

13
The app architecture
Sink
Sampler

CombineCache
CombineStamp

MinRate

SpanningCache
SpanningStamp

DelaunayCache
DelaunayStamp
LocationStamp
LocationCache

SourceCache
SourceStamp
AM
InverseNeighbhood
uses BufferPool
14
So how should it be done?

• Easy
• Programming, debugging
• Extensible
• Component additions, Inheritance
• Familiar
• Learning curve not too steep
• Reusable
• Efficient

15
Users plug services together

• Component software can be snapped together by
  non-programmers to achieve a desired
  functionality
• Without removing flexibility for experts
• Therefore, lots of default behavior
• Building an application, then, requires only to
  learn a configuration language

16
Efficiency not sacrificed

• Weave services together into an efficient
  implementation
• If two services within an application each use a
  component that could be shared, instantiate only
  once and connect to both services
• Provide compiler support for optimizing the
  merging of services
• Write the core services in a powerful and
  standard language

17
Example a sum aggregator

• class SumAggregator32 public Component, public
  Uint32Receiver
• public
• SumAggregator32()
• virtual bool recv(int intstance, uint32_t m)
• void set_acc_target(NodeStore32Access r, int
  i)
• _accTarget r, _accTargetInstance i
• protected
• uint32_t getSum()
• uint32_t _lastSum
• // Variables for calling the push and access
  targets
• Uint32Receiver _pushTarget
• int _pushTargetInstance
• NodeStore32Access _accTarget
• int _accTargetInstance

18
Configuration language

• Flexible wiring environment
• Declarations
• Named instances of components
• E.g. mMinRate(period 100ms)
• Associative array of named parameter types
• E.g., MinRate(period 100ms)
• Wirings
• Connection of components via their interfaces
• Flexibility in specification
• Access rules (how components can be shared)

19
Flexible wiring

• The arrow operator (-gt) connects two components
• TreeRootsignal-gtstartMinRate
• The transitive arrow operator (..gt) establishes a
  precedence relation
• NetworkMsgReceiver..gtExtractor16(type
  TREEHOPS)
• Tokens in brackets , denote interfaces
• Tokens outside of brackets denote components
• Specified interfaces and components can be types
  or instances

20
Design methodology

• Configuration methodology
• Macrocompiler tasks

21
Separate functionality

• Components should be small, but not artificially
  so. Each should serve a specific purpose, but
  should be general enough to be reused
• Examples NodeStore8, MinRate, Stamp8, SendQueue

routingTablehopsAccess-gtAccess8
NodeStore8 TreeRootsignal-gtstart MinRate
(period 300000ms)MsgReceiver ..gt Stamp8
(type TREEHOPS)..gt SendQueue ..gtNetwork
22
Provide component flexibility

• If you don't care which instance of a component
  is used, you don't need to specify an instance
• Examples Network, SendQueue

TreeRootsignal-gtstart MinRate (period
300000ms)MsgReceiver ..gt Stamp8 (type
TREEHOPS)..gt SendQueue ..gt Network
23
Constrain component flexibility

• If you don't care what instance is used, but do
  care about the initialization of whatever is
  used, you can specify a type with an
  initialization
• Use associative array to expose initialization to
  macrocompiler
• Allow parameter bounds instead of constants
• Example

TreeRootsignal -gtstart MinRate (period lt
300000ms)MsgReceiver ..gt Stamp8 (type
TREEHOPS)..gt SendQueue ..gt Network
24
Provide interface flexibility

• If you don't care about the outgoing port or
  incoming port for an interface, you don't need to
  specify instances
• Should not require interface specification if
  same as preceding interfaces specification
• Example MsgReceiver

TreeRootsignal -gtstart MinRate (period
300000ms)MsgReceiver ..gt Stamp8 (type
TREEHOPS)..gt SendQueue ..gt Network
MsgReceiver
25
Example link quality estimation

• lqeStoreNodeStore32()
• lqeStampPullStampBlob(type LQE)
• NetworkMsgReceiver..gtExtractorBlob(type
  LQE)pushGeneric
• -gthoodLinkEstimateLQE
• NetworkMsgReceiver..gtExtractor16(type
  SRCID)push16-gtidLQE
• NetworkMsgReceiver..gtExtractor16(type
  SEQNO)push16-gtseqLQE
• LQEtoAccess-gthighAccess16lqeStore
• LQEfromAccess-gtlowAccess16lqeStore
• lqeStamppullGeneric-gtstatsBlobLQE
• MinRate(period 100000ms)MsgReceiver..gtlqeStamp
  ..gtSendQueue..gtNetwork

26
Design methodology

• Configuration methodology
• Macrocompiler tasks

27
Syntax and semantics check

• Component names are valid
• Interface names are valid
• Component instances are declared
• Wiring uses , , -gt, and ..gt lexemes correctly

28
Precedence graph generation

• The compiler looks at precedence relationships
  and builds a single graph
• It replaces ..gt with -gt

29
Compiler instantiation

• Takes a component wiring and determines how
  instances of each component need to be created
• How many instances?
• What initialization parameters?
• Example MinRate(period 300000ms)minrate_1_
  MinRate(period 300000ms)
• _treeroot_1_ signal
• -gtstart _minrate_1_ msgReceiver -gtmsgRecei
  ver _stamp8_1_ msgReceiver
• -gtmsgReceiver _sendqueue_1_ msgReceiver
• -gtmsgReceiver _network_1_

30
Component Sharing

• Looks for components that can be shared
• ExampleSerives A and B are part of an
  applicationService A needs a NodeStore32(type
  LQE)Service B needs a NodeStore32(type
  LQE)Application get a single NodeStore32(type
  LQE)

31
Semi-constrained initializations

• Components with compatible semi-constrained
  initializations are shared
• ExampleSemi-constrained declarationsMinRate1(
  period lt 1000ms) MinRate2(period lt 500ms)
• Become
• minRate(period 500ms)

32
Efficient Supersets

• The compiler looks for single components that can
  replace sets of components to make things more
  efficient.
• Example Extractor1616 replaces two
  Extractor16's.

33
Code generation

• The compiler generates a C main file and a
  Makefile given the resulting wiring
• Example MinRate _minrate_2__minrate_2_msgRece
  iver-gtlqeStamp
• becomesMinRate _minrate_2__minrate_2_.init(1
  00000)_minrate_2_.set_msg_target(lqeStamp)_min
  rate_2.start()

34
Concluding Remarks

• Work in progress
• Around 20 components written
• A compiler that takes a wiring and produces a C
  instantiation
• Most of the optimization work is ongoing

35
The End