A.4.2 Elements

3GPP44.031Location Services (LCS)Mobile Station (MS) - Serving Mobile Location Centre (SMLC) Radio Resource LCS Protocol (RRLP)Release 17TS

A.4.2.1 E-OTD Reference BTS for Assistance Data Element

This element is conditional. It is as described in sub-clause 2.2.3. If the network can provide assistance data, and data for E-OTD has been requested, this element is included.

A.4.2.2 E-OTD Measurement Assistance Data Element

This element is conditional. It is as described in sub-clause 2.2.4. If the network can provide assistance data, and data for E-OTD has been requested, this element is included.

A.4.2.3 E-OTD Measurement Assistance Data for System Information List Element

This element is conditional. It is as described in sub-clause 2.2.5. If the network can provide assistance data, and data for E-OTD has been requested, this element is included.

A.4.2.4 GPS Assistance Data Element

The GPS Assistance Data element contains a single GPS assistance message that supports both MS-assisted and MS-based GPS methods. This element can contain one or more of the fields listed in table A.12 below, which support both MS-assisted and MS-based GPS methods. As table A.12 shows, all fields are optional.

Note that certain types of GPS Assistance data may be derived, wholly or partially, from other types of GPS Assistance data.

In addition, an Integrity Monitor (IM) shall detect unhealthy (e.g., failed/failing) satellites and also shall inform users of measurement quality in DGPS modes when satellites are healthy. Excessively large pseudo range errors, as evidenced by the magnitude of the corresponding DGPS correction, shall be used to detect failed satellites. Unhealthy satellites should be detected within 10 seconds of the occurrence of the satellite failure. When unhealthy (e.g., failed/failing) satellites are detected, the assistance and/or DGPS correction data shall not be supplied for these satellites. When the error in the IM computed position is excessive for solutions based upon healthy satellites only, DGPS users shall be informed of measurement quality through the supplied UDRE values. After bad satellites have been indicated in the Real Time Integrity field, if the satellites return to healthy condition for some period of time, the indications for them shall be removed from this field.

Table A.12: Fields in the GPS Assistance Data element

Parameter	Presence	Repetition
Reference Time	O	Yes
Reference Location	O	No
DGPS Corrections	O	Yes
Navigation Model	O	Yes
Ionospheric Model	O	No
UTC Model	O	No
Almanac	O	Yes
Acquisition Assistance	O	Yes
Real-Time Integrity	O	Yes

When RRLP pseudo-segmentation is used, Table A.12 indicates which parameters may be repeated in more than one RRLP segment in order to provide data for multiple satellites. When any such parameter appears in more than one segment, the following rules shall apply.

1. There shall be no repetition of data for the same satellite.

2. Optional and conditional elements in the parameter not associated with a particular satellite shall each appear in at most one RRLP segment.

3. Any mandatory element not associated with a particular satellite shall assume consistent values in the case of an element related to current GPS time and the same value otherwise.

4. The maximum number of satellites defined in sub-clause 5.1 for which data can be included for any parameter in one RRLP segment shall apply also when counted over all RRLP segments.

Reference Time

These fields specify the relationship between GPS time and air-interface timing of the BTS transmission in the reference cell. These fields occur once per message; some are mandatory and some are conditional, as shown in table A.14. Note that Reference Time may also be present within the Acquisition Assistance parameter. In such a case, the SMLC shall ensure consistency.

Table A.14: Reference Time (Fields occurring once per message)

Parameter	# Bits	Scale Factor	Range	Units	Incl.
GPS Week	10	1	0 – 1023	weeks	M
GPS TOW	23	0,08	0-604799,92	sec	M
BCCH Carrier	10	1	0 – 1023	—	O (note 1)
BSIC	6	1	0 – 63	—	O (note 1)
FNm	21	1	0 – (221-1)	frames	O (note 1)
TN	3	1	0 – 7	timeslots	O (note 1)
BN	8	1	0 – 156	bits	O (note 1)
GPS TOW Assist	24*N_SAT	—	—-	—	O
NOTE 1: All of these fields shall be present together, or none of them shall be present.

GPS Week

This field specifies the GPS week number of the assistance being provided. GPS Week eliminates one-week ambiguities from the time of the GPS assistance. This field is mandatory.

NOTE: The number of 1024 week cycles since the GPS zero time-point is provided in the GPS Reference Time Extension in Table A.29u.

GPS TOW

The GPS TOW (time-of-week) is a mandatory field and is specified with 80 msec resolution. When GSM Time Present is "1", GPS TOW and BCCH/BSIC/FNm/TN/BN IEs provide a valid relationship between GPS and GSM time, as seen at the approximate location of the MS, ie the propagation delay from BTS to MS shall be compensated for by the SMLC. Depending on implementation, the relation between GPS and GSM time may have varying accuracy. Therefore, the uncertainty of the timing relation may be provided in the optional field GPS Reference Time Uncertainty. If the propagation delay from BTS to MS is not accurately known, the SMLC shall use the best available approximation of the propagation delay and take the corresponding delay uncertainty into account in the calculation of the field GPS Reference Time Uncertainty. When GSM Time Present is "0", GPS TOW is an estimate of current GPS time of week at time of reception of the RRLP segment containing this data by the MS. The SMLC should achieve an accuracy of +/- 3 seconds for this estimate including allowing for the transmission delay between SMLC and MS of the RRLP segment containing GPS TOW. Note that the MS should further compensate GPS TOW for the time between the reception of the segment containing GPS TOW and the time when the GPS TOW field is used.

BCCH Carrier/BSIC/FNm/TN/BN

These fields specify the state of the GSM frame number, timeslot number, and bit number, respectively, of the reference BTS with the specified BCCH carrier and BSIC at the time that correspond to GPS TOW. The SMLC shall use the current serving BTS as the reference BTS. The frame number field is given modulo 2²¹, i.e., the MSB of the GSM frame number is truncated. The MS shall interpret FNm as the most recent of the two possible frame numbers that FNm could represent. The target MS has the option of rejecting a GPS position request or GPS assistance data if the reference BTS is not the serving BTS.

GPS TOW Assist

This field contains several fields in the Telemetry (TLM) Word and Handover Word (HOW) that are currently being broadcast by the respective GPS satellites. Combining this information with GPS TOW enables the MS to know the entire 1,2-second (60-bit) pattern of TLM and HOW that is transmitted at the start of each six-second subframe by the particular GPS satellite. This field contains information for each of N_SAT satellites, and optional. The individual fields for each satellite in the message are shown in table A.15a.

Table A.15a: GPS TOW Assist (Fields occurring N_SAT times per message)

Parameter	# Bits	Scale Factor	Range	Units	Incl.
SatID	6	—	0 – 63	—	M
TLM Message	14	—	0 – 16383	Bit field	M
Anti-Spoof	1	1	0 -1	Bit field	M
Alert	1	1	0 – 1	Bit field	M
TLM Reserved	2	—	0 – 3	Bit field	M

SatID

This field identifies the satellite for which the corrections are applicable. The values ranging from 0 to 63 represent satellite PRNs ranging from 1 to 64, respectively.

TLM Message

This field contains a 14-bit value representing the Telemetry Message (TLM) being broadcast by the GPS satellite identified by the particular SatID, with the MSB occurring first in the satellite transmission.

Anti-Spoof/Alert

These fields contain the Anti-Spoof and Alert flags that are being broadcast by the GPS satellite identified by SatID.

TLM Reserved

These fields contain the two reserved bits in the TLM Word being broadcast by the GPS satellite identified by SatID, with the MSB occurring first in the satellite transmission.

Reference Location

The Reference Location field contains a 3-D location (with uncertainty) specified as per 3GPP TS 23.032. The purpose of this field is to provide the MS with a priori knowledge of its location in order to improve GPS receiver performance. The allowed shape is 3-D location with uncertainty (ellipsoid point with altitude and uncertainty ellipsoid).

DGPS Corrections

These fields specify the DGPS corrections to be used by the MS. All fields are mandatory when DGPS Corrections are present in the GPS Assistance Data.

Table A.15: DGPS Corrections

Parameter	# Bits	Scale Factor	Range	Units	Incl.
The following fields occur once per message
GPS TOW	20	1	0 – 604799	sec	M
Status/Health	3	1	0-7	—	M
N_SAT	4	1	1-16	—	M
The following fields occur once per satellite (N_SAT times)
SatID	6	—	0 – 63	—	M
IODE	8	—	0 – 255	—	M
UDRE	2	—	0 – 3	—	M
PRC	12	0,32	655,04	meters	M
RRC	8	0,032	4,064	meters/sec	M
Delta PRC2	8	—	—	—	M
Delta RRC2	4	—	—	—	M
Delta PRC3	8	—	—	—	M
Delta RRC3	4	—	—	—	M

GPS TOW

This field indicates the baseline time for which the corrections are valid.

Status/Health

This field indicates the status of the differential corrections contained in the broadcast message. The values of this field and their respective meanings are shown below in table A.16.

Table A.16: Values of Status/Health IE

Code	Indication
000	UDRE Scale Factor = 1,0
001	UDRE Scale Factor = 0,75
010	UDRE Scale Factor = 0,5
011	UDRE Scale Factor = 0,3
100	UDRE Scale Factor = 0,2
101	UDRE Scale Factor = 0,1
110	Reference Station Transmission Not Monitored
111	Data is invalid – disregard

The first six values in this field indicate valid differential corrections. When using the values described below, the "UDRE Scale Factor" value is applied to the UDRE values contained in the message. The purpose is to indicate an estimate in the amount of error in the corrections.

The value "110" indicates that the source of the differential corrections (e.g., reference station or external DGPS network) is currently not being monitored. The value "111" indicates that the corrections provided by the source are invalid, as judged by the source. In the later case, the message shall contain no corrections for individual satellites. Any MS that receives DGPS Corrections in a GPS Assistance Data IE shall contain the appropriate logic to properly interpret this condition and look for the next IE.

N_SAT

This field indicates the number of satellites for which differential corrections are available. Corrections for up to 16 satellites.

SatID

This field identifies the satellite for which the corrections are applicable. The values ranging from 0 to 63 represent satellite PRNs ranging from 1 to 64, respectively.

IODE

This IE is the sequence number for the ephemeris for the particular satellite. The MS can use this IE to determine if new ephemeris is used for calculating the corrections that are provided in the broadcast message. This eight-bit IE identifies a particular set of ephemeris data for a GPS satellite and may occupy the numerical range of [0, 255]. The transmitted IODE value will be different from any value transmitted by the GPS satellite during the preceding six hours. For more information about this field can be found from RTCM-SC104.

User Differential Range Error (UDRE)

This field provides an estimate of the uncertainty (1-) in the corrections for the particular satellite. The value in this field shall be multiplied by the UDRE Scale Factor in the common Corrections Status/Health field to determine the final UDRE estimate for the particular satellite. The meanings of the values for this field are described in table A.18.

Table A.18: Values of UDRE IE

Value	Indication
00	UDRE  1,0 m
01	1,0 m < UDRE  4,0 m
10	4,0 m < UDRE  8,0 m
11	8,0 m < UDRE

Each UDRE value shall be adjusted based on the operation of an Integrity Monitor (IM) function which exists at the network (SMLC, GPS server, or reference GPS receiver itself). Positioning errors derived at the IM which are excessive relative to DGPS expected accuracy levels shall be used to scale the UDRE values to produce consistency.

Pseudo-Range Correction (PRC)

This field indicates the correction to the pseudorange for the particular satellite at the GPS Reference Time, t₀. The value of this field is given in meters (m) and the resolution is 0,32, as shown in table A.15 above. The method of calculating this field is described in [9].

If the SMLC has received a request for GPS assistance data from an MS which included a request for the navigation models and DGPS (i.e., bit D and E are set to one in ‘Requested GPS Assistance Data, see 3GPP TS 49.031), the SMLC shall determine, for each satellite, if the navigation model stored by the MS is still suitable for use with DGPS corrections (also see navigation model update conditions right before Table A.19) and if so and if DGPS corrections are supported the SMLC should send DGPS corrections without including the navigation model.

The IODE value sent for a satellite shall always be the IODE value that corresponds to the navigation model for which the pseudo-range corrections are applicable.

The pseudo-range correction shall correspond to the available navigation model (the one already stored in and identified by the MS or the one included in the same procedure as the pseudo-range correction). The MS shall only use the PRC value when the IODE value received matches its available navigation model.

Pseudo-Range Rate Correction (RRC)

This field indicates the rate-of-change of the pseudorange correction for the particular satellite, using the satellite ephemeris identified by the IODE IE. The value of this field is given in meters per second (m/sec) and the resolution is 0,032, as shown in table A.15 above. For some time t₁ > t₀, the corrections for IODE are estimated by

PRC(t_{1, IODE}) = PRC(t_{0, IODE}) + RRC(t_{0, IODE})(t₁ – t₀) ,

and the MS uses this to correct the pseudorange it measures at t₁, PR_m(t_1, IODE), by

PR(t_{1, IODE}) = PR_m(t_{1, IODE}) + PRC(t_{1, IODE}) .

The SMLC shall always send the RRC value that corresponds to the PRC value that it sends (see above for details). The MS shall only use the RRC value when the IODE value received matches its available navigation model.

Delta Pseudo-Range Correction 2 (Delta PRC2)

This IE is not used. The sender shall set it to zero and the receiver shall ignore it.

Delta Pseudo-Range Rate Correction 2 (Delta RRC2)

This IE is not used. The sender shall set it to zero and the receiver shall ignore it.

Delta Pseudo-Range Correction 3 (Delta PRC3)

This IE is not used. The sender shall set it to zero and the receiver shall ignore it.

Delta Pseudo-Range Rate Correction 3 (Delta RRC3)

This IE is not used. The sender shall set it to zero and the receiver shall ignore it.

Navigation Model

This set of fields contains information required to manage the transfer of precise navigation data to the GPS-capable MS. In response to a request from an MS for GPS assistance data, the SMLC shall determine whether to send the navigation model for a particular satellite to an MS based upon factors like the T-Toe limit specified by the MS and any request from the MS for DGPS (also see above). This information includes control bit fields as well as satellite ephemeris and clock corrections. The individual fields are given in Table A.19 below, and the conditions for their presence is discussed below.

Table A.19: Navigation Model (per-satellite fields – ⁽¹⁾ = Positive range only)

Parameter	# Bits	Scale Factor	Units	Incl.
Navigation Model Flow Control (once per message)
Num_Sats_Total	4(1)	1	—	M
Satellite and Format Identification (once per satellite)
SatID	6(1)	—	—	M
Satellite Status	2	—	Boolean	M
Satellite Navigation Model and Associated Bits (once per satellite)
C/A or P on L2	2	—	Boolean	C
URA Index	4	—	Boolean	C
SV Health	6	—	Boolean	C
IODC	10(1)	—	—	C
L2 P Data Flag	1	—	Boolean	C
SF 1 Reserved	87	—	—	C
TGD	8	2-31	sec	C
toc	16(1)	24	sec	C
af2	8	2-55	sec/sec2	C
af1	16	2-43	sec/sec	C
af0	22	2-31	sec	C
Crs	16	2-5	meters	C
n	16	2-43	semi-circles/sec	C
M0	32	2-31	semi-circles	C
Cuc	16	2-29	radians	C
e	32(1)	2-33	—	C
Cus	16	2-29	radians	C
(A)1/2	32(1)	2-19	meters1/2	C
toe	16(1)	24	sec	C
Fit Interval Flag	1	—	Boolean	C
AODO	5	900	sec	C
Cic	16	2-29	radians	C
OMEGA0	32	2-31	semi-circles	C
Cis	16	2-29	radians	C
i0	32	2-31	semi-circles	C
Crc	16	2-5	meters	C
	32	2-31	semi-circles	C
OMEGAdot	24	2-43	semi-circles/sec	C
Idot	14	2-43	semi-circles/sec	C

Num_Sats_Total

This field specifies the number of satellites that are included in the provided Navigation Model. A range of 1-16 is available. This field is mandatory when the Navigation Model field is included in the message.

SatID

This field identifies the satellite for which the assistance is applicable. This value is the same as the PRN number provided in the navigation message transmitted by the particular satellite. The range is 0 to 63, with 0-31 indicating GPS satellites 1-32, respectively, and 32-63 indicating satellites in future augmentation systems (e.g., WAAS or EGNOS). This field is mandatory for each included satellite.

Satellite Status

This field is a two-bit value that indicates the status of the Navigation Model for the particular satellite specified by SatID. This field is mandatory for each included satellite. The MS shall interpret the combinations of the two bits as follows.

Table A.20: Satellite Status (per-satellite field)

MSB	LSB	Interpretation
0	0	New satellite, new Navigation Model
0	1	Existing satellite, same Navigation Model
1	0	Existing satellite, new Navigation Model
1	1	Reserved

This Satellite Navigation Model and associated bit fields include the parameters that accurately model the orbit and clock state of the particular satellite. For the particular satellite, these fields are conditional based on the value of Satellite Status for that satellite. The fields are absent when Satellite Status is "01", and present for all other values. The format for the ephemeris, clock corrections, and associate bits are specified in ICD-GPS-200.

Ionospheric Model

The Ionospheric Model contains fields needed to model the propagation delays of the GPS signals through the ionosphere. The information elements in this field are shown in table A.21. Proper use of these fields allows a single‑frequency GPS receiver to remove approximately 50 % of the ionospheric delay from the range measurements. The Ionospheric Model is valid for the entire constellation and changes slowly relative to the Navigation Model. All of the fields must be included when Ionospheric Model is present.

Table A.21: Ionospheric Model (occurs once per message, when present)

Parameter	# Bits	Scale Factor	Units	Incl.
0	8	2-30	seconds	C
1	8	2-27	sec/semi-circle	C
2	8	2-24	sec/(semi-circle)2	C
3	8	2-24	sec/(semi-circle)3	C
0	8	211	seconds	C
1	8	214	sec/semi-circle	C
2	8	216	sec/(semi-circle)2	C
3	8	216	sec/(semi-circle)3	C

UTC Model

The UTC Model field contains a set of parameters needed to relate GPS time to Universal Time Coordinate (UTC). All of the fields in the UTC Model are mandatory when the field is present.

Table A.22: UTC Model (occurs once per message,
when present per-satellite fields – ⁽¹⁾ = Positive range only)

Parameter	# Bits	Scale Factor	Units	Incl.
A1	24	2-50	sec/sec	C
A0	32	2-30	seconds	C
tot(1)	8	212	seconds	C
WNt(1)	8	1	weeks	C
tLS	8	1	seconds	C
WNLSF(1)	8	1	weeks	C
DN	8	1	days	C
tLSF	8	1	seconds	C

Almanac

These fields specify the coarse, long-term model of the satellite positions and clocks. These fields are given in table A.23. With one exception (i), these parameters are a subset of the ephemeris and clock correction parameters in the Navigation Model, although with reduced resolution and accuracy. The almanac model is useful for receiver tasks that require coarse accuracy, such as determining satellite visibility. The model is valid for up to one year, typically. Since it is a long-term model, the field should be provided for all satellites in the GPS constellation. If almanac is not provided for the full GPS constellation, the SMLC shall set the Complete Almanac Provided field in Table A.29w to FALSE. All fields in the Almanac are mandatory when the Almanac is present. The fields t_oa and WN_a specify the GPS time-of-week and week number, respectively, that are the reference points for the Almanac parameters.

The Almanac also is useful as an acquisition aid for network-based GPS methods. Given a recent Almanac (< 3‑4 weeks old), the MS only needs Reference Time and Reference Location information to quickly acquire the signals and return measurements to the network.

The Almanac also contains information about the health of that satellite as described in ICD-GPS-200. If this Alamanc has been captured from the satellite signal, the SV Health field represents the predicted satellite health at the time the GPS control segment uploaded the Almanac to the satellite. According to ICD-GPS-200, this health information may differ from the SV Health field in the Navigation Model (table A.19) due to different upload times.

The parameters Num_Sats_Total and SatID shall be interpreted in the same manner as described under table A19.

Table A.23: Almanac (per-satellite fields – ⁽¹⁾ = Positive range only)

Parameter	# Bits	Scale Factor	Units	Incl.
The following fields occur once per message
Num_Sats_Total	6(1)	1	—	M
WNa	8(1)	1	weeks	M
The following fields occur once per satellite
SatID	6(1)	—	—	M
e(1)	16	2-21	dimensionless	M
toa(1)	8	212	sec	M
i	16	2-19	semi-circles	M
OMEGADOT	16	2-38	semi-circles/sec	M
SV Health	8	—	Boolean	M
A1/2(1)	24	2-11	meters1/2	M
OMEGA0	24	2-23	semi-circles	M
	24	2-23	semi-circles	M
M0	24	2-23	semi-circles	M
af0	11	2-20	seconds	M
af1	11	2-38	sec/sec	M

Acquisition Assistance

The Acquisition Assistance field of the GPS Assistance Data Information Element contains parameters that enable fast acquisition of the GPS signals in network-based GPS positioning. Essentially, these parameters describe the range and derivatives from respective satellites to the Reference Location at the Reference Time. Table A.24 illustrates the assistance data occurring once per message and table A.25 illustrates the assistance data occurring per number of satellites for which acquisition assistance is being provided. Figure A.2 illustrates the relation between some of the fields.

This field is optional. The field would probably appear when the Method Type field of the Positioning Instructions IE is set to 0 (MS-Assisted) and the Positioning Methods field of the Position Instructions IE is set to 1 (GPS) or 2 (GPS or E-OTD).

Table A.24: GPS Acquisition Assist – Parameters appearing once per message

Parameter		Range	Bits	Resolution	Incl.	Notes
Number of Satellites		0 – 15	4		M
Reference Time	GPS TOW	0 -604799,92 sec	23	0,08 sec	M
	BCCH Carrier	0 – 1023	10		O1
	BSIC	0 – 63	6		O1
	Frame #	0 – 2097151	21		O1
	Timeslots #	0 – 7	3		O1
	Bit #	0 – 156	8		O1
NOTE: All of these field shall be present together, or none of them shall be present.

Table A.25: GPS Acquisition Assist – Parameters appearing [number of satellites] times per message

Parameter	Range	Bits	Resolution	Incl.	Notes
SVID/PRNID	1 – 64 (0 – 63 )	6		M
Doppler (0th order term)	-5120 Hz to 5117,5 Hz	12	2,5 Hz	M
Doppler (1st order term)	-1,0 – 0,5 Hz/sec.	6	1/42 Hz/sec.	O1
Doppler Uncertainty	12.5 Hz – 200 Hz [2-n(200) Hz, n = 0 – 4]	3		O1,3
Code Phase	0 – 1022 chips	10	1 chip	M
Integer Code Phase	0-19	5	1 C/A period	M
GPS Bit number	0 – 3	2		M
Code Phase Search Window	1 – 192 chips	4		M
Azimuth	0 – 348,75 deg	5	11,25 deg	O2
Elevation	0 – 78,75 deg	3	11,25 deg	O2
NOTE 1: Both of these fields shall be present together, or none of them shall be present. NOTE 2: Both of these fields shall be present together, or none of them shall be present. NOTE 3: If Doppler Uncertainty Extension (Table A.29x) is present, Doppler Uncertainty shall be set to value 0 (200 Hz).

Figure A.2. Exemplary calculations of Acquisition Assistance fields.

This field indicates whether or not angle information is present in this message. The MS shall interpret a value of "1" to mean that angle (Azimuth and Elevation) information is present, and "0" to mean that it is not provided. This field is mandatory.

Number of Satellites

This field contains the number of satellites identified in this information element. This field is mandatory.

Range: 0 – 15

Reference Time

The Reference Time field of the GPS Acquisition Assistance Data IE specifies the relationship between GPS time and air-interface timing of the BTS transmission in the reference cell.

GPS TOW subfield specifies the GPS TOW for which the location estimate is valid. When the parameters BCCH Carrier/BSIC/Frame #/Timeslots #/Bit # are present, together with GPSTOW they provide a valid relationship between GPS and GSM time, as seen at the approximate location of the MS, ie the propagation delay from BTS to MS shall be compensated for by the SMLC. Depending on implementation, the relation between GPS and GSM time may have varying accuracy. The uncertainty of the timing relation may be provided in the optional field GPS Reference Time Uncertainty. If the propagation delay from BTS to MS is not accurately known, the SMLC shall use the best available approximation of the propagation delay and take the corresponding delay uncertainty into account in the calculation of the field GPS Reference Time Uncertainty. GPS TOW is mandatory when the GPS Acquisition Assistance Data Information Element is included. When the GSM time parameters are not present the GPS TOW is an estimate of current GPS time of week at time of reception of the RRLP segment containing the GPS TOW by the MS. The SMLC should achieve an accuracy of +/- 3 seconds for this estimate including allowing for the transmission delay between SMLC and MS of the RRLP segment containing GPS TOW. Note that the MS should further compensate GPS TOW for the time between the reception of the segment containing GPS TOW and the time when the GPS TOW field is used.

Range: 0 – 604799,92 sec

The BCCH Carrier # and BSIC subfields specify the reference cell for which GSM timing is provided. These subfields are optional when the GPS Acquisition Assistance Data Information Element is included. If included, the SMLC shall set the reference cell to the current serving cell. A target MS has the option of rejecting a GPS position request or GPS assistance data if the reference cell is not the serving cell.

The Frame # subfield specifies the GSM frame number of the BTS transmissions for the reference cell that occur at the given GPS TOW. This subfield is optional when the GPS Acquisition Assistance Data Information Element is included.

Range: 0 – 2097151

The Timeslots # subfield specifies the GSM timeslot of the BTS transmissions for the reference cell that occur at the given GPS TOW. This subfield is optional when the GPS Acquisition Assistance Data Information Element is included.

Range: 0 – 7

The Bit # subfield specifies the GSM and bit number of the BTS transmissions for the reference cell that occur at the given GPS TOW. This subfield is optional when the GPS Acquisition Assistance Data Information Element is included.

Range: 0 – 156

SVID/PRNID

This field identifies the particular satellite for which the measurement data is supplied. This value is the same as the PRN number provided in the navigation message transmitted by the particular satellite.

The range is 0 to 63, where SVID = PRNID – 1

Doppler (0^th order term)

This field contains the Doppler (0^th order term) value. A positive value defines the increase in satellite signal frequency due to velocity towards the MS. A negative value defines the decrease in satellite signal frequency due to velocity away from the MS. This field is mandatory.

Range: 5120 Hz to 5117,5 Hz

Doppler (1^st order term)

This field contains the Doppler (1^st order term) value. A positive value defines the rate of increase in satellite signal frequency due to acceleration towards the MS. A negative value defines the rate of decrease in satellite signal frequency due to acceleration away from the MS. This field is optional.

Range: -1,0 Hz to 0,5 Hz / s

Doppler Uncertainty

This field contains the Doppler uncertainty value. It is defined such that the Doppler experienced by a stationary MS is in the range "Doppler  Doppler Uncertainty" to "Doppler  Doppler Uncertainty". This field is optional. If Doppler Uncertainty (together with Doppler 1^st order term) is omitted, the terminal shall interpret Doppler Uncertainty as greater than +/-200 Hz. If the Doppler Uncertainty Extension (Table A.29x) field is present, the MS that supports the Doppler Uncertainty Extension shall ignore this field.

Permitted Values: 12,5 Hz, 25 Hz, 50 Hz, 100 Hz, 200 Hz as encoded by an integer n in the range 0-4 according to the formula in Table A.25

Code Phase

This field contains code phase, in units of 1 GPS chip, in the range from 0 to 1022 GPS chips, where increasing binary values of the field signify increasing predicted pseudoranges, as seen by a receiver at the Reference Location at the time GPS TOW. The Reference Location would typically be an apriori estimate of the MS location. This field is mandatory.

Range: 0-1022 chips

Integer Code Phase

This field contains integer code phase, i.e. the number of the code periods that have elapsed since the latest GPS bit boundary, in units of C/A code period, as seen by a receiver at the Reference Location at the time GPS TOW. This field is mandatory.

Range: 0-19

GPS Bit Number

This field contains GPS bit number (expressed modulo 4) currently being transmitted at the time GPS TOW, as seen by a receiver at the Reference Location. This field is mandatory.

Range: 0-3

Code Phase Search Window

This field contains the code phase search window. The code phase search window accounts for the uncertainty in the estimated MS location but not any uncertainty in GPS TOW. It is defined such that the expected code phase is in the range "Code Phase – Code Phase Search Window" to "Code Phase + Code Phase Search Window". This field is mandatory.

Range: 0-15 (i.e. 1-512 chips according to following table)

Table A.26: Code Phase Search Window Parameter Format

CODE_PHASE_WIN	Code Phase Search Window (GPS chips)
‘0000’	512
‘0001’	1
‘0010’	2
‘0011’	3
‘0100’	4
‘0101’	6
‘0110’	8
‘0111’	12
‘1000’	16
‘1001’	24
‘1010’	32
‘1011’	48
‘1100’	64
‘1101’	96
‘1110’	128
‘1111’	192

Azimuth

This field together with the Azimuth LSB included in Acquisition Assistance Extension in Table A.29v contains the azimuth angle. An angle of x degrees means the satellite azimuth a is in the range (x  a < x+0,703125) degrees. This field is optional.

Range: 0 – 359,296875 degrees.

Elevation

This field together with the Elevation LSB included in Acquisition Assistance Extension in Table A.29v contains the elevation angle. An angle of y degrees means the satellite elevation e is in the range (y  e < y+0,703125) degrees except for y = 89,296875 where the range is extended to include 90 degrees. This field is optional.

Range: 0 – 89,296875 degrees

Real-Time Integrity

The Real-Time Integrity field of the GPS Assistance Data Information Element contains parameters that describe the real-time status of the L1C/A signal in GPS constellation. Primarily intended for non-differential applications, the real-time integrity of the satellite constellation is of importance as there is no differential correction data by which the mobile can determine the soundness of each satellite signal. The Real-Time GPS Satellite Integrity data communicates the health of the L1C/A signal to the mobile in real-time. The format is shown in table A.29. The SMLC shall always transmit the Real Time Integrity field with the current list of satellites with unhealthy L1C/A signal, for any A-GPS positioning attempt and whenever A-GPS assistance data is sent. The same applies for GANSS positioning attempt and assistance data when modernized GPS is involved. If the number of bad satellites (NBS) is zero, then the Real Time Integrity field shall be omitted. When the Extended Reference IE is included in the RRLP Measure Position Request message or in the RRLP Assistance Data message, then the MS shall interpret the absence of a Real Time Integrity field in the assistance data provided by the SMLC to mean that NBS is zero. If the Extended Reference IE is not present, this interpretation applies when the assistance data is provided by the SMLC following a previous request of the MS for Real Time Integrity data.

Table A.29: Real-Time Integrity – Parameters appearing NBS times

Parameter	# Bits	Scale Factor	Range	Units	Incl.
Bad_SVID	6	1	0-63	—	C

NBS (Number of Bad Satellites)

The NBS value indicates the number of satellite ID’s that follow. The user should not use the L1C/A signal of those satellites at this time in a fix. This NBS value is determined from the Bad_SVID list.

Bad_SVID

This six bit field appears NBS times, and indicates the SVID of satellites which L1C/A signal should not be used for fix by the user at this time. The values ranging from 0 to 63 represent satellite PRNs ranging from 1 to 64, respectively.

A.4.2.4a GPS Time Assistance Measurement Request Element

This element is optional and controls if the MS should return GPS time assistance measurements or not to the SMLC. The inclusion of this parameter implies use of measure Position Request The description is found in sub-chapter 2.2.4a.

A.4.2.4b GPS Reference Time Uncertainty Element

This element is conditional and provides the accuracy of the relation GPS and GSM time in the Acquisition Assistance in GPS Assistance Data Element. The interval, range and treatment is as described in sub-clause 2.2.4b.

A.4.2.4c Additional GPS Assistance Data

The Additional GPS Assistance Data Element contains additional GPS assistance data which are not included in the GPS Assistance Data Element. This element can contain one or more of the fields listed in Table A.29a below.

Table A.29a: Fields in the Additional GPS Assistance Data element

Parameter	Presence	Repetition
GPS Ephemeris Extension	O	Yes
GPS Ephemeris Extension Check	O	Yes
DGPS Corrections Validity Period	O	Yes
GPS Reference Time Extension	O	No
GPS Acquisition Assistance Extension	O	Yes
GPS Almanac Extension	O	No
GPS Acquisition Assistance Extension-R12	O	Yes

When RRLP pseudo-segmentation is used, Table A.29a indicates which parameters may be repeated in more than one RRLP segment in order to provide data for multiple satellites. When any such parameter appears in more than one segment, the following rules shall apply.

1. There shall be no repetition of the same data for the same satellite, even though there might be multiple realizations of the IEs for the same satellite. For example, GPS Ephemeris Extension may occur multiple times for the same satellite, but with different data content.

2. Optional and conditional elements in the parameter not associated with a particular satellite shall each appear in at most one RRLP segment.

3. Any mandatory element not associated with a particular satellite shall assume consistent values in the case of an element related to current GPS time and the same value otherwise.

4. The maximum number of satellites defined in sub-clause 5.1 for which data can be included for any parameter in one RRLP segment shall apply also when counted over all RRLP segments.

GPS Ephemeris Extension

The GPS Ephemeris extension contains parameters designed to extend the time of applicability of the Ephemeris terms by the continuous addition of the delta ephemeris terms to the respective terms of the referenced ephemeris.

This message can provide extension information for every satellite for many days into the future; doing so may create a large message, thus care must be taken to consider the transport bandwidth. The SMLC can limit the duration of the extension to decrease the message size. For example if the extension duration is limited to twelve hours the payload will be approximately 2,000 octets, for a typical 27 satellite constellation.

Table A.29.b: GPS Ephemeris Extension

Parameter	# Bits	Scale Factor	Units	Incl.
gpsEphemerisHeader	See Table A.29.c		—	O
gpsReferenceSet	See Table A.29.e		—	O
ephemerisDeltaMatrix	List of GPSEphemerisDeltaEpochs			O

Table A.29.c: GPS Ephemeris Header

Parameter	# Bits	Scale Factor	Units	Incl.
GPS Ephemeris Extension (Once per message)
timeOfEstimation	See Table A.29.d		—	M
validityPeriod	3	1	Hours	M
ephemerisExtensionDuration	9	1	Hours	M

Time of Estimation

The GPS Time at Estimation provides the GPS time at which the ephemeris extensions were created.

Table A.29.d: Time of Estimation

Parameter	# Bits	Scale Factor	Units	Incl.
GPS Week of Estimation	10	1	Week	M
GPS TOW of Estimation	20	1	Seconds	M

GPS Week of Estimation

This field specifies the week of the time that the estimation was determined.

Range: 0 – 1023 weeks

GPS TOW of Estimation

Integer number of GPS TOW seconds within the current week of the time that the estimation was determined.

Range: 0 – 604800 s.

Validity Period

The validityPeriod indicates the validity period of the GPS Reference Set. It also indicates the default validity period of each individual delta ephemeris packet in the case that the individual validityPeriod is not present in the GPS Delta Epoch Header (see Table A.29.j). It is the length of time that the GPS Reference Set is intended to last and, if applicable, it is the length of time that the ephemeris constructed by application of the delta is intended to last.

Range: 1 – 8 hours.

Ephemeris Extension Duration

The Ephemeris Extension duration indicates the total block of time measured in units of hours that the extended ephemeris covers.

Range: 1 – 512 hours.

The gpsEphemeris header is mandatory only once in the delivery of the GPS Ephemeris Extension message.

GPS Reference Set

Table A.29.e: GPS Reference Set

Parameter	Presence	Note
GPS Reference Orbit	M	See Table A.29.f

The GPS Reference Set is a list of GPS Reference Orbits, one for each healthy satellite vehicle at the time of construction.

GPSReference Orbit

Table A.29.f: GPS Reference Orbit

Parameter	# Bits	Scale Factor	Units	Incl.
svID	5	1	—	M
gpsOrbitModel	See Table A.29.g		—	M
gpsClockModel	See Table A.29.h		—	M

SvID

The satellite vehicle ID identifying to which satellite the following orbital and clock model apply

GPSOrbitModel

This field is a structure that contains the Reference Nav Model satellite orbit information upon which all subsequent delta information will be applied to create the next ephemeris for use in navigation.

Table A.29.g: Reference Nav Model

Parameter	# Bits	Scale Factor	Units	Incl.
keplerToe	16	24	seconds	M
keplerW	32	2-31	hours	M
keplerDeltaN	16	2-43	semi-circles/sec	M
keplerM0	32	2-31	semi-circles	M
keplerOmegaDot	27	2-43	semi-circles/sec	M
keplerE	32	2-33	—	M
keplerIDot	14	2-43	semi-circles/sec	M
keplerAPowerHalf	32	2-19	Meters1/2	M
keplerIO	32	2-31	semi-circles	M
kelerOmega0	32	2-31	semi-circles	M
keplerCrs	16	2-5	meters	M
keplerCis	16	2-29	radians	M
keplerCus	16	2-29	radians	M
keplerCrc	16	2-5	meters	M
keplerCic	16	2-29	radians	M
KeplerCuc	16	2-29	radians	M

GPSClockModel

This field is a structure that contains the satellite clock model upon which all subsequent clock information will be applied to create the next clock model for use in navigation.

GPS Clock Model

Table A.29.h: GPS Clock Model

Parameter	# Bits	Scale Factor	Units	Incl.
aF2	8	2-55	seconds/seconds2	M
aF1	16	2-43	seconds/seconds	M
aF0	22	2-31	seconds	M
tgd	8	2-31	seconds	M

GPS Ephemeris Delta Matrix

GPS Ephemeris Delta Matrix is a list of GPS Ephemeris Delta Epochs. Each epoch is indicated by a unique seqNum. Each epoch corresponds to a specific update interval and contains a delta epoch header and ephemeris delta elements for all PRNs for that epoch.

GPS Ephemeris Delta Epoch

Table A.29.i: GPS Ephemeris Delta Epoch

Parameter	Note	Incl.
gpsDeltaEpochHeader	See Table A.29.j	O
gpsDeltaElementList	List of GPS Ephemeris Delta Elements	M

GPS Delta Epoch Header

Table A.29.j: GPS Delta Epoch Header

Parameter	# Bits	Scale Factor	Units	Incl.
validityPeriod	3	1	Hours	O
ephemerisDeltaSizes	See Table A.29.k			O
ephemerisDeltaScales	See Table A.29.l			O

Validity Period

The validityPeriod indicates the validity period of each individual delta ephemeris packet. It is the length of time that the ephemeris constructed by application of the delta is intended to last. If not present then the default validityPeriod in the GPS Ephemeris Header IE applies (see Table A.29.c).

Range: 1 – 8 hours.

Ephemeris Delta Sizes

This field is a structure that indicates the bit sizes for all the fields in the GPS Ephemeris Delta structure.

Table A.29.k: GPS Ephemeris Delta Sizes

Parameter	# Bits	Scale Factor	Units	Incl.
bitSize_delta_	5	1	—	M
bitSize_delta_n	4	1	—	M
bitSize_delta_M0	5	1	—	M
bitSize_delta_OMEGAdot	5	1	—	M
bitSize_delta_e	5	1	—	M
bitSize_delta_Idot	4	1	—	M
bitSize_delta_sqrtA	5	1	—	M
bitSize_delta_i0	5	1	—	M
bitSize_delta_OMEGA0	5	1	—	M
bitSize_delta_Crs	4	1	—	M
bitSize_delta_Cis	4	1	—	M
bitSize_delta_Cus	4	1	—	M
bitSize_delta_Crc	4	1	—	M
bitSize_delta_Cic	4	1	—	M
bitSize_delta_Cuc	4	1	—	M
bitSize_delta_tgd	4	1	—	M

Ephemeris Delta Scales

This field is a structure that indicates the scale factor modifiers for all the fields in the GPS Ephemeris Delta structure.

Table A.29.l: GPS Ephemeris Delta Scales

Parameter	# Bits	Scale Factor	Units	Incl.
scale_delta_	5	1	—	M
scale_delta_n	5	1	—	M
scale_delta_M0	5	1	—	M
scale_delta_OMEGAdot	5	1	—	M
scale_delta_e	5	1	—	M
scale_delta_Idot	5	1	—	M
scale_delta_sqrtA	5	1	—	M
scale_delta_i0	5	1	—	M
scale_delta_OMEGA0	5	1	—	M
scale_delta_Crs	5	1	—	M
scale_delta_Cis	5	1	—	M
scale_delta_Cus	5	1	—	M
scale_delta_Crc	5	1	—	M
scale_delta_Cic	5	1	—	M
scale_delta_Cuc	5	1	—	M
scale_delta_tgd	5	1	—	M

GPS Delta Element List

GPS Delta Element List is a list of GPS Ephemeris Delta Elements

GPS Ephemeris Delta Element

Each GPS Ephemeris Delta Element is encoded as an octet string of up to 47 octets. Each element is uniquely identified by the pair (seqNum, sv_ID) and it is defined as a structure as shown in table A.29.m. The MS should parse the octet string according to the fields specified in table A.29.m. Each element in table A.29.m but for seqNum and sv_ID should be treated as a signed integer. The actual number of octets is determined by the size of the bit fields in the GPS_Ephemeris_Delta_Sizes table (table A.29.k). Each set of up to 47 octets represents a single extension for a single satellite vehicle. Each element encodes the satellite vehicle ID and the sequence number. The sequence number specifies the order in which the individual ephemeris extension elements are assembled as time marches forward to create the next ephemeris. The sequence number is the same for all satellite vehicle IDs for a particular update period.

Table A.29.m: GPS Ephemeris Delta Element

Parameter	# Bits	Default # Bits	Scale Factor	Default Scale	Units	Incl.
sequenceNum	7		1	1	—	M
svID	5		1	1	—	M
delta_	1..32 (1)	21	2-16*2-31 .. 215*2-31 (2)	2-31	semi-circles	M
delta_n	1..16 (1)	12	2-16*2-43 .. 215*2-43 (2)	2-43	semi-circles/sec	M
delta_M0	1..32 (1)	21	2-16*2-31 .. 215*2-31 (2)	2-31	semi-circles	M
delta_OMEGAdot	1..24 (1)	13	2-16*2-43 .. 215*2-43 (2)	2-43	semi-circles/sec	M
delta_e	1..32 (1)	18	2-16*2-33 .. 215*2-33 (2)	2-33	—	M
delta_Idot	1..14 (1)	11	2-16*2-43 .. 215*2-43 (2)	2-43	semi-circles/sec	M
delta_sqrtA	1..32 (1)	14	2-16*2-19 .. 215*2-19 (2)	2-19	meters1/2	M
delta_i0	1..32 (1)	14	2-16*2-31 .. 215*2-31 (2)	2-31	semi-circles	M
delta_OMEGA0	1..32 (1)	14	2-16*2-31 .. 215*2-31 (2)	2-31	semi-circles	M
delta_Crs	1..16 (1)	12	2-16*2-5 .. 215*2-5 (2)	2-5	meters	M
delta_Cis	1..16 (1)	11	2-16*2-29 .. 215*2-29 (2)	2-29	radians	M
delta_Cus	1..16 (1)	12	2-16*2-29 .. 215*2-29 (2)	2-29	radians	M
delta_Crc	1..16 (1)	12	2-16*2-5 .. 215*2-5 (2)	2-5	meters	M
delta_Cic	1..16 (1)	11	2-16*2-29 .. 215*2-29 (2)	2-29	radians	M
delta_Cuc	1..16 (1)	12	2-16*2-29 .. 215*2-29 (2)	2-29	radians	M
delta_tgd	1..16 (1)	2	2-16*2-31 .. 215*2-31 (2)	2-31	seconds	M

(1) The number of bits of each signed integer field is variable and it is indicated once for all numEphemerisDeltas by the structure ephemerisDeltasSizes. When the ephemerisDeltaSizes field is not present, the values found in the columns "Default # Bits" shall be used.

(2) The scale factor of each parameter is variable around the default scale factor. The variation for each field is indicated once for all numEphemerisDeltas by the structure ephemerisDeltasScales. For example, if the scale factor modifier for delta_omega has a value of 4, the scale factor for delta_omega is 2⁴ * 2^-31. When the ephemerisDeltaScales is not used, the values found in the column "Default Scale" shall be used.

sequenceNum

This field indicates the order of the Ephemeris delta terms. The ephemeris constructed for use in satellite positioning is built by adding the delta terms to the referenced GPS_Navigation Model in the order dictated by this sequence number. The sequence number shall remain the same for each svID in an epoch of Ephemeris Deltas corresponding to a particular update interval.

svID

This field identifies the satellite ID within a particular sequenceNum or epoch.

These fields, with the exception of sequenceNum and svID, specify the deltas to be added to the existing Ephemeris to create a new Ephemeris suite that is extended from its predecessor by the time provided in the "validityPeriod" parameter. To compute the time of ephemeris for the newly constructed ephemeris, validityPeriod is added to the preceding toe. The ephemeris time of clock (toc) is set equal to the toe.

For each of the other ephemeris terms the corresponding delta ephemeris term is added in order to create the updated ephemeris. The terms delta_M0, delta_i0, and delta_OMEGA0 of the delta ephemeris must be extrapolated prior to the addition of the delta terms as follows:

Where is the WGS 84 value of the earth’s gravitational constant for GPS user and is equal to 3,986005 * 10¹⁴ m³/sec², and A(i) is the semi-major axis associated with this satellite’s update. The extrapolation of delta_M0, uses the prior set’s sqrtA term to compute A_(i) as the square of sqrtA_(i).

delta_OMEGA0_(i+1) = delta_OMEGA0_(i) + delta_OMEGAdot_(i) * dt

i0 _(i+1) = i0_(i) + Idot_(i) * dt

Where dt is equal to the validity period * 3600. The terms af0, and af1 from the GPS clock model must be extrapolated as follows:

af0_(i+1) = af0_(i) + af1_(i)* dt + af2*dt²

af1_(i+1) = af1_(i) + 2 * af2_(i) * dt

af2_(i+1) = af2_(i)

Where af0, af1, and af2 are the clock model terms as shown in table A.29.c

dt is equal to the validity period represented in seconds (validityPeriod * 3600)

The following demonstrates the application of the ephemeris extension technique. Assume the validityPeriod = 5, representing: (5+1) hours = 6 hours, and the GPS Navigation model for a particular satellite, identified by the reference IOD has a toe = 0 seconds.

The toe for sequenceNumber 1 is computed by adding the validityPeriod to the initial toe of 0 as 0 + 6 hours = 0 + 21600 seconds. The new ephemeris is constructed by adding the delta ephemeris terms from set 1 to the reference ephemeris creating the new ephemeris, which will be used for the next six hours. For the five terms listed above (delta_M0, delta_i0, delta_OMEGA0, af0, and af1) the extrapolation described must occur prior to the addition of the delta term.

The next ephemeris computation will occur by adding the validityPeriod to the current toe of 21600 as: 21600 + 6 hours = 21600 + 21600 = 43200. The ephemeris delta terms from set two are added to the ephemeris resulting from the prior addition to create the next ephemeris. This is done for each satellite vehicle ID.

GPS Ephemeris Extension check

The GPS Ephemeris Extension check provides information about non foreseen events that occurred during the period starting at the gpsBeginTime to the current time. An event is signified through a bit string . Each bits refers to one PRN. If a bit is set to one, this means that the ephemeris extension is no longer valid for this specific PRN. In order to indicate planned future manuvers an end time is provided. The SMLC can indicate that a future event is planned between the current time and the end time of this ephemeris extension.

Table A.29.n: Ephemeris Extension check

Parameter	Presence	Note
gpsBeginTime	M	See Table A.29o
gpsEndTime	M	See Table A.29p
gpsSatEventsInfo	M	See Table A.29q

GPS Begin Time

The GPS begin time corresponds to the GPS Week and GPS Seconds of Estimation of the ephemeris extensions block.

Table A.29.o: GPS Begin Time

Parameter	# Bits	Scale Factor	Units	Incl.
GPS Week	10	1	Weeks	M
GPS TOW	20	1	Seconds	M

GPS End Time

The GPS end time represents the final time the Ephemeris extension is valid.

Table A.29.p: GPS End Time

Parameter	# Bits	Scale Factor	Units	Incl.
GPS Week	10	1	Weeks	M
GPS TOW	20	1	Seconds	M

GPS Sat Event Information

This IE is designed to indicate events that have or may occur between the gpsBeginTime and the gpsEndTime.

Table A.29.q: GPS Sat Event Information

Parameter	# Bits	Scale Factor	Units	Incl.
EventOccurred	32	–	–	M
FutureEventNoted	32	–	–	M

EventOccurred

If a bit is is clear in the eventOccured field it indicates that a satellite maneuver has not occurred since the ganssBeginTime nor is a maneuver planned for the next sixty minutes.

FutureEventNoted

If a bit is set in the futureEventNoted field it indicates that a maneuver is planned during the time period between current time plus sixty minutes and gpsEndTime

DGPS Corrections Validity Period

This element is an extension to the DGPS Corrections IE and provides the validity period of the differential corrections for each satellite included in the DGPS Corrections IE (see Table A.15). This element may only be included if the DGPS Corrections IE is included in the GPS Assistance Data element.

Table A.29r: DGPS Corrections Validity Period

Parameter	# Bits	Scale Factor	Range	Units	Incl.
N_SAT	4	1	1-16	—	M
The following fields occur once per satellite (N_SAT times)
SatID	6	—	0-63	—	M
UDRE Growth Rate	3	—	0-7	—	M
Time of Validity for UDRE Growth Rate	3	—	0-7	—	M

N_SAT

This field indicates the number of satellites for which differential corrections validity period is available. This field shall be set to the same value as the N_SAT parameter in the DGPS Corrections element in Table A.15.

SatID

This field identifies the satellite for which the corrections validity period is applicable. The values ranging from 0 to 63 represent satellite PRNs ranging from 1 to 64, respectively. The UDRE Growth Rate and Time of Validity for UDRE Growth Rate IEs shall be included for the same satellite IDs as the differential corrections in Table A.15 are provided.

UDRE Growth Rate

This field provides an estimate of the growth rate of uncertainty (1-) in the corrections for the particular satellite identified by SatID. The estimated UDRE at time value specified in the "Time of Validity for UDRE Growth Rate" t₁ is calculated as follows:

UDRE(t₀+t₁) = UDRE(t₀)  UDRE Growth Rate

where t₀ is the DGPS Reference Time GPS TOW for which the corrections in Table A.15 are valid, t₁ is the "Time of Validity for UDRE Growth Rate" field as shown in Table A.29t, UDRE(t₀) is the User Differential Range Error field as provided in Table A.15, and "UDRE Growth Rate" field is the factor as shown in Table A.29s.

Table A.29s: Values of UDRE Growth Rate IE

Value	Indication
000	1,5
001	2
010	4
011	6
100	8
101	10
110	12
111	16

Time of Validity for UDRE Growth Rate

This field specifies the time when the "UDRE Growth Rate" field applies. The meaning of the values for this field is described in Table A.29t.

Table A.29t: Time of Validity for UDRE Growth Rate IE

Value	Indication [seconds]
000	20
001	40
010	80
011	160
100	320
101	640
110	1280
111	2560

GPS Reference Time Extension

This element is an extension to the Reference Time IE and is shown in Table A.29u. If Reference Time is provided by the SMLC, the GPS Reference Time Extension shall also be provided.

NOTE: For reasons of backward compatibility, this IE is not defined for a Release 9 or earlier SMLC and would be ignored, when received, by a Release 9 or earlier MS. This means that when the element is expected but is not received, the SMLC is Release 9 or earlier.

Table A.29u: Reference Time Extension

Parameter	# Bits	Scale Factor	Range	Units	Incl.
GPS Week Cycle Number	3	1	0 – 7	1024 weeks	M

GPS Week Cycle Number

This field provides the number of 1024 GPS week cycles occurred since the GPS zero time-point (midnight of the night of January 5, 1980/morning of January 6, 1980). The first 1024 GPS weeks since the zero time-point is GPS Week Cycle Number 0.

GPS Acquisition Assistance Extension

This element is an extension to the Acquisition Assistance IE and is shown in Table A.29v. If Acquisition Assistance is provided by the SMLC, the GPS Acquisition Assistance Extension shall also be provided.

NOTE: For reasons of backward compatibility, this IE is not defined for a Release 9 or earlier SMLC and would be ignored, when received, by a Release 9 or earlier MS. This means that when the element is expected but is not received, the SMLC is Release 9 or earlier.

Table A.29v: Acquisition Assistance Extension

Parameter	# Bits	Scale Factor	Range	Units	Incl.
N_SAT	4	1	0-15	—	M
The following fields occur once per satellite (N_SAT times)
SatID	6	—	0-63	—	M
Azimuth LSB	4	0,703125	0-10,546875	degrees	M
Elevation LSB	4	0,703125	0-10,546875	degrees	M

N_SAT

This field indicates the number of satellites for which Acquisition Assistance is provided. This field shall be set to the same value as the Number of Satellites parameter in theAcquisition Assist element in Table A.24.

SatID

This field identifies the satellite for which the Acquisition Assistance is provided. This field shall be set to the same value as the SVID/PRN field in Table A.25.

Azimuth LSB

This field specifies the 4 least significant bits of the satellite azimuth angle. The 5 most significant bits are provided in the Azimuth field in Table A.25. The full satellite azimuth is constructed as "Azimuth"  11,25 + "Azimuth LSB"  0,703125 degrees.

Elevation LSB

This field specifies the 4 least significant bits of the satellite elevation angle. The 5 most significant bits are provided in the Elevation field in Table A.25. The full satellite elevation is constructed as "Elevation"  11,25 + "Elevation LSB"  0,703125 degrees.

GPS Almanac Extension

This element is an extension to the Almanac IE and and is shown in Table A.29w. If Almanac is provided by the SMLC, the Almanac Extension shall also be provided.

NOTE: For reasons of backward compatibility, this IE is not defined for a Release 9 or earlier SMLC and would be ignored, when received, by a Release 9 or earlier MS. This means that when the element is expected but is not received, the SMLC is Release 9 or earlier.

Table A.29w: Almanac Extension

Parameter	# Bits	Scale Factor	Range	Units	Incl.
Complete Almanac Provided	1	—	—	Boolean	M

Complete Almanac Provided

This field indicates whether the SMLC provided Almanac for the full GPS constellation or not. TRUE means complete GPS almanac is provided.

GPS Acquisition Assistance Extension-R12

This element is an extension to the Acquisition Assistance IE and is shown in Table A.29x. The SMLC should include this field only if supported by the MS.

Table A.29x: Acquisition Assistance Extension-R12

Parameter	# Bits	Scale Factor	Range	Units	Incl.
Confidence	7	1	0-100	percent	O
N_SAT	4	1	0-15	—	O
The following fields occur once per satellite (N_SAT times)
SatID	6	—	0-63	—	M
Doppler Uncertainty Extension	3	—	300, 400, 500, 600, ‘No Information’	Hz	M

Confidence

This field specifies the confidence level of the reference location area or volume used to calculate the GPS Acquisition Assistance parameters (search windows). A high percentage value (e.g., 98% or more) indicates to the MS that the provided search windows are reliable. The SMLC should include this field to indicate the confidence level of the provided information.

Range: 0 – 100

N_SAT

This field indicates the number of satellites for which GPS Acquisition Assistance Extension-R12 is provided.

SatID

This field identifies the satellite for which the GPS Acquisition Assistance Extension-R12 is provided.

Doppler Uncertainty Extension

If this field is present, the MS that supports this field shall ignore the Doppler Uncertainty (Table A.25) field. This field specifies additional Doppler uncertainty values. It is defined such that the Doppler experienced by a stationary MS is in the range [Doppler-Doppler Uncertainty Extension] to [Doppler+Doppler Uncertainty Extension].

Enumerated values define 300 Hz, 400 Hz, 500 Hz, 600 Hz, and "No Information".

A.4.2.5 More Assistance Data To Be Sent Element

A.4.2.5 More Assistance Data To Be Sent Element

This element is set by the SMLC to indicate to the MS if more Assistance Data components or a the final RRLP Measure Position Request component will be sent in the current procedure in order to deliver the entire set of assistance data.

A.4.2.6 GANSS Assistance Data

The GANSS Assistance Data consists of two or more data elements depending on the number of GNSS constellations included in the GANSS Assistance Data. GANSS Assistance Data elements are of two different types: GANSS Common Assistance Data and GANSS Generic Assistance Data. GANSS Common Assistance Data element is included at most only once and it contains Information Elements that can be used with any GNSS constellation. GANSS Generic Assistance data element can be included multiple times depending on the number of GNSS constellations supported in the GANSS Assistance Data. One GANSS Generic Assistance Data element contains Information Elements dedicated only for one specific GNSS constellation at a time. If two or more constellations are supported, GANSS Generic Assistance Data is given for each constellation separately.

The fields in GANSS Assistance Data are listed in Table A.30 below. As table A.30 shows, all fields are optional.

Table A.30: Fields in the GANSS Assistance Data element

Element	Presence	Repetition
GANSS Common Assistance Data	O	No
GANSS Generic Assistance Data	O	Yes

When RRLP pseudo-segmentation is used, Tables A.30, A.31 and A.39 indicate which elements may be repeated in more than one RRLP segment in order to provide data for multiple constellations, satellites or signals. When any such element – with the exception of the GANSS ID and SBAS ID element – appears in more than one segment, the following rules shall apply.

1. There shall be no repetition of the same data for the same constellation, satellite or signal even though there might be multiple realizations of the IEs for the same constellation, satellite or signal. For example, DGANSS corrections may occur multiple times for the same satellite.

2. Optional and conditional fields in the element not associated with a particular satellite or signal shall each appear in at most one RRLP segment.

3. Any mandatory field not associated with a particular satellite or signal shall assume consistent values in the case of a field related to current reference time and the same value otherwise.

4. The maximum number of constellations, satellites or signals defined in sub-clause 5.1 for which data can be included for any parameter in one RRLP segment shall apply also when counted over all RRLP segments.

A.4.2.6.1 GANSS Common Assistance Data

GANSS Common Assistance Data element contains GNSS constellation independent information elements that can be applied on any specific GNSS or on a combination of GNSS. GANSS Common Assistance Data fields are included in GANSS Assistance Data only once. This element can contain one or more of the fields listed in table A.31 below. As Table A.31 shows, all fields are optional.

Table A.31: GANSS Common Assistance Data content

Element	Presence	Repetition
GANSS Reference Time	O	No
GANSS Reference Location	O	No
GANSS Ionospheric Model	O	No
GANSS Additional Ionospheric Model	O	No
GANSS Earth Orientation Parameters	O	No
GANSS Reference Time Extension	O	No

GANSS Reference Time

This field specifies the GANSS Time Of Day (TOD) with uncertainty and relationship between GANSS Reference Time and air-interface timing of the BTS transmission in the reference cell. These fields occur once per message; some are mandatory and some are optional, as shown in Table A.33.

When GANSS TOD -GSM Time association is present, GANSS TOD and BCCH/BSIC/FN_m/TN/BN IEs provide a valid relationship between GANSS TOD and GSM time, as seen at the approximate location of the MS, i.e. the propagation delay from BTS to MS shall be compensated for by the SMLC. Depending on implementation, the relation between GANSS TOD and GSM time may have varying accuracy. Therefore, the uncertainty of the timing relation is provided in GANSS TOD Uncertainty. If the propagation delay from BTS to MS is not accurately known, the SMLC shall use the best available approximation of the propagation delay and take the corresponding delay uncertainty into account in the calculation of the field GANSS TOD Uncertainty. When GANSS TOD -GSM Time association is not present, GANSS TOD is an estimate of current GANSS TOD at time of reception of the RRLP segment containing this data by the MS. The SMLC should achieve an accuracy of +/- 3 seconds for this estimate including allowing for the transmission delay between SMLC and MS of the RRLP segment containing GANSS TOD. Note that the MS should further compensate GANSS TOD for the time between the reception of the segment containing GANSS TOD and the time when the GANSS TOD field is used.

Table A.33: GANSS Reference Time

Parameter	# Bits	Scale Factor	Range	Units	Incl.
GANSS Reference Time Information (once per message)
GANSS Day	13	1	0 – 8191	day	M
GANSS TOD	17	1	0 – 86399	sec	M
GANSS TOD Uncertainty	7	–	0…127	–	O
GANSS_TIME_ID	3	—	—	—	O (note 3)
GANSS TOD – GSM Time Association (once per message)
BCCH Carrier	10	1	0 – 1023	—	O (note 1)
BSIC	6	1	0 – 63	—	O (note 1)
FNm	21	1	0 – (221-1)	frames	O (note 1)
TN	3	1	0 – 7	timeslots	O (note 1)
BN	8	1	0 – 156	bits	O (note 1)
FN1	7	2-30	-5,9605e-8 – +5,8673e-8	sec/sec	O (note 2)
NOTE 1: All of these fields shall be present together, or none of them shall be present.
NOTE 2: This field can be optionally included if GANSS TOD – GSM Time association is present.
NOTE 3. Absence of this field means Galileo system time.

GANSS Day

This field specifies the sequential number of days (with day count starting at 0) from the origin of the GNSS system time indicated by GANSS_TIME_ID modulo 8192 days (about 22 years). The GNSS system time origin is defined in Table A.34 for each GANSS.

NOTE: The number of 8192 day cycles since the GANSS zero time-point is provided in the GANSS Reference Time Extension in Table A.35c.

GANSS TOD

Integer number of GANSS TOD seconds within the current day.

Range: 0 – 86399 s.

GANSS TOD Uncertainty

GANSS TOD uncertainty value as described in 3.2.9. This field is optional.

GANSS_TIME_ID

This field specifies the GNSS system time used in GANSS Reference Time. The SMLC shall set the GANSS_TIME_ID only to system times for corresponding GANSSs supported by the MS.

Table A.34: GANSS_TIME_ID

GANSS_TIME_ID	Indication	GNSS System Time Origin
Galileo System Time	(default)	Days from Galileo System Time (GST) start epoch, defined as 13 seconds before midnight between 21st August and 22nd August 1999; i.e., GST was equal to 13 seconds at August 22nd 1999 00:00:00 UTC
GPS System Time	0	January 6, 1980; 00:00:00 UTC(USNO)
QZSS System Time	1	January 6, 1980; 00:00:00 UTC(USNO)
GLONASS System Time	2	December 31st 1995 21:00:00 UTC (SU), which is local UTC Moscow January 1st 1996 00:00:00, defined as UTC(SU) + 3 hours in [17]
BDS	3	January 1, 2006 00:00:00 UTC (NTSC)
Reserved for future use	4 – 7	–

BCCH Carrier/BSIC/FN_m/TN/BN/FN₁

These fields specify the state of the GSM frame number, respectively, of the reference BTS with the specified BCCH carrier and BSIC at the time that correspond to GANSS TOD. Also, the drift rate of the frame timing, FN₁, with respect to the GANSS TOD is optionally given. The SMLC shall use the current serving BTS as the reference BTS. The target MS has the option of rejecting a GANSS position request or GANSS assistance data if the reference BTS is not the serving BTS. If FN_m field is present in the assistance, cellular time parameters FN_m/TN/BN shall be aligned with the integer GANSS TOD second given in GANSS TOD field.

GANSS Reference Location

The Reference Location field contains a 3-D location (with uncertainty) specified as per 3GPP TS 23.032. The purpose of this field is to provide the MS with a priori knowledge of its location in order to improve GNSS receiver performance. The allowed shape is 3-D location with uncertainty (ellipsoid point with altitude and uncertainty ellipsoid). As defined in 3GPP TS 23.032, the GANSS Reference Location is provided in WGS-84 reference system.

NOTE: If GPS Assistance Data component is present as well, the SMLC should include the Reference Location either in the GPS Assistance Data or GANSS Common Assistance Data element.

GANSS Ionospheric Model

GANSS Ionospheric Model contains parameters to model the propagation delay of the GNSS signals through the ionosphere. The information elements in this field are shown in Table A.35. Proper use of these fields as defined in [11] allows a single‑frequency GNSS receiver to remove the ionospheric delay from the pseudorange measurements.

Table A.35: GANSS Ionospheric Model

Parameter	# Bits	Scale Factor	Units	Incl.
GANSS Ionosphere Model Parameters
ai0	11	2-2	Solar Flux Units	M
ai1	11	2-8	Solar Flux Units/degree	M
ai2	14	2-15	Solar Flux Units/degree2	M
GANSS Ionosphere Regional Storm Flags
Storm Flag 1	1	—	—	O (note 1)
Storm Flag 2	1	—	—	O (note 1)
Storm Flag 3	1	—	—	O (note 1)
Storm Flag 4	1	—	—	O (note 1)
Storm Flag 5	1	—	—	O (note 1)
NOTE 1: All of these fields shall be present together, or none of them shall be present.

GANSS Ionosphere Parameters

The ionosphere model parameters are used to estimate the ionospheric distortions on pseudoranges as described in [11] section 5.1.6.

GANSS Ionosphere Regional Storm Flags

These fields specify the Ionosphere disturbance flags (1,…,5) for five different regions as described in [11] section 5.1.6. If the ionosphere disturbance flag for a region is not present the target device shall treat the ionosphere disturbance condition as unknown.

GANSS Additional Ionospheric Model

The GANSS Additional Ionospheric Model contains parameters to model the propagation delays of the GANSS signals through the ionosphere. The information elements in this field are shown in table A.35.a.

When Data ID has the value ’11’ it indicates that the parameters have been generated by QZSS, and the parameters have been specialized and are applicable within the area defined in [16]. When Data ID has the value ’00’ it indicates the parameters are applicable worldwide [16]. All other values for Data ID are reserved. When Data ID has the value ’01’ it indicates that the parameters have been generated by BDS, and UE shall use these parameters according to the description given in 5.2.4.7 in [18].

Table A.35.a: GANSS Additional Ionospheric Model

Parameter	# Bits	Scale Factor	Units	Incl.
Data ID	2	—	See text	M
0	8	2-30	seconds	M
1	8	2-27	sec/semi-circle	M
2	8	2-24	sec/(semi-circle)2	M
3	8	2-24	sec/(semi-circle)3	M
0	8	211	seconds	M
1	8	214	sec/semi-circle	M
2	8	216	sec/(semi-circle)2	M
3	8	216	sec/(semi-circle)3	M

GANSS Earth Orientation Parameters

The GANSS Earth Orientation Parameters provides parameters to construct the ECEF and ECI coordinate transformation as defined in [12] and are shown in Table A.35.b. GANSS Earth Orientation Parameters indicate the relationship between the Earth’s rotational axis and WGS-84 reference system.

Table A.35.b: GANSS Earth Orientation Paramaters

Parameter	# Bits	Scale Factor	Units	Incl.
tEOP	16	24	seconds	M
PM_X	21	2-20	arc-seconds	M
PM_X_dot	15	2-21	arc-seconds/day	M
PM_Y	21	2-20	arc-seconds	M
PM_Y_dot	15	2-21	arc-seconds/day	M
UT1	31	2-24	seconds	M
UT1_dot	19	2-25	seconds/day	M

GANSS Reference Time Extension

This element is an extension to the GANSS Reference Time IE and is shown in Table A.35c. If GANSS Reference Time is provided by the SMLC, the GANSS Reference Time Extension shall also be provided.

NOTE: For reasons of backward compatibility, this IE is not defined for a Release 9 or earlier SMLC and would be ignored, when received, by a Release 9 or earlier MS. This means that when the element is expected but is not received, the SMLC is Release 9 or earlier.

Table A.35c: GANSS Reference Time Extension

Parameter	# Bits	Scale Factor	Range	Units	Incl.
GANSS Day Cycle Number	3	1	0 – 7	8192 days	M

GANSS Day Cycle Number

This field provides the number of 8192 day cycles occurred since the GANSS zero time-point defined in Table A.34. The first 8192 GANSS days since the zero time-point is GANSS Day Cycle Number 0.

A.4.2.6.2 GANSS Generic Assistance Data

GANSS Generic Assistance data elements contain Information Elements that are applied on one specific GNSS at a time indicated by GANSS_ID. The format of the IE’s remains the same regardless of the GANSS; only the values of the parameters and inclusion of certain optional fields will vary.

GANSS Generic Assistance Data is repeated for each GNSS included in GANSS Assistance Data. GANSS Generic Assistance Data can contain one or more of the elements listed in Table A.39 below. As Table A.39 shows, all fields are optional.

Table A.39: GANSS Generic Assistance Data content

Element	Presence	Repetition
GANSS ID	O (note 1)	Yes
GANSS Time Model	O	Yes
DGANSS Corrections	O	Yes
GANSS Navigation Model	O	Yes
GANSS Real-Time Integrity	O	Yes
GANSS Data Bit Assistance	O	Yes
GANSS Reference Measurement Information	O	Yes
GANSS Almanac Model	O	Yes
GANSS UTC Model	O	Yes
GANSS Ephemeris Extension	O	Yes
GANSS Ephemeris Ext Check	O	Yes
SBAS ID	O	Yes
GANSS Additional UTC Model	O	Yes
GANSS Auxiliary Information	O	Yes
DGANSS Corrections Validity Period	O	Yes
GANSS Time Model Extension	O	Yes
GANSS Reference Measurement Extension	O	Yes
GANSS Almanac Model Extension	O	Yes
GANSS Almanac Model Extension-R12	O	Yes
GANSS Reference Measurement Extension-R12	O	Yes
DBDS Corrections	O (note 2)	Yes
BDS Grid Model	O (note 2)	Yes
NOTE 1: Absence of this field means Galileo. NOTE 2: The field may be present if the GANSS ID = BDS; otherwise it is not present.

GANSS_ID

This field indicates the GNSS for which the following assistance data IE’s in GANSS Generic Assistance Data element are dedicated. The supported GANSS are listed in Table A.40. Absence of this field indicates Galileo. If GANSS ID indicates SBAS, the SBAS ID shall be included to indicate the specific SBAS addressed.

Range: 0 – 7

Table A.40: GANSS_ID

GANSS_ID	Indication
SBAS	0
Modernized GPS	1
QZSS	2
GLONASS	3
BDS	4
Reserved for future use	5-7

GANSS Time Model

This field specifies a model to relate GNSS system time to a selected time reference. GNSS Time Offset ID (GNSS_TO_ID) identifies the GNSS for which the relation is provided.

The SMLC may send multiple GANSS Time Models (up to 7) for a specific GNSS depending on the number of the allowed satellite systems in GANSS Positioning Method. For example, the SMLC may send two GANSS Time Models for Galileo to give the relations between Galileo and two GNSS system times.

NOTE: The integer number of seconds of the GNSS-GNSS Time Offset is provided in the GANSS Time Model Extension in Table A.55.22.

Table A.41: GANSS Time Model

Parameter	# Bits	Scale Factor	Range	Units	Incl.
GANSS Time Model Reference Time	16	24	0 – 604784	s	M
TA0	32	2-35		sec	M
TA1	24	2-51		sec/sec	O (NOTE)
TA2	7	2-68		sec/sec2	O (NOTE)
GNSS_TO_ID	3	—	—	—	M
Week Number	13	1	0 – 8191	week	O
NOTE: The fields indicated by "NOTE" should not be included if GPS Reference Time is provided in the assistance data.

GANSS Time Model Reference Time

This field specifies the reference time of week for GANSS Time Model and it is given in GNSS specific system time.

Range: 0 604784 seconds

T_A0/T_A1/T_A2

These fields specify the GANSS Time Model for a specific GNSS system by constant and first and second order terms of polynomial. The first and second order terms are optional.

GNSS_TO_ID

This field specifies GNSS Time Offset ID. GANSS Time Model contains parameters to convert GNSS System Time from the system indicated by GANSS_ID to GNSS System Time indicated by GNSS_TO_ID. The conversion is defined in [12,13,14]. The SMLC should include a GANSS Time Model for the same GANSS_ID as the GANSS_TIME_ID in GANSS Reference Time. If the SMLC does not include a GANSS Time Model for the same GANSS_ID as the GANSS_TIME_ID in GANSS Reference Time or if GANSS Reference Time is not included the MS assumes T_A1 and T_A2 are equal to zero.

Table A.42: GNSS_TO_ID

GNSS_TO_ID	Indication
GPS	0
GALILEO	1
QZSS	2
GLONASS	3
BDS	4
Reserved for future use	5-7

Week Number

This field specifies the reference week of GANSS Time Model given in GNSS specific system time. This field is optional.

NOTE: The time relationship between the system time indicated by GANSS_ID and system time indicated by GNSS_TO_ID is given by the following equation [12,13,14]:

t_GNSS = t_E – ( A_0GGTO + A_1GGTO (t_E – t_GGTO + 604800 (WN – WN_GGTO)) + A_2GGTO (t_E – t_GGTO +
604800 (WN – WN_GGTO))² )

where

t_GNSS is the system time of week for the GNSS indicated by GNSS_TO_ID.
t_E is the system time of week for the GNSS indicated by GANSS_ID.
WN is the week number of the GNSS system time indicated GANSS_ID corresponding to the t_E.
t_GGTO is the system time of week for the time model data in the GNSS time indicated by
GANSS_ID and given by the GANSS Time Model Reference Time field.
WN_GGTO is the week number for the time model data in the GNSS time indicated by GANSS_ID
corresponding to the t_GGTO and given by the Week Number field.
A_0GGTO is given by the T_A0 field.
A_1GGTO is given by the T_A1 field.
A_2GGTO is given by the T_A2 field.

If the T_A1 and T_A2 are not included in the GANSS Time Model, the MS assumes A_1GGTO and A_2GGTO are equal to zero.

The GNSS system times in the GANSS Time Model and used in the equation above are all given in Time of Week (TOW) and Week Number (WN) in the indicted GNSS specific system time. For conversion between TOW/WN and Day Number/Time of Day (GANSS Day/GANSS TOD) a GNSS week consists of 7 days since the origin of the particular GNSS System time (with the week number count starting at 0), and a day consists of 86400 seconds.

DGANSS Corrections

These fields specify the DGANSS corrections to be used by the MS.

Table A.43: DGANSS Corrections

Parameter	# Bits	Scale Factor	Range	Units	Incl.
The following fields occur once per message
DGANSS Reference Time	7	30	0 – 3570	seconds	M
N_SGN_TYPE	2	1	1 – 3	—	M
The following fields occur once per GANSS signal type (N_SGN_TYPE times)
GANSS_Signal_ID	3	—	—	—	M
Status/Health	3	1	0 – 7	—	M
N_SAT	4	1	1 – 16	—	M
The following fields occur once per satellite (N_SAT times)
SV_ID	6	—	0…63	—	M
IOD	10	—	—	—	M
UDRE	2	—	0 – 3	—	M
PRC	12	0,32	655,04	meters	M
RRC	8	0,032	4,064	meters/sec	M

DGANSS Reference Time

This field indicates the baseline time for which the DGANSS corrections are valid as modulo 3600 s. DGANSS Reference Time is given in GNSS system time.

Range: 0 – 3600 s

N_SGN_TYPE

This field indicates the number of GNSS signal types included in DGANSS Corrections IE.

Range: 1 – 3

GANSS_Signal_ID

DGANSS corrections are provided per GNSS signal type identified by GANSS_Signal_ID. The supported signals are listed in Table A.59.

Status/Health

This field indicates the status of the differential corrections contained in the broadcast message. The values of this field and their respective meanings are shown below in Table A.44.

Table A.44: Values of Status/Health IE

Code	Indication
000	UDRE Scale Factor = 1,0
001	UDRE Scale Factor = 0,75
010	UDRE Scale Factor = 0,5
011	UDRE Scale Factor = 0,3
100	UDRE Scale Factor = 0,2
101	UDRE Scale Factor = 0,1
110	Reference Station Transmission Not Monitored
111	Data is invalid – disregard

The first six values in this field indicate valid differential corrections. When using the values described below, the "UDRE Scale Factor" value is applied to the UDRE values contained in the message. The purpose is to indicate an estimate in the amount of error in the corrections.

The value "110" indicates that the source of the differential corrections (e.g., reference station or external DGANSS network) is currently not being monitored. The value "111" indicates that the corrections provided by the source are invalid, as judged by the source. In the later case, the message shall contain no corrections for individual satellites. Any MS that receives DGANSS Corrections in a GANSS Assistance Data IE shall contain the appropriate logic to properly interpret this condition and look for the next IE.

N_SAT

This field indicates the number of satellites (per specified GANSS_Signal_ID) for which differential corrections areincluded in this element.

Range: 1 – 16

SV_ID

The SV ID is an index number for a satellite. The interpretation of SV ID is defined in Table A.10.14.

Issue Of Data

Issue of Data field contains the identity for the GANSS Navigation Model, as defined in Table A.48.2 (i.e., excluding the IOD_MSB, if applicable for the particular GANSS or signal).

User Differential Range Error (UDRE)

This field provides an estimate of the uncertainty (1-) in the corrections for the particular satellite. The value in this field shall be multiplied by the UDRE Scale Factor in the common Corrections Status/Health field to determine the final UDRE estimate for the particular satellite. The meanings of the values for this field are described in Table A.45.

Table A.45: Values of UDRE IE

Value	Indication
00	UDRE  1,0 m
01	1,0 m < UDRE  4,0 m
10	4,0 m < UDRE  8,0 m
11	8,0 m < UDRE

Each UDRE value shall be adjusted based on the operation of an Integrity Monitor (IM) function which exists at the network (SMLC, GPS server, or reference GPS receiver itself). Positioning errors derived at the IM which are excessive relative to DGPS expected accuracy levels shall be used to scale the UDRE values to produce consistency.

Pseudo-Range Correction (PRC)

This field indicates the correction to the pseudorange for the particular satellite at DGANSS Reference Time, t₀. The value of this field is given in meters (m) and the resolution is 0,32, as shown in Table A.43 above. The method of calculating this field is described in [9].

If the SMLC has received a request for GANSS assistance data from an MS which included a request for the navigation models and DGANSS (i.e., bit J and M are set to one in ‘Requested GANSS Assistance Data, see 3GPP TS 49.031), the SMLC shall determine, for each satellite, if the navigation model stored by the MS is still suitable for use with DGANSS corrections (also see navigation model update conditions right before Table A.46) and if so and if DGANSS corrections are supported the SMLC should send DGANSS corrections without including the navigation model.

The IOD value sent for a satellite shall always be the IOD value that corresponds to the navigation model for which the pseudo-range corrections are applicable.

The pseudo-range correction shall correspond to the available navigation model (the one already stored in and identified by the MS or the one included in the same procedure as the pseudo-range correction). The MS shall only use the PRC value when the IOD value received matches its available navigation model.

Pseudo-range corrections are provided with respect to GNSS specific geodetic datum (e.g., PZ-90.02 if GANSS ID indicates GLONASS).

Pseudo-Range Rate Correction (RRC)

This field indicates the rate-of-change of the pseudorange correction for the particular satellite, using the satellite ephemeris and clock corrections identified by the IOD IE. The value of this field is given in meters per second (m/sec) and the resolution is 0,032, as shown in table A.43 above. For some time t₁ > t₀, the corrections for IOD are estimated by

PRC(t_{1, IOD}) = PRC(t_{0, IOD}) + RRC(t_{0, IOD})(t₁ – t₀) ,

and the MS uses this to correct the pseudorange it measures at t₁, PR_m(t_1, IOD), by

PR(t_{1, IOD}) = PR_m(t_{1, IOD}) + PRC(t_{1, IOD}) .

The SMLC shall always send the RRC value that corresponds to the PRC value that it sends (see above for details). The MS shall only use the RRC value when the IOD value received matches its available navigation model.

GANSS Navigation Model

This set of fields contains information required to manage the transfer of precise navigation data to the GANSS-capable MS. In response to a request from a MS for GANSS Assistance Data, the SMLC shall determine whether to send the navigation model for a particular satellite to an MS based upon factors like the T-Toe limit specified by the MS and any request from the MS for DGANSS (also see above). This information includes control bit fields as well as satellite ephemeris and clock corrections and clock and orbit accuracy models. GANSS Orbit Model can be given in Keplerian parameters or as state vector in Earth-Centered Earth-Fixed coordinates, dependent on the GANSS-ID and the MS capabilities. The meaning of these parameters is defined in relevant ICDs of the particular GANSS and GNSS specific interpretations apply. For example, Modernized GPS and QZSS use the same model parameters but some parameters have a different interpretation [16].

GANSS Navigation Model element can contain data up to at most 32 satellites. The individual fields are given in Table A.46 and the conditions for their presence is discussed below.

Table A.46: GANSS Navigation Model contents

Parameter	# Bits	Scale Factor	Units	Incl.
Navigation Model Flow Control (once per message)
Num_Sat	5	1	—	M
Non-Broadcast Indication	1	—	—	M
The following fields occur once per satellite (Num_Sat times)
SV ID	6	—	—	M
SV Health	5	—	—	M
IOD	10	—	—	M
GANSS Clock Model	See Table A.49.1	—	—	M
GANSS Orbit Model	See Table A.49.2	—	—	M
SV Health_MSB	1	—	—	O
IOD_MSB	1	—	—	O
SV Health Extension	4	—	—	O

Num_Sat

This field specifies the number of satellites that are included in the provided GANSS Navigation Model element. A range of 1-32 is available. This field is mandatory when the GANSS Navigation Model field is included in the GANSS Assistance Data message.

Non-Broadcast Indication

This field indicates if the GANSS Navigation Model Elements are not derived from satellite broadcast data or are given in a format not native to the GANSS.

Table A.47: Values of Non-Broadcast Indication Flag

Value	Non-Broadcast Indication
0	GANSS Navigation Data elements corresponding with broadcasted data
1	GANSS Navigation Data element not derived from satellite broadcast

SV_ID

The field specifies the SV/Slot ID for which the GANSS Navigation Model Elements is given. The interpretation of SV ID is defined in Table A.10.14.

Range: 0 – 63

SV Health and SV Health_MSB

This parameter gives information about the satellite’s current health. The health values are GNSS system specific. The SV Health bits have the encoding as in Table A.48.1 for a particular GANSS. The SV Health_MSB may be present for some GANSS or signals as defined in Table A.48.1. If SV Health_MSB is present, the total SV Health information is created by appending the SV Health field to the SV Health_MSB field.

Table A.48.1: Interpretation SV Health Bits

GANSS	SV Health_MSB	SV Health Bit String(5)
		Bit 1 (MSB)	Bit 2	Bit 3	Bit 4	Bit 5 (LSB)
Galileo [11, section 5.1.9.3]	—(1)	E5a Data Validity Status	E5b Data Validity Status	E1-B Data Validity Status	E5a Signal Health Status
Modernized GPS(2)	—(1)	L1C Health [14]	L1 Health [12,13]	L2 Health [12,13]	L5 Health [12,13]	‘0’ (reserved)
SBAS(3)	—(1)	Ranging On (0), Off(1)	Corrections On (0), Off (1)	Integrity On (0), Off(1)	‘0’ (reserved)	‘0’ (reserved)
QZSS QZS-L1(4)	MSB of SV Health [16]	5 LSBs of SV Health [16]
QZSS QZS-L1C/L2C/L5(5)	—(1)	L1C Health [16]	L1 Health [16]	L2 Health [16]	L5 Health [16]	‘0’ (reserved)
GLONASS	—(1)	Bn (MSB) [17, page 23]	FT [17, Table 4.4]
BDS	—(1)	B1I Health (SatH1) [18]	‘0’ (reserved)
Note 1: The SV Health_MSB field shall not be present in GANSS Navigation Model for these GANSS or GANSS signals. Note 2: If a certain signal is not supported on the satellite indicated by SV_ID, the corresponding health bit shall be set to ‘1’ (i.e., signal can not be used). Note 3: SV Health in case of GANSS ID indicates SBAS includes the 5 LSBs of the Health included in GEO Almanac Message Parameters (Type 17) [15]. Note 4: If GANSS ID indicates ‘QZSS’, and GANSS Orbit Model-2 is included, this interpretation of SV Health applies. Note 5: If GANSS ID indicates ‘QZSS’, and GANSS Orbit Model-3 is included, this interpretation of SV Health applies.

SV Health Extension

This parameter gives additional information about the satellite’s current health. The health values are GNSS system specific. The SV Health Extension bits have the encoding as in Table A.48.1a for a particular GANSS.

Table A.48.1a: Interpretation SV Health Extension Bits

GANSS	SV Health Extension Bit String(4)
	Bit 1 (MSB)	Bit 2	Bit 3		Bit 4 (LSB)
Galileo [11, section 5.1.9.3]	E5b Signal Health Status			E1-B Signal Health Status

Issue Of Data

Issue of Data field contains the identity for GANSS Navigation Model. The IOD_MSB may be present for some GANSS or signals as defined in Table A.48.2a. If IOD_MSB is present, the total IOD information is constructed as defined in Table A.48.2a.

In the case of broadcasted Galileo ephemeris, the IOD contains the IODnav as described in [11].

In case of broadcasted Modernized GPS ephemeris, the IOD contains the 11-bit parameter t_oe as defined in [12, Table 30-I] [14, Table 3.5-1] and is constructed using IOD and IOD_MSB fields.

In case of broadcasted SBAS ephemeris, the IOD contains the 8 bits Issue of Data as defined in [15] Message Type 9.

In case of broadcasted QZSS QZS-L1 ephemeris, the IOD contains the IODC as described in [16].

In case of broadcasted QZSS QZS-L1C/L2C/L5 ephemeris, the IOD contains the 11-bit parameter t_oe as defined in [16] and is constructed using IOD and IOD_MSB fields.

In case of broadcasted GLONASS ephemeris, the IOD contains the parameter t_b as defined in [17].

In case of broadcasted BDS ephemeris, the IOD contains the 11 MSB bits of t_oe as defined in [18].

Table A.48.2: Interpretation of Issue Of Data

GANSS	Parameter	# Bits	Scale Factor	Range	Units
Galileo	IODnav	10	—	0-1023	—
Modernized GPS(1)	LSBs of toe	10	300	0-306900	seconds
SBAS	IOD	8	—	0-255	—
QZSS – QZS-L1(2)	IODC	10	—	0-1023	—
QZSS – QZS-L1C/L2C/L5(1)(3)	LSBs of toe	10	300	0-306900	seconds
GLONASS	tb	7	15	15-1425	minutes
BDS(4)	bit 2 (MSB) to bit 11 (MSB) of toe	10	512	0-524288	seconds
Note 1: The MSB of toe is provided in IOD_MSB field. Note 2: If GANSS ID indicates ‘QZSS’, and GANSS Clock and Orbit Model-2 are included, this interpretation of IOD applies. Note 3: If GANSS ID indicates ‘QZSS’, and GANSS Clock and Orbit Model-3 are included, this interpretation of IOD applies . Note 4: If GANSS ID indicates ‘BDS’, the bit 2 (MSB) to bit 11 (MSB) are provided in IOD field and the bit 1 (MSB) is provided in IOD_MSB field.

Table A.48.2a: Interpretation of IOD_MSB

GANSS(1)	IOD_MSB	Scale Factor	Units	Comment
Modernized GPS	MSB of toe	307200	seconds	The full toe is constructed as "MSB of toe" x 307200 + "LSBs of toe" x 300 (Effective range of full toe is 0-604500 seconds)
QZSS – QZS-L1C/L2C/L5	MSB of toe	307200	seconds	The full toe is constructed as "MSB of toe" x 307200 + "LSBs of toe" x 300 (Effective range of full toe is 0-604500 seconds)
BDS	Bit 1 (MSB) of toe	524288	seconds	The full IOD is constructed as " IOD_MSB " x 524288+ "IOD" x 512 (Effective range of IOD is 0-604672 seconds)
Note 1: The IOD_MSB field shall not be present in GANSS Navigation Model for GANSS or GANSS signals not defined in this Table.

GANSS Clock Model

GANSS clock model (Model-1) contains one or two clock model elements. If included, Clock Model-1 shall be included once or twice depending on the MS capability.

If the MS is supporting multiple Galileo signals, the SMLC shall include both F/Nav and I/Nav clock models in GANSS Clock Model IE if the SMLC assumes the MS to perform Location Information calculation using multiple signals. The MS capabilities to support multiple GNSS frequencies are indicated in the Positioning Capability Response element (clause A.8). Otherwise, SMLC shall include only the model suitable for the GNSS.

Table A.49.1: GANSS Clock Model

Parameter	# Bits	Scale Factor	Units	Incl.
One of the following models can be included:
Model-1:
Satellite Clock Model (Galileo [11])
toc	14(u)	60	sec	C(1)
af2	6	2-59	sec/sec2	C(1)
af1	21	2-46	sec/sec	C(1)
af0	31	2-34	sec	C(1)
TGD (BGD)	10	2-32	sec	O(1)
Model ID	1	—	—	O
Model-2:
NAV Clock Model
toc	16	24	seconds	C(1)
af2	8	2-55	sec/sec2	C(1)
af1	16	2-43	sec/sec	C(1)
af0	22	2-31	seconds	C(1)
TGD	8	2-31	seconds	C(1)
Model-3:
CNAV/CNAV-2 Clock Model
toc	11	300	seconds	C(1)
top	11	300	seconds	C(1)
URAoc Index	5	—	—	C(1)
URAoc1 Index	3	—	—	C(1)
URAoc2 Index	3	—	—	C(1)
af2-n	10	2-60	sec/sec2	C(1)
af1-n	20	2-48	sec/sec	C(1)
af0-n	26	2-35	seconds	C(1)
TGD	13	2-35	seconds	C(1)
ISCL1CP	13	2-35	seconds	O(2)
ISCL1CD	13	2-35	seconds	O(2)
ISCL1C/A	13	2-35	seconds	O(3)
ISCL2C	13	2-35	seconds	O(3)
ISCL5I5	13	2-35	seconds	O(4)
ISCL5Q5	13	2-35	seconds	O(4)
Model-4:
GLONASS Satellite Clock Model
n(tb)	22	2-30	seconds	C(1)
n(tb)	11	2-40	—	C(1)
n	5	2-30	seconds	O
Model-5:
SBAS Satellite Clock Model
t0	13	16	seconds	C(1)
aGfo	12	2-31	seconds	C(1)
aGf1	8	2-40	Seconds/sec	C(1)
Model-6:
BDS Satellite Clock Model
AODC	5	—	—	C(1)
toc	17	23	seconds	C(1)
a0	24	2-33	sec/sec	C(1)
a1	22	2-50	sec/sec2	C(1)
a2	11	2-66	seconds	C(1)
TGD	10	10-10	seconds	C(1)
NOTE 1: All of these fields shall be present together, or none of them shall be present. NOTE 2: Both of these fields shall be present together, or none of them shall be present. NOTE 3: Both of these fields shall be present together, or none of them shall be present. NOTE 4: Both of these fields shall be present together, or none of them shall be present.

Model ID

This field specifies the identity of the clock model according to Table A.49.1a. This field is optional.

Table A.49.1a: Galileo Clock Model Identity

Value	Identity
0	I/Nav
1	F/Nav

GANSS Orbit Model

GANSS Orbit Model IE contains the following presentation: Satellite Navigation Model Using Keplerian Parameters or Satellite Navigation Model Using Earth-Centered, Earth-fixed Parameters as described in Table A.49.2.

Table A.49.2: GANSS Orbit Model

Parameter	# Bits	Scale Factor	Units	Incl.
One of the following models can be included:
Model-1:
Satellite Navigation Model Using Keplerian Parameters
toe	14(u)	60	sec	C
	32	2-31	semi-circles	C
n	16	2-43	semi-circles/sec	C
M0	32	2-31	semi-circles	C
OMEGAdot	24	2-43	semi-circles/sec	C
e	32(u)	2-33	—	C
Idot	14	2-43	semi-circles/sec	C
sqrtA	32(u)	2-19	meters1/2	C
i0	32	2-31	semi-circles	C
OMEGA0	32	2-31	semi-circles	C
Crs	16	2-5	meters	C
Cis	16	2-29	radians	C
Cus	16	2-29	radians	C
Crc	16	2-5	meters	C
Cic	16	2-29	radians	C
Cuc	16	2-29	radians	C
Model-2:
Satellite Navigation Model Using NAV Keplerian Parameters
URA Index	4	—	—	C
Fit Interval Flag	1	—	Boolean	C
toe	16	24	sec	C
	32	2-31	semi-circles	C
n	16	2-43	semi-circles/sec	C
M0	32	2-31	semi-circles	C
OMEGAdot	24	2-43	semi-circles/sec	C
e	32(u)	2-33	—	C
Idot	14	2-43	semi-circles/sec	C
sqrtA	32(u)	2-19	meters1/2	C
i0	32	2-31	semi-circles	C
OMEGA0	32	2-31	semi-circles	C
Crs	16	2-5	meters	C
Cis	16	2-29	radians	C
Cus	16	2-29	radians	C
Crc	16	2-5	meters	C
Cic	16	2-29	radians	C
Cuc	16	2-29	radians	C
Model-3:
Satellite Navigation Model Using CNAV/CNAV-2 Keplerian Parameters
top	11	300	seconds	C
URAoe Index	5	—	—	C
A	26	2-9	meters	C
A_dot	25	2-21	meters/sec	C
n0	17	2-44	semi-circles/sec	C
n0_dot	23	2-57	semi-circles/sec2	C
M0-n	33	2-32	semi-circles	C
en	33	2-34	—	C
n	33	2-32	semi-circles	C
0-n	33	2-32	semi-circles	C
_dot	17	2-44	semi-circles/sec	C
io-n	33	2-32	semi-circles	C
i0-n_dot	15	2-44	semi-circles/sec	C
Cis-n	16	2-30	radians	C
Cic-n	16	2-30	radians	C
Crs-n	24	2-8	meters	C
Crc-n	24	2-8	meters	C
Cus-n	21	2-30	radians	C
Cuc-n	21	2-30	radians	C
Model-4:
Satellite Navigation Model Using GLONASS Earth-Centered, Earth-fixed Parameters
En	5(u)	1	days	C
P1	2(u)	—	—	C
P2	1(u)	1	—	C
M	2(u)	1	—	O
	27	2-11	kilometers	C
	24	2-20	kilometres/second	C
	5	2-30	kilometres/second2	C
	27	2-11	kilometers	C
	24	2-20	kilometres/second	C
	5	2-30	kilometres/second2	C
	27	2-11	kilometers	C
	24	2-20	kilometres/second	C
	5	2-30	kilometres/second2	C
Model-5:
Satellite Navigation Model Using SBAS Earth-Centered, Earth-fixed Parameters
t0	13	16	seconds	O(1)
Accuracy	4	—	—	C
XG	30	0,08	meters	C
YG	30	0,08	meters	C
ZG	25	0,4	meters	C
XG Rate‑of‑Change	17	0,000625	meters/sec	C
YG Rate‑of‑Change	17	0,000625	meters/sec	C
ZG Rate‑of‑Change	18	0,004	meters/sec	C
XG Acceleration	10	0,0000125	meters/sec2	C
YG Acceleration	10	0,0000125	meters/sec2	C
ZG Acceleration	10	0,0000625	meters/sec2	C
Model-6:
Satellite Navigation Model Using BDS Keplerian Parameters
AODE	5	—	—	C
URA Index	4	—	—	C
toe	17	23	seconds	C
A1/2	32	2-19	meters1/2	C
e	32	2-33	—	C
	32	2-31	semi-circles	C
n	16	2-43	semi-circles/sec	C
M0	32	2-31	semi-circles	C
0	32	2-31	semi-circles	C
_dot	24	2-43	semi-circles/sec	C
i0	32	2-31	semi-circles	C
Idot	14	2-43	semi-circles/sec	C
Cuc	18	2-31	radians	C
Cus	18	2-31	radians	C
Crc	18	2-6	meters	C
Crs	18	2-6	meters	C
Cic	18	2-31	radians	C
Cis	18	2-31	radians	C
Note 1: If GANSS Clock Model-5 is not included, this field shall be present.
NOTE u: unsigned parameter

GANSS Real-Time Integrity

Integrity Monitor (IM) shall detect unhealthy (e.g., failed/failing) satellite signals and also shall inform users of measurement quality in DGANSS modes when satellite signals are healthy. Excessively large pseudo range errors, as evidenced by the magnitude of the corresponding DGANSS correction, shall be used to detect failed satellite signals. Unhealthy satellite signals should be detected within 10 seconds of the occurrence of the satellite signal failure. When unhealthy (e.g., failed/failing) satellite signals are detected, the assistance and/or DGANSS correction data shall not be supplied for these satellite signals. When the error in the IM computed position is excessive for solutions based upon healthy satellite signals only, DGANSS users shall be informed of measurement quality through the supplied UDRE values. After bad satellite signals have been indicated in the Real Time Integrity field, if the satellite signals return to healthy condition for some period of time, the indications for them shall be removed from this field.

GANSS Real-Time Integrity field of the GANSS Assistance Data Information Element contains parameters that describe the real-time status of the GANSS constellations. Primarily intended for non-differential applications, the real-time integrity of the satellite constellation is of importance as there is no differential correction data by which the mobile can determine the soundness of each satellite signal. GANSS Real-Time Integrity data communicates the health of the GNSS signals to the mobile in real-time. The format is shown in Table A.50. The SMLC shall always transmit the GANSS Real Time Integrity field with the current list of unhealthy signals, for any GANSS positioning attempt and whenever GANSS Assistance Data is sent. If the number of bad signals (NBS) is zero, then the GANSS Real Time Integrity field shall be omitted.

Table A.50: GANSS Real-Time Integrity

Parameter	# Bits	Scale Factor	Range	Units	Incl.
The following fields occur once per SV with bad signal (NBS times)
Bad_GNSS_SV_ID	6	1	—	—	M
Bad_GNSS_Signal_ID	8	1	—	—	O

NBS (Number of satellites with bad signal)

The NBS value indicates the number of satellites with bad signal.

Bad_GNSS_SV_ID

This field specifies the SV ID of the satellite with bad signal or signals. The interpretation of SV ID is defined in Table A.10.14.

Bad_GNSS_Signal_ID

This field identifies the bad signal of a satellite. Absence of this field means that all signals on the specific SV are bad. The interpretation of Bad_GNSS_Signal_ID is listed in Table A.59. If the satellite in question belongs to the modernized GPS constellation and has some healthy signals but bad L1C/A signal, Bad_GNSS_Signal_ID shall be present but may have all the bits set to ‘0’. Status of L1C/A signal shall be indicated with Real-Time Integrity IE in GPS Assistance Data Element.

GANSS Data Bit Assistance

This element provides data bit assistance data for specific satellite signals for data wipe-off. The data bits included in the assistance data depends on the GANSS and its signal.

Table A.51: GANSS Data Bit Assistance

Parameter	Bits	Resolution	Range	Incl.
GANSS TOD	6	1	0 – 59	M
The following fields occur once per satellite (N_SAT times)
SV ID	6	1	—	M
The following fields occur once per signal (N_SGN times)
GANSS_Signal_ID	3	1	0 – 7	M
N_BIT	10	1	1 – 1024	M
Data Bits	N_BIT	—	—	M

GANSS TOD

This field indicates the reference time of the first bit of the data in GANSS Data Bit Assistance in integer seconds in GNSS specific system time.

Data Bit Reference Time is given as modulo 60 s from GANSS TOD.

N_SAT

This field specifies the number of satellites in GANSS Data Bit Assistance element.

SV_ID

The field specifies the SV for which the GANSS Data Bit Assistance is given. The interpretation of SV ID is defined in Table A.10.14.

Range: 0 – 63

N_SGN

This field specifies the number of signals for which GANSS Data Bit Assistance is provided.

Range: 1 – 8

GANSS_Signal_ID

This field specifies the GANSS signal type of the GANSS Data Bit Assistance as listed in Table A.59.

N_BIT

This field indicates the number of bits (or symbols) included in the IE.

Data Bits

Data bits are contained in GNSS system and data type specific format.

In case of Galileo, it contains the FEC encoded and interleaved modulation symbols. The logical levels 1 and 0 correspond to signal levels -1 and +1, respectively. In case of Modernized GPS L1C, it contains the encoded and interleaved modulation symbols as defined in [14] section 3.2.3.1.

In case of Modernized GPS L2C, it contains either the NAV data modulation bits, the FEC encoded NAV data modulation symbols, or the FEC encoded CNAV data modulation symbols, dependent on the current signal configuration of this satellite as defined in [12, Table 3-III].

In case of Modernized GPS L5, it contains the FEC encoded CNAV data modulation symbols as defined in [13].

In case of SBAS, it contains the FEC encoded data modulation symbols as defined in [15].

In case of QZSS QZS-L1, it contains the NAV data modulation bits as defined in [16] section 5.2. In case of QZSS QZS-L1C, it contains the encoded and interleaved modulation symbols as defined in [16] section 5.3. In case of QZSS QZS-L2C, it contains the encoded modulation symbols as defined in [16] section 5.5. In case of QZSS QZS-L5, it contains the encoded modulation symbols as defined in [16] section 5.6.

In case of GLONASS, it contains the 100 sps differentially Manchester encoded modulation symbols as defined in [17] section 3.3.2.2.

In case of BDS, it contains the encoded and interleaved modulation symbols as defined in [18] section 5.1.3.

GANSS Reference Measurement Information

This field provides reference code and Doppler measurement information of visible satellites of a GANSS constellation. The information can be used as acquisition assistance to improve the sensitivity of the receiver.

These parameters describe the range and optionally the derivatives from respective satellites to the GANSS Reference Location at the GANSS Reference Time. The code phase and Doppler fields are aligned with the time provided in GANSS Reference Time. Figure A.4a illustrates the relation between some of the fields with respect to the GANSS TOD.

If GPS Acquisition Assistance is included the Reference Time included in the GPS Acquisition Assistance is also valid for the GANSS Reference Measurement fields and the parameters are referenced to GPS TOW. Figure A.4b illustrates the relation between some of the fields with respect to GPS TOW.

The parameters are given in units of ms and m/s which makes it possible to convert the values to any nominal frequency and chipping and code rate.

Table A.52: GANSS Reference Measurement Information Contents

Parameter	Range	Bits	Resolution	Incl.
GANSS_Signal_ID	0 – 7	3	—	M
The following fields occur once per satellite (Num_Sat times)
SV_ID	0 – 63	6		M
Doppler (0th order term)	-1024 m/s to 1023,5 m/s	12	0,5 m/s	M
Doppler (1st order term)	-0,2 – 0,1 m/s2.	6	1/210 m/s2.	O(1)
Doppler Uncertainty	2,5 m/s – 40 m/s [2-n(40) m/s, n = 0 – 4]	3	—	O(1,3)
Code Phase	0 – (1-2-10) ms	10	2-10 ms	M
Integer Code Phase	0 – 127 ms	7	1 ms	M
Code Phase Search Window	See Table A.53	5	—	M
Azimuth	0 – 348,75 deg	5	11,25 deg	O(2)
Elevation	0 – 78,75 deg	3	11,25 deg	O(2)
Code Phase_1023	boolean	1	—	O
NOTE 1,2: All of these fields shall be present together, or none of them shall be present. NOTE 3: If Doppler Uncertainty Extension (Table A.55.25) is present, Doppler Uncertainty shall be set to value 0 (40 m/s).

Figure A.4a. Exemplary calculations of some GANSS Reference Measurement fields with respect to GANSS TOD.

Figure A.4b. Exemplary calculations of some GANSS Reference Measurement fields with respect to GPS TOW.

GANSS_Signal_ID

This field specifies the GNSS signal type. The supported signals are listed in Table A.59.

Num_Sat

This field specifies the number of satellites in GANSS Reference Measurement Information element.

SV_ID

This field specifies the SV for which the GANSS Reference Measurement Assistance is given. The interpretation of SV ID is defined in Table A.10.14.

Range: 0 – 63

Doppler (0^th order term)

This field contains the Doppler (0^th order term) value. A positive value in Doppler defines the increase in satellite signal frequency due to velocity towards the MS. A negative value in Doppler defines the decrease in satellite signal frequency due to velocity away from the MS.

Doppler is given in unit of m/s by multiplying the Doppler value in Hz by the nominal wavelength of the assisted signal.

This field is mandatory.

Doppler (1^st order term)

This field contains the Doppler (1^st order term) value. A positive value defines the rate of increase in satellite signal frequency due to acceleration towards the MS. A negative value defines the rate of decrease in satellite signal frequency due to acceleration away from the MS.

Doppler (1^st order term) is given in unit of m/s by multiplying the Doppler value in Hz by the nominal wavelength of the assisted signal.

This field is optional.

Doppler Uncertainty

This field contains the Doppler uncertainty value. It is defined such that the Doppler experienced by a stationary MS is in the range "Doppler  Doppler Uncertainty" to "Doppler  Doppler Uncertainty". This field is optional. If Doppler Uncertainty (together with Doppler 1^st order term) is omitted, the terminal shall interpret Doppler Uncertainty as greater than +/-40 m/s. If the Doppler Uncertainty Extension (Table A.55.25) field is present, the MS that supports the Doppler Uncertainty Extension shall ignore this field.

Doppler Uncertainty is given in unit of m/s by multiplying the Doppler Uncertainty value in Hz by the nominal wavelength of the assisted signal.

Permitted Values: 2,5 m/s, 5 m/s, 10 m/s, 20 m/s, 40 m/s as encoded by an integer n in the range 0-4 according to the formula in Table A.52.

Code Phase

This field together with the Code Phase_1023 field contains code phase, in units of milliseconds, in the range from 0 to 1 millisecond scaled by the nominal chipping rate of the GNSS signal, where increasing values of the field signify increasing predicted signal code phases, as seen by a receiver at the Reference Location at the GANSS Reference Time. The Reference Location would typically be an apriori estimate of the MS location. This field is mandatory.

Range: 0 – (1-2^-10) ms

NOTE: The value (1-2^-10) ms is encoded using the Code Phase_1023 field.

Integer Code Phase

This field contains integer code phase (expressed modulo 128 ms). The satellite integer milliseconds code phase currently being transmitted at the GANSS Reference Time, as seen by a receiver at the Reference Location is calculated as reference time (GANSS TOD or GPS TOW, expressed in milliseconds) minus (Integer_Code_Phase + (n×128 ms)), as shown in Figure A.4a/b, with n = …-2,-1,0,1,2…. This field is mandatory.

Range: 0-127 ms

Code Phase Search Window

This field contains the code phase search window. The code phase search window accounts for the uncertainty in the estimated MS location but not any uncertainty in GANSS Reference Time. It is defined such that the expected code phase is in the range "Code Phase – Code Phase Search Window" to "Code Phase + Code Phase Search Window" given in units of milliseconds. This field is mandatory.

Range: 0-31 (i.e. 0,002 – 2,000 ms according to following table)

Table A.53: Code Phase Search Window Parameter Format

CODE_PHASE_SEARCH_WINDOW	Code Phase Search Window [ms]
‘00000’	No information
‘00001’	0,002
‘00010’	0,004
‘00011’	0,008
‘00100’	0,012
‘00101’	0,016
‘00110’	0,024
‘00111’	0,032
‘01000’	0,048
‘01001’	0,064
‘01010’	0,096
‘01011’	0,128
‘01100’	0,164
‘01101’	0,200
‘01110’	0,250
‘01111’	0,300
‘10000’	0,360
‘10001’	0,420
‘10010’	0,480
‘10011’	0,540
‘10100’	0,600
‘10101’	0,660
‘10110’	0,720
‘10111’	0,780
‘11000’	0,850
‘11001’	1,000
‘11010’	1,150
‘11011’	1,300
‘11100’	1,450
‘11101’	1,600
‘11110’	1,800
‘11111’	2,000

Azimuth

This field together with the Azimuth LSB included in GANSS Reference Measurement Extension in Table A.55.23contains the azimuth angle. An angle of x degrees means the satellite azimuth a is in the range (x  a < x+0,703125) degrees. This field is optional.

Range: 0 – 359,296875 degrees.

Elevation

This field together with the Elevation LSB included in GANSS Reference Measurement Extension in Table A.55.23 contains the elevation angle. An angle of y degrees means the satellite elevation e is in the range (y  e < y+0,703125) degrees except for y = 89,296875 where the range is extended to include 90 degrees. This field is optional.

Range: 0 – 89,296875 degrees

Code Phase_1023

This field if set to TRUE indicates that the code phase has the value 1023 × 2^-10 = (1-2^-10) ms. This field may only be set to TRUE if the value provided in the Code Phase field is 1022. If this field is set to FALSE, the code phase is the value provided in the Code Phase field in the range from 0 to (1 – 2×2^-10) ms. If this field is not present and the Code Phase field has the value 1022, the MS may assume that the code phase is between (1 – 2×2^-10) and (1 – 2^-10) ms.

GANSS Almanac Model

These fields specify the coarse, long-term model of the satellite positions and clocks. These fields are given in Table A.54. The meaning of these parameters is defined in relevant ICDs of the particular GANSS and GNSS specific interpretations apply. For example, Modernized GPS and QZSS use the same model parameters but some parameters have a different interpretation [16].

GANSS Almanac Model is useful for receiver tasks that require coarse accuracy, such as determining satellite visibility. The model is valid for up to few weeks, typically. Since it is a long-term model, the field should be provided for all satellites in the GNSS constellation. If almanac is not provided for the full GNSS constellation, the SMLC shall set the Complete Almanac Provided field in Table A.55.24 to FALSE.

Table A.54: GANSS Almanac Model (per-satellite fields – ⁽¹⁾ = Positive range only)

Parameter	# Bits	Scale Factor	Units	Incl.
The following fields occur once per message
Num_Sats_Total	6	1	—	M
Week Number	8	1	weeks	M
Toa	8	212 if GANSS-ID is not Galileo. 600 if GANSS-ID is Galileo	s	O
IODa	2	—	—	O
One of the following models can be included:
Model-1:
This model occurs once per satellite (Num_Sats_Total times)
GANSS Almanac Model Using Keplerian Parameters
SV_ID	6	—	—	M
e	11	2-16	dimensionless	M
i	11	2-14	semi-circles	M
OMEGADOT	11	2-33	semi-circles/sec	M
SV Status INAV	4	—	dimensionless	M
SV Status FNAV	2	—	dimensionless	O
delta_A1/2	13	2-9	meters1/2	M
OMEGA0	16	2-15	semi-circles	M
	16	2-15	semi-circles	M
M0	16	2-15	semi-circles	M
af0	16	2-19	seconds	M
af1	13	2-38	sec/sec	M
Model-2: This model occurs once per satellite (Num_Sats_Total times) GANSS Almanac Model Using NAV Keplerian Parameters SV_ID 6 — — M e 16 2-21 dimensionless M i 16 2-19 semi-circles M OMEGADOT 16 2-38 semi-circles/sec M SV Health 8 — Boolean M A1/2 24 2-11 meters1/2 M OMEGA0 24 2-23 semi-circles M  24 2-23 semi-circles M M0 24 2-23 semi-circles M af0 11 2-20 seconds M af1 11 2-38 sec/sec M Model-3: This model occurs once per satellite (Num_Sats_Total times) GANSS Almanac Model Using Reduced Keplerian Parameters SV_ID 6 — — M A 8 2+9 meters M 0 7 2-6 semi-cicles M 0 7 2-6 semi-circles M L1 Health 1 — — M L2 Health 1 — — M L5 Health 1 — — M
Model-4: This model occurs once per satellite (Num_Sats_Total times) GANSS Almanac Model Using Midi Keplerian Parameters SV_ID 6 — — M e 11 2-16 — M i 11 2-14 semi-circles M _dot 11 2-33 semi-circles/sec M sqrtA 17 2-4 meters1/2 M 0 16 2-15 semi-circles M  16 2-15 semi-circles M M0 16 2-15 semi-circles M afo 11 2-20 seconds M af1 10 2-37 sec/sec M L1 Health 1 — — M L2 Health 1 — — M L5 Health 1 — — M
Model-5:
This model occurs once per satellite (Num_Sats_Total times)
GANSS Almanac Model Using GLONASS Keplerian Parameters
NA	11	1	days	M
nA	5	1	—	M
HnA	5	1	—	M
nA	21	2-20	semi-circles	M
tnA	21	2-5	seconds	M
inA	18	2-20	semi-circles	M
TnA	22	2-9	seconds/orbit period	M
T_DOTnA	7	2-14	seconds/orbit period2	M
nA	15	2-20	—	M
nA	16	2-15	semi-circles	M
nA	10	2-18	seconds	M
CnA	1	1	—	M
MnA	2	1	—	O
Model-6:
This model occurs once per satellite (Num_Sats_Total times)
GANSS Almanac Model Using SBAS ECEF Parameters
Data ID	2	1	—	M
SV_ID	6	—	—	M
Health	8	—	—	M
XG	15	2600	meters	M
YG	15	2600	meters	M
ZG	9	26000	meters	M
XG Rate-of-Change	3	10	meters/sec	M
YG Rate-of-Change	3	10	meters/sec	M
ZG Rate-of-Change	4	40,96	meters/sec	M
t0	11	64	seconds	M
Model-7:
This model occurs once per satellite (Num_Sats_Total times)
GANSS Almanac Model Using BDS Keplerian Parameters
SV_ID		—		M
toa	8	212	seconds	O(note 2)
A1/2	24	2-11	meters1/2	M
e	17	2-21	—	M
	24	2-23	semi-circles	M
M0	24	2-23	semi-circles	M
0	24	2-23	semi-circles	M
_dot	17	2-38	semi-circles/sec	M
i	16	2-19	semi-circles	M
a0	11	2-20	seconds	M
a1	11	2-38	sec/sec	M
Hea	9	—	—	O (note 3)
NOTE 2: This field may be present if the toa is not the same for all SVs; otherwise it is not present and the toa is provided in GANSSAlmanacModel NOTE 3: This IE is mandatory present if the IE "SV ID" is between 0 and 29 and not needed otherwise.

Num_Sats_Total

This field specifies the total number of satellites in GANSS Almanac Model.

Range: 1 – 36

Week Number

This field specifies the Almanac reference week number in GNSS specific system time to which the Almanac Reference Time T_oa is referenced, modulo 256 weeks. If T_oa is not included in GANSS Almanac Model, the MS shall ignore the Week Number.

Range: 0 – 255

NOTE: In case of Galileo, the almanac reference week number WN_a natively contains only the 2 LSB’s [11, section 5.1.10].

T_oa

This field specifies the Almanac Reference Time common to all satellites in GANSS Almanac Model Using Keplerian Parameters given in GNSS specific system time.

Range: 0 – 255

In case of GNSS-ID does not indicate Galileo, the scale factor is 2¹² seconds. In case of GNSS-ID does indicate Galileo, the scale factor is 600 seconds.

NOTE: Range extension of T_oa may be present in the GANSS Almanac Model Extension-R12 element (Table A.55.25), if GANSS-ID indicates Galileo.

IOD_a

This field specifies the Issue-Of-Data common to all satellites in GANSS Almanac Model using Keplerian Parameters.

Range: 0 – 3

NOTE: Range extension of IOD_a may be present in the GANSS Almanac Model Extension-R12 element (Table A.55.25), if GANSS-ID indicates Galileo.

SV_ID

This field identifies the satellite for which the GANSS Almanac Model is given. The interpretation of SV ID is defined in Table A.10.14.

Range: 0 – 63

SV Status INAV

This field contains the I/NAV health status bits [11, section 5.1.10].

SV Status FNAV

This field contains the F/NAV health status bits [11, section 5.1.10]. If the MS is supporting multiple Galileo signals, the SMLC shall include this field.

GANSS UTC Model

The GANSS UTC Model field contains a set of parameters needed to relate GNSS system time to Universal Time Coordinate (UTC). All of the fields in the GANSS UTC Model are mandatory when the field is present. The UTC time standard, UTC(k), is GNSS specific. E.g., if GANSS ID indicates QZSS, GANSS UTC Model field contains a set of parameters needed to relate QZST to UTC(NICT).

Table A.55: GANSS UTC Model (Model-1)

Parameter	# Bits	Scale Factor	Units	Incl.
A1	24	2-50	sec/sec	C
A0	32	2-30	seconds	C
tot	8	212	seconds	C
WNt	8	1	weeks	C
tLS	8	1	seconds	C
WNLSF	8	1	weeks	C
DN	8	1	days	C
tLSF	8	1	seconds	C

GANSS Ephemeris Extension

The GANSS Ephemeris extension contains parameters designed to extend the time of applicability of the Ephemeris terms by the continuous addition of the delta ephemeris terms to the respective terms of the referenced ephemeris.

This message can provide extension information for every satellite for many days into the future; doing so may create a large message, thus care must be taken to consider the transport bandwidth. The SMLC can limit the duration of the extension to decrease the message size. For example if the extension duration is limited to twelve hours the payload will be approximately 2,000 octets, for a typical 27 satellite constellation.

Table A.55.2: GANSS Ephemeris Extension

Parameter	# Bits	Scale Factor	Units	Incl.
ganssEphemerisHeader	See Table A.55.3		—	O
ganssReferenceSet	See Table A.55.5		—	O
ganssEphemerisDeltaMatrix	List of GANSSEphemerisDeltaEpochs			O

Table A.55.3: GANSS Ephemeris Header

Parameter	# Bits	Scale Factor	Units	Incl.
GANSS Ephemeris Extension (Once per message)
timeAtEstimation	See Table A.55.4		—	M
validityPeriod	3	1	Hours	M
ephemerisExtensionDuration	9	1	Hours	M

Time at Estimation

The Time at Estimation provides the GANSS time at which the ephemeris extensions were created.

Table A.55.4: Time at Estimation

Parameter	# Bits	Scale Factor	Units	Incl.
GANSS Day of Estimation	13	1	Day	M
GANSS TOD of Estimation	17	1	Seconds	M

GANSS Day of Estimation

This field specifies the sequential number of days (with day count starting at 0) from the origin of the GNSS system time indicated by GANSS_TIME_ID modulo 8192 days (about 22 years) of the time that the estimation was determined. The GNSS system time origin is defined in Table A.34 for each GANSS.

Range: 0 – 8191 days

GANSS TOD of Estimation

Integer number of GANSS TOD seconds within the current day of the time that the estimation was determined.

Range: 0 – 86399 s.

Validity Period

The validityPeriod indicates the validity period of the GANSS Reference Set. It also indicates the default validity period of each individual delta ephemeris packet in the case that the individual validityPeriod is not present in the GANSS Delta Epoch Header (see Table A.55.8). It is the length of time that the GANSS Reference Set is intended to last and, if applicable, it is the length of time that the ephemeris constructed by application of the delta is intended to last.

Range: 1 – 8 hours.

Ephemeris Extension Duration

The Ephemeris Extension duration indicates the total block of time measured in units of hours that the extended ephemeris covers.

Range: 1 – 512 Hours.

The ganssEphemeris header is mandatory only once in the delivery of the GANSS Ephemeris Extension message

GANSS Reference Set

Table A.55.5: GANSS Reference Set

Parameter	Presence	Note
GANSS Reference Orbit	M	See Table A.55.6

GANSS Reference Orbit

Table A.55.6: GANSS Reference Orbit

Parameter	# Bits	Scale Factor	Units	Incl.
svID	6	1	—	M
ganssOrbitModel	See Table A.29.g		—	M
ganssClockModel	See Table A.49.1		—	M

SvID

The satellite vehicle ID identifying to which satellite the following orbital and clock model apply. The interpretation of SV ID is defined in Table A.10.14.

GANSS OrbitModel

This field is a structure that contains the Reference Nav Model (see Table A.29.g) satellite orbit information upon which all subsequent delta information will be applied to create the next ephemeris for use in navigation.

GANSS ClockModel

This field is a structure that contains the satellite clock model upon which all subsequent clock information will be applied to create the next clock model for use in navigation.

GANSA Ephemeris Delta Matrix

GANSS Ephemeris Delta Matrix is a list of GANSS Ephemeris Delta Epochs. Each epoch is indicated by a unique seqNum. Each epoch corresponds to a specific update interval and contains a delta epoch header and ephemeris delta elements for all PRNs for that epoch.

GANSS Ephemeris Delta Epoch

Table A.55.7: GANSS Ephemeris Delta Epoch

Parameter	Note	Incl.
ganssDeltaEpochHeader	See Table A.55.8	O
ganssDeltaElementList	List of GANSS Ephemeris Delta Elements	M

GANSS Delta Epoch Header

Table A.55.8: GANSS Delta Epoch Header

Parameter	# Bits	Scale Factor	Units	Incl.
validityPeriod	3	1	Hours	O
ephemerisDeltaSizes	See Table A.55.9			O
ephemerisDeltaScales	See Table A.55.10			O

Validity Period

The validityPeriod indicates the validity period of each individual delta ephemeris packet. It is the length of time that the ephemeris constructed by application of the delta is intended to last. If not present then the default validityPeriod in the GANSS Ephemeris Header IE applies (see Table A.55.3).

Range: 1 – 8 hours.

Ephemeris Delta Sizes

This field is a structure that indicates the bit sizes for all the fields in the GANSS Ephemeris Delta structure

Table A.55.9: GANSS Ephemeris Delta Sizes

Parameter	# Bits	Scale Factor	Units	Incl.
bitSize_delta_	5	1	—	M
bitSize_delta_n	4	1	—	M
bitSize_delta_M0	5	1	—	M
bitSize_delta_OMEGAdot	5	1	—	M
bitSize_delta_e	5	1	—	M
bitSize_delta_Idot	4	1	—	M
bitSize_delta_sqrtA	5	1	—	M
bitSize_delta_i0	5	1	—	M
bitSize_delta_OMEGA0	5	1	—	M
bitSize_delta_Crs	4	1	—	M
bitSize_delta_Cis	4	1	—	M
bitSize_delta_Cus	4	1	—	M
bitSize_delta_Crc	4	1	—	M
bitSize_delta_Cic	4	1	—	M
bitSize_delta_Cuc	4	1	—	M
bitSize_delta_tgd1	4	1	—	M
bitSize_delta_tgd2	4	1	—	M

Ephemeris Delta Scales

This field is a structure that indicates the scale factor modifiers for all the fields in the GANSS Ephemeris Delta structure.

Table A.55.10: GANSS Ephemeris Delta Scales

Parameter	# Bits	Scale Factor	Units	Incl.
scale_delta_	5	1	—	M
scale_delta_n	5	1	—	M
scale_delta_M0	5	1	—	M
scale_delta_OMEGAdot	5	1	—	M
scale_delta_e	5	1	—	M
scale_delta_Idot	5	1	—	M
scale_delta_sqrtA	5	1	—	M
scale_delta_i0	5	1	—	M
scale_delta_OMEGA0	5	1	—	M
scale_delta_Crs	5	1	—	M
scale_delta_Cis	5	1	—	M
scale_delta_Cus	5	1	—	M
scale_delta_Crc	5	1	—	M
scale_delta_Cic	5	1	—	M
scale_delta_Cuc	5	1	—	M
scale_delta_tgd1	5	1	—	M
scale_delta_tgd2	5	1	—	M

GANSS Delta Element List

GANSS Delta Element List is a list of GANSS Ephemeris Delta Elements

Ephemeris Delta Element

Each GANSS Ephemeris Delta element is uniquely identified by the pair (seqNum, sv_ID) and it is defined as a structure as shown in table A.55.11. The MS should parse the octet string according to the fields specified in table A.55.4. Each element in table A.55.4 but for seqNum and sv_ID should be treated as a signed integer. Each Ephemeris delta is transmitted as an octet string of up to 49 octets. The actual number of octets is determined by the size of the bit fields in the GPS_Ephemeris_Delta_Sizes table (table A.55.9). Each set of up to 49 octets represents a single extension for a single satellite vehicle. Each set encodes the satellite vehicle ID and the sequence number. The sequence number specifies the order in which the individual ephemeris extension elements are assembled as time marches forward to create the next ephemeris. The sequence number is the same for all satellite vehicle IDs for a particular update period.

Table A.55.11: GANSS Ephemeris Delta Element

Parameter	# Bits	Default # Bits	Scale Factor	Default Scale	Units	Incl.
sequenceNum	7		1	1	—	M
svID	6		1	1	—	M
delta_	1..32 (1)	21	2-16*2-31 .. 215*2-31 (2)	2-31	semi-circles	M
delta_n	1..16 (1)	12	2-16*2-43 .. 215*2-43 (2)	2-43	semi-circles/sec	M
delta_M0	1..32 (1)	21	2-16*2-31 .. 215*2-31 (2)	2-31	semi-circles	M
delta_OMEGAdot	1..24 (1)	13	2-16*2-43 .. 215*2-43 (2)	2-43	semi-circles/sec	M
delta_e	1..32 (1)	18	2-16*2-33 .. 215*2-33 (2)	2-33	—	M
delta_Idot	1..14 (1)	11	2-16*2-43 .. 215*2-43 (2)	2-43	semi-circles/sec	M
delta_sqrtA	1..32 (1)	14	2-16*2-19 .. 215*2-19 (2)	2-19	meters1/2	M
delta_i0	1..32 (1)	14	2-16*2-31 .. 215*2-31 (2)	2-31	semi-circles	M
delta_OMEGA0	1..32 (1)	14	2-16*2-31 .. 215*2-31 (2)	2-31	semi-circles	M
delta_Crs	1..16 (1)	12	2-16*2-5 .. 215*2-5 (2)	2-5	meters	M
delta_Cis	1..16 (1)	11	2-16*2-29 .. 215*2-29 (2)	2-29	radians	M
delta_Cus	1..16 (1)	12	2-16*2-29 .. 215*2-29 (2)	2-29	radians	M
delta_Crc	1..16 (1)	12	2-16*2-5 .. 215*2-5 (2)	2-5	meters	M
delta_Cic	1..16 (1)	11	2-16*2-29 .. 215*2-29 (2)	2-29	radians	M
delta_Cuc	1..16 (1)	12	2-16*2-29 .. 215*2-29 (2)	2-29	radians	M
delta_tgd1	1..16 (1)	2	2-16*2-31 .. 215*2-31 (2)	2-31	seconds	M
delta_tgd2	1..16 (1)	2	2-16*2-31 .. 215*2-31 (2)	2-31	seconds	M

(1) The number of bits of each signed integer field is variable and it is indicated once for all numEphemerisDeltas by the structure ephemerisDeltasSizes. When the ephemerisDeltaSizes field is not present, the values found in the columns "Default # Bits" shall be used.

(2) The scale factor of each parameter is variable around the default scale factor. The variation for each field is indicated once for all numEphemerisDeltas by the structure ephemerisDeltasScales. For example, if the scale factor modifier for delta_omega has a value of 4, the scale factor for delta_omega is 2⁴ * 2^-31. When the ephemerisDeltaScales is not used, the values found in the column "Default Scale" shall be used.

sequenceNum

This field indicates the order of the Ephemeris delta terms. The ephemeris constructed for use in satellite positioning is built by adding the delta terms to the referenced GANSS_Navigation Model in the order dictated by this sequence number. The sequence number shall remain the same for each svID in a group of Ephemeris Deltas corresponding to a particular update epoch.

svID

This field identifies the satellite ID within a particular sequenceNum.

These fields, with the exception of sequenceNum and svID, specify the deltas to be added to the existing Ephemeris to create a new Ephemeris suite that is extended from its predecessor by the time provided in the "validityPeriod" parameter. To compute the time of ephemeris for the newly constructed ephemeris, validityPeriod is added to the preceding toe. The ephemeris time of clock (toc) is set equal to the toe.

For each of the other ephemeris terms the corresponding delta ephemeris term is added in order to create the updated ephemeris. The terms delta_M0, delta_i0, and delta_OMEGA0 of the delta ephemeris must be extrapolated prior to the addition of the delta terms as follows:

Where is the WGS 84 value of the earth’s gravitational constant for GANSS user, and A_(i) is the semi-major axis associated with this satellite’s update. The extrapolation of delta_M0, uses the prior set’s sqrtA term to compute A_(i) .

OMEGA0_(i+1)=OMEGA0_(i) +deltaOMEGA0_(i)+OMEGAdot_(i)*dt

i0 _(i+1) = i0_(i) + delta_i0_(i)+Idot_(i) * dt

Where dt is equal to validityPeriod*3600. The terms af0, and af1 from the GANSS clock model must be extrapolated as follows:

af0_(i+1) = af0_(i) + af1_(i)* dt + af2_(i)*dt²

af1_(i+1) = af1_(i) + 2 * af2_(i) * dt

af2_(i+1) = af2_(i)

Where af0, af1, and af2 are the clock model terms as shown in table A.49.1.

The following demonstrates the application of the ephemeris extension technique. Assume the validityPeriod = 5, representing: (5+1)hours = 6 hours, and the GANSS Navigation model for a particular satellite, identified by the reference IOD has a toe = 0 seconds.

The toe for sequenceNumber 1 is computed by adding the validityPeriod to the initial toe of 0 as 0 + 6 hours =0 + 21600 seconds. The new ephemeris is constructed by adding the delta ephemeris terms from set 1 to the reference ephemeris creating the new ephemeris, which will be used for the next six hours. For the five terms listed above (delta_M0, delta_i0, delta_OMEGA0, af0, and af1) the extrapolation described must occur prior to the addition of the delta term. Of course if one of these three delta ephemeris terms was provided in full via the exception table then the extrapolation is unnecessary and the exception term combined with the delta_ephemeris term is used directly.

The next ephemeris computation will occur by adding the validityPeriod to the current toe of 21600 as: 21600 + 6 hours = 21600 + 21600 = 43200. The ephemeris delta terms from set two are added to the ephemeris resulting from the prior addition to create the next ephemeris. This is done for each satellite vehicle ID listed in the provided satellite list indicated in the ganssSatRef field.

GANSS Ephemeris Extension check

The GANSS Ephemeris Extension check provides information about non foreseen events that occurred during the period starting at the ganssBeginTime to the current time. An event is signified through a bit string . Each bits refers to one PRN. If a bit is set to one, this means that the ephemeris extension is no longer valid for this specific PRN. In order to indicate planned future manuvers an end time is provided. The SMLC can indicate that a future event is planned between the current time and the end time of this ephemeris extension.

Table A.55.12: Ephemeris Extension check

Parameter	Presence	Note
ganssBeginTime	M	See Table A.55.13
ganssEndTime	M	See Table A.55.14
ganssSatEventsInfo	M	See Table A.55.15

GANSS Begin Time

The GANSS begin time corresponds to the GANSS Day and GANSS Seconds of Estimation of the ephemeris extensions block.

Table A.55.13: GANSS Begin Time

Parameter	# Bits	Scale Factor	Units	Incl.
GANSS Day	13	1	Day	M
GANSS TOD	17	1	Seconds	M

GANSS End Time

The GANSS end time represents the final time the Ephemeris extension is valid.

Table A.55.14: GANSS End Time

Parameter	# Bits	Scale Factor	Units	Incl.
GANSS Day	13	1	Day	M
GANSS TOD	17	1	Seconds	M

GANSS Sat Event Information

This IE is designed to indicate events that have or may occur between the ganssBeginTime and the ganssEndTime.

Table A.55.15: GANSS Sat Event Information

Parameter	# Bits	Scale Factor	Units	Incl.
EventOccurred	64	–	–	M
FutureEventNoted	64	–	–	M

EventOccurred

FutureEventNoted

If a bit is clear in the eventOccured field it indicates that a satellite maneuver has not occurred since the ganssBeginTime nor is a maneuver planned for the next sixty minutes.

If a bit is set in the futureEventNoted field it indicates that a maneuver is planned during the time period between current time plus sixty minutes and ganssEndTime

SBAS ID

If GANSS ID indicates SBAS, this field defines the specific SBAS for which the GANSS specific assistance data are provided according to Table A.55.16.

Table A.55.16: SBAS ID

SBAS	Value of SBAS ID
WAAS	0
EGNOS	1
MSAS	2
GAGAN	3
Reserved	4-7

GANSS Additional UTC Model

The GANSS Additional UTC Model field contains several sets of parameters needed to relate GNSS system time to Universal Time Coordinate (UTC), as defined in [12, 13, 14, 15, 16, 17]. Only one parameter set can be included in one GANSS Additional UTC Model and which set of parameters to include depends on the GANSS-ID and MS capabilities.

The UTC time standard, UTC(k), is GNSS specific. E.g., if GANSS ID indicates QZSS, GANSS Additional UTC Model field contains a set of parameters needed to relate QZST to UTC(NICT). If GANSS ID indicates Modernized GPS, GANSS Additional UTC Model field contains a set of parameters needed to relate GPS system time to UTC(USNO). If GANSS ID indicates GLONASS, GANSS Additional UTC Model field contains a set of parameters needed to relate GLONASS system time to UTC(RU). If GANSS ID indicates SBAS, GANSS Additional UTC Model field contains a set of parameters needed to relate SBAS network time for the SBAS indicated by SBAS ID to the UTC standard defined by the UTC Standard ID. If GANSS ID indicates BDS, GANSS Additional UTC Model field contains a set of parameters needed to relate BDS system time to UTC (NTSC).

Table A.55.17: GANSS Additional UTC Model

Parameter	# Bits	Scale Factor	Units	Incl.
One of the following models can be included:
Model-2 (as defined in [12,13,14,16])
A0-n	16	2-35	seconds	C(1)
A1-n	13	2-51	sec/sec	C(1)
A2-n	7	2-68	sec/sec2	C(1)
tLS	8	1	seconds	C(1)
tot	16	24	seconds	C(1)
WNot	13	1	weeks	C(1)
WNLSF	8	1	weeks	C(1)
DN	4	1	days	C(1)
tLSF	8	1	seconds	C(1)
Model-3 (as defined in [17])
NA	11	1	days	C(1)
c	32	2-31	seconds	C(1)
B1	11	2-10	seconds	O(2)
B2	10	2-16	sec/msd	O(2)
KP	2	1	—	O
Model-4 (as defined in [15], Message Type 12)
A1WNT	24	2-50	sec/sec	C(1)
A0WNT	32	2-30	seconds	C(1)
tot	8	212	seconds	C(1)
WNt	8	1	weeks	C(1)
tLS	8	1	seconds	C(1)
WNLSF	8	1	weeks	C(1)
DN	8	1	days	C(1)
tLSF	8	1	seconds	C(1)
UTC Standard ID	3	1	—	C(1)
Model-5 (as defined in [18])
A0UTC	32	2-30	Seconds	C(1)
A1UTC	24	2-50	sec/sec	C(1)
tLS	8	1	Seconds	C(1)
WNLSF	8	1	Weeks	C(1)
DN	8	1	Days	C(1)
tLSF	8	1	Seconds	C(1)
Note 1: All of these fields shall be present together, or none of them shall be present. Note 2: If the optional elements are included, both elements shall be included.

UTC Standard ID

If GANSS ID indicates SBAS, this field indicates the UTC standard used for the SBAS network time indicated by SBAS ID to UTC relation as defined in Table A.55.18 ( [15], Message Type 12).

Table A.55.18: UTC Standard ID

UTC Standard	Value of UTC Standard ID
UTC as operated by the Communications Research Laboratory (CRL), Tokyo, Japan	0
UTC as operated by the National Institute of Standards and Technology (NIST)	1
UTC as operated by the U. S. Naval Observatory (USNO)	2
UTC as operated by the International Bureau of Weights and Measures (BIPM)	3
Reserved for future definition	4-7

GANSS Auxiliary Information

This field contains additional information dependent on the GANSS ID and is shown in Table A.55.19. If GANSS Auxiliary Information is provided together with other satellite dependent GANSS assistance data (i.e., any of DGANSS Corrections, GANSS Navigation Model, GANSS Data Bit Assistance, or GANSS Reference Measurement Information IEs) and RRLP pseudo-segmentation is used, the GANSS Auxiliary Information should be provided for the same satellites and in the same RRLP segment as the other satellite dependent GANSS assistance data.

Table A.55.19: GANSS Auxiliary Information Parameter Format

Parameter		Range	Bits		Resolution	Incl.
One of the following group of elements can be included, dependent on the GANSS ID
The following fields may only be present if GANSS ID indicates Modernized GPS and occur once per satellite (N_SAT times):
SV ID	0-63		6	—		M
Signals Available	Table A.59		8	—		M
The following fields may only be present if GANSS ID indicates GLONASS and occur once per satellite (N_SAT times):
SV ID		0-63	6		—	M
Signals Available		Table A.59	8		—	M
Channel number		-7 – 13	5		—	M

SV_ID

This field specifies the SV for which the GANSS Auxiliary Information is given. The interpretation of SV ID is defined in Table A.10.14.

Range: 0 – 63

Signals Available

This field indicates the ranging signals supported by the satellite indicated by SV ID. This field is given as a bit string as shown in Table A.59 for a particular GANSS. If a bit is set to ‘1’ it indicates that the satellite identified by SV ID transmits ranging signals according to the signal correspondence in Table A.59. If a bit is set to ‘0’ it indicates that the corresponding signal is not supported on the satellite identified by SV ID.

Channel number

This field indicates the GLONASS carrier frequency number of the satellite identified by SV ID, as defined in [17].

DGANSS Corrections Validity Period

This element is an extension to the DGANSS Corrections IE and provides the validity period of the differential corrections for each satellite and signal included in the DGANSS Corrections IE (see Table A.43). This element may only be included if the DGANSS Corrections IE is included in the GANSS Generic Assistance Data element.

Table A.55.20: DGANSS Corrections Validity Period

Parameter	# Bits	Scale Factor	Range	Units	Incl.
N_SGN_TYPE	2	1	1-3	—	M
The following fields occur once per GANSS signal type (N_SGN_TYPE times)
GANSS_Signal_ID	3	—	—	—	M
N_SAT	4	1	1-16	—	M
The following fields occur once per satellite (N_SAT times)
SV_ID	6	—	0-63	—	M
UDRE Growth Rate	3	—	0-7	—	M
Time of Validity for UDRE Growth Rate	3	—	0-7	—	M

N_SGN_TYPE

This field indicates the number of GNSS signal types included in DGANSS Corrections Validity Period IE. This field shall be set to the same value as the N_SGN_TYPE parameter in the DGANSS Corrections element in Table A.43.

GANSS_Signal_ID

DGANSS corrections validity period are provided per GNSS signal type identified by GANSS_Signal_ID. The supported signals are listed in Table A.59. This field shall be set to the same value as the GANSS_Signal_ID parameter in the DGANSS Corrections element in Table A.43.

N_SAT

This field indicates the number of satellites for which differential corrections validity period is available. This field shall be set to the same value as the N_SAT parameter in the DGANSS Corrections element in Table A.43.

SV_ID

This field identifies the satellite for which the corrections validity period is applicable. The interpretation of SV ID is defined in Table A.10.14. The UDRE Growth Rate and Time of Validity for UDRE Growth Rate IEs shall be included for the same SV_IDs as the differential corrections in Table A.43 are provided.

UDRE Growth Rate

This field provides an estimate of the growth rate of uncertainty (1-) in the corrections for the particular satellite identified by SV_ID. The estimated UDRE at time value specified in the "Time of Validity for UDRE Growth Rate" t₁ is calculated as follows:

UDRE(t₀+t₁) = UDRE(t₀)  UDRE Growth Rate

where t₀ is the DGANSS Reference Time for which the corrections in Table A.43 are valid, t₁ is the "Time of Validity for UDRE Growth Rate" field as shown in Table A.55.21, UDRE(t₀) is the User Differential Range Error field as provided in Table A.43, and "UDRE Growth Rate" field is the factor as shown in Table A.55.21.

Table A.55.21: Values of UDRE Growth Rate IE

Value	Indication
000	1,5
001	2
010	4
011	6
100	8
101	10
110	12
111	16

Time of Validity for UDRE Growth Rate

This field specifies the time when the "UDRE Growth Rate" field applies. The meaning of the values for this field is described in Table A.55.21a.

Table A.55.21a: Time of Validity for UDRE Growth Rate IE

Value	Indication [seconds]
000	20
001	40
010	80
011	160
100	320
101	640
110	1280
111	2560

GANSS Time Model Extension

This element is an extension to the GANSS Time Model IE and is shown in Table A.55.22. If GANSS Time Model is provided by the SMLC, the GANSS Time Model Extension shall also be provided.

NOTE: For reasons of backward compatibility, this IE is not defined for a Release 9 or earlier SMLC and would be ignored, when received, by a Release 9 or earlier MS. This means that when the element is expected but is not received, the SMLC is Release 9 or earlier.

Table A.55.22: GANSS Time Model Extension

Parameter	# Bits	Scale Factor	Range	Units	Incl.
GNSS_TO_ID	3	—	—	—	M
Delta T	8	1	-128 – 127	seconds	M

GNSS_TO_ID

This field is the same as defined in Table A.41 and specifies GNSS for which the GANSS Time Model Extension is provided.

Delta T

This field specifies the integer seconds of the GNSS-GNSS Time Offset provided in the GANSS Time Model in Table A.41.

GANSS Reference Measurement Extension

This element is an extension to the GANSS Reference Measurement Information IE and is shown in Table A.55.23. If GANSS Reference Measurement Information is provided by the SMLC, the GANSS Reference Measurement Extension shall also be provided.

NOTE: For reasons of backward compatibility, this IE is not defined for a Release 9 or earlier SMLC and would be ignored, when received, by a Release 9 or earlier MS. This means that when the element is expected but is not received, the SMLC is Release 9 or earlier.

Table A.55.23: GANSS Reference Measurement Extension

Parameter	# Bits	Scale Factor	Range	Units	Incl.
Num_Sat	4	1	0-15	—	M
The following fields occur once per satellite (Num_Sat times)
SV_ID	6	—	0-63	—	M
Azimuth LSB	4	0,703125	0-10,546875	degrees	M
Elevation LSB	4	0,703125	0-10,546875	degrees	M

Num_Sat

This field indicates the number of satellites for which GANSS Reference Measurement is provided. This field shall be set to the same value as the Num_Sat parameter in the GANSS Reference Measurement Information element in Table A.52.

SV_ID

This field identifies the satellite for which the GANSS Reference Measurement is provided. This field shall be set to the same value as the SV_ID field in Table A.52.

Azimuth LSB

This field specifies the 4 least significant bits of the satellite azimuth angle. The 5 most significant bits are provided in the Azimuth field in Table A.52. The full satellite azimuth is constructed as "Azimuth"  11,.25 + "Azimuth LSB"  0,703125 degrees.

Elevation LSB

This field specifies the 4 least significant bits of the satellite elevation angle. The 5 most significant bits are provided in the Elevation field in Table A.52. The full satellite elevation is constructed as "Elevation"  11,25 + "Elevation LSB"  0,703125 degrees.

GANSS Almanac Model Extension

This element is an extension to the GANSS Almanac Model IE and is shown in Table A.55.24. If GANSS Almanac Model is provided by the SMLC, the GANSS Almanac Model Extension shall also be provided.

NOTE: For reasons of backward compatibility, this IE is not defined for a Release 9 or earlier SMLC and would be ignored, when received, by a Release 9 or earlier MS. This means that when the element is expected but is not received, the SMLC is Release 9 or earlier.

Table A.55.24: GANSS Almanac Model Extension

Parameter	# Bits	Scale Factor	Range	Units	Incl.
Complete Almanac Provided	1	—	—	Boolean	M

Complete Almanac Provided

This field indicates whether the SMLC provided Almanac for the full GANSS constellation or not. TRUE means complete GANSS almanac is provided.

GANSS Almanac Model Extension-R12

This element is an extension to the GANSS Almanac Model IE and is shown in Table A.55.25. It is used only if GANSS-ID is Galileo in this version of protocol.

Table A.55.25: GANSS Almanac Model Extension-R12

Parameter	# Bits	Scale Factor	Units	Incl.
Toa-Ext	10	600	s	O (note 1)
IODa-Ext	4	—	—	O (note 2)
NOTE 1: If Toa in GANSS Almanac Model element (Table A.54) is present, this field shall not be present. NOTE 2: If IODa in GANSS Almanac Model element (Table A.54) is present, this field shall not be present.

T_oa-Ext

This field specifies the Almanac Reference Time common to all satellites in GANSS Almanac Model using Keplerian Parameters given in GNSS specific system time.

Range: 256 – 1023

In case of GNSS-ID does indicate Galileo, the scale factor is 600 seconds.

IOD_a-Ext

This field specifies the Issue-Of-Data common to all satellites in GANSS Almanac Model using Keplerian Parameters.

Range: 4 – 15

GANSS Reference Measurement Extension-R12

This element is an extension to the GANSS Reference Measurement Information IE and is shown in Table A.55.25.a. The SMLC should include this field only if supported by the MS.

Table A.55.25.a: GANSS Reference Measurement Extension-R12

Parameter	# Bits	Scale Factor	Range	Units	Incl.
GANSS_Signal_ID	3	—	0-7	—	M
Confidence	7	1	0-100	percent	O
Num_Sat	4	1	0-15	—	O
The following fields, if included, occur once per satellite (Num_Sat times)
SV_ID	6	—	0-63	—	M
Doppler Uncertainty Extension	3	—	60, 80, 100, 120, ‘No Information’	m/s	M

GANSS_Signal_ID

This field specifies the GNSS signal type. The supported signals are listed in Table A.59.

Confidence

This field specifies the confidence level of the reference location area or volume used to calculate the GANSS Reference Measurement parameters (search windows). A high percentage value (e.g., 98% or more) indicates to the MS that the provided search windows are reliable. The SMLC should include this field to indicate the confidence level of the provided information.

Range: 0 – 100

Num_Sat

This field indicates the number of satellites for which GANSS Reference Measurement Extension-R12 is provided.

SV_ID

This field identifies the satellite for which the GANSS Reference Measurement Extension-R12 is provided.

Doppler Uncertainty Extension

If this field is present, the MS that supports this field shall ignore the Doppler Uncertainty (Table A.52) field. This field specifies additional Doppler uncertainty values. It is defined such that the Doppler experienced by a stationary MS is in the range [Doppler-Doppler Uncertainty Extension] to [Doppler+Doppler Uncertainty Extension]. Doppler Uncertainty Extension is given in unit of m/s by multiplying the Doppler Uncertainty Extension value in Hz by the nominal wavelength of the assisted signal.

Enumerated values define 60 m/s, 80 m/s, 100 m/s, 120 m/s, and "No Information".

DBDS Corrections

These fields specify the DBDS corrections to be used by the MS.

Table A.55.25.b: DBDS Corrections

Parameter	# Bits	Scale Factor	Range	Units	Incl.
The following fields occur once per message
N_SGN_TYPE	2	1	1 – 3	—	M
DBDS Reference Time	12	1	0 – 3599	seconds	M
The following fields occur once per GANSS signal type (N_SGN_TYPE times)
N_SAT	6	1	1 – 64	—	M
DBDS Signal ID	3	—	—	—	M
The following fields occur once per satellite (N_SAT times)
SV_ID	6	—	0 – 63	—	M
UDREI	4	—	0 – 15	—	M
RURAI	4	—	0 – 15	—	M
Delta T	13	0.1	-409.5 – 409.5	meters	M

DBDS Reference Time

This field indicates the baseline time for which the DBDS corrections are valid as modulo 3600 s. DBDS Reference Time is given in BDS system time.

Range: 0 – 3599 s

DBDS Signal_ID

DBDS corrections are provided per BDS signal type identified by BDS Signal_ID. The supported signals are listed in Table A.59.

UDREI

UDRE is used to describe the error of equivalent clock correction in meters. It is indicated by user differential range error index (UDREI). It occupies 4 bits for each satellite within the range of 1~15 and the update rate is 3 seconds. The corresponding relationship between UDRE and UDREI is shown in A.55.26.

Table A.55.26: UDREI definitions

UDREI	UDRE （meters, 99.9％）
0	1
1	1.5
2	2
3	3
4	4
5	5
6	6
7	8
8	10
9	15
10	20
11	50
12	100
13	150
14	Not monitored
15	Not available

RURAI

Regional User Range Accuracy (RURA) is used to describe the satellite signal pseudo-range error in meters.The satellite signal integrity information is indicated with the Regional User Range Accuracy Index (RURAI). It occupies 4 bits for each satellite so the effective range of RURAI is 0 to 15. See Table A.55.27 for the corresponding relationship between RURAI and RURA.

Table A.55.27: RURAI definitions

RURAI	RURA （meters, 99.9%）
0	0.75
1	1
2	1.25
3	1.75
4	2.25
5	3
6	3.75
7	4.5
8	5.25
9	6
10	7.5
11	15
12	50
13	150
14	300
15	> 300.0

Delta_T

The BDS differential correction information is expressed in equivalent clock correction (Δt). It occupies 13 bits for each satellite with the unit and scale factor of meter and 0.1 respectively and is expressed with two’s complement. The MSB is for the sign bit (+ or –).

BDS Grid Model

The BDS Grid Model parameters are used to estimate the ionospheric distortions on pseudoranges as described in [18] on page 76.

Table A.55.28: BDS Grid Model

Parameter	# Bits	Scale Factor	Range	Units	Incl.
The following fields occur once per message
BDS Reference Time	12	1	0 – 3599	seconds	M
N_IGP	9	1	1 – 320(1)	–	M
The following fields occur once per IGP (N_IGP times(1))
IGP number	9	—	1…320	—	M
Vertical Delay	9	0.125	0 – 63.625	meters	M
GIVEI	4	—	—	—	M
NOTE 1: Up to 16 instances are used in this version of the specification. The values 17 to 320 are reserved for future use.

BDS Reference Time

This field indicates the baseline time for which the BDS Grid Model are valid as modulo 3600 s. BDS Reference Time is given in BDS system time.

Range: 0 – 3599 s

IGP number

This field indicates the ionospheric grid point (IGP) number as defined in [18].

Vertical DelayVertical delay is used to indicate the vertical ionosphere delay on B1I signal at the i^th grid point, expressed in scale factor of 0.125 and with unit of meters. The effective range of vertical delay is between 0 to 63.625 meters.

GIVEI

The grid ionosphere vertical error (GIVE) describes the delay correction accuracy at ionosphere grid points and is indicated with GIVEI. See Table A.55.29 for the relationship between GIVEI and GIVE.

Table A.55.29: GIVEI definitions

GIVEI	GIVE (meters, 99.9%)
0	0.3
1	0.6
2	0.9
3	1.2
4	1.5
5	1.8
6	2.1
7	2.4
8	2.7
9	3
10	3.6
11	4.5
12	6
13	9
14	15
15	45

A.4.2.7 GANSS Carrier-Phase Measurement Request Element

This element is optional and controls if the MS should return carrier-phase measurements in GANSS Measurement Information IE or not to the SMLC. The inclusion of this parameter implies use of measure Position Request. The description is found in sub-chapter 2.2.4d.

A.4.2.8 GANSS TOD – GSM Time Association Request Element

This element is optional and controls if the MS should return GANSS TOD – GSM Time Association Measurements or not to the SMLC. The inclusion of this parameter implies use of measure Position Request. The description is found in sub-chapter 2.2.4e.