Architecture & Functioning
🔤 Acronyms? See the Glossary
👤 System Integrator
Definition and Architecture​
A flow is one of the most important resources in Acklio IPCore. It defines how a complete transaction is presented and processed from the LPWAN connectors (LNS, NB-IoT, Sigfox, among others) to the IP connection and destination network.
A flow can be defined as a scenario linking together one or more LPWAN connector(s) (the "sources"), one device and one network connection. There is no upper limit to the number of flows. Each flow has its own context that depends on the User's IP Network of the destination services.
- A flow is associated to one source and one IP network.
- Inside a flow, one or several device profiles can be created.
- Each device profile is associated with one SCHC template.
- A device can be provisioned only on one device profile.
IP Network​
See How to configure the IP Network for detailed information and screenshots.
The IP Network is the network to which the IoT devices will all belong. IP Networks can be either IPV4 or IPV6 and are defined through a prefix and prefix length. Associated with the IP Network, a user install a dedicated VPN agent to interconnect the IPNetwork of devices with its internal network where applications are hosted.
An organization can have multiple IP Networks (however administrators can limit them).
IPCore is able to auto-discover devices and automatically allocate them an IP address from the IP Network pool (DHCP like features). The association of a device with an IP address is stored in an internal registry that can be retrieved through an API.
The alternative is to allocate to the devices a static IP address either manually or through a bulk load of a configuration file (in this case, IPCore can support a bulk of up to 100K devices at the same time).
For LoRaWAN devices, IPCore also supports IP address allocation based on AppSKey derivation according to the RFC 9011 specification.
Source​
See How to specify the Source for detailed information and screenshots.
For a given flow, you need to configure the interface that will allow to retrieve/push data to the LPWAN networks.
A source is actually a bidirectionnal connector allowing uplink and downlink exchanges between the network server and Acklio IPCore.
The connector architecture of Acklio IPCore allows to manage different sources, that is to say to mix different types of LPWAN Network Servers using any type of LPWAN technologies.
Supported LPWAN networks are: Sigfox, Objenious, Orange Live Objects, The Thing Network Actility Thingpark, IOT Creators (DT), Senet, Orbiwize, Everynet, … and it offers also generic connectors with other type of Networks through HTTPS callbacks or simple IP/UDP tunnel.
In further versions, SCEF T8 interface will be available for non-IP NB IoT devices. For specific sources, feel free to contact us to discuss the compliance.
SCHC Template​
See How to configure the SCHC Template for detailed information and screenshots.
A SCHC template contains predefined translation rules that will be applied to legacy devices when using Acklio IPCore without Acklio FullSDK, or predefined rules for SDK enabled devices.
Rules can either be generic with parameters to overload when defining a flow, or fully predefined. They are available for both IPv4 or IPv6 networks.
Typical parameters that can be overloaded are:
- The IP address (dynamic or static) of the device,
- The IP address of the application
- The UDP ports
- The URI path for CoAP
- CSAP or SSAP values for DLMS UDP wrapper
To enhance security and integration, Acklio IPCore allows to translate binary payloads sent by the device into JSON format.
This functionality uses YOUPI files, based on YANG model description (See Glossary), that are associated with the SCHC template.
YOUPI ensures that no third-party code will be executed since the data model translation is interpreted.
Starting with IPCORE V3, Acklio introduces a feature to compress payloads (i.e. upper transport layers) using SCHC rules. This requires the use of Acklio FullSDK in the device.
Payload compression is done by associating a specific JSON file with the device template.
Devices Profiles & Provisioning​
See How to configure the Device Profile and How to provision the Device for detailed information and screenshots.
Device profiles are inherited from templates to precisely configure the translation behavior for a specific flow context. A device profile is therefore a duplication of a template where some parameters such as CoAP destination URI and IP destination address are overloaded.
Devices are added to the profile either manually, through a bulk load with a CSV configuration file or automatically (through the autodiscovery option).