One familiar network interface
Control, voice, telemetry, video and ordinary application traffic use a logical Layer-3 network.
Platform
One logical network above every available path.
Nexus Atlas separates applications from the communications complexity underneath. Operators define the outcome and traffic policy; the software measures and schedules compatible links from different technologies and vendors.
Software-onlyRuns from servers to compatible single-board computers weighing around 15 g; no mandatory Atlas appliance.
No fixed link limitConfigure the links the deployment and node resources require.
Vendor-neutralCombine compatible paths from different equipment and service providers.
Field-demonstratedEight-node mixed fleet under controlled link degradation at Hemus 2026.
What the platform provides
Measure, protect and schedule
Atlas encrypts traffic, measures the path set and applies policy beneath applications.
Customer-selected communications
Radio, cellular, satellite, Wi-Fi, mesh and wired paths remain independently owned and operated.
Role in the stack
Change the path without changing the application.
Atlas sits between applications and the available communications inventory. Applications keep using one logical network while Atlas changes which links, peers or relays contribute underneath.
Software-first. Where compatible Linux compute already exists, the initial product case can be demonstrated without an Atlas-specific appliance or radio.
Resilience model
Across links, traffic and topology.
These layers work together. More links improve path diversity; traffic policy protects what matters; multi-hop routing extends the useful network beyond direct reach.
Path resilience
Measure each path independently and use aggregation, best-path, duplication or gradual reweighting according to policy.
Traffic resilience
Give control, voice, position, telemetry, video and bulk data delivery behavior that reflects operational value.
Topology resilience
Route through authenticated participating peers when a destination is not directly reachable and reform paths as nodes change.
Operational resilience
Continue without a mandatory cloud controller while exposing local configuration, diagnostics and live path state.
Make the available paths visible.
Atlas works directly above compatible IP-capable links. Small adapters can expose specialist or serial radios and surface modem telemetry without changing the Atlas core.
Turn each path into current evidence.
Observe reachability, latency, loss, jitter and declared capacity instead of treating a link label as a promise. And where a custom adapter owns the radio, Atlas hears what the hardware itself knows — live signal strength (RSSI), noise floor, SNR, transmit-buffer depth and error counters — so a fading link is seen from inside the radio before it is felt end-to-end.
Look seconds ahead of the measurements.
Signal trends are extrapolated forward, shared position and velocity are projected along their tracks, and each link is scored on where it is going, not only where it is — so a decision can precede the failure it avoids. Shipped, opt-in; terrain analysis in development.
Apply policy to each traffic class.
Best-path, aggregation, duplication, priority, deadline-aware delivery and optional recovery policies serve different objectives.
Reallocate traffic as the network changes.
Applications retain one logical connection while Atlas changes how the underlying paths and peers contribute.
Platform capabilities
Working components around one communications objective.
The business view stays concise. The full catalogue explains every capability, and the engineering site carries the implementation depth.
Path intelligence
Measure path quality repeatedly and change contribution before a binary failure threshold becomes the only available signal.
Full catalogueMulti-path policy
Use best-path, weighted distribution, duplication or adaptive redundancy across the available links.
Full catalogueMulti-hop mesh
Participating Atlas peers can forward traffic across a changing topology when endpoints are not directly connected — and Mesh DNS lets every member resolve fleet names locally, with no name server to lose.
Full catalogueMobility and Traversal
Adopt authenticated endpoint changes and use direct discovery, CGNAT traversal or relay infrastructure where required.
Full catalogueOffline operation
Keep the data plane and local network functions operating without a mandatory internet, cloud-controller or licensing dependency.
Full catalogueOperations and visibility
Inspect link state, peers, topology, traffic policy and session health through local diagnostics, web tooling and APIs.
Deployment & operationsTraffic with a purpose
Protect control from the traffic competing with it.
Six service classes — Control, Voice, Position, Telemetry, Video, Bulk — each with its own delivery contract. With classes enabled, a 4 Mbps video stream cannot crowd out a 2 kbps command channel.
Control and commands
Prioritise or duplicate bounded critical traffic so a large video or bulk transfer cannot silently become a control-plane problem.
Voice and position
Prefer fresh, timely information over retransmitting data that has already been replaced by a newer sample.
Video and ISR
Use available capacity while dropping frames that can no longer meet their latency budget instead of stalling the complete stream.
Bulk and deferred data
Allow patient traffic to wait through an interruption and resume when a useful path returns.
Deployment status matters. Per-class QoS, store-carry-forward and erasure recovery are optional capabilities. Their policy and test boundary must be agreed for each evaluation.
The full transport deep-dive — six classes, six contracts — nexusatlas.io/transportSecurity and trust
Protected on every path, with explicit boundaries.
The word “encrypted” should not hide which components participate in the trust model. Different path types have different forwarding boundaries.
Authenticated peer sessions
Direct Atlas peers establish authenticated encrypted sessions, with key rotation and replay protection applied by the transport.
Opaque hosted relay forwarding
Nexus Atlas Traversal relays forward end-to-end encrypted frames without joining the inner Atlas mesh trust boundary.
Trusted participating relays
An Atlas mesh relay decrypts one protected hop, makes the forwarding decision and re-encrypts toward the next hop. It is an authenticated participating node.
No mandatory Atlas appliance
When installed on compatible existing compute, Atlas adds no dedicated enclosure, mounting, cabling or Atlas-specific hardware mass.
Vendor-neutral path inventory
IP-capable links remain customer-selected. Adapters can bridge specialist radio and telemetry interfaces.
One logical network
Additional independent paths strengthen the connection without replacing equipment that already works.
Integration model
Software-first, incremental and vendor-neutral.
A programme can begin with its present compute and communications equipment, demonstrate the software boundary, then add links from other carriers, bearers or suppliers as the operational case requires.
A second route is valuable only when it introduces real diversity across equipment, carrier, backhaul, technology or physical failure domain.
Map an evaluation boundaryRunning it
One binary to install. One file to manage. One screen to watch.
A per-node web dashboard, plain-text configuration that lives in version control, a CLI for headless estates, a REST API for your NOC — and a hosted console for fleets.
Web dashboard
Links, live topology, scheduler decisions and traffic policy — a browser, not an SSH session.
Plain-text config
One human-readable file; version-controlled, templated, shipped through your existing automation.
CLI & logs
Status, stats and a live terminal monitor; structured logs to journald or syslog.
Hosted console
Enrolment, live map, per-link telemetry, offline alerts and audit across the estate.
Current boundaries
Technical evaluation begins with what is true today.
These boundaries are part of the product case, not footnotes to hide after an evaluation starts.
Linux platform today
The present daemon targets Linux compute. Android integration is an early implementation undergoing device validation.
IPv4 inside the tunnel
Underlay endpoints can use IPv4 or IPv6, while the current inner logical data path remains IPv4.
Evidence is configuration-specific
Timing, throughput and recovery behavior depend on hardware, path conditions, policy and the impairment being tested.
Extending the platform
Future directions, labelled by maturity.
These directions extend the current resilient overlay. They are not presented as generally available product capabilities.
Android nodes
An Android build exists and runs the same engine on real devices against the hosted gateways. Operational testing remains before general availability.
See it in the ecosystemCertification & interoperability
FIPS 140-3 crypto mode, hybrid post-quantum key exchange and DDS/FACE interoperability — committed tracks, honestly labelled.
The roadmap on the trust pageCross-layer intent — an underlay that listens
Adapters already carry radio telemetry upward. The same boundary can carry intent downward: Atlas tells each segment what “good” currently means — latency, throughput, energy — and the segment’s own intelligence decides how. Objectives, never knobs; advisory by construction.
Research directionsTerrain-aware routing
Elevation-model line-of-sight and Fresnel-zone analysis — built, tested and demonstrable in the mission simulator today; wiring into live scheduling and multi-hop routing is in progress.
See it in Atlas SimGPS-disciplined TDMA
One commodity half-duplex radio per node serving the whole neighbourhood, on a GPS-synchronised transmit schedule computed by the overlay — moving the intelligence from the radio into software.
The engineering write-upRelay autopositioning
With positions and velocities in the routing flood, the network computes where a mobile relay should be — “a relay at X prevents the line-of-sight loss in 40 seconds” — advisory output to the C2 system, never an automatic flight command.
Research directions