Open-Source-Software stellt Netzwerkkomponenten bereit, mit denen Sie 5G-Netzwerkfunktionen vom Netzwerkkern bis zum Funk simulieren können.
von Lincoln Lavoie, Interoperabilitätslabor der University of New Hampshire
Die Entwicklung und Bereitstellung einer Laborinfrastruktur zur Unterstützung des Testens von 5G- und Open Radio Access Network-Systemen (Open RAN) kann eine entmutigende und komplexe Aufgabe darstellen. Vor Open RAN war diese Aufgabe nur durch die direkte Zusammenarbeit mit den großen Netzwerksystemanbietern möglich. Seitdem haben mehrere Open-Source-Projekte und -Organisationen Materialien entwickelt, die auf den Spezifikationen von 3GPP und O-RAN Alliance basieren. Diese Tools und Ressourcen ermöglichen die Erstellung einer vollständigen 5G-Bereitstellung, die vom mobilen Kern bis zum RAN reicht, und stellen Ingenieuren unschätzbare Ressourcen zur Verfügung.
Open-Source-Aktivitäten spielen eine wichtige Rolle, da sie ein schnelles Prototyping und die Verifizierung der Spezifikationen ermöglichen. Diese Spezifikationen könnten noch in Entwurfsform vorliegen. Viele Standardisierungsgruppen haben Praktiken und Richtlinien entwickelt, um die Verwendung von Open Source zu fördern. Zu diesen Gruppen gehören die Internet Engineering Task Force (IETF), Richtlinien und Praktiken rund um „groben Konsens und laufenden Code“ und die Open Software Community (OSC) der O-RAN Alliance, die formelle Programme implementiert haben.
Einer der komplexesten Aspekte bei Open-Source-Projekten und -Komponenten in einem 5G-Testlabor ist tatsächlich der Ausgangspunkt. In diesem Artikel besprechen wir einige grundlegende Komponenten, die Ingenieure als Startblöcke verwenden können, und erklären, wie Open-Source-Software Open-RAN-Tests unterstützen kann.
Um mit dem Prozess zu beginnen, müssen Sie zunächst einige der Hauptkomponenten eines 5G-Netzwerks verstehen. In diesem Fall werden wir das Kernnetzwerk als einzelne Komponente verallgemeinern, da derzeit mehrere Open-Source-Optionen die von den 3GPP-Spezifikationen geforderten Kernnetzwerkfunktionen implementieren. Der 5G-Mobilfunkkern umfasst verschiedene einzelne Netzwerkfunktionen, die die von 3GPP definierte dienstbasierte Architektur ermöglichen.
Drei bekannte Beispiele für Open-Source-Systeme, die den 5G-Kern implementieren, sind das Open 5GS-Projekt, das kostenlose 5GC-Projekt und die Open Air Interface 5G-Kernnetzwerkkomponente. Bei den beiden erstgenannten Projekten handelt es sich um eigenständige Implementierungen des 5G-Kerns. Gleichzeitig ist Letzteres enger mit dem größeren Open Air Interface (OAI)-Projekt gekoppelt, das auch das RAN bereitstellen kann.
Am UNH-IOL verwenden wir häufig den Open 5GS-Kern, den wir in zwei Komponentensätzen bereitstellen. Zunächst stellen wir die primären Kontrollkomponenten bereit, einschließlich der Access and Mobility Management Function (AMF), der 5G Session Management Function (SMF) und anderer. Zweitens stellen wir die User-Plane-Funktion (UPF) bereit, die für die Weiterleitung des Teilnehmerverkehrs von den RAN-Schnittstellen an das Datennetzwerk (z. B. das Internet) verantwortlich ist. Dies ermöglicht effektiv die Trennung von Steuerungs- und Benutzerebene (CUPS), wobei diese Funktionen auf separaten virtuellen Maschinen bereitgestellt werden. Ebenso könnten wir in größeren Bereitstellungen auch mehrere UPF-Instanzen implementieren, um die Last des Abonnentenverkehrs auszugleichen. Figure 1 zeigt einen Teil der Logistik dieses Einsatzes in unserem Labor.
Abbildung 1. Das UNH-IOL hat diese Open 5GS-Topologie für Interoperabilitätstests von 5G-Netzwerkkomponenten eingesetzt.
Vom Kern zum RAN
Sobald das Kernnetzwerk läuft, wird der nächste wahrscheinliche Schwerpunkt auf dem RAN liegen. In diesem Bereich nähern wir uns der Spitze der Open-Source-Entwicklungsbemühungen, je nachdem, welche Richtung bei der Bereitstellung eingeschlagen wird. Das RAN stellt eine HF-Verbindung zwischen dem Benutzergerät (UE) und dem mobilen Kernnetzwerk bereit. Das ist eine zu starke Vereinfachung, aber wir bleiben bei dieser Arbeitsdefinition, ohne uns mit einigen komplexen Themen wie Übergaben, Unterstützung mehrerer Zellen, Trägeraggregation usw. zu befassen. Hier wird sich der wichtigste Faktor im Auswahlprozess wahrscheinlich auf die Funkkomponenten konzentrieren, für die wir zwei Optionen haben.
Erstens könnten wir ein auf Software Defined Radio (SDR) basierendes System bereitstellen, das das Open Air Interface-Projekt nutzt, um die Software und Firmware für die Implementierung des vollständigen RAN bereitzustellen, oder genauer gesagt, einer guten Basisstation. Abhängig von der ausgewählten SDR-Hardware ist es möglicherweise möglich, HF-Ports direkt mit der Antenne zu verbinden. Um eine Verletzung des lizenzierten Spektrums zu vermeiden, sollte eine HF-Verbindung zum UE-Gerät möglich sein. In diesem Sinne benötigt ein Labor auch abgeschirmte Kammern oder HF-Isolationsräume, aber das würde den Rahmen dieses Artikels sprengen.
Ein weiterer Ansatz zur Implementierung von RAN folgt den Spezifikationen der O-RAN Alliance, bei der der gNodeB in diskrete Komponenten zerlegt wird: Radio Unit (RU), Distributed Unit (DU) und Centralized Unit (CU). In diesem Bereich kann das OAI-Projekt einige Software bereitstellen, insbesondere die DU- und CU-Komponenten, die dann die Open Fronthaul-Schnittstelle (OFH) gegenüber dem RU implementieren. Für die RU ist die Auswahl eines Produkts von einem Anbieter erforderlich, da derzeit keine Open-Source-RUs existieren.
Um die korrekte Übertragung von Funksignalen oder Frames sicherzustellen, müssen DU und RU die Zeit synchronisieren und sie gut genug verstehen, um die OFH-Schnittstelle zu unterstützen. Auch hier sind mehrere Architekturen oder Ansätze möglich, die als unterschiedliche Konfigurationen LLS-C1 bis LLS-C4 beschrieben werden. In unserem Labor implementieren wir derzeit LLS-C3, wobei einer der Fronthaul-Switches als IEEE-1588-Grandmaster-Takt dient, der das Timing für RU und DU bereitstellt. Für die Netzwerkkarte auf dem DU-Server ist Hardware-Zeitstempelunterstützung erforderlich und das ptp4l-Projekt wird verwendet, um die Serveruhren mit dem Netzwerk zu synchronisieren. Figure 2 zeigt diese Konfiguration im Labor.
Abbildung 2. Für Open RAN verwendet das Labor diese disaggregierte Topologie, die die Netzwerkbegrenzung berücksichtigt.
Angenommen, Sie verwenden handelsübliche UE-Geräte wie Telefone, dann ist alles zum Testen bereit, oder? Na ja, fast. Bisher sind ein Kernnetz und ein Funknetz im Einsatz. Sofern keine Konfigurationsprobleme vorliegen, sollte der gNodeB beim Kernnetzwerk registriert und mit diesem verbunden sein. Es sollte mindestens eine Zelle im gewünschten 5G-Band bereitstellen, damit das UE eine Verbindung herstellen kann. Das UE muss sich beim Netzwerk authentifizieren, was von der SIM-Karte abhängt. Bei 5G funktioniert die Authentifizierung „in beide Richtungen“, wobei das UE das Netzwerk authentifiziert und das Netzwerk das UE authentifiziert. Ohne auf alle Details einzugehen, ist es erforderlich, dass die Netzwerkinformationen, d. h. einige der im Kernnetzwerk bereitgestellten Schlüssel, mit den Schlüsseln in der SIM-Karte übereinstimmen, damit die kryptografische Herausforderung/Antwort erfolgreich abgeschlossen werden kann. Es ist (aus sehr guten Gründen) nicht möglich, diese Schlüsselwerte von einer SIM-Karte auszulesen.
Einige SIM-Karten sind jedoch programmierbar, typischerweise zu Testzwecken. Der letzte Teil der Laborhardware ist also ein kleiner SIM-Kartenleser/-schreiber zusammen mit den programmierbaren SIMs. Glücklicherweise gibt es auf der Programmierseite einige Open-Source-Tools, mit denen Sie die Netzwerkschlüsselwerte und die Teilnehmer-IDs in die SIM-Karte programmieren können, um eine erfolgreiche Authentifizierung zu ermöglichen. Zu diesem Zweck haben wir im Labor die Tools pysim und sysmo-usim-tool verwendet.
Mithilfe von Open-Source-Tools können Sie das UE-Gerät mit einer funktionierenden 5G-Verbindung im Labor online schalten. Die ganze Arbeit hier kratzt nur an der Oberfläche des 5G-Netzwerks und der Testmöglichkeiten. Dennoch sollten Sie ein Labor mit Open-Source-Ressourcen einrichten, das in der Lage ist, bei richtiger Konfiguration erweiterte Funktionen zu unterstützen, wie z. B. Network Slicing oder Carrier/Cell Aggregation, um nur einige mögliche Themen zu nennen.