8.1 GNSS positioning methods

38.3053GPPNG Radio Access Network (NG-RAN)Release 17Stage 2 functional specification of User Equipment (UE) positioning in NG-RANTS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

8.1.1 General

A navigation satellite system provides autonomous geo-spatial positioning with either global or regional coverage. Augmentation systems, such as SBAS, are navigation satellite systems that provide regional coverage to augment the navigation systems with global coverage.

By definition, GNSS refers to satellite constellations that achieve global coverage, however, in 3GPP specifications the term GNSS is used to encompass global, regional, and augmentation satellite systems. The following GNSSs are supported in this version of the specification:

– GPS and its modernization [5], [6], [7]; (global coverage)

– Galileo [8]; (global coverage)

– GLONASS [9]; (global coverage)

– Satellite Based Augmentation Systems (SBAS), including WAAS, EGNOS, MSAS, and GAGAN [11]; (regional coverage)

– Quasi-Zenith Satellite System (QZSS) [10]; (regional coverage)

– BeiDou Navigation Satellite System (BDS) [20] [34] [44] [45]. (global coverage)

– NAVigation with Indian Constellation (NavIC) [43]. (regional coverage)

Each global GNSS can be used individually or in combination with others, including regional navigation systems and augmentation systems. When used in combination, the effective number of navigation satellite signals would be increased:

– extra satellites can improve availability (of satellites at a particular location) and results in an improved ability to work in areas where satellite signals can be obscured, such as in urban canyons;

– extra satellites and signals can improve reliability, i.e., with extra measurements the data redundancy is increased, which helps identify any measurement outlier problems;

– extra satellites and signals can improve accuracy due to improved measurement geometry and improved ranging signals from modernized satellites.

When GNSS is designed to inter-work with the NG-RAN, the network assists the UE GNSS receiver to improve the performance in several respects. These performance improvements will:

– reduce the UE GNSS start-up and acquisition times; the search window can be limited and the measurements speed up significantly;

– increase the UE GNSS sensitivity; positioning assistance messages are obtained via NG-RAN so the UE GNSS receiver can operate also in low SNR situations when it is unable to demodulate GNSS satellite signals;

– allow the UE to consume less handset power than with stand-alone GNSS; this is due to rapid start-up times as the GNSS receiver can be in idle mode when it is not needed;

– allow the UE to compute its position with a better accuracy; RTK corrections (for N-RTK) and GNSS physical models (for SSR/PPP) are obtained via NG-RAN so the UE can use these assistance data, together with its own measurements, i.e., code and carrier phase measurements, to enable computation of a position with a high accuracy;

– allow the UE to determine and report the integrity results of the calculated location; the UE can use the integrity requirements and assistance data obtained via NG-RAN, together with its own measurements, to determine the integrity results of the calculated location.

The network-assisted GNSS methods rely on signalling between UE GNSS receivers (possibly with reduced complexity) and a continuously operating GNSS reference receiver network, which has clear sky visibility of the same GNSS constellation as the assisted UEs. Two assisted modes are supported:

– UE-Assisted: The UE performs GNSS measurements (pseudo-ranges, pseudo Doppler, carrier phase ranges, etc.) and sends these measurements to the LMF where the position calculation takes place, possibly using additional measurements from other (non GNSS) sources;

– UE-Based: The UE performs GNSS measurements and calculates its own location, possibly using additional measurements from other (non GNSS) sources and assistance data from the LMF.

The assistance data content may vary depending on whether the UE operates in UE-Assisted or UE-Based mode.

The assistance data signalled to the UE can be broadly classified into:

– data assisting the measurements: e.g. reference time, visible satellite list, satellite signal Doppler, code phase, Doppler and code phase search windows;

– data providing means for position calculation: e.g. reference time, reference position, satellite ephemeris, clock corrections, code and carrier phase measurements from a GNSS reference receiver or network of receivers;

– data increasing the position accuracy: e.g. satellite code biases, satellite orbit corrections, satellite clock corrections, atmospheric models, RTK residuals, gradients;

– data facilitating the integrity results determination of the calculated location.

A UE with GNSS measurement capability may also operate in an autonomous (standalone) mode. In autonomous mode the UE determines its position based on signals received from GNSS without assistance from the network.

8.1.1a Integrity Principle of Operation

For integrity operation, the network will ensure that:

P(Error > Bound for longer than TTA | NOT DNU) <= Residual Risk + IRallocation (Equation 8.1.1a-1)

for all values of IRallocation in the range irMinimum <= IRallocation <= irMaximum

for all the errors in Table 8.1.2.1b-1, which have corresponding integrity assistance data available and where the corresponding DNU flag(s) are set to false.

The integrity risk probability is decomposed into a constant Residual Risk component provided in the assistance data as well as a variable IRallocation component that corresponds to the contribution from the Bound according to the Bound formula in Equation 8.1.1a-2. IRallocation may be chosen freely by the client based on the desired Bound, therefore the network should ensure that Equation 8.1.1a-1 holds for all possible choices of IRallocation. The Residual Risk and IRallocation components may be mapped to fault and fault-free cases respectively, but the implementation is free to choose any other decomposition of the integrity risk probability into these two components.

The validity time of the integrity bounds is set as equal to twice the SSR Update Interval for the given SSR Assistance Data message, i.e. the time period between the SSR Epoch Time and the SSR Epoch Time plus twice the SSR Update Interval in the GPS time scale.

Equation 8.1.1a-1 holds for all assistance data that has been issued that is still within its validity period. If this condition cannot be met then the corresponding DNU flag must be set.

Equation 8.1.1a-1 holds at any epochs for which Assistance Data is provided. Providing Assistance Data without the Integrity Service Alert IE or Real Time Integrity IEs is interpreted as a DNU=FALSE condition. For any bound that is still valid (within its validity time), the network ensures that the Integrity Service Alert and/or Real Time Integrity IEs are also included in the provided Assistance Data if needed to satisfy the condition in Equation 8.1.1a-1. It is up to the implementation how to handle epochs for which integrity results are desired but there are no DNU flag(s) available, e.g. the Time To Alert (TTA) may be set such that there is a "grace period" to receive the next set of DNU flags.

Only those satellites for which the GNSS integrity assistance data are provided are monitored by the network and can be used for integrity related applications.

Where:

Error: Error is the difference between the true value of a GNSS parameter (e.g. ionosphere, troposphere etc.), and its value as estimated and provided in the corresponding assistance data as per Table 8.1.2.1b-1

Bound: Integrity Bounds provide the statistical distribution of the residual errors associated with the GNSS positioning corrections (e.g. RTK, SSR etc). Integrity bounds are used to statistically bound the residual errors after the positioning corrections have been applied. The bound is computed according to the Bound formula defined in Equation 8.1.1a-2. The bound formula describes a bounding model including a mean and standard deviation (e.g. paired over-bounding Gaussian). The bound may be scaled by multiplying the standard deviation by a K factor corresponding to an IRallocation, for any desired IRallocation within the permitted range.

Bound for a particular error is computed according to the following formula:

Bound = mean + K * stdDev (Equation 8.1.1a-2)

K = normInv(IR_allocation / 2)

irMinimum <= IR_allocation <= irMaximum

where: mean: mean value for this specific error, as per Table 8.1.2.1b-1

stdDev: standard deviation for this specific error, as per Table 8.1.2.1b-1

Time-to-Alert (TTA): The maximum allowable elapsed time from when the Error exceeds the Bound until a DNU flag must be issued.

DNU: The DNU flag(s) corresponding to a particular error as per Table 8.1.2.1b-1. Where multiple DNU flags are specified, the DNU condition in Equation 8.1.1a-1 is present when any of the flags are true (logical OR of the flags).

Residual Risk: The residual risk is the component of the integrity risk provided in the assistance data as per Table 8.1.2.1b-1. This may correspond to the fault case risk but the implementation is permitted to allocate this component in any way that satisfies Equation 8.1.1a-1.

The Residual Risk is the Probability of Onset which is defined per unit of time and represents the probability that the feared event begins. Each Residual Risk is accompanied by a Mean Duration which represents the expected mean duration of the corresponding feared event and is used to convert the Probability of Onset to a probability that the feared event is present at any given time, i.e.

P(Feared Event is Present) = Mean Duration * Probability of Onset of Feared Event (Equation 8.1.1a-3)

irMinimum, irMaximum: Minimum and maximum allowable values of IRallocation that may be chosen by the client. Provided as service parameters from the Network according to Integrity Service Parameters.

Correlation Times: The minimum time interval beyond which two sets of GNSS assistance data parameters for a given error can be considered to be independent from one another.

8.1.2 Information to be transferred between NG-RAN/5GC Elements

This clause defines the information that may be transferred between LMF and UE.

8.1.2.1 Information that may be transferred from the LMF to UE

Table 8.1.2.1-1 lists assistance data for both UE-assisted and UE-based modes that may be sent from the LMF to the UE.

NOTE: The provision of these assistance data elements and the usage of these elements by the UE depend on the NG-RAN/5GC and UE capabilities, respectively.

Table 8.1.2.1-1: Information that may be transferred from the LMF to UE

Assistance Data

Reference Time

Reference Location

Ionospheric Models

Earth Orientation Parameters

GNSS-GNSS Time Offsets

Differential GNSS Corrections

Ephemeris and Clock Models

Real-Time Integrity

Data Bit Assistance

Acquisition Assistance

Almanac

UTC Models

RTK Reference Station Information

RTK Auxiliary Station Data

RTK Observations

RTK Common Observation Information

GLONASS RTK Bias Information

RTK MAC Correction Differences

RTK Residuals

RTK FKP Gradients

SSR Orbit Corrections

SSR Clock Corrections

SSR Code Bias

SSR Phase Bias

SSR STEC Corrections

SSR Gridded Correction

SSR URA

SSR Correction Points

Integrity Service Parameters

Integrity Alerts

8.1.2.1.1 Reference Time

Reference Time assistance provides the GNSS receiver with coarse or fine GNSS time information. The specific GNSS system times (e.g., GPS, Galileo, GLONASS, BDS, NavIC system time) shall be indicated with a GNSS ID.

In case of coarse time assistance only, the Reference Time provides an estimate of the current GNSS system time (where the specific GNSS is indicated by a GNSS ID). The LMF should achieve an accuracy of ±3 seconds for this time including allowing for the transmission delay between LMF and UE.

In case of fine time assistance, the Reference Time provides the relation between GNSS system time (where the specific GNSS is indicated by a GNSS ID) and NG-RAN air-interface timing.

8.1.2.1.2 Reference Location

Reference Location assistance provides the GNSS receiver with an a priori estimate of its location (e.g., obtained via Cell-ID, OTDOA positioning, etc.) together with its uncertainty.

The geodetic reference frame shall be WGS-84, as specified in TS 23.032 [4].

8.1.2.1.3 Ionospheric Models

Ionospheric Model assistance provides the GNSS receiver with parameters to model the propagation delay of the GNSS signals through the ionosphere. Ionospheric Model parameters as specified by GPS [5], Galileo [8], QZSS [10], BDS [20] [34] [44] [45], and NavIC [43] may be provided.

8.1.2.1.4 Earth Orientation Parameters

Earth Orientation Parameters (EOP) assistance provides the GNSS receiver with parameters needed to construct the ECEF-to-ECI coordinate transformation as specified by GPS [5].

8.1.2.1.5 GNSS-GNSS Time Offsets

GNSS-GNSS Time Offsets assistance provides the GNSS receiver with parameters to correlate GNSS time (where the specific GNSS is indicated by a GNSS-1 ID) of one GNSS with other GNSS time (where the specific GNSS is indicated by a GNSS-2 ID). GNSS-GNSS Time Offsets parameters as specified by GPS [5], Galileo [8], GLONASS [9], QZSS [10], BDS [20] [34] [44] [45], and NavIC [43] may be provided.

8.1.2.1.6 Differential GNSS Corrections

Differential GNSS Corrections assistance provides the GNSS receiver with pseudo-range and pseudo-range-rate corrections to reduce biases in GNSS receiver measurements as specified in [12]. The specific GNSS for which the corrections are valid is indicated by a GNSS-ID.

8.1.2.1.7 Ephemeris and Clock Models

Ephemeris and Clock Models assistance provides the GNSS receiver with parameters to calculate the GNSS satellite position and clock offsets. The various GNSSs use different model parameters and formats, and all parameter formats as defined by the individual GNSSs are supported by the signalling.

8.1.2.1.8 Real-Time Integrity

Real-Time Integrity assistance provides the GNSS receiver with information about the health status of a GNSS constellation (where the specific GNSS is indicated by a GNSS ID).

For integrity purposes (as per Clause 8.1.1a), a GNSS satellite and signal combination should be considered as being marked "Do Not Use" (DNU) if the satellite ID and signal are present in the list of unhealthy (bad) signals.

NOTE: The absence of the Real Time Integrity assistance from any Provide Assistance Data message is interpreted as DNU=FALSE for all satellites and signals that are monitored for integrity.

8.1.2.1.9 Data Bit Assistance

Data Bit Assistance provides the GNSS receiver with information about data bits or symbols transmitted by a GNSS satellite at a certain time (where the specific GNSS is indicated by a GNSS ID). This information may be used by the UE for sensitivity assistance (data wipe-off) and time recovery.

8.1.2.1.10 Acquisition Assistance

Acquisition Assistance provides the GNSS receiver with information about visible satellites, reference time, expected code-phase, expected Doppler, search windows (i.e., code and Doppler uncertainty) and other information of the GNSS signals (where the specific GNSS is indicated by a GNSS ID) to enable a fast acquisition of the GNSS signals.

8.1.2.1.11 Almanac

Almanac assistance provides the GNSS receiver with parameters to calculate the coarse (long-term) GNSS satellite position and clock offsets. The various GNSSs use different model parameters and formats, and all parameter formats as defined by the individual GNSSs are supported by the signalling.

8.1.2.1.12 UTC Models

UTC Models assistance provides the GNSS receiver with parameters needed to relate GNSS system time (where the specific GNSS is indicated by a GNSS ID) to Universal Coordinated Time. The various GNSSs use different model parameters and formats, and all parameter formats as defined by the individual GNSSs are supported by the signalling.

8.1.2.1.13 RTK Reference Station Information

RTK Reference Station Information provides the GNSS receiver with the Earth-Centered, Earth-Fixed (ECEF) coordinates of the Reference Station’s installed antenna’s ARP, and the height of the ARP above the survey monument. Additionally, this assistance data provides information about the antenna type installed at the reference site.

NOTE: With the MAC N-RTK technique this assistance data is used to provide information regarding the Master Reference Station (see clause 8.1.2.1a).

8.1.2.1.14 RTK Auxiliary Station Data

RTK Auxiliary Station Data provides the GNSS receiver with the location for all Auxiliary Reference Stations (see clause 8.1.2.1a) within the assistance data. These values are expressed as relative geodetic coordinates (latitude, longitude, and height) with respect to a Master Reference Station (see clause 8.1.2.1a) and based on the GRS80 ellipsoid. This type of assistance data is relevant only with the MAC N-RTK technique [31].

8.1.2.1.15 RTK Observations

RTK Observations provides the GNSS receiver with all primary observables (pseudo-range, phase-range, phase-range rate (Doppler), and carrier-to-noise ratio) generated at the Reference Station for each GNSS signal. The signal generation from the reference station is in compliance with [31]: as an example, the phase measurements of different signals in the same band must be phased aligned. More examples can be found in [31].

The pseudo-range is the distance between the satellite and GNSS receiver antennas, expressed in metres, equivalent to the difference of the time of reception (expressed in the time frame of the GNSS receiver) and the time of transmission (expressed in the time frame of the satellite) of a distinct satellite signal.

The phase-range measurement is a measurement of the range between a satellite and receiver expressed in units of cycles of the carrier frequency. This measurement is more precise than the pseudo-range (of the order of millimetres), but it is ambiguous by an unknown integer number of wavelengths.

The phase-range rate is the rate at which the phase-range between a satellite and a GNSS receiver changes over a particular period of time.

The carrier-to-noise ratio is the ratio of the received modulated carrier signal power to the noise power after the GNSS receiver filters.

NOTE: With the MAC N-RTK technique this assistance data is used to provide raw observables recorded at the Master Reference Station (see clause 8.1.2.1a).

8.1.2.1.16 RTK Common Observation Information

RTK Common Observation Information provides the GNSS receiver with common information applicable to any GNSS, e.g. clock steering indicator. This assistance data is always used together GNSS RTK Observations (see clause 8.1.2.1.15).

8.1.2.1.17 GLONASS RTK Bias Information

RTK Bias Information provides the GNSS receiver with information which is intended to compensate for the first-order inter-frequency phase-range biases introduced by the reference receiver code-phase biases. This information is applicable only for GLONASS FDMA signals. In the case that the MAC Network RTK method is used, GLONASS RTK Bias Information defines the code-phase biases related to the Master Reference Station [31].

8.1.2.1.18 RTK MAC Correction Differences

RTK MAC Correction Differences provides the GNSS receiver with information about ionospheric (dispersive) and geometric (non-dispersive) corrections generated between a Master Reference Station and its Auxiliary Reference Stations [31].

8.1.2.1.19 RTK Residuals

RTK Residuals provides the GNSS receiver with network error models generated for the interpolated corrections disseminated in Network RTK techniques. With sufficient redundancy in the RTK network, the location server process can provide an estimate for residual interpolation errors. Such quality estimates may be used by the target UE to optimize the performance of RTK solutions. The values may be considered by the target UE as a priori estimates only, with sufficient tracking data available the target UE might be able to judge residual geometric and ionospheric errors itself. According to [31], RTK Residual error information should be transmitted every 10-60 seconds.

8.1.2.1.20 RTK FKP Gradients

RTK FKP Gradients provides the GNSS receiver with horizontal gradients for the geometric (troposphere and satellite orbits) and ionospheric signal components in the observation space. According to [31], RTK FKP gradient information should be typically transmitted every 10-60 seconds.

8.1.2.1.21 SSR Orbit Corrections

SSR Orbit Corrections provides the GNSS receiver with parameters for orbit corrections in radial, along-track and cross-track components. These orbit corrections are used to compute a satellite position correction, to be combined with satellite position calculated from broadcast ephemeris (see clause 8.1.2.1.7).

For integrity purposes, SSR Orbit Corrections also provides the correlation time for orbit error and orbit error rate, and the mean and standard deviation that bounds the residual Orbit Error and its associated error rate. The SSR Orbit Corrections also includes the satellite and constellation residual risks. These residual risks are the aggregate residual risk for the satellite or constellation Signal in Space including Orbit, Clock, Bias and all other satellite or constellation feared events, but excluding atmospheric effects.

When applying the integrity bounds as per 8.1.1a, the mean and stdDev must be calculated by projecting the Orbit error mean and variance along the line-of-sight vector between the satellite and the user, according to the following formula:

stdDev_orbit = (Equation 8.1.2.1.21-1)

mean_orbit =

where: I: 3-D line of sight vector from the user to the satellite in the WGS-84 ECEF coordinate frame.

R: the rotation matrix from satellite along-track (AT), cross-track (CT) and radial (RA) coordinates into the WGS-84 ECEF coordinate frame. R^T denotes the transposed matrix.

v: the 3-D Orbit error variance vector expressed in satellite along-track, cross-track and radial coordinates.

μ: the Mean Orbit Error vector expressed in satellite along-track, cross-track and radial coordinates.

The vector v is expressed in the SSR Orbit Corrections as the three elements in the Variance Orbit Residual Error Vector.

8.1.2.1.22 SSR Clock Corrections

SSR Clock Corrections provides the GNSS receiver with parameters to compute the GNSS satellite clock correction applied to the broadcast satellite clock (see clause 8.1.2.1.7). A polynomial of order 2 describes the clock differences for a certain time period: clock offset, drift, and drift rate.

For integrity purposes, SSR Clock Corrections also provides the correlation time for clock error and clock error rate, and the mean and standard deviation that bounds the residual Clock Error and its associated error rate.

8.1.2.1.23 SSR Code Bias

SSR Code Bias provides the GNSS receiver with the Code Biases that must be added to the pseudo range measurements of the corresponding code signal to get corrected pseudo ranges. SSR Code Bias contains absolute values, but also enables the alternative use of Differential Code Biases by setting one of the biases to zero. A UE can consistently use signals for which a code bias is transmitted. It is not reliable for a UE to use a signal without retrieving a corresponding code bias from the assistance data message.

For integrity purposes, SSR Code Bias also provides the mean and standard deviation that bounds the residual Code Bias Error and its associated error rate.

8.1.2.1.24 SSR Phase Bias

SSR Phase Bias provides the GNSS receiver with the GNSS signal phase bias that are added to the carrier phase measurements of the corresponding signal to get corrected phase ranges. An indicator used to count events when phase bias is discontinuous is provided. An optional indicator is also provided to indicate whether fixed, widelane fixed or float PPP-RTK positioning modes are supported on a per signal basis.

NOTE 1: On the UE side, phase bias corrections of appropriate type are needed to restore the integer nature of the phase ambiguities in PPP-RTK. Their absence will affect the quality of the positioning solution and prevent a fast convergence time.

NOTE 2: PPP-RTK Fixed position mode corresponds to the UE fixing the carrier phase ambiguity to an integer value. The PPP-RTK Widelane Fixed positioning mode corresponds to forming the widelane combination of carrier phase measurements and fixing the resulting ambiguity as an integer value. In PPP-RTK Float positioning mode the carrier phase ambiguity is not treated as an integer value.

For integrity purposes, SSR Phase Bias also provides the mean and standard deviation that bounds the residual Phase Bias Error and its associated error rate.

8.1.2.1.25 SSR STEC Corrections

SSR STEC Corrections provides the GNSS receiver with the parameters to compute the ionosphere slant delay correction based on a variable order polynomial on a per satellite basis and applied to the code and phase measurements.

For integrity purposes, SSR STEC Corrections also provides the ionosphere residual risk parameters, correlation time for ionosposphere range error and range error rate, and the mean and standard deviation that bounds the residual Ionospheric Error and its associated error rate.

8.1.2.1.26 SSR Gridded Correction

SSR Gridded Corrections provides the GNSS receiver with STEC residuals and Troposphere delays at a series of correction points and expressed as hydrostatic and wet vertical delays.

NOTE: The final ionosphere slant delay (STEC) consists of the polynomial part provided in SSR STEC Correction and the residual part provided in SSR Gridded Corrections.

For integrity purposes, SSR Gridded Corrections also provides the troposphere residual risk parameters, correlation time for troposphere range error and range error rate, and the mean and standard deviation that bounds the residual Tropospheric Error and associated its error rate in the Vertical Hydro Static Delay and Vertical Wet Delay components.

8.1.2.1.27 SSR URA

SSR URA provides the receiver with information about the estimated accuracy of the corrections for each satellite.

8.1.2.1.28 SSR Correction Points

The SSR Correction Points provides a list of correction point coordinates or an array of correction points ("grid") for which the SSR Gridded Corrections are valid.

8.1.2.1.29 Integrity Service Parameters

Integrity Service Parameters provide the range of Integrity Risk (IR) for which the associated GNSS integrity assistance data is considered to be valid.

8.1.2.1.30 Integrity Alerts

Integrity Service Alerts provide information on whether the service can be used for integrity. A Do Not Use (DNU) flag indicates that the corresponding assistance data is not suitable for the purpose of computing integrity. If an Integrity Service Alert is issued and the DNU flag is false, then the corresponding assistance data may be used for the purpose of computing integrity. The DNU flags are defined to be applicable to the specified epoch time only.

8.1.2.1a Recommendations for grouping of assistance data to support different RTK service levels

This clause provides recommendations for the different high-accuracy GNSS service levels: RTK, N-RTK, PPP and PPP-RTK.

The high-accuracy GNSS methods can be classified as:

– Single base RTK service: RTK is a technique that uses carrier-based ranging measurements i.e., phase-range to improve the positioning accuracy in a differential approach. The basic concept is to reduce and remove errors common to a Reference Station, with known position, and UE pair. When only pseudo ranges (code-based measurements) are used to compute the UE location, this method is known as DGNSS (Differential GNSS).

Table 8.1.2.1a-1: Single base RTK service: Specific information that may be transferred from the LMF to the UE

Assistance Data

RTK Reference Station Information

RTK Observations

RTK Common Observation Information

GLONASS RTK Bias Information (if GLONASS data is transmitted)

Ephemeris and Clock (if UE did not acquire the navigation message)

– Non-Physical Reference Station Network RTK service: In this approach the target UE receives synthetic observations from a fictitious Reference Station. The Network RTK software at the location server is performing the error estimation and creates a virtual Reference Station close to the initial location of the target device (provided a priori to the location server). The target UE interprets and uses the data just as if it had come from a single, real Reference Station. Additionally, the target UE can also receive network information such as RTK Network Residuals (see clause 8.1.2.1.19) or even FKP gradients (see clause 8.1.2.1.20).

Table 8.1.2.1a-2: Non-Physical Reference Station Network RTK service: Specific information that may be transferred from the LMF to the UE

Assistance Data

RTK Reference Station Information

RTK Observations

RTK Common Observation Information

GLONASS RTK Bias Information (if GLONASS data is transmitted)

RTK Residuals

RTK FKP Gradients

Ephemeris and Clock (if UE did not acquire the navigation message)

– MAC Network RTK service: In MAC network RTK, a group of Reference Stations are used and one of them is chosen as a Master station. The other stations are then called Auxiliary stations. In this service, the location server sends full raw observations and coordinate information for a single Reference Station, the Master Station. For all auxiliary stations in the network (or a suitable subset of stations) the information is provided to the UE in a highly compact form: their reduced ambiguity-levelled observations, coordinate differences (to the Master Station observations and coordinates), and network residuals. Two Reference Stations are said to be on a common ambiguity level if the integer ambiguities for each phase range (satellite-receiver pair) have been removed (or adjusted) so that the integer ambiguities cancel when double-differences (involving two receivers and two satellites) are formed during processing. The maintenance of a common ambiguity level at a specific set of stations rather than across the whole GNSS network will lead to a grouping in network clusters or subnetworks of all ambiguity-levelled Reference Stations. If one network has only one subnetwork, this indicates that an ambiguity level throughout the whole network is established. When subnetworks are predefined, the assistance data can be broadcast to all UEs located in the assigned sub-network. More details on the usage of subnetworks can be found in [31].

Table 8.1.2.1a-3: MAC Network RTK service: Specific Information that may be transferred from the LMF to the UE

Assistance Data

RTK Reference Station Information

RTK Auxiliary Station Data

RTK Observations

RTK Common Observation Information

GLONASS RTK Bias Information (if GLONASS data is transmitted)

RTK MAC Correction Differences

RTK Residuals

Ephemeris and Clock (if UE did not acquire the navigation message)

– FKP Network RTK service: With the concept of FKP, horizontal gradients of distance-dependent errors like ionosphere, troposphere and orbits are derived from a network of GNSS Reference Stations and transmitted to a target device together with raw or correction data of a corresponding Reference Station (physical or non physical). The target UE may use the gradients to compute the effect of the distance-dependent errors for its own position.

Table 8.1.2.1a-4: FKP Network RTK service: Information that may be transferred from the LMF to the UE

Assistance Data

RTK Reference Station Information

RTK Observations

RTK Common Observation Information

GLONASS RTK Bias Information (if GLONASS data is transmitted)

RTK Residuals

RTK FKP Gradients

Ephemeris and Clock (if UE did not acquire the navigation message)

– PPP service: This concept uses precise satellite orbit and clock parameters derived from global networks of Reference Stations as well as atmospheric models to perform single station positioning [31]. Compared to RTK and Network RTK, PPP is not a differential technique as there is no baseline limitation. When the orbits and clocks assistance data elements are provided in real-time, with no latency, the method is called Real-Time PPP.

Table 8.1.2.1a-5: SSR PPP service: Information that may be transferred from the LMF to the UE

Assistance Data

SSR Orbit Corrections

SSR Clock corrections

SSR Code Bias

Ephemeris and Clock (if UE did not acquire the navigation message)

– PPP-RTK service: This concept uses precise satellite orbits and clock parameters, the satellite signal biases derived from global networks of Reference Stations as well as ionosphere and troposphere corrections to perform single station positioning IS-QZSS-L6-001 [36]. Therefore, PPP-RTK services compensate the global and local corrections for a more accurate location information. Compared to PPP, PPP-RTK requires the UE to be located within the region covered by the ionosphere and troposphere corrections.

Table 8.1.2.1a-6: SSR PPP-RTK service: Information that may be transferred from the LMF to the UE

Assistance Data

SSR Orbit Corrections

SSR Clock corrections

SSR Code Bias

Ephemeris and Clock (if UE did not acquire the navigation message)

SSR Phase Bias

SSR STEC Corrections

SSR Gridded Correction

SSR URA

SSR Correction Points

8.1.2.1b Mapping of integrity parameters

Table 8.1.2.1b-1 shows the mapping between the integrity fields and the SSR assistance data according to the Integrity Principle of Operation (Clause 8.1.1a). The corresponding field descriptions for each of the field names listed in Table 8.1.2.1b-1 are specified under Clause 6.5.2.2 of TS 37.355 [42].

Table 8.1.2.1b-1: Mapping of Integrity Parameters

Error	GNSS Assistance Data	Integrity Fields
Error	GNSS Assistance Data	Integrity Alerts	Integrity Bounds (Mean)	Integrity Bounds (StdDev)	Residual Risks	Integrity Correlation Times
Orbit	SSR Orbit Corrections	Real-Time Integrity (see Clause 8.1.2.1.8)	Mean Orbit Error Mean Orbit Rate Error (Calculated according to Equation 8.1.2.1.21-1)	Standard Deviation Orbit Error Standard Deviation Orbit Rate Error (Calculated according to Equation 8.1.2.1.21-1)	Probability of Onset of Constellation Fault Probability of Onset of Satellite Fault Mean Constellation Fault Duration Mean Satellite Fault Duration	Orbit Range Error Correlation Time Orbit Range Rate Error Correlation Time
Clock	SSR Clock Corrections		Mean Clock Error Mean Clock Rate Error	Standard Deviation Clock Error Standard Deviation Clock Rate Error		Clock Range Error Correlation Time Clock Range Rate Error Correlation Time
Code Bias	SSR Code Bias		Mean Code Bias Error Mean Code Bias Rate Error	Standard Deviation Code Bias Error Standard Deviation Code Bias Rate Error
Phase Bias	SSR Phase Bias		Mean Phase Bias Error Mean Phase Bias Rate Error	Standard Deviation Phase Bias Error Standard Deviation Phase Bias Rate Error
Ionosphere	SSR STEC Correction	Ionosphere DNU	Mean Ionospherre Error Mean Ionospherre Rate Error	Standard Deviation Ionosphere Error Standard Deviation Ionosphere Rate Error	Probability of Onset of Ionosphere Fault Mean Ionosphere Fault Duration	Ionosphere Range Error Correlation Time Ionosphere Range Rate Error Correlation Time
Troposphere Vertical Hydro Static Delay	SSR Gridded Corrections	Troposphere DNU	Mean Troposphere Vertical Hydro Static Delay Error Mean Troposphere Vertical Hydro Static Delay Rate Error	Standard Deviation Troposphere Vertical Hydro Static Delay Error Standard Deviation Troposphere Vertical Hydro Static Delay Rate Error	Probability of Onset of Troposphere Fault Mean Troposphere Fault Duration	Troposphere Range Error Correlation Time Troposphere Range Rate Error Correlation Time
TroposphereVertical WetDelay	SSR Gridded Corrections	Troposphere DNU	Mean Troposphere Vertical Wet Delay Error Mean Troposphere Vertical Wet Delay Rate Error	Standard Deviation Troposphere Vertical Wet Delay Error Standard Deviation Troposphere Vertical Wet Delay Rate Error

8.1.2.2 Information that may be transferred from the UE to LMF

The information that may be signalled from UE to the LMF is listed in table 8.1.2.2-1.

Table 8.1.2.2-1: Information that may be transferred from UE to the LMF

Information	UE‑assisted	UE‑based/standalone
Latitude/Longitude/Altitude, together with uncertainty shape	No	Yes
Velocity, together with uncertainty shape	No	Yes
Reference Time, possibly together with GNSS to NG-RAN time association and uncertainty	Yes	Yes
Indication of used positioning methods in the fix	No	Yes
Code phase measurements, also called pseudorange	Yes	No
Doppler measurements	Yes	No
Carrier phase measurements, also called Accumulated Delta Range (ADR)	Yes	No
Carrier-to-noise ratio of the received signal	Yes	No
Measurement quality parameters for each measurement	Yes	No
Additional, non-GNSS related measurement information	Yes	No

8.1.2.2.1 GNSS Measurement Information

The GNSS measurement information reported from the UE to the LMF depends on the GNSS mode (i.e., UE-based, autonomous (standalone), or UE-assisted).

8.1.2.2.1.1 UE-based mode

In UE-based or standalone mode, the GNSS receiver reports the latitude, longitude and possibly altitude, together with an estimate of the location uncertainty, if available.

If requested by the LMF and supported by the UE, the GNSS receiver may report its velocity, possibly together with an estimate of the uncertainty, if available.

If requested by the LMF and supported by the UE, the GNSS receiver may report the relation between GNSS system time (where the specific GNSS is indicated by a GNSS ID; the specific GNSS system time may be selected by the UE) and NG-RAN air-interface timing. This information may be used by the LMF to assist other UEs in the network.

The UE should also report an indication of which GNSSs and possibly other location methods have been used to calculate a fix.

8.1.2.2.1.2 UE-assisted mode

In UE-assisted mode, the GNSS receiver reports the Code Phase and Doppler measurements together with associated quality estimates. These measurements enable the LMF to calculate the location of the UE, possibly using other measurements and data.

If requested by the LMF and supported by the UE, the GNSS receiver may report Carrier Phase measurements (also called Accumulated Delta Range), together with associated quality measurements, if available.

8.1.2.2.2 Additional Non-GNSS Related Information

Additional non-GNSS measurements performed by NG-RAN or UE may be used by the LMF or UE to calculate or verify a location estimate. This information may include OTDOA positioning measurements, pathloss and signal strength related measurements, etc.

8.1.3 Assisted-GNSS Positioning Procedures

8.1.3.1 Capability Transfer Procedure

The Capability Transfer procedure for Assisted-GNSS positioning is described in clause 7.1.2.1.

8.1.3.2 Assistance Data Transfer Procedure

The purpose of this procedure is to enable the LMF to provide assistance data to the UE (e.g., as part of a positioning procedure) and the UE to request assistance data from the LMF (e.g., as part of a positioning procedure). In the case of high-accuracy GNSS positioning techniques (e.g., RTK), the LMF can provide unsolicited periodic assistance data to the UE and the UE can request periodic assistance data from the LMF.

8.1.3.2.1 LMF initiated Assistance Data Delivery

Figure 8.1.3.2.1-1 shows the Assistance Data Delivery operations for the network-assisted GNSS method when the procedure is initiated by the LMF.

Figure 8.1.3.2.1-1: LMF-initiated Assistance Data Delivery Procedure

(1) The LMF determines that assistance data needs to be provided to the UE (e.g., as part of a positioning procedure) and sends an LPP Provide Assistance Data message to the UE. This message may include any of the GNSS assistance data defined in clause 8.1.2.1.

8.1.3.2.1a LMF initiated Periodic Assistance Data Delivery

The Periodic Assistance Data Delivery procedure allows the server to provide unsolicited periodic assistance data to the target and is shown in Figure 8.1.3.2.1a-1.

NOTE: In this version of the specification, periodic assistance data delivery is supported for HA GNSS (e.g., RTK) positioning only.

Figure 8.1.3.2.1a-1: LPP Periodic Assistance data delivery procedure

(1) The LMF determines that assistance data needs to be provided to the UE and sends an LPP Provide Assistance Data message to the UE. This message includes information to identify the type of periodic assistance data and a duration for ending the assistance data delivery. The message indicates the end of the control transaction.

(2) When the first periodic message is available, the LMF sends an unsolicited LPP Provide Assistance Data message to the UE containing the periodic assistance data announced in step (1).

(3) The LMF may continue to send further LPP Provide Assistance Data messages to the target containing the periodic assistance data announced in step (1) when each additional periodicity condition occurs. When the duration for ending the periodic assistance data transfer occurs, the last LPP Provide Assistance Data message transferred indicates the end of transaction. Additionally, the session can be ended on request by the UE or by the LMF with the help of an Abort message.

8.1.3.2.2 UE initiated Assistance Data Transfer

Figure 8.1.3.2.2-1 shows the Assistance Data Transfer operations for the network-assisted GNSS method when the procedure is initiated by the UE.

Figure 8.1.3.2.2-1: UE-initiated Assistance Data Transfer Procedure

(1) The UE determines that certain A-GNSS assistance data are desired (e.g., as part of a positioning procedure when the LMF provided assistance data are not sufficient for the UE to fulfil the request) and sends a LPP Request Assistance Data message to the LMF. This request includes an indication of which specific A-GNSS assistance data are requested for each GNSS, possibly together with additional information (e.g., for which GNSS signal types, or satellites, or times the assistance is requested, etc.). Additional information concerning the UE’s approximate location and serving and neighbour cells may also be provided in the Request Assistance Data message and/or in an accompanying Provide Location Information message to help the LMF provide appropriate assistance data. This additional data may include the UE’s last known location if available, the cell IDs of the UE serving NG-RAN node and possibly neighbour NG-RAN nodes, as well as E-UTRA E-CID measurements.

(2) The LMF provides the requested assistance data in a LPP Provide Assistance Data message, if available at the LMF. The entire set of assistance data may be delivered in one or several LPP messages, e.g., one message per GNSS. In this case, this step may be repeated by the LMF several times. If any of the UE requested assistance data in step (1) are not provided in step 2, the UE shall assume that the requested assistance data are not supported, or currently not available at the LMF. If none of the UE requested assistance data in step (1) can be provided by the LMF, return any information that can be provided in an LPP message of type Provide Assistance Data which includes a cause indication for the not provided assistance data.

8.1.3.2.2a UE initiated Periodic Assistance Data Transfer

Figure 8.1.3.2.2a-1 shows the Periodic Assistance Data Transfer operations for the high-accuracy GNSS methods (e.g., RTK) when the procedure is initiated by the UE.

NOTE: In this version of the specification, periodic assistance data transfer is supported for HA GNSS (e.g., RTK) positioning only.

Figure 8.1.3.2.2a-1: UE-initiated Periodic Assistance Data Transfer Procedure

(1) The UE determines that periodic assistance data are desired and sends a LPP Request Assistance Data message to the LMF. This request includes an indication of which specific assistance data are requested together with additional information such as desired periodicity for sending the assistance data and a duration for ending the periodic assistance data delivery session.

(2) The LMF responds with a LPP Provide Assistance Data message to the UE. If the UE request can be supported, the message contains information which may confirm or redefine the type of assistance data or periodicity parameters requested at step (1). This response indicates the end of the control transaction.

(3) When available, the LMF provides the requested assistance data in a LPP Provide Assistance Data message to the UE. If any of the requested assistance data in step (1) or redefined in step (2) are not provided the UE assumes that the requested assistance data are not supported, or currently not available at the LMF.

(4) The LMF may transmit one or more additional LPP Provide Assistance Data messages to the UE containing further periodic assistance data confirmed or redefined in step (2). When the duration for ending the periodic assistance data transfer occur, the last LPP Provide Assistance Data message transferred indicates the end of the transaction. Additionally, the periodic assistance data delivery session can be ended on request by the UE or by the LMF with the help of an Abort message.

8.1.3.3 Location Information Transfer Procedure

The purpose of this procedure is to enable the LMF to request position measurements or location estimate from the UE, or to enable the UE to provide location measurements to the LMF for position calculation.

8.1.3.3.1 LMF initiated Location Information Transfer Procedure

Figure 8.1.3.3.1-1 shows the Location Information Transfer operations for the network-assisted GNSS method when the procedure is initiated by the LMF.

Figure 8.1.3.3.1-1: LMF-initiated Location Information Transfer Procedure

(1) The LMF sends a LPP Request Location Information message to the UE for invocation of A-GNSS positioning. This request includes positioning instructions such as the GNSS mode (UE-assisted, UE-based, UE-based preferred but UE-assisted allowed, UE-assisted preferred, but UE-based allowed, standalone), positioning methods (GPS, Galileo, GLONASS, BDS, NavIC, etc. and possibly non-GNSS methods, such as OTDOA positioning or E-CID positioning), specific UE measurements requested if any, such as fine time assistance measurements, velocity, carrier phase, multi-frequency measurements, quality of service parameters (accuracy, response time), and possibly integrity requirements.

(2) The UE performs the requested measurements and possibly calculates its own location. The UE may also determine the integrity results of the calculated location. The UE sends an LPP Provide Location Information message to the LMF before the Response Time provided in step (1) elapsed. If the UE is unable to perform the requested measurements, or if the Response Time provided in step 1 elapsed before any of the requested measurements have been obtained, the UE returns any information that can be provided in an LPP message of type Provide Location Information which includes a cause indication for the not provided location information.

8.1.3.3.2 UE-initiated Location Information Delivery Procedure

Figure 8.1.3.3.2-1 shows the Location Information delivery operations for the UE-assisted GNSS method when the procedure is initiated by the UE.

Figure 8.1.3.3.2-1: UE-initiated Location Information Delivery Procedure

(1) The UE sends an LPP Provide Location Information message to the LMF. The Provide Location Information message may include any UE measurements (GNSS pseudo-ranges, carrier phase-ranges, and other measurements) already available at the UE.