# An Efficient Resource Allocation Algorithm for Device-To-Device Communications
## 5 Discussion  
This section discusses the findings of the proposed study. As can be seen from the simulation results in Figures 2-10, the proposed allocation algorithm gives better performance in terms of the mentioned parameters in those Figures as compared with the existing competing alternatives. As can be seen from Figure 2, when the number of channel allocations increases, the total system capacity of the existing algorithms in references [16; 20] and RRA is much lower than the proposed algorithm. The capacity gap gets wider with an increasing number of channels which makes the proposed algorithm superior than them. It is also worth notable that the proposed scheme has closed performance with the optimal allocation scheme and this validates with the analytical formulation. In Figure 3, the access allocation to the number of D2D users versus the number of channels is compared for all the algorithms. It can be clearly seen from Figure 3 that as the number of channels allocation increases, the D2D users' access of the proposed algorithm shows better performance than the existing reference algorithms and it also has close relation with the optimal scheme, verifying its effectiveness. The impact of the number of D2D user pairs on the capacity is illustrated in Figure 4. As can be seen from Figure 4 that as the number of D2D user pairs increase, the capacity of the proposed scheme shows a better increase than the existing algorithm, which makes it suitable for a large number of D2D users pairs scenarios. To elaborate on the effectiveness of the proposed allocation algorithm further, the total system capacity is analyzed against the SINR threshold in Figure 5. The results indicate that the capacity of the proposed M21 GS scheme is better than reference [16; 20] and random resource allocation schemes for any SINR threshold value. This means the proposed scheme gives stable and improved QoS under different SINR conditions. The impact of the number of iterations on the total system capacity and the average energy efficiency is assessed in Figures 6 and 7. In Figure 6, when the number of channels is 10, the proposed algorithm converges at _Iteration_ = 4 and gives \(0.6\times 10^{8}\) bps capacity. When the number of channels is 20, the proposed algorithm reaches its peak capacity of \(1.25\times 10^{8}\) bps at _Iteration_ = 7. Finally, when the number of channels is 30, the proposed allocation algorithm reaches the peak capacity of \(1.9\times 10^{8}\) bps at _Iteration_ =12. Such results give us important information about the impact of the number of iterations on the total system capacity. It means that for a higher system capacity requirement when the number of channels is increased, the number of iterations should also be increased to reach the peak capacity value. On the other hand, the existing algorithms require a large number of iterations to give the same capacity, which makes them unsuitable for the D2D communications. The impact of the number of iterations on energy efficiency is illustrated in Figure 7. The results indicate the effectiveness of the proposed algorithm over the existing algorithms. The energy efficiency of the proposed algorithm is almost independent of the number of iterations and stable at 58 Mbit/J which makes it robust against hardware impairments and channel limitations. On the other hand, the scheme in reference [20] reaches an energy efficiency of 50 Mbit/J at _Iteration_ = 13. The algorithm in reference [16] requires MAXGEN= 10 to reach its peak energy efficiency of 43 Mbit/J, whereas the random resource allocation algorithm requires MAXGEN=15 to reach its peak energy efficiency of 33 Mbit/J. By comparative assessment of both results in Figures 6 and 7, the proposed scheme requires a smaller number of _Iterations_ to provide an improved performance than the other competing alternatives. Therefore, system performance can be controlled to an optimal outcome by setting the number of _Iterations_ to a particular required value.