CloudLocate getting started
Last update: November 14th, 2023
Introduction
CloudLocate enables seamless location to locate device even in the most challenging environment. The service uses IoT device measurements (GNSS, Wi-Fi and Cellular) to calculate the location in the cloud and deliver it directly to the enterprise.
Benefits
The service provides several benefits:
cloud hybrid positioning: it combines the provided measurement to maximize the position fix rate
fast go-to market: CloudLocate can be used with any hardware, even with a mix of u-blox and third party modules.
flexibility: the same service can be used with all your different platforms that might be equipped with a subset of sources (for example Wi-Fi and Cellular for one platform and GNSS and Cellular for another platform)
data optimization: position can also be calculated using a single source (Cell ID, GNSS, Wi-Fi) for the applications with data constraints.
power autonomy: typically the GNSS consumes from 25% to 50% of the device battery. With CloudLocate, the energy consumption is minimized by delegating power intensive calculations to the cloud. The GNSS is switched on for few second (1 to 10) thus it consumes significantly less power than a standard approach where the GNSS takes at least 30 seconds to fix a position.
secure: CloudLocate use a per-device authentication; optionally you can decide to protect the transmitted raw data with additional TLS protection
no need of assistance: the service does not need any type of GNSS aiding (ephemeris, almanac).
latency reduction: the estimated position reaches your cloud application immediately. Thanks to the Cloud-to-Cloud connection
fast prototyping and sample code: through very few simple configurations you are ready for the field tests. You can leverage the u-blox reference implementation as a baseline.
scalability: once you move to production, you do not need to worry about additional complexity. Device configuration remains the same for all the devices
Basic principles
CloudLocate works in a very simple way. The service supports three types of data measurements:
Cellular scan information: this is the combination of serving cell (to which the device is connected) and the neighbor cells.
Wi-Fi scan information: this is the list of the visible Wi-Fi access points (AP) around the device. The device does not need to connect to these AP, just a fast passive scanning is required.
Raw GNSS measurement: raw measurement is GNSS snapshot, containing the relevant information about the visible satellites, organized in an optimized format. It is automatically generated by the GNSS receiver during acquisition phase in few seconds
The devices gets the above listed data and send them to the service endpoint. The CloudLocate engine, through a sophisticated algorithm, estimates the most accurate position possible based on the input data quality. The estimated position can be sent directly to your cloud application to minimize the energy consumption, or back to the device if needed or even directly to the end user, after additional data manipulation
According to the device design you can decide to send any mix of the listed data, for example:
only Cellular scan, only GNSS raw data, only Wi-Fi scan or
Wi-Fi Scan plus Cellular data or GNSS raw data plus Cellular scan or
all three sources
In this section
Still need help?
If you need more help or have any questions, please send an email to support@thingstream.io
Typical applications
CloudLocate is the most appropriate solution in the asset tracking use cases with energy-constrained devices where it is hard to get a location due to tough environmental conditions.
Container Tracking
Livestock tracking
Industrial tools tracking
Small asset/parcel tracking
Service access modes
You can access to the service using the most convenient option for your existing architecture:
Device to Service: The device communicates with the service directly over the MQTT protocol and receives the position back.
Service to Service: The device communicates with your server which, using your preferred protocol and eventually aggregating location data with other telemetry data. Your server forwards the position request using REST APIs to our service endpoint. The position is sent back to the customer enterprise server.
Location in Cloud: The device sends request directly to our service. The service calculates the position and push it to the customer's enterprise server. The customer can also get location back on the device if needed.
If you are using one of u-blox IoT Communication-as-a-Service solution like MQTT Anywhere, MQTT Now, MQTT Here or MQTT Flex, the most efficient way to leverage CloudLocate is using the premium extension.
With Data Flow Manager you can build your own logic or manipulate data, by creating a flow made up by multiple nodes (premium extension), each of them implementing a basic functionality
The Flow Editor provides a simple drag and drop interface where you can quickly build powerful flows to work with payloads published by your Things, and get that data out to wherever you need it.
How to generate a RAW snapshots
Regardless which service interface you plan to use (Service to Service, Device to Service, Location in Cloud), you can generate the the RAW snapshot (also named service payload) containing the information for location in the same way.
A typical example of a payload containing all the three sources is reported here below.
Note: When only GNSS is needed there is a more optimized format for low-bandwidth networks that allows to minimize the payload size from 12 to 50 bytes.
{
"CellMeasurements": {
"HomeMCC": 234,
"HomeMNC": 50,
"RAT": "LTE",
"NetworkCells": [
{
"CellIdentifier": 137788526,
"AreaCode": 14354,
"SignalStrength": -98,
"Code": 201,
"Frequency": 6400,
"IsServingCell": true
},
{
"SignalStrength": -90,
"Code": 393,
"Frequency": 6400
}
]
},
"WiFiMeasurements": [
{
"BSSID": "9002184725b4",
"SignalStrength": -69,
"Channel": 1
},
{
"BSSID": "04a222198f15",
"SignalStrength": -69,
"Channel": 1
}
],
"GNSSMeasurements": {
"Payload": "tWIChjIAG/M7CcimDqBmvpr+A9pGYVEPdxhiyIqPToNAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAyAA=="
}
}
In the next sections we will look in detail at each these data. Please remind that you can use any combination of the RAW measurements or just a single one.
Cellular measurement
Once the module have established the connection to the network, you need to retrieve the relevant cells information using the appropriate AT commands, that are vendor dependent:
Network Information: Mobile Country code (MCC), Mobile Network code (MNC), Radio Access Technology (RAT)
Serving cell Information: Cell ID (logical identifier of the cell), Code (or PCI, Physical Cell Identifier), Signal Strength, Frequency
Neighbor cells information: Signal strength, Code, Frequency
Notes
According to module vendor the output from the module can be in Hex or integer, therefore pay attention if a conversion is required, as defined in the documentation
Signal strength might be reported in multiple ways. Some vendors express it according to 3GPP specifications using a positive index, therefore when submitting the API it has to be converted in a negative number (in dBm) by subtracting a fixed value (vendor dependent) to the reported index
The Cellular RAW data guide illustrates in details which are the relevant AT Commands to get the information form the modem, and how to manipulate the output in order to be compliant to CloudLocate specification
A payload containing only cellular scan looks like the following one:
{
"RequestId": "82cb34c9-88c9",
"CellMeasurements": {
"HomeMCC": 234,
"HomeMNC": 50,
"RAT": "LTE",
"NetworkCells": [
{
"CellIdentifier": 137788526,
"AreaCode": 14354,
"SignalStrength": -98,
"Code": 201,
"Frequency": 6400,
"IsServingCell": true
},
{
"SignalStrength": -90,
"Code": 393,
"Frequency": 6400
}
]
}
Wi-Fi measurement
This is the list of Wi-Fi access points (AP) visible to the device in a given location. For privacy reason, you shall send a minimum of 2 access points, providing the three mandatory parameters for each AP:
BSSID: it's the identifier of the AP, made up of 6 octets without any separator (for example "9112684715b4")
SignalStrength: it's the received signal level. It might be reported in different ways according to the module vendor. The API requires a negative value (dBm).
Channel: it's the WiFi channel used by the AP
The Wi-Fi RAW data guide illustrates in details which are the relevant AT Commands to get the information form the Wi-Fi modem, and how to manipulate the output in order to be compliant to CloudLocate specification.
A typical payload containing only Wi-Fi Raw measurements looks like the following one (2 Access points)
{
"RequestId": "82cb34c9-88c9",
"WiFiMeasurements": [
{
"BSSID": "9002184725b4",
"SignalStrength": -69,
"Channel": 1
},
{
"BSSID": "04a222198f15",
"SignalStrength": -69,
"Channel": 1
}
]
}
GNSS raw measurement
A GNSS raw measurement consists in a snapshot of the visible satellites, that includes the relevant values to estimate the position. This snapshot is provided in output by the GNSS receiver as a UBX message generally few seconds (3-10 s) after the cold start, and is processed by the cloud service to estimate a position
The main advantages are:
minimized energy consumption because the receiver on-time is limited to 3-10 seconds instead of the typical use case of 30-40 seconds. This also allows a faster position fix.
aiding data are not required, thus making simpler the device application and removing dependency from the availability of the connectivity.
The snapshot it's a binary message, 20-50 bytes long, and it can be added as it is (just a base64 encoding is required) to the CloudLocate payload.
An example here below reports a payload containing only the GNSS raw measurement
{
"RequestId": "82cb34c9-88c9",
"GNSSMeasurements":{
"Payload": "tWIChjIAG/M7CcimDqBmvpr+A9pGYVEPdxhiyIqPToNAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AyAA==",
"DateTime": "2023-04-05T12:50:16"
}
}
In addition, there is also the DateTime parameter that is required only whenever the snapshot is sent to the cloud service with a delay greater than 60 seconds from when it has been generated by the receiver. This allow you also to save data in the device and do a postprocessing at a later time.
To learn how to generate this message using a u-blox GNSS module (M10 generation), please refer GNSS raw measurement guide.
Request identifier
In all the examples below we reported also the optional parameter RequestId. This value will be returned in the service response jointly to the estimated position. It's an optional alphanumeric string that can be used to indicate a device identifier and/or request identifier. The usage of this parameter is mainly useful when:
using the location in the cloud option, to recognize the device/request on the cloud application
doing troubleshooting or ask to u-blox to analyze a request service side
How to estimate a position
Prerequisites
To use the service you need
at least one of the following hardware (depending which data source you want to use):
a u-blox GNSS receiver (generation M8 or M9 or M10) and/or
a Wi-Fi module and/or (u-blox or third-party) and/or
a Cellular module (u-blox or third-party)
the access to u-blox Thingstream service delivery platform, that provides the technical information to access to the service (credentials and service endpoints) and the billing information and the monitoring capabilities
Depending on which service access mode you selected, the tools/code to send the service payload to CloudLocate endpoint:
Service to Service: a tool/script to send REST APIs
Device to Service or Location in the cloud: an MQTT client
In case you are using the u-blox MQTT Anywhere communication service, you can access to the service through a Node in the Data Flow Manager.
u-blox service platform sign-up
To access CloudLocate, you first need to sign-up/sign-in in the u-blox Thingstream service delivery platform that is the service management console and allows to manage the entire suite of u-blox services.
Sign-up is free, quick and easy. Just go to the portal and register for free with your company information. If you already have a Thingstream domain, you do not need to register again.
Obtain the service credentials
Service to Service
The Service to Service access requires a credential (username & password) to authenticate the API. These credential are fleet based. The platform also allow you to:
modify the pricing plan
deactivate/ reactivate the access
monitor the usage of the service
and look at the the events
Detailed information are available in the CloudLocate Service to Service guide
Device to Service
Device to service access implies that the device sends the service payload directly to the service endpoint without any transit though a cloud application. For this reason, the credentials (username and password) are device based and data shall be transmitted using MQTT protocol.
The credential provisioning in the device can leverage a Zero Touch Provisioning solution that allows you to obtain in a secure manner the device credentials and be immediately up and running.
Detailed information are available in the CloudLocate Device to Service guide
Premium Extension (Flow)
If you are using one of u-blox IoT Communication-as-a-Service solution like MQTT Anywhere, MQTT Now, MQTT Here or MQTT Flex please refer to this guide to know how to use CloudLocate service leveraging the flows
Location estimation
A succesfull location response provides the position estimation as long as the date and time of the request, a copy of the RequestId if provided in input, and a LocationSource that indicates which source (Cellular, Wi-Fi or GNSS) have been used for the provided estimation.
{
"Location": {
"Lat": 51.496268,
"Lon": -0.0949408,
"Unc68": 27.0
},
"DateTime": "2023-09-14T13:02:01",
"RequestId": "82cb34c9-88c9",
"LocationSource": "WiFi"
}
It's important to note that the service implements an Hybrid cloud positioning, to maximize the fix rate and provide always the best possible position.