AssistNow User Guide

System  Overview

Due to the relatively slow broadcast data rate from satellites, there can be a significant delay in providing the first position fix from a GNSS receiver after initial switch on. Assisted GNSS (A-GNSS) uses a reference network to collect data, such as ephemeris, almanac, accurate time and satellite status. It passes the data on to the target receiver via any suitable communications link. 

Such assistance data enables the receiver to compute a position within a few seconds, even under adverse signal conditions when data demodulation is error prone or when satellites are not in view of the receiver.

The u-blox MGA (Multi GNSS AssistNow) services provide a proprietary implementation of an A-GNSS protocol supported by u-blox GNSS receivers. When a client device makes an MGA assistance request, the service responds with the requested data using UBX protocol messages. These messages are ready for direct transmission to the receiver communication port without requiring any modification by the client.

Currently, these MGA services consist of AssistNow Online and Offline, each delivered by the HTTPS protocol.

AssistNow Online provides satellite ephemerides, health information and time aiding data suitable for GNSS receiver systems with direct internet access. The AssistNow Offline service benefits u-blox GNSS receivers that only have occasional internet access. Users request data from the service by specifying the time period for which they want coverage (1 to 5 weeks). The data downloaded from the service is organized by date and encoded into a sequence of UBX-MGA messages.

In order to access either service, users must be authorized and provided with an access token. Please see the section MGA access tokens for more details. 

The u-blox MGA services can provide data for multiple GNSS systems. See the MGA AssistNow Online and Offline section for more details on the supported GNSS constellations.

For more information regarding MGA assistance messages that are supported from M8 onwards, see the relevant u-blox Receiver Protocol specification document. u-blox M10 receiver protocol specification are linked at the end of this document [1]. In general, you can find receiver protocol specification from the u-blox website at the specific receiver product page. 

System architecture

The assistance system relies on a set of monitoring stations distributed around the globe to submit satellite broadcast data to the u-blox assistance servers. The system combines all the reports from the submitters and builds a best view of the current broadcast data sets for multi-GNSS constellations. The service makes assistance available to any u-blox customers and optionally filters data based on parameters (e.g. only SVs visible from a given position). The customer application or u-blox cellular module pulls data from the server and pushes it to the receiver.

The AssistNow system architecture is illustrated below.  Figure below shows MGA system elements using typical assistance client (customer application).

Upon making a request, the server delivers a set of u-blox binary messages with class "MGA". These are assistance messages for each constellation type, with message IDs subdivided into types, such as EPH or ALM (the "format" parameter optionally provides support for u-blox 7 and previous generations. In this case, the messages will be of class "AID"). For more information on receiver message types, see the Receiver protocol specification [1].

*per constellation. The final packet size depends on the constellation selected, the data types requested, and the number of satellites in view.

Typical data volumes 

Table below shows typical AssistNow Online data volumes for a receiver using the GPS, GLONASS, GAL, BDS, and QZSS constellations. For example, the total ephemerides data size for GPS, GLONASS and QZSS constellations is around 3552 bytes.

Table below shows typical AssistNow Offline data volumes for receivers using different GNSS constellations and different validity periods

Although indicative of typical performance, a number of factors (including clock bias/drift prediction, space weather, earth orientation and modeling uncertainties) result in these figures having significantly more variation than conventional TTFF and position accuracy tests.

HTTPS Protocol

Overview

All MGA services exchange information via the HTTPS over SSL protocol.

Request format

The HTTPS GET request from the client to the server contains a standard HTTPS query string in the request URL. The query string consists of a set of key=value parameters in the following form:

key=value;key=value;key=value;

The following rules apply:

·        The order of parameters is not important.

·        Keys and values are case sensitive

·        Keys and values must be separated by an equals character (“=“)

·        Key/value pairs must be separated by semicolons (“;”) or an ampersand (“&”)

·        If a value contains a list, each item in the list must be separated by a comma (“,”)

Numeric values must conform to the regular expression: ^-?[0-9]+(\.[0-9]+)?$. This represents in order: an optional negative sign, one or more digits, and optionally a decimal point and one or more digits.

Upon reception of a standard HTTPS GET request, the server responds with the required messages in binary format, or an error string in text format. After delivery of all data, the server terminates the connection. All URL data (with the exception of hostname, which is used to establish the connection) is carried solely within the encrypted connection and is protected from man-in-the-middle attacks in the same way that any HTTPS data is.

The easiest method to format a request is to use the GUI provided by the u-blox u-center application and then copy the text shown in the “Server request string” box. To try it out, the request can be pasted into an internet browser.

Overuse restrictions

To avoid overload of the services, overuse restrictions are applied to incoming requests. If the overload limit is reached, the service will respond with HTTPS status code 403 (Forbidden). In MGA services comparison Table, the row “Data load frequency” shows the expected usage from an individual device. Excessive use of the services will result in some of the requests to the service being blocked.

AssistNow S2S

AssistNow is optionally available as a service-to-service (S2S) variant. If you have business, technical, or security requirements that constrain the devices from connecting directly to services outside of your private networks, u-blox offers the option of a S2S deployment. With AssistNow S2S, the privacy and confidentiality of your data is safeguarded as it proceeds directly from service to the enterprise. See image below.

Please contact your u-blox sales representative for T&Cs and pricing information. 

MGA AssistNow Online

AssistNow Online is u-blox's end-to-end Assisted GNSS (A-GNSS) solution for receivers that have access to the internet. Data supplied by the AssistNow Online Service is used by a u-blox GNSS receiver in order to substantially reduce Time To First Fix (TTFF), even under poor signal conditions. The data provided includes time aiding data, earth orientation parameters and satellite almanacs, ephemerides, and health information.

This section describes the protocol between the u-blox MGA AssistNow Online Server, and the MGA AssistNow Online Client requesting information.

Request parameters

The following parameters are supported:

For example, all the ephemeris, almanac and auxiliary data for both GPS and GLONASS can be requested as follows (if a valid token is provided):

/GetOnlineData.ashx?token=XXXXXXXXXXXXXXXXXXXXXX;gnss=gps,glo;datatype=eph,alm,aux;

To form a complete URL, the above example requires a valid prefix, such as 

https://online-live1.services.u-blox.com

Best practices

Request frequency

Excessive use of the service from the same IP address will result in blocked requests. A device is only expected to request assistance data at startup. Therefore, there is no need to request assistance data when the receiver is already in tracking mode because the receiver will keep itself updated directly from the satellites thereafter. 

Position parameters (lat, lon, alt and pacc)

The position parameters (lat, lon, alt and pacc) are optional and are used for two purposes:

1)  If the filteronpos parameter is provided, the server determines the currently visible satellites at the user position, and only sends the ephemeris data of those satellites that should be in view at the location of the user. This reduces bandwidth requirements. In this case, the “pacc” value is taken into account, meaning that the server returns all SVs visible in the given uncertainty region.

2) For better performance the host should submit the position information in the GNSS receiver according to the message format UBX-MGA-INI-POS_LLH or UBX-MGA-INI-POS_XYZ (see The GNSS Interface specification [1]).  According to the position accuracy provided the GNSS can decide the best strategy to minimize the Time-To-First-Fix. For example, if the position is accurate to 100 km or better, the u-blox receiver chooses to go for a more optimistic startup strategy. This results in quicker startup time. If the submitted user position is less accurate than what is specified with the “pacc” parameter, then the user experiences prolonged or even failed start-ups. 

Time parameters (tacc and latency)

Time data is always returned with each request. The time data refers to the time at which the response leaves the server, corrected by an optional “latency” value. This time data provided by the service is accurate to approximately 10 ms, but by default the time accuracy is +/-10 seconds in order to account for network latency and any time between the client receiving the data and it being provided to the receiver.

If both the network latency and the client latency can safely be assumed to be very low (or are known), then the client can choose to set the accuracy of the time message (tacc) to a much smaller value (e.g. 0.5 s). This results in a faster TTFF. The latency value can also be adjusted as appropriate. However, these parameters should be used with caution: if the time accuracy is not correct when the time data reaches the receiver, the receiver may experience prolonged or even failed start-ups.

For optimal results, the client should establish an accurate sense of time itself (by maintaining local RTC via a backup supply or using a u-blox cellular modem and “RTC sharing” functionality) and then modify the time data received from the service as appropriate.

MGA AssistNow Offline

Users of AssistNow Offline are expected to download data from the AssistNow Offline Service, specifying the time period they want covered (1 to 5 weeks) and the type(s) of GNSS to use. This data must be transferred to a u-blox receiver, so that it can estimate the positions of the satellites when no better data is available. Using these estimates does not provide as accurate a position fix as if current ephemeris data is used, but it allows much faster TTFFs in nearly all cases. See Image below.

The data obtained from the AssistNow Offline Service is organized by date, normally a day at a time. Consequently the more weeks for which coverage is requested, the larger the amount of data to handle; see the AssistNow offline Data volumes table . Similarly, each different GNSS requires its own data. In extreme cases, the service may provide several hundred kilobytes of data. This amount can be reduced by requesting a lower resolution, but this has a small negative impact on both position accuracy and TTFF. See image above

Although indicative of typical performance, a number of factors (including clock bias/drift prediction, space weather, earth orientation and modeling uncertainties) result in these figures having significantly more variation than conventional TTFF and position accuracy tests.

Request parameters

This section describes the protocol between the u-blox AssistNow Offline Server and the AssistNow Offline Client that requests the information.

The information exchange is based on the HTTPS protocol. Upon reception of an HTTPS GET request, the server responds with the UBX-MGA-ANO messages in binary format, or an error string in text format. After delivery of all of the data, the server terminates the connection.

The response data is ordered by timestamp and then by GNSS. Hence, the response data appears as follows:

04/09/2013 [GPS SV1, GPS SV2, GPS SV3....GPS SV32]

04/09/2013 [GLO SV1, GLO SV2, GLO SV3....GLO SV24]

05/09/2013 [GPS SV1, GPS SV2, GPS SV3....GPS SV32]

05/09/2013 [GLO SV1, GLO SV2, GLO SV3....GLO SV24]

.

.

.

09/10/2013 [GPS SV1, GPS SV2, GPS SV3....GPS SV32]

09/10/2013 [GLO SV1, GLO SV2, GLO SV3....GLO SV24]

The following parameters are supported:

For u-blox M8 and later products, it is recommended to leave the ”format” parameter with the default value "mga", because other format values will not be supported in future generations. 

Best Practices

Request frequency

Excessive use of the service from the same IP address will result in blocked requests. The offline service typically updates once or twice a day, so frequent requests are not necessary.

Almanac Data and GLONASS

The receiver needs a valid set of GLONASS almanac data in order to use the GLONASS offline data. If the receiver does not have this, it can be obtained from the MGA AssistNow Online service (see MGA AssistNow Online section).

GPS Offline does not need an almanac but using one is highly recommended since it improves the performance significantly.

Time, Position and Almanac

While AssistNow Offline can be used on its own, it is expected that the user will provide estimates of the receiver's current position and the current time, and ensure that a reasonably up-to-date almanac is available.

In most cases, this information is likely to be available without the user needing to do anything.

For example, where the receiver is connected to a battery backup power supply and has a functioning real time clock (RTC), the receiver will keep its own sense of time and will retain the last known position and any almanac.

However, should the receiver be completely unpowered before start-up, then it will greatly improve TTFF if time, position and the almanac can be supplied in some form.

Almanac data has a validity period of several weeks and can be downloaded from the AssistNow Offline service. It can then be stored in the host for uploading on receiver startup, or it can be transferred to the receiver straight away and preserved there (provided suitable non-volatile storage is available). Obviously, where a receiver has a functioning RTC, it should be able to keep its own sense of time, but where no RTC is fitted (or power is completely turned off), providing a time estimate via the UBX-MGA-INI-TIME_UTC message will be beneficial.

Similarly, where a receiver has effective non-volatile storage, the last known position will be recalled, but if this is not the case, then it will help TTFF to provide a position estimate via one of the UBX-MGA-INI-POS_XYZ or UBX-MGA-INI-POS_LLH messages.

Where circumstances prevent the provision of all three of these pieces of data, providing some of them is likely to be better than none at all.

MGA server addresses

AssistNow Online

There are two AssistNow Online servers available. The two URLs are:

• online-live1.services.u-blox.com

• online-live2.services.u-blox.com

Users may obtain data from either address. 

An example request for aiding data requiring GPS and GLONASS ephemeris is as follows (a valid token should be provided):

https://online-live1.services.u-blox.com/GetOnlineData.ashx?token=XXXXXXXXX;gnss=gps,glo;datatype=eph

AssistNow Offline

Like the Online service, two server addresses:

• offline-live1.services.u-blox.com

• offline-live2.services.u-blox.com

An example request for GPS aiding data for 1 week with resolution = 1 day is as follows (a valid token should be provided):

https://offline-live1.services.u-blox.com/GetOfflineData.ashx?token=XXXXXXXXX;gnss=gps;period=1;resolution=1

MGA access tokens

Temporary Token

To evaluate MGA services, you can obtain an MGA access token from the following URL:

• https://www.u-blox.com/en/assistnow-service-evaluation-token-request-form

Fill in the form to request a token, which allows access to the servers. This token can then be used in multiple instances. Please note that this is a temporary token and is valid for 90 days. After this period you can redeem your temporary token and it will become permanent. 

Permanent Token

For more information regarding permanent tokens,  please refer to the AssistNow getting started guide.  

Host software and the MGA library

This section describes the host software required to make use of MGA services and the u-blox MGA library. References are made to the u-blox UBX message protocol. For a detailed description of the content of these messages, see the relevant u-blox Receiver Description document [1].

Host software AssistNow Online

As u-blox receivers do not connect directly with the internet, the AssistNow Online system requires the host system (that contains the receiver) to connect to the internet, download the data from the AssistNow Online Service and forward it to the receiver. This can also be achieved with u-blox cellular modules [2]. 

The simplest case is to fetch the data from the AssistNow Online Service (by means of a single HTTPS GET request), and send the resulting data to the receiver. The data returned by the AssistNow Online Service is a sequence of UBX-MGA messages, starting with an estimate of the current time in the form of a UBX-MGA-INI-TIME_UTC message.

Note: It is very important that the receiver has started up fully before sending it any assistance data. The first assistance message provides the receiver with a sense of time. If this message is not received for any reason, the receiver will not use the rest of the assistance data.

Host software AssistNow Offline

The downloaded Offline data is encoded in a sequence of UBX-MGA-ANO messages, one for every SV for every day of the period covered. Thus, for example, data for all GPS SVs for 4 weeks contains in excess of 900 separate messages, taking up around 70 kilobytes.

For u-blox receivers that have flash storage, all the data can be directly transferred to the flash until it is needed. These receivers automatically select the most appropriate data to use at any time. See flash-based AssistNow Offline section for more details.

Receivers without flash storage or with insufficient spare flash memory can also use AssistNow Offline. In this case, the customer's system must store the AssistNow Offline data until the receiver needs it and then transfer only the data needed for immediate use. See host-based AssistNow Offline section further details.

Flash-based AssistNow Offline

Flash-based AssistNow Offline functionality means that AssistNow Offline data is stored in the flash memory connected to the chip (e.g. NEO-M8N).

The user's host system downloads the data from the AssistNow Offline service when an internet connection is available, and then delivers the data to the GNSS receiver. As the total amount of data to be transferred is large (typically around 100 kilobytes) and writing to flash memory is slow, the transfer must be done in blocks of up to 512 bytes, one at a time. The UBX-MGA-FLASH-DATA message is used to transmit each block to the receiver.

AssistNow Offline data stored in flash memory is not affected by any reset of the receiver. To clear the data, completely erase the whole flash memory or overwrite it with a new set of AssistNow Offline data. Transferring a dummy block of data (e.g. all zeros) also has the effect of deleting the data, although this uses a small amount of flash storage.

Flash-based storage procedure

The following steps are a typical sequence for transferring AssistNow Offline data into the receiver's flash memory:

• The host downloads a copy of a latest data from the AssistNow Offline service and stores it locally.

• It sends the first 512 bytes of that data using the UBX-MGA-FLASH-DATA message.

• It awaits a UBX-MGA-FLASH-ACK message in reply.

• Based on the contents of the UBX-MGA-FLASH-ACK message, the host sends the next block, resends the last block or aborts the whole process.

• The above three steps are repeated until all the rest of the data has been successfully transferred (or the process has been aborted).

• The host sends an UBX-MGA-FLASH-STOP message to indicate completion of the transfer.

• The host awaits the final UBX-MGA-FLASH-ACK message in reply. Background processing in the receiver prepares the transferred data for use at this stage. Particularly if the receiver is currently busy, this may take many seconds, so the host must be prepared for a delay before the UBX-MGA-FLASH-ACK is seen.

Note that the final block may be smaller than 512 bytes (where the total data size is not perfectly divisible by 512). Also, the UBX-MGA-FLASH-ACK messages are distinct from the UBX-MGA-ACK messages used for other AssistNow functions.

Any existing data will be deleted as soon as the first block of new data arrives, so no useful data will be available until the completion of the data transfer. Each block of data has a sequence number, starting at zero for the first block. In order to guard against invalid partial data downloads, the receiver will not accept blocks that are out of sequence.

Host-based AssistNow Offline

If the u-blox receiver has no embedded Flash (such as in MAX-M8C), it can use host-based AssistNow Offline. The user's host system downloads the data from the AssistNow Offline service when an internet connection is available. The host stores the AssistNow Offline data so that it is available when the u-blox receiver needs it.

When the receiver needs the data, the host transfers just the relevant portion of the data to the receiver, so that the receiver can start using it. This is achieved by reading the date of each message and selecting only those UBX-MGA-ANO messages with a date-stamp nearest the current time. As each message is a complete UBX message, it can be sent directly to the receiver with no extra packaging.

When parsing the data obtained from the AssistNow Offline service, the following points should be noted:

• The data is made up of a sequence of UBX-MGA-ANO messages.

• Customers should not rely on the messages all being a fixed sized, but should read their length from the UBX header to work out where the message ends (and where the next begins).

• Each message indicates the SV for which it is applicable through the svId and gnssId fields.

• Each message contains a date-stamp within the year, month and day fields.

• Midday (UTC) on the day indicated should be considered the time when the data is most applicable.

• The messages will be ordered chronologically, earliest first.

• Messages with same date-stamp will be ordered by ascending gnssId and then ascending svId.

Host-based procedure

The following steps are a typical sequence for host-based AssistNow Offline:

• The host downloads a copy of a latest data from the AssistNow Offline service and stores it locally.

• It is recommended to also download a current set of almanac data. These are also available from the AssistNow Offline service.

• It waits until it wants to use the GNSS receiver.

• Transfers any almanac (e.g. UBX-MGA-GPS-ALM for GPS), position estimate (UBX-MGA-INI-POS) and/or time estimate (UBX-MGA-INI-TIME) to the receiver.

• It scans through AssistNow Offline data looking for entries with a date-stamp that most closely matches the current (UTC) time/date.

• It sends each such UBX-MGA-ANO message to the receiver.

When data has been downloaded from the AssistNow Offline service with the (default) resolution of one day, the closest matching date-stamp is selected simply by looking for ones with the current (UTC) date.

Flow control

u-blox GNSS receivers aim to process incoming messages as quickly as possible, but there will always be a small delay in processing each message. Transferring assistance data to the receiver can involve sending as many as one hundred individual messages to the receiver, one after the other. If the communication link is fast, and/or the receiver is busy (trying to acquire new signals), it is possible that the internal buffers will overflow and some messages will be lost. To avoid this, u-blox receivers support an optional flow control mechanism for assistance.

*If required, the user can select to employ flow control, but in most cases this is likely to prove unnecessary.

For u-blox generation 8 and below receivers, flow control is activated by setting the ackAiding parameter in the UBX-CFG-NAVX5 message. For u-blox generation 9 and 10 receivers, this can be activated by setting the CFG-NAVSPG-ACKAIDING configuration item in the UBX-CFG-VALSET message. As a result, the receiver will issue an acknowledgement message (UBX-MGA-ACK) for each assistance message it successfully receives. The host software can examine these acknowledgements to establish whether there were any problems with the data sent to the receiver and deduce (by the lack of acknowledgement) if any messages have been lost. It may then be appropriate to resend some of the assistance messages.

The simplest way to implement flow control would be to send one UBX-MGA assistance message at a time, waiting for the acknowledgement, before sending the next. However, such a strategy is likely to introduce significant delays into the whole assistance process. The best strategy will depend on the amount of assistance data that is being sent and the nature of the communications link (e.g. baud rate of serial link). u-blox recommends that when customers are developing their host software they start by sending all assistance messages and then analyze the resulting acknowledgements to see whether there have been significant losses. Adding small delays during the transmission may be a simple but effective way to avoid substantial loss of data.

MGA library sample code

u-blox can provide a platform-independent library to help customers easily implement clients for accessing the MGA services (both AssistNow Online and Offline). The aim of this library, called libMGA, is to facilitate the easy integration of MGA services into a customer’s application, while avoiding the need to have a detailed knowledge of the underlying communication protocols between the application and the MGA service, and between the application and the receiver. Figure below shows the intended implementation method when using the library.

During implementation, keep the following points in mind:

1.      The user application calls the libMGA API function just like any other library.

2.      The data stream to and from the receiver is handled by the user application.

3.      The application passes each UBX message individually on to the libMGA.

4.      libMGA uses callbacks to:

• write data to the receiver

• report on operational progress

The libMGA code and release notes are available to customers via u-blox services support. Please contact us at services-support@u-blox.com for more information.  

MGA services used with u-blox cellular modules

Host software for MGA services has been integrated into the u-blox Cellular modules. This removes the need for customers to implement software to communicate with the assistance servers. See the GNSS Implementation application note [2] for further information.

MGA service migration

The MGA service has been set up to provide multi-GNSS assistance data over the internet to all u-blox receivers. This section addresses customers currently using u-blox 7 and previous u-blox generations who are migrating to the MGA service. Table below summarizes the key points required to migrate between services. 

1. These services are deprecated and must not be used in new designs.  AID protocol is also deprecated and will not be supported in future revisions. 

Table below shows how to migrate the service request parameters from legacy services to the MGA services.

Table below shows how to migrate the contents of the command (cmd) parameter