Location Services features

This page provides an overview of each method available through nRF Cloud Location Services, along with their associated features.

nRF Cloud Location Services offers location assistance using GNSS, cells, and Wi-Fi networks.

GNSS location and assistance

The following figure shows the standard, unassisted process for GNSS coordinate acquisition.

Standard implementation using a GNSS receiver

The standard, unassisted way for devices to obtain a location is using an onboard GNSS receiver, such as the nRF9151 GNSS receiver.

The receiver performs the following actions:

• Searches for satellites overhead.
• Locks on to satellite signals.
• Decodes and downloads the data.
• Computes the location using the device's distance to each satellite and the exact location of each satellite in space.

While this standard method can result in an accurate fix, there are limitations:

• Obtaining navigation data can take time. This depends upon the device's current time-to-first-fix (TTFF): the GNSS receiver downloads data at 50 bits per second (bps), slower than an LTE modem using location assistance.
• The GNSS receiver consumes significant power.
• Unassisted GNSS works best outdoors. A-GNSS can improve GNSS performance for indoor devices by making it easier for the device to find satellites.

Cloud-assisted implementation using A-GNSS and P-GNSS

To overcome the disadvantages of using a GNSS receiver, nRF Cloud offers two types of cloud assistance: A-GNSS and P-GNSS. In both cases, a fix is obtained more quickly by sending the required data to the device through the cloud instead of the satellite, and over an LTE modem with a much higher transfer rate. This allows a faster TTFF while minimizing use of the resource-intensive GNSS receiver.

Assistance data consists of the following:

• Date and time.
• Rough location on Earth (position).
• Accurate satellite orbits (ephemerides):
  • Usable for maximum four hours.
  • Must be updated in GNSS unit on time.
  • Required for a GNSS fix.
• Approximate satellite orbits (almanac):
  • Usable for a month or more.
  • Not accurate enough to compute a fix.
  • Not required if ephemerides are available.
• Other information, such as ionospheric correction or integrity data.

A-GNSS provides the latest current (not predicted) satellite positioning data to devices to help them find a satellite more quickly. This data is for all satellites, regardless of the device's position, and is typically reliable for four hours. A-GNSS also includes an SCELL request as part of its operations. This SCELL request results in an additional data point in the location history.

P-GNSS is similar to A-GNSS, but it allows devices to download predicted satellite ephemerides data for several days into the future. Your device can then use this data to more quickly determine satellite location without needing an active network connection. Predicted data can also provide offline navigation when the device is out of range of a cell.

P-GNSS is especially suited for applications where LTE connection availability is sporadic, whereas A-GNSS requires frequent use of an LTE connection to update assistance information (typically every 2 hours).

With both types of assistance, reduction in TTFF depends on whether the GNSS receiver is fed the device's approximate location, or a previous fix is hot enough to be reliably reused.

The main advantage to cloud assistance is that the data does not need to be downloaded from satellites over a slower GNSS receiver. Even without telling the GNSS receiver the device's approximate location, TTFF is improved.

Comparing unassisted GNSS, P-GNSS, and A-GNSS

The following table compares the different assistance methods available through nRF Cloud.

Assistance type	Cloud access	Memory requirement	Power consumption	Time to first fix (TTFF)
Unassisted	Not required	No flash memory required	Unrestricted	Unrestricted
A-GNSS	Frequent	No flash memory required	Restricted	Faster than unassisted and P-GNSS
P-GNSS	Infrequent	Requires predictions to be stored on flash	Restricted	Faster than unassisted GNSS but slower than A-GNSS

Time-to-first-fix

The documentation for the nRF9151 GNSS receiver describes receiver performance in different startup scenarios such as cold start and hot start. These are industry-standard terms for whether a GNSS receiver has gotten a prior fix since it was last powered on:

• Cold start: The device is starting without previous knowledge of location, date, time, internal clock oscillator frequency, or navigation data, after a reset or power cycle.
• Warm start: The device has an approximate position, date and time, internal clock oscillator frequency, and almanac, but not ephemeris. If the GNSS unit needs to decode the current orbital data for each satellite it is tracking, warm start TTFF can be around 30 seconds.
• Hot start: The device has recently obtained a fix and remembers its last position, accurate time, internal clock oscillator frequency, almanac, and ephemeris. This information enables the device to lock onto the same satellites and calculate the fix very quickly.

P-GNSS and A-GNSS operations are between hot start and warm start regarding TTFF, since orbital data is known.

Location based on cells

Cell location is based on cells near the device. Cell-based location is calculated by the cloud service and sent to the device. GNSS is not involved at all.

Cell-based location assistance (CELL_POS, whether SCELL or MCELL varieties) requires less power and memory because the device does not need to use the GNSS receiver, though the resulting fix is less accurate than GNSS-based location or Wi-Fi. The device is provided a coarse location by submitting a request containing data about the nearest and neighboring cells, if nmr is included in the request. Use of multiple cells (MCELL), if available, can result in a more accurate location.

Cell-based location is most suitable for constrained or indoor devices.

Location based on Wi-Fi networks

Using Wi-Fi location assistance, a device can query nRF Cloud for its location using the MAC addresses of Wi-Fi networks in its area. The device performs an SSID scan of Wi-Fi access points in its surrounding area and sends this data to nRF Cloud. nRF Cloud calculates the location based on the data according to a third-party database, and responds with latitude, longitude and uncertainty.

Wi-Fi location is suitable for indoor devices, or to cover areas where GNSS or cellular networks are not always available. Wi-Fi can be more accurate than GNSS and cellular location for indoor devices, since the signal range of access points indoors is typically much smaller than the range for cells or satellites.

The current implementation of this feature in samples and applications uses a cellular connection for data transfer and connectivity to nRF Cloud, so a valid SIM is also needed.

The GetLocationFromWifiNetworks endpoint supports Wi-Fi location assistance through the nRF Cloud REST API.

Ground fix

Ground fix combines cell and Wi-Fi queries into a single operation. See the cell and Wi-Fi guides for examples, as well as the nRF Cloud multi-service sample for an example integration.

See GetLocationFromCellsOrWifiNetworks for the full endpoint documentation, and the nRF Cloud portal for more information on how the service is billed.

Reverse geocoding

nRF Cloud offers a GetAddressDataFromCoordinates endpoint through the REST API. It allows you to convert a set of coordinates (latitude and longitude) into a physical address.

A successful request returns, at minimum, the country and state, province, or region of the provided coordinates.

The accuracy of the resulting address depends on the method used to obtain the coordinates. Using a lower-accuracy method, such as cellular, gives coordinates that may be further from the device's actual location than a higher-accuracy method (GNSS or Wi-Fi).

Guides

See the list of guides for instructions by method.