RINEX is is a data interchange format for raw satellite navigation system data. This allows the user to post-process the received data to produce a more accurate result — usually with other data unknown to the original receiver, such as better models of the atmospheric conditions at time of measurement. RINEX is the standard format that allows the management and disposal of the measures generated by a receiver, as well as their off-line processing by a multitude of applications, whatever the manufacturer of both the receiver and the computer application. (Wikipedia)

The IGS characterizes RINEX Version 4 as a necessary step to support the modern multiGNSS navigation messages by introducing and defining navigation ‘data records’ to hold both individual satellite navigation messages, constellation-wide parameters and global parameters as transmitted by the different GNSS constellations.

RINEX 4.00 is a major revision of the format document to modernize the Navigation message files to be able to accommodate the new navigation messages from all the GNSS constellations, and system data messages such as; ionospheric corrections, earth orientation parameters and system time offsets. The Observation file format remains the same with some added QZSS signals and tracking codes to fully support the upcoming L1 C/B signal. The Meteo file format also remains the same. All RINEX file types also have new optional header lines to support FAIR data usage; Finding, Accessible, Interoperable and Reusable data.

For more information, see the RINEX page on the IGS website. Image above courtesy IGS.

The post RINEX 4.0 Announced appeared first on Inside GNSS - Global Navigation Satellite Systems Engineering, Policy, and Design.

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.

The NationalSpace-Based Positioning, Navigation, and Timing (PNT) Advisory Board urged opposition to the proposal saying that even if the transmissions’ power was lowered to just under 10 watts it “will create totally unacceptable interference for a great number of GPS users in the United States.”

Ligado Networks declined a request for comment.

Ligado has two bands, licensed now for satellite use, located particularly close to the GPS frequencies. The company and its predecessor LightSquared have been trying since 2010 to convince the Federal Communications Commission (FCC) to allow the frequencies to also be used for terrestrial communications, including for the Internet of things (IoT). To ease opposition from the GPS community and a host of GPS users Ligado pledged not to use the 1545-1555 MHz band for terrestrial applications and said in May it would lower the power in its proposal for the 1526-1536 MHz band to 9.98 dBW to avoid interference with certified aviation receivers.

In a draft letter unanimously approved Monday to be sent to the co-chairs of the

National Executive Committee (ExCom) for Space-Based PNT — a multi-agency body that helps steer GPS policy — the Advisory Board urged the ExCom to oppose Ligado’s amended proposal.

The ExCom will decide whether or not to agree with the recommendation and send its decision to the National Telecommunications and Information Administration (NTIA). NTIA will convey the government’s perspective to the FCC, its commercial sector counterpart. In 2012, after the ExCom and the NTIA came out in opposition to LightSquared’s proposal, the FCC put the project on indefinite hold.

Board co-chair Brad Parkinson said in an analysis presented during the meeting that protecting 90 percent of the high precision GPS receivers within 100 meters of a tower would require the firm lower the power of the signal to 0.00022 watts. Alternatively, he said, the firm could place the towers further from each other. Protecting 90 percent of GPS high precision receivers, for example, would require spacing the terrestrial towers more than 12.5 miles (20.5 kilometers) apart, based on test results from the Adjacent Band Compatibility Assessment done by the Department of Transportation. (See chart above). Studies have shown that high precision receivers are the most susceptible to this type of interference.

Parkinson pointed out that his analysis looked only at a single tower and not at the additional possible interference caused by multiple towers.

The post GPS Experts Vote Unanimously to Oppose Ligado’s Newest Proposal 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.

It is important, therefore, to ensure satellite orbit calculations are as accurate as possible. As discussed in this article, Earth rotation plays a key role in this regard but surprisingly few references on orbit calculation actually mention its affect explicitly or how to compensate for it. Don’t fret, however, the correction is certainly applied or positioning accuracy would be much worse than is currently attained.

Reference Frames

Earth rotation is important because of the choice of reference system in which orbital calculations are performed. In particular, GNSS orbits — either from the broadcast orbital models or precise post-mission estimation — are parameterized in an
Earth-Centered Earth-Fixed (ECEF) coordinate frame such as the WGS84 reference frame used for GPS.

A common definition of an ECEF frame is one whose z-axis is the rotational axis of the Earth (pointing north), whose x-axis is in the equatorial plane and includes the median passing through Greenwich, and the y-axis completes the frame (typically in a right-handed sense). By definition,such a frame rotates with the Earth and is thus time-varying in inertial space with a period of 24 hours.

In the context of satellite position computations, this means that satellite locations can be computed at any given time, in an ECEF coordinate frame that is valid at that same time.

An easy way to visualize this point is to consider an ideal geostationary satellite whose position relative to the Earth does not change over time — orbital parameters or orbital files would always yield the same coordinates for the satellite.

Effect of Earth Rotation

So where does Earth rotation enter the picture? Well, precisely from the fact that the time at which a satellite transmits a signal, and the time a receiver receives that signal differs. Between the time of transmission (tt) and the time of reception (tr) — roughly 70 milliseconds (give or take few milliseconds) for medium-Earth orbiting (MEO) satellites — the Earth has rotated by ωe . (tr – tt), where ωe is the rotation rate of the Earth.

To illustrate the effect of this, we return to our idealized geostationary satellite. We further consider a user located directly below the satellite. Figure 1 shows this situation looking down on the north pole. To simplify later discussions, we consider this figure to apply at the time of signal transmission.

Since the orbital radius of a geostationary satellite is known (approximately 42,164 kilometers) and the radius of the Earth is known (approximately 6,371 kilometers) the separation of the user and satellite at any given instant is constant and can be easily computed.

Now consider Figure 2, which shows the same figure but also includes the location of the user and satellite at time of signal reception. Because of Earth rotation, the signal travels the path denoted by the blue line, which is obviously longer than the instantaneous separation of the satellite and user. This is the path in inertial space (ignoring the Earth’s orbit around the sun for simplicity).

The problem, however, is that because orbits are parameterized in an ECEF frame, the computed position of the satellite will still be directly above the user. This leads to a situation where the true signal path and the computed signal path differ. Unless accounted for, this difference will manifest as a ranging error in the receiver’s position engine, which computes the difference of the measured and predicted signal paths (i.e., ranges). The magnitude of the position error depends on the number and distribution of satellites, as well as user latitude. As an example, in Calgary, Canada, ignoring Earth rotation results in a shift in the estimated user position of about 20 meters, primarily in the east/west direction.

Before moving on, although we used the example of a geostationary satellite, the exact same effect applies to non-geostationary orbits as well. The main difference is that the satellite positions in Figures 1 and 2 would not necessarily be directly above the user, and the distance between the user and satellites, projected into the equatorial plane (which is shown in Figures 1 and 2), will vary with time as satellites move along their orbits. The good news is that regardless of the orbit, the method of compensation is the same.

Simple Solution

To remove the discrepancy between the measured and computed signal paths, we need to compute the ECEF position of the satellite at the time of transition in the ECEF frame at the time of signal reception. Fortunately, this is easily accomplished by realizing that the two coordinate frames are related by a rotation about the z-axis.

Mathematically, we can write

where is a position vector at the subscripted time (or frame), and R3 (ωe . (tr – tt)) is the rotation matrix about the z-axis by the angle subtended by the Earth rotated during signal propagation.

Applying the transformation in (1) yields the position of the yellow satellite in Figure 2, which allows for the proper computation of the (orange) user position.

The astute reader might be wondering how the propagation time is computed. This can be found by iterating to a solution: first, assume an initial distance between the user and satellite (e.g., 70 milliseconds); then compute the satellite position using this assumed distance (for Earth rotation compensation); use the approximate user position to re-compute the range to the satellite; and finally use this range to compute the satellite position.

The accuracy of the user position in the iteration is not typically a problem. The reason is because, even with a position error of 10 kilometers, the worstcase propagation time error would be 33.3 μs (i.e., 10 km / 3e8 m/s). Multiplying this by Earth rotation rate (~7.3e-5 rad/s) yields an angular error of about 2.4 nanoradians. Even over an orbital radius of 26,000 kilometers (assuming a MEO orbit), the orbital error is less than a decimeter. Then, of course, after the first epoch, the position error is typically several orders of magnitude smaller making the effect of user position error negligible.

Summary

This article has shown why Earth rotation needs to be accounted for when computing satellite coordinates for GNSS applications. The compensation is simple but crucial steps for obtaining the highest possible positioning accuracies.

The post How does Earth’s rotation affect GNSS orbit computations? appeared first on Inside GNSS - Global Navigation Satellite Systems Engineering, Policy, and Design.

In Android Release N (“Nougat”), Google introduced APIs giving access to GNSS raw measurements from your phone. Now Google has publicly released Analysis Tools to process and analyze these measurements.

Android now powers more than two billion devices, and Android phones are made by many different manufacturers. The analysis tools enable manufacturers to see details of how the GNSS receivers are performing in different phone designs. Also, with the tools publicly available app developers, researchers, and educators can use them to develop, build and teach.

This article shows what these tools do, and how they reveal details of receiver and signal behavior that are not possible to observe without raw measurements.

We begin with the basic operation of the tools, then describe the raw measurements, derived data, interactive controls, and custom parameters. Additionally, we’ll work through three examples, showing how you can use the tools for easy, but fairly sophisticated, analysis. Next, we’ll cover report generation, and on-phone analysis. Then we’ll describe some specifics of dual frequency analysis, including the mission planner. Finally, we’ll describe where to download the tools, open source code on Github, frequently asked questions and how to provide feedback.

Basic Operation

The basic operation of the tools is: users log raw GNSS Measurements with their phones, and analyze on their desktops.

The desktop tools run on Windows, Linux and Mac OS.
The RF column (Figure 1) shows:
a) The strongest four satellites from each constellation
b) The time plot of C/N0 of all satellites
c) The skyplot of satellite positions
The Clocks column shows:
a) The pseudoranges
b) The offset frequency of the receiver clock. This is computed using a reference position — either:
i) Automatically computed mean position
ii) User entered lat,lon,alt
iii) NMEA file with truth reference PVT
This is the first major benefit of raw measurements:
you can see the receiver clock behavior to better than 1ppb (part per billion) precision. This is a really important thing to see when you are making a phone — because any heat source near the reference oscillator inside the phone may cause the clock error to ramp rapidly. And the best way to see this, in the actual phone, is to use the raw measurements like this.
c) The offset of the standby clock that keeps time if the receiver duty cycles the primary oscillator
The Measurements column shows:
a) The weighted least squares (WLS) position results obtained from the raw and smoothed pseudoranges
b) The residual errors of each pseudorange, raw and smoothed
c) The residual errors of each pseudorange-rate (-Doppler) measurement
This is the second major benefit of raw measurements: you can see the errors of each measurement, and this allows significant insight into the signal environment and receiver behavior.

Raw Measurements and Derived Data

The Android API describes truly raw measurements. One of the first things you might notice when you examine the API (see Table 1) is that there are no pseudorange measurements. This is because pseudorange is not a raw measurement, it is derived from received satellite time (ReceivedSvTimeNanos). This is something of a paradigm shift for readers brought up on survey receivers that output pseudoranges. But remember that the primary purpose of the GNSS Raw Measurements API is to observe (and thus improve) the operation of the GNSS receiver, and that is why the APIs describe the fundamental raw values. It is our hope and intent that developers will create apps that build on these measurements, providing many derivations of the raw measurements. Indeed this has already started with apps to do PPP and generate RINEX data from your phone (see Additional Resources at the end of this article).

How do you get pseudoranges from these values? The analysis tools will do it for you, and if you want to do it yourself, see the open-source code. But as a summary:

pseudorange = (tRx- tTx)*c,
tTx = ReceivedSvTimeNanos [ns],
tRx = (TimeNanos +
TimeOffsetNanos) –
(FullBiasNanos+BiasNanos)
– weekNumberNs [ns],
where
weekNumberNs =604800e9
*floor(-FullBiasNanos/604800e9)

This summary is correct for GPS when time of week is known (State = STATE_TOW_DECODED or STATE_TOW_KNOWN). For other constellations and/or other states you must take care of details such as modulo milliseconds, and system time offsets. This is beyond the scope of this article, but these details are handled by the analysis tools and the resulting pseudoranges are available in the derived data.

The Desktop Analysis Tools compute smoothed pseudoranges as follows.

For intervals where the hardware clock is continuous, the smoothed pseudorange for a particular satellite signal is the least squares solution x to the matrix equation:

Wy = WAx
where
y = [column vector of raw pseudoranges
column vector of prr],
prr is the measured pseudorange-rate or, if available, the
change in carrier phase divided by Δt,

Δt is the time interval between measurements
W is a diagonal matrix, with Wii = 1/σ(yi)

That is, the smoothed pseudorange is the minimum variance linear estimator of the true pseudorange, given the measurements and variances of pseudorange (pr) and pseudorange-rate (prr), and zero-mean uncorrelated errors. In plain English, this is the best estimate we can get by post-processing all the available information.

Derived Data

Once you have processed a log file with the desktop tools, you can save all the derived data to a comma-separated text file. The derived data file includes: satellite azimuth and elevation, raw pseudorange, smoothed pseudorange, and the residual errors of the raw and smoothed pseudoranges (residual errors derived from the known reference positions). The derived data also contains the receiver clock bias and frequency error. From this file you can regenerate all the line plots and the skyplot produced by the Desktop Analysis Tools.

The tools provide interactive controls, and custom parameters. We’ll introduce these now and then show three examples of how to use them for analysis.

For greater control you can set custom parameters by including a text file: CustomParam.txt in the same directory as your log file. In this file you can declare the satellite(s) to be used for computing the clock errors (Figure 2).

Following are three examples that illustrate how to use the interactive controls.

Example 1: Measurement error vs C/NO.

The tool lets you select any subset of the visible satellites. In this case we’ve chosen three with different C/N0: Strong, Medium, Weak (Example 1). You can read the computed raw pseudorange errors directly from the plot, including mean and standard deviation. You can clearly see two things:
1) the relationship of C/N0 to pseudorange errors
2) the increased filtering that the receiver does to track the weaker signals, combined with the fading caused by multipath, especially on weak signals — note the increasing time constants of the errors.

Example 2: Iono, and Tropo analysis

In this example we process data collected at a known point, under open sky, away from any buildings or reflecting surfaces. We disable Iono and Tropo models by unchecking the respective boxes on the control panel, and we set the Reference PVT to the known true position of the receiver (Example 2).

The pseudorange error plots will now include the sum of Ionosphere, Troposphere, and Orbit errors. For GPS and Galileo, the typical orbit error in the broadcast ephemeris are now less than 0.5 meters (see Additional References), so the rest of the pseudorange error will be dominated by Iono+Tropo delay.

There is one thing left to do: specify which satellite to use for computing the clock error. Ordinarily the analysis program will automatically select several satellites for this. But, in order to observe relative error of iono and tropo we select a single reference satellite for computing the receiver clock. The pseudorange error on this satellite will be zero, by definition, and the errors on the remaining satellites will be the difference between their errors and the reference satellite. We choose the highest satellite, and specify it in a text file CustomParam.txt:

You analyze measurement errors from a moving receiver by supplying an NMEA truth reference file. The Analysis Tool reads the NMEA file and extracts the GGA messages (for 3D position) and RMC messages (for velocity). With this information the Tool can compute clock offsets and frequency, and measurement errors for pseudoranges and pseudorange-rate.

As the car drives into the city from bottom-right towards top-left, we see a sudden and dramatic change in C/N0 for the low satellite, and at the same time, a large increase in pseudorange error (Figure 3). While the error on the other satellites remains small.

So, the question is: what happened to this satellite GPS PRN 22?

Multipath — yes, but not classic multipath (with line-of-sight and non-line-of-sight signals overlapping), rather, what we see here are pure reflections. How do we know that? Because we can see from the skyplot, and the Google Earth image that this satellite is completely blocked by the building to the south of the car; combined with the C/N0 and PR error plots we can see that the signal that is tracked is something reflected from across the street.

As these examples show, in just a few minutes you can do fairly sophisticated analysis at a level that, until now, was inaccessible to anyone but the chip manufacturers themselves.

Having done this we run the analysis, and, in this example, pick five satellites with increasing elevations:

For these five satellites we observe the expected trend of greater atmospheric delay with decreasing elevations. The difference between the delay for the highest satellite (PRN 32, at 80°) and the lowest (PRN 24, at 7°) is approximately sixteen meters. In general there will be other errors (such as noise, and multipath) and at times they may be larger than the atmospheric delays. So not all signals will be this well behaved, but you can quite easily see the expected trend in most datasets.

Example 3: Urban Multipath/Reflection analysis

You can observe the individual effect of multipath and/or signal reflections on each measurement. As an example, here is a drive test in San Francisco — you can see the San Francisco Giants baseball stadium in the image.

The green dots here show the truth reference obtained from a GNSS inertial navigation system. We will analyze the GNSS measurements from a smartphone chip.

On-Phone Analysis

You can also do some basic analysis directly on the phone, using the Gnss-Logger App. This app was developed to:

• Exercise and validate the applicationfacing Android GNSS APIs
• Compute real-time (least-squares) position from raw measurements
• Collect data for offline analysis

The Settings View also shows important device related info such as the GNSS HW Year, Android Platform Number, Android Api Level and GnssLogger version. Log View in which the switched ON GNSS outputs will be shown (Figure 4). This view also adds the capability to log the GNSS data for offline processing and as well to send the logged files via email or other sharing options.

The offset between the two positions is also shown (Figure 5). As the device location is generally filtered, offsets of 5-10 meters may occur between device location and WLS (weighted least squares) location; even in open sky. With even higher offsets expected as the device moves to urban areas, or indoors.

Map view where one would see on Google Map the position reported by the device vs the weighted least square position (Figure 5, bottom).

The Signal Strength View is shown in Figure 6. The Residual Error plot is shown in Figure 7, using ground truth location entered by the user. If the ground truth-location is unknown, the average reported device location can be used as ground-truth. The window over which the ground-truth-location is averaged varies based on the user activity (e.g. standing, walking, running and driving).

Multi-Frequency, Multi-Constellation

The tools support multi-constellation (GPS, GLONASS, Galileo, BeiDou and QZSS) and multi-frequency. Specifically, with the advent of L1L5 receivers for smartphones, v2.6.0.0 of the tools includes features specific to analyzing the quality of L5/E5 measurements.

If L1/E1 and L5/E5 measurements are present, then the bar chart of C/N0 shows both L1/E1 and L5/E5 signals, as well as the mean difference between L1 and L5. One of the challenges of implementing L5 in a phone is the L5 antenna, and the tools show the presence and magnitude of any RF losses. Also, the pseudorange error plots show the group delay between signals on different frequencies.

The skyplot and control panel also show which satellites signals have been tracked (e.g. L1,L5, or E1,E5a, etc).

Mission Planner

The tools include a Mission Planning feature, showing which satellites will be visible from any location at any time. In particular, the Mission Planner highlights satellites with L5/E5 signals, so you can plan multi-frequency testing at appropriate times.

For example, Figure 8 shows the Mission Planner skyplot as viewed from Singapore for a 12-hour period. The GEO and IGSO satellites of BeiDou and QZSS have been selected from the control panel.

Receiver Test Report

The tools provide automatic test reports of receivers. Click “Make Report” to automatically create the test report. The report evaluates the API implementation, Received Signal, Clock behavior, and Measurement accuracy. In each case it will report PASS or FAIL based on the performance against known good benchmarks. This test report (Figure 9) is primarily meant for the phone manufacturers to use as they iterate on the design and implementation of a new phone.

Compare Log Files

You can load multiple files and do sideby-side comparison of C/N0. The “Compare” tab lets you load several different log files to compare against each other.

The [Plot C/N0] button then produces side-by-side plots of the strongest satellites from each log file (Figure 10).

To Download the Tools and Open-Sourced Code

The compiled tools run on Windows, Mac and Linux. They have been publicly released by Google, and are available free for download at: https://g.co/GNSSTools

Open-sourced Java code is available for the GnssLogger app, and open-sourced Matlab code is available for the GPS-only part of the desktop analysis. The point of this open-source code is to help developers create their own apps, and also to provide a template for how certain values are computed (such as pseudoranges, discussed above). We will evolve the analysis tools in response to user requests, but we do not intend to open source all the code for the desktop tools beyond what is already available.

Manufacturers

In Example 3, the green dots showing the truth reference are obtained from a NovAtel SPAN system from NovAtel Inc., Calgary, Alberta, Canada. The dual frequency measurements are obtained from the BCM47755 chip from Broadcom Corp., Irvine, CA. The GnssTools smartphone app, and GNSS Analysis desktop tools are from Google Inc., Mountainview, CA.

The post GNSS Analysis Tools from Google appeared first on Inside GNSS - Global Navigation Satellite Systems Engineering, Policy, and Design.

Precise Point Positioning (PPP) techniques can be defined as processes where a single GNSS receiver can precisely compute its position (down to centimeter level) by autonomously correcting its raw pseudorange and carrier phase measurements using the PPP correction message content. PPP corrections data include the constellations’ orbits, clocks, code, and phase biases. They are provided to the receiver via different types of communication channels. The PPP enabled receiver handles these corrections in a real-time process.

PPP based positioning techniques have been extensively investigated and developed in recent years. These methods are now rather mature and provide very good means to achieve in real-time a few centimeters of accuracy and precision in remote areas, where other solutions like real-time kinematic (RTK) are impracticable or too expensive. One main advantage of PPP approaches is that they provide a global means to achieve high accuracy based on a global and low density network of base stations. There is no need for a very dense network of stations in the vicinity of the user, which is often unfeasible in remote areas.

Although PPP algorithms are the cornerstones of these methods, another important issue for their practical use is the way the PPP corrections can be provided to the user receiver. So far, typical solutions encompass:

• Internet, using fixed or mobile internet connections like mobile phone networks (3G/4G). This is a simple solution that suffers from a number of telecommunications issues such as connection discontinuities, unavailability or bad quality of the transmission in remote areas, and costs or limitations for data transmission. Use of such a solution for PPP broadcast to users would also generate a few gigabytes of data transmission per user per month. A generalized use to millions of users (for example, in cars) could rapidly exceed the network capacity.
• Satellite-based PPP solutions. These channels are more adapted to such a broadcast and do not suffer from the above described limitations. Commercial broadcast of such proprietary PPP service by specific Geostationary satellite channels is available (see O. Heunecke and H. Heister in Additional Resources) but requires proprietary receivers and remains expensive, thus limiting its use. Broadcasts using other satellite orbits have also been tested on Highly Elliptic Orbits (HEO) on the Quasi-Zenith Satellite System (QZSS) (C. H. Wickramasinghe and L. Samarakoon; K. Harima et alia) or planned with the Commercial Service (CS) on the Galileo constellation. Figure 1 (see inset photo, above right) shows the architecture of this demonstration, providing PPP via a Galileo E5b signal in real-time, through a geostationary satellite. This demonstration benefited from the opportunity that an EGNOS satellite in test was available, and that an E5b channel was free on the EGNOS payloads.

Complementarity Between MEO and GEO Based PPP Solutions
A demonstration of the PPP message being broadcast on the Galileo E6 central frequency was carried out by I. Fernandez et alia, and showed that broadcasting a PPP message through Medium Earth Orbit (MEO) satellites is meaningful. However, it also showed the weaknesses of such a scheme:

• A relatively high time latency causing decreased positioning performances;
• A low availability of the E6 message.

Adding a Geostationary Orbit (GEO) PPP broadcast channel to a Galileo MEO E6 channel could have the following advantages:

• A higher overall availability thanks to both frequency and spatial diversity. Indeed, the E6 frequency band is not part of the Aeronautical and Radio Navigation Satellite Service (ARNSS) band, and is more subject to interference than the E5b band. On the other hand, considering different types of environments, GEO signals may be masked in harsh environments like urban or deep urban situations. As GEO satellites are stationary, the receiver must be in an unmasked area towards the GEO. Another solution would be to involve differential measurements in the masked area with a second receiver. In such environments, MEO satellites have a clear advantage. It has to be noted that typically in urban areas, PPP is also accessible via wireless internet access such as 3G or Wi-Fi. In open sky environments, the GEO satellites have the advantage of providing a continuous service available in the whole GEO footprint;
• A higher geographic coverage thanks to the combination of MEO and GEO coverage, as MEO satellites offer higher latitudes coverage compared to GEO coverage;
• A higher data rate, as the PPP message can be broadcast with an incremental precision using both the E5b and E6 bandwidth. Using the GEO E5b bandwidth could alleviate the needs of bandwidth on GALILEO MEO E6 for high accuracy service, thus allowing more room for other commercial services like authentication service.

Most importantly, and apart from this end user service complementarity between MEO and GEO satellite-based PPP solutions, the E5b channel available today on EGNOS GEO satellites may be used in the future for several Galileo E6 CS testing ends. This is especially true as it is possible to use existing receivers compatible with Galileo E5b signals to process the PPP message by applying only a firmware update of the receiver, which greatly simplifies the needed infrastructure and thus allows for early testing of different possible Galileo E6 CS functionalities.

In this context, we propose to evaluate the feasibility of broadcasting a signal containing PPP information, via a Galileo signal through a GEO satellite, with a demonstration aiming at evaluating the obtained positioning performances in real conditions.

The demonstration principle consists of broadcasting an E5b signal containing value-added information into an ad-hoc user segment, using the SES Satellite-Based Augmentation System (SBAS) payload capacity to repeat such a signal. The value-added data incoming in real-time from a CNES hosted internet server are encapsulated in a message and signal structure similar to that of Galileo E5b.

Thales Alenia Space with the support of SES Networks implemented a preliminary demonstration of this capacity in early 2015. A second window of opportunity to broadcast the PPP signal through an EGNOS GEO payload was available in July 2016.

Following the context and demonstration presentation, this article describes the detailed test-bed architecture and presents results first obtained in factory and then in an on-site real time configuration.

GEO E5b SIS CHARACTERISTICS
GEO E5b SIS Structure
The E5b GEO signal center frequency is set to 5767.14 MHz for the uplink (NLES-to-Satellite RF link) and to 1207.14 MHz for the downlink (Satellite-to-users broadcast RF link). This is the same center frequency as that used for the Galileo E5b signals. Figure 2 (see inset photo, above right) shows the frequency plan used for this testbed, the resulting measured uplink EGNOS + PPP spectrum on site, and the spectral separation between the EGNOS L5 and the PPP E5b signals. A complete analysis of this spectral separation and interactions between both signals was assessed in H. Al Bitar et alia (2013).

The modulation used to generate the E5b signal is also the same as the one used for the nominal Galileo E5b signal, defined in the Galileo Open Service Signal In Space Interface Control Document (OS SIS ICD) (see Additional Resources). Namely a BPSK(10) modulation is used on two quadraphase channels: one data and one pilot. The data rate is the same as for Galileo E5b (250 sps).

The ranging codes are built from so-called primary and secondary codes by using a tiered codes construction (see Galileo OS SIS ICD).

The signal’s primary and secondary codes comply with the E5b ranging code characteristics. The Galileo PRN 38 as defined in the Galileo ICD is used. This PRN is not part of the Galileo PRNs that are assigned to Galileo satellites. Secondary codes CS41 and CS10088 as defined in the OS SIS ICD are allocated to the E5b GEO signal data and pilot components, respectively.

Tables 1 through 3 (see inset photo, above right) summarize the GEO E5b SIS structure and main RF characteristics.

It is important to note that the PPP corrections typically need a large bandwidth in order to achieve good performance, especially when providing corrections for several satellite constellations. Obviously, limiting the required data bandwidth is always necessary, due to the high cost of this scarce resource. But limiting the bandwidth may impact the resulting PPP performances such as solution accuracy and convergence time and the availability of PPP service to users. Thus a trade-off generally must be found between these two constraints.

For this demonstration, innovative compression techniques developed by the CNES were used to broadcast PPP corrections with the data rate available on one E5b Galileo like signal, i.e., 125 data bits/second, while keeping very good final accuracy and convergence time performances, as shown in the results presented later. These compression techniques are briefly described in the next paragraph.

GEO E5b PPP Message Characteristics
The E5b PPP message has the same structure as the Galileo E5b I/NAV message. The only difference is that the useful data bits of the Galileo E5b I/NAV message are replaced by the PPP corrections Radio Technical Commission for Maritime (RTCM) message, as described in Figure 3 (see inset photo, above right).

In the frame of this PPP demonstration campaign, the word type is set to 63, thus indicating a dummy message.

The PPP correction message contents are generated by the so-called CNES caster.

Indeed, in the framework of the International GNSS Service (IGS) Real Time Service (RTS) (see Additional Resources), CNES provides GNSS augmentation data in real-time. These data include the constellations’ orbits, clocks, code, and phase biases. The main goal of the participation in the IGS RTS for CNES is to promote a new precise point positioning technique that performs undifferenced ambiguity resolution (A. J. Van Dierendonck et alia; D. Laurichesse et alia (2006)). It allows for the positioning of an isolated receiver with centimeter level accuracy in real-time.

In the IGS RTS, the dissemination of the different quantities is performed by means of an open standard, the RTCM. The quantities are defined in a State Space Representation (SSR) (D. Laurichesse and A. Privat), as opposed to other techniques like RTK, which use an Observation State Representation.

Table 4 contains the different RTCM/SSR messages used by the CNES PPP demonstrator and available on the CLK91 mountpoint.

The RTCM standard is primarily designed for terrestrial communications and not with a very low bandwidth in mind. For example, the above-mentioned stream has a bandwidth of several kilobits/second, and is clearly not compatible with the bandwidth of the I/NAV E5b message of 186 bits every two seconds. Thus, an efficient compression scheme and a new message format need to be designed.

In order to compress the initial RTCM stream by a factor of 50, several ingredients are used. The chosen solution (inspired by other augmentation messages like those used in SBAS or JPL-GDGPS (see Additional Resources) is a trade-off between the available bandwidth and corrections latency, while maintaining the main characteristics of PPP, including ambiguity resolution:

• Selection of a reduced set (20) of satellites over the area of service (namely the European continent in this case). The satellites are selected upon their visibility and sorted by their elevation.
• Suppression of the code biases messages. Indeed, as the PPP is mainly a phase solution, code biases are not needed. In the user solution, code measurements are underweighted.
• Phase biases are directly applied to the clocks and do not need to be transmitted.
• Finally, each I/NAV message is comprised of:
  • A “slow” part containing orbit corrections, their first order derivative, a raw clock, and the widelane bias for one satellite.
  • A “fast” part containing accurate clock correction for four satellites.

With four clock corrections transmitted every two seconds, the set of 20
satellite clocks is actualized every 10 seconds. The entire cycle for
the orbit corrections is 40 seconds.

The compression module takes as input the CLK91 stream and sends the compressed stream to a new mountpoint created for this purpose on the CNES caster. It is then possible to access the compressed stream by simply pulling the new stream from the caster.

Figure 4 shows the gain in bandwidth brought by the compression algorithms, as measured by the independent BNC tool (again, see Additional Resources). The improvement is clearly visible.

On the user side, the PPP-Wizard open source software (Version 1.2) is used (D. Laurichesse). This tool is compatible with the RTCM real-time stream available at the IGS Real Time Service and provides centimeter level accuracy in real-time. It has been modified to support the decoding of the new compressed stream.

GEO E5b SIS Generation Scheme
The GEO E5b SIS is generated by an Earth station that is independent from EGNOS NLES. Two one-way links between the EGNOS NLES and the E5b generation Earth station were still needed in this PPP demonstrator for:

• A 10 megahertz input to the different E5b GEO SIS Earth generation station components
• A 1 PPS input for some of these components

These two links were maintained for the sake of E5b Earth station complexity and cost reduction. The different E5b Earth station possible architectures were thoroughly discussed by H. Al Bitar (2013).

DEMONSTRATION SETUP
We now describe the on-site demonstrator setup for the live tests. A description of specific setup related to factory tests follows.

On Site Setup
This section details the on-site setup. The demonstration took place in July 2016 at Betzdorf, Luxembourg, on the SES site. The PPP corrections are provided by the CNES PPP caster. Then, in the NLES E5b, the PPP corrections are encapsulated in the Galileo E5b message format, and generated via a Galileo E5b signal, with the PRN code 38. For the demonstration, the signal is uplinked via the C5 frequency on the SES ASTRA 5B GEO satellite. Finally, the Galileo E5b signal is broadcast via this GEO satellite over Europe, via the E5b frequency.

A commercial off-the-shelf (COTS) receiver is based at Toulouse in order to receive the Galileo E5b signal with the PPP corrections, broadcast by the GEO ASTRA 5B satellite. To be able to use these PPP corrections, the user also needs GNSS constellation measurements. In this demonstration, the PPP corrections for GLONASS and GPS are used.

Thus, the receiver needs to receive GNSS measurements from the GPS and GLONASS constellations.

The E5b demonstrator functional architecture is shown in Figure 5.

The demonstrator is composed of:

• The CNES PPP caster, in charge of the provision of the PPP corrections via internet,
• The NLES E5b, in charge of the Galileo E5b signal, in which the
  PPP corrections are encapsulated, (Figure 6), This station is in turn
  composed of :
• A control PC developed by Thales Alenia Space for this dem
• A signal generator developed by Thales Alenia Space and Elta (NAVYS) providing the flexibility to generate nonstandard signals,
• An L-to-C band frequency converter,
• An RF adapter in order to ensure that the transmitted signal
  quality complies with the uplink and downlink Signal In Space interface
  requirements. It includes an analogic filter, attenuators and splitters
  and combiners when needed.
• The NLES G2, in charge of the provision of time (PPS) and
  frequency (10 megahertz) references to the NLES E5b, along with the
  generation of the EGNOS L1 and L5 signals,
• The SES broadcast means, in charge of the broadcast of the signals
  (EGNOS L1 and L5, and Galileo E5b) over Europe via the GEO ASTRA 5B
  satellite,
• An E5b analysis module, in charge of the verification of the emitted Galileo E5b signal, and
• A PPP solution module, in charge of the reception of the Galileo
  E5b signal, in addition to the GPS and GLONASS measurements, in order to
  compute the PPP solution.

The CNES PPP caster provides PPP corrections via an internet connection. Detailed information on the CNES PPP caster can be found in the Additional Resources section.

The NLES E5b Control PC has two main functions:

• It manages the data interface by communicating with the CNES caster, and
• It manages the real-time interface with the NAVYS GNSS signal
  generator, by sending the real-time data message to NAVYS appropriately
  formatted.

These functions are performed by:

• TPACQ (standing for Thales PPP ACQuisition), in charge of the
  connection to the remote server, the extraction of the payload, its
  convolutional encoding, the construction of a Galileo I/NAV-like format,
  latency management, and providing a data message each and every second,
• GATEWAY, in charge of receiving the messages and writing them in
  the GCS hard drive. It sends commands to the GCS, writes synchronization
  commands, and writes the navigation message.

The RF interface is managed by the NLES-E5b RF Adapter elements. This RF interface is configured based on the given SES RF interface requirements, and the GSA downlink signal quality and characteristics requirements. It allows for controlling the output signal center frequency, power, bandwidth, in and out of band interference, etc.

The RF adapter is composed of:

• An RF filter. This is used at the output of the NAVYS generator in
  order to guarantee that the spectral characteristics of the L5
  generated signal are compliant with the needed safety barriers for the
  uplink signal.
• An Advantech L to C tunable up-converter, borrowed from the NLES
  G2 factory platform. This equipment, originally designed to up-convert
  EGNOS L5 signals in the uplink transmission band with the desired
  amplification level, perfectly fits the demonstrator needs because of
  its passband. It performs the L5 to C5b frequency translation of the
  signal generated by NAVYS.

The NLES G2 is the new generation of EGNOS NLES embedding the ability to generate L1/L5 dual-frequency GEO signals. As already stated, and in order to have a simplified architecture for the NLES E5b, it is foreseen for this station to share some outputs of the NLES G2, such as the 10 megahertz frequency reference and the 1 PPS signal.

The SES broadcast means include the uplink signal interface and the downlink signal interface. The uplink signal interface is a one way RF interface carrying the C5b signal to be uplinked to the GEO satellite. The power level must be adjusted so that, at the SES RF interface, the total power level in the C5 band is -5 dBm. In the demonstration configuration, the power of the C5b component equals -10 dBm. In order to obtain a resulting signal with a power of -5 dBm, the power of the C5a component must equal -6.5 dBm. This configuration is of high interest as authorities could dislike the idea of reducing the power budget allocated to the Safety of Life (SoL) component. The downlink signal interface is a one-way RF interface carrying the E5b signal received by the SES RF station from the ASTRA 5B satellite.

The E5b analysis module is composed of the Thales Alenia Space software receiver, GEMS, and a specific post-processing analysis tool, developed for the demonstration.

The PPP solution module is composed of a GNSS commercial off-the-shelf (COTS) receiver with a firmware patch to allow the processing of the Galileo PRN 38, and a PPP solution computation unit developed by CNES.

The GNSS receiver tracks the GPS and GLONASS constellation signals in order to provide dual-frequency GNSS measurements to the PPP solution computation unit (see Figure 7). In addition, the receiver tracks the Galileo E5b signal from satellite PRN38, corresponding to the E5b signal broadcast by the GEO ASTRA 5B satellite. As mentioned previously, this E5b signal provides the PPP corrections, associated with the GPS and GLONASS satellites and optimized for a user located in the GEO satellite ground track.

Factory Setup
Prior to the on-site demonstration, a comprehensive set of factory tests were performed.

The different objectives of this factory test campaign are recalled as follows:

• Integration of all the demonstrator elements,
• Verification of the feasibility of the demonstration,
• First assessment of the demonstrator performances,
• Demonstration that the demonstrator is compliant with SES requirements,
• Demonstration that the demonstrator does not jeopardize the EGNOS SoL operations.

During factory tests, a so-called GEO Payload Simulator was used to replace the GEO satellite. The GEO Payload Simulator simulated the uplink-GEO-downlink path of both L1 and L5 signals, and was used to generate the E5b signal uplink and downlink paths as well.

DEMONSTRATION RESULTS
Factory Live Tests Results
The factory test on Thales Alenia Space premises was performed on June 15, 2016. The conditions of the test were the same as those described in Figure 5, except that the GEO satellite was simulated by means of an RF payload simulator as previously stated.

Figure 8 shows the error of the PPP, obtained by computing the difference between the PPP module output and the accurate reference coordinates of the receiver antenna, projected in the local frame.

These results are representative of a PPP processing. After a first convergence phase of about one hour, the accuracy is less than 10 centimeters. Fourteen satellites is typical of the dual-constellation (GPS, GLONASS). After convergence, the horizontal accuracy has a Root Mean Square (RMS) error of seven centimeters. Up to six satellites have ambiguities estimated to their integer value. The overall latency is about 30 seconds and explains the short-term noise of the solution.

This successful result demonstrates the validity of the implementation.

On-Site Live Tests Results
The live experiment took place from July 21-27, 2016. The receiver was located on CNES premises, using a geodetic grade antenna on a roof of a building. The NLES E5b was installed on an SES site in Betzdorf, Luxembourg, together with the NLES G2 for the SES ASTRA 5B satellite.

On a typical one-day session (July 24, 2016), PPP results are identical to those obtained during the factory tests, in terms of convergence and accuracy (Figure 9):

After convergence, the RMS of the horizontal accuracy is approximately eight centimeters. The latency measured in this case is about 23 seconds. Note that the latency is mainly due to this testbed configuration, and will be reduced in any future deployment of such PPP corrections broadcast test.

In order to have a better understanding of the contribution of the GEO transfer function in terms of accuracy, the same measurements were processed using the RTCM realtime corrections, before the stream compression. The results are presented on Figure 10. The horizontal RMS is equal to two centimeters. We can deduce that the noise of the transfer function (compression and end-to-end latencies) is equal to seven-and-a-half centimeters.

Conclusion
The main and novel aspect of this article is obviously the implementation of a complete end-to-end GEO satellite-based PPP solution via real live tests.

A proof of concept was first assessed through a laboratory real-time testbed. Next, an on-site real-time end-to-end demonstration was held with different levels of implications of the concerned stakeholders (European GNSS Agency (GSA), SES, ESSP, CNES, and Thales Alenia Space).

The success of this demonstration first reminds us that an E5b non-SoL signal can co-exist with an SoL signal.

Second, and most importantly, the results presented here showed that with only 125 bits/second data rate available on a Galileo E5b-like message, the final accuracy and convergence time performance of the computed solution are still very satisfying (horizontal positioning error equal to eight centimeter RMS after a first convergence step of one hour).

This testbed further demonstrated that broadcasting an additional signal through an existing and transparent GEO payload requires neither heavy nor complex technical means. It is thus compatible with a possible fast deployment and could operate as a test platform for various functionalities to the upcoming CS E6 Galileo signal for example.

Ultimately, a GEO PPP broadcast channel and a Galileo MEO E6 channel used together could result in an improved accuracy service with better performance, thanks to an enhanced availability (frequency and spatial diversity), a higher geographic coverage, and a higher data rate.

Acknowledgements
We would like to thank the GSA (European GNSS Agency), ESSP, and SES engineering and operations teams for their very valuable support to E5b signal testing on SES’s EGNOS uplink station and ASTRA 5B EGNOS payload. We would also like to thank Septentrio for their support in providing a new firmware version of the PolaRx5 receiver allowing for tracking of the Galileo PRN 38 code.

Additional Resources
[1] Al Bitar, H., M. Raimondi, L. Ries, “NLES-NG: Augmenting EGNOS with an E5b Channel,” Proceedings of the 6th European Workshop on GNSS Signals and Signal Processing, Munich, December 2013
[2] Al Bitar, H., M. Raimondi, D. Kubrak, L. Ries, “Augmenting EGNOS with an E5b Channel,” Proceedings of The Institute of Navigation International Technical Meeting (ION ITM 2014), San Diego, CA, 2014
[3] Charlot, B., H. Delfour, D. Laurichesse, P. Lesage, “Efficient Message Coding To Broadcast PPP Corrections Through Satellite,” Proceedings of ISGNSS 2014, ICC Jeju, Korea, 2014
[4] Fernandez, E. C. I., I. Rodriguez, G. Tobias, J. D. Calle, E. Carbonell, G. Seco-Granados, J. Simon, R. Blasi, “Galileo’s Commercial Service, Testing GNSS High Accuracy and Authentication,” Inside GNSS, January/February 2015
[5] Galileo OS SIS ICD
[6] Harima, K. et alia, “Performance of Real-Time Precise Point Positioning using MADOCA-LEX Augmentation Messages,” International Federation of Surveyors Congress, Kuala Lumpur, Malaysia, 2014
[7] Heunecke, O. and H. Heister, “Worldwide Kinematic Positioning using the OmniSTAR HP and XP Services,” Institute of Geodesy, University of the Bundeswehr, Munich, 2010
[8] JPL GDGPS message
[9] Laurichesse, D., “The CNES Real-time PPP with Undifferenced Integer Ambiguity Resolution Demonstrator,” Proceedings of ION GNSS 2011, Portland, OR, September 2011
[10] Laurichesse, D., F. Mercier, J. P. Berthias, P. Broca, L. Cerri, “Integer Ambiguity Resolution on Undifferenced GPS Phase Measurements and its Application to PPP and Satellite Precise Orbit Determination,” NAVIGATION, Volume: 56, Issue: 2, Summer 2009
[11] Laurichesse, D. and A. Privat, “An Open-source PPP Client Implementation for the CNES PPP-WIZARD Demonstrator,” Proceedings of ION GNSS 2015, Tampa, FL, 2015
[12] SC-159, “Minimum Operational Performance Standards for Global Positioning System/Wide Area Augmentation System Airborne Equipment,” RTCA DO 229 D, Annex A, December 13, 2006
[13] Van Dierendonck, A. J. et alia, “Relationship between Allan Variances and Kalma Filter Parameters,” Proceedings of the 16th Annual Precise Time and Time Interval (PTTI) Applications and Planning Meeting, NASA Goddard Space Flight Center, pp 273–293.
[14] Wickramasinghe, C. H. and L. Samarakoon, “QZSS LEX Message Data for Precise Point Positioning,” Coordinates, A Monthly Magazine on Positioning, Navigation and Beyond, 2013
[15] https://igs.bkg.bund.de/ntrip/download, http://www.igs.org/rts, http://www.ppp-wizard.net, http://www.rtca.org
[16] http://www.igs.org/rts
[17] http://www.ppp-wizard.net
[18] http://www.rtca.org

The post A Demonstration of the Galileo E5b Signal appeared first on Inside GNSS - Global Navigation Satellite Systems Engineering, Policy, and Design.

in Ireland, which represent some of the world’s best examples of peatland biodiversity. They also provide an ecosystem for purifying water and help balance the watershed supply naturally by mitigating flood consequence through water absorption.

Monitoring the health of the wetlands requires extremely accurate vegetation data collection over a long period for comparison purposes. Surveyors like WSI monitor the growth or recess of certain indicator species, such as Sphagnum mosses, which are good indicators that a peatland is healthy or drying out.

Recently, the Irish Wildlife Service began requiring WSI to provide submeter accuracy for its vegetation monitoring, so WSI looked for a more sustainable solution, one that would let the field personnel take advantage of the devices and software they already used. To continue monitoring bogland for the Wildlife Service, WSI needed a solution that provided submeter accuracy and tested the Arrow 100 GPS receiver in a weeklong trial survey of remote blanket bogs in western Ireland. The Arrow 100 is made by Canadian company and Esri Silver Tier partner Eos Positioning Systems, a provider of extremely high-accuracy GPS/GNSS receivers and related apps. WSI worked with Eos’s UK distributor, MGISS, to acquire the receivers.

The small, portable receiver draws high-accuracy location data from the European Geostationary Navigation Overlay Service (EGNOS), a free European satellite-based augmentation system (similar to wide area augmentation system [WAAS] in the United States). The Arrow 100 receives a differential correction signal from EGNOS, sends this to the iOS device via Bluetooth, and automatically overrides the device’s native GPS with data that is far more accurate. It delivers submeter accuracy without the need for new hardware or software.

Today, WSI continues monitoring the health of the bog ecosystem with Collector, iOS, and Arrow 100, ensuring progress in the fight to conserve Ireland’s last remaining wetlands.

2. Great American Eclipse
Westford, Mass., USA
√ With the help of plenty of GNSS data, researchers from MIT’s Haystack Observatory and Norway’s University of Tromsø have published a paper in the journal Geophysical Research Letters detailing the presence of eclipse-generated “waves” in the Earth’s ionosphere. A hypothesis that has been around for some time – about the impact of the moon’s shadow as it races at supersonic speeds across the planet – was confirmed by the findings.

While an estimated 212 million Americans looked skyward on Aug. 20, 2017 to catch the historic first coast-to-coast solar eclipse in nearly a century, the moon’s shadow was busy messing with Earth’s upper atmosphere. The Great American Eclipse of 2017 was notable for both the amount of land it crossed (14 states witnessed totality) and the sensitive technology available to gauge its effects. The long-standing theory was that the moon’s shadow would induce rapid cooling in the atmosphere, generating bow waves, and rapid heating as the shadow moved on, creating stern waves.

Using data from more than 2,000 sensors across North America networked into the GNSS, the researchers were able to accurately measure the presence of both bow and stern waves from the eclipse’s shadow. According to the paper, the waves moved at over 650 mph and lasted roughly an hour. The researchers were pleased to prove yet another theory concerning one of nature’s most spectacular phenomena. The results present the “most comprehensive set of eclipse-induced wave characteristics available to date” and advance theoretical understanding, and address a long-standing controversy surrounding one of nature’s most spectacular active events, the researchers stated.

3. Cattle-Herding Drone
California, USA
√ Even as advances in modern agriculture have changed the way tractors are controlled and crop techniques evolve to make growing things more efficient, it appeared as if farmers walking through fields using whistles and dogs to move herds of livestock from one area to another would never change.

But now drone herding has become a thing as evidenced by a number of videos online from places like California, Texas and Australia. With today’s navigation technology drones and agriculture have become great partners when it comes to mapping fields, assessing crop health from the skies and distributing pesticides.

Additionally, some farming pioneers have started using their drones to herd animals, including cattle and sheep, from one place to another. Drones fitted with thermal cameras can easily locate animals that wander off or perform regular aerial inspections to prevent the need for more thorough searches in future.

These breakthroughs may mean the old farmer walking around with a stick and his dog herding cattle may one day become a thing of the past.

The post GNSS Hotspots | January 2018 appeared first on Inside GNSS - Global Navigation Satellite Systems Engineering, Policy, and Design.

“With our current line of NovAtel GNSS receivers, the OEM7 series, we incorporate all four GNSS constellations— GPS, GLONASS, BeiDou and Galileo—in parallel, as well as WAAS and EGNOS and the other augmentation systems. All the boards we have produced, starting with the OEM6, with very few exceptions, have been Galileo-capable.”

Going Way Back
When NovAtel launched its groundbreaking OEM6 series back in 2009, the company had already acquired quite a bit of experience with Galileo. “Actually, it started really early, in the year 2000,” Ritter said. “We had had some discussions with ESA about the Galileo signal structure, and that was when we decided to create what was essentially the first prototype Galileo receiver.

“Things were very fluid back then”, he remembered, “Not everything was clearly defined, so it took a while to get those first receivers out, but by 2004 we had a Galileo receiver available, before there were any satellites in orbit.”

“At the beginning,” Ritter said, “it was kind of engineering driven; because we could do it, we did it. And then we thought, for most of our market it would eventually become a requirement to use all available constellations. So it was less driven by making money and more driven by us saying let’s get ahead of the game.”

“We have been ‘in Galileo’ from the beginning and we are part of the Galileo infrastructure,” Ritter said. The infrastructure referred to includes the Ground Reference Chain (GRC) receiver, used to monitor the quality of the Galileo signal. The contract to build it, awarded to NovAtel in 2005, further solidified the company’s relationship with Galileo.

Strong Suit
Various arguments have been put forward in favor of multi-constellation GNSS and the consensus has generally been ‘the more the merrier’, but if you have to choose just two, Ritter said, there are two systems in particular that really do make a nice pair. “Galileo is a great back-up to GPS, and GPS is a great back-up to Galileo; the two fully compatible Western-World systems are kind of a match made in heaven,” he said.

Ritter cited, among other things, the spoofing threat: it’s a lot harder to spoof two constellations than to spoof just one. This makes the GPS-Galileo pairing potentially extremely interesting, particularly from a military/security perspective.

“But even in the civilian world,” Ritter followed, “having a Galileo constellation, hopefully soon with an authentication signal, and at the same time having the GPS constellation, it will be much harder for anyone to attack the signal.”

In terms of Galileo’s stand-alone added value, Ritter said, it’s nice to see more and more satellites coming online, delivering greater and greater accuracy, but the real focus should be on authentication. “When I talk to people about Galileo, that’s the real seller.”

The European GNSS Agency, which runs the Galileo Program at the behest of the European Commission, seems to agree, regularly highlighting the planned unique authentication capabilities of the Galileo Open Service and Commercial Service, as well as the higher-security-level, encrypted Public Regulated Service (PRS).

“I would love to build a board that does PRS,” Ritter mused. “My future vision for NATO would be a board that does both M-Code [secure military GPS signal] and PRS.”

In addition to providing much-anticipated authentication and security features, certain specific characteristics of the Galileo signal provide additional multi-path resistance, so important in difficult environments such as so-called urban canyons.

“Galileo’s more modern signal structure,” Ritter said, “for example the alt- BOC [alternative BOC], make it a way more reliable and multi-path-resistant signal. It’s something that people in the 1970s, when GPS was defined, didn’t foresee.

The private sector remains willing and able to aid in the development of new cutting edge GNSS technologies, Ritter added. “Over the last few years, Hexagon AB, which is a European company, has invested more than 300 million EUR in correction services that can help the Galileo project meet many of its remaining goals.”

Once in a Lifetime
Recently, Ritter got a chance to look at one of his company’s GRC receivers in Kourou, French Guyana, when he was invited there to witness the lift-off of four new Galileo satellites onboard the astounding Ariane 5 launcher.

“Seeing one of the monitoring stations with our equipment was extremely satisfying,” Ritter said. “It’s a huge receiver that we custom make. And it has our logo on it, so everybody knows who built it.”

As for the launch, Ritter said, “Well, it was really a once-in-a-lifetime experience, and I am really appreciative of the GSA having invited me. Looking back at all the work we have done together, being involved in Galileo since the beginning, to actually witness a launch, and knowing the system is now working, showing a solid performance, it was really a nice finish to the race, kind of like putting the lid on the pot.”

The post GSA’s GNSS Opinion Leaders for January 2018 appeared first on Inside GNSS - Global Navigation Satellite Systems Engineering, Policy, and Design.