5G-Edge-Demo-Plattform für den Mobile World Congress, entwickelt in 30 Tagen
Projekt kurz zusammengefasst: Promwad lieferte den vollständigen Software-Stack: die Ebene, die mit dem 5G-L1-Datapath des Kunden kommuniziert, das Backend, das beide Server koordiniert, und das Dashboard, das das Publikum tatsächlich sah. Das gesamte System lief live auf dem Mobile World Congress und validierte die zentrale Architekturthese des Kunden anhand gemessener Zahlen.
Kunde & Herausforderung
Unser Kunde ist ein US-amerikanisches Halbleiterunternehmen, das eine chipletbasierte Edge-Compute-Plattform entwickelt: ARM-CPU-Chiplets, kombiniert mit einer dedizierten Processing Unit, ausgelegt für AI- und 5G-Workloads, die Telekommunikationsanbieter an den Netzwerkrand verlagern. Das Leistungsversprechen: Cloud-Performance bei einem Bruchteil der Leistungsaufnahme herkömmlicher Serverhardware.
Wir hatten bereits zuvor einmal mit ihnen zusammengearbeitet, in einem kurzen DPDK-Consulting-Projekt, das half, einige Architekturfragen zu klären, bevor sie das Konzept intern weiter ausarbeiteten.
Mehrere Monate später kamen sie mit einer deutlich anspruchsvolleren Anfrage zurück: eine Live-Demo auf dem Mobile World Congress in 30 Tagen. Ihr Engineering-Team arbeitete tief am Rechenkern, einer vollständigen Implementierung eines 5G-L1-Datapaths. Deshalb holten sie Promwad an Bord, um den gesamten umgebenden Stack zu übernehmen.
Lösung
Promwad übernahm die Verantwortung für alles rund um den Rechenkern des Kunden: die Software, die ihn betreibt, und die Ausgabe, die dem Publikum präsentiert wird. Das System besteht aus drei Ebenen, die zusammenarbeiten.
Die unterste Ebene ist die Control Unit, geschrieben in C++ auf Basis von DPDK. Alle 500 µs übergibt sie einen neuen Parametersatz an den 5G-L1-Datapath des Kunden, eine vollständige Echtzeitimplementierung des Verarbeitungs-Stacks der physikalischen Schicht, und sammelt anschließend Metriken zurück. Jede Nachricht wird gemäß dem 5G-FAPI-Standard (SCF 222.10.00) serialisiert. Mehrere Instanzen laufen parallel auf beiden Hosts, ARM und x86. Diese Ebene entscheidet darüber, ob die Demo unter Live-Last stabil bleibt.
Darüber liegt das Backend, entwickelt in Python mit FastAPI. Es verbindet sich über gRPC mit beiden Control Units, koordiniert die Ausführung auf beiden Plattformen, leitet die vom Dashboard kommenden Befehle weiter, konsolidiert die Metriken beider Architekturen in einem einzigen Live-Feed und streamt alles per WebSocket an den Browser.
Die oberste Ebene ist das Dashboard, das das Publikum tatsächlich gesehen hat. Es handelt sich um eine TypeScript-basierte Weboberfläche mit Echtzeitdiagrammen, die die Energieeffizienz von ARM- und x86-Architekturen direkt nebeneinander vergleichen, sowie mit interaktiven Steuerelementen, über die der Presenter während der Demonstration Workload-Parameter anpassen kann. Ziel war es, die Zuschauer die Hypothese selbst testen zu lassen, statt ihnen lediglich eine vorab aufgezeichnete Animation zu zeigen.
Das Team war klein und ohne Rollenüberschneidungen aufgebaut: ein Projektmanager, ein Frontend-Entwickler und eine Backend-Gruppe, die die Control Unit und die Orchestrierungsebene abdeckte. Entscheidungen mit den Ingenieuren des Kunden wurden in regelmäßigen Arbeits-Calls getroffen und anschließend schriftlich festgehalten. Nur dieser Arbeitsmodus hält stand, wenn zwei Engineering-Teams benachbarte Komponenten gegen dieselbe harte Deadline entwickeln.
Business Value
Der Kunde verließ die Veranstaltung mit einem gemessenen Ergebnis statt mit einem Versprechen: Der Energieeffizienzvorteil seiner ARM-basierten Architektur gegenüber x86 wurde live und unter repräsentativen Workload-Bedingungen demonstriert. Die von uns entwickelte Plattform bleibt seine Demonstrationsbasis, während er die nächste Finanzierungsrunde vorbereitet und den Übergang zu dediziertem Silizium einleitet.
Mehr zu unserer Arbeit mit DPDK
- SPDK- & DPDK-Lösungen: unsere Expertise in der Hochleistungs-Paketverarbeitung für Telekommunikation, Edge Computing und 5G-Anwendungen.
- TCP-PEP- und QoS-Module für HTS-Satellitenkommunikation: wie wir DPDK eingesetzt haben, um TCP-Traffic und Bandbreitenbegrenzungen in einem geostationären Satellitennetzwerk zu verwalten.
- Wie Promwad die Netzwerkgeschwindigkeit mit DPDK maximiert: was DPDK tatsächlich leistet und wie wir es einsetzen, um Latenzen in Produktionssystemen zu reduzieren.
FAQ
Warum DPDK für eine 5G-Edge-Demo statt des standardmäßigen Linux-Netzwerk-Stacks verwenden?
Der Netzwerk-Stack des Linux-Kernels verursacht Overhead und Latenzen, die bei hohen Paketraten zum Problem werden. DPDK umgeht den Kernel, läuft im User Space und schreibt direkt auf die Netzwerkkarte. Dadurch ist eine bis zu 10-mal schnellere Paketverarbeitung möglich. Für eine 5G-Edge-Workload mit 500-µs-Slot-Zyklen über mehrere parallele Datapath-Instanzen hinweg macht genau dieser Unterschied den Abstand zwischen einer funktionierenden und einer ins Stocken geratenen Demo aus.
Kann Promwad mit DPDK auf mehreren Hardwareplattformen arbeiten?
Ja. DPDK war ursprünglich auf Intel ausgerichtet, unterstützt heute aber Hardware vieler Anbieter. In diesem Projekt lief derselbe Software-Stack parallel auf ARM- (AArch64) und x86-Server-Hosts, mit identischen Performance-Eigenschaften auf beiden Plattformen — genau dadurch wurde der Vergleich der Energieeffizienz überhaupt erst möglich.
Wo passt DPDK in moderne 5G-Architekturen?
DPDK ist einer der Bausteine für 5G-Core-Netze, Network Slicing und NFV. In Edge-Deployments ermöglicht es die Echtzeitverarbeitung von Paketen und Frames nahe an der Datenquelle — genau dieses Szenario sollte die Demo-Plattform validieren.
Worin unterscheidet sich DPDK von kernelbasierten Ansätzen wie eBPF/XDP?
DPDK läuft im User Space und umgeht den Linux-Kernel vollständig. Dadurch erhält die Anwendung volle Kontrolle über den Paketfluss bei niedrigster Latenz und höchstem Durchsatz. eBPF/XDP laufen innerhalb des Kernels und sind eng in den bestehenden Netzwerk-Stack integriert. DPDK eignet sich besser, wenn maximale Performance und individuelle Paketverarbeitung erforderlich sind, etwa bei einem 5G-L1-Datapath. eBPF/XDP eignen sich besser, wenn Kernel-Integration für Monitoring, Sicherheit oder Tracing gewünscht ist.
Haben Sie weitere DPDK-Case-Studies, die wir uns ansehen können?
Telekommunikationsanbieter, Hersteller von Netzwerkausrüstung, Cloud- und Rechenzentrumsbetreiber, Finanz- und Handelsunternehmen, Cybersecurity-Unternehmen sowie Unternehmen mit stark frequentierten CDNs. Der gemeinsame Nenner sind Workloads, die den Overhead eines standardmäßigen Netzwerk-Stacks nicht tolerieren.
