Studying and testing new and possible future GNSS signals and navigation messages require a signal generator that is flexible and fully modifiable. To overcome the need for implementing a signal generator from scratch, we present a way to modify an existing GNSS software receiver (SR) into a software transceiver (ST). The ST reuses the SR modules and the infrastructure for the signal generation. The modification approach is based on exploiting the vector-tracking feature of the software receiver. Due to the replacement of the position in the vector-tracking loop, it is possible to manipulate the numerical controlled oscillator (NCO) and thereby force the code and carrier generator to generate a signal replica which fits the induced position. Multiplying the replica with the desired symbol value and the desired amplitude yields an entire line-of-sight (LOS) signal. The replica signals of all satellites in tracking match the predefined user trajectory. Saving the added replica signals produces a signal stream at intermediate frequency (IF) which can then be converted to an analog radio frequency (RF) signal. The ST can track, generate, or regenerate tracked signals. The concept and an implementation approach are presented with an assessment of the induced errors arising from this approach. The tracking performance of the generated signals is compared to the theoretical limits.

Research in the field of GNSS signal performance under spoofing, jamming, and multipath comes with the need for reproducing their channels, signals, and scenarios as well as possible. Performance of current signals can be analyzed quite easily as it is possible to use the genuine transmitted signals or use state of the art commercial off-the-shelf (COTS) signal generators to recreate the setup. However, this becomes much more difficult if new signals, channel structures, or navigation messages are under test. Some commercial signal generators have the possibility of implementing new signals and using their own navigation message, but only to a very limited and restricted extent.

To overcome these restrictions, it is necessary to implement one’s own signal generator (see M. Petovello and C. Curran in Additional Resources) to have all the possibilities in creation and testing signals in all desired scenarios. However, implementing a sophisticated signal generator from scratch is a huge, difficult, and time-consuming task.

With an ST it is possible to reuse the sophisticated and optimized infrastructure of an SR for the signal generator. We exploit the fact that each SR must create an estimated replica of code and carrier for the correlation. The key element in our approach is using the software receiver vector-tracking architecture to create the desired LOS parameters for updating the NCO and therefore the code and carrier replica generation (T. Pany and B. Eissfeller).

Feeding the LOS module with the position, velocity, and time (PVT) of a pre-defined receiver trajectory gives an easy opportunity to manipulate the vector-tracking loop to generate replicas as needed to recreate signals that represent the receiver movements. In addition, the desired symbols and amplitudes must be provided to the tracking loops. Multiplying the replica signal with amplitude and symbol yields a new channel IF signal batch of samples. Adding up all channels produces an IF signal stream for a total or even multiple constellations. If required, additive white Gaussian noise (AWGN) can be added before the IF signal batch is written into the output stream. Ionospheric and tropospheric influences are simulated as the line-of-sight parameters are calculated using ionospheric and tropospheric models. The ST is able to track, generate, or regenerate tracked signals. A similar approach for regenerating tracked signals to upgrade existing receivers was presented by Humphreys et alia (Additional Resources).

We first present and explain the SR and the vector-tracking architecture. Thereafter, the modifications are described to convert a software receiver into a software transceiver, using the vector-tracking approach. The implementation as well as error sources are addressed, using the MuSNAT SR as foundation. We assess error sources and finally we compare the tracking and positioning performance of the ST generated signals with the theoretical limits and give examples for the current usage of the ST.

Software Receiver, Vector Tracking Architecture

Vector tracking is an old topic in the GNSS community and was first proposed in 1980 by Copps et alia. Since then, many papers, articles, and books have been published, describing and studying the topic in its full complexity and broadness with all its advantages and drawbacks (see Additional Resources). The references given are far from complete and can only be a starting point for interested readers.

To understand the necessary modifications for transforming a vector tracking-based SR into a signal generator (software transceiver, ST), a brief description of the conventional independent channel tracking architecture and the used vector tracking architecture follows.

All SRs have two main modules defining the processing workflow between the IF sample stream as receiver input and the receiver PVT information as receiver output: the signal processing unit with the tracking loops as its core, and the navigation processor. The signal processing unit, especially the tracking loops, process sample batches of the IF sample stream in sequential order and extract the pseudorange and pseudo range rate p for all tracked satellite signals. These parameters are passed to the navigation processor which then determines the receiver’s PVT.

In a conventional SR, separate and independent tracking loops track each satellite signal as a standalone signal. The signal processing is schematically shown in Figure 1. Each tracking loop consists of a correlator, integrator, discriminator, loop filter, NCO, as well as a code and carrier generator. The code and carrier generator create a replica of the received satellite signal. The replica generation parameters are controlled by the NCO. An early (E), prompt (P), and late (L) version of the generated replica signal is then correlated with the IF sample batch. The values for the integrated correlation signals are dumped and handed over to the discriminator. The discriminator evaluates the E, P, and L values for in-phase (I) and quadrature-phase (Q) and estimates the code time delay error as well as the carrier frequency error and the carrier phase error of the replica signal. Over the loop filter these estimated error values are used to update, i.e., speed up or slow down the NCO, so that the replica signal follows the satellite signal. A detailed description of the signal processing is provided in the Additional Resources. With the replica values, a good estimation of the satellite signal parameters (code delay, carrier Doppler, and carrier phase) can be determined. The satellite signal parameters are used to calculate the pseudorange and pseudorange-rate (Doppler) which are needed for the PVT determination in the navigation module. The update rate of the tracking loops is on the order of 50 to 1,000 hertz, whereas the navigation processor works with a common update rate on the order of 1 to 10 hertz. The loop filter with its bandwidth is used to smooth the high rate values for the NCO update. Therefore, the current smoothed output values of the loop filter are used by the navigation processor at the measurement epoch.

In a conventional SR all tracking loops work independently as mentioned above. This creates the drawback that the tracking loop can easily lose the satellite signal during short periods of signal blockage or signal fading. Even if the signal outage is short, the receiver must start with a reacquisition of the lost signal, which is time- and processing power-consuming. The basic idea of vector tracking is to support the single tracking loop with redundant information from the other tracking loops, so the single tracking loop is able to bridge periods of a weak signal or signal blockage. All satellite signal parameters are defined with respect to the PVT of receiver and satellite. Therefore, the PVT solution of the navigation processor represents the compressed information of the redundant tracking-loop outputs. The vector tracking task is to feedback this redundant information to each single tracking loop, or more precisely, to feedback the best estimation of it. This task can be realized in various forms, some more and some less complex. The more sophisticated approaches usually use some kind of extended Kalman filter (EKF) for PVT estimation (if this filter also includes inertial measurements, it is called a deep GNSS/IMU integration). The implementation used here is sketched in Figure 2, where the PVT algorithm is intentionally left unspecified. An additional module to determine the LOS parameters for all tracked satellites is needed. The satellite position is known from the ephemeris in the navigation message. The navigation module will update the LOS parameter with a rate of 10 hertz (100 ms). The operational update rate of the tracking loop, however, is around 1,000 hertz (1 ms). To overcome this lack of sampling points, a quadratic extrapolation of the LOS parameters is performed, assuming a constant acceleration until the next LOS update. The equations for the code extrapolation look like:

with  

This extrapolation is obviously wrong in the long term but, as we will show later, for the short time span of 0.1 second the approximation works quite well for systems with moderate dynamics. These extrapolated LOS parameters are used to update the NCO in a hard reset fashion. This means that the replica signal changes during the 0.1 second in a smooth fashion, i.e., determined by Equations (1)–(3). After the update of the LOS parameters, however, a jump occurs in the range and range-rate domain of the replica signal parameters. The error of the extrapolation and the jumps of the replica signal are compensated in the pseudorange calculation, as the discriminator determines

For the carrier phase the Doppler values are integrated and reset at the reference epochs to match computed LOS phase values.

Due to the fact that the loop filter is no longer needed to determine the smoothed update values for the NCO, a new decimation filter is needed to provide smoothed pseudorange estimation values to the navigation processor. This can be a Kalman filter as in J.-H. Won et alia, but we use a polynomial fit method, where a vector of discriminator values is fitted with a polynomial function to determine the signal parameters at the measurement epoch (see again, T. Pany and B. Eissfeller).

Software Transceiver

An SR needs to mimic and create the satellite signals as well as possible to be able to track the signal hidden under the noise floor. So, all SRs are already signal generators. The only difference is that an SR reproduces an existing signal and is not creating a new one. To transform the SR vector tracking architecture into an actual signal generator, two main modifications (shown in Figure 3) must be applied.

First, one needs access to the created replica signal which consists of

transceiver implementation following the concept described above. The implementation is based on the Multi-Sensor Navigation Analyzing Tool (MuSNAT) (Additional Resources).

Signal Generation

The MuSNAT SR processes IF sample batches of ~30 ms. This IF sample batch is divided into IF sample frames with a length of ~ 0.8 ms. The sample frames are processed in sequential order. In each processing step, the sample frame is distributed to all Master Channels. Each Master Channel processes one satellite signal and is composed of one or two tracking channels depending on whether the satellite signal has one (data) or two (data and pilot) components. All these channels process the sample frames successively. Due to this sequential workflow, we are able to allocate memory in the receiver with the same size as the IF sample batch and handover memory pointers to the tracking loops. In this way, all tracking loops can add their locally created satellite signal to this memory segment. When the IF sample batch processing is finished, the generated IF sample batch is processed in total. In this final processing step, AWGN can be added and output conversions can be performed. In the conversion step, the generated IF stream output format is set. Internally, the replica signals are stored as double-precision float values, to ensure minimal quantization errors in the signal addition process. For the saving process, the double values can be converted to the desired output format. In this work, either a real-valued 8bit or an I-Q-8bit conversion is used.

For the signal amplitude, we use predefined C/N0 values for each satellite in tracking. The amplitude parameter for each satellite s is defined as a relative amplitude. The reference satellite signal strength is 45 dB-Hz with an assigned reference amplitude of 1, weaker signals are assigned a corresponding smaller amplitude. The calculations were done with the equation

The standard deviation of the AWGN was calculated with:

where Aref=1 and C/N0ref = 45 dB-Hz, as the AWGN is adapted to the reference signal. The equations above were derived from M. Petovello and A. Joseph

where powerequals the sampling rate. SNR and BW denote the signal-to-noise ratio and the bandwidth. The amplitude value can also be used to implement a land mobile satellite (LMS) channel model (A. Lehner and A. Steingass) to simulate more realistic signal propagation conditions including multipath fading and blocking.

The last missing part for the signal generation represents the navigation symbol D. The navigation message has to be pre-produced and is stored in a receiver internal data base. D(t-τ) is selected for each sample frame according to the satellite transmitting time.

Here the SR usage provides the benefit that the data flow is already organized in a way that single frames refer to only one data symbol value.

User PVT Trajectory Feedback

For the user trajectory input we use a text file of the format shown in this example:

where traj is the trajectory time, Px, Py, and Pz represent the user position in the WGS 84 system in meters and represent the user velocity in the WGS 84 system in m/s. The trajectory points (2 hertz) need to be interpolated to the PVT update time steps (10 hertz). To do so, a fourth-degree spline interpolation approach was chosen. The fourth-degree spline interpolation is defined with the following three equations:

The interpolations in the x, y, and z dimension are done independently from each other. The PVT solution also includes values for clock error and clock drift as well as accuracy estimations (mean radial spherical error, MRSE) for position and velocity. Clock error and clock drift are set to zero in a first step, position and velocity accuracy is set to 0.001 m and 0.001 m/s. These parameters can be defined in the trajectory input file and are set as needed. The interpolated PVT solution is handed over to the LOS module.

In this module, the LOS parameters are determined for all satellites in view and above a defined elevation angle. Therefore, the satellite position at the transmitting time is determined. Thereafter, the distance between satellite and receiver is calculated. In addition to Earth rotation and relativistic effects, ionospheric and tropospheric models are applied. The derivatives of the pseudorange are approximated by linear considerations.

In the next step, the LOS parameters are transferred to the tracking loops. Here a second extrapolation step is needed to adapt the sampling rate from the 10 hertz of the navigation process to the 1,000 hertz of the tracking loops. The quadratic extrapolation is already described above in the vector tracking section, see Equations (1)–(3). In the normal vector-tracking process, this approximation is acceptable because the error is compensated by the discriminator value. However, this approximation becomes an issue for the signal generation. The replica is created, following the extrapolated values, and a replica jump occurs at the edge of the last extrapolated point to the first point of the new extrapolation. These jumps could make it more difficult to track the generated signal, especially for the phase tracking. An assessment regarding this error follows in the next section.

Accuracy Assessment

Error model

The interpolation and extrapolation process is visualized in Figure 4 with a sinusoidal movement. Figure 4 is just for illustration purposes of the errors induced by the interpolation and extrapolation processes. To estimate the errors induced by the extrapolation process we use a very simple but representative user/satellite movement model. As the maximum values for

occur when the user movement and the satellite movement are in the same plane, we reduce the three-dimensional problem to the two-dimensional satellite orbit plane. The user movement is assumed to be only in this plane, on a spherical Earth with radius. The satellite orbit is also assumed to be circular with the radius. The 2-D movement model is sketched in Figure 5. In an Earth-centered-Earth-fixed (ECEF) frame, the receiver and satellite position can be calculated with

Error Simulation

With Equations (23)–(25) we can calculate the range, range-rate, and range-rate-rate of a static or dynamic user. In Figure 6 the results for a static user and a user with a very long periodical movement are presented. The long periodical movement with a frequency of 0.001 hertz and a maximum acceleration of 1 m/s2 was chosen as it nicely illustrates the behavior over one total satellite cycle. The receiver movements are visible one-to-one in the range and its derivatives when the satellite has an elevation angle close to zero degrees. In contrast, the receiver movements vanish in the range values for an elevation angle of 90°. This was expected and is of no surprise but shows the correctness of our assumptions. In the next step we calculate the range error ep with Equation (27) and evaluate the maximum error for a specific satellite elevation for an extrapolation time dt=0.1 second. For the static receiver case there are only very small values and small variations for (see Figure 6), therefore, the extrapolation process is uncritical and is below 20 nm for all elevation angles. For a high dynamic receiver case we chose a maximum acceleration of and a movement frequency of 1 hertz. In this case the receiver changes its acceleration from +10 m/s2 to –10 m/s2 in 0.5 seconds. This is similar to an accelerating sports car whose driver later slams on the brakes. The maximum error over the satellite elevation is shown in Figure 7 (High Rx Dynamic). For the medium dynamic receiver case, we chose the values amax=2 m/s2 and f=0.5 hertz, Figure 7 (Medium Rx Dynamic). A low dynamic receiver case is approximated with a maximum acceleration of (acceleration of a train) and a frequency of 0.5 hertz, Figure 7 (Low Rx Dynamic). Comparing the three different cases it is evident that the change in the maximum acceleration (medium versus low) has a similar impact on the total range error as a change in the dynamic frequency (high versus medium). As the approximation assumes a constant acceleration in the extrapolation time dt, it is clear that a fast change in the acceleration creates a significant influence on the range error. The second dominant parameter on the range error is of course the extrapolation time dt. In Table 2 the errors for different simulation parameters are listed for a fixed satellite elevation of 15° and a maximum acceleration of 10 m/s2. If we assume that a carrier phase error (jump) of 1% is tolerable, we end with the requirement <1.9 mm. Therefore, the extrapolation error is only acceptable for low and static receiver dynamics, using an extrapolation time of 0.1 second. If the update rate is increased to 100 hertz, even high receiver dynamics create only small extrapolation errors <<0.1 mm, again, see Table 2).

Results—Pseudorange Verification

To verify the correct implementation and the consistent LOS parameter creation, the values for pseudorange, pseudorange-rate, pseudorange-rate-rate, and the carrier phase were plotted and evaluated using debug information for the respective build ST software module. The pre-defined receiver trajectory resembles a circle with a diameter of ~400 meters and the receiver velocity equals ~60 km/h, which results in a period of ~75 seconds and a frequency of ~0.013 hertz. The trajectory is plotted in Figure 8. The generated satellite configuration consists of eight GPS satellites and seven Galileo satellites, the sky-plot with all generated satellites is shown in Figure 8. The extrapolated LOS parameters of the Galileo satellite with PRN 24, are plotted in Figure 9. In the pseudorange plot and the phase only the satellite motion is visible as the pseudorange is governed by the satellite movement. In pseudorange-rate and pseudorange-rate-rate, however, the velocity and acceleration changes caused by the user movements are clearly visible. In the zoomed plot a constant behavior of and a linear behavior of is observed between the quadratic extrapolation jumps. For the pseudorange, no jump can be detected. These results match perfectly with the above described accuracy assessment. The expected range error for satellite PRN 24 (elevation 24°) with the described receiver movement is only on the order of ~12 μm.

Tracking and Positioning Performance

To check the quality of the generated signal, we compare in a first step the tracking performance of the generated signal with the theoretical value. The used tracking parameters are displayed in Table 3. The tracking results of the ST generated Galileo OS signal of PRN 24 are presented in Figure 10. The measured value for SNR was 27.776 dB and C/N0 = 51.76dB-Hz. According to these parameters, the theoretical values can be calculated as described by Thomas Pany (T. Pany in Additional Resources). The theoretical standard deviation of the code discriminator is. Comparing the measured standard deviation of  small divergence of 2.1% can be observed and is similar to all tracked satellites. The results are very close to the theoretical minimum and proof a nearly perfect channel generation.

In a second step, the Single Point Position (SPP) of the tracking result was compared with the initially defined (“real”) user trajectory. Therefore, the seven Galileo satellites were used for the SPP solution. In Figure 11, the error δ of the SPP solution to the “real” trajectory is plotted in the local east-north-up coordinate frame. The mean position error and the standard deviation error of the SPP position in the east, north, and vertical directions are given in Table 4. The theoretical values are calculated with

where DOP is the Dilution Of Precision value in the corresponding direction and is the pseudorange standard deviation with a theoretical value of 0.090 m. A comparison of the values is given in Table 4. As indicated in Table 4, a gap exists between the theory and the measured noise values of 2–4 decimeters. The reason for the difference is not clarified yet and is under investigation, however, the very small mean position errors prove a bias-free position generation.

Areas of Application

The MuSNAT signal generator was already used to implement and verify Navigation Message Authentication (NMA) (see Additional Resources) foreseen for Galileo Open Service (OS) signals. In this activity, real Galileo satellite signals were recorded and processed with th

e MuSNAT to extract the symbol-stream (navigation message) and satellite ephemeris for each satellite in sight. In the second step, the spare bits in the Galileo E1B INAV navigation message are replaced with the OSNMA authentication bits. Thereafter, the symbol stream, the satellite ephemeris, and the desired C/N0 values for the tracked satellites were read into the GNSS-Transceiver to generate the IF sample-stream file. For analysis, the IF sample file was again processed by the MuSNAT-Transceiver to extract the bits and verify the authentication. The detailed analysis of the NMA is presented by Maier et alia. In the same work, Maier et alia used the MuSNAT signal generator to study the influence of secure code estimation and replay (SCER) attacks (again, see Additional Resources) on a software receiver. In contrast to the NMA test, these tests would not be possible with a COTS signal generator system, due to the need for modifying the generated signal on a deeper level.

Conclusion and Outlook

In this work, it was shown that the conversion of a software receiver into a software transceiver using the vector-tracking approach is feasible and quite easy to realize. The basic concept was presented with an accuracy assessment on the error sources. The implementation of the concept using the MuSNAT software receiver was explained. The quality of the generated signals was compared with the theoretical lower limits. It was shown that the satellite channel could be generated very accurately.

As shown in the accuracy assessment section, the extrapolation range error varies over a wide range, depending on the satellite elevation, the maximum acceleration, the acceleration change rate, and the extrapolation time. The range error is below 1 mm even for high receiver dynamics if an update rate of 100 hertz is chosen. For an update rate of 10 hertz only static and slow receiver movements can be generated with sufficient accuracy. As the current generator settings use an update rate of ~10 hertz, it is planned to increase the update rate and study the possibility of replacing the quadratic extrapolation step with an interpolation, very similar to the trajectory interpolation. To do so, not only the current LOS parameters but also the future LOS parameters need to be passed to the tracking loop. These updates will allow us to create continuous and consistent satellite signals for all possible receiver dynamics. Additionally, the implementation of LMS channel models is planned to increase the realism of the signal generation.

Acknowledgments

This work is funded by the German Federal Ministry for Economic Affairs and Energy on the basis of a decision by the German Bundestag. It is administrated by the German Aerospace Center in Bonn, Germany, (FKZ: 50 NA 1703)

Additional Resources

(1) Copps, E. M., G. J. Geier, W. C. Fidler, and P. A. Grundy, “Optimal Processing of GPS Signals,” NAVIGATION, Volume: 27, Issue: 3, pp. 171-182, 1980.

(2) Fernández-Hernández, I., V. Rijmen, G. Seco-Granados, J. Simon, I. Rodríguez, and J. D. Calle, “A Navigation Message Authentication Proposal for the Galileo Open Service,” NAVIGATION, Volume: 63, Issue: 1, pp. 85-102, 2016.

(3) Galileo SIS ICD, “European GNSS (Galileo) Open Service Signal-
In-Space Interface Control Document,” OS SIS ICD, Issue 1.3, 2016.

(4) Humphreys, T., B. Jahshan, and L. Brent, “The GPS Assimilator: A Method for Upgrading Existing GPS User Equipment to Improve Accuracy, Robustness, and Resistance to Spoofing,” Proceedings of the 2010 ION Conference, Portland, 2010.

(5) Humphreys, T. E., “Detection Strategy for Cryptographic GNSS Anti-Spoofing,” IEEE Transactions on Aerospace and Electronic Systems, Volume: 49, Issue: 2, pp. 1073-1090, 2013.

(6) Institute of Space Technology and Space Applications (ISTA), “MuSNAT,” URL: https://www.unibw.de/lrt9/lrt-9.2/software-packages/musnat/view, September 2018.

(7) Kerns, A. J., K. D. Wesson, and T. E. Humphreys, “A Blueprint for Civil GPS Navigation Message Authentication,” Proceedings of the IEEE/ION 2014 Position, Location and Navigation Symposium (PLANS), pp. 262-269), 2014.

(8) Lehner, A. and A. Steingass, “A Novel Channel Model for Land Mobile Satellite Navigation,” Proceedings of ION GNSS 2005, 2005.

(9) Maier, D., K. Frankl, R. Blum, B. Eissfeller, and T. Pany, “Preliminary Assessment on the Vulnerability of NMA-based Galileo Signals for a Special Class of Record & Replay Spoofing Attacks,” Proceedings of IEEE/ION PLANS 2018, Monterey, CA, pp. 63-71, April 2018.

(10) Pany, T. and E. Bernd, “Use of a Vector Delay Lock Loop Receiver for GNSS Signal Power Analysis in Bad Signal Conditions,” Proceedings of the 2006 IEEE/ION Position, Location, And Navigation Symposium (PLANS), 2006.

(11) Pany, T., Navigation Signal Processing for GNSS Software Receiver, Artech House, 2010.

(12) Parkinson, B. W., P. Enge, P. Axelrad, and J. J. Spilker,Jr., eds., Global Positioning System: Theory and Applications, Volume II, American Institute of Aeronautics and Astronautics, 1996.

(13) Petovello, M.G. and C. T. Curran, “18. Simulators and Test Equipment,” Springer Handbook of Global Navigation Satellite Systems, Springer, 2017.

(14) Petevello, M., M. Lashley, and D. M. Bevly, “What are Vector Tracking Loops, and What are their Benefits and Drawbacks?,” Inside GNSS, May/June, 2009.

(15) Petovello, M. and A. Joseph, “Measuring GNSS Signal Strength,” Inside GNSS, November/December, 2010.

(16) Psiaki, M. L. and T. E. Humphreys, “GNSS Spoofing and Detection,” Proceedings of the IEEE, Volume: 104, Issue: 6, pp. 1258-1270, 2016.

(17) Stöber, C., M. Anghileri, A. Sicramaz Ayaz, D. Dötterböck, I. Krämer, V. Kropp, D. Sanromà Güixens, J.-H. Won, B. Eissfeller, and T. Pany, “ipexSR: A Real-Time Multi-Frequency Software GNSS Receiver,” Proceedings of the IEEE 52nd International Symposium ELMAR, 2010

(18) Wesson, K. D., M. P. Rothlisberger, and T. E. Humphreys, “A Proposed Navigation Message Authentication Implementation for Civil GPS Anti-Spoofing,” Proceedings of the Radionavigation Laboratory Conference, 2011.

(19) Won, J.-H., D. Dominik, and E. Bernd, “Performance Comparison of Different Forms of Kalman Filter Approaches for a Vector-Based GNSS Signal Tracking Loop,” NAVIGATION, Volume: 57, Issue: 3, pp. 185-199, 2010.

(20) Won, J.-H. and T. Pany, eds., “14. Signal Processing,” Springer Handbook of Global Navigation Satellite Systems, Springer, 2017.

The post GNSS Transceiver: Simulation Accuracy Assessment of Using a Vector-Tracking Receiver as RF Constellation Simulator appeared first on Inside GNSS - Global Navigation Satellite Systems Engineering, Policy, and Design.

The signal composition and general architecture of the proposed software receiver implementation are provided along with detailed descriptions of the main signal processing algorithms involved in acquisition, tracking, and telemetry decoding of the navigation signal. Connections to external software by means of traditional format output standards are also presented and validated with real-life signals.

The transmission of new radio navigation signals in a dedicated band has revolutionized the GNSS industry by allowing for crosscompatibility and reduced expenses in receiver design. The concept started with the transmission of the Global Positioning System (GPS) L1 C/A signal, which soon after became the gold standard of radio navigation. GLONASS satellites followed and the constellation reached maturity during the Soviet Union era, but degraded after its collapse. The Galileo constellation finally cemented this idea with the addition of the E1 open service signals. Such efforts prepared the field for international collaboration and signal design around the concept of multi-constellation receiver designs.

The Government of the Russian Federation approved by its Decree No. 587 of 20 August 2001, a budget of 347 billion ruble (US $11.81 billion), running through 2020 by which a federal task program will restore and modernize the GLONASS constellation. The program aims at improving the space, groundbased, and user equipment segments of the system. By 2010, the constellation reached full coverage in Russia and in 2011 full operational capability when the full orbital constellation of 24 satellites was achieved. Aiming to provide better accuracy, multi-path resistance, and especially, greater interoperability with GPS, Galileo, and other GNSS, new GLONASS-K satellites will transmit Code Division Multiple Access (CDMA) signals in addition to the system’s traditional Frequency Division Multiple Access (FDMA) signals. GLONASS system restoration is almost completed and the latest updates seem to indicate that the program is on track and has enough budget to complete its modernization in the future (see Additional Resources, I. Revnivykh). The new modernized system will ensure that GLONASS coherent FDMA and CDMA navigation signal sets will satisfy a wide range of user requirements, from ordinary navigation to high-precision applications.

With the international community moving in this direction, it is more common nowadays to see receiver development focused on CDMA techniques targeting single bands and simplifying the receiver design. Given all this, it is worth asking: Is there benefit in GLONASS FDMA signal processing? What are the advantages of a navigation system processing GLONASS FDMA signals?

Previous research highlights feasibility and effectiveness of cheap jammers on radio navigation signals (T. Kraus et alia; A. D. Fonzo et alia). It can be speculated then that a system moving toward a single band navigation system by means of CDMA exploitation is also extremely susceptible to commercial off-the-shelf jammers and Personal Privacy Devices (PPD). An analysis of commercial offthe-shelf units and PPDs showed how these devices can turn a wide range of CDMA signals completely unusable in their presence (T. Kraus et alia). Interestingly enough, of the seven devices studied, only 10% were capable of blocking the bands where GLONASS and its frequency channels operate (Tables 1 and 2). Taking advantage of the processing of GLONASS FDMA signals is not a direct anti-jamming or anti-spoofing technique, but use of these signals does make it harder to harm the system.

Another interesting case was the recently reported episodes of GPS spoofing happening in the Black Sea (S. Goff). Given the resources available, receivers can no longer simply rely on one single constellation or the other. The future lies in the design of receivers capable of mixing solutions from multiple constellations in a wide range of frequencies. Maybe the presence of a GLONASS capable receiver would have avoided the spoofing by allowing the system to eliminate the compromised GPS measurements and perform navigation with the aid of the GLONASS FDMA signals, assuming of course that the latest signals were not also

spoofed in the area during those episodes.

This work presents a new signal addition to the Global Navigation Satellite System Software Defined Radio (GNSSSDR) platform, making the receiver more robust and diverse. With the GLONASS L1 C/A signal addition, the GNSS-SDR software receiver is available for a new set of applications based on the use of the GLONASS FDMA signals. Given the points made earlier, it seems that receivers taking advantage of a new signal could be better prepared against malicious attacks of any kind. This work is not of course the first implementation of the GLONASS L1 C/A signal and there are multiple implementations by commercial off-the-shelf receivers that support this signal without major issues. Such commercial receivers come with a high price tag that could be a barrier in low funded applications or studies. Some open source versions also support the GLONASS L1 C/A signal, like GNSSSDRLIB, but its software implementation is limited to only the Windows 64 bits platform, does not takes advantage of the latest Intel Advanced Vector Extensions (AVX), and does not support its exportation to available embedded platforms (T. Suzuki and N. Tubo).

GNSS Software Receivers

Since the advent of the Software Defined Radio (SDR), an increasing number of GNSS software receivers have been developed by members of the navigation community. Typical implementations will use low level programming languages like C or C++ in order to achieve a real time receiver running in a general

purpose computer or an embedded platform. Another design approach implements the receiver in a high level programming language like MATLAB or Python, and develops a software receiver ideal for post-processing applications. Popular and open source implementations include GNSS-SDR, GNSSSDRLIB, and SoftGNSS. GNSS-SDRLIB, mainly developed by Taro Suzuki was developed in C and uses the RTKLib navigation engine for computation of the position solution (T. Suzuki and N. Kubo). The software receiver supports all major constellations and signals providing acquisition, tracking, and pseudorange metrics for post-processing analysis. This software receiver, however, is no longer under active development. On the other hand, softGNSS is a software receiver for post processing analysis developed in MATLAB, source code of the receiver is provided with the book that introduces it (K. Borre et alia), and it provides code for a GPS L1/CA signal receiver. Even though multiple efforts have been directed towards extending the receiver capability with the addition of new signals and features, its MATLAB implementation does not make this software receiver adequate for real time signal processing. Another important contribution to the community comes with the software receiver developed by Thomas Pany and his book on GNSS signal processing (see Additional Resources), which introduces key concepts of GNSS software processing in personal computers and discusses several common techniques that can be used to achieve real time processing. In the author’s opinion, a major contribution of this book was the usage of assembly language to accelerate common operations on GNSS signal processing.

There are also commercially available software receivers for use in the community. The business approach for this concept mostly includes a combination of IP core licensing and/or royalties for its use. The commercial implementations will serve multiple applications such as multipath and spoofing evaluation, ionosphere scintillation, interference monitoring, etc. One such software receiver version is capable of running in real time more than 300 channels in a general purpose computer with an Intel Core i7-7490k processor. The solution also provides a hardware front end for data collection and is integrated with the software receiver provided (see Manufacturers section near the end of this paper). Other options will provide free academic versions (normally introduced with a textbook) (I. Petrovski and T. Tsujii) and will then charge for a professional version of the software, including one which will also have the option of a custom Radio Frequency (RF) front end to interface with the software receiver. The result of years of experimentation with software radios as applied to GNSS technologies is a well-established set of tools for the scientific community with plenty of options to pick from depending on end applications, budgets, and experience in the field of radio navigation.

GNSS-SDR

Development of the work presented here was accomplished with GNSS-SDR. This is an open source receiver developed in C++ that uses the GNURadio Application Programming Interface (API) to develop a real time software receiver. The high level of flexibility and re-configurability makes this implementation a very appealing solution to an ever increasing radio navigation signal environment. GNSS-SDR provides an interface to different suitable RF front-ends and implements the entire receiver chain from signal reception up to the navigation solution. Its design allows any kind of customization, including interchangeability of signal sources, signal processing algorithms, interoperability with other systems, and output formats, and offers interfaces to all the intermediate signals, parameters, and variables (C. FernándezPrades et alia, 2011). GNSS-SDR runs on a personal computer or an embedded platform and provides interfaces through Universal Serial Bus (USB) and Ethernet buses to a variety of either commercially available or custom-made RF. As an object-oriented platform and with the idea of keeping a sense of abstraction in the blocks developed, GNSS-SDR is divided into several processing blocks that participate in the whole process of navigation for receivers. These blocks (Figure 1) are part of the abstraction level in the software and can be divided as follows: 1) Signal Source Blocks: Hide the complexity of accessing each specific signal source, providing a single interface to a variety of different implementations. 2) Signal Conditioner Blocks: Adapt the sample bit depth to a data type tractable at the host computer running the software receiver, and optionally intermediate frequency to baseband conversion, resampling, and filtering. 3) Channel Blocks: Encapsulate all signal processing devoted to a single satellite. This is a large composite object which encapsulates the acquisition, tracking, and decoding modules. 1) Acquisition Blocks: Provide a coarse estimation of two signal parameters: the frequency shift (f d ) with respect to the nominal Intermediate Frequency (IF) frequency, and a code delay term (τ) of in view satellites relative to the shifted version of the local code replica. 2) Tracking Block: Aims to perform a local search for accurate estimates of code delay and carrier phase, with their eventual variations based on the input provided by the acquisition block. 3) Telemetry Decoder Block: Detects and decodes the navigation message containing the time the message was transmitted, orbital parameters of satellites (ephemeris), and an almanac. 4) Observables Block: Collects all the data provided by every tracked channel, aligns all received data into a coherent set, and computes the observables (pseudorange, carrier phase, etc.). 5) Position Velocity and Time (PVT) Block: Computes the position solution of the receiver based on all the data generated by the previous block.

Extending the Receiver to GLONASS Processing

Due to its different layers of abstraction, prototyping of the GLONASS L1 C/A signal was done rapidly in the code base. Figure 2 shows the blocks of code added to the system and its object oriented properties relationship with the core blocks of the receiver. Note that the figure only displays the blocks created or modified for GLONASS L1 C/A, and is by no means a detailed Unified Modeling Language (UML) diagram of the objects present in the platform. It is worth mentioning that the GNSS-SDR platform uses some of the key concept ideas of GNU Radio in the sense that it has an abstract block upon which all other interfaces and implementations are based. The block GNSSBlockInterface defines a set of basic properties common to all objects that inherit its properties. Direct descendants of this GNSSBlockInterface are interfaces that describe the software receiver, which range from a Channel interface to a PVT interface that serves as the top layer of the software. Once the basic layers of the GNSS-SDR are defined, then the adapter blocks are used to implement the basic methods of these interfaces and define some others if required (C. Fernández-Prades et alia, 2012). This in particular allows for an extremely flexible design in which adapter blocks could be swapped depending on the algorithm or signal to be processed. At the same time, each adapter block’s dependencies connect GNSS-SDR with the GNU Radio API inheriting some functionality of the gr::block upon which the entire GNU Radio platform is defined.

GLONASS FDMA Signal Model

GLONASS satellites orbit Earth at a 64.8 degree inclination (GPS uses six planes at 55 degrees). This inclination is ideal to ensure good coverage of polar latitudes, where a significant portion of the Russian Federation territory is located. The satellites have an altitude of around 19,100 kilometers in a nearly circular orbit with eccentricity near 0 (again, see Additional Resources). The previous orbital parameters make the satellites have an orbital period of 11 hours, 15 minutes, and 28 seconds, with repeating ground tracks every 7 days, 23 hours, 27 minutes, and 28 seconds. As mentioned before, the GLONASS system uses FDMA for its C/A signal. The system now has allocated 14 frequency channels in the L1 band that are spaced from each other with a constant frequency offset. The received signal can be described as per Equation (1): where: PC is the power of signals with C/A code, C k is the C/A code sequence assigned to satellite number k, τ is the code phase received in ground, Dk is the navigation data sequence, f kL1 is the nominal value of the FDMA L1 carrier frequencies, f d is the Doppler frequency seen in the ground, and n is the received noise. The nominal values of the FDMA L1 carrier frequencies are defined by Equation (2): where: k = represents the frequency channel, f 0L1 = 1602 MHz for the GLONASS L1 band, and ∆f L1 = 562.5 kHz frequency separation between GLONASS carriers in the L1 band. Since a total of 24 satellites populate the constellation and only 14 frequency channels are available, GLONASS satellites will share some frequency channels but only when in antipodal positions, i.e., satellites in opposite position on Earth. General parameters of this signal are defined in Table 2.

Signal Source & Signal Conditioner

The Signal Source block hides the complexity of accessing each specific signal source, providing a single interface to a variety of different implementations. Each implementation will target the parsing of data from specific front ends or custom formats in a raw file. It will then transform it to the standard used by the receiver. Using the NT1065 front end (N. C. Shivaramaiah et alia) data was collected across the GLONASS L1 frequency band and minor modifications to the signal source blocks were added to parse the data previously stored in a file. The Signal Conditioner block oversees adapting the sample bit depth to a data type tractable at the host computer running the software receiver, and optionally intermediate frequency to baseband conversion, resampling, and filtering. Regardless of the selected signal source configuration, this interface delivers a sample data stream to the receiver processing channels, acting as a facade between the signal source and the synchronization channels.

Acquisition

The role of an Acquisition block is the detection of signals from a given GNSS satellite. As per Equation (1),

in the case of a positive detection, it should provide coarse estimations of the code phase (τ) and the Doppler shift (f d ) to initialize the delay and phase tracking loops. Since GLONASS FDMA uses a gold code to detect time delay, acquisition techniques developed for GPS L1 C/A were modified to accommodate GLONASS processing. GLONASS signal acquisition can be seen as that of GPS L1 C/A, but instead of looping over different Pseudo Random Noise (PRN) code values, the code will loop over a single code at different frequency channels k. After frequency channel removal, the typical Parallel Code Phase Search (PCPS) algorithm (D. Akopian) (Figure 3) can be used for acquisition. Most importantly, this approach reuses previously developed blocks in the platform, which allows for this flexible level of abstraction within the internal software architecture. Figure 4 shows the acquisition results for a GLONASS satellite in real data collection. The significant peak in the figure indicates a positive signal detection on a frequency channel.

Tracking

The Tracking block is also receiving the data stream xIN, but does nothing until it receives a “positive acquisition” message from the control pane, along with the coarse estimations τacq and f dacq. Then, its role is to refine such estimations and track their changes along time. Three parameters are relevant for signal tracking: the code phase (τ), Doppler frequency (f d ), and carrier phase (ψ). As with the signal acquisition, GLONASS L1 C/A signal tracking reuses blocks developed for the legacy GPS L1 C/A signal tracking. The main difference to consider is the removal of the frequency channel offsets from IF due to its FDMA properties. After carrier removal happens, tracking for GLONASS could be treated as a typical GPS L1 C/A tracking module (Figure 5). Re-usability of existing

blocks reduces code complexity and highlights the benefits of flexibility within the platform. Tracking results are shown in Figure 6. The values for the C/ N0 , carrier frequency (relative to nominal frequency channel), and code frequency are shown in the bottom, while a discrete time scatter plot showing phase lock with bits of navigation is shown up top. Due to the effect of the meander sequence present in the GLONASS Navigation Message (GNAV) message (see Additional Resources), bits of navigation need further processing before decoding can be applied to the signal. WORKING PAPERS FIGURE 3 Generic PCPS acquisition implementation in GNSS-SDR Incoming signal Output Buffering Local oscillator Circular Shift Gold Code IFFT 1 | 2 FFT FFT 90 deg conj Q r FIGURE 4 Acquisition Results for GLONASS Satellite Number 22 in the GNSS-SDR platform Code Delay (chips) 0 –10000 –5000 0 5000 100 200 300 400 Dopler Shift (Hz) Acquisition metric (µ) ×1013 18 16

Telemetry Decoding

Telemetry Decoding block decodes the navigation message for the signal. Once the signal is properly tracked , the Tracking block will start to populate the required fields in the gnss_ syncro object, which ser ves as the pipeline between the implementation of the blocks in the channel. The symbols populated in gnss_syncro will be used to decode the GNAV message after the meander sequence has been removed, as shown in Figure 7. GNAV decoding is a very straightforward process that requires careful bookkeeping between the bit position for each of the fields in the string, which is carefully described in its Interface Control Document (ICD) (see Additional Resources). Following the design pattern of GNSS-SDR, the decoded data was divided into four objects, named Glonass_Gnav_Ephemeris, Glonass_Gnav_Navigation_Message, Glonass_Gnav_Utc_Model, and Glonass_Gnav_Almanac, holding the relationships described in Figure 2.

Observables

The Observables block generates by default three types of measurements for processing in the navigation solution computation. These measurements include pseudo-ranges, accumulated carrier phase, and Doppler frequencies. All of this is generated through a single object called Hybrid_Observables, which computes these measurements in a generic way across all channels. As such, work in this area was minimalistic and only consisted of managing the information flow between the Telemetry Decoder and Observables block. Nevertheless, a proper definition of the measurements as per the GNSS-SDR platform is offered for clarity. Pseudorange Measurements The basic observation equation for the pseudorange as given by K. Borre et alia, assuming that is geometric pseudorange from satellite k to the receiver i, c is speed of light, δti is receiver clock offset, δtk is satellite clock offset, is tropospheric delay, and is ionospheric delay, is Accumulated Carrier Phase Measurements Following the same definition of pseudorange, the carrier phase can be defined as a measurement of ranges as defined in Equation (4) The last term of the equation represents the initial unknown ambiguity in the cycle number relating to the distance between receiver and satellite. However, when applying a differentiation of continuous carrier phase measurements, ambiguities in the number of cycles are eliminated due to the fact that for continuous carrier phase measurements, the ambiguity will be the same in both cases. The result is a measurement of the range rate defined as:

Doppler Shift Measurement

The Doppler effect is the change in frequency for an observer (in this case, the GNSS receiver i) moving relative to its source (in this case, a given GNSS satellite k). Equation (6) gives the relationship between observed frequency f i and emitted frequency f k : Since the speeds of the receiver vi(t) and the satellite v k are small compared to the speed of light c, the difference between the observed frequency f i and emitted frequency f k can be approximated by Then, the Doppler Effect measurement can be written as where r r (t) and vr (t) are the position and velocity of the receiver at the instant t. The term v (s)(t(s)) − vr (t r ) T is the radial velocity from the receiver relative to the satellite, and and are the receiver and satellite clock drift, respectively. The Doppler Effect measurement is given in Hz.

PVT

The PVT solution in GNSS-SDR currently uses a module created based on the RTKLib library. As such, the GLONASS integration to this module was only in charge of providing the necessary conversion tools to translate from
the GNSS

-SDR modules to the RTKLib input. All conversion parameters were developed following the description of the RTKLib API library (T. Takasu and A. Yasuda). To test the code developed and presented in this work, a GNSS data logger using the NT1065 front end was used. The data logger of this device allowed for mult

i-frequency, multiband collection at the same time. For this study, the specific configuration loaded in the device’s firmware targeted a data collection for GPS L1 C/A, GLONASS L1 C/A, GLONASS L2 C/A, and GPS L2C, simultaneously. Figure 8 shows the first position solution for GLONASS L1 CA signals ever achieved by GNSSSDR. The figure shows the position of the receiver in the Earth Centered Earth Fixed (ECEF) coordinate frame with the position covariance for each of the components. The figure also plots the clock variation error, the number of observations used during the position computation, and the estimated position across the X and Y components relative to the true antenna position. Finally, the 90% Circular Error Probable (CEP) statistic, as per the description by G. M. Siouris, is shown. Case Study: Performance under RFI A Radio Frequency Interference (RFI) tone was introduced in the data set collected for the GPS L1 C/A signal, simulating a scenario where a common Continuous Wave (CW) PPD device will null the operating band of the signal. Typical RFI devices, such as those described in Table 1, were studied and a pulse mimicking their behavior was generated to null the band. The simulated interference in the band was inserted 60 seconds into the collected data (allowing initial position solution computation) and lasted for about 20 seconds. Figure 9 shows the position solution generated by GNSSSDR under the presence of a nulling RFI tone. After 60 seconds of data processing, the position solution stops, resuming around 50 seconds later. This indicates the inability of the receiver to compute its position. Also of interest is the fact that after the RFI resumes, the receiver will need to spend time to decode the ephemeris data before being able to compute a position solution unless some intelligent signal processing technique is applied to reuse the previous decoded ephemeris. If under the assumption of this experiment, a PPD device as in Table 1 is used, then the GLONASS FDMA signals could be used to keep the position solution active, even during the jamming period. Results of this scenario are shown in Figure 10. The receiver, when using a combined solution of GPS L1 C/A and GLONASS L1 C/A, is able to provide position estimates even though the RFI tone is nulling the GPS L1 band. Due to the reduction in the number of observations when the GPS L1 band is nulled, a small performance hit is seen but no loss of the position solution happens, which is the cumbersome mission of the proposal.

Conclusion

This article presents the first-ever position solution of GLONASS L1 C/A in the GNSS-SDR platform. This addition will allow the receiver to take advantage of the FDMA signals available in the radio navigation spectrum and will open a new set of tools for the scientific community to use in the diverse field of GNSS processing. Addition of the GLONASS L1 C/A in a combined position solution is a simple but effective technique to aid the overall position solution of a receiver when in the presence of RFI or spoofing attacks. We also present a detailed description of the process of signal addition to the GNSS-SDR platform and serves as a template for developers with the intention of contributing to the platform.

Acknowledgments

This material is based upon work partially supported by the National Science Foundation Graduate Research Fellowship under Grant No. DGE 1144083 and the Google Summer of Code (GSoC) 2017 program. Special thanks to the GNSS-SDR team mentors during the GSoC 2017 program including Luis Esteve, Carles Fernandez–Prades and Jordi Vilà Valls. In addition, special thanks to Professor Dennis M. Akos for providing some of the data sets used during the testing stage and to the editors of this manuscript Dr. Nagaraj Channarayapatna Shivaramaiah, Sara Hrbek, and members of the University of Colorado at Boulder Wri

ting Center. Manufacturers The first software receiver described in the GNSS Software Receivers section of the article and in Additional Resources (Pany et alia, 2012) is the SX3 software receiver developed by IFEN GmbH from Poing, Germany. Another commercial receiver discussed in the section was the ARAMIS from iP-Solutions with offices in Japan, UK and the U.S. Additional Resources 1. Akopian, D., “Fast FFT based GPS Satellite

Acquisition Methods,” IEE Proceedings – Radar, Sonar and Navigation, Volume: 152, Issue: 4, 2005 2. Borre, K., D. Akos, N. Bertelsen, P. Rinder, and S. Jensen, A Software-Defined GPS and Galileo Receiver: A Single-Frequency Approach, Applied and Numerical Harmonic Analysis, Birkhäuser, 2007 3. Fernández–Prades, C., J. Arribas, P. Closas, C. Avilés, and L. Esteve, “GNSS-SDR: An Open Source Tool For Researchers and Developers,” Proceedings of the ION GNSS 2011 Conference, Portland, OR, 2011 4. Fernández–Prades, C., J. Arribas, L. Esteve, D. Pubill, and P. Closas, “An Open Source Galileo E1 Software Receiver,” Proceedings of the 6th ESA Workshop on Satellite Navigation Technologies (NAVITEC ’12), ESTEC, Noordwijk, The Netherlands, 2012 5. Fonzo, A. D., M. Leonardi, G. Galati, P. Madonna, and L. Sfarzo, “Software-Defined-Radio Techniques Against Jammers for In-Car GNSS Navigation,” 2014 IEEE Metrology for Aerospace (MetroAeroSpace), 2014 6. Goff, S., “Reports of Mass GPS Spoofing Attack in the Black Sea Strengthen Calls for PNT Backup,” Inside GNSS, 2017 7. Kraus, T., R. Bauernfeind, and B. Eissfeller, “Survey of In-Car Jammers – Analysis and Modeling of the RF Signals and IF Samples (Suitable for Active Signal Cancelation),” Proceedings of the 24th International Technical Meeting of the Satellite Division of The Institute of Navigation (ION GNSS 2011), Portland, OR, 2011 8. Pany, T., Navigation Signal Processing for GNSS Software Receivers, GNSS Technology and Applications Series, Artech House, 2010 9. Pany, T., N. Falk, B. Riedl, T. Hartmann, G. Stangl, and C. Stöber, “An Answer for Precise Positioning Research,” Innovation: Software GNSS Receiver, 2012 10. Petrovski, I., and T. Tsujii, Digital Satellite Navigation and Geophysics: A Practical Guide with GNSS Signal Simulator and Receiver Laboratory, Digital Satellite Navigation and Geophysics, Cambridge University Press, 2012 11. Revnivykh, I., “Glonass Programme Update,” 11th Meeting of the International Committee on Global Navigation Satellite Systems, Sochi, Russian Federation, 2016 12. Russian Institute of Space Device Engineering, “Global Navigation Satellite System (GLONASS) Interface Control Document, Navigational Radio Signal in Bands L1, L2,” Technical Report, Moscow, 2008 13. Shivaramaiah, N. C., D. M. Akos, and K. Yan, “A Multi-band GNSS Signal Sampler Module with Open-Source Software Receiver,” Proceedings of the 29th International Technical Meeting of the Satellite Division of The Institute of Navigation (ION GNSS+ 2016), Portland,

OR, 2016 14. Siouris, G. M., Aerospace Avionics Systems : A Modern Synthesis, Academic Press, 1993 15. Suzuki, T. and N. Kubo, “GNSS-SDRLIB: An OpenSource and Real-Time GNSS Software Defined Radio Library,” Proceedings of the 27th International Technical Meeting of the Satellite Division of The Institute of Navigation (ION GNSS 2014), Tampa, FL, 2014 16. Takasu, T. and A. Yasuda, “RTKLIB ver. 2.4.2 Manual,” No. C, 2013

Authors

Damian Miralles is a graduate student in the Department of Aerospace Engineering Sciences at the University of Colorado Boulder. He received a B.S. in Electrical and Computer Engineering from the Polytechnic University of Puerto Rico. His research interests are in GNSS receiver technologies, software defined radio and digital signal processing.

Gabriel F. P. Araujo is an undergraduate student in the Faculty of Technology at the University of Brasilia, Brazil, and scholarship researcher at LARA (Automation and Robotics Laboratory). He works with robotics estimation and navigation. He is currently working with SDR development, a software-defined radio for mobile robot localization using multi-constellation GNSS systems.

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 organizing 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 in 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 a Fellow of ION in 2011. The Technical University of Prague honored 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 Robustness Improvements for the PVT Solution via Consideration of GLONASS in a GNSS Software Defined Receiver 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.

***

Authors: Pauline Martin Thales Alenia Space Thibaud Calmettes Thales Alenia Space Yoan Gregoire CNES Mercedes Reche PILDO LABS Christophe Chatain ECAGROUP Michel Monnerat Thales Alenia Space

On June 1, 2009, the Air France AF447 flying from Paris to Rio experienced a stall that led to the crash of the aircraft in the Atlantic Ocean with 228 passengers and crew members onboard. As the aircraft was transmitting its location nominally only every 10 minutes, the location of the accident site could not be determined with a good accuracy. The search efforts to recover the wreck and the flight data recorder lasted almost 2 years, involving significant aeronautical, maritime and sub-maritime equipment, leaving open the threat that the still unexplained cause of the accident could be at the origin of a similar one in the meantime. Finally, the wreck and the victims were localized in spring 2011 thanks to a submarine robot. The total cost of the operations amounts to more than €34 million, or about $41 million US dollars. 

Later, on March 8, 2014, the Malaysia Airlines MH370 flying from Kuala Lumpur to Beijing disappeared with its 239 passengers and crew members. Four years later, the mystery remains despite the more than 33 months of research and the approximate amount of $200 million US dollars spent in the recovering operations by 26 countries. Contrary to the case of the AF447, the MH370 was not even transmitting its location every 10 minutes and all communication links with the aircraft were shut down.

These two tragedies have highlighted the limitations of the existing air navigation and distress systems: with extensive identification and localization delay of the aircraft in distress, the effectiveness of Search And Rescue (SAR) efforts and recovery operations is dramatically reduced. In both cases, no distress messages transmitted by the Cospas-Sarsat Emergency Locator Transmitters (ELT) distress beacons (mandatory on-board any commercial aircraft by International Civil Aviation Organization [ICAO] requirements) were received by the SAR ground segment. The current ELTs are designed to be triggered automatically further to a shock or upon activation by water (typically after a crash or a hard landing on ground or into the ocean) or manually to transmit a distress signal at 406 MHz for at least 24 hours. For flights AF447 and MH370, no alert messages transmitted by the ELT were received. The reasons are still unknown but several hypotheses can be formulated: the transmission system was damaged at the impact and transmission could not occur, or the wreck and the distress beacon sank very quickly before the beacon could transmit its first distress message. Without the alert messages, no information independent of the aircraft systems was available to determine the position of the crash for both the AF447 and the MH370 after all the aircraft equipment failed. To prevent this situation from occurring again in the future, the solution would be to be able to receive information about the location of the aircraft during the in-flight distress phase. Based on this, ICAO and the international aeronautical community carried on activities to reconsider the effectiveness of the existing SAR operations by improving the in-flight tracking of the aircrafts during the entire flight and under all circumstances, including normal flight and distress. The activities of the Ad-hoc Working Group on Aircraft Tracking led to the definition of a Global Aeronautical Distress and Safety System (GADSS) and additional amendments to the ICAO Annex 6 divided into 3 functions (Figure 1):

• Aircraft Tracking (AT): transmission of data of time and position or information to determine the position of the aircraft at least every 15 minutes during normal flight phase

• Autonomous Distress Tracking (ADT): transmission of time and position or information to determine position of the aircraft at least every minute during in-flight detected distress phase

• Post Flight Localization and Recovery (PFLR): localization of flight data recorders thanks to beacons associated to the FDR.

The ADT function requirement is the answer to the AF447 and the MH370 accidents and its necessity has been confirmed by other aeronautical accidents (like the Egyptair MS804): by initiating the tracking of the aircraft during in-flight distress phase and with the availability of transmitting accurate time and position data, the probability to receive a distress message is increased, as well as the accuracy of the location of the crash area. The evolution of the Cospas-Sarsat system, mandatory onboard all commercial aircraft, into an ADT system appeared as an appropriate solution and is further described in the following sections.

Cospas-Sarsat Solution to ADT Recommendations

a. The Cospas-Sarsat program

The International Cospas-Sarsat Program provides accurate, timely and reliable distress alert and location data to help SAR authorities assist persons in distress. The objective of the Cospas-Sarsat system is to reduce, as much as possible, delays in the provision of distress alerts to SAR services, and the time required locating a distress and providing assistance, which have a direct impact on the probability of survival of the person in distress at sea or on land. To achieve this objective, Cospas-Sarsat Participant governments and agencies implement, maintain, coordinate and operate a satellite system capable of detecting distress alert transmissions from radio-beacons that comply with Cospas-Sarsat specifications and performance standards, and of determining their position anywhere on the globe. The distress alert and location data is provided by Cospas-Sarsat Participants to the responsible SAR services. Cospas-Sarsat cooperates with the ICAO, the International Maritime Organization (IMO), the International Telecommunication Union and other international organizations to ensure the compatibility of the Cospas-Sarsat distress alerting services with the needs, the standards and the applicable recommendations of the international community. It is today the most important worldwide rescue system, having been used from 1982 to December 2016 to provide assistance in rescuing at least 43,807 people in 12,664 events.

From the beginning, Cospas-Sarsat has been integrated to aircraft safety and security systems with two types of beacons: ELT (Emergency Locator Transmitter), attached to the aircraft and mandatory in most of them; and PLB (Personal Locator Beacons), attached to the pilot, widely spread in general aviation. Aviation domain today represents 20% of the 2 million deployed beacons. In 2016, the Cospas-Sarsat system answered to 876 SAR events (177 distresses were related to the aviation domain); contributing to save 2,057 lives (355 lives involved in aeronautical SAR events). Thanks to the efficient communication link between the Cospas-Sarsat Mission Control Centre (MCCs), and the Rescue Coordination Centers (RCCs), the ground operational segment of Cospas-Sarsat in general, and the aeronautical branch in particular, has reached the rank of the most performing SAR system as Cospas-Sarsat has been involved in half of the distress events managed by RCCs around the world.

Over the last 34 years, with 30 operational MCC deployed in 30 countries all around the world, and more than 100 RCC/SPOC, Cospas-Sarsat consolidated its international SAR network and earned a rich experience in coordination of information and rescue means in all the events it treated. Every year, new countries join the program and contribute to the Cospas-Sarsat ground segment.

Today, the Cospas-Sarsat space segment is composed of five satellites in Low-Earth Orbit, eight satellites in Geostationary Orbit, and 37 satellites in Medium Earth Orbit, equipped with SAR payloads to receive and forward distress messages broadcasted by the Cospas-Sarsat SAR beacons. The Cospas-Sarsat system is free of charge for the user and entirely financed by the partners of the program.

Figure 2 illustrates the nominal operation chain of the Cospas-Sarsat system and the Return-Link use (violet arrows); the three space segments of Cospas-Sarsat are represented: the Low Earth Orbit SAR (LEOSAR) space segment, the Medium Earth Orbit SAR (MEOSAR) space segment and the Geostationary orbit SAR (GEOSAR) space segment:

1. Distress beacons are activated by aircraft (ELT and ELT(DT)), ships (EPIRB: Emergency Position Indicating Radio Beacon) or individual users (PLB: Personal Locator Beacon)

2. The SAR payloads aboard Cospas-Sarsat satellites (including Galileo satellites) relay the alert to LUT

3. The Local User Terminals (MEOLUT, LEOLUT and GEOLUT) detect, demodulate and localize the distress beacon signals

4. The LUT forwards the alert data (including the independent location computed by MEOLUT and LEOLUT) to the appropriate MCC (i.e. the MC in charge of the area where the beacon is localized)

5. The Mission Control Centres (MCC) distributes alert data to Rescue Coordination Centres (RCC)

6. RCC organizes and coordinates SAR services and operations

In addition, each Cospas-Sarsat beacon can be localized either thanks to the position encoded in the alert message transmitted or by the independent localization of the alert provided by the Cospas-Sarsat ground segment. This independent localization is based on the capacity to localize the beacon that transmitted the signal based on the reception characteristics of the signal by the Cospas-Sarsat ground segment. With the LEOSAR system, it relies on the Doppler effect but requires several bursts and is disturbed by the beacon motion, with the MEOSAR system relying on the Frequency of Arrival and Time of Arrival of the signal and basically consists in a triangulation just like what is done with GNSS. It eliminates the risks linked to GNSS, as the SAR operators dispose at any time of an estimation of the location of the beacon.

b. ELT(DT) used in the MEOSAR system

In parallel of the MEOSAR evolution, Cospas-Sarsat is also developing new standards of beacons:

• ELT(DT) (Emergency Locator Transmitter for Distress Tracking) a special type of beacon designed to be activated in flight as soon as a distress situation is detected

• SGB (Second Generation Beacons) specially optimized for MEOSAR system and offering an improved performance (detection and independent localization accuracy) compared to current beacons. SGB standard will cover all types of Cospas-Sarsat beacons.

ELT(DT): the Cospas-Sarsat ADT Solution

In order to answer ICAO requirement of Annex 6 for ADT, Cospas-Sarsat has been working on a new beacon standard named ELT(DT). Compared to other types of beacons used in Cospas-Sarsat (EPIRB, ELT, PLB), ELT(DT) has been designed for a particular use case: being activated in flight upon a distress situation. This use case involves additional constraints that were taken into account during the specification phase:

• Based on BEA (Bureau Enquête et Analyse: French Office for Aeronautical Accidents Investigation) studies, it appears that in many cases an aircraft will impact the surface within just a few minutes after the detection of the distress situation. At impact, the beacon and/or the external antenna on the fuselage may be destroyed or the aircraft may sink underwater. In both cases, it is no longer possible to receive signals from the beacon. It was then determined that the beacon has to transmit its signal as soon as a distress situation is detected and until the crash, with a repetition rate high enough to get a sufficient detection probability at ground stations and to make sure that the last burst is not too early before the crash:

■ Transmission of the first burst 5 seconds after reception of the trigger (manual or automatic)

■ A repetition rate of:

• 5 seconds during the first 120 seconds after activation

• 10 seconds after the first 120 seconds and before 300 seconds after activation

• 30 seconds after 300 seconds after activation

• A special transmitted message was designed to indicate at least:

■ The trigger which activated the beacon (automatic trigger or manual trigger)

■ The encoded location from an integrated GNSS receiver

Last but not least, one can note that the MEOSAR system is well suited to process ELT(DT) signals as it allows instantaneous detection and global coverage. MEO satellite visibility offers redundancy then allowing for a high detection rate of the signals. Moreover, if a signal is detected through a sufficient number of satellites, the ground station can compute an independent location associated with speed estimation. Finally, completed by an internationally well-known ground segment for the distribution of the alerts between countries and geographical areas, Cospas-Sarsat offers an efficient solution to ADT.

Another advantage of the Cospas-Sarsat solution is the possibility to combine the ELT(DT) function with a legacy ELT beacon which triggers on crash. Into a single device, it is then possible to answer to both ICAO requirements for ADT and for ELT with minimum evolutions on the aircraft. The specification for this combined solution is currently refined in standardization bodies, in particular in terms of use of homing signal and battery duration, but this would be a significant additional advantage of the solution. To comply with existing environmental and test conditions (lightning, radiofrequency, altitude, pressure, shocks, vibration, fire, transmission duration), ELT(DT) also have now to comply with recent aeronautical standards (DO 160, ED 162) and quality standards: REACH, ROHS, EMC and ESD including documentation, being understood that those requirements have to be fulfilled without any compromise on product availability and reliability, offering ELT(DT) with higher performance requirements.

The Cospas-Sarsat ADT solution has been defined and specified in aeronautical standardization bodies for Europe (EUROCAE) and North America (RTCA) through documents ED-62B and Doc10054, under consolidation and with an expected closure date by June 2018. Currently, it is the only ADT system for which such specification exists, which should ease the support to its adoption.

MEOSAR: Enhancing Location Performance

The MEOSAR system will be interoperable with the current 1.9 million deployed First Generation Beacons. While the LEOSAR and GEOSAR systems have been used for decades, the MEOSAR system just entered in early operations capability in December 2016. The evolution towards MEO orbits is supported by GNSS constellations (Galileo, GPS and GLONASS and future plans for BeiDou) equipped with payloads that relay the distress signals towards ground stations (MEOLUT). MEOSAR uses a different approach compared to LEOSAR. While LEOSAR relies on a multiple burst location method, exclusively based on accurate frequency measurements, MEOSAR relies on instantaneous spatial diversity (reception of the same burst by multiple satellites) and uses both time and frequency measurements (TOA: Time Of Arrival, FOA: Frequency Of Arrival) to compute a location. Then, compared to LEOSAR, the new location method used in MEOSAR allows:

• Localizing a beacon with a single burst

• Localizing a beacon that is fast moving

This transition will increase the quality of service of the Cospas-Sarsat service, with several key added values compared to LEOSAR and GEOSAR system:

• Worldwide real time detection 

• Instantaneous independent localization (localization without reliance on the possible GNSS receiver of the beacon, but based instead on the characteristics of reception of the beacon signal by the SAR system itself) with improved accuracy

• Opportunity to implement the Second Generation Beacon (SGB)

The MEOSAR system opens many new possibilities:

• The beacon may be activated and independently localized in-flight, even in single-burst and even when fast-moving and at high altitude.

• The beacon is continuously tracked after activation, during the complete descent phase, so that rescue teams may be continuously aware of the trajectory evolution. The last burst, just before crash, is also known and localized, which is crucial for the evaluation of its position.

In addition and in parallel of the MEOSAR evolution, the Galileo system introduces the Return Link Service which offers a new feature: the possibility to acknowledge to the user of a beacon the reception of the distress message transmitted and therefore inform them that the alert and its location are processed. This is called the Type-1 RLM. Although Type-1 RLM is the only use case that has been agreed yet by SAR authorities, the Return-Link capability opens several other possibilities to contribute to SAR operations improvement that will be analyzed within a EUROCAE Working Group 98 in 2018, such as:

• A dialog between the ground systems and the beacon, to adapt the transmission periods, the beacon message, and to create system monitoring solutions. A particular dialog case is the switch-off after cancellation, thanks to acknowledgement logic. This switch-off is very important to create autonomous cancellation capacity, as it avoids maintaining alerts if the situation has gone back to normal, and therefore reduces the used bandwidth and prevents from system overcapacity.

• The Return-Link may be used for remote activation. This is particularly useful if the aircraft disappears from other communication systems as the beacon is autonomous (works if everything else in the aircraft is off). Such remote activation could in particular have been used for MH370 flight disappearance.

Cospas-Sarsat operators have expressed their requirements in terms of SGB performance. These requirements are described in document Cospas-Sarsat G.008 “Operational Requirements for Cospas-Sarsat Second-Generation 406-MHz Beacons” that is accessible on the Cospas-Sarsat website. A detailed presentation of SGB specifications and performance can be found in Additional References, and the key improvements are recalled here:

• Better detection performance thanks to a stronger error correcting code

• Increased message content with flexible structure allowing the transmission of information through multiple burst

• Increased TOA measurement accuracy thanks to the use of a spread spectrum modulation, allowing more accurate locations

In particular, the improvement of TOA accuracy compared with FGB characteristics allows reaching the same location accuracy for static and moving beacons. In other words, while TOA and FOA measurements have to be used jointly to estimate the location of an FGB in order to get sufficient location accuracy, the use of TOA only is sufficient for SGB and typically improves the location accuracy by a factor of 10. Since TOA is not affected by the beacon speed, the SGB independent location, which mainly relies on a significantly improved TOA measurement, is also independent of the beacon speed, which is a great asset for independent location of ELT(DT). With accurate and reliable TOA-only position estimation, it becomes interesting to use FOA measurements for beacon instantaneous speed estimation.

The MEOSAR system is also improving the Cospas-Sarsat global performances thanks to the continuous increase of tracking capability on the ground stations (called MEOLUT), with the deployment of new stations in the world (12 commissioned as per today): the addition of dish-antennas to some of them, or deployment of phased-array antennas (see Figure 4). This last solution, deployed as the operational French MEOLUT since 2016, provides the capability to track in parallel all satellites in view instead of selecting some of them pointed by a few dish-antennas: as we are dealing in the end with all GNSS constellations, it will represent up to 30 satellites tracked in parallel.

The gains provided by a higher number of simultaneously tracked satellites are multiple:

• increased probability of detection of the beacon signal through at least one satellite

• higher chances to receive the beacon signal bursts through at least three satellites, enabling the computation of an independent location

• More TOA/FOA measurements, and then a better accuracy on the independent location.

The ground segment is then continuously improved to get real-time access to more satellites relaying alerts from larger areas, as part of the first and most important requirement of the MEOSAR system in Cospas-Sarsat. In the frame of ELT(DT), this objective of improving the performance is particularly important:

• The beacon may only transmit a few bursts before crash: the detection and location probability per burst shall be particularly high

• The beacon localization adds new unknowns: the altitude (usually considered on ground for other beacons, including current ELTs that are triggered by the crash) and/or the speed (in particular for FGB where it impacts the FOA and then the overall accuracy). Even if some default calculations can be implemented which provides quite satisfying results, the access to additional measurements through a fourth satellite is particularly interesting and significantly improves the independent location accuracy. The access to a fifth or sixth — or more — satellite allows to even refine the location performance accuracy.

c. The pre-operational MEOSAR-system used to localize an in-flight activated beacon: the MS804 accident

On May 19, 2016, the MS804 flying from Paris to Cairo crashed into the Mediterranean Sea with 66 people onboard. Unexpectedly, the distress beacon of the aircraft (a standard ELT) transmitted two test messages at 00:36:52 and 00:36:59. These two messages were received after radar contact was lost and a few minutes after the reception of the last ADS-B message, probably several seconds before the crash.

The two messages were received by several SAR satellites of the Cospas-Sarsat space segment:

• 2 GEO satellites: MSG-2 (tracked by the Greek and Turkish GEOLUTs) and MSG-3 (tracked by the French GEOLUT)

• 10 MEO satellites: GPS (PRN 1, 3, 9, 17 and 23), Galileo (PRN 8, 14, 20 and 26) and GLONASS K1-2, received by MEOLUTs in Cyprus, France, Norway, Russia, Spain, Turkey, and USA.

The first message was received with very low signal to noise ratio, therefore, only the second one could be used. The beacon model was not equipped with a GNSS receiver, thus no position was encoded in the alert message. Some MEOLUTs could compute an independent location based on TOA/FOA measurements using standard location algorithm (i.e. not taking into account the fast motion of the beacon) but these locations were highly inaccurate (more than 200 kilometers away from the crash site). An analysis conducted by CNES using location algorithms adapted to fast motion allowed to compute a better location, a few hours after the accident. This information was promptly transferred to search teams and was used to localize the wreck and quickly recover the flight recorders.

Although this accident did not involve the use of an ELT(DT), it demonstrates the ability of the MEOSAR system to provide reliable information to find the accident site in a timely manner.

GRICAS: Providing an Innovative Solution

From the beginning of the MEOSAR system, the European Union (EU) has been deeply involved in the deployment, promotion and enhancement of the system. On one hand, the EU contributes to the space segment of the MEOSAR system with SAR payloads onboard each and every satellite of the Galileo constellation and constituting the Galileo SAR service. On the other hand, EU, via its institutions like the European Commission (EC) or the European GNSS Agency (GSA), every year funds several research and development projects working on the development of the MEOSAR services and the design of new SAR services relying on the Galileo SAR: GRICAS, HELIOS, MAGNIFIC, SAT406M, GRIMASSE, SINSIN, iSSAR… Among those projects, the GRICAS project (Galileo SAR Return-Link Improvement for a better Civil Aviation Safety) is funded by the GSA under the European Union Horizon 2020 Research and Innovation program (grant agreement no. 687556). Initiated in February 2016, it was to be concluded in April 2018 and gathers a consortium of seven companies and administrations from France (CNES, Thales Alenia Space and ECA GROUP (with its brand ELTA), Italy (STMicroelectronics), Spain (PildoLabs, Aeroclub Barcelona Sabadell) and Africa (ASECNA the Agency for Aerial Navigation Safety in Africa and Madagascar). The main objective of the project is to demonstrate the compliance of the Cospas-Sarsat MEOSAR system to the requirements of the Autonomous Distress Tracking function of the GADSS developed by ICAO. In 2017, all the developed operational concepts have been demonstrated through a set of in-flight trials in Europe, testing in particular the first Cospas-Sarsat ELT(DT) (Emergency Locator Transmitter for Distress Tracking) developed for the project. The definition of the operational concept is based on the ED-237 MASPS published by EUROCAE Working Group 98 and the solution proposed is compliant with Cospas-Sarsat specification documents.

d. An operational concept that covers all distress situations taking into account consequences of the distress on the cockpit crew

GRICAS operational concept is based on three main distress scenarios:

• the automatic activation by avionics upon detection of one or several distress situations such as:

■ Criteria defined by EUROCAE as mandatory:

• unusual attitude

• unusual speed

• unusual altitude

• total loss of propulsion

■ Additional criteria identified as relevant by the GRICAS project:

• transponder codes (7500, 7600, 7700)

• fire

• depressurization

• the manual activation by crew

• the manual remote activation from ground through the Galileo Return-Link Service (not required by ICAO at this time).

Based on these scenarios, the solution design requires:

• a new type of Cospas-Sarsat aeronautical distress beacon called ELT(DT)

• an ELT continuously armed and tracking GNSS with its own internal GNSS receiver (GPS + Galileo):

■ The ELT is always ready to be triggered to transmit a distress message as well as the needed data to be localized, as soon as a distress situation is detected.

■ The bi-constellation function of the GNSS receiver also offers robustness to spoofing and jamming on GPS signal

■ beacon can receive an activation command sent via the Galileo Return-Link

• continuous power supply by the aircraft and a 24-hour autonomy at 406 megahertz thanks to the internal and rechargeable battery

• The shape, size and weight of this ELT(DT) are similar to the standard ELT’s  already commercialized.

Moreover, the designed solution offers a strong robustness to possible attempts in tempering the system with:

• robustness to GNSS spoofing: the beacon independent location is computed thanks to the beacon signal characteristics, independently from the message content or availability of GNSS onboard the aircraft, and specific spoofing detectors are implemented together with the beacon internal GNSS to ensure that such attempt triggers the SAR transmission. The beacon can then start transmitting in case of GNSS unavailability (jamming) or unreliability (spoofing), and will then be localized by Cospas-Sarsat MEOSAR independent localization, which will then become the only remaining solution to localize the beacon. To increase the gain of this capability, the beacon transmission implements the Second Generation Beacon waveform, which provides a more accurate in-flight independent localization 

• the acknowledgment from the ground under the responsibility of RCC to avoid fake cancellation of a manually triggered ELT, to avoid ill-intentioned cancellation.

In addition, human factors have become more and more important in recent years in the design of aeronautical systems, and the GRICAS project took these studies into account and implemented a manual acknowledgment from the cockpit crew to be requested in case of automatic activation by avionics, before the avionics send the cancellation command to the beacon. Thus, the pilots can confirm they are back in control of the flight in addition of the flight dynamics criteria characterizing a normal flight situation.

From the beacon point of view, the Cospas-Sarsat ELT(DT) designed for the GRICAS project to comply to the Autonomous Distress Tracking recommendations is identical to currently commercialized and operated ELT’s in terms of electronic components, mechanical and functional interfaces (with an additional interface for the automatic activation). However, this new ELT with Distress Tracking functionality benefits from a new design fitting with aeronautical ADT requirements:

• It implements the new modulation, called Second Generation, of the Cospas-Sarsat system specifically designed to maximize the performances of the MEOSAR system.

• It integrates an internal Galileo compatible GNSS receiver that is continuously turned on:

■ to provide a source of localization, independent from any other aircraft systems

■ to be able to receive any Galileo Return Link messages

■ to be able to identify spoofing or jamming attempts on the GNSS signal

• During normal flight conditions, the ELT(DT) is armed and monitors information

■ From a beacon activation logic that computes the automatic triggers based on detection of a distress situation

■ From the Galileo navigation signal to identify a RLM with its ID encoded and to process the RLM as appropriate (activation for example)

■ From the avionics: the position provided by the avionics GNSS receiver to encode it in the distress or cancellation message when the beacon is activated

• It starts transmitting within five seconds upon reception of triggering command (either manual, automatic or from a remote RLM activation command)

• It is powered by the aircraft main power bus and by an internal rechargeable battery. This double power supply source enables the ELT(DT) to continue to operate when there is a total loss of power onboard and for the whole remaining flight (up to 24 hours).

e. A fully independent solution for distress delivery in all situations

The operational concept and the solution design proposed by GRICAS ensures the ELT(DT) mission not be affected by a communication link inhibition with the avionics, a loss of communication with the aircraft’s GNSS receiver, or even a GNSS jamming or spoofing in the vicinity of the aircraft.

Finally, the ELT(DT) can be triggered in a completely independent process without any inhibition risk thanks to the manual remote activation from ground by Return-Link Message. This service could be provided to airlines, which will be able to request a remote activation (and deactivation) to the Return-Link Service Provider, knowing that the activation of the ELT(DT) will set off a distress at the RCC responsible for the area.

f. Flight trials

All the operational concepts developed within the GRICAS project have been demonstrated through a set of real-time in-flight trials:

• A first campaign, called “ELT(DT) field trial” performed in Sabadell, Spain, onboard a Cessna 182 in April 2017. It was meant to be an in-flight dry-run of the future flight trials and was dedicated to the adjustment of the test equipment. All the test scenarios were performed in-flight and the first in-flight independent localization using the MEOSAR system was realized, with results even better than expected.

• A second campaign, called “in-flight RLS field trial” performed in Sabadell, Spain, onboard a Cessna 182 in November 2017. Its objective was to test the Return-link Service (RLS) user cases defined in the GRICAS operational concept with the pre-operational RLS Provider (RLSP).

• A third campaign, called “Commercial aviation field trial” performed in Toulouse, France, onboard a Falcon 20 of SAFIRE (The French Service of Instrumented Aircraft for Environmental Research) early December 2017. Its objective was to test the GRICAS SGB ELT(DT) onboard an aircraft offering a flight domain similar to the one of an aircraft dedicated to commercial flights (as targeted in GADSS). The Falcon 20, with its 800 km/h cruise speed and 10 kilometer cruise altitude was a perfect test aircraft for this flight trial.

• A fourth flight trial, called the “Final Commercial Aviation field trial”, performed in February 2018 in Dakar, Senegal, onboard the ATR 42 test aircraft of ASECNA. It was a field trial mostly dedicated to dissemination activities around the Cospas-Sarsat compliance to ADT requirements and the improvement of SAR in Africa.

In addition, a helicopter field trial was performed in July 2017 in Graulhet, France, onboard an AS 350 B2 Eurocopter “Squirrel” helicopter. It aimed at initiating work on addressing the problem of ELT(DT) designed for rotorcraft.

For these campaigns, a dedicated platform was developed by PildoLabs in the frame of the project, following the standards and best practices used for laboratory equipment devices that are carried out in research aircrafts (see Figure 5). This demonstration platform contains as main equipment the Second Generation ELT(DT) developed by ELTA, a Remote Control Panel to monitor the beacon status and an EGNOS GNSS receiver to be used as the beacon’s position external reference. The platform was temporarily installed in the aircraft during the flight campaigns and connected to the SAR antenna, as it can be seen in Figures 6-8. The manufacturer also developed an emulator of the Beacon Activation Logic that sends the automatic activation command to the beacon when triggering criteria are met.

The flight tests performed during the project are unique in many aspects:

• It was the first time that an ELT(DT) prototype, representative of what a real ELT(DT) could be, flew onboard airplanes and a helicopter, and was automatically triggered in-flight.

• It was the first time an independent localization of a second generation Cospas-Sarsat beacon was computed during a transmission on-board a flying aircraft and helicopter.

• It was the first time that the Galileo SAR RLS was used to remotely activate an ELT(DT) aboard a flying aircraft.

• Finally, it was also the first time first and second generation beacons modulated distress messages transmitted onboard a flying aircraft were recorded (in the same test environment) to provide consistent data to compare the relative performances of both modulations for independent localization of fast-moving beacons.

Scenarios

The attention of the reader is drawn to scenario 2 (see Figure 9) which is completely automatic. Indeed, for this scenario the beacon was automatically triggered by a Beacon Activation Logic (BAL) based on GNSS information on the flight altitude of the test machine. For the sake of simplicity, the BAL used computed an automatic trigger based on an altitude threshold (instead of proximity with ground); the reader will anyway note the representativeness of the automatic activation process. After take-off, the test pilot pursues the ascent until overtaking a threshold altitude (agreed with the GRICAS engineers and encoded as the threshold altitude in the BAL). The BAL, collecting the position data provided by the GNSS receiver of the demonstrator (emulating the GNSS receiver of the avionics for the tests), identifies the unusual altitude, computes a trigger “Unusual altitude” and sends it to the ELT(DT) prototype. The ELT(DT) prototype receives the trigger and starts transmitting a distress signal with the relevant activation method encoded in the Rotating Field #1. The MEOLUT receives and processes the signal. It computes in real time a single and multi-burst independent location and delivers the alerts to the test ground engineer. Finally, after 5 to 20 minutes (depending on the test case), the pilot flies again under the threshold altitude, the BAL checks that the pilot is in control, then computes a cancellation trigger, the beacon starts transmitting a cancellation message. The cancellation messages were well received, processed and delivered to the test ground engineer by the MEOLUT.

Results

The independent localization accuracy of the ELT(DT) prototype based on Cospas-Sarsat second generation wave form is very good, with single-burst accuracy at 90% of 800 meters and at 95% of 850 meters. It is significantly better than the target performances for second generation beacon specified in Cospas-Sarsat documents: 5 kilometers @ 90% and 13 better than the performance obtained for an ELT based on first generation wave form.

In the case of the Final Commercial aircraft tests, the flights took place outside of the declared Coverage Area of the French MEOLUT (Toulouse, France) used for the tests (in Dakar, Senegal, 3,600 kilometers far from Toulouse, whereas the coverage area is a 3,000-kilometer-radius circle centered on Toulouse), i.e. outside the area where the performances of the MEOLUT are guaranteed. The performances obtained are very good considering the constraints on the tests.

The performance accuracy is a bit lower for the helicopter tests which can come from the interferences observed between the engine and the antenna used to transmit. Further tests will be performed in 2018 and 2019 onboard helicopters with adapted beacon and antenna solution.

The Beacon/MEOLUT Latency

During the field trial, the latency was inferior to 20 seconds between the activation of the beacon and the delivery of the demodulated, independently localized and interpreted signal to the operator on testing site emulating the MCC. This means that the Cospas-Sarsat MEOSAR based ADT solution can pretend to be a real-time flight distress tracking solution that would dramatically improve the efficiency of the SAR operators with a typical overall latency of one minute for the delivery of the distress message to the operators.

Conclusion

Today, it appears that the Cospas-Sarsat MEOSAR system, relying on payload deployed on GNSS constellations (GPS, Galileo, GLONASS), offers all the conditions to meet the new requirement of ICAO for  ADT system for Commercial Aviation, with a new generation of in-flight triggered beacons, identical to the current ELT in terms of aircraft integration, but capable of receiving triggers and cancellation events from the avionics, from the crew or from internal sensors, and of detecting and managing their inhibitions to maintain the capability to raise alerts and be localized in any situation. The redundancy of the localization information (GNSS position encoded in the message and independent MEOSAR localization), the gratuity of the service, the worldwide instantaneous coverage of the space segment and the worldwide coverage of the ground segments guarantee a high quality of service and performances that will contribute efficiently to improve air navigation safety.

Thanks to projects like GRICAS, SAR and aeronautical authorities have a common understanding on the fact that MEOSAR is a strong, reliable system to ensure commercial flight safety. The space segment is currently performing well and, while it is still under deployment, it has already demonstrated its capability to contribute to SAR operations for aeronautical events. The aircraft segment is migrating to benefit from this space segment and the existing SAR ground segment is providing strong results and migrating to the MEOSAR system. However, to fully embrace the MEOSAR evolution and as new operational needs appear, an improvement of the ground segment (MCC, RCC) is required and will allow the MEOSAR system and the Galileo SAR service to reach their maximal potentials. To this extent, EUROCAE will initiate mid-2018 activities to define a Minimum Aviation System Performance Specification for Aircraft Emergency Locator Transmitter Return Link Service including but not restricted to remote activation of ELT(DT), command to modify the content or transmission rate of the distress message and acknowledgment of reception of beacon messages.

In parallel to the on-going development of an ADT solution for commercial aviation, it is not foreseen to extend the ADT to general aviation. General aviation’s needs offer very specific challenges in terms of ADT:

• large variety of aircrafts requiring a better beacon autonomy and flexibility,

• many different user profiles and stakeholders requiring a common communication solution, 

• stronger cost constraints.

Future efforts will now be oriented towards such user sector, with new activities starting in the coming months (in particular with the GRIMASSE project) to make sure that the MEOSAR system ADT solution can answer to General Aviation needs and improve air navigation safety and security to help saving more lives.

Acknowledgment

The GRICAS project has received funding from the European GNSS Agency under the European Union’s Horizon 2020 research and innovation program under grant agreement No 687556.

Additional Resources:

1. cospas-sarsat.int, “Specification for Second-Generation Cospas-Sarsat 406-MHz Distress Beacons”, C/S T.018, which can be found on COSPAS-SARSAT website https://www.cospas-sarsat.int

Authors

Pauline Martin, technical manager of the H2020 GRICAS project, and Operational Concept Engineer in Data Collection in charge of navigation-based innovative services within the Navigation Domain of Thales Alenia Space. She is in charge of developing the new operational concepts for MEOSAR applications. She is also in charge of Thales Alenia Space attendance to COSPAS-SARSAT.

Thibaud Calmettes is technical manager for Data Collection and Scientific Application Programs Service within the Navigation Business segment of Thales Alenia Space France. After being the technical responsible for the on-board processing equipment during ARGOS 4 development, he is now in charge of various data collection systems, such as Satellite-AIS and VDES, and of developments around MEOSAR, including new generation beacons, signals, and MEOLUT processing. As manager for the scientific domain, he also works on the innovative use of GNSS receivers on-board satellites.

Yoan Gregoire is radionavigation and radiolocation engineer in the navigation/location signals and equipment department in CNES, the French Space Agency. His COSPAS-SARSAT activities cover second-generation beacons specifications development and performance evaluation. He is in charge of the development of a MEOSAR open reference chain developed by CNES and used for signal characterization and performance evaluation.

Mercedes Reche obtained her MSc in Telecommunication Engineering from the Universitat Politecnica de Catalunya in 2002. She started to work on Satellite Navigation in 2003 with the Centre Nationale d’Etudes Spatiales (CNES) in France. In October 2004 she joined PILDO LABS as aerospace engineer, giving technical support in activities related to GNSS Operational Validation (mainly EGNOS and GBAS) and acting as project manager of several international projects for Eurocontrol, the European Commission and the European GNSS Agency. Nowadays she is one of the managers of the company, in charge of the GNSS Monitoring department, and provides support to the business development activities.

Christophe Chatain  is in charge of developing and promoting MEOSAR ELT (DT) product line at ECA Group (ELTA Subsidiary). He received his Engineer diploma from Polytech Lille in 1986.  He is now involved in several research projects to define future features of COSPAS-SARSAT beacons for ECA Group.

Michel Monnerat, manager of the advanced projects within the Navigation Business segment of Thales Alenia Space France. After working on many radar programs within Alcatel Space, and being in charge of the onboard processing of the ARGOS/SARSAT payloads, he has been involved in the Galileo program since 1998, particularly for the signal design and performance aspects. He is now in charge of the advanced projects department dealing with the developments of Galileo and EGNOS ground stations, Satellite-Based data collect systems, GNSS regulation including standardisation and Spectrum management, as well as Engineering for innovative Location Solutions for land applications. The department is also in charge of Search and Rescue developments.

The post The Cospas-Sarsat MEOSAR System: A Solution to Support ICAO GADSS Autonomous Distress Tracking Recommendation 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Equation (2)

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

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

Equation (3)

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

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

Equation (4) 

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

Equation (5)

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

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

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

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

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

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

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

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

Equation (7) 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Table 1

Working Papers explore the technical and scientific themes that underpin GNSS programs and applications. This regular column is coordinated by Em. Univ.-Prof. Dr.-Ing. habil. Dr. h.c. Günter W. Hein.

This is the second article in a series. For Part 1: GNSS localization, see here.

Working Papers explore the technical and scientific themes that underpin GNSS programs and applications. This regular column is coordinated by Em. Univ.-Prof. Dr.-Ing. habil. Dr. h.c. Günter W. Hein.

This is the second article in a series. For Part 1: GNSS localization, see here.

GNSS solutions are widely spread and currently able to provide excellent navigation performance under a variety of scenarios, especially with the advent of assisted and cloud GNSS solutions. However, when used indoors and in deep urban canyons, they still suffer from many challenges such as outages of the system due to very low signal powers received indoors or very high positioning errors due to multipath. There are two main ways to circumvent such problems and they are addressed in the following two sections: using hybrid solutions between GNSS and a typically complementary solution, such as cellular, wireless local area network (WLAN), or inertial sensors, or using purely non-GNSS solutions, which might be desirable, for example, on low-cost mobile devices not supporting GNSS chipsets.

Hybrid-GNSS Localization
Hybrid positioning techniques merge GNSS and non-GNSS technologies to provide an accurate position of the user or device. The non-GNSS category typically includes all the terrestrial navigation systems, ranging from cellular to WLAN, and from Ultra Wide Band (UWB) to Inertial Navigation Systems (INS).

Non-GNSS positioning signals are typically referred to as Signals of Opportunity (SoO). SoO by definition means any signal which can be used for positioning, but which, unlike GNSS, was not initially designed with positioning purposes in mind (e.g., cellular, WLAN, UWB, etc.,). A debatable category is the category of 5G cellular signals, which currently are being designed in such a way to also support positioning, and thus they no longer belong to the SoO category. We will briefly discuss 5G positioning in the next section.

Another arguable category is the category of Internet of Things (IoT) and the related IoT positioning. The IoT concept is based on the connection of sensing devices to the internet, with the objective of using the information provided by the sensors (i.e., positioning information) in different applications, such as LBS or transportation and logistics. IoT positioning sensor networks can be divided into homogenous or heterogeneous. The heterogeneity definition deserves a discussion by itself, but in here we refer to this heterogeneity as follows. In a homogenous IoT architecture, the network is only formed by either GNSS or non-GNSS sensors. In a heterogeneous IoT architecture, the network is formed by both GNSS and non-GNSS sensors, whose information is then processed by a control unit applying hybrid positioning techniques. Hybrid (or heterogeneous) IoT positioning is discussed in this section. Homogeneous IoT positioning along with modern navigation solutions purely based on non-GNSS systems are discussed in the next section. The rest of this section focuses on localization techniques which rely on both GNSS and non-GNSS systems.

The fact that GNSS and non-GNSS are complementary technologies enables a ubiquitous localization in a wide range of working cases, which may not be feasible by just using one of these technologies. For instance, GNSS localization systems offer an excellent positioning reliability and accuracy if the working conditions are adequate enough (i.e., outdoors). Nevertheless, their performance in harsh environments (i.e., indoor, urban areas) may be compromised due to the attenuation of the signal power or even the loss of signal, the multipath propagation, the presence of interferences such as jamming and spoofing, etc. Conversely, non-GNSS technologies typically provide reliable positioning in indoor and urban scenarios. For example, cellular systems, from second generation (2G) to the emerging fifth generation (5G) are specifically designed for reliable and continuous communications in populated areas, such as indoors and urban, and their signals are able to penetrate buildings and walls, thus making them suitable alternatives for situations where GNSS fails. Similarly, WLAN networks are widely spread indoors nowadays, and their high density and moderate propagation ranges (e.g., a few tens of meters indoors to a few hundred meters outdoors) make them another excellent candidate for offering localization solutions complementary to GNSS. Therefore, the simultaneous use of such technologies by means of hybrid positioning techniques improves the accuracy, fault tolerance, and availability of the localization service both outdoors and indoors.

There are different combinations of hybrid GNSS and non-GNSS, and these can be classified into two main groups: GNSS+INS and GNSS+SoO. Currently, hybrid localization with GNSS and SoO, such as Long Term Evolution (LTE), 5G, UWB, and WLAN, is a hot topic in the localization field.

In the GNSS+INS integration, the short-term stable INS data complements long-term stable GNSS data. These systems can provide more accurate and precise location information than a single system, also yielding information during a possible outage of one system. In GNSS+INS hybrid localization, the inertial information provided by the Micro-Electro-Mechanical Systems (MEMS) provides location relative to a previous location at high rate. Other devices such as cameras, radar, barometers, and many more deliver absolute position information which can also be synchronized with the GNSS signal. Due to this hybridization, the accuracy and ubiquity of the location service is boosted in indoor and urban environments (due to the non-GNSS technologies) while still maintaining the outdoor scenarios (thanks to GNSS technologies). However, INS systems usually require an initial calibration, and they accumulate position error with time.

For GNSS+INS integration, three principle approaches exist: i) loose coupling (combines a GNSS derived position with INS data), ii) tight coupling (integrates GNSS pseudoranges and INS data), and iii) deep coupling (involves INS data in the GNSS signal tracking). Regarding the location privacy of an end user, pure GNSS+INS systems are commendable because only the user equipment aggregates and processes data of both subsystems; no third party is involved.

Similar integration concepts can also be found for the integration of GNSS with terrestrial communication systems. Hybridization of position level is always possible. Many examples for a tighter integration exist as well. For example, GNSS+LTE combines GNSS technologies and cellular-specific technologies, including Observed Time Difference of Arrival (OTDoA), Uplink-Time Difference of Arrival (U-TDoA), and Enhanced-Cell ID (E-CID) to provide a more robust and ubiquitous localization service. Secondly, GNSS+UWB mixes GNSS positioning technologies and UWB technologies, which usually perform Time of Arrival (TOA) techniques. Thirdly, GNSS+WLAN merges GNSS and WLAN technologies, which often employ Received Signal Strength (RSS)-based techniques, to enhance the performance of the localization service.

A sub-group of GNSS+SoO is a heterogeneous IoT system, where GNSS sensors and terrestrial IoT sensors are combined. GNSS technologies suited for IoT receivers are hindered by the requirements of low computational power and low power consumption, which might clash with the computational requirements of GNSS signal processing, thus resulting in a faulty localization service in severe working conditions. In this sense, vendors are developing ultra-low power GNSS modules aimed for IoT mass-market devices, with the objective of providing high accuracy with low-powered sensors.

Many studies have been carried out evaluating these hybrid systems, in particular in autonomous vehicle applications (see J. A. Peral-Rosado et alia in Additional Resources), where security and privacy are mandatory to avoid life-or-death scenarios occasioned by attackers. As hybrid systems use GNSS and non-GNSS technologies, they also suffer from the same security and privacy threats as pure GNSS and pure non-GNSS technologies, and thus the same solutions may be applied (see Location Privacy Challenges and Solutions – Part 1 published in Inside GNSS September/October 2017 as well as later sections of this article). However, as the number of systems in use increases, so does the probability of suffering an attack. In addition, the software required to carry out the hybrid positioning techniques must offer security and privacy, provided by the usual security software. If not, this software becomes a security breach in the hybrid system that can be exploited by attackers.

The threats to location privacy in GNSS+SoO are more obscure and possibly more abundant compared to the case of GNSS+INS because more parties and communication between those parties are involved. The parties involved in a hybrid GNSS positioning system are: the GNSS space segment, the user’s device and the network segment, including the Location Service Provider (LSP), the anonymizer, and the Location Based Service Provider (LBSP), as illustrated in Figure 1 (see inset photo, above right, for all figures). In practice, some of the units shown in Figure 1 can be merged or absent. The main GNSS data regarding the user localization comes from the satellites. Non-GNSS data for localization comes from the LSP. Nonetheless, as compared to a GNSS-based localization, there are several terrestrial entities involved in a non-GNSS localization, as seen in the “Terrestrial positioning system” block from Figure 1.

First, an LSP should offer an entirely software or a hybrid software-hardware solution to the user for his/her positioning. For example, a mobile application for indoor positioning can be downloaded from a certain server. Alternately, a dedicated positioning hardware solution can be installed in a shopping mall (based on WLAN, Bluetooth Low Energy BLE, LED, etc.) and users visiting that particular shopping mall can download the application that uses the dedicated infrastructure. The LBSP is the one offering the services to the user, such as finding an item on a shelf in a supermarket, or finding the cheapest offers for nearby restaurants, etc. The LSP and LBSP are typically distinct entities, and, in order to preserve the users’ privacy, they might interact through the help of a third entity, called an Anonymizer. This is done in order to not send the user’s position in clear from one server to another. The last entity in the chain is, of course, the user mobile device, on which the positioning application is running.

The position can be computed in two ways:

• network-centric approach, when the LSP computes the user’s position and sends it to the user, or
• mobile-centric approach (J. H. Lee), when the LSP only sends some of the information to the user (e.g., training databases, maps, etc.), and the user device computes its final position based on the signals in range and the information received from the network.

Clearly, the second approach more successfully preserves location-privacy than the first one.

As mentioned earlier, hybrid GNSS positioning systems combine several positioning systems, thus they also incorporate the vulnerabilities of these positioning systems. In a hybrid positioning system aggregation, pre- and post-processing of data can almost arbitrarily be divided between LSP and user device as long they are able to share (intermediate) results. These exchanges of information can potentially suffer breaches of location privacy. Analogous to loose and tight GNSS/INS coupling in other hybrid GNSS systems, either positions or other features derived from the signals are used to yield a more robust solution. These features are often ranges or RSS, but any feature unique to a certain location could be used.

The location privacy vulnerabilities of hybrid GNSS systems depend on the data used by the non-GNSS positioning system, i.e., ranges or RSS, and whether the data is fused on the device or on the network by the LSP. Data that is missing at the fusion center must be transmitted to it. Data fusion on the user device reduces communication and is typically the better choice from a privacy point of view.

Non-GNSS Localization
In recent years, we have witnessed the advent of the IoT. Terrestrial IoT can have positioning capabilities either based on the signal strength of powers measured at the receiver side or as intrinsic to a certain IoT standard, such as 5G positioning (A. Dammann et alia; M. Koivisto et alia) or LoRa positioning (B. Ray). WLAN is currently the most widespread non-GNSS localization technology in IoT and it is typically based on RSS measurements. Cellular technologies are also gaining prominence in the IoT positioning field. The legacy cellular systems (2G and 3G) do not explicitly support positioning signals in their standards, but they do have positioning capabilities based, for example, on cell– ID (i.e., positioning of the device inside the coverage areas of the heard transmitters), RSS, time of arrival (TOA), or time difference of arrival (TDOA). In 4G cellular systems or LTE, the Positioning Reference Signals (PRS) have been introduced to support TDOA-based positioning. The 5G emerging cellular concept is based on the assumption of very dense Access Nodes (AN), e.g., even down to 5-10 meters average distances between the AN, and very large bandwidths (e.g., trend to move towards mmWave communications, where the spectrum is still scarcely used or unused). These two features strongly support the capacity of achieving highly accurate positioning and tracking through, for example, combinations of TOA, TDOA, and Angle of Arrival (AOA) solutions. The privacy threats in 5G will likely be related more to the attacks during channel transmission rather than to unsecure or malicious ANs, as the security in 5G has been actively addressed, deeply thought out and optimized.

Another category of emerging communication systems with potential support for positioning is the terrestrial IoT category. For instance, Low Power Wide Area Network (LPWAN) standards such as LoRa, NarrowBand IoT (NB-IoT), enhanced Machine Type Communication (eMTC) or Sigfox, which were incipiently devoted to IoT communications, can also be used for IoT positioning. These technologies are also affected with the security threats of typical cellular and non-GNSS based localization systems.

The main threats of IoT positioning techniques relate to attacks performed on the IoT sensor itself instead of the localization service. In this context, the IoT sensor suffers from similar threats as most non-GNSS localization techniques, which are node-based localization solutions. Finally, in heterogeneous IoT sensor networks, as the hybrid positioning techniques are applied in a control unit and not in the device itself by means of software, the security breach produced by this software is circumvented. It is supposed that the control unit is already protected against attacks which may jeopardize the security and privacy of the sensor or user. More aspects related to hybrid and non-GNSS localization are discussed later.

Passive Positioning Concept
The current literature includes a dual definition of “passive positioning.” The two definitions, used with opposite meanings, are given below:

1. “Passive” from the user’s point of view: the user terminal is passive, meaning that it does not send any positioning information to the network; the terminal only receives signalling or other information relevant to its positioning, similar to a pure GNSS device. Thus, the network does not have any knowledge about the user’s position. The user is the only one responsible for calculating his/her position in a fully mobile-centric mode and the only one who will have that information (see L. Chen et alia and V. Sark et alia).

2. “Passive” in the sense of “uninvolved” or non-participative user, also referred to as “device-free” localization: the user has no idea it is tracked or positioned and the network locates and tracks the user without his/her express authorization, typically in a radar-like approach, by using signal reflections on the users’ devices or body or passive tags. The user terminal can also be seen as “passive” in the sense that the user does not take an active part in the localization process (see N. Pirzada et alia and Z. Zhang et alia).

In this article, we adopt the first definition, as it is the one strictly associated with a privacy-preserving positioning. We also make the distinction here between the LSP, which is typically the network operator or the provider of the actual positioning information, and the LBSP, which is the provider of a certain service that needs the location information. Many times, they are one and the same, but sometimes they can be disjoint, e.g., an LBSP in a shopping mall which advertises the best-value in that shopping mall can take the position information from a separate LSP entity, which might have installed a positioning-specific infrastructure in that particular mall.

Location Privacy in Hybrid- and Non-GNSS-Based Positioning
In contrast to GNSS, the majority of modern communication systems use bidirectional communication and rely on unique identification of their nodes. Thus, the network operator is, in general, able to obtain knowledge of its user’s whereabouts just based upon the proximity to the AN or the transmitter the user is connected to. It already becomes clear that revelation of location information is almost inevitable when using a communication system for positioning purposes. However, to what extent this becomes critical depends primarily on the accuracy of the location information and the context it might be linked to. The following two sections assess the location privacy vulnerabilities of range-free and range-based positioning systems, which translate to hybrid GNSS positioning systems as part of a loosely or tightly coupled, user-centric or network-centric system.

RSS-Based Techniques
Any communication system can also be used deliberately as a positioning system. WLANs are among the most prominent SoO, providing location information as accurate as a consumer-grade GNSS, but are much less protective of privacy. Fingerprinting relies on the concept that signatures of Radio Frequency (RF) signals – typically RSS signatures (i.e., RSSs and corresponding MAC addresses) – are unique at different locations, and that once enough of these signatures are known at sufficient locations, a user’s location can be recognized at a later stage solely by the signature associated with that location. The set of RSS signatures obtained at known locations is known as a radio map or fingerprint database.

The vulnerabilities in terms of privacy of a fingerprinting-based positioning system depend on the type of positioning system/infrastructure. Two typologies are prevalent: a) infrastructure based, or network-centric, and b) terminal based, or mobile-centric. In a network-centric positioning system, the user observes the signal signatures of the network’s ANs and sends them back through the network to the location provider, where the location is retrieved as the position that is associated with the pre-recorded signatures of the radio map that best match the observed signatures. In a mobile-centric system, a copy of the radio map is available on the user’s device and the position is estimated by the device.

Both, network- and mobile-centric positioning systems are prone to breaches of the user’s location privacy due to a communication link that identifies the user device. Let’s consider the scenario of an adversary controlling an untrusted network. The adversary might use the known AN positions to which a user device connects and infer its location roughly based on proximity. The location disclosure type of attack basically depends on the user’s need and perception of his/her location privacy (J. H. Lee et alia) and by the granularity level of the position information disclosure, as discussed in our previous article.

We extend that scenario and assume that the attacker evaluates packets sent by the user at several ANs in range and that the attacker predicts a radio map with a basic pathloss model and knowledge of the AN positions. Now the adversary can use fingerprinting based on the MAC addresses of the ANs that received packets from the user device (MAC addresses are easily obtained by an eavesdropper, as they are transmitted in the clear by most existing WLAN chipsets.). A rank-based fingerprinting (FP) algorithm can be used to match the MAC addresses of the ANs in the range of the user with that of the radio map. The adversary might as well use fingerprinting with RSS signatures to deduce the user’s position even more accurately. In addition to the previous case he would need to evaluate the RSS from the user’s packets at the different AN positions. The symmetry of the channel (ANs’ RSS signature at the user position equates to the user’s RSSs at the ANs’ location) allows one to estimate the user location by matching the observed RSS to a radio map. A test performed in a four-floor university building in Tampere, Finland showed that the accuracy that can be obtained by an eavesdropper for RSS based FP in WLANs is about 8 meters and typically below 10 meters in more than 70-80% of cases, as illustrated in Figure 2.

Figure 2 shows the positioning accuracy (in terms of cumulative distribution of the distance error) that can be obtained by an adversary for the previously mentioned four-floor building. Three different cases are included: i) the adversary has access to the training database (radio map) and to both MAC addresses and RSS measured by the untrusted network from the attacked device (FP method, average accuracy about 8 meters), ii) the adversary has access to the training database and MAC address knowledge (rank based FP method, average accuracy about 17 meters), and iii) no training phase is needed (the radio map is predicted based on a simplified path loss (PL) model) and the adversary uses only MAC address knowledge (PL, rank based FP method, average accuracy about 27 meters). For networks with a low density of untrusted ANs, i.e., a few ANs placed in the building by an adversary, even the last approach would still offer building-level accuracy. If the adversary additionally has an actual radio map (i.e., training database), the average accuracy can decrease to about 17 meters or even 8 meters, depending on the positioning information used (MAC only or MAC+RSS).

In the network-centric setting, the same vulnerabilities exist. Additional risks arise due to the involvement of an LSP, storing and processing the user’s data with his consent, and the transmission of information that is part of the positioning process, for example, the RSS signature measured by the user, or the estimated position that is forwarded by the LSP to the LBSP. Methods to prevent this are addressed later in this article.

While some location-related vulnerabilities can only be exploited if the attacker has access to the network or information about it, others require information about the positioning system. In the worst case, the adversary is an untrusted network operator or LSP who intentionally computes and/or leaks the location data, or who provides unintentional access to information that allows a third party to compute and/or leak the sensitive information.

Assuming a trustworthy LSP/network operator, a mobile-centric positioning system preserves the location privacy better than a network-centric one because of the reduced communication or signaling between the user and the network. The location privacy in a mobile-centric WLAN positioning system can be further protected if the user does not need to associate with an AN and all necessary data for positioning. For example, a fingerprint database or access node position are broadcast while the user device just listens using 802.11’s “monitor mode” (F. Gschwandtner et alia). However, this scenario is limited to special use cases because this mode hinders communications for the user and is usually not enabled by the user.

Further arguments against the mobile-centric approach exist. First, the radio map is a valuable key component for the location service provider, which is therefore reluctant to make it available without obtaining the user’s location information in exchange. Secondly, maintaining multiple copies of the database implies additional costs. Thirdly, the mobile devices might lack sufficient memory and processing power. Thus, network-centric fingerprinting systems are the common case and one question becomes apparent: is the location service provider trustworthy?

If the LSP/network operator cannot be trusted, then an end-to-end encryption is required to preserve location privacy. For a network-centric positioning system, in which the user’s location is estimated by the LSP, end-to-end encryption can be achieved if the required computations are executed on the encrypted data. Homomorphic encryption allows computations on the encrypted data that, once decrypted, equal the result of the same computations performed on the plain data. For example, the Pallier cryptosystem, which provides only additive homomorphism and therefore reduces computational complexity, has been applied to WLAN fingerprinting (H. Li et alia). As the homomorphic property is reduced to additions, more complex operations can be decomposed and precomputed such that the LSP can perform signature matching based on additions only. However, transmitting several precomputed terms increases the communication overheads. Alternative secure two-party computation protocols, such as Additive Sharing, Yao’s Garbled Circuits, might further reduce the computational burden. Their use for RSS-based fingerprinting is currently under investigation.

One might conclude that, in order to achieve reasonable location privacy on the device, an end-to-end encryption is indispensable during communications and at the LSP side. The use of (partially) homomorphic encryption points to a promising direction, however, many practical issues have still to be solved. Given the diversity of pattern matching algorithms used in fingerprinting, the privacy protection scheme must be included in the design of the positioning system.

Timing and Angle-Based Techniques
Typically, timing and angle-based positioning methods require that the user device is communicating with the network. Examples of timing and angle-based positioning solutions widely used in cellular systems are, for example: TOA, TDOA, Round Trip Times (RTT), Time Of Flights (TOF), Angle or Direction of Arrival (AOA/DOA), Differential Direction of Arrival (DDOA), etc. Due to these communications over wireless channels, an untrusted network could get access to the user location information, but due to synchronization, authentication, and signaling requirements in various cellular and non-cellular communication networks, it is much harder for an attacker to build such an untrusted network, compared with the case when only RSS information is used.

An alternative to the situation when the user communicates with the network in order to get his/her position information via timing or angle approaches is the situation when the network broadcasts some signaling messages for all users in range, and such broadcast messages include the location of the network ANs, the starting time of the signaling message, and possibly some additional information, such as the forwarding time between two ANs. This approach has been proposed for the future 802.11az WLAN standard (see Additional Resources) and it is worth mentioning because it can offer a fully privacy-preserving approach, as the user is not sending back any information to the network. The concept is illustrated in Figure 3.

The ANs in a certain area or building are assumed to be synchronized and to belong to a certain LSP. One of the ANs in the network acts as an initiator and starts sending broadcast and forwarding messages in its range. Each AN that receives a forwarding message, re-sends it further with a certain delay (known to the network and broadcast in the broadcasting message). The mobile user receives such broadcast messages from all the ANs in range, and it is able to compute its position via hyperbolic trilateration (V. Sark et alia), as the ANs’ positions are known (transmitted in the broadcast messages). Such a positioning mechanism has recently been studied by E. S. Santiago. It has been found that at least 10 ANs must be in range of the user mobile in order to achieve good location accuracy. A basic open-source simulator for 802.11az-based positioning studies is also available from E. S. Lohan (see Additional Resources).

Methods to Protect Location Privacy
As the discussions so far show, there is an emerging need for protecting user location privacy and various methods and measures have already been studied or adopted. In our previous article, we described several possible methods currently used or proposed to protect location privacy, such as location cloaking, location obfuscation, position sharing, k-anonymity approaches, and mix zones. Table 1 (see inset photo, above right) presents a summary of privacy-preserving or privacy-protecting methods for user wireless localization.

The listed methods have been developed in light of certain attack scenarios and are vulnerable to attacks in which the adversary has further knowledge than originally assumed in the scenario. Here we mention only the base algorithms, to which many extensions exist. In general, the more information and context an adversary can link to the location data, the less effective these privacy-preserving methods will be. According to the protection goal, these context components are typically user location, temporal information, and user identity. Some privacy-preserving methods may need to be combined in order to achieve full user protection.

Conclusions
In comparison to modern GNSS solutions, such as Cloud and Assisted GNSS, where privacy of localization studies have only recently emerged, the location privacy in hybrid- and non-GNSS localization systems is a multi-faceted issue where many solutions have already been studied and published in the research community. These interdisciplinary efforts need to be further consolidated to design privacy-preserving IoT localization technologies and services. There is a clear inherent tradeoff between the granularity of defining the location accuracy by a certain Location Service Provider and the level of location privacy that the user can reach. Herein we have summarized some of the existing solutions for preserving the user’s location privacy. We have also pointed out that the research on location privacy is a worthy endeavor for future positioning systems targeting sub-meter level accuracies.

Acknowledgements

The authors express their warm thanks to the Academy of Finland (Project 303576) for its financial support for this research work.

Additional Resources
[1] Chen L., S. Thombre, K. Jarvinen, E.S. Lohan, A.K. Alen-Savikko, H. Leppäkoski, M.Z.H., Bhuiyan, S. Bu-Pasha, G.N. Ferrara, and H. Honkala, “Robustness, Security and Privacy in Location-Based Services for Future IoT: A Survey,” IEEE Access, 2017
[2] Dammann, A., R. Raulefs, and S. Zhang, S.,“On Prospects of Positioning in 5G,” 2015 IEEE International Conference on Communication Workshop (ICCW), London, pp. 1207-1213, 2015
[3] Gschwandtner, F. and C.K. Schindhelm, “Spontaneous Privacy-Friendly Indoor Positioning using Enhanced WLAN Beacons,” International Conference on Indoor Positioning and Indoor Navigation (IPIN), 2011
[4] Lee, J.H. and R.M. Buehrer, “Security Issues for Position Location,” chapter in Wiley Handbook for Position Location, 2011
[5] Koivisto, M., Costa, M., Werner, J., Heiska, K., Talvitie, J., Leppänen, K., Koivunen, V., and Valkama, M., “Joint Device Positioning and Clock Synchronization in 5G Ultra-Dense Networks,” IEEE Transactions on Wireless Communications, Volume: 16, Issue: 5, pp. 2866-2881, May 2017
[6] Li, H., L. Sun, H. Zhu, X. Lu, and X. Cheng, “Achieving Privacy Preservation in WiFi Fingerprint-Based Localization,” IEEE Conference INFOCOM, 2014
[7] Lohan, E. S., P. Richter, V. Lucas-Sabola, J. Lopez-Salcedo, G. Seco-Granados, H. Leppakoski, and E. Serna Santiago, “Location Privacy Challenges and Solutions – Part 1: GNSS Localization,” Inside GNSS, September/October 2017
[8] Lohan, E.S. et alia, “Open-Source Software and Measurement Data Available at TLTPOS Group, TUT,” accessed June 20, 2017
[9] Peral-Rosado, J.A., R. Estatuet, J.A. Lopez-Salcedo, G. Seco-Granados, G. Chaloupka, L. Ries, and J.A. Garcia Molina, “Evaluation of Hybrid Positioning Scenarios for Autonomous Vehicle Applications,” Proceedings of ION GNSS+, September 2017
[10] Pirzada, N.M.Y., F.S.M.F. Hassan, and M.A. Khan, “Device-Free Localization Technique for Indoor Detection and Tracking of Human Body: A Survey,” Procedia-Social and Behavioral Sciences, Volume: 129, pp. 422–429, 2014
[11] Ray, B., LoRa Localization, Blog entry, June 2016
[12] Sark, V., E. Grass, and J.G. Teran, “Efficient Positioning Method Applicable in Dense Multi User Scenarios,” IEEE 802.11 White Paper, 2016
[13] Serna Santiago, E., Passive Positioning Approaches in the future positioning systems, MSc. Thesis, Tampere University of Technology, May 2017
[14] Zhang, Z., Z. Tian, M. Zhou, Z. Li, Z. Wu, and Y. Jin, “WIPP: Wi-Fi Compass for Indoor Passive Positioning with Decimeter Accuracy,” MDPI Applied Sciences, Volume: 6, p. 108, 2016

The post Location Privacy Challenges and Solutions, Part 2 appeared first on Inside GNSS - Global Navigation Satellite Systems Engineering, Policy, and Design.

Q: Do modern multi-frequency civil receivers eliminate the ionospheric effect?

Q: Do modern multi-frequency civil receivers eliminate the ionospheric effect?

A: It is common knowledge in the GNSS community that the ionosphere is dispersive in the L-band, meaning the refractive effects on the carrier phases are proportional to the wavelengths of the carriers, in turn causing differential variation in the measured codes and phases of the various navigation signals transmitted by the satellites. Use of multiple signals of distinct center frequency transmitted from the same GNSS satellite allows direct observation and removal of the great majority of the ionospheric delay, and gives the impression to users that the ionosphere may not be a problem for modernized receivers. While the general assumption of nearly perfect correlation between the effects measured on multiple independent signals is correct in normal conditions, it does not appear to hold in the presence of ionospheric scintillation.

High and Low Latitude Scintillation Effects
Scintillation refers to random fluctuations in the received wave field strength (“signal fading”), as well as phase and group delay caused by the irregular structure of the propagation medium. Ionospheric scintillations are random rapid variations in the intensity and phase of the received signals resulting from plasma density irregularities in the ionosphere.

Many of the important contributors to ionospheric scintillation are already known, such as the variation of scintillation activity with magnetic activity, geographic location, local time, season, and the 11-year solar cycle.

The most significant and frequent scintillation activity including both phase and amplitude variations is observed in low latitude regions within about 15° of the Earth’s magnetic equator, particularly in the hours after local sunset. In high latitude regions scintillation is frequent but generally less severe in terms of signal tracking disruptions than that in the equatorial regions. The high-latitude environment can be divided into two subregions, the polar caps (regions around the magnetic poles) and the auroral zones (approximately circular regions around the two geomagnetic poles located at about 67° north and south geographic latitudes, and about 3° to 6° wide). Of these, the polar cap experiences both amplitude as well as phase scintillation activity, while mainly phase scintillation is observed at high latitude auroral regions.

In mid-latitude regions scintillation is rarely observed, but during intense ionospheric storm conditions phenomena can extend into the mid-latitudes.

Figures 1 and 2 (see inset photo, above right, for all figures) show examples of ionospheric scintillation as observed on the detrended signal intensity (effectively power) and detrended carrier phase measurements at 69.5° latitude (Tromsø, Norway) and 21° latitude (Hanoi, Vietnam), respectively. In the particular event shown in Figure 2 the depth of fades reaches 43 decibels (dB) on L1CA which is severe by any metric, and is a substantial qualitative difference from the high-latitude phase scintillation events where only very weak fading activity is typically observed. It should be noted that ionospheric activity is more dependent on the geomagnetic latitude of the user than the geographic latitude. While it might be clear that Tromsø station is located in the auroral region, the Hanoi station has somewhat lower geomagnetic latitude than geographic latitude and is in fact located within the equatorial zone.

Since ionospheric scintillation is essentially a rapid variation in the apparent ionosphere it is easy to assume that the typical approaches applied for removing ionospheric influence will be effective during scintillation.

Ionosphere-Free Combination
The advantage of multi-frequency GNSS receivers in terms of handling the ionospheric error is that they can combine carrier phase measurements at different frequencies to cancel out the first order effect due to ionospheric refraction. The receiver does not typically measure the ionospheric delay directly, but is using the so-called ionosphere-free linear combination of the observables. Consider generalized versions of carrier phase measurements on two frequencies, i and j, expressed in meters:

Φ_Li = ρ + λ_iN_i − I_i     (1)
Φ_Lj = ρ + λ_jN_j − I_j

where ρ is the geometric range between the satellite and the receiver; λ_i and λ_j are the wavelengths, N_i and N_j are the integer ambiguity terms, I_i and I_j are the ionospheric propagation delay errors. For simplicity, the receiver noise and multipath errors are not included. The expression for an arbitrary linear combination of two carrier phase measurements can be written as follows: (For more on this topic, read the GNSS Solutions column from January/February 2009).

Φ_ij = αΦ_Li + βΦ_Lj     (2)

where α and β are constants. This allows one to model a linear combination of phases in the same way as the individual observables:

Φ_ij = ρ + λ_ijN_ij − I_ijη     (3)

In (3), λ_ij is the wavelength, N_ij is the integer ambiguity term, and I_ij is the ionospheric propagation delay error for the linear combination. In order to remove the ionospheric error (η = 0), but leave the geometric portion unchanged and the resulting ambiguity still an integer, the ionosphere-free combination has been proposed:

Φ_IFree = f_i²Φ_Li − f_j²Φ_Lj  ∕ f_i² − f_j²     (4)

where f_i and f_j are the carrier frequencies expressed in hertz. The phase scintillation is, however, caused by both refractive and diffractive effects. The diffractive effects cause rapid transitions in the phase which do not scale with the carrier wavelength resulting in a residual error in the ionosphere-free linear combination (4) of phase measurements.

While this correction term is for most purposes considered complete, there are factors that can cause apparent deviation between the two carriers including multipath, receiver noise, and un-modelled terms in (4). Corrections produced using (4) will have a residual error due to second and third order dispersion effects, which are conservatively bounded to 0–2 centimeters and 0–2 millimeters at zenith respectively, under an assumption of a 100 TECU (total electron content unit; 1 TECU ≈ 16 cm at GPS L1) background ionosphere. Since 100 TECU is a high value for zenith ionosphere the value of the higher order terms will often be well below 2 centimeters instantaneously, and will vary by only a small fraction of this amount over short time periods.

Although some recent findings have shown that magnitudes of 3 centimeters referenced to L1 are possible due to the higher order terms, it has also been shown that the variation rate is typically limited to the level of centimeters per hour.

During phase scintillation events it is possible that the multiple carriers of a given satellite will (when scaled for frequency as in Figure 3) track each other within the margins of error expected when accounting for thermal and oscillator phase noise on each channel. However, it is also possible that near total de-correlation of the phases will occur during phase scintillation accompanied by fading events as is depicted in Figure 4 where the detrended scaled carrier phase observables from L1, L2 and L5 transmitted by a block IIF GPS satellite visibly deviate from one another. Even the closely-spaced L2 and L5 carriers exhibit substantial decorrelation, equivalent at times to a full L1 carrier cycle of nearly 20 centimeters, well outside of the level which could be plausibly attributed to higher order terms ignored by (4).

On close inspection, the data shown in Figure 4 does not appear to contain any stepwise transitions of a magnitude commensurate with a full or half cycle slip on any of the carriers, meaning that this decorrelation is unlikely to be a signal tracking error. Unlike static group delay errors, it is not possible to measure and estimate this error contribution a priori. It is effectively an additional noise source present only during scintillation. Since it will influence the magnitude of the residual error in the case of multi/dual frequency processing it is interesting to analyze this phenomena and attempt to quantify its expected magnitude by considering the level of correlation between carriers during a cross section of scintillation events affecting modernized civil signals believed to be free of cycle slips.

To quantify the correlation level between the scintillation effects on GNSS frequencies, the phase correlation coefficient can be calculated for the observed scintillation events according to the following relationship:

ρ_δφ = ⟨δφ₁δφ₂⟩/(⟨δφ₁²δφ₂²⟩)^1/2, −1 < ρ_δφ < 1     (5)

where the terms δφ₁ and δφ₂ represent epoch to epoch changes in the detrended phases. Figures 5 and 6 show the results for the events observed at 69.5° latitude (Tromsø, Norway) and 21° latitude (Hanoi, Vietnam). In Figure 6 the level of correlation versus the intensity of the phase variation is plotted for L1CA vs. L2CM, and in contrast to the high latitude example shown in Figure 5, where increasing phase instability leads to an increasing level of phase correlation between the two carriers, for the Hanoi data the outcome is entirely different. Indeed, the phase correlation between the two carriers appears to be nearly non-existent on average, as the distribution of correlation measures is bifurcated with half the distribution tending towards higher positive correlation levels, while the other half of the sampled distribution tends towards anti-correlated results.

Ionosphere-free Residual
When scaled by their wavelengths, the carrier phase measurements on different GNSS frequencies appear to match closely when the scintillation effect is weak or moderate, but diverge from one another when the scintillation effect is strong regardless of whether the dominant scintillation effect is on the phase or amplitude of the signal. It is believed that these divergences occur when diffraction alters the phases by a factor that is not proportional to the wavelengths of their carriers leading to a residual in the ionosphere-free phase combination. An example of this phenomena is the so-called “canonical fade”, which may be the cause of the decorrelation events presented here. Figure 7 shows the average absolute L1/L2 ionosphere-free combination residual from Tromsø (69.5° N) observations, whereas results generated based on the data from Hanoi (21° N) are illustrated in Figures 8, 9 and 10.

Noting that the range of carrier phase standard deviation considered in Figures 8, 9 and 10 is smaller than that considered in the high latitude plot, it is clear that the level of ionosphere-free residual present in the Hanoi data increases much more rapidly with rising phase standard deviation than was the case with the high latitude observations.

While it is not unexpected that the L1/L5 combination residual is also substantial, as indicated in Figure 9, the more interesting observation is that the L2C and L5 signals also have considerable levels of decorrelation despite their relatively small 51 megahertz of spectral separation, compared to the nearly 350 megahertz of spectral separation between L1 and L2. In Figure 10, it is seen that for one of the tracked satellites during this event, the level of ionosphere-free residual in the L2CM/L5Q combination seems to exceed one meter even while the underlying data shows no signs of cycle slips.

Conclusion
To summarize, it has been demonstrated that ionospheric scintillation phenomena tend to cause an additional measurement residual in the nominal ionosphere-free combinations that greatly exceeds the expected value of the neglected higher order terms and may be a substantial or dominant nuisance term in some applications. While the residual is present with both phase and amplitude scintillation, and is more pronounced with strong scintillation to a point, the relationship appears stochastic and not deterministic.

It is tempting to assume that concerns about ionospheric effects during all but deep amplitude fades would disappear when users had switched from semi-codeless multi-frequency observables to the use of modernized civil signals due to their much higher tracking robustness. Instead, it seems that even with the modernized signals there is a measurable and occasionally meter level sense in which the ionosphere-free observables are not at all free of ionospheric influence.

Additional Resources

For additional information about ionospheric scintillation:
[1] Conker, R.S., M.B. El-Arini, C.J. Hegarty and T. Hsiao (2003) “Modelling the effects of ionospheric scintillation on GPS/Satellite-Based Augmentation System Availability”, Radio Science, vol.38, no.1.
[2] Carrano, C. S., K. M. Groves, W. J. McNeil, and P. H. Doherty (2013), Direct measurement of the residual in the ionosphere-free linear combination during scintillation, Proceedings of the 2013 Institute of Navigation ION NTM meeting, San Diego, CA, January 28-30, 2013.

For additional information on higher-order ionospheric effects:
[3] Hoque, M.M., and N. Jankowski (2007), “Higher order ionospheric effects in precise GNSS positioning,” Journal of Geodesy number 81, pp 259-268
[4] Liu, Z., Y. Li, J. Guo, and F. Li (2016) “Influence of higher-order ionospheric delay correction on GPS precise orbit determination and precise positioning,” Geodesy and Geodynamics, Volume 7, Issue 5, September 2016, pp 369-376

For information about canonical fades:
[5] Liu, Z., Y. Li, J. Guo, and F. Li (2016) “Influence of higher-order ionospheric delay correction on GPS precise orbit determination and precise positioning,” Geodesy and Geodynamics, Volume 7, Issue 5, September 2016, pp 369-376.

The post Do modern multi-frequency civil receivers eliminate the ionospheric effect? appeared first on Inside GNSS - Global Navigation Satellite Systems Engineering, Policy, and Design.

Table 1

Working Papers explore the technical and scientific themes that underpin GNSS programs and applications. This regular column is coordinated by Em. Univ.-Prof. Dr.-Ing. habil. Dr. h.c. Guenter W. Hein.

This is the first article in a series. For Part 2: Hybrid- and Non-GNSS Localization, see here.

Working Papers explore the technical and scientific themes that underpin GNSS programs and applications. This regular column is coordinated by Em. Univ.-Prof. Dr.-Ing. habil. Dr. h.c. Guenter W. Hein.

This is the first article in a series. For Part 2: Hybrid- and Non-GNSS Localization, see here.

Positioning (or localization) is a key component in many wireless devices and a key enabler and optimizer of many mobile applications, including transportation, smart cities, and ambient assisted living. For example, mobile wireless devices relying on a location component can be used as mobile assistants and wearable devices for the elderly, sick, or disabled, for traffic and environment monitoring, for green mobile crowd sensing, in crisis scenarios, for wildfire risk prediction, etc. (see I. Maglogiannis et alia and L. Skorin-Kapov et alia in Additional Resources). When the time dimension is added to the positioning information, we talk about user or device tracking.

To enable a large-scale uptake of the location-based and location-aware applications, one of the main barriers to overcome is finding solutions to the current vulnerabilities in wireless positioning. Such vulnerabilities exist with respect to the privacy, security, positioning reliability, robustness, and availability, especially in indoor environments, and to the acceptability and safety of tracking devices. Users are indeed, slowly, becoming aware of the potential vulnerabilities in making their minute-by-minute position known to the external world and legislation efforts all over the world are dedicated to build the legal frameworks covering tracking and location privacy (see L. Chen et alia and K. Pomfret). Operators and mobile manufacturers are collecting location-based data and possibly geo-tagged context information en masse from our mobile devices for the purpose of network and service optimization. Crowdsourcing, mobility sensing, and cloud storage processing are becoming default options. Many mobile devices can now be used as identifiers, and digital wallets and biometric data play a crucial role. Location is a key component in all of these aspects. A known location, or being able to fake a current location, could mean, in the near future, higher vulnerability to theft, privacy invasion, and increased stalking. Geo-located patterns can lead to the re-identification of individuals and thus could pose a risk to the right to a private life. All these vulnerabilities with respect to the acquisition, storage, and misuse of the users’ geospatial information are long-overlooked factors which need to be addressed in a systematic and dedicated manner. The promising potential of future prosperous wireless markets relying on some form of localization and geo-spatial information, such as Internet of Things (IoT), Industrial IoT (IIoT), 5G, Device-to-Device (D2D), or Vehicle-to-Anything (V2X) communications, means that the security, privacy, and transparency aspects in mobile positioning need to become a high priority in the world of mobile computing.

In traditional positioning approaches, such as those purely based on Global Navigation Satellite Systems (GNSS), the user device is a purely passive device, thus fully preserving the user’s privacy. Modern localization solutions, including those evolved from GNSS such as Cloud GNSS (C-GNSS) and Assisted GNSS (A-GNSS) involve smart processing of cloud-gathered data, inter-connectivity, and exchange of information between different stakeholders in the localization chain, and possibly geo-tagged content de-identification. Therefore, these are vulnerable to privacy breaches, whereas the user position is fully private in GNSS as its receiver acts only as a passive (receiving) device. This article sheds light on the challenges related to location privacy, emphasizing current user perception of location-based mobile applications, and discusses future research directions and solutions that can benefit the community at large.

Is Location Privacy Something We Should Worry About?
In order to better understand users’ concerns with regard to their location privacy and how much users would be willing to pay for preserving their location privacy, a Webropol web survey (see Additional Resources) was conducted from January to May 2017. The survey was initially built in English and then translated to Finnish and Romanian. The survey link was distributed on different social media channels (e.g., LinkedIn, Twitter, Facebook) and through various mailing lists in order to reach a wide audience with variable backgrounds. In total, 327 answers from respondents across 38 countries in four continents were obtained. 8.8% of the respondents did not answer the question about the country of residence. There were 208 answers in English, 79 in Finnish, and 40 in Romanian. The overall gender distribution is quite balanced: 46.3% male respondents, 49.4% female respondents, and 4.3% declined to state. The age and country distribution of respondents are shown in Figure 1, with Finland, Romania, and UK being the countries of residence for most of the respondents, and the majority of respondents being between 36 and 45 years old.

Figure 2 shows how the respondents are using their mobile phone’s navigation capabilities and Location Based Services (LBS) on their mobile devices. The left plot shows that the vast majority of users (86.6%) are using some form of navigation on their phone, among which 52% typically activate both the GNSS and the non-GNSS (e.g., WiFi and cellular) positioning engines on their phones when navigating. The center plot of Figure 2 describes how often a user reads the permissions before installing an LBS application on his/her phones. These permissions are more or less intrusive in terms of privacy, depending on the application provider and reading them already denotes some minimal concern with regard to the privacy of mobile data. The survey shows that 30.0% of the respondents always read the permissions, 35.49% only occasionally read the permissions, and 28.4% never read the permissions. A small amount of respondents (6.2%) did not know about these permissions.

The right plot of Figure 2 shows how many of the respondents allow the LBS provider to collect their location data. The vast majority of respondents (61.9%) allow their location information to be collected only if they cannot use a particular service otherwise, as is the case with many LBS providers, such as Google maps and HERE maps. 5.2% of respondents always allow the location application to collect the user location data and 9.6% of respondents allow the location application to collect such data from time to time, independently of whether or not the LBS application could have been used in “private” mode (i.e., no data collection). 23% of respondents answered that they had never allowed an application to collect their location data. However, one could also infer that it might be unclear for some users whether or not a certain LBS application collects location data and sends it to the cloud. This comes as a conclusion when comparing the left plot of Figure 2, where only 13.6% of the respondents wrote that they do not use any location engine on their phone, with the right plot of Figure 2, where 23% of respondents say that they never allow an application to collect their location data. Nevertheless, one has to keep in mind that the vast majority of current LBS mobile applications cannot run unless the user allows the application to collect his/her location data.

Figure 3 compares the level of concern of users with respect to their location privacy with other types of personal digital data, such as emails, documents, calls, phone contacts, or images/videos. If we look at the “Very high concern” bars, clearly the users are much more concerned with protecting the privacy of all other types of personal digital data than protecting the location privacy. However, “High” and “Moderate” concerns bars are rather similar for different types of data, which shows that users have significant concerns regarding the privacy of all their personal data, location data included. As for the “No concern” bars, privacy of pictures and videos are least worrisome to those in the survey, with 12.6% having no concern for the privacy of these items. For location privacy, 7.3% had no concern, 14.4% had little concern, 19% moderate concern, 24.5% high concern, and 29.4% very high concern.

How these concerns translate also in a willingness to pay extra for location privacy can be seen in Figure 4. Clearly, the vast majority of users (61.9%) are not yet ready to pay anything extra for a privacy-preserving location engine. It is interesting to see that, among those who are interested in paying something (23.2% of the total respondents), the majority (60.9% of the respondents willing to pay something) would opt to pay up to 15% more compared to their current monthly mobile fee, and no respondent opted to pay more than 20% of the current monthly fee.

The survey findings show that there is already a reasonable awareness about location privacy challenges and that such awareness could be capitalized upon to some extent in business, by offering users more privacy-aware location solutions. The next sections will focus first on some aspects regarding granularity of location estimation, and then on GNSS location technologies categories, and will point out if and how such technologies can better support location privacy.

Granularity of Location Estimates for Various LBS
When talking about location privacy, one refers to the capacity of preventing any third parties to learn anything about a device location in space and time. There is thus a quadruplet (x, y, z, t) characterizing the location, where x, y, z are the spatial coordinates of the mobile device and t is the time at which that location is valid. When time is also known, we often talk about the user or device tracking.

There are two ways of defining the granularity of a location estimate: one is from the point of view of an attacker and it refers to the accuracy level at which the attacker can detect the location information; the other is from the user’s point of view, and it refers to the Quality of Service (QoS) received from a Location Service Provider (LSP), knowing that there is an inherent tradeoff between preserving his/her own location privacy via, for example, some cloaking or obfuscation mechanisms, and the QoS of the LBS. For example, let’s assume that the user’s true position at time t is (x, y, z), but the location information sent to the LBS and/or accessed by an attacker is (x + Δx, y + Δy, z + Δz). Then, the location granularity g in this case is defined as

g = √Δx² + Δy² + Δz²,

which is basically the distance uncertainty in the location estimate.

Table 1 (see inset photo, above right) gives examples of how an attacker can make use of the user location, if the user location is known with a certain granularity. The last column also shows positive examples of how the location information of a certain granularity can serve the user. Typically, the location needs to be known at several moments in time, ranging from a few hours to several months, in order for an attacker to be able to act upon the knowledge, but sometimes even the knowledge of as little as four different locations in time can lead to personal identification (see De Montjoye et alia in Additional Resources). As shown in Table 1, while one may be completely unconcerned if his/her location is known within a kilometer of error, this might be enough for an attacker to establish if a family is away from their home and to organize a house burglary. The examples of attacks shown in all rows above the current row are also applicable to the current row. For example, if the location is known within a few tens of meters from the actual position, house burglary, car thefts, or stalking are also potential threats, in addition to terrorism or disclosures of unwanted personal information, which are enabled by a more precise location known to an attacker.

Location Privacy in GNSS-Based Positioning Cloud GNSS
In the coming years, the development of new GNSS-based applications will play a leading role in the context of urban environments, i.e., Smart Cities, where almost every object or device such as urban furniture or wearable items can be connected between themselves, i.e., Machine to Machine (M2M) or D2D, and to the internet. In this sense, IoT applications have triggered the use of GNSS technologies for retrieving the Position, Velocity, and Timing (PVT) of the devices. Nevertheless, GNSS was designed for outdoor applications, and its performance gets truncated in urban working conditions. Moreover, IoT devices cannot implement advanced computational tasks due to constraints on low energy consumption, thus hindering the use of GNSS in harsh working conditions such as urban canyons, indoors, etc. Computational constraints are not only circumscribed to GNSS-based IoT devices, but also to conventional GNSS receivers providing advanced features such as multi-constellation processing, signal authentication, or threat detection (e.g., interference or propagation effects such as multipath or NLOS).

To overcome this hurdle, the Cloud GNSS concept has recently been proposed as a disruptive approach for solving most of the current limitations of conventional GNSS receivers (see Additional Resources). In this paradigm, the GNSS signal processing tasks traditionally carried out in on-chip GNSS modules at the user terminal, are now relocated in a cloud server, as illustrated in Figure 5, where on-demand scalable computing capacity in terms of data storage and processing power is available. Thanks to this availability, the energy consumption and computational power required by the user terminal is significantly reduced, since its main function is now to gather raw GNSS samples and transfer them to the cloud. Thanks to the computing capacity provided by the cloud, sophisticated GNSS signal processing techniques can easily be performed, thus providing a wider range of use cases where the GNSS sensor can effectively operate. For instance, Cloud GNSS can be used in liability-critical and safety-critical applications, where the use of conventional GNSS receivers faces some limitations due to the stringent requirements imposed on the user terminal in terms of integrity, continuity and, in the future, authentication.

The transfer of information from the user terminal to the cloud may raise some concerns on the potential vulnerabilities of cloud GNSS signal processing in terms of privacy and security. From a high-level perspective, we can identify three different categories of vulnerabilities, explained below: i) at the user-to-cloud communication link; ii) on the cloud storage of personal digital data, such as identifiers or GNSS raw samples; iii) on the computation, and therefore knowledge, of users’ location by third-parties, for example at the Location Based Service Provider (LBSP) side.

User-to-Cloud Communication
During the transmission of raw GNSS samples from the user’s device to the cloud server, personal data may eventually be intercepted by attackers. Location may also be known by the service provider of the network infrastructure due to the identifier each device holds, e.g., IP or MAC address or International Mobile Station Equipment Identity (IMEI). However, communication privacy and security is already provided by wireless infrastructures through secure communication protocols and standards, e.g., user access authentication implemented in Long Term Evolution (LTE) or Narrow Band Internet of Things (NB-IoT). Hence, the security and privacy of the user-to-cloud communication link is achieved with state-of-the-art wireless communication standards. Besides that, some cloud providers also offer secure platforms to connect users’ devices with the cloud. For instance, Amazon Web Services (AWS) offers an IoT platform, which already provides traffic encryption over Transport Layer Security (TLS) by using different cryptography standards such as X.509 or the Signature Version 4 Signing Process (SigV4).

Cloud Storage of Personal Digital Data
Customers may worry about the security involving the raw GNSS samples and personal digital data they upload to the cloud, due to the possibility of it being read or analyzed by third-parties (or attackers) and thus being used in an unauthorized manner. Nine critical threats to cloud security are identified by the Top Threats Working Group (Additional Resources): data breaches, data loss, account hijacking, insecure APIs (Application Program Interface), denial of service, malicious insiders, abuse of cloud services, insufficient due diligence, and shared technology issues. To prevent many of these threats, current cloud providers such as AWS, Microsoft Azure, and Google Cloud provide high-security systems with ISO 27001 certification, thus assuring confidentiality, integrity, and availability. With regard to the stored data, cloud platforms do not distinguish between personal data and any other type of data. Therefore, by using certified cloud platforms, the security of personal data, which in this case would be the raw GNSS samples file, the device location and any other stored personal data, would be guaranteed. Users shall realize that the security policies of a cloud service may change depending on the legislation of the country in which the cloud server is allocated, and hence personal digital data may be accessed by the government.

User’s Location Calculation by Third-Parties
Device anonymization is needed when the user’s location is known to a third-party, either when the location is calculated by the cloud GNSS platform or when it is used by some LBS. If not, the cloud and the LBS server might know who the devices’ owner is, and use the personal data and location for their own benefit. For LBS, a k-anonymization model to deal with location privacy is presented by B. Gedik and L. Liu. In this approach, an anonymity server decrypts the data transferred from the device to the LBS and removes all the related identifiers (e.g., IP or MAC address, device, or customer identifier). Next, the location information is disrupted by means of spatio-temporal cloaking (i.e., hiding the true location information in a wide spatio-temporal area), and finally, the anonymized location is sent to the LBS server. Note that this approach may perturb the quality of service, and thus a tradeoff between the QoS and location privacy is faced.

Another alternative is to assign a random identifier to every device, which is then changed after a fixed time such as minutes, hours, or days depending on the application, in order to facilitate the anonymization. In this context, hash-based ID variation (see Additional Resources) can be used for enhanced location privacy. This process is often accomplished through two different and independent entities, the first one (e.g., a certification body) being in charge of randomly assigning identifiers to users, and the second one (e.g., the LBSP) being in charge of the exploitation of the randomized data. This scheme guarantees that the entity making use of the data has no access to the mechanism whereby the identifier was generated and assigned to the user. In this manner, users have a time-varying identifier with limited lifetime that thus cannot be tracked for a long period of time. Clearly, the shorter the identifier lifetime, the better the user privacy, since we prevent inferral of user identification via behavior pattern analysis.

In conclusion, there are many protection schemes that can be used to solve the potential vulnerabilities of cloud GNSS positioning in terms of location security and privacy. When it comes to strengthening the privacy requirements of the user’s location, this often translates into a tradeoff between privacy and QoS.

Assisted GNSS
In order to position itself using the signals from navigation satellites, the GNSS receiver needs to know the precise time and orbital parameters to compute the positions of the satellites. The GNSS satellites broadcast this information in their navigation messages. However, decoding the orbital information from navigation messages takes 30 seconds in good signal conditions, which is a significant Time-To-First-Fix (TTFF), i.e., delay in the starting of positioning. This time may be much longer in environments dense with buildings or foliage where these obstacles attenuate the satellite signals. If the signal power decreases further, the receiver cannot decode the navigation data even if it is still able to make the ranging measurements. In this case, without information on satellite orbits and precise time, the measurements are useless for the receiver and it cannot compute its position.

In A-GNSS, the functionalities of a GNSS receiver are enhanced through terrestrial communication networks to shorten the TTFF and to improve the sensitivity of the receiver, i.e., to allow positioning with weaker satellite signals (J. Syrjäinne; F. Van Diggelen, Additional Resources). In A-GNSS, the missing information is provided to the receiver by a server that is connected to the receiver that has good visibility to the satellites (Figure 6). In addition to the orbital information and time, the A-GNSS can also deliver the Differential GNSS (DGNSS) corrections which allow improvements of positioning accuracy even to the one meter level.

Two architectures were proposed for A-GNSS where the roles of the user terminal (mobile station, MS) and the server in the network are different. In MS-based A-GNSS (MS-Based Network-Assisted) the user receives assistance data from the server and makes the ranging measurements, possible DGNSS corrections, and positioning calculations by itself. In MS-assisted A-GNSS (MS-Assisted Network-Based) the user terminal makes the ranging measurements and sends them to the server. The server applies the possible DGNSS corrections to the measurements, computes the position, and sends it back to the user. To assist the user terminal in the positioning measurements, the server sends a small set of assistance data to the user to enable fast signal acquisition.

In MS-based A-GNSS, in good signal conditions the user terminal can also position itself without assistance from the server. That is to say, the network connection is not necessary. In MS-assisted A-GNSS, the positioning of the user terminal always requires two-way communication with the server. The best achievable accuracy in both A-GNSS modes is defined by the DGNSS, which allows accuracies on the level of one meter (see Additional Resources). However, both modes are susceptible to multipath and NLOS, and therefore the accuracy is not always as good as in clear LOS. Actually, in an MS-based approach, the positioning accuracy may deteriorate to hundreds of meters when assistance is needed due to bad signal conditions. When the satellite signal levels drop very low, e.g., in underground settings, the user devices also cannot make the measurements, and both A-GNSS modes fail.

While both MS-based and MS-assisted architectures require point-to-point communication, either in the control plane of a cellular network or in the user plane of a wireless internet, only in MS-assisted approach does the user terminal reveal its accurate position to the server. The functionalities of the current Cloud GNSS are very similar to MS-assisted A-GNSS, therefore the privacy threats are also similar. For A-GNSS, secure architectures exist (L. Wirola et alia), e.g., the Open Mobile Alliance Secure User Plane Location Protocol (OMA SUPL) which provides security and authentication services using Generic Bootstrapping Architecture (3GPP GBA) (please see Additional Resources).

Conclusions
Our studies shed more light on users’ perception of their location privacy and on the privacy threats and solutions in modern wireless localization. We learned that, in general, users are not yet particularly aware of location privacy threats and most would not be willing to pay much or anything for private or passive positioning. In addition, privacy of localization is not yet fully solved in many state-of-the-art GNSS localization systems, such as Cloud GNSS and Assisted GNSS.

Acknowledgements
The authors express their warm thanks to the Academy of Finland (Project 303576) for its financial support for this research work.

Additional Resources
[1] 3GPP TS 33.220 Generic Bootstrap Architecture
[2] Chen, L., Thombre, S., Järvinen, K., Lohan, E. S., Korpisaari, P., Kuusniemi, H., Leppäkoski, H., Honkala, S. , Bhuiyan, M. Z. H., Ruotsalainen, L., Ferrara, G. N., Bu-Pasha, S., “Robustness, Security, and Privacy in Location-Based Services for Future IoT,” IEEE Access, Vol. 5, pp. 8956-8977, 2017
[3] De Montjoye, Y. A. , Hidalgo, C. A., Verleysen, M., and Blondel., V. D., “Unique in the Crowd: The Privacy Bounds of Human Mobility,” Scientific Reports 3, Article number: 1376, 2013
[4] Gedik, B. and Liu, L., “Location Privacy in Mobile Systems: A Personalized Anonymization Model,” Proceedings of the 25th IEEE International Conference on Distributed Computing Systems, ICDCS, pp. 620-629, June 2005
[5] Gschwandtner, F. and Schindhelm, C. K., Spontaneous Privacy-Friendly Indoor Positioning using Enhanced WLAN Beacons, 2011
[6] Henrici, D. and Muller, P., “Hash-based Enhancement of Location Privacy for Radio-Frequency Identification Devices using Varying Identifiers,” Proceedings of the 2nd IEEE Annual Conference in Pervasive Computing and Communications Workshops, pp. 149-153, March 2004
[7] Li, M., Zhu, H., Gao, Z., Chen, S., Ren, K., Yu, L., and Hu, S., “All Your Location are Belong to Us: Breaking Mobile Social Networks for Automated User Location Tracking,” Proceedings of MobiHoc, ACM, pp. 43-52 2014
[8] Lucas-Sabola, V., Seco-Granados, G., López-Salcedo, J. A., García-Molina, J. A., and Crisci, M., “Cloud GNSS Receivers: New Advanced Applications Made Possible,” Proceedings of the International Conference in Localization and GNSS (ICL-GNSS), pp. 1-6, June 2016
[9] Maglogiannis, I., Kazatzopoulos, L., Delakouridis, K., and Hadjiefthymiades, S., “Enabling Location Privacy and Medical Data Encryption in Patient Telemonitoring Systems,” IEEE Transactions on Information Technology in Biomedicine, Vol. 13, No. 6, pp. 946-954, November 2009
[10] Mascetti, S., Bertolaja, L., and Bettini, C., “A Practical Location Privacy Attack in Proximity Services,” 2013 IEEE 14th International Conference on Mobile Data Management, Milan, pp. 87-96, 2013
[11] Misra, P. and Enge, P., Global Positioning System – Signals, Measurement and Performance, 2nd ed., Ganga-Jamuna Press, ISBN 0-9709544- 1-7, 2006
[12] OMA Secure User Plane Location 1.0, OMA-ERP-SUPL-V1_0-20070615-
[13] Pomfret, K., “Geolocation Privacy – Implications of Evolving Expectations in the United States,” Inside GNSS, September/October 2016
[14] Skorin-Kapov, L., Pripužić,K., Marjanović, M., Antonić, A., and Žarko, I. P., “nergy Efficient and Quality-Driven Continuous Sensor Management for Mobile IoT Applications,” 10th IEEE International Conference on Collaborative Computing: Networking, Applications, and Worksharing, Miami, FL, pp. 397-406, 2014
[15] Syrjärinne, J., Studies of Modern Techniques for Personal Positioning, Ph.D. Dissertation, Tampere University of Technology, 2001
[16] Top Threats Working Group, The Notorious Nine: Cloud Computing Top Threats in 2013, Cloud Security Alliance, 2013
[17] Van Diggelen, F., A-GPS : Assisted GPS, GNSS, and SBAS, Artech House, 2009
[18] Webropol web survey tool
[19] Wirola, L., Laine, T. A., and Syrjärinne, J., “Mass-Market Requirements for Indoor Positioning and Indoor Navigation,” Proceedings of the International Conference on Indoor Positioning and Indoor Navigation (IPIN), Zürich, Switzerland, 2010

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

Working Papers explore the technical and scientific themes that underpin GNSS programs and applications. This regular column is coordinated by Prof. Dr.-Ing. Günter Hein, head of Europe’s Galileo Operations and Evolution.

Working Papers explore the technical and scientific themes that underpin GNSS programs and applications. This regular column is coordinated by Prof. Dr.-Ing. Günter Hein, head of Europe’s Galileo Operations and Evolution.

Several advanced services rely on Global Navigation Satellite System (GNSS) receivers as data providers. GNSS-derived position, velocity, and time (PVT) information enables applications such as proximity-based marketing, real-time travel services, traffic updates, precision farming, weather reports, and roadside assistance, to mention a few examples.

GNSS receivers also play a significant role in several regulated applications where security is an important aspect. In the road transportation sector, the new EU Regulation 165/2014 (see European Commission in Additional Resources) adopted in February 2014 by the European Parliament and the Council foresees the introduction of a new generation of Digital Tachographs (DTs), called “smart tachographs,” with increased security mechanisms, a GNSS component, and different communication interfaces. Tachographs record driving time and mitigate the risk of tired drivers having looser control of vehicles with higher risk of accidents. There are potential economic incentives for infringement of the regulation and tampering with the tachograph system. In this respect, the secure provision of PVT information from a trusted GNSS receiver is an important asset.

Integrated in smartphones, GNSS receivers can also be used to increase the security of mobile banking services (see A. Pujante in Additional Resources). In addition, there may be economic interests around smartphone usage to falsify the data provided by a GNSS receiver.

In this respect, GNSS receivers can be interpreted as nodes in a network where they provide location data to higher service levels. In the tachograph, the vehicle unit, i.e., the recording equipment installed in the commercial vehicle to monitor the driver behavior, implements and provides these higher service levels. In smartphones, these levels are the final user applications: electronic fraud can take advantage of possible vulnerabilities of the communication channel between GNSS receivers and higher service levels. In particular, GNSS Faking Software (GFS) applications can be installed on the smartphone to falsify the user position with the final goal of obtaining a personal or commercial benefit.

GNSS data faking consists of intercepting genuine GNSS data and replacing them with forged location information. Differently from jamming and spoofing, which operate at the Signal-in-Space (SiS) level, GNSS data faking operates at the receiver level. GNSS data faking tries to intercept and falsify the messages between the GNSS receiver and the application nodes.

In GNSS spoofing, an attack can be detected by exploiting SiS-specific features which are difficult to counterfeit (see A. Jafarnia-Jahromi et alia in Additional Resources). Similarly, a possible solution to GNSS data faking is the usage of device-specific features which are difficult to counterfeit. This approach is usually referred to as device fingerprinting and is defined as “the process of gathering device information to generate device-specific signatures using them to identify individual devices” (Q. Xu et alia, Additional Resources). Fingerprinting has gained significant interest in the field of wireless networks where node forgery or impersonation has become a threat. Node forgery consists of the acquisition of legitimate credentials by an adversary who will use them to conduct fraudulent activities. GNSS data faking is similar to node forgery in a wireless network.

In particular, a simulator or another device can be used to impersonate an actual GNSS receiver. In this way, misleading PVT information can be sent to the final PVT user. GNSS receiver fingerprinting can be adopted in security- enhanced applications that will be able, at least to a certain extent, to verify the authenticity of GNSS data. In such applications, the device which relies on GNSS data, such as the vehicle unit of the tachograph, will also extract from the received GNSS messages unique features which could be used to validate the identity of the GNSS receiver by comparing it to the previously recorded data. In a potential deployment scenario for the DT, the vehicle unit could record the fingerprints of the GNSS receiver in the initial installation phase or during the periodic calibration checks (e.g., every two years as defined by the regulation). The installation and calibration phases are executed in a controlled environment (e.g., workshop) where the identity of the GNSS receiver can be checked by the installer.

The first step in device fingerprinting is the selection of appropriate features, which should satisfy two basic properties: the features should be difficult to counterfeit and be stable with respect to environmental changes.

We investigate the selection of appropriate features for GNSS receiver fingerprinting. This process consists of considering, at first, a set of redundant metrics that have the potential to identify the receiver. A fingerprint, i.e., a subset of the original set of metrics, is then selected using a filtering approach.

We first investigate metrics related to the receiver clock, summarizing the results obtained by the authors in the paper presented at the 2016 ION GNSS+ conference and listed in Additional Resources. We then extend the analysis to clock-unrelated features.

Clock-Based Metrics
Fingerprinting of electronic devices is often based on distinctive imperfections such as the errors generated by the local oscillator of the device under test. In the context of wireless networks, Radio Frequency (RF) oscillator imperfections have been used as a source of reliable, forge-resistant features (see, for example, A. C. Polak and D. L. Goeckel in Additional Resources).

Consider for example, the normalized frequency error shown in Figure 1. The time series have been obtained by normalizing the receiver clock drift estimated as part of the navigation solution of a GNSS receiver and shows distinctive random effects with (possibly) stable characteristics. These characteristics must be identified and used as features.

We analyzed several metrics that are adopted in the literature to characterize the behavior of a time/frequency source.

The metrics considered are illustrated in Figure 2 that also describes the main elements of the methodology adopted for their evaluation. GNSS measurements are used to compute the user PVT solution. The normalized receiver frequency error, f_e[n], is then computed from the clock bias, dt_r[n], as 

Equation (1) (for equations, see inset photo, above right)

here n is the time index and Ts is the sampling rate. f_e[n] can also be computed by normalizing the clock drift by the GNSS center frequency, in this case f_L1=1575.42 MHz. The time series shown in Figure 1 have been obtained by normalizing the clock drift estimated during a static data collection. It is noted that the clock drift and the clock bias are computed from different observables, Doppler measurements, and pseudoranges. Thus, they have different characteristics. We showed in our paper presented at the ION 2016 GNSS+ conference that the normalized frequency error derived from Doppler measurements leads to the features that are more stable to environmental changes. Doppler measurements are less affected by the different error sources and thus should be preferred for the determination of receiver features.

The normalized frequency error is then used to compute different metrics such as the Allan Deviation defined as (see S. Bregni, Additional Resources):

Equation (2)

Equation (3)

The Allan Deviation is a curve which depends on the averaging time, τ. For this reason, it cannot be used directly as a feature for fingerprinting. Therefore, summary statistics, describing the behavior of the Allan Deviation are needed. We selected the Allan Deviations at τ = 1 second and at τ = 30 seconds, the curve slope between τ = 1 second and τ = 30 seconds, the minimum value, and the averaging time corresponding to the minimum Allan Deviation. In this way, five features where obtained from the Allan Deviation.

A similar process was undertaken for other performance curves that are generally used for characterizing time and frequency sources. We considered the Root Mean Square Time Interval Error (RMS-TIE), the Maximum Time Interval Error (MTIE), and the correlation between the samples of the normalized frequency error. As for the Allan Deviation, summary statistics were selected. In this way, a total of 13 features were determined. Additional details on the different features selected can be found in D. Borio et alia.

Clock-Unrelated Metrics
Many mass-market receivers only provide the user location and velocity. In this case, it is not possible to compute the clock-based metrics discussed above. For this reason, we considered clock-unrelated features for receiver identification. The term “clock-unrelated” is used to denote features derived from the position and velocity time series, i.e., from data that do not include the receiver clock bias and clock drift. The rationale behind the analysis conducted is that the errors affecting the clock components and the vertical components in the navigation solution should, in general, be highly correlated. In this way, it should also be possible to extract effective features for receiver fingerprinting from the spatial components of the navigation solution.

We followed an approach similar to that detailed for the clock-related features. In particular, the features described in the previous section were computed using velocity and position components. For example, the Allan Deviation is computed using the velocity time series. In this case, the Allan Deviation does not characterize the stability of the receiver oscillator but determines the quality of the velocity solution.

From the analysis conducted, it emerged that clock-unrelated features are not, in general, strongly related to their clock-based counterpart. Figure 3 compares the Allan Deviations computed using the different PVT components for two different receivers. The left column of the figure considers Allan Deviation curves computed using Doppler-based time series. Since velocity components and clock drifts have different normalizations, the curves have been shifted in order to make the initial point of each plot coincide. In particular, the Allan Deviations were shifted to start at one. A good match between Allan Deviations is found between the different curves for τ ∈ [1 – 100] for the one receiver considered in the top row of Figure 3. The same result, however, is not true for the other receiver considered in the bottom row. Although a better match is found when considering pseudorange-derived metrics (see right column of Figure 3), clock-unrelated metrics convey, in general, different information than their clock-based counterparts. Thus, the results obtained from the clock bias and drift cannot be directly applied to features extracted from position and velocity time series.

Filtering and Feature Selection
After selecting a redundant set of candidate features, it is necessary to apply a selection process in order to determine the most effective subset of features for classification. Feature selection algorithms are broadly classified as filter and wrapper methods (see the review paper from G. Chandrashekar and F. Sahin, Additional Resources). The former approaches use a cost function to rank the different subsets of features. The latter techniques wrap the selection process around a classifier/predictor, i.e., the final “user” of the subset of features selected. In particular, wrapper methods select the subset of features with the highest classification performance.

We adopted a filter approach as a compromise between complexity and performance. To apply the filtering approach, it is first necessary to preprocess the time series obtained from the GNSS receivers. The pre-processing applied here is briefly summarized in Figure 4. The time series collected for the feature computation are first segmented into data blocks of limited duration. Each segment of data will be used for computing a different realization of the metrics described above. In this way, several realizations of feature vectors are obtained. Note that several receivers of different models have been used for the analysis described in the next sections. Each receiver model represents a class. In this way, several realizations of the feature vectors are obtained for the different classes. The components of the feature vectors are heterogeneous and can assume significantly different values. Thus, a normalization is required. The following normalization is used here:

Equation (4)

where χ_j^k denotes the jth realization of the kth feature. The overline notation is used to denote normalized quantities. In the following, an additional index will be used to denote membership to a specific class or receiver type. The maximum and minimum values are obtained considering all the feature realizations from all receiver classes. Using Equation (4), normalized feature vectors are obtained where each component takes values within the [0, 1] range.

After data pre-processing, feature filtering is applied. The score function considered here is

Equation (5)

where F denotes the subset under analysis and d_i,j(F) is the inter-class distance between classes i and j. d_i,j(F) is the intra-class distance of the ith class. The intra- and inter-class distances are defined in terms of normalized features (4). In particular, the intra-class distance is defined as

Equation (6)

Equation (7)

and describes the average distance between two classes. Figure 5 provides a geometric interpretation of the different quantities defined here. It emerges that score function (5) is the ratio between the minimum distance between classes and the larger class size. Thus, subset F is selected in order to maximize the spread between classes and minimize the class dimensions.

Experimental Setup
The theoretical framework described in the previous sections has been implemented and tested using the data collected during two data collections. The tests were performed in different weeks and in different signal conditions. Two different scenarios were selected in order to evaluate the feature stability to environmental changes.

The first test was conducted using a geodetic antenna located on the European Microwave Signature Laboratory (EMSL) at the Joint Research Centre (JRC) premises in Ispra, Italy. The EMSL is the highest building in the area and no obstacles are present around the antenna. Hence, the first test was carried out in open-sky conditions.

The second test was performed using an antenna mounted on the rooftop of an office building in the JRC campus. In this case, the building is surrounded by taller constructions and by high trees which cause multipath and fading creating a disturbed signal environment.

The locations of the antennas used for the data collection are shown in Figure 6.

A common setup was designed and adopted for the two data collections. In each setup, several receivers were connected to the same antenna using an RF splitter and used to collect almost four days of data for each experiment. The length of each data collection justifies the data segmentation introduced in the previous section. The receivers logged raw GNSS observables, i.e., pseudoranges and Doppler shifts, with a 1 hertz data rate. Different types of receivers were used, including mass-market and professional multi-constellation receivers.

In order to have the same conditions, only GPS measurements were used for the data analysis. Moreover, a common set of ephemerides were adopted for all the receivers. In this way, the same operational conditions were adopted for the different receivers.

The list of receivers used in the two tests is provided in Table 1 along with the number of devices of the same type. The actual model of the devices can be found in the Manufacturers section.

Five GNSS timing modules were used for the two data collections. Among them, one was updated with the latest firmware that enabled the processing of Galileo signals. The update was performed to analyze the impact of firmware changes on devices of the same type.

Experimental Results
The data collected during the two tests described above were used for feature selection. In particular, subsets of two and three elements were considered. For each subset, score function (5) was computed. We considered only features derived from Doppler measurements, i.e., computed from the velocity/clock drift solution, because of the higher stability of these types of observables to errors and environmental changes. The features have been computed using data segments of one hour, i.e., 3,600 elements.

Subsets of three elements are analyzed in Figure 7 where both clock-based and clock-unrelated metrics are considered. In the clock-based case, features are computed from the receiver clock drift. In the clock-unrelated case, the up component of the velocity solution is used. Since 13 features were originally considered, a total of 286 subsets is found. The abscissa in Figure 7 is the index used to enumerate the different subsets of three elements. From the results reported in Figure 7, it clearly emerges that clock-based features significantly outperform their clock-unrelated counterparts. In the clock-based case, the maximum value of the score function is greater than six. This implies that, for the feature subset leading to the maximum of (5), the smallest inter-class distance is more than six times bigger than the largest inter-class distance. In this way, classes/receiver types are clearly separated and effective clustering can be performed.

This fact is further analyzed in Figure 8 showing the clusters formed using the three features leading to the maximum value of (5). These features are all derived from the Allan Deviation curve and are the Allan Deviations at τ = 1 second and τ = 30 seconds, and the averaging time leading to the minimum Allan Deviation value. The different receivers can be easily identified in the feature space depicted in Figure 8. The professional receivers from one manufacturer show enhanced performance in terms of Allan Deviation with respect to mass-market devices. This is expected given the different market segment, i.e., that of professional receivers. Mass-market receiver of type a is the only device showing significantly different behaviors in the two data collections. In the open-sky scenario, this receiver has features similar to those obtained for the timing modules mentioned above. Figure 8 also shows that firmware updates can affect the receiver behavior. This fact clearly emerges when considering the behavior of the one device updated with the Galileo firmware: the cluster defined by the features determined for this device is clearly distinct from that of the standard timing modules.

In the clock-unrelated case, the score function is always lower than 0.5. This implies a significant overlapping between classes in terms of clock-unrelated features. This fact is further investigated in Figure 9 showing feature selection results in the two-dimensional case. Two-dimensional feature vectors are considered here for clarity reasons. When the three-dimensional case is considered, the feature space representation is quite cluttered making the interpretation of the results more difficult. Moreover, the score function reported in the right part of Figure 9 shows that, in the clock-unrelated case, there is no significant gain when moving from fingerprints with two features to vectors with three elements.

The receiver classes represented in the left part of Figure 9 show that the one manufacturer’s receivers of different types have similar features. The overlapping between classes observed in Figure 9a compromises the overall score that does not increase even when an additional feature is included for fingerprinting. However, the results observed suggest that clock-unrelated features may allow for the identification of different receiver manufacturers. When considering receivers from the other manufacturer, the Allan Deviation at one second progressively decreases as a function of the receiver generation. This result reflects the fact that more recent receiver models have better Allan Deviations than older models.

Conclusion
This working paper provides initial results towards the fingerprinting of GNSS devices. The PVT solutions provided by GNSS receivers were considered as possible sources of features for fingerprints. It was shown that Doppler-derived time series, i.e., the three velocity components and the receiver clock drift, are more stable to environmental changes and thus should be preferred for receiver fingerprinting. Moreover, clock-related features, i.e., metrics derived from the receiver clock bias and drift, better discriminate the different receiver models. In this respect, a vector of three clock-derived features is sufficient to characterize a receiver model. Clock-unrelated features, i.e., based on the velocity time series, do not always allow for the identification of the receiver model. Despite this fact, experimental results indicate that manufacturer identification should at least be possible using clock-unrelated features.

Additional data collections will be performed as future work to confirm the preliminary results discussed here. A classification framework based on the features identified will also be implemented to demonstrate automatic receiver identification.

Additional Resources
[1] Borio, D., Gioia, C., Baldini, G., and Fortuny, J., “GNSS Receiver Fingerprinting for Security- Enhanced Applications,” Proceedings of the 29th International Technical Meeting of the Satellite Division of The Institute of Navigation (ION GNSS+ 2016), Portland, OR, September 2016
[2] Bregni, S, Synchronization of Digital Telecommunications Networks, Wiley, June 2002
[3] Chandrashekar, G. and Sahin, F., “A Survey on Feature Selection Methods,” Computers & Electrical Engineering, Volume: 40, Issue: 1, 2014.
[4] European Commission, “Regulation (EU) No 165/2014 of the European Parliament and of the Council of 4 February 2014 on Tachographs in Road Transport,” on-line, 2014
[5] Jafarnia-Jahromi, A., Broumandan, A., Nielsen, J., and Lachapelle, G., “GPS Vulnerability to Spoofing Threats and a Review of Anti-Spoofing Techniques,” International Journal of Navigation and Observation, May 2012
[6] Polak, A. C. and Goeckel, D. L., “Wireless Device Identification based on RF Oscillator Imperfections,” IEEE Transactions on Information Forensics and Security, Volume: 10, December 2015
[7] Pujante, A., “Location Authentication, Enabling New Smartphone Apps,” Inside GNSS, Volume: 9, May-June 2014
[8] Xu, Q., Zheng, R., Saad, W., and Han, Z., “Device Fingerprinting in Wireless Networks: Challenges and Opportunities,” IEEE Communications Surveys and Tutorials, Volume: 18, First Quarter 2016

The post Feature Selection for GNSS Receiver Fingerprinting appeared first on Inside GNSS - Global Navigation Satellite Systems Engineering, Policy, and Design.