Nucleus Network Management System

1
Nucleus Network Management System

• Gilman Tolle
• UC Berkeley

2
Motivation

• TinyOS WSNs need visibility and testability
• Visibility
• Getting data out of a mote takes work
• Performance statistics and failure notifications
  are easily obtained -- within a motes boundaries
• Only critical data is ever sent out of the mote
• Testability
• TinyOS apps perform differently in the field
• Lab testing is not enough, but field testing is
  hard
• Interactively viewing health data in field is
  testing

3
Nucleus Overview

• Nucleus is an infrastructure that makes it easier
  for TinyOS developers to include visibility and
  testability in their own applications
• Infrastructure overcomes inertia
• Nucleus is simple, lightweight, and flexible
• Three easy pieces
• Parallel dissemination and collection layers
• Query system for exported attributes
• Logging system for asynchronous events

4
Drip Dissemination Layer

• Delivers queries and commands to network
• Replaces Bcast.nc
• Improvements over simple broadcast
• Epidemic reliability through retransmissions
• Fewer messages through neighborhood suppression
• Optional scoping node addr, TTL
• TinyOS interface
• event Receive.receive(msg, )
• event Drip.rebroadcastRequest(msg, )
• RAM 8 bytes per id

5
Drain Collection Layer

• Gathers query responses and log events
• Runs alongside applications collection layer
• Fully controllable from any host node
• No node zero problem
• Minimal RAM no neighbor table
• Uses RSSI or LQI for tree construction
• Fast tree construction and collapse
• TinyOS interface similar to standard
  collection
• RAM 28 bytes message queue

6
Attribute Export

• Components expose potentially interesting
  attributes to Nucleus query system
• e.g. activity counters, catalog data, status info
• Integer names for compact queries
• Auto-generated schema for host tools
• string names, sizes, and primitive types
• TinyOS interface
• command Attr.get(void buf)
• nesC 1.2 attribute tags generate wiring, build
  schema
• RAM symbols exported as pseudo-attributes
• Debugger-style access to RAM, over network

7
Nucleus Queries

• Simple and compact, single-message queries
• Core List of attributes
• Response delay, to control bandwidth usage
• Response destination (serial, local, tree, flash)
• Repeating or one-shot
• Queries can be injected over serial, local, Drip
• Compact single-message responses
• Pack all attribute values into one message
• Rely on receiver schema to decode it
• Use nonce to associate response with query
• RAM 3 bytes 33 bytes per concurrent query

8
Nucleus Event Logging

• Record a human-readable string and a set of data
  elements to flash, as a log
• e.g. Warning Volume 2 has only 928 bytes left
• Send a command to retrieve portions of the log
  over serial, local, collection tree
• Interface EL.log(ltstrgt, ltvargt, ltvargt, )
• Requires compile-time code generation
• no varargs in nesC, replace with pushes
• ltstrgt replaced by short integer in mote code
• Prototype used perlnesc, could be better
• RAM 40 bytes

9
Nucleus Status

• Drip is implemented beta/Drip
• Drain is implementedcontrib/nucleus/MultiHop
• Attributes, Query System, and Event Loggerformal
  release next month
• Alpha code in contrib/nucleus
• Unsupported prototype of entire Nucleus system
  beta/SystemCore
• Planned Nucleus front end web application