Non-Terrestrial Networks are becoming an important part of the evolution of 5G and future 6G systems, but validating NTN behaviour has traditionally required satellite capacity, RF equipment or specialised channel emulators. We are releasing an end-to-end GEO NTN testbed that runs a complete 5G Standalone network over a simulated geostationary satellite link, on a single machine, with no radio hardware, no satellite capacity, and no dedicated channel-emulation equipment.
The testbed brings together OCUDU RAN with 3GPP Release 17 NTN support, an OAI UE Simulator communicating through ZMQ, a sample-exact bidirectional channel-delay relay, and a 5G Standalone core, all running on a single machine. The environment models approximately 120 milliseconds of one-way GEO propagation delay and lets the complete 5G procedure be exercised under realistic satellite-scale timing conditions.
Why GEO NTN Testing Is Different
A geostationary satellite operates approximately 35,786 kilometres above the equator and appears fixed relative to a location on Earth. This provides very wide geographical coverage, but the distance introduces a significant propagation delay: a signal takes roughly 120 milliseconds to travel in each direction, and the resulting application-level round-trip time can approach half a second.
Terrestrial 5G networks are designed around relatively short propagation delays. Satellite-scale timing therefore affects several important procedures, including random access, timing advance, uplink scheduling, HARQ timing, RLC retransmissions, RRC signalling, NAS procedures, PDU session establishment, and end-to-end user-plane performance.
3GPP introduced NTN support in Release 17 to address these requirements. But implementing NTN parameters in software is not enough. The complete system must be tested under conditions where the propagation delay is genuinely present throughout the protocol stack. The objective of this testbed is therefore to exercise Release 17 NTN timing mechanisms rather than simply assuming that they work.
End-to-End NTN Testbed Architecture
The testbed consists of an OCUDU gNB, an OAI UE Simulator and a 5G core network running on a common host. The gNB and UE exchange baseband IQ samples over TCP sockets using the ZMQ interface, and a custom channel relay is inserted directly into the sample path between them.
This architecture introduces the satellite propagation delay at the baseband level instead of adding artificial latency only at the IP or application layer. The OAI UE Simulator's native ZMQ support is a key enabler: it allows a processing component to be inserted transparently between the UE and gNB while preserving the overall RAN and UE software architecture.
Modelling GEO Delay as a Sample Backlog
The channel relay models propagation delay by maintaining a fixed backlog of IQ samples in both directions. At a sample rate of 15.36 Msps, the relay stores 1,848,576 samples per direction, representing approximately 120.35 milliseconds of one-way delay.
The relay does not depend on timestamps or the host operating system's clock. Instead, the configured delay is represented directly by the number of samples held inside the buffer:
Output sample k = Input sample k − Configured delay
This approach ensures the delay remains sample-exact and consistently affects the physical-layer and higher-layer procedures.
Demand-Paced Channel Relay
One of the most important design decisions was to make the relay demand-paced rather than wall-clock-paced. The relay sends one block of samples whenever the receiving gNB or UE requests one, so pacing is controlled by the existing slot clocks of the gNB and UE.
A conventional throttled flowgraph introduces an additional clock based on the host wall clock. Because this third clock is not synchronised with the UE and gNB, small timing differences can accumulate and eventually disturb sample alignment. During comparative testing:
- The wall-clock-throttled relay produced 70 Msg3 CRC failures out of 70 attempts.
- Uplink SINR fell between approximately −13 dB and −29 dB.
- The gNB reported repeated RF overflow events.
- The demand-paced relay achieved 77 successful Msg3 CRC decodes out of 78 attempts.
- No RF overflow events were observed with the demand-paced architecture.
PRACH could survive both approaches because its long cyclic prefix provides additional tolerance. PUSCH demodulation, however, requires much tighter sample-level timing and failed when the relay introduced clock drift.
Maintaining Stream Alignment
In a sample-based NTN emulator, silently adding or losing even one sample can permanently change the configured propagation delay. The relay therefore maintains a strict stream-alignment invariant through three mechanisms:
- The serving process blocks until real sample data is available instead of inserting padding.
- A serving-credit mechanism prevents the prefilled delay buffer from being drained.
- A shift counter reports sample movement in both directions.
The expected shift value is +0. Any non-zero value would indicate that the sample stream has moved and that the configured propagation delay is no longer being applied accurately. This makes timing drift visible and measurable rather than allowing it to remain hidden inside the test environment.
3GPP Release 17 NTN Configuration
The GEO NTN cell operates using band n256, a 10 MHz channel bandwidth, 15 kHz subcarrier spacing, a cell-specific K-offset configured to 240 slots, satellite ephemeris broadcast through SIB19, UE-side timing-advance pre-compensation, UE-side Doppler pre-compensation, HARQ feedback disabled for GEO operation, and RLC ARQ configured for long round-trip timing.
The satellite ephemeris is broadcast as an Earth-Centred, Earth-Fixed state vector. The UE combines this with its GNSS position to calculate the required timing and Doppler corrections. For the GEO profile, HARQ feedback is disabled and RLC ARQ is used for retransmission, with RLC timers and retransmission thresholds increased to accommodate satellite-scale round-trip times. Without these changes, the transmitter would spend a large amount of time waiting for acknowledgements that cannot return within terrestrial timing assumptions.
Why the Cell Uses 10 MHz
Testing also identified an important bandwidth-related behaviour. At 5 MHz bandwidth, corresponding to 25 resource blocks, the scheduling-request PUCCH resource was placed on the uppermost resource block and was not decoded successfully. The UE eventually exhausted its scheduling-request attempts, released its PUCCH resources and lost the ability to request an uplink grant, so the connection stalled before the security procedure could complete. Operating the cell at 10 MHz avoided this issue and enabled the complete end-to-end procedure to succeed.
Scheduler Defects Revealed by Satellite-Scale Timing
The GEO testbed exposed three software defects that were not visible under normal terrestrial timing conditions.
1. Uplink grants blocked by in-flight HARQ processes
Pending uplink data was calculated after subtracting all bytes associated with active HARQ processes. Under GEO timing, HARQ processes remain in flight much longer than in a terrestrial network, so the pending-byte calculation reached zero and prevented the gNB from issuing another uplink grant. The condition could become self-sustaining: the UE could not transmit, the gNB could not receive the corresponding CRC, and the HARQ process remained active.
2. Incorrect PUSCH resource-block accounting
PUSCH allocations were recorded using the NTN-adjusted transmission slot, but the resource-counter clearing process did not include the NTN K-offset, so the scheduler read stale resource information from an earlier cycle.
3. Missing maxMIMO-Layers in RRC encoding
The extension flag in the PDSCH-ServingCellConfig structure was evaluated before all extension fields were populated. As a result, maxMIMO-Layers was omitted from the encoded configuration, leading to an assertion in the UE.
All three issues were corrected in the OCUDU RAN implementation rather than being bypassed using testbed-specific configuration workarounds.
End-to-End Results
The testbed successfully completes the full 5G Standalone procedure over the simulated GEO link: cell search, system-information acquisition, SIB19 acquisition, random access, RRC connection setup, NAS authentication, security activation, PDU session establishment, operator-assigned IP address allocation, and end-to-end user-plane traffic.
The measured 510 ms average round-trip time is consistent with GEO propagation combined with radio scheduling and protocol-processing delays. This is an important result because it confirms the delay is genuinely experienced across the complete network rather than being approximated above the physical layer.
What This Release Unlocks
The testbed provides a reproducible environment for Release 17 NTN protocol validation, GEO satellite timing validation, NTN scheduler development and optimisation, random-access testing under long propagation delays, timing-advance and K-offset verification, HARQ and RLC behaviour analysis, SIB19 and ephemeris validation, satellite-aware UE development, NTN regression testing on commodity hardware, reproduction of defects that appear only at satellite scale, integration testing between independently developed RAN, UE and core components, and development of future satellite 5G and direct-to-device use cases.
The complete environment is open-source and can run on a single host without requiring satellite bandwidth, SDR hardware or a dedicated channel-emulation platform.
Release A: GEO NTN
This is the first release in a two-part NTN testbed series. Release A focuses on the geostationary case, where the propagation delay is large but relatively constant. Starting with GEO is deliberate: a constant-delay model allows the Release 17 timing mechanisms to be validated while isolating the propagation-delay variable. Before moving to a dynamic satellite environment, mechanisms such as cell-specific K-offset, common timing advance, SIB19 processing, ephemeris-based timing pre-compensation, Doppler pre-compensation, HARQ adaptation, RLC retransmission handling, and long-delay scheduler operation must work correctly.
Next Release: LEO NTN
Release B will extend the same testbed architecture to Low Earth Orbit. Unlike GEO satellites, LEO satellites move continuously relative to the user, which introduces continuously changing propagation delay, dynamic Doppler shift, satellite trajectory modelling, timing and Doppler pre-compensation updates, satellite visibility windows, satellite handover, and beam and mobility management. The next release will add a satellite-motion model to the channel relay while retaining the existing OCUDU RAN, OAI UE Simulator and 5G core architecture.
Availability
- Demo Video: NTN E2E Testbed :Release A - GEO NTN with OCUDU RAN and OAI UE Simulator
- GitHub: TOSSI-Foundation/OCUDU-RAN (ntn branch)
- Documentation: GEO NTN Testbed (TOSSI Docs) · NTN: An Introduction