An Open Architecture for Signal Monitoring and Recording Based on SDR and Docker Containers: A GNSS Use Case

Signal monitoring and recording station architectures based on software-defined radio (SDR) have been proposed and implemented since several years. However, the large amount of data to be transferred, stored, and managed when high sampling frequency and high quantization depth are required, poses a limit to the performance, mostly because of the data losses during the data transfer between the front-end and the storage unit. To overcome these limitations, thus allowing a reliable, high-fidelity recording of the signals as required by some applications, a novel architecture named SMART (Signal Monitoring, Analysis and Recording Tool) based on the implementation of Docker containers directly on a Network Attached Storage (NAS) unit is presented. Such paradigms allow for a fully open-source system being more affordable and flexible than previous prototypes. The proposed architecture reduces computational complexity, increases efficiency, and provides a compact, cost-effective system that is easy to move and deploy. As a case study, this architecture is implemented to monitor Radio-Frequency Interferences (RFI) on Global Navigation Satellite System (GNSS) L1/E1 and L5/E5 bands. The sample results show the benefits of a stable, long-term capture at a high sampling frequency to characterize the RFIs spectral signature effectively.


I. INTRODUCTION
Monitoring the quality of wireless signals at the Radio Frequency (RF) level is a relevant aspect of ensuring reliable and efficient wireless communications and correct processing of signals to a large extent.RF signals are subject to interference and unexpected degradation, and monitoring them is critical to ensure they remain reliable and consistent.Quality monitoring can be pursued in various ways, including the use of specialized software and hardware tools.These tools can measure the strength and direction of arrival of a signal, the interference levels, and other factors that may affect the performance of wireless communication or may lead to wrong inferred conclusions from signal observations in remote sensing applications.By measuring these factors, it is possible to determine whether a signal is working properly or whether there are interferences that needs to be addressed, for example.For this reason, several kinds of monitoring stations have been proposed, and one of the main threats addressed is indeed the presence of intentional or unintentional interference over the frequency bandwidths of interest such as communication systems [1], Global Navigation Satellite System (GNSS) [2], [3], or others wireless transmission devoted to different aims [4], [5].These stations can implement advanced equipment and techniques to continuously monitor RF signals and identify any anomalies that affect their performance.The most interesting modern approach to the implementation of such monitoring stations is based on the use of Software Defined Radio (SDR) techniques, which allow the recording of signal samples that can be processed in real-time, but also postprocessed to perform deeper analysis and, in some cases, the replay of the scenario [6] [7].In particular, in recent decades, GNSS monitoring stations have become increasingly popular in scientific research [8], [9].Historically, GNSS signal monitoring gathers a set of consolidated techniques that leverage live signal processing through front-ends and dedicated monitoring receivers.Similar architectures can be found in the literature that present multi-frequency software receivers aimed at monitoring ionospheric scintillation [10] [11].
Relying on the SDR approach, Cristodaro et al. [2] present the design of a configurable grabbing station to reproduce altered GNSS signals in the laboratory.The proposed architec- ture, shown in Figure 1a, allowed GNSS signal samples to be stored on external hard drives using Universal Software Radio Peripheral (USRP).In this configuration, the recorded data, in form of binary files (.bin), could be post-processed offline through GNSS fully-software receivers [12].A MATLAB routine, hosted on the host-PC, was used to post-process the collected samples and decide whether to store or discard the data.Despite its effectiveness [13], this methodology does not easily scale with the number of signals (and bandwidths) that can be recorded, and the need for a dedicated host PC and external storage constitutes a non-negligible limitation.Furthermore, MATLAB-based recording and post-processing require concurring instances that may induce an overload of the host-PC, leading to system instability.Based on such architecture, Pica et al. [14] prototyped a novel system architecture for the triggered grabbing of the GNSS signals by an external GNSS Ionospheric Scintillation and Total Electron Content Monitoring (GISTM) receiver, in case of ionospheric scintillation.At the time of writing, the system is operational in Lampedusa (Italy) and has collaterally detected several unexpected RFI phenomena [14].Unlike the previous solution, the data storage is managed through a Network Attached Storage (NAS) but still requires a host PC and is mainly based on MATLAB recording and analysis routines.The architecture is still shown in Figure 1a.
In such systems, however, some aspects limiting the overall performance and monitoring potential are present.Autonomous and reliable data collection with high quantization depth and sampling frequencies is threatened by architectural bottlenecks leading to system instability and sample loss.These weaknesses adversely affect the post-processing of the data and may cause a lack of integrity in the recorded datasets.As also reported in [2], the data transfer bottleneck is a non-negligible issue since high sampling frequencies and quantization depth require significant throughput between the front-end and the storage units.In this chain, the host PC of Figure 1a, despite optimization of the operating system and functions, still remains the main point of failure for which high-speed data transfer is concerned.
In order to overcome these limitations, this paper proposes an open architecture named SMART (Signal Monitoring, Analysis, and Recording Tool) and depicted in Figure 1b.This solution is based on SDR and Docker containers directly implemented on the NAS unit, aiming to overcome the limitations mentioned above.The adopted paradigms allow for a fully open-source environment for the monitoring, analyzing, and recording of RF signals.Last but not least, the compact implementation of the data processing in the NAS makes this architecture more suited for in-field implementation and monitoring operations to be performed in remote regions of the Earth lacking or with very limited power supply and connectivity resources.Such a modernized system architecture is suitable for recent advances in the signal analysis since Docker can also host specialized on-site monitoring algorithms without the need to transfer a large amount of typical SDRgrabbed data to remote processing centers.On-site processing allows for the implementation of smart strategies for data storage or limiting the capacity needed for the transfer of the results instead of the complete datasets.As a use case, the significant interest in the usage of Machine Learning (ML) methods to detect and classify interference in GNSS by processing raw signal samples [15] [16] can benefit from the high-fidelity datasets, reliably provided by the proposed system.In this framework, the proposed architecture can provide intermediate-frequency (IF) high-fidelity, In-phase/Quadrature (IQ) signal samples that can be used as input to ML training algorithms hosted in a docker of the system.

II. ARCHITECTURE DESIGN
In the following, the main components of the proposed solution are presented.Then, the design of the system architecture is described in detail.

A. Main system Components 1) Docker Container:
A container is a compact, encapsulated environment created through containerization, which packages an application, its required dependencies, and the necessary system libraries into a single unit.Docker is an open-source platform that automates the deployment of applications within containers and ensures that the container application operates in any environment [17].Docker is designed to provide a fast and lightweight environment in which programs can run effectively [18].In other words, containerization is a type of Operating-System-level virtualization that creates virtual environments for applications through process and network isolation.Container virtualization differs from traditional virtualization, which typically involves creating an entire Virtual Machine (VM) with its own operating system.As shown in Figure 2, unlike VMs, containers share the host's kernel and do not simulate the whole operating system [19].The main advantage of Docker is density, which implies the container uses the available resources of the host, as opposed to VM, where the machine occupies the dedicated resources, even if it does not use all of them.Docker containers are isolated from each other and the host system, so multiple containers can run on the same host without interfering with each other.Other benefits include speed (time required to create a container), portability, rapid delivery, and an easy way to scale and manage applications [18].
2) Software-Defined Radio: SDR is a wireless communication technology that runs software on a generalpurpose processor to emulate hardware components and enable the development of radio communication functions [20].Consequently, SDRs are more flexible and adaptable to changing the wireless communication architecture by just modifying the software to support new communication services or protocols.SDR technology offers several advantages, such as the rapid evolution of communication standards, performing real-time signal processing, and opening up a wide range of possibilities by simplifying the use of existing radio application types [20].In GNSS, SDR platforms are used to implement receiver functions in general-purpose software and processors and are divided into real-time receivers, educational/research tools, and snapshot GNSS receivers [21].GNU radio is one of the most popular open-source frameworks that provides a software toolkit for building and operating SDR systems.It also provides a software development kit (SDK) for developing SDR flowcharts in C++ or Python programming languages [22].In this study, the SDK of GNU radio is used to develop the system's front-end in Python.
3) Network-Attached Storage: A Network Attached Storage (NAS) device is a standalone data storage system connected to a network and designed for sharing files among multiple users.
It acts as a central data repository, and users can access files stored on the NAS from any device connected to the network [23].The manufacturer typically designs its own Operating System (OS) for NAS units, and it is strongly recommended not to modify its OS or run applications on it.There are a few reasons for this, such as security risks, compatibility issues, and complexity.Instead, they offer tools and services to customize the device, such as a Docker host or virtual machine.Other ranges of features and services include file-sharing protocols (e.g., SMB, NFS, FTP), file synchronization, and backup and recovery options.NAS devices are a convenient and cost-effective alternative to traditional file servers.They offer a flexible and scalable solution for managing and storing data and are designed to provide high reliability, security, and performance for networked data storage needs.The Synology brand is the chosen NAS in this research.Its OS is DiskStation Manager (DSM), which provides a responsive web-based and user-friendly interface for managing and organizing data and various applications and services.

B. System Architecture
Figure 3a depicts a high-level block diagram of the proposed architecture, outlining both the hardware and software components.At the center of the hardware architecture of the proposed system is a NAS device that serves as the core of the system.The NAS is capable of running a Docker container and can host the containers of the required applications and plays the role of host PC.The NAS also stores the collected data, making it the central repository for all raw IF, I/Q signal samples.One of the main advantages of using a NAS as the core of the system is that it eliminates the usual data transfer bottleneck often caused by a host PC and external hard drives.This is because USRP devices can be connected directly to the NAS, bypassing the need for a separate host PC and eliminating the need to transfer data from the USRP device to the host PC and from the host PC to the storage unit.The software architecture of the proposed system is designed to make the collection and processing of radio signals as efficient as possible.To achieve this, a Docker container has been created to host the GNU radio and UHD libraries.These libraries provide support for general-purpose front-ends such as the Universal Software Radio Peripheral (USRP) and make it easier for users to acquire and process signals from multiple sources.In addition, the scripts used for the grabbing routine and data collection process have been coded in Python.This programming language makes configuration more manageable, eliminates the need for any licensed software, helps reduce costs, and makes the system more accessible.These scripts run within the same Docker container as the GNU radio and UHD libraries.Furthermore, a multi-purpose web application is developed in the system using Flask and Ninja libraries.The web application • enables monitoring of system status, including the health and performance of hardware and software components.• provides a dedicated graphical user interface for monitoring output logs, including detailed records of system activities such as data transfers, processing events, and system updates • provides the ability to configure local station settings, such as USRP device installation, sampling frequency, bit depth, and scheduling of recording sessions (i.e., duration and time intervals).A modular hardware solution is depicted in Figure 3b that is conceived for the on-field deployment.

III. EXPERIMENTAL SETUP
The proposed architecture has been implemented as a case study in GNSS L-band, i.e., L1/E1 (1575.42MHz) and L5/E5 (1176 MHZ), for further analysis of the collected data to observe and monitor RFI phenomena.In this experiment, two USRP are utilized as RF front-ends for each band to acquire multi-band GNSS signals simultaneously.Figure 4 shows the hardware installation of the SMART system and its configuration in operation at the NavSAS laboratories.A brief description of each part is described below.
• Antenna : It is a choke ring multi-band antenna that supports multi-constellation GPS, GLONASS, and Galileo.(AeroAntenna AT 1675-382).• Low Noise Amplifier (LNA): This is a line amplifier 20dB with a DC filter from GPS Networking that am-

IV. RESULT
Hereafter, a sample application is exploited to show the benefits of the proposed architecture in terms of system performance.Furthermore, the advantages of recording signals at high frequency and direct transfer to the NAS storage unit without loss of samples are highlighted.

A. System resources usage
Figure 5 presents the resource usage (CPU and memory) of the SMART system during the process of grabbing the GNSS signals at different sampling frequencies.The sampling frequency on the x-axis refers to the sum of the sampling frequency for both USRPs (L1/E1 and L5/E5).Figure 5 Fig. 5: Resource usage of SMART system provides insight into how the usage of CPU increases with increasing sampling frequency and how memory utilization does not change during signal grabbing.Points A (30.5 MHz) and B (43 MHz) in Figure 5 refer to the critical sampling frequency of the implemented system in the case of 32-bit and 16-bit quantization, respectively.When the sampling frequency exceeds these points, the system starts to lose sampling.Nonetheless, the result shows long-term reliability in grabbing GNSS signals without sampling loss at a high quantization depth and sampling frequency below the critical points.It is quite evident that the system can achieve a higher sampling frequency if the resources of the NAS device are upgraded.It is interesting to note that in the idle state (no grabbing) with ten active users, the station occupies 4 % of CPU and 9 % of RAM resources.

B. RFI characterization in GNSS L-Band
In this experiment, an interference scenario is designed to show the advantages of grabbing GNSS signals with high sampling frequency.In this scenario, the GNSS signal is interfered with by a linear chirp signal (known as the most disruptive jammer in the GNSS band [24]).Figure 6 shows the implementation of this scenario, where the interfering signal from the multi-band jammer is attenuated and mixed with the GNSS signal.

Fig. 1 :
Fig. 1: Evolution of multi-band monitoring and recording stations applied to GNSS signals.State-of-the-art architecture (a) and proposed open architecture (b).

Fig. 3 :
Fig. 3: High-level hardware and software block diagram (a), and SMART modular concept for the on-field deployment of the proposed solutions (b).

Fig. 4 :
Fig. 4: Prototype of an operational GNSS Monitoring and Grabbing Station at the NavSAS laboratories.