Due to the proliferation of personal privacy devices and other jamming sources, it is imperative for safety-critical GNSS users such as airports and marine ports to be situationally aware of local GNSS interference. This article proposes and validates an enhanced method for geolocating GNSS interference sources so that jammers and spoofers can be found and disabled.

Wideband jammers or interference, intentional or not, are most effective at jamming nearby GNSS users as it is frequency agnostic and causes sustained loss of GNSS signal by nearby GNSS users (see Borio et alia, Additional Resources, posted in the online version of this article). Examples of intentional wideband jammers uses modulation schemes such as FM chirp (sometimes also known as swept Continuous Wave) and Additive White Gaussian Noise (AWGN). In comparison, narrowband jammers such as Continuous Wave (CW) are relatively frequency selective and can cause intermittent GNSS operation. Hence, it is imperative to have the ability to identify the presence of a wideband GNSS jammer and geolocate it as they pose a greater danger to GNSS users.

It is well known that phased arrays can be used passively to determine the AOA of a Radiofrequency (RF) emitting signal source. Typical passive GNSS interference sensing uses a network of phased arrays to infer two or more Angles of Arrival (AOA). Conventional AOA estimation using phased arrays assumes narrowband signals that satisfy the time bandwidth product:

where

is defined as the maximum distance (in meters) between station pairs and B is defined as the signal bandwidth is Hertz. To accommodate wideband signals, most AOA algorithms (see multiple papers, Additional Resources) partition the signal into multiple narrowband channels for AOA processing. Thus, such methods are attempting to geolocate wideband sources despite the source being wideband. Examples of algorithms that are able to deduce the AOA from phased arrays are MUSIC (Schmidt) and MVDR (Rieken and Fuhrmann).

The AOA measurements from two or more stations can then be used to triangulate the location of the interference source. By deploying multiple stations of phased arrays that are geographically dispersed, AOA estimates retrieved from each station can be used to accurately geolocate a source using techniques such as least-squares that are based on the intersection of AOA lines of position (Dempster).

To exploit fully the wideband characteristics of the source signal, a cross-correlation method needs to be employed. The cross correlation of received signals between two distant stations will produce a distinct peak at a cross-correlation delay with the Time Difference of Arrival (TDOA) of the corresponding source. Hence, TDOA is another sensor station’s observation that relates to the geographical location of the wideband source signal. If there are three or more stations, the combination of two or more detected TDOA measurements can be used to geo-localize the jammer position.

Recently, new methods consider a modified Maximum Likelihood (ML) approach for AOA geo-localization dubbed direct positioning (see both Cheong and Dempster, and Tzafri and Weiss). Indeed, cross-correlation and AOA characteristics can also be simultaneously exploited for geolocation in direct positioning. However, this occurs at the expense of orders of magnitude greater in computational cost and is beyond our scope.

Until recently, source geo-localization algorithms have only considered either AOA measurements or TDOA measurements as independent systems of equations for geo-localization. By and large, conventional algorithms have not appropriately considered the fusion of heteroskedastic (i.e. unequal variances) AOA and TDOA measurements and have not fairly characterised their advantages against pre-existing methods.

Modern techniques have attempted to integrate AOA with TDOA using computationally expensive constrained optimization techniques (Bishop et alia). Another method attempts to integrate AOA with TDOA by assuming at least one Time of Arrival (TOA) is available (Li and Weihua). While this may be afforded by CDMA cellular networks that are active systems, passive sensing systems like those considered here are unable to obtain TOA. Some papers considered unweighted algorithms, not considering that AOA and TDOA measurement standard deviations vary from station to station, which is highly unrealistic (see again Li and Weihua). The most recent progress has been made by Yin et alia where AOA and TDOA are combined for geo-localization in closed form but that method is unable to cope with incomplete information; hence one missing AOA measurement from station i, for example, will result in the complete loss of all TDOA measurements involving station i. This lack of robustness ultimately affects the geo-localization accuracy.

Closely based on Cheong et alia, Additional Resources, this paper presents empirical results for combining AOA and TDOA measurement to consistently obtain superior geolocation accuracy. We will also show that the empirical results fit its theoretical error models.

AOA Geolocalization

We consider a vector of AOA measurements from L stations

modelled as a Gaussian distribution

as described by Yu, Additional Resources. Here, the true AOA is denoted as

and the AOA measurement is denoted as

which has a normal distribution with variance
.l specifies the station index. Its error covariance matrix

where the off-diagonal elements are zero and the diagonal elements

corresponds to the l-th station’s AOA error variance in units of rad2. It is important to convert all angle measurements and covariances into units of rad for all AOA related processing. In this paper, the origin of AOA corresponds to the East direction and increasing AOA is in the anti-clockwise direction.

To accommodate the heteroskedastic nature of AOA measurements, a Gauss-Newton approach to geolocate the source can be taken. The first step for deriving a Gauss-Newton solution is to identify the Jacobian matrix Ja which is the gradient to the linear approximation to the geolocation process at every new iteration. Detailed relationships of the AOA measurements with respect to the jammer’s coordinates (Xu, Yu) can be found in the paper by Dempster. This procedure is then iterated until convergence as summarised in Pseudocode 1. Starting from a source coordinate initialized using a conventional technique, Pseudocode 1 iteratively evaluates the linearized approximation using the Gauss-Newton approach and updates the Jacobian Ja to yield the final jammer coordinates

Notice that in the absence of any AOA measurement

does not affect the overall operation of pseudocode 1. The only prerequisite of pseudocode 1 to achieve convergence is that Ja cannot be rank deficient (i.e. need to have full rank). This can be ensured by geographically spacing out the stations from each other as best as possible throughout the surveillance area. Based on the Cramer Rao Lower Bound (CRLB), the error covariance of the AOA-only geo-localisation estimate

is expressed as

as reported in the work of Xu and Doʇançay.

TDOA Geolocalization

Let us define the source’s TDOA of station i from station j as τij. Then if we construct the observed TDOA from all stations with reference to station j=1 as

the TDOA observation model used is a multivariate Gaussian distribution. [6].

The mean and the covariance component of the multivariate Gaussian distribution can be further defined as:

Note that

is the true TDOA of the i-th station from station 1, and

is the variance related to the signal arriving at the i-th station.

Given that we are considering a wideband GNSS jammer, we can use cross-correlation signal processing techniques to measure the TDOA arriving between several stations. The TDOA measurement is related to the source coordinates (Xu, Yu) by

Note that ||.|| is the Euclidean distance of the vector. From its partial derivatives, we can construct the Jacobian matrix for the TDOA measurement vector as Jt as described in the paper by Kaune et alia. A Gauss Newton algorithm can be derived using its gradient Jt for a TDOA-only source geo-localisation algorithm. The implementation of this iterative process can be summarised in Pseudocode 2.

Pseudocode 2 considers TDOAs from a star network topology. If a fully connected network is considered, the algorithm can still cater for all the TDOAs, but its effect on accuracy is negligible. However, in the case where there are certain missing TDOA measurements, this algorithm can still easily adapt to that. Based on the reasoning for the case of AOA-only geo-localisation, the accompanying error covariance of the position solution based on the CRLB is.

Proposed AOA/TDOA Integrated Geolocalization

This section presents the core contribution of this paper, that is to be able to geolocate by fusing both AOA and TDOA measurements. Given the AOA-only and TDOA-only geolocalization estimates (i.e. and ) which can be computed from Pseudocode 1 and Pseudocode 2 and their respective errors covariances Σt and Σa, their solutions can be found by using the Weighted Least Squares (WLS) as follows,

Where the integrated error covariance matrix and the transformation matrices are respectively,

The appropriately weighted AOA/TDOA loose integration requires perfect knowledge of the AOA-based and TDOA-based position error covariance matrices. The calculation of AOA-only and TDOA-only covariance matrices ΣuT and ΣuA in turn requires sufficiently accurate coordinates of the source and station. While the station coordinates are known, the source coordinates are generally unknown. In practice, this solution is implemented as an iterative process because the best guess of the source coordinates is at the end of each iteration. Thus, in such an iterative procedure, a guesstimate position from either the AOA or TDOA estimation process can be used in the first iteration to initialize both the TDOA and AOA position covariance matrices. After the AOA/TDOA integration has been performed, subsequent iteration uses the updated position estimates to re-calculate Σu,T and Σu,A. This is repeated until convergence. Indeed, we have experimentally verified that in some, but not all cases when (Xa, Ya) or (Xt, Yt) is sufficiently accurate, the number of iterations for AOA/TDOA integration K can be as small as one. The maximum number of iterations is considered sufficient when the Euclidean difference between the coordinate estimates

of iteration K and K-1 is within a desired tolerance. This convergence principle applies also to Pseudocode 1 and 2. This iterative process is detailed in Pseudocode 3.

While this proposed architecture of integration can be thought of as “loose”, it has the advantage of accommodating existing TDOA-only and/or AOA-only geo-localization implementations that are already in place. It also has very low computational cost and low complexity as it does not require complicated forms of numerical optimization techniques, nor does it require evaluation of non-linear functions, as tighter integration methods do.

To obtain the CRLB for the integrated solution, we first need to derive the Fisher Information Matrix (FIM) as

The CRLB for the joint AOA/TDOA geolocation is defined as the inverse of the FIM:

Numerical Results

For this section, we intend to visualize the geometry-dependant accuracy of AOA-only, TDOA-only and our proposed AOA/TDOA integrated solution over a realistic configuration of station baselines. We consider three stations in an ENU coordinate frame: (0, 0), (-2, -740) and (-383, -2). These coordinates correspond to the field trial configuration in the next section. In Figure 2, the superimposed geographical lines corresponding to a range of constant TDOA (iso-TDOA lines) spaced at 200 meters for a scenario with three stations is shown. An iso-TDOA line indicates the direction with zero gradient, hence the tangent to the iso-TDOA line is the direction with the greatest descent or greatest ascent.

For a fair comparison, it is important to assume appropriate measurement standard deviations that are realistic for both the AOA and TDOA systems in a convex region formed by three stations. The convex region corresponds to red grid points in Figure 3. For this section, we used AOA standard deviation of 0.3° and a time of arrival standard deviation of 1 meter as they are the worst case observed in our field test. For the following results, the effect of coverage is considered. Thus, the source location needs to be within 2 kilometers of a station for its AOA to be measurable and at least two AOA measurements are needed for AOA-only geo-localization, whereas TDOA can only be measured when the source location is in coverage of two stations and three stations are needed for TDOA-only geolocalization.

Figure 3 is produced by sorting the source’s position indices according to the CRLB of joint AOA/TDOA geo-localization and superimposing its corresponding AOA-only CRLB and TDOA-only CRLB. The superiority of joint AOA/TDOA estimation is obvious. The CRLB of either AOA-only or TDOA-only geolocalization within the convex region is within 2.0±0.5m and 5.0±3.0m, respectively as seen in Figure 3. In the same convex region, the CRLB of the joint AOA/TDOA geolocalization maintained within 1.0±0.3m. Hence, the AOA/TDOA geolocalization yields two major benefits. First, the CRLB at any point within the convex region will experience an overall reduction, in this case, a median of at least 50% improvement. Secondly, the stability of the positioning error within this region will have far smaller fluctuation; up to tenfold improvement in stability in this example.

The horizontal CRLB of all three methods are shown in a colormap in Figure 4. Commensurate with Figure 3, these figures show clear improvements delivered by the joint AOA/TDOA geolocalization.

The improvement, i.e. CRLB reduction, experienced when switching from an AOA-only geolocalization to a joint AOA/TDOA geolocalization is shown in Figure 5. The percentage improvement peaks near the edges of the convex region where the AOA measured from a pair of stations have a difference of {0,π} radians. The joint AOA/TDOA geolocalization performs significantly better than AOA especially at these boundary points due the increased diversity in geometry when both AOA and TDOA measurements are considered for geolocation. From the TDOA-only geolocalization perspective, the joint AOA/TDOA geolocalization similarly yields an average of approximately 35% CRLB reduction within the convex region. This can be seen from Figure 5.

Field Test Result

We verify our proposed method against data collected from a specialised open area calibrated test range. The range is a remote site in southern Australia that permits actively monitored and controlled transmissions of weak signal GNSS jamming & spoofing for experimental purposes. The 1 km2 range consists of three passive sensor arrays (each with a circular concentric array of eight element antennas, see Figure 7) as stations. As the sensor arrays operate in the GNSS band, it uses beam-steering to exploit the GNSS signal for calibration without being affected by the interference. This configuration is visualised in Figure 6. The positional inference from AOA measurements are not visualized here.

TThe stations are spread across three corners of the almost rectangular test range with local East-North coordinates (0.0, 0.0), (-1.9, -739.8) and (-383.1, -2.3). The station’s hardware was used to detect the occurrence of jammers and the computation of its AOA and TDOA measurements. It performs MUSIC processing of AOA measurements; whilst the TDOA measurements were computed via cross-correlation of baseband signals.

In this field test in early 2017, we deployed two wideband jammers as stationary sources at GNSS-surveyed coordinates (-114.0, -199.8) and (-375, -304.5) for source 1 and source 2, respectively. The antenna is mounted on the two vehicles as depicted at the right of Figure 8. The GNSS antenna used for ground truth is shielded from the source’s antenna and is positioned at the null of the jammer antenna’s radiation pattern. Its RF cable is also guided away from source’s antenna before entering the equipment in the vehicle. The source transmitter is a BladeRF x40 (with a bandwidth of 20MHz) controlled by an Intel NUC small form factor PC running Linux.

Using the setup in Figures 7, 8 and 9, we collected 261 epochs valid of AOA and TDOA measurements from all three stations. These are logged from the GRIFFIN hardware which performs MUSIC processing for AOA estimation and cross-correlation processing for TDOA estimation in real-time.

We estimate the TDOA and AOA statistics from the dataset itself. The standard deviation of AOA for source 1 at stations 1, 2 and 3 are 0.05°, 0.12° and 0.30°, respectively. For source 2, those are 0.10°, 0.13° and 0.16°, respectively. The TDOA standard deviations for source 1 are 0.875m and 0.860m for the measurements between station 1-2 and station 1-3, respectively. For source 2, the TDOA standard deviations are 0.845 meters and 0.988 meters for the respective station pairs. An example for the gaussian fit on these measurements are shown in Figure 10.

The computed coordinates of the AOA-only geolocalization, TDOA-only geolocalization and the proposed AOA/TDOA geolocalization is shown in Figure 11. The scatter plot for both sources show good agreement between the CRLB 3σ error ellipses and the empirical scatter points. Furthermore, the empirical scatter points for the proposed AOA/TDOA algorithm exhibited an equal degree of improvement as predicted by its theoretical CRLB error ellipse. More importantly, the geometry of the AOA (red) error ellipse and the TDOA (black) error ellipse is shown to complement each other to produce an improved accuracy for the joint AOA/TDOA (blue) error ellipse.

The theoretical and empirical error statistics for the East and North component are shown in Table 1 and Table 2 for source 1 and source 2. The AOA and AOA/TDOA error statistics are highly commensurate with bounds dictated by the theoretical CRLB.

The minor discrepancy between the empirically measured 3σ error and the theoretical 3σ CRLB can be attributed to minor differences between the modelled distribution of AOA and TDOA error and the actual AOA and TDOA error distribution (see Figure 10). Specifically, the empirical TDOA error statistics are unable to be correctly captured by a simple Gaussian model due to minor unmitigated timing variation and localised multipath effects.

From Table 1, we can compute the empirical Euclidean 3σ error for source 1 as 3.82 meters, 2.42 meters and 1.39 meters for AOA-only, TDOA-only and AOA/TDOA joint geolocalization. The corresponding errors for source 2 shown in Table 2 are 3.44 meters, 4.01 meters and 2.22 meters. RMSE reduction is empirically shown for the proposed AOA/TDOA method for source 1 to be at 63.6% from an AOA-only geolocalization and at 42.5% from a TDOA-only geolocalization. For source 2 the RMSE reduction is empirically shown to be ranging from 35.4% to 44.6%. These improvements are also commensurate with theoretical expectations as dictated by the CRLB.

While some of the features of the AOA/TDOA integration methods may enhance the positioning performance only in decimeters, they can be in the order of tens or hundreds of meters as the AOA and TDOA measurements increase in error variance due to weaker transmit signal strength or greater geographical inter-station separation.

Application

While the scale of the RMSE enhancements are small in our field trials, such improvements should not be underappreciated. To illustrate how our proposed method affect large scale deployment, we adopt the Kingsford Smith airport in Sydney, Australia as the scenario. The simulated stations are situated at (-1744, 2555), (1318, 1180) and (-32, -2262). As we only seek to understand the effects of geometrical variation, we base our TDOA and AOA measurements covariances to our field trial data to compute the horizontal CRLB in this simulated scenario. The results are shown in Figure 12. Notice the significantly enlarged contours of equi-RMSE for the joint AOA/TDOA method in comparison to the AOA-only or TDOA-only. The joint AOA/TDOA method also does not suffer from undesirable fluctuation in accuracy as seen in the AOA-only method.

In absolute terms, the CRLB predicted RMSE are large because we have considered three stations over an approximately 3km x 5km coverage area, which is an order of magnitude larger than the coverage of our GRIFFIN open area test range. Also, the contours indicate the maximum CRLB. Actual CRLB near the center of the convex region of three stations are substantially smaller.

Conclusion

We have proposed a new integrated AOA/TDOA geolocalization algorithm that can be used for passively sensing and geolocating a wideband GNSS jammer and characterized its theoretical error distribution via Cramer Rao Lower Bounds. Also, we theoretically analyzed the proposed integrated AOA/TDOA with realistic covariances in a hypothetical environment and found that this approach can deliver substantial reduction in root mean squared error (RMSE) over conventional AOA-only or TDOA-only geolocalization, when averaged across the entire test range. Additionally, we also show in a real-world experiment employing the GRIFFIN network of time-synchronized phased arrays that our proposed approach can deliver up to 63.6% and 44.6% of RMSE reduction when compared against AOA-only and TDOA-only geolocalization.

In absolute terms, our approach has delivered up to 2.43m reduction 3σ error in a real-world experiment, bringing the resultant horizontal 3σ error down to 1.39m. In our tests, the size of the approved GRIFFIN interference test range has limited our ability to test the case for stations spread across longer baselines. By way of extrapolation, our proposed methods can potentially deliver hundreds of meters of improvement in accuracy as visualised in a simulated deployment at an airport.

Acknowledgments

This work was jointly funded by the Australian Research Council (ARC) and GPSat Systems Industry through Linkage Project LP140100252. The field tests were supported by GPSat Systems Australia Pty Ltd.

Manufacturer

The stations used GRIFFIN prototype engineering hardware manufactured by GPSat Systems Australia Pty Ltd in early 2017 as supporting contribution for its ARC Linkage project with UNSW. The GRIFFIN hardware has since undergone substantial engineering changes. GRIFFIN is a series of hardware and software suite for detecting and geolocating jammers and spoofers in one or more GNSS spectrums. On 15 August 2019, the Australian Ministry of Defence announced that GRIFFIN is currently being taken into production via its Defence Innovation Hub program.

Authors

The post Detecting and Geolocating Jammers and Spoofers Using Integrated AOA and TDOA Measurements appeared first on Inside GNSS - Global Navigation Satellite Systems Engineering, Policy, and Design.

Authors: Vicente Lucas-Sabola IEEC-CERES, UNIVERSITAT AUTÒNOMA DE BARCELONA Gonzalo Seco-Granados IEEC-CERES, UNIVERSITAT AUTÒNOMA DE BARCELONA José A. López-Salcedo IEEC-CERES, UNIVERSITAT AUTÒNOMA DE BARCELONA José A. García-Molina European Space Agency, ESA/ESTEC

***

In recent years, modern society has moved towards the use of emerging technologies in order to facilitate day-to-day decisions while optimizing resources in an automatic way. This is the case of the Internet of Things (IoT), where physical objects such as bikes, wearables, urban furniture, etc., are connected within a network with the mission of providing some kind of information (e.g., temperature, humidity, lighting, etc.) that can later be used in different applications and services (see Additional Resources, D. Singh et alia). As an example, a smart city uses the information gathered by multiple IoT sensors distributed in an urban area to optimize the efficiency of city operations: waste management, smart lighting, traffic congestion, etc. The goal is to make cities more sustainable places and to manage them in a more effective, efficient, and social manner. In this context, positioning information remains a key component for a wide range of applications that use multi-sensor data for real time sensing or crowd-sourcing, among others (M. Batty et alia). 

In general, IoT sensors must cope with many key challenges: identification, information privacy, security, interoperability, low-cost, etc. (R. Khan et alia). More importantly, even though semiconductor technologies are evolving by leaps and bounds, one of the main challenges IoT positioning sensors must face is power consumption. The battery life of a sensor is expected to last as long as possible (on the order of 10 years) in order to minimize human maintenance and hence reduce costs. To achieve a longer battery lifetime, IoT sensors usually work with short duty cycles: they remain in sleep mode, where the power consumption is significantly low (on the order of µA), and only swap to active mode (power consumption on the order of mA) when they sense data and communicate it to a central node. IoT positioning sensors often use the Global Navigation Satellite System (GNSS) due to its coverage and its ease of use, i.e., the user is not required to install any kind of infrastructure. However, GNSS chipsets are power hungry devices, incurring a considerable decrease of the IoT sensor battery lifetime, an aspect that vendors are trying to tackle with the development of low-powered GNSS chipsets. Furthermore, as we will see in the next section, the performance of GNSS receivers is jeopardized in challenging environments such as indoor, light-indoor, or urban scenarios (G. Seco-Granados et alia).

Current GNSS IoT positioning solutions compute the so-called Position, Velocity, and Time (PVT) on the sensor itself, hence requiring a certain amount of computational resources (i.e., CPU and RAM) and thus consuming a certain amount of power. This is further aggravated by the increase of data (e.g., signals from multiple GNSS constellations) to be processed and the complexity of the GNSS signal processing techniques to be applied. This article sheds some light on the challenges of current IoT positioning sensors and proposes the use of a cloud-based GNSS positioning approach, in which the computational tasks typically carried out on-chip are migrated to a cloud server with the objective of enhancing the sensor’s battery lifetime without compromising the performance (V. Lucas-Sabola et alia, 2016). The processing of GNSS signals in remote servers was initially proposed in the 1990s to reduce power consumption and economic cost of positioning sensors (A. Brown and R. Silva). Nowadays, the high-scalability and low-cost offered by cloud computing services make them the perfect choice for implementation of remote GNSS signal processing. These services require less energy than GNSS modules (J. Liu et alia; V. Lucas-Sabola et alia, 2017). 

IoT Positioning Sensors

IoT positioning solutions can be divided into three main groups: those based on GNSS, those based on non-GNSS, and those combining both GNSS and non-GNSS technologies in a hybrid manner. Outdoor IoT positioning typically relies on the use of GNSS modules that are in charge of capturing the GNSS signal transmitted by the satellites from one or multiple constellations such as Global Positioning System (GPS), Galileo, GLONASS, or BeiDou and applying the necessary signal processing techniques in order to obtain the PVT. Even though GNSS were originally designed for outdoor environments, novel techniques are designed to boost the performance in indoor scenarios, including the exploitation of distributed Receivers of Opportunity (RoO) located in close-by locations in a cloud-based GNSS framework (J. A. García-Molina et alia) and the implementation of advanced GNSS signal processing techniques. On the other hand, indoor IoT positioning usually relies on non-GNSS technologies namely 4G/Long Term Evolution (LTE), Wireless Local Area Network (WLAN), Low-Power Wide-Area Network (LPWAN), Ultra-Wide-Band (UWF), or Inertial Navigation Systems (INS). Eventually, IoT positioning sensors may perform on-chip hybrid positioning using a combination of GNSS and non-GNSS technologies at the expense of higher power consumption and cost (G. De Angelis et alia). 

An IoT positioning sensor is typically composed of a MicroController Unit (MCU), a reception/transmission Radio-Frequency (RF) front-end (so-called communication module), an antenna, the respective positioning module, memory and the power supply (i.e., battery). The MCU is the brain of the sensor, an integrated circuit that includes one or more CPUs and a low capacity RAM able to perform basic computational tasks. The communication module (includes reception and transmission front-end) receives the requests and transfers the data or information to a central node. The positioning module varies depending on the technology used (e.g., GNSS, INS, LTE). In this article we only focus on GNSS-based solutions. 

The positioning module of a GNSS-based IoT positioning sensor is a GNSS module, as depicted in Figure 1(a), which is in charge of capturing and conditioning the GNSS signals of interest with its own RF front-end (usually included in the GNSS module) and processing them to compute the position. Positioning data is often delivered by means of the National Marine Electronics Association (NMEA) protocol, producing a file that contains information regarding the position of the sensor, visible satellites, measurements, pseudoranges, etc., whose size is in the range from 1 to 5 kilobytes (kB). In order to reduce the amount of data to be transferred from the IoT sensor to the central node (uplink transmission), the NMEA is processed on-board and just the location of the sensor is delivered in the end, hence reducing the output to a few bytes. During the time the GNSS module is in active mode, it essentially switches between acquisition and tracking state. In the acquisition state, the GNSS module is searching and acquiring GNSS signals until it is capable of providing a position fix. This is the maximum power-consuming state of the GNSS module. Afterwards, it switches to a tracking state that provides position fixes with the already acquired satellite signals and searches for signals of new visible satellites. The tracking state is considerably less power-consuming than the acquisition state. Nevertheless, it is difficult to measure the power consumption of a GNSS module as it varies depending on the working conditions. For instance, a satellite with low Carrier-to-Noise ratio (C/N0) would require a longer coherent or non-coherent integration at the acquisition stage, thus needing a larger amount of computational resources which implies an increase in the power consumption. 

Hence, one of the goals most Mass-Market (MM) GNSS chipset vendors have (in addition to achieving lower power consumptions) is to reduce the active time until providing a reliable position fix, also known as Time-To-First-Fix (TTFF). The TTFF depends on the starting mode at which the GNSS module initiates when it is switched from sleep to active mode. There are four different starting modes: cold, warm, assisted, and hot (F. Van Diggelen). In a cold start, all the possible frequency and code delays are searched and the ephemeris and broadcast time are decoded. In a warm start, only the broadcast time and ephemeris are decoded, as the frequency and code delays are held as prior information. In a hot start, frequency and code delays, broadcast time, and ephemeris data are already known. Novel GNSS modules include assisted start, which allows downloading ephemeris and broadcast time information from private servers or GNSS Data Centers (GDC) in order to achieve a faster TTFF, but requires a downlink internet connection. After downloading the assistance data, the GNSS module is able to perform an assisted start. The TTFF estimates of a GNSS module for cold, warm, assisted, and hot starts (GPS L1 C/A only) are approximately 44.34, 20.52, 2 and 0.51 seconds, respectively (M. Anghileri et alia). However, larger TTFF may be achieved in harsh environments due to the difficulties in decoding the broadcast message or ephemeris, larger acquisition times, etc.  

The emergence of IoT positioning applications has sparked the interest of several MM GNSS vendors. Indeed, one manufacturer provides Assisted GNSS (A-GNSS) services to their GNSS modules at system start-up to minimize the TTFF. Similarly, another operates a worldwide reference network to provide A-GNSS data to its users, thus boosting the TTFF speed and accuracy. Furthermore, novel GNSS modules from another vendor includes two Power Save Modes (PSMs) to reduce the average power consumption: Cyclic Tracking (PSMCT) for short update periods (1-10 seconds) and On/Off (PSMOO) for long update periods (larger than 10 seconds). Of particular interest is the PSMOO which is suitable for IoT applications with long update periods (typically from hours to days). Nonetheless, the use of the PSMOO may provide significant error in the position fix. Similar power modes are available in one company’s GNSS modules: the GNSS Low Power (GLP) and the periodic mode, analogue to the PSMCT and PSMOO modes provided by another MM GNSS vendor, respectively, with the latter being the most suitable for IoT applications. See Additional Resources for more information on all of these vendors.  

To sum up, MM GNSS chipsets offer power saving configurations oriented to IoT applications. However, a tradeoff is faced between accuracy and power consumption, which varies depending on the application or use. Additionally, the use of power save modes leads to a degradation in the accuracy performance of GNSS chipsets. Together with a reduction in power consumption, diminishing the TTFF becomes mandatory in order to minimize the amount of time the GNSS chipset is in active mode. To do so, vendors provide A-GNSS services so the GNSS module can implement an assisted start. Therefore, the IoT positioning sensor would require a downlink channel for downloading the GNSS assistance data, whose size is in the range of 1 to 3 kB per constellation. Note that IoT sensors do not typically use the downlink channel as they are already pre-configured to switch between states beforehand, and hence this feature is only occasionally used.   

Cloud GNSS Receiver

In the previous section we discussed power-hungry GNSS modules and how their accuracy performance is jeopardized as power consumption is reduced. We now propose a cloud GNSS receiver that performs the GNSS signal processing tasks in a cloud server instead of on the sensor itself, thus facilitating the computational resources required by the IoT positioning sensor and hence reducing its power consumption without compromising the accuracy. In addition, the cloud GNSS receiver paves the way for innovative and more advanced applications due to the amount of available computational resources in the cloud servers: secure and authenticated GNSS positioning, crowdsourcing GNSS signal processing, pay-per-use insurance, etc. 

The cloud GNSS receiver is considered a Software as a Service (SaaS), a remote application that can be used by any user or machine while it is completely transparent to him. That is to say, its services can be used without having any kind of knowledge of the software, algorithms, and computing resources used in the back-end. In this work, the cloud computing resources and services used are provided by Amazon Web Services (AWS) due to their wide range of cloud solutions, functionalities, and configuration options, along with their openness, flexibility, and low cost. 

Architecture 

The architecture of the cloud GNSS receiver is composed of three main elements (Figure 2): the cloud GNSS sensor, the cloud front-end in charge of interacting with the user, and the back-end module where a High-Sensitivity (HS) GNSS Software Receiver (SwRx) is running and where all the computational tasks, reporting, and delivery of results are carried out. The cloud GNSS sensor is the IoT hardware element in charge of gathering the raw GNSS samples at the user side, and sending them to the cloud GNSS receiver for subsequent processing. It is composed of an RF front-end tuned to the GNSS band of interest that includes an Analog-to-Digital Converter (ADC) for digitizing the GNSS signals, memory, and a communication module for interacting with the cloud GNSS receiver. 

The cloud front-end is the interface through which a user or a machine, Human-to-Machine (H2M) and Machine-to-Machine (M2M), respectively, interacts with the cloud GNSS receiver. In the H2M approach, the user can access the cloud GNSS through an HTTP web service, where users can log in and enter into a private desktop. Then, new executions or jobs can be launched using an online graphic user interface that allows for configuration of the HS-GNSS SwRx. Notwithstanding, H2M interfacing is not a scalable approach and it is not suitable for large cloud GNSS sensor networks. It is for this reason that a M2M interface becomes mandatory. In this sense, an Application Programming Interface (API) has been built to allow sensors to automatically connect with the cloud GNSS receiver. Afterwards, the output results, PVT being an example, are stored in a database and can be retrieved at any time by the user. Both API and webpage are used to generate a new job with a raw GNSS sample file and a JavaScript Object Notation (JSON) file as inputs. The JSON is used to configure the HS-GNSS SwRx to the specific needs of the analysis to be done, and to the working conditions where the samples were gathered with parameters such as the number of snapshots, the GNSS band to be processed, the coherent and non-coherent integration time, etc. The flexibility offered by the cloud GNSS receiver allows the choice of some advanced features including using long integration times for processing weak GNSS signals, implementing signal-level analysis, etc. Metadata associated with the capture of raw GNSS samples including RF and Intermediate Frequency (IF), sampling rate, quantization, encoding, etc., can be included in the JSON or by using the Institute of Navigation (ION) Software-Defined Radio (SDR) metadata standard (J. Curran et alia). Likewise, assistance information regarding the list of satellites to be searched together with their Doppler frequency can also be attached to decrease the execution time (like a hot start in an MM GNSS receiver). Assistance information can be automatically generated by the cloud GNSS receiver by attaching an approximate location and the timestamp. Finally, a Receiver Independent Exchange Format (RINEX) navigation file must be attached in order to calculate the PVT of the sensor. In this context, the cloud GNSS receiver also procures the capability of downloading RINEX navigation files from servers of the International GNSS Service (IGS). This is mainly to avoid the need for capturing GNSS signals during a long interval of time (i.e., at least 30 seconds in GPS L1 C/A are required to read and decode the ephemeris embedded into the navigation message) and hence reduce the amount of data to be captured and transferred to the cloud to a few milliseconds of signal. Lastly, the files and job instructions generated by the cloud front-end (i.e., raw GNSS sample file, JSON, API commands) are transferred and communicated to the cloud back-end.

Each new job generated by a user or IoT positioning sensor is received and managed by a resource manager in charge of allocating cloud computing resources to the job. The back-end of the cloud GNSS receiver is where the bulk of the processing tasks are carried out. This comprises reading, decoding, and processing the raw GNSS sample file given the configuration parameters included in the JSON file to finally obtain the desired output such as PVT. This process is implemented by means of an HS-GNSS software receiver, a snapshot-based GNSS receiver with a C/N₀ sensitivity down to 15 dBHz (J. Lopez-Salcedo et alia). The HS-GNSS SwRx core is based on the extensive use of FFT processors and implements long integration times up to several seconds using advanced non-coherent integrations. 

In addition, different AWS solutions are used to build the back-end: Elastic Cloud Computing (EC2), Simple Queue Service (SQS), Batch, Relational Database Service (RDS), Elastic Container Service (ECS), and Simple Storage Service (S3). EC2 provides re-sizable and scalable computing resources (i.e., RAM, CPU, storage, etc.) in the cloud as instances (virtual machines) that act as a physical computing machine. There is a wide range of available virtual machine types, each of them suitable for different uses. SQS is a message queuing service to communicate different modules and systems within the cloud infrastructure. Batch enables us to optimally compute jobs on AWS resources (i.e., EC2) based on its computing requirements (e.g., CPU, RAM). RDS is used to store and manage the database of the cloud infrastructure which includes information such as users, PVT results, job configurations, etc. ECS allows for the launch and scale of Docker containers on AWS when a job is received. A Docker container includes the HS-GNSS SwRx and all the necessary software for the processing of the raw GNSS sample file. S3 provides secure, durable and highly-scalable object storage and is used to store the data uploaded from the sensor, which is then downloaded in an EC2 virtual machine in order to be processed. 

Thus, when a cloud GNSS IoT sensor (Figure 1(b)) launches a request, it first has to upload the raw GNSS sample file and the configuration data (i.e., JSON) to the S3 repository and send a request by means of a message to the SQS queue. When the SQS message is read by the resource manager, a new job is generated, inserted into the database by its identification number, and then managed by Batch, which will start a given EC2 instance type depending on the computing resources required by the job, and launch a Docker container from the ECS service. Once the container is launched, it automatically downloads the data regarding to the identification number of the job (i.e., raw GNSS sample file, JSON) from S3 and the HS-GNSS SwRx is launched. Finally, the output results are stored in the database from which it can be retrieved through the API or web page. This workflow is depicted in Figure 2. 

Energy Consumption

As we have previously seen, instead of locally processing the GNSS data, the cloud GNSS IoT sensor (Figure 1(b)) only has to transfer it to a cloud server. This simple process is expected to be more energy efficient than conventional IoT positioning approaches where the PVT is computed on-chip. Nevertheless, it is known that data transmission is one of the most energy consuming stages of an IoT sensor. Depending on the application, it is even higher than performing the computational tasks locally in the device itself. In the cloud GNSS receiver, the size of the data (i.e., raw GNSS sample file) to be transmitted from the sensor to the cloud is directly proportional to the signal length (in time), the sampling frequency of the reception RF front-end, and the quantization of its ADC. Therefore, a trade-off is met between the size of the data to be transmitted and the energy consumed by the cloud GNSS IoT sensor (Figure 1(b)). Furthermore, the signal length is also related to the sensitivity of the GNSS receiver, as increasing the coherent or non-coherent integration time allows for the detection and acquisition of weaker GNSS signals. Hence, another trade-off is met between the sensitivity of the GNSS receiver and the size of the data to be transferred. 

In order to properly compare the expected energy consumption of both the conventional and cloud GNSS IoT sensors (Figure 1), we have to address the energy consumed by each of the components they comprise (V. Lucas-Sabola et alia, 2017). First, the energy consumption of a conventional GNSS IoT sensor (Figure 1(a)) performing a position fix is discussed. Basically, the required energy by a component can be obtained by its current consumption in active mode, the amount of time in active mode, and the supply voltage. For this study case, the supply voltage is set to 3.3 V. The current consumption has been obtained from datasheets of state-of-the-art components (Table 1). Regarding the current consumption of the components, the reader should note that the communication module also consumes an additional amount of energy due to the release of power from the antenna during transmission, and the GNSS module current consumption may vary depending on the working conditions of the sensor (e.g., open, mild, or obstructed environment). 

The active time of the different components have been obtained as follows: the MCU is active from the time the sensor is switched on and begins capturing the GNSS signal until the PVT is sent; the active time of the memory and communication module is directly dependent on the size of the packet to be stored and transmitted, respectively (a few bytes in this study case); and the GNSS module active time is equal to the TTFF for each of the four different starts: 44.34, 20.52, 2, 0.5 seconds for cold, warm, assisted, and hot, respectively (TTFF for assisted depends on the downlink latency). Note that the acquisition time may vary depending on the working conditions, i.e., larger in harsh environments and hence increasing the energy consumption. 

In Figure 3 the expected energy consumption of the different components of a conventional GNSS IoT positioning sensor (Figure 1(a)) is shown. It can be seen that the energy consumption of the GNSS module depends on the operation mode (i.e., hot, assisted, warm, cold), and hence depends on the TTFF. In contrast, the rest of the sensor components such as the MCU, memory, and communication modules have an energy consumption directly dependent on the packet to be handled and transmitted to the cloud. Indeed, the MCU must stay in active time until the data (i.e., PVT output) is sent to, for example, a central node. The size of the packet to be transmitted through the communication module when only the coordinates are sent is approximately 1-2 bytes, 1 kB for a small NMEA, and 5 kB for a large NMEA. We can clearly see that the GNSS module typically is the largest consumer of a conventional GNSS IoT sensor (Figure 1(a)), even for hot and assisted starts by an order of magnitude in comparison with the MCU and up to four orders of magnitude in contrast with the communication and memory modules. 

For the cloud GNSS IoT sensor (Figure 1(b)), the same procedure has been applied, but the GNSS module has been substituted with only a GNSS RF front-end, also including an ADC. In this sense, the GNSS RF front-end must be carefully chosen to avoid compromising the energy-efficiency of the cloud GNSS IoT sensor (Figure 1(b)), as it will not only contribute to its own energy consumption, but also in the energy consumed by the other components as they are directly dependent on the packet size. Indeed, the size of the data to be transferred to the cloud can be expressed as L = T_slbFs_rx, where L is the packet size in bits, T_sl is the captured GNSS signal length in seconds, b is the quantization bits of the ADC, and Fs_rx is the sampling frequency of the RF front-end. Therefore, there are three alternatives in order to work with small-sized packets: reduce the sampling frequency, work with a low quantization level, or capture a signal of short length. In this study case, with the objective of achieving low energy consumption, the RF bandwidth is set to 2 megahertz, enough to capture the main lobe of the GPS L1 C/A signal, and the sampling frequency is set to 4 megahertz. On the other hand, the ADC uses 1 bit to digitize the GNSS signal. According to state-of-the-art components, the current consumption of a GNSS RF front-end with such characteristics is approximately 5 mA. 

A comparison between the energy consumed by the cloud and the conventional GNSS IoT sensor (Figure 1) with different starts is addressed in Figure 4. In order to implement a fair comparison, the energy consumption of the conventional GNSS IoT sensor (Figure 1(a)) for different starting modes has been obtained for a packet with size 2 bytes (see Figure 3). It can be seen how as the signal length to be captured by the cloud GNSS IoT sensor (Figure 1(b)) is moderately small, the cloud GNSS receiver offers a more energy efficient positioning solution than conventional approaches. For instance, compared to a conventional sensor with hot start, the cloud sensor provides energy savings up to one order of magnitude for small signal lengths (i.e., a few ms) and is more energy efficient by using a signal length up to 24 ms (bear in mind that a PVT can be obtained with just 1 or 2 ms of signal). Notwithstanding, the GNSS module cannot implement a hot start every time it provides a position fix, as the stored information expires (range from 30 minutes to 4 hours). MM GNSS chipsets usually download or try to decode ephemeris data (as in cold start) every 30 minutes with the objective of having recent ephemeris and navigation data and then provide a higher position accuracy. Likewise, in contrast with an assisted start, the cloud GNSS IoT sensor (Figure 1(b)) can capture and transfer up to 46 ms of GNSS data and still continue to be more energetically efficient. Finally, in comparison with the warm and cold starts, whose TTFF and hence the amount of time in active mode is significantly high (i.e., 30-40 seconds), the cloud GNSS IoT sensor (Figure 1(b)) remains active for some milliseconds (up to 600 and 800 ms, respectively), and thus energy efficiency can reach up to 2.5 orders of magnitude. 

Performance of the Cloud GNSS Receiver

In this section we will briefly discuss the accuracy performance of the cloud GNSS receiver by means of an experimental test. To do so, a synthetic signal was generated with a GPS/Galileo signal generator simulating a static outdoors open-sky scenario at the School of Engineering of Universitat Autònoma de Barcelona (UAB). A low-cost RTL-SDR V3 USB front-end was used to capture the GPS L1 C/A signal with a sampling frequency of 2.048 MHz and generate the raw GNSS sample file, which is then transferred to the cloud GNSS receiver together with the required JSON configuration file. The visible satellites have been configured with a C/N₀ of roughly 46 dBHz.

The obtained results for GPS L1 C/A with different coherent integration times are provided in Figure 5. For a small signal length (i.e., 1 to 4 ms) a position error of tens of meters is obtained. However, as the coherent integration time is increased (i.e., 10 and 20 ms), and hence the amount of signal captured and sent to the cloud GNSS receiver is also larger, the positioning accuracy is enhanced to a few meters. In contrast to conventional GNSS IoT positioning approaches where the sensor must be in active mode for a long period of time to calculate the PVT (from a few seconds up to minutes, depending on the working conditions), in a cloud-based approach the sensor must be in active mode for just a few milliseconds, enough time to capture the desired GNSS signal and forward it to the cloud servers. Therefore, it is shown that the cloud GNSS receiver becomes an energy-efficient IoT positioning solution without compromising the obtained accuracy, particularly for those IoT applications that do not require precise positioning. 

Economic Cost of GNSS Signal Processing in the Cloud 

Processing the raw GNSS sample file in cloud servers instead of in the sensor itself as in conventional approaches implies the added cost of hiring cloud computing resources. Among the different AWS services used in the cloud GNSS receiver infrastructure, the service that implies a significant cost is the EC2 service. AWS offers three ways to pay for its services: on-demand, reserved, and spot. On-demand services are paid per hour use as they are opened and closed with a fixed cost. Reserved services, which are paid in advance, are suited for applications with predictable usage and offer discounts up to 75% in contrast with on-demand services. Moreover, we can bid for EC2 spot services whose cost may decrease up to 90% in comparison with on-demand (their fluctuating price varies depending on the supply and demand of EC2). Additionally, the price of different services may vary depending on the selected region of use, i.e., the geographic area where the EC2 servers are hosted. 

For this test set-up, c3.xlarge (Table 2) have been selected to compose the cloud back-end for processing the raw GNSS sample files with signal length between 1 and 5 ms. The allocation of the jobs generated by the requests of a network of cloud GNSS IoT sensors (Figure 1(b)) is assumed to be optimum in terms of usage time: the computational tasks of a given amount of sensors are sequentially performed in the same EC2 instance, hence reducing the cost per position fix. The monthly cost of the necessary cloud resources (i.e., EC2) for an IoT application that requires one position fix per hour is presented in Table 3: for $0.51, $0.23 and $0.1 per month, a cloud GNSS IoT sensor (Figure 1(b)) position can be calculated once per hour for on-demand, reserved and spot services, respectively. Notice that in typical IoT positioning applications, a position fix is usually requested from hours up to days. Hence, the cost of the cloud services used by a network of cloud GNSS IoT sensors (Figure 1(b)) should not be a showstopper as it has been demonstrated to be considerably low. 

Conclusions

This article discusses the conventional solutions for IoT positioning, with GNSS-based solutions being the most widespread in positioning IoT sensor networks. The architecture of a conventional GNSS IoT positioning sensor (Figure 1(a)) has been addressed, together with the energy consumption of its different components, showing that the GNSS module is the largest consumer if the data to be transferred is not large. To tackle the dilemma of energy consumption in IoT positioning sensors, we propose the use of a cloud-based GNSS approach, in which the purpose of sensors is just to capture the GNSS signal and send it to a cloud server where it will then be processed. 

The energy consumption of the proposed cloud GNSS IoT sensor (Figure 1(b)) has also been addressed and compared with state-of-the-art GNSS IoT positioning sensors. Under the constraint of working with a relatively small signal length, the use of the cloud GNSS receiver achieves a significant savings in the sensor’s consumed energy, up to one order of magnitude compared with hot and assisted starts, and up to roughly 2.5 orders of magnitude in contrast with warm and cold starts. 

Finally, the economic cost implied by the use of cloud services to process the GNSS data and obtain the position of the sensor has been shown to be low, thus ensuring the cloud GNSS receiver as a low-energy and low-cost solution for IoT positioning.

Acknowledgements

The views presented in this article represent solely the opinion of the authors and not necessarily the view of ESA. This work was partly supported by the European Space Agency (ESA) under contract No. 4000119070/16/NL/GLC and by the Spanish Government under grant TEC2017-89925-R.

Manufacturers

When the authors address the emergence of IoT positioning applications sparking the interest of MM GNSS vendors, they note u-blox, Thalwil, Switzerland, Telit, London, UK, and Broadcom Corp., Irvine, CA, as examples.

In the section discussing the accuracy performance of the cloud GNSS receiver’s experimental test, a synthetic signal was generated using a Spirent (West Sussex, UK) GPS/Galileo signal generator. Furthermore, the cloud GNSS receiver was using the baseline broadcast ephemeris from the IGS service.

Additional Resources

[1] Anghileri, M., M. Paonni, S. Wallner, J.-Á Ávila-Rodríguez, and B. Eissfeller, “Ready to Navigate! A Methodology for the Estimation of the Time-to-First-Fix,” Inside GNSS, Volume: 5, Issue: 2, 2010

[2] Atmel, “SPI Serial EEPROM – ATM25M02,” Data Sheet, 2017

[3]  Batty, M., K. W. Axhausen, F. Giannotti, A. Pozdnoukhov, A. Bazzani, M. Wachowicz, G. Ouzounis, and Y. Portugali, “Smart Cities of the Future,” European Physical Journal Special Topics, Volume: 214, Issue: 1, 2012

[4] Bousquet, F. and u-blox, “Portables: The Challenge of Low Power and Good GNSS Performance,” White Paper, 2017

[5] Broadcom Corporation, “Top Ten Advantages: AGPS Server and Worldwide Reference Network,” 2007

[6] Brown, A. and R. Silva, “TIDGET Mayday System for Motorists,” IEEE Position Location and Navigation Symposium (PLANS), 1994

[7] Curran, J., M. Arizabaleta, T. Pany, and S. Gunawardena, “The Institute of Navigation’s GNSS SDR Metadata Standard,” Inside GNSS, Volume: 12, Issue: 6, 2017

[8] De Angelis, G., A. De Angelis, V. Pasku, A. Moschitta, and P. Carbone, “A Hybrid Outdoor/Indoor Positioning System for IoT Applications,” Proceedings of the 1st IEEE International Symposium on Systems Engineering (ISSE 2015), 2015

[9] García-Molina, J. A. and J. M. Parro-Jiménez, “Cloud-based GNSS Processing of Distributed Receivers of Opportunity: Techniques, Applications and Data-Collection Strategies,” 6th International Colloquium – Scientific Fundamental Aspects of GNSS/Galileo, 2017

[10] Khan, R., S. U. Khan, R. Zaheer, and S. Khan, “Future Internet: The Internet of Things Architecture, Possible Applications and Key Challenges,” Proceedings of the IEEE 10th International Conference on Frontiers of Information Technology (FIT 2012), 2012

[11] Liu, J., B. Priyantha, T. Hart, Y. Jin, W. Lee, V. Raghunathan, H. S. Ramos, and Q. Wang, “CO-GPS: Energy Efficient GPS Sensing with Cloud Offloading,” IEEE Transactions on Mobile Computing, Volume: 15, Issue: 6, 2016

[12] López-Salcedo, J., Y. Capelle, M. Toledo, G. Seco, J. López Vicario, D. Kubrak, M. Monnerat, A. Mark, and D. Jiménez, “DINGPOS: A Hybrid Indoor Navigation Platform for GPS and GALILEO,” 21st International Technical Meeting of the Satellite Division of The Institute of Navigation (ION GNSS 2008), 2008

[13] Lucas-Sabola, V., G. Seco-Granados, J. A. López-Salcedo, J. A. García-Molina, and M. Crisci, “Cloud GNSS Receivers: New Advanced Applications Made Possible,” Proceedings of the International Conference on Localization and GNSS (ICL-GNSS), 2016

[14] Lucas-Sabola, V., G. Seco-Granados, J. A. López-Salcedo, J. A. García-Molina, and M. Crisci, “Efficiency Analysis of Cloud GNSS Signal Processing for IoT Applications,” Proceedings of ION GNSS (ION GNSS 2017+), 2017

[15] Seco-Granados, G., J. A. López-Salcedo, D. Jiménez-Baños, and G. López-Risueño, “Challenges in Indoor Global Navigation Satellite Systems,” IEEE Signal Processing Magazine, February 2012

[16] Singh, D., G. Tripathi, and A. J. Jara, “A Survey of Internet-of-Things: Future Vision, Architecture, Challenges and Services,” 2014 IEEE World Forum Internet of Things (WF-IoT 2014), 2014

[17] Telit, “K3 Series Power Modes,” Application Note, 2017

[18] Texas Instruments, “CC1310 SimpleLink Ultra-Low-Power Sub-1 GHz Wireless MCU,” Data Sheet, 2016

[19] u-blox, “Power Management Considerations for u-blox 7 and M8 GNSS Receivers,” Application Note, 2014

[20] u-blox, “u-blox M8 Concurrent GNSS Modules,” Data Sheet, 2016

[21] Van Diggelen, F., A-GPS: Assisted GPS, GNSS, and SBAS, Artech House, 2009

Authors

Vicente Lucas-Sabola received a B.Sc. in telecommunication systems engineering in 2015 and a M.Sc. in telecommunication engineering in 2017, both from Universitat Autònoma de Barcelona (UAB). Since 2015 he has been involved in the development of a Cloud GNSS receiver. Since 2017 he has also been pursuing a PhD at the SPCOMNAV group at the Department of telecommunication and systems engineering, IEEC-CERES, UAB, dealing with topics related to Cloud GNSS signal processing for Internet of Things (IoT) applications.

Gonzalo Seco-Granados received a Ph.D. degree in telecommunications engineering from Universidad Politècnica de Catalunya and an MBA from IESE, the graduate business school of the University of Navarra. From 2002 to 2005, he was with the European Space Agency, Netherlands. Since 2006, he has been an associate professor at the Universidad Autònoma de Barcelona, where he coordinates the SPCOMNAV (Signal Processing for communications and Navigation) group, IEEC-CERES. His research interests include signal-processing techniques for advanced features of GNSS receivers and localization using next-generation wireless communications networks.

José A. López-Salcedo received his Ph.D. degree in telecommunications engineering from Universitat Politècnica de Catalunya (UPC), Barcelona, Spain, in 2007. He is Associate Professor at the Department of Telecommunications and Systems Engineering, IEEC-CERES, Universitat Autònoma de Barcelona (UAB). He has held several visiting appointments at the University of California Irvine, University of Illinois at Champaign-Urbana and the European Commission, Joint Research Centre in Ispra, Italy. His research interests lie in the field of signal processing for communications and navigation, with emphasis on cloud and IoT GNSS signal processing and the convergence of 5G/GNSS systems.

José A. García-Molina is a Radio Navigation engineer at ESA/ESTEC in Noordwijk, The Netherlands, where he leads several R&D projects and internal research activities on GNSS receiver technology and signal processing techniques for ground and space applications in the context of different ESA programs (including Galileo). His main research interests include signal processing and estimation theory, GNSS/Galileo receivers and signals, unambiguous estimation of high-order BOC signals, Cloud GNSS receivers, techniques and applications, collaborative positioning, and MIMO-GNSS signal processing.

Em. Univ.-Prof. Dr.-Ing. habil. Dr. h.c. Guenter W. Hein is Professor Emeritus of Excellence at the University FAF Munich. He was ESA Head of EGNOS & GNSS Evolution Programme Dept. between 2008 and 2014, in charge of development of the 2nd generation of EGNOS and Galileo. Prof. Hein is still organising the ESA/JRC International Summerschool on GNSS. He is the founder of the annual Munich Satellite Navigation Summit. Prof. Hein has more than 300 scientific and technical papers published, carried out more than 200 research projects and educated more than 70 Ph. D.´s. He received 2002 the prestigious Johannes Kepler Award for “sustained and significant contributions to satellite navigation” of the US Institute of Navigation, the highest worldwide award in navigation given only to one individual each year. G. Hein became 2011 a Fellow of the US ION. The Technical University of Prague honoured his achievements in satellite navigation with a Doctor honoris causa in Jan. 2013. He is a member of the Executive Board of Munich Aerospace since 2016. 

The post GNSS IoT Positioning: From Conventional Sensors to a Cloud-Based Solution appeared first on Inside GNSS - Global Navigation Satellite Systems Engineering, Policy, and Design.

The spoofing of GNSS signals is a controversial and divisive topic within the satellite navigation community. Some believe that spoofing is virtually infeasible, while other industry insiders believe that spoofing is actually trivial. Referring to Figure 1, we present an example of a survey grade receiver, reporting that it is tracking each of L1 C/A, L2C, L1P(Y), L2P(Y) signals and generating a valid position solution in Norway while it is actually sitting on a desk in the Netherlands being fed a spoofed signal from an low-cost off-the-shelf “single frequency” software defined radio. Contrary to other assertions, it was possible to perform this using only 12 megahertz of instantaneous broadcast spectrum. This resulted in no measurable code-carrier divergence, nor was the spectrum quite as obviously distorted as has been suggested. Given that these apparently reasonable assumptions (that multi-frequency spoofing required a “multi-frequency” signal generator, and that spoofed signals will have obvious imperfections), were demonstrated to be unfounded, then we should perhaps revise our assumption, and reconsider our approach to the problem. 

Background

The reliability of radionavigation equipment and the trust that can be placed in its correct functioning has become of increased importance as ever more aspects of modern infrastructure and civilian services have become dependent on it. Systems and techniques aimed at providing robustness or resilience against the malicious adversary come in a variety of forms: some are based on the augmentation of the receiver with sensors that are deemed inaccessible to the remote adversary, including inertial, odometer barometer sensors; some are based on spatial-signal processing techniques, including multi-element or synthetic-aperture antennas; some are based on signal fidelity tests, which assess whether certain characteristics of the received signal fulfill the expectation of the receiver, being power levels, data content, modulation, or the presence of certain signals. 

The trust we can place in the receiver is therefore inherently tied to our estimate of the capabilities of the adversary, and how each of these relative capabilities might evolve over time. Unfortunately, advances in technology play in the favor of the ever-adapting adversary, not the user with installed equipment or infrastructure. There is a risk that if the capability of the adversary is underestimated, or the difficulty of signal generation is overestimated, then the user will be exposed. An additional challenge is that it can be difficult to envisage how the adversary might approach the problem. As engineers, we are often biased, even subconsciously, by best practices, rules-of-thumb, precedence, or general convention — we tend to use things in the way they are supposed to be used. In contrast, an adversary who is already committed to breaking the law is unlikely to hesitate to break some design rules too.

In this article, we examine this problem through an example of multi-frequency signal generation via existing off-the-shelf low-cost equipment which was dismissed as incapable of such signal generation. It has been generally held that the generation of multi-frequency GNSS signals is beyond the capability of an “entry-level” adversary, and so multi-frequency receivers are, to some extent, invulnerable. This belief is based on the observation that the low-cost software-defined transceivers support only a single transmit frequency and have insufficient instantaneous bandwidth to synthesize two adjacent GNSS bands. While it is true that if these devices are used as intended, they are not capable of producing multi-frequency signals; however, if they are appropriately abused, then they can, as is demonstrated here. In this example it is shown that a transceiver can be intentionally misconfigured, such that it produces an ensemble of GNSS signals at an “incorrect” frequency, but leaks harmonics into two different GNSS bands (both above and below the transmitted carrier frequency). It is further shown that if the generated signal is sufficiently strong then these harmonics can be acquired and tracked by a naive GNSS receiver — with the result that the receiver produces a dual-frequency position solution based on signals generated from a single narrow-band single-frequency transmitter.

The authors offer this as a cautionary example, suggesting that we do not underestimate the adversary, and note that if some technical feat has not yet been observed, it does not necessarily imply that it is impossible. It might only illustrate that it has not yet been provoked. Moreover, this principle might be extended beyond signal synthesis, to condition our general assumptions about what is, and what is not, technically feasible. Continuously challenging our assumptions and embracing a “red-team” approach might be necessary to more accurately quantify the risks. 

Recent Developments

The spoofing of GNSS signals is controversial, with points of view on the topic ranging from the belief that spoofing is virtually infeasible, to the belief that it is trivial. Some hold that the act of spoofing is still only in the domain of state actors due to the extremely high resource requirements necessary to properly execute such an attack, while others assert that entire families of mass market receivers are vulnerable to the most simplistic of spoofing attacks. Both of these camps can be viewed as correct in light of specific recent events including ships in the Black Sea reporting that they were parked on the tarmac of a nearby international airport, to smartphones at the ION GNSS+ 2017 conference in Portland adamantly insisting that they had traveled through space and time to visit Europe circa 2014. 

Throughout a variety of interesting presentations authors pointed out a number of signal characteristics that could be used to detect, and therefore mitigate, the low-cost spoofing threat. One popularly held belief is questioned here: that it is technically challenging to create a set of dual-frequency counterfeit GNSS signals having sufficient phase and delay fidelity to be acceptable to a dual-frequency GNSS receiver, and that the cost of doing so is significantly higher than the cost of creating a single-frequency counterfeit signal. By extension, it is held that dual- or multi-frequency GNSS receivers are far less vulnerable to spoofing than single-frequency receivers. This assertion caused the authors to utter a collective “hold my beer and watch this” as we set out to debunk it. 

Further characteristics listed as red flags included: inconsistent navigation data; anomalous code-carrier divergence; and obvious spectral shaping indicating unexpectedly high received power levels, are discussed critically here in light of the questionable validity of the claim that dual-frequency signal generation is difficult.

Technological Barrier to Multi-Frequency Signal-Generation

In GNSS receiver design, we are very much conditioned to strive for quality and precision, tend to use extremely high quality components, and take great measures to minimize receiver losses. For this reason we might overlook the simple “ugly” shortcuts that might be available to a less fastidious adversary. The adversary is only interested in the minimum passing standard, not the best that can be achieved, so equipment and techniques that might be unthinkable to a receiver engineer might be perfectly acceptable to him. 

To explore this idea, it is worth noting that there can be a large difference between: i) what the satellite actually generates, ii) what the receiver expects, iii) what signals and features the receiver actually looks for, iv) what signals the adversary is obliged to generate to satisfy this expectation, and v) what other signals the adversary can get away with producing. Therefore, the adversary can put many things into the spectrum that is observed by the receiver, provided it also includes the expected signal, and provided any extra signals are not obviously anomalous. More importantly, the spoofer can put virtually anything into the spectrum that the receiver does not observe. Under certain circumstances this fact can be exploited.

In this example, we consider a typical type of SDR transceiver that has been used in numerous demonstrations of single-frequency (L1) GNSS spoofing, however this particular device is very similar to other popular and similarly priced pieces of equipment available. These devices typically have a USB 2.0 or 3.0 interface to the host computer, produce from 20 to 40 megahertz of instantaneous bandwidth, and can modulate a baseband signal to a carrier in the range of approximately 100 megahertz to 6 gigahertz. The challenge was to perform dual-frequency spoofing with such a device. Conductive tests were performed on a commercial multi-frequency survey-grade receiver, as shown in Figure 2.

Without revealing too many details (so as not to encourage misbehavior), what follows is a brief description of the concept. It was noted that if the front-end “reconstruction” filter were disabled or removed from a transmitter, then the signal synthesized at the digital-to-analog converter (DAC) would alias across the entire spectrum. Secondly, it was noted that if the L2 signals were present in the L1 band, they would likely go unnoticed by the receiver, and vice-versa for L1 signals in the L2 band. Noting these two facts, it was clear that if a single composite baseband signal consisting of all of the L1 C/A, L1 P(Y), L2C, and L2 P(Y) signals were generated and broadcast somewhere between L1 and L2, then it would be possible, with appropriate tuning, to cause genuine-looking signals to appear at L1 and again at L2. Because of this unusual generation technique, these signals were attenuated by approximately 23 decibels relative to the total broadcast power, that is, less than 0.5% of the total broadcast power appears as a useful signal. Nonetheless the signals are present in a useful form. An example of the resultant spectrum is shown in Figure 3. This is the signal processing equivalent of playing a xylophone with a cat; it is ugly and illegal, but it works.

Given that the spectrum aliasing could be used to repeat the broadcast signals across the required bands, what remained was to remove the high-power signal and adjust the power accordingly. Fortunately, when performing a conductive test, (or a very-close range broadcast), then achieving sufficient power is not a challenge, and even though over 99.5% of the power was spent in Nyquist bands not observed by the receiver, the remaining 0.5% was sufficient. Also, it was noted that most commercial receivers implement relatively sharp band-pass filtering on the RF spectrum such that the large `interference’ signal residing in the middle of the band was rejected. An example of the carrier-to-noise ratio observed by the receiver under test is shown in Figure 1. Note that all four signals were tracked, although the P(Y) codes appeared to suffer somewhat from the narrow-bandwidth of the re-broadcast. In the figure, note also that only five of the satellites were L2C-enabled.  The receiver tracked steadily for over 30 minutes, and produced a steady code-only position solution, an example of which is shown in Figure 4. While the signals might be considered `ugly hacks’ (which they are), it is important to note that contrary to popular belief neither the need for two center frequencies nor the lack of bandwidth on existing SDR platforms posed a particular problem. Moreover, although this article has demonstrated only a dual-frequency spoofing, the underlying principle can readily be extended to three or four center-frequencies. This has its most immediate value in the generation of GLONASS signals for spoofing mass-market L1-only receivers. 

Detection of Spoofing Based on Signal Anomalies

Further characteristics that are popularly listed as red flags included: inconsistent navigation data; anomalous code-carrier divergence; and obvious spectral shaping indicating unexpectedly high received power levels. In light of the questionable validity of the claim that dual-frequency signal generation is difficult, these further points are briefly discussed.

Excessive code-carrier divergence observed in the received signal is not a function of whether or not a signal is counterfeit, but rather is related to the particular method used in the generation of the signal. In many cases, equipment that has been designed for use in telecommunications applications does not offer very precise carrier frequency tuning, and although it may report that it is tuned to, for example, L1, it may in fact be tuned to the nearest frequency that can be achieved with its synthesizer. For example, the device shown in Figure 5 uses a 20-bit fractional PLL and 30 megahertz reference (where the reference clock is first multiplied by three), and so can only tune with a resolution of approximately 28 hertz. Similarly, the device used in one example at ION GNSS+ 2017, uses a 22-bit fractional-N synthesizer, and can only tune with a resolution of approximately 8.5 hertz that, given its 38.4 megahertz reference, matches almost exactly the 1.7 m/s reported excess code-carrier divergence. By calculating this residual frequency error it can be compensated with a non-zero IF at signal-synthesis, at no extra cost. Once this code-carrier divergence anomaly becomes part of the “spoofing defense”, the adversary will simply correct them in the signal-generation stage. As such, this kind of detection scheme is temporary, at best.   

To demonstrate this, a simple GPS/Galileo L1/E1 spoofer was assembled and used to spoof a survey receiver. The signal generation function was carefully configured to address the synthesizer considerations discussed above, such that the exact carrier frequency was known, and the delta frequency to L1 was injected as a digital IF in the signal generation stage. 

The spoofer itself was based on a software-defined radio constellation simulator, written specifically to adhere to the resource constraints of a micro-computer such as the Raspberry-Pi and therefore uses very limited memory. The digital baseband GNSS signal ensemble is generated with a transmit bandwidth of 8 megahertz and is streamed via USB 2.0 to the transceiver board at an 8-bit sample depth. The device upconverts this signal to RF and broadcasts to the target receiver. The spoofer is controlled using a simple command-line interface that can be a accessed via SSH, enabling it to be controlled remotely via cell-phone, as shown in Figure 6. The complete spoofer has an off-the-shelf build cost of approximately $400 (USD).

The test spoofed a static position with between eight and 10 satellites in view (owing to rising and setting satellites). A one hour test was conducted and the receiver measurements were logged as RINEX 3.02 for post-processing. The pseudorange and carrier phase were loaded from the RINEX file and code-carrier difference was formed for the GPS L1 C/A signals. These are plotted in Figure 5 for the first 20 minutes of the test for eight of the satellites observed. As can be seen, the code and carrier are coherent and do not diverge with time. As such, provided the spoofing hardware is appropriately configured (and regardless of whether it is low-cost or expensive) it is unlikely that it is possible to effect any level of spoofing detection based on the code-carrier coherency.

Inconsistent navigation data is simultaneously a very good and very bad way to isolate a spoofed signal from a real one. In one sense it is an effective approach for a user with multiple sources of information and who can, at the very least, flag navigation data inconsistencies as deserving of a closer look. In another sense it can be viewed as a weak approach, given that an adversary might generate any arbitrary navigation message, and might take relatively simple steps to ensure that the navigation data carried by the counterfeit signals matches that which would be expected. 

That said, given the results of the unintentional spoofing at ION GNSS+ 2017, it appears that even when a consumer device has access to three or more streams of location and timing data (GNSS, LTE, WiFi), many implementations will happily travel three years back in time if their GNSS radio says to — implying that although the capability to detect message inconsistency is present in these devices, it is not necessarily exploited. While this aspect of spoofing resistance can certainly be improved, it might not be advisable to view it as robust against a moderately well prepared adversary who, for example, also might have an internet connection. Looking forward, even cryptographic message content that the attacker cannot generate can appear to be predicted given a small delay, and a clever attacker might find a way to insert one.

In terms of the fidelity of the physical layer of counterfeit signals, a number of authors have pointed to excessive code carrier divergence or spectrum abnormalities as being indicative of spoofing. While this might be the case in some crude implementations, in light of the discussion here, it is perhaps naive to assume that once a receiver begins to monitor these features, that the adversary will be incapable of adapting.

Obvious spectral deformation due to the use of a high spoofing power level is a parameter that can offer caution to a user in some cases, but may not actually be a wise choice of metric to base a security system on. While it is much easier for an adversary who does not care about collateral disruption to set their transmit power level to an extreme level, a more careful adversary might readily tune to within +/- 6 dB of a desired power level even on a relatively close and moving target. A crafty adversary could just as easily pre-filter their side-lobes to make their presence less obvious at the cost of a bit more computation and a bit higher code tracking noise in the output, depending on the receiver model. Additionally, since it is completely reasonable that users might want to make use of their GNSS receivers with simulators or in areas where unintentional RFI may be present, declaring the signal to be compromised based only on spectral bumps might result in an undesirably high false-alarm rate. Systems that make use of 12 megahertz clocks can produce RF spurs at 1572 megahertz, while those that use 24 megahertz clocks may produce one at 1560 megahertz or 1608 megahertz which have potential aliasing concerns. Considering how prevalent 12 and 24megahertz oscillators are in modern electronics we highlight that devices using USB 1.0, 2.0 or 3.0 will likely have at least one of these frequencies present. Moreover, it is well known that many USB 3.0 devices generate broadband interference in the L-band observable in the vicinity of their connectors. The short summary being that whether we want it or not, the modern connected world is rich in useful devices that can cause artifacts in the L-band, and declaring a navigation fault or malicious attack whenever one is detected may not be the best way to serve the end users.

Outlook

In summary, while we are glad the threat of spoofing is being discussed, it is worth noting that it is probably dangerous to adopt an industry posture that either exaggerates or minimizes the scope of the threat. It is not the case that we are adopting a new technology (GNSS), and doing so in full knowledge of the calculated risks — rather, we find ourselves having already fully embraced this technology, and only now are the risks coming to light. As users of GNSS receivers — consumer-grade equipment with scientific-grade precision — we are in some sense perfectionists, and so may have trouble identifying the dirty short-cuts that can be taken. It is worth remembering that from the perspective of the adversary, it doesn’t have to be pretty, it just has to work. While this article might at first appear to be pessimistic, suggesting that the adversary is boundlessly capable, the authors suggest that to believe the contrary, and to rely on the adversary to sleep through their comms-theory lectures and misconfigure their radio, is also probably not a good idea.

Manufacturers

The transceiver that has been used in numerous demonstrations of single-frequency (L1) GNSS spoofing is the Nuand BladeRF from Nuand LLC, Rochester, N.Y. USA, while the similarly priced pieces of equipment available refer to the HackRF from Great Scott Gadgets, Evergreen, Colorado, USA and the LimeSDR from Lime Microsystems, Surrey, United Kingdom.

Further Reading

LimeSDR https://www.crowdsupply.com/lime-micro/limesdr

BladeRF https://nuand.com/

HackRF: https://greatscottgadgets.com/hackrf/

GSA: https://www.gsa.europa.eu/system/files/reports/gnss_user_technology_report_webb.pdf

Septentrio: https://www.septentrio.com/insights/gps-spoofing-your-receiver-ready-attack

New America: https://www.newamerica.org/international-security/future-property-rights/blog/price-precision-dual-frequency/

Black Sea Incident: http://www.insidegnss.com/node/5555

ION GNSS+ Spoofing: http://www.insidegnss.com/node/5661

Authors

James T. Curran received a Ph.D. in electrical engineering from University College Cork, Ireland. Over the past decade has worked in radio navigation research at the University of Calgary, Canada, the Joint Research Center of the European Commission, Italy, and for the European Space Agency, ESTEC, Netherlands. 

Aiden Morrison received his Ph.D. in 2010 from the University of Calgary, where he worked on ionospheric phase scintillation characterization using multi-frequency civil GNSS signals. He works as a research scientist at SINTEF Digital in Trondheim, Norway

Cillian O’Driscoll received his Ph.D. degree from University College Cork, Ireland. He has worked as a senior research engineer with the PLAN Group at the University of Calgary, as a Grantholder with the European Commission, and as a research support officer at University College Cork, and is currently an independent consultant specializing  in GNSS signal processing.  

The post (In)Feasibility of Multi-Frequency Spoofing appeared first on Inside GNSS - Global Navigation Satellite Systems Engineering, Policy, and Design.

Signal design is one of the core tasks of GNSS development, because the broadcast signal is the only interface of the system for receivers, and its inherent performance determines the success of the entire system’s performance. Once the signal detail is defined, any subsequent change may cause changes to a large number of user terminals, which could have significant cost impact.

Therefore, GNSS signal design cannot simply follow the “release first, update later” route. It must be fully studied and demonstrated before system implementation. However, as a significant infrastructure, GNSS has a long development cycle. It may take several years from the time of initial signal design to the full operation of the system. This fact forces signal designers to have sufficient foresight, using existing technology, to enable unknown service requirements over future decades of operation. Therefore, although most of the signals in current GNSS have been defined, the evolution of GNSS signal design will not stop there. The full operation of the current GNSS is the beginning of the design work of the next generation GNSS.

From the reality of GNSS design one can find that the growing expanded applications and refined services prompt the new generation systems to broadcast more signals with more complicated structure, which on the one hand makes more efficient use of limited spectrum resources, already crowded with GNSS signals, but on the other hand makes the spectrum crowding situation even worse. Moreover, such a complicated signal structure may make the realization of signal multiplexing more difficult for satellite payloads. Additionally, the limitation of receiving complexity, the requirement for backward compatibility, as well as the demand of interoperability among systems, add many constraints into the GNSS signal design optimization problem. The immaturity of methodology and the conflict between application expansions and resource scarcity cause the signal design of the next generation GNSS to face a series of challenges. At present, it is necessary to take a hard look at the technical challenges in future GNSS signal design, and look for possible solutions in advance.

Challenges Facing Future GNSS Signal Design
Compared with wireless communication signal design, the major feature of navigation signal design is the pursuit of high accuracy ranging capability. If we compare the wireless communication signal, of which the most concerned targets are the capacity and reliability of data transmission, to a paper envelope, then the satellite navigation signal can be compared to a ruler, since its main concern is the accuracy and robustness of the ranging measurement.

In the design process of this “ruler”, the selection of the carrier frequency, the optimization of the spreading modulation, and the multiplexing of signal components are the top three critical and challenging parts.

Carrier Frequency Selection
The carrier frequency, as is the material of a ruler, determines many of the attributes of a navigation signal, including the propagation characteristics, the cost of transmitting and receiving hardware, signal Doppler shift, and possible interference with other radio systems.

Among all available spectrum resources, the L-band has many advantages for satellite navigation applications, such as good propagation characteristics, moderate antenna size, and relatively small atmosphere influence, and therefore became the preferred frequency band for satellite navigation signals. At present, the vast majority of GNSS signals are gathered in the upper L band (1559 ~ 1610 MHz) and the lower L band (1164 ~ 1300 MHz).

Figure 1 (see inset photo, above right) illustrates spectra of navigation signals of the current and emerging GNSSs in the upper L band. Obviously, it is hard to find any unoccupied contiguous segment in this frequency band. There are only a few scattered available frequency fragments remaining between main lobes of existing signals. Interference arises among different signals. Although it is possible to reduce the spectral overlap of the signal located at the same central frequency to a certain extent by using different subcarriers or adjusting the spreading chip waveforms, it is still becoming increasingly difficult to find a suitable central frequency for a newly added navigation signal in L-band.

Some studies (including Avila-Rodriguez et alia, and Irsigler et alia, Additional Resources) consider the use of higher frequency bands, such as the S-band at 2483.5 to 2500 MHz and the C-band at 5010 to 5030 MHz. However, compared with L-band, the valid frequency spectrum allocated to navigation service in S- and C-bands is more limited, so that signals these bands can support are more limited. In addition, using these bands with higher frequencies will result in greater space transmission loss, greater phase noise, and greater Doppler shift.

Spreading Modulation Design
Spreading modulation is to a satellite navigation what scale is to a ruler. The most direct influence of the spreading modulation design is to adjust the signal spectrum shape in order to distribute the power of the signal to a specific frequency position. Research indicates that spreading modulation directly affects the receiving performance for a signal in thermal noise, interference, as well as multipath environments, and RF compatibility between signals in the same frequency band. Therefore, the optimization of the spreading modulation technique is considered one of the most important ways to realize spectrum compatibility and performance improvement simultaneously.

In the new generation GNSS, there are two new trends emerging in spread modulation design. Firstly, signal power distribution is changing from concentrating near the carrier frequency to a splitting spectrum form, which is represented by binary offset carrier (BOC) modulation. Research indicates that splitting spectrum characteristics result in a spectrum separation from legacy signals located at the same central frequency and a wide root mean square (RMS) bandwidth which results in the potential advantage of improved ranging accuracy and inherent multipath resisting ability. Secondly, in addition to bipolar waveforms, more and more multi-level spread modulation waveforms are emerging, such as that in Composite BOC (CBOC) and Alternative BOC (AltBOC) modulations. Relaxing the constraint of waveform level can provide greater freedom for spread modulation waveform optimization, thus providing more possibilities for improvement of the signal performance (Pratt and Owen, and Zhang et alia 2011, Additional Resources).

However, these two trends bring increased complexity to both the transmitter and the receiver. The larger RMS bandwidth of the splitting spectrum signal requires a higher subcarrier frequency, which means a wider receiver frontend bandwidth and the increment of complexity of the receiver. Although the sophisticated receiving strategy is acceptable for high-end applications such as surveying and mapping, the cost and complexity is hard to justify for low-end consumer electronics devices. A direct way to address this problem is by transmitting multiple signals from the satellite, providing high-end users with a wideband signal that uses a complex chip waveform, while allowing the low-end users to have a simple receiving strategy for a narrowband signal with a simple chip waveform. Unfortunately, the increment in the number of signals at the same frequency degrades the multi-access interference (MAI) between the system and the inter-system signals, which leads to deterioration in the receiving performance. Furthermore, the increase in the number of signals and the complexity of the signal waveform pose a challenge to constant envelope multiplexing, which is another critical part of satellite navigation signal design.

Multiplexing
Signal multiplexing refers to the technique of combining multiple different signal components into one signal over a shared transmitting chain. It is not widely treated in most GNSS interface control documents (ICDs) but is the basis for a variety of PNT services for today and the future. Due to the limitation in GNSS transmitting power and the nonlinearity of the amplifier, multiple spreading signals should share a carrier frequency and multiplex into a composite signal with a constant envelope in the signal transmitter.

In the constant envelope multiplexing on the navigation satellite, as the number of multiplexing signals increases, more inter-modulation terms power should be added to keep the envelope of multiplexed signal constant. Since the information carried on inter-modulation terms is redundant for a receiver, the higher proportion of inter-modulation terms mean the less useful power output, which is expressed as a lower multiplexing efficiency, thus reducing the received carrier to noise ratio (CNR). Though increasing the transmitting power can compensate for the multiplexing loss, it will further deteriorate MAI between the system and the inter-system signals.

A Gordian Knot
Under the conventional idea of separately optimizing carrier frequency, spreading modulation, and multiplexing, a Gordian knot is emerging in future GNSS signal design. As shown in Figure 2, in the independent design of these three key elements, it is difficult to reconcile the contradictions among service diversity, ranging accuracy, receiving complexity, radio frequency (RF) compatibility and multiplexing efficiency.

Users always want signal ranging performance to be as high as possible while the receiving complexity is as low as possible. However, one cannot have both at the same time. The most straightforward way to cope with the high-performance demand is to increase the signal bandwidth, and moving the main spectrum component of signal away from the carrier frequency. However, since there are almost no contiguous segments of unoccupied spectrum remaining in the upper L-band, increasing the signal bandwidth will aggravate spectral interference between the new signal and existing signals. Furthermore, a wider signal bandwidth and complex subcarrier structure also result in a higher processing burden on receivers, which is unacceptable by low-end users. The direct way to further support low-end users is to add more narrowband signals with simple structures. Nevertheless, increasing signal numbers not only further increases spectrum interference, but also further reduces the power efficiency of multiplexing. That means the useful signal power is reduced, and also that the interference is increased. As a result, although the original intention is to improve the overall performance, the actual effect is to degrade the performance of each signal component.

In order to get out of the cycle of contradictions among measurement accuracy, services variety, RF compatibility, as well as multiplexing efficiency in satellite navigation signal design, it is necessary to break the routine.

Our inspiration is attributed to Vernier caliper, which combines two rulers with different scales together. In principle, each scale can be used independently as a simple ruler. However, based on the difference between scale divisions of these two rulers, when we use these two scales jointly in a proper way, we can obtain a higher measurement accuracy. Along the way, in navigation signal design, when we re-examine carrier frequency, spreading modulation, and multiplexing these three key elements as a whole, we find a solution to cut the Gordian knot: the multicarrier constant-envelope composite (MCC) signal.

Multicarrier Constant-Envelope Composite Signal
The concept of multi-carrier signals originates from the field of wireless communications. Typical multicarrier communication signals include multi-tone signals, orthogonal frequency division multiplexing (OFDM) signals, and multicarrier code division multiple access (MC-CDMA) signals. However, the satellite navigation signal has two major differences compared with the communication signal: First, the core mission of the navigation signal is the high accuracy time of arrival (TOA) estimation but not the data transmission. The TOA estimation processes based on multi-carrier communication signals, such as OFDM signal, are complex (See Thevenon et alia, Additional Resources) and the inherent high RMS bandwidth performance advantage of multi-carrier signals is difficult to be adequately brought into play. Second, the vast majority of existing multi-carrier signals have a high peak-to-average ratio (PAR), which hinders their application for satellite transmission (See Mateu et alia, and Emmanuele et alia, Additional Resources).

Unlike the above-mentioned multicarrier communication signals, as shown in Figure 3, the proposed MCC signal is like a “spectral transparent adhesive”. It “glues” a plurality of narrowband signal components located in multiple spectral gaps together to form a wideband constant envelope signal, sharing a common up-converter, amplifier chain and antenna aperture. The core features of the MCC signal are:

• Sparsity in the frequency domain;
• Envelope constancy in the time domain; 
• High flexibility on design elements such as the number of sub-bands, sub-band frequency spacing, the number of signal components in each sub-band, shape of the spreading waveform, the power ratio and relative phase of signal components; 
• Transparency of the compositing to the receiver.

Compared with existing solutions, the MCC signal has the following unique advantages:

On the one hand, multicarrier is one of the most effective ways to utilize spectrum gap resources. As previously mentioned, in the increasingly crowded satellite navigation band, the absolute bandwidth of the newly added signal is severely limited. There are only some scattered frequency fragments available between main lobes of existing signals, as illustrated in Figure 3(a). However, the frequency difference between signal components in different sub-bands of the multi-carrier signal can transform this unfavorable factor into a favorable one. As illustrated in Figure 3(b) and (c), placing multiple sets of narrowband signals components in the fragment band gaps and combining them into a wideband constant envelope signal can construct a MCC signal. The spectrum sparse characteristic of such signal can not only ensure adequate spectral separation with existing signals in the same band, but also provide a large RMS bandwidth for better ranging performance, resulting in solving the contradiction between spectral efficiency and ranging performance.

On the other hand, the different narrowband components in the MCC signal can be optimized for targeted PNT services, with different spreading sequences, different spreading waveforms, different power allocations, and different data message structures and contents, to meet future diversified PNT requirements. At the same time, in MCC signals, those components are combined into a whole signal by constant envelope multiplexing that is “transparent” enough for receivers, not only allowing narrowband receivers to process each component separately with low-complexity, but also allowing wideband receivers to process the total or partial components of this signal with a wide RMS bandwidth. That is, the MCC signal has innate features of diversified receiving and processing strategies, which addresses the contradiction between power efficiency and service diversity.

In addition, the integrated structure of the MCC signal ensures a strong correlation between the transmission channel effects of each sub-band component, which creates conditions for joint processing of components in multi sub-bands, such as joint acquisition, joint tracking, and joint pseudorange extraction.

Given the above, a MCC signal can not only achieve outstanding ranging accuracy without significantly increasing the RF interference to the existing signals in the same band, but also provide users with diversified and targeted service without noticeably deteriorating the multiplexing efficiency onboard the satellite. It provides a promising technique solution for the next generation GNSS signal design.

Construction of a MCC Signal Based on the CEMIC Method
The key to the MCC is determining how to combine several flexible signals located at multiple different central frequencies with arbitrary power, chip rate, and spreading waveform into an integral signal with a constant envelope. In the field of satellite navigation signal design, the study of constant envelope multiplexing has long focused at single-frequency cases. Although there are some dual-frequency constant envelope multiplexing methods, such as those described by Lestarquit et alia, Yao et alia 2016 and Zhang in Additional Resources, few of them can support multiplexing for more than two sub-bands. Moreover, the vast majority of existing constant envelope multiplexing techniques are only applicable under strict pre-conditions in the component waveform shape, component number, component power ratio and phase relationship, which is not suitable for the proposed conception of using multiple spectral gaps to carry diversified services.

The recent emergence of a high efficiency generalized multicarrier joint CEM technique for multilevel spreading signals, termed CEM via intermodulation construction (CEMIC), as described by Yao et alia 2017a in Additional Resources, presents the possibility for the realization of a MCC signal. Compared with existing CEM techniques, CEMIC has a much higher design flexibility in the number of sub-bands, the number of signal components, power ratio and phase relationship among components, and the shape of spreading chip waveforms. CEMIC can be applied to any number of bipolar or multilevel spreading spectrum signals with arbitrary power distribution at one or more subcarrier frequencies. Such a high degree of design flexibility provides system designers great room in signal scheme optimization for varied navigation applications in the future.

In this section, based on the design theories presented in Yao et alia 2017a, and Yao et alia 2017b, Additional Resources, an implementation technique of MCC with extremely high design flexibility is presented.

Consider combining N spreading spectrum signal components located at several sub-bands, s_i(t), for i = 1 = N , into a composite signal with constant envelope. In principle, there is no constraint on the spreading code rate and spreading waveform shape for each s_i(t). However, for simplicity, here we assume that all of the s_i(t) are MCS signals with the same code rate T_c, and every MCS symbol is divided into M segments with equal length T_s = T_c/M. More general cases can be found again in Yao et alia 2017. Then can be mathematically expressed as

Equation (1) (see inset photo, above righ, for all equations)

where c_i is the navigation data modulated by the corresponding spreading code, p_i is the waveform value in k-th segment, and ψ(t) is unit amplitude rectangular pulse function with T_s duration.

Define f_i as the frequency offset of the subcarrier of s_i(t) from the carrier frequency f₀, the selection of which depends on the specific location of spectral gaps. For the convenience of digital implementation, the subcarrier waveform can choose the sample-and-hold version of the complex sinusoid waveform

Equation (2)

where Δf_i = f_iT_s. Since for all of the deployed GNSS signals, the carrier frequency, the spreading chip rate, as well as the subcarrier rate are all the multiple of 1.023 megahertz, by choosing the proper values of T_c, f_i, and M, it is easy to ensure that ΔT_i = 1 / Δf_i is an integer. That means the signal component modulated by the subcarrier is still a MCS signal. 

Directly combining these N signal components into a multicarrier composite signal is mathematically equivalent to constructing a new baseband signal, of which the complex envelope is

Equation (3)

where c̃_i[m] = c_i[n]p_i[k] e^j2πΔf_im with n = [m T_s/T_c] and, k = [(mT_s − nT_c)/T_s], P_i and θ_i are the power allocation and initial phase of i-th component respectively.

It can be seen from the above equation that s_MUX(t) is also a MCS signal with segment length T_s, and in every duration t[m] ∈ [mT_s,(m+1)T_s) , its value is fixed to

Equation (4) 

In general, the MCS waveform may have multi amplitude levels. For simplicity, assume that every p_i has up to K different possible values, while every sample-and-hold version subcarrier waveform has up to ΔT_i different values. Then s_MUX(t) has a maximum of

Equation (5)

possible complex values, resulting in the temporal fluctuation of the envelope. In order to keep the envelope of the multicarrier composite signal constant, the basic idea of CEMIC is adding an additional component I_IM(t) to s_MUX(t) to compensate for the envelope fluctuation. This additional component can be referred to as the intermodulation (IM) term. In every time period t[m] ∈ [mT_s, (m+1)T_s], the value of I_IM(t) is determined by the value of s_MUX(t[m]), to ensure the composite signal s_CE(t) = s_MUX(t) + I_IM(t) is a constant envelope signal. As pointed out in Yao et alia 2012, this is equivalent to finding an amplitude mapping rule f: {c̃₁, c̃₂, …, c̃_N} ↦ I_IM, that gives values to the IM term for each of the F combinations of values of c̃_i, to make the envelope of the superposed signal be constant. 

If only the envelope constancy of s_CE is constrained, then an infinite number of mapping rules can be used. However, since the IM term I_IM(t) is only used to maintain the constancy of signal envelope, from a receiving power efficiency standpoint, its proportion should be as low as possible in the whole composite signal, and its influence on receiving performance should be as small as possible. The core of CEMIC is to find an optimal mapping rule, which constructs an IM term that can guarantee the optimal power efficiency, minimal impact on the correlation characteristics of useful components, and the envelope constancy of the composite signal.

Generally, using CEMIC to construct a MCC signal has the following four main steps:

1) According to T_c, f_i, M, and the shapes of p_i, for i = 1 = N, list all F possible combinations of values of {c̃₁, c̃₂, …, c̃_N}, and construct the component weight vectors

c̃_i = [c̃_i⁽¹⁾, c̃_i⁽²⁾, …, c̃_i^(F)]^T     (6)

for i = 1 = N, where c̃_i^(ℓ) is the value of c̃_i in the ℓ-th combination. Note that, in order to distinguish from the time index that is in square brackets, here the combination index is put in parentheses. 

2) Based on component weight vectors c̃₁, c̃₂, …, c̃_N using the Gram-Schmidt orthogonalizing method or other methods, construct a set of orthogonal vectors {g₁, g₂, …, g_F-N} to make span{g₁, g₂, …, g_F-N} be the orthogonal complement space of {c̃₁, c̃₂, …, c̃_N}. A general construction algorithm for this step is given in Appendix A of Yao et alia 2017. However, if all of p_i are bipolar, a much simpler direct construction method proposed in Zhang et alia 2012, Additional Resources can also be available.

Define
s_CE = Cr + Gw, where C = [c̃₁, c̃₂, …, c̃_N], G = [g₁, g₂, …, g_F-N], and r = [√P₁e^jθ₁, √P₂e^jθ₂, …, √P_Ne^jθ_N]^T and solve the following constraint minimization problem

Equation (7) 

to obtain the optimal coefficient vector w, where s^(ℓ)_CE is the ℓ-th entry of s_CE. 

Let λ = Gw = [λ⁽¹⁾, λ⁽²⁾, …, λ^(F)]^T. Then we obtain the optimal mapping rule from the value combination of N signal components to the IM term I_IM(t). In every moment, if the values of {c̃₁, c̃₂, …, c̃_N(t)} correspond to the ℓ-th value combination, I_IM(t) takes the value λ^(F), and s_CE(t) = s_MUX(t) + I_IM(t). 

Case Study of Adding a MCC Signal in L1 Band
As a sample application, consider adding a new MCC signal in the L1 band. Although current GNSSs do not have such a plan yet, through this specific example, one can clearly see the design process of a MCC signal, and the characteristics and advantages of this signal in both the transmitter and receiver.

As mentioned, the upper L-band has been overcrowded. All GNSSs broadcast their open and authorized service signals in this band. If a new wideband signal is added to this band, it will be hard to avoid significant spectrum overlapping with the existing signals. However, it is noted that most of the existing signals in this band have spectral nulls at 1575.42, ±4.092, ±8.184, and ±10.23 megahertz, etc. Thus, under the premise of ensuring good RF compatibility, a possible new signal solution is to place multiple narrowband components in these spectral gaps.

For simplicity, consider the case of multiplexing five narrowband components with BPSK-R(0.5) spreading modulation in this example. As shown in Figure 4, the center frequencies of these five components are set to 1577.466 MHz, 1579.512 MHz, 1581.558 MHz, 1583.604 MHz, and 1585.65 MHz, respectively. In the transmitter, the carrier frequency of the composite MCC signal can be 1581.558 MHz. Thus, the subcarrier frequencies of components are f₁ = –4.092 MHz, f₂ = –2.046 MHz, f₃ = 0, f₄ = 2.046 MHz, and f₅ = 4.092 MHz, respectively. Under the equal power assumption, r can be set to [1,1,1,1,1]^T. In this design case, considering the constraint of implementation complexity, M should not be too large. Here we take M = 8, the shortest segment length T_s = (32 °— 1.023e6)^–1 s.

The theoretical power spectral density (PSD) of these five narrowband components before the constant envelope reconstruction is shown in Figure 5(a). Following four steps of the CEMIC method presented in the previous section, the MCC signal is constructed, for which the theoretical and simulation PSDs are shown in Figure 5(b) and (c), respectively.

By comparing Figure 5(a) and (b), it is observed that after constant envelope reconstruction, the PSD of the MCC signal is different from that of the direct superposition of these five components. The difference is mainly reflected in the appearance of the IM term in MCC signal. It can be seen that the power of the IM term is much lower than that of the useful signal components, and the difference is at least 10 decibels. In fact, the multiplexing efficiency of this example is 80.41%. That is, the newly added IM term accounts for only 19.6% of the total signal power, and its spectrum is distributed far away from the carrier center frequency.

Figure 6 shows the modulation constellation of the MCC signal. As illustrated in the figure, all the phase points are distributed on a circle. This feature enables the payload high power amplifier (HPA) to operate in its full-saturation mode to maximize power conversion efficiency.

RF Compatibility Analysis
To evaluate the RF compatibility between the newly added MCC signal and the existing BPSK-R(1), MBOC(6,1,1/11), BPSK (10), as well as BOC (10,5) signals in the same frequency band, we calculate their spectral separation coefficient (SSC). The receiver front-end filter is assumed to center on 1575.42 MHz, with a single side bandwidth of 12 megahertz, which is sufficient to cover the highest frequency component of the MCC signal. Table 1 shows the SSC of the existing signals with MCC signal.

It can be seen that the MCC signal maintains good RF compatibility with the existing signals by effectively utilizing the fragment band gaps between the main lobes of existing signal spectrum. It can be verified that if more sub-bands are employed, or moving f₅ from 1575.42 + 10.23 MHz to 1575.42 + 12.276 MHz, the RF compatibility between MCC signal and the BOC(10,5) signal can be further improved.

Diversified Processing Strategies
As previously mentioned, in addition to the effective utilization of the spectrum resource, another key advantage of the MCC signal is that it inherently has multiple receive modes, providing a variety of processing strategies for receivers with different performance and complexity constraints.

Since the MCC signal is composited in the digital baseband, the subcarrier phase of each component is completely coherent, and components within the MCC signal pass through the same transmission channel, the errors introduced by thermal noise, multipath, as well as the dynamic stress also have strong correlation. The receiver can either treat these signal components separately, or jointly process multiple components or even the entire composite signal as a whole.

The simplest processing mode is treating the narrowband components in the MCC signal as different signals. Such a processing mode requires minimal processing complexity. If narrowband components employ BPSK-R spreading modulation, as discussed in this example, their acquisition and tracking methods can be directly inherited from the traditional cases, where both the rectangular pulse spreading chip and the sinusoidal subcarrier waveforms can be employed in the local replica. The cross-correlation function (CCF) between the received MCC signal and the local replica of each signal component in this processing mode is shown in Figure 7(a).

If the receiver jointly processes three signal components, which are s₂(t), s₃(t), and s₄(t), without loss of generality, the local replica can be

s_local(t) = s₂(t)e^j2Πf₂t + s₃(t) + s₄(t)e^j2Πf₄t     (8)

The CCF between the received MCC signal and this local replica is shown in Figure7(b). 

Further, the whole MCC signal can even be used as the local replica to realize the matching receiving, for which the CCF is shown as Figure 7(c).

In order to quantitatively compare the performance of above three processing modes, equivalent Gabor bandwidth, correlation loss, and average multipath error envelope are used as evaluation indexes to measure the code tracking accuracy, the performance of acquisition and demodulation, and the multipath resisting performance, respectively.

Figure 8(a) and (b) show the equivalent Gabor bandwidth and the correlation loss of these three processing strategies with respect to the front-end double-sided bandwidth, respectively. Figure 8(c) shows the average multipath error envelopes of these three processing strategies, with front-end double-sided bandwidth of 10 megahertz, and multipath-to-direct ratio (MDR) of –5dB.

One can see from Figure 8 that in different processing strategies, the receiving performance presents an obvious graded characteristic. With a narrow bandwidth, the single-component processing mode has the minimum processing complexity, but the largest correlation loss and the lowest ranging accuracy. However, as an increasing number of components are processed jointly, for wideband receivers, not only is the correlation power loss decreased, but also a higher ranging accuracy as well as a better multipath resisting ability can be obtained. That means the innate multiple processing strategies of the MCC signal can provide different tradeoffs between performance and processing complexity to different PNT application requirements. With MCC signals, receivers can obtain various levels of receiving performance by jointly processing different subsets of signal components. This is one of the major advantages of the MCC signal.

Processing Mode Switching
The inherent multi-strategy processing advantage of MCC signal can be taken not only by different types of receivers, but also in different stages of a wideband receiver. The MCC signal allows the receiver to dynamically switch the processing strategy at different processing stages, according to the current working status to achieve balance between processing complexity and accuracy.

From Figure 7, it can be seen that the main peak of CCF under the single-component processing mode is the widest, which can widen the acquisition bins and provide an unambiguous large pull-in range to the tracking loop. As more components are jointly processed, the energy of the CCF increases significantly, and the main peak of the CCF becomes sharper, which implies higher potential tracking accuracy. However, more side peaks appear on both sides of the CCF main peak.

One possible strategy for a wideband MCC signal receiver is using the single-component processing mode in the initial acquisition and pull-in phases, utilizing the wide CCF main peak to obtain a wider search step and a larger pull-in range. After the tracking loop is stabilized, three- and five-component joint processing can be employed incrementally, gradually gaining higher signal-to-noise ratio and sharpening the CCF peak to obtain higher tracking accuracy.

The switching strategies of the processing mode of MCC signals are not limited to this simple mode. In fact, the multi-component multi-subcarrier structure of the MCC signal provides the possibility for the future receivers to explore the diverse switching strategies.

Selective Availability
Since the multiplexing used in MCC signal construction is sufficiently flexible, different signal components in the MCC signal can be configured with different pseudorandom (PN) codes and different spreading modulation waveforms, and can be modulated with different data messages. Therefore, the service provider can assign different codes and messages to different signal components, controlling the access permissions and providing selective performance to different user levels. The receiver selects the corresponding processing mode according to its own privilege level and thus obtains the available acquisition, tracking, and demodulation performances.

For example, as shown in Figure 9, in the five-component design case provided in this section, s₃(t), which is located on the carrier frequency, can be assigned to be the open access signal, of which the PN code generation method and the data message structure are fully open. All receivers can access this component with the single-component processing mode, thus obtaining a relatively low signal-to-noise ratio, and a basic ranging accuracy level.

Components s₂(t) and s₄(t), which are with relatively low subcarrier frequencies, can be assigned as the secondary authorized signals. Their PN code generating information and data message structures are only provided to the authorized secondary users. These users can access three components, so that multi-component joint processing and dynamical mode switching strategies can be used to obtain the improved performance.

Components s₁(t) and s₅(t) can be assigned as senior authorized signals, with encrypted PN codes and data message structures, serving authorized senior users. Senior authorized receivers can access all the five components, to obtain the most diversified processing strategies, the highest signal-to-noise ratio, and the highest ranging performance.

In addition, if the data structures of different components are well-designed to carry complementary messages — for authorized users who can access multiple components — the time to first fix (TTFF) can be effectively reduced. In theory, the TTFF of a receiver that jointly processes five components can be shortened by 80% over that of the basic single-component receiver.

The case study in this section demonstrates that the MCC signal has a high degree of flexibility in both the broadcasting strategy and the receiving strategy. There are many more possible broadcasting and receiving modes of MCC than those discussed in this example. In fact, this signal structure offers a wide design space for both the system providers and the receiver developers in future.

Conclusions
As a significant infrastructure, GNSS has a long development cycle. This characteristic means that we can only employ existing techniques to meet the demands over the next few decades. Although it is impossible to envision GNSS products and services further out in time, we can enable future development by implementing excellent signal designs with higher adaptability and flexibility.

The contradiction between the need for performance improvement and the fact that power and spectrum resources are limited will be more serious in the next generation of GNSS signal designs. In order to solve this contradiction, this article first proposes the concept of a multi-carrier constant envelope signal, and studies its feasibility as the next generation satellite navigation signal. A corresponding design method based on the CEMIC technique is given, and an example is presented to demonstrate the RF compatibility, typical receiving strategies, corresponding performances and selection availability of MCC signals. The analyses show that the MCC signal can make full use of the existing spectrum resources, providing both various broadcast strategies and multiple receiving strategies with a variety of performance levels for different categories of users. This technique can serve as a practical new solution to the next generation satellite navigation signals design.

Acknowledgment
This article is based on a presentation given by the first author at the ION GNSS+ 2017 conference on September 27-29, 2017, hosted by the Institute of Navigation in Portland, Oregon, USA. This work is supported by National Natural Science Foundation of China (NSFC), under Grant 61771272.

Additional Resources
[1] Avila-Rodriguez, J.-A., S. Wallner, G. W. Hein, B. Eissfeller, M. Irsigler, and J.-L. Issler, “A vision on new frequencies, signals and concepts for future GNSS systems,” in Proceedings of the 20th International Technical Meeting of the Satellite Division of The Institute of Navigation, Fort Worth, TX, 2007, pp. 517-534.
[2] Emmanuele, A., et alia., “Evaluation of Filtered Multitone (FMT) Technology for Future Satellite Navigation Use,” Proceedings of the 24th International Technical Meeting of the Satellite Division of the Institute of Navigation (ION GNSS 2011), pp. 3743-3755, 2011.
[3] Irsigler, M., G. W. Hein, and A. Schmitz-Peiffer, “Use of C-Band frequencies for satellite navigation: benefits and drawbacks,” GPS Solutions, vol. 8, no. 3, pp. 119-139, 2004.
[4] Lestarquit, L., G. Artaud, and J.-L. Issler, “AltBOC for Dummies or Everything You Always Wanted to Know About AltBOC,” presented at the ION GNSS 2008, Savannah, GA, US, 2008.
[5] Mateu, I., et alia., “A search for spectrum: GNSS signals in S-band, part 2,” Inside GNSS, vol. 2010, no. October, pp. 46-53, 2010.
[6] Pratt, A. R. and J. I. Owen, “BOC modulation waveforms,” in Proceedings of the 16th International Technical Meeting of the Satellite Division of the Institute of Navigation, ION-GPS/GNSS-2003, 2003, pp. 1044-1057.
[7] Thevenon, P. et alia, “Pseudo-Range Measurements Using OFDM Channel Estimation,” (in English), Proceedings of the 22nd International Technical Meeting of the Satellite Division of the Institute of Navigation (ION GNSS 2009), pp. 481-493, 2009.
[8] Yao, Z., J. Zhang, and M. Lu (2016), “ACE-BOC: dual-frequency constant envelope multiplexing for satellite navigation,” IEEE Transactions on Aerospace and Electronic Systems, vol. 52, no. 1, pp. 466-485, 2016.
[9] Yao, Z., F. Guo, J. Ma, and M. Lu (2017a), “Orthogonality-based generalized multicarrier constant envelope multiplexing for DSSS signals,” IEEE Transactions on Aerospace and Electronic Systems, vol. 53, no. 4, 2017.
[10] Yao, Z., and L. Mingquan. (2017b) Signal Multiplexing Techniques for GNSS: The principle, progress, and challenges within a uniform framework. IEEE Signal Processing Magazine.
[11] Zhang, X. M., X. Zhang, Z. Yao, and M. Lu (2012), “Implementations of Constant Envelope Multiplexing based on Extended Interplex and Inter-Modulation Construction Method,” (in English), Proceedings of the 25th International Technical Meeting of the Satellite Division of the Institute of Navigation, pp. 893-900, 2012.
[12] Zhang, X., Z. Yao, X. Zhang, and M. Lu (2011), “A Method to Optimize the Spreading Code Chip Waveform in Sense of Gabor Bandwidth,” in Proceedings of the 24th International Technical Meeting of The Satellite Division of the Institute of Navigation (ION GNSS 2011), 2011, pp. 1299-1304.
[13] Zhang, K., “Generalised constant-envelope DualQPSK and AltBOC modulations for modern GNSS signals,” Electronics letters, vol. 49, no. 21, pp. 1335-1337, 2013.

The post Spectral Transparent Adhesive appeared first on Inside GNSS - Global Navigation Satellite Systems Engineering, Policy, and Design.

The post Figure 1: How Effective Are Signal Quality Monitoring Techniques? appeared first on Inside GNSS - Global Navigation Satellite Systems Engineering, Policy, and Design.

GNSS SDRs are a rapidly advancing area in GNSS receiver research and design. The last few years have brought tremendous growth in this field. Universities and other research institutions have developed and demonstrated advanced capabilities, particularly with respect to multi-constellation GNSS and GNSS-plus-multi-sensor navigation processing for challenging environments. The recent commercial availability of multi-sensor data collection equipment, development platforms and open-source software projects have catalyzed this rapid pace of innovation. Indeed, SDR will likely become a significant commercial GNSS receiver architecture by the end of this decade due to today’s ongoing deployment of multiple global and regional satnav constellations with their diverse signal structures, and rapid advancements in parallel low-power processors and inexpensive sensors.

Non-realtime SDR operational scenarios involve storage and post-processing of samples. These sampled data files can also be used in radio frequency (RF) playback systems for GNSS receiver test and evaluation in the lab. Post-processing and/or playback requires several generic front-end parameters such as RF and intermediate frequency (IF) center frequencies, sample rate, file format, as well as GNSS-specific information such as antenna location and type. We define this information as GNSS SDR metadata. Manual transfer of metadata is the method predominantly used today – a process that is cumbersome and error prone to say the least. No established method exists to exchange this metadata automatically.

During the ION GNSS+ 2013 conference, a group of attendees discussed the need for a formal standard for the exchange of GNSS SDR metadata. This group identified the following benefits of engaging in this activity at the present:

• It identifies and brings the international GNSS SDR community together as a working group. This collaboration is critical in order to get broad acceptance and usage.
• Standardization will help to avoid technology segmentation issues while promoting the pace of innovation by standard practices and compliant tools. 
• The formal standard, if widely adopted, will help ensure compatibility and interoperability of future GNSS SDRs. Specifically, front-end agnostic “plug-and-play” SDRs are envisioned. These have the potential for revolutionizing positioning, navigation, and timing (PNT) systems of the future.

Most authors of significant GNSS SDR publications and contributions over the past two decades are ION members and frequent meeting attendees. Hence, we decided to pursue this standard through ION sponsorship. During the January 2014 Council Meeting in San Diego, ION approved the process for establishing a formal standard. The ION GNSS SDR Metadata Working Group (WG) was formed in April 2014. Membership represents academia, industry (including GNSS SDR product vendors as well as traditional GNSS equipment manufacturers), non-profit research entities, and government agencies spanning countries in America, Europe, Asia and Australia.

Justification for GNSS Metadata Standardization
Figure 1 (see inset photo, above right, for all figures) shows the metadata transfer scheme mainly used in today’s GNSS SDR systems. The top row depicts data collection system (DCS) A, producing an SDR file of format A, consumed by SDR processor A. This may represent an end-to-end solution provided by a vendor or a system that was initially developed around a specific hardware platform. In any case, assume that the metadata for decoding Format A is hard-coded into the processor. Consequently, supporting other file formats involves extensive software revisions on a case-by-case basis. One group may want to share SDR files from DCS A with other groups using SDRs X and Y for research collaboration. This involves conveying the file format and other relevant information accurately to these other groups. Today, this metadata transfer occurs in an ad-hoc way that is prone to interpretation errors.

The second row depicts multi-stream DCS B that produces files with a more complicated format. SDR processors X and Y represents more flexible SDRs that are able to support multiple file formats. However, the data/metadata association requires manual intervention.

DCS C multiplexes other data (such as sensor data) along with multiple GNSS sample streams in the same file. This type of multiplexed collection has the potential to become more common with emerging SDR-related data streaming standards such as VITA-49 (See T. Cooklev et alia, Additional Resources). In this case, custom-designed processor C represents an SDR that fully supports multi-sensor integration capabilities. Because DCS C’s GNSS stream parameters are open, SDR Y is also able to support GNSS-only processing using an ad-hoc metadata transfer scheme. The sensor data parameters in Format C may or may not be open.

As clear from Figure 1, today’s ad hoc methods of metadata exchange do not encourage interoperability and instead cultivates potential for technology segmentation (i.e., various groups developing their own stove-piped solutions and technologies).

Figure 2 shows the same systems of Figure 1 that have adopted a metadata standard. As shown, each DCS produces a compliant metadata file along with the SDR file. The metadata file is read-in by the compliant SDR processor to correctly decode and process files seamlessly.

Adoption of a metadata standard benefits DCS developers because their systems become applicable to a much wider group of users. Similarly, an SDR processor’s utility is extended when it is capable of supporting many file formats from multiple sources seamlessly. Thus, metadata standardization promotes interoperability of GNSS SDR systems and greatly simplifies the exchange of files between groups.

Metadata standardization also benefits other use cases beyond post-processing GNSS SDRs. For example, consider the use of the metadata specification to synthesize compliant SDR files for use in RF playback systems. Additionally, libraries of compliant SDR file sets containing various real-world scenarios could be used interchangeably in compliant RF playback simulators for repeatable and consistent testing of GNSS receivers.

SDR Data Collection Topologies
The ION Executive Committee stipulated that this standardization activity shall not create an unfair advantage or disadvantage to any entity. Specifically, the standard shall not require any existing system to undergo data format changes to achieve compliance. This “do no harm” stipulation implies that the standard be designed such that it supports all current and future SDR file formats. This also means that the WG must “get it right the first time” since major revisions to the standard would be undesirable and adverse to the goal of widespread adoption. Hence, we considered the entire space of possible GNSS SDR data collection topologies. Figure 3 illustrates these topologies.

Figure 3.a illustrates the simplest data collection topology that can exist. This is when a single swath of RF spectrum (referenced henceforth as a “band”) is down-converted and sampled to produce a single data stream. The stream, which may be IF sampled (real samples) or baseband sampled (complex samples) is written to disk as a single file.

Figure 3b represents a DCS that writes parts of a single data stream across multiple files. This may be done to reduce the sustained write performance requirement of storage drives (similar to striping mode in RAID systems).

Figure 3.c is similar to Figure 3.a, except that the data stream represents more than one RF band. An example of this topology is a direct RF sampling front-end architecture that intentionally aliases multiple bands to fall next to each other at baseband. Some bands may be spectrally inverted as a result of the digital down-conversion process.

A DCS may produce multiple data streams. Each stream may contain information from one of many antenna elements (as shown in Figure 3.d, where each stream may also encompass multiple bands as in Figure 3.c). Alternatively, a stream may be sampling one of several bands received by a single wideband antenna, where the multiplexed streams written to file represents channelized samples. Combinations of the above are also possible.

Each stream may also be sampled at different rates and bit depths. For example, consider a civilian GPS L1, L2, L5 system. In this case, the L1 and L2 streams may be sampled at rate f₀ and the L5 stream at 10·f₀ (since the L5 signal’s null-to-null bandwidth is 10 times wider than L1 C/A and L2C), where f₀ represents the base sample rate. Figure 3.d may also represent how these multiple streams are multiplexed into a single lane of packed binary data and written to a single file.

Similar to Figure 3.d, Figure 3.e illustrates a GNSS data stream multiplexed with other data that is written to a single file. This non-GNSS SDR data may be from additional sensors (as shown), and may be written in a proprietary format that may or may not be known.

The specification of metadata parameters for non-GNSS data is outside the scope of the present standardization effort. However, the standard must support adequate information to skip over such non-GNSS data bytes. Since the metadata schema is extensible, it can cover the description of non-GNSS SDR data as needed by specific users.

It is important to note that although we use the term “GNSS SDR data” in this article to generally refer to the type of sampled data for which metadata parameters are defined in the standard, the samples need not correspond to GNSS frequency bands. For example, frequency bands containing RF signals of opportunity are supported as long as they can be represented by the standard’s metadata parameters.

Due to the typically high data rate of GNSS SDRs, some DCSs write data as temporally split files, as illustrated in Figure 3.f. This allows for efficient data management through multiple smaller files compared to a single large file. The metadata for each file must associate the previous and next files in order to represent the sequence. Note that the DCS block shown in Figure 3.f could represent any of those described in topologies a, c, d, and e of Figure 3.

Figure 3.g illustrates spatial splitting of files. Here, the binary data lanes from two or more DCSs are written to separate files. These files may be written by different computer systems. In this case, a non-zero inter-system timing offset, Δt, may exist and must be supported in the standard. Since Δt may or may not be known at time of collection, it represents an example metadata parameter that may be back-annotated into the metadata file after an initial pass of SDR data processing.

Multi-lane DCSs that write each lane to a separate file may also implement temporal file splitting according to 3.f. We call this “spatial-temporal splitting”, and is illustrated in Figure 3.h.

Since multi-stream-multi-file data collection topologies (i.e., (g) and (h) in Figure 3) produce multiple data files applicable to a given time interval, the SDR processor must be “introduced” to the full or partial set of lanes associated with the topology. This is covered by lane selection parameters in the standard.

Metadata Parameters
The metadata standard enables a user to specify a wide range of properties of the binary data file. Some of these properties relate to the data collection scenario itself, such as the time and location, and the type of scenario. Other properties of the dataset relate to the particular RF data that is captured as IF samples, including center frequency and bandwidth. Yet other details such as the IF digitization configuration and data packing can be specified. These are briefly summarized below. Some of the parameters are free-form text, others are integer or floating point variables, and others are enumerations. The primary classes are shown in Figure 4.

The metadata “session” class holds details such as the time, the position, the measurement campaign, and the type of scenario. The “file” class contains a path to the corresponding binary data file, time-stamp info, and a reference to the contained “lane” (described below). A “system” class contains details of the data recording equipment, such as the equipment name, the reference clock frequency, and the antenna details/specifications. The metadata standard allows for the specification of a variety of RF bands, each “band” class includes details of the band’s center frequency, intermediate frequency, bandwidth and group-delay bias.

The actual format of the binary data is detailed in the “lane” class, which allows for the specification of a hierarchy of binary data packing patterns, entitled “blocks”, “chunks” and “lumps”. These classes specify the arrangement of the packed IF data and optional additional data such as sensor measurements or configuration information, and further specify the arrangement of data relative to the standard word-sizes (arrays of byte, short integers, integers, long integers, etc.). The arrangement of the raw IF samples within these blocks is specified by the “stream” class. This class specifies the associated RF band, the sample rate, the quantization, the sample format (real/complex), the encoding of the binary data and the arrangement/alignment of the samples. Together these classes contain sufficient information to unambiguously interpret the packed binary data.

Normative Reference Software
The primary responsibilities of the Normative Reference Implementation Subcommittee are to reduce to practice the conceptual design developed through consensus by the WG into an appropriate set of schema (according to industry best practices) and to develop a compliant software library implementation. The WG was fortunate to receive voluntary participation for this task from individuals representing established commercial GNSS SDR vendors.

The WG decided to work on a publicly available reference software library to be released with the standard. The goal of this effort is to promote early and widespread adoption of the standard by making it easy for vendors and researchers to integrate standard-compliance by integrating the library into their existing software. The scope of this effort is twofold, to develop a metadata interpreter, and to develop a binary data converter using this metadata interpreter.

The first contribution was a library that would produce standard-compliant metadata files from an appropriately-populated data structure, a library capable of reading the content of such files back to a data structure. The second contribution was in the form of a library capable of parsing and converting binary IF data based on an associated metadata description. When combined, it is hoped that these two libraries offer sufficient functionality to enable adoption of the metadata standard in SDRs, or to serve as a benchmark against which implementations of the standard can be validated.

The software is written in C++ and managed using CMake. It has been divided into two libraries, “apilib” implementing the Metadata Interpreter and “converterlib” implementing the binary data conversion, and is accompanied by a selection of utilities, including a data-converter application and a simple test application. The software is available on the Institute of Navigation’s GitHub account here.

The Metadata Interpreter library includes a reader functionality that can parse a metadata file and populate a corresponding metadata object that can then be queried through a selection of member-function calls. Similarly, a metadata object can be instantiated and configured through a selection of member functions and, subsequently, it can be instructed to write a corresponding metadata file.

The converter library can be used for parsing binary data files and interpreting the data according to a metadata file. The basic converter can be adapted to support processing of the converted data streams, and two such adaptations have been implanted in the reference software. The first functionality is depicted in Figure 5, where the data-converter is embedded in a file-converter. The file-converter configures the embedded data-converter using a Metadata Interpreter object, and is capable of parsing a packed binary input file and producing one file per IF data stream in a user-specified data type (int8, int16, float, double, etc.).

A second functionality has been implemented by embedding the data converter in a “front-end”, as depicted in Figure 6. This front-end offers a means of loading short portions of the binary data file and converting them to a user-specified data type (int8, int16, float, double, etc.) while handling details such as sample alignment, when different streams are sampled at different rates.

The software suite includes a selection of example binary datasets and associated metadata files along with a simple MATLAB/Octave script to test the build against reference datasets. To date five different file formats have been included in the repository including a wide range of front-end configurations and data packing variations.

A number of working group members volunteered to perform “blind testing” of SDR data files against draft specifications. This involves exchanging SDR data files and associated metadata specifications among parties and verifying that the files can be fully decoded without additional information. Working group members participating in this activity will comprise the Compliance Verification Subcommittee.

SDR Data Repository
As with most standards and programming projects, they are best understood through good examples. Thus, this page has been created and contains several binary sample files together with metadata files. All file sets have been tested to follow the standard and to be readable by the normative reference software. The binary files typically contain samples over a duration of more than 60 seconds and position fixes have been obtained by at least one software receiver implementation.

Further examples will be added, not only emphasizing new data recording systems but also illustrating different SDR applications such as antenna arrays, reflectometry or ionospheric scintillation analysis. Further, data from GNSS seen only at certain locations of the Earth (e.g., Quasi-Zenith Satellite System [QZSS]) are being considered.

Organizations are encouraged to contact the working group if they have files with formats that are currently not adequately represented in the repository or represent use cases so far not considered. The respective point of contact is given on the web page. The working group will then take care of creating a metadata file (if not yet available), check the correctness and organize the upload.

Additional Resources
[1] Cooklev, T., R. Normoyle, and D. Clendenen, “The Vita49 Analog RF-Digital Interface,” IEEE Circuits and Systems Magazine, Q4 2012.
[2] Favenza, A., and N. Linty, “Exploiting Standardized Metadata for GNSS SDR Remote Processing: a Case Study”, ION GNSS+ 2016, Portland, Oregon (USA), 09/2016.
[3] Lucas-Sabola, V., G. Seco-Granados, J. A. López-Salcedo, J. A. García-Molina, M. Crisci, “Cloud GNSS receivers: New advanced applications made possible”, Proc. Int. Conf. Localization GNSS (ICL-GNSS), pp. 1-6, 2016.
[4] Lucas-Sabola, V., Seco-Granados, G., López-Salcedo, J.A., García-Molina, J.A., Crisci, M., “Demonstration of Cloud GNSS Signal Processing,” Proceedings of the 29th International Technical Meeting of The Satellite Division of the Institute of Navigation (ION GNSS+ 2016), Portland, Oregon, September 2016, pp. 34-43.

The post GNSS SDR Metadata Standard appeared first on Inside GNSS - Global Navigation Satellite Systems Engineering, Policy, and Design.

Return to main article: "Location Privacy Challenges and Solutions"

The post Figures 1 – 6: Location Privacy Challenges and Solutions appeared first on Inside GNSS - Global Navigation Satellite Systems Engineering, Policy, and Design.

Return to main article: "A Fresh Look at GNSS Anti-Jamming"

The post Figures 5, 6, 7 & 8: A Fresh Look at GNSS Anti-Jamming appeared first on Inside GNSS - Global Navigation Satellite Systems Engineering, Policy, and Design.

Return to main article: "A Fresh Look at GNSS Anti-Jamming"

The post Figures 1, 2, 3 & 4: A Fresh Look at GNSS Anti-Jamming appeared first on Inside GNSS - Global Navigation Satellite Systems Engineering, Policy, and Design.

Return to main article: “Consumer Mass Market Accelerometers for GNSS Anti-Spoofing”

The post Figures 13, 14 & 15, Table 1: Consumer Mass Market Accelerometers for GNSS Anti-Spoofing appeared first on Inside GNSS - Global Navigation Satellite Systems Engineering, Policy, and Design.