There are more and more applications where one-to-many or many-to-many dissemination is an essential task. The multicast service is critical in applications characterized by the close collaboration of teams (e.g. rescue patrol, battalion, scientists, etc) with requirements for audio and video conferencing and sharing of text and images. In the Internet (IPv4), multicasting facilities were introduced via the Multicast Backbone (MBone), a virtual overlay network on top of the Internet. This overlay network consists of multicast-capable islands connected by tunnels. Each island contains one or more special routers called multicast routers, which are logically connected by these tunnels. These routers manage group membership and cooperate to route data to all hosts wishing to participate in a multicast group. IP multicast groups are identified by special IP addresses. Support for multicasting is an integral component of IPv6, so it can be assumed that multicasting applications will become even more popular with the increased popularity and acceptance of IPv6.
Typically, the membership of a host group is dynamic; that is, hosts may join and leave groups any time. There is no restriction on the location or number of members in a host group. A host may be a member of more than one group at a time. A host does not have to be a member of a group to send packets to it. A host group may be permanent or transient. A permanent group has a well-known, administratively assigned address. It is the address, not the membership of the group that is permanent; at any time a permanent group may have any number of members, even zero. Those IP multicast addresses that are not reserved for permanent groups are available for dynamic assignment to transient groups which exist only as long as they have members.
Maintaining group membership information and building an optimal multicast distribution structure (typically in the form of a routing tree) is challenging even in wired networks. However, nodes are increasingly mobile. One particularly challenging environment for multicast is a mobile ad-hoc network (MANET). A MANET consists of a dynamic collection of nodes with sometimes rapidly changing multi-hop topologies that are composed of relatively low-bandwidth wireless links. There is no assumption of an underlying fixed infrastructure. Nodes are free to move arbitrarily. Since each node has a limited transmission range, not all messages may reach all the intended hosts. To provide communication through the whole network, a source-to-destination path could pass through several intermediate neighbour nodes. Unlike typical wireline routing protocols, ad-hoc routing protocols must address a diverse range of issues. The network topology can change randomly and rapidly, at unpredictable times. Since wireless links generally have lower capacity, congestion is typically the norm rather than the exception. The majority of nodes will rely on batteries, thus routing protocols must limit the amount of control information that is passed between nodes. Also, multicast group members and other nodes move, thus precluding the use of a fixed multicast topology.
The goal of MANETs is to extend mobility into the realm of autonomous, mobile, wireless domains, where a set of nodes form the network routing infrastructure in an ad-hoc fashion. The majority of applications for the MANET technology are in areas where rapid deployment and dynamic reconfiguration are necessary and the wireline network is not available. These include military battlefields, emergency search and rescue sites, classrooms, and conventions where participants share information dynamically using their mobile devices. These applications lend themselves well to multicast operation. In addition, within a wireless medium, it is even more crucial to reduce the transmission overhead and power consumption. Multicasting can improve the efficiency of the wireless link when sending multiple copies of messages by exploiting the inherent broadcast property of wireless transmission. While many applications, such as audio/video distribution, can tolerate loss of data content, many other applications cannot. In addition, even loss-tolerant applications will suffer a performance penalty: an audio stream may experience a short gap or lower fidelity in the presence of loss.
In our work to date, we conducted an in-depth study of one-to-many and many-to-many communication in mobile ad-hoc networks. The original goal of this work was to design an efficient protocol that delivers packets from one or multiple senders to many receptions with high probability. We started this effort by exploring the performance of a number of best-effort protocols: 2 unicast routing protocols, 3 multicast routing protocols, and 2 broadcast protocols. Extensive simulation results show that broadcast protocols perform surprisingly well, and that this performance does not come with a high overhead. So we decided to use the more efficient broadcast protocol, BCAST, as starting point for the next step. We enhanced BCAST with a NACK-based retransmission scheme to further increase the packet delivery ratio. The simulation results demonstrate that this mechanism indeed increases the packet delivery ratio. The experiments also show that a high degree of mobility is actually advantageous: as network partitions are potentially short-lived, our retransmission scheme is more likely to successfully recover from packet losses during such partitions. In contrast, in networks with longer-lived partitions, the amount of packets buffered at nodes needs to be increased substantially to recover in these cases. Finally, the results show that implementing any reliability mechanism has to be done with care. As the network capacity is limited, flooding the network with NACKs and the ensuing packet re-transmission attempts will have a detrimental impact on the protocol performance when the network is experiencing congestion. In the reliable BCAST protocol, we therefore have each node monitor the local network traffic and suppress NACKs when it observed too much traffic in the recent past.
Next, we explored the impact of the MAC layer on the performance of both best-effort BCAST and reliable BCAST. Varying the user traffic load and the MAC layer, we derived a number of insights into the relationship between MAC and ROUTING layer. In particular, we noted that BCAST suffers as the number of MAC-level packet collisions increases. Therefore, approaches to reduce such collisions have the potential to increase the performance of BCAST substantially. The results also indicate that our NACK-based packet retransmission scheme increases packet delivery ratio in only a limited number of scenarios. If the user traffic, relative to the MAC layer data rate, is low, best-effort BCAST performs already extremely well. If, on the other hand, the network starts to experience congestion due to high user traffic, we have to throttle NACKs to prevent them from negatively impacting the protocol performance, so again there is little difference between the best-effort and reliable protocol versions. As the results also demonstrate, the NACK throttle has to be tuned carefully for the MAC layer, otherwise the resulting performance suffers.
In conclusion, BCAST is a protocol that achieves high packet delivery, at the cost of an increase in packet latency. We have shown that the protocol performs well in a wide range of scenarios and over a number of MAC layers (all of which were variants of the 802.11 protocol family). Increasing packet delivery through a retransmission scheme is, however, only of limited value. As MAC rates increase for current and future networks, MANETs will be able to support a non-trivial amount of traffic per multicast sender. Achieving high packet delivery ratios in these networks can be achieved by adjusting the data volume through flow control to operate in the protocol "sweet spot", using the best-effort protocol as basic protocol.
In future work, we will implement BCAST using the XORP/CLICK routing platform in Linux laptops and Compaq iPaqs. The implementation will also allow us to compare the protocol performance on a real system with the results predicted by simulation, which may serve to validate or critically examine the suitability of simulation for protocol work.