Introduction 93 The mobility of the nodes creates a continuously changing topology for communication. Routing paths break and new ones are formed dynami- cally. Unlike the wired network, wireless medium is a broadcast medium; all nodes in the transmission range of a node can hear the packets simulta- neously. In light of the above differences, the issues and challenges for intercommu- nication in MANETs are more complex than their wired counterpart. IP multicasting was first proposed over a decade ago [1] as an extension to Internet architecture to support multiple clients at network layer. The funda- mental motivation behind IP multicasting is to save network and bandwidth resource via transmitting a single copy of data to reach multiple receivers si- multaneously. A basic principle for the forwarding tree is to branch as close to the receivers as possible. In ad hoc networks, we want to adhere to this requirement as closely as possible because of the severe bandwidth limitations in ad hoc networking environments. Similar to Internet multicasting, it is necessary to deal with dynamic mem- berships in multicast groups in ad hoc networks. In both Internet and ad hoc multicasting, dynamic membership refers to the fact that individual clients may join and leave multicasting sessions dynamically. As a result, a multicast pro- tocol needs to define operations of member join and leave, and how to recover from routing failure. The data forwarding path is constructed either as a tree or a mesh. What makes ad hoc multicasting distinguished from Internet multicasting is that mobile nodes could move around freely and rapidly. In other words, we have to deal with high network dynamics due to node mobility, which makes ad hoc multicasting even more challenging. Ad hoc multicasting protocols in existing literature have either evolved from the Internet multicast protocol, or designed specifically for ad hoc networks. Most of these protocols attempt to adapt to the network dynamics in ad hoc networks. The primary goal of ad hoc multicasting protocols should be to construct/maintain a robust & efficient multicasting route even during high network dynamics. By “robust”, we mean that the protocol should be able to operate correctly in spite of node mobility and topology changes. By “efficient”, we mean both control and data forwarding overheads should be maintained low. This chapter is organized as follows. In Section 4.2, we outline a clas- sification methodology for multicasting protocols. The details of the specific protocols are described in Section 4.3. Broadcasting is discussed in Section 4.4. In Section 4.5, we provide a qualitative comparison of multicasting protocols. Overarching issues such as quality of service, energy conservation, reliability, 94 Multicasting in Ad Hoc Networks and security are addressed in Section 4.6, followed by the concluding remarks in Section 4.7. 4.2 Classifications of Protocols 4.2.1 Dealing with Group Dynamics General principles for dealing with dynamic membership in ad hoc mul- ticasting protocols are: on demand, receiver initiated, timer-based soft state. The basic idea of on demand approaches is to construct and maintain multicast routes only when needed. In receiver initiated approaches, it is the receiver’s responsibility to find and keep track of a multicast session. If some states must be maintained to make a multicast session work, it is desirable to use timer- based soft state instead of hard state. Soft states are maintained on demand and refreshed from time to time; otherwise, its associated timer expires and the state is removed from intermediate nodes. A primary issue for managing multicast group dynamics is the routing path that is built for data forwarding. Most existing ad hoc multicasting protocols can be classified as tree-based or mesh-based. In a tree-based protocol, a tree-like data forwarding path is built with the root at the source of the multicast session. The multicast tree consists of a unique path from the sender to a receiver. This can be extended to a shared-tree when multiple multicast sessions are in parallel in the network and can share some common parts of data forwarding trees with each other. In a mesh-based protocol, in contrast, multiple routes may exist between any pair of source and destination, which is intended to enrich the connectivity among group members for better resilience against topology changes. A major difference between tree-based and mesh-based protocols lies in the manner in which a multicast message is relayed. In a tree-based protocol, each intermediate node on the tree has a well-defined list of next hops for a specific multicast session. It will send a copy of the received message to only the neighboring nodes on its nexthop list. In most mesh-based protocols, however, relaying transmission takes a more redundant approach: each node on the mesh will broadcast the message upon its first reception of the message. Although this transmission redundancy may lead to higher overheads in many cases, it is still worth because of its resilience against dynamic topology and link quality. A compromise between the tree-based and mesh-based protocols is made in MCEDAR [2] builds a mesh structure among multicast members to obtain Multicasting techniques in MANETs can be classified based on group dy- namics or network dynamics. In this section, we describe these two basis of classifications. Details of the protocols will follow in the next section. Classifications of Protocols 95 redundant connectivity, and extract a data forwarding tree on top of the mesh structure. To the best of our knowledge, all the existing protocols for ad hoc multi- casting, both tree-based and mesh-based, do not make explicit efforts to take advantage of the broadcast nature of wireless medium. In an ad hoc network with a shared wireless channel, a link between any pair of nodes is not well defined as in the case of Internet. Instead, any two nodes within each other’s transmission ranges may form a link, and a node may form multiple links to its neighbors simultaneously. We believe this feature of broadcast media can help in reducing transmission overhead if we take it into consideration when constructing the multicast routes. 4.2.2 Dealing with Network Dynamics As mentioned earlier, we need to overcome the network dynamics in order to achieve robust and efficient ad hoc multicasting. A major source of network dynamics is node mobility and node failure. In this subsection we summarize some basic approaches to addressing this challenge in existing literature. We cite some examples for each of the approaches. Approach 1: Reliance on More Nodes Since nodes are mobile, every in- termediate node could be a possible cause of route breakage. If we include more nodes in the multicast infrastructure, we can obtain better connectivity among group members. When a link breaks due to node mobility, we may have a good chance to find an alternative route. In other words, we don’t need to initiate route maintenance procedure frequently corresponding to every single link failure. The second advantage of this approach is related to the transmission aspect: redundant transmissions can offset the influence of the unreliable wireless links. In many mesh-based protocols, within-mesh flooding is a common choice to improve reliability of data delivery. Some examples for this approach include CAMP’s forwarding group [3], ODMRP [4], and neighbor support multicasting [5]. Approach 2: Reliance on Fewer Nodes Since nodes are mobile, it is time- and resource-consuming for a large number of nodes to get involved in route construction and maintenance. By limiting the number of nodes involved, the control overhead can be reduced. We can extract a virtual backbone, typi- cally a dominating set of the entire network, and rely on the backbone while constructing multicast route when a new session starts. MCEDAR [2] uses this approach for ad hoc multicast. This approach is also used in unicast ad hoc routing [6] [7]. 96 Multicasting in Ad Hoc Networks Approach 3: Reliance on No Nodes Since all nodes are mobile, the multicast routes would need maintenance as time goes by. If session states are stored in packet headers, the protocol does not have to rely on any specific nodes to form a forwarding path because we do not even need one! Session states carried in packet header may be a list of node IDs, or a series of location coordinates. In a protocol using this approach, intermediate nodes check the packet header and decide where or who to forward the packet. Examples for this approaches include location guided small group commu- nication [8] and DDM [9]. Approach 4: Reliance on Stabler Nodes This approach attempts to take advantage of node mobility and network architecture. If nodes in a network have different degrees of mobility, for example, fast and slow, we can rely on the slow (thus stabler) nodes in order to build the multicast route. Note that “fast” and “slow” could be in the relative sense. For example, a group of nodes may move fast together toward a common direction, but the relative speed among group member is “slow”. An example of this approach is M-LANMAR [10], which is a multicast protocol exploiting team-based mobility. Approach 5: Reliance on an Overlay Layer Since all nodes are mobile, adapting to network dynamics is an extra burden for multicasting protocols. By inserting a middle layer in between, we can hide dynamics in lower layer and let multicast protocols concentrate only on multicasting. In this approach, the protocols normally build an overlay mesh on top of the physical network, and the multicasting route is built on top of this overlay mesh. Without knowing the underlying dynamics, it is easier for the multicast protocol to focus on implementing multicast functionalities. Protocols using this approach includes AMRoute [11] and PAST-DM [12], both of which construct a virtual mesh structure on top of the physical network. The virtual mesh relies on some unicast routing protocols to provide tunneling route between any two nodes on mesh. Data forwarding tree is extracted on top of the virtual mesh, and is unaware of underlying topology changes. Several popular multicasting protocols are classified according to our dis- cussion and are summarized in Table 4.1. 4.3 Multicasting Protocols In the previous sections, we reviewed the special properties of mobile ad hoc networks, and examined how these properties affect the design and imple- mentation of network protocols. To deliver packets effectively to the multicast group members, any multicasting protocol should address these properties. In Multicasting Protocols 97 this section, we present several multicasting protocols proposed specifically for the mobile ad hoc networks. 4.3.1 Multicast operations of AODV (MAODV) As the multicast protocol associated with AODV [13], MAODV [14] uses the conventional tree-based approach for multicast routing. Besides the routing table, each node maintains a Multicast Route Table (MRT) to support multicast routing. A node adds new entries into the MRT after it is included in the route for a multicast group. Each entry records the multicast group IP address, group leader IP address, group sequence number and next_hops (neighbors on the multicast tree). Each multicast group also needs its own sequence number in order to indicate the freshness of a multicast route, which is maintained by the group leader. When a node wishes to join a multicast group and it does not know who is the leader, it broadcasts a RREQ packet with destination field set as the group ID address. If it does not receive a RREP before timing out, it will retry for certain number of times. Subsequent unsuccessful attempts would mean that there are no other members of the group within its connected portion of the network. In such cases, it assumes the group leadership. It initializes the group sequence number to one, and broadcasts a Group Hello packet across the network periodically with step-wise incremented sequence number. Every node keeps record of who is the leader of which group by promis- cuously listening to RREPs. Thus, if it want to join a group, it may have the address of the leader. If it also has a route to the leader in its routing table, it can unicast the join RREQ to the leader directly. Otherwise, it will broadcast the join RREQ packet. If a member node loses its route to the group, it broadcasts a normal RREQ when it want to send data to the group. If a node receives a join RREQ, it can reply if it is a router on the group’s multicast tree and it holds a group sequence number that is high enough, while the group leader always can reply join RREQ. RREP is unicasted, and the 98 Multicasting in Ad Hoc Networks responding node updates its MRT accordingly. RREP contains the last known group sequence number, address of group leader, and a special field called Mgroup_Hop. This field is initialized to zero. When a node on the path to the source node receives the RREP, it increases its Mgroup_Hop field, and updates to its multicast route table. When the source node receives the RREP, it can determine the hop distance to the nearest router on the group’s tree, and a new branch of the tree is also built at the same time. Moreover, the whole multicast tree is gradually built up while branches are added one by one. When a node on the tree receives a packet targeting its group address, it will multicast the packet to all its neighbors on the tree. To ensure loop-free property, it is necessary to make sure only one router on the tree responds the join RREQ. If multiple responses do arrive, the source node should accept only one. All the other responses will be ignored and finally invalidated by expiration timers. Figure 4.2. Multicast join operation of MAODV. When a member decide to leave its group, and if it is not a leaf node in the multicast tree, it must continue to serve as a router. If it is a leaf node, it will have only one immediate neighbor. The node unicast a leave message to that neighbor and clears all information about the group in its tables. The neighbor, upon receiving the message will update its neighbor list as well. If it is not a member and it becomes a leaf node after the pruning, it will start its own pruning by doing the same. So the pruning stops when either a group member or a non-leaf node is reached. Multicast tree links may break due to node mobility or timer expiration, and this will be detected by both end nodes of the link. But only the downstream node will be responsible for the repair. To repair, it broadcasts a join RREQ with destination address set as group leader and Mgroup_Hop field set to its distance from the leader. The last known group sequence number is also included. To restrict the effects, the TTL field of the RREQ is set to a small value. If no reply is received before the time out period, the retrials will be network wide broadcasts. The nodes that can respond to this RREQ are those that are at least Multicasting Protocols 99 as close to the group leader as indicated by the packet. This prevents those nodes on the same side of the broken link from responding. Finally, when RREPs are unicasted to the initiating node, the procedure is the same as the joining of a new node. If no RREP is received, it is assumed that the network has been partitioned and the tree cannot be reconnected. The partition of the tree that is downstream of the broken link can select a new leader. It must be a group member, and the new leader will distribute new round of group sequence numbers to its members. Later on, the partitions of network may become connected. Then, the two leaders will know each other since they are both broadcasting group hello messages, and will negotiate and combine there partitions and one leader will stop its role. 4.3.2 Reliance on More Nodes Node mobility poses a great challenge to multicast routing. It is mandatory that a tree-based routing protocol should continuously update itself to accom- modate the changing network topology. When a tree link breaks, a branch of the multicast tree becomes disconnected. The routing protocol needs to reconnect the partitioned branches swiftly. In a highly mobile network, the robustness and efficiency would be an important issue. If we allow path redundancy in the routing structure, i.e., allow the presence of multiple paths between certain node pairs, we change the tree structure into a mesh structure. Thus, the routing structure does not need to react to every link breakage, which is a nice feature especially in the mobile ad hoc network settings. However, the path redundancy will reduce the data forwarding efficiency, and there could be loop formations. Thus, a mesh-based routing protocol needs a very careful design, 4.3.2.1 Core-Assisted Mesh Protocol (CAMP). CAMP [3] is designed to support multicast routing in very dynamic ad hoc networks using a shared mesh structure. It ensures that the shortest paths from all receivers to the sources (called reverse shortest paths) are included in the group’s mesh. Figure 4.3 illustrates how data packets are forwarded from router to the rest of the group members in CAMP and in a shared-tree multicast protocol. To prevent packet replication or looping in the mesh, each node maintains a cache to keep track of recently forwarded packets. Periodically, a receiver node reviews its packet cache in order to determine whether it is receiving data packets from those neighbors which are not on the reverse shortest path to the source. Whenever such situation arises, a heartbeat message is sent to successor in its reverse shortest path to the source. That heartbeat message triggers a push join message when the successor is not a mesh member. This procedure ensures all the nodes along any reverse shortest path are included in the mesh. 100 Multicasting in Ad Hoc Networks Figure 4.3. Traffic flow from h. (a) In a CAMP mesh. (b) In the equivalent shared tree. CAMP uses core node for limiting the control traffic needed for creation of multicast meshes. Unlike CBT, it does not require that all traffic should flow through the core nodes. If a node wishing to join a multicast group finds that it has neighbors which are duplex members of the group, it simply updates its multicast routing table (MRT) and announces its membership to the neighbors using a standard multicast routing update procedure. When none of its neigh- bors are mesh members, it either sends a join request toward a core or attempts to reach a group member by the expanding ring search. Any duplex member of the mesh can respond a join request with a join ACK, which is propagated back to the originator of the request. The normal mesh members are called duplex nodes. Besides, CAMP allows a node to join the mesh in a simplex mode when creating one-way connections between sender-only nodes and the rest of the multicast mesh. 4.3.2.2 On-Demand Multicast Routing Protocol (ODMRP). ODMRP [4] [15] extends the concept of mesh with the forwarding group concept. The forwarding group is a set of nodes responsible for forwarding multicast data on shortest paths between any member pairs, as is shown in Figure 4.4. Figure 4.4. The forwarding group concept. Multicasting Protocols 101 In ODMRP, group membership and multicast mesh are established and up- dated by each source on demand. By flooding a JOIN Query, a source node starts building a forwarding mesh for the multicast group, and collect mem- bership information at the same time. When a node receives a non-duplicate JOIN Query, it stores the upstream node ID and rebroadcasts the packet. When the JOIN REQUEST packet reaches a multicast receiver, the receiver creates or updates the source entry in its Member Table. A JOIN Reply packet is then prepared and broadcasted by the receiver node. The packet is relayed back towards the source along the reverse path traversed by the JOIN Query packet. This process constructs (or updates) the routes from sources to receivers and builds a mesh of nodes, the forwarding group. Multicast sources refresh the membership information and update the routes by sending JOIN Query period- ically. Figure 4.5. Format of JOIN Query packet. Figure 4.5 shows the format of a JOIN Query packet. When a multicast source has data packets to send but no route is known, it originates a “Join Query” packet. The source set Type field to 01 (which means a Join Query packet). Hop Count is initially set to zero. The TIME_TO_LIVE value for the packet should be adjusted based on network size and network diameter. The Sequence Number must be large enough to prevent wraparound ambiguity. When a node receives a Join Query packet, the following process is adopted. 1 2 3 Check if it is a duplicate by comparing the (Source IP Address, Sequence Number) combination with the entries in the message cache. If a dupli- cate, then discard the packet. DONE. If it is not a duplicate, insert an entry into the message cache with the information of the received packet (i.e., sequence number and source IP address) and insert/update the entry for routing table (i.e., backward learning). If the node is a member of the multicast group, it originates a Join Reply packet with the RET value enclosed. 102 Multicasting in Ad Hoc Networks 4 5 6 Increase the Hop Count field by 1 and decrease the TTL field by 1. If the TTL field value is less than or equal to 0, then discard the packet. DONE. If the TTL field value is greater than 0, then set the node’s IP Address into Last Hop IP Address field and broadcast. DONE. Figure 4.6. Format of JOIN Reply packet. A multicast receiver transmits a “Join Reply” packet after selecting the mul- ticast route. Each sender IP address and next hop IP address of a multicast group are contained in the Join Reply packet. Figure 4.6 shows the format of a JOIN Reply packet. When a Join Reply is received: 1 2 3 The node looks up the Next Hop IP Address field of the received Join Reply entries. If no entries match the node’s IP Address, do nothing. DONE. If one or more entries coincide with the node’s IP Address, set the FG_FLAG and build its own Join Reply. The next hop IP address can be obtained from the routing table. Broadcast the Join Reply packet to the neighbor nodes. DONE. One salient feature of ODMRP is the soft state approach in maintaining mul- ticast group members. For each member, the group membership is periodically renewed by the rounds of request/reply procedure. Once a member wants to leave a group, no additional signaling is needed. It simply just stops respond- ing to the Join Query packets. This feature is very suitable for the mobile ad [...]... Simplot, and I Stojmenovic Localized minimum-energy broadcasting in ad- hoc networks In Proc of IEEE InfoCom 2003 [31] E Pagani and G P Rossi Providing reliable and fault tolerant broadcast delivery in mobile ad- hoc networks Mobile Networks and Applications, vol 4, pp 1 75- 192, 1999 [32] C.S Hsu and Y.C Tseng An efficient reliable broadcasting protocol for ad hoc networks IASTED Networks, Parallel and Distributed... mobile ad hoc networks In Proc of ACM Mobihoc ’02, pp 194-2 05, 2002 [ 25] J Wu and F Dai Broadcasting in ad Hoc networks based on self-pruning Proc of the 22nd Annual Joint Conf of IEEE Communication and Computer Society (INFOCOM), March 2003 [26] S J Lee, W Su, J Hsu, M Gerla, and R Bagrodia A performance comparison study of ad hoc wireless multicast protocols In Proc of IEEE INFOCOM 2000: 56 5 -57 4 [27]... 2003 [13] C E Perkins and E M Royer Ad hoc On-Demand Distance Vector Routing Ad Hoc Networking, edited by C E Perkins, Addison-Wesley, 2001 [14] E M Royer and C E Perkins Multicast operation of the ad hoc on demand distance vector routing protocol In Proc of ACM MOBICOM, Aug 1999, pp 207–18 [ 15] S.-J Lee, W Su, and M Gerla On-demand multicast routing protocol (ODMRP) for ad hoc networks Internet-Draft,... Kim Neighbor support ad hoc multicast routing protocol In Proc the First Annual Workshop on Mobile and Ad hoc Networking and Computing, 2000, pp 37-44 120 Multicasting in Ad Hoc Networks [6] B Das, R Sivakumar, and V Bharghavan Routing in ad hoc networks using a virtual backbone In Proc IEEE IC3N, 1997 [7] J Wu, and H Li A dominating set based routing scheme in ad hoc wireless networks Proc of the... Gerla, and K Obraczka Scalable team multicast in wireless ad hoc networks exploiting coordinated motion To appear in the Elsevier Ad Hoc Networks Journal [11] J Xie, R Talpade, T McAuley, and M Liu AMRoute: Ad hoc multicast routing Protocol ACM Mobile Networks and Applications (MONET) Journal, 7(6): 429-439, Dec 2002 [12] C Gui, and P Mohapatra Efficient overlay multicast for mobile ad hoc networks. .. is in its data buffer 4.4 Broadcasting Network wide broadcasting is an important function in MANETs, which attempts to deliver packets from a source node to all other nodes in the network Broadcasting is often used as a building block for route discovery in on-demand ad hoc routing protocols 110 Multicasting in Ad Hoc Networks For designing broadcast protocols for ad hoc networks, one of the primary... C Gui and P Mohapatra Scalable multicasting in mobile ad hoc networks IEEE Infocom 2004, Hong Kong, China, March 2004 [28] Y Yi, M Gerla, and T J Kwon Efficient flooding in ad hoc networks using on-demand (passive) cluster formation In Proc of ACM MobiHoc 2002 [29] J E Wieselthier, G D Nguyen, and A Ephremides On the construction of energy-efficient broadcast and multicast trees in wireless networks. .. (ICDCS), pages 2 75 283, 2001 [22] J Luo, P.Th Eugster, and J.-P Hubaux Route driven gossip: Probabilistic reliable multicast in ad hoc networks In Proc of INFOCOM’03, 2003 [23] D.B Johnson, D.A Maltz, and J Broch DSR: The Dynamic Source Routing Protocol for Multi-Hop Wireless Ad Hoc Networks Ad Hoc Networking, edited by C E Perkins, Addison-Wesley, 2001 [24] B Williams and T Camp Comparison of broadcasting... of additional coverage area (shadowed in the figure), decides whether to rebroadcast the packet Note that the additional coverage area of node B is a function of transmission radius R and nodal distance d When d = R, the maximum additional coverage area is reached, which is about A general framework on self-pruning-based broadcast redundancy reduction techniques in ad hoc networks was proposed in [ 25] ... wireline networks The wireless broadcast media is more prone to both passive and active attacks The MAC layer solutions to group key management and source authentication proposed for wireline networks need to be modified/enhanced to be able to adopted to wireless environment Compared to other wireless communications such as cellular networks, ad hoc networks require even more sophisticated, efficient, and . or designed specifically for ad hoc networks. Most of these protocols attempt to adapt to the network dynamics in ad hoc networks. The primary goal of ad hoc multicasting protocols should be to construct/maintain. route discovery in on-demand ad hoc routing protocols. For designing broadcast protocols for ad hoc networks, one of the primary goal is to reduce the overhead (collision and retransmission, redundant. the existing protocols for ad hoc multi- casting, both tree-based and mesh-based, do not make explicit efforts to take advantage of the broadcast nature of wireless medium. In an ad hoc network with