PointPerfect Service Description

Overview

The PointPerfect service is designed to provide high-precision GNSS corrections to suitable receivers (e.g. u-blox F9 platform products) within a client system to allow for decimeter-level location accuracy. The product page for Pointperfect includes technical specifications of the PointPerfect Service including reference frame, GNSS signal support, and more information on data format and other distribution details. Additional information about how our PointPerfect service is shared here.

GNSS corrections can be distributed to your receiver in various ways to suit your needs.  For more details, see the Data Distribution Protocols section.

Service Coverage

Our Service Coverage page shows where we currently provide our PointPerfect service.  Coverage includes up to 12 nautical miles (roughly 22 kilometers) off continental coastlines.  Note, some distribution methods may not be available in all areas and bandwidth estimations may vary. 

Device Provisioning

The service allows for device provisioning through the User Interface of the Thingstream platform, or through the API interface for programmatic provisioning.

Find out more information about Device Provisioning: PointPerfect getting started guide
Find out more information about Zero Touch Provisioning: PointPerfect Zero Touch Provisioning

Data Format

PointPerfect correction data consists of a collection of messages in the SPARTN 2.0 format.  SPARTN is an industry recognized standard that supports wide and global area broadcasts and other performance requirements.  

The SPARTN message format is an evolution of other legacy state space representation (SSR) formats that have been made available by different players in the GNSS industry. The table below shows supported SPARTN message types which are also described in the F9 Integration Manual. [1] Refer to the output of the UBX-RXM-COR message to review how this information is received.

Data Distribution Protocols

PointPerfect corrections can be delivered through MQTT 3.1.1 or NTRIP protocols for IP-based connections, or via L-band satellite.  

The links below go to pages that describe each distribution method, including related architecture and other protocol usage details. 

Below is a table of our delivery and distribution methods available. 

MQTT Payload Estimation

MQTT payload estimates vary by the distribution method and by region.  For example, Continental payloads in South Korea and Japan may be one-third that of Europe, and Localized corrections are generally smaller resulting in lower bandwidth usage and user data costs. 


Correction data from L-band satellites is streamed continuously at a rate of 9000 bytes per 30 seconds. 


PointPerfect SPARTN Correction OCB messages are sent to the MQTT broker every 5 seconds, while HPAC and GAD messages are sent every 30 seconds. PointPerfect localized corrections are generally smaller than continental corrections, resulting in a reduction in bandwidth usage and lower user data costs of up to 80% depending on your region.  The following table shows the differences between Localized and Continental payloads for the US region. 

*The IP Continental HPAC message is received in four smaller messages that are sent simultaneously 

Note 1: Because NTRIP and MQTT Continental use the same source the values quoted in the table above for IP Continental also relate to NTRIP. 

Note 2: It is important to ensure your device has enough memory allocation to avoid possible failures. We recommend adjusting your data buffer limits to 1.5 times the observed payload average to accommodate the current payload while leaving room for future growth. This will make sure you have enough capacity to avoid potential bottlenecks during processing as well as to accommodate any additional GNSS signals when added. 

Client Authentication and Encryption

Each client must authenticate with the PointPerfect service to apply corrections to the device. Credentials are provided for each device (aka ‘Thing’) in our Thingstream platform. 

Encryption is applied only to our Continental streams, provided via MQTT or L-band satellite.  Clients using these plans must acquire dynamic keys to access the corrections data. Corrections delivered via NTRIP or with the Localized distribution of our MQTT delivery method are not encrypted.

The implementation of encryption & authentication for SPARTN messages is described in section 8.15 of the SPARTN 2.0 specification.[4] However, PointPerfect implements a system-wide approach to authentication and encryption that combines elements of the SPARTN specification with those of MQTT.

Client Authentication with NTRIP

Client Authentication for NTRIP uses a device specific username and password.  The port used to connect to the NTRIP caster will designate if you wish to apply additional TLS encryption for your credentials.  For more information, see our PointPerfect NTRIP Distribution page.

Client Authentication with the MQTT Broker

Connections to the PointPerfect MQTT broker are made over TLS using system-unique X.509 certificates, available for download on the Thingstream platform. These certificates provide mutual trust between the client system and the MQTT broker. The MQTT client must also be configured with client-unique credentials (client ID, client certificate). 

Message Decryption with Dynamic Keys

This section applies only to solutions that use our service via MQTT Continental distribution or L-band satellite delivery.  It does not apply when implementing our NTRIP delivery method or Localized distribution via MQTT. 

The SPARTN messages published as a Continental stream are encrypted per section 8.15 of the SPARTN specification.[4]  These messages are delivered through MQTT topics (/pp/<plan>/<region>) for any IP or L-band+IP plans using our MQTT Continental distribution. When using u-blox high precision GNSS receivers (e.g. u-blox F9 platform products), the decryption of the messages and the validation of messages using the SPARTN Group Authentication Message[4] is performed in the module itself.

Dynamic keys are rotated approximately every 28-35 days.  When obtaining the dynamic key lease, the message will contain two keys labeled “current” and “next” with details of each key validity period.  You can find these keys under the Credentials tab in Thingstream and compare them to the content of the UBX-RXM-SPARTNKEY message on your device.

Obtaining Dynamic Keys

Timely connections via MQTT or HTTPS  (or alternative methods for key management) are needed to collect valid keys for the time period. Collecting valid dynamic keys for your device can be done in various ways.  

For devices with a consistent internet connection, the client system can simply subscribe to the MQTT key topic (/pp/ubx/0236/<plan>) and obtain the current dynamic keys. This key topic has a single message published to it by the PointPerfect service with the MQTT RETAIN flag set, through a dedicated REST API over HTTPS.  

If you are using corrections from the L-band satellite, a consistent internet connection may not be available (if at all.)  We have listed some options below to update your dynamic keys. To extend the amount of time before you must update the keys, collect both ‘current’ and ‘next’ keys and provide logic in your host application to use the ‘next’ key after the start date provided. The keys may then be cached on the client while they remain valid.

The dynamic keys lease message is encapsulated in a JSON structure in the following format: 

 {

   "dynamickeys":{

   "current":{

      "start":"Current key lease start time (ms since start of epoch UTC)",

      "duration":"Current key lease duration (ms)",

         "value":"Current key as hex string"

   },

   "next":{

      "start":"The next key lease start time (ms since start of epoch UTC)",

      "duration":"Next key lease duration (ms)",

      "value":"Next key as hex string"

   }

   }