## 5 Deployment Independence in Action: Aggregate Computing over DingNet
### Aggregate Computing over DingNet  
We now define our cyber system and the mapping of pulverized components with the platform layer given by DingNet.  
The cyber system, which we target when defining the business logic, is composed of several logical devices with computation, sensing, actuation, and communication capabilities. Logical components have a position in space, and their neighborhoods are defined based on geographical proximity, within some arbitrarily chosen range (although, in principle, any policy for neighborhood definition could be used). The set of sensors and actuators may differ on each device. All logical devices have computational capabilities. Every logical device is _bound_ to a situated platform device of the simulated system, inheriting its spatial situation.  
The pulverized logical system is then mapped over the platform system as follows (see also Table 1). Sensing and actuation systems \(\sigma\) and \(\alpha\) are always deployed on the host bound to the logical node. This is true for both _thin_ and _thick_ hosts. Behavior (\(\beta\)) and state (\(\kappa\)) components cannot get allocated on thin hosts: their deployment targets are restricted to the cloud, edge servers, and thick situated devices. To simulate realistic situations, we allow \(\beta\) and \(\kappa\) components of LoRa motes associated devices to be located solely on edge servers or on the cloud, and we let \(\beta\) and \(\kappa\) associated with localized thick devices (e.g., handhelds) to be hosted locally or on the cloud. Impractical deployments, (e.g., \(\beta\) and \(\kappa\) on a device backing the LoRa mote [70]) although possible in principle, are deemed as unrealistic with the current state-of-the-art technologies, and thus excluded from the present analysis. Moreover, as introduced in Section 4, we note that all logical devices share the same behavior: \(\beta_{i}=\beta_{j}\lor i,j\) where \(i,j\) are logical device identifiers. This is part of the semantics of aggregate computing, and may vary for other pulverizable computational models. We give an example program of logical devices for the evaluation case in Section 6. Finally, communication components \(\chi\) are all hosted on a single device, the MQTT broker, that can be either an edge server or a service on the cloud. This choice was made for the sake of simplicity and without loss of generality: in fact, even though in principle \(\chi\) components could be located on diverse hosts, and communication among them could be wired to any level 7 network protocol, we share in fact the same MQTT broker supporting the  
\begin{table}
\begin{tabular}{l c c c c c} \hline \hline
**Device Type** & **Sensors (\(\varepsilon\))** & **Actuators (\(\alpha\))** & **Behavior (\(\beta\))** & **State (\(\kappa\))** & **Communication (\(\chi\))** \\ \hline Thin host & D & D & E/C & E/C & E /C \\ Thick host & D & D & D/E/C & D/E/C & E/C \\ \hline \hline \end{tabular}
\end{table}
Table 1: Available choices for pulverized component deployment for different device types in the extended DingNet simulator. 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. The simulator supports only configurations where behavior and state are located onto the same type of host (e.g., edge-edge). The devices can be _thin_ (e.g., LoRa mote) or _thick_ hosts (e.g., handhelds).  
Chirpstack architecture. Figure 6 summarizes the aggregate system as deployable within the DingNet extended simulator.