Real-Time Range Query Approximation
by Means of Adaptive Quad Streaming
Simon Keller and Rainer Mueller
University of Applied Sciences, Constance, Germany
Keywords:
Continuous Spatial Range Queries, Mobile Objects, Streaming-based Decentralization, Mobile Environments.
Abstract:
Continuous range queries are a common means to handle mobile clients in high-density areas. Most existing
approaches focus on settings in which the range queries for location-based services are mostly static whereas
the mobile clients in the ranges move. We focus on a category called Dynamic Real-Time Range Queries
(DRRQ) assuming that both, clients requested by the query and the inquirers, are mobile. In consequence,
the query parameters results continuously change. This leads to two requirements: the ability to deal with
an arbitrary high number of mobile nodes (scalability) and the real-time delivery of range query results. In
this paper we present the highly decentralized solution Adaptive Quad Streaming (AQS) for the requirements
of DRRQs. AQS approximates the query results in favor of a controlled real-time delivery and guaranteed
scalability. While prior works commonly optimizes data structures on servers, we use AQS to focus on a
highly distributed cell structure without data structures automatically adapting to changing client distributions.
Instead of the commonly used request-response approach, we apply a lightweight streaming method in which
no bidirectional communication and no storage or maintenance of queries are required at all.
1 INTRODUCTION
Today’s ubiquitous mobile devices in everyone’s
hands and the location sensors they contain lead to
both, demand and potential for location-aware ser-
vices (Kaczor and Kryvinska, 2013). As a con-
sequence of ubiquity, there is an obvious need for
more efficiency in spatial queries in terms of given
QoS parameters. And these parameters certainly de-
pend on the type of the application scenarios con-
sidered. There are countless use cases for applica-
tions, often in the area of nearby business or leisure
which provide mobile users with aggregated informa-
tion out of spatial queries (e.g. gas stations, hospitals,
stores/shopping malls) (Moln
´
ar et al., 2014). In con-
trast to these stationary target objects or clients of a
system, there are mobile ones such as commuters on
a busy train looking for free seats, people requiring
an ad-hoc ridesharing (cab-hailing) in order to man-
age the next two blocks, or firefighters in a smoky
building, forest or disaster event. In these scenarios
the requirement is not to know, who/which are the
next k clients (matching the needs) but which clients
are within a specific range (range query), in our case
within in a geometrical range (spatial range query)
of d
0
meters around a dedicated client. Moreover,
not only are the requested clients mobile (e.g. the
requested firefighter colleagues), which is a contin-
uous spatial range query. Also the requesting clients
or inquirers (e.g., a dedicated firefighter looking for
colleagues in restricted visibility) are mobile. We
call this a dynamic real-time range query (DRRQ)
in which not only the query results but the queries
as such change continuously. The application scenar-
ios behind DRRQs involve a certain degree of unpre-
dictability or spontaneity. We call this class of prob-
lems ad-hoc mobility challenges, which obviously in-
creases the complexity of continuous range queries,
but is much closer to reality nowadays when every-
one and everything is mobile. You can easily trans-
fer the described ad-hoc mobility challenges to other
domains or objects (firefighters, autonomous vehicle
controlling/dispatching, supply chains, business pro-
cesses, etc.). Many range query approaches are re-
stricted to either static objects or static queries (e.g.
(Wu et al., 2004c; Kalashnikov et al., 2002; Xuan
et al., 2011)). Others optimize established search al-
gorithms on a centralized single server (e.g. (Mokbel
and Aref, 2008; Al-Khalidi et al., 2013; AL-Khalidi
et al., 2013)). Even already existing distributed ap-
proaches often turn their attention either to the static
variants (e.g. (Wang et al., 2006)) or to optimize well-
known local data structures such as variants of R or B
trees (e.g. (Yu et al., 2019)).
In contrast, we focus on DRRQs and maximize the
degree of distribution defining a very fuzzy or foggy
edge between mobile clients and servers. Even if all
nodes, servers and clients, are involved, their indi-
Keller, S. and Mueller, R.
Real-Time Range Query Approximation by Means of Adaptive Quad Streaming.
DOI: 10.5220/0010246500130024
In Proceedings of the 10th International Conference on Sensor Networks (SENSORNETS 2021), pages 13-24
ISBN: 978-989-758-489-3
Copyright
c
2021 by SCITEPRESS Science and Technology Publications, Lda. All rights reserved
13
vidual local range query processing load is reduced
as much as possible. We largely dispense with local
range query data structures in favor of using a gran-
ular distribution intelligence and a lightweight, fast
communication pattern on a streaming basis. The dis-
tribution fuzziness results in an approximated, not al-
ways completely correct range query result. However,
we will show that this inaccuracy can be optimized
with respect to real-time support and scalability and
is therefore becoming irrelevant.
2 PRECONDITIONS AND
REQUIREMENTS
The discussion of two-dimensional DRRQs in the eu-
clidean space and their preconditions can be enhanced
by a more formal consideration. In the infrastructure
considered, we define C := {c
t
= (c
id
,c
t
1
,c
t
2
)} as the
set of mobile client nodes (in the following: client
nodes or just nodes). t of c
t
indicates the point in
time, at which c is considered. c
id
is its never chang-
ing, system-wide unique identifier. (c
t
1
,c
t
2
) are the co-
ordinates of c in the two-dimensional euclidean space
at point in time t. S is the set of one or more server
nodes (in the following: servers) and D := C S the
distributed system. The nodes in C have the ability to
determine their own location (GPS, Bluetooth, Wifi,
etc.) and have a network connection (4G/5G, Wifi,
etc.) to communicate with the servers in S. For defin-
ing a query we use the euclidean norm (or 2-norm) as
metric d.
Following these names and notions, a range query can
now be specified as a request and response:
Definition 1. Request Q(c
t
) and response R(c
t
)
Q(c
t
) := query of c
t
at point in time t
R : CP (C) with R(c
t
):={b
t
C | d(b
t
,c
t
) d
0
}
Following these definitions, we are now able to define
different categories of range queries:
Type 1: Static (Spatial) Range Queries
Node locations are constant (immovable clients)
R(c
t
)=R(c
t
0
); t,t
0
R
+
with c
t
=c
t
0
Queries are constant (immovable inquirers)
c
t
=c
t
0
; t,t
0
R
+
Type 2: Continuous (Spatial) Range Queries
Identical to Type 1 except:
Node locations are variable (moving clients)
t,t
0
R
+
: c
t
=c
t
0
R(c
t
)6=R(c
t
0
)
Type 3: Dynamic Real-Time Range Queries
Identical to Type 2 except:
Queries are variable (moving inquirers)
t,t
0
R
+
: c
t
6=c
t
0
We will discuss related approaches for these query
categories in Section 3. Having the considered terms
in mind, the requirements needed for a DRRQ solu-
tion become straightforward. Under the terms of deal-
ing with high-density systems of millions of nodes per
considered area unit (cmp. ITU expectation (Interna-
tional Telecommunication Union lTU, 2015)), every
centralized approach (especially a single, centralized
or replicated server) obviously becomes a bottleneck.
We will discuss this in more detail in Section 4. This
leads us to our first requirement:
Requirement A Scalability: Q(c
t
) has to be pro-
cessed in sublinear time in n, c
t
C,t R
+
,n = |C|
In this context, hotspots in which high-density clus-
ters intersect with the range of the query (c
t
C :
|R(c
t
)| O(n)) are of particular interest.
The ad-hoc mobility character of these scenarios
(cmp. Section 1) in combination with high-density
areas lead to the supply and demand for continuously
updated information. To be more precise, the mobil-
ity of both requesting and requested nodes (moving
clients and inquirers) in DRRQs requires real-time
behavior in answering the queries as the second re-
quirement for our solution.
Requirement B Real-time Propagation: c
t
C, t R
+
,b
t
0
R(c
t
) : τ(c
t
) t
0
t
0
with τ(c
t
) :=
earliest point in time, at which R(c
t
) is available to c
t
.
t
0
obviously depends on the application domain and
can either be a hard or a soft deadline. In a ridesharing
scenario a soft deadline of 2000 3000ms might be
acceptable whereas in a firefighter’s life-threatening
setting a hard deadline of 300ms is crucial. As a con-
sequence, recomputing all query results from scratch
on every client movement seems to be the wrong ap-
proach in contrast to focusing on the deltas.
3 RELATED WORK
Location-dependent queries have been extensively
studied in the last decade. While a lot of litera-
ture propose general implementations for a spatial
query processing (Mokbel et al., 2004; Gedik and Liu,
2004; Tao and Papadias, 2003), the two most dom-
inant research issues related to this paper are range
queries (Wu et al., 2004c; Wu et al., 2004a; Wu et al.,
2004b; Wu et al., 2005; Kalashnikov et al., 2002)
and nearest neighbor queries (Yang and Chiu, 2017;
Gao et al., 2014; Wu et al., 2007; Mouratidis et al.,
2005a; Mouratidis et al., 2005b) which do not match
our research problem directly but provides inspiring
solutions. Another related field are spatial alarms
SENSORNETS 2021 - 10th International Conference on Sensor Networks
14
(Bamba et al., 2009), as they use similar techniques
to query safe areas. While Continuous Range Queries
(moving clients) are often studied (e.g. (Wu et al.,
2004c; Wu et al., 2004a; Wu et al., 2004b; Yu et al.,
2005; Kalashnikov et al., 2002; Wang et al., 2006)),
a much smaller set of literature is found for support-
ing DRRQs (moving inquirers). We can divide the
literature on moving queries into two categories of
centralized approaches, such as SINA (Mokbel et al.,
2004), SOLE (Mokbel and Aref, 2008), GPAC (Mok-
bel and Aref, 2005) or (Cheema et al., 2010; Al-
Khalidi et al., 2013; AL-Khalidi et al., 2013) and
distributed solutions like MobiEyes (Gedik and Liu,
2006) or Distributed Hybrid Index (Yu et al., 2019).
The latter meet our Requirement A (cmp. Section
2) of horizontal scalability much better. However,
MobiEyes requires a centralized server as a mediator
between mobile clients which could obviously lead
to the already discussed bottleneck and in turn can-
not guarantee free scalability. The Distributed Hy-
brid Index avoids centralization by providing a pre-
defined grid spread over many servers, but adopts
the dynamic character of ad-hoc mobility challenges
solely by a local server-internal height-limited vari-
ant of an R tree (VR tree). Even if update costs are
therefore limited, the tree might degenerate in our
high-density scenarios with hotspots in terms of the
number of leafs and nodes per leaf. We will come
back to this solution later after having described our
approach in detail. Another stream in literature on
range queries takes assumptions about the objects’
movement into account. To optimize query process-
ing, fix road trajectories (Papadias et al., 2003), or
motion adaption, indexing (Gedik and Liu, 2004) is
used which is not really applicable in an emergency
scenario with people in panic whose movements are
not predictable. Yet another stream in literature deals
with computation offloading in order to optimize the
balance between task offloading to expedite the task
execution and additional communication costs and la-
tency (Kao et al., 2017; Ying Cai et al., 2006; Gedik
and Liu, 2004). This assumption is not always realis-
tic, as clients lack battery capacity and computational
or storage capabilities. Indexing techniques for mov-
ing objects have been proposed and optimized mul-
tiple times in centralized database environments with
grid or cell structures (Yu et al., 2005; Zheng et al.,
2006; Mouratidis et al., 2009;
ˇ
Sidlauskas et al., 2012;
Wang and Zimmermann, 2008), hash-based schemes
in buckets (Song and Roussopoulos, 2003), and via
tree-based methods (Tayeb, 1998; Prabhakar et al.,
2002;
ˇ
Saltenis and Jensen, 2002;
ˇ
Saltenis et al., 2000;
Jensen et al., 2004). Non-uniformity in mobile ob-
ject data is also handled by a hierarchical grid index
structure (Yu et al., 2005) or a binary tree with spatial
operations (Arya et al., 1998). However, the scalabil-
ity aspect in a distributed mobile environment is not
the focus but those works could provide an inspiring
base for indexing clients in our distributed solution.
We distinguish our solution from the approaches
mentioned above as it provides the following unique
properties: (1) Our system can be distributed on an
unlimited number of server nodes, fitting an unlim-
ited volume of clients without the need to know the
whole system, and (2) we do not separate mobile ob-
jects and query consumers but link them and do not
assume that there is an imbalance between a large vol-
ume of mobile objects and only a few queries. (3)
Neither the clients nor the queries are of static nature
and our system works well with random movements
and non-uniformity. (4) Finally our solution outputs
a range query change immediately to the consuming
clients to meet real-time requirements.
4 QUAD STREAMING
The Adaptive Quad Streaming (AQS) approach can
be described in three parts: (1) the distribution
scheme (adaptive cell structure, cmp. 4.1); (2) the
interaction pattern (a streaming-based variant, cmp.
4.2); (3) the (range query) processing (algorithms,
cmp. 4.3). The scheme applied to the distribution
of servers in our approach results from the following
consideration: Let us assume that the range query is,
as already mentioned in 2, realized straightforwardly
through a request-response interaction pattern using
one centralized server s
0
for all client nodes. That
means, a client joins the system (i.e., becomes a client
node c
t
C), later after each movement at time t, it
sends a range query Q(c
t
) as a request to s
0
and re-
ceives a result R(c
t
) C as a response from s
0
. Fi-
nally, c
t
leaves the system. In consequence, s
0
knows
all clients that still joined (c C) and their latest trans-
mitted locations. On each received Q(c
t
), s
0
calcu-
lates d(c
t
,b
t
),b
t
C and, if d(c
t
,b
t
) d
0
, sends
updated R(b
t
) for every previously received Q(b
t
)
back to node b
t
, as well as R(c
t
) back to c
t
. This
brute-force, any-to-any calculation, obviously result-
ing in complexity O(n
2
) with n = |C|, cannot fulfill
our Requirement A of sublinear processing. There
are many approaches in literature addressing a sub-
linear indexing of mobile nodes in continuous spatial
range queries (e.g. (Wu et al., 2004b; Kalashnikov
et al., 2002; Yu et al., 2019)). But even in the best
case of non-overlapping ranges and constant time for
each query
Real-Time Range Query Approximation by Means of Adaptive Quad Streaming
15
R(c
t
) =
/
0 σ(Q(c
t
)) O(1), Q(c
t
),c
t
C
σ(O(c
t
)) := time span on server side between
receiving query O(c
t
) and sending result R(c
t
)
the processing workload for n cannot be man-
aged by a single server alone. For an arbitrary c
t
C:
b
t
C
σ(O(b
t
)) n · O(σ(O(c
t
))) = O (n)
It is always possible to find a greater n to overload all
vertically scaled server hardware.
Just the opposite extreme to the server bottleneck
would be an approach in which the nodes, as clients,
share the range processing uniformly without a cen-
tralized component. This is obviously a good pre-
condition for scalability. However, the lack of peer-
to-peer communication for coordination and synchro-
nization between clients in a mobile cellular or simply
Internet-based network requires a centralized compo-
nent for mediation. Yet limited resources of mobile
nodes in terms of battery inhibit extensive process-
ing on the clients’ side. Additionally, limited storage
and computation resources of mobile clients might
prevent complex calculations of requests on such de-
vices, even on today’s hardware (Shao and Taniar,
2014).
As a consequence, we aim at a compromise be-
tween both extremes, full server and full client pro-
cessing. Therefore, a horizontal scaling of server
infrastructure in terms of partitioning the processing
load between server and client nodes, minimizing the
communication load and fitting arbitrary client distri-
butions and counts must be the focus. In order to find
an optimal load partitioning for servers and clients we
create a self-adapting multidimensional structure built
of cells.
4.1 Adaptive Cell Structure
The first step for an adaptive cell structure is the
initial cell X
0
covering the whole considered two-
dimensional area. As all following cells in the struc-
ture, this cell is a square. X
0
is assigned to an initial
server s
0
S (see Figure 1).
Figure 1: Initial Cell.
If a new node joins the system and therewith the ini-
tial cell X
0
, the cellcount (number of nodes covered
by the cell) might exceed a predefined split thresh-
old. As a consequence, the initial cell X
0
is divided
into four equally-sized subcells X
(0,1)
,...,X
(0,4)
. X
0
is called the supercell of X
(0,1)
,...,X
(0,4)
. For a bet-
ter generalization we introduce some definitions for
these concepts.
A cell X
u
:= (x
1
,x
2
,l) R
3
is defined by its upper left
corner (x
1
,x
2
) as a coordinate and its edge length l.
XC
u
is the set of nodes covered by cell X
u
and |XC
u
|
therefore its cell count.
Definition 2. Cell node set XC
u
XC
u
:= {c = (c
id
,c
1
,c
2
) C |
x
1
c
1
x
1
+l x
2
c
2
x
2
+l}
Definition 3. General indexing notation of cells
X
u
is a cell with index u = (n
1
,...,n
k
)
Subcells of X
u
: X
v
1
,...,X
v
4
with v
i
= (u,i)
In the indexing notation of X
u
, the u = (n
1
,...,n
k
) de-
scribes its creation history: u = (0) = 0 for the initial
cell, {(0, i) | 1 i 4} for its subcells and so on.
This indexing notation is used for understanding only
and not in the implementation of the algorithms of the
system themselves.
Definition 4. Thresholds & Relaxed Adaption Factor
Relaxed Adaption Factor: R [0,1]
Split Threshold: C
split
N
Merge Threshold: C
merge
:= bR/4 ·C
split
c
Using these thresholds, we can now define the split
and merge rules:
Split Rule for Cell X
u
= (x
1
,x
2
,l) : |XC
u
| > C
split
1. X
(u,i)
:=(x
1
+l ·i mod 2,x
2
+lbi/2c,l/2), 1 i 4
2. XC
(u,i)
:= {c = (c
id
,c
1
,c
2
) XC
u
|
x c
1
x + l y c
2
y + l},X
(u,i)
= (x,y, l)
3. XC
u
:=
/
0
If the cell count |XC
u
| of X
u
exceeds the split thresh-
old C
split
, X
u
will be split into four new subcells
X
(u,i)
,1 i 4, each assigned to a new unused server
from the pool of servers S (see Figure 2). Note, that
the original cell X
u
and its server s
u
remain for coor-
dination purposes, but do not contain nodes anymore.
These nodes were divided between the subcells.
Figure 2: Cell splitting and server assignment.
SENSORNETS 2021 - 10th International Conference on Sensor Networks
16
In the same way, the four cells created during a split
are merged again, if their cell counts underrun the
merge threshold C
merge
.
Merge Rule for subcells of X
(n
1
,...,n
k
)
:
X
(n
1
,...,n
k
,i)
: |XC
(n
1
,...,n
k
,i)
| < C
merge
1. XC
(n
1
,...,n
k
)
:=
4
i=1
XC
(n
1
,...,n
k
,i)
2. XC
(n
1
,...,n
k
,i)
:=
/
0,1 i 4
3. Delete X
(n
1
,...,n
k
,i)
,1 i 4
After a merge, the supercell absorbs all nodes of the
merged cells. The servers, to which the subcells were
assigned, are released and available in the serverpool
again. Following this rule, the cell counts of all four
cells have to underrun the threshold. But less strict
rules might be conceivable, e.g. only two cells are
sufficient for a merge.
Before we are able to introduce how this cell struc-
ture is used for the DRRQs, we have to define the con-
nections between all nodes, servers and clients. Every
cell maintains a maximum of eight links to adjacent
cells, three to the neighbor cells created during the
split (the other quad cells), one to the supercell, and
four to the subcells. Except for the subcell links, all
links are mandatory. In addition, every cell has an un-
sorted simple list with links to the covered clients (see
Figure 3). Please, keep in mind, that we would never
explicitly set, update, or follow these cell links in the
following sections for the sake of clarity. We assume,
that these links are just there.
4.2 Streaming
In contrast to most other approaches, we do not
use the request-response pattern, neither directly nor
implicitly (Yu et al., 2019), for the range queries.
Requests for DRRQs are never created, transferred,
stored, or updated anywhere in the whole system.
Neither is there a need to re-evaluate such a query
in case of location updates of covered nodes nor to
update a query itself on an inquirer’s movement. In-
stead, we use a streaming communication pattern in
which events, as small information chunks, stream
from node to node, whether server or client. For in-
stance, location update events permanently flow from
moving clients over the cells to all other clients af-
fected by their movements.
Each node of the system, server and client, is able
to send arbitrary events to arbitrary receivers using
a service primitive sendEvent: sendEvent <receiver
address> <event>. sendEvent uses one of the outgo-
ing links from the sending node to the next node spec-
ified by address. In addition, each node has as service
primitive receiveEvent forwarding a received event
to a node-internal callback registered for this type of
event. Every event e := (t p,O
1
,O
2
,O
3
,...) is simply a
tuple of undefined length, in which t p N is the type
of e. O
i
are arbitrary objects of any type and repre-
sent the information of the event, in which count and
type of the objects O
i
depend on the type of event t p.
Please note that the events themselves include neither
a sender nor a receiver address. Therefore, a node
receiving an event cannot identify where it originally
comes from. In the following, we describe the differ-
ent event types and their objects:
Definition 5. Location Update Event (LU
c
t
)
e := (0,c
t
,t, f )
t R: timestamp at which c
t
reached its location
c
t
C: node that moved to a new location
f N: flag (0: regular, 1: join, 2: connected)
The location update events (in the following often
simply LU
c
t
) are used to inform that a node c
t
moved
at point in time t to a new location. The new loca-
tion is stored in the node itself (cmp. Section 2). This
is the most important event type in the system. The
events of this type are initially created by the nodes
themselves after they have moved to a new location
(see Figure 3). The flag f of LU
c
t
is used to trans-
Figure 3: Location update event streaming.
mit a status intended by the event and is on demand
changed by nodes while flowing over them. A join
status intends that the node specified in the event is
either new to the system and wants to join it (system
join) or has left a cell and wants to join another cell
(cell join). Later on, we will see that the differenti-
ation between the two join types is not relevant. We
define c
t
as Connected Node, if it is connected to s
u
in
the sense of, it is covered by the cell X
u
assigned to s
u
.
As we know from Subsection 4.1, every server uses an
unsorted list of links to all its connected nodes. Note,
that a connected node itself also maintains a link (or
a connection) to its server. The link between a con-
Real-Time Range Query Approximation by Means of Adaptive Quad Streaming
17
nected node and its server is therefore always bidirec-
tional. A connected flag in an LU
c
t
indicates, that the
node specified in the event is already connected to the
server that received the event. A regular flag tells the
receiving node that the client node c
t
specified in the
LU
c
t
is neither connected to this server nor wants to
join it.
Definition 6. Connected Event (CON
s
u
)
e := (1,s
u
)
s
u
S: server the receiver is now connected to
A node receives a CON
s
u
event if it has been con-
nected to (new) server s
u
. As a consequence, only
client nodes receive this type of event which happens
for one of the following three reasons:
1. New node joins: A new node c
t
wants to join the
system and therefore already sent an LU
c
t
with the
join flag to a node of the system D. After hav-
ing received CON
s
u
the node knows that it is con-
nected to D for the first time over server s
u
.
2. Node moved to non-covered location: A node c
t
moved to a location where it lost cell coverage by
its original connected cell and therefore joined an-
other server s
u
whose cell X
u
covers the node.
3. Cell split: After a cell has been split, the con-
nected nodes are divided between the four sub
cells. This is also realized by a LU
c
t
with join
flag which in turn results in a CON
s
u
sent by the
individual subcells.
Definition 7. Merge Request Event (MREQ
X
u
)
e := (2,X
u
)
X
u
X: cell X
u
whose server s
u
wants to merge
Definition 8. Merge Acknowledged Event (MACK)
e := (3)
If a cell count underruns the merge threshold C
merge
,
the server s
u
of the corresponding cell X
u
sends a
MREQ to the server of the supercell. If a cell received
MREQs from all four subcells, it initiates a merge ac-
tion and in turn sends a MACK to the servers of the
four subcells to request their closing (cmp. merge rule
in Subsection 4.1).
We will now explain how these streamed events
and the cell structure described above are used in the
algorithms of the system D.
4.3 Algorithms
In the following, the algorithmic parts of the system
D and our Adaptive Quad Streaming approach are de-
scribed in more detail from the servers’ perspective.
However, we start with a client activity since this is
the most straightforward way to introduce the server
algorithms consistently. Following our streaming in-
teraction approach, most algorithms are realized as
callbacks receiving and sending events.
If a new (client) node c
t
wants to join the system,
it sends a location update event with a join flag to
the server s
0
of the initial cell X
0
(cmp. 4.1) using
its sendEvent service primitive. However, s
0
handles
this initial event just like any other event of this type.
From s
0
s point of view, it does not matter whether
the node c
t
specified in the event is new to the sys-
tem or just new to its cell. The only interesting as-
pect for s
0
is that c
t
wants to join and whether its cell
X
0
covers c
t
. It will then be connected to s
0
. Oth-
erwise, s
0
passes this event to the next adjacent cell
in direction to c
t
s location. And this is the uniform
behavior of every server. The only difference is that
the path (number of hops) from s
0
to the server the
node is later connected to might be longer compared
to a usual node’s movement. The reason is that s
0
is
the only entry point into the system regardless of the
node’s initial position.
Figure 4 describes the central algorithm in terms
of a callback function (locationUpdateReceived)
handling the scenario mentioned above and all other
cases, in which server nodes received a location up-
date event. In this algorithm, the server s
(n
1
,...,n
k
)
first
checks the flags of the passed location update event
LU
c
t
:= (0,c
t
,t, f ). If it is not flagged, i.e. a regular
event, than c
t
neither wants to join nor is connected
to s
(n
1
,...,n
k
)
(line 2). In this case, the only remaining
task for s
(n
1
,...,n
k
)
is to check, if the node’s range inter-
sects with its cell X
0
and if so, to inform all connected
nodes b XC
(n
1
,...,n
k
)
about the location update event
LU
c
t
(lines 2–4). In case of an LU
c
t
flagged as join,
s
(n
1
,...,n
k
)
checks if its cell X
(n
1
,...,n
k
)
covers c
t
. If yes
and if there are no further subcells potentially cover-
ing this node (lines 5–6), then c
t
will be connected
to s
(n
1
,...,n
k
)
. Therefore, s
(n
1
,...,n
k
)
adds c
t
to its un-
sorted list, checks if its cell has now to split (cmp.
Figure 5) and informs c
t
about now being connected
to s
(n
1
,...,n
k
)
(lines 7–9). Before informing all other
connected nodes about c
t
, LU
c
t
is reflagged with 0,
since the join of c
t
is already executed (lines 10–12).
In case of LU
c
t
being flagged as connected, s
(n
1
,...,n
k
)
checks if c
t
is still covered by its cell after the move-
ment (lines 13–14). If yes, the LU
c
t
is reflagged with
0 before informing all other nodes, since no further
reconnection of c
t
is required (lines 15–17). If no, c
t
is disconnected from s
(n
1
,...,n
k
)
and therefore removed
from the unsorted list of nodes (line 19). In case of
underrunning the merge threshold, s
(n
1
,...,n
k
)
requests
a merge from its supercell server s
(n
1
,...,n
k1
)
(lines 20–
21). After disconnecting c
t
from s
(n
1
,...,n
k
)
, c
t
has to
join another cell. Therefore, the LU
c
t
is reflagged with
SENSORNETS 2021 - 10th International Conference on Sensor Networks
18
1 before informing all other connected nodes about
this news (lines 22–25). All server- or cell-internal
work is now done. The following lines are for pass-
ing the event to the adjacent neighbors, if they exist
and their cells intersect with c
t
s range: (1) subcells
(lines 26–29); (2) the three quad neighbor cells (lines
30–32); (3) the supercell, if c
t
s range covers the su-
percell completely (lines 33–34). Please note, that
Data:
s
(n
1
,...,n
k
)
: server that received a LU
c
t
X
(n
1
,...,n
k
)
: cell assigned to s
(n
1
,...,n
k
)
X
(n
1
,...,n
k
,i)
: potential subcells of X
(n
1
,...,n
k
)
X
(n
1
,...,n
k1)
: supercell of X
(n
1
,...,n
k
)
1: function LOCATIONUPDATERECEIVED(c
t
C,t
R, f N)
2: if f = 0 rangeIsIntersected(X
(n
1
,...,n
k
)
,c
t
) then
3: for all b XC
(n
1
,...,n
k
)
do
4: sendEvent(b,LU
c
t
)
5: if f = 1 nodeIsCovered(X
(n
1
,...,n
k
)
,c
t
) then
6: if ¬ exists(X
(n
1
,...,n
k
,i)
) then
7: XC
(n
1
,...,n
k
)
:= XC
(n
1
,...,n
k
)
{c
t
}
8: splitCheck(X
(n
1
,...,n
k
)
)
9: sendEvent(c
t
,CON
s
(n
1
,...,n
k
)
)
10: f:=0
11: for all b XC
(n
1
,...,n
k
)
\ {c
t
} do
12: sendEvent(b,LU
c
t
)
13: if f = 2 then
14: if nodeIsCovered(X
(n
1
,...,n
k
)
,c
t
) then
15: f:=0
16: for all b XC
(n
1
,...,n
k
)
\ {c
t
} do
17: sendEvent(b,LU
c
t
)
18: else
19: XC
(n
1
,...,n
k
)
:= XC
(n
1
,...,n
k
)
\ {c
t
}
20: if |XC
(n
1
,...,n
k
)
| < c
merge
then
21: sendEvent(s
(n
1
,...,n
k1
)
,MREQ
X
(n
1
,...,n
k
)
)
22: f:=1
23: if rangeIsIntersected(X
(n
1
,...,n
k
)
,c
t
) then
24: for all b XC
(n
1
,...,n
k
)
\ {c
t
} do
25: sendEvent(b,LU
c
t
)
26: if exists(X
(n
1
,...,n
k
,i)
) then
27: for all i {1,...,4} do
28: if rangeIsIntersected(X
(n
1
,...,n
k
,i)
,c
t
) then
29: sendEvent(s
(n
1
,...,n
k
,i)
,LU
c
t
)
30: for all j {1,...,4} 6= n
k
do
31: if rangeIsIntersected(X
(n
1
,...,n
k1
, j)
,c
t
) then
32: sendEvent(s
(n
1
,...,n
k1
, j)
,LU
c
t
)
33: if ¬ rangeIsCovered(X
(n
1
,...,n
k1
)
,c
t
) then
34: sendEvent(s
(n
1
,...,n
k1
)
,LU
c
t
)
Figure 4: Callback processing an LU
c
t
event.
the functions rangeIsIntersected, rangeIsCovered,
and nodeIsCovered are not described in detail, since
these are simple functions with the given coordinates
of cells and nodes.
Figure 5 describes how the split threshold is ver-
ified in function splitCheck (line 2) and how the
split of the cell is performed, if required. As a con-
sequence, the subcells for the split are created and
the required servers allocated from the server pool
to which the subcells are assigned (lines 3–6). Af-
terwards, all connected nodes are divided between
the subcells by sending a join-flagged location update
event to this subcell that covers the respective node
(lines 7–11). Keep in mind, that a splitted cell has no
connected nodes anymore.
Data:
s
(n
1
,...,n
k
)
: server that received a LU
c
t
X
(n
1
,...,n
k
)
: cell assigned to s
(n
1
,...,n
k
)
X
(n
1
,...,n
k
,i)
: potential subcells of X
(n
1
,...,n
k
)
1: function SPLITCHECK(X X
(n
1
,...,n
k
)
)
2: if |XC
(n
1
,...,n
k
)
| > C
split
then
3: for all i {1,...,4} do
4: createCell(X
(n
1
,...,n
k
,i)
)
5: s
(n
1
,...,n
k
,i)
:=allocateServer()
6: assignCellToServer(s
(n
1
,...,n
k
,i)
,X
(n
1
,...,n
k
,i)
)
7: for all b XC
(n
1
,...,n
k
)
do
8: LU
b
:= (0,b,t,1)
9: for all i {1,...,4} do
10: if nodeIsCovered(X
(n
1
,...,n
k
,i)
,c
t
) then
11: sendEvent(s
(n
1
,...,n
k
,i)
,LU
b
)
12: XC
(n
1
,...,n
k
)
:=
/
0
Figure 5: Split check for a cell.
In the callback mergeRequestReceived, the server
s
(n
1
,...,n
k1)
received a merge request event MREQ
from subcell server s
(n
1
,...,n
k
)
. If the number of
MREQs received from different subcells in total ex-
ceeds the given limit (default is 4, i.e. all four sub-
cells need to request for a merge), then the merge is
executed. For that purpose s
(n
1
,...,n
k1)
sends a merge-
acknowledged event (MACK) to the subcell servers.
The server s
(n
1
,...,n
k
)
received the MACK event in
callback mergeAckReceived. In turn, it passes all con-
nected nodes back to the server s
(n
1
,...,n
k1
)
of the su-
percell by sending join-flagged location update events
for them. Afterwards, it releases itself back to the
server pool. The callbacks mergeRequestReceived
and mergeAckReceived are not described in pseu-
docode syntax due to space restrictions. Please note,
that all event receivers has to ensure, that events are
not directly and redundantly sent back to its receivers
(rebound effect). This can simply be realized by
adding flags or sender addresses to the send and re-
ceived primitives. We have skipped these rebound
parts in the algorithms for the sake of clarity.
Finally, if a (client) node b
t
receives a location up-
date event LU
c
t
:= (0,c
t
,t,0), it has to check if c
t
is in
its range: d(b
t
,c
t
) d
0
. If yes, b
t
can update its local
Real-Time Range Query Approximation by Means of Adaptive Quad Streaming
19
data structures accordingly. If no, b
t
has to drop c
t
.
In this case, b
t
was falsely informed by a location up-
date event and uselessly spent limited local resources
for this check. The question is how often this happens
in terms of probability. We will come back to this in
Section 6.
5 EVALUATION
The major benefit of AQS is the very symmetric and
regular self-adapting structure resulting in several ad-
vantages. Compared to other approaches handling the
dynamic behavior of DRRQs by a more or less static
distribution plus a flexible server-internal data struc-
ture, AQS does not need complex server data struc-
tures and handles the dynamics by using a very flexi-
ble distribution pattern. Compared to DHI (Yu et al.,
2019) for example, we use a simple unsorted list and
an self-adapting cell structure instead of an local R
tree variants and a fixed distribution grid. In con-
trast to DHI, the number of nodes per server (cell
count) and the branching factor (number of network
links to cell neighbors, sub- and supercells) are lim-
ited in AQS. The update costs for a split or merge
are therefore constant and do not influence cells be-
yond the direct links. Keeping the supercell saves
update costs for neighbor links. The communication
load can be limited due to the very regular cell struc-
tures: before sending an event to an adjacent cell, a
cell can easily check whether the other one covers the
node or its range due to its known coordinates and di-
mensions. Instead of parallelizing the calculation and
maintenance of saved range queries on a streaming
basis, as with DHI (Yu et al., 2019), we completely
renounce the storage of range queries and use stream-
ing in its originally intended sense as a flowing event
data stream from clients to clients. Once, an location
update event from a client reaches the cell level, it
spreads in a waveform-like manner through the cell
structure until the cells transfer it back to their con-
nected nodes affected by the update.
Scalability. The scalability is given by construction
of the adaptive quad cell structure: in the best pos-
sible case of uniformly distributed nodes, the cell
structure splits very regularly with new nodes (system
join). If one cell X
u
(of capacity m = C
split
) splits into
subcells X
(u,i)
, the path length for the covered nodes
to other nodes might increase by one due to the re-
maining supercell X
u
. But at the same time, X
(u,i)
provides free capacity for covered nodes of 3m until
the next split due to the uniform distribution. In to-
tal, X
(u,i)
cover 4m nodes and after further k splits,
X
(u,i,n
1
,...,n
k
)
cover 4
k
m nodes. As a consequence,
for n the cell count (server load) stays limited
and the path length between two client nodes c
t
and
b
t
and therewith the update time of a Q(c
t
) increases
in a logarithmic manner (base 4), if we use a lim-
ited average latency value per hop on the path. This
assumption also holds for non-uniformly distributed
scenarios since the average cell size decreases expo-
nentially (by splits) in high-density areas whereas the
path length grows logarithmically only. That means
that in these areas, the logarithmic behavior holds,
whereas in other areas with fewer new nodes, the path
length remains equal or grows in a sublogarithmic
manner. The exponentially decreasing cell size leads
to another result.
Approximation. The cell structure approximates the
spatial distribution of the client nodes in terms of cell
granularity. In high-density regions (hotspots), we
have much smaller cells which gradually adapt, i.e.
the nearer the hotspot edges get, the larger the cell
size will be. Much more interesting is the fact that
this way the cell structure approximates the ranges
of the queries in terms of falsely informed clients.
The better our cell structure approximates the shape
of the ranges on average, i.e. the circle lines, the less
clients are falsely informed. In order to motivate this
assumption, consider the fact that our system leads
to a coarsely granulated cell structure in low-density
areas. As a result, the cells approximate the shape
(circle line) of ranges less exactly compared to high-
density areas. But the influence of these coarse bigger
cells is reduced, since one of these cells cover fewer
nodes compared to areas of this size (covered by sev-
eral cells) in high-density regions. Therefore, even
if big cells inaccurately approximate the circle line
only, the number of falsely informed clients is still
small with respect to C
split
. If the circle line intersects
a cell, whether large or small, there is always only a
limited number of falsely informed nodes in it. As a
result, with an optimized pair of (C
split
,C
merge
), the
range can be approximated as well as possible in or-
der to minimize the falsely informed clients. We will
demonstrate this in our experimental results in the fol-
lowing section.
6 EXPERIMENTAL RESULTS
For our performance test we consciously rely on very
limited hardware in terms of resources (single-board
computers Raspberry Pi 3 B+ with a 1.40 GHz quad-
core ARM processor and 1 GB main memory). As
OS we choose a minimal Unix distribution to reduce
external influence and run our Java implementation
on the Java Virtual Machine. To test different client
SENSORNETS 2021 - 10th International Conference on Sensor Networks
20
(a) Uniform
(b) Unequal
(c) Hotspot
Figure 6: Tested client distribution scenarios and resulting
cell structure.
distributions with non-uniformity in high- and low-
density areas, we create three deterministic scenarios
of client movements the positions of which are visu-
alized as snapshots in Figure 6. To achieve compa-
rable results, we always test with a uniform client
distribution (Figure 6a) against a very high-density
hotspot with empty areas on the edge (Figure 6c)
and a less unequal distribution with a non-centered
hotspot (Figure 6b). With an increasing probability
Figure 7: Split threshold influence on error share and la-
tency.
of the nodes moving back to their spawn point the
further they move away, we ensure, that the distribu-
tion pattern does not change significantly with ran-
dom client movement over time. A resulting cell
structure created by AQS is also displayed in Fig-
ure 6 for each of the example distribution scenarios
(C
split
= 40). Obviously, the client distributions are
represented very well by the cell structure in the sys-
tem. Different movement velocities are considered to
get more realistic scenarios. The velocities allow each
client to move randomly, limited to a max. step size of
5% of the whole simulation area’s width or height per
update. We run our tests with |C| = 100‘000 clients in
an area of 1000 × 1000 and a query range of d
0
= 50.
To achieve comparable simulation results, all clients
update their location in the same time interval, and af-
ter 100‘000 updates a system snapshot is recorded for
the result sets described in the following.
Figure 8: Min/max latency in hotspot scenario.
Effect of Split Threshold C
split
. As already men-
tioned in Section 4.3, the approximation of a range
query leads to falsely sent LU
c
t
messages received by
a client node b
t
. Filtering those messages unnecessar-
ily consumes limited client resources. However, to re-
duce this proportion named error share, the threshold
C
split
can be decreased which leads to a better approx-
imation of the range query as demonstrated in Figure
7 used with our hotspot scenario. At the same time,
the communication effort increases as more cells must
be addressed while processing a location update with
a smaller C
split
in a deeper cell structure. This is also
shown in Figure 7 as latency representing an aver-
age time between sending an LU
c
t
from the updating
client node c
t
to all receiving client nodes b
t
. De-
picting additionally the minimum and maximum mea-
sured latency for all LU
c
t
s, Figure 8 shows that there
is no measured latency which strongly deviates from
the mean value even in a hotspot scenario. However,
in most real-life scenarios a real-time deadline t
0
of
300ms as in the firefighters scenario could easily be
fulfilled with the measured latency in our simulation
results, even in worst case.
Figure 9: Scalability with increasing client count.
Scalability with Increasing Client Count. To test
robustness in scalability on high-density clusters of
mobile clients, we record the average latency of LU
c
t
while spawning an increasing count of clients (sys-
tem join). This is shown in Figure 9 for our differ-
ent distribution scenarios (C
split
= 40). As we can
see, our solution performs sublinear with respect to
an increasing client count and is not much affected
by a non-uniform client distribution. Nevertheless we
discuss the influence of client distribution in the next
Real-Time Range Query Approximation by Means of Adaptive Quad Streaming
21
paragraph.
Figure 10: Distribution effect on latency.
Effect of Hotspots. Hotspots are simulated with our
distribution scenarios described above and visualized
in Figure 6. As a high-density cluster of clients yield
to a deeper cell structure and a higher number of cells
in those areas, the average latency of an LU
c
t
event
increases more slowly as the error share decreases.
This can be easily identified by comparing Figure 10
and Figure 11: the first one shows the increasing la-
tency for different split sizes and distribution scenar-
ios whereas the latter visualizes the error share in the
same way.
Reducing the error share in a high-density area is a
highly desirable result, as neighbor links in a fix query
range rise very sharply in high-density hotspots and
challenge client nodes in maintaining many connec-
tions.
Figure 11: Distribution effect on error share.
Throughput in a Cell. While we are dealing with
limited server hardware, the throughput of events han-
dled by a cell within a certain time span is an interest-
ing point. As demonstrated in Figure 12, we could
record an average throughput of 10/ms in an in-
out-measuring setting. The vertical axis shows the av-
erage amount of events which can be processed by a
cell in one single millisecond whereas the horizontal
axis displays the simulation breakpoints recorded by
us over time while our clients are moving and produc-
ing a variety of different events. In Figure 13 we show
the workload of cell generated by the events (first is
uniform, second is unequal, third is hotspot distribu-
tion). We use a uniform client distribution of 100‘000
LU
c
t
s of 100‘000 clients. They are nearly equally
spread over all cells regardless of their structure layer.
As we can see, leaf cells handle fewer events com-
pared to other cells as expected due to missing sub-
cells. However, that is advantageous as the leaf cells
Figure 12: Throughput per cell over time.
have to handle their connected client nodes. Main-
taining these communication connections consumes
additional calculation power in mobile environments
(e.g. availability checks of unreliable mobile devices,
network changes, etc.).
Figure 13: Received events per cell per layer (uniform, un-
equal, hotspot).
An even more interesting point is the event work-
load in non-uniform distributions displayed in Fig-
ure 13. We identify the same general behavior of an
equally spread workload in upper cell layers as with
uniform distributions. But in lower cell structure lay-
ers the workload drops dramatically on average. An
explanation could be the many low-density areas in
those scenarios which are near a hotspot and there-
fore splitted in a deeper layer. The important mea-
sured value is the maximum workload received by a
cell which stays equally regardless of the distribution
pattern and indicates that our system does not over-
load any cell as expected.
Effect of Client Velocity. In Figure 14, we evaluate
the influence of client movement velocity on latency.
The horizontal axis represents the client’s velocity in
random movements which is realized with the step
size displayed on the axis, but in a random angle. Al-
though more cells are involved in high velocity up-
SENSORNETS 2021 - 10th International Conference on Sensor Networks
22
Figure 14: Influence of velocity on latency.
dates, the count of cells receiving an LU
c
t
(describing
a movement in time from t 1 to t) is limited. In the
worst case, the earlier query result R(c
t1
) and new
one R(c
t
) do not intersect at all. This results in a pro-
cessing of all cells which are covered by both queries.
As also shown in Figure 14, AQS is robust enough
to deal with arbitrary client velocities as it hardly has
any influence on the end-to-end latency.
7 CONCLUSION AND FUTURE
WORK
In this paper we focused on a subclass of contin-
uous spatial range queries, the Dynamic Real-Time
Range Queries (DRRQ). In these queries, both, re-
questing and requested nodes, are mobile, leading
to always changing queries and results. The DR-
RQs address a category of mobile application sce-
narios we call ad-hoc mobility challenges. They
are rapidly gaining importance nowadays as clients
in high-density systems demand ad-hoc information
(movement) updates about other clients nearby in a
unpredictable and therefore real-time manner. In or-
der to address this scalability and real-time require-
ments, we presented Adaptive Quad Streaming (AQS)
as a highly distributed approach for DRRQs. It com-
bines a dynamically self-adapting cell structure with
a lightweight streaming approach. Along with a cell-
per-server assignment it adapts to arbitrary and al-
ways changing clients distributions using a splitting
and merging method and approximates the results of
DRRQs. We have shown in simulations that the error
rate of the approximation decreases more rapidly than
the end-to-end latency (one client’s movement update
to another client) increases with respect to the used
threshold for splitting. With a latency of 150ms we
achieved an error rate of 16% whereas an acceptable
latency of 200ms lowers the error rate to 4.5%. This is
obviously a good quality measure for the approxima-
tion of client distributions and corresponding range
shapes of client queries. AQS strictly limits the num-
ber of clients handled by a cell and server as well as
the number of links to other servers, that way control-
ling the processing and communication load. In con-
sequence, we also showed in our experiments, that the
latency grows logarithmically in the number of nodes
in the system. This is an indicator for the scalability of
AQS, capable to deal with arbitrary high numbers of
clients per area unit. The approximation of client dis-
tributions by dividing the work and communication
load of DRRQs between several servers and (in a very
limited way) also clients can be seen and also visual-
ized as a fuzzy two-dimensional edge between clients
and servers. This might be an interesting theoretical
insight in dynamically adapting edge computing.
Our future work lies in finding out how to assign a
server’s free capacity more flexibly instead of assum-
ing an unlimited server pool and a one-server-per-cell
assignment in an idealistic manner. Another perspec-
tive might be how to react on imbalances between
processing and communication load as a degeneration
effect among the servers arising over time. A chal-
lenging aspect might be the influence to the results af-
ter a shift to more than two and also non-spatial client
dimensions, thus representing very realistic and con-
siderably more complex application scenarios.
REFERENCES
AL-Khalidi, H., Taniar, D., Betts, J., and Alamri, S. (2013).
On finding safe regions for moving range queries.
Mathematical and Computer Modelling.
Al-Khalidi, H., Taniar, D., and Safar, M. (2013). Ap-
proximate algorithms for static and continuous range
queries in mobile navigation. Computing.
Arya, S., Mount, D. M., Netanyahu, N. S., Silverman, R.,
and Wu, A. Y. (1998). An optimal algorithm for ap-
proximate nearest neighbor searching in fixed dimen-
sions. Journal of the ACM.
Bamba, B., Liu, L., Iyengar, A., and Yu, P. S. (2009). Dis-
tributed processing of spatial alarms: A safe region-
based approach. International Conference on Dis-
tributed Computing Systems.
Cheema, M. A., Brankovic, L., Lin, X., Zhang, W., and
Wang, W. (2010). Multi-guarded safe zone: An ef-
fective technique to monitor moving circular range
queries. International Conf. on Data Engineering.
Gao, S., Ji, C., Xu, C., and Yang, N. (2014). Parallel spatial
nearest neighbour query based on grid index. 2014
IEEE Workshop on Electronics, Computer and Appli-
cations, IWECA 2014.
Gedik, B. and Liu, L. (2004). MobiEyes: Distributed Pro-
cessing of Continuously Moving Queries on Moving
Objects in a Mobile System. In Advances in Database
Technology - EDBT 2004. Springer Berlin Heidelberg.
Gedik, B. and Liu, L. (2006). MobiEyes: A distributed
location monitoring service using moving location
queries. IEEE Transactions on Mobile Computing.
International Telecommunication Union lTU (2015). IMT
Vision Framework and overall objectives of the fu-
ture development of IMT for 2020 and beyond.
Real-Time Range Query Approximation by Means of Adaptive Quad Streaming
23
Jensen, C. S., Lin, D., and Ooi, B. C. (2004). +Query and
Update Efficient B-Tree Based Indexing of Moving
Objects. In Proceedings 2004 VLDB Conf. Elsevier.
Kaczor, S. and Kryvinska, N. (2013). It is all about services-
fundamentals, drivers, and business models. Journal
of Service Science Research.
Kalashnikov, D., Prabhakar, S., Hambrusch, S., and Aref,
W. (2002). Efficient evaluation of continuous range
queries on moving objects. Lecture Notes in Computer
Science.
Kao, Y. H., Krishnamachari, B., Ra, M. R., and Bai, F.
(2017). HERMES: Latency Optimal Task Assignment
for Resource-constrained Mobile Computing. IEEE
Transactions on Mobile Computing.
Mokbel, M. F. and Aref, W. G. (2005). GPAC: Generic and
progressive processing of mobile queries over mobile
data. Sixth International Conference on Mobile Data
Management, MDM’05.
Mokbel, M. F. and Aref, W. G. (2008). SOLE: Scalable
on-line execution of continuous queries on spatio-
temporal data streams. VLDB Journal.
Mokbel, M. F., Xiong, X., and Aref, W. G. (2004). SINA.
In The 2004 ACM SIGMOD international conference
on Management of data - SIGMOD ’04. ACM Press.
Moln
´
ar, E., Moln
´
ar, R., Kryvinska, N., and Gregu
ˇ
s, M.
(2014). Web intelligence in practice. Journal of Ser-
vice Science Research.
Mouratidis, K., Bakiras, S., and Papadias, D. (2009).
Continuous monitoring of spatial queries in wireless
broadcast environments. IEEE Transactions on Mo-
bile Computing.
Mouratidis, K., Hadjieleftheriou, M., and Papadias, D.
(2005a). Conceptual partitioning: An efficient method
for continuous nearest neighbor monitoring. ACM
SIGMOD Int. Conference on Management of Data.
Mouratidis, K., Papadias, D., Bakiras, S., and Tao, Y.
(2005b). A threshold-based algorithm for continuous
monitoring of k nearest neighbors. IEEE Transactions
on Knowledge and Data Engineering.
Papadias, D., Mamoulis, N., Zhang, J., and Tao, Y. (2003).
Query processing in spatial network databases. 29th
International Conference on Very Large Data Bases.
Prabhakar, S., Xia, Y., Kalashnikov, D. V., Aref, W. G., and
Hambrusch, S. E. (2002). Query indexing and velocity
constrained indexing: Scalable techniques for contin-
uous queries on moving objects. IEEE Transactions
on Computers.
ˇ
Saltenis, S. and Jensen, C. S. (2002). Indexing of mov-
ing objects for location-based services. International
Conference on Data Engineering.
ˇ
Saltenis, S., Jensen, C. S., Leutenegger, S. T., and Lopez,
M. A. (2000). Indexing the positions of continuously
moving objects. SIGMOD Record (ACM Special In-
terest Group on Management of Data).
Shao, Z. and Taniar, D. (2014). Range-based nearest neigh-
bour search in a mobile environment. 12th Interna-
tional Conference on Advances in Mobile Computing
and Multimedia, MoMM 2014.
ˇ
Sidlauskas, D.,
ˇ
Saltenis, S., and Jensen, C. S. (2012). Par-
allel main-memory indexing for moving-object query
and update workloads. The ACM SIGMOD Interna-
tional Conference on Management of Data.
Song, Z. and Roussopoulos, N. (2003). SEB-tree: An Ap-
proach to Index Continuously Moving Objects. In Mo-
bile Data Management. Springer Berlin Heidelberg.
Tao, Y. and Papadias, D. (2003). Spatial Queries in Dy-
namic Environments. ACM Transactions on Database
Systems.
Tayeb, J. (1998). A Quadtree-Based Dynamic Attribute In-
dexing Method. The Computer Journal.
Wang, H. and Zimmermann, R. (2008). Snapshot location-
based query processing on moving objects in road net-
works. GIS: ACM International Symposium on Ad-
vances in Geographic Information Systems.
Wang, H., Zimmermann, R., and Ku, W.-S. (2006). Dis-
tributed Continuous Range Query Processing on Mov-
ing Objects. In Database and Expert Systems Appli-
cations. Springer Berlin Heidelberg.
Wu, K. L., Chen, S. K., and Yu, P. S. (2004a). Index-
ing continual range queries for location-aware mobile
services. 2004 IEEE International Conference on e-
Technology, e-Commerce and e-Service, EEE 2004.
Wu, K. L., Chen, S. K., and Yu, P. S. (2004b). Indexing
continual range queries with covering tiles for fast lo-
cating of moving objects. International Conference
on Distributed Computing Systems.
Wu, K. L., Chen, S. K., and Yu, P. S. (2004c). Process-
ing continual range queries over moving objects using
VCR-based query indexes. MOBIQUITOUS 2004 -
1st Annual International Conference on Mobile and
Ubiquitous Systems: Networking and Services.
Wu, K. L., Chen, S. K., and Yu, P. S. (2005). On incremen-
tal processing of continual range queries for location-
aware services and applications. MobiQuitous 2005:
Second Annual International Conference on Mobile
and Ubiquitous Systems -Networking and Services.
Wu, W., Guo, W., and Tan, K. L. (2007). Distributed pro-
cessing of moving K-nearest-neighbor query on mov-
ing objects. Int. Conference on Data Engineering.
Xuan, K., Zhao, G., Taniar, D., Rahayu, W., Safar, M., and
Srinivasan, B. (2011). Voronoi-based range and con-
tinuous range query processing in mobile databases.
Journal of Computer and System Sciences.
Yang, K.-T. and Chiu, G.-M. (2017). Monitoring contin-
uous all -nearest neighbor query in mobile network
environments. Pervasive and Mobile Computing.
Ying Cai, Hua, K., Guohong Cao, and Xu, T. (2006). Real-
time processing of range-monitoring queries in het-
erogeneous mobile databases. IEEE Transactions on
Mobile Computing.
Yu, X., Pu, K. Q., and Koudas, N. (2005). Monitoring k-
nearest neighbor queries over moving objects. Inter-
national Conference on Data Engineering.
Yu, Z., Xhafa, F., Chen, Y., and Ma, K. (2019). A distributed
hybrid index for processing continuous range queries
over moving objects. Soft Computing.
Zheng, B., Xu, J., Lee, W.-C., and Lee, D. L. (2006). Grid-
partition index: a hybrid method for nearest-neighbor
queries in wireless location-based services. The VLDB
Journal.
SENSORNETS 2021 - 10th International Conference on Sensor Networks
24