SNMS

1
SNMS
Application-Cooperative Management for Wireless
Sensor Networks Gilman Tolle ltget_at_cs.berkeley.edugt
David Culler ltculler_at_cs.berkeley.edugt
Motivation

• Embedded sensor networks are naturally hidden
• Performance degradations and failures are
  common, and introspection can assist in
  troubleshooting
• Introspection is often omitted from
  applications, due to limited memory and
  bandwidth
• Can a lightweight system enable introspection
  by cooperating with sensor network applications?

SNMS gives applicationdevelopers
plug-and-playintrospection ability
Design
Implementation
Application System Components

• Minimal Resource Usage
• Divided into separate TinyOS components
• Core requires less than 300 bytes of RAM
• RAM usage depends on the statistics being kept
  as much as on the system
• Generates little network traffic when
  the network is not actively being managed
• Responds quickly during management
• Naming Debugger vs. Catalog
• Debugger-style local names require
  less coordination, but complicate management of
  heterogeneous systems
• Catalog-style global names provide a framework
  to contain different apps, but are rigid and
  become incomplete
• SNMS supports programmer-specified local names,
  and direct query of program symbols in RAM
• Components Already Monitored
• Task Scheduler
• Network Interfaces
• Persistent Storage
• Bootloader
• Query Processor
• Event Log Processor

Events
Variables
Sensor Network Management System
VariableQuery Processor
Event Logger
Names Descriptors
Collection Dissemination Protocols

• Resource Discovery
• Tools gather names, addresses, and types
  of reachable nodes in a multihop network
• Tools continually watch for node failure
  or network disconnection, in real-time
• Performance Monitoring
• Programmer uses nesC wiring to export counters
  and statistics that aid in understanding system
  performance
• User can remotely select variables to watch
• Tools display data for human interpretation
• Fault Awareness
• Programmer records interesting application events
  to local persistent storage, using a
  printf-style interface
• Users remotely retrieve event logs, in
  real-time or after some delay
• Tools display events as human-readable text
• Resource Control
• User controls sleep, wake, and reboot for a
  network, or for individual nodes
• Redundant Networking
• Programmer can choose to use a
  lightweight parallel collection and
  dissemination layer, for reliability and to
  lessen fate-sharing

Future Work

• Integrated global and local naming
• In-network variable summarization
• Collection of list-structured variables
• per-neighbor link statistics
• per-task cpu time
• per-program image metadata
• Controlling and querying groups of nodes
• Configuration Management
• Modifiable catalog of system parameters
• User/programmer studies of effectiveness