## 6 Experiments
### Use Case  
For this comparison, we present a scenario to be simulated in Phileas that describes a smart city that provides several applications to its citizens. Specifically, the use case contains the description of a total of 13 devices distributed among the Cloud Continuum: 10 Edge devices, 2 Fog devices, and a Cloud device with unlimited resources to simulate unlimited scalability. Along with the devices' description, the use case defines 6 different smart city applications, namely: healthcare, pollution-monitoring, traffic-monitoring, video-processing, safety, and audio-processing applications, whose importance is described by the _Theta_ parameters shown in Table 3.  
To simulate a workload for the described applications, we reenacted 10 different groups of users located at the Edge that generate requests according to the configuration values illustrated in Table 4. It is worth specifying that the request generation is a stochastic process that we modeled using 10 different random variables with an exponential distribution, i.e., one for each user group. Furthermore, Table 4 also reports the computed latency for each service type. As for the time between message generation, we modeled the processing time of a task by sampling from a random variable with an exponential distribution. Let us also note that the \"compute latency\" value does not include queuing time, i.e., the time that a request spends before being processed. Finally, the resource occupancy indicates the number of cores that each service instance requires to be allocated on a computing device.  
We set the simulation to be 10 s long, including 1 s of warmup, to simulate the processing of approximately 133 requests per second. Finally, we report the intra-layer communication model in Table 5, where each element is the configuration for a normal random variable that we used to simulate the transfer time between the different layers of the Cloud Continuum.  
Concerning the optimization approaches, we compared the open-source and state-of-the-art DQN and PPO algorithms provided by Stable Baselines3 ([[https://github.com/DLR-RM/stable-baselines3](https://github.com/DLR-RM/stable-baselines3)]([https://github.com/DLR-RM/stable-baselines3](https://github.com/DLR-RM/stable-baselines3)) (accessed on 21 September 2023)) with the GA, PSO, QPSO, MPSO, and GWO. For the metaheuristics, we used the implementations of a Ruby metaheuristic library called ruby-mhl, which is available on GitHub ([[https://github.com/mortonesi/ruby-mhl](https://github.com/mortonesi/ruby-mhl)]([https://github.com/mortonesi/ruby-mhl](https://github.com/mortonesi/ruby-mhl)) (accessed on 21 September 2023)).  
\begin{table}
\begin{tabular}{c c c c} \hline \multirow{2}{*}{**Service Type**} & **Time Between Req.** & \multirow{2}{*}{**Compute Latency (\(\lambda\))**} & **Resource Consumption** \\  & **Gen. (\(\lambda\))** & & **Consumption** \\ \hline Healthcare & 1/120 (ms) & 1/150 (ms) & 4.5 (cores) \\ Pollution & 1/45 (ms) & 1/250 (ms) & 3.5 (cores) \\ Traffic & 1/40 (ms) & 1/300 (ms) & 3.5 (cores) \\ Video & 1/100 (ms) & 1/225 (ms) & 6.0 (cores) \\ Safety & 1/100 (ms) & 1/150 (ms) & 4.0 (cores) \\ Audio & 1/25 (ms) & 1/200 (ms) & 3.0 (cores) \\ \hline \end{tabular}
\end{table}
Table 4: Service description: time between request generation and compute latency modeled as exponential random variables with rate parameter \(\lambda\) for each service type and resource occupancy.  
\begin{table}
\begin{tabular}{c c c c} \hline \hline
**Layers** & **Edge** & **Fog** & **Cloud** \\ \hline \multirow{2}{*}{Edge} & \(\mu=5.00\) (ms) & \(\mu=15.00\) (ms) & \(\mu=100\) (ms) \\  & \(\sigma=3.00\) (ms) & \(\sigma=5.00\) (ms) & \(\sigma=6.00\) (ms) \\ \hline \multirow{2}{*}{Fog} & & \(\mu=5.00\)(ms) & \(\mu=80.00\) (ms) \\  & & \(\sigma=3.00\) (ms) & \(\sigma=8.00\) (ms) \\ \hline \multirow{2}{*}{Cloud} & & & \(\mu=17.00\) (ms) \\  & & & \(\sigma=7.00\) (ms) \\ \hline \end{tabular}
\end{table}
Table 5: Communication latency configuration for the Cloud Continuum use case.