Multicast Routing Protocols in Mobile Ad Hoc Networks: A Comparative Survey and Taxonomy <s> MAC Layer Multicast in Wireless Multihop Networks <s> In IEEE 802.11 based mobile ad hoc networks (MANET) multicast packets are generally forwarded as one hop broadcast; mainly to reach all the multicast members in the neighborhood in a single transmission. Because of the broadcast property of the forwarding, packets suffer from increased instances of the hidden terminal problem. Mobility of nodes makes things more difficult, and unlike unicast transmissions where MAC can detect the movement of a nexthop by making several retries, it is not possible in case of multicast forwarding. To address these issues, we propose a multicast aware MAC protocol (MMP) for MANET. The basic objective of MMP is to provide a MAC layer support for multicast traffic. This is done by attaching an extended multicast header (EMH) by the multicast agent, which provides the address of the nexthop nodes that are supposed to receive the multicast packet. The MAC layer in MMP uses the EMH field to support an ACK based data delivery. After sending the data packet, the transmitter waits for the ACK from each of its destinations in a strictly sequential order. A retransmission of the multicast packet is performed only if the ACK from any of the nodes in EMH is missing. We compare MMP with IEEE 802.11 and results show that MMP substantially improves the performance of multicast packet delivery in MANET without creating much MAC overhead. In addition, MMP provides a better mechanism to detect the movement of its nexthop members. <s> BIB001 </s> Multicast Routing Protocols in Mobile Ad Hoc Networks: A Comparative Survey and Taxonomy <s> MAC Layer Multicast in Wireless Multihop Networks <s> Many applications in wireless ad-hoc networks require multicast communication. In order to provide efficient multicast, various multicast routing protocols have been designed in recent years to facilitate formation of routes between multicast senders and receivers. There has also been some work to develop a suitable MAC protocol to improve efficiency of multicast communication. In this work we explore some approaches for reliable multicast at the MAC layer. We develop a multicast extension of IEEE 802.11 protocol and evaluate its performance. We have implemented our protocol in the popular ns-2 simulator and have performed experiments with multicast routing protocol.1. Our approach demonstrates superior performance in terms of packet deliveryfraction as well as delay compared to the IEEE 802.11 protocol. <s> BIB002
Protocol Description. In BIB002 , a MAC protocol which can improve the efficiency of multicast communication is suggested. These authors have developed MAC layer multicast as an extension to the IEEE 802.11 DCF protocol, which can be used with any multicast routing protocol, and introduced several modifications to it to implement their protocol. They modified the control packets (RTS, CTS, and ACK) and data packets. The RTS frame is modified (extended RTS, RTSExt) to include at most four multicast next hop neighbor addresses, a design choice which keeps the RTS frame size within bounds. The CTS frame is modified (extended CTS, CTSExt) to include the order of the receiver (the node that sends the CTS in this case), as determined from the RTS frame, which helps the original sender to differentiate among multiple CTS. The ACK frames are modified (extended ACK, ACKExt) to include the receiver's order determined from the position index (the sending nodes set an integer number in the RTSExt frame, to differentiate among multiple CTSExt, and in the DATA frame, to differentiate among multiple ACKExt) of its address in the received DATA frame. Finally, the DATA packet header is modified (DATAExt) to include the addresses of all those nodes from which CTS was successfully received. Neighbors are grouped into different cliques and multicast data are sent to at most 4 neighbors at a time. Only those nodes that are part of the multicast route and whose addresses are included in the RTSExt must prepare to respond with CTSExt frames. If all the CTSExt frames are sent simultaneously, they may not be correctly received, and so CTSExt are sent one after another by deliberately introducing a fixed amount of delay between successive transmissions. Discussion. Compared with MMP BIB001 , this protocol has a small RTS size, and so is not prone to collisions. The RTS/CTS/Data/ACK exchange is completed before the NAV of two hop neighbors and potential interferers expire. However, considerable overhead is introduced to transmit a single data packet. In addition, delays may be introduced when paths contain a large number of hops, since each node should wait for some time (calculated as described in BIB002 ) before sending CTSExt and ACKExt. Also, a clustering algorithm is needed when there are more than four next hop nodes in the multicast route.