Nucleus Network Management System Gilman Tolle UC Berkeley.
-
Upload
cody-maldonado -
Category
Documents
-
view
215 -
download
1
Transcript of Nucleus Network Management System Gilman Tolle UC Berkeley.
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