## 6 Testing and Validation  
This section shows the simulations performed, and the results obtained are discussed (see Table 1). CloudAnalyst [32] was used for all simulations. It is a simulation tool based on CloudSim [33; 34], specifically designed to model and analyze the impact of the geographic distribution of cloud computing resources on performance. It provides an interface to characterize the nodes regarding computational capacity, storage space, geographic location, network characteristics, and the number of concurrent users. After preparing the environment, it is possible to launch the simulation and obtain performance measures through the use of this tool, which we will analyze in this section. The Cloud Analyst tool was configured to simulate the three different architectures defined in Section 4 with the nodes represented in Figure 14. In detail, the characterizing nodes are as follows: \(UB_{1}\), \(UB_{2}\), \(UB_{3}\), \(UB_{4}\), and \(UB_{5}\) represent the various pulls of users that can vary from a value n to a value n\({}^{\prime}\). In our specific case, four different simulations were carried out for each of the three architectures. The number of \(UB_{5}\) was set to 5, the peak user hours for each UB were set from 3:00 P.M. to 9:00 P.M., and the number of users varied in the following way. \(NUB_{\text{min}}\) is denominated as the minimum number of users for each UB, \(NUB_{\text{max}}\) is the number of connected users for each UB, \(N_{\text{max}}\) is the maximum number of total connected users, and \(N_{\text{min}}\) is the minimum number of connected users. The configurations considered are as follows:  
1. \(NUB_{\text{min}}=0\) and \(NUB_{\text{max}}=1\Rightarrow N_{\text{min}}=0\) and \(N_{\text{max}}=5\). 2. \(NUB_{\text{min}}=1\) and \(NUB_{\text{max}}=10\Rightarrow N_{\text{min}}=5\) and \(N_{\text{max}}=50\). 3. \(NUB_{\text{min}}=10\) and \(NUB_{\text{max}}=100\Rightarrow N_{\text{min}}=50\) and \(N_{\text{max}}=500\). 4. \(NUB_{\text{min}}=100\) and \(NUB_{\text{max}}=1000\Rightarrow N_{\text{min}}=500\) and \(N_{\text{max}}=5000\). As for the components in red, these represent the cloud and edge resources on which we deployed the components described in the section dedicated to architectures (e.g., Server Cloud is SC). In the simulations carried out, the virtual machines created for the server were equipped with 10 TB of storage, 150 GB of RAM and Intel Xeon processors. The edge virtual machines, on the other hand, had 500 GB of storage, 10 GB of RAM, and a 4-core ARM CPU. Since most of the services used came from America, we simulated the resources as if they were allocated by consistently setting the data transmission time with this design choice. As for the edge components, these were simulated by setting the latency time appropriately low to simulate a resource allocated close to the IoT devices and a reduced computational capacity based on the preliminary tests performed in the implementation. Figure 14: This figure shows graphically, for each architecture, the defined components and user groups, highlighting the interactions between the users and the various components. Figure 15 shows that the resource distribution and optimized configuration of architectures two and three make them more scalable and efficient. Moreover, among all architectures, the minimum response times are relatively stable and low, especially for architectures two and three, indicating that systems can handle isolated requests more efficiently, especially with a low user load. Going into more detail, several critical values essential for interpreting the results emerge from the table. The generic simulation is described by the code NArchi_i.j, where N represents the simulated architectures in the order they are described in Section 4, i represents the minimum number of users for each connected userbase, and j represents the maximum number of connected users.