multicast routing in mobile ad hoc networks

Telecommunication Systems 25:1,2, 65–88, 2004 2004 Kluwer Academic Publishers. Manufactured in The Netherlands.

Multicast Routing in Mobile Ad Hoc Networks

HASNAA MOUSTAFA and HOUDA LABIOD {moustafa;labiod}@enst.frGroupe des Ecoles des Télécommunications (GET), Ecole Nationale Supérieure des Télécommunications(ENST), INFRES Department, 46 rue Barrault, 75634 Paris Cedex 13, France

Abstract. We focus on one critical issue in mobile ad hoc networks that is multicast routing. Advantagesand limitations of existing routing protocols are illustrated. Optimal routes, stable links, power conserva-tion, loop freedom, and reduced channel overhead are the main features to be addressed in a more effi-cient mechanism. In this paper, we propose a new on-demand multicast routing protocol, named SourceRouting-based Multicast Protocol (SRMP). Our proposition addresses two important issues in solving rout-ing problems: (i) path availability concept, and (ii) higher battery life paths. SRMP applies a source routingmechanism, and constructs a mesh to connect group members. It provides stable paths based on links’availability according to future prediction of links’ states, and higher battery life paths. This protocol suc-ceeded to minimize network load via designing optimal routes that guarantee reliable transmission and ac-tive adaptability. A performance comparison study with On-demand Multicast Routing Protocol (ODMRP)and Adaptive Demand-driven Multicast Routing (ADMR) protocol is undertaken. Analysis results showthe strength of the SRMP nodes’ selection criteria and its efficient energy consumption compared to theother two protocols.

Keywords: multicast routing, mobile ad hoc networks, source routing, forwarding group concept, link stateprediction, energy-conserving

Introduction

The advent of ubiquitous computing and the proliferation of portable computing deviceshave raised the importance of mobile and wireless networking. Recently, there has beena tremendous interest in broadband wireless access systems, including wireless localarea networks (WLAN), broadband wireless access and wireless personal area networks(WPAN). This domain is a subject of a huge research and many standardization activitiesare undertaken throughout the world, in many 3G/4G related study committees like ITU-R JRG 8A-9B, ETSI BRAN and IEEE 802. Research prototyping is currently underwayat many research academic and industrial institutions [9].

Moreover, Mobile Ad hoc NETworks (MANETs) are specific network configura-tions that appear in the context of these systems. They provide a powerful paradigm formodeling open self-configuring wireless networks and seem so appropriate to use in thefourth generation of mobile networks. In fact, this subdomain, in recent years, recog-nizes a significant explosion of activities due to the availability of low-cost peripherals(laptops, palmtops) equipped with wireless interfaces. A Mobile Ad hoc NETworking(MANET) working group has been created within the Internet Engineering Task Force(IETF) to develop a routing framework for IP-based protocols in ad hoc networks. Actu-

66 MOUSTAFA AND LABIOD

ally, mobile ad hoc systems are networks that are completely deprived of infrastructure.A MANET is an autonomous collection of mobile nodes communicating over wirelesslinks. Users can communicate with each other in a temporary manner with no centralizedadministration and in a dynamic topology that changes frequently. Each node partici-pating in this network acts both as a host and a router and must therefore be willing toforward packets for other nodes. As the case of all wireless environments, radio linksare not perfect and they are affected by several sources of errors resulting in a high andvariable bit error rate. Consequently, one of the critical issues of a MANET is its radiointerface. The second one is the mobility of the nodes. Therefore, it is necessary to de-velop powerful protocols able to ensure a correct reception of transmitted information onradio links. Among these protocols, those related to routing play a very significant rolein the performance of these systems. For this purpose, routing protocols used in wirednetworks are not appropriate and there is a need for new routing protocols, adapting tothe high dynamic topology of ad hoc networks.

Routing becomes an important and a major issue that must be considered carefully.Despite the fact that nodes such as laptops and personal digital assistants are often verylimited in resources (CPU capacity, storage capacity, battery power and bandwidth), afundamental challenge in the design of such networks is the development of routingprotocols fulfilling some key features like robustness, simplicity and energy conserving.

Since the 1990’s, studies did not cease enriching ad hoc routing field. In spite ofthe diversity of routing protocols, we find in the literature many classifications. Thefirst taxonomy reflects the existence of three main categories based on the routing strat-egy. Firstly, there are protocols, which use a proactive approach. The main feature ofthis class consists of keeping continuous up-to-date routing information from each nodeto each other node in the network. Secondly, there are the reactive (on-demand) rout-ing protocols with the key motivation of reducing routing load. Contrarily to proactivemechanisms, these protocols initiate routing activities on an “on-demand” basis. In addi-tion, hybrid protocols combine reactive and proactive characteristics, which enable themto adapt efficiently to the environment evolution.

Pioneer work [Royer and Toh, 14; Moustafa, 10] has been realized by Perkins andBhagwat (1994) and Johnson and Maltz [5]. As succeeding contributions, we also find[Royer and Perkins, 15; Toh et al., 16; Lee et al., 7; Lee and Kim, 6], Due et al. (1997),Toh (1997), Pearlman and Hass (1998), Pei and Gerla (2000), Park and Corson (2001),Clausen and Jacquet et al. (2001), Perkins and Royer (2002), and Ogier and Templin(2002).

QoS routing is another critical issue in MANETs. The goal of ensuring the Qualityof Service (QoS) is ideally to find a path that respects the constraints of QoS required bythe application. It is particularly a delicate problem in ad hoc networks due to mobilityand resource limitations. The idea is to eliminate among the selected routes those not re-specting certain imposed criteria, and to consider QoS aspects within routing algorithms(based on the used load, node’s activity, link’s stability or energy consideration). Thereis a challenge to design efficient routing protocols that satisfy different QoS with the

MULTICAST ROUTING IN MOBILE AD HOC NETWORKS 67

best use of available resources, through exploiting many metrics optimizing the use ofthe resources and meeting the requirements of the multimedia applications effectively.

The multicast concept for packet-oriented networks has been widely studied duringthe past years due to the huge increase of the number of bandwidth-intensive multicast-based applications [Papadimitrian et al., 13] in conjunction with the popular grow ofInternet applications. The advantage of multicast communication is its efficient savingin bandwidth and network resources since the sender can transmit the data with a sin-gle transmission to a group of receivers [Nikaein et al., 11]. Nowadays, typical ad hocenvironments offer an excellent deployment field for such applications because networknodes work in groups to carry out a given task. By extending the multicast technologyto the ad hoc domain, applications such as videoconferencing, distributed games andcomputer supported collaborative work (CSCW) can be provided with enhanced perfor-mance thanks to the optimization of network resources. However, most MANETs do notsupport multicast communications, even though wireless links have a broadcasting na-ture suitable to such communications. Certainly, multicast might play an important rolein ad hoc networks and many critical issues have to be addressed. Our work in this paperfocuses on one critical issue in future mobile ad hoc networks that is multicast routing.In fact, the advantages mainly expected are providing efficient saving in bandwidth, re-ducing communication cost, supplying efficient data delivery with highly unpredictablenode’s mobility, and supporting dynamic topology with unreliable wireless links. Mostof the work done for multicast communication has been carried out within a fixed staticInternet environment. These mechanisms are not suitable to multihop wireless envi-ronment due to the use of multicast trees, which are difficult to maintain each time theconnectivity changes. Besides, multicast trees usually require a global burdensome rout-ing substructure such as link state or distance vector. This leads to frequent exchange ofrouting vectors or link state tables due to continuous topology change causing excessivechannel and processing overhead. In addition, storage capacity and power consumptionare severely limited. Also, the unreliability of media degrades noticeably the transmis-sion quality (near-far effect, multipath fading, hidden and exposed station problems). Inthis paper, we suggest providing efficient multicast routing by applying a different kindof routing strategy, which modifies the conventional tree structure or deploy a differenttopology between group members. Until now, only a few multicast routing protocolshave been proposed. We propose a novel multicast routing protocol. Our scheme namedSource Routing-based Multicast Protocol (SRMP) operates in a loop-free manner andattempts to minimize both routing and storage overhead in order to provide efficientlyrobustness to host mobility, adaptability to wireless channel fluctuations, and optimiza-tion of network resources use. SRMP applies the source routing mechanism defined bythe Dynamic Source Routing (DSR) unicast protocol [Johnson and Maltz, 5] to avoidchannel overhead and to improve scalability. SRMP is a mesh-based, instead of tree-based, protocol that provides richer connectivity. It outperforms other multicast proto-cols by providing available stable paths based on future prediction for links state. Thesepaths also guarantee nodes stability with respect to their neighbors, strong connectivitybetween nodes, and higher battery life.


Our paper includes three main parts. The first one is devoted to the advantagesof multicast routing in the context of multihop wireless communications and states themost recent multicast routing protocols proposed by the MANET group. The second partgives a detailed description of our proposed protocol SRMP. A performance analysis ispresented in the third part, through a simulation model and relevant obtained resultscompared to ODMRP and ADMR routing protocols. Finally, we summarize the paper,providing concluding remarks and highlighting our future work.

1. Multicast routing in MANETs

In this paper, we focus on one critical issue that is multicast routing. Indeed, applyingmulticast communication within infrastructureless networks environment seems appro-priate and very interesting. In fact, the advantages mainly expected are providing ef-ficient saving in bandwidth, reducing communication cost, providing efficient deliveryof data taking in consideration unlimited mobility, and supporting dynamic topology.The advantages should be taken from broadcasting capabilities of the radio interface totransmit multicast traffic in each cell.

Multicast technique requires some technological constraints, where more capacityshould be added into the network as multicast addressing, capacity multiplication andspecific signalling protocols. Until now, only a few multicast routing protocols havebeen recently proposed for ad hoc networks.

Actually, multicast protocols used for static networks such as DVMRP, CBT, PIM,and MOSPF do not perform well in ad hoc networks. This fact is due to the fragilemulticast tree structure that should be reconstructed each time the connectivity changes.Furthermore, multicast trees usually require a global routing substructure such as linkstate or distance vector. This will require frequent exchange of routing vectors or linkstate tables due to continuous topology change causing excessive channel and process-ing overhead. In addition, storage capacity and power are severely limited requiringmuch less multicast state exchange. Traditional multicast protocols based on upstreamand downstream links are not suitable because creating and maintaining upstream anddownstream link status is not efficient in a wireless network [Chiang et al., 2]. To pro-vide efficient multicast routing in MANETs, a different kind of protocols should bedesigned. These protocols should modify the conventional tree structure, or deploy adifferent topology between group members [Lee, 8]. Designing multicast routing pro-tocols is a complex problem. Group membership can change, and network topologycan also evolve (links can fail and nodes can disappear). Some technical challenges ofmulticast routing are as follows [Obraczka and Tsudik, 12]: minimizing network load,providing basic support for reliable transmission, designing optimal routes, providingrobustness, efficiency, active adaptability, and unlimited mobility.

1.1. Classification

Because of the complexity of multicast routing in ad hoc networks, only a few propo-sitions are made. Globally, we notice two main categories, tree-based protocols (e.g.,


MAODV, ABAM, ADMR) and mesh-based protocols (e.g., ODMRP, PatchODMRP).As we focus only on on-demand multicast protocols, the following section presents theproposed routing protocols in this approach.

Multicast Ad hoc On-Demand Distance Vector Routing (MAODV) protocol ex-tends AODV to offer multicast capabilities [Royer and Perkins, 15]. It builds shared mul-ticast trees as needed (on-demand) to connect multicast group members. Thus, MAODVis capable of unicast, broadcast, and multicast. A group leader node maintains the mul-ticast group sequence number.

Associativity-based Multicast (ABAM) routing protocol [Toh et al., 16], estab-lishes the multicast sessions using the association stability concept introduced in ABRunicast protocol [Royer and Toh, 14] and requiring no underlying unicast routing proto-col. On-demand source based multicast trees are constructed using this concept, whichreduces communication overhead and improves end-to-end delay.

The On-Demand Multicast Routing Protocol (ODMRP) [Lee et al., 7] is based on amesh structure for connecting multicast members using the concept of forwarding groupnodes. Flooding within the mesh is applied. ODMRP operates by periodically flood-ing control packets to create and maintain the multicast forwarding state. In particular,while a multicast source using ODMRP is active, the source periodically floods Join-Data control packets. A node receiving a Join-Data packet stores the upstream node ID(backward learning) and rebroadcasts the packet. When the Join-Data packet reaches amulticast receiver, the receiver creates a Join-Table and broadcasts it to the neighbors.A node receiving the Join-Table becomes a member of the forwarding group if the nextnode ID of one of the entries of the Join-Table matches its own ID. It then broadcastsits own Join-Table. Each forwarding group member propagates the Join-Table until itreaches the multicast source via the shortest path. This process constructs and updatesthe routes from the source to the receivers, building a mesh of nodes. Multicast sourcesrefresh the membership information and update the routes by sending Join-Data period-ically. Group maintenance takes place through a soft state approach.

PatchODMRP [Lee and Kim, 6] extends the ODMRP providing a more efficientway to deal with small number of multicast sources and high mobility. To guaranteehigh data delivery ratio, the Join-Query interval has to be set shorter with larger mobility.However, it still considers the shortest path criteria.

Adaptive Demand-Driven Multicast Routing (ADMR) protocol [Jetcheva andJohnson, 4] creates source-based forwarding trees connecting each source with the re-ceivers of the multicast group. The multicast forwarding state for a given multicast groupand a source is conceptually represented as a loosely structured multicast-forwardingtree routed at the source. The forwarding mechanism is based on the shortest-delay paththrough the tree to the receiver members of the multicast group. A sequence numberis included in the packet’s header. This sequence number uniquely identifies the packetand is generated as a count of all ADMR packets flooded in any way that originated fromthe source. Packets forwarding is based on two types of flooding: tree flood and networkflood. Tree flood occurs among nodes of the multicast tree, this is indicated by the sourceaddress (original sender) and destination address (multicast group address) in the packet.


Table 1Comparison of multicast protocols.

ADMR ODMRP PatchODMRP MAODV ABAM

Multicast delivery Source-based Mesh Mesh Shared-tree Source-based(Configuration) Tree TreeRouting approach On-demand On-demand On-demand On-demand On-demandDependency on No No No No Nounicast routingPeriodic flooding Keep_alive Join-data/Join-

tableJoin request Route request No

Control overhead At tree construc-tion and mainte-nance

At gp. Formationand periodic flood

At gp. Formationonly

At tree con-struction andmaintenance

At tree forma-tion and repair

Routing philosophy Flat Flat Flat Flat FlatRouting metric Freshest and Shortest path Shortest path Freshest and Tree and link

shortest path shortest path longevity

While network flood is flooding among all nodes in the network. ADMR sends Keep-alive messages to maintain the existing forwarding state for the multicast distributiontree for the source and the group. The absence of data packets and Keep-alive messageswithin a certain period of time is an indication of forwarding tree disconnection. Firstly,a local repair procedure is performed to reconnect the tree; if it fails a global reconnectprocedure is used. Moreover, ADMR defines a pruning mechanism if a lack of passiveacknowledgements from downstream nodes occurred.

Table 1 summarizes the previously discussed multicast routing protocols.

1.2. Synthesis

Actually, most existing multicast protocols face several problems in tree maintenanceand frequent reconfiguration when link failures occur. These protocols depend on up-stream and downstream nodes requiring storage and control overhead. Additionally,some protocols consider the shortest path as a criterion for path selection which is notusually suitable to the high and unpredictable variation of the topology of ad hoc net-works. Similar to unicast routing, multicast routing is a young research domain, nostandard has been adopted yet and many issues have to be addressed and more studiesare needed. During our studies in this area, we noted the following observations;

• performance studies are not completely finalized,

• the validation of the presented hypothesis being mainly conducted through simulationresults with few theoretical analysis,

• analytical studies being complex are not approached at all,

• the lack of standards in this area of study leads to several works and propositions,

• diverse metrics were proposed through few mechanisms to ensure the respect of somenetwork related criteria.


In this context, we propose a new on-demand multicast routing protocol, namedSource Routing-based Multicast Protocol (SRMP). This protocol constructs a mesh toconnect group members thus providing robustness against mobility. Multicast routesand group memberships are obtained on-demand to use efficiently network resources,avoiding channel overhead and improving scalability.

2. SRMP: a new multicast routing protocol

Our protocol named SRMP is a mesh-based multicast routing protocol. A mesh structure(arbitrary subnetwork) is established on-demand to connect group members, providingricher connectivity among multicast members. We define a multicast mesh as a subsetof the network topology that provides at least one path from each source to each receiverin the multicast group. During mesh establishment, we apply the concept of ForwardingGroup (FG) nodes [Chiang et al., 2]. The mechanism of source routing proposed in DSRunicast protocol is applied, in a modified manner. Available paths are provided throughfuture prediction for links’ state.

In the following sections, we start by giving an overview on SRMP. Then, we pointout the selection criteria used in mesh establishment, stating the metrics used to selectFG nodes. Subsequently, we mention the used data structures. Finally, we describe theprotocol operation and present our simulation results.

2.1. Protocol overview

SRMP is an on-demand multicast routing protocol. Route selection takes place throughestablishing a multicast mesh, started at the multicast receivers, for each multicast ses-sion. We address two important issues to solve routing problems: (i) path availabilityconcept, and (ii) higher battery life concept. The former allows the protocol to distin-guish between available and unavailable paths. We define the path as available or un-available according to the radio quality of each link constituting the path and the nodesstability at both ends of each link. The latter biases the protocol towards choosing achannel that tends to power conserving. Then, the combination of these two criteriaallows the selection of available and power conserving links.

Advantages are provided over tree-based protocols in several means:

– Providing redundant paths between members: thus topology changes are less likelyto disrupt the flow of multicast data or require the re-construction of the routing struc-ture. This returns to the fact of applying a mesh-based approach that grants robustnessand richer connectivity between group members,

– Avoiding the drawbacks of multicast trees (intermittent connectivity, traffic concen-tration, frequent tree reconfiguration, non-shortest path in a shared tree),

– Applying efficient criteria in selecting FG nodes, where paths’ availability and nodes’strong connectivity are fulfilled.


To establish a mesh for each multicast group, SRMP uses the concept of FG nodes.We consider the forwarding group as a set of selected nodes responsible for forward-ing multicast data between any member pairs [Chiang et al., 2]. This scheme can beviewed as a “limited scope” flooding within a properly selected forwarding set. Thekey challenge in efficient multicasting is the choice of FG nodes and how to elect andmaintain them. SRMP achieves a compromise between the size of the selected nodes,the availability and stability of the selected paths.

2.2. FG selection criteria

We apply an efficient FG nodes selection criteria that establishs a mesh structure pos-sessing the following characteristics:

• available paths based on future prediction for links’ state. By “a path being avail-able”, we mean that the radio quality of each link in the path satisfies the minimalrequirements for successful communication,

• reliable paths where nodes are stable with respect to their neighbors,

• strong connectivity between nodes,

• higher battery life.

Then, we define four metrics as our selection criteria to establish the mesh struc-ture: association stability, link signal strength, link availability, and higher battery life.

2.2.1. Association stabilityThis metric measures how long the node is stable with respect to each neighbor. It hasbeen first introduced in ABR protocol [Royer and Toh, 14], and is known as the degreeof association stability. Association stability is calculated by each node with respectto each neighbor through the use of associativity ticks field stored in the node’s Neigh-bor_Stability_Table. It is incremented each time the node receives a beacon indicatingneighbor’s existence. A node is considered stable with respect to a certain neighbor,when the accumulated associativity ticks value corresponding to this neighbor fulfills acertain predefined threshold.

2.2.2. Link signal strengthThis metric measures the signal strength between each node and each of its neigh-bors indicating connectivity strength. SRMP uses this metric to select links that offerstronger connectivity between nodes. Signal strength is calculated according to the levelof strength the beacon is received, where it is classified as weak or strong. In fact, clas-sification is done through comparing the level of strength of the received beacon with acertain predefined threshold.

2.2.3. Battery lifeThis metric periodically calculates the current battery power, which is a decreasing func-tion of time and processed packets. We introduce this metric for power conservation of


nodes. Paths with higher battery life, indicating less power consumption, are only se-lected.

Let Bp(0) is the initial battery power predefined for each node. The node is consid-ered as possessing high battery life, as long as its battery life counter (see formula (1))fulfills a certain predefined threshold.

Bp(t) = Bp(current) − [PCgp + PCrp + PCfp + K]. (1)

• Bp(t): battery power at time t , Bp(current): current battery power (initially,Bp(current) = Bp(0)).

• PCgp: total power consumed for each generated packet (including processing andtransmission).

• PCrp: total power consumed for each received packet (including reception andprocessing).

• PCfp: total power consumed for each forwarded packet (including reception, process-ing and transmission).

• K: power consumed by the node itself (equipment).

2.2.4. Link availability estimationPath reliability is an important consideration to eliminate rerouting operation and selectan optimal path. SRMP decreases the frequency of path failure, through the use ofa link availability estimation metric during path selection. This metric is based on aprobabilistic model for future availability of the path. We use the prediction-based linkavailability estimation introduced in [Moustafa, 10].

2.3. Data structures

To enable SRMP routing, we define the following data structures:

• Neighbor_Stability_Table gathers continuous node-neighbor information (table 2),

• Multicast_Message_Duplication_Table identifies each received Join-request or datapacket (table 3),

• Multicast_Routing_Cache stores all possible routes from each node to each multicastgroup (table 4),

• Receiver_Multicast_Routing_Table maintained at each receiver for each multicastgroup, and stores the used route between each receiver and each source (table 5).

Table 2Neighbor_ Sability_Table.

Neighbor Type Associativity ticks Signal strength Link availability


Table 3Multicast _Message_ Duplication_ Table.

Source ID Sequence number Type

Table 4Multicast _Routing _Cache.

Group ID Type Route to receiver Timer

Table 5Receiver_ Multicast_ Routing_ Table.

Group ID Source ID Route to source Timer

2.4. Operation

Similar to the operation of on-demand routing protocols, a request phase and a replyphase comprise the protocol. The request phase invokes a route discovery process tofind routes to reach the multicast group. Different routes to the multicast group are setupduring the reply phase through FG nodes selection and mesh construction.

The following sections describe the request phase, reply phase, FG nodes selection,and data transmission and forwarding through the constructed mesh.

2.4.1. Route request phaseThis section discusses the route request phase of our protocol. It starts when a sourcenode, which is not a group member, wishes to join the group. At this time, it broad-casts a Join-request packet to neighbors invoking a route discovery procedure towardsthe multicast group. The Join-request packet is shown in figure 1, it contains the IDof the source node in its Source ID field, the multicast group ID in its DestinationID field, and a Sequence number field set by the source node. To eliminate the pos-sibility of receiving multiple copies for a Join-request, each node receiving a Join-request compares the identification of each received packet with those stored in its Mul-ticast_Message_Duplication_Table.

We consider this phase as a modified form of the route request in DSR protocol.The major mismatch arises in the means of applying the source routing concept. Thesource route accumulates in the Join-reply packet during the reply phase instead of ac-cumulating in the request phase. Thus, we eliminate channel and routing overhead.


2.4.2. Reply phase and FG nodes selectionInitially, a multicast receiver initiates the reply phase. A multicast receiver, when re-ceiving a Join-request packet, first checks for stability among its neighbors includingassociativity ticks, signal strength, and link availability towards each neighbor. Batterylife is also checked considering consumed power needed to transmit to each neighbor.A neighbor is selected as an FG node, if these metrics satisfy predefined thresholds. Thereceiver starts sending Join-reply message to it setting its type as member node in theNeighbor_Stability_Table. In the case, where there are no neighbor nodes satisfying thepredefined thresholds for stability and battery life, the node with the best metrics amongall the neighbors will be selected as FG node. Figure 2, shows the Join-reply packetformat, it stores the multicast group ID in a Source ID field and the ID of the requestingnode (source of Join-request) in a Destination ID field. A source route from the multi-cast receiver (source of Join-reply) to the requesting node will also accumulate, duringJoin-reply propagation, in a Route record field in the packet.

An FG node, receiving a Join-reply, first creates an entry to the multicast group inits Multicast_Routing_Cache. In this entry, the node sets its state as FG node and copiesthe reversed accumulated route of the received Join-reply. It also stores the source ofthe Join-reply, and the time at which the packet is received. This node then performssame previous steps for selecting FG nodes among neighbors. This process continuesuntil reaching the source, constructing a mesh of FG nodes connecting group mem-bers.

A source receiving a Join-reply packet becomes a multicast source and creates anentry to the multicast group in its Multicast_Routing_Cache. Due to mesh structure,more than one Join-reply may be received by the source for the same multicast group.

Figure 1. Format of the Join-request packet.

Figure 2. Format of the Join-reply packet.

Figure 3. Format of the multicast-RERR packet.

Figure 4. Format of the leave group message.


Figure 5. Data packet format.

Hence, multiple routes can be stored for the same multicast group. An explanation dia-gram is presented in figure 6.

After mesh creation, new Join-request packets to any multicast group can receivereplies from any FG member node, having unexpired routes to this multicast group inits cache. In this case, the FG node broadcasts a Join-reply to the requesting source withthe Route record field taken as its ID together with the corresponding route stored inits cache. This process follows the same previous selection among the neighbors untilreaching the requestor node. Thanks to the source routing concept, loop formation isprevented during Join-reply propagation.

2.4.3. Data forwardingNext, we consider how data is transmitted through the multicast mesh. A source startstransmission via selecting one of the routes stored in its cache. The shortest path route interms of number of hops is selected, or the freshest route if more than one shortest pathroutes are found. The data packet format is shown in figure 5, it carries in its header theselected route indicating the sequence of hops to be followed.

Each FG node receiving a data packet forwards this packet, if it stores in its cacheat least one valid route towards the multicast group and the packet is not duplicated.This leads to an attractive feature in SRMP, preventing packets transmission throughstale routes and minimizing traffic overhead. This process continues until reaching allmulticast receivers.

A multicast receiver, receiving a data packet for the first time, creates an entry inits Receiver_Multicast_Routing_Table. To guarantee data transmission to all multicastreceivers, nodes duplicate transmission if the selected route leads directly to the multicastgroup. We define duplication in transmission, as selecting one more route followingsame previous criteria and transmitting data to both routes. An explanation diagram ispresented in figure 7.

2.4.4. Descriptive exampleLet us use the example in figure 8 to illustrate how the protocol works. Assuming thatthere is only one multicast group of multicast address 01 (for simplicity), we consider S

as the multicast source wishing to join the group and (R1, R2) as the multicast receiversof the group.

In figure 8(a), we show the route discovery process. S broadcasts a Join-requestpacket to its neighbors; meanwhile duplication of Join-request is detected and discarded.First, node S broadcast the Join-request to its neighbors (x, y, z). Then each neighbor in


Figure 6. Reply phase and mesh establishment.

its turn starts to broadcast the packet to its neighbors until reaching the receivers, at thesame time duplication in reception is detected and ignored at (x, y, z, and R1).

The reply phase from both receivers (R1, R2) is shown respectively in figures 8(b)and 8(c). This process selects nodes X and Y as FG nodes, following SRMP selectioncriteria and constructing the mesh. During Join-reply propagation, cache entries are


Figure 7. Data forwarding.

created or refreshed at each node. First R1 sends its Join-reply (assumed at time 1) to X

and Y , nodes X and Y starts to store in their caches new entries (01 FG 01 1) indicatingthe route to the multicast group which is for R1 up till now. Then R2 starts to send itsJoin-reply (assumed at time 1.5) to node Y , node Y will update the timer of the entry (01FG 01 1) in its cache refreshing the same route to the multicast group. The process ofJoin-reply transmission continues in the same way until the source, storing or refreshingroutes in each node’s cache.

Due to host mobility and/or interference, an established route may be broken.Route maintenance should concern how routing problems are reported and recovered.To achieve this, SRMP introduces several mechanisms including: multicast mesh recon-figuration, node-neighbors information, mesh refreshment, and member node pruning.

2.5. Maintenance procedures

In our protocol, we address several mechanisms by which the multicast mesh is re-freshed, link breaks are detected and repaired, continuous node-neighbor information is


(a)

(b)

Figure 8. A network example: (a) Join-request generation by S; (b) Join-reply generation by R1 to S;(c) Join-reply generation by R2 to S.


(c)

Figure 8. (Continued.)

provided, and pruning is supported allowing any node to leave the group. Our goal isto keep the lifetime of a route as long as possible. We make use of MAC layer beaconsand introduce two new messages: the multicast-RERR message, and the leave groupmessage.

2.5.1. Neighbor existence mechanismSRMP uses MAC layer beacons to provide each node with neighbors existence informa-tion. When a node receives a neighbor’s beacon, it updates or creates the correspondingentry of this neighbor in its Neighbor_Stability_Table. Entry update takes place throughincrementing the associativity ticks field, and setting the signal strength field accordingto the level of strength the beacon is received. In addition, the node performs continuousprediction for link’s availability towards the neighbor and updates its link availabilityfield. If no beacons are received by a node from a certain neighbor upto a certain periodof time, the node indicates neighbor’s movement and updates its stability table fieldstowards this neighbor.


2.5.2. Mesh refreshment mechanismIt follows a simple mechanism making use of data packets propagation and requiring noextra control overhead. During data packets’ propagation, route refreshment for differentpaths on the mesh takes place. Each time the source transmits a data packet; it updates inits cache the timer of the used route. Typically, an FG node forwarding this packet scansthe packet header, and refreshes in its cache the corresponding route entry timer. Fur-thermore, a multicast receiver scans the header of each received data packet, refreshingits corresponding table entry timer to the source. We guarantee that no stale routes arestored. Periodically, each node checks its timers and purges out expired multicast groupentries.

2.5.3. Link repair mechanismMesh reconfigurations are required to adapt the multicast mesh when nodes in the meshmove. SRMP reacts to nodes’ mobility on-demand, such that it detects link failure duringdata transmission through the use of MAC layer support. The following two mechanismsare addressed: (i) how to maintain routes when a link fails between two FG nodes, and(ii) how to maintain routes when a link fails between a multicast receiver and an FGnode. Note that mesh reconfigurations are not needed if the stability characteristicstogether with high battery life paths are valid through out the lifetime of the multicastcommunications.

SRMP follows the same idea proposed in DSR unicast protocol when link failureoccurs between two FG nodes. In this case, the node detecting failure reports it to theoriginal source of data packets. First, it generates a Multicast-RERR packet indicatingthe broken link. Then, it deletes from its cache any routes containing the broken link.Nodes on the way to the source, receiving this packet, in turn clean their caches from allroutes containing the broken link. We show the format of the Multicast-RERR packet infigure 3.

For a link failure between an FG node and a multicast receiver, the FGnode detecting the failure simply deletes the receiver membership from its Neigh-bor_Stability_Table. Periodically, each FG node checks its neighbor table and deletesfrom its cache routes to multicast groups possessing no more members. Then, aMulticast-RERR is sent to all member neighbors reporting the failure. The Route tosender field in this packet is set to the member neighbor address. Each member neigh-bor, receiving this packet, in its turn, cleans its cache from routes containing this link.This process is repeated until all member nodes in the mesh are visited.

2.5.4. Pruning schemeSRMP employs an effective pruning mechanism allowing a member node to leave themulticast session. We distinguish two cases: (i) when an FG node wants to prune itself,and (ii) when a multicast receiver wants to prune itself.

A multicast source wishing to leave a multicast group simply stops transmittingdata to this group, and deletes from its cache entries concerning this group. This leads toexpiration of all routes connecting this source to the multicast group due to no refresh-


ment. Similarly, the Receiver_Multicast_Routing_Table entries towards this source willbe expired and deleted. Typically, a multicast receiver wishing to leave a multicast groupsends a leave group message to all its member neighbors, and deletes from its table allentries corresponding to this group. A member neighbor, receiving this message, can-cels in its turn the receiver membership from its Neighbor_Stability_Table. Periodically,each FG node checks its neighbor table entries for group memberships. When no moremembers are found for a multicast group, all routes towards this group are deleted fromthe cache. Then, the node sends a Multicast-RERR message to all member neighborsfollowing previous procedure in link failure. Figure 4, shows the format of the leavegroup message. The ID of the multicast session is carried in a multicast group ID field,while a Neighbor ID field carries the ID of the member neighbor to which the messageis sent.

Furthermore, an FG node wishing to leave a multicast group starts by sending aleave group message to its neighbors, deleting from its cache all multicast group en-tries. Each neighbor receiving this message cancels the FG node membership from itsNeighbor_Stability_Table, deletes routes containing this node from its cache, and sendsMulticast-RERR message to its member neighbors following previous procedure of linkfailure. The Broken link field in this message stores the FG node, which has left.

2.5.5. DiscussionThe above discussion concerns some interesting features in SRMP. First, it offers reli-able paths in terms of nodes’ stability with respect to neighbors and strong connectivitybetween each link’s end-points. Second, it offers much longer route lifetime comparableto other existing protocols. This is achieved through constructing routes with availablelinks and less consumed power. One significant characteristic in our protocol is its reac-tive approach in discovering routes and detecting link failures. This minimizes channeland storage overhead, improving scalability of the protocol.

While most of the multicast protocols suffer from the effect of tree structure, thiscan be significantly reduced in SRMP through constructing a mesh topology to connectgroup members. In addition, we achieve minimized flooding scope thanks to applyingthe FG node concept during mesh establishment phase.

Aiming at justifying our proposition and investigating the performance of the pro-tocol, we evaluated the performance of SRMP in a variety of mobility and communica-tion scenarios.

3. Simulation results and analysis

Network Simulator2 (Ns2) is used to study the performance of SRMP. Ns2 is a discreteevent simulator developed at Berkeley University targeted at networking research [Falland Varadhan, 3]. It provides support for modeling and performing accurate simulationsof mobile wireless networks.


3.1. Simulation and scenarios model

The aim of our performance analysis is to evaluate the behavior of SRMP and to compareits performance to both ODMRP and ADMR protocols, since they are reactive routingprotocols. We chose ODMRP because it uses the mesh structure in forwarding multicastpackets, and ADMR as it is more classical based on using multicast forwarding trees.

The overall goal of our simulation study is to analyze the behavior of our protocolunder a range of various mobility scenarios. Our simulations have been run using aMANET composed of 20 nodes moving over a rectangular 1200 m × 300 m space, andoperating over 600 seconds of simulation time. The radio and MAC models used aredescribed in [Fall and Varadhan, 3]. Nodes in our simulation move according to theRandom WayPoint mobility model [Bettstetter et al., 1]. The movement scenario filesused in each simulation are characterized by pause times; we studied 6 different pausetimes (0, 30, 60, 120, 300, 600). A pause time of 600 represents a stationary network,while a pause time of 0 represents a network of very high mobility in which all nodesmove continuously.

Our performance evaluation is a result of 120 different simulations, using 20 dif-ferent simulations for each pause time. At each pause time, we study runs with a maxnodes movements’ speed of 20 m/s and others with a max nodes movements’ speed of1 m/s. For each pause time and max nodes movements’ speed, we randomly generated10 different scenarios. The multicast traffic sources in our simulation are constant bitrate (CBR) traffic. Each traffic source originates 64 bytes data packets, using a rate of4 packets/s.

We used two different combinations of number of multicast groups, sources, andreceivers. In order to observe the behavior of the routing protocol in a simple environ-ment, we considered a first scenario with 1 multicast source and 10 multicast receivers.The second scenario consists of 3 groups with 1 source and 3 receivers each.

3.2. Observed results

This section presents our simulation results. The aim of this simulation analysis is toevaluate the performance of SRMP, and to compare it with ODMRP and ADMR underdifferent network scenarios. We analyze our results in terms of end-to-end delay, deliv-ery ratio, and control packets and bytes overhead. The obtained performance results areillustrated and discussed below.

Figure 9 shows the evaluation of the cited performance metrics as a function ofpause time in the 1-source and 10 receivers scenario. Regarding the delivery ratio infigure 9(a), ODMRP and ADMR show nearly the same behavior. SRMP shows incre-mental delivery ratio starting from intermediate mobility, and outperforms ODMRP andADMR starting from pause time 500, when the network tends to be stationary. Thisrefers to the links’ quality compared to ODMRP and ADMR. The signal strength metricused in the selection criteria while constructing the mesh, allows SRMP links in this caseto react better towards interference and distortion that is frequent in ad hoc environment.In case of continuously moving nodes and intermediate mobility nodes, SRMP exerts


(a) (b)

(c) (d)

Figure 9. Results for 1 source and 10 multicast receivers: (a) delivery ratio; (b) delay; (c) packets controloverhead; (d) bytes control overhead.

less delivery ratio with no great impact. This returns to the fact of network flood usein ODMRP, which reduces the latency of link breakage discovery increasing the deliv-ery ratio. Similarly, the use of tree and network flood in ADMR to forward multicastpackets, together with the shortest-delay path, increase the delivery ratio.

Figures 9(c) and (d) illustrate the routing overhead experienced in the MANETdefined space. In terms of both packets and bytes overheads, SRMP provides betterresults. This is due to the frequent network flood use in ODMRP. For ADMR, this refersto the network flood together with the overhead in its local and global repair mechanismsand the keep-alive messages adding to protocol overhead. On the contrary, SRMP showsmuch less overhead thanks to its source routing approach across different mobility levels.In fact, the use of extra header packets fields in ADMR and the large size Join-table inODMRP compared to SRMP Join-reply packet, causes a worst performance comparedto SRMP.

Figure 9(b) demonstrates the transmission delay; ODMRP and ADMR show nearlythe same behavior. SRMP shows an increase of delay in the case of very high mobility,this comes from the frequent application of the selection criteria to set up new links dueto the high link failure rate. It is clearly noticed that this increase in delay drops fastwith the little decrease in mobility. But thanks to these selection criteria, SRMP is ableto assure more stable, longer route lifetime, and higher battery life paths consuming lessenergy compared to the other two protocols. Using these paths, the probability of links’


(a) (b)

(c) (d)

Figure 10. Results for 3 sources and 3 multicast receivers per source: (a) delivery ratio; (b) delay; (c) packetscontrol overhead; (d) bytes control overhead.

failure and paths reconstruction is minimized, minimizing the protocol’s overhead by arealized difference and providing more quality links reacting better in a radio environ-ment.

For the 3 sources and 3 receivers’ scenario, SRMP depicts out nearly the same be-havior as clearly illustrated in figures 10(a) and (b). In particular, the delay differencewith respect to ODMRP and ADMR is minimized compared to the first scenario. Thisis due to the lower number of receivers for each source, decreasing the delay consumedduring paths’ selection. Moreover, SRMP outperforms ODMRP and ADMR at inter-mediate and low mobility, this refers to the strength and availability of the used linksshowing better effect for this mobility cases.

Figure 11 illustrates the behavior of SRMP and how it adapts to link failure rel-ative to the two scenario cases. We calculate the average link failure rate to show therobustness of the protocol for each scenario case. The average link failure rate decreasesgradually with pause time decrease for our two scenario cases. This is normal, sincelinks’ break is more frequent at the cases of higher mobility (smaller pause time). As themobility of nodes increases, the more possibility of links’ break takes place. Compar-ing the two scenarios cases, scenario1 has better impact on the average link failure ratethan scenario2. This is due to the construction of a denser mesh, constituting of a larger


Figure 11. SRMP average link failure rate.

fraction of forwarding group nodes, which provides more robustness and increases thepossibility of reaching multicast receivers due to the existence of more possible routes.

We have chosen to run our simulations under different combinations of scenarios.Scenario1 (1 source and 10 receivers) is useful to analyze the routing protocol perfor-mance in a simple environment. While scenario2 (3 multicast groups, each group con-sisting of 1 source and 3 receivers) is useful to investigate the behavior of our protocolin the presence of multiple groups. The performance results have the same general be-havior for the two scenarios. The difference in scenario1 from scenario2 is that when alarger number of nodes are receivers for the multicast group, a larger number of nodeswould have forwarding state. In fact the density of the nodes with forwarding state be-comes higher. This translates the SRMP performance difference between scenario1 andscenario2 (figures 9 and 10, respectively). At scenario1, SRMP performs better in termsof delivery ratio (figure 9(a)) and control overhead (figures 9(c) and (d)). It shows a 20%better delivery ratio compared to scenario2 (figure 10(a)), and the impact on the controloverhead is about 7 times improved with respect to scenario2 (figures 10(c) and (d)).In fact, scenario1 causes a more denser mesh in terms of forwarding group nodes giv-ing more probability to reach multicast receivers and more probability for having stableroutes, this leads to improvements in the delivery ratio and control overhead. Whilescenario2, provides a sparse mesh for each multicast group, this opposes the previousprobabilities.

Regarding the delay (figures 9(b) and 10(b), respectively), SRMP has better impacton the delay at scenario2. This refers to the fact of the less number of receivers for eachmulticast group, requiring lesser time to construct the group mesh and to transmit a datapacket for all multicast receivers of the group.


4. Conclusion

In this paper, we focus on one critical issue in MANETs that is multicast routing. Rout-ing requirements are reviewed. Particularly, the main existing multicast routing proto-cols are cited. Their advantages and limitations are illustrated. Drawbacks of existingproposed multicast mechanisms involve the necessity of designing a new generation ofpowerful schemes. In fact, mainly flexibility, adaptability, distribution, power conserva-tion, scalability and robustness are the main features to be addressed in a suitable proto-col that fulfills these requirements. Our aim in this study is to present an alternative toexisting strategies related to multicast routing. Contrarily to most of existing protocols,our protocol follows a mesh-based approach to establish and maintain routes. More-over, thanks to applying the FG nodes concept, minimized flooding scope is achieved.Robustness and richer connectivity are then provided. Also, SRMP follows a reactiveapproach saving network resources and routing load. Consequently, SRMP guaranteesloop freedom and fewer overheads in maintaining next hop information, due to apply-ing the source route concept. Other significant strengths of this protocol include thepowerful FG node selection criteria, route maintenance and pruning capability.

In fact, SRMP uses no periodic network flood of control packets. Thanks to itsselection criteria in mesh construction, stable paths with future links availability andhigher battery life are provided. This assures better quality of links and minimizes thepossibility of links’ failure and the overhead needed to re-construct the paths.

A performance evaluation of the proposed scheme is carried out via simulation.A performance evaluation of SRMP is compared to ODMRP and ADMR protocols. Ourprotocol shows a significant decrease in the control overhead; its impact on the delayis acceptable depending on the mobility type, and outperforming ODMRP and ADMRat intermediate and low mobility cases. SRMP provides an incremental delivery ratiostarting from intermediate mobility.

As a means of vindicating our proposition, we focus on comparing it with ODMRP,as it is a mesh-based protocol. In fact, SRMP achieves some characteristics that grant itmore superiority over ODMRP.

It is clear that SRMP outperforms ODMRP in its effective mesh refreshment mech-anism, making use of data propagation and requiring no extra control overhead. Mean-while, ODMRP depends on periodical (Join-query/Join-reply) to refresh route entriesconstituting the mesh. In addition, the request/reply phase in SRMP is more efficient,such that the request is sent once by a source wishing to join the group. Then small sizereply packets are sent back. ODMRP follows a different approach by using periodicalquery/reply during the period of data transmission requiring more control and commu-nication overhead. Furthermore, it transmits a reply table with multiple reply entries todifferent sources causing reliability problems, such that the verification of the Join-replydelivery that may not be handled by the MAC layer and special mechanisms are requiredto overcome this problem.

In terms of link breakage, ODMRP has no special mechanism; it only assumes thata receiver wanting to move would stop sending replies. On the other hand, SRMP pos-


sesses an effective link breakage mechanism to discover unavailable routes and deletethem from nodes caches. It also uses a special pruning mechanism allowing mesh mem-bers to leave the group at any time.

For future work, we intend to compare SRMP with more multicast routing proto-cols, considering new performance metrics such as energy-based mobility and link sta-bility metrics. We also intend to implement the protocol with different group mobilitymodels, which are suitable for multicast applications.

References

[1] C. Bettstetter, H. Hartenstein and X. Pérez-Costa, Stochastic properties of the random waypoint mo-bility model: Epoch length, direction distribution and cell change rate, in: ACM MSWiM’02, 2002.

[2] C. Chiang, M. Gerla and L. Zhang, Forwarding Group Multicast Protocol (FGMP) for multihop,mobile wireless networks, Cluster Computing 1(2) (1998) 187–196.

[3] K. Fall and K. Varadhan, NS notes and documentation, The VINT project, UC Berkeley, LBL,USC/ISI and Xerox PARC (1998) work in progress.

[4] J.G. Jetcheva and D.B. Johnson, Adaptive demand-driven multicast routing in multi-hop wireless adhoc networks, in: ACM MobiHoc’01, Long Beach, CA, USA, 2001.

[5] D. Johnson and D. Maltz, Dynamic source routing in ad hoc wireless networks, in: Mobile Computing,eds. T. Imielinski and H. Korth (Kluwer, Norwell, MA, 1996).

[6] M. Lee and Y.K. Kim, PatchODMRP: An ad-hoc multicast routing protocol, in: Proc. of the 15thInternat. Conf. on Information Networking, 2001, pp. 537–543.

[7] S. Lee, W. Su and M. Gerla, On-demand multicast routing protocol in multihop wireless mobilenetworks, Mobile Networks and Applications 7 (2002) 441–453.

[8] S.-J. Lee, Routing and multicast strategies in wireless mobile ad hoc networks, Ph.D. thesis, Univer-sity of California (2000).

[9] Mobile Ad hoc NETwork (MANET), URL: http://www.ietf.org/html.charters/manet-charter.html (1999).

[10] H. Moustafa, Multicast routing in mobile ad hoc networks, Master thesis (2001).[11] N. Nikaein, H. Labiod and C. Bonnet, Error recovery scheme for multicast transmission overwireless

networks, in: IEEE ICC’2000, New Orleans, LA, USA, 2000.[12] K. Obraczka and G. Tsudik, Multicast routing issues in ad hoc networks, in: IEEE Internat. Conf. on

Universal Personal Communication (ICUPC’98), 1998.[13] Papadimitrian et al., Optical multicast in wavelength switched networks, IPO working group, Internet

draft <draft poj-optical multicast-01.txt> (2001).[14] E. Royer and C. Toh, A review of current routing protocols for ad hoc mobile wirless networks, IEEE

Personal Communications (1999).[15] E.M. Royer and C.E. Perkins, Multicast Operation of the ad-hoc on-demand distance vector routing

protocol, in: Proc. of the 5th Annual ACM/IEEE Internat. Conf. on Mobile Computing and Network-ing, 1999, pp. 207–218.

[16] C.-K. Toh, G. Guichal and S. Bunchua, ABAM: On-demand Associativity-Based Multicast routingfor ad hoc mobile networks, in: 52nd IEEE Vehicular Technology Conf., 2000, Vol. 3, pp. 987–993.

multicast routing in mobile ad hoc networks

Documents