1 / 7

Joe Polastre <polastre@cs.berkeley>

Building Real Applications How do we get people to use this stuff? How do we get industry actively involved?. Joe Polastre <polastre@cs.berkeley.edu>. Observations. CENTS Applications Robustness Simplicity Industry plays a vital role, not gov’t TinyOS

mwong
Download Presentation

Joe Polastre <polastre@cs.berkeley>

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. Building Real ApplicationsHow do we get people to use this stuff?How do we get industry actively involved? Joe Polastre <polastre@cs.berkeley.edu>

  2. Observations • CENTS • Applications • Robustness • Simplicity • Industry plays a vital role, not gov’t • TinyOS • Platform for building solutions for CENTS • But how do we build applications with it?

  3. Observations • Our applications are difficult • GDI, Redwoods, GGB • But the networking is not difficult… • Useful applications are not difficult! • David Gay’s Plant Watering System • Building Metering / AC Powered Networks • Asset Tracking • Monitoring Applications

  4. Development Roadblocks:Building Applications with TinyOS • Not commercial-grade • Not yet “Linux” for sensor networks • Students committing what they think people want – Very little industry participation • nesC static checks increase robustness • Interoperability • nesC provide network data structure • No protocol specifications  Incompatible Networks • Communication with an arbitrary TinyOS device? • Hard to use; not natural to program with • Components, Generic Components, Interfaces, Wiring • Most applications are simple • Don’t need complex protocols, code

  5. Proposal:TinyOS “Certified” Protocols • NOT a proposal to solve any WSN applications; only “simple” applications • A First Cut at Open Protocol Standards for WSNs? The following services: • Many-to-few routing • Any-to-Any (dissemination) • Any-to-Many (dissemination) • Management • Reprogramming • Low Power idle listening • All the building blocks are there! • Hood for network data management • Reliable Route + improvements • Trickle/Drip for “any-to-any” routing, Deluge for network programming • Low Power Listening / Idle Listening • SNMS

  6. Proposal:TinyOS “Certified” Protocols • All protocols are above the PHY protocol to promote evolution • No dependence on CC1000, 802.15.4, UWB, etc • Learn from internet protocols and their evolution • Design, Implement, and Publish protocols useful for sensor networks • Don’t just publish the ideas; publish the protocol format and explicit message exchanges • Make it easy to build compatible protocols • Basic Primitive: “Query protocol” to determine which services are running

  7. Effects and Next Steps • Effects of an Open Source/Open Standard Protocol Movement: • Gain commercial interest and involvement • Interoperability: same radio = let’s talk! • Developers write minimal TinyOS code • Simple, but powerful, applications are easy to build • Next Steps? • TinyOS Technology Exchange • TinyOS “Certified” Working Group

More Related