System Architecture for Sensor Networks
Jason Hill and David Culler
1
Different platforms need
different solutions
Capabilities
Highly constrained
(memory, cpu,
storage, power)
Solutions: TinyOS,…
StarGate
MK - II
Ample resources
MICA Mote
Spec
Solutions: Linux,
uCos Emstar…
Size, Power Consumption, Cost
2

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
3
Goal: Build low-end sensor node
COTS prototype for mm3 device
SENSING
SUB-SYSTEM
ACTUATION
SUB-SYSTEM


PROCESSING
SUB-SYSTEM
COMMUNICATION
SUB-SYSTEM
POWER MGMT.
SUB-SYSTEM
Small physical size: 1 mm3
Low Power Consumption: < 50 mW
4
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
5
Wireless Comm. Basics


RFM Radio– Simple radio, only modulates-demodulates bits
CC1000 Radio– Performs Manchester coding-decoding and
synchronization also
6
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 ?
7
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
8
Traditional Systems

Application
Application
User


System
Network Stack
Transport
Threads

Network
Address Space
Data Link
Files
Physical Layer
Drivers

Well established
layers of abstractions
Strict boundaries
Ample resources
Independent apps at
endpoints
communicate pt-pt
through routers
Well attended
Routers
9
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
10

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
actuators
=> 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

sensors
storage
network
Robust Operation
– numerous, unattended, critical
=> narrow interfaces
11
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
12
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
13
TinyOS
●
●
●
●
application = scheduler + graph of components
event-driven architecture
single shared stack
NO kernel, process/memory management, virtual memory
14
Tiny OS Concepts

Commands,
Event Handlers
Frame (storage)
Tasks (concurrency)
Constrained Storage Model
– frame per component, shared stack, no
heap


Very lean multithreading
Efficient Layering
Messaging Component
internal thread
Internal
State
TX_packet_done
(success)
RX_packet_done
(buffer)
–
–
–
–
Events
send_msg
(addr,
type, data)
Component:
power(mode)

Commands
init
– constrained two-level scheduling model:
threads + events
msg_rec(type, data)
msg_sen
d_done)
Scheduler + Graph of Components
init
Power(mode)
TX_packet(buf)

15
TOS Execution Model

packet

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

bit
byte

data processing
application comp
message-event driven
active message
event-driven packet-pump
Radio Packet
crc
event-driven byte-pump
Radio byte
encode/decode
event-driven bit-pump
RFM
16
Evaluation

meet power constraints?
Idle
2 mA
4.5 mA (RX)
Sleep
5 μA
5 μA
EE-Prom
3 mA
LED’s
4 mA
Photo Diode 200 μA
0
0
0
0
0
0
200 μA
0
0
CPU
Radio
Temperatur
e
Active
5 mA
7 mA (TX)
17
Evaluation
 meet power save?
Battery Lifetime for sensor reporting every minute
Duty
Cycle
Estimated Battery
Life
Full Time Listening
100%
3 Days
Full Time Low Power
Listening
100%
6.54 Days
10%
65 Days
Periodic Multi-Hop
Listening
No Listening
0.01%
Years
18
Components

A component has:
– Frame (internal state)
– Tasks (computation)
– Interface (events, commands)

●
Tasks
Fra
me
Frame :
– one per component
– statically allocated
– fixed size
●
Component
Commands
Events
Commands and Events are function calls
Application: linking/glueing interfaces (events, commands)
19
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
20
Scheduler



two level scheduling: events and
tasks
scheduler is simple FIFO
a task can not preempt another task
events preempt tasks (higher priority)
main {
…
while(1) {
while(more_tasks)
schedule_task;
sleep;
}
}
Tasks
Preempt
POST
events

FIFO
commands
commands
Interrupts
Hardware
Time
21
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
22
Questions ???
23