Pervasive and Mobile Computing

GeoEkuiper: A Cloud-Cooperated Geospatial Edge Stream Processing Engine for

Resource-Constrained IoT Devices with Higher Throughput
--Manuscript Draft--

Manuscript Number: PMC-D-23-00537

Article Type: Research Paper

Keywords: Internet of Things; Big Data; Geospatial; Edge Computing; Stream Processing
Engine

Corresponding Author: WeI Huang

Huazhong University of Science and Technology
Wuhan, Hubei CHINA

First Author: Wei Huang

Order of Authors: Wei Huang

Xiaoyun Deng

Abstract: Internet-of-things and big data are important technical means to enhance human
resilience to natural hazards in Earth Science. Continuous geospatial data streams
generated from in-situ monitoring devices provide the first line of defense. An efficient
and high-throughput stream processing engine (SPE) is an indispensable
infrastructure. It remains a challenge for cloud-based distributed computing
frameworks to analyze and process such high-speed and large-volume data in real
time. This challenge has driven growing interest in various edgebased SPEs such as
EdgeWise and DART to address this issue. There is an urgent need to develop a
general-purpose edge SPE with a unique focus on handling the spatial big data
challenge on resource-constrained distributed devices. This work introduces a cloud-
cooperated geospatial SPE named GeoEkuiper for these devices. It abstracts all
operations of spatial data into functions of expressions of Open Geospatial Consortium
(OGC) compliant structured query language (SQL) statements and provides a rule-
oriented interface to facilitate chaining complex SQL processing logic. User-defined
spatial analysis can be easily expressed as a plugin-able extension. It incorporates a
cloud native messaging system to transfer rules to other edge or cloud nodes. By
taking advantage of the elasticity and reliability of the messaging system on cloud
nodes, GeoEkuiper addresses the throughput challenge of resource-constrained
devices with a lightweight scheduling strategy considering runtime metrics.
Experimental results show that GeoEkuiper can support efficient spatial queries and
processing of large-scale spatial stream data on a Raspberry Pi device with enhanced
throughput and provide an effective cross-platform solution to achieve edge
intelligence.

Suggested Reviewers: Zhenlong Li

zli1@gmu.edu

Min Sun
msun@gmu.edu

Powered by Editorial Manager® and ProduXion Manager® from Aries Systems Corporation
Cover Letter

Dear Editor,

I am writing to submit our manuscript titled "GeoEkuiper: A Cloud-Cooperated Geospatial Edge Stream Processing
Engine for Resource-Constrained IoT Devices with Higher Throughput" for consideration for publication in Pervasive
and Mobile Computing. The research presented in this manuscript addresses the challenges of real-time and
high-throughput processing of spatial data streams on resource-constrained distributed devices, which is a topic of
great interest in the field of Internet-of-Things (IoT) and big data.The manuscript introduces a cloud-cooperated
geospatial stream processing engine (SPE) named GeoEkuiper, which abstracts all operations of spatial data into
functions of expressions of Open Geospatial Consortium (OGC) compliant structured query language (SQL) statements.
statements. It provides a rule-oriented interface to facilitate chaining complex SQL processing logic and incorporates a
a cloud-native messaging system to transfer rules to other edge or cloud nodes. Experimental results demonstrate that
that GeoEkuiper can efficiently support spatial queries and processing of large-scale spatial stream data on
resource-constrained devices, such as a Raspberry Pi.We believe that the unique focus of GeoEkuiper on handling the
spatial big data challenge on resource-constrained distributed devices makes it a valuable contribution to the field.
The manuscript also includes a thorough review of related works and a discussion of the challenges and shortcomings
of existing stream processing engines.Thank you for considering our manuscript for publication in Pervasive and
Mobile Computing. We believe that the research presented in this manuscript will be of great interest to your
readership, and we look forward to hearing from you soon.

Sincerely,
Wei Huang
Liuzhou Railway Vocational and Technical College, Liuzhou, Guangxi, China; P.C: 545616
huangwei2913@gmail.com
+86-13247123363
Manuscript File Click here to view linked References

GeoEkuiper: A Cloud-Cooperated Geospatial Edge

Stream Processing Engine for Resource-Constrained
IoT Devices with Higher Throughput

Wei Huang and Xiaoyun Deng1

Abstract
Internet-of-things and big data are important technical means to enhance hu-
man resilience to natural hazards in Earth Science. Continuous geospatial data
streams generated from in-situ monitoring devices provide the first line of de-
fense. An efficient and high-throughput stream processing engine (SPE) is an
indispensable infrastructure. It remains a challenge for cloud-based distributed
computing frameworks to analyze and process such high-speed and large-volume
data in real time. This challenge has driven growing interest in various edge-
based SPEs such as EdgeWise and DART to address this issue. There is an
urgent need to develop a general-purpose edge SPE with a unique focus on han-
dling the spatial big data challenge on resource-constrained distributed devices.
This work introduces a cloud-cooperated geospatial SPE named GeoEkuiper
for these devices. It abstracts all operations of spatial data into functions of
expressions of Open Geospatial Consortium (OGC) compliant structured query
language (SQL) statements and provides a rule-oriented interface to facilitate
chaining complex SQL processing logic. User-defined spatial analysis can be
easily expressed as a plugin-able extension. It incorporates a cloud native mes-
saging system to transfer rules to other edge or cloud nodes. By taking advan-
tage of the elasticity and reliability of the messaging system on cloud nodes,
GeoEkuiper addresses the throughput challenge of resource-constrained devices
with a lightweight scheduling strategy considering runtime metrics. Experi-
mental results show that GeoEkuiper can support efficient spatial queries and
processing of large-scale spatial stream data on a Raspberry Pi device with en-
hanced throughput and provide an effective cross-platform solution to achieve
edge intelligence.
Keywords: Internet of Things, Big Data, Geospatial, Edge Computing,
Stream Processing Engine.

1. Introduction

With the advancement of Internet-of-Things (IoT) and big data technology,

artificial intelligence (AI) empowered smart facilities have become an indispens-
able part of human beings’ efforts to achieve resilience to natural hazards and

Preprint submitted to Elsevier September 17, 2023

man-made disasters in Earth Sciences [1]. In a smart city, an AI-empowered
flooding process prediction model on remote sensing satellites can boost the
safety of citizens[2]. In an intelligent transportation system, a crash prediction
model running in autonomous vehicles can greatly enhance the safety of drivers
and travelers[3]. In a smart factory, a safety robot continuously monitors the
concentration of harmful chemicals such as CO and methane in real-time[4].
Large-scale spatial data, such as location-related data and three-dimensional
geological model data, are constantly being produced by these facilities to pro-
vide the first line of defense against possible chaos and to depict the current
shape, location, and distribution of the multi-dimensional space in which peo-
ple live or work. Therefore, real-time and high-throughput processing of such
spatial data streams on these “Edges” will be beneficial for many applications
that may change science and society.
In the last decade, many stream processing engines, such as Apache Spark[5],
Storm[6], and Flink[7] have provided a standard of handling big data in com-
puting clusters and cloud environments. Now, it is urgent to develop a real-time
cross-platform computing system for stream processing of spatial data in dis-
tributed facilities. To build such a system, four major challenges deserve deep
investigation. The first is adaptiveness; the system must have the ability to
better utilize constrained resources efficiently. The second challenge is the mul-
tiplexing ability to facilitate the expression of complex spatial stream topology
with user-friendly programming models. The third challenge is the ability to
support multiple platforms and provide higher throughput for handling spa-
tial big stream data while keeping the scalability and low-latency in the last
challenge.
Some efforts have been made to handle spatial stream data. For instance,
systems based on Apache Spark include SpatialSpark[8], GeoSpark[9], and Spark-
GIS[10]. All of these systems are based on in-memory cluster computing frame-
works. As used and testified in our previous works[11, 12, 13], these frameworks
are good at parallel processing large volumes of spatial data and support time-
constrained data analysis; however, the efficiency of these systems is based on
the elasticity of computing resources, which is unrealistic and not applicable
to dispersed devices. Spark-based systems are memory-intensive and do not
support real-time processing of stream data. Other systems based on Apache
Flink and Apache Beam include GeoFlink[14] and GeoBeam[15]. GeoFlink is a
distributed and scalable framework that supports real-time query processing of
spatial streams. However, the framework is also based on powerful computing
resources provided by cloud-centralized job schedulers. Distributed devices still
lack efficient spatial stream engines to support the resilient society for human
beings. GeoBeam supports large-scale spatial data processing. However, it con-
siders little about the resource-constrained characteristics of edge devices. The
challenges and shortcomings of state-of-the-art works motivate us to answer the
following question: Can we develop a general SPE for spatial data and support
platform-independent distributed devices?
Fortunately, a few works, such as EdgeWise[16] and Ekuiper (see:https://gith
ub.com/lf-edge/ekuiper), are tailored for real-time processing streaming data in

2
IoT devices. Ekuiper is a lightweight SPE that runs on resource-constrained
edge devices, enables real-time analytics for faster decision-making to under-
stand events as they happen, and supports SQL-based syntax or a visual Flow
editor to compose powerful analytic rules. Unlike most SPEs, Ekuiper adopts
Go language to implement core functionalities and is inherently cloud-native.
The boot footprint of the core functions is less than 12 MB, which shows sig-
nificant potential to enable smart devices. However, Ekuiper does not support
spatial data and operations. Ekuiper is not optimized to run on an individual
device and does not support distributed processing at the time of this writing.
Moreover, there is a lack of works that explore the differences between various
edge SPEs in the literature. The performance gains of these edge stream pro-
cessing engines are still unclear. We believe it is necessary to investigate this in
the article to support the development of edge intelligence technology for the
earth science community.
To this end, the GeoEkuiper presented in this paper is a cloud-cooperated
SPE based on Ekuiper for spatial stream data. We have extended the core of
Ekuiper to support spatial indexing and operations. Specifically, it abstracts all
the spatial data operations into the functions of expressions of OGC-compliant
SQL statements with a rule-oriented interface to facilitate chaining complex
SQL processing logic. The main contributions of this paper are as follows: (1)
GeoEkuiper is designed and implemented as the first open-source edge stream
engine for processing spatial data in heterogeneous distributed devices. (2) A set
of geospatial functions and analysis extensions are provided to support geome-
try operations and analysis. (3) A lightweight scheduling strategy considering
runtime metrics is provided to overcome the wide-existing throughput challenge
for edge devices. (4) GeoEkuiper provides an opportunity for cloud-enhanced
edge intelligence by implicitly transferring rules to other edge devices to further
increase throughput with consideration on the insecurity and unstable networks.
The remainder of this paper is as follows. Section 2 provides background
on edge computing and introduces application scenarios. Section 2 also ana-
lyzes the requirements for edge stream processing engines and reviews related
works along with their limitations. Section 3 presents the proposed GeoEkuiper
architecture and scheduling strategies. The principle of distributed execution
of streaming rules in GeoEkuiper is also described. Section 4 documents the
experiments and results analysis. Section 5 discusses the effects of the proposed
scheduling strategies, scalability issues like deployment time costs, implicit rule
transferring, and the central processing unit (CPU) workload. We also outline
the limitations of our engine. Finally, Section 6 concludes this paper.

2. Motivations and Background

2.1. Emerging Edge Stream Processing Paradigm

Edge stream processing represents a typical application paradigm in edge
computing (EC) that performs continuous computing on any available devices
near data sources, considering mobility and resource constraints of devices. In

3
the last five years, some edge SPEs have been proposed [17, 18]. They can be
classified based on the data flow direction regarding the computing roles taken
by IoT, edge, and cloud nodes [19]. Devices and nodes are interchangeable in
this study if not specified. IoT devices are used to collect data and pull and/or
push data to edges or cloud nodes. Edge devices are mainly used for filtering
raw data and undertaking real-time processing tasks. Since the edges may be
overloaded with tasks, it may act as a gateway that offloads processing tasks
to cloud nodes. Cloud nodes are theoretically unlimited virtual computing and
storage resources that may be saturated with data-intensive and computational-
intensive analysis tasks. Because the roles of IoT and edge may overlap, we
concentrate on cloud-edge cooperation to build an edge SPE and do not strictly
distinguish between IoT and edge nodes.
We have envisaged application scenarios in which edge devices are autonomous.
As shown in Figure 1, patrolling police cars would independently decide to find
the nearest people who need help rather than passively and traditionally ac-
cepting dispatches from call centers in a smart city. Mobile devices are typically
resource-constrained and would be used to make emergency calls to edge nodes.
Edge nodes represent communication and computing infrastructures near the
users and would transmit information to cloud nodes. In intelligent transporta-
tion systems, edge cameras placed in front of tunnels may use deep learning
models with relatively low accuracy and low computation but fast processing
speed to issue warnings about rockfalls. Suspicious rockfalls are sent via 5G
or other wireless technologies to cloud nodes or the nearest trains for further
inspection of rockfall risks [20]. Edge devices such as home cleaning robots and
virtual reality devices are intelligent enough to adapt to the environment while
being easily configured by users.
Based on the emerging stream processing paradigm and potential application
scenes, we anticipate that edge devices should be managed with rules designed
by people. Edge devices must have the ability to sense the spatial-temporal dig-
ital earth using common protocols and spatial data analysis capabilities [9]. On
the one hand, spatial data operations, including spatial relationship judgment
and distance computation, are vital for these emerging applications. There are
eight types of spatial operations between two spatio-temporal objects as fol-
lows: “Disjoint” means neither the boundaries of two objects intersect nor do
the two objects intersect inside; “Within” means the interior of a given object
does not intersect the outside of another object; “Crosses” expresses that the
line-type object intersects the interior of the polygon-type object; “Contain”
means the given object contains the other object; “Touch” means the bound-
aries of two objects intersect; “Overlaps” means two objects intersect inside;
“Equals” means two features are identical; and “Intersect” means two objects
intersect with each other. Based on these spatial relationships, there are three
common spatial query operations: The spatial range query retrieves certain spa-
tial objects within a specific region; The spatial join query combines two spatial
datasets with a certain spatial predicate, for example, an overlapping relation-
ship or distance relationship; The spatial k-Nearest Neighbors (KNN) query
finds the nearest spatial objects to a given spatial object. Spatial indexes are

4
Figure 1: Application scene of the edge stream processing engine (A man makes emergency
calls with mobile devices in a smart city). Edge nodes represent communication and computing
infrastructures near the users and would transmit information to cloud nodes.

vital for accelerating query processing. There are many indexes such as R-Tree,
DTR-Tree, DTI-Tree, and STR trees etc. On the other hand, there are many
IoT protocols such as Constrained Application Protocol (CoAP) and Message
Queue Telemetry Transport (MQTT) [21]. MQTT is the most widely-used ap-
plication protocol, which is built on Transmission Control Protocol (TCP). By
reducing the amount of transport overhead and limiting protocol exchanges,
MQTT is well-suited for unstable networks where edge devices reside. The
publish-subscribe pattern of MQTT provides IoT devices with a novel way to
sense the world with semantic topics [22].

2.2. Edge SPE Requirement Analysis

Edge devices should have the ability to sense the world and support diverse
workloads. The requirements for the edge SPE design include:
1. Multiplexed with enhanced adaptiveness: Edge SPE must support ar-
bitrary topology on limited resources and be adaptive to satisfy high
throughput and scalable requirements.
2. Low latency with enhanced throughput: Low latency is a preliminary
requirement, and must be enhanced with higher throughput for intelligent
devices that require deep learning classification and inference on limited
processors[23].

5
 3. Configurable with enhanced security: Humans should be able to interact
with edge SPE easily. Edge devices should be configurable to react with
outsides, and the number of threads, memory used, and priority of a
stream topology on a single edge device should also be configurable.
4. Geo-spatial data analysis support: edge SPE must support geospatial
analysis, as geospatial query processing is indispensable for many IoT
applications in Earth Sciences.

2.3. State-of-the-art Edge SPEs and Their Limitations

Before detailing our framework, we collected state-of-the-art works in the
last decade and analyzed their shortcomings in this section. We excluded dep-
recated edge stream computing engines, such as Apache Edgent. We collected
all relevant works through Google Scholar, IEEE, and Semantic Scholar with
keywords “Edge computing”, “spatial”, “stream processing”, and “IoT”. Af-
ter filtering the search results, we thoroughly examined each paper to ensure
completeness.
As shown in Table 1, Dart [17] is a scalable and adaptive edge SPE that
uses Peer-to-Peer (P2P) overlay network to organize edge devices. Dart shows
significant potential for reducing the query latency of IoT applications on edge
devices. However, the system architecture considers little about the through-
put of edge devices. Evaluation of Dart’s performance was conducted on local
area networks, which are not referable for the aforementioned requirements.
Moreover, such an engine does not support geospatial data analysis either. The
configuration of applications is still too verbose, which forces users to prepare
all sources and libraries on all computing nodes in advance.
DSCS [18] is a data stream cleaning system that is proprietary. In other
words, such a system cannot be configured to satisfy our needs.
Edgewise [16] is an edge-friendly prototype that uses a fixed-size work pool
to mitigate the congestion of tasks and improve throughput on an edge device.
Such a system considers little about distributed resources. Additionally, the
deployment cost of multiple stream topologies would be high.
Shepherd [24] is a novel stream processing framework that offers efficient dy-
namic placement of operators along a hierarchy of data centers located between
edge devices and the cloud. However, Shepherd is tailored for video stream
processing only.
Amnis [25] is a distributed stream processing platform that optimizes re-
source allocation for stream queries in an edge computing environment by care-
fully considering data locality and resource constraints during physical plan
generation and operator placement. It achieves significant improvements in
end-to-end latency and overall throughput as compared to other SPEs. How-
ever, this engine is not configurable and does not support geospatial operations
either.
GeoFlink, based on the well-known Flink framework, is the only engine
that supports continuous queries over spatial data streams. However, GeoFlink
makes the assumption that computing and storing resources are pervasive and

6
permanent which are not held on edge devices. Still, GeoFlink is hard to run
on resource-constrained edges.
To conclude this section, we found that most works adopt Java programming
language. They either depend on centralized job schedulers to dispatch special
tasks or use closed-source solutions that consider little about spatial data op-
erations in resource-constrained edge nodes. We thus propose a cloud-assisted
SPE for higher throughput analysis of spatial data streams on edge devices in
the next section.
Table 1: Edge stream processing engines (2013-2023). The columns in the table represent
system, programming language (LANG), spatial analysis supports (SAS), year of publication
(YOP), open-sourced (OS), and is-prototype (ISP) respectively.

System LANG SAS YOP OS ISP

DART Java N 2021 Y N
DSCS X N 2021 N X
GeoFlink Java Y 2022 N N
EdgeWise Java N 2019 Y Y
Shepherd Java N 2022 N N
Amnis Java N 2022 N Y
“Y”, “N”, and “X” represent “Yes”, “No”, and “Unknown” respectively.

3. Proposed Edge Stream Processing Engine

3.1. GeoEkuiper Architecture

GeoEkuiper, a spatial data stream processing system based on Ekuiper, sim-
plifies the process with its three-layer architecture: spatial operation, core, and
infrastructure. As shown in Figure 2, GeoEkuiper consists of six main compo-
nents. The first component is the infrastructure layer modules, which provide
virtual or physical computing and storage resources for the upper layers. For
example, a local edge node’s virtual resources may have a small surplus of pow-
erful computing resources with virtualization features to provide computational
resources specifically for mobile edge devices. Cloudlet is an enabling technol-
ogy widely used by Google Glass to perform real-time scene interpretation[26].
The infrastructure layer also provides runtime libraries for the upper layers,
including compiler tool chains, TensorFlow Lite framework, container runtime,
application dependencies, and networking facilities.
The second component of GeoEkuiper is the “Source” module in the core
layer, which acts as the entry point for streams from various data sources such
as Neuron and message queues. A stream is an unbounded sequence of tuples,
and the “Source” module includes many adapters for interacting with other
edge devices using IoT protocols such as LWM2M, CoAP, and MQTT. The
functionality of this module is similar to the spout of Apache Storm, as they
both read tuples from the sources and emit them as new tuples to be processed

7
Figure 2: GeoEkuiper system architecture (adopting a three-layered architecture; the outer-
most icons represent the supported internet-of-things protocols.)

by the Directed Acyclic Graph (DAG) topology. The operator module, not
shown in the figure, has functionality similar to the bolts of the Apache Storm.
Both consume input tuples in the streams and perform transformations such as
running functions, filtering tuples, performing streaming aggregations and joins,
machine learning inference, and more. In addition to subscribing to topics from
MQTT brokers, the “Source” module running on an edge device can also publish
relevant data to other edge devices implicitly. This procedure will be explained
in more detail later.
The third component of GeoEkuiper is the “Sink” module in the core layer,
which serves as the exit point for stream data. This module transmits the
results of incoming messages from the “Source” module to various destinations.
It may use IoT protocols or directly store data in local storage. Other functions
of the “Sink” module include publishing results to peer devices and collecting
performance metrics for later use.
The fourth component of GeoEkuiper is the core, which provides a spatial
query infrastructure for edge nodes and cloud-edge cooperative nodes. This
component consists of nine modules: SQL parser, Logical planner, Physical ex-
ecution, Rule management, Rule chaining, Rule transferring, Profiling, Schedul-
ing, and Storage. Specifically, an OGC-compliant SQL statement is parsed by
the built-in SQL parser module to build an abstract syntax tree. The logical
planner uses keywords of the SQL statement such as “SELECT”, “FROM”,
“WHERE”, fields, tables, conditions, constants, and labels to build a DAG
from source to sink. Each inner node of the topology performs an operation
ranging from simple filtering to complex calculations like deep learning-based

8
classification and inference. After initializing the source and sink modules, the
physical execution module dispatches rules to the infrastructure layer. Unlike
other frameworks that use the Java language, GeoEkuiper provides user-friendly
interfaces for people unfamiliar with Geographic Information System (GIS) op-
erations. The rule management module allows for rule creation, updating, and
controlling rule executions. A rule is an abstraction that includes a SQL state-
ment and one or more actions specified by users using JavaScript Object Nota-
tion (JSON) syntax. The rule chaining module splits and reforms rules. The rule
transfer module is used by the scheduling module to improve engine through-
put. The profiling module collects runtime metrics such as operation latency,
message length, and resource usage. The final module is a storage module that
can be either single-node or distributed storage.
The fifth component of GeoEkuiper is the spatial function registration mod-
ule, which encapsulates the aforementioned spatial operations. These standard
spatial operations are used by the logical planner module to bind functions to
a stream topology.
The final component of GeoEkuiper is the plugin module, which wraps com-
plex spatial analysis functions to meet specific processing needs. For example,
spatial query processing of an SQL statement may require the source module
to build an advanced index to accelerate spatial operations or perform certain
transformations beforehand. Spatial analysis results may also need to be further
processed statistically.

3.2. Proposed Profile-based Scheduling Strategy

To understand our improvement, it would be beneficial to analyze the defi-
ciency of native Ekuiper engine.
Internally, in the native Ekuiper implementation, as shown in Fig. 3, when
a rule is received from the system or input by external users, the RuleManager
component queries the SQLite database via the ExecCreate interface provided
by the RuleProcessor component to determine if a rule with an identical name
exists. If no such rule is found, a description containing the rule name and
corresponding rule content is generated. If the creation is successful, the system
invokes the createRuleState interface provided by the RuleManager component
to generate a RuleState object for the corresponding rule. Among the interfaces
provided by the RuleState component, there exists a Run function that enables
execution of the rule until its deletion. The RuleState component utilizes Ac-
tionSignalStart and ActionSignalStop channels, representing the start and stop
signals. Upon successful creation of a RuleState object, the system invokes the
Plan interface of the LogicalPlanner component to generate a Topology object
containing source, operator, and sink components based on the SQL statements
and action instructions contained within the rule content. When the start func-
tion of the RuleState component is invoked by the system, it activates the start
signal and executes the Open function of the Topology object to initialize sub-
scription methods for source objects, publishing methods for sink objects, and
execution methods for operator objects. More specifically, the Topology object
is a logical description of a rule; the topics a rule subscribes to by source objects

9
are based on the from statement of the SQL statement. Each operation has a
unique name and has one or more output channels to output processing results
to other operation nodes or sinks. The sink node has only one input channel and
many output channels. The component diagram demonstrates the creation of
an input rule; after configuring rule options such as concurrency, buffer length,
quality of service (QoS), and restart strategy, physical execution will execute
the topology. For convenience, we treat rule instances as tasks that have a cor-
responding topology describing data flow from source to sink. Source, sink and
operator are all operations if not specified.

Figure 3: Component Diagram of Ekuiper (Users input rules; the system components execute
the corresponding processing logic.)

Once rules are created, RuleState instances are instantly executed for incom-
ing messages. Ekuiper’s design facilitates real-time processing of input stream
messages. However, this design is not suitable for certain scenarios. For in-
stance, there is a growing demand for devices to intelligently process streaming
data from multiple sources. As a result, multiple execution rules are often de-
signed on smart devices, with hundreds or even thousands of rules controlling
the execution of smart devices. The flow input pattern of each rule may differ,
which is reflected in the frequency and data size of the input stream. Some
input streams have high frequency but process small amounts of data, while
others process large amounts of data but have low frequency of input streams.
Ekuiper’s native implementation does not account for this variability. Addi-
tionally, Ekuiper employs the same pre-allocated resource strategy for all rules,
which may cause unused rules take memory resources which cannot be used by
other active rules. Although applications designed based on Golang coroutines

10
are inherently highly concurrent and occupy few resources, this does not im-
ply that non-substantive coroutines do not consume limited system resources.
Furthermore, as previously discussed, the complexity of the smart algorithms
on which smart devices rely is increasing, necessitating the migration of some
specific smart applications to the cloud for execution, which is not currently
supported by Ekuiper. Ekuiper can process over 10,000 messages per second on
cloud and edge nodes, however, its benchmark is based on simple filtering oper-
ation, which may not reflect real-world complexity. Ekuiper lacks a scheduling
module to adaptively utilize resources.
State-of-the-art works either adopt profile-based or profile-free methods to
improve the efficiency of stream processing engines [27]. The former focuses on
minimizing the average latency of complex topology, but may disturb current
operations if metrics are not carefully designed [28]. The latter methods fo-
cus on avoiding unnecessary back-pressure and must depend on indirect ways
to identify heavy-loaded operations. For example, EdgeWise identifies heavy-
workload operations by monitoring queue size and focuses on optimizing the
operation waiting time in the fixed-sized queue [16]. For human-managed edge
devices, most stream applications either have simple topology with computa-
tional operations or have complex logic with simple operations. Therefore, a
new methodology should be designed.
To this end, we propose profile-based scheduling strategies to optimize through-
put with consideration of practical application scenes, and not to disturb the
execution of topologies. As shown in Figure 4, we can stop the least recently
used rules and restart them later to allocate resources to active rules. We can
dynamically adjust concurrency and queue size based on runtime metrics. More-
over, we can leverage the rule transferring mechanism to enhance the throughput
of the edge devices. Instead of running computational topologies on the edges,
they can also be transferred to cloud nodes.
To explain our improvements, given the input message count λt and the total
message count µt , we model the system throughput as:
n
λt Ct X
ρt = ×( )× Sij , j ∈ N+ (1)
µt Nt i=1

where t represents the sampling time period, Ct the number of completed

rules, Nt the total number of rules, and Si represents the execution number of
a rule Ri , and j represents the number of tuples that go through the topology
chain of the rule.
Strategy 1: Put the least recently used rules in stop status and restart the
rules later. To improve throughput, the strategy is to increase the number of
completed rules Ct . Each running rule will spend system resources to store
and update running status, checkpoints, lockers, and message channels. In
Golang, large capacity channels of complex types would definitely consume more
memory. Therefore, stopping some rules means giving more channels for other
rules, and the throughput will be improved thereafter. Many rules wait for a
special event to occur in a time window and would be idle; therefore, such rules

11
 Figure 4: Optimzing strategies for native Ekuiper.

should be stopped and restarted later.

Strategy 2: For a computational rule, if the cost on peer nodes is signifi-
cantly smaller than that on the local node and the peers are stable, the input
tuples of the source module of the rule should be transferred to peers with higher
priority. The total latency of a completed rule equals the sum of latency paid
at each operation of the topology the rule has. Suppose that we have a simple
topology rule that consists of one source, one operation, and one sink. Let the
data transfer time cost over the network be Td , the execution time cost of the
operation on the local node L be Tl , and on peer node P be Tp , the speedup of

12
the task can be expressed as follows:
TL
speedup = (2)
Tp + Td

Strategy 3: Dynamically change the resources of running rules with consid-

eration of their concurrency and channel sizes. For rules that have a small input
rate of messages but slow processing speed, the channel size should be decreased,
while the number of threads should be increased to increase throughput. For
rules that have a large input rate but fast processing speed, the channel size
should be increased, while the concurrency should be decreased or kept constant.
The rationale behind this strategy is that rules should dynamically adapt to
changing inputs rather than using predefined waiting queues and channel sizes.
To support profile-based scheduling strategies, we have implemented a light-
weight metric sampling method. Tracking the latency of every input message
for a rule is not necessary and can be costly. Instead of recording the processing
latency of each operation for a rule, we recorded the input and output rela-
tionship from source to sinks. We adopted an in-memory database with the
Universally Unique Identifier (UUID). Specifically, we used the Golang memdb
package to store the message id, source name, topic, and input time in the
source table. We stored the sink name, input time of intermediate results, and
their length in the sink table. We also stored the operation name, input time of
messages, messages’ UUIDs, output time of messages, and UUIDs of the output
messages. Golang memdb is able to support any number of concurrent read-
ers without locking and allows a writer to make progress with immutable radix
trees. Whenever a topology of a rule is created, a memdb database is created to
store traceable metrics with these tables. When a message comes from a source
module, we record the time, message id, length, and input time as the metadata
of the message. The source node of the topology will store the message id in
both the source table and operation table. It then outputs a processed message
with a new UUID to operators along with the topology. When the processed
message arrives, the operator node of the topology records the UUID as the
input message and generates a new UUID to store the output message. Since
UUIDs have a near-zero possibility of conflict, we can use them to track rule per-
formance. Note that most SPEs adopt tuples to express this type of abstraction
of messages and tuples represent either messages or processed messages along
the topology path. We use them interchangeably if not specified.
In summary, lightweight profiling is achieved by tracing relationships from
source to sink using UUIDs and memdb for storage. This allows tracking latency
and performance to enable scheduling strategies, without disrupting ongoing
operations.

3.3. Implicit Rule Transferring Mechanism

Cloud-edge cooperative computing is a new paradigm that can enhance
throughput through a rule transferring mechanism. This is the first time that
peer-to-peer-like technology has been combined with edge SPE. Unlike Dart,

13
which uses peer-to-peer technology to schedule stream applications on distributed
nodes, GeoEkuiper adopts a voluntary-based computing paradigm to choose
whether to accept transferred rules or not.
Suppose we have a simple streaming rule that contains one source node,
which subscribes to the demo topic from an MQTT broker, an operator node
that performs deep learning inference, and a sink node that writes the result to
the MQTT broker. As shown in Figure 5, the cooperative computing paradigm
includes an implicit rule execution logic where the source node of the rule run-
ning on edge node A will publish data to edge node B with a topic name that
is its name. Once the rule is transferred to edge node B, the source node of
the transferred rule’s topology on node B will automatically subscribe to the
topic with its name. For convenience, we call the rule on node B a peer rule.
Suppose edge node A is an edge camera and B is a cloud node, the rule latency
on edge node A would be reduced if the operator latency on cloud node B is sig-
nificantly smaller than that on edge node A. Supposing cloud node B completes
the topology earlier, the operator of the peer rule on the cloud node would also
automatically publish the topic. Since the sink node on the edge camera also
subscribes to the topic, the data can then be written out. In order to notify
the rule instance on the edge node A that the whole chain has already been
completed, each sink node would emit a completion message to our engine and
store the incoming messages that have not been processed at same time. Our
engine would stop the rule instance and restart the rule later without loss of any
messages according to the aforementioned scheduling policy. Our rule transfer-
ring mechanism learns from decentralized architecture and volunteer computing
paradigms that have been extensively investigated in recent years [29, 30, 31].
Specifically, similar to blockchain technology that uses libp2p library [32], rules
can run on independent nodes and complete special operations if they implicitly
support pub-sub semantics.
We used NATS to implement the rule transferring mechanism. NATS is a
simple, secure, and highly performant messaging system that supports millions
of messages per second on a single server [33]. Its features include zero-downtime
scaling, self-healing, and resilience. NATS is a connective technology for adap-
tive edge and distributed systems, and is widely-used by companies like Tesla,
PayPal, Walmart, and many others. More specifically, we designed a P2pSource
module that implements the interfaces of the Source module. In the Configure
interface, we configured the Source module to use the messaging service on a
cloud node with a public Internet Protocol (IP) address. After configuration, we
implemented the Open interface to subscribe to specified topics from the cloud-
hosted messaging system. The P2pSource module enables the peer rule task
to seamlessly cooperate with the original rule without modifying other mod-
ules such as LogicalPlanner and RuleProcessor. The cloud-assisted messaging
system enables edge devices to implicitly cooperate in that all edge nodes sub-
scribing to the same topic can obtain the same message. Therefore, each edge
node can accept rule metrics queries from and transfer rule content to other
nodes. To enable inter-edge chaining of rules, we modified Ekuiper’s memory
module and made sink nodes output to the cloud-hosted messaging system as

14
Figure 5: Component Diagram of GeoEkuiper using the implicit rule transferring mechanism.
The left part demonstrates a rule on Edge node A. If the rule is transmitted to Edge node B,
Node A and B would implicitly cooperate to execute the rule. The communication mechanism
adopts cloud-native message systems such as libp2p and NATS.

well. One thing to note is that Ekuiper’s topic naming scheme is slightly dif-
ferent from NATS’. Specifically, NATS uses “*” and “>” as wildcards while
Ekuiper uses “#” and “+” as wildcards. We also added a conversion function to
bridge this semantic divergence. Many may argue why not use an MQTT bro-
ker for cooperation. This is because MQTT brokers do not have semantics for
supporting rule topology. Another question may be whether it is possible for all
edge nodes connecting to a cloud node to become a bottleneck. In fact, typical
cloud centers are already configured with plentiful load-balancing strategies [34].
Another functionality of cloud nodes is that we can use them as bootstrapping
nodes to fabricate overlay networks that support NAT traversal for edge devices
behind local area networks as demonstrated in the next section.
To sum up, the key to efficiency comes from several factors. First, the
advantage of throughput lies in our ability to allocate resources to rules more
efficiently. Second, we use a lock-free memory database, memdb, to support the
storage and tracking of concurrent performance data. Finally, we employ cloud-
native messaging middleware and leverage the rule transfer mechanism to meet
the high-concurrency and computationally intensive scalability requirements of
individual embedded devices.

15
4. Experimental Results

4.1. Experiment Setup

GeoEkuiper is designed for the Edge, so experiments use four nodes to sim-
ulate the cloud-edge cooperative scenario. The cloud node has 2 virtual CPUs
and 2 GB of memory, which is leased from the Tencent cloud (the public IP
address is “175.178.60.176”). We used a Raspberry Pi device as the edge com-
puting device, which has a 64-bit quad-core processor running at 1.5 GHz with
4 GB memory and a 32 GB Sand disk. The other two computing nodes are
virtual machines (VMs) hosted by VMware Workstation 16 Pro hypervisors on
two off-the-shelf personal computers (PCs). One VM is configured with 4 vir-
tual CPUs and 7 GB memory, and the other has 4 virtual CPUs and 4 GB
memory (Intel® Core— i7-10510U CPU @ 1.80 GHz). All of the nodes run
with Ubuntu 22.04 Linux operating system. The Raspberry device and the two
computing nodes are all located on a home network and use a wireless access
point of a TP-Link router device having a maximum of 1,000 Gigabit per second
(Gbps) bandwidth. We constructed an overlay network over these nodes with
WireGuard[35]. WireGuard is a virtual private network (VPN) that utilizes
state-of-the-art cryptography. WireGuard intends to be considerably more per-
formant than OpenVPN[36]. WireGuard is a general-purpose VPN for running
on embedded interfaces and supercomputers alike. The average time to live
(TTL) between the Raspberry Pi device and the cloud node is about 20 ms.
We used emqx 5.0.15 to build a distributed cluster of MQTT brokers. We use
EdgeWise and DART as the edge SPE performance baseline.
Since EdgeWise adopts a master-worker mode, we configured Nimbus on
one of the VM nodes and the supervisors on the Raspberry device. We used
Java— SE Runtime Environment (build 1.8.0 202-b08) to launch Java virtual
machines. All the software versions are listed in Table 2. As shown in Figure 6, a
MQTT cluster is used as the stream source for both EdgeWise and GeoEkuiper.
EdgeWise requires the Apache Zookeeper to coordinate between the Nimbus and
supervisor components. We used Apache ZooKeeper (the latest version is 3.8.1)
to build the coordination services over the same overlay network. DART is also a
Java-based scalable stream engine. It adopts Apache Flume as the run time core
to manage Flume agents in nodes [37]. Flume agents are Java processes that
manage and coordinate the execution of Sources, Channels and Sinks based
on flow definitions. DART uses Pastry to construct a distributed hash table
(DHT)-based P2P overlay network to place, link, and scale operators of stream
applications. We used Apache Flume 1.9.0 and FreePasty 2.1 to configure DART
on all nodes.

4.2. Benchmark Testing

The test cases are designed to cover as many spatial query types as possible.
We used a program to send location information to the MQTT brokers peri-
odically in every 100ms. Our first rule used a spatial point query that counts
the number of points in the stream that have the distance over 5 meters from a
specified point. Specifically, the topology of the testing rule consists of a filter

16
 Table 2: Software Information

Software Version Functionalities

Golang 1.20.3 GeoEkuiper Runtime
supports
Emqx 5.0.15 Building MQTT cluster
Java 1.8.0 202 Provision of JVMs
Ekuiper 1.8.0 GeoEkuiper’s core
WireGuard v1.0.20200513 Building VPNs
Apache storm 2.4.0 EdgeWise’s core
Apache 3.8.1 Coordination services
ZooKeeper
GEOS geos-3.11.2 Geo-processing
NATS v2.9.16 Semantic message passing
Operating sys- Ubuntu 22.04 System supports
tem
VMware® 16.2.3 Provision of VMs
Workstation
JTS Topology 1.18.1 Geo-processing
Suite for EdgeWise
Apache Flume 1.9.0 Dart Runtime core
FreePastry 2.1 Overlay network
for DART

Figure 6: A Message Queue Telemetry Transport (MQTT) cluster built with WireGuard that
provides overlay networking on four distributed nodes.

operation, a window operation, a project operation, and a sink operation. We

measured throughput by counting the number of input messages that have gone
through the topology of the rule. In other words, we treat throughput as the

17
capacity of the edge device to process rules in a given period. Other engines
adopt different ways to calculate this metric. For instance, EdgeWise obtains
throughput by counting the number of tuples that reach the sink, which may
be unstable and inaccurate if many tuples are written out to the sink. We mea-
sured latency by comparing timestamps at the source and sinks. We recorded
the latency of operators along the stream topology using timestamps and UUIDs
for GeoEkuiper. All but our distributed experiment used the Raspberry Pi 4B
device. For some convenience, we call Raspberry Pi 4B devices as Pi devices if
not otherwise specified. To make these engines comparable, we conducted the
following experiments.
For EdgeWise, we implemented the same topology using Java JTS Topology
to process spatial data. More specifically, for the test case 1, we implemented
a spout to read data from a GeoJSON files and emit point objects into the
topology, a filtering bolt to receive the data emitted by the spout and filter
it based on the condition “st distance(other, mine) > 5”, and a bolt receives
the filtered data and counts it with the tumbling window. We began sampling
the execution of the topology instances as soon as the stream applications and
stream rules were submitted. We collected the successful run of the topology
and counted the number of successful runs based on the records at the last
bolts or nodes of the topology. Only one streaming application or a rule runs on
the Pi device to exclude the scheduling effect of the engines in the benchmark
testing. The critical parameters that would impact the performance of stream
applications on the storm cluster are the queue size of supervisor, the memory
capacity, and the number of thrift threads, we set them by defining ”super-
visor.queue.size=128”, ”supervisor.memory.capacity.mb=4096”, and ”supervi-
sor.thrift.threads =16”. Since Niumbus does not participate in the computing
procedure of topology tasks, we configured it with the default parameters.
For DART, we used the flume-ng-mqtt-source plugin to subscribe messages
from the MQTT cluster. we disabled the failed recovery mechanism and set
up a memory channel for transmitting event data from Sources to Sinks. The
”capacity” and ”transactionCapacity” properities of memory channel represent
the maximum number of events that can be cached, and the maximum number
of events that can be processed by each transaction. We have set the value
of these properties to 1. Since DART can automatically scale operators, we
manually disable the flume agent process in cloud node to restrict the DART
scheduler to scale out to the cloud node. The deployment of a stream application
on a Flume cluster involves creating a configuration file that describes the types
of Sources, Sinks, and Channels used by the application, as well as the data flow
between them. The expression of DART for the test case 1 is rather verbose.
We must use a ”spatial-filter” interceptor, which will count the total number of
data entries where the distance between two spatial objects is greater than 5
meters every 5000 milliseconds. The statistical results will be sent to a channel
named ”memory-channel” and eventually written into a text file in the specified
directory. We calculate the throughput of DART by counting the number of
times Sink writes to the text file.
As shown in Figure 7, we found that GeoEkuiper completes 12 topology

18
tasks per minute. There are no successful tasks when we use EdgeWise to exe-
cute the defined topology. This is related to the jar upload phase of EdgeWise.
Most Java Virtual Machine (JVM) based distributed computing engines must
transfer necessary libraries before executing tasks on target nodes. Based on
our experiments, we found that even the point query stream application would
need to package around 170 MB executable jars, which is very difficult and time-
consuming to transfer from the Nimbus node to the supervisor over the unstable
wireless networks. Many may argue that streaming applications that use Edge-
wise engines should not consider the deployment cost. Based on our experiment
results, we found that the number of completed topology tasks is less than 10
when using EdgeWise. The number surpasses over 120 when using GeoEkuiper.
We found that the throughput performance of DART is better than EdgeWise,
but it is far from reaching half of the performance of GeoEkuiper. Apache
Flume applications need to be deployed first and then scheduled later. There-
fore, there is no cost to the library’s transmission. However, the scheduler would
spend a lot of time on routing and launching tasks. The results demonstrate
the deficiency of EdgeWise. GeoEkuiper can achieve about 10X throughput
over EdgeWise and 4X throughput over DART. The ”Computed Throughput”
in the bar plot indicates that the number of processed messages is about 2 to
3X that of the incoming message count, which reflects GeoEkuiper does well
in the spatial operations in the Pi device with lower latency. We used ”Com-
puted Throughput” to represent the throughput improvement of our scheduling
strategies for the GeoEkuiper engine. Note that “Computed Throughput” is
a dimensionless value obtained by applying Formula 1 and incorporating the
performance parameters we have obtained.
Test case 1: Every five seconds, count the number of points that have a
distance over 5 meters from a specified point.
GeoEkuiper rule:
”select count(*) from TS where st distance(other,mine)>5 group by TUM-
BLINGWINDOW(ss, 5)”;
EdgeWise topology:
builder.setSpout(”spout”, new SpatialSpout(), 1);
builder.setBolt(”filter”, new FilterBolt(), 1).shuffleGrouping(”spout”);
builder.setBolt(”count”, new CountBolt(). withTumblingWindow(Duration(5,
TimeUnit.SECONDS), 1).shuffleGrouping(”filter”);
DART configuration:
agent.sources = mqtt-source
agent.channels = memory-channel
agent.sinks = file-sink
agent.sources.mqtt-source.interceptors = spatial-filter
agent.sources.mqtt-source.interceptors.spatial-filter.threshold = 5
agent.sources.mqtt-source.interceptors.spatial-filter.interval = 5000
agent.sources.mqtt-source.channels = memory-channel
agent.sinks.file-sink.channel = memory-channel
The second test case is about the spatial range query. A typical application
scene is that a robot in a smart factory continuously queries whether it has

19
Figure 7: Spatial point query throughput comparison of GeoEkuiper, DART, and EdgeWise
on a Raspberry Pi 4 device. The missing values of EdgeWise represent no successful runs of
the tested topology.

entered the special locations for executing specified tasks. We implemented the
topology for EdgeWise by defining one spout and filtering bolt. Specifically, the
spout reads from MQTT brokers and emits tuples to the filtering bolt. The
filtering bolt uses a geometry intersecting method to determine whether two
polygons intersect. We used a program to periodically publish polygon data to
the MQTT cluster every 100 ms. After waiting for the completion of EdgeWise
topology and the allocation of task resources on the Pi device, we compared
the number of completed topology for EdgeWise and GeoEkuiper. The config-
uration of DART is the same as test case 1. We defined the ”spatial intersect”
interceptor to judge intersections without waiting for a time window.
Test case 2: Find whether a specified spatial feature is located in a given
polygon range.
GeoEkuiper rule:
”select * from TS where st intersects
(POLYGON ((0.0 0.0, 10.0 0.0, 10.0 10.0, 0.0 10.0, 0.0 0.0)),POLYGON
((1.0 1.0, 11.0 1.0, 11.0 11.0, 1.0 11.0, 1.0 1.0)))=true”;
EdgeWise topology:
builder.setSpout(”spout”,new MQTTSpout(),1);
builder.setBolt(”filtering”,new FilterBolt(), 1).shuffleGrouping(”spout”);

20
 DART configuration:
agent.sources = mqtt-source
agent.channels = memory-channel
agent.sinks = file-sink
agent.sources.mqtt-source.interceptors = spatial-intersect
agent.sources.mqtt-source.channels = memory-channel
agent.sinks.file-sink.channel = memory-channel
As shown in Figure 8, we found that the number of processed topology
tasks would equal the number of incoming tuples. For GeoEkuiper, there are
600 tasks completed in a minute, and 6,000 tasks completed in ten minutes.
Meanwhile, the number is less than 100 in a minute and 800 in ten minutes
on EdgeWise. The results demonstrate that GeoEkuiper performs quite well in
real-time processing of spatial range queries and is 10x faster than EdgeWise
regarding spatial range queries. Based on our experiments, the average latency
of a task is about 0.07 s on GeoEkuiper. From the “Computed throughput”
bar, we can infer that GeoEkuiper can withstand even more incoming tuples
at a higher speed. Many may argue that the experiments do not consider the
parallelism of the topology for EdgeWise. We know that bolts can share the
number of parallel tasks at runtime, however, the number of Worker processes
is constrained due to the JVM setting. All parallel tasks compete for the re-
sources of these worker processes. We also found that the average latency of
the streaming application is about 0.36 s when using DART. On Pi devices, the
average latency is about 0.48 s. GeoEkuiper performance is about 2x faster than
DART. In fact, three computing nodes participated for the DART application
in this context. The scaling mechanism of DART is indeed beneficial. Despite
this, GeoEkuiper has a much shorter query latency on a single embedded device
than DART.
The third test case is about the spatial joint query. A potential application
scene is an edge device that monitors the location of two robots, and analyzes
whether they may collide. For GeoEkuiper, the rule content contains a win-
dow operation that waits for messages from the two streams named ”src1” and
”src2”, a join operation, and a projection operation to count the number of
tuples whose polygons intersect. Similarly, we defined two spouts, one joint
bolt, one window bolt and one counting bolt for EdgeWise with the Topology-
Builder object. We used a program to concurrently publish geometry objects to
MQTT brokers. Since Apache Flume does not support joint query operations,
for DART, channels are independent units, therefore, it does not support joint
query operations either. We omitted the DART experiments from the test case.
Test case 3: Find out whether a spatial feature contains another spatial
feature, and count the numbers.
GeoEkuiper rule:
”SELECT count(*) FROM src1 INNER JOIN src2 on st contains(src1.geom,
src2.geom) GROUP BY TUMBLINGWINDOW(ss, 5)”;
EdgeWise topology:
builder.setSpout(”src1”, new Src1Spout());
builder.setSpout(”src2”, new Src2Spout());

21
Figure 8: Comparing Spatial Range Query Throughput Among GeoEkuiper, DART, and
EdgeWise on a Raspberry Pi 4 Device: Processing a Stream Tuple Containing a Polygon
Every 100 ms.

builder.setBolt(”join”, new JoinBolt()) .fieldsGrouping(”src1”,

new Fields(”joinKey”)) .fieldsGrouping(”src2”, new Fields(”joinKey”));
builder.setBolt(”window”, new WindowBolt().
withTumblingWindow(BaseWindowedBolt.Duration. seconds(5)))
.shuffleGrouping(”join”);
builder.setBolt(”count”, new CountBolt()).
shuffleGrouping(”window”);
DART configuration: (Omitted)
As shown in Figure 9, we found that there are about 12 tasks completed
in a minute when using GeoEkuiper, and 120 tasks would be processed in ten
minutes. The results show that GeoEkuiper does quite well in the spatial joint
query. The average time cost for the rule is about 2.08 s based on our exper-
iments. We tracked deeply into the procedure of the topology running on the
Pi device. We found that EdgeWise consumes a lot of time on heartbeat noti-
fication of workers’ status to the storm servers. The thread loading, executing,
and revoking would occur very frequently, which can impact the whole perfor-
mance of the topology tasks. As aforementioned, the preparation of tuples of
the topology consumes much of the time, which makes EdgeWise complete less
than 12 tasks in ten minutes.

22
Figure 9: Spatial join query throughput comparison of GeoEkuiper and EdgeWise on a Rasp-
berry Pi 4B device. A stream tuple containing a polygon is processed by the engines every
100 ms.

The fourth test case is about the KNN query. For GeoEkuiper, the rule
content contains a projection operation that waits for messages from a stream
named “src1” and calculates the distance between the given coordinate point
and the geometries in the messages, an order operation that sorts the results,
and a sink operation to write out results. For EdgeWise, there should be two
bolts to express the same logic. For DART, we defined three components: a
source, a channel, and a sink. The relationship between these components is
as follows: The source is responsible for receiving data and passing it to the
interceptors for processing. We define two interceptors: distance-interceptor and
knn-interceptor. These interceptors are executed in sequence, first calculating
the distance to the specified point, and then finding the 10 nearest geographic
data points. The processed data is sent to the channel, which is responsible for
caching the data and passing it to the sink, and finally, the file-sink writes the
results to a local file. We implemented a program to send 100 geometries to the
MQTT cluster in every 100 ms. Each geometry has 10 vertices. We measure
the throughput of the DART engine by counting the number of times it writes
to a text file during its runtime.
Test case 4: Find the 10 nearest geographical spatial objects to a specified
spatial coordinate point.

23
 GeoEkuiper rule:
”select * from src1 order by st distance(src1.geom, POINT(20 40)) limit 10”;
EdgeWise topology:
builder.setSpout(”src1”, new Src1Spout());
builder.setBolt(”distance”, new DistanceBolt())
.shuffleGrouping(”src1”);
builder.setBolt(”knn”, new KNearestNeighborsBolt(10))
.shuffleGrouping(”distance”);
DART configuration:
agent.sources = mqtt-source
agent.channels = memory-channel
agent.sinks = file-sink
agent.sources.mqtt-source.interceptors =
distance-interceptor knn-interceptor
agent.sources.mqtt-source.interceptors.
distance-interceptor.type = DistanceInterceptoragent.sources.
mqtt-source.interceptors.knn-interceptor.type = KNearestNeighborsIntercep-
tor agent.sources.mqtt-source.interceptors.knn-interceptor.k = 10
agent.sources.mqtt-source.channels = memory-channel
agent.sinks.file-sink.channel = memory-channel
As shown in Figure 10, we found that the throughput of GeoEkuiper keeps
high throughtput as in the second test case. For EdgeWise and DART, the
throughput decreased. EdgeWise decreased by about 20%, while DART was
very unstable, with a decrease in throughput of about 40%. The results show
that GeoEkuiper has the potential to execute complex processing chains stably.
The reason for the decrease in EdgeWise’s throughput may be related to the
increased computational complexity of bolts and the delay caused by JVM mem-
ory allocation management. We found that the average task delay increased to
about 800 ms and memory was intensively used. As for DART, we believe that
the reason for this decrease in throughput is related to the allocation of DART’s
automatic operators among nodes. It may not be a problem in high-speed lim-
ited local area networks, but it has a greater impact on the wireless network
used in this experiment.
To investigate the effect of tuple size on the performance of these engines,
we conducted experiments using the spatial range query and spatial join query
from the second and third test cases. All experimental settings were the same,
except for varying the number of vertices in the polygon. We observed changes
in latency and throughput by adjusting the vertex count from 1,000 to 10,000,
with each vertex containing two 8-byte coordinate values. Disregarding the
overhead of the MQTT protocol encapsulation, we sent messages ranging from
16 KB to 160 KB to the MQTT cluster every 100 ms in the second experiment.
During a one-minute period, we carefully monitored the input message count,
processed message count, completed rule topology count, and average rule com-
pletion time. Each experimental configuration runs ten times to measure the
performance impact. Our findings revealed that when using GeoEkuiper, the
completed rule topology count ranged from 82 to 122, and the average rule

24
Figure 10: Comparing KNN Query Throughput Among GeoEkuiper, DART, and EdgeWise
on a Raspberry Pi 4B Device: Processing a Stream Tuple Containing 100 Polygons Every 100
ms.

completion time ranged from 0.03 seconds to 0.34 seconds. As shown in Figure
11, in contrast, when using EdgeWise, the completed rule topology count is
from 25 to 60, and the average rule completion time varies from 2 seconds to
5 seconds. These results indicate that as the size of the geospatial dataset and
the amount of data to be processed increase, GeoEkuiper exhibits a 2 to 4 times
higher throughput and approximately 10X lower average rule execution delay
compared to EdgeWise.
The results show that all engines experience a decrease in throughput as
the tuple size in the streaming data increases. However, it is evident that
GeoEkuiper does not exhibit a linear decrease. Upon examining the network
message passing and CPU load, we observed that the CPU load remains stable,
while network message passing increases significantly. Therefore, it is believed
that the main reason for the decrease in throughput lies in the network perfor-
mance overhead of MQTT message passing. Since the implicit rule propagation
mechanism is not enabled, there are no messages passing via wireless networks
to the cloud messaging system. Although DART achieved comparable perfor-
mance as GeoEkuiper with the scaling mechanism, the performance has a big
variation.
We continued observing the performance impact of different stream data

25
Figure 11: Comparison of throughput among GeoEkuiper, EdgeWise, and DART as tuple size
varies: spatial range query performance on a Raspberry Pi 4B during a one-minute runtime.

sizes on the GeoEkuiper and EdgeWise engines during spatial joint queries, and
it was found that when sending stream tuples of varying sizes to the MQTT
cluster every second, the GeoEkuiper engine completed rule topologies between
1 and 12 times, with an average rule latency time ranging from 1.7 to 3.1 seconds.
However, as shown in Figure 12, when using the EdgeWise engine, the number
of completed rule topologies was equal to or less than 1, with an average task
processing time exceeding 10 seconds. The results indicate that GeoEkuiper is
significantly more efficient than EdgeWise when handling larger spatial datasets
of stream tuples. It was observed that the number of completed rule topologies
decrease significantly when messages containing geometry objects with more
than 7,000 vertices are passed to the engine. This could be attributed to the
aforementioned network transmission limitations. Another possible reason is
that the time required for data matching, decompression, and merging increases
dramatically when performing joint operations across different stream objects
that require mutual data dependencies.

4.3. GeoEkuiper performance

To testify the concurrency capacity of GeoEkuiper, we used the tested topol-
ogy shown in Figure 13. We emulated the real scene that a MQTT client pub-
lishes polygon objects to the random topics named “SourceX” and “SourceY”

26
Figure 12: Comparison of throughput between GeoEkuiper and EdgeWise as tuple size varies:
spatial joint query performance on a Raspberry Pi 4B during a one-minute runtime.

(X and Y ranging from 1 to 10). Rules are dynamically added to GeoEquiper

and would subscribe to different topics. These polygon objects are sent to the
MQTT cluster by the client in every 100 ms, and each polygon object has 400
points (6,400 bytes). As introduced earlier, we used the memedb module to col-
lect metrics about the ingested message counts, the processed message counts,
the completed rule counts, the number of completed rules, and task latency
of the rules. We used a bash script to randomly create a specified number of
rules in each experiment. We force the created rules for each subscriber to two
different streaming topics. After waiting for the completion of the deployment
of these rules, we collected the relevant performance metrics.
As shown in Figure 14, the average latency of rules shows that the perfor-
mance is not strictly determined by the number of rules that simultaneously
run on the GeoEkuiper engine. When the system holds 100 rules, the average
latency of the rules is about 7.4 s. When the system schedules 200 rules, the
average latency is about 4.23 s to 6.98 s. When there are over 1,000 rules, the
average latency is about 3 s. Some intuitions may think that the more rules
running, the time of each rule topology task would be longer. The reason why
the count-intuitions result occurs is highly correlated with that the inputs to the
MQTT clusters would not cover all topic requirements of rules that subscribe
to different topics. In other words, the number of rules awaiting the inputs

27
Figure 13: The tested topology contains the following operations: 1) Message Queue Telemetry
Transport (MQTT) brokers randomly publish geometry objects; 2) Two independent window
operations wait for input tuples; 3) A spatial join operation performs the geospatial ”Contain”
operation; 4) A sink operation records the results.

would be larger than the number of rules being processed. When the number
of rules increases, the average latency of these processed rules decreases. The
results show that GeoEkuiper supports multiple rules execution efficiently in
resource-constrained devices.

Figure 14: Average latency of rules running on the GeoEkuiper engine on a Raspberry Pi 4B
device, with different numbers of rules executing the tested topology.

To understand the throughput baseline of GeoEkuiper, we continued our

experiments by comparing the multiple rules performance on GeoEkuiper with
the number of corresponding stream topologies on EdgeWise. It is difficult to

28
submit over 100 topologies to the Pi device when we use EdgeWise. Therefore,
we plan to compare the throughput of GeoEkuiper with EdgeWise using only
100 rules and applications in this context. Many may ask why we cannot deploy
as many topologies on the Pi device. In fact, each submission of an EdgeWise
application contains a whole copy of Java libraries that need a large amount of
memory and disk spaces. Although the topology of the applications is the same,
they cannot share anything between these applications.
As shown in Figure 15, the black bars show that GeoEkuiper achieves better
throughput over EdgeWise. Based on our experiments, when using GeoEkuiper,
the number of tasks that finish the tested topology is 88 a minute. While there
are 15 tasks per minute when using EdgeWise. when using GeoEkuiper, the
number of tasks that finish the tested topology is 714 in ten minutes. While
the number of tasks is 140 in ten minutes when we used EdgeWise. The results
show that the throughput of GeoEkuiper can be 5X to that of EdgeWise. We
also found that the latency of a task using GeoEkuiper is about 15 s, which is
nearly 3x less than EdgeWise. This is because GeoEkuiper always stops rules
that are least used, and dynamically changes the channel size for running rules.
Another reason that the achieved higher throughput of GeoEkuiper is that it
would automatically scale the concurrency threads for rules that have the fasted
processed speed, which enables the minimum latency for higher incoming rate
tuples. Based on our experiment not shown here, when using GeoEkuiper, we
observed that the minimum latency of a rule task is 1.45 s, and the maximum
latency of a rule task is 62.34 s. We divided deep into all of the rules and found
that only a special rule instance is always waiting too much time. This can be
ascribed to the rule that subscribes to topics that are not very frequently used.
EdgeWise seems to be very stable with processing latency. This may be highly
corrected with the fixed pool thread design for EdgeWise.

5. Discussion
Designing scalable, higher-throughput edge stream engines for resource con-
strained devices remains a great challenge. As discussed earlier, Edge SPEs
should provide quick responses to satisfy management requirements for timely
deployment and configuration of operations. We adopted the deployment time
cost as one of the most important scalability metrics[17]. We compared the
time cost of EdgeWise, DART, and GeoEkuiper by deploying different numbers
of rules and applications. Note that we compared the deployment time cost
of EdgeWise and GeoEkuiper on a virtual machine node. Deployment using
DART is conducted in the cluster. As shown in Figure 16, the deployment
time cost of EdgeWise is nearly linear with the increasing number of stream
applications. We see that GeoEkuiper requires only 350 seconds to dispatch
1,000 stream rules, while EdgeWise consumes over 4,000 seconds to deploy the
same number of stream applications on the VM node. The results show that
GeoEkuiper has an overwhelming advantage in scalability on edge devices. The
time it takes for DART to configure and deploy the same number of applica-
tions to all cluster nodes is 1.8 to 2.3 times less than EdgeWise deploying the

29
Figure 15: Number of completed rule instance executions using 100 rules corresponding to
the tested topology, comparing the throughput of GeoEkuiper and EdgeWise engines on a
Raspberry Pi 4B device.

same number of applications to the VM node, but overall, this speed is about 5
times slower compared to GeoEkuiper. Most state-of-the-art SPEs adopt Java
to distribute operators to available nodes, however, the preparation phase takes
a very long time, which is not applicable for edge devices. Additionally, most
edge SPEs require coordinated services from external components, which may
bring about additional burdens for managing distributed devices.
We continued our experiments to investigate the effect of the proposed
scheduling strategies for GeoEkuiper. We used the tested topology as previously
introduced. We tested the efficiency of our engine with or without scheduling
modules. Note that we implemented the scheduling module as a time ticker that
would be triggered every five seconds. Therefore, it is much easier to disable this
functionality. We used the same script to create rules and a Golang program to
publish geometry data to the MQTT cluster. By using average rule latency as a
metric and feeding engines with different numbers of stream rules, we recorded
at least ten times metrics in each experiment and depicted average results in
the following table. As shown in Table 3, we found that time costs were rather
similar when using GeoEkuiper with and without a scheduling strategy. When
the number of rules surpasses 1,000, we can see the effect of our scheduling
strategies. When the number of rules is 2,000, the average latency for rule tasks

30
Figure 16: Comparison of Deployment Time Costs Among GeoEkuiper, DART, and Edge-
Wise.

is 3.38 s if scheduling strategies are used, while latency is 6.45 s when we do not
use a scheduling module. The results demonstrate that a scheduling strategy
can benefit applications that may define a large number of rules on a single
device.
We conducted our final experiment to investigate the effect of the rule trans-
ferring mechanism. Test case 5 is a typical application scenario for many intel-
ligent devices. Typically, edge devices such as automotive vehicles may require
continuous transfer of object detection results from camera video streams to
cloud centers rather than transferring huge volumes of raw data to the cloud. Be-
cause many edge devices do not have computational accelerators such as Graph-
ics Processing Units (GPUs), there is a strong need to offload computation-
intensive tasks to cloud centers. We first used the command ”./kuiper create
stream tfdemo ’() WITH (FORMAT=”BINARY”, DATASOURCE=”tfdemo”)’”
to create a stream named tfdemo. Then, we used a single-shot multibox de-
tector (SSD) MobileNet V1 model to test the object detection throughput of
GeoEkuiper in this experiment. SSD MobileNet is a type of neural network ar-
chitecture that predicts bounding boxes and classes directly from feature maps
in one single pass. MobileNet has been widely used in computer vision[38].
As previously introduced, GeoEkuiper adopts a plugin model that allows us to
use other languages to express complex analysis functions. The pre-trained DL

31
Table 3: The average time cost of the tested rule using GeoEkuiper with and without the
scheduling module.

Number of Rules With scheduling(s) Without scheduling(s)

100 7.2 7.4
200 4.23 4.33
300 3.16 4.36
400 3.21 4.54
500 3.18 4.78
600 3.13 4.56
700 3.10 4.45
800 3.04 4.68
900 3.04 4.64
1000 3.01 5.13
1500 2.99 5.77
2000 3.38 6.45

model is about 4.1 MB. We implemented the object detection plugin using the
TensorFlow-Lite library. We used a Golang program to publish a picture to the
MQTT cluster with the tfdemo topic. Every second, 160 KB of raw data from a
picture would be sent to the MQTT cluster. We used a VM node with 4 virtual
CPUs and 7 GB of memory as the rule transferring target.
Test case 5: Continuously log the object detection results of a deep learning
model from camera.
GeoEkuiper rule:
”SELECT Classify Image(self) FROM tfdemo”;
We used a metric to measure engine throughput during our experiment in
terms of how many images could be processed per second. As shown in Figure
17, we found that 5 images can be processed per minute on a Pi device with-
out a GPU and without using GeoEkuiper’s rule transferring mechanism. The
number of images processed by the engine is linearly related to execution time.
In other words, the average latency for object detection algorithms is about
10 seconds on Pi devices with GeoEkuiper when its rule transferring module
is disabled. Based on our experiments, we found that 55 images could be pro-
cessed in 180 seconds when using GeoEkuiper’s rule transferring mechanism.
Results show that it would take about 8 seconds to process an image of 160
KB when using GeoEkuiper with its rule transferring mechanism. According
to Equation 2, there would be a 1.25X speedup. In fact, enhanced throughput
is quite beneficial for distributed devices. Internally, our scheduling strategy
captures process latency for the Pi device and VM node operators and chooses
to dispatch all incoming images to VM nodes. Many may argue that such a
designation only takes into account computing power for one nearby device, as
NATS systems would dispatch all tuples to all nearby devices without consider-
ing the performance differences among these devices. We suggest using queues
to dispatch more tuples to other volunteer devices using control theory. We will

32
explore a voluntary-based computing paradigm in the near future.

Figure 17: Number of 160 KB images processed on a Raspberry Pi 4B device using

GeoEkuiper, with and without the rule-transferring mechanism. The processing algorithm
is a Single Shot Multibox Detector (SSD) MobileNet model (mobilenet quant v1 224.tflite).

We tracked CPU workload while using GeoEkuiper to process multiple rule

instances on a Pi device. As shown in Figure 18, GeoEkuiper consumes about
24% of the CPU to deploy 1,000 rules in context. These rules were previously
introduced. After the deployment phase, the average CPU workload is about
3.3%. Results indicate that GeoEkuiper can easily support over a thousand
rule instances on Pi devices. The memory used by the GeoEkuiper engine is
less than 400 MB, based on our observations. We also tracked execution phases
for multiple concurrent rule instances. We use Netdata tool to monitor CPU
workload. As shown in Figure 19, the average CPU workload is about 10%.
Results show that CPU overhead is an acceptable trade-off for maintaining
performance and could be further reduced if stream data speeds were not so
high.
Although GeoEkuiper maintains the characteristic of low-latency processing
of high-speed spatial data streams while further improving throughput, there
is still a lot of room for optimization, and we believe that the necessary direc-
tions for improvement include: 1) How to further reduce the consumption of
memory space and computing resources while monitoring the performance of
stream processing tasks. 2) When GeoEkuiper deals with large-scale window

33
aggregation function operations, how to develop geospatial indexes specifically
for stream processing tasks. 3) How can GeoEkuiper support hot plugging of
complex analysis tasks, because currently, complex analysis tasks still require
pre-compilation and designation of dependent library functions. 4) GeoEkuiper
has not yet implemented a reliable task state management.

Figure 18: The CPU workload of GeoEkuiper engines deploying 1,000 rules on a Raspberry
Pi 4B device. During the deployment phase, the average CPU workload of GeoEkuiper is
about 24%. After the deployment, the workload is about 3.3%. Blue color represents system
workload, red color curve represents user workload.

6. Conclusion

In this study, we designed a higher-throughput spatial stream processing

engine called GeoEkuiper for resource constrained edge devices. We introduced
the emerging edge stream processing paradigm, outlined their requirements, and
reviewed state-of-the-art works from the last decade and their limitations. We
adopted the concept that edge represents any computing and network resources
along the path from data generation to data processing if the rationale that com-
puting should happen at the proximity of data sources is followed. Edge devices
should process stream data in real-time whenever possible. We incorporated a
novel computing paradigm that considers the autonomous characteristics from
the viewpoint of distributed devices. Unlike most state-of-the-art works that

34
Figure 19: The CPU workload of GeoEkuiper engines executing 1,000 rules on a Raspberry Pi
4B device. Blue color represents system workload, red color curve represents user workload.

build distributed edge SPEs from the management viewpoint of cloud centers,
our proposed engine adopts a layered architectural style to achieve real-time
processing of spatial stream data either locally or in a distributed manner. The
total size of our engine is less than 30 MB. GeoEkuiper requires fewer computing
resources and external dependencies. GeoEkuiper extends the core functionality
of Ekuiper to support on-the-fly processing of spatial stream data. Based on our
experiments, the throughput of spatial point queries, spatial range queries, and
spatial joint queries can be an order of magnitude higher compared to EdgeWise.
GeoEkuiper can easily support thousands of parallel tasks with much fewer
memory resources. Additionally, we proposed profile-based scheduling strategies
to further improve the performance of our engine. Our rule transfer mechanism
further improves deep learning influencing throughput. Our engine is open-
sourced on GitHub (see: https://github.com/huangwei2913/GeoEkuiper). We
believe that the engine can provide an effective cross-platform solution to achieve
edge intelligence for IoT devices in intelligent transportation systems.

References

[1] Y. Liu, M. Peng, G. Shou, Y. Chen, S. Chen, Toward edge intelligence:

Multiaccess edge computing for 5g and internet of things, IEEE Internet of
Things Journal 7 (8) (2020) 6722–6747. doi:10.1109/JIOT.2020.3004500.
[2] C. Chen, J. Jiang, Y. Zhou, N. Lv, X. Liang, S. Wan, An edge intelligence
empowered flooding process prediction using internet of things in smart
city, Journal of Parallel and Distributed Computing 165 (2022) 66–78.

35
 doi:https://doi.org/10.1016/j.jpdc.2022.03.010.
URL https://www.sciencedirect.com/science/article/pii/S0743731522000612
[3] Z. Halim, R. Kalsoom, S. Bashir, G. Abbas, Artificial intelligence tech-
niques for driving safety and vehicle crash prediction, Artificial Intelligence
Review 46 (3) (2016) 351–387. doi:10.1007/s10462-016-9467-9.
URL https://doi.org/10.1007/s10462-016-9467-9
[4] A. Bouras, A. Gutierrez-Galvez, J. Burgués, Y. Bouzid, A. Pardo,
M. Guiatni, S. Marco, Concentration map reconstruction for gas source
location using nano quadcopters: Metal oxide semiconductor sensor
implementation and indoor experiments validation, Measurement 213
(2023) 112638. doi:https://doi.org/10.1016/j.measurement.2023.112638.
URL https://www.sciencedirect.com/science/article/pii/S0263224123002026
[5] M. A. Alsheikh, D. Niyato, S. Lin, H.-p. Tan, Z. Han, Mobile big data an-
alytics using deep learning and apache spark, IEEE Network 30 (3) (2016)
22–29. doi:10.1109/MNET.2016.7474340.

[6] S. Chintapalli, D. Dagit, B. Evans, R. Farivar, T. Graves, M. Holderbaugh,

Z. Liu, K. Nusbaum, K. Patil, B. J. Peng, P. Poulosky, Benchmarking
streaming computation engines: Storm, flink and spark streaming, in: 2016
IEEE International Parallel and Distributed Processing Symposium Work-
shops (IPDPSW), 2016, pp. 1789–1792. doi:10.1109/IPDPSW.2016.138.

[7] H. Li, J. Xia, W. Luo, H. Fang, Cost-efficient scheduling of streaming ap-

plications in apache flink on cloud, IEEE Transactions on Big Data (2022)
1–16doi:10.1109/TBDATA.2022.3233031.
[8] R. T. Whitman, B. G. Marsh, M. B. Park, E. G. Hoel, Distributed spatial
and spatio-temporal join on apache spark, ACM Trans. Spatial Algorithms
Syst. 5 (1) (jun 2019). doi:10.1145/3325135.
URL https://doi.org/10.1145/3325135
[9] J. Yu, J. Wu, M. Sarwat, Geospark: A cluster computing framework for
processing large-scale spatial data, in: Proceedings of the 23rd SIGSPA-
TIAL International Conference on Advances in Geographic Information
Systems, SIGSPATIAL ’15, Association for Computing Machinery, New
York, NY, USA, 2015. doi:10.1145/2820783.2820860.
URL https://doi.org/10.1145/2820783.2820860
[10] F. Baig, H. Vo, T. Kurc, J. Saltz, F. Wang, Sparkgis: Resource aware effi-
cient in-memory spatial query processing, in: Proceedings of the 25th ACM
SIGSPATIAL International Conference on Advances in Geographic Infor-
mation Systems, SIGSPATIAL ’17, Association for Computing Machinery,
New York, NY, USA, 2017. doi:10.1145/3139958.3140019.
URL https://doi.org/10.1145/3139958.3140019

36
[11] W. Huang, L. Meng, D. Zhang, W. Zhang, In-memory parallel processing
of massive remotely sensed data using an apache spark on hadoop yarn
model, IEEE Journal of Selected Topics in Applied Earth Observations and
Remote Sensing 10 (1) (2017) 3–19. doi:10.1109/JSTARS.2016.2547020.
[12] W. Huang, W. Zhang, D. Zhang, L. Meng, Elastic spatial query process-
ing in openstack cloud computing environment for time-constraint data
analysis, ISPRS International Journal of Geo-Information 6 (3) (2017).
doi:10.3390/ijgi6030084.
URL https://www.mdpi.com/2220-9964/6/3/84
[13] W. Huang, J. Zhou, D. Zhang, On-the-fly fusion of remotely-sensed big data
using an elastic computing paradigm with a containerized spark engine on
kubernetes, Sensors 21 (9) (2021). doi:10.3390/s21092971.
URL https://www.mdpi.com/1424-8220/21/9/2971
[14] S. A. Shaikh, H. Kitagawa, A. Matono, K. Mariam, K.-S. Kim, Geoflink:
An efficient and scalable spatial data stream management system, IEEE
Access 10 (2022) 24909–24935. doi:10.1109/ACCESS.2022.3154063.
[15] Z. He, G. Liu, X. Ma, Q. Chen, Geobeam: A distributed computing
framework for spatial data, Computers & Geosciences 131 (2019) 15–22.
doi:https://doi.org/10.1016/j.cageo.2019.06.003.
URL https://www.sciencedirect.com/science/article/pii/S0098300418311336

[16] X. Fu, T. Ghaffar, J. C. Davis, D. Lee, EdgeWise: A better stream pro-

cessing engine for the edge, in: 2019 USENIX Annual Technical Conference
(USENIX ATC 19), USENIX Association, Renton, WA, 2019, pp. 929–946.
URL http://www.usenix.org/conference/atc19/presentation/fu
[17] P. Liu, D. D. Silva, L. Hu, DART: A scalable and adaptive edge stream pro-
cessing engine, in: 2021 USENIX Annual Technical Conference (USENIX
ATC 21), USENIX Association, 2021, pp. 239–252.
URL https://www.usenix.org/conference/atc21/presentation/liu
[18] D. Sun, S. Xue, H. Wu, J. Wu, A data stream cleaning sys-
tem using edge intelligence for smart city industrial environments,
IEEE Transactions on Industrial Informatics 18 (2) (2022) 1165–1174.
doi:10.1109/TII.2021.3077865.
[19] X. Wang, Z. Zhou, P. Han, T. Meng, G. Sun, J. Zhai, Edge-stream: a
stream processing approach for distributed applications on a hierarchical
edge-computing system, in: 2020 IEEE/ACM Symposium on Edge Com-
puting (SEC), 2020, pp. 14–27. doi:10.1109/SEC50012.2020.00009.
[20] C. Chen, L. Zhu, H. Zhao, 5g-enabled edge intelligence for autonomous
train control: A practical perspective, in: 2022 IEEE 25th International
Conference on Intelligent Transportation Systems (ITSC), 2022, pp. 1790–
1794. doi:10.1109/ITSC55140.2022.9922178.

37
[21] J. Tournier, F. Lesueur, F. L. Mouël, L. Guyon, H. Ben-Hassine,
A survey of iot protocols and their security issues through the
lens of a generic iot stack, Internet of Things 16 (2021) 100264.
doi:https://doi.org/10.1016/j.iot.2020.100264.
URL https://www.sciencedirect.com/science/article/pii/S2542660520300986

[22] B. Mishra, A. Kertesz, The use of mqtt in m2m and iot systems: A survey,
IEEE Access 8 (2020) 201071–201086. doi:10.1109/ACCESS.2020.3035849.
[23] T. Cassimon, S. Vanneste, S. Bosmans, S. Mercelis, P. Hellinckx, De-
signing resource-constrained neural networks using neural architecture
search targeting embedded devices, Internet of Things 12 (2020) 100234.
doi:https://doi.org/10.1016/j.iot.2020.100234.
URL https://www.sciencedirect.com/science/article/pii/S2542660520300676
[24] B. Ramprasad, P. Mishra, M. Thiessen, H. Chen, A. da Silva Veith,
M. Gabel, O. Balmau, A. Chow, E. de Lara, Shepherd: Seamless stream
processing on the edge, in: 2022 IEEE/ACM 7th Symposium on Edge
Computing (SEC), 2022, pp. 40–53. doi:10.1109/SEC54971.2022.00011.
[25] J. Xu, B. Palanisamy, Q. Wang, H. Ludwig, S. Gopisetty, Am-
nis: Optimized stream processing for edge computing, Jour-
nal of Parallel and Distributed Computing 160 (2022) 49–64.
doi:https://doi.org/10.1016/j.jpdc.2021.10.001.
URL https://www.sciencedirect.com/science/article/pii/S0743731521001921
[26] K. Bilal, O. Khalid, A. Erbad, S. U. Khan, Potentials, trends,
and prospects in edge technologies: Fog, cloudlet, mobile edge,
and micro data centers, Computer Networks 130 (2018) 94–120.
doi:https://doi.org/10.1016/j.comnet.2017.10.002.
URL https://www.sciencedirect.com/science/article/pii/S1389128617303778
[27] H. Isah, T. Abughofa, S. Mahfuz, D. Ajerla, F. Zulkernine, S. Khan, A
survey of distributed data stream processing frameworks, IEEE Access 7
(2019) 154300–154316. doi:10.1109/ACCESS.2019.2946884.
[28]

[29] T. V. Doan, Y. Psaras, J. Ott, V. Bajpai, Toward decentralized cloud stor-

age with ipfs: Opportunities, challenges, and future considerations, IEEE
Internet Computing 26 (6) (2022) 7–15. doi:10.1109/MIC.2022.3209804.
[30] A. Antelmi, G. D’Ambrosio, A. Petta, L. Serra, C. Spagnuolo, A volunteer
computing architecture for computational workflows on decentralized web,
IEEE Access 10 (2022) 98993–99010. doi:10.1109/ACCESS.2022.3207167.
[31] P. Agostinho, D. Dias, L. Veiga, Smartpubsub: Content-based pub-sub on
ipfs, in: 2022 IEEE 47th Conference on Local Computer Networks (LCN),
2022, pp. 327–330. doi:10.1109/LCN53696.2022.9843795.

38
[32] S. Göndör, H. Yildiz, M. Westerkamp, A. Küupper, Blade: A blockchain-
supported architecture for decentralized services, in: 2022 IEEE Inter-
national Conference on Decentralized Applications and Infrastructures
(DAPPS), 2022, pp. 19–26. doi:10.1109/DAPPS55202.2022.00011.
[33] S. Luu, A. Ravindran, A. D. Pazho, H. Tabkhi, Vei: A multicloud
edge gateway for computer vision in iot, in: Proceedings of the 1st
Workshop on Middleware for the Edge, MIDDLEWEDGE ’22, Associ-
ation for Computing Machinery, New York, NY, USA, 2022, p. 6–11.
doi:10.1145/3565385.3565877.
URL https://doi.org/10.1145/3565385.3565877

[34] D. A. Shafiq, N. Jhanjhi, A. Abdullah, Load balancing techniques in

cloud computing environment: A review, Journal of King Saud Uni-
versity - Computer and Information Sciences 34 (7) (2022) 3910–3933.
doi:https://doi.org/10.1016/j.jksuci.2021.02.007.
URL https://www.sciencedirect.com/science/article/pii/S131915782100046X

[35] B. Lipp, B. Blanchet, K. Bhargavan, A mechanised cryptographic proof

of the wireguard virtual private network protocol, in: 2019 IEEE Euro-
pean Symposium on Security and Privacy (EuroS&P), 2019, pp. 231–246.
doi:10.1109/EuroSP.2019.00026.
[36] S. Mackey, I. Mihov, A. Nosenko, F. Vega, Y. Cheng, A performance com-
parison of wireguard and openvpn, in: Proceedings of the Tenth ACM
Conference on Data and Application Security and Privacy, CODASPY
’20, Association for Computing Machinery, New York, NY, USA, 2020,
p. 162–164. doi:10.1145/3374664.3379532.
URL https://doi.org/10.1145/3374664.3379532

[37] G.-A. Tenesaca-Luna, D. Imba, M.-B. Mora-Arciniegas, V. Segarra-

Faggioni, R. L. Ramı́rez-Coronel, Use of apache flume in the big data en-
vironment for processing and evaluation of the data quality of the twitter
social network, in: M. Botto-Tobar, L. Barba-Maggi, J. González-Huerta,
P. Villacrés-Cevallos, O. S. Gómez, M. I. Uvidia-Fassler (Eds.), Information
and Communication Technologies of Ecuador (TIC.EC), Springer Interna-
tional Publishing, Cham, 2019, pp. 314–326.
[38] C. Yu, B. Xiao, C. Gao, L. Yuan, L. Zhang, N. Sang, J. Wang, Lite-
hrnet: A lightweight high-resolution network, 2021 IEEE/CVF Conference
on Computer Vision and Pattern Recognition (CVPR) (2021) 10435–10445.

39
LaTeX Source File

Click here to access/download

LaTeX Source File
PVC.zip
Video

Click here to access/download

Video
Presentation of GeoEkuiper.mkv
Video Still

Click here to access/download

Video Still
spatial join query on Raspbery Pi.mkv
Declaration of Interest Statement

Declaration of interests

☒The authors declare that they have no known competing financial interests or personal relationships
that could have appeared to influence the work reported in this paper.

☐The authors declare the following financial interests/personal relationships which may be considered
as potential competing interests: