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 trough the combination of different source types (GNSS, Wi-Fi and Cellular) that are used to estimate the device position
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.
no need of assistance: the service does not need any type of GNSS aiding (ephemeris, almanac).
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.
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
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.
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
How to generate a RAW snapshots
To estimate a position you need to 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": 10,
"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.
Note: 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": 10,
"RAT": "LTE",
"NetworkCells": [
{
"CellIdentifier": 137788526,
"AreaCode": 14354,
"SignalStrength": -98,
"Code": 201,
"Frequency": 6400,
"IsServingCell": true
},
{
"SignalStrength": -90,
"Code": 393,
"Frequency": 6400
}
]
}
}
Wi-Fi measurementThis 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.
Location estimation
A successful 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"
}
Service access modes
You can get access to CloudLocate function using the Premium Extension available in Data Flow Manager in the Thingstream Portal.
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.
The CloudLocate Premium Extension guide provides the relevant information
Still need help?
If you need more help or have any questions, please send an email to services-support@u-blox.com