# Resource Indexing and Querying in Large Connected Environments
## 5 Proposed Approach
### Index Generation Algorithm
In that case, the query is forwarded to a randomly chosen covered zone. In this situation, \(z2\) is chosen. The device located in \(z2\) is device \(d2\), meaning that this device receives the query (step 1). The query is forwarded to \(z3\), since \(d2\) is partially covered by \(d3\) only. The query is forwarded to device \(d3\) (step 2). \(d3\) has an index for \(z5\) leading to forwarding the query to the user, with a response that \(z5\) is an uncovered zone. When a blocked path is faced, a \"no response\" message is returned for the user by the last device reached. This type of query can be used to gather data in order to perform analytics where having missing data is not important. * Retry Queries: Figure 6 shows the cases of retrying queries with a random strategy. In this case, the source zone is \(z4\), and the destination zone is \(z5\). In Figure 6, the query is first sent to \(d4\), which chooses a random device from its index to forward the query. \(d4\) chooses, for instance, to forward it to \(d1\). Since \(d1\) has a capacity of 1, it has no information about any zone except its current zone. As a result, it is no longer possible for \(d1\) to continue forwarding the query, indicating that the path is blocked (even though the device has an index for its gateway, the query is not forwarded to the gateway, since the query is designated for the current sub-environment). Consequently, the query is returned to \(d4\), trying to find another path. The query is re-sent to \(d2\). After \(d2\) receives the query, it forwards it to \(d3\). \(d3\) returns an uncovered zone response to the user. When a blocked path is faced and no more devices are in the current coverage zone, a \"no-response\" message is returned to the user. The following queries are used for model training, reducing missing data and making the preprocessing easier. * Guaranteed queries: Figure 7 presents an example of a guaranteed query. \(z4\) is the source zone and \(z5\) is the destination zone. \(d4\) sends a broadcast request to \(d1\) and \(d2\). \(d1\) is a blocked path, so the query ends here for the first path. For the second path, the query continues until reaching \(d3\), having information about \(z5\). If there is no path that leads to the requested destination, a no-response message is returned. These queries are for high-urgency cases such as fires and natural disasters. * Default queries: Figure 8 demonstrates an example of a default query. Recall that guaranteed and default queries work in almost the same way, since the default querieshave extra parameters (in our case, we consider a minimum capacity equal or greater to 2). The same source/destination zones are used (\(z4\) to \(z5\)). Once \(d4\) receives the query, it broadcasts it to all its index entries that fit the criteria selected. The same process is repeated until the desired destination zone is reached. Notice that the query is not routed to \(d1\), due to its limited capacity, which is insufficient for accommodating a value greater than two. In this example, \(d3\) returns the result (uncovered zone) for the user. A no-response message is returned if no path leads to the requested destination. These queries are designed for high-urgency cases, such as fires and natural disasters, with an emphasis on minimizing the utilization of network resources. Figure 5: One-path queries example. Figure 6: Retry queries example. Figure 7: Guaranteed queries example. ## 6 Experiments

In the upcoming section, we describe a series of experiments carried out to confirm the efficacy of our approach. Through this evaluation, we measured the performance of our approach regarding: (1) the index generation, (2) the index coverage, and (3) the execution of different types of queries. The experiments were executed on a computer system equipped with 16 GB of RAM, a Core i7 CPU, and running the Windows 10 operating system.