HERMES: Metric-Driven Multi-Transport Routing for Civilian Messaging During Connectivity Disruption

Abstract

Civilian communication systems often fail during armed conflicts, political unrest, and large-scale Internet disruptions—precisely when reliable communication is most needed. This paper presents HERMES, a resilient hybrid communication architecture that integrates HTTP/IP networking, Bluetooth Low Energy (BLE) mesh communication, and Delay-Tolerant Networking (DTN) within a unified adaptive routing framework. Unlike conventional approaches that treat alternative transports as backup solutions, HERMES dynamically selects the most efficient transport path based on current network conditions using a transport-aware forwarding policy whose cost function combines round-trip time, transport preference, and observed link risk. The architecture is built on distributed microservices that support topology discovery, shortest-path routing, and fault-tolerant message delivery. Reliability is enhanced through acknowledgments, bounded retransmissions, duplicate suppression, and graceful degradation mechanisms, while end-to-end authenticated encryption (Noise XX with a Double Ratchet) ensures secure communication across transport changes. A prototype implementation developed in C# on .NET 9 was evaluated on a five-node testbed, and a custom Network Simulator 3 (NS-3) module was used to extend the evaluation to networks of up to 500 nodes, under multiple failure scenarios, including node crashes, network partitioning, and complete Internet outages. Experimental results show that HERMES maintains perfect or near-perfect delivery in static topologies, including during a complete Internet blackout that disables IP-only messaging. Compared with the published Delay-Tolerant Networking protocols Epidemic and PRoPHET at one hundred nodes, HERMES exceeds their delivery ratio in static and failure scenarios and remains within 0.06 of them under pedestrian mobility during blackout, while transmitting roughly 35× fewer bytes– and about 21× fewer even relative to the more bandwidth-efficient MaxProp baseline. Under coordinated drop attacks by adversarial relays, HERMES degrades gracefully where flooding-based baselines collapse. This approach demonstrates that resilient civilian communication can be effectively achieved through metric-driven adaptive multi-transport routing, making it suitable for disaster recovery, contested environments, and connectivity-limited regions.

1. Introduction

Communication networks are often among the first systems to fail during armed conflicts and periods of political instability. Over the past decade, governments have increasingly used large-scale internet disruptions as mechanisms of control, while military campaigns have caused extensive damage to telecommunications infrastructure. The nationwide shutdown imposed in Iran in January 2026 has been identified in recent measurement studies as one of the most comprehensive and technically coordinated blackouts recorded in the country, simultaneously disrupting international connectivity, the National Information Network, privileged Subscriber Identity Module (SIM) services, and fixed-line communications [1,2]. In Gaza, civilians have experienced recurrent communication outages lasting weeks, compounded by the destruction of cellular towers and the cutting of fiber-optic links [3]. Similar disruptions have been reported in Sudan, Myanmar, Ethiopia, and several regions of Central Asia [4]. Such incidents are no longer isolated; they increasingly represent the communication environment faced by populations living under conflict and political instability.

Contemporary messaging platforms are largely built on assumptions that often do not hold in such situations—specifically, that Internet connectivity is always available, centralized servers are accessible, and a complete end-to-end path exists when a message is sent. When these assumptions break down, communication systems frequently fail entirely. Satellite-based connectivity can offer limited alternatives, but these systems are expensive, highly visible, susceptible to jamming, and inaccessible to much of the civilian population. Virtual private networks (VPNs) may bypass certain types of censorship [5], but they provide little benefit when the underlying physical or routing infrastructure is disrupted. Addressing these challenges requires communication architectures that do not rely on a single transport mechanism, can opportunistically use any available connectivity at a given time, and support delay-tolerant message delivery when no direct real-time communication path exists.

The challenges of disrupted and intermittently connected networks have long been recognized by the networking research community. Delay-Tolerant Networking (DTN), first introduced by Vinton Cerf and colleagues [6] and later formalized by the Internet Engineering Task Force (IETF) through Bundle Protocol Version 7 [7], established a communication model for environments where stable end-to-end connectivity cannot be guaranteed. Building on this foundation, research on opportunistic and intermittently connected networks has produced a wide range of routing strategies, including epidemic forwarding, the probabilistic PRoPHET protocol, controlled-replication approaches such as Spray-and-Wait, and vehicular DTN schemes such as MaxProp, as discussed in surveys by Zhang [8] and Pelusi et al. [9].

Parallel research in emergency communication systems [10,11] has explored integrating mobile ad hoc networks, wireless mesh infrastructures, satellite communication links, and unmanned aerial platforms to support connectivity in disaster and conflict scenarios. More recently, deployed systems such as Bitchat [12] have demonstrated that decentralized peer-to-peer messaging over Bluetooth Low Energy mesh networks can operate effectively at large scale, particularly during the protest movements and communication disruptions observed in several countries between 2025 and 2026.

Despite these advances, a significant limitation persists in the existing literature. Most proposed systems address only a subset of the broader communication challenges encountered during large-scale connectivity disruptions. For example, DTN architectures have primarily been developed for deep-space communication, military operations, or sensor-network environments, with limited adoption in civilian contexts. Bluetooth-based mesh applications such as Bitchat function effectively only over short physical distances and generally require dense and sustained proximity between users. In contrast, conventional Internet messaging platforms still depend on uninterrupted IP connectivity and accessible centralized infrastructure. Hybrid emergency-response frameworks that combine satellite, aerial, and terrestrial communication systems [10] largely focus on operator-managed infrastructure recovery rather than direct civilian messaging.

As a result, no single transport technology adequately addresses the full range of communication requirements that arise during conflict-related or politically induced outages. This paper argues that resilient civilian communication should be treated not only as a transport-layer issue but as a dynamic multi-transport routing problem. In disrupted environments, communication systems must operate across multiple heterogeneous delivery mechanisms, each with distinct trade-offs in latency, transmission range, energy consumption, and availability. Rather than relying on a single networking substrate, the system must continuously determine which transport is most suitable under current connectivity conditions. To address this, we present HERMES, a hybrid multi-transport messaging architecture that integrates three complementary communication layers within a unified routing framework. The first layer uses HTTP over IP to support high-throughput communication when conventional Internet connectivity is available. The second layer uses BLE mesh networking to enable short-range peer-to-peer relaying between physically proximate devices. The third layer employs a store-and-forward bundle mechanism based on DTN principles, allowing asynchronous message delivery when no contemporaneous end-to-end path exists. At each node, a routing component evaluates candidate forwarding opportunities across all available transports and selects the next hop that minimizes an estimated delivery cost function under prevailing network conditions, combining round-trip time, transport preference, and observed link risk. This design enables the system to adapt dynamically to changing connectivity regimes while maintaining communication continuity across heterogeneous and intermittently available infrastructures.

HERMES uses a microservice-based architecture with four independently deployable services and five network nodes operating in the prototype testbed. In the prototype implementation, components communicate through HTTP/REST interfaces using JSON messages. Each node periodically measures the round-trip time to its neighboring nodes and shares these measurements via a gossip mechanism with a topology aggregation service. Routing paths are determined by Dijkstra’s shortest-path algorithm based on the collected latency data. To enhance reliability, the system provides per-hop acknowledgments with limited retransmission attempts, node-level deduplication using Redis-based key management, and an application-level time-to-live parameter to prevent persistent routing loops. A circuit-breaker mechanism enables services to degrade gracefully when downstream components become unavailable [13,14]. In accordance with the CAP (Consistency, Availability, Partition-Tolerance) theorem [15,16], HERMES adopts an availability and partition-tolerance (AP) design strategy. Consequently, when the central coordinator is unreachable, nodes continue forwarding packets using locally cached topology information, prioritizing approximate routing over complete service interruption. In addition to the prototype, we implemented HERMES as a custom NS-3 module that reproduces the routing logic, cost function, and failure model of the prototype, enabling controlled evaluation at scales of up to 500 nodes.

Message confidentiality is ensured through end-to-end authenticated encryption. The system employs well-established cryptographic mechanisms, including the Noise Protocol Framework handshake [17] for secure session initialization, ChaCha20-Poly1305 [18] for authenticated message encryption, and the Double Ratchet algorithm [19,20] to provide both forward secrecy and post-compromise security. These mechanisms are integrated into a transport-independent session model in which the ratchet state remains synchronized across HTTP, BLE, and bundle-based communication channels. The cryptographic primitives themselves are not presented as a novel contribution. Their integration with the multi-transport routing architecture is one contribution of this work, along with the routing and evaluation contributions listed below. This design allows encrypted messages to remain protected even when communication dynamically transitions between different transport layers, while maintaining forward secrecy across heterogeneous relay nodes.

The main contributions of this work are as follows. First, we propose a multi-transport routing architecture that integrates heterogeneous communication mechanisms into a unified routing framework, rather than treating them as simple backup options. Second, we introduce a metric-driven, transport-aware handoff strategy that dynamically selects between HTTP, BLE mesh, and bundle-based communication on a per-hop basis using a cost function that combines round-trip time, transport preference, and observed link risk. Third, we implement the proposed architecture as a microservice-based system using C# and .NET 9, incorporating features such as topology discovery, message deduplication, circuit breaking, and a real-time observability dashboard. Fourth, we integrate end-to-end authenticated encryption within a transport-independent session model, ensuring forward secrecy even when communication switches between different transport layers. Fifth, we develop a custom NS-3 module that mirrors the prototype’s routing logic and use it to evaluate HERMES at scales of up to 500 nodes under controlled failure scenarios (relay-node failure, central-coordinator partitioning, and complete Internet outage), random-waypoint mobility, and coordinated adversarial-relay drop attacks. Sixth, we compare HERMES with four published Delay-Tolerant Networking routing protocols Epidemic [21], PRoPHET [22], Spray-and-Wait [23], and MaxProp [24] on identical NS-3 topologies; the comparison shows that HERMES matches or exceeds their delivery ratio while transmitting 21–35× fewer bytes, and that HERMES degrades far more gracefully than flooding-based baselines under adversarial conditions. Together, these contributions situate HERMES within the broader contexts of delay-tolerant networking and emergency communication systems.

To clearly delineate the novelty of this work, existing hybrid and emergency communication systems either treat non-IP transports as sequential fallbacks chosen at the source or restrict routing to a single communication technology, such as BLE mesh flooding or DTN contact graphs. To the best of our knowledge, HERMES is the first civilian messaging architecture to model HTTP, BLE mesh, and DTN bundle links as parallel, first-class edges within a unified routing graph, selecting routes with a common cost function while preserving end-to-end encryption across transport transitions. The advantages over the closest baselines are demonstrated quantitatively rather than asserted qualitatively: for a network of $N=100$ nodes, HERMES achieves delivery ratios comparable to or better than flooding-based DTN protocols while transmitting 21–35× fewer bytes, reducing the estimated radio energy per delivered message by 52× in steady state and 41× under blackout, and dynamically adapting its transport usage from 75% HTTP in steady state to 70% BLE and 5% DTN bundle as network connectivity deteriorates.

The remainder of this paper is organized as follows. Section 2 reviews the literature on delay-tolerant and opportunistic networking, emergency communication frameworks, civilian mesh messaging platforms, microservice resilience techniques, and secure end-to-end messaging protocols. Section 3 introduces the HERMES system model and provides an overview of the proposed architecture. Section 4 explains the multi-transport routing mechanism and the transport-aware handoff strategy. Section 5 describes the reliability, consistency, and end-to-end security components of the system. Section 6 presents the experimental setup and evaluation results, including the prototype testbed and the NS-3 scale-out evaluation. Section 7 discusses the limitations of the current approach and outlines potential directions for future research. Section 8 concludes the paper and explains our perspectives.

2. Related Work

HERMES is based on five major research areas: delay-tolerant and opportunistic networking, emergency communication systems, peer-to-peer civilian messaging platforms, microservice resilience engineering, and end-to-end secure messaging. A sixth area, related to adversarial routing and Byzantine fault tolerance, is discussed briefly in the evaluation section, where we present new results in that direction. This section reviews the main developments in each area, highlights the limitations that motivate the proposed approach, and closes with a review of evaluation methodology and network-simulation practice that underpins our NS-3 study.

2.1. Delay-Tolerant and Opportunistic Networking

The Delay-Tolerant Networking (DTN) architecture introduced by Cerf et al. [6] defines an overlay store-and-forward paradigm for environments with intermittent connectivity and potentially very long propagation delays. The Bundle Protocol Version 7 [7] is the current IETF standard supporting this architecture. Extensive research has addressed routing in scenarios where no stable end-to-end path exists at any given time.

Early foundational work includes Epidemic routing by Vahdat and Becker [21], which established the baseline flooding-based approach. PRoPHET [22] improved forwarding decisions by using probabilistic metrics derived from historical encounter patterns. To reduce the overhead of flooding, the Spray-and-Wait family of protocols [23] introduced controlled message replication with a limited number of copies. In another direction, MaxProp [24] used prioritized scheduling and path likelihood estimation, particularly in vehicular DTN environments, to enhance delivery performance. Comprehensive overviews of these routing strategies are provided in surveys by Zhang [8] and Pelusi et al. [9], while more recent developments in opportunistic routing metrics and evaluation frameworks are discussed by Abdollahi et al. [25].

To strengthen the comparison, we include MaxProp [24] as a fourth NS-3 baseline. Owing to its delivered-ACK deletion mechanism, MaxProp is among the most bandwidth-efficient protocols in the flooding-based DTN family; however, at comparable delivery ratios it still transmits approximately 21× more bytes than HERMES. We do not include recent utility-based or learning-based routing protocols as direct baselines because a fair comparison would require complete, reproducible implementations with published parameter settings and identical contact traces. An approximate reimplementation could introduce uncontrolled bias. Accordingly, our evaluation focuses on representative flooding-family protocols (Epidemic, PRoPHET, Spray-and-Wait, and MaxProp), while identifying modern learning-based routing as an important direction for future comparative evaluation.

HERMES adopts the Delay-Tolerant Networking (DTN) store-and-forward bundle semantics as one of three transport mechanisms; however, it diverges from the conventional DTN paradigm in two key respects. First, classical DTN architectures generally assume a homogeneous environment in which all communication is handled through bundle-based forwarding. In contrast, HERMES treats bundles as one transport option within a heterogeneous set of mechanisms and performs dynamic routing across them depending on context and availability. Second, the DTN research literature has predominantly been shaped by use cases in deep-space communication, military networks, and resource-constrained sensor deployments. As a result, many established routing metrics—such as energy-aware cost functions or contact-schedule optimization—do not directly transfer to civilian-scale environments, where performance objectives are more strongly driven by latency minimization and control over metadata exposure.

Of the DTN protocols cited above, Epidemic [21], PRoPHET [22], and Spray-and-Wait [23] are the most relevant comparators for HERMES because they represent the three main DTN routing families: unbounded flooding (Epidemic), history-based probabilistic forwarding (PRoPHET), and bounded controlled replication (Spray-and-Wait). All three are implemented in our NS-3 evaluation, together with MaxProp as a fourth baseline in the byte-level comparison.

2.2. Emergency Communication Networks

Surveys of emergency communication network architectures by Ali et al. [10] and Wang et al. [11] describe a multi-layered design space that integrates satellite systems, unmanned aerial platforms, terrestrial cellular fallback mechanisms, mobile ad hoc networks, and wireless mesh deployments. Additional surveys focusing on big data analytics and network management in emergency contexts [26] expand this view by addressing operational coordination and data-driven decision-making layers.

Overall, this body of work primarily presents emergency communication as a challenge of infrastructure provisioning and deployment for network operators and first responders. In this framework, the main goal is to restore or rapidly deploy temporary communication infrastructure in affected areas. This perspective is complementary to, but distinct from, the approach taken by HERMES. HERMES instead treats civilian end-to-end messaging as an application-layer routing problem that operates over heterogeneous transports already available on user devices, without assuming restored infrastructure. The two approaches target different stakeholders and operate over different timeframes; HERMES focuses on the immediate post-disaster phase and peripheral areas where operator-led infrastructure recovery has not yet taken place.

2.3. Deployed Civilian Mesh Messaging Systems

Over the past five years, peer-to-peer civilian messaging platforms have become increasingly important during periods of network disruption and Internet shutdowns. Bridgefy saw widespread use during the 2019–2020 Hong Kong protests through its Bluetooth-based mesh communication model; however, subsequent security analyses [27] revealed protocol vulnerabilities that raised serious concerns about user safety. Briar similarly combines Tor, Bluetooth, and Wi-Fi Direct to support communication among journalists and activists operating in constrained environments. More recently, Bitchat saw significant adoption during the 2025 and 2026 Internet shutdowns in countries including Iran, Uganda, Madagascar, Nepal, and Indonesia. The system relies on Bluetooth Low Energy (BLE) mesh networking combined with Noise Protocol Framework encryption and uses an eight-bit time-to-live parameter limited to seven hops—a bound that reflects Bitchat’s deployment in physically dense crowds where mesh diameter is small. HERMES, designed for sparser civilian topologies where multi-hop paths may extend further, uses a larger time-to-live (TTL) bound (TTL = 16) whose justification is presented and validated empirically. It also integrates a complementary Nostr-based fallback mechanism for users with Internet connectivity. Among currently deployed systems, Bitchat is the closest to HERMES in terms of motivation and operational goals, making it the most relevant comparison.

However, HERMES differs from these platforms in several important respects. First, while Bitchat relies primarily on gossip-based flooding within a single BLE mesh layer, HERMES uses metric-driven shortest-path routing across multiple heterogeneous transports. Second, instead of treating Internet-based services such as Nostr as fallback mechanisms, HERMES considers all available transports as potential next hops during each routing decision. Third, unlike earlier systems such as Bridgefy, whose deployment exposed weaknesses due to insufficiently analyzed protocol design [27], HERMES exclusively adopts cryptographic primitives supported by published formal analyses [20,28].

2.4. Microservice Resilience Patterns

The microservice architectural paradigm has evolved alongside a well-established set of resilience patterns, including retry with exponential backoff, bulkhead isolation, timeout control, and the circuit-breaker pattern originally introduced by Nygard [13] and later formalized in modern service-mesh frameworks [29]. Subsequent research expanded this foundation in several directions. Mendonça et al. [30] conducted a model-based analysis of resiliency mechanisms in microservice systems, while Aderaldo et al. [29] proposed a declarative benchmarking framework for systematically evaluating resilience strategies under controlled conditions. Sedghpour et al. [31] later introduced self-adaptive retry and circuit-breaking mechanisms capable of dynamically adjusting to changing system conditions. More recently, a systematic review of recovery-oriented design patterns [14] identified nine recurring resilience themes, including adaptive backpressure management and chaos engineering-based validation techniques.

HERMES incorporates established resilience mechanisms at the microservice level. Each node maintains an independent circuit breaker for downstream services, retry attempts are explicitly limited, and service-specific graceful degradation policies are defined to preserve operational continuity under partial failure conditions. However, HERMES does not introduce new resilience patterns. Its contribution is the application of established microservice resilience principles within a heterogeneous multi-transport routing environment.

2.5. End-to-End Messaging Security

The cryptographic foundations in HERMES rely exclusively on well-established primitives that have undergone extensive formal evaluation. The Noise Protocol Framework has been formally analyzed by Dowling et al. [28] within the Flexible Authenticated and Confidential Channel Establishment (fACCE) security model and further examined through automated symbolic verification by Girol et al. [32]. Similarly, the Double Ratchet algorithm, which underpins Signal-style secure messaging, was first studied in a foundational symbolic analysis by Cohn-Gordon et al. [33]. Subsequent work by Alwen et al. [34] introduced a modular game-based formalization, while Bienstock et al. [20] expanded the threat model to include additional adversarial capabilities. More recently, Cheval et al. [35] identified attacks affecting specific Double Ratchet variants, highlighting the importance of carefully selecting the inherited construction.

In the DTN domain, the Bundle Protocol Security (BPSec) extension [36] provides integrity and confidentiality protection at the block level. However, these mechanisms typically rely on pre-shared symmetric keys and do not offer forward secrecy [37]. Although several studies have examined cross-layer encryption and multi-path secure communication, no published architecture, to our knowledge, integrates a Noise-based handshake, a Signal-inspired ratcheting mechanism, and a DTN-compatible bundle layer within a unified end-to-end ciphertext framework that preserves forward secrecy during transport transitions.

Therefore, HERMES does not contribute by introducing new cryptographic primitives. Instead, its novelty lies in integrating formally analyzed cryptographic constructions into a unified multi-transport communication architecture that preserves end-to-end confidentiality and forward secrecy across heterogeneous routing layers.

2.6. Adversarial Routing and Network-Level Threats

The adversarial-resilience result reported connects HERMES to a long-standing line of research on routing in the presence of malicious or compromised nodes. Marti et al. [38] introduced the Watchdog and Pathrater mechanisms for mobile ad hoc networks, where neighbors observe each other’s forwarding behavior and downgrade those that drop packets—an active reputation approach. Awerbuch et al. [39] later proposed on-demand secure Byzantine routing for ad hoc networks with explicit fault detection. In the wireless sensor network literature, Wood and Stankovic [40] surveyed denial-of-service attacks across protocol layers, including selective-drop attacks.

HERMES’s approach to adversarial relays is deliberately simpler than the work cited above. We do not employ active monitoring, signed acknowledgments, or relay reputation tables. The risk term in the cost function is purely passive: it raises the cost of edges that fail to ACK, and Dijkstra routes around those edges. We show that this passive mechanism alone is sufficient to outperform the canonical DTN baselines under coordinated drop attacks. We view active reputation mechanisms as a natural extension.

In the revised evaluation, the adversary model is extended beyond passive monitoring and silent packet dropping. We additionally consider two active relay attacks: an ACK-and-drop relay, which acknowledges packets before discarding them, and a topology-poisoning relay, which advertises falsely low-latency links to attract and subsequently discard traffic. These attacks represent practical instances of the Byzantine forwarding behavior addressed by Marti et al. [38] and Awerbuch et al. [39] through active monitoring and authenticated routing mechanisms. Sybil identity flooding and timing-correlation attacks are outside the scope of this work and are discussed as future directions. For the attacks considered here, the corresponding mitigation is authenticated, digitally signed link-state dissemination.

2.7. Evaluation Methodology and Network Simulation

The evaluation section integrates a functional C# .NET 9 prototype with a custom NS-3 module for scale-out experiments. NS-3 is the de facto standard discrete-event simulator for networking research [41] and has been widely used for DTN evaluations, including by the authors of PRoPHET and Spray-and-Wait. We follow established practice in the opportunistic networking literature by reporting the mean and standard deviation over multiple independent random seeds, applying Welch’s t-test and the Mann–Whitney U-test for significance, and making the complete simulator code, configuration files, and random seeds available from the corresponding author upon reasonable request. Comparisons with published DTN protocols use their canonical parameter values from the original papers [21,22,23].

2.8. Synthesis and Research Gaps

Table 1 groups the reviewed work by technical category—DTN routing, emergency-infrastructure provisioning, civilian mesh messaging, microservice resilience, secure messaging, and adversarial/Byzantine routing—and indicates, for each, whether it addresses (i) multi-transport adaptation, (ii) cross-layer forward secrecy, (iii) byte-level bandwidth accounting, and (iv) adversarial resilience. No prior system covers all four columns; that gap motivates HERMES. The broader principle of coordinating distributed nodes from eventually-consistent local state, rather than from a central authority, also appears in other domains such as distributed energy-resource control [42]. The security properties of the cryptographic components are established through peer-reviewed analyses; the underlying protocol specifications (Noise, Double Ratchet) and the Bitchat system, for which no peer-reviewed analysis yet exists, are cited as protocol and system definitions rather than as evidence of security.

Table 1. Coverage of the four HERMES design dimensions across the reviewed literature. Columns: (i) dynamic adaptation across multiple transports; (ii) forward secrecy preserved across a transport/layer switch; (iii) bandwidth reported in bytes rather than transmission counts; (iv) network-level adversarial resilience addressed and evaluated. ✓ = stated design goal and evaluated; • = partially or implicitly addressed; – = not addressed.

System/Work	(i)	(ii)	(iii)	(iv)
DTN/opportunistic routing
Epidemic [21]	–	–	–	–
PRoPHET [22]	–	–	–	–
Spray-and-Wait [23]	–	–	•	–
MaxProp [24]	–	–	–	–
Emergency-infrastructure provisioning
Emergency-network surveys [10,11,26]	•	–	–	–
Civilian mesh messaging
Bridgefy [27]	–	–	–	–
Briar	•	•	–	•
Bitchat	–	•	–	–
Microservice resilience
Retry/circuit-breaker patterns [13,29,30,31]	–	–	–	–
Secure-messaging primitives
Noise, Double Ratchet [20,28,32,33,34,35]	–	•	–	–
Adversarial/Byzantine routing
Watchdog, Byzantine routing, DoS survey [38,39,40]	–	–	–	✓
HERMES (our solution)	✓	✓	✓	✓

3. System Model and Architectural Overview

This section introduces the HERMES system model and provides an overview of the proposed architecture. We begin by defining the system’s underlying assumptions, including those related to participating nodes, network conditions, available transports, adversarial capabilities, and failure scenarios. Next, we describe the four-tier microservice architecture that implements the proposed model and explain the responsibilities of each service layer. Finally, we position HERMES relative to the most closely related existing systems through a comparative analysis. The detailed mechanisms and protocols within this architecture are presented in the following sections.

3.1. Node Model

The HERMES network comprises a collection of autonomous nodes, denoted as N = {$n_1$, $n_2$, …, $n_k$}. Each node acts as an independent participant in the messaging system and may represent a user device such as a smartphone, laptop, or single-board computer; a stationary relay deployed by a community or organization; or a mobile infrastructure platform, including vehicles or unmanned aerial systems. All nodes operate under the same protocol model and can generate, forward, store, and deliver messages. The architecture does not rely on dedicated routers or centralized servers within the data plane.

To support these operations, each node $n_i$ maintains four categories of local state. First, it stores a long-term Ed25519 public/private key pair ($s{k}_i$, $p{k}_i$) to provide end-to-end authentication. Second, it keeps a routing cache with the latest topology information available to the node. Third, it maintains a local message repository for buffering and storing bundles awaiting forwarding or delivery. Finally, it preserves session information for neighboring peers with which a Noise-based secure channel has been established. In the current prototype, these data structures reside in volatile memory; future production versions are expected to include persistent storage mechanisms.

Each node may support one or more communication interfaces selected from the set $I_i$ ⊆ {HTTP, BLE, BUNDLE}. Support for a given interface means the node can transmit and receive data through that transport, although the interface may not always be operational. The topology management layer dynamically evaluates transport availability. While every node must implement at least one communication interface, it may optionally support all available transports.

3.2. Network and Transport Model

HERMES is designed to operate in asynchronous networking environments where communication delays are inherently unpredictable. The system does not assume any upper bound on message delivery time, and transmitted messages may experience arbitrary delays, reordering, duplication, or loss before reaching their destination. Rather than relying on the underlying network for reliability, HERMES enforces message integrity and authenticity at the application layer through authenticated encryption mechanisms. This communication model aligns with that adopted by the Bundle Protocol [7] and reflects the realities of heterogeneous and intermittently connected networks spanning multiple administrative and technological domains.

Unlike conventional routing systems that are tightly coupled to a single communication technology, HERMES incorporates transport heterogeneity directly into the routing process. Communication links are characterized not only by their connectivity but also by the transport technology they use. To support deployment across diverse networking environments, HERMES currently defines three transport types.

3.2.1. HTTP/REST over IP ($T\_HTTP$)

When two nodes have IP connectivity, messages can be exchanged through an HTTP/REST interface using JSON-formatted payloads. This transport typically provides low communication latency, ranging from a few milliseconds to several hundred milliseconds, and relatively high throughput that can reach tens of megabits per second or more. Reliable and ordered delivery is ensured by the underlying TCP connection, making HTTP the most efficient transport under normal operating conditions.

Despite these advantages, HTTP-based communication relies heavily on the availability of the underlying Internet infrastructure. Network disruptions, routing failures, traffic filtering mechanisms, or protocol-specific blocking can render this transport unavailable. Therefore, while HTTP is the preferred communication method when connectivity permits, HERMES does not assume its continuous availability and is designed to transition seamlessly to alternative transport mechanisms when necessary. Accordingly, $T\_HTTP$ is selected as the primary transport whenever it is operational.

3.2.2. Bluetooth Low Energy Mesh ($T\_BLE$)

When two nodes are within Bluetooth communication range, they can exchange messages directly using Bluetooth Low Energy (BLE) without external networking infrastructure. The effective communication range depends on the BLE physical layer: legacy 1M-PHY transceivers operate at approximately 30 to 100 m line-of-sight, while Bluetooth 5.0 Coded-PHY (long-range) mode extends this to roughly 150 m in the configuration evaluated here. The prototype testbed uses the 50 m 1M-PHY range, and the NS-3 evaluation uses the 150 m Coded-PHY range. Effective range is also influenced by environmental conditions, device characteristics, and radio interference. Compared with IP-based communication, BLE offers lower throughput and more limited coverage, making it best suited for short-range peer-to-peer interactions.

Connectivity through $T\_BLE$ exists only while participating devices remain within communication range. However, message propagation can extend beyond direct contact through multi-hop forwarding, in which intermediate nodes relay messages between disconnected peers. The practical reach of such forwarding depends on the density, mobility, and distribution of participating devices. Recent large-scale deployments of Bluetooth-based mesh communication systems have demonstrated the viability of this approach for maintaining communication in environments where conventional Internet connectivity is unavailable or disrupted. Therefore, HERMES uses $T\_BLE$ as its preferred transport whenever IP-based communication is inaccessible and nodes remain in physical proximity.

3.2.3. Store-and-Forward Bundle Transport ($T\_BUNDLE$)

When no end-to-end communication path is available at the time of transmission, HERMES uses a store-carry-forward mechanism based on the principles of the Bundle Protocol Version 7 (BPv7) architecture [7]. Messages are encapsulated as bundles and temporarily stored by intermediate nodes until a suitable forwarding opportunity occurs. This approach enables communication across intermittently connected networks where continuous connectivity cannot be guaranteed. To avoid overstating interoperability, we describe the bundle layer as DTN-inspired rather than fully BPv7-compliant. The implementation adopts the core store-carry-forward and custody transfer concepts of BPv7 but does not implement the complete RFC 9171 bundle specification, including the primary and canonical block formats, CBOR encoding, or administrative records. A roadmap for achieving full compliance, including CBOR bundle encoding, BPv7 block formatting, and BPSec block-level security, is outlined in the future work section.

The $T\_BUNDLE$ transport is specifically designed for disruption-tolerant operation and accommodates highly variable delivery delays, ranging from seconds to several hours depending on network conditions and node mobility. Communication over this transport relies on intermediate nodes maintaining custody of bundles and storing them persistently until successful forwarding or delivery is possible. As a result, $T\_BUNDLE$ provides resilience in environments where conventional communication paths are unavailable, though this comes at the cost of increased delivery latency.

Within HERMES, T_BUNDLE acts as the fallback transport and is used only when neither $T\_HTTP$ nor $T\_BLE$ can provide a viable forwarding path that meets the message delivery requirements. This design ensures that communication continues even under severe connectivity constraints. The three transport mechanisms have distinct operational characteristics that influence routing decisions. Specifically, they differ in latency, bandwidth, communication range, persistence requirements, and network observability. These attributes are summarized in Table 2. To leverage the strengths of each transport while adapting to changing network conditions, HERMES employs a transport-aware forwarding strategy that evaluates candidate links with a cost function based on these characteristics and selects the most appropriate transport on a per-hop basis.

Table 2. Characteristics of the three HERMES transports.

Dimension	${\mathit{T}}_{\mathbf{HTTP}}$	${\mathit{T}}_{\mathbf{BLE}}$	${\mathit{T}}_{\mathbf{BUNDLE}}$
Typical latency	10 ms–500 ms	50 ms–2 s per hop	seconds to hours
Typical bandwidth	≥10 Mbps	≤1 Mbps practical	limited by storage
Effective range	global (IP-reachable)	30–100 m (legacy 1M-PHY) or up to 150 m (Coded-PHY) per hop	asynchronous, no contemporaneous range
Persistence required	no	no	yes (custodial)
Observability to adversary	high (DPI-visible)	metadata leakage via radio	low if storage is local
Failure mode	IP shutdown, DPI	out of range	storage exhaustion, delivery timeout

3.3. Topology Model

The network topology in HERMES is represented as a labeled directed graph G = (N, E, $\lambda$), where N is the set of participating nodes, E ⊆ N × N is the set of directed communication links, and $\lambda$ is a labeling function that assigns metadata to each edge. Each edge label contains a set of link-state attributes, including the measured round-trip time (RTT), the transport technology used for the measurement, the timestamp of the latest observation, and an estimate of the available link capacity. A directed edge ($n_i$, $n_j$) is included in the graph whenever recent observations show that node $n_i$ can successfully transmit data to node $n_j$ through at least one supported transport.

A distinguishing feature of the HERMES topology model is its support for multiple transport-specific links between the same pair of nodes. Because connectivity may exist simultaneously over HTTP, BLE, and DTN bundle forwarding, the graph maintains separate transport-aware representations of these communication opportunities. As a result, multiple parallel edges may exist between two nodes, each corresponding to a different transport and characterized by its own performance metrics. During route computation, the forwarding engine evaluates these alternatives and selects the transport that best satisfies the routing objectives. This transport-aware representation extends conventional mesh network models, which typically assume a single communication medium for all links.

The topology information maintained by HERMES uses an eventual consistency model. Nodes periodically collect link-state measurements from neighboring peers using all currently available transports. For real-time transports such as HTTP and BLE, measurements are obtained through periodic probing, while disruption-tolerant bundle links are updated opportunistically when contact opportunities arise. Collected measurements are disseminated through a gossip-based synchronization mechanism, allowing topology information to propagate throughout the network without centralized coordination.

As a result of this decentralized dissemination process, the topology maintained by each node represents only a recent approximation of the global network state. The stored view may contain outdated information and does not guarantee instantaneous connectivity. However, repeated exchanges of topology updates ensure convergence toward a consistent representation over time. This eventual consistency is especially well suited to highly dynamic and partition-prone environments, where strong consistency guarantees would be impractical or would significantly reduce system availability.

To prevent obsolete information from influencing routing decisions, each edge has a freshness constraint. Link entries not updated within a configurable validity interval are automatically removed from the topology database by a maintenance process. This mechanism ensures that routing decisions are based on recently observed communication opportunities rather than outdated historical connectivity information.

3.4. Failure and Adversary Model

3.4.1. Failure Model

HERMES uses a fail-stop failure model for participating nodes. In this model, a failed node stops all communication activities, including message transmission, forwarding, and response generation. The node does not produce corrupted data, advertise incorrect state information, or display arbitrary behavior during failure. Upon recovery, transient runtime information is reinitialized, while persistent data such as cryptographic identity material, stored messages, and retained protocol state remain available. This approach aligns with failure models commonly used in distributed systems and microservice-based architectures, where node failures are treated as service interruptions rather than adversarial events. The fail-stop model allows for simple and efficient reliability mechanisms based on acknowledgements, retransmissions, and timeout detection.

In addition to node failures, HERMES treats communication links as independently failure-prone. A link may become unavailable even if both endpoint nodes remain fully operational. Such failures typically appear as increased packet loss or communication timeouts and are detected by network monitoring mechanisms in the topology layer. Link degradation and disconnection are reflected in the routing graph by removing outdated connectivity information. At the messaging layer, unsuccessful transmissions are identified by acknowledgement timeouts and managed with bounded retransmission strategies.

3.4.2. Adversary Model

The threat model in this work describes a network-level adversary operating in environments subject to censorship, Internet disruption, or contested communication infrastructures. The adversary is assumed to be capable of monitoring traffic on public networks, including protocol metadata, communication patterns, and traffic volumes. The adversary may also deploy traffic inspection and filtering mechanisms at strategic network points to selectively block, manipulate, or disrupt communications. The model further assumes that a limited number of relay nodes may be compromised, giving the adversary full visibility into traffic processed by those nodes and the ability to drop, delay, or fail to acknowledge messages routed through them, to advertise false link-state records into the topology service, and to acknowledge messages that they subsequently discard. Additionally, Bluetooth communications may be monitored by adversaries within radio reception range.

The adversary is not assumed to have the capability to compromise the underlying cryptographic primitives used by HERMES. The security guarantees of the cryptographic protocols and algorithms employed by the system are assumed to hold under their standard security assumptions. The long-term identity keys of honest participants are assumed to remain secure, and the adversary is not assumed to have simultaneous access to the internal state of both communicating endpoints.

Within this threat model, HERMES aims to achieve five principal security objectives. First, it provides end-to-end confidentiality, ensuring that message contents are accessible only to the communicating parties and protected from intermediate relays and external observers. Second, it guarantees sender authentication, enabling recipients to verify the origin of received messages. Third, it ensures message integrity by detecting unauthorized modification of transmitted data. Fourth, it preserves forward secrecy across heterogeneous transports, preventing the compromise of protocol state associated with one transport from exposing messages exchanged through another. Finally, it minimizes metadata exposure by limiting the amount of communication information observable by any individual relay or monitoring entity.

These security objectives are designed to provide robust protection in highly dynamic and intermittently connected environments while maintaining the flexibility needed for multi-transport communication across heterogeneous networks. HERMES does not provide full Byzantine fault tolerance: a compromised relay can still deviate arbitrarily from the protocol. However, two specific Byzantine behaviors are now measured rather than merely acknowledged. First, a topology-poisoning relay that advertises false 1 ms links to itself captures and sinks traffic; even at 5% adversarial nodes this collapses delivery to ≈0.37 under scenario S0, far worse than silent dropping, because the attack actively attracts traffic rather than waiting for it. Second, an ACK-and-drop relay defeats the passive risk term entirely: by acknowledging the previous hop it keeps $failure\_rate$ at zero, so Dijkstra continues to route through it. These results delimit the passive defense precisely: it handles relays that fail to acknowledge, not relays that acknowledge falsely or forge topology. Full defense against these stronger behaviors requires authenticated link-state dissemination and signed end-to-end acknowledgements, which we identify as the corresponding active mechanisms.

3.5. Microservice Architecture

Each HERMES node is realised as a composition of four microservices, with the NodeService serving as the user-facing tier. All services within a node are independently deployable processes; they communicate over local HTTP/REST with JSON payloads in the current prototype, with no shared in-process state across service boundaries. This architecture follows the microservice resilience principles characterised by Nygard [13], formalised by Mendonça et al. [30], and reviewed systematically in [14]. Figure 1 shows the four-tier composition; Table 3 lists the services.

Figure 1. HERMES Node Architecture.

Table 3. HERMES microservice architecture: services, responsibilities, and analogues.

Tier	Service	Responsibility	Analogue
Application/Node	NodeService	Receive, validate, route, deliver; probe neighbours; participate in gossip; perform Noise handshakes; manage user-facing API and dashboard.	Application server
Messaging	MessageService	SHA-256 payload integrity verification; TTL enforcement; protocol-version gate; per-hop message validation.	API gateway
Reliability	ReliabilityService	Atomic deduplication via Redis SET NX; pending-state tracking; ACK accounting; retry coordination.	State store
Coordination	TopologyService	Aggregate gossip; maintain global topology graph; compute Dijkstra inputs; prune stale edges; expose observability dashboard.	Service registry/router

3.5.1. NodeService

The NodeService is the user-facing tier and the only service that holds transport interfaces. It runs one transport adapter per active transport in $I_i$: an HTTP adapter that exposes inbound REST endpoints and dispatches outbound HTTP requests; a BLE adapter that uses the platform’s Bluetooth stack to advertise, scan, and exchange messages with co-located peers; and a bundle adapter that implements a Bundle-Protocol-Version-7-style convergence layer [7] with a local persistent store for custodial bundles. The NodeService also originates and consumes user messages via a local Application Programming Interface (API), performs Noise XX handshakes [17] with new peers, and provides the observability dashboard.

3.5.2. MessageService

The MessageService is called by the NodeService at every receive event, regardless of transport, and performs three checks: (i) the message’s Secure Hash Algorithm 256-bit (SHA-256) payload hash matches the value declared in the message header, ensuring accidental-corruption integrity; (ii) the message’s Time to Live (TTL) is greater than zero, otherwise the message is dropped with a $TTL\_STOP$ log event; and (iii) the message’s protocol version is supported. The MessageService is intentionally stateless across messages, making it inexpensive to scale and easy to restart. When the MessageService is unavailable, the NodeService falls back to local validation, skipping the hash check—an acceptable degradation.

3.5.3. ReliabilityService

The ReliabilityService uses a Redis key–value store to provide per-hop reliability primitives. Its main function is atomic deduplication using the Redis SET NX EX command, with a per-node key format (message:node:nodeId:id:messageId). This approach converts at-least-once delivery into effectively-once delivery without requiring application-level locking: Redis ensures that only one concurrent caller can set a key that does not already exist, and the key’s TTL (default 300 s) prevents unbounded memory growth. The ReliabilityService also tracks the pending state for in-flight messages (messages dispatched but not yet acknowledged) and manages retries. If the ReliabilityService is unavailable, the NodeService skips deduplication and continues forwarding messages, following a fail-open policy that prefers delivering a possible duplicate over dropping a possible original.

3.5.4. TopologyService

The TopologyService aggregates gossip from all nodes in the network and maintains the multi-transport topology graph G. It exposes the graph to NodeServices for Dijkstra-based forwarding decisions and runs a background pruning process to remove stale edges. The impact of losing the TopologyService is now quantified rather than merely asserted. With the coordinator taken permanently offline at t = 30 s and transport left intact, the cached-topology fallback bounds the damage in every configuration tested: under a static topology, delivery stays at 1.000 for all failure durations, and at pedestrian speed (1.5 m/s) it remains ≥0.93. The two pruning loci trade off differently—local pruning preserves delivery (≥0.997) at a latency cost as the believed graph collapses to the one-hop neighborhood and Bundle custody carries ≈80% of traffic, while central (frozen-graph) pruning keeps latency lower but degrades delivery to 0.907 at 5 m/s. The coordinator is therefore a performance dependency, not a correctness dependency; a CRDT-replicated TopologyService that eliminates it entirely is specified as future work.

3.6. Consistency, Availability, and Positioning

According to the CAP theorem [15,16], a distributed system can guarantee at most two of consistency, availability, and partition tolerance. HERMES intentionally chooses availability and partition tolerance. The topology graph is eventually consistent; stale edges may occur, and nodes continue routing using cached topology when the TopologyService is unreachable. The rationale is that for a routing system designed for connectivity disruption, approximate routing is preferable to no routing. This approach aligns HERMES with the design philosophy of Dynamo-class key–value stores [43], Cassandra, and the broader gossip-based membership tradition. The trade-off is that routing decisions based on stale topology may select suboptimal paths or, in adversarial cases, paths that no longer exist. The reliability layer is designed to detect and recover from such cases through ACK timeouts and bounded retries.

Table 4 positions HERMES against the most directly comparable existing systems. The comparison clarifies what is and is not novel: HERMES inherits its routing primitive (Dijkstra over a measured graph) from Open Shortest Path First (OSPF), its eventual consistency model from Dynamo-class systems, its store-and-forward semantics from DTN, its multi-protocol comparison framing from the DTN routing literature, and its BLE-mesh civilian messaging instinct from Bitchat. The novelty lies in their combination: HERMES is, to the authors’ knowledge, the first system to treat HTTP, BLE-mesh, and DTN-bundle transports as parallel first-class edges in a single routing decision, with end-to-end encryption that survives transitions between them, and to demonstrate that this combination achieves delivery comparable to flooding-based DTN protocols while transmitting 21–35× fewer bytes.

Table 4. HERMES positioning against directly comparable systems.

System	Routing	Transport(s)	Encryption	Coordinator	Persistence
OSPF [44]	Link-state Dijkstra	IP only	none at routing layer	decentralised (areas)	—
DTN/BPv7 [7]	Custody-based, contact graphs	Bundle over arbitrary CL	BPSec, pre-shared keys [36]	none	yes (custodial)
Epidemic [21]	Unbounded flooding	Single-transport contact graph	none (orthogonal)	none	yes (per-relay)
PRoPHET [22]	Encounter-probability forwarding	Single-transport contact graph	none (orthogonal)	none	yes (per-relay)
Bitchat [12]	Flooding with TTL = 7	BLE-mesh + Nostr fallback	Noise XX, end-to-end	none	no
Bridgefy	Flooding, BLE-mesh	BLE only	broken [27]	none	no
Our Solution-HERMES	Metric-driven multi-transport Dijkstra with per-hop handoff (TTL = 16)	HTTP + BLE-mesh + DTN-bundle	Noise XX + Double Ratchet, transport-agnostic	central TopologyService (AP)	yes (bundle layer)

3.7. End-to-End Walkthrough

To make the model concrete, we trace the delivery of a single message m from sender $n_s$ to recipient $n_d$ through the architecture. Suppose $n_s$ and $n_d$ are not direct neighbors and that a path $n_s$→$n_a$→$n_b$→$n_d$ exists across mixed transports (Figure 2).

Figure 2. Message m from $n_s$ to $n_d$ via $n_a$ and $n_b$.

At $n_s$, the user submits m via the local API. The NodeService initiates or reuses a Noise XX session with $n_d$ and produces an authenticated ciphertext c that wraps m end-to-end. It assigns c a fresh message identifier, sets TTL to 16, and queries the local TopologyService cache for the shortest path to $n_d$. Dijkstra returns the next hop $n_a$ and the transport selected for the $n_s$ to $n_a$ edge, for example, T_HTTP. The NodeService dispatches c to $n_a$ over HTTP.

At $n_a$, the inbound HTTP adapter receives c. The MessageService validates the SHA-256 hash, TTL, and protocol version. The ReliabilityService checks the deduplication key for ($n_a$, message_id); since the message has not been seen before, the key is set. The NodeService consults its TopologyService cache, runs Dijkstra excluding $n_s$ (to prevent immediate backtracking), and obtains the next hop $n_b$ on transport T_BLE. The NodeService decrements TTL (now 15), forwards c to $n_b$ over BLE, and upon receiving an ACK from $n_b$, returns an ACK to $n_s$.

At $n_b$, the same per-hop sequence executes: MessageService validation, deduplication, and route lookup. Suppose the only path to $n_d$ at this moment is via T_BUNDLE because $n_d$ is currently offline. The NodeService encapsulates c into a bundle, commits it to local custodial storage, and, on the next contact with $n_d$, transmits the bundle. $n_d$ receives the bundle, runs MessageService validation, deduplicates against its local Redis, decrypts c using its half of the Noise session state with $n_s$, and delivers m to the user. An ACK propagates back along the reverse path.

This walkthrough illustrates the three properties that distinguish HERMES. First, the routing decision at each hop is independent and considers all available transports, rather than being committed to a transport at the source. Second, the reliability and validation pipeline is uniform across transports: every receive event, whether it arrives over HTTP, BLE, or bundle, passes through the same MessageService and ReliabilityService logic. Third, the encryption envelope is opened only at $n_d$; $n_a$ and $n_b$ see only ciphertext plus the minimum routing header required to forward.

4. Routing Algorithm and Transport-Aware Handoff

In this section, we explain how HERMES determines where to forward a message at each hop. We describe how each node builds its local view of the network, the shortest-path computation, the transport-aware handoff policy that selects among HTTP, BLE, and Bundle, the TTL sizing that limits path length, and the complete forwarding pseudocode. Routing failures and fallback are addressed in the last section.

4.1. Building the Local Topology View

Each node $n_i$ maintains a local copy of the network graph $G_i$. This copy is updated from two sources. The first source is gossip from the TopologyService, which carries edge records ($n_x$, $n_y$, rtt, transport, $t_{last}$). The second source is the node’s own RTT probes to its direct neighbors, which generate fresh edge records at each probe interval. Both sources update the same in-memory graph.

To bound maintenance overhead, probing is limited to neighboring nodes connected through currently active, probe-capable transports (i.e., $T_{\mathrm{HTTP}}$ and $T_{\mathrm{BLE}}$), rather than all $N-1$ nodes in the network. Consequently, the per-round probing cost scales with the number of active incident links, denoted $\mathrm{incidentUp}$, instead of the total network size. This avoids the apparent $O\left(N^2\right)$ complexity of topology maintenance and forms the basis of the bandwidth model. Under this model, each probe incurs an overhead of $2\times 53$ B per active incident edge, while each gossip round requires

$$\mathrm{incidentUp}\times \left(53+\mathrm{incidentUp}\times 24\right)\mathrm{B}.$$

Probes run every 10 s for T_HTTP and T_BLE. T_BUNDLE cannot be probed in the usual way because the purpose of a bundle transport is that the other side may not be present. Instead, an edge for T_BUNDLE is recorded only when a successful bundle handover occurs, so bundle edges update slowly but reflect actual delivery events rather than reachability tests.

Each edge has a freshness timestamp $t_{last}$. A background process in TopologyService prunes edges whose freshness exceeds 60 s (configurable). The reason for pruning is that a 50-s-old Round-Trip Time (RTT) measurement is less useful than no measurement at all—Dijkstra will route a packet across a link that no longer exists. Stale data is removed even if this makes the graph more sparse.

The graph is multi-edge: between any two nodes ($n_i$, $n_j$), there can be up to three parallel edges, one per transport, each with its own RTT. This is the structural change from a standard OSPF-style graph and enables multi-transport decisions. A single-edge graph would force the choice of transport at the time of measurement; the multi-edge graph defers that choice until routing time.

4.2. Shortest-Path Computation

Forwarding uses Dijkstra’s algorithm over $G_i$. The weight of an edge is its measured RTT plus a defined transport-dependent cost. Dijkstra is the natural choice here for three reasons. First, edge weights are non-negative—RTTs and penalties are always ≥ 0. Second, the graph is small in practice (tens to a few hundred nodes), so Dijkstra runs in well under a millisecond on commodity hardware. Third, this is the same algorithm OSPF uses [44], so the design inherits the convergence and stability properties of a well-studied protocol.

We considered Bellman-Ford and A* but rejected both. Bellman-Ford handles negative weights, which we do not have. A* requires a heuristic, and in a multi-transport graph that heuristic would need to be transport-aware, which complicates reasoning about correctness. Dijkstra with adjusted weights is simpler and sufficient.

When Dijkstra returns a path P = ($n_i$, $n_a$, $n_b$, …, $n_d$), node $n_i$ takes only the first hop $n_a$ from this path and the transport label on the edge ($n_i$, $n_a$). The rest of the path is discarded. This is intentional: forwarding decisions are made per hop. The next node $n_a$ will run its own Dijkstra on its own view of G when the message arrives and may choose a different transport than $n_i$ predicted. This is the same hop-by-hop forwarding model IP uses, and it ensures that if the topology changes mid-route, the message can still reach the destination because each hop re-evaluates the path.

4.3. Transport-Aware Handoff Policy

The handoff policy determines, at each hop, which transport to use among the available edges to the candidate next hop. The policy is defined as a cost function over a candidate next hop $n_j$:

$$\mathrm{cost}(n_i\to n_j,T)=\mathrm{RTT}(n_i,n_j,T)+\mathrm{penalty}\left(T\right)+\mathrm{risk}(n_i,n_j,T)$$

(1)

where T ∈ T_HTTP, T_BLE, T_BUNDLE ranges over the transports for which an edge ($n_i$, $n_j$, T) exists in $G_i$.

4.3.1. The RTT Term

RTT($n_i$, $n_j$, T) is the most recent measured round-trip time on the edge ($n_i$, $n_j$) over transport T. For T_BUNDLE, this is the time between bundle dispatch and ACK of custody, which can be seconds or longer. For T_HTTP and T_BLE, it is the recent probe RTT. The RTT value is in milliseconds and dominates the cost for low-latency transports.

4.3.2. The Penalty Term

The penalty (T) is a fixed per-transport cost that encourages the policy to select the optimal transport when both are available. The values used are shown in Table 5:

Table 5. Transport penalty values (in milliseconds).

Transport	Penalty (ms)	Reasoning
$T_{\mathrm{HTTP}}$	0	Default transport; no penalty.
$T_{\mathrm{BLE}}$	500	Higher energy cost on mobile devices; metadata visible to nearby radios.
$T_{\mathrm{BUNDLE}}$	5000	Long delivery delay possible; storage cost on relay.

These values are not derived from first principles. They were chosen so that when all three transports are available HTTP is preferred; when HTTP is unavailable BLE is preferred over Bundle; and Bundle is used only as a last resort. The NS-3 parameter sweep confirms there is a broad plateau of (penalty_BLE, penalty_Bundle) values that produce indistinguishable delivery ratios at the default operating point.

4.3.3. The Risk Term

The risk ($n_i$, $n_j$, T) is the only non-static term. It indicates how likely the edge is to fail at this moment.

$$\mathrm{risk}(n_i,n_j,T)=\alpha ·(\mathrm{now}-t_{\mathrm{last}})+\beta ·\mathrm{failure}\_\mathrm{rate}(n_i,n_j,T)$$

(2)

where $t_{last}$ is the freshness of the edge, and failure_rate is the fraction of the last 10 messages on this edge that did not receive an ACK. The constants are $\alpha$ = 10 ms per second of staleness and $\beta$ = 1000 ms per unit of failure rate. The first term causes Dijkstra to gradually distrust stale edges before they are pruned at 60 s. The second term causes Dijkstra to avoid edges that have been failing recently. Without this term, Dijkstra selects the cheapest path even if that path has just failed three times in a row.

Both constants are swept over their full operating range rather than asserted. On the staleness axis (Figure 3, left), delivery under blackout rises monotonically with $\alpha$: at 5 m/s the ratio is 0.667 with the term disabled ($\alpha$ = 0), 0.780 at the default $\alpha$ = 10, and 0.876 at $\alpha$ = 20; at 1.5 m/s the corresponding values are 0.877, 0.935, and 0.968. The staleness weight is therefore the effective lever under mobility—probe rate is not. On the failure axis (Figure 3, right), under a 30% silent-drop adversary the delivery ratio is 0.839 with the failure term disabled ($\beta$ = 0) and 0.930 at the default $\beta$ = 1000, isolating the term’s contribution at +0.091 while retry and reroute account for the remainder. Delivery is insensitive to $\beta$ across a broad region (0.892–0.930 for $\beta$ between 50 and 1000); the default sits at the maximum of that region, and values an order of magnitude larger over-penalize recently failed edges and give back part of the gain. A malicious relay that drops messages cannot acknowledge them; the failure_rate on edges through that relay increases; the risk term makes those edges expensive, and Dijkstra routes around them.

Figure 3. Risk-term sensitivity (NS-3, $N=100$, medium, BLE 150 m, TTL = 16, 10 seeds). (Left): staleness weight $\alpha$ under blackout at 1.5 and 5 m/s ($\beta =1000$). (Right): failure weight $\beta$ under a 30% silent-drop adversary ($\alpha =10$). Dotted lines mark the defaults.

4.4. TTL Sizing

The application-layer TTL sets the maximum number of hops a message can traverse. It prevents routing loops and limits how far a single message can propagate. Choosing the right value is more important than it may appear: a TTL that is too small restricts paths in deep topologies and forces premature Bundle fallback, while a TTL that is too large allows messages to circulate longer than necessary and wastes bandwidth.

For a network of N nodes with a BLE contact graph of mean degree d, the expected diameter is O(log_d N). At our default operating point (N up to a few hundred, d ≈ 6.6 at medium density with BLE Coded-PHY 150 m range), the expected diameter is about 3 hops, but tail paths through low-degree corridors can reach 10–12 hops. We use TTL = 16 as a conservative bound to cover the tail without causing excessive circulation.

For comparison, Bitchat [12] uses TTL = 7 in its BLE-mesh deployment, which is limited by the same physical reasoning (cluster diameter in a crowd) but does not apply to mixed HTTP + BLE + Bundle topologies of arbitrary scale. Our TTL = 16 is larger because the design must accommodate longer BLE-only paths during Internet blackout, which Bitchat’s all-flood approach does not require.

4.5. Forwarding Pseudocode

The complete forwarding decision at node $n_i$ when a message m arrives for destination $n_d$ is shown in Algorithm 1. First, Dijkstra’s algorithm is run once for each candidate transport, restricting the first hop to that transport. This approach allows the policy to compare transports directly, rather than selecting among them only at the source. Second, the cost function is evaluated only on the first hop, as that is the only hop $n_i$ actually controls; downstream nodes may use different transports for the remainder of the path. Third, an ACK timeout triggers a failure mark on the specific (edge, transport) pair, which is incorporated into the risk term and increases the cost of the failed path in future decisions.

Algorithm 1 Metric-driven multi-transport forwarding at a node.

1: function Forward(m, $n_d$)   2:     if $n_d=\mathit{self}$ then   3:         Deliver(m)   4:         return   5:     end if   6:     if $m.\mathrm{TTL}\le 0$ then   7:         Drop(m, reason=’TTL_STOP’)   8:         return   9:     end if 10:     $m.\mathrm{TTL}\leftarrow m.\mathrm{TTL}-1$ 11:     $G\leftarrow$ LocalTopologyView( ) 12:     $\mathit{candidates}\leftarrow \left[\right]$ 13:     for all transport $T\in \{\mathrm{HTTP},\mathrm{BLE},\mathrm{BUNDLE}\}$ do 14:         $\mathit{path}\leftarrow$ Dijkstra(G, self, nd, restrictFirstHop=T) 15:         if $\mathit{path}\ne$ None then 16:            $n_{\mathit{next}}\leftarrow \mathit{path}\left[1\right]$ 17:            $c\leftarrow$ Cost(self, nnext, T) 18:            $\mathit{candidates}.$append((c, nnext, T)) 19:         end if 20:     end for 21:     if $\mathit{candidates}$ is empty then 22:         return EnqueueForLater(m) 23:     end if 24:     $(c_{min},n_{\mathit{next}},T_{\mathit{chosen}})\leftarrow min\left(\mathit{candidates}\right)$ 25:     Dispatch(m, $n_{\mathit{next}}$, $T_{\mathit{chosen}}$) 26:     WaitForAck($\mathit{timeout}=$ AckTimeout(Tchosen)) 27:     if no ACK received then 28:         MarkFailure($\mathit{self}$, $n_{\mathit{next}}$, $T_{\mathit{chosen}}$) 29:         RetryOrChooseAlternate(m) 30:     end if 31: end function

Algorithm 2 expands the two procedures invoked by Algorithm 1. Two details distinguish it from textbook Dijkstra. First, relaxation iterates over parallel edges rather than over neighbors: between any ordered pair $(u,v)$ the graph may hold up to three edges, one per transport, each with its own round-trip time and freshness timestamp, and each is relaxed independently. Second, the first-hop restriction admits only edges of transport $T^{*}$ leaving the source, so that running the procedure once per transport yields three directly comparable candidates. This is the mechanism by which the policy compares transports at each hop rather than committing to one at the source, and it is the structural difference from the single-medium graphs assumed by conventional mesh routing.

The cost function is evaluated at every relaxation, but only the first hop and its transport label are retained: downstream nodes rerun the procedure against their own view of G and may select different transports for the remainder of the path. Path length is not bounded inside the search; it is bounded at forwarding time by the TTL decrement of Algorithm 1. The staleness contribution is bounded by the pruning interval, since edges older than ${\tau }_{\mathrm{prune}}=60\mathrm{s}$ are removed from G; the term therefore contributes at most $\alpha ·{\tau }_{\mathrm{prune}}=600\mathrm{ms}$ before the edge disappears altogether.

With N nodes and at most $3N^2$ directed edges, the procedure runs in $O(ElogN)$ with $E\le 3N^2$, and Algorithm 1 invokes it once per candidate transport, so a single forwarding decision costs at most three runs. At the scales evaluated here ($N\le 500$) this completes in well under a millisecond on commodity hardware, which is why the routing computation does not appear in the latency budget of the latency section.

Algorithm 2 Multi-edge Dijkstra and the transport-aware cost function.

1: function Cost(u, v, T)   2:     $s\leftarrow min$ (Now$\left(\right)-t_{\mathrm{last}}(u,v,T),{\tau }_{\mathrm{prune}}$)   3:     f ← FailureRate$(u,v,T)$   4:     return Rtt$(u,v,T)+\mathrm{penalty}\left[T\right]+\alpha ·s+\beta ·f$   5: end function

6: function Dijkstra(G, $src$, $dst$, $T^{*}$)   7:     $dist[·]\leftarrow \infty$;   $prev[·]\leftarrow \perp$;   $dist\left[src\right]\leftarrow 0$   8:     $Q\leftarrow$ min-heap keyed by $dist$;   Push$(Q,src,0)$   9:     while $Q\ne \varnothing$ do 10:         $(u,k)\leftarrow$ PopMin(Q) 11:         if $k>dist\left[u\right]$ then 12:            continue 13:         end if 14:         if $u=dst$ then 15:            break 16:         end if 17:         for all edges $(u,v,T)\in$ Out(u) do 18:            if $u=src$ and $T\ne T^{*}$ then 19:                continue 20:            end if 21:            $w\leftarrow$ Cost(u, v, T) 22:            if $dist\left[u\right]+w<dist\left[v\right]$ then 23:                $dist\left[v\right]\leftarrow dist\left[u\right]+w$;   $prev\left[v\right]\leftarrow (u,T)$ 24:                Push$(Q,v,dist[v\left]\right)$ 25:            end if 26:         end for 27:     end while 28:     if $prev\left[dst\right]=\perp$ then 29:         return None 30:     end if 31:     return Reconstruct$(prev,src,dst)$ 32: end function

4.6. Routing Failures and Fallback

Two routing failures must be addressed. The first occurs when no path exists in $G_i$—either the destination has never been discovered, or all known paths have been pruned. In this case, the node enqueues the message in its local bundle store and retries upon the next topology update. Gossip events trigger a re-evaluation of the queue, so the routing failure results in delayed delivery rather than message loss. This is the primary purpose of using T_BUNDLE as a fallback.

The second failure occurs when a path exists but the selected next hop does not acknowledge. After max_retries attempts—by default, three times with exponential backoff and jitter—the node marks the (edge, transport) as failed and re-runs the cost function, which will then select the second-best path. If the second-best path also fails, the message is placed in the bundle queue. We chose exponential backoff with jitter instead of the linear backoff used in some earlier mesh designs because linear backoff can cause retry storms when multiple nodes recover from the same failure simultaneously [14].

5. Reliability, Consistency, and End-to-End Security

In this section, we explain how HERMES ensures that the forwarding decisions from previous section result in delivered messages: per-hop reliability, eventual consistency without locks, graceful degradation, and end-to-end encryption that persists across transport switches.

5.1. Per-Hop Reliability

At each hop, HERMES uses a stop-and-wait acknowledgment scheme. The sender transmits the message, waits for an ACK from the next hop, and considers the hop complete only when the ACK is received. If no ACK arrives within ack_timeout, the message is retried up to max_retries times with exponential backoff and random jitter. The timeout depends on the transport: it is short for HTTP (typically 1 s), longer for BLE (5 s), and very long for Bundle (configurable, with a default of 30 s before declaring the contact lost).

We chose per-hop ACK over end-to-end ACK because end-to-end ACK does not work when the path crosses a Bundle relay: the destination may be unreachable for hours, and waiting for an end-to-end ACK that long would block the sender. Per-hop ACK provides the sender with immediate feedback (the next hop has custody) without requiring commitment to end-to-end delivery time.

The TTL is decremented at each hop, and a message with TTL = 0 is dropped with a TTL_STOP event. The empirical saturation sweep in Section 6 confirms that TTL = 16 is sufficient for all network sizes evaluated (N up to 500).

5.2. Eventual Consistency Without Locks

HERMES uses no distributed lock. Two properties make this possible. First, the deduplication store (Redis) provides atomic SET NX, which guarantees that two concurrent attempts to register the same (node, message_id) pair will result in exactly one success and one failure, without any explicit lock on the caller side. Second, the routing graph is eventually consistent: each node has a local view and makes decisions based on that view, so there is no shared mutable state that requires synchronization. This works because the system is an availability and partition-tolerance (AP) system under CAP [15,16]: we prioritize availability over consistency. A node that cannot reach the TopologyService falls back to cached topology. A node whose Redis is unreachable falls back to local in-memory deduplication (weaker but does not block forwarding). A node that cannot reach the MessageService skips the SHA-256 check. In every case, the principle is the same: keep the message moving, even with slightly weaker guarantees, because in our scenario, a message that gets through with a small risk of duplication is better than a message that does not get through at all.

5.3. Circuit Breaker and Graceful Degradation

Every service-to-service call within the node is wrapped in a circuit breaker [13]. The breaker has three states: CLOSED (calls pass through), OPEN (calls fail immediately without attempting), and HALF_OPEN (one test call is allowed; based on its result, the breaker either reopens or returns to CLOSED). The thresholds we use are: five consecutive failures move the breaker from CLOSED to OPEN; the breaker remains OPEN for 30 s; one HALF_OPEN test call determines whether to recover.

Each service has a defined degradation behavior when its breaker is OPEN, as shown in Table 6. In all four cases, the principle is that the system continues to forward messages, but with reduced guarantees. This follows the same fail-open philosophy used in production microservice systems [14,30], and is appropriate for HERMES because the alternative—refusing to forward—is the worst possible outcome for a wartime messaging system. When the HTTP adapter’s circuit breaker is OPEN, the cost function simply finds no candidates with T = T_HTTP, so it selects among T_BLE and T_BUNDLE. The multi-transport design enables graceful degradation at the transport layer, not just at the service layer.

Table 6. Circuit breaker degradation behaviour per service.

Service	When Breaker is OPEN, the Node…
MessageService	Skips SHA-256 verification; TTL and version still checked locally.
ReliabilityService	Skips Redis dedup; uses local in-memory dedup table (smaller, per-process).
TopologyService	Routes using cached topology graph (last known snapshot); does not update.
Any transport adapter	Drops that transport from candidates in the cost function; chooses among the remaining two.

5.4. End-to-End Authenticated Encryption Across Transports

HERMES protects message content with end-to-end authenticated encryption. The primitives are standard: Noise XX [17] for session establishment, ChaCha20-Poly1305 [18] for authenticated encryption with associated data (AEAD) ciphertext, X25519 for key agreement, and Ed25519 for long-term identity. We use the Double Ratchet [19,20] for forward secrecy and post-compromise security. The contribution is how these components fit together when the message can travel over three different transports between the sender and receiver.

5.4.1. Identity and Key Derivation

Each node has a long-term Ed25519 identity key pair ($s{k}_i$, $p{k}_i$). This identity remains the same regardless of the transport the node uses. It is not tied to an IP address, a Bluetooth MAC address, or any transport-specific identifier. This is important because a node may be reachable over HTTP at time t and over BLE at time t+1, and the recipient must still recognize it as the same sender. Transport-specific keys (such as TLS keys for HTTP, BLE link keys, and Bundle Protocol Security keys) are derived from the long-term identity using HMAC-based key derivation function (HKDF) with transport-specific salts, so compromise of one transport’s key does not directly compromise the others.

5.4.2. Session Establishment

When $n_s$ wants to send the first message to $n_d$, it initiates a Noise XX handshake. The handshake consists of three messages (-> e, <- e, ee, s, es, -> s, se). Each of these messages can be transmitted over any transport. For example, if the first message is sent over HTTP and the second is returned over BLE, the handshake still completes correctly because the Noise state machine does not depend on which transport carries each byte. This is a practical advantage of using Noise instead of Transport Layer Security (TLS): Noise is transport-agnostic by design, while TLS is tied to a single TCP connection.

After the handshake, $n_s$ and $n_d$ share a session state consisting of a root key, a sending chain key, and a receiving chain key. This session state remains the same regardless of which transport is used for future messages.

5.4.3. Forward Secrecy Across Transport Switches

This is the part that fails in a naive composition of TLS, Noise, and BPSec. In the naive approach, each transport maintains its own session state and ratchet, so switching transports requires starting over. Forward secrecy is lost because the new transport’s session is freshly negotiated from long-term keys, not from a continuing ratchet.

HERMES addresses this by ratcheting per message, not per transport. After each message is sent, the sending chain key is advanced (KDF step), and after each message is received, the receiving chain key is advanced. The transport over which the message is carried does not affect the ratchet computation. For example, if $n_s$ sends $m_1$ over HTTP, $m_2$ over BLE, and $m_3$ as a bundle, the sending chain advances three times, and $n_d$’s receiving chain advances three times to match. A compromise of the session state at any point reveals only messages received after that point, regardless of the transport used. This is the forward secrecy property of the original Signal protocol [33], extended across transports.

The integration is verified by the prototype’s automated test suite, which exercises this cross-transport composition end-to-end. We do not provide a formal cryptographic analysis of the composition itself; instead, we provide an implementation that uses primitives with published formal analyses [20,28,33] in a configuration that the test suite confirms preserves forward secrecy across transport switches.

5.4.4. Out-of-Order Arrival and the Skipped-Key Window

The complication with per-message ratcheting is that messages may arrive out of order, especially when they are sent over different transports. Suppose $n_s$ sends $m_1$ over HTTP and $m_2$ over BLE-and-bundle, which takes longer. If $n_d$ receives $m_1$ first, the receiving chain advances once. If $n_d$ receives $m_2$ first, the chain must skip one step, and the key for $m_1$ must be stored so it can decrypt $m_1$ when it arrives later. This is the same problem the original Double Ratchet solves [19], and we use the same mechanism: a small, bounded cache of skipped message keys. The Signal default is 1000; we use 100 since our message volumes are lower. If a message arrives too late and its key has been evicted from the cache, the message is dropped.

6. Experimental Evaluation

The evaluation consists of two complementary parts. First, we present results from the C# prototype on a five-node testbed, which exercises the actual implementation, including microservices, real network sockets, and real encryption primitives. Next, we present NS-3 simulation results that extend the evaluation to larger scales (up to N = 500), compare against published DTN routing protocols, and characterize behavior under mobility and adversarial conditions. The two evaluations are shown in separate tables because they address different questions; combining their numbers would be a methodological error. All values are reported as mean ± standard deviation over 10 independent runs with different random seeds, at medium load (10 messages per second) unless otherwise specified.

6.1. Methodology

6.1.1. Prototype Testbed

The prototype runs in C# on .NET 9 across four microservices: NodeService, MessageService, ReliabilityService (backed by Redis 7), and TopologyService. Five nodes operate as separate processes on a single Linux host (Ubuntu 24.04, 16 GB RAM, 8 cores). The HTTP transport uses real TCP sockets on localhost. The BLE transport is emulated as a software channel with configurable latency (uniform 100–250 ms) and a 1 Mbps rate cap. The Bundle transport is a custodial, SQLite-backed store-and-forward layer with a configurable delivery delay (lognormal, mean 5 s, sigma 0.5 s). The five-node topology is shown in Figure 4. Encryption is enabled in all prototype experiments unless otherwise stated.

Figure 4. Network topology graph G with parallel transport edges.

6.1.2. NS-3 Simulation

The NS-3 evaluation uses a custom HERMES application module that implements the same routing algorithm and cost function as the prototype, with cryptography represented as a fixed per-message latency penalty calibrated from the prototype’s measured per-hop overhead of 0.17 ms. The simulator models HTTP as a CSMA channel, BLE as a custom range-based point-to-point channel, and Bundle as an asynchronous custodial queue. Nodes are placed uniformly at random within a 1000 m × 1000 m square. Density labels are defined as follows: sparse (50 nodes per km², average BLE degree 3.3), medium (100 nodes per km², degree 6.6), and dense (250 nodes per km², degree 15.9). BLE range is set to 150 m, modeling the Bluetooth 5.0 Coded-PHY long-range mode used in real mesh deployments.

The simulator’s BLE range is intentionally set higher than in the original prototype topology, which used 50 m, the standard 1M-PHY range. This is necessary because contact-based DTN baselines (Epidemic, PRoPHET, Spray-and-Wait) only function when the BLE contact graph is connected. At 50 m and N ≥ 100, the contact graph is fragmented, and these protocols would deliver nearly zero, making the comparison meaningless. HERMES is run at the same 150 m to ensure a fair comparison.

6.1.3. Failure Scenarios

We compare four failure scenarios applied identically in both prototype and simulation. S0 (no failure) serves as the steady-state baseline. S1 (relay crash) permanently disables a designated relay node at t = 30 s. S2 (TopologyService partition) makes the central coordinator unreachable from t = 30 to t = 90 s. S3 (Internet blackout) disables all HTTP transport globally from t = 30 to t = 90 s. Each experiment runs for 90 s of steady-state traffic after a 30-s warmup period, which is excluded from the metrics.

6.1.4. Routing Variants

Four routing variants in the prototype are: HERMES (full multi-transport handoff), HTTP-only (HERMES restricted to T_HTTP), BLE-only (HERMES restricted to T_BLE), and Flooding (TTL = 7 controlled flooding across all available transports, modeled on Bitchat [12]). In NS-3, we add three published DTN baselines: Epidemic [21] (unbounded flooding with summary-vector exchange), PRoPHET [22] (probabilistic forwarding with P_init = 0.75, $\beta$ = 0.25, $\gamma$ = 0.98 as in the original paper, unrelated to the failure weight $\beta$ in the risk term section), Spray-and-Wait [23] (L = 10 copies), and MaxProp (prioritised scheduling with delivered-ACK deletion), the last evaluated at the byte level only.

The DTN baselines use their canonical parameter values from the published literature; only the TTL in HERMES was varied in this work. We confirm by direct comparison that the baseline measurements (delivery ratio and transmissions) are byte-identical for both TTL = 4 and TTL = 16 runs.

6.2. Prototype Delivery Ratio

Delivery ratio is the fraction of originated messages that reach their destination before the experiment ends. Table 7 shows the results for each scenario and routing variant on the five-node testbed.

Table 7. Delivery ratio (%) by scenario and routing variant—prototype, five nodes, medium load.

Scenario	HERMES	HTTP-Only	BLE-Only	Flooding
S0 (no failure)	$100.0\pm 0.0$	$59.6\pm 2.2$	$59.8\pm 1.8$	$100.0\pm 0.1$
S1 (relay crash)	$100.0\pm 0.1$	$34.4\pm 1.4$	$100.0\pm 0.0$	$98.9\pm 0.4$
S2 (topology partition)	$100.0\pm 0.0$	$59.9\pm 2.5$	$58.6\pm 2.4$	$100.0\pm 0.1$
S3 (Internet blackout)	$100.0\pm 0.0$	$29.7\pm 0.7$	$60.5\pm 2.2$	$98.5\pm 0.4$

Three findings stand out. First, HERMES achieves perfect delivery in every scenario. Second, both single-transport baselines reach about 60% in S0 because the topology includes node pairs that cannot be reached using a single transport ($n_3$ has no BLE connectivity; $n_4$ has no HTTP). This demonstrates the value of multi-transport routing. Third, HTTP-only collapses under both S1 and S3 (34% and 30%), confirming the fragility of the single-transport approach in the scenarios motivating this work.

A note on BLE-only achieving 100% under S1: in the prototype topology, the crashed node $n_3$ has no BLE neighbors, so its loss does not affect BLE-only paths. This is a topology artifact rather than a property of BLE itself; in a network where the crashed node was BLE-active, the number would be lower.

6.3. Prototype Latency

End-to-end latency is measured from the time a message originates at the sender to its delivery at the recipient. Table 8 reports HERMES’s percentiles compared to the best single-baseline alternative for each scenario.

Table 8. End-to-end latency (ms) on the prototype. HERMES P50/P95/P99 vs. best-baseline P50.

Scenario	HERMES P50	HERMES P95	HERMES P99	Best Baseline P50
S0	$64\pm 4$	$166\pm 12$	$574\pm 142$	Flooding: $62\pm 2$
S1	$106\pm 9$	$219\pm 26$	$700\pm 28$	BLE-only: $162\pm 26$
S2	$64\pm 3$	$155\pm 8$	$608\pm 37$	Flooding: $61\pm 2$
S3	$114\pm 13$	$\mathrm{12,883}\pm 520$	$\mathrm{14,795}\pm 108$	Flooding: $103\pm 4$

HERMES’s median latency remains in the low hundreds of milliseconds across all scenarios. Under S2, it is essentially identical to S0 because cached topology continues to function. Under S1 and S3, the median increases modestly (by 50–60 ms) because more messages traverse BLE paths.

The key observation is the tail behavior under S3. The 95th percentile (P95) reaches 12.9 s, and the 99th percentile (P99) reaches 14.8 s with the prototype’s TTL = 4 configuration. This reflects the cost of falling back to Bundle for node pairs without contemporaneous HTTP or BLE paths: the Bundle transport’s lognormal delivery delay imposes a floor in the multi-second range. Approximately 10% of messages take seconds rather than milliseconds. The tail shortens substantially with the higher TTL = 16 used in all NS-3 experiments.

6.4. Prototype Transport Mix

In Table 9, under S0, HERMES uses HTTP for 76% of hops, consistent with the cost function’s preference for HTTP when all transports are available. Under S1, the HTTP share drops to 55% and BLE rises to 45%; the cost function adapts automatically to the loss of $n_3$. Under S2, the mix is essentially identical to S0 because the topology has not changed—only the central coordinator is unreachable. Under S3, the mix shifts dramatically: HTTP drops to 37%, BLE rises to 53%, and Bundle accounts for 10%, corresponding exactly to the paths with no contemporaneous BLE or HTTP option.

Table 9. Transport mix in delivered messages (% of hops, HERMES routing, prototype).

Scenario	% Over HTTP	% Over BLE	% Over Bundle
S0 (no failure)	$76.1\pm 3.7$	$23.9\pm 3.7$	$0.0\pm 0.0$
S1 (relay crash)	$54.6\pm 2.8$	$45.4\pm 2.8$	$0.0\pm 0.0$
S2 (topology partition)	$77.2\pm 2.4$	$22.8\pm 2.4$	$0.0\pm 0.0$
S3 (Internet blackout)	$36.7\pm 4.0$	$53.0\pm 3.2$	$10.4\pm 1.0$

Figure 5 presents this adaptation over time as a stacked area chart. The S3 panel makes the adaptation visually clear: the HTTP region collapses at t = 30, BLE expands to take over, and a visible Bundle band appears for pairs that BLE alone cannot reach. This Bundle traffic accounts for 10.4% of hops reported in Table 9 and is concentrated entirely in the blackout window, since Bundle is essentially unused while HTTP is available.

Figure 5. Transport-mix adaptation over time on the prototype (HERMES, $N=5$). Failure injected at $t=30$ s (dashed lines).

6.5. Encryption Overhead

To quantify the cost of the end-to-end encryption layer, we ran S0 twice on the prototype: once with the Noise XX + ChaCha20-Poly1305 + Double Ratchet pipeline enabled, and once with it disabled. Table 10 reports the difference.

Table 10. Encryption overhead at S0, HERMES, medium load (prototype).

Metric	Encryption OFF	Encryption ON	Δ
Mean per-hop latency (ms)	$35.21\pm 3.31$	$35.38\pm 3.32$	$+0.17$
P95 latency (ms)	$166\pm 12$	$166\pm 12$	$+0.4$
CPU per message (μs)	5	100	$+95$
Ciphertext expansion (bytes)	0	28	$+28$

The latency impact of encryption is negligible (0.17 ms per hop, 0.4 ms at P95). The CPU cost increases from 5 to 100 μs per message—a 20× increase in relative terms but trivial in absolute terms on modern hardware. Ciphertext expansion is 28 bytes per message (16 bytes for the Poly1305 tag plus 12 bytes for the nonce), independent of payload size. End-to-end encryption is not a barrier to adoption; the design incurs a small constant cost per message and gains the security properties.

6.6. NS-3 Scale-Out: Delivery Ratio Versus Node Count

The prototype testbed has five nodes. To verify that the design scales, we extended the evaluation to N ranging from 5 to 500 nodes using the NS-3 simulator, as shown in Table 11.

Table 11. Delivery ratio (NS-3) versus node count, S0, medium density, BLE 150 m, TTL = 16.

N	HERMES	HTTP-Only	BLE-Only	Flooding
5	1.000 ± 0.000	0.415 ± 0.190	1.000 ± 0.000	1.000 ± 0.000
10	1.000 ± 0.000	0.558 ± 0.127	0.899 ± 0.190	1.000 ± 0.000
25	1.000 ± 0.000	0.528 ± 0.109	0.898 ± 0.150	1.000 ± 0.000
50	1.000 ± 0.000	0.504 ± 0.061	0.873 ± 0.112	1.000 ± 0.000
100	1.000 ± 0.000	0.493 ± 0.050	0.921 ± 0.079	0.990 ± 0.011
250	1.000 ± 0.000	0.490 ± 0.041	0.911 ± 0.077	0.994 ± 0.008
500	1.000 ± 0.000	0.494 ± 0.025	0.686 ± 0.080	0.999 ± 0.002

HERMES maintains perfect delivery (DR = 1.000) at every scale from N = 5 to N = 500. HTTP-only stabilizes at roughly 50%, independent of BLE range, because the HTTP overlay covers about half the random pairs by design (p_http = 0.7). BLE-only is competitive over this range—above 0.87 through N = 250—but falls to 0.686 at N = 500 as the contact graph fragments at the scale limit of the medium-density deployment. Flooding also delivers nearly perfectly (≥ 0.99) once the contact graph is connected. Figure 6 shows these curves.

Figure 6. Delivery ratio vs. scale (S0).

6.7. Failure Tolerance at Scale

Table 12 reports the delivery ratio at scale under the three failure scenarios. Figure 7 presents the same data in three panels.

Table 12. Delivery ratio (NS-3) under failure scenarios, medium density, BLE 150 m, TTL = 16.

Scenario/N	HERMES	HTTP-Only	BLE-Only	Flooding
S1, $N=25$	1.000 ± 0.000	0.512 ± 0.112	0.895 ± 0.153	1.000 ± 0.000
S1, $N=50$	1.000 ± 0.000	0.495 ± 0.062	0.870 ± 0.114	1.000 ± 0.000
S1, $N=100$	1.000 ± 0.000	0.489 ± 0.051	0.920 ± 0.079	0.990 ± 0.011
S2, $N=25$	1.000 ± 0.000	0.528 ± 0.109	0.898 ± 0.150	1.000 ± 0.000
S2, $N=50$	1.000 ± 0.000	0.504 ± 0.061	0.873 ± 0.112	1.000 ± 0.000
S2, $N=100$	1.000 ± 0.000	0.493 ± 0.050	0.921 ± 0.079	0.990 ± 0.011
S3, $N=25$	1.000 ± 0.000	0.226 ± 0.056	0.898 ± 0.150	0.942 ± 0.082
S3, $N=50$	1.000 ± 0.000	0.220 ± 0.027	0.873 ± 0.112	0.929 ± 0.064
S3, $N=100$	1.000 ± 0.000	0.206 ± 0.021	0.921 ± 0.079	0.948 ± 0.045

Figure 7. Failure tolerance at scale.

HERMES maintains perfect delivery (1.000) across all three failure scenarios at every tested N. HTTP-only falls to about 20% under S3, where the blackout disables its only transport, while > holding near 50% under S1 and S2—clearly demonstrating that a single IP-based transport is insufficient in the motivating scenario. BLE-only is essentially unaffected by failure type, at around 0.90 in every scenario, since none of S1–S3 alters the BLE contact graph; instead, it carries the N = 500 fragmentation seen in Table 11. Flooding stays high throughout (0.93–1.00), including under S3: at 150 m the mesh is dense enough that TTL = 7 flooding reaches most destinations without HTTP. As at scale, the separation under failure is a matter of cost rather than delivery—HERMES matches flooding’s delivery at a fraction of its bytes and energy.

6.8. Density Sensitivity

How HERMES’s transport mix changes with topology density provides direct empirical evidence that the cost function adapts to connectivity conditions. Table 13 shows the mix at N = 100 under S3 across three density regimes.

Table 13. Transport mix in delivered HERMES messages under S3 at $N=100$ (NS-3, BLE range 150 m, TTL = 16, $\alpha =10$, $\beta =1000$, 10 seeds). The delivery ratio is $1.000\pm 0.000$ in all three regimes.

Density	% HTTP	% BLE	% Bundle	Mean Hop Count
Sparse (BLE degree 3.3)	$42.5\pm 3.1$	$32.5\pm 7.7$	$25.0\pm 5.1$	$1.97\pm 0.20$
Medium (degree 6.6)	$25.4\pm 2.7$	$69.7\pm 4.6$	$4.9\pm 2.3$	$3.16\pm 0.28$
Dense (degree 15.9)	$26.3\pm 1.8$	$73.7\pm 1.8$	$0.0\pm 0.0$	$2.68\pm 0.11$

The Bundle share falls monotonically as density rises, from 25.0% in the sparse regime to 4.9% at medium density and to exactly zero in the dense regime, where none of the ten seeds used custodial forwarding at all. The BLE share moves in the opposite direction (32.5% → 69.7% → 73.7%): once the contact graph is connected, the mesh absorbs the blackout unaided and custodial storage stops being necessary. This is the structural reason why multi-transport routing is important: a single-transport design commits to one operating regime, whereas the cost function moves HERMES between regimes with no reconfiguration. Figure 8 illustrates the trend.

Figure 8. Transport mix vs. density under S3 (N = 100).

The residual HTTP share is not monotone (42.5%, 25.4%, 26.3%). Scenario S3 removes IP transport for 60 of the 90 measured seconds, and HERMES routes roughly three quarters of hops over HTTP whenever it is available (74.7% at medium density under S0), so a residual share near one quarter is what the failure schedule predicts; medium and dense density both sit there. The sparse regime lies well above this level because its blackout-period paths are the shortest of the three (1.97 hops against 3.16 at medium density): custodial transfer replaces multi-hop mesh forwarding, so the hops taken while IP connectivity is available account for a larger fraction of the total. The same effect makes the mean path length peak at medium rather than dense density, since connectivity must be good enough to sustain long mesh chains but not so good that paths collapse to two or three hops.

6.9. Cost-Function Parameter Sensitivity

The penalty values ($penalty\_BLE$ = 500 ms, $penalty\_Bundle$ = 5000 ms) were chosen heuristically. We swept $penalty\_BLE\in \{0,100,250,500,1000,2000\}$ ms against $penalty\_Bundle\in \{1000,2500,5000,10,000\}$ ms at $N=100$ under S3, five seeds per cell; Figure 9 reports the resulting grids. Delivery is invariant: every one of the 24 cells returns at least 0.9997.

Figure 9. DR sensitivity to cost-function penalties (S3, N = 100). Star: penalty values.

The penalties control transport selection and tail latency. The Bundle share of delivered hops spans 2.3% to 28.6% (Figure 9a) and P95 latency 3.6 s to 9.5 s (Figure 9b), while the median moves only between 0.24 s and 0.52 s. Both surfaces are monotone in the intended directions: raising $penalty\_BLE$ shifts traffic onto HTTP and Bundle, and raising $penalty\_Bundle$ pushes it back onto the mesh. The default sits at 4.7% Bundle usage and 5.7 s P95, matching the medium-density figures obtained independently in Table 13. The penalties are therefore a latency and storage choice, not a delivery one.

6.10. TTL Sizing

We empirically verify the choice by sweeping TTL across HERMES under S3 at N = 100, medium density. Only HERMES’s TTL was varied; baseline parameters remained unchanged, and the baseline measurements are byte-identical between the TTL = 4 and TTL = 16 runs. The results are shown below in Table 14.

Table 14. HERMES TTL sweep under S3 at $N=100$, medium density (NS-3, 10 seeds each).

TTL	DR	P95 Latency (ms)	Total Transmissions	Mean Hops
4	$0.776\pm 0.052$	6801	$1849\pm 168$	2.25
8	$0.994\pm 0.011$	5901	2208	3.12
16 (default)	$1.000\pm 0.000$	5885	2213	3.16
32	$1.000\pm 0.000$	5885	2213	3.16
64	$1.000\pm 0.000$	5885	2213	3.16

Three observations: First, the delivery ratio saturates at TTL ≥ 16; values from 16 to 64 are byte-identical. TTL = 16 is on the plateau, not at its edge. Second, the bandwidth cost of increasing TTL from 4 to 16 is modest (1849 to 2213 transmissions, a 20% increase). Third, P95 latency decreases as TTL increases, from 6.8 s at TTL = 4 to 5.9 s at TTL = 16. This is because higher TTL allows multi-hop BLE paths to complete instead of forcing the slower Bundle fallback. TTL = 16 improves delivery, lowers latency, and adds minimal bandwidth, making the choice principled rather than tuned.

6.11. Comparison Against Published DTN Routing Protocols

We implemented Epidemic, PRoPHET, Spray-and-Wait, and MaxProp in the NS-3 simulator using their published parameter values, under identical conditions: N = 100, medium density, BLE range 150 m, S0 and S3 scenarios, and 10 seeds. Table 15 presents delivery ratio and bandwidth side by side.

Table 15. HERMES vs. published DTN protocols, NS-3, $N=100$, medium, BLE 150 m, 10 seeds.

Scenario	Protocol	Delivery Ratio	Total tx	Tx per Delivery
S0	HERMES (TTL = 16)	$1.000\pm 0.000$	$1702\pm 75$	≈$2.5$
S0	Epidemic	$0.924\pm 0.079$	79,877 ± 6808	≈128
S0	PRoPHET	$0.825\pm 0.125$	55,613 ± 9678	≈100
S0	Spray-and-Wait	$0.190\pm 0.019$	$5790\pm 256$	≈45
S3	HERMES (TTL = 16)	$1.000\pm 0.000$	$2213\pm 260$	≈$3.3$
S3	Epidemic	$0.924\pm 0.083$	79,877 ± 7176	≈128
S3	PRoPHET	$0.825\pm 0.131$	55,613 ± 10,201	≈100
S3	Spray-and-Wait	$0.190\pm 0.020$	$5790\pm 270$	≈45

HERMES delivers all messages in both scenarios. Epidemic delivers 92%, PRoPHET 83%, and Spray-and-Wait 19%. HERMES uses 1700–2200 total transmissions, while Epidemic uses 79,877. Measured in transmissions, Epidemic uses 47× HERMES’s S0 count and PRoPHETuses 33×; the byte-level accounting below gives the corresponding figures in bytes. Spray-and-Wait’s L=10 copy budget is too small for this network size.

This comparison reframes HERMES’s contribution. Compared to standard DTN protocols, HERMES is not just better than naive baselines; it achieves the same or higher delivery ratio while transmitting 21–35× fewer bytes than flooding-based approaches. This bandwidth efficiency is important in any setting where capacity is constrained—such as BLE radios, cellular fallback during partial shutdowns, or battery-limited devices. Figure 10 plots delivery ratio against transmissions on a logarithmic scale.

Figure 10. DR vs. bandwidth by routing protocol (medium, BLE 150 m).

The submitted bandwidth figure counted transmissions. Because a 28-byte ACK and a 281-byte data packet each counted as one, we rebuilt the accounting at the byte level, decomposing every transmission into payload, cryptographic expansion (AEAD tag and nonce), routing header, control traffic (HERMES probe/gossip and the DTN summary-vector exchange), ACKs, and retransmissions—for all protocols, under identical conditions. Table 16 reports the result. The headline survives at the byte level: Epidemic transmits 35× HERMES’s total bytes with control traffic included and 40× with it excluded, and the four baselines span 27–40× with control traffic excluded, and HERMES delivers each message at ≈9.2 KB versus Epidemic’s ≈ 351 KB. We report both control-inclusive and control-exclusive ratios because HERMES’s own gossip anti-entropy is a large share (≈88–91%) of its (small) byte budget; Epidemic’s summary vectors are proportionally just as heavy, so the ratio is robust either way. MaxProp matches Epidemic’s delivery ratio (0.924) with about 60% of its bytes via delivered-ACK deletion, but still transmits approximately 21× HERMES’s bytes. It sits between HERMES and Epidemic on the delivery/bandwidth scatter, and therefore reinforces the bandwidth claim.

Table 16. Byte-level bandwidth decomposition (S0, $N=100$, medium; mean over 10 seeds).

Protocol	DR	Payload (B)	Crypto + Hdr (B)	Control (B)	Total (B)	Bytes/Deliv.
HERMES	1.000	340,060	137,724	5,857,008	6,424,908 1	9186
Epidemic	0.924	15,975,420	6,470,045	203,501,356	225,946,821	349,492
PRoPHET	0.825	11,122,680	4,504,685	160,055,572	175,682,937	303,111
MaxProp	0.924	—	—	—	134,430,588	209,484

¹ HERMES’s total additionally includes 90,116 B of per-hop acknowledgement traffic (1,733 acknowledgements of 52 B: a 28 B acknowledgement in a 24 B routing header), not itemised above; the control-exclusive base is therefore 567,900 B. Epidemic and PRoPHET send no per-hop acknowledgement, so their columns sum to their totals.

6.12. Tail Latency at Scale

Table 17 shows the S3 latency tail for TTL = 16. We report HERMES at N = 25, 50, 100, 250, and 500 under S3 with medium density.

Table 17. HERMES tail latency under S3 versus scale (NS-3, medium density, BLE 150 m, TTL = 16, $\alpha =10$, $\beta =1000$, 10 seeds). The delivery ratio is $1.000\pm 0.000$ at every N.

N	P50 (ms)	P95 (ms)	P99 (ms)
25	$153\pm 12$	$2385\pm 2960$	$4726\pm 5362$
50	$198\pm 20$	$4432\pm 1888$	$9314\pm 1867$
100	$253\pm 28$	$5885\pm 1441$	10,443 ± 1234
250	$411\pm 60$	$8270\pm 524$	12,236 ± 547
500	$571\pm 125$	$8926\pm 407$	13,213 ± 626

Tail latency under S3 increases with scale rather than remaining flat: the median rises from 0.15 s at $N=25$ to 0.57 s at $N=500$, the 95th percentile from 2.4 s to 8.9 s, and the 99th percentile from 4.7 s to 13.2 s. The growth is markedly sub-linear– a twentyfold increase in network size costs a factor of 3.7 at P50 and P95 and 2.8 at P99. The driver is custodial buffering rather than path length: the Bundle share of delivered hops rises from 3.0% at $N=25$ to 16.4% at $N=500$, while the mean path length is essentially unchanged (2.27 to 2.60 hops) and the TTL bound is never reached, the longest observed path being 11 hops against the limit of 16. Larger networks place a growing fraction of traffic in custody during the blackout window, and each custodial hop contributes the Bundle transport’s lognormal delivery delay.

The dispersion at $N=25$ deserves comment, since the standard deviation of P95 there exceeds its mean. The distribution is bimodal across seeds: five of the ten seeds route no traffic at all through the Bundle layer and reach P95 values between 0.39 s and 0.63 s, whereas the three seeds with 6–13% Bundle usage sit between 5.9 s and 7.7 s. The effect disappears by $N=250$, where every seed carries custodial traffic. Figure 11 shows these percentiles. As an internal consistency check, the $N=100$ P95 of 5885 ms is the same quantity as the TTL = 16 row of Table 14, obtained from an independent sweep at the same configuration. Delivery remains 1.000 at every scale tested (Table 11), so what scale costs HERMES under blackout is delay rather than reliability, and it costs delay sub-linearly.

Figure 11. HERMES tail latency vs. scale (S3, TTL = 16).

6.13. Mobility

This section evaluates HERMES under node mobility. Nodes follow a random waypoint mobility model, with speed drawn uniformly from the configured range and pause time exponentially distributed with a mean of 30 s. BLE link availability is re-evaluated every 100 ms based on the geometric distance and range threshold. The results are shown below in Table 18.

Table 18. Delivery ratio under mobility (NS-3, $N=100$, medium, BLE 150 m, TTL = 16, $\alpha =10$).

Mobility, Scenario	HERMES	Epidemic	PRoPHET
static, S0	1.000 ± 0.000	0.924 ± 0.079	0.825 ± 0.125
1.5 m/s, S0	0.993 ± 0.005	0.990 ± 0.011	0.988 ± 0.013
5 m/s, S0	0.956 ± 0.011	0.997 ± 0.003	0.995 ± 0.004
static, S3	1.000 ± 0.000	0.924 ± 0.079	0.825 ± 0.125
1.5 m/s, S3	0.935 ± 0.031	0.990 ± 0.011	0.988 ± 0.013
5 m/s, S3	0.780 ± 0.050	0.997 ± 0.003	0.995 ± 0.004

Under static conditions, HERMES delivers all messages, exceeding Epidemic and PRoPHET (0.924 and 0.825) under both S0 and S3, representing the clearest delivery advantage in the mobility study. At walking pace (1.5 m/s, the realistic civilian scenario), HERMES matches the baselines without failure (0.993 versus 0.990) and trails modestly under blackout (0.935 versus 0.990). At vehicular speed (5 m/s) under blackout, the contact-flooding baselines perform better (0.997 and 0.995 versus HERMES’s 0.780). This regime favors protocols whose delivery probability increases with the rate of node-to-node contacts.

We tested the proposed mechanism directly rather than asserting it. Sweeping the probe interval over 1, 2, 5, and 10 s at 5 m/s under blackout leaves the delivery ratio flat at 0.780 (Figure 12): faster probing does not recover the corner because BLE reachability is already re-evaluated every 100 ms independently of the probe interval. The submitted attribution to topology-view staleness, purportedly curable by faster probing, is therefore not supported. The effective lever is the cost weight $\alpha$: raising $\alpha$ from the default 10 to 20 lifts the 5 m/s delivery ratio from 0.780 to 0.876 and the 1.5 m/s ratio from 0.935 to 0.968 (Figure 3). We accordingly do not add an adaptive-probe scheme and instead characterize the applicable operating envelope. The speed at which HERMES stops leading on delivery depends on density: $\mathsf{\Delta }DR$ changes sign between 3 and 5 m/s in sparse deployments, but between 0.5 and 1.5 m/s at medium and dense densities. Its byte cost per delivered message remains 37–59× lower than Epidemic’s at every tested speed.

Figure 12. Probe-interval sweep at 5 m/s S3 (alpha = 10).

We note that the 5 m/s regime lies outside the primary motivating scenario, since civilians during connectivity disruption move at pedestrian rather than vehicular speeds. The pedestrian case is not a clear win either: at 1.5 m/s under blackout, HERMES trails by 0.06 (0.935 versus 0.990), compared with a gap of 0.22 at 5 m/s. The deficit therefore narrows continuously as speed falls rather than vanishing below a vehicular threshold, and topology-update strategies for high-churn regimes remain future work. Figure 13 shows the curves.

Figure 13. Delivery ratio under mobility (N = 100, medium, BLE 150 m).

6.14. Adversarial Resilience

This section evaluates HERMES under a simple adversarial model, shown in Table 19. A configurable fraction K of nodes is designated as adversarial; an adversarial node silently drops every message it receives instead of forwarding it. This models a coordinated drop attack by compromised relays. The defense in HERMES is passive: adversarial relays cannot acknowledge, so the risk term in the cost function increases the cost of edges through them, and Dijkstra’s algorithm routes around them. The defense does not require cryptographic detection.

Table 19. Delivery ratio versus % adversarial relays (NS-3, S0, $N=100$, medium, BLE 150 m). Adversarial relays silently drop all traffic they receive.

% Adversarial K	HERMES	Epidemic	PRoPHET
0	1.000 ± 0.000	0.924 ± 0.079	0.825 ± 0.125
5	0.991 ± 0.004	0.831 ± 0.110	0.731 ± 0.143
10	0.979 ± 0.008	0.785 ± 0.106	0.615 ± 0.154
20	0.958 ± 0.011	0.636 ± 0.149	0.470 ± 0.174
30	0.930 ± 0.018	0.408 ± 0.160	0.287 ± 0.119
50	0.813 ± 0.039	0.171 ± 0.080	0.124 ± 0.049

HERMES degrades gracefully: even with 50% of relays adversarial, it still delivers 81% of messages. Epidemic and PRoPHET collapse rapidly—at 30% adversarial relays they deliver 41% and 29% of messages, respectively, and at 50% they fall to 17% and 12%. Thus, at the highest attack intensity, HERMES delivers roughly 4.8× more messages than the best flooding baseline. The mechanism is straightforward. Epidemic relies on every relay holding and rebroadcasting messages, so each adversarial relay destroys every copy that passes through it. HERMES routes selectively, so an adversarial relay loses messages routed through it only once, after which the risk term steers traffic elsewhere.

Figure 14 shows these curves. This is the single clearest separation in the evaluation. HERMES does not detect adversaries cryptographically—the defense is passive, driven by ACK timeouts—but the routing effect alone is enough to outperform contact-flooding by a wide margin.

Figure 14. Resilience to adversarial relays (S0, HERMES failure weight $\beta$ = 1000).

6.14.1. ACK-and-Drop Adversary

A relay that acknowledges the previous hop and then discards the payload is strictly more powerful than a silent dropper: the ACK keeps the edge’s $failure\_rate$ at zero, so the passive risk term never fires and Dijkstra keeps sending it traffic. This is the boundary of passive defense. At 30% adversarial relays under S0, ACK-and-drop reduces HERMES’s delivery ratio to 0.637, compared with 0.930 for silent dropping at the same fraction; under S3 the corresponding values are 0.563 and 0.983. The gap is structural rather than a matter of tuning: the ACK-and-drop curve is invariant to $\beta$, because a forged acknowledgement holds $failure\_rate$ at zero and the risk term—which $\beta$ scales—never engages. The passive risk term defends against relays that fail to acknowledge, but it cannot defend against relays that acknowledge falsely, because a per-hop ACK carries no proof of onward delivery (Figure 15).

Figure 15. Silent-drop versus ACK-and-drop adversaries: delivery ratio against adversarial fraction K. (Left): S0. (Right): S3.

6.14.2. Topology Poisoning

A compromised node can inject false low-RTT link-state records to attract traffic (a black hole), a vulnerability that the “Adversary Model” section acknowledges the system cannot cryptographically detect. Injecting false 1 ms edges is more damaging than silently dropping traffic because it attracts traffic rather than waiting for it: even at 5% adversarial nodes, the black hole crushes delivery to ≈0.37 (versus ≈ 0.99 for silent dropping at the same fraction), and the mean hop count decreases as traffic is pulled onto the false edges (Figure 16). This attack is likewise insensitive to $\beta$: the falsely advertised low-RTT edges dominate the cost function, so the failure term cannot compensate.

Figure 16. Topology poisoning: routing distortion (false edges, forwarding) and black hole (false edges with dropping). Honest-endpoint delivery ratio against adversarial fraction K—messages whose source or destination is adversarial are excluded (NS-3, $N=100$, medium density, BLE 150 m, $\alpha =10$, $\beta =1000$). (Left): S0. (Right): S3.

Figure 16 reports honest-endpoint delivery, excluding messages whose source or destination is adversarial, so the curves are not inflated by traffic the adversary legitimately receives. On this basis, the dropping variant degrades monotonically under S0, reaching 0.245 at K = 30%. The remaining curves recover above K = 5%, which is therefore the worst measured case and the value quoted here. A full account of the non-monotonicity—particularly why the dropping variant recovers under blackout but not under S0—requires a traffic-attraction analysis that we leave to future work.

6.14.3. Long-Duration Attack and Cross-Message Learning

Because the risk term’s $failure\_rate$ is estimated from the outcomes of recent transmissions on each edge, routing decisions improve across successive messages instead of only through retries of a single message. Grouping messages into 60 s origination cohorts, the fraction of each cohort ever delivered rises over a 10-min sustained 30% attack. Under silent dropping, the cohort delivery ratio rises from 0.928 to 0.981 under S0 and from 0.987 to 1.000 under S3, as traffic is rerouted around malicious nodes. Under an ACK-and-drop attack (Figure 17), learning is slower because acknowledgements conceal the forwarding failures: the cohort ratio rises from 0.643 to 0.860 under S0 and from 0.597 to 0.976 under S3. In both cases, the observed delivery exceeds the naive per-attempt prediction

$$P_{\mathrm{clean}}={(1-K)}^h$$

(3)

even with bounded retries, demonstrating the benefit of cross-message learning.

Figure 17. Cohort delivery ratio versus message origination time under a sustained 30% attack (NS-3, $N=100$, medium, BLE 150 m, $\alpha =10$, $\beta =1000$; 60 s origination cohorts over a 10-min run, mean over 3 seeds). (Left): S0. (Right): S3.

6.15. Coordinator Failure: Duration × Mobility

The TopologyService represents a partial single point of failure, and its impact is evaluated explicitly. In these experiments, the coordinator is taken offline at $t=30$ s for controlled outage durations of 60, 300, 900 s, or permanently, while node mobility is varied (static, 1.5 m/s, and 5 m/s) under both pruning strategies. Simulation time is extended to ensure that the longest outage is fully observed. The evaluation measures delivery ratio, P95 end-to-end latency, bundle-store occupancy, and the average believed-graph size per node. Throughout the experiment, the communication transports remain operational; the coordinator outage affects only topology knowledge, not network connectivity.

The cached-topology fallback effectively limits the impact of coordinator failure. Under static conditions, both pruning strategies maintain a delivery ratio of 1.000 regardless of outage duration, indicating that coordinator failure is benign when the topology is unchanged. Under mobility, however, the two pruning strategies exhibit different trade-offs. With local pruning, each node’s believed graph collapses roughly 60 s after coordinator failure—from the full gossip-learned topology to about seven edges—converging on the one-hop neighborhood. Despite this reduction, DTN bundle custody preserves delivery, achieving a delivery ratio of 0.997 at 5 m/s during a permanent outage, at the cost of approximately 11 s P95 latency and bundle forwarding for nearly 80% of messages. In contrast, central pruning retains the last synchronized topology; as nodes continue to move, routing decisions increasingly rely on stale links, reducing delivery to 0.907 at 5 m/s while maintaining substantially lower latency. In both cases, the system degrades gracefully rather than failing completely. The original short-duration experiment was unable to capture this behavior because the 60 s outage matched the topology staleness threshold; it has therefore been replaced with the more comprehensive parameter sweep described above. Figure 18 shows the delivery ratio and believed graph size over time under local pruning.

Figure 18. Coordinator failure under local pruning (NS-3, $N=100$, medium, BLE 150 m). (Top): delivery ratio per 30 s bucket; (Bottom): mean believed-graph size. Coordinator offline at $t=30$ s.

6.16. Speed × Density Operating Envelope

To characterize the operating envelope, we evaluate node speeds of $\{0,0.5,1.5,3,5,10\}$ m/s across sparse, medium, and dense network deployments under communication blackout, comparing HERMES with Epidemic and PRoPHET routing. Performance is summarized as

$$\mathsf{\Delta }DR=DR\left(\mathrm{HERMES}\right)-max\left(DR\left(\mathrm{Epidemic}\right),DR\left(\mathrm{PRoPHET}\right)\right),$$

where positive values indicate superior delivery by HERMES. HERMES consistently outperforms the flooding-based protocols at low mobility, particularly in sparse networks where intermittent connectivity fragments the contact graph and the multi-transport custody mechanism remains effective, achieving $\mathsf{\Delta }DR=+0.73$ under static sparse conditions. As mobility increases, the advantage decreases, and the crossover speed itself depends on density: $\mathsf{\Delta }DR$ changes sign between 3 and 5 m/s in sparse deployments, but already between 0.5 and 1.5 m/s at medium density, while dense deployments are marginally negative from 0.5 m/s onward. HERMES falls furthest behind at high speed in dense networks ($\mathsf{\Delta }DR=-0.37$ at 10 m/s). Delivery performance, however, represents only part of the comparison. At medium density, HERMES requires 8–9 KB per delivered message, compared with 350–511 KB for Epidemic, a ratio that widens with mobility from 37× at rest to 59× at 10 m/s. Consequently, even in scenarios where flooding-based protocols achieve higher delivery ratios—above roughly 4 m/s in sparse deployments and above 1 m/s in medium and dense deployments—they do so with between 37 and 59 times the communication overhead (Figure 19). Overall, HERMES is preferable in low-mobility environments—below roughly 3 m/s in sparse deployments and below approximately 1 m/s in medium and dense deployments—and remains consistently superior at every tested speed when evaluated in terms of bandwidth consumed per successfully delivered message.

Figure 19. Speed–density operating envelope under blackout (NS-3, $N=100$, S3, BLE 150 m, $\alpha =10$, HERMES failure weight $\beta =4000$, 10 seeds). (a) $\mathsf{\Delta }DR$ against HERMES’s best DTN baseline; leftmost column is static, dashed line is $\mathsf{\Delta }DR=0$. (b) Bytes per delivered message, medium density, log scale.

6.17. Channel Realism: Per-Link Loss and Offered Load

The submitted BLE channel is a range-based, point-to-point channel without contention. We add a loss-and-queuing abstraction—a per-link Bernoulli loss process and a finite per-node transmit service rate with a bounded queue—applied identically to HERMES and the three flooding-family baselines and conservative with respect to HERMES, which carries the least traffic. We label this explicitly as a loss-and-queuing model, not a full interference model (Figure 20). Two findings follow. First, HERMES’s per-hop reliability masks per-link loss: its delivery ratio remains at approximately 1.000 up to 30% loss (due to retry and reroute), whereas Epidemic falls to 0.796 and PRoPHET to 0.606. Second, and more importantly, under a finite service rate the bandwidth advantage becomes a delivery advantage: as offered load rises, Epidemic’s delivery ratio collapses from 0.92 to 0.30 at 100 msg/s as its flooding volume overflows the queue, while HERMES remains flat at 1.000. Flooding’s transmission volume, harmless in an uncontended channel, becomes delivery failure under contention.

Figure 20. (a): delivery ratio vs. per-link loss. (b): delivery ratio vs. offered load at a finite service rate (blackout).

6.18. Energy per Delivered Message

The penalty values are justified by energy and storage arguments that the submission never quantified (Figure 21). We estimate per-transport energy per delivered message by combining the byte decomposition with the transport mix and published per-transport energy figures (BLE Coded-PHY current draw for an nRF52840-class radio; Wi-Fi/cellular per-bit plus connection-setup energy for HTTP; storage energy for Bundle), and apply them to the delivered-message traces of HERMES and the three flooding-family baselines. These are order-of-magnitude estimates, with the HTTP term explicitly labeled as unmeasured pending the hardware campaign in the future work section. On this basis, flooding is even more expensive relative to HERMES in energy than in bandwidth: Epidemic spends approximately 52× the energy per delivered message that HERMES does at S0, because every redundant transmission is a radio activation.

Figure 21. Estimated energy per delivered message by protocol (log scale, S0).

7. Limitations and Future Work

HERMES represents one design point within a broader landscape of civilian-resilient communication systems, rather than a definitive solution. The evaluation demonstrates that metric-driven multi-transport routing achieves delivery ratios equal to or higher than those of flooding-based DTN protocols in static and failure scenarios while transmitting approximately 35× fewer bytes—and about 21× fewer even against the more bandwidth-efficient MaxProp baseline. Additionally, the passive risk term offers unexpectedly strong adversarial robustness—delivering up to 4.8× times more messages than contact flooding under coordinated drop attacks—without any explicit security mechanism.

HERMES does not dominate delivery in all scenarios: at vehicular-speed mobility (5 m/s), contact flooding performs better, and at walking pace under blackout HERMES trails the baselines by approximately 0.06 (0.935 versus 0.990). We quantitatively characterize this boundary with the speed–density envelope and show that the cause is not probe-refresh staleness—faster probing does not help, leaving delivery flat at 0.780—but contact dynamics at high churn; the cost weight $\alpha$ is the effective mitigation, raising delivery to 0.876 at $\alpha$ = 20. The coordinator single point of failure is now measured and found less severe than a total outage; a decentralized replacement—a last-writer-wins map of edge records keyed by ($n\_i$, $n\_j$, transport) on $t\_last$, with staleness applied as a read-time predicate rather than an explicit remove—is the immediate next step. The passive adversarial defense has a measured boundary: it does not stop relays that acknowledge falsely (ACK-and-drop) or that poison topology, and this boundary is structural rather than a matter of tuning, since a forged acknowledgement holds $failure\_rate$ at zero regardless of the failure weight $\beta$. Both motivate signed end-to-end ACKs and signed link-state records. Remaining next steps include full RFC 9171 (BPv7) compliance, a Tamarin/ProVerif proof of the cross-transport ratchet composition, and an nRF52840-class hardware calibration campaign—the correct platform, since smartphones expose 1M-PHY rather than the 150 m Coded-PHY under study—with the published-measurement calibration and loss/contention sensitivity standing in until it is complete.

Beyond these, the most actionable next steps are mobility-adaptive tuning of the staleness weight $\alpha$, and authenticated relay reputation that combines the passive risk term with signed acknowledgements.

8. Conclusions

In this paper, we present HERMES, a hybrid multi-transport architecture that treats HTTP over IP, Bluetooth Low Energy mesh, and delay-tolerant bundle transport as parallel labeled edges in a single routing graph, selecting among them per hop using a cost function based on RTT, transport preference, and observed link risk. The architecture is implemented as four microservices in C# on .NET 9, with end-to-end authenticated encryption using a transport-agnostic Noise XX handshake and a Double Ratchet that advances per message, regardless of which transport carried it.

The experimental evaluation, conducted in two complementary parts—a five-node prototype testbed and an NS-3 simulator at scales up to 500 nodes—demonstrates that the design functions as intended. HERMES achieves perfect or near-perfect delivery in every scenario tested. Compared with published DTN routing protocols (Epidemic, PRoPHET, Spray-and-Wait, and MaxProp) at $N=100$, HERMES delivers at least as well while transmitting 21–35× fewer bytes. Under coordinated adversarial drop attacks, HERMES degrades gracefully, whereas flooding-based DTN baselines collapse. End-to-end encryption adds negligible overhead. Topology adaptation is automatic: on the five-node testbed, the transport mix shifts from 76% HTTP under normal conditions to 53% BLE and 10% Bundle during an Internet blackout, with no manual reconfiguration.

Under vehicular-speed mobility combined with an Internet blackout, contact-flooding outperforms HERMES because high churn outpaces the topology update rate. The Bluetooth Low Energy transport is emulated rather than measured on real hardware.