## 4 Architecture
### Hybrid IoT Infrastructure with Balanced Processing Between Cloud and Edge  
In this second architecture, there is the addition of some components that have been repositioned in an environment architecturally closer to IoT devices (Figure 4). Figure 3: This figure allows you to visually understand what happens if an offset is not properly scheduled depending on the number of participants. In the first case, all the spawns are overlapped. In the second case, however, the spawns are perfectly ordered depending on the number of participants (in this specific case, nine). Figure 2: This diagram shows the flow and the error-handling mechanisms of the first reference architecture to send data, reconstruct a 3D model, check collisions and trigger events, involving the client, object creation, data reconstruction, and the cloud server. Even the devices themselves have been imagined to be computationally more efficient and capable of performing more complex operations than just sending and receiving data. The \"Collision\" component placed in the cloud functions as a monitor that can view all user locations thanks to the \"Client\" component at any instant and trigger events based on these locations. An example could be limiting movements to an area or triggering an event if multiple users are in the same location. \"Cloud Storage\" and \"Local Storage\" components were introduced, both dedicated to data management and storage. The choice to separate the storage function from the server compared to the previous architecture was made to allow collaboration between the \"Cloud Storage\" and the \"Local Storage\". In particular, through a specific algorithm, the saving of objects intended to be used in the scenario, both in AR and VR, is managed. This algorithm aims to optimize the loading and unloading of data from the server, keeping the most frequently used objects local. In detail, if the object has reached a usage threshold and space is available, it is saved. If there is no space, the least used item is removed and replaced with the new one. Figure 5.  
Finally, synchronization between multiple users has been divided into two components, one managed in the cloud and the other on the edge. The \"Collaboration\" component creates and manages the different lobbies. Specifically, it is responsible for processing requests based on the number of users and managing peer-to-peer connections. It instructs the \"Server Cloud\" to create new lobbies to optimize participant collaboration when necessary. Concerning the workflow of the various components, this is described in the component  
Figure 4: This figure depicts a component diagram of the second reference architecture, in which the computation is balanced between the cloud and the edge. Figure 5: The sequence in this image shows an algorithm for local memory management in which an object is saved or replaced based on the number of uses and maximum memory capacity. diagram in Figure 6, except the \"Collision\" component, since it has the same function as \"Object Collider\" in the previous architecture. For this reason, it was preferred to hide it so as not to make it hard to read. As you can see from Figure 6, the operation is as follows: starting from the client, it first requests to enter the lobby. If no lobby is active, the _Server Cloud_ component is asked to create one. After carrying out this request, different objects can be inserted into the AR and/or VR scene through a request made via the client, first to the local storage, and in the cases where it does not possess the requested asset, to the cloud storage. During the entire session, the positions of the assets are continuously updated and monitored by the _Collision_ component in the cloud, which takes care of unleashing triggers based on the type of collision. Thus, the second architecture represents a balanced compromise between cloud and edge processing. Some operations are handled locally in this context, easing network traffic and optimizing bandwidth usage.