## 3 Basic System Operation
### SBD Routing
GHT routing uses a node as a step unit rather than zone or sector. As a result, it leads to a bit higher traffic causing more congestion and packet loss than those of the DCSMSS \(+\) LEACH and SDS. Figure 12(b) shows that DD's latency grows radically due to the congestion as traffic increases. Since DD uses broadcasting for data querying, it produces excessive message and traffic congestion when the number of queries per batch increases. DCSMSS \(+\) SBD, DCSMSS \(+\) LEACH and SDS have almost similar latency. GHT takes the shortest path and thus it outperforms other approaches when the traffic

Figure 12: (**a**) Latency (sec) and (**b**) total RTS sent. was low but its latency is affected by the congestion caused by the increased traffic with the increase in the number of queries per batch. DCSMSS and SDS schemes do not need to send as many queries as GHT since they rely on neighbor zone or SH to forward queries, thus reducing traffic and congestion. DCSMSS + SBD produces less traffic by realizing the collision avoidance technique (GCA) compare to DCSMSS + LEACH and SDS with Car Pooling. Due to the collision free time slot allocated to SH in the routing layer through GCA, SBD in DCSMSS uses a store and forward technique. However, the overhead that was added due to the store and forward technique is consistent regardless of traffic volume. Hence, it is observed from Figure 13b that SBD's latency outperforms DCSMSS + LEACH and SDS with the increased number of queries per batch. #### 5.2.2 Range Query

This experiment was conducted in order to realize the performance of range query in various scenarios. The network size and number of queries was the same as the previous experiment. In Figure 14a-c, experiments were conducted for four different variations of range query. The range of the queries was varied in such a way so that in case one to four the number of sectors for the target data varies from one to four. For example, DCSMSS + Sector = 2 refers to the case where the target result of the query is to be fetched from two neighbor sectors. Figure 14a shows the average latency of each scenario as a function of number of queries per batch. As expected, the latency increases when the number of target sectors increases. If the target range of a query includes more than one sector all the corresponding SH fetch data from their respective segments and returns the data to the source SH. It is observed that, the latency for all scenarios grows slightly when the number of queries per batch increases except for the scenario DCSMSS + Sector = 4. In the case of DCSMSS + Sector = 4, latency begins to grow sharply when the number of queries increases from four to eight. This happens because of the congestion created due to the high number of reply packets flowing to the source query node from four neighbor sectors in response to a single query. Figure 13: (**a**) Success Rate and (**b**) latency. Figure 14b shows the success rate of each scenario as a function of the number of queries per batch. As expected, the performance of different scenarios is inversely proportional to the number of target sector. It is noted that all approaches falls slightly when the number of queries per batch increases from one to four but they start dropping sharply with the increase of number of queries per batch from four to sixteen. Figure 14c shows the number of discovered data items for each scenario when the number of queries per batch is four. #### 5.2.3 KNN Query

The setting of this experiment was similar to that of the previous experiment. Like the previous experiment, the value of \(k\) in _KNN_ (\(q\), \(k\)) in the four different scenarios was varied in such a way that the target number of sectors varied from one to four. It is observed from Figure 15a that the latency is directly relative to the number of target sectors from which the resultant query is to be fetched. In addition, latency increases for each scenario with the increase in the number of queries per batch.