Routing and protocol translation for low Earth orbit.
ELEVSOFT SPACE-NIC
A preliminary architecture: this note explains the concept and the mechanism. The simulation campaign that evaluates the routing approach over real orbital data is reported in the white paper, ES-002.
Low Earth orbit is filling with constellations that operate as separate mesh networks, which limits the sharing of capacity and routes. Interconnecting compatible networks would give operators access to spare transport capacity, alternative delivery routes, and greater resilience, while reducing repeated integration work. The Space-NIC is a standardized onboard component aimed at that gap: one card that translates between the optical and host-side networking standards satellites already use, and forwards across a multi-hop mesh using tables computed on the ground from orbital prediction rather than converged in orbit by a link-state protocol. Satellites from different makers can already form a link; what does not exist is a vendor-agnostic, off-the-shelf onboard card that routes and translates across those links. This note sets out the preliminary architecture and the published work it rests on; the supporting simulation results are reported in the white paper.
A mechanism, its sources, and the order of proof.
1.1 Purpose and audience
This note is written for engineers deciding whether the approach is sound. It assumes the reader knows what an optical terminal is and does not gloss its acronyms. The commercial argument is made elsewhere. What follows is the preliminary architecture, the published work it rests on, and the order of proof; the simulation campaign behind the routing approach is reported in the white paper.
One card between the optical link and the host bus.
2.1 Datapath
The card sits between the spacecraft optical terminals and the host bus. Ingress framing is parsed into packets, each packet is matched against a forwarding table already resident on the card, and the result is framed for whichever bus the host actually speaks. The forwarding table is an input rather than a product: it is computed on the ground for a given epoch and uplinked, so the lookup stage never waits on a protocol to converge. Fig. 1 shows the arrangement.
A block diagram of the card. On the left, five optical ingress ports carrying SDA OCT v3.2.0, SDA OCT v4.0.0, a proprietary OCT waveform, CCSDS and Ethernet. They feed one card containing three stages in sequence: parse, which turns optical framing into packets; lookup, which reads a forwarding table; and frame, which emits packets in the format the host expects. The forwarding table is drawn below the three stages, feeding into lookup, and is marked as computed on the ground from ephemeris and uplinked per epoch rather than converged in orbit. On the right, the host bus, with SpaceWire, SpaceFibre, Ethernet and CCSDS ports.
Fig. 1 · Datapath of the Space-NIC. Mixed optical ingress on the left, three stages in sequence, host bus on the right. The forwarding table is an input to the card rather than something the card derives.
Forwarding tables computed from orbital prediction.
3.1 The topology is deterministic
LEO topology is deterministic. Contact windows between satellites follow from ephemeris, so which neighbours a spacecraft can see, and when, is predictable well ahead of the pass. This is a property of the orbits, not of any particular design.[LEO networking survey]
3.2 Tables generated per epoch
The design generates forwarding tables on the ground per epoch, uplinks them ahead of time, and swaps them at scheduled link make and break events. Nothing converges in orbit; the routing decision has already been made by the time the packet arrives.
3.3 Cost of the link-state alternative
The alternative is running a terrestrial link-state protocol across the constellation. One published emulation of OSPF over a 48-satellite LEO constellation counts 235 LSU and LSAck packets for a single topology change, spent as control traffic on the inter-satellite links that are the scarcest resource on the spacecraft. Fig. 2 sets that figure beside what this design does instead.[OSPF convergence overhead]
| LINK-STATE IN ORBIT | ELEVSOFT | |
|---|---|---|
| TOPOLOGY | Discovered in orbit | Predicted on the ground from ephemeris |
| ON A LINK CHANGE | Reconverges | Swaps to the table for the next epoch |
| CONTROL TRAFFIC | 235 LSU and LSAck packets per topology change, published | One table uplink per epoch |
| CARRIED ON | The inter-satellite links themselves | The ground uplink |
| BASIS | Published emulation, 48 satellites | Simulated over real orbital data; white paper, section 3.2 |
Fig. 2 · Where the forwarding decision is computed. The left column is published behaviour for a link-state protocol over a LEO mesh; the packet count is from the cited 48-satellite emulation. The right column is what this design does instead.[OSPF convergence overhead]
Protocol translation in the datapath.
4.1 Ingress and egress are both mixed
Ingress is optical and mixed: SDA OCT profiles, vendor-proprietary OCT waveforms, CCSDS framing, Ethernet. Egress is whatever the host expects: SpaceWire and SpaceFibre on older buses, Ethernet on newer ones, CCSDS where the ground segment demands it. The spread is a fact of the terminal and avionics market as it stands, not an assumption of this design.[Terminal vendor landscape]
4.2 Why the datapath and not the host processor
Translation happens in the datapath rather than in a host processor. At line rate there is no room for a store-and-forward round trip through software, or for a per-packet cost that grows with the number of distinct protocols in the constellation.
4.3 Coverage
Fig. 3 is the ingress-to-egress coverage of the datapath.
| SpaceWire | SpaceFibre | Ethernet | CCSDS | |
|---|---|---|---|---|
| SDA OCT v3.2.0 | ||||
| SDA OCT v4.0.0 | ||||
| Proprietary OCT | ||||
| CCSDS | ||||
| Ethernet |
Fig. 3 · Ingress-to-egress coverage. Rows are what arrives on the optical side; columns are what the host expects. XLATE marks a pair the datapath translates, PASS a pair that is the same protocol on both sides.[Terminal vendor landscape]
A reference implementation, not a proprietary stack.
5.1 Standards the card speaks
The design implements the SDA Optical Communications Terminal standard, v3.2.0 and v4.0.0, and the NEBULA network standard that sits above it, alongside CCSDS optical for civil interoperability.[SDA NEBULA v3.05]
5.2 Why a merchant part helps
In 2025 GAO recommended that SDA prove its laser links work in orbit in each batch of satellites before committing to the next, and noted that SDA had yet to demonstrate a link between two terminal vendors in space. A merchant part built to the published standard is aimed at that gap.[GAO-25-106838]
5.3 Commercial shape
The commercial shape follows from the technical one: a card, plus the same core licensable as an IP block for integrators who would rather build it into avionics they already make.
The case for silicon over software.
6.1 Power against rate
Optical downlinks from small LEO satellites are specified at up to gigabits per second, and DLR notes that compact LEO satellites often cannot afford such a link on mass and power grounds.[DLR optical downlinks for small LEO]
6.2 What that rules out
Link-state routing and protocol translation both run at packet rate. In software on a general-purpose processor their cost scales with traffic, and we do not believe a small satellite’s power envelope has headroom for that at gigabit rates. That is the argument for putting the datapath in reconfigurable silicon and leaving the processor to configuration. Reconfigurability also matters on its own: standards revise and new formats appear over a satellite’s service life, and a reprogrammable datapath can take new protocol implementations after launch within the limits of its physical interfaces.
Two builds, one core.
7.1 The split
A radiation-tolerant COTS-plus card for bench work and early flight demonstration, and a radiation-hardened flight unit for production programmes. The two sit at very different price and qualification points, and the split exists so that one piece of logic can reach both.
7.2 The common core
Both builds run the same routing and translation core, and that core is licensable on its own.
| COTS-PLUS | RAD-HARD FLIGHT | |
|---|---|---|
| ROLE | Bench work and early flight demonstration | Production programmes |
| RADIATION POSTURE | Radiation-tolerant parts | Radiation-hardened parts |
| ROUTING AND TRANSLATION CORE | Common core | Common core |
| CORE LICENSABLE AS IP | Yes, as an IP block | Yes, as an IP block |
Fig. 4 · Two builds against one core. The split is how one piece of logic reaches two very different price and qualification points.
The order of proof.
8.1 Sequence
Packet-level simulation first, then hardware in the loop, then a ground interoperability test across terminals from more than one vendor, then a hosted payload for on-orbit heritage. Each step gates the one after it. The simulation step is complete: the white paper reports evaluation over real orbital data for every tracked Starlink, OneWeb and Iridium NEXT satellite, covering connectivity across constellation boundaries, ground-computed forwarding schedules against a link-state baseline, recovery from unexpected link failures, and storage and update requirements at larger scales. Fig. 5 lists the sequence and the state of every step.
| STEP | WHAT IT ESTABLISHES | STATE |
|---|---|---|
| 1 | Packet-level simulation of ephemeris-driven forwarding against a link-state baseline: control overhead, delivery, and recovery across link make and break events | COMPLETE · WHITE PAPER |
| 2 | Hardware in the loop: a bench driven by real orbital propagation, showing scheduled table swaps and translation at rate | PLANNED |
| 3 | Ground interoperability across optical terminals from more than one vendor | PLANNED |
| 4 | A hosted payload, for on-orbit heritage | PLANNED |
Fig. 5 · The order of proof. Each step gates the one after it. The state column is the programme on the date of this revision; the simulation campaign is reported in the white paper.
- Shortest Path Orbit Prediction for Resilient LEO Satellite Networks to Navigating the Cosmos · IJCISIM vol. 17, 2025
- Optical Satellite Communication: Who Builds the Terminals · Space Ambition, 2026-06-01
- Laser Communications: Space Development Agency Should Create Links Between Development Phases · U.S. Government Accountability Office, 2025-02-26
- LEO Satellite Networking Relaunched: Survey and Current Research Challenges · arXiv 2310.07646, 2023
- Direct Optical High Speed Downlinks and Ground Station Networks for Small LEO Missions · DLR · 16th Ka- and Broadband Communications Conference, 2010
- Network Established Beyond the Upper Limits of the Atmosphere (NEBULA) Standard, v3.05 · US Space Development Agency, 2024-09-25