PROTOCOLS AND ARCHITECTURES
FOR WIRELESS SENSOR NETWORKS
UNIT – 4
ROUTING PROTOCOLS FOR WSN
CLASSIFICATION OF ROUTING
PROTOCOLS IN WSN
• A routing protocol specifies how routers
communicate with each other to distribute
information that enables them to select routes
between nodes.
• Classification of Routing Protocols:
– Proactive or table-driven routing protocols –
Maintain routing information in the routing table –
Routing information is flooded in the whole network
– Runs path-finding algorithm with the routing table
– Reactive or on -demand routing protocols –
Obtain the necessary path while required
– Hybrid routing protocols – In the zone of given
node : use table-driven – Out of the zone of given
node : use on-demand 2
CLASSIFICATION OF ROUTING
PROTOCOLS IN WSN
3
DESIGN ISSUES
• The design of routing protocols in WSNs is influenced
by many challenging factors.
– Node deployment: Node deployment in WSNs is
application dependent and affects the performance
of the routing protocol. The deployment is either
deterministic (manual) or self-organizing (random).
In deterministic situations, the sensors are
manually placed and data is routed through pre-
determined paths. Whereas in self-organizing
systems, the sensor nodes are scattered randomly
creating an infrastructure in an ad hoc manner.
– Energy Conservation: During the creation of an
infrastructure, the process of setting up the routes
is greatly influenced by energy considerations.
Since the transmission power of a wireless radio4 is
proportional to distance squared or even higher
DESIGN ISSUES
• The design of routing protocols in WSNs is influenced
by many challenging factors.
– Scalability: The number of sensor nodes deployed
in the sensing area may be in the order of hundreds
or thousands, or more. Any routing scheme must be
able to work with this huge number of sensor
nodes. In addition, sensor network routing protocols
should be scalable enough to respond to events in
the environment.
– Network dynamics: Most of the network
architectures assume that sensor nodes are
stationary, because there are very few setups that
utilize mobile sensors. It is sometimes necessary to
support the mobility of sinks or cluster heads
(gateways). 5
DESIGN ISSUES
• The design of routing protocols in WSNs is
influenced by many challenging factors.
– Sensor network topology: It must be
maintained even with very high node density.
– Environment: Nodes should be operating in
inaccessible location because of hostile
environment.
– Production Costs: The cost of a single node
must be low.
– Hardware Constraint: All Subunits of sensor
node (e.g. sensing, processing, communication,
power, location finding system and mobilizer)
must consume extremely low power and be
contained within an extremely small volume. 6
Ad Hoc On-Demand Distance Vector
Routing (AODV)
• DSR includes source routes in
packet headers
• Resulting large headers can
sometimes degrade performance
– particularly when data contents of a
packet are small
• AODV attempts to improve on DSR
by maintaining routing tables at the
nodes, so that data packets do not
have to contain routes
• AODV retains the desirable feature
Ad Hoc On-Demand Distance Vector
Routing (AODV)
• Route Requests (RREQ) are forwarded in a
manner similar to DSR
• When a node re-broadcasts a Route Request, it
sets up a reverse path pointing towards the
source
– AODV assumes symmetric (bi-directional) links
• When the intended destination receives a
Route Request, it replies by sending a Route
Reply (RREP)
• Route Reply travels along the reverse path set-
up when Route Request is forwarded
Ad Hoc On-Demand Distance Vector
Routing (AODV)
Route Requests in AODVY
Z
S E
F
B
C M L
J
A G
H D
K
I N
Represents a node that has received RREQ for D from S
Ad Hoc On-Demand Distance Vector
Routing (AODV)
Route Requests in AODV
Y
roadcast transmission
Z
S E
F
B
C M L
J
A G
H D
K
I N
Represents transmission of RREQ
Ad Hoc On-Demand Distance Vector
Routing (AODV)
Route Requests in AODV
Y
Z
S E
F
B
C M L
J
A G
H D
K
I N
Represents links on Reverse Path
Ad Hoc On-Demand Distance Vector
Routing (AODV)
Reverse Path Setup in AODV
Y
Z
S E
F
B
C M L
J
A G
H D
K
I N
• Node C receives RREQ from G and H, but does not
forward it again, because node C has already
forwarded RREQ once
Ad Hoc On-Demand Distance Vector
Routing (AODV)
Reverse Path Setup in AODV
Y
Z
S E
F
B
C M L
J
A G
H D
K
I N
Ad Hoc On-Demand Distance Vector
Routing (AODV)
Reverse Path Setup in AODV
Y
Z
S E
F
B
C M L
J
A G
H D
K
I N
• Node D does not forward RREQ, because node D
is the intended target of the RREQ
Ad Hoc On-Demand Distance Vector
Routing (AODV)
Forward Path Setup in AODV
Y
Z
S E
F
B
C M L
J
A G
H D
K
I N
Forward links are setup when RREP
travels along the reverse path
Represents a link on the forward path
Ad Hoc On-Demand Distance Vector
Routing (AODV)
Route Request and Route Reply
• Route Request (RREQ) includes the last known
sequence number for the destination
• An intermediate node may also send a Route
Reply (RREP) provided that it knows a more
recent path than the one previously known to
sender
• Intermediate nodes that forward the RREP,
also record the next hop to destination
• A routing table entry maintaining a reverse
path is purged after a timeout interval
• A routing table entry maintaining a forward
path is purged if not used for a
Ad Hoc On-Demand Distance Vector
Routing (AODV)
Link Failure
• A neighbor of node X is considered
active for a routing table entry if the
neighbor sent a packet within
active_route_timeout interval which
was forwarded using that entry
• Neighboring nodes periodically
exchange hello message
• When the next hop link in a routing
table entry breaks, all active neighbors
are informed
Ad Hoc On-Demand Distance Vector
Routing (AODV)
Route Error
• When node X is unable to forward packet P
(from node S to node D) on link (X,Y), it
generates a RERR message
• Node X increments destination sequence
number for D cached at node X
• The incremented sequence number N is
included in the RERR
• When node S receives the RERR, it initiates a
new route discovery for D using destination
sequence number at least as large as N
MULTICASTING VS. BROADCASTING
MULTICASTING
• Routing protocols offering efficient
multicasting in wired networks may fail
to keep up with node movements and
frequent topological changes.
• Broadcast protocols cannot be used
either as multicasting requires a
selected set of nodes to receive the
message.
• All multicast algorithms depend on the
topology of the network Majority of
applications requiring rapid deployment
and dynamic reconfiguration, need
multicasting such as military
battlefields, emergency search and
rescue sites, classrooms, and
MULTICAST ROUTING PROTOCOLS
Broadcast protocols cannot be used as
multicasting requires a selected set of MHs
to receive the message
Protocols are classified into four categories
based on how route to the members of the
group is created:
Tree-Based Approaches
Meshed-Based Approaches
Stateless Multicast
Hybrid Approaches
TREE-BASED APPROACHES
A packet traverses each hop and node in
a tree at most once
Very simple routing decisions at each
node
Tree structure built representing shortest
paths amongst nodes, and a loop-free
data distribution structure
Even a link failure could mean
reconfiguration of entire tree structure,
could be a major drawback
Consider either a shared tree or establish
a separate tree per each source
For separate source trees, each router
in multiple router groups must
maintain a list of pertinent information
ILLUSTRATION OF TREE-BASED
MULTICAST
Nodes not a part
of Multicast
group
1 1
Source
0 2
1 1
2 2
2
3 3
3
TREE-BASED APPROACHES
Ad hoc Multicast Routing Protocol Utilizing Increasing Id-Numbers
Utilizing Increasing id-numberS (AMRIS) is an on-demand protocol,
which constructs a shared multicast delivery tree to support
multiple senders and receivers in a multicast session
AMRIS dynamically assigns an id-number to each node in each
multicast session and a multicast delivery tree – rooted at a special
node with Sid (Smallest-ID and is usually a source that initiates a
multicast session) – is created and the id-number increases as the
tree expands from the Sid
In case of multiple senders, a Sid is selected among the given set
of senders
Once a Sid is identified, it sends a NEW-SESSION message to its
neighbors
This message includes Sid’s msm-id (multicast session member id)
and the routing metrics
Nodes receiving the NEW-SESSION message generate their own
msm-ids, which is larger than the msm-id of the sender
In case a node receives multiple NEW-SESSION messages from
different nodes, it keeps the message with the best routing metrics
and calculates its msm-ids
To join an ongoing session, a node checks the NEW-SESSION
message, determines a parent with smallest msm-ids, and unicast
a JOIN-REQ to its potential parent node
If parent node is already in the multicast delivery tree, it replies
with a JOIN-ACK.
If a node is unable to find any potential parent node, it executes a
branch reconstruction (BR) process to rejoin the tree
TREE-BASED APPROACHES
Ad hoc Multicast Routing Protocol Utilizing
Increasing Id-Numbers (AMRIS)
Packet forwarding example
• Nodes X and 34 are sources
• Nodes 11, 24, and 28 are recipients
ROUTE-DISCOVERY AND JOIN FOR
MULTICAST
Multicast Ad hoc On-Demand Distance Vector
Protocol
Follows directly from the unicast AODV
Discovers multicast routes on-demand using a broadcast
route discovery mechanism employing the same Route
Request (RREQ) and Route Reply (RREP) messages
A MH originates a RREQ message when it wishes to join a
multicast group, or when it has data to send to a multicast
group but it does not have a route to that group
Only a member of the desired multicast group may
respond to a join RREQ
If the RREQ is not a join request, any node with a fresh
enough route to the multicast group may respond
As the RREQ is broadcasted across the network, nodes set
up pointers to establish the reverse route in their route
tables
A node receiving a RREQ first, updates its route table to
record the sequence number
For join RREQs, an additional entry is added to the
multicast route table and is not activated unless the route
is selected to be a part of the multicast tree
MULTICAST ON-DEMAND DISTANCE
VECTOR
ROUTING
Multicast Ad hoc On-Demand Distance
Vector Protocol
Follows directly from the unicast AODV
Multicast
Member
MESH – BASED APPROACH
Mesh-based multicast protocols may have
multiple paths between any source and
receiver pairs.
Mesh-based protocols seem to outperform tree-
based proposals due to availability of
alternative paths.
A mesh has increased data-forwarding
overhead.
The redundant forwarding consumes more
bandwidth.
The probability of collisions is higher when a
larger number of packets are generated.
MESH – BASED APPROACH
On-Demand Multicast Routing
Protocol
Core-Assisted Mesh Protocol
Forwarding Group Multicast
Protocol
MESH – BASED APPROACH
On-Demand Multicast Routing Protocol
Mesh-based protocol employing a forwarding group
concept.
Only a subset of nodes forwards the multicast packets.
No explicit control message is required to leave the
group.
The group membership and multicast routes are
established and updated by the source on demand.
If no route to the multicast group, a multicast source
broadcasts a Join-Query control packet to the entire
network.
This Join-Query packet is periodically broadcasted to
refresh the membership information and updates routes
MESH – BASED APPROACH
On-Demand Multicast Routing Protocol
After establishing a
forwarding group and route
construction process, a
source can multicast packets
to receivers via selected
routes and forwarding
groups
To leave the group, source
simply stops sending Join-
Query packets
If a receiver no longer wants
to receive from a particular
multicast group, it does not
send the Join-Reply for that
group
MESH – BASED APPROACH
Core-Assisted Mesh Protocol
Supports multicasting by creating a
shared mesh for each multicast group.
Meshes thus created, helps in
maintaining the connectivity to the
multicast users, even in case of node
mobility.
It borrows concepts from CBT, but the
core nodes are used for control traffic
needed to join multicast groups.
Assumes a mapping service by building
and maintaining the multicast mesh.
Nodes are classified as: simplex, duplex
and non-member.
MESH – BASED APPROACH
Forwarding Group Multicast Protocol
Can be viewed as flooding with
“limited scope”.
Flooding is contained within a selected
forwarding group (FG) nodes.
Makes innovative use of flags and an
associated timer to forward multicast
packets.
Uses two approaches to elect and
maintain FG of forwarding nodes:
THANK
YOU
34
