Architektura sieci 5G dla geeków: RAN, core, virtualizacja funkcji i orkiestracja NFV

Jak myśleć o architekturze 5G: mapa terenu dla geeka

Od smartfona do chmury: mentalny diagram 5G

Najprościej patrzeć na architekturę sieci 5G jak na łańcuch kilku warstw, które wspólnie dowożą pakiety od urządzenia do usługi w internecie lub w sieci operatora. W codziennej rozmowie z inżynierem dobrze mieć w głowie taki uproszczony model:

• Urządzenie użytkownika (UE) – telefon, modem, router CPE 5G, moduł IoT. Mówi językiem 5G NR w stronę sieci radiowej i IP w stronę aplikacji.
• RAN 5G (5G RAN, gNodeB) – stacje bazowe i ich logiczne klocki: RU, DU, CU. To tutaj dzieje się radiowy „magiczny” fragment transmisji.
• 5G Core (5GC) – serce sieci. Zbiór funkcji sieciowych (NF) realizowanych jako oprogramowanie (VNF lub CNF), odpowiedzialnych za sygnalizację, sesje danych, polityki i billing.
• Sieć szkieletowa / transport – MPLS, IP, optyka. Klej łączący RAN z core, core z edge, a potem z data center i internetem.
• Usługa końcowa – serwery aplikacyjne, chmura publiczna, edge computing, sieci prywatne, systemy przemysłowe.

Każdy z tych poziomów ma swoje protokoły, swoje ograniczenia i swoje typowe punkty awarii. Patrząc na diagram architektury sieci 5G, dobrze od razu oznaczyć w głowie: tu kończy się RAN, tu zaczyna core, a tu zaczyna się świat IT i chmury.

Od „pudełka” do funkcji: kluczowy zwrot w stronę NFV i cloud-native

W 4G oraz starszych generacjach operator kupował sprzęt w stylu „pudełka”: EPC w jednej szafie, HSS w drugiej, firewall w trzeciej. W 5G architektura sieci 5G jest projektowana od początku z myślą o wirtualizacji funkcji sieciowych (NFV) i podejściu cloud-native. Zamiast jednego monolitycznego pudełka mamy:

• Funkcje sieciowe (Network Functions, NF) – AMF, SMF, UPF, UDM, AUSF, PCF, NRF itd.
• Każda NF może być dostarczona jako VNF (na maszynach wirtualnych) albo jako CNF (w kontenerach, np. na Kubernetesie).
• Skalowanie odbywa się poziomo – dokładamy instancje NF, zamiast wymieniać całe urządzenie na „większe”.

Ten zwrot powoduje, że sieć 5G wygląda architektonicznie bliżej dużego systemu mikrousług w chmurze niż tradycyjnej telekomowej infrastruktury. To rodzi nowe wymagania: CI/CD, monitoring, logowanie rozproszone, orkiestracja NFV i MANO, a także integrację z istniejącymi platformami IT.

Dlaczego 5G to nie tylko szybsze LTE

Slogan „5G to szybsze LTE” sprawdza się marketingowo, ale technicznie omija sedno sprawy. Różnica nie dotyczy wyłącznie radia (większe pasmo, MIMO, modulacja), lecz przede wszystkim modelu architektury:

• 5G core jest projektowany w pełni jako architektura oparta na usługach (SBA) z interfejsami HTTP/2, REST-like, JSON.
• Network slicing pozwala wydzielać logiczne sieci end-to-end, z własnymi parametrami QoS, bezpieczeństwa i routingu.
• Edge computing staje się integralną częścią architektury – UPF blisko stacji bazowej, aplikacje na krawędzi.
• Trzy scenariusze usług: eMBB (wysoka przepływność), URLLC (bardzo małe opóźnienia i wysoka niezawodność), mMTC (masowe IoT)

Każdy z tych scenariuszy wymusza inne decyzje projektowe: od gęstości stacji bazowych, przez strukturę RAN, po sposób zestawiania PDU Session i projekt topologii UPF.

Jak czytać diagram architektury sieci 5G: pytania kontrolne

Patrząc na diagram architektury 5G, warto zadawać sobie kilka konkretnych pytań technicznych:

• Gdzie kończy się RAN, a zaczyna core? – zazwyczaj na interfejsie NG (NG-C i NG-U).
• Gdzie są punkty skalowania? – które NF są skalowalne poziomo, a które pionowo? Co jest „gorącym” bottleneckiem?
• Jak rozwiązano redundancję? – czy widać aktywne/aktywne instancje AMF/SMF/UPF, czy aktywne/pasywne, jak wygląda failover?
• Jak wygląda edge? – czy UPF-y są tylko centralne, czy również dystrybuowane przy RAN?
• Jak jest zrobiony network slicing? – czy widać logiczne przekroje przez RAN, core i transport?

Takie pytania szybko odsiewają slajdy czysto marketingowe od projektów, w których faktycznie przemyślano architekturę sieci 5G end-to-end.

Od 4G do 5G: co faktycznie się zmieniło pod maską

EPC vs 5G Core – porównanie filozofii

Szereg elementów 4G i 5G na pierwszy rzut oka jest podobnych (MME, SGW, PGW vs AMF, SMF, UPF), ale sposób myślenia o całości jest inny. EPC można traktować jako duży monolit z kilkoma jasno zdefiniowanymi boxami. 5G core to kolekcja funkcji sieciowych komunikujących się po modelu usługowym.

W EPC większość relacji jest statyczna i twardo skonfigurowana – w 5GC dużo silniej akcentowana jest dynamiczność: NF rejestruje się w NRF, inne NF go odnajdują, a topologia logiczna może zmieniać się w czasie.

Non-Standalone kontra Standalone: dwa światy 5G

W praktyce obecnie funkcjonują dwa główne tryby wdrożeń 5G:

• 5G NSA (Non-Standalone) – radio 5G NR współpracuje z EPC 4G. Kontrola sygnałowa idzie po 4G, dane mogą płynąć po 5G.
• 5G SA (Standalone) – pełen 5G core standalone, RAN 5G połączony bezpośrednio z 5GC. Wszystkie możliwości 5G (URLLC, slicing, SBA) stają się realnie dostępne.

NSA był dla operatorów wygodnym etapem przejściowym: można uruchomić nowe pasma i marketing „5G ready”, a jednocześnie nie inwestować od razu w kompletny 5G core. Z punktu widzenia architektury sieci 5G jest to jednak hybryda: RAN 5G, ale logika sesji i mobilności ciągle w EPC.

SA to docelowy model, w którym całe zarządzanie ruchem, tożsamością, politykami i slice’ami odbywa się wewnątrz 5G core standalone. Dla geeka oznacza to, że dopiero przy SA w pełni interesują nas funkcje takie jak AMF, SMF, UPF, PCF, UDM, AUSF, NSSF czy NRF.

Separacja płaszczyzny sterowania i użytkownika w praktyce

Rozdzielenie płaszczyzny sterowania (C-plane) i płaszczyzny użytkownika (U-plane) pojawiło się już w 4G, ale w 5G jest domknięte dość konsekwentnie. Przekłada się to na bardzo konkretny układ:

• C-plane: AMF, SMF, PCF, UDM, AUSF, NSSF, NRF i inne NF sterujące.
• U-plane: UPF – jedyna funkcja 5GC obsługująca realny payload użytkownika (pakiety IP, Ethernet).

Daje to spore korzyści architektoniczne: UPF można skalować, lokalizować i optymalizować niezależnie od logiki sterowania. Przykładowo, dla usług edge computingowych instaluje się lokalny UPF przy stacji bazowej, który kończy tunel GTP i kieruje ruch do aplikacji na krawędzi, podczas gdy AMF/SMF mogą pozostać w centralnym data center.

Nowe typy usług: eMBB, URLLC, mMTC i ich wpływ na projekt

Trzy „flagowe” scenariusze usług 5G narzucają odmienne wymagania na architekturę sieci 5G:

• eMBB (enhanced Mobile Broadband) – wysoka przepływność, duże pasma, massive MIMO. Wymaga szerokich kanałów radiowych, gęstego RAN-u i wydajnego transportu.
• URLLC (Ultra-Reliable Low-Latency Communication) – opóźnienia rzędu pojedynczych milisekund, bardzo wysoka niezawodność. Wymusza wykorzystanie edge computing, lokalnych UPF-ów, uproszczonej ścieżki protokołów i ostrożnego projektowania QoS.
• mMTC (massive Machine Type Communication) – setki tysięcy urządzeń na komórkę, małe pakiety, niska przepływność na urządzenie. Wpływa na sposób zarządzania sygnalizacją, oszczędzanie energii (Power Saving Mode, eDRX) i skalę baz danych subskrypcji.

Jeśli gdzieś na diagramie 5G brak lokalnych UPF-ów i edge’a, a jednocześnie ktoś obiecuje pełne URLLC, można z dużym prawdopodobieństwem założyć, że to się nie zepnie w realnych warunkach.

RAN 5G dla dociekliwych: od anteny po interfejs NG

gNodeB i jego logiczne moduły: RU, DU, CU

W LTE stacja bazowa (eNodeB) była zazwyczaj jednym logicznym bytem. W 5G RAN dominującym modelem staje się podział gNodeB na trzy elementy:

• RU (Radio Unit) – „głowica radiowa” przy antenie. Zajmuje się analogową i niskopoziomową częścią warstwy fizycznej: przetwarzanie RF, konwersja sygnałów, niekiedy część FFT/OFDM.
• DU (Distributed Unit) – najczęściej umieszczone bliżej RU, w szafie na stacji. Odpowiada za warstwę MAC, RLC i część warstwy PHY, harmonogramowanie, retransmisje.
• CU (Central Unit) – logicznie wyżej, często scentralizowane i uruchamiane jako oprogramowanie na serwerach. Obsługuje PDCP, RRC, SDAP – bliżej logiki sesji.

Taki podział umożliwia centralizację części funkcji (CU), a tym samym lepszą koordynację między komórkami, łatwiejsze aktualizacje softu i wykorzystanie NFV w warstwie RAN. Sam RU bywa mocno sprzętowy, natomiast DU i CU są często już wirtualizowane.

Warstwy protokołów RAN: co gdzie zwykle ląduje

Aby sensownie rozmawiać o podziale funkcji, dobrze mieć w głowie, które warstwy OSI/protokółowe są realizowane w którym klocku:

• RU – dolna część warstwy PHY: modulacja, demodulacja, cyfrowo-analogowa obróbka sygnałów RF.
• DU – górna część PHY, MAC (harmonogramowanie, alokacja zasobów), RLC (segmentacja, retransmisje), część Packet Data Convergence Protocol (PDCP) w niektórych implementacjach.
• CU – reszta PDCP (szyfrowanie, kompresja nagłówków), RRC (Radio Resource Control), SDAP (Service Data Adaptation Protocol) mapujący QoS flow na DRB.

To nie jest sztywna reguła – konkretne podziały mogą się różnić między vendorami – ale w rozmowie technicznej taki model w zupełności wystarcza, żeby rozumieć, dlaczego np. DU wymaga niskich opóźnień w fronthaulu, a CU może siedzieć w bardziej oddalonym data center.

Interfejsy F1, E1, NG: klej między klockami RAN i core

RAN 5G wprowadza kilka nowych interfejsów logicznych, które pojawiają się na każdym sensownym diagramie:

Fronthaul, midhaul, backhaul – gdzie faktycznie boli opóźnienie

W LTE mówiło się głównie o fronthaulu i backhaulu. W 5G, przy podziale na RU/DU/CU, sensowniej jest myśleć o trzech odcinkach transportu:

• Fronthaul – między RU a DU. Tu opóźnienia i jitter są najbardziej krytyczne, bo przenosimy sygnał bardzo blisko warstwy fizycznej. Często wymusza to światłowód i bardzo precyzyjną synchronizację czasową.
• Midhaul – między DU a CU. Wymagania są bardziej „ludzkie”, ale nadal restrykcyjne – zbyt duże opóźnienia rozwalą harmonogramowanie i procedury RRC.
• Backhaul – między CU a 5G Core (NG-C/NG-U), dalej w stronę data center. Tu można już stosować klasyczne rozwiązania IP/MPLS, choć przy dużej skali QoS i inżynieria ruchu przestają być nudne.

Jeśli ktoś próbuje centralizować DU w dalekim data center, fronthaul szybko staje się miejscem bólu. Z kolei przeniesienie tylko CU do chmury daje sporo korzyści z centralizacji, a jednocześnie nie dobija łącza RU–DU.

Synchronizacja i czas w RAN 5G

5G jest dużo wrażliwsze na synchronizację niż starsze generacje. Dla masive MIMO i TDD trzeba mieć bardzo precyzyjnie „ustawiony zegarek” między różnymi RU. Realizuje się to przez:

• GPS/GNSS – klasyczny „zewnętrzny zegar”, ale podatny na zakłócenia i nie wszędzie dostępny (budynki, tunele).
• PTP (Precision Time Protocol, IEEE 1588) – dystrybucja czasu po sieci transportowej. Wymaga odpowiednio przygotowanej infrastruktury (boundary clocks, transparent clocks).
• Synchronous Ethernet (SyncE) – synchronizacja częstotliwościowa na warstwie 2, często razem z PTP.

Bez dobrej synchronizacji rośnie liczba błędów radiowych, spada efektywność widma, a w skrajnych przypadkach komórki zaczynają „wchodzić sobie w słowo”. Z punktu widzenia geeka sieć transportowa nagle staje się tak samo krytyczna jak samo radio.

Interfejs NG i rola NGAP

Łącze między RAN 5G a 5G Core to interfejs NG, który dzieli się na:

• NG-C – płaszczyzna kontrolna, oparta na protokole NGAP (NG Application Protocol), łącząca gNodeB z AMF.
• NG-U – płaszczyzna użytkownika, oparta na GTP-U, łącząca gNodeB z UPF.

NGAP pełni podobną rolę jak S1-AP w LTE, ale jest przystosowany do nowych koncepcji 5G, takich jak PDU Sessions, QoS flows czy obsługa wielu slice’ów. W logach NGAP widać sporo ciekawych rzeczy: procedury rejestracji, handover między gNodeB, alokację zasobów dla różnych PDU Session.

Open RAN i otwarte interfejsy w praktyce

Open RAN (często w wariancie O-RAN) próbuje rozbić tradycyjny, vendor-lockowy RAN na komponenty różnych dostawców, sklejone standardowymi interfejsami. Pojawiają się tu nowe, sprecyzowane interfejsy:

• Open fronthaul między RU i DU, opisany przez O-RAN Alliance.
• E2 – interfejs pozwalający na sterowanie elementami RAN przez tzw. RIC (RAN Intelligent Controller).

Do tego dochodzi warstwa „inteligencji” – Near-RT RIC (near real-time) i Non-RT RIC, gdzie można wrzucać algorytmy optymalizacji, xApps/rApps, machine learning do sterowania zasobami radiowymi. Dla inżyniera oznacza to, że RAN przestaje być czarną skrzynką, a zaczyna przypominać platformę do eksperymentów.

5G Core krok po kroku: funkcje sieciowe zamiast monolitu

AMF – brama do świata 5GC

AMF (Access and Mobility Management Function) to pierwszy „punkt kontaktu” urządzenia z 5G Core. Realizuje m.in.:

• obsługę rejestracji UE (Registration Management),
• zarządzanie mobilnością (handover, przenoszenie kontekstu UE),
• terminację sygnalizacji NAS,
• autoryzację dostępu przy współpracy z AUSF/UDM.

Można o nim myśleć jak o połączeniu części starego MME z „front-endem” do świata usług SBA. AMF nie dotyka danych użytkownika – jest czystą funkcją sterującą, która deleguje decyzje dotyczące sesji do SMF.

SMF i UPF – duet od sesji i danych

SMF (Session Management Function) odpowiada za logikę PDU Session, czyli „tuneli” danych dla konkretnego UE. To SMF decyduje, jak i gdzie zostanie utworzony UPF, jaka będzie polityka routingu, jak zrealizować QoS czy split ruchu (np. lokalny breakout do edge’a).

UPF (User Plane Function) to z kolei miejsce, gdzie faktycznie płyną pakiety użytkownika. Realizuje m.in.:

• terminację GTP-U od strony RAN,
• oznaczanie QoS (np. DSCP),
• opcjonalne funkcje jak buffering, raportowanie statystyk, ewentualne funkcje SGi-LAN (firewall, NAT) jeśli tak to zaprojektowano.

SMF i UPF są zwykle rozdzielone fizycznie i logicznie, co pozwala mieć wiele instancji UPF close to edge, podczas gdy SMF pozostaje scentralizowany. Dobrą praktyką jest projektowanie UPF-ów w kilku poziomach: centralne (internet/peering), regionalne (duże miasta) i skrajne (MEC przy RAN).

UDM, AUSF i UDR – tożsamość i subskrypcja

W 5G funkcje HSS zostały rozbite głównie na:

• UDM (Unified Data Management) – logika zarządzania danymi abonenta, generowanie kluczy bezpieczeństwa, dane subskrypcji.
• AUSF (Authentication Server Function) – funkcja uwierzytelniania, współpracująca z UDM przy procedurach AKA.
• UDR (Unified Data Repository) – „pasywny” magazyn danych, z którego korzystają różne NF, nie tylko UDM.

Ten podział pozwala z jednej strony skalować logikę (UDM, AUSF), z drugiej trzymać wspólne dane w jednym, dobrze zabezpieczonym repozytorium (UDR). W dużych sieciach rozbijanie UDR na klastry regionalne może być kluczem do sensownego czasu dostępu i replikacji.

PCF – polityki zastępują PCRF

PCF (Policy Control Function) to następca PCRF z EPC, ale w świecie SBA. Współpracuje z SMF, AMF i innymi NF, aby wdrażać polityki dotyczące:

• QoS (przepływy QoS, priorytety),
• limitu przepływności, kształtowania ruchu,
• reguł chargingowych (we współpracy z systemami billingowymi),
• specyficznych polityk dla pojedynczych slice’ów czy aplikacji.

W praktyce PCF przestaje być wyłącznie komponentem billingowym, a staje się centralnym miejscem „polityki sieci”. API PCF jest zresztą jednym z ciekawszych punktów integracji dla usług zewnętrznych, które chcą prosić sieć o konkretne zachowanie (np. „dać temu strumieniowi wideo wyższy priorytet na czas transmisji”).

NRF, NSSF, NEF – klej świata SBA

Wśród nowych funkcji 5GC kilka robi za swoisty „klej” architektury:

• NRF (Network Repository Function) – rejestr NF-ów. Każda funkcja sieciowa rejestruje się tam ze swoimi możliwościami i endpointami, a inne NF pytają NRF „kto w sieci pełni rolę SMF dla tego slice’a?” itd.
• NSSF (Network Slice Selection Function) – bierze udział w procesie przypisywania UE do odpowiedniego slice’a (NSSAI). Współpracuje z AMF i innymi NF, aby zdecydować, jaką kombinację slice’ów przypisać dla danego urządzenia i usług.
• NEF (Network Exposure Function) – wystawia funkcje sieciowe i zdarzenia na zewnątrz, np. dla aplikacji w chmurze. To coś w rodzaju bezpiecznego „adaptera” między światem 5G a developerami aplikacji.

Bez NRF trudno mówić o dynamicznej, usługowej architekturze. Bez NSSF – o sensownym network slicingu. Bez NEF – o poważnej integracji 5G z aplikacjami verticali (przemysł, automotive, e-zdrowie).

Architektura oparta na usługach (SBA): co oznacza dla inżyniera

HTTP/2, JSON i REST w rdzeniu sieci komórkowej

5G Core wprowadza komunikację między NF opartą na usługach (Service-Based Architecture). Zamiast klasycznego, zdefiniowanego na sztywno interfejsu (jak S6a czy S11), funkcje rozmawiają ze sobą używając:

• HTTP/2 jako warstwy transportowej,
• JSON jako formatu danych,
• stylu REST-like z odpowiednimi metodami i URI.

Dla zespołów, które do tej pory siedziały bardziej w świecie IT niż telco, nagle część rdzenia sieci wygląda jak typowy microservices backend. Można użyć znanych narzędzi do debugowania (curl, Postman), proxy (Envoy, NGINX) czy obserwowalności (Prometheus, Jaeger).

Service-Based Interfaces (SBI) i rejestracja w NRF

Komunikacja usługowa odbywa się przez tzw. SBI – Service-Based Interfaces. Każda funkcja sieciowa udostępnia zestaw usług (API), na przykład:

• UDM: usługi dotyczące danych abonenta,
• PCF: usługi związane z politykami,
• SMF: usługi zarządzania sesjami.

NF-y rejestrują się w NRF, zamieszczając tam informacje o tym, jakie usługi oferują, w jakich slice’ach uczestniczą, jakie mają parametry (np. lokalizacja, obciążenie). Inne funkcje mogą dynamicznie odkryć partnerów komunikacji, zamiast mieć w konfiguracji twarde adresy IP.

Load balancing, retries i resiliency w SBA

Przejście na SBA otwiera tematykę typową dla systemów rozproszonych. Pojawiają się pytania:

• jak robić load balancing między instancjami NF (np. kilka SMF)?
• jak radzić sobie z transient errors, timeoutami, powtórzeniami żądań?
• jak zapewnić observability – metryki, logi, trace’y end-to-end?

Wiele wdrożeń 5GC używa rozwiązań znanych z mikroserwisów: sidecar service mesh, centralny tracing, circuit breakers, backoff w retry. Dla kogoś, kto do tej pory stroił głównie STP i SIGTRAN, to inny świat – ale dla kogoś z doświadczeniem w Kubernetesie i mikroserwisach łączy się to bardzo naturalnie.

Bezpieczeństwo na poziomie API

Skoro NF to w praktyce usługi HTTP, pojawia się temat bezpieczeństwa API. 3GPP definiuje mechanizmy autoryzacji oparte na OAuth2 i JSON Web Tokens (JWT). Każdy NF posiada swój „profil” i może występować w rolach klienta i serwera względem innych funkcji.

Do tego dochodzą klasyczne elementy: TLS, zarządzanie certyfikatami, segmentacja sieci (np. Kubernetes Network Policies, VLAN-y / VRF-y), a także kontrola dostępu na poziomie samego API (kto może wywołać daną operację w UDM czy PCF). Z punktu widzenia security teamu 5G Core zaczyna wyglądać jak duży, krytyczny system webowy, a nie „magiczna czarna skrzynka” od vendora.

NFV: od „pudełek” do funkcji – wirtualizacja sieci w praktyce

NFV Infrastructure (NFVI) – z czego składa się „grunt” pod 5GC

NFV formalnie rozbija się na trzy główne kategorie: NFVI (infrastruktura), VNF/CNF (funkcje) i MANO (zarządzanie i orkiestracja). Na poziomie NFVI mówimy w praktyce o:

• klastrach serwerów x86 (czasem ARM) z akceleratorami (SmartNIC, FPGA, GPU),
• wirtualizacji (KVM, ESXi) lub konteneryzacji (Kubernetes),
• wirtualnej sieci (OVS, SR-IOV, DPDK, eBPF) i systemach storage.

Dobór hardware’u nie jest trywialny. Funkcje C-plane zwykle działają dobrze na klasycznych VM/kontenerach, ale U-plane (UPF, vRAN) lubi przyspieszenia typu DPDK, SR-IOV czy nawet specjalizowane karty sieciowe z offloadem GTP.

VNF vs CNF – jak zmienia się sposób dostarczania funkcji

Na początku NFV większość rozwiązań przychodziła jako VNF – wirtualne appliance’y, często z własnym, zamkniętym OS-em, zarządzane bardziej jak „pudełka w chmurze”. W 5G rośnie nacisk na CNF (Cloud-Native Network Functions), czyli funkcje sieciowe zaprojektowane od zera jako zestaw kontenerów, skalowalnych mikroserwisów.

Różnica jest istotna:

Praktyczne różnice w podejściu do VNF i CNF

W VNF-ach vendor często dostarcza „gotową skrzynkę w VM-ce”: jeden duży obraz, własny sposób logowania, specyficzny mechanizm upgrade’u. Skalowanie bywa toporne – dorzucasz kolejną wirtualkę, a reszta to ręczna orkiestracja lub wewnętrzny clustering.

CNF-y podchodzą do tematu inaczej. Funkcja sieciowa jest podzielona na mniejsze komponenty (np. osobne pody dla sygnalizacji, osobne dla metryk, osobne dla interfejsów SBI), które:

• skalują się niezależnie (więcej instancji microserwisu sygnalizacyjnego bez ruszania całej reszty),
• korzystają z natywnych mechanizmów chmury (Kubernetes, service mesh),
• są aktualizowane „po kawałku” – rolling update jednego komponentu zamiast restartu całego monolitu.

W świecie VNF zarządzanie zasobami to głównie sizing VM-ki (vCPU, RAM, vNIC). W CNF dochodzą limity i requesty w Kubernetesie, affine’y, pod anti-affinity, pinning do NUMA, a do tego interplay z CNI i pluginami sieciowymi zoptymalizowanymi pod low latency.

Wydajność i data plane: jak nie zabić UPF-a abstrakcją

Najdelikatniejszym tematem przy NFV jest warstwa użytkownika. UPF, vRAN czy bramy peeringowe łatwo „zadusić” nadmiarem abstrakcji, jeśli wszystko będzie przechodzić przez klasyczną wirtualną kartę i kernelową ścieżkę sieciową.

Aby tego uniknąć, w praktyce stosuje się połączenie kilku technik:

• SR-IOV – bezpośrednie przydzielanie wirtualnych funkcji karty sieciowej do VM/poda, z pominięciem wirtualnego switcha,
• DPDK – user-space’owa obsługa pakietów, minimalizująca koszty przełączania kontekstu i kopii danych,
• XDP/eBPF – programowalne filtry i akcje w bardzo wczesnym etapie przetwarzania pakietu w kernelu.

Typowy kompromis wygląda tak: C-plane (AMF, SMF, PCF, UDM itd.) dostają „normalne” wirtualne interfejsy i klasyczny stack TCP/IP, natomiast UPF i ewentualnie elementy vRAN działają w trybie „specjalnym” z SR-IOV i DPDK. To rozdziela dwie klasy wymagań: elastyczność kontra raw performance.

Przy pierwszych testach loadowych wielu operatorów boleśnie odkrywa, że to nie CPU jest problemem, tylko źle dobrany model I/O: mały MTU, zbyt dużo kopii pakietów, brak pinningu przerwań do konkretnych rdzeni. To hala serwerowni, ale diagnostyka brzmi momentami jak z czasów optymalizacji ISR-ów w urządzeniach embedded.

Automatyzacja lifecycle: od day-0 do day-2

Virtualizacja bez automatyzacji szybko kończy się zoo obrazów i konfiguracji. Przy NFV w 5G naturalnie pojawia się rozróżnienie na różne „dni życia” funkcji:

• Day-0 – projekt: modele usług, szablony VNF/CNF, katalog NF-ów,
• Day-1 – pierwsze wdrożenie: instancjonowanie, podstawowa konfiguracja, integracja z OSS/BSS,
• Day-2 – operacje: scaling, upgrade’y, patchowanie, migracje między klastrami.

Na poziomie praktycznym oznacza to playbooki Ansible’a, Helm charty dla CNF-ów, deklaratywne CRD w Kubernetesie czy gotowe workflowy w systemach orkiestracji. Manualne „klikanie” nowej instancji SMF w konsoli hypervisora po prostu nie skaluje się przy kilkudziesięciu lub kilkuset site’ach MEC.

Orkiestracja NFV i MANO: kto nad tym wszystkim panuje

Trzy warstwy MANO: NFVO, VNFM i VIM

ETSI NFV zdefiniowało klasyczną trójkę, która porządkuje chaos:

• VIM (Virtualized Infrastructure Manager) – odpowiada za zarządzanie infrastrukturą: compute, sieć, storage. W praktyce to OpenStack, VMware vCloud/NSX, a w nowych wdrożeniach coraz częściej Kubernetes (czasem jako „CaaS” opakowany przez dostawcę).
• VNFM (VNF Manager) – zarządza lifecycle poszczególnych funkcji: instancjonowanie, skalowanie, upgrade. Dla CNF-ów coraz częściej rolę VNFM pełnią natywne narzędzia K8s plus specjalizowany kontroler vendora.
• NFVO (NFV Orchestrator) – najwyższy poziom: „układa” VNF/CNF-y w kompletne usługi (Network Services), decyduje, gdzie i jak mają zostać wdrożone, pilnuje zależności między nimi.

Taki podział pozwala oddzielić pytanie „gdzie to postawić?” (VIM) od „jak zarządzać konkretną funkcją?” (VNFM) i „jak z tych klocków zbudować całą usługę sieciową?” (NFVO). Gdy wchodzi 5G Core z kilkunastoma NF w różnych slice’ach, ta warstwa pośrednia staje się niezbędna, żeby nie skończyć z zestawem silosów.

Modele opisowe: TOSCA, YANG i szablony usług

Żeby orkiestrator mógł czymkolwiek zarządzać, musi dostać opis: co to za funkcja, jakie ma wymagania, jakie interfejsy. Tu wchodzą modele opisowe:

• TOSCA – do opisu złożonych usług sieciowych (Network Service Descriptor – NSD, VNF Descriptor – VNFD),
• YANG – do modelowania konfiguracji i interfejsów zarządzania (Netconf/Restconf),
• czasem własne DSL-e vendora (szablony w YAML/JSON) jako warstwa pośrednia.

Przykładowo NSD opisuje, że kompletna usługa „5G Core dla regionu X” to zestaw: 1× AMF, 2× SMF, kilka UPF, UDM/UDR/AUSF, PCF, NRF, NSSF – wszystkie połączone określonymi wirtualnymi sieciami (np. management, control, user-plane). Orkiestrator na tej podstawie wie, co wdrożyć, w jakiej kolejności i w którym regionie NFVI.

Gdy dana funkcja to CNF, szablon najczęściej wskazuje już gotowy Helm chart lub operatora Kubernetes wraz z wartościami parametrów (ilość replik, limity zasobów, profile NUMA). To łączy klasyczny świat NFV z cloud-native w całkiem elegancki sposób.

Closed-loop automation: gdy sieć sama się poprawia

Przy dużych wdrożeniach ręczna reakcja na zdarzenia przestaje mieć sens. Pojawia się koncepcja closed-loop automation: system monitoringu wykrywa anomalię, polisy decydują, co z tym zrobić, a orkiestrator wykonuje odpowiednią akcję bez udziału człowieka.

Typowe pętle zamknięte to:

• autoskalowanie UPF-ów w regionie, gdzie rośnie ruch (na podstawie metryk CPU, przepływności, latency),
• przełączenie ruchu między instancjami SMF po awarii, z automatycznym podniesieniem nowej instancji w innym data center,
• dynamiczne dostrajanie parametrów slice’a (np. maksymalna przepływność, priorytety QoS) pod wpływem zdarzeń z systemów OSS/BSS albo z NEF.

Technicznie sprowadza się to do połączenia kilku elementów: telemetrii (Prometheus, streaming telemetry z routerów), silnika reguł/polityk (np. komponent w OSS albo dedykowana platforma „analytics & policy”), orkiestratora NFV/K8s i odpowiedniego API w NF-ach (SBI). Z zewnątrz wygląda to jak sterowanie systemem rozproszonym, a nie „konfiguracja routerów”.

Integracja z OSS/BSS i światem „nad siecią”

Orkiestracja NFV nie żyje w próżni. Żeby ktokolwiek mógł sprzedawać usługi oparte na 5G, MANO musi dogadać się z klasycznymi systemami:

• OSS – inventory, planowanie pojemności, zarządzanie awariami,
• BSS – katalog produktów, zamówienia, billing.

Scenariusz zamówienia nowego slice’a dla fabryki zwykle wygląda tak: klient składa zamówienie w portalu, BSS przekłada to na techniczny request, który trafia do OSS/orkiestratora. Ten na bazie szablonów NSD/VNFD/CNF tworzy nowy slice (lub rozszerza istniejący), odpala odpowiednie NF-y i przypisuje im zasoby. Po kilku minutach klient może już zacząć rejestrować swoje urządzenia w dedykowanym slice’ie – bez dotykania CLI pojedynczego routera.

Network slicing: jeden fizyczny świat, wiele logicznych sieci

Podstawowe pojęcia: S-NSSAI, slice i subnet slice

Network slicing w 5G to nic innego jak logiczne sieci „wydzielone” na wspólnej infrastrukturze. Każdy slice identyfikowany jest poprzez S-NSSAI (Single Network Slice Selection Assistance Information), który składa się z:

• SST – typ slice’a (np. eMBB, URLLC, mMTC),
• SD – opcjonalny identyfikator różnicujący slice’y w ramach tego samego typu.

Dodatkowo 3GPP mówi o Network Slice Subnet Instance (NSSI) – części slice’a odpowiadającej np. tylko za RAN, tylko za Core, albo tylko za transport. W praktyce pozwala to dzielić odpowiedzialności: inny zespół zarządza NSSI RAN, inny – 5GC, jeszcze inny – transportem IP/MPLS.

Jak urządzenie trafia do konkretnego slice’a

Cały proces wyboru slice’a zaczyna się już przy rejestracji UE. Terminal może mieć skonfigurowaną listę preferowanych slice’ów (NSSAI), operator ma z kolei konfigurowaną NSSAI po stronie sieci, a pośrodku stoi NSSF, który dopasowuje jedno do drugiego.

W skrócie wygląda to tak:

1. UE wysyła żądanie rejestracji z listą NSSAI (lub pustą, jeśli „nie ma preferencji”).
2. AMF kontaktuje się z NSSF, który bierze pod uwagę subskrypcję abonenta (UDM), aktualną konfigurację slice’ów i dostępność zasobów.
3. NSSF zwraca zestaw „dozwolonych” S-NSSAI oraz wybór właściwego AMF (czasem dedykowanego dla danego slice’a lub grupy slice’ów).
4. Na tej bazie dochodzi do przypisania UE do jednego lub kilku slice’ów (terminal może równolegle korzystać z kilku, jeśli to przewidziano).

Dla inżyniera ciekawostką jest to, że między różnymi slice’ami mogą być zupełnie różne instancje NF – inny zestaw SMF/UPF, inny PCF, a nawet osobne instancje UDM/UDR dla izolacji danych. Logiczną przynależność widać w polach S-NSSAI, a techniczną – w mapowaniu na konkretne NF Instance ID w NRF.

Izolacja zasobów: QoS, compute i transport

Network slicing to nie tylko „kolorowanie” sygnalizacji. Żeby miało sens, musi nieść pewien poziom izolacji. Realizuje się to na kilku warstwach:

• RAN/QoS – dedykowane profile QoS (5QI), priorytety schedulera, osobne konfiguracje dla eMBB i URLLC. Czasem stosuje się nawet oddzielne nośne lub pasma.
• Core/compute – NF-y danego slice’a mogą mieć wydzielone pulle węzłów w Kubernetesie, oddzielne klastery NFVI albo twarde limity CPU/RAM gwarantujące minimalny performance.
• Transport – segmentacja sieci (VRF, segment routing, VLAN-y), osobne klasy QoS na MPLS/IP, a w skrajnych przypadkach dedykowane łącza dla krytycznych slice’ów.

W praktyce rzadko idzie się w pełną izolację na każdym poziomie – to by zaprzeczało sensowi współdzielenia infrastruktury. Częściej buduje się profilowane klasy slice’ów: „zwykły komercyjny eMBB”, „przemysłowy z gwarancją opóźnień”, „public safety z wyższym priorytetem preempcji”, i dla każdej z nich predefiniuje się polityki od RAN po 5GC.

Katalog slice’ów i ich orkiestracja

Skoro slice staje się produktem, musi mieć swój katalog. Orkiestrator MANO (czasem w połączeniu z OSS/BSS) przechowuje szablony:

• jakie NF-y wchodzą w skład danego typu slice’a (AMF, SMF, UPF, PCF, UDM, NEF itd.),
• jakie profile QoS i zasoby są przypisane (np. minimalny throughput na użytkownika, maksymalna liczba jednoczesnych UE),
• jakie zasady skalowania, backupu, geo-redundancji obowiązują.

Kiedy pojawia się potrzeba nowego slice’a (np. dla operatora wirtualnego, miasta, zakładu produkcyjnego), orkiestrator klonuje odpowiedni szablon, instancjonuje NF-y w zadanych regionach i publikuje nowe S-NSSAI do systemów konfigurujących RAN i 5GC. Z punktu widzenia klienta może to wyglądać jak „zamówienie sieci prywatnej z panelu samoobsługowego”.

Network slicing a sieci prywatne (Non-Public Networks)

NPN (Non-Public Networks) – prywatne sieci 5G – często mieszają się w dyskusji o slice’ach. W uproszczeniu mamy dwie drogi:

• Stand-alone NPN – cała infrastruktura 5G (RAN, 5GC) stoi u klienta, pełna separacja od sieci publicznej.

Najczęściej zadawane pytania (FAQ)

Na czym polega podstawowa architektura sieci 5G – z jakich głównych elementów się składa?

Sieć 5G można rozłożyć na kilka kluczowych klocków: urządzenie końcowe (UE), sieć dostępu radiowego RAN (stacje bazowe gNodeB), 5G Core (5GC), sieć transportową/szkieletową oraz usługi końcowe w chmurze lub data center. Od telefonu do serwera w chmurze pakiet przechodzi po kolei przez te warstwy.

RAN odpowiada za „magiczny” fragment w eterze – modulację, MIMO, przydział zasobów radiowych. 5G Core to już świat oprogramowania: funkcje sieciowe (NF) realizujące sygnalizację, sesje danych, polityki, bezpieczeństwo i billing. Między nimi działa sieć transportowa (MPLS, IP, optyka), która spina RAN z core i dalej z edge oraz internetem.

Jaka jest różnica między RAN 5G a 5G Core (5GC)?

RAN 5G (gNodeB) to część odpowiedzialna za radio – anteny, modulację, przydział czasu i częstotliwości, obsługę wielu użytkowników w komórce. Logicznie dzieli się na RU (Radio Unit), DU (Distributed Unit) i CU (Centralized Unit), które można rozlokować w różnych miejscach sieci, aby balansować między opóźnieniem a kosztami.

5G Core to serce całej logiki: tam działają funkcje takie jak AMF, SMF, UPF, UDM, PCF czy AUSF. Zajmują się rejestracją urządzeń, utrzymaniem sesji danych (PDU Session), routingiem, QoS, autoryzacją i integracją z systemami billingowymi. RAN „mówi” z urządzeniem w języku 5G NR, a core tłumaczy to wszystko na sesje IP/Ethernet i zasady ruchu w reszcie sieci.

Czym różni się 5G od 4G/LTE pod względem architektury sieci?

W 4G (EPC) dominował model „pudełkowy”: MME, SGW, PGW, HSS jako stosunkowo duże, statycznie powiązane elementy, często na dedykowanym sprzęcie. Interfejsy były specyficzne (S1, S5, S11) i raczej sztywno zdefiniowane. Całość przypominała kilka dużych serwerów spełniających konkretne role.

5G Core jest projektowany jako architektura oparta na usługach (SBA): wiele mniejszych funkcji sieciowych (NF) komunikuje się po API (HTTP/2, REST‑like, JSON). NF rejestrują się w NRF, inne NF je dynamicznie odkrywają. Dzięki temu topologia jest bardziej elastyczna, łatwiej wprowadzić automatyczne skalowanie, ciągłą integrację (CI/CD) i uruchamianie nowych usług bez przebudowy całej sieci.

Co to jest NFV, VNF, CNF i orkiestracja w sieciach 5G?

NFV (Network Functions Virtualization) to podejście, w którym funkcje sieciowe nie są już sprzętowymi „pudełkami”, tylko oprogramowaniem działającym na platformach wirtualnych lub kontenerowych. VNF (Virtual Network Function) to funkcja uruchomiona na maszynie wirtualnej, a CNF (Cloud‑Native Network Function) – to samo, ale zbudowane w stylu cloud‑native i działające w kontenerach, np. na Kubernetesie.

Orkiestracja NFV (często w ramach MANO – Management and Orchestration) steruje cyklem życia tych funkcji: ich uruchamianiem, skalowaniem, przenoszeniem między data center, aktualizacjami czy naprawą po awarii. Zamiast zamawiać nową szafę z hardware, operator może „dokręcić” kolejne instancje UPF lub AMF jednym poleceniem w systemie orkiestracji.

Na czym polega network slicing w 5G i jak wpływa na architekturę?

Network slicing to możliwość wydzielenia wielu logicznych sieci end‑to‑end na wspólnej fizycznej infrastrukturze. Każdy slice może mieć własne parametry QoS, bezpieczeństwa, routingu i zestaw funkcji w 5G Core. Przykładowo: jeden slice dla klientów masowych (eMBB), inny dla krytycznych aplikacji przemysłowych (URLLC), a jeszcze inny dla masowego IoT (mMTC).

W praktyce oznacza to, że RAN, core i sieć transportowa muszą wspólnie „rozumieć” identyfikatory slice’ów (np. NSSAI) i obsługiwać je spójnie. W 5G Core pojawia się m.in. funkcja NSSF, która pomaga przyporządkować urządzenie do odpowiedniego slice’a. Architekt musi więc patrzeć na projekt nie tylko jako jedną sieć, ale jako zestaw równoległych, logicznych sieci biegnących przez te same zasoby fizyczne.

Czym się różni 5G NSA (Non‑Standalone) od 5G SA (Standalone) od strony architektury?

W trybie 5G NSA radio 5G NR współpracuje z dotychczasowym EPC 4G. Kontrola sygnalizacyjna biegnie przez 4G (MME), a dane użytkownika mogą już korzystać z pasma 5G. Architektonicznie jest to hybryda: nowy RAN 5G, ale logika mobilności, sesji i tożsamości wciąż siedzi w infrastrukturze LTE.

5G SA oznacza pełny 5G Core standalone i gNodeB podłączony bezpośrednio do 5GC. Dopiero wtedy dostępne stają się w praktyce takie funkcje jak pełne network slicing, architektura SBA, elastyczne rozmieszczenie UPF (w tym przy edge) czy scenariusze URLLC. Jeśli ktoś pyta „czy to już prawdziwe 5G?”, zwykle ma na myśli właśnie wdrożenie SA.

Co to jest UPF w 5G i dlaczego jest tak ważny dla edge computingu i opóźnień?

UPF (User Plane Function) to jedyna funkcja 5G Core, która przesyła realne pakiety użytkownika (IP lub Ethernet). Odpowiada za zakończenie tuneli GTP, kształtowanie ruchu, stosowanie polityk QoS, a także za przekierowanie danych do odpowiednich sieci czy aplikacji. Cała reszta NF w core to głównie płaszczyzna sterowania (C‑plane).

Ponieważ UPF można instalować w wielu lokalizacjach, operatorzy umieszczają część instancji blisko RAN – w węzłach edge. Dzięki temu dane np. z robotów przemysłowych czy gogli AR nie muszą lecieć przez centralne data center, tylko są „zawracane” lokalnie do aplikacji na krawędzi. To jeden z głównych powodów, dla których w 5G da się zejść z opóźnieniami do pojedynczych milisekund w realistycznych scenariuszach URLLC.

Najważniejsze wnioski

• Architekturę 5G najlepiej widzieć jak łańcuch od urządzenia użytkownika przez RAN, core i sieć transportową aż po chmurę i aplikacje – każde ogniwo ma inne protokoły, ograniczenia i typowe punkty awarii.
• 5G zrywa z myśleniem „kup pudełko od dostawcy” – zamiast monolitycznych szaf są funkcje sieciowe (NF) uruchamiane jako VNF/CNF, skalowane poziomo i zarządzane jak mikrousługi w chmurze.
• 5G Core jest zbudowany w modelu SBA: funkcje typu AMF, SMF, UPF, UDM, PCF komunikują się po HTTP/2 z użyciem API i JSON, a ich relacje są dynamiczne dzięki rejestracji w NRF.
• Różnica między 4G i 5G to nie tylko szybsze radio – kluczowe są network slicing, natywna integracja z edge computing oraz obsługa trzech scenariuszy (eMBB, URLLC, mMTC), z których każdy wymusza inną architekturę od RAN po UPF.
• Patrząc na diagram sieci 5G, technik w pierwszej kolejności powinien szukać granicy RAN–core, miejsc skalowania NF, mechanizmów redundancji, rozmieszczenia UPF (centralny vs edge) oraz sposobu realizacji slicing’u end-to-end.
• Przejście z EPC 4G do 5G Core to zmiana filozofii: z kilku statycznie spiętych boxów na zestaw elastycznych usług, które można niezależnie wdrażać, skalować, aktualizować i orkiestrwać (NFV/MANO, CI/CD, monitoring rozproszony).