HaLert: Mesh Networks & LLM Hallucination Alerts
- HaLert is defined as a dual-purpose system: a resilient smart-city disaster response architecture reusing IoT infrastructure via a split Wi‑Fi HaLow data plane and LoRa control network.
- Its smart-city design employs a distinct high-throughput data plane and a robust low-rate SDN control plane, ensuring reliable emergency communications even in adverse conditions.
- In the LLM context, HaLert-style layers act as lightweight, always-on monitors to assess hallucination risk without full model retraining, thereby enhancing trust in AI outputs.
Searching arXiv for papers on “HaLert” and closely related uses in the literature. HaLert denotes two distinct constructs in recent arXiv literature. In networking and smart-city research, it is a resilient post-disaster communication architecture that reuses smart-city IoT infrastructure through a Wi‑Fi HaLow IEEE 802.11s mesh network for emergency data services and a LoRa controlled-flooding mesh for SDN-based control (Ortigoso et al., 10 Jul 2025). In later large-language-model research, “HaLert” or “HaLert-style” is used as a design target for lightweight hallucination-alert layers that sit around an LLM and estimate hallucination risk from internal or output-side signals without requiring full retraining of the base model (Shapiro et al., 2 Feb 2026, Itkin, 10 Jun 2026, Liu et al., 21 Jul 2025).
1. HaLert as a post-disaster smart-city architecture
HaLert was introduced as “a resilient architecture for smart cities based on a Wi‑Fi HaLow IEEE 802.11s mesh network, whose resources can be readily reallocated to support a emergency communication system to exchange messages (including text, location, image, audio, and video) between citizens, authorities, and between both parties” (Ortigoso et al., 10 Jul 2025). Its starting assumption is that catastrophes and disasters are unpredictable, and that reusing existing infrastructures to develop alternative communication strategies after disasters is essential to minimise the impact of these events on the population’s ability to communicate and promptly receive alerts from authorities (Ortigoso et al., 10 Jul 2025).
The architecture is explicitly framed around the smart-city condition of “dense and geographically distributed IoT networks,” treating those networks as an emergency asset rather than only as routine urban infrastructure (Ortigoso et al., 10 Jul 2025). In that formulation, HaLert is not merely an ad hoc mesh overlay. It is a city-scale contingency design in which smart traffic lights, sensors, access points, gateways, and local servers are reallocated to sustain emergency messaging, authority coordination, and local situational awareness when conventional mobile or Internet infrastructure is unavailable or degraded (Ortigoso et al., 10 Jul 2025).
A central design choice is the split between a higher-throughput data plane and a lower-rate control plane. Wi‑Fi HaLow carries citizen and authority communications and IoT data, while a LoRa mesh supports remote monitoring and configuration of the network through the SDN paradigm (Ortigoso et al., 10 Jul 2025). This separation is foundational to HaLert’s resilience claims, because it keeps management traffic distinct from user and sensor traffic.
2. Architectural organization, protocols, and service model
HaLert is organized into an IoT network, an SDN network, and the urban smart environment that hosts the devices (Ortigoso et al., 10 Jul 2025). In the IoT network, Wi‑Fi HaLow nodes operate as Mesh Points in an IEEE 802.11s mesh, and a HaLow gateway acts as the Mesh Point Portal bridging the mesh to the IoT servers (Ortigoso et al., 10 Jul 2025). The IoT side includes an IoT server, an MQTT broker implemented with Mosquitto on the HaLow gateway, a citizens chat server, an authorities chat server, and a HaLert Manager responsible for managing chat services and validating alerts before broadcasting them to citizens (Ortigoso et al., 10 Jul 2025).
The SDN network is built around a LoRa controlled-flooding mesh, an SDN server or controller, a LoRa gateway, and a React.js web application that lets an operator register devices, inspect status, and send configuration actions (Ortigoso et al., 10 Jul 2025). Supported actions include sensor control, Wi‑Fi control, switching between sensor and AP roles, device reboot, sensor status check, AP status check, AP connection count, connectivity check, and device CRUD operations with map-based visualization (Ortigoso et al., 10 Jul 2025). The control channel is deliberately low-bitrate and robust, matching LoRa’s role as a management plane rather than a user-data plane.
At the device level, the prototype combines Raspberry Pi 3B nodes, NRC7292-based HaLow modules such as AHMB7292S and AHPI7292S, E220‑900T22D LoRa modules, DHT11 sensors, RGB LEDs for traffic-light emulation, and MikroTik mAP lite routers acting as local 2.4 GHz access points with captive portal support (Ortigoso et al., 10 Jul 2025). Citizens and authorities connect to those local APs with ordinary smartphones or laptops; the smart node then forwards traffic into the HaLow mesh (Ortigoso et al., 10 Jul 2025).
HaLert’s control protocol is compact. LoRa SDN messages are encoded with Google Protocol Buffers as four uint32 fields: source device ID, destination device ID, message ID, and action ID (Ortigoso et al., 10 Jul 2025). For some numeric responses, the system encodes the action type and value into a single integer according to
so that a value such as the number of connected clients can be returned without adding new fields (Ortigoso et al., 10 Jul 2025). On the service side, chat applications are implemented as React.js progressive web apps with Node.js and WebSockets, and support text, location, images, audio, and video, although citizen-to-authority traffic is more constrained than authority communications in order to limit overload (Ortigoso et al., 10 Jul 2025).
3. Prototype deployment and measured performance
The published prototype was tested in a real urban scenario at Campus 2 of the Polytechnic University of Leiria, comprising both indoor and outdoor environments and including obstacles, lack of line-of-sight, and terrain slope differences (Ortigoso et al., 10 Jul 2025). The deployment placed the LoRa gateway inside a first-floor room, the HaLow gateway behind an open window in the same room, a smart temperature and humidity sensor on the ground floor of another building near a closed window, and a smart traffic light on a second-floor balcony ledge (Ortigoso et al., 10 Jul 2025). The scenario was small, but it was intentionally propagation-challenging.
The Wi‑Fi HaLow results showed stable connectivity with no packet loss in the reported ping tests, but clear sensitivity to propagation conditions. The smart temperature and humidity sensor, which had the more obstructed path, showed RSSI of dBm and SNR of $2$ dB, whereas the smart traffic light showed RSSI of dBm and SNR of $15$ dB (Ortigoso et al., 10 Jul 2025). Round-trip latency ranged from an average of about $15$ ms for the better-positioned traffic-light node to $54.8$ ms for the more obstructed sensor node, with minimum values of $7.8$ ms in both cases and maximum values reaching $49.8$ ms and $269$ ms respectively (Ortigoso et al., 10 Jul 2025).
Throughput varied accordingly. The reported upload bitrate ranged between 0 and 1 Kbps, and the reported download bitrate ranged between 2 and 3 Kbps, depending on node position and channel conditions (Ortigoso et al., 10 Jul 2025). The smart traffic light reached 4 Kbps upload and 5 Kbps download, while the smart temperature and humidity sensor reached 6 Kbps upload and 7 Kbps download (Ortigoso et al., 10 Jul 2025). The authors therefore conclude that obstacles, lack of line-of-sight, and terrain slopes have a significant impact on HaLow performance, but that the network nevertheless remained stable and resilient and successfully provided all functionalities associated with the architecture (Ortigoso et al., 10 Jul 2025).
The LoRa control network was evaluated over one hour of repeated SDN requests. Message success rates ranged from 8 to 9 across devices, with a reported high average message success rate of $2$0 and an average error rate of $2$1 (Ortigoso et al., 10 Jul 2025). Smart edge devices exhibited about three times more error messages than the gateways, which the paper attributes to their more difficult physical positions (Ortigoso et al., 10 Jul 2025). Even so, the control plane remained sufficiently reliable for status collection and reconfiguration tasks.
4. Resilience model, operating constraints, and future directions
HaLert’s resilience model rests on a layered combination of physical, network, and management properties. Wi‑Fi HaLow contributes sub‑GHz propagation, longer range, and IP-native integration. The paper notes a range on the order of $2$2 km, flexible channel widths from $2$3 to $2$4 MHz, data rates from $2$5 kbps to $2$6 Mbps, and support for up to $2$7 stations per AP (Ortigoso et al., 10 Jul 2025). LoRa contributes robustness, low power operation, and the ability to keep an SDN control channel alive even when the HaLow data plane is degraded (Ortigoso et al., 10 Jul 2025). Controlled flooding with message identifiers and duplicate suppression supplies redundancy without a full routing-table protocol (Ortigoso et al., 10 Jul 2025).
The architecture’s strongest comparative feature is the deliberate division between a HaLow data plane and a LoRa control plane. That division means a network operator can still turn APs or sensors on or off, switch device roles, reboot devices, and query status via LoRa even if the HaLow portion has deteriorated or been misconfigured (Ortigoso et al., 10 Jul 2025). In contrast, the paper argues that systems relying only on LoRa cannot support multimedia or rich multi-user chats, while systems relying on conventional Internet-connected platforms remain exposed to single points of failure in public telecom infrastructure (Ortigoso et al., 10 Jul 2025).
The prototype also exposes clear limits. The experimental topology was small and effectively star-like rather than a large multi-hop mesh, Wi‑Fi HaLow performance was highly sensitive to obstacles and line-of-sight conditions, and the availability and stability of NRC7292-based hardware remained a practical constraint (Ortigoso et al., 10 Jul 2025). Future work proposed in the paper includes simulation of realistic disaster scenarios, analysis of how increasing mesh depth affects service quality, estimation of the required HaLow AP density per user population, implementation of high-availability clustering and load balancing for servers, large-scale experiments with more devices and alternative HaLow hardware, and development of a digital twin for monitoring and predictive analytics (Ortigoso et al., 10 Jul 2025).
5. “HaLert”-style systems in LLM hallucination detection
A separate strand of literature uses “HaLert” or “HaLert-style system” not for disaster networking but for practical hallucination monitors around LLMs. In this usage, the term denotes a lightweight alert layer that estimates hallucination risk during or after generation, often without requiring access to full model internals (Shapiro et al., 2 Feb 2026, Itkin, 10 Jun 2026, Liu et al., 21 Jul 2025). This later usage is not a single standardized architecture; it is a family resemblance across monitoring systems.
One prominent example is HALT, a response-level binary classifier that treats the top-20 token log-probabilities of an LLM generation as a time series and feeds them, together with entropy-based features, into a GRU-based detector of roughly $2$8M parameters (Shapiro et al., 2 Feb 2026). HALT operates in a regime with no hidden states, no attention maps, no extra API calls, and no external knowledge, and on HUB it is reported as $2$9 smaller than Lettuce and about 0 faster while achieving a higher overall macro-F1 on the benchmark (Shapiro et al., 2 Feb 2026). In a more explicitly online framing, “Quickest Detection of Hallucination Onset” formulates token-level hallucination onset as a quickest change detection problem, defines average run length to false alarm and expected detection delay as the operative metrics, derives a Lorden-style lower bound of about 1 tokens at false-alarm rate 2, and reports 3 tokens of delay for a learned GRU-based CUSUM statistic at 4 on RAGTruth (Itkin, 10 Jun 2026).
Other “HaLert”-style proposals occupy different points in the design space. HalMit is described as a black-box watchdog framework for LLM-empowered agents that models a domain-specific generalization bound using probabilistic fractal sampling, stores “boundary points” in a vector database, and flags new queries by similarity and semantic-entropy rules (Liu et al., 21 Jul 2025). HALT-RAG is a post-hoc verifier for RAG pipelines that combines a universal feature set from an ensemble of two frozen NLI models with lexical signals, trains a calibrated task-adapted meta-classifier under a 5-fold out-of-fold protocol, and reports OOF F1 scores of 5, 6, and 7 on HaluEval summarization, QA, and dialogue respectively, with an abstention mechanism enabled by calibration (Goswami et al., 9 Sep 2025). A plausible implication is that, in the LLM literature, “HaLert” functions less as a proper name than as an operational shorthand for a lightweight, always-on hallucination alert layer.
6. Broader methodological neighborhood and scope of the term
The later “HaLert”-style literature has diversified across multiple signal families. Attention-based work has proposed frequency-aware analysis of attention distributions, showing that hallucinated tokens are associated with high-frequency attention energy and that a lightweight detector built on these features improves over prior attention-based methods on RAGTruth and HalluRAG (Qi et al., 20 Feb 2026). HaluNet integrates hidden-state embeddings, token log-likelihoods, and predictive entropy in a multi-branch one-pass detector for QA and reports strong AUROC and efficiency with or without context (Tong et al., 31 Dec 2025). HARP uses singular value decomposition of the unembedding layer to define a reasoning subspace, projects hidden states into that subspace, and reports an AUROC of 8 on TriviaQA (Hu et al., 15 Sep 2025). HSAD models hidden-layer temporal signals with FFT and reports over 10 percentage points improvement compared to prior state of the art across several QA benchmarks (Li et al., 16 Sep 2025). MultiHaluDet probes full hidden-state trajectories across layers with a stacking framework and reports up to 9 AUROC on English HaluEval and TriviaQA, together with cross-lingual transfer to French, Bangla, and Amharic (Alvi et al., 24 May 2026). A separate interpretable line combines Predictive Coding and the Information Bottleneck, defining signals such as Entity-Focused Uptake, Context Adherence, and Falsifiability Score, and reports $15$0 AUROC on HaluBench with a model of less than $15$1M parameters (Bhatt, 22 Jan 2026).
This broader neighborhood clarifies the contemporary scope of the term. In smart-city networking, HaLert names a specific dual-mesh emergency architecture (Ortigoso et al., 10 Jul 2025). In LLM safety, the same label has become a reference point for systems that sit between a model and its deployment environment, consuming signals such as log-probabilities, hidden states, attention patterns, NLI scores, or calibrated classifier outputs to estimate whether a response should be trusted (Shapiro et al., 2 Feb 2026, Itkin, 10 Jun 2026, Liu et al., 21 Jul 2025). This suggests that “HaLert” now occupies two distinct but structurally related places in the literature: as a concrete resilient communication system for disaster response, and as an architectural metaphor for lightweight alerting layers that improve reliability in high-risk AI deployments.