# FODIT: A Filter-Based Module for Optimizing Data Storage in B5G IoT Environments
## 2 Background
### Filters
For these studies, we collected: timestamp, temperature, humidity, and luminosity data from an Arduino-based device designed to monitor environmental conditions during the transportation and storage of sensitive goods (e.g., food, vaccines). We then performed

Figure 4: Integration of FODIT in Phonendo [25]. three simulations--storing 10,000, 100,000, and 1,000,000 records, respectively--using different IoT storage options: a DB, DaaS, and DLT (see Section 4). Each simulation was executed both with and without the FODIT module to compare performance. It is important to highlight that FODIT stores a label for each data entry, which in our case is a hash of the data. This hash also serves as the identifier for the corresponding data stored in the different storage options. Additionally, to evaluate the handling of redundant data, each simulation included a percentage (4%, 5%, 7%, 8%) of repeated data out of the total stored data. Regarding the query case study, we used the previous simulations and attempted to retrieve (4%, 5%, 7%, 8%) of data that was not stored (e.g., environmental conditions of a device at a specific timestamp). ### Experiments and Results

According to case studies, two experiments were designed: Experiment 1 to minimize redundant data storage and Experiment 2 to optimize data retrieval efficiency. Both were executed on a computer with the following specifications:

* _CPU_: Core(tm) i7-7500U Intel(r) processor 2.70 GHz \(\times\) 4
* _OS_: Ubuntu 22.04.2 LTS
* _Compiler_: gcc 7.4.0
* _Local Databases Manager_: MongoDB 6.0 LTS
* _Cloud Computing Service:_ AWS RDS-PostgreSQL 10.9
* _DLT_: IOTA Tangle [47]

#### 6.2.1 Experiment 1

The experiment involved inserting 10,000, 100,000, and 1,000,000 records into three different storage systems: a DB, a DaaS, and a DLT platform called IOTA [48]. The insertion process was performed both with and without the FODIT module. When conducted without the FODIT module, the process is referred to as classical insertion. First, we analyzed classical insertion in the DB. The initial simulation focused on inserting 10,000 records plus 4%, 5%, 7%, and 8% redundant data. Subsequently, using the FODIT module, only 10,000 records were inserted since it prevents duplicate data insertion. However, the FODIT module's filtering process for detecting duplicates still required computation. For the second and third simulations involving 100,000 and 1,000,000 records, respectively, we followed the same procedure as the first simulation. The process described above for classical insertion in a local DB was also applied to classical insertions in DaaS. Regarding the classical insertion in DLT, the process is a little bit different because it is necessary to incorporate an extra cost associated with the structure used to manage scenarios in which data are sent to the DLT but, in the end, are not recorded in the DLT. Table 3 presents the time required for both classical insertion and insertion with the FODIT module. The table's first column indicates the storage option name, followed by the corresponding data volume. The \"Classical\" column shows the percentage of duplicate data, with the associated insertion time reported for each percentage. The \"FODIT\" column consists of three components: (1) the \"No Duplicates\" sub-column shows the insertion time without duplicate data, (2) the \"Filter\" sub-column displays the time needed for FODIT to build the filter, (3) the \"AuxS\" sub-column presents the time required by the structure used in DLT, and (4) the \"Total\" sub-column represents the sum of these two times. It is important to mention that the time shown pertains to DLT processing. To better compare classical insertion with insertion using the FODIT module, we plotted the time results from Table 3. Figure 5 shows comparative graphs for the local DB, where the classical insertion is represented by a green bar chart, while the insertion with the FODIT module is shown in the blue bar chart.