# Bloom Filter Approach for Autonomous Data Acquisition in the Edge-Based MCS Scenario +
## 4 Results and Discussion
### Evaluation of BF Algorithm  
One of the main characteristics of our decentralized MCS ecosystem is that it suppresses redundant and possibly irrelevant data readings by using the BF structure to deactivate some of the workers. However, this is achieved at the expense of filter control messages. Therefore, in this section, we first overview the messages exchanged between workers (i.e., their mobile devices) and ME hosts in our solution and then evaluate the proposed algorithm on a real-world dataset. As already stated in Section 3.2, an ME host is deployed in an MGRS area of 10 square kilometers and maintains BFs for all _km_ MGRS areas under its responsibility. It is aware of all user requests (tasks) and workers in the area. Whenever a worker moves to a neighboring _km_ MGRS area, it will send an _announce_ message to the corresponding ME host and receive an _assign_ message as a reply if at least one task is assigned to a worker, and it will start a data acquisition process and _submit_ results to the ME host until its BF membership test reports a positive match. In case the corresponding ME host determines that the submitted result is redundant (i.e., it has already received all required data readings in the meantime), it will send a BF _update_ message to the worker who submitted this result. Additionally, a BF maintained by the ME host is periodically _reset_ and delivered to the potential workers in the area. Therefore, the total number of exchanged messages equals the sum of all messages explained above (see Equation (7)):  
\[M_{MEC}=M_{ann}+M_{ass}+M_{sub}+M_{BFupdate}+M_{BFreset}, \tag{7}\]  
where \(M_{MEC}\) is the total number of messages that are exchanged within our MCS ecosystem, \(M_{ann}\) is the number of _announce_ messages, \(M_{ass}\) is the number of _assign_ messages, \(M_{sub}\) is the number of _submit_ messages, \(M_{BFupdate}\) is the number of BF _update_ messages, and \(M_{BFreset}\) is the number of BF _reset_ messages in the system. Next, we observe the possible energy savings achievable with our approach compared to the baseline approach when all results produced by workers are transmitted to the ME hosts. Given that the energy consumption is in a linear relationship with the number of generated messages, the savings can be calculated as the percent decrease in the number of transmitted messages generated by our solution as compared to all produced results (see Equation (8)):  
\[Saving_{MEC}=\frac{M_{allResults}-M_{MEC}}{M_{allResults}}, \tag{8}\]  
where \(Saving_{MEC}\) is the energy savings, \(M_{allResults}\) is the number of all produced results that are transmitted in a traditional baseline MCS system, and \(M_{MEC}\) is the total number of messages that are exchanged within our MCS ecosystem. We analyze the behavior of our solution concerning parameters \(m_{worker}\), \(m_{MEC}\), and _window_, where \(m_{MEC}\) indicates a required number of results (of the same type) per _small_ MGRS area of 100 m\({}^{2}\) under the authority of an ME host, \(m_{worker}\) indicates the number of results that a worker needs to submit per each _small_ MGRS area of 100 m\({}^{2}\) before updating its BF, and _window_ indicates duration of the observation time slot in which a BF structure on the ME host is valid prior to reset (i.e., a day is divided into sequential independent time windows with a fixed duration, and upon the end of each time slot, a BF structure is reset). The initial parameter configuration is shown in Table 1. Note that the number of all produced results, as well as the number of _announce_ messages, are obtained from the dataset, while the default values chosen for \(m_{worker}\), \(m_{MEC}\), and _window_ are hypothetical. The actual values for these three parameters in a real-world case would depend on the geographical configuration of a city, its population distribution, user mobility, and implemented application.