copyright 2021, hema naga sai sudha jagarlapudi

Sky Caching Assistedk-Anonymity in Spatial Querying

by

Hema Naga Sai Sudha Jagarlapudi, B.Tech

A Thesis

In

Computer Science

Submitted to the Graduate Facultyof Texas Tech University in

Partial Fulfillment ofthe Requirements for

the Degree of

MASTER OF SCIENCE

Approved

Dr. Sunho LimChair of the Committee

Dr. Michael E. Shin

Dr. Mark SheridanDean of the Graduate School

May, 2021

Texas Tech University,Hema Naga Sai Sudha Jagarlapudi, May 2021

Acknowledgments

Coming from a society in which parents play a very important and decisive

role in their children‘s lives, I have been fortunate to haveparents that support and

encourage me to be independent and do things that I think are best for me. Though

it has not always been easy for them, there was never any deficit in the faith that they

placed in my decisions and my capabilities. And for that, I will forever be indebted to

them. I know that both of them have always strived to give me the best. I am what I am

today because of their thousand unseen sacrifices.

I feel nothing but gratitude for how my thesis advisor, Dr. Sunho Lim, guided

me throughout my research and for all the insightful inputs he has given me. Though

I might have been a pain to deal with at times, I thank him for not giving up on me.I

wouldn‘t have made it here without his patience, kindness, and most importantly the

unrelenting efforts he puts in to help his students. I am extremely grateful for all of his

advice that has helped me academically and professionally.I would also like to express

my gratitude to Dr. Michael Shin for being my committee member, for seeing merit in

my work, and for approving my thesis.

It is such a blessing to have friends that stood by my side in every hour of

need.Though the time zones make it very hard for us to keep in touch, they were al-

ways there for me when I needed it the most. I can not thank you all enough for your

unconditional love and for being so generous. Your efforts in helping me stay motivated

and looking out for me will never go forgotten.

I owe my success to all of the above people who have made such a positive

impact in every aspect of my life and I thank you all from the bottom of my heart.

ii


Table of Contents

Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ii

Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v

List of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vi

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1 Spatial Cloaking . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2 Privacy-preserving Caching . . . . . . . . . . . . . . . . . . . 5

3. Privacy-Preserving Spatial Querying and Sky Caching . . . . . . . . . 6

3.1 Research Motivation . . . . . . . . . . . . . . . . . . . . . . 6

3.1.1 Frequent Queries. . . . . . . . . . . . . . . . . . . . . . . 6

3.1.2 Obsolete User Query Probability. . . . . . . . . . . . . . . 6

3.1.3 Attack-Prone Peer-to-Peer Queries. . . . . . . . . . . . . . 7

3.2 System and Threat Models . . . . . . . . . . . . . . . . . . . 7

3.3 Basic Query Operation with k-Anonymity . . . . . . . . . . 9

3.4 Drone-Assisted Query and Cache Operations . . . . . . . . 9

3.5 Analysis of Drone-Assisted Location Privacy. . . . . . . . . 12

3.5.1 Location Obfuscation. . . . . . . . . . . . . . . . . . . . . 12

3.5.2 Cloaking Area . . . . . . . . . . . . . . . . . . . . . . . . 12

4. Performance Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.1 Simulation Testbed. . . . . . . . . . . . . . . . . . . . . . . . 15

4.2 Simulation Results . . . . . . . . . . . . . . . . . . . . . . . . 16

4.2.1 Cache hit ratio . . . . . . . . . . . . . . . . . . . . . . . . 16

4.2.2 Number of contacts to LBS. . . . . . . . . . . . . . . . . . 21

iii


4.2.3 Convex hull area. . . . . . . . . . . . . . . . . . . . . . . 23

5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

iv


Abstract

As smartphones are prevalent and resource-rich,users can freely query any point-

of-interest (POI) and enjoy diverse location-based services (LBS) deployed in infras-

tructure-based wireless networks. However, users often trade their location privacy

with services by sharing their location information with a LBS server, without knowing

whether the server can be trusted. In this thesis, we proposea privacy-aware spatial

query scheme and its corresponding operations with the support of a flying drone. The

basic idea is that both user and its drone conduct a query operation collaboratively

using an extended k-anonymity. We also propose cache admission control schemes

to efficiently cache the queried results into the storage of user and/or drone. Since

both caches of user and drone can virtually form an aggregatecache, a decision as to

whether to cache the queried results depends not only on the user itself, but also on the

drone. The location privacy of user is analyzed and measuredin terms of cache hit and

size of convex-hull,consisting of dummy locations residedwithin the cloaking areas of

user and drone. We conduct extensive simulation experiments using the OMNeT++

for performance evaluation and comparison.The simulationresults show that the pro-

posed drone-assisted approach can improve location obfuscation and extend cloaking

area significantly.

v


List of Figures

3.1 (a) User’s location query to LBS (b) Dummies within cloaking area . . 8

3.2 (a) User-drone communication (b) Drone mobility arounduser . . . . . 10

3.3 A pseudo code of our proposed drone-assisted query operations. . . . . 13

4.1 Query interval vs. CHR for different caching strategies. . . . . . . . . 17

4.2 Query interval vs. CHR : Forward caching - threshold≥ 1 . . . . . . . 18

4.3 Query interval vs. CHR : Forward caching - threshold> 1 . . . . . . . 18

4.4 Query interval vs. CHR - Switched caching - threshold≥ 1 . . . . . . 19

4.5 Query interval vs. CHR - Switched caching - threshold> 1 . . . . . . . 20

4.6 Local and Remote hits for Forward caching. . . . . . . . . . . . . . . 21

4.7 Local and Remote Hits for Switched caching. . . . . . . . . . . . . . 21

4.8 Query interval vs. NCS - Forward caching - threshold≥ 1 . . . . . . . 22

4.9 Query interval vs. NCS - Forward caching - threshold> 1 . . . . . . . 23

4.10 Query interval vs. NCS - Switched caching - threshold≥ 1 . . . . . . . 23

4.11 Query interval vs. NCS - Switched caching - threshold> 1 . . . . . . . 24

4.12 k vs. Convex hull area . . . . . . . . . . . . . . . . . . . . . . . . . . 24

vi


Chapter 1

Introduction

As smartphones are becoming increasingly popular and resource-rich, users1

run mobile applications (Apps) and enjoy diverse location-based services (LBS), such

as geosocial network, vehicle navigation, or point-of-interests (POIs) query. For exam-

ple, the number of smartphone users in the world is about 3.5 billion in 2020 and it is

more than 45% of the world’s population [1]. In particular, the number of smartphone

users in the U.S. is about 272 million in 2020 and it is expected to grow more than 285

million by 2023 [2]. With jumping on the bandwagon, location-based (or geo-targeted)

mobile marketing is rapidly growing in which e-flyers are broadcasted to the locations

of users wirelessly. Unlike traditional advertisements through the mass media, markets

spent about $17 billion for location-based mobile advertisements and its expenditure

will increase more than $38 billion by 2022 [3]. Over 50% of U.S. brands already use

the location data for business aggressively [4].

When a user requests an LBS, it generates and sends a location-based query

(later in short, query) piggybacked with its current location to an LBS server2. In

this query, it is implicitly assumed that the user has agreedto share its location with

the server without knowing whether the server could be trusted. In fact, more than

65% users reveal or share their location with a weather App [5], trading their location

privacy with the service. Since the server can collect and store incoming queries in

its local storage, it might easily infer a certain level of confidential information by

analyzing and tracing the locations obtained from users, such as home and working

locations, mobility patterns, life preferences, or even health conditions. The server

could also release or sell the confidential information extracted from the queries to

the third parties for mobile marketing without the consensus of users. An adversary

could even compromise the server and misuse the stored queried information. In light

of these, spatial cloaking techniques have been widely usedby considering location

1In this thesis, we use the term user and smartphone user interchangeably to refer to a mobile deviceor a person who carries it.

2From a user’s point of view, an access point (AP) or base station (BS) is transparent to an LBS serverand thus, we use the terms AP (or BS) and LBS server (later in short, server) interchangeably.

1


perturbation, obfuscation, anonymity, and their variants[6], [7], [8], [9], [10], [11].

In this thesis, we propose a novel location privacy-aware spatial querying in

LBS, where a low-altitude unmanned aerial vehicle (UAV) [12], commercially well

known as a drone, is deployed. Drones are increasingly popular to the public because

of their versatility, easy installation and interface, andrelatively low operating cost. We

envision that each individual user will equip with a light-weighted, micro-sized, and

user-friendly drone in a near future, just like a smartphone. Thus, the basic idea is

that a user and its personal drone will collaboratively conduct querying operations and

caching queried results to protect the current location of auser from the server. To the

best of our knowledge, no prior research effort has been devoted to deploying drones

to protect the location privacy of a user in the realm of spatial querying research. Our

contributions are summarized in three-fold:

• We identify three implicit assumptions and potential issues found in prior LBS

literature. Then we propose a location privacy-aware spatial query scheme and

its corresponding operations with the support of a flying drone.

• We also propose three cache admission control schemes to efficiently cache the

query results received from the server into the local storages of user and/or drone:

switched, filtered, and forward. This approach reduces the duplication of cached

copies between the user and drone.

• The location privacy is analyzed and measured in terms of cache hit and size of

cloaking area. The size of the extended cloaking area is measured by the convex

hull consisting of dummy locations.

We develop a customized discrete-event driven simulator using the OMNeT++ [13].

We extensively conduct the performance evaluation and comparison of querying and

caching strategies in terms of the cache hit consisting of local and remote cache hits,

the number of queries sent to the server, and the size of the convex hull. The simulation

results show that higher cache hit and extended cloaking area reduce the chance of user

revealing its current location from the server.

The rest of thesis is organized as follows. The prior work is briefly reviewed and

2


analyzed in Chapter2. We investigate a drone-based spatial query and its corresponding

operations in Chapter3. The proposed scheme is extensively evaluated in Chapter4.

3


Chapter 2

Related Work

2.1 Spatial Cloaking

Location perturbation, obfuscation, anonymity, and theirvariant techniques have

been widely used to protect the location privacy of users from an untrusted server [14],

[15].

The basic idea is that a set of locations including a query issuing user and its

neighbors is sent to the server as a part of query parameters to hide the exact location

of the query issuing user from the server [6], [7], [8]. Location obfuscation schemes

[9], [10], [11] require a set of dummy or fixed locations to form a query. To achieve

k-anonymity, a queried area is often geographically enlarged to encompass at leastk - 1

dummy or real users’ locations. However,k-anonymity may need an extra computation

to create or locatek - 1 additional locations and reduce the accuracy of query results

replied from the server. In [9], a set of dummy locations is generated without deploying

a third-party anonymizer and its corresponding mobility isalso updated based on the

density of queried area to avoid an adversary from tracking the real location. To reduce

the communication cost, the amount of unnecessary queried results received from the

server is limited by using keywords that do not relate to queried location data. In

[16], each user specifies a privacy profile containingk-anonymity requirements and

the minimum size of the cloaking area. The size of the cloaking area can be variable

depending on the distribution of users, indexed by a hierarchy of grid structure. A

virtual circle or square shaped cloaking region is created to include the locations of the

user andk - 1 dummies, in which the distribution of dummy locations canbe controlled

[10]. For example, both locations of user and dummies are aligned in a grid in the

square cloaking region, wherek is assumed as a square number or the smallest square

number less thank, if k is not a square number.

4


2.2 Privacy-preserving Caching

Users cache the LBS data obtained from prior queries in localstorage to answer

potential queries without contacting the server. This caching can reduce the number of

queries sent to the server as well as the probability of revealing users’ exact locations.

A simple distributed location privacy-preserving scheme,called MobiCrowd, is

proposed in [17]. Each user requests its adjacent users of interested LBS data in a peer-

to-peer (P2P) communication manner and then sends a query tothe server, only if the

requested LBS data are not available. The Caché is proposed to improve users’ location

privacy by periodically pre-fetching LBS data of large geographic areas, where users

would most likely visit [18]. Users can either locally access cached LBS data with a

long time-to-live (TTL) according to the preferred POIs or only share a general geo-

graphic region with the server. In the MobiCache [19], both caching andk-anonymity

are combined to improve location privacy by increasing the cache hit ratio on the stored

LBS data. Here, an area is virtually divided into a set of cells andk - 1 dummy loca-

tions are randomly selected from the cells that have never been queried. In [20], the

cache hit ratio can further be improved by carefully selecting dummy locations that ei-

ther have similar query probability or can contribute more for caching. The Cachecloak

plays a role as an anonymizer located between the server and users and replies cached

LBS data to users [21]. When a user generates a query, the Cachecloak sends a pre-

dicted user path that is extended until the path is intersected with other paths to avoid

the user from being tracked by the server. Unlike [9], a third-party anonymizer cloaks

users’ locations and caches their queried results [22], [23]. Since the anonymizer can

be compromised, each user caches extra queried results and shares them with others

through a P2P network, where queried results are extensively searched before queries

are submitted to the server [24].

In summary, as far as our best knowledge, the proposed approach that integrates

aggregate caching andk-anonymity for improving location privacy has not been inves-

tigated in the realm of LBSs.

5


Chapter 3

Privacy-Preserving Spatial Querying and Sky Caching

3.1 Research Motivation

We identify implicit assumptions and potential issues on prior location privacy-

preserving approaches and their querying operations.

3.1.1 Frequent Queries

When a user sends a query to a server, it often generates a set of dummy loca-

tions resided within its cloaking area to hide its current location from the server. Upon

receiving queried results from the server, the user answersthe query and caches queried

results in its local storage. Due to the blind caching or lackof cache management mech-

anism for the queried results, the user tends to send more queries to the server. This can

increase the chance of the user revealing its current location because it sends multiple

queries to the server frequently.

3.1.2 Obsolete User Query Probability

A set of dummy locations can be selected based on the previousquery history.

A queried area is virtually divided into a set of rectangle cells and each cell has a user

query probability [25]. A set of cells having the same or similar query probabilities is

chosen as dummy locations to achieve the maximum entropy. Since the query probabil-

ities are time-varying, however, it is hard (if it is not impossible) for each user to keep

the most updated query probabilities in the area. Prior userquery probability sharing

approaches can be deployed. For example, the server can periodically disseminate the

user query probabilities or local APs can collect and broadcast them. However, the ap-

proaches require a non-negligible computing and communication overhead and a local

AP can even easily be compromised by an adversary.

6


3.1.3 Attack-Prone Peer-to-Peer Queries

To achievek-anonymity, a query issuing node often queries the locations from

its adjacent nodes to collectk - 1 dummy locations to hide its real location. In this

approach, there is an implicit assumption that each node will collaboratively forward

and share the query result and location information, resulting in another location pri-

vacy issue. Since the query is disseminated to the network inan ad hoc manner [19],

[20], public key infrastructure (PKI) based cryptography tools can be deployed to avoid

an eavesdropping attack from the adversary. However, an adversary can also conduct

a denial-of-service (DoS) attack to interfere any on-goingcommunication, such as a

selective forwarding attack [26].

3.2 System and Threat Models

Users carry a wireless and mobile device (e.g., smartphone)equipped with an

on-board Global Positioning System (GPS) and freely move inthe network under a

mobility model, such as random waypoint. Users are aware of the current location

and generate a spatial query for a POI that is closely locatedto their current location.

When a user receives a query result from a server, it stores the query results in its local

storage. In this thesis, we assume that each user is able to control a programmable and

micro-sized drone wirelessly.

To partially assist a query operation, the drone is able to take off and land back

after completing a mission and even fly toward a specific location in an autonomous

mode [27].

The drone is basically equipped with a wireless communication device and a

geographical position system (GPS). The drone can also attach any device for detection

depending on a query mission, such as a camera, sensor, or radar.

Due to the inherent resource constraints, however, the drone has limited comput-

ing power, memory storage, and battery power. The drone can be affected by weather

(e.g., wind) and may not correctly navigate to the location requested by the user.

A server connected with the infrastructure is located between users and their

launching drones. The server relays ongoing communications and answers the queries

7


��

��

��

�

(a)

��

��

��

��

��

(b)

Figure 3.1. (a) User’s location query to LBS (b) Dummies within cloakingarea

generated either from users or drones. When a user generatesa query, an anonymizer

located between the user and server can be deployed to generate or collect a set of

dummy locations to hide the user’s real location by using a peer-to-peer communi-

cation with other users. The anonymizer is often assumed to know and store users’

location information. Thus, we do not deploy the anonymizerin LBSs because this

third-party anonymizer could be compromised by an adversary. The server could also

be compromised by the adversary and behave maliciously. Since the server receives all

queries from users and stores their corresponding locationinformation, it can conduct

an inference attackby extracting side information and deduce users’ location informa-

tion. In addition, the adversary could intercept any on-flying packet in the network. A

set of network components and its basic query operation are shown in Subfig.3.1(a).

8


3.3 Basic Query Operation with k-Anonymity

When a user generates a query for a POI, it checks its local cache if the queried

result is available to answer the query. We consider a staticPOI that is stationary and

never changes its location in a short period, such as a gas station, restaurant, museum,

hospital, etc. [28]. If the queried result is not found in the cache, the user sends the

query to a server. The query contains the user’s current location (e.g., (x, y)), k - 1

dummy locations, a queried POI (P OIqry), and a query area (r), wherek is meant tok-

anonymity. To prevent the server from inferring the exact location of the user, the user

randomly generatesk - 1 dummy locations and mix them with their current location.

As depicted in Subfig.3.1(b), a set of dummy locations is generated within a virtual

circle, cloaking area. In this thesis, the size of the cloaking area is the same as the

user’s communication range. We limit a query range to searchthe queried POI in the

network because the queried POI located far away from the user may not be useful.

Thus, we set the size of the query range to the same size as the user’s communication

range. As the cloaking area increases, the dummy locations can be distributed widely

in the network. The server becomes harder to infer the exact location of the user. Since

the size of the cloaking area is the same as the query area in this thesis, however, the

number of queried POIs replied from the server to the user canbe increased. This can

increase network traffic and some of queried POIs may not be useful. Both cloaking

and query areas should not be increased blindly.

When the server receives a query from a user (ui), pqry,i [(x, y)k, P OIqry, r], it

repeatedly searches the queried POI that are resided withinthe query area for eachk

location. The server collects the locations of queried POI,piggybacks them to a query

reply, prpy,i [(x, y)P OIqry,k], and send it back to the user as shown in Subfig.3.1(b).

Upon receiving the query reply from the server, the user extracts a queried result to

answer the query and caches the queried result in its local storage.

3.4 Drone-Assisted Query and Cache Operations

In this thesis, we deploy a drone to assist a query operation as well as protect

the location privacy of user from a server.The basic idea is that the drone helps the user

in generating a set of dummy locations to confuse the server in identifying and tracing

9


��

��

��

(a)

��

��

(b)

Figure 3.2. (a) User-drone communication (b) Drone mobility around user

the exact locations of user. Also both user and drone judiciously cache the received

queried results to reduce the number of queries sent to the server. Since both caches of

user and drone can virtually form an aggregate cache, a decision as to whether to cache

the queried results depends not only on the user itself, but also on the drone. Here, we

consider two types of cache hit: a local cache hit or a remote cache hit. A local cache

hit occurs when the queried data item is available in the user’s local cache. A remote

cache hit implies that the queried data item is available in the drone’s local cache.

First, a drone can communicate with a user and server as depicted in Subfig.

3.2(a). Both drone and user can communicate directly if they arelocated within their

communication ranges.When the drone becomes out of the communication range of

user, it can still communicate with the user through the server indirectly. A communi-

cation range of drone may vary depending on a capacity of wireless device attached.

In this thesis, we assume that both communication ranges of drone and user are same.

As shown in Subfig.3.2(b), the drone moves under a circular mobility model. As the

user moves, the drone flies around the user by keeping a distance between them. The

drone can play a role as a dummy user and hide the real user fromthe server. A set of

mobility models can also be applied to the drone, such as a linear, zig-zag, or random.

Second, when a user (ui) generates a query that cannot be answered by its local

10


cache, it can either send the query to the server or forward the query to a drone (di). If

the user randomly decides to forward the query to the drone, it generatesk - 1 dummy

locations and piggybacks them to the query including its current location. Upon receiv-

ing the query, the drone searches its local cache and repliesa query result to the user

directly, if cached. If not, the drone also generatesk′ dummy locations within its cloak-

ing area as shown in Subfig.3.2(b). The drone-generated dummy locations can be part

of or added to thek - 1 dummy locations that the user has originally generated. Then

we can have several variants in selecting the number of dummylocations. For exam-

ple, the drone can randomly choosek dummy locations including the current location

of user out ofk + k′. To clearly see the impact of number of dummy locations, we use

the combinedk + k′ dummy locations for query. The drone piggybacks the dummy

locations to the query and sends it to the server,pqry,i [(x, y)k+k′, P OIqry, r]. When

the server receives the query, it collects the locations of queried POI that are resided

within the query area for eachk + k′ location, piggybacks them to a query reply,prpy,i

[(x, y)P OIqry,k+k′], and send it back to the drone. The server in fact does not know

whether the query is originally generated and sent either from the user or drone. Thus,

the drone can play a role as an another user and hide the real user from the server.

Third, when the drone receives the query reply, a cache admission control

(CAC) is triggered to decide whether the drone caches and forwards the queried re-

sults in its local cache and to the user, respectively. In this thesis, we propose three

CAC schemes to clearly define which POI location is cached in the user and/or drone:

switched, filtered, and forward. Since the drone has an inherent resource constraints, it

caches only a part of the queried results in its local storage. The basic ideas is that we

try to cache as many queried results as possible, while trying to avoid too many dupli-

cation in both user and drone to increase accessibility. A rationale behind this approach

is to reduce the number of queries sent to the server that ultimately helps the location

privacy of user. In the switched CAC, both user and drone cache all the queried results

in their local storage alternatively. If the drone have cached all the queried results, it

will forward the next queried results received from the server to the user for caching.

Unlike simple switched CAC, the filtered CAC allows the droneto selectively caches

the query results that are not currently stored in the cache.The rest of query results that

are not cached in the drone is forwarded to the user. This approach is to avoid cache du-

11


plication between user and drone. In the forward CAC, the drone forwards all the query

results to the user. The user caches the query results and triggers a cache replacement

policy when the cache becomes full. When a cached data item isevicted, the user sends

it to the drone. Upon receiving the evicted data item, the drone caches it in its local

storage. If the cache becomes full at the drone, the drone also triggers a cache replace-

ment policy and removes an evicted data item permanently. Here, the least recently

used (LRU) is deployed for cache replacement policy. The proposed query operations

are also summarized in Fig.3.3.

3.5 Analysis of Drone-Assisted Location Privacy

We analyze the location privacy assisted by a drone in two aspects: location

obfuscation and cloaking area. We also measure the locationprivacy in terms of cache

hit and size of convex hull.

3.5.1 Location Obfuscation

A user randomly forwards a query either to the drone or serverif the queried

data item is not available, local cache miss. The drone also sends the received query

to the server if the queried data item is not available either, remote cache miss. The

number of queries sent to the server is proportional to cachemiss. In this thesis, we

deploy three CAC schemes to increase both local and remote cache hits by reducing

the duplicated cached copies stored in both user and drone. Higher cache hit not only

reduces the number of queries sent to the server but reduce the chance of user revealing

its current location from the server.

3.5.2 Cloaking Area

When a user forwards a query to a drone, it piggybacksk dummy locations in-

cluding its current location to the query.k - 1 dummy locations are randomly generated

within the user’s cloaking area. When the drone receives thequery, it also generates

k′ dummy locations resided within its cloaking area. Since thedrone moves around

the user by following a circular mobility, the cloaking areas of both user and drone are

12


Notations:• ui, di: A query issuing node and its drone, respectively.• cu,i, cd,i: A local cache ofui anddi, respectively.• pqry,i [(x, y)k+k′ , POIqry, r]: A query packet is generated byui, containingk + k′ dummylocations includingui’s current location, a queried POI (POIqry) and a query area (r).• prpy,i [(x, y)P OIqry,k+k′]: A query reply packet containing the query results ofPOIqry.⋄ Whenui generates a query that can be answered by a query result (rqry),

if rqry ∈ cu,i

Userqry to answer the query and exit;else

Generatek - 1 dummy locations;Send the query to the drone,pqry,i [(x, y)k, POIqry, r];

⋄ Whendi receives a query fromui,if qryr ∈ cd,i

Sendqryr back toui and exit;else

Generatek′ additional dummy locations;Send the query to the server,pqry,i[(x, y)k+k′ , POItype, r];

⋄ When the server receives a query either fromui or di,SearchPOIqry and send a query reply back either toui or di, prpy,i [(x, y)P OIqry,k+k′];

⋄ Whenui receives a query reply fromdi,if cache admission control = forward

Send the evicted victim LRU data item todi when cache is full;if cache admission control = filtered

Filter the results, store 50% of filtered results in cache andsend 50% todi;if cache admission control = switched

Cache the results in cache incu,i;⋄ Whendi receives a query reply from the server or user,

Conduct a cache admission control; /* switched, filtered, orforward */Cache the queried results incd,i and forward them toui accordingly;if cd,i is full

Evict a victim data item fromcd,i; /* LRU */

Figure 3.3. A pseudo code of our proposed drone-assisted query operations.

partially overlapped (see Subfig.3.2(b)). In this thesis, we deploy a convex hull algo-

rithm to approximate the size of combined cloaking areas. A convex hull is the smallest

convex polygon containing a given set of points in a two-dimensional area. We use the

Graham-Scan based method [29] to construct a convex hull. Given randomly generated

k + k′ dummy locations, we initially choose a location with the minimum x- and y-

13


coordinates and sort the rest of locations based on the angleto the location in counter-

clockwise order. Then the initially chosen location is connected with a location with

the minimum angle. We incrementally keep connecting the locations only if they are

located to the counterclockwise of the line connecting previous two locations.This con-

vex hull becomes an area wherek + k′ dummy locations are resided. The bigger the

size of convex hull is, the harder the server guesses the location of user. Note that the

size of convex hull is directly proportional to the cloakingarea where dummy locations

are distributed. If dummy locations are widely spread out inthe area, the size of convex

hull increases.

In summary, our drone-assisted querying approach can improve location obfus-

cation and extend cloaking area. Location obfuscation can be enhanced because both

user and drone can generates a query and a set of dummy locations collaboratively. The

server can be confused in identifying and tracing the exact locations of user. An cloak-

ing area of user can be extended by including a cloaking area of drone.A set of dummy

locations can be widely distributed in the network. This would take more time for the

server to infer the exact location of user.

14


Chapter 4

Performance Evaluation

We evaluate and compare the performance of proposed querying strategies by

changing key simulation parameters.

4.1 Simulation Testbed

We developed a customized discrete-event driven simulatorusing the OMNeT++

[13]. A 2,000× 2,000 m2 rectangle network is deployed, wheren users are uniformly

distributed. Each user is equipped with an on-board GPS receiver and multiple network

interface cards and communicates with a server and drone simultaneously. A user com-

municates with its drone wirelessly using a wireless local area network (WLAN), e.g.,

IEEE 802.11. The radio transmission range (r) is assumed to be 150 m. The two-ray

ground propagation channel is assumed with a data rate of 2 Mbps. We deploy a sim-

ple CSMA/CA based medium access for the link layer. For the sake of simplicity, we

assume that both user and drone have the same communication range and use a sym-

metric link. Both user and drone also communicate with the server directly through an

infrastructure network, e.g., a cellular network.

A set of POIs is uniformly distributed in the network, where the total number

of POIs is set to 100 with a single type. The random waypoint mobility model [30] is

deployed to simulate the user mobility with a speed 1 m/s and apause time between

0 to 50 sec. Under the mobility model, the user travels towarda randomly selected

destination in the network. After the user arrives at the destination, it pauses for the

predetermined period of time and travels toward another randomly selected destination.

The drone follows one of the drone mobility models with a speed v m/s as shown in

Fig. 3.2.

The number of dummy locations (k) is set betweenk′ andk′′. Both user and

drone have their own local storage to cache queried results.The size of cache of user

and drone is set tocsize andc′

size, respectively. A set of major simulation parameters is

summarized in Table4.1.

15


Table 4.1.Simulation Parameters

Parameter Values

Network size 2000 × 2000 (m2)Number of users 5Number of POIs 100Types of POIs 1User communication range100, 150 (m)User velocity 1 m/secUser mobility type Random WaypointUser cache size 40Drone velocity 6 m/secDrone cache size 20Pausing time 0 to 50 (sec)Data transmission rate 2 MbpsAnonymity (k) 6 to 22Cloaking area radius 100, 150 (m)Query interval 5 to 500 (sec)Simulation Time 2,50,000 seconds

4.2 Simulation Results

We consider three major performance metrics in the network:cache hit ratio,

the number of queries sent from user to LBS (i.e., cache miss ratio) and the convex hull

area.

4.2.1 Cache hit ratio

Here, we measure the cache hit ratio (CHR) as query interval of a user increases.

Query interval decides how frequently a user generates a location query. As the query

interval increases, the number of queries generated by a user decrease and the time gap

between consecutive queries increases. Hence, the cache hit ratio should decrease. In

our approach, we run simulations for long enough and hence the cache hit ratio does

not drop down drastically.

Fig. 4.1 shows the results of cache hit ratio for a user with and without drone.

When drone is included, we consider the performance of threecaching strategies when

CR is 150 m and threshold> 1. Switched cache yielded best results of all three mech-

anisms. In filtered caching, focus is on avoiding duplicatesand share the filtered set

16


100 200 300 400 500

Query interval

0

10

20

30

40

50

60

70

80

90

100

Cac

he h

it ra

tio (

in %

)

Without droneWD-SwitchedWD-FilteredWD-Forward

Figure 4.1.Query interval vs. CHR for different caching strategies

of results between user and drone such that each node stores half of the filtered set.

Here, drone cache size is half of that user since drone is not as resource rich as a user’s

smartphone. Hence, storing 50% of results (if any) results in drone’s cache getting

filled up sooner than that of user. In such cases, empty slots at user’s end are not uti-

lized properly. There are also cases where the user/drone might not have anything to

forward after filtering. Hence, this caching technique doesnot bring much change in

cache hit ratio. In forward caching, the drone stores the LRUitems evicted by the user

and it is less likely that a user accesses these LRU items again in near future. Hence,

the performance of forward caching lies in between the filtered caching and switched

caching. In switched caching, the user and drone take turns in storing the LBS results.

It is similar to a case where there are two users who are collaborating in storing results

almost equal number of times. Hence, the cache hit ratio improved and is best of all

three mechanisms.

Figs.4.2and4.3show the results of cache hit ratio vs query interval for thresh-

old ≥ 1 and threshold> 1 by following Forward caching strategy.

17


0 100 200 300 400 500

Query interval

0

10

20

30

40

50

60

70

80

90

100

Cac

he h

it ra

tio (

in %

)

CR=100m without droneCR=100m with droneCR=150m without droneCR=150m with drone

Figure 4.2. Query interval vs. CHR : Forward caching - threshold≥ 1

0 100 200 300 400 500

Query interval

0

10

20

30

40

50

60

70

80

90

100

Cac

he h

it ra

tio (

in %

)


Figure 4.3. Query interval vs. CHR : Forward caching - threshold> 1

Figs.4.4and4.5show the results of cache hit ratio vs query interval for thresh-

old ≥ 1 and threshold> 1 by following switched caching strategy. Here, the threshold

decides the condition of cache hit. For example, threshold> 1 implies user must find

more than one POI from its cache to be considered as cache hit and to satisfy the gen-

18


erated location query. Since, we have only one type of POI, user is most likely to have

more than one POI within its query area. To efficiently use thecached POI items and

to obtain as many POI results as possible we use threshold. The results show that the

cache hit ratio improved when drone is included because drone’s cache acts like an

extended cache to a user and can contribute to cache hits. Drone also generatesk′ dum-

mies which can yield more POI data that can be used to answer future queries of the

user.

0 100 200 300 400 500

Query interval

0

10

20

30

40

50

60

70

80

90

100

Cac

he h

it ra

tio (

in %

)


Figure 4.4.Query interval vs. CHR - Switched caching - threshold≥ 1

19


0 100 200 300 400 500

Query interval

0

10

20

30

40

50

60

70

80

90

100

Cac

he h

it ra

tio (

in %

)


Figure 4.5.Query interval vs. CHR - Switched caching - threshold> 1

Figs. 4.6 and4.7 show the local and remote hit contribution of a user and its

drone when threshold> 1 and cloaking radius is 150 m. As mentioned earlier, forward

caching makes a drone store the LRU items of a user which are less likely to be accessed

in near future and hence the remote hit contribution is less when compared to switched

caching. In switched caching, user and drone take turns in storing LBS results which

makes user and drone take almost equal share of chances in storing LBS results. Hence,

the remote hit contribution is almost equal to local hit contribution.

20


5 10 25 50 100 200 300 500

Query interval

0

10

20

30

40

50

60

70

80

90

100

Cac

he h

its (

in %

)

Local HitsRemote Hits

Figure 4.6.Local and Remote hits for Forward caching

5 10 25 50 100 200 300 500

Query interval

0

10

20

30

40

50

60

70

80

90

100

Cac

he h

its (

in %

)

Local HitsRemote Hits

Figure 4.7.Local and Remote Hits for Switched caching

4.2.2 Number of contacts to LBS

Here, we measure the number of contacts user made to LBS (NCS)as the query

interval increases. When user generates a location query, its either a cache hit or a cache

21


miss. In case of local and remote cache miss, drone forwards the user’s query to LBS.

Hence, number of contacts user made to LBS is measured in terms of cache miss ratio.

As query interval, cache hit ratio decreases and a greater number of contacts could be

made to LBS.

Figs.4.8and4.9show the results of query interval vs number of contacts to LBS

using forward caching. Fig4.10and4.11show the results of query interval vs number

of contacts to LBS using switched caching. When drone is included, the number of

contacts made to LBS reduced which is in turn reducing the exposure of user’s location

the LBS server. Drone can contribute to satisfying more userqueries using its cached

contents. Of the two caching strategies which resulted in less number of contacts,

switched caching worked better than forward caching.

0 100 200 300 400 500

Query interval

0

10

20

30

40

50

60

70

80

90

100

Use

r co

ntac

ts to

ser

ver

(in %

)


Figure 4.8. Query interval vs. NCS - Forward caching - threshold≥ 1

22


0 100 200 300 400 500

Query interval

0

10

20

30

40

50

60

70

80

90

100

Con

tact

s to

ser

ver

(in %

)


Figure 4.9.Query interval vs. NCS - Forward caching - threshold> 1

0 100 200 300 400 500

Query interval

0

10

20

30

40

50

60

70

80

90

100

Use

r co

ntac

ts to

ser

ver

(in %

)


Figure 4.10.Query interval vs. NCS - Switched caching - threshold≥ 1

4.2.3 Convex hull area

Even though user has a predefined value of cloaking radius to construct a cloak-

ing area, it is the dummy distribution that finally decides the obfuscated area of user.

Hence, the convex hull region is the area formed by the dummies. With the help of

23


0 100 200 300 400 500

Query interval

0

10

20

30

40

50

60

70

80

90

100

Use

r co

ntac

ts to

ser

ver

(in %

)


Figure 4.11.Query interval vs. NCS - Switched caching - threshold> 1

6 10 14 18 22

k

0

10

20

30

40

50

60

70

80

90

100

Con

vex

Hul

l are

a (in

%)

Without drone, k+k' at userWith drone, k(user) +k'(drone) & k'=k

Figure 4.12.k vs. Convex hull area

drone and its contribution of dummies to the user’s query, user will be able to obtain

dummies outside it’s cloaking area and this can increase theconvex hull area. As a

result, it would be more difficult for the LBS to find user’s location. Fig. 4.12shows

results fork vs. convex hull area where cloaking radius =150 m andk′ = k. With-

out drone, user generatesk + k′ dummies. With the help of drone, user generatesk

24


dummies and drone contributesk′ dummies.

25


Chapter 5

Conclusion

In conclusion, we have proposed drone-assisted query operations to enhance

the privacy of user while enjoying the LBS services. We have also investigated three

caching strategies filtered,forward and switched. We foundthat drone is enhancing

the privacy of the user by addingk′ dummy locations to increase the anonymity and

also increasing the cloaking area of the user significantly thereby improving location

obfuscation. When LBS receives a location request, it doesn’t know if the request is

sent by user or drone. This results in LBS getting more confused. In addition to this,

drone’s cache acts as an extended cache to user thereby improving the cache hit ratio.

This reduces the user’s location exposure to LBS.

This approach can be extended by testing various mobility models with drone

and having a strategy based dummy selection to see the affecton cache hit ratio and

cloaking area.

26


BIBLIOGRAPHY

[1] How many smartphones are in the world?, Jan 2020,

https://www.bankmycell.com/.

[2] Number of smartphone users in the United States, Feb 2020,

https://www.statista.com/.

[3] Local Mobile Ad Spending, Feb 2018, http://www.biakelsey.com/.

[4] LBMA 2017 Global Location Trends Report, March 2017, https://thelbma.com//.

[5] Location Based Services : Expected Trends and Technological Advancements,

June 2017, http://geoawesomeness.com/).

[6] C. Y. Chow, M. F. Mokbel, and X. Liu, “A Peer-to-Peer Spatial Cloaking Algo-

rithm for Anonymous Location-based Service,” inProc. ACM GIS, 2006.

[7] R. Shokri, P. Papadimitratos, and G. Theodorakopoulos,“Collaborative Location

Privacy,” inProc. IEEE MASS, 2011.

[8] B. Niu, X. Zhu, W. Li, and H. Li, “EPcloak: An Efficient and Privacy-Preserving

Spatial Cloaking Scheme for LBSs,” inProc. IEEE MASS, 2014.

[9] H. Kido, Y. Yanagisawa, and T. Satoh, “An Anonymous Communication Tech-

nique using Dummies for Location-based Services,” inProc. Int’l Conf. on Per-

vasive Services, 2005.

[10] H. Lu, C. S. Jensen, and M. L. Yiu, “PAD: Privacy-Area Aware, Dummy-Based

Location Privacy in Mobile Services,” inProc. ACM Int’l Workshop on Data En-

gineering for Wireless and Mobile Access, 2008.

[11] T. Hara, A. Suzuki, M. Iwata, Y. Arase, and X. Xie, “Dummy-Based User Loca-

tion Anonymization Under Real-World Constraints,”IEEE Access, vol. 4, pp. 673

– 687, 2016.

[12] P. Fahlstrom and T. Gleason,Introduction to UAV systems. John Wiley & Sons,

2012.

27


[13] OMNeT++ Documentation and Tutorials, http://www.omnetpp.org/documentation/.

[14] K. G. Shin, X. Ju, Z. Chen, and X. Hu, “Privacy Protectionfor Users of Location-

Based Services,”IEEE Wireless Communications, vol. 9, no. 1, pp. 30–39, 2012.

[15] M. Wernke, P. Skvortsov, F. Durr, and K. Rothermel, “A Classification of Location

Privacy Attacks and Approaches,”Personal and Ubiquitous Computing, vol. 18,

no. 1, pp. 163–175, 2014.

[16] M. F. Mokbel, C. Y. Chow, and W. G. Aref, “The New Casper: Query Processing

for Location Services without Compromising Privacy,” inProc. VLDB, 2006.

[17] R. Shokri, G. Theodorakopoulos, P. Papadimitratos, E.Kazemi, and J. Hubaux,

“Hiding in the Mobile Crowd: LocationPrivacy through Collaboration,” IEEE

Trans. on Dependable and Secure Computing, vol. 11, no. 3, pp. 266–279, 2014.

[18] S. Amini, J. Lindqvist, J. Hong, J. Lin, E. Toch, and N. Sadeh, “Caché: Caching

Location-Enhanced Content to Improve User Privacy,” CMU CyLab Technical

Report CMU-CyLab-10-019, Tech. Rep., 2010.

[19] X. Zhu, H. Chi, B. Niu, W. Zhang, Z. Li, and H. Li, “MobiCache: When k-

anonymity Meets Cache,” inProc. IEEE GLOBECOM, 2013.

[20] B. Niu, Q. Li, X. Zhu, G. Cao, and H. Li, “Enhancing Privacy through Caching in

Location-Based Services,” inProc. IEEE INFOCOM, 2015.

[21] J. Meyerowitz and R. R. Choudhury, “Hiding Stars with Fireworks: Location

Privacy through Camouflage,” inproc. ACM MOBICOM, 2009.

[22] Y. Chen, J. Bao, W. Ku, and J. Huang, “Cache Management Techniques for Pri-

vacy Protected Location-based Services,” inInt’l Workshop on Privacy-Aware

Location-based Mobile Services (PALMS), 2008.

[23] S. Zhang, K. Choo, Q. Liu, and G. Wang, “Enhancing Privacy through Uniform

Grid and Caching in Location-based Services,”Future Generation Computer Sys-

tems, vol. 86, pp. 881–892, 2018.

28


[24] K. Jung and S. Park, “Collaborative Caching Techniquesfor PrivacyPreserving

Location-based Services in Peer-to-Peer Environments,” in IEEE Int’l Conf. on

Big Data (BIGDATA), 2017, pp. 4497–4506.

[25] B. Niu, Q. Li, X. Zhu, G. Cao, and H. Li, “Achieving k-anonymity in Privacy-

Aware Location-Based Services,” inIEEE INFOCOM, 2014.

[26] C. Pu, S. Lim, B. Jung, and J. Chae, “EYES: Mitigating Forwarding Misbehavior

in Energy Harvesting Motivated Networks,”Computer Communications, vol. 124,

no. 2018, pp. 17 – 30, 2018.

[27] Crazyflie 2.0, https://www.bitcraze.io/crazyflie-2/.

[28] B. Jung, S. Lim, J. Chae, and C. Pu, “VRSense: Validity Region Sensitive Query

Processing Strategies for Static and Mobile Point-of-Interests in MANETs,”Com-

puter Communications, vol. 116, no. 2018, pp. 132–146, 2018.

[29] R. Graham, “An Efficient Algorithm for Determining the Convex Hull of a Finite

Planar Set,”Information Processing Letters, vol. 4, no. 1, pp. 132–133, 1972.

[30] D. B. Johnson and D. A. Maltz, “Dynamic Source Routing inAd Hoc Wireless

Networks,” inMobile Computing, Kluwer 1996, pp. 153–181.

29


Appendix

IMPLEMENTATION

In this appendix, we cover the implementation part and evaluate the perfor-

mance of the proposed approaches. We use OMNeT++ discrete event simulator and

simuLTE framework to simulate our system on windows 10 machine.

Besides simuLTE, we need to install an additional frameworkcalled INET for

running our simulations. These files can be directly downloaded from the web and

imported into the OMNeT++ platform. For implementing the modules we used OM-

NeT++ 5.5.1, inet 4.2.2 and simuLTE 1.2.0 versions. There are two commands for

installing the platform which are as follows:

$ ./configure

$ make

We have .cc files to design the modules and respective .h file for each designed

module. These modules are used to define the behavior. The network is set up in .ned

file and parameters are set in .ini file. We present our pseudocode in the below files.

In our approach, we consider only one type of POI but the code is implemented in a

flexible way and doesn’t need to be changed even when we consider more than one POI

type.

1. GENERATE LOCATION QUERY :

In this method, user generates a request for POI data within its query area and checks its

local cache first. If it’s a cache miss, then it sends the request to drone. When threshold

is greater than one, user might have one item each that can completely satisfy the user’s

query. Hence we used "cachedItems" to keep track of that count.

For example: If user finds 0 items then drone must find more thanone POI. If user finds

one POI item then drone must one more item to satisfy user’s query.

void BaseClient::generateLocationQuery() {

30


//Get POI Types parameter value from ini file

int poiTypes = getParentModule()->getParentModule()

->par("poiTypes").intValue();

// Randomly select one type of POI

int rNum = intuniform(0, poiTypes - 1);

int cachedItems = 0;

// Check local cache and if value is true then it’s a cache miss, contact Drone

bool value = checkLocalCache(rNum, queryRadius, cachedItems);

if (value) {

checkDroneCache(rNum, cachedItems);

}

if (resetFlag == true) {

totalQueries++;

emit(totalQueriesSignal, totalQueries);

}

}

2. CHECK LOCAL CACHE

In this method, user checks its local cache. User maintains amap ( here locationCache

) that contains poiType as key and a map of poiData as value. This poiData map in turn

contains key as poiId and poiLocation as value. So, user firstloads the poiData map of

certain poiType it needs. Now it checks if there are any POI within its query radius that

could satisfy its query based on threshold set. If it finds an item, then its updates the

timeStamp of that item to current simTime() to indicate thisitem is recently accessed.

If it’s a cache miss, request is sent to drone.

bool BaseClient::checkLocalCache(int type, int radius, int &cachedItems) {

// Extract POI data of specified type from local cache to a temporary map

std::map<int, inet::Coord> tempMap = locationCache[type];

// If map is empty then it is a cache miss

31


if (tempMap.empty())

return true;

// Get the user’s current location

Coord myCoord = ltePhy_ -> getCoord();

int threshold = 0;

for (std::map<int, inet::Coord>::iterator it = tempMap.begin();

it != tempMap.end(); it++) {

// Find POI within query radius of user

if (it->second.distance(myCoord) <= radius) {

//Update time stamp against this POI after accessing it

timeStamps[it->first] = simTime();

threshold++;

}

}

cachedItems = threshold;

if (threshold > 1) {


localHit++;

emit(localHitSignal, localHit);

}

// False implies item found in local cache, there’s no need tocontact the LBS

return false;

}

tempMap.clear();

// true implies item not found in cache, request must be sent to LBS

return true;

}

3.CHECK DRONE CACHE

This method is invoked when its a cache miss at user side. Userconstructs a query and

sends it to the drone. Just in case, if its a cache miss at drone, then drone will attach its

share of dummies to this query and forward it to LBS.

void BaseClient::checkDroneCache(int poiType, int cachedItems) {

32


numDroneSent++;

Packet *packet = new Packet();

// Construct payload

const auto &payload = makeShared<RequestPacket>();

payload->setPoiType(poiType);

payload->setCount(cachedItems);

payload->addTag<CreationTimeTag>()->setCreationTime(simTime());

payload->setQueryRadius(queryRadius);

payload->setSrcId(findContainingNode(this)->getId());

std::vector<Coord> userK;

// select dummies randomly in user’s cloaking region

uniformDummySelection(userK);

payload->setDummyLocations(userK);

packet->insertAtBack(payload);

L3Address destAddr = L3AddressResolver().resolve(

findContainingNode(droneltePhy_)->getFullName());

socket.sendTo(packet, destAddr, destPort);


emit(sentToDroneSignal, numDroneSent);

}

}

4. PROCESS PACKET

This method is executed when user receives a packet either from drone. Drone could

either send remote cache hit results or forward the LBS results. To distinguish this, we

have a flag. If it’s an LBS result forwarded by drone, based on the caching strategy

being followed the results are either directly store in cache or filtered. In forward and

switched caching, user simply caches the LBS results. In filtered caching, user first

filters the results and then stores 50% of filtered results ( ifany ) in its local cache.

void BaseClient::processPacket(Packet *msg) {

if (checkIfHeaderType<DroneResponse>(msg)) {

const auto &myPacket = msg->popAtFront<DroneResponse>();

33


// If cache hit flag is true then the results are from drone cache. Else those are

from LBS.

if (myPacket->getCacheHit() == true) {

std::map<int,Coord> poiResults = myPacket->getPoiInfo();


remoteHit++;

emit(remoteHitSignal, remoteHit);

}

}

else {

// If the caching used is forward or switched, then simply cache the

results received

storeResultsInCache(myPacket->getPoiInfo(),

myPacket->getPoiType());

// If the caching used is filtered, then filter the results firstand then

store 50%, share rest 50%

// filterResults(myPacket->getPoiInfo(), myPacket->getPoiType());


numServerResultsReceived++;

emit(rcvdServerResultsSignal, numServerResultsReceived);

}

}


numDroneReceived++;

emit(rcvdFromDroneSignal, numDroneReceived);

}

}

delete msg;

}

5. STORE RESULTS IN CACHE – FILTERED AND SWITCHED

This method is executed when user wants to store POI results locally while using fil-

tered or switched caching approaches. Here, user first loadsthe poi data map of respec-

34


tive POI type. Before inserting a POI record, it checks if this record is already present.

If so, only the time stamp against it is updated because this poi is received as part of

LBS results at that instance. If that item is not already present, user simply stores it and

a timestamp is associated with it. If the cache size is full, user deletes one LRU item

from its cache and then inserts this new record.

void BaseClient::storeResultsInCache(std::map<int, Coord> poiInfo, int poiType) {

std::map<int, Coord> locationTable = locationCache[poiType];

for (std::map<int, inet::Coord>::iterator it = poiInfo.begin(); it != poiInfo.end();

it++) {

// If the poi id is not already present in location cache only then we store it.

if (locationTable.find(it->first) == locationTable.end()) {

Coord pos = it->second;

//if cache is full then delete an LRU item from local cache andthen insert

new record

if (timeStamps.size() >= cacheSize) {

getSpaceinCache();

}


locationCache[poiType][it->first] = pos;

}

// if the poi id is already present, update it’s timestamp

else {


}

}

}

6. STORE RESULTS IN CACHE – FORWARD

This method is executed when user wants to store POI results in case of forward

caching. When user cache is full, the LRU item is added to a mapand then deleted

locally. Finally, this map is sent to drone.

35


void BaseClient::storeResultsInCache(std::map<int, Coord> poiInfo, int poiType) {


std::map<int, Coord> dronePoiMap;

std::map<int, int> dronePoiType;

for (std::map<int, inet::Coord>::iterator it = poiInfo.begin();

it != poiInfo.end(); it++) {


Coord pos = it->second;

if (timeStamps.size() >= cacheSize) {

Coord poiPos;

int poiType;

int poiId;

// deletes an LRU item from local cache and returns details ofit.

getSpaceinCache(poiPos,poiType,poiId);

dronePoiMap[poiId] = poiPos;

dronePoiType[poiId] = poiType;

}


locationCache[poiType][it->first] = pos;

}

else {


}

}

// send LRU items to drone

if (dronePoiMap.size() > 0) {

sendPoiDataToDrone(dronePoiMap, dronePoiType);

}

}

7. PROCESS PACKET AT DRONE

This method is executed when drone receives a packet either from user or from server.

If the packet from user is a request then drone local cache is checked or forwarded to

36


LBS if its a cache miss. If the packet from user contains LBS results forwarded by user,

drone must simply store them just like user doesn. In all cases, when the packet received

from user the behavior is same. But the response from server is handled differently in

3 different caching approaches.

• In case of forward caching, the LBS results received from server are sent to user

as it is. User stores these results in its cache and if cache isfull, it will send LRU

items to drone.

• In case of filtered caching, the LBS results are first filteredand then filtered set is

forwarded to user. User will filter the results and send 50% offiltered results ( if

any ) to drone.

• In case of switched caching, drone stores once and forwardsthe next time. Drone

and user take turns in storing the results. This switching isdone based on a flag

at drone.

void DroneForUser::processPacket(Packet *msg) {

//Request from user

if (checkIfHeaderType<RequestPacket>(msg)) {


numUserReceived++;

emit(rcvdFromUserSignal, numUserReceived);

}

const auto &userRequest = msg->popAtFront<RequestPacket>();

// Check local cache and if it’s a cache miss, send request to LBS.

checkLocalCache(userRequest->getPoiType(),

userRequest->getQueryRadius(), userRequest->getDummyLocations(),

userRequest->getCount());

}

// IN CASE OF FORWARD CACHING:

//Response from server

else if (checkIfHeaderType<ResponsePacket>(msg)) {


37


numServerReceived++;

emit(rcvdFromServerSignal, numServerReceived);

}

const auto &myPacket = msg->popAtFront<ResponsePacket>();

// for forward caching, send the LBS results directly to user.

// the flag false is to distinguish drone cache results from LBS results when user

receives it.

sendPoiDataToUser(myPacket->getPoiMap(), myPacket->getPoiType(), false);

}

// received a set of results from user ( LRU items of user in case of forward caching)

else if (checkIfHeaderType<DroneResponse>(msg)) {

const auto &myPacket = msg->popAtFront<DroneResponse>();

storeResultsInCache(myPacket->getPoiInfo(), myPacket->getPoiType());

// If its forward caching, drone receives LRU POI items of user which could

be of different type, then

// storeResultsInCache(myPacket->getPoiInfo(),

myPacket->getPoiTypeMap());

}

delete msg;

}

IN CASE OF FILTERED CACHING:






}


std::map<int, inet::Coord> mainPoiMap = myPacket->getPoiMap();

std::map<int, inet::Coord> filteredMap;

int poiType = myPacket->getPoiType();


// Filter the LBS results and forward the filtered set to user.

38


for (std::map<int, inet::Coord>::iterator it = mainPoiMap.begin();it != mainPoiMap.end();

it++) {


filteredMap[it->first] = it->second;

}

else {


}

}

if (filteredMap.size() > 0) {

sendPoiDataToUser(filteredMap, myPacket->getPoiType(), false);

}

}

IN CASE OF SWITCHED CACHING:






}


// for switched caching - based on a flag, user and drone take turns in storing

if (myPacket->getPoiMap().size() > 0)

if (sendFlag == false)

sendPoiDataToUser(myPacket->getPoiMap(),myPacket->getPoiType(), false);

sendFlag = true;

}

else {

storeResultsInCache(myPacket->getPoiMap(),myPacket->getPoiType());

sendFlag = false;

}

}

}

39


8. SERVER SIDE - PROCESS PACKET

This method is executed when server receives a request packet from drone. Server

pulls up POI data within query area of each location attachedin query and sends it in

response.

void BaseServer::processPacket(Packet *pk) {

numReceived++;

emit(packetReceivedSignal, pk);

const auto &myPacket = pk->popAtFront<RequestPacket>();

if (myPacket != NULL) {

Packet *packet = new Packet();

const auto &payload = makeShared<ResponsePacket>();

int poiType = myPacket->getPoiType();

std::vector<int> v = myMap[poiType];

std::vector<inet::Coord> dummyLocations = myPacket->getDummyLocations();

int sizemm = 0;

std::vector<std::vector<int» finalPoiIds;

std::map<int, inet::Coord> mainPoiMap;

for (int i = 0; i < dummyLocations.size(); i++) {

Coord dummyPos = dummyLocations.at(i);

std::vector<int> poiIds;

for (int x : v) {

Coord pos = ltePhysPoi[x];

if (pos.distance(dummyPos) <= myPacket->getQueryRadius()) {

if (mainPoiMap.find(x) == mainPoiMap.end()) {

mainPoiMap[x] = ltePhysPoi[x];

}

poiIds.push_back(x);

}

}

finalPoiIds.push_back(poiIds);

}

40


payload->setSequenceNumber(myPacket->getSequenceNumber());

payload->setPoiIds(finalPoiIds);

payload->addTag<CreationTimeTag>()->setCreationTime(simTime());

payload->setPoiMap(mainPoiMap);

payload->setDummyLocations(myPacket->getDummyLocations());

payload->setPoiType(myPacket->getPoiType());

L3Address destAddr = L3AddressResolver().resolve(

findContainingNode(ltePhysUser[myPacket->getSrcId()])

->getFullName());

packet->insertAtBack(payload);

socket.sendTo(packet, destAddr, localPort);

numSent++;

emit(sentPkSignal, numSent);

}

delete pk;

}

9. Configuration file

The following is the omnetpp.ini file which is used for running our simulations.

[General]

network = Base

sim-time-limit = 250000s

*.numUes = 5

*.numEnbs = 1

*.numPoi= 100

*.poiTypes = 1

*.User[*].numApps = 1

*.User[*].app[0].typename = "BaseClient"

*.User[*].app[0].queryRadius = 100m

41


*.User[*].app[0].destPort = 100

*.User[*].app[0].destAddresses = "server"

// Destination address can be changed even before sending the packet.

*.User[*].app[0].cacheLimit = 40

*.User[*].app[0].communicationRange =100m

*.User[*].app[0].anonymity = ${k=3,5,7,9,11,13,15,17}

/* Same settings apply to drone */

/* User drone mobility */

*.User[*].mobilityType = "RandomWPMobility"

*.User[*].mobility.typename = " RandomWPMobility"

*.User[*].mobility.initialX = uniform(0m, 2000m)

*.User[*].mobility.initialY = uniform(0m, 2000m)

*.User[*].mobility.speed = 1mps

*.Drone[0].mobilityType = "SuperpositioningMobility"

*.Drone[0].mobility.typename = "SuperpositioningMobility"

*.Drone[0].mobility.numElements = 2

*.Drone[0].mobility.element[0].typename = "AttachedMobility"

*.Drone[0].mobility.element[0].mobilityModule = "∧.∧.∧.User[0].mobility"

*.Drone[0].mobility.element[1].typename = "CircleMobility"

*.Drone[0].mobility.element[1].cx = 0m

*.Drone[0].mobility.element[1].cy = 0m

*.Drone[0].mobility.element[1].r = 100m

// In inet superpositioning, the standard is to give speed as-.

*.Drone[0].mobility.element[1].speed = -6mps

// Same settings apply to other user and drones

42

copyright 2021, hema naga sai sudha jagarlapudi

Documents