A Survey of QoS Multicast in Ad Hoc Networks

Abstract

This survey on Quality of Service (QoS) in multicast ad hoc networks uses a framework based on the mechanisms in three important elements: resource estimations, multicast tree/mesh administration, and multicast routing. Our contribution is an exploration of the design space and an identification of areas that have not been fully explored. We discuss the design space of central mechanisms and classify proposed QoS multicast schemes according to the mechanisms they used. In addition, we summarize the scenarios used for evaluating their performance. Furthermore, we identify issues, mechanisms, and scenarios that have not been fully investigated in existing works. The paper provides a coherent understanding of design principles, conceptual operation, and evaluated scenarios of schemes designed for QoS multicast application in mobile ad hoc networks (MANETs). It also outlines new areas for future research in this field.

1. Introduction

Ad hoc networks are self-configuring networks of mobile devices connected by wireless links. The devices are free to move and organize themselves in an arbitrary fashion. Ad hoc networks are suitable for situations where an infrastructure is unavailable or ineffective to deploy. Examples are emergency operations, disaster relief operations, temporary networks, transient vehicle-to-vehicle communication and tactical military networks. In most of these settings multipoint-to-multipoint multimedia communication is a requirement. Multicast is an efficient method to implement multipoint-to-multipoint communication. Multimedia content also requires networks with predictable service or Quality of Service (QoS).

As Internet is making the transition to a ubiquitous network, available anytime and anywhere, more and more of the communication will be over wireless technologies. As already mentioned, not all this can be handled in the context of single hop as in cellular or wireless access. Future Internet will therefore to a larger extent than today also incorporate ad hoc networks. More important, the functionality and the protocols of the future internet must seamlessly handle the challenges of multihop wireless communication.

Our intention is to describe the design space of the protocols for QoS enabled multicast. In addition, we summarize the simulation scenarios used to evaluate these protocols. The end result of the survey is an identification of possible areas and scenarios that could benefit from a more in-depth investigation.

There are several surveys and reviews on the separate topics of QoS and multicast in ad hoc networks. Symeon et al. [6], in a paper from 2002, summarized issues and challenges for supporting multicast in ad hoc networks. They classified the multicast protocols as proactive and reactive, tree and non-tree approaches and summarized some of the more typical protocols. The survey is a few years old and does not include QoS multicast in ad hoc networks. In [5], Aaron et al. presented a multicast “life cycle” model for fixed networks. They considered three important events happening during a life cycle, namely group dynamics, network dynamics, and traffic dynamics. They also examined some issues and solutions for managing group dynamics and handling failure in QoS multicasting. Dmitri et al. [3] in 2002 and T. Bheemarjuna et al. [4] in 2006 both described the issues and challenges in providing QoS for ad hoc networks. They identified a set of required components for all QoS solutions: (1) a QoS routing protocol, (2) a resource reservation scheme, and (3) a QoS capable medium access control (MAC) layer. Lajos et al. [7] surveyed various QoS routing solutions for MANETs published in the period 1997–2006. They focused on QoS routing metrics, resources, and factors affecting performance. The protocols were grouped based on their interaction with MAC protocol. Luo et al. [1] surveyed multicast routing protocols and classified them into two categories, application independent multicast routing and multicast routing aimed for specific application requirements. The latter group was divided into subcategories based on requirements for QoS, energy efficiency, network coding, and reliable transfer.

However, these surveys only cover some of the subtopics of QoS multicast in ad hoc networks. To our knowledge, there are only two reviews covering the full topic [2,10]. Aisha et al. [2] reviewed nine protocols and presented a short description, advantages, and disadvantages of these protocols. Masoudifar [10] reviewed seven QoS multicast routing protocols. The focus was on QoS routing protocols. They were classified based on their dependency on other protocols, whether they could function as a sublayer, as an enhancement of existing protocols, or whether they were completely independent. Both surveys only include a limited subset of the protocols we have analyzed. Their focus is also only on some of the elements we are targeting. Our contribution is an in depth analysis of the design space for more than 30 QoS multicast protocols in ad hoc networks. The end result is an identification of possible mechanisms and scenarios that could benefit from a more detailed investigation.

The remainder of the paper is organized as follows. In the remainder of Section 1 we introduce the challenges and the functionalities required for providing QoS multicast. Section 2 classifies the various protocols based on the mechanisms used to implement the functionalities. In Section 3 we focus on the actual scenario used to evaluate the performance of the various proposed schemes. The limitations of existing scenarios are also described. Most of the existing scenarios are quite limited with the small number of groups and sources. In the conclusion part, Section 4, we identify design mechanisms and usage scenarios that have only been investigated to a limited degree. The 31 protocols surveyed in the paper are listed in Table 1.

Table 1. Description of protocol names.

No.	Protocol	Full Name
1	QAMNet [11]	Quality of service for Multicast in MANETs
2	CQMRP [12]	Cluster-based QoS Multicast Routing Protocol
3	QMRPCAH [13]	QoS Multicast Routing Protocol for Clustering Mobile Ad Hoc Network
4	HVDB [14]	Hypercube-based Virtual Dynamic Backbone
5	QoS-ODMRP [15]	QoS On-Demand Multicast Routing Protocol
6	E-QMR [16]	Cross-layer QoS Multicast Routing Protocol (This protocol is an extenson of protocol QMR[44])
7	Hu* [17]	This protocol was not named by the authors. The first author’s name is used instead
8	QMRP [18]	QoS aware Multicast Routing Protocol
9	QoS-AODV [19]	QoS Ad Hoc On-Demand Distance Vector Routing
10	HQMRP [21]	Hybrid QoS Multicast Routing Protocol
11	QoS-MEM [22]	QoS-aware Minimum Energy Multicast
12	LTM* [23]	Lantern-Tree-based QoS Multicast (This protocol was not named by the authors. We call it LTM)
13	MPT* [24]	Multiple paths/trees (This protocol was not named by the authors. We call it MPT)
14	EQMGA [25]	Entropy-based Genetic Algorithm to support QoS Multicast Routing
15	QMOST [26]	QoS-aware Multicast Overlay Spanning Tree
16	LACMQR [28]	Location-based multicast routing for mobile ad hoc networks
17	AQM [29,45]	Ad Hoc QoS Multicasting
18	M-CAMP [30]	Call-Admission Multicast Protocol for MANETs
19	MCEDAR [31]	Multicast Core-Extraction Distributed Ad Hoc Routing
20	QoS-MAODV [32]	QoS–Multicast Ad Hoc On-Demand Distance Vector Routing
21	HQMGA [33]	Hierarchical QoS Multicast routing using GA in MANET
22	QMR [44]	QoS Multicast Routing Protocol
23	EGA [35]	A Genetic Algorithm for Energy-Efficient Based Multicast Routing on MANETs
24	SEQMRAN [36]	Secure Efficient QoS Multicast Route Discovery for MANETs
25	FQM [37]	Framework for QoS Multicast
26	ODQMM [38]	On-Demand QoS Multicast for MANETs
27	MACO [41]	Ant Colony Algorithm Based on Orientation Factor for QoS Multicast
28	AMOMQ [42]	Ad-hoc Mesh-based On-demand Multicast Routing Protocol with Quality of Service Support
29	QoS-MAODV-2Lqos [43]	QoS Constrained Multicast Routing For Mobile Ad Hoc Networks
30	HTQ* [50]	Hexagonal-tree TDMA-based QoS multicast protocol (This protocol was not named by the authors. We call it HTQ)
31	QMMRP [51]	QoS Multilayered Multicast Routing Protocol

Table 1. Description of protocol names.

No.	Protocol	Full Name
1	QAMNet [11]	Quality of service for Multicast in MANETs
2	CQMRP [12]	Cluster-based QoS Multicast Routing Protocol
3	QMRPCAH [13]	QoS Multicast Routing Protocol for Clustering Mobile Ad Hoc Network
4	HVDB [14]	Hypercube-based Virtual Dynamic Backbone
5	QoS-ODMRP [15]	QoS On-Demand Multicast Routing Protocol
6	E-QMR [16]	Cross-layer QoS Multicast Routing Protocol (This protocol is an extenson of protocol QMR[44])
7	Hu* [17]	This protocol was not named by the authors. The first author’s name is used instead
8	QMRP [18]	QoS aware Multicast Routing Protocol
9	QoS-AODV [19]	QoS Ad Hoc On-Demand Distance Vector Routing
10	HQMRP [21]	Hybrid QoS Multicast Routing Protocol
11	QoS-MEM [22]	QoS-aware Minimum Energy Multicast
12	LTM* [23]	Lantern-Tree-based QoS Multicast (This protocol was not named by the authors. We call it LTM)
13	MPT* [24]	Multiple paths/trees (This protocol was not named by the authors. We call it MPT)
14	EQMGA [25]	Entropy-based Genetic Algorithm to support QoS Multicast Routing
15	QMOST [26]	QoS-aware Multicast Overlay Spanning Tree
16	LACMQR [28]	Location-based multicast routing for mobile ad hoc networks
17	AQM [29,45]	Ad Hoc QoS Multicasting
18	M-CAMP [30]	Call-Admission Multicast Protocol for MANETs
19	MCEDAR [31]	Multicast Core-Extraction Distributed Ad Hoc Routing
20	QoS-MAODV [32]	QoS–Multicast Ad Hoc On-Demand Distance Vector Routing
21	HQMGA [33]	Hierarchical QoS Multicast routing using GA in MANET
22	QMR [44]	QoS Multicast Routing Protocol
23	EGA [35]	A Genetic Algorithm for Energy-Efficient Based Multicast Routing on MANETs
24	SEQMRAN [36]	Secure Efficient QoS Multicast Route Discovery for MANETs
25	FQM [37]	Framework for QoS Multicast
26	ODQMM [38]	On-Demand QoS Multicast for MANETs
27	MACO [41]	Ant Colony Algorithm Based on Orientation Factor for QoS Multicast
28	AMOMQ [42]	Ad-hoc Mesh-based On-demand Multicast Routing Protocol with Quality of Service Support
29	QoS-MAODV-2Lqos [43]	QoS Constrained Multicast Routing For Mobile Ad Hoc Networks
30	HTQ* [50]	Hexagonal-tree TDMA-based QoS multicast protocol (This protocol was not named by the authors. We call it HTQ)
31	QMMRP [51]	QoS Multilayered Multicast Routing Protocol

1.1. Design Space for QoS Multicast

QoS multicast in ad hoc networks represents specializations of regular data communication. All of these specializations require specific elements in order to address the added requirements. Our main focus is on the QoS aspects, and therefore the elements that are needed to provide QoS in multicast ad hoc environments.

Providing QoS in ad hoc networks has additional challenges due to the wireless medium and the mobility of nodes. The wireless medium itself induces errors and packets are lost as part of the normal operating context. Often the MAC layer offers a shared common channel for nodes in the vicinity of each other. In addition, the interference range of a transmission may be larger than the transmission range. The available resources and the probability of a successful transmission therefore may depend on the details of the topology and the traffic load at neighboring nodes.

1.2. Context

Traditionally, multicast distributions have been classified in terms of structure, either tree or mesh. They were also classified according to how the sources in a multicast group share the multicast distribution; whether it is one per source (source specific) or a common one for all sources (shared tree or mesh). A tree versus a mesh is a tradeoff between availability, robustness, and resources consumed. Redundant paths in mesh structure result in higher availability and more robustness. An inherent advantage of shared structures is that no separate mechanism is needed for source discovery. As long as receivers are connected to the common structure, they will receive packets from all sources. With a source specific distribution mechanism, receivers must have some method of discovering the sources within a multicast group. In principle, a directory based solution is possible, ad hoc networks will typically use broadcasting for source announcement. Source specific tree/mesh has the potential for being more efficient (fewer hops between a source and the receivers).

The type of distribution mechanisms affects how resource reservation and admission control is handled. In a shared tree/mesh, without QoS, a new source needs only to find the shortest path to the shared tree. However, in a QoS setting, a source must try to be admitted by all relaying nodes in a shared structure. Shared structures also allow different styles of resource reservation. The reservation can be per source or be shared. The latter is typically exemplified by voice conferences in which participants seldom talk simultaneously. They can therefore share the same reservation, and in this situation a reservation per participant would be a waste of resources. This concept is formalized in the resource usage filter defined in Resource ReSerVation Protocol (RSVP) [55]. Most protocols based on a shared tree use shared reservation style [29,32,43]. Only the protocol ODQMM [38] utilizes both types of reservations, shared and source specific reservation.

1.3. Necessary Elements for QoS Multicast

The functionality of the various protocols can be isolated to a few common elements, namely QoS routing, call admission, resource estimation, resource reservation, and preemption. We will explain in detail these elements in Section 2. Although, the survey describes them sequentially, these elements cannot be organized into a fixed sequence. Different protocols will order them differently or combine several of them into one operation. For example, many of the protocols based on reactive multicast routing combine QoS routing, resource reservation, and call admission.

All the schemes need to identify potential segments of a distribution tree that may have resources or capabilities sufficient to meet the requirements (QoS routing). The segments will be used to search for the best path that can admit the session or admit the combination of session and source. If there is at least one potential segment, admission control determines whether source, relaying node or receiver can be connected to the distribution mechanism. Relaying nodes may occupy part of the resources in neighboring nodes, therefore the impact which relaying nodes make on other relay nodes, sources or groups must be assessed.

Depending on the forwarding model, resources may be reserved on a per source or per multicast group. We make the distinction between admission control and resource reservation although these elements are combined in several protocols; admission control is implicit when resource reservation is successful. However, the resource reservation is not necessary. It is sufficient to assess whether a new source or relay does not have a decremental impact on existing sources and/or relays. Admission control and resource reservation are not alternative elements; the mesh based protocols tend to separate the two [11,15,16,18,37,42]. They will admit sources and relays, but the resource reservation will only be done for a subset of the relay nodes [11,15,16,18,37,42].

Both admission control and resource reservation rely on the estimation of available resources and the estimation of required resources (consumed resource estimation). The complexity of the estimation depends on the capabilities of underlying MAC and physical layer.

The last necessary element is preemption. In a wireless ad hoc network all resources are stochastic entities. Random changes in the conditions of the radio channel or movement and changes in topology may affect the capacity. Earlier admission decisions may therefore result in oversubscription. The oversubscribed traffic must then be rejected or their reserved resources must be released. An explicit part of preemption is monitoring QoS or resource availability. Few protocols have implemented explicit preemption. Instead, preemption is performed as periodic admission control and resource reservation.

1.4. Multicast Model

The original wireline multicast protocols were based on a stringent multicast model. According to this model, a source could send data packets to multicast group without being part of the group, a sender should not need to know the address and identity of the receivers, and any receiver or source could join and leave the group dynamically. The multicast model defines the expectations applications will have to the distribution mechanism and it therefore imposes restrictions on the design space of the QoS multicast protocols. A protocol that does not adhere to the model can have a simpler design and potentially be more efficient. However, the applications may be more complex or costly to develop. The applications must either be tailor-made for the particular protocol, or an additional adaptation layer must be developed.

The QoS requirement for multicast may change the semantics of multicast when there are multiple sources per group. In a non-QoS setting, all receivers in a multicast group receive information from all sources as long as the network is not partitioned. Adding QoS implies that potentially there may not be enough resources on a logical link. The admission to these bottleneck links will depend on the sequence sources and receivers joining the group. If we assume admission control is used, it is then not given that all receivers will get information from the same set of sources. Translated into a video conference setting, there is a risk that the participants do not have the same view of the other participants. A shared distribution mechanism has the same potential problem for inconsistent admission control.

For shared trees, resources can be reserved either as shared or source specific. If the resources are shared by all sources, there is no difference between the semantics for QoS and non-QoS. The admission control is then whether a receiver or source can use the path to the tree. The reservation will not be performed in the rest of the tree. The result is that a source is either connected to all receivers or to none. Likewise, a receiver is connected either to all sources or to none. This is equivalent to whether a path exists in the non-QoS case. However, a shared resource reservation between multiple sources has a limited applicability for offering QoS. The exception is when the application imposes a strict ordering of when the sources use the resources, like voice in a conference.

To preserve the multicast semantics, admission control should be limited to whether a source or receivers should be allowed to join with given QoS requirements or to join without any requirements. To our knowledge the interaction between admission control/resource reservation and the group semantics has been discussed only to a limited degree.

There is a close relationship among the semantics of the admission control, adherence to the multicast model, the type of resource reservation/QoS offered, and the complexity of the protocols. The lack of adherence to the multicast model also indicates the potential need for special design of multicast enabled applications. As shown in

Table 2. Comparison of QoS multicast routing protocols in ad hoc networks.

No.	Protocol	Routing Scheme	Multicast Distribution	Adherence MulticastModel	Type of Admission Control	Type of Reservation(class, flow)	Type of Reservation(state)	QoS Constraints	MAC Sublayer	Tree/Mesh Maintenance	Estimating Resource	Resource Estimation Technique	Failure Handling	Group Formation	Group Teardown
1	QAMNet [11]	Reactive	Mesh	Yes	Intermediate	Per class	N/A	B	802.11	Soft	Yes	ConserRate	Soft	Source	Soft
2	CQMRP [12]	Hybrid	SST	No	Intermediate	Per flow	Hard	B,D,J,Buf	Any	Hard	No	–	Local	Source	–
3	QMRPCAH [13]	Hybrid	SST	No	Intermediate	Per flow	Soft	B,D	MACA	Hard	No	–	Global	Reveiver	–
4	HVDB [14]	Hybrid	SST	Yes	Intermediate	–	–	B,D	Any	Hard	No	–	Backup	Source	–
5	QoS-ODMRP [15]	Reactive	Mesh	Yes	Intermediate	Per flow	Soft	B	802.11	Soft	Yes	RateSum	Soft	Source	Soft
6	E-QMR [16]	Reactive	Mesh	Yes	Intermediate	Hybrid	Soft	B	802.11	Soft	Yes	Listening	Soft	Source	Soft
7	Hu [17]	Reactive	SST	No	Source	Per flow	Hard	B	802.11	Hard	Yes	Exchange	Global	Source	–
8	QMRP [18]	Reactive	Mesh	Yes	Intermediate	–	–	B	802.11	Soft+Hard	Yes	Exchange	Soft+Local	Source	Soft
9	QoS-AODV [19]	Reactive	ST	Yes	Intermediate	–	–	D	Any	Soft	Yes	ExBwRE	Soft	Receiver	Soft
10	HQMRP [21]	Hybrid	SST	No	Intermediate	–	–	B	TDMA	Hard	No	–	Local	Source	–
11	QoS-MEM [22]	Reactive	SST	Yes	Source	Per flow	Hard	B	TDMA	Hard	Yes	Timeslot	–	Source	–
12	LTM* [23]	Hybrid	Any	Yes	Intermediate	Per flow	Soft	B	CDMA over TDMA	Soft	Yes	Timeslot	Soft	Source	Soft
13	MPT* [24]	Reactive	SST	No	Source	Per flow	Hard	B	CDMA over TDMA	Hard	Yes	Timeslot	Global	Source	–
14	EQMGA [25]	Proactive	SST	No	Source	–	–	B	Any	Hard	No	–	–	Source	–
15	QMOST [26]	Hybrid	ST	No	Source	Per flow	Soft+hard	B	802.11	Hard	No	–	Global	Source	–
16	LACMQR [28]	Hybrid	SST	Yes	Intermediate	–	–	B	Any	Hard	No	–	–	Source	–
17	AQM [29]	Reactive	ST	Yes	Intermediate	Per flow	Hard	B	Any	Hard	Yes	Exchange	Global	Receiver	SI
18	M-CAMP [30]	Reactive	Any kind	No	Receiver	N/A	N/A	B	Any	Any	Yes	Probing	Local	Any kind	–
19	MCEDAR [31]	Proactive	Hybrid	Yes	Intermediate	–	–	B	MACAW	Soft	No	–	Soft	Common core	Soft
20	QoS-MAODV [32]	Reactive	ST	Yes	Intermediate	Per flow	Soft	B	802.11	Soft	Yes	RateSum	Soft	Receiver	Soft
21	HQMGA [33]	Proactive	SST	Yes	Intermediate	–	–	B,D	802.11	Hard	No	–	–	Source	–
22	QMR [44]	Reactive	Mesh	Yes	Intermediate	Hybrid	Soft	B	802.11	Soft	Yes	–	Soft	Source	Soft
23	EGA [35]	Proactive	SST	Yes	Intermediate	–	–	D,C	Any	Hard	Yes	ExBwRE	–	Source	–
24	SEQMRAN [36]	Reactive	ST	Yes	Intermediate	–	–	B,D,J	802.11	Hard	No	–	–	Source	–
25	FQM [37]	Reactive	Mesh	Yes	Intermediate	Hybrid	Soft	B	802.11	Soft	Yes	Listening	Soft	Source	Soft
26	ODQMM [38]	Reactive	ST	Yes	Intermediate	Per flow	Hard	B	TDMA	Hard	No	–	Local	Receiver	–
27	MACO [41]	Proactive	SST	No	Source	–	–	B,D,J	Any	Hard	No	–	–	Source	–
28	AMOMQ [42]	Reactive	Mesh	Yes	Intermediate	Per flow	Soft	B	802.11	Soft	Yes	RateSum	Soft	Source	Soft
29	QoS-MAODV-2Lqos [43]	Reactive	ST	Yes	Intermediate	Per class	N/A	B,D,Buf,S	802.11	Soft	Yes	ExBwRE	Soft	Receiver	Soft
30	HTQ [50]	Reactive	Any	Yes	Intermediate	Per flow	Hard	B	TDMA	Hard	Yes	Timeslot	Backup	Source	–
31	QMMRP [51]	Reactive	SST	Yes	Source	Per flow	Hard	B	CDMA over TDMA	Hard	Yes	Timeslot	Local	Source	–

Notes:

• Multicast distribution type: ST—Shared tree; SST—Source specific tree; Hybrid (reactive + proactive or geographical + proactive)
• Type of admission control (AC): Source—Source AC, Receiver—Receiver AC, Intermediate—Intermediate node AC
• (–): there is lack of information about the characteristic in simulation of the protocol
• N/A—No Apply
• QoS constraints: B—Bandwidth; D—Delay; J—Jitter; Buf—Buffer capacity level; ST—Stream latency; SR—Stream resolution; SC—Stream continuity; S—Stability
• MAC sublayer: Any—the protocol can be applied to any kind of MAC sublayer
• Resource estimation technique: ConserRate—This technique is based on conservative rate and current traffic rate; RateSum—Rate summaration; Listening—Medium listening; Timeslot—Determining free timeslots and scheduling; Probing—End-to-end probing; Exchange—Bandwidth usage exchanging; ExBwRE—Technique for estimation of other resources than bandwidth
• Failure handling: Soft—soft handling; Local—hard handling and local recovery; Global—hard handling and global recovery; Backup—Backup path switching
• Group formation: Source—source initiation; Receiver—receiver initiation; Common core—common node initiation
• Group teardown: SI—Session is terminated by a session initiato

(see Appendix), many of the protocols do not appear to be designed in accordance with the multicast model.

2. Mechanisms Specific to QoS and Multicast in Ad Hoc Networks

2.1. Mechanisms for Multicast Routing

Table 2 summarizes the characteristics of the 31 protocols for QoS multicast in ad hoc networks included in our survey. It provides comparison between protocols in term of routing scheme, multicast distribution type, whether adherence multicast model, tree/mesh initiation, type of admission control, type of reservation according to class and flow, type of reservation according to state, QoS constraints, MAC sublayer, tree maintenance scheme, and resource estimation technique. It also provides comparison between protocols in term of the presence or absence of the resource estimation technique.

2.1.1. Routing Type

The routing decision can be made centrally or distributively among all nodes. In a distributed scheme, all nodes take part in the routing process and determine the multicast tree/mesh structure. Typically, a request-reply process is performed to select multicast routes. The source floods a route request. Intermediate nodes make the decision of whether to forward the route request or discard it. A route reply is sent by the receiver and forwarded to the source. When an intermediate node receives the route reply, it is a confirmation that the node is part of the tree/mesh for the multicast group. Otherwise any state the node is in will time out. Protocols in [15,19,29,32,38] are examples of schemes using the distributed approach.

In the central method, the source (or a dedicated node) collects the topology and resource information from the network and computes the multicast tree/mesh. The next step is to distribute the calculated multicast tree/mesh topology to other nodes.

The central decided routing is used in [17,24,25,41]. The protocol proposed by Hu [17] is designed to correctly estimate interference between different flows. Therefore, all routes satisfying the QoS requirement must concurrently be determined by the source. In MPT [24], the source first discovers the topology, it then uses available bandwidth information of the links in topology to select the multicast routes. The protocol EQMGA [25] uses an entropy-based genetic algorithm to support QoS multicast routing. Here the entropy metric is computed based on the direction and the speed of the nodes and its neighbors. The protocol MACO [41] proposes a biology based ant algorithm where the direction towards the destination is determined by a heuristic method based on location.

In ad hoc networks the topology and resource information changes quite frequently. As a result, the resource information and the calculation of the multicast tree/mesh may be outdated in centralized schemes. The majority of the proposed schemes is therefore based on the distributed approach.

2.1.2. Routing Scheme

The routing scheme reflects the basic ad hoc routing schemes, namely proactive, reactive, geographic routing, and hybrid approach. Among these three types, reactive and hybrid approaches form the majority.

Only two protocols in [31,33] use a proactive approach. In these schemes, the routes to the destinations are maintained in the multicast table of each node. Since the source is aware of the topology (or part of topology) of the network, the multicast routes can be computed immediately. The routing table at each node is updated periodically. MCEDAR [31] is an extension of the CEDAR unicast protocol, where a backbone is established and maintained as the basis for all forwardings. The protocol HQMGA [33] divides the network into clusters and computes a tree for each cluster as well as a tree connecting all clusters. The trees are calculated by a genetic algorithm.

In the reactive approach, the nodes do not collect topology information in advance. Whenever a source or receiver joins a multicast group, join requests are flooded and the possible alternatives are unicast to the initiator from existing member of the multicast group. Reactive routing reduces the overhead at the expense of delay and broadcasting traffic to identify possible paths. There is a close resemblance between the dynamic signaling of joining and leaving groups and the reactive methods used for multicast routing. The two processes can therefore easily be combined. This might be the reason for a fair number of proposals based on reactive routing such as schemes in [11,15,16,18,32].

In geographic routing, packets are routed based on the location of nodes. With only local information, packets can be forwarded to the node that is closest to the destination. Route discovery and maintenance are then not needed. For multicast, geographic routing is used whenever applications require geographic coverage like requesting a target for a specific location. None of the protocols in the survey is solely based on geographic routing. However, two hybrid protocols in [14,28] combine proactive and geographic routing.

The hybrid approach combines the reactive and the proactive approach or combines the geographical and proactive approach. In [12,13,21], the network is divided into clusters. Each cluster has a cluster head which proactively maintains the local cluster topology. Reactive protocols are used to build the multicast tree/mesh between clusters. The clusters can be formed based on the geographical location of nodes, connectivity, signal range, mobility, or relative location between nodes. CQMRP [12] uses a self-terminating algorithm to build clusters. In LTM [23], the local link-state information is collected periodically for each node to identify the lantern which has one or more sub-paths existing between two nodes. The lantern-tree or multicast tree is then constructed reactively. The protocol QMOST [26] relies on a QoS unicast link state protocol (like QOLSR [56]). The overlay multicast tree is built actively after the source has all the necessary topology information. Two hybrid protocols in [14,28] combine proactive and geographic routing. LACMQR [28] is based on a distributed cluster-based QoS multicast routing algorithm. It requires maintaining the local state at each node. The location information provided by the positioning device is used to discover and maintain routes. HVDB [14] also divides the network into clusters and uses the mobility prediction and location-based clustering technique to form stable clusters. The forwarding between logical nodes is done by a location-based unicast routing algorithm.

If the number of receivers is high and the receivers are well distributed, it is not given that separate multicast trees/mesh is needed. It might be more efficient to broadcast the information to all nodes. The overhead could be lower if the broadcast is done efficiently. One example is Simplified Multicast Forwarding (SMF) [34]. SMF may utilize the Multi Point Relay nodes (MPR) of OLSR [49]. If SMF is combined with admission control and preemption, as suggested in [46], it may be considered QoS multicast routing. However, it would only be suited in context where most nodes are receivers.

2.1.3. Multicast Distribution Mechanisms

There are two types of distribution mechanisms, tree and mesh. With a tree structure, each node is associated with one parent that forwards packets. In a mesh, there might be alternative paths and a node can have multiple parents. A relaying node forwards a packet once regardless of who it was received from. A mesh can either be guaranteed or probabilistic. In a guaranteed mesh, a node has multiple nodes that forward packets to it. In a probabilistic mesh, the number of parents depends on the location of the receivers. All of the mesh protocols surveyed are probabilistic. Mesh structures are more robust. However they may consume more resources and the resource reservation mechanism becomes more complex.

2.2. Mechanisms for Providing Multiple QoS Constraints

Common QoS metrics used in the QoS enable multicast protocols include available bandwidth, end-to-end delay, probability of packet loss, delay variance (jitter), life time, and link reliability. Multi-constraints QoS multicast routing can be seen as the problem of solving a multi-constraints Steiner tree. It has been shown to be a NP-Complete problem, and heuristic approaches are usually used to solve the problem. This section outlines the existing proposals dealing with the multiple-constraints QoS problem.

In order to meet requirements (constraints) of applications, routing protocols must use QoS metrics to find QoS satisfied paths. While the number of hops is usually used for selecting routes in none-QoS routing, various metrics reflecting different application requirements are used for QoS routing. Note that QoS metrics used for selecting routes is not necessarily the same as QoS constraints. For example, stability metric can be used for selecting routes to meet the bandwidth requirement of applications. Metrics for selecting QoS paths can be classified into three categories, namely additive, multiplicative, and concave (minimum) properties. With additive metric, QoS of the whole path equals to aggregation QoS metrics of all links along the path. With multiplicative metric, QoS metric of the whole path equals to the product of QoS metrics of all links along the path. With concave metric, QoS metric of the whole path equals to the minimum QoS metrics of all links along the path. Delay, jitter, and cost are examples of additive metrics; packet loss ratio and link reliability are examples of multiplicative metrics; while available bandwidth is an example of concave metric.

The mechanisms for dealing with multiple QoS constraints can be classified into two categories, the constructed metric technique and independent metric technique. Both techniques will be described in detail in the following subsections.

2.2.1. Constructed Metric Technique

With this technique, the protocols use accumulated constructed metric, which is a function of other metrics such as bandwidth and delay, to prioritize the various path segments.

The protocol LACMQR [28] is an example. The constructed metric is a function of several metrics (e.g., delay and cost). When an intermediate node receives a probe packet, it calculates the value of constructed metric of this probe packet. If the value of constructed metric of the new probe is better than that of the previous probe, the node changes its predecessor to the node that forwarded the new probe packet. As a better path has been found, the probe will be forwarded; otherwise, the probe packet is discarded.

2.2.2. Independent Metric Technique

An alternative is to consider multiple metrics independently and only path segments that can satisfy all requirements are considered. Generally, all paths satisfying the QoS constraints are selected first. The next step is to apply an evaluation function, based on the other metrics, to select the best path, for building the multicast tree/mesh. The evaluation function is usually the function of some parameters such as cost of tree, tree stability. The protocols in [12,13,14,26,33,35,41,43] use this type of technique.

In CQMRP [12], the four parameters considered are bandwidth, delay, jitter, and buffer capacity. An intermediate node will forward a request packet (which is sent from source) if the following conditions are satisfied: its available bandwidth is greater than the required bandwidth, the transmission delay and delay variations is less than an allowed delay, and the buffer level is higher than a threshold. This protocol does not use an evaluation function.

QMRPCAH [13] uses delay, bandwidth, jitter, and packet loss metrics. However, the authors mainly considered the delay and bandwidth QoS constraints. In this protocol, the links that violate the bandwidth constraint will first be deleted. Then routing process uses a cost function of link delay to decide the multicast routes.

The protocol HQMGA [33] finds a multicast tree which satisfies the constraints (bandwidth and delay) and maximizes the value of an evaluation function. The evaluation function is a function of tree stability, latency, and the number of nodes that can receive the data stream.

Protocol EGA [35] considers two QoS constraints: propagation delay and residual battery energy. The propagation delay is used for building the multicast tree. The maximum lifetime of the multicast tree is defined based on a function of the total residual battery energy in the multicast tree. The protocol MACO [41] uses a modified biology inspired algorithm for multicast routing. Multiple multicast trees, where the links satisfying bandwidth, delay, and jitter constraints, are found; then the best multicast tree is selected based on the value of cost function of these trees.

In QoS-MAODV-2Lqos [43], QoS constraints are delay, throughput, and cost. Metrics considered for selecting the paths are end-to-end delay, bandwidth, power level, buffer level, stability level, and hop count. The power level is acquired from MAC layer. It indicates the availability of current amount of battery. The buffer level is used to present the available unallocated buffer. Stability level is defined as the connectivity variance of a node with respect to its neighboring nodes over time. The protocol provides services for three classes of applications: the delay sensitive application, throughput constraint application, and best effort application. When receiving the request from source, the receiver selects the path based on QoS class and QoS state, which are included in the request, and sends a reply packet forward to the source. When the source receives the reply packet, the stability metric followed by power level is used to select the path.

2.3. Mechanisms for Admission Control

Admission control is simple mechanism with few design choices. The decision is either to accept or reject connections of a source or a receiver to a distribution tree/mesh. One design choice is the location where admission control is made: at the source, at the receiver, or at intermediate nodes.

With admission control at an intermediate node, each node on a path checks whether it has sufficient resources to accept the multicast flow. Typically, a new source initiates a route request to establish a multicast route to its receivers. Each intermediate node checks if it has sufficient resources to meet the QoS requirements (typically available bandwidth). If so, the node forwards the route request; otherwise, the route request is discarded. The destinations therefore only receive route requests along one or more paths that have sufficient resources. The reply is sent along one of these paths back to the source. The return packets are typically used to confirm the admission control and the associated resource reservation. The actual path to select must then be confirmed in a three way handshake. Most of the protocols use this technique, for instance, protocols in [12,15,16,24,29].

Admission control can also be done at the receivers. M-CAMP [20] performs admission control by end-to-end probing. The source initiates probes, and the receivers can then determine whether to admit the flow. Probe packets are used to measure the quality of the path from the source to the destination. When the destination receives the probe packets, it measures the quality of the probe packet and compares to the known QoS requirements. If the quality of the probe packets is satisfied, the receiver accepts the session; otherwise, the session is rejected. The receiver then sends its decision to the source.

Finally, admission control can be performed at the source. The source calculates the QoS satisfied paths to all the destinations while building a multicast tree. Once a tree with the necessary resources has been identified, all nodes involved are informed of the multicast structure and the source admits itself to the single source tree. Protocols in [17,24,25,26,41,51,22] use this type of admission control.

The advantage and the cost of a particular admission control must be seen in close conjunction with the resource reservation. Admission control at intermediate nodes along potential paths may result in resource reservations that will not be used. Admission control at source or a centralized node may be based on outdated information, but offer more precise resource reservation in terms of nodes involved.

2.4. Mechanisms for Resource Reservation/Release

To achieve QoS, resources must be reserved, either explicitly or implicitly. In implicit resource reservation, the system is viewed as a black box and the number of flows into the system is restricted to those that can achieve the target QoS. There are no resources associated with a particular flow. When a new source or receiver is to be admitted into the system, end-to-end probing is used to determine whether the resulting QoS is acceptable. M-CAMP [30] is an example of a protocol using implicit reservation. With explicit resource reservation, each node associates resources to a particular source or a multicast group. Transmission bandwidth is the limiting resource and therefore the resource reserved. Most of the protocols use explicit reservation.

As mentioned in the description part of the routing methods, many protocols explore alternative paths. If the admission control is performed at intermediate nodes, resource reservation must also be done in conjunction with the admission control. In both cases, there is a likelihood that an allocated reservation is not being used. It may be on a path that is not selected, or a node downstream might reject the join request. Many protocols therefore divide the reservation into stages, like “possible”, “likely”, and a final commit stage when it is determined that packets will actually flow through the node [15,16,30,42]. This ensures that resources are not unnecessarily blocked. The protocol QoS-ODMPR [15] uses three states (explored, registered, and reserved) for resource reservation. The path discovery process reserves “explored” resources. The response back from the receivers changes the state of the selected forwarding nodes to “registered”. Only when traffic actual flows through the node, the reservation state changes to “reserved”. Similarly, E-QMR [16] uses three states called free, allocate, and reserved.

It is a policy issue if the sum of the resource reservation in the various stages can be more than the total resources. If most reservations are not committed, oversubscription could be beneficial to avoid unnecessary blocking. The final commit stage ensures that the sum of reserved resources is within acceptable limits. To our knowledge, this policy consideration has not been explored.

The location of the resource reservation is a design choice that depends on the underlying MAC protocol. With a shared access, a node’s transmissions will affect the available capacity at neighboring nodes. Two neighboring nodes may not have the same interference patterns and will therefore not necessarily have the same available bandwidth. It is therefore not given that free resources at a node also are free at the neighboring nodes. The protocols only perform reservation at the nodes in the forwarding path. However, the resource estimation may consider the impact of reservation at other nodes, for example in Hu [17]. However, this will not reflect the impact of reserving resources at the node on flows forwarded from other nodes.

As discussed in the Introduction section, there are two types of reservation for shared tree/mesh, namely a shared reservation, which is common for all sources, and a source specific reservation. A shared resource reservation reflects applications where only one source is active. A typical case is voice conferences. One protocol, ODQMM [38], offers both types and with different protocol functions. Reservation for the shared resources only travels to the existing distribution tree, while source specific travels to all nodes in the distribution tree. Several of the protocols do not make this distinction and one must infer the type based on how far the reservation travels in the distribution tree/mesh.

Figure 1(a) illustrates the classification of resource reservation/release mechanisms of QoS enable multicast protocols in ad hoc networks.

Figure 1(b) illustrates the types of reservation/release mechanisms for shared tree/mesh.

Figure 1. (a, left) Classification of resource reservation/release mechanisms of QoS enable multicast protocols in ad hoc networks; (b, right) Classification of resource reservation/release mechanisms for shared tree/mesh.

Figure 1. (a, left) Classification of resource reservation/release mechanisms of QoS enable multicast protocols in ad hoc networks; (b, right) Classification of resource reservation/release mechanisms for shared tree/mesh.

If there are multiple sources in a multicast group, source specific resource reservation and thereby admission control may result in that the receivers are not connected to the same set of sources. From an application viewpoint this may not be acceptable. The third alternative is represented by most of the mesh protocols, for example QAMNet [11]. They have source specific reservation along the primary paths, additional forwarders schedule the packets without any guarantees. Thereby they preserve the connection semantics of the non-QoS multicast, all sources will connect to the same subset of receivers. However, the quality may vary. This could be generalized into protocols without admission control, but with resource reservation. All sources and receivers are admitted. If there are enough resources on the selected path, the necessary resources are reserved. Otherwise the source or receivers are connected as best effort [16].

Reservation implies state. Traditionally, state is classified into soft sate and hard state. Hard states is maintained through explicit set up and tear down, while soft state is maintained with explicit and periodic set up and timer based tear down. Most of the protocols in the survey use soft state, since this is well suited for the dynamic topology and the dynamic membership of multicast groups. CQMRP [12] and AQM [29] use hard state for reserving resource. In CQMRP [12], a QoS-error notification message is sent out when the link break occurs. The node will release the reserved resources for the multicast group at the time it receives a QoS-error message. Also, during connection termination, the reserved resources are released by sending explicit resource release message. In AQM [29], a session is started and closed by a session initiator with the initiation message and the termination message, respectively. Additionally, a node informs its forwarders on the multicast graph when leaving a session by sending a leave message. Upon receiving the session termination message sent by the initiator, the forwarder frees the allocated resource.

Reservation mechanisms can also be classified into three types: per-flow reservation (IntServ), per-class reservation (DiffServ), and hybrid reservation (IntServ over DiffServ). In the per-flow reservation method, resources are reserved for certain flows or sources. It follows the IntServ model. Most of protocols use this kind of reservation, e.g., [12,15,16,30,38,42]. The DiffServ model is used by protocols in [11,43]. With this technique, there is no flow reservation and the reservation is implicit. The hybrid reservation used in [16,37] combines some features from both IntServ and DiffServ. In these protocols, the bandwidth is partitioned into fix reservation for accepted sources and shared reservation for other sources. The forwarding node provides IntServ and reserves bandwidth for every source that has been accepted. It provides DiffServ when it receives data packets from rejected sources or best-effort traffic and it has available bandwidth.

2.5. Mechanisms for Resource Estimation

Both admission control and resource reservation depend on resource estimation. The resource estimation for bandwidth depends on the type of MAC layer. In addition, some of the protocols also estimate other resources such as delay, buffer level, and power level. The resource estimation mechanisms are therefore divided into methods for estimation of bandwidth in contention-free MAC, methods for estimation of bandwidth in contention MAC, and methods for estimation of resources other than bandwidth.

2.5.1. Mechanisms for Estimation of Bandwidth in Contention-free MAC Ad Hoc Networks

The protocols in the survey use two types of contention-free MAC sub-layer, TDMA (Time Division Multiple Access) and CDMA-over TDMA. The CDMA (Code Division Multiple Access) system employs spread-spectrum technology and a special coding scheme to allow multiple users to be multiplexed over the same physical channel. CDMA can be overlaid on top of the TDMA infrastructure. In other words, multiple sessions can share the same TDMA slot via CDMA. In CDMA-over TDMA, the use of a time slot on a link only depends on the status of its one-hop neighboring links.

Four protocols in [21,22,38,50] use TDMA while two protocols in [23,24] use CDMA-over TDMA for their sublayer. Protocols in [21,38] assume that the available bandwidth of a link is available from the underlying layers. QoS-MEM [22] uses bandwidth-constrained multicast tree to formulate the QoS-aware Minimum Energy Multicast problem as a Mixed Integer Linear Programming model in a TDMA-based ad hoc network. A suitable scheduling of free slots for each link of the multicast tree can be obtained from this model. In [50], both the hidden-terminal and exposed-terminal problems are taken into consideration in order to possibly exploit the time-slot reuse capability. The hexagonal-based scheme offers a higher success rate for constructing a QoS multicast tree due to the use of the hexagonal-tree structure. A hexagonal-tree is a tree whose sub-path is a hexagonal-path, which is a special two-path structure.

In [23], timeslot reservation is used as a primitive operation for constructing the lantern-path and lantern-tree. The lantern is identified after collecting the local link-state information for all nodes. The lantern-tree then is constructed by the lantern-path search operation and the lantern-tree construction operation. The timeslot assignment algorithm on a path in [24] follows the method proposed in [48]. In this protocol, the available bandwidth of a link is the number of free timeslots over the link. The available bandwidth of a path is the minimum bandwidth of the links along the path. The available bandwidth of a tree is the minimum bandwidth of the paths on the tree.

2.5.2. Mechanisms for Estimation of Bandwidth in Contention-based MAC Ad Hoc Networks

With contention-based MAC, the actual resource can either be direct or indirect of the type “is there enough available resources?”. The direct estimation is a hard problem when the wireless channel uses a multiple access scheme. Transmissions from a node may block or interfere with transmissions from other nodes. Correct estimation therefore depends on full topology information and detailed knowledge of interference and transmission range for each node. Indirect estimation is based on end-to-end probing. Here the state of the network is not needed. Instead, the available resources are estimated based on whether the requesting node could be added with acceptable QoS for the information flow.

2.5.2.1. Direct Estimation

The bandwidth estimation in contention-based MAC ad hoc networks must incorporate four factors: available resource estimation, transmission resources consumed by transmitting a flow along a chain of nodes, interference between different branches in the multicast tree/mesh, and interference between different flows.

The bandwidth consumed by a requesting flow at a relaying node is different from the requested minimum bandwidth of the flow, since the relaying will block neighboring nodes from transmitting. Define r as the flow rate measured in Bytes per sec. A relaying node will therefore occupy h * r, where h is a function of topology and radio. In unicast, h will typically be between 2 and 7, depending on topology and the ratio between sensing and transmission range [54]. In multicast, the branching at a relaying node may increase the factor even further. In a simplistic case, where the transmission range equals the sensing range, the total capacity consumed at the forwarding node for k branches would be (2 ＋ k)*r. A receiving node connecting to an existing relay node does not consume resources. This illustrates that estimation of bandwidth consumed must be different for a source node, a relaying node, and a receiver that is not relaying.

So far, the examples have been formulated as interferences along a path from packets in the same flow. However, transmission of neighboring nodes will affect the available capacity of a node. Hu [17] classified the interference into two groups, interferences from different branches of the same multicast tree/mesh (the hidden multicast route problem) and interference from unicast of another multicast traffic (the hidden route problem).

The available bandwidth needs to be estimated. Three different methods can be identified: information exchange between the nodes, listening on the MAC layer, and summation of rates. The latter neglects any of the effects discussed in the previous paragraphs, and it is therefore not suited for contention based MAC layers.

In addition, 12 protocols do not estimate resource. They assume that the information about resource is available from lower layers. The different methods can be summarized by:

• Bandwidth usage exchanging—In this technique, the information for the metric is gathered by exchanging information of current bandwidth usage of existing session to its neighbor nodes. Protocols in [29,17,18] belong to this category.
  In AQM [29], each node sends its current bandwidth usage to its one-hop neighbors. It calculates its available bandwidth based on information received from its one-hop neighbors. The maximum bandwidth capacity of the node is acquired by the MAC layer. The residual bandwidth of the node is computed by subtracting the bandwidth usage of the node and all its neighbors from the maximum bandwidth. Hu [17] also uses this technique to compute available bandwidth.
  Each node in QMRP [18] collects bandwidth usage information of its one-hop neighbors and two-hop neighbors by periodically broadcast hello messages. A hello message contains bandwidth usage of the sender and of its one-hop neighbors. When a node receives a hello message, it knows its first and second neighbors and their bandwidth usages. Then the residual bandwidth is computed as the difference between raw channel bandwidth and total bandwidth usage (accumulation of bandwidth usage of the node and its first and second neighbors) divided by a weight factor.
• Medium listening—In this method, a node estimates the available bandwidth by observing the traffic coming in and going out of a node. Each node listens to the channel to determine the channel status (idle or busy) and compute the idle duration for a period of time. In [16,37], the available bandwidth is computed as T_i/t * BW, where T_i is the total idle time, t is observation time, BW and is the raw channel bandwidth. However, the above estimation techniques are imprecise because they do not account for packet overhead and coding rates. The advantage is low control overhead. The node, however, cannot release the bandwidth immediately when a route breaks [52] since it does not associate resources with flows.
• Rate summation—In [15,32,42] the capacity is estimated as the difference between the raw rate and the sum of rate of the flows through the nodes. The bandwidth between the node and its neighbor is just obtained by recording the rate through the node.

Figure 2 presents the classification of available resource estimation mechanisms of QoS enable multicast protocols in our survey.

In IEEE 802.11, the carrier sense range is usually more than twice transmission range (the default ratio between these parameters is often 2.2 [47]). Therefore, the transmission of k-hop neighbor nodes (where k is more than two) must be considered. None of protocols in surveyed papers considers the transmission of more than two hop neighbor nodes when estimating available bandwidth. Only one protocol, QMRP [18], considers transmission of two-hop neighbor nodes; two protocols, Hu [17] and AQM [29], take into account transmission of one-hop neighbor nodes.

In networks with a common channel with multiple accesses, the hidden node problem may cause packet collisions. QoS implies stricter boundaries on the packet jitter at each node. The more synchronized multicast is, the higher is the likelihood of packet collision due to hidden node problems. None of the protocols in the survey have investigated this effect.

Figure 2. Classification of available resource estimation mechanisms.

Figure 2. Classification of available resource estimation mechanisms.

An additional concern is that available capacity is not the same as usable capacity. If the capacity is utilized to the maximum, the delay might not be acceptable in systems with contention-based MAC. Ideally, protocols should estimate the threshold load that results in a not acceptable delay. This is different from the total capacity. In QAMNet [11], a conservative rate is used instead of the threshold rate. Then the available bandwidth of a node is the difference between the conservative admission control rate and the current rate of the real-time traffic. However, this protocol does not consider any method to obtain this conservative admission control rate, which is still difficult to obtain.

In the previous paragraphs, we have argued that resource estimation requires detailed knowledge of topology and transmission, interference, and carrier sense range. There is a continuous improvement in resource estimation in proposed QoS multicast systems. We also argue that the models are still based on simplified assumptions. The resource estimation will always be an estimate, not only because it is based on modeling assumption. The resource estimation is made when a source or receivers connect. It is therefore a point estimate for a longer period is the future. The accuracy of this point estimate will be a function of movement of all nodes involved and the delays in the information exchange between the nodes. It is therefore not given that more accurate models are the recommended path to follow.

2.5.2.2. Indirect Estimation (End-to-end Probing)

The alternative for estimation is to probe the network and measure the end-to-end performance from source to receiver as in [30] or from source to intermediate nodes as in [28]. In the former case, the source sends probes to the destinations. As soon as the destination receives the probe packets, it measures the achieved quality. If the difference between the quality of probe packets and required QoS (known prior) is within an accepted threshold, the receiver accepts the whole transmission; otherwise, it refuses. The method also introduces the priority of packets. The priority of the probe packets is lower than that of QoS multicast packets and higher than that of best effort packets. This priority assignment ensures that the probing traffic does not affect the existing QoS flows. An example of this mechanism is in M-CAMP [30]. In the later case, the sender also sends probe packets to the destinations. When a node receives a probe packet, it checks the QoS constraints and compares the metric (e.g., delay and cost) of the current probe packet with the previous probe packets. If the QoS constraints are satisfied and the metric of the new probe is better than the previous probes metric, the node change its predecessor to the node that the new probe packet came from. This strategy is called “the best predecessor replacement strategy”. LACMQR [28] uses this technique for multicast routing.

2.5.3. Mechanisms for Estimation of Resources other than Bandwidth

In these mechanisms, there are no constraints on the kind of MAC layer, since the focus is on parameters at the path level like delay, route stability, power level, buffer level, streaming resolution, streaming continuity, etc.

In order to measure delay, the creation time of a route request message is usually included in the route request. When an intermediate node receives this message, delay is computed as the difference between the creation time and the current time. Such one-way measured delay consists of the queuing delay, the transmission time, the collision avoidance time, and the control overhead time. This measured delay is included on each routing table entry corresponding to each destination. QoS-AODV [19] is an example of this technique. The method assumes a synchronized network.

Node stability, called entropy in [25], is calculated based on speed and direction of the node and its neighbors. The end-to-end route stability of a path between two nodes is computed based on the entropy of the nodes along the path and the number of intermediate mobile nodes over the route. The value of end-to-end route stability is used to build the multicast tree. EQMGA [25] uses this technique for QoS multicast routing.

The stability level is defined as the connectivity variance of a node with respect to its neighboring nodes over time. It is obtained by the information of the frequency of the changes in the neighbors of the node. Based on the value of these metrics, protocol establishes the multicast tree. QoS-MAODV-2Lqos [43] considers three metrics (power level, buffer level, stability level) for multicast routing.

2.6. Mechanisms for Tree/Mesh Maintenance

Tree/mesh maintenance mechanisms can be divided into two categories: soft state maintenance and hard state maintenance. For the soft state maintenance technique, the tree/mesh is refreshed periodically by the source or receivers. The period interval is usually several seconds (e.g. six seconds in protocol E-QMR [16]). There is no need to have an additional technique for handling the link break or the leaving/joining of multicast members. When a link is broken, it is repaired automatically at the beginning of the refresh interval. Similarly, as a new node wants to join the multicast group, it waits until the route request is sent again from the source or it sends out a route request in case of receiver initiates tree/mesh structure. A receiver leaves the multicast group by not participating in the tree initiation process. The protocols in [11,13,15,16] use the soft state technique to maintain the tree/mesh.

Figure 3 depicts the classification of tree/mesh maintenance mechanisms in QoS enable multicast protocols.

If the hard state maintenance mechanism is used, an additional technique must be included to handle the link break, the joining of a new node, and the leaving of an existing member node. The main difference between the QoS multicast scheme for wired networks and ad hoc networks is the mobility handling. The nodes usually maintain the information about neighborhood nodes by hello message. The link breakage is detected when no HELLO packet or other control or data packets are received from its neighbors during an interval.

Figure 3. Classification of tree/mesh maintenance mechanisms.

Figure 3. Classification of tree/mesh maintenance mechanisms.

When there is a broken link, the upstream node or the downstream node will initiate an explicit message to recover the route. Similarly, when a node wants to join the multicast group, it initiates an explicit join message. The explicit message in both cases can be sent out locally or globally in the network. In the local maintenance technique, any node which is on the tree/mesh can reply to the message. Then a path from the new node to this member is established and the node joins the tree/mesh. The protocols in [12,29,30] are examples of this technique. In the global maintenance technique, only a source can reply to the explicit message to form a QoS satisfied path from the source to the requested node. This technique is used in [21,24,28].

Mesh structures are more robust against link breaks since packets are sent along primary and alternative paths. No separate mechanism is needed until both the primary and alternative paths are broken [11,15,16,18,37,42]. An extension of the mesh structure is to use pre-calculated alternative paths. These are used immediately when a link break is detected. HVDB [14] deals with mobility by using logical hypercube model where there are multiple disjoint local logical routes between each pair of cluster heads. When detecting a link breakage, multiple candidate logical routes become available immediately to sustain the service without QoS being degraded.

When a receiver wants to leave the multicast group, the associated resource must be released and the routing table of involved nodes must be updated. In this case, a prune packet is sent upstream and the upstream nodes will delete the downstream node from its downstream list for the tree in its multicast table. As the upstream node receives the prune packet, it checks whether it has a downstream node other than the receiver. If it has, the node simply deletes the receiver from its routing table. The prune packet is then discarded. If it has not, it deletes the entry for the receiver in its routing table and releases the reserved resource. The node then sends the prune packet to all its upstream nodes before it leaves the multicast tree/mesh and becomes a non-forwarding node. The process is performed until either the prune packet reaches the source or the prune packet is discarded.

2.7. Mechanisms for QoS Preemption

Preemption techniques can be broadly divided into two categories, implicit preemption and explicit preemption. Implicit preemption is the result of performing periodic admission control and resource reservation. Most protocols use this mechanism to maintain QoS condition. Only two protocols [11,17] use explicit preemption mechanism to detect and recover the QoS violation.

In QAMNet [11], each node monitors its real-time traffic class periodically. When QoS violations are detected, a flow is randomly selected and congestion experienced (CE) bit is set in all packets belonging to that flow. This implies that downstream nodes treat the packet as best effort.

In the scheme proposed by Hu [17], a receiver monitors the receiving packets delivered from the source to check whether the bandwidth requirement is obtained. If it detects a QoS violation (the route is unsatisfied), the node will find a new bandwidth-satisfied route to the source.

3. Simulation Study

The previous chapter mapped the various QoS multicast protocols onto a framework of design choices. A similar commonality does not exist in the performance evaluation of the protocols. In this chapter, we briefly summarize the common features of the evaluation, and identify scenarios that have to a lesser degree been used in the performance evaluation.

Only four of the surveyed protocols do not include a simulation evaluation [14,30,31,38]. Ns-2 [40] is the most popular simulator (9 out of 27) followed by GloMoSim [39] (6 out of 27). The parameters of the simulations vary to a large degree.

In

Table 3. Simulation parameters of evaluated scenarios (1).

No.	Protocol	Network parameters					Desity & Hops		Speed (m/sec)	Mobility Model	Type of Radio
		Simulator	Area (m × m)	Transmission Range (m)	Capacity (Mbps)	# Nodes	Neighbor Count (Density)	No. of Nodes/Neighbor Count
1	QAMNet [11]	NS-2	1500 × 300	250	2	50	21.8	2.3	0–20	RWP	802.11 b
2	CQMRP [12]	NS-2	500 × 500	–	–	50	–	–	10–45	RR	–
3	QMRPCAH [13]	NS-2	–	–	1	200	–	–	2-20	CR	–
4	QoS-ODMRP[15]	GloMoSim	1000 × 1000	250	2	50	9.8	5	0.25–5	RWP	802.11
5	E-QMR [16]	GloMoSim	1000 × 1000	250	2	50–100	–	–	0–20	RWP	802.11
6	Hu [17]	NS-2	1000 × 1000	250	-	50	9.8	5	5–20	RWP	802.11
7	QMRP [18]	GloMoSim	1000 × 1000	250	2	50	9.8	5	3–20	RR	–
8	QoS-AODV [19]	NS-2	1500 × 300	250	-	50	21.8	2.3	0.5–20	RWP	–
9	HQMRP [21]	OMNeT++	3500 × 3250–6500 × 6250	2000	0.02	10–45	11–14	1.1–3.2	0–15	–	–
10	QoS-MEM [22]	–	1000 × 1000	50 mW*	–	20	-	-	0	–	–
11	LTM [23]	–	1000 × 1000	100	2	50, 100	1.6; 3.1	31.3–32.3	0–25	–	–
12	MPT [24]	–	100 × 100	30	–	100	28.3	3.5	Low	–	–
13	EQMGA [25]	NS -2	1000 × 1000	250	2	100	19.6	5.1	0–20	RWP	-
14	QMOST [26]	NS-2	1000 × 1000	250	–	100	19.6	5.1	0–10	RWP	802.11
15	LACMQR [28]	Glomosim	1000 × 1000	–	2	300–1500	–	–	–	–	–
16	AQM [29]	OPNET	1000 × 1000	250	10	10–100	2–19.6	5	1–4	RWP	–
17	QoS-MAODV [32]	Qualnet	1000 × 1000	250	2	50	9.8	5	0–42	RWP	802.11
18	HQMGA [33]	GTNetS	3000 × 3000	160	2	1000	8.9	112.4	0–1	RWP	802.11
19	QMR [44]	GloMoSim	1000 × 1000	250	2	50	9.8	5	0.25–5	RWP	802.11
20	EGA [35]	Self-developed	–	–	–	–	–	–	–	–	–
21	SEQMRAN [36]	NS-2	1500 × 300	250	11	50	21.8	2.3	0–1	RWP	802.11 b
22	FQM [37]	Glomosim	1000 × 1000	250	2	100	19.6	5.1	0–20	RWP	802.11
23	MACO [41]	–	–	–	–	20, 100	–	–	–	–	–
24	AMOMQ [42]	GloMosim	1000 × 1000	250	2	50	9.8	5	1–20	RWP	802.11
25	QoS-MAODV-2Lqos [43]	NS-2	1000 × 1000	250	2	60	11.8	5.1	10–60	RWP	802.11
26	HTQ [50]	NCTUns 2.0	1000 × 1000	200	5	20–50	2.5–6.3	8	0.28–11.1	–	–
27	QMMRP [51]	MATLAB	1000 × 1000	250	–	50–100	9.8–19.6	5.1	–	–	–

Notes:

• (–): there is lack of information about the characteristic in simulation of the protocol
• (a–b): the value ranges from a to b
• *: In QoS-MEM [22], transmission range is not provided while maximum transmission power is 50 mW, noise power is –50 dBm, minimum required SINR is 15 dB
• Neighbor count (density) = П * r * r * N/A where r is transmission range; N is the total number of network nodes; A is area of the simulation area.
• No. of nodes/Neighbor count: Number of nodes/Neighbor count
• RWP: Random Waypoint mobility model

and

Table 4. Simulation parameters of evaluated scenarios (2).

No.	Protocol	Multicast group				Traffic type/pattern			Simulating Background Traffic
		# Group	# Sources per Group	# Receivers per Group	% Receivers per Group	Traffic Type	Packet Size (bytes)	Rate (kbps)
1	QAMNet [11]	1	3	15	30%	CBR	330	118.8	Yes
2	CQMRP [12]	–	–	–	–	CBR	512	–	No
3	QMRPCAH [13]	1	–	10, 20, 50, 60, 100	5%–50%	Message length 5000 bits	–	Maximum 20 Mps	No
4	QoS-ODMRP [15]	3	1	–	-	CBR	512	128, 256, 512	No
5	E-QMR [16]	1	3	15	15%–30%	CBR	512	8	No
6	Hu [17]	10	1	3	6%	CBR	512	–	No
7	QMRP [18]	1	5	20	40%	CBR	512	8	No
8	QoS-AODV [19]	1	10	10–50	20%–100%	CBR	512	16 kbps	No
9	HQMRP [21]	1	1	3–7	15%–30%	1 session per minute	–	–	No
10	QoS-MEM [22]	1	1	5–20	25%–100%	–	–	–	No
11	LTM [23]	–	–	–	–	Message length 1-30Kb	–	–	No
12	MPT [24]	1	1	1-30	30%	–	–	–	Yes
13	EQMGA [25]	1	1	5–30	5%–30%	CBR	512	16–40	No
14	QMOST [26]	1	1	5–50	5%–50%	CBR	–	9.6; 200	Yes
15	LACMQR [28]	2	1–2	–	–	CBR	512	8	No
16	AQM [29]	–	–	–	–	Voice, audio, video	–	–	No
17	QoS-MAODV [32]	3	1	3–30	6%–60%	CBR	1024	128, 256, 512	No
18	HQMGA [33]	–	–	–	–	Stream	–	64	No
19	QMR [44]	1	3	15	15%–30%	CBR	512	8	No
20	EGA [35]	1	2	–	–	–	–	–	–
21	SEQMRAN [36]	9	1	5–50	10%–100%	CBR	256	4	No
22	FQM [37]	1	3	15	15%	CBR	–	118.8	Yes
23	MACO [41]	–	–	–	–	–	–	–	–
24	AMOMQ [42]	1	1–25	50	100%	CBR	512	–	No
25	QoS-MAODV-2Lqos [43]	1	5–25	50	83%	CBR	–	–	Yes
26	HTQ [50]	1	1	2–5	10%	Message length 1–4 Mbits	–	5 Mbps	No
27	QMMRP [51]	1	1	10–30	5%–60%	–	–	–	No

Notes:

• (–): there is lack of information about the characteristic in the simulation evaluated;
• (a–b): the value range from a to b.

(see Appendix), we have tabulated different characteristics of the evaluation. Most of the protocols are evaluated without any common simulation parameter setting. For instance, the simulation area varies from 500 m × 500 m to 300m × 3000m, and transmission range varies from 30 m to up to 2000 m.

As other authors have noted [53], the simulation studies in the ad hoc field do not always give sufficient level of details. As shown in Table 3 and Table 4, for many protocols in the survey there is not sufficient information about parameter settings.

The number of nodes in a scenario varies from 10 nodes to 1500 nodes and reflects the various design goals of the protocols. The number of neighbors is calculated based on transmission range and node density range disregarding any boundary effect. The number is an indicator of whether the protocols are evaluated in topology sparse or dense environments (a number below 10 should be considered sparse).

The risk of network partitioning increases as the expected number of neighbors decreases. A protocol operating in a dense network is more likely to recover from link failure or routing failure compared to operating in more sparse environments. On the other hand, dense networks tend to have more interfering paths making it more difficult to estimate, reserve, or maintain QoS for the ongoing multicast sessions. A fair number of the protocols are evaluated in environments with less than 10 expected neighbors, where there is a risk of partitioned networks.

In Table 3, column 9 (number of nodes/expected number of neighbors) provides an indication of the length of the path from source to receivers. As a group, the protocols are evaluated over a reasonable set of expected path lengths.

Mobility of nodes varies from 0 m/s to 60 m/s. Most of the protocols use Random Waypoint as the mobility model (15/27 schemes). In this model, each node randomly selects the moving direction and move there at a random speed with a uniform distribution. Upon reaching the destination, the node stays there for some pause time. Upon expiration of the pause time, the next destination and speed are again chosen in the same way and the process repeats until the simulation ends. The schemes in [12,18] use the random direction and the random speed for nodes, while the scheme in [13] uses the random direction and the constant speed for nodes. Most scenarios are evaluated over a range of speeds ranging from no movement to vehicle speed (above 10 m/sec). Notable exceptions are [22,33,36], in which [22] evaluates with static nodes, [33] and [36] evaluates at very low mobility with speed ranging from 0 m/s to 1 m/s.

Although the set of protocols span a wide scenario, the multicast aspects of the scenarios were limited. A fair number of the evaluations only have one source per group which reflects a streaming scenario. Protocols in [15,17,21,22,24,25,26,32,36,50] are examples. The number of sources impacts on the efficiency of mechanisms of source specific tree and shared tree/mesh.

Also along the axis of competing traffic the scenarios are limited. Only five schemes consider multiple groups in scenarios: [17] with 10 groups, [36] with nine groups, [15] and [32] with three groups, and [28] with two groups. In addition, only five schemes used background traffic [11,24,26,37,43]. It is not a realistic usage scenario when there is no background traffic in simulation. More important, it is also a limited test of the protocols ability to estimate capacity, interference and needed resource reservation of protocols.

The density of the receivers covers a larger range, but there are a few protocols that have only been evaluated for a limited range of variability. As a group, the protocols seems to have been evaluated for sufficient range of possible receiver densities.

Multicast is usually related to real time applications such as video streaming, audio conference. This is reflected in the universal use of Constant Bit Rate traffic generators (CBR). However, the large packet size more closely reflects packet sizes used in video and not in voice.

The evaluations encompass different metrics. The common ones are PDR (Packet Delivery Ratio), success rate, average latency, packet loss, and routing overhead. These are network centric and do not reflect the group aspect of multicast. Examples of such performance metrics are rate of successful joins and the fraction of groups using overloaded distribution trees [29].

There is no common set of usage scenarios, and therefore also no common performance metrics, topology and traffic scenario. The diversity in the simulation scenarios is therefore to be expected. However, the QoS aspect of the protocols necessitates mechanisms for resource reservation and resource usage. We had therefore expected a larger fraction of the simulation studies to include competing traffic from other groups and unicast traffic.

4. Conclusions

Our focus has been on discussing the possible alternatives in the design space. There are a large number of proposed protocols, but there are still multiple mechanisms that have not been fully investigated. There are at least three areas that should be investigated further, namely, heterogeneous networks, connectionless multicast and preemption.

• In heterogeneous ad hoc networks, nodes have different transmission ranges, channel capacity and receivers have different QoS requirements. This increases the risk of inconsistent routing tables. Also, performing admission control and resource reservation for different QoS requirements becomes challenging.
• Most of the protocols do not use preemption but utilize periodic admission control. In either case, random choice selects the flows, sources and receivers that are allowed or denied. Multicast packets do not have the same “value”. The value of a packet decreases as it traverses the distribution tree or mesh. Its highest value is at the top, since the loss will affect the most receivers. At the same time, a tree with many receivers might have a different value than one with few receivers. None of such considerations are part of the preemption schemes evaluated.
• Connectionless multicast routing or source routing (source computes the route and includes identification of relay nodes in the packet) has only been included in a few protocols. In particular, when there are only a few receivers, and the groups have a limited lifetime, the overhead of maintaining state at all relay nodes might not be optimal.

In the previous section we discussed the evaluation of the proposed protocols. As other authors have clearly identified [53], there is need for a stricter documentation and more common evaluation scenarios. These conclusions also are valid for the subgroup of proposals we have analyzed. QoS in multicast is needed in media distribution, and in an ad hoc network this cannot only be associated with streaming. The protocols should therefore also be evaluated for a larger set of groups and sources. The traffic models should also reflect a wider set of types and background traffic. The latter is important, for it is unlikely, that ad hoc networks are dedicated to only multicast.

A possible lack in most of the proposals is the application viewpoint. For example, few of them discuss the implication of admission control and the application. For some of the proposals, one could risk that participants in video conferences did not have a full mesh view of all the other participants. We believe that future proposals should take an application viewpoint when designing admission control and preemption mechanisms.