International Journal of Distributed and Parallel Systems (IJDPS) Vol.1, No.

2, November 2010

SCALABLE AND ROBUST LOCATION AWARE

MULTICAST ALGORITHM (SRLAMA) FOR MANET

Pariza Kamboj1and Ashok. K. Sharma2

1
CSE Department, ITM University, Gurgaon, Haryana- 122017, India, 09911920199,
[email protected].
2
CSE Department, YMCA Institute of Engineering, Faridabad, Haryana, India,
9811735202, [email protected]

ABSTRACT
An ad hoc network is composed of mobile nodes without the intervention of any fixed infrastructure or
central administration. Multicasting is intended for group-oriented communication. A lot many
applications depend on one-to-many or many-to-many dissemination of the information. However, in ad
hoc environment, multicasting protocols are faced with the challenge of producing multihop routes under
dynamic topology and bandwidth constraints. Due to the dynamic topology of MANETs it is very difficult
to build optimal multicast trees and maintaining group membership, making even more challenging to
implement scalable and robust multicast in Mobile Ad hoc Networks (MANET). A Scalable and Robust
Location Aware Multicast Algorithm, called SRLAMA, for mobile ad hoc networks is presented in the
paper that is based on creation of shared tree using the physical location of the nodes for the multicast
sessions. It constructs a shared bi-directional multicast tree with an alternate root that avoids the
network partitioning in case of primary root failurte, which results in better performance even than a
shared tree. The algorithm uses the concept of small overlapped zones around each node for employing
proactive routing with in the smaller zone. Protocol is based on the location information obtained
employing relevant data structure, which effectively reduces the overheads for route searching and
shared multicast tree maintenance. It employs a preventive route reconfiguration to avoid the latency in
case of link breakages and to prevent the network from splitting.

KEYWORDS
Ad-hoc networks, multicasting, shared tree, alternate node, routing zone, geographic location, global
positioning system GPS, preventive route updation.

1. INTRODUCTION
An ad-hoc network is a multihop wireless network formed by a collection of mobile nodes
forming a dynamic multi-hop autonomous network [3] without the intervention of any
centralized access point or fixed infrastructure. Multicast has great impact in mobile networks
because of their inherent broadcast capability. Using multicast instead of sending through
multiple unicasts not only minimizes link consumption, but also reduces sender and router
processing, communication costs and delivery delay [7].

Group communication is important in Mobile Ad Hoc Networks (MANET). Many ad hoc

network applications which require close association of the member nodes depends on group
communication. Disaster relief, conferences, action directions given to the soldiers in a
battlefield and communications required during a rescue operation are some examples of these
applications. In addition, many routing protocols for wireless MANETs need a
broadcast/multicast as a communication primitive to update their states and maintain the routes
between nodes [18].

Multicast protocols can be categorized in tree based and mesh based protocols. Multicast tree
structures are frail therefore need to be readjusted and repaired continuously as the connectivity
DOI : 10.5121/ijdps.2010.1202 10
 International Journal of Distributed and Parallel Systems (IJDPS) Vol.1, No.2, November 2010

changes. Even in wired networks maintaining group membership information and building
an optimal multicast distribution structure (typically in the form of a routing tree) is
challenging. A detailed survey of the work done in that area and a discussion of various design
tradeoffs can be found in [23]. One particularly challenging environment is a mobile ad-hoc
network (MANET). Nodes are free to move arbitrarily. Bandwidth scarcity, limited power
resource, and above all dynamicity of topology in a mobile ad hoc network make the multicast
protocol design predominantly challenging than that for wired network.

The proposed protocol, scalable and robust location aware multicast algorithm, called
SRLAMA, uses the concept of zone and constructs a shared bi-directional multicast tree for its
routing operations rather than a mesh, which helps in achieving more efficient multicast
delivery. Zone building, multicast tree construction and multicast packet forwarding depends on
the location information obtained using relevant data structure, which effectively reduces the
overheads for route searching and shared multicast tree maintenance. It employs a preventive
route reconfiguration to avoid the latency in case of link breakages and to prevent the network
from splitting.

The rest of the paper is organized as follows: Section 2 takes a look at the tree based multicast
protocols classification for MANET and also emphasizes the problems lie in the existing
multicast routing protocols. The proposed scalable and robust location aware multicast
algorithm is discussed in Section 3. Section 4 analyses the performance of SRLAMA in
comparison with other tree-based multicast protocols. Finally, section 5 summarizes the study of
the work in conclusions.

2. MULTICAST PROTOCOLS FOR MANETS

A number of multicast protocols have been proposed to provide multicasting in MANET like
challenging environments [11, 19]. A multicast packet is delivered to all the receivers belong to
a group along a network structure such as tree or mesh, which is constructed once a multicast
group is formed. Based on this network structure, multicast protocols can be broadly
categorized into two types, namely tree-based multicast and mesh-based multicast. A tree based
multicast routing protocol is either a source-tree or a shared-tree protocol. In a source tree based
multicast routing protocol data packets are delivered through multiple source-based routing
trees routed at the sources of the multicast session and in shared tree protocol data packets are
delivered along a shared multicast tree for the whole multicast group. Shared tree protocols
construct a single tree for a multicast group which is shared by all senders. If the nodes in the
network are highly dynamic, a large number of source trees might need reconstruction, causing
excessive overhead in case of source-tree multicast [20]. On the other hand, shared tree
multicast is more scalable because of lower control overhead requirement for maintaining only a
single shared tree for all multicast sources [1]. The shared tree approach has some other
drawbacks. The paths are non-optimal and traffic is concentrated on the shared tree, rather than
being evenly distributed across the network. The shared tree based protocols need a group
leader (or a core or a rendezvous point) to maintain group information and to create multicast
trees. To deal with the problem of dynamic nature of MANET, mesh based protocols provide a
number of redundant paths between a pair of sender and receiver. This in turn results in a great
number of control overhead.

Tree based protocols are generally more efficient in terms of data transmission, but they are not
robust against topology changes as there is no alternative path between a source and a
destination, while mesh based protocols are more robust against topology changes due to
availability of many redundant paths between mobile nodes, resulting in high packet delivery
ratio. On the other hand, multicast mesh does not perform well in terms of energy efficiency

11
 International Journal of Distributed and Parallel Systems (IJDPS) Vol.1, No.2, November 2010

because mesh-based protocols depend on broadcast flooding within the mesh and therefore,
involving many more forwarding nodes than multicast trees. In summary, the broadcast
forwarding in mesh based protocols produces redundant links, which improves the packet
delivery ratio but spends more energy than the tree-based multicast.

2.1. Comparison of Existing Multicast Protocols

Tree-based protocols use a spanning tree for data transmission connecting all multicast group
members and some non-members also. A tree-based multicast routing protocol constructs and
maintains either a shared multicast routing tree or multiple source-based multicast routing trees
(one for each sender) to deliver data packets from sources to receivers of a group. Ad Hoc
Multicast Routing Protocol Utilizing Increasing ID Numbers (AMRIS) [17] and Multicast Ad
Hoc On-Demand Distance Vector (MAODV) Protocol [13] are on-demand protocols, in which
a shared tree is constructed for the delivery of multicast packets to the entire multicast group.
AMRIS employs a proactive approach while MAODV is based on a reactive approach for
building the shared tree. AMRIS dynamically assigns an msm-ID (multicast session member –
ID) to each node in each multicast session. Based on the msm-ID number, a multicast delivery
tree — rooted at a special node with Smallest msm-ID (Sid) — is created, and the ID number
increases as the tree expands from the Sid. Generally, Sid is the source or the node that initiates
a multicast session. AMRIS maintains the relationship between nodes of the whole network,
therefore, its performance could suffer when traffic load or mobility rate increases. MAODV
routing protocol follows directly from unicast AODV, and discovers multicast routes on
demand using a broadcast route discovery mechanism employing the same route request
(RREQ) and route reply (RREP) messages that exist in the unicast AODV protocol. The
primary drawback of MAODV is high delay and overhead in fixing broken links as it uses
expanding ring search flooding for the task.
In contrast to shared-tree protocols, source-rooted tree-based multicast routing protocol
maintains one tree per sender. Multicast trees are rooted at source nodes, which are responsible
for data distribution, tree construction and tree maintenance. AMRoute [26] and ADMR [27] are
examples for source-rooted tree multicast routing protocol. AMRoute, a proactive source-rooted
tree-based multicast protocol, provides a robust approach using multicast trees and dynamic
logical cores. It creates a bidirectional multicast tree using unicast tunnels as tree links to
connect multicast group members. The data distribution tree comprises of only group senders
and receivers as tree nodes. Each group has at least one logical core that is responsible for
member and tree maintenance. The key characteristic of AMRoute is its usage of virtual mesh
links to establish the multicast tree. AMRoute exploits a mesh for connecting group members,
while a tree is used for data exchange. Therefore, as long as routes between tree members
exist via the mesh, the tree need not be readjusted when the network topology changes. The
major disadvantage of the protocol is that it suffers from temporary loops with several tunnels in
AMRoute. The ADMR is a source-based on-demand multicast protocol. ADMR creates a
source mesh between each multicast sender and the multicast receivers for the group. Compared
to other shared-trees based approaches, the use of source-based trees in ADMR creates much
more states at those routers which are participating in many groups.

CAMP [2] and On-Demand Multicast Routing Protocol (ODMRP) [21] are well-known
examples of mesh-based multicast routing protocols. They enhance the robustness by providing
redundant paths between the source and destination pairs. The mesh is created at the cost of
higher forwarding overhead. CAMP illustrates a proactive mesh based protocol. On the other
hand, in ODMRP, the mesh is created using the forwarding group concept and a reactive
approach is followed to keep the forwarding group current [20].

Due to shared tree structure in these protocols, the whole traffic is concentrated on the shared
tree links which likely to cause congestion at these links. Also there is a great chance of early
12
 International Journal of Distributed and Parallel Systems (IJDPS) Vol.1, No.2, November 2010

failure of the root node of the tree due to complete drain of its battery power as it offers more
responsibilities than other tree nodes. In case of shared-tree multicast tree, every source need to
be aware of the topology information and addresses of all of its receivers in the multicast group.
Therefore, these protocols suffer from high traffic overhead in high mobility networks. And
moreover, maintaining a number of trees is a tough task that requires too many overhead for the
maintenance. The main disadvantage with mesh based protocols is the excessive overhead
incurred in keeping the forwarding group current and in the global flooding of the
JOINREQUEST packets.

Every multicast routing protocol is having some or the other problem, hence suitable to specific
kind of environment. To overcome from these problems and to make an environment
independent protocol, a hybrid approach is needed that can control the power resource, reduce
the overhead and also enhance the scalability at the same time. Moreover, the location
advantage of the nodes can further improve the performance of the protocol manifolds. Based
on this view we have designed a new multicast routing protocol named scalable and robust
location aware multicast algorithm (SRLAMA) with reduced overhead.

3. PROPOSED PROTOCOL SRLAMA

This section introduces a new multicast protocol, Scalable and Robust Location Aware
Multicast Algorithm (SRLAMA), which follows the hybrid approach, a mix of proactive and
reactive routing using the physical location of the nodes. Like other tree based multicast
protocols it does not depend on a core node (root node) as the alternate root node provides
support in case of primary root node failure.

3.1. Geographic Location of Nodes

The routing performance can be significantly improved by utilizing location information of
nodes in forwarding the packets directionally towards the location of the tree members thus
limit the flooding of packets to a small region. A node can use Global Positioning System (GPS)
to obtain its geographic location information. The locations of other nodes can be obtained by
implementing some extra packets. However, in practice, it is difficult to find/maintain node
locations with accuracy in an ad hoc environment, where nodes move around. Some well-
known location-based routing algorithms are location-aided routing (LAR) protocol [16],
distance routing effect algorithm for mobility (DREAM) [15], and grid location system (GLS)
[12]. In SRLAMA, some extra packets are employed to provide location information to all
mobile ad hoc nodes.

3.2. Routing Zone around Nodes

In an ad-hoc network, it can be assumed that most of the traffic is directed to nearby nodes.
Therefore, the proactive scope is reduced to a small zone around each node in the SRLAMA
protocol. In this limited specified zone, all nodes maintain a proactive unicast route to every
other node. A routing zone is defined for each node separately, and the zones of neighboring
nodes overlap. A k-hop routing zone of node S can be defined as a connected topological
subgraph, on which node S is aware of the route to any other node [5]. The k-hop zone thus
includes the nodes, whose distance (not physical) from the node in question is at most k-hops,
therefore it can be of any shape. The nodes of a zone are divided into border nodes and interior
nodes. Border nodes are nodes which are exactly k hops away from the node in question. The
nodes which are less than k hops away are interior nodes. In fig. 2, the nodes G, D and M are
border nodes and rest all are interior nodes and the node N, 4 hops away from S, is outside the
routing zone. However node L is within the zone, since the shortest path up to L with length 3 is
less than the maximum routing zone hops.

13
 International Journal of Distributed and Parallel Systems (IJDPS) Vol.1, No.2, November 2010

As the zone radius is significantly smaller than the network radius, zone routing is also much
cheaper (in terms of control traffic and congestion) and faster than a global reactive route
discovery mechanism, as the number of nodes queried in the process is very small [20]. A
bigger proactive zone can be selected for comparatively stable topology where the updates of
topology are done on topology change only otherwise a smaller zone can be preferred.

3.3. Shared Multicast Tree with Alternate Root

In case of shared multicast tree the protocol depends on a core or root node to maintain the
group information which makes the root node easily overloaded. Due to this shared tree
multicast is particularly not suitable from energy balancing point of view because the root of the
tree takes on more responsibility for routing, consumes more battery energy, and stops working
earlier than other nodes. This leads to MANET partitioning as well as reduced network lifetime
[22], which in turn consumes a lot of bandwidth and generates more overhead for creating new
trees and searching the group leaders of all the partitions. To alleviate this problem, SRLAMA
uses a shared multicast tree with alternate root node instead of a single root node. Creation of a
alternate root node enhances the performance of the multicast tree and also lessens the load on
the primary root node. In case of primary root node failure the alternate root node takes over,
therefore, reduces the dependency on a single root node. This facilitates a great reduction in tree
maintenance overheads and tree re-construction. Selection of alternate root node is done from
the neighbor nodes of the primary root node on the basis of stability and battery status. A node
with slow movement and more power status is chosen to be the alternate root node. If the root
node does not found any neighbor node with the required criterion then the selection process is
delayed by some random time and after that the alternate root node search process starts again.
The selection process may lead to slight delay but improves overall efficiency of the protocol by
selecting a suitable node as alternate node. Selecting a suitable node as alternate root node not
only serves the purpose of standby root node but also defer the early possibility of searching the
alternate root node again in case of power failure or movement of the existing alternate root
node.

The proposed scheme is explained with the help of an example shown in Figure 1. In the given
tree R is the primary root node. The root node searches the nearest node by comparing the
nodes’ locations in its neighborhood with lowest speed and good power status and found a node
B suitable for the purpose of alternate root node. Figure 1 shows an example of a multicast tree.
A multicast packet is delivered from the root node R to all the six group members. Using the
zone routing every tree member unicasts the multicast packet only to the neighbor tree
members, thus saves a lot many transmissions otherwise required in case of broadcasts [24].

R B
G
I G

I
G
G

I G

Tree Link G

R Primary Root node

B Alternate root node
G Group members
I Intermediate nodes
Figure 1. Shared Multicast Tree with Alternate Root

14
 International Journal of Distributed and Parallel Systems (IJDPS) Vol.1, No.2, November 2010

B
Z
R
Өd A Q

Өg P
D C S Өm
E G
H F
I
K M
N
J
L

Figure 2. 3 hop Routing zone at node S

3.4. Data Structure and Neighborhood Updation

SRLAMA has inbuilt distributed location service, i.e., each node in the network maintains a part
of the overall location database. In order to facilitate the location service, each node has some
data structures in addition to those needed for the routing algorithm, which are as follows:

First, a localized “zone neighbor table” is maintained by each node, which contains routing
entries for each neighbor within the k-hop routing zone as shown in table 1. Each routing entry
contains the IP of neighbor nodes, their location, next immediate hop, hop count to this
particular node and a timestamp indicating when the entry was added or updated. In case of
enough space available in a node, it may store the entries of other nodes about which it learnt by
passively listening on the network in addition to its zone neighbors.

Besides Zone Neighbor Table (ZNT), for the purpose of routing information each node
maintains Multicast Tree Table (MTT) as shown in table 2 and Request Table (RT) as shown in
table 3. Each entry of Multicast Tree Table contains the multicast group IP address, multicast
group leader IP address, hop count to multicast group leader, next hops and timestamp. This
table has entries for all those multicast groups of which group the node is a member. The Next
Hops field is a linked list of structures, each of which contains the following fields:

- Next Hop IP Address

- Link Direction
- Activated Flag
The direction of the link is relative to the location of the group leader. UPSTREAM is a next
hop towards the group leader, and DOWNSTREAM is a next hop away from the group leader
[5]. An entry is added to the table when the node becomes a multicast group member. A request
table is maintained by all those nodes that support multicast. An entry in this table contains
multicast group IP address, requesting node (actually a tree member node) IP address,
requesting node location and a timestamp. On reception of MGREQ with join flag set
(MGREQ-J) from a request node an entry is made in this table [10].

In order to exchange location information on the network, SRLAMA uses four special packet
types which are exchanged in the same way as data packets.
15
 International Journal of Distributed and Parallel Systems (IJDPS) Vol.1, No.2, November 2010

A node broadcasts LOCN packet (as shown in fig. 3) and its zone neighbor table to all nodes in
its zone when it wants to inform other node(s) of its location. LOCN packet contains the IP,
location (latitude and longitude) of the source node and a timestamp.

Source Node Timestamp

TS
IP Latitude Longitude
SRC_I SRC_LO SRC_LNG
P C T

Figure 3. Format of LOCN packet

When a node receives a LOCN packet from another node it unicasts back a location
acknowledgement packet LACK as shown in fig. 4. This packet contains the IP and location of
the source node, the IP and location of the node acknowledging receipt of a LOCN and a
timestamp. This node compares the entries of its ZNT with the ZNT of request node and adds
the new entries into its ZNT which were not present earlier. This acknowledging node sends
entries of its ZNT which were not present in the request nodes’ ZNT along with LACK. Now
the request node also appends the new entries received along with LACK from all nodes into its
own ZNT. Entry of any neighbor node is removed from the ZNT only when the node moves out
of its radio range otherwise keeps the entry low in the ZNT.

Obtaining the locations of the mobile nodes, distance d between two mobile nodes can be
calculated using (1) and slope θ using (2) and projection P using (3).

d = ( x 2 − x1) 2 + ( y 2 − y1) 2 (1)

( y 2 − y1)
θ = tan −1
( x 2 − x1) (2)
P= d × Sinθ (3)
where (x1,y1) and (x2,y2) are the locations of two mobile nodes.

When a node wants to search for an existing multicast group it broadcasts a multicast group
request packet MGREQ, shown in fig. 5, within its zone. This packet contains the IP and
location of the request node, IP of the multicast group and a timestamp. A location reply packet
MGRPL as shown in fig. 6 is sent in response to a MGREQ packet by a tree member. The
MGRPL packet contains the IP and location of the multicast group tree member, the IP and
location of the request node, and a timestamp.

Table 1. Zone Neighbor Table maintained by each node

Neighbor Node Location Immediate Hop Count Timestamp

IP Latitude Longitude Next Hop HOP_CNT TS
LAT LNGT NXT_HOP
222.24.15.06 420 10’ E 560 40’ S 222.24.15.15 3 15:09 PM
222.24.15.11 550 10’ W 340 33’ S 222.24.15.31 2 15:15 PM
222.24.15.20 230 26’ E 150 14’ N 222.24.15.19 3 15:24 PM
222.24.15.29 450 30’ N 430 20’ E 222.24.15.43 1 15:42 PM

16
 International Journal of Distributed and Parallel Systems (IJDPS) Vol.1, No.2, November 2010

Ack. Node Source Node Time-

IP Latitude Longitude IP Latitude Longitude stamp
ACK_IP ACK_LAT ACK_LNGT SRC_IP SRC_LAT SRC_LNGT TS

Figure 4. Format of LACK packet

Request Node Multicast Join Time-

Group IP Flag Stamp
IP Latit Longit MG_IP JF TS
RQ_ ude ude
IP RQ_ RQ_L
LAT NGT

Figure 5. Format of MGREQ packet

Multicast Group Tree Member Request node Time

IP Latitude Longitude RQ_ Latitude Longitude stamp
TM_IP TM_LAT TM_LNGT IP RQ_LAT RQ_LNGT TS

Figure 6. Format of MGRPL packet

Table 2. Scorecard maintained by Table 3. Multicast Tree Table

each node
IP IP Hop Immediate Time-
IP Score Multicast group Multicast Count Next hop stamp
( location node) (pheromone) MG_IP Group Leader HOP_C NXT_HOP TS
222.24.15.06 35 MGL_IP NT

222.24.15.11 30 224.30.15.10 222.24.15.50 8 222.24.15.05 15:39 PM

222.24.15.20 27 224.30.10.10 222.24.15.65 9 222.24.15.11 15:45 PM

222.24.15.29 12 224.30.10.15 222.24.15.36 7 222.24.15.10 15:04 PM

224.30.10.50 222.24.15.45 10 222.24.15.20 15:12 PM

Table 4. Request Table

IP IP Multicast Location of Multicast Time-

Multicast group group Tree group Tree Member stamp
MG_IP Member Latitude longitude TS
TM_IP TM_LAT TM_LNGT
224.30.15.10 222.24.15.06 420 10’ E 560 40’ S 13:41 PM
224.30.10.10 222.24.15.11 550 10’ W 340 33’ S 14:38 PM
224.30.10.15 222.24.15.20 230 26’ E 150 14’ N 13:24 PM
224.30.10.50 222.24.15.29 450 30’ N 430 20’ E 14:12 PM

Nodes learn of their neighbors through transmission of LOCN, LACK, MGREQ and MGRPL
packets used by SLS. In SRLAMA, instead of beaconing, a node broadcasts LOCN packet with
TTL value equal to k hops whenever it enters into a network or whenever it moves significantly
from the previous location, to inform other node(s) of its location and these neighbors unicasts
the LACK packet to the sending node to get update their locations. When a node sends an

17
 International Journal of Distributed and Parallel Systems (IJDPS) Vol.1, No.2, November 2010

LACK packet to some node, all of its neighbors hear the transmission and maintains this node
as their neighbor in the ZNT with the appropriate value of hop count. A node also learns of its
neighbours by promiscuous snooping on the channel for detecting activities of neighbors.

3.5. Multicast Group Management

SRLAMA maintains a bi-directional shared multicast tree for each multicast group, consisting
of the members of the multicast group and several routers. Each multicast group has a unique
multicast group IP (address) [8] and a group leader. The group member that first constructs the
tree is designated as the group leader or the primary root of the tree [10].

3.5.1. Joining the multicast group - A request node, that wants to join the multicast group, will
first look for the existing tree of the multicast group. The node broadcasts a MGREQ message
with join flag set to the nodes within its zone in search of multicast group IP. All nodes of the
zone search the multicast group IP in their multicast tree table first and then in request table and
a node having a matched entry replies MGRPL back unicastly. The MGRPL is sent using the
reverse route maintained during the traversing of MGREQ packet. After receiving the MGRPL
following the forward route the request node sends the GRAFT message to confirm the join
process to the node from which it received the MGRPL message. The GRAFT message will
activate the tree link between the request node and the node which sent the MGRPL message
and the request node becomes the tree member. Request node also updates its request table and
multicast tree table. In case of no entry matches in the multicast tree table or request table of all
the neighbor nodes, the request node searches the tree existence outside the zone.

3.5.2. Creating a new multicast group - Once the whole network is traced in search of
multicast group and still no MGRPL is received by the request node, it assumes that the
requested multicast group does not exist. It then declares itself the leader of the multicast group
and becomes the primary root of the tree and broadcasts this information to all nodes within its
zone.

3.6. Multicast Tree Maintenance

The robustness of the multicast tree is adversely affected with the time as individual links are
repaired only when broken. Over a period of time due to high mobility among the nodes the
overall structure of the tree would be far from optimal, hence making the tree susceptible to
even more link breakages. In SRLAMA, the tree is updated regularly and also the preventive
maintenance is done which kept the tree robust.

3.6.1. Tree Updation - In order to maintain the tree structure even when nodes move, group
members periodically send tree_update requests to the alternate root node to lessen the load on
the primary root node. The multicast tree can be updated using the path information included in
the tree_update request messages. If any change is found in the path the back up root node sends
an update message to the primary root node to notify about the change so that the changes in the
topology also reflect in the tree structure. Tree_update need to be initiated by leaf nodes only as
each uplink next hop puts its own uplink on the tree update message, therefore contains all
uplinks as it travels towards alternate root node. The period must be carefully chosen to balance
the overhead associated with tree update and the delay caused by the tree not being timely
updated when nodes move [4], [8], [9].

3.6.2. Preventive Multicast tree Maintenance - A preventive approach is being proposed for
tree reconstruction prior to link breakages using the following methods:

18
 International Journal of Distributed and Parallel Systems (IJDPS) Vol.1, No.2, November 2010

a. Leaving the tree- In the proposed protocol a non-leaf node wishing to move out of the
multicast tree, will broadcast an alarm message to all of its neighbors with TTL value 1 before
sending the Leave message. It then compares the location of nodes in its ZNT and passes all of
its routing information to a nearest node which is not a tree member. Thus new links are grafted
on the tree from the upstream node and downstream nodes of the leaving node to the newly
found neighbor node. The downstream node sends tree_update to the alternate root node. All the
future transmissions follow the path with newly discovered link. In case of leaf node or a
normal network node, the node simply sends the leave message to its one hop neighbor nodes.
All the neighbor nodes receiving the alarm packet from any node also remove the related entry
from their ZNT and also from request table, if the entry with IP of leaving node exists there. In
case of primary root mobility, the primary root sends the alarm message to back up root
notifying it to take the control of the tree and passes its all routing information to the back up
root. Upon receiving the alarm message, the back up root updates its downstream next hops to
the downstream next hops of the primary root node. It also selects a new back up root for its
replacement after it resumes as primary root node.

b. Power Resource Depletion - Another proactive measure can be taken in case of the complete
depletion of the power sources of a node of the multicast tree. Route is reconfigured quickly in
case of a node goes off because of complete drainage of its energy sources. The power sources
of the nodes in the multicast tree are examined periodically (frequency of examination is
doubled in case of primary root node) and if the power source of a node goes below a threshold
value, a new link is discovered prior to its failure, and the links to this node are deleted from the
multicast tree. New link is searched in the same way as in case of leaving the tree process [6].

The latency in finding new route in case of nodes failure is reduced by reconfiguring the routes
using preventive approach before the failure of the node.

3.6.3. Multicast Tree Repair - When a link breakage is detected, the downstream node of the
break (node farther away from the group leader) initiates to repair the link by broadcasting a
MGREQ-J within the zone. Only a tree node with lesser hop count to the leader (that is nearer to
the group leader) may respond to this MGREQ. If the node receives a reply it then grafts a new
branch using GRAFT message up to the node which sent the MGRPL.

3.7. Data Transmission Process

SRLAMA algorithm searches the multicast group tree member in the zone of the intermediate
node. It searches the possibility of tree member by searching the multicast group IP in the
multicast tree table and request table of each neighbor node in the zone. In case of no match
found with in the zone it repeats the search outside the zone as shown in fig. 7. In this way the
routing is initially established with proactively prospected routes within the zone and then
outside the zone, serves the demand from selectively activated nodes through reactive approach
using the physical location of the nodes. Therefore, route requests can be more efficiently
performed without exploiting the flooding in the network.

Proactive Routing inside zone- Proactive topological routing operates within the k-hop routing
zone to search a tree member within the zone. When a node wants to route a data packet or join
a multicast group, it first checks the multicast tree member in the zone by broadcasting a
MGREQ packet with multicast group IP within its k-hop routing zone (TTL=k). All nodes of
the zone search the multicast group IP in their multicast tree table. If an entry of the multicast
tree table of a particular node matches, then this node unicasts MGRPL to the request node
putting its own IP, latitude and longitude in the multicast tree member IP, latitude and longitude
fields of the MGRPL. After receiving the MGRPL the request node broadcasts a stop search

19
 International Journal of Distributed and Parallel Systems (IJDPS) Vol.1, No.2, November 2010

signal to all nodes in its zone. The request node then send the data packet to this replying node
(tree member) along the forward route created during MGRPL transmission, as the MTT
contains entries for those multicast group of which the node is a member.

Reactive Routing outside zone - In case of no entry found in the multicast tree table of the zonal
nodes, these nodes search the multicast IP in their request table. If any entry of the request table
matches, then the node unicasts MGRPL to the request node by putting the IP, latitude and
longitude of the multicast tree member from the matched entry in the multicast tree member IP,
latitude and longitude fields of the MGRPL. The matched entry in the request table actually
provides the tree member node IP and its location outside the zone.

In case of no entry matches in the multicast tree table and the request table of the nodes in the
zone and the network diameter is still not reached, then the request node sends a small signal to
its border nodes (in case of no border nodes, nodes with k-1 hop) to forward the cached copy of
the MGREQ to all their border nodes for further searching of the multicast group in the whole
network. These border nodes then broadcast the MGREQ packet to all the nodes in their zone.
These zonal nodes of the border nodes further search the multicast group IP in their multicast
tree table and request table and a node having a matched entry in either table replies MGRPL
back unicastly to the request node.

Controlled directional forwarding - If the tree member node is found through multicast tree
table of any node outside the zone then the request node sent the packet along the forward route
to this tree member. If the tree member node is found through request table of any node within
or outside the zone then a route up to the tree member is find out by controlled directional
forwarding using its geographic location. For that the request node selects the border node of its
k-hop zone nearest to the tree member for data forwarding. As shown in fig. 2, node S selects
the border nodes G as its projection on the direction line towards tree member is largest [25].
After selecting the node, the packet is forwarded to the next hop towards the border node. In
case of sparse network, if there is no border node in the zone then the route search packet is
forwarded to only the farthest neighbor node in the zone which is having largest projection with
the direction of the tree member among others.

Thereafter these border or farthest nodes will forward the route search packet to the border
nodes of their respective k-hop zones in the direction of tree member only. This process goes on
until the packet reaches to the tree member specified in the MGRPL packet. After accepting the
first copy of the packet rest copies are discarded by the tree member. This tree member now
replies back the MGRPL to the request node. The request node transmits the data packet to the
tree member along the forward route.

Since the traffic would be forwarded only through limited nodes to tree members for route
discovery using controlled directional forwarding it actually reduces the scope of data packet
forwarding whereas the existing protocols broadcast the data packet to entire ad hoc network.
Thus SRLAMA does not involve the entire network into data forwarding activity leading to
considerable reduction in the packets processing. This feature significantly saves the battery
power and channel bandwidth and also reduces the traffic effectively.

20
 International Journal of Distributed and Parallel Systems (IJDPS) Vol.1, No.2, November 2010

Figure 7. Data Transmission Process

4. PERFORMANCE ANALYSIS
SRLAMA provides a number of benefits because of its hybrid nature, geographic location
inclusion of nodes, controlled directional forwarding of packets towards tree member.
21
 International Journal of Distributed and Parallel Systems (IJDPS) Vol.1, No.2, November 2010
Good Scalability: Scalability is also achieved due to the shared tree multicast routing protocol
as single tree maintenance of all group members is easier than the maintenance of number of
trees in case of source based multicast routing protocol. Scalability is also a by-product due to
geographic routing as new nodes periodically announce their geographic location and therefore
can easily become the part of the existing network. Improvement in scalability is achieved by
minimizing the routing overheads which in turn minimizes wireless bandwidth consumption.

Reduced Network Structure Construction & Maintenance overhead: Multicast tree construction
and maintenance is less than even shared tree multicast due to only one shared tree per group
and alternate root node and preventive maintenance.

Also the protocol rely on controlled directional forwarding for location update and query rather
than exploiting flooding which ensures the reduction in overheads.

Independent of single point failure: Another novelty of this hybrid routing protocols is that it
avoids single-point of failure with incorporation of alternate root node. Energy and bandwidth
efficient: The protocol uses proactive topological routing within small k-hop routing zone and
directional forwarding of the data packets outside the zone towards the target. These results in
considerable reduction in packet processing therefore minimize the usage of energy and
bandwidth.

Packet Delivery Ratio: SRLAMA shows moderate delivery ratio due to preventive maintenance
and local link repair in comparison of per-source tree multicast and shared tree multicast.

Load Distribution: SRLAMA has better load distribution than shared tree multicast due to
alternate root node while

Latency due to link error: It represents moderate latency in route finding in comparison to
source based tree multicast and shared tree multicast due to preventive maintenance and local
link repair.

5. CONCLUSION

The Scalable and Robust Location Aware Multicast Algorithm shows better performance than
Mesh Based Multicast, Per-Source Tree Multicast and Shared Tree Multicast protocols which
are popular tree based multicast routing for ad hoc networks. It has been analyzed on various
parameters like Scalability, Network Structure Construction & Maintenance overhead, Point of
Failure, Packet Delivery Ratio, Energy Consumption, Bandwidth Consumption, Latency due to
link error, and Load Distribution.

SRLAMA eliminates the drawbacks of per-source tree and even that of shared tree protocols. It
reduces the latency problem due to controlled directional forwarding and also the network
partition problem when a link error occurs due to the failure of primary root. It is independent of
any location service and also avoids any coupling with an underlying unicast routing protocol
without incurring any extra overhead due to the inclusion of relevant data structure for obtaining
the geographic location of the nodes and for multicast related information sharing. The protocol
reduces the total energy consumption as well as improves the performance than a conventional
shared tree based protocol.

SRLAMA exhibits reduction in tree reconstruction and tree maintenance overhead due to the
use of alternate root and preventive maintenance. The protocol results in improved packet
delivery ratio and energy balance and efficient usage of bandwidth compared to the
22
 International Journal of Distributed and Parallel Systems (IJDPS) Vol.1, No.2, November 2010
conventional shared tree multicast (STM) due to preventive maintenance, local link repair and
also because it can switch to the alternate root when the primary root is overloaded or becomes
invalid.

Scalability is also achieved due to the shared tree multicast routing protocol as single tree
maintenance of all group members is easier than the maintenance of number of trees in case of
source based multicast routing protocol. The protocol also exhibits a good scalability because of
incorporation of geographical locations into routing decisions.

ACKNOWLEDGEMENTS
I am grateful to my colleague Ms. Smita Rajpal, Asstt. Prof., Department of Computer Science
and Engineering, ITM University, Gurgaon, India for the guidance and motivation. I am also
thankful to my family for kind support and affection.

REFERENCES
[1] M. Gerla, C.-C. Chiang, and L. Zhang, “Tree Multicast Strategies in Mobile, Multihop Wireless
Networks,” Baltzer/ACM Journal of Mobile Networks and Applications (MONET), Vol. 3, No. 3,
pp. 193-207, 1999.
[2] J.J Garcia-Luna-Aceves and E.L. Madruga, “The Core-Assisted Mesh Protocol,” IEEE Journal on
Selected Areas in Communication, vol. 17, no. 8, August 1999.
[3] A.K. Sharma and Amit Goel, “Moment to Moment Node Transition Awareness Protocol
(MOMENTAP)”, International Journal of Computer Applications (IJCA) Special Issue, IASTED,
Vol. 27/1, Jan 2005, pp. 1-9.
[4] Elizabeth M. Royer and Charles E. Perkins, “Multicast Operation of the Ad-hoc On-Demand
Distance Vector Routing Protocol”, in Proceedings of the 5th Annual ACM/IEEE International
Conference on Mobile Computing and Networking (Mobicom’99), Seattle, WA, USA, August 1999,
pages 207-218.
[5] Hui Cheng and Jiannong Cao, “A Design Framework and Taxonomy For Hybrid Routing Protocols
in Mobile Ad Hoc Networks”, IEEE Communications, Surveys 3rd Quarter 2008, Volume 10, No. 3.
[6] Kamboj, Pariza & Sharma, A. K., “Location Aware Reduced Diffusion Hybrid Routing Algorithm
(LARDHR)”, IEEE Computer Society (2009), S. 1156-1161, 2009.
[7] Stephen Mueller , Rose P. Tsang and Dipak Ghosal, “ Multipath Routing in Mobile Ad Hoc
Networks: Issues and Challenges”.
[8] Yufang Zhu and Thomas Kunz, “MAODV Implementation for NS – 2.26” Communications and
Networking in China, 2006. ChinaCom apos;06. First International Conference on Volume, Issue 25-
27, pp:1 - 5
[9] M. Liu, R. R. Talpade, A. McAuley, and E. Bommaiah, “AMRoute: Adhoc Multicast Routing
Protocol,” Technical Report, vol. TR 99-8, The Institute for Systems Research, Univesity of
Maryland, 1999.
[10] Pariza Kamboj, A.K.Sharma, “MAODV-PR: A Modified Mobile Ad Hoc distance Vector Routing
Protocol with Proactive Route Maintenance”, VOYAGER - The Journal of Computer Science &
Information Technology, Vol. 6, No. 1, Jan-June 2008, pp. 35-41.
[11] S.-J. Lee et al., “A Performance Comparison Study of Ad hoc Wireless Multicast Protocols”, Porc.
INFOCOM 2000, Mar. 2000, pp 564-574.
[12] N. K. Guba and T. Camp, Recent work on GLS: a location service for an ad hoc network,
Proceedings of the Grace Hopper Celebration (GHC), 2002.
[13] E. M. Royer and C. E. Perkins, “Multicast Operation of the Ad Hoc On-
Demand Distance Vector Routing Protocol,” ACM MOBICOM, Aug. 1999, pp. 207–218.
[14] Sangman Moh, Chansu Yu, Ben Lee, and Hee Yong Youn, “Energy Efficient and Robust Multicast
Protocol for Mobile Ad Hoc Networks”, Proceedings of the 2002 Pacific Rim international
Symposium on Dependable Computing (December 16 - 18, 2002). Proceedings of IEEE Computer
Society, Washington, DC, 145.
[15] S. Basagni, I. Chlamtac, V. R. Syrotiuk, and B. A. Woodward, “A distance routing effect algorithm
for mobility (DREAM),” presented at the ACM/IEEE MobiCom’98, Oct. 1998.

23
 International Journal of Distributed and Parallel Systems (IJDPS) Vol.1, No.2, November 2010
[16] Y. B. Ko and N. H. Vaida, “Location-aided routing (LAR) in mobile ad hoc networks”, presented at
the ACM/IEEE MobiCom’98, Oct. 1998.
[17] C. W. Wu, Y.C. Tay, and C.-K. Toh, “Ad Hoc Multicast Routing Protocol Utilizing Increasing id-
numberS (AMRIS) Functional Specification,” Internet draft, Nov. 1998.
[18] Song Guo, Member, IEEE, and Oliver Yang, Senior Member, IEEE, “Maximizing Multicast
Communication Lifetime in Wireless Mobile Ad Hoc Networks”, IEEE Transactions on Vehicular
Technology, vol. 57, no. 4, July 2008
[19] Carlos de Morais et al, “Multicast over wireless mobile ad hoc networks: present and future
directions”, IEEE Network, Jan/Feb, pp 52-59.
[20] Aniruddha Rangnekar, Ying Zhang,Ali A. Selcuk, Ali Bicak, Vijay Devarapalli, Deepinder Sidhu,
“A Zone-Based Shared-Tree Multicast Protocol for Mobile Ad Hoc Networks”, In Vehicular
Technology Conference, 2003, 2003.
[21] S.-J. Lee, M. Gerla, and C.-C. Chiang, “On-Demand Multicast Routing Protocol,” in Proceedings of
IEEE WCNC’99, September 1999.
[22] J. E. Wieselthier, G. D. Nguyen, and A. Ephremides, “Algorithms for Energy-Efficient Multicasting
in Ad Hoc Wireless Networks,” Proc. of Military Communication Conference (MILCOM 1999),
Vol. 2, pp. 1414-1418, Nov. 1999.
[23] V. Li and Z. Zhang, Internet Multicast Routing and Transport Control Protocols, in Proc. of the
IEEE, pp. 360-391, Vol. 90, No. 3, March 2002.
[24] Kamboj, Pariza & Sharma, A. K., “Scalable Energy Efficient Location Aware Multicast Protocol for
MANET (SEELAMP)”, Journal of Computing, USA, ISSN 2151-9617, Vol. 2, Issue 5, May 2010,
pp. 20-30.
[25] Pariza Kamboj, A.K.Sharma, “Location Aided Flat Hybrid Routing Protocol (LAFHRP)”
International Journal of Computational Cognition (IJCC) (submitted for publication) ISSN 1542-
5908, USA.
[26] Bommaiah, E.; Liu, M.; McAuley, A.; and Talpade, R.; "AMRoute: Ad-hoc Multicast Routing
Protocol", Internet Draft, draft-talpade-manetamroute-00.txt, August 1998, work in progress.
[27] Jorjeta G. Jetcheva and David B. Johnson, “Adaptive Demand-Driven Multicast Routing in Multi-
Hop Wireless Ad-Hoc Networks”, Proceedings of the second symposium on Mobile Ad Hoc
Networking and Computing (MobiHoc 2001), 2001.

Authors
Pariza Kamboj
Ms. Pariza Kamboj received her M.Tech (Comp. Sc. & Engg.) with Hons. from Kururkshetra
University (KU), Kurukshetra, Haryana (India) in the year 2006. From July 1996 to Mar 2007, she
served at JMIT, Radaur, Yamuna Nagar, Haryana (India). From Apr 2007 to Nov 2007, she
served as Assistant Professor at CITM, Faridabad, Haryana (India). Since Dec 2007, she is
working as Assistant Professor at ITM University, Gurgaon (India) in the department of Computer
Science. Currently she is pursuing her Ph.D. in the area of Mobile Ad Hoc Networks. Her
research interest areas are Mobile Ad-hoc networks, Computer Networks, Mobile Computing,
Pervasive Computing.

Ashok Sharma
Prof. A.K.Sharma received his M.Tech (Comp. Sc. & Tech) with Hons. from University of
Roorkee (India) in the year 1989 and Ph.D. (Fuzzy Expert System) from JMI, New Delhi (India)
in the year of 2000. From July 1992 to April 2002, he served as Assistant Professor and
became Professor in Computer Engg at YMCA Institute of Engineering, Faridabad (India) in
April 2002. He received his 2nd Ph.D. in Information Technology from Indian Institute of
Information Technology & Management, Gwalior (India) in the year 2004. His research interest
includes Fuzzy System, Knowledge Representation, and Computer Networks & Internet
Technology.

24