SSID-based Wi-Fi locationing: Comparing performance with other location services

SSID-based Wi-Fi locationing: Comparing performance with other location services

With the introduction of the nRF7000 Wi-Fi companion IC, we now offer a complete silicon-to-cloud locationing solution with Wi-Fi, cellular IoT, and GNSS. The nRF7000 is optimized for Wi-Fi network scanning, and together with the nRF91 Series cellular IoT SiP, it enables SSID-based Wi-Fi locationing. Nordic’s SSID-based Wi-Fi locationing enables the acquisition of accurate location fixes in an extremely power-efficient manner both indoors and outdoors, in urban and suburban areas. This is a valuable complement to GNSS, especially in buildings and dense urban areas where GNSS can fail due to signal fading and interruptions.

This blog post will give an introduction to how our SSID-based Wi-Fi locationing solution works and how to get started testing it. Then, we will perform and present actual power consumption and accuracy measurements using the nRF9160 DK, nRF7002 EK, and PPK2 to compare the performance of the different location services available in nRF Cloud.

Background Knowledge

Wi-Fi locationing service

Wi-Fi is a well-known wireless networking technology used for local area networking of devices and Internet access. Wi-Fi provides convenient wireless Internet access service through Wi-Fi networks in environments like homes, offices, and schools.

Wi-Fi locationing is a geolocation functionality that allows Wi-Fi-enabled devices to determine their approximate location using data from nearby Wi-Fi networks. It works by retrieving Wi-Fi network information like SSID, BSSID, and signal strength of nearby networks and comparing this information to a database of Wi-Fi networks with known locations.

A Wi-Fi locationing system contains the following key components:

  • Wi-Fi radio in the user's device to detect nearby networks.

  • Database that maps Wi-Fi network information like MAC addresses to locations. This database is maintained by location service providers.

  • Algorithm to estimate location by looking for pattern matches in the database and calculating signal strengths.

When a device queries the location service, it provides data on all the Wi-Fi networks it can see. The service looks up the networks in its database, finds the associated locations, and estimates a location for the device based on similarities and signal strengths.

nRF Cloud Wi-Fi location service

The nRF Cloud offers location services that provide fast and power-efficient location capabilities tailored for Nordic silicon chips. They can help devices and applications that need location data without high power draw. Multiple location technologies are offered, including Assisted-GPS, Predictive-GPS, Single-Cell, Multi-Cell, and Wi-Fi locations. By leveraging nRF Cloud's optimized location algorithms, products built on Nordic SoCs and SiPs can achieve high performance with ultra-low power consumption for location use cases. For Wi-Fi location requests, nRF Cloud can calculate the device position with the help of a Wi-Fi database, which has coordinates of different Wi-Fi networks. The device position is then sent from the nRF Cloud to either the customer cloud or back to the device.

nRF70 Series

Nordic Semiconductor released our Wi-Fi product series, the nRF70 Series, early this year. The first chip launched in this series is the nRF7002, which is an ultra-low-power dual-band wireless companion IC that adds low-power Wi-Fi® 6 capabilities to another host chip. In addition, we recently introduced the nRF7000, dedicated to this use case. It is a dual-band Wi-Fi companion IC that does not send data but can do active and passive scanning purely for Wi-Fi locationing purposes. In conjunction with our nRF9160 cellular IoT SiPs and nRF Cloud services, the nRF7000 enables Wi-Fi-based location service by sniffing the SSID of local Wi-Fi access points.

Wi-Fi Location Service Process

The Cellular: Location sample in the nRF Connect SDK demonstrates how to use the different location services offered by nRF Cloud.

Let's test how the nRF Cloud Wi-Fi locationing service works in an indoor environment.

  • Hardware: nRF9160 DK, nRF7002 EK, PPK2.
  • Software: nRF Connect SDK v2.4.2, MFW v1.3.5, Power Profiler application in nRF Connect for Desktop.

The hardware connection is set up according to the picture below. In the Power Profiler application, configure the PPK2 source meter mode to power the nRF9160 SiP on the DK and record its current consumption change.

The original location_wifi_get() function in the Cellular: Location sample can be used to request Wi-Fi location service. Additional log configurations are enabled to help to understand the request process.

# Add the following lines to the end of prj.conf
CONFIG_LOCATION_LOG_LEVEL_DBG=y
CONFIG_NRF_CLOUD_REST_LOG_LEVEL_DBG=y
CONFIG_REST_CLIENT_LOG_LEVEL_DBG=y
CONFIG_NRF_CLOUD_LOG_LOG_LEVEL_DBG=y
CONFIG_NRF_CLOUD_LOG_LEVEL_DBG=y 

Let's go through the process of how to use location_wifi_get() to request the Wi-Fi locationing service. We have split the process into three steps to explain the Wi-Fi locationing service request process.

Step 1: Scan Wi-Fi APs information

In this step, the Wi-Fi locationing service is configured, and the device starts scanning for nearby Wi-Fi access points. The result shows that the device found 14 Wi-Fi APs near or in the Nordic Semiconductor Oslo office building.

Requesting Wi-Fi location with GNSS and cellular fallback...
[00:01:19.903,594] <dbg> location: location_core_config_log: Location configuration:
[00:01:19.911,682] <dbg> location: location_core_config_log:   Methods count: 1
[00:01:19.919,342] <dbg> location: location_core_config_log:   Interval: 0
[00:01:19.926,605] <dbg> location: location_core_config_log:   Timeout: 300000ms
[00:01:19.934,356] <dbg> location: location_core_config_log:   Mode: 0
[00:01:19.941,223] <dbg> location: location_core_config_log:   List of methods:
[00:01:19.948,913] <dbg> location: location_core_config_log:     Method #0
[00:01:19.956,146] <dbg> location: location_core_config_log:       Method type: Wi-Fi (3)
[00:01:19.964,660] <dbg> location: location_core_config_log:       Timeout: 30000ms
[00:01:19.972,686] <dbg> location: location_core_config_log:       Service: Any (0)
[00:01:20.044,921] <dbg> location: location_request_info_create: Wi-Fi and cellular methods are not one after the other in method list so they are not combined
[00:01:20.059,448] <dbg> location: location_core_location_get_pos: Requesting location with 'Wi-Fi' method
[00:01:20.069,458] <dbg> location: location_core_location_get_pos: Starting request timer with timeout=300000
[00:01:20.079,711] <dbg> location: location_core_timer_start: Starting timer with timeout=30000
[00:01:20.088,745] <dbg> location: scan_wifi_start: Triggering start of Wi-Fi scanning
[00:01:24.832,458] <dbg> location: scan_wifi_result_handle: scan result #1 stored: ssid XXXX, channel 108, mac 24:36:da:16:xx:xx
[00:01:24.845,184] <dbg> location: scan_wifi_result_handle: scan result #2 stored: ssid XXXX, channel 108, mac 24:36:da:16:xx:xx
[00:01:24.858,093] <dbg> location: scan_wifi_result_handle: scan result #3 stored: ssid XXXX, channel 11, mac 24:36:da:16:xx:xx
[00:01:24.870,910] <dbg> location: scan_wifi_result_handle: scan result #4 stored: ssid XXXX, channel 11, mac 24:36:da:16:xx:xx
[00:01:24.883,483] <dbg> location: scan_wifi_result_handle: scan result #5 stored: ssid XXXX, channel 1, mac 24:36:da:11:xx:xx
[00:01:24.896,209] <dbg> location: scan_wifi_result_handle: scan result #6 stored: ssid XXXX, channel 1, mac 24:36:da:17:xx:xx
[00:01:24.908,935] <dbg> location: scan_wifi_result_handle: scan result #7 stored: ssid XXXX, channel 1, mac 24:36:da:17:xx:xx
[00:01:24.921,417] <dbg> location: scan_wifi_result_handle: scan result #8 stored: ssid XXXX, channel 64, mac 24:36:da:11:xx:xx
[00:01:24.933,990] <dbg> location: scan_wifi_result_handle: scan result #9 stored: ssid XXXX, channel 64, mac 24:36:da:11:xx:xx
[00:01:24.946,807] <dbg> location: scan_wifi_result_handle: scan result #10 stored: ssid XXXX, channel 6, mac 8a:5a:85:af:xx:xx
[00:01:24.959,442] <dbg> location: scan_wifi_result_handle: scan result #11 stored: ssid XXXX, channel 100, mac 24:36:da:17:xx:xx
[00:01:24.972,167] <dbg> location: scan_wifi_result_handle: scan result #12 stored: ssid XXXX, channel 6, mac 34:21:09:48:xx:xx
[00:01:24.984,649] <dbg> location: scan_wifi_result_handle: scan result #13 stored: ssid XXXX, channel 132, mac 24:36:da:11:xx:xx
[00:01:24.997,619] <dbg> location: scan_wifi_result_handle: scan result #14 stored: ssid XXXX, channel 132, mac 24:36:da:11:xx:xx
[00:01:25.010,284] <dbg> location: scan_wifi_done_handle: Scan request done with 14 Wi-Fi APs

Step 2: Request nRF Cloud Wi-Fi locationing

The nRF9160 will encode the Wi-Fi APs information, including MAC address, SSID, signal strength, and channel, into a JSON file. The JSON file is then sent to nRF Cloud, which will use the data to check the Wi-Fi location database and calculate the device location using a specific algorithm. nRF Cloud will send back the result to the device for a successful request. The result contains information like latitude, longitude, accuracy. See the nRF Cloud REST API Documentation for the API request and response formats.

[00:01:25.028,015] <dbg> location: cloud_service_location_get: Cloud service location parameters:
[00:01:25.037,170] <dbg> location: cloud_service_location_get:   Service: 0
[00:01:25.044,494] <dbg> location: cloud_service_location_get:   Timeout: 25060ms
[00:01:25.052,337] <dbg> location: cloud_service_nrf_pos_get: Sending positioning request (REST)
[00:01:25.160,125] <dbg> nrf_cloud_codec_internal: nrf_cloud_location_req_json_encode: JSON: {"wifi":{"accessPoints":[{"macAddress":"24:36:da:16:xx:xx","ssid":"XXXX","signalStrength":-41,"channel":108},{"macAddress":"24:36:da:16:xx:xx","ssid":"XXXX","signalStrength":-41,"channel":108},{"macAddress":"24:36:da:16:xx:xx","ssid":"XXXX","signalStrength":-48,"channel":11},{"macAddress":"24:36:da:16:xx:xx","ssid":"XXXX","signalStrength":-49,"channel":11},{"macAddress":"24:36:da:11:xx:xx","ssid":"XXXX","signalStrength":-63,"channel":1},{"macAddress":"24:36:da:17:xx:xx","ssid":"XXXX","signalStrength":-70,"channel":1},{"macAddress":"24:36:da:17:xx:xx","ssid":"XXXX","signalStrength":-70,"channel":1},{"macAddress":"24:36:da:11:xx:xx","ssid":"XXXX","signalStrength":-72,"channel":64},{"macAddress":"24:36:da:11:xx:xx","ssid":"XXXX","signalStrength":-72,"channel":64},{"macAddress":"8a:5a:85:af:xx:xx","ssid":"XXXX","signalStrength":-73,"channel":6},{"macAddress":"24:36:da:17:xx:xx","ssid":"XXXX","signalStrength":-75,"channel":100},{"macAddress":"34:21:09:48:xx:xx","ssid":"XXXX","signalStrength":-76,"channel":6},{"macAddress":"24:36:da:11:xx:xx","ssid":"XXXX","signalStrength":-85,"channel":132},{"macAddress":"24:36:da:11:xx:xx","ssid":"XXXX","signalStrength":-85,"channel":132}]}}
[00:01:25.283,142] <dbg> rest_client: rest_client_request: Requesting destination HOST: api.nrfcloud.com at port 443, URL: /v1/location/ground-fix
[00:01:25.296,966] <dbg> rest_client: rest_client_request: Payload: {"wifi":{"accessPoints":[{"macAddress":"24:36:da:16:xx:xx","ssid":"XXXX","signalStrength":-41,"channel":108},{"macAddress":"24:36:da:16:xx:xx","ssid":"XXXX","signalStrength":-41,"channel":108},{"macAddress":"24:36:da:16:xx:xx","ssid":"XXXX","signalStrength":-48,"channel":11},{"macAddress":"24:36:da:16:xx:xx","ssid":"XXXX","signalStrength":-49,"channel":11},{"macAddress":"24:36:da:11:xx:xx","ssid":"XXXX","signalStrength":-63,"channel":1},{"macAddress":"24:36:da:17:xx:xx","ssid":"XXXX","signalStrength":-70,"channel":1},{"macAddress":"24:36:da:17:xx:xx","ssid":"XXXX","signalStrength":-70,"channel":1},{"macAddress":"24:36:da:11:xx:xx","ssid":"XXXX","signalStrength":-72,"channel":64},{"macAddress":"24:36:da:11:xx:xx","ssid":"XXXX","signalStrength":-72,"channel":64},{"macAddress":"8a:5a:85:af:xx:xx","ssid":"XXXX","signalStrength":-73,"channel":6},{"macAddress":"24:36:da:17:xx:xx","ssid":"XXXX","signalStrength":-75,"channel":100},{"macAddress":"34:21:09:48:xx:xx","ssid":"XXXX","signalStrength":-76,"channel":6},{"macAddress":"24:36:da:11:xx:xx","ssid":"XXXX","signalStrength":-85,"channel":132},{"macAddress":"24:36:da:11:xx:xx","ssid":"XXXX","signalStrength":-85,"channel":132}]}}[00:01:25.417,358] <dbg> rest_client: rest_client_sckt_connect: Doing getaddrinfo() with connect addr api.nrfcloud.com port 443
[00:01:25.435,699] <dbg> rest_client: rest_client_sckt_connect: getaddrinfo() 52.70.xxx.xxx
[00:01:25.445,892] <dbg> rest_client: rest_client_sckt_connect: Connecting to api.nrfcloud.com port 443
+CSCON: 1
[00:01:26.902,130] <dbg> rest_client: rest_client_http_response_cb: HTTP: All data received (content/total: 79/328), status: 200 OK
[00:01:26.914,245] <dbg> rest_client: rest_client_request: API call response len: http status: 200, 79 bytes
[00:01:26.926,025] <dbg> location: location_core_event_cb_fn: Location acquired successfully:
[00:01:26.934,844] <dbg> location: location_core_event_cb_fn:   method: Wi-Fi (3)
[00:01:26.942,901] <dbg> location: location_core_event_cb_fn:   latitude: 59.920980
[00:01:26.950,988] <dbg> location: location_core_event_cb_fn:   longitude: 10.689317
[00:01:26.959,136] <dbg> location: location_core_event_cb_fn:   accuracy: 15.0 m
[00:01:26.966,857] <dbg> location: location_core_event_cb_fn:   date: 2023-08-31
[00:01:26.974,609] <dbg> location: location_core_event_cb_fn:   time: 13:49:40.035 UTC
[00:01:26.982,879] <dbg> location: location_core_event_cb_fn:   Google maps URL: https://maps.google.com/?q=59.920980,10.689317
Got location:
  method: Wi-Fi
  latitude: 59.920980
  longitude: 10.689317
  accuracy: 15.0 m
  date: 2023-08-31
  time: 13:49:40.035 UTC
  Google maps URL: https://maps.google.com/?q=59.920980,10.689317

Step 3: Device goes to sleep

When the RRC Inactivity Timer expires, the nRF9160 will enter RRC Idle state. I have set the active timer (T3324) to 0 (CONFIG_LTE_PSM_REQ_RAT="00000000") to help the device enter PSM immediately to save power once the device enters the RRC Idle state. The RRC Inactivity Timer is configured by MNOs (here it is 5 seconds for Telenor Norway). If the fast release feature (AS-RAI) is supported by the MNO, the device can enter RRC Idle immediately by sending RAI to inform the base station to release the radio connection between them. This will further reduce the total power consumption. You can learn more about RAI from the blog Maximizing battery lifetime in cellular IoT: An analysis of eDRX, PSM, and AS-RAI.

Comparing the location services in practice

The location services available in nRF Cloud have different performance when it comes to position accuracy and power consumption, and it is up to you to select the one best suited for your application needs.

Figure: Position accuracy and power consumption on location services

Power consumption: GNSS location service consumes around 50mA during the fixing search process, and the search without assistance can last from tens of seconds to several minutes. Even with A-GPS data assistants, the time-to-first-fix (TTFF) will still take several seconds. My previous blog Up to 4x battery life: The benefits of assisted GPS in asset tracking shows more measurement data on this topic. Wi-Fi and cellular based location services consume much less power since they collect surrounding data, either from Wi-Fi access points or cellular base stations, then send the collected data to nRF Cloud for device locationing. The processes are purely Internet communication, so they consume significantly less power than GNSS operations.
Accuracy: When it comes to accuracy, however, it is the opposite. GNSS will provide higher position accuracy than the other two, and Wi-Fi can give better accuracy than cellular location service. 

Power consumption and accuracy are the most important considerations when choosing the right location service for an application, but you should also consider things like indoor/outdoor environment usage, Wi-Fi and cellular coverage to choose the best one or switch between them for location services. The table below presents the performance of the different nRF Cloud location services, measured against factors like accuracy, latency and power consumption.
Wi-Fi GNSS Single-cell Multi-cell
Accuracy (optimal) 5-15m 5-10m 1000m 200-300m
Latency Seconds Seconds <1s <1s
Power consumption Moderate Very high Low Low+
Read distance 150m Anywhere 35km 35km
Use-case Which room Very accurate outdoor Very rough outdoor Which building

The chart has a table listing the optimal accuracy of different location services; the actual accuracy will vary in practice. For example, GNSS location service accuracy in a city surrounded by tall buildings can get poorer accuracy than Wi-Fi because of reflections and buildings that can interfere with the GNSS signal. It is important to choose the correct location service methods according to application needs and evaluate the actual position accuracy and power consumption with measurements.

To help you understand how to do this evaluation in practice, we have taken power consumption measurements when using different locationing methods. The measurements are still based on the nRF Connect SDK sample Cellular: Location. The test is on the roof of the Nordic Semiconductor Oslo office building.

Cellular-based location service

The following new function location_cellular_get() is defined to test the cellular location service.

/**
 * @brief Retrieve location with cellular location service.
 */
static void location_cellular_get(void)
{
        int err;
        struct location_config config;
        enum location_method methods[] = {LOCATION_METHOD_CELLULAR};

        location_config_defaults_set(&config, ARRAY_SIZE(methods), methods);

        printk("Requesting cellular location...\n");

        err = location_request(&config);
        if (err) {
                printk("Requesting location failed, error: %d\n", err);
                return;
        }
        location_event_wait();
}

The power consumption results of cellular-based location services look quite similar to a Wi-Fi location service. The following picture shows the PPK2 measurement of a cellular location service.

Here is the log output from the test. The total power consumption of this cellular location service request was 122.48 mC, and the accuracy was 1708.0 m.

Requesting cellular location...
Got location:
  method: Cellular
  latitude: 59.920624
  longitude: 10.689719
  accuracy: 1708.0 m
  date: 2023-09-04
  time: 12:47:23.399 UTC
  Google maps URL: https://maps.google.com/?q=59.920624,10.689719

Wi-Fi-based location service

The following captures use the location_wifi_get function to request Wi-Fi location service. The total power consumption for this event was 125.85mC, and the log showed 30.0m accuracy.

Got location:
  method: Wi-Fi
  latitude: 59.919015
  longitude: 10.688577
  accuracy: 30.0 m
  date: 2023-09-04
  time: 12:47:51.753 UTC
  Google maps URL: https://maps.google.com/?q=59.919015,10.688577

GNSS-based location service using A-GPS

The original function location_gnss_low_accuracy_get() in the sample is used for the GNSS location service request, and A-GPS assistance is enabled. Low accuracy mode lets GNSS demonstrate a looser acceptance criterion for a fix to conserve power consumption. There are three accuracy mode for GNSS location service: low, normal, and high. The higher accuracy, the more power the device will consume, but we know from experience that all of them will consume more power than Wi-Fi and cellular location services. In the GNSS location service measurement, we expect even the GNSS low accuracy mode will provide better location accuracy than Wi-Fi and cellular location services, so the low accuracy mode is used in this measurement and we can see the "closest" power consumption difference of GNSS with other location services."We expect even the GNSS low accuracy mode will provide better location accuracy than other methods, but it will consume more power, so the low accuracy mode is used in this measurement. The result did prove this assumption. A-GPS data is only requested one time to speed up TTFF. Note that the A-GPS request is not needed as long as the almanac and ephemeris data in the device are still valid.

The PPK2 measurement shows the total charge for this event is 316.71mC without the A-GPS data request process, and the log shows 16.9m accuracy.

Got location:
  method: GNSS
  latitude: 59.920928
  longitude: 10.689040
  accuracy: 16.9 m
  date: 2023-09-04
  time: 12:48:34.586 UTC
  Google maps URL: https://maps.google.com/?q=59.920928,10.689040

Results

Below you can see the results from our power consumption and accuracy measurements, taken from the roof of the Nordic Semiconductor office in Oslo. 

nRF Cloud location service

Power consumption (mC)

Accuracy (m)

Cellular

122.48

1708.0

Wi-Fi

125.85

30.0

GNSS (low accuracy with A-GPS)

316.71 (A-GPS data request process is not included)

16.9

As we can see, these measurements properly reflect what was presented in the figure "Position accuracy and power consumption on location services". In general condition, Wi-Fi is a great location service method that captures great accuracy with a low power consumption.

Note that the chart has a table listing the optimal accuracy of different location services; the actual accuracy will vary in practice. For example, GNSS location service accuracy in a city surrounded by tall buildings can get poorer accuracy than Wi-Fi because of reflections and buildings that can interfere with the GNSS signal. It is important to choose the correct location service methods according to application needs and evaluate the actual position accuracy and power consumption with measurements.

Useful references

Parents
No Data
Comment
  • $core_v2_ui.GetResizedImageHtml($comment.User.AvatarUrl, 44, 44, "%{border='0px', alt=$comment.User.DisplayName, ResizeMethod='ZoomAndCrop'}")
    $core_v2_ui.UserPresence($comment.User.Id) $comment.User.DisplayName
    This comment is under review.
Children
No Data