1 / 9

Nucleus Network Management System

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

Download Presentation

Nucleus Network Management System

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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 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

  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 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

  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(<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

  9. 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

More Related