PHD Thesis Ifernandez Aau OTTIMA

SNAPSHOT AND AUTHENTICATION TECHNIQUES
FOR SATELLITE NAVIGATION
by
Ignacio Fernández Hernández
Dissertation submitted to the Faculty of Engineering and Science at Aalborg University
in partial fulfilment of the requirements for the degree of
Doctor of Philosophy in Electrical Engineering.
I
SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
Thesis submitted: May 7th, 2015
PhD supervisors: Prof. Kai Borre,
Aalborg University
Prof. Torben Larsen,
Aalborg University
PhD committee: Prof. Per K. Enge, Stanford University
Dr. Frank van Diggelen, Broadcom Corporation
Prof. Søren Holdt Jensen, Aalborg University
PhD Series: Faculty of Engineering and Science, Aalborg University
II
ENGLISH SUMMARY
Since GPS was declared fully operational in 1995, satellite navigation technologies have
evolved in many ways. Two of them are the drivers for this doctoral thesis: satellite
navigation authentication and snapshot positioning techniques.
The first research area of this thesis is GNSS authentication. In spite of the high importance
of GNSS in our society and economy, its civil signals are easy to counterfeit. This thesis
proposes novel techniques and concepts, such as satellite cross-authentication, single key
chains for all satellites, and offsetting schemes, to improve the performance of navigation
message authentication. It presents and analyses a solution requiring less than two hundred
bits for authenticating four satellites, providing high availability and robustness.
The second research area of this thesis is snapshot positioning. Snapshot techniques are based
on computing a position using only a set of digital signal samples captured over some
milliseconds. Existing techniques require a rough knowledge of the position and/or time at
which the snapshot was captured. This thesis proposes and characterizes a novel method to
instantaneously compute a snapshot position without any initial information. The proposed
method does not cause any accuracy or availability degradation compared to other state-of-
the-art snapshot methods.
In relation to the previous area, this thesis also deals with the generalization of the snapshot
positioning concept to non-GNSS satellites. By using more powerful signals from non-GNSS
satellites, indoors localization and resilience can be improved. This thesis proposes a method
based on a ground network that processes non-GNSS satellite signal snapshots and is able to
compute from them the instantaneous position and other reference parameters of those
satellites. Thus, a receiver can get a fix by receiving its own snapshot and the associated
instant satellite parameters from the ground network. Experimentation shows that, depending
on the satellite-ground geometry and signal characteristics, metre-level accuracies are
possible with this method.
This thesis also presents some research initial on the combination of authentication and
snapshot positioning. Snapshot authentication methods based on a trusted clock and
geometrical constraints are proposed to authenticate unpredictable signals through snapshot
techniques.
III
DANSK RESUME
GPS blev erklæret fuldt operationelt i 1995. Siden da har teknologien bag satellit navigation
udviklet sig på mange måder. To af dem er drivkraften bag denne Ph D afhandling:
troværdighed (på engelsk: authentication) af satellitbaseret navigation og metoder for snap-
shot positionering.
Det første forskningsområde i denne afhandling vedrører troværdigheden af GNSS. På trods

af den store betydning af GNSS i vores samfund og økonomi er det let at forfalske de civile
signaler. Denne afhandling foreslår nye teknikker og begreber -- som kryds-troværdighed
mellem satellitter, signatur for alle satellitter og forskydningstabeller -- for at sikre
troværdigheden af navigationsdata. Den fremlægger og analyserer en løsning, der kræver
mindre end to hundrede bits for at gøre fire satellitter troværdige, tilvejebringe høj
tilgængelighed og robusthed.
Afhandlingens andet forskningsområde vedrører snap-shot positionering. Snap-shot metoder

beregner en position udelukkende på grundlag af et sæt signaler hver af en varighed på få
millisekunder. Eksisterende metoder kræver kendskab til position og/eller det tidspunkt, hvor
snap-shottet blev indsamlet. Denne afhandling foreslår og karakteriserer en hidtil uset metode
til øjeblikkeligt at beregne en snap-shot position uden nogen forudgående information. Den
foreslåede metode indebærer ikke forringet nøjagtighed eller tilgængelighed sammenlignet
med de mest avancerede snap-shot metoder.
I tilknytning til det foregående emne indeholder denne afhandling også en generalisering af
snap-shot positionering, så den omfatter ikke-GNSS satellitter. Ved at anvende kraftigere
signaler fra ikke-GNSS satellitter kan man forbedre indendørs lokalisering og den tilknyttede
robusthed. Denne afhandling foreslår en metode -- baseret på et jordbaseret net -- som
beregner snap-shots fra ikke-GNSS satellitter og er i stand til også at beregne en øjeblikkelig
position og andre reference parametre for disse satellitter. Herved kan en bruger beregne en
position ved at modtage sit eget snap-shot og de tilknyttede øjeblikkelige satellit parametre
fra det jordbaserede net. Eksperimenter viser, at afhængig af satellit-jord geometrien og
signal egenskaberne er det muligt at opnå meter nøjagtighed med denne metode.
IV
Et fjerde forskningsområde, der sættes i gang i denne afhandling, er kombinationen af
troværdighed og snap-shot positionering. Der foreslås en snap-shot metode, der baserer sig på
en pålidelig ekstern ur-reference, hvorved uforudsigelige signaler kan gøres troværdige
gennem snap-shot teknikker.
V
ACKNOWLEDGEMENTS
First, I would like to thank my supervisors Prof. Kai Borre and Prof. Torben Larsen,
from AAU, for facilitating so much the process of preparing my PhD candidature. Prof.
Borre has given me very valuable strategic advice and a lot of technical and moral
support over these years, and Prof. Larsen has helped me a lot on the home strait of the
thesis. Both have given me their trust and a lot of flexibility in the orientation the
research activities, which I highly appreciate.
I would like to give specially thanks Prof. Gonzalo Seco-Granados, for his generosity and
patience in sharing some of his vast knowledge and perspicacity with me. His help
extends throughout all the research in this thesis, including both snapshot and
authentication areas. He has provided many useful references and suggestions, especially,
but not only, on signal-related aspects.
The work on authentication relates to my job duties and my job colleagues have partly
supported it. I have been luckily surrounded by very good engineers “helping the cause”
of authenticating Galileo in a selfless, constructive and collaborative way, reviewing and
discussing material and making insightful comments. I would like to thank Prof. Vincent
Rijmen for providing many references and recommendations used in this thesis
concerning the cryptographic parts and for being available to share his insight during our
long discussions. I also appreciated Dr. Paul Walker's critical review and useful
suggestions. The review and sharp comments from Andrew Kerns and Prof. Todd
Humphreys have been also very valuable. Javier Simón, Guillermo Tobías, David Calle,
Enrique Carbonell and Irma Rodríguez, with the support of Oscar Pozzobon, Laurens
Bogaardt and Dominic Hayes, have also significantly contributed to improving the
quality of our publications on the subject. In addition, I would like to thank my
colleagues at EC/GSA Fiammetta Diani, Jean Marechal and Eric Châtre for their
determination and support.
On the snapshot research area, I would like to thank Oriol Badia for giving me access to
some of the snapshot data captures and Matlab code from his Master's Thesis at AAU. I
would also like to thank Michele Bavaro for kindly lending me one of his SDRs, and
Darius Plaušinaitis.
6
Dr. Frank van Diggelen's A-GPS book, Prof. Enge's GPS book, and Prof. Borre's GNSS
SDR book are the three main references that have allowed me to “triangulate” and find
my way through this thesis, with the regular assistance channel of Prof. Seco. I am highly
privileged in having Dr. van Diggelen and Prof. Enge, together with Prof. S. J. Jensen, in
my PhD assessment committee. I would like to thank them for their availability and
inspirational contributions, without which this thesis would not probably have been even
started.
Finally, but most importantly, I would like to thank Paloma, my wife, for her continuous
support during this journey.
The information and views set out in this dissertation are those of the author and do not
necessarily reflect the official opinion of the European Union.
7
TABLE OF CONTENTS
Chapter 1. Introduction ..................................................................................................... 17

1.1. Scientific Challenges and Main Contributions....................................................... 17
1.2. Thesis Outline ........................................................................................................ 20
Chapter 2. General Technical Background....................................................................... 21

2.1. A Brief History of Navigation ................................................................................ 21
2.2. Radionavigation Methods ...................................................................................... 24
2.2.1. Satellite Navigation Systems and Signals ........................................................ 25
2.2.2. Satellite Navigation Receivers ......................................................................... 28
2.3. A Brief History of Cryptography ........................................................................... 29
2.3.1. Modern Cryptography and Asymmetric Algorithms ....................................... 31
2.3.2. GNSS and Cryptography ................................................................................. 33
Chapter 3. Navigation Message Authentication ............................................................... 36

3.1. Motivation .............................................................................................................. 36
3.2. Background ............................................................................................................ 37
3.2.1. Information Security Management Systems (ISMS) ....................................... 37
3.2.2. Standards .......................................................................................................... 38
3.2.3. GNSS Positioning Threats ............................................................................... 40
3.2.4. Detection and Mitigation Actions .................................................................... 41
3.2.5. Detection and Mitigation based on GNSS Signal Properties........................... 42
3.2.6. Summary .......................................................................................................... 43
3.3. User Needs, High Level Requirements and Design Drivers .................................. 43
3.4. Performance Indicators .......................................................................................... 46
3.4.1. Authentication Error Rate ................................................................................ 48
3.4.2. Time Between Authentications ........................................................................ 49
8
3.4.3. Robustness against Replay Indicators: Maximum Predictable Time and
Unpredictable Symbol Ratio...................................................................................... 50
3.4.4. Other Robustness Indicators ............................................................................ 51
3.5. Proposed GNSS Authentication Concept .............................................................. 51
3.5.1. The TESLA Protocol Features ......................................................................... 51
3.5.2. TESLA with a Single Chain from Several Senders ......................................... 54
3.5.3. TESLA with a Single Chain and Different Keys from Different Senders ...... 55
3.5.4. TESLA and "Cross-Authentication" ................................................................ 58
3.6. An NMA Proposal for Galileo Signals .................................................................. 59
3.6.1. H-K-root Section ............................................................................................. 62
3.6.2. MAC-K Sections ............................................................................................. 65
3.6.3. Bandwidth Allocation Analysis ....................................................................... 69
3.7. A Proposed Implementation in the Galileo System and Facilities ......................... 70
3.7.1. NMA Architecture ........................................................................................... 70
3.7.2. System Latency and User Performance ........................................................... 71
3.7.3. Message Losses ............................................................................................... 75
3.7.4. Downlink Requirements .................................................................................. 76
3.7.5. NMA of Data from Other GNSS ..................................................................... 77
3.8. Design Trade-Offs.................................................................................................. 77
3.8.1. Cross-Authentication of Neighbouring Satellites ............................................ 78
3.8.2. Digital Signatures vs. Time-Delayed Asymmetry ........................................... 80
3.8.3. Staggering of Authentication Events ............................................................... 81
3.8.4. Security Considerations ................................................................................... 83
3.8.5. Receiver CPU Needs ....................................................................................... 85
3.9. Performance Results............................................................................................... 86
3.9.1. NMA Availability and AER ............................................................................ 86
3.9.2. Time To First Authenticated Fix ................................................................... 100
3.9.3. Performance Assessment in Urban Environments – A Practical Case .......... 103
9
3.9.4. Assumptions for satellites transmitting NMA ............................................... 106
3.9.5. Assumptions for satellite MAC sequence ...................................................... 106
3.10. Signal Unpredictability and Anti-Replay Protection ......................................... 108
3.10.1. USR and Predictability of the Last Bits of the Key ..................................... 109
3.10.2. Symbol Unpredictability and MPT after Encoding and Interleaving .......... 111
3.10.3. Detection of Signal Replay Attacks Based on NMA ................................... 115
3.11. Conclusions ........................................................................................................ 120
Chapter 4. Snapshot Positioning Without Initial Information ........................................ 123

4.1. Motivation ............................................................................................................ 123
4.2. Background .......................................................................................................... 124
4.2.1. Snapshot Positioning ...................................................................................... 124
4.2.2. Snapshot Signal Acquisition and Measurement Accuracy ............................ 126
4.2.3. Snapshot Synchronisation .............................................................................. 127
4.2.4. Code Phase Ambiguity Resolution ................................................................ 128
4.3. General Description of the Proposed Algorithm .................................................. 129
4.3.1. "Cold Snapshot" Equations for a Static Receiver .......................................... 132
4.3.2. "Cold Snapshot" Equations for a Dynamic Receiver..................................... 133
4.4. General Algorithm Implementation Including Long Time Uncertainty Periods . 134
4.4.1. Orbital Repeatability and Advantages of Multi-GNSS ................................. 137
4.4.2. "Cold Snapshot" with Coarse Time Pseudorange Navigation ....................... 140
4.4.3. Hardware Implementations and Applications of the Proposed Algorithm .... 141
4.5. Experimental Results............................................................................................ 142
4.5.1. Configuration ................................................................................................. 143
4.5.2. Signal Acquisition .......................................................................................... 144
4.5.3. Coarse Time Doppler Stage ........................................................................... 147
4.5.4. Coarse Time Navigation and Final PVT Calculation .................................... 149
4.5.5. Results ............................................................................................................ 149
4.6. Conclusions .......................................................................................................... 152
10
Chapter 5. Generalisation of Snapshot Positioning ........................................................ 154
5.1. Motivation ............................................................................................................ 154
5.2. Background .......................................................................................................... 156
5.2.1. Overview of non-GNSS Constellations, Satellites and Signals ..................... 156
5.2.2. Background on Positioning with Non-GNSS Satellites ................................ 158
5.3. Signal and Error Model ........................................................................................ 159
5.3.1. Ranging Accuracy Estimation Through the CRLB ....................................... 161
5.4. Description of the Method ................................................................................... 162
5.4.1. Capture of User Receiver Snapshot ............................................................... 163
5.4.2. Capture of Snapshot at Monitor Stations ....................................................... 165
5.4.3. Signal Acquisition and Satellite Range Estimation ....................................... 167
5.4.4. Instantaneous Satellite Position and Clock Calculation ................................ 169
5.4.5. Satellite Velocity and Frequency Drift Calculation ....................................... 171
5.4.6. Reference Parameters for at Least Four Satellites. ........................................ 171
5.4.7. User Receiver Position Calculation ............................................................... 172
5.5. Experimental Results: One Satellite Snapshot Positioning.................................. 172
5.5.1. Configuration ................................................................................................. 173
5.5.2. Simulator Steps .............................................................................................. 176
5.5.3. Signal Acquisition and Parameter Estimation ............................................... 177
5.5.4. Satellite PVT Computation ............................................................................ 178
5.5.5. Results............................................................................................................ 178
5.6. Experimental Results: User Snapshot Positioning Based on Satellite Snapshot

Positioning .................................................................................................................. 180
5.6.1. Configuration ................................................................................................. 180
5.6.2. Simulator Steps .............................................................................................. 184
5.6.3. Results............................................................................................................ 184
5.7. Conclusions .......................................................................................................... 187
Chapter 6. Conclusions and Further Work ..................................................................... 189

6.1. Further Work ........................................................................................................ 190
11
6.1.1. GNSS Authentication..................................................................................... 190
6.1.2. Cold Snapshot ................................................................................................ 191
6.1.3. Snapshot Generalisation................................................................................. 191
6.1.4. Snapshot Authentication ................................................................................ 192
Literature list................................................................................................................... 193

Appendices ..................................................................................................................... 203
12
TABLE OF FIGURES
Figure 1 – John Harrison's portable Chronometer H5 ...................................................... 22

Figure 2 –LEO, MEO and GEO satellite orbital radiuses, periods and speeds ................ 25
Figure 3 – Satellites in view foreseen at Aalborg, 23/6/2015, 12:00 (CET) .................... 26
Figure 4 – GNSS signals .................................................................................................. 27
Figure 5 – GNSS receiver blocks ..................................................................................... 28
Figure 6 – Symmetric systems: diagram (left) and Enigma machine with four rotors
(right) ................................................................................................................................ 30
Figure 7 – Asymmetric Cryptography for Confidentiality (left) and Authentication (right)
.......................................................................................................................................... 32
Figure 8 - Authentication Performance Framework ......................................................... 46
Figure 9 – TESLA one-way chain of keys ....................................................................... 52
Figure 10 – Standard TESLA approach with a different key and chain per sender ......... 54
Figure 11 – TESLA approach with the same key for all senders ..................................... 55
Figure 12 – TESLA one-way chain with different keys from different senders .............. 57
Figure 13 – TESLA single-chain approach with a different key transmitted by each
sender. No cross-authentication........................................................................................ 57
Figure 14 – TESLA single-chain approach with connected (2,4) and non-connected (1, 3,
5) satellites ........................................................................................................................ 58
Figure 15 – Galileo E1B I/NAV subframe message structure ......................................... 60
Figure 16 – "Reserved 1" field in each I/NAV Word ...................................................... 61
Figure 17 –NMA proposal within the Galileo I/NAV message structure ........................ 62
Figure 18 – H-K-root structure and fields (see Appendix B for more details)................. 63
Figure 19 – H-K-root example in five subframes/blocks ................................................. 64
Figure 20 – H-K-root / header / number of blocks field................................................... 64
Figure 21 – MAC-K section structure (see Appendix B for more details) ...................... 65
Figure 22 – NMA Architecture ........................................................................................ 71
Figure 23 – Authenticated PVT as a function of IODnav of a given satellite during
IODnav transition ............................................................................................................. 72
Figure 24 –"Optimised" authentication transmission to authenticate IODnav from the
same subframe (eph&clock I/NAV words 1, 2, 3, 4 marked in grey) .............................. 74
Figure 25 – Schematic of the cross-authentication approach ........................................... 78
13
Figure 26 – Out of view satellites in cross-authentication ............................................... 79

Figure 27 – Key-to-MAC allocation and authentication offsetting .................................. 82
Figure 28 – (Maximum) BER of Galileo I/NAV E1-B vs C/N0, AWGN channel .......... 88
Figure 29 –AER vs C/N0 , ADKD=0 ('eph&clk', blue), 1 ('ionoBGD',red), 2 ('SF',green)
.......................................................................................................................................... 89
Figure 30 – Error rates with and without authentication for 1 satellite, 4 satellites and 4
satellites and 'ionoBGD' ................................................................................................... 90
Figure 31 – Error rates with and without authentication for 1 satellite, 4 satellites and 4
satellites and 'ionoBGD' – Zoom around 26 dBHz C/N0 (ii)............................................ 91
Figure 32 – Four-satellite AER vs BER ........................................................................... 92
Figure 33 – Probability of successfully authenticating one satellite (S) (i.e. 1 – AER)
when only the MAC & key is required (blue), and when the MAC & key & navigation is
required (red), vs. the probability of successful reception of navigation information
(black). Top: Nominal-2C Scenario; Middle: Nominal-1C Scenario; Bottom: Worst-Case
Scenario ............................................................................................................................ 97
Figure 34 – Probability of data authenticated position (PVT) vs. BER, for 4 to 9 satellites
in view, based on S without navigation reception. Top: Nominal-2C Scenario; Middle:
Nominal-1C Scenario; Bottom: Worst Case Scenario ..................................................... 99
Figure 35 – Probability of data authenticated position (PVT) vs. BER, for 4 to 9 satellites
in view, based on S including navigation reception. Top: Nominal-2C Scenario; Middle:
Nominal-1C Scenario; Bottom: Worst Case Scenario ................................................... 100
Figure 36 – Masking vs. azimuth and elevation sky plot - Urban Environment, using
GNSS Planning Online tool [60] .................................................................................... 104
Figure 37 – Satellite view, 48.8567° N, 2.3508° E, 30 GPS satellites, 1/4/2015, using
GNSS Planning Online tool [60] .................................................................................... 105
Figure 38 – Sky plot at 1/4/2015, 10:20:00, using GNSS Planning Online tool [60] .... 105
Figure 39 – Time to compute the remaining bits of a key (𝜏𝑗) compared to the time
between unpredictable symbols (𝜏𝐵𝑈𝑆) ........................................................................ 111
Figure 40 – Galileo I/NAV convolutional encoding [12]............................................... 112
Figure 41 – Probability of error in the estimation of an unpredictable symbol wrt.
Integration time (M*Ts), for different C/(N0 + I0) values ............................................. 117
Figure 42 – Minimum Gain Reduction when spoofed (Maximum spoofed vs non-spoofed
gain), vs. Integration Time (M*Ts) ................................................................................ 119
Figure 43 – Satellite range rate variation over time ....................................................... 130
14
Figure 44 – Satellite-to-receiver acceleration estimated as range-rate variation over time
........................................................................................................................................ 131
Figure 45 – Range rate (i.e. the sign-reversed Doppler shift), and relative acceleration
over a satellite pass. Relative acceleration can be approximated by a constant ............. 131
Figure 46 – Logic flow diagram of the "cold snapshot" algorithm ................................ 135
Figure 47 – "Cold snapshot" algorithm run for different periods .................................. 138
Figure 48 - Low-residual GPS orbital repeatability – 12-hour effect ............................ 139
Figure 49 – "Cold snapshot" algorithm run for different periods with different GNSS to
avoid low-residual wrong solutions due to satellite orbital repetition ........................... 139
Figure 50 – Pseudorange solution residual computation to determine the right "cold
snapshot" solution........................................................................................................... 140
Figure 51 – Logic flow diagram of the "cold snapshot" algorithm combined with coarse
time navigation ............................................................................................................... 141
Figure 52 –Receiver-server implementation of "cold snapshot" .................................... 142
Figure 53 – Block diagram of Code phase parallel acquisition [13] .............................. 145
Figure 54 - Quadratic Peak Interpolation - Sample '1' corresponds to the peak. Sampling
Frequency = 16.368e6. GPS PRN 2 in ID6 data capture, first snapshot. ....................... 146
Figure 55 - Instantaneous Doppler Positioning for scenario ID2 (DGC). Instantaneous
Doppler solutions are calculated once every minute. Top-left: Doppler measurement
residuals vector module. Top-right: Position error. Bottom left: Estimated frequency
drift. Bottom right: Estimated position height. ............................................................... 148
Figure 56 – Left: Position errors of 20 10-ms snapshots. Right: Horizontal "cold
snapshot" results - Scenario ID2 - Danish GPS Centre, Aalborg. 2DRMS means RMS in
2 Dimensions (horizontal RMS)..................................................................................... 150
snapshot" results - Scenario ID6 - UAB, Barcelona. ..................................................... 151
snapshot" results - Scenario ID3 – CTAE, Barcelona .................................................... 151
snapshot" results - Scenario ID5 – Gallecs, Barcelona. 2DRMS error means RMS error in
two horizontal dimensions.............................................................................................. 152
Figure 60 – Operational, Partly Operational and Spare Satellites, Apr. 2015 - source:
Spacebook. ...................................................................................................................... 155
15
Figure 61 – Maximum accuracy achievable (standard deviation) according to Cramér-

Rao Lower Bound for different signal to noise density ratios and chip frequencies. 1-
milisecond integration time ............................................................................................ 162
Figure 62 – User receiver signal snapshot – Asynchronous case ................................... 164
Figure 63 – User receiver signal snapshot – Synchronous case ..................................... 165
Figure 64 - Satellite signal snapshot reception by a ground monitor network ............... 166
Figure 65 – Example of satellite signal time of arrival at different monitor stations (m1,
m5) .................................................................................................................................. 168
Figure 66 – Example of sliding window for snapshot acquisition. Highest correlation at
w5.................................................................................................................................... 169
Figure 67 – Diagram showing the information available to the user: position(t0),
velocity(t0), bias(t0), frequency drift and signal sequence to correlate from at least four
satellites .......................................................................................................................... 172
Figure 68 – Snapshot satellite positioning – Satellite and Ground monitor positions
(Google Earth) ................................................................................................................ 174
Figure 69 - Monitor snapshot generation: signal samples for one signal at 6 monitor
stations. C/N0 = 70 dBHz. Fs = 16.7439 MHz .............................................................. 177
Figure 70 – Satellite position 3D error [m] and RMS-3D. ............................................. 179
Figure 71 – Satellite position 3D error [m] in XYZ coordinates.................................... 179
Figure 72 – Snapshot ground segment, including 6 stations and a test user. ................. 181
Figure 73 – Ground segment, space segment, and user segment ................................... 183
Figure 74 – User horizontal (2D) and 3D position error and RMS error ....................... 186
Figure 75 – User horizontal position error (X=East; Y=North) ..................................... 186
Figure 76 – DSM field options ....................................................................................... 213
Figure 77 - User terminal, time reference and spoofer .................................................. 230
Figure 78 - Reduction of solution space with height estimation ................................... 231
16
Chapter 1. Introduction
As our lives become more dependent on satellite navigation, the threats to GPS and its
signals become potentially more harmful. GNSS (Global Navigation Satellite System)
signals are weak and can be easily jammed and spoofed. To increase resilience of GNSS,
some research over the last years has studied concepts to both authenticate the GNSS
data and signals, and to increase PNT (Position, Navigation and Timing) resilience by
using other technologies. Within this area of research, this thesis focuses on NMA
(Navigation Message Authentication), and analyses its implementation for Galileo, the
European GNSS. The first part of this thesis devoted to this topic.
Thanks to the progress in the semiconductor industry, more and more functions of GNSS
receivers can be written in software and performed by a general CPU in real time. This
includes the computation of a position from a digital snapshot of data, without the need
to track the signals and decode their data. This thesis proposes an algorithm to improve
snapshot positioning allowing a position solution to be computed without any
information about when or where the snapshot was captured. It also generalizes snapshot
positioning to its application to signals from satellites other than GNSS. This is the
subject of the second part of the thesis. At the end of the thesis, an annex is devoted to
snapshot authentication, that is, the combination of the two areas.
1.1. Scientific Challenges and Main Contributions

This section presents the principal thesis contributions and the problems they intend to
solve.
The first challenge in the authentication area has been to define a framework with the key
performance indicators for designing and comparing authentication solutions. This thesis
proposes a simple yet useful performance framework for this purpose. The main
scientific and engineering challenge in the authentication area has been the design of an
NMA solution that is robust and highly available. For this, novel concepts such as the
authentication through one key for all satellites based on the TESLA (Timed Efficient
Stream Loss-Tolerant Authentication) protocol; TESLA authentication through one chain
17
and different keys for all satellites; or cross-authentication, are proposed. Based on the
above concepts, the thesis proposes a cryptographically robust solution requiring less
than 200 bits for authenticating four satellites, which facilitates authentication even in
difficult environments compared to standard digital signatures, which would require
around 2000 bits for a similar security level. An average Time Between Authentications
(TBA) of 5 seconds at user level, at 20 authentication bits per second, can be achieved.
This reduces receiver coasting time and improves NMA robustness.
The work for this thesis has also led to the first end-to-end bit-level public proposal of an
open NMA service in a GNSS, particularised for the Galileo I/NAV message “Reserved
1” field, with all data fields required for a potential operational implementation,
including operational modes, key management fields, user notification flags, on-the-fly
configuration parameters, etc. The solution allows on-the-fly modification of the sizes
and functions of chains, keys, MACs and digital signatures, allowing to maintain security
through a long operational lifetime.
Understanding the protection against replay attacks that an NMA solution offers is also a
challenge tackled in the GNSS authentication literature and partly in this thesis. This
thesis characterises the replay detection capabilities of NMA in a receiver based on signal
processing of the first samples of unpredictable symbols.
The main scientific contribution of the snapshot research area is a novel snapshot
navigation method (named "cold snapshot" in the thesis) to calculate a position and
timing solution of a snapshot without any initial conditions. This method allows
calculating positions based on snapshots unrelated to any position or time reference. It
allows time uncertainties of several days or weeks to be resolved instantaneously,
without any position reference, and without accuracy degradation. The thesis presents an
algebraic description of the algorithm and validates its performance with real data.
The second principal contribution in the snapshot domain is the definition of a method to
generalise snapshot positioning for non-GNSS satellites. Through this method, receivers
could ideally use all satellites in view (not only GNSS) for an instantaneous position
solution. An end-to-end simulator has been developed to prove the concept and assess its
performance.
Out of the above, the contributions of the thesis considered as the most significant are:
18
 The “cold snapshot” algorithm (section 4.3).
 A generalisation of snapshot positioning (section 5.4).
 One-key and one-chain TESLA approaches including cross-authentication
(sections 3.5.2 to 3.5.4).
 An exhaustive analysis of an NMA implementation proposal in a GNSS (sections
3.6 to 3.10).
The work of this thesis has led to the following publications and patent applications:
 I. Fernández Hernández, “GNSS authentication: design parameters and service

concepts”, European Navigation Conference 2014, Rotterdam, April 2014, n.150.
 I. Fernández Hernández, V. Rijmen, G. Seco-Granados, J. Simón, I. Rodríguez,
D. Calle, “Design Drivers, Solutions and Robustness Assessment of Navigation
Message Authentication for the Galileo Open Service”, Proceedings of ION
GNSS+ 2014, Tampa, Florida, September 2014
 I. Fernández Hernández, V. Rijmen, G. Seco-Granados, J. Simón, I. Rodríguez,
D. Calle, “A Navigation Message Authentication Proposal for the Galileo Open
Service”, Journal of the Institute of Navigation. Currently under review.
 EP13175821, Digitally signed satellite radio-navigation signals, Ignacio
Fernández Hernández, The European Union, represented by The European
Commission. –related to a specific implementation for the Galileo system-
 EP14163902, Method and system to optimise the authentication of
radionavigation signals, Ignacio Fernández Hernández, The European Union,
represented by The European Commission. –related to a specific implementation
for the Galileo system-
 GB1412351.7, Method and apparatus for instantaneous positioning and timing
without initial information, Ignacio Fernández Hernández, Kai Borre.
The results presented in this thesis are reproducible. The work in this thesis includes the
following software developments:
 A Matlab snapshot GPS L1 C/A receiver (section 4.5).

 A Matlab end-to-end snapshot signal and system simulator, including space,
ground and user segments (sections 5.5 and 5.6).
 A set of Matlab scripts to analyse NMA performance (section 3.9).
19
1.2. Thesis Outline

Chapter One presents the general introduction to the thesis and the main contributions.
Chapter Two presents a general technical introduction to the main subjects of the thesis,
by providing a general overview of satellite navigation systems and receivers, and an
introduction to cryptography.
Chapter Three presents the work on GNSS navigation message authentication.
Chapter Four presents the work on snapshot positioning techniques without initial
conditions.
Chapter Five presents the generalisation of snapshot positioning to non-GNSS satellites.
Chapters Three to Five compose the core of the thesis. To improve readability, each of
these chapters follows the same structure: First, it presents the motivation of the work,
including the statement of the problem to solve. Then, the chapter presents some
background on the research subject, including the related work in the state-of-the-art and
the identification of the gaps the thesis is trying to address. The following sections of the
chapter present the actual work performed, starting with the hypotheses and theoretical
frameworks used, followed by the theoretical analyses and experimental results with real
or simulated data, when pertinent. Each chapter is finalised with the conclusions.
Chapter Six presents the overall conclusions of the thesis and proposes some further
work.
Some appendices complement the thesis. Appendix A presents the GNSS authentication
user needs and high level requirements analysis. Appendix B details a bit-level
description of the NMA end-to-end proposal. Appendix C presents the analysis of NMA
MAC and key sizes versus bandwidth allocation. As an epilogue of the thesis, Appendix
D merges the two main research areas and presents some snapshot authentication
methods.
20
Chapter 2. General Technical
Background
2.1. A Brief History of Navigation
Navigation is the science allowing us to go from point A to point B. Satellite navigation
means navigating using satellites, and we mainly refer here to artificial satellites. Many
satellite navigation applications relate to satellite-based positioning only, that is, the
determination of point A. This thesis refers to satellite navigation in a broad sense,
including satellite-based positioning. A comprehensive history of navigation since the
ancient history until the start of GPS is presented in [1]. [2] (Chapter 1) presents a
general overview of radionavigation systems, and [3] (Chapter 1) present the GPS
program in its early days.
Much before humankind could overcome the Earth's gravitational well and put satellites
in orbit, navigators used other means. First, they had to locate points A and B in a map.
The Greeks already new that the Earth was spherical and drew maps of the known world
at the time with a remarkable accuracy, as the Ptolomean map of the world known in the
Hellenistic era in the II century A.D. The estimation of the Earth's radius by Erathostenes
around two centuries B.C. was another substantial achievement. He measured the
distance, in camel-days, from two points, and calculated the Earth radius by comparing
the inclination of the sun at these two points at noon, being the sun at the zenith for one
of them.
After the middle ages, Renaissance arrived allowing significant progress in navigation.
Men navigated using celestial bodies in a not-so-different way as modern angle-of-arrival
radionavigation techniques. During the day, navigators measured the Sun's elevation
angle from the horizon at its highest point, and estimated their latitude from tables, or
almanacs, relating the Sun's elevation to a given latitude at different days of the year. At
night, navigators in the Northern hemisphere could measure the elevation of the Pole
Star, knowing that it is pointing to the north, and its elevation angle corresponds to the
21
observer's latitude. Navigators could get some help from tables with the positions or
celestial bodies, or ephemerides.
In parallel, scientists like Copernicus, Galileo, Kepler and Newton set the basis for
modern astronomy and geodesy: Copernicus reformulated the model of the universe, in
which the Sun, and not the Earth, was at its centre, contradicting classical Ptolemaic
geocentric astronomy. Galileo developed the modern scientific method based on
observation of nature and put it in practice by, among others, improving the telescope,
which allowed the detailed observation of planetary motion. Thanks to that, Kepler
discovered the three planetary movement's laws, which Newton later generalised to the
single law of universal gravitation.
While latitude was relatively easy to determine, it took several centuries to compute
longitude with a reasonable accuracy to navigate. This goal was not achieved until the
1770s when John Harrison set the basis of modern timekeeping with sea watches H4 and
H5, shown in Figure 1. H5 proved accurate to within one second in three days (or 3.8
ppm). This allowed the comparison of observations of the celestial sphere at different
positions at the very same time, and hence the longitude.
Figure 1 – John Harrison's portable Chronometer H51
Navigation based on celestial objects, increasingly accurate compasses, and dead

reckoning systems was dominant until radio frequency waves arrived. Early
radionavigation systems in the XXth century measured the direction/angle of radio waves
and the Doppler effect. Following the developments of information theory, electronics
1
Racklever under CC2.5
22
and computing engineering in the first half of the XXth century, several radionavigation
terrestrial systems were developed, as OMEGA, LORAN, VOR (VHF Omni-directional
Radio Range) or DMEs (Distance Measuring Equipment), some of which are in use
today. The first satellite systems developed specifically for radionavigation were:
 TRANSIT, a Doppler rate-based radionavigation system developed by the US

Navy and operational from the early 1960's composed by 5 or more satellites in a
low polar orbit, and which required about one hour to provide a position fix. It
included several frequencies to correct for different ionospheric delays.
TSIKADA was a similar system developed by Russia.
 621B and TIMATION were satellite systems developed by the US Air Force and
the US Navy, respectively, which tested on space some key technologies for
satellite navigation: highly accurate clocks (TIMATION) for synchronisation, and
pseudo-random codes (621B), for better resistance to interference and higher
accuracy synchronisation accuracy.
The US Air Force incorporated elements from these systems and developed a system
based on a global constellation of nominally 24 satellites with accurate on-board clocks,
spread-spectrum signals with pseudorandom codes and multiple carrier frequencies. They
called it the NAVSTAR Global Positioning System, or GPS.
Other regions have followed the U.S. in developing their own global navigation satellite
system, or GNSS: Russia has developed GLONASS, currently operational, China is
developing Beidou, and Europe is developing Galileo. This global effort is
complemented by other regional systems as India's IRNSS or Japan's QZSS, and
augmentation systems mainly (but not only) for aviation use, as WAAS (U.S.), EGNOS
(Europe), MSAS (Japan), or SDCM (Russia), all included in the category of SBAS
(Satellite Based Augmentation Systems).
Current ground-based navigation systems and technologies include GBAS (Ground

Based Augmentation Systems), VOR/DME/TACAN, or e-Loran. The U.S. is also
developing a program called APNT (Alternative Position, Navigation and Timing) to
increase resilience of radionavigation.
23
2.2. Radionavigation Methods

There are several methods to compute a position based on radio waves. They are briefly
explained here:
 Time Of Arrival (TOA) implies computing the travel time of a signal from a
transmitter at a known position, and the distance, assuming that the signal travels
at the speed of light. Performing these measurements for signals from several
transmitters, whose position at the time of transmission is known, allows solving
all the user position unknowns. These unknowns usually include the receiver
clock bias, which is common to all measurements.
 Time Difference Of Arrival (TDOA) implies computing the receiver position by
calculating the time interval between the arrivals of two signals transmitted at the
same time from two stations. One of the stations is used as a reference for the
other stations. Each TDOA equation of the system can be represented by a
hyperbola, and TDOA is also known as hyperbolic positioning.
 Angle Of Arrival (AOA) implies measuring the angle in which a signal arrives
(usually with several antennas). AOA is described in detail in [4] (Ch. 8).
 Doppler-rate positioning (or Doppler positioning) consists of measuring the
signal frequency variation due to the relative speed of the transmitter and the
receiver. Doppler-rate positioning principles are explained in [2] (Ch. 1).
 Instantaneous Doppler positioning consists of measuring the signal frequency
Doppler and comparing them with the Doppler estimate at a given time, for
several signals. The receiver may need to add an extra measurement to solve the
frequency drift unknown. This method is explained in detail in [5] (Ch. 8).
 Receiver Signal Strength (RSS) positioning is based on matching a position to a
previously measured map of positions to signal-strength values.
TDOA and AOA methods are commonly used for mobile localisation. TOA is used for
GNSS. Doppler-rate positioning was used for TRANSIT and TSIKADA, and
instantaneous Doppler positioning can be used for Assisted GPS to estimate an initial
position, later corrected by TOA methods. RSS is commonly used for short-range
location systems as Wi-Fi, and usually in indoor environments.
Radionavigation is usually combined with other location sources and sensors as INS
(Inertial Navigation Systems) carrying accelerometers and gyroscopes, including MEMS
24
(Micro-Electro-Mechanical Systems) embedded currently in smartphones, odometers,
compasses, or GIS (Geographic Information Systems). Modern location services used in
mobile phones generally use a combination of the available methods, including
GPS/GNSS and other signals.
Figure 2 –LEO, MEO and GEO satellite orbital radiuses, periods and speeds2
2.2.1. Satellite Navigation Systems and Signals
Satellite navigation signals and constellations have some common features that make
them suitable for navigation. They use Medium Earth Orbit (MEO) satellites, which are
supposed to provide the best coverage and performance versus the cost of placing the
satellite constellation into orbit (see Chapter 1 of [6] for more details about GNSS and in
particular Walker constellations). Lower altitude constellations would require more
satellites to cover the globe, and higher altitude constellations would require more power
in the satellites to transmit the same power on ground, and a higher cost to put the
satellites in orbit. GNSS use almost circular medium earth orbits of around 20.000-
25.000 Km above Earth surface, with between 3 to 6 nominal orbital planes, for a total of
around 24-30 satellites. This seems to be an optimal combination to provide enough
coverage of at least four satellites (to solve for a 3-D position plus clock bias) worldwide.
Figure 2 shows the orbits of GPS, GLONASS, Galileo and Beidou (COMPASS) together
2
Cmglee under CC BY-SA 3.0
25
with the orbits of other LEO (Low Earth Orbit) and GEO (Geostationary Earth Orbit)
satellites.
Navigation satellites have ultra-stable atomic clocks. This allows them to provide ranging
signals very well synchronised to a common time reference. It also allows the ground
segment to better estimate satellite clock offsets and tell the users through the navigation
signal.
Thanks to using several constellations, receivers can see nowadays many more than four
satellites in view, if they have a multi-GNSS receiver, even in environments with reduced
visibility. Figure 3 shows the number of GNSS satellites visible in Aalborg on June 23rd
2015, 12:00 CET.
Figure 3 – Satellites in view foreseen at Aalborg, 23/6/2015, 12:00 (CET)3
Navigation satellite signals use spread spectrum techniques; thus, the signals become
more resilient to CW (Continuous Waveform) interference. The spread spectrum
technique broadens the bandwidth of the signal, making the ranging signals also more
accurate [7]. They also use CDMA (Code Division Multiple Access) techniques to
access the media, except for the case of some GLONASS FDMA (Frequency Division
Multiple Access) signals. Signals are mainly transmitted in the L band between around
1150 MHz and 1610 MHz. They are transmitted in several frequencies: in addition to
offering more services and data, this allows users to correct the ionospheric propagation
delays. When received on Earth, the signals are below the noise level: signal power is
around -125 to -130 dBm, while noise power is around −110 dBm. The receivers need to
3
GNSS Planning Online [6]
26
correlate the signals with the spreading code replica to increase their power sufficiently
to extract the signal information.
The most popular signal modulations in GNSS are BPSK (Binary Phase Shift Keying)
and BOC (Binary Offset Carrier) [8]. Figure 4 [9] shows all satellite signal modulations.
More details on GNSS signal modulations are provided in [10]. A detailed signal
specification of GPS and Galileo can be found in [11] and [12], respectively.
Figure 4 – GNSS signals
27
2.2.2. Satellite Navigation Receivers
Satellite navigation receivers are mainly composed of:
 An antenna, in charge of transforming the radiated electromagnetic signals into a

voltage. Sometimes the antenna is considered a separate part from the receiver.
 A Front-End (FE), in charge of synthesizing and down-converting the signals
(generally received at a too high frequency to be optimally treated) and digitizing
them into a binary bit stream.
 A "baseband processing" component, in which the digital signals are treated to
extract the relevant reference parameters: time of arrival (code phase), carrier
phase, frequency and data. Usual baseband processing engines are composed of:
o An acquisition engine, in charge of searching for the signals at different
code delays and frequencies.
o A tracking engine, in charge of tracking the signals through delay locked
loops and frequency and/or phase locked loops.
 An application processing block, in charge of generating a PVT (Position,
Velocity and Time) solution, allowing receiver positioning and navigation.
Figure 5 presents the main receiver building blocks. An extensive description of classic
receiver architectures can be found in Ch. 8 of [3] (Vol. 1). A detailed description of a
GPS/Galileo receiver, including Matlab code, is found in [13].
Figure 5 – GNSS receiver blocks
Most modern receivers can be aided by an assistance channel. This allows improving
Time To First Fix (TTFF) and increasing sensitivity by searching for the signals more
quickly and dwelling for a longer time at a given delay-frequency bin during acquisition,
receiving more signal energy. More details about Assisted GNSS (A-GNSS) and
Assisted GPS (A-GPS) can be found in [5]. Snapshot architectures, further presented in
chapters 4 and 5 of this thesis, do not consider the tracking engine and calculate a
position based only on the acquisition block.
28
2.3. A Brief History of Cryptography
Cryptography is the science of designing cypher systems. A cypher system protects
confidential information from being read by unauthorised people. We call this
confidentiality. Cryptography has also other uses, which are data integrity,
authentication, and non-repudiation:
 Data integrity ensures that the information received is the same as that sent by the
sender.
 Authentication ensures that the source of the information is authentic, that is, the
sender is who is supposed to be. This is normally referred to data origin
authentication. Authentication also refers to ensuring that an entity is who says he
is. In other words, it ensures that information is coming from someone, and
corroborates that this someone is who says he is.
 Non-repudiation prevents that an originator of information denies being the
source of that information.
Confidentiality is normally achieved through encryption, i.e. cyphering the message, or

plaintext, with a secret key shared between the sender and the receiver. Encryption does
not guarantee authentication, as any unauthorised person can send a message to the
receiver. When the receiver decrypts the message, it may realise it makes no sense, but it
cannot confirm its origin.
Cryptography is complemented by cryptanalysis, which is the process of deciphering

encrypted messages without having the key. Cryptology is considered as the ensemble of
cryptography and cryptanalysis. Basic definitions and notions of cryptography can be
found in [14]. Engineering guidelines for the design or cypher systems can be found in
[15]. [16] provides a very good introduction to cryptography, including many examples
through history.
There are records that prove that cryptography has been used since the ancient times by
most civilisations, mainly by governments and military, but also for private users who
dealt with confidential information. Here are some examples of popular documented
cyphers used throughout history [14]:
 The Caesar cypher, used by the Julius Caesar's Roman Empire. It consisted of
replacing the alphabet letters by those X places ahead in the alphabet. For
29
example, if X equals 3, A would be replaced by D, B by E, etc. This is a

particularisation of substitution cyphers, where, each letter is replaced by another
one following a given table. A vulnerability of this cypher (among many others)
is that, if the cyphered text is long enough, an attacker can perform statistics on
the frequencies of the letters, and guess the conversion table.
 To protect against frequency analysis, the Vigenère cypher, published in the
XVIth century, performed different shifts in the letters, according to a given word
or text. For example, if the word 'men' is used, the first letter of the plaintext, or
text to be encoded, would shift 12 places (for 'm'), the second one would shift 4
places (for 'e'), the third 13 places (for 'n'), the fourth 12 places, and so on.
 The Enigma cypher system (Figure 6, right), used to encrypt and decrypt radio
communications of the German army during World War II. Enigma machines
used three or four interconnected wheels, or rotors, with the alphabet letters
scrambled, and a plug-board to swap pairs of letters. To make the cypher more
robust, the scrambles turned every time a letter was encoded [16].
Figure 6 – Symmetric systems: diagram (left4) and Enigma machine with four rotors (right)
The above cyphers are similar in the following ways:
 They require a key: in the Caesar case, the key is the number of places 'X'. In the
case of the Vigenere example, the key would be the word 'men'. In case of the
Enigma, the key would be the position of the wheels and the letter swaps. Both
the sender and the receiver need to know the key to communicate.
4
Source: Microsoft.
30
 The key is secret: Once the key is compromised, the whole system is
compromised, until a new key is used.
Cyphers using shared secret keys are called symmetric, and generally require a strong
effort in key management (generation, distribution, storage, use, change, destruction).
For example, during World War II, each day the Germans placed the wheels and swaps
in different positions (i.e. changed the key). Finding the key of one day would not help
deciphering the messages of the next day. Figure 6 shows a diagram of symmetric
systems.
2.3.1. Modern Cryptography and Asymmetric Algorithms
Modern cryptography has been intimately related to the development of computers, since
the breaking of the Enigma keys in World War II to our days. Modern symmetric cyphers
usually digitalise the plaintext and XOR it with an also digital keystream sequence
generated from the secret key. A key of n bits can easily produce a keystream of (2n-1)
bits [14].
The plaintext can be XORed with the keystream sequence bit by bit, as is the case of
stream cyphers, or in blocks of some bits, as in the case of block cyphers. The most
widespread symmetric cypher used nowadays is the AES (Advanced Encryption
Standard), proposed by NIST (National Institute of Standards and Technology) in 2001.
NIST adopted the algorithm Rijndael, designed by J. Daemen and V. Rijmen [17]. It is a
block cypher that encrypts the plaintext in blocks using keys of 128, 192 or 256 bits. It
replaced the DES (Data Encryption Standard), published in 1976.
Cryptographic security of cypher systems is commonly measured in security bits. For

example, a system of a 128-bit security level implies that there are 2128 possibilities for
the key, so an attacker would need to try for a long time before having a minimal
probability of success. Well-designed symmetric systems using keys of 128 bits provide
a 128-bit security level. Currently, 128 bits of security are considered sufficient for
cyphers to be secure for the next decades.
One of the problems of symmetric cryptography is that it requires the sender and the
receiver to share a secret key. To avoid this problem, asymmetric cryptography was
developed and perfected since the 70s to our days [16]. Asymmetric cryptography is
31
based on key pairs where one key is public, and the other is private. This can facilitate
information exchange in the following way:
 For confidentiality: if Alice wants to transmit a confidential message to Bob, it

uses Bob's public key to encrypt the message. Only Bob, who has the private key,
can decrypt the message.
 For authentication: if Alice wants to ensure the authenticity of the message, it
adds a digital signature to its plaintext with its own private key. Bob can use
Alice's public key to ensure that the message comes from Alice, as only she has
the private key.
Figure 7 – Asymmetric Cryptography for Confidentiality (left) and Authentication (right)5
The first publication on asymmetric systems was made in 1976 by W. Diffie and
Helleman [18], although the problem was similarly solved by the British Government
Communication Head Quarters (GCHQ), but its solution remained secret [16]. Since
then, several asymmetric algorithms as RSA (Rivest, Shamir and Adleman), DSA
(Digital Signature Algorithm) or ECDSA (Elliptic Curve Digital Signature Algorithm)
have been developed. Figure 7 shows diagrams of how asymmetric cryptography is used
for confidentiality and authentication.
Asymmetric algorithms are generally based on one-way functions, i.e. functions that are
very easy to perform in one way, but almost computationally impossible in the inverse
way. For example, the difficulty of factoring two prime numbers p and q of a number n
made public in the case of RSA, or the difficulty of calculating the inverse of a discrete
5
Source: Microsoft.
32
logarithm over integer numbers in case of DSA. More details about these and many other
cryptographic functions can be found in [19].
2.3.2. GNSS and Cryptography
GNSS are one-way, one-to-many systems. This means that GNSS authentication cannot
use challenge-response protocols through a secured two-way communication is
established as, for example, when we authenticate ourselves with a token to enter into our
bank's secure website to make a transaction. GNSS can however encrypt their signals
through symmetric cryptography and digitally sign them through asymmetric
cryptography. Here is how the abovementioned four uses of cryptography
(confidentiality, integrity, authentication, and non-repudiation), relate to GNSS.
2.3.2.1 Confidentiality
Cyphers have been intimately related to satellite navigation since its inception, but
mainly for military purposes. The widespread GPS C/A 1-millisecond spreading codes
were transmitted in-the-clear (i.e. unencrypted) to allow military users to perform a fast
signal acquisition and time synchronisation, before switching to 7-week portion of a
much longer Y code, encrypted before transmission, and once encrypted known as P(Y)
code.
Other governmental signals as Galileo's PRS (Public Regulated Service) or GLONASS

or Beidou military signals are also encrypted. Galileo transmits also the CS signals that
can be encrypted for civil purposes.
One purpose of signal encryption is access control, i.e. confidentiality. Some years ago,
the GPS applied an intentional degradation to the open signals called Selective
Availability, and only receivers having the secret keys could access the more accurate
signals. In addition, in crisis situations, jamming the open signals can deny navigation
services to users not having the secret keys.
Another property of GNSS signals to avoid eavesdropping is that, as said before, they are
received at a very low power on earth. In order to decode the data modulated in the
signals, and due to the DSSS technique in which GNSS signals are modulated, the
receiver needs to have the pseudo random code replicas to correlate the signal. In the
absence of the codes, the signals cannot be acquired. Therefore, only the users having the
spreading codes (or a high gain directive antenna, which is cumbersome and expensive)
33
can de-spread the signal and raise it above the noise level and get the reference
parameters from the satellites (time of arrival, frequency, phase and data). This implies
some sort of steganographic protection, similar to writing in 'invisible ink'.
2.3.2.2 Data Integrity
While cyphers can guarantee data integrity, the integrity of the data transmitted by GNSS
systems is guaranteed by the data encoding, and usually by a CRC.
2.3.2.3 Authentication
Authentication is generally provided through Message Authentication Codes (MACs) or

digital signatures. MACs rely on symmetric schemes and are based on generating a tag
that depends on the message to protect and the secret key. The receiver then re-generates
the MAC with the received message and its own key, and both should coincide. Digital
signatures are based on public-private key schemes, as explained before.
In the case of GNSS, authentication is needed to protect users against malicious attacks
whereby spoofers falsify GNSS signals making them believe they are somewhere else. It
is also necessary to avoid self-spoofing of malicious users reporting a falsified position.
GNSS signal authentication can relate to the two main components of the signal: the
spreading codes and the data.
If spreading codes are encrypted (as in the P(Y) case), only users having the key can
acquire the signals. Therefore, signal encryption in this case provides some level of
authentication. This was also one of the uses of the encrypted codes by the GPS P(Y)
military users. Receivers contained a SAASM (Selective Availability and Anti Spoofing
Module) to authenticate the codes, and therefore the time of arrival, against spoofing
attacks. So, GNSS authentication, although relatively new in the civil domain, has been
used in the military domain since the beginning of GPS.
Signal encryption per se does not provide authentication though. For example, an
attacker would have difficulties to modify the data modulated over encrypted spreading
codes, but this does not mean that the attack is impossible. Some methods in the GNSS
literature, as [20] [21], have been proposed to authenticate spreading codes for public
users. They are based on the insertion of some cryptographic information that can be
34
verified but does not prevent receiving most of the spreading code, and therefore
acquiring and tracking the signal.
GNSS authentication requires also the authentication of the data. This is often called
Navigation Message authentication, or NMA [22]. Authentication of the data for public
non-controlled user communities can be performed by digital signatures [23], so
receivers can authenticate the data just by having a public key. Authentication can also
follow hybrid (symmetric/asymmetric) approaches relying on time-delayed asymmetry,
as is the case in this thesis.
2.3.2.4 Non-repudiation
Non-repudiation seems not useful for GNSS if interpreted as avoiding that a satellite or
system denies being the source of the signals, as this is not expected to happen. It can be
however useful for avoiding that a user denies he was at a given place at a given time.
This use may be relevant for GNSS location applications with financial or legal
implications, as e.g. road tolling.
35
Chapter 3. Navigation Message

Authentication
3.1. Motivation
Over the last decade, the increasing dependence of civil applications on GPS has raised
concerns over GPS security [24]. Gradually, some demand for authentication services has
arisen in the location community. Due to the high demand to strengthen GNSS civil
signals for consumer or mass market users, the GNSS research community is studying
how positioning authentication could be implemented based on GNSS signals and other
sensors. The work presented in this chapter is the partly result of an internal action within
the Galileo program whose purpose was to study how Galileo could authenticate its
signals with minimal modifications to the system baseline, and before its Full
Operational Capability. The Galileo signal design and message structure is adequate for
introducing authentication, as it allows higher bitrates compared to other GNSS [12, 11].
In addition, due to the Galileo safety-of-life service 're-profiling', a significant amount of
bandwidth has been liberated for future uses.
Previous literature suggests that, when complemented with additional checks at the
receiver, NMA can provide a reasonable level of protection not only of the satellite data
but also against replay attacks [25, 23]. In any case, as the Galileo service offering
includes spreading-code encrypted civil signals in the E6-B/C as part of the Commercial
Service [26], an NMA service could be combined with these signals for users that rely on
encrypted spreading codes, as described in [27]. The proposed NMA scheme could also
be upgraded to spreading code techniques, such as [20] or [28], in future Galileo
generations. . In parallel to the analysis of this proposal, the Galileo program has carried
out other authentication testing activities, some of which have included some signal-in-
space testing in the Galileo E6 band. They are reported in [27] and [29].
As described in the literature, NMA required four digital signatures, or for MAC-key
pairs, for a 4-satellite data-authenticated PVT. This implies receiving many additional
36
bits from each satellite. The main scientific and engineering challenge of this research
area has consisted in designing and characterizing a service that decreases the amount of
bits required and can work for all kinds of users, while being robust against
cryptographic and signal attacks. The work in this thesis proposes an authentication
solution for Galileo E1B I/NAV message implementable for the Galileo first generation.
The solution can provide data authentication and anti-replay protection based on the
authentication of unpredictable symbols.
One of the main drivers for the authentication solution proposed in this thesis is the
minimisation of modifications of the Galileo infrastructure with respect to the current
baseline (based on the available documentation). For this reason, the authentication
solution proposed is based on NMA as opposed to the authentication or encryption of the
signal spreading codes. For this reason also, it is based on the "Reserved 1" field of the
I/NAV message and relies only on satellites connected in real time to the ground
segment. Other authentication solutions not subject to these constraints and based on
modifications to the satellite and ground segments may yield even better performance.
The sections in this chapter present first some background on information security and
GNSS authentication. Then, the user needs, or high level requirements used for the NMA
design are presented. The following section presents a performance framework to
characterise NMA (and GNSS authentication in general). Then, the concept proposed is
presented, followed by a detailed implementation proposal for Galileo I/NAV and the
experimentation results.
3.2. Background
To understand the purpose of the authentication solutions proposed later, it is important
to explain what we are trying to protect, and against what. This section presents some
background on information security systems, security risk assessments and presents some
threats and mitigation actions to GNSS positioning, NMA being one of them.
3.2.1. Information Security Management Systems (ISMS)
Security cannot be guaranteed by cryptography only. It depends on the security of the

whole system. The background used for protecting systems providing any information
(like GNSS, or GNSS receivers) is based on ISMS standards and policies. ISMS provide
a generic framework to analyse and manage the security of information, including how to
control information and react in case of threats. ISMS deal with cryptography and other
37
broader security aspects as physical security, communications, operations,

procurement/acquisition, operations or human resource management. Most ISMS
identify confidentiality, integrity and availability as the critical factors:
 Confidentiality is understood as the protection of the information from

unauthorized parties (similarly to the previous definition in Chapter 2).
 Integrity is understood as the protection of information from modification by
unauthorized users (also similarly to the previous definition).
 Availability is understood as making the information available to authorized
users.
Cybersecurity, or IT security, refers to information security for computers and computer

networks. Cybersecurity is fully applicable to a GNSS receiver, being it a computer
providing information based on some RF hardware.
3.2.2. Standards
The ISO/IEC 27000 series from ISO (International Standards Organisation) and IEC
(International Electrotechnical Commission) on security of information systems [30] are
now the main international security standards. Current ISMS standards are derived from
BSI (British Standards Institution) BS 7799, published in the 90's, which established best
practices for Information Securities. This was later incorporated in to ISO standards, that
in the 2000s became part of the ISO 27k series, which merged information security
management practices with other ISO generic standards for quality management.
The "Common Criteria for Information Technology Security Evaluation", commonly

referred as "common criteria" ISO/IEC 15408 [31], provide a framework to specify
security requirements to develop, analyse and test computer-based software. The
Common Criteria ensures that the specification, development and testing of a product has
been conducted according to a standard and in a repeatable manner according to a certain
"Protection Profile", which can be certified. The CC is not so relevant for this thesis, as
the analysed threats focus on signal aspects, as opposed to cybersecurity aspects. We
assume cybersecurity requirements for NMA implementation as similar as to other
existing IT devices so this falls outside the main scope of the thesis.
In addition to ISO standards, other organisations as U.S. NIST (National Institute for
Standards and Technology) develop standards for cybersecurity, as is the case of the AES
38
[17] and many other referred to in this thesis. Other national security standards include
EBIOS [32], the French government security standard, or CRAMM (CCTA (Central
Computing and Telecommunications Agency) Risk Analysis and Management Method)
[33].
ISO/IEC 27005, "Information technology — Security techniques — Information security

risk management" is the standard for risk management of the 27k series. The standard
follows a common definition of a risk as “a combination of the consequences that would
follow from the occurrence of an unwanted event and the likelihood of the occurrence of
the event”. The methodology is based on the following steps to identify:
 Assets at risk, and therefore to be protected.

 Threats to these assets.
 Vulnerabilities of the assets to the threats.
 Impact if the threats are materialised.
 Mitigation actions.
The methodology just provides a framework. It does not provide the knowledge of which
are the threats and the technology required for them. A very preliminary security risk
analysis of GNSS positioning, from the receiver point of view, implies to define:
 Assets: the main asset at risk is the position and time solution generated by the
receiver.
 Threats: they are presented in the next section.
 Vulnerabilities: from a receiver perspective, one could relate them to the main
receiver blocks: Antenna, RFFE (Radio Frequency Front End), ADC (Analog to
Digital Converter), signal acquisition, signal tracking (unless a snapshot approach
is followed), PVT, and communication with a third party, if applies. Other
conceptual approaches are possible. The focus of this work is on vulnerabilities at
the level of signal reception, or antenna level, i.e. how can an attacker attack what
the receiver is receiving. In a broad sense, cybersecurity attacks to the receiver
must also be considered.
 Impact can be assessed per threat and per receiver stage (vulnerability), i.e. how
each attack could affect ADC, acquisition, tracking, etc.
 Mitigation Actions: they are presented in the section 3.2.4.
39
3.2.3. GNSS Positioning Threats
Jamming, spoofing, and meaconing are in most of the GNSS literature the principal
classification of threats to GNSS signals [34] [35]. The Volpe Report [24] follows a risk
analysis similar to the abovementioned, and concludes that GPS is a critical infrastructure
subject to interference and should be backed up by other radionavigation aids. It also
recommends the application users to assess the risk of losing GPS. More concretely, as
regards the GPS threats, it classifies them in unintentional and intentional disruptions.
Recent GNSS literature also maintains the same classification [23] [25]. In particular, a
survey of spoofing attacks has been presented in [36] not long ago.
The preliminary threat model proposed here divides the attacks into signal attacks and
non-signal attacks. Signal attacks affect the reception of GNSS signals. Non-signal
attacks affect the receiver device or to the key management infrastructure. Here is a
generic definition of jamming, meaconing and spoofing signal attacks:
 Jamming refers to the transmission of an interfering signal (e.g. pulsed,

continuous) in the bands used by the GNSS signals. It cannot be counterfeited by
the signal design (other than raising the transmission power) and leads to a
service denial (i.e. no GNSS PVT), as opposed to a wrong GNSS PVT. Some
authors propose smart jamming as an intermediate attack between jamming and
spoofing [37]. Smart jamming is jamming using GNSS-like signals, for example
with GNSS PRN (Pseudo Random Number) codes, which may affect the tracking
loops leading to false (but incoherent) PVTs.
 Meaconing is generally defined as the replay of the full GNSS digital stream.
This type of attack affects any kind of GNSS signal authentication scheme, with
the limitation that it can only delay the whole signal stream, therefore falsifying
the receiver clock bias at the position of the antenna used for meaconing.
Selective meaconing attacks using directional high-gain antennas may lead to a
false position.
 Spoofing can be defined as one of these two:
 The transmission of fully simulated signals without any replication capability
of the authentic signals: this seems the easiest attack to which current open
signals as GPS L1 C/A are vulnerable. NMA fully protects from this attack.
 The reception of the actual signal and its rebroadcast with a minimal delay.
This is known in some literature [23] as a Security Code Estimation and
40
Replay (SCER) attack. NMA, can protect from these attacks but a
probabilistic analysis using hypothesis testing methods is required.
Non-signal attacks can be divided in:
 Tampering within the receiver to alter the stored bits from the demodulated
signal, the result of the authentication check, or the previously stored public keys.
 Provision of the wrong keys to the receiver by attacking the Public Key
Infrastructure (PKI).
 Alteration of the position reported by the receiver to a third party.
Taking the above into account, GNSS authentication should:
 Counterfeit any type of spoofing attacks through fully simulated signals.

 In case of a SCER attack:
o Confirm the authenticity and integrity of the data used for the authenticated
PVT.
o Confirm, up to a certain probability and under certain conditions, the
authenticity of the signal timing used to generate the time-of-arrival
measurements used for the PVT calculation.
3.2.4. Detection and Mitigation Actions
For unintentional disruption, the recommendations from [24] to GPS are to transmit at a
higher broadcast power, and to use of several civil frequencies. Against intentional
disruption, it recommends to:
 Transpose military anti-jam techniques to civil technologies;

 Develop anti-spoofing techniques in the receivers.
 Monitor the evolution of threats to take appropriate countermeasures.
In particular, the following techniques are recommended against spoofing in the

receivers:
 Amplitude Discrimination
 Time-Of-Arrival Discrimination
 Consistency of Navigation IMU Cross-Check
 Angle-Of-Arrival Discrimination
41
 Cryptographic Authentication (the main subject of this chapter).
Redundancy within measurements through RAIM (Receiver Autonomous Integrity

Monitoring) and with other non-GNSS systems is recommended. This recommendation
has been materialised in US's APNT (Alternative Positioning, Navigation and Timing)
program. Complementarily, L. Scott in [20] also proposes receiver countermeasures,
divided in those at signal level and those at navigation level. At signal level, these are
proposed:
 Use J/N (Jamming to Noise) meter to check for above normal energy levels
 C/N0 (Carrier to Noise density ratio) monitoring
 C/N0 and J/N verification
 Multi-antenna phase difference measurement.
 "deep acquisition" for weak, real signals.
At navigation level, the proposed mitigation actions are:
 Signal synchronisation ("watch time" vs "signal time" comparison).

 continuity of position and timing.
 consistency with sensors.
 residual verification (e.g. RAIM-like and FDE).
[36], [28] and [23] also propose the addition of trusted clocks as an additional protection
against spoofing attacks, and this technique is also detailed in Appendix D. Appendix D
also proposes the use of geometrical constraints or consistency with digital maps.
3.2.5. Detection and Mitigation based on GNSS Signal Properties
Currently, there are no civil authentication measures or services as such in civil GNSS
signals. However, since the Volpe report in 2001 [24], there has been public research in
the subject. We divide them in those at spreading-code level and those at data level.
Reference [20] mentions data message authentication (known as NMA in this thesis),
SCA (Spreading Code Authentication) and SCE (Spreading Code Encryption). It also
refers to Spread Spectrum Security Codes (SSSC), similar to spreading code
watermarking techniques as proposed in other references as [38]. Reference [22] coined
the term NMA and proposed several NMA techniques, including one based on TESLA,
although using different keys from different satellites and requiring about 238
42
authentication bits per satellite. It also proposes also NME (navigation message
encryption). Many publications from the research group from the University of Texas at
Austin present the results of actual spoofing attacks and GNSS and receiver
authentication methods [39] [40] [25] [41]. On NMA in particular, [23] proposes 466-bit
digital signatures over GPS CNAV message and their integration in anti-replay
protection measures, and [40] proposes a hybrid ECDSA-TESLA approach optimised for
GPS CNAV. Also, Stanford GPS laboratory group have presented an amount of solutions
for radionavigation authentication [35] [42] [43], including some TESLA-based
protocols for e-Loran authentication [44] or GBAS/SBAS [42], both studying TESLA.
The next sections provide further references to the state of the art, when adequate.
3.2.6. Summary
Here are some conclusions from the background literature review:
 Any measures for securing radionavigation services can and should be analysed
through standard Information Security Management Systems (ISMS) and Security
Risk Assessment standards. In particular, ISO 27000 series provides guidelines for all
kinds of analysis. Concerning security risk assessments, other similar methodologies
apply at national level (e.g. EBIOS or CRAMM). As regards cryptographic security,
NIST standards are one of the main references.
 Security Risk Assessments usually consist of a framework to identify the assets under
risk, the threats, the vulnerabilities, the impact and the mitigation actions.
 GNSS threats are generally divided in jamming, spoofing and meaconing.
 GNSS authentication literature presents a wealth of GNSS threat detection and
protection based on radionavigation backups, receiver measures, GNSS
authentication and policy or security management-related actions.
 No GNSS authentication (be it NMA or SCE) is fully robust against all threats.
However, they can be robust against most threats and be complemented with other
measures at the receiver or by other aids. Signal unpredictability obtained by SCE or
NMA, is beneficial to protect against replay attacks.
3.3. User Needs, High Level Requirements and Design Drivers

The design of an NMA service needs to take into account target users environments,
receiver technological constraints, robustness and performance. In addition, feasibility in
the system and backward compatibility with the current signals has been taken into
43
account as well. The user needs and high level requirements identified are summarised
in Table 1. Some background to the table is presented in Appendix A.
Table 1 – Summary of User Needs and High Level Requirements
Target Users and Receiver Constraints
The solution shall work in standalone mode
The solution shall work in assisted mode
Security-related receiver requirements shall be minimised
The solution must be E1 mono-frequency
The solution shall not require any additional hardware components than those of a
standard low-cost receiver
The solution shall be computationally feasible in a standard low-cost receiver
Robustness and Performance
The solution shall use standardised functions and protocols considered secure by the
cryptographic community
The solution shall be cryptographically secure in the long term
The satellite and receiver key update frequency must be minimised
The solution robustness against attacks shall be at least comparable to other

solutions in the state-of-the-art
The solution performance shall at least be comparable to other authentication

proposals in the state-of-the-art
Feasibility
The solution shall be compatible with current Galileo satellites
The solution shall be compatible with Galileo uplink capabilities
The solution shall be compatible with the Galileo ground segment
The solution shall be compatible with the Galileo operations concept
Backward Compatibility
The solution shall be compatible with the current Galileo signal specification
The solution shall not degrade the Galileo navigation data transmission performance
The solution shall not prevent other signal evolutions.
44
An NMA service can provide two service levels: data authentication and signal
unpredictability for protecting against replay attacks. Based on the abovementioned user
needs and types, the authentication design drivers, as regards data authentication, are:
 An asymmetric scheme is favoured, so the users do not need to store, protect and
replace a secret key. Publication of keys through a public web or a dedicated public
key infrastructure (PKI) is therefore needed to certify the authenticity of the signal in
space data.
 The authentication of the data should not degrade user accuracy, or this degradation,
if any, should be minimised.
 The use of only authenticated satellites versus the use of all satellites should not lead
to a lower availability. In other words, all satellites visible by the user shall be
authenticated (either through the SIS, or through receiver verifications). Availability
is actually one of the drivers for the NMA design due to the following:
o Not all satellite signals may be authenticated by the GNSS.
o Not all satellite signals may be authenticated if the user does not successfully
demodulate the authentication data due to shadowing or multipath.
 The solutions shall be cryptographically secure.
As regards anti-replay measures:
 The signal shall contain unpredictability features.

 The design must reduce latency between the start of authentication information
transmission, and its verification by the user. It shall minimise the amount of
information required for the verification authentication, without compromising
security.
Other design drivers related to the usability of authentication at start-up are:
 For standalone users, Time To First Authenticated Fix (TTFAF) shall be minimised.
 Signal unpredictability provided often could help assisted users having authentic data
from their assistance server (and potentially a trusted time reference), by verifying
that their measurements are not replayed.
45
3.4. Performance Indicators

Ideally, user authentication needs could be summarised as having a fully guaranteed
positioning and timing service without any degradation in accuracy, availability and time
to first fix in any environment. On this premise, the main four user performance drivers
considered are availability, accuracy, TTFAF, and robustness. The thesis proposes other
lower-level performance indicators, which relate to these four as depicted in Figure 8.
Further details can be found in [45].
The proposed KPIs (Key Performance Indicators) apply differently whether they are used
to characterise data authentication only, or anti-replay. Given that anti-replay capabilities
depend partly on the receiver, the higher-level indicators are defined for data-
authentication only, unless otherwise stated. For example, for data authentication, all
data-authenticated satellites can be considered in the PVT solution accuracy and
availability performance, although some may not be protected against replay. They can
be translated between data authentication and anti-replay easily, just by relating them to
data-authenticated satellites or data-authenticated and replay-protected satellites. In
addition, some indicators as MPT (Maximum Predictable Time) and USR (Unpredictable
Symbol Ratio) only apply to the anti-replay feature.
Figure 8 - Authentication Performance Framework
Accuracy reflects the user position error using only data-authenticated satellites. It is
equivalent to standard PVT accuracy and can be approximated as follows [6]:
𝐴𝑐𝑐𝑢𝑟𝑎𝑐𝑦𝐴𝑢𝑡ℎ [𝑚] = 𝑈𝐸𝑅𝐸𝐴𝑢𝑡ℎ [𝑚] ∙ 𝐷𝑂𝑃𝐴𝑢𝑡ℎ (3.1)
𝑈𝐸𝑅𝐸𝐴𝑢𝑡ℎ : User Equivalent Range Error represents the accuracy of a ranging

measurement from an authenticated satellite. It depends on the accuracy of the orbit,
46
clocks, ionospheric and tropospheric corrections, multipath and receiver noise [2].
Aspects that could increase UERE due to authentication are:
 The navigation data authenticated is less than the total navigation data. This may
happen if e.g. only the satellite almanacs were authenticated.
 The age of the authenticated navigation data is higher than the most recent
navigation. In the proposed NMA implementations, this effect would be minimal.
𝐷𝑂𝑃𝐴𝑢𝑡ℎ : Dillution Of Precision, or more generally, different satellite geometry of the

authentication solution, can be due to these factors:
 If a user has more difficulties to receive the authentication information than the
standard navigation information, then successfully authenticated satellites, even
in the absence of attacks, may be less than the total.
 If the system is not able to authenticate all the satellites in view by the user, for
example because the user uses other non-authenticated GNSS, or because the
system can only authenticate a subset of its satellites.
Availability reflects the percentage of time, over a certain interval, that a user under
certain conditions correctly receives the authentication information for at least four
satellites. As is the case for 𝐷𝑂𝑃𝐴𝑢𝑡ℎ , it is affected by the reception conditions and
number of authenticated satellites. A global worldwide service volume area must a priori
be targeted by a GNSS.
Time to First Authenticated Fix reflects the time a receiver takes to calculate a position
fix based on at least four data-authenticated satellites.
Robustness encompasses all metrics and indicators related to the security achieved by the
authentication solution. Robustness KPIs MPT and USR are described later.
The following paragraphs describe the lower level KPIs that relate to these four as
illustrated in Figure 8. Out of these, AER (Authentication Error Rate) and TBA (Time
Between Authentications) are highlighted as they stand out as the drivers for
authentication.
System Availability represents the percentage of time that the system has at least four
data-authenticated satellites above a certain elevation at certain positions over a given
area, independently of the user reception conditions.
47
System TTFAF represents the time that the system takes to transmit the navigation and
authentication data required for a fix with data-authenticated satellites, independently of
the user reception conditions.
This section explains more in detail the four indicators considered the most important.
They are the Authentication Error Rate (AER), the Time Between Authentications
(TBA), the Maximum Predictable Time (MPT) and the Unpredictable Symbol Ratio
(USR). AER and TBA are highlighted in the figure due to their high influence on other
indicators.
3.4.1. Authentication Error Rate
AER is defined as the probability of error of a satellite being authenticated in the absence
of attacks but in the presence of disturbances of a real transmission channel. It is
equivalent to packet error rate, the packet encompassing the bits required for a successful
authentication. AER is mainly dependent on the Bit Error Rate (BER) and the total
Number of Navigation and Authentication bits (NNA) required for a successful
verification.
𝐴𝐸𝑅 = 1 − (1 − 𝐵𝐸𝑅)𝑁𝑁𝐴 (3.2)
AER depends on the authentication solution, the signal definition and the shadowing or
fading effects in the communication channel affecting the bit error rate. BER is
understood as the number of bit errors divided by the total number of transferred bits
during a time interval, or the percentage or probability of bit errors. For open-sky
environments, an Additive White Gaussian Noise (AWGN) channel can be assumed. In
this case, assuming no forward error correction, the BER can be derived by
1
𝐵𝐸𝑅 = ∙ 𝑒𝑟𝑓𝑐(√𝐶/𝑁0 ∙ 𝑇) (3.3)
2
where erfc is the complementary error function, C/N0 is the carrier to noise ratio, and T is
the bit period (e.g. 20 ms in case of GPS L1 C/A data bits). Number of Navigation and
Authentication bits required (NNA), includes the Number of Navigation bits (NN) and
the Number of Authentication bits (NA) required for a successful verification:
𝑁𝑁𝐴 = 𝑁𝑁 + 𝑁𝐴 (3.4)
48
The minimisation of NA while preserving adequate security strength is one of the main
challenges and drivers of the design of a data authentication scheme. Not only it has a
high impact in the AER, but it also has a direct impact in the bandwidth overhead
required by the GNSS for authentication. This later aspect is not the focus of this paper as
due to the re-profiling of the Safety-Of-Life service of Galileo, the current Galileo
I/NAV message structure and bitrate allow enough margin to add authentication and keep
spare bandwidth for future uses.
3.4.2. Time Between Authentications
Time Between Authentications (TBA) is the time elapsed between two successive
authentication verifications of a satellite. This means the time, for a certain satellite, to
transmit a new full digital signature, MAC, MAC + key, or whatever authentication
information is chosen. This parameter is relevant for the authentication solutions mainly
for two reasons:
 It influences TTFAF: the receiver needs to wait for all authentication information
to be received.
 It influences robustness: during the time a receiver is processing data for the next
authentication verification, it has no way to verify that the incoming signal is
authentic. The receiver can navigate with past authenticated data, but if the
signals are coherently replayed, the user will be vulnerable until he realises that
the next authentication fails. Therefore, after an data-authenticated, TBA is
mainly relevant to protect against replay attacks.
Once the navigation and authentication information is received, the time for the receiver
to perform the authentication in the order of few milliseconds, and therefore negligible,
for symmetric or even asymmetric schemes. It is therefore considered that a KPI such as
Authentication Latency, understood as the time between all navigation is received, and it
is actually authenticated, is not necessary, and all the relevant aspects are already
encompassed in TBA.
TBA is a design parameter so it need not be computed analytically. The staggering or

offsetting of the authentication events for different satellites can implemented, as
proposed in [23], in which case the user can authenticate subsets of satellites at different
times, reducing coasting time. Then, a distinction between 'user' TBA and 'system' (or
49
channel) TBA can be made. In this chapter by TBA we refer to 'system' TBA, unless
otherwise stated. In real conditions, assuming some AER, average TBA is:
𝑇𝐵𝐴
̅̅̅̅̅̅
𝑇𝐵𝐴 = (3.5)
1 − 𝐴𝐸𝑅
TBA and AER drive the Time To First Authenticated Fix (TTFAF). Assuming that the
user already has valid (but not yet authenticated) navigation data, or that the receiver
receives simultaneously the navigation and authentication data, the average TTFAF is:
𝑇𝐵𝐴
̅̅̅̅̅̅̅̅̅
𝑇𝑇𝐹𝐴𝐹 = + ̅̅̅̅̅̅
𝑇𝐵𝐴 (3.6)
2
TBA/2 is the mean of a uniform probability distribution between 0 and TBA, and
represents the average time that the receiver needs to wait since data demodulation starts
until a new authentication starts (assuming that authentication information is transmitted
sequentially, i.e. all the information for the next authentication is transmitted after the last
authentication). The average TBA takes into account the fact that, because of data
demodulation errors, sometimes the first authentication will be erroneous, increasing the
TTFAF. Signal acquisition time is left out of the computation formulas, as it does not add
value to compare authentication solutions in the context of this work.
3.4.3. Robustness against Replay Indicators: Maximum Predictable Time and

Unpredictable Symbol Ratio
MPT reflects the maximum time that, according to the design, the signal is predictable. It
is based on the fact that if any of the inputs of the authentication function (e.g. the
message to sign or the signature key), varies, the output authentication information will
be fully unpredictable. If the authenticated information includes time, the output bits will
always be unpredictable. The main purpose of reducing MPT is to constrain attacks
taking control of the receiver tracking loops. Having unpredictability in the signal very
often may also favour snapshot approaches whereby a signal snapshot containing
unpredictable features is captured in the receiver, time-tagged with a trusted clock and
checked in a server. MPT is a design parameter and therefore can be computed from the
NMA data structure.
USR, in the context of this work, reflects the percentage of unpredictable symbols out of
the total number of symbols over a given time period in which the message structure is
repeated. With this parameter, if a replay detection test statistic based on hypothesis
50
testing is computed from the estimation of unpredictable symbols (or the first samples
thereof), USR gives an indicator of how long a receiver has to wait to have a reliable test
statistic. USR is a design parameter and therefore can be computed from the NMA data
structure.
3.4.4. Other Robustness Indicators
Symmetric key strength relates to the key length of a symmetric key scheme that would
provide the same level of security. This key strength should drive the design of
asymmetric schemes for NMA.
Key Exposure Time is also a relevant parameter for a NMA solution design. It can be
defined as the time that a public key is known to potential attackers. The exposure time
of the public keys to be transmitted through other means that the SIS (Signal-In-Space),
and stored in the receiver, needs to be traded off with the autonomy of the authentication
solution. Over-The-Air Rekeying (OTAR) can be implemented to reduce exposure time.
3.5. Proposed GNSS Authentication Concept

This section presents the authentication concept on which the proposed NMA proposal
relies. It is based on two main principles:
 The authentication of data from some satellites by other satellites, or cross-

authentication, as described in [45].
 The use of different keys from different satellites but from a single one-way chain
shared by all satellites, through a Timed Efficient Stream Loss-tolerant
Authentication (TESLA) protocol [46].
3.5.1. The TESLA Protocol Features
The main properties of the TESLA protocol make it very suitable for radionavigation
authentication, in spite of the fact that it is standardised to a lesser degree than some
widely used digital signatures. These properties are [46]:
 Low computation overhead for the generation, and mainly the validation, of
authentication information.
 Low communication overhead. This is a key parameter, which affects AER and
TBA. It is maximised if a single chain is used for several satellites, as in the
proposed case.
51
 Strong robustness to data loss, as is the case for GNSS receivers in environments
with reduced visibility.
 Optimal for multicast (one-to-many) transmissions, as is the case for GNSS.
In addition to the obvious requirement that the cryptographic functions used are
cryptographically secure, two assumptions are required for TESLA to provide security:
Firstly, the receiver is loosely synchronised with the transmitter. With the current
proposal, the time uncertainty can be bound by several minutes. Secondly, another
authentication system is required at start-up. The receiver is required to have an authentic
public key or root key.
TESLA is based on the transmission of a Message Authentication Code (MAC) to

authenticate the plaintext message and the delayed transmission of the key used to
compute the MAC. This key belongs to a chain generated through a one-way function F.
The chain starts with a random seed key Kn, which is secret, and ends with a root key K0
that is public and certified through external means so the receiver can consider it as
authentic.
𝐾0 = 𝐹 𝑛 (𝐾𝑛 ) (3.7)
where Fn means recursively applying n times the function F. A hash function is a one-
way function, so each element of the chain can be constructed by hashing the previous
element, as shown in Figure 9. The diode symbol represents a one-way function.
Figure 9 – TESLA one-way chain of keys
GNSS authentication through TESLA would be performed in the following way:
 The receiver receives the navigation data and the MAC.

 The receiver receives later a key from which the MAC can be generated.
52
 The receiver authenticates the key with a previous key from the chain that is
considered authentic, or the root key, by performing function F the required
number of times.
 The receiver re-generates the MAC with the key and the data, which should
coincide with the previously received MAC.
More details about TESLA protocols for GNSS can be found in [42], [22], [47], [48] and
[40]. The cryptographic strength of the chain generation mechanism is increased by
adding to the hashing process other information known to the receiver, as e.g. a counter
or time reference. In addition, the key size can be reduced by truncating the hash output,
in order to reduce communication overhead. In this case, the function F is proposed as
follows:
𝐹(𝐾𝑚 , 𝐺𝑆𝑇𝑗 ) = 𝑡𝑟𝑢𝑛𝑐(𝐾𝑙𝑒𝑛 , (ℎ𝑎𝑠ℎ(𝐾𝑚 || 𝐺𝑆𝑇𝑗 ))) (3.8)
where Km is the key used as an input to the function, GSTj is the Galileo System Time
associated to the beginning of the authentication frame 'j' in which the key is applied,
trunc is the truncation function to the Klen Most Significant Bit (MSB), Klen is the length
of the key, hash is hash function used (e.g. SHA-256 [14]), and || is the operator to
concatenate Km and GSTj into a single bit chain. An authentication frame here refers to
the interval of time during which authentication information (MACs and key) are
transmitted. The authentication frame finalises with the authentication verification, once
the key has been received.
One potential vulnerability to this chain generation process is that, if the start and end
times of the chain are known by an attacker, e.g. if the attacker knows that the K-root of
each new chain will be tied to Jan 1st 00:00:00 of each new year, the attacker would also
know the applicability time of Kn, and could pre-compute several chains much before
their K-root is published. To protect against that, two measures are possible: First, the K-
root applicability time can be made less deterministic, so the attacker has to search for
more options. Second, a few-bit pattern published together with the K-root, and used in
function F, would make pre-computation attacks much more difficult. In this second
case, the function F would be as follows:
𝐹(𝐾𝑚 , 𝐺𝑆𝑇𝑗 , 𝑝𝑎𝑡𝑡𝑒𝑟𝑛) = 𝑡𝑟𝑢𝑛𝑐(𝐾𝑙𝑒𝑛 , (ℎ𝑎𝑠ℎ(𝐾𝑚 || 𝐺𝑆𝑇𝑗 || 𝑝𝑎𝑡𝑡𝑒𝑟𝑛))) (3.9)
53
In a standard TESLA approach, each sender (satellite) uses a different one-way chain, as
shown in Figure 10. If a receiver authenticates four satellites, it should receive, in
addition to the data to authenticate (P1, P2, P3, P4), four MACs (MAC1, MAC2, MAC3,
MAC4) and four keys (K1, K2, K3, K4), one from each satellite, where each key belongs
to a different chain. The next section presents an optimization whereby all senders
(satellites) use the same key chain, in order to reduce AER.
Figure 10 – Standard TESLA approach with a different key and chain per sender
3.5.2. TESLA with a Single Chain from Several Senders
The proposed concept differs from other solutions that have been described in previous
literature in the use of a single one-way chain for all senders, as opposed to the use of a
single one-way chain for each sender. The main motivation of this choice is to drastically
reduce the AER: by allowing all the satellites to be authenticated through the same chain,
a user needs to receive only a correct key from any satellite to authenticate all satellites.
This reduces dramatically the number of bits required for calculating a PVT using data-
authenticated satellites.
A single chain is beneficial not only for the NMA success rate in stationary conditions
(i.e. after a certified root key is in possession of the receiver): It also helps during the
initialization, thanks to the fact that only one root key is required for all satellites, as
opposed to one root key for each satellite. This highly reduces the Time To First
Authenticated Fix.
54
Figure 11 – TESLA approach with the same key for all senders
The proposed solution is especially useful when one or few satellite signals are received
in good conditions, while others are received at lower elevation angles or subject to
multipath or blockage and therefore they are demodulated with a much higher bit error
rate, which may be the case in urban environments. Even if due to shadowing or fading,
no key is successfully demodulated from any satellite in a certain authentication frame,
which lasts a number of seconds equivalent to TBA, any key from the next authentication
frame can be used to verify the previous authentication frame.
3.5.3. TESLA with a Single Chain and Different Keys from Different Senders
One problem that arises when using a single one-way chain for all satellites is that it
reduces signal unpredictability: if the same key is transmitted at the same time from all
satellites, it will be received at different times by users due to the different satellite clock
offsets and, principally, due to the differences in distance. For example: The signal from
a Galileo satellite at the zenith would arrive at the Earth surface after approximately 77
ms, while the signal from a satellite at a very low elevation could take around 100 ms. A
spoofer would have some milliseconds to estimate some unpredictable bits from one
satellite and replay them with a delay at another one, spoofing the position even if the
data message is authentic. As a result, if all satellites are transmitting the same key at the
same time, only the symbols from the satellite closest to the zenith can be considered
unpredictable.
This problem can be overcome by transmitting different keys from different satellites, but
still from the same chain. In this way, the key bits would still be unpredictable while the
MAC key is recoverable from any later key of the chain. At a given authentication frame
j, the key used for the MACs can be derived from the key received from satellite i as
follows:
55
𝐾𝑗,𝑀𝐴𝐶 = 𝐹 𝑖−1 (𝐾𝑗,𝑖 , 𝐺𝑆𝑇𝑗 ) (3.10)
where 𝐾𝑗,𝑀𝐴𝐶 is the key used for the MAC computations of the MACs transmitted at j,
𝐹 𝑖−1 is the F function in equation (3.8) applied i-1 times to Kj,i, the key received from
satellite i in authentication frame j, and 𝐺𝑆𝑇𝑗 is the Galileo System Time at the beginning
of authentication frame j. In this case, the key Kj,1 would be transmitted by satellite 1 at
authentication frame j and be used for the MAC computation, i.e. Kj,1 = Kj,MAC. To avoid
the reuse of the key, another chain element can be added, or an additional function can be
used to generate the MAC keys from the transmitted keys as proposed in [42] and [46].
For the sake of simplicity, at the time being this is not part of the NMA proposal in this
chapter. This potential evolution does not affect the conclusions derived from the
proposal.
To validate the MAC key in authentication frame j with the MAC key from the previous
frame j-1:
𝐾𝑗−1,𝑀𝐴𝐶 = 𝐹 𝑆 (𝐾𝑗,𝑀𝐴𝐶 , 𝐺𝑆𝑇𝑗−1 ) (3.11)
where S is a constant representing the maximum number of satellites, i.e. the maximum
number of times the function F is executed in one authentication frame. The main
drawback of this approach compared to the use of one key per authentication frame is
that it requires a higher computational power, as the number of one-way operations per
chain is higher. For example, if S=40, the chain would become 40 times longer. The
assessment of the additional CPU needs for this approach is covered in a later section.
Figure 12 and Figure 13 present how the keys of a certain chain would be transmitted and
used every time the receiver performs an authentication. The discontinuous lines of
Figure 13 for the keys imply that the receiver (Rx) only needs to receive a key from one
satellite to authenticate all MACs.
For example, if authentication frame j lasts 10 seconds (TBA=10s), every 10 seconds

each satellite would send at least one MAC generated with Kj,1 = F(Kj,2,GSTj) = F2
F(Kj,3,GSTj), etc. Kj,1 would also be transmitted from SVID (Space Vehicle ID) 1, while
SVID 2 would transmit Kj,2, SVID 3 would transmit Kj,3, and so on. In this way, a spoofer
would not be able to predict the key of one satellite from another. One could argue that if
SVID2 is closer than SVID1 to the receiver, an attacker could predict Kj,1 by receiving
previously Kj,2 from the closer satellite. However, as the transmission of the keys is done
56
in parallel during some seconds, only the very few final bits of Kj,1 could be predicted by
having a high amount of bits of Kj,2, rendering such an attack rather impractical. User
implementations should discard the last bits of the key in the anti-replay statistics.
Figure 12 – TESLA one-way chain with different keys from different senders
Figure 13 – TESLA single-chain approach with a different key transmitted by each sender. No cross-
authentication
To finalise the description of the proposed concept, the generation of the MACs
transmitted by each satellite can be performed as follows:
𝑀𝐴𝐶𝑗,𝑖,𝑙 = 𝑡𝑟𝑢𝑛𝑐(𝑛, 𝑚𝑎𝑐(𝐾𝑗,𝑀𝐴𝐶 , (𝑖 || 𝑙 || 𝐺𝑆𝑇𝑗 || 𝐶𝑇𝑅 || 𝑃𝑗,𝑙 ))) (3.12)
where 𝑀𝐴𝐶𝑗,𝑖,𝑙 is the MAC for frame j transmitted by satellite i to authenticate the
navigation of satellite l (note that i and l can coincide, when the satellite self-
authenticates); 𝑡𝑟𝑢𝑛𝑐 is the truncation function to the n MSB, GSTj is the Galileo system
time associated to authentication frame j; CTR is a counter with the position of the MAC
in the transmission; and Pl,j is the navigation data from satellite l at frame j to be
authenticated. Note that, following the cross-authentication approach, each satellite
57
transmitting authentication can transmit several MACs, for itself and the neighbouring
satellites. Examples of typical MAC functions used are HMAC-SHA-256, as
standardized in [49], and CMAC-AES, standardized as Algorithm 5 in [50].
3.5.4. TESLA and "Cross-Authentication"
Due to the current architecture of the Galileo system, only satellites connected to ground
may be able to transmit authentication information. This means that, in the full
operational capability, the percentage of connected satellites transmitting authentication
information can be approximately between 2/3 and 4/5 of the total number of satellites
(next Galileo generations may overcome this limitation). The navigation data of the
remaining satellites can be data-authenticated by these satellites: Several MACs can be
transmitted for each MAC-Key section, allowing to "cross-authenticate" some satellites
by others.
Figure 14 – TESLA single-chain approach with connected (2,4) and non-connected (1, 3, 5) satellites
Figure 14 shows how satellites 2 and 4 can authenticate their own navigation (N2, N4)
and cross-authenticate the surrounding (non-connected) satellites 1, 3 and 5. This scheme
may lead to duplications in the transmitted information (e.g. MAC(N3,Kj) in the figure) or
to the reception of authentication for satellites out of view. However, it ensures the
authentication of all the navigation information received by all users on earth, at least by
Galileo and potentially by other GNSS.
58
3.6. An NMA Proposal for Galileo Signals
This section presents a concrete NMA proposal for the Galileo I/NAV message structure.
One of the drivers for this proposal is that it does not require any modifications in the
Galileo core system infrastructure, other than extending its input interface to
accommodate more bits in the "Reserved 1" field described below. This would permit
Galileo to offer an NMA service in the next few years very easily. The NMA proposal
performance could be improved by further modifications of the Galileo satellites and
ground segments.
The Galileo E1-B I/NAV message structure is based on the transmission of a full
navigation frame every 750 seconds. The frame is composed by 30-second subframes,
which always transmit all the required positioning parameters except the almanac. Every
subframe is divided in 15 2-second pages, each of which contains one word and some
other fields, as shown in Figure 15. 120 bps can be transmitted in the E1-B I/NAV
message, which are convolutionally encoded into 240 sps, interleaved and appended to a
10-symbol synchronisation pattern for a total of 250 sps. The E1-B symbol stream is
modulated through a DSSS (Direct Sequence Spread Spectrum) technique with 4092-
chip pseudorandom codes at 1.023 Mcps, and with a subcarrier at 1.023 MHz to achieve
a BOC(1,1) modulation. Thus, every 4-ms symbol is modulated within a single 4-ms
code. All the details about Galileo I/NAV signals and message can be found in the
Galileo Open Service Signal-In-Space Interface Control Document (OS SIS ICD) [12].
The field named as "Reserved 1" in the ICD [12], also known as ERIS (External
Regional Integrity Service) field or EDBS (External Data Broadcast Service) field, and
currently unused, is proposed to transmit NMA information. This field provides a
bandwidth of 40 bits every other second. Galileo is designed to receive the bits of this
field from an external source. Thus, by using this field, the Galileo system can provide
NMA into the Galileo core infrastructure, minimizing the impact at core system level of
adding NMA. In addition, the scattering of the bits across the navigation message allows
reducing MPT.
Figure 15 presents the Galileo E1B I/NAV message structure and the position of the
"Reserved 1" field in it, and Figure 16 shows the position of the "Reserved 1" field
within an E1-B I/NAV word.
59
Figure 15 – Galileo E1B I/NAV subframe message structure
The 40 bits-per-2-second bandwidth yields 20 bps for a total of 600 bits every I/NAV
subframe, after which, in nominal conditions, the I/NAV words are repeated. This 30-
second subframe structure has also been taken as a reference for NMA, to facilitate
synchronization between the reference time, the authenticated navigation data, and the
authentication data. The authentication message structure is therefore synchronized with
the Galileo I/NAV navigation message structure.
60
Figure 16 – "Reserved 1" field in each I/NAV Word
The full use of the 20 bps of the I/NAV E1-B "Reserved 1" field allows very low TBAs
and a high cross-authentication redundancy, both of which increase robustness and
performance. The high amount of spare bits in the current Galileo I/NAV makes the full
use of this field for NMA a reasonable design decision, leaving other spare bits for future
uses.
This section describes the data structure in which the authentication information can be
provided in the Galileo SIS. It also describes all the fields and their possible values. The
main data blocks of the NMA proposal are presented in Figure 17. The SIS
authentication information is based on two main sections:
 "H-K-root" (Header and Root Key) section: This section includes the global
header and a digitally signed root key. In fact, the header and the K-root parts can
be considered as separate sections.
 "MAC-K" (MACs and Key) section: This section includes the MACs and
associated key, delivered later. Three MAC-K sections are shown, for
authentication frames j, j+1 and j+2, each of 10 seconds, as TBA is 10 seconds.
The number of MAC-K sections, as well as other parameters, is dynamically
configurable for each chain.
The authentication service is mainly based on the MAC-K section, which occupies 32 out
of the 40 bits per word, while the H-K-root section occupies the remaining 8 bits.
61
t[s] 0 2 4 6 8 10 12 14 16 18 20 22 24 26 28
p1 p2 p3 p4 p5 p6 p7 p8 p9 p10 p11 p12 p13 p14 p15
MAC-K-1 MAC-K-2 MAC-K-3

(MAC-K sections)
MACS KEY MACS KEY MACS KEY
DS header
Header
DSM (H-K-root section)
Figure 17 –NMA proposal within the Galileo I/NAV message structure
The top row of Figure 17 shows the subframe time, which goes from zero to 30 seconds.
The second row shows the page order, from one to 15. For every page, 40 bits are
available for NMA. To authenticate the keys of the MAC-K section, a root key (K-root)
is sent with a digital signature in the H-K-root section. In addition to the SIS information,
the system shall provide a public key to authenticate the K-root through other means than
the SIS, allowing the verification of the root key.
The following sections provide a general description of the NMA fields. To improve the
readability of this chapter, the detailed, bit-level definition of each field and possible
values is presented in Appendix B.
3.6.1. H-K-root Section
A global header and a digitally signed root key is provided in this section allowing the
user to verify the root key authenticity through a public key. H-K-root (Header and K-
root) is transmitted in the first 8 bits of each EDBS 40-bit field. The K-root section
ensures that an authentic [K-root, K-root Time] pair is known to the receiver, allowing it
to validate a key of the chain received in the MAC-K section. Chains may be several
months long, so the receiver will seldom need to decode this section, as it can work with
a previously loaded K-root, either from a previous certificate, or from a previous K that is
considered authentic (by a K-root).
One of the reasons to transmit H-K-root in parallel with the other fields (keys and
MACs), as opposed to sending it in some full EDBS 40-bit fields, is that in the latter case
the signal may be predictable during this time, therefore increasing maximum predictable
time of the signal and potentially weakening the service protection against replay attacks.
62
In addition, separating H-K-root and MAC-K sections allows more flexibility in the
solution design by removing cross-dependencies.
H-K-root is transmitted synchronously with the I/NAV subframe. That means that each
subframe a full block is transmitted. Each block is 8 bits * 15 words = 120 bits long.
Figure 18 presents the structure of the H-K-root section, including all the fields.
Figure 18 – H-K-root structure and fields (see Appendix B for more details)
The main data blocks of the H-K-root section are the Header, DS-Header, and DSM
(Digital Signature and Message):
Header: At the beginning of each subframe, the global authentication header is

transmitted. It occupies 16 bits (i.e. two words, or 4 seconds in the I/NAV structure) and
it is repeated in each subframe. It includes the system operational status and the flags
required for chain and management (OS, CID, EOC and NKR). It also contains the
information of the digital signature to be transmitted in the remaining 104 bits of the
subframe (Digital Signature ID and Block ID).
DS-Header: It is the Digital Signature Header transmitted at the beginning of a digital

signature (i.e. only in the first subframe), and contains the number of blocks it occupies
(NB) and the ID of the public key used for its generation (PKID).
DSM: Digital signature (with or without recovery) authenticating the K-root and its
associated parameters: Chain ID (CID), Key Size (KS), Hash Functions (HF), MAC
Function (MF), MAC Size (MS), and time associated to the K-root (WN-Kr and DOW-
Kr, for Week Number and Day Of Week). A pattern may be added after the K-root in the
case of digital signatures with message recovery. See Appendix B for more details.
63
Figure 19 shows an example of the transmission of a full H-K-root in the I/NAV

subframe structure. In the proposed example, the transmission lasts 5 subframes per
satellite (i.e. 150 seconds) and the DS and message (DMS field) length is 512 bits.
field H DSH DSM(1/5)

length [b] 16 8 96
H DSM(2/5)
16 104
H DSM(3/5)
16 104
H DSM(4/5)
16 104
H DSM(5/5)
16 104
Figure 19 – H-K-root example in five subframes/blocks
By knowing the DS ID and the Block ID, a receiver can reconstruct a K-root easily, even
if different K-root blocks were transmitted at the same time from different satellites. In
principle, there is no reason to change often the DS-ID, which would facilitate the
authentication process, as the same K-root would be transmitted continuously from all
satellites for long periods. A K-root update will only be mandatory for every new chain,
and the change of chain is expected to happen between once every several weeks, to once
every several months, depending on the chain key length and other security
considerations.
t t+30s t+60s t+90s t+120s t+150s

SV1 I1,B1 I1,B2 I1,B3 I1,B4 I1,B5 I2,B1
SV2 I1,B2 I1,B3 I1,B4 I1,B5 I2,B1 I2,B2
SV3 I1,B4 I1,B5 I2,B1 I2,B2 I2,B3 I2,B4
SV4 I1,B1 I1,B2 I1,B3 I1,B4 I1,B5 I2,B1
Figure 20 – H-K-root / header / number of blocks field
Figure 20 shows an example of a 5-block digital signature recovery where block

transmission is offset between satellites. The receiver only needs to decode the blocks in
dark orange to obtain a certified K-root. The blocks in light orange are redundant blocks
of DSID1. Assuming the receiver can receive SV1 to SV3 in good conditions, it would
complete a K-root in two subframes, or one minute.
A receiver does not need to receive a whole block correctly from one satellite. It can just
reconstruct a certain block from different satellites, by aggregating the 8-bit parts
64
received correctly from different I/NAV words. This can be verified e.g. by checking the
CRC (Cyclic Redundancy Check) validity of an I/NAV 2-second word, which includes
the EDBS field. If the CRC check is correct, that means that the 8-bit H-K-root portion of
that word should be valid as well.
3.6.2. MAC-K Sections
This section is transmitted in parallel to the H-K-root and contains the truncated MACs
and keys that are delivered later, from which the key used for the MACs computation can
be derived. As the H-K-root section consumes 120 bits per subframe, the remaining 480
bits are available for the MAC-K section.
The currently foreseen length of keys and MACs is 80-128 bits and 10-20 bits
respectively. Thus, one, two or three keys can be sent every subframe, one every 30, 15
or 10 seconds, respectively, with its associated MACs. This allows frequent
authentications to constrain the potential attacks. As mentioned before, the MAC and key
size is configurable for every chain, and fixed when the K-root is sent in the H-K-root
section.
For the remaining of this chapter, a scheme with three MAC-K sections per subframe is
analysed. This means that the 480 bits available for the MAC-K sections will be divided
in three MAC-K sections of 160 bits each.
Figure 21 depicts the structure of the MAC-K section. The different fields are grouped by
type: all MAC and MAC-Info sections of a given MAC-K section are put in a column,
the associated key is put in the next column, and so on. The order in which the
information is received by a receiver is given by reading each row from left to right, and
then from top to bottom.
Figure 21 – MAC-K section structure (see Appendix B for more details)
65
The receiver can determine how many MACs are transmitted per MAC-K section by
knowing the key and MAC sizes, and assuming a predefined number of MAC-K sections
from the NMA specification document. If not, an additional field in the K-root message
can be added to specify the number of MACs.
The MAC-K sections are identical in format. Each one is composed of several MACs,
each one with a 'MAC-Info' field (equivalent to the header), providing information about
the MAC. The reasons why the MAC-Info field is appended as a tail and not a header
before the MAC are that, first, it increases the distance between the last MAC and the
transmission of the key. Second, it prevents the case in which, due to I/NAV encoding
and interleaving, a significant number of bits of the key are delivered before some bits of
the MAC. While an attack based on this feature seems difficult, the design should
prevent an early key disclosure in any case.
The main data blocks of each MAC-K section are the MAC, the MAC-Info and the key:
MAC: Truncated MAC (from the MSB) with the length as defined in the MAC Size field
of the DSM section. Typically, the permitted values are between 10-20 bits. In addition
to the data, the MACs authenticate also the system time and the SVID in the following
way:
𝑚 = (𝑆𝑉𝐼𝐷_𝑁 || 𝑆𝑉𝐼𝐷_𝐴 || 𝐺𝑆𝑇 || 𝐶𝑇𝑅 || 𝑛𝑎𝑣𝑑𝑎𝑡𝑎) (3.13)
𝑡𝑎𝑔 = 𝑡𝑟𝑢𝑛𝑐(𝑛, 𝑚𝑎𝑐(𝐾, 𝑚)) (3.14)
where m is the message to be authenticated, SVID_N is the satellite ID being

authenticated as defined in the MAC-info section, SVID field; SVID_A is the satellite ID
providing authentication as defined in the MAC-info section (it can only be a Galileo
satellite). When NMA status is in 'test' mode, SVID_A = 0 (see Appendix B for more
details); GST is the Galileo system time (seconds), as per [12], of the start of the
subframe in which the MAC is transmitted6; CTR is a counter with the position (8-bit
uint) of the MAC in the MAC-K section. E.g. if the MAC is going to be transmitted first,
CTR=1; navdata is the navigation data authenticated as defined in the MAC-info section,
ADKD (Authentication Data and Key Delay) field (see definition below); tag is the
6
For offset MAC-K sections (SVID 16 onward) the subframe taken for the time reference will be that if no offset were
applied. Note that with the current implementation this is irrelevant anyway.
66
truncated MAC transmitted in the signal; trunc(n,p) is the truncation function whereby
the message p is truncated to the n MSB; n is the truncated MAC length, as defined in the
DSM; mac is the MAC function used, as defined in the DSM; and K is the key from the
one-way chain used for the MAC.
If the SVID were not added to the MAC, given that all MACs in a MAC-K section are
signed with the same key, an attacker could forge the signal and transmit the same
navigation data from several satellites, and later replay the first MAC. This attack is
prevented by adding the SVID to the authenticated message.
The GST is added to make the message to be signed always different and increase
robustness, as the navigation data may be updated only every hour or so. However, even
if it were not added, the MACs would be unpredictable in the current NMA proposal, as
they use a different key every MAC-K section. The signal time is authenticated just by
ensuring the authenticity of a key vs the K-root: if a key of a certain subframe is
authenticated using the TOW of that subframe, the TOW must be authentic too as,
otherwise, the hashing process would not lead to the K-root.
MAC-Info: It identifies the MAC just transmitted, by telling to which satellite the
authenticate data corresponds (SVID), what is the Issue Of Data associated (IOD), and
what kind of data is authenticated, and the latency between the MAC and the key
(ADKD). Due to its importance in the concept, the ADKD is described in more detail. Its
values are presented in Table 2.
67
Table 2 – ADKD parameter proposed definition
ADKD Definition (TBC)

0 Eph&Clk
1 IonoBGD
2 Subframe
3 Gal F/NAV Eph&Clk
4 GPS L1C Eph&Clk
5 SBAS TBC
6 Rsvd
7 Rsvd
8 Rsvd
9 Rsvd
10 Rsvd
11 SLOW-MAC, Eph&Clk, 1 subframe delay
12 SLOW-MAC, Eph&Clk, 2 subframes delay
The proposed meaning of ADKD bits for Galileo is:
 '0', eph&clk: the MAC authenticates the bits of the fields related to the ephemeris,
including clock corrections, of the given satellite.
 '1', ionoBGD: the MAC authenticates the bits of the fields related to the
ionospheric corrections, Broadcast Group Delays (BGDs), satellite health and
Galileo time.
 '2', subframe: the MAC authenticates the bits of a certain full subframe.
 '3', Gal F/NAV eph&clk: the MAC authenticates the ephemeris and clocks of the
F/NAV message.
 '11' to '15', "slow MACs": As described in [46], a requirement of the TESLA
protocol is a loose time synchronisation between the sender and the receiver. In
order to prevent attacks whereby the attacker would rebroadcast a right key with
forged navigation and MACs, which could happen if the receiver has a time
uncertainty in the order of the seconds between the reception of the MACs and
the key, the concept of "slow MACs" is added. A "slow MAC" is a MAC
generated with a key that will be broadcast with some subframes of delay.
Key: this field contains the key.
68
3.6.3. Bandwidth Allocation Analysis
The figures in Appendix A present a bandwidth allocation analysis for different MAC
lengths and key lengths. Based on this analysis, lengths can be selected to avoid having
unused bits in the MAC-K sections. The figures in Appendix A show, for a given number
of MAC-K sections per subframe and a given length of MACs and keys, the number of
MACs that can be transmitted and the spare bits per MAC-K section, among other
parameters. With these constraints, Table 3 and Table 4 show combinations that yield all
160 bits used (3 MAC-K sections / subframe) and all 240 bits used (2 MAC-K sections /
subframe), respectively, and the achievable number of MACs per MAC-K section. By
keeping a truncated MAC length of 10 bits, and a key length of 82 bits or less, three
MACs per MAC-K section can be transmitted, for a total of 9 MACs, i.e. a maximum of
9 data-authenticated satellites per channel, every 30 seconds.
Table 3 - Number of possible MACs for a given MAC length and Key length combination using the whole
bandwidth. 3 MAC-K sections per 30-s subframe – 10s TBA
Key size MAC size [bits] Number of Number of Number of keys

[bits] MACs per MACs per 30- per 30-seconds
MAC-K section seconds
82 10 3 9 3
88 20 2 6 3
90 19 2 6 3
92 18 2 6 3
94 17 2 6 3
96 16 2 6 3
98 15 2 6 3
100 14 2 6 3
102 13 2 6 3
104 12 2 6 3
106 11 2 6 3
108 10 2 6 3
Table 4 - Number of possible MACs for a given MAC length and Key length combination using the whole
bandwidth. 2 MAC-K sections per 30-s subframe - 15s TBA
Key size MAC size [bits] Number of Number of Number of keys

[bits] MACs MACs per 30- per 30-seconds
seconds
80 16 5 10 2
84 10 6 12 2
85 15 5 10 2
90 14 5 10 2
95 13 5 10 2
96 20 4 8 2
100 12 5 10 2
100 19 4 8 2
104 18 4 8 2
69
105 11 5 10 2
108 17 4 8 2
110 10 5 10 2
112 16 4 8 2
116 15 4 8 2
120 14 4 8 2
124 13 4 8 2
128 12 4 8 2
With the current proposal, each satellite could transmit three keys per subframe (one
every 10 seconds), and transmit 9 MACs in total (3 per key) (see first row of Table 3)
which gives a highly performant authentication solution. The fast key update can be also
useful if Galileo signal evolutions allow for encoding parts of the spreading codes with
the keys later delivered.
In the rest of this chapter, we use as the baseline proposal three MAC-K sections with
10-bit MACs and 82-bit keys.
3.7. A Proposed Implementation in the Galileo System and Facilities

3.7.1. NMA Architecture
The NMA service proposed uses data in the E1-B I/NAV EDBS (former ERIS indirect
link) bits (20 bps in E1-B), currently unused in the Galileo system. EDBS is received by
the Galileo core infrastructure from an external source. This external source can be the
European GNSS Service Centre (GSC), which will be accredited in any case to be
connected in real time to the Galileo core infrastructure to deliver the Galileo
Commercial Service [27]. The NMA proposal can based on Galileo already existing
features, as follows:
 The GSC specification foresees the interface for the transmission of E6 data
already and a framework to transmit EDBS data in similar conditions. The
transmission of EDBS data can be incorporated into the interface specification
between the Galileo Ground Mission Segment (GMS) and the GSC.
 The latency for EDBS data transmission within the core infrastructure is assumed
the same as that for E6 data transmission, and in the order of 6 seconds. As
explained below, the proposed concept is not very sensitive to system latency.
 The GSC already foresees to connect in real time to the GMS to transmit E6 data
and receive real-time information from the system. Therefore, security
70
accreditation activities already foreseen for the GSC can be leveraged to allow the
transmission of EDBS data.
Figure 22 presents the basic architecture on which the proposed NMA could be
implemented in the Galileo system.
Figure 22 – NMA Architecture
An NMA generation module, which could be integrated within the GSC secured
perimeter, receives I/NAV data in real time from the GMS. This information is already
available in the current interface. This interface already includes GPS ephemeris data, so
GPS could be also data-authenticated. The NMA generation module authenticates I/NAV
data, which is sent by the GSC to the GMS through the ERIS/EDBS channel (already
built in the GMS). The Galileo Control Centre (GCC), through its Message Generation
Facility (MGF) incorporates the EDBS information and transmits it to the Up-Link
Station (ULS) for uplink to the connected satellites. The connected satellites transmit the
authentication data interleaved with the E1-B I/NAV message in the ERIS/EDBS field,
and the users authenticate the I/NAV with the EDBS authentication information and a
public key already in their receivers. This public key is published and certified as correct.
3.7.2. System Latency and User Performance
Following the proposed architecture, there will be latency between data is received by the
user and authenticated by the system. This section analyses the impact of this latency in
user performance. In the current system, this latency can be down to some seconds
(thanks partly to the inherited Galileo safety-of-life architecture). For the remaining, we
71
assume an end-to-end latency of 12 seconds, twice the foreseen 6 seconds by design, and
therefore considered affordable in the Galileo system. We also assume a delay in the
authentication process of a full 30-second subframe (except when noted). This means that
if new data is transmitted by the system, it will not be authenticated until one subframe
later. This is a conservative assumption given that every subframe, up to three
authentication events (one every 10 seconds) can take place, according to the current
authentication definition.
The main reason why latency will have little impact in NMA performance is that a user
already tracking data-authenticated signals and calculating authenticated PVT can
continue navigating using authenticated data. I.e., when a new IODnav is transmitted by
the system but not yet authenticated by the NMA generation module, the user receivers
will still use the previous IOD until the next subframe, in which the new IOD is
authenticated. This will pose no or minimal degradation in the navigation performance
during 30 seconds, as illustrated in Figure 23.
Figure 23 – Authenticated PVT as a function of IODnav of a given satellite during IODnav transition
The only authentication event whose latency can have an impact in the user performance
is the ephemeris authentication type (ADKD=0). Delay in providing authentication of
ionospheric parameters ('ionoBGD', ADKD=1) has no impact in authentication
performance as the ionospheric parameters are foreseen to be updated very seldom, and
navigation performance is not foreseen to be altered by using the previous ionospheric
parameters. Also, by receiving E1-B and E5b I/NAV messages, the NMA generation
module can receive the Iono word (Word 5) before the 6th second of a subframe from
E5b, and send it by the end of the E1-B subframe, so authentication of ionospheric
parameters could even take place within a given subframe, with a 12-second latency.
3.7.2.1 Impact in a Stationary User
We assume that an IODnav is never updated more frequently than once every 10 minutes
(5% of subframes), and normally around once every hour (0.8%). IODnav changes will
not occur simultaneously for several satellites in view by the user, at least for Galileo,
72
minimising the overall effect, if any at all, of using older ephemerides in the PVT
computation.
Therefore, the impact in a stationary user, i.e. a user already computing data-
authenticated PVT, due to the authentication system latency is minimal. However, any
guidelines for receiver implementation must state that the data-authenticated PVT service
relies on the usage of the latest authenticated data, even if newer data is available.
3.7.2.2 Impact in TTFAF
This section presents the impact of system latency in TTFAF data authentication in cold
start mode. We assume that:
 The receiver has neither any IODnav nor any recent MAC-key information. It
does have a certified and valid K-root.
 The user needs one full subframe to process all necessary navigation data to
compute a first PVT (mainly ephemeris, ionosphere, and TOW).
 The user needs one full subframe to process all authentication information
necessary for a data auth-PVT (mainly MAC sections from satellites and at least 1
key).
In this situation, authentication latency would only impact the case in which a user
receives as first subframe containing IODnav(i+1) and Auth(IODnav(i)), as e.g. between
T0+30s and T0+60s in Figure 24. In a nominal scenario, one can assume that the
satellites whose IOD is being updated are a minority, and that the user will still have
enough satellites in view whose IOD is not updated, therefore causing no degradation at
all for the TTFAF even in this case, i.e. TTFAF will be the same as TTFF. Therefore, in a
nominal scenario, even if the user switches on its receiver at an IODnav change, its
TTFAF will not be affected.
In a worst-case scenario, in which the updated IODnav satellites are necessary for the
PVT and therefore for the first fix, the user receiver might need to wait for another
subframe (30s) to receive the new authenticated IODnav. This situation seems very
unusual. Even if it happened, the NMA module could receive a new IODnav from E1 and
E5b (which transmit the both the same I/NAV message, but in different order), assuming
a latency of 12 seconds, and would still have time to transmit it to the user within the
subframe, as shown in Figure 24.
73
I/NAV word
E1B 2 4 6 7 or 9 8 or 10 rsvd rsvd rsvd rsvd rsvd 1 3 5 spare spare
E5B 1 3 5 7 or 9 8 or 10 rsvd rsvd rsvd rsvd rsvd 2 4 6 spare spare
time [s] 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30
end-to-end latency: 4s-16s subframe time to transmit new IOD authentication: 16s-30s
Figure 24 –"Optimised" authentication transmission to authenticate IODnav from the same subframe
(eph&clock I/NAV words 1, 2, 3, 4 marked in grey)
Therefore, with an optimised NMA implementation, and under the current assumptions,
TTFAF can be the same as TTFF in all cases.
As regards anti-replay protection, in case the unpredictability of the authentication

information is used for signal (and therefore pseudorange) authentication, the same as for
data authentication applies, i.e. in most cases the user receiver will have all the elements
available to perform an authentication verification.
3.7.2.3 Examples
In order to illustrate the above cases, we analyse some examples. In the current examples,
we assume that 30 seconds are elapsed between data is transmitted in the I/NAV by the
core infrastructure.
Example 1 – Stationary case – IODnav change: a user is performing authenticated

PVT with IODnav(i) and authentication data for IODNav(i). In a given subframe, the
system updates the navigation data to IODnav(i+1). For this subframe, the user will
receive IODnav(i+1) and authentication of IODNav(i). The user can navigate with
IODNav(i) authenticated data, and re-authenticate IODNav(i) to protect against replay,
until both IODnav(i+1) and authentication of IODnav(i+1) are received in the next
subframe.
Example 2 – Cold start – no IODnav change: a user switches on its receiver. Once the
signals are acquired, it starts demodulating the navigation data. As the IODnav is not
changed, the user will get at the same time the navigation and the authentication for this
navigation data, even if authentication data has a latency of 30s. Once it has received the
navigation and authentication data, it can continue re-authenticating the data to ensure it
is not subject to replay attacks.
Example 3 – Cold start – IODnav change: a user switches on its receiver. Once the
signals are acquired, it starts demodulating the navigation data. As the IODnav has
changed, the user will get at the same time the navigation data of IODnav(i+1) and the
authentication data of IODNav(i). It will be able to start navigating with IODnav(i+1),
74
but it cannot authenticate this data with the authentication information. It needs to wait at
most 30 seconds (the latency assumed in this case) to receive authentication information
for IODnav(i+1), in order to authenticate IODnav(i+1).
Example 4 – Warm start – IODnav change: a user switches on its receiver. Once the
signals are acquired, it starts demodulating the navigation data. As the IODnav has
changed, the user will get at the same time the navigation data of IODnav(i+1) and the
authentication data of IODNav(i). However, as the user already has IODNav(i) data, it
can navigate temporarily with this data (which should not be degraded, as it is only 30-
seconds beyond its foreseen applicability time), until authentication for IODnav(i+1) is
received.
We can conclude that an end-to-end latency in the order of some seconds will not have a
significant impact in the NMA, neither in stationary mode nor for TTFAF, which should
remain the same as TTFF. The current system architecture should therefore allow
latencies with enough margin to perform NMA as proposed.
3.7.3. Message Losses
Data losses in the transmission of data authentication through the system loop lead to
unsuccessful authentication events. Events in the data transmission should be reported to
the user, for example by the broadcast of an EDBS dummy message, as opposed to a
wrong or corrupted message, as otherwise they may have an impact on the spoofing
detection logic. This way, the user can detect an error in the system transmission and flag
the unsuccessful authentication accordingly. Data transmission events leading to a
missing/dummy EDBS field in a given I/NAV word while a satellite is connected can be
any of the following:
 Late packets, i.e. arriving after the reception window is closed anywhere in the
chain.
 Corrupted packets.
 Lost packets.
We can characterise the affordable data transmission events as follows:
1 – SAER = (1- Perr)n (3.15)
75
where SAER is the System Authentication Error Rate, i.e. the rate of authentication errors
due to the system, Perr is the probability of error of an EDBS packet, and n is the number
of EDBS packets required for a successful authentication event. We propose the
following numbers for this preliminary analysis:
 SAER = 0.001, i.e. at most, one out of 1000 authentications can be wrong due to a
system issue, when a satellite is stably connected to ground.
 n = 5. There is an authentication verification every 10 seconds (following the
MAC-K section definition in other sections), involving 5 full 40-bit EDBS
packets in E1-B I/NAV, i.e. 5 packets need to be correctly received for a
successful authentication.
Table 5 presents a preliminary analysis of data losses in the transmission chain. They are
approximations of what data loss ratio would be tolerable to achieve a SAER in the order
of 0.001. The Space segment to GMS step loss is assumed to be 1 as it is considered that
the redundancy in the monitor network will allow the GMS to receive the navigation data
from all constellation satellites from at least one station.
Table 5 – NMA data losses vs. System Authentication Error Rate
Step (1 - Message loss) (1 - Message loss)

Space to GMS 1 1
GMS to NMA Module 0.9999 0.99999
NMA Module to GMS 0.9999 0.99999
GMS to Uplink Station 0.9999 0.99999
MEO Uplink 0.9999 0.99999
Total message correct transmission 0.99960006 0.999960001
(1-Perr)
1 – SAER 0.998001899 0.999800019
SAER 0.001998101 0.000199981
The table shows that, to achieve a SAER in the order of 1/1000 (0.001998 particularly),
all steps in the chain would require a data transmission success ratio of 99.99%, i.e. 1
faulty transmission out of 10,000.
3.7.4. Downlink Requirements
The proposed NMA can be defined as a data authentication service or a data and time-of-
arrival authentication service. In case of data authentication only, the service is provided
if the system data-authenticates four or more satellites within an I/NAV subframe (30
76
seconds), which can be achieved with one connected satellite in view. In case of data and
time-of-arrival authentication, the service is provided only if four connected satellites are
visible, although it is also useful to characterise the case where only three, or two
connected satellites are visible7. The Galileo services are foreseen to rely on 16
connected-to-ground satellites, and the system is currently dimensioned up to 20
connected satellites, though with the potential to increase downlink capabilities in the
future.
3.7.5. NMA of Data from Other GNSS
As already mentioned, the proposed architecture can authenticate GPS data. This may be
a useful feature, as users will very likely navigate with GPS and other GNSS. If GPS data
is not authenticated, the receivers cannot compute a data-authenticated GPS + Galileo
solution. Given that the proposed concept allows to data-authenticate up to 9 satellites
per connected satellite per I/NAV 30-second subframe, i.e. for maximum 27 satellites
every 30 seconds, there is enough bandwidth to provide data authentication for GPS, if
estimated convenient.
The process to data-authenticate GPS satellites is similar to that for Galileo satellites, as
all satellites for which data available can be treated similarly by the OS authentication
module. This is currently the case for the CS Demonstrator authentication solutions,
which already authenticated GPS data [27] [51]. As mentioned in 3.6.2.2 (ADKD field),
the "MAC-Info" header allows the system to authenticate other GNSS' data.
3.8. Design Trade-Offs

This section presents in detail some justification and trade-offs of some design aspects in
the proposed NMA solution. Some parts present some preliminary quantitative
assessments to justify the design decision.
7
In the absence of more E1 unpredictable signals in Galileo first generation, the case whereby a user receiver can
authenticate a position with less than 4 connected satellites by adding other constraints must be considered as well.
These constraints can relate to restrictions in the clock drift, restrictions on the position solution, or information those
from other sensors. Appendix D analyses some of these restrictions.
77
3.8.1. Cross-Authentication of Neighbouring Satellites
As mentioned before, a solution to Galileo uplink capability constraints is to design a

service whereby a satellite can transmit authentication information for other surrounding
satellites, as shown in Figure 25.
Auth(P1)
P1 P2 P3 P4 Auth(P2)
Auth(P3)
Auth(P4)
Rx
Figure 25 – Schematic of the cross-authentication approach
Figure 25 depicts four satellites, whereby satellites SV1-3 are transmitting standard
"plaintext" navigation data (P1, P2, P3), and satellite SV4 is transmitting authentication
information for all of them. Satellites 1-3 can be satellites from other GNSS, or satellites
that due to the system constraints cannot transmit authentication. The main differentiator
of the proposed concept with respect to standard authentication schemes relates to the
simultaneous authentication of several sources: In standard authentication schemes, there
is one source of information providing both the plaintext and the authentication data
(digital signature or MACs). By comparing both, this source can be authenticated.
Conversely, in the proposed concept, the senders of the plaintext and the sender of the
authentication information are different.
When a satellite cross-authenticates its nearest neighbours, only a subset of all satellites
authenticated may be visible to the end user, as shown in Figure 26. Taking any position
on earth, and the user masking angle α which describes the cone for which satellite
signals are able to reach the user (dashed spherical cap in the figure), we see a proportion
of out-of-view satellites that needs to be accounted for in the performance assessment.
78
Figure 26 – Out of view satellites in cross-authentication
Four satellites need to be data-authenticated for a data-authenticated PVT. This means

that they have to be visible and authenticated by a connected satellite within a 30-second
subframe. Following the NMA implementation proposal in this chapter, each connected
satellite can authenticate up to 9 satellites (3 MACs x 3 MAC-K sections). For this
analysis, we assume that, out of the 9, 1 MAC authenticates the ionosphere and the other
8 are for the satellite to authenticate itself and other 7 satellites, some of which may fall
out of the visibility cone of the user. The visible and authenticated satellites will be those
in the intersection of the user visibility cap and the satellite Sc cross-authentication cap,
as shown in Figure 26. Based on a Monte-Carlo simulation and assuming a uniform
satellite distribution in the caps.
Table 6 presents the percentage of out-of-view satellites for different number of MACs
per connected satellite and masking angle. We see that, for a masking angle of 25º, and 7
MACs, the average percentage is 45%, i.e. more than 3 visible satellites would be
authenticatable, even with only one satellite connected. If we have more connected
satellites in view, the average number of visible-and-connected satellites will be
increased. This means that the proposed approach of three MAC-K sections with three
10-bit MACs each seems adequate, even in degraded conditions. Other approaches
transmitting more MACs per subframe yield even better performance.
79
Table 6 - Percentage out-of-view satellites as a function of the number of MACs and the masking angle –
source: L. Bogaardt, EC.
MACs per connected satellite
1 2 3 4 5 6 7 8 9 10 11 12
5 10.8 15.9 19.7 22.8 25.7 28.3 30.6 32.9 35.1 37.2 39.3 41.2
10 12.6 18.1 22.1 25.5 28.6 31.4 33.9 36.5 38.9 41.2 43.4 45.5
15 14.4 20.1 24.4 28.0 31.3 34.3 37.2 39.9 42.5 45.0 47.4 49.7
20 16.4 22.6 27.3 31.3 34.9 38.2 41.4 44.4 47.2 49.9 52.5 55.0
Masking angle
25 17.8 24.5 29.7 34.0 38.0 41.6 45.0 48.2 51.2 54.1 56.8 59.4
30 19.2 27.1 33.0 37.8 42.4 46.4 50.1 53.5 56.8 59.9 62.7 65.4
35 20.8 29.6 36.0 41.4 46.3 50.6 54.5 58.1 61.6 64.7 67.6 70.3
40 23.3 32.9 40.1 46.3 51.6 56.2 60.5 64.3 67.8 70.9 73.5 75.8
45 26.2 36.4 44.7 51.5 57.2 62.1 66.5 70.3 73.6 76.2 78.4 80.2
50 28.8 40.7 50.7 58.3 64.5 69.6 73.9 77.1 79.7 81.7 83.4 84.8
3.8.2. Digital Signatures vs. Time-Delayed Asymmetry
To maximize the use of GNSS authentication, cryptographic key management should be

simplified as much as possible. This means that asymmetric schemes, whereby the user
receivers need only to possess a public key, are preferred to symmetric schemes, whereby
the user needs to store a secret key in a security module within the receiver. Asymmetric
schemes can be achieved mainly through two ways:
 Digital signatures, as RSA, DSA or ECDSA [10]. In these schemes, the satellites
transmit a digital signature of their navigation data, as described in [4].
 Delayed symmetric key delivery, as TESLA.
The main advantage of authentication through digital signatures is that there are known
methods and functions in the cryptographic standards that make them reliable for the
cryptographic community. The main disadvantage of authentication through digital
signatures, compared to time-delayed symmetric approaches, is the bandwidth required
to transmit the authentication information. For example, in order to transmit a digital
signature that guarantees a 112-bit to 128-bit level of security, signatures in the order of
80
500 bits are required (e.g. 512 bits for standard DSA, 128-bit security, or 466 bits for
112-bit security through ECDSA, as per [23]). Other disadvantages may include the
computational effort required per authentication, and the fact that some elliptic curves
may be subject to patent rights.
The main advantage of schemes based on the delayed delivery of a key used to generate a
previously sent authentication code, as TESLA, is the bandwidth reduction and the
tolerance to data loss. Their main disadvantages may be that they are not as standardized
and accepted by the cryptographic community as digital signatures are, and their design
must protect the user against more threats, as they rely on a coarse time synchronization
of the receiver with a time reference.
In any case, to authenticate the signal-in-space (SIS), the receiver must possess some
information that is certified as correct independently from the signal-in-space. This
means that even for TESLA approaches, the receiver must possess a public key to
authenticate the SIS. However, the frequency with which this public key is used, and the
bandwidth associated to this process, can be very low, if a TESLA approach is used.
Combining TESLA with cross-authentication maximises the advantages of TESLA wrt.
Digital signatures. For example:
 Assuming ECDSA digital signatures of 446 bits (112 symmetric security bits), 4
x 446 = 1784 bits would be required for the authentication of four satellites.
 Assuming TESLA keys of 112 bits and truncated MACs of 10 bits each, each
carrying a 16-bit MAC-info section, 4 x (10 + 16) + 112 = 216 bits would be
required for the authentication of four satellites. For the proposed 82-bit keys, the
total number is 186 bits.
3.8.3. Staggering of Authentication Events
The introduction of a time offset for subsets of satellites to stagger the authentication
verification times can improve authentication robustness. This has been already proposed
in [23]. In a fully synchronous scheme with a TBA of 10 seconds, all satellite
information would be authenticated every 10 seconds. However, receivers can be subject
to attacks during these 10 seconds, only noticing when the authentication verification is
performed. If the transmission of authentication information is offset for some satellites,
different subsets of satellites would be authenticated at different times, leading to a lower
TBA at user level. The Key-to-MAC allocation proposed in this scheme must allow
81
minimizing TBA at user level while not compromising other parameters, avoiding the
disclosure of the keys associated to MACs before or during the time the MACs are being
transmitted. If two subsets of satellites are transmitted at different times, and with the
currently proposed TBA of 10 seconds, the system could achieve an average user TBA of
5 seconds. Even if the satellites authenticated every 5 seconds (in average) are less than
four, as required to compute a position, a receiver can make use of the pseudorange
bounds for increasing its robustness, in combination with other previously authenticated
ranges. The main features of the proposed offsetting scheme are:
 MAC-K transmission is divided in 2 groups:

o SVID1 to SV15 transmit MAC-K sections allowing authentications at
seconds 0, 10 and 20 of the subframe.
o SVID16 to SVID308 transmit delayed MAC-K sections allowing
authentications at seconds 4, 14 and 24.
 MACs transmitted by SVID1 to SVID15 use the key transmitted from SVID1
(K1) (for clarity, the j sub-index representing the authentication frame is omitted
here). This key can also be recovered from a key from any satellite SVID2 to
SVID15 transmitted at the same time, or any key transmitted later.
 MACs transmitted by SVID16 to SVID30 use the key transmitted from SVID16
(K16). This key can also be recovered from a key from any satellite SVID16 to
SVID30 transmitted at the same time, or any key transmitted later.
Figure 27 presents this offsetting in MAC & key transmission scheme. It assumes that
the first key used in the subframe is K(m+1).
t [s] 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34
SV1 MACS(K(j,1)) K(j,1) MACS(K(j+1,1)) K(j+1,1) MACS(K(j+2,1)) K(j+2,1) …

SV2 MACS(K(j,1)) K(j,2) MACS(K(j+1,1)) K(j+1,2) MACS(K(j+2,1)) K(j+2,2)
… MACS(K(j,1)) K(j,...) MACS(K(j+1,1)) K(j+1,...) MACS(K(j+2,1)) K(j,...)
SV16 … MACS(K(j,16)) K(j,16) MACS(K(j+1,16)) K(j+1,16) MACS(K(j+2,16)) K(j+2,16)
… MACS(K(j,16)) K(j,...) MACS(K(j+1,16)) K(j+1,19) MACS(K(j+2,16)) K(j,...)
Auth. Events 6s 4s
Figure 27 – Key-to-MAC allocation and authentication offsetting
8
If higher SVIDs (SVID31, SVID32…) are used, they can be included in the second group.
82
The proposed scheme authenticates half of the satellites at 0, 10, and 20 seconds, and the
other half at 4, 14 and 24 seconds, leading to a user TBA between 4 and 6 seconds, with
an average time between authentications of 5 seconds. As shown in the figure, the
proposed scheme allows the simultaneous transmission of keys and MACs without
compromising the system, as the transmitted MACs always use a key that cannot be
computed from the keys under transmission.
3.8.4. Security Considerations
3.8.4.1 Single One-Way Chain
By using only one chain for all satellites, if the chain is compromised (i.e. the seed key
Kn is found), the whole system is compromised. However, if a one-way-per-satellite
chain is secure, a one-way-all-satellites chain shall be secure as well, due to the
following:
 The one-way chain security depends on the choice of the hash primitive and hash bit
output length. A cryptographically secure design choice for several chains shall be as
secure for a one-way all-satellite chain.
 For a certain chain interval, instead of protecting several seed keys Kn the system
shall protect only one Kn. The existence of a single vs. multiple parallel chains does
not change the system architecture, as the security measures of the system are similar.
 The choice for the hash function and the key length can be done with enough margins
to be considered secure for a much higher duration than the validity period of the
chain. For example, if a chain is valid for some months, the design can make it secure
for years. If, due to the higher criticality of compromising Kn, higher security
measures are proposed in the system, the validity period of each chain could be
shortened, or the key bit length increased, or other system-related measures could be
introduced, while maintaining the advantages of the current concept.
In summary, using a single chain for all satellites does not seem to reduce the security of
the system.
3.8.4.2 Key Length
As regards the symmetric key length used in the one-way chain, in correspondence with
[52] and [53], a key length of 80 bits is considered to be strong enough at the time of
writing the thesis for chain durations of up to one year. Robustness of this approach is
83
reinforced by including the GST (Galileo System Time) or any other unpredictable input
before the rook key is published, preventing pre-computation attacks. Longer keys may
be chosen during the lifetime of the system, if needed, and this NMA proposal allows
that. For example, if the key has to be guaranteed for e.g. 20 or 30 years, longer keys of
e.g. 128 bits would be recommended in the future [54]. To accommodate keys as short
as 80-bits in a standard one-way function as SHA-256 [55] or SHA-3 [56], the one-way
function needs to truncate the output of the hash function to the length of the key for
every iteration in the chain, as shown in Equation (3.8), but this does not reduce the
security of the system.
3.8.4.3 MAC Truncation and One-Way Function Truncation
For applications using large data bandwidths compared to the output sizes of
cryptographic algorithms, it is common to use MAC functions with output sizes of 80 or
even 160 bits, as is the case for some HMAC functions [12]. It should be noted, however,
that meaningful levels of security are achieved already with much shorter output sizes.
Given the low throughput available in GNSS signals, the lengths of the key and the
truncated MACs are very sensitive parameters. They drive the number of authentication
bits (NA), and therefore affect AER and TBA (the latter assuming a fixed bandwidth),
which are reflected in all other indicators. Therefore, their length should be reduced as
much as possible, while maintaining security to an acceptable level.
Given that GNSS are one-way systems, an attacker has no control over the message that
is authenticated (i.e. it cannot request a satellite to authenticate a given message), or the
key used, and the MAC and key transmission occurs with a certain cadence controlled by
the system specification. This yields some attacks impractical, permitting the use of very
short MAC tags. Assuming the MAC algorithm chosen behaves as a lookup table with a
message and a key as entries, and an n-bit random sequence as an output, an attacker
could only try to guess the MAC, which is very unlikely even for extremely truncated
MACs to very few bits [40] [45]. A MAC as short as 10 bits would be guessed with an
average probability of 0.097% (one time out of 1024), rendering the "MAC-guessing"
attack very impractical compared to a pure service denial by e.g. jamming the signal.
Some additional protections to this attack are:
84
 A receiver can accumulate two or more data authentications before accepting the data
as authenticated, in order to reduce the "MAC guessing" attack probability. Given the
very short TBAs and the possibility to cross-authenticate several satellites, this
permits data authentication with higher probabilities with a delay of few seconds, or
even without any delay. For example, Let us imagine a receiver that only uses a new
issue of data (IOD) which is authenticated twice, reducing the "MAC guessing"
probability to 1/(1024)2 and navigating in the meantime with the previous IOD,
which should minimally affect the navigation performance.
 The NMA solution could encrypt each MAC-Info section with the key later
delivered, making the "MAC guessing" attack more difficult and adding
unpredictability to the signals. This is left for further work beyond this thesis.
3.8.5. Receiver CPU Needs
To understand the computational power required in a single one-way chain scheme

where each satellite transmits a different key, state of the art SHA-2 implementations
have been looked at. It is claimed that around 11.5 processor cycles per byte are required
[57]. As a rough estimation, a 1GHz processor available in smartphones already would
need around 0.4 microseconds for one SHA-256 (i.e. 32 bytes) iteration. Other more
widespread references, as the benchmarks for Crypto++ libraries [58] suggest 15.8 cycles
per byte. For the rest of the analysis, and taking into account that the one-way function
may also involve the concatenation of a counter of time reference, and a truncation, one
microsecond per iteration is taken.
The CPU required for a single chain multiple-key TESLA approach, assuming 40 hash
iterations per authentication (allowing to cover 30+ satellites) would be therefore 40
microseconds for the whole set of satellites every TBA period, as the operation is
required only once for all satellites, which in absolute terms is very affordable for a
standard low-end processor.
As regards the CPU needed to verify a certain key K against an authenticated root key,
which is, for example, associated to a time 1 week before the applicability time of K,
assuming 40 hash iterations for a 10-second TBA period, it would require 7 days/week *
24 hours/day * 60 minutes/hour * 2 subframes/minute * 3 authentications/subframe * 40
hashes = 2419200 iterations, i.e. around 2.5 seconds, which is affordable taking into
account that this operation may be required very unfrequently. Therefore, the CPU
computing power required seems not a major driver. In standard 1-chain-per-sender
85
TESLA approach, the chain verification needs to be once computed for each satellite in
view, leading to lower computing power needs. However, this does not seem to represent
a huge difference in terms of computational feasibility for the receivers.
As a summary, this preliminary assessment shows that CPU power required for a single
one-way chain using different keys per satellite is affordable for the CPUs of present and
future GNSS terminals.
3.9. Performance Results

This section characterizes the proposed solution mainly in terms of AER, which affects
all the high-level indicators. It also assesses the impact of adding authentication in
accuracy, availability and time to fix. Introducing the cross-authentication approach
makes the characterization not as straightforward as if each satellite were self-
authenticating, and this leads to some extra explanations and indicators described below.
The performance is principally measured for data authentication. Considerations on anti-
replay protection are presented in section 3.10.
Except when noted, the performance analysis covers the 82-bit key, 10-bit MAC and
three MAC-K section proposal, with 1 MAC-K section every 10 seconds. We presented
other combinations for comparison in some of the results. The characterization below
excludes the processing of the H-K-root. It is assumed that the receiver has an authentic
K-root.
3.9.1. NMA Availability and AER
Availability is characterised under the following assumptions:
 At a given subframe, and given that connected satellites cross-authenticate non-

connected ones, the Galileo system is able to transmit the authentication information
to all Galileo satellites in view by any user with good visibility. This is a realistic
assumption taking into account that each connected satellite is able to transmit 9
MACs in a given subframe, i.e. a total of 18, 27 or 36 MACs, in the case of 2, 3 and 4
connected satellites visible respectively This allows the system to transmit
authentication for ionospheric parameters and ephemerides and clocks for all Galileo
satellites in view and potentially satellites from other constellations.
86
 Given that all data authentication information will be available, the availability will
depend on the percentage of this information that is demodulated correctly, which is
measured by AER as described below.
Table 7 presents the number of bits required with (NNA) and without (NN)
authentication in three cases:
 Ephemeris and clocks of one satellite are authenticated

 Ephemerides and clocks of four satellites and TOW are authenticated.
 Ephemerides and clocks of four satellites, TOW, BGD and ionospheric
information (Word 5) are authenticated.
Table 7 – Number of Bits Required With and Without Authentication
Indicator Number of bits Comments

1 Satellite, Ephemeris and Clock(Words 1-4) Authentication
NN1 NN = Number of Galileo I/NAV (Navigation) bits for ephemeris
and clock of one satellite (ADKD = 0).
It is considered that the required navigation bits to read are all in
words 1 to 4 minus the reserved (4) and spare bits (2), i.e. 128 * 4
– 6 = 506. Further optimisations (e.g. not reading word type or
IODnav, assuming that they are deterministic) are not considered.
506 They are in any case of little relevance for the calculations.
NA1 NA = Number of authentication bits to data-authenticate a satellite
108 MAC-info: 16 bits; MAC: 10 bits; Key: 82 bits
NNA1 NNA = Number of Navigation and Authentication bits required to
614 authenticate a satellite (only ephemeris and clock counted)
4Satellites, Ephemerides and Clocks (Words 1-4) Authentication
NN4 NN4 = Number of Galileo I/NAV (Navigation) bits for
ephemerides and clocks of four satellites. TOW bits are taken into
account (We assume WN is known). Therefore, NN4 = NN1*4 +
20, where 20 bits come from TOW.
Note also that GST need not be authenticated separately as the
time reference is verified as part of the TESLA authentication: if
2044 incorrect, the key vs. K-root verification will fail.
NA4 NA4 = Number of Authentication bits required to authenticate four
satellites (4 MACs of ADKD=0 type)
186 MAC-info: 4*16; MAC: 4*10; Key: 82
NNA4 NNA4 = Number of Navigation and Authentication bits required
to authenticate 4 satellites (only ephemerides, clocks and TOW
2230 counted)
4Satellites, Ephemerides and Clocks (Words 1-4) and Iono-BGD (Word 5) Authentication
NN4I NN4I = Number of Galileo I/NAV (Navigation) bits for
ephemerides and clocks of four satellites plus ionospheric
corrections, BGD and GST (105 bits (128 – 23 spare) from Word
2129 5).
NA4I NA4I = Number of Authentication bits required to authenticate
four satellites (4 MACs of ADKD=0 type) and "ionoBGD"
212 (ADKD=1)
87
MAC-info: 5*16; MAC: 5*10; Key: 82

NNA4I NNA4 = Number of Navigation and Authentication bits required
2341 to authenticate 4 satellites, iono/BGD corrections and GST.
The proposed bit numbers consider that CRC is not required, i.e. the receiver does not
reject a full page if CRC fails, as CRC data integrity provision can be replaced by data
authentication.
As shown in equation (3.2), AER depends on bit error rate (BER) and number of
navigation and authentication bits (NNA) to be demodulated. BER is defined in (3.3)
when no coding is applied. In the case of FEC (Forward Error Correction) convolutional
encoding of Galileo E1-B I/NAV, the BER can be bounded by the equations below [6],
assuming a soft decision Viterbi decoder and a static receiver under an AWGN channel
and stable PLL (Phase Locked Loop) tracking:
1
𝐵𝐸𝑅 ≤ ∙ (36𝐷10 + 21𝐷12 + 1404𝐷14 + 11633𝐷16 ) (3.16)
2
1
− 𝐶/𝑁0 (3.17)
𝐷=e 2R𝑏
where Rb is the number of bits per second. Figure 28 shows the BER versus carrier to
noise density ratio (C/N0) to give a sense of the reception conditions as per equations
(3.16) and (3.17). AER vs C/N0 is shown in Figure 29 for three cases, where ADKD is '0'
(eph&clk), '1' (ionoBGD) and '2' (SF).
Figure 28 – (Maximum) BER of Galileo I/NAV E1-B vs C/N0, AWGN channel
88
Figure 29 –AER vs C/N0 , ADKD=0 ('eph&clk', blue), 1 ('ionoBGD',red), 2 ('SF',green)
Figure 29 shows that, under these assumptions, very low AER values are obtained even
at low C/N0 values. For example, an AER of 1% is obtained with a C/N0 between
25dBHz and 26 dBHz for all cases. It also shows that below 24 dBHz NMA is barely
usable. The authentication performance is thus as good as expected and in line with the
I/NAV demodulation performance. A receiver able to demodulate the navigation data
should also authenticate with a reasonably high availability.
A receiver in an environment subject to fading may have problems to perform

authentication. However, it still can have a high availability by receiving the key from
the connected satellite with best visibility conditions, and successfully demodulate some
of the received MACs.
Figure 30 and Figure 31 show the different error rates for decoding just the navigation
data and for decoding the navigation plus authentication, assuming an AWGN channel.
FER-1SV represents the Frame Error Rate (FER) of decoding only the ephemeris and
clock of one satellite (words 1-4, NN=506 bits). AER-1SV represents the authentication
error rate of decoding the same bits plus the authentication (NNA=608 bits in total). A
similar reasoning applies to the 4SV and 4SVI cases. 4SV implies decoding and
authenticating the ephemeris and clock data, plus TOW, for four satellites (NN=2044;
NNA = 2230) and 4SVI implies decoding the same data as in the 4SV case plus an
89
additional word (Word 5) with the ionospheric and BGD corrections (NN=2129;
NNA=2341).
Figure 30 and Figure 31 show that there is very little difference in the error rate for the
receiver, with or without authentication, at a given C/N0. For example, to achieve the
same error rate with authentication, the signal should be only around 0.02 dB more
powerful than that without authentication. This power difference is reduced as more
satellites are authenticated, as only one key is necessary for all satellites.
Figure 30 – Error rates with and without authentication for 1 satellite, 4 satellites and 4 satellites and
'ionoBGD'
90
-2.1
10 FER-1SV
AER-1SV
FER-4SV
-2.3
10 AER-4SV
FER-4SVI
Error Rates AER-4SVI
-2.5
10
-2.7
10
-2.9
10
25.8 25.9 26 26.1 26.2 26.3
C/N0 [dBHz]
Figure 31 – Error rates with and without authentication for 1 satellite, 4 satellites and 4 satellites and
'ionoBGD' – Zoom around 26 dBHz C/N0 (ii)
Figure 31 shows, with some more resolution, the different error rates in different cases.
For example, when comparing the 4SVI case, FER at a C/N0 of 26 dBHz is below 10-2.28
or 0.0052, while AER is below 10-2.24, or 0.0058. This means that the degradation in
availability from decoding the navigation bits to decoding the navigation plus
authentication bits is very low.
In absolute terms, and assuming that a Galileo signal processed with a receiver with a
standard noise figure and in good visibility conditions is received with a C/N0 of around
45 dBHz, we can conclude that, even with a power loss of around -18 dB (from 45 dBHz
to 27 dBHz), data authentication can be performed at a very low error rate (AER for four
satellites is below 10-4). Therefore, and taking into account that all the data required for
navigation is authenticated, the degradation of adding the proposed NMA to accuracy
and availability standard navigation performance will be minimal (this does not consider
any performance alteration due to replay protection processing within the receiver).
3.9.1.1 AER and Availability Comparison of Different Authentication Solutions
As the AER result does not show in an evident way the advantages of the proposed
solution compared to other authentication solutions, Figure 32 presents the "four satellite
AER" for a given BER. It represents probability that four satellites are correctly
authenticated under a noisy channel (AWGN in this case), versus a given BER. For
clarity, only NA (as opposed to NNA) has been considered. This may represent the real
case whereby a receiver has already received the slow time varying navigation
91
information (ephemeris, ionospheric model, etc.), while it still requires successful

authentications to verify it is not under a replay attack. The following cases are
considered:
1) AER-NA-DS: 466-bit digital signature, one per satellite (112 security bits).
2) AE-NA-STD-TESLA: Standard TESLA approach, with 224-bit keys and 15-bit
truncated MACs (224 security bits).
3) AER-NA-1C-TESLA: 1-chain TESLA approach, with 224-bit keys and 15-bit
truncated MACs (224 security bits).
4) AER-NA-1C-TESLA-F: Current proposal, with 10-bit MACs and 82-bit keys (82
security bits).
Cases 1) and 2) have been already presented in [45] . Cases 2) and 3) use the same
security bits level but illustrate the improvement by using a single chain. Cases 3) and 4)
follow the same concept and illustrate the improvement by reducing the security bits
level and increasing the MAC truncation. As expected, a lower NA leads to a higher
availability of the service in equal conditions, which makes the service more robust. For
example, to achieve a 4-satellite NA-only AER of 10% a BER of 5*10-5 in case of a
digital signature is required, but only a BER of around 10-3 is required in the "fast
TESLA" case described in the current proposal.
Figure 32 – Four-satellite AER vs BER
92
3.9.1.2 Probabilistic Analysis of Authentication Error Rate including Multiple Satellites
and Multiple MAC and Key channels
The previous section has calculated the NMA performance based on per-satellite
indicators. However, for a user intending to authenticate its data, its performance will be
related to the fact that it has multiple channels to receive information that is transmitted
several times. This section quantifies data authentication error rate in this scenario, so
protection against replay attacks is not taken into account. This analysis relates to data
authentication only.
Let us now calculate the probability of authenticating a satellite over a given time
interval T. In order to authenticate a satellite, we need correct reception of the navigation,
the key and the MAC. Therefore, the probability of performing a successful
authentication depends on the probability of correctly decoding a MAC, a key and the
navigation data (if not previously available). Let us start calculating the probability of not
decoding successfully a MAC of a given satellite:
̅𝑀
̅̅̅𝑙 = 𝑀𝐹𝐸𝑅 𝑁𝑀𝑙·𝐶 (3.18)
𝑙
Where 𝑀𝐹𝐸𝑅 𝑙 is the frame error rate of the MAC information packet for satellite l, 𝑁𝑀𝑙
is the number of MACs of satellite l received per channel during T, and C is the number
of channels, i.e. the number of connected satellites. In other words, the probability of not
getting a MAC for satellite l during T is the probability of not receiving any of the MACs
for this satellite transmitted through the different channels.
We can now calculate the probability of not decoding successfully any key usable to
authenticate satellite l's MAC during T as follows:
N𝑀𝐾 𝐶
1
̅=[
𝐾 ∑ (𝐾𝐹𝐸𝑅 )𝑖 ] (3.19)
N𝑀𝐾
𝑖=1
where N𝑀𝐾 is the number of MAC-K sections in T, 𝐾𝐹𝐸𝑅 is the frame error rate of the key
packet (i.e. the key, as no further information is transmitted), and C is the number of
channels.
The formula can be explained with an example. Let us suppose that T is 30 seconds (1
subframe), and N𝑀𝐾 is three, each MAC-K which one key. If satellite l's MAC was
93
received in the first MAC-K section, then it can be authenticated with any of the three
keys that will come during T. The probability of not receiving successfully any valid key
is therefore (𝐾𝐹𝐸𝑅 )3. If satellite l's MAC was received in the 2nd MAC-K section, it is
(𝐾𝐹𝐸𝑅 )2, and if it were in the first section, it is 𝐾𝐹𝐸𝑅 . As we do not know a priori to
which section the MAC belongs, all sections are treated with the same probability 1/NMK
, or 0.33. The sum of all cases is what Equation (3.19) provides.
In addition to the error rate in the MAC and the key, we need to account for the error rate
in the navigation reception:
̅̅̅
𝑁𝑙 = 𝑁𝐹𝐸𝑅𝑙 (3.20)
Where 𝑁𝐹𝐸𝑅𝑙 is the navigation frame error rate for satellite l. We are assume that it is
transmitted once every T, and only from each satellite. Otherwise, a power factor would
be applied as in case of the MAC and the key.
As mentioned before, we need correct navigation, key and MAC to successfully

authenticate a satellite. Therefore, the probability of successfully authenticating satellite l
is:
𝑆𝑙 = 𝑀𝑙 𝐾𝑁𝑙 = (1 − ̅𝑀
̅̅̅𝑙 )(1 − 𝐾
̅ )(1 − ̅̅̅
𝑁𝑙 ) (3.21)
To calculate the probability of authenticating four satellites, we can use the probability
function of a binomial distribution.
𝑛
𝑝(𝑋 = 𝑘) = ( ) 𝑝𝑘 𝑞𝑛−𝑘 (3.22)
𝑘
where 𝑝(𝑋 = 𝑘) is the probability that variable X gets k successes after n experiments,
being 𝑝 the probability of success, and q the probability of failure. In our case, we need
to compute (𝑋 ≤ 𝑘) where p is 𝑆̅ i.e. the probability of a failed satellite authentication,
𝑆̅ = 1 − 𝑆; and k = L – 4, L being the total number of satellites in view. We remove the
sub-index l for simplicity, assuming the same probability for all satellites.
In other words, we compute the cumulative probability of these cases: no satellite failed
(𝐹 = 0), one satellite failed (𝐹 = 1), two satellites failed, etc., until all-minus-four
satellites failed. In all these cases, there is a data-authenticated PVT.
94
𝑝(𝐴𝑈𝑇𝐻𝑃𝑉𝑇) = 𝑝(𝐹 ≤ 𝐿 − 4) =
(3.23)
𝑝(𝐹 = 0) + 𝑝(𝐹 = 1) + ⋯ + 𝑝(𝐹 = 𝐿 − 4)
Table 8 presents the NMA performance scenarios and associated parameters.
Table 8 – NMA Performance Scenarios and Parameters
Parameters vs. Nominal-2C Nominal-1C Worst Case

Scenarios
T 30s 30s 30s
C 2 1 1
NMK 3 3 1
NM,l 1 1 1
Key Size 82 bits 82 bits 128 bits
MAC & MAC Info 26 bits 26 bits 36 bits
Size
Navigation Size (NN) 506 bits 506 bits 506 bits
Here are some considerations about the scenario parameters:
 T = 30 seconds implies one I/NAV subframe.

 C = 2, is considered a moderately pessimistic assumption, given that between 15
to 20 connected satellites can be expected (i.e. between half and 2/3 of a full 30-
satellite constellation, provided a reasonable user visibility, system availability
and system uplink plan). Anyway, the even more pessimistic case of C = 1 is also
analysed.
 The nominal scenario is related to the 82-bit key, 10-bit MAC case with 3 MAC-
K sections already presented. The worst-case scenario takes the longest keys and
MACs (128 bits and 20 bits, respectively).
 The worst-case scenario implies that only one key is transmitted every 30
seconds. In this scenario, we assume 9 MACs are transmitted as well, which is a
correct assumption taking into account the available bandwidth (floor((480 –
128)/36=9).
 NM,l = 1 implies that, for each satellite in view, the system transmits its MAC at
least once per channel every T. Given that there are 9 MACs per channel in all
cases, and only the nearest neighbour satellites are transmitted, it seems a
reasonable assumption that all satellites in view are nearest neighbours of the
connected satellites (more details about the validity of this assumption in practice
are given in section 3.8.1), and at least one MAC is received.
95
The following plots in Figure 33 present some results for different scenarios: Nominal-
2C (top), Nominal-1C (middle) and Worst-Case (bottom).
96
Figure 33 – Probability of successfully authenticating one satellite (S) (i.e. 1 – AER) when only the MAC &
key is required (blue), and when the MAC & key & navigation is required (red), vs. the probability of
successful reception of navigation information (black). Top: Nominal-2C Scenario; Middle: Nominal-1C
Scenario; Bottom: Worst-Case Scenario
Figure 33 above shows an interesting result: in the Nominal-2C scenario, adding the
requirement to receive the MAC and key bits and authenticating a satellite does not
decrease the probability of successful demodulation of navigation. If the navigation has
been demodulated already, which may be often the case (let us recall that it is updated
only every about one to 2 hours), the probability of authentication (S when ̅̅̅
𝑁𝑙 = 0) is
high. Even at very bad bit error rates, as 0.01, S remains around 90%. In the case of one
channel, the degradation is still very low. In the worst-case scenario, an appreciable
difference is observed between receiving navigation only and navigation +
authentication, although the difference is not dramatic. For example, with a BER of
0.001, the probability of navigation reception is around 0.6, while it is 0.5 for navigation
+ authentication. We can also see that the probability of authentication only (S when
̅̅̅
𝑁𝑙 = 0) is significantly degraded with respect to the standard case. E.g. at a BER of
0.001, the probability of authentication is 0.2 in the worst-case scenario and 0.85 in the
Nominal-2C scenario.
In Figure 34 we characterise the performance of authenticated PVT with four or more

satellites, as per Equation (3.23), for the three scenarios. The plots show that, in the
Nominal-2C case, even at BERs as high as 0.01, if the receiver already has the navigation
data, it will be able to compute a data-authenticated position, e.g. with a probability
higher than 95% with 6 satellites in view. The plots show that, the more satellites in
97
view, the more likely to authenticate, as one could expect from (3.23). Another way to
look at it is that if there are more satellites in view, even at the same number of channels,
there are more combinations of receivable MACs leading to a successful data
authentication.
98
Figure 34 – Probability of data authenticated position (PVT) vs. BER, for 4 to 9 satellites in view, based on S
without navigation reception. Top: Nominal-2C Scenario; Middle: Nominal-1C Scenario; Bottom: Worst
Case Scenario
Figure 35 shows the authentication probabilities when the navigation has to be received
as well. It shows that, due to the need to receive the navigation bits, the probability of
data-authenticated PVT is highly degraded. The figure does not show the difference with
the navigation-only (i.e. not authentication) probability, but we can infer from the
previous results that it will be almost the same.
99
Figure 35 – Probability of data authenticated position (PVT) vs. BER, for 4 to 9 satellites in view, based on S
including navigation reception. Top: Nominal-2C Scenario; Middle: Nominal-1C Scenario; Bottom: Worst
Case Scenario
The results show that adding the proposed data authentication scheme does not generally
degrade the navigation availability performance. It may marginally reduce availability in
some cases and, only in some extreme cases, it will have an impact in navigation
performance.
3.9.2. Time To First Authenticated Fix
Time To First Authenticated Fix reflects the time a receiver takes to calculate a position
fix based on at least four data-authenticated satellites. Table 9 presents TTFF (i.e. time to
100
first fix with no authentication, in standard conditions) versus TTFAF in different
receiver start-up cases. The analysis considers that K-root can be received in 3
subframes, which seems a realistic, if not conservative, assumption in view of Figure 19.
The definition of factory, cold, warm and hot start is based on [5] and extended for
authentication. Table 9 shows that, except for a very specific case ("Cold Start, No K-
root", which should not occur often, if it occurs at all), time to fix will not be degraded by
adding authentication.
As TBA is 10s, and therefore much lower than the time to get a full subframe (30s), and
taking into account the slight degradation in error rates, the difference between TTFF and
TTFAF is negligible, except in two cases: when the receiver needs to receive the signed
K-root at start-up, which is foreseen to occur very seldom; and when the receiver
synchronization is so loose that it needs to process a 'slow MAC'.
101
Table 9 – Data Authentication in different Acquisition Modes
Almanacs K-root P0 T0 (<1 TOW Ephemerides Data- Comments and Assumptions TTFF; TTFAF
(<100km min) & clocks authenticated
error) Ephemerides
Factory Start N N N N N N N In this case, all K-root and MAC-K

authentication information is received in
parallel to the Almanac within the I/NAV TTFF = TTFAF≈ 15 min
Frame (720s), so authentication does not
degrade TTFAF wrt. TTFF.
Signal Acquisition lasts 2.5 min approx.
Cold Start, No K-root Y N N N N N N This case should not occur if a receiver is

switched on regularly (e.g. once per week).
TTFF ≈ 1 min
Signal Acquisition lasts 30 seconds.
TTFAF ≈ 2 min
K-root received in 3 subframes.
Cold Start, K-root Y Y N N N N N In this case, all MAC-K authentication

information is received within an I/NAV
subframe, so authentication does not TTFAF = TTFF ≈ 1 min
degrade TTFAF wrt. TTFF.
Warm Start Y Y Y Y N N N The receiver has an approximate position

to reduce acquisition search space. No
difference in data demodulation process TTFAF = TTFF ≈ 30 seconds
wrt. cold start, K-root.
Hot Start Y Y Y Y Y Y Y The receiver navigates with the previously

authenticated ephemeris.
TTFAF = TTFF ≈ 1 second
If anti-replay is considered, TBA (10
seconds) should be waited for a new
authentication event.
102
3.9.3. Performance Assessment in Urban Environments – A Practical Case
The purpose of this section is to generally characterise the NMA performance of the proposed
approach in low visibility conditions. The analysis uses a "simplified LMS (Land Mobile
Satellite)" model, in which, instead of simulating fading events, we add a C/N0 degradation
and a masking angle to remove satellites from the visibility field 9 on an AWGN channel.
With the Galileo I/NAV convolutional encoding and interleaving, a BER as bad as 0.01 is
obtained at a C/N0 between 23 and 24 dBHz (i.e. 20 dB below the standard 44-45 dBHz open-
sky reception conditions). There may be differences between an AWGN channel and a LMS
channel based on statistical models as the Jahn model [59]. However, this is compensated by
the C/N0 reduction and masking proposed. The interleaving property of the I/NAV message
makes data more resilient to temporary busts of corrupted bits due to fading as occurs in LMS
channels. The masking angles are defined in Table 10.
Table 10 – Masking vs. Azimuth and elevation – Urban Environment
Zone Elevation range Azimuth range Signal

Attenuation
A 0-5 Degrees 0 - 360 Degrees Masked
B 5 - 30 Degrees 210 - 330 Degrees Masked
C 5 - 30 Degrees 30 - 150 Degrees Masked
Background Area out of Zones A, B, C 0
9
Based on LMS model proposed by Thales Alenia Space France for the CESAR project (EC internal documentation).
103
Figure 36 – Masking vs. azimuth and elevation sky plot - Urban Environment, using GNSS Planning Online tool
[60]
Figure 36 shows the elevation and azimuth mask in a sky plot. The C/N0 is degraded as per
Table 11:
Table 11 – C/N0 reduction vs. elevation
Environment Name Revised C/N0 C/N0 [dBHz]

drop [dB]
el > 70° -16 28 dBHz
30° < el < 70° -17 27 dBHz
15° < el < 30° -19 25 dBHz
el < 15° -21 23 dBHz
In the original model, the degradation was 6, 7, 9 and 11 dB, i.e. 10 dB less. However, we
already know that in the region of 30 dBHz or more, the Galileo I/NAV BER is low (at least
with the currently used AWGN model) and error rates will be negligible, as shown in Figure
28. To worsen the conditions, the delta C/N0 has been reduced by 10 extra dB to what was
originally proposed.
To select a representative case for Galileo FOC, the GPS constellation has used as a
reference. Here are the parameters used for the analysis:
104
 Position: 48.8567° N, 2.3508° E. The location of Paris has been selected for the
analysis, as a city with average latitude and longitude within Europe, and therefore
representative.
 GPS constellation has been selected as a reference. Out of the 31 operational
satellites, satellite 'G06' has been taken out to match the number of 30 expected
Galileo satellites (24 in operational slots plus 6 spares). The choice of satellite 'G06' is
because at the time of this writing, its almanac is outdated and its orbit seems the
furthest from nominal. Its RAAN is -67º, between the RAANs of -100º and -40º of the
nominal orbital planes. Figure 37 shows the satellites visible over the 24-hour ground
track period.
Figure 37 – Satellite view, 48.8567° N, 2.3508° E, 30 GPS satellites, 1/4/2015, using GNSS Planning Online tool
[60]
 We select an instant in which six satellites are in view with an average geometry (note
that the geometry does not have a significant impact in the analysis but it affects the
C/N0, as it depends on the elevation).
Figure 38 – Sky plot at 1/4/2015, 10:20:00, using GNSS Planning Online tool [60]
105
3.9.4. Assumptions for satellites transmitting NMA
We assume around 2/3 and 4/5 of the 24 operational satellites (i.e. around ½ and a 2/3 of the
full 30-satellite constellation) to be connected, i.e. between around 15 and 20 satellites
connected. For our case, we assume three channels, i.e. three satellites are connected. We
assume they are those at the worse elevations. We therefore consider satellite 2, satellite 7
and satellite 23 as connected. We can assume a C/N0 in good receiving conditions and
including the noise added by the receiver to be 44 dBHz [5] (Ch.6, table 6.3). Their
elevations and C/N0 according to the model are:
Table 12 – Revised C/N0 of satellites transmitting NMA
Elevation Revised C/N0 drop C/N0
Sat 2 33º -17 dB 27 dBHz
3.9.5. Assumptions for satellite MAC sequence
The assumptions for the MAC sequence transmitted in the MAC-K section are based on the
proposal of 82-bit keys and 10-bit MACs. Every 30 seconds, 9 unique MACs per connected
satellite are transmitted. The 9 MAC sequence includes:
 8 MACs with ephemeris and clocks authentication for 8 satellites. These satellites will
be the closest 8 in distance (including one constellation only).
 One MAC with ionospheric corrections 67% of the time, and a "slow MAC" the
remaining 33%.
 Out of the satellites cross-authenticated, we assume that 50% are discarded as they
belong to out-of-view satellites. We also assume that all satellites in view are always
part of the 9 satellites authenticated per channel. These assumptions seem correct as
demonstrated in section 3.8.1.
 We also assume that the connected satellites authenticate themselves but do not
authenticate other connected satellites.
 The receiver is loosely synchronised to less than 10 seconds error to GST. Therefore,
the 'slow MAC' is not needed. IonoBGD MACs are also ignored in the calculation
assuming they are not needed.
106
Based on these assumptions, we fix the 30-s subframe sequence as per the Table 13.
Table 13 – MAC-K sequence from 3 connected satellites and packet error rates (err. Probabilities)
CN0 [dBHz] Sat 2 IonoBGD-1 S2-1 S10-1 K11 S4-2 K21 S13-2 K31
27 Error probabilities 9.432E-07 9.432E-07 2.975E-06 9.432E-07 2.975E-06 9.432E-07 2.975E-06
Sat 7 IonoBGD-2 S7-1 K12 S4-1 S13-1 K22 S10-3 K32
Sat 23 Slow MAC S23-1 S10-2 K13 S4-3 K23 S13-3 K33
Table 13 has been generated taking as inputs the packet (MAC, key) lengths, the C/N0, and
the signal properties to calculate the BER. Based on that, Table 14 shows the probability of
authentication of each transmitted MAC for each satellite.
Table 14 – Probability of authentication of each of the MACs for each satellite during a subframe
Satellites/MACs S2-1
S2 9.432E-07
S7-1
S7 2.188E-03
S23-1
S23 9.432E-07
S4-1 S4-2 S4-3
S4 2.188E-03 9.432E-07 9.432E-07
S13-1 S13-2 S13-3
S13 2.188E-03 9.432E-07 9.432E-07
S10-1 S10-2 S10-3
S10 9.432E-07 9.432E-07 2.188E-03
As mentioned, the proposed algorithm does not cross-authenticate connected satellites. Due
to that, the MACs from connected satellites at low elevations are not repeated, making the
authentication of low-elevation connected satellites difficult. Perhaps this algorithm should
be revisited, allowing connected satellites to cross-authenticate other connected satellites.
In most cases, the driver for the MAC authentication probability is the MAC reception, and
not the key reception. This is due to the single one-way chain concept. Even for MACs in the
107
last MAC-K section (e.g. S4-3, S13-3), the probability of not getting the key is the
probability of not getting any key from the last MAC-K section, i.e. (2.975*10-6)2* 6.883*10-
3
, i.e. around 6*10-14.
In any case, to prove that the Authentication Error Rate of 4 satellites is close to zero,
assuming the navigation is already present, we can again take a pessimistic scenario and
compute the 𝑝(𝐴𝑈𝑇𝐻𝑃𝑉𝑇) as per (3.28). Assuming that the failure probability for all
satellites is the highest one, i.e. that of satellite 7 (0.002188, and which is due to an artificial
bottleneck due to the algorithm proposed), 𝑝(𝐴𝑈𝑇𝐻𝑃𝑉𝑇) is a cumulative binomial
distribution of (𝑋 ≤ 𝐾), K = 2, N = 6 and p = 0.002188. The result is as low as 0.999999792,
i.e. 1 – 2*107. Therefore, with 6 satellites in view and the worst three connected satellites, the
probability of not getting authentication information for a four-satellite PVT is very low,
which means that data authentication should be available in urban environments under the
conditions here presented, or similar conditions.
3.10. Signal Unpredictability and Anti-Replay Protection

This section characterises in detail the signal unpredictability of the proposed solution mainly
in terms of USR and MPT, and characterises the level of anti-replay protection offered.
Maximum Predictable Time depends on how the encoding and interleaving process of the
Galileo I/NAV message encodes the unpredictable bits in symbols (some of which are
predictable and some of which not) and spreads them across the transmitted message. It
comes out that all of the unpredictable symbols of every 2-second word are transmitted in a
period of 0.4 to 0.5 seconds, leaving the remaining 1.6 to 1.5 seconds fully predictable. As a
reference, we take a MPT of 1.6 seconds.
This is based on the assumption that every 40-bit "Reserved 1" field contains unpredictable
information. As every "Reserved 1" field contains 32 bits of a MAC-K section, and the
longest predictable interval of a MAC-K section is the 16 bits of the MAC-info field, all the
"Reserved 1" fields contain some unpredictable symbols.
Unpredictable Symbol Ratio is calculated under the assumption that all symbols are
predictable except the MAC and the key bits, excluding some last bits of the key to avoid
attacks whereby the last key bits are deduced and rebroadcast. The number of unpredictable
symbols can be determined as follows:
108
(𝐾𝑙𝑒𝑛 − 𝐾𝑝𝑟𝑒𝑑 + 𝑁𝑀𝐴𝐶 𝑀𝐴𝐶𝑙𝑒𝑛 )𝑁𝑀𝐴𝐶𝐾
𝑈𝑆𝑅 = (3.24)
𝑁𝑆𝐹
where 𝐾𝑙𝑒𝑛 is the key length (82 bits), 𝐾𝑝𝑟𝑒𝑑 is the number of last bits of the key considered
predictable, 𝑁𝑀𝐴𝐶 is the number of MACs in a MAC-K section (3), 𝑀𝐴𝐶𝑙𝑒𝑛 is truncated
MAC length (10 bits), 𝑁𝑀𝐴𝐶𝐾 is the number of MAC-K sections in a subframe (3 in our
proposal) and 𝑁𝑆𝐹 is the total number of symbols in a given time period in which the
message structure is repeated (I/NAV subframe).
3.10.1. USR and Predictability of the Last Bits of the Key
When assessing USR, one has to take into account that some of the a-priori unpredictable bits
may be guessed by an attacker, as explained below, and in that case those bits become
predictable. This attack seems unlikely, as it would not affect the data authentication but
would just give a little more freedom for performing a replay. However, it has to be taken
into account to characterise the solution.
The bit unpredictability is based on the MAC and key sections. We can consider the full
MAC bits unpredictable, as having knowledge of the first bits does not give any advantage
for the last bits. However, this is not the case for the key bits.
Let us assume that a key n bits long is being transmitted. At a given time, the key has already
transmitted n-j bits, and only j remain (the meaning of j here is not related to the
identification of an authentication frame). We also know that between the transmission of
each new unpredictable key symbol, an attacker can 'guess' the remaining symbols by
performing a brute force attack, in which all possible combinations of the remaining bits are
tested by performing the chain function F, until the correct one is found.
For example, when j is 3, assuming conservatively an average unpredictable symbol ratio of

1/24 ms (round(40/250)), an attacker would have 24 ms to test all the possible combinations
(23 in this case) that yield the correct key, and would guess the remaining bits, making them
predictable.
We can calculate a boundary on how many bits are considered predictable as follows:
 We assume a time per iteration of the chain function F for the attacker. We assume a
standard CPU multiplied by a coefficient expressing how more powerful the attacker's
109
CPU will be, which depends on how many resources an attacker will devote for this
attack. We must recall that the asset to protect is just the unpredictability of a few
symbols.
 We define a tolerable probability of success of the attack.
 We evaluate when the total time for achieving the tolerable success probability
exceeds the time between unpredictable symbols.
The equations below express the previous bullets in mathematical terms:
𝜏𝑗 = 2𝑗 𝜏𝑖𝑡𝑒𝑟 𝑃𝑠𝑢𝑐𝑐𝑒𝑠𝑠 (3.25)
𝜏𝑗 > 𝜏𝐵𝑈𝑆 (3.26)
where 𝜏𝑗 is the time an attacker will require to guess the remaining j bits of the key with a
probability of success 𝑃𝑠𝑢𝑐𝑐𝑒𝑠𝑠 , provided that it takes 𝜏𝑖𝑡𝑒𝑟 in one iteration. 𝑃𝑠𝑢𝑐𝑐𝑒𝑠𝑠 captures
the fact that, if the system wants to protect against attacks with a 100% success rate, then
attackers will need to test all combinations. If attacks testing fewer combinations and
therefore giving a lower success rate, are considered still harmful, then 𝜏𝑗 will be shorter.
𝜏𝐵𝑈𝑆 expresses the time between unpredictable symbols, so we should discard the bits that
allow combinations solvable before the next symbol, i.e. before 𝜏𝐵𝑈𝑆 . Figure 39 compares
𝜏𝑖𝑡𝑒𝑟 with 𝜏𝐵𝑈𝑆 , assuming:
 0.01 microseconds per SHA byte iteration (i.e. around 50-100 times faster than a
standard current processor)
 A 10% maximum tolerable probability of success.
 An average of one unpredictable symbol out of 6 (i.e. 24 milliseconds time for an
attacker to perform the attack).
110
Figure 39 – Time to compute the remaining bits of a key (𝜏𝑗 ) compared to the time between unpredictable symbols
(𝜏𝐵𝑈𝑆 )
Under these assumptions, it seems prudent to consider a value of j of 20 bits. That means that
we will not consider the last 20 bits unpredictable for computing the USR. In the following
sections, the number of predictable bits of the key will be defined as Kpred.
Applying Equation (3.24), that gives a total of 276 unpredictable symbols per subframe out of
a total of 7500 symbols , i.e. an USR of 3.68%.That means that, in average, there are 9.2
symbols per second that are unpredictable, from which an anti-replay test statistic could be
derived. In reality, and according to the Galileo I/NAV convolutional coding and interleaving
scheme, all unpredictable symbols are concentrated every other second.
3.10.2. Symbol Unpredictability and MPT after Encoding and Interleaving
As shown in Figure 16, NMA is embedded in the "Reserved 1" field of each I/NAV word. As
we want to increase signal unpredictability to protect against replay attacks, we have to
analyse how 40 unpredictable bits are encoded into 80 unpredictable and predictable
symbols. It is necessary to determine which symbols are considered unpredictable, and which
not, and how the encoding and interleaving affects USR and MPT. One can anticipate that the
entropy of the signal will not be increased by coding, i.e. that if there are 40 unpredictable
bits, which are coded into 80 symbols, only 40 of them will be unpredictable. However, in
order to understand their place in the symbol stream, a deeper analysis is performed in this
section.
Galileo signals, and in particular the I/NAV message, are convolutionally encoded with the
following data coding parameters [12]:
 Coding rate: ½
111
 Coding scheme: convolutional
 Constraint length: 7
 Generator Polynomials (in octal10): G1=171o ; G2 = 133o
 Encoding sequence: G1, then G2.
Each bit is encoded into two symbols (i.e. coded bits), which depend on the present and past
bits according to the scheme in Figure 40. Further details on convolutional coding and
interleaving can be found in [61], particularly in Ch.8, S. 8.8.2.
Figure 40 – Galileo I/NAV convolutional encoding [12]
In addition to the encoding, the symbols are interleaved to add robustness against temporary
fading effects in the channel. Galileo I/NAV interleaving consists of a block interleaver of
size 240, i.e. all the symbols in an I/NAV word except the synchronisation sequence, and
dimensions of 30 columns x 8 rows. That means that the 240 symbols are written, column
after column, in 30 columns of 8 symbols each, and read row by row, so the symbols are
scattered across the 240-symbol packet. To decode the bits from the symbols, most receivers
use a Viterbi decoder [62].
The 40 "Reserved 1" bits are those located between bit 19 and bit 58, both included. This
means that symbols 37 to symbol 128, both included, contain "Reserved 1" bits.
Each new unpredictable bit will lead to two new symbols. If the symbols were not
interleaved, the first (from G1) would be unpredictable, and the second (from G2) would not.
The 240-bit stream will look as in Table 15 in the interleaver:
Table 15 – I/NAV 240-symbol unpredictability before interleaving. Green: unpredictable symbols. Yellow:
predictable symbols based on unpredictable bits. White: predictable symbols based on predictable bits
10
For example, 171o = 1111001 in binary.
112
1 9 17 25 33 41 49 57 65 73 81 89 97 105 113 121 129 137 145 153 161 169 177 185 193 201 209 217 225 233
2 10 18 26 34 42 50 58 66 74 82 90 98 106 114 122 130 138 146 154 162 170 178 186 194 202 210 218 226 234
3 11 19 27 35 43 51 59 67 75 83 91 99 107 115 123 131 139 147 155 163 171 179 187 195 203 211 219 227 235
4 12 20 28 36 44 52 60 68 76 84 92 100 108 116 124 132 140 148 156 164 172 180 188 196 204 212 220 228 236
5 13 21 29 37 45 53 61 69 77 85 93 101 109 117 125 133 141 149 157 165 173 181 189 197 205 213 221 229 237
6 14 22 30 38 46 54 62 70 78 86 94 102 110 118 126 134 142 150 158 166 174 182 190 198 206 214 222 230 238
7 15 23 31 39 47 55 63 71 79 87 95 103 111 119 127 135 143 151 159 167 175 183 191 199 207 215 223 231 239
8 16 24 32 40 48 56 64 72 80 88 96 104 112 120 128 136 144 152 160 168 176 184 192 200 208 216 224 232 240
After the interleaver, the sequential dependency between unpredictable symbols and bits is
broken, so it is not a priori obvious which symbols based on unpredictable bits, are indeed
unpredictable, and which not. However, if a receiver wants to perform a test statistic based on
the unpredictable symbols to protect against replay attacks, it must know which symbols are
considered unpredictable. The post-interleaving symbol unpredictability has been determined
as follows:
 The unpredictable bits are considered as unknowns.

 Every time a new symbol is received, which depends on one or several unpredictable
bits, a new equation is added to a system. This equation adds the new unpredictable
bits as new unknowns.
 When the number of equations equals the number of unknowns (i.e. when the number
of already received unpredictable symbols equals the number of unpredictable bits
involved in those symbols), the system can be solved. If all the unpredictable bits are
in the system, then the stream will not be predictable anymore.
Table 16 – I/NAV 240-symbol unpredictability before interleaving considering 8 H-K-root bits predictable.
1 9 17 25 33 41 49 57 65 73 81 89 97 105 113 121 129 137 145 153 161 169 177 185 193 201 209 217 225 233
2 10 18 26 34 42 50 58 66 74 82 90 98 106 114 122 130 138 146 154 162 170 178 186 194 202 210 218 226 234
3 11 19 27 35 43 51 59 67 75 83 91 99 107 115 123 131 139 147 155 163 171 179 187 195 203 211 219 227 235
4 12 20 28 36 44 52 60 68 76 84 92 100 108 116 124 132 140 148 156 164 172 180 188 196 204 212 220 228 236
5 13 21 29 37 45 53 61 69 77 85 93 101 109 117 125 133 141 149 157 165 173 181 189 197 205 213 221 229 237
6 14 22 30 38 46 54 62 70 78 86 94 102 110 118 126 134 142 150 158 166 174 182 190 198 206 214 222 230 238
7 15 23 31 39 47 55 63 71 79 87 95 103 111 119 127 135 143 151 159 167 175 183 191 199 207 215 223 231 239
8 16 24 32 40 48 56 64 72 80 88 96 104 112 120 128 136 144 152 160 168 176 184 192 200 208 216 224 232 240
The results of the algorithm are presented in the capture below (Table 17), for the case in
which the last 32 out of the 40 "Reserved 1" bits are considered unpredictable, consistently
with the current proposal, in which the first 8 bits are devoted to the H-K-root section and are
considered predictable. That means that the first unpredictable symbol is the 8th one (57) and
not the 6th one (41), as shown in Table 16.
113
Table 17 – Results of unpredictability analysis after I/NAV convolutional encoding and interleaving
Symbol Position | Nb. Equations | Nb. Unknowns | 2^(U-E)

8 1 3 4
9 2 7 32
10 3 11 256
11 4 15 2048
12 5 19 16384
13 6 23 131072
14 7 27 1048576
15 8 31 8388608
16 9 32 8388608
38 10 32 4194304
39 11 32 2097152
40 12 32 1048576
41 13 32 524288
42 14 32 262144
43 15 32 131072
44 16 32 65536
45 17 32 32768
46 18 32 16384
68 19 32 8192
69 20 32 4096
70 21 32 2048
71 22 32 1024
72 23 32 512
73 24 32 256
74 25 32 128
75 26 32 64
76 27 32 32
98 28 32 16
99 29 32 8
100 30 32 4
101 31 32 2
102 32 32 1
** MAXIMUM PREDICTABLE TIME [ms]:1620
** UNPREDICTABLE SYMBOL RATIO (Ubps):32/(250+250)=0.065306
The first column shows the position of unpredictable symbols, which can be used by the
receiver to protect against replay attacks. Then the results present the total number of
equations every time a new unpredictable symbol (equation) is found. The next column is the
number of unknowns (unpredictable bits depending on received symbols), and the last
column presents the minimum number of possibilities that an attacker should search.
The results also present the maximum predictable time at the bottom, i.e. the time between
the last unpredictable symbol of an I/NAV word, and the first of the next word. The
algorithm also presents the number of possibilities (2^(unknowns – equations)), to assess the
risk that a spoofer would 'guess' the unpredictable symbols. We see that, for most of the
unpredictable symbols, the number of possibilities is very high. Therefore, it is not
considered worth to discard any unpredictable symbol from the test statistic. The MPT result
is 1.620 seconds.
We can see that, after the symbol in position 102, the system of equations can be solved, and
the remaining symbols are predictable. The results of the analysis showing the positions of
unpredictable symbols are presented in Table 18.
114
Table 18 – I/NAV 240-symbol unpredictability after interleaving.
1 9 17 25 33 41 49 57 65 73 81 89 97 105 113 121 129 137 145 153 161 169 177 185 193 201 209 217 225 233
2 10 18 26 34 42 50 58 66 74 82 90 98 106 114 122 130 138 146 154 162 170 178 186 194 202 210 218 226 234
3 11 19 27 35 43 51 59 67 75 83 91 99 107 115 123 131 139 147 155 163 171 179 187 195 203 211 219 227 235
4 12 20 28 36 44 52 60 68 76 84 92 100 108 116 124 132 140 148 156 164 172 180 188 196 204 212 220 228 236
5 13 21 29 37 45 53 61 69 77 85 93 101 109 117 125 133 141 149 157 165 173 181 189 197 205 213 221 229 237
6 14 22 30 38 46 54 62 70 78 86 94 102 110 118 126 134 142 150 158 166 174 182 190 198 206 214 222 230 238
7 15 23 31 39 47 55 63 71 79 87 95 103 111 119 127 135 143 151 159 167 175 183 191 199 207 215 223 231 239
8 16 24 32 40 48 56 64 72 80 88 96 104 112 120 128 136 144 152 160 168 176 184 192 200 208 216 224 232 240
We can therefore conclude that convolutional encoding and interleaving maintains the
entropy and unpredictability of the signal in a way that can be determined a priori by the
receiver, depending on the message structure. We have also demonstrated that, out of n
unpredictable bits coded into 2n symbols, the first n symbols based on unpredictable bits after
interleaving can be considered unpredictable.
3.10.3. Detection of Signal Replay Attacks Based on NMA
So far, the anti-replay capabilities of the solution have been characterised from a system
perspective, i.e. by how often, and how much, the signal will be unpredictable. To provide a
benchmark of how this unpredictability is translated into protection against replay, this
section analyses the replay detection performance based on NMA unpredictable symbols.
A full characterisation of security code estimation and replay (SCER) attack detectors using
different test statistics is presented in [25]. This section proposes some theoretical analyses to
validate the assumption that NMA unpredictability does protect against signal replay. It also
presents some general characterisation of the detection process. The replay attack analysed
here consists of a zero-delay attack, as described in [25]. In this attack, the spoofer estimates
and rebroadcasts the symbols at the same time (or with a minimal delay) as the receiver in
order to initially take control of the tracking looks and then to start gradually adding a delay
to the pseudorange. Before the attack, we assume that the receiver is locked to authentic
signals.
A non-zero delay attack requires the attacker to force signal reacquisition by jamming the
receiver for some seconds (e.g. 20 seconds for a two μs delay with a static receiver using a
0.1-ppm TCXO (Temperature-Controlled Cristal Oscillator), as per [25]). The fact that the
receiver may have other means to detect this attack is left out of the scope of this section.
Within the zero-delay attack, we assume that the attacker is continuously transmitting a
signal with a zero delay (or a delay that is so close to zero that does not represent any
115
difference in the symbol detection process). We assume that the attacker is not switching on
and off the spoofer so that at the beginning of an unpredictable symbol is off, and it is on
otherwise, as this could be detected by e.g. looking at signal power variation patterns.
This section proposes a replay detection method based on the accumulation of the first signal
samples of each unpredictable symbol, and the correlation of that signal sample sequence
with the known replica once the symbols are authenticated. The purpose of the proposed
method is just to demonstrate the protection against replay provided by unpredictable
symbols. Other methods optimised for different receiver types are possible.
In order to detect if the signal is correct, the receiver can accumulate the first samples of the
NC chips of NU unpredictable ± 1 symbols over a given interval. The receiver will accumulate
the samples of NCNU chips. In our NMA study case, in a time interval of 30 seconds each
usable satellite transmits 276 unpredictable symbols (NU = 276). Once the NU symbols are
received and authenticated, the receiver can generate a replica of the NCNU sequence and
correlate it with the received signal samples. By this process, the power gain 𝐺𝑎 obtained
from an authentic signal can be approximated by the total number of chips correlated [63], or
𝑁𝐶 𝑁𝑈 .
𝐺𝑎 = 𝑁𝐶 𝑁𝑈 (3.27)
For example, if NU = 276 and we use the first 5 chips of each unpredictable symbol (𝑁𝐶 = 5),
the gain would be 𝐺𝑎 = 1380, or 31.39 dB.
One potential disadvantage of this method is that it cannot take advantage of the cross-
correlation properties of PRN codes, which minimise the interference between satellites, as
only the first chips are looked at. Therefore, one can expect a higher level of interference due
to other satellites for both authentic and spoofed signals. In any case, for the rest of this
section, we assume that the 𝑁𝐶 𝑁𝑈 sequence is long enough to have a significant gain above
the noise plus interference level. We will also assume that a processing gain in that order will
be sufficient, even noting that the pre-correlation SNR of a typical receiver can be in the
order -20 dB, as shown in [5], Ch. 6, and therefore a power gain of 30dB or more is desirable.
This assumption depends on the number of unpredictable symbols used, but assuming 𝑁𝑈 is
high enough, the conclusions are considered valid. This is why the USR is one of the key
NMA design performance indicators.
116
If the receiver is tracking a spoofed signal subject to a zero-delay attack, the gain will be
much lower, and will depend on the probability of successfully estimating the symbol by the
spoofer with a much-reduced number of samples. For every set of m samples, we can
calculate the probability of error in the estimation of an unpredictable symbol by the spoofer
as follows:
1
𝑝𝑒𝑟𝑟 (𝑚) = 𝑒𝑟𝑓𝑐(√𝑚𝑇𝑠𝐶/(𝑁0 + 𝐼0 ) ) (3.28)
2
where m is the number of samples integrated by the spoofer, 𝑇𝑠 is the sampling period and
𝐶/(𝑁0 + 𝐼0 ), 𝑠 is the carrier to noise plus interference density ratio as seen by the spoofer. Note
that 𝑚𝑇𝑠 is a measure of time, and is equivalent to 𝑁𝑐𝑇𝑐 being 𝑇𝑐 the chip period. Figure 41
shows the error probability in the estimation of a symbol after 𝑚𝑇𝑠 microseconds of
integration, for four different spoofers, each one receiving the signal at different 𝐶/(𝑁0 + 𝐼0 )
of 42 dBHz, 45 dBHz, 48 dBHz and 52 dBHz.
Figure 41 – Probability of error in the estimation of an unpredictable symbol wrt. Integration time (M*Ts), for
different C/(N0 + I0) values
As mentioned before, the 𝐼0 term a priori cannot be neglected for a few samples, as cross-
interference from other satellites may be neglected after correlation with a full code, but this
is not the case if only a few samples are taken. Due to the 𝐼0 term, carrier to noise values can
be lower than the standard C/N0 of around 45 dBHz. However, as the spoofer may
incorporate additional hardware to raise the signal power, as directional antennas, higher
117
values are considered. The importance of the 𝐼0 term is not so relevant as we analyse in
relative terms the difference between the spoofed and non-spoofed cases.
It should be noted that 𝑝𝑒𝑟𝑟 is the error probability after 𝑚𝑇𝑠 integration. The average
probability of error of the total M samples is higher, and will be between 0.5 and 𝑝𝑒𝑟𝑟 . We
call this average Unpredictable Symbol Error Rate (USER):
𝑀
1
𝑈𝑆𝐸𝑅 = ∑ 𝑝𝑒𝑟𝑟 (𝑚) (3.29)
𝑀
𝑚=1
where M is the total number of samples integrated per unpredictable symbol (𝑀 = 𝑁𝑐𝑇𝑐/𝑇𝑠).
Assuming that the receiver performs the abovementioned correlation over a spoofed signal,
the power gain when tracking a spoofed signal would be limited as follows:
𝐺𝑠 = 𝑁𝐶 (1 − 2 𝑈𝑆𝐸𝑅 )2 𝑁𝑈 = 𝐺𝑎 (1 − 2 𝑈𝑆𝐸𝑅 )2 (3.30)
The factor 2 multiplying USER is due to the fact that the wrongly guessed symbols not only
do not add, but subtract from the correlation peak. It assumes that the spoofer does not stop
transmitting even from the beginning of the symbol. If this case is considered pessimistic for
the spoofer, we can consider USER = 𝑝𝑒𝑟𝑟 (𝑀). Figure 42 shows the reduction in the gain
between G,s and G,r for different integration times, for spoofers at a C/(N0 + I0) of 42, 45, 48
and 52 dBHz under the case USER = 𝑝𝑒𝑟𝑟 (𝑀).
118
Figure 42 – Minimum Gain Reduction when spoofed (Maximum spoofed vs non-spoofed gain), vs. Integration
Time (M*Ts)
The gain reduction is quite evident especially if only the beginning of unpredictable symbols
is taken. Following the above example, if we use look at the first 5 chips (5 μs approx.) of
each unpredictable symbol, and we correlated spoofed signals for a 45 dBHz spoofer, our
gain would be reduced by more than 7 dB with respect to tracking an authentic signal.
We must note that a low gain may be due to a degradation in the original signal, in which
case not only 𝐺𝑎 would be reduced, but also other standard signal indicators as C/N0 and bit
error rate, leading possibly to an authentication denial of service, but not to an authenticated
position with signal under delay attack.
3.10.3.1 USR Impact in detection of Signal Replay Attacks
A receiver needs two inputs to perform this antireplay test:
 The validation of the unpredictable symbols. This occurs every TBA seconds
(TBA=10, 20 or 30s, depending on the implementation).
 The accumulation of a high enough amount of chips from unpredictable symbols to
generate a peak above the noise and interference. This depends on NC and NU, which
in turn depends on USR.
119
As mentioned above, NU = 276. Depending on the amount of unpredictable symbols, the

receiver can wait for more time or less time. Waiting for less time to compute antireplay
statistics makes the system more robust. On the other hand, raising Nc also facilitates the
success rate of the spoofer. Sensitivity analyses and trade-offs on this respect are left further
work beyond this thesis. Even if we have to wait for 30 seconds to get enough symbols, the
receiver could perform the check every 10 seconds (TBA), by sliding a 30-second window
every 10 seconds. What seems clear is that symbol unpredictability is a relevant KPI if NMA
is designed to be used against replay attacks. While more detailed analyses and metrics can
be performed, including hypothesis testing versus missed detection and false alarm
probabilities as those proposed in [25] and outlined in [39] and [36], we can conclude that
adding unpredictability to the signals highly restricts the possibilities of a spoofer to perform
replay attacks.
3.11. Conclusions
This chapter has presented the main motivations to study the provision of an open navigation
message authentication (NMA) service. Out of the key performance indicators defined to
characterised NMA solutions, TBA and AER stand out as the most important. USR and MPT
are also relevant if the NMA solution is meant to protect against replay attacks.
A TESLA protocol seems more convenient than digital signatures for NMA due to the lower
amount of data required per authentication. TESLA protocols using a single chain of keys for
all satellites are very advantageous as they reduce the authentication data required even
further. Reducing authentication data also reduces AER and TBA, improving the overall
NMA performance. To improve NMA availability in difficult visibility conditions and
overcome mitigations in the authentication transmission, some satellites can transmit MACs
to authenticate neighbouring satellites.
A concrete NMA proposal including these concepts is proposed in the Galileo E1-B I/NAV
message structure using the "Reserved 1" field, which provides 20 bps. The NMA structure
proposed is divided in two main sections: The H-K-root section to transmit a header and a
signed root key (4 bps), and the MAC-K sections to transmit the MACs and keys used
regularly for authentication (16 bps). A NMA implementation proposal considered secure at
the time being consists of one MAC-K section every 10 seconds, containing three MAC
sections of 26 bits, including 10-bit MACs, and an 82-bit key. Anyhow, the concept follows a
120
flexible approach whereby the SIS can inform the receiver about the MAC and key sizes for
new chains, allowing keeping high system robustness during the system lifetime even in case
of computational and cryptanalysis progresses.
The proposed solution is then characterised, mainly in terms of TBA and AER. A TBA of 10
seconds provides a very low time to first authenticated fix and a high robustness, while
maintaining a sufficient cryptographic security level at the time being. TBA can be reduced
to 5 seconds in average at user level by adding a transmission offset to a subset of satellites.
AER is very low as well, thanks to the low number of bits required for authentication and the
possibility to get most of them from the best visible satellite(s), maximizing the availability
of the authentication service even in degraded conditions. MPT achieved is in the order of 1.5
seconds, and USR yields 276 unpredictable symbols every 30 seconds, even considering the
last 20 bits of a key as predictable. USR can be improved by encrypting each MAC-Info
section with the key delivered later.
The NMA performance in degraded environments is characterised, showing that availability

is just minimally degraded or not degraded at all, when navigation data is authenticated, with
respect to standard non-authenticated navigation.
The chapter also discusses the value of NMA against replay attacks. A method is proposed in
which, by storing the first chips of every unpredictable symbol, a receiver can create a signal
sequence whose correlation gain will be very low once if the signal is spoofed. This justifies
why signal unpredictability is a relevant design parameter and is maximised in the proposal.
As a summary, Table 19 presents the performance of the proposed NMA solution.
Table 19 - Performance characterization of the proposed authentication solution
Indicator Result Comments
Availability No degradation Same performance as standard navigation with

Galileo I/NAV
Accuracy No degradation Same performance as standard navigation with

Galileo I/NAV
TTFAF No degradation Except in "cold start, no K-root" or "slow MAC"
121
cases
TBA 10 sec
MPT ~1.6 sec Every 2 seconds, 40 authentication bits out of which

some are unpredictable, are transmitted.
USR 3.68% (of total) Assuming 276 unpredictable symbols every 30

seconds.
23% (of auth.)
3.68% of total I/NAV symbols (7500 per subframe)
23% of authentication symbols (1200 per subframe)
AER See Figure 30, Minimal degradation wrt. navigation frame error
Figure 31 rates.
Based on the design choices and the experimentation results, we can conclude that the
proposed NMA solution is compliant with the user needs listed in Table 1 at the beginning of
the chapter.
122
Chapter 4. Snapshot Positioning
Without Initial Information
4.1. Motivation
Thanks mainly to GPS, satellite navigation technologies have become ubiquitous. Currently
they are used in various devices and applications such as smartphones, personal navigation
devices, vehicle guidance, machine control, and many others. Future devices may include
miniaturised positioning 'dots' or stickers attached to living beings or objects that are
switched on sporadically at a given event or on request. For these applications, instantaneous,
push-to-fix, or snapshot techniques are more suitable than standard receiver architectures.
Snapshot positioning techniques are based on saving digital samples from the ADC (Analog
to Digital Converter) of a GNSS receiver front end, and post-processing them to calculate a
position and time solution. When applied to standard GPS L1 C/A signals, the receiver can
obtain frequency and pseudorange measurements from the signal processing block, and can
use satellite ephemeris data coming from another source, e.g. a server or a pre-calculated set
of long term ephemerides, to calculate a position solution. In this case, the receiver needs to
calculate the full pseudorange measurements from the code phase measurements obtained
from the acquisition or tracking stages, which are ambiguous, as snapshot techniques do not
foresee the receiver to wait until a synchronization sequence (as e.g. TLM/HOW fields for
GPS) is received.
To solve this ambiguity, the receiver can use an initial position from a server, which must be
accurate to around 100 km if GPS L1 C/A codes are used, or it can calculate its initial
position based on Doppler measurements as proposed in [5]. If the time is unknown, it can
use the coarse time navigation equations [64]. However, it requires an initial time reference
accurate to the level of a minute.
123
The purpose of this chapter is to present an algorithm based on snapshot positioning

techniques that allows computing a position and time solution without any initial position or
timing information.
Apart from potential applications as animal trackers, container trackers and the like, a main
motivation for this work is to help solve the theoretical problem of how to calculate a position
with as minimum information as possible.
4.2. Background
Standard standalone GPS receivers estimate the time of arrival of signals transmitted from
satellites, and compute the satellite position from the signal data. They first acquire the
signals, measuring its frequency (Doppler) and delay (code phase), by correlating a signal
replica with the received signal. After acquisition, a receiver locks to the signals with
dedicated tracking loops, and starts demodulating the data contained therein. As the receiver
has a priori no synchronisation with the signal, it has to demodulate the signal data until a
certain pattern is found (called TLM, or telemetry, in the GPS signal). After this pattern is
found, the receiver can synchronise and start interpreting the data. This first includes the
satellite time reference called in GPS Time of Week and Week Number (TOW and WN), and
then the satellite ephemeris, which allow to compute the satellite position and clock offset.
Once data is demodulated and time-of-arrival is estimated for at least four satellites, the
receiver is able to compute a 3D position and its time offset. While the satellites are
accurately synchronised to a time reference, the receiver is a priori not. This whole process
may take between 30 seconds and 1 minute for standard receivers, until a first position fix is
obtained.
The standard receiver acquisition process is described in detail by F. van Diggelen in [5] and
K. Borre et al. in [13]. Classic receiver architectures involving acquisition and tracking stages
are described by A. J. Van Dierendonck in Chapter 8 of [3] and by P. Misra and P. Enge in
Chapters 11 and 12 of [2].
4.2.1. Snapshot Positioning
Snapshot positioning is based on the following steps:
 Reception and digitalisation by the ADC of IF (Intermediate Frequency) samples of

the target band, in which the positioning signals are foreseen.
124
 Storage of a slice of raw digital samples of certain duration, in the order of some
milliseconds, depending on the integration time and other considerations.
 Post-processing of the raw digital samples from which the frequency and code phase
measurements are obtained.
 Estimation of the position and time of the receiver based on the measurements and
satellite (and potentially propagation error) data.
Snapshot techniques provide some advantages over standard acquisition and tracking
positioning:
 They can provide an instantaneous position fix.

 They require much less power consumption, as the signals do not need to be tracked
continuously.
 The receiving device can be cheaper than an ordinary GNSS receiver.
There are not many references in the open literature specifically about snapshot processing
techniques. One of the earliest references focusing on snapshot techniques is [65], which
presents some simulated performance of a high-sensitivity snapshot GPS software receiver.
[66] describes a GPS/Galileo snapshot receiver and the signal detection theory behind,
showing some simulated performance. [67] implements snapshot techniques based on coarse
time navigation and presents some performance results. As a major building block of assisted
GNSS, [5] describes snapshot techniques at signal processing level, and at PVT computation
level. These techniques are based on the existence of a communication channel between the
receiver and a server, which allows the server to compute the receiver position or to transmit
to the receiver the satellite ephemeris to allow a faster, sometimes instantaneous, fix. Assisted
techniques, as implemented in mobile phones or smartphones, are generally based on the
synchronisation of the receiver through a wireless network, down to at least a few seconds.
They also transmit a position and time reference to facilitate the acquisition process.
Assistance techniques can therefore provide an instantaneous positioning and timing service.
However, they generally require an initial position and time reference to function. To
calculate the initial position, [5] describes in Ch. 8 the instantaneous Doppler algorithm, and
how it can be combined with code phase, or pseudorange, measurements, for positioning.
Doppler measurements are used to compute an initial position, accurate to some kilometres,
which can be later used as a reference for a more accurate position using pseudorange
measurements through the Coarse Time Navigation equations. However, this initial position
125
calculation requires a given initial time to be calculated, which has to be accurate to the level
of minutes. [5] and [68] also presents methods to solve the time uncertainty by solving the
navigation equations for each possible case, with an iteration at least every minute, and
determining the correct solution by estimating the solution residuals. The required number of
operations of this method implies that it cannot instantaneously determine a position and time
solution with currently standard processing power if the initial time uncertainty is up to
several days and without an initial position.
4.2.2. Snapshot Signal Acquisition and Measurement Accuracy
One of the potential limitations of snapshot positioning is the accuracy that can be obtained
with the frequency and code phase estimations from the acquisition stage. The acquisition is
generally performed in code phase and frequency bins. Parallel acquisition based on FFT
(Fast Fourier Transform), as described in [13], allows speeding up the acquisition process and
achieving a finer estimation of the delay-frequency acquisition peak. If a serial acquisition is
followed with typical 500 Hz frequency bins, the maximum frequency error will be 250 Hz,
(i.e. the case between two bins), with an mean error of 125 Hz (i.e. ¼ of the frequency bin,
assuming a uniform error probability distribution between 0 Hz and 250 Hz). If the Doppler
measurements are used for positioning, as is the case here, and given that a 1 Hz accuracy
error can lead to approximately 1 km in the instantaneous Doppler positioning error [5],
frequency estimation must be fine-tuned to obtain an accurate Doppler measurement. If serial
acquisition is followed, the average delay error will be again ¼ of the correlator spacing, i.e.
around 37.5m if the typical 0.5 chip correlator spacing is used.
Here are some methods proposed to improve accuracy of snapshot techniques.
 Closed-Loop architectures: Once the signals are acquired, the receiver can run some
standard tracking loops to do some fine adjustments of the phase, frequency and code,
through PLL/FLL and DLL engines.
 Parallel FFT search: by performing FFT and IFFT (Inverse FFT) of the signals, a
higher resolution than through serial bin search can be achieved. This is further
explained later in this chapter, in the experimental results section.
 Interpolation in Open-Loop architectures: the receiver can take the correlation peak
and the previous and next samples and fit the points to a function (either a triangle or
126
a parabola), and link the peak to the maximum of the function. This is further
explained later in this chapter, in the experimental results section.
Another relevant aspect of measurement accuracy in open-loop architectures is the coefficient

between the sampling frequency (fs) and the code frequency (fc). If fs is a multiple of fc, the
correlation peak will be staircase-shaped and will limit the average accuracy of the
pseudorange by the sampling rate (Ts = 1/fs). This matter is further explained in section 5.5.
4.2.3. Snapshot Synchronisation
If the raw signal samples are synchronised to the level of the spreading code duration (1 ms
for GPS L1 C/A, 4 ms for Galileo E1B/C), the receiver can solve the code phase ambiguity
and calculate the pseudorange from the code phase measurement. This is called fine time
acquisition in [5] and can be achieved in U.S.'s CDMA mobile networks.
If the raw signal samples are synchronised just to the level of some seconds, then coarse time
acquisition techniques apply. The time uncertainty in coarse time navigation can be solved by
the coarse time navigation algorithm by Peterson et. al. initially presented in [64]. This
algorithm allows a fix even if time is only known with a minute of error and hence satellite
positions are not known, by adding a 5th unknown named "coarse time" to the navigation
equations. The coarse time navigation algorithm is based on the solution of the following
equation:
𝛿𝑥
𝛿𝑦
𝛿𝜌 = 𝐻𝛿𝑋 + 𝜀 = [−𝑒 𝑖 1 𝑅𝑅𝑖 ] 𝛿𝑧 + 𝜀 (4.1)
𝛿𝑏
[𝛿𝑡𝑐 ]
where 𝛿𝜌 is the update of the a-priori state, i.e. a column matrix with the difference between
the predicted pseudoranges 𝜌̂ and the measured pseudoranges 𝜌 (𝛿𝜌 = 𝜌 − 𝜌̂ ); H is the
observation matrix that relates the measurements with the state vector 𝛿𝑋, −𝑒 𝑖 is the
estimated receiver-to-satellite-i unit vector with the opposite sign, RRi is the range rate of
satellite i, and [δx δy δz δb δtc] T is the update of the state vector 𝛿𝑋, or the vector of
unknowns to solve, which includes the receiver position (x, y, z), the receiver bias b, and the
coarse time difference tc, i.e. the difference between the estimated measurement time and the
actual measurement time. The measurement and linearization errors are represented by 𝜀.
127
The proposed system of equations resembles to that of standard PVT estimation one as
described in [5], Section 4.2, or [2], Chapter 6, with the exception that it adds an unknown to
the state vector, tc, to account for the coarse synchronisation time error.
Coarse time navigation is limited by a time uncertainty of around one minute. To reduce
timing requirements, [68] proposes a method to calculate a fix by using Doppler and code
phase measurements where the required time accuracy for the Doppler measurements (T0)
can be relaxed to a maximum of twelve hours. While this method is targeting the same
challenge as this chapter, it uses the Doppler instantaneous positioning method as described
in [5] at different initial time solutions which differ in one minute. The method requires about
30 seconds processing in a standard processor to solve a 12-hour ambiguity.
4.2.4. Code Phase Ambiguity Resolution
As mentioned before, to calculate a position from the snapshot, the receiver needs to solve
the code phase ambiguity. In order to solve the code phase ambiguity, the receiver needs to
assign an integer number of codes Ni to the differential code phase of each satellite i. Due to
the receiver clock bias, which commonly affects all code phase measurements, even if the
receiver position, and satellite position at a time are roughly known, the receiver cannot know
for sure what is the Ni of each satellite until it verifies the residuals of a solution. A method to
calculate the integer codes is proposed in [5], Chapter 4. The method is previously described
in [69]. It is mainly based on these steps:
 Assigning a Ni to each satellite. For this, a satellite 0 is taken as a reference, its integer
code ambiguity N0 is estimated, and the Ni for the remaining satellites are estimated
coherently.
 Solving the coarse time navigation equation with the estimated full pseudoranges.
 If the solution residuals are low (i.e. do not have an error of several km), then the
estimation is good. If not, another Ni combination is used.
In order to solve the code phase ambiguity, an initial position accurate to some km is
required. The GPS code duration is 1ms, or 300 km at light speed, so to ensure that the right
Ni are taken, the position error should be less than 100km (and the time error less than a
minute, as mentioned before).
128
Receivers connected to a communication network may easily obtain such an initial position.
In other cases, instantaneous Doppler positioning can be used to provide an initial position.
For a static or slow-moving receiver, the instantaneous Doppler equations are11:
𝛿𝑥
𝛿𝑦
𝛿𝐷 = [−𝑒 ′ 𝑖 1] [ 𝛿𝑧 ] + 𝜀 (4.2)
𝛿𝑓𝑑
where 𝛿𝐷 is the update of the a-priori state, i.e. a column vector with the difference between
the predicted Dopplers ̂ ̂ ), −𝑒′𝑖 is the derivative
𝐷 and the measured dopplers D (𝛿𝐷 = 𝐷 − 𝐷
in time of −𝑒 𝑖 , and [δx δy δz δfd] T is the update of the state vector, which estimates the
receiver position and the frequency drift.
The Doppler measurements are obtained as the difference between the intermediate
frequency at which the signals are down-converted in the receiver front-end, and the
frequency measured from the acquisition engine. They can be also obtained as the difference
between two pseudoranges taken at different epochs (dividing by the time increment), or two
carrier phase measurements from the tracking loops. We must note that Doppler and range
rate have inverse signs, i.e. when the satellite is approaching (the range is diminishing), the
Doppler measurement is positive (the frequency is higher):
𝑅𝑅𝑖 = −(𝐷 𝑖 − 𝑓𝑑 )𝜆 + 𝜀 (4.3)
where 𝑅𝑅 𝑖 is the range rate of satellite i, 𝐷𝑖 is the Doppler measurement of the same satellite,
fd is the receiver clock frequency drift, 𝜆 is the wavelength of the carrier frequency (𝜆 of
GPS/Galileo L1/E1 signals of fc= 1575.42 MHz is c/fc≈ 19 cm), and 𝜀 represents the errors in
the measurement (e.g. frequency misalignment, receiver noise, etc.).
4.3. General Description of the Proposed Algorithm

This section describes the algorithm to instantaneously calculate the position and time of a
receiver based on satellite radiofrequency signals with very inaccurate, initial receiver timing
or information and no position information. It is based on the instantaneous Doppler
positioning algorithm and estimates the coarse time offset by introducing an additional
11
The notation has been adapted to the one used throughout the dissertation
129
unknown to the state vector, and relating it to the range rate measurements through the
acceleration of the satellites as seen by the receiver.
Figure 43 – Satellite range rate variation over time
Figure 43 depicts, for the case of one satellite and a receiver located at P0, the estimated
range rate RR(t0) at time t0 and the measured range rate RR(t1) at time t1 between the
satellite and the receiver. It also depicts the estimated unit vector 𝑒̅ pointing from the receiver
to the satellite. Satellite-to-receiver range rate RR(t0) at an instant t0 and at an instant t1
RR(t1) differ by a magnitude that can be approximated by the time increment between t1 and
t0 multiplied by the satellite-to-receiver relative acceleration.
Figure 44 depicts how the satellite-to-receiver acceleration a can be estimated as the time
derivative of the range rate, that is, the increment in range rate (ΔRR) divided by the
increment in time (Δt):
𝑎 = 𝛥𝑅𝑅/𝛥𝑡 (4.4)
This acceleration relates the estimated range rate at t0 with the actual or measured range rate
at t1 according to the equation
𝑅𝑅(𝑡1) ≈ 𝑅𝑅(𝑡0) + (𝑡1 − 𝑡0) ∙ 𝑎 (4.5)
where RR is the range rate, and a is the time variation of the range rate, or satellite
acceleration relative to the receiver.
130
Figure 44 – Satellite-to-receiver acceleration estimated as range-rate variation over time
t1 and t0 can differ by several hours, and the assumption that the acceleration is constant may
be still valid for approximating to the correct time. Figure 45 depicts the range rate and
satellite acceleration (or Doppler rate, or second range derivative in time) relative to the
receiver.
Figure 45 – Range rate (i.e. the sign-reversed Doppler shift), and relative acceleration over a satellite pass. Relative
acceleration can be approximated by a constant
131
4.3.1. "Cold Snapshot" Equations for a Static Receiver
For simplicity, we start with the description of an algorithm for a static (or slow-moving)
receiver. We assume the receiver is static, or moving at a relatively low speed (<100 km/h),
which allows the receiver velocity to be approximated to zero. In this static case, the
proposed state vector to be solved is
𝑋 = (𝑥, 𝑦, 𝑧, 𝑓𝑑, 𝑡𝑐) (4.6)
where x, y and z are the receiver coordinates, fd is the receiver clock frequency drift, and tc is
the time difference between the initial time t0 and the actual time t1. In this case, the
proposed system of equations is solved to estimate the state vector:
𝛿𝑥
𝛿𝑦
−𝛿𝐷 = [−𝑒 ′ 𝑖 1 𝑎𝑖 ] 𝛿𝑧 + 𝜀 (4.7)
𝛿𝑓𝑑
[ 𝛿𝑡𝑐 ]
where 𝛿𝐷 corresponds to the vector of the differences between the Doppler measurements (in
m/s) and the Doppler estimation from the satellite data and a previous position and time,
which for the first iteration is set to P0 at t0. It is multiplied by -1 to convert Doppler
measurements into range rate measurements, 𝑎𝑖 is the satellite-i-to-receiver relative
acceleration, and 𝜀 is the error associated to the measurements and the linearisation process.
This system of equations is similar to that in [5] (8.7). It can be solved by a standard iterative
method where the 𝛿𝐷 and the state vector 𝛿𝑥, 𝛿𝑦, 𝛿𝑧, 𝛿𝑓𝑑, 𝛿𝑡𝑐 provides an update to the next
iteration.
If the receiver is dynamic but has a sensor or sets of sensors that provide measurements of the
receiver velocity, the measurements can be subtracted from the Doppler measurements and
we can apply the equations for a static receiver. Velocity could be determined from an inertial
unit, odometer or any other source or signal. By having a static receiver or not estimating the
receiver velocity as part of the unknowns, the number of visible satellites can be reduced to at
least five, or at least six if the measurement residuals are verified. If the frequency drift is
known or very low, the number of visible satellites can be reduced to at least four, or five if
residuals are verified.
132
4.3.2. "Cold Snapshot" Equations for a Dynamic Receiver
Before providing the equations for a dynamic receiver, we mathematically derive "cold
snapshot" system of equations. The system of equations presented in (4.7) can be obtained by
differentiating in time the coarse time navigation equations in (4.1):
𝛿𝑍 ′ = 𝐻 ′ 𝛿𝑋 + 𝐻𝛿𝑋 ′
𝛿𝑥 𝛿𝑥 ′
𝛿𝑦 𝛿𝑦 ′
−𝛿𝐷 = [−𝑒 𝑖 ′ 0 𝑅𝑅𝑖 ′] 𝛿𝑧 + [−𝑒 𝑖 1 𝑅𝑅 𝑖 ] 𝛿𝑧 ′ + 𝜀
𝛿𝑏 𝛿𝑏 ′
[𝛿𝑡𝑐 ] [𝛿𝑡𝑐 ′ ]
(4.8)
𝛿𝑣𝑥
𝛿𝑥
𝛿𝑣𝑦
= [−𝑒 𝑖 ′ 𝛿𝑦
𝑎𝑖 ] [ ] + [−𝑒 𝑖 1 𝑅𝑅𝑖 ] 𝛿𝑣𝑧 + 𝜀
𝛿𝑧 𝛿𝑓𝑑
𝛿𝑡𝑐 [ 0 ]
When the receiver is static (or moving slowly), the relative velocity is zero, and therefore the
system of equations becomes that in (4.7). When the receiver velocity needs to be taken into
account, the system of equations is as follows:
𝛿𝑥
𝛿𝑦
𝛿𝑧
𝛿𝑣𝑥
−𝛿𝐷 = [−𝑒 ′ 𝑖 −𝑒 𝑖 1 𝑎𝑖 ] 𝛿𝑣𝑦 + 𝜀 (4.9)
𝛿𝑣𝑧
𝛿𝑓𝑑
[ 𝛿𝑡𝑐 ]
𝑖
The derivative −𝑒 ′ of the receiver-to-satellite unit vector for a given satellite at position 𝑆̅
and a receiver at position ̅̅̅̅
𝑅𝑥, with a range r between the two, can be calculated as follows:
133
𝑟̅
𝑒=
𝑟
1
𝑒′ = ( 2 )[𝑟̅ ′ 𝑟 − 𝑟̅ 𝑟 ′ ]
𝑟
(4.10)
1
̅̅̅̅̅̅̅̅ )𝑟 − (𝑟̅ )𝑅𝑅]
= ( 2 )[ (𝑉𝑠_𝑟𝑥
𝑟
1
̅̅̅̅̅̅̅̅ − 𝑒𝑅𝑅)
= (𝑟) (𝑉𝑠_𝑟𝑥
̅̅̅̅̅̅̅̅ is the vector of satellite velocity relative to the receiver. A similar expression is
where 𝑉𝑠_𝑟𝑥
found in (8.6) of [5].
4.4. General Algorithm Implementation Including Long Time Uncertainty

Periods
The logic flow diagram is presented in Figure 46. The proposed algorithm can solve a time
ambiguity of some hours in one shot. However, for longer time ambiguities, the algorithm
can be run several times in different intervals of some hours, and the residuals of each
solution can be verified to assess if the solution is plausible or not. This section explains this
process in more detail. It also explains all the steps, from the signal reception to the PVT
computation.
First, the receiver receives the radiofrequency signal stream containing the satellite signals
later used for positioning. It then filters, amplifies, conditions and digitises the signal stream
to generate digital samples containing the satellite signals, which are usually under the
thermal noise level in the case of GNSS signals.
Then, the receiver processes the samples to obtain the range rate measurements. In the case of
direct sequence spread spectrum signals as GPS, this processing is usually subject to a signal
acquisition engine in which the digital samples are correlated with replicas of the signal
spreading codes at different time offsets and frequencies. As an outcome of the acquisition
stage, measurements for each satellite of the satellite-to-receiver Doppler and range can be
obtained. Range rate measurements can be obtained from frequency Doppler measurements
as well as code phase difference measurements or carrier phase difference measurements.
134
Figure 46 – Logic flow diagram of the "cold snapshot" algorithm
A receiver using this algorithm requires the knowledge of the satellite positions during the
time uncertainty interval. If satellite clock drift impact is non-negligible, it could be required
as well as part of the satellite data. In standard receiver architectures, the receiver decodes
this information from the data modulated on the satellite signal (50 bps in GPS L1 C/A
signals), a process which may last several tens of seconds in good reception conditions for
each satellite. In snapshot positioning, this data cannot be demodulated and needs to be
obtained from another source: previously demodulated ephemerides from the signals, satellite
data downloaded from a server, long term orbital predictions from the satellites, satellite
almanac data, which provides long term satellite orbits with a precision of some kilometres
and which can be a valid source depending on the accuracy desired for the position to be
calculated, or other sources. These data can be formatted in standard orbital Keplerian
parameters that can be interpolated to a given time reference, satellite position, velocity and
acceleration models, or other formats, as long as they allow the estimation of the satellite
positions at a given time.
135
In addition to the satellite data, the proposed algorithm requires the definition of an initial
time reference t0 and position reference P0. The accuracy of the initial position P0 is not
relevant. Therefore, the position P0 can be set to the Earth centre, or the centre of the polygon
formed by the satellite ground projection at t0 for the observed satellites. As regards the
accuracy of the initial reference t0, it can differ from the actual measurement time in several
hours. If the time error is in the order of hours, one computation may be sufficient. If the time
error is higher, several computations with different time references over the uncertainty
interval may be required, as described later.
For a given position and time pair (P0, t0), the proposed method obtains the receiver position,
velocity, timing and frequency offset in the following step by resolving Equations (4.8) or
(4.9), depending on the receiver dynamics.
If a position with a higher accuracy needs to be obtained, existing methods can use this initial
position and time for a coarse time navigation solution using pseudorange measurements as
described in prior art [64] [5], allowing an accuracy in the meter-level, or even below,
depending on the accuracy of the code phase measurements.
We can see that the range rate function is not in general linear over time, and therefore the
acceleration is not constant, as here approximated. The validity of the proposed
approximation is in the order of a few hours, as demonstrated in later sections of this chapter.
We can also observe that the range rate measurement depends on the satellite clock frequency
drift. This drift can be added to the measurement estimation, or neglected in the case of
navigation satellites with highly stable atomic clocks. The estimation of the acceleration can
be also taken from the satellite data and can be further refined by adding a linear time-varying
components, as jerk, or higher order components, in order to refine the range rate estimation
at a different time and improve the convergence period.
Once a solution is obtained, the algorithm checks if the obtained solution (P1,t1) is
considered plausible, meaning that it is near the Earth surface and any standard integrity
check related to the solution residuals does not show any anomaly. If this is the case, the
solution is stored for later use and reported as an output of the method.
If the time uncertainty is reduced to some hours, only one iteration is performed. After the
process of calculating the position and time of the receiver is terminated, the method ends.
136
However, if the time uncertainty is higher, several iterations with different initial times can be
performed if needed, and as shown graphically in more detail in Figure 47.
When the time uncertainty period is too long and in the order of many hours, days, weeks or
even months, the abovementioned system of equations will not converge to an adequate
solution, due to the linearization errors of non-linear equations or other motives. A solution to
this problem is presented in Figure 47, which consists of calculating a solution for several
initial times. A way to implement this method is to split the time uncertainty interval into
sub-intervals, define an initial time t0-i (T0-1, T0-2, T0-3, etc.), for each interval, and
calculate a solution for each initial time. If the method converges to a plausible solution for a
certain interval, the obtained measurement residuals, in case of an over-determined solution,
will be below a certain threshold. The proposed method calculates an indicator of the
residuals magnitude for each solution P1 at T1-1, T1-2, etc. It can also include the distance
between the estimated height and the Earth surface to validate the position.
4.4.1. Orbital Repeatability and Advantages of Multi-GNSS
As shown in Figure 47, if the time uncertainty interval is too broad, there will be periods of
non-convergence, where the initial time is far from the correct time of the measurements T1
and the method does not converge to a plausible low-residual solution, and periods of
convergence, wherein the initial time is close to the actual time and the method will converge
to a plausible solution. However, for every solution, there may be several plausible solutions
due to the orbital repeatability of navigation satellite orbits, which leads to low-residual
solutions at wrong times.
137
Figure 47 – "Cold snapshot" algorithm run for different periods
Due to this effect, a low residual solution can be obtained with a fixed periodicity, which may
occur every 6 hours (1/2 GPS orbital period), and will always occur every 12 hours in the
case of GPS. Every 12 hours a very low residual solution is found associated to a position at
the opposite side of the Earth. Given the 12-hour orbital repeatability of GPS, every 12 hours
there will be a plausible solution at the same latitude but opposite longitude of the Earth. The
satellites will have completed their orbits and will be exactly at the same positions, but the
Earth will have turned 180º only. This effect is illustrated in Figure 48. The figure shows in
two dimensions the solution of four Doppler measurements (a line, instead of a cone) from
four sources, after one orbital period, after which the inner grey disk has rotated only 180º.
(One can also infer from the figure that if only the satellites of one orbital plane would be
taken in a solution, there would be a low-residual solution at all times.)
138
Figure 48 - Low-residual GPS orbital repeatability – 12-hour effect
This +/- 12h solution may pass the coarse-time Doppler residual thresholds and can only be
discarded at the later coarse-time pseudorange algorithm step.
A way to solve this problem is to use measurements from at least two satellites, each from a
different satellite constellation like GPS, GLONASS, Galileo or Beidou, and with a different
orbital period, to avoid the periodic repeatability of range rates from satellites from a single
constellation. In this case, the range rate repeatability period will correspond to the minimum
common multiple of the orbital periods of the satellites used. Therefore, by using more than
one constellation, the proposed method leads to a single low-residual solution over a period
of even several days. Figure 49 shows that only solutions including the correct time T1 will
be accepted as plausible solutions (T1-2, T1-3), and solution T1-5 will be discarded.
Figure 49 – "Cold snapshot" algorithm run for different periods with different GNSS to avoid low-residual wrong
solutions due to satellite orbital repetition
139
4.4.2. "Cold Snapshot" with Coarse Time Pseudorange Navigation
The "cold snapshot" method when based only on Doppler measurements will not yield an
accuracy at the meter level unless the signal carrier phases are stably tracked for some time.
However, it can be used to calculate a more accurate instantaneous position and time based
on range measurements. For this, methods to resolve the code phase integer ambiguity to
compute a full range measurement from an instantaneous fractional range measurement
without integer rollovers may be required, as the one proposed in Ch.5 of [5]. Several
solutions (P1, t1) may be obtained and stored from the "cold snapshot" algorithm applied
over a broad time uncertainty interval (e.g. those associated to T1-2, T1-3 and T1-5 in Figure
50). Some of them may be wrong, due to the orbital repeatability, even if residuals are low
(those of T1-5).
Figure 50 – Pseudorange solution residual computation to determine the right "cold snapshot" solution
In case a wrong initialisation solution (e.g. T1-5) enters the coarse time pseudorange
navigation block, the residuals will declare it as incorrect. The residual threshold in this case
will be much lower than in the coarse time Doppler case, commensurate with the accuracy of
the range-based solution.
If the solution is incorrect, we expect a high-residual output so it will be discarded. If the

solution is correct we expect a low-residual output and it will be considered as correct. An
over-determined solution is required to generate an indicator of the measurement residuals,
and the application of orbital and clock corrections to satellites at instants that differ by
several hours or days to the correct time of applicability, will lead to positioning errors that
will be reflected into a solution with higher residuals, as shown in Figure 50. Interestingly,
thanks to the orbital imperfections and clock drifts, the algorithm is able to work with time
140
uncertainties of several days, which would not have been possible if the satellite orbits and
clocks were perfectly estimated by the ground segment.
Figure 51 – Logic flow diagram of the "cold snapshot" algorithm combined with coarse time navigation
4.4.3. Hardware Implementations and Applications of the Proposed Algorithm
The proposed algorithm can be implemented in a receiver-server architecture, as shown in

Figure 52. In the figure, the receiver captures data snapshots regularly or triggered by certain
events (for example a signal received, a movement detected, etc.), and stores them into a
memory unit. Then, at a certain time, the receiver sends the snapshots to a server. The
receiver may not have an accurate or continuous time reference, so snapshots may not be
time-tagged. The server then receives the snapshots and resolves the position and timing for
each of them through the proposed algorithm, by having satellite position and clock data for
the interval of analysis.
141
Figure 52 –Receiver-server implementation of "cold snapshot"
Applications of the proposed algorithm may include any location trackers that do not foresee
to be continuously on, for power saving purposes or any other purposes. For example, one
can think of a small and low-power tracker that is stuck to a container travelling worldwide.
It will be switched on just sporadically, for example, when an alert is received through
mobile networks or DSRC (Dedicated Short-Range Communications), its solar battery has
been charged to a certain level, or it is subject to a movement captured by inertial sensors. At
this point, if the tracker has been completely switched off, it may not have a clock providing
a reasonably accurate time reference. The tracker just wakes up after a long sleep without
having a clue of when or where it is. There may be similar use cases for animal tracking or
for the internet of things, or just as a backup system for devices that are usually connected to
the network, but may not be in some occasions, as a smartphone powered on in another
country having lost its time reference. Other applications could also integrate any physical or
biometric sensors tied with the snapshot position data, for example, for animal or human
tracking.
4.5. Experimental Results

This section presents some experimental results of the proposed algorithm. The results are
based on real GPS snapshot data captures. A Matlab-based snapshot receiver for GPS L1
C/A has been developed, based partly on [13]. Six data captures have been analysed, all
showing similar results. They are summarised in Table 20. ID1 was available from [13]. IDs
142
2, 3, 4, 5 were available at the DGC from the experimental work of O. Badia [67]. ID6 was
obtained by courtesy of UAB SPCOMNAV Group from Prof. Seco-Granados.
Table 20 – Summary of data captures
ID Data capture Sampling Intermediate Location Date Data Number

configuration Frequency Frequency Analysed an
file [Hz] [Hz] Duration
of
Snapshots
Calculated
12
1 20050507- 38.192e6 9.548e6 University of 7th May 200 ms 20, 10ms

col-1s.cfg Boulder, 2005
Colorado, U.S.
2 20100302- 16368e3 4129945 Danish GPS 2nd 200 ms 20, 10ms
dgc-1s.cfg Centre, Aalborg, March
Denmark. 2010
3 20100325- 16368e3 4129945 CTAE, 25th 200 ms 20, 10ms
ctae-1s.cfg Barcelona, March
Spain 2010
4 20100427- 16368e3 4129945 Danish GPS 27th April 200 ms 20, 10ms
dgc-1s.cfg Centre, Aalborg, 2010
Denmark.
5 20100617- 16368e3 4129945 Gallecs, 17th June 200 ms 20, 10ms
glcs-1s.cfg Barcelona, 2010
Spain
6 20140212- 16.368e6 4.092e6 Universidad 12th 200 ms 20, 10ms
UAB-s1m1- Autónoma de February
30s.cfg Barcelona, 2014
Barcelona,
Spain
ID1 and ID4 are not reported: For ID1, the reference position was not known. For ID4, the
reference position is the same as ID2 and the results are similar. ID2 and ID6 are reported in
more detail, as an example of all the other captures. The process followed in the snapshot
receiver is based on three steps: Acquisition, Coarse Time Doppler and Coarse Time Code
Phase. They are described after presenting the test configuration.
4.5.1. Configuration
Here are the configuration parameters of the ID2 and ID6 datasets.
 True Position (Lat[º], Long[º], h[m, WGS84]):

o ID2: 57.01473071 , 9.9859041 , 59.998
o ID6: 41.50408 , 2.09924 , 209.009
 True time:
12
The snapshot function left 1ms unprocessed between snapshots. This is why a total of 220ms was read, out of which 10 ms
out of 11 ms of data were processed.
143
o ID2: 2010/3/2 , 12:14:04

o ID6: 2014/2/12 , 15:15:00
 Initial position (X,Y,Z): (0,0,0)
 Initial time:
o ID2: 2010/2/2 , 02:00:00 (28.43 days error)
o ID6: 2014/2/6, 04:00:00 (6.47 days error)
 Coarse Time Doppler Interval: 180 mins. Every 180 minutes a new solution is
calculated.
 Number of solutions: 20.
 Elevation mask: 5º
 Integration Time for each solution: 10 ms.
 Coherent Integration time: 1ms
 Non-coherent integrations: 10
 Doppler Solution - Residuals Threshold: 15 m (i.e. 78.9 Hz for L1)
 Code Solution - Residuals Threshold: 500 m.
 Maximum Height: 20000m (above WGS84 geoid).
 Acquisition Method: code-phase parallel acquisition.
 Acquisition Frequency Bin Step: 500 Hz.
All tests were performed over static receivers. The satellite ephemerides for the time
uncertainty period are obtained from RINEX Navigation files downloaded from a server
(ftp://cddis.gsfc.nasa.gov).
4.5.2. Signal Acquisition
First, acquisition is performed over a data snapshot. Acquisition leads to a set of

Frequency/Code-Phase bins for the acquired satellites. Acquisition is performed coherently
for 1 ms with 10 non-coherent integrations, for a 10-ms total. The signal acquisition method
used is based on the non-coherent code phase parallel acquisition. It is described in [13] and
[67], and depicted in Figure 53. It is based on the following steps:
 For each frequency bin, the signal is converted to baseband in its I and Q components
by multiplying by the carrier.
 The resulting complex baseband signal is transformed through a discrete Fourier
transform (DFT) into a function in frequency.
144
 The PRN code under search is also transformed through a DFT.
 The two frequency functions (signal and code) are multiplied, which is equivalent to
their convolution in time.
 The inverse Fourier transform of the multiplication of the signal and code is
calculated. If the signal is found, a peak will be observed at a given time,
corresponding to the code phase measurement. If not, no peak is observed.
Figure 53 – Block diagram of Code phase parallel acquisition [13]
4.5.2.1 Fine Tuning for Open-Loop Code Phase and Frequency Accuracy
One of the limitations of open-loop positioning is that, without any additional processing, the
code phase accuracy is limited by the sampling frequency. If parallel code acquisition is
performed, the acquisition peak will tell which the sample with the highest peak is, but the
actual code delay will usually be between samples.
Assuming that the peak is close to sample T, to obtain a more accurate delay measurement,
interpolation between the samples T-1, T and T+1 can be performed. For that, the acquisition
values for these three samples can be fitted to a function, and the maximum of the function
will provide the peak. [65] proposes two types of interpolations: quadratic and piecewise
linear. The quadratic interpolation fits the correlation results with a parabola, and the
piecewise linear with a triangle. In the current implementation, the quadratic interpolation has
been used, as it is shown by the above reference that its results are similar in the presence of
noise.
145
Figure 54 - Quadratic Peak Interpolation - Sample '1' corresponds to the peak. Sampling Frequency = 16.368e6.
GPS PRN 2 in ID6 data capture, first snapshot.
As regards frequency accuracy, once the code phase measurement has been obtained, the
signal can be de-spread to leave only the frequency carrier, and transformed through DFT
into a function of frequency, in which the maximum provides the fine-tuned Doppler
measurement.
The acquisition results for ID2 and ID6 scenarios are shown below in Table 21. For each
scenario, the results show the PRN of the satellite acquired; the frequency, which is around
the front end intermediate frequency fif; the measured Doppler; the code offset, in samples;
the acquisition peak metric (compared to the second peak); the predicted Doppler for the
actual position; the difference of the two; and the elevation and azimuth of the satellite. All
Doppler measurements are given in Hz.
Table 21 – ID2 and ID6 acquisition results

ID2 - DGC
*=======*=============*===========*=============*=============*===========*===========*==============
| PRN | Frequency | Doppler | Code Offset | Peak Metric | Dopp Pred | Dopp Diff | el[º],az[º] |
*=======*=============*===========*=============*=============*===========*===========*==============
| 4 | 4.13386e+06 | 3913 | 15349 | 15.62 | 3125 | 788 | 26, 302
| 11 | 4.12733e+06 | -2612 | 8070 | 11.84 | -3393 | 781 | 31, 164
| 12 | 4.13028e+06 | 338 | 7408 | 5.47 | -438 | 776 | 9, 347
| 13 | 4.13461e+06 | 4670 | 6089 | 4.26 | 3888 | 782 | 19, 205
| 17 | 4.12949e+06 | -450 | 4456 | 16.86 | -1232 | 782 | 37, 262
| 20 | 4.13048e+06 | 533 | 5112 | 24.97 | -181 | 714 | 85, 147
| 23 | 4.13341e+06 | 3468 | 3229 | 38.07 | 2691 | 777 | 47, 193
| 30 | 4.13180e+06 | 1860 | 11739 | 3.22 | 1080 | 780 | 7, 17
| 31 | 4.13081e+06 | 861 | 10530 | 13.87 | 77 | 784 | 31, 66
| 32 | 4.12869e+06 | -1254 | 14314 | 23.27 | -2037 | 782 | 54, 87
*=======*=============*===========*=============*=============*===========*===========*==============
ID6 - UAB
*=======*=============*===========*=============*=============*===========*===========*==============
| PRN | Frequency | Doppler | Code Offset | Peak Metric | Dopp Pred | Dopp Diff | el[º],az[º] |
*=======*=============*===========*=============*=============*===========*===========*==============
| 2 | 4.08893e+06 | -3067 | 15882 | 6.01 | -3026 | -41 | 11, 217
| 5 | 4.09190e+06 | -101 | 6552 | 25.00 | -68 | -34 | 72, 255
| 7 | 4.08913e+06 | -2872 | 16355 | 3.05 | -2912 | 39 | 28, 50
| 8 | 4.09056e+06 | -1444 | 10912 | 22.46 | -1417 | -27 | 62, 45
| 9 | 4.09067e+06 | -1327 | 12274 | 33.04 | -1295 | -32 | 67, 41
| 10 | 4.08863e+06 | -3372 | 1762 | 13.53 | -3403 | 31 | 32, 155
146
| 15 | 4.09482e+06 | 2818 | 14466 | 4.39 | 2863 | -45 | 19, 290
| 26 | 4.09365e+06 | 1655 | 3466 | 24.70 | 1686 | -31 | 54, 306
| 28 | 4.09360e+06 | 1600 | 11524 | 20.19 | 1568 | 32 | 44, 123
*=======*=============*===========*=============*=============*===========*===========*==============
We can observe that, for example, the Doppler difference is close to zero-average for ID6,
meaning that the frequency drift of the receiver clock was low, while there is a bias of around
770 Hz per second in ID2.
4.5.3. Coarse Time Doppler Stage
Coarse Time Doppler time uncertainty windows of 3 hours (i.e. one coarse time Doppler
computation every 3 hours) are selected because plausible Doppler solutions with GPS
appear every 6 hours, as shown before (GPS orbits repeat every 12 hours; every 12 hours
there is a plausible -low residuals- position in the opposite side of the Earth, same
hemisphere, but every 6 hours there is a plausible Doppler position in the opposite
hemisphere, as all the satellites are in the contrary hemisphere after 6 hours.
The proposed coarse time Doppler equations have been solved using a Taylor first order
linearisation, as in the standard literature and a solution has been estimated through least
squares [2] [5] [70]. If the solution is good, it is expected that the Doppler measurement
residuals will be low. The algorithm therefore relies on the solution residuals to assess the
correctness of the coarse-time Doppler algorithm.
To illustrate the residuals obtained, Figure 55 presents some magnitudes of instantaneous

Doppler solutions over time. Note that in the coarse-time Doppler algorithm proposed, when
in the proximity of a solution, the least squares approximation will converge to it. The plots
present the residuals over a period between -10 hours and +10 hours around the correct
measurement time.
Figure 55 top-left plot presents the measurement residuals. It shows that the residuals are
very low at the correct time. It also shows some relatively low residuals at +/- 360 min, i.e.
every 6 hours, or half the GPS 12h orbital period. The residual vector is in the order of 100
m/s, or 526 Hz. Other tests have shown similar low residuals.
Figure 55 top-right plot shows the actual position error, which is very high in all cases except
at the right timing. The bottom-left plot shows the estimated clock frequency offset fo (or
clock drift). For the right timing, it is shown that it crosses slightly above zero, i.e. at around
100 m/s. This implies that the frequency offset is around 100 / 0.19 = 500 Hz off per second,
147
or around 500 / 1575.42*106 = 0.3 ppm off, which is a clock stability one could expect from a
TCXO receiver clock.
Figure 55 bottom-right plot shows the height of the estimated position, which is close to zero
for the correct time, and not far from zero at +/- 6h. The low residual repeatability is further
analysed in the next section.
Figure 55 - Instantaneous Doppler Positioning for scenario ID2 (DGC). Instantaneous Doppler solutions are
calculated once every minute. Top-left: Doppler measurement residuals vector module. Top-right: Position error.
Bottom left: Estimated frequency drift. Bottom right: Estimated position height.
The measurement residuals of the every-3-hour CT-Doppler solutions are regarded for
consideration in the CT-Code Phase solution. Only the position and time reference of below-
threshold residuals solutions (residual vector below threshold), are considered for the CT-
Code Phase stage.
4.5.3.1 Low Doppler Residuals due to GPS Orbital Repeatability
Figure 55 showed relatively low residuals every 6 hours, but generally not low enough to
remain undetected by the residuals check. They may appear because a similar satellite
geometry is found at the other hemisphere at 1/2 an orbit, possibly if all satellites would be
allocated perfectly to their slots. The 6-h effect has not been analysed in detail as it is not
found problematic, and is left for further study. However, the most problematic orbital
repeatability effect is not shown in the figure and occurs every 12h for GPS, as explained
before. As already mentioned, thanks to errors in the orbital and clock estimations, the
148
algorithm can discriminate at the coarse-time range algorithm between the correct and
incorrect solutions. If orbits were perfect and clocks had no drift, all plausible Doppler
solutions would pass the coarse time pseudorange solution threshold as well.
4.5.4. Coarse Time Navigation and Final PVT Calculation
As mentioned, the initial coarse time Doppler solutions are then used for the coarse time
pseudorange algorithm. The measurement residuals of the coarse time code phase solutions
are looked at, and the final solution taken has residuals below the threshold.
The PVT calculation has been performed by solving the system in Equation (4.1) through
least-squares estimation. Once reconstructed, the pseudoranges can be approximated as
follows (satellite indices have been omitted):
𝜌=𝑟+𝑏+ 𝐼+𝑇+ 𝜀 (4.11)
Where 𝜌 is the pseudorange, 𝑟 is the actual range, b is the receiver clock bias, 𝐼 is the
ionospheric delay, 𝑇 is the tropospheric delay and ε is the error due to other factors: receiver
noise, sampling and quantization, effects from the receiver clock drift, and multipath [2]. The
tropospheric error has been estimated following [71], which is the function implemented in
[13]. For the ionospheric correction, the Klobuchar model [72] broadcast by GPS has been
used. A Klobuchar error correction model has been coded in Matlab for the experimental
work of this dissertation following the GPS interface specification [11].
4.5.5. Results
As an example, below the screen outputs of the algorithm are shown. It shows that, in the ID2
run, the 5-state Doppler algorithm was run 241 times, and 85 low-residual solutions were
found, out of which only one had low-enough code-phase residuals, which is considered the
correct solution.
Table 22 – Example of "cold snapshot" algorithm outputs, ID2. The 5-state (coarse time) Doppler is executed for
241 possible initial times, separated by 180 min. each.
********************************************************
**** INITIAL CONDITIONS ****
Initial(I):0.00000°N 0.00000°E -6378137.00m; 6363188.18m error
Initial(II):2/2/2010 1:59:45 DOY 33, GPSw 1569, GPSs 180000s; -2456059s, -
28.43 days error
**** DOPPLER NAVIGATION ****
Running 5-state Doppler 241 times...
85 solutions found
**** COARSE TIME NAVIGATION ****
+ + + PRCT nav(OK): (I):57.01473°N 9.98589°E 56.58m; 3.52m error; Mres:
149
10.497(m | m/s)
+ + + PRCT nav(OK): (II):2/3/2010 12:14:3.5389 DOY 61, GPSw 1573, GPSs
216858.5389s; -0.46113s, -0.00 days error
The rest of this section shows the final accuracy obtained for all scenarios except ID1 and
ID4 (for ID1 –Colorado-, the exact position was unknown, and ID4 –DGC- results are similar
to ID2).
The RMS-3D (Root Mean Squared, 3-Dimensional) error is in the order of 10-11 meters for
ID2 and ID6, and around 31-33 meters for ID3 and ID5. The RMS-2D error (not to confound
with 2drms error, as explained in [73]), is generally below 6.5 meters, except in ID3 which
rises to around 11 meters. In this scenario, a bias in the average horizontal position can be
seen in the figure, likely due to an error in the reference position used. In any case, the
performance is not far from that of standard GPS receivers. The higher vertical than
horizontal error may be due to ionospheric effects or geometry, which could be seen in the
DOP (Dilution of Precision).
Figure 56 – Left: Position errors of 20 10-ms snapshots. Right: Horizontal "cold snapshot" results - Scenario ID2 -
Danish GPS Centre, Aalborg. 2DRMS means RMS in 2 Dimensions (horizontal RMS)
150
Figure 57 – Left: Position errors of 20 10-ms snapshots. Right: Horizontal "cold snapshot" results - Scenario ID6 -
UAB, Barcelona.
Figure 58 – Left: Position errors of 20 10-ms snapshots. Right: Horizontal "cold snapshot" results - Scenario ID3 –
CTAE, Barcelona
151
Figure 59 – Left: Position errors of 20 10-ms snapshots. Right: Horizontal "cold snapshot" results - Scenario ID5 –
Gallecs, Barcelona. 2DRMS error means RMS error in two horizontal dimensions.
As the main purpose of the experimentation is to demonstrate the "cold snapshot" concept, a
further characterisation of the accuracy results is out of scope. Taking into account that open-
loop acquisition has been implemented, without any tracking loop fine-tuning or multipath
mitigation strategy, and there accuracy of the measurements has not been the focus of this
research, the performance are considered in line with the expectations.
4.6. Conclusions
This chapter of the dissertation has presented a new algorithm to instantaneously calculate
PVT over snapshots without any position and time reference has been presented. The
algorithm is based on the addition of one unknown to the instantaneous Doppler equations
[5], which accounts for the time difference, which can be in the order of hours, allowing an
iterative process to solve time uncertainties up to days, weeks or even months, by verifying
the solution residuals. In principle, there is no limit in the time uncertainty, other than CPU
time, which increases due to the higher number of iterations (8 per day with the current
configuration). Using multi-GNSS to avoid orbital repeatability and some refinements to
cope with non-linearities may reduce the number of iterations in a given period.
The algorithm has been implemented in a snapshot receiver in Matlab, validating the
hypotheses. Accuracies of few meters have been obtained almost instantaneously with time
uncertainties of several days.
152
Accuracy is not dependent on time uncertainty. The algorithm has implemented in a GPS L1
C/A snapshot open loop receiver (i.e. with no tracking loops) in Matlab. Accuracies obtained
for the scenarios analysed are in the order of 6 to 11 meters 2D-RMS and 10 to 30 meters 3D-
RMS, in line with the expectations.
153
Chapter 5. Generalisation of Snapshot

Positioning
5.1. Motivation
GNSS signals are received at a very low power (around -160 dBW). This makes GNSS
positioning difficult indoors and vulnerable to interference. This chapter explores snapshot
positioning with signals from satellites other than GNSS. In addition to currently existing
satellites and constellations, as e.g. Iridium, Globalstar, Orbcomm or the hundreds of
geosynchronous satellites in the geostationary belt, there are plans by some companies like
Google or SpaceX to launch new satellite constellations for broadband worldwide internet
connection [74]. A positioning system based on signals from other already existing and to-be-
launched satellites could complement existing GNSS to make position, navigation and timing
more available and resilient. The proposed method can add more ranging sources to a
radionavigation solution, use stronger or broader bandwidth signals than those from GNSS to
improve indoor localisation and add robustness against interference.
From a radionavigation service provider point of view, a snapshot based positioning system
can be also advantageous, as it can reduce space segment costs by relying on existing
satellites, simplify the on-ground estimation of satellite positions and clock errors and reduce
risks and dependability of critical infrastructures as GNSS.
154
Figure 60 – Operational, Partly Operational and Spare Satellites, Apr. 2015 - source: Spacebook.
Generic satellite signals may not be adequate for navigation for various reasons. First, they do
not provide their position, so receivers need to get their position from another source. Second,
if positioning is based on TOA or TDOA, the satellites need to be synchronised to a common
time reference, and use stable clocks. In addition, the signals, due to their power and
bandwidth, may not be suitable for accurate navigation.
The main motivation of this chapter is to study how snapshot positioning techniques can
overcome these limitations. After presenting some well-known satellite communication
systems and signals, and a snapshot method to locate a receiver using generic radiofrequency
signals is presented. The proposed method requires a monitoring network of stations and a
user receiver. It is based on the following steps: First, Both the user receiver and a ground
segment with monitor stations spread across the region over which the service is provided,
capture a snapshot of the signals that will be used for positioning. Then, the ground segment
calculates the instantaneous position of satellites visible by at least four stations by
triangulation. Finally, the user position is calculated based on the instantaneous satellite
positions, velocities and clocks calculated by the ground segment, and the snapshot received
by the receiver.
The proposed method, and a signal simulator allowing to do some testing, have been
implemented in Matlab. The tests present the experimental results of snapshot positioning of
155
one satellite, based on a ground monitor station segment, and the snapshot positioning of a
user receiver, based on the snapshot position and other reference parameters of four satellites.
5.2. Background
5.2.1. Overview of non-GNSS Constellations, Satellites and Signals
Satellite navigation signals and constellations have some common features that make them
suitable for navigation. They use medium earth orbit (MEO) satellites with ultra-stable
atomic clocks. Their signals are transmitted in the L band using spread-spectrum techniques,
generally through multiple frequencies. They are received on Earth at a low power, -125dBm
to -130 dBm, below the noise level. This section provides an overview of non-GNSS
satellites and constellations, and assesses the suitability of some non-GNSS satellites and
signals for navigation. Some references are provided where more detailed information can be
found.
The Union of Concerned Scientists (UCS) provides an exhaustive list of satellites using
general public information, including orbital description [75]. This database includes
launches until 31 Jan 2015. 1265 satellites are listed at the time of this writing, for civil,
governmental and military users, and for use in earth and space observation, communications
and navigation. Around half of the satellites in the database are LEO satellites (669 out of
1265) and the other half is divided between GEO satellites (465), MEO (94) and elliptical
(37).
GEO satellites are not the best for the method proposed in this chapter due to the geometric
dilution of precision of snapshot triangulation, which significantly affects accuracy. For
GEO-based snapshot positioning, the GEO satellites should be tracked continuously on
ground, as is the case for SBAS GEO satellites, and then their reference parameters could be
transmitted in snapshot mode to the user. As regards LEO satellites, they are (geometrically)
more adequate for positioning, although they require a higher density of monitor stations to
cover a given area.
A full characterisation of all satellites for positioning can be a daunting task and is considered
out of scope of this chapter. However, some examples of popular constellations are provided
here. The satellite systems described are O3b (MEO), Globalstar and Idirium (LEO).
156
O3b satellites fly at around 8000 km altitude. A constellation of 20 satellites is foreseen by
2015. They will provide a bandwidth of around 150 Mbps through signals in the Ka band,
through FDMA, CDMA and TDMA combined modulation techniques [76]. The satellite-to-
user frequency bands are foreseen in the 17.70 – 20.20 GHz range [77].
Around 45 Globalstar satellites currently orbit the earth at around 1400 km altitude. They are
placed in 8 orbital planes at an inclination of 52 degrees, with 6 equally spaced satellites per
orbital plane. They use the L-band (1610–1626.5 MHz) for user-to-satellite transmissions,
and the S-band (2483.5–2500 MHz) for satellite-to-user transmissions, providing voice and
data communications to mobile and fixed users [78]. Globalstar signals are modulated
through an extension of IS-95 CDMA used for terrestrial communications. This means that
signals combine FDMA and CDMA access techniques. For each frequency, the channel
bandwidth is 1.23 MHz, for a chip rate of 1.2288 Mcps. Data channels used by Globalstar
support 9600, 4800, and 2400 bps.
Iridium satellite constellation is composed by 66 satellites orbiting at 780 km height, in six

near-polar orbital planes. They use the L-band (1616 to 1626.5 MHz bandwidth) and FDMA
and TDMA signals. FDMA divides the 10.5 MHz bandwidth in 240 channels of 41.6 KHz.
Due to its low orbit, Iridium satellites have a footprint radius of 2209 km [79] [80].
One of the major advantages of non-GNSS signals is that they are generally received at a
higher power than GNSS signals. For example, in the case of Iridium, C/N0 of its signals
received outdoors are in the order of 80 dBHz [81], i.e. around 35-40 dB higher than GPS
signals. This allows the reception of the signals in highly attenuated indoor environments.
Table 23 provides a summary of Iridium, Globalstar and O3b systems and signals.
Table 23 - Iridium, Globalstar and O3B system and signal properties. 13
13
"Iridium Satellite" by Cliff under CC BY 2.0 via Wikimedia. Globalstar satellite IMAGE from Globalstar. O3B Satellite
image from TAS.
157
System Iridium Globalstar O3B
Nb. Sats aprox. 66 45 20
Orb. Heigth 780 km 1400 km 8000 km
Sat-to-User L S Ka
Frequency
Band
Sat-to-User 1616-1626.5 MHz 2483.5–2500 MHz 17.70 – 20.20 GHz
carrier
frequencies
Access FDMA, TDMA FDMA, CDMA FDMA, CDMA, TDMA
Technique
Signal 10.5 MHz 1.23 MHz ≥ 150 MHz
bandwidth (1-
sided)
Bit/chip rate 50 Kbps 1.2288 Mcps 150 Mbps
In addition to the existing systems, there are some recent initiatives for deploying future
commercial constellations: OneWeb proposes a satellite constellation to be composed of
around 650 satellites for providing internet around 2019, with backing of Qualcomm and
Virgin. Google has also presented plans of launching thousands of LEO satellites for various
purposes [74].
5.2.2. Background on Positioning with Non-GNSS Satellites
This section presents a short overview of reported positioning techniques using non-GNSS
satellites, and some references. One advantage of LEO satellites is that their signals have high
varying Doppler shifts, as they move at higher relative speeds than MEO GNSS satellites. For
example, Globalstar is known for offering a positioning service providing around 10-km
accuracy [82]. Some research of positioning techniques using Globalstar satellites shows a
method to instantaneously calculate a position with just one Globalstar LEO satellite [83].
The method is based on combining range and range rate measurements similarly to the
method proposed in [5].
Concerning Iridium, work has been performed to combine Iridium signals with GPS signals
[84], [85]. A system called IGPS uses Iridium fast-changing Doppler measurements to help
solve carrier ambiguities and add robustness against failures. [86] proposes an integration of
GPS and LEO communication signals for E911, in which LEO range rate measurements are
combined with RF pattern matching to increase availability indoors. [87] also proposes
158
techniques to combine LEO satellites with GPS to enhance navigation capabilities. They rely
on increasing geometric diversity (wrt. GPS alone) and helping the resolution of carrier phase
ambiguities, achieving centimetre-level accuracy.
While the methods proposed improve significantly navigation performance and robustness
compared to GNSS alone, they are based on the processing over a time interval of the signals.
Even if they allow a relatively low time to fix, they are not strictly based on snapshot
positioning techniques. More generally, the combination of GNSS and non-GNSS ranging
sources is dealt with in the mobile location domain, where GNSS signals are combined with
signals-of-opportunity from base stations [4] or wireless access points [88].
5.3. Signal and Error Model

This section proposes a signal and error model for the snapshot generalisation proof-of-
concept. This model follows standard models used in GNSS literature. The main difference
with standard models is that the satellite frequency drift is explicitly taken into account, to
model high frequency drifts from satellite clocks that are not as stable as GNSS satellite
clocks. This term is very small in GNSS satellites and is generally neglected in other models.
For the snapshot generalisation proof-of-concept, a signal as it should be transmitted at an

instant t by a satellite can be modelled as follows:
𝑠(𝑡) = 𝐴𝐶(𝑡) cos(2𝜋𝑓𝑐𝑎𝑟𝑟 𝑡 + 𝜑(𝑡)) (5.1)
Where A is the signal amplitude, 𝑓𝑐𝑎𝑟𝑟 is the signal carrier frequency, 𝜑(𝑡) is the signal phase
offset and C(t) is a sequence of [+1,-1] symbols, each of period TC, when the signal is
transmitted, or zero when the signal is not transmitted (allowing to represent TDMA signals).
The proposed signal assumes a PSK (Phase Shift Keying) modulation. C(t) represents a
sequence of chips irrespectively from whether they belong to spreading codes or useful data
sequences. Now, we can model the signal as actually transmitted by the satellite, affected by
a bias and a drift, as follows:
𝑠𝑡𝑥 (𝑡 + 𝑏𝑡𝑥 ) = 𝐴𝐶(𝑡) cos(2𝜋(𝑓𝑐𝑎𝑟𝑟 + 𝑓𝑑𝑡𝑥 )𝑡 + 𝜑) + 𝜀𝑡𝑥 (5.2)
Where 𝑏𝑡𝑥 is the time bias in the satellite clock at instant t, 𝑓𝑑𝑡𝑥 is the satellite clock
frequency drift at instant t, and 𝜀𝑡𝑥 is the signal error due to other factors (e.g. signal filtering,
carrier-code coherency, etc). Note that 𝑏𝑡𝑥 is the time derivative of 𝑓𝑑𝑡𝑥 , and therefore is
159
time-dependent, but this is not reflected in the equation. Snapshot positioning performance is
not so sensitive to the time variation of the errors, but to their absolute value at the snapshot
positioning time.
The signal, transmitted at 𝑡 + 𝑏𝑡𝑥 , is subject to errors in its propagation through the
atmosphere. When the signal arrives at the receiver, it arrives with a delay τ due to the
distance between the satellite and the receiver and additional propagation delays in the
atmosphere and local and filtering effects. This last term accounts for the errors due to
receiver filtering, code misalignment, quantization, frequency misalignment and multipath.
At reception, the frequency of the signal is modified due to the Doppler effect. Therefore,
when received and down-converted to intermediate frequency 𝑓𝐼𝐹 , the signal can be modelled
as follows:
𝐼𝜌 𝑇 ε𝜌
𝑠𝑟𝑥 (𝑡 + 𝑏𝑡𝑥 + τ + + + ) = 𝐴𝐶(𝑡) cos(2𝜋(𝑓𝐼𝐹 + 𝛥𝑓)𝑡 + 𝜑) + 𝜀𝑡𝑥 + 𝜀𝑟𝑥 (5.3)
𝑐 𝑐 𝑐
where 𝐼𝜌 corresponds to the ionospheric range error in the pseudorange, 𝑇 is the tropospheric
range error, and ε𝜌 models other error effects. This last term accounts for the errors due to
receiver filtering, code misalignment, quantization, frequency misalignment and multipath,
𝜀𝑟𝑥 corresponds to other non-modelled errors in the receiver. 𝛥𝑓 is the frequency difference
at which the down-converted signal is found with respect to 𝑓𝐼𝐹 , and can be modelled as
follows:
𝛥𝑓 = 𝐷 − 𝑓𝑑𝑟𝑥 + 𝑓𝑑𝑡𝑥 (5.4)
where D is the Doppler effect due to the relative satellite-to-receiver velocity and equivalent
to minus the range rate, and 𝑓𝑑𝑟𝑥 is the frequency drift in the receiver clock. Note that the
receiver clock drift has the inverse sign of 𝛥𝑓: the faster the receiver clock is running, the
'slower' the signals appear to arrive, so signal appears to the receiver to have a lower
frequency.
Equation (5.3) represents the signal in the reference time scale at reception time. However,
the receiver is not synchronized with this time scale. It just has its own reference time 𝑡𝑟𝑥 that
relates to the absolute time t by a bias 𝑏𝑟𝑥 .
𝑡𝑟𝑥 = 𝑡 + 𝑏𝑟𝑥 (5.5)
160
Therefore, the signal, as time-tagged by the receiver in its own local time scale, can be
represented as follows:
𝐼𝜌 𝑇 ε𝜌
𝑠𝑟𝑥 (𝑡𝑟𝑥 − 𝑏𝑟𝑥 + 𝑏𝑡𝑥 + τ + + + ) = 𝐴𝐶(𝑡) cos(2𝜋(𝑓𝐼𝐹 + 𝛥𝑓)𝑡 + 𝜑) + 𝜀𝑡𝑥 + 𝜀𝑟𝑥 (5.6)
𝑐 𝑐 𝑐
The receiver therefore receives the signal at 𝑡𝑟𝑥 − 𝑏𝑟𝑥 + 𝑏𝑡𝑥 + τ + 𝐼𝜌 /𝑐 + 𝑇/𝑐. It can
calculate the pseudorange 𝜌(t) as the estimated difference between signal transmission and
reception times t and trx, multiplied by the light speed.
𝑠𝑟𝑥 (𝑡𝑟𝑥 + 𝜌(𝑡)/𝑐 ) = 𝐴𝐶(𝑡) cos(2𝜋(𝑓𝐼𝐹 + 𝛥𝑓)𝑡 + 𝜑) + 𝜀𝑡𝑥 + 𝜀𝑟𝑥 (5.7)
𝜌(𝑡) = 𝑐(τ − 𝑏𝑡𝑥 + 𝑏𝑟𝑥 ) + I𝜌 + T + ε𝜌 (5.8)
5.3.1. Ranging Accuracy Estimation Through the CRLB
The positioning accuracy generally depends on two aspects: the DOP and the ranging error.
The DOP can be calculated from the equation system covariance matrix as described in [2].
As regards ranging accuracy, the Cramér-Rao Lower Bound gives the lower bound of the
variance of an unbiased estimator.
A didactic description of the CRLB in the frame of signal estimation theory is given Chapter
3 of [89] for different parameters to be estimated, such as frequency, carrier-to-noise or
range. In our case, the parameter to estimate is the satellite-to-receiver range. Depending on
how this parameter is estimated, the CRLB can be expressed in various ways. According to
(3.38) of this reference, the CRLB for range estimation can be expressed as:
1
𝑣𝑎𝑟(𝜏̂0 ) ≥
𝐸 (5.9)
( 𝑁0 ) ̅𝐹̅̅2̅
2
T 𝑑𝑠(𝑡) 2
∫0 𝑠 ( ) 𝑑𝑡
̅𝐹̅̅2̅ = 𝑑𝑡 (5.10)
T𝑠
∫0 𝑠 2 (𝑡)𝑑𝑡
Where 𝜏̂0 is the estimated range, 𝐸 is the integrated signal energy between 0 and Ts and 𝑁0 is
the noise power density. The factor ̅𝐹̅̅2̅ is indeed the mean square signal bandwidth.
Therefore, the higher the bandwidth, the lower the variance of the estimator, and the higher
the accuracy. We can therefore summarise by saying that, according to the CRLB, the signal
161
accuracy depends on a) the signal power to noise ratio, b) the signal bandwidth, and c) the
signal integration time in the receiver.
The abovementioned expression is suitable for our purposes under open-loop snapshot
positioning techniques, as it is not particularised to tracking loop parameters as e.g. tracking
loop bandwidth, but it is only dependent on the signals. Other expressions of the CRLB are
presented in [90], Chapter 2. They are particularised to Pulse Amplitude Modulations (PAM),
so they can also be used to the already digitalised signal. Chapter 3 of [91] also proposes a
CRLB formula particularised for GNSS. The work in this chapter is based on estimating the
CRLB based on Equations (5.9) and (5.10).
Considering that the target signals (mainly for communications) have a similar or wider
bandwidth than GPS L1 C/A, and their power is expected to be higher than that of GNSS
signals, and modern receivers allow long integration times, it seems worthwhile to consider
positioning with the characteristics of these target signals.
Figure 61 – Maximum accuracy achievable (standard deviation) according to Cramér-Rao Lower Bound for
different signal to noise density ratios and chip frequencies. 1-milisecond integration time
Figure 61 shows the accuracy signals at different C/N0 and chip (or bit) frequencies, for a
relatively short integration time of one millisecond. The bandwidth used is equivalent to the
chip frequency, and the sampling frequency is set to 4 times the chip frequency (Fs=4*Fc).
As expected, the figures show that high C/N0 and high bandwidths (i.e. high chip rates) lead
to higher accuracies.
5.4. Description of the Method

With more details than above, the method here proposed is based on the following steps:
162
1) Capture and store a digital snapshot by a user receiver, on a given frequency band
where the target satellite signals are transmitted.
2) Capture digital snapshots around the same frequency by several monitor stations
synchronised to a common time reference. These snapshots shall include or overlap
sufficiently in time with the snapshot captured by the user.
3) For a given satellite, estimate the range from the satellite to each monitoring station at
a given common time reference.
4) Determine the instantaneous satellite position and clock bias solution at the common
time reference based on the range measurements from at least four stations.
5) Determine the instantaneous satellite velocity and clock frequency drift solution at the
common time reference based on the range measurements from at least four stations.
6) Perform steps 3) to 5) for up to at least four satellites.
7) Use the satellite position, velocity, bias and drift at the given time reference from at
least four satellites, together with the satellite measurements obtained from the
snapshot captured by the user receiver, to compute the user receiver position.
Each step of the process is described in detail in the next subsections.
5.4.1. Capture of User Receiver Snapshot
We assume that a user receiver is loosely synchronised with a time reference, say, UTC
(Universal Time Coordinated) or GPST (GPS Time). The time reference chosen is not a
driver for the system, as long as it is coherent in all steps involved. We assume a loose
synchronisation of the receiver clock in the order of a few milliseconds, although a looser
synchronisation can be tolerable by extending the snapshot capture period accordingly. If the
signals to be used are transmitted continuously by the satellites (which is generally the case)
and can be properly demodulated and/or correlated by the ground segment, the user receiver
could take a snapshot at an arbitrary time reference.
The receiver captures a snapshot of digital samples associated to a time interval of

length/duration Δ between (tstart, tend). At this stage, the user receiver does not necessarily
know the properties of the signal to correlate, other than the bandwidth to capture and the
time interval during which the signal is correlated.
163
We consider two cases. In the first one (Case A), the snapshot capture is totally
asynchronous, i.e. the receiver captures the snapshot without any synchronisation whatsoever.
In the second one (Case B), the receiver is loosely synchronised with a time reference.
5.4.1.1 Case A – No Synchronisation
This is the simplest case for the receiver. The receiver captures a snapshot without any
constraint, assuming that signals usable for ranging are continuously transmitted by the
satellites and will appear in the snapshot. The time uncertainty can be solved by the snapshot
ground segment. In the below example, the receiver starts capturing the snapshot at its own
estimation of t0, i.e. t0rx. The snapshot length is the minimum length required to correlate the
signal, i.e. Δ = Δmin. This is shown in Figure 62.
Figure 62 – User receiver signal snapshot – Asynchronous case
5.4.1.2 Case B – Loose Synchronisation
In this case, the receiver correlates a snapshot of signals transmitted by each satellite j at t0tx,j,
i.e. at the satellite's own estimation of t0, which altered by satellite j's clock bias. The
minimum 'useful' snapshot duration required is Δmin, as in the previous case. The receiver
must have an estimation of the maximum biases of the satellites' clocks and its own clock,
and the maximum and minimum signal transit time. If this information is not known, a longer
snapshot can be taken, to ensure that the desired signals will be captured.
The snapshot start and end times are
𝑡𝑠𝑡𝑎𝑟𝑡 = 𝑡0𝑟𝑥 + 𝜏𝑚𝑖𝑛 − 𝑏𝑟𝑥,𝑚𝑎𝑥 − 𝑏𝑡𝑥,𝑚𝑎𝑥 (5.11)
𝑡𝑒𝑛𝑑 = 𝑡0𝑟𝑥 + 𝜏𝑚𝑎𝑥 + 𝑏𝑟𝑥,𝑚𝑎𝑥 + 𝑏𝑡𝑥,𝑚𝑎𝑥 + ∆𝑚𝑖𝑛 (5.12)
where 𝑡0𝑟𝑥 is t0 according to the user time reference, 𝜏𝑚𝑖𝑛 and 𝜏𝑚𝑎𝑥 are the minimum and
maximum transit times of the signal respectively (𝜏𝑚𝑖𝑛 represents the case where the satellite
is at the zenith, and 𝜏𝑚𝑎𝑥 can be bounded by 𝜏𝑚𝑖𝑛 plus the Earth radius*c), 𝑏𝑡𝑥,𝑚𝑎𝑥 is the
164
maximum user bias, 𝑏𝑡𝑥,𝑚𝑎𝑥 is the maximum satellite clock bias of any satellite extracted
from the snapshot, and ∆𝑚𝑖𝑛 is the minimum useful snapshot duration time. The biases can
apply in any sense, and this is why they are subtracted for 𝑡𝑠𝑡𝑎𝑟𝑡 and added for 𝑡𝑒𝑛𝑑 . Thus, the
user expects the satellites to transmit the signals expected at t0 between t0 - 𝑏𝑡𝑥,𝑚𝑎𝑥 and t0 +
𝑏𝑡𝑥,𝑚𝑎𝑥 . In our case, we assume that the user does not have a priori knowledge of the receiver
or satellite biases. If this were the case, the estimated biases should be taken into account and
the total snapshot length can be reduced. Figure 63 represents the total snapshot start, length
and end in a time scale. The target satellites do not necessarily use atomic clocks to
synchronise its signals, and therefore the satellite clock biases and drifts can be similar to
those in user receivers and have to be estimated. The effect in the snapshot duration of the
user or satellite frequency drifts is considered negligible.
Figure 63 – User receiver signal snapshot – Synchronous case
5.4.2. Capture of Snapshot at Monitor Stations
In order for the user to calculate her position, the instantaneous position and time of the
satellites used for the user position computation need to be known. For this, a snapshot
ground segment is required. This ground segment is in charge of recording digital samples of
the desired signals by a network of monitor stations, allowing computing the instantaneous
position of the satellites. A ground segment of monitor stations scattered across a given
service area and synchronised with a common time reference (e.g. through a GPS receiver)
are required to capture data snapshots. Figure 64 depicts a ground segment formed by 5
monitor stations (m1 to m5). The figure depicts how these stations receive a signal from a
given satellite at different times (t1 to t5), depending on the time of arrival of the signal.
165
Figure 64 - Satellite signal snapshot reception by a ground monitor network
As the proposed system is a generalisation of snapshot techniques for different types of

signals, no signal properties as carrier, modulation, bitrate, etc. are specified at this stage.
However, it is assumed that the monitor stations are able to demodulate and/or correlate the
signal and extract a sequence of bits or chips that can be used to compute the signal time of
arrival.
Concerning the equipment required at the monitor stations, commercial off-the-shelf

previously geo-located USRPs (Universal Software Radio Peripherals) with sufficient storage
capabilities and synchronised to a GPS-based time reference through a 1PPS would suffice.
In any case, for the ground segment to provide the snapshot reference parameters, it is not
mandatory that the ground segment use snapshot satellite positioning techniques. It can
continuously track the satellites and estimate their parameters through Kalman filters or other
techniques, as applied in current GNSS. However, for the rest of the chapter, and in order to
assess snapshot ground segment performance, the proposed ground segment also uses
snapshot techniques.
5.4.2.1 Case A – No Synchronisation
In this case, the relaxation of requirements in the user receiver would increase the
requirements at the ground segment. The ground segment should continuously monitor the
satellites by either tracking their signals in a classical way, or performing continuous
166
snapshot positioning. This general case is left aside of the dissertation and proposed for
further work. The proposed concept is better explained through the loose synchronisation
case.
5.4.2.2 Case B – Loose Synchronisation
In this case, each station would capture a snapshot of the signal in a similar fashion as in step
2), with the difference that, if the reference station is accurately synchronised with the time
reference, the term 𝑏𝑟𝑥,𝑚𝑎𝑥 will be in the order of nanoseconds and can be neglected for the
calculation of the snapshot interval. Therefore,
𝑡𝑠𝑡𝑎𝑟𝑡 = 𝑡0 + 𝜏𝑚𝑖𝑛 − 𝑏𝑡𝑥,𝑚𝑎𝑥 (5.13)
𝑡𝑒𝑛𝑑 = 𝑡0 + 𝜏𝑚𝑎𝑥 + 𝑏𝑡𝑥,𝑚𝑎𝑥 + ∆𝑚𝑖𝑛 (5.14)
We assume, for simplicity, that the stations are perfectly synchronised with the reference time
and therefore the time estimation of t0 from all stations equals the actual t0. We also assume
no knowledge of the satellite time biases.
5.4.3. Signal Acquisition and Satellite Range Estimation
To illustrate this case, let us assume that a monitor station of the "Snapshot Ground Segment"
is able to time-tag the signals by correlating the received signal with a known pattern unique
for the satellite (as done e.g. for GNSS DSSS signals), or demodulating the received signal,
assigning it to a satellite based on its properties (carrier frequency, code sequences, etc.) and
time-tagging the demodulated sequence. In this case, the signal to correlate (i.e. the "useful
signal") is the snapshot of the signal appearing in white in Figure 65, and the method ignores
all other parts of the signal. We assume that the system can determine the "useful signal"
duration.
167
Figure 65 – Example of satellite signal time of arrival at different monitor stations (m1, m5)
5.4.3.1 Sliding Window Acquisition when ∆>>∆𝒎𝒊𝒏
Due to the satellite time bias uncertainty, there may be cases in which the time window to
perform acquisition may be too long, compared to the effective integration time ∆𝑚𝑖𝑛 . In this
case, a snapshot acquisition based on a sliding window may be applied, as illustrated in the
following example and Figure 66:
 We capture a snapshot of Δ = 60 ms, where the "useful signal" is only 10 ms (Δmin)

and starts to be received at around tstart + 24 ms.
 The snapshot is divided into sliding time windows. A snapshot is taken every Tslide (5
ms), with a duration of Tslide+ Δmin = 15 ms.
 Each 15 ms window the snapshot is correlated with the 10 ms length replica, plus
zeros.
 In case the signal is acquired in more than one window (w3, w4, w5, w6 and w7 in the
figure), the time window with the highest correlation can be taken (w5). We assume
that other windows will only partially correlate the signal leading to a smaller peak.
Assuming that the monitor station is under good visibility conditions, signal
correlation should generally not be subject to high variations. The process can be
performed more than once to increase robustness. The proposed sliding time window
allows performing snapshot correlations over long periods without correlating the
whole snapshot, although at the expense of correlating the same signal slices several
times.
168
Figure 66 – Example of sliding window for snapshot acquisition. Highest correlation at w5.
The acquisition search space must take into account the fact that the satellite clock drift is
unknown. We assume, however, that monitor stations can have good clocks and their clock
drifts are low. Therefore, and taking into account that they are static, the only factors
contributing to the frequency search space are the satellite range rate and the satellite clock
drift.
5.4.4. Instantaneous Satellite Position and Clock Calculation
Once a set of satellite-to-monitor pseudorange measurements are obtained from the

acquisition process, the satellite position at a given time can be calculated.
The obtained pseudorange measurements 𝜌𝑖 and Doppler measurements 𝐷𝑖 for each station i
are subject to errors. Standard error models in GNSS literature are used here [2], as already
mentioned in section 5.3. The main difference here is that, as opposed to calculating the
position of a receiver based on 4+ satellites, we calculate the position of a satellite based on
4+ monitor receivers.
Classic position calculation methods in the literature involve Time Of Arrival (TOA) and
Time-Difference Of Arrival (TDOA). While TOA is more popular for satellite navigation,
TDOA, also known as hyperbolic positioning, is commonly used in communication systems.
For example, 3GPP and LTE-based positioning use TDOA to locate a user transmitting a
signal to the surrounding base stations [4]. In the current case, and given that the satellite
transmission time is unknown, the two options available are:
 Estimate a TOA solution with at least 4 stations, calculating the satellite position
(x,y,z) at the time the signal transmission started and a bias btx at t0.
 Estimate a TDOA solution with at least four stations, using a station as a reference
and calculating the satellite position (x,y,z) at the time the signal transmission started.
169
TOA and TDOA methods yield equivalent results in terms of DOP if measurements errors
are uncorrelated and homogeneous [92]. It is also proven in [93] that TOA and TDOA are
equivalent in a general case, even with non-homogeneous and correlated ranging sources. It
is recommended TOA over TDOA for simplicity in its implementation. Therefore, we
propose to solve the positioning problem using the TOA equations, and calculating a bias
term with respect to the time reference t0.
The following equation represents the satellite range determination through TOA for a
monitor station i:
𝜌𝑖 = √(𝑥𝑗 − 𝑥𝑖 )2 + (𝑦𝑗 − 𝑦𝑖 )2 + (𝑧𝑗 − 𝑧𝑖 )2 − 𝑏𝑡𝑥,𝑗 + 𝑏𝑟𝑥,𝑖 + I𝜌,𝑖,𝑗 + T𝑖,𝑗 + ε𝜌,𝑖,𝑗 (5.15)
where xj, yj, zj and btx,j are the satellite j position and bias unknowns, 𝑥𝑖 , 𝑦𝑖 and 𝑧𝑖 are the
coordinates of monitor station i, 𝑏𝑡𝑥,𝑗 is the clock bias of satellite j, 𝑏𝑟𝑥,𝑖 is the estimated bias
of monitor station i, 𝐼𝜌,𝑖,𝑗 , 𝑇𝑖,𝑗 and ε𝜌,𝑖,𝑗 are the ionospheric, tropospheric and other errors,
respectively.
The system of equations can be solved following a Newton-Raphson method and linearising
the equations through a first order Taylor series, as proposed in most GNSS literature already
referred to in this dissertation. In case the system is overdetermined, a least squares estimator
can be used to calculate the solution, as in standard satnav positioning, to minimise the
squared residual errors. The following steps are performed iteratively:
𝛿𝜌 = 𝐻𝛿𝑋 (5.16)
𝛿𝑋 = (𝐻 𝑇 𝐻)−1 𝐻𝑇 𝛿𝜌 (5.17)
where 𝛿𝜌 is an [m x 1] vector (m is the number of measurements) with the difference between

the estimated and obtained pseudorange measurements for a given X, 𝛿𝑋 is the updated
(x,y,z,b) solution with respect to the previous iteration, and H is the [m x 4] geometry matrix.
−𝑒 1 1
𝐻=( ⋮ ⋮) (5.18)
−𝑒 𝑚 1
where −𝑒 𝑖 is the unit vector between the satellite i and the monitor station (note that i is not
an exponent). As regards the initial position, in the case of standard satellite navigation, often
170
the position solution is initialised to a previously known value, or if no previous value is
known, the position is initialised to Cartesian coordinates (0,0,0). In our case, the satellite
initial position has been calculated by averaging the latitudes and longitudes of the stations
acquiring the signal, and adding an average height of the satellite orbit (which can be easily
known by the system. E.g. [94] provides real-time satellite information).
5.4.5. Satellite Velocity and Frequency Drift Calculation
The equations used to calculate the solution velocity and clock drift based on range rate
(Doppler with inverse sign) measurements are similar to those for the position and bias
calculation. They can be derived from the differentiation in time of the pseudorange equation
system, as shown in (6.33) of [2].
−𝛿𝐷 = 𝐻𝛿𝑣 + 𝜀 (5.19)
𝛿𝑣 = (𝐻 𝑇 𝐻)−1 𝐻𝑇 (−𝛿𝐷) + 𝜀 (5.20)
where 𝛿𝐷 are the Doppler measurements and 𝛿𝑣 is the vector (vx, vy, vz, fd) of the satellite
velocity and frequency drift.
5.4.5.1 Additional considerations about satellite clock errors
One of the main differences of GNSS-based positioning with respect to the proposed method
is that satellite clocks cannot be assumed as highly stable in this method. In the current
model, satellite clock errors have been modelled as a bias and a drift, whose magnitude can
be in the order of standard TCXO clocks in marketable GNSS receivers. This assumption
seems valid for very short snapshots, in which the clock drift can be considered as constant.
For much longer snapshots, including several hundreds of milliseconds, or even seconds, the
satellite clock stability may become a limiting factor. To further understand its effect, more
refined clock models, as for example those proposed in Chapter 11 of [95] or in [96], can be
used.
5.4.6. Reference Parameters for at Least Four Satellites.
At the end of this step, the "Snapshot ground segment" is able to calculate the 3D-position,
3D-velocity, clock bias and drift of a set of satellites. Therefore, the user position
computation process takes as an input for each satellite j the values pj(xj, yj, zj), vj(vxj, vyj, vzj),
btx,j, fdtx,j referred to a given time t0. If unknown to the user, the system can also provide the
171
bit sequence needed to correlate the signal seqj. Without further processing, the position (xj,
yj, zj) computed in step 4) refers not to t0 but to t0 + btx,j. The position can be translated to t0
by applying the calculated velocity, and assuming that during btx,j the velocity vector is
constant, as follows:
𝑐𝜏(𝑡𝑜) = 𝑐𝜏(𝑡𝑡𝑥 ) − 𝑏𝑡𝑥 𝑅𝑅 (5.21)
where RR is the range rate and c the light speed, so 𝑐𝜏 is the range. Figure 67 shows the
parameters available as an input for the user position calculation, for j=1,2,3,4.
Figure 67 – Diagram showing the information available to the user: position(t0), velocity(t0), bias(t0), frequency
drift and signal sequence to correlate from at least four satellites
5.4.7. User Receiver Position Calculation
Once the information for at least four satellites is available, a user receiver can easily
calculate its own snapshot position by extracting the pseudorange measurements from the
snapshot and applying standard techniques following equations (5.16) and (5.17).
5.5. Experimental Results: One Satellite Snapshot Positioning

This section describes the results of calculating the reference parameters of a satellite through
snapshot positioning techniques in a ground segment including six ground monitor stations.
First, the experiment configuration is presented, including the signal configuration
parameters, error models, monitoring receiver parameters, and so forth. Then, the steps for
the signal generation and satellite position computation are detailed. Finally, the results are
presented. The purpose of the experiment is to validate the satellite snapshot positioning
proof of concept and generally characterise its performance in a particular setup.
172
The signal and satellite analysed are fictitious. Their resemblance to GPS signals is due to the
convenience of using code developed in other parts of the thesis. However, the analysis is
considered generic enough so as to be extended to other signals. The satellite positions and
velocities are fictitious as well and do not consider the earth gravitational field, without this
limiting or invalidating the results.
5.5.1.1 Signal Parameters
For simplicity, the simulated signal is based on transmitting one GPS's DSSS BPSK L1C/A
code.
 Carrier frequency fcarr = 1575.42 MHz

 Chip frequency fc = 1/Tc = 1.023 Mcps.
 Code length: 1023.
 Data frequency: no data has been modulated.
 Code: 1023-chip Gold code as for GPS L1 C/A of PRNs 121 (SBAS satellite).
 Synchronisation: The satellite transmits only one code at t0 + btx, where btx is the
clock bias of the satellite.
 Received carrier to noise density ratio: C/N0 = 50 dBHz
5.5.1.2 Satellite and Propagation Parameters
The satellite is located at zero longitude, zero latitude and around 1630 km altitude. The
clock performance is considered similar to that of standard TCXO clocks. The satellite
velocity is set to arbitrary values. The currently proposed satellite speed is around 3.7 km/s,
while the speed of a satellite at that orbit would be around twice as much. This is considered
sufficiently representative for the proof-of-concept.
 XYZ ECEF (Earth Centred Earth Fixed) coordinates: (0, 0, 8000000) [m]
 Vxyz (ECEF): (1000, 2000, 3000) [m/s].
 Clock bias: 𝑏𝑡𝑥 = 20 ms
 Clock drift: 𝑓𝑑𝑡𝑥 = 1 ppm (1Hz / 106 Hz)
A normal error distribution of variance 1 m2 N(0,1) has been introduced to model signal
propagation errors. This simplistic model intends to account the residual ionospheric,
173
tropospheric and multipath errors. We know that it is not a fine-grained error model but it
seems enough for this section's objectives. It is also assumed that the ground segment can
have an available tropospheric and ionospheric real-time correction model and the stations
are sufficiently free from multipath. A more refined model including elevation dependent
errors and error contributions as that proposed in [2], Chapter 5, is left for future work. The
satellite initial positions and velocities are given in an ECEF frame. The simulator only uses
ECEF positions.
5.5.1.3 Monitor Station Parameters
We consider 6 monitor stations (M1 to M6) granting a reasonable geometry at the following
latitude (º), longitude (º) and height (m) (wrt. WGS84 geoid) positions: (0,0,0), (20, 0, 0), (0,
15, 0), (0, -20, 0), (-15, 0, 0), (10, 10, 0), as shown in Figure 68.
Figure 68 – Snapshot satellite positioning – Satellite and Ground monitor positions (Google Earth)
For this test, the monitor clock biases and drifts are considered zero: we can assume that the
monitors have good clocks, and any drifts and biases can be estimated to a level that would
not degrade the performance. These are the remaining common monitor station parameters:
174
 Intermediate Frequency fIF = 1.51 MHz
 Sampling Frequency fs = 16.7439 MHz
 RF Front End Central frequency: 1575.42 MHz
 RF Front End Bandwidth: fs /2
 Masking Angle = 5º
 Acquisition frequency step = 500 Hz
 Acquisition frequency bins = 81
The sampling frequency has been selected taking into account the fact that it should not be
commensurate with fc. The effect of commensurate frequencies for snapshot positioning is
that they will lead to a 'staircase' correlation peak that degrades the accuracy, as explained in
[65]. It is recommended to use a sampling frequency so that
𝑝
𝑓𝑠 = 𝑓 (5.22)
𝑞 𝑐
where p and q are prime numbers. In our case, p = 15991 and q=997.
The acquisition window length is 15 ms. We assume that the stations are roughly
synchronised (Case B above), i.e. they start acquiring the signal at around t0, i.e. the time the
signal is expected to arrive. The acquisition search is that presented in section 4.5.2 and
follows a parallel code-phase acquisition.
The acquisition search space, which usually ranges between -10 kHz and +10 kHz approx.,
can be covered with 21 bins being separated by 500-Hz. In our case, the 81 bins are used,
covering -40 kHz to +40 kHz. Leaving 10 kHz as a margin for other effects (satellite and
receiver clock drifts, receiver velocity), we have +/- 30 kHz for the satellite velocity, which at
the employed wavelength, would allow the acquisition of a satellite at a relative velocity of
approximately 5700 m/s. While this may not be enough for some LEO satellites, which orbit
at a speed around 7 km/s, it is enough for the demonstrator. Enlarging the acquisition search
space would make the simulation longer but would not change the results or the conclusions.
As the frequency Doppler depends on the wavelength, satellites at other carrier frequencies
may require careful analysis leading to a different frequency search space and step width.
This is left for further work.
175
5.5.2. Simulator Steps
This section describes the process of signal generation, acquisition at the monitors, and
satellite PVT computation.
5.5.2.1 Signal Generation
For each satellite-monitor pair, the monitor-to-satellite vector and range rate at t0 is
calculated. The theoretical range is generated taking into account the fact that, when the
satellite transmits the signal, it is at a different position than at t0, as expressed in Equation
(5.21).
The frequency at which the signal is generated emulates the frequency as received by the
monitor as per equations (5.3) and (5.4). The simulated range adds a random error following
the configured error model.
In general, in order to simulate the digitally sampled signal, the signal generator needs to
account for the frequency drift of the monitor, even if set to zero in this experiment.
𝑓𝑠,𝑚 = 𝑓𝑠 + 𝑓𝑑𝑚 (5.23)
where m is the identifier of the monitor station. With all these parameters, and the signal is
generated according to Equation (5.6). It is generated at a higher sampling rate (an x10
multiplication factor is configured in the simulator), and then down-sampled according to the
sampling rate of the monitor.
Once the signal is generated, noise is added according to the configured C/N0. For that, the
signal power is normalised to 1 Watt, and the noise power is calculated accordingly:
𝑓𝑠,𝑚
𝑃𝑛 = 𝑁0 (5.24)
2
Where 𝑃𝑛 is the noise power, and 𝑁0 is the noise density from the C/N0. The simulator could
be evolved to compute 𝑁0 by knowing the effective temperature from the front-end noise
figure following the Friis formula, e.g. from [5], Chapter 6. Once 𝑃𝑛 is known, the noise will
follow a normal distribution 𝑁(0, √𝑃𝑛 ).
The generated signal is also filtered to simulate the noise and delay filtering effects. An IIR
(Infinite Impulse Response) band-pass Butterworth filter with -3 dBs at both cut-off
176
frequencies and order 10 has been implemented. The cut-off frequencies are calculated
depending on the receiver bandwidth configured (see e.g. user configuration in section
5.6.1.4). Note that monitor stations can have wide bandwidths to minimise accuracy loss. In
the current configuration, to facilitate the comparison with theoretical results, no filtering has
been applied. Unlike end users, monitor stations can have wide bandwidths minimising this
effect, so it is not unrealistic to minimise filtering effects.
Figure 69 - Monitor snapshot generation: signal samples for one signal at 6 monitor stations. C/N0 = 70 dBHz. Fs
= 16.7439 MHz
The steps above are performed for each monitor stations, in order to generate all the signal
snapshots as illustrated in Figure 69. This figure shows the signal plus noise in the time
domain. A 1-ms fragment of the signal is received by each monitor. C/N0 has been raised to
70 dBHz to raise the signal visible above noise in the time domain.
5.5.3. Signal Acquisition and Parameter Estimation
The signal acquisition process is performed as explained theoretically before and according to
the configuration parameters. The satellite reference parameters estimated for each station are
the signal delay, frequency, bit sequence and C/N0. Delay and frequency are estimated as
177
mentioned before (parallel code-phase acquisition). The bit sequence in this case is known.
Concerning the C/N0, it is estimated by the method of moments [65], as follows14:
𝑋𝐵 − 𝑇𝑃
𝐶/𝑁0 = 10𝑙𝑜𝑔10 ( 2 ) (5.25)
𝑇 𝑃−𝑋
where X is the result of the squared peak, B is the signal bandwidth and T is the integration
time (1 ms). There are other standard methods in the literature, as proposed by A.J. Van
Dierendonck in Chapter 8 of [3], based on the difference between the non-coherent and
coherent averages in the correlation peak. However, for snapshot positioning, and in
particular the current experiment, given that averaging is not possible, the method of
moments is selected.
5.5.4. Satellite PVT Computation
Based on the range and frequency measurements calculated in the acquisition stage, the
satellite PVT can be calculated as per Equation (5.17). Satellite velocity and frequency drift is
estimated as per Equation (5.20). The satellite position is not calculated for t0, but for the
time the satellite transmitted the signal, t0 + btx . If the position to be reported is the satellite
position at t0, then the satellite movement during btx needs to be accounted, as per Equation
(5.21).
5.5.5. Results
This section reports the satellite positioning results obtained, over 50 runs. Figure 70 presents
the satellite error vector in three dimensions. Figure 71 represents the satellite error in 3D
coordinates. The capture below shows the acquisition results from each station, for one of the
runs.
** SNAPALL REPORT **
CRLB std. dev. [m]: 4.700
Elevations matrix [º]:

SV34
M1 90.00
M2 22.76
M3 33.09
M4 22.61
M5 33.25
M6 35.39
M1 Acquisition . SVID34 peak:10.18; PR Error: -6.21 m; f Error: 7.216 Hz; CN0: 49.42 dBHz
M2 Acquisition - SVID34 peak: 8.31; PR Error: 5.48 m; f Error: 60.177 Hz; CN0: 50.26 dBHz
M3 Acquisition - SVID34 peak: 7.31; PR Error: -1.23 m; f Error: 2.337 Hz; CN0: 48.12 dBHz
M4 Acquisition - SVID34 peak: 8.46; PR Error: 3.13 m; f Error: -20.206 Hz; CN0: 49.00 dBHz
M5 Acquisition - SVID34 peak: 9.98; PR Error: 1.92 m; f Error: 48.860 Hz; CN0: 49.88 dBHz
M6 Acquisition - SVID34 peak: 5.53; PR Error: -1.18 m; f Error: 31.444 Hz; CN0: 48.52 dBHz
14
The formula in [62] had an error that is corrected in the formula here proposed.
178
Locating Satellite SV01
GDOP: 5.12 PDOP: 4.13 TDOP: 3.03 xDOP: 3.90
( X, Y, Z, B)[m][s]:( 8000028.98 , -2.23 , 0.70 , 1.999992e-02)
( dX, dY, dZ, dB)[m][s]:( 28.98 , -2.23 , 0.70 , -7.603586e-08)
( VX, VY, VZ, FD)[m/s] :( 1009.77 , 2003.87 , 3001.42 , -1.318053e-04)
(dVX,dVY,dVz,dFD)[m/s] :( 9.77 , 3.87 , 1.42 , -1.328053e-04)
One can see that the results are more or less as expected. With a CRLB standard deviation of
4.7 m and a PDOP of 4.13, we can expect an RMS accuracy (assuming no biases, as is the
case) around 4.7 * 4.13 = 19.411m. We see that the RMS-3D error obtained is 19.95 m.
Figure 70 – Satellite position 3D error [m] and RMS-3D.
Figure 71 – Satellite position 3D error [m] in XYZ coordinates.
179
Figure 71 shows a much higher error in the X component. This is natural as the geometry is
especially bad in the vertical (or X) axis. The DOP values for the different components are:
GDOP = 5.1185; PDOP = 4.1272; XDOP = 3.8970; YDOP = 0.9540; ZDOP = 0.9680;
TDOP = 3.0275, which may explain the degradation in this component (XDOP) and in the
time (TDOP).
In summary, the results show an accuracy below 20 meters about two thirds of the time.
While not great, it is what can be expected from this geometry and signal delay estimation
accuracy. Signals with wider bands and using longer integration times will offer a higher
accuracy.
5.6. Experimental Results: User Snapshot Positioning Based on Satellite

Snapshot Positioning
This section presents the end-user performance of the snapshot generalisation method using
four satellites and a wider service area, based on satellites at a higher altitude and more
spread-out stations. As mentioned for the one-satellite case, the signals and satellite orbits
and velocities analysed are fictitious, but the analysis is considered generic enough to be
applicable to other signal and satellites.
5.6.1.1 Signal Parameters
Signal parameters are the same as in the previous test. The Gold codes used for the four
satellites under test correspond to PRNs 121, 122, 123 and 124.
5.6.1.2 Satellite and Propagation Parameters
The satellite configuration parameters are:
Table 24 - Satellite Parameters
SAT PRN Position at t0 [X;Y;Z], Velocity at t0 Clock bias Clock drift at t0 [s/s] Initial
ECEF [m] [VX;VY;VZ], at t0 [s/s] Orbital
ECEF [m/s] Radius [m]
1 121 [18000e3; 0; 0] [0; 1000; 2000] 5e-3 1e-7 (0.1 ppm) 7000e3
2 122 [1.5588e7; -9e6; 0] [2000 ; 0 ; 1000] 8e-3 -1e-7 (-0.1 ppm) 18000e3
3 123 [1.5588e7; 9e6; 0] [1000 ; 2000 ; 0] -6e-3 1e-8 (-0.01 ppm) 12000e3
4 124 [1.039e7; 1.039e7; 9.237e6] [-1000 ; -2000 ; 0] -4e-3 1e-8 (0.01 ppm) 12000e3
180
The Initial Orbital Radius parameter represents the initial height at which the least-squares
position estimator starts. The same normal error distribution of variance 1 m2, denoted as
N(0,1) as before has been used.
5.6.1.3 Monitor Station Parameters
6 Monitor stations (M1 to M6) have also been used in this case, at the following positions
(lat(º), long(º), h(m wrt. WGS84)): (0, 0, 0), (45, 0, 0), (0, 45, 0), (0,-45, 0), (-45, 0, 0), (20,
20, 0), as shown in Figure 72.
These are the common monitor station parameters:

 RF Front End Bandwidth: fs /2
 Acquisition frequency step = 500 Hz
 Acquisition frequency bins = 81
Figure 72 – Snapshot ground segment, including 6 stations and a test user.
Here are some additional comments on the monitor station parameters:
181
 Stations 2 to 5 are in the same plane. A solution based on measurements from these
four stations would lead to a rank-deficient matrix. This is supposed to be mitigated
by stations 1 and 6. Nevertheless, optimum geometry solutions have not been studied
yet.
 For the moment, the biases and drifts are set to zero. It can be realistically assumed
that monitor stations can have good clocks (or a GNSS receiver) and time errors
would be in the order of the nanosecond, or below.
5.6.1.4 User Receiver Parameters
The user receiver parameters are:

 RF Front End Bandwidth (single-sided): 3 MHz
 Acquisition frequency step: 500 Hz
 Acquisition frequency bins: 81
 User clock bias: brx = 3 ms
 User clock frequency drift: fdrx = 2 ppm (2 cycles per million cycles)
The frequency plan has been slightly updated with respect to the previous test: The
intermediate frequency is 3.5 MHz, allowing testing the effect of filtering in the system.
Figure 73 shows the full system, including the four satellites, the 6 monitor stations, and the
user.
182
Figure 73 – Ground segment, space segment, and user segment
Table 25 shows the elevations of each satellite with respect to each station. Some satellites
are below the horizon but the system geometry ensures that all satellites are seen by at least
four stations.
Table 25 - satellite elevations (º)
Elevations SAT1 SAT2 SAT3 SAT4
M1 90º 45.66º 45.66º 16.10º
M2 26.59º 18.13º 18.13º 35.79º
M3 26.51º -5.65º 67.06º 42.00º
M4 26.51º 67.06º -5.65º -20.17º
M5 26.59º 18.13º 18.13º -17.77º
M6 48.44º 17.41º 56.49º 51.25º
Usr 58.15º 24.23º 58.15º 40.77º
183
5.6.2. Simulator Steps
The simulation steps from signal generation to satellite PVT computation have been
described in the previous section. We assume here that the satellite reference parameters
(position, velocity, bias, drift, sequence) have been computed for the four satellites.
Therefore, the only remaining step is the user PVT computation.
Once the satellite positions, velocities and clock parameters are known, and the user has
stored a snapshot with the satellite measurements, there are no particularities in estimating the
user position. The simulator is estimating the user position through standard least squares
following equations (5.16) and (5.17).
5.6.3. Results
This section presents the user positioning results, obtained over 30 runs. Each run took
approximately 3 mins with Matlab running in an Intel i7-3630QM CPU @ 2.4 GHz, in
Windows 8 at x64 bits. The Matlab code was running in debugging mode to output figures
and results and was not optimised. Optimised codes in other languages and faster parallelised
platforms may allow running the method instantaneously (i.e. with an execution time
comparable to the snapshot duration). As an example, the following capture shows the main
intermediate results of one of the 30 runs.
Table 26 – User positioning through general snapshot satellite system results

** SNAPALL REPORT **
CRLB std. dev. [m]: 4.700
Elevations matrix [º]:

SV34 SV35 SV36 SV37
M1 90.00 45.66 45.66 16.10
M2 26.59 18.13 18.13 35.79
M3 26.51 -5.65 67.06 42.00
M4 26.51 67.06 -5.65 -20.17
M5 26.59 18.13 18.13 -17.77
M6 48.44 17.41 56.49 51.25
M1 Acquisition
SVID34 peak: 5.49; PR Error: 8.44 m; f Error: 47.242 Hz; CN0: 49.10 dBHz
SVID35 peak: 6.83; PR Error: 4.47 m; f Error: -20.401 Hz; CN0: 48.35 dBHz
SVID36 peak:13.82; PR Error: 6.13 m; f Error: -15.073 Hz; CN0: 50.69 dBHz
SVID37 peak:12.19; PR Error: 5.40 m; f Error: 14.127 Hz; CN0: 50.91 dBHz
M2 Acquisition
SVID37 peak:10.08; PR Error: -4.21 m; f Error: 0.465 Hz; CN0: 49.92 dBHz
M3 Acquisition
SVID34 peak:15.52; PR Error: -9.58 m; f Error: -14.502 Hz; CN0: 50.59 dBHz
.
SVID36 peak:10.91; PR Error: 5.08 m; f Error: -57.849 Hz; CN0: 50.16 dBHz
SVID37 peak: 9.58; PR Error: 1.11 m; f Error: -30.153 Hz; CN0: 49.90 dBHz
M4 Acquisition
.
.
M5 Acquisition
.
184
M6 Acquisition
SVID34 peak: 7.52; PR Error: -6.68 m; f Error: -92.201 Hz; CN0: 48.93 dBHz
SVID36 peak: 7.23; PR Error: -2.31 m; f Error: 46.904 Hz; CN0: 48.61 dBHz

( X, Y, Z, B)[m][s]:( 17999905.36 , -35.43 , -3.11 , 5.000295e-03)
( dX, dY, dZ, dB)[m][s]:( -94.64 , -35.43 , -3.11 , 2.952998e-07)
( VX, VY, VZ, FD)[m/s] :( -79.53 , 978.58 , 1988.74 , 1.970120e-05)
(dVX,dVY,dVz,dFD)[m/s] :( -79.53 , -21.42 , -11.26 , 1.960120e-05)

( X, Y, Z, B)[m][s]:( 15588408.95 , -8999960.37 , 6.04 , 8.000191e-03)
( dX, dY, dZ, dB)[m][s]:( -48.31 , 39.63 , 6.04 , 1.910498e-07)
( VX, VY, VZ, FD)[m/s] :( 2293.01 , -200.19 , 1015.91 , -1.306621e-04)
(dVX,dVY,dVz,dFD)[m/s] :( 293.01 , -200.19 , 15.91 , -1.305621e-04)

( X, Y, Z, B)[m][s]:( 15588407.30 , 8999966.75 , -4.47 , -5.999810e-03)
( dX, dY, dZ, dB)[m][s]:( -49.97 , -33.25 , -4.47 , 1.904129e-07)
( VX, VY, VZ, FD)[m/s] :( 1189.74 , 2094.40 , 23.53 , -8.753485e-05)
(dVX,dVY,dVz,dFD)[m/s] :( 189.74 , 94.40 , 23.53 , -8.754485e-05)

( X, Y, Z, B)[m][s]:( 10392184.08 , 10392112.90 , 9237422.74 , -3.999068e-03)
( dX, dY, dZ, dB)[m][s]:( -120.77 , -191.94 , -181.57 , 9.316991e-07)
( VX, VY, VZ, FD)[m/s] :( -1306.03 , -2433.64 , -361.21 , 2.631344e-04)
(dVX,dVY,dVz,dFD)[m/s] :( -306.03 , -433.64 , -361.21 , 2.631244e-04)
** USER SOLUTION **
SVID34 peak: 7.72; f Error: -30.512 Hz; CN0: 50.25 dBHz
SVID36 peak:11.24; f Error: 39.693 Hz; CN0: 51.37 dBHz
( X, Y, Z, B)[m] :( 5952245.43 , 1594889.73 , 1640132.95 , -1.268617e-01)
( dX, dY, dZ, dB)[m] :( 27.84 , -2.16 , 32.81 , -1.278617e-01)
The results show that DOP values for the satellite positioning are very high (GDOPs are
between 29.52 and 66.02). This is because geometry of the monitor stations is much worse
than for standard satellite positioning, especially for satellites at high elevations, as most lines
of sight are concentrated over the same area (the Earth) with respect to the total satellite
visibility. Geometry is much worse in this case compared to the 1-satellite test, as in the latter
the satellite was at a lower height. Even if the signal delay estimation accuracy is not far from
the CRLB of 4.7 m (std. dev.), the satellite position errors are of several tens of meters in
general, and this translates in the user position error.
Figure 74 and Figure 75 show the user accuracy results of 30 runs. RMS-3D of 73.2 m and
RMS-2D of 42.8 m reflect the accuracy degradation due to the suboptimal geometry. The
elliptical shape of the scatter plot in Figure 75 shows a high covariance in the XY
components, which reflects this suboptimal satellite geometry, which translates in further
accuracy degradation.
185
Figure 74 – User horizontal (2D) and 3D position error and RMS error
Figure 75 – User horizontal position error (X=East; Y=North)
The results show that there is room for accuracy optimisation. Nevertheless, this accuracy
may be enough for certain applications, especially if the service is provided indoors or
increases localisation resilience. Anyway, more realistic results can be obtained when
analysing more in detail the signals of other non-GNSS constellations, which is left for future
186
work. As mentioned at the beginning of the chapter, the fact that higher C/N0, similar-to-
GNSS or wider bandwidths are used for this signals, and the fact that only 1 ms integration
time has been tested, suggest that meter-level results can be obtained. Also, taking into
account that only four satellites have been used, while there may be hundreds usable non-
GNSS satellites, one can assume that geometrical DOP can be also decreased.
That being said, the purpose of developing an end-to-end Matlab simulator of the proposed
positioning method as a proof-of-concept has been fulfilled. This simulator can be easily
reconfigured and enhanced to study the performance of other satellite-to-monitor geometries,
signal frequencies, bandwidths and bitrates, RF properties at the stations and user receiver,
and so on. The error models can be enhanced to model more realistic errors, for example, for
better modelling multipath errors at user level.
5.7. Conclusions
This chapter has presented a satellite positioning method based on a snapshot ground
segment, which provides instantaneous satellite reference parameters (position, velocity,
clock bias, clock drift, bit sequence) to a user receiver. The method may be applied to present
and future non-GNSS satellites transmitting signals with the adequate properties: wide-
enough bandwidth, enough power and sufficiently long integration times. Together with
ranging accuracy, satellite-monitor geometry is the other driver for positioning accuracy.
A signal model has been proposed based on continuous or pulsed BPSK-like signals. An
error model is proposed as well, including signal generation, reception and propagation
errors, with a focus on the first two. First, the method for calculating the position of a satellite
has been evaluated with one-millisecond pulses of GPS-like signals. The satellite clock has
been modelled with a bias and a drift of a medium quality oscillator, at an orbit with radius of
8000 kilometres. 3D-RMS errors obtained in the satellite position calculation are below 20
metres, which is in line with the expected values according to the geometry and the CRLB,
especially given the very short integration times (one millisecond).
Finally, the whole system, including satellite, ground and user segments, is simulated. A user
position horizontal error of around 40 metres RMS-2D has been obtained, using an almost
arbitrary 6-station ground network and four satellites at orbits at around 18.000 km radius.
The position accuracy is highly degraded by the satellite-to-monitor and satellite-to-user
geometry. Ranging accuracy based on CRLB shows that much higher accuracies could be
187
obtained. In any case, no major hurdles have been found to implement a snapshot-based
positioning system using satellites with unstable clocks and non-GNSS signals.
188
Chapter 6. Conclusions and Further
Work
This thesis has presented some concepts, frameworks, models, experiments, and results on
satellite navigation authentication and snapshot techniques.
On satellite navigation authentication, this thesis proposes some concepts to improve

authentication performance. With the proposed approaches, which are based on a TESLA
protocol using a single key chain, cross-authentication, and reduced key and MAC lengths,
authentication bits can be reduced to less than two hundred, improving availability and
robustness. Users can then authenticate navigation data without performance loss. The thesis
presents a specific implementation proposal for the Galileo I/NAV message which allows an
average time between authentications of 5 seconds, at 20 bps, out of which 4 bps are devoted
to a root key certificate and 16 bps to MACs and keys. The signal is unpredictable every 1.6
seconds, making it suitable for A-GNSS or snapshot users that require to be protected against
replay attacks. Anti-replay capabilities based on the first samples of each unpredictable
symbol are also characterised.
The thesis then presents the "cold snapshot" method. This method allows a position to be
calculated based on a digital snapshot without any time or position reference parameters. The
method is based on using the instantaneous Doppler equations with an additional 'coarse time'
unknown, which can be as high as several hours, depending on the satellite geometry and
constellations used. The "cold snapshot" method is algebraically described and characterized
with real data snapshots in a snapshot software receiver. Through several iterations, it is
proven that time uncertainties of around a month can be solved almost instantaneously,
obtaining an accuracy similar to that of standard snapshot positioning.
Another research area of the thesis is the generalization of snapshot techniques to non-GNSS
satellites. This method may serve to calculate snapshot user positioning based on other
satellites that may transmit more powerful and wider bandwidth signals for communications
189
than that used for GNSS, thus improving resilience and indoor localization availability. In
order to test this concept, an end-to-end simulator has been developed, including space,
ground, and user segments. The results obtained in a use case with six stations and four
satellites show user position errors in the order of tens of metres. These errors can be
significantly reduced by improving the geometry and the signal processing features. They are,
however, sufficient to validate the concept at this stage. The work performed proves that such
end-to-end snapshot architectures are feasible.
The thesis finalizes with a short appendix (Appendix D) establishing some concepts and
theoretical basis to authenticate snapshots, which is equivalent to authenticating signals from
receiver start-up. The proposed methods are based on signal unpredictability, as that offered
by the NMA scheme proposed before, a trusted and accurate clock reference, and the
introduction of geometrical constraints such as height from a digital model.
6.1. Further Work

This section presents the further work in the different research areas of this thesis. As the
research areas cover different topics, it is presented separately for each chapter.
6.1.1. GNSS Authentication
Areas of further work in GNSS authentication in general and NMA in particular are:
 The analysis of how the receiver can deal with data-authenticated, replay-authenticated,
and non-authenticated signals, and other sensors, and derive from those an overall
confidence level for position authenticity.
 The proposed concept extension to spreading code-based measures, as the quick
transmission of keys also allows low TBAs in this case. The implementation of TESLA-
based NMA+SCE can be a subject of further research.
 Sensitivity analyses for antireplay protection, including hypothesis testing versus missed
detection and false alarm probabilities for different NU and NC values and under different
spoofing conditions.
 To further understand the performance in urban environments and optimise the
algorithms to place MACs throughout the MAC-K sections of a subframe, Monte Carlo
simulations using realistic reception probabilities and LMS models can be performed.
190
6.1.2. Cold Snapshot
Further experiments may be conducted on the following subjects:
 Application of the algorithm to multi-GNSS receivers, in which the mentioned orbital

repeatability of GPS would be mitigated by other constellations. In addition, other
methods to cope with non-linearity to get a one-shot fix without needing several iterations
for periods longer than some hours may improve the performance of the method.
 The focus of the research was not on obtaining the highest accuracy from the
measurements. Longer snapshots, including open loop and closed loop techniques, or any
other advanced signal processing techniques, may improve further snapshot positioning
performance. High accuracy Doppler measurements could be obtained by allowing stable
carrier phase tracking for a given time, reducing the Doppler error to the carrier frequency
measurement error.
 Testing and tuning of the algorithm for dynamic users and in degraded environments.
6.1.3. Snapshot Generalisation
Further work proposed to continue the research in this chapter includes:
 Use of Weighted Least Squares (WLS) or Receiver Autonomous Integrity Monitoring

(RAIM) methods to detect inaccurate measurements, both in the satellite positioning as in
the user positioning stages.
 Sensitivity analyses on the performance impact from satellite clock biases and drifts, and
adding more refined satellite clock models as proposed in [95] and [96].
 Analyse real non-GNSS satellites and signals in more depth and configure the simulator
accordingly to study their performance.
 Study the effect of different receiver hardware biases in case signals at different carrier
frequencies are used for the same snapshot position.
 Study the case in which the ground segment can perform continuous tracking of the
satellite signals, to reduce the error from the satellite snapshot positioning methods, even
if the snapshot techniques are applied at user level.
 Add more refined ionospheric, tropospheric and multipath propagation error models.
 Study in more detail the signal acquisition process with non-GNSS signals: impact of
using highly different carriers in Doppler measurements, cross correlation with other
signals, etc.
191
 Simulate realistic satellite-monitor geometries, taking into account realistic satellite orbits
and potential monitor locations.
6.1.4. Snapshot Authentication
In order to complement Appendix D, further work can be conducted in these subjects:
 Experimentation of the proposed authentication algorithms, and improvements thereof

derived.
 Development of a theoretical model to define the missed detection and false alert
probabilities for different algorithms under different cases, including more realistic error
models.
 Combination of signal-related authentication measures with position-related
authentication measures towards fully authenticated snapshot localization.
192
LITERATURE LIST
[1] J. Williams, From Sails to Satellites: Origin and Development of Navigational Science,
Oxford University Press, 1992.
[2] P. Misra and P. Enge, Global Positioning System: Signals, Measurements and
Performance (Revised Second Edition), Ganga-Jamuna Press, 2010.
[3] B. W. Parkinson and J. J. Spilker, Global Positioning System: Theory & Applications
(Volume One), 1st Edition ed., American Institute of Aeronautics and Aeronautics,
1996.
[4] J. Nurmi, E. S. Lohan, S. Sand and H. Hurskainen, Galileo Positioning Technology,

Springer, 2014.
[5] F. van Diggelen, A-GPS: Assisted GPS, GNSS, and SBAS, Artech House, 2009.
[6] E. Kaplan and C. Hegarty, Understanding GPS Principles and Applications, Artech
House Inc., 2006.
[7] A. J. Viterbi, “Spread Spectrum Communications - Myths and Realities,” IEEE

Communications Magazine, 1979.
[8] J. Betz, “Binary Offset Carrier Modulations for Radionavigation,” NAVIGATION:

Journal of The Institute of Navigation , vol. 48, no. 4, 2002.
[9] S. Wallner, “Navipedia,” [Online]. Available:

http://www.navipedia.net/index.php/GNSS_signal. [Accessed April 2015].
193
[10] J. Á. Á. Rodríguez, On Generalized Signal Waveforms for Satellite Navigation - PhD

Dissertation, UNIVERSITY FAF MUNICH, 2008.
[11] The US Government, “GPS Interface Specification IS-GPS-200,” 2014.
[12] European Union, “OSSISICD: Open Service Signal In Space Interface Control
Document, Issue 1.1,” September 2010.
[13] K. Borre, D. M. Akos, N. Bertelsen, P. Rinder and S. H. Jensen, A Software-Defined

GPS and Galileo Receiver: Single-Frequency Approach, Birkhäuser, 2007.
[14] F. Piper and S. Murphy, Cryptography – A Very Short Introduction, Oxford University
Press, 2002.
[15] N. Ferguson, B. Schneier and T. Kohno, Cryptography Engineering - Design Principles

and Practical Applications, Wiley & Sons, 2010.
[16] S. Singh, The Code Book: Science of Secrecy from Ancient Egypt to Quantum
Cryptography, Anchor Books, 2000.
[17] J. Daemen and V. Rijmen, “AES Proposal: Rijndael,” National Institute of Standards
and Technology, 2001.
[18] W. Diffie and M. E. Hellman, “New Directions in Cryptography,” IEEE Transactions

on Information Theory, Vols. IT-22, pp. 644-654, 1976.
[19] A. Menezes, P. Van Oorschot and S. Vanstone, Handbook of Applied Cryptography,

CRC Press, Inc., 1997.
[20] L. Scott, “Anti-Spoofing & Authenticated Signal Architectures for Civil Navigation
Systems,” ION GPS, 2003.
[21] O. Pozzobon, G. Gamba, M. Canale and S. Fantinato, “Supersonic GNSS

Authentication Codes,” in Proceedings of the 27th International Technical Meeting of
The Satellite Division of the Institute of Navigation (ION GNSS+ 2014), Tampa,
Florida, 2014.
194
LITERATURE LIST
[22] C. Wullems, O. Pozzobon and K. Kubik, “Signal Authentication and Integrity Schemes
for Next Generation Global Navigation Satellite Systems,” Proceedings of the
European Navigation Conference, 2005.
[23] K. Wesson, M. Rothlisberger and T. Humphreys, “Practical Cryptographic Civil GPS

Signal Authentication,” The Journal of the Institute of Navigation, February 2012.
[24] John A. Volpe National Transportation Systems Cent, “Vulnerability Assessment of the
Transport Infrastructure Relying on the Global Positioning System,” U.S. DoT, 2001.
[25] T. Humphreys, “Detection Strategy for Cryptographic GNSS Anti-Spoofing,” in IEEE

Transactions on Aerospace and Electronic Systems , 2013.
[26] I. Fernández-Hernández, J. Simón, R. Blasi, C. Payne, T. Miquel and J. P. Boyero, “The

Galileo Commercial Service: Current Status and Prospects,” Coordinates, pp. 18-25,
July 2014.
[27] I. Fernandez-Hernandez, I. Rodríguez, G. Tobías, J. D. Calle, E. Carbonell, G. Seco-

Granados, J. Simón and R. Blasi, “Testing GNSS High Accuracy and Authentication -
Galileo’s Commercial Service,” Inside GNSS, pp. 37-48, Jan-Feb 2015.
[28] O. Pozzobon, “Keeping the spoofs out - Signal Authentication Services for future
GNSS,” InsideGNSS, 2011.
[29] D. Calle, E. Carbonell, I. Rodríguez, G. Tobías, E. Göhler, O. Pozzobon, M. Cannale

and I. Fernández-Hernández, “Galileo Commercial Service from the Early Definition to
the Proof-Of-Concept,” in Proceedings of the ION GNSS+ 2014, Tampa, FL, 2014.
[30] “ISO/IEC 27000,” Interational Standards Organisation, 2014.
[31] I. S. Organisation, “ISO/IEC 15408-1:2009,” 2009.
[32] SSI, “ssi.gouv.fr,” [Online]. Available: http://www.ssi.gouv.fr. [Accessed Dec 2013].
[33] Z. Yazar, “A qualitative risk analysis and management tool – CRAMM,” SANS
Institute, 2002.
195
[34] G. W. Hein, F. Kneissl, J. A. Avila-Rodriguez and S. Wallner, “Authenticating GNSS

Proofs against Spoofs,” Inside GNSS, 2007.
[35] S. Lo, D. De Lorenzo, P. Enge, D. Akos and P. Bradley, “Signal Authentication: A

Secure Civil GNSS for Today,” InsideGNSS, no. September-October 2009, 2009.
[36] C. Günther, “A Survey of Spoofing and Counter-Measures,” NAVIGATION, Journal of

The Institute of Navigation, vol. 61, no. 3, Fall 2014, pp. 159-177., 2014.
[37] D. Lu, R. Wu, P. Li and Z. Su, “GPS smart jammer suppressin algorithm based on
spatial APES,” in International Symposium on Intelligent Signal Processing and
Communication Systems, 2007. ISPACS. , 2007.
[38] M. Kuhn, “An Asymmetric Security Mechanism for Navigation Signals,” Proceedings
of the Information Hiding Workshop, 2004.
[39] A. Kerns, D. Shepard, J. Bhatti and T. Humphreys, “Unmanned Aircraft Capture and
Control Via GPS Spoofing,” Journal of Field Robotics, pp. 617-636, 2014.
[40] A. J. Kerns, K. Wessons and T. Humphreys, “A Blueprint for Civil GPS Navigation
Message Authentication,” in Proceedings of Position, Location and Navigation
Symposium, Monterey, 2014.
[41] T. Humphreys, “UAVs Vulnerable to Civil GPS Spoofing,” Inside GNSS, 2012.
[42] S. Lo and P. Enge, “Aviation Augmentation System Broadcasts,” IEEE/ION Position

Location and Navigation Symposium (PLANS), 2010.
[43] D. Qiu, “Security From Location (PhD Dissertation),” Stanford University, 2009.
[44] G. T. Becker, S. Lo, D. D. Lorenzo, D. Qiu, C. Paar and P. Enge, “Efficient

authentication mechanisms for navigation systems – a radio-navigation case study,” in
ION GNSS, Savannah, 2009.
[45] I. Fernández Hernández, “Authentication: Design Parameters and Service Concepts,”

Proceedings of the European Navigation Conference, 2014.
196
LITERATURE LIST
[46] A. Perrig, R. Canetti, J. D. Tygar and D. Song, “The TESLA Broadcast Authentication
Protocol,” CryptoBytes, 2002.
[47] I. Fernandez-Hernandez, V. Rijmen, G. Seco-Granados, J. Simón and I. Rodríguez,

“Design Drivers, Solutions and Robustness Assessment of Navigation Message
Authentication for the Galileo Open Service,” in ION GNSS+ 2014, 2014.
[48] J. T. Curran, M. Paonni and J. Bishop, “Securing the Open-Service: A Candidate

Navigation Message Authentication Scheme for Galileo E1 OS,” in European
Navigation Conference ENC 2014, Rotterdam, 2014.
[49] National Institute of Standards and Technology, “FIPS PUB 198-1: The Keyed-Hash
Message Authentication Code (HMAC),” 2008.
[50] International Organization for Standardization, “ISO/IEC 9797-1:2011: Information

technology - Security techniques - Message Authentication Codes (MACs) - Part 1:
Mechanisms using a block cipher,” 2011.
[51] I. Rodríguez, G. Tobías, D. Calle, J. M. Martín, O. Pozzobon, M. Canale, D. Maharaj,

P. Walker, E. Göhler, P. Toor and I. Fernández, “Preparing for the Galileo Commercial
Service – Proof of Concept and Demonstrator Development,” in Proceedings of the
ION GNSS+ 2014, Tampa, Florida, 2014.
[52] A. K. Lenstra, “Key Lengths, contribution to The Handbook of Information Security,”

2004.
[53] ECRYPT, “Yearly report on Algorithms and Keysizes,” 2012.
[54] ENISA, “Algorithms, Key Sizes and Parameters Report - recommendations,” 2013.
[55] National Institute of Standards and Technology, “FIPS PUB 180-4: Secure Hash
Standard (SHS),” 2012.
[56] National Institute of Standards and Technology, “DRAFT FIPS PUB 202: SHA-3
Standard: Permutation-Based Hash and Extendable-Output Functions,” 2014.
197
[57] J. Guilford, K. Yap and V. Gopal, “Fast SHA-256 Implementations on Intel

Architecture Processors,” IA Architects, 2012.
[58] Crypto++, “Crypto++ 5.6.0 Benchmarks,” [Online]. Available:

http://www.cryptopp.com/benchmarks.html. [Accessed April 2015].
[59] A. Jahn, H. Bischl and G. Heib, “Channel Characterization for Spread Spectrum
Satellite,” in IEEE 4th International Symposium on Spread Spectrum Techniques and
Applications Proceedings, Volume 3. pp. 1221-1226., 1996.
[60] Trimble, “Planning Online Tool,” Trimble, [Online]. Available:

http://www.trimble.com/gnssplanningonline. [Accessed March 2015].
[61] A. Goldsmith, “Wireless Communications,” Cambridge University Press, 2005.
[62] A. J. Viterbi, “Error bounds for convolutional codes and asymptotically optimum
decoding algorithm,” IEEE Trans. Inform. Theory, p. 260–269, 1967.
[63] A. J. Viterbi, CDMA: Principles of Spread Spectrum Communication, Addison-Wesley

Publishing Company, 1995.
[64] B. Peterson, R. Hartnett and G. Ottman, “GPS Receiver Structures for the Urban
Canyon,” Palm Springs, CA, 1995.
[65] G. López-Risueño and G. Seco-Granados, “Measurement and Processing of Indoor GPS

Signals Using a One-Shot Software Receiver,” in 2nd ESA Workshop on Satellite
Navigation User Equipment Technologies , 2004.
[66] D. Dötterböck and B. Eissfeller, “A GPS/Galileo Software Snap-Shot Receiver for

Mobile Phones,” in Proceedings of the IAIN 2009 World Congress, Stockholm,
Sweden., 2009.
[67] O. Badia-Solé and T. Iacobescu-Ioan, GPS Snapshot Techniques, Aalborg: Aalborg

University, Danish GPS Center, 2010.
[68] H. Chen, W. H.-S., C. Y-T. and F.-R. Chang, “A new coarse-time GPS positioning
198
LITERATURE LIST
algorithm using combined Doppler and code-phase measurements,” vol. 18, no. 4,
2013.
[69] F. van Diggelen, “Method and Apparatus for Time-free Processing of GPS Signals”.
U.S. Patent 6417801, November 2000.
[70] K. Borre and G. Strang, Algorithms for Global Positioning, Wellesley-Cambridge Press
, 2012.
[71] C. Goad and L. Goodman, “A Modified Tropospheric Refraction Correction Model,” in

American Geophysical Union Annual Fall Meeting, San Francisco, 1974.
[72] J. Klobuchar, “Ionospheric Time-Delay Algorithms for Single-Frequency GPS Users,”

IEEE Transactions on Aerospace and Electronic Systems, pp. pp. 325-331., 1987.
[73] F. van Diggelen, “GPS Accuracy: Lies, Damn Lies, and Statistics,” GPS World, 1998.
[74] J. Foust, 2015. [Online]. Available: http://www.thespacereview.com/article/2716/1.
[75] “Union of Concerned Scientists - UCS Satellite Database,” 2015. [Online]. Available:
http://www.ucsusa.org/nuclear_weapons_and_global_security/solutions/space-
weapons/ucs-satellite-database.html.
[76] S. Blumenthal, “satmagazine,” 2010. [Online]. Available:

http://www.satmagazine.com/story.php?number=281305822.
[77] R. Barnett, “O3b – A different approach to Ka-band satellite system design and
spectrum sharing,” O3b Networks, Almaty, Kazakhstan, 2012.
[78] L. Schiff and A. Chockalingam, “Design and system operation of GlobalstarTM versus
IS-95 CDMA – similarities and differences,” Wireless Networks (6), p. 47–57, 2000.
[79] M. A. Jabbar, “Multi-Link Iridium Satellite Data Communication System,” Hyderabad,

India, 2001.
[80] S. Pratt, R. Raines, C. Fossa and M. Temple, “An Operational and Performance
199
Overview of the IRIDIUM Low Earth Orbit Satellite System,” IEEE Communications
Surveys, 1999.
[81] D. Whelan, G. Gutt and P. Enge, “BTL, an Indoor Capable Time Transfer and
Geolocation System,” Boeing, 2011.
[82] “Globalstar - Position Location,” [Online]. Available:

www.globalstar.com/en/index.php?cid?1450. [Accessed 2015].
[83] N. Levanon, “Instant Active Positioning with One LEO Satellite,” Journal of the
Institute of Navigation, vol. 46, no. 2, pp. 87-96, 1999.
[84] M. Joerger, J. Neale and B. Pervan, “Iridium/GPS Carrier Phase Positioning and Fault
Detection Over Wide Areas”.
[85] M. Joerger, L. Gratton, B. Pervan and C. E. Cohen, “Analysis of Iridium-Augmented

GPS for Floating Carrier Phase Positioning,” Journal of the Institute of Navigation, vol.
57, no. 2, pp. 137-160, 2010.
[86] D. Qiu, D. d. Lorenzo and T. Bhattacharya, “Indoor Geo-Location with Cellular RF

Pattern Matching and LEO Communication Satellite Signals,” in International
Technical Meeting of the Institute of Navigation, San Diego, California, 2013.
[87] M. Rabinowitz, B. Parkinson and J. Spilker, “Some Capabilities of a Joint GPS-LEO

Navigation System,” in ION GPS 2000, Salt Lake City, UT, 2000.
[88] M. Toledo, Y. Capelle, G. Seco, A. Mark, I. Fernández, D. Kubrak, M. Monnerat, J.

Salcedo, J. Vicario and D. Jiménez, “DINGPOS: Indoor Navigation Demonstration
Platform,” in ENC 2008, 2008.
[89] S. M. Kay, Fundamentals of Statistical Signal Processing: Estimation Theory, Prentice

Hall, 1993.
[90] U. Mengali and A. N. D'Andrea, Synchronization Techniques for Digital Receivers,

Plenum Press, 1997.
200
LITERATURE LIST
[91] N. B. Delgado, “Signal Processing Techniques in Modern Multi-Constellation GNSS

Receivers (PhD Thesis),” UNIVERSIDADE TECNICA DE LISBOA - INSTITUTO
SUPERIOR TECNICO, 2011.
[92] G. Shen, R. Zetik and R. S. Thomä, “Performance Comparison of TOA and TDOA
Based Location Estimation Algorithms in LOS Environment,” in PROCEEDINGS OF
THE 5th WORKSHOP ON POSITIONING, NAVIGATION AND COMMUNICATION
2008 (WPNC’08), 2008.
[93] J.-Y. Do, M. Rabinowitz and P. Enge, “Performance of TOA and TDOA in a Non-
homogeneous Transmitter Network Combining GPS and Terrestrial Signals,” in
Proceedings of the 2006 National Technical Meeting of the Institute of Navigation, PP
642-649, Monterey, CA, 2010.
[94] “N2YO,” [Online]. Available: http://www.n2yo.com/satellites/. [Accessed 2015].
[95] R. G. Brown and P. Y. C. Hwang, Introduction to Random Signals and Applied Kalman
Filtering. Third Edition, John Wiley & Sons, Inc., 1997.
[96] T. S. Bruggemann, D. G. Greer and R. Walker, “Chip Scale Atomic Clocks: Benefits to
Airborne GNSS Navigation Performance,” in Proceedings International Global
Navigation Satellite Systems Society, Holiday Inn Surfers Paradise, Australia, 2006.
[97] National Institute of Standards and Technology, “FIPS PUB 186-3: Digital Signature
Standard (DSS),” 2009.
[98] H. Krawczyk, M. Bellare and R. Canetti, “HMAC: Keyed-Hashing for Message

Authentication,” Network Working Group, 1997.
[99] National Institute of Standards and Technology, “NIST Special Publication 800-38B:
Recommendation for Block Cipher Modes of Operation: The CMAC Mode for
Authentication,” 2004.
[100] International Organization for Standardization, “ISO/IEC 9796-3. Information

technology – Security techniques – Digital signatures giving message recovery – Part 3:
201
Discrete logarithm based mechanisms.,” 2006.
[101] International Organization for Standardization, “ISO/IEC 14888-3: Information

technology - Security techniques - Digital signatures with appendix - Part 3: Discrete
logarithm based mechanisms - Amendment 1,” 2009.
[102] Russian Institute of Space Device Engineering, “Glonass Interface Control Document -
Navigational Radiosignal In Bands L1, L2 (Edition 5.1),” 2008.
[103] China Satellite Navigation Office, “BeiDou Navigation Satellite System Signal In
Space - Interface Control Document - Open Service Signal B1I (Version 1.0),” 2012.
[104] “Temperature Compensated Crystal Oscillator (TCXO / VCTCXO),” Pericom,

[Online]. Available: https://www.pericom.com/products/crystal-and-crystal-
oscillator/tcxo-vctcxo/. [Accessed April 2015].
[105] J. Eidson, “IEEE-1588 Standard Version 2 - A Tutorial,” Agilent Technologies, 2006.
[106] L. Scott, “Proof of Location; Verifying Physical Space in a Virtual Space,” 2012.
[107] M. Weiss, “Telecom Requirements for Time and Frequency Synchronisation”.
[108] I. Fernández-Hernández, J. Caro-Ramón, M. Toledo-López, M. A. Martínez-Olagüe

and M. Azaola-Saenz, “Method for map matching with guaranteed integrity”. Patent
US8032299 B2, 2008.
[109] G. Strang and K. Borre, Linear Algebra, Geodesy, and GPS, Wellesley - Cambridge
Press, 1977.
202
APPENDICES
Appendix A. Open Authentication Service – Summary of User Needs and High Level
Requirements Justification ............................................................................................. 204
Appendix B. NMA Bit-level Field Description ............................................................. 209
Appendix C. Bandwidth Allocation Analysis for Different MAC and Key Sizes ......... 220
Appendix D. Snapshot Authentication ........................................................................... 226
Appendix E. Acronyms .................................................................................................. 237
Appendix F. Published Papers ........................................................................................ 243
Appendix A. Open Authentication Service – Summary of

User Needs and High Level Requirements Justification
This appendix presents the justification for the user needs and high level requirements
used for the design of the NMA solution presented in Chapter 3. They were defined prior
to the definition of any authentication solution. They are divided in these categories:
 Target Users and Receiver Constraints

 Robustness and Performance
 Feasibility
 Backward Compatibility
TARGET USERS AND RECEIVER CONSTRAINTS
The authentication solution proposed can be part of the Galileo Open Service. Currently,
the biggest Galileo OS user base is foreseen to be portable handset devices (mobile
phones, PNDs, tablets or the like) for personal or vehicular use, as is now the case for
GPS SPS. This is translated into the following requirements.
The solution shall work in standalone mode: Many OS users will not have a
communication channel always available, so the authentication service shall work in
standalone mode, as the OS navigation service does.
The solution shall work in assisted mode: Users may have a communication channel
(A-GNSS) available for data reception and synchronisation to decrease time to fix and
increase sensitivity. The service should therefore take advantage of an A-GNSS
communication channel. Ideally, an instantaneous authenticated PVT in assisted mode
should be targeted.
Security-related receiver requirements shall be minimised: Symmetric encryption,

which implies sharing a secret key between the provider and the user, must be avoided,
as the receiver would then need a continuous and authenticated communication channel
or a tamper-proof security module. Furthermore, it is then likely that a complicated key
204
management process is put in place to provide and update the secret keys. Therefore,
asymmetric methods are proposed. This includes asymmetry obtained through a delayed
delivery of a symmetric key, as explained later.
The solution must be E1 mono-frequency: The authentication solution should be based

on E1 only, if possible, as opposed to a dual frequency solution, the reason being that
most mass-market devices are foreseen to remain E1/L1 single frequency for the
following years, due mainly to power consumption reasons. E1 is the band compatible
with GPS so it is the obvious choice. The solution may, however, be expandable to other
frequencies (note that the I/NAV message is transmitted in both E1 and E5b).
The solution shall not require any additional hardware components than those of a
standard low-cost receiver: As mentioned above, no additional hardware has to be
required (as e.g. several antennas, INS (Inertial Navigation System), odometers,
compass), although the solution must, in the future, be compatible with them. The service
must be implementable with low-cost components available in low cost GNSS chips as
e.g. crystal oscillators, low-cost antennas and front-end components, and small memories
and CPUs that will be integrated into mass-market equipment.
The solution shall be computationally feasible in a standard low-cost receiver: The

computational workload for the authentication mechanism shall be affordable and
therefore in the order of (or below) the standard receiver processing tasks such as PVT
computation. If this requirement is fulfilled, future software-oriented architectures should
also be compatible.
ROBUSTNESS AND PERFORMANCE
The solution proposed must be assessed against other state-of-the-art solutions for GNSS
authentication. The following requirements summarise some issues to be considered
from the point of view of the security robustness of a cryptographic system and include
some metrics to be looked at to assess the performance of the solution.
The solution shall use functions and protocols considered secure by the
cryptographic community: Attacks to asymmetric key systems rely on mathematical
techniques combined with exhaustive key searches. New ideas not tested by the
cryptographic community over several years, even if ascertained as secure enough, can
be subject to unforeseen mathematical attacks that can render the whole system insecure.
205
The solution shall be cryptographically secure in the long term: A period of 30 years
since its implementation is considered the lower bound of long-term security as presented
in [54]. This is considered as a stringent yet desirable requirement taking into account the
evolution pace of GNSS services and infrastructure. Moreover, these figures are also
considered in some references [23, 97] from cryptography standardisation and security
bodies, as e.g. NIST (National Institute of Standards and Technology) or NSA (National
Security Agency), to assess the number of symmetric security bits required for a system
to be cryptographically secure in the next years. These projections are based on how
technology evolution can make exhaustive key searches or mathematical attacks much
shorter than the cryptoperiod in a way that the keys can be broken by an attacker. These
projections take into account Moore's law and the use of disruptive technologies as
quantum computers that may come in the following years [14].
The satellite and receiver key update frequency must be minimised: If the proposal
needs the receiver to handle cryptographic keys, these will not need to be updated with a
high frequency. The period during which a key can be utilised must be in the order of
around a year, several years or even the whole the lifetime of the system. The system
shall also be designed in a way to allow changing the keys quickly if the keys have been
compromised.
The proposal robustness to attacks shall be at least comparable to other solutions in

the state-of-the-art: They authentication services can be summarised in two categories:
Authentication of the navigation data, and protection against replay attacks. For the
latter, the unpredictable features of the authentication information can be used. In
addition, to increase robustness against replay attacks, the time between authentication
events must be minimised.
The proposal performance shall at least be comparable to other authentication

proposals in the state-of-the-art: The performance must be assessed for Standalone
mode (i.e. the receiver does not have any communication channel to provide assisted
information) and assisted mode (i.e. the receiver has a communication channel to provide
satellite ephemeris and estimated initial position and time).
206
FEASIBILITY
The implementation of the NMA proposal should be feasible within the boundaries of the
Galileo first generation system as foreseen, with minor modifications, if any. This can be
translated in the following requirements:
The solution shall be compatible with current Galileo satellites: No modifications to

the satellite hardware or software should be envisaged.
The solution shall be compatible with Galileo uplink capabilities: The service
proposed should be implementable taking into account that part of the satellites seen by a
user at a time will be connected to ground, but the majority will not.
The solution shall be compatible with the Galileo ground segment: The service
proposed shall leverage the existing capabilities of the existing ground segment and
minimise the modifications to its baseline and associated documentation. The number of
ground elements and interfaces modified shall be minimised, and no increase in the
system infrastructure, including redundancies, new stations or equipment, or additional
network requirements, shall be required.
The solution shall be compatible with the Galileo operations concept: No or minimal
changes in operational procedures and effort associated shall be required.
BACKWARD COMPATIBILITY
The elements already defined in the SIS ICD should remain unchanged so that existing
Galileo-enabled receivers built according to the OS SIS ICD specification should not be
impacted at the time the authentication service is applied.
The solution shall be compatible with the current Galileo signal specification: The
authentication service shall not modify the current signal properties as signal power,
modulation, pseudorandom codes, secondary codes, or other parameters already defined
in the SIS ICD [12].
The solution shall not degrade the Galileo navigation data transmission
performance: To keep backward compatibility, the service must be relayed in currently
unused data fields. It shall not use the fields currently defined in the SIS ICD. It shall not
207
increase the overhead of the navigation data transmission by leading to a higher data
aging or TTFF.
The solution shall not prevent other signal evolutions: At the time this text is written,
some signal and message evolutions are under consideration. Future services as e.g.
support to integrity monitoring, may be occupy the E1 channel. Therefore, the
authentication solution shall leave some spare bit capacity unused in a way that does not
prevent the implementation of options already under discussion for future
implementation.
208
Appendix B. NMA Bit-level Field Description
To improve the readability of the thesis, the details of the bit-level NMA implementation
proposal is presented in this appendix.
H-K-ROOT
The following sections describe the H-K-root fields in detail: H-K-root Header, Digital
Signature Header, and Digital Signature and Message.
1) H-K-root Header
At the beginning of each subframe, an authentication header is transmitted. It includes

the fields Overall NMA status, Chain ID, New K-root flag, End-of-chain flag, DS-ID,
Block-ID and reserved bits for future use. If there is no need for the receiver to decode
the K-root part, the second half of the header (8 bits in the 2ndsubframe word) could be
ignored. Therefore, the two 8-bit parts of the header can be treated separately.
Overall NMA Status (2 bits): These bits present the overall status of the navigation
message authentication service as follows:
Table 27 –NMA Overall Status
0 1 2 3
test-1 test-2 operational don't use
The modes are described as follows:
 "Test-1" mode indicates that authentication is provided without any operational

guarantees. In test-1 mode, all connected satellites are transmitting the same
information. This mode is defined to cope with a current limitation in the
"Reserved 1" bit transmission in the Galileo system.
 "Test-2" indicates that authentication is provided without any operational
guarantees. In test-2 mode, connected satellites are able to transmit different
information, as in the operational case.
 "Operational" mode indicates that the authentication service is providing
according to the specifications.
 "Don't use" mode warns the user not to use the authentication service.
209
Chain ID (2 bits): ID of the chain in force in the MAC-K section.
New K-root Flag (1 bit): In nominal operations, the K-roots transmitted are the same as
in previous subframes, and once a valid K-root of the chain in force is known by the
receiver, the receiver does not need to process more K-roots, until it is notified through
the end-of-chain flag. Nevertheless, the receiver will be notified when a new K-root
(either a more recent one from the current chain or one from the next chain) is
transmitted. In this case, this bit is set to '1', to alert the receiver that it can read the new
K-root. Otherwise, this bit is set to '0'.
End-Of-Chain Flag (1 bit): When this bit is '1', the users are notified that the current
chain ID is coming to an end, so the users should start processing a K-root from another
chain ID, as it is expected that the system will start authentication with this new chain.
Reserved (2 bits): Bits of the header reserved for future use. For example, to indicate
whether the signature being transmitted is signing a K-root or a new public key, if an
over-the-air-rekeying approach is followed. This latter option is not considered in detail
in this specification and is left for further work.
Digital Signature ID (4 bits): As a digital signature is transmitted in several blocks

(one block per subframe), DS-ID identifies which is the digital signature associated to the
current block. In this way, nominal operation could allow the same or different signatures
be transmitted from different satellites in an asynchronous way (but keeping
synchronicity with the subframe structure).
Digital Signature Block ID (4 bits): This field represents the ID of the current block.
The blocks will in general be transmitted sequentially, but the current definition allows
for scattered blocks, in case e.g., there is a problem in the EDBS transmission from the
system and a block is rebroadcast. It is not foreseen that more than 16 blocks (1920 bits,
1656 bits of DSM) are necessary for the K-root transmission.
Table 28 –Block ID field
Block ID value 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Block ID 16 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
210
2) Digital Signature Header
In the first subframe of an H-K-root, the H-K-root incorporates a header that will define
some properties about the root key (K-root) and the digital signature used. When BID = 1
(1st block), the receiver will know that a DS Header is coming. The DS Header includes
the following fields:
Number of Blocks (4 bits): This field represents the number of blocks of the current
signature. Note that the 4-bit value does not express directly the number of blocks and
needs to be converted as per Table 29. According to the current definition, the maximum
DSM length is 104i – 8, i being the number of blocks. This table also shows DSM
lengths for different blocks.
Table 29 – Number of K-root blocks field and maximum DSM length
NB value 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Number of
3 4 5 6 7 8 9 10 11 12 rsvd rsvd rsvd rsvd rsvd rsvd
blocks
DSM length 304 408 512 616 720 824 928 1032 1136 1240 TBD TBD TBD TBD TBD TBD
Now 12 blocks seems enough as they allow signing a 512-bit key with a 512-bit key for
OTAR, with some margin. Future versions of the ICD could accommodate longer public
keys to increase the key pair validity period or increase security, if vulnerabilities are
found.
Public Key ID (4 bits): In order to facilitate the use of keys when the receiver is built,
several public keys may be required. Public keys should be published just before their
validity period, as otherwise the paired private key could be attacked by the knowledge
of the public key, even if no information has been yet signed with it. However, the
requirement to connect the receiver to a network to upload new public keys should be
minimised. To solve that, the system may define overlaps between in validity periods of
several key pairs. For example, if there were no overlap, a receiver manufactured just
before the end of the validity period of a certain key Vi, would be forced to be upgraded
to load the new public key Vi+1 at the start of its life cycle. To avoid this, public keys can
be overlapped, so that at a certain time several keys are valid and the system can transmit
digital signatures with different keys.
211
Table 30 – Public Key Validity Period for several key pairs, assuming each key pair is valid for 5 years
2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 2026 2027 2028
S1, V1
S2, V2
S3, V3
S4, V4
S5, V5
S6, V6
S7, V7
S8, V8
S9,V9
Table 30 shows how several key pairs would be valid for different periods. For example,
a receiver manufactured in 2021 could load in its memory the public keys V2, V3, V4,
V5 and V6. This would ensure a lifetime of 5 years without the need to upgrade the
public keys.
A 4-bit public key ID would allow up to 16 keys in force, which seems more than
sufficient, assuming one key is provided every year, and keys are valid for 5 years as in
this case. During the lifetime of the system, after the first 16 public keys are used, the
public key ID would roll over to zero.
If a private-public key pair has to be revoked, the system will just stop signing H-K-roots
with this key, and it will notify through a public internet site or public key infrastructure
through an Online Status Certification Protocol (OSCP), that the key is revoked. Even
receivers without access to the internet will be able to continue functioning, just by using
the other keys.
As mentioned above, another approach for managing public-private key pairs is through
over-the-air rekeying (OTAR). In this case, the system would sign a new public key Vi,
to be in force in the near future, with the previous public key Si-1, so the receiver can
verify its authenticity with Vi-1. If this is implemented, the current DSM scheme could
be maintained, but the user flags should be used to notify whether a K-root or a new
public key is being transmitted.
3) Digital Signature and Message (DSM)
This section describes the digital signature field. Given that the concept shall allow for
different digital signature schemes, some of them allowing message recovery, a single
212
section is considered for the transmission of the digital signature and the message. If the
message is not fully recovered from the digital signature, the full message or the part of it
that is not recovered is appended just after the digital signature, as shown in Figure 76. If
the digital signature plus the message do not sum up to one of these lengths, then the
remaining bits can be used to increase redundancy of the data.
Figure 76 – DSM field options
The following subsections describe the DSM section, for the case in which a K-root is
signed. In this case, the message to be signed is composed of the following fields:
Chain ID (2 bits): ID of the chain to which the K-root belongs. Although in nominal
conditions there will only be one valid chain, it seems logical to allow for several chains
(up to 4). If a chain is revoked for any reason, the system could start transmitting keys of
a new chain in a way that allows the user to determine to which chain a given key
belongs and continue authentication in a seamless way.
Key Size (4 bits): It identifies the key size. It represents the size of each key in the chain,
including the transmitted K-root. It is interpreted as follows:
Table 31 – Key Size field
Key Size value 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Key Size 80 82 84 86 88 90 92 94 96 98 100 112 128 rsvd rsvd rsvd
An 80-bit key is considered to be strong enough for long (e.g. 1 year) chain durations, at
the time of writing this thesis. Further discussion on key lengths is presented in section 0.
The current proposal allows for margin for longer keys to be used in the future. Other
key values could be defined. Flexibility in key length also allows bandwidth
optimisation, as shown later.
It is assumed that the key size of a certain chain does not change, once the chain has been
created and is in use. Therefore, the key size is a parameter that relates to the length of
the whole key chain. However, the system can change the key length from one chain to
another.
213
Hash Function (3 bits): It identifies the hash function used for the chain. It is interpreted
as follows:
Table 32 – Hash Function field
0 1 2 3 4 5 6 7 8
SHA-256 SHA3-224 SHA3-256 rsvd rsvd rsvd rsvd rsvd rsvd
SHA-2 family hashes (SHA-256) are defined in the latest FIPS publication (FIPS PUB
180-4) [55]. SHA-3 family is implemented according to the Keccak algorithm. Draft
FIPS PUB 140-2 is under public consultation (as the time of writing this thesis), based on
the Keccak algorithm [56]. A new reference standard for SHA-3 shall be given, when
available.
This field provides some reserved values for future standard hash functions that may be
standardised. Given the high length of the chains, the algorithm implementation is very
sensitive to the hash function, a simple, yet secure, function should be used.
MAC Function (2 bits): It identifies the MAC function used with the keys of the chain.
It is interpreted as follows:
15
Table 33 – MAC Function - specific implementations
0 1 2 3
HMAC-SHA-256 CMAC-AES rsvd rsvd
Option 0: standardized in [98] and in [49].
Option 1: CMAC-AES, standardized as Algorithm 5 in [50], and in [99].
MAC Size (4 bits): This field tells the degree of truncation of the abovementioned MAC,
according to the following definition:
Table 34 – MAC Truncation
MAC Trunc. Value 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Trunc. MAC length 10 11 12 13 14 15 16 17 18 19 20 rsvd rsvd rsvd rsvd rsvd
15
The a and b constants required for the HMAC function can be given in the signal and service specification
documents. There is no need to transmit them in the signature. The same occurs for other parameters in other
cryptographic functions.
214
In this way, the service can provide more truncated or less truncated MACs, depending
of e.g. the number of satellites to be authenticated, out of the existing constellation(s).
For example, in test-1 mode, short MACs may be used, as the same data will be sent
from all satellites. This flexibility can also accommodate different degrees of uplink
capabilities of the system.
WN-K-root (12 bits): this parameter refers to the time associated to the K-root, in
Galileo System Time (GST). It provides the Week Number of the time associated to K-
root (T-K-root). WN is represented in 12 bits as in the Galileo SIS ICD [12].
DOW-K-root (3 bits): Day of week associated to K-root. The combination of WN-K-

root and DOW-K-root should give an unambiguous time reference associated to K-root
in the following way: K-root is the key immediately preceding the first key of the chain
whose application time corresponds to the subframe starting at WN, DOW at 00:00:00,
GST. The K-root is therefore derivable from the first key applicable at this time in just
one step.
WN-K-root and DOW-K-root compose the time associated to K-root, or T-K-root. 1 day
of resolution is considered enough for T-K-root. More resolution (up to the second level)
can be added if entropy needs to be increased to avoid pre-computation attacks.
K-root (80-128 bits): Root key associated to T-K-root. Several K-roots of the same
chain associated to different times can be transmitted by the system. Therefore, the term
K0 used in previous documentation has been replaced by a 'floating' term K-root, as K0
may be associated to a certain fixed place in the chain, which, if it corresponds to the
beginning of the chain, it would require to perform several million hashes to verify the
validity of a new key.
Therefore, according to the current proposal, the message to be signed is composed of the
following fields with the following lengths:
Table 35 – K-root message
field CID KS HF MF MS WN DOW Kroot total length

length 2 4 3 2 4 12 3 80-128 110-158
If a pattern needs to be added, it would be added as an element of this table.
Digital Signature Generation: two examples of digital signatures types, with and
without message recovery, are Nyberg-Rueppel [100] and Schnorr-DSA [101]. They can
215
both provide a high level of security with 512-bit signatures, without precluding the use
of shorter signatures (e.g. 448 bits). In the case of K-root signature without message
recovery, the message bit stream can be generated as follows:
M = (CID || KS || HF || MF || MS || WNKroot || DOWKroot || Kroot) (B.1)
In the case of K-root signature with message recovery, the message to sign requires a
certain pattern, to verify the authenticity and integrity of the message:
M = (CID || KS || HF || MF || MS || WNKroot || DOWKroot || Kroot || pattern) (B.2)
MAC-K SECTIONS
Each MAC-K section is composed of the following fields:
1) MAC
Message Authentication Code generated according to equations (3.13) and (3.14).
2) MAC-Info
This field contains the fields SVID, Authentication Data & Key Delay and Issue Of Data,
as shown in Table 36.
Table 36 – MAC-Info
field SVID ADKD IOD total length
length 8 4 4 16
SVID (8 bits): Satellite ID of the satellite transmitting navigation data that is

authenticated. By using 8 bits, up to 255 satellites could be authenticated, which allows
for the authentication of satellite data from Galileo and other constellations (mainly GPS
but also, GLONASS, Beidou or others) and regional systems as SBAS. The convention
proposed for the SVID field is:
 SVID 0: reserved.
 SVIDs 1-32: Galileo SVIDs as per Galileo signal specification [12].
216
 SVIDs 33-64: GPS SVIDs as per GPS signal specification [11], minus 32 (e.g.
SVID 33 is GPS SVID 1)
 SVID 65-96: GLONASS satellite numbers as per GLONASS ICD [102], minus
64. (e.g. SVID 65 is GLONASS SVID 1).
 SVID 97-128: TBC - Beidou MEO SVIDs as per Beidou ICD [103], minus 96.
(e.g. SVID 97 is Beidou SVID 1).
 SVID 129-160: SBAS GEO SVIDs. Exact allocation TBC (e.g. WAAS MOPS
PRN minus 9; e.g. SVID 129 is WAAS MOPS PRN120). 32 values can include
GEO satellites from all SBAS: EGNOS, WAAS, MSAS …).
 SVID 161-255: reserved (e.g. IRNSS).
 SVID 252: general BEIDOU constellation information that does not relate
specifically to a satellite.
 SVID 253: general GLONASS constellation information that does not relate
specifically to a satellite (e.g. ionospheric corrections).
 SVID 254: general GPS constellation information that does not relate specifically
to a satellite (e.g. ionospheric corrections).
 SVID 255: general Galileo constellation information that does not relate
specifically to a satellite (e.g. ionospheric corrections).
Authentication Data and Key Delay (ADKD) (4 bits): This field describes the signed
navigation data and, in the case of the "Slow MAC" values, the time between the MAC
and the associated key transmission.
The proposed meaning of ADKD bits for Galileo is:
 '0', eph&clk: the MAC authenticates the bits of the fields related to the ephemeris,
including clock corrections, of the given satellite. It refers to the ephemeris and
clock data bits transmitted in the E1 I/NAV message, Words 1 to 4 of [12]. The
SISA field will also be included. The spare bits are not included.
 '1', ionoBGD: the MAC authenticates the bits of the fields related to the
ionospheric corrections, BGDs, satellite health and Galileo system time, i.e. all
data bits in E1 I/NAV message Word 5: iono correction, BGDs, HS (Health
Status), DVS (Data Validity Status) and GST.
217
 '2', subframe (SF): the MAC authenticates the bits of a certain full subframe. This
includes all the Word data. It does not include other reserved fields, the SAR data
or the CRC.
 '3', Gal F/NAV eph&clk: the MAC authenticates the ephemeris and clocks of the
F/NAV message. Exact definition is TBC.
 '11' to '15', "slow MACs": As described in [46], a requirement of the TESLA
protocol is a loose time synchronisation between the sender and the receiver. In
order to prevent attacks whereby the attacker would rebroadcast a right key with
forged navigation and MACs, which could happen if the receiver has a time
uncertainty in the order of the seconds between the reception of the MACs and
the key, the concept of "slow MACs" is added. A "slow MAC" is a MAC
generated with a key broadcast some subframes later. For example, if ADKD
field is 12, it means that the receiver gets the key associated to that MAC exactly
with two subframes (60 seconds) delay with respect to the time it would have
received it in normal conditions. The TTFAF of a receiver requiring the use of
'slow-MAC's to achieve the loose time synchronisation required for TESLA may
be degraded by the extra delay between the MACs and the associated key. In a
similar implementations, "slow MACs" could refer to the delay measured in
"authentication frames" (i.e. MAC-K sections) as opposed to I/NAV subframes.
The proposed meaning of ADKD bits for GPS is:
 '0', eph&clk: In case of a GPS satellite, it refers to the bits transmitted in the GPS
L1 C/A signal for clock corrections, SV health/accuracy and ephemeris
parameters. This data is included in subframes 1, 2 and 3 of a GPS L1 C/A 30-
second frame.
 '1', ionoBGD: the MAC authenticates the bits of subframes 4 and 5 related to the
ionospheric model (other bits not TBC).
 '2', subframe: the MAC authenticates the bits of a whole 30-second GPS frame,
including subframes 1 to 5.
 '4': GPS L1C eph&clk: the MAC authenticates the ephemeris and clock bits from
GPS L1C signal. Exact definition is TBC.
 '11' to '15': same as for Galileo, but related to GPS eph&clk interpretation.
218
The detailed interpretation of the other values, or of the same values for other
constellations, is TBD.
Issue-Of-Data (4 bits): Identification of the Issue Of Data of the signed data. 4 bits are
considered be enough, as IOD is updated very seldom, even if IOD transmission is
disordered by the GNSS ground segment. IOD can be interpreted as follows:
 For eph&clk authentication, the 4 bits can be interpreted as follows:

o The first bit is '1' when the system is authenticating a new IOD, and '0'
otherwise.
o The last 3 bits correspond to the IOD truncated to the LSB (Least
Significant Bit).
o For Galileo satellites and eph&clk authentication, the last 3bits of IOD
correspond to the truncated IODnav.
o For GPS satellites and eph&clk authentication, the last 3bits of IOD
correspond to the truncated IOD Ephemeris. The IOD Clock
associated to the authenticated clock corrections is not necessary to be
transmitted. It can be assumed by the receiver that the authenticated
clock corrections will be those transmitted together with the last
authenticated IODE.
 For Galileo and GPS satellites and ionoBGD (Word 5) authentication, the last 3
bits of IOD are set to zero. The first bit will be '1' when the system is
authenticating a new set of ionospheric data. The receiver will assume (TBC) that
the data corresponds to the last full subframe (Galileo) or frame (GPS) received.
 For type '2' – subframe authentication, the first bit is '1' if the subframe
authenticated corresponds to the current subframe and '0 if it corresponds to the
last subframe16.
3) KEY
This field will contain the key.
16
Note that through E1 and E5b the Datagen can get all words to be authenticated around second 9 of the subframe.
This will allow signing the data and having it sent by the end of the same subframe.
219
Appendix C. Bandwidth Allocation Analysis for Different

MAC and Key Sizes
This annex presents the tables used for selecting MAC and key sizes. The tables
represent the design parameters for different MAC and key sizes, at a given MAC-K
section length. First, the case of 3 MAC-K sections per subframe (one every 10s) is
represented. Then, the case with two MAC-K section per subframe (one every 15s in
average) is represented.
Each sub-table is formed by 11 rows representing the cases of 10-bit to 20-bit MACs,
and each column represents the key size, between 80 bits to 128 bits. The table results are
coloured according to their value, to visually indicate the optimal parameters.
The first sub-table (blue) represents the number of MACs that fit into a MAC-K section
for a given MAC/K-size pair. The numbers in red represent the cases where the MAC-
key combination leaves no spare bits.
The second sub-table (green) represents the total number of MACs transmitted per 30s
I/NAV subframe, per channel (i.e. connected satellite).
The third sub-table (red) represents the number of spare bits of the given combination.
Only values leaving no spare bits are selected for analysis.
The fourth and fifth sub-tables (red-green) represent the number of unpredictable
symbols every 30 seconds, and its percentage, for consideration to protect against replay
attacks. Note that the percentage is calculated with respect to the number of
authentication bits (20 bps), and not to the total number of I/NAV bits in the I/NAV
message structure, in order to better assess the sensitivity of different approaches, which
otherwise will be masked by the repeatability of the I/NAV message.
Only the MACs and some of the key bits are considered unpredictable. The input
variable 'predictable key bits' is subtracted to the key length to exclude the last bits of the
key from the unpredictability test statistics.
220
The sixth sub-table presents the NA (i.e. number of bits for authentication) required to
data-authenticate four satellites.
The following input parameters are assumed:
 Kpred: 20
 TOTAL I/NAV EDBS symbols/30s: 600
 Total MAC-K bits available: 480
 MAC Info Length: 16
221
Table 37 - Authentication design parameters vs MAC/key lengths - 2 MAC-K sections / SF (i)
1- NB OF MACS PER MAC-K MAC length 2- NB OF MACS PER 30S MAC length 3- MAC-K SPARE BITS MAC length
Key
length 10 11 12 13 14 15 16 17 18 19 20 10 11 12 13 14 15 16 17 18 19 20 10 11 12 13 14 15 16 17 18 19 20
80 6 5 5 5 5 5 5 4 4 4 4 12 10 10 10 10 10 10 8 8 8 8 4 25 20 15 10 5 0 28 24 20 16
81 6 5 5 5 5 5 4 4 4 4 4 12 10 10 10 10 10 8 8 8 8 8 3 24 19 14 9 4 31 27 23 19 15
82 6 5 5 5 5 5 4 4 4 4 4 12 10 10 10 10 10 8 8 8 8 8 2 23 18 13 8 3 30 26 22 18 14
83 6 5 5 5 5 5 4 4 4 4 4 12 10 10 10 10 10 8 8 8 8 8 1 22 17 12 7 2 29 25 21 17 13
84 6 5 5 5 5 5 4 4 4 4 4 12 10 10 10 10 10 8 8 8 8 8 0 21 16 11 6 1 28 24 20 16 12
85 5 5 5 5 5 5 4 4 4 4 4 10 10 10 10 10 10 8 8 8 8 8 25 20 15 10 5 0 27 23 19 15 11
86 5 5 5 5 5 4 4 4 4 4 4 10 10 10 10 10 8 8 8 8 8 8 24 19 14 9 4 30 26 22 18 14 10
87 5 5 5 5 5 4 4 4 4 4 4 10 10 10 10 10 8 8 8 8 8 8 23 18 13 8 3 29 25 21 17 13 9
88 5 5 5 5 5 4 4 4 4 4 4 10 10 10 10 10 8 8 8 8 8 8 22 17 12 7 2 28 24 20 16 12 8
89 5 5 5 5 5 4 4 4 4 4 4 10 10 10 10 10 8 8 8 8 8 8 21 16 11 6 1 27 23 19 15 11 7
90 5 5 5 5 5 4 4 4 4 4 4 10 10 10 10 10 8 8 8 8 8 8 20 15 10 5 0 26 22 18 14 10 6
91 5 5 5 5 4 4 4 4 4 4 4 10 10 10 10 8 8 8 8 8 8 8 19 14 9 4 29 25 21 17 13 9 5
92 5 5 5 5 4 4 4 4 4 4 4 10 10 10 10 8 8 8 8 8 8 8 18 13 8 3 28 24 20 16 12 8 4
93 5 5 5 5 4 4 4 4 4 4 4 10 10 10 10 8 8 8 8 8 8 8 17 12 7 2 27 23 19 15 11 7 3
94 5 5 5 5 4 4 4 4 4 4 4 10 10 10 10 8 8 8 8 8 8 8 16 11 6 1 26 22 18 14 10 6 2
95 5 5 5 5 4 4 4 4 4 4 4 10 10 10 10 8 8 8 8 8 8 8 15 10 5 0 25 21 17 13 9 5 1
96 5 5 5 4 4 4 4 4 4 4 4 10 10 10 8 8 8 8 8 8 8 8 14 9 4 28 24 20 16 12 8 4 0
97 5 5 5 4 4 4 4 4 4 4 3 10 10 10 8 8 8 8 8 8 8 6 13 8 3 27 23 19 15 11 7 3 35
98 5 5 5 4 4 4 4 4 4 4 3 10 10 10 8 8 8 8 8 8 8 6 12 7 2 26 22 18 14 10 6 2 34
99 5 5 5 4 4 4 4 4 4 4 3 10 10 10 8 8 8 8 8 8 8 6 11 6 1 25 21 17 13 9 5 1 33
100 5 5 5 4 4 4 4 4 4 4 3 10 10 10 8 8 8 8 8 8 8 6 10 5 0 24 20 16 12 8 4 0 32
101 5 5 4 4 4 4 4 4 4 3 3 10 10 8 8 8 8 8 8 8 6 6 9 4 27 23 19 15 11 7 3 34 31
102 5 5 4 4 4 4 4 4 4 3 3 10 10 8 8 8 8 8 8 8 6 6 8 3 26 22 18 14 10 6 2 33 30
103 5 5 4 4 4 4 4 4 4 3 3 10 10 8 8 8 8 8 8 8 6 6 7 2 25 21 17 13 9 5 1 32 29
104 5 5 4 4 4 4 4 4 4 3 3 10 10 8 8 8 8 8 8 8 6 6 6 1 24 20 16 12 8 4 0 31 28
105 5 5 4 4 4 4 4 4 3 3 3 10 10 8 8 8 8 8 8 6 6 6 5 0 23 19 15 11 7 3 33 30 27
106 5 4 4 4 4 4 4 4 3 3 3 10 8 8 8 8 8 8 8 6 6 6 4 26 22 18 14 10 6 2 32 29 26
107 5 4 4 4 4 4 4 4 3 3 3 10 8 8 8 8 8 8 8 6 6 6 3 25 21 17 13 9 5 1 31 28 25
108 5 4 4 4 4 4 4 4 3 3 3 10 8 8 8 8 8 8 8 6 6 6 2 24 20 16 12 8 4 0 30 27 24
109 5 4 4 4 4 4 4 3 3 3 3 10 8 8 8 8 8 8 6 6 6 6 1 23 19 15 11 7 3 32 29 26 23
110 5 4 4 4 4 4 4 3 3 3 3 10 8 8 8 8 8 8 6 6 6 6 0 22 18 14 10 6 2 31 28 25 22
111 4 4 4 4 4 4 4 3 3 3 3 8 8 8 8 8 8 8 6 6 6 6 25 21 17 13 9 5 1 30 27 24 21
112 4 4 4 4 4 4 4 3 3 3 3 8 8 8 8 8 8 8 6 6 6 6 24 20 16 12 8 4 0 29 26 23 20
113 4 4 4 4 4 4 3 3 3 3 3 8 8 8 8 8 8 6 6 6 6 6 23 19 15 11 7 3 31 28 25 22 19
114 4 4 4 4 4 4 3 3 3 3 3 8 8 8 8 8 8 6 6 6 6 6 22 18 14 10 6 2 30 27 24 21 18
115 4 4 4 4 4 4 3 3 3 3 3 8 8 8 8 8 8 6 6 6 6 6 21 17 13 9 5 1 29 26 23 20 17
116 4 4 4 4 4 4 3 3 3 3 3 8 8 8 8 8 8 6 6 6 6 6 20 16 12 8 4 0 28 25 22 19 16
117 4 4 4 4 4 3 3 3 3 3 3 8 8 8 8 8 6 6 6 6 6 6 19 15 11 7 3 30 27 24 21 18 15
118 4 4 4 4 4 3 3 3 3 3 3 8 8 8 8 8 6 6 6 6 6 6 18 14 10 6 2 29 26 23 20 17 14
119 4 4 4 4 4 3 3 3 3 3 3 8 8 8 8 8 6 6 6 6 6 6 17 13 9 5 1 28 25 22 19 16 13
120 4 4 4 4 4 3 3 3 3 3 3 8 8 8 8 8 6 6 6 6 6 6 16 12 8 4 0 27 24 21 18 15 12
121 4 4 4 4 3 3 3 3 3 3 3 8 8 8 8 6 6 6 6 6 6 6 15 11 7 3 29 26 23 20 17 14 11
122 4 4 4 4 3 3 3 3 3 3 3 8 8 8 8 6 6 6 6 6 6 6 14 10 6 2 28 25 22 19 16 13 10
123 4 4 4 4 3 3 3 3 3 3 3 8 8 8 8 6 6 6 6 6 6 6 13 9 5 1 27 24 21 18 15 12 9
124 4 4 4 4 3 3 3 3 3 3 3 8 8 8 8 6 6 6 6 6 6 6 12 8 4 0 26 23 20 17 14 11 8
125 4 4 4 3 3 3 3 3 3 3 3 8 8 8 6 6 6 6 6 6 6 6 11 7 3 28 25 22 19 16 13 10 7
126 4 4 4 3 3 3 3 3 3 3 3 8 8 8 6 6 6 6 6 6 6 6 10 6 2 27 24 21 18 15 12 9 6
127 4 4 4 3 3 3 3 3 3 3 3 8 8 8 6 6 6 6 6 6 6 6 9 5 1 26 23 20 17 14 11 8 5
128 4 4 4 3 3 3 3 3 3 3 3 8 8 8 6 6 6 6 6 6 6 6 8 4 0 25 22 19 16 13 10 7 4
Table 38 - Authentication design parameters vs MAC/key lengths - 2 MAC-K sections / SF (ii)
4- UNPRED. SYMBOLS PER 30s MAC length 5- UNPRED. SYMBOL RATIO (VS. EDBS) MAC length 6- NA - 4SV MAC length
10 11 12 13 14 15 16 17 18 19 20 10 11 12 13 14 15 16 17 18 19 20 10 11 12 13 14 15 16 17 18 19 20
240 230 240 250 260 270 280 256 264 272 280 20.0% 19.2% 20.0% 20.8% 21.7% 22.5% 23.3% 21.3% 22.0% 22.7% 23.3% 184 188 192 196 200 204 208 212 216 220 224
242 232 242 252 262 272 250 258 266 274 282 20.2% 19.3% 20.2% 21.0% 21.8% 22.7% 20.8% 21.5% 22.2% 22.8% 23.5% 185 189 193 197 201 205 209 213 217 221 225
244 234 244 254 264 274 252 260 268 276 284 20.3% 19.5% 20.3% 21.2% 22.0% 22.8% 21.0% 21.7% 22.3% 23.0% 23.7% 186 190 194 198 202 206 210 214 218 222 226
246 236 246 256 266 276 254 262 270 278 286 20.5% 19.7% 20.5% 21.3% 22.2% 23.0% 21.2% 21.8% 22.5% 23.2% 23.8% 187 191 195 199 203 207 211 215 219 223 227
248 238 248 258 268 278 256 264 272 280 288 20.7% 19.8% 20.7% 21.5% 22.3% 23.2% 21.3% 22.0% 22.7% 23.3% 24.0% 188 192 196 200 204 208 212 216 220 224 228
230 240 250 260 270 280 258 266 274 282 290 19.2% 20.0% 20.8% 21.7% 22.5% 23.3% 21.5% 22.2% 22.8% 23.5% 24.2% 189 193 197 201 205 209 213 217 221 225 229
232 242 252 262 272 252 260 268 276 284 292 19.3% 20.2% 21.0% 21.8% 22.7% 21.0% 21.7% 22.3% 23.0% 23.7% 24.3% 190 194 198 202 206 210 214 218 222 226 230
234 244 254 264 274 254 262 270 278 286 294 19.5% 20.3% 21.2% 22.0% 22.8% 21.2% 21.8% 22.5% 23.2% 23.8% 24.5% 191 195 199 203 207 211 215 219 223 227 231
236 246 256 266 276 256 264 272 280 288 296 19.7% 20.5% 21.3% 22.2% 23.0% 21.3% 22.0% 22.7% 23.3% 24.0% 24.7% 192 196 200 204 208 212 216 220 224 228 232
238 248 258 268 278 258 266 274 282 290 298 19.8% 20.7% 21.5% 22.3% 23.2% 21.5% 22.2% 22.8% 23.5% 24.2% 24.8% 193 197 201 205 209 213 217 221 225 229 233
240 250 260 270 280 260 268 276 284 292 300 20.0% 20.8% 21.7% 22.5% 23.3% 21.7% 22.3% 23.0% 23.7% 24.3% 25.0% 194 198 202 206 210 214 218 222 226 230 234
242 252 262 272 254 262 270 278 286 294 302 20.2% 21.0% 21.8% 22.7% 21.2% 21.8% 22.5% 23.2% 23.8% 24.5% 25.2% 195 199 203 207 211 215 219 223 227 231 235
244 254 264 274 256 264 272 280 288 296 304 20.3% 21.2% 22.0% 22.8% 21.3% 22.0% 22.7% 23.3% 24.0% 24.7% 25.3% 196 200 204 208 212 216 220 224 228 232 236
246 256 266 276 258 266 274 282 290 298 306 20.5% 21.3% 22.2% 23.0% 21.5% 22.2% 22.8% 23.5% 24.2% 24.8% 25.5% 197 201 205 209 213 217 221 225 229 233 237
248 258 268 278 260 268 276 284 292 300 308 20.7% 21.5% 22.3% 23.2% 21.7% 22.3% 23.0% 23.7% 24.3% 25.0% 25.7% 198 202 206 210 214 218 222 226 230 234 238
250 260 270 280 262 270 278 286 294 302 310 20.8% 21.7% 22.5% 23.3% 21.8% 22.5% 23.2% 23.8% 24.5% 25.2% 25.8% 199 203 207 211 215 219 223 227 231 235 239
252 262 272 256 264 272 280 288 296 304 312 21.0% 21.8% 22.7% 21.3% 22.0% 22.7% 23.3% 24.0% 24.7% 25.3% 26.0% 200 204 208 212 216 220 224 228 232 236 240
254 264 274 258 266 274 282 290 298 306 274 21.2% 22.0% 22.8% 21.5% 22.2% 22.8% 23.5% 24.2% 24.8% 25.5% 22.8% 201 205 209 213 217 221 225 229 233 237 241
256 266 276 260 268 276 284 292 300 308 276 21.3% 22.2% 23.0% 21.7% 22.3% 23.0% 23.7% 24.3% 25.0% 25.7% 23.0% 202 206 210 214 218 222 226 230 234 238 242
258 268 278 262 270 278 286 294 302 310 278 21.5% 22.3% 23.2% 21.8% 22.5% 23.2% 23.8% 24.5% 25.2% 25.8% 23.2% 203 207 211 215 219 223 227 231 235 239 243
260 270 280 264 272 280 288 296 304 312 280 21.7% 22.5% 23.3% 22.0% 22.7% 23.3% 24.0% 24.7% 25.3% 26.0% 23.3% 204 208 212 216 220 224 228 232 236 240 244
262 272 258 266 274 282 290 298 306 276 282 21.8% 22.7% 21.5% 22.2% 22.8% 23.5% 24.2% 24.8% 25.5% 23.0% 23.5% 205 209 213 217 221 225 229 233 237 241 245
264 274 260 268 276 284 292 300 308 278 284 22.0% 22.8% 21.7% 22.3% 23.0% 23.7% 24.3% 25.0% 25.7% 23.2% 23.7% 206 210 214 218 222 226 230 234 238 242 246
266 276 262 270 278 286 294 302 310 280 286 22.2% 23.0% 21.8% 22.5% 23.2% 23.8% 24.5% 25.2% 25.8% 23.3% 23.8% 207 211 215 219 223 227 231 235 239 243 247
268 278 264 272 280 288 296 304 312 282 288 22.3% 23.2% 22.0% 22.7% 23.3% 24.0% 24.7% 25.3% 26.0% 23.5% 24.0% 208 212 216 220 224 228 232 236 240 244 248
270 280 266 274 282 290 298 306 278 284 290 22.5% 23.3% 22.2% 22.8% 23.5% 24.2% 24.8% 25.5% 23.2% 23.7% 24.2% 209 213 217 221 225 229 233 237 241 245 249
272 260 268 276 284 292 300 308 280 286 292 22.7% 21.7% 22.3% 23.0% 23.7% 24.3% 25.0% 25.7% 23.3% 23.8% 24.3% 210 214 218 222 226 230 234 238 242 246 250
274 262 270 278 286 294 302 310 282 288 294 22.8% 21.8% 22.5% 23.2% 23.8% 24.5% 25.2% 25.8% 23.5% 24.0% 24.5% 211 215 219 223 227 231 235 239 243 247 251
276 264 272 280 288 296 304 312 284 290 296 23.0% 22.0% 22.7% 23.3% 24.0% 24.7% 25.3% 26.0% 23.7% 24.2% 24.7% 212 216 220 224 228 232 236 240 244 248 252
278 266 274 282 290 298 306 280 286 292 298 23.2% 22.2% 22.8% 23.5% 24.2% 24.8% 25.5% 23.3% 23.8% 24.3% 24.8% 213 217 221 225 229 233 237 241 245 249 253
280 268 276 284 292 300 308 282 288 294 300 23.3% 22.3% 23.0% 23.7% 24.3% 25.0% 25.7% 23.5% 24.0% 24.5% 25.0% 214 218 222 226 230 234 238 242 246 250 254
262 270 278 286 294 302 310 284 290 296 302 21.8% 22.5% 23.2% 23.8% 24.5% 25.2% 25.8% 23.7% 24.2% 24.7% 25.2% 215 219 223 227 231 235 239 243 247 251 255
264 272 280 288 296 304 312 286 292 298 304 22.0% 22.7% 23.3% 24.0% 24.7% 25.3% 26.0% 23.8% 24.3% 24.8% 25.3% 216 220 224 228 232 236 240 244 248 252 256
266 274 282 290 298 306 282 288 294 300 306 22.2% 22.8% 23.5% 24.2% 24.8% 25.5% 23.5% 24.0% 24.5% 25.0% 25.5% 217 221 225 229 233 237 241 245 249 253 257
268 276 284 292 300 308 284 290 296 302 308 22.3% 23.0% 23.7% 24.3% 25.0% 25.7% 23.7% 24.2% 24.7% 25.2% 25.7% 218 222 226 230 234 238 242 246 250 254 258
270 278 286 294 302 310 286 292 298 304 310 22.5% 23.2% 23.8% 24.5% 25.2% 25.8% 23.8% 24.3% 24.8% 25.3% 25.8% 219 223 227 231 235 239 243 247 251 255 259
272 280 288 296 304 312 288 294 300 306 312 22.7% 23.3% 24.0% 24.7% 25.3% 26.0% 24.0% 24.5% 25.0% 25.5% 26.0% 220 224 228 232 236 240 244 248 252 256 260
274 282 290 298 306 284 290 296 302 308 314 22.8% 23.5% 24.2% 24.8% 25.5% 23.7% 24.2% 24.7% 25.2% 25.7% 26.2% 221 225 229 233 237 241 245 249 253 257 261
276 284 292 300 308 286 292 298 304 310 316 23.0% 23.7% 24.3% 25.0% 25.7% 23.8% 24.3% 24.8% 25.3% 25.8% 26.3% 222 226 230 234 238 242 246 250 254 258 262
278 286 294 302 310 288 294 300 306 312 318 23.2% 23.8% 24.5% 25.2% 25.8% 24.0% 24.5% 25.0% 25.5% 26.0% 26.5% 223 227 231 235 239 243 247 251 255 259 263
280 288 296 304 312 290 296 302 308 314 320 23.3% 24.0% 24.7% 25.3% 26.0% 24.2% 24.7% 25.2% 25.7% 26.2% 26.7% 224 228 232 236 240 244 248 252 256 260 264
282 290 298 306 286 292 298 304 310 316 322 23.5% 24.2% 24.8% 25.5% 23.8% 24.3% 24.8% 25.3% 25.8% 26.3% 26.8% 225 229 233 237 241 245 249 253 257 261 265
284 292 300 308 288 294 300 306 312 318 324 23.7% 24.3% 25.0% 25.7% 24.0% 24.5% 25.0% 25.5% 26.0% 26.5% 27.0% 226 230 234 238 242 246 250 254 258 262 266
286 294 302 310 290 296 302 308 314 320 326 23.8% 24.5% 25.2% 25.8% 24.2% 24.7% 25.2% 25.7% 26.2% 26.7% 27.2% 227 231 235 239 243 247 251 255 259 263 267
288 296 304 312 292 298 304 310 316 322 328 24.0% 24.7% 25.3% 26.0% 24.3% 24.8% 25.3% 25.8% 26.3% 26.8% 27.3% 228 232 236 240 244 248 252 256 260 264 268
290 298 306 288 294 300 306 312 318 324 330 24.2% 24.8% 25.5% 24.0% 24.5% 25.0% 25.5% 26.0% 26.5% 27.0% 27.5% 229 233 237 241 245 249 253 257 261 265 269
292 300 308 290 296 302 308 314 320 326 332 24.3% 25.0% 25.7% 24.2% 24.7% 25.2% 25.7% 26.2% 26.7% 27.2% 27.7% 230 234 238 242 246 250 254 258 262 266 270
294 302 310 292 298 304 310 316 322 328 334 24.5% 25.2% 25.8% 24.3% 24.8% 25.3% 25.8% 26.3% 26.8% 27.3% 27.8% 231 235 239 243 247 251 255 259 263 267 271
296 304 312 294 300 306 312 318 324 330 336 24.7% 25.3% 26.0% 24.5% 25.0% 25.5% 26.0% 26.5% 27.0% 27.5% 28.0% 232 236 240 244 248 252 256 260 264 268 272
223
Table 39 - Authentication design parameters vs MAC/key lengths - 3 MAC-K sections / SF (i)

1- NB OF MACS PER MAC-K MAC length 2- NB OF MACS PER 30S MAC length 3- MAC-K SPARE BITS MAC length
Key
length 10 11 12 13 14 15 16 17 18 19 20 10 11 12 13 14 15 16 17 18 19 20 10 11 12 13 14 15 16 17 18 19 20
80 3 2 2 2 2 2 2 2 2 2 2 9 6 6 6 6 6 6 6 6 6 6 2 26 24 22 20 18 16 14 12 10 8
81 3 2 2 2 2 2 2 2 2 2 2 9 6 6 6 6 6 6 6 6 6 6 1 25 23 21 19 17 15 13 11 9 7
82 3 2 2 2 2 2 2 2 2 2 2 9 6 6 6 6 6 6 6 6 6 6 0 24 22 20 18 16 14 12 10 8 6
83 2 2 2 2 2 2 2 2 2 2 2 6 6 6 6 6 6 6 6 6 6 6 25 23 21 19 17 15 13 11 9 7 5
84 2 2 2 2 2 2 2 2 2 2 2 6 6 6 6 6 6 6 6 6 6 6 24 22 20 18 16 14 12 10 8 6 4
85 2 2 2 2 2 2 2 2 2 2 2 6 6 6 6 6 6 6 6 6 6 6 23 21 19 17 15 13 11 9 7 5 3
86 2 2 2 2 2 2 2 2 2 2 2 6 6 6 6 6 6 6 6 6 6 6 22 20 18 16 14 12 10 8 6 4 2
87 2 2 2 2 2 2 2 2 2 2 2 6 6 6 6 6 6 6 6 6 6 6 21 19 17 15 13 11 9 7 5 3 1
88 2 2 2 2 2 2 2 2 2 2 2 6 6 6 6 6 6 6 6 6 6 6 20 18 16 14 12 10 8 6 4 2 0
89 2 2 2 2 2 2 2 2 2 2 1 6 6 6 6 6 6 6 6 6 6 3 19 17 15 13 11 9 7 5 3 1 35
90 2 2 2 2 2 2 2 2 2 2 1 6 6 6 6 6 6 6 6 6 6 3 18 16 14 12 10 8 6 4 2 0 34
91 2 2 2 2 2 2 2 2 2 1 1 6 6 6 6 6 6 6 6 6 3 3 17 15 13 11 9 7 5 3 1 34 33
92 2 2 2 2 2 2 2 2 2 1 1 6 6 6 6 6 6 6 6 6 3 3 16 14 12 10 8 6 4 2 0 33 32
93 2 2 2 2 2 2 2 2 1 1 1 6 6 6 6 6 6 6 6 3 3 3 15 13 11 9 7 5 3 1 33 32 31
94 2 2 2 2 2 2 2 2 1 1 1 6 6 6 6 6 6 6 6 3 3 3 14 12 10 8 6 4 2 0 32 31 30
95 2 2 2 2 2 2 2 1 1 1 1 6 6 6 6 6 6 6 3 3 3 3 13 11 9 7 5 3 1 32 31 30 29
96 2 2 2 2 2 2 2 1 1 1 1 6 6 6 6 6 6 6 3 3 3 3 12 10 8 6 4 2 0 31 30 29 28
97 2 2 2 2 2 2 1 1 1 1 1 6 6 6 6 6 6 3 3 3 3 3 11 9 7 5 3 1 31 30 29 28 27
98 2 2 2 2 2 2 1 1 1 1 1 6 6 6 6 6 6 3 3 3 3 3 10 8 6 4 2 0 30 29 28 27 26
99 2 2 2 2 2 1 1 1 1 1 1 6 6 6 6 6 3 3 3 3 3 3 9 7 5 3 1 30 29 28 27 26 25
100 2 2 2 2 2 1 1 1 1 1 1 6 6 6 6 6 3 3 3 3 3 3 8 6 4 2 0 29 28 27 26 25 24
101 2 2 2 2 1 1 1 1 1 1 1 6 6 6 6 3 3 3 3 3 3 3 7 5 3 1 29 28 27 26 25 24 23
102 2 2 2 2 1 1 1 1 1 1 1 6 6 6 6 3 3 3 3 3 3 3 6 4 2 0 28 27 26 25 24 23 22
103 2 2 2 1 1 1 1 1 1 1 1 6 6 6 3 3 3 3 3 3 3 3 5 3 1 28 27 26 25 24 23 22 21
104 2 2 2 1 1 1 1 1 1 1 1 6 6 6 3 3 3 3 3 3 3 3 4 2 0 27 26 25 24 23 22 21 20
105 2 2 1 1 1 1 1 1 1 1 1 6 6 3 3 3 3 3 3 3 3 3 3 1 27 26 25 24 23 22 21 20 19
106 2 2 1 1 1 1 1 1 1 1 1 6 6 3 3 3 3 3 3 3 3 3 2 0 26 25 24 23 22 21 20 19 18
107 2 1 1 1 1 1 1 1 1 1 1 6 3 3 3 3 3 3 3 3 3 3 1 26 25 24 23 22 21 20 19 18 17
108 2 1 1 1 1 1 1 1 1 1 1 6 3 3 3 3 3 3 3 3 3 3 0 25 24 23 22 21 20 19 18 17 16
109 1 1 1 1 1 1 1 1 1 1 1 3 3 3 3 3 3 3 3 3 3 3 25 24 23 22 21 20 19 18 17 16 15
110 1 1 1 1 1 1 1 1 1 1 1 3 3 3 3 3 3 3 3 3 3 3 24 23 22 21 20 19 18 17 16 15 14
111 1 1 1 1 1 1 1 1 1 1 1 3 3 3 3 3 3 3 3 3 3 3 23 22 21 20 19 18 17 16 15 14 13
112 1 1 1 1 1 1 1 1 1 1 1 3 3 3 3 3 3 3 3 3 3 3 22 21 20 19 18 17 16 15 14 13 12
113 1 1 1 1 1 1 1 1 1 1 1 3 3 3 3 3 3 3 3 3 3 3 21 20 19 18 17 16 15 14 13 12 11
114 1 1 1 1 1 1 1 1 1 1 1 3 3 3 3 3 3 3 3 3 3 3 20 19 18 17 16 15 14 13 12 11 10
115 1 1 1 1 1 1 1 1 1 1 1 3 3 3 3 3 3 3 3 3 3 3 19 18 17 16 15 14 13 12 11 10 9
116 1 1 1 1 1 1 1 1 1 1 1 3 3 3 3 3 3 3 3 3 3 3 18 17 16 15 14 13 12 11 10 9 8
117 1 1 1 1 1 1 1 1 1 1 1 3 3 3 3 3 3 3 3 3 3 3 17 16 15 14 13 12 11 10 9 8 7
118 1 1 1 1 1 1 1 1 1 1 1 3 3 3 3 3 3 3 3 3 3 3 16 15 14 13 12 11 10 9 8 7 6
119 1 1 1 1 1 1 1 1 1 1 1 3 3 3 3 3 3 3 3 3 3 3 15 14 13 12 11 10 9 8 7 6 5
120 1 1 1 1 1 1 1 1 1 1 1 3 3 3 3 3 3 3 3 3 3 3 14 13 12 11 10 9 8 7 6 5 4
121 1 1 1 1 1 1 1 1 1 1 1 3 3 3 3 3 3 3 3 3 3 3 13 12 11 10 9 8 7 6 5 4 3
122 1 1 1 1 1 1 1 1 1 1 1 3 3 3 3 3 3 3 3 3 3 3 12 11 10 9 8 7 6 5 4 3 2
123 1 1 1 1 1 1 1 1 1 1 1 3 3 3 3 3 3 3 3 3 3 3 11 10 9 8 7 6 5 4 3 2 1
124 1 1 1 1 1 1 1 1 1 1 1 3 3 3 3 3 3 3 3 3 3 3 10 9 8 7 6 5 4 3 2 1 0
125 1 1 1 1 1 1 1 1 1 1 0 3 3 3 3 3 3 3 3 3 3 0 9 8 7 6 5 4 3 2 1 0 35
126 1 1 1 1 1 1 1 1 1 0 0 3 3 3 3 3 3 3 3 3 0 0 8 7 6 5 4 3 2 1 0 34 34
127 1 1 1 1 1 1 1 1 0 0 0 3 3 3 3 3 3 3 3 0 0 0 7 6 5 4 3 2 1 0 33 33 33
128 1 1 1 1 1 1 1 0 0 0 0 3 3 3 3 3 3 3 0 0 0 0 6 5 4 3 2 1 0 32 32 32 32
224
Table 40 - authentication design parameters vs MAC/key lengths - 3 MAC-K sections / SF (ii)
4- UNPRED. SYMBOLS PER 30s MAC length 5- UNPRED. SYMBOL RATIO (VS. EDBS) MAC length 6- NA - 4SV MAC length
10 11 12 13 14 15 16 17 18 19 20 10 11 12 13 14 15 16 17 18 19 20 10 11 12 13 14 15 16 17 18 19 20
270 246 252 258 264 270 276 282 288 294 300 22.5% 20.5% 21.0% 21.5% 22.0% 22.5% 23.0% 23.5% 24.0% 24.5% 25.0% 184 188 192 196 200 204 208 212 216 220 224
273 249 255 261 267 273 279 285 291 297 303 22.8% 20.8% 21.3% 21.8% 22.3% 22.8% 23.3% 23.8% 24.3% 24.8% 25.3% 185 189 193 197 201 205 209 213 217 221 225
276 252 258 264 270 276 282 288 294 300 306 23.0% 21.0% 21.5% 22.0% 22.5% 23.0% 23.5% 24.0% 24.5% 25.0% 25.5% 186 190 194 198 202 206 210 214 218 222 226
249 255 261 267 273 279 285 291 297 303 309 20.8% 21.3% 21.8% 22.3% 22.8% 23.3% 23.8% 24.3% 24.8% 25.3% 25.8% 187 191 195 199 203 207 211 215 219 223 227
252 258 264 270 276 282 288 294 300 306 312 21.0% 21.5% 22.0% 22.5% 23.0% 23.5% 24.0% 24.5% 25.0% 25.5% 26.0% 188 192 196 200 204 208 212 216 220 224 228
255 261 267 273 279 285 291 297 303 309 315 21.3% 21.8% 22.3% 22.8% 23.3% 23.8% 24.3% 24.8% 25.3% 25.8% 26.3% 189 193 197 201 205 209 213 217 221 225 229
258 264 270 276 282 288 294 300 306 312 318 21.5% 22.0% 22.5% 23.0% 23.5% 24.0% 24.5% 25.0% 25.5% 26.0% 26.5% 190 194 198 202 206 210 214 218 222 226 230
261 267 273 279 285 291 297 303 309 315 321 21.8% 22.3% 22.8% 23.3% 23.8% 24.3% 24.8% 25.3% 25.8% 26.3% 26.8% 191 195 199 203 207 211 215 219 223 227 231
264 270 276 282 288 294 300 306 312 318 324 22.0% 22.5% 23.0% 23.5% 24.0% 24.5% 25.0% 25.5% 26.0% 26.5% 27.0% 192 196 200 204 208 212 216 220 224 228 232
267 273 279 285 291 297 303 309 315 321 267 22.3% 22.8% 23.3% 23.8% 24.3% 24.8% 25.3% 25.8% 26.3% 26.8% 22.3% 193 197 201 205 209 213 217 221 225 229 233
270 276 282 288 294 300 306 312 318 324 270 22.5% 23.0% 23.5% 24.0% 24.5% 25.0% 25.5% 26.0% 26.5% 27.0% 22.5% 194 198 202 206 210 214 218 222 226 230 234
273 279 285 291 297 303 309 315 321 270 273 22.8% 23.3% 23.8% 24.3% 24.8% 25.3% 25.8% 26.3% 26.8% 22.5% 22.8% 195 199 203 207 211 215 219 223 227 231 235
276 282 288 294 300 306 312 318 324 273 276 23.0% 23.5% 24.0% 24.5% 25.0% 25.5% 26.0% 26.5% 27.0% 22.8% 23.0% 196 200 204 208 212 216 220 224 228 232 236
279 285 291 297 303 309 315 321 273 276 279 23.3% 23.8% 24.3% 24.8% 25.3% 25.8% 26.3% 26.8% 22.8% 23.0% 23.3% 197 201 205 209 213 217 221 225 229 233 237
282 288 294 300 306 312 318 324 276 279 282 23.5% 24.0% 24.5% 25.0% 25.5% 26.0% 26.5% 27.0% 23.0% 23.3% 23.5% 198 202 206 210 214 218 222 226 230 234 238
285 291 297 303 309 315 321 276 279 282 285 23.8% 24.3% 24.8% 25.3% 25.8% 26.3% 26.8% 23.0% 23.3% 23.5% 23.8% 199 203 207 211 215 219 223 227 231 235 239
288 294 300 306 312 318 324 279 282 285 288 24.0% 24.5% 25.0% 25.5% 26.0% 26.5% 27.0% 23.3% 23.5% 23.8% 24.0% 200 204 208 212 216 220 224 228 232 236 240
291 297 303 309 315 321 279 282 285 288 291 24.3% 24.8% 25.3% 25.8% 26.3% 26.8% 23.3% 23.5% 23.8% 24.0% 24.3% 201 205 209 213 217 221 225 229 233 237 241
294 300 306 312 318 324 282 285 288 291 294 24.5% 25.0% 25.5% 26.0% 26.5% 27.0% 23.5% 23.8% 24.0% 24.3% 24.5% 202 206 210 214 218 222 226 230 234 238 242
297 303 309 315 321 282 285 288 291 294 297 24.8% 25.3% 25.8% 26.3% 26.8% 23.5% 23.8% 24.0% 24.3% 24.5% 24.8% 203 207 211 215 219 223 227 231 235 239 243
300 306 312 318 324 285 288 291 294 297 300 25.0% 25.5% 26.0% 26.5% 27.0% 23.8% 24.0% 24.3% 24.5% 24.8% 25.0% 204 208 212 216 220 224 228 232 236 240 244
303 309 315 321 285 288 291 294 297 300 303 25.3% 25.8% 26.3% 26.8% 23.8% 24.0% 24.3% 24.5% 24.8% 25.0% 25.3% 205 209 213 217 221 225 229 233 237 241 245
306 312 318 324 288 291 294 297 300 303 306 25.5% 26.0% 26.5% 27.0% 24.0% 24.3% 24.5% 24.8% 25.0% 25.3% 25.5% 206 210 214 218 222 226 230 234 238 242 246
309 315 321 288 291 294 297 300 303 306 309 25.8% 26.3% 26.8% 24.0% 24.3% 24.5% 24.8% 25.0% 25.3% 25.5% 25.8% 207 211 215 219 223 227 231 235 239 243 247
312 318 324 291 294 297 300 303 306 309 312 26.0% 26.5% 27.0% 24.3% 24.5% 24.8% 25.0% 25.3% 25.5% 25.8% 26.0% 208 212 216 220 224 228 232 236 240 244 248
315 321 291 294 297 300 303 306 309 312 315 26.3% 26.8% 24.3% 24.5% 24.8% 25.0% 25.3% 25.5% 25.8% 26.0% 26.3% 209 213 217 221 225 229 233 237 241 245 249
318 324 294 297 300 303 306 309 312 315 318 26.5% 27.0% 24.5% 24.8% 25.0% 25.3% 25.5% 25.8% 26.0% 26.3% 26.5% 210 214 218 222 226 230 234 238 242 246 250
321 294 297 300 303 306 309 312 315 318 321 26.8% 24.5% 24.8% 25.0% 25.3% 25.5% 25.8% 26.0% 26.3% 26.5% 26.8% 211 215 219 223 227 231 235 239 243 247 251
324 297 300 303 306 309 312 315 318 321 324 27.0% 24.8% 25.0% 25.3% 25.5% 25.8% 26.0% 26.3% 26.5% 26.8% 27.0% 212 216 220 224 228 232 236 240 244 248 252
297 300 303 306 309 312 315 318 321 324 327 24.8% 25.0% 25.3% 25.5% 25.8% 26.0% 26.3% 26.5% 26.8% 27.0% 27.3% 213 217 221 225 229 233 237 241 245 249 253
300 303 306 309 312 315 318 321 324 327 330 25.0% 25.3% 25.5% 25.8% 26.0% 26.3% 26.5% 26.8% 27.0% 27.3% 27.5% 214 218 222 226 230 234 238 242 246 250 254
303 306 309 312 315 318 321 324 327 330 333 25.3% 25.5% 25.8% 26.0% 26.3% 26.5% 26.8% 27.0% 27.3% 27.5% 27.8% 215 219 223 227 231 235 239 243 247 251 255
306 309 312 315 318 321 324 327 330 333 336 25.5% 25.8% 26.0% 26.3% 26.5% 26.8% 27.0% 27.3% 27.5% 27.8% 28.0% 216 220 224 228 232 236 240 244 248 252 256
309 312 315 318 321 324 327 330 333 336 339 25.8% 26.0% 26.3% 26.5% 26.8% 27.0% 27.3% 27.5% 27.8% 28.0% 28.3% 217 221 225 229 233 237 241 245 249 253 257
312 315 318 321 324 327 330 333 336 339 342 26.0% 26.3% 26.5% 26.8% 27.0% 27.3% 27.5% 27.8% 28.0% 28.3% 28.5% 218 222 226 230 234 238 242 246 250 254 258
315 318 321 324 327 330 333 336 339 342 345 26.3% 26.5% 26.8% 27.0% 27.3% 27.5% 27.8% 28.0% 28.3% 28.5% 28.8% 219 223 227 231 235 239 243 247 251 255 259
318 321 324 327 330 333 336 339 342 345 348 26.5% 26.8% 27.0% 27.3% 27.5% 27.8% 28.0% 28.3% 28.5% 28.8% 29.0% 220 224 228 232 236 240 244 248 252 256 260
321 324 327 330 333 336 339 342 345 348 351 26.8% 27.0% 27.3% 27.5% 27.8% 28.0% 28.3% 28.5% 28.8% 29.0% 29.3% 221 225 229 233 237 241 245 249 253 257 261
324 327 330 333 336 339 342 345 348 351 354 27.0% 27.3% 27.5% 27.8% 28.0% 28.3% 28.5% 28.8% 29.0% 29.3% 29.5% 222 226 230 234 238 242 246 250 254 258 262
327 330 333 336 339 342 345 348 351 354 357 27.3% 27.5% 27.8% 28.0% 28.3% 28.5% 28.8% 29.0% 29.3% 29.5% 29.8% 223 227 231 235 239 243 247 251 255 259 263
330 333 336 339 342 345 348 351 354 357 360 27.5% 27.8% 28.0% 28.3% 28.5% 28.8% 29.0% 29.3% 29.5% 29.8% 30.0% 224 228 232 236 240 244 248 252 256 260 264
333 336 339 342 345 348 351 354 357 360 363 27.8% 28.0% 28.3% 28.5% 28.8% 29.0% 29.3% 29.5% 29.8% 30.0% 30.3% 225 229 233 237 241 245 249 253 257 261 265
336 339 342 345 348 351 354 357 360 363 366 28.0% 28.3% 28.5% 28.8% 29.0% 29.3% 29.5% 29.8% 30.0% 30.3% 30.5% 226 230 234 238 242 246 250 254 258 262 266
339 342 345 348 351 354 357 360 363 366 369 28.3% 28.5% 28.8% 29.0% 29.3% 29.5% 29.8% 30.0% 30.3% 30.5% 30.8% 227 231 235 239 243 247 251 255 259 263 267
342 345 348 351 354 357 360 363 366 369 372 28.5% 28.8% 29.0% 29.3% 29.5% 29.8% 30.0% 30.3% 30.5% 30.8% 31.0% 228 232 236 240 244 248 252 256 260 264 268
345 348 351 354 357 360 363 366 369 372 315 28.8% 29.0% 29.3% 29.5% 29.8% 30.0% 30.3% 30.5% 30.8% 31.0% 26.3% 229 233 237 241 245 249 253 257 261 265 269
348 351 354 357 360 363 366 369 372 318 318 29.0% 29.3% 29.5% 29.8% 30.0% 30.3% 30.5% 30.8% 31.0% 26.5% 26.5% 230 234 238 242 246 250 254 258 262 266 270
351 354 357 360 363 366 369 372 321 321 321 29.3% 29.5% 29.8% 30.0% 30.3% 30.5% 30.8% 31.0% 26.8% 26.8% 26.8% 231 235 239 243 247 251 255 259 263 267 271
354 357 360 363 366 369 372 324 324 324 324 29.5% 29.8% 30.0% 30.3% 30.5% 30.8% 31.0% 27.0% 27.0% 27.0% 27.0% 232 236 240 244 248 252 256 260 264 268 272
225
Appendix D. Snapshot Authentication
MOTIVATION
GNSS positioning authentication requires authentic data and time of arrival

measurements. While data can be easily authenticated, reception time can be subject to
replay attacks, no matter that the signals are protected at spreading code level or at data
level, if the spoofer has the adequate means [36].
A receiver that is just switched on can be subject to replay attacks without noticing if it
starts acquiring the spoofed signals. The same occurs with snapshot positioning.
However, unpredictability poses a constraint to the attacker: If the signals are partly
unpredictable and these unpredictable features are later verified, a spoofer could apply a
delay to the signal, but it could hardly make the signal arrive earlier. Even if an attacker
placed a receiver just below the satellite, and relayed the signal to the spoofer through
other means, the signal cannot travel faster than the light speed, so it cannot arrive earlier
than from the satellite. Other attacks may look at the early samples after unpredictable
symbol transitions, in case of NMA, and make the symbols end faster, modifying the
number of codes that compose the pseudorange, but as mentioned in Chapter 3, these
attacks can be detected by careful signal processing.
The receiver can however use a trusted reference to time-tag the reception time of the
measurements. Still, if a spoofer adds selective delays, depending on the satellite
geometry it could induce to coherently false positions, as shown in Figure 77. However,
if an approximate height is known and introduced as a constraint, for example from a
digital elevation model (DEM), this threat is partly mitigated. This section presents an
algebraic description of signal authentication based on a trusted clock reference and the
expected user height as an additional constraint. The method can be applied to snapshot
positioning, as long as the signals in the snapshot contain features that are unpredictable
and verifiable. A similar idea to the one at the core of this chapter has been independently
outlined in [28], although the focus of this reference is on other authentication topics and
therefore it does not analyse the subject in detail.
BACKGROUND
The principal technical problem of location authentication seems related not to the data
authentication, which can be digitally signed, but to ensuring that the measurements used
in the position solution are the original ones and not a rebroadcast of them. While signal
replay can be detected when an attacker intends to take control of a receiver already
tracking authentic signals, at the moment of receiver start-up this detection seems more
difficult. The main vulnerability comes from the fact that the receiver may not have a
good-enough clock reference against which to check the signal times of arrival to
ascertain if they arrive in delay. The receiver may have been switched off for hours, days
or weeks, and the receiver clock bias may be too large. For example, current
Temperature-Controlled Cristal Oscillators (TCXO) in smartphone devices can have a
stability of up to 0.5 ppm (parts per million) (i.e. they can drift 0.5 seconds in a million
seconds, or 0.5 microseconds in a second) [104]. In some few milliseconds (some
hundred km at light speed), or even microseconds (some hundred metres at light speed),
an attacker could selectively replay the signal satellites with a coherent delay leading to a
coherently wrong position. Attacks in these situations cannot be protected through any
signal-only measures as NMA or SCE. We cannot assume the existence of method that
authenticates a fix based only on radionavigation signals against all types of known
attacks. In our help, there are other systems and protocols available that provide external
synchronisation:
 PTP (Precise Timing Protocol), defined in the IEEE-1588 Standard and providing
nanosecond-level synchronisation [105] [106] [107]17.
 Mobile communication network standards as or 4G LTE networks, expected to
provide time authentication to user terminals in the order of the microsecond.
 Other radiofrequency systems more difficult to spoof, transmitting a signal to
which the receiver can be synchronised (e.g. e-Loran), that can provide time
transfer in the nanosecond level.
 An external frequency standard signal connected to the receiver and providing a
time reference, or a second clock reference embedded in the user terminal.
17
It must be noted that the timing sources that provide timing by any protocol can also use GPS/GNSS receivers, and
therefore be also subject to spoofing. This is left out of the scope of the thesis. In any case, is not obvious to attack a
highly accurately synchronised network, even if it uses GPS, while remaining unnoticed.
227
 A previously authenticated time reference from the same receiver clock that is
propagated to the current time with an associated uncertainty. If the receiver is
using an accurate clock as e.g. a Chip-Scale Atomic Clock (CSAC), this process
is feasible with low accuracy degradation.
Based on this idea, the following section describes algebraically some methods to detect
such spoofing attacks. They are very simplified and more sophisticated methods based on
the same or similar principles are possible. This is left for further work.
GENERAL DESCRIPTION
The purpose of this method is to authenticate pseudoranges by adding time and

geometrical constraints. The ones analysed here are the receiver clock bias and the
receiver height. These methods do not assume any previous tracking of the authentic
signals. Therefore, they can be used for snapshot positioning or at signal acquisition.
External Receiver Clock Reference
This method is based on constraining the receiver clock bias through another time
synchronisation source. The method assumes the use of an accurate time reference
provided through any of the several other protocols and systems using an authenticated
point-to-point two-way link, unlike satellite one-way radionavigation signals, as the ones
mentioned above, or by a trusted accurate clock as a CSAC. The user terminal will be
able to time-tag the computed measurements with the external time reference in order to
constrain the position and time solution given originally by the GNSS measurements. In
other words, the receiver does not need to compute the bias because it is known.
A user terminal receiver can obtain an external time reference from a network server or
base stations through an authenticated communication channel, as follows:
 It can send a time-tagged request to a nearest base station/server of a mobile

network that is synchronised with the same time reference (e.g. GPS or Galileo
time) as that used for navigation, or a time reference whose offset is known to
that used for navigation. An authenticated channel is required.
 The server provides an accurately time-tagged message.
 The communication protocol allows the User Terminal (UT) synchronisation by
for example determining the packet time of departure plus estimating the delay of
228
a round-trip communication. Any other standard accurate synchronisation
protocols can be used, as the external synchronisation process is not the core of
the method.
By time tagging the reference time with the local time, the UT is able to determine the
time bias between the local clock and the time reference. In addition, the system needs
that:
 The pseudorange measurements used must come from satellites that include
unpredictability and authentication features as NMA, SCE, SSSC watermarking
[20] or others. That means that, if their signals are spoofed, they need to be
replayed to be correct by verifying a digital signature, a MAC, decoding a
cyphered stream, receiving the unpredictable symbols from an assistance channel,
or any other means as described in Chapter 3. This makes the only attack possible
to be the signal replay attack, in which case, this set of pseudorange
measurements will incorporate a delay introduced by the attacker.
 The data/codes modulated in the signals from which these measurements are
computed, have been authenticated by the authentication method proposed in the
signal, e.g. digital signatures or message authentication codes, or through
assistance data, e.g. verifying that the unpredictable demodulated symbols or
chips correspond to those received by the assistance server, and considered as
authentic.
 The data used to compute the satellite positions and times, is authentic, and
optionally the data to model the propagation errors if these error models are used
(e.g. Klobuchar ionospheric correction).
Therefore, signals incorporating the NMA solution proposed in Chapter 3 are good
candidates, as they contain some of the unpredictable symbols transmitted every 1.5
seconds, and their per-satellite TBA is only 10 seconds (TBA would become irrelevant if
an assistance server sends the unpredictable symbols through an authenticated channel).
Figure 77 shows a time-aided terminal under a meaconing attack. The user terminal (UT)
is receiving unpredictable signals from navigation satellites. It time-tags the received
signals with 𝑡𝑟𝑥,𝑚𝑒𝑎𝑠 , the local time reference. The UT is also synchronised with an
external synchronisation reference, shown as an external block in the figure. The external
synchronisation link allows to determine the actual offset b between 𝑡𝑟𝑥,𝑚𝑒𝑎𝑠 and 𝑡𝑚𝑒𝑎𝑠 ,
229
the time at which the measurements were actually received. If the receiver is not under
any signal replay attack, the bias of the position solution will coincide with the bias from
the external source. The figure shows the case whereby an attacker is replaying the
signals with a fixed delay D (necessary to perform the attack; in an intelligent spoofing
attack, the signals may incorporate a variable delay per satellite in addition to D, leading
to a coherently spoofed position. For simplicity, these variable delays have not been
considered in the illustration). If the receiver is receiving replayed signals, b'=b+D ≠ b,
so it can detect spoofing thanks to the external reference.
Figure 77 - User terminal, time reference and spoofer
External Receiver Position Height Reference
The principal constraint proposed here is an externally estimated height, e.g. through an
approximate position of the user in a given reference frame and/or a Geographical
Information System (GIS), or Digital Elevation Model (DEM), Digital Surface Model
(DSM) or Digital Terrain Model (DTM). Other altitude metrics, as e.g. barometers used
for aviation, are possible.
As no satellite signal can be received from underground, the satellite measurements

cannot by themselves constrain the height direction. There will be plausible (low-
residual) solution with replayed signals at heights below the actual one. If measurements
were received from satellites from both directions of the three axes (e.g. North, East,
Down or NED) this check would not be necessary, as a delay in the measurements would
lead to no plausible solution.
230
The use of the height helps constrain the solution. It may be comparable to having a
satellite at the Earth centre whose pseudorange is known, and corresponds to the height
(from the Earth centre, in this case; other reference points are possible) given by the
external sensor or model. The concept is illustrated in Figure 78. It presents a two-
dimensional example of the reduction of the plausible space of solutions due a priori
height and clock bias estimations.
Figure 78 - Reduction of solution space with height estimation
The figure presents two satellites located at distances R1 and R2 of the receiver (P). D
represents the delay for the spoofer to estimate and replay the signal. Without the height
estimation, the space of possible spoofed solutions is the purple area: The spoofer could
locate the receiver in any point of this area (P'), without the receiver having a way to
notice.
A navigation solution using measurements generated from rebroadcast signals would fall
out of the space of plausible data-authenticated navigation solutions and therefore would
be detected as a wrong solution. Therefore, if there is a plausible solution consistent with
the additional reference time, the obtained measurements, and the imposed height
constraint, we can conclude that, with a very high likelihood, a replay attack has not been
performed, or the position has not been displaced more than a certain distance in the
order of the accuracy of the measurements and the additional time reference (e.g. a time
source with a 1-μs accuracy would lead to an uncertainty in the order of 300m).
Other Constraints
Similarly, additional constraints that may be imposed on the solution are:
231
 Distance to a reference station or stations from a network, installed for

communication (e.g. mobile network base stations) or navigation and positioning
purposes, as RTK (Real Time Kinematic) networks.
 Other GIS information constraining the type of application under use, as for
example the elimination of non-passable areas for vehicular positioning
applications [108].
IMPLEMENTATION DESCRIPTION
This section describes some implementations of the method. Measurement errors (e.g.
multipath, ionosphere or receiver noise) are aggregated to a single error term 𝜺, without
precluding the implementation of error estimation according to standard navigation
models as those mentioned several times throughout the thesis.
The following sections present authenticated PVT navigation equation systems.
Navigation Solution without Estimation of Receiver Clock Bias and with Height
Verification
We assume that the receiver clock bias is provided from an external source and is
authenticated. We name it brx,ref in the remaining steps. The method assumes that brx,ref is
the bias at the measurement reception time. If not, the error will depend on the receiver
clock drift. For example, an error of 1ms in a clock with a 1ppm drift will lead to a bias
error of 1ms/106 = 1ns, or 30 cm.
The user terminal selects the pseudorange measurements of N satellites transmitting

unpredictable signals, N≥ 3. These pseudorange measurements are called ρi, i=1,..,N.
The user estimates the range measurements by subtracting brx,ref to the pseudoranges, and
any other ephemeris or propagation (ionosphere and troposphere) errors 𝜀𝑖 that are
known to the user, either from the satellite navigation message or from an assisted data
channel.
𝑟𝑖 = 𝜌𝑖 − 𝑏𝑟𝑥,𝑟𝑒𝑓 − 𝜀𝑖
(D.1)
i=1,..,N. N≥ 3
where 𝑟𝑖 is the range of satellite i, and 𝜀𝑖 incorporates all the pseudorange errors apart
from the receiver clock bias: satellite clock, ionosphere, troposphere, multipath and
232
receiver noise. These errors are modelled through data that is already authenticated, or
bounded through error model statistical distributions.
The UT computes a user position with the range measurements through standard methods
(Taylor linearization, Kalman filters [95], Least squares if more than three
measurements, etc.). In our particular case, the receiver clock bias, which is the fourth
unknown, does not need to be estimated, and instead the external bias estimation brx,ref is
used. The next steps are equivalent to standard position estimation methods (e.g. [5], Ch.
4). We start with an a-priori estimation of the state vector X0=(x0, y0, z0). The bias, as
already determined by brx,ref, is not part of the state vector.
Based on the reference time 𝑡𝑟𝑥,𝑚𝑒𝑎𝑠 + 𝑏𝑟𝑥,𝑟𝑒𝑓, in which measurements 𝜌𝑖 are time-
tagged, we predict the measurements 𝜌̂𝑖 that would be obtained for each satellite i.
𝜌̂𝑖 = |S𝑖 − 𝑋0 | + 𝑏𝑟𝑥,𝑟𝑒𝑓 + 𝜀̂𝑖 (D.2)
where S𝑖 is the satellite position vector at the estimated transmission time, X0 is the
receiver estimated position and 𝜀̂𝑖 is the estimated measurement delay error. We then
compute the difference between the received measurements 𝜌𝑖 and the predicted
measurements:
δ𝜌𝑖 = 𝜌𝑖 − 𝜌̂𝑖 (D.3)
We compute the geometry matrix H as an [i x 3] matrix, without the 4th column of 1s

usually employed for navigation to calculate the bias. The state vector is updated through
the standard least-squares iterations.
𝐻[𝑖 𝑥 3] = [−𝑒𝑖 ] (D.4)
δX = (𝐻 𝑇 𝐻)−1 𝐻 𝑇 δ𝜌
𝑋 = 𝑋0 + 𝛿𝑋 (D.5)
where 𝑒𝑖 is the unit vector pointing from X0 to the satellite i. We iterate several times by
using X as 𝑋0 for the next iteration, until the solution converges to a position X=(x,y,z).
The position, in ECEF coordinates, is converted to latitude, longitude and height geodetic
coordinates through the required translation matrix: Xgeod=(lat, long, h).
233
Now, the receiver will use estimation of the position height from an external source. This
estimation is called href in the following steps. Now, the receiver compares the height of
the estimated position h with href. If they differ more than a certain amount H_THR, then
the position is considered as not authenticated.
| href – h| < H_THR (D.6)
The value of H_THR will depend on the probability of missed detection (PMD) and
probability of false alarm (PFA) used in hypothesis testing, in which one hypothesis (H0)
assumes that there is no spoofing, and another one (H1) assumes there is. The distribution
errors are characterised and then the threshold is set to accept a maximum P FA. If no
accurate measurement of the user position height can be obtained, href can be calculated
as the minimum height for the user to be in or above the earth surface expressed in a
given reference frame. The threshold (H_THR) shall be adjusted to the desired missed
detection and false alert probabilities of the application, the uncertainty associated to the
position and external height estimations, and satellite geometry as reflected in the HDOP.
The use of height is important as otherwise the delayed measurements generated by an

attacker may be used to find a plausible solution with delayed (i.e. longer) ranges at a
lower height, as shown in Figure 78. To ensure that this is not occurring in other
directions, the receiver can check that the geometry does not allow ranging
measurements being increased while still leading to a coherent (i.e. low residual error)
position. Having satellites at low elevations will help constrain the solution. In addition,
common biases that are not part of the clock bias (e.g. receiver filters, non-modelled
ionospheric delay) will introduce a position error. This error may be assumable for many
applications requiring authentic positioning.
Including the Height as an Additional Pseudorange
Another possible method is to consider the height as an additional pseudorange source in

the navigation equations, and look at the solution residuals. The potentially higher error
of the external height estimation can be treated through the appropriate measurement
weighting. Weighed Least Squares estimation method is explained in detail in Chapter 11
of [109], for example, and is common practice in GNSS. In this case, if we have N
measurements, the component n+1 of the measurement vector 𝜌 would be the
234
determined by the height model, and the 'pseudo-satellite' position can be at the Earth
centre, or Cartesian coordinates (0,0,0).
𝜌̂𝑛+1 = |𝑋0 | + 𝑏𝑟𝑥,𝑟𝑒𝑓 (D.7)
𝜌𝑛+1 = 𝐹(𝑚𝑜𝑑𝑒𝑙, 𝑋0 ) + 𝑏𝑟𝑥,𝑟𝑒𝑓 (D.8)
̂𝒏+𝟏 is the estimated range from (0,0,0). 𝐹(𝑚𝑜𝑑𝑒𝑙, 𝑋0 ) provides that range
where 𝝆
from the height model, at a given , 𝑋0. The following equations present the weighted least
squares standard steps, when the '0,0,0' pseudo-satellite is used.
𝛿𝜌𝑛+1 = 𝜌𝑛+1 − 𝜌̂𝑛+1 (D.9)
𝛿𝑋 = (𝐻𝑇 𝑊𝐻)−1 𝐻𝑇 W𝛿𝜌 (D.10)
The last row of H will include the reverse-signed unit vector of the (0,0,0) pseudo-
satellite. If the solution converges to a position at the adequate height, it can be flagged
as authentic. If not, it can be flagged as not authenticated. If an overdetermined solution
is used, the measurement residuals |𝐻𝛿𝜌 − 𝛿𝑋| can be computed and if they are above a
given threshold, then the solution can be flagged as not authenticated. Similar hypothesis
testing as abovementioned can be performed.
Removing the Height Computation from the Satellite Positioning Solution
Another approach similar to this one, but perhaps simpler, would be to remove the height
unknown and compute just the two horizontal components. For each iteration, the height
would be taken from the height model. Combining this approach with the provision of
the clock bias from an external source makes that only two unpredictable signals are
sufficient to protect against replay.
Standard 4-Dimensional State Vector and Bias Threshold Comparison
Another approach is to use the standard navigation equations, solving the 3-dimensional
position and the bias, and then compare the difference between the obtained bias minus
brx,ref, with a threshold, equivalently to the proposal described after Figure 77. If the
spoofer is falsifying the position while maintaining the bias as correct, then the height of
the position solution needs to be verified, as per Equation (D.8).
235
|brx,ref – b| < B_THR (D.11)
CONCLUSIONS
The purpose of this appendix is to study the provision of snapshot authentication. It

serves as an epilogue of the technical and scientific work of this thesis, by merging the
two principal research areas.
Robustness against attacks taking place at the switch-on and acquisition phase is more
difficult to achieve than when authentic signals are tracked. The case of snapshot
positioning, and/or A-GNSS positioning, is similar. If no trusted time reference is
available, snapshot positioning can always be subject to an attack in which the attacker
has pre-recorded a snapshot and re-broadcasts it later.
The solutions proposed are therefore based on the knowledge of an accurate and
authentic external reference time. Accurate timing protocols (as e.g. PTP) that can
produce up to sub-ns timing accuracy, can be used to externally synchronise the receiver.
This appendix has focused on the PVT domain, assuming that the measurements coming
from the signal processing block are based on unpredictable and verifiable satellite
signals. In this case, an attacker can only delay the signals. If the clock bias is known, at
the time the measurements are time-tagged, the attacker can only make the pseudoranges
bigger, which poses some constraints for coherent attacks. Another constraint proposed
to detect attacks is to use height, from either a digital height model, GIS information, a
barometer, or more simply the geoid, assuming that the user is on the earth surface.
Depending on the input, the method will be more or less resilient.
Based on these two constraints, some methods to compute an authenticated position are
proposed. The methods are based on incorporating timing and geometric constraints in
the navigation solution.
We can conclude that, by applying these (and other) methods, robustness when signals
are acquired by a receiver with a stable and trusted reference clock can be high sufficient
with signal-only measures, especially if combined with geometrical constraints. Adding
other sensors (e.g. INS) to the positioning engine can nothing but improve the PNT
resilience in a complementary way.
236
Appendix E. Acronyms
3GPP 3rd Generation Partnership Project
AAU Aalborg University
ADC Analog to Digital Converter
ADKD Authentication Data and Key Delay
AER Authentication Error Rate
AES Advanced Encryption Standard
AGC Automatic Gain Control
A-GNSS Assisted GNSS
A-GPS Assisted GPS
AOA Angle Of Arrival
APNT Alternative Positioning, Navigation and Timing
AWGN Additive White Gaussian Noise
BER Bit Error Rate
BGD Broadcast Group Delay
BOC Binary Offset Carrier
BPSK Binary Phase Shift Keying
BSI British Standards Institution
C/N0 Carrier to Noise density ratio
CDMA Code Division Multiple Access
CET Central European Time
CMAC Cipher based Message Authentication Code
CPU Central Processing Unit
CRC Cyclic Redundancy Check
CRLB Cramér Rao Lower Bound
CS Commercial Service
CSAC Chip-Scale Atomic Clock
237
CT Coarse Time
CW Continuous Waveform
DEM Digital Elevation Model
DME Distance Measuring Equipment
DOP Dilution Of Precision
DOW Day Of Week
DSA Digital Signature Algorithm
DSH Digital Signature Header
DSID Digital Signature ID
DSM Digital Signature and Message
DSM Digital Surface Model
DSRC Dedicated Short-Range Communications
DSSS Direct Sequence Spread Spectrum
DTM Digital Terrain Model
ECDSA Elliptic Curve Digital Signature Algorithm
ECEF Earth Centred Earth Fixed
EDBS External Data Broadcast Service
EGNOS European Geostationary Navigation Overlay Service
ERIS External Regional Integrity Service
FDMA Frequency Division Multiple Access
FEC Forward Error Correction
FER Frame Error Rate
FFT Fast Fourier Transform
GBAS Ground Based Augmentation System
GDOP Geometric Dilution Of Precision
GEO Geostationary Earth Orbit
GIS Geographic Information System
GLONASS GLObal NAvigation Satellite System
238
GMS Ground Mission Segment
GNSS Global Navigation Satellite System
GPS Global Positioning System
GPST GPS Time
GSC European GNSS Service Centre
GST Galileo System Time
H-KROOT Header and Root Key
HMAC Hash-based Message Authentication Code
HS Health Status
ICD Interface Control Document
IEC International Electrotechnical Commission
IF Intermediate Frequency
IFFT Inverse Fast Fourier Transform
IIR Infinite Impulse Response
INS Inertial Navigation System
IOD Issue Of Data
IODnav Issue Of Data - Navigation
IRNSS Indian Radio Navigation Satellite System
ISO International Standards Organisation
IT Information Technologies
J/N Jamming to Noise
KPI Key Performance Indicator
LEO Low Earth Orbit
LMS Land Mobile Satellite
LSB Least Significant Bit
LTE Long Term Evolution
MAC Message Authentication Code
MAC-K MAC and Key
239
MEMS Micro-Electro-Mechanical Systems
MEO Medium Earth Orbit
MPT Maximum Predictable Time
MSAS Multi-functional Satellite Augmentation System
MSB Most Significant Bit
NA Number of Authentication bits
NED North East Down
NIST National Institute of Standards and Technology
NMA Navigation Message Authentication
NN Number of Navigation bits
NNA Number of Navigation and Authentication bits
NSA National Security Agency
OS Open Service
OTAR Over-The-Air Rekeying
PAM Pulse Amplitude Modulation
PDOP Position Dilution of Precision
PKI Public Key Infrastructure
PLL Phase Locked Loop
PNT Positioning, Navigation and Timing
PPM Parts Per Million
PRN Pseudo Random Number
PRS Public Regulated Services
PSK Phase Shift Keying
PTP Precise Time Protocol
PVT Position, Velocity and Time
QZSS Quasi-Zenith Satellite System
RAIM Receiver Autonomous Integrity Monitoring
RF Radio Frequency
240
RMS Root Mean Squared
RSA Rivest, Shamir and Adleman
RSS Receiver Signal Strength
RTK Real Time Kinematics
SAASM Selective Availability and Anti-Spoofing Module
SBAS Satellite Based Augmentation System
SCE Spreading Code Encryption
SCER Security Code Estimation and Replay
SDR Software Defined Radio
SHA Secure Hash Algorithm
SIS Signal in Space
SSSC Spread Spectrum Security Codes
SVID Space Vehicle ID
TACAN Tactical Air Navigation System
TBA Time Between Authentications
TCXO Temperature-Controlled Cristal Oscillator
TDMA Time Division Multiple Access
TDOA Time Difference Of Arrival
TDOP Time Dilution of Precision
TESLA Timed Efficient Stream Loss-Tolerant Authentication
TLM Telemetry
TOA Time Of Arrival
TOW Time Of Week
TTFAF Time To First Authenticated Fix
TTFF Time To First Fix
UERE User Equivalent Range Error
ULS Up-Link Station
USR Unpredictable Symbol Ratio
241
USRP Universal Software Radio Peripherals
UT User Terminal
UTC Universal Time Coordinated
VOR VHF Omni-directional Radio Range
WAAS Wide Area Augmentation System
WGS84 World Geodetic System 1984
WLS Weighted Least Squares
WN Week Number
XOR eXclusive OR
242
Appendix F. Published Papers
Thesis title: Snapshot and Authentication Techniques for Satellite Navigation
Name of PhD student: Ignacio Fernández Hernández
Name and title of supervisor and any other supervisors: Prof. Torben Larsen. Prof Kai
Borre.
List of published papers:
Paper 1: I. Fernández Hernández, “Authentication: Design Parameters and Service

Concepts,” Proceedings of the European Navigation Conference, 2014.
Paper 2: I. Fernandez-Hernandez, V. Rijmen, G. Seco-Granados, J. Simón, I.

Rodríguez, J.D. Calle, “Design Drivers, Solutions and Robustness Assessment of
Navigation Message Authentication for the Galileo Open Service,” in ION GNSS+
2014, 2014.
Paper 3 (pending): I. Fernandez-Hernandez, V. Rijmen, G. Seco-Granados, J. Simón,

I. Rodríguez, J.D. Calle, "A Navigation Message Authentication Proposal for
theGalileo Open Service", The Journal of the Institute of Navigation, Date to be
defined.
"This thesis has been submitted for assessment in partial fulfilment of the PhD degree.
The thesis is based on the submitted or published scientific papers which are listed
above. Parts of the papers are used directly or indirectly in the extended summary of
the thesis. As part of the assessment, co-author statements have been made available to
the assessment committee and are also available at the Faculty. The thesis is not in its
present form acceptable for open publication but only in limited and closed circulation
as copyright may not be ensured.".
243

PHD Thesis Ifernandez Aau OTTIMA

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

PHD Thesis Ifernandez Aau OTTIMA

Enviado por

Direitos autorais:

Formatos disponíveis

SNAPSHOT AND AUTHENTICATION TECHNIQUES

FOR SATELLITE NAVIGATION

Ignacio Fernández Hernández

Dissertation submitted to the Faculty of Engineering and Science at Aalborg University

in partial fulfilment of the requirements for the degree of

Doctor of Philosophy in Electrical Engineering.

Thesis submitted: May 7th, 2015

PhD supervisors: Prof. Kai Borre,

Prof. Torben Larsen,

PhD committee: Prof. Per K. Enge, Stanford University

Dr. Frank van Diggelen, Broadcom Corporation

Prof. Søren Holdt Jensen, Aalborg University

PhD Series: Faculty of Engineering and Science, Aalborg University

Det første forskningsområde i denne afhandling vedrører troværdigheden af GNSS. På trods

Afhandlingens andet forskningsområde vedrører snap-shot positionering. Snap-shot metoder

Chapter 1. Introduction ..................................................................................................... 17

1.2. Thesis Outline ........................................................................................................ 20

Chapter 2. General Technical Background....................................................................... 21

2.2. Radionavigation Methods ...................................................................................... 24

2.2.1. Satellite Navigation Systems and Signals ........................................................ 25

2.2.2. Satellite Navigation Receivers ......................................................................... 28

2.3. A Brief History of Cryptography ........................................................................... 29

2.3.1. Modern Cryptography and Asymmetric Algorithms ....................................... 31

2.3.2. GNSS and Cryptography ................................................................................. 33

Chapter 3. Navigation Message Authentication ............................................................... 36

3.2. Background ............................................................................................................ 37

3.2.1. Information Security Management Systems (ISMS) ....................................... 37

3.2.2. Standards .......................................................................................................... 38

3.2.3. GNSS Positioning Threats ............................................................................... 40

3.2.4. Detection and Mitigation Actions .................................................................... 41

3.2.5. Detection and Mitigation based on GNSS Signal Properties........................... 42

3.2.6. Summary .......................................................................................................... 43

3.4. Performance Indicators .......................................................................................... 46

3.4.1. Authentication Error Rate ................................................................................ 48

3.4.2. Time Between Authentications ........................................................................ 49

3.4.4. Other Robustness Indicators ............................................................................ 51

3.5. Proposed GNSS Authentication Concept .............................................................. 51

3.5.1. The TESLA Protocol Features ......................................................................... 51

3.5.2. TESLA with a Single Chain from Several Senders ......................................... 54

3.5.4. TESLA and "Cross-Authentication" ................................................................ 58

3.6. An NMA Proposal for Galileo Signals .................................................................. 59

3.6.1. H-K-root Section ............................................................................................. 62

3.6.2. MAC-K Sections ............................................................................................. 65

3.6.3. Bandwidth Allocation Analysis ....................................................................... 69

3.7. A Proposed Implementation in the Galileo System and Facilities ......................... 70

3.7.1. NMA Architecture ........................................................................................... 70

3.7.2. System Latency and User Performance ........................................................... 71

3.7.3. Message Losses ............................................................................................... 75

3.7.4. Downlink Requirements .................................................................................. 76

3.7.5. NMA of Data from Other GNSS ..................................................................... 77

3.8. Design Trade-Offs.................................................................................................. 77

3.8.1. Cross-Authentication of Neighbouring Satellites ............................................ 78

3.8.2. Digital Signatures vs. Time-Delayed Asymmetry ........................................... 80

3.8.3. Staggering of Authentication Events ............................................................... 81

3.8.4. Security Considerations ................................................................................... 83

3.8.5. Receiver CPU Needs ....................................................................................... 85

3.9. Performance Results............................................................................................... 86

3.9.1. NMA Availability and AER ............................................................................ 86

3.9.2. Time To First Authenticated Fix ................................................................... 100

3.9.3. Performance Assessment in Urban Environments – A Practical Case .......... 103

3.9.4. Assumptions for satellites transmitting NMA ............................................... 106

3.9.5. Assumptions for satellite MAC sequence ...................................................... 106

3.10. Signal Unpredictability and Anti-Replay Protection ......................................... 108