## 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 and Table 4 (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 \(\times\) 500 m to 300m \(\times\) 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.