## 5 Use Case Description with the OGC SensorThings Standard
### General Model of the Prototype Based on SensorThings  
The proposed architecture consists of sensors from different manufacturers communicating with their respective connectors and a server for data collection. In particular, the architecture is composed of:  
* An instance of **FROST-Server** for data collection;
* An instance of **Mosquito** [95] as the MQTT broker;
* Sensors with different payloads;
* A Java application to simulate the behaviour of the connectors. In particular, for the connectors, the FROST client libraries were used for the creation of entities and communication with the server. The advantage of using these libraries is the abstraction of the HTTP POST operations, which is entirely handled by the library, greatly simplifying both the creation of new entities and their retrieval from the server. Finally, regarding the server, an instance of FROST-Server was chosen using the Docker distribution provided directly by the authors [96]. For correct operation, each DATASTREAM entity associated with a device must be identified by a unique name. Furthermore, within the OGC SensorThings database, the entities THING associated with the devices, OBSERVED PROPERTY, SENSOR, and FEATURE OF INTEREST (for example, LOCATION) associated with the DATASTREAM must be preloaded. The use of internal databases within the device has the advantage of being able to add and update information related to it without having to modify the connector's code. In the prototype, the internal database was implemented using SQLite [97], which allows for the creation of small-sized databases suitable for our purpose and also provides libraries for interfacing. However, the proposed architecture can easily integrate other production-grade databases, such as PostgreSQL, MySQL, MongoDB (NoSQL), and others. The first operation the client performs once it receives the message is to identify the device from which it was sent. To do this, the client must know the unique ID associated with the device. This ID can either be sent by the sensor itself or added by the gateway in cases where the sensor model does not include the information by default. Subsequently, the connector queries its internal database to find out which entity in the database is associated with the device. The entity associated with the device is an instance of the THING entity in the OGC SensorThings model. It is necessary to know the THING entity to which the device is associated because the related DATASTREAMS can be derived from it, enabling the publication of the related sensor observations. Next, we move on to the phase of \"translating\" the information: this operation is specific to each sensor model and characterizes each connector. Later, we will present examples that will address this operation more specifically; for now, we will limit ourselves to describing, in general terms, the operations performed by each connector:  
1. The connector extracts the measurement data from the received payload. 2. It interprets the data according to the guidelines provided by the manufacturer. 3. It determines the type of measurement and its values. 4. It searches among the DATASTREAMS associated with the THING entity for the one related to the measurement. 5. If not present, it creates a new DATASTREAM entity with the information available in its database: first, it extracts from the internal database the SENSOR and OBSERVED PROPERTY entities related to the DATASTREAM to be created; subsequently, it extracts the data related to their properties and completes the creation. In the event that one or more SENSOR or OBSERVED PROPERT entities are unavailable, the connector will create new ones using the data available in its database. 6. It publishes a new OBSERVATION linked to the related DATASTREAM, containing the received values, and associates the relevant FEATURE OF INTEREST. The steps related to the creation and linking of the SENSOR and OBSERVED PROPERTY entities are illustrated only in the first example and are subsequently omitted for clarity.