1 / 14

Sensor Coordination using Active Dataspaces

Sensor Coordination using Active Dataspaces. Steven Cheung NSF NOSS PI Meeting October 18, 2004. Outline. Motivation/Problem Characteristics of sensor networks Techniques for building sensor network applications Why sensor network programming hard? Need: High-level programming abstraction

jon
Download Presentation

Sensor Coordination using Active Dataspaces

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. Sensor Coordination using Active Dataspaces Steven Cheung NSF NOSS PI Meeting October 18, 2004

  2. Outline • Motivation/Problem • Characteristics of sensor networks • Techniques for building sensor network applications • Why sensor network programming hard? • Need: High-level programming abstraction • Our approach • Active dataspace (ADS) • Features of ADS • Tuples on demand • Example scenario • Vehicle detection: Setup • Event sequence: Bootstrapping • Event sequence: Detection phase

  3. Characteristics of sensor networks • Resource constraints • Energy reserve • Computation power • Memory • Unpredictable communication links • Intermittent connectivity • Asymmetric links and radio directionality • Node failure • Exposed to harsh environment and attacks • Battery depletion • Possibly large number of nodes • Possibly difficult deployment environment

  4. Techniques for building sensor network applications • General resource conservation • In-network processing • Localized algorithms • Hibernation (e.g., sentry service) • Optimizations for key communication patterns • Tree-based aggregation scheme (many-1) • Firecracker protocol (1-many) • Adaptive protocols • Protocols that adaptively optimize communication based on local information and feedback (e.g., directed diffusion and PARC’s CB-LRTA*) • Exploiting redundancy and broadcast medium

  5. Why sensor network programming hard? Deploying new or additional sensors Applications Intermittent end-to-end connectivity Limited CPU power and memory Hibernation Attacks Scalability Data aggregation Locality Sensor nodes

  6. Optimizing CPU & memory use Naming Deploying new or additional sensors Aggregation Security Intermittent end-to-end connectivity Scalability Locality Hibernation Need: High-level programming abstraction Applications Focus of this project Sensor nodes

  7. Active dataspace (ADS) • ADS is an active data repository that provides associative operations for data access • Inspired by the tuple space model [Gelernter 85], developed for parallel computing • Every data tuple (or record) contains a list of fields • Basic TS operations: • in is used to remove tuples from TS • rd to read tuples • out to create data tuples • eval to create “active” tuples

  8. Features of ADS • Data-centric model • Time-uncoupling: Data consumers and producers do not need to be active at the same time • Identity-uncoupling: Endpoints do not need to know each other’s identities • Stable network paths between endpoints need not exist • Virtual tuples support data generation on demand • Tuple set operator and cardinality constraint to facilitate in-network aggregation • Search constraint for specifying the scope and preferences for tuple selection to exploit locality

  9. Tuples on demand • Motivation: To enable sensor nodes to conserve energy and other resources during time intervals in which their work is not needed • A virtual tuple represents the capability of a node to generate a certain type of tuple specified by the virtual tuple • When a tuple request matches a virtual tuple, the corresponding node will be contacted to produce the data on demand • Use of virtual tuple is transparent to data consumers

  10. Vehicle detection: Setup • Sensors deployed in a region for vehicle detection • 2 types of sensor nodes • Type 1 (Sensors A, B, and C) : • Low-cost to operate • less accurate • has a shorter range • cannot classify vehicles • Type 2 (Sensor X): • Expensive to use • more accurate • have a longer range • can distinguish different classes of vehicles

  11. Event sequence: Bootstrapping • Sensors put virtual • tuples in ADS, which • represent their • detection capabilities • Sensor X hibernates • Sensors A, B, & C • take turn being active • (i.e., the sentry) B A outv(type1,?,{A,B,C}) C outv(type2,?,X) X

  12. 2 3 Event sequence: Detection phase (1) • A detects a vehicle • A requests other • type1 sensor data • ADS matches the • request with B’s and • C’s virtual tuples • B and C produce • sensor reading tuples • A confirms detection • with B’s and C’s input out(type1,+ve) 4 B A in(type1,?,≠A) outv(type1,?,{A,B,C}) C outv(type2,?,X) X

  13. Event sequence: Detection phase (2) • A requests type2 • sensor data • ADS matches the • request with X’s • virtual tuple • X is awaken for • vehicle detection B A 1 in(type2,?,≠A) 2 outv(type1,?,{A,B,C}) outv(type2,?,X) C X 3

  14. Expected results • High-level programming model and language to ease sensor network programming for a wide range of application domains • Architecture and techniques to implement a resource-efficient, adaptive, and trustworthy ADS system

More Related