snapshot and authentication techniques for … and authentication techniques for satellite...

I

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.

SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION

II

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

III

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.


IV

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.

V

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.

6

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.

7

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.


8

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

9

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


10

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

11

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


12

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

13

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


14

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

15

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


16

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

17

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


18

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:

19

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).


20

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.

21

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


22

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

23

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.


24

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

25

(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


26

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]

27

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


28

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.

29

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


30

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.

31

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


32

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.

33

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)


34

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

35

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.


36

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

37

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


38

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

39

[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.


40

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

41

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


42

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

43

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


44

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.

45

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.


46

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,

47

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.


48

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

2 ∙ 𝑒𝑟𝑓𝑐(√𝐶/𝑁0 ∙ 𝑇) (3.3)

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)

49

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


50

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:

𝑇𝐵𝐴̅̅ ̅̅ ̅̅ =𝑇𝐵𝐴

1 − 𝐴𝐸𝑅 (3.5)

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:

𝑇𝑇𝐹𝐴𝐹̅̅ ̅̅ ̅̅ ̅̅ ̅ =𝑇𝐵𝐴

2+ 𝑇𝐵𝐴̅̅ ̅̅ ̅̅ (3.6)

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

51

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.


52

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.

53

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)


54

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.

55

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:


56

𝐾𝑗,𝑀𝐴𝐶 = 𝐹𝑖−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

57

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


58

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.

59

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.


60

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.

61

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.


62

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.

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

He

ade

r

DS

hea

der

DSM (H-K-root section)

63

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.


64

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.

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.

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

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

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

65

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)


66

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.

67

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.


68

Table 2 – ADKD parameter proposed definition

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.

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




69

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

[bits]

MAC size [bits] Number of

MACs per

MAC-K section

Number of

MACs per 30-

seconds

Number of keys

per 30-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

[bits]

MAC size [bits] Number of

MACs

Number of

MACs per 30-

seconds

Number of keys

per 30-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


70

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

71

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


72

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,

73

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.


74

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),

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

75

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)


76

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

(1-Perr)

0.99960006 0.999960001

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

77

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.


78

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.

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.

Rx

P1Auth(P1)Auth(P2)Auth(P3)Auth(P4)

P2 P3 P4

79

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.


80

Table 6 - Percentage out-of-view satellites as a function of the number of MACs and the masking angle – source: L. Bogaardt, EC.

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

MACs per connected satellite

1 2 3 4 5 6 7 8 9 10 11 12

Ma

skin

g a

ng

le

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

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

81

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


82

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).

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.

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

83

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


84

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:

85

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


86

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.

87

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

506

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.

They are in any case of little relevance for the calculations.

NA1

108

NA = Number of authentication bits to data-authenticate a satellite

MAC-info: 16 bits; MAC: 10 bits; Key: 82 bits

NNA1

614

NNA = Number of Navigation and Authentication bits required to

authenticate a satellite (only ephemeris and clock counted)

4Satellites, Ephemerides and Clocks (Words 1-4) Authentication

NN4

2044

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

incorrect, the key vs. K-root verification will fail.

NA4

186

NA4 = Number of Authentication bits required to authenticate four

satellites (4 MACs of ADKD=0 type)

MAC-info: 4*16; MAC: 4*10; Key: 82

NNA4

2230

NNA4 = Number of Navigation and Authentication bits required

to authenticate 4 satellites (only ephemerides, clocks and TOW

counted)

4Satellites, Ephemerides and Clocks (Words 1-4) and Iono-BGD (Word 5) Authentication

NN4I

2129

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

5).

NA4I

212

NA4I = Number of Authentication bits required to authenticate

four satellites (4 MACs of ADKD=0 type) and "ionoBGD"

(ADKD=1)


88

MAC-info: 5*16; MAC: 5*10; Key: 82

NNA4I

2341

NNA4 = Number of Navigation and Authentication bits required

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

2 ∙ (36𝐷10 + 21𝐷12 + 1404𝐷14 + 11633𝐷16) (3.16)

𝐷 = e

−1

2R𝑏𝐶/𝑁0

(3.17)

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

89

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


90

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'

91

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

25.8 25.9 26 26.1 26.2 26.3

10-2.9

10-2.7

10-2.5

10-2.3

10-2.1

C/N0 [dBHz]

Err

or

Ra

tes

FER-1SV

AER-1SV

FER-4SV

AER-4SV

FER-4SVI

AER-4SVI


92

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

93

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:

�̅� = [1

N𝑀𝐾∑(𝐾𝐹𝐸𝑅)

𝑖

N𝑀𝐾

𝑖=1

]

𝐶

(3.19)

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


94

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 2

nd 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.

95

𝑝(𝐴𝑈𝑇𝐻𝑃𝑉𝑇) = 𝑝(𝐹 ≤ 𝐿 − 4) =

𝑝(𝐹 = 0) + 𝑝(𝐹 = 1) +⋯+ 𝑝(𝐹 = 𝐿 − 4)

(3.23)

Table 8 presents the NMA performance scenarios and associated parameters.

Table 8 – NMA Performance Scenarios and Parameters

Parameters vs.

Scenarios

Nominal-2C Nominal-1C Worst Case

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

Size

26 bits 26 bits 36 bits

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.


96

The following plots in Figure 33 present some results for different scenarios: Nominal-

2C (top), Nominal-1C (middle) and Worst-Case (bottom).

97

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


98

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.

99

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.


100

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

101

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'.

102

Table 9 – Data Authentication in different Acquisition Modes

Almanacs K-root P0

(<100km

error)

T0 (<1

min)

TOW Ephemerides

& clocks

Data-

authenticated

Ephemerides

Comments and Assumptions TTFF; TTFAF

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

Frame (720s), so authentication does not

degrade TTFAF wrt. TTFF.

Signal Acquisition lasts 2.5 min approx.

TTFF = TTFAF≈ 15 min

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).

Signal Acquisition lasts 30 seconds.

K-root received in 3 subframes.

TTFF ≈ 1 min

TTFAF ≈ 2 min

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 degrade TTFAF wrt. TTFF.

TTFAF = TTFF ≈ 1 min

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

wrt. cold start, K-root.

TTFAF = TTFF ≈ 30 seconds

Hot Start Y Y Y Y Y Y Y The receiver navigates with the previously

authenticated ephemeris.

If anti-replay is considered, TBA (10 seconds) should be waited for a new

authentication event.

TTFAF = TTFF ≈ 1 second

103

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 field9 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).


104

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

drop [dB]

C/N0 [dBHz]

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:

105

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]


106

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.

107

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)

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

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



108

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:

109

𝑈𝑆𝑅 = (𝐾𝑙𝑒𝑛 − 𝐾𝑝𝑟𝑒𝑑 + 𝑁𝑀𝐴𝐶 𝑀𝐴𝐶𝑙𝑒𝑛)𝑁𝑀𝐴𝐶𝐾

𝑁𝑆𝐹 (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


110

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).

111

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: ½


112

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.

113

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.

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.

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

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


114

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.

115

Table 18 – I/NAV 240-symbol unpredictability after interleaving.

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

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


116

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.

117

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

2 𝑒𝑟𝑓𝑐(√𝑚𝑇𝑠𝐶/(𝑁0 + 𝐼0) ) (3.28)

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


118

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

𝑀∑ 𝑝𝑒𝑟𝑟(𝑚)

𝑀

𝑚=1

(3.29)

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 = 𝑝𝑒𝑟𝑟(𝑀).

119

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.


120

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

121

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"


122

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)

23% (of auth.)

Assuming 276 unpredictable symbols every 30

seconds.

3.68% of total I/NAV symbols (7500 per subframe)

23% of authentication symbols (1200 per subframe)

AER See Figure 30,

Figure 31

Minimal degradation wrt. navigation frame error

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.

123

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.


124

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.

125

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


126

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

127

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 휀.


128

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).

129

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 �̂� and the measured dopplers D (𝛿𝐷 = 𝐷 − �̂�), −𝑒′𝑖 is the derivative

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

11The notation has been adapted to the one used throughout the dissertation


130

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.

131

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


132

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.

133

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 𝑅𝑅𝑖]

[ 𝛿𝑥′

𝛿𝑦′

𝛿𝑧′

𝛿𝑏′

𝛿𝑡𝑐′]

+ 휀

= [−𝑒𝑖′𝑎𝑖] [

𝛿𝑥𝛿𝑦𝛿𝑧𝛿𝑡𝑐

] + [−𝑒𝑖 1 𝑅𝑅𝑖]

[ 𝛿𝑣𝑥𝛿𝑣𝑦𝛿𝑣𝑧𝛿𝑓𝑑0 ]

+ 휀

(4.8)

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:


134

𝑒 =�̅�

𝑟

𝑒′ = (1

𝑟2)[�̅�′𝑟 − �̅�𝑟′]

= (1

𝑟2)[ (𝑉𝑠_𝑟𝑥̅̅ ̅̅ ̅̅ ̅̅ )𝑟 − (�̅�)𝑅𝑅]

= (1

𝑟) (𝑉𝑠_𝑟𝑥̅̅ ̅̅ ̅̅ ̅̅ − 𝑒𝑅𝑅)

(4.10)

where 𝑉𝑠_𝑟𝑥̅̅ ̅̅ ̅̅ ̅̅ is the vector of satellite velocity relative to the receiver. A similar expression is

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.

135

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.


136

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.

137

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.


138

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.)

139

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


140

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

141

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.


142

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

143

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

configuration

file

Sampling

Frequency

[Hz]

Intermediate

Frequency

[Hz]

Location Date Data

Analysed

Number

an

Duration

of

Snapshots

Calculated 12

1 20050507-

col-1s.cfg

38.192e6 9.548e6 University of

Boulder,

Colorado, U.S.

7th May

2005

200 ms 20, 10ms

2 20100302-

dgc-1s.cfg

16368e3 4129945 Danish GPS

Centre, Aalborg,

Denmark.

2nd

March

2010

200 ms 20, 10ms

3 20100325-

ctae-1s.cfg

16368e3 4129945 CTAE,

Barcelona,

Spain

25th

March

2010

200 ms 20, 10ms

4 20100427-

dgc-1s.cfg

16368e3 4129945 Danish GPS

Centre, Aalborg,

Denmark.

27th April

2010

200 ms 20, 10ms

5 20100617-

glcs-1s.cfg

16368e3 4129945 Gallecs,

Barcelona,

Spain

17th June

2010

200 ms 20, 10ms

6 20140212-

UAB-s1m1-

30s.cfg

16.368e6 4.092e6 Universidad

Autónoma de

Barcelona,

Barcelona,

Spain

12th

February

2014

200 ms 20, 10ms

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.


144

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.

145

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.


146

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

147

| 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,


148

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

149

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:


150

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)

151

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


152

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.

153

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.


154

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.

155

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


156

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).

157

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.


158

System Iridium Globalstar O3B

Nb. Sats aprox. 66 45 20

Orb. Heigth 780 km 1400 km 8000 km

Sat-to-User

Frequency

Band

L S Ka

Sat-to-User

carrier

frequencies

1616-1626.5 MHz 2483.5–2500 MHz 17.70 – 20.20 GHz

Access

Technique

FDMA, TDMA FDMA, CDMA FDMA, CDMA, TDMA

Signal

bandwidth (1-

sided)

10.5 MHz 1.23 MHz ≥ 150 MHz

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

159

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


160

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)

161

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:

𝑣𝑎𝑟(𝜏0̂) ≥

1

(𝐸𝑁02

)𝐹2̅̅̅̅

(5.9)

𝐹2̅̅̅̅ = ∫ (

𝑑𝑠(𝑡)

𝑑𝑡)2𝑑𝑡

T𝑠0

∫ 𝑠2(𝑡)𝑑𝑡T𝑠0

(5.10)

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


162

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:

163

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.


164

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

165

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.


166

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

167

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.


168

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.

169

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.


170

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⋮ ⋮−𝑒𝑚 1

) (5.18)

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

171

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


172

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.

173

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,


174

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:

175

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.


176

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 𝑓𝑠,𝑚 2

(5.24)

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

177

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


178

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.

179

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.


180

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],

ECEF [m]

Velocity at t0

[VX;VY;VZ],

ECEF [m/s]

Clock bias

at t0 [s/s]

Clock drift at t0 [s/s] Initial

Orbital

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

181

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

Masking Angle = 5º

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:


182

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

Masking Angle = 5º

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.

183

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º


184

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




.

185

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.


186

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

187

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


188

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.

189

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


190

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.

191

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.


192

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.

193

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].


194

[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.

LITERATURE LIST

195

[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.


196

[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.

LITERATURE LIST

197

[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.


198

[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

LITERATURE LIST

199

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


200

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.

LITERATURE LIST

201

[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:


202

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.

APPENDICES

Open Authentication Service – Summary of User Needs and High Level Appendix A.

Requirements Justification ............................................................................................. 204

NMA Bit-level Field Description ............................................................. 209 Appendix B.

Bandwidth Allocation Analysis for Different MAC and Key Sizes ......... 220 Appendix C.

Snapshot Authentication ........................................................................... 226 Appendix D.

Acronyms .................................................................................................. 237 Appendix E.

Published Papers ........................................................................................ 243 Appendix F.


204

Open Authentication Service – Summary of Appendix A.

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

205

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.


206

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).

207

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


208

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.

209

NMA Bit-level Field Description Appendix B.

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 2nd

subframe 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

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.

0 1 2 3

test-1 test-2 operational don't use


210

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

211

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

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.

NB value 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Number of

blocks3 4 5 6 7 8 9 10 11 12 rsvd rsvd rsvd rsvd rsvd rsvd

DSM length 304 408 512 616 720 824 928 1032 1136 1240 TBD TBD TBD TBD TBD TBD


212

Table 30 – Public Key Validity Period for several key pairs, assuming each key pair is valid for 5 years

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

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

213

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

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.

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


214

Hash Function (3 bits): It identifies the hash function used for the chain. It is interpreted

as follows:

Table 32 – Hash Function field

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:

Table 33 – MAC Function15

- specific implementations

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

15The 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.

0 1 2 3 4 5 6 7 8

SHA-256 SHA3-224 SHA3-256 rsvd rsvd rsvd rsvd rsvd rsvd

0 1 2 3

HMAC-SHA-256 CMAC-AES rsvd rsvd

215

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

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

field CID KS HF MF MS WN DOW Kroot total length

length 2 4 3 2 4 12 3 80-128 110-158


216

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].

217

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.


218

'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.

219

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.


220

Bandwidth Allocation Analysis for Different Appendix C.

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.

221

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

Table 37 - Authentication design parameters vs MAC/key lengths - 2 MAC-K sections / SF (i)

1- NB OF MACS PER MAC-K 2- NB OF MACS PER 30S 3- MAC-K SPARE BITS

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

MAC length MAC lengthMAC length

223

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


224

Table 39 - Authentication design parameters vs MAC/key lengths - 3 MAC-K sections / SF (i)

1- NB OF MACS PER MAC-K 2- NB OF MACS PER 30S 3- MAC-K SPARE BITS

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

MAC length MAC lengthMAC length

225

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

Snapshot Authentication Appendix D.

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.

227

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.


228

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

229

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 𝑡𝑚𝑒𝑎𝑠,


230

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.

231

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:


232

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.

𝑟𝑖 = 𝜌𝑖 − 𝑏𝑟𝑥,𝑟𝑒𝑓 − 휀𝑖

i=1,..,N. N≥ 3

(D.1)

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

233

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] = [−𝑒𝑖]

δX = (𝐻𝑇𝐻)−1𝐻𝑇δ𝜌

(D.4)

𝑋 = 𝑋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).


234

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 PFA. 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

235

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)

where �̂�𝒏+𝟏 is the estimated range from (0,0,0). 𝐹(𝑚𝑜𝑑𝑒𝑙, 𝑋0) provides that range

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).


236

|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.

237

Acronyms Appendix E.

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


238

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

239

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


240

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

241

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


242

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

243

Published Papers Appendix F.

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.".

snapshot and authentication techniques for … and authentication techniques for satellite...

Documents