Investigating Latency in gnu software Radio with usrp embedded Series sdr platform

A.
Universal Software Radio Peripherals (USRPs) 
The USRP product family is a hardware platform from 
Ettus Research with the purpose of creating an inexpensive and 
flexible hardware platform for software radio. USRPs are
widely used in research labs, universities, and commercial 
companies. USRPs consist of analog digital conversions 
(ADCs), digital analog conversions (DAC), RF antenna and a 
FPGA which can be programmed to implement some signal 
processing functions as well as digital down converter (DDC). 
USRPs also contain a bus controller for transferring samples 
from/to a host computer (USB 2.0 in USRP1, Gigabit Ethernet 
in USRP2, USRP N series) or from/to an embedded system 
(GPMC bus in USRP E series).
Along with USRPs are daughter-boards for sending and 
capturing radio signals with the ability of tuning to different 
frequency bands. Daughter-boards also need to down convert 
radio signals to an Intermediate Frequency (IF) that the ADC 
can handle [14]. There are several types of daughterboard 
covering different frequency bands such as RFX2400 for the 
frequency band from 2.25 GHz to 2.9 GHz, RFX1200 for the 
band from 1.15 GHz to 1.45 GHz and WBX which is capable 
of tuning from 50 MHz to 2200 MHz [15]. 
B.
GNU Radio software 
GNU Radio is a free, open-source toolkit contained 
libraries to conduct DSP functions and utilities by leveraging 
RF front-end devices like USRPs to implement the real world 
radio system. GNU Radio also works alone without real RF 
devices as a simulation environment [2]. 
The core of the GNU Software Radio is DSP blocks that 
conduct signal processing functions such as modulations, 
demodulations, filters, mixers, operators, i.e. These DSP blocks 
are implemented in C++ language which supports low level 
programming for higher performance. However, GNU 
Software Radio applications are commonly written in Python 
and use a generator named Simplified Wrapper and Interface 
Generator (SWIG) for interfacing with these DSP blocks [2]. 
Besides, GNU Software Radio supports several tools and 
utilities. For instance, the application 
fft
analyzes Fast Fourier 
Transform spectrum at a specific frequency, and the application 
siggen
creates several common radio signals. 
C. Universal Hardware Driver (UHD) 
UHD is a hardware driver library for all USRP devices and 
all types of daughter-board. It is able to use UHD driver 
standalone or with 3rd party applications such as GNU Radio,
Labview, and Simulink [16]. Before UHD is introduced, GNU 
Software Radio used 
Libusrp, Libusrp-GNU Radio
,
Python 
daughterboard code
,
C++ daughterboard code 
for USRP1,
USRP2 or USRP N series. Instead, UHD provides a unique 
Application Program Interface (API) for the radio software to 
work with any kinds of USRP and daughter-boards. As an API, 
UDH is considered as a bridge between user-space radio 
software and OS kernel.
D. Related Work 
Valentin et.al measured the latency on GNU Radio/USRP1 
testbed but they neglected the delay introduced in USB bus and 
in USRP device. They used two cross-connected USRPs to 
measure the RTT at the Data Link Control (DLC) layer with 
the assumption that RTT = 2x(Rx latency + Tx latency). The 
total latency of the SDR system is about 1.4ms [9]. Other 
researchers pointed out that besides Tx and Rx latency, USB 
bus transmission contributes a big amount of the latency [8]. 
Schmid et al. investigated the performance impact when 
latency increases in the USRP1/GNU Radio SDR platform [8].
They measured the latency by using an external generator to 
generate square-wave signals. One output is directly connected 
to an oscilloscope. Another output is connected to a USRP1/ 
GNU Radio system that detects the edges of the square wave 
then toggling a pin on a parallel port in the host computer. This 
parallel port is also connected to another input of the 
oscilloscope. The difference between two channels of the 
oscilloscope is the SDR platform latency. The results showed
that Rx latency and Tx latency are from 1ms up to 30ms and 
from 28.9ms to 36.9ms, respectively. They also theoretically 
analyzed the latencies introduced in GNU Software Radio and 
USRP by considering the role of USB buffer and USRP buffer. 
Nychis et al. proposed a method to estimate the latency 
introduced in GNU Radio/USRP1 system by putting timestamp 
at various places in the Tx/Rx processes. They designed a low-
level ping command on their designated channel to measure the 
RTT from the software radio to FPGA in USRP. The results 
showed that the total latency of the SDR system is dominated 
by the Kernel-FPGA RTT and the time spent in the GNU 
Radio chain (291us and 270us, respectively). The switching 
time between user-space and kernel is relatively modest at 27us 
average, but the standard deviation is very high, since the 
maximum latency reaches to 7000us [10]. Nychis et al. had a
different perspective of the latency from the point of system 
view. 
Puschmann et al. also measured throughput, latency and 
jitter by using a designated ping command to measure the RTT 
between two SDR platforms [19]. The testbed was based on
Iris framework and made used of TUN/TAP components, 
ping
and 
iperf
Linux utilities as well as Send-And-Wait ARQ 
protocol in Iris [20]. Note that they used Iris framework instead 
of GNU Radio for working with USRP2. The results showed
that the RTT of the SDR platform ranges from 38.1ms to 
53.7ms (Acknowledgement mode, ping) and from 24.4ms to 
40.4ms (Acknowledgement mode, ARQ layer2). 
Because of big latency, high jitter, and poor performance, 
some researchers proposed other SDR platforms such as SODA 
[11], SORA [7], and CalRadio [12]. SODA is a SDR platform 
based on an asymmetric processor, consisting of a scalar and 
Single Instruction, Multiple Data (SIMD) pipeline. SODA 
10
10

---

architecture uses four cores; each of them contains asymmetric 
dual pipelines that support scalar and 32-wide SIMD execution 
by using efficient parallel DSP algorithms. SODA uses Arm 
Cortex M3 control processor and an embedded DSP processor 
that can meet high performance requirements of current 
wireless protocols with low power consumption [11]. CalRadio 
was designed for developing and doing research on the IEEE 
802.11 wireless protocols by simplifying 802.11 Multiple 
Access Control (MAC) protocols [12]. Calradio implements 
MAC functionalities on a specific chip (GPP with DSP) 
running on a simplifier Linux for embedded systems called 
uCLinux. This uCLinux is integrated with a designated MAC 
layer provided some new features such as faster 
implementation time, MAC formats, erroneous Packet 
Processing, new inter-frame space timings and fast channel and 
network switching [12]. 
III.
A
NALYTICAL 
L
ATENCY 
M
EASUREMENT ON
GNU
R
ADIO
/USRP E100 P
LATFORMS
We characterize the reasons that cause the latency on GNU 
Radio/USRP E100 platforms then estimate them. 
A.
Latency Sources on GNU Radio/USRP E100 Platforms 
The latency on a GNU Radio/USRP E100 system could be 
divided into three parts: the latency at GNU Radio and OS
(denoted as 
∆
software), the latency due to GPMC bus transfer 
(denoted as 
∆
bus); and the latency in USRP device (denoted as 
∆
hardware).
The first component 
∆
software is because of many factors 
such as the processing time of DSP functions; buffering 
scheme at GNU Radio; and data transferring between GNU
Radio (user-space) and bus driver (kernel-space). The second 
component 
∆
bus is introduced by buffering scheme at the bus 
driver as well as the transmission time through GMPC bus. The 
third component 
∆
hardware is due to buffering schemes at 
USRP buffer and FPGA buffer; samples generating time and 
FPGA processing time. 
B.
Software Latency Analysis (
∆
software) 
Depending on the complexity of signal processing tasks 
such as producing, filtering, encoding, and modulating (Tx); 
demodulating data, decoding (Rx); as well as the power of 
GPPs, the processing time of the GNU software radio may take 
a significant amount of time. The user-space/kerner-space 
interaction in the OS is also unpredictable depending on