Situational Awareness: Mapping Interference Sources in Real-Time Using a Smartphone App

In the past years, many techniques have been researched and developed to detect and identify the interference sources of Global Navigation Satellite System (GNSS) signals. In this paper, we utilize a simple and portable application to map interference sources in real-time. The results are promising and show the potential of the crowdsourcing for monitoring and mapping GNSS interference distribution.


Introduction
Radio-frequency interference (RFI), either unconscious or intentional, is one of the most feared events that can disrupt the functionalities of a Global Navigation Satellite System (GNSS) receiver and the user-level applications dependent on it [1,2]. The importance of creating a 'situational awareness' around the receiver, in order to recognize the situation in which an unwanted RFI prevents the correct functioning of the receiver and to react properly without 'domino' effects on the application layer has been widely argued [3,4].
Receivers with fully-capable RFI detection modules have been so far quite complex and, translating complexity into costs and size and power consumption, limited to specific professional or military applications [3,5]. On the other hand, the close advent of a multiplicity of payment/finance applications based on GNSS is today considered a fact [5,6], as well as the need for high positioning accuracy and reliability expressed by automated driving applications [7,8]. Contexts like these foresee a massive deployment of 'consumer-grade' receiver chipsets, in which not only each on-field receiver needs to be aware of the levels of RFI it is surrounded by to properly react in real-time, but it can be an added value for the application service provider to have a real-time map of the RFI over wide areas, for example to possibly take preventive actions.
Several past works have reported the creation of interference source maps in the GNSS bands, through various data collections performed ad-hoc for testing specific detection, mitigation, or localization algorithms [9,10]. However, those data collection campaigns are unfit for the applications mentioned before, because they are meant to offer a representative sample of the average interference scenario in a certain environment in non-real-time, while they are evidently unable to offer a real-time picture of the RFI nearby a certain position.
In our work we leverage the huge computational capabilities offered today by an octa-core commercial smartphone to run on it an instance of a software GNSS receiver, used as a portable and easily deployable "early stage RFI detector"; we named this software receiver 'NGeneApp', as it is the App evolution of our original software receiver for standard PC 'NGene' [11,12]. In this way, equipped • the grabber, which consists of a function that stores the raw GNSS samples coming from the FE to the internal memory of the smartphone, for post-processing analysis; • the whole GNSS signal processing chain, from acquisition to PVT computation, for the real-time processing of the raw GNSS samples coming from the FE; • the interference detection functionality, working in real-time and implemented at two stages, as better detailed in Section 4: Early stage detection, by means of a spectral analysis, called PSD evaluator in Figure 1; Intermediate stage detection, by means of a correlation distortion monitoring technique, as shown in Figure 1; • real-time server communication and data storage for interference distribution monitoring in a crowdsourcing perspective: NGeneApp sends a data message containing the receiver measurements to the server every second. The data are processed and stored in the database for mapping and investigating the distribution of interference in the area in real-time. In case the communication connection is lost, the data message is kept in the local memory of the device and will be resubmitted to the server right after the network is available again.
NGeneApp can be executed in two modes: 1.
Grabbing mode: NGeneApp stores the raw GNSS samples coming from the FE to the internal memory of the smartphone. In this mode, only the grabber module, as depicted in Figure 1, is enabled. 2.
Receiver&RFI detector mode: NGeneApp acts as a complete GNSS receiver and enables its capabilities of RFI detection and transmission of data to a remote server. The user can further specify the data source and its associated processing mode: a.
Real-time: the raw GNSS samples come at high rate (tens of MHz) from a USB-based FE and are processed on the fly; b.
Post-processing: NGeneApp reads the GNSS data from a file. In this case, no real-time requirements have to be satisfied.
Sensors 2018, 18, x FOR PEER REVIEW 5 of 23  real-time server communication and data storage for interference distribution monitoring in a crowdsourcing perspective: NGeneApp sends a data message containing the receiver measurements to the server every second. The data are processed and stored in the database for mapping and investigating the distribution of interference in the area in real-time. In case the communication connection is lost, the data message is kept in the local memory of the device and will be resubmitted to the server right after the network is available again.
NGeneApp can be executed in two modes: 1. Grabbing mode: NGeneApp stores the raw GNSS samples coming from the FE to the internal memory of the smartphone. In this mode, only the grabber module, as depicted in Figure 1, is enabled. 2. Receiver&RFI detector mode: NGeneApp acts as a complete GNSS receiver and enables its capabilities of RFI detection and transmission of data to a remote server. The user can further specify the data source and its associated processing mode: a. Real-time: the raw GNSS samples come at high rate (tens of MHz) from a USB-based FE and are processed on the fly; b. Post-processing: NGeneApp reads the GNSS data from a file. In this case, no real-time requirements have to be satisfied.   [48] and the STEREO FE [49] are configurable, thus the configuration reported in the second and third rows of Table 1 represents just one of the many possibilities. Other FEs are currently under evaluation. For the purpose of a portable and easily deployable RFI detector, an additional aspect that cannot be neglected is the power supply mode required by the FEs. Both SiGE v2 and v3 can be powered by the smartphone USB, so both are suitable to be used for on-field tests. The STEREO FE, on the contrary, needs an external power supply, to be provided via an additional portable charger.    [48] and the STEREO FE [49] are configurable, thus the configuration reported in the second and third rows of Table 1 represents just one of the many possibilities. Other FEs are currently under evaluation. For the purpose of a portable and easily deployable RFI detector, an additional aspect that cannot be neglected is the power supply mode required by the FEs. Both SiGE v2 and v3 can be powered by the smartphone USB, so both are suitable to be used for on-field tests. The STEREO FE, on the contrary, needs an external power supply, to be provided via an additional portable charger.

The Crowdsourcing Approach of the Server
For saving bandwidth and further analysis in case of interference, the information sent to server is classified into two types of message. The first type of message, which is regularly sent to server, contains the following information:

•
The PVT results computed by NGeneApp receiver • The PSD estimation and the total energy of error value • The correlation distribution of the Chi-square GoF test The second type of message will be sent when the interference is detected consist of the following information: The output of the tracking stage (i.e., correlators value, Doppler frequency, code rate) • C/N 0 measurements By using the PVT results and the C/N 0 from the crowd-sourced, the possibility of detecting and localizing the source of the jammer was demonstrated in [17,51]. In those studies, the information (i.e., C/N 0 ) is extracted from the GNSS receiver embedded in smartphone. However, the C/N 0 value may be affected by other factors, such as multipath and partial blockage. Therefore, when the interference is detected, NGeneApp sends also the spectrum and raw data which enable the server to identify the source of jamming in a more accurate and flexible way [9]. An analysis of the advantages and drawbacks of the proposed crowdsourcing approach versus other similar works is reported in Table 2. All available information can be gathered from the GNSS receiver:  The proposed server can also characterize the interference by using the spectrum data. Moreover, the raw data sent simultaneous from multi-source is also valuable for further investigation. With this IF samples database, the interference event can be analyzed and replicated in post-processing investigation. Hence, we can evaluate the effect of interference on the receiver operation and assess the performance of receiver under harsh environment [54,55].

Hardware-Dependent Optimizations
In order to fulfill the real-time requirement, some smartphone-dependent optimizations are required. The interference detection functionality demands a very high computational burden, thus, the multi-thread programming needed a threads re-distribution among all available processor cores, to fully exploit the benefit of the high performance chipset. Figure 2 represents the threads allocation onto the eight cores of the Exynos 7 Octa 7420 system-on-chip. The proposed server can also characterize the interference by using the spectrum data. Moreover, the raw data sent simultaneous from multi-source is also valuable for further investigation. With this IF samples database, the interference event can be analyzed and replicated in post-processing investigation. Hence, we can evaluate the effect of interference on the receiver operation and assess the performance of receiver under harsh environment [54,55].

Hardware-Dependent Optimizations
In order to fulfill the real-time requirement, some smartphone-dependent optimizations are required. The interference detection functionality demands a very high computational burden, thus, the multi-thread programming needed a threads re-distribution among all available processor cores, to fully exploit the benefit of the high performance chipset. Figure 2 represents the threads allocation onto the eight cores of the Exynos 7 Octa 7420 system-on-chip. Being specifically designed for high performance applications, the Cortex-A57 cluster is in charge of handling all the threads with high priority or computational burden. For example, the FE thread, in charge of handling all functions related to the USB FE and stream, is allocated to one core due to the high data rate. The main thread including the PVT computation, the PSD estimation and the 'main' receiver function is mapped to the core no. 7 while a channel thread is assigned to each of the two remaining cores in the cluster. The channel thread includes all the operations needed to track a certain number of satellite signals and to perform the intermediate stage interference detection. Thus, cores no. 4 and 6 can manage up to six channels, i.e., six satellites in tracking. Signal acquisition, which is the heaviest function in terms of computational burden, is continuously performed on one channel on core no. 6, until all the channels are in tracking state. Being optimized for power efficiency, the Cortex-A53 cluster is less powerful compared to the Cortex-A57 also in terms of clock frequency (1.5 GHz vs. 2.1 GHz). Thus, in this case, three cores handle two channels each one. The remaining Being specifically designed for high performance applications, the Cortex-A57 cluster is in charge of handling all the threads with high priority or computational burden. For example, the FE thread, in charge of handling all functions related to the USB FE and stream, is allocated to one core due to the high data rate. The main thread including the PVT computation, the PSD estimation and the 'main' receiver function is mapped to the core no. 7 while a channel thread is assigned to each of the two remaining cores in the cluster. The channel thread includes all the operations needed to track a certain number of satellite signals and to perform the intermediate stage interference detection. Thus, cores no. 4 and 6 can manage up to six channels, i.e., six satellites in tracking. Signal acquisition, which is the heaviest function in terms of computational burden, is continuously performed on one channel on core no. 6, until all the channels are in tracking state. Being optimized for power efficiency, the Cortex-A53 cluster is less powerful compared to the Cortex-A57 also in terms of clock frequency (1.5 GHz vs. 2.1 GHz). Thus, in this case, three cores handle two channels each one. The remaining core executes the communication thread, in charge of handling the remote server link, which requires high priority for the timely delivery of the messages. Taking advantage of this threads allocation, NGeneApp is currently able to handle up to 12 channels in real-time.

In-Field Interference Detection Modules
According to the theoretical background in Section 2, the best way to detect the interference is to monitor its effects along the receiving chain. For this reason, the detection module of NGeneApp includes so far two monitoring points: the first one on the pre-correlation samples, based on PSD evaluations, the second one on the post-correlation samples, based on the Chi-square GoF statistical test [43]. The two techniques are briefly described hereafter.

Power Spectral Density (PSD) Monitoring
A well-known pre-correlation technique consists in monitoring the digitalized samples at the FE output by means of a PSD evaluation. In this case, any interferer with power level exceeding the noise floor can be detected by comparing the PSD of the incoming signal with a pre-set threshold mask. This method can detect the appearance of a disturbance at a very early stage, warning the user in real-time, and this is the approach we use in NGeneApp. Together with a post-correlation technique to assess the actual impairment to the receiver operations, this method has the potential to provide a reliable real-time interference detection tool. This technique works on the raw samples produced by the digital FE, therefore NGeneApp is the suitable tool to access those samples through the USB connection with the FE; the same processing cannot be directly applied to the commercial chipsets, because they do not provide the intermediate frequency signal samples. In the crowd-sourcing perspective, the mobile network can be exploited to send detected interference information to a remote server, for mapping, monitoring and analysis purposes.
The spectral estimation method implemented in NGeneApp is the normalized Welch periodogram, based on the average of a sequence of windowed Fast Fourier Transforms (FFTs) computed over 4096 points. A threshold mask mechanism is currently applied, to detect and roughly classify GNSS interference source, either CW or wideband. A calibration phase has been performed in laboratory in order to properly set the detection masks as a function of the detectable Interference-over-Signal power ratio (I/S). In fact, the threshold was set based on the total energy of error (TE) between the computed PSD and the PSD evaluated in the interference-free environment. The TE was computed as: where N is number of frequency samples per spectrum, C i and R i are the PSD values computed at frequency point i of the current PSD and the reference PSD, respectively.
When no interference is detected (TE under threshold), the computed PSDs are sent to the server with a rate of 1 Hz, while when a disturbance is noticed (TE above threshold), the transmission rate is increased to 5 Hz (selectable).

Chi-Square Goodness of Fit (GOF) Test
The second interference detection technique implemented in NGeneApp is the Chi-square GoF test, which acts a post-correlation monitoring point along the receiver chain [43]. It is based The algorithm is based on the fact that in the nominal case, i.e., when no interference is present, the code correlation for each satellite signal is an even function; each pair of Early (E) and Late (L) correlators equally spaced from the Prompt (P) (the early-prompt spacing and the late-prompt spacing are equal, i.e., d EP = d LP ) can be modeled as a pair of normally distributed random variables with the same mean, i.e., µ E = µ L = µ, and variance that depends on the (C/N 0 ). On the other hand, in the presence of an interfering signal, the E and L point correlation distributions significantly differ, because of the induced code correlation distortion. If the early-late spacing d EP exceeds 1 chip, then it is possible to show that E and L are independent and D = E − L results to be a normally distributed random variable with zero mean, µ D = 0. Then, the test statistic is built on the vector of differences D. Based on these assumptions, the GoF algorithm consists in evaluating the distribution of D, against the expected distribution, i.e., the one calibrated in nominal conditions. The GoF is able to estimate how much the two distributions differ, by means of a statistical metric, the so-called p-value, which is the probability that the two distributions have the same statistical characteristics. When no disturbances affect the signals and the correlation shape is not distorted, the distribution of D is similar to the one calibrated in nominal conditions, and the p-value is close to one. On the contrary, in a critical scenario where interference distorts the correlation, the p-value assumes smaller values. A threshold mechanism is used to decide on the binary hypothesis, set on the basis of the 'significance level' of the test [44]. For a thorough theoretical description of the GoF statistical test, the reader can refer to [43,44]. Hereafter, the in-laboratory calibration phase as a function of the C/N 0 signal ratio in nominal conditions and the on-field test results are presented in Sections 5.2 and 6.3 respectively.

In-Laboratory Tests and Calibrations
The capability of NGeneApp of acting as an interference detector was first assessed with in-laboratory tests, aimed at determining the detection sensitivity of the App to two basic kinds of interference: wideband noise and CW. This test campaign also served to calibrate the spectral detection masks and GoF reference correlations. A picture of the experiment setup is shown in Figure 3. in the presence of an interfering signal, the E and L point correlation distributions significantly differ, because of the induced code correlation distortion. If the early-late spacing exceeds 1 chip, then it is possible to show that E and L are independent and = − results to be a normally distributed random variable with zero mean, = 0. Then, the test statistic is built on the vector of differences . Based on these assumptions, the GoF algorithm consists in evaluating the distribution of , against the expected distribution, i.e., the one calibrated in nominal conditions. The GoF is able to estimate how much the two distributions differ, by means of a statistical metric, the so-called p-value, which is the probability that the two distributions have the same statistical characteristics. When no disturbances affect the signals and the correlation shape is not distorted, the distribution of is similar to the one calibrated in nominal conditions, and the p-value is close to one. On the contrary, in a critical scenario where interference distorts the correlation, the p-value assumes smaller values. A threshold mechanism is used to decide on the binary hypothesis, set on the basis of the 'significance level' of the test [44]. For a thorough theoretical description of the GoF statistical test, the reader can refer to [43,44]. Hereafter, the in-laboratory calibration phase as a function of the C/N0 signal ratio in nominal conditions and the on-field test results are presented in Subsections 5.2 and 6.3 respectively.

In-Laboratory Tests and Calibrations
The capability of NGeneApp of acting as an interference detector was first assessed with inlaboratory tests, aimed at determining the detection sensitivity of the App to two basic kinds of interference: wideband noise and CW. This test campaign also served to calibrate the spectral detection masks and GoF reference correlations. A picture of the experiment setup is shown in Figure 3.

Spectral Detection with Wideband Interference
In the first experiment a wideband jammer, visible in Figure 3, was employed. It features eight RF outputs, covering different frequencies, including the GNSS L1 band. The power of the generated wideband noise, measured over the GNSS FE bandwidth with a spectrum analyzer connected via RF cable, was −60 dBm ( Figure 4).
The jamming source was wired to attenuators in order to control its power with respect to the GNSS signal. Two kinds of attenuator were used: a variable attenuator (0 ÷ 20 dB) with 1 dB resolution and two fix attenuators (10 dB and 20 dB). Once attenuated, the jamming signal was combined with the GNSS signal coming from a rooftop antenna. The mixed signal was then sent to the SiGE v3 FE [48],

Spectral Detection with Wideband Interference
In the first experiment a wideband jammer, visible in Figure 3, was employed. It features eight RF outputs, covering different frequencies, including the GNSS L1 band. The power of the generated wideband noise, measured over the GNSS FE bandwidth with a spectrum analyzer connected via RF cable, was −60 dBm ( Figure 4).  The effect of the jammer has been evaluated both on the PSD of the received signal and on the receiver capability of acquiring, tracking and computing the PVT. Figure 5 summarizes the obtained results in terms of PSD estimation for different level of the interfering power: the green plot represents the obtained PSD when the jammer is on, while the black one is the interference-free PSD. When the jammer power is not attenuated (Figure 5a), the PSD is totally distorted, and the spectral distortion increases dramatically in the whole bandwidth; in this case, the GNSS signal is disrupted and the receiver cannot operate. Till −80 dBm (Figure 5b), the jamming signal has a relevant effect to the receiver performance: when the jammer is turned on, the tracking of some satellite is lost, while some others experience a drop in the C/N0 level. No tracking anomaly happens when the jamming level is lower than −85 dBm, but the application is still able to detect the distortion of the spectrum if the interference power is greater than −95 dBm ( Figure 5c) where a small distortion in the left side of the spectrum is still visible. Only below −105 dBm (Figure 5d), no distortion is detectable. Based on these observations, the detection threshold for the TE metric was set to 50,000 units. These test results are summarized in Table 3.  The jamming source was wired to attenuators in order to control its power with respect to the GNSS signal. Two kinds of attenuator were used: a variable attenuator (0 ÷ 20 dB) with 1 dB resolution and two fix attenuators (10 dB and 20 dB). Once attenuated, the jamming signal was combined with the GNSS signal coming from a rooftop antenna. The mixed signal was then sent to the SiGE v3 FE [48], which outputs a 16.368 MHz digitalized signal modulated at intermediate frequency of 4.092 MHz, as indicated in Table 1. This sample stream is processed in real-time by NGeneApp.
We started the test with maximum jamming power, then we decreased the power with −5 dB step using the attenuators, to determine the minimum in-band interference power level whose effect is non-negligible.
The effect of the jammer has been evaluated both on the PSD of the received signal and on the receiver capability of acquiring, tracking and computing the PVT. Figure 5 summarizes the obtained results in terms of PSD estimation for different level of the interfering power: the green plot represents the obtained PSD when the jammer is on, while the black one is the interference-free PSD. When the jammer power is not attenuated (Figure 5a), the PSD is totally distorted, and the spectral distortion increases dramatically in the whole bandwidth; in this case, the GNSS signal is disrupted and the receiver cannot operate. Till −80 dBm (Figure 5b), the jamming signal has a relevant effect to the receiver performance: when the jammer is turned on, the tracking of some satellite is lost, while some others experience a drop in the C/N 0 level. No tracking anomaly happens when the jamming level is lower than −85 dBm, but the application is still able to detect the distortion of the spectrum if the interference power is greater than −95 dBm (Figure 5c) where a small distortion in the left side of the spectrum is still visible. Only below −105 dBm (Figure 5d), no distortion is detectable. Based on these observations, the detection threshold for the TE metric was set to 50,000 units. These test results are summarized in Table 3. level is lower than −85 dBm, but the application is still able to detect the distortion of the spectrum if the interference power is greater than −95 dBm (Figure 5c) where a small distortion in the left side of the spectrum is still visible. Only below −105 dBm (Figure 5d), no distortion is detectable. Based on these observations, the detection threshold for the TE metric was set to 50,000 units. These test results are summarized in Table 3.

GoF Test: Calibration of the Nominal Distributions
The third in-laboratory test aimed to calibrate the reference distribution function of the Chisquare GoF Test. In a previous work [44,45], the reference distribution function was computed and stored during the calibration phase executed in a portion of "clean" signal; in this way, the detection method was calibrated every time a channel starts tracking. The approach [44,45] shows a drawback in the real-time application because it implies repeating the calibration for each channel and for each time the detector starts monitoring, using a portion of non-interfered signal. Therefore, in NGeneApp the calibration phase was performed in the laboratory and the reference distributions are loaded from static memory every time the receiver is switched on. Since the reference distribution depends on the C/N0 of the tracked signal, the GoF method implemented in NGeneApp employs the same reference distribution for all the tracking channels which run with similar C/N0.
To compute such reference distributions, we simulated a dataset with eight GPS L1 signals at different power levels, using the NAVX-NCS GNSS signal generator [56]. The received power assigned to the list of satellite signals varied from −110 dBm to −131 dBm, with a step of 3 dB between each pair of received signals. Figure 6 shows the estimated C/N0 of each PRN associated to the input power level. From the dataset, the reference distribution function for the Chi-square GoF test of each C/N0 level (i.e., PRN) was computed. Then, each reference distribution was used to execute the GoF test on all the simulated signals, to empirically estimate the false alarm rate, which is expected to be zero because the signals are not spoofed. The test was conducted on about 1400 test samples for each signal. The rationale is that, if the reference distribution for a certain input power level keeps the false

GoF Test: Calibration of the Nominal Distributions
The third in-laboratory test aimed to calibrate the reference distribution function of the Chi-square GoF Test. In a previous work [44,45], the reference distribution function was computed and stored during the calibration phase executed in a portion of "clean" signal; in this way, the detection method was calibrated every time a channel starts tracking. The approach [44,45] shows a drawback in the real-time application because it implies repeating the calibration for each channel and for each time the detector starts monitoring, using a portion of non-interfered signal. Therefore, in NGeneApp the calibration phase was performed in the laboratory and the reference distributions are loaded from static memory every time the receiver is switched on. Since the reference distribution depends on the C/N 0 of the tracked signal, the GoF method implemented in NGeneApp employs the same reference distribution for all the tracking channels which run with similar C/N 0 .
To compute such reference distributions, we simulated a dataset with eight GPS L1 signals at different power levels, using the NAVX-NCS GNSS signal generator [56]. The received power assigned to the list of satellite signals varied from −110 dBm to −131 dBm, with a step of 3 dB between each pair of received signals. Figure 6 shows the estimated C/N 0 of each PRN associated to the input power level. From the dataset, the reference distribution function for the Chi-square GoF test of each C/N 0 level (i.e., PRN) was computed. Then, each reference distribution was used to execute the GoF test on all the simulated signals, to empirically estimate the false alarm rate, which is expected to be zero because the signals are not spoofed. The test was conducted on about 1400 test samples for each signal. The rationale is that, if the reference distribution for a certain input power level keeps the false alarm rate close to zero, then it is suitable for the C/N 0 of the signal under test. The results of such a calibration test are shown in Table 4.    We can see that all the PRNs which have C/N 0 in the same range can use the same reference distribution without significant effect on the algorithm. For example, signals in the range [48][49][50][51][52][53][54][55][56][57][58][59] dBHz (e.g., PRN 1, PRN 5, PRN 6 and PRN 10) could use the reference distribution of PRN 5 with limited false alarm rate. However, from the table, we can also realize that the lower the C/N 0 value, the higher the false alarm rate. It means that signals with lower C/N 0 ratio are more sensitive to the change of reference distribution. For example, the GoF test makes the true decision (i.e., authentic signal) for PRN 22 (which has C/N 0 about 36 dBHz) only when using the exact reference distribution for C/N 0 = 36 dBHz. In the end, the grouping of C/N 0 levels that can share the same reference distribution is summarized in Table 5. The same procedure was performed for Galileo E1 signals, obtaining similar results. Table 5. GoF test method: assignment of the pre-computed GPS L1 C/A reference distribution functions to C/N 0 ranges of tracked signals.

On-Field Measurement Campaigns
A first live test campaign was conducted in order to assess the capability of NGeneApp to catch RF disturbances in real-time and real-life environment. Figure 7a shows the test setup: a smartphone equipped with NGeneApp, a pocket-size FE and a portable patch antenna. We started to map the RF interferences, walking along the streets of the center of Turin, Italy, using this small and lightweight portable equipment. The PSD estimates are displayed on the smartphone and sent to the remote server with a rate of 1 H, increased to 5 Hz when a disturbance is noticed. The GUI and a sample spectrum of received signal are represented in Figure 7b,c, respectively.

On-Field Measurement Campaigns
A first live test campaign was conducted in order to assess the capability of NGeneApp to catch RF disturbances in real-time and real-life environment. Figure 7a shows the test setup: a smartphone equipped with NGeneApp, a pocket-size FE and a portable patch antenna. We started to map the RF interferences, walking along the streets of the center of Turin, Italy, using this small and lightweight portable equipment. The PSD estimates are displayed on the smartphone and sent to the remote server with a rate of 1 H, increased to 5 Hz when a disturbance is noticed. The GUI and a sample spectrum of received signal are represented in Figure 7b and Figure 7c, respectively.

Interferences in an Urban Scenario
Three examples of non-harmful interference detected during real-life urban situations are reported in the following case-studies.

Interferences in an Urban Scenario
Three examples of non-harmful interference detected during real-life urban situations are reported in the following case-studies. The TE in such cases was 12,000 (dB/Hz) 2 , which was under threshold because the interference in this case have very narrow band and it did not affect considerably the TE value.

On-Field Measurement Campaigns
A first live test campaign was conducted in order to assess the capability of NGeneApp to catch RF disturbances in real-time and real-life environment. Figure 7a shows the test setup: a smartphone equipped with NGeneApp, a pocket-size FE and a portable patch antenna. We started to map the RF interferences, walking along the streets of the center of Turin, Italy, using this small and lightweight portable equipment. The PSD estimates are displayed on the smartphone and sent to the remote server with a rate of 1 H, increased to 5 Hz when a disturbance is noticed. The GUI and a sample spectrum of received signal are represented in Figure 7b and Figure 7c, respectively.

Interferences in an Urban Scenario
Three examples of non-harmful interference detected during real-life urban situations are reported in the following case-studies.

Case-Study B: Experiment Performed on the Road along Corso Eusebio Giambone and Corso Cosenza
Another interesting anomaly was recorded on 7 March 2017, at a specific place in Corso Eusebio Giambone. The evident spectrum distortion is illustrated in Figure 9. This event was noticed each time the receiver passes a pharmacy in Corso Eusebio Giambone, 19. The measured TE was 17,056 (dB/Hz) 2 , which is still under the TE threshold.

Case-Study C: Experiment Performed around Porta Susa Area
During the 7 th March test, other disturbances were collected in two places close to the Porta Susa train station. For example, a PSD anomaly has been observed in Via Paolo Borsellino and reported in Figure 10 in two different moments of the day. In this case, the spectrum shows unexpected spikes, however, the anomaly in this place is not persistent.
Apart from the location and address, in all the considered cases it was not possible to locate the interference sources in a more precise way. Anyway, no harmful effect on the receiver operations has been noticed for all the observed disturbances in this scenario.

Case-Study B: Experiment Performed on the Road along Corso Eusebio Giambone and Corso Cosenza
Another interesting anomaly was recorded on 7 March 2017, at a specific place in Corso Eusebio Giambone. The evident spectrum distortion is illustrated in Figure 9. This event was noticed each time the receiver passes a pharmacy in Corso Eusebio Giambone, 19. The measured TE was 17,056 (dB/Hz) 2 , which is still under the TE threshold.

Case-Study B: Experiment Performed on the Road along Corso Eusebio Giambone and Corso Cosenza
Another interesting anomaly was recorded on 7 March 2017, at a specific place in Corso Eusebio Giambone. The evident spectrum distortion is illustrated in Figure 9. This event was noticed each time the receiver passes a pharmacy in Corso Eusebio Giambone, 19. The measured TE was 17,056 (dB/Hz) 2 , which is still under the TE threshold. During the 7 th March test, other disturbances were collected in two places close to the Porta Susa train station. For example, a PSD anomaly has been observed in Via Paolo Borsellino and reported in Figure 10 in two different moments of the day. In this case, the spectrum shows unexpected spikes, however, the anomaly in this place is not persistent.
Apart from the location and address, in all the considered cases it was not possible to locate the interference sources in a more precise way. Anyway, no harmful effect on the receiver operations has been noticed for all the observed disturbances in this scenario.

Case-Study C: Experiment Performed around Porta Susa Area
During the 7 March test, other disturbances were collected in two places close to the Porta Susa train station. For example, a PSD anomaly has been observed in Via Paolo Borsellino and reported in Figure 10 in two different moments of the day. In this case, the spectrum shows unexpected spikes, however, the anomaly in this place is not persistent.  Apart from the location and address, in all the considered cases it was not possible to locate the interference sources in a more precise way. Anyway, no harmful effect on the receiver operations has been noticed for all the observed disturbances in this scenario.

Detection of an Interference from the Space
On 17 May 2017, a CW interference on the L1 spectrum was detected by the researchers of the NavSAS group, analyzing the signal received from the ISMB rooftop antenna. Two spikes appeared at approximately ±0.5 MHz from the L1 carrier frequency. The phenomenon happened during the afternoon (from about 1.00 p.m. UTC to 6.30 p.m. UTC) and repeated along consecutive days. To investigate the source of this interference, NGeneApp was used as portable RFI detector for dynamic observations (by foot and by car) around the ISMB premises as well as in some other areas of the city, far from the Institute. The spectra observed in all visited areas were similar, with the two spikes always appearing at the same frequency. This fact suggested the intuition that the interference was not a local effect, but something farther, probably originated in space.
Furthermore, during the dynamic observations, when the receiver was moving around a building, the interference seemed to disappear each time the western part of the sky was blocked by the building, as illustrated in Figure 11 and better detailed in Figure 12. Considering the visible duration of the GPS satellites and the direction in the sky, the GPS SVN 71 (PRN 26) was first identified as the potential source of the interference. A dataset was then collected with NGeneApp for the post-processing. Figure 13 shows the correlation output of the GPS satellite SVN 71 performed by the NGeneApp. We can recognize that when the PRN 26 loses the tracking (see cursors info in Figure 13), the two spikes in the spectrum disappeared, as shown in Figure 12a,b at about 50 s and 294 s from the receiver start, respectively.

Detection of an Interference from the Space
On 17 May 2017, a CW interference on the L1 spectrum was detected by the researchers of the NavSAS group, analyzing the signal received from the ISMB rooftop antenna. Two spikes appeared at approximately ±0.5 MHz from the L1 carrier frequency. The phenomenon happened during the afternoon (from about 1.00 p.m. UTC to 6.30 p.m. UTC) and repeated along consecutive days. To investigate the source of this interference, NGeneApp was used as portable RFI detector for dynamic observations (by foot and by car) around the ISMB premises as well as in some other areas of the city, far from the Institute. The spectra observed in all visited areas were similar, with the two spikes always appearing at the same frequency. This fact suggested the intuition that the interference was not a local effect, but something farther, probably originated in space. Furthermore, during the dynamic observations, when the receiver was moving around a building, the interference seemed to disappear each time the western part of the sky was blocked by the building, as illustrated in Figure 11 and better detailed in Figure 12. Considering the visible duration of the GPS satellites and the direction in the sky, the GPS SVN 71 (PRN 26) was first identified as the potential source of the interference. A dataset was then collected with NGeneApp for the post-processing. Figure 13 shows the correlation output of the GPS satellite SVN 71 performed However, the appearance of the interference did not perfectly match with the visibility of the SVN 71. This mismatch was then explained by the fact that the interfering signal did not come from the SVN 71, but from the non-operational GPS satellite SVN 49 which had a similar orbit to SVN 71. For more details about the analysis of the anomalous GPS signals reported from SVN 49, the interested reader can refer to [57,58]. by the NGeneApp. We can recognize that when the PRN 26 loses the tracking (see cursors info in Figure 13), the two spikes in the spectrum disappeared, as shown in Figure 12a,b at about 50 s and 294 s from the receiver start, respectively.  However, the appearance of the interference did not perfectly match with the visibility of the SVN 71. This mismatch was then explained by the fact that the interfering signal did not come from the SVN 71, but from the non-operational GPS satellite SVN 49 which had a similar orbit to SVN 71. For more details about the analysis of the anomalous GPS signals reported from SVN 49, the interested reader can refer to [57,58]. by the NGeneApp. We can recognize that when the PRN 26 loses the tracking (see cursors info in Figure 13), the two spikes in the spectrum disappeared, as shown in Figure 12a,b at about 50 s and 294 s from the receiver start, respectively.  However, the appearance of the interference did not perfectly match with the visibility of the SVN 71. This mismatch was then explained by the fact that the interfering signal did not come from the SVN 71, but from the non-operational GPS satellite SVN 49 which had a similar orbit to SVN 71. For more details about the analysis of the anomalous GPS signals reported from SVN 49, the interested reader can refer to [57,58].

Interferences from a Complex System
Another anomaly detected and analyzed thanks to NGeneApp is the interference in a complex integration system. The setup included a GNSS receiver, PCs, a GoPro camera, a Universal Software Radio Peripheral (USRP) and a rubidium clock. A photo taken during one of the performed data collections is shown in Figure 14, where the complex integration setup, including the GoPro camera and the USRP, is visible. During the experimental campaign, the researchers of NavSAS group observed some narrow-band interferences on the raw digital samples collected from the USRP. With the spectrum displaying in NGeneApp in real-time, the source of the interference was easily recognized by turning off each device at a time in the system. Finally, the camera was identified as the source of the narrow-band interference. Figure 15a shows the impact of the interference on the spectrum when the camera was turned on. When the GNSS antenna faced the camera at close range (about 10 cm) the spectrum was considerably distorted. After turning off the camera, the shape of spectrum became normal (Figure 15b). observed some narrow-band interferences on the raw digital samples collected from the USRP. With the spectrum displaying in NGeneApp in real-time, the source of the interference was easily recognized by turning off each device at a time in the system. Finally, the camera was identified as the source of the narrow-band interference. Figure 15a shows the impact of the interference on the spectrum when the camera was turned on. When the GNSS antenna faced the camera at close range (about 10 cm) the spectrum was considerably distorted. After turning off the camera, the shape of spectrum became normal (Figure 15b). the spectrum displaying in NGeneApp in real-time, the source of the interference was easily recognized by turning off each device at a time in the system. Finally, the camera was identified as the source of the narrow-band interference. Figure 15a shows the impact of the interference on the spectrum when the camera was turned on. When the GNSS antenna faced the camera at close range (about 10 cm) the spectrum was considerably distorted. After turning off the camera, the shape of spectrum became normal (Figure 15b). In addition, another anomaly was noticed. In this regard, Figure 16 represents the PSD estimated by NGeneApp in case the USRP was triggered on (blue line) and off (red line). It is evident that although the shape of the spectrum is not distorted, the PSD looks noisier when the USRP is enabled. The effect can be clearly seen in Figure 17a: there is a sudden drop in the C/N0 values of about 10 dB-Hz when the USRP starts recording data at about 95 s from the receiver start. However, the interference detector did not raise any warning. In fact, the test metrics produced by the GoF test were always above the detection threshold (i.e., no interference detection, see Figure 17b) meaning that such kind of anomaly did not produce any relevant distortion neither on the correlation function nor on the spectrum. Furthermore, Figure 17c shows a sudden rise in the energy error of the PSD when the anomaly occurs but this increase is not sufficient to trigger the warning. However, when the disturbance occurred, the receiver was significantly affected, so that some channel lose track, for example, GPS PRN14, GPS PRN 25, GPS PRN 31. A possible explanation of this effect is a powerful uniform wideband noise generated by the USRP, which increases the noise floor of the received signal without distorting it. It is clear that, in order to cope with such kind of anomalies, the detection algorithms have to be complemented with additional monitors. For more details about the integration results of this experimental campaign, the interested reader can refer to [59]. In addition, another anomaly was noticed. In this regard, Figure 16 represents the PSD estimated by NGeneApp in case the USRP was triggered on (blue line) and off (red line). It is evident that although the shape of the spectrum is not distorted, the PSD looks noisier when the USRP is enabled. The effect can be clearly seen in Figure 17a: there is a sudden drop in the C/N 0 values of about 10 dB-Hz when the USRP starts recording data at about 95 s from the receiver start. However, the interference detector did not raise any warning. In fact, the test metrics produced by the GoF test were always above the detection threshold (i.e., no interference detection, see Figure 17b) meaning that such kind of anomaly did not produce any relevant distortion neither on the correlation function nor on the spectrum. Furthermore, Figure 17c shows a sudden rise in the energy error of the PSD when the anomaly occurs but this increase is not sufficient to trigger the warning. However, when the disturbance occurred, the receiver was significantly affected, so that some channel lose track, for example, GPS PRN14, GPS PRN 25, GPS PRN 31. A possible explanation of this effect is a powerful uniform wideband noise generated by the USRP, which increases the noise floor of the received signal without distorting it. It is clear that, in order to cope with such kind of anomalies, the detection algorithms have to be complemented with additional monitors. For more details about the integration results of this experimental campaign, the interested reader can refer to [59]. rest) and (c) the total energy of error measured during the experiment.
In addition, another anomaly was noticed. In this regard, Figure 16 represents the PSD estimated by NGeneApp in case the USRP was triggered on (blue line) and off (red line). It is evident that although the shape of the spectrum is not distorted, the PSD looks noisier when the USRP is enabled. The effect can be clearly seen in Figure 17a: there is a sudden drop in the C/N0 values of about 10 dB-Hz when the USRP starts recording data at about 95 s from the receiver start. However, the interference detector did not raise any warning. In fact, the test metrics produced by the GoF test were always above the detection threshold (i.e., no interference detection, see Figure 17b) meaning that such kind of anomaly did not produce any relevant distortion neither on the correlation function nor on the spectrum. Furthermore, Figure 17c shows a sudden rise in the energy error of the PSD when the anomaly occurs but this increase is not sufficient to trigger the warning. However, when the disturbance occurred, the receiver was significantly affected, so that some channel lose track, for example, GPS PRN14, GPS PRN 25, GPS PRN 31. A possible explanation of this effect is a powerful uniform wideband noise generated by the USRP, which increases the noise floor of the received signal without distorting it. It is clear that, in order to cope with such kind of anomalies, the detection algorithms have to be complemented with additional monitors. For more details about the integration results of this experimental campaign, the interested reader can refer to [59].

Conclusions and Expected Developments
In this paper, a new portable and easily deployable real-time RFI detector named NGeneApp has been presented. Particular emphasis has been dedicated to the development work, i.e., to the porting of a software receiver to an Android-based smartphone. The RFI detection functionality has been implemented by means of a combination of pre-and post-correlation techniques, properly calibrated with lab instruments. Furthermore, its effectiveness in catching RF disturbances in real-

Conclusions and Expected Developments
In this paper, a new portable and easily deployable real-time RFI detector named NGeneApp has been presented. Particular emphasis has been dedicated to the development work, i.e., to the porting of a software receiver to an Android-based smartphone. The RFI detection functionality has been implemented by means of a combination of pre-and post-correlation techniques, properly calibrated with lab instruments. Furthermore, its effectiveness in catching RF disturbances in real-time and real-life environment has been demonstrated with a live test campaign. In this regard, three main usage examples have been presented and in all of the considered situations, NGeneApp was shown to be able to detect interferences successfully. For instance, narrow band disturbing signals and unexpected spikes, likely unintentional, have been noticed walking in an urban scenario. Using NGeneApp for dynamic tests, the source of an interfering signal coming from space has been quickly identified in a non-operational GPS satellite. Finally, NGeneApp has been employed to quickly recognize potential sources of interference in complex integration systems.
According to the achieved results, NGeneApp shows to be a simple and portable tool to check the presence of interference in the environment in real-time. It has been developed with the potential of being an in-field sensor in a de-centralized, unstructured, interference monitoring network. In this network, several sensors spread across wide areas should monitor local GNSS interference, then transmit to a remote server their measurements collected whenever an interference even is detected. Following a crowdsourcing philosophy, a short-delay post-processing implemented at the server side on the data received from sensors would allow drawing a near-real-time map of the interference over a certain area, in order to create conditions of situational awareness. Longer time observations would allow inferring about interference persistence or periodicity and source localization. On the sensor side, the software approach easily enables the potential of enhancing the sensitivity and accuracy of the detection module, for example implementing other detection metrics or refining the detection rules.
The current version of NGeneApp is able to handle up to maximum 12 channels, which satisfies the interference monitoring requirements. The possibility of using other wider-bandwidth front-ends is currently under investigation, in order to improve the capability of classification and identification of the interference sources. The development of the backend server with monitoring capabilities is another future investigation direction.

Conflicts of Interest:
The authors declare no conflict of interest.