# An Efficient Dummy-Based Location Privacy-Preserving Scheme for Internet of Things Services
## 4 Experimental Results and Analysis  
In order to evaluate the performance of the Enhanced-DLP, we designed and implemented comprehensive experiments using the Python 3.5 language environment. All experiments were performed on an Intel i5 2.5-GHz machine with 12 GB RAM and the Windows 10 operating system. Moreover, the scheme run time is measured in terms of CPU time. In the experiment, the service map data of the LBS provider is divided into n \(\times\) n cells and each cell has the same size for IoT users to submit queries. We set a historical query probability in these cells. We set two scenarios to evaluate the performance of our scheme. **Scenario 1**: There are more than \(k\) locations that have the same historical query probability as the user's real location. The Enhanced-DLP will select some dummy locations with the same historical query probability as the user's real location. The dataset is from the NA dataset [13] the North America road network, which contains 175,813 real POIs. **Scenario 2**: Let the user be located in a cell such that there are a few (less than \(k\) but greater than 1) cells which have the same probability as the user's current location. In this scenario, the Enhanced-DLP can choose enough dummy locations which have the same query probability to form a anonymous set for the user. The dataset is from an n \(\times\) n grid map whose cell's historical query probability is randomly generated. We have compared the performance of five schemes (i.e. DLS [8], DLP [9], GridDummy [14], CircleDummy [14], and Optimal) in terms of the run time and the privacy level under various degrees of anonymity. We also compare the probability of query recognition with DLS and DLP under Scenario 2. Figure 2(a),b illustrate the results of the comparison of the degree of privacy protection and run time with the Enhanced-DLP, DLS, DLP, Optimal, GridDummy and CircleDummy scheme in Scenario 1. From the Figure 2(a), we can see that the entropy obtained by all schemes increases continuously when the value of k increases, indicating that the privacy protection capability of all schemes is increasing. The Enhanced-DLP, the DLP, the Optimal, and the DLS scheme have the largest entropy. The reason is that the Enhanced-DLP scheme adopts the enhanced greedy scheme to ensure that the final anonymous set entropy value is the largest. The GridDummy and CircleDummy scheme select dummy locations adjacent to the user's location based on their geographic location, so the GridDummy  
and the GridDummy scheme cannot obtain the maximum entropy, and the obtained entropy is not stable. From the Figure 3b, we can see that the computational cost of the Enhanced-DLP and the DLP scheme increases with the growth of the value of \(k\), but the run time of the Enhanced-DLP is 3.77% lower than the run time of the DLP. The reason is that the Enhanced-DLP adopts an enhanced greedy scheme which has a lower computational cost. In addition, the scheme of generating dumb positions in DLP and enhanced-DLP in this scenario is almost the same. Our work mainly reduces the computational cost of the scheme in the dataset of Scenario 2. The run time of the other schemes can be seen in Table 1 where the DLP and Enhanced-DLP schemes have a shorter time, while the DLS and CircleDummy run times are very long. The run times of CircleDummy and DLS rapidly increase as the value of \(k\) increases. The reason is that the DLS scheme select \(k\) dummy locations by the way of the enumeration scheme which has a high computational cost, and the CircleDummy scheme needs to calculate the angle and distance between all locations and the user location which also has a high computational cost. Figure 4a,b illustrate the results of the comparison of entropy and run time in Scenario 2. In Figure 4a, the entropy obtained by all schemes increases continuously when the value of \(k\) increases. While the entropy of the Enhanced-DLP and the DLP scheme are the same, there are big differences in the computational costs in Figure 4b.