protocols

On-Demand Multicast Routing Protocol in Multihop Wireless Mobile Networks (ODMRP)

Introduction

Issues in Ad Hoc Networks

Bandwidth Constraints

Frequent Topology changes

Limited Battery power

Problems with Current Multicast Routing Protocols

They have a tree based structure, so as the node connectivity changes, the tree structures changes accordingly.

Multicast trees require a global routing substructureinvolving excessive channel and processing overhead

ODMRP

Provides a richer connectivity among multicast members using a mesh based approach

Supplies multiple route for one particular destination

– Helps in case of topology changes and node failure

Uses a concept of Forwarding Group

– Only a subset of nodes forwards multicast packets via scoped flooding

Basic Operation of ODMRP

On Demand Route and Mesh Creation

Join Query Join Reply

S floods a Join Query to entire network to refresh membership.

Receiving node stores the backward learning into routing table and rebroadcasts the packet.

Finally when query reaches a receiver creates a Join Reply and broadcasts its to its neighbors.

Node receiving the Join Reply checks whether the next node id in Join Reply matches it own. If yes , it is a part of the forwarding group, sets its

FG_FLAG and broadcasts its join reply built upon matched entries.

Join Reply is propagated by each forwarding group member until it reaches source via a shortest path.

Routes from sources to receivers builds a mesh of nodes called “forwarding group”.

1

SR

R

R R

R

Concept of Forwarding Group Why a mesh?

Links

Multicast Routes

Initial Route from S1 to R2 is < S1 -A- B- R2>

Redundant Route < S1- A- C- B- R2>

Reliability in ODMRP

Reliable transmission of Join Replies plays an important role in establishing and refreshing multicast routes, hence proper care should be taken for delivering the Join packets properly.

As Join replies are broadcasted to more than one upstream neighbors, IEEE 802.11 MAC protocol fails here. (e.g. Join Reply from R1).

Two approaches to solve this problem:

Sub-divide the join Replies into separate sub-tables, one for each distinct node. For e.g. Split the Join Reply at R1 into I1 and I2 and unicast these packets.

It works good if the number of neighbors are limited.

Passive Acknowledgement

Source should send an active acknowledgement to the previous hop.

Issues:

Hidden Terminal Problem: Node may not hear acknowledgement from its upstream neighbors.

It can be solved by carrying out retransmissions in unicast mode to selected neighbors with reduced sub-tables. An alternate route must be found “on spot” if packet delivery cannot be verified after certain no. of transmissions

Finding a route “ On spot “

Each node broadcasts a packet to its neighbors specifying that the next hop to a set of sources is unreachable.

If a node upon receiving this packet has a route to the multicast source, it unicasts a Join reply to its next hop neighbors .

If no route is known it simply broadcasts the packet specifying that the next hop is unavailable.

2

FG

FG

FG FG

FGFG R1

B C R3

AS1

R2

S2S3

In both cases it sets its FG_FLAG.

It helps in establishing an alternate path until a more efficient route is established during the next refresh phase.

Data Forwarding

A node forwards the received multicast data packet only when it is not a duplicate one and the setting of FG_FLAG for that multicast group has not expired.

Soft state

No explicit control packet need to be sent to join or leave a group.

If a multicast source wants to leave a group, it simply stops sending the JOIN QUERY packets.

If a receiver o longer wants to receive from a multicast group it does not send the JOIN REPLY for that group.

Forwarding nodes are demoted to non-forwarding nodes if not refreshed( no Join Replies received) before they timeout.

Unicast Capability

It can operate as an unicast routing protocol also as well as coexist with any unicast routing protocol.

Selection of Timer values

For Route Refresh Interval

– Small Route Refresh Interval used Fresh route Information and membership information obtained. Flow of more packets causing network congestion.

– Large Route Refresh Interval used Up to date information about the nodes in the network is not known.

– Less control traffic generated .

For Forwarding group timeout Interval

– In heavy network load, timeout values should be small so that unnecessary nodes can timeout quickly and create excessive redundancy.

– In network with high mobility, the forwarding group timeout value must be larger so that alternate paths can be provided.

– Generally forwarding group timeout value must be 3 to 5 times larger than the route refresh Interval

Required Data Structures

Route table

– Entry is updated upon receiving a JOIN QUERY.

– Stores the destination (source of the Join Query) and the next hop destination (node from which Join Query is received from).

Forwarding Group Table

3

– Every node in the forwarding group maintains the group information. It records the multicast group id and the time when the node was last refreshed is recorded.

Message cache

– Every node maintains this structure to detect duplicate.

– Whenever a node receives a Join query or a data packet it stores the source ID and the sequence number of the packet.

– Entries in here are not permanent.

Adapting the Refresh Interval via Mobility Prediction

Periodic flooding of Join query to refresh routes and group membership is not a good idea due to bandwidth constraints.

Enhancing the performance of ODMRP demands selection of an optimal route interval .

GPS (Global positioning system) provides location and mobility information of a node. Thus Join Queries can be sent only when route breaks of ongoing data session are imminent.

In the paper, assumption is made that the clocks are synchronized by NTP or GPS itself at boot time.

By the knowledge of speed, direction and radio propagation range, one can determine how long a node will remain connected.

Steps taken for Mobility Prediction

Along with the Join query which the source sends, it also appends Location, Speed and Direction.

Source sets the MIN_LET( Minimum Link Expiration Time) field to MAX_LET_VALUE since the source does not know any previous hop node.

Next hop neighbor predicts the LET by using the showed equation.

The minimum between the value and the MIN_LET value from the Join Query received is overwritten in the packet and sent. The location , speed and direction are also overwritten by its own value.

Join Query upon reaching the multicast member, the predicted LET of the Last link is calculated and the minimum of the two (LET and MIN_LET in Join Query) is chosen to be the RET( Route Expiration Time)

The RET is enclosed in Join Reply and is broadcasted.

Nodes in a forwarding group when receive multiple join replies , the one with the minimum RET is chosen, attached to the packet and broadcasted.

Source on receiving multiple Join Replies chooses one with minimum RET

Advantages of Mobility Prediction

The whole idea of calculating the RET is new routes should be built via flooding before the minimum RET approaches.

A minimum of a refresh interval should be set MIN_REFRESH_INTERVAL . It is required in case of high mobility of nodes to avoid excessive flooding.

4

A maximum of a refresh interval should be set MAX_REFRESH_INTERVAL . This is required when the mobility of nodes is very slow.

It may happen that a node suddenly moves out, new routes wont be constructed on time.

It is also required if a new non-member node wants to join the group.

Route Selection Criteria

Generally multicast receiver selects routes based on the minimum delay.

Instead, a receiver can choose the most stable route one with the maximum RET.

In this case the receiver needs to wait for some appropriate amount of time after the first join query calculate all possible routes and select on with largest RET and broadcasts the Join Reply.

Simulation Analysis

ODMRP was simulated in GloMoSim simulation environment with 4 other multicast routing protocols.

Channel and Radio was assumed to be a free space propagation model.

The IEEE 802.11 MAC with Distribution Coordination function (DCF) was used.

ORMRP implementation was carried out without mobility prediction scheme.

Metrics considered for Simulation

Packet Delivery Ratio

Number of packets transmitted per data packet delivered

Number of control bytes transmitted per data byte delivered

Number of control and data packets transmitted per data packet delivered

Simulation Results

Mobility Speed

Packet delivery ratio as well as the Number of data packets transmitted per data packet delivered is high even when the Mobility speed increases.

Number of control bytes transmitted per data byte delivered as the function of mobility speed remains constant.

Number of Senders

As the number of Senders increases, the performance of ODMRP increases in terms of Packet delivery ratio and Number of data packets transmitted per data packet delivered.

Control Packet overhead is high.

Multicast Group Size

Performance of ODMRP is unaffected by the growth in the number of multicast members.

Network Traffic Load

5

As the network load increases, the performance of ODMRP in terms of Packet delivery ratio keeps on decreasing , but its performance is still better than the other 4 protocols implemented.

Conclusion

Features of ODMRP :

– Simplicity

– Low channel and storage overhead

– Usage of Up-to-date shortest routes

– Reliable construction of routes and forwarding group

– Robustness to host mobility

– Maintenance and utilization of multiple paths

– Exploitation of the broadcast nature of the wireless environment

– Unicast routing capability

Area to be looked into:

– ODMRP has a problem of excessive flooding when number of multicast senders are more.

– One solution to this is to make the route refresh as receiver initiated or one can make ODMRP adaptive to the way the network changes.

Ad hoc On-demand Distance Vector (AODV) Routing Protocol

AODV Overview

AODV is a packet routing protocol designed for use in mobile ad hoc networks (MANET)

Intended for networks that may contain thousands of nodes

One of a class of demand-driven protocols

– The route discovery mechanism is invoked only if a route to a destination is not known

UDP is the transport layer protocol

Source, destination and next hop are addressed using IP addressing

Each node maintains a routing table that contains information about reaching destination nodes.

Each entry is keyed to a destination node.

Routing Table Fields

Destination IP address

Destination Sequence Number

6

Valid Destination Sequence Number Flag

Other state and routing flags

Network Interface

Hop Count (needed to reach destination)

Next Hop

Precursor List

Lifetime (route expiration or deletion time)

Overview (continued)

Routing table size is minimized by only including next hop information, not the entire route to a destination node.

Sequence numbers for both destination and source are used.

Managing the sequence number is the key to efficient routing and route maintenance

– Sequence numbers are used to indicate the relative freshness of routing information

– Updated by an originating node, e.g., at initiation of route discovery or a route reply.

– Observed by other nodes to determine freshness.

The basic message set consists of:

– RREQ – Route request

– RREP – Route reply

– RERR – Route error

– HELLO – For link status monitoring

AODV Operation – Message Types

RREQ Messages

– While communication routes between nodes are valid, AODV does not play any role.

– A RREQ message is broadcasted when a node needs to discover a route to a destination.

– As a RREQ propagates through the network, intermediate nodes use it to update their routing tables (in the direction of the source node).

– The RREQ also contains the most recent sequence number for the destination.

– A valid destination route must have a sequence number at least as great as that contained in the RREQ.

AODV Operation – Message Types

RREP Messages

7

– When a RREQ reaches a destination node, the destination route is made available by unicasting a RREP back to the source route.

– A node generates a RREP if:

It is itself the destination.

It has an active route to the destination. Ex: an intermediate node may also respond with an RREP if it has a “fresh enough” route to the destination.

– As the RREP propagates back to the source node, intermediate nodes update their routing tables (in the direction of the destination node).

AODV Operation – Message Types

RERR Messages

– This message is broadcast for broken links

– Generated directly by a node or passed on when received from another node

Hello Messages

– Hello Message = RREP with TTL = 1

– This message is used for broadcasting connectivity information.

Ex: If a neighbor node does not receive any packets (Hello messages or otherwise) for more than ALLOWED_HELLO_LOSS * HELLO_INTERVAL mseconds, the node will assume that the link to this neighbor is currently lost.

– A node should use Hello messages only if it is part of an active route.

Message routing

Congestion Handling

One method that AODV handle congestion is:

– If the source node receives no RREP from the destination, it may broadcast another RREQ, up to a maximum of RREQ_RETRIES.

– For each additional attempt that a source node tried to broadcast RREQ, the waiting time for the RREP is multiplied by 2.

DSR is not capable of handling congestion.

8

AB D

FC

G

E

RREQ

RREQ

RREQ

RREQ

RREQ

RREQRRE

Q

RREQ RRE

Q

RREP

RREP

RREP

Source

Destination

Other possible methods to improve AODV congestion handling:

– A route may predict when congestion is about to occur and try to avoid it by reduce the transmission rate.

– Schedule the requests so that it will not overload the network.

AODV Routing

There are two phases

Route Discovery.

Route Maintenance.

Each node maintains a routing table with knowledge about the network.

AODV deals with route table management.

Route information maintained even for short lived routes – reverse pointers.

Entries in Routing Table

Destination IP Address

Destination Sequence Number

Valid Destination Sequence Number flag

Other state and routing flags (e.g., valid, invalid, repairable, being repaired)

Network Interface

Hop Count (number of hops needed to reach destination)

Next Hop

List of Precursors

Lifetime (expiration or deletion time of the route)

DSR maintains additional table entries, causing a larger memory overhead

Discovery

Broadcast RREQ messages.

Intermediate nodes update their routing table

Forward the RREQ if it is not the destination.

Maintain back-pointer to the originator.

Destination generates RREQ message.

RREQ sent back to source using the reverse pointer set up by the intermediate nodes.

RREQ reaches destination, communication starts.

9

Maintenance

Hello messages broadcast by active nodes periodically HELLO_INTERVAL.

No hello message from a neighbor in DELETE_PERIOD,link failure identified.

A local route repair to that next hop initiated.

After a timeout ,error propagated both to originator and destination.

Entries based on the node invalidated.

Information “Freshness” Assured

Each originating node maintains a monotonically increasing sequence number.

Used by other nodes to determine the freshness of the information.

Every nodes routing table contains the latest information available about the sequence number for the IP address of the destination node for which the routing information is maintained.

– Updated whenever a node receives new information about the sequence number from RREQ, RREP, or RERR messages received related to that destination.

AODV depends on each node in the network to own and maintain its destination sequence number.

A destination node increments its own sequence number immediately before it originates a route discovery

A destination node increments its own sequence number immediately before it originates a RREP in response to a RREQ

The node treats its sequence number as an unsigned number when incrementing accomplishing sequence number rollover.

Destination information is assured by comparing the sequence number of the incoming AODV message with its sequence number for that destination.

RERR Messages

Message is broadcasted when:

– A node detects that a link with adjacent neighbor is broken (destination no longer reachable).

10

– If it gets a data packet destined to a node for which it does not have an active route and is not repairing.

– If it receives a RERR from a neighbor for one or more active routes.

RERR Processing (for above broadcasts)

Build Affected Destination Listing

– List unreachable destinations containing unreachable neighbor & destination using unreachable as next hop

– Only one unreachable destination, which node already has.

– List of nodes where RERR is next hop

Update information

Transmit RERR for each item listed

RERR – information update

Destination Sequence #

– Update sequence # for case i and ii

– Copy sequence # for case iii

Invalidate route entry

Update Lifetime field as (currtime + DELETE_PERIOD)

Only now may route entry be deleted

RERR message transmission

Unicast

– Send RERR to single recipient

Unicast iteritive

– Send RERR to a number of recipients individually

Broadcast

– Notify multiple recipients simultaniously

– Broadcast via 255.255.255.255 TTL = 1

RERR message transmission

Unicast

– A node detects that a link with adjacent neighbor is broken (destination no longer reachable).

– If it gets a data packet destined to a node for which it does not have an active route and is not repairing.

– If it receives a RERR from a neighbor for one or more active routes.

Unicast iteritive

Broadcast

11

How Broken Links are Handled

All nodes directly using the broken link get a RERR packet.

Then those nodes sends the RERR packet to their predecessor nodes.

This is continued all the way to the source nodes.

Upon completion of sending the RERR packet through the source node will no longer use the link.

AODV uses loop free-routes.

There are only a finite number of nodes in a ad-hoc network.

DSR does not remove the path as well.

In DSR nodes in the network can still think the broken link is still valid.

This can lead to having to search for new paths multiple times.

Reestablishing a Link

The source node can restart the discovery process if a path is still needed.

The source node or any node on the path can rebuild the route by sending out a RREQ.

The Dynamic Source Routing Protocol

Dynamic Source Routing (DSR) Protocol

The DSR is a simple and efficient protocol for routing in mobile, ad hoc and wireless networks.

DSR is suitable for routing in multi-hop networks.

A mobile, ad hoc network is completely self-organizing while using the DSR protocol. All nodes cooperate to forward packets.

The DSR Protocol (I)

Nodes in the network may move about, join or leave.

All routing is automatically determined by the protocol.

The number and sequence of intermediate hops needed to reach any destination may change dynamically. Hence the network topology may be quite complex.

The DSR Protocol (II)

DSR is an on-demand or reactive routing protocol.

When a source node S wants to send a message to a destination node D, the process starts with a route discovery phase.

The message is sent once a route has been discovered and S knows about the discovered route.

12

The DSR Protocol (III)

However, DSR extensively takes advantage of existing knowledge of the network topology.

Each node gathers information about the network topology by overhearing other nodes’ transmissions.

This is known as promiscuous mode of operation and most wireless cards support this (IEEE 802.11 standard).

The DSR Protocol (IV)

Each node maintains a route cache to remember routes that it has learnt about.

One of the main advantages of DSR as opposed to a table driven protocol like DSDV is that the number of control messages is much smaller.

Hence DSR is more energy-efficient and does not congest the network with too many control messages.

An Example when a Route is Discovered Completely

13

BDA

AABC A

BC

EABCD

A is trying to find a route to E

Each intermediate node appends its ID at the end.

E knows the reverse route and sends a route reply.

An Example when a Route is Discovered Partially

Assumptions

All nodes wishing to communicate with other nodes in the ad hoc network participate fully in running the DSR protocol.

The diameter of the network is more than 1, but usually a small number.

In other words, a message usually goes through only a small number of hops.

The nodes may move at any time without notice and may even move continuously.

However, we assume that the speed with which the nodes move is moderate with respect to the packet transmission latency or wireless transmission range of the network.

If the nodes move extremely fast, the only possible protocol is flooding.

Each node selects a single IP address by which it is known in the network.

This is necessary for assigning a unique ID for each node.

Each node may or may not work in the promiscuous mode. However, most wireless interface cards support this.

Overview and Important Properties

The DSR protocol has two important mechanisms through which the protocol operates.

Route Discovery : A node S wishing to send a packet to node D obtains a route to D

Route Maintenance : When S is using a discovered route to D, S may detect that the route is broken. In such cases, S may use an alternate route to D (if it is known), or start another route discovery phase to D.

14

AA

BABC

D

E

A is trying to find a route to E

C already has a route to E in its route cache.

C sends back the complete route to A.

Overview of the DSR Protocol

Route discovery and route maintenance operate entirely on-demand.

There is no need to broadcast periodically to update routing information in individual nodes. DSDV requires such periodic broadcasts.

The number of overhead packets is much smaller in DSR. The number of overhead packets drop to zero when the nodes are static and all routes have been discovered.

When nodes are mobile and/or communication pattern changes, the number of overhead packets increase proportionately.

It is necessary to discover new routes in these situations and hence the new route discovery packets are the overhead packets.

Note that, a node may receive multiple routes to a destination in response to a route discovery request.

A node may store multiple routes to a destination in its route cache.

A node can react to changes in network topology much more rapidly by taking advantage of cached routes.

For example, if one route to a destination is broken, the source node can choose another route to the destination from its route cache.

DSR Route Discovery

Consider the case when a source node S wants to send a packet to a destination node D.

In a ‘good situation’, S already knows a route to D from its route cache.

In this case, S will add the sequence of hops to D in the header of the packet. Then S will send the packet to the first node in this sequence.

In the ‘bad case’ S will not find any route to D in its route cache.

S will initiate the route discovery protocol. In this case, we call S the initiator and D the target of this protocol.

Node S is trying to discover a route to node D.

S broadcasts a route request message to its neighbours. This message is received by all nodes within the transmission range of S.

Each route request message contains the initiator and target of the route discovery.

Also, each route request is stamped with a unique ID assigned by the initiator.

15

An Example Route Discovery

DSR Route Discovery

Every node that receives a route request message, does one of the following :

A node like B first searches its route cache to see whether it has a stored route to D. If it has such a route, B sends that route to S.

If there is no such route in its route cache, B broadcasts the route request message to its neighbours. B attaches its own ID to the route request message

The Zone Routing Protocol (ZRP)

Brief Review of Reactive and Proactive protocols

A reactive routing protocol tries to find a route from S to D only on-demand, i.e., when the route is required, for example, DSR and AODV are such protocols.

The main advantage of a reactive protocol is the low overhead of control messages.

However, reactive protocols have higher latency in discovering routes.

Proactive Protocols

A proactive protocol maintains extensive routing tables for the entire network. As a result, a route is found as soon as it is requested.

The main advantage of a proactive protocol is its low latency in discovering new routes.

However, proactive protocols generate a high volume of control messages required for updating local routing tables.

A Combined Protocol

It is possible to exploit the good features of both reactive and proactive protcols and the Zone routing protocol does that.

The proactive part of the protocol is restricted to a small neighbourhood of a node and the reactive part is used for routing across the network.

This reduces latency in route discovery and reduces the number of control messages as well.

Routing Zones

16

AB

C

D

A

AB AB

C

ABCD

Each node S in the network has a routing zone. This is the proactive zone for S as S collects information about its routing zone in the manner of the DSDV protocol.

If the radius of the routing zone is k, each node in the zone can be reached within k hops from S.

The minimum distance of a peripheral node from S is k (the radius).

A Routing Zone

All nodes except L are in the routing zone of S with radius 2.

Nodes in a Routing Zone

The coverage of a node´s trasmitter is the set of nodes in direct communication with the node. These are also called neighbours.

In other words, the neighbours of a node are the nodes which are one hop away.

For S, if the radius of the routing zone is k, the zone includes all the nodes which are k-hops away.

Neighbour Discovery Protocol

Like other ad hoc routing protocols, each node executes ZRP to know its current neighbours.

Each node transmits a hello message at regular intervals to all nodes within its transmission range.

If a node P does not receive a hello message from a previously known neighbour Q, P removes Q from its list of neighbours.

Basic Strategy in ZRP

The routing in ZRP is divided into two parts

– Intrazone routing : First, the packet is sent within the routing zone of the source node to reach the peripheral nodes.

– Interzone routing : Then the packet is sent from the peripheral nodes towards the destination node.

Intrazone Routing

17

S

LKG

H

I

J

ABC D E

SD

Each node collects information about all the nodes in its routing zone proactively. This strategy is similar to a proactive protocol like DSDV.

Each node maintains a routing table for its routing zone, so that it can find a route to any node in the routing zone from this table.

In the original ZRP proposal, intrazone routing is done by maintaining a link state table at each node.

Each node periodically broadcasts a message similar to a hello message kwon as a zone notification message.

Suppose the zone radius is k for k>1

Zone Notification Message

A hello message dies after one hop, i.e., after reaching a node´s neighbours.

A zone notification mesage dies after k hops, i.e., after reaching the node´s neighbours at a distance of k hops.

Each node receiving this message decreases the hop count of the message by 1 and forwards the message to its neighbours.

Keeping Track of Nodes in a Routing Zone

The message is not forwarded any more when the hop count is 0.

Each node P keeps track of its neighbour Q from whom it received the message through an entry in its link state table.

P can keep track of all the nodes in its routing zone through its link state table.

ZRP: Example with Zone Radius = K = 2

18

S CA EF

BD

S performs routediscovery for D

Denotes route request

ZRP: Example with K = 2

ZRP: Example with K = 2

Interzone Routing

The interzone routing discovers routes to the destination reactively.

Consider a source (S) and a destination (D). If D is within the routing zone of S, the routing is completed in the intrazone routing phase.

Otherwise, S sends the packet to the peripheral nodes of its zone through bordercasting.

Bordercasting

The bordercasting to peripheral nodes can be done mainly in two ways :

– By maintaining a multicast tree for the peripheral nodes. S is the root of this tree.

– Otherwise, S maintains complete routing table for its zone and routes the packet to the peripheral nodes by consulting this routing table.

Interzone Route Discovery

S sends a route request (RREQ) message to the peripheral nodes of its zone through bordercasting.

Each peripheral node P executes the same algorithm.

– First, P checks whether the destination D is within its routing zone and if so, sends the packet to D.

– Otherwise, P sends the packet to the peripheral nodes of its routing zone through bordercasting.

19

S CAEF

BD

S performs routediscovery for D

Denotes route replyE knows route from E to D, so route request need not beforwarded to D from E

S CAEF

BD

S performs routediscovery for D

Denotes route taken by Data

– An Example of Interzone Routing

Route Reply in Interzone Routing

If a node P finds that the destination D is within its routing zone, P can initiate a route reply.

Each node appends its address to the RREQ message during the route request phase. This is similar to route request phase in DSR.

This accumulated address can be used to send the route reply (RREP) back to the source node S.

An alternative strategy is to keep forward and backward links at every node´s routing table similar to the AODV protocol. This helps in keeping the packet size constant.

A RREQ usually results in more than one RREP and ZRP keeps track of more than one path between S and D. An alternative path is chosen in case one path is broken.

Route Maintenance

When there is a broken link along an active path between S and D, a local path repair procedure is initiated.

A broken link is always within the routing zone of some node.

Hence, repairing a broken link requires establishing a new path between two nodes within a routing zone.

The repair is done by the starting node of the link (node A in the previous diagram) by sending a route repair message to node B within its routing zone.

This is like a RREQ message from A with B as the destination.

How to Prevent Flooding of the Network

Interzone routing may generate many copies of the same RREQ message if not directed correctly.

The RREQ should be steered towards the destination or towards previously unexplored regions of the network.

Otherwise, the same RREQ message may reach the same nodes many times, causing the flooding of the network.

Routing Zones Overlap Heavily 20

SD BH

A

C

PQA

BC

NX

Since each node has its own routing zone, the routing zones of neighbouring nodes overlap heavily.

Since each peripheral node of a zone forwards the RREQ message, the message can reach the same node multiple times without proper control.

Each node may forward the same RREQ multiple times.

Guiding the Search in InterZone Routing

Query Forwarding and Termination Strategy

When a node P receives a RREQ message, P records the message in its list of RREQ messages that it has received.

If P receives the same RREQ more than once, it does not forward the RREQ the second time onwards.

Also P can keep track of passing RREQ messages in several different ways.

Termination Strategies

In the promiscuous mode of operation according to IEEE 802.11 standards, a node can overhear passing traffic.

Also, a node may act as a routing node during bordercasting in the intrazone routing phase.

Whenever P receives a RREQ message through any of these means, it remembers which routing zone the message is meant for.

Suppose P has a list of nodes A, B,C,...,N such that the RREQ message has already arrived in the routing zones of the nodes A, B, C, ...,N.

Now P receives a request to forward a RREQ message from another node Q.

This may happen when P is a peripheral node for the routing zone of Q.

21

Early Termination of Unnecessary RREQs

Evaluation of ZRP

When the radius of the routing zone is 1, the behaviour of ZRP is like a pure reactive protocol, for example, like DSR.

When the radius of the routing zone is infinity (or the diameter of the network), ZRP behaves like a pure proactive protocol, for example, like DSDV.

The optimal zone radius depends on node mobility and route query rates.

Control Traffic

Control traffic generated by a protocol is the number of overhead packets generated due to route discovery requests.

In ZRP, control traffic is generated due to interzone and intrazone routing.

Hello messages transmitted for neighbour discovery are not considered as control traffic since mobility has no effect on it.

Control Traffic for Intrazone Routing

In the intrazone routing, each node needs to construct the bordercast tree for its zone.

With a zone radius of r, this requires complete exchange of information over a distance of 2r-1 hops.

For unbounded networks with a uniform distribution of nodes, this results in O( ) intrazone control traffic.

However, for a bounded network, the dependence is lower than .

There is no intrazone control traffic when r=1.

The intrazone control traffic grows fast in practice with increase in zone radius. So, it is important to keep the zone radius small.

22

P receives a RREQ from Q since P is a peripheral node for the routing zone of Q.

PQABC NX

P does not bordercast the RREQ to A,B,...,N but only to X which is not in its list.

When the zone radius is 1, the control traffic is maximum since ZRP degenerates into flood search.

In other words, every RREQ message potentially floods the entire network. This is due to the fact that all the neighbours of a node n are its peripheral nodes.

However, control traffic drops considerably even if the zone radius is just 2.

The control traffic can be reduced drastically with early query termination, when a RREQ message is prevented from going to the same region of the network multiple times.

However, the amount of control traffic depends both on node mobility and query rate.

The performance of ZRP is measured by compairing control traffic with call-to-mobility (CMR) ratio.

The call-to-mobility ratio (CMR) is the ratio of route query rate to node speed.

As CMR increases, the number of control messages is reduced by increasing the radius of the routing zones.

This is because, it is easier to maintain larger routing zones if mobility is low. Hence, route discovery traffic also reduces.

On the other hand, CMR is low if mobility is high.

In such a case, the routing zone maintenance becomes very costly and smaller routing zones are better for reducing control traffic.

An optimally configured ZRP for a CMR of 500 [query/km] produces 70% less traffic than flood searching.

Route Query Response Time

For a fixed CMR, the route query response time decreases initially with increased zone radius.

However, after a certain radius, the response time increases with zone radius.

This is due to the fact that the network takes longer time to settle even with small changes in large routing zones.

23