LEO NTN Testbed: 5G NR over a Moving Satellite
A working 5G NR connection over a simulated low-Earth-orbit satellite link. This is Release B of the TOSSI NTN testbed.
Introduction
Non-terrestrial networks extend 5G coverage to areas without ground infrastructure, using a satellite in place of a base station tower. 3GPP standardised this in Release 17.
Release A established the foundation using a geostationary satellite. A GEO satellite orbits at 35,786 km and remains in a fixed position relative to the ground. The round-trip delay is approximately 480 milliseconds, well beyond what terrestrial 5G assumes, but it does not change over time. Release A demonstrated that the OCUDU RAN and the OAI UE could interoperate and complete a connection under those conditions.
Release B extends the work to low Earth orbit. A satellite at 600 km gives a round-trip delay of approximately 8 milliseconds, but it travels at 7.5 kilometres per second. This introduces three conditions that a geostationary link does not have:
- the distance between the satellite and the device changes continuously, so the propagation delay changes with it;
- the relative motion produces a Doppler shift of tens of kilohertz on the carrier frequency; and
- a single satellite remains within view for only a few minutes.
The network and the device must therefore track the satellite's motion continuously, and both must use the same position for the same instant.
This release provides a 5G connection over a moving satellite, with propagation delay, rate of change of delay, and Doppler shift applied to the baseband sample stream. The connection completes through random access, RRC setup, NAS registration and a PDU session carrying user traffic.
Network architecture
Release 17 specifies a transparent payload architecture. The satellite acts as a relay and the base station remains on the ground, connected to the satellite over a feeder link.
[ gNB + gateway ] ---- feeder link ----> [ satellite ] ---- service link ----> [ UE ]
ground 600 km ground
7.5 km/s
The signal crosses two legs in each direction, from the gateway to the satellite and from the satellite to the device. Both legs contribute to the total propagation delay.
The following table compares the relevant properties against a terrestrial cell.
| Property | Terrestrial cell | LEO NTN |
|---|---|---|
| Round-trip delay | under 70 microseconds | approximately 8 milliseconds |
| Change in delay | negligible | approximately 11 microseconds per second |
| Doppler shift | under 1 kilohertz | tens of kilohertz |
Implementation
The testbed consists of four parts. Three run as separate processes and the fourth runs inside one of them.
The two stacks exchange baseband samples over ZMQ sockets, so no radio hardware is required.
The orbit model
The satellite is defined by a state vector at a reference time, consisting of its position and velocity in earth-centred coordinates. The position at any later time is obtained from a closed-form circular-orbit calculation.
A single orbit model supplies all components. The same state vector produces both the ephemeris that the gNB broadcasts in SIB19 and the geometry that the channel model applies. If the two were to differ, the device would compensate for a link other than the one in use.
Timing
Over a satellite link, a timing correction sent by the network is already out of date by the time it reaches the device. The timing advance is therefore composed of three parts, each obtained from a different source:
| Part | Who computes it | How |
|---|---|---|
| Service leg | the device | from the ephemeris in SIB19 and its own position |
| Feeder leg | the network | broadcast as ta-Common with drift terms |
| Residual | the network | closed-loop commands in the random-access response |
SIB19 also carries K_offset, which adjusts the scheduling relationship between an uplink grant and the corresponding transmission. Without it, the scheduler would expect a response before the round trip has completed. Its value is derived from the worst-case delay across the satellite's period of visibility.
Doppler
Release 17 divides Doppler compensation between the device and the network. The device pre-compensates the service link using the ephemeris, while the feeder link is compensated at the gateway and does not appear on the air interface.
The channel model follows this division. Delay is applied for both legs, and Doppler is applied for the service leg only.
The channel model
The channel model runs inside the UE's ZMQ device driver, which allows it to operate on the sample stream without an additional process or transport hop. For each block of samples it evaluates the orbit once and applies the result:
- Downlink: the stream is delayed by reading from sample history at an offset and is rotated by the current Doppler shift.
- Uplink: the transmit timestamp is advanced by the delay and the samples are rotated by the uplink Doppler shift.
The delay increases as the satellite moves away from the device. The channel model maintains continuity of the sample stream as this occurs.
Real-time pacing
A ZMQ link has no hardware clock, so by default both endpoints exchange samples as quickly as they can be processed. Stream time then advances faster than real time, and the satellite position, which is propagated from the system clock, no longer corresponds to the timestamps being broadcast.
Release B introduces pacing on the gNB transmit path. Each block of samples is held until its timestamp is due according to the system clock, so the stream advances at the configured sample rate and all components share a common time reference.
Pacing is enabled by including realtime in the radio device arguments. The gNB reports at shutdown how closely real time was maintained.
Connection flow
The message sequence follows standard 5G NR procedures. SIB19 is the only satellite-specific addition. The remaining signalling is unchanged, and operates with satellite-scale timing values.
- Device finds the cell and decodes MIB and SIB1.
- Device decodes SIB19, carrying ephemeris,
ta-Common,K_offsetand epoch. - Device computes the timing advance: service leg plus feeder leg.
- Device computes Doppler for the service leg only.
- Random access, with the preamble pre-compensated in time and frequency.
- RRC setup:
rrcSetupRequest,rrcSetup,rrcSetupComplete. - NAS registration: authentication and security through the core.
- Security and capabilities:
securityModeCommand,ueCapabilityEnquiry. - PDU session:
rrcReconfiguration, bearer established. - User traffic: IP over the tunnel interface.
Because the core network sees a conventional NR cell, it needs no satellite awareness and runs unmodified.
Deployment and running
Requirements
- a Linux host with a recent GCC or Clang toolchain;
- CMake and the usual build dependencies for both projects;
- a 5G core network reachable from the host. The shipped configuration targets SD-Core; any Release 15 or later core providing AMF and UPF may be used; and
sudo, which the device needs to create its tunnel interface.
1. Build the RAN
git clone -b ntn https://github.com/TOSSI-Foundation/OCUDU-RAN.git
cd OCUDU-RAN
mkdir build && cd build
cmake ..
make -j$(nproc) gnb
This produces the gNB at build/apps/gnb/gnb.
2. Build the device
git clone -b develop https://github.com/TOSSI-Foundation/OAI-RAN.git
cd OAI-RAN/cmake_targets
mkdir -p ran_build/build && cd ran_build/build
cmake ../../.. -DOAI_ZMQ=ON
make -j$(nproc) nr-uesoftmodem oai_zmqdevif
-DOAI_ZMQ=ON is required. Without it the ZMQ radio and the satellite channel model are not built. This produces nr-uesoftmodem and liboai_zmqdevif.so in the build directory.
3. Configure the core
Edit configs/ntn/leo/leo_600km_amf.yml in the OCUDU repository and set the AMF address, the local bind address, and the tracking area and slice values to match your core network. The shipped values target an SD-Core deployment.
Provision the subscriber in your core. The identity, key and operator code are in configs/ntn/leo/leo_600km_ue.conf; either match your core to those values or change the file to match your core.
4. Run
cd OCUDU-RAN/configs/ntn/leo
OAI_DIR=/path/to/OAI-RAN ./run_leo.sh
OCUDU_DIR is detected from the script location. OAI_DIR must point at the root of the OAI repository; both build layouts are recognised automatically.
The script stamps the current time into both configurations, starts the gNB, starts the device, and reports the outcome:
RESULT pbch=1 sib1=15 sib19=15 prachtx=2 prachrx=2 ra=1 nas=1 ip=10.0.0.39
PRACH ta: ta=48.44us ta=0.00us
PACING real-time pacing: 553 of 38711 transmit blocks were late (1.4%)
LOGS /tmp/leo_run/gnb.log /tmp/leo_run/ue.log
An IP address on the last field means the connection completed. The script exits zero on success and one otherwise, so it can be used in automated testing.
Useful settings: GNB_SECS, UE_SECS and WAIT_SECS control run length; OUT sets the output directory; GNB_EXTRA and UE_EXTRA pass additional arguments.
Running without the script
The launch is two commands. The epoch must be stamped in both configurations first, because the satellite position is propagated from it:
NOW=$(date -u '+%Y-%m-%dT%H:%M:%S'); NOW_UNIX=$(date -u -d "$NOW" +%s)
sed -i "s/epoch_timestamp: '[^']*'/epoch_timestamp: '$NOW'/" leo_600km_gnb.yml
sed -i "s/ntn_epoch = .*/ntn_epoch = ${NOW_UNIX}.0;/" leo_600km_ue.conf
gnb -c gnb_zmq_10mhz.yml -c leo_600km_gnb.yml -c leo_600km_amf.yml
sudo nr-uesoftmodem -O leo_600km_ue.conf --band 256 -C 2185000000 \
--CO -190000000 -r 52 --numerology 0 --ssb 62 --initial-fo -6302 \
--cont-fo-comp 3 --time-sync-I 0.1 --ntn-initial-time-drift 5.77 \
--device.name oai_zmqdevif
Start the device about eight seconds after the gNB.
Other orbits
The shipped configuration describes a 600 km orbit. ntn_orbit.py regenerates every derived value for a different altitude or ground location:
from ntn_orbit import CircularOrbit, NtnChannel, geodetic_to_ecef
lat, lon = -2.2817, 131.7327
orbit = CircularOrbit(600e3, lat, lon, 0.0)
ground = geodetic_to_ecef(lat, lon)
channel = NtnChannel(orbit, ground, gateway_ecef=ground)
orbit.ephemeris_at(0.0) # state vector for both configs
NtnChannel(orbit, ground).doppler_hz(10.0, 2185e6) # acquisition frequency offset
channel.one_way(10.0) # delay, for K_offset and drift
The satellite state vector must be identical in the gNB configuration and the device configuration.
Roadmap
Release B is the second stage of the NTN testbed programme. Each stage builds on the previous one, holding the same certification and interoperability approach while adding the next piece of satellite behaviour.
References
3GPP specifications
| Document | Title | Relevance |
|---|---|---|
| TS 38.300 | NR and NG-RAN Overall Description | Clause 16.14 defines NTN operation and the split of Doppler responsibility |
| TS 38.331 | Radio Resource Control protocol specification | SIB19 contents: ephemeris, ta-Common, K_offset, epoch time |
| TS 38.213 | Physical layer procedures for control | Clause 4.2 defines the timing advance, including the NTN common terms |
| TS 38.211 | Physical channels and modulation | Clause 6.3.3 defines PRACH preamble generation |
| TS 38.321 | Medium Access Control protocol specification | Clause 5.4.4 covers timing advance maintenance |
| TR 38.821 | Solutions for NR to support non-terrestrial networks | Study item behind the Release 17 NTN work |
3GPP NTN overview: 3gpp.org/technologies/ntn-overview. Specifications are available from the 3GPP portal.
Source repositories
| Repository | Branch | Contents |
|---|---|---|
| TOSSI-Foundation/OCUDU-RAN | ntn | OCUDU RAN with NTN support, real-time pacing, and the LEO testbed |
| TOSSI-Foundation/OAI-RAN | develop | OAI UE with the NTN timing corrections and the satellite channel model |