Download Ad - start [kondor.etf.rs]

WIRELESS SENSOR
NETWORKS
`
Author:
Aleksandar Crnjin, 00/17
[email protected]
Supervised by:
Dr Veljko Milutinović,
http://galeb.etf.bg.ac.yu/~vm/
Topics
2/105



Introduction
 What are WSNs?
 An example: ESB
 WSN applications


Energy conservation
Ad-hoc routing
 Basic principles
 Overview of routing protocols
 Data-centric protocols
 Rumor Routing
 Geographical protocols



Localization and Positioning
Synchronization and
Security
The TinyOS operating
system
The TinyDB query system
Proto programming
language
Introduction: What are WSNs?
3/105
Sensors, connected into
wireless networks, are:


Wireless sensor
networks
Very small computer systems
With very high interconnection
ability
GRPS-enabled mobile
phones and PDAs
Compactness

v
Ad
IBM S/360
a
e
nc
o
ch
e
fT
n
o
ol
gy
PC
computers
Interconnection ability
Introduction: What are WSNs? 2
4/105
Wireless sensor networks
Tiny units with very small
power consumption
Possibility of geographical
and diffusion routing
Mobile ad-hoc networks
(MANETs)
Wireless LAN
Ad hoc networks
No permanent
infrastructure
Computer networks
Overview of networking
technologies
Introduction: What are WSNs? 3
5/105


The idea of wireless sensor networks
was first popularized by scientists from UC Berkeley
They have developed:


series of sensor nodes
(so-called mica nodes)
open-source software



TinyOS operating system
TinyDB query system
for efficient manipulation of sensed data
An interesting fact:


one of the first applications for small interconnected autonomous systems
was in submarine warfare
Integrated Undersea Sound Survelliance System (IUSS)
Introduction: What are WSNs? 4
6/105

Sensor network (def):



a set of small autonomous systems (sensor nodes)
working together to solve at least one common problem
their tasks always include some way of
perception of the physical environment
Sensor nodes:



basic units in a sensor network
they are usually powered by batteries
and they have some kind of a radio transceiver
Alternative names:


motes (most often)
smart dust
Architecture of a sensor node
7/105
Transciever
Power source
Microcontroller
External RAM
memory
Sensors...
A/D conversion
Sensors...
Block diagram of a typical sensor node (mote)
An example: ESB, FU-Berlin
8/105
Source: [1]
WSN Applications
9/105

Treatment of ill people: wearable computing



Embedded systems: home automation





under-skin implants – measurement of blood parameters,
early detection of some illnesses
already marketed – capsules with 24 hours of battery life
which move through the patient’s body and relay images to the doctor
through another device worn externally by the patient
temperature measurement
alarm systems
Traffic – sensors in cars,
early traffic congestion warning
Military applications
Many other; new applications are constantly devised.
One application: Camalie Vineyards
10/105
One mote in the vineyards: Crossbow mica2dot mote, NiMH
batteries, solar panel, 3V voltage regulator.
Source: [12].
One application: Camalie Vineyards 2
11/105
The visitors of the Camalie Vineyards website can view graphs of ambient
temperature (with respect to time) in all points where sensors are present.
Slightly colder temperatures come from sensors in the wine cellar;
dysfunctional motes report absolute zero. Source: [12].
Topics
12/105



Introduction
 What are WSNs?
 An example: ESB
 WSN applications


Energy conservation
Ad-hoc routing
 Basic principles
 Overview of routing protocols
 Data-centric protocols
 Rumor Routing
 Geographical protocols



Localization and Positioning
Synchronization and
Security
The TinyOS operating
system
The TinyDB query system
Proto programming
language
Energy conservation
13/105





Careful use of available energy is of paramount importance in WSNs
 Batteries, in most cases, cannot be recharged!
Inefficient energy use shortens battery life considerably!
Some of the methods for reduced energy consumption and
prolonged battery life:
Passive conservation methods
 Use of sophisticated energy sources
 Placement of sensors into energy efficient topologies
Active conservation methods
 Hardware solutions
(watchdog timer, reduced clock frequency...)
 Energy aware routing protocols;
energy efficient medium access (MAC layer)
 The choice of an energy-saving operating system
Energy sources for motes
14/105



Rechargeable macro-batteries
as a secondary energy source
Micro-batteries on a wafer
Ultracapacitors








They not only hold electrical charge in the dielectric,
they also hold ionic charge in the double electrical layer
Energy density larger than in ordinary capacitors
by an order of magnitude
Micro Fuel Cells
Microturbines
Radioactive power sources
Solar cells
Energy of the human body

Wearable computing
Hydrogen micro-fuel cell
4mm micro turbine
Source: [13]
Energy conservation: hardware solutions
15/105

Watchdog timers



deliberately turn the power down
if the software is stuck in an infinite loop
Sleep states
Variable voltage processing


Deliberate performance degradation
by dropping the voltage and
reducing the clock frequency
so the same task could be done with
smaller energy consumption,
at the expense of performance.
Variable Voltage Processing
Same task can be performed with smaller
energy consumption if voltage and
frequency are reduced (shaded area).
Source: [13]
MAC energy aware protocols
16/105


Energy aware protocols are used at the MAC layer
(energy efficient medium access).
Basic principle:
 Energy required for signal transmission is
proportional to d α
 d – distance between two nodes
 α – attenuation factor
(medium dependent)
MAC energy aware protocols 2
17/105
For optimum α = 2,
transmitting a signal to ½ of
distance requires ¼ of
energy: (½ d)2 = ¼ d2
→ If a protocol can find a node
on ½ distance to target,
which can supply additional ¼
of energy to transmit the
signal through the remaining
half, ½ of energy is saved!
(½ d)2 + (½ d)2 =
¼ d2 + ¼ d2 = ½ d2

Energy solutions in the ESB
18/105






Microcontroller TI MSP340:
energy consumption 3V, 1mA (3mW)
total energy consumption is 12mA at 4.5 V,
plus additional 12mA during data transmission
program memory: 8KB EEPROM
only 2KB of conventional RAM memory;
60KB Flash RAM for special purposes only
(high energy consumption!)
watchdog timer: uses an NMI interrupt to
shut the node down immediately,
if software gets stuck in an infinite loop
sleep mod, consumes only 0.008 mA
(practically equivalent to battery self-discharge)
Printed circuit of the ESB
Topics
19/105



Introduction
 What are WSNs?
 An example: ESB
 WSN applications


Energy conservation
Ad-hoc routing
 Basic principles
 Overview of routing protocols
 Data-centric protocols
 Rumor Routing
 Geographical protocols



Localization and Positioning
Synchronization and
Security
The TinyOS operating
system
The TinyDB query system
Proto programming
language
Ad-hoc routing
20/105


Wireless networks: computer networks with
wireless communication links
Ad-hoc networks:




in ad-hoc nets every node can forward packages
the decision whether each node will or will not forward packages
is made dynamically,
with regard to current connectivity matrix.
Comparison:


in conventional computer networks,
there are dedicated nodes (routers, switches, hubs...)
which forward packages.
Such approach is impossible in ad hoc networks –
all nodes are constantly on the move, connectivity changes all the time
so there are no good candidates for dedicated routers.
Ad-hoc routing
2
21/105

In ad-hoc networks, individual nodes
have no a priori knowledge of network topology


when connected, they gradually discover other
nodes
Basic principle:
a newly connected nodes advertises it’s presence
 reads broadcast messages from neighboring nodes


In this way, a node gradually discovers:
the positions of other nodes in a network,
 ways to reach each one of them.

Ad-hoc routing
3
22/105



When enough time has passed,
routing protocol convergence is established.
When this happens,
each node “knows” about all the
other nodes in the net,
and how to reach each one of them.
Convergence time is total time elapsed
from when the network topology is changed
(for example, when a communication link goes down)
to when all nodes have restructured their routing
tables in accordance with the change.
Ad-hoc routing
4
23/105




Conventional networks use data-centric routing:
each node has an unique data identifier
which serves as its address on the network
(IP-address, MAC-address...)
Some ad-hoc networks use different concepts
For example, it might not be necessary for information to be
routed from a specific starting point to a specific endpoint,
but only to be propagated and diffused through the network.
This is called Rumor Routing.
Or, geographical coordinates could be used as means for
addressing (Geographical Routing).
Overview of ad hoc routing protocols
24/105
Ad hoc protocols
Data-centric
Diffusion
Proactive
Reactive
Location based
Rumor
routing
Directed
diffusion
GeoCast
Hybrid
GeoGrid
Data-centric protocols
1
25/105
Proactive protocols:
maintain consistent knowledge of network topology
through routing tables
which are exchanged between nodes periodically
Drawbacks:
 network bandwidth is wasted:
routing tables are an overhead
which decreases available bandwidth for useful data
 some paths are never used, and yet they are kept in the tables
 simulations show very long convergence time
some proactive protocols never converge in large wireless networks!
Example:
 WRP – Wireless Routing Protocol
Data-centric protocols
2
26/105
Reactive protocols:
information about paths is not kept; a path is discovered on
demand only, by flooding the network with Route Request
packages
Drawbacks:
 on demand path discovery introduces significant delays
 flooding the network can lead to severe network congestion
Examples: can be found, in detail, in [10]
 AODV – Ad-hoc On-demand Distance Vector
 DSR – Dynamic Source Routing
 TORA – Temporally Oriented Routing Algorithm
Data-centric protocols
3
27/105
Hybrid protocols:
locally proactive, globally reactive
e.g. ZRP – Zone Routing Protocol


The network is divided into routing zones
 the zone is usually an sphere with a specified diameter,
measured in hop counts
 the nodes positioned at the maximum distance from central node X
are called peripheral nodes for the routing zone centered at X.
When package needs to be sent from node A to node B:
 if B is within the same routing zone as A,
local routing table is looked up to find the path to B (proactive behaviour),
 if this is not the case, Route Request packages are sent
to all peripheral nodes
 each peripheral node repeats this step
(checks whether the destination B is inside its routing zone).
Data-centric protocols
28/105

ZRP example:



If a package is sent
from node S to node G:


A sphere centered at S:
is a zone of radius ρ = 2
J, G, H, I:
peripheral nodes
Destination is within
the same zone,
routing table is looked up.
If a package is sent
from node S to node T:



Destination is in a different zone,
Route Request packages are sent to nodes G, H, I, J.
Node I discovers that T is within its routing zone (d = 2),
It looks up its routing table, and sends the package to L.
4
Rumor Routing
29/105


first proposed by Braginsky and Estrin (UCLA)
in their paper [4].
All nodes are divided into two groups:





nodes that perceive events,
nodes which seek information about events,
from the nodes of the preceding group
There is no network topology
There is no coordinate system
The protocol doesn’t try to find an optimum route,
it seeks only to relay the information end-to-end

sub-optimum routes are satisfactory for this purpose
Rumor Routing
2
30/105
Rumor Routing protocol:
1
1
2
3
2
Illustration of Rumor Routing protocol
(Source: [1])
1. Events A and B are
perceived on some nodes
2. An agent is sent from both
groups (A and B) to “spread
rumors” about the
whereabouts of possible
sources of information for
events A and B
3. When agent B meets agent
A on its way, it goes on to
spread information about
both events A and B
Rumor Routing
3
31/105
1
2
4
3
Illustration of Rumor Routing protocol
(Source: [1])
Handling the information requests:
1. A node requests information
about event A
2. It’s request “moves blindly”
through the network until it
stumbles upon a node visited
by the information spreading
agent. While moving, it leaves
traces so it can backtrack when
information is found.
3. When a node visited by the
agent is found, a route is
followed to the source of
information
4. Information is retrieved and
brought back to the source of
the request.
Geographical Protocols: An Overview
32/105


Routing relies on geographical position information
(as opposed to data centric routing)
Destination for a package is a specific area
e.g. a city, a section of a highway, or,
at the micro level, a part of the conference room
 recipient cannot determine exactly who is the sender,
it can only determine roughly from where
the package came from



Routing decision are made with respect to
real, spatial coordinates
For that to be possible,
positioning information is necessary

one way of obtaining position information is
GPS (Global Positioning System)
An example: GeoCast
33/105


Proposed by Navas and Imielinski, 1997.
Three-tiered architecture:

GeoHosts are endpoints of the network




GeoGateways are the network’s entry and exit points



Client processes (applications) are run on them
GeoHosts initiate message transfer
On receipt of the package, they check if their geographical region
is the destination of the package.
GeoHosts communicate with GeoRouters through broadcast messages
a GeoGateway is responsible for a given area specified by a radius
GeoRouters perform the actual routing


they are aware of the coordinates of neighboring
GeoRouters and GeoGateways
they route the package through neighboring GeoRouters
to the destination GeoGateway
so that it can reach the destination geographical area.
GeoCast routing
34/105
Ilustracija koncepata GeoHost, GeoGateway, GeoRouter
2
GeoCast routing
3
35/105
GeoCast communication:
Client
Process
Event
GeoGateway
GeoHost
Client
Process
GeoRouter
Direct
message
Source: [5]
1. A node on Net A
perceives the event
2. It sends a message to its
GeoGateway
3. Gateway forwards the
message to a neighboring
GeoRouter
4. Routing is performed
5. At some moment,
destination Gateway is
direct neighbor to a
router; the router hands
the message to
destination Gateway.
6. Destination Gateway
delivers the message to
Net B.
GeoCast routing
36/105


With classical IP networks,
next hop address is determined
by looking up a routing table
With GeoCast, destination addresses are areas
specified by necessary parameters



if the area is a circle,
location of center and length of radius are required
if the area is a polygon,
locations of all angles are required
Routers are organized in a hierarchical manner


routers responsible for smaller geographical areas are
lower in the hierarchy
routers responsible for larger geographical areas are
lower in the hierarchy
4
GeoCast routing
5
37/105
A client process, running on a GeoHost, delivers a message
to its GeoRouter through its network’s GeoGateway
GeoRouter consults lower-level GeoRouters and determines:
1.
2.



3.
4.
Is there any overlap between the zone of responsibility of the lower
level router, and the destination area?
If there is an overlap,
the message is forwared to the lower-level GeoRouter.
When this is repeated for all lower level routers,
was the destination area covered completely?
If it was, the procedure ends here.
If it wasn’t, the message is unicast to a higher level router,
responsible for wider geographical area,
which repeats the procedure starting at 2.
GeoCast routing
38/105


In order to implement the
described procedure,
another procedure is necessary,
one that will determine if the
two areas overlap.
If the two areas are both
circles, the procedure is simple

if the distance between centers
is smaller than the sum of the
radiuses,
the circles indeed overlap
6
GeoCast routing
39/105

If the two areas are a circle
and a polygon, or they are
both polygons, things get
complicated


Geographical calculations of
higher complexity are necessary
Comparison with IP nets:
In IP networks, a simple query on
the routing table is all that is
necessary
 In GeoCast networks,
routing decision complexity is
several orders of magnitude
higher!

7
Routing Protocols: A Conclusion
40/105
Rough classification of protocols:




Data-centric: an address is some kind of datum
(e.g. an IP address – 4 bytes of data)
Diffusion: it is not necessary to address individual nodes,
only to diffuse the information through the network
Geographical: an address is a geographical area,
described by geographical parameters
Most uses for data centric protocols are
outside of wireless sensor networks
Diffusion protocols are simple



but they are suitable only for a small number of use cases
Geographical protocols are conceptually most suitable for
wireless sensor networks


but making a routing decision can be very complex
Topics
41/105



Introduction
 What are WSNs?
 An example: ESB
 WSN applications


Energy conservation
Ad-hoc routing
 Basic principles
 Overview of routing protocols
 Data-centric protocols
 Rumor Routing
 Geographical protocols



Localization and Positioning
Synchronization and
Security
The TinyOS operating
system
The TinyDB query system
Proto programming
language
Localization and Positioning
42/105



Measurements by sensor networks
are substantially more valuable
if the location of measurement
is known
Therefore, a sensor has to be
aware of its position in the real
world
Two approaches:


Localization
Positioning
B
C
A
Localization and Positioning
43/105

Localization:
location of the sensor is given
as relative to some local point



it is then possible to calculate
distances and angles between individual nodes
but it is not possible to determine the
sensor’s global position
Positioning:
a sensor is given absolute coordinates on the world map

e.g. coordinates can be longitude and latitude
2
Localization and Positioning
3
44/105

The simplest solution to the
problem of positioning is to
put a GPS device in each
sensor node.


GPS receivers are still too
expensive and too big!
The remaining possibilities
can be divided into 4
groups (picture).
1
Some nodes
know their
position, and
distances
between nodes
are known.
2
No node knows
its position, but
distances
between nodes
are known.
3
Some nodes
know their
position, but
distances
between nodes
are not known.
4
No node knows
its position and
distances
between nodes
are not known.
Localization and Positioning
4
45/105
1
Some nodes
know their
position, and
distances
between
nodes are
known.
2
No node
knows its
position, but
distances
between
nodes are
known.
3
Some nodes
know their
position, but
distances
between
nodes are not
known.
4
No node
knows its
position and
distances
between
nodes are not
known.
1.
2.
3.
4.
Global coordinates are
available for the
complete topology,
Only local coordinates
are known,
It is possible only to
roughly estimate the
position of the whole
system,
Only the network’s
connectivity matrix
is available.
Localization and Positioning
5
46/105

Since only some nodes need to be aware of their position
in order to establish positioning for the complete network,




Alternate solution:
instead of equipping them with a GPS device,
some nodes could have their position manually input by an
operator (based on measurements from his GPS device).


only some nodes need to be equipped with a GPS device,
because of high energy consumption,
GPS could be turned on only occasionally,
in those intervals, remaining nodes perform localization
with respect to the GPS-equipped nodes.
This solution is sometimes neither practical nor possible!
For mobile networks,
public positioning stations are usually used.
Positioning
1
47/105

Positioning of every node is possible in Case 1 from
the table


that is the case when positions of some nodes are known,
and distances between nodes are known, too.
Three already positioned nodes are enough to
determine position of another node
if the distances between nodes are known.
 one way of measuring distance is
measuring the attenuation of the radio signal


If some of the 3 nodes is not positioned with sufficient
precision, the error propagates quickly!
Positioning (2D)
2
48/105







pi, pj – already positioned nodes
n – newly added node
We consider two spheres, with
radiuses dn, i i dn, j, around their centers
pi i pj
They intersect in two points: n i n’
The final step in positioning is to
choose one of these points
In order to do this, we need the third
already positioned node
Mutual visibility is checked with the
third node, in order to discount one of
the points n i n’.
In satellite positioning (3D) the final step is usually unnecessary;
the object has to be on Earth’s surface→
points in space or below surface are instantly discarded
Localization
1
49/105



In case no node is aware of it’s position,
but distances between nodes are known,
localization is the only possible approach.
Capkun, Hamdi, Hubaux,
“GPS-free Positioning in Mobile Ad-hoc Networks”
Describes the procedure which establishes
a global coordinate system (CS)

based on measurements of distances between nodes
Localization
2
50/105
Basic procedure for establishment of a global coordinate system
(CS), in a two-dimensional environment, is as follows:
1.
Each node searches for its immediate neighbors
in this way, “immediate neighborhood”, consisting of all
nodes one hop away, is formed.

2.
3.
4.
The distance table obtained in (1) is sent to all neighbors
In each node a local coordinate system is established,
with that node in the center
For each node n, two additional nodes p and q
are chosen from the immediate neighborhood,
in order to define x and y axes


x-axis is a line drawn from the circle, through node p,
oriented outwards
y-axis is always perpendicular to the x-axis,
node q is necessary only to determine its orientation
Localization
51/105
In each node, the remaining nodes’
positions are expressed in the local
coordinate system
One of the local coordinate systems is
chosen (for example, CS of node i);
origins of all other CS’s have their
locations in the CS of node i
For each node j, j ≠ i:
5.
6.
7.
1.
2.
Axes are rotated so that they become
parallel to axes of CS i
Coordinates of the origin of CSj, with
respect to CSi, are added to coordinates
of all pointsd in CSj.
In this way, all local coordinate systems are unified into a
global coordinate system, in which node i holds the position (0,0).
3
Localization and Positioning: Conclusion
52/105



For the measurements to be truly useful,
it is necessary to know the location of the
measurement.
When some of the nodes are aware of their global
position, it is possible to establish positioning
information for each node in the network.
If there are no such nodes, it is still possible to
construct a local coordinate system.
Topics
53/105



Introduction
 What are WSNs?
 Primer čvora senzora
 WSN applications


Energy conservation
Ad-hoc routing
 Basic principles
 Overview of routing protocols
 Data-centric protocols
 Rumor Routing
 Geographical protocols



Localization and Positioning
Synchronization and
Security
The TinyOS operating
system
The TinyDB query system
Proto programming
language
Synchronization
54/105


Time synchronization of events and activities
is essential in all distributed systems
In wireless sensor networks:



even more precise synchronization is needed
and it has to obtained with scarce critical resources
(battery power, communication channel availability, etc.)
Comparison with conventional distributed systems:

each node can operate only as long as its batteries last



therefore, clocks in all nodes cannot be maintained
from a central place (so called master clock)
as that node may run out of power
each use of the CPU and the communication medium
comes with a great price in energy
therefore, existing systems aren’t good enough!
Synchronization
2
55/105




Possible distortions of
measured time,
as the clock propagates
through the sensor network:
Jitter: “podrhtavanje” časovnika
usled nepreciznosti.
Skew: the clock becomes faster or
slower than normal
(frequency distortion)
Drift: measured time differs
by a constant offset
(phase distortion)

Source: [1]
this is a problem only
if different nodes have
different offsets
Synchronization
56/105



There is no optimum solution with satisfies all criteria
(preciseness, lifespan, availability)
Different approaches are often combined
Some commonly applied solutions:

Explicit synchronization




instead of keeping all clocks in synch all the time
events are recorded with respect to local time
when needed, these time marks are converted to another scale
on demand only
Peer-to-peer synchronization



amount of synch related errors between two nodes is
proportional to distance between them
therefore, keeping a centralized clock is not a good approach
instead, only neighboring nodes exchange synch related information
3
Security
57/105



Sensor networks usually consist of a large number of nodes
To supervise each node is practically impossible
Therefore, sensor networks are:


highly susceptible to logical and physical attacks
and communication interception



a node could be seized, reprogrammed,
then put back into the network
by means of reverse engineering, nodes could be designed to trick the
network into treating them as authentic
Various forms of abuse are then possible



intercepting confidential information (sensed data)
falsifying sensor readings
Distributed Denial of Service (DDoS) attacks.
Security
2
58/105


To protect every single node from reprogramming
is economically unfeasible
Other approaches are used:
node-to-node authentication:
nodes in the network have to prove their identity
to each other
 node revocation: when an intruding node is discovered,
it is forbidden to access the network any further


Applied protocols have to be made resilient

Meaning, the network has to be able to continue functioning
properly, even if some nodes are compromised.
Security
3
59/105


Privacy of sensed data is kept by encryption
Conventional approach – large keys


Commonly applied approach – hop-to-hop encryption



Unsuitable for sensor networks – because of limited memory!
Messages are encrypted using short keys in every node
Drawback: if one node in the chain is taken over,
there is no more encryption for any messages passing through that node
Multipath routing



before it is sent, the message is broken into several chunks
these chunks move through the network using different routes
they are not reassembled until they reach the destination
Security
60/105

DoS attacks – another threat
through DDoS attacks,
attackers can deliberately drain the batteries
 physical protection:



spread spectrum communication
frequency hopping
logical protection: constantly checking and
discarding messages with invalid
authenticity information
 danger: in this way, the very protection from DDoS
can drain the battery!


because, power is constantly spent on
authenticity checks for incoming messages
4
Security
5
61/105
Energy cost of added security through authentification:
as much as 71% extra energy cost is due to increased amount of transmission!
Synchronization and Security: Conclusion
62/105



These are the problems also present in conventional
networks
However, because of different architecture,
many traditional approaches are not suitable
Solutions for sensor networks have to be designed
with respect to the specific architecture of
sensor nodes
 most
of all, the scarcity of energy resources
Topics
63/105



Introduction
 What are WSNs?
 Primer čvora senzora
 WSN applications


Energy conservation
Ad-hoc routing
 Basic principles
 Overview of routing protocols
 Data-centric protocols
 Rumor Routing
 Geographical protocols



Localization and Positioning
Synchronization and
Security
The TinyOS operating
system
The TinyDB query system
Proto programming
language
TinyOS
64/105


Because of the specific architecture
of sensor networks,
a suitable operating system had to be devised
Conventional OSes for embedded systems
VxWorks
 Windows CE
 PalmOS
 QNX


They all require ROM of 100KB or more!
The ESB, introduced in Chapter 1, has only 8 KB ROM!
 Because of this, TinyOS was developed.

Characteristics of TinyOS
65/105

Event-driven programming






conventional context switching is impossible,
there is no room for the stack!
a system of components is used instead;
each component has its own static area in memory (“frame”)
in this way, the need for stack is eliminated
programs are executed only in response to the events
events are registered by components beforehand
Energy conservation


Interrupt polling is forbidden:
if the CPU constantly checks the status register,
battery power is continuously expended
Interrupt masking is forbidden, too:
node which requests the interrupt would spend power while it waits
TinyOS Architecture
66/105

TinyOS has:


a short-term task scheduler
components, which usually have:





Each component advertises:



command handling routines (command handlers)
event handling routines (event handlers)
a fixed amount of allocated memory (frame)
a few simple tasks
which commands it can handle,
which events it can report.
All tasks, commands, and event handler routines are executed
only within the allocated memory frame
TinyOS Architecture
2
67/105




they place parameters on pre-defined
locations within the memory frame
they deposit tasks for later execution
at some moment, they provide feedback to
the caller component
Task planning
Event handling routines:





respond to hardware events
write information to the memory frame
deposit tasks for later execution
signal events to higher level components
issue commands to lower level components
Component
Level i+1
Level i
Events

Memory frames are allocated statically
at compile time
Commands are issued by higher level
components, to lower level components
Commands

Component
TinyOS Architecture
68/105

Tasks:
perform the actual work
 with respect to other tasks, they are atomic



once started, they cannot be interrupted by other tasks
higher level events, however, can interrupt them
(pre-emption)
issue commands to lower level components
 signal events to higher level components
 deposit new tasks to their component


Short-term scheduler: a simple FIFO buffer
3
TinyOS: An example Component
69/105





A message transfer component
Sends and receives individual
packages to/from the lower level
Sends and receives whole
messages to/from the higher
level
As all components, it sends
commands to the lower level:

an initialization command:
init,

power management
command:
power(mode)
It recieves the same components
from the higher level
TinyOS: An example Component 2
70/105



It also sends the transfer
initiation command:
TX_packet (buf)
It responds to following
events (from lower level):

package is transmitted
TX_packet_done (success)

package is received
RX_packet_done (buffer)
It signals the following
events (to higher level):

message is transmitted
msg_send_done (success)

message is received
msg_rec (type, data)
TinyOS: An example Component 3
71/105
This code is used to declare the message transfer component
TinyOS: An example Component 4
72/105





An illustration of the amount
of occupied memory in a
typical sensor node:
Our component, AM, takes
up 356 bytes of ROM and
40 bytes of RAM
In the list of components, we
can also see the
components which provide
for hardware abstraction
For example, RFM
represents the built-in
RFM transciever
A fully functional sensor
node needs only
3450 bytes of ROM
and 226 bytes of RAM!
Topics
73/105



Introduction
 What are WSNs?
 Primer čvora senzora
 WSN applications


Energy conservation
Ad-hoc routing
 Basic principles
 Overview of routing protocols
 Data-centric protocols
 Rumor Routing
 Geographical protocols



Localization and Positioning
Synchronization and
Security
The TinyOS operating
system
The TinyDB query system
Proto programming
language
TinyDB
74/105




A query processing system,
which gathers information from sensor nodes
which have TinyOS installed
It uses a declarative programming language, TinySQL
Queries are always performed on a unique, default,
logic table: sensors
The sensors table has:



one row, for each measurement performed by any sensor node;
one column, for each relevant attribute of the measurement:
nodeID, temp, state, ...
It is bundled together with TinyOS
as a component which is installed on every mote in the net
TinyDB
75/105



TinySQL is very similar to standard SQL,
but there are some very important conceptual differences
It also has aggregate functions and triggers
A query, once input, is performed repeatedly



performing frequency is input through the epoch parameter
it has to be chosen carefully,
having in mind the limited battery capacity
Queries can be input:


visually,
through an application bundled with TinyOS
through coding,
in a language very similar to SQL
2
TinyDB
76/105

Basic form of the query:
SELECT select-list
[FROM sensors]
WHERE where-clause
[GROUP BY gb-list
[HAVING having-list]]
[TRIGGER ACTION cmd-name[(param)]]
[EPOCH DURATION integer]

An example:
SELECT temp
FROM sensors
WHERE temp > thresh
TRIGGER ACTION SetSnd(512)
EPOCH DURATION 512

If temperature higher than specified threshold is found on any sensor,
a beep 512ms long is sounded,
and the query is performed again after 512ms.
3
TinyDB
4
77/105

Queries can be performed in response to
external events, too


for example: an event which signals that the temperature
has risen above some threshold
Two procedures are necessary:


Writing a component which detects the event and
notifies TinyDB that it has indeed happened
A query in TinyDB of the form:
on event:
SELECT...
TinyDB
78/105

Example:
ON evtTest:
SELECT nodeid,light
SAMPLE PERIOD 1024

In response to event evtTest, sensed light data is
collected every 1 second.
5
Topics
79/105



Introduction
 What are WSNs?
 Primer čvora senzora
 WSN applications


Energy conservation
Ad-hoc routing
 Basic principles
 Overview of routing protocols
 Data-centric protocols
 Rumor Routing
 Geographical protocols



Localization and Positioning
Synchronization and
Security
The TinyOS operating
system
The TinyDB query system
Proto programming
language
Proto programming language
80/105




Proto:
a high-level programming language
used to program sensor and actuator networks
Proposed by Jonathan Bachrach and Jacob Beal
from the Massachusetts’ Institute of Technology
Computer Science and Artificial Intelligence
laboratory
(MIT-CSAIL)
Paper:
“Programming sensor networks as an
amorphous medium” [7]
Proto programming language
2
81/105




The goals of the Proto language:
to relieve the programmer from worrying about the
physical aspects of sensor network programming
the exact way of providing fast, efficient and robust
communication between nodes is below the barrier of
abstraction
instead,
the programmer writes declarative code, such as
If the temperature is high,
(sensor measurement)
 Then, the field should be watered, every few hours
(a command to actuators)

Proto programming language
3
82/105


In order to accomplish this,
the sensor network is
imagined as an
amorphous medium




Approximation of an amorphous medium
Continuous field of calculable
material
Sensed data in each sensor node
is a point in the field
Dimensions and physical
distribution of the points is not
known
Each point in the amorphous
field:


executes the same code
advertises its state to the
immediate neighborhood
Proto programming language
4
83/105

Proto programs
manipulate over fields
 One
field is
a mapping scheme
which assigns
some value
to a set of points in
space
Proto programming language
84/105
Primitives in Proto can be:
 terminals
 operators
 common
arithmetic operators, in prefix notation
 if operator
 special
primitives
 mux
 sense
and act
 let and def
5
Proto programming language
85/105


Primitives can be combined
into complex expressions
Besides the individual fields,
field streams can be also used
When evaluating expressions with field streams,
the result has to be calculated separately
for each field from the stream
 Therefore, the result is a field stream, too

6
Proto programming language
86/105

Terminals correspond to constants
and they generate fields
 For
example, the terminal 2
generates a field with value 2 in every point

Operators calculate the output field
using a set of input fields
 for
example, the expression + 2 5 generates
a field with value 7 in every point
 the if operator has standard meaning
7
Proto programming language
87/105

mux uses a selector field of booleans
in order to generate a field
in which for every point,
one of two possible values is chosen:
the value from the corresponding point in field #1,
or,
the value from the corresponding point in field #2.
 this
is performed for each point separately,
with respect to the boolean value in the
corresponding point in the selector field.
8
Proto programming language
88/105

sense and act represent the sensor readings and
actuator commands, respectively.
 They
are analogous to, for example,
read and write procedures in Pascal
 In this way, Proto programs
communicate with their environment.

let assigns a value to a variable
 E.g.

(let x 3)
def defines a procedure (a macro)
 E.g.
(def sq(x) (* x x))
9
Proto examples
1
89/105


Example (a):
terminal 2
generates a field which
has value 2 in every point
(“2”)
Example (b):
we add up the field “2”
with field stream (“1”, “3”)
the result is a
field stream (“3”, “5”)
Proto examples
2
90/105



Example (c):
input parameters are
fields “2”, “3”
and field stream (“false”, “true”)
As the selector is a
field stream and not a field,
the result will be a field stream too
One field from the result field
stream corresponds to
selector field “false”:
that is field “3”


selector has semantics “do we
choose the first field?”,
and as it is false, we choose the 2nd
Second field corresponds to “true”;
that is field “2”
Proto examples
3
91/105



Example (d):
a complex operation
Firstly, terminals 2 and 5
generate fields “2” and “5”
Secondly, as a result of
add operation the
result field “7” is
generated.
Proto examples
4
92/105



Example (e):
definition of a procedure
we define sq(x) as x*x
Example (f):
terminal 3 generates field “3”
as a result of a sq call,
field “9” is generated
Proto code:
(def sq(x) (* x x))
sq(3)
Proto examples
93/105

an input and output example:
input – light is perceived
output – a signalization light is emitted
5
Proto examples
94/105

the following code turns the red light emitter on
each sensor where any light is perceived
6
Proto: reduce-nbrs
95/105


nbrs (x):
neighborhood of point x
Proto also has primitives
which enable it to
describe behavior which
depends not only on a
single point in space
(single sensor),
but it’s immediate
neighborhood, too
The neighborhood of a
single point is an infinite
number of points

Amorphous medium –
continuous space!
Proto: reduce-nbrs
96/105

The reduce-nbrs primitive summarizes the
neighborhood of a single point


using some quantificator applicable to infinite sets
Proto has five such quantificators:
integral
 forall
 exists
 limsup
equivalent to max, for infinite sets
 liminf
equivalent to min, for infinite sets

2
Proto: reduce-nbrs
3
97/105




In this way, implicit communication between points
is established
By aggregating the values in neighborhood of x,
the points from the neighborhood
communicate their value to x
Real-life communication has a delay
Proto simulates this delay using primitives
delay and letfed
An example Proto application
98/105


the Threat Avoidance problem
If we have:






current coordinates,
a means for perceiving the danger
(threat sensor)
a model of exponentially falling danger
how can we calculate the safest route?
Implementation in the nesC language
(standard procedure language for sensor networks)
~ 2000 lines of code
Implementation in Proto:
only 22 lines of code
An example Proto application
99/105


In order to test the threat avoidance program,
a model is required
So, we describe a model with
exponentially falling danger:
2
An example Proto application
100/105

Now, with regard to our current location,
we can calculate the
cumulative probability of survival
3
An example Proto application
101/105

Greedy-ascent procedure:
in every point,
the direction for next move is chosen
in which the threat is best avoided
4
An example Proto application
102/105

By combining all these procedures,
a complete solution for threat avoidance is obtained
5
An example Proto application
103/105

The results obtained
when the threat
avoidance program
is run on a simulator
For more information, please consult [7] and [9].
6
References
104/105
[1] Thomas Hänselmann, Sensor Networks, 2006.
[2] Jason Hill et al., System Architecture Directions for Networked Sensors, Department of
EE/CS, UC Berkeley
[3] Sam Madden, Joe Hellerstein, Wei Hong, TinyDB: In-Network Query Processing with
TinyOS, UC Berkeley, 2003.
[4] David Braginsky, Deborah Estrin, Rumor Routing in Sensor Networks, LECS-UCLA
[5] Joe Polastre, Rachel Rubin, GeoMote: Geographical Network Architecture for Sensor
Networks, CS Berkeley
[6] Jeremy Elson, Time Synchronization in Wireless Sensor Networks, UCLA, 2003.
[7] Jonathan Bachrach, Jacob Beal, Programming a Sensor Network as an Amorphous
Medium, MIT-CSAIL, 2006.
[8] Haowen Chan, Adrian Perrig, Security and Privacy in Sensor Networks, Carnegie
Mellon University, 2003.
[9] Jacob Beal, Continuous Semantics of Proto, MIT-CSAIL, 2006.
References
2
105/105
[10] Đ. Trifunović, N.Milanović, V.Milutinović, Ad-hoc Networks:
Estabilishing node-to-node communication with no infrastructure needed,
http://galeb.etf.bg.ac.yu/~vm/os/vlsi/ADHOC.ppt
[11] en.wikipedia.org, USA, 2007.
[12] www.camalie.com, USA, 2007.
[13] M. Ilyas, I. Mahgoub (ed.), Handbook of Sensor Networks: Compact Wireless and
Wired Sensing Systems, CRC Press, 2005.
[14] I. Stojmenović (ed.), Handbook of Sensor Networks: Algorithms and Architectures,
Wiley, 2004.