slide1 n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
System Architecture for Sensor Networks Jason Hill and David Culler PowerPoint Presentation
Download Presentation
System Architecture for Sensor Networks Jason Hill and David Culler

Loading in 2 Seconds...

play fullscreen
1 / 23

System Architecture for Sensor Networks Jason Hill and David Culler - PowerPoint PPT Presentation


  • 161 Views
  • Uploaded on

System Architecture for Sensor Networks Jason Hill and David Culler. Different platforms need different solutions. Highly constrained (memory, cpu, storage, power) Solutions: TinyOS,…. StarGate. Capabilities. MK - II. Ample resources Solutions: Linux, uCos Emstar…. MICA Mote. Spec.

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

PowerPoint Slideshow about 'System Architecture for Sensor Networks Jason Hill and David Culler' - ancelin


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
slide1
System Architecture for Sensor Networks

Jason Hill and David Culler

different platforms need different solutions
Different platforms need different solutions

Highly constrained (memory, cpu, storage, power)

Solutions: TinyOS,…

StarGate

Capabilities

MK - II

Ample resources

Solutions: Linux, uCos Emstar…

MICA Mote

Spec

Size, Power Consumption, Cost

technology push towards miniaturization
Technology push towards miniaturization
  • CMOS miniaturization
    • 1 M trans/$ => tiny (~mm2), inexpensive processing and storage
    • 1-10 mW active, 1 mW passive (at 1% use 100 mW ave)
  • Micro-sensors (MEMS, Materials, Circuits)
    • acceleration, vibration, gyroscope, tilt, magnetic, heat, motion, pressure, temp, light, moisture, humidity, barometric
    • chemical (CO, CO2, radon), biological, microradar, ...
    • actuators too (mirrors, motors, smart surfaces, micro-robots)
  • Communication
    • short range, low bit-rate, CMOS radios (1-10 mW)
  • Power
    • batteries remain primary storage (1,000 mW*s/mm3), fuel cells 10x
    • solar (10 mW/cm2, 0.1 mW indoors), vibration (~uW/gm), flow
  • 1 cm3 battery => 1 year at 10 msgs/sec
goal build low end sensor node cots prototype for mm 3 device
Goal: Build low-end sensor node COTS prototype for mm3 device

SENSING

SUB-SYSTEM

PROCESSING

SUB-SYSTEM

COMMUNICATION

SUB-SYSTEM

ACTUATION

SUB-SYSTEM

POWER MGMT.

SUB-SYSTEM

  • Small physical size: 1 mm3
  • Low Power Consumption: < 50 mW
communication sub system
Communication Sub-System
  • Functions
    • Transmit – Receive data packets wirelessly
    • Co-ordinate/Network with other nodes
  • Implementation
    • Radio
      • Modulation – Demodulation
      • Two types of radios: RFM, ChipCon CC1000
      • RFM: Mica & predecessors
      • CC1000: Mica2 onwards
wireless comm basics
Wireless Comm. Basics
  • RFM Radio– Simple radio, only modulates-demodulates bits
  • CC1000 Radio– Performs Manchester coding-decoding and synchronization also
radio power management
Radio Power Management
  • Radio has very high power consumption
    • Tx power is range dependant - 49.5 mW (0 dBm)
    • Rx power is also very high - 28.8 mW
    • Power-down sleep mode - 0.6 uW
    • Above data for CC1000, 868 MHz (Check out CC1000 data-sheets for more numbers)
  • Radio power management critical
    • Idle state channel monitoring power = Rx Power
    • Put radio to sleep when not in use
    • But then, how do we know when somebody is trying to contact us ?
typical sensor network operation
Typical sensor network operation
  • Sensing Subsystem
    • Keep the very low power sensors on all the time on each node in the network
  • Processing subsystem
    • Low-power sensors interrupt (trigger) processor when “events” are identified OR
    • Processor wakes up periodically on clock interrupt, takes a sample from sensor, processes it, and goes back to sleep.
  • Radio subsystem
    • Processor wakes up radio when event requires collaborative processing or multi-hop routing.
  • Tiered architectures of above subsystems can be envisaged in other platforms
traditional systems
Traditional Systems
  • Well established layers of abstractions
  • Strict boundaries
  • Ample resources
  • Independent apps at endpoints communicate pt-pt through routers
  • Well attended

Application

Application

User

System

Network Stack

Transport

Threads

Network

Address Space

Data Link

Files

Physical Layer

Drivers

Routers

by comparison
by comparison ...
  • Highly Constrained resources
    • processing, storage, bandwidth, power
  • Applications spread over many small nodes
    • self-organizing Collectives
    • highly integrated with changing environment and network
    • communication is fundamental
  • Concurrency intensive in bursts
    • streams of sensor data and network traffic
  • Robust
    • inaccessible, critical operation
characteristics of network sensors

sensors

actuators

storage

network

Characteristics of Network Sensors
  • Small physical size and low power consumption
  • Concurrency-intensive operation
    • multiple flows, not wait-command-respond

=> never poll, never block

  • Limited Physical Parallelism and Controller Hierarchy
    • primitive direct-to-device interface
    • Asynchronous and synchronous devices

=> interleaving flows, events, energy management

  • Diversity in Design and Usage
    • application specific, not general purpose
    • huge device variation

=> efficient modularity

=> migration across HW/SW boundary

  • Robust Operation
    • numerous, unattended, critical

=> narrow interfaces

design goals of tinyos
Design Goals of TinyOS
  • Concurrency-Intensive Operations
    • flow information from place to place on-the-fly
    • Example: simultaneously capture data from sensors, processing the data, then send out to the network
  • Robust Operations
    • Cross devices redundancy prohibitive
    • Individual reliable devices desired
    • Application tolerant individual device failures
design goals of tinyos cont
Design Goals of TinyOS (cont.)
  • Limited Physical Parallelism and Controller Hierarchy
    • Less independent controllers
    • Less processor-memory-switch level
    • Sensor and Actuator directly interact with the single-chip micro controller
  • Diversity in Design and Usage
    • Sensor network application specific design
    • But wide range potential applications
    • deep modularity of software needed
tinyos

application = scheduler + graph of components

  • event-driven architecture
  • single shared stack
  • NO kernel, process/memory management, virtual memory
TinyOS
tiny os concepts

msg_rec(type, data)

msg_send_done)

Tiny OS Concepts
  • Scheduler + Graph of Components
    • constrained two-level scheduling model: threads + events
  • Component:
    • Commands,
    • Event Handlers
    • Frame (storage)
    • Tasks (concurrency)
  • Constrained Storage Model
    • frame per component, shared stack, no heap
  • Very lean multithreading
  • Efficient Layering

Events

Commands

send_msg(addr, type, data)

power(mode)

init

Messaging Component

internal thread

Internal

State

TX_packet(buf)

Power(mode)

init

RX_packet_done (buffer)

TX_packet_done (success)

tos execution model

Radio Packet

packet

Radio byte

byte

RFM

bit

TOS Execution Model

data processing

application comp

  • commands request action
    • ack/nack at every boundary
    • call cmd or post task
  • events notify occurrence
    • HW intrpt at lowest level
    • may signal events
    • call cmds
    • post tasks
  • Tasks provide logical concurrency
    • preempted by events
  • Migration of HW/SW boundary

message-event driven

active message

event-driven packet-pump

crc

event-driven byte-pump

encode/decode

event-driven bit-pump

evaluation
Evaluation
  • meet power constraints?
evaluation1

Battery Lifetime for sensor reporting every minute

DutyCycle

Estimated Battery Life

Full Time Listening

100%

3 Days

Full Time Low Power Listening

100%

6.54 Days

Periodic Multi-Hop Listening

10%

65 Days

No Listening

0.01%

Years

Evaluation
  • meet power save?
components

Component

Frame

Tasks

Commands

Events

  • Commands and Events are function calls
  • Application: linking/glueing interfaces (events, commands)
Components
  • A component has:
    • Frame (internal state)
    • Tasks (computation)
    • Interface (events, commands)
  • Frame :
    • one per component
    • statically allocated
    • fixed size
commands events
Commands/Events
  • commands:
    • deposit request parameters into the frame
    • are non-blocking
    • need to return status => postpone time consuming work by posting a task
    • can call lower level commands
  • events:
    • can call commands, signal events, post tasks, can not be signaled by commands
    • preempt tasks, not vice-versa
    • interrupt trigger the lowest level events
    • deposit the information into the frame
scheduler

main {

while(1) {

while(more_tasks)

schedule_task;

sleep;

}

}

Tasks

Preempt

POST

FIFO

events

commands

commands

Interrupts

Time

Hardware

Scheduler
  • two level scheduling: events and tasks
  • scheduler is simple FIFO
  • a task can not preempt another task
  • events preempt tasks (higher priority)
tasks
Tasks
  • FIFO scheduling
  • non-preemptable by other task, preemtable by events
  • perform computationally intensive work
  • handling of multiple data flows:
    • a sequence of non-blocking command/event through the component graph
    • post task for computational intensive work
    • preempt the running task, to handle new data