## 4 Algorithmic Approaches
In general, it can be observed that the objective solutions are higher for \(\alpha=0.75\) compared to \(\alpha=0.5\) and \(\alpha=0.25\), which is consistent because giving more weight to switch-controller latencies, which are more numerous than the connections between controllers, naturally leads to higher solution values. It is also noticeable that, in general, the scenario with \(\alpha=0.5\) is worse than the scenario with \(\alpha=0.25\) and \(\alpha=0.75\), either in terms of CPU processing times and MipGaps obtained. Furthermore, it can be appreciated that \(\alpha=0.75\) achieves more efficient results in terms of processing times for larger networks compared to \(\alpha=0.25\). For \(\alpha=0.75\), optimal solutions are obtained for all benchmark networks studied, unlike \(\alpha=0.25\) and \(\alpha=0.5\), where an optimal solution is not obtained for the VtlWavenet2008 network. Regarding the study

\begin{table}
\begin{tabular}{l c c c c c c c c c c c} \hline \hline \multirow{2}{*}{**Network Name**} & \multicolumn{3}{c}{\(M_{3}\) **with \(\mathbf{\mathbf{\mathbf{\mathbf{\mathbf{\mathbf{\mathbf{\mathbf{\mathbf{\mathbf{ \mathbf{\mathbf{\mathbf{\mathbf{\mathbf{\mathbf{\mathbf{\mathbf{\mathbf{  }}}}}}}}}}}}}}}\) & \



of random networks, the results are similar. It is noted that \(\alpha=0.75\) achieves optimal solutions for all the studied networks, whereas \(\alpha=0.25\) and \(\alpha=0.5\) do not achieve optimal solutions; instead, the solutions are close to optimal for the 100-node network. Additionally, for \(\alpha=0.25\), less efficient results were obtained when compared to \(\alpha=0.5\) for all the networks except for those with 20, 35, 45, 80, and 100 nodes. Overall, \(\alpha=0.75\) yields better results in terms of CPU processing times. Regarding this analysis, it can be determined that as the weighting of switch-controller communication relative to controller-controller communication increases, the objective values approach one. After the previous observations and to improve the performance of the methods used so far, the best model, \(M_{2}\), was compared to the proposed algorithm. For the scenario with 20% controller density, it can be observed in Figure 2, on the left side, that the solution value found by the algorithm is not better than that of model \(M_{2}\). However, it is still very close, with small differences in the majority of the studied networks. In contrast, the CPU times used for networks with fewer nodes are similar, whereas for the larger networks, they are drastically lower, as observed in network #13 (following the same order as the benchmark networks in Table 1). Similarly, the comparison results can be observed for the 30% controller density scenario. This can be observed in Figure 3.

Figure 3: This figure represents both the objective function values on the left and the CPU times on the right side for the benchmark networks studied at a 30% controller density. Figure 2: This figure represents both the objective function values on the left and the CPU times on the right side for the benchmark networks studied at a 20% controller density. For this scenario, the solutions found by the algorithm align more closely with those obtained using model \(M_{2}\), with considerably better times in the majority of the studied networks and noteworthy performance in larger networks, such as network #13. The trend of aligning with model \(M_{2}\) is highlighted more effectively in the 40% controller density scenario. In these cases, the proposed algorithm achieves solutions that are very close to those of model \(M_{2}\), with significantly more efficient times. It performs best in the largest networks, where the solution found is very close to optimal and has drastically lower CPU times. Observe network #13 in Figure 4. The same previous analysis is conducted with the studied random networks. In this case, there are certain differences compared to the benchmark networks.