document production · gala ref : date : gala-als-dd-014 12-04-2001 ephemeris, almanacs and...

GALA REF :DATE :

Gala-als-dd-01412-04-2001

EPHEMERIS, ALMANACS AND CORRECTIONS ISSUE : 3.1 PAGE: a

DOCUMENT PRODUCTIONYou are using a template created for the GALA data production:• Do not delete the Document Production and Document Distribution sections.• Do not modify its styles which are common to all project documents.• At each section, a short guideline is given to help you find the nature of information to fill

in. Those guidelines are given in “Italics” font and are to be deleted.• Some text are already included . They are presented in the “Normal” font style used in the

template. Keep those and complete with the information requested.• The Company Logo can be added in the footer part.

Before final edition of your document you need to update:• in the "Summary Folder" :

• Title• Author (Check it)• Comments (Document summary)

• in the " Custom Folder", the following properties :• Doc Approved By (Name)• Doc Classification (TBD)• Doc Company (TBD)• Doc Contract Number (TBD)• Doc Date Issue (Issue Date)• Doc Identification (Document Identification)• Doc Issue Number (Issue Number)• Doc Project Acronym (GALA)• Doc Project Name (GALILEO Overall Architecture

Definition)• Doc Status (- / Reviewed / Approved)• Doc Type (A / R / I)• Doc Verified By (Name)• Doc WBS Code (WBS Code)

To do so follow following instructions:• Double-click on the following button

Update Properties• Select the property• Modify it and click on the button Modify

• CTRL+A, F9 , F9 and answer to the questions.(If some are to be ignored, leave the default ones proposed.)

• Before printing, check that Table of Content has been properly updated and fill the field"Date" of Change record with current date.

GALA REF :DATE :

Gala-als-dd-01412-04-2001

EPHEMERIS, ALMANACS AND CORRECTIONS ISSUE : 3.1 PAGE: b

Hereafter the mandatory fields with a TBD value are listed in RED

Double-Click on the above button to initialise the Comments Field in the Summary Folder inthe Property Box

GALA REF :DATE :

Gala-als-dd-01412-04-2001

EPHEMERIS, ALMANACS AND CORRECTIONS ISSUE : 3.1 PAGE: A

DOCUMENT DISTRIBUTION

From : Romay M. - Mozo A. Schlueter S. - Kraemer R. Detoma E. - Leonardi M.Project Acronym : GALAProject Name : Galileo Overall Architecture DefinitionTitle : EPHEMERIS, ALMANACS AND CORRECTIONSIssue : 3.1Reference : Gala-als-dd-014Date : 12-04-2001Pages Number : 154File : dd14-v3.1(ephemeris, almanacs and corrections).docIssue : 3.1Classification : PUWBS : WPD 2.2.3Contract : GALA-1999-AM-004Emitting Entity : ALS / GMV / DLRType of Document : RStatus : -Template Name : gala_v1.dot

To :

Internal Distribution

Service Name N° Ex. Service Name N° Ex.

External Distribution

Company Name N° Ex. Company Name N° Ex.

GALA REF :DATE :

Gala-als-dd-01412-04-2001

EPHEMERIS, ALMANACS AND CORRECTIONS ISSUE : 3.1 PAGE: B

THIS PAGE IS INTENTIONALLY LEFT BLANK

GALA REF :DATE :

Gala-als-dd-01412-04-2001

EPHEMERIS, ALMANACS AND CORRECTIONS ISSUE : 3.1 PAGE: 3

Sustainable Mobility and IntermodalityPromoting Competitive and Sustainable Growth

Galileo Overall ArchitectureDefinition

EPHEMERIS, ALMANACS AND CORRECTIONS

Written by Responsibility - Company Date Signature

Romay M. - Mozo A.Schlueter S. - Kraemer R.Detoma E. - Leonardi M.

GMV / DLR / ALS

Verified by

J.P. Vincent WP 2.2 responsible – ASPI

Approved

N. Vincent WP 2 responsible - ASPI

Documentation Manager

WBS Code : WPD 2.2.3Emitting entity : ALS / GMV / DLR

GALA REF :DATE :

Gala-als-dd-01412-04-2001


CHANGE RECORDS

ISSUE DATE § : CHANGE RECORD AUTHOR

1 First issue. E. Detoma

1.1 01/03/00 PM2 Issue. Review of issue 1 taking into account thereceived comments.

Please note that the issue number of the delivereddocument was erroneously set to issue 2.

E. Detoma

1.2 28/04/00 MTR Issue. Review of the issue 1.1 (ex 2) to respect theconsistencies with other GALA documents.

M. Leonardi

2 15/06/00 PM3 Issue. Analysis and trade-off of various orbit models,almanac data sets and ephemeris data sets. Parametersdefinition, validity time and data flow for ionosphericcorrections, satellite clock, ephemeris, almanacs anddifferential corrections.

A. Mozo Garcia,S. Schlueter,R. Kraemer,M. Leonardi.

2.1 21/07/00 Previous issue review taking into account the receivedcomments. Improvement of Section 4 (more detailedanalysis on other ionospheric models) and Section 6(differential corrections).

S. Schlueter, M. Leonardi.

3 03/11/00 Final report. A. Mozo Garcia,A.B.Martin PeiròS. Schlueter,R. Kraemer,M. Leonardi.

3.1 12/04/01 Review of the Final Report according to the GASTcomments, considerations and suggestions received afterthe Gala Final Review.

A. Mozo Garcia,A.B.Martin PeiròS. Schlueter,R. Kraemer,M. Leonardi.

GALA REF :DATE :

Gala-als-dd-01412-04-2001


TABLE OF CONTENTS

1. INTRODUCTION ............................................................................................................. 11

1.1 SCOPE AND UNDERSTANDING OF THE STUDY...................................................111.2 STUDY RATIONALE..................................................................................................11

2 REFERENCES.................................................................................................................. 13

2.1 DEFINITIONS.............................................................................................................132.2 ACRONYMS................................................................................................................132.3 APPLICABLE DOCUMENTS.....................................................................................152.4 REFERENCE DOCUMENTS......................................................................................15

3 NAVIGATION MESSAGE DESIGN GUIDELINES ........................................................ 18

3.1 EXISTING SATELLITE NAVIGATION SYSTEMS...................................................183.2 THE CONCEPT OF ALMANAC AND SIGNAL ACQUISITION STRATEGY..........22

3.2.1 Current implementation in GPS (and Glonass)..................................................... 223.2.2 Possible alternatives to improve the navigation message ....................................... 24

3.2.2.1 Data to be transmitted..................................................................................... 243.2.2.2 Messages definition drivers ............................................................................. 263.2.2.3 Message definition........................................................................................... 273.2.2.4 Broadcasting strategy and requirements ......................................................... 27

4 IONOSPHERIC CORRECTIONS.................................................................................... 30

4.1 IONOSPHERIC DELAY AND CAUSES .....................................................................304.2 IONOSPHERIC DELAY MEASUREMENT (DUAL FREQUENCY TECHNIQUE) ..314.3 MODELS FOR IONOSPHERIC CORRECTIONS......................................................32

4.3.1 The Klobuchar model........................................................................................... 324.3.2 Other ionospheric models ..................................................................................... 35

4.3.2.1 Indices and Databases ..................................................................................... 354.3.2.2 Models ............................................................................................................ 35

4.4 APPLICATION OF IONOSPHERIC MODELS IN SATELLITE NAVIGATION......384.5 SUMMARY..................................................................................................................40

5 TIME CORRECTIONS .................................................................................................... 42

5.1 SATELLITE CLOCK CORRECTIONS WITHIN THE NAVIGATION MESSAGE..425.2 ADDITIONAL DATA TO ENSURE A POSSIBLE INTEROPERABILITY WITHOTHER NAVIGATION SYSTEMS......................................................................................49

5.2.1 GST steering to UTC ............................................................................................ 495.2.2 Interoperability and compatibility with GPS......................................................... 51

5.3 TIME CORRECTION PARAMETERS SUMMARY..................................................52

6 DIFFERENTIAL CORRECTIONS .................................................................................. 55

6.1 GENERAL DESCRIPTION.........................................................................................556.2 CONTINENTAL COVERAGE....................................................................................60

6.2.1 Fast and Slow corrections ..................................................................................... 626.2.2 Validity time and update rate ............................................................................... 62

6.3 LOCAL DIFFERENTIAL CORRECTIONS ...............................................................636.3.1 Local differential correction spatial validity.......................................................... 646.3.2 Validity time and update rate ............................................................................... 656.3.3 Local differential correction parameters ............................................................... 66

GALA REF :DATE :

Gala-als-dd-01412-04-2001


6.3.4 Broadcasting strategy ........................................................................................... 696.3.5 Local differential corrections within CAS-1 signal................................................ 69

6.3.5.1 Study case ....................................................................................................... 706.3.5.2 Number of local areas covered by a satellite .................................................... 716.3.5.3 Advantages of broadcasting local correction within CAS 1 signal ................... 716.3.5.4 Drawbacks of broadcasting local correction within CAS 1 signal.................... 71

6.4 LOCAL DIFFERENTIAL CORRECTION SUMMARY.............................................71

7 ORBIT MODELS, EPHEMERIS AND ALMANAC ANALYSIS...................................... 73

7.1 CONSIDERED SATELLITE CONSTELLATIONS....................................................747.2 ALMANACS................................................................................................................75

7.2.1 Analysis of GPS almanac performance using real data......................................... 757.2.2 Almanac improvement by reducing the number of parameters ............................ 77

7.2.2.1 Almanac Definition ......................................................................................... 777.2.2.2 Performance Assessment................................................................................. 78

7.3 EPHEMERIS ...............................................................................................................797.3.1 Assessment of accuracy strategy ........................................................................... 797.3.2 Analysis of existing navigation message models .................................................... 80

7.3.2.1 Model definition.............................................................................................. 807.3.2.1.1 GPS.............................................................................................................. 807.3.2.1.2 GLONASS................................................................................................... 82

7.3.2.2 Results of the Analysis .................................................................................... 837.3.3 Survey of other existing analytical propagators .................................................... 85

7.3.3.1 Stroboscopic Propagator................................................................................. 857.3.3.2 SPOT Model................................................................................................... 85

7.3.4 Investigation of new possibilities ........................................................................... 887.3.4.1 Evolution of the orbital Elements .................................................................... 887.3.4.2 Improvement of the GPS Model...................................................................... 90

7.3.4.2.1 RAAN Modifications ................................................................................... 907.3.4.2.2 Rotation Parameters .................................................................................... 907.3.4.2.3 Results of the Analysis ................................................................................. 91

7.3.4.3 Polynomial Approaches .................................................................................. 937.3.4.3.1 Polynomial Approach of the Orbital Elements. ........................................... 937.3.4.3.2 Lagrange Polynomials ................................................................................. 94

7.3.5 Application to the GEO satellites .......................................................................... 977.3.6 Implementation of a numerical orbit integrator...................................................100

7.3.6.1 Definition of the dynamic model.....................................................................1007.3.6.2 Processing capabilities considerations ............................................................102

7.3.7 Broadcasting of current satellite position.............................................................1037.3.7.1 Low-order Lagrange interpolation.................................................................1047.3.7.2 High order polynomials ..................................................................................104

7.4 ANALYSIS RESULTS ...............................................................................................105

8 BASELINE FOR THE STUDY ........................................................................................107

8.1 IONOSPHERIC CORRECTIONS.............................................................................1078.2 CLOCK PARAMETERS...........................................................................................1098.3 DIFFERENTIAL CORRECTIONS ...........................................................................1128.4 DATA RATE CONSIDERATIONS............................................................................1138.5 ALMANAC CODING................................................................................................1148.6 EPHEMERIS BROADCAST AND CODING.............................................................117

8.6.1 Ephemeris coding ................................................................................................1178.6.2 A possible alternative and broadcasting strategies...............................................118

GALA REF :DATE :

Gala-als-dd-01412-04-2001


8.7 PROPOSED NAVIGATION MESSAGE DATA FLOW............................................119

ANNEX A - RECALLS OF ORBITOGRAPHY AND SYNCHRONIZATION .......................123

INITIAL PROPOSED SCENARIOS...................................................................................123Scenario 1.........................................................................................................................123Scenario 2.........................................................................................................................123Scenario 3.........................................................................................................................123Scenario 4.........................................................................................................................123

SYSTEM CONFIGURATION.............................................................................................124MEO satellites ..................................................................................................................124GEO satellites...................................................................................................................124Measurement Technique ..................................................................................................124

INITIAL TRADE-OFFS FOR THE COMPARATIVE SYSTEM STUDY (CSS) ................125Trend analysis on the different parameters ......................................................................125Atomic clocks comparisons ...............................................................................................126Uploading functions ..........................................................................................................126Trend analysis for Age of Data performance versus different European atomic oscillators

126Uploading Ground Station Coverage ................................................................................127Uploading functions Summary..........................................................................................127Errors introduced by the ephemeris message ...................................................................128Synchronization functions ................................................................................................128

CSS TECHNICAL BASELINE ...........................................................................................129OPEN ISSUES.....................................................................................................................129

ANNEX B – MESSAGE STRUCTURES IN EXISTING SATELLITE NAVIGATIONSYSTEMS................................................................................................................................130

BASIC DESCRIPTION OF THE GPS NAVIGATION MESSAGE AND EPHEMERISDATA SET ..........................................................................................................................130

Basic structure ..................................................................................................................130TLM word ........................................................................................................................131Hand-Over Word..............................................................................................................131Sub-frame #1: satellite clock parameters and health data.................................................132Sub-frame #2 and #3: satellite ephemeris data..................................................................134Sub-frame #4 and #5: support (almanac) data..................................................................135

BASIC DESCRIPTION OF THE GLONASS NAVIGATION MESSAGE AND EPHEMERISDATA SET ..........................................................................................................................141

Basic structure ..................................................................................................................141Almanac data set ..............................................................................................................144Ephemeris data set ...........................................................................................................145Timing 146

BASIC DESCRIPTION OF THE EGNOS NAVIGATION MESSAGE AND EPHEMERISDATA SET ..........................................................................................................................146

Basic description of the EGNOS message .........................................................................146Ephemeris data set ...........................................................................................................147Wide-Area Augmentation data set....................................................................................149

Fast Corrections Message Types 2 - 5 ...........................................................................149Integrity Information Message Type 6..........................................................................150Fast Correction Degradation Factor - Message Type 7 .................................................151Long Term Satellite Error Corrections Message Type 25 .............................................152Ionospheric Delay Corrections Messages Type 26.........................................................155

Almanac data set ..............................................................................................................157

GALA REF :DATE :

Gala-als-dd-01412-04-2001


GALA REF :DATE :

Gala-als-dd-01412-04-2001


LIST OF FIGURES

Figure 4-1. The ionospheric propagation error (m) by the Klobuchar model for 01.07.1999 computed for 12:00LT at every map point......................................................................................................................................34

Figure 4-2. Model Profiles used in BENT. .........................................................................................................................37Figure 4-3. The ionospheric propagation delay mapped at the ECAC grid in the EGNOS System Test Bed

(ESTB) based on data of 8 monitor stations in Europe at 01/07/1999...................................................39Figure 5-1. Clock errors of different clock types ..............................................................................................................44Figure 5-2. Physical steering update time of different clock types ................................................................................46Figure 6-1. Differential corrections geometry (redraw from [RD 7])...........................................................................57Figure 7-1. Error tree for a general satellite-based navigation system........................................................................73Figure 7-2. IGS Orbits accuracy..........................................................................................................................................75Figure 7-3. GPS Almanac Accuracy (1 and 4 days).........................................................................................................76Figure 7-4. Evolution of Almanac Accuracy (4 days, SV 14) .........................................................................................77Figure 7-5. Simplified Almanac Accuracy (1 and 4 days) ...............................................................................................79Figure 7-6. Estimation process flow chart .........................................................................................................................80Figure 7-7. GPS and GLONASS Message Accuracy........................................................................................................83Figure 7-8. Degradation of GPS and GLONASS Message Accuracy along Time ......................................................84Figure 7-9. Degradation of GPS and GLONASS Message Accuracy along Time ......................................................84Figure 7-10. RSS of the Position Error for several analytical models. METOP analysis .........................................86Figure 7-11. SPOT Message Accuracy in Meters .............................................................................................................87Figure 7-12. Evolution of the Semi-Major Axis .................................................................................................................88Figure 7-13. Evolution of the Inclination ...........................................................................................................................88Figure 7-14. Evolution of the RAAN....................................................................................................................................89Figure 7-15. Evolutions of Argument of Perigee and Mean Anomaly...........................................................................89Figure 7-16. Evolution of the Argument of Latitude.........................................................................................................89Figure 7-17. Evolution of the Eccentricity .........................................................................................................................90Figure 7-18. GPS-Type Message Accuracy........................................................................................................................91Figure 7-19. GPS-Type Message Accuracy........................................................................................................................92Figure 7-20. GPS-type Message Accuracy Degradation along Time ............................................................................93Figure 7-21. Evolution of the Semi-Major Axis in Three Hours.....................................................................................93Figure 7-22. Evolutions of the RAAN and the Inclination during 3 Hour-Time ..........................................................94Figure 7-23. Lagrange Polynomial Interpolation Accuracy ...........................................................................................95Figure 7-24. Lagrange Polynomial Interpolation Accuracy ...........................................................................................96Figure 7-25. Degradation of Lagrange Polynomial Interpolation along Time ...........................................................96Figure 7-26. GPS-type Message Accuracy (GEO case)...................................................................................................97Figure 7-27. GPS -type Message Accuracy Degradation along Time (GEO case).....................................................98Figure 7-28. Lagrange Polynomial Interpolation Accuracy (GEO case).....................................................................99Figure 7-29. Degradation of Lagrange Polynomial Interpolation along Time (GEO case) ...................................100Figure 7-30. Orbit accuracy for several dynamic models .............................................................................................101Figure 7-31. Orbit propagation accuracy for several number of harmonics in Earth’s gravity field...................101Figure 7-32. Effect of the Cr mismodelling in propagation accuracy.........................................................................102Figure 7-33. 2nd order Lagrange Polynomial Interpolation Accuracy......................................................................104Figure B-1. Super-frame structure.....................................................................................................................................142Figure B-2. Frame structure: frames 1-4..........................................................................................................................143Figure B-3. Frame structure: frame 5 ...............................................................................................................................143Figure B-4. Ionospheric grid points ..................................................................................................................................155

GALA REF :DATE :

Gala-als-dd-01412-04-2001


LIST OF TABLES

Table 3-1. Major perturbations to a MEO Keplerian orbit.............................................................................................18Table 3-2. Ephemeris Representation Candidates versus Selection Criteria...............................................................21Table 3-3. Memory and Duty-cycle Requirements for Ephemeris Algorithm Implementation. ................................22Table 3-4. Broadcasting requirements for GPS and Glonass navigation data............................................................29Table 4-1. World-wide IGP distribution and spacing ......................................................................................................38Table 4-2. IGP Mask Message Format for Message Type 18 in EGNOS .....................................................................38Table 4-3. Ionospheric Delay Model Parameters for Message Type 26 in EGNOS ...................................................39Table 5-1. Assumed typical frequency ageing values for the different clock types .....................................................45Table 5-2 Physical steering update time of different clock types ...................................................................................46Table 5-3 Galileo clock correction parameters.................................................................................................................48Table 5-4. Galileo almanac clock correction parameters ...............................................................................................49Table 5-5. Galileo clock parameters summary ..................................................................................................................53Table 6-1. A possible navigation error budget (single frequency) without any correction. ......................................60Table 6-2. Residual UERE budget (spatial degradation)................................................................................................60Table 6-3. UERE error budget (user close to reference).................................................................................................63Table 7-1. GPS Almanac Accuracy (1 day)........................................................................................................................76Table 7-2. Simplified Almanac Accuracy (1 day)..............................................................................................................78Table 7-3. GPS message parameters ...................................................................................................................................81Table 7-4. Summary of equation used in the GPS ephemeris model..............................................................................81Table 7-5. GLONASS message parameters ........................................................................................................................82Table 7-6. SPOT Message Accuracy in Meters..................................................................................................................87Table 7-7. SPOT Message Accuracy in Meters (P9, P10 and P11 not estimated)......................................................87Table 7-8. GPS-Type Message Accuracy in Meters..........................................................................................................92Table 7-9. Lagrange Polynomial Interpolation Accuracy in Meters.............................................................................95Table 7-10. Parameters required for GPS and Lagrange interpolation messages .....................................................97Table 7-11. GPS-type Message Accuracy in Meters (GEO case)...................................................................................98Table 7-12. Lagrange Polynomial Message Accuracy in Meters (GEO case).............................................................99Table 7-13. 2nd order Lagrange Polynomial Interpolation Accuracy..........................................................................104Table 8-1. Ionospheric correction parameters for the considered options.................................................................108Table 8-2. Galileo clock correction parameters for ephemeris message: Rb clocks................................................110Table 8-3. Local differential corrections parameters.....................................................................................................113Table 8-4. Almanacs in the case of GPS, Glonass and Galileo systems for a 24-satellite constellation ..............116Table 8-5. Ephemeris data in the case of GPS, Glonass and Galileo systems...........................................................118Table 8-6. Galileo navigation data: broadcasting requirements (30 MEOs case)....................................................121Table 8-7. The navigation message with respect to different service levels ...............................................................121Table 8-8. Galileo navigation data: options....................................................................................................................122Table 8-9. Galileo navigation data: no almanac broadcasting case...........................................................................122Table 8-10. Navigation message options versus different scenarios...........................................................................122

GALA REF :DATE :

Gala-als-dd-01412-04-2001


1. INTRODUCTION

1.1 SCOPE AND UNDERSTANDING OF THE STUDY

AleniaSpazio, GMV and DLR have been tasked to analyse the possible solutions and achieve alogic trade-off concerning some specific data-sets within the Galileo navigation message,including the almanac and the differential corrections. This activity will be carried on in theframework of the W.P. 2.2.3 within the GALA program, aimed to define the general requirementsand the overall architecture of the future European satellite navigation system.

Implicitly, the definition of the navigation message implies an extension of the study involving thestructure of the algorithm for orbit propagation in the user receiver and the form of the correctionsto be applied to account for the major perturbation terms.

The format of the differential corrections and the definition of the navigation information such as:ü format of the corrections to the orbit predictor,ü data coding (scaling and truncation);ü ionospheric and clock corrections,ü acquisition (almanac, time-to-first fix) andü timing issues (interoperability with other systems)

will have a major impact on the structure of the signal and slightly affect the overall systemarchitecture.

1.2 STUDY RATIONALE

In the past, the same problem has been faced by two previously deployed satellite navigationsystems, GPS and Glonass (omitting the Transit NNSS, because of the different requirements andoperation). Both systems went through analysis and tradeoffs of possible solutions, so it seemsjustifiable to start the study by making a survey of the tradeoffs and solutions implemented bythese previous systems.

Four main points are to be tackled in this study:

1. the analysis of the impact on the overall accuracy of the scaling and truncation on theephemeris and clock parameters transmitted in the navigation message once the form of theseparameters has been defined;

2. the analysis and impact on the overall accuracy and degradation with time of the form ofthe corrective terms required to account for the gravitational field perturbations to theKeplerian orbit (for GPS, these are represented by the 6 sine and cosine terms in the ICD-200/C GPS navigation message);

3. the overall architecture of the navigation message, broadcast by each satellite andcomposed of two parts:

ü the first, called the almanac, providing coarse ephemeris for the full constellation andallowing the user to know which satellites are in view, their status and the visibilityconditions;

GALA REF :DATE :

Gala-als-dd-01412-04-2001


ü the second, the space vehicle precise ephemeris and clock correction terms set, whichallows the user to propagate at the time of the pseudorange measurement the preciseposition of the space vehicle.

4. the analysis and impact on accuracy augmentation by transmitting differential correctionsto be applied to pseudoranges (the preferred method) instead that to the correction in latitude,longitude, height and time.

The evaluation of the possibility not to broadcast the almanac has been specifically requested inorder to reduce the Time To First Fix (TTFF) for a receiver in the cold-start mode. Possiblealternate solutions must be evaluated against parameters such as availability, reliability androbustness of the information transmitted to the users and the means of transmission.

In addition, the study will address the verification of the GPS ionospheric correction model andapplicability at the accuracy required by the Galileo system. This is not an issue, and the GPSmodel has been specifically requested in the ESA Invitation To Tender (ITT). However, werecommend that it is performed as an option, taking into account that, in order to achieve the fullsystem accuracy, two-frequencies receivers must be used and the ionosphere contribution may bemeasured and not modelled. Nevertheless, it will provide an upper bound to the OAS service.

GALA REF :DATE :

Gala-als-dd-01412-04-2001


2 REFERENCES

2.1 DEFINITIONS

No definition

2.2 ACRONYMS

AFB Air Force BaseAoD Age of DataAS Anti-Spoofingbps bit per secondBIPM Bureau International des Poids et MesuresBPSK Bi-Phase Shift KeyingC/A Clear/Acquisition (code, GPS)CAS Controlled Access Service (GalileoSat)CCDS Consultative Committee for the Definition of the SecondCCIR Comité Consultative International des RadiocommunicationsCCTF Consultative Committee for Time and FrequencyCME Coronal Mass Ejection’sCPU Central Processing UnitCs CaesiumCs-AFS Caesium Atomic Frequency StandardCSS Comparative System StudyDN Day NumberDS Direct SequenceDGPS Differential GPS (mode)EGNOS European Geo-stationary Navigation Overlay ServiceERP Earth Rotation ParametersESA European Space AgencyESOC European Space Operations CentreESTEC European Space research and Technology CentreGEO Geo-synchronous Earth OrbitGIVD Grid Ionospheric Vertical DelayGIVE Grid Ionospheric Vertical ErrorGLONASS Global Navigation Satellite System (Russian Federation)GNSS Global Navigation Satellite SystemGPS Global Positioning SystemGST Galileo System TimeH HydrogenHMa-AFS Hydrogen Maser- Atomic Frequency StandardHOW Hand-Over WordICD Interface Control DocumentIGS International GPS Geodynamics ServiceIGSO Inclined Geo-Synchronous OrbitIOD Issue Of DataIODC Issue Of Data, Clock

GALA REF :DATE :

Gala-als-dd-01412-04-2001


IODE Issue Of Data, EphemerisIPE Ionospheric Propagation ErrorIPP Ionopheric Piercing PointIRI International Reference IonosphereISR Incoherent Scatter RadarITT Invitation To TenderJGM Joint Gravity ModelJPL Jet Propulsion LaboratoryJSC Johnson Space Center (NASA)LAN Longitude of Ascending NodeLEO Low Earth OrbitLSB Least Significant BitMASER Microwave Amplification by Stimulated Emission of Radiation (also referred to

as "maser", used here in the oscillator implementation)MCS Master Control StationMEO Medium Earth OrbitNASA National Aeronautics and Space AdministrationNNSS Navy Navigation Satellite System (Transit)OAS Open Access ServiceOCS Operational Control StationOCXO Oven Controlled crystal OscillatorOD Orbit DeterminationOD&TS Orbit Determination and Time Synchronisationpps pulse per secondPPS Precise Positioning Service (GPS)PRN Pseudo-Random NoiseQPSK Quadri-Phase Shift KeyingRAAN Right Ascension of the Ascending NodeRAFS Rb Atomic Frequency StandardRb RubidiumRMS Root Mean Squares/c SpacecraftSA Selective AvailabilitySCs-AFS Space-qualified Caesium - Atomic Frequency StandardSHMa-AFS Space-qualified Hydrogen Maser- Atomic Frequency StandardSIS Signal-In-SpaceSNF Satellite Navigation FrameSPS Standard Positioning Service (GPS)SS Spread-SpectrumSSN Solar Sunspot NumberS-VCXO Space-qualified Voltage Controlled crystal OscillatorTAI International Atomic TimeTBC To Be ConfirmedTBD To Be DefinedTBW To Be WrittenTEC Total Electron ContentTID Travelling Ionospheric DisturbanceTLM TelemetryTS Time SynchronisationTTFF Time-To-First-FixUDRE User Differential Range ErrorUERE User Estimated Range Error

GALA REF :DATE :

Gala-als-dd-01412-04-2001


UIVE User Ionospheric Vertical ErrorURA User Range AccuracyURE User Range ErrorUT Universal TimeUTC Universal Time CoordinatedWAAS Wide Area Augmentation SystemWN Week Number

2.3 APPLICABLE DOCUMENTS

No applicable documents

2.4 REFERENCE DOCUMENTS

RD 1: A.J. Van Dierendonck, S.S. Russell, E.R. Kopitze, M. Birnbaum, “GPS NavigationMessage”, in Global Positioning System, vol. I, pp. 55-73 (Institute of Navigation, 1980)

RD 2: Y. Kozay, “The Motion of a Close Earth Satellite”, The Astronomical Journal, 64, pp.367-377 (1959)

RD 3: F.R. Hoots, “A Short, Efficient Analytical Satellite Theory”, Journal of Guidance,Control and Dynamics, vol. 5, #2, pp.194-199 (1982)

RD 4: M.H. Lane, F.R. Hoots, “General Perturbations Theories Derived from the 1965 LaneDrag Theory”, Aerospace Defense Command, Peterson AFB, Colorado, Project Space-Track, Report no. 2 (1979)

RD 5: “Almanac for Computers”, Nautical Almanac Office, United States Observatory(published in the years 1984 – 1987, then discontinued).

RD 6: Arinc Research Corp., “Navstar GPS Space Segment / Navigation User Interfaces”, ICD-200, Rev. C – 002 (September 25, 1997)

RD 7: J. Beser, B.W. Parkinson, “The Application of NAVSTAR Differential GPS in theCivilian Community”, in Global Positioning System, vol. II, pp. 167-196 (Institute ofNavigation, 1984)

RD 8: "Orbit Determination and Time Synchronisation trade-offs: Final Report" Technical Note3.3.2, Issue2, Rev B (30 November 1999), ESA contract n0 3217/98/NL/DS

RD 9: Hahn J., Tavella P.: "A Time Scale for Satellite Navigation Systems: Why and How?",Special Edition on Satellite Navigation and Positioning of the International Journal ofSatellite Communications (IJSC), to be published

RD 10: ITU-T, Telecommunication standardisation section of ITU, InternationalTelecommunication Union, "Definition and terminology of synchronisation networks"(1996).

RD 11: "ISO-8601: Data elements and interchange formats - information interchange -Representation of dates and times", International Organisation for Standardisation (1988).

GALA REF :DATE :

Gala-als-dd-01412-04-2001


RD 12: NATO-STANAG 4430, "Precise Time and Frequency Standards (PTFS) for militaryelectronic systems", draft edition (1992).

RD 13: Comptes rendus des séances de la quinzième Conférence Générale des Poids et Mesures,Paris (1975).

RD 14: Hoffmann-Wellenhof B. , Lichtenegger H., and Collins J., “GPS Theory and Practice”,Springer Verlag Wien (1992)

RD 15: Bauer M., “Vermessung und Ortung mit Satelliten”, Wichman (1997)

RD 16: Kunches J.M. ,“Now It Gets Interesting: GPS and the Onset of Solar Cycle 23“,Proceedings of ION GPS (Sep. 1997)

RD 17: Sardón E., Rius A., Zarraoa N., ”Estimation of the transmitter and receiver differentialbiases and the ionospheric total electron content from Global Positioning Systemobservations”, Radio Science, Vol.:29(3), 577-586 (May-June 1994)

RD 18: Chiu Y., T., “A Phenomenological Model of Global Ionospheric electron density in theE-, F1- and F2 Regions“, J. Atmos. Terr. Phys. 35, 1615 (1973)

RD 19: Bent R., B., et al., “Ionospheric Refraction Corrections in satellite Tracking“, SpaceResearch XII, 1186-1194, Akademic-Verlag, Berlin (1972)

RD 20: El-Arini, M.,B., Wisser, T. C., et al, ”The FAA Wide Area Differential GPS(WDGPS)Static Ionospheric Experiment”, Proc. Of the ION Tech. Meeting, San Diego, CA, Jan.1994

RD 21: A.Mozo Garcia, M. M. Romay Merino, “Almanac, Ephemeris and Corrections”, GMV-GALA-TN-2.2.3 (January 2000)

RD 22: T.A. Morley, “A SPOT Orbit model on board ARTEMIS and SPOT-4”, OAD Workingpaper no. 444 (July 1991)

RD 23: Technical Note, “Signal Design and Transmission Performance Study for GNSS2”

RD 24: “Technical Characteristics of the NAVSTAR GPS”, Public release of the NATOdeveloped by the NAVSTAR GPS Technical Support Group under the direction of theNATO NAVSTAR GPS Project Steering Committee, June 1991.

RD 25: Jones, W.B. and Gallet, R.M., “The representation of Diurnal and Geographic Variationsof Ionospheric data by Numerical methods”, Telecomm. J. 29,129,1962, and 32,18,1965.

RD 26: Rush, C.M. et al, “Improving Ionospheric Maps Using Theoretically Derived Values offoF2”, Radio Sci. 19,1083,1984.

RD 27: J.R.Martín, M.Toledo, “WP 5240 Report 1 Message Definition”, GNSSIG Study, GMV(6/07/98)

RD 28 A.Belén Martìn Peirò et al., "Galileo In-Orbit Control Strategy" in proc. of the IAIN-IONGPS 2000

GALA REF :DATE :

Gala-als-dd-01412-04-2001


Other referencesD. Brouwer, “Solution of the Problem of Artificial Satellite Theory Without Drag”, TheAstronomical Journal, 64, pp. 378-397 (1959)

J.P. Vinti, “New Method of Solution for Unretarded Satellite Orbits”, Journal of the NationalBureau of Standards, 62B, pp. 105-116 (1959)

W.M. Lear, “Planetary and Orbital Elements, 1980-2016”, NASA JSC Technical Report JSC-23457 (April 1989)

Para. 6.1.15, “Navigation Data Message Content”, in ESA/ESTEC, “Attachment A to Statement ofWork “GalileoSat Definition Study” – GalileoSat System Specification SP-10-0-1, ref.NS/0001335, Draft 01 (16 August 1999)

“Global Positioning System, Standard Positioning Service: Signal Specification”, NAVCEN, 2nd

edition (June 2, 1995)

"Global Satellite Navigation System GLONASS: Interface Control Document", RTCA paper No.639-95/SC159-685, GNSSP/2-WP/66 (November 14, 1995)

R.M. Kalafus, J. Vilcans, N. Knable, “Differential Operation of NAVSTAR GPS”, in GlobalPositioning System, vol. II, pp. 197-214 (Institute of Navigation, 1984)

Jakowski N.,Jungstand A., „Modelling the regional ionosphere by using GPS observations“,Proceedings of the International Beacon Satellite Symposium, Aberystwyth, U.K. (11.-15. July1994)

Sardón E., Jakowski N., Schlüter S., “Comparisons between IRI TEC predictions and the TECobtained from GPS data, Proceeding of the COST/IRI Workshop, Kühlungsborn, Germany (27-30May 1997)

GALA REF :DATE :

Gala-als-dd-01412-04-2001


3 NAVIGATION MESSAGE DESIGN GUIDELINES

3.1 EXISTING SATELLITE NAVIGATION SYSTEMS

In the design of the GPS navigation message, constraints, based on operational and system-levelrequirements, were placed upon the message structure before the content of the navigation messagewas defined:

Ø data rate: 50 bps(1)

Ø data frame length (600, 900, 1200, 1500 or 1800 bit)(2)

Ø each data frame shall contain HOW and TLMØ HOW spaced 6 s apart(3)

Ø SV memory ≈ 100 kbit

Therefore, the contents were tailored to the structure, with only minor modifications applied in theprocess to the HOW and TLM words from the original requirement.

The external forces that constitute the major perturbations to a MEO Keplerian orbit can be listed asfollows (Table 3-1), together with the order of magnitude of their effects, if unaccounted, on the orbitpropagation [RD 1]:

Table 3-1. Major perturbations to a MEO Keplerian orbit.

Earth mass attraction (4) GM -

Second zonal harmonic J2 300 m/hr

Lunar gravity 40 m/hr

Solar gravity 20 m/hr

4th zonal harmonic 0.6 m/hr

Solar radiation pressure 0.6 m/hr

Gravity anomalies 0.06 m/hr

Other forces 0.06 m/hr

Clearly, it will be difficult to achieve the required accuracy with a general perturbationsanalytical model, which will become too complex to be handled in a user receiver. Therefore,some form of correction to the basic Keplerian orbit propagator should be devised in terms ofinterpolating the changes in some orbital elements instead than deriving them analytically.It is also clear that the selection of the orbit propagator affects and implicitly defines the format of theephemeris data(5) in the navigation message. In the past, the orbit propagation by numerical integration

(1) To keep high the anti-jamming processing gain.(2) 1500 bit was selected.(3) To provide system time, consistent with the DoD requirement to maintain a synchronisation toUTC.(4) This is the force determining the Keplerian orbit, and therefore its contribution to the orbitdegradation is zero.

GALA REF :DATE :

Gala-als-dd-01412-04-2001


was ruled out in the user receiver because of the complexity and intensive computations required. Thesituation is not changed nowadays if the cost of the receiver must be kept low and some kind ofcompatibility is to be maintained with the present GPS/Glonass equipment.

Classical analytical theories (based on the work of Kozai [RD 2] and evolved up to the SGP-x series[RD 3], [RD 4]) are complex to implement. Moreover, they require lengthy calculations and, if usedstand-alone, they are not enough accurate with respect to the elapsed time since the epoch of issue ofthe element set. This has led with time to the development of the so-called semi-analytical theories.

The solution for GPS has been to use a truncated analytical theory with added correction terms, thelatter resulting from interpolation on the interval of validity of the data, for increased accuracy. Theephemeris representation trade-off has been based [RD 1] on the following parameters and constraints:

1. Users time-to-first-fix (TTFF) A short TTFF is clearly desirable – the data rate and number of framesfor the navigation data will have the major impact on this parameter.

2. User computational time This is a function of the complexity of the algorithm to be used for orbitpropagation; this rules out numerical integration and generalperturbations analytical theories.

3. User storage requirements The number of sub-frames to be stored and the code size will impactthis constraints, which is less of a problem today than 30 years ago!

4. Refresh rate It is a function of the validity of data versus elapsed time, which in turnis a function of the interpolation selected for the corrections - impactsthe memory requirement in the Space Vehicle, which, again, is less of aproblem today than 30 years ago!

5. Overlap in Time of Applicability Impacts the refresh rate.

6. Accuracy This is the major requirement to consider in the study, since it willdepend upon the ephemeris format and the rate of change of theephemeris.

7. Orbital tolerance Once a correction strategy has been selected for the nominal orbit, thedegradation for non-nominal orbits (slightly offset) must be estimatedas it has an impact on the overall system operations and constellationmaintenance.

8. Degradation Obviously, for the ephemeris format chosen, a graceful degradationwith age-of-data is a highly desirable feature.

9. Clock/relativity compensation The same applies to the clock correction terms and the possibility tocorrect for relativistic effects due to orbital eccentricity. Again,graceful degradation with age-of-data is desirable.

10. Time for user to receive almanac This trade-off impacts mainly the TTFF and has a secondary impact onthe user equipment storage requirements.

11. Clarity of representation This constraint impacts the mathematical formulation of the orbitpropagator as well as the coding of the algorithms; clarity ofrepresentation clearly facilitates debugging for the receivermanufacturers.

(5) Some other modified Keplerian set can be implemented, for instance an augmented set (with

derivatives), such as in the Two-Line Element set (NORAD/NASA format, for use with SGP-xtheories). But again, if used stand-alone, without corrections, this suffers from the accuracy versuscomplexity problem which is peculiar to all the analytical theories.

GALA REF :DATE :

Gala-als-dd-01412-04-2001


The impact of the above listed constraints and parameters on the selection of the corrections model tothe orbit perturbations and the orbit propagation algorithm are listed in Table 3-2 and Table 3-3 (from[RD 1], modified). Some constraints are changed with time, since speed and storage requirements areless of a problem now than in the ‘70s, both onboard the SVs and for the user equipment.Nevertheless, the tables present a previous attempt to optimize the solution, which may be re-evaluated now, in terms of the technology available today.

For instance, an additional solution to the ephemeris representation (perturbations) could involve aseries expansion with Chebyshev polynomials (widely used in astronomy, see, for instance, [RD 5]).However, like the polynomial interpolation, this may not provide for the graceful degradation outsidethe fitted time interval.

GALA REF :DATE :

Gala-als-dd-01412-04-2001


Table 3-2. Ephemeris Representation Candidates versus Selection Criteria.

(from: Van Dierendonck et al., “GPS Navigation Message”, in Global Positioning System, vol. I, Institute of Navigation [1980])

Parameter Polynomials Harmonic Expansion Keplerian with Polynomials Keplerian with Harmonics

No. of subframes 3+ 2+ 2+ 2-

User computation time short, simple sines, cosines sines, cosines sines, cosines

User storage requirements 3+ subframessmall algorithmneed almanac

2+ subframesmedium algorithmsame as almanac

2+ subframeslarge algorithm

same as almanac

2 subframeslarge algorithm

same as almanac

Refresh rate once per hour once per hour once per hour once per hour or longer

Refresh overlap ½ hr ½ hr ½ hr ½ hr or longer

Accuracy < 30 cm Probably enough < 30 cm < 30 cm

Effects on orbital tolerance Not clear Not clear Handles any orbit Handles any orbit

Degradation Abrupt Unknown Marginal Graceful

Clock/relativity compensation Not compatible Not compatible Compatible Compatible

Almanac subframe Not compatible 1+ 1- 1-

Clarity Not clear Not clear Orbit – clear Perturbations – not clear Clear

GALA REF :DATE :

Gala-als-dd-01412-04-2001


Table 3-3. Memory and Duty-cycle Requirements for Ephemeris AlgorithmImplementation.(from: Van Dierendonck et al., “GPS Navigation Message”, in Global Positioning System, vol. I,Institute of Navigation [1980])

Algorithm Relative order ofimportance

Memory required for fourspace vehicles (relative %)

Cycle time percall (relative %)

Modified Lagrange solutionof the equation of the center

AccuracyClaritySpeed

Memory1 0.4

Modified Lagrange solutionof the equation of the center(coded for speed)

AccuracySpeed

MemoryClarity

0.7 0.2

Classic successive substitutionsto solve Kepler’s equation

AccuracyMemorySpeedClarity

0.5 0.7

Stephenson’s successivesubstitutions method to solveKepler’s equation(proves inferior to the classicmethod in this application)

AccuracySpeed

MemoryClarity

0.6 0.8

Classic Newton-Raphsonmethod to solve Kepler’sequation

AccuracyClaritySpeed

Memory0.7 1

Modified Newton-Raphsonmethod to solve Kepler’sequation (different coding)

AccuracyClarity

MemorySpeed

0.8 0.7

Modified Newton-Raphsonmethod to solve Kepler’sequation (different coding)

AccuracyMemorySpeedClarity

0.6 0.4

Note: the last two columns provide only a relative order of magnitude, since storage requirementsand speed are a function of the processor being used.

3.2 THE CONCEPT OF ALMANAC AND SIGNAL ACQUISITIONSTRATEGY

3.2.1 Current implementation in GPS (and Glonass)The almanac was originally intended as an aid in acquiring the satellites when a receiver isswitched on the first time. This set of data is used to predict satellite visibility and estimatethe pseudorange to a satellite, thereby narrowing the search window for a ranging code. Asky-search for a usable signal, scanning all possible PRN codes is performed. When onesatellite is locked and the Costas-loop tracks the incoming PRN stream, the data can be

GALA REF :DATE :

Gala-als-dd-01412-04-2001


decoded. Since each satellite transmits the coarse position of all the satellites in theconstellation (the almanac is valid for long time periods up to 180 days), one satellite isenough to assess(6) the visible satellites and restrict the signal search that follows to thesatellites of interest.

This process took some time, because of the structure of the almanac in the GPS message(7),but it was deemed a viable solution to render acceptable the Time-To-First-Fix (TTFF) at atime in which multi-channel receivers where expensive. However, with the progress oftechnology, multi-channel receivers based on multiple parallel correlators, have becomeviable and widespread, and the TTFF was considerably reduced by simultaneous trackingmore than one satellite and downloading the almanac from different satellites.

The TTFF is a measure of the elapsed time required for a receiver to acquire the satellitesignals and navigation data and calculate the first position solution. TTFF begins wheninitialisation of the receiver is complete (including self-test, loading of PPS keys and anyrequired operator input) and the receiver is commanded to begin the positioning function. Incase of GPS it is possible to refer to TTFF1 and TTFF2. The TTFF1 is based on C/A codeacquisition. TTFF2 is based on direct P-code acquisition. The reaction time (REAC) is theterm typically used to include both the initialisation process and the TTFF.TTFF is a function of the initial receiver state as well as receiver design. Three differentvariations of the TTFF are commonly defined and any one (or all three) can be specified for aparticular receiver:

• cold start,• warm (or normal) start,• hot start.

A warm (or normal) start is based on the assumption that the receiver already has anestimate of current time and position as well as a recent copy of the satellite almanac data.Typically, time should be knows within 20 seconds of the System Time, position should beknown within 100 kilometres, velocity within 25 meters per seconds and satellite almanacshould have been collected within the past few week (typically 2 weeks).

A cold start occurs whenever there is a problem with these key data elements. This is thetypical situation of a receiver as delivered from a manufacturer or when the supply batteriesare removed. The receiver need to systematically scan the incoming messages until it can finda satellite and retrieve time and a current almanac.

A hot start occurs when a receiver is provided with a standby feature to maintain oscillatortemperature, time, position and individual satellite ephemeris (as well as the almanac). Whenthe receiver is commanded out of the standby mode, the time required to achieve the next fullposition fix is usually named Time To Subsequent Fix (TTSF) rather than TTFF. Typically,TTSF is on the order of 10 s for standby periods of a few hours.

(6) This is to be taken in a general sense, since, because of the difference in upload times for

the almanac and the ephemeris data set, there may be a possible discrepancy between thehealth status as provided in the almanac and the current health status of the satellites.Attempts to track unhealthy SVs that are marked healthy in the almanac is a result of thisimplementation strategy.

(7) Glonass is faster, since in a single super-frame, 2.5m, the full almanac is transmitted, whileGPS must switch several pages in sub-frames 4 and 5 to recover the full almanac.

GALA REF :DATE :

Gala-als-dd-01412-04-2001


For military applications the GPS User Equipment Requirements include the capability, forP(Y)-sets, to acquire the P(Y) code at TTFF using almanac-only information(8). Therefore, thealmanac degradation in time for GPS must be weighted against this requirement, and theusable accuracy at the end of validity period kept to a reasonable level. This is expressed bythe following table (GPS almanac updated within the last six-days):

Operational Interval Almanac Ephemeris URE(9), 1-σ [m]

Normal 900

Short-term Extended 900 ÷3600

Long-term Extended(10) 3600 ÷ 300000

URE values tend to degrade quadratically with time. Large errors follow an eclipse period orafter manoeuvres.

For a detailed description of the almanac structure and data content on GPS, Glonass andEGNOS systems, the reader may refer to annex B of this document.

Concerning the GPS ephemeris data, note that unlike almanac, which can be obtained for thewhole constellation from a single satellite, the ephemeris must be collected from eachsatellite being tracked on acquisition and at least one every hour. GPS Ephemeris informationis normally valid for 4 hours from the time of transmission. Depending on the navigationmessage collection scheme employed in a particular receiver, it can take between 30 s and 3minutes to collect the ephemeris information.

3.2.2 Possible alternatives to improve the navigation messageThe main data-sets and driver factors composing a navigation message are presentedhereafter. A detailed analysis on this subject was also performed and documented in [RD 23].In addition, some ideas on further options to be analysed will be outlined.

3.2.2.1 Data to be transmittedThe main data-sets composing a navigation message are:

1. Ephemeris data: Set of data which give the satellite location at a specificreference time and which are used to predict location at any time. The requiredprecision is constrained by the desired position accuracy. Several options can beaddressed:

• Broadcast of parameters of models describing motion, for exampleKeplerian orbital elements plus perturbation coefficients (as it is done inGPS).

• Broadcast accurate state vector of satellite at reference time(GLONASS), the interval of validity being determined by the complexityof the user propagator.

(8) Normal Operations only. Short-term and Long-term Extended Operations (that make use of

the Autonav capability starting from the block IIR satellites) may not support this UserEquipment requirement. The same consideration for Extended Operations apply to theaccuracy of the UTC parameters.

(9) Estimated by analysis.(10) Up to 180 days (300 km, 1-σ).

GALA REF :DATE :

Gala-als-dd-01412-04-2001


• Simplified version of previous option; user implements a simplepropagator and state vector data are frequently updated to compensatefor the lack of propagation accuracy.

• Broadcast coefficients of polynomial expression interpolation the satelliteposition.

First option is robust and accurate, allowing degraded status as precisiondecreases smoothly if there is a lack of upgrading data. Second and third optionsallow a simpler message, as they require less parameters. Last option requiressimilar number of parameters than first one, but precision is strongly degradedoutside the validity interval.

2. Satellite clock data: Once the frequency standards have been selected, studiesshall be performed to assess their performances and define the best suitable clockmodel. Real clocks behaviour will condition the number of required parametersand their interval of validity.

3. Almanac data: The almanac is a reduced-precision subset of the clock andephemeris data. It is used for satellite selection purposes and as an aid toacquisition. Included data may be simple ephemeris (to estimate approximateposition), clock data and health status of the satellites, and information to GNSSreference time with other systems (e.g. UTC). The main requirement here is theminimisation of TTFF.

4. Ionosphere data: These data are mandatory required for single frequency users.In this case, the use of an analytical model (such as in GPS) may lead to tooinaccurate results (an EGNOS-like ionospheric information, based on a set of gridpoints, seems to be the best solution). Multi-frequency users may estimate andcompute directly the ionospheric delay in the slant range, but some specificmeasurement processing for relative navigation require a message with theestimated ionosphere.

5. Integrity data: These are the most important data for users concerned by thesafety of use of Galileo. EGNOS-like information will include a UDRE (whichmeasures orbit and clock errors) and a GIVE (which measures the accuracy of theionospheric delay). High frequency updates will be needed, at least once beforeeach time to alarm; thus the broadcasting strategy shall be defined allowing aquick update and reception of the integrity message.

6. Differential corrections : These corrections are intended to partially eliminateunmodelled biases from the propagation delay. Such biases, for the userequipment, comprise mainly the atmospheric delay and errors in the satelliteposition and time due to residual errors in the ephemeris, orbit propagation andonboard clock estimation.

Note that both time and space information has to be referred to an appropriate time andcoordinate frame system, to be defined at system level.

While clock and ephemeris data are clearly related to one specific satellite, almanac andionosphere data are referred to the whole system. In relation to the almanac data, they must bebroadcast by all the satellites in the constellation, as this information will help the receiversstarting up once one satellite has been locked.

Some possible solutions concerning specific sections of the Galileo navigation message willbe analysed in subsequent sections of this document. In particular, with respect to:

− ephemeris data,

GALA REF :DATE :

Gala-als-dd-01412-04-2001


− almanac data,− satellite clock data,− ionospheric corrections,− differential corrections,

several options will be investigated. A possible baseline will be finally proposed (Section 8)although some trade-offs could not be completely consolidated.

3.2.2.2 Messages definition driversWhen defining a navigation message, the following driver factors must be kept into account:

− Accuracy: Messages must provide the users the necessary information to reach thedemanded precision level. This implies that each transmitted parameter shall be accurateenough (thus affecting the number of bits and message size) and that data sets have a periodof validity after which precision will be degraded.

− Integrity: Comprises alarms on failure events and estimation of performances provided.The time to alarm requirements are a major driver for the navigation message definition, asthey affect both message structure and broadcasting strategy.

− Message robustness: It is conditioned by the message word length, rate of parity bits anderror correcting scheme, but the proper selection is constrained to the time to alarmrequirements (which condition the message length) and the data link integrity (whichconditions the rate of parity bits and the correction scheme). Robustness may be alsoincreased by the use of dual frequency.

− Time to first fix: Any user must acquire at any time the necessary data to compute theposition as soon as possible; this implies that the information must be transmittedcontinuously even if the interval of validity is several hours. As almanac data speed up thereceiver start up significantly, once a satellite has been locked the information should bedownloaded as soon as possible. To reduce the 12.5 min needed in GPS due to the fixedbroadcast order, an adaptive strategy could be used, which would transmit data from theclosest satellites more frequently. The use of multiple frequencies could also be anadvantage.

− Continuity: Concerning this requirement, the ground segment must broadcast the estimatestime for manoeuvre start in each satellite some hours in advance, plus a time span ofunavailability or maybe an a priori error bound.

− Data update, validity and refresh time : The period after which the data are updated undernominal conditions is the update time. Such value depends on the transmitting strategywithin the uploading stations. With validity time, instead, it is intended the maximum periodduring which a set of data can be used, without being updated, leaving the system still ableto guarantee the requested performances (normally the update time should be always loweror at least equal to the validity time in order not to degrade the system performances). Thevalidity interval, therefore, depends on the parameter (hours for ephemeris, somewhat lessfor clocks, minutes for ionosphere), thus conditioning the update interval, which will be alsoconditioned by the interval of validity of the parameters estimation.The time it takes the entire set of data to be broadcast to the user disregarding the fact if thedata are updated or not is the refresh time (or repetition time). This last value is driven bythe TTFF and it is strictly related to the message structure design. As a consequence, todetermine the correspondent refresh time values related to each data-set it is necessary to

GALA REF :DATE :

Gala-als-dd-01412-04-2001


consider also other investigations concerning the definition of the message which areperformed in other WP's in the frame of the GALA and GALILEOSAT programs.

3.2.2.3 Message definitionThe Galileo system will provide signals at least on two separate frequencies in order to allowthe users to remove the ionospheric propagation errors in a safe and accurate way. Therefore,it is possible to take advantage of this fact and transmit the data separately in the differentfrequencies. This strategy helps relax the bit rate requirements resulting in a more safety andeffective transmission.

The final Galileo navigation message structure (together with data rates), however, is notgiven by the present document. Other WPs in the frame of the GALA and GALILEOSATstudies are in charge to define the signal structure and the bit rate in the various channels.

3.2.2.4 Broadcasting strategy and requirementsThe same is valid concerning the broadcasting strategy of the Galileo navigation data; onlysome recommendations can be given in the present document. It is, in fact, not a task ofWP2.2.3 to define the finale structure of the entire message to be transmitted and how it mustbe disseminated.

Two assumption, however, may be kept in mind in the prosecution of the investigation:• two final users may be considered: single and multi-frequency receivers;• the signal specification is composed of two channels, low bit rate capability (in the order

of 150 bps) and a high bit rate capacity (in the order of 1250 bps).

Concerning the data priority, in fact, the high constraining requirements of the integrity datasuggest the possibility of use of one frequency, the high bit rate channel, as integrity channel,being the information transmitted there mainly referred to integrity. Other frequency, the lowbit rate channel, would transmit a complete set of data at the allowed bit rate with acquisitiontime in the order of minutes, which would be suffice. For TTFF purposes additional data haveto be broadcast in the high bit rate channel, at least the almanac data. This strategy allows todistinguish two levels of Galileo service:

• Multi-frequency users: They would be the most demanding users. Equipped withmulti-frequency receivers they can remove precisely the ionospheric propagationerrors and obtain integrity information which satisfy the most stringent requirements.Their TTFF should be in the order of seconds.

• Single-frequency users: Equipped with single frequency and cheaper receivers, theyobtain a less accurate positioning and integrity information which, nevertheless,satisfy their needs. In this case, the integrity data would be also transmitted in thisfrequency, but the stringent Time-To-Alarm requirements would not be guaranteed.Parameters for an ionospheric model have to be broadcast in order to obtain apartial compensation of the ionospheric delays.

In relation to the refresh rate the data can be classified by their validity period:

• Typical long-term validity (Clock, Ephemeris, Almanac, Nominal ionosphere).• Typical short-term validity: (Integrity, Ionosphere perturbations).

But the main driver for refresh time is the TTFF requirements. Initially one satellite must betracked, then the first fix is obtained once there are tracking and enough data from foursatellites. In these conditions diversity must be applicable just from these 4 satellites. In theseprocess at each step there is a different priority in data reception:

GALA REF :DATE :

Gala-als-dd-01412-04-2001


• One satellite tracking: Almanacs must have acquisition priority. In the worstreception conditions these data are only received through the low bit rate channel,but in normal conditions the high bit rate channel is also available without diversity.

• Acquisition of four satellites: Now, in order to achieve the first fix, all the other datahave acquisition priority: clock, ephemeris, integrity, and ionosphere for a singlefrequency user. The diversity in the high bit rate channel can be exploited.

• Normal navigation: In these conditions the reception priority is for the short-termvalidity data: integrity and ionosphere perturbations for the single frequency userswhile the multiple frequency users does not require ionosphere data, as it is beingdirectly measured.

Another constrain to set the broadcasting strategy is to consider the possibility of cheapreceivers with only one carrier and the low bit rate channel. In these conditions the priorityorder for the data at the low bit rate channel has to be set for the acquisition and the cheapestreceiver. It is:

Integrity (priority in order, not in data amount), Almanacs, Other data. The priority ofthe ionosphere data depends on how important these data are considered for this type ofuser. In a trade-off between the priority of the TTFF requirement, and the accuracyrequirement that demands an appropriate knowledge of the ionosphere it looks that thetransmission of a good ionosphere estimation should be carried out, although at the costof a longer TTFF for this type of user. This means that although taking some time thefull ionosphere has to be sent. Then the priority in the other of data broadcast isIonosphere perturbations (for integrity, but the consideration or not of these type of datafor this user depends on the demanded level of integrity), Clocks and Ephemeris (forTTFF) and later the full nominal ionosphere model content (for accuracy).This cheap receiver will then have an initial navigation state without ionosphere, as nowis the nominal case of the GLONASS system, and some time later a more accuratenavigation state with ionosphere. Except in locations and periods of high ionosphericactivity the degraded accuracy of this initial navigation state is not critical, while the gainin global accuracy later is high, because even the locations with high ionospheric activitywill have good accuracy service. Then, the discussion relies only in if the upgrade inperformances by having available the ionosphere perturbations data has to be achieved.

The priority order for the data at the high bit rate channel, for a single frequency receiver isthe same than for the previous user, with a high gain in TTFF:

Integrity (priority in order, not in data amount), Almanacs, Ionosphere perturbations,Clocks and Ephemeris, Full nominal ionosphere. In this case, in order to support theintegrity and TTFF requirements, the diversity must be used for all the data. So clock andephemeris are not send as in low bit rate channel, specific for each satellite, but withdiversity simultaneously through all the satellites. If for any data diversity is not used,e.g. for the full nominal ionosphere, then the receiver could remain in the state ofnavigation without ionosphere the same time than the cheapest receiver, what does notlook admissible.

In this scheme the only difference between both single carrier receivers is that the only lowbit rate receiver is slower in TTFF, in integrity and in arriving to the full navigation state, butthe accuracy at this final stage is only determined by the differences in measurements quality.Any use of a simpler ionosphere model degrades the availability of accuracy in the fullnavigation, while only some initialisation time is gained.

In the case of multi-frequency receivers with different high bit rate data on them, then theionosphere model is not more required. The priority in all the other data must keep the

GALA REF :DATE :

Gala-als-dd-01412-04-2001


integrity in the first place but trying to be complementary to high bit rate channel. The priorityis then as follows:

Integrity (priority in order, not in data amount), Clocks and Ephemeris, Almanacs. In allthe cases diversity has to be used. Integrity must be sent simultaneously by all the highbit rate channels for redundancy purposes, but Clocks, Ephemeris and Almanacs musthave a complementary order among the three high bit rate carriers in order to reduce thereception time of the messages for all the satellites by a factor of three.

Concerning the broadcasting requirements, Table 3-4 summarises the adopted requirements inthe case of the GPS and the Glonass systems. The proposed solutions for Galileo will bereported in next sections of the present document (mainly Section 8).

Table 3-4. Broadcasting requirements for GPS and Glonass navigation data.Type

of dataEstimated size

(bits)Validity

TimeRepetition

TimeApplicability

Almanac(for a 24 MEO constellation)

For GPS, to a=8 bits, af0=11 bits,af1=11 bits not considered

GPS 144 (per satellite)GLONASS 99 (per satellite)

Several daysSeveral days

12.5 minutes2.5 minutes Whole system

Ephemeris GPS 366GLONASS 175

4 hours15 minutes

30 seconds30 seconds

1 satellite

IonosphericCorrection

(Klobuchar model)GPS 64 Hours 12.5 minutes Whole system

Estimated Groupdelaly differential (TGD)

(per satellite)GPS 8 Few hours 30 seconds 1 satellite

Clock correctionparameters

For GPS IODC=10bits andWN=10bits not considered

(per satellite)GPS 62GLONASS 60 (within the almanac data) 52(within the ephemeris data)

Few hours

TBDTBD

30 seconds

2.5 minutes30 seconds

1 satellite

UTC-GPS(time)correlation

GPS 104(within the almanac data)

6 days curvefits

12.5 minutes Whole system

For TTFF considerations, since almanacs take a long time to be collected, they have to bebroadcast by both the signals with the low and the high bit rate to speed up the acquisitionprocess, down it from minutes to seconds. Then, once the appropriate number of satellites arebeing tracked, depending on the TTFF requirements the clock and ephemeris data have to besend both channels. If TTFF is in the order of few minutes their broadcast through the low bitrate channel is enough, while to reach the performances in the order of seconds, the high bitrate channel is also required.

Finally, to the requirements shown in Table 3-4, integrity data must be added. They are themost stringent as they must be updated and transmitted in less than 6 seconds for CAT I andin the order of 1 second for better than CAT I category. These data are to be sent by all thefrequencies, although the final service level can be different on each frequency.

GALA REF :DATE :

Gala-als-dd-01412-04-2001


4 IONOSPHERIC CORRECTIONS

4.1 IONOSPHERIC DELAY AND CAUSES

The ionosphere, extending in various layers from about 50 km to 1000 km above earth, is adisperse medium with respect to radio signals. Main parameter for the propagation error ofradio signals induced by the ionosphere is the Total Electron Content (TEC) along the signalpath. TEC itself is a fairly complicated quantity because it depends e.g. on sunspot activities(approximately 11-year cycle), seasonal and diurnal variations, the line of sight whichincludes elevation and azimuth of the satellite, and the position of the observation site [RD14].

The main ionospheric influences on radio signals are the following:1. Ionospheric propagation error for signal group (-) and signal phase (+):

TECf

3.40d

2ion ±≈ , (1)

where dion is the ionospheric propagation error (m), f (Hz) the carrier frequency andTEC the total electron content in TEC Units (1 TECU = 1016 electrons / m2).

2. Doppler-Shift:

dtdTEC

cf3.40

dtdn

f ==∆ (2)

3. Faraday-Rotation:

TECBf63.2

L2⋅=Ω (3)

where Ω is the rotation of the polarisation plane in radiant and BL the longitudinalcomponent of the magnetic field of the earth.

4. Refraction and diffraction of radio signals.

5. Fast changes in amplitude and phase (amplitude and phase scintillation) of radiosignals.

Depending on the morphology, it can be distinguished between regular and irregularionospheric effects which influence signal transmission. Regular effects result from thenormal sun driven large-scale TEC variations, which lead to the above mentioned signaldelays and polarisation effects. Irregular effects result from small scale irregularities in theelectron density distribution, often caused by special solar events, like Coronal MassEjections, Proton Events, X-ray flares, etc. These events cause geomagnetic and ionosphericstorms, TIDs, Single Event Upsets etc. Outcomes of these are high variations in theionospheric electron density as well as the above mentioned scintillation effects.

Especially scintillation is of strong interest for the integrity of satellite navigation systems,working in the L-Band. When small scale irregularities in the ionosphere are sufficientlyintense, rapid fluctuations (scintillations) in the amplitude and phase of radio signals aregenerated. Whenever the signal amplitude fades exceed the receiver’s fade margin, the signal

GALA REF :DATE :

Gala-als-dd-01412-04-2001


is temporarily lost. Phase scintillations can produce cycle slips and sometimes overstrain areceiver’s ability to hold lock on a signal.

The strongest scintillation (fades up to 20-30dB) occur in the region of the equatorial anomalyregion located ±15° of the geomagnetic equator. Scintillation in this region is seasonallydependent and limited to local night-time hours.

The occurrence of high latitude scintillation is strongly dependent on the geomagnetic activitylevels, but can occur in all seasons at all times.

In mid-latitudes scintillation only occur in response to extreme levels of geomagnetic activity.During these periods, the active aurora expands both poleward and equatorward exposing themid-latitude region to auroral scintillation activity.

All these effects are more or less correlated with the solar cycle. At present the solar activityis increasing and will reach its maximum at about 2000-2001. Thinking about integrity of aGNSS, the following expectations for solar maximum shall be taken into account [RD 16]:

1. Increase of solar EUV ⇒ High increase of TEC; maximum at 2000-2001 (high rate ofscintillations, especially in the equatorial regions)

2. Increase of CME ⇒ Increase of geomagnetic storms at 2000-2002 (high rate ofscintillations especially in polar regions)

3. Increase of Coronal Holes ⇒ Maximum number of minor storms at ca. 2005 (high rate ofscintillations especially in polar regions)

4. Increase of Proton Events ⇒ Increase of Single Event Upsets at ca. 2001

5. Increase of x-ray flares ⇒ Rapid change in dayside TEC at ca. 2001

4.2 IONOSPHERIC DELAY MEASUREMENT (DUAL FREQUENCYTECHNIQUE)

The estimation of the ionospheric propagation delay makes use of the disperse character ofthe ionosphere. According to the GPS receiver type, up to 5 observables are at disposal forevery single tracked satellite: CA- and P-Code on L1, P-Code on L2 and carrier phasemeasurements on L1 (1.575 GHz) and L2 (1.227 GHz). The resulting equations for code andphase pseudoranges are:

(2) satkrec

satkrec

satkrec

satkkrec

satkrec

satkrec EfdiondtropdTdtcRC ,,,,,, )(][ +++−⋅+= [Code]

(3) satkrec

satkrec

satkrec

satkkrec

satkrec

satkrec ENfdiondtropdTdtcRP ,,,,,, )(][ −⋅−−+−⋅+= λ [Phase]

Where:sat

krecR , denotes the real satellite receiver distance,

krecdt , the receiver clock error,

satkdT the satellite clock error,

satkrecdtrop , the tropospheric error,

)(, fdion satkrec the frequency depending ionospheric error,

N the ambiguities,

λ the wavelength of the carrier phases andsat

krecE , the sum of noise, multipath and instrumental biases for an epoch k.

GALA REF :DATE :

Gala-als-dd-01412-04-2001


For the estimation of the ionospheric delay combinations of these observables are used toremove all frequency independent effects like geometrical distance, clock and troposphericeffects. This results into 3 possible equations for the estimation of TEC:

Biased TEC , Code combination:

ctnoise

ctmultipath

ctbias

TECct

PPk

kk +++=− 12

Biased TEC, Phase combination:

ctnoise

ctsAmbiguitie

TECct

LLk

kk ++=− 21

Biased TEC ,Code/Phase combination:

22 /3.402/3.4021

fsambiguitiebiasnoisemultipath

TECf

LCAk

kk

⋅+++

+=⋅

−

where: 2

2L21L

22L

21L

ffff

3.40ct⋅−

= .

For the estimation of the pure ionospheric delay the TEC has to be separated from the noise,multipath and bias terms, in case of phase measurements we have to estimate ambiguities anddetect cycle slips during the measurement. How to remove or reduce these effects shall not beoutlined in this document. It shall only be mentioned, that multipath effects can be onlyreduced (not eliminated) by the use of data smoothing or the use of observations withelevation angles greater then 10°. Ambiguities can be solved by combining phase and codemeasurements and bias can be estimated as described by Sardón et al. [RD 17] or removed bythe use of bias data as supplied by DLR (http://www.kn.nz.dlr.de) or IGS(ftp://igs.ensg.ign.fr/pub/igs/iono/).

4.3 MODELS FOR IONOSPHERIC CORRECTIONS

Corrections of the ionospheric propagation error by the above-described procedure are onlypossible by the use of two-frequency receiver. For single-frequency users it is necessary tomodel the ionospheric delay.In GPS, the sub-frame 4 of the navigation message contains coefficients that allow thecomputation of ionospheric corrections on base of the ionospheric refraction modelKLOBUCHAR.

4.3.1 The Klobuchar modelThe KLOBUCHAR model is based on an ionospheric single-layer model and allows anapproximation of the propagation delay for signals which cross the ionosphere in verticaldirection. At night times the delay is set to a constant value of 5 ns, at day the delay ismodelled by a cosine function of the local time. Amplitude and period of the cosine functionare dependent on the geomagnetic latitude of the sub-ionospheric point. They can becomputed by the use of 8 coefficients uploaded daily to the satellites and broadcast to theuser.

GALA REF :DATE :

Gala-als-dd-01412-04-2001


The full algorithm for this ionospheric correction model KLOBUCHAR is given by [RD 24]:

seconds

57.1,)105(

57.1,242

1105

9

429

≥⋅

<

+−+⋅

=

−

−

xF

xxx

AMPFTion

where T ion is referenced to the L1 frequency.The obliquity factor (F) in the model is given by:

)ensionless(dim)E53.0(161F 3−+=

where E is the elevation angle between the user and the observed satellite in semicircles.The vertical delay amplitude (AMP) in the model is given by:

ondssec0AMP,0AMPif

0AMP,

AMP

3

0n

nmn

=<

≥φα

=

∑=

where:an = The satellite transmitted coefficients of a cubic equation representing the amplitude of the

vertical delay with n=0,1,2,3 (four coefficients, eight bits each)φm =

=

Geomagnetic latitude of the earth projection of the ionospheric intersection point. The meanionospheric height is assumed to be 350 km.φi +0.064 cos (λi –1.617) semicircles

φi ==

Geodetic latitude of the earth projection of the ionospheric intersection pointAcosu ψ+φ semicircles,

for 416.0i ≤φ semicirclesif 416.0i >φ , then 416.0i +=φif 416.0i <φ , then 416.0i −=φ

φu = User WGS 84 geodetic latitude (semicircles)ψ =

=

Earth’s central angle between user position and Earth projection of the ionospheric intersectionpoint

022.011.0E

0137.0 −+

semicircles

A = Azimuth angle between the user and the observed satellite (semicircles)λi =

=

Geodetic longitude of the earth projection of the ionospheric intersection point

iu cos

Asinφ

ψ+λ semicircles

λu = User WGS 84 geodetic longitude (semicircles)

The phase (x) in the model is given by:

PER)50400t(2

x−π

= radians

GALA REF :DATE :

Gala-als-dd-01412-04-2001


where:

T = Local time timeGPS)1032.4( i4 +λ⋅= (seconds)

For 86400t0 ≤≤ secondsIf 86400t ≥ , subtract 86400 secondsIf 86400t < , add 86400 seconds

GPS time = Receiver computed system timePER =

=

Period of the model

=<

≥φβ∑=

72000PER,72000PERif

72000PER,3

0n

nmn

nβ = The satellite-transmitted coefficients of a cubic equation representing the period of themodel with n=0,1,2,3 (four coefficients, eight bit each)

As an example for the performance of the model, Figure 4-1 shows the ionosphericpropagation delay computed with Klobuchar model using the coefficients from the01.07.1999. To get an impression of the geomagnetic dependencies, considered by the model,the local time for every map point was set to 12:00LT. Even this plot shows the simplicity ofthe Klobuchar model. For example, without going in detail, although the equatorialionospheric maximum is following the geomagnetic field lines correctly this more complexregion isn’t reproduced satisfactory. The maximum in this region has to be divided by aminimum in the middle with high gradients in between. This is a special phenomena of theequatorial region (equatorial crest). The literature states that the Klobuchar model includesonly 50 % of the ionospheric delays [RD 14], [RD 15].

Figure 4-1. The ionospheric propagation error (m) by the Klobuchar model for01.07.1999 computed for 12:00 LT at every map point.

GALA REF :DATE :

Gala-als-dd-01412-04-2001


4.3.2 Other ionospheric modelsBeside the Klobuchar model several other models for the temporal and spatial variations ofthe ionosphere including the distribution of the electron density have been developed in thepast. In contrast to the KLOBUCHAR most of these models where developed as an attempt toreproduce physical ionospheric coherence, then to compute ionospheric corrections withefficient and simple runtime optimised algorithms. Some of them are based on large sets ofcoefficients (CCIR, URSI) or indices and provide beside TEC also height profiles of electrondensity, ion composition etc. In the following a brief description of the most applicablemodels will be given.

4.3.2.1 Indices and DatabasesAs mentioned above the important characteristics of the ionosphere are correlated with certainquantities associated to the changes of solar and geomagnetic activity. For the prediction ofmedian ionospheric variations two types of indices are applicable:§ Solar Indices: Measurable quantities of solar activity or radiation,§ Ionospheric Indices: Quantification’s of the global change in ionospheric

characteristics at selected observing stations.

At present the solar sunspot number (SSN), the solar flux at 10.7cm (F10.7) together with the12 month running average of the SSN (R12) and F10.7 are used to couple ionospheric modelsto the solar activity.For the reproduction of the geomagnetic activity in the models, the Kp and Ap indices aregenerally used:§ Kp is based on the range of variations within 3-hour periods of the day, observed in

the records from about a dozen selected magnetic observatories. After localweighting, and averaging, the Kp value for each 3 hours of the day is obtained on ascale from 0 (very quiet) to 9 (very disturbed).

§ Ap is a daily index, obtained from the same database as Kp, but converted to a linearscale (3-hour ap) and then averaged over the day. The value of the intermediate ap isapproximately half the range of variations of the most disturbed magnetic componentmeasured in nanoteslas.

Beside these indices, ionospheric models make use of the CCIR and URSI coefficient sets.The CCIR data set contains the coefficients for the foF2 and M(3000)F2 modelsrecommended by the Comité Consultative International des Radiocommunications (CCIR).foF2 is the F2-peak plasma frequency and M(3000)F2 is the highest frequency that, refractedin the ionosphere, can be received at a distance of 3000km. Both parameters are routinelyscaled from ionograms of about 150 ionosonde stations world-wide. Following a numericalmapping procedure [RD 25] each station data set is first represented by a Fourier time seriesand then in a special form of Legendre coefficients is applied for each Fourier coefficient. Forthe URSI coefficients the numerical mapping method is the same, but the data gaps are filledby using aeronomic theory [RD 26], before applying the mapping procedure.

4.3.2.2 ModelsOne of the simples ionospheric models is the Chiu ionospheric model. This phenomenologicalmodel describes the large-scale variations of ionospheric electron density with local time,latitude and solar sunspot number. It is based on ionosonde data from 50 stations spanning theperiod 1957 to 1970. The model profile is obtained as the sum of three Modified Chapmanfunctions for E-, F1- and F2-layers. The model is fairly simple, using less than 50

GALA REF :DATE :

Gala-als-dd-01412-04-2001


coefficients, which limits it’s application for equatorial and higher latitudes. It is, however,fast and easily manipulable [RD 18].

A more sophisticate (but only regional) ionospheric model is the NTCM2. It is based on long-term TEC observations of the European region. Here the TEC is modelled as:

TEC H h Y d L h d S Fi j k llkji

=====∑∑∑∑ ( ) ( ) ( , , , ) ( )φ λ 10

1

2

1

2

1

3

1

5

Where Hi(h) denotes the diurnal and semidiurnal variation, Yj(d) the annual and semiannualvariation, Lk(φ , λ, h, d) the dependence on the solar zenith angle and Sl(F10) the dependenceon the solar activity.

The model approximates the TEC depending on the input of location, time and solar activity.The combination of the modelled TEC and real TEC, derived by the GPS data of the IGSnetwork, by a least square approach leads to European TEC maps with an overall RMS ofabout 2-3 TECU, which can be used for ionospheric corrections [RD 19]. One disadvantageof the model from the application-oriented point of view is, that the coefficients have to beenyearly updated to suit the ionospheric conditions under increasing solar activity.

The Bent model was developed for trans-ionospheric propagation uses. It describes theionospheric electron density as a function of latitude, longitude, time, season. The model isbased on coefficients retrieved from Alouette topside ionograms, Ariel 3 in situ measurementsand bottomside ionograms and on solar sunspot number (R12), solar radio flux (12 monthaverage of F10.7) and actual Kp values, provided by the user. For the F2-peak the CCIR mapsare used. The electron density is modelled differently in five height layers as shown in Figure4-2. There k1, k2, k3 denote the decay constants for the lower middle and upper section of theexponential topside profile. y1, y2 and y3 are the values of half thickness for the topsideparabolic layer and for the bottomside bi-parabolic layer respectively. The height limits foreach layer are first determined and the value of electron density at the start point of thevarious layers Nm, N0, N1, N2. The height increments measured from the start point of thevarious layers are denoted as variables b1, b2, a1, a2, a3.The model was primarily developed for use near to or above the height of maximum electrondensity, therefore it does not include the lower ionospheric layers (D,E,F1) and uses simplyquadratic relationship between CCIR’s M(3000)F2 factor and the height of the F2-peak [RD19]. Even if the BENT model use simplifications for the lower ionospheric layers it showsacceptable results for the reproduction of median TEC and the topside of the ionosphere.

One of the most complex models at present is the International Reference Ionosphere (IRI95),a result of the activities of the international scientific organisations URSI and COSPAR. IRIis an empirical model based on the following large databases:§ Electron density: Height profiles deduced from ionograms, profiles obtained by

incoherent scatter radar (ISR) sounding and the compilation of Alouette topsidesounder profiles.

§ Plasma temperatures: ISR profiles, rocket in-situ (probe) measurements and satelliteprobe data, the latter mainly from the AEROS and the Atmosphere ExplorerSatellites.

§ Chemical Ion composition: Mass spectrometer and retarding potential analyser in-situ measurements, mainly from USSR rockets and the AEROS and AtmosphereExplorer satellites.

GALA REF :DATE :

Gala-als-dd-01412-04-2001


It provides the electron density, electron temperature, ion temperature and ion composition inthe non-auroral ionosphere for magnetically quite conditions in an altitude range of 50-2000km, for a given location, time and date. Being built on monthly average data, IRI hascertain limitations. In particular the peak electron density, for a given local hour, showssignificant diurnal fluctuations of up to 30%. IRI therefore includes an option that allows theinput of measured peak data. Further the ionospheric conditions in the polar zones (that areextremely variable) depend on the largely variable corpuscular flux arriving from themagnetospheric tail and can not extrapolated from data of lower latitudes. Therefore even thecomplex IRI model gives an unsatisfying picture of these regions. IRI is updated yearlyduring special workshops. (A comparison between IRI TEC predictions and the TEC obtainedfrom GPS data can be found in [RD 19]). The source code is distributed by the NationalSpace Science Data Center (NSSDC) and the World Data Center A for Rockets and Satellites(WDC-A-R&S), USA.

Figure 4-2. Model Profiles used in BENT.

The above-described models are only a subset of all existing ionospheric models. However, ithas to be mentioned that these models as well as most of the other available models arelimited to quiet or moderate geomagnetic conditions and provide only TEC or electrondensity profiles. Additionally, only a few models (WBMOD, GIM) are available forscintillations. Models of other perturbances are still missing a validation and require acomplex approach that makes them not easily usable for navigation applications.

↓ b2

↑ b 1

↑ a1

↑ a0

↑ a2

2

2m

22

myb1NN

−=

−= 2

t

21

my

b1NN

Electron Density N

Height h

h2

h1

h0

hm

11e

ak0

NN −=

22e

ak1

NN −=

33e

ak2

NN −=

2Ff k

2Ff 0

2N 1N0N mN

1,000 km

Ym

Y t

d

GALA REF :DATE :

Gala-als-dd-01412-04-2001


4.4 APPLICATION OF IONOSPHERIC MODELS IN SATELLITENAVIGATION

At current two methods to provide ionospheric corrections to users of satellite navigationsystem are in use or in case of EGNOS intended to use.

As already mentioned, the GPS navigation message contains a set of eight parameters of theKlobuchar model for an estimation of the ionospheric delay. The Master Control Station(MCS) of the Operational Control Segment (OCS) updates these parameters in a period ofabout 7 to 10 days. Estimates of the accuracy are not included.

Augmentation systems as WAAS, MSAS, EGNOS and ESTB provide or will provide GridIonospheric Vertical Delays (GIVD) as well as Grid Ionospheric Vertical Errors (GIVE) forwell defined monitored grid points. Beside the correction data also information about thevalid grid points has to be broadcast to the users.For EGNOS the chosen grid contains 1808 predefined possible IGP locations (as defined inTable 4-1), which must be permanently stored by the user.

Table 4-1. World-wide IGP distribution and spacing

Latitudes Latitude Spacing Longitude Spacing85°N 10° 90°

75°N-65°N 10° 10°55°S-55°N 5° 5°75°S-65°S 10° 10°

85°S 10° 90° (Offset 40° E)

Since the total IGP grid represents too many IGPs to be broadcast in a single message, thegrid is divided into 9 bands with 201 possible IGPs. Each message also contains a ionosphericmask issue of data (IODI) to ensure that the ionospheric corrections are well decoded. Thesame IODI will be used for all bands. An additional "band number" indicates how many bandmasks being broadcast by the satellite. Only the IGPs in the bands composing the satelliteobserved region will be transmitted. Table 4-2 gives an overview about the message design.

Table 4-2. IGP Mask Message Format for Message Type 18 in EGNOS

Parameter No. of Bits Scale Factor Effective Range UnitsNumber of Bands being broadcast 4 1 0 – 9 DiscreteBand Number 4 1 0 - 8 DiscreteIssue of Data, Ionosphere (IODI) 2 1 0 - 3 DiscreteIGP Mask 201 --- --- DiscreteSpare 1 --- --- ---

The actual correction message contains a band number and a block ID, which indicates thelocation of the IGPs in the respective band mask. If the number of bands is 0, no ionosphericdelay corrections are provided. The 4-bit block ID (0-13) indicates which block ofionospheric corrections, within the band, are provided. Every Block contains IGP correctionsfor 15 IGPs designated in the band mask. Each band is divided into a maximum of 14 blocks.Corrections associated with slot numbers that exceed the number of IGPs indicated in the IGPband mask shall be ignored. The vertical delays and the evaluated GIVEs have to betranslated by the user to the Ionospheric Piercing Point (IPP - points where the signals fromthe satellites intersect an imaginary sphere 350 km above the earth surface) of the observedsatellite.

This computed vertical delay and the associated UIVE (User Ionospheric Vertical Errorcomputed from associated GIVEs) must then be multiplied by a simple mapping factor,

GALA REF :DATE :

Gala-als-dd-01412-04-2001


depending on the elevation angle to the satellite, to convert vertical delays and errors to slantcorrections. The 9-bit IGP vertical delays have a resolution of 0.125 meter for a 0-63.625meter valid range. A vertical delay of 63.750 meters (111111110) indicates that the IGP wasnot monitored; and a vertical delay of 63.875 meters (111111111) indicates that this IGP cannot be used. (Table 4-3 shows the ionospheric parameters in the EGNOS message). Themaximum message update interval for GIVD/GIVE is 300s.

Table 4-3. Ionospheric Delay Model Parameters for Message Type 26 in EGNOS

Parameter No. ofBits

ScaleFactor

EffectiveRange

Units

Band Number 4 1 0-8 DiscreteBlock ID 4 1 0-13 DiscreteFor Each of 15 Grid Points 13 --- --- ---

• IGP Vertical Delay Estimate 9 0.125 0-63.875 Meters• Grid Ionospheric Vertical

Delay Error Indicator4 1 0-15 Discrete

IODI 2 1 0-3 DiscreteSpare 7 --- --- ---

As mentioned above the Klobuchar model lead to inaccurate corrections, thus theWAAS/EGNOS-like grid point concept with possibility to provide, beside the ionosphericdelay information, also regional error estimates (depending on the distribution of the monitorstations) seems to be the best solution.But also the grid-concept may take advantage from the use of a ionospheric model. One mainproblem in the grid concept is to transform the slant ionospheric delays and errors from theremote monitor stations to vertical delays and errors at the grid points (in principal the user ofthe system has the same problem just the other way round). Simple weighted least squaremethods computing distance weighted means of the measured data to estimate GIVD/GIVE ata specific IGP may by adequate in mid latitude regions with a high number of monitorstations as Europe, USA etc. (see Figure 4-3) but will be insufficient in areas with a lownumber of monitor stations especially in the equatorial and polar regions where theionosphere has more complex structure with higher variations.

Figure 4-3. The ionospheric propagation delay mapped at the ECAC grid in the EGNOSSystem Test Bed (ESTB) based on data of 8 monitor stations in Europe at 01/07/1999.The measured delays at the monitor stations are transformed to the grid points by adistant weighted least square method.

GALA REF :DATE :

Gala-als-dd-01412-04-2001


To solve these problems a method as published by El-Arini et al [RD 20] may be moresuccessful. He estimates the vertical ionospheric delay at a specific IGP as the average of allvertical delays of all pierce points seen by all remote monitors weighted by:§ the inverse distance between each pierce point and the IGP,§ the ratio of vertical ionospheric delay predicted by an ionospheric model at the IGP to

the predicted vertical ionospheric delay at each of the IPP from all remote monitors usingthe same model.

The model used in this experiment, limited to the US East Coast, was the above-describedKlobuchar model, for a global system a more complex model is recommended.

4.5 SUMMARY

The ionosphere is a highly variable and complex system with different impacts on L-bandsatellite navigation:§ Regular ionospheric effects lead to shifts in phase and group delay of the signal which, if

not corrected, lead to large positioning errors. As single frequency users have to rely onmodels or external measurements of the ionospheric propagation error, multi frequencyusers are able to use the dispersiveness of the medium for first order corrections.

§ Irregular ionospheric effects (as scintillation) generate high fluctuations in phase andamplitude of radio signals and, if sufficiently intense, lead to lose of lock and cycles slipsand disable also multi frequency receiver of correct positioning.

In case of regular ionospheric effects different models exist to estimate ionosphericcorrections. However, since most of the present ionospheric models (IRI, BENT etc.) rely onlarge sets of data and complex algorithms, they cannot be used for navigation purposes.

To support possible single frequency users of the Galileo system, two different solutions maybe adopted for ionospheric corrections:

1. a simple model of less accuracy comparable with the Klobuchar, which consist of 8parameters with an overall data size of 64 bits in the navigation message and a validitytime in the range of hours (GPS approach);

2. a grid point concept as in WAAS or EGNOS systems, providing ionospheric correctionsand error estimates for global defined grid points, with an overall data size of 205 bitsper block (i.e. 15 IGPs) in the navigation message and a validity time in the range of10min to hours. This implies that since a maximum of 14 blocks (worst case) compose one"band", a maximum of 2870 bits will be necessary to completely describe one of the ninebands in which the overall grid is divided.

Comparing the capability for regular ionospheric corrections, the EGNOS/WAAS grid pointconcept seems to be the preferable solution. It is able to provide corrections of higheraccuracy even in critical ionospheric regions. It provides error estimates and, if required byfuture applications, it is also possible to enhance the correction accuracy (e.g. by the use ofmore reference stations or new background models or algorithms) without changing thenavigation message.

Independent of the inclusion of regular ionospheric corrections in the navigation message, theproblem of ionospheric scintillation and it’s effect on system integrity still remains for both,single and multi frequency users.These effects cannot be assigned to a special satellite, in this case only a grid point concept,with different parameters than the current EGNOS (e.g. scintillation probability), offers the

GALA REF :DATE :

Gala-als-dd-01412-04-2001


ability to consider local ionospheric scintillation effects and to provide global integrityinformation to potential users.

GALA REF :DATE :

Gala-als-dd-01412-04-2001


5 TIME CORRECTIONS

In Galileo, like in other one-way ranging systems, the time keeping system is one of the keyelements. The heart of Galileo is composed of precision clocks, i.e. ultra-stable frequencysources, which exist in several types and are also widely employed by the conventionalsystems GPS and GLONASS in the space and ground networks. Navigation and timing usersrely mainly on these clocks, the navigation signal is even based on the clock signal. To enablea solution of the navigation equation, the system provider needs to mutually synchronise allthe system clocks very accurately. Consequently, a new independent system time scale has tobe generated. All the clocks can then be referenced to that time scale.

For navigation, dating and dissemination purposes, the existence of one Galileo System Time(GST) scale as a reference time scale is compulsory. The clocks of each satellite shall then besynchronised to this GST scale. This is necessary in particular for [RD 9]:

• evaluating satellite ephemeris;• having a common reference time for scheduled activities (for example performing

synchronisation measurements in the system);• providing a correct information on the clock status in the navigation message(this

gives the basis for a correct solution of the user's navigation equation);• disseminating a reference time scale or Universal Time Coordinated (UTC) to

different users.

Some clock parameters must, therefore, be defined in order to broadcast within the navigationmessage such time information. The necessary parameters will be analysed in the followingsub-sections. They can be divide into two types:

• The clock correction parameters (they are necessary due to the impossibility ofdirectly steering the physical satellite clocks to the system time. Thus it is necessaryto transmit correction parameters, which represent the difference between thetransmitted physical clock time and the system time. With this information thereceiver is able to synchronise the received time signals to the GST).

• Parameters for interoperability between the GPS and the Galileo System and theconnection of GST to the Universal Time Co-ordinated (UTC).

5.1 SATELLITE CLOCK CORRECTIONS WITHIN THE NAVIGATIONMESSAGE

Due to the requirement of synchronised satellite clocks, the physical times of the differentonboard time standards have to be corrected to the GST scale. The difference between thetime of the physical clock and GST is called satellite clock correction term ∆tsv. This term,which is individual for each satellite, can be approximated by the following 2nd orderpolynomial:

( ) ( ) R2

ocf2ocf1f0sv tttattaat ∆+−+−+≅∆ ,

GALA REF :DATE :

Gala-als-dd-01412-04-2001


where a f0, af1 and af2 are the polynomial correction coefficients corresponding to phase error,frequency error and rate of change of frequency error. Higher order terms have been omitted.The parameter toc is a reference time (in s) for the clock correction and ∆tR describes thecorrection of the relativistic clock effects, which must be computed by the user.Consequently:

• toc is the time issue of the clock correction parameters;• af 0 is the time offset between the physical satellite clock and the GST as

determined at toc;• af 1 is the frequency offset between the physical satellite clock and the GST as

determined at toc;• af 2 is the frequency drift between the physical satellite clock and the GST as

determined at toc;• ∆tR is the relativistic correction term.

The previous polynomial allows the user to determine the effective satellite PRN code phaseoffset referenced to the phase centre of the antennas (∆tsv) with respect to the Galileo SystemTime (t) at the time of data transmission. For that the coefficients toc, af0, af1 , af2 have to betransmitted in the navigation message. The relativistic correction term ∆tR, which describesthe relativistic clock effects, must be determined by the user equipment with the relation:

kR sinEAeFt ⋅⋅⋅=∆ ,where the eccentricity (e) and the semi-major axis (A) of the orbit parameters are provided inthe ephemeris data section of the navigation message, and Ek is the eccentric anomaly,computed by the user as a part of the orbit propagation algorithm. F is a constant given as:

[ ]ms/ 10442807633.4c

2F 10

2−⋅−=

⋅−=

µ

where:

)parameters nalgravitatio universal sEarth' of (value sm

103.986005

light) of (speed sm

102.99792458c

2

314

8

⋅=

⋅=

µ

With that the user can correct the received time tsv to the system time tsystem by calculating:

svsvsystem ttt ∆−=

Figure 5-1 shows the clock error behaviour for different clock types, where:

S-VCXO: space- qualified crystal oscillatorSHMa-AFS: space-qualified H-maserSCs-AFS: space-qualified caesium clockHMa-AFS: H-maserCs-AFS: caesium clockRAFS: rubidium clock

This plot shows that most of the clock types exhibit a systematic behaviour, which can bedescribed by a second order polynomial. Higher order terms are not needed to model theclocks for the required accuracy. As a consequence, the transmission of only three clockparameters (including drift) for each satellite is sufficient. (This is a flexible approach tomodel each potential clock type).

GALA REF :DATE :

Gala-als-dd-01412-04-2001


Figure 5-1. Clock errors of different clock types

In the following the necessary range of values of the clock correction parameters af0, af1 andaf2 will be discussed. Assuming that the atomic clock has only a deterministic frequency drifterror dclock we get for the time error:

( ) ( ) RSV ttttt ∆−∆=∆ ε ,which is the difference between the time of the clock and the Galileo System Time (GST)after the correction of the relativistic effects, the expression:

( ) ( ) ( )2clock2clock

2clock

clock ttatt2

dtt −⋅=−⋅=∆ ε

In this equation the parameter tclock represents the theoretical time, where the clock has nofrequency and time offset error.Now for the satellite navigation message this error function has to be expressed as a quadraticpolynomial with the coefficients af0, af1 and af2 for a given time toc. Thus we get the followingequation:

( ) ( ) ( )2ocf2ocf1f0

!2

clock2clock ttattaatta −⋅+−⋅+=−⋅With the definition:

clockoc ttt −=∆we get:

( ) ( )

( )( )

( ) ( ) 22clockoc2clock

2oc2clock

!

2oc2clock

!

2ocf2ocf1f0

tattta2tta

ttta

ttattaa

∆⋅+∆⋅−⋅⋅+−⋅=

∆+−⋅=

−⋅+−⋅+

Finally the following relation between the coefficients can be found:

RAFS

SHMa-AFS HMa-AFS

SCs-AFS Cs-AFS

S-VCXO

sample interval = 10 s

Time [s]

?t sv

-?t R

[ns]

GALA REF :DATE :

Gala-als-dd-01412-04-2001


( )( )

2d

aa

t-tdta2a

t-t2

dtaa

clock2clockf2

clockocclock2clockf1

2clockoc

clock22clockf0

==

⋅=∆⋅⋅=

⋅=∆⋅=

where dclock is the frequency drift of the clock and ∆t represents the time span between the lastphysical steering of the clock tclock and the time toc for which the correction parameters aredetermined.In the following the necessary number of bits and the scaling factor of the clock correctionparameters in the navigation message will be discussed. This specification directly defines therange of values of the clock correction parameters. Because the absolute value of theparameters af0 and af1 increases over the time (see the equation above), the synchronisation ofthe physical clock with the second order polynomial based on this parameter set is onlypossible in a fixed time span, where the necessary clock parameters are in the defined rangeof values. After this time span the satellite clock must be physically steered to the Galileosystem time (GST). This means that the existing frequency and phase offset have to bephysically controlled to the correct values. After this steering the satellite clock has to bemonitored and the new correction parameters have to be calculated by the master controlstation. In the whole time (GPS: 7 days!) the satellite is not operable and must be switched tothe "bad" mode. Thus the specification of the number of bits and the scaling factor of theclock correction parameters have great influence on the operation of the satellites. Now eachof the clock correction parameters will be discussed separately.

• Time Offset af0:The number of bits and the scaling factor of this parameter defines the offset range, inwhich the onboard clock can be adapted to the GST. If the difference between theonboard clock and the GST is greater than the maximum value of af0, the onboard clockmust be physically steered.The scaling factor, which represents the value of the LSB (Least Significant Bit), ischosen as 2-31 seconds in GPS, which is approximately 466 ps. With this proven scalingfactor we get, depending on the number of bits and the type of the onboard clock,different time intervals for the necessary physical clock steering. In the following theresulting necessary clock steering intervals of a high precise caesium frequency standard,a hydrogen maser, a rubidium frequency standard and a quartz oscillator will becompared. The assumed typical clock frequency ageing values for this high precise clocksare shown in Table 5-1.

Table 5-1. Assumed typical frequency ageing values for the different clock types

Clock Type Typical Frequency Ageing

Caesium Atomic Frequency Standard (Cs) 3*10 -13 1/year

Hydrogen-Maser (HMa) 3*10 -12 1/year

Rubidium Atomic Frequency Standard (Rb) 1*10 -10 1/year

Ultra Stable Crystal Oscillator (OCXO) 5*10 -9 1/year

Figure 5-2 depicts the simulation results of this four clocks.

GALA REF :DATE :

Gala-als-dd-01412-04-2001


Figure 5-2. Physical steering update time of different clock types

The following table (Table 5-2) shows the results in more detail.

Table 5-2 Physical steering update time of different clock types

Necessary physically clock steering after ... yearsNumber ofBits

Range of af0

in seconds Cs HMa Rb OCXO

16 ±0,305*10 -4 1,796 0,567 0,098 0,0139

17 ±0,610*10 -4 2,540 0,803 0,139 0,0197

18 ±0,122*10 -3 3,592 1,136 0,197 0,0278

19 ±0,244*10 -3 5,080 1,606 0,278 0,0193

20 ±0,977*10 -3 7,184 2,272 0,393 0,0556

21 ±0,488*10 -3 10,160 3,213 0,556 0,0787

22 (GPS) ±0,977*10 -3 14,368 4,544 0,787 0,1113

23 ±1,954*10 -3 20,320 6,426 1,113 0,1574

24 ±3,908*10 -3 28,736 9,087 1,574 0,2226

25 ±7,816*10 -3 40,639 12,851 2,226 0,3148

26 ±1,563*10 -2 57,473 18,174 3,148 0,4452

27 ±3,126*10 -2 81,279 25,703 4,452 0,6296

28 ±6,252*10 -2 114,95 36,349 6,296 0,8904

29 ±0,125 162,56 51,405 8,904 1,259

30 ±0,25 229,89 72,698 12,592 1,781

31 ±0,5 325,11 102,81 17,807 2,518

32 ±1,0 459,78 145,40 25,183 3,561

As we can see, we get the following physical steering update time intervals for the 22bits of the a0 parameter used in GPS:

GALA REF :DATE :

Gala-als-dd-01412-04-2001


Cs: 14,4 yearsHMa: 4,5 yearsRb: 9 monthsOCXO: 40 days

This is sufficient for caesium clocks and H-masers, but critical for rubidium clocks andcompletely unacceptable for OCXOs. Please notice that this are results of high end clockversions. For example if we use the frequency ageing value of a standard rubidium clockwith about 3*10-10 1/year, we only get 5-6 months.Thus, if we want e.g. a minimum physical steering update time interval of about 3 years,we need the following number of bits for the a0 parameter:

Cs: 18 bitsHMa: 21 bitsRb: 26 bitsOCXO: 32 bits

• Frequency Offset af 1:In GPS this parameter is realised with 16 bits and a scaling factor of 2-43, which definesthe range of values:

9f1 103,725a −⋅<

and a resolution of 1343 1014,12 −− ⋅= .With that we get for the typical clock types (assumed frequency ageing values see table)the following physical steering update time intervals:

Cs: 12418 yearsHMa: 1242 yearsRb: 37 yearsOCXO: 0,75 years

Please notice that these update time intervals assume that the physical steering processcan synchronise the satellite clocks with the GST without any error. Actually there is stilla little frequency offset error, thus the real update time intervals are smaller. Neverthelesswe can see that the GPS definition of the af1 parameter is completely sufficient forcaesium, H-Maser and rubidium satellite clocks. Only if we want to make the Galileosystem flexible for the possible use of OCXOs in the satellites, the number of bits for af1

should be increased to 19, which corresponds to a time interval of 6 years for an OCXO.

• Frequency Drift af 2:In GPS this parameter is realised with 8 bits and a scaling factor of 2-55, which defines therange of values:

115f2 s103,55a −−⋅<

and a resolution of 117155 s102,78s2 −−−− ⋅= .

With 2

da clock

f2 = we get for the following values for the typical clock types:

Cs: -1-21-1-13 s 104,8 year 101,5 ⋅=⋅

HMa: -1-20-1-12 s 104,8 year 101,5 ⋅=⋅

Rb: -1-18-1-11 s 101,6 year 105,0 ⋅=⋅

OCXO: -1-17-1-9 s 107,9 year 101,5 ⋅=⋅

GALA REF :DATE :

Gala-als-dd-01412-04-2001


We see that the GPS definition is not useful, because all clock types, apart from theOCXO, have lower af2 values as the defined scaling factor. Indeed if we have a look at theGPS navigation message we see that this parameter is permanently set to zero.If we want to define an adequate scaling factor for this parameter, we must orientateourselves on the clock type with the lowest value for the af2 parameter, which is thecaesium clock. With that we get a scaling factor of:

121170 s100,85s2 −−−− ⋅=which can express the value of the caesium clock with sufficient resolution.For the upper limit of af2, we must orientate ourselves on the worst clock type which isthe rubidium clock or the OCXO if we want to use such clocks in the satellites. With Rbstandards we get for the range of values for the parameter af2:

-118159f2 s101,7s 2a −−− ⋅=< ,

or if we want to allow the use of OCXOs:-116153

f2 s101,1s 2a −−− ⋅=<With that we must spend in case of Rb clocks:

2s 2s 2 11

170

159

→=−−

−−

(11 bits plus 1 sign bit)

i.e. 12 bits for the parameter, or 18 bits if we want to allow the use of OCXOs:

2s 2s 2 17

170

153

→=−−

−−

(17 bits plus 1 sign bit)

In addition to the already described clock parameters (af0, af1, af2) and the clock reference timetoc, a parameter for the differential group delay TGD and a parameter which indicates changesof the clock data set are needed. For the latter task, GPS transmits in the navigation message a10 bit long parameter IODC ("Issue Of Data Clock"). In Galileo it is discussed to use a newIOD parameter (9 bit) which will include also the SNF index (3 bit), adopted to indicate eachchange in the satellite navigation frame.Coming back to the group delay, note that this parameter may be considered not as a "real"clock parameter. Nevertheless in the navigation message this information must be included.Since different frequencies will be adopted by Galileo, different group delay parameters mustbe defined. However, it is not necessary to transmit all group delay parameters in eachnavigation message. Only one parameter is, in fact, sufficient, the one which describes thegroup delay of that frequency band where the parameter (navigation message) was sent. Inother words in the navigation message only one parameter is defined for the group delay (asin GPS), but the value of this parameter depends on the adopted frequency band.

In Conclusion Table 5-3 summarises the necessary clock correction parameters which mustbe broadcast within the navigation message. Such table shows the realisation in GPS and theproposed realisation in Galileo with respect to the number of bits and the scale factor. Thesevalues are related to navigation satellites with caesium, H-maser or rubidium clocks.

Table 5-3 Galileo clock correction parameters

Number of bits Scale factor, LSBParameter

proposed for Galileo GPS proposed for Galileo GPS

Units

tOC 16 16 24 24 s

TGD 8 8 2-31 2-31 s

af2 12 8 2-70 2-55 s/s2

af1 16 16 2-43 2-43 s/s

af0 26 22 2-31 2-31 s

GALA REF :DATE :

Gala-als-dd-01412-04-2001


Note that in case we additionally want to allow the use of OCXOs in the satellites, theproposed specifications (reported in Table 5-3) have to be adapted as follows:

af0: 32 bitsaf1: 19 bitsaf2: 18 bits

When considering the almanac data, since they contain a subset of clock and ephemerisinformation with reduced precision, it is possible to describe the clock parameters with lessbits than those just suggested. GPS truncates the lowest 5 bits of the af1 and the lowest 11 bitsof the af0 parameter. In the following table (Table 5-4) the specification of these parametersfor the Galileo almanac is proposed in the same manner and the same precision as in GPS.

Table 5-4. Galileo almanac clock correction parameters

Number of bits Scale factor, LSBParameter

proposed for Galileo GPS proposed for Galileo GPS

Units

WNa 8 8 1 1 weeks

t0a 8 8 212 212 s

af1 11 11 2-38 2-38 s/s

af0 15 11 2-20 2-20 s

where t0a is the reference time and WNa the reference week of the almanac data. With that theclock correction term can be calculated as:

( ) ( )a0asystemk

kf1f0sv

WN-WN604800 plus seconds 604800 modulo tttwhere

taat

⋅−=

⋅+≅∆

5.2 ADDITIONAL DATA TO ENSURE A POSSIBLE INTEROPERABILITYWITH OTHER NAVIGATION SYSTEMS

5.2.1 GST steering to UTCUTC is the ultimate reference time computed at the BIPM by about 50 laboratories from allover the world including approximately 200 clocks. Due to the choice of optimising its long-term stability and also for practical reasons, UTC exists only "after the fact". Currently, theresults are available with a delay of one month. Therefore, many local approximaterealisations of UTC are created and also GST – when being steered towards UTC – will be amean for disseminating UTC in almost real-time around the world.

Additionally, a recommendation of CCTF (at that time CCDS) requires that:

the reference times (modulo 1 s) of satellite navigation systems withglobal coverage have to be synchronised as closely as possible toUTC.

GALA REF :DATE :

Gala-als-dd-01412-04-2001


In a recent recommendation of 1999, the CCTF recommends:

all global navigation satellite systems to be designed so that it ispossible to use their signals for time and frequency comparisons.

The existence of a reference time scale with easy access, being accurate and of low cost, isrequested by telecommunication institutions, scientific laboratories, and astronomicalobservatories, industries that synchronise their computers, banks, watch sellers, transportationsystems etc. This clearly asks for a close conformity with UTC, and GST must ensure the bestmetrological qualities in any time interval when UTC is not known. This is a reason forsuggesting that the GST should be optimised over an integration interval of about 10 - 20days.

In addition, there are recommendations of standardisation organisations like the ITU [RD 10],the CIPM [RD 13], ISO [RD 11], and military NATO [RD 12], explicitly asking to use UTCas reference. Moreover, for practical reasons, it seems surely easier to maintain the agreementwith an existing and well disseminated time scale rather than creating a complete independentone. For sake of reliability and safety, it could be convenient to use also another intermediatetime scale chosen among the real-time approximations of UTC against which the GST couldbe more frequently compared [the same role as UTC(USNO) in GPS].

As mentioned above, UTC relies on a large number of ultra-stable clocks hosted at timinglabs. UTC itself is heavily weighted towards UTC(USNO). From this follows that if Galileohas ambitions to be a stand-alone system then it has to develop its own stand-alone timesource rather than relying on what is effectively UTC(USNO). The Galileo timingindependence would require the establishment of a large body of good clocks in Europe.

Galileo must make use of an "external" or "internal" UTC source. This is usually a wellestablished timing lab which realises a local UTC(k) scale, where k is the designation of thetiming lab. There are both technical and institutional issues when trying to connect UTC(k) tothe outside world, and these need to be resolved. The preliminary view is that good caesiumclocks will be needed, although another view is that a clock ensemble could be used toachieve the requirements. H-masers might be the best approach to the connection betweenUTC(k) and GST.

The necessary transmitted information for the user (receiver) to calculate the current UTCtime from the transmitted Galileo System Time can be identically realised as in GPS, whichdefines the following types of parameters in the navigation message:

a) the parameters needed to relate the system time to UTC, and

b) the parameters needed to inform the user regarding the scheduled future or recent past(relative to the navigation message upload) value of the delta time due to the leapseconds (∆tLSF), together with the week number (WNLSF) and the day number (DN) atthe end of which the leap second becomes effective.

“Day one” is the first day relative to the end/start of week, and the WNLSF value willconsist of the 8 LSBs of the full week number. The user must account for thetruncated nature of this parameter as well as for the truncation of WN, WNt andWNLSF due to the roll-over of the full week number. The absolute value of thedifference between the untruncated WN and WNLSF values will not exceed 127.

For this purpose GPS defines the following parameters in the navigation message:

GALA REF :DATE :

Gala-als-dd-01412-04-2001


a) A0: constant term (in seconds) of polynomial describing the offset ∆tUTC between GPSand UTC time scales at the time tE, that is the GPS time as estimated by the user onthe basis of correcting tSV for the satellite clock offset and relativity terms as well asfor ionospheric and Select Availability (dither) effects. [32-bit];

b) A1: rate of change (in seconds per second) of the offset ∆tUTC between GPS and UTCtime scales [24-bit];

c) ∆tLS: is the offset due to the integer number of seconds between GPS time and UTC[8-bit];

d) t0t: time of validity of the UTC offset parameters [8-bit];e) WNt: UTC reference week number [8-bit];f) WNLSF: week number for the leap second adjustment [8-bit];g) DN: day number for the leap second adjustment [8-bit];h) ∆tLSF: is the offset due to the introduction of a leap second at WNLSF and DN [8-bit];

Therefore altogether 104 bits are required in the navigation message to describe GPS timewith respect to UTC. With these parameters, in fact, the difference between UTC and GPStime may be computed as:

( )( )∆ ∆t t A A t t WN WNUTC LS E t t= + + ⋅ − + ⋅ −0 1 0 604800 [s]

and UTC time can be calculated from tE (GPS time, estimated) as:

( ) t t tUTC E UTC= − ∆ modulo 86400 seconds

The same definitions may be adopted for the new Galileo System. As a consequence, thedifference between UTC and GST may be broadcast within the navigation message adopting104 bits and 8 parameters. The validity time of such parameters is the same of the GPS one.

5.2.2 Interoperability and compatibility with GPSTo satisfy the Galileo requirement of being independent from any other navigation system,the GST has to be independent too. In GPS, the corresponding time scale is obtained from theMaster Kalman filter, where both the satellite orbits and the corrections for the satellite andground clocks are obtained. Thus, Galileo is proposed to follow this approach and to define itsown time scale.

For interoperability and compatibility purposes, a close agreement with GPS time should bestressed. Considering the fact that GST will be steered to UTC (see above), and thus behandled in the same manner as GPS time, the close agreement can be achieved more or less"automatically".

A difference will exist in a first approach, but some efforts can be made to minimise it. Toallow the user to use both systems, the estimated time difference between both systems mustbe available to him. Therefore, in situations where only a limited number of satellites isvisible (urban areas), the user can benefit from an increased number of satellites, as the"other" system may be applied too.

To make the information of the time difference between the Galileo and the GPS system timeavailable to the user, this time difference must be calculated from the master control stations

GALA REF :DATE :

Gala-als-dd-01412-04-2001


of Galileo and GPS and then it must be transmitted in the navigation message. Similar to thetransmitted relation between UTC and Galileo (see previous section) the following parametershave to be defined in the navigation message:

a) A0: constant term (in seconds) of polynomial describing the offset ∆tsystems betweenthe Galileo and the GPS system time scales at the time tGalileo, which is the Galileotime estimated by the user [32-bit];

b) A1: rate of change (in seconds per second) of the offset ∆tsystems between Galileo andGPS time scales [24-bit];

c) t0: time of validity of the offset parameters [8-bit];d) WN0: reference week number [8-bit];

Therefore altogether 72 bits are required in the navigation message to describe therelationship between GPS and GST. With this 4 parameters, in fact, the difference betweenthe Galileo and GPS time scale may be computed as:

( )( ) [s] 604800 0010,, WNWNttAAttt GalileoGPSSystemGalileoSystemsystems −⋅+−⋅+=−=∆

A not really alternative for the transmission of the above parameters is, that the usercalculates the time difference itself by using the time offset information between the Galileosystem time and UTC(Europe) included in the Galileo navigation message, and the offsetbetween the GPS system time and UTC(USNO) included in the GPS navigation message. Areceiver which want to use both systems automatically receives both navigation messages.With this information the user could calculate:

( ) ( )444 3444 21

zero! set to bemust it thusUnknown,)()(,,

,)(,)(

,,

USNOUTCEuropeUTCGPSUTCGalileoUTC

GPSUTCUSNOUTCGalileoUTCEuropeUTC

GPSSystemGalileoSystemsystems

tttt

tttt

ttt

−+∆−∆=

∆+−∆+=

−=∆

The great drawback of this second method is the bad accuracy of the time difference betweenthe two system times. The reasons for that are the following additional errors which areincluded in the time difference result:

♦ The error of the UTC(Europe) estimation from the Galileo system time by usingthe correction polynomial.

♦ The error of the UTC(USNO) estimation from the GPS system time by using thecorrection polynomial.

♦ The error on account of the difference between UTC(USNO) and UTC(Europe).

Thus, this alternative without additional parameters in the navigation message is notpracticable.

5.3 TIME CORRECTION PARAMETERS SUMMARY

Summarising, it can be seen that no significant change with regard to the GPS solution isforeseen in the area of the clock correction and UTC parameters. Changes are proposed onlyin following points:

GALA REF :DATE :

Gala-als-dd-01412-04-2001


1. Adaptation of the number of bits and the scale factor of the clock correction parametersto ensure the proper work of Galileo with rubidium, H-maser and caesium clocksonboard the satellites.

2. In Galileo the use of a so called IOD parameter (9 bit) which includes also the SNF index(3 bit) is proposed. With that an IODC as in GPS is not necessary.

3. No changes with regard to the GPS solution are foreseen for the UTC to Galileo SystemTime connection, but additionally parameters which describe the connection between theGalileo and GPS system time are added.

Table 5-5 summarises all the necessary clock parameters for Galileo.

Table 5-5. Galileo clock parameters summary

Parameter Number of bits Scale factor, LSB Units

1. Ephemeris clock correction parameters:

tOC 16 24 s

TGD 8 2-31 s

af2 12 2-70 s/s2

af1 16 2-43 s/s

af0 26 2-31 s

IOD 6 (+3 SNF) 1 -

2. Almanac clock correction parameters:

t0a 8 212 saf1 11 2-38 s/s

af0 15 2-20 s

WNa 8 1 weeks

3. Parameters for the GST - UTC connection:

A1 24 2-50 s/sA0 32 2-30 s

∆tLS 8 1 s

t0t 8 212 s

WNt 8 1 weeks

WNLSF 8 1 weeksDN 8 1 days

∆tLSF 8 1 s

4. Parameters for the Galileo and GPS system time connection:

A1 24 2-50 s/sA0 32 2-30 s

t0 8 212 s

WN0 8 1 weeks

Please note that the almanac parameters t0a and WNa do not only apply to the clock correctionparameters, but also to the whole almanac data. Analogously, the IOD is not only a parameterfor the clock correction, but also for the ephemeris data.

GALA REF :DATE :

Gala-als-dd-01412-04-2001


For what concern the validity time of the analysed parameters, clock corrections have a fewhours validity interval, whilst the parameters in the almanac have several days of validity.The connection between GST and UTC or between GST and GPS system time, has a variablevalidity time dependent on the application. In GPS 6 days curve fits are used.

GALA REF :DATE :

Gala-als-dd-01412-04-2001


6 DIFFERENTIAL CORRECTIONS

Differential corrections should enhance standalone Galileo accuracy reducing (or removing)common (i.e. correlated) errors occurred in the signal propagation delay as detected by two(or more) users viewing the same satellite.

Since minor improvements are possible with additional airborne augmentations, in order toguarantee more significant enhancements, Galileo augmentations must be ground-based. Withsuch approach, a truth reference is, therefore, available and the system corrections can bebroadcast to all users.In their most fundamental form differential corrections consist of:

1. a ground calibrated receiver which measures the time-biases in the Galileosatellite signals,

2. a transmitter (not necessary at Galileo frequencies) which relays thecorrections to an appropriately equipped user.

The information data are constituted by the differences obtained comparing simultaneous ornear–simultaneous measurements performed by a reference station (located in a knownposition), with the expected values (based on the “a priori” known location). Such correctionsare then transmitted in real-time(11) to the users over the area of interest.Differential corrections can be used to cover a local area with high accuracy (theimplementation is generally referred to as Local Area Augmentation) or to cover a wider areawith somewhat reduced accuracy (Wide Area Augmentation). The latter approach may besatellite based in order to easily broadcast the differential correction signal (data and possiblyan additional navigation signal) over the visibility area of a geo-synchronous satellite. Thisimplementation is the basis of the GPS/Glonass overlay systems currently in development byEurope, the United States and Japan.

6.1 GENERAL DESCRIPTION

A number of schemes may be identified to accomplish differential corrections. Hereaftersome of them are discussed and contrasted. Position coordinate corrections or pseudorangecorrections can be determined in the case of code-based techniques. Both real time and postprocessing computation can be performed.To provide sub-meter accuracy, differential techniques that utilise phase information of thenavigation signal carrier frequency have also been developed (carrier–based techniques).Such techniques are based on interferometric measurements of the satellite carrier frequency.Extremely high accuracy (20 cm in dynamic applications and millimeter level for staticapplications) can be achieved by processing the received satellite signal Doppler frequencies.

Whatever solution is chosen, the geometry for the differential correction technique may bereconducted to the Figure 6-1 scenario, where S(true, t) is the true satellite position at the timet, S(assumed, t + ∆t) is the assumed satellite position at the time t + ∆t, the position errorbeing d. A distance δ separates the reference station and the user location.

(11) Some geodesy techniques may use non-real time data in post-processing of themeasurements.

GALA REF :DATE :

Gala-als-dd-01412-04-2001


The errors (position and time) may result from the uncertainties in the satellite ephemeris orclock offset estimation. Propagation biases(12) can always be reduced to an offset in themeasured pseudoranges (corresponding to the ∆r or ∆r' , that are the difference between thetrue and the assumed range) and therefore treated as ephemeris or clocks offsets.

Following the derivation given in [RD 7], at the reference station the time at which the signalis received and the time at which the signal is expected are:

tcr

t receivedsignal +=,

ttc

rrt ectedsignal ∆++∆+=exp,

(12) Care must be exercised when applying ionospheric corrections to single frequencyreceivers using a model, since different receivers may use different models. Differentialcorrections to pseudo-range, not including ionospheric corrections, should be used (and theuser will not apply any ionospheric model correction, but use just the received differentialcorrections). The same applies to tropospheric delays if some model (based, for instance, onthe elevation angle) is introduced in the processing.

GALA REF :DATE :

Gala-als-dd-01412-04-2001


Figure 6-1. Differential corrections geometry (redraw from [RD 7])

the total time error being tcr

∆+∆

. For the user, at a distance δ from the reference point, the

time error will be: tcr

∆+∆ '

.

Therefore, the range error introduced at the user location by correcting his measurements withthe data gathered at the reference location will be:

rre ′∆−∆=and:

( ) ( )αεεααεαα cossincossinsinsinsin ⋅+⋅−⋅=−⋅−⋅≅ ddde

Assuming ε small, sin ε ≈ 0 and cos ε ≈ 1; therefore, the equation reduces to:

αε cos⋅⋅≅ de

The value of ε depends upon the distance δ between the reference and user locations, and for

our scope can be bounded to be: rδ

ε ≤ , which leads to: αδ

cos⋅⋅

≤r

de . The worst case

will be for α = 0, since cos α = 1 (along-track offset), and in this case: r

de

δ⋅≤ .

For δ = 100 km and d = 1 km, assuming r ~23000 km, we get: | e | ≤ 4,35 m, and even withthe typical errors caused when SA was in use (i.e. 30-100 m) it was feasible to reach a meteraccuracy over distances of hundreds of km.

The pseudo-range correction at the reference point is (∆r + c·∆t). It is obtained by taking thedifference between the expected (computed, being known the position of the satellite and thereference site) and measured reception times. This difference will include all propagationdelays, and its value (for each visible satellite) will be broadcast to the users.The ranging error (once the corrections are applied using this technique) is (approximately(13))linearly proportional to the distance δ from the reference station.

In case geographic(14) corrections (∆x, ∆y and ∆z, or ∆_latitude, ∆_longitude and ∆_height)are broadcast, the geometry must be taken into account. An error in position is related to anerror in range by the Position Dilution of Precision (PDOP). The final error will be greateralthough the effect is partially compensated by the fact that, in any case, the user will adoptthe pseudo-ranges to compute its geographical position, and in doing this the same PDOPfactor is introduced.The PDOP, furthermore, is dependent (for a given geometry) upon the reciprocal user andsatellites positions. Moving far away from the reference location the geometry may changeconsiderably, and therefore the PDOP will be different for the user and the reference station.

(13) Since the same propagation conditions may not exist along the two paths (r and r') due todifferent atmospheric (ionosphere and troposphere) conditions. This term will generallyproduce an additional increase with the distance δ.(14) These are ECEF coordinates (Earth-Centered, Earth-Fixed).

GALA REF :DATE :

Gala-als-dd-01412-04-2001


As a consequence, transmitting the geographical corrections does not allow the user to takeinto account for this difference, and therefore a larger error will result from this type ofapproach.Moreover, a geographic correction will compel the user to apply the same navigation solutionto its data processing for the correction to be effective. Therefore, users working withdifferent navigation solutions ("best-4-in-view" or "all-in-view") or using different satellitesbecause of the different geometry (over a wide area) or different selection criteria will not beable to use the corrections effectively.Consequently, whenever possible it is suggested to prefer pseudo-range corrections togeographical ones.

Whatever approach is used, the corrections, to be effective, must be synchronous: thepropagation conditions may change with time, the corrections must be distributed and appliedin real-time (non real-time users require a reasonably accurate time-tagging of the data).

The basic concept, when considering the code-based pseudorange measurements for Galileo,is that the reference station makes code-based pseudorange measurements, just as anystandard Galileo receiver, but because the monitoring station position is accurately known, itis possible to determine the “biases” in the measurements. The mobile users should be in lineof sight of the reference station. For each satellite in view of the monitoring station, the time-biases are computed by differencing the pseudorange measurement and the satellite-to-reference station geometric range.Note that these techniques requires that all receivers make pseudorange to the same set ofsatellites to ensure that common errors are experienced.The biases include errors incurred in the pseudorange measurement process (e.g. commonionospheric and tropospheric delay, common receivers noise, etc.). Differential corrections,however, cannot take into account for multipath errors, receiver errors, or other randomnoises that are not common in the receivers.

For a general satellite navigation system, not only related to Galileo, the major pseudorangeerror sources are listed hereafter:

1. Satellite clock instabilities2. Ephemeris prediction errors3. Satellite perturbations4. Ionospheric delay5. Tropospheric delay6. Man-made degradation (such as GPS selected availability)7. Other minor sources (thermal radiation, thruster performance, etc)8. Receiver noise and resolution9. Multipath

The errors from 1 to 7 are not dependent from the final user, thus receiving drasticimprovements from the correction available by the differential status. The remaining twosources, as already stated, cannot be compensated by such corrections.

Satellite clock errors: differences between the actual satellite clock time and the predictedone adopting the satellite data. The oscillator, which times the satellitesignals, is free-running; the Galileo ground control station monitors itand establishes corrections which are sent up to the satellite to set thedata message. The user reads the data and adjusts the signal timingaccordingly.

GALA REF :DATE :

Gala-als-dd-01412-04-2001


Ephemeris errors: differences between the actual satellite location and the locationpredicted by the satellite orbital data. Normally such contribution isquite small (less than 3m-one sigma) in the operational system.

Ionospheric delays: signal propagation group delay, which can be as much as 20-30 m (onesigma) during the day to 3-6 m (one sigma) at night.

Tropospheric delays: signal propagation delay caused by the lower atmosphere. While thedelays are as much as 30 m (one sigma) at low satellite elevationangles, they are quite consistent and modellable. Variation in the indexof refraction can cause signal delay differences between referencestation and user of 1-3 m (one sigma) for low-lying satellites.

Whatever is the cause, the differences in the delays translate to differences in pseudorangemeasurement errors with the effect on the position solution also being a function of thedilutions of precision. To translate the Galileo range accuracy into navigation accuracy, basicaccuracy of Galileo may be viewed as the product of the errors in ranging to the satellites andthe diluting effects of the geometry. A simplified relationship may be adopted for a first orderevaluation:

(User position error) = (geometric dilution) * (user equivalent ranging error)

where geometric dilution is a class of multipliers called DOP (Dilution Of Precision).Using, for example, HDOP (Horizontal DOP), the differential pseudorange error can beconverted to two-dimensional (horizontal) radial error statistics. The typical differentialpseudorange of 1m results in horizontal position errors at approximately the 95 percentconfidence level of about (2m* HDOP). As an example, if the satellite constellation providesan average HDOP of 1-1.5, this means that position errors will be about 2-3m.These two effects are separated: reducing the ranging error does not affect the geometricdilution effects. While the ranging errors typically vary by a factor of two or three, thegeometric dilutions may vary by a factor of ten or more.

Note that differential corrections do not improve the geometric dilution effects. Nonetheless,they materially improve the final accuracy reducing the ranging errors for both the normaloperation and when an artificial degradation is used.

Even when differential corrections are adopted, there may be circumstances in which theimprovement is still not enough. As examples: the satellite constellation offers very poorgeometry, local conditions may have terrain or man made features which further reduce theavailability of satellites. Last but not least the satellite outages must also be considered. Insuch cases, differential correction are not designed to compensate for DOP degradation. Theuse of pseudolites (that broadcast also differential corrections) offer a valid alternative andsignificant advantages.

Last but not least, some of the pseudorange errors sources are spatially correlated, so that theposition solutions of users further away from the reference station will be less accurate thanthose close to the monitoring station.Consequently, as the distance between the users and the monitor station increases, rangedecorrelation occurs, and accuracy degrades. The errors increase because projection of theephemeris error onto the user-satellite line of sight is no longer the same as the monitorstation-satellite line of sight. In addition, if the two receivers are widely separated, the lines ofsight through the ionosphere are also different, resulting in differences in the ionosphericdelay observed. A similar, but smaller effect occur for the tropospheric delay.

GALA REF :DATE :

Gala-als-dd-01412-04-2001


Briefly, the error sources that cause the correction to decorrelate spatially are: errors in theGalileo ephemeris data, ionospheric and tropospheric refraction.

Beyond a separation distance of about 100 km, a range error correction is not sufficientlyaccurate to realise the full potential of differential corrections. In such conditions, instead ofcalculating a scalar range error correction for each satellite, as done conventionally, a vectorof error corrections comprising a three-dimensional ephemeris error and clock bias for eachsatellite, plus ionospheric time delay parameters can be adopted.

Taking into account the contributions and the analysis performed in the frame of other GALAWPs, an absolute pseudorange error budget (as a function of the elevation angle) is describedin (see also GALA-ASPI-DD036 document for further detail).

Table 6-1. A possible navigation error budget (single frequency) without any correction.

Total error budgetElevation

angleSatellite Clock stability

+Ephemeris prediction errorIonospheric

delayTropospheric

delayReceiver with

high multipathCalibration andother sources

One-sigma error(meters)

5 0.65 11.74 2.49 3.30 0.1 12.4610 0.65 9.24 1.33 1.71 0.1 9.5115 0.65 7.47 0.91 1.16 0.1 7.6420 0.65 6.21 0.70 0.86 0.1 6.3425 0.65 5.30 0.57 0.71 0.1 5.4130 0.65 4.62 0.48 0.61 0.1 4.7340 0.65 3.74 0.38 0.46 0.1 3.8350 0.65 3.18 0.32 0.38 0.1 3.2860 0.65 2.84 0.28 0.33 0.1 2.9570 0.65 2.63 0.26 0.32 0.1 2.7480 0.65 2.52 0.25 0.31 0.1 2.6390 0.65 2.48 0.24 0.30 0.1 2.59

6.2 CONTINENTAL COVERAGE

To realise a continental differential corrections, several reference stations (widely dispersed)must be used. These ground stations receive and process signals broadcast by the Galileosatellites, forwarding their data to processing sites (wide area master stations) where the rawmeasurements are processed to determine the differential corrections and residual errors foreach monitored satellite.

Since the satellite clock timing error appears as a bias on the pseudorange measurements,such contribution is totally removed by differential corrections (if corrections are applied atthe time they are calculated). The satellite position error, instead, does not cancel completelywith differential navigation when the user and reference station are separated. The satelliteposition errors will not, therefore, cancel completely unless the user and reference station areclose to each other.

In order to highlight the spatial degradation of the various contribution in continentalapplication only a given geometrical configuration of the mobile user (with respect to thesatellite in view), is considered for simplicity (i.e. tables refer only to a specific value of theelevation angle). Analogous consideration may be obtained for the other elevation angles. Thefollowing table (Table 6-2) shows how the error budget reported in the previous Table 6-1 iscorrected when continental differential correction are applied (only the case related to a 10°elevation angle is reported). When the mobile user is close (both in distance and in altitude) tothe reference station the corrections are ideally perfect.

Table 6-2. Residual UERE budget (spatial degradation)

One-sigma error (meters)

GALA REF :DATE :

Gala-als-dd-01412-04-2001


Error source(10° ELV angle)

0 km 180km 920km 1850km 3700km

Ephemeris andclock errors

0(ideal case)

0.19 1.04 2.1 4.2

residualionospheric delay

0(ideal case)

2.1 4.85 6.4 8.2

residualtropospheric delay

0(ideal case)

1.82 1.82 1.82 1.82

Receiver noise withmultipath

1.71 1.71 1.71 1.71 1.71

Calibration siteresidual

0.1 0.1 0.1 0.1 0.1

residual UERE(RMS)

1.71 3.27 5.55 7.18 9.54

As Table 6-2 shows the accuracy of the differential navigation solution is strongly dependenton the spatial decorrelation of the ionosphere. When reference station and vehicle areseparated geographically, the satellite signals are passing through different areas of theionosphere and so will experience different group delays. It has been demonstrated thationospheric delays have a correlation coefficient of 0.7 over 2000 km in latitude and over3000km in longitude at northern mid latitudes when data are taken at common local times.The large diurnal change in the ionosphere will introduce a much larger variation overlongitude for the data sets used in the differential correction process as the data are taken atthe same UTC time and so at different local time.As shown in Section 4, the effect of the ionosphere on radio signals is proportional to thenumber of free electrons along the signal path (the total electron content-TEC). The groupdelay introduced on satellite signals is proportional to the vertical TEC at the vehicle’slocation, scaled by an obliquity factor to account for slanted paths through the ionosphere forlow-elevation satellites. Such ionospheric obliquity factor varies between a value of 1(satellite at zenith) and a value of 3 (satellite over the horizon).The vertical electron content in the mid-latitude regions is typically around 50 TECU (oneTECU is equivalent to 1016 electrons/m2). On occasion, it can reach values as large as 100TECU during periods of high solar activity. Modelling the group delay caused by ionosphere(adopting eq. 1 in Chapter 4) and using a vertical TEC of 50 TECU, the ionosphere groupdelay will vary between 8m and 25m depending on the satellite elevation angle.For a single frequency receiver the ionospheric model which is broadcast in the navigationmessage helps in modelling the values. The Klobuchar model allows user to compensateapproximately 50%RMS of the total delay. This will typically result in a residual ionosphericdelay of about 8m. Adopting updated ionospheric model, the ionospheric delay can further bereduced.

The tropospheric delay can typically be described giving the mean surface refractivity, thevehicle’s altitude, the satellite elevation angle and the tropospheric height (6870m). Since thetropospheric delay is a function of local humidity, temperature and altitude, differentialcorrections are ineffective for compensating tropospheric errors outsides local areas. This iswhy Table 6-2 reports the same value allocated for absolute navigation (see previous Table6-1). Local modelling of tropospheric effects may also be adopted in order to reduce thisdegradation.

The user segment errors are introduced at the user’s receiver and are, therefore, unaffected bydifferential corrections. In the case of GPS with C/A-code receiver, the noise introduced bythe code-tracking loops is generally on the order of 9m this can be significantly reduced bythe use of filtering techniques, such as a Kalman filter. For differential corrections it isessential to reduce the receiver noise by filtering to improve the navigation accuracy. Byusing a Kalman filter, it is possible to reduce the effective receiver noise to within 1m(1sigma) or lower.

GALA REF :DATE :

Gala-als-dd-01412-04-2001


Multipath errors are introduced at the receiver from reflected navigation signals received bythe antenna. These vary depending on the types of reflective surfaces around the vehicle (e.g.water, concrete, buildings) and the type of antenna used. The effect of multipath can bereduced significantly through the use of an antenna that will reject reflected signals receivedfrom directions below the local horizon. With a specific designed antenna, it is possible toreduce the multipath errors to insignificant levels.

6.2.1 Fast and Slow correctionsSince now, only the spatial decorrelation has been considered. Table 6-2, in fact, shows theresidual error budget in the case the differential correction are applied at the same time theyhave been calculated. Once adopted these corrections, the residual major contributions to thefinal UERE error are, obviously, multipath and receiver noise. Corrections, however,decorrelate also with time. Furthermore, there are quickly varying errors and slowly varyingones.In continental scenarios, in order to optimise the broadcasting strategy of these corrections,the fast ones may be broadcast rapidly to account for quickly varying errors. Long-termcorrections, instead, may be devoted to more slowly varying errors, such as the satellitelocation. These type of errors are also valid over the entire coverage area (in the case they aresent as three-dimensional corrections to each satellite position). This strategy greatlycompresses the required data capacity because the fast corrections (which age quickly) arevalid over the entire coverage area. In addition corrections that decorrelate spatially do notneed to be refreshed frequently. In short, vector corrections constitute a data compressionscheme for differential correction that is to be used over continental areas.

The fast corrections messages (i.e. the quickly varying component) must be sent for eachsatellite much more frequently than any other message (except for integrity), but they do notdecorrelate spatially. Consequently, a single very short message suffices even for the entirefootprint of a satellite. Fast corrections consists of a term to be added directly to measuredpseudorange.

The corrections specific for ionospheric effects may be sent for a grid of locations over thedesired coverage area, because these errors do vary spatially. However the requiredthroughput, for ionospheric corrections is manageable because they vary slowly in time.

As described, for each Galileo satellite the continental differential information messageshould contain separate corrections for the quickly varying component of the pseudorangeerror and the slowly varying component of this pseudorange error. It is assumed thationospheric information are already broadcast within the navigation message.The entire message stream, however, must carry corrections for all the satellite in theconstellation in order to assure the continental coverage.

6.2.2 Validity time and update rateEphemeris errors present a slowly variation in time, therefore they do not impact the updatetime. Ephemeris errors have been observed to have variations with time constant on the orderof 30 min.Since in Galileo the introduction of an artificial degradation is not envisaged, the drivercontribution for the update time is the ionospheric behaviour. Its nominal update interval isbetween 150 s and 300 s , depending on ionospheric activities.Time variation of the tropospheric effects are not considered in this context since incontinental coverage their spatial decorrelation is not compensated.

GALA REF :DATE :

Gala-als-dd-01412-04-2001


For what concern the clocks, current time standards onboard GPS satellites have beenobserved to produce constant variations (at a meter level accuracy) after several minutes.Same assumptions may be addressed for Galileo clocks, although the proposed Rubidiumreferences will request for a more frequent update rate (the final figure depends on the finalstability the considered clocks will perform).In conclusion, the fast corrections for the continental differential service present a nominalvalidity time in the order of the minutes and the suggested update interval is in the order oftwo minutes.

6.3 LOCAL DIFFERENTIAL CORRECTIONS

The aim of local corrections is to give a further improvement to the position accuracy takinginto account also for those errors that the previous approach does not compensate. The scalarpseudo-range correction technique is generally adopted in such cases. As a consequence, it isnot possible to distinguish the various contributions and to assign them different updateintervals (although, also in this case, it exists a quickly and a slowly varying component of thepseudorange error).

Furthermore, the pseudorange differential corrections already contains information onionospheric and tropospheric corrections. Therefore, the user receiver algorithms must applythe usual ephemeris and satellite clock correction terms in the satellite data, but must notapply any ionospheric or tropospheric models. In this manner the problem of potentiallydifferent models being used by user and reference station and the possibility to correct twicethe same error is avoided.

If local differential corrections are applied to the same error budget of the previous Table 6-1(again for simplicity only the 10° elevation angle case is considered) the ideal residual errorsare reported in Table 6-3 (which shows the same values reported in the first two columns ofTable 6-2). As for continental corrections, in fact, also in the case of the pseudorangecorrection satellite clock errors can be completely compensated by differential operation, aslong as both reference and user receivers employ the same satellite data. Ephemeris errors,unless they are quite large (say 30m or more), are similarly compensated by differentialoperation. Furthermore, local differential corrections are specifically design to improvelocally the performances disregarding the fact to serve far away users.

Table 6-3. UERE error budget (user close to reference)

Error source(10° ELV angle)

One-sigma error(meters)

Ephemeris and clock errors

0(ideal case)

Ionospheric delay(if not modelled)

0(ideal case)

Tropospheric delay(if not modelled)

0(ideal case)

Receiver noise with multipath 1.71Calibration site residual 0.1residual UERE (RMS) 1.71

Tropospheric and ionospheric delays are only expected to be common when both receiversare at the same altitude and in a relatively close proximity. For user near the reference station,the respective signal paths to the satellites are close enough that the compensation forionospheric and tropospheric errors is almost complete. As the user-reference stationseparation is increased, the different ionospheric and tropospheric paths to the satellites canbe far enough apart that the atmospheric inhomogeneities cause the delays to differ

GALA REF :DATE :

Gala-als-dd-01412-04-2001


somewhat. To the extent they differ, they constitute an error in the differential Galileomeasurements. This type of error will be greater at larger user-reference station separations.

Note, also, that atmospheric models degrade at low satellite elevations, when the model canbe off by a factor of two at times. The ionospheric delay is the least well-behaved at lowsatellite elevations. However, the profile of the ionospheric delay over time can be observedby plotting the difference between integrated range-rate from the carrier and pseudorangefrom the code. This difference can be compared to the modelled ionospheric delay todetermine whether the modelled profile matches the measured profile.Receiver inter-channel biases, receiver noise, receiver quantisation errors, local multipatheffects, instead, are other error sources in the positioning process which are not correlated andwhich cannot be compensated with differential corrections. Accurate calibration of thereceivers can reduce calibration errors to less than 1m (typically to about 0.2m). The majorunmodelled error source, however, is code (pseudorange) multipath, which can haveamplitude and periods that are close to what might was expected when SA was still in use.Adopting correct differential correction and assuming that the separation between userreceiver and reference station is negligible, all the biased contributions can be compensated.

The residual pseudorange errors that are related to the user receiver and the user environment(i.e. the receiver noise and the multipath error delay) may assume very high values withrespect to the other contributions, thus driving the final achievable accuracy. Therefore, invery degraded environmental conditions (i.e. with high multipath), a relative advantage couldbe taken also with a relaxed update rate of the differential corrections, because the clock andatmospheric errors have a relative minor impact on the overall accuracy (already degraded bythe user environment).

Also in case of local corrections, nevertheless, a good antenna environment will reducemultipath errors. In addition carrier multipath is negligible small in the contest of differentialnavigation application, so carrier filtering of the code will attenuate the effect of multipath (aswell as code noise) considerably.Note that the code carrier filtering would not be possible if the timing for both code andcarrier transmitted from the Galileo satellites were not derived from a single master frequencygenerator.The receiver noise can be dropped off (about an order of magnitude) with filtering techniques.Therefore, lower UERE values may be obtained depending on the receiver design.

Finally, the user may be able to mathematically model which are the systematic effects in thevariation behaviour of the atmosphere with respect to the one present at the reference station.In such a way only the really random effects remain uncorrected. For instance, in case oftroposphere, only the wet component (10% contribution) remains unmodelled. This impliesthat the final UERE reported in the previous tables may be further reduces to sub-meter level.

6.3.1 Local differential correction spatial validityAs previously anticipated, the correlation in the delays at two receivers due to the troposphereusually decrease more rapidly than for delays caused by the ionosphere. Tropospheric delays,are only expected to be common when both receivers are at the same altitude and in a veryclose proximity. Beyond a separation distance of a few decades of kilometers the troposphericeffects in the two sites are completely uncorrelated and therefore they cannot be corrected bydifferential techniques (in “good” atmospheric conditions the total decorrelation may bereached even at a distance of about 100 km although normally this value is much lower).At a receiver separation of 100 km, in fact, the surface refractivities are completelyuncorrelated and, thus, the difference in tropospheric delays are uncorrelated. This is because

GALA REF :DATE :

Gala-als-dd-01412-04-2001


tropospheric delay is a function of local humidity, temperature and altitude, thereforedifferential corrections are effective for compensating for tropospheric errors only in limitedcoverage areas.Typical differences due to atmospheric effects for separation between the receivers of 100 kmare found to be about few meters, except for the effect of the troposphere on altitudedifferences. For tropospheric phenomena, in fact, a difference in height between the receiverhas greater effects than horizontal displacement (for some km of displacement, meters ofdelay difference are detected).For a smaller separation the errors which decorrelate spatially remain sufficiently correlatedto be compensated. In case that the mobile receiver is very close to the reference station,several error contribution can be nearly totally compensated.

A baseline of 10 Km is used for the definition of the local corrections validity area due to thespatial decorrelation of differential corrections. When selecting the local area width, in fact, itis necessary to considered a pessimistic scenario with reference to the tropospherephenomena. Furthermore, also other contributions to the differential error decorrelatespatially. As a consequence, the 10 km wide local area gives only an order of magnitude andhas been selected in a conservative way.

However, the user may be able to model which are the systematic variations of theatmosphere with respect to the reference station situation. Wider areas, as a consequence, maybe considered, but as a function of local environmental and atmospheric conditions. Onlywhen a multipath level or a noise receiver level are selected for the interested area it ispossible to estimate how the differential corrections operate. In such cases, however, thedriving factors to the final accuracy become the environmental conditions and the differentialcorrections, although still very useful, cannot fulfil the required performances as specified inCAS1 service level.

6.3.2 Validity time and update rate

Also in the case of local enhancement, the differential corrections are accurate only at theinstant of time for which they were calculated. Their accuracy degrades as they get older andthe clock dither wanders. Despite of this, differential pseudorange corrections must betransmitted at discrete times by the reference station, therefore also the satellite motion causessignificantly changes in the pseudorange error. A geometrical degradation of the pseudorangecorrection (caused by the relative motion between the satellite, the reference station and themobile user) must, therefore, be taken into account. Few seconds are sufficient to reach morethan 1m errors (one sigma) if the pseudorange corrections are not applied.Such accelerations due to satellite motion are easily predictable and slowly changing, as aconsequence, the transmission of also the pseudorange rate (first order approximation) isconsidered in order to have not a stringent constraint on the refresh rate. The update rate, infact, should be designed to provide correction accuracy consistent with typical one-sigmadifferential pseudoranging errors of better than 1m. With pseudorange correction only, and norange-rate corrections, the standard deviation of the pseudorange correction error wouldincrease with time too rapidly.The aim of the rate-correction parameter is, therefore, to reduce the growth in thepseudorange correction error due to the satellite motion once the correction has beendetermined. After a few seconds, negligible quantity (compared with differential pseudorangeerror) can be obtained and growth over a couple of minutes can be limited to less than ameter. The increased message length is more than compensated by the lower update rateallowed by introducing the range-rate corrections.

GALA REF :DATE :

Gala-als-dd-01412-04-2001


The pseudorange and range rate measurements from the Galileo receiver are converted topseudorange and pseudorange rate errors by first correcting the raw measurements forsatellite clock errors, relativistic effects and atmospheric effects, then the calculated range andrange-rate are subtracted for each satellite. The resulting pseudorange and pseudorange-rateerrors consist of transmitted satellite range and range-rates errors plus the unknown receiverclock error and other, less significant, errors.

For the other contributions, the consideration reported for the continental corrections,concerning validity time and refresh rate in the case of ionospheric, tropospheric, ephemerisand clock errors, are still valid.

Tropospheric effect do not vary so rapidly, although the possibility that a fast vertical descentof the mobile receiver respect to the reference station must be considered. Because a differentin height between the receivers has greater effects than horizontal displacement, if a highvertical accuracy is needed when a fast descent (or ascent) is performed, an high refresh ratemust be adopted. A baseline of 120 s for the tropospheric delay removal should beconsidered.

The time variation of the ionospheric corrections is comparable with the previous values.Nominally the update interval is probably between 150 s and 300 s, depending on ionosphericactivities.

Ephemeris errors present a slowly variation in time, therefore they do not impact the updatetime. Ephemeris errors have been observed to have variations with time constant on the orderof 30 min.

Clock contribution to pseudorange error presents only a time decorrelation and not a spatialone. The validity time of such corrections depends on which type of time standard isconsidered. GPS Clock errors are characterised by variations with time slower than thoseshown by rubidium standards. Due to the lower accuracy of the latter time references, a lowertime constant must be expected with respect to the GPS one. In any case, such validityintervals are greater than the 120s related to the growth in the pseudorange correction error orto the atmospheric effects (see also GALILEOSAT studies).

As last remark, note that the refresh rate for differential corrections still remains related to theintegrity requirements that Galileo must respect, as a consequence the update rate cannot berelaxed too much even in the case the various contributions have a slow time decorrelation.Of course, if an additional integrity flag is added to describe the validity of the differentialcorrections, a further relaxation can be accepted.Furthermore, the update time requirement can be also relaxed with an accurate broadcastingstrategy (see Section 6.3.4)

6.3.3 Local differential correction parametersA. Each satellite pseudorange (measured by the receiver) is corrected as follows:

PR(t)=PRm(t)+PR0+(dPR0/dt) (t-t0)

where PRm(t) is the measured pseudorange at time t in meter, PR0 represents thepseudorange correction at t0, dPR0/dt is the range-rate correction and t0 is thereference time.It is important to note that such a pseudorange correction is a predicted correction thatwill have an error build-up over time. Thus it will be updated and transmitted as oftenas required to maintain high accuracy. The user should update the solution using allthe corrections as they are received.

GALA REF :DATE :

Gala-als-dd-01412-04-2001


More than one reference station may be adopted, therefore, in defining the parametersto describe differential correction, such possibility must be considered. In the messagea specific section for the station recognition is reserved:• the station ID identifies which reference station is considered. (9 bits or) 10

bits can be used to represent this information (up to 1024 reference stationcan be considered).

For each single reference station, the following parameters must be considered forlocal differential corrections:• the time reference for the message: 13 bits can be allocated to describe it.• the pseudorange correction: described with 16 bits.• the range-rate correction: described with 8 bits (although 16 bits could be

adopted to improve the performances).These 37 bits are sufficient to represent one satellite. The latter two parameters (i.e.the pseudorange and the range-rate) must be determined and broadcast for eachsatellite seen by the reference station. The former one (the time reference), instead, isnormally the same for all the satellite in view. As a consequence, under thehypothesis that the corrections are determined at the same time for all the satellite inview, it is sufficient to broadcast it only once and 24 bits per each satellite can beadopted.

Because one reference station broadcasts corrections for several satellites at the sametime, also a satellite identifier is necessary:• the satellite ID selects the satellite: 5 bits can be allocated to this purpose,

describing up to 32 satellites (6 bits if the possibility to describe up to 36satellites is requested).

Although for most of the time, the user and reference station will base the positionestimates on the same satellite data, the possibility that the reference station is basingthe corrections on the most recent satellite data whilst the user receiver has still notupdate its data, may also be taken into account. In such a case, the user should receivethe identification of the time at which the data have been updated for each singlesatellite, in order to create a warning when processing data:• the Issue of Data provides satellite message timing 8 bits may be allocated

for each satellite.

To summarise, six parameters are sufficient to describe local differential corrections.The station ID and the time reference constitute a common information for all thesatellite in view (23 bits per reference station). The pseudorange correction, therange rate, satellite ID and the Issue of Data, instead, must be broadcast for eachsingle satellite in view (37 bits per satellite).

Auxiliary messagesTo account for the possibility that a user adopts old satellite data in its pseudorangecomputations or in the case that additional data must be transmitted (such as the location ofthe reference station, location of differential broadcast transmitters, tropospheric correctionfactors or model parameters and further range corrections to adjust for satellite messagechanges), auxiliary messages can be defined. These messages can be interposed occasionallyto the primary differential correction message just described.

B. For example, when the satellite ephemeris and clock data set (with which the useroperates) are older than the data set being used by the reference station, the receivedcorrections must be modified. This can be done by transmitting a second type ofmessage as soon as the reference station starts using new Galileo navigation message

GALA REF :DATE :

Gala-als-dd-01412-04-2001


data (the Issue of Data parameter is changed to indicate such event). A deltadifferential correction can be sent every two or three minutes or so, updating thisinformation with each transmission, since the corrections will change slowly withtime. This is a result of the fact that the satellite ephemeris data parameters are relatedto orbital parameters, while the delta differential corrections are satellite positionalparameters.

C. A further different type of message, to be sent when possible, may contain essentialauxiliary information about the reference station, such as:

station coordinates (Earth Centred Earth Fixed)tropospheric delay at the zenith of the reference stationstation healthestimated station clock parametersaverage carrier-to-noise density figure of merit.

The tropospheric delay is provided for those users at an altitude different from that ofthe reference station. The provided parameter could be in a form of a verticalcorrection in meters, representing the delay of the signal from a satellite at the zenithover the reference station. Any of several tropospheric user models defined by theuser can be adopted.

D. Extra differential correction can be adopted and transmitted in the rare event thatpseudorange or range-rate excursions for a particular satellite are excessive. Tofacilitate the possibility of rapidly changing pseudoranges or range-rates, in fact, ashort message can be transmitted as soon as possible, repeating the parameters forthat (those) satellite(s) only. In such a way, only the corrections for the affectedsatellite would be involved. It is not certain that this message is needed.

Note: such approach could also be used in order to relax the data update interval. Infact, the update time can be design in such a way to not compensate all possibleevents but only the average of them. Normal atmospheric effects can, in such a way,be compensated although the chosen update time is not able to take into account forparticular atmospheric conditions. Critical situations verify when, for example, lowelevation angles are considered. In this case, in fact, an higher sensitivity to theatmospheric variation and multipath and a generally higher noise level is foreseen. Ina similar way, only normal clock behaviours can be described. If a particular eventoccur and the update time is not able to take into account for it, such messages can bebroadcast to rapid correct the differential data.

E. A dedicated message can also be defined to support surveying applications. It is, infact, possible to provide high precision Doppler counts using carrier phasemeasurements, which make possible centimetre resolution for stationary platforms.The instantaneous cumulative fractional Doppler count as obtained from the carrierphase measurements at the ground station can be transmitted together with thepseudorange corrections. By knowing the precise location of the differential station acomparison of the Doppler counts at the user and reference station over a period oftime can provide relative accuracy at the centimetre level.Surveyors typically determine relative positions using continuously integrated carrierDoppler measurements, where the modification in satellite geometry over time enablethem to remove system biases. Normally, the ionosphere does not change in anentirely predictable manner, so that the ionospheric delays limit the achievableaccuracy, especially when only one signal frequency is available. However, therelative effects of the ionosphere can be cancelled, at least over short baseline (tens ofkilometres).

GALA REF :DATE :

Gala-als-dd-01412-04-2001


Such a message can be transmitted only by a reference station set up for specificservice to surveying users, its transmission, in fact, would reduce the update rate ofthe primary message to navigation users. For surveying users this new message wouldbe the primary one.

F. Finally, in case of two frequency receivers, the possibility to transmit a deltacorrection between the two carriers should also be considered.

6.3.4 Broadcasting strategyAs a first recommendation, in order to maximise the rate of transmission of differentialcorrections, a variable length format of the message should be adopted. In such a way it isup to the reference station designer to determine which messages are sent, and how often.Furthermore, only the necessary information may be broadcast, delaying those data thatslowly decorrelates in time.Secondly, the update rate can be further relaxed by adopting a broadcasting strategy that usean optional differential correction message which may be transmitted only to compensatethose unexpected and excessive errors as soon as they occur.Finally, differential corrections for a specific reference station can be broadcast locally (witha dedicated ground transmitter by UHF/VHF signals) in order to adopt the smallest updaterate for all the data. The most stringent positioning requirements of sub-meter accuracy canbe, therefore, fulfilled. The dissemination of several local differential corrections related to anumber of reference stations, instead, can be performed via the Galileo navigation messagewith a relaxed update interval. In such a case the positioning requirement degrades a little, butif a meter accuracy is accepted a relaxed refresh rate may be adopted. The final accuracydepends on how much the update time is relaxed.

6.3.5 Local differential corrections within CAS-1 signalCurrently, the Gala baseline considers a total of 350 bps available in the Galileo CAS-1 signalin space for the broadcast of the local differential corrections.Different strategies could be adopted for the broadcast to the user of the differential correctionvia the CAS-1 SIS. Actually, these strategies shall be based on the current definition of theGalileo architecture, in which only some satellites (that broadcast integrity information) arecontinuously connected by the ground up-link stations. Anyway, two solution are brieflyanalysed in order to give an idea of the possible broadcast capacity from each satellite. Anoptimisation of the uplink strategy and message scheduling, in fact, is out of the scope of thisWork Package.

Corrections related to a specific satelliteA single local differential correction is valid for a single satellite viewed from a single area.This means that a single satellite has 350 bps available in CAS-1 signal to broadcast thecorrections for all the existing local areas. An optimisation of the message forming, taken intoaccount the satellite visibility of the various areas, would result in an augmentation of theserved areas (roughly two times). Due to the current architecture, in which not all thesatellites are continuously connected, this solution is not fully feasible, but is presented hereas a lower boundary.

All corrections by one satelliteAssuming the opposite case with respect to the previous one, only a single satellite could bein charge of broadcasting the differential corrections for all the satellites for all the existingareas. Thus there are only 350/30=11.7 bps available for a single area. An optimisation in the

GALA REF :DATE :

Gala-als-dd-01412-04-2001


satellite up-link scheduling could of course increase this figure, up to the limits previouslyshown.

An intermediate figure between the two cases can be assumed as feasible, and is the base forthe following analysis.

6.3.5.1 Study caseThe overall accuracy improvements that could results from the local differential correctionare strictly related with the user environment (on which the corrections have no effect). Thecase of low contribution to the UERE budget for the receiver noise and multipath delay hasbeen taken into account for the analysis.Note that in case a major degradation of the UERE due to multipath is considered, thenominal CAS-1/L2 level of performances cannot be anyhow reached. However differentialcorrection with degraded accuracy may take advantage with a relaxed refresh rate of thecorrections, i.e. allowing to serve a greater number of stations.

The following assumptions have been considered:

A) UPDATE RATEIn order to reach the required sub-meter accuracy, the following update rate seemsneeded for each specific contribution:

Contribution to pseudorange error Update rateGeometrical degradation

(when pseudorange-rate is transmitted)>120 s

Tropospheric delay >120 sIonospheric delay 150 s – 300 s

Clock effect Dependent on atomic standardsbut in any case >120 s

Ephemeris >30 min

The driving factors, as a consequence, are atmospheric effects and the geometricaldegradation due to satellite motion. A refresh period of 120 s is suggested to update thedifferential corrections when considering a “Low user contribution” (e.g. multipath andreceiver noise) and a pessimistic scenario with respect to the atmosphere.

B) CORRECTION DATA LENGHTA data flow of 60 bits is assigned for a differential correction relative to a single area andsatellite, considering 37 bits for each satellite, and 23 bits for each reference station.

C) CORRECTION DATA RATEBased on the previous assumptions, the following data rate is necessary to describe thecorrection for each area and each satellite:

(Low user contribution to UERE): 60 bits/120 s = 0.5 bps

D) AVAILABLE SIGNAL DATAIn the CAS-1 signal in space a total of 350 bits per second is foreseen, up to now, for thebroadcasting of the local differential corrections.

GALA REF :DATE :

Gala-als-dd-01412-04-2001


6.3.5.2 Number of local areas covered by a satelliteBased on the latter assumption, the following total number of reference stations is derived inthe case that each satellite transmits exclusively its own corrections (more stations for thesame satellite):

350 bps / 0.5 bps = 700 areas(inconsistent approach with current Gala architecture)

In the particular case that each satellite transmits only the corrections related to those areasthat are in its view, it is possible to save bits in the correction message. Under suchbroadcasting hypothesis, it is no more necessary to transmit the satellite ID (5 bits), leading toa total of 55 bits instead of 60. This could augment the total number of areas up to 763.

If each satellite is viewed by only one reference station (simplistic assumption) and if eachsatellite transmits the corrections for the whole constellation, the following total number ofreference stations is derived:

350 bps / 0.5 bps / 30 sat = 23 areas

A mixed solution could take into account for the current GALA architecture. In this case,each connected satellite broadcasts also the corrections for the autonomous satellites and ifeach satellites is viewed by two reference stations, then the number of area is:

350 bps / 0.5 bps / 2 / 1.5 = 233 areas

6.3.5.3 Advantages of broadcasting local correction within CAS 1 signal• No need for Local Component RF datalink.• No need for separate differential corrections data link receiver.• Possible use of differential correction service in areas not covered by VHF links

6.3.5.4 Drawbacks of broadcasting local correction within CAS 1 signal• The CAS-1/L2 does not include the user integrity data• The Global Component shall be sized on a fixed maximum number of Local

Component• The impact on the overall architecture is highly significant• Major cost impact for the network deployment; this cost could be the responsibility of

the differential service provider, i.e. the differential service provided would pay forthe data link to the nearest node in the Galileo data network.

6.4 LOCAL DIFFERENTIAL CORRECTION SUMMARY

The investigation concerning local differential corrections still need consolidation. Thecurrent state of the analysis is hereafter summarised.

When local differential corrections are considered, the residual driving factors to the finalUERE are:§ the multipath level;§ the receiver noise.

A data flow of 60 bits is assigned for a local differential correction relative to a single areaand satellite, considering 37 bits for each satellite, and 23 bits for each reference station.

The 120 s validity time of these corrections is driven by:§ tropospheric and ionospheric effects,

GALA REF :DATE :

Gala-als-dd-01412-04-2001


§ geometrical degradation of the pseudorange correction.

The local area width of 10-30 km must NOT be considered as a fix value:§ it represents the worst case (vertical variation within the area, high solar activities),§ its range of variation is high depending on the considered scenario (holography,

multipath, noise receiver),§ the local area may be even 100 km wide (optimistic environment and scenario).

GALA REF :DATE :

Gala-als-dd-01412-04-2001


7 ORBIT MODELS, EPHEMERIS AND ALMANAC ANALYSIS

The error-tree for a general satellite-based navigation system is shown in Figure 7-1.

Figure 7-1. Error tree for a general satellite-based navigation system

Only a few of the errors, mainly systematic, appearing in the graph will be analysed in theframe of the study tasked by the work package 2.2.3.

Several strategies may be investigated in order to improve the navigation messageperformances and the Time To First Fix; the final option may be a combination of some ofthem:

• Increase transmission data rate.

• Use of several data channels.

• Investigate ephemeris message to be broadcast and user algorithms, in order to reducenumber of parameters, increase interval of validity or increase accuracy:- GPS message performances will be assessed using real GPS data (the results will be

considered as a reference baseline).- Several propagation algorithms will be studied (GPS-like, GLONASS-like,

polynomials…), in order to assess the influence of the number of parameters, theperiod of validity and the degraded performances (accuracy outside the fit interval).The results of previous analysis on message models is shown below as a reference.

• Assess the reduction of parameters of the almanac, taking GPS performances (which willbe assessed using real GPS data) as a reference:

GALA REF :DATE :

Gala-als-dd-01412-04-2001


- Reduce the number of almanac parameters by not broadcasting data for all satellitesbut describing the full constellation with a few parameters, plus some informationabout possible deviations from nominal positions. This strategy will be feasible only ifselected orbits are stable.

- Assess whether the reduction of the number of parameters can be compensated withthe use of more accurate propagation models.

- The possibility not to use the almanac will also be studied.

The study intend to verify the validity of the format for the navigation message, in order notto degrade the Galileo required accuracy, and re-evaluate possible solutions in light of therecent technological advances.

Alternative approaches to the almanac broadcasting are analysed, with the aim to reduce theTTFF without jeopardising the robustness of the navigation data transmitted. Such a trade-offis conducted in order to minimise the impact on user equipment implementation, whileinsuring the capability for the user, at cold start, to acquire the approximate positions of theusable satellites under possible interference conditions. This requires, if the almanacs aredistributed on a separate communication channel, to insure to this channel the samerobustness of the primary navigation channel used by the Galileo system, while notcomplicating unnecessarily the user equipment.

Alternative solutions to the orbit propagation algorithms will also be investigated, to verifypossible improvements in the general solution and in the applicable.

The purpose of this chapter is to define suitable models for Almanacs and Ephemeris andassess their performance, in terms of number of parameters required, accuracy, interval ofvalidity and degradation of accuracy.

7.1 CONSIDERED SATELLITE CONSTELLATIONS

Two constellations were proposed at the end of the GNSS-2 Comparative System Study: oneincluding both MEO and GEO satellites and the other composed only of MEO satellites.Their characteristics are described below:

v MEO + GEO Architecture Constellation:• 24 MEO Walker 24/3/2 plus 8 GEO satellites• GEO satellites equally spaced around the Equator with 1st s/c at 0-deg longitude• 3 orbital planes• 57 deg inclination• 30505 km semi-major axis

v MEO Only Architecture Constellation:• 30 MEO (Walker 30/3/0) satellites• 3 orbital planes• 54 deg inclination• 29601 km semi-major axis

The satellites used to perform the hereafter analyses are part of the previous constellations.Therefore, two kinds of s/c have been used: MEOs and GEOs. Their characteristics are thefollowing:v MEO satellites have an area of 14 m2 and 500 kg of mass.v GEO satellites have 16 m2 of area and a mass of 1000 kg.

GALA REF :DATE :

Gala-als-dd-01412-04-2001


To work in a more realistic scenario, the following procedure has been followed:

• MEO constellation has been optimised with the ELCANO tool to improve the stability ofthe orbits, so small corrections have been added to all semi-major axes in order tominimise the degradation of navigation performances. GEO s/c are located in a fixed“slot” in the geostationary orbit, so frequent manoeuvres are performed in order to keepthe satellites within their assigned narrow boundary.

• Then, the new constellation has been propagated over a year taking into consideration themajor forces acting on satellites (Earth’s gravity, third body perturbations and solarradiation pressure). Orbits computed from the resulting constellation are considered to bemore representative than nominal ones.

In addition, real orbits of GPS satellites have been used to assess operational performances ofGPS almanac and navigation message.

7.2 ALMANACS

7.2.1 Analysis of GPS almanac performance using real dataGPS Almanac performance has been assessed to state a reference for the accuracy of thealmanac to be achieved. To do this, a real GPS almanac has been retrieved using a GPSreceiver and then satellite orbits have been computed for 1 and 4 days with the standard GPSalgorithm. This algorithm is the same used with the ephemeris message (described in7.3.2.1.1), but all the perturbation parameters except the rate of change of the ascending nodeare set to zero.These orbits have then been compared with those computed by IGS. IGS collects data from aworldwide ground station network and provides very precise GPS orbits, satellites andstations clock information, Earth rotation parameters, and tracking station coordinates andvelocities. Figure 7-2, taken from the ESOC IGS Analysis Centre site, shows the comparisonbetween the final IGS orbits and those computed by each of the IGS Analysis Centres. It canbe seen that typical accuracy of IGS orbits is below 10 cm, so when comparing with themrealistic accuracy values are being obtained.

Figure 7-2. IGS Orbits accuracy

GALA REF :DATE :

Gala-als-dd-01412-04-2001


Results are presented in the following table for all satellites which almanac was available.Orbit accuracy is computed as RMS of the difference between the satellite positions in theorbit computed from the almanac and the IGS one, along the 1-day propagation interval(Table 7-1). In addition, RMS values for all satellites have been plotted, for both 1 and 4 dayspropagation intervals (Figure 7-3).

Table 7-1. GPS Almanac Accuracy (1 day)

Satellite PRN X accuracy (m) Y accuracy (m) Z accuracy (m) Accuracy (m)1 1150.993 1280.886 1224.608 2113.0832 1408.316 1395.880 1209.242 2322.5203 1300.649 1178.896 1114.087 2079.1044 535.704 608.752 562.588 986.9465 1457.944 2039.924 1702.474 3030.7276 1489.948 1374.118 1267.353 2390.4667 2044.750 1354.103 1670.053 2967.0998 1492.567 2277.224 1695.460 3207.5059 2190.491 2864.052 2550.134 4416.359

10 1161.681 1405.843 1179.208 2171.73413 1662.351 1341.967 1534.284 2630.26914 1211.869 1562.757 1562.907 2520.61815 1019.903 1368.863 1477.834 2257.87116 1611.520 1892.196 1895.890 3125.98817 443.665 431.219 809.570 1018.91718 719.664 886.832 550.432 1267.81819 1665.284 1784.547 1844.215 3059.23321 3105.265 2472.398 2660.384 4778.39622 1177.237 947.947 1331.664 2014.40323 1323.667 1297.796 1329.255 2281.07224 1734.952 2188.135 1745.641 3293.21425 2858.798 2438.568 2957.548 4781.88626 1488.429 1804.910 1510.648 2784.81227 516.822 482.336 820.310 1082.89529 1250.798 975.424 1082.149 1920.15530 352.418 423.212 686.604 880.18931 1012.095 1037.964 1141.601 1845.253

RMS 1523.945 1582.079 1561.447 2695.088

0

2000

4000

6000

8000

10000

12000

14000

16000

1 2 3 4 5 6 7 8 9 10 13 14 15 16 17 18 19 21 22 23 24 25 26 27 29 30 31 RMS

SV

1 day

4 days

Figure 7-3. GPS Almanac Accuracy (1 and 4 days)

The use of a GPS-like almanac allows a smooth degradation of accuracy. To illustrate this,the orbit accuracy (in X, Y and Z components) has been plotted along time for SV 14, whichaccuracy figure is close to the typical constellation value (Figure 7-4). It must be noted that

GALA REF :DATE :

Gala-als-dd-01412-04-2001


the propagation starts at the beginning of the day corresponding to the almanac’s epoch. Thebest accuracy is obtained around the almanac epoch.

-20

-15

-10

-5

0

5

10

15

20

0 1000 2000 3000 4000 5000

Propagation Time (min)

X

Y

Z

Figure 7-4. Evolution of Almanac Accuracy (4 days, SV 14)

7.2.2 Almanac improvement by reducing the number of parameters

7.2.2.1 Almanac DefinitionThe first approach to reduce the TTFF is to decrease the number of broadcast parameters. Asat least 6 parameters are required to define an orbit, assumptions on them will have to bemade resulting in a loss of flexibility (a GPS-like almanac does not impose any constraint tothe location of the satellites). It is believed that the implementation of other type of almanacwill be adequate if there is a significant reduction of the number of parameters whilstmaintaining the accuracy at the GPS level. Otherwise, (e.g. 5 parameter per satellite) theTTFF reduction may not be worth the decrease of the flexibility and robustness of a GPS-likealmanac.The proposed set of parameters takes advantage of the stability of the selected orbits (so theproposed mean values will be close to the real ones). It assumes that the 3-plane configurationwill be maintained along the constellation lifetime, so future satellites will be added in thesame planes as existing ones. In any case, space may be reserved in the broadcast signal totransmit additional parameters (e.g. the 6 Keplerian parameters for TBD additional satellites)when required.

The proposed almanac consists of:

• Mean of semimajor axis, eccentricity, inclination and RAAN (Right Ascension ofAscending Node) for all planes (i.e. 4 parameters per plane).

• Argument of perigee of each plane’s first satellite, assumed equal for all satellites in thatplane (i.e. 1 parameter per plane).

GALA REF :DATE :

Gala-als-dd-01412-04-2001


• Mean anomaly of all satellites (i.e. 1 parameter per satellite). It must be considered thatall satellites in each plane have the same argument of perigee (corresponding to the firstsatellite of the plane). Therefore, the real mean anomaly has to be modified to take intoaccount the difference of arguments of perigee, so the phasing between satellites in eachplane will be kept to its real value.

This will result in a 39-parameter almanac for a constellation composed of 24 satellites in 3planes. In contrast, a GPS-like almanac will require 168.

7.2.2.2 Performance AssessmentOrbits have been computed for the constellation described in section 7.1 using the proposedalmanac. In addition, reference orbits have been computed using an orbit propagator takinginto account the main forces acting on MEO satellites (Earth’s gravity -JGM3 model-, Sunand Moon perturbations and solar radiation pressure). Then they have been compared as inthe GPS Almanac performance assessment. The results for 1 day are presented in Table 7-2,while those for 1 and 4 days are plotted in Figure 7-5.

Table 7-2. Simplified Almanac Accuracy (1 day)

Satellite ID X accuracy (m) Y accuracy (m) Z accuracy (m) Accuracy (m)1 751,822 3077,072 3418,727 4660,6122 1067,080 3834,676 4331,927 5882,9413 1732,042 3536,699 3744,571 5434,1534 1436,276 3046,322 3195,488 4642,6405 770,227 3116,852 3423,696 4693,5826 1036,259 3864,100 4299,448 5872,8497 1611,470 3565,765 3708,018 5390,8178 1546,079 3079,442 3139,160 4661,2939 4002,853 2253,505 2811,456 5385,666

10 2977,762 1072,646 2575,412 4080,48811 2729,337 1757,691 3623,649 4865,14012 3589,859 1643,398 3120,965 5032,72013 4008,022 2215,894 2818,802 5377,73814 2932,665 1078,294 2642,378 4092,11515 2740,316 1763,555 3706,981 4935,70316 3607,402 1583,702 3086,588 5004,84617 2440,727 2410,553 4829,304 5923,68918 3184,246 2351,877 5545,002 6813,06119 2812,903 2577,322 5917,399 7040,64120 2190,130 2966,443 4826,142 6073,55721 2489,352 2442,880 4883,872 6001,39522 3289,046 2401,002 5505,036 6847,48523 2768,853 2552,459 5769,060 6889,38724 2227,050 2886,118 4735,043 5975,790

RMS 2600,332 2660,490 4114,702 5547,135

This almanac is less accurate than GPS one, but accuracy level remains within the same orderof magnitude. It shall be recalled that almanac is an aid to signal acquisition, so high precisionin satellite position is not required. Therefore, the significant reduction of the number ofparameter (thus helping the improvement of the TTFF) may be worth the reduction ofaccuracy. There is also a decrease in the flexibility (a 3-plane satellite constellation isassumed) but it is not considered a major drawback, as no significant changes are expected inthe constellation configuration during its operational life.

GALA REF :DATE :

Gala-als-dd-01412-04-2001


0

5000

10000

15000

20000

25000

SV

1 day

4 days

Figure 7-5. Simplified Almanac Accuracy (1 and 4 days)

7.3 EPHEMERIS

7.3.1 Assessment of accuracy strategySeveral models for the ephemeris message will be analysed in this chapter, in order to assesstheir performances in terms of accuracy, interval of validity and degradation of accuracy. Thefollowed strategy consists of the steps described below:

1. A reference orbit is selected. It may be either a real GPS orbit from IGS or an orbitobtained from the constellation described in chapter 7.1 by means of an orbit propagator,taking into consideration all major perturbations acting on MEO and GEO orbits.

2. A least squares estimator is used to compute the model parameters; the process isrepresented in Figure 7-6. Several time intervals are used to perform the fit (the fitinterval corresponds to the interval of validity of the message ).

3. Once the parameters are obtained, the message is used to compute a new orbit. This orbitis compared with the one used as a reference in the parameters estimation.3.1. The comparison is performed along the fit interval, to obtain the model accuracy

within the interval of validity, i.e. the nominal performance.3.2. The comparison is performed outside the fit interval, to obtain the degradation of

accuracy along time, i.e. the degraded performance.

GALA REF :DATE :

Gala-als-dd-01412-04-2001


Start

Estimateinitial valuesfor parameters

OrbitFile

ReadOrbitData

CalculateXe, Ye,Ze frommodel

Calculatederivatives

frommodel

Calculateresiduals

(Xe-X, Ye-Y,Ze-Z)

LeastSquaresEstimator

Calculaterms of

residuals

Print rmsand parameters

in outputfile

OutputFile

Updatevalues

of parameters

End

Repeat for each time t

Repeat until rmsis minimum

k

Figure 7-6. Estimation process flow chart

7.3.2 Analysis of existing navigation message modelsThe existing models (GPS and GLONASS) have been tested to assess their accuracy usingreal data. To do this, the model parameters have been computed by means of a least squaresfit to a GPS orbit from IGS. Several time intervals (from 1 to 12 hours) have been used; thenthe orbit has been computed using the message (with the standard GPS and GLONASSalgorithms) and compared with the original one to assess the accuracy of the model.

7.3.2.1 Model definition

7.3.2.1.1 GPSThe GPS Model is the model applied by the GPS receivers in order to calculate the position ofthe GPS satellites from the message sent by them. It is a very standard model, and theavailability of commercial products would make the implementation of the algorithm a simpleprocess. The parameters included in the GPS message are defined in Table 7-3.

The satellite position at a certain epoch can be determined from the previous set of parametersby calculating the perturbed Keplerian orbit that corresponds to the values of the parameters.The set will be valid for a certain period of time only (typically 4 hours). The calculation ofthe parameters is done by an optimisation in order to minimise the position error during thatperiod.The way the local user calculates the position of the satellite at a certain time t for a givenperiod starting at toe and a set of parameters is explained in Table 7-4. There are two

GALA REF :DATE :

Gala-als-dd-01412-04-2001


constants, GM = 3.9686005 1014 m3/s2 (geocentric gravitational constant) and ωe =7.2921151467 10-5 rad/s (earth rotation rate).

Table 7-3. GPS message parameters

Time parameters

Toe Reference time for ephemeris parameters

IODE Issue of data, arbitrary identification number

Keplerian parameters

a1/2 Square root of the semi-major axis

E Eccentricity

i0 Inclination angle at reference time

Ω0 Right ascension of the ascending node at reference time

ω Argument of the perigee

M0Mean anomaly at reference time

Perturbation parameters

∆n Mean motion difference from computed value

&Ω Rate of change of right ascension

&i Rate of change of inclination

Cus Amplitude of the sine harmonic correction to the argument of latitude

Cuc Amplitude of the cosine harmonic correction to the argument of latitude

Cis Amplitude of the sine harmonic correction to the angle of inclination

Cic Amplitude of the cosine harmonic correction to the angle of inclination

Crs Amplitude of the sine harmonic correction to the orbit radius

Crc Amplitude of the cosine harmonic correction to the orbit radius

Table 7-4. Summary of equation used in the GPS ephemeris model

t t tk e= − 0Time elapsed sincereference epoch toe

u uk k k= +Φ δ Corrected trueargument of latitude

22/1 )(aa = Semi-major axis r a e E rk k k= − +( cos )1 δ Corrected radius

nGMa0 3=

Computed mean-motion

i i it ik k k= + +0& δ Corrected

inclination

n n n= +0 ∆ Corrected mean-motion

′ =X r uk k kcos X Position in theorbital plane

M M ntk k= +0Mean anomaly ′ =Y r sinuk k k

Y Position in theorbital plane

E M esinEk k k= + Eccentric anomaly(solved by iteration) Ω Ω Ωk e k e et t= + − −0 0( & )ω ω Corrected longitude

of ascending node

coscos

cosν k

k

k

E ee E

=−

−1

True anomaly X X Y sin ik k k k k k= ′ − ′cos cosΩ Ω Earth fixedgeocentric satelliteX coordinate

GALA REF :DATE :

Gala-als-dd-01412-04-2001


sine sinE

e Ekk

k

ν =−−

11

2

cos

True anomaly Y X sin Y ik k k k k k= ′ + ′Ω Ωcos cos Earth fixedgeocentric satelliteY coordinate

Φ k k= +ν ω True argument oflatitude

Z Y sinik k k= ′ Earth fixedgeocentric satelliteZ coordinate

δu C C sink uc k us k= +cos 2 2Φ Φ True argument oflatitude correction

δr C C sink rc k rs k= +cos 2 2Φ Φ Radius correction

kiskick sinCCi Φ+Φ= 22cosδ Inclinationcorrection

7.3.2.1.2 GLONASSThis is the model implemented in GLONASS receivers. The satellite position is computedfrom the following parameters (Table 7-5):

Table 7-5. GLONASS message parameters

Time parameters

tb Reference time for ephemeris parameters

State vector (Earth-fixed reference frame)

x x coordinate of satellite position

y y coordinate of satellite position

z z coordinate of satellite position

vx x component of satellite velocity

vy y component of satellite velocity

vz z component of satellite velocity

Perturbation parameters (Earth-fixed reference frame)

ax x component of residual perturbating acceleration

ay y component of residual perturbating acceleration

az z component of residual perturbating acceleration

The satellite position at any epoch within the validity interval (15 min from tb) is computed bynumerical integration (by means of a 4th order Runge-Kutta integrator) of a simplified set ofdifferential equations describing the satellite motion:

222

2

2

5

2

203

3232

2

5

2

203

3232

2

5

2

203

where

53

23

25

123

25

123

zyxr

azrz

zra

Czrdt

dvz

ayvxyrz

yra

Cyrdt

dvy

axvyxrz

xra

Cxrdt

dvx

vzdtdzvydt

dtvxdtdx

e

e

e

++=

+

−+−=

+−+

−+−=

+++

−+−=

===

µµ

ωωµµ

ωωµµ

GALA REF :DATE :

Gala-als-dd-01412-04-2001


µ (Earth’s gravitation constant), ae (Earth’s equatorial radius), C20 (Zonal geopotentialcoefficient of spherical harmonic expansion) and w3 (Earth’s rotation rate) are fixed constants(given in the same Earth-fixed frame as the model parameters).Initial conditions for the integration is the given state vector. The perturbing acceleration isconsidered as constant within the validity interval of the message. This interval of validity ismuch shorter than GPS’s message one, but only 9 parameters are required in this model.

7.3.2.2 Results of the AnalysisResults are presented in the following graph (Figure 7-7), in which model accuracy is plottedagainst the fit interval for both GPS and GLONASS models. These values correspond to theorbit accuracy within the fit interval.

0123456789

1011121314151617181920

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

Message Fit Interval (hours)

GPS

GLONASS

Figure 7-7. GPS and GLONASS Message Accuracy

Orbit accuracy outside the fit interval has also been computed, in order to test the robustnessof the model, i.e. the orbit degradation due to the message update not performed at thenominal rate.The following graphics show the evolution of orbit accuracy along time (starting after the fitinterval), for both GPS and GLONASS messages. Fit interval used is 3 hours for GPS and 30minutes for GLONASS. The second one shows in detail the degradation in the first threehours.

GALA REF :DATE :

Gala-als-dd-01412-04-2001


0

1000

2000

3000

4000

5000

6000

0 100 200 300 400 500 600 700

Time (min)

GPS

GLONASS

Figure 7-8. Degradation of GPS and GLONASS Message Accuracy along Time

0

5

10

15

20

25

30

35

40

45

50

0 20 40 60 80 100 120 140 160 180

Time (min)

Acc

ura

cy (

met

ers)

GPS

GLONASS

Figure 7-9. Degradation of GPS and GLONASS Message Accuracy along Time

It can be seen that the interval of validity of the GPS message (15 parameters) is significantlylonger than GLONASS message (9 parameters) one. In addition, the degradation of theaccuracy outside the fit interval is notably greater in the GLONASS case, especially in longperiods of time.

GALA REF :DATE :

Gala-als-dd-01412-04-2001


7.3.3 Survey of other existing analytical propagators

7.3.3.1 Stroboscopic PropagatorThe Stroboscopic Propagator is a semi-analytical propagator that uses a “variation-of-parameters” approach. It integrates analytically derived equations of motion computing theaverage effects of perturbations over an orbit. This approach allows large multi-orbit time-steps and typically improves computational speed by several hundreds of times while stilloffering high fidelity computation of orbital parameters.The principle of the Stroboscopic propagator is the use of an analytical integration ofanalytical expressions (approximations) of the perturbations on each orbital element (and theorbital period) for a complete orbit.With these considerations, it is concluded that the stroboscopic propagator is not suitable forthe user algorithms, as propagation intervals are less than a revolution and high short-termaccuracy is required.

7.3.3.2 SPOT ModelSPOT is a set of LEO, sun-synchronous satellites. Even though the GPS Model works wellwith satellites in a medium or high orbit, for a satellite such as SPOT, with a low orbit andtherefore significant perturbations due to the non-sphericity of the Earth and drag, a moreaccurate model is required.[RD 22] describes the orbit model that is used for SPOT. The generalised on-board orbitmodel given by [RD 22] was defined by performing a study of the major sources ofperturbations acting on the satellite and obtaining an analytical approximation for them. Allthe equations are shown in the reference and will not be repeated here, except for the finalexpressions. The perturbations included in the model are:

• Secular and short period perturbations due to oblateness, J2

• Significant short-period perturbations due to J2,2

• Short-period position perturbations (due to gravity)• Long-period perturbations (due to gravity)• Atmospheric drag

When the analytical expressions for these perturbations are combined, the following set ofequations (which define the model) is obtained:

t t t

a P P sin P

e P P P t P sin P sin P

e sin P P P t P sin P sin sin P sin

i P P sin PPsinP

tT

P

k oe

k k

k k k k k

k k k k k

k kk

d

k

= −

= +

⋅ = − + − −

⋅ = + + − −

= + + +

1 92

4

2 3 13 92

42

4

3 2 13 92

42

4

4 9 410

411

132

2

78

332

54

1

78

332

74

1

38

2 23

4

( cos )

cos cos ( ) cos

( )

cos cos

α

ω α α

ω α α

απ

Ω = + +

= + −

+ +

= + +

P P t P P sin

P sin P sin P sint

TP

where

P P t P t

k k

k k kk

d

k k k

5 7 9 4

92

4 10 11

6 8 122

34

2

34

52

1 24

cos α

α α απ

α

GALA REF :DATE :

Gala-als-dd-01412-04-2001


This model will provide the osculating orbital elements ak (semi-major axis), ek (eccentricity),ik (inclination), Ωk (right ascension of ascending node), ωk (argument of perigee) and αk

(argument of latitude, αk = ωk + Mk, where Mk is the mean anomaly) at each time tk inseconds, for a given set of parameters P1, ... P13. Td is 86400 seconds for a sun-synchronoussatellite. This model is more complex than the GPS one so a small price has to be paidregarding computational time for both the on-ground parameter optimisation and user’sposition determination, although the latter is negligible. On the other hand, only 13parameters are needed to define the model.SPOT model, along with GPS and a variation of it (called extended GPS model, with anadditional parameter to consider drag perturbation) were analysed for METOP satellite, asboth missions had very similar orbits. Some of the results obtained are presented in Figure7-10.It can be seen that SPOT model provides better accuracy than GPS one, especially when longfit intervals (up to 36 hours) are used. Since gravitational perturbations due to non-sphericityof Earth are less significant in MEO orbits, this model could provide better accuracy thanGPS one, plus consisting only of 13 parameters instead of 15. In addition, it may be possibleto obtain larger intervals of validity.Similar analyses to those carried out in section 7.3.2 have been performed using the SPOTmodel. A Galileo orbit has been used to perform a least squares fit, in order to estimate themodel parameters. Then the orbit computed using the message has been compared with thereference one in order to assess the model accuracy.Unlike the GPS and GLONASS case, there is not a clear difference between the ‘main’parameters (orbital elements or position and velocity) and the perturbation ones. Therefore,when using the SPOT model it is not easy to make an initial estimation of the parameters, tobe used as input for the least squares fit (in the GPS and GLONASS case, however, it issufficient to use the initial Keplerian elements or state vector, and to set the perturbations tozero). It should be noted that a good set of initial values is required in order for the lineartheory to be applicable, and thus to allow the convergence of the estimation process. Initialestimates for some parameters can be derived analytically, as can be seen in [29], and aniterative process is used for the computation of the initial value of P6.

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

6 12 18 24 30 36

Time (hours)

Po

siti

on

err

or

(rm

s, k

m)

GPS Model

Extended GPS Model

SPOT Model

Figure 7-10. RSS of the Position Error for several analytical models. METOP analysis

The accuracy results obtained using the SPOT model are presented in Table 7-6.

GALA REF :DATE :

Gala-als-dd-01412-04-2001


Table 7-6. SPOT Message Accuracy in Meters

Message Duration (hours) Message Accuracy (meters)

1 4.691

2 3.011

3 2.416

4 7.380

6 22.330

8 48.917

It can be seen that the level of accuracy achievable is several meters, which can not beconsidered as acceptable for Galileo.

The SPOT model was designed for low orbits, with a required accuracy of 1 km and aninterval of validity of 24h (up to 36h in some circumstances), therefore including several orbitrevolutions. Under these conditions, the model provides quite good performances, clearlybetter than GPS one (as seen in Figure 7-10). However, it does not give the accuracynecessary for Galileo applications. It should be recalled that Sun and Moon gravityperturbations, which have a significant effect on MEO orbits, are not included in the model.Moreover, the typical intervals of validity of the message will correspond to short orbit arcs;therefore, some of the parameters may not be observable enough.This is the case of P9, P10 and P11. Table 7-7 reports the results obtained using the SPOTmodel, but these parameters were not solved for in the estimation process.

Table 7-7. SPOT Message Accuracy in Meters (P9, P10 and P11 not estimated)

Message Duration(hours) Message Accuracy (meters)1 1.1472 1.9593 5.5754 14.119

The results of Table 7-6 and Table 7-7 are presented in Figure 7-11.

0

2

4

6

8

10

12

14

16

18

1 2 3 4Message Duration (hours)

All parametersestimated

P9, P10, P11not estimated

Figure 7-11. SPOT Message Accuracy in Meters

GALA REF :DATE :

Gala-als-dd-01412-04-2001


It can be seen that P9, P10 and P11 do not improve the model accuracy when the interval ofvalidity is low.Finally, it can be concluded that the SPOT model is not suitable for Galileo. The designcriteria were different, and the provided performance has been found not to be sufficient.

7.3.4 Investigation of new possibilities

7.3.4.1 Evolution of the orbital ElementsThe evolution of the orbital elements has been analysed to define a set of parameters thatapproaches the orbit with the desired level of accuracy.The orbit has been propagated for one day, computing the orbital parameters every fiveminutes, in order to study their behaviour. The first three observed elements: semi-major axis,inclination and RAAN have similar evolutions.The semi-major axis has a harmonic evolution, with the period twice the orbital period, as canbe seen in the following graphic (Figure 7-12).

Figure 7-12. Evolution of the Semi-Major Axis

The graphic below (Figure 7-13) shows the evolution of the inclination. A linear componenttogether with the harmonic evolution can be observed.

Figure 7-13. Evolution of the Inclination

There is a significant linear component in the evolution of the RAAN. However, a harmonictendency can also be observed, as presented in the following graph (Figure 7-14).

GALA REF :DATE :

Gala-als-dd-01412-04-2001


Figure 7-14. Evolution of the RAAN

The argument of perigee and the mean anomaly do not have a regular evolution, as can beseen in the following plots (Figure 7-15). That is why the argument of latitude has beenconsidered.

Figure 7-15. Evolutions of Argument of Perigee and Mean Anomaly

The evolution of the argument of latitude is presented in the following graphs (Figure 7-16).There is a significant linear behaviour, as can be seen in the left plot. The non-linearcomponent (mainly harmonic) is plotted in the right one.

Figure 7-16. Evolution of the Argument of Latitude

The value of the eccentricity is always close to the initial value. The following plot shows itsevolution, changing from 0 to 0.0001 (Figure 7-17). The change is very small, so it has notbeen taken into account in the message corrections.

GALA REF :DATE :

Gala-als-dd-01412-04-2001


Figure 7-17. Evolution of the Eccentricity

Considering the evolution shown in the previous plots, GPS model seems to be adequate ,since the corrections for the nominal semi-major axis and inclination are harmonic. Theharmonic component in the evolution of the argument of latitude is also taken into account inthe corrections of the GPS message. However, several improvements to the existing modelhave been carried out, introducing new corrections to the RAAN and considering rotationangles for transformation between Inertial and Earth Fixed frames.

7.3.4.2 Improvement of the GPS Model

7.3.4.2.1 RAAN ModificationsFrom the evolution of the orbital parameters GPS model equations seem to be adequate.However, as seen in a previous section, the harmonic behaviour of the RAAN is not takeninto account. Trying to improve the accuracy, an equation is added to the GPS set to obtainthe GPSLan message.Two new parameters are needed: Cls and Clc. The former (i.e. Cls) is the amplitude ofthe sine harmonic correction to the longitude of the ascending node, and the latter (i.e.Clc) is the amplitude of the cosine harmonic correction to the same parameter. A newequation is needed:

klsklck sinCC Φ+Φ=Ω 22cosδWith the new correction the corresponding equation for the longitude of the ascending nodeis:

+−−Ω+Ω=Ω eekek tt 00 )( ωω&klsklc sinCC Φ+Φ 22cos

The rest of the equations are the same as in the GPS model, in Table 7-4.

7.3.4.2.2 Rotation ParametersIn GPS message the x, y, z coordinates of the satellite position are transferred to Earth-fixedcoordinates, as seen in Table 7-4. To do so, the longitude of the ascending node (i.e. theLAN), is considered. This parameter is computed as follows:

Ω Ω Ωk e k e et t= + − −0 0( & )ω ωAccording to the expression above, Earth’s rotation rate takes part in the calculation of theLAN. Therefore, only rotation around the z-axis is considered in the GPS model. However,effects of nutation, precession and Earth mean pole motion are not taken into consideration.To include these effects in the analysis of the perturbations, three additional parameters areestimated in this section: the rotation angles around the three reference axes.Two different cases have been studied:

GALA REF :DATE :

Gala-als-dd-01412-04-2001


• GPS model with rotation parameters and linear evolution of the RAAN. This is calledGPSRot.

• GPS model considering the harmonic component in the RAAN evolution and the threerotation angles. This is the GPSLanRot message.

7.3.4.2.3 Results of the AnalysisThe accuracy of the messages presented above has been tested, in the same way as in GPSand GLONASS models. The following graphs show the message accuracy in the differentcases. In the first one, all GPS-type messages are plotted. The more parameters are used, thehigher accuracy is observed. The graphic presents the evolution of the accuracy in twelvehours. GPSLan is the message obtained by adding the harmonic evolution of the rightascension to the GPS message. GPSRot adds to the GPS message three rotation angles aroundthe three coordinate axes. The last one, GPSLanRot, is the combination of all the previous,i.e., GPS message plus RAAN harmonic correction and the three rotation angles. The mostaccurate model is the last one, which includes all the corrections. However, the RAANharmonic correction does not seem to be very necessary, since accuracy results of GPSRotmessage are very similar to those of GPSLanRot. Moreover, for not very long messagevalidity periods, up to six hours, the accuracy of all messages is very similar, so GPSmessage is suggested, for less number of parameters is needed.

0

1

2

3

4

5

6

7

8

9

10

1 2 3 4 5 6 7 8 9 10 11 12Message Fit Interval (hours)

Mes

sag

e A

ccu

racy

(met

ers)

G P S

GPSLan

GPSRot

GPSLanRot

Figure 7-18. GPS-Type Message Accuracy

The different values for the accuracy in this period of time are represented in the followingtable (Table 7-8).The most significant improvement in the accuracy obtained by adding parameters to the GPSmodel is observed after the seventh hour, when values are not accurate enough for Galileoorbits. In order to better observe the differences when errors are lower, a shorter period oftime is represented in the following graph. Not very significant improvements are achieved byadding corrections to the GPS model, since the accuracy in all cases is in the same order ofmagnitude.

GALA REF :DATE :

Gala-als-dd-01412-04-2001


Table 7-8. GPS-Type Message Accuracy in Meters

Message Fit Interval (hours) GPS GPSLan GPSRot GPSLanRot

1 0.010 0.032 0.008 0.006

2 0.003 0.001 0.005 0.004

3 0.027 0.013 0.014 0.013

4 0.142 0.070 0.072 0.070

5 0.327 0.185 0.194 0.183

6 0.412 0.277 0.310 0.261

7 0.661 0.379 0.428 0.318

8 2.002 1.340 1.194 1.064

9 3.947 3.278 2.752 2.413

10 5.696 5.411 4.146 3.715

11 7.377 7.257 4.575 4.203

12 9.802 9.642 4.680 4.457

When the fit interval is short the observability of some parameters is reduced, thus explainingthe better results observed for the GPS model for short time intervals (1 and 2 hours). GPS’value can be assumed for all models in these cases, as this result will be obtained by settingthe additional parameters to zero in the estimation process.

0

0 . 1

0 . 2

0 . 3

0 . 4

0 . 5

0 . 6

0 . 7

0 . 8

0 . 9

1

1 2 3 4 5

M e s s a g e F i t I n t e r v a l ( h o u r s )

Mes

sage

Acc

urac

y (m

eter

s)

G P S

G P S L a n

G P S L a n R o t

G P S R o t

Figure 7-19. GPS-Type Message Accuracy

As in section 7.3.2.2, orbit accuracy outside the fit interval has also been computed; in orderto analyse the robustness of the message model. Fit interval considered in the four cases isthree hours. The results of this study are presented in the following graph.

GALA REF :DATE :

Gala-als-dd-01412-04-2001


0

200

400

600

800

1000

1200

1400

0 60 120 180 240 300 360 420 480 540 600 660 720

Time (minutes)

Mes

sag

e A

ccu

racy

(m

eter

s)

GPS

GPSLan

GPSRot

GPSLanRot

Figure 7-20. GPS-type Message Accuracy Degradation along Time

The estimation of the three frame rotation angles improves accuracy within the fit interval.However, since Earth rotation parameters change along time, the message degradation outsideits validity period is higher when these angles are included in the model, as can be seen in theprevious figure.

7.3.4.3 Polynomial Approaches

7.3.4.3.1 Polynomial Approach of the Orbital Elements.The evolution of the orbital elements in short periods of time will be analysed, to see if theycan be approximated by not very complex functions using a reduced number of parameters.Analysing the evolution of the orbital parameters in a few hours, a polynomial behaviour canbe observed. The following plots show the evolution of some orbital elements whenpropagating the orbit for three hours. The semi-major axis, for instance, behaves like apolynomial of third degree, as can be seen in the graph (Figure 7-21).

Figure 7-21. Evolution of the Semi-Major Axis in Three Hours

GALA REF :DATE :

Gala-als-dd-01412-04-2001


The following plots show, from left to right, the evolutions of the RAAN and the inclination.In both cases, the behaviour is similar to that of a polynomial of order 2 (Figure 7-22).

Figure 7-22. Evolutions of the RAAN and the Inclination during 3 Hour-Time

Regarding the evolution of the argument of latitude, there are not significant differences whenpropagating the orbit for short periods of time, so the corrections will be the same as in theprevious models.The following set of equations shows the corrected semi-major axis, inclination and RAAN inthis polynomial model.

2210

2210

33

2210

)( kkek

kkk

kkkk

tt

titiii

tatataaa

Ω+−Ω+Ω=Ω

++=

+++=

ω

&&

The model is completed with the following parameters (the same as in GPS model):e (Eccentricity)ω (Argument of perigee)

0M (Mean anomaly at reference time)∆n (Mean motion difference from computed value)

Preliminary tests performed with this 14-parameter model provided accuracy of severalmeters for short fit intervals (less than 2 hours). These results are significantly worse thanthose of a GPS-like approach, so this kind of polynomial message was rejected and otherpolynomial models were considered.

7.3.4.3.2 Lagrange PolynomialsAnother kind of polynomial approach will be the interpolation of the orbit using polynomialfunctions. Interpolation consists of using a set of samples to build a function thatapproximates the initial one. Lagrange interpolating polynomials are used in this model. Ingeneral, given a set of N+1 samples )( kxf , k = 0, 1, … , N, the unique order N polynomial

)(xy that interpolates the samples is

∏

∑

≠

=

−−

=

=

ik ik

ik

k

N

Kk

xxxx

xl

xfxlxy

)(

)()()(0

This unique polynomial is called Lagrange order N Interpolating Polynomial.

GALA REF :DATE :

Gala-als-dd-01412-04-2001


In the orbit case, x represents time, kx are the dates used to interpolate and )( kxf are the

Earth-Fixed orbit positions in the corresponding moment kx .Figure 7-23 shows the evolution of the accuracy when using Lagrange polynomialapproximation of the orbit. Different orders of the polynomial approximations are plotted inthe same graphic, from 8th to 15th degree. An improvement of the accuracy is observed whenincreasing the order in the polynomial, i.e., using three more parameters per degree (one moredegree means one more interpolating point). However, this kind of message does not seem tobe very adequate, since it needs much more parameters than one of the GPS-type for similaraccuracy in the same fit interval.

0

5000

10000

15000

20000

25000

30000

35000

40000

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


Acc

urac

y (m

eter

s)

8th degree

9th degree

10th degree

11th degree

12th degree

13th degree

14th degree

15th degree

Figure 7-23. Lagrange Polynomial Interpolation Accuracy

The different values for the message accuracy in this period of time are shown in Table 7-9.

Table 7-9. Lagrange Polynomial Interpolation Accuracy in Meters

Message Fit Interval(hours)

8th degree(27 param)








1 0.0003 0.0064 0.0006 0.0005 0.002 0.007 0.016 0.008

2 0.005 0.001 0.001 0.001 0.001 0.003 0.005 0.006

3 0.180 0.012 0.001 0.002 0.004 0.004 0.007 0.033

4 2.418 0.207 0.018 0.002 0.005 0.002 0.005 0.007

5 17.378 1.965 0.207 0.021 0.006 0.012 0.009 0.027

6 88.550 11.970 1.513 0.177 0.024 0.012 0.020 0.021

7 338.797 52.937 7.991 1.128 0.157 0.024 0.024 0.035

8 1095.355 197.138 33.350 5.234 0.830 0.127 0.026 0.014

9 2992.197 614.250 116.280 20.150 3.517 0.600 0.117 0.038

10 7406.098 1649.473 352.211 67.770 12.592 2.236 0.415 0.096

11 16385.265 4119.870 953.233 202.010 39.755 7.040 1.352 0.330

12 33981.076 9341.488 2353.093 541.775 114.429 21.587 3.672 0.837

Since the message is less accurate after a few hours, another plot is presented showing theevolution of the message accuracy for a shorter period of time, four hours (Figure 7-24).

GALA REF :DATE :

Gala-als-dd-01412-04-2001


0

0.5

1

1.5

2

2.5

3

1 2 3 4Message Fit Interval (hours)

Acc

urac

y (m

eter

s)8th degree

9th degree

10th degree

11th degree

12th degree

13th degree

14th degree

15th degree

Figure 7-24. Lagrange Polynomial Interpolation Accuracy

The first polynomial considered (order 8th) needs 9 interpolation points (i.e. 27 parameters),but it is not very precise after two hours. More parameters are needed to obtain accurateapproximations for longer time intervals. However differences between the use ofpolynomials of more than 9th degree are not very significant for a message fit interval of fourhours.The robustness of the different models has been studied, computing the degradation of themessage outside the validity period. The fit interval has been changed depending on thedegree of the interpolating polynomial used. Starting with 2 hours of fit interval for the 8th

degree polynomial, one more hour of validity in the message corresponds to one more degreein the polynomial (e.g. 3 hours for 9th degree, 4 hours for 10th degree and so on). The accuracyof the message within the fit interval is around 2 cm in all cases. The results of thedegradation of the accuracy of the message outside the validity period are presented in thefollowing graph (Figure 7-25). In order to clarify the plot, only some of the interpolatingpolynomial degradation results are presented.

0

1000

2000

3000

4000

5000

6000

0 60 120 180

Time (minutes)

Acc

urac

y (m

eter

s)

8th degree9th degree

10th degree

11th degree

12th degree

Figure 7-25. Degradation of Lagrange Polynomial Interpolation along Time

GALA REF :DATE :

Gala-als-dd-01412-04-2001


Great degradation is observed in all polynomial messages after an hour outside the fit interval.Comparing these results with the ones of GPS-like messages, smoother degradation isobserved in the GPS case, since a polynomial approximation is always divergent. Thefollowing table shows a comparison between both GPS and Lagrange interpolation messages,in terms of number of parameters needed to obtain similar accuracy results for differentvalidity periods.

Table 7-10. Parameters required for GPS and Lagrange interpolation messages

Interval of Validity GPS Message Lagrange Interpolation3 hours 15 (1 message) 30 (9 th order)6 hours 30 (2 messages) 39 (12th order)9 hours 45 (3 messages) 45 (14th order)

It can be concluded that, for long fit intervals (9 hours) one polynomial message providessimilar accuracy results than three GPS messages. However, it is suggested to use severalGPS messages rather than only one polynomial message, in order to reduce the number ofbroadcast parameters and therefore the message size. Moreover, smoother degradation isachieved in case of possible looses of message.

7.3.5 Application to the GEO satellitesIn section 7.3.4.2.3 the analysis of the different Message Accuracy for MEO s/c is presented.Similar study has been carried out for the GEO satellites. The same kind of message as forMEOs is desirable, so the analysis in this section is based on the type of messages analysed insection 7.3.4.2.3. Only the GPS-like messages and Lagrange interpolating polynomials havebeen considered, since the rest does not provide satisfactory results for the MEO case.The accuracy of GPS-like messages is slightly worse for GEO satellites. However, the use ofLagrange interpolating polynomials to build the orbit improves the accuracy for the GEOs. Infact, less number of parameters is needed in this case to obtain similar results of precision.The following plot (Figure 7-26) shows the accuracy of GPS-like messages for fit intervalvalues up to twelve hours. As in section 7.3.4.2.3, in GPSLan a correction for the longitude ofthe ascending node is added to the GPS corrections and GPSRot represents the addition ofthree extra rotation parameters to the GPS message. GPSLanRot is the combination of allprevious messages: GPS corrections together with harmonic correction of the longitude of theascending node and the three extra rotation angles. The best accuracy is obtained when usingthe most complex message, which involves 19 parameters. The results are very similar tothose presented in Figure 7-18 and Table 7-8, referred to MEO satellites.

0

1

2

3

4

5

6

7

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


Mes

sage

Acc

urac

y (m

eter

s)

GPS

GPSLan

GPSRot

GPSLanRot

Figure 7-26. GPS-type Message Accuracy (GEO case)

GALA REF :DATE :

Gala-als-dd-01412-04-2001


The different values for the message accuracy within the fit interval are presented in thefollowing table (Table 7-11):

Table 7-11. GPS-type Message Accuracy in Meters (GEO case)

Message Fit Interval (hours) GPS GPSLan GPSRot GPSLanRot

1 0.032 0.027 0.022 0.031

2 0.083 0.024 0.014 0.017

3 0.044 0.008 0.040 0.004

4 0.040 0.021 0.038 0.047

5 0.212 0.077 0.075 0.083

6 0.647 0.265 0.221 0.176

7 1.456 0.758 0.544 0.313

8 2.632 1.755 1.083 0.482

9 3.977 3.298 1.800 0.822

10 5.144 4.804 2.561 1.491

11 5.834 5.717 3.221 2.457

12 6.057 6.031 3.760 3.460

The accuracy of the messages outside the fit interval has also been computed, to test theirrobustness along time, i.e., the orbit degradation when there is no update of the message in thenominal rate. The results of the evolution of the orbit accuracy along time, starting after the fitinterval, are presented in the following plot (Figure 7-27). Fit interval used is 3 hours for allcases.

0

2000

4000

6000

8000

10000

12000

0 60 120 180 240 300 360 420 480 540 600 660 720

Time (minutes)

Mes

sag

e A

ccu

racy

(m

eter

s)

GPS

GPSLan

GPSRot

GPSLanRot

Figure 7-27. GPS -type Message Accuracy Degradation along Time (GEO case)

The accuracy obtained approximating the orbit using Lagrange interpolating polynomials isalso analysed in this section. The number of parameters needed to obtain comparableaccuracy to MEO s/c is lower. Polynomials of six degree provide good accuracy for GEOsatellites in a few hours. The evolution of the message accuracy is presented in the followingplot (Figure 7-28):

GALA REF :DATE :

Gala-als-dd-01412-04-2001


0

20

40

60

80

100

120

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


Mes

sage

Acc

urac

y (m

eter

s)

5th degree

6th degree

7th degree

8th degree

9th degree

Figure 7-28. Lagrange Polynomial Interpolation Accuracy (GEO case)

The corresponding values for the message accuracy are presented in the following table(Table 7-12):

Table 7-12. Lagrange Polynomial Message Accuracy in Meters (GEO case)

Message FitInterval (hours)

5th degree 6th degree 7th degree 8th degree 9th degree

1 0.001 0.001 0.001 0.001 0.001

2 0.011 0.001 0.001 0.001 0.005

3 0.151 0.011 0.001 0.001 0.002

4 0.983 0.079 0.006 0.001 0.001

5 4.235 0.355 0.029 0.003 0.001

6 13.925 1.177 0.126 0.013 0.001

7 37.728 3.182 0.437 0.051 0.001

8 88.321 7.442 1.241 0.159 0.022

9 184.351 15.746 3.122 0.432 0.069

10 350.683 31.115 7.061 1.073 0.182

11 617.705 58.737 14.742 2.416 0.450

12 1019.543 107.128 28.040 5.176 1.015

The evolution of the message accuracy outside the fit interval has been computed to test therobustness of the message in case of not updating it in the convenient period. The followingplot shows the degradation of the different polynomial messages. As in the MEO case, shownin section 7.3.4.2.3, polynomial messages loose accuracy in a few hours. Fit interval for themessages depends on the degree of the polynomial: from 3 hours in the case of 6th degree to 7hours in the 9th degree polynomial. In all these cases, the degradation of message accuracy islower than 8 centimetres.

GALA REF :DATE :

Gala-als-dd-01412-04-2001


0

10000

20000

30000

40000

50000

60000

70000

80000

90000

100000

0 60 120 180 240 300 360 420Time (minutes)

Mes

sag

e A

ccu

racy

(m

eter

s) 6th degree

7th degree

8th degree

9th degree

Figure 7-29. Degradation of Lagrange Polynomial Interpolation along Time (GEO case)

7.3.6 Implementation of a numerical orbit integratorOver the last months, GMV has developed a precise yet fast and relatively simple numericalorbit propagator module. Since computer technology is improving faster every day, in termsof CPU speed, memory capability and low cost, the possibility of implementing a similaralgorithm in the user receiver shall be studied.GLONASS receivers are employing a similar concept nowadays, by integrating gravitationalforces (considering J2 term) by means of a Runge-Kutta method (4th order). The forces to beincluded shall be defined, along with the number of terms of the Earth’s gravity model to beconsidered. Sun and Moon ephemeris, if required, could be hard-coded for a set of years (e.g.25 years). With this approach, the required parameters will be only the state vector andpossibly the three Earth Rotation Parameters, which may be broadcast in a daily basis (e.g.using the almanac).This kind of approach will allow to obtain different levels of accuracy for different users,depending on the force model implemented in each type of receiver. However, it is believedthat this approach is most suitable when combined with on-board processing (see 7.3.7).

7.3.6.1 Definition of the dynamic modelTests have been performed in order to assess the dynamic model to be implemented in thepropagator in order to achieve acceptable accuracy results. A nominal orbit has beengenerated, by means of a state-of-the-art orbit propagator, taking into consideration all majorperturbations acting on high orbits:

• Earth’s gravity (JGM-3 model, 70x70 harmonics)• Sun and Moon gravitational perturbations• Solar radiation pressure (cannon-ball model)• Solid and ocean tides

New orbits have been generated with the proposed propagator, using several dynamic models.The same values have been assumed for the satellite’s mass, area and solar radiation pressurecoefficient Cr. These orbits have been compared with the reference one, in order to assesspropagation accuracy. Propagation interval is one day for all cases.The following graph (Figure 7-30) plots orbit accuracy versus time for three dynamicalmodels:

GALA REF :DATE :

Gala-als-dd-01412-04-2001


• Earth, 15x15: Earth’s gravity field only, 15x15 harmonics• Sun & Moon, 15x15: Earth’s gravity (15x15 harmonics), Sun and Moon gravity

perturbations• All, 15x15: Earth’s gravity (15x15 harmonics), Sun and Moon gravity perturbations,

Solar radiation pressure (cannon-ball model)

0

1000

2000

3000

4000

5000

6000

7000

8000

0 200 400 600 800 1000 1200 1400

Time (min)

All, 15x15

Sun&Moon, 15x15

Earth, 15x15

Figure 7-30. Orbit accuracy for several dynamic models

The curve for All, 15x15 cannot be seen with this scale, because it is close to the X-axis(RMS of accuracy is about 10 cm). It can be seen that the effect of Sun and Moonperturbations and Solar radiation pressure is important and therefore theseperturbations must be included in the propagation model in order to obtain accuracyvalues acceptable for Galileo.Additional tests have been performed in order to assess the possibility of simplifying thedynamical model by reducing the number of harmonics in the Earth’s gravity field. The Sunand Moon gravity perturbations and the solar radiation pressure were maintained in the forcemodel. The propagation accuracy results are presented in the following graph (Figure 7-31):

0

0.05

0.1

0.15

0.2

0.25

0.3

0.35

0 200 400 600 800 1000 1200 1400

Time (min)

Orb

it A

ccur

acy

(met

ers)

All, 5x5All, 6x6

All, 8x8All, 12x12

All, 15x15

Figure 7-31. Orbit propagation accuracy for several number of harmonics in Earth’sgravity field

GALA REF :DATE :

Gala-als-dd-01412-04-2001


From, these results it can be concluded that at least 5x5 harmonics need to be included, andthat the use of more than 8x8 harmonics is profitless. It can also be seen that this approachprovides very good accuracy for the nominal 12-hour validity interval, and performs also verywell for up to one day, presenting a smooth degradation of accuracy after the first 12 hours.Unless the other model analyses, orbits have been here computed in inertial frame instead ofEarth-Fixed. Since the user needs satellite positions in Earth-Fixed frame, there is the need ofan additional frame rotation of the orbit. Precise rotation matrices must be available in orderfor the accuracy to be acceptable; this is an important time and memory consuming issue forthe propagator, and will be commented in the following section. It must be recalled that thesematrices must be also available in order to compute Earth’s gravity force when propagatingin the Inertial frame.Precise rotation matrices are not necessary for the other navigation messages, sinceparameters fit is performed directly using the Earth-Fixed orbit.Another test has been performed in order to analyse the influence of a mismodelling in thesolar radiation pressure. To do this, a 0.5% error in the Cr has been introduced in thepropagated orbit; the results are presented in the following graph, for a 5x5 harmonics Earth’sgravity field. The nominal curve (no error in the Cr) is also plotted as a reference.

0

0,2

0,4

0,6

0,8

1

1,2

0 200 400 600 800 1000 1200 1400

Time (min)

All, 5x5

All, 5x5, Cr=1.005

Figure 7-32. Effect of the Cr mismodelling in propagation accuracy

It can be seen that a precise Cr value is required in order to achieve acceptable accuracyvalues.

From all the analysis, the following conclusions can be presented:• The force model shall include Earth’s gravity field with at least 5x5 and no more than 8x8

harmonics, Sun and Moon perturbations and solar radiation pressure (cannon-ballmodel)

• Precise Inertial to Earth-Fixed frame rotation matrices shall be available• A precise Cr and initial state vector shall be available

7.3.6.2 Processing capabilities considerationsThe orbit propagator used in this analysis was designed for fast yet precise performance, andwas especially oriented to constellations propagation, basically by making use of caches tostore information common to all orbits (such as rotation matrices and third body ephemera). It

GALA REF :DATE :

Gala-als-dd-01412-04-2001


uses an 8th order Adams-Bashford prediction-correction numerical integrator, started bymeans of an 8th order Runge-Kutta algorithm. It contains about 2400 lines of C++ code. APC-compiled executable is 100kb-size, and the time to propagate 1 day (1-min propagationstep) is about 2 seconds (PC Pentium II processor, 350 MHz).However, a significant amount of computational effort is devoted to the calculation of framerotation matrices, taking into consideration precession, nutation and ERPs, in addition toEarth’s rotation motion. Another resources-consuming problem is the time conversionsbetween UTC (used for input and output) and TAI (used for propagation, as it is a continuoustime scale).It should also be recalled that a significant part of the computation time is consumed in theRunge-Kutta startup algorithm, which shall be called only once with every set of parameters(the data for the prediction-correction algorithm will be then stored in memory and re-used ineach propagation).For a practical use of this approach, the best solution is that rotation matrices (consideringprecession, nutation and ERPs) be transmitted (e.g. in a daily basis, or every 12 hours), and allcalculations be performed in system (e.g. Galileo) time; therefore simplifying thecomputations.This way, about 500 lines of code can be saved, in addition several time-consumingoperations (including data files accessing) are not performed.Moreover, the Earth’s gravity computation module allows the use of an arbitrary number ofharmonics, which requires the computation of Legendre’s polynomials and harmonic series.A great simplification can be achieved by hard coding the equations resulting after fixing thenumber of terms required.Further simplifications can be done, for instance by removing some caches used forconstellations propagation and some file access code not necessary for single orbitpropagation. Anyway, it is required to compute Sun and Moon positions. This computationdoes not require high accuracy, and it can be done, for instance, by means of interpolation inlook up tables (which must therefore be stored); it should be recalled that this approach seemsto be better for on-board processing, therefore the storage of Sun and Moon data for a certainvalidity interval (which may be the whole satellite life) should be not a problem. Currently,monthly values for ephemera are used (JPL files).To summarise, the following parameters shall be uploaded for each propagation (12 hours):

• Initial state vector (position and velocity, 6 parameters)• Rotation matrix (9 parameters)• Solar radiation coefficient (1 parameter)

The number of parameters is similar to the GPS message’s, but this approach provides goodaccuracy for at least 12 hours (it could be valid for even one day). On the other hand, itrequires computations that are much more complex and the availability of Sun and Moondata. However, the implementation in user receivers can be envisaged (maybe by transmittingalso Sun and Moon data valid for current message) when considering the evolution ofcomputing capabilities and the possible simplifications to the code.

7.3.7 Broadcasting of current satellite positionConsidering that on-board equipment processing capabilities evolve, once the navigationmessage has been uploaded to the satellite, it could be feasible that the on-board computercalculates the satellite position in real time to be broadcast to the user. In that case, no useralgorithms will be required, as computations will be performed by the spacecraft.However, it must be taken into account that the receiver shall be able to compute the user’sposition several times between two consecutive navigation messages, therefore it is

GALA REF :DATE :

Gala-als-dd-01412-04-2001


necessary to know the precise satellite position at all these intermediate stages (e.g. GPSmessages are updated every 30 sec). Several alternatives could be envisaged:

7.3.7.1 Low-order Lagrange interpolationThe satellite computes the current position plus two additional ones in two near future epochs.Thus, 9 parameters are transmitted. The user then calculates the position at the required epochusing low (2nd) order Lagrange interpolation (which requires very small computingcapabilities).The accuracy obtained using this approach has been tested using short intervals; the resultsare presented in Table 7-13.

Table 7-13. 2nd order Lagrange Polynomial Interpolation Accuracy

Time interval Accuracy (meters)30 sec 0.008

60 sec 0.061

90 sec 0.207

120 sec 0.490

150 sec 0.957

180 sec 1.655

The results of the table are plotted in the next graph (Figure 7-33):

0

0.2

0.4

0.6

0.8

1

1.2

1.4

1.6

1.8

30 60 90 120 150 180

Message Fit Interval (seconds)

Mes

sag

e A

ccu

racy

(m

eter

s)

Figure 7-33. 2nd order Lagrange Polynomial Interpolation Accuracy

It can be seen that accuracy degrades rapidly with time; therefore this approach could bevalid if message updates are acquired not longer than every 60 sec. It shall be recalled thata GLONASS message is valid for up to 15 min, and it is also composed of 9 parameters(however it requires higher computational load in the receiver).

7.3.7.2 High order polynomialsIn this case, the satellite broadcasts only its current position with every message. The receiverstores the positions from several successive messages and then computes the position at the

GALA REF :DATE :

Gala-als-dd-01412-04-2001


required epoch using high order polynomials. This strategy allows a simpler message, but itshall be considered that polynomial approaches are better when using to interpolate, and inthis case it would be required to extrapolate. In addition, the TTFF is increased, as it isnecessary to receive several messages in order to gather the required information.Another drawback of these strategies is their low robustness against small satellite outages(i.e. urban environment or antenna masking during aircraft manoeuvres).

7.4 ANALYSIS RESULTS

The almanac is a set of parameters which allow the user to compute approximate satellitepositions in order to have an aid in their acquisition. The almanac specially improves theTTFF in a warm start of the receiver although it was not possible, in the frame of thisinvestigation, to give a finale figure to such a parameter since its strong dependence on themessage structure and on the receiver architecture (topics which are out of the scope of theWP2.2.3 investigations).

Two possible solutions were analysed:v A GPS-like almanac provides parameters to fully define all constellation orbits

independently (in addition, since orbital elements are provided, a smooth degradation oforbit accuracy is obtained).

v A reduced almanac, using mean values of 5 orbital elements for all satellites in eachorbital plane plus all mean anomalies, can provide sufficient accuracy with asignificant reduction of the number of parameters. The only main assumption is that theconstellation configuration (i.e. the number of orbital planes) will never be changedduring the entire operational life of the system.

Following the performed investigations, the latter approach is the recommended one.Although such investigations were accurate, some of the assumptions and hypothesis onwhich this solution is based could need for further verifications in order to consolidate theanalysis. As an example, it is requested that the satellites must be put into accurate and stableorbits. In the frame of the performed analysis it was assumed that when the performancerequirements for orbit stability are met, the proposed almanac is valid (see Section 8 forfurther considerations).

For what concern the ephemeris data-set, the analysis of operational performance of GPS andGLONASS navigation messages showed that the GPS message (15 parameters) interval ofvalidity is clearly greater than GLONASS (9 parameters). In addition, the degradation ofaccuracy is much smoother.

From the analysis performed for Galileo orbits, it has been concluded that:v The Stroboscopic propagator and the SPOT model do not satisfy the accuracy

requirements for Galileo.

v The GPS message takes into account all major characteristics observed in the evolutionof orbital elements. Some improvements, however, have been presented:§ Harmonic corrections to the LAN.§ Inertial to Earth-Fixed frame rotation parameters.

v Better results are obtained when using the rotation parameters. However, benefits are notsignificant below 4 hours of fit interval.

v The polynomial approach of the orbital elements for short periods of time does not satisfythe accuracy requirements for Galileo with an acceptable number of parameters.

GALA REF :DATE :

Gala-als-dd-01412-04-2001


v The use of Lagrange interpolation of the state vector is an alternative for the ephemerismessage, however it requires a high number of parameters (it is equivalent to the use ofseveral consecutive GPS-like messages, in addition, there is a high degradation ofaccuracy outside the message validity interval).

v A numerical integrator approach has also been considered. This kind of approach seemsmore useful for on-board processing (the satellite computes and broadcasts its ownposition):§ The implemented force model shall take into consideration:

♦ Earth’s gravity field (from 5x5 to 8x8 harmonics).♦ Sun and Moon gravity perturbations.♦ Solar radiation pressure.

§ Precise initial state vector, solar radiation pressure coefficient and Inertial toEarth-Fixed frame rotation matrix shall be available for the propagation (16parameters).

§ With this strategy, sufficient accuracy is achieved for a 12-hour propagation, withsmooth degradation in longer intervals. The major drawback is that morecomputational load (CPU time, memory and data storage) than with the othermodels is required.

v With an on-board processing approach, it must be considered that the receiver needs tocompute satellite positions between two consecutive messages, therefore it is necessarysome kind of short-term predictions. 2nd order Lagrange interpolation can satisfyaccuracy requirements for up to 60 seconds. The major drawback of this strategy is thelow robustness against outages.

v For GEO satellites, the best option is to use the same kind of message than for MEOones, therefore the navigation message and user algorithms will be the same:§ GPS-like messages are also valid for GEO satellites with comparable accuracy

results.§ Lagrange interpolation behaves better for GEOs (lower order is required for

similar accuracy within the same fit interval).

v The use of a GPS strategy can provide very satisfactory results for 3 hours updateinterval, with a smooth degradation outside the fit interval and keeping compatibilitywith current technology:§ Four messages will cover the 12 hour orbit predictions generated from the OD

process. All messages can be computed and uploaded to the satellite in a singlestep.

§ The messages could be fitted to a 4-hour interval (the impact in orbit error is stillmarginal), though the nominal period of update period will be 3 hours. This waythere is a 1-hour overlap interval, which will be helpful against short outages ordelays.

§ The satellite selects the adequate message to be broadcast at every time.§ Successive uploads (valid for 12 hours) can be scheduled for instance every 9

hours. This way there will be valid data on board for 3 hours, in order to maintainsystem performance if unexpected upload delays occur.

This latter solution represents the proposed Galileo ephemeris data set.

GALA REF :DATE :

Gala-als-dd-01412-04-2001


8 BASELINE FOR THE STUDY

The following section runs through the analysis performed in the previous chapters andrepresents the baseline of the study as discussed in the time elapsed from the GALA Kick-OffMeeting (December 1999) and the PM5 (October 2000).The specific portions of the Galileo navigation message considered in this document, theirvalidity time, the parameter definitions and the shown data flow are reported and summarisedhereafter.

Although deep investigations have been performed covering the various data-sets within theGalileo navigation message, some trade-offs could need for further consolidations before thecomplete finalisation. Some considered assumptions and hypothesis could, for example,require some more verifications.

The proposal to adopt a reduced almanac, for instance, implies (as showed in Sections 7.2 and7.4) that the satellites must be put into their orbits with enough accuracy and stability to fulfilthe required constellation performances (i.e. the relative drift of the satellites in the sameplane needs to be accurately controlled). The Galileo constellation, however, has beendesigned to be stable (more detail may be found in [RD 28]), as a consequence, the proposedalmanac does not impose any particular constraint to the satellite control but the Galileoperformances themselves do. This may be fulfilled, in fact, with an adequate orbit design,such as the one considered for the analyses.When the performance requirements for orbit stability are met, the proposed almanac is valid.In addition, putting the satellites into their orbits with the required accuracy is not believed tobe a major constraint (many satellite missions have already achieved this goal). In any case averification of such hypothesis is mandatory although it was not possible to perform it in theframe of this document.

Analogous considerations may be adduced for the other considered data-sets. In the case oflocal differential corrections, as a further example, it was not possible to precisely define thevalidity area since of the various possible situations which may be considered and possibleatmospheric degradations. Only an order of magnitude of the area size in which theenhancements were obtained, has been given.

8.1 IONOSPHERIC CORRECTIONS

The Galileo system is envisaged to provide a dual frequency signal for all services, includingOAS. Therefore, in principle, there is no need to provide a ionospheric model orionospheric corrections as a part of the navigation message, since the Galileo userequipment shall have the capability to retrieve the ionospheric delay by measurement insteadthan by modelling.

Removal of the ionospheric corrections from the navigation message will have the advantageto shorten the length of the message itself, by reducing the data transmitted, and also toreduce the measurement and computational load placed on the ground segment andoperations.

However,ü in view of the fact that the great part of low cost GPS receivers that make up the mass-

market for most civilians applications today are single-frequency receivers, andü given the fact that a dual-frequency receiver may be more expensive than a single-

frequency unit,

GALA REF :DATE :

Gala-als-dd-01412-04-2001


it is envisaged to leave open the capability for a Galileo user to adopt a single frequencyreceiver. This in order not to limit the economic competitiveness of the Galileo low-end userequipment which may develop into a significant and large portion of the market and allow afair competition with equivalent GPS user equipment.

For real time applications which need a high grade of accuracy, furthermore, ionosphericcorrections are very useful, because they will benefit quick ambiguity solution, which willreduce measurement time and, therefore, cost.Ionospheric information may also be needed in case of ionospheric irregularities, especiallyfor user which have to rely on high integrity.

If the ionospheric corrections are considered and implemented, two different solutions may beadopted to broadcast such information to the end-users (Table 8-1).

Table 8-1. Ionospheric correction parameters for the considered options.

Klobucharmodel

WAAS/EGNOSGrid Point model

Parameters 8 5(per each Grid Point)

Estimated data size (+)

(per satellite)64 bits 205 bits + 7 spare bits

(for each block of 15 IGPs)

Validity time hours 10 min- hours(+) The bits reported in the table do not take into account for

warnings flags, age of data, health, parity, TLM, HOW, etc.

Option 1 (Klobuchar approach)The former possibility is limited to a simple model of less accuracy comparable with theKlobuchar one (or equivalent), given the fact that it will serve only the lower end of themarket, where positioning accuracy requirements are relatively low (see Chapter 4).Following the GPS model, 8 parameters per satellite with a total estimated data size of 64 bitsare sufficient (8 bits per parameter). Their validity time is hours.

Option 2 (WAAS/EGNOS grid point model)An alternative solution is based on the WAAS/EGNOS grid point concept (see Chapter 4).Beside the ionospheric delay information, this model provides also regional error estimates.Furthermore Klobuchar approach is of less worth especially in critical ionospheric regions.For these reasons such approach for ionospheric corrections is the recommended one.For the grid point model implementation, 5 parameters per Grid Point are needed (namely,the band number, the block ID, the IGP Vertical Delay Estimate , the Grid IonosphericVertical Delay Error Indicator and the IODI). To describe a complete block composed by 15IGPs, a data size of 205 bits(15) (plus 7 spare bits) is necessary. Their validity time is in therange of 10 min-hours.The overall grid (covering the Earth) is composed by 1808 predefined IGPs and this grid isdivided into 9 bands, 8 of which contain 201 IGPs, whilst the ninth one contains only 200IGPs. Each band is, in its turn, divided into a maximum of 14 blocks, therefore each blockcontains a maximum of 15 IGPs in such a way that block No. 0 contains the first 15 IGPs,block No. 1 the second 15 IGPs and the last block contains less than 15 IGPs. As aconsequence, the stated 205 bits describe an entire block which contains 15 IGPs.

(15) In fact, 13 bits are necessary for each grid point. With 15 Grid Points, 195 bits arerequired. To these bits, 4 bits for the band number, 4 bits for the block ID and 2 bits for IODImust be added, for a total of 205 bits.

GALA REF :DATE :

Gala-als-dd-01412-04-2001


In the case each satellite needs to broadcast the ionospheric corrections corresponding to thetotality of the Grid Points (which compose the overall Grid), 23514bits(16) should benecessary. However an accurate broadcasting strategy could be adopted. The Galileo MEOsatellites have a theoretical covering angle of roughly 112°. If it is supposed that every MEOshall broadcast information for its all footprint area, it has to broadcast the ionosphericinformation for no more than three bands (1 band covers approximately 35° latitude).With this broadcasting assumption each satellites requires for a maximum of 7849 bits(always with a validity time of 10min-hours). A further reduction in the number of bits maybe achieved if considering the fact that it is not necessary to broadcast the informationconcerning all the blocks which cover one band that includes all latitudes (MEO satellites areused).An alternative assumption could take advantage of the fact that 30 MEOs compose theGalileo constellation, therefore each satellite could broadcast ionospheric information for asmaller area with respect to its footprint. Only one band, for example, could be covered byeach satellite. In such a case, however, intense ground evaluation to correctly control theoverlapping of the various bands, could be necessary.

In any case, since it is not an aim of this document to design the broadcasting strategy of thedata, it is not possible to state which is the total number of bits necessary to broadcastionospheric corrections (it depends, in fact, on the adopted transmitting strategy). In any caseit is possible to assume within the Galileo navigation message single packets of 205 bits each,which are necessary to describe one single block of 15 IGPs. The number of the transmittedIGPs will be defined by the transmission strategy designer.

Regarding the suggested update rate of the data, the Egnos values can be reported asreference. The maximum data update interval for ionospheric corrections is 300s (i.e. 5 min),therefore all users should be guaranteed to have consistent information within this time. TheEgnos system itself, however estimates the GIVD/GIVE every 60s and updates the value ofthe IGPs depending on the gradients of the previous measurements.

Finally, the reader must, in any case, keep in mind that besides from which option is adoptedto broadcast these positioning corrections, the effects related to scintillation phenomena arenot compensated by the presented models and the problems of system integrity in criticalionospheric regions are still unsolved even for multi-frequency users.

8.2 CLOCK PARAMETERS

No significant changes are foreseen in this specific item (with regards to GPS solution), otherthan the possible addition of the offset between the GPS time and Galileo time (plus apossible drift term) in case full interoperability between the two systems is desired. This inorder to not waste an additional satellite for the computation of the time offset between thetwo systems in the navigation solution. This follows from the fact that it is fairly easy toestablish an accurate transformation between geodetic reference frames (WGS-84 for GPSand an ITRF96 for Galileo), since their relationship can be fixed at a given date.

Note that the time reference evolves continuously with time, even if both systems (Galileotime and GPS time) are tied to UTC, as realised in different and geographically separated

(16) In fact, 13 bits are necessary for each grid point. With 1808 Grid Points, 23504 bits arerequired. To these bits, 4 bits for the band number, 4 bits for the block ID and 2 bits for IODImust be added, for a total of 23514 bits

GALA REF :DATE :

Gala-als-dd-01412-04-2001


laboratories. Recent discussions have shown that comparisons between GPS common viewand two-way time transfer between laboratories in the USA and Europe are possible withnanoseconds precision and 10 to 20 ns accuracy, the latter figure mainly due to calibrationerrors or inaccuracies in ionospheric delay modelling(17).

The proposed Galileo solution concerning the clock parameters is, therefore, very similar tothe GPS one (see chapter 5). Only the IODC parameter is replaced by the IOD (Issue of Data)parameter which, together with the SNF index, takes also into account for the IODEparameter. As a consequence, 4 clock parameters per satellite are sufficient to correct theonboard time standards, namely the reference time and three polynomial correctioncoefficients (the Estimated Group Delay Differential is not taken into account in thisparameter computation although it is essential for clock correction).The total estimated data size depends on which type of clocks are used onboard the satellites.GPS was designed for caesium standards and represents these 4 parameters with 62 bits. Incase Rb standards are adopted, the total data size of the clock parameter should be 70 bits (incase of OCXOs 85 bits). These 70 bits guarantee a minimum physical steering update ofclocks time interval of about three years (for Rb standards). To these bits, 6 bits of the Issueof Data and 8 bits of the Estimated Group Delay Differential (TGD) must be added (Table8-2). The validity time can be assumed similar to the GPS one (i.e. hours ).Note that the Week Number (8 bits) is not needed for the clock corrections in the ephemeris,but it is essential for “long term” corrections such as the almanac data or UTC/Galileo andGalileo/GPS differences.

For what concern the clock data update time, an high uploading frequency (45 min) for thecorrections of the clock errors is technically practicable and fulfil the more stringentrequirements (45 min data update → UERE=0.65 m), although the repercussions on theGround Segment architecture and on its workability have not to be underestimated (see alsothe GNSS2 Comparative System Study outputs). With an uploading frequency of 3 hours theUERE remains below 1 m (from GNSS-2CSS). Currently, in GPS the update time is 2 hoursalthough curve fit interval is 4 hours.

Table 8-2. Galileo clock correction parameters for ephemeris message: Rb clocks

Clock correction

Parameters 4 (+2)


(per satellite)70 bits

(+6 bits for IOD+8 bits for TGD)

Validity time hours

(+) The reported data size do not take intoaccount for warnings flags, age of data,health, parity, TLM, HOW, etc.

When the almanac is considered a reduced precision is requested. As a consequence, a total of26 bits per satellite are sufficient to describe the clock parameters plus 16 bits per almanacdata set. These 16 bits are necessary to represent the week number WNa and the almanacreference time t0a which are only needed once a time in the almanac data and not per eachsatellite (see chapter 5).

(17) Meetings of the CCTF Working Group on GPS/Glonass Time Transfer Standardisationheld at Dana Point (Ca.) on December 6, 1999 and of the CCTF Working Group on Two-WayTime Transfer held at the USNO on December 13-14, 1999.

GALA REF :DATE :

Gala-als-dd-01412-04-2001


For what concern the steering of Galileo System Time to UTC, the GPS solution can beadopted too. Currently, 8 parameters are used in GPS to realise the UTC-GPS timecorrelation, with a data size of 104 bits. As the consequence, also in the case of the UTC-Galileo time correlation, 104 bits are sufficient (see chapter 5). The validity time of such datacannot be clearly specified since it depends on which application the user needs thisinformation. Wide time offsets can be accepted in everyday activities, whilst, industrialprocess may require synchronisation in time of 10-3 or 10-6 s.In any case the UTC/GPS data (realised in GPS) are 6 days curve fits. In fact, the GPSalmanac (and UTC parameters) is (are) updated by the control station at least once every 6days. Galileo can adopt this update time, too. It is, however, clear that such update timeshould be as short as possible, but this is a question of the possibility of the ground stationsystem to update the data on the satellites. In any case such time information is not the moststringent in the entire Galileo system.

Finally, to broadcast the difference between Galileo System Time and GPS time only 72 bitsare necessary. The parameters concerning the leap seconds, in fact, are useless since bothsystems (GPS and GALILEO) have continuous time scales and the difference between thesetime scales shall be very small (see chapter 5).

If a complete interoperability of two independent navigation systems is desired, the followingtiming strategy should be considered. When combining GPS and Glonass measurements, forinstance, one independent measurement (i.e. one satellite) is lost in order to compute theoffset between the two time scales in real time as an additional unknown in thepositioning/timing solution. Given the current level of capability of an independent timesynchronisation between the two time scales(18) will not provide enough accuracy to resolvethe offset at the level required not to degrade the combined positioning solution.

Therefore, a different strategy is required. A possible solution is given by the followingprocedure:

1. all Galileo Orbitography and Synchronisation Stations will carry on GPS measurementsin addition to Galileo Measurements;

2. each system will process independently the data acquired by its own satellites, andproduce a system state vector yielding the orbit and the time offset with respect to eachsystem reference frames;

(this will allow the independent use of each system by any user under the currentcircumstances)

3. in addition, the Galileo Orbit and Synchronisation Processing Facility at the NavigationControl Centre will process all the measurements (pseudoranges) acquired by allsatellites of the two systems in a combined timing-only solution based on the nominalorbits previously determined(19);

4. this will provide the clock parameters of each individual satellite with respect to a timescale which will be the average of the independent time scales of the two systems. Since,in turn, each clock parameters are already reference to these independent time scales, the

(18) This can be carried on, for instance, by the use of a two-way method between the USNOand the Galileo Navigation Control Center.(19) These are the orbits that in any case will be available to the users, so no degradation isforeseen by this process with respect to the user solution.

GALA REF :DATE :

Gala-als-dd-01412-04-2001


results can be expressed also as an average offset and drift of the two time scales withrespect to each other;

5. the last parameters will allow to correct for the offset between the two navigation systemtime scales with an accuracy comparable to the expected navigation (positioning)solution in each of the two systems, thereby increasing the overall accuracy of the userposition determination because of the greater number of available satellites, whereas nosatellite is wasted in the process.

It is likely that the data reduction in the computation of the average common time scalebetween the two systems will likely be improved by:

• an "a priori" knowledge of the algorithm used to construct the individual time scales;• a prior notice of any change that can occur in the weight assigned to the individual clocks

in each system (the "q"'s parameters in the GPS Kalman filter processing of the timingdata).

Since the exchange of this data does not seem to pose a significant threat to the security ofeach system (especially in non-crisis conditions), and since this procedure saves the completeindependence of each system with respect to the other under any circumstances (whileallowing the full interoperability of the combined systems), it is suggested that this possibilityshould be studied and pursued in the appropriate and relevant tasks.

8.3 DIFFERENTIAL CORRECTIONS

Differential corrections are intended to partially eliminate unmodelled biases from thepropagation delay. Such biases, for the user equipment, comprise mainly the atmosphericdelay and errors in the satellite position and time due to residual errors in the ephemeris, orbitpropagation and onboard clock estimation.

Tropospheric delays are mainly affecting timing receivers, since for navigation sets theyappear in the solution mostly as a common-mode delay on the pseudorange measurements,and therefore their contribution affect mainly the clock offset term in the solution.

Moreover, when addressing differential corrections for wide-area augmentation system, theeffectiveness of the tropospheric correction obtained by differential correction will degraderapidly as the distance from the reference station increases, and therefore tropospheric delaycannot be compensated adequately in a wide-area scenario.

Still, continental differential corrections may provide some benefits in further reducing theresidual errors affecting the broadcast satellite position and time. In this wide-areaenhancement, for each Galileo satellite, the differential information message should contain aquickly and a slowly varying component of the pseudorange error.

Better accuracies (sub-meter level) can be achieved considering local differential corrections.Although the performed investigation need for consolidation, the current status of the analysishighlights the fact that 6 parameters are sufficient to describe local improvements (Table8-3). The station ID and the time reference constitute a common information for all thesatellite in view (23 bits per reference station). The pseudorange correction, the range rate ,satellite ID and the Issue of Data , instead, must be broadcast for each single satellite in view(37 bits per satellite).The validity time is driven by geometrical degradation of the pseudorange correction and byatmosphere effects. A validity time in the order of 120 s must be considered. Broadcasting

GALA REF :DATE :

Gala-als-dd-01412-04-2001


strategy, however can give an aid to relax the update rate of these data (see specific section inthis document concerning differential corrections).

Table 8-3. Local differential corrections parameters

Local differential correction

Parameters 6

Estimated data size 37 bits per satellite23 bits per reference station

Validity time minutes

Differential corrections broadcast as a part of the Galileo navigation message may impose anadditional burden on the system complexity, especially in regard to the integrity and liabilityin the use of the differential corrections themselves.Differential corrections, if considered part of the Galileo requirements in terms of availabilityand integrity, will raise considerable issues in terms of reaction time (since the alarm limit forintegrity may be considerably reduced given the high accuracy obtainable from differentialcorrections) and, consequently, in terms of liability to the users.

In addition, the broadcast of differential corrections will increase the amount of data to betransmitted as a part of the navigation message. To be effective, differential corrections mustreach the users quickly, therefore a high-data rate is required, which is contrast with thesuggestions that will be set forth in the following paragraphs concerning the data rate.

Moreover, they will require a continuous data uploading for maximum effectiveness. Thismay place an additional burden on the system operations and ground segment(communication links and uploading stations) even if differential corrections are intended tobe broadcast by GEO satellites only (if any will be part of the final Galileo constellation).

Therefore, it is suggested that, if no sizeable user group can be found to require increasedaccuracy such as that can be produced only by differential corrections, differential correctionswill not be incorporated as a part of the navigation message.

This by no means implies that a differential corrections service may be established by a third-party (for wide-area or local-area augmentation) outside and independently of the Galileosystem.

8.4 DATA RATE CONSIDERATIONS

Since the finale navigation message structure and data rates will not be define in the presentstudy (other WPs in the frame of the GALA and GALILEOSAT studies are in charge todefine such signal structure and the bit rate in the various channels), present section reportsonly simple considerations. Please, refer to the relevant documents for the finale conclusions.

To decrease the Time-To-First-Fix (TTFF) one possibility is to increase the data rate for thenavigation message; the second alternative is to reduce the amount of data. As a firstrecommendation it is suggested to try not to increase the data rate, as far as it is feasible.Increasing the data rate will not allow the bit period of the navigation message to be usedeffectively for pseudorange ambiguity resolution and will decrease the resistance to jammingand interference of the navigation signal. This has been already proven poor for the C/Acoding scheme used by GPS (1.023 Mchip/s and 50 bps data rate).

GALA REF :DATE :

Gala-als-dd-01412-04-2001


Therefore, it is suggested to consider as a baseline the same option (50 bps for the data rate),with the possibility to increase the chip rate for the Galileo system above 1.023 Mchip/s, ifthe bandwidth allocation will allow. Current GALILEO baseline, however, adopts a bit rate of150 bps, having a symbol rate of 300 sps and a code rate of 2046 Mcps.

The precision code will be a more lengthy sequence, which may be periodic or not over theperiod of validity, possibly encrypted. On the precision code we envisage that no modulation(navigation message) will be added in order to conserve the full ranging accuracy to the code.The short code and the precision code will be bi-phase modulated, with a 90° relative phaseshift, over each carrier (as in GPS), or QPSK modulated.The current GALILEO modulation scheme baseline is to adopt QPSK techniques.

Since two separate carriers are used to convey the navigation message, an interestingpossibility arise if one of the carrier carries the navigation message at low data rate, therebysaving the jamming resistance capability of the navigation signal. The second carrier can bemodulated with the very same navigation message but at a considerably higher data rate todecrease the TTFF whenever possible.

In presence of high interference, the user will acquire the navigation message from the carriertransmitting at low data rate, while in a clean electromagnetic environment, the high data ratemodulation can be quickly acquired on the second carrier, considerably reducing the TTFF.

8.5 ALMANAC CODING

The acquisition of the almanac plays an important role in reducing the TTFF. In the currentGPS and Glonass implementation, the almanac is devised as a mean to quickly acquire thevisible satellites when only simple receivers (single or few independent channels at most)could be envisaged.

The time necessary for the transmission of the entire almanac is a limiting factor for a coldstart TTFF. The total duration of the almanac broadcast by a GPS satellite is in excess of 12minutes, and 2.5 minutes are required to retrieve the almanac for a Glonass constellation(using a single channel receiver).

It is difficult to explicitly provide a final figure for the TTFF within the Galileo system in theframe of this document, since this value depends also upon the receiver architecture andimplementation. Currently, many aspects are still not definitive and other WPs areinvestigating the receiver design.As a term of comparison, however, the performance of modern GPS receivers may beconsidered: a TTFF (cold start) of only 120 s for the GPS system is feasible, a 6 timesimprovement over the performance of a single-channel receiver(20). Most modern receivers, infact, can update the almanac periodically and store its most recent version (together with thereceiver position) in dedicated memory. A clock can also be kept operating when the receiveris off or in standby mode, so as to minimise initial acquisition time for the next start up.Normally, when a receiver is initially turned on, time must be allowed for the receiver crystaloscillator to warm up and stabilise at its normal operating temperature. In GPS receivers it

(20) Assuming for the last that only the almanac is retrieved and no errors occur during dataacquisition. Consider that the 120 s for TTFF include also the carrier and code acquisition,plus pseudorange measurements from a minimum of four visible satellites and the navigationsolution processing after the almanac has been acquired and processed.

GALA REF :DATE :

Gala-als-dd-01412-04-2001


takes up to 6 minutes to complete this process. If the receiver is provided with a mode thatkeeps the oscillator warm, this contribution to TTFF can be avoided.

A number of enhanced acquisition techniques have been developed for modern receivers.TTFF performance can be significantly improved by the use of multi-tap correlators andmulti-channels search algorithms. Several possibilities have been also examined in the presentinvestigation and will constitute the baseline for further analysis, mainly:

1. reduction of the data amount (or of the number of parameters) required to broadcast thealmanac versus the accuracy degradation that can be expected in time (in this case areduced almanac will be broadcast, allowing to decrease the time required to acquire thefull navigation message);

2. elimination of the almanac by having each satellite in the constellation to transmit, inaddition of its own, the ephemeris of all (or part of) the other satellites in theconstellation; this will require a reassessment of the models used for the orbitpropagation in the user set and the coding of the relevant parameters in the navigationdata message.

The former approach, i.e. the reduction of the number of parameters required tobroadcast the almanac, is the recommended one.The GPS almanac provides a smooth degradation in accuracy versus time, with betteraccuracy and graceful degradation after the validity period than the simpler Glonass almanac.Simulations carried on by GMV [RD 21] prove this assumptions, as well as confirm the orderof magnitude of the limits for the accuracy degradation over and outside the reporting periodgiven as requirements in the ICD-200 (rev. C, [RD 6]).

In order to perform a valid comparison between the parameters needed to describe the variousconstellations of different navigation systems (namely, GPS, Glonass, Galileo), it wasnecessary to consider the same number of satellites. Therefore, only for comparison reasonsan equispaced Galileo constellation of 24 satellites (3 orbital planes, 8 satellites per plane)was assumed.

Please note that the driving factor in the analysis of the orbital model for the message is thebehaviour of the orbits, that is, the main forces acting at the satellite altitude. The order ofmagnitude of the relevant perturbations (Earth gravity, Sun and Moon gravity, Solar radiaturepressure,…) and therefore the behaviour of the orbits, does not vary significantly for the 24MEOs, 30 MEOs or even the GEO orbits. Thus the analysis results can be applied for allcases (in fact, the MEO orbits for the 24 MEO and 30 MEO constellations are very similar).The conclusion, as a consequence, can be easily extrapolated for the true Galileoconstellation.

With the equispaced Galileo constellation of 24 satellites (3 orbital planes, 8 satellites perplane), a modified, reduced-set almanac has been tested to assess the increased degradationover the current GPS almanac (see Section 7.2). The proposed almanac consists of:

ü Mean of semi-major axis, eccentricity, inclination and right ascension of the ascendingnode for all planes (4 parameters per plane, for a total of 12 parameters).

ü Argument of Perigee of the first satellite in each plane, assumed equal for all satellites inthat plane (1 parameter per plane, i.e. 3 more parameters).

ü Mean anomaly of all satellites (1 parameter per satellite, i.e. 24 more parameters),computed by adjusting the (true) mean anomaly of each satellite to compensate for theslight changes in the argument of perigee of each individual satellite with respect to thefirst satellite in each plane (given argument of perigee).

GALA REF :DATE :

Gala-als-dd-01412-04-2001


Therefore, the total almanac will result in 39 parameters to describe a full constellation of 24satellites in 3 planes, versus the 168 parameters (7 parameters on 166 bits per each singlesatellite) required by the GPS almanac (only orbit parameters) or the 144 parameters (6parameters on 99 bits per each single satellite) in the Glonass case (only orbit parameters).Preliminary results of simulations, to be confirmed by further analysis, yield a degradation ofa factor of two over the same period when compared with results obtained by the use of aGPS-like almanac [RD 21].Adopting the same GPS bit assignation to the proposed parameters (i.e. [24 bits] to the squareroot of the semi-major axis, [16 bits] to the eccentricity, [16 bits] to the inclination(21), [24bits] to the right ascension of the ascending node, [24 bits] to the argument of Perigee, [24bits] to the Mean anomaly) each orbital plane is described by 104 bits. To these bits it isnecessary to add 24 bits to determine each satellite position in the plane.Since the almanac is intended to provide an aid to signal acquisition, it is not necessary a highprecision level in satellite position, therefore the number of bits required per parameter can bereduced.Although the proposed almanac is less accurate than GPS one (see Par. 7.2.2.2), the accuracylevel remains within the same order of magnitude, therefore the same GPS validity time ofseveral days can be assumed also for Galileo (Table 8-4).

Table 8-4. Almanacs in the case of GPS, Glonass and Galileo systems for a 24-satellite constellation

GPS solution(24 satellites)

Glonass solution(24 satellites)

Galileo solution(24 satellites)

Orbit parameters (only)

168(7 per satellite)

(toa, a f0,af1 not considered)

144(6 per satellite)

39(1 per satellite+

5 per orbital plane)


per satellite144 bits per satellite

(only orbit parameters)99 bits per satellite

(only orbit parameters)104 bits per orbital plane

24 bits per satellite

Validitytime

Several days (up to 180)(update time: 6 days)

Several days Several days

(+) The reported data size refers exclusively to the orbit parameters. Bits related towarnings flags, age of data, health, parity, TLM, HOW, etc. are not taken intoaccount in the table

Extrapolating the solution for the current Galileo 30 MEOs constellation, the proposedalmanac will result in 45 orbit parameters. As a consequence, the total data flow for thealmanac (only for the section dedicated to the satellite orbits), if 30 MEO satellites and 3orbital planes are assumed, is 1032 bits. In any case, space may be reserved in thebroadcasting signal to transmit parameters for additional satellites in the constellation. In thecase room for a 33-satellite constellation deployed over 3 orbital planes will be reserved inthe navigation message, the almanac will be composed by 48 parameters and 1104 bits .

If the MEO+GEO option is considered, note that for the GEO satellites the only requiredparameters are their longitude. There is, in fact, really no need to send the 6 keplerianparameters for the GEOs. Since they are allocated in a fixed "slot" in the geostationary orbit,frequent manoeuvres are performed in order to keep the satellite within the assigned narrowboundary, which is typically of a few kilometres size. This is sufficient for the almanacpurposes, so it is possible to take benefit of it and use the GEO longitude as the only almanacparameter (just as it is used to point antennae to communication GEOs). As a consequence,only 1 parameter per GEO satellite is needed, therefore, 47 orbit parameters will be necessary

(21) In GPS the offset from the nominal inclination is reported.

GALA REF :DATE :

Gala-als-dd-01412-04-2001


for the 24MEO+8GEO constellation. Note that the GPS message is also valid in this case asexpected due to the similarity of acting perturbations mentioned before.

The previous data flow in the presented almanac definition, refers exclusively to the orbitparameters. Also the clock parameters for all the satellites in the constellation need to beconsidered (refer to the specific Section 8.2 on Clock corrections). Other type of parameters,such as identifiers, health, warning flags, parity, age of data, time information, etc, which areessential part of the navigation message, have not been considered since it is not the task ofthis document to design the Galileo message structure.

8.6 EPHEMERIS BROADCAST AND CODING

8.6.1 Ephemeris coding

The GPS orbit propagator is based on a Keplerian set, to which 9 correction coefficients(22)

are added. For the Glonass system, instead, a numerical integrator is used (Runge-Kutta, 4th-order), with reduced accuracy over time; the advantage is that this latter set requires only 9parameters (plus the one representing the epoch of ephemeris validity). However, the shortvalidity interval, which affects the up-link rate, and the great degradation outside the validityinterval, are such that the performances are not acceptable to meet the Galileo requirements.In addition, Glonass approach is not better than GPS in term of receiver computational load.

A different coding strategy for the ephemeris, with the aim to reduce the size of the data set,is based on a different selection for the model used in the user sets for the orbit propagation.Looking at other models, the so-called "stroboscopic model"(23) has been deemed not suitableas a user algorithm [RD 21], since its validity covers intervals shorter than one revolution(short arcs).

Another model is the "SPOT model" [RD 22]; developed for a LEO satellite, wheresignificant perturbations due to the non-sphericity of the Earth and drag can be expected, itwas used for SPOT in the context of the ARTEMIS mission.This accounts for the following main orbital perturbations:

• secular and short period perturbations due to the oblateness term J2;• significant short-period perturbations, due to J2,2;• short-period positions perturbations (due to gravity);• long-period perturbations (due to gravity);• atmospheric drag.

When the analytical equations of the model are cast together, only 13 parameters are requiredto derive the Keplerian elements (or combinations thereof, such as in the case of eccentricityand argument of perigee). The model is computationally more complex than the GPS one,both for the ground parameter determination and for the user propagator, but it is well withinthe current availability of user set computational power. Unfortunately the analysis carried outto validate the applicability of this model to the Galileo orbits propagation, demonstrates that

(22) Six harmonic coefficients, inclination and LAN rates plus mean motion correction(23) This is an analytical integrator based in the "variations of parameters" approach,integrating the average effects of the perturbations over an orbit.

GALA REF :DATE :

Gala-als-dd-01412-04-2001


also this approach is not suitable (the obtained accuracy does not meet the Galileorequirements).

A possible alternative is to devise new sets of parameters; not least, a simplified numericalorbit integrator, yet enough accurate to satisfy the Galileo requirements, may be proposed.The approach will be similar to the one followed by the Glonass system, whereas the luni-solar perturbations can be pre-computed with the required accuracy and hard-coded for a setof years in look-up tables.

Finally, the simplest possibility of all has also been examined, i.e. the direct broadcast of thesatellite position and velocity vectors, with the required accuracy, in real time. In this case thepropagator would be running on the satellite computer and no user algorithm would berequired, thereby minimising the complexity and cost of the user receiver. This approachwould also minimise the number of parameters transmitted.

Taking into account the results obtained by the investigation performed on differentephemeris coding strategies, the current baseline for Galileo is to adopt the GPS orbitpropagator. The GPS ephemeris model, in fact, resulted to be adequate for Galileo in termsof accuracy, number of parameters, validity interval. As a consequence the Galileo ephemerisfor each satellite are composed by 15 parameters (6 keplerian parameters, 6 harmoniccoefficients, inclination and LAN rates plus mean motion correction). To these, the IODE(Issue Of Date, Ephemeris) and the toe (reference time for the ephemeris data set) must beadded. However, as reported in the previous section related to the clock corrections, the IODEparameter (represented in GPS with [8 bits]) may be described by the IOD [6 bits] and theSNF [3 bits] parameters. As a consequence, the total data size of these 17 parameters (theSNF parameter is not considered) is 364 bits (GPS uses 366 bits since the IODE has 2 morebits with respect to the IOD parameter). The validity interval for the Galileo ephemerismessage is 4 hours, as in GPS (Table 8-5). The proposed update interval, however, is 3hours though it is suggested the use of a 4-hour fit interval, in order to keep a 1-hour safetyoverlap interval between successive messages. This strategy is also used by GPS (its messageis updated every 2 hours, but is fitted using 4 hours).

Table 8-5. Ephemeris data in the case of GPS, Glonass and Galileo systems

GPS solution Glonass solution Galileo solution

Parameters 15+2 9+1 15+2 (GPS like)

Estimated data size (24) 342+24=366 (168+7)=175 364

Validity time 4 hours(+) 15 minutes 4 hours(++)

(+) GPS message is updated every 2 hours, but it is fitted using 4 hours(++) The proposed update interval for Galileo ephemeris message is 3 hours, using a 4-hour fit interval

8.6.2 A possible alternative and broadcasting strategiesA different possibility which has been envisaged to reduce the amount of data in thenavigation message is to completely remove the almanac and broadcast the ephemeris only.For the acquisition phase, the ephemeris of all the satellites in the constellation could be

(24) The reported data size refers exclusively to the parameters necessary to the orbit prediction(for GPS and Galileo: 6 keplerian parameters plus 9 correcting coefficients, for Glonass: 3cartesian coordinates plus their first and second derivatives with respect to time). Bits relatedto warnings flags, age of ephemeris data, health, parity TLM, HOW, etc. are not taken intoaccount in the table.

GALA REF :DATE :

Gala-als-dd-01412-04-2001


broadcast. This in turn requires means to reduce the number of parameters necessary for theorbit propagation without decreasing the accuracy.However, it must be noticed that for a user in a definite location it is not necessary to retrievethe elements of satellites which are not visible, such as the ones positioned at the other side ofthe Earth. This will considerably reduce the number of elements broadcast.For a 6 or 8 satellites per plane constellation, the number of satellites per plane that the usercan see at any moment is 2 or 3 (TBC); this will yield 6 to 9 satellites in view, available tocompute the position solution. Therefore, it seems to be enough that each satellite in a planewill broadcast the ephemeris of itself and the preceding and following satellite in the sameplane(25).This approach will considerably reduce the amount of data within the navigation message,eliminating the transmission of the almanac altogether.

Note, however, that the broadcasting of the ephemeris of two additional satellites implies that30 more parameters (GPS uses 15 parameters for satellite ephemeris) need to be transmitted.In comparison, the proposed almanac requires 45 parameters for the 30 MEOs constellationand it is a much more robust solution. For instance, in case of a satellite failure, it would notbe immediate to obtain the data for the neighbour ones without the almanac. In addition, sincethe almanac is intended to provide less accuracy than the navigation message, the number ofbits required per parameter can be reduced. Therefore, it is possible that less bits are requiredfor the 45-parameter almanac than for the two additional ephemeris messages.

Considering again the three distinct ephemeris messages solution, a second possibility to evenfurther reduce the acquisition time is to stagger in time the broadcast of identical parts of themessage. Since each satellite will broadcast its own ephemeris and the ephemeris of theadjacent satellites, a strategy can be devised to transmit different portions of the samemessage from different satellites at the same time. This will allow multi-channel receivers tofurther decrease the TTFF by acquiring simultaneously data from separate satellites, reducingby an additional factor of 3 the TTFF.

Nevertheless, from the receiver point of view, the almanac is a powerful mean of improvingwarm start, which are much more frequent than cold starts in normal receiver operation. Theproposed idea to irradiate two additional ephemeris messages was carried out on the basis ofreducing the TTFF for cold starts, but did not take into account warm starts. The proposedalmanac, therefore, seems to be the most attractive solution, combining robustness, lownumber of parameters and a warm start speed-up.

A sort of “combined” option, that may help improving the TTFF (cold start) can, finally, beadopted. Each satellite transmits the full almanac, but irradiating first the data for theneighbour satellites. In such a way, acquisition of the adjacent satellites could be executedfaster, since the repetition of the full almanac is not necessary.

8.7 PROPOSED NAVIGATION MESSAGE DATA FLOW

Summarising the previous sections, the proposed Galileo navigation message data flow is,hereafter, reported. Only specific data packets of such message were analysed in the frame ofthis investigation, in particular:

• satellite clock data;• ephemeris data;

(25) It will be more difficult to extend this concept to satellites placed in different planes sincetheir relative phasing will change over time and moreover will depend upon the usergeographical position.

GALA REF :DATE :

Gala-als-dd-01412-04-2001


• almanac data;• ionospheric corrections;• differential corrections.

Since other WPs in the frame of the GALA and GALILEOSAT programs are in charge todefine the signal structure and the bit rate in the various channels, the finale navigationmessage structure and data rates will not be define in the present document.Furthermore, since up to now, such signal data rates and message structure are still notdefinitive, the data refresh time (i.e. the time necessary to the system to broadcast again theinformation disregarding the fact that it has been updated or not) for each set of the previousdata will not be reported hereafter.

For the considered data the shown sizes do not take into account bits related to warning flags,age of data, parity, TLM, HOW, coding, etc., since they refer exclusively to the “pure”information necessary for positioning computation.

A number of trade-offs were performed to investigate the interest/impact of transmittingwithin the navigation message the various data sets necessary for positioning computation.The outputs may be summarised as follows:

• Satellite clock data: no significant changes with regard to GPS approach can be adopted(refer to Par. 5.1 of this document).

• Ephemeris data: a keplerian data set plus 9 correcting coefficients (as for GPS model)can be adopted. Each satellite will broadcast its own ephemeris data (refer to Par. 7.4 ofthis document).

• Almanac data: reduced set of parameters can be selected. Each satellite will broadcastthe almanac for the entire constellation, transmitting as first information the data relatedto the adjacent satellites (refer to Par. 7.4 of this document).

• Ionospheric corrections : if this corrections will be adopted, the WAAS/EGNOS gridpoint model should be adopted for single frequency receiver (refer to Par. 4.4 of thisdocument).

• Differential corrections : if such concept is retained for CAS1 service and if it iscompatible with the frequency scenario, such corrections will be incorporated as part ofthe CAS1 navigation message (refer to Par. 6 of this document). In any case, localdifferential corrections relative to a specific reference station may be broadcast locallywith a dedicated ground transmitter (i.e. not within the navigation message).

Since the performed trade-offs highlighted that the GPS model is adequate for the ephemerisand the data clock corrections in terms of accuracy, number of parameters and validity time,the proposed data size for these specific parameters has been considered similar to the GPSone. The sensitivity analysis on the number of bits associated to each of these parameters hasbeen considered not necessary due to the confidence that can be expected on such data.

Also for the almanac data, a sensitivity analysis has not been performed. It must be remind, infact, that the requirements for the almanac are not so stringent. Therefore the bit assessmentfor such data is of less interest.

Taking into account the carried out trade-offs, the default Galileo broadcasting strategyrequests that each single satellite in the constellation irradiates its own exclusively ephemerisdata together with the full proposed almanac. In order to give benefits to the receiver TTFF,the data describing the neighbour satellites (with respect to the transmitting one) must betransmitted first. The repetition of the full almanac, in fact, is not necessary and theacquisition of the information related to the adjacent satellites, if executed immediately afterthe beginning of the almanac sequence, may improve the receiver first fix.

GALA REF :DATE :

Gala-als-dd-01412-04-2001


Table 8-6 reports the current data flow for the Galileo navigation message with somebroadcasting requirements in the case of the GALA study baseline, i.e. a 30 MEOsconstellation with three orbital planes, without ionospheric and differential corrections.

Table 8-6. Galileo navigation data: broadcasting requirements (30 MEOs case)

Typeof data

Estimated size(+)

(bits)Validity

Time Applicability

Almanac I(orbit parameters only)

104 per orbital plane24 per satellite

Several days(GPS update time: 6 days)

Whole system

Almanac II(clock corrections only)

16 per almanac data set26 per satellite days Whole system

Ephemeris 364 per satellite4 hours

(3 hours update time 4-hour fit interval)

1 satellite

Clock corrections(Rb standards)

70(IOD=6bits+WN=10bits not included)

Few hours(GPS update time:1hour)

1 satellite

Estimated Groupdelaly differential (T GD)

8 Few hours(GPS update time:1hour)

1 satellite

UTC/GSTcorrelation 104

(dependent on theapplication)

in GPS: 6 days curve fitsWhole system

GST/GPScorrelation 72 (dependent on the

application) Whole system

(+) Bits related to warnings flags, age data, health, parity, etc, are not takeninto account.

Since Galileo uses separate carriers to convey the navigation message, different bit rates maybe adopted. The navigation message can be transmitted on one signal at low data rate, savingthe jamming resistance capability. A second carrier can be modulated with the very samenavigation message but at a considerably higher data rate to decrease the TTFF wheneverpossible.

Currently, the various Galileo services adopt such approach (OAS 150 bps and 1250 bps,CAS1 150 bps and 1250 bps, SAS 150 bps, GAS 150 bps). Whatever is the service or the bitrate, the considered data sets are essential part of the navigation message. Table 8-7 showsthese relationships between the various contribution to the navigation message and the OAS,CAS-1, SAS and GAS services.

Table 8-7. The navigation message with respect to different service levels

Type of data OAS CAS-1 SAS GASAlmanac YES YES YES YES

Ephemeris YES YES YES YESEstimated Group delaly differential YES YES YES YES

Clock YES YES YES YESUTC/Galileo YES YES YES YESGalileo/GPS YES YES YES YES

A number of alternative approaches may be adopted within the Galileo navigation message,taking also into account the GALA study options. Table 8-8 shows how the single data setschange in the case of such Galileo options.Two possible solutions are reported in the case of ionospheric corrections. The former isperformed adopting the Klobuchar model, the latter is based on the WAAS/EGNOS gridpoint model. If the MEO+GEO constellation is considered, the almanac data (concerning theorbit parameters) must be modified as reported in Table 8-8, where also the MEO only

GALA REF :DATE :

Gala-als-dd-01412-04-2001


approach is reported for comparison reasons. Table 8-8 also reports the data flow necessary tobroadcast the local differential corrections in the case this option is considered within Galileo.No options for the clock parameters (both those in the ephemeris data and the ones in thealmanac) have been, up to now, foreseen.

Table 8-8. Galileo navigation data: options

Type of data Estimated size(+) (bits) Validity Time Applicability

Almanac - baseline (MEO only)(orbit+clock parameters)

16 per almanac data set (clock)104 per orbital plane (orbit)

24+26=50 per satellite (clock+orbit)several days

(GPS update time:6 days)Whole system

Almanac – option 1 (MEO+GEO)(orbit+clock parameters)

16 per almanac data set (clock)104 per MEO orbital plane (orbit)

24+26=50 per satellite (clock+orbit)several days

(GPS update time:6 days)Whole system

Ionospheric corrections-option 1 64 (klobuchar model) hours Whole system

Ionospheric corrections-option 2 205 per 15 IGPs (1 block)(WAAS/EGNOS grid point) 10 min-hours Whole system

Local differential correction 23 per reference station37 per satellite 120s Whole system

(+) The estimated data size refers exclusively to the specific parameters. Bits relatedto warnings flags, age data, health, parity, etc. are not taken into account.

The possibility to do not broadcast the almanac has been also considered. This alternativeapproach foresees that each satellite irradiates three different sets of ephemeris, the onerelated to its own data and those associated to the two adjacent satellites in the same orbitalplane (Table 8-9).

Table 8-9. Galileo navigation data: no almanac broadcasting case

Type of data Estimated size (bits) Validity Time ApplicabilityAlmanac - - -

Ephemeris 3*364=10924 hours

(3 hours update time 4-hour fit interval)

3 satellite

Finally, Table 8-10 reports the navigation message with respect to the different services(OAS, CAS-1, SAS and GAS) in the case of the considered options. As highlighted in thetable, it is foreseen to broadcast the ionospheric correction only on OAS signals, whilstdifferential correction will be disseminate within the CAS1 service.

Table 8-10. Navigation message options versus different scenarios

Type of data OAS CAS-1 SAS GASAlmanac YES YES YES YES

Ephemeris YES YES YES YESEstimated Group delaly differential YES YES YES YES

IONOS (klobuchar)IONOS (grid point)

YESYES

NONO

NONO

NONO

Clock YES YES YES YESUTC/Galileo YES YES YES YESGalileo/GPS YES YES YES YES

Differential correction NO YES NO NO

GALA REF :DATE :

Gala-als-dd-01412-04-2001


ANNEX A - RECALLS OF ORBITOGRAPHY ANDSYNCHRONIZATION

In the aim of the GNSS Comparative System Study (CSS), Alenia Aerospazio, GMV and IEN(Istituto Elettrotecnico Nazionale) were tasked to analyse and to assess the functions relatedto the Orbit Determination and Time Synchronisation (OD&TS) to individuate the mostsuitable options for each of the different architecture proposed. Moreover performanceassessment of the different alternatives had to be provided [RD 8].

INITIAL PROPOSED SCENARIOS

The proposed scenarios for the comparative studies have been:

• Scenario 1: On Board Centralised processing based on Two Way Ranging;

• Scenario 2: On Ground Centralised processing based on Two Way Ranging;

• Scenario 3: On Board Centralised processing with One Way Ranging or Two WayRanging using the inter-satellite ranging too;

• Scenario 4: On Ground Centralised processing based on One Way Ranging.

Moreover the space segment configuration foresaw two different layouts:

1. MEO plus GEO constellation;

2. MEO-only constellation.

Scenario 1The proposed Scenario 1 is based on the processing of Orbit Determination (OD) and TimeSynchronization (TS) performed On Board of each in a Real Time way. In this configurationthe measurements are performed by Two Way Ranging technique.

Scenario 2Scenario 2 is based on the On Ground Processing using the two-way ranging technique. InMEO + GEO configuration the Ground Segment time synchronization is performed throughthe GEO satellites that transpose the signal transmitted by the Station A toward the Station Bthat, at the same time, transmits its own signal to the Station A.

Scenario 3The proposed Scenario 3 includes the inter-satellite ranging between GEO and MEO for theOD. The Time Synchronization has performed as the Scenario1.

Scenario 4The Scenario 4 has been considered the reference baseline for the whole study being the GPS-like strategy. In this configuration the ranging measurements is performed through the OneWay ranging. During the first review phase (MTR) ESA considered not viable (for severalreasons i.e. complexity, economical impacts, integrity aspects, etc) the On Ground approach.Therefore the trade-off were performed only for the Scenarios 2 and 4

GALA REF :DATE :

Gala-als-dd-01412-04-2001


SYSTEM CONFIGURATION

For the constellation to be analyzed two options have been considered:

• MEO plus GEO option consists of 24 MEO and 3 GEO satellites.

• MEO only option consists of 30 MEO satellites.

The two constellation characteristics are presented below.

MEO satellites

For the first option we have:

♦ 24 MEO satellites form a Walker constellation with three planes, which is defined withthese parameters:§ Altitude: 24126 km§ Inclination: 52.5 deg§ First RAAN: 0 deg

For the second one:

♦ 30 MEO satellites form a Walker constellation with three planes, which is defined withthese parameters:§ Altitude: 23222 km§ Inclination: 54 deg§ First RAAN: 0 deg

Moreover the physical characteristics of the satellites are:§ Initial mass: 500 kg§ Frontal area: 14 m2

GEO satellites

The three GEO satellites present in the first option are equally spaced over the Equator.§ Altitude: 35678 km§ First position: 0 deg§ Initial mass: 1000 kg§ Frontal area: 16 m2

Measurement Technique

Two different tracking data types were used in this analysis:

§ One way ranging

§ Two way ranging

GALA REF :DATE :

Gala-als-dd-01412-04-2001


INITIAL TRADE-OFFS FOR THE COMPARATIVE SYSTEM STUDY(CSS)

For the above two scenarios several trade-off have been provided during the CSS phase:ü Trend analysis on the different parameters

• Signal noise applied to measurements• Number of Ground stations• Tracking data rate (OSPF Ground Station measurements frequency)• Random number generator seed (specific for the type of simulations performed)• Robustness of the satellite Orbit Determination process with respect to a Satellite

Firing:- Time to recover after a manoeuvre for the MEO satellites- Time to recover after a manoeuvre for the GEO satellites

ü Atomic clocks comparisons (clocks stability)ü Uploading functions

• Trend analysis for Age of Data performance versus different European atomicoscillators

• The verification of how many uploading facilities need to give an accurate andfrequent uploading service.

ü Errors introduced by the ephemeris messageü Synchronization functions

• Implementation of timing subsystems at the Galileo Ground Segment facilities• Clocks baseline definition for the Galileo system

Trend analysis on the different parameters

For all these analysis plots have been produced showing the contribution of ephemeris andclock errors to the UERE (SIS URE). Plots are representing the so-called zero Age of Datavalues, that represents the internal Kalman filter performance. And they have been producedfor the two types of orbits to be analysed (GEO and MEO) and have been provided withrespect to the elevation angle.

Similar results have been found for the two proposed measurement technique. The majorconclusions are:

Ø The two-way ranging scenario is very sensitive to large biases in the measurements, inparticular for the GEO satellites.

Ø The one way ranging strategy is quite adequate to compute accurate GEO orbits, it isprobably the only possible option to compute accurate GEO orbits.

Ø For the expected signal noise values the contribution of OD&TS to the UERE is typicallybetween 10 and 20 cm at 90 degrees elevation angle, and between 20 and 50 cm for zerodegrees elevation angle.

Ø In the MEO only Scenario at least seven ground stations are required (this is of course notconsidering redundancy) for tracking measurements: no significant improvement isobserved by increasing the number of stations

Ø In the MEO plus GEO scenario better results (for the GEO orbit determination) can bereached considering more stations: twelve stations provide very good results.

GALA REF :DATE :

Gala-als-dd-01412-04-2001


Ø Results can be significantly improved by increasing the data rate to one measurement perminute but in this case maybe could be impossible to provide a pre-processing activity(smoothing).

Ø The time to recover after a maneuver is typically around 3 hours for the MEO satellitesand around 8-12 hours for the GEO satellites.

Ø For the two-way ranging scenario the presence of non-modeled tropospheric effects mayaffect significantly to the GEO orbit determination.

After all these trend analysis no advantages are observed for the two-way ranging scenario. Itis believed that this scenario is adding a lot of complexity to the system without bringing anyadded value. So it has been recommended to discard the two-way ranging option.

Atomic clocks comparisons

As the CSS have shown, clocks are one of the components that have a great influence on thesystem performance.

The Hydrogen-maser could improve significantly the GALILEO system performance,relaxing the design of some subsystems and the ground segment operation. Actually the realproblem is its availability and space qualification, not forgetting also the cost which surelywill be higher then for the Rb oscillator.

The Rubidium atomic frequency standard anyway provides optimal results. If the stabilityspecifications of the European RAFS (σ(τ) = 5·10-14 at τ = 10000 s) is confirmed in the nextfuture the GALILEO system will have a very good clock equipment through which todevelop the final system architecture.

Uploading functions

Once the OSPF (the master control station of Galileo system) has evaluated the satellitesephemeris and clocks (included the Ground Segment clocks) states, prediction has to beprovided.

The propagation errors are function of unmodeled and random noise effects and increase asfunction of the propagation time span. To minimize this effect more frequent uploads areneeded to be able to broadcast fresh data. Frequent uploads are especially required to providemore fresh clocks data to satellites.

Two analysis have been provided:

Ø The Age of Data (AoD) analyzes versus different clocks characteristics,

Ø The verification of how many uploading facilities need to give an accurate and frequentuploading service.

Trend analysis for Age of Data performance versus different European atomicoscillators

To acquire a better feeling with respect to the effect of AoD on the OD&TS processperformance, in the last phase of the CSS study ALS has conducted several simulationsproviding the SIS-URE versus the Age of Data. For this investigation, which consider the

GALA REF :DATE :

Gala-als-dd-01412-04-2001


different influence of H-maser and RAFS clocks stability, it has been implemented anaccurate algorithm for the Allan Variance clock model which in the SW tool which generatesthe measures. A simplified model has been implemented for the drift component; for this onewe have assumed a null derivative and none noise.

With these assumptions several simulations have been provided for the two atomic Europeanoscillators. These analyses demonstrate that is possible to have a contribution to UERE below1m up to 3 hours (RAFS case). It must to be stressed that the results are influenced by the useof a simple model for the drift component (null derivative and no noise). This leads to slowerincreasing of the accuracy vs. AoD curve; this behavior affects the Rb more then the H-Masersince the H-maser drift is an order of magnitude less then the Rb clock.

Choosing an uploading frequency for clocks corrections of about 0.5 hours the URE value isabout 0.65m. Obviously a better behavior versus the uploading frequency can be reached byusing the H-maser clock.

These results are in line with the correspondent projections developed by the USA for GPSIIF block (GOSPAR project). Anyway further investigations could be necessary. They couldbe devoted to analyze for GALILEO system the correlation degree between the radialcomponent of the estimation error versus the clock error. In fact the correlation factor,included in the adopted URE formulation, influences the performance sensitively. Moreover amore accurate drift model will have to be provided.

Uploading Ground Station Coverage

The investigation has been performed for the Ground Stations considered under the Europeancommunity control.

The medium inclination selected for the constellation suggests to select the Ground Stationlocation equally spaced, when possible, over the equatorial region. Moreover the need to havean high reliability for the whole service over the Europe, constrains to consider also somestations located in these territories. A high uploading frequency has been selected.

The CSS analyzes lead to conclude that the uploading function related to the OD&TS needalmost 5 facilities on the ground. Anyway it has been proposed the stations set of Helsinki,Kourou, Reunion, Fucino, Reykjavik and Wallis and Futuna to have a better degree ofreliability. The architectural assumptions are:

Ø Each station have at least 4 antennas,

Ø Any antenna is able to track at least 3 satellites in a period of 0.45h,

Uploading functions Summary

After these two investigations it has been considered that a high uploading frequency (0.45 h)for the corrections of clocks errors is technically practicable and can fulfil the more stringentrequirements (0.65 m) although the repercussions on the Ground Segment architecture and onits workability have not to be underestimated.

The choice of a high frequency uploading may require further analysis especially with respectits possible repercussions. In fact the adoption of a frequent uploading could induce spike inthe orbit propagation of final user. With the hypothesis of a state vector solution every 10

GALA REF :DATE :

Gala-als-dd-01412-04-2001


14, 107.0) 1( −⋅≈= daySTSy τσ

to15 min and an update rate very close to this time we report to the final user directly the stateafter his evaluation that could be different enough with respect the previous one producinghigh variation in the navigation solution.

Moreover more frequents uploads translate into additional operator workload and probablynew automatic or quasi-automatic uploading process have to be implemented. This solution(optimized uploading process) seems necessary to reduce the uneven distribution of AoD andSIS URE across the constellation that can occur in uploading the vehicles one at a time. Thisuneven distribution will result in degradation of user positioning accuracy.

Errors introduced by the ephemeris message

The CSS study has demonstrated that for periods of validity below three hours the errorsintroduced can be considered as marginal.

Synchronization functions

For navigation, dating and dissemination purposes, the existence of a system reference timescale is compulsory in GALILEO: the clocks of each satellite and of ground segment facilitiesmust be synchronized to the common reference time scale. The system time could be anindependent time scale (i.e. the GALILEO time), with the unique request to be the commonreference time scale.

In the CSS study it has been proposed to synchronize the GALILEO system to UTC/TAI. Theproposed scenario is the following:

Ø steering the GALILEO time to the UTC’(k) or TA’(k) physical representation locatedclose to the OSPF

Ø through a one-way link (via GALILEO satellites) provide the synchronization with theUTC(k)/TA(k) generated by a selected national laboratory that is itself synchronized withthe BIPM UTC/TAI.

Nowadays the only national laboratory that could provide a 10 ns/month of accuracy versusUTC/TAI is the German National time-keeping Laboratory (PTB). The two-way option usingthe GEO satellite is considered optional for cost reasons.

For the reference time scale an investigation with respect to the synchronization error hasbeen provided. Considering only the one-way approach one baseline for the clocks to be usecan be:

Ø (3) RAFS on each spacecraft (only one powered-on, the other two acting as coldbackups),

Ø (2) Caesium and (1) RAFS at each OSS ( 7 OSS has been considered),

Ø (12) Caesium plus a counter at OSPF (using H-maser the Rb number decreases).

This baseline is really very close to the error value considered as assumption to fulfilthe 10 ns/month:

GALA REF :DATE :

Gala-als-dd-01412-04-2001


Anyway we want to remember that the definition of a baseline for the clocks isclosely linked to the algorithms involved in the OD&TS process and the UTC/TAIsynchronization approach chosen.

CSS TECHNICAL BASELINE

The performance analyses of OD&TS for different studies cases have shown that the OnGround centralized process based on the use of one-way satellite ranging (Scenario 4) andemploying a state of the art orbit determination package, where both extremely accuratedynamic and clocks models are implemented, can provide accurate orbit prediction for theGALILEO constellation.

The adoption of the one way technique, which presents comparable accuracy versus the twoway method and some advantages in GEO orbit determination, lead to simpler and lessexpensive architectural implementations.

Moreover the use on board of Rubidium atomic oscillator with high stability [ )(τσ y =5·10-14

or less at 10000 s] and the adoption of optimized technique for the clock correctionparameters uploading can provide a contribution to UERE that typically does not exceed the 1m (1-σ) up to 3 hours.

OPEN ISSUES

Further investigations could be will provided to consolidate the range of measurements noisein input to the Kalman Filter. Particularly a careful analyzes will have to be developed on thepre-processing activity (smoothing) to be performed on the pseudorange measures both atOSS and OSPF.

A ‘data valid’ criteria will have to be studied for the measures coming from OSS and ininput to the filter; in parallel a measurements data rate will have to define.

In the CSS study many algorithms have been used for modeling the real behavior of thesystem, taking advantage of the ALS, GMV, IEN different experiences. On the other handsome diversity have been observed in the results. Therefore it has been recommended that inthe following study phase it will be foresee a task dedicated to a critical revision of theimplemented models (i.e. improving the clock model), with the corresponding results and ofthe statistical parameters definition used for providing the OD&TS accuracy.

For the reduction of the Age of Data effect, it has been recommended that an accurateinvestigation will have to be performed on the real availability of the above European clocksand on the statistical parameters to be used to show the results.

Finally, more analysis, focused on the operational critical aspects when a high uploadingfrequency has been selected, could be necessary (i.e. the definition of different uploadingstrategy including the automatic uploading).

GALA REF :DATE :

Gala-als-dd-01412-04-2001


ANNEX B – MESSAGE STRUCTURES IN EXISTINGSATELLITE NAVIGATION SYSTEMS

BASIC DESCRIPTION OF THE GPS NAVIGATION MESSAGE ANDEPHEMERIS DATA SET

Basic structure

The navigation message is transmitted by the satellites on L1 at a rate of 50 bps. The messagestructure utilises a 1500 bit long frame, composed of five sub-frames, each sub-frame being300 bit long. Therefore, the frame has a duration of 30s and each sub-frame has a duration of6s.

To transmit the almanac for the full constellation, sub-frames 4 and 5 are cyclicallycommutated 25 times each, so that a complete data message requires the transmission of 25frames, lasting a total of 12m30s. The 25 versions of sub-frames 4 and 5 are referred to aspages 1 through 25 of each sub-frame. Each sub-frame consists of ten words, each word being30-bit long; the MSB of each word is transmitted first.

Each sub-frame and/or page of sub-frame starts with a Telemetry (TLM) word and Hand-Over Word (HOW). TLM is transmitted first, followed by HOW and by eight data words.Each word in each frame contains parity (six parity bits as LSBs). In addition, bit 23 and 24of words 2 and 10 are transmitted for parity computation purpose.

At the end/start of the GPS weeka) the cyclic paging of sub-frames 1 through 5 will restart with sub-frame 1, regardless to

which sub-frame was last transmitted prior to end/start of the week, andb) the cyclic of the 25 pages of sub-frames 4 and 5 will restart with page 1 of each of the

sub-frames, regardless to which page was last transmitted prior to end/start of the week.

All uploads and page cutovers occur on frame boundaries (i.e.: modulo-30 seconds from thestart of the week); accordingly, new data in sub-frames 4 and 5 may start to be transmittedwith any of the 25 pages of these sub-frames.

Under certain conditions, GPS satellites may transmit default navigation data in place of validdata in the navigation message; the default navigation data is defined as follows:

a) a pattern of alternating ones and zeros in words 3 to 10;b) the two trailing bits of word 10 will be zeros, to allow the parity of subsequent sub-frames

to be valid, andc) the parity of affected words will be invalid.

If the condition is a lack of a data element, only those sub-frames supported by that dataelement will transition to the default condition. Other conditions will cause all the sub-framesto transition to the default navigation data, and cause the sub-frame ID in the HOW to beequal one. Users are cautioned not to use a satellite transmitting default navigation data.

GALA REF :DATE :

Gala-als-dd-01412-04-2001


TLM word

The TLM word is 30-bit long, occurs every 6 seconds in the data frame, and is the first wordin each sub-frame or data page. It consists of a preamble of 8 bits, with the pattern“10001011”, followed by 16 reserved bits and 6 parity bits.

Hand-Over Word

The HOW is 30-bit long and is the second word in each sub-frame or data page, occurringimmediately after TLM. The HOW carries important timing information: the HOW beginswith the 17 MSBs of the Time Of Week (TOW) count26, corresponding to the TOW count atthe 1.5 s epoch which occurs at the start (leading edge) of the next following sub-frame.

Bit 18 is used in two-ways:

a) on satellites that are designated by configuration code “000”, bit 18 is the rollmomentum dump flag, with a “1” in this bit position indicating that a non-conservative(thruster-type) momentum dump has occurred since the last upload27; and

b) on satellites designated by configuration code “001”, bit 18 is an alert flag; when raised(bit 18 = “1”) it will indicate to the SPS user that the satellite URA may be worse thatindicated in sub-frame 1 and that the user may use that satellite at the user’s own risk.

Bit 19 has also a dual role:

a) on satellites that are designated by configuration code “000” in page 25 of sub-frame 4,bit 19 is used as a synchronisation flag; and

b) on satellites designated by configuration code “001”, bit 19 is an anti-spoof (A-S) flag.

When used as a synchronisation flag, a “0” in bit position 19 indicates that the satellite is insynchronism, which is the condition in which the leading edge of the TLM word is coincidentwith the 1.5 s epoch. If bit 19 is a “1” this condition may not exist and further data from thissatellite should not be used. When used as an A-S flag, a “1” in bit position 19 indicates thatthe A-S mode is “ON” in that satellite.

Bits 20, 21 and 22 of the HOW provide the ID of the subframe in which that particular HOWis the second word; the ID code is as follows:

Sub-frame ID code

1 0012 0103 0114 1005 101

26 The full TOW count is obtained by adding the 19 LSBs of the 29-bit Z-count.27 The flag is reset at a new end-of-message transmission at the conclusion of the next upload.

GALA REF :DATE :

Gala-als-dd-01412-04-2001


Sub-frame #1: satellite clock parameters and health data

The GPS ephemeris data set is transmitted in sub-frames #1 through #3 of the repeatingframe.

Sub-frame #1 contains satellite clock and health data (words #3 to #10):

1. Week_no.: the week number contains the ten MSBs of the 29-bit Z-count as specifiedherein; these 10 bits represent the number of the GPS weeks28 at the start of the data settransmission interval, with “all zeros” indicating “week 0”; the GPS week numberincrements at each end/start of week epoch [10-bit];

2. URA (User Range Accuracy): bits 13 through 16 of data word 3 give the predicted URAof the satellite; the URA reported in the navigation message shall correspond to themaximum value 29 anticipated over the validity period of the transmitted data, assuminguniform level of the SA [4-bit];

3. Satellite Health: bits 17 through 22 provide health information for the transmittingsatellite. The MSB summarizes the health status, where “0” indicating that all navigationdata is OK, while”1” indicates that some or all navigation data is bad [6-bit].The five additional bits are coded as follows:

MSB LSB Description (status)

0 0 0 0 0 All signals OK

** 1 1 1 0 0 Satellite is temporarily out ofservice (do not use the satelliteduring the current pass)

** 1 1 1 0 1 Satellite will be temporarily outof service (use with caution)

1 1 1 1 0 Spare

1 1 1 1 1 More than one combination would berequired to describe anomalies,except those marked by (**)

All other combinations Satellite experiencing codemodulation and/or signal powerlevel transmission problems

Additional health data is given in sub-frames #4 and #5 as a part of the almanac data set,even if data shown in sub-frame #1 can differ from data transmitted in sub-frames #4 and#5 since the latter may be updated at a different time;

4. Issue Of Data, Clock (IODC): bits 23 and 24 of word #3 in sub-frame #1 are the twoMSBs of the 10-bit Issue-Of-Data, Clock (IODC) term. Bits 1 through 8 of word #8 insub-frame 1 will contain the 8 LSBs of the IODC. The IODC indicates the issue numberof the data set and therefore provides the user with a convenient mean to detect any

28 Being limited to 10 bits, corresponding to slightly more than 19 years, this word has beenresponsible of the GPS Week Roll-Over (WRO) event, that has occurred for the first time atmidnight (00:00 UTC) on August 22, 1999, when the week count dropped from 1023 to 0.29 Does not include the single-frequency ionospheric delay model.

GALA REF :DATE :

Gala-als-dd-01412-04-2001


change in the correction parameters. The transmitted IODC will be different from anyvalue transmitted by the satellite during the preceding 7 days (the relationship betweenIODC and IODE, Issue Of Data-Ephemeris, will be discussed when describing the IODE)[2-bit+8bit];

5. Estimated Group Delay Differential: bits 17 through 24 of word #7 contain thecorrection term TGD to account for the satellite group delay differential [8-bit]. The SPSuser who utilizes the L1 frequency, will modify the code phase offset as:

( )∆ ∆t t TSV L SV GD1= −

6. Satellite Clock Correction Parameters : bits 9 through 24 of word #8, bits 1 through 24of word #9 and bits 1 through 22 of word #10 contain the parameters required by the userfor apparent satellite clock correction. These are:

a) tOC is the time of issue (in seconds) of the clock corrections parameters [16-bit];

b) af2 is the frequency drift (in seconds per second²) for the onboard clock as determinedat tOC [8-bit];

c) af1 is the frequency offset (or phase/time drift, in seconds per second) of the onboardclock as determined at tOC [16-bit];

d) af0 is the time offset [in seconds] of the onboard clock as determined at tOC [22-bit];

so that the satellite PRN code phase offset is given as:

( ) ( ) ( )∆ ∆t a a t t a t t t TSV L1 f0 f1 OC f2 OC2

r GD= + ⋅ − + ⋅ − + −

where ∆tr is a relativistic correction term given as:

∆t F e A sinEr k= ⋅ ⋅ ⋅

The orbit parameters e (eccentricity), A (semi-major axis) are provided in the ephemerisdata section of the navigation message, and Ek is the eccentric anomaly, computed by theuser as a part of the orbit propagation algorithm. F is a constant given as:

[ ]Fc

s / m2=− ⋅

= − ⋅ −24 442807633 10 10µ.

7. Sub-frame #1 Reserved Data Fields : these are provided in the following table:

Word Bits

3 2 (bit 11 through 12)





GALA REF :DATE :

Gala-als-dd-01412-04-2001


Sub-frame #2 and #3: satellite ephemeris data

Sub-frames #2 and #3 contain the ephemeris parameters of the transmitting satellite. Sub-frame #2 contains:

1. Issue Of Data, Ephemeris (IODE): is an 8-bit number equal to the 8 LSBs of the 10-bitIODC of the same data set [8-bit].Again, the IODE provides the user with a convenient mean to detect any changein the correction parameters. The IODE is provided in both the sub-frames #2 and#3 for purpose of comparison with the 8 LSBs of the IODC issued in sub-frame#1. Whenever these three terms do not match, a new data set must be collected.The transmitted IODE will be different from any value transmitted by the satelliteduring the preceding 6 hours.Any change in the sub-frame #2 and #3 data will produce a change in both the IODEwords. Cutovers to new data sets will occur only on hour boundaries, except for the firstdata set of a new upload. The first data set30 may be cut-in at any time during the hour,and therefore may be transmitted by the satellite for less than one hour. Additionally, thetoe value, for at least the first data set transmitted by a satellite after an upload, will bedifferent from that transmitted prior to cutover.

2. Crs: amplitude of the sine harmonic correction term to the orbit radius, in m [16-bit];3. ∆n: mean motion difference from computed value, in semi-circles/s [16-bit];4. M0: mean anomaly at reference time, in semi-circles [32-bit];5. Cuc: amplitude of the cosine harmonic correction term to the argument of latitude, in

radians [16-bit];6. e: eccentricity [32-bit];7. Cus: amplitude of the sine harmonic correction term to the argument of latitude, in

radians [16-bit];

8. A : square-root of the semi-major axis, in m1/2 [32-bit];

Sub-frame #3 contains:

9. toe: reference time for the ephemeris data set, in seconds [16-bit]10. Cic: amplitude of the cosine harmonic correction term to the inclination, in radians [16-

bit];11. Ω0: longitude of the ascending node of the orbit plane at weekly epoch, in semi-circles

[32-bit];12. Cis: amplitude of the sine harmonic correction term to the inclination, in radians [16-bit];13. i0: orbit plane inclination at reference time, in semi-circles [32-bit];14. Crc: amplitude of the cosine harmonic correction term to the orbit radius, in radians [16-

bit];15. ω: argument of perigee, in semi-circles [32-bit];

16. Ω& : first derivative of the right ascension of the ascending node, in semi-circles/s [24-bit];

17. i&: first derivative of the inclination, in semi-circles/s [14-bit];18. Spare and Reserved Data Fields, sub-frame 2: these are provided in the following table: 30 This corresponds to a physical data upload to the satellite.

GALA REF :DATE :

Gala-als-dd-01412-04-2001


Word Bits

10 Bit 17 (reserved)

10 Bit 18 through 22 (spare)

Sub-frame #4 and #5: support (almanac) data

Both sub-frames 4 and 5 are sub-commutated 25 times each; the 25 versions of these sub-frames are referred to as pages 1 through 25 of each sub-frame. With the possible exceptionof “spare” pages and explicit repeats, each page contains different data in words 3 through 10.The pages of sub-frame 4 use six different formats, while those of sub-frame 5 use two. Thecontent of the 25 pages is as follows:

a) Sub-frame 4:• Pages 2, 3, 4, 5, 7, 8, 9 and 10: almanac data for satellite 25 through 32 respectively;

these pages may be designated for other functions; the format and content of eachpage is defined by the satellite ID of that page. In this case, the six-bit health word ofpage 25 is set to “6 ones” and the satellite ID of the page will not have a value in therange of 25 through 32;

• Pages 17: special messages;• Pages 18: ionospheric and UTC data;• Page 25: satellite configurations for 32 satellites;• Pages 1, 6, 11, 12, 16, 19, 20, 21, 22, 23 and 24: (reserved);• Pages 13, 14 and 15: spares;

b) Sub-frame 5:• Pages 1 through 24: almanac data for satellites 1 through 24;• Page 25: satellite health data for satellites 1 through 24, the almanac reference time

and the almanac reference week number.

The following is a detailed description of the data contents for the almanac data.

1. Data and satellite IDs

The two MSBs of word 3 in each page contain the data ID which defines theapplicable GPS navigation data structure. Data ID one (denoted by binary code00) was utilized during Phase I of the GPS program, and is no longer in use; dataID two (denoted by binary code 01) is described in the Signal Specification.Future data IDs will be defined as necessary.The data ID is used to provide one of two indications:

a) for those pages which are assigned to contain the almanac data of one specificsatellite, the data ID defines the data structure utilized by that satellite whosealmanac data are contained in that page; and

b) for all other pages, the data ID denotes the data structure of the transmitting satellite.

The data IDs and satellite IDs in sub-frames #4 and #5 are identified in thefollowing table:

Sub-frame 4 Sub-frame 5

GALA REF :DATE :

Gala-als-dd-01412-04-2001


Page Data ID Satellite ID Data ID Satellite ID

1 Note (2) 57 Note (1) 1

2 Note (3) Note (1) 25 Note (1) 2

3 Note (3) Note (1) 26 Note (1) 3

4 Note (3) Note (1) 27 Note (1) 4

5 Note (3) Note (1) 28 Note (1) 5

6 Note (2) 57 Note (1) 6

7 Note (3) Note (1) 29 Note (1) 7

8 Note (3) Note (1) 30 Note (1) 8

9 Note (3) Note (1) 31 Note (1) 9

10 Note (3) Note (1) 32 Note (1) 10

11 Note (2) 57 Note (1) 11

12 Note (2) 62 Note (1) 12

13 Note (2) 52 Note (1) 13

14 Note (2) 53 Note (1) 14

Sub-frame 4 Sub-frame 5

Page Data ID Satellite ID Data ID Satellite ID

15 Note (2) 54 Note (1) 15

16 Note (2) 57 Note (1) 16

17 Note (2) 55 Note (1) 17

18 Note (2) 56 Note (1) 18

19 Note (2) 58 Note (4) Note (1) 19

20 Note (2) 59 Note (4) Note (1) 20

21 Note (2) 57 Note (1) 21

22 Note (2) 60 Note (4) Note (1) 22

23 Note (2) 61 Note (4) Note (1) 23

24 Note (2) 62 Note (1) 24

25 Note (2) 63 Note (2) 51

NOTES:

*: Use “0” to indicate a “dummy” satellite. When using “0” to indicate a dummy satellite, use the data IDof the transmitting satellite.

Note 1: Data ID of that satellite whose satellite ID appears in that page;Note 2: Data ID of the transmitting satelliteNote 3: Pages 2, 3, 4, 5, 7, 8, 9 and 10 of sub-frame 4 may contain almanac data for satellites 25 though 32

respectively, or data for other functions as identified by a different satellite ID from the value shown.Note 4: Satellite ID may vary

The satellite ID is given by bits 3 through 8 of word 3 in each page. Specific IDsare reserved for each page of sub-frames #4 and #5; however, the satellite ID ofpages 2, 3, 4, 5, 7, 8, 9 and 10 of sub-frame #4 may change for each page toreflect the contents for that page. The satellite IDs are utilized in two differentways:

GALA REF :DATE :

Gala-als-dd-01412-04-2001


a) for those pages which contain the almanac data of a given satellite, thesatellite Id is the same number that is assigned to the PRN code phase ofthat satellite; and

b) for all other pages the satellite Id assigned in accordance with the tableabove serves as the “page ID”.

IDs 1 through 32 are assigned to those pages which contain the almanac data ofspecific satellites (pages 1-24 of sub-frame 5 and pages 2-5 plus 7-10 of sub-frame 4). The “0” ID (binary all zeros) is assigned to indicate a dummy satellite,while IDs 51 through 63 are utilized for pages containing other than almanac dataof a specific satellite. The remaining IDs (33 through 50) are unassigned.

Pages, which contain identical data (for more frequent repetition), carry the samesatellite ID (e.g., in sub-frame #4. pages 1, 6, 11 and 21 carry an ID of 57, whilepages 12 and 24 are designated by an ID of 62).

2. Pages 1 through 24 of sub-frame #5, as well as pages 2 through 5 and 7 through10 of sub-frame #4, contain the almanac data and a satellite health word for upto 32 satellites. The almanac data are a reduced-precision subset of the clock andephemeris parameters. The data occupy all bits of words 3 through 10 of eachpage, except the eight MSBs of word 3 (data ID and satellite ID), bits 17 through24 of word 5 (satellite health) and the 50 bits devoted to parity.

The data in the almanac31 are as follows:a) e: eccentricity [16-bit];b) t0a: reference time32 for the almanac data set, in seconds [8-bit].c) δi: offset from nominal33 inclination, in semi-circles [16-bit];

d) Ω& : first derivative of the right ascension of the ascending node, in semi-circles/s[16-bit];

e) A : square-root of the semi-major axis, in m1/2 [16-bit];f) Ω0: longitude of the ascending node of the orbit plane at weekly epoch, in semi-

circles [24-bit];g) ω: argument of perigee, in semi-circles [24-bit];h) M0: mean anomaly at reference time, in semi-circles [24-bit];

i) af0 is the time offset [in seconds] of the onboard clock as determined at t0a

[11-bit];

31 The almanac message for a dummy satellite will contain alternating ones and zeros withvalid parity.32 This is nominally a multiple of 212 seconds truncated from 3.5 days after the first validtransmission time for this almanac data set. The almanac is updated often enough to insurethat GPS time, t, will differ from t0a by less than 3.5 days during the transmission period. Thealmanac parameters are updated at least once every 6 days during normal operations.33 Relative to i0 = 0.30 semicircles.

GALA REF :DATE :

Gala-als-dd-01412-04-2001


j) af1 is the frequency offset (or phase/time drift, in seconds per second) of theonboard clock as determined at t0a [11-bit];

where the last two terms are the time parameters describing the behavior of eachsatellite clock in the constellation.

3. Almanac Reference Week: bits 17 through 24 of word #3 in page 25 of sub-frame #5 will indicate the number of the week (WNa) to which the almanacreference time t0a is referenced. The WNa term consists of the 8 LSBs of the fullweek number. Bits 9 through 16 of word 3 in page 25 of sub-frame 25 will containthe value of t0a which is referenced to this WNa.

4. Health summary : Sub-frames #4 and #5 contain two-types of satellite healthdata:a) each of the 32 pages which contain the clock/ephemeris related almanac data

provide an eight-bit satellite health status word regarding the satellite whosealmanac data they carry, and

b) the 25th page of sub-frame 4 and of sub-frame 5 jointly contain six-bit healthstatus data for up to 32 satellites.

The 8-bit health status words occupy bits 17 through 24 of word 5 in those 32pages that contain almanac data for individual satellites. The 6-bit health statuswords occupy the 24 MSBs of words 4 through 9 in page 25 of sub-frame #5 plusbits 19 through 24 of word 8, the 24 MSBs of word 9 and the 18 MSBs of word 10in page 25 of sub-frame #4.The 3 MSBs of the 8-bit health words indicate health of the navigation data inaccordance with the code given in the table below:Bits position in page Indication

137 138 139

0 0 0 All data OK

0 0 1 Parity failure (some or all parity is bad)

0 1 0 TLM/HOW format problem (any departure from standardformat, e.g., preamble misplaced and/or incorrect,etc., except for incorrect Z-count, as reported inHOW)

0 1 1 Z-count in HOW is bad (any problem in the Z-countnot reflecting the actual code phase)

1 0 0 Sub-frames 1, 2, 3 (one or more elements in word 3through 10 of one or more sub-frames are bad)

1 0 1 Sub-frames 4, 5 (one or more elements in word 3through 10 of one or more sub-frames are bad)

1 1 0 All uploaded data is bad (one or more elements inword 3 through 10 of any one or more sub-frames arebad)

1 1 1 All data is bad (TLM word and/or HOW abd one or moreelements in any one or more sub-frames are bad

The 6-bit words provide a 1-bit summary of the navigation data’s health status inthe MSB position in accordance to what has been described in sub-frame 1. Thefive LSBs of both the 8-bit and the 6-bit health words provide the health status of

GALA REF :DATE :

Gala-als-dd-01412-04-2001


the satellite’s signal components in accordance with the code given in the tablebelow:

MSB LSB Description (status)

0 0 0 0 0 All signals OK

** 1 1 1 0 0 Satellite is temporarily out of service(do not use the satellite during thecurrent pass)

** 1 1 1 0 1 Satellite will be temporarily out ofservice (use with caution)

1 1 1 1 0 Spare

1 1 1 1 1 More than one combination would berequired to describe anomalies, exceptthose marked by (**)

All other combinations Satellite experiencing code modulationand/or signal power level transmissionproblems

A special meaning34 is assigned, however, to the “6 ones” combination of the 6-bithealth words in the 25th pages of sub-frames 4 and 5. It indicates that “the satellitewhich has that ID is not available, and there may be no data regarding thatsatellite in that page of sub-frames 4 and 5 that is assigned to normally containthe almanac data of that satellite”.

The predicted health data will be updated at the time of upload. The transmittedhealth data may not correspond to the actual health of the transmitting satellite orother satellites in the constellation. The data given in sub-frames 1, 4 and 5 of theother satellites may differ from that shown in sub-frames 4 and/or 5 since thelatter may be updated at a different time.

5. Page 25 of sub-frame 4 contains a 4-bit long term for each of up to 32 satellites toindicate the configuration code for each satellite, suing the following code:

Code Satellite configuration

000 "Block I" satellite 001 “Block II” satellite … ………

These 4-bit terms occupy bits 9 through 24 of word 3, the 24 MSBs of words 4through 7, and the 16 MSBs of word 8, all in page 25 of sub-frame #4.

6. Universal Coordinated Time (UTC) parameters : page 18 of sub-frame #4 includes:

c) the parameters needed to relate GPS time to UTC, and 34 (a) this special meaning applies to the 25th pages of sub-frames 4 and 5 only; and

(b) there may be data regarding another satellite in the almanac page referred to above.

GALA REF :DATE :

Gala-als-dd-01412-04-2001


d) notice to the user regarding the scheduled future or recent past (relative to thenavigation message upload) value of the integer number of seconds time offset due tothe leap seconds (∆tLSF) together with the week number (WNLSF) and the day number(DN) at the end of which the leap second becomes effective.

“Day one” is the first day relative to the end/start of week, and the WNLSF value willconsist of the 8 LSBs of the full week number. The user must account for the truncatednature of this parameter as well as for the truncation of WN, WNt and WNLSF due to theroll-over of the full week number. The absolute value of the difference between theuntruncated WN and WNLSF values will not exceed 127.

The 24 MSBs of words 6 through 9 plus the eight MSBs of word 10 in page 18 ofsub-frame 4 contain the parameters related to correlating UTC time with GPStime. The data is as follows:i) A0: constant term (in seconds) of polynomial describing the offset ∆tUTC between GPS

and UTC time scales at the time tE, that is the GPS time as estimated by the user onthe basis of correcting tSV for the satellite clock offset and relativity terms (see sub-frame 1 above) as well as for ionospheric and SA (dither) effects) [32-bit];

j) A1: rate of change (in seconds per second) of the offset offset ∆tUTC between GPS andUTC time scales [24-bit];

k) ∆tLS: is the offset due to the integer number of seconds between GPS time and UTC[8-bit];

l) t0t: time of validity of the UTC offset parameters [8-bit];m) WNt: UTC reference week number [8-bit];n) WNLSF: week number for the leap second adjustment [8-bit];o) DN: day number for the leap second adjustment [8-bit];p) ∆tLSF: is the offset due to the introduction of a leap second at WNLSF and DN [8-bit];

so that the difference between UTC and GPS time may be computed as:

( )( )∆ ∆t t A A t t WN WNUTC LS E t t= + + ⋅ − + ⋅ −0 1 0 604800 [s]

and UTC time can be calculated from tE (GPS time, estimated) as:

( ) t t tUTC E UTC= − ∆ modulo 86400 seconds

7. Ionospheric parameters : the ionospheric parameters allows the SPS user to utilize theionospheric model for the computation of the ionospheric delay. Ionospheric parametersoccupy bits 9 through 24 of word 3 plus the 24 MSBs of words 4 and 5:• αi, i = 0, 3: polynomial coefficients of the ionospheric model, 8-bit each [32-bit

total];• βi, i = 0, 3: polynomial coefficients of the ionospheric model, 8-bit each [32-bit

total];

8. Special message : page 17 of sub-frame 4 is reserved for special messages with thespecific content at the discretion of the system operator; it will accomodate the

GALA REF :DATE :

Gala-als-dd-01412-04-2001


transmission of 22 8-bit ASCII characters35. The requisite 176 bits occupy bits 9 through24 of word 3, the 24 MSBs of words 4 through 9, plus the 16 MSBs of word 10. The 8MSBs of word 3 contain the data ID and the satellite ID, while bits 17 through 22 of word10 are spares containing alternating ones and zeros. The remaining 50 bits of words 3through 10 are used for parity (six bits/word) and parity computation (two bits on word10);

9. Spare data fields :

Sub-frame Pages Words Spare Bit Position inWord

4 12, 19, 20, 22, 23, 24 9 9-24

4 1, 6, 11, 12, 16, 19, 20, 21, 22, 23, 24 10 1-22

4 17 10 17-22

4 18 10 9-22

4 25 8 17-18

4 25 10 19-22

5 25 10 4-22

NOTE: In addition, all bits of words 3 through 10 in pages 13, 14 and 15 of sub-frame 4 (except the 58 bits used fordata ID, satellite (page) ID, parity and parity computation) are also designated as spares

BASIC DESCRIPTION OF THE GLONASS NAVIGATION MESSAGEAND EPHEMERIS DATA SET

Basic structure

The modulating sequence is added modulo-2 to the spread-spectrum code (511 kbps), andconsists of two components (in addition to the spread-spectrum sequence):

• data of the navigation message, transmitted at 50 bps;

• meander sequence36 at 100 bps.

The navigation message data is further augmented by a Hamming code and packed in astructure called a super-frame, which repeats continuously. The super-frame is composed ofseveral frames and each frame by a number of strings. The starting time of string, frames andsuper-frames of the navigation message from different Glonass satellites are bound to timingerrors less than 2 ms.

35 From a limited set, including only characters A-Z, 0-9, +, -, ., ‘, °, /, <blank>, :, “.36 This basically transforms the NRZ data [50 bps] into a bi-phase coded data stream.

GALA REF :DATE :

Gala-als-dd-01412-04-2001


Figure B-1. Super-frame structure

30s ? 5 = 2.5 m

inutes

30 s

Frame number String number1 0 Immediate data ?? ? ?2 0 for ?? ? ?3 0 transmitting satellite ?? ? ?

I . Non-immediate data. (almanac). for

15 0 five satellites ?? ? ?1 0 Immediate data ?? ? ?2 0 for ?? ? ?3 0 transmitting satellite ?? ? ?

II . Non-immediate data. (almanac). for


III . Non-immediate data. (almanac). for


IV . Non-immediate data. (almanac). for

15 0 five satellites ?? ? ?1 0 Immediate data ?? ? ?2 0 for ?? ? ?3 0 transmitting satellite ?? ? ?. Non-immediate data

V . (almanac)for

. four satellites14 0 Reserved bits ?? ? ?15 0 Reserved bits ?? ? ?

1.7 s 0.3 s

2 s

Hamming codebits

in relativebi-binary code

data bitsin relative

bi-binary code

bit numberwithinstring

85 84.............….......9 8...... ...1

GALA REF :DATE :

Gala-als-dd-01412-04-2001


Figure B-2. Frame structure: frames 1-4

τGPSbn2 N?

m 4 τc KX MB

32 22 811

ln

εAnn?

m 4 τA

n KX MB10 15 85 λA

n21 18∆i

An

ω?nm

4KX MB

7 816 τAλn

21 22∆TA

n ∆T′A

n ln∆?A

n5

εAnn?

m 4 τA

n KX MB10 15 85 λA

n21 18∆i

An

ω?nm

4KX MB

7 816 τA

λn

21 22∆TA

n ∆T ′An ln∆? A

n5

εAnn?

m 4 τA

n KX MB10 15 85 λA

n21 18∆i

An

ω?nm

4 KX MB7 816 τA

λn

21 22∆TA

n ∆T′A

n ln∆?A

n5

εAnn?

m 4 τA

n KX MB10 15 85 λA

n21 18∆i

An

ω?nm

4 KX MB7 816 τA

λn

21 22∆TA

n ∆T′A

n ln∆? An

5

εAnn?

m 4 τA

n KX MB10 15 85 λA

n21 18∆i

An

ω?nm

4 KX MB7 816 τA

λn

21 22∆TA

n ∆T′A

n ln∆? An

5

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

Mna2

Mna2

Mna2

Mna2

Mna2

(Cn 1)

τc

n

7tbBnm

4 yn′(tb) yn

′′(tb) yn(tb) KX MB24 5 27 8

p

m 4

P1 tk xn′(tb) xn

′ ′(tb) xn(tb) KX MB

12 24 5 27 8

m 4 γn(tb) zn

′(tb) zn

′′(tb) zn(tb) KX MB

11 24 5 27 8

m 4 τn(tb) En KX MB

22 5 8

ln

string ?

P4

(P3 1)

(P2 1)

2

NT11

F?4∆τn

5 2

?

2

53

112

5

n3114

1

N4

5

Figure B-3. Frame structure: frame 5

τGPSbn2 N?m 4 τc KX MB

32 22 811

ln

εAnn?m 4 τA

n KX MB10 15 85 λAn

21 18∆iAn

ω?nm 4 KX MB

7 816 τAλn

21 22∆TAn ∆T ′A

n ln∆? An

5

εAnn?m 4 τA


21 18∆iAn

ω?nm 4 KX MB7 816 τA

λn

21 22∆TAn ∆T ′A

n ln∆? An

5

εAnn?m 4 τA


21 18∆iAn


λn

21 22∆TAn ∆T ′A

n ln∆? An

5

εAnn ?m 4 τA


21 18∆ iAn


λn

21 22∆TAn ∆T′ A

n ln∆? An

5

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

M na

2

M na2

M na2

Mna2

(C n 1)

τc

n

7tbB nm 4 yn′(tb) yn

′′(tb) yn(tb) KX MB24 5 27 8

p

m 4P1 tk xn

′(tb) x n′ ′(tb) xn(tb) KX MB

12 24 5 27 8

m 4 γn(tb) zn′(tb) zn

′′(tb) zn(tb) KX MB11 24 5 27 8

m 4 τn(tb) En KX MB22 5 8

ln

string ?

P4

( P3 1)

( P2 1)

2

NT11

F?4

∆τn5 2

?

2

53

112

5

n3114

1N4

5

? 1m 4 ? 2 KX MB10 811

? ?2

m 4 KX MB8ln

GALA REF :DATE :

Gala-als-dd-01412-04-2001


The super-frame has a duration of 2.5 minutes and consists of 5 frames. Each frame has aduration of 30 s and consists of 15 string, each 2 s long. The first 1.7 s of each string containsthe data, terminating with 8-bit of Hamming code. The following 0.3 s of each string aredevoted to time synchronization, and contain a fixed pattern of 30 bit (10 ms each), providedby the polynomial g(x) = 1 + x3 + x5, in the form:

111110001101110101000010010100

The total content of the almanac (24 Glonass satellites) is transmitted within one super-frame,and therefore is available every 2.5m.

Almanac data set

The Glonass almanac transmitted within the superframe is partitioned all over frames in thefollowing way:

Frame number Satellite numbers, for which almanac is within the superframe transmitted within given frame_________

1 1 … 52 6 … 103 11 … 154 16 … 205 21 … 24

The Glonass almanac includes the timing terms (the Glonass time scale correction toUTC(SU), coarse correction of each satellite clock to the system time, described separatelybelow), orbit elements and health status of all Glonass satellites.

The latter are:

1. nA is the satellite numbering within the Glonass space segment (number of the slotoccupied by the satellite); transmitted in string number 6, 8, 10, 12, 14, bit number 88through 92 [5-bit];

2. HnA is the carrier frequency transmitted by the n-th satellite; transmitted in string number

7, 9, 11, 13, 15, bit number 25 through 29 [5-bit];

3. λnA is the longitude of the first ascending node of day NA for the n-th satellite orbit in the

PZ-90 coordinate system; transmitted in string number 6, 8, 10, 12, 14, bit number 57through 77 [21-bit];

4. ∆inΑ is the correction to the mean value of the nominal inclination (63°) for the n-th

satellite orbit; transmitted in string number 6, 8, 10, 12, 14, bit number 39 through 56[18-bit];

5. ∆TnA is the correction to the nominal mean value (43200 s) of the Draconic37 period of

the n-th satellite at the instant tλnA; transmitted in string number 7, 9, 11, 13, 15, bit

number 37 through 58 [22-bit];

6. AnT&∆ is the first derivative (rate of change) of the Draconic period of the n-th satellite;

transmitted in string number 7, 9, 11, 13, 15, bit number 30 through 36 [7-bit];

37 The Draconic period is the time interval required tfor the satellite to complete a revolutionreturning to the (ascending) node.

GALA REF :DATE :

Gala-als-dd-01412-04-2001


7. εnA is the eccentricity of the n-th satellite orbit at the instant tλn

A; transmitted in stringnumber 6, 8, 10, 12, 14, bit number 24 through 38 [15-bit];

8. ωnA is the argument of perigee of the n-th satellite orbit at the instant tλn

A; transmitted instring number 7, 9, 11, 13, 15, bit number 80 through 95 [16-bit];

9. CnA is the health flag for the n-th satellite; transmitted in string number 6, 8, 10, 12, 14,

bit number 95 [1-bit].

for a total of 110 bit per satellite (to which 60 bit of timing information are to be added).

Ephemeris data set

The Glonass ephemeris data set includes some timing terms (the satellite clock offset withrespect to the Glonass time scale, the time of the beginning of the frame, the time of validityof the ephemeris set and the frequency correction to the onboard clock, described separatelybelow) and the orbit elements and health status of the transmitting Glonass satellite.

The latter are:

1. m is the string number within the frame; transmitted in string number 1, … 15, bitnumber 96 through 99 [4-bit];

2. xn(tb), yn(tb), zn(tb) are the cartesian coordinates of the transmitting satellite at the time tb;transmitted in string number 1, 2, and 3 respectively, bit number 24 through 50 in eachstring [27-bit x 3];

3. (tz (ty (tx bAnb

Anb

An )),), &&& are the first derivatives with respect to time (rate of change) of

the cartesian coordinates; transmitted in string number 1, 2, and 3 respectively, bitnumber 56 through 79 in each string [24-bit x 3];

4. (tz (ty (tx bAnb

Anb

An )),), &&&&&& are the second derivatives with respect to time (acceleration) of

the cartesian coordinates; transmitted in string number 1, 2, and 3 respectively, bitnumber 51 through 55 in each string [5-bit x 3];

5. En is the age of ephemeris data, i.e.: the time interval (in days) elapsed since the time ofcalculation (uploading) until the epoch tb for the satellite; transmitted in string number 4,bit number 64 through 68 [5-bit];

6. Bn is a health status flag for the transmitting satellite, of which only the first bit is ofinterest to the user; transmitted in string number 2, bit number 93 through 95 [3-bit];

7. Π1 is a flag indicating the update rate. Flag values of 00, 01, 10 and 11 indicate updaterates of 0m, 30m, 45m and 60m respectively; transmitted in string number 1, bit number 92through 93 [2-bit];

8. Π2 is a flag of “oddness” (Π2 = 1) or “eveness” (Π2 = 0), indicating the eveness oroddness of the ordinal number (b) for a 30 (60) minutes interval. The middle of theinterval corresponds to the value of tb; transmitted in string number 2, bit number 92 [1-bit];

9. Π3 is a flag within the frame that indicates the number of satellites for which the almanacis transmitted within the given frame. Since the message is composed of 5 frames, andthere are 24 satellites in the constellation, the first 4 frames transmit the almanac data forfive satellites (Π3 = 1), while the last transmits the almanac data for the last four satellites(Π3 = 0); transmitted in string number 3, bit number 95 [1 bit].

GALA REF :DATE :

Gala-als-dd-01412-04-2001


Therefore, in each frame there are 184 bit of ephemeris and ancillary data information towhich 52 bit of timing information must be added, for a total of 236 bit.

Timing

The main difference between Glonass and GPS time scales is that Glonass time is corrected ofthe leap seconds that characterise UTC, therefore Glonass time follows directly UTC (butwith a 3 hours shift, due to the Russian time zone) without the need to transmit any timeoffset. However, the calculations of the ephemeris at the time of introduction of the UTC leapsecond involves the additional complexity of taking into account the resulting time step.

Seven parameters are used to transfer the time in the Glonass system; three of them are in thealmanac sub-frame (non-immediate information):

1. τ c is the Glonass time scale offset [in s] with respect to UTC(SU); transmitted in stringnumber 5, bit number 57 through 84 [28-bit];

2. τλAn is the time [in s] of the first ascending node of the n-th satellite orbit within the NA

day; transmitted in string number 7, 9, 11, 13, 15, bit number 59 through 79 [21-bit]

3. NA [in days] is the number of days elapsed in a 4-year period beginning from the lastleap year; transmitted in string number 5, bit number 85 through 95 [11-bit];

and four are in the specific satellite ephemeris sub-frame (immediate data):

4. τn(tb) is the coarse value of the n satellite time offset [in s] to Glonass time at the epochtb; transmitted in string number 4, bit number 74 through 95 [22-bit];

5. tk this is the time [in hours, minutes and seconds] referenced to the beginning of theframe within the current day and calculated according to the satellite time scale, ininteger number of hours and minutes plus thirty-seconds intervals; transmitted in stringnumber 1, bit number 80 through 91 [12-bit];

6. γn(tb) is the frequency offset (predicted, dimensionless) from the nominal value forsatellite n at the time tb; this takes into account gravitational and relativistic effects at theinstant time tb; transmitted in string number 3, bit number 84 through 94 [11-bit];

7. tb is the time of the current day [in minutes], as UTC + 3h 00m; resolution 15 minutes; isthe epoch of validity of the current ephemeris set, taken at the middle of the validityinterval; transmitted in string number 2, bit number 85 through 91 [7-bit].

BASIC DESCRIPTION OF THE EGNOS NAVIGATION MESSAGEAND EPHEMERIS DATA SET

Basic description of the EGNOS message

The European Geostationary Navigation Overlay System (EGNOS) uses satellites (initiallygeostationary satellites - GEOs) to broadcast Global Navigation Satellite System (GNSS)integrity and correction data to GNSS users, and to provide a ranging signal that augments theGNSS, which is made up of the Global Positioning System (GPS) and Global SatelliteNavigation System (GLONASS) systems.

EGNOS data are broadcast at a 250 bits per second rate; the format is shown in the followingfigure:

GALA REF :DATE :

Gala-als-dd-01412-04-2001


24-BITSPARITY212-BIT DATA FIELD

8-BIT PREAMBLE OF 24 BITS TOTAL IN 3 CONTIGUOUS BLOCKS6-BIT MESSAGE TYPE IDENTIFIER (0 - 63)

250 BITS - 1 SECOND

DIRECTION OF DATA FLOW FROM SATELLITE; MOST SIGNIFICANT BIT (MSB) TRANSMITTED FIRST

.

A block is defined as the complete 250 bits, while a message is defined as the 212 bit datafield. The start of the first 8-bit part of every other 24-bit distributed preamble will besynchronous with the 6-second GPS subframe epoch to within the overall EGNOSperformance requirements. The block transmission time will be one second. Message typesare presented in the following table:

Type Contents

0 Don't use this GEO for anything (for EGNOS testing)1 PRN Mask assignments, set up to 51 of 210 bits2-5 Fast corrections6 Integrity information7 Fast correction degradation factor9 GEO navigation message (X, Y, Z, time, etc.)10 Degradation Parameters11 Reserved for future messages12 EGNOS Network Time/UTC offset parameters13-16 Reserved for future messages17 GEO satellite almanacs18 Ionospheric grid point masks19-23 Reserved for future messages24 Mixed fast corrections/long term satellite error corrections25 Long term satellite error corrections26 Ionospheric delay corrections27 EGNOS Service Message28-61 Reserved for future messages62 Internal Test Message63 Null Message

Ephemeris data set

Part of the EGNOS message is devoted to the ephemerides of the GEO satellites, necessary asthey will be used for navigation purposes. The information concerning the orbital data isgrouped in the Type 9 Message, consisting of the position, velocity and acceleration of thegeostationary satellite, in ECEF Coordinates, and its apparent clock time and frequencyoffsets. Also included is the time of applicability t0, an Issue of Data (IOD) and an accuracyexponent (URA) representing the estimated accuracy of the message. aGf0 and aGf1 will be anestimate of the time offset and drift with respect to EGNOS Network Time. Their combinedeffect will be added to the estimate of the satellite's transmit time.

The position and time of the GEO will be propagated to time-of-day tk, corrected for end-of-day cross-over, as

GALA REF :DATE :

Gala-als-dd-01412-04-2001


( ) ( )200 2

1tt

ZYX

ttZYX

ZYX

ZYX

G

G

G

k

G

G

G

G

G

G

Gk

Gk

Gk

−

+−

+

=

&&&&&&

&&&

( ) ( ) ( )010 ttaatttttt kGfGfGkGGkG −++=∆+=

where t0 is the time after midnight of the current day. The ranges of the parameters in thismessage allow for GEO inclination angles of up to ±8°.

In contrast to the time correction for GPS satellites, there is no user correction for generalrelativity to GEO time. Any relativity effects will be removed by the earth station controllingthe GEO signal. The format of the Type 9 Message (GEO Navigation Message) is depicted inthe following figure:

24-BITSPARITY

8-BIT PREAMBLE OF 24 BITS TOTAL IN 3 CONTIGUOUS BLOCKS6-BIT MESSAGE TYPE IDENTIFIER (= 9)

250 BITS - 1 SECOND

ISSUE OF DATA, SEQUENCING BETWEEN 0 AND 255


*

*ACCURACY EXPONENT; SEE SECTION 2.5.3 OF [1]

X G YG ZG GX.

GY.

GZ.

aGf0aGf1

GX..

GZ..

GY..

t0

The parameters, along with their coding characteristics are listed in the table below:

Parameter No. ofBits*

Scale Factor(LSB)

Effective Range Units

Issue of Data 8 1 255 discrete

t0 13 16 86,384 seconds

Accuracy** 4 ** ** **

XG (ECEF) 30* 0.08 ?42,949,673 meters

YG (ECEF) 30* 0.08 ?42,949,673 meters

ZG (ECEF) 25* 0.4 ?6,710,886.4 meters

XG Rate-of-Change 17* 0.000625 ?40.96 meters/sec

YG Rate-of-Change 17* 0.000625 ?40.96 meters/sec

ZG Rate-of-Change 18* 0.004 ?524.288 meters/sec

XG Acceleration 10* 0.0000125 ± 0.0064 meters/sec2

YG Acceleration 10* 0.0000125 ± 0.0064 meters/sec2

ZG Acceleration 10* 0.0000625 ± 0.032 meters/sec2

aGf0 12* 2-31 ?0.9537??? ? ? seconds

aGf1 8* 2-40 ?1.1642??? ? ? ? seconds/sec

NOTES TO THE TABLE:

* Parameters so indicated will be two's complement, with the sign bit occupying the MSB.

GALA REF :DATE :

Gala-als-dd-01412-04-2001


** See Section 2.5.3 of [RD 27]

Wide-Area Augmentation data set

Augmentation data basically consist of:

- Differential corrections to GPS/GLONASS message data: Fast (pseudorange) and longterm (satellite position and velocity) corrections (message types 2-5, 24, 25) Fastcorrections consist of a term to be added directly to measured pseudorange; range-ratecorrections are computed by differencing previous fast corrections.

- Integrity information: Message types 6, 7. It consists of an Issue of Data of the fastcorrections, a UDRE indicator (UDREI) and a fast corrections degradation factor(message 7). UDRE is a bound of the positioning accuracy provided by the system.

- Ionosphere information: Message types 18, 26. It consists of a series of ionosphericdelays, corresponding to a predefined grid of locations. Users compute the correctioncorresponding to their location by interpolation of the surrounding grid points.

- Service Indications, UDRE regional increments: Message type 27.

Fast Corrections Message Types 2 - 5

The fast corrections messages format is illustrated in the figure below:

24-BITSPARITY

8-BIT PREAMBLE OF 24 BITS TOTAL IN 3 CONTIGUOUS BLOCKS6-BIT MESSAGE TYPE IDENTIFIER (= 2, 3, 4 & 5)

250 BITS - 1 SECOND

IODF (2 BITS)13 12-BIT FAST CORRECTIONS


IODP (2 BITS)

PRCf

UDREIREPEAT FOR 12 MORE SATELLITESREPEAT FOR 12MORE SATELLITES

13 4-BIT UDREIs

Message Type 2 contains the data sets for the first 13 satellites designated in the PRN mask.Message Type 3 contains the data sets for satellites 14 - 26 designated in the PRN mask, etc.,through Message Type 5, which contains the data sets for satellites 40 through 51 designatedin the PRN mask. The last data set of Message Type 5 is not used due to the constraint thatcorrections can only be provided for 51 satellites (see Message Type 6). A fast correctionsmessage type will only be sent if the number of satellites designated in the PRN maskrequires it: e.g., Message Type 5 will only be broadcast if 40 or more satellites are designated.Message Types 2-5 contain a 2-bit IODFj, indicating to which satellites the corrections apply.The IODFj, where j is the fast corrections Message Type (2 - 5), is used to associate the? 2

UDRE contained in a Message Type 6. If there are 6 or fewer satellites in a block, they maybe placed in a mixed corrections message, Type 24. The last half of Message Type 24 isreserved for slow corrections. The fast data set for each satellite consists of 16 bits; a 12-bitfast correction and a 4-bit UDRE Indicator (UDREI). Each message also contains a 2-bitIODP indicating the associated PRN mask. Due to a constraint of Message Type 6, thenumber of satellite corrections is limited to 51 satellites.

The 12-bit fast correction (PRCf) has a 0.125 meter resolution, for a [-256.000 m, +255.875m] valid range. If the range is exceeded, a don't use indication will be inserted into the

GALA REF :DATE :

Gala-als-dd-01412-04-2001


UDREI field. The user should ignore extra data sets not represented in the PRN mask. Thetime of applicability (tof) of the PRCf is the start of the epoch of the WNT second that iscoincident with the transmission at the GEO satellite of the first bit of the message block.

Range-rate corrections (RRC) of the fast corrections will not be broadcast. The user willcompute these rates-of-change by differencing fast corrections (regardless of IODFj). Thetotal fast correction for a given satellite will be applied as

( ) ( ) ( ) ( )ofoffmeasuredcorrected ttRRCtPRCtPRtPR −×++=

where RRC is computed by the user differencing successively received corrections. Anytime a“don’t use” or "not monitored" indication is received, and is then followed by a validcorrection, the calculation of the RRC must be reinitialized. The computation of RRC isrequired even in the case of an identical IODFj.

The high degree of resolution of these fast corrections should not be confused with correctionaccuracy. The actual accuracy provided will be indicated by the σ2

UDRE data.

Integrity Information Message Type 6

The integrity information message is shown in the figure below:

24-BITSPARITY


250 BITS - 1 SECOND


IODF2, IODF3, IODF4 & IODF5 (2 BITS EACH)

51 4-BIT UDREIs

Each message includes an IODFj for each fast corrections Message Type (2 - 5). The σ2UDRE

information for each block of satellites applies to the fast corrections with the correspondingIODFj. An IODFj=3 indicates that the σ2

UDRE 's apply to all active data corresponding messagetype (j = 2 - 5). The remaining 204 bits is divided into 51 slots of 4 bit UDREIs, one for eachsatellite in the mask. Message Type 6 allows the fast corrections of Message Type 2-5 and 24to be updated infrequently, commensurate with the dynamics of the satellite clock errors. Ifall fast corrections are being updated at a six second rate, Message Type 6 is not requiredsince the UDREIs are also included in Message Types 2-5 and 24. Message Type 6 can alsobe used to indicated an alarm condition on multiple satellites.

The four bit UDREIs are used for the evaluation of the σ2UDRE’s, indicating the accuracy of

combined fast and slow error corrections, not including the accuracy of the ionospheric delaycorrections (indicated in σ2

GIVE’s), which are computed from the indicators that are providedseparately in Message Type 26.

The ephemeris accuracy component is an “equivalent” range accuracy, rather than accuracyof each of the Earth-Centered-Earth-Fixed (ECEF) components. Evaluation of model variance(σ2

UDRE) versus indicator value is given in the following table. The σ2UDRE (in Type 2 - 6)

applies at a particular time and degrades as defined in Message Type 7.

GALA REF :DATE :

Gala-als-dd-01412-04-2001


UDREIi UDREi Meters σ2i.UDRE Meters2

0 0.75 0.0520

1 1.0 0.0924

2 1.25 0.1444

3 1.75 0.2830

4 2.25 0.4678

5 3.0 0.8315

6 3.75 1.2992

7 4.5 1.8709

8 5.25 2.5465

9 6.0 3.3260

10 7.5 5.1968

11 15.0 20.7870

12 50.0 130.9661

13 150.0 2078.695

14 Not Monitored Not Monitored

15 Do Not Use Do Not Use

Fast Correction Degradation Factor - Message Type 7The σ2

UDRE broadcast in Types 2 - 6 applies at a time prior to the time of applicability of theassociated corrections. The Type 7 message specifies the applicable IODP, system latencytime (tl) and the fast correction degradation factor indicator (aii) for computing thedegradation of fast and long term corrections

The Type 7 message contents are described below:

24-BITSPARITY


250 BITS - 1 SECOND


IODP (2 BITS)

51 4-BIT UDRE degradation factor indicators

t l (4 BITS)SPARE (2 BITS)

Parameter No. of

Bits

Scale Factor

(LSB)

Effective

Range

Units

System latency (tl) 4 1 0 - 15 seconds

IODP 2 1 0 - 3 ---

Spare 2 --- --- ---

For each of 51 satellites 204 --- --- ---

Degradation factor indicator (aii) 4 1 0 - 15 ---

The following table provides the evaluation of the fast corrections degradation factor giventhe degradation factor indicator, aij. It also shows the user time-out interval for fastcorrections. This time-out interval is measured from the end of the last valid corrections

GALA REF :DATE :

Gala-als-dd-01412-04-2001


message received to the end of next valid corrections message received for the satellite ofinterest.

Fast CorrectionsDegradation Factor

Indicator

Fast CorrectionsDegradation Factor -

mm/s2

User Time-Out Period forcorrections – seconds

Nonprecision Approach

User Time-Out Period forcorrections – seconds

Precision Approach Mode (Ifc)

0 0.0 180 120

1 0.15 171 114

2 0.35 153 102

3 0.4 135 90

4 0.5 135 90

5 0.75 117 78

6 1.0 99 66

7 1.5 81 54

8 2.0 63 42

9 3.0 45 30

10 5.0 45 30

11 7.0 27 18

12 9.0 27 18

13 11.0 27 18

14 15.0 18 12

15 19.0 18 12

Long Term Satellite Error Corrections Message Type 25

Message Type 25 will be broadcast to provide error estimates for slow varying satelliteephemeris and clock errors with respect to WGS-84 ECEF coordinates. These long termcorrections are not broadcast for the GEO satellites. Instead, the Type 9 GEO NavigationMessage will be updated as required to prevent slow varying GEO satellite errors. Thesecorrections are estimated with respect to the GNSS broadcast clock and ephemerisparameters.

First and second halves (106 bits) of the message are equal in format, defined as follows:

The first bit of the 106 bits is a velocity code, indicating whether or not this half-messageincludes clock drift and velocity component error estimates. If it is set to a 1, the messageincludes clock drift and velocity component estimates; otherwise it consists of only clockoffset and position component error estimates, but for 2 satellites, instead of 1. Thus, themessage can consist of error estimates for 1, 2, 3 or 4 satellites, depending upon the velocitycodes in both halves of the message (which may be different) and how many satellites arebeing corrected.

GALA REF :DATE :

Gala-als-dd-01412-04-2001


24-BITSPARITY


250 BITS - 1 SECOND

ISSUE OF DATA; SEE [1]


δ x δy δ z

PRN MASK NUMBER

VELOCITY CODE = 0

δx δy δz SECOND HALF OF MESSAGEδafo δafo

IODP SPARE

Type 25 long term satellite error corrections (velocity code = 0)

24-BITSPARITY


250 BITS - 1 SECOND

ISSUE OF DATA; SEE [1]


δx δy δz

PRN MASK NUMBER

VELOCITY CODE = 1δaf1

SECOND HALF OF MESSAGEt oδafo δx. δy

.δz.

IODP (2 BITS)

Type 25 long term satellite error corrections (velocity code = 1)

Half message parameters for both velocity codes are listed in the tables below:

Velocity code = 0

Parameter No. of

Bits1

Scale Factor

(LSB)

Effective

Range

Units

For 2 Satellites 106 --- --- ---

Velocity Code = 0 1 1 -- discrete

PRN Mask No.2 6 1 51 ---

Issue of Data3 8 1 255 discrete

δx (ECEF) 91 0.125 ±32 meters

δy (ECEF) 91 0.125 ±32 meters

δz (ECEF) 91 0.125 ±32 meters

δaf0 101 2-31 ±2-22 seconds

PRN Mask No. 6 1 51 ---

Issue of Data 8 1 255 discrete

δx (ECEF) 91 0.125 ±32 meters

δy (ECEF) 91 0.125 ±32 meters

δz (ECEF) 91 0.125 ±32 meters

δaf0 101 2-31 ±2-22 seconds

IODP 2 1 0 - 3 discrete

Spare 1 --- --- ---

GALA REF :DATE :

Gala-als-dd-01412-04-2001


Velocity code = 1

Parameter No. of

Bits1

Scale Factor

(LSB)

Effective

Range

Units

For 1 Satellite 106 --- --- ---

Velocity Code = 1 1 1 -- discrete

PRN Mask No. 6 1 0 - 51 ---

Issue of Data 8 1 0 - 255 discrete

δx (ECEF) 111 0.125 ±128 meters

δy (ECEF) 111 0.125 ±128 meters

δz (ECEF) 111 0.125 ±128 meters

δaf0 1112-31 ±2-21 seconds

δx rate-of-change (ECEF) 812-11 ±0.0625 meters/sec

δy rate-of-change (ECEF) 812-11 ±0.0625 meters/sec

δz rate-of-change (ECEF) 812-11 ±0.0625 meters/sec

δaf1 812-39 ±2-32 seconds/sec

Time-of-Day Applicability to 13 16 86,384 seconds

IODP 2 1 0 - 3 discrete

1) Parameters so indicated will be two's complement, with the sign bit occupying the MSB.

Note that the ranges of the clock offset and position component error estimates when thevelocity code is 0 are less than if the velocity code is 1. The reason for this is for data rateefficiency.

Usually, the necessity for clock drift and velocity component error estimates is small. Onlythe clock offset and position component error estimates will be broadcast, unless any of theerrors (position, velocity, offset or drift) are large enough to warrant their use on a satellite-by-satellite basis.

In case of the clock offset error correction (δaf0) and clock drift error correction (δaf1), theuser will compute the clock time error estimate δ∆tSV at time-of-day tk as

( ) ( ) 0010 fGattaattkffkSV

δδδδ +−+=∆

where t0 is the time of day applicability, correcting for rollover if needed. Likewise, the userwill compute the position error correction vector as

GALA REF :DATE :

Gala-als-dd-01412-04-2001


( )0

ttzyx

zyx

zyx

k

k

k

k

−

+

=

&&&

δδδ

δδδ

δδδ

If the velocity code is set to 0, the rate-of-change vector and the δaf1 term are simply set to 0.The corrections will be added to the computed satellite position vector and clock delta.

Upon transmission of new clock and ephemeris data, the EGNOS will continue to broadcastcorrections to the old long term clock and ephemeris data for a period of 2 minutes. Thisdelay enables all EGNOS users to acquire the new GNSS data.

Ionospheric Delay Corrections Messages Type 26

The Type 26 Ionospheric Delay Corrections Message provides the users with vertical delaysand their 99.9% accuracy (via the GIVEs) at geographically defined IGPs identified by anIGP number. The grid points are indicated in figure 4.

Each message contains a band number and a block ID, which indicates the location of theIGPs in the respective band mask. The 4-bit block ID (0-13) indicating to which IGPs thecorrections apply. Block 0 contains the IGP corrections for the first 15 IGPs designated in theband mask. Block 1 contains the IGP corrections for IGPs 16 - 30 designated in the bandmask, etc.

Each band is therefore divided into a maximum of 14 blocks. Corrections associated with slotnumbers that exceed the number of IGPs indicated in the IGP band mask should be ignored.

Figure B-4. Ionospheric grid points

N75

N65

N55

0

0W180N85

W100 E100W140 W60 W20 E20 E60 E140

N50

S75

S65

S55

S85

S500 1 2 3 4 5 6 7 8

GALA REF :DATE :

Gala-als-dd-01412-04-2001


The data content for this message is described below:

24-BITSPARITY


250 BITS - 1 SECOND


S

S = SPARE (7 BITS)

BLOCK ID (4 BITS)IGP VERTICAL DELAY (9 BITS)GIVEI (4 BITS)

REPEAT FOR 14 MORE GRID POINTS

2 3 4 5 6 7 8 9

IODI

10 11 12 13 14

BAND NUMBER (4 BITS)

15

Parameter No. of Bits Scale Factor (LSB) Effective Range Units

Band Number 4 1 0 − 8 discrete

Block ID 4 1 0 - 13 discrete

For Each of 15 Grid Points 13 --- --- ---

IGP Vertical Delay Estimate 9 0.125 0-63.875 meters

Grid Ionospheric VerticalError Indicator (GIVEI)

4 1 0-15 discrete

IODI 2 1 0 - 3 Discrete

Spare 7 --- --- ---

The evaluation of the GIVEs is as follows:

GIVEIi GIVEi (99.9%)- Meters

0 0.3

1 0.6

2 0.9

3 1.20

4 1.5

5 1.8

6 2.1

7 2.4

8 2.7

9 3.0

10 3.6

11 4.5

12 6.0

13 9.0

14 15.0

15 45.0

These vertical delays and the evaluated GIVEs will be translated by the user to the IPP of theobserved satellite. This computed vertical delay and the associated UIVE (User IonosphericVertical Error computed from associated GIVE's) must then be multiplied by the obliquity

GALA REF :DATE :

Gala-als-dd-01412-04-2001


factor computed from the elevation angle to the satellite to obtain a slant range correction andthe slant range correction error User Ionospheric Range Error (UIRE). The GIVEs arecomputed by the EGNOS to provide a 99.9% UIRE bound of the currently broadcast IGPcorrection errors and the previously broadcast IGP correction errors. This is because theuser’s pierce point correction may be based upon a mixture of currently broadcast IGPcorrections and previously broadcast IGP corrections if the user missed the broadcast of someof the currently broadcast IGP corrections.

The 9-bit IGP vertical delays have a 0.125 meter resolution, for a 0-63.625 meter valid range.A vertical delay of 63.750 meters (111111110) will indicate that the IGP was not monitored;and a vertical delay of 63.875 meters (111111111) will indicate don't use. That is, there are noIGP vertical delays greater than 63.625 meters. If that range is exceeded, a don't useindication will be used.

Almanac data set

Almanacs for all GEOs will be broadcast periodically to alert the user of their existence,location, the general service provided and health and status. Almanacs for three satellites willbe broadcast in the GEOs Almanacs Message Type 17 described below. These messages willbe repeated to include all GEOs. Unused almanacs will have a PRN number of 0 and shouldbe ignored.

24-BITSPARITY


250 BITS - 1 SECOND


TIME-OF-DAY (11 BITS)

XG YG ZG

DATA ID (2 BITS)PRN NUMBER (8 BITS)HEALTH AND STATUS (8 BITS)

67 BITS; REPEAT FOR 2 MORE SATELLITES

2 3DERIVATIVES

Parameter No. ofBits*

Scale Factor(LSB)

EffectiveRange

Units

For each of 3 satellites 67 -- −− --

Data ID 2 -- -- discrete

PRN Number 8 1 0 − 210 --

Health and Status 8 -- − discrete

XG (ECEF) 15* 2,600 ±42,595,800 meters

YG (ECEF) 15* 2,600 ±42,595,800 meters

ZG (ECEF) 9* 26,000 ±6,630,000 meters

XG Rate-of-Change 3* 10 ± 40 meters/sec

YG Rate-of-Change 3* 10 ± 40 meters/sec

ZG Rate-of-Change 4* 60 ± 480 meters/sec

to (Time-of-Day) 11 64 86,336 seconds

* Parameters so indicated will be two's complement, with the sign bit occupying the MSB.

The position of a GEO using the almanac parameters will be evaluated as when using theephemeris data set, with the acceleration components set to 0 and t0 set to the Time-of-Daygiven in the message.

GALA REF :DATE :

Gala-als-dd-01412-04-2001


The Data ID for the current Signal Specification format is 00. Other states of the data ID arereserved for the possibility of future Signal Specification formats.

Health and Status bits are defined as follows:

Bit 0 (LSB) Ranging On (0), Off (1)

Bit 1 Corrections On (0), Off (1)

Bit 2 Broadcast Integrity On (0), Off (1)

Bits 3 - 7 Reserved (0)

Note that if all bits are 0, the Health and Status are OK for all functions.

END OF DOCUMENT

document production · gala ref : date : gala-als-dd-014 12-04-2001 ephemeris, almanacs and...

Documents