A Group Programming Architecture for MultiFunctionality Wireless Sensor Networks

1
A Group Programming Architecture for
Multi-Functionality Wireless Sensor Networks

• Vartika Bhandari (UIUC)
• Loren J. Rittle (Motorola Labs)

2
Motivation

• General-purpose sensor network deployment
• Multiple concurrent applications may exist
• Applications executed by potentially overlapping
  groups of nodes
• Desirable to have ability to remotely program and
  manage functionality

We describe an early design experience in
developing a system to remotely program and
manage functionality
3
Example
A
B
Gateway point of injection of commands/code
GW
C
Sensor Network
4
This work

• Initial design toward programming of
  multi-functionality WSNs
• Provides a basic framework for
• Flexible executor-set specification
• Semi-autonomous member-selection
• Efficient code-propagation
• Some design aspects from this work form the basis
  of the Group Establishment and Management System
  in the MuSE middleware developed at Motorola Labs

5
System Assumptions

• Virtual Machine based architecture
• Derived from the Mate/Bombilla VM Levis et al.
• ZigBee-based network layer
• Default routing based on a logical-tree structure

6
Group Paradigm

• Notion of groups (akin to multicast)
• Groupcollective responsibility to perform task A
  over some time period
• Groups identified by (gid, seqno) signature
• gid re-usable seqno helps distinguish different
  instantiations

7
Group Paradigm

• Abstraction of an application and its
  executor-set
• Gateway can issue commands/code by just
  specifying the (gid, seqno) signature
• Allows for evolving functionality by multiple
  re-programmings of same set of nodes

8
Group Membership Specification

• Two-part specification (p, q)
• p predicate
• Necessary condition
• q quantifier
• Auxiliary condition

Goal Not to tie down (p, q) to some
pre-specified attribute-set or code-book!
9
Membership Specification

• (p, q) specified as bytecode capsules returning
  boolean result
• Can be any criterion expressible as VM-executable
  bytecode sequence
• Result (T, T) group member
• else non-member

10
Optimized Code Propagation

• ZigBee tree based propagation
• Pruning aka multicast
• Nodes maintain meta-data regarding group
  membership in their subtree
• Re-propagate code only if non-zero membership
  amongst descendents

11
Two Phase Programming Protocol

• Phase 1 Group Instantiation
• GW injects SIGNAL packet with (p, q) definition
  for group instance (gid, seqno)
• SIGNAL propagates in network each node makes
  local decision on membership status
• Phase 2 Code Propagation
• Gateway injects CODE packet(s)
• Only members install the code
• Optimized propagation if possible
• May occur multiple times (if associated
  functionality needs to change)

12
Programming Protocol

• Uses sequence number and code version number for
  stale/duplicate detection
• Leverages ZigBee tree maintenance procedures for
  meta-data exchanges via piggybacking of data

13
Protocol Operation
Gateway
SIGNAL sent
CODE sent
Metadata collection occurs via periodic beacons
Lmax
Simplified View of a ZigBee Tree Hierarchy
14
Protocol Operation Major Aspects
From parent path for SIGNAL/CODE
To/From Neighbor
To/From Neighbor Meta-data potential redundant
paths for SIGNAL/CODE packets
To child re-propagate SIGNAL/CODE
From child meta-data
15
System Architecture
Group Programming Subsystem
Capsule Manager
Predicate/Quantifier
Membership Filter
Membership Decider
Meta-data Maintainer
Other VM Contexts
Once Context
Mate VM Architecture/Execution Model
Result
Byte-code Interpreter
Periodic payload sent/recvd
Received Code
ZigBee-like Network Layer
Simplified View of System Architecture showing
Logical Separation of Functionality
16
Test Implementation

• TinyOS/TOSSIM Bombilla VM
• Implemented a thin ZigBee-like network layer with
  logical tree based addressing/routing
• Implemented major features of architecture
• TOSSIM simulations were promising

17
Further Possibilities

• Fault Tolerance
• Ternary State associated with membership decision
• (T, T) member
• (T, F) potential member
• (F, F) non-member
• A member node running out of battery may pass on
  functionality to a potential member in its
  vicinity

18
Further Possibilities

• Suspended Predicates
• Group membership definition resides at nodes
• Event-triggered membership decision
• Semi-autonomous group instantiation requires no
  immediate intervention by gateway

19
Conclusion

• Group programming paradigm
• Provides an easy-to-use abstraction at gateway
• Leverages VM for flexible group specification
• Provides framework for inclusion of more advanced
  self-organizing capabilities

20
Thank You