## 4 Simulation Results and Performance Analysis
### Comparison Charts  
For reducing the overhead incurred in the process of cluster formation and maintenance, the formed clusters must be stable. The stability of the clusters is inversely proportional to the number of times a vehicle changes its state. The proposed scheme achieved reduction in the number of state changes by forming the clusters with vehicles having relatively the same speed and selecting the cluster head that had highest degree of cohesion among its 2-hop neighborhood. Figure 10 depicts the cluster stability in all three traffic scenarios. The results showed that almost 80% of the vehicles, once they clustered under one cluster head, remained in the same cluster for a longer duration in an average traffic scenario, during dense traffic it turned out to be 71%, and during sparse traffic it was 54%. During the simulation runs, the cluster state of a vehicle changes on an average of 3 to 4 times and up to a maximum of 10 times. The cluster density is measured as the average number of vehicles belonging to the cluster. Figure 11 compares the cluster density of DTA, DWCM, and the proposed scheme CDS_SC. In the proposed scheme the cluster size increases when the number of vehicles increases and thereby the number of clusters decreases. This exhibits the typical behavior of the vehicle movement in a real-time scenario. When the traffic density increases, due to the presence of a higher number of vehicles on the road, the speed of the vehicles within a region is almost the same and their degree of cohesion increases. Hence, the number of vehicles per cluster increases. Figure 10: Cluster stability. The cluster head density is measured as the number of vehicles selected as cluster heads per kilometer. Figure 12a compares the cluster head density of DTA, DWCM, and the proposed protocol CDS_SC. The CDS_SC exhibits a slow increase in the number of cluster heads when the number of vehicles increases. That is when the number of vehicles increases by ten times, the number of cluster heads increases only by twice and this is due to the increase in the cluster size. Figure 12b shows the percentage of vehicles that are identified as cluster heads, cluster members, gateways, and un-clustered in sparse, average, and dense traffic scenarios. The reduction in cluster heads and gateways clearly reveals the achievement of the reduction in the number of rebroadcasting vehicles. In dense and average traffic scenarios the un-clustered vehicles were almost 0% (<1%), and only 6% of vehicles acted as cluster heads and 1% of vehicles acted as gateways. Hence, a total of only 7% of vehicles are rebroadcasting. Figure 11: Average number of members per cluster. Figure 12: _Cont._  
Figure 13 compares the percentage of vehicles selected as cluster heads and gateways in DTA, DWCM, and CDS_SC. The proposed scheme outperforms the other two protocols. In CDS_SC, when the network was sparse, nearly 12-36% of the vehicles are rebroadcasting, whereas in dense and average networks only 6% to 10% of the vehicles are rebroadcasting. Compared to DTA and DWCM, the proposed algorithm has one-third reduction in the percentage of vehicles that performs rebroadcasting. This significantly reduces the broadcast storm problem. Due to reduction in rebroadcasting the packet collisions, packet losses, and delay are also reduced. The selection of gateway vehicles based on set cover significantly reduces the number of rebroadcasting vehicles. The proposed algorithm chooses only 4% to 12% of vehicles as gateways, whereas in DTA nearly 7% to 16% of vehicles are chosen as gateways and in DWCM nearly 9% to 28% of vehicles are chosen as gateways. Figure 14 shows the message reachability in the three different scenarios. The packet delivery ratio was calculated as the percentage of vehicles successfully receiving the alert message. In a sparse scenario using a store-and-forward mechanism [31] to overcome intermittent connectivity, 88% to 96% reachability has been achieved. In average and dense scenarios 99% to100% reachability was reached.