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.
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.
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. Architecture, protocol behavior and implementation detail remain available through the engineering and Traversal websites.
Path intelligence
Measure path quality repeatedly and change contribution before a binary failure threshold becomes the only available signal.
Multi-path policy
Use best-path, weighted distribution, duplication or adaptive redundancy across the available links.
Multi-hop mesh
Participating Atlas peers can forward traffic across a changing topology when endpoints are not directly connected.
Mobility and Traversal
Adopt authenticated endpoint changes and use direct discovery, CGNAT traversal or relay infrastructure where required.
Offline operation
Keep the data plane and local network functions operating without a mandatory internet, cloud-controller or licensing dependency.
Operations and visibility
Inspect link state, peers, topology, traffic policy and session health through local diagnostics, web tooling and APIs.
Traffic with a purpose
Protect control from the traffic competing with it.
Not every message needs the same delivery behavior. Atlas can treat operational traffic according to urgency, freshness, reliability and available capacity.
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.
Security 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 boundaryCurrent 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 the core integration is underway. Device validation and operational testing remain before general availability.
Layer 3 guiding Layer 2
Use Atlas’s global topology and mission objectives to advise compatible local mesh behavior through supported vendor interfaces.
Synchronised TDMA mesh
Research GPS-synchronised—and eventually alternative-time-synchronised—airtime allocation and purpose-built IP mesh radios without weakening the vendor-neutral software core.