What is a Wireless Sensor

Network ?
 WSN consists of spatially
distributed autonomous
sensors to cooperatively
monitor physical or
environmental
conditions.


 Can monitor temperature,

sound, vibration,
pressure, motion or
pollutants.
Where can you use a WSN ?
Initially : Military applications such as


battlefield surveillance.


Now :


 Industrial process monitoring and control

 Machine health monitoring

 Environment and habitat monitoring

 Healthcare applications

 Traffic control.
Smartdust – An instance of
WSN
 Is a hypothetical system of many tiny
microelectromechanical systems
(MEMS) such as sensors, robots, or
other devices, that can detect light,
temperature, vibration, magnetism or
chemicals.


 Usually networked wirelessly.



 Called the “REAL World Wide Web”

Companies using Smartdust
 Hewlett-Packard - "Central Nervous
System for the Earth.”
 1 Trillion sensors !


 Check if ecosystems are healthy

 Detect earthquakes more rapidly
 Predict traffic patterns
 Save energy and prevent accidents, since
you know it in real time !

Companies using
Smartdust(contd.)
 Royal Dutch Shell to install 1 million
matchbook-size monitors to aid in oil
exploration by measuring rock
vibrations and movement.


 Those sensors, which already have been

developed, will cover a 6-square-mile
area.

Motivation to design an OS for WSN
1.Today, sensors exist on the scale of a
square inch in size, and a fraction of a
watt in power.
2.
3.In the future, it may be possible to reduce
sensors to the size of a cubic
millimeter, or smaller.
4.
5.The key missing technology for these
devices is system software to manage
and operate them efficiently.
Operating System
Requirements
 Small physical size and low power consumption
 Devices have limited memory and power
resources


 Concurrency intensive operation

 Need to be able to service packets on-the-
go in real-time


 Limited hardware parallelism and controller

hierarchy
 Limited number, and capability of
controllers
 Unsophisticated processor-memory-switch
level interconnect
Operating System
Requirements (contd.)

 Diversity in design and usage
 Provide a high degree of software
modularity for application specific
sensors

 Robust Operation
 OS should be reliable, and assist
applications in surviving individual
device failures

The Solution: Tiny OS
 A microthreaded OS that draws on
previous work done for lightweight
thread support, and efficient network
interfaces


 Two level scheduling structure

 Long running tasks that can be interrupted
by hardware events


 Small, tightly integrated design that

allows crossover of software
components into hardware
 TinyOS Component Model

 Component has:
 Frame (storage) Messaging Component
Int
er
nal
 Tasks Internal Tasks St
at

(computation)
e

 Command and
Commands Events
Event
nTo facilitate modularity, each component declares
Interface

the commands it uses and the events it signals.
nStatically allocated, fixed sized frames allow us to
know the memory requirements of a component
at compile time, and avoid the overhead
associated with dynamic allocation.
Tasks
 Perform the primary computation work


 Can be preempted by events



 Allow the OS to allocate a single stack

assigned to the currently executing
task


 Schedule other tasks within a

component
 Commands

 Deposit request parameters into a

component’s frame, and post a task
for later execution

 Can also invoke lower level commands,
but cannot block.

 To avoid cycles, commands cannot
signal events

 Return status to the caller
 Events
 Event handlers deal with hardware events
(interrupts) directly or indirectly

 Deposit information into a frame

 Post tasks

 Signal higher level events

 Call lower level commands

TOS Component
 //AM.comp//
 TOS_MODULE AM;

AM_MSG_SEND_DONE
ACCEPTS{

AM_SEND_MSG  char AM_SEND_MSG(char addr, char type,

AM_POWER

char* data);
AM_INIT

void AM_POWER(char mode);

AM_MSG_REC


 char AM_INIT();
};

SIGNALS{

 char AM_MSG_REC(char type,

char* data);
Messaging Component
Int  char AM_MSG_SEND_DONE(char success);
er };
nal
Internal Tasks St HANDLES{

at  char AM_TX_PACKET_DONE(char success);

e
AM_SUB_TX_PACKET

 char AM_RX_PACKET_DONE(char* packet);

AM_SUB_POWER

};
AM_SUB_INIT

AM_TX_PACKET

AM_RX_PACKET

USES{

 char AM_SUB_TX_PACKET(char* data);

 void AM_SUB_POWER(char mode);
_DONE

_DONE

 char AM_SUB_INIT();
};

Commands Events
 Putting It All Together

 The task scheduler is a simple FIFO

scheduler.

 The scheduler puts the processor to sleep
when the task queue is empty.

 Peripherals keep operating and can wake
up the processor.

 Communication across components takes
the form of a function call. This results
in low overhead, and allows compile time
type checking.
 Sample Application
 To build application consisting of a
number of sensors distributed within a
localized area
 Monitor temperature and light conditions
 Periodically transmit measurements to a
base station
 Sensors can forward data for other
sensors that are out of range of the
base station
 Dynamically determine the correct
routing topology for the network
Internal Component Graph

application Ad hoc Routing Application

Active Messages

packet
Radio Packet Serial Packet Temp
SW

byte
Radio byte UART I2C HW
Photo

bit
RFM Clocks
Ad hoc Routing
 Base station periodically broadcasts route
updates
 Any sensors in range of this broadcast record
the identity of the base station, and
rebroadcast the update
 Each sensor remembers the first update
received in an era, and uses the source of the
update as the destination for routing data
2
back to the base station
1

3

Base 0
2

1
Evaluation: Small Physical Size
Component Name Code Size Data Size
nScheduler only Multihop router
(bytes)
88
(bytes)
0
occupies 178 bytes AM_dispatch
AM_temperature
40
78
0
32
nComplete application AM_light
AM
146
356
8
40
only requires 3 KB of Packet
Processor_init
RADIO_byte
334
172
810
40
30
8
instruction memory TinyOS
RFM
C
scheduler
runtime
178
310
82
16
1
0
and 226 bytes of data Photo
Temperature
84
64
1
1
(less than 50% of the Total
UART
UART_packet
3450
196
314
226
1
40
512 bytes available) I2C_bus 198 8

nOnly processor_init,
TinyOS scheduler,
and C runtime are
required
Evaluation: Concurrency Intensive
Operations
nLow overhead is Operations Cost Time Normalized to
essential for Byte copy
(cycles)
8
(µs)
2
byte copy
1

achieving Post an Event

Call a Command
10
10
2.5
2.5
1.25
1.25
modular Post a task to scheduler
Context switch overhead
46
51
11.5
12.75
6
6
efficiency Interrupt (hardware cost) 9 2.25 1

nCost of posting Interrupt (software cost) 71 17.75 9

an event = cost
of copying 1
byte of data
n
nCost of posting a task or context switching is the
same as copying 6 bytes of data
nInterrupt handling requires saving and storing
registers
Efficient Modularity
 Message Send Transition
 Total propagation delay up the 5 layer radio
communication stack is about 80 instructions

Timing diagram of event propagation

Evaluation: Limited Hardware Parallelism
and Controller Hierarchy

Packet reception
Components work breakdown CPU Utilization Energy (nj/Bit)
AM 0.05% 0.20% 0.33
Packet 1.12% 0.51% 7.58
Radio handler 26.87% 12.16% 182.38
Radio decode thread 5.48% 2.48% 37.2
RFM 66.48% 30.08% 451.17
Radio Reception - - 1350
Idle - 54.75% -
Total 100.00% 100.00% 2028.66
 Successfully demonstrated a system
with multiple flows of data running
through a single microcontroller
Evaluation: Diversity in Usage and
Robust Operation

 Can create several sample applications

that exploit the modular structure of
the system
 Source based multi-hop routing
applications
 Active-badge-like location detection
applications
 Sensor network monitoring applications
 C programming language allows the
ability to target multiple CPU
architectures in future systems
 Robustness: Multihop routing application
automatically reconfigures itself to
Conclusions

 TinyOS is a highly modular software

environment tailored to the
requirements of WSNs, stressing
efficiency, modularity, and concurrency.


 TinyOS should be able to support new

sensor devices as they evolve.


 Makes it easier to design hardware that is

optimized for a particular application.
Thanks !