Einleitung

Die Technology Summits von RDK-B der letzten Jahre zeigten deutlich, wie diese Technology eine Reife erlangte, mit der auch komplexe Applikationen in das Framework integriert werden können. Beispiele für solche Applikationen sind „Parental Control“, WiFi-Vernetzung mit „Easy Mesh“, „Device Identification“, Integration von Mobilfunkschnittstellen und vieles mehr.

Damit versetzt sie Provider in die Lage, das Potenzial dieser Technik vermehrt auszunutzen, wie wir es bereits in unserem Artikel RDK-B Revolution im Heimnetzbereich (?) beschrieben haben. Der Kern dieses Potenzials liegt in dem modularen Design des RDK-B Stacks, in den zusätzliche Softwarekomponenten so integriert werden können, dass sie die Ressourcen des RDK-B Stacks wie beispielsweise R-BUS und D-BUS und das Persistent Storage Management (PSM) in Anspruch nehmen können, um mit anderen Komponenten zu interagieren. Insbesondere der dadurch automatisch gewährleistet Remote Service über das Protokoll WebPA bietet einen erheblichen Vorteil.

Eine solche Integration wollen wir in diesem Blog anhand eines einfachen Beispiels demonstrieren, wie wir es in ähnlicher Weise bereits in Projekten umgesetzt haben. Wir reduzieren die Anforderungen dabei so weit, dass unser Vorgehen unmittelbar nachvollziehbar ist und selbst ausgeführt werden kann.

Unser Beispiel demonstriert die Integration einer Applikation wie Iperf3 in die RDK-B Referenzumgebung. Iperf3 ist ein vielseitiges Tool, mit dem sich unter anderem die Qualität und der Durchsatz von IP-Verbindungen ermitteln lässt. Wir haben es insbesondere ausgesucht, um seine Eignung im Kontext der vom Broadband Forum (BBF) vorgeschlagenen QoS Messungen (BBF TR-143: Enabling Network Throughput Performance Tests and Statistical Monitoring) zu untersuchen.

In diesem Beitrag zeigen wir, wie das Tool in die Build-Umgebung[1] von RDK-B eingefügt wird, so dass Iperf3 als eine Softwarekomponente von RDK-B auf dem Raspberry 4 (RPi4) genutzt werden kann. Der RPi4 ist eine der Referenzumgebungen von RDK-B.

Ein Folgebeitrag soll sich dann damit befassen, wie Iperf3 mit den Mitteln von RDK-B für die Gestaltung einer Applikation (RDK-B Service Komponente) im Kontext von TR-143 genutzt werden kann.

Vorgehensweise

Der Ablauf der Integration einer Anwendung in den RDK Software Stack folgt der folgenden prinzipiellen Vorgehensweise

  1. Generierung der Build Umgebung für das Referenzsystem (RPi4) wie auf RDK-Central beschrieben
    Für die Nutzung dieser Quellen ist lediglich eine Registrierung erforderlich.
  2. Download des source code von iperf3 von Index of /pub/iperf/ (es.net) in das Repository der Build Umgebung
  3. Anpassung des RDK Software Stacks mit zusätzlichen Komponenten für die Applikation
  4. Entwurf und Codierung einer RDK-B-Softwarekomponente, die die Applikation als Service bereitstellt
  5. Erstellen der Image Datei und brennen auf eine SD-Karte für den RPi4

Plattform

Die Erstellung eines RDK-B Images aus einem der aktuellen RDK-B Releases kann leicht in einer Microsoft WLS 2.0 erfolgen, beispielsweise mit Ubuntu 20.04LTS. Das System sollte jedoch ausreichend mit CPU Kernen und Speicher bestückt sein, damit die Wartezeiten überschaubar bleiben. Beispielsweise benötigt ein Intel i7 – 1260P (12 Kerne, 16log. Prozessoren) in einem Notebook mit 48GByte RAM circa 100 Minuten. Doch dieser Prozess muss in der Regel nur einmal vollständig durchlaufen werden. In der weiteren Entwicklung werden nur noch der hinzugefügte Code und abhängige Pakete neu kompiliert.

Integration in die Build Umgebung von RDK-B

RDK-B nutzt das Yocto Projekt der Linux Foundation, um die RDK-Software für unterschiedliche Router Architekturen zu erstellen. Der Software-Stack wird als hierarchische Verzeichnisstruktur (Baum) abgebildet und jede Komponente ist als ein Unterverzeichnis (Zweig) in dieser Struktur abgelegt. Dieser Baum stellt quasi die Anleitung zum Kompilieren des Images[2] dar.

Für eine neue Komponente wird ein zusätzlicher Zweig eingerichtet, der alle Konfigurationseinstellungen und Rezepte (Recipes in der Sprache Yoctos) enthält, die für eine Kompilierung erforderlich sind.

Der Ordner wurde in unserem Beispiel meta-rdk-iperfthrd genannt und er enthält Informationen über evtl. Lizenzen, eine grundlegende Paketkonfiguration und den Recipes selbst.

Hier eine Baumansicht des Beispiels:

Abbildung 1:  Integration des Packages in den Verzeichnisbaum

Abbildung 1:  Integration des Packages in den Verzeichnisbaum

Der Ordner mit den Recipes haben wir zweigeteilt. Ein Unterordner enthält das Recipe zur Erstellung der RDK-Software Komponente, die den Iperf3-Service anbietet und steuert, der andere Unterordner enthält das Recipe zum Kompilieren von Iperf3. Die Zweiteilung dient zum einen der besseren Übersichtlichkeit und zum anderen der vereinfachten Fehlersuche, wenn beim Debugging die beiden Komponenten getrennt analysisiert werden können.

In diese Struktur werden die benötigten Rezepte, erkennbar an dem Suffix “.bb”, eingefügt. Ein Rezept in Yocto enthält alle Informationen und Angaben zu evtl. zusätzlichen Ressourcen, damit aus dem Quellcode einer Komponente eine im RDK-Stack ausführbare Datei erzeugt werden kann. Zusätzliche Ressourcen sind beispielsweise Services, die der Kernel bereitstellen muss, damit das Programm lauffähig wird. Yocto ist dafür zuständig, dass alle angegebenen Ressourcen bei der Erstellung eines Images auch erzeugt werden.

Der wichtigste Teil des Rezepts für eine Iperf3 Kompilierung ist der Quellcode, der öffentlich verfügbar ist.

Abbildung 2: Beispiel für das Recipe iperfthrd.bb

Abbildung 2: Beispiel für das Recipe iperfthrd.bb

Der Eintrag “SRC_URI = .... ” im Rezept gibt den Ursprung der “Zutat” an.

Der Eintrag “S= "${WORKDIR}/git” markiert den Ordner in den das Iperf3 Repository geklont werden soll und in dem dann der Quellcode zum Kompilieren zu finden ist.

Der Eintrag “inherit autotools pkgconfig” bestimmt die Tools zum Kompilieren und Zusammenbau der Anwendung.

Damit haben wir eine kompakte Automatisierung geschaffen, mit der Yocto Iperf3 erstellen kann und im fertigen Image sollte dann Iperf3 als ausführbares Programm aufgerufen werden können.

Jetzt müssen noch an drei Stellen Änderungen vorgenommen werden, um das Metapackage für Iperf3 bekannt zu machen, damit es beim Erstellen des Images auch berücksichtigt wird.

Erstens:

Um das Blatt in den Baum zu hängen, tragen wir einen entsprechenden Eintrag in die zentrale Konfigurationsdatei ein.
Konkret erweitern wir die Datei “meta-cmf-raspberrypi/conf/layer.conf” um den Eintrag LAYERDEPENDS_cmf-raspberrypi = "iperfthrd"

Zweitens:

Um die zugehörigen Recipes zu finden, tragen wir im Setup-environment unser Metapackage ein. Konkret erweitern wir die Datei “meta-cmf-raspberrypi/setup-environment” um den Eintrag BBLAYERS  =+ "${RDKROOT}/meta-rdk-iperfthrd" wie es unten gezeigt ist.

Abbildung 3: Auszug aus meta-cmf-raspberrypi/setup-environment

Abbildung 3: Auszug aus meta-cmf-raspberrypi/setup-environment

Drittens:

Das Package, das für den Bau der Anwendung genutzt werden soll, ist Yocto noch bekannt zu machen.
Konkret erfolgt dies in der Datei „meta-cmf-raspberrypi/recipes-core/packagegroups/packagegroup-rdk-oss-broadband.bbappend“.
Darin ergänzen wir die Variable DEPENDS_packagegroup-rdk-oss-broadband_append um den Wert "iperfthrd".

Jetzt sind alle Zutaten benannt, mit denen ein RDK-B Image erzeugt werden kann, das die Applikation Iperf3 enthält.

Wir haben diesen Prozess mit dem RDK-B Release RDKB-2024q1-dunfell durchgeführt und ein RDK-B Image mit der Applikation Iperf3 für den RPi4 erzeugt, was wir nachfolgend demonstrieren wollen.

 

Demonstration

Die folgende Abbildung zeigt das Terminal eines RPi4 auf dem das erzeugte RDK-Image installiert wurde. Der Befehl der ersten Zeile demonstriert, dass es sich um ein RDK-B-System handelt und nennt dazu verschiede Versionsinformationen.

Mit dem nächsten Befehl wird die RDK-Komponente für Iperf3 geladen und der darauffolgende Befehl startet eine Iperf3 Messung, die nach circa 5 Sekunden endet und das Ergebnis präsentiert.

Abbildung4: Terminalabbild mit dem Ergebnis der Iperf3 Messung

Abbildung4: Terminalabbild mit dem Ergebnis der Iperf3 Messung

Fazit

Mit der Integration von Iperf3 in ein RDK-System stehen vielfältige Möglichkeiten zur Untersuchung von QoS mit Iperf3 zur Verfügung.

In einem Folgebeitrag werden wir auf diese Möglichkeiten näher eingehen, und dabei insbesondere auch die Softwarekomponente des RDK-B Iperf Service beleuchten.

[1] Build-Umgebung: Bausatz mit dem sich ein lauffähiges Betriebssystem erstellen lässt.

[2] Image: Container mit dem zukünftigen Betriebssystem, und allen Anwendungen

Autoren

Joachim Bodensohn

Sebastian Limberg