# Bloom Filter Approach for Autonomous Data Acquisition in the Edge-Based MCS Scenario +
## 4 Results and Discussion
### Evaluation of BF Algorithm
First, we analyze the influence of parameters \(m_{MEC}\) and \(window\) on the amount of sent data when the parameter \(m_{worker}\) has a fixed value of 1 (i.e., a worker updates its BF structure after submitting the first result in the _small_ MGRS area). In other words, Figure 8 depicts the cumulative number of results that were sent by all workers in our distributed system when an MCS service deployed on the ME host requires up to 15 results per each _small_ MGRS area, and each worker is instructed to submit only one result per _small_ area. As expected, the results show that with a longer \(window\) duration (i.e., the BF validity period), the number of sent results will be lower because the time between two consecutive filter resets is longer, and workers discard more results. In particular, when the filter reset period is 1 min, the percentage of _useful_ data sent by all workers is between 18% and 19%, while with the reset period of 120 min, this percentage drops to values between 11% and 15.5%, depending on the required number of workers per _small_ MGRS cell. We can see that when \(m_{MEC}\) has the value of 1 (i.e., ME host requires only one result per every 100 m\({}^{2}\)), the amount of generated data is the lowest, because hosts update their BF immediately after they receive the first result for the _small_ MGRS area. In contrast, for bigger \(m_{MEC}\), hosts expect to receive more results and update their filters less often, which leads to a higher amount of data sent by workers. When the filter validity period is 1 min, the influence of the parameter \(m_{MEC}\) on the percentage of sent data is not significant because there are not many workers located in the same area in such a short time interval, and the amount of redundant data is similar regardless of the required amount of data per _small_ MGRS area. On the other hand, when filter reset occurs every 120 min, it is very likely to find more workers in the same area who can submit data during the observed period, which results in greater differences in the percentage of sent data for different values of the parameter \(m_{MEC}\). For example, when \(m_{MEC}\) is 1, the required amount of data on the ME host is collected very soon. Suppose other workers come to the same area in the remaining period. In that case, they will be instructed not to produce measurements because they receive an updated version of a BF (i.e., the host has already inserted received results in the filter), while when \(m_{MEC}\) is 15, more workers who send an announcement later in the time slot will also receive an initial (empty) version of the BF, and the ME host will receive more data readings. Overall, we can conclude that more than 80% of data readings produced by all workers in the system are never sent to edge hosts even in the worst-case scenario when the filter validity period is only 1 min, and MCS service requires up to 15 results per each _small_ MGRS area. That is a significant reduction in the number of transmitted data compared to a baseline approach where all produced data readings are sent to the cloud server. Next, we observe trends in energy savings (8) with respect to parameters \(m_{MEC}\), \(m_{worker}\), and \(window\). We analyze the number of all transmitted messages in our distributed MCS architecture compared to the baseline approach in which all produced data readings would be sent to the edge hosts. We modify two parameters for each analysis, while the third parameter is fixed to one of the default values given in Table 1. First, in Figure 9, we show how parameters \(m_{MEC}\) and \(window\) influence the savings when workers are instructed to transmit only one data reading per 100 m\({}^{2}\). In general, the results indicate that the advantage of our approach drops when increasing the value of parameter \(m_{MEC}\) because the required number of workers per _small_ MGRS area increases, consequently leading to a greater number of submitted results per cell, as already shown in Figure 8. If