--- service: "Publicasta" schema_version: "1.0" article_id: 840 title: "OCUDU 26.10 bringt Satelliten-5G und einen härteren Interoperabilitätstest für Open RAN" language: "de" default_language: "en" canonical_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g?lang=de" json_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g.json?lang=de" api_url: "https://publicasta.com/api/public/v1/channels/open_source_radar/articles/ocudu_26_10_open_source_ran_satellite_5g?lang=de" 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:10+00:00" updated_at: "2026-10-09T06:42:10+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 bringt Satelliten-5G und einen härteren Interoperabilitätstest für Open RAN > OCUDU 26.10 erweitert den offenen 5G-RAN-Stack um Release-17-NTN, 8T8R, Positionierung, Sicherheitsfunktionen und eine frühe Split-7.2b-Implementierung. Der Nutzen ist real – ebenso die Integrationsarbeit, die vor einem Produktionseinsatz bleibt. OCUDU 26.10 ist die Art von Open-Source-Release, die sich leicht falsch einordnen lässt. Die Schlagworte klingen wie eine gemeinsame Antwort auf mehrere schwierige Telekommunikationsprobleme: Satellitenanbindung, höherwertiges MIMO, Beam-Management, Positionierung, offenes Fronthaul und stärkere Sicherheit. Zugleich bewegt sich das Projekt von einer ersten öffentlichen Veröffentlichung hin zu einem planbareren April-und-Oktober-Zyklus unter der Governance der Linux Foundation. ![Telekommunikationslabor mit 5G-Funktechnik und einem Satellitenlink-Testaufbau zur Darstellung der Open-RAN-Interoperabilität](https://publicasta.com/storage/projects/10/pages/840/2026/10/3f4611c8-f80d-4020-abfe-d61d78e98a2f.webp) Das macht diese Version wichtig. Sie ist deshalb aber kein sofort einsetzbarer Ersatz für ein kommerzielles Funkzugangsnetz. OCUDU 26.10 lässt sich am besten als ernsthafte öffentliche Implementierung eines 5G-CU/DU-Stacks verstehen, die genügend neue Fähigkeiten für Experimente von Telekommunikationsforschern, Betreibern privater Netze und Geräteentwicklern mitbringt. Sie ist kein Beleg dafür, dass die schwierigen Teile der Open-RAN-Interoperabilität verschwunden sind. Die sinnvollere Frage ist deshalb enger gefasst als die nach der Produktionsreife von OCUDU: Welche Teile der Version kann ein technisch ausgestattetes Team jetzt testen, welche Hardware- und Timing-Annahmen liegen darunter, und welche Funktionen benötigen weiterhin eine unabhängige Validierung über die gesamte Kette? ## Was sich in OCUDU 26.10 geändert hat Die offiziellen [Release Notes](https://docs.ocudu.org/releases/release_notes/) führen eine breite Reihe von Erweiterungen auf. Am folgenreichsten ist die Unterstützung von Release 17 für Non-Terrestrial Networks, kurz NTN. Hinzu kommen eine grundlegende O-RAN-Split-7.2b-Unterstützung in der Open-Fronthaul-Implementierung, 8T8R-Antennen, Release-15- und -16-Beam-Management für FR1 und FR2, winkelbasierte Positionierung, Downlink-Positioning-Reference-Signals, zweistufiger Random Access, Uplink-Pre-Scheduling, Configured Grants, TTI-Bundling, PUCCH-Repetition und DTLS-Unterstützung. Die [Ankündigung der Linux Foundation](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) ordnet diese Änderungen drei praktischen Themen zu: mehr Bereitstellungsoptionen, bessere Funkleistung und geringere Latenz sowie zusätzliche Positions- und Sicherheitsfunktionen. Das ist eine faire Zusammenfassung. Für die Beurteilung der Reife sind die detaillierten Notes jedoch wichtiger, weil sie zeigen, welchen Status die einzelnen Funktionen tatsächlich haben. Mehrere Einträge sind ausdrücklich als grundlegende Unterstützung oder als noch nicht mit einem O-RU getestet gekennzeichnet. Das ist keine Fußnote. In einem verteilten RAN kann eine Funktion kompilieren, Unit-Tests bestehen und trotzdem scheitern, sobald sie auf eine bestimmte Radio Unit, eine Timing-Quelle, ein Kompressionsprofil, ein Transportnetz oder eine Management-Implementierung trifft. Wenn in den Release Notes steht, dass eine Funktion nicht Ende zu Ende getestet wurde, zeigt das einem Evaluator, wo er anfangen sollte – es ist kein Versprechen, dass die Arbeit abgeschlossen ist. OCUDU beschreibt sich als vollständiges Open-Source-5G-gNB-Projekt für die Control Plane und User Plane der Central Unit sowie für die Distributed Unit. Die [offizielle Dokumentation](https://docs.ocudu.org/) nennt kommerzielle Nutzung und Forschung als Ziel, unterstützt allgemeine x86- und ARM-Hardware, orientiert sich an 3GPP- und O-RAN-Spezifikationen und steht unter der BSD-3-Clause-Lizenz. Das Repository wird auf GitHub als Spiegel gehostet; Beiträge erfolgen im [GitLab-Repository des Projekts](https://gitlab.com/ocudu/ocudu). Diese Struktur ist relevant, weil OCUDU nicht nur ein Protokoll-Demonstrator ist. Sein Wert liegt an der Grenze zwischen Standards, Echtzeitsystemen, HF-Hardware und Bereitstellungswerkzeugen. Je mehr von dieser Grenze der öffentliche Code sichtbar macht, desto nützlicher wird er für Teams, die ein RAN untersuchen, verändern oder validieren müssen, statt es als versiegeltes Appliance-Produkt zu beziehen. ## Warum Release-17-NTN die meiste Aufmerksamkeit erhält Non-Terrestrial Networking erweitert 5G-Verfahren auf Verbindungen über Satelliten oder andere luftgestützte Plattformen. Die Funkstrecke ist dann kein kurzer, vergleichsweise stabiler terrestrischer Weg zwischen Endgerät und naher Basisstation mehr. Ausbreitungsverzögerung, Timing, Doppler-Effekte, Satellitenbewegung, Abdeckungsgeometrie und die Position des Gateways werden zu Teilen des Systemdesigns. Die Software muss diese Bedingungen berücksichtigen, ohne so zu tun, als verhalte sich eine Satellitenzelle wie eine gewöhnliche städtische Makrozelle. OCUDU hatte Unterstützung für GEO-NTN bereits in früheren Materialien dokumentiert. Der Meilenstein 26.10 erweitert den erklärten Umfang des Projekts auf Release-17-NTN. Die Tutorials beschreiben einen NTN-Modus mit SIB19-Ephemeriden sowie Timing-Unterstützung für GEO- und LEO-Szenarien. Das [NTN-Tutorial](https://docs.ocudu.org/tutorials/) ist für einen potenziellen Tester daher hilfreicher als die Schlagzeile allein: Es deutet auf einen Versuchsaufbau mit geeigneter UE-Ausrüstung und einer sorgfältig kontrollierten Funkumgebung hin. Hier wird die Version auch für andere als Satellitenspezialisten interessant. Eine offene Implementierung bietet Forschern einen Ort, an dem sie untersuchen können, wie NTN-Annahmen durch Konfiguration, Broadcast-Informationen, Timing und Mobilitätslogik laufen. Das ermöglicht Experimente, die mit einem Herstellersystem und nicht zugänglichen Implementierungsdetails schwerer wären. Teams für robuste Konnektivität, abgelegene Industriestandorte, maritime Verbindungen oder hybride terrestrisch-satellitengestützte Netze können ein offenes CU/DU außerdem als Referenzpunkt für Architekturvergleiche nutzen. Offener Code hebt die physikalischen Grenzen jedoch nicht auf. Ein Entwickler kann einen Teil der Software per Simulation oder virtuellem Funkpfad ausführen. Für eine realistische Bewertung braucht es aber ein UE, eine Funkfront oder einen Emulator, geeignetes Timing, einen 5G-Core und einen Transportpfad, der die vorgesehenen Bedingungen nachbildet. In der Dokumentation nennt das Projekt für einige NTN-Tutorials Amarisoft-Geräte. Das erinnert daran, dass die interessanteste Demo weiterhin von spezialisierten oder proprietären Komponenten rund um die offene Software abhängen kann. Eine weitere Einschränkung bleibt. Die Unterstützung eines Standardmerkmals bedeutet nicht die Unterstützung jeder Satellitenbahn, jeder Spektrumanordnung, jeder Endgerätekategorie oder jedes Mobilitätsmusters, die von diesem Standard erfasst werden. Release-17-NTN ist ein großes technisches Gebiet. Die verantwortungsvolle Interpretation von OCUDU 26.10 lautet daher: Die Version stellt eine öffentliche Implementierungsfläche für NTN-Arbeiten bereit. Sie hat Satelliten-5G als Produktkategorie nicht gelöst. ## Was 8T8R und Beam-Management verändern Die 8T8R-Arbeit ist für allgemeine Leser weniger sichtbar, kann für terrestrische Funkexperimente aber unmittelbarer relevant sein. Eine 8T8R-Konfiguration verwendet acht Sende- und acht Empfangsantennenpfade. Mehr Antennenports können zusätzliche Kontrolle über Precoding und Beam-Muster geben. Das Ergebnis hängt jedoch von Radio Unit, Kalibrierung, Kanalbedingungen, Codebooks, Verarbeitungskapazität und der tatsächlich verwendeten Zahl räumlicher Layer ab. Acht Ports bedeuten nicht automatisch acht unabhängige Datenströme. Der öffentliche Merge Request des Projekts erklärt, dass die Implementierung acht Ports erlaubt, die maximale Layer-Zahl pro Codeword in der beschriebenen Phase aber weiterhin auf vier begrenzt. Außerdem werden CSI-Konfiguration, Downlink-Precoding, PDSCH-Konfiguration, HARQ-Pufferdimensionierung und die Verarbeitung von PUCCH-Nutzlasten genannt. Diese Details sind aufschlussreich, weil sie zeigen, dass eine Antennenzahl kein einzelner Schalter ist. Sie berührt Scheduler-Annahmen, Feedback, Puffer, Steuersignalisierung und die Funkschnittstelle. OCUDU 26.10 umfasst außerdem grundlegendes Type-II-Codebook-CSI-Reporting und Feedback sowie Beam-Management nach Release 15 und 16 für FR1 und FR2. Beam-Management bezeichnet die Verfahren zum Auffinden, Messen, Auswählen und Halten geeigneter Beams. In einem realen System gehören dazu Steuersignalisierung, Referenzsignale, Messungen, Mobilität und die Abstimmung zwischen Distributed Unit und Radio Unit. Ein Codepfad, der das Verfahren unterstützt, ist notwendig. Sein Nutzen hängt aber davon ab, ob die komplette Kette bei wechselnden Kanalbedingungen korrekt arbeitet. Deshalb lohnt es sich, den Meilenstein zusammen mit den Release Notes zu lesen. Der [Meilenstein v26.10](https://gitlab.com/ocudu/ocudu/-/milestones/2) dokumentiert die Arbeit stärker aus Engineering-Sicht: Cat-B-7.2-Open-Fronthaul, Type-II-CSI, 8T8R, Beam-Management, winkelbasierte Positionierung, Downlink-Positioning-Reference-Signals, zweistufiger Random Access, Uplink-Scheduling, Configured Grants, TTI-Bundling, PUCCH-Repetition, DTLS und Release-17-NTN. Er liefert zudem eine sichtbare Spur aus Issues und Merge Requests, statt die Funktionsliste als fertige Produktoberfläche zu präsentieren. Für ein Labor ist das ein guter Grund, die Version auszuprobieren. Code und Issue-Historie können einem Evaluator helfen, einem Fehler das zuständige Subsystem zuzuordnen. Für einen Netzbetreiber ist es zugleich ein Hinweis, den Integrationsplan konkret zu halten. Der richtige Test ist nicht bloß, ob eine Zelle startet. Entscheidend ist, ob die vorgesehene RU, die Taktungsarchitektur, Kanalbandbreite, Numerologie, UE-Fähigkeiten und das Verkehrsprofil unter Last stabil funktionieren. ## Split 7.2b ist gerade deshalb nützlich, weil es noch nicht langweilig ist In Open-RAN-Diskussionen steht Interoperabilität oft stellvertretend für das Versprechen, dass eine Distributed Unit eines Anbieters mit einer Radio Unit eines anderen Anbieters arbeiten kann. Die offene Fronthaul-Schnittstelle ist für dieses Versprechen zentral. Bei einem funktionalen Split der Familie 7.2x werden Teile der physikalischen Verarbeitung zwischen O-DU und O-RU aufgeteilt; Funksamples und Steuerinformationen laufen über ein Fronthaul-Netz. Das kann ein breiteres Lieferantenökosystem ermöglichen, macht aber Timing, Pakettransport, Kompression, Synchronisierung und Profilkompatibilität zu betrieblichen Fragen. Die [O-RAN Alliance](https://www.o-ran.org/specifications) veröffentlicht Spezifikationen für Schnittstellen und Funktionen, die offene, intelligente und interoperable Funkzugangsnetze unterstützen sollen. Der Unterschied zwischen einer Spezifikation und einer funktionierenden Multi-Vendor-Integration ist entscheidend. Die Spezifikation definiert den Vertrag. Implementierungen müssen sich dennoch auf Profile, optionale Funktionen, Management-Verhalten, Synchronisierung, Leistungsgrenzen und Testabdeckung einigen. OCUDU 26.10 ergänzt eine grundlegende Split-7.2b-Unterstützung. Die offiziellen Release Notes sagen ausdrücklich, dass sie noch nicht mit einem O-RU getestet wurde. Dieser eine Satz sollte die Bewertung bestimmen. Die Funktion ist für Entwickler wertvoll, die die Schnittstelle untersuchen oder erweitern möchten. Er ist kein Grund anzunehmen, dass jede 7.2b-Radio-Unit erfolgreich verbunden werden kann. Der Unterschied zwischen 7.2a und 7.2b hat zudem praktische Folgen. Die Platzierung von Funktionen wie Precoding beeinflusst, was O-DU und O-RU wissen müssen, wie viele Informationen das Fronthaul übertragen muss und wie sich die Radio Unit am Beamforming beteiligt. Öffentliche technische Materialien zu 7.2x unterscheiden Category A und Category B häufig anhand dieser Precoding-Platzierung. Wer von 7.2a auf 7.2b wechselt, sollte mehr als eine Änderung der Konfigurationsdatei erwarten. Zu prüfen sind unterstützte Profile, Kompression, Control-Plane-Nachrichten, Timing und das Verhalten der Radio Unit. Auch die vorhandene Projektdokumentation weist in diese Richtung. In den aktuellen öffentlichen Funktionsmaterialien führt OCUDU Split 7.2a über die eigene Open-Fronthaul-Bibliothek auf, während die Release Notes von 26.10 7.2b als grundlegende Erweiterung beschreiben. Dieser Übergang macht 26.10 zu einem interessanten Kompatibilitätstest für das Ökosystem. Er bedeutet aber auch, dass die Version mit benannter Hardware und einem reproduzierbaren Testplan bewertet werden sollte. Ein sinnvoller erster Versuch würde eine bekannte O-RU, ein festes Band und eine feste Bandbreite, eine dokumentierte Takt- und Synchronisierungskonfiguration sowie einen wiederholbaren Verkehrstest verwenden. Fronthaul-Pakete und Steuernachrichten sollten aufgezeichnet werden. Zu dokumentieren sind CPU-Last, Paketverlust, Timing-Fehler, Attach-Stabilität und Durchsatz. Bei einem Fehlschlag besteht das Ziel darin, den gebrochenen Vertrag zu identifizieren – nicht darin, die gesamte Architektur vorschnell für tauglich oder untauglich zu erklären. ## Positionierung ist eine zweite, im Release verborgene Geschichte OCUDU 26.10 ergänzt winkelbasierte Positionierung und die Erzeugung von Downlink-Positioning-Reference-Signals. Diese Fähigkeiten weisen auf ein RAN hin, das mehr als Konnektivität liefern kann. Funkmessungen können Positionsschätzungen, industrielle Ortung, Asset-Überwachung, Notfalldienste und netzbewusste Anwendungen unterstützen. In einem privaten Netz kann Positionierung auch dann nützlich sein, wenn Satellitennavigation nicht verfügbar oder unzuverlässig ist. Auch hier verwenden die Release Notes vorsichtige Formulierungen: Die Positionsfunktionen werden als grundlegende Unterstützung beschrieben und sind noch nicht Ende zu Ende mit einem O-RU getestet. Diese Einschränkung ist bei Positionierung besonders wichtig, weil das Ergebnis von Antennengeometrie, Kalibrierung, Synchronisierung, Mehrwegeffekten, Messqualität und den Algorithmen abhängt, mit denen Funkbeobachtungen in eine Positionsschätzung umgewandelt werden. Ein Positionierungsreferenzsignal kann im Stack vorhanden sein, ohne in einem Lager, einem Straßenschlucht-Szenario oder einer Industriehalle eine brauchbare Position zu liefern. Ein Evaluator sollte deshalb drei Fragen trennen: Kann das Netz die relevanten Signale konfigurieren und senden? Können UE und Radio Unit sie konsistent messen? Erreicht das Gesamtsystem ein Genauigkeits- und Verfügbarkeitsniveau, das zur vorgesehenen Anwendung passt? OCUDU 26.10 scheint die erste Frage zu adressieren und Arbeit an der zweiten und dritten zu eröffnen. Das ist dennoch bedeutsam. Offene Implementierungen erlauben Forschern, Timing- und Messpfade zu untersuchen, Algorithmen zu vergleichen und reproduzierbare Testharnesses zu bauen. Sie können außerdem die Grenze zwischen einem Protokollproblem, einem Funkkalibrierungsfehler und einer Annahme auf Anwendungsebene sichtbarer machen. Geschlossene Systeme liefern womöglich ein poliertes Ergebnis, erschweren diese Diagnose aber. ## Sicherheitsarbeit ist mehr als ein Punkt auf einer Checkliste Die Version enthält DTLS-Unterstützung für sichere Kommunikation, Verbesserungen bei Sicherheit und Resilienz sowie Dokumentationsaussagen zu O-RAN-Sicherheitstests. Die Ankündigung der Linux Foundation nennt außerdem kontinuierliches Fuzzing, die Teilnahme an OSS-Fuzz und unabhängige Validierung. Das sind positive Signale, weil ein Netzwerkstack mit Steuer-, Nutzer- und Management-Schnittstellen eine große Angriffsfläche hat. Sicherheitsunterstützung sollte trotzdem als Prozess- und Architekturfrage gelesen werden, nicht als Auszeichnung. DTLS kann einen Kommunikationskanal schützen. Es entscheidet aber nicht, wer diesen Kanal aufbauen darf, wie Schlüssel bereitgestellt und rotiert werden, welchen Endpunkten vertraut wird, was beim Ablauf von Zertifikaten geschieht oder wie Management-, Control- und User-Plane-Verkehr voneinander isoliert werden. Fuzzing kann Klassen von Parser- und Zustandsautomatenfehlern finden, beweist aber nicht, dass eine Bereitstellung korrekt konfiguriert ist. Die [Dokumentation zu Sicherheit und Bereitstellung](https://docs.ocudu.org/tutorials/) sollte zusammen mit Quellcode und Testberichten gelesen werden, bevor die Software in ein exponiertes Netz gelangt. Eine ernsthafte Bewertung sollte jede Schnittstelle erfassen: Verbindungen zum Kernnetz, F1 oder interne CU/DU-Pfade, E1-Verbindungen zwischen CU-Komponenten, O-RAN-Fronthaul, Management-APIs, Metriken, Container-Schnittstellen und entfernte Befehlswege. Danach sollten Authentifizierung, Zertifikatsfehler, fehlerhafte Nachrichten, Ressourcenerschöpfung, Rechteaufteilung und Protokollierung geprüft werden. Die freizügige BSD-3-Clause-Lizenz ist für kommerzielle und wissenschaftliche Nutzung attraktiv, aber Lizenzierung ist nicht dasselbe wie Betriebssicherheit. Die Repository-Hinweise weisen darauf hin, dass Teile 3GPP-Spezifikationen implementieren und zusätzlichen Lizenzanforderungen unterliegen können. Ein Unternehmen, das ein Produkt ausliefern will, sollte eine eigene rechtliche Prüfung durchführen, Drittanbieterkomponenten nachverfolgen und die Hinweise des Projekts erhalten. Es sollte außerdem den konkreten Code und Teststatus der geplanten Funktionen prüfen, statt die Lizenz auf oberster Ebene als vollständige Compliance-Antwort zu behandeln. ## Wer OCUDU 26.10 ausprobieren sollte Die stärkste Zielgruppe ist ein Team, das bereits eine Linux-basierte 5G-Testumgebung aufbauen und betreiben kann. Der [Installationsleitfaden](https://docs.ocudu.org/user_manual/installation/) verlangt ein Linux-basiertes Betriebssystem mit Unterstützung für einen Echtzeitkernel. Der Build verwendet CMake und C++17; zu den Abhängigkeiten gehören SCTP, yaml-cpp, mbedTLS und eine FFT-Bibliothek. Der Leitfaden nennt Ubuntu 22.04 oder neuer, Fedora und Arch als unterstützte Installationswege. Die tatsächliche Echtzeitleistung hängt jedoch von Host, CPU, NIC, Kernelkonfiguration und Funkaufbau ab. Forscher zu NTN, Beam-Management, Positionierung oder offenem Fronthaul können die Version als öffentliche Grundlage für Experimente verwenden. Teams für private Netze können untersuchen, wie ein CU/DU-Stack mit 5G-Core, O-RU und Managementsystem zusammenspielt. Hardwareentwickler können Code und Issue-Historie nutzen, um Annahmen über Schnittstellen zu prüfen. Auch Studierende und Ingenieure, die 5G-Architektur lernen, können profitieren – sofern sie das Projekt als System zum Verstehen behandeln und nicht als Binärdatei, die man installiert und anschließend vergisst. Die Tutorials des Projekts gehen über einen einfachen Build hinaus. Sie behandeln ein vollständiges Split-8-Netz mit srsUE und Open5GS, Handover-Tests mit COTS-UEs, NTN-Konfiguration, Near-RT-RIC-Integration, DPDK, Hardwarebeschleunigung, Container-Images, Kubernetes-Bereitstellung und Performance-Tuning. Diese Breite ist hilfreich, weil sie die Software in das umgebende Ökosystem einordnet. Sie zeigt aber auch die Kosten einer realistischen Bewertung: Einige Tutorials benötigen ein USRP, eine DPDK-fähige NIC, einen Beschleuniger, Timing-Hardware, eine kompatible O-RU oder ein kommerzielles UE. Für ein Team, das ein fertiges privates 5G-Produkt mit Hersteller-Support, zertifizierten Hardwarekombinationen, einer schlüsselfertigen Managementebene und einem vertraglichen Leistungsziel sucht, ist OCUDU die schwächere Wahl. Es kann Teil eines solchen Produkts werden, doch Integrations- und Verifikationsaufwand verschwinden nicht, nur weil der Quellcode offen ist. Die Möglichkeit, den Code zu ändern, schafft sogar eine zusätzliche Verantwortung: einen Patch-Satz zu pflegen, Upstream-Änderungen zu verfolgen, Builds zu reproduzieren und festzulegen, welche Testergebnisse für das Risikoprofil der Bereitstellung genügen. ## Ein praktischer Evaluationsplan Zuerst sollte eine einzige Frage festgelegt werden. Wer alle Funktionen von 26.10 auf einmal testet, erzeugt vor allem eine beeindruckende Menge an Rauschen. Ein Labor für Satellitenverbindungen sollte mit dem NTN-Tutorial und einem definierten Timing- und Ephemeridenszenario beginnen. Ein Team zur Bewertung der Radio-Unit-Interoperabilität sollte mit einer O-RU und Split 7.2b starten, nicht mit einer Sammlung ungeprüfter Geräte. Eine Forscherin oder ein Forscher zur Positionierung sollte zunächst Signalerzeugung und Messung verifizieren, bevor ein Genauigkeitsziel auf Anwendungsebene versprochen wird. Die exakte Quellrevision sollte festgehalten werden, ebenso Compiler, Kernel, CPU, NIC, FPGA oder Beschleuniger, HF-Front-End, UE, Kernnetz und Konfiguration. Build-Logs und Konfigurationsdateien gehören zum Testergebnis. Open-Source-Telekomsysteme reagieren ungewöhnlich empfindlich auf Umgebungsdetails. Ein Ergebnis, das sich nicht reproduzieren lässt, ist schwer zu interpretieren, selbst wenn der Code verfügbar ist. Danach sollte die Bewertung in Schichten erfolgen. Zuerst laufen Softwaretests und statische Prüfungen. Als Nächstes wird mit dem einfachsten unterstützten Aufbau ein stabiler Attach und eine User-Plane-Sitzung hergestellt. Danach kommt die ausgewählte Funktion hinzu. Erst dann folgen Last, Mobilität, Timing-Variationen oder eine zweite Herstellerkomponente. Diese Reihenfolge hilft, ein Problem des Basissystems von einem Funktionsproblem und einem Multi-Vendor-Problem zu unterscheiden. Für Split 7.2b sollten funktionale und betriebliche Messwerte erfasst werden. Zu bestätigen ist, dass O-DU und O-RU Profile und Kompression gemeinsam verwenden. Die Synchronisierung muss geprüft werden, bevor der Durchsatz interpretiert wird. Zu messen sind Paket-raten, Latenz, Jitter, Verlust und CPU-Reserve. Der Test sollte nach einem Neustart und unter einer kontrollierten Beeinträchtigung wiederholt werden. Eine Schnittstelle, die einmal auf einer sauberen Laborbank funktioniert, ist noch keine interoperable Bereitstellung. Bei NTN sollten Timing- und Mobilitätsannahmen getrennt vom Anwendungstraffic getestet werden. Das erwartete und das beobachtete Verhalten sind zu vergleichen, während sich Verzögerung und Geometrie ändern. Zu dokumentieren ist, welche Teile simuliert, emuliert oder über echte Funk- beziehungsweise Satellitentechnik geführt werden. Diese Unterscheidung wird wichtig, wenn später jemand das Ergebnis als Beleg für Feldreife anführt. Für Sicherheit sollte vor dem Aktivieren des Fernzugriffs ein Bedrohungsmodell erstellt werden. Netzwerksegmentierung, geringstmögliche Rechte, geschützte Zugangsdaten und signierte oder verifizierte Artefakte sind einzusetzen, soweit verfügbar. Container-Images, Hilfswerkzeuge, Management-Endpunkte und Überwachungssysteme gehören zur Trusted Computing Base und müssen entsprechend behandelt werden. Sicherheitsberichte und Issue-Tracker des Projekts sind hilfreich, ersetzen aber nicht die abschließende Risikobewertung des Betreibers. ## Alternativen und Vergleichspunkte OCUDU ist nicht der einzige Open-Source-Weg zu einem 5G-RAN-Experiment. OpenAirInterface bleibt ein wichtiges Referenzprojekt für Forscher und Betreiber, die sich mit Open RAN und 5G-Systemen beschäftigen. Das srsRAN Project bietet einen weiteren offenen CU/DU- und Funkzugangsstack mit umfangreicher Dokumentation und Materialien zur Hardwareintegration. Die Wahl sollte von der jeweils getesteten Funktions- und Hardwarekombination abhängen, nicht von einer allgemeinen Rangliste. Der nützliche Vergleich ist oft sehr konkret. Welches Projekt unterstützt das gewünschte Band und den gewünschten Split? Welches hat eine getestete Konfiguration für die ausgewählte O-RU? Welcher Scheduler, welche PHY-Implementierung oder welche E2-Integration passt zum Experiment? Wie aktiv ist die relevante Issue-Warteschlange? Kann das Team einen Build reproduzieren und Hilfe erhalten, wenn ein hardwareabhängiger Fehler auftritt? Eine Feature-Matrix ist weniger wertvoll als ein getesteter Pfad durch die exakt im Labor vorhandene Ausrüstung. OCUDUs Besonderheit ist der aktuelle Versuch, eine breite CU/DU-Implementierung, offene Governance, eine Oktober-Veröffentlichung und neuere Fähigkeiten wie NTN und 8T8R in einem öffentlichen Projekt zusammenzuführen. Deshalb ist die Version auch für Teams interessant, die sie nicht übernehmen. Ihre Implementierungsentscheidungen können als Vergleichspunkt für andere Stacks dienen; die öffentliche Integrationsarbeit kann sichtbar machen, wo Standards Interpretationsspielraum lassen. Die Alternative zum Testen eines offenen Stacks ist nicht immer ein kommerzielles Produkt. Es kann auch ein kleiner, kontrollierter Komponententest sein. Ein Team kann ein Open-Fronthaul-Profil, einen Positionierungssignalpfad oder eine Scheduler-Änderung validieren, ohne ein Netz in Carrier-Größe aufzubauen. OCUDU ist für diese Rolle geeignet, weil Quellcode, Dokumentation und Issue-Historie das Experiment eng an der Implementierung halten. ## Die eigentliche Bedeutung dieses Releases OCUDU 26.10 ist relevant, weil Open-RAN-Code in eine anspruchsvollere Phase eintritt. Die erste öffentliche Version zeigte, dass das Projekt eine breite offene CU/DU-Grundlage veröffentlichen konnte. Die Oktober-Version stellt die Frage, ob diese Grundlage Satelliten-Timing, höherwertige Antennenkonfigurationen, Beam-Verfahren, Positionierung, Sicherheitstests und zusätzliche Fronthaul-Profile aufnehmen kann, ohne einen transparenten Entwicklungsprozess zu verlieren. Das ist die wertvollere Geschichte als die Behauptung, Open Source habe etablierte Telekommunikationsinfrastruktur ersetzt. Open RAN muss Vertrauen weiterhin durch Interoperabilitätstests, Leistungsmessungen, Sicherheitsprüfungen, Betriebssysteme und langfristige Wartung erwerben. Eine freizügige Lizenz erleichtert mehr Menschen die Prüfung und Weiterentwicklung der Software. Sie liefert jedoch weder Funkkalibrierung noch Frequenzgenehmigung, Synchronisierung, Supportverträge oder Produktionsvalidierung. Entwickler sollten zunächst eine einzige Funktion von 26.10 auswählen und den dokumentierten Pfad des Projekts reproduzieren, bevor sie Änderungen vornehmen. Forschern bietet die Version eine reichhaltigere Grundlage für Experimente zu NTN, Positionierung und disaggregierter Funkverarbeitung. Betreiber und Gerätehersteller sollten als nächsten Schritt einen Interoperabilitätstest mit benannter Hardware und aufgezeichneten Belegen durchführen, nicht sofort eine weitreichende Beschaffungsentscheidung treffen. OCUDU 26.10 ist damit bereit zum Testen und in mehreren Bereichen bereit, etwas zu vermitteln. Die eigenen Release Notes machen zugleich deutlich, wo zusätzliche Arbeit nötig ist, bevor Vertrauen ohne weitere Prüfung gerechtfertigt wäre. Diese Kombination aus substanzieller öffentlicher Fähigkeit und sichtbar markierten Grenzen ist genau das, was man von einem neuen Infrastruktur-Release unter Open-Source-Bedingungen erwarten sollte. ## Quellen - [OCUDU Ecosystem Foundation: Ankündigung von OCUDU 26.10](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) - [OCUDU 26.10 Release Notes](https://docs.ocudu.org/releases/release_notes/) - [OCUDU-v26.10-Meilenstein](https://gitlab.com/ocudu/ocudu/-/milestones/2) - [OCUDU-Dokumentation](https://docs.ocudu.org/) - [OCUDU-Installationsleitfaden](https://docs.ocudu.org/user_manual/installation/) - [OCUDU-Tutorials](https://docs.ocudu.org/tutorials/) - [Merge Request zur 8T8R-Antennenunterstützung](https://gitlab.com/ocudu/ocudu/-/merge_requests/1056) - [OCUDU-Quellcode-Spiegel](https://github.com/ocudu/ocudu) - [O-RAN-Spezifikationen](https://www.o-ran.org/specifications) - [srsRAN: Leitfaden für O-RAN 7.2 RU](https://docs.srsran.com/projects/project/en/latest/tutorials/source/oranRU/source/)