Geon Technologies is both a member and strong supporter of the REDHAWK SDR community. As such, we have unique opportunities to not only showcase our own technologies using REDHAWK SDR but also solutions to common system architecture problems. One of the strongest examples of this work has been showcased over several YouTube videos and blog posts here at GeonTech.com. Each public release highlighted both our in-house Cognitive Radio system, built on REDHAWK, as well as how we simplified our deployment and demo build process by using Docker containers.

Cognitive Radio Project

The original Cognitive Radio project began as a small business investment for research which targeted solutions for cognitive radio receiver design. Where traditional receivers may have a handful of operating environments or signals in which they excel, the cognitive radio receiver scans across traditional environments to learn the nature of the signal space using an inference engine. The outputs of such an engine are estimates of not only the presence of signals but also signal types, protocols, etc., which can potentially lead to more deliberate processing of the signal space.

Two of the core elements to this system are generic software-defined radio receivers for ingesting RF data and perhaps several general purpose processors (GPPs) for executing a variety of signal processing techniques, which analyze the data. In REDHAWK terms, we have Devices implementing the generic FrontEnd Interfaces specification (which operate within Device Managers), and a set of Applications (Waveforms) that can execute in a distributed fashion across the available GPPs, respectively. All of these elements operate within a single logical Domain, which may be spanned across multiple hardware or virtual subsystems, thanks in large part to the features REDHAWK provides the system architecture.

System Designer’s Dilemma

As we continue to rapidly grow this system with new features and capabilities, we face the same development issues common to the industry and typical REDHAWK installations up to version 2.0.3. The two primary issues are hardware support and system deployment (for testing, demos, etc.).

Hardware support is a typical issue mainly because the most turn-key (and thus typical) REDHAWK installation up to present has been on CentOS 6.x versions by way of RPM (Redhat Package Manager) files. The latest radio receivers however often require drivers that leverage libraries significantly more current than what is available in that operating system. The most common offender is Boost, which because of ABI differences creates a number of issues when mixing versions in the same environment. This leaves implementers a difficult decision between re-compiling everything for REDHAWK from source on a more up-to-date operating system (thus breaking the ability to launch Applications against RPM-based REDHAWK installations) and migrating all systems to the same operating system (and re-compiled installation) all to support a particular driver.

The above scenario plays out for a number of different SDR receivers on the market. In our Cognitive Radio project however, we use the ubiquitous Ettus Research USRP line of SDRs including the network-attached N210 and USB powered B205mini, both of which either require or benefit from the latest UHD driver, which requires a more current version of Boost.

We have also seen a similar pattern of this issue coming from the system deployment perspective. Whether the task is to stand up enough of the system to test functionality or cobble together a live system demo from nothing, both tend to ask the question: which base operating system, and version, does one need to use to be successful? Perhaps as importantly, do we want to impose that requirement on our audience or customer?

For us, we wanted a simple solution to both of these issues. We wanted a solution that imposed a simple requirement: use a relatively recent Linux OS as the host, beginning at the oldest required version: CentOS 6. Our solution was to use Docker.

Docker Container-based REDHAWK

Docker is a Linux-only virtualization system that allows the user to build operating system images that integrate with the host operating system’s own kernel. Each of these images can then be launched as independent runtime instances called containers.

One of the cornerstones of this approach is that each launched container should represent a specific task that once terminated causes the container to exit like any other typical application. This concept dovetails nicely with REDHAWK as well since we can launch a container representing the Domain networked, virtually, to another container representing a Device Manager containing updated drivers, and to another container providing GPP facilities, etc.

In terms of the Cognitive Radio project, Docker opened an avenue for standing up the entire system using whatever operating environment was most conducive to the particular effort. For example, we could wrap the Domain and GPP resources in a CentOS 6 RPM -installed environment and wrap our Device Managers in an environment supporting the latest UHD drivers. Or we could separate the pieces so that some ran on the host operating system while we maintained the latest UHD driver support in containers. Through this development, we released the base operating system and UHD image definitions onto our GitHub repositories, docker-redhawk and docker-usrp, so that the rest of the community benefit.

Besides announcing the capabilities on YouTube, we also attended the Virginia Tech Wireless Symposium in 2016; the image above is from our poster. There we demoed our Cognitive Radio project using these tools for a hybrid operating environment. We leveraged the Docker containers containing the latest UHD driver to interact with the latest networked and USB-attached Ettus receivers along with an embedded model (E310), all connected to a Docker-based configuration of the Cognitive Radio project’s various subsystems and databases including a web server for the user interface. All of the Docker containers ran on an Intel NUC, small form-factor PC.

Conclusion

Publicly, releasing these Docker capabilities has enabled other REDHAWK SDR implementers to solve their own System Designer’s Dilemma in whatever fashion best applies to their system. Internally however, using Docker enabled our being able to integrate our code repositories and system configuration build processes into Docker image definitions which yield a repeatable build, installation, and verification system. The process for standing up our entire Cognitive Radio project for testing and demos, beginning at a base host operating system installation, transitioned from requiring a full day down to a few hours with all functionality pre-configured: REDHAWK itself, initial processing Waveforms, follow-on processing Waveforms, Devices, databases, and the user interface controlling it all. Our own dilemma is no longer about if we can use the latest receivers with the Cognitive Radio project, rather: who wants to see it run?