## 6 Evaluation
### Case Description and Simulation Configuration  
Our CPS is composed of a sensor network of LoRa motes, each equipped with a sensor measuring \(PM_{10}\) in \(\
icefrac{{\text{g}}}{{\text{m}}^{3}}\). Eight motes are installed in fixed position, while two are mobile (mounted on public transport systems). LoRa network coverage on the city is provided by nine gateways, whose position in the simulated environment matches one of the physical gateways deployed in the Belgian city of Leuven. The target of the control system are 300 households, randomly selected in the city area, equipped with a smart thermostat. Our logical neighborhood relationship allows logical direct communication in a unit disc of 1 km radius. The deployment possibilities and network architecture are summarized in Table 2. The actual deployment scheme is controlled by three parameters described in Table 3, indicating respectively: the fraction of LoRa devices whose computation is hosted on the edge rather than on the cloud (\(P_{e}\));  
Figure 6: Abstract architecture of the experiment, graphical elements share the semantics of Figure 1c, with some additional elements: red dashed lines represent platform-level MQTT communications; small antennas identify thin hosts (LoRa motes); large antennas are LoRa gateways, houses depict situated thick devices, and vertical gray rectangles symbolize edge servers. The green circle with a B marks a MQTT broker, which can be deployed on edge servers as in the figure, or in the cloud. the fraction of smart thermostats whose computation is hosted on the local device rather than on the cloud (\(P_{l}\)); and whether the MQTT broker is hosted on the edge or on the cloud (\(B\)). Changing the values of such parameters generates a new deployment, with its own performance and price tradeoffs: we exercise our approach by showing that the business logic is unaffected by such change. The DingNet simulator takes care of realistically simulating LoRaWAN network interactions and delays, while other communications are simulated with a refined version of the network model proposed by EdgeCloudSim [72]. More precisely, the communication delay (\(D\)) is a function of a propagation delay \(d\), the message size \(s\), and the channel data rate \(b\): \(D=d+s/b\). Since all communications in our system are mediated by an MQTT broker, we consider delays and data rates all relative to communications from and to that broker. In particular, we assume the data rate of the broker to be \(1 Gb/s\), and we compute the propagation delay \(d\) considering the actual network path the data needs to travel, summing the individual contributions of each communication link. We account separately for end devices Internet access delay, e.g., due to Wi-Fi or LTE (\(d_{a}\)); communication delays between cloud and edge (\(d_{cc}\)), edge servers (\(d_{ee}\)), and cloud services (\(d_{cc}\)). Actual delay values are free \begin{table}
\begin{tabular}{l c c c c c} \hline \hline
**Device Type** & **Sensors (\(\sigma\))** & **Actuators (\(\alpha\))** & **Behavior (\(\beta\))** & **State (\(\kappa\))** & **Communication (\(\chi\))** \\ \hline \multicolumn{6}{c}{MQTT broker on edge server} \\ \hline LoRa mode & D & D & E/C & E/C & broker’s host \\ Thermostat & D & D & D/C & D/C & broker’s host \\ \hline \multicolumn{6}{c}{MQTT broker on cloud service} \\ \hline LoRa mode & D & D & E/C & E/C & broker’s host \\ Thermostat & D & D & D/C & D/C & broker’s host \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Deployment configurations under simulation. D indicates that the component can be deployed on the local device directly, E that it can get deployed on edge, and C on cloud. Behavior (\(\sigma\)) and state (\(\kappa\)) components must be located onto the same host (device-device, edge-edge, cloud-cloud).