## 5 Simulation Result and Discussion
### Simulation Based on Different Numbers of MEC Servers  
The number of MEC servers can have a significant impact on offloading latency costs and energy consumption in the edge node. Generally, adding more MEC servers to the system can reduce the offloading latency cost, as tasks can be distributed across multiple servers and processed in parallel, leading to faster processing times. However, adding more servers can also increase energy consumption, as each server requires power to operate. The optimal number of MEC servers for a given MEC system depends on various factors, including the workload characteristics, the performance requirements, and the energy constraints. For instance, if the workload is highly parallelizable and energy consumption is a key concern, adding more servers can lead to better performance and energy efficiency. On the other hand, if the workload is less parallelizable and energy consumption is not a limiting factor, a smaller number of servers may suffice. In Figure 5 on the left side, we compare the performance of total latency on average in terms of different numbers of MEC Servers. The given information presents the results of a comparison between the proposed scheme and three conventional offloading approaches: Greedy Latency, Load Balancing, and Random Offloading based on different numbers of MEC servers, including 2, 4, 6, 8, and 10. The proposed scheme achieves total latencies in ms of 62.88, 60.60, 58.49, 56.41, and 54.28 according to the MEC numbers of 2, 4, 6, 8, and 10, respectively. These results indicate that the proposed scheme performs well in reducing latency as the number of MEC servers increases. In comparison to the proposed scheme, the Greedy Latency approach achieves total latencies of 62.87, 61.60, 59.20, 57.89, and 56.67 according to the MEC numbers of 2, 4, 6, 8, and 10, respectively. Similarly, the Load  
Figure 4: Total latency and cost based on number of tasks. Balancing approach achieves total latencies of 62.92, 61.58, 60.39, 59.16, and 57.91 according to the MEC numbers of 2, 4, 6, 8, and 10, respectively. The Random Offloading approach obtains total latencies of 63.06, 62.06, 61.00, 59.87, and 58.67 according to the MEC numbers of 2, 4, 6, 8, and 10, respectively. If we compare the performance of total latency on average in terms of different numbers of edge servers, when the number of edge servers increases from 2 to 10, the total latency of our proposed approach is 1.90% better than that of Greedy Latency, 3.18% better than that of Load Balancing, and 4.10% better than that of Random Offloading. Overall, the results show that the proposed scheme and the conventional approaches demonstrate varying levels of performance in reducing latency based on the number of MEC servers. However, the proposed scheme outperforms conventional approaches in reducing latency, particularly as the number of MEC servers increases. In Figure 5 on the right side, we compare the performance of total cost on average in terms of different MEC servers. As the number of MEC servers varies from 2 to 10, the proposed Lagrange method achieves lower total costs of 0.0633, 0.0618, 0.0605, 0.0592, and 0.0578. These results indicate that the proposed algorithm is effective in reducing computation costs even when the number of tasks increases. In contrast, conventional approaches have different results. Greedy Latency yields total costs of 0.0633, 0.0624, 0.0610, 0.0606, and 0.0598, while Load Balancing results in a total cost of 0.0633, 0.0625, 0.0617, 0.0609, and 0.0603. Lastly, Random Offloading produces a total cost of 0.0635, 0.0629, 0.0622, 0.0614, and 0.0606 according to the MEC numbers of 2, 4, 6, 8, and 10, respectively. If we compare the performance of the total cost on average in terms of different numbers of edge servers, when the number of edge servers increases from 2 to 10, the total cost of our proposed approach is 1.49% better than that of Greedy Latency, 2.02% better than that of Load Balancing, and 2.64% better than that of Random Offloading.