Toward a Sensor Network Management Service

1
Toward a Sensor Network Management Service

• Gilman Tolle
• UC Berkeley

2
Why a SNMS?

• We currently have very little visibility into the
  functioning of our wireless sensor networks
• Every application designer implements mutually
  incompatible tools for understanding the status
  of the system
• If the application is working, then the network
  is working
• Goal 1 Create a set of core WSN management
  services to ensure constant visibility (the SNMS)
• Limited node resources have made designers
  unwilling to run services that do not directly
  support the application, like management
• Goal 2 Create services with a small footprint
  that can operate alongside every TinyOS
  application

3
Outline

• Overview
• Goals and Requirements
• ISO Network Management Model
• Planned Management Services
• Current Status
• Conclusions

4
Goal

• Create a set of core application-independent
  services to enable
• Node Reconfiguration and Control
• Periodic Managment Data Gathering
• Local Event Logging and Notification
• Supports Host Management Interfaces
• GUI
• Scripting (Matlab, Python, etc)
• UNIX Command-Line

5
Requirements

• These services will eventually be present
  alongside every TinyOS application
• Must be stable and dependable
• Must have a minimal RAM footprint
• Must create minimal network traffic when the
  network is healthy
• Must support zero-effort integration for basic
  functionality
• Must provide the option to take advantage of
  existing components
• Must be extensible enough to support management
  of new components

6
ISO Network Management Model

• Can inform the development of our own system
• 5-Part model for understanding the major
  functions of network management systems
• 1) Configuration Management
• Gather information
• Modify system configuration
• Examine effects of changing parameters on network
  operation
• 2) Performance Management
• Gather data on interesting variables
• Determine alert thresholds
• 3) Fault Management
• Detect, log, notify users, and fix network
  problems
• 4) Accounting Management
• 5) Security Management

7
Related IP Standards

• ICMP at the network level
• Specially marked messages for reporting network
  failure, and for active probing of connectivity
• SNMP at the individual device level
• ISO Configuration Performance Management
• Requests for values of system parameters
• Traps (alarms) are sent when parameters leave
  their normal range
• Vendor-Specific Network Management Systems
• IP management tools assume end-to-end
  connectivity
• This is not standard practice in WSNs
• Base our services on epidemic dissemination and
  collection

8
All TinyOS Components
Node Controls
Node Monitoring
Neighborhood Watch
Built-ins
Generated Marshalling Code
Get()
Register()
Register()
Set()
Log()
Health Query Processor
Event Logger and Notifier
Management
Control Dispatch
Flash Memory
Epidemic Dissemination
Minimal Converge-Cast Routing Layer
Non-Cached Flooding
Underlying
Sensor-Net Protocol
Dynamic Unmarshalling Layer
PC
Host Interface
Host Interface
Host Interface
9
Underlying Services

• Use cached epidemic dissemination to reliably
  reach any node
• Control and small data for reconfiguration
• Flood, Drip
• Bulk data for reprogramming
• Deluge
• Use converge-cast routing to retrieve information
• Use pre-existing routing layer
• MintRoute, ReliableRoute, BVR
• Create lightweight parallel layer
• MultiHopRSSI
• Use flash memory for persistent storage
• ByteEEPROM, Matchbox

10
Core Management Services

• Signal Reliable network-scoped commands
• Heartbeat Dynamic queries over internal
  component parameters
• Reflex Event notification and logging with
  runtime message composition

11
Node Reconfiguration Control

• Use epidemic dissemination service
• Components register values as changeable
• Change handlers translate value changes into
  changes in node operation
• Some values are synchronized with the whole
  network
• Some are set only on a single node
• Must be able to control basic node functionality
  with interactive commands
• Sleep/Wakeup
• Reboot
• Radio duty cycle
• Radio signal power
• Component-specific commands

12
Management Data Collection

• Technique Heartbeats
• Pro collects performance and configuration info
• Con constant traffic, even when network is
  healthy
• Current Approach
• Component designer lists heartbeat information
  and defines fixed packet format
• Changing the contents of the heartbeat requires
  recompilation, reinstallation, re-running of mig,
  and modification of host-side code
• Different heartbeats are incompatible
• SNMS Approach Management Queries

13
Managment Queries

• SNMS Management Queries
• Each component registers interesting parameters
  with a query processing component
• Preprocessing builds a list of names, keys, and
  formats for the host-side management tool
• Management tool disseminates list of keys and
  sample rate
• Query processing component dynamically formats
  single-packet responses by packing values that
  match keys
• Converge-cast or local broadcast used to return
  results
• Management tool unpacks and displays results
• TinyDB comparison fewer messages, less overhead,
  different focus

14
Interesting Query Parameters

• Configuration data
• Serial number
• Currently executing program identifiers
• uname data (platform, CPU, radio, sensors, ...)
• Component names, organization, settings
• Performance data
• Battery status and power consumption
• Real measured duty cycle
• Message traffic and radio utilization
• Queue lengths and MAC backoffs
• Available RAM, ROM, Flash memory
• Self-test results

15
Event Logging

• Technique Local Fault Detection
• Pro only produces traffic when a problem exists
• Con vulnerable to node or comms failure
• Current Approach
• Report events using dbg() in TOSSIM
• Develop ad-hoc event reporting messages to be
  flooded out to network
• No standard interchange formats
• SNMS Approach
• Structured Event Logging System

16
Event Logging

• Programmer interface will be similar to that of
  dbg() command, with format and values
• Preprocessor converts log() statements
• code that writes values to flash memory
• code that sends immediate multihop alerts
• Marshal values into packed log entry or message
• Unmarshal based on auto-assigned identifiers
• Tape interface for log retrieval
• play, pause, rewind
• Can store strings on host side and reinsert
  values, for human-readable log display

17
Dynamic Marshalling

• Needed to ensure compact data formats one
  parameter per message is wasteful
• Managment Query list of keys
• Query response packed list of values
• Unpacked based on known value sizes
• Log Event packed list of values
• TinyOS packing code generated by preprocessor
• Host-side unpacking information is extracted
• Compile-time assignment of identifiers to
  settable controls, gettable params, events
• Need to maintain separate schema file

18
Neighborhood Watch

• Based on the concept of process pairs
• Each node monitors a subset of neighbors through
  beacons and traffic snooping
• Tracks neighbor arrival, presence, and departure
• Sends events when neighborhood state changes
• Pros
• Less traffic when the network is normal
• Can report individual node failures
• Cons
• Intermittent connectivity can be confused with
  node failure, and cause neighbors to send
  spurious alarms
• Vulnerable to large-scale failures

19
Human Interface

• Current tools Surge
• Surge is an excellent tool for node-level
  information display
• Surge depends on specific message formats and
  specific TinyOS applications for data gathering
• Next step
• Build a query and management interface,
  integrating Surge as a display tool
• Ensure that other front-ends have enough hooks
  for query generation, event unpacking, etc.
• This SNMS must integrate with many other
  host-side tools Matlab, scripts, etc.

20
Other Services

• A set of core services encompasses more than
  management
• This system only focuses on the topics described
  above
• Network Reprogramming
• Deluge supports multiple program images, and this
  metadata must also be available for remote query
• Basic services should ensure that nodes are
  always remotely programmable, through use of a
  core image and a reboot system to execute it
• Calibration
• The calibration issue is specific to sensor
  networks, but is so central that it should be a
  part of the basic services
• Many open questions exist around developing a
  common calibration framework allowing for in situ
  tuning of parameters
• System Core
• Many other pieces may be installed as standard,
  but are not part of the management system per se

21
To-Do List

• Stabilize underlying services
• Design SNMS TinyOS component architecture
• Decide on command dispatch system
• Develop interaction APIs for query and events
• Define dynamic marshalling
• Create preprocessors and code generators
• Build basic top-level components
• Encourage developers of other TinyOS components
  to add management hooks

22
Conclusions

• A WSN management system
• would provide greater visibility into the
  behavior of our networks, while lightening the
  burden on application developers
• should be application-cooperative, assisting
  multiple components and taking advantage of
  services
• will eventually be part of a broader set of core
  services, to enable development of more advanced
  applications