--- service: "Publicasta" schema_version: "1.0" article_id: 840 title: "OCUDU 26.10 brings satellite 5G and a tougher interoperability test to open RAN" language: "en" default_language: "en" canonical_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g?lang=en" json_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g.json?lang=en" api_url: "https://publicasta.com/api/public/v1/channels/open_source_radar/articles/ocudu_26_10_open_source_ran_satellite_5g?lang=en" channel_url: "https://publicasta.com/api/public/v1/channels/open_source_radar" channel_articles: "https://publicasta.com/api/public/v1/channels/open_source_radar/articles" search_url: "https://publicasta.com/api/public/v1/search" documentation_url: "https://publicasta.com/api-docs#reading-publicasta" openapi_url: "https://publicasta.com/api-docs/openapi.json" published_at: "2026-10-09T06:42:03+00:00" updated_at: "2026-10-09T06:42:03+00:00" translations: - language: "ar" html_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g?lang=ar" markdown_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g.md?lang=ar" json_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g.json?lang=ar" - language: "de" html_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g?lang=de" markdown_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g.md?lang=de" json_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g.json?lang=de" - language: "en" html_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g?lang=en" markdown_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g.md?lang=en" json_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g.json?lang=en" - language: "es" html_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g?lang=es" markdown_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g.md?lang=es" json_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g.json?lang=es" - language: "fr" html_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g?lang=fr" markdown_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g.md?lang=fr" json_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g.json?lang=fr" - language: "pl" html_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g?lang=pl" markdown_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g.md?lang=pl" json_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g.json?lang=pl" - language: "ru" html_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g?lang=ru" markdown_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g.md?lang=ru" json_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g.json?lang=ru" - language: "zh" html_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g?lang=zh" markdown_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g.md?lang=zh" json_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g.json?lang=zh" --- # OCUDU 26.10 brings satellite 5G and a tougher interoperability test to open RAN > OCUDU 26.10 is a substantial open-source RAN release: Release 17 NTN support, 8T8R antennas, positioning, security work and an early Split 7.2b implementation. Its value is real, but the release notes also show exactly why operators should test it as infrastructure, not install it as a finished network. OCUDU 26.10 is the kind of open-source release that is easy to misread. The headline features sound like a complete answer to several difficult telecom problems at once: satellite connectivity, higher-order MIMO, beam management, positioning, open fronthaul and stronger security. The project is also moving from an initial public release toward a predictable April-and-October cadence under Linux Foundation governance. ![Telecom laboratory with 5G radio equipment and a satellite-link test setup representing open RAN interoperability work](https://publicasta.com/storage/projects/10/pages/840/2026/10/3f4611c8-f80d-4020-abfe-d61d78e98a2f.webp) That makes this release important. It does not make it a plug-and-play replacement for a commercial radio access network. OCUDU 26.10 is best understood as a serious public implementation of a 5G CU/DU stack, with enough new capability to justify experiments by telecom researchers, private-network builders and equipment developers. It is not evidence that the hard parts of Open RAN interoperability have disappeared. The useful question is therefore narrower than whether OCUDU is ready for production. Which parts of the release can a technically equipped team test now, what hardware and timing assumptions sit underneath them, and which features still need independent end-to-end validation? ## What changed in OCUDU 26.10 The project’s official [release notes](https://docs.ocudu.org/releases/release_notes/) list a broad set of additions. The most consequential is Release 17 support for non-terrestrial networks, or NTN. The same release adds baseline O-RAN Split 7.2b support in the Open Fronthaul implementation, 8T8R antenna support, Release 15 and 16 beam management for FR1 and FR2, angle-based positioning, downlink positioning reference signals, two-step random access, uplink pre-scheduling, configured grants, TTI bundling, PUCCH repetition and DTLS support. The Linux Foundation’s [announcement](https://www.linuxfoundation.org/press/ocudu-ecosystem-foundation-announces-ocudu-26.10-and-invites-developers-to-the-ocudu-ecosystem-developer-summit-october-20-22-near-washington-dc-to-learn-m-1791460743158) groups those changes into three practical themes: more deployment choices, better radio performance and lower latency, and additional positioning and security functions. That is a fair description, but the detailed notes matter more than the summary because they expose the maturity of each feature. Several entries are explicitly marked as baseline support or as not yet tested with an O-RU. That wording is not a footnote. In a distributed RAN, a feature can compile, pass unit tests and still fail when it meets a particular radio unit, timing source, compression profile, transport network or management implementation. A release note that says a function is not end-to-end tested is telling an evaluator where to begin, not promising that the work is finished. OCUDU describes itself as a complete open-source 5G gNB project covering the central unit control plane, central unit user plane and distributed unit. The [official documentation](https://docs.ocudu.org/) says it targets commercial deployment and research, runs on general-purpose x86 and ARM hardware, follows 3GPP and O-RAN specifications, and is licensed under the BSD 3-Clause license. The repository is hosted on GitHub as a mirror, while contributions take place in the project’s [GitLab repository](https://gitlab.com/ocudu/ocudu). That structure matters because OCUDU is not merely a protocol demonstrator. Its value is in the boundary between standards, real-time systems, RF hardware and deployment tooling. The more of that boundary the project exposes in public code, the more useful it becomes for people who need to inspect, alter or validate a RAN rather than consume one as a sealed appliance. ## Why Release 17 NTN is the attention-grabber Non-terrestrial networking extends 5G procedures to links involving satellites or other airborne platforms. The radio link is no longer a short, relatively stable terrestrial path between a handset and a nearby base station. Propagation delay, timing, Doppler effects, satellite motion, coverage geometry and gateway placement all become part of the system design. The software must account for those conditions without pretending that a satellite cell behaves like an ordinary urban macrocell. OCUDU already documented GEO NTN support in earlier material. The 26.10 milestone expands the project’s stated scope to Release 17 NTN, and the tutorials describe an NTN mode using SIB19 ephemeris and timing support for GEO and LEO scenarios. The [NTN tutorial](https://docs.ocudu.org/tutorials/) is therefore more useful to a prospective tester than the headline alone: it signals that the project expects a test setup involving suitable UE equipment and a carefully controlled radio environment. This is where the release becomes relevant beyond satellite enthusiasts. An open implementation gives researchers a place to inspect how NTN assumptions flow through configuration, broadcast information, timing and mobility logic. It can support experiments that are difficult to perform with a vendor system whose implementation details are unavailable. A team working on resilient connectivity, remote industrial sites, maritime links or hybrid terrestrial-satellite networks can also use an open CU/DU as a reference point when comparing architectures. But open code does not remove the physical constraints. A developer can exercise part of the software with simulation or a virtual radio path, yet a realistic evaluation needs a UE, a radio front end or emulator, suitable timing, a 5G core and a transport path that reproduces the intended conditions. The project’s documentation names Amarisoft equipment for some NTN tutorials. That is a reminder that the most interesting demo may still depend on specialized or proprietary components around the open software. There is another limit. Support for a standard feature does not mean support for every satellite orbit, spectrum arrangement, terminal class or mobility pattern covered by that standard. Release 17 NTN is a large technical area. The responsible interpretation of OCUDU 26.10 is that it provides a public implementation surface for NTN work, not that it has solved satellite 5G as a product category. ## What 8T8R and beam management change The 8T8R work is less visible to general readers but may be more immediately relevant to terrestrial radio experiments. An 8T8R configuration uses eight transmit and eight receive antenna paths. More antenna ports can provide additional control over precoding and beam patterns, although the result depends on the radio unit, calibration, channel conditions, codebooks, processing capacity and the number of spatial layers actually used. Eight ports do not automatically mean eight independent data streams. The project’s public merge request for the feature explains that the implementation allows eight ports while still capping the maximum number of layers per codeword at four in the described stage. It also calls out CSI configuration, downlink precoding, PDSCH configuration, HARQ buffer sizing and PUCCH payload handling. Those details are useful because they show that an antenna-count feature is not a single switch. It touches scheduler assumptions, feedback, buffers, control signalling and the radio interface. OCUDU 26.10 also includes baseline Type-II codebook CSI reporting and feedback, as well as Release 15 and 16 beam management for FR1 and FR2. Beam management is the set of procedures used to discover, measure, select and maintain suitable beams. In a real system, that involves control signalling, reference signals, measurements, mobility and coordination between the distributed unit and radio unit. A code path that supports the procedure is necessary, but its usefulness depends on whether the complete chain behaves correctly under changing channel conditions. This is one reason to read the project’s milestone alongside the release notes. The [v26.10 milestone](https://gitlab.com/ocudu/ocudu/-/milestones/2) records the feature work in a more engineering-oriented way: Cat-B 7.2 Open Fronthaul, Type-II CSI, 8T8R, beam management, angle-based positioning, downlink positioning reference signals, two-step random access, uplink scheduling, configured grants, TTI bundling, PUCCH repetition, DTLS and Release 17 NTN. It also provides a visible trail of issues and merge requests rather than presenting the feature list as a finished product surface. For a lab, that is a strong reason to try the release. The code and issue history can help an evaluator identify which subsystem owns a failure. For a network operator, it is also a warning to keep the integration plan explicit. The right test is not merely whether a cell comes up. It is whether the intended RU, clocking arrangement, channel bandwidth, numerology, UE capability set and traffic profile produce stable behaviour under load. ## Split 7.2b is useful precisely because it is not yet boring Open RAN discussions often use interoperability as shorthand for the promise that a distributed unit from one supplier can work with a radio unit from another. The open fronthaul interface is central to that promise. In a 7.2x functional split, parts of the physical-layer processing are separated between the O-DU and O-RU, with radio samples and control information crossing a fronthaul network. This can create a broader supplier ecosystem, but it also makes timing, packet transport, compression, synchronization and profile compatibility operational concerns. The [O-RAN Alliance](https://www.o-ran.org/specifications) publishes specifications for interfaces and functions intended to support open, intelligent and interoperable radio access networks. The distinction between a specification and a working multi-vendor integration is important. The specification defines the contract. Implementations still need to agree on profiles, optional features, management behaviour, synchronization, performance limits and test coverage. OCUDU 26.10 adds baseline Split 7.2b support. The official release notes specifically say that it has not yet been tested with an O-RU. That single sentence should shape how the feature is evaluated. It is valuable for developers who need to examine or extend the interface. It is not a reason to assume that any 7.2b radio unit will connect successfully. The difference between 7.2a and 7.2b also has practical consequences. The placement of functions such as precoding affects what the O-DU and O-RU must know, how much information crosses the fronthaul and how the radio unit participates in beamforming. Public technical material on 7.2x commonly separates Category A and Category B around that precoding placement. A team moving from a 7.2a configuration to 7.2b should expect more than a configuration-file edit. It needs to verify supported profiles, compression, control-plane messages, timing and radio-unit behaviour. The project’s existing documentation points in the same direction. OCUDU’s current public feature material lists Split 7.2a through its in-house Open Fronthaul library, while the 26.10 release notes describe 7.2b as a baseline addition. That transition makes 26.10 a useful compatibility test for the ecosystem, but it also means that the release should be evaluated with named hardware and a reproducible test plan. A sensible first experiment would use one known O-RU, a fixed band and bandwidth, a documented clock and synchronization setup, and a traffic test that can be repeated across builds. Capture the fronthaul packets and control messages. Record CPU load, packet loss, timing errors, attach stability and throughput. If the result is a failure, the objective is to identify the failing contract rather than to declare the entire architecture viable or broken. ## Positioning is a second story hidden in the release OCUDU 26.10 adds angle-based positioning and downlink positioning reference signal generation. These capabilities point toward a RAN that can provide more than connectivity. Radio measurements can support location estimates, industrial tracking, asset monitoring, emergency services and network-aware applications. In a private network, positioning may be useful even when satellite navigation is unavailable or unreliable. The project’s release notes again use careful language: the positioning features are described as baseline support and not yet tested end to end with an O-RU. That qualification is especially important for positioning because an implementation’s output depends on antenna geometry, calibration, synchronization, multipath, measurement quality and the algorithms used to convert radio observations into a location estimate. A positioning reference signal can exist in the stack without producing a useful location in a warehouse, street canyon or industrial hall. For that reason, an evaluator should separate three questions. Can the network configure and transmit the relevant signals? Can the UE and radio unit measure them consistently? Does the complete system produce an accuracy and availability level that fits the intended application? OCUDU 26.10 appears to address the first question and opens work on the second and third. That is still meaningful. Open implementations let researchers inspect timing and measurement paths, compare algorithms and build repeatable test harnesses. They can also make it easier to find the boundary between a protocol issue, a radio calibration problem and an application-level positioning assumption. Closed systems may provide a polished result, but they make that diagnosis harder. ## Security work is more than a checklist item The release includes DTLS support for secure communication, improved security and resiliency work, and claims in the documentation around O-RAN security testing. The Linux Foundation announcement also mentions continuous fuzz testing, OSS-Fuzz participation and independent validation. These are positive signals because a network stack that handles control traffic, user traffic and management interfaces has a large attack surface. Still, security support should be read as a process and architecture question, not a badge. DTLS can protect a communication channel, but it does not decide who is allowed to establish that channel, how keys are provisioned and rotated, which endpoints are trusted, what happens when certificates expire, or how a deployment isolates management, control and user-plane traffic. Fuzzing can find classes of parser and state-machine defects, but it does not prove that a deployment is correctly configured. The [security and deployment documentation](https://docs.ocudu.org/tutorials/) should be read together with the source and the project’s test reports before the software is placed on an exposed network. A serious evaluation should inventory every interface: core-network connections, F1 or internal CU/DU paths, E1 connections between CU components, O-RAN fronthaul, management APIs, metrics, container interfaces and any remote command paths. It should then test authentication, certificate failure, malformed messages, resource exhaustion, privilege separation and logging. The permissive BSD-3-Clause license is attractive for commercial and research use, but licensing is not the same as operational assurance. The repository notes that portions may implement 3GPP specifications and may have additional licensing requirements. A company planning to ship a product should perform its own legal review, track third-party components and preserve the project’s notices. It should also examine the exact code and test status of the features it plans to distribute rather than treating the project’s top-level license as a complete compliance answer. ## Who should try OCUDU 26.10 The strongest audience is a team that can already build and operate a Linux-based 5G test environment. OCUDU’s [installation guide](https://docs.ocudu.org/user_manual/installation/) requires a Linux-based operating system with real-time kernel support. The build uses CMake and C++17, with dependencies including SCTP, yaml-cpp, mbedTLS and an FFT library. The guide lists Ubuntu 22.04 or later, Fedora and Arch as supported installation paths, while actual real-time performance depends on the host, CPU, NIC, kernel configuration and radio setup. Researchers working on NTN, beam management, positioning or open fronthaul can use the release as a public base for experiments. Private-network teams can examine how a CU/DU stack fits with a 5G core, O-RU and management system. Hardware developers can use the code and issue history to validate assumptions about interfaces. Students and engineers learning 5G architecture can also benefit, provided they treat the project as a system to understand rather than a binary to install and forget. The project’s tutorials cover more than a simple build. They include a complete split 8 network using srsUE and Open5GS, COTS UE handover tests, NTN configuration, Near-RT RIC integration, DPDK, hardware acceleration, container images, Kubernetes deployment and performance tuning. That range is helpful because it maps the software to the surrounding ecosystem. It also reveals the cost of a realistic evaluation: some tutorials require a USRP, DPDK-capable NIC, accelerator, timing equipment, compatible O-RU or commercial UE. OCUDU is a weaker choice for a team that wants a ready-made private 5G product with vendor support, certified hardware combinations, a turnkey management plane and a contractual performance target. It may become part of such a product, but the integration and verification burden does not disappear because the source is open. In fact, the ability to change the code creates another responsibility: maintain a patch set, track upstream changes, reproduce builds and decide which test results are sufficient for the deployment’s risk profile. ## A practical evaluation plan Start by choosing one question. Testing everything in 26.10 at once will produce an impressive amount of noise. A lab interested in satellite links should begin with the NTN tutorial and a defined timing and ephemeris scenario. A team evaluating radio-unit interoperability should begin with one O-RU and Split 7.2b, not a collection of unverified devices. A positioning researcher should first verify signal generation and measurement before promising an application-level accuracy target. Pin the exact source revision and record the compiler, kernel, CPU, NIC, FPGA or accelerator, RF front end, UE, core network and configuration. Store the build logs and configuration files with the test result. Open-source telecom systems are unusually sensitive to environmental details; a result that cannot be reproduced is difficult to interpret, even when the code is available. Then divide the evaluation into layers. First, run software tests and static checks. Second, establish a stable attach and user-plane session with the simplest supported setup. Third, add the selected feature. Fourth, introduce load, mobility, timing variation or a second vendor component. This order helps distinguish a base-system problem from a feature problem and a multi-vendor problem. For Split 7.2b, capture both functional and operational measurements. Confirm that the O-DU and O-RU agree on profiles and compression. Check synchronization before interpreting throughput. Measure packet rates, latency, jitter, loss and CPU headroom. Repeat the test after restart and under a controlled impairment. An interface that works once on a clean bench is not yet an interoperable deployment. For NTN, test the timing and mobility assumptions separately from application traffic. Compare the expected and observed behaviour as delay and geometry change. Document which parts are simulated, which are emulated and which traverse real RF or satellite equipment. The distinction will matter when someone later cites the result as evidence of field readiness. For security, build a threat model before enabling remote access. Use network segmentation, least privilege, protected credentials and signed or verified artifacts where available. Treat container images, helper tools, management endpoints and monitoring systems as part of the trusted-computing base. Review the project’s security reports and issue tracker, but do not outsource the final risk assessment to upstream maintainers. ## Alternatives and comparison points OCUDU is not the only open-source route to a 5G RAN experiment. OpenAirInterface remains an important reference project for researchers and operators exploring open RAN and 5G systems. srsRAN Project provides another open-source CU/DU and radio-access stack with extensive documentation and hardware integration material. The choice between them should follow the feature and hardware combination being tested, not a general ranking. The useful comparison is often specific. Which project supports the target band and split? Which one has a tested configuration for the chosen O-RU? Which project’s scheduler, PHY implementation or E2 integration matches the experiment? How active is the relevant issue queue? Can the team reproduce a build and obtain help when a hardware-specific failure appears? A feature matrix is less valuable than a tested path through the exact equipment in the lab. OCUDU’s distinction is its current attempt to place a broad CU/DU implementation, open governance, an October release and newer capabilities such as NTN and 8T8R in one public project. That makes it worth watching even for teams that do not adopt it. Its implementation choices can provide a comparison point for other stacks, and its public integration work can expose where standards leave room for interpretation. The alternative to testing an open stack is not always a commercial product. It may be a smaller, controlled component test. A team can validate an Open Fronthaul profile, a positioning signal path or a scheduler change without building a carrier-scale network. OCUDU is useful in that role because the source, documentation and issue history allow the experiment to stay close to the implementation. ## The real significance of the release OCUDU 26.10 matters because it moves open RAN code into a more demanding phase. The first public release established that the project could publish a broad open CU/DU foundation. The October release asks whether that foundation can absorb satellite timing, higher-order antenna configurations, beam procedures, positioning, security testing and additional fronthaul profiles without losing a transparent development process. That is a more valuable story than a claim that open source has replaced established telecom infrastructure. Open RAN still has to earn trust through interoperability tests, performance measurements, security review, operations tooling and long-lived maintenance. A permissive license helps more people inspect and build on the software, but it does not provide radio calibration, spectrum authorization, synchronization, support contracts or production validation. For developers, the immediate advice is to choose one 26.10 feature and reproduce the project’s documented path before modifying anything. For researchers, the release offers a richer base for experiments around NTN, positioning and disaggregated radio processing. For operators and equipment vendors, the right next step is a named hardware interoperability test with captured evidence, not a broad procurement conclusion. OCUDU 26.10 is therefore ready to test, and in several areas ready to teach. Its own release notes make clear where it is not yet ready to be trusted without additional work. That combination—substantial public capability plus visible limits—is exactly what an open-source radar should look for in a new infrastructure release.