Adaptive Execution Timing for Offline First Quorum Coordination in LoRa Mesh Networks

1. Introduction

When disasters, infrastructure outages, or remote deployments remove reliable backhaul, nodes must still coordinate decisions despite intermittent links, constrained airtime, and volatile participation. These constraints are acute in LoRa-based deployments, where long transmission times and variable spreading factors make coordination completion highly sensitive to how slot spacing and round deadlines are timed. Central schedulers are frequently unavailable in offline-first field settings, so timing control must emerge from local interaction among constrained nodes.

Quorum-based coordination provides a lightweight agreement mechanism that tolerates limited participation loss without heavyweight consensus infrastructure. In this paper, a vote denotes one bounded coordination round keyed by a unique identifier: nodes transmit on scheduled LoRa slots until either a quorum threshold or a full-participation rule is satisfied, after which local state is cleared. Many deployments still fix slot spacing and deadlines offline [1,2]. When links improve, fixed timing wastes latency margin; when airtime or participation worsens, the same schedules become brittle. LoRa optimisation has focused mainly on PHY/MAC efficiency (spreading-factor adaptation, collision reduction, energy-aware scheduling) [3,4,5,6], with far less attention to continuous retuning of coordination execution timing from live airtime.

This paper designs, implements, and evaluates an adaptive execution-timing framework for quorum-based coordination on constrained LoRa mesh nodes. Rather than treating timing as a fixed deployment parameter, each node runs a local Monitor–Analyse–Plan–Execute–Knowledge (MAPE-K) loop that derives slot spacing $S\left(c\right)$ and round deadlines $D\left(c\right)$ from LoRa time-on-air estimates, guard margins, and observed participation. Figure 1 summarises the four-node LoRa mesh, the opportunistic Wi-Fi/UDP gateway path, and the embedded MAPE-K loop on each node. The design is motivated by the Emergency Buddy System (EBS), where low-bitrate voice, lightweight ledger anchoring, and mesh coordination share the same airtime budget [7,8,9]. Prior EBS work addressed voice transport and gateway integration; this paper addresses the separate execution-timing problem that arises when verification and agreement must remain bounded under changing airtime.

The novelty is not a new consensus algorithm, new quorum theory, or a new MAPE-K architecture in the abstract. MAPE-K, adaptive radio scheduling, and quorum finalisation are established building blocks [10,11,12]. The contribution is closing the control loop from measured LoRa time-on-air into per-round coordination variables $S\left(c\right)$, $D\left(c\right)$, and dual-mode (quorum versus full-participation) finalisation on resource-constrained mesh nodes, with bounded queueing and a single retry so cleanup remains deterministic. Existing approaches typically adapt PHY parameters for delivery, membership, or epoch-level timeouts independently; they do not continuously expose PHY airtime as the runtime control signal for scheduled quorum execution.

We implemented the framework on a four-node SX1276 LoRa mesh and evaluated 2,514 coordination rounds under crash and omission faults with honest firmware. The results characterise latency, mode mix, and recovery on that testbed.

Our contributions are as follows.

a)

A runtime execution-timing framework that maps measured LoRa airtime ($\mathrm{ToA}\left(c\right)$) into coordination scheduling variables $S\left(c\right)$ and $D\left(c\right)$ under constrained bandwidth.

b)

An embedded node-local MAPE-K loop that updates $S\left(c\right)$, $D\left(c\right)$, and finalisation policy from observed airtime and participation without adding coordination messages or changing agreement semantics.

c)

A bounded recovery architecture with a single active coordination instance, FIFO queue capacity $K=10$, and at most one retry per round.

d)

Firmware implementation and laboratory validation on a four-node LoRa mesh across 2,514 rounds under crash and omission faults with honest firmware.

The remainder of the paper is organised as follows. Section 2 reviews related work. Section 3 defines the system model and timing framework. Section 4 presents the algorithms. Section 5 analyses complexity and overhead. Section 6 and Section 7 describe the experimental setup and results. Section 8 discusses implications, and Section 9 outlines scalability and deployment considerations.

2. Background and Related Work

Autonomic computing and delay-tolerant networking (DTN) motivate embedded adaptation when operators are absent and connectivity is fragmentary [10,13,14,15], yet many autonomic deployments still assume edge–gateway paths absent in disconnected meshes.

Table 1 contrasts representative families. Inclusion criteria are: (i) relevance to intermittent or austere connectivity; (ii) support (or explicit absence) of distributed agreement under partitions; (iii) device class compatible with constrained radios. The Evidence column uses a uniform scale: conceptual, simulation, laboratory, or field. DTN stacks emphasise store-and-forward delivery but rarely add a coordination layer for committed votes. IoT consensus treatments often keep phase timing fixed. Adaptive-consensus work typically varies who votes, when views change, or epoch-level timeouts [11,16,17,18], rather than per-round slot spacing from PHY airtime.

Quorum intersection and flexible voting sets are well studied in the Paxos family [12]. WAN-facing consensus separates site-local progress from wide-area latency [19]. Partial-synchrony models motivate configured timeouts relative to unknown but bounded delay [20]. The timing contribution here is orthogonal: fixed-threshold finalisation with continuous retuning of $S\left(c\right)$ and $D\left(c\right)$ from measured LoRa time-on-air.

Table 1. Comparative landscape for intermittent coordination. Inclusion: works addressing austere connectivity, agreement under partitions, and/or constrained radios. Evidence scale: conceptual / simulation / laboratory / field.

Family	Representative works	Connectivity	Device budget	Timing / coordination focus	Evidence
Autonomic NSM	IBM MAPE-K [10]; ETSI GANA [21]	Mostly continuous edge–gateway	Edge/gateway	Policy loops; no LoRa airtime control	Conceptual
DTN protocols	RFC 4838 [14]; DTNRG	Partition-tolerant forwarding	Edge nodes	Delivery only; no vote coordination	Field (delivery)
LoRa PHY/MAC adaptation	Surveys [4,22]; SF/power control [5,23]; duty-cycled SF adaptation [24]; cross-layer reviews [6,25]	Sparse star/mesh	MCU/LoRa	Delivery, energy, collisions; not quorum deadlines	Simulation / laboratory
Blockchain emergencies	Bibliometric survey [26]	Online-first backbone	Mixed	Integrity; limited in-mesh timing	Conceptual
Consensus in IoT	PBFT [11]; Tendermint [16]; HotStuff [17]; surveys [27,28]	Semi-synchronous clusters	SBC/MCU	Epoch/view timeouts; not per-slot ToA	Simulation / laboratory
This work	MAPE-K timing + scheduled quorum	Lab mesh; USB-logged	MCU/LoRa	Per-round $S\left(c\right)$, $D\left(c\right)$ from ToA; dual-mode finalisation	Laboratory ($n=4$)

Table 1. Comparative landscape for intermittent coordination. Inclusion: works addressing austere connectivity, agreement under partitions, and/or constrained radios. Evidence scale: conceptual / simulation / laboratory / field.

Family	Representative works	Connectivity	Device budget	Timing / coordination focus	Evidence
Autonomic NSM	IBM MAPE-K [10]; ETSI GANA [21]	Mostly continuous edge–gateway	Edge/gateway	Policy loops; no LoRa airtime control	Conceptual
DTN protocols	RFC 4838 [14]; DTNRG	Partition-tolerant forwarding	Edge nodes	Delivery only; no vote coordination	Field (delivery)
LoRa PHY/MAC adaptation	Surveys [4,22]; SF/power control [5,23]; duty-cycled SF adaptation [24]; cross-layer reviews [6,25]	Sparse star/mesh	MCU/LoRa	Delivery, energy, collisions; not quorum deadlines	Simulation / laboratory
Blockchain emergencies	Bibliometric survey [26]	Online-first backbone	Mixed	Integrity; limited in-mesh timing	Conceptual
Consensus in IoT	PBFT [11]; Tendermint [16]; HotStuff [17]; surveys [27,28]	Semi-synchronous clusters	SBC/MCU	Epoch/view timeouts; not per-slot ToA	Simulation / laboratory
This work	MAPE-K timing + scheduled quorum	Lab mesh; USB-logged	MCU/LoRa	Per-round $S\left(c\right)$, $D\left(c\right)$ from ToA; dual-mode finalisation	Laboratory ($n=4$)

Recent LoRa work adapts spreading factor, power, and duty-cycle policy to improve throughput, coverage, or latency under imperfect SF orthogonality [5,23,24,25]. Cross-layer and fine-grained scheduling schemes (e.g., FREE) target reliable energy-efficient collection in LoRaWAN-like settings [6]. These results are complementary: they optimise delivery airtime and collisions, whereas this paper maps the resulting airtime into coordination slot spacing and deadlines for scheduled quorum rounds. We do not claim a head-to-head reimplementation of those stacks on our testbed; positioning is by control objective and assumptions (Table 1).

State-machine replication typically relies on view-based rounds and configured timeouts [11,16,17,19,20,27,28]. LoRa/LPWAN research studies scalability and duty-cycle limits but usually targets delivery rather than agreement on committed decisions [4,22,29,30,31]. DTN architectures deliver under partitions without mesh-level vote finalisation [14,15,32].

The gap addressed here is continuous per-round PHY-driven timing adaptation for scheduled quorum coordination: a node-level MAPE-K loop treats $\mathrm{ToA}\left(c\right)$ as a control variable and drives $S\left(c\right)$, $D\left(c\right)$, and finalisation mode online while a vote engine enforces bounded recovery. This paper does not introduce new agreement theory [12]. Evaluation uses a deployed laboratory prototype rather than simulation-only scalability claims (Section 6Section 7).

Prior EBS publications established low-bitrate voice over LoRa and satellite–LoRa emergency infrastructure [7,8,9]. Offline-first Byzantine-fault-tolerant agreement with token-gated security in the same low-bitrate mesh setting is treated in [33]; that layer does not retune per-round $S\left(c\right)$ and $D\left(c\right)$ from measured airtime, nor provide the bounded vote engine with dual-mode finalisation under crash and omission faults evaluated here. The present work is that scheduling and timing layer.

3. System Model

We model a low-power mesh in which each vote is one time-bounded coordination instance with explicit start, deadline, and cleanup so that intermittent links cannot grow unbounded local state. The following subsections fix topology, timing, and fault assumptions used later in the algorithms and evaluation.

3.1. Network, Timing, and Fault Management

Table 2 summarises notation. The architecture in Figure 1 is used throughout: an embedded management loop on each node and an opportunistic Wi-Fi/UDP path to a gateway, with the LoRa radio layer represented abstractly rather than as a geographic map.

Nodes are resource-constrained devices with a single application processor that may also serve best-effort gateway traffic; mesh timing is therefore modelled without assuming a dedicated quiet host. The graph, clock, and loss model below capture the quantities the adaptive scheduler uses. Latency, loss, and contention on each link vary with environment and duty cycle.

Let $G=(N,E)$ be a directed graph where each node $i\in N$ has a LoRa interface and each link $(i,j)\in E$ has delay ${\delta }_{ij}\left(t\right)$ and loss probability $p_{ij}\left(t\right)$ [3]. Nodes are half-duplex, use fixed transmit power $P_t$, and choose physical parameters $c=\langle BW,SF,CR\rangle$ (bandwidth, spreading factor, coding rate) [4,34].

Each node keeps a local clock. The timing model treats misalignment relative to a reference schedule as bounded by the configured parameter ${\Delta }_{\mathrm{clk}}$ [35]. LoRa time-on-air $\mathrm{ToA}\left(c\right)$ dominates packet duration; queueing and propagation add smaller but non-negligible jitter under contention. Let $M_{ij}\left(\tau \right)$ be the set of payloads successfully delivered from i to j within time $\tau$.

Together, G, c, and ${\Delta }_{\mathrm{clk}}$ supply the inputs on which $S\left(c\right)$, $D\left(c\right)$, and the MAPE loop operate; the next subsection fixes the round semantics built on top.

3.2. Coordination and Timing Framework

Coordination proceeds in discrete rounds, each initiated by a node acting as a temporary leader. A round comprises $n_{\mathrm{slots}}$ transmission slots determined by the channel-adaptive schedule $S\left(c\right)$ and bounded deadline $D\left(c\right)$:

$$\begin{array}{cc}\hfill S\left(c\right)& =\lceil \mathrm{ToA}\left(c\right)\rceil +t_{\mathrm{sw}}+t_g,\hfill \end{array}$$

(1)

$$\begin{array}{cc}\hfill D\left(c\right)& =n_{\mathrm{slots}}S\left(c\right)+t_{\mathrm{lead}}+t_{\mathrm{gw}}+t_{\mathrm{margin}}.\hfill \end{array}$$

(2)

For a homogeneous validator set of size n, we take $n_{\mathrm{slots}}=n$ so each vote round assigns one deterministic LoRa transmit slot per participant before quorum aggregation.

Each node maintains a single active vote $v=\langle \mathrm{id},t_{\mathrm{start}},t_{\mathrm{deadline}},r\rangle$ with retry flag $r\in \{0,1\}$. Votes that arrive while another is active are stored in a bounded FIFO queue Q of capacity $K=10$. This ensures deterministic upper bounds on latency and resource usage, with maximum queue recovery time of $10\times S\left(c\right)$.

The algorithmic design assumes a hybrid fault framework appropriate for intermittently connected LoRa mesh networks [36,37]. Nodes may experience crash faults, in which a node stops transmitting or fails silently, as well as omission faults caused by packet loss due to channel interference or buffer overflow. In addition, timing faults are considered: local clock drift can lead to slot misalignment within the configured ${\Delta }_{\mathrm{clk}}$ envelope used in the analysis.

The coordination layer exposes a quorum decision interface and enforces deterministic timing bounds through $S\left(c\right)$, $D\left(c\right)$, bounded queueing, and a single retry. The fault model considers crash and omission behaviour on intermittently connected links; adversarial Byzantine behaviour is out of scope for the implementation level properties stated here and for the evaluation in Section 6.

A round is successful if at least q nodes agree on the same vote outcome within the deadline $D\left(c\right)$. If the quorum condition is not satisfied within the specified deadline, the protocol initiates a bounded retry mechanism, allowing at most one retry per vote.

3.3. Baseline Model: Static Slot Scheduling (SSS)

To compare against a conservative non-adaptive schedule without collecting a second corpus, we define static slot scheduling (SSS) that fixes the LoRa configuration to $c_{\mathrm{SF}12}$ (SF12 on 125 kHz with the same coding and payload assumptions as the firmware) and uses worst-case airtime for every round. Static spacing and deadline are

$$\begin{array}{cc}\hfill S_{\mathrm{static}}& =\lceil \mathrm{ToA}\left(c_{\mathrm{SF}12}\right)\rceil +t_{\mathrm{sw}}+t_g,\hfill \end{array}$$

(3)

$$\begin{array}{cc}\hfill D_{\mathrm{static}}& =n_{\mathrm{slots}}{S}_{\mathrm{static}}+t_{\mathrm{lead}}+t_{\mathrm{gw}}+t_{\mathrm{margin}}.\hfill \end{array}$$

(4)

Both the adaptive scheduler and SSS are grounded in the same time-on-air quantity $\mathrm{ToA}(·)$: the adaptive controller computes $\left(S\right(c),D(c\left)\right)$ from $\mathrm{ToA}\left(c\right)$ using the current radio configuration c, whereas SSS fixes c to $c_{\mathrm{SF}12}$ and therefore uses one conservative $\mathrm{ToA}\left(c_{\mathrm{SF}12}\right)$ for all rounds. The key distinction is whether the timing rules track per-round PHY settings (adaptive, executed) or impose a fixed ToA schedule (static). Section 7.2 reports three complementary comparison points: (i) the measured adaptive validation trace, (ii) an executed fixed-configuration static baseline (SF10) measured on hardware (Table 4), and (iii) a replay-derived fixed-SF12 worst-case timing baseline (SSS) applied counterfactually to the adaptive trace (Table 7). Trace replay then recomputes each validation round’s counterfactual completion time by substituting $\left(S\right(c),D(c\left)\right)$ with $(S_{\mathrm{static}},D_{\mathrm{static}})$ while preserving the logged initiation order, per-slot transmission attempts, and finalisation events (quorum formation and retries). Medians and tail latencies in Table 7 are replay-derived; the measured adaptive row is taken directly from the same 2,514-round trace. This baseline is a counterfactual timing comparison that holds the observed event sequence fixed while changing only the slot/deadline rules; it does not, by itself, constitute a second long-run executed with static SF12 timing on the nodes.

Trace replay quantifies timing-rule sensitivity on an identical logged event sequence, and it does not model closed-loop feedback that would arise under an actually executed static policy. In particular, (i) longer slot spacing can change collision/loss patterns, (ii) different deadlines can change when retries occur and thus alter subsequent transmissions, and (iii) queue dynamics can change when earlier rounds take longer and overlap with application and gateway activity. For these reasons, we use replay to characterise timing-policy sensitivity and a conservative upper-bound schedule under fixed events, while treating executed baselines as the source of measured static-configuration behaviour.

A companion study evaluates executed fixed configuration behaviour of the same four-node LoRa mesh stack under a fixed high-reliability PHY setting (SF10 with 120-byte payloads), including measured quorum and full-participation latencies, success rate, and tail latency (Table 4). The SF12 SSS replay here answers a complementary question for the MAPE validation corpus: how pessimistic completion times become if every slot in the same 2,514-round log assumes worst-case SF12 airtime. The two baselines are not interchangeable—they answer different questions under different PHY assumptions—but together they separate (i) measured fixed-configuration operation from (ii) counterfactual worst-case static timing on the adaptive event log. Executing a long-run static-SF12 schedule on hardware for the same workload remains a useful extension.

3.4. Problem Definition and Design Rationale

We seek a self-managing mesh coordination layer with: (i) safety—at most one committed outcome per vote id; (ii) liveness under crash/omission within the tested quorum model; and (iii) low latency L and bounded recovery time $T_{\mathrm{rec}}$ on duty-cycled, memory-limited devices. Central orchestration is ruled out by the deployment model.

Three constraints drive the design. Delays swing with SF, interference, and MCU load, so each node must sense and retune locally. A capacity-K queue, explicit $D\left(c\right)$, and $r\le 1$ retries cap state and avoid retransmission storms when several nodes recover together. The MAPE loop exports measurements directly into the slot planner, rather than through a separate management plane that might itself be unreachable.

Section 4 formalises these constraints as executable algorithms.

4. Algorithms

Notation used below is summarised in Table 2. Algorithm 1 is the vote engine: one active vote, FIFO queue of capacity K, and at most one retry. Algorithm 2 is the MAPE-K controller that samples radio and node metrics on a fixed interval and updates the timing parameters consumed by Algorithm 1. The subsections present cleanup rules, safety and liveness properties (Section 4.4), and the autonomic controller.

Algorithm 1 Channel-Adaptive Coordination with Queue and Single Retry

Require:  $s\in \{\perp ,v\}$, FIFO queue Q of capacity K Require:  $c,n_{\mathrm{slots}},t_{\mathrm{sw}},t_g,t_{\mathrm{lead}},t_{\mathrm{gw}},t_{\mathrm{margin}}$ 1:    2: Event OnReceiveVoteInit$\left(x\right)$: 3: if  $s=\perp$  then 4:    $v\leftarrow \langle x,t_{\mathrm{now}},t_{\mathrm{now}}+D\left(c\right),0\rangle$ 5:    StartVote$\left(v\right)$; 6: else if x = s.id  then 7:    MergeFragments$\left(s\right)$ 8: else if $\left|Q\right|<K$ then 9:    Enqueue$(Q,\langle x,t_{\mathrm{now}},0,0\rangle )$ 10: else 11:    SendBusy$\left(x\right)$ {Send NACK, sender backs off} 12: end if 13:    14: Event OnQuorumReached$\left(\right)$: 15: FinaliseVote(); CleanupVote(); $s\leftarrow \perp$ 16: if  $Q\ne \varnothing$  then 17:    $u\leftarrow \mathtt{Dequeue}\left(Q\right)$ 18:    $u.t_{\mathrm{start}}\leftarrow t_{\mathrm{now}}$; $u.t_{\mathrm{deadline}}\leftarrow t_{\mathrm{now}}+D\left(c\right)$ 19:    StartVote$\left(u\right)$; $s\leftarrow u$ 20: end if 21:    22: Event OnDeadlineTick$\left(\right)$: 23: if  $s\ne \perp$  and  $t_{\mathrm{now}}\ge s.t_{\mathrm{deadline}}$  then 24:    if $s.r=0$ then 25:      FinaliseVote(); $s.r\leftarrow 1$ 26:      $s.t_{\mathrm{start}}\leftarrow t_{\mathrm{now}}$; $s.t_{\mathrm{deadline}}\leftarrow t_{\mathrm{now}}+D\left(c\right)$ 27:      RescheduleSlots$\left(S\right(c\left)\right)$ 28:    else 29:      FinaliseVote(); CleanupVote(); $s\leftarrow \perp$ 30:      if $Q\ne \varnothing$ then 31:         $u\leftarrow \mathtt{Dequeue}\left(Q\right)$; $u.t_{\mathrm{start}}\leftarrow t_{\mathrm{now}}$; $u.t_{\mathrm{deadline}}\leftarrow t_{\mathrm{now}}+D\left(c\right)$ 32:         StartVote$\left(u\right)$; $s\leftarrow u$ 33:      end if 34:    end if 35: end if

4.1. Deterministic Cleanup with Bounded Queue and Single Retry

To ensure predictable recovery under intermittent links, the coordination engine maintains at most one active vote at a time. Incoming votes are queued in a bounded FIFO buffer of capacity K. Each vote $v=\langle \mathrm{id},t_{\mathrm{start}},t_{\mathrm{deadline}},r\rangle$ carries a retry flag $r\in \{0,1\}$. A vote may be retried once using updated timing derived from the channel configuration c.

The slot spacing and deadline are computed from the LoRa time-on-air parameters (closed-form airtime from the PHY parameterisation of the deployed transceiver family [4,38]):

$$\begin{array}{cc}\hfill t_{\mathrm{sym}}(BW,SF)& ={\displaystyle \frac{2^{SF}}{BW}},\hfill \end{array}$$

(5)

$$\begin{array}{cc}\hfill S\left(c\right)& =\lceil \mathrm{ToA}\left(c\right)\rceil +t_{\mathrm{sw}}+t_g,\hfill \end{array}$$

(6)

$$\begin{array}{cc}\hfill D\left(c\right)& =n_{\mathrm{slots}}S\left(c\right)+t_{\mathrm{lead}}+t_{\mathrm{gw}}+t_{\mathrm{margin}}.\hfill \end{array}$$

(7)

The queue provides bounded buffering with capacity $K=10$, ensuring deterministic recovery time $O\left(K\right)$. Safety is maintained by enforcing a single active vote and limiting the retry count to at most one ($\le 1$). Timing functions $S\left(c\right)$ and $D\left(c\right)$ adapt automatically with LoRa bandwidth and spreading factor, thereby stabilising slot allocation under channel variation.

When queue capacity is exceeded, the node issues a SendBusy notification (NACK) to the vote initiator to signal overload; the initiator then applies exponential backoff (initial delay 500 ms, maximum 4 s) before retrying, which prevents vote loss without unbounded congestion.

4.2. Correctness and Bounded Progress

The correctness of the autonomic coordination process is defined by two fundamental properties: safety and liveness. Safety ensures that all non-faulty nodes reach consistent decisions, while liveness properties that progress continues despite transient faults and intermittent connectivity.

Safety is enforced through a set of invariants that constrain node behaviour throughout the coordination process. At most one active vote may exist within a round at any given time, and vote cleanup must complete before the initiation of any subsequent vote. Each vote is retried at most once, which bounds fault recovery and prevents unbounded retransmission, while FIFO ordering of queued votes preserves the arrival sequence across distinct identifiers.

Together, these invariants prevent two quorums from deciding conflicting outcomes for the same vote identifier. Because any retry reuses the same identifier and deadline structure, stale or duplicate state cannot be committed after cleanup. As a result, agreement is preserved provided that the quorum size satisfies $q>f$ and that at least one honest node remains active in each round.

The algorithm design ensures liveness when at least a quorum of nodes remains reachable within bounded delay $D\left(c\right)$. If temporary disruptions prevent quorum formation, pending votes are held in the queue Q and retried after timeout. The bounded queue capacity K prevents indefinite growth of uncommitted votes, maintaining finite recovery time.

Formally, let $T_{\mathrm{rec}}$ denote the maximum time to recover quorum after a transient fault. Given retry bound $r\le 1$ and deterministic slot spacing $S\left(c\right)$, the expected upper bound on recovery is:

$$T_{\mathrm{rec}}\le 2D\left(c\right)+KS\left(c\right),$$

which ensures eventual completion under bounded delay and limited fault rate under the stated fault model.

4.3. Assumptions and Decision Semantics

To avoid over-interpreting the implementation-aligned properties below, we make explicit the assumptions and the meaning of finalisation used in this paper.

Each coordination instance is keyed by a unique vote identifier id and targets a single outcome value associated with that identifier (e.g., a hash-committed payload). A node FinaliseVote() when either (i) a quorum of q authenticated participant messages is accumulated (quorum mode, three-of-four in the evaluation), or (ii) all n participants contribute within the bounded wait window $W_{\mathrm{perf}}$ (full participation mode). Once finalised, CleanupVote() removes local state for that identifier and prevents later messages for the same id from being committed after cleanup.

The arguments in Section 4.4 are stated for the evaluated crash/omission setting with honest firmware, where (i) messages are authenticated and vote identifiers are not forged; (ii) non-faulty nodes follow the specified queue, deadline, and retry rules ($K=10$, $r\le 1$); (iii) participants share a consistent membership list for the round; and (iv) quorum intersection holds for the chosen threshold [12]. Byzantine equivocation, replay attacks, and adversarial scheduling are outside the experimental scope of this paper.

4.4. Implementation Invariants and Recovery Bounds

We state compact properties that mirror the implemented invariants and bounds rather than a full protocol proof under adversarial scheduling.

Proposition 1 (implementation safety shell, per vote id). At most one committed value is associated with each vote identifier.

Invariant I1 enforces a single active vote; retries reuse the same identifier and deadline envelope; FIFO queueing with cleanup before the next activation prevents overlapping decisions for the same id. Under authenticated messages and quorum intersection assumptions, two conflicting quorums for the same id cannot both complete without violating those invariants. This is an implementation-aligned argument rather than a full proof under adversarial scheduling.

Proposition 2 (bounded liveness). If at least q nodes are reachable within deadline $D\left(c\right)$ for a vote, then that vote completes or exhausts its single retry within

$$T_{\mathrm{rec}}\le 2D\left(c\right)+KS\left(c\right).$$

A vote either finalises on the first attempt, waits one bounded retry, or is superseded by queue draining; each step waits at most $D\left(c\right)$, and at most K queued predecessors each advance by one slot spacing $S\left(c\right)$.

The system therefore provides bounded, implementation aligned properties. Empirical checks in Section 7 show the invariants held on all 2,514 validation rounds under crash and omission faults.

4.5. Autonomic Controller for Mesh Coordination

Algorithm 2 implements the autonomic controller for EBSC in intermittently connected networks. The controller follows the MAPE-K paradigm, integrating monitoring, adaptation, and recovery directly into the coordination execution path without reliance on centralised coordination.

Algorithm 2 Autonomic controller for offline-first quorum coordination

Require:  Local radio metrics; deterministic ToA model; payload byte lengths pktBytes and sigPktBytes; leader view-controller; gateway optional Ensure:  Self-monitor, self-adapt, self-heal under intermittent links 1:    2: State: link metrics $\mathcal{M}$, slot base ${\Delta }_0$, slot interval $\Delta$, view v, window $W_{\mathrm{perf}}$ 3:    4: Procedure Monitor(): 5: $\mathcal{M}\leftarrow$  Sample$(\mathtt{RSSI},\mathtt{SF},\mathtt{BW},\mathtt{CR},\mathtt{queueLoad},\mathtt{latency})$ 6: $\mathtt{ToA}\leftarrow$  SemtechToA$(\mathtt{SF},\mathtt{BW},\mathtt{CR},\mathtt{pktBytes})$ 7: $\mathtt{sigToA}\leftarrow$  SemtechToA$(\mathtt{SF},\mathtt{BW},\mathtt{CR},\mathtt{sigPktBytes})$ 8:    9: Procedure Analyze(): 10: ${\Delta }_0\leftarrow \mathtt{ToA}+\mathtt{guard}+\mathtt{switch}+\mathtt{proc}$ 11: $\Delta \leftarrow \mathtt{sigToA}+\mathtt{guard}+\mathtt{switch}$ 12: $W_{\mathrm{perf}}\leftarrow 3\Delta$ wait window for 4/4 13:    14: Procedure Plan(v): 15: AssignDeterministicSlots(${\Delta }_0,\Delta$) 16: if QuorumReached() and ¬LeaderFrozen()  then 17:    FreezeSigners(); ElectLeaderDet(); $v\leftarrow 0$ 18: end if 19: if LeaderTimeout(v) then 20:    $v\leftarrow v+1$ view change for failover 21: end if 22:    23: Procedure Execute(): 24: ScheduleTX(); RunScheduledTX() 25: if Perfect4of4Within $\left(W_{\mathrm{perf}}\right)$  then 26:    FinalisePerfect() 27: else if WindowExpired() and QuorumReached () then 28:    FinaliseQuorum() 29: end if 30: if IsLeader()  then 31:    SendToGatewayOrDefer() 32: end if 33: BroadcastConsensusStatus() 34: EnforceDeadlineCleanup() 35:    36: while True do 37:    Monitor(); Analyze(); Plan(v); Execute() 38: end while

In the monitoring phase, each node continuously observes radio and system-level metrics, including RSSI, spreading factor, bandwidth, coding rate, queue occupancy, and observed latency. Rather than relying on empirical transmission delays, the controller derives deterministic airtime estimates from the closed-form LoRa time-on-air expression in the radio parameters [4,38], allowing scheduling decisions to reflect real hardware behaviour under strict duty-cycle constraints.

The analysis and planning phases translate these observations into bounded timing and coordination decisions. The base slot ${\Delta }_0$ aggregates the vote-payload airtime $\mathrm{ToA}\left(c\right)$ with guard, switching, and processing delays, while the inter-slot cadence $\Delta$ uses a second Semtech airtime variable sigToA, which implements ${\mathrm{ToA}}_{\mathrm{sig}}\left(c\right)$ for the shorter signed control frames on the mesh. A bounded performance window specifies the tolerance for achieving full agreement before falling back to quorum-based execution. Deterministic slot assignments are generated, and view state is managed to support leader continuity and failover. When the current leader becomes unresponsive, a view-change operation advances the view index and enables deterministic leader rotation.

Execution enforces the resulting schedule by transmitting votes and verification messages in assigned slots. Full agreement triggers immediate finalisation, while partial but sufficient quorum completion finalises under quorum mode. Finalised summaries are forwarded opportunistically to gateways when available, and each node performs deterministic cleanup to bound local state growth.

The knowledge component of the MAPE-K loop maintains protocol state, timing bounds, and recent execution outcomes, enabling each node to reason about progress and recovery locally. By embedding deterministic timing control, leader rotation, and bounded recovery actions within this autonomic cycle, the system achieves predictable coordination on low-bitrate, delay-tolerant links with quorum-mode and full participation finalisation as discussed in Section 3.

5. Complexity and Overhead

Per round, monitoring and analysis are $O\left(1\right)$ in the number of scalar metrics sampled; planning and signature verification are $O\left(n\right)$ per node for n participants. Aggregated over the mesh, signature checks imply $O\left(n^2\right)$ local work, whereas protocols such as PBFT [11] additionally incur $O\left(n^2\right)$ messages across phases; here the LoRa schedule keeps messages linear in n per round while verification cost remains the dominant quadratic term but parallelises per node.

Memory is $O\left(n\right)$ for participant state plus $O\left(nK\right)$ for signatures buffered with at most $K=10$ queued votes, so queue RAM is bounded by construction. The MAPE-K loop runs on the same microcontroller as coordination; on the validation build it executed at a 50 ms interval and contributed under 2% CPU utilisation on the Arduino Uno R4 while sharing the core with LoRa and Wi-Fi tasks (Section 6). Adaptation adds no extra on-air control-plane messages beyond the scheduled vote and status frames already required by the coordination path, so communication overhead remains $O\left(n\right)$ transmissions per round. Energy was not power-instrumented; LoRa airtime $\mathrm{ToA}\left(c\right)$ remains the dominant energy proxy under duty-cycle limits, and adaptive timing reduces unused wait relative to worst-case SF12 provisioning without claiming a joule-level battery budget.

6. Experimental Evaluation

We evaluate the firmware on a four-node LoRa mesh with opportunistic gateway backhaul, focusing on latency, mode mix, timeouts, and invariant checks under a controlled RF setting. Interpretation limits are collected in Section 6.2.

6.1. Experiment Design

The firmware evaluated here implements EBSC as the offline-first quorum coordination layer within EBS. Evaluation covers scheduled votes, quorum or full-participation finalisation, and bounded retries under crash and omission faults with honest firmware only; it must not be read as a Byzantine fault-tolerant consensus protocol despite historical internal naming in the wider project. A four-node LoRa mesh was built from Arduino Uno R4 WiFi boards (nodes A3–A6), each hosting a Semtech SX1276 LoRa transceiver on a 915 MHz ISM band module (125 kHz and 250 kHz channel options, spreading factors SF7–SF12, coding rate 4/5 in validation logs) and sharing a single-core firmware image that multiplexes LoRa, Wi-Fi, and UDP tasks. An opportunistic Raspberry Pi 4 gateway provided best-effort Wi-Fi/UDP backhaul on port 20240; it was not required for safety or liveness. Every node ran one firmware build (Arduino IDE 2.3.3) combining Algorithm 1 and Algorithm 2; the MAPE loop updated ${\Delta }_0$, $\Delta$, and $W_{\mathrm{perf}}$ in the same task set as coordination using (1)–(2) with $n_{\mathrm{slots}}=4$. Gateway stalls of up to 10 s were observed after Wi-Fi drops during development, confirming that mesh timing cannot assume a quiet host.

For experimental observability, all nodes were connected via USB serial links (115,200 baud) to a central logging workstation running Windows 10. This configuration provides synchronised, high resolution event traces across nodes and supports the timing and invariant analyses reported in Section 7.

Communication followed a hybrid model combining WiFi UDP and LoRa mesh propagation. Nodes attempted UDP communication with the gateway when connectivity was available and fell back to LoRa-based forwarding when disconnected or partitioned. The gateway listened on UDP port 20240 for finalised blocks and disseminated configuration updates when reachable. In mesh-only operation, configuration commands and initiation signals propagated via a hop-limited store-and-forward mechanism designed to prevent flooding.

Autonomic fault management was exercised through a distributed MAPE-K loop running locally on each node at a fixed 50 ms interval. On the validation firmware build, that control interval added under 2% CPU utilisation on the Arduino Uno R4 while sharing the core with LoRa and Wi-Fi tasks. To minimise control overhead, nodes exchanged only essential information, including outcomes, participant counts, and critical timing measurements. Gateway reachability was determined through adaptive probing, with nodes operating fully autonomously when the gateway was unavailable. This design ensured that adaptation and recovery behaviour were evaluated under both connected and partitioned conditions without reliance on centralised coordination.

6.2. Limitations of Experimental Validation

The evaluation uses a four-node testbed with high-rate USB serial instrumentation and co-located LoRa radios in a controlled indoor laboratory. This setting supports detailed timing and invariant checking, and it fixes the scope of what is measured.

• Clocking and synchronisation. USB serial logging introduces implicit clock alignment through the host; independent untethered oscillator drift is not measured.
• RF environment. The controlled indoor laboratory does not capture outdoor multipath, strong external interference, mobility, or geographic dispersion.
• Scale. Topology size $n=4$ does not characterise denser meshes or large validator sets; Section 9 provides analytical scaling arguments only.
• Fault model. Experiments exercise crash and omission faults with honest firmware. Byzantine equivocation, adversarial scheduling, and intentional jamming are out of scope.
• Baselines. The executed static reference is a fixed-SF10 hardware run (Table 4). The SF12 static comparison is a replay counterfactual on the adaptive event log (Table 7), not a long-run executed SF12 campaign on identical events.
• Energy. Airtime is observed as an energy proxy; battery-level joule budgets were not power-instrumented.
• External systems. We do not reimplement third-party adaptive LoRaWAN or consensus stacks on this testbed; related-work positioning is by objective and assumptions (Section 2).

Within this defined setting, the paper establishes the behaviour of the adaptive timing controller and bounded recovery mechanisms on real embedded hardware.

6.3. Experiment Execution

Rounds were initiated via UDP commands to nodes with gateway connectivity, while mesh-only nodes received initiation messages through LoRa propagation. Each node executed deterministic slot scheduling and single-retry logic as specified in Algorithm 1, maintaining autonomous operation regardless of gateway availability. To minimise network load, only essential coordination metadata were transmitted during execution, including vote identifiers, outcomes (full participation or quorum), and participant counts. LoRa configuration updates were disseminated through the mesh to ensure consistency even under partial connectivity.

Following an initial optimisation and stabilisation phase, the validation study comprised 2,514 coordination rounds executed on the controlled testbed. The evaluation covered natural link variability, rounds with varying numbers of participating nodes (three to four), and execution both with and without active gateway backhaul to assess fully mesh-autonomous operation. Multiple LoRa configurations were tested to examine the impact of channel parameters on latency, including spreading factors from $SF=7$ to $SF=12$ and bandwidths of 125 kHz and 250 kHz.

Operational margins were selected after laboratory experimentation on the target hardware rather than from analytic defaults alone. Extended bring-up runs were used to separate Wi-Fi/LoRa contention effects, validate queue and single-retry cleanup under fault injection, and settle the timing margins $t_{\mathrm{sw}}=50$ ms, $t_g=100$ ms, and $t_{\mathrm{lead}}=200$ ms together with $K=10$ and $r\le 1$, chosen to accommodate SX1276 airtime, half-duplex switching, and single-core scheduling on the Uno R4 while keeping deadlines tight enough to limit queue buildup. The reported validation results use one frozen firmware revision at these parameters; Section 7 analyses the 2,514-round post-tuning window. First-deadline satisfaction $\rho$ and latency statistics in that window characterise steady-state behaviour of the selected configuration, not exploratory development logs.

6.4. Runtime safety invariant checks

The firmware asserts invariants I1–I4 on every round during validation. Table 3 records violations observed over the 2,514-round window; the checks provide implementation evidence complementary to the informal arguments in Section 4.4.

No violations were observed. Together with the static bounds on K and r, this supports the claim that the deployed binary matches the intended safety shell under the exercised fault model.

6.5. Outcome measures

Table 5 defines the metrics captured during experiments and used to evaluate coordination performance in Section 7. Metrics are extracted from instrumented firmware logs: the coordination engine (Algorithm 1) and MAPE loop (Algorithm 2) share one runtime image, so samples reflect single-core scheduling, LoRa variability, and intermittent WiFi.

Table 3. Runtime enforcement of safety invariants across 2,514 coordination rounds

Invariant	Violations	Max observed	Status
I1: Single active vote	0	1 vote	Verified
I2: Cleanup before next	0	–	Verified
I3: Single retry max	0	1 retry	Verified
I4: FIFO ordering	0	–	Verified

Table 3. Runtime enforcement of safety invariants across 2,514 coordination rounds

Invariant	Violations	Max observed	Status
I1: Single active vote	0	1 vote	Verified
I2: Cleanup before next	0	–	Verified
I3: Single retry max	0	1 retry	Verified
I4: FIFO ordering	0	–	Verified

Table 4. Executed fixed-configuration baseline (SF10) measured on identical hardware (separate run, not replay-aligned with the 2,514-round adaptive validation trace). Success rate applies only to the SF10 workload.

Metric	Value	Configuration
Success rate	100%	SF10, four nodes
Three-of-four quorum latency	2.7 s	SF10, CR 4/5
Four-of-four latency	5.2 s	SF10, CR 4/5
End-to-end latency (P99)	6.6 s	SF10, 120 B payloads

Table 4. Executed fixed-configuration baseline (SF10) measured on identical hardware (separate run, not replay-aligned with the 2,514-round adaptive validation trace). Success rate applies only to the SF10 workload.

Metric	Value	Configuration
Success rate	100%	SF10, four nodes
Three-of-four quorum latency	2.7 s	SF10, CR 4/5
Four-of-four latency	5.2 s	SF10, CR 4/5
End-to-end latency (P99)	6.6 s	SF10, 120 B payloads

Table 5. Outcome measures used in the validation analysis

Measure	Symbol	Definition
Coordination latency	L	Time from vote initiation to finalisation
First-deadline satisfaction rate	$\rho$	Fraction of rounds that satisfy the first adaptive deadline $D\left(c\right)$ without invoking the single-retry path

Table 5. Outcome measures used in the validation analysis

Measure	Symbol	Definition
Coordination latency	L	Time from vote initiation to finalisation
First-deadline satisfaction rate	$\rho$	Fraction of rounds that satisfy the first adaptive deadline $D\left(c\right)$ without invoking the single-retry path

A multi-threaded serial logger records 18 timing channels from all four nodes while matching vote events online; SF7–SF12 and 125/250 kHz settings are swept as described above. Section 7 reports the 2,514-round post-tuning validation window; development and bring-up traces were used for parameter selection and are excluded from those headline statistics.

In the validation trace, $\rho =0.886$ (88.6% of rounds), complementary to the adaptive first-deadline timeout rate reported with the results depicted in Table 7. After warm-up, measured slot edges remained within $\pm 2$ ms of the planner schedule under the USB-logged setup, consistent with the scheduled timing model used to derive $S\left(c\right)$ and $D\left(c\right)$.

6.6. Artefacts and Reproducibility

The results in Section 7 are obtained from instrumented firmware logs collected on the four-node testbed for the 2,514-round post-tuning validation window. The corresponding USB serial traces, processed tables, and analysis scripts used to generate the reported figures and tables are publicly available at https://github.com/f2ka07/adaptive-timing-data/.

7. Results and Analysis

We structure the results as follows: mode-level latency, trace-replay comparison to static SF12 scheduling (Section 3.3), per-node summaries, distribution and correlation views, timeout and recovery behaviour, gateway sensitivity, and a synthesis tied to Table 7.

7.1. Participation-Mode Analysis

The framework supports two adaptive finalisation modes based on node participation, demonstrating the balance between latency and completeness. Table 6 presents the breakdown across 2,514 validation rounds. Figure 2 visualises the same mixture.

Table 6. Coordination Latency by Participation Mode

Mode	Threshold	Rounds	Median (s)	90th %ile (s)	95th %ile (s)
Quorum (3/4)	75%	1,580	2.1	2.8	3.2
Full participation (4/4)	100%	934	5.3	6.4	7.2
Overall	–	2,514	3.4	6.4	7.2

Table 6. Coordination Latency by Participation Mode

Mode	Threshold	Rounds	Median (s)	90th %ile (s)	95th %ile (s)
Quorum (3/4)	75%	1,580	2.1	2.8	3.2
Full participation (4/4)	100%	934	5.3	6.4	7.2
Overall	–	2,514	3.4	6.4	7.2

The histogram shows a faster mass corresponding to quorum finalisation and a slower mass corresponding to full participation, with a small tail attributable to bounded single-retry recovery.

The system achieved three-of-four quorum finalisation (a three-node threshold in our four-node setting) in 62.9% of rounds (1,580/2,514) with median latency of 2.1 seconds. Full participation (4/4) occurred in 37.1% of rounds (934/2,514) with median latency of 5.3 seconds, reflecting the additional bounded wait time specified by the window $W_{\mathrm{perf}}$ in Algorithm 2. Interpreting these statistics, the scheduler is designed to expose an explicit latency–completeness trade-off: when a quorum is reached quickly the round can finalise early, while rounds that keep waiting for 4/4 finalisation are intentionally slower but more complete in the sense of including all participants’ contributions under honest firmware. These results should be read within the evaluated crash/omission setting, not as evidence of adversarial Byzantine tolerance.

7.2. Trace-Replay Comparison to Static Slot Scheduling

This section separates three notions of baseline so the evaluation can be interpreted without conflating them. (i) Adaptive measured: the 2,514-round validation trace reported throughout Section 7. (ii) Static executed (fixed configuration): a separate hardware run under fixed SF10 on the same class of devices (Table 4). (iii) Static replay (fixed-SF12 worst case): the SSS counterfactual of Section 3.3, replaying the adaptive event log under $(S_{\mathrm{static}},D_{\mathrm{static}})$ (Table 7).

SSS replay is a timing-policy sensitivity analysis under a frozen event sequence. It is not a substitute for a long-run executed static-SF12 campaign: closed-loop collisions, retry timing, and queue dynamics would differ under an actually executed static policy (Section 3.3). Table 7 is treated as an upper-bound style counterfactual and Table 4 as the executed fixed-configuration reference.

Table 4 summarises the executed fixed-SF10 run. Table 7 contrasts the measured adaptive controller against the SSS replay. Adaptive medians match Table 6. The SF10 reference uses a favourable fixed PHY and 120-byte payloads, so deadlines carry more slack than many adaptive rounds that sweep SF7–SF12; it is not a head-to-head reliability comparison on identical events. The adaptive trace reports $\rho =0.886$ (11.4% first-deadline miss rate) with all misses recovered by a single retry.

Table 7. Median latency, 90th percentile latency, and timeout rate for the measured adaptive controller and trace-replayed static SF12 schedule (SSS) over the same 2,514-round event log.

Model	Median (s)	P90 (s)	Timeout rate
Static SSS (SF12 replay)	11.3	12.0	5.1%
Adaptive (measured)	3.4	6.4	11.4%

Table 7. Median latency, 90th percentile latency, and timeout rate for the measured adaptive controller and trace-replayed static SF12 schedule (SSS) over the same 2,514-round event log.

Model	Median (s)	P90 (s)	Timeout rate
Static SSS (SF12 replay)	11.3	12.0	5.1%
Adaptive (measured)	3.4	6.4	11.4%

Under the replayed static schedule, each slot assumes worst-case SF12 airtime, so median completion time increases toward the fixed-cycle duration implied by $(S_{\mathrm{static}},D_{\mathrm{static}})$. The lower replay timeout rate reflects that $D_{\mathrm{static}}$ is looser than many adaptive per-round deadlines that triggered retries in the measured trace; it should not be read as evidence that static SF12 execution would necessarily yield fewer timeouts on hardware. Consistent with Section 3.3, we interpret Table 7 as a timing-policy sensitivity analysis under identical logged events (different timing rules), not as an executed head-to-head benchmark.

7.3. Timing and Finalisation Sensitivity

Two comparisons use the validation trace and the replay baseline from Section 3.3: static timing rules versus adaptive $\left(S\right(c),D(c\left)\right)$, and quorum versus full-participation finalisation.

Table 7 replaces $\left(S\right(c),D(c\left)\right)$ with $(S_{\mathrm{static}},D_{\mathrm{static}})$ on the same 2,514-round event log. Relative to the measured adaptive controller, the static-schedule replay increases median completion time from 3.4 s to 11.3 s, isolating sensitivity to the timing rules updated by the MAPE-K loop.

Table 6 conditions on observed participation in the same trace: three-of-four quorum mode has median latency 2.1 s, while full participation has median latency 5.3 s. The gap quantifies the additional wait when all participants must be included, holding the airtime-derived timing model fixed.

The replay baseline changes timing rules while holding the logged event sequence fixed; Table 6 conditions on observed participation rather than enforcing a fixed policy. A full factorial study (static timing × forced finalisation mode) would require additional executed runs or counterfactual logs. Here, the results depicted in Table 7 attribute completion-time sensitivity to removing adaptive timing, and the results depicted in Table 6 attribute the latency component tied to the finalisation policy.

7.4. Analytical Regimes for Timing Adaptation

The adaptive controller improves completion time by reducing conservative margin in the timing rules that govern unused airtime. This yields strong, system-level regime insights directly from the timing model.

From (1), slot spacing decomposes as

$$S\left(c\right)=\lceil \mathrm{ToA}\left(c\right)\rceil +(t_{\mathrm{sw}}+t_g),$$

so timing adaptation changes the dominant term $\mathrm{ToA}\left(c\right)$ when PHY settings vary. A fixed worst-case schedule instead provisions $S_{\mathrm{static}}$ using $\mathrm{ToA}\left(c_{\mathrm{SF}12}\right)$ for every round (3). The resulting sensitivity is governed by the ratio

$${\displaystyle \frac{S_{\mathrm{static}}}{S\left(c\right)}}\approx {\displaystyle \frac{\mathrm{ToA}\left(c_{\mathrm{SF}12}\right)+t_{\mathrm{sw}}+t_g}{\mathrm{ToA}\left(c\right)+t_{\mathrm{sw}}+t_g}},$$

which increases when $\mathrm{ToA}\left(c\right)$ is much smaller than the worst-case airtime.

LoRa airtime grows rapidly as data rate decreases (higher spreading factor, lower bandwidth). Adaptation helps most in regimes where (i) the node frequently operates at better-than-worst-case PHY settings (e.g., lower SF or higher BW than the SF12/125 kHz bound used by SSS), and (ii) PHY settings vary across rounds so that a single static schedule would have to provision for the worst case. When the system already runs near the worst-case airtime for extended periods, adaptive timing has limited headroom because $\mathrm{ToA}\left(c\right)\approx \mathrm{ToA}\left(c_{\mathrm{SF}12}\right)$.

When $\mathrm{ToA}\left(c\right)\gg (t_{\mathrm{sw}}+t_g)$, slot time is airtime-dominated and timing adaptation directly translates into shorter slots and deadlines. When $\mathrm{ToA}\left(c\right)$ becomes comparable to fixed overheads $(t_{\mathrm{sw}}+t_g)$, the marginal benefit of further reducing airtime shrinks because $S\left(c\right)$ approaches an overhead floor. This predicts diminishing returns for adaptation at high data-rate PHY settings.

Table 6 shows a second, orthogonal regime effect: when one participant is delayed or absent, quorum finalisation avoids waiting for full participation and reduces latency. In rounds where all participants respond promptly, the policy difference collapses and both modes converge toward the same airtime-limited schedule.

7.5. Latency Distribution by Node

Table 8 aggregates latency by node. A Kruskal–Wallis test on per-round samples grouped by node gives $H=2.14$, $df=3$, $p=0.543$ [39]. With overlapping confidence intervals and similar interquartile ranges around a common median near 3.4 s, the test provides no evidence of a meaningful node-specific latency bias under this mix of quorum and full-participation rounds. Figure 3 shows comparable spreads across nodes.

Per-node latency distributions are bimodal across A3–A6, reflecting the system’s dual finalisation policy: faster three-of-four quorum rounds (median 2.1 s) and slower full-participation rounds (median 5.3 s). The interquartile ranges in Table 8 are therefore largely explained by this intentional mixture of execution modes rather than instability or contention.

Whisker lengths remain bounded across nodes, with 90th-percentile latencies below 6.5 s in this trace.

7.6. Latency Cumulative Distribution

To complement the per-node latency spread, we summarise the cumulative distribution of latency over the full set of measured rounds. This view quantifies the proportion of rounds completed within specific latency thresholds and complements the mode breakdown in Table 6. Figure 4 summarises the aggregated distribution.

Figure 4 makes the tail behaviour explicit: most rounds complete within a few seconds, and the remaining probability mass corresponds to full-participation waiting and the bounded retry path.

The resulting CDF summary indicates how quickly rounds finalise across nodes, including both quorum-based and full-participation outcomes. The rise around 5.3–5.5 s aligns with the concentration of full-participation (4/4) rounds (37.1% of rounds), while the remaining mass reflects faster quorum finalisation and recovery cases. Latencies remain bounded in this dataset, with 90% of rounds completing within 6.4 seconds and 95% within 7.16 seconds; the small tail beyond 7 seconds corresponds to rounds that invoke the bounded single-retry path. Together with the results depicted in Table 6, this supports the interpretation that adaptive finalisation yields a consistent mixture of execution modes within the exercised fault model and controlled conditions.

7.7. Correlation Between Metrics

We evaluated Pearson correlations across per-round log vectors (latency to finalisation, deadline-driven retries, gateway Wi-Fi events, and recovery/cleanup counters). Latency shows only weak association with retry-triggering timeouts ($r=-0.11$), indicating that timeout occurrence alone does not explain the dominant latency variation. The bimodal latency structure arises from the dual-mode finalisation policy (quorum versus full participation), and the bounded recovery design (at most one retry, bounded queue $K=10$) prevents unbounded backlog-driven delay. Figure 5 visualises the correlation structure.

Figure 5 summarises these relationships: latency correlates primarily with participation-mode and airtime-driven timing effects, while recovery/control-plane events are more strongly coupled among themselves than to end-to-end completion time in this dataset.

Strong correlations are observed among control-plane and recovery-related events, including Wi-Fi connectivity changes and enforced cleanup actions. No strong correlation is observed between latency and these control-plane events in this dataset, which is consistent with recovery activity not dominating end-to-end round completion time under the evaluated conditions.

Latency is primarily driven by timing variance and bounded retry behaviour, while queueing delay and recovery overhead remain negligible in this dataset.

7.8. Timeout Density and Recovery Behaviour

We summarise deadline-miss (timeout) events observed before the bounded single-retry path completes. Timeout events occurred in 287 rounds (11.4%), with all cases recovered via a single retry in this dataset. Figure 6 plots their distribution over the validation window.

Figure 6 shows that deadline misses are episodic rather than persistent, consistent with the design goal of bounded, self-stabilising recovery rather than oscillatory behaviour.

Timeout events are relatively infrequent, occurring in 287 out of 2,514 rounds (11.4%), indicating that the majority of rounds complete within the initial deadline without invoking recovery. All timeout events in this dataset were resolved through the bounded single-retry mechanism, resulting in zero failures due to exhausted retries. This is consistent with the intended role of the retry policy in Algorithm 1: bounded recovery without repeated retransmission.

The observed timeout rate provides a quantitative baseline for the framework’s resilience under the tested conditions. Together with the bounded recovery behaviour, these results demonstrate that transient timing violations are handled predictably and do not cascade into persistent failure or instability.

7.9. Impact of Gateway Connectivity: Wi-Fi Latency vs Timeout

To examine whether opportunistic gateway backhaul coincides with mesh deadline misses, we correlate gateway Wi-Fi latency with timeout occurrence. Coordination safety and liveness do not depend on the gateway (Section 3).

Figure 7. Gateway Wi-Fi latency versus mesh timeout occurrence across the validation window.

Figure 7. Gateway Wi-Fi latency versus mesh timeout occurrence across the validation window.

Effect size is small: Wi-Fi latency explains only about 3.2% of timeout variance ($r^2=0.032$; Pearson $r=0.18$). With $n=2,514$, even weak associations can yield $p<0.05$, so statistical significance alone would overstate practical relevance. The association is weak relative to airtime-driven timing effects, consistent with an offline-first design in which the gateway is opportunistic rather than on the critical path for round completion. Mesh airtime and the retry policy dominate timeout behaviour in this dataset.

7.10. Summary

Table 7 provides a conservative upper bound on completion times under worst-case airtime provisioning by replaying the validation event log with a fixed-SF12 static schedule (SSS). In that upper-bound analysis, SSS yields a higher median completion time than the measured adaptive trace, while the adaptive controller maintains the bimodal 2.1 s / 5.3 s behaviour reported in Table 6. The ratio between the replayed SF12 median and the measured adaptive median is reported as a timing-policy sensitivity under identical logged events. Together with the executed fixed-SF10 reference point in Table 4, the evaluation separates measured adaptive behaviour from both (i) executed fixed-configuration operation and (ii) upper-bound replay under worst-case provisioning. Across all 2,514 validation rounds under the evaluated conditions, 62.9% of rounds used quorum finalisation and 37.1% waited for full participation; 88.6% met the first adaptive deadline, 11.4% used one retry, and none exhausted the retry budget. Invariant checks I1–I4 remained clean, Kruskal–Wallis found no node bias ($p=0.543$), and Wi-Fi jitter stayed a weak correlate of timeouts ($r^2=0.032$).

8. Discussion

The four-node USB-logged setup shows that a MAPE-K scheduler around a lightweight scheduled quorum path can reduce completion time relative to worst-case SF12 replay provisioning while preserving bounded queue and retry behaviour under crash and omission faults.

Table 7 isolates timing policy by replaying an identical event sequence; it supports a sensitivity claim, not a claim that an executed SF12 static firmware would match the replayed timeout rate. Table 4 reports executed fixed-configuration behaviour under a favourable PHY on identical hardware. Together they separate measured adaptive behaviour from executed fixed-configuration operation and from a conservative replay upper bound.

Read with prior EBS work on offline-first voice and gateway integration [7,8,9], the results motivate treating wait time on the air as a first-class control variable when voice and ledger traffic share a duty cycle. Where gateways buffer finalised summaries or ledger artefacts for later backhaul, confidentiality planning must also account for harvest-now, decrypt-later exposure over the storage interval [40]. Applicable deployment assumptions include: small validator sets (n on the order of the evaluated four-node mesh or modestly larger neighbourhoods), honest participants under crash/omission, opportunistic rather than mandatory gateway backhaul, and acceptance of quorum finalisation when full participation is slow. Outdoor propagation, mobility, untethered clock drift, congestion under dense interference, and Byzantine behaviour remain unvalidated (Section 6.2).

The implementation invariants (I1–I4) and single-retry bound address deterministic cleanup under omissions and crashes. They do not provide Byzantine safety: equivocating nodes, forged vote identifiers, or adversarial scheduling could violate the informal arguments in Section 4.4. Congestion that systematically violates the configured ${\Delta }_{\mathrm{clk}}$ envelope is likewise outside the measured regime.

Section 9 summarises expected behaviour beyond $n=4$, including how $S\left(c\right)$ and $D\left(c\right)$ scale with validator-set size and duty-cycle constraints.

9. Scalability and Deployment Considerations

The evaluation in this paper uses $n=4$ nodes to enable end-to-end instrumentation and controlled fault injection. Unlike many coordination studies that report only simulation-based scalability, this work validates timing, recovery, and invariant behaviour on a deployed prototype with real LoRa airtime and embedded scheduling constraints. The following discussion summarises how the timing model and coordination overhead scale with validator-set size and with practical LPWAN deployment constraints, and how measured four-node results could inform larger-scale simulation or staged field trials.

Under scheduled transmission with $n_{\mathrm{slots}}$ slots per round, the deadline in (2) grows approximately linearly with the number of scheduled slots:

$$D\left(c\right)=n_{\mathrm{slots}}S\left(c\right)+t_{\mathrm{lead}}+t_{\mathrm{gw}}+t_{\mathrm{margin}}.$$

In the simplest mapping where $n_{\mathrm{slots}}\propto n$ (one transmit opportunity per participant per phase), both round duration and worst-case completion time increase as $O\left(nS\right(c\left)\right)$. Because $S\left(c\right)$ is dominated by the airtime term $\mathrm{ToA}\left(c\right)$ in low-rate regimes, increasing n at a fixed PHY setting can quickly drive $D\left(c\right)$ beyond operationally acceptable limits. The adaptive controller mitigates this by tracking the current $\mathrm{ToA}\left(c\right)$ and selecting spacing/deadlines that avoid provisioning every round for a worst-case PHY. However, it does not remove the fundamental linear dependence of scheduled airtime on the number of required transmissions per round.

In unlicensed LPWAN bands, regulatory duty-cycle limits and fair-use constraints bound the feasible number of transmissions per device per hour [29,34]. Increasing n increases aggregate on-air load even when individual nodes transmit infrequently. When the channel is airtime-limited, two effects become dominant: (i) more contention and collisions reduce effective delivery probability, and (ii) deadlines must grow to accommodate longer schedules, which increases application-perceived latency. Practically, larger validator sets benefit from reducing per-round message count (e.g., smaller payloads, fewer phases, or aggregated signatures where feasible) and from structuring coordination so that only a subset of nodes is required to transmit in every round.

For $n>4$, two regimes emerge. In a reliability-dominated regime (higher SF, lower BW), airtime dominates $S\left(c\right)$, so both adaptive and static schedules lengthen substantially; in this regime, quorum finalisation is particularly valuable because it avoids waiting for all participants. In a higher-rate regime (lower SF or higher BW), fixed overheads ($t_{\mathrm{sw}}+t_g$ and processing time) become a larger fraction of $S\left(c\right)$, and the marginal gain from further airtime reductions diminishes, as discussed in Section 7.4. Regardless of regime, larger n increases the probability that at least one node is delayed or temporarily unreachable; therefore, the mixture of quorum versus full-participation rounds is expected to shift toward quorum completion in the absence of strong synchronisation and stable links.

The proposed design is best suited to small-to-moderate validator sets where quorum semantics are acceptable and where per-round scheduling can be kept short relative to application deadlines. For larger meshes, a practical path is hierarchical coordination: use local quorums within neighbourhoods or clusters, then propagate committed summaries across clusters using store-and-forward. This preserves offline-first operation while avoiding $O\left(n\right)$ on-air coordination at the full network scale.

A staged programme—requiring experiments beyond this paper—could (i) repeat the present instrumentation on eight- or twelve-node indoor meshes to measure growth in $D\left(c\right)$ and timeout rates, (ii) introduce controlled geographic separation and untethered clocks outdoors, and (iii) feed empirical airtime and participation distributions into discrete-event simulators so larger topologies are explored with parameters grounded in prototype measurements. Simulation remains useful for sweeping policy choices, but the four-node trace provides anchor points for slot spacing, retry rate, and quorum-mode mix that pure simulation studies often lack.

Outdoor propagation and interference, battery budgets, larger validator sets, executed long-run static SF12 baselines, and adversarial Byzantine behaviour are left to future field and adversarial testbeds.

10. Conclusion

We presented a quorum-based coordination framework with adaptive execution timing for low-bitrate LoRa mesh networks. The approach maps runtime LoRa airtime estimates into coordination scheduling variables $S\left(c\right)$ and $D\left(c\right)$ through a deterministic MAPE-K loop, dual-mode (quorum and full-participation) finalisation, and bounded recovery with $K=10$ and at most one retry, delivered as (a) the airtime-to-timing mapping itself, (b) an embedded node-local MAPE-K loop that updates $S\left(c\right)$, $D\left(c\right)$, and finalisation policy without adding coordination messages, (c) a bounded recovery architecture with a single active instance and one retry per round, and (d) firmware validation on real hardware. The novelty is closing this airtime-to-timing control loop on constrained nodes, not a new consensus algorithm.

The framework was implemented on a four-node SX1276 LoRa mesh and evaluated across 2,514 coordination rounds under crash and omission faults with honest firmware. Three-of-four quorum finalisation achieved a median completion time of 2.1 s, while full participation achieved 5.3 s; the pooled median (3.4 s) exceeds the naive mass-weighted expectation from the two conditional medians alone, reflecting the small fraction of quorum-mode rounds whose single-retry recovery pushed completion time toward the full-participation range. Across the validation window, 88.6% of rounds completed within the first adaptive deadline and the remainder completed through bounded recovery, with no exhausted retry budgets and no observed invariant violations. Against a replay-derived SF12 static schedule (11.3 s median, an upper-bound timing-policy comparison on the same event log) and an executed SF10 fixed-configuration reference (2.7 s / 5.2 s quorum/full-participation latency), the adaptive controller retains the SF10 baseline’s favourable latency while tracking airtime online rather than fixing it offline. These results apply to the evaluated testbed and fault model.

For EBS-style deployments where voice, ledger anchoring, and mesh coordination share one airtime budget, the practical implication is that treating airtime as a runtime signal rather than a provisioning constant recovers most of the latency headroom of a favourable fixed configuration without committing the link to it in advance.

Future work requires new experiments beyond this manuscript: larger topologies, untethered outdoor timing, power-instrumented energy budgets, executed long-run static SF12 baselines, and adversarial evaluation.