## 4 Architecture
### Decentralized IoT Solution with Prevalent Processing at the Edge  
In our presented architecture, the computational load has been wholly repositioned towards the edge, leaving only storage and synchronization functions to the cloud (Figure 7). Figure 6: This sequence diagram shows the main operations of the second architecture, including lobby creation, asset management, and the interaction between local client storage, the cloud server, and cloud storage. In fact, only two components have been placed within the cloud, which are the cloud server and Global Storage. The former is the heart of the synchronization logic and management of collaborative sessions, supporting crucial operations such as the following:  
* **SyncScene**: Ensures all devices display an updated and synchronized scene version. * **BroadcastUpdate**: Broadcasts changes made to the scene to all participants, ensuring consistency in the shared experience. * **ReceiveInputData**: Processes input received from users to update the state of the scene accordingly. * **DistributeAudio**: Handles the distribution of audio signals among participants, allowing voice interactions within the virtual environment. As for cloud storage, this operates in exactly the same way as defined in the previous architecture and shown in Figure 5. For these reasons, we will not describe it a second time. As for the edge side, this is composed of the main component, the **Visor Component**, which constitutes the interface through which users interact with the augmented reality environment, offering a range of essential features:  
* **OpenCameraSensor**: Activates the camera sensors to integrate virtual elements into the real scene visible to the user. * **InitializeTracking**: Initializes the tracking of the user's movements and position, allowing intuitive interactions with the virtual scene. * **ConnectToServer**: Establishes a connection with the cloud server to access the shared scene and synchronize the experience with other users. * **UpdateScene**: Updates the virtual scene display based on user inputs and updates from the cloud server. * **SendInputData**: Transmits input data to the cloud server, such as movements and selections. * **MoveObject**: Allows users to change the position of objects within the virtual scene. * **InitializeAudio**: Prepares the audio system for user voice communication. * **SendAudio/ReceiveAudio**: Manages the sending and receiving of audio streams, facilitating real-time communication. * **SpawnOtherAvatar**: Generates virtual representations of other users, enriching the shared scene with their virtual presence. The other supporting components are in **Local Storage**, which works similarly to Global Storage (Figure 5). A component called the **Gesture Recognition Module** will be  
Figure 7: This figure shows a component diagram of the third reference architecture, in which most of the operations are shifted to the edge. responsible for interpreting the gestures and associating them with a movement. Finally, the Edge Processing Unit has the task of preprocessing the data to send to the cloud Server. Let us now analyze the interactions between these components by analyzing a communication prototype using a sequence diagram Figure 8.  
This sequence reflects a typical workflow that allows users to share and interact within the same virtual scene superimposed on the real world, highlighting the collaborative capabilities of the application. At the start of the session, User A and User B activate their respective headsets, which begin tracking their movements and position through the _initializeTracking()_ method that calls the **Gesture Recognition Module** component. This is essential to allow the system to interpret and respond to the movements and interactions  
Figure 8: This sequence diagram shows the main operations for synchronizing a scene and sharing audio data between two users (User A and User B), using viewers, cloud servers, gesture recognition modules, and processing units at the edge.