Otwarta sieć RAN (Open RAN) w 5G: szansa na tańszą infrastrukturę czy nowe ryzyka cyber

Open RAN w 5G: czego tak naprawdę szuka biznes

Intencją większości decydentów nie jest „posiadanie Open RAN”, tylko osiągnięcie konkretnego efektu: niższego TCO infrastruktury radiowej, większej elastyczności zakupowej i możliwości szybszego uruchamiania usług. Z drugiej strony każda nowa warstwa złożoności i każdy dodatkowy dostawca to kolejne punkty podatności i koszty bezpieczeństwa, których CFO często nie widzi na pierwszym slajdzie prezentacji.

Sensowne podejście do Open RAN zaczyna się więc od chłodnej kalkulacji: gdzie realnie można obniżyć koszty (sprzęt, licencje, energia, obsługa), gdzie z kolei wydatki wzrosną (integracja, cyberbezpieczeństwo, testy, kompetencje), oraz jaki poziom ryzyka organizacja jest w stanie zaakceptować w perspektywie kilku lat.

Czym jest Open RAN i dlaczego wywołuje tyle szumu

Klasyczny RAN vs Open RAN – gdzie dokładnie przebiega granica

W tradycyjnym modelu Radio Access Network dla LTE i 5G jeden duży dostawca dostarcza praktycznie całą warstwę radiową: sprzęt antenowy (RU), jednostki bazowe (DU/CU), oprogramowanie, system zarządzania, a często także usługi integracji i utrzymania. Interfejsy między elementami są w dużym stopniu zamknięte lub „półotwarte”, co utrudnia mieszanie rozwiązań różnych vendorów.

Open RAN rozbija ten monolit na mniejsze klocki. Zamiast „jednego pudełka” od jednego dostawcy pojawia się kilka warstw:

• Remote Unit (RU) – głowica radiowa przy antenie, potencjalnie od innego producenta,
• Distributed Unit (DU) – warstwa blisko radia, często wirtualizowana,
• Centralized Unit (CU) – wyższe warstwy protokołów, również w formie oprogramowania na serwerach COTS,
• wspólne, zdefiniowane standardami interfejsy między RU–DU–CU oraz do systemów zarządzania.

Granica zmian nie dotyczy więc samej idei dostępu radiowego, lecz sposobu jego „poskładania”: zamiast jednego dostawcy odpowiadającego za całość pojawia się ekosystem dostawców sprzętu, oprogramowania, integratorów i narzędzi automatyzacji.

Co w Open RAN jest faktycznie „open”, a co jest marketingiem

Hasło „open” w kontekście Open RAN bywa mylące. W praktyce obejmuje trzy różne obszary, które nie zawsze występują razem:

• Otwarte interfejsy – zdefiniowane w sposób jawny i standaryzowany (np. specyfikacje O-RAN Alliance), tak aby RU jednego producenta mogła współpracować z DU innego. To jest sedno architektury Open RAN.
• Otwarta architektura – rozłożenie funkcji na mniejsze komponenty (RU, DU, CU, RIC, systemy orkiestracji), z możliwością niezależnego doboru i rozwoju tych elementów.
• Otwarte oprogramowanie – użycie komponentów open source (np. w warstwie orkiestracji, RIC, automatyzacji). Tu często pojawia się mit: Open RAN ≠ obowiązkowo „open source”. Wiele krytycznych modułów pozostaje komercyjnych i zamkniętych.

Dla inwestora i działu bezpieczeństwa kluczowa jest pierwsza warstwa: otwarte, udokumentowane interfejsy, które ułatwiają interoperacyjność, ale równocześnie zwiększają powierzchnię potencjalnych ataków. To właśnie na styku tych interfejsów trzeba później zainwestować najwięcej czasu w testy, hardening i monitoring.

Obietnice zwolenników Open RAN

Argumenty za Open RAN powtarzają się w prezentacjach, ale da się je przełożyć na bardziej konkretne kategorie biznesowe:

• Niższe koszty infrastruktury – możliwość wykorzystania serwerów COTS i standardowego sprzętu sieciowego do uruchamiania funkcji DU/CU. Potencjalnie tańsze RU od wyspecjalizowanych producentów, gdy rynek dojrzeje.
• Brak twardego vendor lock-in – łatwiej wymienić jeden element (np. RIC lub RU) bez wymiany całej sieci. Daje to lepszą pozycję negocjacyjną względem dostawców.
• Szybsze innowacje – nowe funkcje (np. optymalizacja zużycia energii, dynamiczne sterowanie zasobami radiowymi) można dodawać jako xApps/rApps na platformie RIC, bez wymiany całego stosu RAN.
• Elastyczność wdrożeń – możliwość uruchamiania RAN w różnych środowiskach: w lokalnym edge, w regionalnym DC, w chmurze publicznej lub w modelu hybrydowym.

Co budzi największe obawy wśród praktyków

Korzyści są kuszące, ale ich osiągnięcie wymaga zmierzenia się z realnymi wyzwaniami:

• Złożoność integracji – więcej dostawców, więcej kombinacji wersji oprogramowania, więcej scenariuszy testowych. Bez poważnego podejścia do integracji multi-vendor koszty szybko zjadają pierwotne oszczędności.
• Rozproszona odpowiedzialność za bezpieczeństwo – trudniej jednoznacznie wskazać, kto odpowiada za incydent lub lukę w łańcuchu interfejsów, komponentów open source i usług w chmurze.
• Dojrzałość ekosystemu – w wielu krajach dopiero powstają stabilne wdrożenia Open RAN na dużą skalę. Spora część oferty to produkty „w trakcie dojrzewania”, co symptomatycznie wpływa na planowanie długoletniego TCO.
• Niedoszacowanie kosztów kompetencji – potrzebni są ludzie, którzy rozumieją jednocześnie RAN, chmury, konteneryzację, bezpieczeństwo i automatyzację. Taki profil jest drogi i rzadki.

Podstawy RAN w sieci 5G – na czym w ogóle można oszczędzić

Tradycyjny 5G RAN: DU, CU, RU i modele rozmieszczenia

Architektura 5G w warstwie dostępowej wprowadza podział funkcji stacji bazowej na trzy główne elementy:

• RU (Radio Unit) – odpowiada za przetwarzanie sygnału radiowego, modulację, demodulację i interakcję z anteną. To element znajdujący się fizycznie na maszcie lub dachu.
• DU (Distributed Unit) – obsługuje dolne warstwy protokołów (warstwa MAC, część PHY), czasem umieszczony blisko RU (np. w szafie na obiekcie lub w lokalnym punkcie agregacji).
• CU (Centralized Unit) – realizuje wyższe warstwy (RLC, PDCP), zwykle zlokalizowany w bardziej scentralizowanym węźle (site agregacyjny, regionalne DC).

W tradycyjnej implementacji jednego dostawcy ten podział może być częściowo „zaszyty” w jednym fizycznym pudełku albo rozdzielony zgodnie z określonym przez dostawcę modelem. Otwartość interfejsów bywa ograniczona, co utrudnia mieszanie elementów od różnych vendorów.

Architektura 5G pozwala na różne stopnie centralizacji: od bardzo rozproszonej (DU blisko RU) po silnie scentralizowaną (wiele RU obsługiwanych przez DU/CU w dużym węźle). Każdy wariant wpływa na koszty transmisji, opóźnienia, potrzeby energetyczne oraz wymagania co do synchronizacji.

Wąskie gardła kosztowe w tradycyjnym RAN

Z perspektywy CFO ważne jest, które elementy faktycznie „ciągną” budżet:

• Sprzęt dedykowany – zintegrowane stacje bazowe, specjalizowane karty i moduły, które w praktyce można kupić tylko u jednego lub dwóch dużych producentów. Ograniczona konkurencja przekłada się na wysokie ceny.
• Licencje oprogramowania – opłaty za funkcje radiowe, licencje na sektor/pasmo, aktualizacje i wsparcie. Struktura licencyjna bywa skomplikowana, a zmiana dostawcy jest kosztowna.
• Utrzymanie i serwis – kontrakty serwisowe (SLA, części zamienne, on-site support), aktualizacje oprogramowania, wymiana przestarzałych komponentów.
• Integracja i testy – koszt konfiguracji sieci, optymalizacji parametrów radiowych, integracji z core, OSS/BSS, a także regresji przy nowych wersjach softu.

W tle dochodzą jeszcze koszty energii (szczególnie istotne przy dużej gęstości stacji bazowych) oraz wymagań co do lokalnych pomieszczeń technicznych.

CAPEX i OPEX w RAN: gdzie kryje się potencjał oszczędności

Warstwa radiowa stanowi znaczącą część CAPEX (sprzęt, instalacja, klimatyzacja, wieże) w sieci 5G, ale też istotny fragment OPEX (energia, serwis, utrzymanie, licencje). Potencjalne oszczędności z Open RAN koncentrują się w kilku punktach:

• możliwość stopniowej wymiany sprzętu na tańsze RU od nowych graczy,
• uruchamianie DU/CU na wspólnych zasobach serwerowych używanych także do innych funkcji sieci,
• lepsza automatyzacja, która redukuje koszty ręcznej konfiguracji i utrzymania,
• większa konkurencja cenowa wśród dostawców software’u RAN i aplikacji RIC.

Nie wszystkie te oszczędności pojawiają się od razu. Część wymaga osiągnięcia skali (np. wspólnych platform serwerowych dla setek DU/CU), a część jest warunkowana dojrzałością rynku RU i narzędzi automatyzacji.

Jak RAN wpisuje się w całkowity koszt sieci 5G z perspektywy CFO

Dla działu finansowego RAN jest tylko jednym z elementów szerszego obrazu. Całkowity koszt sieci 5G obejmuje również:

• licencje częstotliwości,
• budowę lub dzierżawę lokalizacji (wieże, dachy, pomieszczenia techniczne),
• transmisję (światłowody, dzierżawa łączy),
• siec core (5GC),
• OSS/BSS, billing, CRM,
• koszty organizacyjne: personel, centrum operacyjne, bezpieczeństwo, compliance.

Szacunkowo, w wielu projektach RAN potrafi pochłonąć jedną z największych pozycji sprzętowych CAPEX. Dlatego obietnica „tańszej infrastruktury radiowej” jest tak atrakcyjna. Jednocześnie każdy dodatkowy dostawca i warstwa wirtualizacji wprowadza narzut na koszty integracji, bezpieczeństwa i utrzymania, który w arkuszu CFO musi być rzetelnie uwzględniony, a nie tylko „ukryty” pod pozycją „projekt IT”.

Architektura Open RAN w praktyce – z czego to się składa

Kluczowe elementy Open RAN i ich rola

Architektura Open RAN rozwija tradycyjny podział RU–DU–CU i wprowadza dodatkowe komponenty zarządzające oraz standaryzowane interfejsy. Podstawowy zestaw elementów to:

• RU (O-RU) – otwarty element radiowy, który komunikuje się z DU przez zdefiniowany interfejs fronthaul (np. O-RAN fronthaul). Umożliwia wykorzystanie RU różnych producentów.
• DU (O-DU) – często wirtualizowana funkcja działająca na serwerach COTS, obsługująca dolne warstwy RAN. Interfejsy do RU i CU są standaryzowane.
• CU (O-CU) – warstwa wyższa RAN, typowo w formie VNFs/CNFs, skalowalna poziomo, wdrażana w DC lub edge.
• RIC (RAN Intelligent Controller) – mózg optymalizacji sieci RAN, podzielony na Near-RT RIC (działający blisko czasu rzeczywistego) i Non-RT RIC (działający w dłuższych skalach czasowych).
• OSS/Orkiestracja – systemy do zarządzania konfiguracją, automatyzacją, cyklem życia funkcji wirtualnych, często oparte na rozwiązaniach NFV/SDN lub chmury natywnej.

Każdy z tych elementów może pochodzić od innego dostawcy, pod warunkiem zgodności z odpowiednimi specyfikacjami O-RAN i/lub 3GPP. To otwiera drogę do konkurencji, ale zarazem komplikuje debugowanie, testy i bezpieczeństwo.

O-RAN Alliance, Open RAN i „quasi-open” – istotne różnice

O-RAN Alliance to organizacja definiująca otwarte i interoperacyjne interfejsy, referencyjne architektury i wymagania dla elementów Open RAN. W praktyce istotne są trzy rozróżnienia:

• Open RAN (w szerokim sensie) – ogólna idea otwartego, wielodostawczego RAN, z interoperacyjnymi interfejsami.
• O-RAN (ścisły zestaw specyfikacji) – implementacje, które są zgodne ze specyfikacjami technicznymi O-RAN Alliance (np. O-RAN fronthaul, E2, A1, O1).
• „Quasi-open” rozwiązania single-vendor – jeden dostawca deklaruje zgodność z Open RAN, ale w praktyce interfejsy są „otwarte” głównie w teorii. Zamknięte rozszerzenia, brak pełnej dokumentacji i utrudniona interoperacyjność ograniczają korzyści.

Otwarte interfejsy: fronthaul, midhaul, backhaul w ujęciu Open RAN

Największa różnica między klasycznym a otwartym RAN-em dotyczy sposobu, w jaki elementy RU–DU–CU komunikują się ze sobą. Z punktu widzenia kosztów i bezpieczeństwa kluczowe są trzy warstwy transportu:

• Fronthaul – łączy O-RU z O-DU, zwykle bardzo wymagający pod względem przepływności i opóźnień. W Open RAN jest to interfejs zdefiniowany m.in. przez specyfikacje O-RAN Alliance (np. O-RAN fronthaul). Wymusza większą standaryzację, ale też podnosi oczekiwania wobec jakości sieci transportowej.
• Midhaul – połączenie między O-DU a O-CU. W porównaniu do fronthaulu ma luźniejsze wymagania co do opóźnień, co pozwala na większą elastyczność w lokalizacji DU i CU (np. w regionalnych DC).
• Backhaul – łączy warstwę RAN z core (5GC). Tutaj Open RAN szczególnie korzysta z już ustandaryzowanych interfejsów 3GPP (NG), więc nacisk jest bardziej na skalowalność i bezpieczeństwo transportu niż na nową funkcjonalność.

Z perspektywy budżetu telekomu każda z tych warstw może być optymalizowana niezależnie. W praktyce oznacza to np. możliwość tańszej modernizacji fronthaulu tylko tam, gdzie rzeczywiście występuje duża koncentracja ruchu, a nie „hurtowo” w całej sieci.

RIC, xApps i rApps – „marketplace” funkcji radiowych

RIC jest jedną z najbardziej charakterystycznych części Open RAN. W praktyce działa jak platforma, na którą można „doinstalowywać” funkcje od różnych dostawców:

• Near-RT RIC obsługuje aplikacje xApps, które działają w skali od dziesiątek milisekund do sekund. Mogą to być np. funkcje dynamicznej optymalizacji handoverów czy zarządzania interferencjami.
• Non-RT RIC obsługuje rApps, działające w dłuższych horyzontach (minuty, godziny, dni). Tu trafiają bardziej „analityczne” scenariusze: planowanie pojemności, polityki QoS, optymalizacja zużycia energii.

Ekonomicznie przypomina to sklep z aplikacjami: operator może dokupić konkretną xApp/rApp zamiast inwestować w kosztowną, monolityczną funkcję od jednego vendora. Z drugiej strony każda dodatkowa aplikacja to nowy komponent do certyfikacji bezpieczeństwa i testów regresyjnych. Przy kilku aplikacjach sytuacja jest jeszcze prosta; przy kilkudziesięciu staje się to osobnym projektem integracyjnym, który skutecznie „zjada” założone oszczędności, jeśli nie jest dobrze automatyzowany.

Chmura i wirtualizacja jako fundament Open RAN

Większość wdrożeń Open RAN opiera się na infrastrukturze chmurowej lub NFV. O-DU i O-CU działają jako VNFs lub CNFs na serwerach COTS, co zdejmuje z operatora konieczność kupowania drogiego, dedykowanego sprzętu. Pojawiają się natomiast inne koszty:

• utrzymanie platformy wirtualizacyjnej (Kubernetes, OpenStack, VMware lub chmura publiczna),
• monitorowanie wydajności i bezpieczeństwa na poziomie hostów, węzłów i sieci wirtualnej,
• upgrade’y platformy, które muszą być zsynchronizowane z cyklem życia funkcji RAN.

Niegłupim podejściem na start bywa ograniczenie różnorodności stosów – np. jeden preferowany OS, jedna dystrybucja Kubernetesa, jeden system obserwowalności. Mniej „pudełek” do obsługi to mniej kosztownych niespodzianek podczas aktualizacji.

Argument ekonomiczny: gdzie realnie można ciąć koszty dzięki Open RAN

Sprzęt RU: presja na ceny i elastyczność dostaw

Otwarty interfejs fronthaul umożliwia mieszanie RU różnych producentów z tym samym DU/CU. Dla finansów oznacza to kilka konkretnych dźwigni:

• negocjacje cenowe – przy kilku równorzędnych dostawcach RU łatwiej wynegocjować lepsze warunki cenowe i gwarancyjne, szczególnie przy dużej skali zakupów,
• dywersyfikacja łańcucha dostaw – mniejsze ryzyko opóźnień projektów z powodu problemów produkcyjnych jednego producenta,
• stopniowa modernizacja – możliwość wymiany tylko RU (np. na nowsze pasma lub MIMO) bez ruszania DU/CU.

W praktyce kilku operatorów zaczynało od pilotażu na ograniczonej liczbie stacji (np. w jednym mieście), gdzie RU od nowego vendora było istotnie tańsze od rozwiązań incumbentów. Kluczowe jest jednak uwzględnienie: integracji, testów, szkoleń terenowych i logistyki części zamiennych. Tanio kupione RU szybko przestaje być tanie, jeśli do każdej awarii potrzeba specjalnej ekipy z unikalnymi kompetencjami.

Wirtualizacja DU/CU i współdzielenie infrastruktury

Przeniesienie DU/CU na wspólne serwery COTS daje szansę na:

• lepsze wykorzystanie mocy obliczeniowej – te same klastry mogą obsługiwać RAN, część funkcji core, a nawet wybrane systemy IT, o ile pozwala na to polityka bezpieczeństwa,
• elastyczne skalowanie – uruchamianie nowych instancji DU/CU w godzinach szczytu i ich wygaszanie poza szczytem, co poprawia TCO energii i licencji,
• ograniczenie „wysp sprzętowych” – mniej unikalnych konfiguracji w terenie, prostsze zarządzanie zapasami serwerów i części.

Rzeczywisty efekt pojawia się dopiero przy rozsądnej skali. Kilka pojedynczych węzłów DU/CU w chmurze potrafi być nawet droższe niż klasyczne podejście, bo przewaga kosztowa wynika z masy – automatyzacji, zunifikowanego monitoringu i wielokrotnego wykorzystania tej samej platformy.

Automatyzacja operacji: od instalacji po optymalizację

Open RAN i chmura sprzyjają daleko idącej automatyzacji. Z punktu widzenia finansów istotne są głównie trzy obszary:

• provisioning i konfiguracja – automatyczne wdrażanie nowych stacji (Zero Touch Provisioning) ogranicza liczbę wizyt techników w terenie,
• aktualizacje oprogramowania – masowe roll-outy nowych wersji DU/CU/RIC sterowane centralnie, z rollbackiem w razie problemów, zmniejszają czas okien serwisowych i ryzyko błędów ludzkich,
• autonomiczna optymalizacja – xApps/rApps mogą ograniczyć konieczność ręcznego strojenia parametrów radiowych przez inżynierów RF.

Na początek nie trzeba budować w pełni autonomicznej sieci. Ekonomicznie sensowne jest wdrożenie kilku praktycznych automatyzacji: standaryzowany szablon konfiguracji site’u, pipeline CI/CD dla funkcji RAN oraz podstawowy monitoring zdrowia xApps/rApps. To stosunkowo tanie kroki, które szybko pokazują wymierną oszczędność czasu i roboczogodzin.

Model multi-vendor jako dźwignia negocjacyjna

Nawet jeżeli operator nie planuje od razu szerokiego miksowania vendorów, sam fakt posiadania technicznie działającej alternatywy (np. pilota Open RAN z innym dostawcą) znacząco wzmacnia pozycję negocjacyjną w kolejnych rundach zakupów:

• łatwiej wymagać przejrzystych cenników i prostszych modeli licencjonowania,
• istnieje realna groźba przeniesienia części wolumenu do konkurencji,
• dostawcy tradycyjni częściej oferują „hybrydowe” modele wsparcia, a nie wyłącznie pełen outsourcing.

Żeby ten efekt był wiarygodny, pilot nie może być „na slajdach” – potrzebne jest kilka działających lokalizacji z mierzalnymi parametrami KPI. Nawet ograniczone wdrożenie w jednym regionie może być wystarczającym argumentem przy stole negocjacyjnym.

Ryzyka cyber w Open RAN – więcej dostawców, więcej wektorów ataku

Nowe powierzchnie ataku w architekturze Open RAN

W klasycznym RAN powierzchnia ataku koncentruje się głównie na fizycznych stacjach bazowych i interfejsach do core. W Open RAN do gry dochodzą:

• otwarte interfejsy (E2, A1, O1, O2) – więcej API, więcej protokołów, z którymi trzeba sobie poradzić,
• RIC i aplikacje xApps/rApps – dodatkowa warstwa logiki sterującej RAN, często rozwijana przez mniejszych vendorów lub integratorów,
• platforma chmurowa – podatności na poziomie hypervisora, Kubernetesa, CNI, storage’u, które mogą przełożyć się na kompromitację funkcji RAN,
• łańcuch dostaw oprogramowania – biblioteki open source, kontenery, narzędzia CI/CD używane przez różne podmioty.

Każdy z tych elementów może stać się punktem wejścia. Przy architekturze jedno-vendorowej da się jeszcze „zasłonić” część ryzyk za kontraktem i certyfikacją dostawcy. W pełnym Open RAN odpowiedzialność jest bardziej rozproszona, co wymaga lepszej widoczności end-to-end i precyzyjnych podziałów odpowiedzialności w umowach.

Scenariusze ataków specyficzne dla Open RAN

Atakujący zyskują kilka nowych możliwości wpływu na sieć:

• manipulacja RIC/xApps – złośliwa lub skompromitowana xApp może sterować parametrami radiowymi w sposób prowadzący do przeciążenia wybranych komórek, degradacji jakości usług lub celowego „zacieniania” obszarów zasięgu,
• atak na interfejs E2 – przejęcie kontroli nad kanałem między Near-RT RIC a O-DU/O-CU umożliwia wstrzykiwanie nieautoryzowanych komend sterujących,
• podszywanie się pod komponent OAM – niewystarczająco zabezpieczone API O1/O2 może pozwolić na nieuprawnione zmiany konfiguracji lub pozyskanie wrażliwych danych inwentaryzacyjnych,
• lateral movement w klastrze chmurowym – kompromitacja jednego kontenera może posłużyć do eskalacji uprawnień i przejęcia kontroli nad innymi elementami RAN działającymi na tym samym klastrze.

Dla operatora istotne jest, aby te scenariusze były jasno opisane w modelu zagrożeń. Na tej podstawie buduje się konkretne wymagania do vendorów: szyfrowanie, uwierzytelnianie wzajemne, segmentację sieciową, logowanie i mechanizmy detekcji anomalii.

Łańcuch dostaw: od kodu źródłowego po obraz kontenera

Open RAN w praktyce oznacza silniejsze poleganie na komponentach programowych od wielu podmiotów. Typowy łańcuch dostaw może wyglądać tak:

1. dostawca tworzy kod źródłowy (często z dużym udziałem bibliotek open source),
2. kod jest budowany w pipeline CI/CD,
3. powstaje obraz kontenera lub paczka binarna,
4. obraz trafia do rejestru (registry) i jest dalej dystrybuowany do operatora,
5. operator wdraża go na swoim klastrze.

Na każdym z tych etapów może dojść do zainfekowania kodu (np. złośliwe biblioteki, „tylne drzwi” w pipeline, przejęty rejestr obrazów). Rozsądne minimum to:

• skanowanie bezpieczeństwa obrazów kontenerów przed wdrożeniem (SCA, SAST/DAST),
• podpisywanie obrazów i weryfikacja podpisów (Sigstore, Notary, podobne rozwiązania),
• jasny proces zarządzania podatnościami (SBoM, CVE, czas reakcji vendora na krytyczne luki).

Bez takiego minimum różnorodność vendorów przestaje być przewagą, a staje się niekontrolowaną mozaiką ryzyk, w której trudno nawet ustalić, kto powinien załatać daną lukę i w jakim terminie.

Standardy, regulacje i wytyczne bezpieczeństwa dla Open RAN

Rola O-RAN Alliance i 3GPP w definiowaniu wymagań

Specyfikacje O-RAN Alliance skupiają się przede wszystkim na interoperacyjności i architekturze. Część dokumentów (np. dotyczących interfejsów O1/O2, E2, A1) zawiera wymagania bezpieczeństwa, ale nie jest to pełny framework cyber. Bezpieczeństwo „horyzontalne” (np. szyfrowanie, certyfikaty, polityki dostępu) w dużym stopniu dziedziczone jest z:

• 3GPP (seria 33.x) – ogólne wymagania bezpieczeństwa dla sieci mobilnych, w tym 5G,
• standardów branżowych – takich jak ETSI NFV (bezpieczeństwo wirtualizacji) czy GSMA NESAS (ocena bezpieczeństwa vendorów i produktów).

Przy projektowaniu Open RAN dobrze jest zbudować macierz: który aspekt bezpieczeństwa jest pokryty którym standardem i jak przekłada się to na konkretne zapisy w umowach z dostawcami. To żmudna praca, ale znacznie ułatwia audyty i rozmowy z regulatorami.

Wytyczne rządowe i sektorowe

W wielu krajach Open RAN trafia pod lupę regulatorów telekomunikacyjnych i instytucji odpowiedzialnych za bezpieczeństwo narodowe. Pojawiają się m.in.:

• listy dostawców wysokiego ryzyka oraz ograniczenia udziału określonych podmiotów w budowie infrastruktury RAN,

Implementacja standardów bezpieczeństwa w praktyce operatora

Same odwołania do 3GPP, O-RAN Alliance czy ETSI w dokumentacji przetargowej niewiele dają, jeśli nie są przełożone na konkretne kontrole i procedury. W praktyce przy Open RAN zwykle kończy się na trzech poziomach implementacji:

• poziom architektoniczny – zdefiniowane strefy bezpieczeństwa (core, RAN, zarządzanie, chmura), reguły segmentacji sieci oraz minimalny zestaw protokołów dopuszczonych między komponentami,
• poziom produktowy – checklista wymagań dla każdego komponentu (O-DU, O-CU, RIC, SMO, platforma chmurowa), w której mapuje się zapisy standardów na realne funkcje: rodzaje szyfrowania, obsługiwane metody uwierzytelniania, mechanizmy logowania,
• poziom procesowy – sposób utrzymania bezpieczeństwa w czasie: aktualizacje, testy penetracyjne, przeglądy konfiguracji, zarządzanie kluczami.

Najtańsze w uruchomieniu są proste checklisty produktowe i szablony architektury. Jednorazowe przygotowanie wzorcowego modelu stref i podstawowych reguł (np. „xApps nigdy nie łączą się bezpośrednio z O-CU”, „OAM/O1 tylko z sieci zarządzającej z silną autoryzacją”) później wielokrotnie się zwraca – ogranicza jałowe dyskusje z każdym nowym vendorem.

Regulator, NIS2 i krajowe wymogi dla sieci 5G

Open RAN wchodzi na rynek w momencie, gdy sektor telekomunikacyjny coraz mocniej podlega regulacjom bezpieczeństwa (NIS2, krajowe ustawy o KSC, wymogi dla operatorów usług kluczowych). Dla projektów RAN oznacza to kilka dodatkowych warstw formalnych:

• klasyfikacja usług – określenie, które elementy Open RAN podpadają pod „usługę kluczową” lub „usługę istotną”, a co można traktować jako wsparcie techniczne poza głównym zakresem,
• obowiązki raportowania incydentów – konieczność zapewnienia takich logów i korelacji zdarzeń, aby dało się odróżnić awarię techniczną od incydentu cyber,
• wymogi dotyczące podwykonawców – wpisanie do kontraktów wymogów NIS2, w tym przejrzystości łańcucha dostaw i obowiązku informowania o podatnościach.

Przy ograniczonym budżecie sensownym kompromisem jest wzięcie istniejącego frameworka bezpieczeństwa operatora (np. ISO 27001, lokalne wytyczne dla core) i rozszerzenie go o specyfikę Open RAN. Zamiast doklejać nowe, równoległe procedury tylko dla jednego pilota, taniej jest dołączyć Open RAN do już działającej machiny compliance.

Certyfikacja i ocena dostawców Open RAN

Wielu operatorów nie ma zasobów, żeby samodzielnie prowadzić głębokie audyty bezpieczeństwa każdego vendora xApps czy wyspecjalizowanych komponentów RIC. Zamiast tego warto korzystać z istniejących schematów oceny:

• GSMA NESAS – daje pewien poziom zaufania do procesu wytwórczego vendora i bezpieczeństwa samego produktu,
• krajowe listy „approved vendors” – tam, gdzie regulator publikuje rekomendacje lub białe listy, dobrze jest je skorelować z planem zakupowym,
• testy wspólne z innymi operatorami – np. w ramach branżowych laboratoriów Open RAN; koszty rozkładają się na wielu uczestników.

Minimalistyczne podejście, które często wystarcza na start, to wymaganie od vendora: raportu z NESAS (lub równoważnego audytu), podstawowych raportów z testów penetracyjnych oraz deklaracji wsparcia dla SBoM. To już filtruje dostawców „garażowych”, a nie wymaga od operatora budowania własnego, rozbudowanego programu oceny.

Open RAN a bezpieczeństwo operacyjne: monitoring, detekcja, reakcja

Co faktycznie monitorować w środowisku Open RAN

W klasycznym RAN monitoring skupia się na KPI radiowych i dostępności site’ów. Open RAN dodaje nowe kategorie sygnałów, które trzeba zebrać i połączyć:

• metryki aplikacyjne RIC/xApps/rApps – liczba decyzji sterujących, opóźnienia, błędy logiki, nagłe zmiany w profilu działań,
• logi bezpieczeństwa z interfejsów O1/O2/E2/A1 – nieudane logowania, zmiany konfiguracji, próby zestawienia nieautoryzowanych sesji,
• telemetria z platformy chmurowej – restartujące się pody, skoki zużycia CPU/RAM, zmiany polityk Kubernetesa,
• klasyczne KPI RAN – handover, drop call, throughput – ale korelowane z wydarzeniami w RIC i na poziomie chmury.

Z ekonomicznego punktu widzenia nie ma sensu budować osobnego systemu monitoringu tylko dla Open RAN. Dużo skuteczniejszy (i tańszy w utrzymaniu) jest model, w którym logi i metryki trafiają do już istniejącej platformy SIEM/observability, z dodaniem kilku dedykowanych dashboardów i alertów.

Integracja sygnałów radiowych i bezpieczeństwa

Największą trudnością nie jest samo zebranie danych, ale sensowna korelacja zdarzeń. Przykład z praktyki: nagły spadek przepustowości w wybranych komórkach na pierwszy rzut oka wygląda jak zwykłe przeciążenie. Dopiero po zestawieniu z logami RIC okazuje się, że jedna z xApps zaczęła agresywnie modyfikować parametry schedulera w tym regionie.

Podstawowy poziom integracji można osiągnąć stosunkowo niskim kosztem:

• zdefiniowanie kilku prostych reguł korelacyjnych w SIEM (np. „nagła zmiana konfiguracji przez O1 + wzrost błędów RAN w tym regionie” => zdarzenie wysokiego priorytetu),
• wymuszenie na vendorach RIC i SMO spójnego formatu logów (czas, identyfikatory komórek, identyfikator xApp/rApp),
• wdrożenie centralnego katalogu mapującego identyfikatory komponentów Open RAN do regionu/sieci, co ułatwia analitykom SOC szybkie określenie zasięgu skutków.

Nie jest to zaawansowana analityka behawioralna ani ML, ale dla większości realnych incydentów daje wystarczającą widoczność przy relatywnie małym nakładzie.

Zarządzanie konfiguracją i „drift” w środowisku wielovendorowym

W Open RAN warstwa konfiguracji staje się jednym z kluczowych obszarów ryzyka. Różni vendorzy mogą inaczej interpretować te same parametry, a zmiany w jednym elemencie (np. wersja xApp) mogą wymagać subtelnej korekty w innych.

Żeby utrzymać kontrolę i nie pogrążyć się w ręcznym porównywaniu plików YAML, przydaje się kilka prostych zasad:

• infrastruktura jako kod (IaC) dla konfiguracji RAN tam, gdzie to możliwe – nawet jeżeli nie wszystko da się zautomatyzować, już częściowe ujednolicenie wzorców konfiguracyjnych robi różnicę,
• kontrola wersji konfiguracji (Git lub równoważny system) z możliwością odtworzenia stanu z konkretnej daty,
• regularne skany driftu – porównanie stanu rzeczywistego z tym zapisanym w repozytorium; rozbieżności powinny automatycznie generować zgłoszenia.

Taki „lekki” model GitOps nie wymaga od razu pełnej automatyzacji wdrożeń, a już ogranicza ryzyko nieautoryzowanych lub nieudokumentowanych zmian, które często są początkiem poważniejszych incydentów.

Procedury reagowania na incydent w Open RAN

Plan reagowania na incydenty cyber w sieci mobilnej zwykle jest zorientowany na core i systemy IT. W przypadku Open RAN trzeba doszyć do niego kilka nowych wątków:

• możliwość szybkiego „odłączenia” xApp/rApp – jasno opisany proces „emergency disable”, ze zdefiniowanym czasem reakcji i odpowiedzialnością (operator vs vendor RIC),
• tryb degradacji kontrolowanej – scenariusze, w których RAN przechodzi na bezpieczniejszy, mniej zautomatyzowany tryb (np. wyłączenie dynamicznej optymalizacji w danym regionie),
• komunikacja między RF/Operations a SOC – szybkie kanały przekazywania informacji o podejrzanych zdarzeniach, które z perspektywy samego RF mogą wyglądać jak typowa awaria.

Z perspektywy kosztów najważniejsze jest, żeby nie pisać całkowicie od nowa planu IR, tylko rozszerzyć istniejące playbooki o jeden–dwa scenariusze specyficzne dla Open RAN (np. „kompromitacja xApp” i „podejrzenie ataku na interfejs E2”). Takie „modus operandi” można potem ćwiczyć w ramach krótkich, tanich ćwiczeń typu table-top.

Rola dostawców w SOC i utrzymaniu bezpieczeństwa

Przy ograniczonym zespole wewnętrznym naturalne jest delegowanie części zadań bezpieczeństwa na vendorów – ale w modelu Open RAN trzeba to zrobić ostrożniej niż przy jednym dostawcy end-to-end. Kilka punktów, które zwykle robią różnicę:

• jasno zdefiniowane SLO bezpieczeństwa w kontraktach (czas reakcji na incydent, czas dostarczenia łatek, dostępność ekspertów L3 w incydentach krytycznych),
• współdzielone dashboardy – zamiast prosić vendora o pliki z logami po fakcie, lepiej wymagać bieżącego dostępu do wybranych metryk i alarmów,
• konkretne wymagania co do integracji z SIEM – format logów, częstotliwość, sposób przekazywania.

Kluczem jest uniknięcie sytuacji, w której każdy vendor proponuje własny „portal bezpieczeństwa” z osobnym logowaniem. To kuszące z punktu widzenia sprzedawcy, ale dla operatora oznacza mnożenie narzędzi i zwiększenie kosztów operacyjnych. Lepiej wymusić jednolitą integrację z centralnym SOC, nawet jeśli początkowo oznacza to mniej „ładnych” funkcji po stronie narzędzi vendora.

Bezpieczeństwo a testbedy i środowiska pilotażowe

Pilotaż Open RAN często jest traktowany jako „piaskownica”, gdzie można luźniej podejść do procedur bezpieczeństwa. To pozorna oszczędność. Środowisko testowe, do którego mają dostęp zewnętrzni integratorzy, studenci czy partnerzy technologiczni, bywa najsłabszym ogniwem – szczególnie jeśli łączy się w jakiś sposób z siecią produkcyjną.

Niewielkim kosztem można zamknąć kilka najczęstszych dziur:

• oddzielenie sieciowo pilota od produkcji (firewalle, brak bezpośredniego routingu, wyraźnie oznaczone punkty styku),
• stosowanie tych samych standardów haseł, MFA i zarządzania dostępami co w produkcji,
• okresowe „czyszczenie” pilota: usuwanie nieużywanych kont, wyłączanie zapomnianych komponentów, które pozostały po wcześniejszych testach.

Jeśli pilot technicznie działa i ma szansę przerodzić się w wdrożenie produkcyjne, inwestowanie w jego bezpieczeństwo na wczesnym etapie oszczędzi kosztownego „dozbrajania” później, kiedy architektura jest już usztywniona i trudniej coś zmienić bez przerw w usługach.

Najczęściej zadawane pytania (FAQ)

Czym dokładnie jest Open RAN w sieciach 5G?

Open RAN to sposób budowania warstwy radiowej 5G z wykorzystaniem otwartych, standaryzowanych interfejsów między elementami takimi jak RU, DU i CU. Zamiast jednego zamkniętego „pudełka” od jednego producenta, operator może zestawić sieć z kilku komponentów różnych dostawców.

Kluczowe jest tu rozdzielenie funkcji na mniejsze klocki i możliwość ich niezależnego doboru. Dzięki temu łatwiej jest wymienić tylko jeden element (np. głowicę radiową lub oprogramowanie sterujące), bez przepinania całej infrastruktury na nowego vendora.

Na czym można realnie zaoszczędzić dzięki Open RAN?

Największy potencjał oszczędności leży w sprzęcie i licencjach. DU i CU można uruchamiać na standardowych serwerach COTS, zamiast inwestować w drogie, dedykowane platformy. Pojawia się też szansa na tańsze jednostki RU od nowych producentów, gdy rynek się nasyci.

Drugie źródło oszczędności to mniejsze uzależnienie od jednego dostawcy. Mając możliwość mieszania komponentów, operator ma lepszą pozycję negocjacyjną przy przedłużaniu kontraktów i zakupie dodatkowych licencji. Część kosztów (np. integracja multi‑vendor, testy, bezpieczeństwo) jednak wzrośnie, więc kalkulacja musi uwzględniać pełne TCO, a nie tylko cenę sprzętu.

Czy Open RAN jest bezpieczny, czy zwiększa ryzyko cyberataków?

Open RAN nie jest z definicji mniej bezpieczny, ale ma inną strukturę ryzyka. Więcej otwartych interfejsów i więcej dostawców oznacza większą powierzchnię ataku oraz bardziej rozproszoną odpowiedzialność za incydenty. Szczególnie newralgiczne są styki RU–DU–CU oraz integracje z systemami zarządzania i chmurą.

Żeby utrzymać poziom bezpieczeństwa, trzeba mocniej zainwestować w testy, hardening i monitoring tych interfejsów oraz w procesy zarządzania podatnościami u każdego dostawcy z osobna. Tam, gdzie budżet jest napięty, rozsądnym minimum jest: jasny podział odpowiedzialności w umowach, centralny SOC obejmujący całą warstwę RAN i regularne testy bezpieczeństwa integracji multi‑vendor.

Czy Open RAN zawsze oznacza użycie open source?

Nie. Open RAN oznacza przede wszystkim otwarte, zdefiniowane standardami interfejsy i otwartą architekturę, a nie obowiązkowe korzystanie z oprogramowania open source. Krytyczne elementy sieci, takie jak DU, CU czy część funkcji RIC, bardzo często pozostają komercyjne i zamknięte.

Open source pojawia się najczęściej w warstwie orkiestracji, automatyzacji czy jako komponenty w RIC. Dla działu finansów i bezpieczeństwa ważniejsze od licencji (open source vs komercja) jest to, czy interfejsy są dobrze udokumentowane, wspierane i możliwe do przetestowania pod kątem bezpieczeństwa oraz interoperacyjności.

Dla jakich operatorów i firm Open RAN ma największy sens biznesowy?

Największy sens ma tam, gdzie skala sieci jest na tyle duża, że opłaca się inwestować w integrację multi‑vendor i budowę kompetencji. Duzi operatorzy komórkowi mogą dzięki temu negocjować lepsze warunki, stopniowo wymieniać elementy RAN i optymalizować koszty energii oraz utrzymania.

Dla mniejszych graczy (np. sieci prywatne 5G, lokalni operatorzy) opłacalny może być wariant „na start” z jednym głównym integratorem Open RAN, który dostarcza gotowy, przetestowany stack i ogranicza złożoność. W takim modelu elastyczność jest mniejsza niż przy pełnym multi‑vendor, ale nakłady na kompetencje i integrację są znacząco niższe.

Jakie są największe wyzwania przy wdrażaniu Open RAN w praktyce?

Najtrudniejsza jest integracja wielu dostawców i utrzymanie zgodności wersji oprogramowania na całej długości łańcucha RU–DU–CU–RIC–OSS/BSS. Bez solidnych procesów testowych i automatyzacji aktualizacji początkowe oszczędności szybko zjadają dodatkowe godziny pracy inżynierów i dłuższe okna serwisowe.

Drugie wyzwanie to kompetencje: potrzebne są zespoły, które rozumieją jednocześnie RAN, chmury, konteneryzację i bezpieczeństwo. W praktyce wiele firm zaczyna od pilota na ograniczonym obszarze, współpracując z doświadczonym integratorem, a dopiero potem stopniowo przenosi część wiedzy i narzędzi „in‑house”, co pozwala rozłożyć koszty w czasie.

Jak ocenić, czy Open RAN obniży TCO w mojej organizacji?

Najprostsze podejście to zestawienie dwóch scenariuszy TCO na kilka lat: klasyczny RAN jednego dostawcy vs RAN oparty na Open RAN, licząc łącznie CAPEX i OPEX. W kalkulacji trzeba uwzględnić nie tylko ceny sprzętu i licencji, ale też koszty integracji, testów, energii, szkoleń, utrzymania i bezpieczeństwa.

Praktycznym krokiem „low‑cost” jest mały pilotaż Open RAN w wybranym regionie lub dla konkretnego pasma, z precyzyjnym pomiarem kosztów wdrożenia i utrzymania. Taki pilotaż daje własne dane do kalkulacji, zamiast opierania się wyłącznie na slajdach dostawców i ogólnych benchmarkach z rynku.