ES-001TECHNICAL NOTEREV A

Routing and protocol translation for low Earth orbit.

ELEVSOFT SPACE-NIC

ES-001REV A
DOCUMENTES-001
SUBJECTELEVSOFT SPACE-NIC
REVISIONREV A
ISSUED2026
CLASSIFICATIONPUBLIC
STAGECONCEPT · NO BENCH RESULTS
FIGURES 5REFERENCES 6

This document reports no measurement. Elevsoft Silicon is at concept and research stage: no simulation, no RTL, no bench, no hardware, no flight heritage, no partner, no customer. Every figure attributed to Elevsoft is a design target; every number stated as fact is cited to somebody else’s published work.

ABSTRACT

Elevsoft Silicon is building a merchant network interface card for low Earth orbit: one part 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 architecture, the published work it rests on, and the order in which it would have to be proven.

1.SCOPE AND STATUS

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 mechanism, the published work it rests on, and the order in which it would have to be proven.

1.2 Evidence classes

Every figure and every substantive claim in this document carries one of two labels.

SOURCED
The claim comes from published literature or a government report, and carries a citation. It says nothing about Elevsoft’s own work.
DESIGN TARGET
Intent. A number or a behaviour the design is aimed at, not measured.
2.SYSTEM OVERVIEW

One card between the optical link and the host bus.

2.1 Datapath

DESIGN TARGET

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.

FIG. 1 // DATAPATHREF 2.1
datapath5 IN · 4 OUT
1 PARSE · optical framing to packets2 LOOKUP · forwarding table hit, no convergence3 FRAME · packets to the host busFORWARDING TABLE · from ephemeris on the ground, uplinked per epoch

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.

DESIGN TARGET

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.

3.FORWARDING

Forwarding tables computed from orbital prediction.

3.1 The topology is deterministic

SOURCED

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

DESIGN TARGET

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

SOURCED

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]

FIG. 2 // CONTROL PLANEREF 3.3
LINK-STATE IN ORBITELEVSOFT (INTENDED)
TOPOLOGYDiscovered in orbitPredicted on the ground from ephemeris
ON A LINK CHANGEReconvergesSwaps to the table for the next epoch
CONTROL TRAFFIC235 LSU and LSAck packets per topology change, publishedOne table uplink per epoch
CARRIED ONThe inter-satellite links themselvesThe ground uplink
BASISPublished emulation, 48 satellitesDesign intent, not simulated
DESIGN TARGET

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]

4.TRANSLATION

Protocol translation in the datapath.

4.1 Ingress and egress are both mixed

SOURCED

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

DESIGN TARGET

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

DESIGN TARGET

Fig. 3 is the ingress-to-egress coverage the design targets.

FIG. 3 // TRANSLATION COVERAGEREF 4.3
INGRESS (rows) × EGRESS (columns): intended coverage, not measured
SpaceWireSpaceFibreEthernetCCSDS
SDA OCT v3.2.0
SDA OCT v4.0.0
Proprietary OCT
CCSDS
Ethernet
DESIGN TARGET

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]

5.STANDARDS

A reference implementation, not a proprietary stack.

5.1 Standards the design targets

DESIGN TARGET

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

SOURCED

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

DESIGN TARGET

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.

6.IMPLEMENTATION

The case for silicon over software.

6.1 Power against rate

SOURCED

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

DESIGN TARGET

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. It rests on the published rate figures above and on our reading of the power constraint, not on a measurement of ours.

7.FORM FACTORS

Two builds, one core.

7.1 The split

DESIGN TARGET

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

DESIGN TARGET

Both builds run the same routing and translation core, and that core is licensable on its own.

FIG. 4 // FORM FACTORSREF 7.1
COTS-PLUSRAD-HARD FLIGHT
INTENDED USEBench work and early flight demonstrationProduction programmes
RADIATION POSTURERadiation-tolerant partsRadiation-hardened parts
ROUTING AND TRANSLATION CORECommon coreCommon core
CORE LICENSABLE AS IPIntendedIntended
BUILTNoNo
DESIGN TARGET

Fig. 4 · Two builds against one core. The split is how one piece of logic reaches two very different price and qualification points.

8.VALIDATION

The order we intend to prove it in.

8.1 Sequence

DESIGN TARGET

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. Fig. 5 lists the sequence and the state of every step; work starts at its first line.

FIG. 5 // VALIDATION SEQUENCEREF 8.1
STEPWHAT IT WOULD ESTABLISHSTATE
1Packet-level simulation of ephemeris-driven forwarding against an OSPF baseline: control overhead and path stability across link make and break eventsNOT STARTED
2Hardware in the loop: a bench driven by real orbital propagation, showing scheduled table swaps and translation at rateNOT STARTED
3Ground interoperability across optical terminals from more than one vendorNOT STARTED
4A hosted payload, for on-orbit heritageNOT STARTED
DESIGN TARGET

Fig. 5 · The order the approach would have to be proven in. Each step gates the one after it. The state column is the programme on the date of this revision.