Exploring Distance Query Processing in Edge Computing Environments

TL;DR

This work tackles scalable exact distance querying on dynamic road networks where centralized approaches incur high latency and update costs. It proposes an edge-computing architecture that partitions the graph into districts connected by border vertices and uses Border Labeling together with a local-bound mechanism to support cross-district queries and timely updates. At its core, the approach builds hub labeling under a 2-hop framework, with $d_G(s,t) = \lambda(s,t,L)$ and $\lambda(s,t,L) = \min_{h \in L(s) \cap L(t)} (d_G(s,h) + d_G(h,t))$, and uses hub pushing with PLL-style pruning to keep label sizes compact. Empirical results on multiple road networks show ultra-fast query responses, competitive indexing times, and robustness to dynamic updates, highlighting the practicality of edge-centric distance querying for real-time GIS.

Abstract

In the context of changing travel behaviors and the expanding user base of Geographic Information System (GIS) services, conventional centralized architectures responsible for handling shortest distance queries are facing increasing challenges, such as heightened load pressure and longer response times. To mitigate these concerns, this study is the first to develop an edge computing framework specially tailored for processing distance queries. In conjunction with this innovative system, we have developed a straightforward, yet effective, labeling technique termed Border Labeling. Furthermore, we have devised and implemented a range of query strategies intended to capitalize on the capabilities of the edge computing infrastructure. Our experiments demonstrate that our solution surpasses other methods in terms of both indexing time and query speed across various road network datasets. The empirical evidence from our experiments supports the claim that our edge computing architecture significantly reduces the latency encountered by end-users, thus markedly decreasing their waiting times.

Figures (1)

• Figure 1: Example hub pushing situations. In each case, the yellow vertex denotes the root of one pushing operation, the blue vertices denote those which were visited and labeled in the pushing, the pink vertices denote those which were visited but pruned, and the gray vertices denote roots of previous pushing operations.