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

Supported SPARTN Messages

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.

Supported RTCM Messages

The RTCM data format applies a standard for the network communication and encoding of GNSS data.  It was the first published standard by the Radio Technical Commission for Maritime Services for Differential GNSS and is used today by many high-precision GNSS receivers.

Data Distribution Protocols

PointPerfect corrections can be delivered through MQTT 3.1.1 or NTRIP (NTRIP is for either SPARTN/NTRIP or RTCM over 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. 

Payload Estimation

The payload data throughput depends on the delivery and distribution used. The localized distribution improves data usage efficiency, reduces energy consumption, and saves costs, promoting environmental conservation.


MQTT IP Delivery (SPARTN)

MQTT is a lightweight publish-subscribe protocol designed for efficient machine-to-machine communication, commonly used in IoT applications. PointPerfect MQTT messages begin with the MQTT header. Each message (OCB, CLK, HPAC, & GAD) is part of a serialized data stream that is updated at 30-second intervals. Continental messages contain data for the entire region, and maximums can be smaller depending on the region. Localized messages only include area-specific information, leading to reduced data throughput.

Note for MQTT configuration: It is important to ensure your device has enough memory allocated to avoid failures. We suggest adjusting your data buffer limits to 1.5 times the maximum observed payload to accommodate the current payload and allow for future development if needed. This will ensure you have enough capacity to avoid potential bottlenecks during processing and to accommodate any additional GNSS signals if added.  

NTRIP IP Delivery (SPARTN)

PointPerfect NTRIP service provides PPP-RTK correction data in SPARTN format, which is compatible with u-blox F9 GNSS receiver modules. The entire payload is delivered upfront and then becomes a continuous stream. This approach doubles the initial payload size but improves the Time to First Fix (TTFF). NTRIP and MQTT both utilize the same source of corrections but are delivered in different protocols.

NTRIP IP Delivery (RTCM) 

As mentioned above the RTCM data format applies a standard for the network communication and encoding of GNSS data.  


PointPerfect delivers RTCM 3.3 via NTRIP when a user selects an RTCM plan.

L-band Delivery 

Correction data from L-band satellites is continuously streamed at a set rate of 300 Bytes per second. Both L-band and MQTT share the same source of corrections. 

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  or PointPerfect RTCM Distribution pages.

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 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"

   }

   }