Satellite Non-Terrestrial Network (NTN) features are now live in the main branch of OCUDU. We sat down with Justin Tallon and Piotr Gawłowicz from SRS to hear what went into bringing 3GPP NTN Release 17 support to the CU/DU stack, how you can start using it today, and what’s coming next.
Let’s start with introductions. Please introduce yourself and what do you focus on?
Justin: I’m Justin Tallon, NTN Manager at SRS. I’ve been with SRS for ten years, and my focus is NTN from both the technical and the business side.
Piotr: I’m Piotr Gawłowicz, and I’ve been at SRS for four years, working specifically on NTN. With Justin, we started with 4G and are now working on 5G.
Justin: Piotr and I have both worked extensively on NTN for many years starting with proprietary enhancements to 4G where we supported the first ever satellite direct-to-cell (DTC) phone call. That success gave us a practical understanding of challenges with space based cellular connectivity and a stronger understanding of what has come to be the 3GPP 5G NTN standard. While 5G utilizes a wholly different architecture our learnings gave us the insight we needed to implement the standard 5G NTN features now part of OCUDU.
For readers new to the topic, what is 5G NTN?
Justin: In a cellular radio access network (RAN) base station context, NTN gives the RAN the ability to communicate with a phone or other user equipment (UE) using a satellite link. The enabler for the user is connectivity anywhere on the planet. But the technical challenge is about overcoming the channel impairments that come with a satellite link: long delays, large Doppler shifts, and the attenuation that comes with enormous distances.
What makes that so much harder than a terrestrial base station?
Piotr: The biggest challenge is that low earth orbit (LEO) satellites move at around 7.5 kilometers per second (16,777 miles per hour!). That creates a constantly changing frequency shift (Doppler shift) as the satellite moves toward and away from the UE of up to 50 kHz on a 2 GHz carrier, and a round-trip time between the UE, the satellite, and the gNodeB that changes very rapidly based on the changing slant distance. The channel is constantly shifting. In our LTE work, all of that had to be handled on the network side. In 5G NTN, 3GPP pushed most of the responsibility for pre- and post-compensating the channel onto the UE, but the network still has a lot of work to do to support it.
What’s in the current release
So what’s actually being added to OCUDU for 26.10?
Justin: First I’ll point out that the features we’re discussing are slightly ahead of schedule and already checked into mainline OCUDU. At a high level, we’ve added NTN Rel 17 support, which breaks down into roughly 15 to 20 sub-features spread across every layer of the stack. Starting at the bottom, the PHY adds Doppler compensation for the feeder link. In the MAC, there are scheduling delays that need to be accounted for, and the HARQ processes used for fast error correction have been modified to cope with the long delays. Moving up to RRC, there’s a new system information block, SIB19, which carries the satellite and channel information the UE needs over the broadcast channel.
Does NTN change the core functionality of the RAN?
Justin: Not really. It doesn’t change what the RAN is or how it works. It gives the existing capabilities the means to overcome the new challenges of an NTN channel. Every part of the stack is touched to some degree. In some places that’s just a matter of extending buffers and timers to deal with the delay; in others, the modifications are extensive but only enabled when running in NTN mode.
The biggest addition is a module that sits somewhat outside the stack: the orbital compute module. It populates the broadcast fields with orbital information and can inject real-time updates directly into the MAC over a WebSocket. It’s a key feature for handling the complexity of orchestrating and adapting to the constantly changing topology of the network with the goal of creating a seamless connection for the user equipment.
Getting started
Once someone pulls the latest OCUDU, how do they take advantage of NTN?
Justin: The best place to start is our NTN application note. It’s a step-by-step tutorial that walks you through setup with whatever gear you happen to have. You can choose LEO or GEO orbits and pick your emulator, whether that’s an internal software emulator or, for GEO, a GNU Radio–based emulator. It’s written so that someone who knows nothing about NTN can follow it and get a working connection. I often get contacted with setup questions, and they’re invariably answered in that app note.
Piotr: Alongside the tutorial, we provide a Python script that generates the configuration parameters for the NTN feature the stack supports. You give it a TLE file, add options for the features you want, such as mapped cell IDs based on UE location or predefined geographic cells that are independent of the broadcast cell IDs, and it generates the configuration for you.
One nice aspect is that you can mix terrestrial and non-terrestrial cells within the same DU, which could be useful for scenarios like handover between TN and NTN cells. From the gNodeB side, you’re ready to go immediately.
What additional equipment will I need to exercise the NTN features?
Justin: You need an NTN-capable UE and an NTN channel emulator. Both tend to be expensive today. Some open-source solutions are emerging, though they aren’t yet fully compliant. In the tutorial we use GNU Radio to implement a simple delay based channel emulator using ZMQ to transfer in/out raw IQ samples. We then connect that to a proprietary 5G NTN UE emulator, for a simple GEO demonstration. For the LEO demonstration, we use the NTN channel emulator built into the UE emulator to model the rapidly changing delay and Doppler.
What has the implementation been tested against?
Justin: The tutorials use Amarisoft UEs, and the implementation has also been exercised with 3rd party UE test equipment and with pre-silicon development platforms from chipset vendors, by us and by partners. We look forward to expanding test coverage as more UE options become available.
Live over-the-air testing
Are there any live satellite demonstrations you can talk about?
Justin: We’ve been developing 5G NTN features for some time and some of the base code was demonstrated as part of TRANTOR, a Horizon Europe Space program we recently completed, led by CTTC, a research center here in Catalonia Spain. We ran many in-orbit tests using a Ka-band link over a Hispasat GEO satellite, and we ran a 10 MHz 5G NTN carrier over that link on and off for about two and a half years.
We even held our TRANTOR final review meeting over the satellite link: the project coordinator routed his call through it, so while he was presenting to the reviewers, he could tell them it was going over the satellite. There was a small amount of lag from the GEO latency, but overall it worked well. Additionally we demoed the link at MWC, where it ran on both the Hispasat and CTTC booths. Our project colleagues were walking around the show floor with it running on his iPad, showing attendees.
Piotr: This effort is also fueling continued work through other SNS JU projects including Stardust, which just completed, Nexasphere and Unity-6G which are all using various aspects of the OCUDU NTN capabilities.
And what’s next on that front?
Justin: We’ve started work on 3GPP Release 18 features for the next major OCUDU update (27.04), due in April 2027. Those features will be more centered around regenerative payload support. We’re also exploring Integrated Access and Backhaul (IAB). With IAB, a 5G base station node mounted on a moving vehicle, such as a plane or train, can connect back to the network over a 5G satellite (NTN) link. That one satellite connection can then serve everyone on board treating the node as though it was a single user.
Looking ahead: Release 18 and beyond
The roadmap shows Release 18 features landing later in OCUDU 27.04. What’s changing?
Justin: The way I’d summarize it: Release 17 is about establishing a basic NTN link. Release 18 adds what’s needed to make it truly deployable. Release 19 then starts addressing the questions raised by regenerative payload architectures, things like feeder link switchover and CU/DU handover across the F1 interface, which Release 18 barely touches and Release 19 fleshes out properly.
Piotr: Conditional handover is another important one for Release 18, especially for coordinating a satellite RAN. The basics are already in OCUDU today, but Release 18 added trigger conditions which make the feature more useful.Instead of issuing a handover command at runtime, the handover can be prepared in advance and executed by CHO once predefined conditions are met. Although satellites move very quickly, their trajectories are highly predictable, so their position at any given time can be calculated very precisely. This makes it possible to prepare the UE to switch at exactly the right moment.
Justin: Features like conditional handover and satellite switch are what really come into play when you try to deploy, not just test in a lab. That’s why we prioritized them. We want OCUDU’s NTN support to be as deployable as possible, as quickly as possible.
What 3GPP leaves undefined
What does 3GPP leave out of the spec and up to the integrator or deployer of the RAN?
Justin: The biggest one is what TS 38.300 calls the NTN control entity. It gets an annex at the back of the document with maybe five or six bullet points on what it should do. It’s very vague, yet it’s arguably the single biggest piece of work we had to complete to make a functional NTN RAN. Everyone building this will have done some version of it in their own way. Ours is included in OCUDU and part of the orbital compute module.
Piotr: A LEO satellite spends only about five minutes over a given UE, so there are constant handovers. Orbits also precess, which means the orbit slowly shifts or rotates over time relative to the ground. The net result is that no two satellites travel exactly the same ground path, so you can’t assume the beam patterns or doppler shift repeat over time. Therefore, satellite RAN operation is going to be a big topic. We’re providing all the building blocks from the gNodeB perspective, but you still need an O&M (Operation and Maintenance) module or control entity to orchestrate them, and that control strategy has to be tailored to your constellation: how many satellites, how dense, how you plan to operate.
Justin: We built a basic O&M module which is required for even the most basic testing as a starting point. It works well for improving the OCUDU out-of-box experience. However, in real deployments, operators may use all of it, parts of it, or none of it, and that integration will likely be custom for everyone.
Final thoughts
Any final thoughts for developers building NTN systems?
Justin: What we’ve built into OCUDU is best-in-class capabilities for NTN and they’re actively being tested by us, our partners, and some are even in the early stages of production deployment. What we’ve learned is that while OCUDU provides the fundamental building blocks, the integration between the orchestrator and the RAN will decide whether your constellation works or not. It’s not a single pipe. It’s about knitting all these capabilities into the right hooks seamlessly: providing orbital data, triggering handovers through specific APIs, and so on. That’s the whole ball game.
Piotr: With Release 17 capability now in mainline OCUDU we’re starting to collect feedback from users and begin work on Release 18. There are still many implementation and operational decisions that are not fully defined by the standard. While 3GPP specifies the NTN link and the basic procedures, it leaves many questions open when it comes to operating and orchestrating a complete satellite RAN in practice. We’re providing all the building blocks from the gNodeB perspective, but ultimately feedback and contributions from the community is essential to refine these operational aspects and take NTN capabilities to the next level.
Any specific requests for the community?
Justin: Good testing partners are key. Many of the 3GPP Release 18 features aren’t supported by the UEs we typically use, so we’re looking for testing partners and access to more commercial NTN-capable UEs. If you’re working on NTN UEs or test equipment and want to collaborate, we’d love to hear from you. The best way to reach out is by creating an issue or question on the OCUDU discussion board.
