Offline Emergency Peer-to-Peer Broadcast Protocol

1.1. Related Work

3.1. Transport Abstraction Layer (TAL)

The TAL manages physical-layer state transitions and exposes a uniform datagram interface to the Mesh Intelligence Layer. To support OEPB, the TAL MUST expose a minimum datagram MTU of 256 bytes to the MIL. Transports that cannot natively deliver a 256-byte MTU (e.g., standard BLE 4.0 with a 20-byte ATT payload) MUST implement fragmentation and reassembly at Layer 2. Transport-specific framing is defined in separate Transport Binding Profile documents. A companion document [OEPB-BLE] defines the Bluetooth Low Energy binding, including the advertising mode, the L2 fragmentation and reassembly scheme required to meet the 256-byte MTU over BLE 4.x legacy advertising, and the optimized single-frame path for BLE 5.x with Data Length Extension. Binding profiles for Wi-Fi Direct, LoRa, and IEEE 802.15.4 are future work; Section 11.3 discusses the platform constraints any Wi-Fi Direct binding must address.¶

TAL implementations that perform L2 fragment reassembly MUST apply a reassembly timeout: any partially-received fragment set for which the complete packet has not been received within MAX_FRAG_TIMEOUT = 30 seconds of the first fragment's arrival MUST be discarded and all associated reassembly buffers released. This prevents memory exhaustion attacks where an attacker sends only the first fragment of a large packet and withholds subsequent fragments indefinitely. Implementations on LoRa or other low-data-rate transports with duty-cycle constraints SHOULD increase MAX_FRAG_TIMEOUT to at least 60 seconds to accommodate the transport's time-on-air budget.¶

3.2. Mesh Intelligence Layer (MIL)

The MIL executes all core overlay routing policy:¶

• Trickle algorithm [RFC6206] for probabilistic suppression.¶

• Weighted Fair Queuing (WFQ) across five message classes.¶

• MsgID-keyed deduplication cache with LRU eviction.¶

• Multi-radio bridging for heterogeneous-radio nodes.¶

• Rate limiting: The MIL applies per-transport-source-address rate limiting (absolute intake budget) for all packets. Per-public-key-fingerprint rate limiting for authenticated packets is an Application Layer responsibility, because the sender's public key is not present in the fixed header and can only be resolved by the Application Layer trust store (see Section 8.2).¶

The MIL operates a single logical deduplication namespace spanning all transport bindings. A packet accepted as novel by the MIL is broadcast on all active Transport Bindings.¶

3.3. Application Layer

The Application Layer parses CBOR [RFC8949] payload blocks and maps data structures to end-user interfaces. It is responsible for:¶

• Constructing outbound OEPB packets including the Ed25519 signature.¶

• Setting the initial TTL value.¶

• Presenting received messages with appropriate trust indicators.¶

3.4. Geographic Scope Design

Geographic scope information is intentionally absent from the OEPB v1 fixed header. Geographic scope filtering is an Application Layer function: terminal nodes SHOULD filter displayed messages by geographic relevance using coordinate fields present in ALERT, EVAC, and SOS message payloads. Relay nodes in the MIL MUST NOT drop packets based on geographic scope -- relay nodes may lack location awareness entirely, and encoding a geographic field in the 40-byte header would consume MTU budget required for cryptographic material.¶

This design mirrors the trust architecture: just as relay nodes forward without signature verification (preserving life-safety reachability for unauthenticated SOS), relay nodes also forward without geographic verification (preserving mesh coverage across heterogeneous deployments). Geographic relevance is a presentation-layer concern, not a forwarding concern.¶

Implementations MAY add a geo_scope field to the header in a future protocol extension to enable relay-level geographic suppression in high-density homogeneous deployments. Such an extension is out of scope for OEPB v1.¶

5.1. Sizing Constraints

Fixed Header = 4 + 8 + 8 + 16 + 4 = 40 bytes
Ed25519 Signature                  = 64 bytes
Total Overhead (signed packet)     = 104 bytes

Given minimum Transport MTU of 256 bytes:
MAX_PAYLOAD_SIZE = 256 - 104 = 152 bytes

Unsigned packets have a maximum payload of 216 bytes (256 - 40). However, implementations SHOULD use the signed-packet budget of 152 bytes as the safe default to allow signatures to be added without restructuring.¶

Payload sizes exceeding MAX_PAYLOAD_SIZE for the applicable packet type MUST cause the parser to silently discard the packet.¶

5.2. Field Definitions

Version (1 byte): Assigned 0x01. Nodes receiving an unknown version value MUST silently discard the packet. Version 1 establishes no backward compatibility obligations with future versions.¶

Msg Type (1 byte): Identifies the message class. Valid values are 0x01-0x05. Packets carrying unknown or reserved Msg Type values MUST be silently discarded and MUST NOT be forwarded.¶

TTL (1 byte): Hop limit. Decremented by 1 on each forward. The recommended initial value is DEFAULT_TTL = 10. Nodes MAY set initial values up to MAX_TTL = 15. Nodes MUST silently discard packets received with TTL = 0 (before decrement). Nodes MUST silently discard packets received with TTL > MAX_TTL (15) on ingress; such values indicate a malformed or maliciously crafted packet. TTL is mutable and MUST NOT be included in the signature input (see Section 5.3).¶

Hop Count (1 byte): Incremented by 1 on each forward. Retained to supply Application Layer heuristics such as spatial proximity estimation. Nodes MUST silently discard packets received with Hop Count >= MAX_HOPCOUNT = 15. Hop Count is mutable and MUST NOT be included in the signature input.¶

Timestamp (8 bytes): 64-bit unsigned integer, UNIX epoch seconds. Nodes MUST tolerate highly unsynchronized clocks; the Timestamp field is used for cache eviction velocity relative to the receiving node's local clock, not for absolute event ordering. See Section 8 for expiration semantics.¶

Nonce (8 bytes): 64-bit pseudo-random value generated fresh for each new message. Combined with the Timestamp, the Nonce provides a cryptographically unique sequence number, allowing identical payloads originating simultaneously to produce distinct Message IDs.¶

Message ID (16 bytes): Primary deduplication key. Computed deterministically from immutable packet fields prior to signature generation. See Section 5.3 for the canonical construction.¶

Payload Length (2 bytes): Length in bytes of the Variable Payload field. A value of 0 is valid for message types that carry no payload data.¶

Flags (2 bytes): Bit field controlling packet interpretation and forwarding behavior. See Section 5.5 for bit assignments. Bits not assigned in this specification are Reserved. Reserved bits MUST be set to zero on transmission. Reserved bits MUST be ignored on reception.¶

Variable Payload (variable): CBOR-encoded [RFC8949] message-type-specific data. Payload schemas are defined per message type in Section 5.4.¶

Ed25519 Signature (64 bytes, conditional): Present if and only if the SIGNED flag bit (bit 0 of Flags) is set. Covers the canonical signature input defined in Section 5.3. Absent for unsigned messages.¶

5.3. Cryptographic Construction

MsgID = Truncate_128( SHA-256(
    Version        ||
    Msg_Type       ||
    Timestamp      ||
    Nonce          ||
    Payload_Length ||
    Flags          ||
    Payload
))

Signature_Input = Version   ||
                  Msg_Type  ||
                  Timestamp ||
                  Nonce     ||
                  MsgID     ||
                  Payload_Length ||
                  Flags     ||
                  Payload

5.4. CBOR Payload Schemas (CDDL)

All coordinate fields MUST use Signed 32-bit integers encoding WGS84 microdegrees. The valid range for latitude microdegrees is [-90,000,000, 90,000,000] and for longitude microdegrees is [-180,000,000, 180,000,000].¶

Note on CDDL coordinate constraints: the .size 4 operator constrains the byte length of the serialized CBOR integer but does NOT constrain the numeric value. A value such as 2,000,000,000 is byte-length-valid but geographically impossible. The schemas below use the CDDL range operator .. to enforce value bounds directly. Implementations MUST reject payloads where latitude or longitude values fall outside the stated geographic range.¶

; SOS: Individual distress signal with geographic location
SOS_Payload = {
    1: -90000000..90000000,    ; latitude (WGS84, microdeg)
    2: -180000000..180000000,  ; longitude (WGS84, microdeg)
    ? 3: uint .size 4,         ; accuracy_meters (uint32)
    ? 4: uint .size 1,         ; emergency_code (uint8)
    ? 5: tstr .size (0..40),   ; short_text (UTF-8, <= 40 B)
}

; ALERT: Hazard warning from verified authority
ALERT_Payload = {
    1: uint .size 2,           ; alert_code (uint16)
    2: tstr .size (0..60),     ; short_text (UTF-8, <= 60 B)
    ? 3: uint .size 4,         ; expires_at (uint32, Unix epoch)
    ? 4: -90000000..90000000,  ; ref_latitude (WGS84, microdeg)
    ? 5: -180000000..180000000, ; ref_longitude (WGS84, microdeg)
}

; EVAC: Evacuation directive from verified authority
EVAC_Payload = {
    1: uint .size 2,           ; evac_code (uint16)
    2: tstr .size (0..60),     ; short_text (UTF-8, <= 60 B)
    ? 3: bstr .size (0..16),   ; route_hint (opaque, <= 16 B)
    ? 4: uint .size 4,         ; expires_at (uint32, Unix epoch)
}

; INFO: Supplementary situational information
INFO_Payload = {
    1: uint .size 2,           ; info_code (uint16)
    2: tstr .size (0..60),     ; short_text (UTF-8, <= 60 B)
    ? 3: bstr .size (0..16),   ; reference (opaque, <= 16 B)
}

; AUTH: Trust management (key announcements and revocations)
; subject_id = Truncate_128(SHA-256(key_material)):
;   first 16 bytes of SHA-256 over raw 32-byte Ed25519 key.
;   128-bit fingerprint provides second-preimage resistance at 2^128.
;   MUST be consistent so revocations match announced keys.
;
; "/" (type choice) enforces conditional key_material:
;   announcement (0x01) requires key_material + validity;
;   revocation (0x02) requires only subject_id.
AUTH_Payload =
    {                          ; Key Announcement
        1: 0x01,               ; auth_action = announce
        2: bstr .size 16,      ; subject_id (Truncate_128)
        3: uint .size 4,       ; validity (seconds); REQUIRED
        4: bstr .size 32,      ; key_material (Ed25519); REQUIRED
    } /
    {                          ; Key Revocation
        1: 0x02,               ; auth_action = revoke
        2: bstr .size 16,      ; subject_id of revoked key
    }

; CANCEL: cancels a prior alert. MUST be signed.
; Replaces the normal payload when CANCEL flag is set.
CANCEL_Payload = {
    1: bstr .size 16,        ; target_msg_id (exactly 16 bytes)
    ? 2: uint .size 1,       ; reason: 0x01=expired 0x02=false_alarm
                             ;         0x03=superseded
    ? 3: tstr .size (0..40), ; short_text (UTF-8, <= 40 B)
}

The route_hint field (EVAC_Payload key 3) and reference field (INFO_Payload key 3) are opaque binary identifiers whose interpretation is deployment-specific and outside the scope of this specification. Implementations MUST NOT assume any particular structure or meaning for these fields. Interoperating deployments that require structured route hints or references MUST define the encoding in an out-of-band agreement or companion specification. Implementations that do not understand the content of these fields MUST ignore them and MUST NOT discard the packet solely because these fields are present.¶

A CANCEL packet MUST carry the same Msg Type as the message being cancelled, so that WFQ priority matches the urgency of the retraction. If the original message type is unknown to the sender, Msg Type EVAC (0x03) MUST be used as a conservative default, ensuring the retraction receives adequate scheduling bandwidth.¶

A packet with the CANCEL flag set MUST NOT be counted toward type-specific operational statistics or presentation heuristics (including the Mesh Consensus heuristic of Section 9.4), regardless of the Msg Type field value. The Msg Type field in a CANCEL packet conveys only WFQ priority for the retraction, not semantic message content.¶

CANCEL processing is split across two protocol layers. Relay nodes (MIL-layer only) and Application Layer nodes have different responsibilities:¶

Relay node behavior (MIL layer, no trust store):¶

1. Verify the SIGNED flag is set. If not, silently discard -- unsigned CANCEL packets MUST NOT be forwarded.¶

2. Forward the packet normally per Trickle and WFQ rules if the SIGNED flag is set. Relay nodes do not perform signing key verification; they cannot -- they do not cache public keys from previously forwarded messages.¶

Application Layer node behavior (nodes maintaining a trust store and presenting alerts to users):¶

1. Verify the packet is signed (SIGNED flag set). If not, silently discard.¶

2. Verify the Ed25519 signature is cryptographically valid.¶

3. Verify that the signing public key satisfies at least one of the following conditions. If neither condition is met, silently discard -- do not suppress the original message:¶

a. The signing public key matches the public key that signed the original message identified by target_msg_id (as cached from when the original was received and verified), OR b. The signing public key is the immediate (1-hop) rotation successor of the original signing key: a valid AUTH announcement (auth_action=0x01) signed by the original key, announcing the current signing key, was previously received and validated, and that AUTH message is still within its declared validity window. Rotation chain traversal MUST NOT exceed 1 hop: a key may cancel only messages signed by itself or its immediate cryptographic predecessor. Multi-hop chains (e.g., original -> key1 -> current key) are NOT valid for CANCEL authorization. This depth limit bounds the blast radius of a compromised historical key. Condition (b) accommodates the operational pattern where an authority issues an EVAC, subsequently rotates keys per the rotation policy of Section 9.1, and then discovers the EVAC was a false alarm after rotation.¶

1. Mark the target_msg_id as cancelled in the local cache and suppress its display to the user. If target_msg_id is not present in the local cache (the node never received the original message), the node MUST create a tombstone cache entry for that MsgID, permanently marked as cancelled, to preemptively suppress any future out-of-order arrival of the original message. Tombstone entries MUST persist for the full MAX_EXPIRATION_WINDOW. The tombstone cache MUST be bounded to at most MAX_TOMBSTONE_SIZE = 512 entries. When the tombstone cache is full, the oldest-received tombstone entry MUST be evicted (LRU) to create space for the new one. This may evict a tombstone that is still within its MAX_EXPIRATION_WINDOW, creating a residual window where the corresponding cancelled message could be accepted if the original arrives after eviction; this is an accepted trade-off of bounded memory operation.¶

Implementations receiving a CANCEL packet where field 2 (reason) carries a value not in {0x01, 0x02, 0x03} MUST process the cancellation normally as if the reason field were absent. An unknown reason code MUST NOT cause the CANCEL packet itself to be discarded.¶

5.5. Flags Bit Assignments

Nodes receiving a packet with the CANCEL flag set MUST verify the signature before acting on the cancellation. Unsigned CANCEL packets MUST be silently discarded.¶

6.1. Simulation-Based Characterization of Trickle Constants

The Trickle constants specified above were characterized using a discrete-event simulation across a range of node densities. Simulation parameters: 200m x 200m arena, 50m radio range, 5000ms simulation window, 30 Monte Carlo runs per configuration. The per-MsgID instance termination bounds of Section 6.3 (MAX_TRICKLE_INTERVALS = 8, MAX_TRICKLE_TX = 3) were active in all simulations.¶

Key results (Imin=50ms, k=3, Imax=1000ms):¶

Key observations:¶

• At all tested densities (10-200 nodes), delivery ratio is 100% with Imin=50ms, k=3, including with the instance termination bounds in force -- bounding instance lifetime to ~4.55 seconds costs no delivery.¶

• Suppression rate scales with density (9.5% at 10 nodes -> 83.2% at 200 nodes), demonstrating Trickle's self-scaling suppression behaviour: the algorithm eliminates more redundant transmissions precisely where the mesh is most redundant.¶

• p95 latency peaks at intermediate densities (~150 ms at 25-50 nodes, where multi-hop path lengths are longest relative to available path redundancy) and falls to 76 ms at 200 nodes, where more parallel relay paths accelerate convergence.¶

• Reducing Imin to 50ms (versus 100ms or 200ms) provides the lowest median latency with no delivery penalty. This is critical for SOS delivery where seconds matter.¶

• k=3 provides full delivery with balanced suppression. A lower threshold of k=2 suppresses more aggressively (e.g., 63.3% vs 51.0% at 50 nodes) but exhibits delivery instability in sparse, slow configurations (99.9% at 25 nodes with Imin=200ms). A higher threshold of k=5 forfeits a large fraction of suppression (32.9% vs 51.0% at 50 nodes) -- and the redundant airtime and energy that suppression saves -- for marginal latency improvement.¶

Lossy-link results: A lossless radio model trivially yields 100% delivery for any flooding protocol; the lossless table above therefore characterizes latency and suppression behaviour, not delivery robustness. To characterize delivery under loss, the same sweep was repeated with independent per-link, per-transmission Bernoulli loss applied to every delivery attempt (Imin=50ms, k=3):¶

Observations under loss:¶

• 10% per-link loss is fully absorbed at every tested density and every tested k: the redundant transmissions that Trickle deliberately permits (up to k copies per interval) function as forward error correction at the topology level.¶

• At 30% per-link loss, residual delivery failure concentrates in sparse topologies (10-25 nodes), where some nodes are reachable only through one or two relay paths; dense meshes (>= 50 nodes) retain 100% delivery. Delivery differences between k=2, k=3, and k=5 at 30% loss are within Monte Carlo variance at 30 runs per configuration and should not be interpreted as a ranking.¶

• Suppression rate falls as loss rises (51.0% to 39.8% at 50 nodes from 0% to 30% loss) without any parameter change: lost copies do not increment the redundancy counter c, so Trickle automatically substitutes retransmissions for suppression exactly when the channel degrades. This self-tuning property is the principal argument for counter-based suppression over fixed-probability gossip in emergency deployments.¶

• The loss model is a simplification: independent Bernoulli loss does not capture bursty interference, MAC-layer collision correlation between neighboring links, or capture effects. The results bound protocol-layer behaviour, not radio-layer behaviour.¶

Comparison with a flooding baseline: To quantify what Trickle adds over the simplest viable alternative, the same simulator was run in a flooding-with-deduplication mode -- on first receipt of a novel MsgID, a node schedules exactly one rebroadcast after a random 0-50ms jitter; duplicates are dropped and never retransmitted. This is the dissemination mechanism of the Meshtastic/Disaster Radio class of systems surveyed in Section 1.1. Topologies, seeds, and the loss model are paired with the Trickle runs (Imin=50ms, k=3):¶

The comparison yields three honest conclusions:¶

1. Trickle is not a transmission-count optimization over single-shot flooding. On lossless links both achieve 100% delivery, flooding transmits less (exactly once per node, by construction), and flooding's median latency is marginally lower (no Imin scheduling delay). Claims that suppression "saves airtime versus flooding" hold only against naive flooding *without* deduplication; OEPB does not make that comparison.¶

2. What Trickle purchases is loss robustness. Single-shot flooding has no recovery path: one lost transmission can permanently strand a node, and at 30% per-link loss sparse-mesh delivery collapses to 81.9-84.2%. Trickle re-arms across intervals and retransmits up to MAX_TRICKLE_TX times, holding 96.6-98.1% delivery in the same topologies -- a 12-16 percentage-point improvement exactly in the sparse, degraded conditions that characterize disaster scenarios.¶

3. The retransmission budget is self-allocating. Per-node transmissions fall from 3.0 (the full MAX_TRICKLE_TX budget) in sparse meshes, where redundancy must be manufactured, to 1.3 in dense meshes, where suppression recognizes that ambient redundancy already exists -- approaching flooding's 1.0 floor without giving up the retransmission reserve. OEPB Trickle is best understood as flooding plus a bounded, self-tuning retransmission reserve.¶

Two caveats apply: the jittered, deduplicated flooding baseline is itself a polite idealization (the simulator models no MAC collisions, so dense unsuppressed flooding suffers no broadcast-storm penalty here -- in real radio environments it would); and the transmission-count comparison inherits the lossless-model limitations noted above.¶

The chosen constants Imin=50ms, k=3, Imax=1000ms represent the optimal tradeoff across the full density range. Implementations MAY tune these values for specific deployment contexts (e.g., increasing Imin on duty-cycled LoRa radios to respect regulatory transmission limits).¶

Minimum viable topology for suppression: With k=3, meaningful Trickle suppression requires a fully-connected mesh of at least 4 nodes. In a 3-node fully-connected triangle, the maximum counter value any node can reach is c=2 (it hears the other two nodes), which is less than k=3 -- suppression never fires with k=3. In a 2-node mesh, each node hears at most c=1 copy. Implementations SHOULD reduce k proportionally: k=2 enables suppression in a 3-node mesh (c=2 >= k=2); k=1 enables suppression in a 2-node mesh (c=1 >= k=1). The delivery ratio remains 100% in small meshes regardless of suppression; reduced k only prevents unnecessary retransmissions in micro-deployments.¶

Simulation Scope and Limitations: The results above were produced by a discrete-event Python simulator (simulator/python/trickle_sim.py) that models protocol-layer logic with position-aware topology. The simulator does not model BLE connection setup latency (~100-600ms per peer), Wi-Fi Direct group formation overhead (~2-8 seconds), MAC-layer collision behavior at high density, or radio duty-cycle constraints. Link loss is modeled only as independent per-link Bernoulli loss (see the lossy-link results above), not as correlated or bursty interference. Consequently, the median latency figures above represent a lower bound; real-hardware delivery latency on BLE or Wi-Fi Direct transports will exceed these values by the connection setup overhead of the underlying transport. The simulator validates protocol-layer correctness properties (delivery ratio, suppression behavior under varying density) rather than absolute latency. Implementations deploying on specific transports MUST measure end-to-end latency empirically on target hardware and adjust Imin to a value achievable by the transport's connection setup pipeline.¶

Simulation source: simulator/python/trickle_sim.py; full results in simulator/python/trickle_results.json.¶

6.2. Per-Transport Trickle Instances

Nodes possessing heterogeneous radios (e.g., BLE + Wi-Fi Direct) operate an independent Trickle instance per Transport Binding. The MIL deduplication cache is shared across all bindings. When a packet is received on one Transport Binding and cleared as novel by the deduplication cache, the MIL schedules independent transmissions on all other active Transport Bindings, each governed by their own Trickle state.¶

This prevents cross-radio amplification: a packet suppressed on BLE (due to c >= k) is independently evaluated on Wi-Fi Direct before being forwarded on that medium.¶

6.3. Trickle State Granularity and Reset

Each MsgID maintains its own independent Trickle state tuple (interval, c, timer_fires_at). Trickle state is per-MsgID, not per-WFQ-class. Sharing one Trickle instance across a WFQ class would allow a flood of novel packets in that class to continuously reset the interval to Imin, preventing suppression from ever engaging -- the precise attack Trickle is intended to defeat.¶

In the OEPB context, a Trickle "inconsistency" per RFC 6206, Section 4.2 is defined as the receipt of a packet bearing a novel MsgID not present in the local deduplication cache. Upon detecting this inconsistency, the node MUST initialize a new per-MsgID Trickle instance with interval=Imin and c=0.¶

When a node receives a packet with a MsgID not present in its deduplication cache (a novel message), it MUST create a new per-MsgID Trickle state entry, set the interval to Imin, set c=0, and schedule the first transmission timer at a random offset in [0, Imin], consistent with RFC 6206 Section 4.2.¶

When a node receives a packet with a MsgID already present in its deduplication cache (a redundant copy), it MUST increment the counter c for that MsgID's Trickle state. If c reaches k, the scheduled transmission for that MsgID is suppressed for the current interval.¶

Trickle instance termination: The Trickle algorithm as specified in RFC 6206 maintains ongoing routing consistency and therefore runs indefinitely. Applied unmodified to one-shot message dissemination, an unsuppressed per-MsgID instance (c < k, as occurs in sparse topologies) would retransmit the same packet once per Imax interval until the MsgID is evicted from the deduplication cache -- up to MAX_EXPIRATION_WINDOW (24 hours), or approximately 86,000 redundant transmissions of a single message. OEPB therefore bounds the lifetime of every per-MsgID Trickle instance. An instance MUST be terminated when the first of the following conditions is met:¶

1. The instance has completed MAX_TRICKLE_INTERVALS = 8 Trickle intervals since creation. With the constants of Section 6, this is the doubling ladder of 50, 100, 200, 400, and 800 ms followed by three intervals at Imax = 1000 ms, giving a maximum instance lifetime of approximately 4.55 seconds.¶

2. The node has transmitted the packet MAX_TRICKLE_TX = 3 times on the associated Transport Binding.¶

Upon termination, the instance's Trickle state tuple and pending timer MUST be discarded, freeing the instance's slot against the MAX_ACTIVE_TRICKLE_INSTANCES bound. The MsgID itself remains in the deduplication cache for the full MAX_EXPIRATION_WINDOW per Section 8.1. A redundant copy received after instance termination MUST be discarded as a duplicate per Section 7 and MUST NOT cause a new Trickle instance to be created for that MsgID; only a MsgID absent from the deduplication cache constitutes a Trickle inconsistency.¶

Both termination bounds were active in the simulations of Section 6.1: delivery ratio remains 100% across all tested densities (10-200 nodes) with the bounds in force, confirming that bounding instance lifetime costs no delivery. Implementations on duty-cycle-constrained transports that increase Imin or Imax MUST retain the interval-count and transmission-count bounds (the absolute lifetime scales with the configured intervals).¶

Originator self-suppression prohibition: A node MUST transmit the first broadcast of any locally-originated message regardless of Trickle counter state. Trickle suppression (c >= k) applies exclusively to relay forwarding of packets received from peer nodes. A locally-generated message MUST be dispatched directly to all active Transport Bindings without entering the Trickle suppression evaluation path. Failure to enforce this rule risks a victim's SOS never leaving their device in a dense RF environment where the suppression threshold is met by ambient mesh traffic before the originating node schedules its first transmission.¶

Memory note: implementations maintaining per-MsgID Trickle state MUST bound the number of simultaneously active Trickle timer instances to MAX_ACTIVE_TRICKLE_INSTANCES = 512. This bound is intentionally lower than MAX_CACHE_SIZE = 2048 because each Trickle instance requires an active timer in addition to cache memory, and constrained hardware (MCU-class devices) may have far fewer available timer resources than cache entries. When MAX_ACTIVE_TRICKLE_INSTANCES is reached, new novel MsgIDs MUST be forwarded immediately on first receipt (without Trickle scheduling) and added to the deduplication cache without a Trickle instance. Timer slots are freed by instance termination (the lifetime and transmission-count bounds above); additionally, if a MsgID is evicted from the deduplication cache while its Trickle instance is still active, that Trickle state MUST also be discarded. Because instance lifetime (~4.55 s) is far shorter than cache residency (24 h), termination is the dominant slot-recycling path, and the 512-instance bound is reached only under sustained novel-packet arrival rates exceeding ~112 packets/second.¶

7.1. Message ID Collision Handling

A SHA-256 truncation collision producing a matching MsgID for a different packet is cryptographically negligible. However, implementations MAY perform secondary disambiguation if a collision is suspected (the MsgID matches a cached entry but the payload length differs). Disambiguation rules by packet type:¶

• If both the cached and incoming packets have SIGNED flag set: compare the 64-byte Ed25519 signatures. If they differ, treat the incoming packet as a distinct message with a new cache entry.¶

• If either packet is unsigned: the collision MUST be resolved by discarding the incoming packet. Without a signature to distinguish the two, no safe disambiguation is possible. The probability of a legitimate collision between two unsigned packets is negligible (2^{-128}) and does not justify the complexity of accepting both.¶

8.1. Deduplication Cache

The MIL maintains a bounded cache of observed MsgIDs. Eviction is driven by two policies, applied in order:¶

• Time-Based Eviction: For each cached entry, compute delta = |LocalClock - Timestamp|. Entries where delta > MAX_EXPIRATION_WINDOW (default: 24 hours) MUST be evicted on each cache sweep. Implementations on critically memory-constrained hardware MAY reduce MAX_EXPIRATION_WINDOW to as low as 4 hours under high-load conditions.¶

• Capacity Eviction: When the cache exceeds MAX_CACHE_SIZE = 2048 entries after time-based eviction, the MIL evicts the entry whose wire-packet Timestamp is furthest in the past (oldest originating packet first) until the entry count is within bounds.¶

Note on CANCEL persistence: When a CANCEL is processed for a given target_msg_id, the cache entry for that MsgID MUST be retained for the full MAX_EXPIRATION_WINDOW even if it would otherwise be evicted by capacity pressure. This prevents a cancel-then-replay attack in which the cancelled MsgID is evicted from cache and a replayed copy of the original message is subsequently accepted as novel. Implementations MUST maintain a separate "cancelled" flag on cache entries independently of the capacity eviction policy.¶

8.2. Rate Limiting

A token bucket rate limiter applies per originating public-key fingerprint (derived from authenticated packets), allocating a sustained rate of 1 packet per 5 seconds with a burst capacity of 3 packets. Because the sender's public key is not present in the OEPB fixed header, the MIL cannot independently determine a packet's key fingerprint; per-key rate limiting MUST be implemented at the Application Layer, which has access to the trust store and can resolve the signing key from verified packets. The MIL applies only per-transport-source-address rate limiting (see below). Rate-limiting applies to packet acceptance, not to forwarding of packets already in the relay queue.¶

Nodes MUST apply a general absolute per-transport-source intake budget: no more than MAX_PKT_RATE = 30 packets per MAX_PKT_WINDOW = 60 seconds MUST be accepted from any single transport-layer source address (e.g., BLE MAC address, Wi-Fi Direct peer ID), regardless of packet type or authentication status. This baseline MIL-level budget is the primary defense against authenticated flooding attacks where an attacker uses a self-generated keypair to flood signed packets with unique Nonces (bypassing Trickle suppression and the unauthenticated-SOS-specific limit). When this budget is exhausted, additional packets from that source MUST be silently discarded until the window resets.¶

For unauthenticated SOS packets where no public-key fingerprint is available, an additional stricter limit applies: no more than MAX_UNAUTH_SOS_RATE (default: 10) unauthenticated SOS packets per MAX_UNAUTH_SOS_WINDOW (default: 60 seconds) MUST be accepted from any single transport-layer source address. This tighter budget applies within the general MAX_PKT_RATE budget. Both limits are intentionally per transport-layer source, not global, to prevent a single flooding attacker from exhausting budget for geographically distinct genuine SOS signals.¶

8.3. Global Intake Limiting

Under global network saturation conditions where completely unique packets overwhelm Trickle suppression, nodes MUST apply a Global Intake Limit. When the MIL's inbound queue depth exceeds DEFAULT_QUEUE_DEPTH = 64 packets (RECOMMENDED default; implementations MAY configure a different value), new packets are accepted in WFQ priority order and INFO packets are Tail-Dropped until the queue depth returns to a safe level. Implementations MUST document their configured queue depth threshold.¶

9.1. Identity and Key Rotation

Authority nodes -- nodes that issue signed ALERT, EVAC, or AUTH messages -- SHOULD rotate their Ed25519 signing keypair periodically. The rotation period depends on the operational profile:¶

• Fixed-installation authorities (emergency operations centers, fire stations, municipal alert systems): RECOMMENDED maximum rotation period of 7 days. The physical location of such installations is typically public knowledge, so frequent rotation purchases no tracking resistance; the residual value of rotation is bounding the blast radius of an undetected key compromise.¶

• Mobile or field-operated authority keys (keys carried on personal devices by responders or officials): SHOULD rotate at least every 24 hours. A stable public-key fingerprint broadcast from a moving device allows a passive adversary to track the operator's movements (Section 10.6).¶

Rotation is deliberately SHOULD rather than MUST. Every mechanism in this specification that exists to survive rotation -- the KEY_OVERLAP_WINDOW below, the 1-hop CANCEL rotation chain of Section 5.4, and the validity-window management of Section 11.2 -- is exercised only when a rotation actually occurs. Deployments that rotate less frequently encounter proportionally fewer rotation-induced failure modes; a mandatory aggressive rotation schedule would maximize exposure to exactly the operational hazards those mechanisms mitigate, while delivering tracking resistance that fixed installations do not need.¶

Non-authority nodes (civilian SOS senders, relay-only nodes) are not required to maintain a keypair; key rotation requirements do not apply to unsigned operation. The new public key SHOULD be announced via an AUTH message signed by the previous key during the rotation window.¶

To prevent loss of CANCEL authority after key rotation, nodes MUST retain the previous private key for a KEY_OVERLAP_WINDOW of at least 10 minutes following the rotation AUTH announcement. During this overlap window, the node MAY sign CANCEL packets using the previous key to retract messages issued under that key. After KEY_OVERLAP_WINDOW expires, CANCEL authority for messages signed with the previous key is delegated to the current key via the rotation chain: a CANCEL signed with the current key is accepted for prior-key messages if a verified rotation AUTH from the previous key to the current key is in the receiving node's trust cache and remains within its validity window. See Section 5.4 for CANCEL verification rules that implement this chain.¶

9.2. Authority Trust Levels

Nodes classify received packets into one of four trust levels for presentation and forwarding policy:¶

Trust level assignment is implementation-defined. Nodes MUST NOT refuse to forward packets solely on the basis of trust level. Trust level influences presentation (e.g., visual indicators) and MAY influence storage duration.¶

9.3. Authority Root Anchors

Authority-issued EVAC and ALERT messages are verified against Monolithic Root Anchor public keys distributed out-of-band (e.g., pre-installed in emergency management applications, broadcast by national alert systems prior to disaster events). Nodes without a matching root anchor for a given signing key MUST treat the message as Trust Level 0 and SHOULD indicate the unverified status to the user.¶

9.4. Sybil Defense for SOS

Unauthenticated SOS broadcasts do not admit exhaustive Sybil defenses without contradicting the emergency use case (a person in immediate danger cannot be required to solve a computational puzzle). The following lightweight mitigations apply:¶

• MsgID-based Geographic Convergence: A node receiving 3 or more distinct SOS packets (distinct MsgIDs) whose payload coordinates fall within a proximity threshold (implementation-defined, e.g., 500 meters) within a rolling time window of MAX_EXPIRATION_WINDOW MAY elevate the effective trust presentation of those messages to indicate corroborated geographic activity. This heuristic is advisory and SHOULD be labeled clearly as "multiple independent reports" rather than "verified." Note that a single attacker with a single device can still trigger this heuristic by originating 3 distinct SOS packets with different Nonces (producing 3 unique MsgIDs); it provides weak social evidence, not cryptographic assurance.¶

Implementations MUST NOT use Layer 2 source addresses (BLE MAC address, Wi-Fi Direct peer ID) as a metric for source diversity. On modern Android and iOS, MAC addresses are randomized per connection; a single device can rotate its L2 address to appear as arbitrarily many distinct sources, making MAC-based diversity counting trivially exploitable.¶

• Rate Limiting: Per-sender rate limiting (Section 8.2) limits the throughput of any single attacker.¶

• Forwarding Caps: SOS packets exceeding the Trickle redundancy threshold k are suppressed, limiting amplification from any single fabricated SOS flood.¶

Geographic evaluation is delegated to emergency responder analysis; the protocol does not attempt algorithmic verification of SOS legitimacy.¶

10.1. Replay Attacks

The combined (Timestamp, Nonce, MsgID) triple provides replay resistance. The 64-bit Nonce ensures that even identical payloads originating at the same timestamp produce distinct MsgIDs. Time-based cache eviction (Section 8.1) bounds the replay window to MAX_EXPIRATION_WINDOW. Implementations MUST treat clock uncertainty conservatively: a packet timestamped significantly in the past may be legitimate (originating node had a wrong clock) or a replay attempt.¶

10.2. Amplification Attacks

Trickle suppression (Section 6) is the primary amplification defense against retransmission storms for a given MsgID. An adversary that floods the network with unique-Nonce packets bypasses Trickle's MsgID-based suppression since each packet has a distinct MsgID. Three layered backstops bound this attack: (1) for authenticated sources, the per-key token bucket (Section 8.2) limits throughput to 1 pkt/5s sustained; (2) for unauthenticated sources, the per-transport-source absolute intake budget (Section 8.2) limits acceptance to MAX_UNAUTH_SOS_RATE packets per window; (3) the Global Intake Limit (Section 8.3) applies WFQ-ordered tail drop when queue depth is exceeded. Implementations SHOULD additionally monitor total forwarding rate and apply backpressure when it exceeds a locally configured threshold. Note that BLE MAC address randomization on modern smartphones limits the effectiveness of the per-transport-source budget against an attacker that rotates their L2 address; this residual risk is acknowledged in Section 3.8 of the threat model.¶

10.3. Forged Authority Alerts

An adversary may transmit EVAC or ALERT messages with the AUTHORITY_HINT flag set but without a valid signature, or with a signature from a key not in the receiving node's trust anchor set. Nodes MUST NOT present such messages as authenticated authority alerts. The AUTHORITY_HINT flag is advisory; trust is established solely through successful signature verification against a trusted root anchor.¶

At the Application Layer, packets bearing AUTHORITY_HINT=1 that fail signature verification or trust chain resolution MUST have the AUTHORITY_HINT flag treated as unset for all presentation and heuristic purposes. The flag MUST NOT be re-propagated with authority weight by relay nodes performing application-layer processing; any presentation to the user MUST reflect Trust Level 0 (Unverified) for such packets. Pure relay nodes (MIL-only forwarding without application-layer involvement) MAY forward the flag bytes unchanged, as they do not perform trust evaluation.¶

10.4. TTL Inflation by Malicious Relay

The TTL field is mutable and intentionally excluded from the signature, allowing relay nodes to decrement it without invalidating cryptographic integrity. A consequence is that a malicious relay node may inflate the TTL field (e.g., resetting a TTL=1 packet to MAX_TTL=15) before retransmitting, extending a packet's intended propagation range beyond what the originator specified.¶

The MsgID deduplication cache is the primary defense against TTL-inflation routing loops: a node that has already forwarded a MsgID will reject any subsequent copy bearing the same MsgID regardless of TTL value, preventing indefinite circulation of inflated packets within the mesh. However, the dedup cache does not prevent geographic range extension: nodes that have not yet seen the packet will accept and forward the TTL-inflated copy, propagating it further than the original TTL would allow.¶

Relay nodes MUST NOT increase TTL values on any packet they forward. This requirement cannot be cryptographically enforced, so implementations in security-sensitive deployments SHOULD log and flag packets whose hop count appears inconsistent with their TTL (e.g., TTL=15 but Hop Count=8 suggesting prior decrements that should have reduced TTL further).¶

10.5. CANCEL Abuse

The CANCEL flag allows a valid authority to retract a previously issued alert. An adversary might transmit forged CANCEL messages to suppress legitimate alerts. Section 5.5 mandates that unsigned CANCEL packets MUST be silently discarded. Nodes MUST verify that the CANCEL signing key is authorized per the rotation chain rules in Section 5.4: either it is the exact key that signed the original message, or it is the immediate (1-hop) rotation successor of that key within its validity window. A CANCEL signed by an unrelated key or by a key more than 1 rotation step removed from the original MUST be silently discarded.¶

10.6. Privacy and Tracking

Key rotation (Section 9.1) limits long-term geographic tracking via static public-key fingerprints. However, within any single rotation window, a passive adversary observing broadcast traffic can correlate a node's movements with its current key fingerprint. This is why Section 9.1 differentiates by operational profile: fixed installations with public locations gain nothing from frequent rotation, while mobile signers SHOULD rotate at least every 24 hours. Mobile operators in high-sensitivity contexts SHOULD apply additional rotation (e.g., every 6 hours) and avoid including precise coordinates in INFO packets.¶

10.7. Energy Exhaustion

Adversaries may attempt to exhaust node battery resources by flooding novel packets that pass Trickle suppression. The mandatory Imax = 1000ms bound limits active radio transmit cycles. Rate limiting and Global Intake Limiting (Section 8) provide additional protection. Implementations SHOULD implement radio duty-cycling at the TAL for low-power deployments.¶

10.8. Signature Verification Cost

Ed25519 verification on constrained hardware requires approximately 0.5-2 ms and 1-3 mA depending on hardware. Because OEPB mandates that signature verification MUST NOT be required for forwarding decisions, relay nodes can forward without verification, deferring verification cost to the application presentation layer. This asymmetry is intentional: it preserves relay throughput while allowing full verification at terminals.¶

10.9. Root Anchor Key Compromise

Root anchor keys distributed out-of-band (Section 9.3) cannot be revoked in-band. The AUTH revocation mechanism (Section 5.4) applies to sub-authority keys only; there is no OEPB-level message that can revoke a pre-installed root anchor. If a root anchor private key is compromised after deployment, all messages signed under that root anchor (or any sub-authority chain rooted there) must be treated as potentially adversarial, and there is no in-band mechanism to push a replacement root. Remediation requires an out-of-band channel (e.g., an application update). Deployments MUST treat root anchor key compromise as a critical incident requiring immediate out-of-band remediation. To limit blast radius, deployments SHOULD use root anchors only to certify short-lived sub-authority keys (via AUTH announcements) rather than signing operational messages directly with root keys.¶

10.10. CRL Withholding

An adversary that selectively drops AUTH (CRL) packets can prevent nodes from learning about compromised authority keys. This is a fundamental limitation of any offline system. Implementations SHOULD apply conservative key validity windows (AUTH packet validity field) and require periodic re-announcement of authority keys to bound the impact of CRL suppression.¶

11.1. Clock Bootstrap in Infrastructure-Absent Environments

OEPB uses the 64-bit Timestamp field for cache eviction relative to local clock. A node whose real-time clock is wrong by more than MAX_EXPIRATION_WINDOW (24 hours) will reject all received packets as expired or from the distant future, isolating itself from the mesh.¶

In an infrastructure-absent disaster scenario, a freshly powered-on or battery-reset device may have an incorrect RTC (e.g., reset to UNIX epoch 0). Implementations SHOULD apply the following clock bootstrap heuristic:¶

1. On startup, before accepting or rejecting packets on timestamp grounds, a node SHOULD listen passively for a short window (RECOMMENDED: 30 seconds) and collect the Timestamp field values of received packets.¶

2. If the node observes 3 or more packets with SIGNED=1 and AUTHORITY_HINT=1 whose Timestamps agree within a 5-minute window and diverge from the local clock by more than 1 hour, the node MAY advance its local time estimate to the median of those Timestamps. Note: AUTHORITY_HINT is an unverified advisory flag -- any device can set it. An attacker could transmit multiple SIGNED+AUTHORITY_HINT packets with false future timestamps to force a victim node's clock forward. The monotonic-only constraint (step 3) limits damage by preventing the attacker from pushing the clock backward (which would expand the replay acceptance window); a forward push causes the node to reject past-legitimate packets as "too old" until real traffic arrives. Implementations SHOULD cap single-step clock advancement at 48 hours regardless of observed Timestamps to limit attacker leverage. Implementations MUST additionally apply a cumulative multi-cycle cap: the total cumulative forward clock advancement applied via this heuristic from node startup MUST NOT exceed 72 hours. This prevents an attacker from repeatedly triggering the bootstrap condition across multiple cycles (each time staying just below the 48-hour per-step cap) to advance the node's clock by an arbitrarily large amount.¶

3. Clock adjustment MUST be strictly monotonic: a node MUST NOT move its local clock backward under any circumstance, to prevent replay window expansion.¶

4. If no Authority-signed packets are available for bootstrap, the node SHOULD accept packets whose Timestamp values fall within a liberal initial window (RECOMMENDED: +/-7 days of local clock time) for the first 10 minutes of operation, then revert to the standard +/-MAX_EXPIRATION_WINDOW check once the clock is likely synchronized.¶

This heuristic does not provide cryptographically secure time synchronization and should not be confused with NTP or PTP. Its purpose is to prevent a node with a dead RTC from being permanently excluded from the mesh.¶

11.2. CANCEL Authority Window for Long-Duration Events

The 1-hop rotation chain limit (Section 5.4) combined with periodic key rotation (Section 9.1) creates a bounded CANCEL authority window. A message signed under key K0 can be cancelled by: (a) K0 directly during the KEY_OVERLAP_WINDOW, or (b) K1 (immediate successor of K0) while the K0->K1 rotation AUTH remains within its validity window. If an event spans more than the K0->K1 AUTH validity period, messages signed under K0 can no longer be cancelled cryptographically. Authorities operating multi-day deployments MUST set the validity field of rotation AUTH messages to cover the expected event duration, and MUST issue CANCEL messages for false alarms promptly following key rotation rather than deferring them. Note that this window exists only across rotation events: the 7-day RECOMMENDED rotation period for fixed installations (Section 9.1) means most events of ordinary duration complete under a single signing key, never exercising this machinery.¶

11.3. Mobile Platform Execution Constraints

The protocol-layer properties specified in this document assume that participating nodes can transmit, receive, and relay continuously. On consumer smartphone platforms -- the primary deployment target -- this assumption is constrained by the operating system, not by the protocol, and deployments MUST plan for the following realities:¶

Wi-Fi Direct topology constraints: Wi-Fi Direct requires Group Owner (GO) negotiation before any data transfer. Group formation takes approximately 2-8 seconds, produces a star topology centered on the GO rather than a true many-to-many mesh, and Android devices can be a member of only one P2P group at a time. A relay node bridging two groups must time-division multiplex between them, adding multi-second latency per bridge hop. Consequently, Wi-Fi Direct SHOULD be treated as a high-throughput secondary transport between already-associated peers (e.g., for AUTH/CRL transfer), not as the primary spontaneous-mesh transport. BLE advertising, which requires no association, group formation, or negotiation, SHOULD be the primary discovery and dissemination transport on smartphone deployments. The BLE Transport Binding Profile [OEPB-BLE] specifies this binding.¶

Background execution limits: Mobile operating systems aggressively restrict background radio activity. On iOS, an application cannot broadcast manufacturer-specific BLE advertising data while backgrounded, and background scanning is heavily throttled; on Android, Doze mode and App Standby throttle scanning, and continuous BLE operation requires a user-visible foreground service. Mesh applications relying on background participation have historically seen effective node density collapse once users switch away from the app -- a primary operational failure mode of the FireChat-class systems surveyed in Section 1.1. Smartphone deployments SHOULD therefore run as a foreground service with persistent user-visible notification (Android) and SHOULD document the foreground-only limitation to users (iOS). Reliable always-on relay participation ultimately requires OS-level or firmware-level integration (e.g., inclusion in a platform emergency framework); this is a deployment prerequisite that no overlay protocol can engineer around, and OEPB does not claim otherwise.¶

These constraints reinforce the scope statement of Section 6.1: protocol-layer simulation results are lower bounds, and end-to-end behaviour on smartphone platforms is dominated by transport and OS factors that MUST be measured on target hardware.¶

11.4. IANA Codepoint Stability

This document defines specific numeric codepoints (Message Types 0x01-0x05, Flags bits 0-3) as informational values for Experimental use. Concurrent independent implementations SHOULD use these exact codepoint values to maintain interoperability. If this specification is advanced to the Standards Track, IANA will be requested to create formal registries (see Section 12).¶

In the interim, implementors extending the protocol with private codepoints SHOULD use values in the Reserved ranges. For Msg Type, the RECOMMENDED private-use range is 0xF0-0xFF (following the private-use range convention of [RFC8126]). For Flags bits, the RECOMMENDED private-use range is bits 8-15. Implementors SHOULD document their private codepoints in a manner that avoids collision with other deployments.¶

13.1. Normative References

• [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.¶

• [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017.¶

• [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, "The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206, March 2011.¶

• [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017.¶

• [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC 8949, DOI 10.17487/RFC8949, December 2020.¶

• [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019.¶

13.2. Informative References

• [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol Specification", RFC 5050, DOI 10.17487/RFC5050, November 2007.¶

• [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017.¶

• [RFC9171] Burleigh, S. et al., "Bundle Protocol Version 7", RFC 9171, DOI 10.17487/RFC9171, January 2022.¶

• [SERVAL] Gardner-Stephen, P. and Arns, J., "The Serval Project: Practical Wireless Ad Hoc Mobile Telecommunications", Technical Report, Flinders University, Australia, December 2011.¶

• [BT-MESH] Bluetooth Special Interest Group, "Mesh Profile Specification", Version 1.0.1, March 2019, <https://www.bluetooth.com/specifications/specs/mesh-profile/>.¶

• [EPIDEMIC] Vahdat, A. and Becker, D., "Epidemic Routing for Partially Connected Ad Hoc Networks", Technical Report CS-2000-06, Duke University, April 2000.¶

• [IEEE80211S] IEEE, "IEEE Standard for Information Technology -- Local and Metropolitan Area Networks -- Part 11: Wireless LAN MAC and PHY Specifications Amendment 10: Mesh Networking", IEEE Std 802.11s-2011, September 2011.¶

• [MESHTASTIC] Meshtastic Project, "Meshtastic Open Source Mesh Communication", 2020, <https://meshtastic.org>.¶

• [APRS] Bruninga, B., "Automatic Packet Reporting System -- Protocol Reference 1.0.1", US Naval Academy, 2000, <http://www.aprs.org/doc/APRS101.PDF>.¶

• [DISASTER-RADIO] Disaster Radio Project, "Disaster Radio: Open Source LoRa Mesh Communication", 2019, <https://disaster.radio>.¶

• [OEPB-BLE] Sharma, K., "OEPB Transport Binding: Bluetooth Low Energy", Internet-Draft draft-sharma-oepb-binding-ble-00, June 2026.¶

---¶

13.3. : Test Vectors and Routing Example

Private Key Seed (Ed25519, 32 bytes):
  9D61B19DEFFD5A60BA844AF492EC2CC4
  4449C5697B326919703BAC031CAE3D55

Public Key (Ed25519, 32 bytes):
  700E2CE7C4B674427EAB27BA820BCF6F
  0FAEBE68E09FE8564292114E41DC6A41

Version     : 0x01
Msg Type    : 0x01 (SOS)
TTL         : 0x0A (10)
Hop Count   : 0x00
Timestamp   : 0x000000006787A340 = 1736942400 = 2025-01-15 12:00:00 UTC
Nonce       : 0x4F4550425F563100 (ASCII "OEPBV1\x00\x00")
Flags       : 0x0001 (SIGNED)
Payload Len : 0x0010 (16 bytes)

A3                      CBOR map(3)
  01 1A 01 B4 9D 70  key=1, lat  = 28614000 (~28.614 N, New Delhi)
  02 1A 04 9A 03 7C  key=2, lon  = 77202300 (~77.202 E)
  03 18 1E              key=3, accuracy  = 30 meters

Payload hex: A3 01 1A 01 B4 9D 70 02 1A 04 9A 03 7C 03 18 1E

01 01                            Version || MsgType
00 00 00 00 67 87 A3 40          Timestamp (BE)
4F 45 50 42 5F 56 31 00          Nonce (BE)
00 10                            PayloadLength (BE)
00 01                            Flags (BE)
A3 01 1A 01 B4 9D 70 02
1A 04 9A 03 7C 03 18 1E          Payload

MsgID: 11 84 78 44 E6 41 C2 8C 0F 40 48 24 08 8B 09 6B

01 01                            Version || MsgType
00 00 00 00 67 87 A3 40          Timestamp (BE)
4F 45 50 42 5F 56 31 00          Nonce (BE)
11 84 78 44 E6 41 C2 8C          MsgID (first 8 bytes)
0F 40 48 24 08 8B 09 6B          MsgID (last 8 bytes)
00 10                            PayloadLength (BE)
00 01                            Flags (BE)
A3 01 1A 01 B4 9D 70 02
1A 04 9A 03 7C 03 18 1E          Payload

B9 81 45 84 5F DD D9 6F  0F 49 FE 2F 95 23 16 EE
0A DE 69 53 66 E2 85 92  E3 3C 91 28 B1 59 B8 98
A8 51 E4 66 11 E6 2F F5  CE C8 36 D1 E9 15 2D 06
A9 99 C1 4C 28 E4 37 A7  25 07 6B 97 58 16 FA 08

01 01 0A 00 00 00 00 00  67 87 A3 40 4F 45 50 42
5F 56 31 00 11 84 78 44  E6 41 C2 8C 0F 40 48 24
08 8B 09 6B 00 10 00 01  A3 01 1A 01 B4 9D 70 02
1A 04 9A 03 7C 03 18 1E  B9 81 45 84 5F DD D9 6F
0F 49 FE 2F 95 23 16 EE  0A DE 69 53 66 E2 85 92
E3 3C 91 28 B1 59 B8 98  A8 51 E4 66 11 E6 2F F5
CE C8 36 D1 E9 15 2D 06  A9 99 C1 4C 28 E4 37 A7
25 07 6B 97 58 16 FA 08