System Architecture for Sensor Networks

1

• System Architecture for Sensor Networks
• Jason Hill and David Culler

2
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
3
Technology push towards miniaturization

• CMOS miniaturization
• 1 M trans/ gt 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
  mWs/mm3), fuel cells 10x
• solar (10 mW/cm2, 0.1 mW indoors), vibration
  (uW/gm), flow
• 1 cm3 battery gt 1 year at 10 msgs/sec

4
Goal Build low-end sensor node COTS prototype
for mm3 device
PROCESSING SUB-SYSTEM
COMMUNICATION SUB-SYSTEM
SENSING SUB-SYSTEM
POWER MGMT. SUB-SYSTEM
ACTUATION SUB-SYSTEM

• Small physical size 1 mm3
• Low Power Consumption lt 50 mW

5
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

6
Wireless Comm. Basics

• RFM Radio Simple radio, only modulates-demodulate
  s bits
• CC1000 Radio Performs Manchester coding-decoding
  and synchronization also

7
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 ?

8
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

9
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
10
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

11
Characteristics of Network Sensors

• Small physical size and low power consumption
• Concurrency-intensive operation
• multiple flows, not wait-command-respond
• gt never poll, never block
• Limited Physical Parallelism and Controller
  Hierarchy
• primitive direct-to-device interface
• Asynchronous and synchronous devices
• gt interleaving flows, events, energy management
• Diversity in Design and Usage
• application specific, not general purpose
• huge device variation
• gt efficient modularity
• gt migration across HW/SW boundary
• Robust Operation
• numerous, unattended, critical
• gt narrow interfaces

12
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

13
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

14
TinyOS
15
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 State
internal thread
TX_packet(buf)
Power(mode)
init
RX_packet_done (buffer)
TX_packet_done (success)
16
TOS Execution Model

• 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

data processing
application comp
message-event driven
active message
event-driven packet-pump
crc
event-driven byte-pump
encode/decode
event-driven bit-pump
17
Evaluation

• meet power constraints?

18
Evaluation

• meet power save?

19
Components

• A component has
• Frame (internal state)
• Tasks (computation)
• Interface (events, commands)
• Frame
• one per component
• statically allocated
• fixed size

20
Commands/Events

• commands
• deposit request parameters into the frame
• are non-blocking
• need to return status gt 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

21
Scheduler

• two level scheduling events and tasks
• scheduler is simple FIFO
• a task can not preempt another task
• events preempt tasks (higher priority)

22
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

23
Questions ???