Design of an ApplicationCooperative Management System for Wireless Sensor Networks

1
Design of an Application-Cooperative Management
System for Wireless Sensor Networks

• Gilman TolleCENTS Research RetreatJanuary 13th
  2005

2
Introduction

• Micro-climate monitoring in the Sonoma redwood
  forest
• Deployed 80 wireless sensors
• 52 never joined the network
• 12 more died during the experiment
• The rest reported sporadically and filled up
• The real deployment challenge is not physical
  installation, but network administration

3
Visibility

• TinyOS has no visibility infrastructure
• Getting data out of a mote is hard
• Nodes produce much non-application data
• With no infrastructure, developers dont save it
• Infrastructure overcomes inertia
• Visibility infrastructure is needed
• Management tools enable information flow
• Developer Application Administrator

4
Field Testing

• TinyOS networks are rarely testable in field
• Test node presence
• Test network connectivity
• Test network performance
• Field testing runs at human timescale
• Very different from application timescale
• Field testing infrastructure is needed
• Management tools make testing possible

5
Problem Statement

• Visibility and testing are needed
• But, sensor networks are constrained
• WSN management must
• be simple
• occupy minimal resources
• cooperate with the application
• share minimal fate

6
Nucleus Architecture
Application and System Components
Memory
Attributes
Events
Sensor Network Management System
Data Exposure
Query System
EventLogging
Collection Protocol (Drain)
Dissemination Protocol (Drip)
7
Nucleus Architecture
Application and System Components
Memory
Attributes
Events
Sensor Network Management System
Data Exposure
Query System
EventLogging
Collection Protocol (Drain)
Dissemination Protocol (Drip)
8
Collection (Drain)

• Analogy thief
• get in quickly, from anywhere
• get what you want
• get out
• leave no trace
• A management collection layer must fit the
  interactive needs of people, not the long-term
  needs of the environment

9
Dissemination (Drip)

• Many pieces depend on dissemination
• Queries, commands, etc
• Must be fast
• Human timescale
• Must be resilient to network failure
• Dead nodes should not prevent dissemination
• Must be targetable
• Management is not only done in aggregate

10
Lightweight Layers

• Redundant network layers must occupy minimal
  network and node resources
• Drain does not keep a neighbor table
• Drip keeps small counters and metadata
• Future work will keep only one counter
• Both generate little traffic in steady state
• Collapsing tree and increasing timers

11
Nucleus Architecture
Application and System Components
Memory
Attributes
Events
Sensor Network Management System
Data Exposure
Query System
EventLogging
Collection Protocol (Drain)
Dissemination Protocol (Drip)
12
Query System

• Gives administrator access to
• identification
• metadata
• activity counters
• failure counters
• Access occurs on the admins schedule
• Developer decides whats possible
• Administrator decides whats interesting

13
Patterns of Data Exposure

• Hard Coded (MintRoute)
• Hand-crafted C structures carry data
• Data is given at fixed periods
• All modifications are compile-time
• All modifications break existing tools
• Query (Nucleus)
• Attributes are exposed and given names
• Queries select subset of attributes
• Data is returned, unpacked, processed

14
Data Exposure

• Encourage developer to expose rich data
• Two methods
• Named attributes
• Debugger access to RAM
• Attribute advantages
• Can be calculated at response time
• Can have meaning across multiple programs
• Debugger advantages
• Really easy

15
Data Queries

• Query is a list of named attributes
• Attributes named with short integers
• Mapping is generated to text names
• Query contains response delay
• Regulate network bandwidth
• Query can be one-shot or periodic
• One-shot is safer but more costly
• Periodic is cheaper but dangerous

16
Data Responses

• Competing against hand-crafted structures
• Attribute values are packed into buffer
• No overhead from sizes or delimiters
• Receiver must remember attributes and sizes
• Simple byte array values impose no restrictions
• Integers are as easy as structures

17
Resource Consumption

• Hard Coded
• Must always keep information
• Must always report information
• Must report all the information, all the time
• Query
• No additional RAM consumed per attribute
• Subset selectable at runtime
• Same cost to maintain attributes

18
Nucleus Architecture
Application and System Components
Memory
Attributes
Events
Sensor Network Management System
Data Exposure
Query System
EventLogging
Collection Protocol (Drain)
Dissemination Protocol (Drip)
19
Event Logging System

• Developers have rich failure data
• Every function call and every subsystem
• Failure data fails to leave the node
• If its not deadly, ignore it
• Queries are synchronous
• Data must be requested by administrator
• Events are asynchronous
• Can occur anytime and be read later

20
Programmer Interface

• Responding to failure is complicated
• Event logging should be easy
• Inspired by Internet-scale tools
• syslog, log4j
• Like printf(text d d,var1,var2)
• Events are defined inline
• Descriptive text and associated variables

21
Event Representation

• When compiling
• Strings replaced with short integer identifiers
• Mapping between them is auto-generated
• When event occurs
• Variables are copied sequentially into buffer
• Event is timestamped and tagged with identifier
• Event records are not self-describing

22
Event Access

• Events written to local permanent storage
• Future work developer and administrator
  cooperatively pick destination(local storage,
  collection tree, serial cable)
• Events retrieved with Drip command
• Like a management query
• Read position, delay, one-shot or periodic
• Future work select types of events to retrieve
• Events collected over Drain tree

23
Conclusion

• Small systems still contain rich data
• for testing, performance analysis, failure
  prediction, failure notification
• Nucleus Management Tool
• gives developers the ability to provide data
• gives administrators the ability to access it
• Management can use resources efficiently
• Improves deployment, debugging, study, and use of
  wireless sensor networks