Nucleus Network Management System

Gilman Tolle

UC Berkeley

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 mote’s 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

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

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

Drain Collection Layer

Gathers query responses and log events Runs alongside application’s 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

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

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

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(<str>, <var>, <var>, …) Requires compile-time code generation

no varargs in nesC, replace with pushes <str> replaced by short integer in mote code

Prototype used perlnesc, could be better RAM: 40 bytes

Nucleus Status

Drip is implemented: beta/Drip Drain is implemented:contrib/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