Concepts, illustrated

Thirteen ideas explain most of Nexus Atlas.

Each idea is a single picture and a plain-language explanation — written for the decision-maker, not the network engineer. Every one links to the engineering site, where your advisors can go deeper — most of them into an interactive demonstration of the same idea. And every one is labelled: what is demonstrated, what ships, what is opt-in.

13 conceptsDeep links to nexusatlas.ioEvery one labelled
Concept 01 · Bonding

One connection from many links.

Field-proven

The foundation. Dissimilar links — satellite, cellular, radio, Wi-Fi, mesh, wired — become one encrypted connection, and applications see one ordinary network. They never learn which link carried the bytes, so nothing has to be integrated, modified or made "Atlas-aware". Six dissimilar link types have been bonded on one field node — a demonstrated point, not a ceiling: there is no fixed link limit, and a node bonds as many links as the deployment and its resources require.

The interactive bonding demo — nexusatlas.io
Many links converge into one encrypted connection Satellite, cellular, radio and wired links converge through the Nexus Atlas core into one resilient, encrypted logical connection. AVAILABLE LINKS MEASURE · PROTECT · SCHEDULE Satelliteany provider Cellularany carrier Radioany vendor Fiber / Wiredexisting LAN Nexus Atlas software on existing compute one resilient, encrypted logical connection APPLICATIONS STAY CONNECTED Four dissimilar links bonded into one encrypted connection Satellite, cellular, radio and fiber links are collected onto one bus and converge through Nexus Atlas into a single encrypted connection that applications see as one ordinary network. AVAILABLE LINKS ANY PROVIDER Satelliteany provider Cellularany carrier Radioany vendor Fiber / Wiredexisting LAN Nexus Atlas on existing compute ONE ENCRYPTED CONNECTION

Four links keep the picture simple — any IP-capable transport joins the same bond: 802.11s mesh, Wi-Fi HaLow, Bluetooth and serial telemetry radios via small adapters, from a few kbps to multi-gigabit.

Concept 02 · Failover

Failover you never notice.

Shipped

There is no moment where a link "fails over". Every path is measured continuously — delay, jitter, loss — and traffic shifts away from trouble in proportion to measured quality, on a cadence typically configured between 0.1 and 0.75 seconds. By the time a link actually dies, the traffic has usually already left. A response cadence, not a universal recovery guarantee — and never a binary up/down switch.

The gradual-degradation demo — nexusatlas.io
Traffic shifting between three links, live A looping timeline: three links carry evenly; loss rises on link two and its traffic visibly thins while the others densify; link two dies with its traffic already gone. ONE PAIR OF NODES · LIVE TIMELINE SHARES FOLLOW MEASURED QUALITY link 1 link 2 link 3 34%45%50% 33%10%0% 33%45%50% every path measured — even splitLOSS RISING ON LINK 2 — TRAFFIC ALREADY LEAVINGLINK 2 DOWN — ITS TRAFFIC HAD ALREADY LEFT T+0 · EVEN SPLIT T+2 S · LINK 2 DEGRADING T+4 S · LINK 2 DOWN T+0 · EVEN SPLIT T+2 S · LINK 2 DEGRADING T+4 S · LINK 2 DOWN 50%0%50%LINK 2 DOWN — ITS TRAFFIC HAD ALREADY LEFT Node A Node B GRADUAL, IN PROPORTION — NEVER A BINARY SWITCH Traffic shares re-weighting away from a degrading link Three links start with an even share; as loss rises on link two its share thins while the other two thicken, so when link two dies its traffic has already left. SHARES FOLLOW MEASURED QUALITY T+0 · EVEN SPLIT link 1 34% link 2 33% link 3 33% T+2 S · LINK 2 DEGRADING 45% 10% 45% T+4 S · LINK 2 DOWN 50% 0% 50% its traffic had already left

Shares are illustrative; the real split follows the measured delay, jitter and loss of each link, re-weighted on the configured cadence.

Concept 03 · Redundancy

Redundancy that escalates.

Shipped

Eight scheduling strategies ship; three are adaptive. As loss or latency worsens, the traffic that matters is duplicated across one, then two, then three simultaneous paths — and scaled back the moment conditions clear. The arithmetic is why it works: three independent links each losing 2% of packets yield 0.0008% effective loss with copies on all three. In the scripted demonstration, three links forced to 30% loss delivered roughly 2.7% effective loss end-to-end.

The strategies in detail — nexusatlas.io
Redundancy escalating from one to three paths, live A looping timeline: one path carries a critical stream; as loss rises the same packets are duplicated on a second, then a third path — copies travelling in step — and when conditions clear it scales back to one. ONE CRITICAL STREAM · LIVE TIMELINE REDUNDANCY FOLLOWS CONDITIONS ×1 — ONE PATH CARRIES×2 — DUPLICATED ON TWO PATHS×3 — EVERY PATH CARRIES A COPY path 1 path 2 path 3 loss low — no copies neededLOSS RISING — COPIES ABSORB ITSEVERE — THREE 2% LINKS → 0.0008% EFFECTIVEconditions cleared — scaled back to one path CLEAN LOSS RISING SEVERE LOSS CLEARED CLEAN LOSS RISING SEVERE LOSS CLEARED ×3 — EVERY PATH CARRIES A COPYSEVERE — THREE 2% LINKS → 0.0008% EFFECTIVE Node A one critical stream Node B ESCALATES UNDER PRESSURE — SCALES BACK WHEN IT CLEARS Redundancy escalating from one path to three as loss rises A critical stream travels one path while conditions are clean, the same packets are duplicated onto a second and then a third path as loss rises, and the extra copies are dropped again once conditions clear. ONE CRITICAL STREAM · A TO B CLEAN AB LOSS RISING SEVERE — EVERY PATH CARRIES A COPY scaled back the moment conditions clear THREE 2% LINKS → 0.0008% LOSS

The interference-adaptive mode is the live demonstration mode — the escalation shown here is the behaviour exhibited under controlled link degradation.

Concept 04 · Mesh

The fleet routes around loss.

Field-proven

When two nodes cannot reach each other directly, traffic crosses the other members of your own fleet — re-encrypted at every hop, up to 8 hops by default. Every node holds the same picture of the topology; lose a relay and every survivor recomputes independently, with no controller anywhere. Relay nodes are trusted, authenticated members of your fleet — stated plainly, because your security review will ask.

The distributed control-plane demo — nexusatlas.io
A relay is lost and the fleet re-routes Node A reaches Node B through a relay that is lost; the topology re-forms and traffic threads through two surviving relays instead. A RELAY NODE IS LOST TRAFFIC THREADS THE SURVIVORS relay — lost relay relay Node A Node B NO CONTROLLER — EVERY NODE RECOMPUTES ALONE A relay is lost and the fleet threads the survivors The relay Node A was using is lost, so the route re-forms through two surviving relays instead; every node recomputes independently from the same picture of the topology, with no controller anywhere. A RELAY NODE IS LOST Node A relay — lost relay relay Node B EVERY SURVIVOR RECOMPUTES ALONE

The route re-forms the moment the loss is detected — ≈ 1.25 s at default probe settings. Re-encrypted per hop; every relay is an authenticated member of your own fleet.

Concept 05 · One-to-many

One stream, many watchers.

Opt-in

When several stations watch the same live feed across the mesh, the scarce hops carry it once — not once per viewer. The network computes where the watchers' paths diverge from the topology it already floods, and duplicates the stream only there; the cost of the trunk does not grow with the audience. Measured on an eight-node rig: five minutes of Full-HD-rate video to three stations, with the scarce first hop carrying exactly one copy per packet.

How the tree is computed — nexusatlas.io
ONE COPY PER VIEWER EACH STATION SENT ITS OWN COPY ×3 ×3 ×3 relay hop relay hop junction ISR aircraft one video feed Ground station 1 Ground station 2 Ground station 3 ONE COPY PER SHARED HOP WITH NEXUS ATLAS ×1 ×1 ×1 relay hop relay hop COPIES MADE HERE ISR aircraft one video feed Ground station 1 Ground station 2 Ground station 3 One feed to three stations, sent per viewer and per shared hop Sending one copy per viewer puts three copies on the first hop; with Nexus Atlas the first hop carries one copy and the stream is duplicated only where the watchers' paths diverge. ONE COPY PER VIEWER TODAY ISR aircraft ×3 ON THE SCARCE HOP station 1 station 2 station 3 ONE COPY PER SHARED HOP WITH ATLAS ISR aircraft ×1 ON THE SCARCE HOP copies made here station 1 station 2 station 3 THE TRUNK DOES NOT GROW WITH THE AUDIENCE

Three stations watching one feed: the scarce hops carry it once — copies are made only where the stations’ paths part. Delivery stays video-shaped: losses repaired by forward error correction, never by retransmission storms.

Concept 06 · Traffic classes

Video can never starve the command link.

Opt-in

Reliability and priority are a property of the message, not the connection. Six service classes — Control, Voice, Position, Telemetry, Video, Bulk — each get their own delivery contract, and strict priority comes with reserved floors: with classes enabled, a 4 Mbps video stream cannot crowd out a 2 kbps command channel — measured, with the drop counters to show it. Classification uses standard packet marks and flow heuristics: zero application changes.

Priority under pressure, measured — nexusatlas.io
Command rides first through a degraded link A small command stream and a large video stream share one degraded link; the command stream has a reserved floor and rides first, video takes what remains. TWO STREAMS · ONE DEGRADED LINK DELIVERY CONTRACTS PER CLASS ONE DEGRADED LINK control has a reserved floor — video takes what remains Command 2 kbit/s Video 4 Mbit/s Receiver A 4 MBIT/S STREAM CANNOT CROWD OUT A 2 KBIT/S COMMAND CHANNEL — MEASURED SIX CLASSES · SIX DELIVERY CONTRACTS ZERO APPLICATION CHANGES A command stream and a video stream sharing one degraded link Control keeps a reserved floor on a degraded link while video takes what remains, so a 4 Mbit per second video stream cannot crowd out a 2 kbit per second command channel. TWO STREAMS · ONE DEGRADED LINK Command 2 kbit/s Video 4 Mbit/s CTRL VIDEO — WHAT REMAINS Receiver both still delivered control keeps a reserved floor as the link contracts 4 MBIT/S CANNOT CROWD OUT 2 KBIT/S measured, with the drop counters to show it

Off by default; with classes off the data path is byte-identical. Deadline delivery and erasure recovery are contracts of the same system — too-late video frames are dropped, never retransmitted.

Concept 07 · Delay tolerance

Nothing is lost in the blackout.

Opt-in

Bulk data addressed to an unreachable peer is held — surviving reboots — and drained automatically the instant a path returns: the home network, or a passing relay vehicle, vessel or aerial node. Sender and receiver never need to be connected at the same moment. Delivery that waits, instead of failing — demonstrated as the "data mule" scenario.

Survive the blackout — nexusatlas.io
Data waits out the blackout, then drains During a blackout, bulk data queues on the sender and survives reboots; the moment any path returns, the queue drains automatically to the receiver. DURING THE BLACKOUT — NO PATH BULK DATA WAITS INSTEAD OF FAILING Sender Receiver held on the node — survives reboots ANY PATH RETURNS — THE QUEUE DRAINS Sender Receiver drains at full bonded throughput — even via a passing relay node Bulk data queued through a blackout, then drained While no path exists the sender holds bulk data on the node, surviving reboots; the moment any path returns the queue drains automatically to the receiver at full bonded throughput. DURING THE BLACKOUT — NO PATH Sender Receiver held on the node — survives reboots ANY PATH RETURNS — THE QUEUE DRAINS Sender Receiver drains at full bonded throughput

The queue is a delivery contract of the Bulk traffic class — real-time classes are never held back behind it.

Concept 08 · Reachability

Unreachable, then upgraded.

Opt-in

A node behind carrier-grade NAT — no inbound ports, no fixed address — becomes reachable outbound-only in under a second through a relay, and the relay path is an ordinary link in the bond with its own measurements. Path candidates are then exchanged over that already-working relay, and crossing probes open a direct path through both NATs. The upgrade is a scheduler decision: the relay stays in the bond as a warm standby, so a failed attempt costs nothing. Managed relay and exit locations in the EU and North America run today; private, on-premises relay estates serve closed networks.

The traversal deep-dive — nexusatlas.io
Relay first, then a hole-punched direct path Two nodes behind carrier-grade NAT reach each other through a relay network; a hole-punched direct path then opens and carries, while the relay stays warm as standby. NO INBOUND PORTS ANYWHERE PROVEN BEHIND TWO SIMULATED CARRIER NATS Relay network reachable in under a second HOLE-PUNCHED DIRECT — RELAY STAYS WARM Node A behind carrier NAT carrier-grade NAT Node B behind carrier NAT carrier-grade NAT THE UPGRADE IS A SCHEDULER DECISION — A FAILED ATTEMPT COSTS NOTHING Relay first, then a hole-punched direct path Two nodes behind carrier-grade NAT reach each other through a relay in under a second, then a direct path is punched through both NATs and carries, while the relay stays in the bond as a warm standby. NO INBOUND PORTS ANYWHERE Node A behind carrier NAT Node B behind carrier NAT Relay network reachable in under a second HOLE-PUNCHED DIRECT Node A same NAT, no ports Node B same NAT, no ports relay — warm standby A FAILED ATTEMPT COSTS NOTHING

Relay and gateway lists are signed with an offline key and verified by every client — a directory outage never becomes a tunnel outage.

Concept 09 · Mobility

Addresses change. Sessions don’t.

Shipped

A link whose public address changes mid-mission — a cellular modem crossing carriers, a moving vehicle — keeps its tunnel without a reconnect. Sessions are bound to cryptographic identity, not to addresses, and only cryptographically verified traffic can move an endpoint. The same indifference to link identity is what lets SIM and eSIM profiles cycle underneath a mission without dropping it.

How sessions bind to identity — nexusatlas.io
A vehicle crosses carriers and the session holds A vehicle moves from one carrier's coverage into another's; its public address changes but the encrypted session to operations continues unbroken. MID-MISSION ADDRESS CHANGE NO RECONNECT — NOTHING DROPS CARRIER A CARRIER B address 100.64.7.21 address 172.58.9.4 ADDRESS CHANGES — SESSION DOES NOT vehicle — crossing carriers one session — identity is keys, not addresses Operations Nexus Atlas node ONLY CRYPTOGRAPHICALLY VERIFIED TRAFFIC CAN MOVE AN ENDPOINT A vehicle crossing carriers without dropping its session A vehicle moves from one carrier's coverage into another's and its public address changes, but the encrypted session to operations continues because sessions are bound to cryptographic identity rather than to addresses. MID-MISSION ADDRESS CHANGE CARRIER A CARRIER B 100.64.7.21 172.58.9.4 was now Operations one unbroken session IDENTITY IS KEYS, NOT ADDRESSES only verified traffic can move an endpoint

Addresses illustrative. Roaming is a property of every link in the bond — each link roams independently while the others keep carrying.

Concept 10 · Prediction

Predict, don’t react.

Opt-in

For platforms that move, the killer is geometry. Nodes share position and velocity inside the routing flood; the scheduler projects each node along its track and hands traffic to the longer-reaching link before the short one stretches past its declared range — while both still work. Signal-trend and range prediction ship today, opt-in; terrain awareness is in development. Prediction is advisory: it biases decisions, never kills a link, and never falsifies a measurement.

The position & velocity demo — nexusatlas.io
Traffic handed over before the geometry breaks A moving platform is at the edge of its Wi-Fi link's range envelope; traffic has already been handed to a longer-reaching radio before the short link breaks. THE PLATFORM IS MOVING HANDOVER BEFORE GEOMETRY BREAKS Wi-Fi range envelope radio range envelope Wi-Fi — at its range edge longer-reach radio — now carrying UAV leaving Wi-Fi range Ground station Nexus Atlas node PREDICTION IS ADVISORY — DASHBOARDS SHOW WHAT WAS MEASURED Traffic handed to the longer-reaching link before geometry breaks the short one A moving platform passes the edge of its Wi-Fi range envelope, and because nodes share position and velocity the scheduler has already handed traffic to the longer-reaching radio while both links still work. THE PLATFORM IS MOVING radio range Wi-Fi range UAV past the Wi-Fi edge Wi-Fi — at its range edge radio — now carrying Ground station position · velocity known HANDED OVER WHILE BOTH STILL WORK

Each radio is scored against its own declared reach — a 300 m Wi-Fi leg and a multi-kilometre radio leg get different risk from the same distance.

Concept 11 · Encryption

Encrypted everywhere, with the boundaries stated.

Shipped

Always on — there is no unencrypted production mode. Noise IK handshake; X25519, ChaCha20-Poly1305, BLAKE2s: the cryptographic family of WireGuard and Signal. And the word “encrypted” is not allowed to hide who can read what: direct peer traffic is end-to-end; mesh relays re-encrypt per hop and are trusted, authenticated members of your own fleet; hosted Traversal relays forward envelopes they cannot open. Three different boundaries, stated as three different facts — because your security review will ask.

Hop honesty — the three boundaries — nexusatlas.io
Three kinds of path, three stated trust boundaries Direct peers are end-to-end encrypted; mesh relays re-encrypt at every hop as trusted fleet members; traversal relays forward sealed envelopes they cannot open. ALWAYS ON — NO UNENCRYPTED MODE THE CRYPTOGRAPHIC FAMILY OF WIREGUARD AND SIGNAL Node A Node B DIRECT — END-TO-END end-to-end — only the two endpoints hold the keys MESH RELAY — PER HOP, TRUSTED FLEET re-encrypted at every hop — relays are authenticated members of your fleet TRAVERSAL RELAY — SEALED ENVELOPES relay forwards sealed envelopes it cannot open — outside the trust boundary Three kinds of path, three stated trust boundaries Direct peer traffic is end-to-end encrypted; mesh relays re-encrypt at every hop as authenticated members of your own fleet; hosted traversal relays forward sealed envelopes they cannot open. ALWAYS ON — NO UNENCRYPTED MODE DIRECT — END-TO-END AB only the two endpoints hold the keys MESH RELAY — PER HOP, TRUSTED FLEET re-encrypted at every hop — relays are authenticated members of your fleet TRAVERSAL RELAY — SEALED ENVELOPES forwards envelopes it cannot open THREE BOUNDARIES, STATED AS THREE FACTS

The suite is the default, not a lock-in — the primitives can be exchanged without changing the protocol, the engineering basis of the FIPS and post-quantum tracks.

Concept 12 · Names

Names, with no name server to lose.

Opt-in

Your people should type isr02.narva, not read an address off a laminated card. Every node already announces who it is and where it can be reached, so every node answers name lookups itself, out of its own copy of the fleet — there is no name server anywhere in the mesh to stand up, defend or lose. Names keep resolving with the uplink dead, and when a network splits in two, each half keeps resolving its own half. Existing corporate names can be pointed down the tunnel without touching your DNS estate, and a mesh-only mode fits an EMCON posture: no query ever leaves on an uplink.

How names resolve without a server — nexusatlas.io
Four nodes resolving names with no name server A crossed-out name server sits unused while four nodes each answer name lookups from their own copy of the fleet; the network is partitioned down the middle and both halves keep resolving their own names. NAMES SERVED BY THE MESH NETWORK PARTITION NO REACHBACK REQUIRED no central name server to stand up or lose gs01.narva answers from its own copy relay04.narva answers from its own copy isr02.narva answers from its own copy ops01.narva answers from its own copy relay04.narva → resolved locally ops01.narva → resolved locally EVERY NODE ANSWERS FROM ITS OWN COPY OF THE FLEET Four nodes resolving names with no name server A crossed-out central name server sits unused while four nodes answer name lookups from their own copy of the fleet; the network is partitioned down the middle and both halves keep resolving their own names. NAMES SERVED BY THE MESH no name server to stand up or lose gs01.narva answers locally relay04.narva answers locally isr02.narva answers locally ops01.narva answers locally resolves its own half resolves its own half NO SERVER · NO REACHBACK

Answers come out of the routing database itself, so they track the topology — 30-second lifetimes, never stale by design. Names resolve only inside the tunnel, and the tunnel itself never waits on a lookup.

Concept 13 · Autonomy

No controller. No cloud. Fully offline.

Shipped

Every node is autonomous and carries everything it needs: its full configuration, its own view of the topology, its own decisions. There is no orchestrator to stand up, no cloud that must be reachable, no licence server to call — licensing is an offline signed file. The data plane needs no internet at any point in its life, air-gapped networks are a first-class operating condition, and a partitioned network keeps operating on both sides of the split.

Operations without a controller — nexusatlas.io
Four self-contained nodes, no controller anywhere Four Nexus Atlas nodes keep routing among themselves; a crossed-out cloud controller above them is disconnected and not needed. NO CONTROLLER · NO CLOUD · NO LICENCE SERVER AIR-GAPPED IS A FIRST-CLASS CONDITION no cloud, no controller Node A config · topology · decisions Node B config · topology · decisions Node C config · topology · decisions Node D config · topology · decisions EVERY NODE CARRIES EVERYTHING IT NEEDS — AUTONOMY IS THE ARCHITECTURE Four self-contained nodes routing with no controller Four Nexus Atlas nodes route among themselves over six links; above them a crossed-out cloud controller is disconnected and not needed, because each node carries its own configuration, topology and decisions. NO CONTROLLER AIR-GAPPED BY DESIGN no orchestrator to stand up, no licence server to call Node A config · topology Node B config · topology Node C config · topology Node D config · topology EVERY NODE CARRIES WHAT IT NEEDS

The only hosted pieces are optional — Traversal relays and the fleet console — and losing them costs visibility, never connectivity.

Beyond the pictures

Thirteen ideas. Seventy-five capabilities.

These pages showed the shape of the platform. The full catalogue goes through everything it does, in the same plain language — seventy-five capabilities across ten groups, each with an engineering deep link where your advisors can go deeper.

Browse the full catalogue — /product/capabilities
Request a briefing

Bring the network that is limiting your platform.

We will map the links, vendors, shared failure domains and integration boundary—and define what a useful demonstration or pilot should prove.