Release A established the foundation: a complete 5G Standalone network operating over a simulated geostationary satellite link on a single machine, without radio hardware or satellite capacity. Release B changes the problem. The satellite now moves.
We are releasing an end-to-end LEO NTN testbed running the same OCUDU RAN and OAI UE over a Low Earth Orbit link at 600 km altitude, with changing propagation delay and Doppler shift applied directly to the live baseband sample stream. The complete 5G procedure succeeds through cell acquisition, SIB19 decoding, random access, RRC connection setup, NAS registration, security procedures, PDU session establishment and end-to-end user traffic.
This is the next step in a larger programme: building an NTN testbed entirely from software components, capable of evolving from a single simulated satellite towards a complete satellite constellation.
From GEO to LEO: the problem becomes dynamic
A geostationary satellite operates approximately 35,786 km above the equator and appears stationary from the ground. That creates a severe timing problem: the round-trip delay is roughly 480 milliseconds, far beyond terrestrial 5G assumptions. But GEO has one useful property. The geometry is effectively constant, so once the network and UE account for the propagation delay, the underlying satellite position does not continuously change relative to the user.
LEO is fundamentally different. At 600 km the satellite is much closer and the modelled round-trip delay falls to approximately 8 milliseconds. That sounds easier. It is not.
The satellite travels at approximately 7.5 kilometres per second. It rises above the horizon, crosses the visible sky and sets again in roughly thirteen minutes. During that pass:
- the satellite-to-device distance changes continuously;
- propagation delay changes with that geometry, by roughly 11 microseconds per second;
- relative motion produces carrier-frequency shifts of tens of kilohertz; and
- the satellite position changes continuously, so timing and Doppler corrections cannot be calculated once and reused.
GEO requires the network to solve a large but mostly static timing problem. LEO requires the network and device to keep solving the problem continuously while the connection is active.
More importantly, the gNB, UE and channel must agree on where the satellite is at the same instant. If they do not, the UE can correctly calculate a correction for the wrong geometry. The mathematics may be right; the connection will still fail. That synchronisation problem is at the centre of Release B.
What the testbed models
The Release 17 configuration uses a transparent-payload architecture. The satellite acts as a relay while the gNB remains on the ground and communicates through a feeder link. From the UE perspective the radio path therefore contains two geometrical components, UE to satellite and satellite to gateway, and both legs contribute to propagation delay. Across a complete round trip the signal traverses the satellite path four times.
This distinction matters because Release 17 does not assign compensation for every part of that path to the same component. Timing and Doppler responsibilities are divided between the UE and the network, and the testbed models those responsibilities explicitly rather than applying a generic delay or frequency offset to the connection.
End-to-end architecture
The Release B testbed consists of four functional components.
OCUDU gNB
The OCUDU gNB provides the complete RAN stack. It propagates the satellite orbit, derives the required NTN parameters, computes network-side timing information, determines the scheduling offset and broadcasts satellite information through SIB19.
OAI UE
The OAI UE provides the complete NR device stack. It acquires the cell, decodes SIB19, independently propagates the satellite orbit, calculates its satellite-relative geometry, pre-compensates uplink timing and service-link Doppler, and proceeds through the normal 5G NR connection procedure.
LEO channel model
The channel model applies satellite effects directly to the baseband sample stream: propagation delay, delay variation caused by satellite motion, and service-link Doppler. Unlike Release A, the LEO model runs inside the UE ZMQ device driver, which removes an additional process and transport hop while keeping the satellite model directly in the sample path.
5G core
A standard 5G core completes the network and requires no NTN-specific modification. From the core network's perspective the system remains an ordinary NR access network; the satellite-specific behaviour is handled below it by the RAN, UE and radio-channel model. The gNB and UE exchange baseband samples through ZMQ, so no SDR or other radio hardware is required anywhere in the setup.
One orbit model, three independent consumers
A moving-satellite testbed is only useful if every component agrees on the satellite's position. Release B therefore begins with a single satellite state vector at a defined reference time, giving position and velocity. From that state, satellite position at any later time is calculated using a closed-form circular-orbit model.
The same underlying orbital state feeds three different parts of the system:
- The gNB propagates the orbit and generates the ephemeris transmitted to the UE through SIB19.
- The UE receives the ephemeris and independently propagates the satellite position for its own timing and Doppler calculations.
- The channel independently evaluates the same satellite geometry to determine the delay and Doppler that should physically affect the sample stream.
These are three separate consumers implementing the same orbital model, and they must agree. This is not simply a software-design convenience, it is a correctness condition for the testbed. If the gNB tells the UE that the satellite occupies one position while the channel applies signal conditions corresponding to another, correct protocol behaviour cannot recover the link. Release B therefore validates not only NTN signalling, but consistency between the geometry described by the network, the geometry calculated by the UE, and the geometry physically applied to the signal.
Timing under motion
Propagation delay in a moving satellite system is not only large enough to matter, it is continuously changing. A conventional closed-loop timing correction therefore cannot solve the problem on its own: by the time a correction travels through the network and reaches the UE, the satellite has already moved and the geometry has changed. Release 17 divides the timing problem into multiple components.
Service-link timing
The UE calculates the service-link contribution itself, combining satellite ephemeris from SIB19 with its own known position to determine the propagation path between the UE and satellite. This represents the largest and most rapidly changing component of the timing correction.
Feeder-link timing
The UE cannot calculate the feeder link independently because it does not know the gateway location. The network therefore supplies the feeder-link contribution through ta-Common, along with a linear drift term and a quadratic drift term. This allows the UE to evaluate the feeder-link timing correction as a function of elapsed time instead of treating it as a fixed value.
Closed-loop timing
After the predictable satellite geometry has already been compensated, the normal network timing loop handles the remaining residual error. Instead of asking closed-loop control to correct the entire satellite path, Release 17 removes most of the deterministic error before transmission.
K_offset: scheduling for a satellite path
Timing compensation alone is not sufficient. The scheduler must also understand that an uplink response cannot arrive according to normal terrestrial timing relationships. SIB19 therefore carries K_offset, which changes the relationship between an uplink grant and the corresponding UE transmission so that the scheduler does not expect the response before satellite propagation makes it physically possible.
For Release B the value is derived from the worst-case propagation delay across the satellite's visibility period. The orbit is sampled to determine that delay instead of assuming a fixed value, which becomes increasingly important in LEO because the satellite geometry changes throughout the pass.
Doppler has a different responsibility split
Timing and Doppler are both consequences of satellite geometry, but Release 17 does not divide their compensation responsibilities in the same way. For Doppler, the UE pre-compensates the service link while the network handles the feeder link and any transponder-related frequency error.
The Release B channel follows that model directly: delay is applied for both satellite-path legs, but Doppler is applied only for the service leg.
This asymmetry proved important during development. An earlier implementation applied Doppler to both legs. The UE then attempted to compensate for a frequency error that was not its responsibility, its timing loop began reacting to the resulting mismatch, and the connection failed to complete. The solution was not to modify the 5G protocol procedure. The error was in the channel model: the channel must apply exactly the impairment that the UE is expected to observe at the air interface, no more and no less. This demonstrates an important property of protocol-level simulation. A more complicated channel model is not necessarily a more correct channel model.
In LEO, time itself becomes part of the model
Moving the satellite introduced another issue that does not exist in the same form for GEO. A ZMQ-based radio link has no physical RF clock. Without pacing, the gNB and UE can exchange samples as quickly as the host CPU can process them, so the radio simulation can run faster than real time. For a static channel that can be acceptable. For a moving satellite it breaks the model.
The satellite orbit is propagated from system time, while radio procedures advance according to radio-frame time. If the sample stream runs faster than real time, those two clocks diverge. The network may broadcast an ephemeris corresponding to one physical instant while the sample stream has already advanced to another, and the channel and network then disagree about where the satellite is. In testing this appeared as a frequency discontinuity at system-information updates, until the downlink could no longer be decoded.
Real-time pacing
Release B therefore adds real-time pacing to the gNB transmit path. Each block of samples is held until its timestamp becomes due according to the system clock. This forces the sample stream to advance at the configured sample rate and keeps orbital time, radio-frame time, channel geometry and SIB19 ephemeris on the same time base.
The pacing mechanism intentionally uses a single origin captured at the beginning of the run. Every subsequent deadline is derived from that original reference rather than from the previous sample block, which prevents small scheduling errors from accumulating continuously. If the host cannot maintain real time, the implementation does not add further delay by sleeping; instead it records the deficit, and at shutdown the gNB reports how closely real-time operation was maintained. A run that could not sustain the required rate is therefore visible rather than silently producing unreliable satellite geometry.
Why Release A and Release B use different pacing strategies
This produces an important contrast with Release A. During GEO development, wall-clock pacing proved to be the wrong approach; the successful architecture was demand-paced, allowing the UE and gNB slot clocks to control movement of the sample stream. Release B reaches the opposite conclusion. That is not a contradiction. It reflects the difference between GEO and LEO.
In GEO, the satellite does not move relative to the user. The important requirement is that the sample stream remain internally aligned and that the configured propagation delay stays exact. The system does not need orbital geometry to evolve against wall-clock time.
In LEO, the satellite is continuously moving and its position is explicitly a function of time. The channel, network and UE must therefore agree not only on the orbit, but also on what time it currently is within that orbit. In GEO the sample stream needs to be internally consistent. In LEO, real time has to be real.
The connection sequence
Once satellite timing and frequency compensation are in place, the rest of the procedure remains standard 5G NR, with SIB19 as the satellite-specific addition. The end-to-end sequence is:
- Cell acquisition. The UE finds the cell and decodes MIB and SIB1.
- SIB19 acquisition. The UE receives satellite ephemeris,
ta-Common,K_offsetand the associated epoch. - Timing calculation. The UE calculates satellite timing compensation from the service-link geometry and network-provided feeder-link information.
- Doppler calculation. The UE calculates service-link Doppler pre-compensation.
- Random access. The PRACH transmission is pre-compensated in both time and frequency.
- RRC connection setup.
- NAS registration.
- Security and capability exchange.
- PDU session establishment.
- End-to-end user traffic through the tunnel interface.
Random access is the critical transition. Without satellite-aware pre-compensation the uplink preamble arrives approximately 8 milliseconds away from where the gNB expects it, and that error is too large for the normal correction procedure to recover. Pre-compensation moves the transmission into the timing and frequency region where ordinary NR procedures can take over.
End-to-end result
Release B demonstrates a complete 5G Standalone connection operating through a moving 600 km LEO satellite model. The system successfully combines live orbital propagation, SIB19 ephemeris distribution, continuously changing propagation geometry, UE timing pre-compensation, feeder-link timing information, K_offset-based scheduling adaptation, service-link Doppler pre-compensation, real-time sample pacing, random access, RRC and NAS procedures, PDU session establishment and user-plane traffic.
The important result is not simply that delay and Doppler can be inserted into a packet path. They are applied at the baseband level while the network and UE independently calculate the satellite state required to compensate for them. The connection succeeds because the protocol state, orbital state, radio-frame state and channel state remain consistent with one another while the satellite moves.
Why this matters
NTN validation has traditionally depended on resources that are difficult for most developers and researchers to access: satellite capacity, RF equipment and specialised satellite channel emulators. Release B moves this class of testing into software. A complete 5G connection can operate through a moving satellite model on a single machine.
The RAN remains the full OCUDU stack. The UE remains a full NR implementation rather than a purpose-built NTN traffic generator. The channel is driven from the same underlying orbital state used by the network and device, so the geometry is internally consistent rather than approximated independently. That means engineers can directly observe and modify satellite ephemeris handling, timing and Doppler compensation, NTN scheduling, random access, radio procedures under moving geometry, and the interactions between orbital dynamics and the 5G protocol stack, using the same RAN and UE software being exercised by the testbed.
From a satellite link to a constellation
Release A established GEO NTN. Release B establishes the moving single-satellite LEO case: a UE can now acquire a moving satellite, establish the 5G connection and pass traffic while satellite geometry changes. That creates the foundation for the next problem. The satellite eventually disappears below the horizon, and at 600 km the modelled pass lasts approximately thirteen minutes, so continuous service requires the UE to transition from one satellite to another.
The next stage of the programme addresses satellite handover. That requires completing the relevant UE-side behaviour and modelling the timing and geometry discontinuity introduced when the active satellite changes. Beyond handover lies another architectural step: regenerative NTN, where the base-station functionality moves onto the satellite instead of remaining entirely on the ground. Further work also extends into the operational requirements needed for a real satellite network, including determining where a device is located, associating it with the appropriate jurisdiction and selecting the appropriate core-network path.
The longer-term destination is a software-based NTN digital twin, modelling a complete satellite constellation propagated from orbital data, with satellites rising, moving and setting, devices transitioning between them, and real network software operating against that geometry. At that point the platform is no longer only a way to verify whether an NTN implementation works. It becomes an environment for investigating how an NTN constellation should operate.
Release 17 NTN under motion
Release A demonstrated why satellite-scale delay must be exercised rather than assumed. Release B extends that principle. In LEO the network cannot merely know that a satellite exists. It must know where the satellite is, how fast that geometry is changing, what part of the resulting timing and Doppler each component is responsible for, and what instant every calculation refers to. The satellite model, RAN, UE and sample stream must remain synchronised throughout the connection. That is what Release B validates.
A complete 5G Standalone connection can now operate through a moving LEO satellite using open software components, on a single machine, without requiring satellite capacity or radio hardware. With the single-satellite moving case established, the next problem becomes unavoidable: keeping the connection alive when the satellite changes.
Availability
- Demo: youtu.be/g-ADyBkNKUQ
- Technical documentation: LEO NTN Testbed
- OCUDU RAN: github.com/TOSSI-Foundation/OCUDU-RAN (branch
ntn) - OAI UE: github.com/TOSSI-Foundation/OAI-RAN (branch
develop)