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(,,, …) Requires compile-time code generation no varargs in nesC, replace with pushes 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 implemented: contrib/nucleus/MultiHop Attributes, Query System, and Event Logger formal release next month Alpha code in contrib/nucleus Unsupported prototype of entire Nucleus system beta/SystemCore Planned Nucleus front end – web application