Introduction

The Technology Summits of RDK-B in recent years have clearly demonstrated how this technology has matured to the point where even complex applications can be integrated into this framework. Examples of such applications include: “Parental Control,” WiFi networking with “Easy Mesh,” “Device Identification,” integration of mobile interfaces, and much more.

This development enables providers to increasingly exploit the potential of this technology, as we already discussed in our article RDK-B Revolution im Heimnetzbereich (?).The core of this potential lies in the modular design of the RDK-B stack, which allows additional software components to be integrated in a way that they can utilize the resources of the RDK-B stack, such as R-BUS and D-BUS, and the Persistent Storage Management (PSM) to interact with other components. A significant advantage is the automatically ensured remote service via the WebPA protocol.

In this blog, we want to demonstrate such an integration using a simple example, similar to what we have implemented in projects before. We will minimize the requirements so that our approach is easily understandable and can be followed and executed by others.

Our example demonstrates the integration of an application like Iperf3 into the RDK-B reference environment. Iperf3 is a versatile tool that can be used to assess the quality and throughput of IP connections, among other things. We specifically chose it to examine its suitability in the context of the Quality of Service (QoS) measurements proposed by the Broadband Forum (BBF) (BBF TR-143: Enabling Network Throughput Performance Tests and Statistical Monitoring).

In this post, we will show how to incorporate the tool into the RDK-B build environment[1] so that Iperf3 can be used as a software component of RDK-B on the Raspberry Pi 4 (RPi4). The RPi4 is one of the reference environments for RDK-B.

A follow-up post will then address how Iperf3 can be used with RDK-B tools to create an application (RDK-B service component) in the context of TR-143.

Procedure

The process of integrating an application into the RDK software stack follows these general steps:

  1. Generate the Build Environment for the Reference System (RPi4)
    Start by setting up the build environment for the Raspberry Pi 4 as described on RDK-Central. Registration is required to access these resources.
  2. Download the Source Code for Iperf3
    Download the Iperf3 source code from the Index of /pub/iperf/ (es.net) and place it into the repository of the build environment.
  3. Modify the RDK Software Stack with Additional Components for the Application
    Adjust the RDK software stack by integrating additional components necessary for the application.
  4. Design and Code an RDK-B Software Component
    Create an RDK-B software component that will provide the application as a service.
  5. Build the Image File and Burn It onto an SD Card for the RPi4
    Finally, compile the image file and burn it onto an SD card for use with the Raspberry Pi 4.

Platform

Creating an RDK-B image from one of the latest RDK-B releases can be easily accomplished using Microsoft WSL 2.0, for example, with Ubuntu 20.04 LTS. However, the system should be equipped with sufficient CPU cores and memory to keep wait times reasonable. For instance, an Intel i7-1260P (12 cores, 16 logical processors) in a laptop with 48 GB of RAM takes approximately 100 minutes to complete the process. This full process typically needs to be run only once. During further development, only the newly added code and dependent packages will need to be recompiled.

Integration in die Build Umgebung von RDK-B

RDK-B uses the Yocto Projekt from the Linux Foundation to build RDK software for various router architectures. The software stack is organized as a hierarchical directory structure (tree), where each component is stored as a subdirectory (branch) within this structure. This tree essentially serves as the instruction manual for compiling the image [2].

To add a new component, an additional branch is created, containing all the configuration settings and Recipes required for compilation.

In our example, the folder is named meta-rdk-iperfthrd. This folder contains information about potential licenses, a basic package configuration, and the recipes themselves.

Here is a tree view of the example:

Figure 1: Integration of the Package into the Directory Tree

Figure 1: Integration of the Package into the Directory Tree

We have divided the folder containing the recipes into two subfolders. One subfolder contains the recipe for creating the RDK software component that offers the Iperf3 service and manages it, while the other subfolder contains the recipe for compiling Iperf3. This division helps in maintaining clarity and simplifies debugging by allowing separate analysis of the two components.

In this structure, the necessary recipes are added and are identifiable by the “.bb” suffix. A recipe in Yocto includes all the information and details about any additional resources required to build an executable file from the source code within the RDK stack. Additional resources might include services that the kernel must provide for the program to run. Yocto ensures that all specified resources are generated during image creation.

The most crucial part of the recipe for compiling Iperf3 is the link to the source code that is publically available.

Figure 2: Example of the Recipe iperfthrd.bb

Figure 2: Example of the Recipe iperfthrd.bb

The entry SRC_URI = .... in the recipe specifies the origin of the “ingredient”.

The entry S= "${WORKDIR}/git indicates the folder where the Iperf3 repository will be cloned and where the source code for compilation will be located.

The entry inherit autotools pkgconfig determines the tools used for compiling and building the application.

This setup creates a compact automation process, allowing Yocto to build Iperf3, which should then be callable as an executable program in the final image.

Three additional changes are needed to make the Iperf3 meta-package recognized so that it would be included in the image build as well:

First: Add Entry to Configuration File

To integrate the package into the build tree, we’ll add an entry to the central configuration file. Specifically, we expand the file meta-cmf-raspberrypi/conf/layer.conf to include LAYERDEPENDS_cmf-raspberrypi = "iperfthrd".

Second: Update the Setup Environment

To find the associated recipes, we‘ll include the meta-package in the setup environment. Specifically, we expand the file meta-cmf-raspberrypi/setup-environment to include BBLAYERS  =+ "${RDKROOT}/meta-rdk-iperfthrd" as shown below:

Figure 3: Excerpt from meta-cmf-raspberrypi/setup-environment

Figure 3: Excerpt from meta-cmf-raspberrypi/setup-environment

Third: Registering the Package in Yocto for Build Integration

Yocto needs to be made aware of the package used for building the application. This is done by updating the file meta-cmf-raspberrypi/recipes-core/packagegroups/packagegroup-rdk-oss-broadband.bbappend. Specifically, we’ll add the value “iperfthrd” to the variable DEPENDS_packagegroup-rdk-oss-broadband_append.

With all the components named, an RDK-B image can now be generated that includes the Iperf3 application.

We carried out this process using the RDK-B release RDKB-2024q1-dunfell and created an RDK-B image with the Iperf3 application for the Raspberry Pi 4 (RPi4), which we will demonstrate next.

Demonstration

The following image shows a screenshot of the terminal of a Raspberry Pi 4 (RPi4) where the generated RDK image has been installed. The command in the first line demonstrates that the system is running RDK-B and it provides various version information.

The next command loads the RDK component for Iperf3, and the following command starts an Iperf3 measurement, which completes after approximately 5 seconds and presents the results.

Abbildung4: Terminalabbild mit dem Ergebnis der Iperf3 Messung

Abbildung4: Terminalabbild mit dem Ergebnis der Iperf3 Messung

Conclusion

By integrating Iperf3 into an RDK system, a wide range of possibilities for investigating QoS with Iperf3 becomes available.

In a follow-up post, we will explore these possibilities in more detail, with a particular focus on the RDK-B Iperf Service software component.

[1] Build Environment: A toolkit used to create a functional operating system.

[2] Image: A container that includes the future operating system and all applications.

Authors

Joachim Bodensohn

Sebastian Limberg