OCUDU 26.10 to rodzaj wydania open source, który łatwo źle odczytać. Nagłówkowe funkcje brzmią jak jednoczesna odpowiedź na kilka trudnych problemów telekomunikacyjnych: łączność satelitarną, MIMO wyższego rzędu, zarządzanie wiązkami, pozycjonowanie, otwarty fronthaul i silniejsze zabezpieczenia. Projekt przechodzi też od pierwszego publicznego wydania do przewidywalnego rytmu publikacji w kwietniu i październiku, pod zarządem Linux Foundation.

Laboratorium telekomunikacyjne ze sprzętem radiowym 5G i stanowiskiem testowym łącza satelitarnego przedstawiającym interoperacyjność Open RAN

To czyni tę wersję ważną. Nie oznacza jednak, że jest ona gotowym zamiennikiem komercyjnej sieci dostępu radiowego, który można po prostu uruchomić. OCUDU 26.10 najlepiej rozumieć jako poważną, publiczną implementację stosu 5G CU/DU, oferującą wystarczająco dużo nowych możliwości, by zainteresować badaczy telekomunikacji, twórców sieci prywatnych i producentów urządzeń. Wydanie nie dowodzi, że trudne problemy interoperacyjności Open RAN zniknęły.

Właściwe pytanie jest więc węższe niż kwestia gotowości OCUDU do produkcji. Które elementy wydania może już teraz przetestować technicznie przygotowany zespół, jakie założenia sprzętowe i czasowe stoją za tymi funkcjami oraz które z nich nadal wymagają niezależnej walidacji od końca do końca?

Co zmieniło się w OCUDU 26.10

Oficjalne informacje o wydaniu wymieniają szeroki zestaw dodatków. Najważniejszym z nich jest obsługa Release 17 dla sieci nieterestrialnych, czyli NTN. Ta sama wersja dodaje bazową obsługę O-RAN Split 7.2b w implementacji Open Fronthaul, obsługę anten 8T8R, zarządzanie wiązkami zgodne z Release 15 i 16 dla FR1 i FR2, pozycjonowanie oparte na kącie, referencyjne sygnały pozycjonowania w łączu downlink, dwuetapowy dostęp losowy, planowanie uplinku z wyprzedzeniem, granty konfigurowane, łączenie TTI, powtarzanie PUCCH oraz obsługę DTLS.

Ogłoszenie Linux Foundation grupuje te zmiany w trzy praktyczne obszary: większy wybór wdrożeń, lepszą wydajność radiową i mniejsze opóźnienia oraz dodatkowe funkcje pozycjonowania i bezpieczeństwa. To uczciwy opis, lecz szczegółowe notatki są ważniejsze od streszczenia, bo pokazują dojrzałość poszczególnych funkcji.

Kilka pozycji jest wyraźnie oznaczonych jako obsługa bazowa albo jako funkcje, których nie testowano jeszcze z O-RU. Takie sformułowanie nie jest przypisem. W rozproszonym RAN funkcja może się kompilować, przechodzić testy jednostkowe, a mimo to zawodzić po zetknięciu z konkretną jednostką radiową, źródłem taktowania, profilem kompresji, siecią transportową albo implementacją zarządzania. Informacja o braku testu end-to-end wskazuje ewaluatorowi, od czego zacząć; nie obiecuje ukończenia prac.

OCUDU opisuje się jako kompletny projekt open source dla 5G gNB, obejmujący płaszczyznę sterowania jednostki centralnej, płaszczyznę użytkownika jednostki centralnej oraz jednostkę rozproszoną. Oficjalna dokumentacja podaje, że projekt jest przeznaczony do wdrożeń komercyjnych i badań, działa na sprzęcie ogólnego przeznaczenia x86 i ARM, stosuje się do specyfikacji 3GPP i O-RAN oraz jest objęty licencją BSD 3-Clause. Repozytorium jest hostowane na GitHubie jako mirror, natomiast prace nad kodem odbywają się w repozytorium GitLab.

Ta struktura ma znaczenie, ponieważ OCUDU nie jest wyłącznie demonstratorem protokołów. Wartość projektu leży na granicy między standardami, systemami czasu rzeczywistego, sprzętem RF i narzędziami wdrożeniowymi. Im większą część tej granicy projekt udostępnia w publicznym kodzie, tym bardziej przydaje się osobom, które muszą badać, zmieniać lub walidować RAN, zamiast korzystać z niego jak z zamkniętego urządzenia.

Dlaczego NTN Release 17 przyciąga największą uwagę

Sieci nieterestrialne rozszerzają procedury 5G na połączenia z satelitami lub innymi platformami powietrznymi. Łącze radiowe nie jest już krótką i względnie stabilną trasą naziemną między telefonem a pobliską stacją bazową. Opóźnienie propagacji, taktowanie, efekty Dopplera, ruch satelity, geometria pokrycia i rozmieszczenie bram stają się częścią projektu systemu. Oprogramowanie musi uwzględniać te warunki, nie udając, że komórka satelitarna zachowuje się jak zwykła miejska makrokomórka.

OCUDU dokumentowało już wcześniej obsługę NTN GEO. Kamień milowy 26.10 rozszerza deklarowany zakres projektu o NTN Release 17, a samouczki opisują tryb NTN wykorzystujący efemerydy SIB19 i obsługę taktowania dla scenariuszy GEO i LEO. Samouczek NTN jest zatem dla potencjalnego testera bardziej użyteczny niż sam nagłówek: pokazuje, że projekt zakłada konfigurację z odpowiednim sprzętem UE i starannie kontrolowanym środowiskiem radiowym.

W tym miejscu wydanie staje się istotne także dla osób niezajmujących się wyłącznie satelitami. Otwarta implementacja daje badaczom miejsce, w którym mogą prześledzić, jak założenia NTN przechodzą przez konfigurację, informacje rozgłaszane, taktowanie i logikę mobilności. Umożliwia eksperymenty trudne do wykonania z systemem dostawcy, którego szczegóły implementacyjne są niedostępne. Zespół pracujący nad odporną łącznością, odległymi zakładami przemysłowymi, połączeniami morskimi lub hybrydowymi sieciami naziemno-satelitarnymi może też wykorzystać otwarte CU/DU jako punkt odniesienia przy porównywaniu architektur.

Otwarty kod nie usuwa jednak ograniczeń fizycznych. Deweloper może przećwiczyć część oprogramowania przy użyciu symulacji lub wirtualnej ścieżki radiowej, ale realistyczna ocena wymaga UE, toru radiowego albo emulatora, odpowiedniego taktowania, rdzenia 5G oraz ścieżki transportowej odtwarzającej zamierzone warunki. Dokumentacja projektu wskazuje urządzenia Amarisoft w części samouczków NTN. To przypomnienie, że najbardziej interesująca demonstracja może nadal zależeć od wyspecjalizowanych lub zamkniętych komponentów otaczających otwarte oprogramowanie.

Istnieje też inne ograniczenie. Obsługa funkcji standardu nie oznacza obsługi każdej orbity satelitarnej, konfiguracji widma, klasy terminala ani wzorca mobilności objętych tym standardem. NTN Release 17 to rozległy obszar techniczny. Odpowiedzialna interpretacja OCUDU 26.10 brzmi: projekt zapewnia publiczną powierzchnię implementacyjną do pracy nad NTN, ale nie rozwiązał satelitarnego 5G jako kategorii produktowej.

Co zmieniają 8T8R i zarządzanie wiązkami

Prace nad 8T8R są mniej widoczne dla ogólnych odbiorców, ale mogą być bardziej bezpośrednio przydatne w naziemnych eksperymentach radiowych. Konfiguracja 8T8R wykorzystuje osiem torów nadawczych i osiem odbiorczych. Większa liczba portów antenowych może zapewnić dodatkową kontrolę nad precodingiem i wzorami wiązek, ale wynik zależy od jednostki radiowej, kalibracji, warunków kanału, codebooków, mocy obliczeniowej i faktycznej liczby używanych warstw przestrzennych. Osiem portów nie oznacza automatycznie ośmiu niezależnych strumieni danych.

Publiczny merge request projektu dotyczący tej funkcji wyjaśnia, że implementacja pozwala na osiem portów, jednocześnie ograniczając na opisanym etapie maksymalną liczbę warstw na codeword do czterech. Wskazuje też konfigurację CSI, precoding downlinku, konfigurację PDSCH, rozmiar buforów HARQ i obsługę ładunku PUCCH. Te szczegóły są ważne, bo pokazują, że funkcja dotycząca liczby anten nie jest pojedynczym przełącznikiem. Dotyka założeń harmonogramowania, informacji zwrotnej, buforów, sygnalizacji sterującej i interfejsu radiowego.

OCUDU 26.10 obejmuje również bazowe raportowanie CSI i informację zwrotną dla codebooku typu II, a także zarządzanie wiązkami zgodne z Release 15 i 16 dla FR1 i FR2. Zarządzanie wiązkami to zestaw procedur służących do wykrywania, pomiaru, wyboru i utrzymywania odpowiednich wiązek. W realnym systemie obejmuje sygnalizację sterującą, sygnały referencyjne, pomiary, mobilność oraz koordynację między jednostką rozproszoną i radiową. Ścieżka kodu obsługująca procedurę jest konieczna, lecz jej użyteczność zależy od tego, czy cały łańcuch poprawnie reaguje na zmienne warunki kanału.

To jeden z powodów, dla których kamień milowy projektu warto czytać razem z informacjami o wydaniu. Kamień milowy v26.10 przedstawia prace bardziej inżyniersko: Cat-B 7.2 Open Fronthaul, CSI typu II, 8T8R, zarządzanie wiązkami, pozycjonowanie oparte na kącie, referencyjne sygnały pozycjonowania w downlinku, dwuetapowy dostęp losowy, planowanie uplinku, granty konfigurowane, łączenie TTI, powtarzanie PUCCH, DTLS i NTN Release 17. Pokazuje też widoczny ślad zgłoszeń i merge requestów, zamiast przedstawiać listę funkcji jako gotową powierzchnię produktu.

Dla laboratorium to mocny powód, by wypróbować wydanie. Kod i historia zgłoszeń mogą pomóc ustalić, który podsystem odpowiada za awarię. Dla operatora jest to również ostrzeżenie, by plan integracji pozostał konkretny. Właściwy test nie polega wyłącznie na sprawdzeniu, czy komórka się uruchamia. Trzeba sprawdzić, czy wskazany RU, układ taktowania, szerokość kanału, numerologia, zestaw możliwości UE i profil ruchu zapewniają stabilne działanie pod obciążeniem.

Split 7.2b jest użyteczny właśnie dlatego, że nie stał się jeszcze nudny

W dyskusjach o Open RAN interoperacyjność często oznacza obietnicę, że jednostka rozproszona jednego dostawcy będzie współpracować z jednostką radiową innego. Otwarty interfejs fronthaul jest centralny dla tej obietnicy. W funkcjonalnym podziale 7.2x część przetwarzania warstwy fizycznej zostaje rozdzielona między O-DU i O-RU, a próbki radiowe i informacje sterujące przechodzą przez sieć fronthaul. Może to poszerzyć ekosystem dostawców, ale jednocześnie czyni z taktowania, transportu pakietów, kompresji, synchronizacji i zgodności profili kwestie operacyjne.

O-RAN Alliance publikuje specyfikacje interfejsów i funkcji mających wspierać otwarte, inteligentne i interoperacyjne sieci dostępu radiowego. Ważne jest rozróżnienie między specyfikacją a działającą integracją wielu dostawców. Specyfikacja określa kontrakt. Implementacje nadal muszą uzgodnić profile, funkcje opcjonalne, zachowanie zarządzania, synchronizację, limity wydajności i zakres testów.

OCUDU 26.10 dodaje bazową obsługę Split 7.2b. Oficjalne informacje o wydaniu mówią wprost, że funkcja nie była jeszcze testowana z O-RU. To jedno zdanie powinno określić sposób jej oceny. Dla deweloperów jest ona wartościowa, bo pozwala badać i rozszerzać interfejs. Nie jest natomiast powodem, by zakładać, że dowolna jednostka radiowa 7.2b połączy się bez problemu.

Różnica między 7.2a i 7.2b ma też praktyczne konsekwencje. Umiejscowienie funkcji takich jak precoding wpływa na to, co muszą wiedzieć O-DU i O-RU, ile informacji przechodzi przez fronthaul oraz jak jednostka radiowa uczestniczy w formowaniu wiązek. Publiczne materiały techniczne o 7.2x zwykle rozróżniają kategorie A i B właśnie wokół miejsca wykonywania precodingu. Zespół przechodzący z konfiguracji 7.2a na 7.2b powinien oczekiwać czegoś więcej niż zmiany pliku konfiguracyjnego. Musi zweryfikować obsługiwane profile, kompresję, komunikaty płaszczyzny sterowania, taktowanie i zachowanie jednostki radiowej.

Dotychczasowa dokumentacja projektu wskazuje ten sam kierunek. Aktualne publiczne materiały OCUDU wymieniają Split 7.2a przez własną bibliotekę Open Fronthaul, natomiast informacje o wydaniu 26.10 opisują 7.2b jako dodatek bazowy. Ta zmiana czyni z 26.10 użyteczny test zgodności dla ekosystemu, ale oznacza również, że wydanie należy oceniać na nazwanym sprzęcie i według powtarzalnego planu testów.

Rozsądny pierwszy eksperyment powinien wykorzystać jedną znaną jednostkę O-RU, stałe pasmo i szerokość kanału, udokumentowaną konfigurację zegara i synchronizacji oraz test ruchu, który da się powtórzyć między kompilacjami. Należy rejestrować pakiety fronthaul i komunikaty sterujące, a także obciążenie CPU, utratę pakietów, błędy taktowania, stabilność rejestracji i przepustowość. Jeśli wynik będzie negatywny, celem powinno być wskazanie niespełnionego kontraktu, a nie ogłoszenie, że cała architektura działa albo jest bezużyteczna.

Pozycjonowanie to druga historia ukryta w tym wydaniu

OCUDU 26.10 dodaje pozycjonowanie oparte na kącie oraz generowanie referencyjnych sygnałów pozycjonowania w downlinku. Te możliwości wskazują na RAN, który może oferować więcej niż samą łączność. Pomiary radiowe mogą wspierać estymację lokalizacji, śledzenie przemysłowe, monitorowanie zasobów, służby ratunkowe i aplikacje świadome położenia sieciowego. W sieci prywatnej pozycjonowanie może być przydatne nawet wtedy, gdy nawigacja satelitarna jest niedostępna lub zawodna.

Informacje o wydaniu projektu ponownie stosują ostrożny język: funkcje pozycjonowania opisano jako obsługę bazową i zaznaczono, że nie były jeszcze testowane od końca do końca z O-RU. To zastrzeżenie jest szczególnie ważne dla pozycjonowania, ponieważ wynik implementacji zależy od geometrii anten, kalibracji, synchronizacji, wielodrogowości, jakości pomiarów oraz algorytmów przekształcających obserwacje radiowe w estymację lokalizacji.

Sygnał referencyjny pozycjonowania może istnieć w stosie, a mimo to nie zapewniać użytecznej lokalizacji w magazynie, miejskim kanionie ani hali przemysłowej. Dlatego ewaluator powinien rozdzielić trzy pytania. Czy sieć potrafi skonfigurować i nadać odpowiednie sygnały? Czy UE i jednostka radiowa potrafią mierzyć je w sposób spójny? Czy kompletny system zapewnia dokładność i dostępność odpowiednie dla zamierzonej aplikacji? OCUDU 26.10 zdaje się odpowiadać na pierwsze pytanie i otwierać prace nad drugim oraz trzecim.

To nadal ma znaczenie. Otwarte implementacje pozwalają badaczom analizować ścieżki taktowania i pomiarów, porównywać algorytmy oraz budować powtarzalne narzędzia testowe. Ułatwiają też ustalenie granicy między problemem protokołu, błędem kalibracji radiowej i założeniem aplikacji pozycjonującej. Systemy zamknięte mogą oferować dopracowany wynik, ale utrudniają taką diagnozę.

Prace nad bezpieczeństwem to coś więcej niż pozycja na liście

Wydanie obejmuje obsługę DTLS dla bezpiecznej komunikacji, usprawnienia w obszarze bezpieczeństwa i odporności oraz deklaracje dokumentacji dotyczące testów bezpieczeństwa O-RAN. Ogłoszenie Linux Foundation wspomina również o ciągłym fuzzingu, udziale w OSS-Fuzz i niezależnej walidacji. To pozytywne sygnały, bo stos sieciowy obsługujący ruch sterujący, użytkownika i zarządzanie ma dużą powierzchnię ataku.

Obsługę bezpieczeństwa należy jednak traktować jako pytanie o proces i architekturę, a nie jako odznakę. DTLS może chronić kanał komunikacyjny, ale nie określa, kto może ten kanał ustanowić, jak klucze są dostarczane i obracane, które punkty końcowe są zaufane, co dzieje się po wygaśnięciu certyfikatów ani jak wdrożenie oddziela ruch zarządzania, sterowania i użytkownika. Fuzzing może znajdować klasy błędów parserów i maszyn stanów, ale nie dowodzi, że wdrożenie zostało poprawnie skonfigurowane.

Dokumentację bezpieczeństwa i wdrożeń należy czytać razem ze źródłami i raportami testów projektu, zanim oprogramowanie trafi do sieci wystawionej na zagrożenia. Poważna ocena powinna obejmować każdy interfejs: połączenia z siecią rdzeniową, ścieżki F1 lub wewnętrzne CU/DU, połączenia E1 między komponentami CU, fronthaul O-RAN, API zarządzania, metryki, interfejsy kontenerów oraz wszelkie zdalne ścieżki poleceń. Następnie trzeba sprawdzić uwierzytelnianie, awarie certyfikatów, zniekształcone komunikaty, wyczerpanie zasobów, separację uprawnień i logowanie.

Permisywna licencja BSD 3-Clause jest atrakcyjna dla zastosowań komercyjnych i badawczych, lecz licencja nie jest tym samym co gwarancja operacyjna. W repozytorium zaznaczono, że niektóre fragmenty mogą implementować specyfikacje 3GPP i podlegać dodatkowym wymaganiom licencyjnym. Firma planująca dostarczać produkt powinna przeprowadzić własną analizę prawną, śledzić komponenty stron trzecich i zachować wymagane informacje. Powinna również przeanalizować dokładny kod i status testów funkcji, które zamierza dystrybuować, zamiast traktować licencję najwyższego poziomu projektu jako pełną odpowiedź na kwestie zgodności.

Kto powinien wypróbować OCUDU 26.10

Najlepszym odbiorcą jest zespół, który potrafi już budować i obsługiwać środowisko testowe 5G oparte na Linuksie. Instrukcja instalacji OCUDU wymaga systemu operacyjnego opartego na Linuksie ze wsparciem dla jądra czasu rzeczywistego. Kompilacja wykorzystuje CMake i C++17, a zależności obejmują SCTP, yaml-cpp, mbedTLS i bibliotekę FFT. Instrukcja wymienia Ubuntu 22.04 lub nowsze, Fedorę i Arch jako obsługiwane ścieżki instalacji, jednak rzeczywista wydajność czasu rzeczywistego zależy od hosta, procesora, karty sieciowej, konfiguracji jądra i układu radiowego.

Badacze pracujący nad NTN, zarządzaniem wiązkami, pozycjonowaniem lub otwartym fronthaulem mogą użyć wydania jako publicznej bazy eksperymentów. Zespoły sieci prywatnych mogą sprawdzić, jak stos CU/DU współpracuje z rdzeniem 5G, O-RU i systemem zarządzania. Twórcy sprzętu mogą wykorzystać kod i historię zgłoszeń do walidacji założeń dotyczących interfejsów. Studenci i inżynierowie uczący się architektury 5G również mogą na tym skorzystać, o ile potraktują projekt jako system do zrozumienia, a nie binarium do zainstalowania i zapomnienia.

Samouczki projektu obejmują więcej niż prostą kompilację. Znajduje się wśród nich kompletna sieć split 8 z srsUE i Open5GS, testy handoveru z urządzeniami COTS UE, konfiguracja NTN, integracja z Near-RT RIC, DPDK, akceleracja sprzętowa, obrazy kontenerów, wdrożenie Kubernetes i strojenie wydajności. Ten zakres jest pomocny, bo pokazuje, jak oprogramowanie łączy się z resztą ekosystemu. Ujawnia też koszt realistycznej oceny: część samouczków wymaga USRP, karty sieciowej obsługującej DPDK, akceleratora, urządzeń do taktowania, zgodnego O-RU albo komercyjnego UE.

OCUDU jest słabszym wyborem dla zespołu, który chce gotowego produktu prywatnego 5G ze wsparciem dostawcy, certyfikowanymi zestawieniami sprzętowymi, gotową płaszczyzną zarządzania i umownym celem wydajnościowym. Projekt może stać się częścią takiego produktu, ale ciężar integracji i weryfikacji nie znika tylko dlatego, że źródła są otwarte. Możliwość zmiany kodu tworzy nawet dodatkową odpowiedzialność: trzeba utrzymywać zestaw poprawek, śledzić zmiany upstreamu, odtwarzać kompilacje i zdecydować, które wyniki testów wystarczają z punktu widzenia ryzyka danego wdrożenia.

Praktyczny plan oceny

Na początku należy wybrać jedno pytanie. Testowanie wszystkiego, co zawiera 26.10, naraz wygeneruje imponującą ilość szumu. Laboratorium zainteresowane łączami satelitarnymi powinno zacząć od samouczka NTN i określonego scenariusza taktowania oraz efemeryd. Zespół oceniający interoperacyjność jednostek radiowych powinien zacząć od jednego O-RU i Split 7.2b, a nie od kolekcji niezweryfikowanych urządzeń. Badacz pozycjonowania powinien najpierw sprawdzić generowanie i pomiar sygnałów, zanim obieca docelową dokładność na poziomie aplikacji.

Należy przypiąć dokładną rewizję źródeł i zapisać kompilator, jądro, CPU, kartę sieciową, FPGA lub akcelerator, tor RF, UE, sieć rdzeniową i konfigurację. Logi kompilacji oraz pliki konfiguracyjne powinny być przechowywane razem z wynikiem testu. Otwarte systemy telekomunikacyjne są wyjątkowo wrażliwe na szczegóły środowiska; wynik, którego nie da się odtworzyć, trudno zinterpretować, nawet gdy kod jest dostępny.

Następnie ocenę trzeba podzielić na warstwy. Najpierw należy uruchomić testy programistyczne i kontrole statyczne. Potem trzeba ustanowić stabilną rejestrację oraz sesję płaszczyzny użytkownika w najprostszym obsługiwanym układzie. W trzecim kroku należy dodać wybraną funkcję. Dopiero później warto wprowadzać obciążenie, mobilność, zmienność taktowania albo komponent drugiego dostawcy. Taka kolejność pomaga odróżnić problem systemu bazowego od problemu funkcji i problemu integracji wielu dostawców.

W przypadku Split 7.2b trzeba rejestrować zarówno pomiary funkcjonalne, jak i operacyjne. Należy potwierdzić, że O-DU i O-RU zgadzają się co do profili i kompresji. Synchronizację trzeba sprawdzić przed interpretacją przepustowości. Warto mierzyć liczbę pakietów, opóźnienie, jitter, straty i zapas CPU. Test należy powtórzyć po restarcie oraz przy kontrolowanym zakłóceniu. Interfejs działający raz na czystym stanowisku nie jest jeszcze interoperacyjnym wdrożeniem.

Dla NTN należy testować założenia dotyczące taktowania i mobilności niezależnie od ruchu aplikacyjnego. Trzeba porównywać oczekiwane i obserwowane zachowanie przy zmianie opóźnienia i geometrii. Należy udokumentować, które elementy są symulowane, które emulowane, a które przechodzą przez rzeczywisty sprzęt RF lub urządzenia satelitarne. To rozróżnienie będzie ważne, gdy ktoś później zacytuje wynik jako dowód gotowości terenowej.

W obszarze bezpieczeństwa należy zbudować model zagrożeń przed włączeniem dostępu zdalnego. Trzeba stosować segmentację sieci, minimalne uprawnienia, chronione dane uwierzytelniające oraz podpisane lub zweryfikowane artefakty, gdy są dostępne. Obrazy kontenerów, narzędzia pomocnicze, punkty końcowe zarządzania i systemy monitorowania należy traktować jako część podstawy zaufania. Raporty bezpieczeństwa projektu i tracker zgłoszeń są przydatne, ale nie można przenosić końcowej oceny ryzyka na opiekunów upstreamu.

Alternatywy i punkty odniesienia

OCUDU nie jest jedyną otwartoźródłową drogą do eksperymentów z RAN 5G. OpenAirInterface pozostaje ważnym projektem referencyjnym dla badaczy i operatorów badających otwarte sieci radiowe oraz systemy 5G. srsRAN Project oferuje inną otwartą implementację CU/DU i stos dostępu radiowego, wraz z obszerną dokumentacją oraz materiałami dotyczącymi integracji sprzętowej. Wybór między nimi powinien wynikać z kombinacji funkcji i sprzętu poddawanej testom, a nie z ogólnego rankingu.

Najbardziej użyteczne porównanie jest często konkretne. Który projekt obsługuje docelowe pasmo i podział? Który ma przetestowaną konfigurację dla wybranego O-RU? Czy harmonogram, implementacja PHY albo integracja E2 danego projektu pasują do eksperymentu? Jak aktywna jest kolejka zgłoszeń dotyczących konkretnej funkcji? Czy zespół potrafi odtworzyć kompilację i uzyskać pomoc, gdy pojawi się awaria zależna od sprzętu? Macierz funkcji jest mniej wartościowa niż sprawdzona ścieżka przez dokładnie ten sprzęt, który znajduje się w laboratorium.

Wyróżnikiem OCUDU jest obecna próba połączenia szerokiej implementacji CU/DU, otwartego zarządzania, październikowego cyklu wydań i nowszych możliwości, takich jak NTN i 8T8R, w jednym publicznym projekcie. To czyni go wartym obserwowania nawet dla zespołów, które go nie wdrożą. Decyzje implementacyjne mogą stanowić punkt porównania dla innych stosów, a publiczne prace integracyjne mogą ujawnić miejsca, w których standardy pozostawiają przestrzeń do interpretacji.

Alternatywą dla testowania otwartego stosu nie zawsze musi być produkt komercyjny. Może nią być mniejszy, kontrolowany test komponentu. Zespół może zweryfikować profil Open Fronthaul, ścieżkę sygnału pozycjonowania albo zmianę harmonogramu bez budowania sieci operatorskiej. OCUDU jest przydatne w tej roli, ponieważ źródła, dokumentacja i historia zgłoszeń pozwalają utrzymać eksperyment blisko implementacji.

Rzeczywiste znaczenie tego wydania

OCUDU 26.10 ma znaczenie, ponieważ przenosi kod Open RAN w bardziej wymagającą fazę. Pierwsze publiczne wydanie pokazało, że projekt może opublikować szeroką bazę otwartego CU/DU. Wydanie październikowe stawia pytanie, czy ta baza potrafi obsłużyć satelitarne taktowanie, bardziej rozbudowane konfiguracje anten, procedury wiązek, pozycjonowanie, testy bezpieczeństwa i dodatkowe profile fronthaulu, zachowując przy tym przejrzysty proces rozwoju.

To cenniejsza historia niż twierdzenie, że open source zastąpił istniejącą infrastrukturę telekomunikacyjną. Open RAN nadal musi zdobywać zaufanie dzięki testom interoperacyjności, pomiarom wydajności, przeglądom bezpieczeństwa, narzędziom operacyjnym i wieloletniemu utrzymaniu. Permisywna licencja ułatwia większej liczbie osób analizowanie i rozwijanie oprogramowania, ale nie zapewnia kalibracji radiowej, zezwoleń na wykorzystanie widma, synchronizacji, umów wsparcia ani walidacji produkcyjnej.

Dla deweloperów najbliższa rada jest prosta: wybrać jedną funkcję 26.10 i odtworzyć udokumentowaną ścieżkę projektu przed wprowadzeniem zmian. Dla badaczy wydanie oferuje bogatszą bazę eksperymentów dotyczących NTN, pozycjonowania i rozdzielonego przetwarzania radiowego. Dla operatorów i producentów urządzeń właściwym kolejnym krokiem jest test interoperacyjności na nazwanym sprzęcie wraz z zarejestrowanymi dowodami, a nie szeroki wniosek zakupowy.

OCUDU 26.10 jest więc gotowe do testowania, a w kilku obszarach także gotowe, by pełnić funkcję narzędzia edukacyjnego. Własne informacje o wydaniu wyraźnie pokazują, gdzie nie należy mu jeszcze ufać bez dodatkowych prac. To połączenie — znaczne publiczne możliwości i widoczne ograniczenia — jest dokładnie tym, czego warto szukać w nowym wydaniu infrastruktury open source.

Źródła

Opis opiera się na publicznych materiałach projektu OCUDU, dokumentacji Linux Foundation, specyfikacjach O-RAN Alliance oraz materiałach dotyczących otwartych implementacji RAN wskazanych w treści.