1 / 10

Creating an Architecture for Wireless Sensor Networks – in a nutshell

This article provides a concise overview of creating an architecture for wireless sensor networks, including design principles, programming and protocol architectures, and system support. It also explores the areas of work and cross-layer issues in sensor network architecture.

clord
Download Presentation

Creating an Architecture for Wireless Sensor Networks – in a nutshell

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. Creating an Architecture for Wireless Sensor Networks – in a nutshell David Culler, Scott Shenker, Ion Stoica Electrical Engineering and Computer Sciences University of California, Berkeley NETS/NOSS Infosession

  2. Sensor Network Networking Today Appln EnviroTrack Hood TinyDB Regions FTSP Dir.Diffusion SPIN Transport TTDD Trickle Deluge Drip MMRP Arrive Routing TORA Ascent MintRoute CGSR AODV GPSR DSR ARA GSR GRAD DBF DSDV TBRPF Scheduling Resynch SPAN GAF FPS ReORg Topology PC Yao SMAC WooMac PAMAS BMAC TMAC WiseMAC Link Pico 802.15.4 Bluetooth Phy eyes RadioMetrix CC1000 nordic RFM NETS NOSS

  3. The “Internet Architecture” • End-to-end flows • Pt-to-pt dominantly • Many applications sharing the network • Over best effort packet delivery service • Opaque, universal routing service • Agnostic to physical link and application characteristics • Radical simplification of a really hard problem • Efficiency cost • Quality cost application transport IP network link physical NETS NOSS

  4. Env. Monitoring Active Environments Detection/Alarm Tracking Structures Distr. Control What role a “sensor net architecture”? • Wide range of long-lived applications • Diverse, constrained, evolving resources • Low duty cycle • Small tables • Loss, noise & change • Embedded in & adapting to phy. env. • In-network processing, not E2E • Highly application specific • WSN needs a “narrow waist” • Few applications over many nodes NETS NOSS

  5. Pt-Pt Routing 1-1 Neighborhood Sharing 1-k / k-1 Aggregation N --- 1 Data Collection N-1 Robust Dissemination 1-N Rich Common Link Interface (SP) Multiple Link and Physical Layers IEEE 802.15.4 *** CC1000 infneon BlueTooth ??? Emerging view of sensor networking Applications Compose what they need Tracking Application Sensing Application Multiple Network Layer Protocols NETS NOSS

  6. Six Aspects of a Sensor Network Arch. • Design Principles • Guidelines and constraints, what functionality, what state • To what are we agnostic • Functional Architecture • Logical building blocks/protocols, interfaces, interconnections, interdependencies • Programming Architecture • API/ISA – what logical data types and operations are expressible • Protocol Architecture • Distributed algorithms to provide each component service, defn. of the information exchanged between instances • Most existing work is of this form • System Support Architecture • Capabilities of the node to support the network arch. • Physical Architecture • Set of nodes, interconnects, communication fabrics upon which network is constructed NETS NOSS

  7. Areas of Work • Physical Architecture • Multitier, non-homogeneous (patches, transit, internet) • SNA should not require unconstrained nodes • Should utilize unconstrained nodes to reduce burden on constrained ones • Mobility within physically embedded context • Programming Architecture • SNA will define consistent interfaces that encompass seven communication abstractions underlying range of programming models • Dissemination • Collection • Aggregation • Localized Neighborhood • Point-to-point • Data-centric storage • Attribute-based routing • Functional Architecture • Protocol Architecture • System Support Architecture • Design Principles NETS NOSS

  8. Areas of Work (2) • Physical Architecture • Programming Architecture • Functional Architecture • Thin-waist as expressive interface to best-effort 1-hop broadcast - SP • implement over a range of links, utilize by a range of network protocols • Higher level optimization within control & info exposed by SP • Protocol Architecture • address-free protocols over SP, focusing on general, yet efficient techniques for defining forwarding predicate and reusable mech. For duplicate detection, suppression, and transmission scheduling • Name based: simple set of primitives at SP layer that allow network layer services to dictate and use naming schemes • Discovery, formation, maintenance, forwarding • Application-independent portions support sharing of partner networks • In-network storage: provide soft-state abstraction as building-block for variety of address-free and name-based network protocols • active in-network storage: identify minimalist actions that are flexible enough to higher levels to express meaningful predicates and queries • System Support Architecture • Design Principles NETS NOSS

  9. Areas of Work (3) • Physical Architecture • Programming Architecture • Functional Architecture • Protocol Architecture • Key cross-layer issues: discovery, time coordination, power management, network management security • Focus on cooperative interfaces • System Support Architecture • SNA independent of particular OS, but implemented on one • extend TinyOS to better support SNA processing • Encapsulation, Buffer management, Robustness, Scheduling • Design Principles • Initial set guide the SP approach • Refined through the process NETS NOSS

  10. Goal: Open, Interactive Community Process • Push-and-pull • Actively pull in components developed by the community • Actively push out the framework • Interactive dialog on both • Community Workshops – early and often • First one ~march 04 • Initial framework for feedback on direction • Establish key collaboration participants in sub-areas • Annual follow-ons • Experience, feedback, planning, prioritize, next steps • Winnowing process for interfaces, components • Network stack(s) openly available to entire program at all times • On testbeds as they emerge • Series of course materials • Intend to be shared and circulated NETS NOSS

More Related