Open Source 5G on a Drone

This past summer Geon explored a new, embedded development workflow creating applications for a drone platform. We selected the platform because it was the most cost effective way to get access to a Qualcomm® QRB5165 SoC for IoT (often just called the ‘RB5’) which we had interest in gaining familiarity with. The high performance and highly integrated nature of the RB5 coupled with a GPU and 5G modem makes it perfect for low SWAP field applications for AI/ML, 5G, Wireless, and general SDR appliations. Since purchasing the drone we have chosen to develop on and deploy code to it by cross compiling docker containers using buildx tool provided by Docker®. We found that the containerized cross-compilation workflow was a good fit for our preferred practice of developing, debugging, and benchmarking first on standard Intel-based platforms and then integrating with the low-SWAP platform for field testing and deployment.

Since we have been primarily working on 5G applications, our first task required cross-compiling the Open Air Interfaces (OAI) codebase for aarch64. We quickly ran into trouble when trying to cross-compile the OAI source code due to its heavy reliance on Intel intrinsics throughout the codebase. After doing some research, we selected the SIMDe project to integrate with OAI and were quickly able to produce a working ARM cross-build of the Docker® images that are supplied with OAI.

Results

The next step was to preform verification of the executables within the resulting Docker® images on the RB5 drone. First, a quick spot check of the executables ability to load into memory and execute the help screen was preformed with success. Next, we launched a docker compose file that connects a UE (a handset) and gNodeB (gNB) container, a basestation, in OAI’s rfsim mode. This verification step runs OAI’s codebase in a non-real-time mode where it transmits preD (pre-demodulated) data across TCP ports between processes on a single or multiple hosts. A successful execution of the containers in rfsim mode on the drone is shown below:

The next step was to attempt to run the UE container on the drone in a real-time configuration by using a USB connected Ettus B210 SDR. We selected the UE container first because the processing required for the UE executable is less then what is required for the gNB executable. Once the SDR was hooked up properly and the UE was launched the following error output occurred:

We began debugging to determine why the platform was struggling to process enough samples to perform the operations required by the UE. There were a few portions of the platform where we directed our attention: the speed and amount of RAM on the platform, the speed and number of CPU cores, and the I/O demands of the preD data from/to the SDR across the USB bus. We compared these parameters on the drone platform against the Intel® based platforms we had be using successfully with OAI to help us determine the location of the processing bottle-neck. The parameters of each platform are as follows:

An experiment was preformed on the drone where the UE application was launched and the output of ‘top’ was watched and there wasn’t any indication that the any CPU, RAM, or other resource was being completely used up during execution. We then turned our attention to the I/O performance of the drone platform relative to OAI’s I/O requirements for the SDR. We used the Ettus USRP benchmarking application that is provided as part of the UHD installation to evaluate the drone’s USB performance. The sample rate that OAI uses on a 40Mhz 5G channel is 46.08 MS/s Tx and Rx, this configuration was used with the benchmarking application and the platform failed to keep up with that data rate. We ran some more additional tests and determined that the highest sampling rate supported without data loss was 15 MS/s Tx and Rx. This is not high enough for OAI’s processing architecture so we are looking for other ways to integrate an SDR with the RB5 to get better I/O performance.

This experiment taught us a great deal about the RB5 drone platform itself. Geon also gained familiarity with using Docker on ARM and porting software dependent on Intel intrisics to an ARM platform that is likely to prove a valuable skillset in future work. While there were challenges with this particular processing platform we still think there is value in releasing the updated OAI code to the community for anybody who is interested this code can be found here

Further Development

The next step in our research is to decompose the new aarch64 OAI code into portions of the UE and gNB codebase that require leaner processing and bandwidth requirements. Thew first logical step in this line of research is to take the the UE codebase and extract the SSB decoding algorithm for use in a possible surveying application. The SSB signal is not of particularly high bandwidth compared to the full 40Mhz channel. Another avenue of research could be to take the heavy weight portions of the digital signal processing chain within the OAI codebase and port that code to the on board GPU in order to accelerate processing times. The I/O problem still needs to be solved so stay tuned for updates. Please contact us if you would like to discuss Geon’s 5G research.