# Resource Indexing and Querying in Large Connected Environments
## 5 Proposed Approach
### Contribution Insights  
In order to detail our proposal, we first present the adopted topology of the connected environment network. Figure 3 shows a sub-environment (extracted from our motivating scenario) that is supervised by one orchestrator \(d_{o}\), having visibility over the related set of sensing nodes deployed. Selected according to its high-capacity (the selection process of super nodes, such as orchestrators, gateways, and cluster heads, is performed in the clustering step and will be detailed in a dedicated study), the orchestrator receives as input the clustered sub-environment details. Then, it generates the sub-environment global index \(gi\). The latter can respond to requests but cannot be seen as a routing table. In other words, \(gi\) shows the communication between the devices, but it does not show the physical routing of the message. This implies, before assigning a device to a corresponding zone, that we make sure (through the clustering process) that there is a physical link with the related cluster head. After generating \(gi\), the orchestrator will be ready to send to each cluster head its corresponding local index \(li\). In our motivating scenario, \(d4\) was chosen as the sub-environment gateway (during the environment clustering process). Since this device does not interfere in the global index generation, we did not include it inside the global index generation algorithm.  
Sensing devices have specific coverage zones (cf. Definition 4). In essence, given a sensor deployment strategy and an overall number of sensors, \(len(D)\), the sub-environment will contain zones that are covered by one or more sensors, as well as uncovered zones.  
The example depicted in Figure 3 shows the sub-environment with the six zones of our motivating scenario (4 are covered: \(z_{1},z_{2},z_{3},z_{4}\) and 2 uncovered: \(z_{5},z_{6}\)). We recall that a sensing device (1) has one location and can communicate with its cluster head, (2) has a local index, and (3) has a limited storage capacity (e.g., a sensing device can store 4 index entries when its capacity is equal to 4, and (4) cannot store the entire global index. As a result, the orchestrator generates the index entries to be sent to cluster heads for local indexing or in-zone distribution.  
Users can then query the environment by submitting queries (\(q\)) directly to sensing devices having a specific location stamp \(l\) or a zone \(z\). The devices check their local indexes, to decide if they can answer or need to forward to another device. When the desired device is found, it will return its observation \(o\) with its corresponding timestamp \(t\). Similarly, queries can be submitted to the orchestrator, which then checks its global index to forward the query to the corresponding devices. The latter case will not be discussed further in this paper.  
The main contribution of our proposal relies on determining the right distribution of index entries that need to be stored locally on devices. In other terms, which local index entries are to be stored on each device in order to adequately respond to queries in a timely fashion and maximize the query answering potential over the connected environment zones, while adapting to the different sensing device storage capacities.  
In the following, we focus on the algorithm that generates and distributes the resources' indexes. It is important to note that in what follows, we will not address how the environment has been clustered, challenges related to sensor deployment, nor device-to-device communication. They will be addressed in separate works. In what follows, we will use the example in Figure 4 to show the main steps of our algorithms. The illustrative example uses four devices, four covered zones, and two uncovered zones.