Real-Time Edge Construction (RTEC)

• Real-Time Edge Construction (RTEC) is a mechanism that dynamically attaches query data, such as Wi-Fi fingerprints, to reference graphs for improved indoor localization.
• It employs an attention-based edge formation approach and fixed neighbor budgets to adaptively integrate new data with pre-built offline graphs.
• Beyond localization, RTEC represents a family of edge-native pipelines used in decentralized knowledge transfer, surveillance analytics, and 3D reconstruction under strict latency and resource constraints.

Real-Time Edge Construction (RTEC) denotes, in its most explicit published use, an inference-time graph adaptation mechanism within the GATE indoor-localization framework, where a newly observed Wi-Fi Received Signal Strength (RSS) fingerprint is inserted as a temporary node and connected online to reference-point nodes through attention-based edge formation (Gufran et al., 15 Jul 2025). Across adjacent literatures, the phrase also functions as a broader descriptor for edge-native construction or reconstruction workflows that must operate under latency, bandwidth, privacy, and resource constraints, including decentralized knowledge transfer, surveillance analytics, multi-view 3D reconstruction, SLAM, and streaming scientific imaging (Goldstein et al., 2020). The terminology is not uniform, however: in symbolic event recognition, RTEC instead denotes an Event Calculus dialect for run-time reasoning rather than edge construction (Artikis et al., 2015).

1. Terminology, scope, and acronym ambiguity

The explicit phrase “Real-Time Edge Construction” appears as a named component in “GATE: Graph Attention Neural Networks with Real-Time Edge Construction for Robust Indoor Localization using Mobile Embedded Devices,” where RTEC is the mechanism that dynamically attaches a query fingerprint to a graph at inference time (Gufran et al., 15 Jul 2025). In that setting, the term refers neither to generic edge computing nor to graph-edge discovery in the abstract, but to a concrete, query-conditioned graph-building step for localization.

The acronym is not stable across the literature. “Reactive Reasoning with the Event Calculus” uses RTEC for an Event Calculus dialect that supports composite event recognition over streams of time-stamped events, with windowing and interval-based reasoning; that usage is technically unrelated to graph adaptation or edge-native reconstruction (Artikis et al., 2015). Conversely, “Real-Time Decentralized knowledge Transfer at the Edge” does not define a separate formal acronym named RTEC, but its appendix describes a decentralized, pairwise, real-time transfer scheme at the edge that is explicitly characterized as “RTEC-style” in the supplied material (Goldstein et al., 2020).

Reference	Use of “RTEC”	Technical object
“GATE” (Gufran et al., 15 Jul 2025)	Explicit term	Dynamic inference-time graph attachment
“Reactive Reasoning with the Event Calculus” (Artikis et al., 2015)	Different acronym usage	Event Calculus dialect for run-time reasoning
“Real-Time Decentralized knowledge Transfer at the Edge” (Goldstein et al., 2020)	RTEC-style interpretation	Decentralized pairwise transfer at the edge

This suggests that “RTEC” is best treated as an overloaded term. In a narrow sense, it denotes the GATE graph-construction module. In a broader systems sense, it describes edge-native construction pipelines that selectively assemble structure, state, or reconstructions close to data sources under stringent runtime constraints.

2. Core formulation in GATE: query-conditioned graph construction

In GATE, RTEC is introduced to address a mismatch between static graph construction and online RSS fingerprinting under device heterogeneity and non-uniform noise (Gufran et al., 15 Jul 2025). The paper first writes a fingerprint as

$F = [RSS_{AP1}, RSS_{AP2}, \ldots, RSS_{APN}],$

then contrasts a Euclidean-style disturbance model,

$$F_{euclidean} = [(d, RSS_{AP1}), (d, RSS_{AP2}), \ldots, (d, RSS_{APN})],$$

with a non-Euclidean one,

$$F_{non-euclidean} = [(d_{1}, RSS_{1}), (d_{2}, RSS_{2}), \ldots, (d_{N}, RSS_{N})].$$

The stated implication is that a graph built once from offline reference fingerprints may be poorly matched to a new online sample coming from a different device or operating condition (Gufran et al., 15 Jul 2025).

The offline graph is defined as

$G = (V, E, F),$

where nodes correspond to reference points and node features are RSS fingerprints. Offline construction is described as hybrid: edges are first formed based on indoor topology, and attention scores are then assigned according to fingerprint similarity. The paper defines the GATE attention score as

$a_{i,j} = \frac{F_i \cdot F_j}{|F_i| . |F_j|},$

the message-passed vector as

$MSG_i = \sum_{j \in N(i)} (A_{i,j}.F_j),$

and the Attention Hyperspace Vector (AHV) as

$AHV_{i,j} = \frac{F_i}{|F_i|} \; \⨀ \; \frac{F_j}{|F_j|}.$

The Multi-Dimensional Hyperspace Vector (MDHV) is then formed from the original fingerprint vector, the message-passed vector, and the AHV tensor; that MDHV is the input to a custom GCN trained offline with learning rate 0.001, sparse categorical cross-entropy, ReLU activations, 1000 epochs, and a 604 KB model footprint for GATE-Full (Gufran et al., 15 Jul 2025).

RTEC proper appears at online inference. A new fingerprint $F_{new}$ is treated as a temporary node. The paper states that attention is computed between this temporary node and all stored reference-point nodes using

$$∝_{new,i}= \frac{F_{new} \cdot F_i}{|F_{new}| . |F_i|},$$

after which edges are assigned to the “most relevant” nodes while keeping a fixed number of neighbors for dimensional consistency. The text does not provide explicit pseudocode, an adjacency-matrix formula, or a threshold rule; however, it states that retained edges are those connecting the temporary node to selected reference points, and that the fixed neighbor budget is controlled experimentally by $NB$, the percentage of nodes connected per node (Gufran et al., 15 Jul 2025). The associated online aggregation is written as

$$F_{euclidean} = [(d, RSS_{AP1}), (d, RSS_{AP2}), \ldots, (d, RSS_{APN})],$$0

The technical significance of this mechanism is twofold. First, it makes the graph around the query sample dynamic rather than fixed, which the paper positions as a response to device heterogeneity, environmental variability, and dense-access-point “blind spot” effects. Second, it couples edge construction directly to downstream representation learning: the selected neighbors determine both the message vector and the AHV tensor, and thus the MDHV seen by the pretrained GCN (Gufran et al., 15 Jul 2025).

3. Broader RTEC-style architectures at the edge

Outside GATE, closely related work treats “real-time edge construction” as a systems pattern rather than a single algorithm. In “Real-Time Decentralized knowledge Transfer at the Edge,” each agent trains locally while selectively incorporating remote outputs and layer-wise transfer from other agents. Source selection is driven by task overlap and novelty,

$$F_{euclidean} = [(d, RSS_{AP1}), (d, RSS_{AP2}), \ldots, (d, RSS_{APN})],$$1

architectural compatibility,

$$F_{euclidean} = [(d, RSS_{AP1}), (d, RSS_{AP2}), \ldots, (d, RSS_{APN})],$$2

and per-class source statistics, while the target loss balances local supervision and remote consistency: $$F_{euclidean} = [(d, RSS_{AP1}), (d, RSS_{AP2}), \ldots, (d, RSS_{APN})],$$3

$$F_{euclidean} = [(d, RSS_{AP1}), (d, RSS_{AP2}), \ldots, (d, RSS_{APN})],$$4

$$F_{euclidean} = [(d, RSS_{AP1}), (d, RSS_{AP2}), \ldots, (d, RSS_{APN})],$$5

This is not graph construction in the GATE sense, but it is a selective, metadata-driven construction of collaboration edges among edge agents (Goldstein et al., 2020).

In edge computer-vision monitoring, “Towards Edge-Based Idle State Detection in Construction Machinery Using Surveillance Cameras” frames a lightweight, modular pipeline that processes video streams through object detection, tracking, and idle-state identification on CPU-only edge devices (Küpers et al., 1 Jun 2025). The task-specific construction step is not a graph but a short temporal state estimate computed from tracked bounding-box dynamics. The paper defines Area Difference and Centroid Difference as

$$F_{euclidean} = [(d, RSS_{AP1}), (d, RSS_{AP2}), \ldots, (d, RSS_{APN})],$$6

$$F_{euclidean} = [(d, RSS_{AP1}), (d, RSS_{AP2}), \ldots, (d, RSS_{APN})],$$7

summarizes them with a median-based deviation statistic, and feeds $$F_{euclidean} = [(d, RSS_{AP1}), (d, RSS_{AP2}), \ldots, (d, RSS_{APN})],$$8 and $$F_{euclidean} = [(d, RSS_{AP1}), (d, RSS_{AP2}), \ldots, (d, RSS_{APN})],$$9 into a logistic model

$$F_{non-euclidean} = [(d_{1}, RSS_{1}), (d_{2}, RSS_{2}), \ldots, (d_{N}, RSS_{N})].$$0

Within the supplied material, this is presented as a representative edge-analytics construction task rather than a formal RTEC acronym usage (Küpers et al., 1 Jun 2025).

Several 3D reconstruction papers extend the same design pattern to sensing, networking, and compute orchestration. “Reinforcement Learning-Driven Edge Management for Reliable Multi-view 3D Reconstruction” uses two cooperative Q-learning agents for camera selection and server selection, with reliability defined as threshold satisfaction in both quality and latency (Mounesan et al., 9 Oct 2025). “Reliable Multi-view 3D Reconstruction for ‘Just-in-time’ Edge Environments” instead formulates camera selection through portfolio-theoretic risk minimization under correlated disruptions (Absur et al., 21 Aug 2025). “An Edge Computing-based Photo Crowdsourcing Framework for Real-time 3D Reconstruction” selects a representative set of photos under coverage and cost constraints before reconstructing with VisualSFM at the MEC server (Yu et al., 2020). “Edge Robotics: Edge-Computing-Accelerated Multi-Robot Simultaneous Localization and Mapping” moves local map construction and preparative fusion to edge servers in a robot–edge–cloud hierarchy (Huang et al., 2021). “Deep learning at the edge enables real-time streaming ptychographic imaging” splits responsibilities between edge-side surrogate inversion and downstream HPC retraining, so that detector streams can be inverted online while model maintenance happens asynchronously (Babu et al., 2022). Taken together, these works suggest a broader RTEC family in which edge construction consists of selective evidence acquisition, local inference or fusion, and only limited upstream synchronization.

4. Real-time constraints, selectivity, and edge locality

A recurring property of RTEC-like systems is selective rather than exhaustive construction. In decentralized knowledge transfer, the point is explicitly to avoid raw-data exchange while still letting nodes benefit from others’ models, statistics, and outputs (Goldstein et al., 2020). In photo crowdsourcing for 3D reconstruction, the MEC server first gathers photo metadata and only then requests uploads for a selected subset of representative photos, minimizing monetary cost subject to target-area coverage (Yu et al., 2020). In GATE, the same selectivity appears as a fixed-budget neighborhood around a temporary query node rather than an all-to-all graph attachment (Gufran et al., 15 Jul 2025).

This selectivity is usually driven by the same four pressures: latency, bandwidth, privacy, and limited local compute. The construction-machinery pipeline is explicitly designed for resource-constrained, CPU-based devices and treats cloud dependence as undesirable because of latency, bandwidth, hardware cost, and privacy concerns (Küpers et al., 1 Jun 2025). RecSLAM argues that cloud-only multi-robot SLAM is impractical because robot-side SLAM remains expensive and cloud communication dominates latency; its solution is to offload raw sensor data to edge servers, perform local map construction and preparative fusion there, and send only edge maps upstream for global fusion (Huang et al., 2021). The ptychography workflow makes the same division in a different domain: immediate, low-latency reconstruction is handled by an embedded GPU near the detector, while iterative reconstruction on HPC generates labels and updated models (Babu et al., 2022).

Related work also shows that “real-time” in RTEC contexts is rarely a single latency number. In GATE, the relevant unit is end-to-end query inference on a mobile embedded device (Gufran et al., 15 Jul 2025). In construction-machinery monitoring, the idle classifier operates over fixed temporal windows, and the supplied material notes that the practical decision window used for logistic-regression training was 1.5 seconds at 10 FPS (Küpers et al., 1 Jun 2025). In edge photo crowdsourcing, “real-time” means seconds-to-tens-of-seconds photo collection and local reconstruction rather than sub-frame reaction (Yu et al., 2020). This suggests that RTEC is best understood as a latency-sensitive design philosophy whose operative time scale depends on the underlying sensing and construction task.

A further implication is that topology matters. PM-EdgeMap, although framed around process mining rather than geometric reconstruction, formalizes distributed event streams with explicit source locations and models processing time as

$$F_{non-euclidean} = [(d_{1}, RSS_{1}), (d_{2}, RSS_{2}), \ldots, (d_{N}, RSS_{N})].$$1

This suggests one way to analyze RTEC-like pipelines when construction itself is distributed across heterogeneous edge, fog, and cloud nodes (Reiter et al., 10 Jun 2026).

5. Empirical evidence and deployment characteristics

The empirical record associated with RTEC is heterogeneous because the term covers different technical objects. Still, several concrete reports establish what edge-side construction currently looks like in practice.

System	Reported figures	Context
GATE-Full	1.6x to 4.72x lower mean localization errors; 1.85x to 4.57x lower worst-case errors; 871 ms mean inference latency; 604.0 KB model	Indoor localization with explicit RTEC (Gufran et al., 15 Jul 2025)
Edge-IMI	Detection $$F_{non-euclidean} = [(d_{1}, RSS_{1}), (d_{2}, RSS_{2}), \ldots, (d_{N}, RSS_{N})].$$2; idle accuracy $$F_{non-euclidean} = [(d_{1}, RSS_{1}), (d_{2}, RSS_{2}), \ldots, (d_{N}, RSS_{N})].$$3; idle $$F_{non-euclidean} = [(d_{1}, RSS_{1}), (d_{2}, RSS_{2}), \ldots, (d_{N}, RSS_{N})].$$4; 8.5 FPS after OpenVINO; 9.4 FPS with FP16 and 11% mAP50-95 drop	CPU-only construction machinery monitoring (Küpers et al., 1 Jun 2025)
RL edge management	Adaptive Q-Learning reliability $$F_{non-euclidean} = [(d_{1}, RSS_{1}), (d_{2}, RSS_{2}), \ldots, (d_{N}, RSS_{N})].$$5 vs $$F_{non-euclidean} = [(d_{1}, RSS_{1}), (d_{2}, RSS_{2}), \ldots, (d_{N}, RSS_{N})].$$6 Round-Robin and $$F_{non-euclidean} = [(d_{1}, RSS_{1}), (d_{2}, RSS_{2}), \ldots, (d_{N}, RSS_{N})].$$7 Latency-Greedy	Reliable multi-view 3D reconstruction (Mounesan et al., 9 Oct 2025)
RecSLAM	Up to $$F_{non-euclidean} = [(d_{1}, RSS_{1}), (d_{2}, RSS_{2}), \ldots, (d_{N}, RSS_{N})].$$8 latency reduction; robot mean CPU load $$F_{non-euclidean} = [(d_{1}, RSS_{1}), (d_{2}, RSS_{2}), \ldots, (d_{N}, RSS_{N})].$$9 vs $G = (V, E, F),$0 in cloud approach	Multi-robot laser SLAM (Huang et al., 2021)
EC-PCS	28% delay reduction over TPU-ES; at $G = (V, E, F),$1 vs $G = (V, E, F),$2 coverage, 25% photo uploading and 36.1% monetary-cost reduction on GATE dataset	Edge photo crowdsourcing for 3D reconstruction (Yu et al., 2020)
Streaming ptychography	Detector stream up to 2 kHz; AGX Xavier TensorRT batch-1 inference $G = (V, E, F),$3 ms; step size 2.5x/5x larger for 80%/90% acceptable accuracy	Edge/HPC scientific imaging (Babu et al., 2022)
PM-EdgeMap	Cloudlet 0.027 s/event and $G = (V, E, F),$4; MCC 0.036 s/event and $G = (V, E, F),$5	Edge-cloud process analysis (Reiter et al., 10 Jun 2026)

Within GATE itself, the neighbor-budget parameter $G = (V, E, F),$6 is central. The paper reports that the recommended deployment region is $G = (V, E, F),$7 from 1% to 10%, where localization error stays below 2 m, end-to-end latency remains under 1 second, and EDP stays below 0.6 J/s; by contrast, RTEC-only latency rises to 842 ms at $G = (V, E, F),$8, and full RTEC+GCN latency rises to 1616 ms at $G = (V, E, F),$9 (Gufran et al., 15 Jul 2025). The same study reports a model size of 604.0 KB, EDP of 0.543 J/s, and $a_{i,j} = \frac{F_i \cdot F_j}{|F_i| . |F_j|},$0 FLOP for GATE-Full, indicating that the explicit RTEC mechanism was engineered for deployment on mobile embedded devices rather than server-class inference (Gufran et al., 15 Jul 2025).

Across the broader literature, the strongest quantitative pattern is that edge-side selectivity often matters more than raw model complexity. Edge-IMI becomes near-real-time or better-than-input-rate only after OpenVINO conversion of a lightweight detector (Küpers et al., 1 Jun 2025). EC-PCS reduces delay by selecting representative photos before upload instead of uploading all available images (Yu et al., 2020). RecSLAM reduces collaborative SLAM latency by moving local map construction and preparative fusion from robots and cloud into the edge tier (Huang et al., 2021). The ptychography system alters the acquisition contract itself by using a learned surrogate that tolerates no-overlap or low-count regimes, thereby reducing both reconstruction latency and sensing burden (Babu et al., 2022).

6. Limitations, controversies, and open directions

The first limitation is terminological. Because RTEC already names an Event Calculus dialect in one literature, references to “RTEC” are ambiguous unless the application domain is explicit (Artikis et al., 2015). In practice, the most precise usage is the one in GATE, where RTEC is a specific online graph-construction mechanism for RSS localization (Gufran et al., 15 Jul 2025).

The second limitation is technical underspecification in the explicit RTEC formulation. The GATE paper does not provide a full pseudocode listing for online edge construction, an explicit adjacency-matrix formula, a threshold or temperature term, an online topology-preservation constraint, exact handling of self-loops, or complete preprocessing rules for missing access-point values (Gufran et al., 15 Jul 2025). The supplied material therefore supports the mechanism clearly at the level of score computation, fixed-budget neighbor selection, and MDHV construction, but not every implementation detail of a reproducible graph-building kernel.

A third limitation is that many RTEC-like systems optimize orchestration rather than the construction back-end itself. The RL-based multi-view reconstruction work manages camera and server choices under dynamic disruptions but does not propose a new reconstruction algorithm (Mounesan et al., 9 Oct 2025). The portfolio-theoretic “just-in-time” edge reconstruction paper optimizes camera subsets based on expected usable resolution and correlated failure risk, but its quality proxy is not a geometric reconstruction objective and its analysis assumes static cameras (Absur et al., 21 Aug 2025). EC-PCS improves selection, upload scheduling, and caching around VisualSFM rather than redefining the underlying SFM backend (Yu et al., 2020). This suggests that “RTEC” often advances by systems co-design—selection, placement, scheduling, caching—rather than by replacing reconstruction mathematics outright.

A fourth limitation concerns real-time semantics. Several papers use “real-time” pragmatically. The construction-machinery pipeline makes idle decisions over a 1.5-second window in its reported training setup (Küpers et al., 1 Jun 2025). RecSLAM reports seconds-scale end-to-end latency rather than hard real-time guarantees (Huang et al., 2021). The ptychography workflow is online at the edge but depends on asynchronous HPC supervision for retraining and validation (Babu et al., 2022). The implication is not that the term is misleading, but that RTEC currently denotes low-latency operational usefulness rather than deterministic hard real-time analysis.

Privacy and visibility assumptions also remain unresolved. The decentralized knowledge-transfer framework avoids raw-data sharing, yet it assumes access to remote model availability, architecture information, learned parameters, and class-distribution statistics; the supplied material explicitly notes that such outputs and metadata can still leak sensitive information (Goldstein et al., 2020). More generally, edge-side construction reduces cloud exposure but does not by itself guarantee privacy or resilience.

Taken as a whole, the literature supports two defensible meanings of Real-Time Edge Construction. In the strict sense, it is the query-conditioned, attention-based graph attachment mechanism introduced in GATE for robust indoor localization on mobile embedded devices (Gufran et al., 15 Jul 2025). In the broader systems sense, it is a family of edge-native construction pipelines that assemble graphs, states, maps, reconstructions, or task-specific representations close to the data source, using selectivity, locality, and resource-aware orchestration to meet task-dependent latency targets. The present state of the art suggests that the concept is technically productive, but still methodologically fragmented.