Navipedia - User contributions [en]

Time References in GNSS

2026-03-23T09:43:54Z

Natalia.Castrillo:

{{Article Infobox2
|Category=Fundamentals
|Authors=J. Sanz Subirana, J.M. Juan Zornoza and M. Hernández-Pajares, Technical University of Catalonia, Spain.
|Level=Basic
|YearOfPublication=2011
|Title={{PAGENAME}}
}}

GNSS Systems strongly rely on measuring the time of arrival of radio signals propagation. Thus, each GNSS System has its own time reference from which all elements of the Space, Control and User segments are time synchronized, as well most of the [[GNSS Applications|GNSS-based applications]].
The most relevant GNSS time references are briefly described below.

==GPS Time (GPST)==
GPS Time (GPST) is a continuous time scale (no leap seconds) defined by the GPS Control segment on the basis of a set of atomic clocks at the Monitor Stations and onboard the satellites. It starts at 0h UTC (midnight) of January 5th to 6th 1980 (6.d0). At that epoch, the difference TAI−UTC was 19 seconds, thence GPS−UTC=n − 19s. GPS time is synchronised with the UTC(USNO) at 1 microsecond level (modulo one second), but actually is kept within 25 ns.<ref name="GPS ICD 200">[https://archive.gps.gov/technical/icwg/IS-GPS-200N.pdf GPS ICD-200 Revision N, "Navstar GPS Space Segment/Navigation User Segment Interfaces"]</ref>

==GLONASS Time (GLONASST)==
GLONASS Time (GLONASST) is generated by the GLONASS Central Synchroniser and the difference between the UTC(SU) and GLONASST should not exceed 1 millisecond plus three hours<ref group="footnotes">The difference between Moscow Time and Greenwich Mean Time (GMT).</ref> (i.e.,<math>GLONASST=UTC(SU)+3^h-\tau</math>, where <math>|\tau|< 1
milisec.</math>), but <math>\tau</math> is typically better than 1 microsecond. Note: Unlike GPS, Galileo or BeiDou, GLONASS time scale implements leap seconds, like UTC.<ref name="GLONASS ICD">GLONASS Interface Control Document, Russian Institute of Space Device Engineering, Edition 5.1, 2008</ref>

==Galileo System Time (GST)==
Galileo System Time (GST) is a continuous time scale maintained by the Galileo Central Segment and synchronised with TAI with a nominal offset below 50 ns. The GST start epoch, GST(T0), is defined 13 seconds before 0:00:00 UTC on Sunday, 22 August 1999 (midnight between 21 and 22 August).<ref name="Galileo OS ICD">[https://www.gsc-europa.eu/sites/default/files/sites/all/files/Galileo_OS_SIS_ICD_v2.2.pdf Galileo Open Service Signal In Space Interface Control Document (OS SIS ICD), EUSPA, Issue 2.2, November 2025]</ref>

==BeiDou Time (BDT)==
BeiDou Time (BDT) is a continuous time scale starting at 0h UTC on January 1st, 2006<ref name="BDS B2b ICD">[http://en.beidou.gov.cn/SYSTEMS/ICD/202008/P020231201537880833625.pdf BeiDou Navigation Satellite System Signal In Space Interface Control Document Open Service Signal B2b, China Satellite Navigation Office, Version 1.0, July 2020]</ref>. In order to be as consistent as possible with UTC, BDT may steer to an interposed frequency adjustment after a period of time (more than 30 days) according to the situation, but the quantity of adjustment is not to allowed more than 5x10E-15 <ref>[https://nap.nationalacademies.org/read/13292/chapter/10#87 National Academies of Sciences, Engineering, and Medicine. 2012. Global Navigation Satellite Systems: Report of a Joint Workshop of the National Academy of Engineering and the Chinese Academy of Engineering. Washington, DC: The National Academies Press]</ref>.

==Notes==
<references group="footnotes"/>

==References==
<references/>

[[Category:Fundamentals]]
[[Category:GNSS Time Reference, Coordinate Frames and Orbits]]

Time References in GNSS

2026-03-23T09:41:06Z

Natalia.Castrillo:

{{Article Infobox2
|Category=Fundamentals
|Authors=J. Sanz Subirana, J.M. Juan Zornoza and M. Hernández-Pajares, Technical University of Catalonia, Spain.
|Level=Basic
|YearOfPublication=2011
|Title={{PAGENAME}}
}}

GNSS Systems strongly rely on measuring the time of arrival of radio signals propagation. Thus, each GNSS System has its own time reference from which all elements of the Space, Control and User segments are time synchronized, as well most of the [[GNSS Applications|GNSS-based applications]].
The most relevant GNSS time references are briefly described below.

==GPS Time (GPST)==
GPS Time (GPST) is a continuous time scale (no leap seconds) defined by the GPS Control segment on the basis of a set of atomic clocks at the Monitor Stations and onboard the satellites. It starts at 0h UTC (midnight) of January 5th to 6th 1980 (6.d0). At that epoch, the difference TAI−UTC was 19 seconds, thence GPS−UTC=n − 19s. GPS time is synchronised with the UTC(USNO) at 1 microsecond level (modulo one second), but actually is kept within 25 ns.<ref name="GPS ICD 200">[https://archive.gps.gov/technical/icwg/IS-GPS-200N.pdf GPS ICD-200 Revision N, "Navstar GPS Space Segment/Navigation User Segment Interfaces"]</ref>

==GLONASS Time (GLONASST)==
GLONASS Time (GLONASST) is generated by the GLONASS Central Synchroniser and the difference between the UTC(SU) and GLONASST should not exceed 1 millisecond plus three hours<ref group="footnotes">The difference between Moscow Time and Greenwich Mean Time (GMT).</ref> (i.e.,<math>GLONASST=UTC(SU)+3^h-\tau</math>, where <math>|\tau|< 1
milisec.</math>), but <math>\tau</math> is typically better than 1 microsecond. Note: Unlike GPS, Galileo or BeiDou, GLONASS time scale implements leap seconds, like UTC.<ref name="GLONASS ICD">GLONASS Interface Control Document, Russian Institute of Space Device Engineering, Edition 5.1, 2008</ref>

==Galileo System Time (GST)==
Galileo System Time (GST) is a continuous time scale maintained by the Galileo Central Segment and synchronised with TAI with a nominal offset below 50 ns. The GST start epoch, GST(T0), is defined 13 seconds before 0:00:00 UTC on Sunday, 22 August 1999 (midnight between 21 and 22 August).<ref name="Galileo OS ICD">[https://www.gsc-europa.eu/sites/default/files/sites/all/files/Galileo_OS_SIS_ICD_v2.2.pdf Galileo Open Service Signal In Space Interface Control Document (OS SIS ICD)], EUSPA, Issue 2.2, November 2025</ref>

==BeiDou Time (BDT)==
BeiDou Time (BDT) is a continuous time scale starting at 0h UTC on January 1st, 2006<ref name="BDS B2b ICD">http://en.beidou.gov.cn/SYSTEMS/ICD/202008/P020231201537880833625.pdf BeiDou Navigation Satellite System Signal In Space Interface Control Document Open Service Signal B2b, China Satellite Navigation Office, Version 1.0, July 2020</ref>. In order to be as consistent as possible with UTC, BDT may steer to an interposed frequency adjustment after a period of time (more than 30 days) according to the situation, but the quantity of adjustment is not to allowed more than 5x10E-15 <ref>[https://nap.nationalacademies.org/read/13292/chapter/10#87 National Academies of Sciences, Engineering, and Medicine. 2012. Global Navigation Satellite Systems: Report of a Joint Workshop of the National Academy of Engineering and the Chinese Academy of Engineering. Washington, DC: The National Academies Press]</ref>.

==Notes==
<references group="footnotes"/>

==References==
<references/>

[[Category:Fundamentals]]
[[Category:GNSS Time Reference, Coordinate Frames and Orbits]]

The EGNOS SBAS Message Format Explained

2026-02-25T08:33:52Z

Natalia.Castrillo:

{{Article Infobox2
|Category=EGNOS
|Authors=Daniel Porras Sánchez & César Pisonero Berges, GMV S.A., Spain.
|Level=Basic
|YearOfPublication=2006
|Logo=ESA
|Title={{PAGENAME}}
}}
==Introduction==
This article contains a brief summary of EGNOS signal structure as described in RTCA MOPS DO-229-C “''Minimum Operational Performance Standards for Global Positioning System/Wide Area Augmentation System airborne equipment''” (particularly in its Appendix A “''Signal characteristics and format''”) just to allow the reader to have a first contact with the specification of the SiS that is applicable for Satellite Based Augmentation Systems (SBAS), in particular for the European EGNOS.

It is worthwhile to highlight that the SBAS SiS specification is also detailed in the ICAO SARPs “Standards and Recommended Practices”, Appendix B “Detailed technical specifications for the Global Navigation Satellite System (GNSS)”. These two standards are nearly aligned in what regards to the SBAS SiS specification but still some differences remain. In fact, some topics such as the augmentation of GLONASS constellation is covered by the ICAO SARPs but not by the MOPS and hence both MOPS and SARPs will be referenced along the following paragraphs.

For a more precise knowledge of EGNOS SiS specification the reading of the aforementioned annex of MOPS is recommended. The purpose of the material presented hereafter is just to summarise the contents of MOPS Appendix A in order to make easier the first touch with it for those readers that are not familiarised with aviation equipment standards.

==Summary of EGNOS SiS==
===SBAS broadcast data===
Every satellite-based wide area augmentation system, as the European system EGNOS, does provide ranging signals transmitted by GEO satellites, differential corrections on the wide area and additional parameters aimed to guarantee the integrity of the GNSS user:
* GEO Ranging: transmission of GPS-like L1 signals from GEO satellites to augment the number of navigation satellites available to the users.
* Wide Area Differential (WAD): differential corrections to the applicable GNSS/GEO navigation services computed in a wide area to improve navigation services performance.
* GNSS/Ground Integrity Channel (GIC): integrity information to inform about the availability of GNSS/GEO safe navigation service.
SBAS shall provide the following information:
* Satellite orbit and clock corrections to the existing satellite navigation services (GNSS and GEO), as well as the estimation of errors associated to satellites (UDRE).
* Ionospheric corrections for a given grid of points, as well as the estimation of errors associated to ionosphere (GIVE).
* Tropospheric corrections. Satellite orbit/clock corrections and ionospheric corrections are dynamically modelled. The SBAS shall communicate the user the corrections that are available to be used by the receiver. The information of the models is packed on messages to be sent to the user. On the other hand, tropospheric corrections are statically modelled, which means that corrections are tabulated and the information does not depend on any external behaviour but the user position (a mean troposphere is assumed). The algorithm for computing the tropospheric correction is available to the global community (section A.4.2.4 of MOPS).
In addition to this, navigation data for each GEO satellite supporting ranging service is also transmitted through SBAS.
SBAS interacts with the user via the Signal in Space (SiS). The way the SBAS delivers to the user the aforementioned corrections and integrity data as well as some ancillary information (timing, degradation parameters, etc.) is through messages encoded in the signal. These messages are sent each second with a data rate of 250 bits, as it is explained in the following section.
====Signal data structure====
The raw navigation message of the SBAS contains 500 bits. These raw data are ½ convolutional encoded with a FEC code, which means that 250 bits of information are available every second at user level.
The 250-bit message has different parts, including an 8-bit preamble and 24 ancillary bits to include redundancy and error checking within the message. The following table and figure summarise the message format. Bit 0 is considered the most significant bit, i.e. the bit that is transmitted and received first.

{|{{Prettytable}}
|+ align="bottom"|'''''Table 1:''''' SBAS Message format (components).
!style="background-color:#D5D6D2"|Position in message
!style="background-color:#D5D6D2"|Name
!style="background-color:#D5D6D2"|Purpose
|-
|0-7
|Preamble
|Assure frame synchronisation
|-
|8-13
|Message type identifier
|Define the type of message
|-
|14-225
|Data field
|GIC/WAD information
|-
|226-249
|Parity information
|Redundancy & error checking
|}

[[File:SBAS Message format.jpg|none|thumb|400px|alt=SBAS Message format|'''''Figure 1:''''' SBAS Message format (lengths in bits)]]

A brief explanation of the different data fields is presented hereafter:
* Preamble. It is a unique 24–bit field, distributed over three successive words. The preamble sequence (in three consecutive words) is 01010011 (83) - 10011010 (154) - 11000110 (198). It is assured that the start of the preamble is synchronous with a 6-second GPS sub-frame. Thus, the preamble allows the receiver to achieve frame synchronisation.
* Message Type Identifier. It is a 6-bit field, which permits up to 64 different messages (identifiers 0 to 63). Depending on the message type, the information included in the Data field has different meaning. Even though 64 type messages are available, only 20 are currently defined.
* Data Field. It contains different corrections and integrity information that depends on the type of message. The specific content of this field will be addressed in the following sections.
* Parity Information. The 24 bits of the end of the message (CRC parity bits) provide protection against burst and random error. For more information on parity bits algorithm generator see MOPS.

Messages are interrelated using the Issue of Data parameters (IOD), which are present in the message data. Also satellite messages are related with satellite navigation services ephemeris via the issues of data.

The sequence of transmission of the messages is not fixed and is responsibility of the SBAS Service Provider (each second the provider decides which message is to be sent). There are requirements in MOPS concerning the refresh time for each type of information and about the alarm conditions (problems with one or more satellite information or with ionospheric information). Under an alert condition, the SBAS must repeat the message with the alert information up to three times (i.e. four messages in four seconds in total). Further details in the next sections.

===Message types===
SBAS messages have a 6-bit message type identifier, which informs the receiver about the information the message holds. Due to the limited size of the type identifier (6 bits), 64 types of messages are possible. Nowadays, only 20 of these messages are defined. The following table summarises the current message types and the contained information.

{|{{Prettytable}}
|+ align="bottom"|'''''Table 2:''''' SBAS Message types.
!style="background-color:#D5D6D2"|Type
!style="background-color:#D5D6D2"|Contents
|-
|0
|Don’t use for safety applications
|-
|1
|PRN mask assignments, set up to 51 of 210 possible
|-
|2-5
|Fast corrections
|-
|6
|Integrity information
|-
|7
|Degradation Parameters
|-
|9
|Geo Navigation message (''X'',''Y'',''Z'', time, etc.)
|-
|10
|Degradation parameters
|-
|12
|SBAS Network time / UTC offset parameters
|-
|17
|Geo satellite almanacs
|-
|18
|Ionospheric grid points masks
|-
|24
|Mixed fast corrections/long term satellite error corrections
|-
|25
|Long term satellite error corrections
|-
|26
|Ionospheric delay corrections
|-
|27
|SBAS Service message
|-
|28
|Clock Ephemeris Covariance Matrix message
|-
|62
|Internal test message
|-
|63
|Null message
|}

As a rough approximation, there are three different categories of messages: messages related with satellite information, messages related with ionospheric information and other ancillary messages. Several of those messages are interrelated using the IOD parameters present in the message data.

===Satellite information messages===
Satellite related messages contain the differential corrections that shall be applied to each satellite to improve the satellite clock and satellite orbit provided by the existing satellite navigation services. Also GEO navigation message is broadcast as no external system provides the GEO ephemeris data.

The following table summarises the messages included in this section.

{|{{Prettytable}}
|+ align="bottom"|'''''Table 3:''''' Satellite messages.
!style="background-color:#D5D6D2"|Type
!style="background-color:#D5D6D2"|Contents
|-
|1
|PRN mask assignments, set up to 51 of 210 possible
|-
|2-5
|Fast corrections
|-
|6
|Integrity information
|-
|7
|Fast correction degradation factor
|-
|9
|Geo Navigation message (''X'',''Y'',''Z'', time, etc.)
|-
|17
|Geo satellite almanacs
|-
|24
|Mixed fast corrections/long term satellite error corrections
|-
|25
|Long term satellite error corrections
|-
|28
|Clock Ephemeris Covariance Matrix message
|}

====Message type 1====
Message type 1 includes the PRN mask assignments, chosen among the applicable GNSS and GEO satellites. Instead of sending for each correction the satellite PRN associated with, a mask is created to save space in the messages. This bit mask contains the i-th bit to 1 to inform that i-th satellite PRN is being used.

Although there are 210 slots (bits) in the mask, only a maximum of 51 can be set at a time due to constraint in the limited size available to broadcast information (message type 6 does only have enough free space to allocate UDREI figures for 51 satellites). Corrections are provided only for these satellites.

The user will read the mask and then each satellite correction will be related with the satellite via the mask contained in this message. IODP indicates the mask’s applicability to the corrections contained in the messages to which the mask applies.
Message type 1 format and the PRN allocations for message type 1 (depending on the satellite navigation service provider) are defined the section A.4.4.2 of MOPS.

====Message types 2 to 5====
Messages of type 2, 3, 4 and 5 include satellite fast corrections and UDRE values (via the UDRE indicator, UDREI). Message type 2 includes the information related to the first 13 satellites in mask. Message type 3 contains information related to the 14th to the 26th satellite in the mask and so on. If the number of satellites in mask is less than 40, the message type 5 will not used. If the number of satellites in the mask is less than 26, the message type 4 will not be broadcast. Finally, if there are less than 6 satellites to be allocated in the last fast correction message, this message type 2 to 5 can be replaced by a message type 24.

Summarizing the above mentioned requirements, fast corrections messages that have to be broadcast depending on the number of configured satellites are reflected in the following table:

{|{{Prettytable}}
|+ align="bottom"|'''''Table 4:''''' Different combinations of fast corrections messages.
!
!style="background-color:#D5D6D2"|MT2
!style="background-color:#D5D6D2"|MT3
!style="background-color:#D5D6D2"|MT4
!style="background-color:#D5D6D2"|MT5
!style="background-color:#D5D6D2"|MT24
|-
|style="background-color:#D5D6D2"|Number of SV ∈[1,13]
|X
|
|
|
|-
|style="background-color:#D5D6D2"|Number of SV ∈[14,19]
|X
|
|
|
|X
|-
|style="background-color:#D5D6D2"|Number of SV ∈[20,26]
|X
|X
|
|
|
|-
|style="background-color:#D5D6D2"|Number of SV ∈[27,32]
|X
|X
|
|
|X
|-
|style="background-color:#D5D6D2"|Number of SV ∈[33,39]
|X
|X
|X
|
|
|-
|style="background-color:#D5D6D2"|Number of SV ∈[40,45]
|X
|X
|X
|
|X
|-
|style="background-color:#D5D6D2"|Number of SV ∈[46,51]
|X
|X
|X
|X
|
|}

The time of applicability of the fast corrections, which is used in fast correction computation, is defined as the start of the epoch of the SBAS Network Time (SNT) second that is coincident with the transmission of the first bit of the message block (bit belonging to the preamble) at the GEO satellite.

The message format is defined the section A.4.4.3 of MOPS, as well as the table that the SBAS user will consider to translate the UDREI to a variance σ2UDRE. Note that the status of the satellite is also included into the UDREI:
* Use: UDREIs from 0 to 13 indicates that the satellite is usable.
* Not Monitored: UDREI=14 indicates that the satellite does not appear in the mask or even appearing there are not corrections or UDRE values available for it.
* Don’t Use: UDREI=15 indicates that an inconsistency has been found for this satellite (alarm situation) or the estimated fast correction is greater than 256.0 m.

====Message type 6====
Message type 6 contains the integrity information for 51 satellites, which is the maximum number of satellites that can be present in the PRN mask. This message also includes IODFj (j=2…5) to relate the UDREI to the fast corrections included in messages of type 2 to 5 or 24.

Message type 6 can be used in two different ways. On the one hand, it allows the fast corrections to be updated infrequently. In PA mode the UDREI values have a time-out of 12 seconds, while the time-out for fast corrections is between 12 and 120 seconds, depending on information sent in message type 7. On the other hand, message type 6 may be also used in case of satellite alert conditions (even if just one satellite is in alert mode).
The message type 6 format is defined the section A.4.4.4 of MOPS. It has to be remarked that this message does not include an IODP and hence the link to the PRN mask is not provided within the message. The UDRE indicators included in message type 6 do apply to the satellites defined in the last received PRN mask.

====Message type 7====
Message type 7 includes the degradation factors in time for the fast corrections received in fast corrections messages (types 2 to 5, 24) as well as the system latency time.

The fast correction degradation factor indicators, aij, where j is the satellite in mask, are translated into fast correction degradation factors ai (in metres), used for fast correction degradation, and user time-out interval for fast corrections Ifc (in seconds) for the different phases of flight, following the Table A-8 of MOPS.

Message type 7 format is included in the section A.4.4.6 of MOPS.

====Message type 9====
Message type 9 contains the information about the GEO navigation.
As GEO satellites do not belong to any satellite positioning service (e.g. GPS, GLONASS), ephemeris for those satellites are not externally available. Therefore, it is the SBAS that is in charge of providing the user with the GEO ephemeris. Keep in mind that all components are expressed in ECEF reference coordinates and the time offset is with respect to SBAS Network time (SNT).

The message format is included in the section A.4.4.11 of MOPS. In addition to the ephemeris data an URA (User Range Accuracy), as defined for GPS satellites, is also provided. An IODN used to link the GEO long-term corrections with the message type 9 ephemeris is included in the previous versions of MOPS, but it has been removed from MOPS. However EGNOS makes use of this parameter to match the long-term corrections broadcast for its GEO satellites with the appropriate navigation data broadcast through message type 9.

The GEO satellite will provide message type 9 with its own navigation (so for that no PRN nor PRN mask is included in the message). A receiver using more than a GEO will receive and decode the message type 9 for each GEO satellite from the corresponding broadcast lane.

====Message type 17====
Message type 17 contains the almanac for up to three GEO satellites (more than one message of this type can be broadcast if almanacs are provided for a higher number of SBAS GEO satellites). Almanacs only provide information about satellite health and status as well as its rough position. Unused slots are marked with the PRN set to zero. No IODP is needed as each satellite PRN number is included.

The message format is included in the section A.4.4.12 of MOPS. As it can be appreciated, the precision of message type 17 parameters is worse than the one defined for the parameters of message type 9. The information included in messages of type 17 does only inform the user about the existence of the GEO satellites, their location, the general service provided and heath and status for acquisition purposes.
However, GEO almanac positions cannot be used in the computation of the user position: message type 9 parameters have to be considered.

====Message type 25====
Message type 25 includes estimations of slow varying satellite ephemeris and clock errors (in ECEF WGS-84) with respect to the ephemeris and clock parameters broadcast by the satellite navigation service. IODE is used to relate the long-term corrections with the ephemeris used to which the corrections are computed.

Long-term corrections are available to both the applicable GNSS and GEO satellites that belong to another SBAS.

Long-term corrections for GEO satellites that do belong to the SBAS will be included in message type 9. Note however that this is not EGNOS approach. In addition to this, for visible GEO satellites not belonging to the SBAS but providing long-term corrections in message type 25, these corrections in message type 25 have to be related with message type 9 coming from the other SBAS. EGNOS makes use of satellite IODN of message type 9 although this parameter has been removed from MOPS and SARPS.

The Data Field of the message type 25 (212 bits long, from bit 16 to bit 227) is divided into two parts of 106 bits each. The information contained in each message half depends on the first bit of the sequence of 106 (named Velocity Code). Only the definition of one half is included hereafter since the other part has exactly the same structure.
* If the Velocity Code is 0, no drift (orbital velocity components and clock drift) is included in this part of the message. Long-term corrections for up to two satellites are included in this half part of the message in this case.
* If the Velocity Code is 1, orbital velocity components and clock drift are included in this part of the message. As more space is needed (compared with the case in which the Velocity Code is set to 0), only long-term corrections for one satellite are included.
Message type 25 format is included in the section A.4.4.7 of MOPS.

====Message type 24====
Message type 24 contains both fast and long-term satellite corrections. Message type 24 can be broadcast if the number of satellites in the last fast correction message is less than or equal to 6.

Message type 24 format is included in the section A.4.4.8 of MOPS. The first half includes fast corrections for 6 or less satellites whereas the second half holds the same long-term information as each half of the message type 25 (long term corrections for one or two satellites, depending on the value of the velocity code parameter).

====Message type 28====
This is an optional message included in the last versions of the standards, but it is not considered in the baseline of EGNOS for the time being.
Message type 28 may be broadcast to provide the relative covariance matrix for clock and ephemeris error. Each covariance matrix is updated on the same order as the long-term corrections. This is an expansion of the information contained in the 2UDRE in that it specifies the correction confidence as a function of user location. This way message type 28 provides increased availability inside the service area and increased integrity outside.

Each satellite covariance matrix is a function of satellite location, reference station observational geometry, and reference station measurement confidence. Consequently it is a slowly changing function of time and hence it is updated on the same order as the long-term corrections.
Message type 28 definition is included in the section A.4.4.16 of MOPS.

====Interrelations between satellite messages====
The following Issues of Data (IODs) are defined in order to relate the information of previously issued messages. There is no IOD linking fast corrections to long-term corrections, as small jumps depending on the use of one or other long-term correction with the same fast correction are allowed by the SBAS.

=====IODP=====
The IODP (Issue Of Data PRN mask) relates messages 2 to 5, 7, 24, 25 and 28 with message type 1. IODP appears in each of the previous messages. It is used to connect the information contained in messages 2 to 5, 7, 24, 25 and 28 with the satellite mask defined in a message type 1 that contains the same IODP.

Each time the mask changes, which will be very infrequent and normally due to a satellite launch or a satellite that is permanently set out of service, the IODP is incremented in 1 modulo 4 (i.e. from 3 goes to 0). Satellites that are temporarily but not permanently set out of service (e.g. during a manoeuvre) will not be removed from the PRN mask but flagged as “Not Monitored” in the UDREI section.
During a change in the PRN mask, and to avoid interruption of the service, the user equipment shall keep both masks in order to use information with the old and with the new IODP. In case the IODP changes in messages 2 to 5, 7, 24, 25 or 28 before the reception of the new mask, which is not the nominal situation, the information contained in them cannot be used until the reception of the new message type 1. These messages shall be stored to be used after the new PRN mask is received.

Message type 6 is related with messages of type 2 to 5 and 24 via the IODF, but it does not include an IODP and therefore the link to the PRN mask is not provided within the message. The UDRE indicators included in message type 6 do apply to the satellites defined in the last received PRN mask.

=====IODF=====
The IODF (Issue Of Data Fast Corrections) is used to link the data broadcast in messages of type 2 to 5 with the UDREI transmitted in the message type 6. There are four IODF parameters: IODFj links message type "j" to message type 6, with j = 2, 3, 4, 5 (the IODF broadcast in message type 24 is one of these, depending on the fast corrections message that it replaces).

In the message type 6 the four IODFs are included. Every time a new message type 2 to 5 is sent, the IODFj is incremented in 1 unit between 0 and 2. The value IODFj = 3 is usable under alarm condition and means that UDREI values apply to all active data from the corresponding fast correction message type (message type "j").

=====IODE/IODC=====
For GPS satellites: 
The IODE (Issue Of Data Ephemeris) included in message type 25 (and also in the long-term part of message type 24) links the long-term orbit and clock corrections contained in the SBAS message to the GPS satellite broadcast ephemeris with the same IODE. For GPS satellites the IODE is defined as the 8 least significant bits of the IODC defined for each ephemeris in the GPS ICD.

The user shall maintain at least two GPS ephemerides. If the GPS IODE does not match the long-term correction IODE, this is an indicator that a new GPS ephemeris is being broadcast. The user shall continue using the previous ephemeris until the reception of long-term correction with the new IODE.

For GLONASS satellites: 
As no IODE is included in GLONASS ephemerides, an ancillary algorithm has been defined to link these ephemeris and the long-term corrections broadcast by the SBAS. This algorithm is defined in SARPS but not in MOPS (GLONASS constellation in not augmented by WAAS and there are no plans for doing it in the future).

For GEO satellites: 
Long-term corrections have only to be broadcast for GEO satellites that do not belong to the SBAS but to another SBAS. The way to link the GEO long-term corrections to the GEO ephemeris (message type 9 broadcast by that satellite, but filled by another SBAS) is to use the IODN defined in message type 9 as a GPS-like IODE. Although the 8 bits of the IODN field have been left spare in the last versions of the applicable standards, EGNOS makes use of the IODN to match the GEO long-term corrections with the appropriate message type 9 ephemeris.

===Ionospheric information messages===
The [[Ionospheric Delay|ionospheric delay]] depends on the path that the signal traverses or through which the signal propagates. A grid 350 km above the WGS-84 ellipsoid Earth approximation is defined, with ionospheric delay corrections broadcast for those special points, known as Ionospheric Grid Points (IGPs). The ionospheric vertical delay estimates applicable to L1 signal (ionospheric delay depends on the frequency of the signal) of these IGPs are broadcast (Grid Ionospheric Vertical Delay, GIVD).

The ionospheric corrections applied by the user depend on the GIVDs of the IGPs, the Ionospheric Pierce Point (IPP) which is the location on which the line-of-sight crosses the layer at 350 km and the elevation of that line-of-sight. Knowing the location of the IGPs and the estimated ionospheric delay for them, the user can compute for each measurement the ionospheric delay interpolating among the IGPs located in the neighbourhood of the line of sight user-satellite corresponding to this measurement.

The following table summarises the messages included in this section.

{|{{Prettytable}}
|+ align="bottom"|'''''Table 5:''''' Ionospheric related messages.
!style="background-color:#D5D6D2"|Type
!style="background-color:#D5D6D2"|Contents
|-
|18
|Ionospheric grid points masks
|-
|26
|Ionospheric delay corrections
|}

The IGPs that constitute the interpolation grid are predefined, divided in 11 numbered bands (band 0 to band 10) on a Mercator projection map of the Earth surface. Bands 0 to 8 are vertical, while bands 9 and 10 are defined around the poles. A total of 2192 IGPs are considered. Because of the large variation in the ionosphere vertical delay due to the solar activity, IPGs are more densely defined at lower latitudes.

Within each band between 0 and 8, IGPs are numbered from 1 to 201, starting from the South-West corner up each longitude column of the band from South to North and continuing for each column from West to East from the bottom of each column (there is not an IGP 201 in band 8).
Within bands 9 and 10, IGPs are numbered from 1 to 192. The IGPs are numbered counting eastward from the western corner closest to the equator along each latitude row of the band (from West to East) and continuing for each row towards the poles.
IGP coordinates are defined in the Table A-14 of MOPS.

====Message type 18====
Messages type 18 include the ionospheric mask. Each message contains the mask information of a band. A bit set to 1 indicates that ionospheric correction information is being provided for that IGP.

Also the IODI is included in the message. IODI range is from 0 to 3, changing each time the IGP mask is modified, which is expected to happen rarely. The user will link the corrections in messages of type 26 with the band definition in message type 18 using the IODI.
As SBAS is a wide area, but local system though, the system will broadcast vertical ionospheric delays only for a restricted set of IGPs. In this sense:
* Bands that are not used by the SBAS (i.e. band 0 in EGNOS) do not have to be broadcast in a dedicated message type 18 with all IGPs set to 0.
* If the ionospheric band contains less than 201 IGPs, the IGP mask slots corresponding to those bits that represent IGPs that do not exit are set to 0.
The receiver uses the parameter “Number of Bands being broadcast” to know if there are more bands to be acquired or all available data have been received yet. It is necessary to get all messages of type 18 (the complete IGP mask) prior to use the information broadcast through messages of type 26.
The format of message type 18 is included in the section A.4.4.9 of MOPS.

====Message type 26====
Messages of type 26 provide the Ionospheric Delay Corrections (GIVD) and their accuracy (σ2GIVE) in terms of GIVEI (GIVE Indicators) for the IGPs that are configured in the mask. In order to match the ionospheric information with the applicable IGP mask the IODI parameter is also included.
The format of these messages is included in the section A.4.4.10 of MOPS. The table that the SBAS user will use to translate the GIVEI to a variance σ2GIVE is also included in this section.

As only 15 IGPs fit in message type 26 meanwhile each ionospheric band has up to 201, the bands are divided into blocks. Each block holds 15 IGPs. Block 0 contains the corrections for the first 15 IGPs in the mask (not in the band), block 1 contains the correction for 16 to 30 IGPs in mask … Each band is therefore divided into a maximum of 14 blocks (it is possible and normal to be divided in less blocks as a SBAS is not able to observe a whole band).

The status of an IGP, like for a satellite, can be:
* Use: There are available IGP Delay Estimate and GIVEI.
* Not Monitored: IGP does not appear in mask or even appearing in mask there is not available Delay Estimate or GIVEI.
* Don’t Use: An inconsistency has been found for this IGP (alarm situation) or the estimated delay is greater than 63.750 m. The user has to be alerted of the strange behaviour in the IGP for not to use it. IGP Delay Estimate is always positive since the ionosphere produces a positive delay in signal code. An IGP Delay Estimate of 63.875 m (byte 11111111 in the message field) indicates an alarm situation for the IGP.
The algorithm to compute the ionospheric delay correction and the upper bound of the residual error for a given line of sight based on the corrections and error bounds that are broadcast in messages of type 26 is included in A.4.4.10 of MOPS.

===Other messages===
This section includes the messages that are not directly related with satellite corrections or with ionospheric corrections. The information included in these messages is ancillary SBAS information, useful to compute the user navigation position in PA operations, to compute precisely the UTC time, or to degrade the UDRE over selected regions.

The following table summarises the messages included in this section.

{|{{Prettytable}}
|+ align="bottom"|'''''Table 6:''''' Other Messages.
!style="background-color:#D5D6D2"|Type
!style="background-color:#D5D6D2"|Contents
|-
|0
|Don’t use for safety applications
|-
|10
|Degradation parameters
|-
|12
|SBAS Network time / UTC offset parameters
|-
|27
|SBAS Service message
|-
|62
|Internal test message
|-
|63
|Null message
|}

====Message type 0====
This message will be used during SBAS testing. After the reception of message type 0, all ranging and correction information obtained from the SBAS must be discarded for safety critical applications. The existence of a message type 0 indicates that the system integrity performances are not assured.

MOPS has introduced a new potential use for the message of type 0, which is optional. During SBAS testing, the contents of message type 2 can be included in message type 0 and in such case it is not necessary to transmit this fast correction message. This information can be used for non-safety critical applications.

====Message type 10====
Message type 10 contains degradation parameters. These parameters are not satellite or IGP dependent so only one message of this type will be needed for the SBAS. The specific format is defined in the section A.4.4.6 of MOPS.

These parameters are used in the computation of the degradation parameters for fast and long-term corrections σ2flt and ionospheric corrections σ2ionogrid (defined in sections A.4.5.1 and A.4.5.2 of MOPS) for Precision Approach operations.

====Message type 12====
Message type 12 contains information about time-offset parameters between different system times. The first 104 bits contains the UTC parameters in the format defined in the GPS ICD. Then GPS time is included (in Seconds of Week and Week Number format) and a bit to indicate if GLONASS time offset is provided or not.

In addition to this, a time offset parameter to steer GLONASS time into SBAS time has been included in SARPS. In MOPS this parameter is not yet defined. EGNOS service provider makes use of this offset for the computation of GLONASS long-term clock correction, and EGNOS users need it to combine GPS and GLONASS measurements in the determination of their position and time.
Message type 12 format is defined in the section A.4.4.15 of MOPS.

====Message type 27====
This is an optional message not considered in the baseline of EGNOS.
Messages of type 27 are used to increase the UDRE values that are broadcast through messages of type 2 to 5, 6 or 24 over several selected areas. This degradation is incompatible with the one defined in message type 28. The message contains the value of δUDRE factor (a multiplier factor) to be applied to integrity monitoring algorithms depending on the user location: inside any defined region or outside of all regions.
Each message contains up to 5 regions. If more regions are defined in the SBAS, more than one message type 27 will be broadcast. Different messages of type 27 are linked between them via IODS parameter (Issue of Data Service Message). Each time a parameter in any message type 27 of the group is changed, the IODS is incremented, being the effective range is from 0 to 7. Two messages with the same IODS have the same value for δUDRE factor outside.

Priority code is used to allow the overlapping of the regions. A user situated in the intersection of two or more regions will use the δUDRE factor for the region with the higher priority code. In case of equality in priority code, the user will use the smallest δUDRE factor as this results in better performance.
Messages type 27 format is defined in the section A.4.4.13 of MOPS.
====Message type 62====
EGNOS does not transmit this optional message, which can be broadcast for SBAS internal test only. Upon reception of this message, the user will continue using the GEO broadcast data and ranging capabilities, but no additional information is acquired.
====Message type 63====
EGNOS does not transmit this optional message, which can be broadcast in case no other message is available to be sent. Upon reception of this message, the user will continue using the GEO broadcast data and ranging capabilities, but no additional information is acquired.

===Messages time-outs and alerts===
====Message time-outs====
The following table (which is just a mimic of Table A-25 of MOPS) includes the maximum update interval requirements for the SBAS data broadcast through the different messages, not for the messages themselves. There are various types of phase of flight: En Route, Terminal, Non-Precision Approach (NPA) and Precision Approach (PA), being PA the most restrictive one. Time-outs for corrections, integrity and GEO navigation data corresponding to the different phases of flight are also included in the table (they limit the interval of applicability of SBAS data):

{|{{Prettytable}}
|+ align="bottom"|'''''Table 7: '''''SBAS data broadcast intervals.
!style="background-color:#D5D6D2"|SBAS Data
!style="background-color:#D5D6D2"|Maximum update interval (s)
!style="background-color:#D5D6D2"|En Route, Terminal, NPA Time-outs (s) Precision Approach
!style="background-color:#D5D6D2"|Time-outs (s)
!style="background-color:#D5D6D2"|Associated Message Types
|-
|Don’t use for safety applications
|6
|N/A (*)
|N/A (*)
|0
|-
|PRN mask
|120 (**)
|600
|600
|1
|-
|UDREI
|6
|18
|12
|2 to 6, 24
|-
|Fast Corrections
|See MOPS Table A-8
|See MOPS Table A-8
|See MOPS Table A-8
|2 to 5, 24
|-
|Long Term Corrections
|120
|360
|240
|24, 25
|-
|GEO Navigation Data
|120
|360
|240
|9
|-
|Fast Correction Degradation
|120
|360
|240
|7
|-
|Degradation Parameters
|120
|360
|240
|10
|-
|Ionospheric Grid Mask
|300 (**)
|1200
|1200
|18
|-
|Ionospheric Corrections
|300
|600
|600
|26
|-
|UTC Timing Data
|300
|86400
|86400
|12
|-
|Almanac Data
|300
|None
|None
|17
|-
|Service Level
|300 (if used)
|86400
|86400
|27
|-
|Clock. Ephemeris Covariance Matrix
|120
|360
|240
|28
|}

''(*) Message type 0 must be sent only if the system is not usable for safety-critical applications. After the reception of a message type 0 the SBAS signal shall be de-selected and all data received for one minute shall be discarded.
''

''(**) Message type 1 (PRN Mask) and Message type 18 (IGP Mask) should be repeated several times whenever the satellite or ionospheric mask is changed respectively. This will ensure that all users receive the new mask before it is applied maintaining high continuity (i.e. in EGNOS message type 1 is sent four times within one minute upon a change of PRN mask).
''

====Alert conditions====
An alarm situation can be defined as a non-expected behaviour of the SBAS corrections. Two types of alarms are possible:
* Satellite alert: the status of a satellite is set to "Don't Use" due to an integrity risk detected at pseudorange level or an out of range of its fast correction or UDRE figure.
* Ionospheric alert: the status of an IGP is set to "Don't Use" due to an integrity risk detected at pseudorange level or an out of range of its delay estimation or GIVE figure.
Ionospheric alerts are always broadcast in messages of type 26. Satellite alerts can be sent in fast correction messages (types 2 to 5, 24) or in the integrity message (type 6). The IODF for the block in which the satellite is included will be set to 3 whether the message used to send the alert is a fast correction message, but this is not mandatory if message type 6 is used instead.
Every alert condition will be repeated three times after the notification of the alert condition, that is, during an alert situation the message with the alarm information must be sent four times in four seconds, with the same information in all these epochs. Subsequent messages can be broadcast at the normal update rate, as defined in the previous section.

===SBAS L5 Messages===
The proposed L5 MOPS ephemeris message is based on an augmented set of Keplerian orbital elements. Like its predecessor, it remains a 9 degree of freedom parameterization of the orbit and is based on a subset of the GPS ephemeris orbital elements. The message parameters are given below. It consists of a nominal elliptical trajectory described by the six Keplerian elements as well as an additional three correction terms, namely, a correction rate in the inclination IDOT, as well as the so-called harmonic correction terms in the along-track direction Cus and Cuc, which allow us to achieve the necessary orbit representation accuracy. The rate in the inclination allows for cross track correction and the harmonic correction terms, which are a subset of those employed by the GPS ephemeris, allow for along-track correction due to J2 effects. It was determined that over the time scale of this message the dominant 3D position errors observed in using the six Keplerian elements were in the transverse direction, not radial. To mitigate this, we selected parameters which allowed for additional corrections in the along- and cross-track directions.

{|{{Prettytable}}
|+ align="bottom"|'''''Table 8:''''' SBAS L5 Message types.
!style="background-color:#D5D6D2"|Type
!style="background-color:#D5D6D2"|Contents
|-
| 31
|Satellite Mask
|-
| 34,35 and 36
|Integrity message
|-
| 32
|Clock-Ephemeris Corrections and Covariance Matrix
|-
| 39/40
|SBAS Broadcasting Satellites Ephemeris and Covariance Matrix
|-
| 37
|Degradation Parameters and DREI Scale Table
|-
| 47
|SBAS broadcasting Satellite Almanac
|}

====Message Type 31 Satellite Mask====
The Satellite Mask is given in Message Type 31. It consists of 214 Satellite Slot Numbers (including reserved and spare bits), for which the associated Satellite Slot Value indicates whether correction and integrity data can be provided for the corresponding satellite.
The mask will have a maximum of 92 Satellite Slot Values set to 1 within the 214 Satellite Slot Numbers. The mask will be followed by a 2-bit Issue of data Mask (IODM) to indicate the mask’s applicability to the data contained in messages to which the mask applies. The SBAS increases IODM by 1 at each update when the content changes (modulo 4), but not if the content does not change.

====Message Types 34, 35 and 36 Integrity Messages====

=====Message Type 34=====
This message is used to transmit the Integrity information through DFRECIs and DFREIs, for all the Augmented Slot Indices derived from the Satellite Mask.
=====Message Type 35=====
This message is used to transmit the Integrity information through DFREIs up to the 53rd Augmented Slot Index.
=====Message Type 36=====
This message is used to transmit the Integrity information through DFREIs from the 54th Augmented Slot Index derived from the Satellite Mask, up to the 92nd Augmented Slot Index.

====Message Type 32 Clock-Ephemeris corrections and covariance matrix====
This message contains the corrections parameters for a single satellite.

====Message Types 39/40: SBAS satellites ephemeris and covariance matrix====
These messages contain the ephemeris and covariance matrix of the SBAS broadcasting satellite.
The satellite location is transmitted as Keplerian parameters, thus allowing the messages to handle different types of orbits (e.g. IGSO, HEO, MEO, GEO). Due to the size of these parameters, these navigation data and covariance matrix are actually contained, for a given satellite, in two messages (namely MT 39 and MT 40). A service provider may elect to not broadcast the MT 39/40 pair for SBAS satellites for which it does not provide a ranging service.

====Message Type 37: Degradation parameters and DFREI scale table====
This message contains the OBAD parameters and the data which allow a given SBAS System to customize the SigmaDFRE value for each DFRE Indicator.

====Message Type 47: SBAS satellite almanacs====
This message contains the navigation data (as Keplerian parameters) describing the coarse position of two SBAS broadcasting satellites (for any type of orbit).

==File formats for embedding SBAS messages==
For offline analysis and non-SoL/non-real-time applications, familiarization with EGNOS system or general research, the European Space Agency (ESA) has developed the EGNOS Message Server (EMS) file format. EMS is a well-known file format that captures, per GEO satellite and epoch, the Navigation Overlay Frames (NOF) broadcast to single-frequency L1 users. EMS file format is not limited to EGNOS but can contain NOF from any RTCA MOPS DO-229 compliant SBAS.
The format definition of EGNOS legacy service (SF) is available here: [[:File:EMS_UID_2_0.pdf|EMS_UID_2_0.pdf]].

In future major system upgrades (V3.x), EGNOS will also provide information to dual-frequency and multi-constellation (DFMC) users (more specifically, receivers using both L1/E1 and L5/E5a frequencies of GPS and Galileo). To support this evolution, new standards such as the DFMC SBAS MOPS and message formats (such as this Multi-Band EGNOS File Format) have been created to serve a larger user community and benefit from increased processing on user side.
The new Multi-Band EGNOS File Format is backwards compatible with the legacy EMS format and is available here: [[:File:EMS_UID_Multi-band.pdf|EMS_UID_Multi-band.pdf]].

==Summary==
The aim of this article is to provide a summary of what the structure of the signal broadcast by EGNOS is, based on the Appendix A of the RTCA MOPS DO-229-C and the Appendix B of the ICAO SARPs. It goes towards those readers not familiarised with aviation equipment standards, especially with MOPS and SARPs.

It presents the data that are broadcast by EGNOS through the GEO satellites and how this information is distributed in their signals. In addition to the GEO L1 ranging signal (GPS-like), EGNOS broadcasts differential corrections, ionospheric delay estimations for a set of predefined points defined on a grid 350km above the WGS-84 ellipsoid Earth approximation (IGPs), and integrity information to inform about the goodness of the service provided. A model to obtain the tropospheric delays is used instead of any kind of broadcast data due to the local character of the troposphere.

EGNOS does provide all this information through messages (blocks of 250 bits) encoded in the GEO signal. These messages are composed of a preamble, a type identifier, the message body and finally CRC parity information. The maximum update intervals for the data contained in the different messages are predefined and EGNOS Service Provider accounts for them for transmitting all the information in due time.
From a total number of 64 possible message types (8 bits), nowadays there are only 20 defined and some of them are optional (types 27, 28, 62 and 63). Defined messages can be roughly separated in following categories:
:(a) messages related with satellite information (types 1, 2 to 5, 6, 7, 9, 17, 24, 25 and 28), which contain the differential corrections that shall be applied to each satellite to improve the satellite clock and satellite orbit provided by the existing navigation services and the corresponding integrity bounds. Also GEO navigation message is broadcast as no external system provides the GEO ephemeris (type 9),
:(b) messages related with ionospheric information , and (types 18 and 26), which contain the vertical delay estimates for the IGPs (valid for the user to remove the ionosphere contribution from GNSS L1 measurements) and the corresponding integrity bounds.
:(c) other ancillary messages (types 0, 10, 12, 27, 62 and 63), which provide other kinds of useful information, as for instance message type 12, which allows to EGNOS users to compute precisely the UTC time.
:(d) SBAS L5 messages.
[[Category:EGNOS|SBAS]]
[[Category:EGNOS Fundamentals|SBAS]]

GPS Navigation Message

2026-01-28T09:54:03Z

Natalia.Castrillo:

{{Article Infobox2
|Category=Fundamentals
|Authors=J. Sanz Subirana, JM. Juan Zornoza and M. Hernandez-Pajares, University of Catalunia, Spain.
|Level=Basic
|YearOfPublication=2011
|Title={{PAGENAME}}
}}
The GPS monitor stations continuously track each satellite in GPS constellation to estimate its precise orbit and clock errors, then the Master Control Station uses those solutions to generate the GPS navigation messages. These data is uploaded to the GPS satellites through S-band ground antennas during passes and stored onboard. The satellites then rebroadcast the message to users on the L-band navigation signals (L1/L2/L5).

The navigation message provides all the necessary information to allow the user to perform the positioning service. As a minimum, each GPS navigation message includes the ephemeris parameters, needed to compute the satellite coordinates with enough accuracy; the time parameters and satellite clock corrections, to compute satellite clock offsets and time conversions; service parameters such as satellite health flags; ionospheric parameters, used by single frequency receivers; and the almanacs, which allow the computation of the position of "all satellites in the constellation" with a reduced accuracy (1 - 2 km of 1-sigma error) in order to support receiver signal acquisition.

Under nominal conditions, the GPS Control Segment uploads new ephemeris data approximately every two hours, with longer intervals of six hours or more during non-nominal conditions. The almanac changes much more slowly, being updated at least every six days but usually refreshed daily.

Besides the "legacy" L1 C/A navigation message (LNAV), four additional new messages were introduced during the so called GPS modernisation: L2-CNAV, CNAV-2, L5-CNAV and MNAV. The LNAV, L2-CNAV, CNAV-2, L5-CNAV are civil messages, while the MNAV is a military message. In modernised GPS, the same type of contents as the legacy navigation message (NAV) is transmitted but at higher rate and with improved robustness.

The messages L2-CNAV, L5-CNAV and MNAV have a similar structure and data format which allows more flexibility, better control and improved content. The MNAV includes new improvements for the security and robustness of the military message.
The CNAV-2 is modulated onto L1C signal, sharing the same band as the "legacy" LNAV navigation message.

Further information on the different navigation messages can be found in the respective GPS Interface Control Documents (ICD) available at [https://archive.gps.gov/technical/icwg/ GPS Official Website] <ref name="GPS GOV Webpage">[https://archive.gps.gov/ Official U.S. government information about the Global Positioning System (GPS)]</ref>.

== LNAV ==

The current “legacy” Navigation Message (LNAV) is modulated on both L1 C/A and L2 P(Y) carriers at 50 bps. The whole message contains 25 pages (or "frames") of 30 seconds each, forming the master frame that takes 12,5 minutes to be transmitted. Every frame is subdivided into 5 sub-frames of 6 seconds each; in turn, every sub-frame consists of 10 words, with 30 bits per word (see figure 3).
Every sub-frame always starts with the telemetry word (TLM), which is necessary for synchronism. Next, the transference word (HOW) appears. This word provides time information (seconds of the GPS week), allowing the receiver to acquire the week-long P(Y)-code segment.

[[File:Navigation Message.png|none|thumb|450px|alt=navigation message|'''''Figure 1:''''' "Legacy" Navigation message]]

The content of every sub-frame is as follows:
* Sub-frame 1: contains information about the parameters to be applied to satellite clock status for its correction. These values are polynomial coefficients that allow converting time on board to GPS time. It also has information about satellite health condition.
* Sub-frames 2 and 3: these sub-frames contain satellite ephemeris.
* Sub-frame 4: provides ionospheric model parameters (in order to adjust for ionospheric refraction), UTC information (Universal Coordinate Time), part of the almanac, and indications whether the Anti-Spoofing, A/S, is activated or not (which transforms P code into the encrypted Y code).
* Sub-frame 5: contains data from the almanac and the constellation status. It allows to quickly identify the satellite from which the signal comes. A total of 25 frames are needed to complete the almanac.
Sub-frames 1, 2 and 3 are transmitted with each frame (i.e., they are repeated every 30 seconds). Sub-frames 4 and 5 contain different pages (25 pages each) of the navigation message (see figure 1). Thence, the transmission of the full navigation message takes 25 × 30 seconds = 12.5 minutes.
The content of sub-frames 4 and 5 is common for all satellites. Thence, the almanac data for all in orbit satellites can be obtained from a single tracked satellite.

Further information on the LNAV message can be found in IS-GPS-200 ICD document <ref name="GPS ICD 200">[https://archive.gps.gov/technical/icwg/IS-GPS-200N.pdf GPS ICD-200 Revision N, "Navstar GPS Space Segment/Navigation User Segment Interfaces"]</ref>.

== L2-CNAV ==

The initial L2C broadcast consisted of a default message (Message Type 0) that did not provided full navigational data. Initially the plan was to keep the dummy transmission until the new [[GPS Future and Evolutions#New Control Segment|Operational Control Segment (OCX)]] would be operational. However the Air Force decided to anticipate the provision of the L2C navigation message with the aim of helping the development of compatible user equipments as well facilitate the CNAV Operations Concept. The message-populated broadcast started on April 2014 with reduced data accuracy and update frequency compared to the legacy GPS signals in wide use today. From December 2014 is planed that L2-CNAV data updates will increase to a daily rate, bringing L2C signal-in-space accuracy on par with the legacy signals. However, derived position accuracy cannot be guaranteed during the pre-operational deployment of the frequencies and its use must be used only for testing and research activities despite the health bit set “healthy”<ref name=early_cnav_message_populated>[http://gpsworld.com/dod-announces-start-of-civil-navigation-message-broadcasting/ DOD Announces Start of Civil Navigation Message Broadcasting], GPS World, GPS Staff, April 29, 2014</ref>. On December 2014, the CNAV navigation message started to be updated on a daily basis just like the legacy message but must be still considered as pre-operational data and its use must be restricted to testing purposes<ref>[http://gpsworld.com/cnav-messages-now-transmitted-daily/ CNAV Messages Now Transmitted Daily], GPS World, GPS Staff, January 2, 2015</ref>. Operational declarations for L2-CNAV will require implementation of new monitoring and control capabilities in Block 1 of the Next Generation Operational Control System (OCX).

Its design replaces the use of frames and sub-frames of data (repeating in a fixed pattern) of the original “legacy” NAV by a packetised message-based communications protocol, where individual messages can be broadcast in a flexible order with variable repeat cycles as represented in figure 2. Moreover, Forward Error Correction (FEC) and advanced error detection (such as a CRC) are used to achieve better error rates and reduced data collection times.

[[File:L2c.png|none|thumb|450px|alt=L2c|'''''Figure 2:''''' L2-CNAV Navigation message]]

Each message is composed by fixed data such as a Preamble, Message Type ID, Alert Flag, Message TOW count and CRC which lets 238 bits to be filled with other navigation related data. It is possible to define up to 63 different message types, but currently only the messages types 10-14 and 30-37 are defined. The remaining undefined and unused message types are reserved for future use.
Broadcast of messages is completely arbitrary, but sequenced to provide optimum user performance.

Further information on the L2-CNAV message can be found in IS-GPS-200 ICD document <ref name="GPS ICD 200"></ref>.

== L5-CNAV ==

Like L2-CNAV, the L5 message-populated broadcast started on April 2014 but set “unhealthy,” but as greater experience with the L5 broadcast and implementation of signal monitoring is achieved, this status may change upon review<ref name=early_cnav_message_populated/><ref>[http://insidegnss.com/nanu-alerts-gps-users-to-start-of-l2c-l5-cnav-messages/ NANU Alerts GPS Users to Start of L2C/L5 CNAV Messages], Inside GNSS, April 24, 2014</ref>. Operational declarations for L5-CNAV will require implementation of new monitoring and control capabilities in Block 1 of the Next Generation Operational Control System (OCX).

The L5-CNAV is modulated onto L5I signal component, containing basically the same information data as L2-CNAV. The message structure is exactly the same but its content may vary slightly.

[[File:L5c.png|none|thumb|450px|alt=L5c|'''''Figure 3:''''' L5-CNAV Navigation message]]

As in L2-CNAV, it is possible to define up to 63 different message types, but currently only the messages types 10-14 and 30-37 are defined. The remaining undefined and unused message types are reserved for future use.

Further information on L5-CNAV message can be found in IS-GPS-705 ICD document <ref name="GPS ICD 705">[https://archive.gps.gov/technical/icwg/IS-GPS-705J.pdf GPS ICD-705 Revision J, "Navstar GPS Space Segment/User Segment L5 Interfaces"]</ref>.

== CNAV-2 ==

The message CNAV-2 consists of sub-frames and frames and is modulated onto the L1C signal. Each frame is divided into three sub-frames of varying length being required multiple frames to broadcast a complete data message set to users.

* Subframe 1 (9 bits) provides Time of Internal.
* Subframe 2 (600 bits) provides clock and ephemeris data.
* Subframe 3 (274 bits) provides other navigation data which is commutated over multiple pages.

[[File:Cnav-2.png|none|thumb|450px|alt=Cnav-2|'''''Figure 4:''''' CNAV-2 Navigation message]]

Further information on CNAV-2 message can be found in IS-GPS-800 ICD document <ref name="GPS ICD 800">[https://archive.gps.gov/technical/icwg/IS-GPS-800J.pdf GPS ICD-800 Revision J, "Navstar GPS Space Segment/User Segment L1C Interfaces"].</ref>.

==References==
<references/>

[[Category:Fundamentals]]
[[Category:GPS]]
[[Category:GPS Signal Structure]]

GPS Navigation Message

2026-01-28T09:50:08Z

Natalia.Castrillo:

{{Article Infobox2
|Category=Fundamentals
|Authors=J. Sanz Subirana, JM. Juan Zornoza and M. Hernandez-Pajares, University of Catalunia, Spain.
|Level=Basic
|YearOfPublication=2011
|Title={{PAGENAME}}
}}
The GPS monitor stations continuously track each satellite in GPS constellation to estimate its precise orbit and clock errors, then the Master Control Station uses those solutions to generate the GPS navigation messages. These data is uploaded to the GPS satellites through S-band ground antennas during passes and stored onboard. The satellites then rebroadcast the message to users on the L-band navigation signals (L1/L2/L5).

The navigation message provides all the necessary information to allow the user to perform the positioning service. As a minimum, each GPS navigation message includes the ephemeris parameters, needed to compute the satellite coordinates with enough accuracy; the time parameters and satellite clock corrections, to compute satellite clock offsets and time conversions; service parameters such as satellite health flags; ionospheric parameters, used by single frequency receivers; and the almanacs, which allow the computation of the position of "all satellites in the constellation" with a reduced accuracy (1 - 2 km of 1-sigma error) in order to support receiver signal acquisition.

Under nominal conditions, the GPS Control Segment uploads new ephemeris data approximately every two hours, with longer intervals of six hours or more during non-nominal conditions. The almanac changes much more slowly, being updated at least every six days but usually refreshed daily.

Besides the "legacy" L1 C/A navigation message (LNAV), four additional new messages were introduced during the so called GPS modernisation: L2-CNAV, CNAV-2, L5-CNAV and MNAV. The LNAV, L2-CNAV, CNAV-2, L5-CNAV are civil messages, while the MNAV is a military message. In modernised GPS, the same type of contents as the legacy navigation message (NAV) is transmitted but at higher rate and with improved robustness.

The messages L2-CNAV, L5-CNAV and MNAV have a similar structure and data format which allows more flexibility, better control and improved content. The MNAV includes new improvements for the security and robustness of the military message.
The CNAV-2 is modulated onto L1C signal, sharing the same band as the "legacy" LNAV navigation message.

Further information on the different navigation messages can be found in the respective GPS Interface Control Documents (ICD) available at [https://archive.gps.gov/technical/icwg/ GPS Official Website]<ref name="GPS GOV Webpage">[https://archive.gps.gov/]</ref>.

== LNAV ==

The current “legacy” Navigation Message (LNAV) is modulated on both L1 C/A and L2 P(Y) carriers at 50 bps. The whole message contains 25 pages (or "frames") of 30 seconds each, forming the master frame that takes 12,5 minutes to be transmitted. Every frame is subdivided into 5 sub-frames of 6 seconds each; in turn, every sub-frame consists of 10 words, with 30 bits per word (see figure 3).
Every sub-frame always starts with the telemetry word (TLM), which is necessary for synchronism. Next, the transference word (HOW) appears. This word provides time information (seconds of the GPS week), allowing the receiver to acquire the week-long P(Y)-code segment.

[[File:Navigation Message.png|none|thumb|450px|alt=navigation message|'''''Figure 1:''''' "Legacy" Navigation message]]

The content of every sub-frame is as follows:
* Sub-frame 1: contains information about the parameters to be applied to satellite clock status for its correction. These values are polynomial coefficients that allow converting time on board to GPS time. It also has information about satellite health condition.
* Sub-frames 2 and 3: these sub-frames contain satellite ephemeris.
* Sub-frame 4: provides ionospheric model parameters (in order to adjust for ionospheric refraction), UTC information (Universal Coordinate Time), part of the almanac, and indications whether the Anti-Spoofing, A/S, is activated or not (which transforms P code into the encrypted Y code).
* Sub-frame 5: contains data from the almanac and the constellation status. It allows to quickly identify the satellite from which the signal comes. A total of 25 frames are needed to complete the almanac.
Sub-frames 1, 2 and 3 are transmitted with each frame (i.e., they are repeated every 30 seconds). Sub-frames 4 and 5 contain different pages (25 pages each) of the navigation message (see figure 1). Thence, the transmission of the full navigation message takes 25 × 30 seconds = 12.5 minutes.
The content of sub-frames 4 and 5 is common for all satellites. Thence, the almanac data for all in orbit satellites can be obtained from a single tracked satellite.

Further information on the LNAV message can be found in IS-GPS-200 ICD document <ref name="GPS ICD 200">[https://archive.gps.gov/technical/icwg/IS-GPS-200N.pdf GPS ICD-200 Revision N, "Navstar GPS Space Segment/Navigation User Segment Interfaces"]</ref>.

== L2-CNAV ==

The initial L2C broadcast consisted of a default message (Message Type 0) that did not provided full navigational data. Initially the plan was to keep the dummy transmission until the new [[GPS Future and Evolutions#New Control Segment|Operational Control Segment (OCX)]] would be operational. However the Air Force decided to anticipate the provision of the L2C navigation message with the aim of helping the development of compatible user equipments as well facilitate the CNAV Operations Concept. The message-populated broadcast started on April 2014 with reduced data accuracy and update frequency compared to the legacy GPS signals in wide use today. From December 2014 is planed that L2-CNAV data updates will increase to a daily rate, bringing L2C signal-in-space accuracy on par with the legacy signals. However, derived position accuracy cannot be guaranteed during the pre-operational deployment of the frequencies and its use must be used only for testing and research activities despite the health bit set “healthy”<ref name=early_cnav_message_populated>[http://gpsworld.com/dod-announces-start-of-civil-navigation-message-broadcasting/ DOD Announces Start of Civil Navigation Message Broadcasting], GPS World, GPS Staff, April 29, 2014</ref>. On December 2014, the CNAV navigation message started to be updated on a daily basis just like the legacy message but must be still considered as pre-operational data and its use must be restricted to testing purposes<ref>[http://gpsworld.com/cnav-messages-now-transmitted-daily/ CNAV Messages Now Transmitted Daily], GPS World, GPS Staff, January 2, 2015</ref>. Operational declarations for L2-CNAV will require implementation of new monitoring and control capabilities in Block 1 of the Next Generation Operational Control System (OCX).

Its design replaces the use of frames and sub-frames of data (repeating in a fixed pattern) of the original “legacy” NAV by a packetised message-based communications protocol, where individual messages can be broadcast in a flexible order with variable repeat cycles as represented in figure 2. Moreover, Forward Error Correction (FEC) and advanced error detection (such as a CRC) are used to achieve better error rates and reduced data collection times.

[[File:L2c.png|none|thumb|450px|alt=L2c|'''''Figure 2:''''' L2-CNAV Navigation message]]

Each message is composed by fixed data such as a Preamble, Message Type ID, Alert Flag, Message TOW count and CRC which lets 238 bits to be filled with other navigation related data. It is possible to define up to 63 different message types, but currently only the messages types 10-14 and 30-37 are defined. The remaining undefined and unused message types are reserved for future use.
Broadcast of messages is completely arbitrary, but sequenced to provide optimum user performance.

Further information on the L2-CNAV message can be found in IS-GPS-200 ICD document <ref name="GPS ICD 200"></ref>.

== L5-CNAV ==

Like L2-CNAV, the L5 message-populated broadcast started on April 2014 but set “unhealthy,” but as greater experience with the L5 broadcast and implementation of signal monitoring is achieved, this status may change upon review<ref name=early_cnav_message_populated/><ref>[http://insidegnss.com/nanu-alerts-gps-users-to-start-of-l2c-l5-cnav-messages/ NANU Alerts GPS Users to Start of L2C/L5 CNAV Messages], Inside GNSS, April 24, 2014</ref>. Operational declarations for L5-CNAV will require implementation of new monitoring and control capabilities in Block 1 of the Next Generation Operational Control System (OCX).

The L5-CNAV is modulated onto L5I signal component, containing basically the same information data as L2-CNAV. The message structure is exactly the same but its content may vary slightly.

[[File:L5c.png|none|thumb|450px|alt=L5c|'''''Figure 3:''''' L5-CNAV Navigation message]]

As in L2-CNAV, it is possible to define up to 63 different message types, but currently only the messages types 10-14 and 30-37 are defined. The remaining undefined and unused message types are reserved for future use.

Further information on L5-CNAV message can be found in IS-GPS-705 ICD document <ref name="GPS ICD 705">[https://archive.gps.gov/technical/icwg/IS-GPS-705J.pdf GPS ICD-705 Revision J, "Navstar GPS Space Segment/User Segment L5 Interfaces"]</ref>.

== CNAV-2 ==

The message CNAV-2 consists of sub-frames and frames and is modulated onto the L1C signal. Each frame is divided into three sub-frames of varying length being required multiple frames to broadcast a complete data message set to users.

* Subframe 1 (9 bits) provides Time of Internal.
* Subframe 2 (600 bits) provides clock and ephemeris data.
* Subframe 3 (274 bits) provides other navigation data which is commutated over multiple pages.

[[File:Cnav-2.png|none|thumb|450px|alt=Cnav-2|'''''Figure 4:''''' CNAV-2 Navigation message]]

Further information on CNAV-2 message can be found in IS-GPS-800 ICD document <ref name="GPS ICD 800">[https://archive.gps.gov/technical/icwg/IS-GPS-800J.pdf GPS ICD-800 Revision J, "Navstar GPS Space Segment/User Segment L1C Interfaces"].</ref>.

==References==
<references/>

[[Category:Fundamentals]]
[[Category:GPS]]
[[Category:GPS Signal Structure]]

BeiDou Signal Plan

2025-08-26T07:46:11Z

Natalia.Castrillo:

{{Article Infobox2
|Category=Fundamentals
|Authors=J.A Ávila Rodríguez, University FAF Munich, Germany.
|Level=Advanced
|YearOfPublication=2011
|Title={{PAGENAME}}
}}
Presently, the in-orbit operational BDS satellites providing open services include 5 GEO satellites, 7 IGSO satellites and 21 MEO satellites, which can be further divided as 15 BDS-2 satellites ( 5 BDS-2G, 7 BDS-2I, 3 BDS-2M) and 18 BDS-3 satellites (BDS-3M). In addition to B1I and B2I signals, the B1C and B2a ones have started broadcasting by the BDS-3M satellites<ref name="BeiDou Navigation Satellite System Open Service Performance Standard ">[http://en.beidou.gov.cn/SYSTEMS/Officialdocument/201812/P020181227424526837905.pdf] BeiDou Navigation Satellite System Open Service Performance Standard（Version 2.0)</ref>.

== BeiDou B1I Band ==
The B1I signal is composed of the carrier frequency, ranging code and navigation message. The ranging code and navigation message are modulated on carrier. The B1I signal is expressed as follows<ref name="B1I">[http://en.beidou.gov.cn/SYSTEMS/Officialdocument/201902/P020190227601370045731.pdf]BeiDou Navigation Satellite System Signal In Space Interface Control Document Open Service Signal B1I (Version 3.0) </ref>:

SjB1I (t) = AB1ICjB1I(t)DjB1I(t)cos(2πf1t + ѰjB1I)

Where: 
• Superscript j: satellite number. 
• AB1I : amplitude of B1I. 
• CB1I : ranging code of B1I. 
• DB1I : data modulated on ranging code of B1I. 
• f1 : carrier initial phase of B1I. 
• ѰB1I : carrier initial phase of B1I. 

To conclude some technical characteristics of the BeiDou B1 signals are given next:

{| class="wikitable" style="text-align: left; width: 600px; height: 200px;"
|+ Beidou B1I signal characteristics <ref>[http://en.beidou.gov.cn/SYSTEMS/Officialdocument/201902/P020190227601370045731.pdf] Beidou B1I signal characteristics</ref>
|-
! Technical KPI
! High Level Description
|-
| Carrier Frequency || 1561.098 MHz
|-
| Modulation Mode || Binary Phase Shift Keying (BPSK)
|-
| Polarization Mode || Right-Hand Circularly Polarized (RHCP)
|-
| Carrier Phase Noise || Third-order phase locked loop with 10 Hz one-sided noise bandwidth
|-
| Received Power Levels on Ground || -163 dBW (measured at the output of a 0 dBi RHCP user receiving antenna when the satellites are above a 5-degree elevation angle)
|-
| Signal Multiplexing Mode || Code Division Multiple Access (CDMA)
|-
| Signal Bandwidth || 4.092 MHz (centered at the carrier frequency)
|-
| Spurious || Shall not exceed -50dBc
|-
| rowspan="2" |Signal Coherence || The random jitters of the ranging code phase differentials between B1I, B2I and B3I shall be less than 1ns (1σ).
|-
| The random jitter of the initial phase differential between the ranging code and the corresponding carrier shall be less than 3° (1σ).
|-
| Equipment Group Delay Differential || TGD1 (less than 1ns)
|}

== BeiDou B1C Band ==
This section defines the characteristics of the open service signal B1C transmitted by the Medium Earth Orbit (MEO) satellites and the Inclined GeoSynchronous Orbit (IGSO) satellites of BDS-3 for providing open service, and shall not be transmitted by the Geostationary Earth Orbit (GEO) satellites.
The signal characteristics described in this chapter pertain to the B1C signal contained within the 32.736 MHz bandwidth with a center frequency of 1575.42MHz.
The carrier frequencies, modulations and symbol rates of the B1C signal are shown in the following table.<ref>[http://en.beidou.gov.cn/SYSTEMS/Officialdocument/201806/P020180608525871869457.pdf] BeiDou Navigation Satellite System Signal In Space Interface Control Document Open Service Signal B1C (Version 1.0) </ref>

{| class="wikitable" style="text-align: left; width: 600px; height: 200px;"
|+ Beidou B1C components: frequencies and modulations
|-
! Signal
! Signal component
! Carrier frequency (MHz)
!Modulation
!Symbol rate (sps)
|-
| rowspan="2" | B1C
| Data component B1C_data
| rowspan="2" | 1575.42
| BOC(1,1)
| 100
|-
| Pilot component B1C_pilot
| QMBOC(6, 1, 4/33)
| 0
|}
The complex envelope of the B1C signal is expressed as: 
SB1C(t) = SB1C_data(t)+jS SB1C_pilot (t) 
Where the SB1C_data(t) is the data component, which is generated from the navigation message data DSB1C_data(t) and the ranging code CSB1C_data(t) modulated with the sine-phase BOC(1,1) subcarrier scSB1C_data(t). SB1C_pilot(t) is generated from the ranging code CB1C_pilot(t), modulated with the QMBOC(6,1,4/33) subcarrier scB1C_pilot(t). The power ratio of the data component to the pilot component is 1:3. 
In the next table appear phase relationship, as well as the power ratio of each component.
{| class="wikitable" style="text-align: left; width: 600px; height: 200px;"
|+ Beidou B1C phase relationship and power ratio per component
|-
! Component
! colspan="2" | Modulation
! Phase relationship
! Power ratio
|-
| SB1C_data(t)
| colspan="2" | Sine BOC(1,1)
| 0
| 1/4
|-
| SB1C_pilot_a (t)
| rowspan="2" | QMBOC (6,1,4/33)
| Sine BOC(1,1)
| 90
| 29/44
|-
| SB1C_pilot_b (t)
| Sine BOC(6,1)
| 0
| 1/11
|}
To conclude some technical characteristics of the BeiDou B1C signals are given bellow: 
{| class="wikitable" style="text-align: left; width: 600px; height: 200px;"
|+ Beidou B1C signal characteristics
|-
! Technical KPI
! High Level Description
|-
| Carrier Frequency || 1575.42 MHz
|-
| Modulation Mode || BOC/QMBOC
|-
| Polarization Mode || Right-Hand Circularly Polarized (RHCP)
|-
| Carrier Phase Noise || Third-order phase locked loop with 10 Hz one-sided noise bandwidth
|-
| Received Power Levels on Ground || -159 dBW for MEO and -161 dBW for IGSO satellites
|-
| Signal Multiplexing Mode || Code Division Multiple Access (CDMA)
|-
| Signal Bandwidth || 32.736 MHz (centered at the carrier frequency)
|-
| Spurious || Shall not exceed -50dBc
|-
| Signal Coherence || The time difference between the ranging code phases of all signal components <= 10 ns.
|-
| Correlation Loss || The correlation loss due to payload distortions <= 0.3 dB
|-
| rowspan="2" |Data/Code Coherence
| The edge of each data symbol is aligned with the edge of the corresponding ranging code chip. The start of the first chip of the periodic ranging codes is aligned with the start of a data symbol.
|-
| The edge of each secondary chip is aligned with the edge of a primary code chip. The start of the first chip of the primary codes is aligned with the start of a secondary code chip.
|}

== BeiDou B2a Band ==
The signal characteristics described in this point correspond to the B2a signal contained within the 20,46 MHz bandwidth with a center frequency of 1176,45 MHz. The following table shows the carrier frequencies, modulations and symbol rates of the B2a signal <ref>[http://en.beidou.gov.cn/SYSTEMS/Officialdocument/201806/P020180608525870555377.pdf] BeiDou Navigation Satellite System Signal In Space Interface Control Document Open Service Signal B2a (Version 1.0). </ref>.

{| class="wikitable" style="text-align: left; width: 600px; height: 200px;"
|+ Beidou B2a components: frequencies and modulations
|-
! Signal
! Signal component
! Carrier frequency (MHz)
!Modulation
!Symbol rate (sps)
|-
| rowspan="2" | B2a
| Data component B2a_data
| rowspan="2" | 1176.45
| rowspan="2" | BPSK(10)
| 200
|-
| Pilot component B2a_pilot
| 0
|}
Taking into account both aforementioned signal components, the complex envelope of the B2a signal is:
SB2a (t) = SB2a_data(t)+jS SB2a_pilot (t)
Where, the data component is generated from the navigation message data (DB2a_data(t)) modulated with the ranging code CB2a_data(t), while the pilot component contains the ranging code CB2a_Pilot(t) only. They both adopt BPSK(10) modulation. The power ratio of the data component to the pilot component is 1:1. 
In the next table appear phase relationship, as well as the power ratio of each component.
{| class="wikitable" style="text-align: centre; width: 600px; height: 200px;"
|+ Beidou B2a phase relationship and power ratio per component
|-
! Component
! Modulation
! Phase relationship
! Power ratio
|-
| SB2a_data(t)
| rowspan="2" | BPSK(10)
| 0
| rowspan="2" | 1/2
|-
| SB2a_pilot (t)
| 90
|}

To conclude, some technical characteristics on the BeiDou B2a signals are presented more in detail in the next table:
{| class="wikitable" style="text-align: left; width: 600px; height: 200px;"
|+ Beidou B2a signal characteristics
|-
! Technical KPI
! High Level Description
|-
| Carrier Frequency || 1176.45 MHz
|-
| Modulation Mode || Binary Phase Shift Keying (BPSK)
|-
| Polarization Mode || Right-Hand Circularly Polarized (RHCP)
|-
| Carrier Phase Noise || Third-order phase locked loop with 10 Hz one-sided noise bandwidth
|-
| Received Power Levels on Ground || -163 dBW (measured at the output of a 0 dBi RHCP user receiving antenna when the satellites are above a 5-degree elevation angle)
|-
| Signal Multiplexing Mode || Code Division Multiple Access (CDMA)
|-
| Signal Bandwidth || 20.46 MHz (centered at the carrier frequency)
|-
| Spurious || Shall not exceed -50dBc
|-
| Signal Coherence || The time difference between the ranging code phases of all signal components <= 10 ns.
|-
|-
| rowspan="2" |Data/Code Coherence
| The edge of each data symbol is aligned with the edge of the corresponding ranging code chip. The start of the first chip of the periodic ranging codes is aligned with the start of a data symbol.
|-
| The edge of each secondary chip is aligned with the edge of a primary code chip. The start of the first chip of the primary codes is aligned with the start of a secondary code chip.
|}

== BeiDou B3 Band ==
Finally, this section of the document defines the characteristics of the open service signal B3I, transmitted by the BDS-2 and BDS-3 satellites including MEO, IGSO and GEO satellites for providing open service.

The B3I signal is composed of the carrier frequency, ranging code and navigation message. The ranging code and navigation message are modulated on carrier. The B3I signal is expressed as follows <ref> [http://en.beidou.gov.cn/SYSTEMS/Officialdocument/201806/P020180608525869304359.pdf] BeiDou Navigation Satellite System Signal In Space Interface Control Document Open Service Signal B3I (Version 1.0) </ref>:

SjB3I (t) = AB3ICjB3I(t)DjB3I(t)cos(2πf3t + ѰjB3I)
Where: 
• Superscript j: satellite number 
• AB3I : amplitude of B3I 
• CB3I : ranging code of B3I 
• DB3I : data modulated on ranging code of B3I 
• f3 : carrier initial frequency of B3I 
• ѰB3I : carrier initial phase of B3I 

To conclude, some technical characteristics on the BeiDou B3 signals are provided next.

{| class="wikitable" style="text-align: left; width: 600px; height: 200px;"
|+ Beidou B3I signal characteristics
|-
! Technical KPI
! High Level Description
|-
| Carrier Frequency || 1268.520 MHz
|-
| Modulation Mode || Binary Phase Shift Keying (BPSK)
|-
| Polarization Mode || Right-Hand Circularly Polarized (RHCP)
|-
| Carrier Phase Noise || Third-order phase locked loop with 10 Hz one-sided noise bandwidth
|-
| Received Power Levels on Ground || -163 dBW (measured at the output of a 0 dBi RHCP user receiving antenna when the satellites are above a 5-degree elevation angle)
|-
| Signal Multiplexing Mode || Code Division Multiple Access (CDMA)
|-
| Signal Bandwidth || 20.46 MHz (centered at the carrier frequency)
|-
| Spurious || Shall not exceed -50dBc
|-
| rowspan="2" |Signal Coherence || The random jitters of the ranging code phase differentials between B1I, B2I and B3I shall be less than 1ns (1σ).
|-
| The random jitter of the initial phase differential between the ranging code and the corresponding carrier shall be less than 3° (1σ).
|-
| Equipment Group Delay Differential || Tref (less than 0.5ns)
|}

==References==
<references/>

== Credits ==

[[Category:Fundamentals]]
[[Category:GNSS Signals]]
[[Category:BEIDOU]]

Galileo Navigation Message

2025-08-26T07:41:11Z

Natalia.Castrillo:

{{Article Infobox2
|Category=Fundamentals
|Authors=J. Sanz Subirana, JM. Juan Zornoza and M. Hernandez-Pajares, University of Catalunia, Spain.
|Level=Basic
|YearOfPublication=2011
|Title={{PAGENAME}}
}}
The Galileo satellites broadcast different types of data in four navigation messages: the F/NAV navigation, the I/NAV navigation message, the Commercial Navigation Message (C/NAV) and the Governmental Navigation Message (G/NAV).

The G/NAV navigation message does not belong to the public domain and the C/NAV is not yet defined. Please note that the formerly Commercial Service is now known as High Accuracy Service.

The details of the Galileo Signal Status are provided in the Galileo OS SIS Interface Control Document (ICD). <ref name = "GAL SIS ICD">[https://www.gsc-europa.eu/sites/default/files/sites/all/files/Galileo_OS_SIS_ICD_v2.0.pdf Galileo OS SIS ICD]</ref> No other ICD documents have been published to date.

== General Structure and Contents ==
The Galileo Signal-In-Space data channels transmit different messages type according to the general contents identified in the following table. The F/NAV types of message correspond to the OS and the I/NAV types of messages correspond to both OS and CS (current High Accuracy Service). The following table indicates the signal component associated to each navigation message type. Let us also note that the Return Link Message from Galileo SAR service is provided as part of I/NAV data.

[[File:Message_types.png |none|thumb|400px| Source: Galileo OS SIS ICD <ref name = "GAL SIS ICD">[https://www.gsc-europa.eu/sites/default/files/sites/all/files/Galileo_OS_SIS_ICD_v2.0.pdf Galileo OS SIS ICD]</ref> ]]

The complete navigation message data are transmitted on each data component as a sequence of frames. A frame is composed of several sub-frames, and each sub-frame is composed of several pages. The page is the basic structure for building the navigation message.

All data values encoded using the following bit and byte ordering criteria:
* For numbering, the most significant bit/byte is numbered as bit/byte 0.
* For bit/byte ordering, the most significant bit/byte is transmitted first.

According with the current published ICD <ref name = "GAL SIS ICD">[https://www.gsc-europa.eu/sites/default/files/sites/all/files/Galileo_OS_SIS_ICD_v2.0.pdf Galileo OS SIS ICD]</ref> both F/NAV and I/NAV navigation messages are called super-frame and broadcast as a sequence of frames that are composed of several sub-frames which in turn is composed by several pages.

[[File:Galileo_Navigation_Message_Structure.png |none|thumb|400px]]

The general structure of the navigation messages are common but the number of sub-frames and pages as well as the duration of each page are not the same, as represented in the following table.

{| class="wikitable"
|-
!|Message||Channel||Data rate (bps)||Page Duration (s)||Pages in a sub-frame||Sub-frames in a frame
|-
| align="center" | F/NAV
| align="center" | E5a-I
| align="center" | 25
| align="center" | 10
| align="center" | 5
| align="center" | 12
|-
| align="center" | I/NAV
| align="center" | E1B, E5b-I
| align="center" | 125
| align="center" | 2
| align="center" | 15
| align="center" | 24
|}

This arrangement allows accomplishing the three different main categories of data to be transmitted at different rates:
* Fast rate (for urgent data, such as integrity): page.
* Medium rate (Ephemeris, Clock Correction): sub-frame.
* Slow rates (Almanacs): frame.
The page starts with a Synchronisation Word (SW) followed by the interleaving FEC (Forward Error Correction) coded navigation data and ends with tail bits for the FEC decoding. In addition both navigation messages transmit a CRC data field in order to detect corrupted data. The size of this field is different in each navigation message.
Three levels of error coding are applied to the Galileo Message Data Stream:
# A Cyclic Redundancy Check (CRC) with error detection capabilities after recovery of the received data;
# A one-half rate Forward Error Correction (FEC). Tail Bits (sequence of zeros) to allow Viterbi decoding;
# Block Interleaving on the resulting frames: provides robustness to the FEC decoding algorithm since in presence of a burst of erroneous bits it is converted into small errors in several pages. This scheme allows reducing the bit error ratio in the increased data rates.

As referred, the FEC coded symbols are transmitted interleaved within the page and because of that the navigation data can only be decoded when the complete interleaving FEC coded part is received.

The following table summarizes the parameters transmitted by FNAV and INAV messages.

[[File:Params.png|none|thumb|400px]]

As can be seen in the table above, the parameters transmitted in F/NAV and I/NAV have the same size except for signal and message specific parameters, such as "Issue of Data (IOD)" and "Navigation Data Validity and Signal Health Status". In the case of "Satellite Almanac" set, the size is also different because the set includes the "Satellite signal health status".
The Galileo ephemeris parameters are [[GPS and Galileo Satellite Coordinates Computation|Keplerian-like orbital elements as in GPS]]. The nominal period update is 3 hours, being valid for a 4 hours time interval. The 1-hour overlap interval is intended to help against short outages or delays. The Galileo Almanac is also similar to the GPS and GLONASS ones.

== F/NAV Structure ==
The F/NAV navigation message is transmitted on channel E5a-I at a rate of 25 bps. The F/NAV message structure is shown in the following figure, where the duration of each entity is indicated.

[[File:FNAV.png |none|thumb|400px]]

Each frame of the F/NAV message has a duration of 600 seconds and it is composed by 12 sub-frames. In turn, each sub-frame has a duration of 50 seconds and it is composed by 5 pages with a duration of 10 seconds. The page itself comprises 3 main fields:
* Synchronisation pattern: it is no encoded and it has a length of 12 bits and is always 101101110000 being its purpose to allow the receiver to achieve synchronisation to the page boundary; it allows the receiver to achieve synchronization to the page boundary.
* F/NAV word: has a length of 238 bits and it is the interleaved and FEC encoded part of the page that encodes the fields: Page Type (6 bits) enabling the page content identification;, Navigation Data (208 bits) and CRC (24 bits) to detect potential bit errors. The CRC is computed on the Page Type and Navigation Data fields.
* Tail: has a length of 6 bits and consists of 6 zero-values that are used to enable the completion of the FEC decoding of each page.

[[File:Fnav.png | F/NAV Navigation message structure|none|thumb|400px]]

The Page Type field identifies the broadcast page which allows the user-receivers to react accordingly and grants the possibility of changing the pages sequencing, while keeping backward compatibility. The CRC is used as the most inner mechanism of errors detection because it is computed only on the Page Type and Navigation Data fields.

Please refer to the Galileo OS SIS ICD<ref name = "GAL SIS ICD">[https://www.gsc-europa.eu/sites/default/files/sites/all/files/Galileo_OS_SIS_ICD_v2.0.pdf Galileo OS SIS ICD]</ref> for detailed analysis on the F/NAV Frame layout and page contents.

== I/NAV Structure ==

The I/NAV navigation message is transmitted on both E1B and E5b-I channels at a rate of 125 bps. The two versions of the I/NAV message are disseminated through the same structure being its content also the same but not aligned over the time.

[[File:INAV.png |none|thumb|400px]]

The I/NAV message structures for the E1B and E5b-I signals use the same page layout since the service provided on these frequencies is a dual frequency service, using frequency diversity. Only page sequencing is different, with page swapping between both components in order to allow a fast reception of the data by a dual frequency receiver. However, the frame is designed to allow receivers to work also with a single frequency.

Each frame of the I/NAV message has a duration of 720 seconds and it is composed by 24 sub-frames. In turn, each sub-frame has a duration of 30 seconds and it is composed by 15 pages with a duration of 2 seconds. The page itself is composed by 3 fields:
* Synchronisation pattern: has a length of 10 bits and is always 0101100000 being its purpose to allow the receiver to achieve synchronisation to the page boundary;
* I/NAV page part: has a length of 114 bits and it is the interleaved FEC encoded part of the page where the navigation data is conveyed.
* Tail: has a length of 6 bits and consists of 6 zero-value bits that are used to enable the completion of the FEC decoding of each page part.

The page part of the message can be even or odd and both parts are always broadcast one after the other. In channel E1B the even part is transmitted first while in channel E5b-I the even part is transmitted after. The combination of two page parts constitutes a valid set of data (Nominal Page) that has to be parsed together to get the Navigation Data. The advantage of this configuration is that a receiver decoding the I/NAV on both frequencies can decode the same pages in half the time of a single frequency receiver.

[[File:Inav.png | INAV Navigation message structure |none|thumb|400px]]

Two types of I/NAV pages are defined:
* Nominal pages: having a duration of 2 seconds transmitted sequentially in time in two parts of duration 1 second each on each of the E1B and E5b-I components. The first part of the page is denoted ‘even’ and the second one is denoted ‘odd’.
* Alert pages: having a duration of 1 second transmitted in two parts of duration 1 second each at the same epoch over the E1B and E5b-I components. Again, the first part of the page is denoted ‘even’ and the second one is denoted ‘odd’. This transmission is repeated at the next epoch but switching the two parts between the components.

Please refer to the Galileo OS SIS ICD <ref name = "GAL SIS ICD">[https://www.gsc-europa.eu/sites/default/files/sites/all/files/Galileo_OS_SIS_ICD_v2.0.pdf Galileo OS SIS ICD]</ref> for detailed analysis on the I/NAV Frame layout and page contents. Let us remark that the [[Galileo Search and Rescue Service|Galileo Search and Rescue (SAR)]] Return Link Message (RLM) is transmitted only in the E1-B component. The SAR field structure for the E1-B component in nominal mode is formatted according to the values stated in the Galileo SIS ICD<ref name = "GAL SIS ICD">[https://www.gsc-europa.eu/sites/default/files/sites/all/files/Galileo_OS_SIS_ICD_v2.0.pdf Galileo OS SIS ICD]</ref> and the Galileo SAR Service Definition Document<ref name="SAR SDD">[https://www.gsc-europa.eu/sites/default/files/sites/all/files/Galileo-SAR-SDD.pdf Galileo SAR Service Definition Document]</ref>.

[[Galileo Open Service Navigation Message Authentication | Galileo OS-NMA]] capability will be added in the Reserved 1 40 bits in E1 I/NAV message.

The Galileo OS ICD released in January 2021 <ref name = "GAL SIS ICD"/> introduces new features in parts of I/NAV message transmitted on the Galileo E1-B signal component which were previously marked as spare or reserved. This means that these improvements will provide full backwards compatibility. The new features are:
* Reduced Clock and Ephemeris Data (RedCED);
* Reed-Solomon Outer Forward Error Correction Data (FEC2);
* Secondary Synchronization Pattern (SSP).

As a result of these technical solutions, users will experience an improvement of the Galileo E1 Open Service performance in terms of Robustness and Timeliness; a significant Time To First Fix Improvement in challenging environments addressing both unassisted and assisted GNSS; backward compatibility guaranteed (no impact on legacy or non-participative receivers) and low complexity implementation within OS receivers.

The Galileo system is set to begin transmitting these new I/NAV capabilities by 2023. <ref>[https://www.gsc-europa.eu/sites/default/files/sites/all/files/Galileo_OS_SIS_ICD_v2.0.pdf Galileo Open Service Signal-in-Space Interface Control Document, v2.0]</ref>

==Notes==
<references group="footnotes"/>
The information from this article has been updated by GMV based on the applicable Galileo OS Signal-In-Space Interface Control Document (ICD).

==References==
<references/>
* Hofmann-Wellenhof, B., Lichtenegger, H., K. and Wasle, E., 2008. GNSS - Global Navigation Satellite Systems. Springer-Verlag, Wien, Austria.
* Powe, M., 2006. Introduction to Galileo. powerpoint presentation, progeny.

[[Category:Fundamentals]]
[[Category:GALILEO]]

Solid Tides

2025-08-20T07:45:32Z

Natalia.Castrillo:

{{Article Infobox2
|Category=Fundamentals
|Authors=J. Sanz Subirana, J.M. Juan Zornoza and M. Hernández-Pajares, Technical University of Catalonia, Spain.
|Level=Advanced
|YearOfPublication=2011
|Title={{PAGENAME}}
}}
Earth solid tides comprise the Earth's crust movement (and thus the receiver location coordinates variation) due to gravitational attracting forces produced by external bodies, mainly the sun and the moon. The Solid Tides produce vertical and horizontal displacements that can be expressed by spherical harmonics expansion (<math>\displaystyle m</math>,<math>\displaystyle n</math>), characterised by the Love and Shida numbers <math>\displaystyle h_{mn}</math>, <math>\displaystyle l_{mn}</math>.

An accurate modeling of Earth solid tides is essential for ensuring that GNSS-derived positions are reliable, especially for scientific and engineering applications.

==IERS solid Earth tide model==

A simplified model for the tide displacement, but with few millimeters of accuracy, is given by the following expression (from IERS Conventions degree 2 tides displacement model --in-phase corrections--, see [Denis et al., 2004] <ref> [Denis et al., 2004] Denis, D., McCarthy and Petit, G., 2004. IERS Conventions (2003). IERS Technical Note 32. IERS Convention Center, Frankfurt am Main.</ref>, page 79):

:<math>
\Delta {\mathbf r}= \sum_{j=2}^{3}{\frac{G\,M_j\,R_e^4}{G\,M_\oplus\,R_j^3}} \left \{h_2 \,\hat{\mathbf r} \left ( \frac{3}{2} (\hat{\mathbf R}_j \cdot \hat{\mathbf r})^2 -\frac{1}{2}\right) + 3\,l_2\,(\hat{\mathbf R}_j \cdot \hat{\mathbf r}) \left [\hat{\mathbf R}_j-(\hat{\mathbf R}_j \cdot \hat{\mathbf r})\,\hat{\mathbf r} \right ]\right \} \qquad\mbox{(1)}</math>

:::<math>\Delta {\mathbf r}</math> is a site displacement vector in a Cartesian coordinates system.
:::<math>G\,M_\oplus</math> is gravitational parameters of the earth.
:::<math>G\,M_j</math> is gravitational parameters of the moon (<math>j = 2</math>) and sun (<math>j = 3</math>).
::::::(<math>M_{sun}/M_\oplus=332946.0</math>, <math>M_{moon}/M_\oplus=0.01230002</math>)
:::<math>\hat{\mathbf R}_j</math>, <math>\displaystyle R_j</math> are the unit vector from the geocentre to moon or sun and the magnitude of that vector.
:::<math>\displaystyle R_e</math> is the earth's equatorial radius (<math>R_e=6378136.6\,m</math>).
:::<math>\hat{\mathbf r}</math>, <math>\displaystyle r</math> are the unit vector from the geocentre to the station and the magnitude of that vector.
:::<math>\displaystyle h_2</math> is the nominal degree 2 Love number (<math>\displaystyle h_2=0.6078</math>).
:::<math>\displaystyle l_2</math> is the nominal degree 2 Shida number (<math>\displaystyle l_2=0.0847</math>).

Notice that the radial (not vertical) component (<math>\displaystyle \hat{\mathbf r}</math>) is proportional to the Love number <math>\displaystyle h_2</math>, while the terms in <math>\displaystyle l_2</math> corresponds to components orthogonal to the radial direction (not the horizontal plane).

A small correction of latitude (<math>\varphi</math>) dependence can be considered in the <math>\displaystyle h_2</math> and <math>\displaystyle l_2</math> values of previous equation (1) according to the expression:

::<math>
\begin{array}{rl}
h_2&= 0.6078-0.0006\left [(3 \sin^2\varphi-1)/2\right]\\[0.3cm]
l_2&= 0.0847+0.0002\left [(3 \sin^2\varphi-1)/2\right]
\end{array} \qquad\mbox{(2)}</math>

An additional refinement can be to take into account the additional contribution due to the degree 3 tides [Denis et al., 2004], page 80):

<math>
\Delta {\mathbf r}= \sum_{j=2}^{3}{\frac{G\,M_j\,R_e^5}{G\,M_\oplus\,R_j^4}} \left \{h_3 \,\hat{\mathbf r} \left ( \frac{5}{2} (\hat{\mathbf R}_j \cdot \hat{\mathbf r})^3 -\frac{3}{2} (\hat{\mathbf R}_j \cdot \hat{\mathbf r})\right) + l_3\,\left (\frac{15}{2} (\hat{\mathbf R}_j \cdot \hat{\mathbf r})^2 - \frac{3}{2} \right ) \left [\hat{\mathbf R}_j-(\hat{\mathbf R}_j \cdot \hat{\mathbf r})\,\hat{\mathbf r} \right ]\right \} \qquad\mbox{(3)}</math>

where <math>\displaystyle h_3=0.292</math> and <math>\displaystyle l_3=0.015</math>. Only the moon's contribution (<math>j=2</math>) need to be computed, because the contribution of sun (<math>j=3</math>) is negligible. Nevertheless, also the moon's contribution to this degree 3 tide to the radial displacement does not exceed the <math>1.7</math> millimetres in radial and <math>0.02</math> millimetres in transversal components.

Finally, it must be taken into account that the previous equations provide the correction to obtain the coordinates relative to the "conventional tide free". To obtain the position relative to the "mean tide" the following vector must be added <ref group="footnotes"> According to the Resolution of 18th IAG General Assembly, 1983 (see [Denis et al., 2004] pages 9-10, and 83, the (degree 2 zonal) tidal potential contains a time independent (i.e., permanent) part, which is included in the geoid definition. Thence, the "mean tide" position is obtained after removing this part to the tidal displacement. This is done, by adding the vector in equation (4) to the tidal displacement computed from equation (1).</ref>:

::<math>
\begin{array}{ll}
\left [-0.1206+0.0001\,P_2(\sin \varphi)\right ]P_2(\sin \varphi) \qquad\mbox{(m) radial direction}\\
\left [-0.0252+0.0001\,P_2(\sin \varphi)\right ]\sin 2\varphi \qquad\mbox{(m) north direction}
\end{array} \qquad\mbox{(4)}</math>

where <math>P_2(\sin \varphi)=(3\,\sin^2\varphi-1)/2</math>.

Notice that the radial component of this part can amount for about <math>-12</math> centimetres at the poles and about <math>+6</math> centimetres at the equator.

An alternative set of equations describing a similar model implemented in GIPSY-OASIS II can be found in [Webb and Zumberge, 1993] <ref> [Webb and Zumberge, 1993] Webb, F. and Zumberge, J., 1993. An Introduction to GIPSY/OASIS-II. Jet Propulsion Laboratory, JPL, 4800 Oak Grove Drive, Pasadena, CA 91109.</ref>.

Figure 1 illustrates an example of the effect of the Solid Tides correction. The navigation solution computed using the solid tides correction is shown in blue and the solution without using this correction in red. The effect of solid tides displacement on range is shown in the second row at left.

::{|
|+align="bottom"|''Figure 1: Solid Tides: Range and position domain effect.''
| [[File:Solid_Tides_Ex2b2.png|none|thumb|400px|frameless]]
| [[File: Solid_Tides_Ex2b3.png|none|thumb|400px|frameless]]
|-
| [[File:Solid_Tides_Ex2b1.png|none|thumb|400px|frameless]]
| '' First row shows the horizontal (left) and vertical (right) positioning error using (blue) or not using (red) the solid tides correction (from equations (1) to (3)). The effect on range of solid tides displacement is shown in the second row at left.''
|}

==Rotational ellipsoid model for solid Earth tide with high precision==

A new [https://rdcu.be/elmWR model] for the solid Earth tide was published in 2024<ref name="Solid Earth Tide high precision"> Yang, Y., Zhang, Y., Liu, Q. et al. A rotational ellipsoid model for solid Earth tide with high precision. Sci Rep 14, 28527 (2024). https://doi.org/10.1038/s41598-024-79898-8 </ref>, presenting a rotating ellipse for computing Earth's tidal deformations with improved accuracy, and integrating recent geophysical data and refined computational methods. The vertical displacement of a reference point relative to the Earth's center at a time ''t'' can be written as:

<math>H_{(t)} = \sqrt{(R+M_e)^2 \cos^2\alpha+(R-M_s)^2\sin^2\alpha}+\sqrt{(R+S_e)^2 \cos^2\beta+(R-S_s)^2\sin^2\beta}-2R</math>

where

<math>R</math> is the mean radius of solid Earth, 6371 km;

<math>M_e(S_e)</math> and <math>M_s(S_s)</math> are the elongation in the major semi-axis and the shortening in the minor semi-axis due to the Moon (Sun), respectively;

<math>(R+M_e)</math> and <math>(R-M_s)</math> are the major semi-axis's length and minor semi-axis's length of the ellipsoid due to the Moon;

<math>(R+S_e)</math> and <math>(R-S_s)</math> are the major semi-axis's length and minor semi-axis's length of the ellipsoid due the Sun;

<math>\alpha</math> and <math>\beta</math> are the lunar and solar angles of the reference point relative to the Earth's center;

and <math>M_e=K_{me}P_m\cos^2{\delta_m}</math>, <math>S_e=K_{se}P_s\cos^2{\delta_s}</math>, <math>M_s=K_{ms}P_m\cos^2{\delta_m}</math>, <math>S_s=K_{ss}P_s\cos^2{\delta_s}</math>, where <math>P_m=D_{me}^2/D_m^2 \left( P_s=D_{se}^2/D_s^2 \right))</math> is a distance factor that relates to the Earth and Moon (Sun), <math>D_{me}\left( D_{se} \right)</math> is the mean distance between the Earth and Moon (Sun) at the time, <math>D_m\left( D_s \right)</math> is the temporary distance between the Earth and Moon (Sun) at the time, <math>K_{me}\left( K_{se} \right)</math> and <math>K_{ms}\left( K_{ss} \right)</math> are undetermined parameters of elongation and shortening in the prolate ellipsoid due to the Moon (Sun), <math>\cos^2\delta_m\left(\cos^2\delta_s\right)</math> denotes a latitude factor that relates to the position of the Moon (Sun), <math>\delta_m\left(\delta_s\right)</math> is the declination of the Moon (Sun).

By a least-squares fitting with observations (i.e., superconducting gravity data), the parameters <math>K_{me}, K_{ms}, K_{se}</math> and <math>K_{ss}</math> are resolved to be 41.33 cm, 21.41 cm, 15.93 cm, and 13.03 cm, respectively.

==Notes==
<references group="footnotes"/>

==References==
<references/>

[[Category:Fundamentals]]
[[Category:GNSS Measurements Modelling]]

Galileo Space Segment

2025-06-25T09:00:02Z

Natalia.Castrillo:

{{Article Infobox2
|Category=GALILEO
|Editors=GMV
|Level=Basic
|YearOfPublication=2011
|Logo=GMV
|Title={{PAGENAME}}
}}

The Galileo constellation comprises of 30 satellites placed in MEO orbit, with 10 satellites placed in each of 3 orbital planes (at 56º nominal inclination <ref name="Galileo_Early_Services">[https://www.gsc-europa.eu/galileo/system Galileo System in European GNSS Service Centre website]</ref>) distributed evenly round the equator. The active constellation comprises of 24 satellites (Walker 24/3/1), including 6 spare satellites, which can be moved to replace any failed satellite within the same plane, thereby reducing the impact of failures upon quality of service. All satellites are identical in terms of design, performance capability and fuel load. Each satellite broadcasts navigation timing signals together with navigation data providing the clock and ephemeris correction data which are essential for navigation.<ref name="Galileo_Early_Services">[https://www.gsc-europa.eu/galileo/system Galileo System in European GNSS Service Centre website]</ref>

The nominal orbit of a Galileo satellite is circular, with an altitude of approximately 23,229 km above the Earth’s surface. This configuration results in a ground track that repeats every 10 days, corresponding to 17 orbital revolutions over nearly ten sidereal days.

==Constellation features==
[[File:Galileo Space Segment.jpg|left|thumb|400px|Galileo Space Segment]]
The altitude of the satellites has been chosen to avoid gravitational resonances so that, after initial orbit optimisation, station-keeping manoeuvres will not be needed during the lifetime of a satellite. The altitude chosen also ensures a high visibility of the satellites.

The position constraints for individual satellites are set by the need to maintain a uniform constellation, for which it is specified that each satellite should be within +/- 2° of its nominal position relative to the adjacent satellites in the same orbit plane and should be within 2° of the orbit plane.

The in-plane accuracy is equivalent to a relative tolerance of over 1000 km but requires very careful adjustment of the satellite velocity to ensure that the orbit period of all the satellites is kept precisely the same. The across-track tolerance allows the inclination and Right Ascension of the Ascending Node (RAAN) of each satellite to be biased at launch so that natural drifts remain within the tolerance without the need for orbit plane changes requiring major expense of fuel.

The spare satellite in each orbit plane ensures that in case of failure the constellation can be repaired quickly by moving the spare to replace the failed satellite. This could be done in a matter of days, rather than waiting for a new launch to be arranged which could take many months. The satellites are designed to be compatible with a range of launchers providing multiple and dual launch capabilities.

There are good reasons for choosing such a structure for the Galileo constellation. With 30 satellites at such an altitude, there is a very high probability (more than 90%) that anyone anywhere in the world can always be in sight of at least four satellites and hence is able to determine their position from the ranging signals broadcast by the satellites. The inclination of the orbits was chosen to ensure good coverage of polar latitudes, which are poorly served by the US GPS system.

From most locations, six to eight satellites may always be visible, allowing positions to be determined very accurately – to within a few centimeters. Even in high rise cities, there is a good chance that a road user may have sufficient satellites overhead for taking a position, especially as the Galileo system is interoperable with the US system of 24 GPS satellites.

This constellation provides good local geometries with a typical vertical dilution of precision (VDOP) of 2.3 and horizontal dilution of precision (HDOP) around 1.3. An additional benefit of the constellation geometry is the limited number of planes, which allows for faster deployment and reduced constellation maintenance costs due to the capability to launch multiple satellites with a single launcher.

==Galileo satellites==
[[File:Galileo satellite system.jpg|right|thumb|300px|Galileo satellite]]

The Galileo constellation is composed of a total of 30 Medium Earth Orbit (MEO) satellites, of which 6 are spares. Each satellite broadcasts precise time signals, ephemeris and other data. The Galileo satellite constellation has been optimised to the following nominal constellation specifications:<ref name="OS SDD"> [https://www.gsc-europa.eu/sites/default/files/sites/all/files/Galileo-OS-SDD_v1.1.pdf Applicable galileo Open Service (OS) Service Definition Document (SDD)]</ref>

*circular orbits (satellite altitude of 23 222 km)
*orbital inclination of 56°
*three equally spaced orbital planes
*eight operational satellites, equally spaced in each plane
*six spare satellites (also transmitting)

The constellation is complemented by spare satellites that can be repositioned to any given slot depending on maintenance or service evolution needs. The location of the spare satellites in each plane is not yet frozen and will be decided at the time of deployment of the spare capability.<ref name="OS SDD"> [https://www.gsc-europa.eu/sites/default/files/sites/all/files/Galileo-OS-SDD_v1.1.pdf Applicable galileo Open Service (OS) Service Definition Document (SDD)]</ref>

Each Galileo satellite is a 700 kg/1600 W class satellite, contains all the equipment needed to perform its assigned navigation and timing tasks over the course of its 12-year design life. Powered by solar arrays, with its internal components carefully shielded against the radiation prevailing in medium-Earth orbit.

The image shows an artist's impression of a Galileo spacecraft in orbit with solar arrays deployed. The spacecraft rotates about its Earth-pointing axis so that the flat surface of the solar arrays always faces the Sun to collect maximum solar energy. The antennas, shown on the underside of the body in the picture, always point towards the Earth. The spacecraft body will measure 2.7 m x 1.1 m x 1.2 m and the deployed solar arrays span 13 m.

===Galileo Satellite subsystems===
The satellite is composed of the following subsystems:
*Payload Subsystem including the navigation payload and the SAR payload
*Structure Subsystem
*Thermal Control Subsystem (TCS)
*Electrical Power Subsystem (EPS) with the following units:
**Solar Arrays (SA)
**Solar Array Drive Mechanisms (SADM)
**Battery
**Power Conditioning and Distribution Unit (PCDU)
*Harness
*Avionics Subsystem with
**on-board computer (Integrated Control and Data Handling Unit, ICDU)
**Attitude and Orbit Control System, AOCS (based on earth sensors, sun sensors, gyros, reaction wheels and magnetic torquers),
**Software (SW)
*Telemetry, Tracking and Command (TTC) Subsystem (with S-Band Transponder and two low-gain, omni-directional antennas)
*Propulsion Subsystem (mono-propellant system with one tank and 8 thrusters)
*Laser Retro-Reflector (LRR)
*Platform Security Unit (PFSU)

===Galileo Satellite components===
The '''L-band antenna''' transmits the navigation signals in the 1200-1600 MHz frequency range.

The '''[[Galileo Search and Rescue Service|SAR (Search and Rescue) antenna]]''' picks up distress signals from beacons on Earth and transmits them to a ground station for forwarding to local rescue services.

The '''C-band antenna''' receives signals containing mission data from Galileo Uplink Stations. This includes data to synchronise the on-board clocks with a ground-based reference clock and integrity data which contains information about how well each satellite is functioning. The integrity information is incorporated into the navigation signal for transmission to users.

Two '''S-band antennas''' are part of the telemetry, tracking and command subsystem. They transmit housekeeping data about the payload and spacecraft to ground control and, in turn, receive commands to control the spacecraft and operate the payload. The S-band antennas also receive, process and transmit ranging signals that measure the satellite's altitude to within a few metres.

The '''infrared Earth sensors''' and the '''Sun sensors''' both help to keep the spacecraft pointing at the Earth. The infrared Earth sensors do this by detecting the contrast between the cold of deep space and the heat of the Earth's atmosphere. The Sun sensors are visible light detectors which measure angles between their mounting base and incident sunlight.

The '''laser retro-reflector''' allows the measurement of the satellite's altitude to within a few centimetres by reflecting a laser beam transmitted by a ground station. The laser retro-reflector is used only about once a year, as altitude measurements via S-band antenna ranging signals are otherwise accurate enough.

The '''space radiators''' are heat exchangers that radiate waste heat, produced by the units inside the spacecraft, to deep space and thus help to keep the units within their operational temperature range.

In the following image are identified the main external components: <ref name = "Satellite anatomy">[https://www.esa.int/Applications/Navigation/Galileo/Satellite_anatomy "Satellite anatomy”, ESA] </ref>

[[File:ExternalPartsGalileoSatellite.png | none|thumb|400px| Source: "Satellite anatomy”, ESA<ref name = "Satellite anatomy">[https://www.esa.int/Applications/Navigation/Galileo/Satellite_anatomy "Satellite anatomy”, ESA] </ref>]]

===Interior: payload===
The Galileo satellites include two payloads, the Navigation payload and the Search and Rescue payload.
Their main functions are:
*Provision of on-board timing signals
*Receipt & storage of up-linked navigation message data
*Receipt & storage of up-linked integrity data
*Assembly of navigation message in the agreed format
*Error correction coding of navigation message
*Generation of ranging codes
*Encryption of ranging codes as required
*Generation and modulation of L-Band carrier signals
*Broadcast of navigation signals

The timing signals are provided by high precision on-board clocks, implemented as two (cold) redundant pairs per satellite, each pair including two different technologies, both of them being operated simultaneously:

A '''Passive Hydrogen Maser (PHM) clock''' is the master clock on board the spacecraft. It is an atomic clock which uses the ultra stable 1.4 GHz transition in a hydrogen atom to measure time to within 0.45 ns over 12 hours.

A '''Rubidium Atomic Frequency Standard (RAFS) clock''' will be used should the maser clock fail. It is accurate to within 1.8 ns over 12 hours.
[[File:Rubidium_clock.jpg|left|thumb|250px|Rubidium clock]]

At any time, only one clock of each type is operating. Under normal conditions, the operating maser clock produces the reference frequency from which the navigation signal is generated. Should the maser clock fail, however, the operating rubidium clock will take over instantaneously and the two reserve clocks will start up. If the problem with the failed maser clock is unique to that clock, the second maser clock will take over from the rubidium clock after a few days when it is fully operational. The rubidium clock will then go on stand-by or reserve again. In this way, by having four clocks, the Galileo spacecraft is guaranteed to generate a navigation signal at all times.

The '''clock monitoring and control unit''' provides the interface between the four clocks and the navigation signal generator unit (NSGU). It passes the signal from the active master clock to the NSGU and also ensures that the frequencies produced by the master clock and the active spare are in phase, so that the spare can take over instantly should the master clock fail.

The '''navigation signal generator, frequency generator and up-conversion units''' are in charge of generating the navigation signals using input from the clock monitoring unit and the up-linked navigation and integrity data from the C-band antenna. The navigation signals are converted to L-band for broadcast to users.

The '''navigation signal generator, frequency generator and up-conversion units (NSGU)''', which includes internal cold redundancy, receives the up-linked navigation data and uses them to generate the navigation signals in the appropriate format, performs the PRN encoding and the modulation of the 3 navigation signals (E5a + E5b, E6 and L1) and passes them to the Frequency Generation and Up-conversion Unit (FGUU) which performs the up- conversion into L-band of the 3 signals.

The '''remote terminal unit''' is the interface between all the payload units and the on-board computer.

===Interior: service module===
'''SADM''' is the drive mechanism that connects the solar arrays to the spacecraft and rotates them slowly so that the surface of the arrays can remain perpendicular to the Sun's rays at all times.

The '''gyroscopes''' measure the rotation of the spacecraft.

The '''reaction wheels''' control the rotation of the spacecraft. When they rotate, so does the spacecraft. It rotates twice per orbit to allow the solar arrays to remain parallel to the Sun's rays.

The '''magneto bar''' modifies the speed of rotation of the reaction wheels by introducing a torque (turning force) in the opposite direction.

The '''power conditioning and distribution unit''' regulates and controls power from the solar arrays and batteries and distributes it to all the spacecraft's subsystems and payload.

The '''environmental monitoring unit''' on-board takes radiation measurements.

The '''on-board computer''' controls all aspects of spacecraft and payload functioning.

=== Satellites Key Features<ref>[https://www.ohb-system.de/files/images/mediathek/downloads/190603_OHB-System_Galileo_FOC-Satellites_2019-05.pdf Key Features of the Galileo Satellites], OHB</ref> ===

{| class="wikitable"
|-
! colspan="2" | Key Features
|-
|Body dimensions || 2.5 x 1.2 x 1.1 m
|-
|Span solar generator || 14.67 m
|-
|Solar generator power || 1.9 Kw
|-
|Navigation signals || 3 bands (E5, E6, E1)
|-
|SAR Transponder || UHF Receiver 406 MHz
L-Band transceiver 1,544 MHz
|-
|Lifetime || > 12 years on-orbit
> 5 years ground storage
|-
|Reliability || > 0.88 /12 years
|-
|Launch mass || 732.8 Kg
|}

==Galileo Metadata ==
The Galileo Metadata can be found in the GNSS Service Centre Web Page. See the following link:

https://www.gsc-europa.eu/support-to-developers/galileo-satellite-metadata

==Satellites Names and Launching ==

Up to date information on the Galileo program, namely launching and phases can be found in: <ref>[https://www.gsc-europa.eu/system-service-status/constellation-information Current Galileo constellation status] </ref>.

European Commission created a children's drawing competition to name each launched satellite. The competition was open to children from all member states and the name of the winner from each state was given to one of the Galileo satellites.

The full list of the winners competition can be found [http://ec.europa.eu/enterprise/policies/satnav/galileo/drawing-competition/index_en.htm here], as well the drawings that gave them the victory.

More information on the Galileo IOV satellites is provided [https://ec.europa.eu/growth/sectors/space/galileo/drawing-competition_en| here].

==References==
<references/>

[[Category:GALILEO]]
[[Category:GALILEO Architecture]]
[[Category:GALILEO Space Segment]]

GPS and Galileo Satellite Coordinates Computation

2025-06-25T08:09:18Z

Natalia.Castrillo:

{{Article Infobox2
|Category=Fundamentals
|Authors=J. Sanz Subirana, J.M. Juan Zornoza and M. Hernández-Pajares, Technical University of Catalonia, Spain.
|Level=Intermediate
|YearOfPublication=2011
|Title={{PAGENAME}}
}}
Table 1 provides the [[GPS General Introduction|GPS]] or [[GALILEO General Introduction|Galileo]] broadcast ephemeris parameters to compute their satellite coordinates at any observation epoch. These parameters are periodically renewed (typically every 2 hours for [[GPS]] and 3 hours for [[GALILEO General Introduction|Galileo]]) and must not be used out of the prescribed time (about four hours), because the extrapolation error grows exponentially beyond its validity period.

The algorithm provided is from the [IS-GPS-200, table 20-IV] <ref group="footnotes"> [IS-GPS-200], NAVSTAR GPS Space Segment/Navigation User Interfaces https://www.gps.gov/technical/icwg/IS-GPS-200M.pdf </ref>.The Galileo satellites follow an analogue scheme [OS SIS ICD, Issue 2.1, Table 66: User Algorithm for Ephemeris Determination] <ref group="footnotes"> [OS SIS ICD], Galileo Open Service Signal-In-Space Interface Control Document https://www.gsc-europa.eu/sites/default/files/sites/all/files/Galileo_OS_SIS_ICD_v2.1.pdf </ref>.

::[[File: GPS_Galileo_Coord_Comp_Table_1.png|none|thumb|640px|'''''Table 1:''''' GPS and Galileo broadcast ephemeris and clock message parameters.]]

In order to compute satellite coordinates from navigation message, the algorithm provided as follows must be used. An accuracy of about 4 meters (RMS) is achieved for GPS satellites with S/A=0ff and several tens of meters with S/A=on <ref group="footnotes"> Actually, the S/A was mainly applied to the satellite clocks and, apparently, not so often to the ephemeris.</ref>:

* Compute the time <math>t_k</math> from the ephemerides reference epoch <math>t_{oe}</math> (<math>t</math> and <math>t_{oe}</math> are expressed in seconds):

::<math>t_k=t-t_{oe}</math>

<math>t</math> being the system time at the moment of transmission, expressed in GPS System Time for GPS, or Galileo System Time for Galileo.

:For GPS, if <math>t_k>302\,400</math> sec, subtract <math>604\,800</math> sec from <math>t_k</math>. If <math>t_k< -302\,400</math> sec, add <math>604\,800</math> sec.

* Compute the mean anomaly for <math>t_k</math>,
::<math>M_k=M_o+\left( \frac{\sqrt{\mu }}{\sqrt{a^3}}+\Delta n\right)t_k
</math>

* Solve (iteratively) the Kepler equation for the eccentricity anomaly <math>E_k</math>:
::<math>M_k=E_k-e\sin E_k</math>

* Compute the true anomaly <math>v_k</math>, two different formulas can be used. The first formula uses the arctangent function, while the second one uses the inverse tangent function. Both formulas yield the same result, but they approach the calculation differently:

::<math>(1) v_k=\arctan \left( \frac{\sqrt{1-e^2}\sin E_k}{\cos E_k-e}\right)</math>

::<math>(2) v_k = 2 \tan^{-1} \left( \sqrt{\frac{1+e}{1-e}} \tan \left( \frac{E_k}{2} \right) \right)</math> (Recommended, unambiguous quadrant)

* Compute the argument of latitude <math>u_k</math> from the argument of perigee <math>\omega </math>, true anomaly <math>v_k</math> and corrections <math>c_{uc}</math> and <math>c_{us}</math>:
::<math>u_k=\omega +v_k+c_{uc}\cos 2\left( \omega +v_k\right) +c_{us}\sin
2\left( \omega +v_k\right)</math>

* Compute the radial distance <math>r_k</math>, considering corrections <math>c_{rc}</math> and <math>c_{rs}</math>:
::<math>r_k=a\left( 1-e\cos E_k\right) +c_{rc}\cos 2\left( \omega
+v_k\right) +c_{rs}\sin 2\left( \omega +v_k\right)
</math>

* Compute the inclination <math>i_k</math> of the orbital plane from the inclination <math>i_o</math> at reference time <math>t_{oe}</math>, and corrections <math>c_{ic}</math> and <math>c_{is}</math>:
::<math>i_k=i_o+\stackrel{\bullet }{i} t_k+c_{ic}\cos 2\left(
\omega +v_k\right) +c_{is}\sin 2\left( \omega +v_k\right)
</math>

* Compute the longitude of the ascending node <math>\lambda_k</math> (with respect to Greenwich). This calculation uses the right ascension at the beginning of the current week (<math>\Omega _o</math>), the correction from the apparent sidereal time variation in Greenwich between the beginning of the week and reference time <math>t_k=t-toe</math>, and the change in longitude of the ascending node from the reference time <math>t_{oe}</math>:
::<math>\lambda _k=\Omega _o+\left( \stackrel{\bullet }{\Omega }-\omega
_E\right) t_k-\omega _E t_{oe}
</math>

* Compute the coordinates in TRS frame, applying three rotations (around <math>u_k</math>, <math>i_k</math> and <math>\lambda _k</math>):
::<math>\left[
\begin{array}{c}
X_k \\
Y_k \\
Z_k
\end{array}
\right] ={\mathbf R}_3\left( -\lambda _k\right) {\mathbf R}_1\left( -i_k\right) {\mathbf R}_3\left( -u_k\right) \left [
\begin{array}{c}
r_k \\
0 \\
0
\end{array}
\right]
</math>

:where <math>{\mathbf R}_1</math> and <math>{\mathbf R_3}</math> are the rotation matrices defined in [[Transformation between Terrestrial Frames]].

==Notes==
<references group="footnotes"/>

[[Category:Fundamentals]]
[[Category:GNSS Time Reference, Coordinate Frames and Orbits]]
[[Category:GPS]]
[[Category:GALILEO]]

GPS and Galileo Satellite Coordinates Computation

2025-06-25T08:03:14Z

Natalia.Castrillo:

{{Article Infobox2
|Category=Fundamentals
|Authors=J. Sanz Subirana, J.M. Juan Zornoza and M. Hernández-Pajares, Technical University of Catalonia, Spain.
|Level=Intermediate
|YearOfPublication=2011
|Title={{PAGENAME}}
}}
Table 1 provides the [[GPS General Introduction|GPS]] or [[GALILEO General Introduction|Galileo]] broadcast ephemeris parameters to compute their satellite coordinates at any observation epoch. These parameters are periodically renewed (typically every 2 hours for [[GPS]] and 3 hours for [[GALILEO General Introduction|Galileo]]) and must not be used out of the prescribed time (about four hours), because the extrapolation error grows exponentially beyond its validity period.

The algorithm provided is from the [IS-GPS-200, table 20-IV] <ref group="footnotes"> [IS-GPS-200], NAVSTAR GPS Space Segment/Navigation User Interfaces https://www.gps.gov/technical/icwg/IS-GPS-200M.pdf </ref>.The Galileo satellites follow an analogue scheme [OS SIS ICD, Issue 2.1, Table 66: User Algorithm for Ephemeris Determination] <ref group="footnotes"> [OS SIS ICD], Galileo Open Service Signal-In-Space Interface Control Document https://www.gsc-europa.eu/sites/default/files/sites/all/files/Galileo_OS_SIS_ICD_v2.1.pdf </ref>.

::[[File: GPS_Galileo_Coord_Comp_Table_1.png|none|thumb|640px|'''''Table 1:''''' GPS and Galileo broadcast ephemeris and clock message parameters.]]

In order to compute satellite coordinates from navigation message, the algorithm provided as follows must be used. An accuracy of about 4 meters (RMS) is achieved for GPS satellites with S/A=0ff and several tens of meters with S/A=on <ref group="footnotes"> Actually, the S/A was mainly applied to the satellite clocks and, apparently, not so often to the ephemeris.</ref>:

* Compute the time <math>t_k</math> from the ephemerides reference epoch <math>t_{oe}</math> (<math>t</math> and <math>t_{oe}</math> are expressed in seconds):

::<math>t_k=t-t_{oe}</math>

<math>t</math> being the system time at the moment of transmission, expressed in GPS System Time for GPS, or Galileo System Time for Galileo.

:For GPS, if <math>t_k>302\,400</math> sec, subtract <math>604\,800</math> sec from <math>t_k</math>. If <math>t_k< -302\,400</math> sec, add <math>604\,800</math> sec.

* Compute the mean anomaly for <math>t_k</math>,
::<math>M_k=M_o+\left( \frac{\sqrt{\mu }}{\sqrt{a^3}}+\Delta n\right)t_k
</math>

* Solve (iteratively) the Kepler equation for the eccentricity anomaly <math>E_k</math>:
::<math>M_k=E_k-e\sin E_k</math>

* Compute the true anomaly <math>v_k</math>, two different formulas can be used. The first formula uses the arctangent function, while the second one uses the inverse tangent function. Both formulas yield the same result, but they approach the calculation differently:

::<math>(1) v_k=\arctan \left( \frac{\sqrt{1-e^2}\sin E_k}{\cos E_k-e}\right)</math>

::<math>(2) v_k = 2 \tan^{-1} \left( \sqrt{\frac{1+e}{1-e}} \tan \left( \frac{E_k}{2} \right) \right)</math>

* Compute the argument of latitude <math>u_k</math> from the argument of perigee <math>\omega </math>, true anomaly <math>v_k</math> and corrections <math>c_{uc}</math> and <math>c_{us}</math>:
::<math>u_k=\omega +v_k+c_{uc}\cos 2\left( \omega +v_k\right) +c_{us}\sin
2\left( \omega +v_k\right)</math>

* Compute the radial distance <math>r_k</math>, considering corrections <math>c_{rc}</math> and <math>c_{rs}</math>:
::<math>r_k=a\left( 1-e\cos E_k\right) +c_{rc}\cos 2\left( \omega
+v_k\right) +c_{rs}\sin 2\left( \omega +v_k\right)
</math>

* Compute the inclination <math>i_k</math> of the orbital plane from the inclination <math>i_o</math> at reference time <math>t_{oe}</math>, and corrections <math>c_{ic}</math> and <math>c_{is}</math>:
::<math>i_k=i_o+\stackrel{\bullet }{i} t_k+c_{ic}\cos 2\left(
\omega +v_k\right) +c_{is}\sin 2\left( \omega +v_k\right)
</math>

* Compute the longitude of the ascending node <math>\lambda_k</math> (with respect to Greenwich). This calculation uses the right ascension at the beginning of the current week (<math>\Omega _o</math>), the correction from the apparent sidereal time variation in Greenwich between the beginning of the week and reference time <math>t_k=t-toe</math>, and the change in longitude of the ascending node from the reference time <math>t_{oe}</math>:
::<math>\lambda _k=\Omega _o+\left( \stackrel{\bullet }{\Omega }-\omega
_E\right) t_k-\omega _E t_{oe}
</math>

* Compute the coordinates in TRS frame, applying three rotations (around <math>u_k</math>, <math>i_k</math> and <math>\lambda _k</math>):
::<math>\left[
\begin{array}{c}
X_k \\
Y_k \\
Z_k
\end{array}
\right] ={\mathbf R}_3\left( -\lambda _k\right) {\mathbf R}_1\left( -i_k\right) {\mathbf R}_3\left( -u_k\right) \left [
\begin{array}{c}
r_k \\
0 \\
0
\end{array}
\right]
</math>

:where <math>{\mathbf R}_1</math> and <math>{\mathbf R_3}</math> are the rotation matrices defined in [[Transformation between Terrestrial Frames]].

==Notes==
<references group="footnotes"/>

[[Category:Fundamentals]]
[[Category:GNSS Time Reference, Coordinate Frames and Orbits]]
[[Category:GPS]]
[[Category:GALILEO]]

Solid Tides

2025-05-09T14:51:06Z

Natalia.Castrillo:

{{Article Infobox2
|Category=Fundamentals
|Authors=J. Sanz Subirana, J.M. Juan Zornoza and M. Hernández-Pajares, Technical University of Catalonia, Spain.
|Level=Advanced
|YearOfPublication=2011
|Title={{PAGENAME}}
}}
Earth solid tides comprise the Earth's crust movement (and thus the receiver location coordinates variation) due to gravitational attracting forces produced by external bodies, mainly the sun and the moon. The Solid Tides produce vertical and horizontal displacements that can be expressed by spherical harmonics expansion (<math>\displaystyle m</math>,<math>\displaystyle n</math>), characterised by the Love and Shida numbers <math>\displaystyle h_{mn}</math>, <math>\displaystyle l_{mn}</math>.

An accurate modeling of Earth solid tides is essential for ensuring that GNSS-derived positions are reliable, especially for scientific and engineering applications.

==IERS solid Earth tide model==

A simplified model for the tide displacement, but with few millimeters of accuracy, is given by the following expression (from IERS Conventions degree 2 tides displacement model --in-phase corrections--, see [Denis et al., 2004] <ref> [Denis et al., 2004] Denis, D., McCarthy and Petit, G., 2004. IERS Conventions (2003). IERS Technical Note 32. IERS Convention Center, Frankfurt am Main.</ref>, page 79):

:<math>
\Delta {\mathbf r}= \sum_{j=2}^{3}{\frac{G\,M_j\,R_e^4}{G\,M_\oplus\,R_j^3}} \left \{h_2 \,\hat{\mathbf r} \left ( \frac{3}{2} (\hat{\mathbf R}_j \cdot \hat{\mathbf r})^2 -\frac{1}{2}\right) + 3\,l_2\,(\hat{\mathbf R}_j \cdot \hat{\mathbf r}) \left [\hat{\mathbf R}_j-(\hat{\mathbf R}_j \cdot \hat{\mathbf r})\,\hat{\mathbf r} \right ]\right \} \qquad\mbox{(1)}</math>

:::<math>\Delta {\mathbf r}</math> is a site displacement vector in a Cartesian coordinates system.
:::<math>G\,M_\oplus</math> is gravitational parameters of the earth.
:::<math>G\,M_j</math> is gravitational parameters of the moon (<math>j = 2</math>) and sun (<math>j = 3</math>).
::::::(<math>M_{sun}/M_\oplus=332946.0</math>, <math>M_{moon}/M_\oplus=0.01230002</math>)
:::<math>\hat{\mathbf R}_j</math>, <math>\displaystyle R_j</math> are the unit vector from the geocentre to moon or sun and the magnitude of that vector.
:::<math>\displaystyle R_e</math> is the earth's equatorial radius (<math>R_e=6378136.6\,m</math>).
:::<math>\hat{\mathbf r}</math>, <math>\displaystyle r</math> are the unit vector from the geocentre to the station and the magnitude of that vector.
:::<math>\displaystyle h_2</math> is the nominal degree 2 Love number (<math>\displaystyle h_2=0.6078</math>).
:::<math>\displaystyle l_2</math> is the nominal degree 2 Shida number (<math>\displaystyle l_2=0.0847</math>).

Notice that the radial (not vertical) component (<math>\displaystyle \hat{\mathbf r}</math>) is proportional to the Love number <math>\displaystyle h_2</math>, while the terms in <math>\displaystyle l_2</math> corresponds to components orthogonal to the radial direction (not the horizontal plane).

A small correction of latitude (<math>\varphi</math>) dependence can be considered in the <math>\displaystyle h_2</math> and <math>\displaystyle l_2</math> values of previous equation (1) according to the expression:

::<math>
\begin{array}{rl}
h_2&= 0.6078-0.0006\left [(3 \sin^2\varphi-1)/2\right]\\[0.3cm]
l_2&= 0.0847+0.0002\left [(3 \sin^2\varphi-1)/2\right]
\end{array} \qquad\mbox{(2)}</math>

An additional refinement can be to take into account the additional contribution due to the degree 3 tides [Denis et al., 2004], page 80):

<math>
\Delta {\mathbf r}= \sum_{j=2}^{3}{\frac{G\,M_j\,R_e^5}{G\,M_\oplus\,R_j^4}} \left \{h_3 \,\hat{\mathbf r} \left ( \frac{5}{2} (\hat{\mathbf R}_j \cdot \hat{\mathbf r})^3 -\frac{3}{2} (\hat{\mathbf R}_j \cdot \hat{\mathbf r})\right) + l_3\,\left (\frac{15}{2} (\hat{\mathbf R}_j \cdot \hat{\mathbf r})^2 - \frac{3}{2} \right ) \left [\hat{\mathbf R}_j-(\hat{\mathbf R}_j \cdot \hat{\mathbf r})\,\hat{\mathbf r} \right ]\right \} \qquad\mbox{(3)}</math>

where <math>\displaystyle h_3=0.292</math> and <math>\displaystyle l_3=0.015</math>. Only the moon's contribution (<math>j=2</math>) need to be computed, because the contribution of sun (<math>j=3</math>) is negligible. Nevertheless, also the moon's contribution to this degree 3 tide to the radial displacement does not exceed the <math>1.7</math> millimetres in radial and <math>0.02</math> millimetres in transversal components.

Finally, it must be taken into account that the previous equations provide the correction to obtain the coordinates relative to the "conventional tide free". To obtain the position relative to the "mean tide" the following vector must be added <ref group="footnotes"> According to the Resolution of 18th IAG General Assembly, 1983 (see [Denis et al., 2004] pages 9-10, and 83, the (degree 2 zonal) tidal potential contains a time independent (i.e., permanent) part, which is included in the geoid definition. Thence, the "mean tide" position is obtained after removing this part to the tidal displacement. This is done, by adding the vector in equation (4) to the tidal displacement computed from equation (1).</ref>:

::<math>
\begin{array}{ll}
\left [-0.1206+0.0001\,P_2(\sin \varphi)\right ]P_2(\sin \varphi) \qquad\mbox{(m) radial direction}\\
\left [-0.0252+0.0001\,P_2(\sin \varphi)\right ]\sin 2\varphi \qquad\mbox{(m) north direction}
\end{array} \qquad\mbox{(4)}</math>

where <math>P_2(\sin \varphi)=(3\,\sin^2\varphi-1)/2</math>.

Notice that the radial component of this part can amount for about <math>-12</math> centimetres at the poles and about <math>+6</math> centimetres at the equator.

An alternative set of equations describing a similar model implemented in GIPSY-OASIS II can be found in [Webb and Zumberge, 1993] <ref> [Webb and Zumberge, 1993] Webb, F. and Zumberge, J., 1993. An Introduction to GIPSY/OASIS-II. Jet Propulsion Laboratory, JPL, 4800 Oak Grove Drive, Pasadena, CA 91109.</ref>.

Figure 1 illustrates an example of the effect of the Solid Tides correction. The navigation solution computed using the solid tides correction is shown in blue and the solution without using this correction in red. The effect of solid tides displacement on range is shown in the second row at left.

::{|
|+align="bottom"|''Figure 1: Solid Tides: Range and position domain effect.''
| [[File:Solid_Tides_Ex2b2.png|none|thumb|400px|frameless]]
| [[File: Solid_Tides_Ex2b3.png|none|thumb|400px|frameless]]
|-
| [[File:Solid_Tides_Ex2b1.png|none|thumb|400px|frameless]]
| '' First row shows the horizontal (left) and vertical (right) positioning error using (blue) or not using (red) the solid tides correction (from equations (1) to (3)). The effect on range of solid tides displacement is shown in the second row at left.''
|}

==Rotational ellipsoid model for solid Earth tide with high precision==

A new [https://rdcu.be/elmWR model] for the solid Earth tide was published in 2024<ref name="Solid Earth Tide high precision"> Yang, Y., Zhang, Y., Liu, Q. et al. A rotational ellipsoid model for solid Earth tide with high precision. Sci Rep 14, 28527 (2024). https://doi.org/10.1038/s41598-024-79898-8 </ref>, presenting an updated approach for modeling Earth's tidal deformations with improved accuracy, and integrating recent geophysical data and refined computational methods.

==Notes==
<references group="footnotes"/>

==References==
<references/>

[[Category:Fundamentals]]
[[Category:GNSS Measurements Modelling]]

NTCM G Ionospheric Model

2025-04-30T09:48:08Z

Natalia.Castrillo:

{{Article Infobox2
|Category=Fundamentals
|Authors=
|Level=Intermediate
|YearOfPublication=2025
|Title={{PAGENAME}}
}}
__TOC__
The '''NTCM G''' (Neustrelitz Total Electron Content Model) ionospheric model is designed to compute ionospheric corrections based on the broadcast coefficients in the navigation message for Galileo single-frequency users. NTCM-G is proposed as an alternative to the [[NeQuick_Ionospheric_Model|NeQuick-G ionospheric model]], whose high computational load poses a constraint in those user-segments where the user equipment has limited resources available. This is typically the case of the receivers used in civil aviation and location-based services (e.g., smartphones, UAVs, IoT devices).

The NTCM G electron density model was developed by the German Aerospace Center [https://www.dlr.de/en (DLR)]. The validation of NTCM G single-frequency ionospheric correction algorithm has been performed by DLR with the support of ESA, and the Joint Research Centre [https://joint-research-centre.ec.europa.eu (JRC)]<ref name="NTCMG_ICD2022">[https://www.gsc-europa.eu/sites/default/files/NTCM-G_Ionospheric_Model_Description_-_v1.0.pdf NTCM G Ionospheric Model Description, Issue 1.0, May 2022]</ref>.

The NTCM is an empirical model designed to provide a practical and cost-effective solution for estimating global TEC (Total Electron Content). It relies on 12 model coefficients (k₁ to k₁₂), a few fixed empirical parameters, and the solar radio flux index F10.7. To use the NTCM with the broadcast Galileo Effective Ionisation Level coefficients of the navigation message (aᵢ₀, aᵢ₁, aᵢ₂)<ref name="GALOSICD2023">[https://www.gsc-europa.eu/sites/default/files/sites/all/files/Galileo_OS_SIS_ICD_v2.1.pdf EU, SIGNAL-IN-SPACE INTERFACE CONTROL DOCUMENT, Issue 2.1, November 2023]</ref>, the F10.7 solar index is replaced by the term '''Azpar'''. This term is used as a proxy measure of the solar activity level and is determined as follows:
<math>
Azpar = \left| \sqrt{a_{i0}^2 + 1633.33 \cdot a_{i1}^2 + 4802000 \cdot a_{i2}^2 + 3266.67 \cdot a_{i0} \cdot a_{i2}} \right|
</math>

Where (aᵢ₀, aᵢ₁, aᵢ₂) are the three Effective Ionisation Level coefficients broadcast in the Galileo navigation message. The Azpar term is used to account for the solar activity dependency (F₅) in the estimation of VTEC (Vertical Total Electron Content) explained below.

NTCM G modeling approach consists of five major dependencies of TEC:
* Local time dependency (F₁)
* Seasonal dependency (F₂)
* Geomagnetic field dependency (F₃)
* Equatorial anomaly dependency (F₄)
* Solar activity dependency (F₅)

The dependencies are combined in a multiplicative way to compute a value of the VTEC:

<math>
VTEC_{NTCM-G} = F_1 \cdot F_2 \cdot F_3 \cdot F_4 \cdot F_5
</math>

Each Fi factor contains the model coefficients (k₁ to k₁₂) for its computation, whose values are provided in Table 3 of the model description document<ref name="DLR2022">[https://www.gsc-europa.eu/sites/default/files/NTCM-G_Ionospheric_Model_Description_-_v1.0.pdf DLR, NTCM-G Ionospheric Model Description, mayo de 2022]</ref>.

===Input parameters===
The input parameters required by the NTCM G model to estimate each TEC dependency (F₁ to F₅), and consequently the VTEC value, include:
* Galileo Effective Ionisation Level coefficients (aᵢ₀, aᵢ₁, aᵢ₂)
* User receiver and satellite positions in WGS-84 ellipsoidal coordinates (φu, λu, hu) and (φs, λs, hs)
* Universal Time (UT)
* Day of Year (DOY)

The output of NTCM G is the VTEC in TECU for each line of sight between satellite and receiver.

The estimated VTEC output can be converted to STEC (Slant Total Electron Content) using the following equation:

<math>
STEC = MF_{MSLM} \cdot VTEC_{NTCM-G}
</math>

Where the Modified Single Layer Model (MSLM) mapping function is:

<math>
MF_{MSLM} = \frac{1}{\sqrt{1 - (\sin z)^2}}
</math>

<math>
\sin z = \frac{R_e}{R_e + h_I} \cdot \sin(0.9782 \cdot (\frac{\pi}{2} - E))
</math>

With:
* Re = 6371 km (Earth's mean radius)
* hI = 450 km (ionospheric pierce point height)
* E = satellite elevation angle in radians

=== Ionospheric Delay Calculation ===
Once the STEC is estimated, the ionospheric propagation delay (in meters) can be computed:

<math>
I_f = \frac{40.3 \cdot 10^{16}}{f^2} \cdot STEC
</math>

Where:
* ''f'' is the signal frequency in Hz
* The constant 40.3 is in m³/s²/electrons
* 1016 converts TECU to electrons/m²

Higher-order ionospheric terms are generally neglected due to their small magnitude (e.g., < 20 cm for Galileo E1)<ref name="Hoque2008">M. M. Hoque y N. Jakowski, "Estimate of higher order ionospheric errors in GNSS positioning", Radio Sci., vol. 43, no. 5, 2008, doi:10.1029/2007RS003817.</ref>.

=== Algorithm Steps ===
To implement the ionospheric correction using NTCM G for Galileo single-frequency receivers, follow these steps<ref name="DLR2022" /> for each satellite-user line-of-sight:
# Obtain receiver (φu, λu, hu) and satellite (φs, λs, hs) positions, and Universal Time (UT), in terms of time of day and month.
# Compute Effectiove Ionization Level Azpar using the broadcast coefficients (aᵢ₀, aᵢ₁, aᵢ₂).
# Calculate satellite elevation (E) and azimuth (A) angles.
# Determine ionospheric pierce point location (φpp, λpp) for the user-to-satellite link at 450km height, and Local Time (LT).
# Use NTCM G to compute VTEC at (φpp, λpp), LT.
# Calculate mapping function (MF).
# Convert VTEC to STEC using the MF.
# Compute delay using equation for If for the corresponfing frequency to obtain the correction.
# Apply correction to pseudorange.
# Repeat for each satellite.

Under normal ionospheric conditions, variations occur slowly, making high-rate recomputation of delay corrections unnecessary for most applications. A 30-second update interval is generally adequate for stationary receivers or pedestrian users applying the NTCM G ionospheric model.<ref name="DLR2022" />.

=== Performance ===
The performance of the NTCM G model has been validated and compared to the NeQuick-G model. Results indicate that NTCM G provides generally comparable and sometimes slightly better performance than NeQuick-G<ref name="DLR2022" />. Validation includes comparisons with ground-based VTEC maps from IGS (International GNSS Service), STEC observations, and SPP-based (Single Point Positioning) 3D positioning errors under various geographic and solar activity conditions.

::[[File: VTEC_RMS_NeQuick_vs_NTCM.png |800px|center|thumb|'''''Figure 1:''''' VTEC RMS residual error distribution in 2014 and 2015 for daytime hours 12-15 LT for NeQuick-G (left panel) and NTCM (right panel) <ref>M. M. Hoque, N. Jakowski, y J. A. Cahuasqui, «Fast Ionospheric Correction Algorithm for Galileo Single Frequency Users», 2020 Eur. Navig. Conf. ENC, pp. 1-10, nov. 2020, doi: 10.23919/ENC48637.2020.9317502.</ref> ]]
==References==
<references/>

NTCM G Ionospheric Model

2025-04-30T09:46:50Z

Natalia.Castrillo: References and content updated, performances may need to be also reviewed - more recent analysis may be available

{{Article Infobox2
|Category=Fundamentals
|Authors=
|Level=Intermediate
|YearOfPublication=2025
|Title={{PAGENAME}}
}}
__TOC__
The '''NTCM G''' (Neustrelitz Total Electron Content Model) ionospheric model is designed to compute ionospheric corrections based on the broadcast coefficients in the navigation message for Galileo single-frequency users. NTCM-G is proposed as an alternative to the [[NeQuick_Ionospheric_Model|NeQuick-G ionospheric model]], whose high computational load poses a constraint in those user-segments where the user equipment has limited resources available. This is typically the case of the receivers used in civil aviation and location-based services (e.g., smartphones, UAVs, IoT devices).

The NTCM G electron density model was developed by the German Aerospace Center [https://www.dlr.de/en (DLR)]. The validation of NTCM G single-frequency ionospheric correction algorithm has been performed by DLR with the support of ESA, and the Joint Research Centre [https://joint-research-centre.ec.europa.eu (JRC)]<ref name="NTCMG_ICD2022">[https://www.gsc-europa.eu/sites/default/files/NTCM-G_Ionospheric_Model_Description_-_v1.0.pdf NTCM G Ionospheric Model Description, Issue 1.0, May 2022]</ref>.

The NTCM is an empirical model designed to provide a practical and cost-effective solution for estimating global TEC (Total Electron Content). It relies on 12 model coefficients (k₁ to k₁₂), a few fixed empirical parameters, and the solar radio flux index F10.7. To use the NTCM with the broadcast Galileo Effective Ionisation Level coefficients of the navigation message (aᵢ₀, aᵢ₁, aᵢ₂)<ref name="GALOSICD2023">[https://www.gsc-europa.eu/sites/default/files/sites/all/files/Galileo_OS_SIS_ICD_v2.1.pdf EU, SIGNAL-IN-SPACE INTERFACE CONTROL DOCUMENT, Issue 2.1, November 2023]</ref>, the F10.7 solar index is replaced by the term '''Azpar'''. This term is used as a proxy measure of the solar activity level and is determined as follows:
<math>
Azpar = \left| \sqrt{a_{i0}^2 + 1633.33 \cdot a_{i1}^2 + 4802000 \cdot a_{i2}^2 + 3266.67 \cdot a_{i0} \cdot a_{i2}} \right|
</math>

Where (aᵢ₀, aᵢ₁, aᵢ₂) are the three Effective Ionisation Level coefficients broadcast in the Galileo navigation message. The Azpar term is used to account for the solar activity dependency (F₅) in the estimation of VTEC (Vertical Total Electron Content) explained below.

NTCM-G modeling approach consists of five major dependencies of TEC:
* Local time dependency (F₁)
* Seasonal dependency (F₂)
* Geomagnetic field dependency (F₃)
* Equatorial anomaly dependency (F₄)
* Solar activity dependency (F₅)

The dependencies are combined in a multiplicative way to compute a value of the VTEC:

<math>
VTEC_{NTCM-G} = F_1 \cdot F_2 \cdot F_3 \cdot F_4 \cdot F_5
</math>

Each Fi factor contains the model coefficients (k₁ to k₁₂) for its computation, whose values are provided in Table 3 of the model description document<ref name="DLR2022">[https://www.gsc-europa.eu/sites/default/files/NTCM-G_Ionospheric_Model_Description_-_v1.0.pdf DLR, NTCM-G Ionospheric Model Description, mayo de 2022]</ref>.

===Input parameters===
The input parameters required by the NTCM-G model to estimate each TEC dependency (F₁ to F₅), and consequently the VTEC value, include:
* Galileo Effective Ionisation Level coefficients (aᵢ₀, aᵢ₁, aᵢ₂)
* User receiver and satellite positions in WGS-84 ellipsoidal coordinates (φu, λu, hu) and (φs, λs, hs)
* Universal Time (UT)
* Day of Year (DOY)

The output of NTCM G is the VTEC in TECU for each line of sight between satellite and receiver.

The estimated VTEC output can be converted to STEC (Slant Total Electron Content) using the following equation:

<math>
STEC = MF_{MSLM} \cdot VTEC_{NTCM-G}
</math>

Where the Modified Single Layer Model (MSLM) mapping function is:

<math>
MF_{MSLM} = \frac{1}{\sqrt{1 - (\sin z)^2}}
</math>

<math>
\sin z = \frac{R_e}{R_e + h_I} \cdot \sin(0.9782 \cdot (\frac{\pi}{2} - E))
</math>

With:
* Re = 6371 km (Earth's mean radius)
* hI = 450 km (ionospheric pierce point height)
* E = satellite elevation angle in radians

=== Ionospheric Delay Calculation ===
Once the STEC is estimated, the ionospheric propagation delay (in meters) can be computed:

<math>
I_f = \frac{40.3 \cdot 10^{16}}{f^2} \cdot STEC
</math>

Where:
* ''f'' is the signal frequency in Hz
* The constant 40.3 is in m³/s²/electrons
* 1016 converts TECU to electrons/m²

Higher-order ionospheric terms are generally neglected due to their small magnitude (e.g., < 20 cm for Galileo E1)<ref name="Hoque2008">M. M. Hoque y N. Jakowski, "Estimate of higher order ionospheric errors in GNSS positioning", Radio Sci., vol. 43, no. 5, 2008, doi:10.1029/2007RS003817.</ref>.

=== Algorithm Steps ===
To implement the ionospheric correction using NTCM-G for Galileo single-frequency receivers, follow these steps<ref name="DLR2022" /> for each satellite-user line-of-sight:
# Obtain receiver (φu, λu, hu) and satellite (φs, λs, hs) positions, and Universal Time (UT), in terms of time of day and month.
# Compute Effectiove Ionization Level Azpar using the broadcast coefficients (aᵢ₀, aᵢ₁, aᵢ₂).
# Calculate satellite elevation (E) and azimuth (A) angles.
# Determine ionospheric pierce point location (φpp, λpp) for the user-to-satellite link at 450km height, and Local Time (LT).
# Use NTCM-G to compute VTEC at (φpp, λpp), LT.
# Calculate mapping function (MF).
# Convert VTEC to STEC using the MF.
# Compute delay using equation for If for the corresponfing frequency to obtain the correction.
# Apply correction to pseudorange.
# Repeat for each satellite.

Under normal ionospheric conditions, variations occur slowly, making high-rate recomputation of delay corrections unnecessary for most applications. A 30-second update interval is generally adequate for stationary receivers or pedestrian users applying the NTCM-G ionospheric model.<ref name="DLR2022" />.

=== Performance ===
The performance of the NTCM-G model has been validated and compared to the NeQuick-G model. Results indicate that NTCM-G provides generally comparable and sometimes slightly better performance than NeQuick-G<ref name="DLR2022" />. Validation includes comparisons with ground-based VTEC maps from IGS (International GNSS Service), STEC observations, and SPP-based (Single Point Positioning) 3D positioning errors under various geographic and solar activity conditions.

::[[File: VTEC_RMS_NeQuick_vs_NTCM.png |800px|center|thumb|'''''Figure 1:''''' VTEC RMS residual error distribution in 2014 and 2015 for daytime hours 12-15 LT for NeQuick-G (left panel) and NTCM (right panel) <ref>M. M. Hoque, N. Jakowski, y J. A. Cahuasqui, «Fast Ionospheric Correction Algorithm for Galileo Single Frequency Users», 2020 Eur. Navig. Conf. ENC, pp. 1-10, nov. 2020, doi: 10.23919/ENC48637.2020.9317502.</ref> ]]
==References==
<references/>

NTCM G Ionospheric Model

2025-04-30T09:07:44Z

Natalia.Castrillo:

{{Article Infobox2
|Category=Fundamentals
|Authors=
|Level=Intermediate
|YearOfPublication=2025
|Title={{PAGENAME}}
}}
__TOC__
The '''NTCM G''' (Neustrelitz Total Electron Content Model) ionospheric model is designed to compute ionospheric corrections based on the broadcast coefficients in the navigation message for Galileo single-frequency users. NTCM-G is proposed as an alternative to the [[NeQuick_Ionospheric_Model|NeQuick-G ionospheric model]], whose high computational load poses a constraint in those user-segments where the user equipment has limited resources available. This is typically the case of the receivers used in civil aviation and location-based services (e.g., smartphones, UAVs, IoT devices).
The NTCM is an empirical model designed to provide a practical and cost-effective solution for estimating global TEC (Total Electron Content). It relies on 12 model coefficients (k₁ to k₁₂), a few fixed empirical parameters, and the solar radio flux index F10.7. To use the NTCM with the broadcast Galileo Effective Ionisation Level coefficients of the navigation message (aᵢ₀, aᵢ₁, aᵢ₂)<ref name="ICD2021">[https://galileognss.eu/wp-content/uploads/2021/01/Galileo_OS_SIS_ICD_v2.0.pdf EU, SIGNAL-IN-SPACE INTERFACE CONTROL DOCUMENT, Issue 2.0, enero de 2021]</ref>, the F10.7 solar index is replaced by the term '''Azpar'''. This term is used as a proxy measure of the solar activity level and is determined as follows:
<math>
Azpar = \left| \sqrt{a_{i0}^2 + 1633.33 \cdot a_{i1}^2 + 4802000 \cdot a_{i2}^2 + 3266.67 \cdot a_{i0} \cdot a_{i2}} \right|
</math>

Where (aᵢ₀, aᵢ₁, aᵢ₂) are the three Effective Ionisation Level coefficients broadcast in the Galileo navigation message. The Azpar term is used to account for the solar activity dependency (F₅) in the estimation of VTEC (Vertical Total Electron Content) explained below.
NTCM-G modeling approach consists of five major dependencies of TEC:
* Local time dependency (F₁)
* Seasonal dependency (F₂)
* Geomagnetic field dependency (F₃)
* Equatorial anomaly dependency (F₄)
* Solar activity dependency (F₅)

The dependencies are combined in a multiplicative way to compute a value of the VTEC:

<math>
VTEC_{NTCM-G} = F_1 \cdot F_2 \cdot F_3 \cdot F_4 \cdot F_5
</math>

Each Fi factor contains the model coefficients (k₁ to k₁₂) for its computation, whose values are provided in Table 3 of the model description document<ref name="DLR2022">[https://www.gsc-europa.eu/sites/default/files/NTCM-G_Ionospheric_Model_Description_-_v1.0.pdf DLR, NTCM-G Ionospheric Model Description, mayo de 2022]</ref>.

===Input parameters===
The input parameters required by the NTCM-G model to estimate each TEC dependency (F₁ to F₅), and consequently the VTEC value, include:
* Galileo Effective Ionisation Level coefficients (aᵢ₀, aᵢ₁, aᵢ₂)
* User receiver and satellite positions in WGS-84 ellipsoidal coordinates (φu, λu, hu) and (φs, λs, hs)
* Universal Time (UT)
* Day of Year (doy)
The output of NTCM-G is the VTEC in TECU for each line of sight between satellite and receiver.
The estimated VTEC output can be converted to STEC (Slant Total Electron Content) using the following equation:

<math>
STEC = MF_{MSLM} \cdot VTEC_{NTCM-G}
</math>

Where the Modified Single Layer Model (MSLM) mapping function is:

<math>
MF_{MSLM} = \frac{1}{\sqrt{1 - (\sin z)^2}}
</math>

<math>
\sin z = \frac{R_e}{R_e + h_I} \cdot \sin(0.9782 \cdot (\frac{\pi}{2} - E))
</math>

With:
* Re = 6371 km (Earth's mean radius)
* hI = 450 km (ionospheric pierce point height)
* E = satellite elevation angle in radians

=== Ionospheric Delay Calculation ===
Once the STEC is estimated, the ionospheric propagation delay (in meters) can be computed:

<math>
I_f = \frac{40.3 \cdot 10^{16}}{f^2} \cdot STEC
</math>

Where:
* ''f'' is the signal frequency in Hz
* The constant 40.3 is in m³/s²/electrons
* 1016 converts TECU to electrons/m²

Higher-order ionospheric terms are generally neglected due to their small magnitude (e.g., < 20 cm for Galileo E1)<ref name="Hoque2008">M. M. Hoque y N. Jakowski, "Estimate of higher order ionospheric errors in GNSS positioning", Radio Sci., vol. 43, no. 5, 2008, doi:10.1029/2007RS003817.</ref>.

=== Algorithm Steps ===
To implement the ionospheric correction using NTCM-G for Galileo single-frequency receivers, follow these steps<ref name="DLR2022" /> for each satellite-user line-of-sight:
# Obtain receiver (φu, λu, hu) and satellite (φs, λs, hs) positions, and Universal Time (UT), in terms of time of day and month.
# Compute Effectiove Ionization Level Azpar using the broadcast coefficients (aᵢ₀, aᵢ₁, aᵢ₂).
# Calculate satellite elevation (E) and azimuth (A) angles.
# Determine ionospheric pierce point location (φpp, λpp) for the user-to-satellite link at 450km height, and Local Time (LT).
# Use NTCM-G to compute VTEC at (φpp, λpp), LT.
# Calculate mapping function (MF).
# Convert VTEC to STEC using the MF.
# Compute delay using equation for If for the corresponfing frequency to obtain the correction.
# Apply correction to pseudorange.
# Repeat for each satellite.

Under normal ionospheric conditions, variations occur slowly, making high-rate recomputation of delay corrections unnecessary for most applications. A 30-second update interval is generally adequate for stationary receivers or pedestrian users applying the NTCM-G ionospheric model.<ref name="DLR2022" />.

=== Performance ===
The performance of the NTCM-G model has been validated and compared to the NeQuick-G model. Results indicate that NTCM-G provides generally comparable and sometimes slightly better performance than NeQuick-G<ref name="DLR2022" />. Validation includes comparisons with ground-based VTEC maps from IGS (International GNSS Service), STEC observations, and SPP-based (Single Point Positioning) 3D positioning errors under various geographic and solar activity conditions.

::[[File: VTEC_RMS_NeQuick_vs_NTCM.png |800px|center|thumb|'''''Figure 1:''''' VTEC RMS residual error distribution in 2014 and 2015 for daytime hours 12-15 LT for NeQuick-G (left panel) and NTCM (right panel) <ref>M. M. Hoque, N. Jakowski, y J. A. Cahuasqui, «Fast Ionospheric Correction Algorithm for Galileo Single Frequency Users», 2020 Eur. Navig. Conf. ENC, pp. 1-10, nov. 2020, doi: 10.23919/ENC48637.2020.9317502.</ref> ]]
==References==
<references/>