Ionospheric corrections are delivered as combinations of three different LPP message types:

  • GNSS-SSR-CorrectionPoints, which defines the grid layout for a single grid
  • GNSS-SSR-STEC-Correction, which provides polynomials of STEC delays for each satellite
  • GNSS-SSR-GriddedCorrection, which provides residuals of the polynomial with respect to the actual STEC values at grid points inside a grid.

See Chapter LPP ASN.1 Schema for LPP schema and specification and a more detailed description of contents of each message type.

You can download the LPP v16.6.0 specification from this link: LPP v16.6.0.

You can download QZSS ICD from this link: QZSS ICD.

Details of the ionospheric correction elements in LPP ASN.1 schema

To avoid confusion and misunderstandings, some details and clarifications of each ionospheric correction LPP message are provided below.


The GNSS-SSR-CorrectionPoints-element is used to provide grid definitions. Grids are defined as a set of grid points, which cover an area, where corresponding correction data can be used. Grids are defined in GNSS-SSR-ArrayOfCorrectionPoints-r16-format: nxm-point rectangles, where either some or all the points can be used. Each grid is marked with a unique grid ID, which can be used to associate the correction data with a grid.

Description of field bitmaskOfGrids-r16 leaves some room for interpretation. The specification contains the following statement:

"This field specifies the availability of correction data at the correction points in the array. If a specific bit is enabled (set to '1'), the correction is available. Only the first numberOfStepsLatitude x numberOfStepsLongitude bits are used, the remainder are set to '0'..."

The above would suggest that, for example, parameter numberOfStepsLatitude indicates the number of points in the latitude direction (similarly for longitude), as the product of the two, then gives the total number of points, and each bit then corresponds to one point.

On the other hand, these two parameters can have values 0..63, which would indicate that these indeed are steps rather than points in each direction, as there is no sense in having a grid with zero points in either direction. Additionally, this interpretation does not allow 64 points in one direction.

The interpretation in HERE GNSS Service is that, instead, the first (numberOfStepsLatitude+1) x (numberOfStepsLongitude+1) bits are used. The number of points in one direction is always one larger than the number of steps, and this version of the product gives the correct total number of points. This does not affect the number of bits used or the possible valid values, only the interpretation of the bits.


The GNSS-SSR-STEC-Correction-element is used by HERE GNSS Service to provide a polynomial model of STEC corrections for each satellite. Values of the polynomial are calculated with respect to the reference point, given in the grid definition in GNSS-SSR-CorrectionPoints. The grid ID in the message must match the one in GNSS-SSR-CorrectionPoints.


The GNSS-SSR-GriddedCorrection-element is used by HERE GNSS Service to provide residuals between the polynomial in GNSS-SSR-STEC-Correction and the actual STEC value for each satellite in the points defined in GNSS-SSR-CorrectionPoints. The grid ID in the message must match the ones in GNSS-SSR-CorrectionPoints and GNSS-SSR-STEC-Correction.

Some satellites may be visible only from some of the grid points, meaning that STEC values are not available at each point of the grid. This can be indicated with a special value of the residual. The special value depends on which field is present in the stecResidualCorrection-r16-element. For fields b7-r16 and b16-r16, special values are -64 and -32768, respectively. If a residual has one of these values, the STEC value for corresponding satellite at the corresponding point is not available.

Grid layout

The global grid layout consists of multiple grids, each associated with a unique grid ID delivered as part of the GNSS-SSR-CorrectionPoints-message. Grids do not overlap, and it is possible for the user's location to be between grids. This does not cause issues in the STEC delay calculation algorithm, provided that the user has data for all the surrounding grids.

In current grid layout of HERE GNSS Service, all grid definitions are rectangular with a vast majority of grids consisting of 64 points, delivered in the GNSS-SSR-ArrayOfCorrectionPoints-r16-format as an 8x8 grid. The step sizes in each direction are not fixed and are subject to changes. Figure 1 contains an example of two such grids laid out adjacent to each other.

Grid example
Figure 1. Example of two adjacent grids: 8x8 arrays with step sizes 2.5 and 5.0 degrees in latitude and longitude direction, respectively.

Because the grid layout is not fixed, user may have to change grid ID(s) they have subscribed to. Changes in grid layout can be detected from the received data: If grid definition is no longer the same as the previous one, users may have to determine new grid ID(s) for their subscription by requesting all grid definitions and determine the relevant ones from there.

It should be noted that changes in grid layout happen infrequently, but client software has to be prepared for them.

How to calculate corrections

Calculating the STEC delays at user location using the message contents and utilizing them as correction data is explained in LPP specification (Section Section and QZSS ICD (Sections 5.5.4 and 5.5.7). There are, however, some ambiguities in the explanations, so below is a concrete example, that should explain the procedure in detail. The following method can always be utilized with the current grid layout used by HERE GNSS Service (unless on polar areas, where values from simply the nearest grid point should be used).

To calculate STEC corrections at any location, the user first needs to calculate STEC values from four closest surrounding points, that form a rectangle around the user. When the user is at the border of two (or more) rectangles, meaning that the user is exactly between two points, either rectangle can be used for interpolation. The four surrounding points can be from a single grid, or from multiple grids.

After choosing the points, the STEC value for each satellite is calculated for each point according to the LPP specification. The data in GNSS-SSR-STEC-Correction and GNSS-SSR-GriddedCorrection -elements associated with the grid, in which the point is, can be used to calculate these values.

The STEC value for each satellite at the user location is then calculated by interpolating the calculated STEC values. The recommended interpolation method is the bi-linear method, where the value is calculated as a weighted sum of the four calculated STEC values. Therefore, the STEC delay for the satellite can be calculated as follows:

\[ I = \frac{1}{(\phi_2-\phi_1)\cdot(\lambda_2-\lambda_1)}((\phi_2-\phi)(\lambda_2-\lambda)I_{1,1} + (\phi-\phi_1)(\lambda_2-\lambda)I_{1,2} + (\phi_2-\phi)(\lambda-\lambda_1)I_{2,1} + (\phi-\phi_1)(\lambda-\lambda_1)I_{2,2}) \]

where \(\phi\), \(\lambda\) denote the latitude and the longitude of the user location and \(\phi_1\), \(\phi_2\), \(\lambda_1\), \(\lambda_2\) denote the latitudes and the longitudes at the surrounding points. Similarly, I is the STEC delay for the satellite at user location, whereas \(I_{1,1}\), \(I_{1,2}\), \(I_{2,1}\), \(I_{2,2}\) are STEC delays at surrounding points. Figure 2 illustrates the different points and their relation to one another.

Points example
Figure 2. Illustration of grid points and interpolation.

Users should subscribe to correction data so that they can always interpolate using the four surrounding grid points. This might mean subscribing to data for multiple grids, for example, when the location of the user is between two grids. It should be noted that there is no difference in the algorithm when using data from more than one grid, as long as data for both is available and up to date. Therefore, users can move from one grid to another without any special logic, provided that the user has subscribed to data for both grids.

results matching ""

    No results matching ""