Related Works

(3.8)

On the other hand, if routers use unicast mode to transmit multicast packets, the number of forwarding events is the number of edges on the tree, which is equivalent to the number of nodes on the tree (interior nodes plus leaf nodes) minus one.

(3.9)

Therefore, the forwarding difference of these two modes is the number of leaf nodes minus one.

3.5.4 Related Works

To efficiently support multicast transmission, a few multicast MAC protocols [53], [54], [55], [56] have been proposed to extend the IEEE 802.11 broadcast/multicast protocol with RTS/CTS handshaking. In [53], once a sender gains access to the medium, it transmits an RTS packet to its neighbors and waits for CTS packet for WAIT FOR CTS time units. If a node receives an RTS packet when it is not in the YIELD phase, it sends back a CTS and then waits for the data packet for WAIT FOR DATA time units. If the sender does not receive any CTS packet be-fore its WAIT FOR CTS timer expires, it backs off and enters the contention phase again to retransmit the broadcast/multicast data packet. If the sender receives any CTS packet before its WAIT FOR CTS timer expires, it transmits the data packet and waits for WAIT FOR NAK time units for any possible transmission prob-lem reported by the neighboring nodes. If a receiver does not receive the data packet after it has transmitted the CTS packet for WAIT FOR DATA time units, it transmits NAK packet. If the sender does not receive any NAK packet before its WAIT FOR NAK timer expires, the broadcast/multicast service is complete. Oth-erwise, the sender backs off and enters the contention phase again to retransmit

the data packet. Broadcast Medium Window (BMW) [54] mainly considers sup-porting reliability for broadcast but it can also support multicast. The basic idea of BMW is that a node reliably transmits a broadcast packet to each of its neighbors in a round robin fashion. The neighbor list is obtained by both periodical HELLO messages and overhearing. Once a packet other than HELLO message is transmit-ted by a node, the node will suppress its next HELLO message, assuming neighbor nodes can know its presence by overhearing this packet. The main drawback of the BMW is that it uses at least rounds of unicasts for a broadcast/multicast packet addressed to its neighbors, which does not only introduce at least rounds of contention phases, but also makes no use of the broadcast nature of the wireless channel. This protocol is very similar to our unicast forwarding mechanism except that it operates at the MAC layer while ours is located in Network layer.

Considering the problem of BMW, Batch Mode Multicast MAC protocol (BMMM) [55] proposes to consolidate the contention phases into a single one and trans-mits the data packet only one time before the ACK collecting. To reliably transmit a multicast packet in BMMM, a sender first uses its RTS packets to request in-tended receivers one by one to reply with a CTS. If the sender receives at least one CTS, it transmits the data packet. After the data packet transmission, it uses a new control packet called RAK (Request for ACK) to request ACKs from the intended receivers one by one. In case of missing ACKs, the sender will do retransmission.

All the intervals between the above sequence of packets are set to a value less than DIFS, so once the sender grabs the channel, the reliable multicast operation will not be interrupted by other transmissions. It introduces rounds of RTS/CTS exchange and RAK/ACK exchange, in which any of the packets missing will cause retransmission.

BMMM uses less medium than the unicast transmission mode of our adap-tive forwarding mechanism. However, it obtains a certain reliability at the cost of bandwidth consumption and bigger transmission delays. This protocol uses extra bandwidth for channel reservation and transmission acknowledgment compared to the plain CSMA/CA mechanism defined in the IEEE 802.11 specification. Further-more, if these protocols operate alone, they might provide unnecessary reliability in some cases. For example, in Figure 3.2, node E is a multicast receiver for both node B and C at the MAC layer point of view . Thus nodes B and C could reliably send multicast packets to node E since reliable transmission from one node is enough.

However, if BMMM cooperates with MRDC by replacing the unicast transmission mode, we can achieve a much better multicasting performance. Suppose that the MRDC constructs a multicast tree to connect source and receivers in Figure 3.2 and that node E is node B’s downstream node on the tree. Node B can explicitly inform the MAC layer that receivers are node E and D. Node C does not need to reliably reach node E but node E is always able to receive multicast packet from node C. In this way, we can reduce bandwidth consumption and obtain redundant transmissions at the same time.

3.6 Conclusion

In this chapter, we introduced a best effort multicast routing protocol, called the Multicast Routing protocol with Dynamic Core (MRDC) for mobile ad hoc net-works. The aim of this work is to reach a compromise between forwarding over-head and routing overover-head so we can minimize the total bandwidth consumption.

Because traffic packets are generally much more numerous and bigger than con-trol messages, our strategy chooses the techniques which are most efficient for data transmissions while usually creates heavier control overheads. We developed some techniques which significantly reducing the control overhead with the cost of loos-ing some data transmission efficiency to obtain an optimal bandwidth utilization.

Finally the routing protocol uses the best effort approach to deliver packets.

According to this idea, MRDC is split into two planes: the control plane and the forwarding plane. The control plane chooses tree structure to achieve the best data transmission efficiency. As nodes move and the network configuration changes, the tree is periodically reconfigured to maintain efficiency. A multicast tree is rooted at the first source of a multicast session. Therefore, since the tree is source-based, MRDC achieves the best data transmission efficiency for in a single source mul-ticast session. In multiple source applications the tree becomes group-shared to reduce control overhead. Another improvement to reduce the control overhead is that the construction and maintenance of any multicast tree are triggered in an on-traffic-demand basis at the cost of introducing transmission delays for the first packets. Faults are tolerated in the trees, which might affect packet delivery on the concerned sub-tree but can avoid heavy control overheads to maintain a strictly cor-rect tree. MRDC only needs a small quantity of control overhead but can provide a delivery structure which generates less forwarding overhead, therefore reducing the total bandwidth consumption.

The forwarding plane is in charge of delivering multicast packets on a best ef-fort basis. Considering the shortcoming of the current 802.11 standards in multicast packet transmission, we introduced an adaptive multicast forwarding mechanism in MRDC’s forwarding plane for 802.11 wireless networks. This mechanism makes a transmission mode choice based on two metrics: Average Queue Length (AQL) and Medium Occupation for Reception (MOR). If both metrics are smaller than their respective thresholds, the forwarding mechanism treats a multicast packet as a set of unicast packets and delivers them with the RTS/CTS option of IEEE 802.11.

If it is not the case, the forwarding mechanism passes a multicast packet directly to the MAC layer. Through this mechanism, MRDC provides some degree of reli-ability in one hop multicast delivery. Thus, we can offer a better service for upper layer applications. If they are sensitive to delay or benefit from some other mech-anisms to recover delivery failures, MRDC can always use the broadcast mode to achieve short delays and low bandwidth consumption. For the other applications, MRDC is able to offer an optimal packet delivery ratio with respect to the network load. That is what we call best-effort multicasting.

We estimated the routing overhead and forwarding overhead of MRDC. This

overhead is a function of the multicast tree size which is further decided by the distribution of group members in the network and their distance to the core. In the next chapter, we will study the performance of MRDC in a packet level simulator.

After selecting the suitable key metrics for MRDC such as the period of tree refresh (PERIOD REF) and the thresholds of mode selection procedure, we evaluate the size of MRDC multicast tree and discuss the efficiency and robustness of MRDC under different movement and traffic scenarios. We then compare its performance to other multicast routing protocols.

Chapter 4