Location data

One of the main use cases in the Internet of Things is tracking of assets. Therefore KPN Things has location data at the core of its design, especially if you take into account the wide variety of tracking hardware we sell.

We consider two different types of determining the location of your Device:

• Localization: really determining the absolute location of your Device on the world.

• Detection: detecting the presence of your Device with an anchor in the world which has a known location. With this you can safely say your Device is close to the anchor.

Localization

Using multiple measurements in a single domain to try to approximate the location of the device.

The following measurement values are outputted by KPN Things:

• latitude

• longitude

• radius (if available)

• source

GPS

The device determines location using GPS. An implementation works for a given device and decoder.

• Device: Should have a GPS module and send GPS location.

• Decoder: A decoder for each device type that sends GPS data (unless a Things protocol is used)

LoRa Geolocation

The LoRa network determines the approximate location of the device using three or more fine timestamps calculated by the gateways. An implementation works for all LoRa devices.

• Network: Should be KPN LoRa with a geo-enabled connectivity plan

• Decoder: LoRa Geolocation decoder should be enabled.

Wifi localization

There should be WiFi infrastructure, dense enough for a device to pick up multiple access points. A device should scan for available WiFi access points and send their MAC-address and received signal strength to Things DM. Things DM should then decode the payload whereafter an external service can be called to resolve the measurements to a latitude and longitude.

• Device: Device should be able to scan for WiFi access points

• Decoder: A decoder for each device type that scans for WiFi access points (unless a Things protocol is used)

• Processing: A WiFi Localization processor should translate incoming WiFi MAC+RSSI measurements to a latitude, longitude and radius using an external service.

Detection

Trying to detect another identifiable object with a known location and using the location of that object as approximate location of the device.

• detectedBeacon

• source

LoRa On Premises Gateway detection

The LoRa network forwards the identifier of the best receiving gateway. Using the user-administrated location of this gateway the general location of the device is determined.

• Network: Should be KPN LoRa.

• Decoder: Metadata embedded in the DevEUI_uplink message from Thingpark should be accepted as information to be processed in Things DM.

• Processing: One LoRa Metadata decoder for location detection using LoRa Gateway ID

Bluetooth beaconing

There should be managed infrastructure of Bluetooth beacons that transmit their identifier in a known manner. The locations of these beacons should be administrated in an (out-of-scope) application. There should be devices being able to detect the beacon and send the beacon identifier to Things.

• Device: There should be a beacon device transmitting a Bluetooth beacon. There should be another device picking up the beacon and sending its identifier to Things.

• Decoder: A decoder for each device type that sends a bluetooth beacon ID (unless a Things protocol is used)

• Processing: trancelate beacon to coordinates.