When data is sent from device to KPN Things
KPN Things Data Management is a data processing platform that enables you to connect all your KPN Things devices to all supported destinations through one standard way of data processing. This principle is visualized in the diagram below:
Read more on device support:
KPN Things Data Management supports multiple forms of connectivity to receive data from devices. When you have a KPN Things device it is already configured to work with KPN Things Data Management.
Read more on connectivity support here:
During the optional decoding phase the device specific data protocol is transformed to the universal language of SenML. This is called decoding. Decoding for KPN Things devices and custom devices that use the KPN Things client libraries is taken care of automatically. Therefor there is automatic compatibility with the enrichment phase.
In future releases KPN will introduce data enrichment functionality in KPN Things Data Management.
After processing your data will be forwarded to one or more Destinations you have configured.
Explaining the data model of the platform.
Green bordered blocks are objects provided to you.
Green filled blocks are objects you can create and manage.
Grey bordered blocks are objects globally managed by the system.
If you have an account on KPN Things Data Management, it belongs to a Customer account. All main objects in the KPN Things Data Management belong to a Customer: Projects, Devices, Destination and Network subscriptions.
A Network subscription contains information for network types for a specific client. Learn more about connectivity types.
Each Project defines a solution you buy or build in KPN Things. Learn more about Projects.
With a Flow you link one or more devices to one or more plugs. So, if data is received from a device in a device group, its data will be forwarded to the plugs that are in the same device group.
A project has one or multiple activated decoders and encoders. These decoders prescribe which decoders should be used when data is received by a device that is in a device group that belongs to this project. Learn more about Flows.
A Device represents a single physical device that can send data to the platform. When creating a device you tell the system the device specification it belongs to.
A Device specification has one or multiple supported network types. For all our supported device types, go to Devices.
For a device, you can create a Network info for each supported network type of the given device specification.
A Destination allows you to forward the data from your devices to an external system. For detailed information go to Destinations.
The KPN Things Platform is the bridge between IoT Devices and IoT Applications. It offers a unified way of connecting Devices at the one side, and applications at the other side, making Devices and applications completely interchangeable in every IoT solution that uses KPN Things.
Devices can communicate with the platform using one of our networks, LoRa or M2M (2G/3G/4G/LTE-M), or a Device using another network can get its data to and from KPN Things over the Internet.
Communication from your Device is called uplink communication. When data or instructions are sent to your Device, it is called downlink communication. The communication within KPN Things Platform uses the SenML data protocol. Devices using other languages can be translated from and to SenML using encoders and decoders.
KPN Things will connect to your application through a dedicated connection layer. To connect your application to KPN Things you can use one of the available Destination types. We support connecting plain HTTPS endpoints to KPN Things, but if you are developing in Microsoft Azure, you can connect directly to the Azure Event Hub.
The Destination types that support 'management' connect on a platform level and can also manage objects in the application. The Cumulocity destination for instance will create Device objects in the Cumulocity tenant for each Device that KPN Things sends data of.
The KPN Things Portal is the web application through which you can manage and monitor almost all parts of the KPN Things solutions. You can manage each part of the KPN Things solution, from Device to Destination, to bring your IoT data from the real world to the digital world. You are also able to use KPN Things API's directly to manage your IoT solutions.
The KPN Things Portal is the visual interface with which you configure your solutions on the KPN Things Data Management platform.
To manage your IoT solution you use Flows and in a Flow you link Devices, configure Data Processing and set up Destinations together. See how these components relate to each other in the Management Data model. Since network configuration, or Connectivity, is part of the Device in KPN Things, a Flow expresses the complete way how IoT data should be received, processed and forwarded, from the Device to the Destination and vice versa.
When data is sent to the device
All downlink communication is requested on and managed by the Actuator API. Optionally a Destination can request and manage downlink communication as well. See Destination types to learn which destinations can support downlink communication.
After a downlink is requested on the Actuator API it is encoded. Meaning the downlink is translated to a message the device will understand. After encoding the downlink is send over the selected network to your device.
The network (and the device) will report feedback about the delivery of the downlink to the Actuator API. This information can be retrieved by the application, or the Things Connector fetches this information into your system.
Using the KPN Things Portal, you can request downlinks, and check their progress. Learn how you can send a downlink in the KPN Things Portal or read getting started on sending a downlink to a LoRa Device via Things Portal.
Since December 2020 it is also possible to directly call the Actuator API. Head on over to the API access documentation for more information!
Using our encoders the downlink request is translated to a device specific message. All available encoders are specified per device type.
Currently the following networks are supported for downlink communication:
LoRa downlink
HTTP response downlink for M2M devices
HTTP response downlink for Internet-connected devices
Some Destination types also support sending downlinks.
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 .
We consider two different types of determining the location of your Device:
: really determining the absolute location of your Device on the world.
: 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.
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
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)
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.
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.
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
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
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.
