[Paper] HERMES: Heterogeneous Application-Enabled Routing Middleware for Edge-IoT Systems

Published: (December 1, 2025 at 11:04 AM EST)
4 min read
Source: arXiv

Source: arXiv - 2512.01824v1

Overview

The paper introduces HERMES, a middleware that lets edge‑IoT applications steer routing decisions based on their own performance needs. By exposing application‑level metrics (e.g., latency, compute capability) to the routing layer, HERMES bridges the gap between heterogeneous devices (ESP8266, ESP32, Raspberry Pi) and the static assumptions of classic routing protocols.

Key Contributions

  • Application‑aware routing middleware that can be plugged into any multi‑hop Wi‑Fi IoT network.
  • Three routing‑influence strategies: two that adapt the path a message follows, and one that lets an app reshape the network topology itself.
  • Proactive, fault‑tolerant routing that continues operating despite node or packet loss.
  • Real‑world validation on a heterogeneous testbed using edge‑intelligence workloads (distributed neural‑network inference and full off‑loading).
  • Empirical analysis showing how device heterogeneity, topology, and the chosen strategy affect throughput and inference latency.

Methodology

  1. Hardware platform – A physical testbed composed of ESP8266, ESP32, and Raspberry Pi 3B nodes forming a multi‑hop Wi‑Fi mesh.
  2. Routing layer – A proactive protocol that constantly maintains route tables, refreshed by periodic hello messages. Fault tolerance is achieved by automatically recomputing routes when a node disappears or a packet is dropped.
  3. Middleware layer – Exposes a simple API (setPolicy(), publish(), subscribe()) that applications use to:
    • Strategy A – Prefer low‑latency hops (e.g., choose the fastest link).
    • Strategy B – Favor energy‑efficient hops (e.g., route through low‑power ESP8266 nodes).
    • Strategy C – Dynamically rewire the mesh (add/remove virtual links) based on current compute load.
  4. Use‑case implementation – Two edge‑AI scenarios were built:
    • Distributed inference – Split a tiny CNN across several nodes, each performing part of the forward pass.
    • Full off‑load – Send the whole inference request to the most capable node (the Pi).
  5. Measurements – Collected throughput, end‑to‑end latency, and inference time under varying network topologies and loss conditions.

Results & Findings

ScenarioStrategyThroughput (kbps)Avg. Inference Time (ms)
Distributed inferenceLow‑latency (A)42078
Distributed inferenceEnergy‑aware (B)31095
Full off‑loadTopology‑shaping (C)48062
  • Heterogeneity matters – Adding a Pi to the mesh boosted overall throughput by ~30 % and cut inference latency by up to 25 % compared with an ESP‑only network.
  • Strategy impact – The low‑latency strategy consistently reduced end‑to‑end delay, while the energy‑aware strategy saved ~15 % power on ESP8266 nodes at the cost of higher latency.
  • Fault tolerance – When a node was deliberately powered off, routes were recomputed within 150 ms, and the system kept delivering inference results without noticeable service interruption.
  • Topology shaping – Allowing the application to create “shortcut” links (e.g., direct ESP32‑Pi connections) yielded the best performance for compute‑heavy off‑loading.

Practical Implications

  • Edge AI pipelines – Developers can now let their inference code decide whether to run locally, split across devices, or off‑load to a more powerful node, without rewriting networking code.
  • Energy‑constrained deployments – Battery‑powered sensors can request energy‑saving routes, extending device lifetime while still participating in collaborative processing.
  • Dynamic reconfiguration – In environments where nodes join/leave (e.g., smart factories, agricultural fields), HERMES automatically adapts, reducing the need for manual network planning.
  • Vendor‑agnostic integration – Because the middleware sits above standard Wi‑Fi stacks, it can be adopted on existing ESP/Arduino/Raspberry platforms with minimal firmware changes.
  • Scalable edge services – Service orchestration tools (Kubernetes‑edge, OpenYurt) could expose HERMES policies as custom resources, enabling automated QoS‑aware routing at scale.

Limitations & Future Work

  • Scalability testing – Experiments were limited to < 15 nodes; larger meshes may expose routing table overhead or increased convergence time.
  • Security considerations – The current API trusts applications to set policies; future versions need authentication and policy sandboxing to prevent malicious routing manipulation.
  • Protocol diversity – HERMES is built on Wi‑Fi; extending the middleware to BLE, LoRaWAN, or 5G‑NR‑based edge links is left for later work.
  • Adaptive learning – Incorporating reinforcement‑learning agents that automatically select the optimal strategy based on real‑time metrics could further improve performance.

Bottom line: HERMES demonstrates that giving edge‑IoT applications a say in routing decisions unlocks measurable gains in latency, throughput, and energy efficiency—an insight that developers can start leveraging today in any heterogeneous mesh deployment.

Authors

  • Jéssica Consciência
  • António Grilo

Paper Information

  • arXiv ID: 2512.01824v1
  • Categories: cs.NI, cs.NE
  • Published: December 1, 2025
  • PDF: Download PDF
Back to Blog

Related posts

Read more »