Routing Techniques in Wireless Sensor
Networks: A Survey
J. Al-Karaki, A. E. Kamal
A Survey on Routing Protocols for
Wireless Sensor Networks
K. Akkaya, M. Younis
Based on materials from Fei Hu and Kang
MANET-Inspired WSN Application: Military
From UMASS
MANET-Inspired WSN Application:
Environmental
From UMASS
MANET-Inspired WSN Application: Future
Health
Circulatory Net
General Properties (1)
Mainly for Information Collection
Single Owner
Up to Hundreds of Thousands of Nodes
Disposable Nodes
Cheap Nodes
Security Concerns
General Properties (2)
Bounded Directed Stream (from/to Sink)
Somewhat Limited Computation Capability
Limited Communication Capability
Limited Power Resources
Node may not have Unique ID
Common case - Stationary Nodes
General Architecture (1)
Sensor Network Node Main Components
Sensor Unit
ADC – Analog Digital Converter
CPU – Central Processing Unit
Power Unit
Communication Unit
General Architecture (2)
General Requirements (1)
Varying Network Size
Inexpensive Nodes Equipment
Long Lifetime (Power)
Load-Balancing
Self-Organization
Re-tasking and Querying Capability
General Requirements (2)
Sensible Data Aggregation
Consolidation of Redundant Data
Application Awareness
Tradeoff
Communication for Computation
Possible Mobility
Some WSN Routing challenges and
design issues
Node deployment
Manual deployment
Sensors are manually deployed
Data is routed through predetermined path
Random deployment
Optimal clustering is necessary to allow
connectivity & energy-efficiency
Multi-hop routing
Some WSN Routing challenges and
design issues (contd)
Fault tolerance
Some sensors may fail due to lack of power,
physical damage, or environmental
interference
Adjust transmission power, change sensing
rate, reroute packets through regions with
more power
Some WSN Routing challenges and
design issues (contd)
Network dynamics
Mobile nodes
Mobile events, e.g., target tracking
If WSN is to sense a fixed event,
networks can work in a reactive manner
A lot of applications require periodic reporting
Some WSN Routing challenges and
design issues (contd)
Connectivity
High density high connectivity
Some sensors may die after consuming
their battery power
Connectivity depends on possibly random
deployment
Routing challenges and design issues
(contd)
Data routing methods
Application-specific
Time-driven: Periodic monitoring
Event-driven: Respond to sudden changes
Query-driven: Respond to queries
Hybrid
Routing challenges and design issues
(contd)
Transmission media
Wireless channel
Limited bandwidth: 1 – 100Kbps
Using MAC (Link Layer)
Contention-free, e.g., TDMA (Time Division
Multiple Access) or CDMA (Code Division
Multiple Access)
Contention-based, e.g., CSMA (Carrier Sense
Multiple Access), MACA (Multiple Access with
Collision Avoidance), or 802.11
Putting all together: Motivation
Properties of Sensor Networks
Data centric
No central authority
Resource constrained
Nodes are tied to physical locations
Nodes may not know the topology
Nodes are generally stationary
How can we get data from the sensors? Using Conventional
Routing Protocols? Using MANET Routing Protocols? No and Yes!
No: We need WSN Routing Protocols; Yes: WSN Routing
protocols based on the conventional and MANET ones.
WSN Routing Protocols
for CSE4PND
Reactive
Proactive
Clustered/ Flat/Data-C Clustered/
Flat/Data Hierarchical
Hierarchical entric
-Centric
SPIN LEACH Directed TEEN
Diffusio
n
18
Routing Protocols in WSNs
I. Flat
II. Hierarchical
III. Location-based (excluded for
CSE4PND)
IV. QoS-based (excluded for CSE4PND)
I. Flat routing
Flat routing by conventional
Flooding, but …
Too much waste
Implosion & Overlap
Use in a limited scope, if
necessary
That is, unsuitable for most
WSNs
Flat routing by data-centric
routing
No globally unique ID
Naming based on data
attributes
That is, individual nodes are
unimportant
Egs: SPIN, Directed
Diffusion, ...
Sensor Protocol for Information via Negotiation
SPIN
n Data centric and proactive (getting ready
Protocol Highlights
all paths to named data)
n Network-wide broadcast Limited by
negotiation and using local communication
n Flooding problems solved:
Implosion – same data from many neighbors
Detection of overlapping regions
Excessive resources consumption (Blindness)
n Needs only localized information
Sensor Protocol for Information via Negotiation
SPIN
Broadcast - limited scale –
Main Drawbacks
n
every node handles O(n) messages
n Data is updated throughout network –
unnecessary in many cases
n Network (power) lifetime - good
n High degree nodes = High power needs
Sensor Protocol for Information via Negotiation
SPIN
Main Procedures
Data is described by meta-data ADV msg.
Source node (say Node A) has data sends ADV to
neighbors
If neighbor does not have data sends REQ
Node A responds by sending the DATA
This process continues around the network
Nodes may aggregate their data to ADV
In a lossy network ADV or REQ may be repeated
periodically, if they are not answered respectively
SPIN (Sensor Protocols for Information via
Negotiation) - next few slides for illustrations
Sensor Protocol for Information via Negotiation
SPIN
Node with data
Illustrations
ADV
Node with data advertises to all its neighbors
Sensor Protocol for Information via Negotiation
SPIN
Node with data
Illustrations
REQ
Neighbor requests for data and it is sent
Sensor Protocol for Information via Negotiation
SPIN
DATA Node with data
Illustrations
Node with data advertises to all its neighbors
Sensor Protocol for Information via Negotiation
SPIN
Node with data
Illustrations
ADV
Receiving node sends ADV to neighbors
Sensor Protocol for Information via Negotiation
SPIN
Node with data
Illustrations
Already
has data
(or dead)
REQ
Receiving neighbors requests for data.
Sensor Protocol for Information via Negotiation
SPIN
Node with data
Illustrations
DATA
Receiving node sends ADV to neighbors
SPIN
Pros
Each node only needs to know its one-hop
neighbors
Significantly reduce energy consumption compared
to flooding
Cons
Data advertisement cannot guarantee the delivery
of data
If the node interested in the data are far from the
source, data will not be delivered
Not good for applications requiring reliable data delivery,
e.g., intrusion detection
Directed Diffusion: Main Features
data centric and reactive (Sink looking for named
data; constructing a path to named data when
required)
Request (on-demand) driven
Sinks place requests as interests
(requests/queries/RREQ)
Sources (Named data) satisfying the interest can
be found
Intermediate nodes route data toward sinks
Localized repair and reinforcement
Multi-path delivery for multiple sources, sinks, and
queries
Directed Diffusion (DD)
DD: a Snapshot
A query for named data (interest) is
Main Procedures
broadcast by a node (sink)
Query reaches relevant sensor sources
This sets up exploratory gradients (forward
paths)
Once data is available in a Source
it is sent Back via Reinforced Path
Failing Links / nodes are being gradually
bypassed
Directed Diffusion: Motivating Example
Sensor nodes are monitoring animals
Users are interested in receiving data
for all 4-legged creatures seen in a
rectangle
Users specify the data rate
Directed Diffusion: Interest and Event
Naming (Forward Path)
Query/interest (from Sink):
1. Type=four-legged animal
2. Interval=20ms (event data rate)
3. Duration=10 seconds (time to cache)
4. Rectangle =[-100, 100, 200, 400]
Reply (from Source or from an intermediate sensor
node with previously cached data – forward path) :
1. Type=four-legged animal
2. Instance = elephant
3. Location = [125, 220]
4. Intensity = 0.6
5. Confidence (probability) = 0.85
6. Timestamp = 01:20:40
Attribute-Value pairs, no advanced naming
scheme
Directed Diffusion: Interest/Request
Propagation
Flood interest/request
Constrained or Directional flooding based on location is possible
Directional propagation based on previously cached data
Interest = Request/Query
Gradient = forward path
Gradient
Source Interest
Sink
Directed Diffusion: Data Propagation
Multipath routing
Consider each gradient’s link quality
Select the preferred path/route
(reinforcement) for forwarding data.
Gradient
Source Data
forward
path
Sink
Directed Diffusion: Reinforcement
Reinforce one of the neighbor after receiving initial
data.
Neighbor who consistently performs better than others
Neighbor from whom most events received
Reinforcement = preferred path for the Sink-Source (to-
and-forth) link.
Source Data -
Reinforcement
Request-
Reinforcement
Sink
Directed Diffusion: Negative
Reinforcement (path maintenance)
Explicitly degrade the path by re-sending interest with lower
data rate.
Time out: Without periodic reinforcement, a gradient will be
torn down
Gradient
Source Data
Reinforcement
Sink
Directed Diffusion: Summary of the
protocol
Directed Diffusion
DD – Another Example CLASS_KEY IS INTEREST_CLASS
LONGITUDE_KEY GE 10
LONGITUDE_KEY LE 50
LATITUDE_KEY GE 100
Illustrations
LATITUDE_KEY LE 120
SENSOR EQ MOVEMENT
Source INTENSITY GE 0.6
CONFIDENCE GE 0.7
INTERVAL IS 10
EXPIRE_TIME IS 100
Sink
Directed Diffusion
DD: another Example (contd)
FilterAttrVec
CLASS_KEY EQ DATA_CLASS
Illustrations
SENSOR EQ MOVEMENT
INTENSITY GE 0.7
Source 3. addFilter (FilAttrVec, FilterCallback)
1. subscribe (InterestAttrVec, Callback) 2. subscribe (AttrVec, ApplCallback)
InterestAttrVec
CLASS_KEY EQ INTEREST_CLASS
LONGITUDE_KEY IS 35
LATITUDE_KEY IS 110
SENSOR IS MOVEMENT
Sink
Directed Diffusion
1. Interests Setting up
DD (contd) gradients (Path
Discovery)
Illustrations
Source
Sink
Interest = Query/Request
Gradient = Forward path
Directed Diffusion
DD (cont)
2. Sending data
…(Data Forward)
Illustrations
Source
4. h = publish (SensedAttrVec)
5. send (h, SensedAttrVec)
SensedAttrVec Sink
CLASS_KEY IS DATA_CLASS
LONGITUDE_KEY IS 35
LATITUDE_KEY IS 110
SENSOR IS MOVEMENT
INTENSITY IS 0.8
CONFIDENCE IS 0.7
Low rate event
Directed Diffusion
DD (cont)
Illustrations
Source m1 6. FilterCallback.recv (Message m1)
a
m1 m2 m2
CLASS_KEY IS DATA_CLASS
b LONGITUDE_KEY IS 35
m2 LATITUDE_KEY IS 110
SENSOR IS MOVEMENT
INTENSITY IS 0.8
CONFIDENCE IS 0.8
7. sendMessage (Message new)
Low rate event
Directed Diffusion
DD (contd)
Illustrations
Source 8. ApplCallback.recv (NRAttrVec)
Sink
Low rate event
Directed Diffusion
DD (contd) … and Reinforcing the
best path
Illustrations
CLASS_KEY IS INTEREST_CLASS
LONGITUDE_KEY GE 10
LONGITUDE_KEY LE 50
LATITUDE_KEY GE 100
Source LATITUDE_KEY LE 120
SENSOR EQ MOVEMENT
INTENSITY GE 0.6
CONFIDENCE GE 0.7
INTERVAL IS 1
EXPIRE_TIME IS 90
Sink
Low rate event Reinforcement = Increased interest
Directed Diffusion
DD: Node failure
Illustrations
Source
Sink
Recovering
from node failure
Low rate event
Reinforcement
High rate event
Directed Diffusion
DD: Path recovery from a node failure
Illustrations
Source
Sink
Stable path
Low rate event
High rate event
Directed Diffusion
DD: Broken link
Illustrations
Source
Sink
Recovering
from link failure
Low rate event
Reinforcement
High rate event
Directed Diffusion
DD: Path Recovery from a broken
link
Illustrations
Source
Sink
Stable path
Low rate event
High rate event (Reinforcement)
Directed Diffusion: Pros & Cons
Different from SPIN in terms of on-demand data querying
mechanism
Sink floods interests only if necessary
A lot of energy savings
In SPIN, sensors advertise the availability of data
Pros
Data centric: All communications are neighbor to neighbor with no
need for a node addressing mechanism
Each node can do aggregation & caching
Cons
On-demand, query-driven: Inappropriate for applications requiring
continuous data delivery, e.g., environmental monitoring
Attribute-based naming scheme is application dependent
For each application it should be defined a priori
Extra processing overhead at sensor nodes
II. Hierarchical Routing
Low Energy Adaptive Clustering Hierarchy
LEACH
Illustrations
Low Energy Adaptive Clustering Hierarchy
LEACH (Multi-level /hierarchical clustering)
Illustrations
Low Energy Adaptive Clustering Hierarchy
LEACH
Proactive, Self-Organizing – Adaptive
Protocol Highlights
Clustering
Cluster-Heads elect themselves –
by “Random Round-Robin” or
Power-Based Probability
Low Energy Adaptive Clustering Hierarchy
LEACH: Routing
Works in Rounds (cluster periods): each round/cluster
Main Procedures
period (h = 0, 1, 2, … ) with
Set-Up (Shorter h) and Steady-State (Longer h)
Set-Up Phase - subdivided:
h = 0: Advertisement (I am a Cluster-Head)
h = 1: Cluster Set-Up (I am in your Cluster)
h =2: Schedule Creation (This is your slot)
Steady-State Phase:
h = 3, …: Data Transmission using TDMA (Time
Division Multiple Access)
Low Energy Adaptive Clustering Hierarchy
LEACH
Every node uses the same channel
Main Procedures
Different clusters use different CDMA
(Code Division Multiple Access) codes
Code chosen in random
Data signal + random code = Transmitted signal at
various speeds -> spread spectrum
Cluster-Heads communicate with Sink
Can be extended to Hierarchical/Multi-
Layer Clustering
LEACH
Pros
Distributed, no global knowledge required
Energy saving due to aggregation by CHs
Shortcomings
LEACH assumes all nodes can transmit with enough power
to reach BS if necessary (e.g., elected as CHs)
Each node should support both TDMA & CDMA
LEACH (summary)
Cluster-based protocol
Each node randomly decides to become a cluster head (CH)
CH chooses the code to be used in its cluster
CH broadcasts Adv; Each node decides to which cluster it
belongs based on the received signal strength of Adv
Nodes can sleep when it’s not their turn to transmit
CH compresses data received from the nodes in the cluster and
sends the aggregated data to BS (Base Station/ Sink)
CH is rotated randomly
Threshold sensitive Energy Efficient Sensor
Network (TEEN)
TEEN: Hierarchical clustering – single
level or multi-level
Threshold sensitive Energy Efficient Sensor Network
TEEN: Routing Snapshot
n One cluster period (h = 0, 1, 2, …) consisting of Phase I
Main Procedures
and Phase II.
n Phase I: TEEN sets up clusters and Cluster Heads as in
LEACH
n Phase II: A node transmitting data (see next slide)
Threshold sensitive Energy Efficient Sensor Network
TEEN: Routing Snapshot
n Phase II: A node transmits data in a timeslot h, only if :
Main Procedures
its sensed data is greater than a Hard Threshold
(HT) (ie data in the range of interest set by Sink) –
sent by Cluster Head; and
its sensed data differs from last transmitted value (
variable SV ) by more than a Soft Threshold (ST) (ie
the amount of change must be = or > ST set by Sink)
– sent by CH
n After transmission SV is updated/assigned with the
value of the currently transmitted data
Cluster Heads need to listen constantly
Cluster Heads are rotated randomly in each cluster
TEEN (in perspective)
Reactive, event-driven protocol for time-critical
applications
A node senses the environment continuously, but turns radio
on and xmit only if the sensor value changes drastically
No periodic xmission
Don’t wait until the next period to xmit critical data
Save energy if data is not critical
CH sends its members a hard & a soft threshold
Hard threshold: A member only sends data to CH only if data
values are in the range of interest
Soft threshold: A member only sends data if its value
changes by at least the soft threshold
Every node in a cluster takes turns to become the CH for a
time interval called cluster period
Hierarchical clustering
TEEN (pros & cons)
Good for time-critical applications
Energy saving
Less energy than proactive approaches
Soft threshold can be adapted
Hard threshold could also be adapted depending on
applications
Inappropriate for periodic monitoring, e.g.,
habitat monitoring
Ambiguity between packet loss and
unimportant data (indicating no drastic
change)
TEEN (pros & cons) - contd
Compared to LEACH, TEEN consumes less energy
Network lifetime: TEEN ≥ LEACH
Drawbacks of TEEN
Overhead & complexity of forming clusters in multiple levels
and implementing threshold-based functions
Comparison between SPIN, Directed
Diffusion, LEACH & TEEN
SPIN DD LEACH TEEN
Optimal No Yes No No
Route
Network Good Good V Good Excellent
Lifetime