Download
1 / 9
90 likes | 209 Views
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
E N D
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
