towards a holistic approach for system design in sensor networks l.
Skip this Video
Loading SlideShow in 5 Seconds..
Towards A Holistic Approach for System Design in Sensor Networks PowerPoint Presentation
Download Presentation
Towards A Holistic Approach for System Design in Sensor Networks

Loading in 2 Seconds...

play fullscreen
1 / 70

Towards A Holistic Approach for System Design in Sensor Networks - PowerPoint PPT Presentation

  • Uploaded on

Towards A Holistic Approach for System Design in Sensor Networks. Chair: Prof. Nael Abu-Ghazaleh Committee Members: Prof. Kenneth Chiu Dr. Tony Fountain Prof. Wendi Heinzelman Prof. Kyoung-Don Kang Prof. Michael Lewis . Sameer Tilak. Outline.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Towards A Holistic Approach for System Design in Sensor Networks' - bernad

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
towards a holistic approach for system design in sensor networks
Towards A Holistic Approach for System Design in Sensor Networks

Chair: Prof. Nael Abu-Ghazaleh

Committee Members: Prof. Kenneth Chiu

Dr. Tony Fountain

Prof. Wendi Heinzelman

Prof. Kyoung-Don Kang

Prof. Michael Lewis

Sameer Tilak

  • WSN Applications and Challenges
  • Summary of Contributions
  • Holistic Principle
  • WSN critical Subsystems and Services
  • Holistic Framework Architecture
  • Abstractions and Virtualization
  • Conclusion and Future Work
enablers micro sensors
Enablers – Micro-sensors
  • Small (coin->matchbox->PDA range)
  • Limited resources
    • Battery operated
    • Embedded processor (8-bit to PDA-class processor)
    • Memory: Kbytes—Mbytes range
    • Radio: (Kbps – Mbps; often small range)
    • Storage (none to a few Mbits)

Sensor Network Applications

Disaster Response

Embed numerous distributed devices to monitor and interact with physical world: hospitals, homes, vehicles, and “the environment”

Network these devices so that they can coordinate to perform higher-level tasks.

Requires robust distributed systemsof hundreds or thousands of devices.

sensor node specific challenges
Sensor Node Specific Challenges
  • Low Battery power
  • Low bandwidth
  • Error-prone air medium
  • Low computing power and memory
  • Heterogeneous software and Hardware architectures
sensor network challenges
Sensor Network Challenges
  • Large-scale fine-grained heterogeneous sensing
    • 100s to 1000s of nodes providing high resolution
    • Spaced a few feet to 10s of meters apart
  • Collaborative
    • Each sensor has a limited view
      • Spatially
      • In terms of sensed data type
  • Distributed
    • Communication is expensive
    • Localized decisions and data fusion necessary
summary of contributions
Summary of Contributions
  • WSN critical subsystems and services
    • Information dissemination
    • Storage Management
    • Localization
  • Holistic Framework
  • Abstraction and virtualization
holistic principle
Holistic Principle
  • Data centric, resource constrained operation
    • effective operation requires careful balancing of application level utility and cost  (Principle 1) 
  •  Communication is expensive
    • Localized interactions -- produce local estimates of utility and cost (Principle 2)
  • Local estimates of application level utility and cost can significantly differ from actual value observed globally
    • Information available globally that significantly impacts local estimates are called context
    • Identify and track context when it is worth it to do so (Principle 3)
wsn critical subsystems services
WSN Critical Subsystems/Services

Non-Uniform Information Dissemination

ICNP 2003, NCA 2004, NCA 2005, TR

non uniform information dissemination
Non-Uniform Information Dissemination

Loss in precision as a function of distance is acceptable

  • Forward packets less aggressively the further away you are from the event
    • deterministically: e.g., forward every nth packet, n increase with distance
    • probabilistically: e.g., forward packets with a probability thatdrops with distance from event
  • Here, the context is spatial and can be efficiently tracked by tracking the distance from the source on the event packet
  • Significant energy saving results, while keeping information accurate close to the event source
randomized protocols
Randomized Protocols

Biased protocol:

  • Packet forwarding decisions are based on a coin toss and relative distance from source.
  • Forwarding probability is higher for physically closer sources. (Context)
  • Simple, low overhead and very scalable
high level concluding remarks
High-level concluding remarks
  • Energy-efficient light-weight protocols that capitalize on non-uniform information granularity
  • Context embedded in the form of TTL (distance from an event source).
wsn critical subsystems services15
WSN Critical Subsystems/Services

Storage Management

IJAHUC 2005, Wiley Book chapter 2005, TR

  • Exploit spatio-temporal redundancy
  • Coordinate for redundancy control
  • Context is Spatial
candidate protocols
Candidate Protocols
  • Local Storage
    • Local-Buffer
  • Clustering
    • CBCS: Aggregate and Store and Cluster Head
  • Context:
    • CLS: Coordinate and store locally
    • CCS: Combined CBCS + CLS

Round 1 (time = 0)

Round 2 (time = 20)

  • Only CH stores data
  • Rotate CH
  • Distributed storage, medium fault-tolerance
  • Spatial aggregation possible

Round 1 (time = 40)




CH has more global view than individual sensor




Round 1 (time = 0)

Feedback provides context for data utility

Round 1 (time = 40)

high level concluding remarks21
High-level concluding remarks
  • Collaborative protocols are scalable, light-weight, does load balancing and increase storage lifetime
  • Context provided in terms of feedback for redundancy control
  • Context in space

WSN Critical Subsystems/Services



mobile sensor localization
Mobile Sensor Localization
  • Localization: Determine physical coordinates of a given sensor
  • Existing research considers static sensor nets.
  • Mobile sensors
  • Energy versus accuracy trade-offs
  • Protocols
    • SFR (Static Fixed Rate)
    • DVM (Dynamic Velocity Monotonic)
    • MADRD (Mobility Aware Dead Reckoning Driven)
existing research on localization
Existing Research on Localization
  • Assumes Static Sensor Network
  • Focus on How to Carry Localization and not When
  • Range/Direction Based
    • Calculate distance from anchors and triangulate
        • Received Signal Strength (e.g. RADAR)
        • Time of Arrival (e.g. GPS)
        • Time Difference of Arrival (Cricket, Bat)
        • ProximityBased
          • Centroid
          • ATIP
          • DV HOPS
          • MDS


What about Mobile Sensor Networks ?

Interesting Energy-Accuracy trade off !

  • Localize every t seconds
  • Very simple to implement
  • Once Localize tag data with those coordinates till next localization
  • Energy expenditure independent of Mobility
  • Performance varies with Mobility
  • Existing Projects such as Zebranet use this approach (3 minutes).
  • Adaptive Protocol
  • Sensor Adapts its localization frequency to Mobility
  • Goal maintain error under application-specific tolerance
  • Compute current velocity and use it to decide next localization period
  • Once Localize tag data with those coordinates till next localization
  • Upper and Lower query threshold
  • Energy expenditure varies with Mobility
  • Performance almost invariant of Mobility
  • Predictive Protocol
  • Estimate mobility pattern and use it to predict future localization
  • Localization triggered when actual mobility and predicted mobility differs by application-specific tolerance
  • Tag data with predicted coordinates (differs from SFR and DVM)
  • Changes in mobility model affect the performance
  • Upper and Lower query threshold
  • Energy expenditure varies with Mobility
  • Performance almost invariant of Mobility
high level summary of analysis
High-level Summary of Analysis
  • Error in non-predictive protocols increase with any mobility that moves the node away from its last localization point
  • Error in Predictive protocols increase only when the predictive
  • Model is inaccurate
      • Model estimation in incorrect
      • Model changes (pause, direction change)
  • Studied energy versus accuracy tradeoff in localization for mobile sensors
  • DVM and MARD are completely

distributed scalable protocols

  • DVM and MADRD outperform SFR
  • Context Temporal



Data Samples

Local utility estimate

Resource Management

  • Non-Local resources
  • Data utility
  • (Principle 3)




Local Resources


Principle 1

Operation Management

Principle 2

Initial Idea

  • Localized decisions leads to scalability
  • Local estimate of utility of data can differ from global measurement
    • Absence of relevant global knowledge: Context
    • Feedback can be used to improve accuracy of local estimate
patterns types context
Patterns & Types Context
  • Patterns
    • Context in time
    • Context in space
    • Application-specific (domain knowledge)
    • Resource related (src-dest path)
  • Types
    • Utility context
    • Cost context
research challenges
Research Challenges
  • Data Utility Assessment
  • Resource Cost Assignment
  • Utility-Cost Normalization
  • Tracking, Building, and Maintaining Context
  • Middleware
holistic framework components
Holistic Framework Components
  • Benefit Estimator
  • Cost Calculator
  • Planner
benefit estimator
Benefit Estimator
  • Data Significance
    • Data scope in Time, Space
    • App-specific (observer interest)
  • Data Quality
    • Data Freshness, accuracy, resolution,
    • App-specific measures
  • Output Benefit Vector (BV)
  • MAUT
cost calculator
Cost Calculator
  • Sensing, Transmission, Storage, Computational, Reception.
  • Output Cost Vector (CV): Vector of pre-determined transformations
  • MAUT
  • Rule based engine.
  • Input BV, CV
  • Incorporates application state
  • Objective: Maximize Benefit/Cost ratio
instance of a planner algorithm
Instance of a Planner Algorithm

IF (Utility == HIGH)





If (Utility == MEDIUM)


If (Utility == MEDIUM)

Low drop.

component placement trade offs
Component Placement Trade-offs
  • Middleware versus Application
    • Benefit Estimator?
      • Application-specific knowledge
    • Cost Calculator?
      • App/infrastructure communication
      • Resource cost in middleware
    • Planner?
      • Single versus multiple apps


EESR 2005

related work
Related Work
  • Database Abstraction
  • Programming abstractions e.g. Nesc
  • TinyOS
  • Plan-9, Inferno
file system abstraction
File System Abstraction
  • Treat entire sensor network as a distributed file system
  • Application-specific namespaces
  • Well understood interface
  • Heterogeneity
  • Applications get fine grained control over resources

Application-specific Namespaces

Making Abstractions efficient

Default resource namespace

  • Monitoring and Calibration
  • Debugging
  • Sense & Respond
  • Data Centric Application etc.

Sample Usages

mount /dev/network /network

ls /network/cluster1/sensors/

cat /network/cluster1/s1/remaining-energy

echo 2.5 > /network/cluster1/s1/control


Query Execution Scenario

query /network/cluster1/Location

  • Fine-grained resource control
  • Exposes cost and utility explicitly
  • Optimized query planner (Below DB)
abstraction virtualization
Abstraction & Virtualization

WSN Virtualization

NCUS 2005

micro sensor hardware
Micro-sensor Hardware
  • Berkeley Motes (Mica2)
  • Pasta nodes
  • Mantis-nymph
  • WINS
software architectures
Software Architectures
  • Operating Systems
    • TinyOS
    • Linux
    • Windows CE
    • MOS
  • Programming Languages
    • C
    • nesC
    • JAVA
motivation for resource discovery middleware
Motivation for Resource Discovery Middleware
  • Mobile and Ad-Hoc sensor networks
    • Rescue operations
    • Battlefield scenarios
  • Seamless Integrating of sensors to Grids
  • Sensors control, configuration (remote)
mobile sensor network
Mobile Sensor Network
  • Ad-Hoc Network
  • Self-Configuration
service discovery protocols
Service Discovery Protocols
  • Scalable to thousands to sensors
  • Energy-efficient
  • Standardization
  • Design Space
    • Proactive versus reactive
    • Distributed versus centralized
    • Tuned for Sensor network characteristics
      • Minimize Transmission and reception of messages
      • Sensors have low duty cycle radios
our approach
Our Approach


Resource registry

Register Message

Query Message

Resource Info. message

xml versus proprietary format
XML versus proprietary format

<id>10</id> 10

<precision>100</precision> 100

<minrange>-40</minrange> -40

<maxrange>100</maxrange> 100

<capacity>-1</capacity> -1

Describing resource in XML consumes 10 times more power than proprietary binary message

  • Application-specific, light-weight, energy-efficient protocols for critical services and subsystems
  • Holistic principle and framework
  • Abstraction and virtualization
future work
Future Work
  • Holistic Framework
  • VSN
  • ICTs for developing regions

Analysis of the Proposed Protocols

  • Constant Velocity model
    • SFR and DVM error increases linearly
    • MADRD estimates location precisely (no error)
  • Constant Velocity + pause
      • SFR and DVM error increasely linearly and stays there
      • MADRD has 0 initial error and then it increases linearly
  • Contant Vecloty + change in direction
      • SFR: performs better if the turn is towards the prev
    • localization point (turn 90deg to 270 deg)
      • MADRD: otherwise performs better

(DOES NOT increase/decrease linearly)