{'fraction_non_alphanumeric': 0.01878324962106577, 'fraction_numerical': 0.0026748298511011384, 'mean_word_length': 4.694364528685057, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 2, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
Scalable Energy Efficient Location Aware Multicast Protocol for MANET (SEELAMP)

Multicast plays an important role in implementing the group communications in bandwidth scarce multihop mobile ad hoc networks. However, 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 energy efficient location aware multicast algorithm, called SEELAMP, 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 for its routing operations rather than a mesh, which helps in achieving more efficient multicast delivery. The algorithm uses the concept of small overlapped zones around each node for proactive topology maintenance with in the zone. Protocol depends on the location information obtained using a distributed location service, which effectively reduces the overheads for route searching and shared multicast tree maintenance. In this paper a new technique of local connectivity management is being proposed that attempts to improve the performance and reliability. It employs a preventive route reconfiguration to avoid the latency in case of link breakages and to prevent the network from splitting.


INTRODUCTION
N Ad hoc network consists of a collection of mobile hosts 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.
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 changes. Even in wired networks building optimal multicast trees and maintaining group membership information is challenging. 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, a scalable and robust location aware multicast algorithm, called SEELAMP 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 a distributed location service, which effectively reduces the overheads for route searching and shared multicast tree maintenance [17]. In this paper a new technique of local connectivity management is being proposed that attempts to improve the performance and reliability. 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 Energy Efficient Location Aware Multicast Protocol is discussed in Section 3. Section 4 analyses the performance of SEELAMP in comparison with other tree-based multicast protocols. Finally, section 5 summarizes the study of the work in conclusions.

MULTICAST PROTOCOLS FOR MANETS
Several multicast protocols have been proposed for mobile ad hoc networks. Based on the network structure along which multicast packets are delivered to multiple receivers, multicast protocols can be broadly categorized into two types, namely tree-based multicast and meshbased 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. 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 has lower control overhead because it needs to maintain only a single shared tree for all multicast sources and therefore is more scalable [1].
The tree structure is known for its efficiency in utilizing the network resource optimally, while tree based protocols are generally more efficient in terms of data transmission. Mesh based protocols are more robust against topology changes due to availability of many redundant paths between mobile nodes and result in high packet delivery ratio. On the other hand, multicast mesh does not perform well in terms of energy efficiency 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. 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. They are not robust to mobility as there is no back up path between a source and a destination, besides that, all shared tree based protocols need a group leader (or a core or a rendezvous point) to maintain group information and to create multicast trees. 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. However, due to node mobility the network structure is fragile and thus, the multicast packet may not be delivered to some members. To compensate this problem and to improve the packet delivery ratio, multicast protocols for MANETs usually employ control packets to periodically refresh the network structure [14].

Comparison of Multicast Protocols
Ad hoc Multicast Routing (AMRoute) [9] and Lightweight Adaptive Multicast (LAM) [19] are tree based protocols, in which a shared tree is constructed for the delivery of multicast packets to the entire multicast group. In AMRoute protocol a bi-directional shared multicast tree is created involving only the group members. The tree links are created as unicast tunnels between the tree members. The problem with AMRoute is that it depends heavily on an underlying unicast protocol for creating these unicast tunnels. The LAM protocol depends on Temporally-Ordered Routing Algorithm (TORA) for route finding ability and cannot operate independently. An advantage of LAM is that, it reduces the amount of control overhead generated for route finding, due to its tight coupling with TORA. However, due to shared tree structure these protocols have the disadvantage of their dependency on a core node, thus have a central point of failure. CAMP [2] and On-Demand Multicast Routing Protocol (ODMRP) [21] are wellknown 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]. 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 Energy Efficient Location Aware Multicast Protocol (SEELAMP) with reduced overhead.

PROPOSED PROTOCOL SEELAMP
This section introduces a new multicast protocol, Scalable Energy Efficient Location Aware Multicast Protocol (SEELAMP), which follows the hybrid approach, a mix of proactive and reactive routing using the physical location of the nodes. Like some other multicast protocols neither it depends on any underlying unicast protocol nor on a core node (root node) as the backup root node provides support in case of primary root node failure. The protocol reduces the total energy consumption as well as improves the performance than a conventional shared tree based protocol.

Backup Root Shared Tree based Multicast
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 HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/ WWW.JOURNALOFCOMPUTING.ORG nodes. This leads to MANET partitioning as well as reduced network lifetime [22].
In case of shared tree multicast protocol if the primary root node goes off then the whole multicast tree is disconnected into a number of partitions which consumes a lot of wireless bandwidth for searching the group leaders of all the partitions. To alleviate this problem, SEELAMP uses a shared multicast tree with backup root node instead of a single root node. Creation of a backup 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 backup 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 backup 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 backup root node. Selecting a suitable node as backup root node not only serves the purpose of standby root node but also defer the early possibility of searching the backup root node again in case of power failure or movement of the existing backup 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 backup 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 backup 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 backup node. Figure 1 shows an example of a multicast tree. The tree consists of a root node (R), Backup root node (B), three intermediate nodes (I), six member nodes of a multicast group, and nine tree links. 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.

Location Information of nodes
The routing performance can be significantly improved by utilizing location information of nodes in communication e.g., if a sender node knows the location of the tree member, it can find out the route to the tree member using diffused routing by forwarding the packet in the relative direction in hopes of getting it there quickly therefore communication delay can be minimized with location information. A node can use Global Positioning System (GPS) to obtain its geographic location information. The locations of other nodes can be obtained by implementing a distributed location service [6]. 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 locationbased routing algorithms are location-aided routing (LAR) protocol [29], distance routing effect algorithm for mobility (DREAM) [15], and grid location system (GLS) [12]. In SEELAMP a location service algorithm using swarm intelligence techniques, called SLS (Swarm location service) [11] developed by Bluetronix is used to provide location information to all mobile ad hoc nodes and the geographical information obtained is used to limit the flooding of packets to a small region.

Zone Routing
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.
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 SEELAMP protocol. In a limited zone, all nodes proactively keep track of their neighbor nodes within the zone, hence in a zone routing network, each node maintains a proactive unicast route to every other node within the specified zone. In the proposed protocol 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.
As the zone radius is significantly smaller than the network radius, the cost of learning the zones' topologies is a very small fraction of the cost required by a global proactive mechanism. 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.

Data Structure
SLS represents a fully 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. To reduce the redundancy in the data structure we have modified the data structure used by SLS, 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.
In order to exchange location information on the network, SLS uses four special packet types which are exchanged in the same way as data packets.
A LOCN packet as shown in fig. 5 is broadcasted by a node in its zone when it wants to inform other node(s) of its location. It contains the IP, location (latitude and longitude) of the source node and a timestamp.
When a node receives a LOCN packet from another node it unicasts back a location acknowledgement packet LACK as shown in fig. 6. 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.
Obtaining the locations of the mobile nodes, distance d between two mobile nodes can be calculated using (1) and slope theta is calculated using (2).
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. 7, 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. 8 is sent in response to a MGREQ packet. 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.
Entries are added and updated in ZNT on the reception of LOCN, LACK, MGREQ and MGRPL. Besides Zone Neighbor Table (   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].

Neighborhood Connectivity Updation
Nodes learn of their neighbors through transmission of LOCN, LACK, MGREQ and MGRPL packets used by SLS. In SEELAMP, 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 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. A soft state approach is followed to remove stale routes from the ZNT. Entries are removed after a certain interval of time with respect to time stamp in order to clear a node's table of possibly outdated information.

Multicast Tree Creation and Maintenance
SEELAMP 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].

Joining the existing tree -
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. 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.6.2 Link grafting -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.

Creating a new tree for 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.4
Maintenance of the tree -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 SEELAMP, the tree is updated regularly and also the preventive maintenance is done which kept the tree robust. 3.6.4.1. Tree Updation -In order to maintain the tree structure even when nodes move, group members periodically send tree_update requests to the backup 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 backup 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.4.2 Preventive Multicast tree Maintenance -A preventive approach is being proposed for tree reconstruction prior to link breakages using the following methods: a. Leaving the tree-In the proposed protocol a nonleaf 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 backup 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 HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/ WWW.JOURNALOFCOMPUTING.ORG 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.
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.

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.

Data Transmission Process
3.7.1 Tree member search within zone -Proactive topological routing operates within the k-hop routing 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 matches, then the node unicasts MGRPL to the request node with 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 signal to all nodes in its zone. The request node then sent the packet along the forward route created during MGRPL transmission.

3.7.2
Tree member search outside zone -In case of no entry found in the multicast tree table of the zonal nodes, these nodes search the multicast IP in the 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 matched entry node in the multicast tree member IP, latitude and longitude fields of the MGRPL. The matched entry node, in the request table, is actually the tree member node 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 as shown in fig.2) to forward the cached copy of the MGREQ to all their border nodes for further searching of the multicast group in the whole network as shown in fig.1. The border nodes then broadcast the MGREQ packet to all the nodes in their zone. These 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.

Diffused reactive routing
-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 upto the tree member is find out by directional diffused reactive routing using its location information. For that the request node selects only those nodes lying on the perimeter of its k-hop zone which are in the direction of the tree member, hence geographically closer to the tree member. As shown in fig. 2, node S selects the border nodes G and M only as their slope magnitude with the direction of tree member θg and θm are less than the threshold slope magnitude θt while the slope magnitude of D i.e. θd is more than θt. After selecting the nodes, the packet is forwarded to the next hops towards the border nodes. In case of sparse network, if there is no border node in the zone then the route search packet is forwarded to only those farthest neighbor nodes in the zone which are having slope less than the threshold slope with the direction of the tree member.
As shown in fig. 3, node S forwards the packet towards the neighbor nodes F and K through next hops E and H only as their slope magnitude θf and θk are less than the threshold slope magnitude θt while the slope magnitude of C i.e. θc is more than θt. If no such nodes are found then the route search packet is forwarded to all neighbor nodes within the zone which further forwards the packet to their border nodes in the direction of the tree member as described above. As shown in fig. 4, node S forwards the packet towards all the neighbor nodes C, F and H through next hops B, E and H as no node is having the slope less than the threshold slope magnitude θt. 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 diffused reactive routing it effectively reduces the traffic and saves the bandwidth a lot.
SEELAMP 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.
Algorithm: SEELAMP (MGREQ, ZNT_Size, MTT_Size, RT_Size) // RQ is the request node, ZNT is the zone neighbor table having entries for all neighbors in its zone and some other neighbors in case of free room, MTT is the multicast tree table maintained by each node having entries of those multicast groups to whom the node belongs as a tree member. RT is the request  Directional diffused forwarding algorithm forwards the MGREQ to the border nodes or the farthest nodes in the zone in the direction of the tree member. It selects only those border nodes whose slope with the direction of tree member is less than the threshold value of the slope. Slope can be find out by (2)

CONCLUSION
The Scalable Energy Efficient Location Aware Multicast Protocol is compared with Mesh Based Multicast, Per-Source Tree Multicast and Shared Tree Multicast protocols which are based on two popular multicast routing i.e. mesh-based and tree-based methodology for ad hoc networks. Comparison was made on various parameters like Packet Delivery Ratio, Network Structure Construction & Maintenance overhead, Latency due to link error, Energy Consumption and Load Distribution. SEELAMP eliminates the drawbacks of mesh based protocols, per-source tree and even that of shared tree protocols. It reduces the latency problem due to directional diffused forwarding routing and also the network partition problem when a link error occurs due to the failure of primary root. It also avoids any coupling with an underlying unicast routing protocols without incurring any extra overhead due to the incorporation of SLS for obtaining the physical location of the nodes and for other information sharing. Backup root also facilitates reduction in overhead in case of SEELAMP otherwise required for tree reconstruction and tree maintenance. This result in improved packet delivery ratio and energy balance compared to the conventional shared tree multicast (STM) due to preventive maintenance, local link repair and also because it can switch to the backup root when the primary root is overloaded or becomes invalid. Scalability is 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.