Ir para o conteúdo
NavTrax Sistema operacional de expedição

Defense · Communications · Whitepaper

The network is the target.

Any communications design that assumes the link will be available is a design that fails on contact. NavTrax treats degradation as the normal case: per-message key rotation, hop rerouting inside two seconds, jittered beaconing, and a documented response to jamming and GPS spoofing.

What we are designing against.

A tactical mesh faces four adversary actions, and a design that addresses only the first is not a design.

Interception. A shared channel key means capturing one node yields the traffic history of the whole network. This is the failure that matters most after the fact.

Node loss. Nodes stop. If path recomputation waits for a human to notice, the message is already late. The relevant number is the time from the last acknowledgment to the first retry on a different path.

Direction finding. A predictable beacon interval is a fix. Regular, identical transmissions are the easiest thing in the RF environment to locate.

Denial. Jamming the band and spoofing GNSS are cheap, widely available and frequently combined. A system whose fallback is "wait for the link" has no fallback.

The design, stated so it can be evaluated.

Per-message key rotation
Every message is encrypted under a freshly derived key. Capturing a node yields that node’s forward traffic only — not the network’s history. This is the single most consequential difference from a shared-channel-key mesh.
Acknowledgment per hop
Frames are acknowledged hop by hop rather than end to end, so a failure is localized to the link that failed instead of being reported as an end-to-end timeout.
Sub-two-second repair
A missing acknowledgment within the beacon window marks the peer down, the path is recomputed, and the first retry goes out on a different route. No operator action.
Beacon cloaking
Transmission intervals are jittered and beacon power is reduced to the minimum that sustains the link, which degrades direction-finding without degrading the mesh.
Jam response
On detected denial the stack hops channel, drops to a lower bitrate with higher link margin, and where necessary switches to a store-and-forward posture that tolerates minutes rather than seconds.
GNSS spoof response
Position discontinuity and constellation-geometry checks flag a spoof. The client falls back to inertial dead reckoning corrected by terrain matching against the offline DEM.
Store and forward at the edge
Unattended relay caches hold traffic for a bounded window and report what they still hold, so "it will get through" is a number with a horizon.

What is actually delivered.

01

Forward secrecy per message

Node capture does not yield network history.

02

Autonomous path repair

Under two seconds from last acknowledgment to first retry.

03

Reduced RF signature

Jittered intervals, minimum sustaining power.

04

Channel and mode agility

Hop and downshift on detected denial.

05

GNSS-denied navigation

Dead reckoning corrected by terrain matching against the offline DEM.

06

Bounded store and forward

Held traffic is reported with its age, not assumed delivered.

07

Off-the-shelf hardware

Meshtastic and MeshCore class radios. No bespoke procurement.

Adversary action and system response
ActionDetectionResponseOperator step
Node capturePer-message keys limit exposure to forward trafficNone
Node lossBeacon gapPath recompute, retry under 2 sNone
Direction findingJittered interval, minimum powerNone
Band jammingNoise floor and error rateChannel hop, bitrate downshiftNone
Sustained denialHop and downshift exhaustedStore-and-forward postureAdvisory shown
GNSS spoofingPosition discontinuity, geometryDead reckoning plus terrain matchingAdvisory shown

Traced, node by node.

Mesh resilience — relevant process graph Arraste para deslocar · ⌘/Ctrl + scroll para zoom · arraste um nó para reorganizar

Degradation is the normal case.

Mesh is on Pro. Cloaking, jam response and GNSS-denied fallback are configured per deployment on Enterprise.