Topologia sieci Private 5G: on-premise core vs chmura publiczna. Co wybrać?

Czy dane przemysłowe z hal produkcyjnych powinny opuszczać teren zakładu, a każda milisekunda opóźnienia w sterowaniu autonomicznymi wózkami AGV może decydować o ciągłości operacyjnej? Przed takim dylematem staje każdy inżynier i dyrektor IT planujący wdrożenie prywatnej sieci łączności komórkowej (Private 5G / P5G). Wybór między instalacją rdzenia sieci (5G Core – 5GC) w lokalnym centrum danych (on-premise) a uruchomieniem go w chmurze publicznej nie jest wyłącznie decyzją o alokacji budżetu między CAPEX a OPEX. To przede wszystkim strategiczny wybór określający niezawodność, suwerenność danych oraz odporność przedsiębiorstwa na awarie łączy nadrzędnych.

Prywatne sieci 5G przestają być jedynie domeną operatorów telekomunikacyjnych, stając się integralnym elementem architektury OT/IT w przemyśle, logistyce, energetyce czy medycynie. Różnice technologiczne i eksploatacyjne między poszczególnymi modelami wdrożenia rdzenia są fundamentalne. Zrozumienie relacji pomiędzy płaszczyzną sterowania (Control Plane), płaszczyzną danych użytkownika (User Plane) a infrastrukturą radiową (RAN) stanowi punkt wyjścia do stworzenia bezbłędnej specyfikacji technicznej.

Anatomia prywatnej sieci 5G a lokalizacja rdzenia (5GC)

Rdzeń sieci 5G w architekturze Standalone (5G SA) został zaprojektowany w modelu opartym na usługach (Service-Based Architecture – SBA). Oznacza to, że funkcje sieciowe nie są już monolitycznymi urządzeniami sprzętowymi, lecz zwirtualizowanymi lub skonteneryzowanymi mikroserwisami, które komunikują się ze sobą za pośrednictwem ustandaryzowanych interfejsów API opartych na protokole HTTP/2. Ta elastyczność sprawia, że poszczególne elementy rdzenia mogą być fizycznie rozproszone pomiędzy lokalną serwerownią a chmurą publiczną.

Kluczowe komponenty: Control Plane vs User Plane (UPF)

Dla zrozumienia topologii P5G decydujące znaczenie ma separacja funkcji płaszczyzny sterowania od płaszczyzny danych (Control and User Plane Separation – CUPS). Płaszczyzna sterowania (Control Plane) obejmuje moduły odpowiedzialne za zarządzanie mobilnością (AMF – Access and Mobility Management Function), sesjami (SMF – Session Management Function), uwierzytelnianiem i politykami bezpieczeństwa (AUSF, UDM, PCF). Funkcje te generują stosunkowo niewielki ruch sieciowy o charakterze sygnalizacyjnym.

Z kolei płaszczyzna danych opiera się na module UPF (User Plane Function). To przez UPF przepływa 100% właściwego ruchu generowanego przez urządzenia końcowe (kamery przemysłowe, czujniki telemetryczne, pojazdy autonomiczne czy panele HMI). Lokalizacja modułu UPF determinuje fizyczną trasę pakietu danych: czy ruch z maszyny trafia bezpośrednio do lokalnego systemu SCADA/MES, czy też musi pokonać drogę przez zewnętrzne łącze WAN do chmury obliczeniowej.

Rola warstwy radiowej (RAN) w relacji do rdzenia sieci

Warstwa dostępu radiowego (Radio Access Network – RAN), składająca się z anten (RU – Radio Unit), jednostek dystrybucyjnych (DU – Distributed Unit) oraz jednostek centralnych (CU – Centralized Unit), zawsze musi znajdować się fizycznie na terenie chronionego obiektu. RAN odpowiada za modulację sygnału, przydział zasobów radiowych i bezpośrednią komunikację ze stacjami bazowymi (gNodeB).

Relacja pomiędzy RAN a rdzeniem 5GC opiera się na interfejsach N2 (sygnalizacja Control Plane) oraz N3 (dane User Plane). Jeśli cała infrastruktura rdzenia znajduje się w chmurze, obydwa interfejsy muszą być zestawione przez łącze WAN. Jeśli wdrożono architekturę hybrydową, interfejs N3 zamyka się lokalnie, a jedynie N2 kierowany jest do instancji chmurowej.

Podstawowe warianty architektoniczne na rynku

W praktyce inżynieryjnej wyróżnia się trzy główne modele rozmieszczenia komponentów prywatnej sieci 5G:

• Pełny On-Premise (Private-All): Wszystkie elementy – RAN, UPF oraz pełny Control Plane 5GC – znajdują się w lokalnym centrum danych na dedykowanym sprzęcie (bare-metal lub lokalny klaster Kubernetes).
• Model w 100% Chmurowy (Cloud-Native Core): RAN działa lokalnie w fabryce, natomiast cały rdzeń (Control Plane oraz UPF) jest hostowany w chmurze hyperscalera (AWS, Microsoft Azure, Google Cloud). Cały ruch danych opuszcza obiekt.
• Model Hybrydowy (Split-Control / Edge UPF): RAN oraz funkcja UPF pozostają on-premise (zapewniając lokalny breakout ruchu), podczas gdy nadrzędne funkcje zarządzania i Control Plane są utrzymywane w chmurze dostawcy lub operatora.

Jeśli profil przedsiębiorstwa wymaga przetwarzania wrażliwych danych operacyjnych z zerową tolerancją na awarie łączności zewnętrznej, to pełny on-premise stanowi punkt odniesienia do dalszych analiz. Jeśli natomiast celem jest szybkie uruchomienie sieci pilotażowej przy minimalnym koszcie infrastrukturalnym, model chmurowy pozwala na elastyczny start.

Wariant pełny on-premise – maksymalna suwerenność i determinizm

Wdrożenie pełnego rdzenia 5G on-premise to podejście bezkompromisowe pod względem bezpieczeństwa i wydajności. W tym scenariuszu infrastruktura telekomunikacyjna staje się autonomiczną wyspą, w pełni niezależną od publicznego Internetu, zewnętrznych dostawców chmurowych czy operatorów telekomunikacyjnych.

Zalety operacyjne: brak zależności od łącza WAN i minimalne opóźnienia

Kluczowym atutem modelu on-premise jest determinizm czasowy. W aplikacjach z obszaru Przemysłu 4.0, takich jak sterowanie ramionami robotów w pętli zamkniętej

(closed-loop control) czy koordynacja floty wózków AGV/AMR przemieszczających się z dużą prędkością, akceptowalne opóźnienia pakietów (RTT – Round Trip Time) muszą wynosić poniżej 10–15 ms, a w skrajnych przypadkach poniżej 5 ms. Lokalny rdzeń sieciowy eliminuje zmienność (jitter) wynikającą z trasowania ruchu przez publiczny Internet czy łącza MPLS.

Drugim fundamentalnym filarem jest tzw. air-gap readiness, czyli zdolność zakładu do nieprzerwanej pracy nawet w przypadku całkowitego zerwania łączności ze światem zewnętrznym (np. w wyniku fizycznego uszkodzenia światłowodu doprowadzającego Internet do fabryki). W pełnym modelu on-premise lokalny AMF i SMF nadal rejestrują terminale, przydzielają adresację IP, a UPF nieprzerwanie przekazuje pakiety pomiędzy urządzeniami a lokalnymi serwerami aplikacyjnymi.

Wyzwania wdrożeniowe: wysoki CAPEX i złożoność operacyjna

Niezależność operacyjna wiąże się jednak z istotnymi barierami wejścia. Wdrożenie pełnego rdzenia na terenie zakładu wymaga inwestycji w certyfikowaną infrastrukturę serwerową (często w układzie wysokiej dostępności HA z pełną redundancją zasilania i chłodzenia) oraz oprogramowanie do orkiestracji kontenerów klasy enterprise (np. Red Hat OpenShift czy VMware Tanzu).

Kolejnym wyzwaniem jest zarządzanie cyklem życia oprogramowania (Lifecycle Management). Aktualizacje poprawek bezpieczeństwa, podnoszenie wersji mikroserwisów 5GC oraz monitoring wskaźników KPI sieci radiowej i rdzeniowej spoczywają bezpośrednio na wewnętrznym zespole inżynierów sieciowych lub wymagają zakupu kosztownych kontraktów serwisowych (SLA) u integratora.

Rdzeń w chmurze publicznej – elastyczność i skalowalność dla rozproszonych lokalizacji

Podejście oparte na chmurze publicznej (np. usługi AWS Private 5G, Azure Private 5G Core) radykalnie zmienia sposób zarządzania siecią komórkową. W tym modelu cały skomplikowany stos oprogramowania rdzenia jest uruchamiany, konfigurowany i monitorowany z poziomu konsoli chmurowej dostawcy hyperscale.

Dla organizacji posiadających wiele mniejszych, geograficznie rozproszonych obiektów (np. sieć 20 centrów logistycznych w całym kraju), model ten eliminuje konieczność zakupu i utrzymywania 20 osobnych klastrów serwerowych dla rdzenia. Wystarczy instalacja warstwy radiowej RAN w każdym obiekcie i spięcie jej bezpiecznym tunelem IPsec lub dedykowanym łączem (AWS Direct Connect / Azure ExpressRoute) z centralnym rdzeniem w chmurze.

Model ten niesie jednak dwa zasadnicze ograniczenia: wrażliwość na parametry łącza WAN oraz koszty transferu danych (data egress). Jeśli kamery monitoringu wizyjnego AI przesyłają strumienie 4K przez sieć 5G bezpośrednio do UPF w chmurze, koszty pasma zewnętrznego mogą szybko przewyższyć oszczędności z braku lokalnych serwerów. Co więcej, chwilowa degradacja łącza internetowego prowadzi do natychmiastowych zakłóceń w komunikacji maszyn.

Wariant hybrydowy (Edge UPF) – złoty środek dla nowoczesnego przemysłu

Najczęściej wybieranym kompromisem w zaawansowanych projektach przemysłowych staje się architektura hybrydowa. Polega ona na fizycznym rozdzieleniu płaszczyzny sterowania i danych:

Funkcje Control Plane (zarządzanie, uwierzytelnianie, billing, panele analityczne) są hostowane centralnie w chmurze, co daje wygodę jednolitego zarządzania wszystkimi lokalizacjami z jednego miejsca. Z kolei instancja UPF zostaje zainstalowana lokalnie na niewielkim serwerze brzegowym (Edge Server) w fabryce. Dzięki temu ruch roboczy maszyn nie opuszcza sieci lokalnej, opóźnienia pozostają minimalne, a polityka bezpieczeństwa danych zostaje w pełni zachowana.

Warto przeczytać również powiązany artykuł: Jak 5G zmienia IoT i przemysł w praktyce.

Warto pamiętać o zachowaniu funkcji hybrydowej przy awarii WAN: w przypadku utraty połączenia z chmurą istniejące już sesje transmisyjne na lokalnym UPF mogą być nadal podtrzymywane, jednak podłączenie nowego urządzenia czy ponowne uwierzytelnienie karty SIM wymaga aktywnego łącza do chmurowego Control Plane.

Porównanie modeli architektonicznych

Jak dopasować architekturę do profilu przedsiębiorstwa?

Wybór topologii nie powinien opierać się wyłącznie na preferencjach technologicznych działu IT, lecz na dokładnej analizie przypadków użycia (use cases) generujących ruch w sieci.

Przykładowo, w zautomatyzowanym zakładzie chemicznym lub hucie, gdzie sieć P5G obsługuje systemy wczesnego ostrzegania, łączność krytyczną Push-to-Talk (MC-PTT) oraz telemetryczne zawory odcinające, jedynym dopuszczalnym wyborem jest pełny on-premise. Ryzyko zatrzymania linii produkcyjnej z powodu prac konserwacyjnych u dostawcy chmury lub zerwania łącza światłowodowego wyklucza architekturę zależną od WAN.

Z kolei w nowoczesnym centrum dystrybucyjnym e-commerce, gdzie sieć 5G służy głównie do łączenia setek ręcznych skanerów kodów kreskowych, tabletów pracowników i kamer monitoringu stanu paczek, model hybrydowy lub w pełni chmurowy sprawdzi się znakomicie. Zapewnia on niski koszt wdrożenia, centralne zarządzanie uprawnieniami pracowników z poziomu chmurowego katalogu tożsamości oraz prostą skalowalność w sezonach szczytowych (np. Black Friday).

Ścieżka decyzyjna przed podpisaniem umowy wdrożeniowej

Aby uniknąć kosztownych zmian architektonicznych na etapie produkcyjnym, proces decyzyjny warto oprzeć na weryfikacji trzech podstawowych parametrów operacyjnych:

W pierwszej kolejności zdefiniuj krytyczność czasową: jeśli jakikolwiek proces wymaga opóźnień poniżej 15 ms przy stałym jitterze, funkcja UPF bezwzględnie musi znaleźć się on-premise. Następnie zweryfikuj politykę zgodności (Compliance) i RODO: jeśli regulacje branżowe zabraniają przesyłania metadanych produkcyjnych poza granice kraju lub obiektu, konieczny będzie pełny lokalny rdzeń. Na koniec skalkuluj realny koszt łącza zapasowego i transferu danych – w scenariuszach wideo wysoki wolumen wysyłania (uplink) do chmury często niweluje wszelkie oszczędności z modelu SaaS.

Ostateczny wybór topologii Private 5G to zawsze sztuka kompromisu pomiędzy absolutną suwerennością operacyjną a elastycznością chmurowego ekosystemu. Przeprowadzenie wstępnego audytu procesów OT oraz testów Proof of Concept (PoC) z wykorzystaniem lokalnego breakoutu danych pozwala precyzyjnie dobrać architekturę, która zabezpieczy rozwój przedsiębiorstwa na kolejne dekady.

Integracja z istniejącą infrastrukturą IT/OT – na co zwrócić uwagę?

Wybór lokalizacji rdzenia sieci to dopiero połowa sukcesu architektonicznego. Równie istotnym aspektem jest sposób wpięcia Private 5G w istniejącą sieć zakładową (LAN, WLAN oraz przemysłowe sieci fieldbus). Niezależnie od wybranego wariantu – on-premise, hybrydowego czy chmurowego – punkt styku UPF z infrastrukturą fabryczną definiuje bezpieczeństwo i stabilność całego środowiska.

W praktyce przemysłowej ruch z sieci 5G najczęściej przekazywany jest do zapory sieciowej nowej generacji (NGFW) poprzez dedykowane łącza światłowodowe 10/25 GbE z wykorzystaniem routingu BGP lub statycznych tras dla poszczególnych podsieci urządzeń końcowych (UE). Przy planowaniu integracji warto uwzględnić cztery krytyczne elementy techniczne:

• Rozmiar ramki i fragmentacja (MTU): Narzut nagłówków tunelowania GTP-U (GPRS Tunnelling Protocol User Plane) pomiędzy stacją bazową gNodeB a UPF zmniejsza efektywne MTU pakietów. Niezbędne jest włączenie obsługi Jumbo Frames (min. 1600–9000 bajtów) na przełącznikach warstwy transportowej lub skonfigurowanie mechanizmu MSS Clamping na brzegu sieci.
• Synchronizacja czasu (PTP/IEEE 1588v2): Współczesne sieci 5G NR działające w trybie TDD (Time Division Duplex) bezwzględnie wymagają precyzyjnej synchronizacji fazy i czasu rzędu sub-mikrosekund. Zapewnienie lokalnego serwera Grandmaster Clock z anteną GNSS jest koniecznością w modelu on-premise, by uniknąć interferencji radiowych pomiędzy komórkami.
• Segmentacja ruchu (VLAN / VRF): Maszyny autonomiczne AGV/AMR, telemetria czujników SCADA oraz terminale użytkowników biurowych powinny trafiać do odrębnych instancji trasowania VRF (Virtual Routing and Forwarding) bezpośrednio na wyjściu z modułu UPF (Data Network Name – DNN mapping).
• Translacja adresów (NAT vs Routed Mode): W środowiskach przemysłowych preferuje się model w pełni routowalny bez podwójnego NAT-owania. Pozwala to na bezpośrednią widoczność adresów IP urządzeń końcowych w systemach diagnostycznych i firewallach przemysłowych OT.

Praktyczny plan testów Proof of Concept (PoC)

Zanim zapadnie wiążąca decyzja o zakupie pełnej licencji on-premise lub wieloletniego abonamentu chmurowego, zaleca się przeprowadzenie pilotażu obejmującego co najmniej jedną stację bazową (gNB) i wybraną grupę maszyn produkcyjnych.

W trakcie testów laboratoryjnych i polowych kluczowe jest przeprowadzenie kontrolowanej symulacji scenariuszy awaryjnych. W modelu hybrydowym oraz chmurowym należy fizycznie odłączyć łącze WAN i zmierzyć zachowanie maszyn: jak szybko reagują systemy bezpieczeństwa wózków AGV na brak odpowiedzi z Control Plane oraz czy po przywróceniu łączności internetowej następuje bezproblemowy powrót telemetryczny bez konieczności manualnego restartowania modułów radiowych.

Równie ważnym testem jest weryfikacja parametrów jittera przy nasyceniu pasma transmisyjnego. Równoległe uruchomienie transmisji z kilku kamer przemysłowych 4K oraz krytycznego protokołu sterowania maszyną (np. PROFINET przez sieć bezprzewodową) pozwala jednoznacznie ocenić, czy polityki jakości usług (5G QoS Identifiers – 5QI) są prawidłowo egzekwowane przez wybrany rdzeń w warunkach skrajnego obciążenia.

Świadome przejście przez etap audytu transmisyjnego i testów brzegowych eliminuje ryzyko nietrafionej inwestycji, gwarantując, że wdrożona sieć Private 5G stanie się stabilnym kręgosłupem cyfryzacji zakładu na wiele lat.