Skip to main content
Version: 5.0

Demo Purpose

🔤 Acronyms? See the Glossary

DLMS using IP-DTLS over NB-IoT

This fourth use case illustrates an end-to-end communication from a DLMS metering device to a DLMS Head-End System (HES) where the combination IP/UDP/DTLS creates a kind of IoT VPN where data exchange is safe, even if it passes through a public network.

A DTLS server is placed before Acklio IPCore as a security handler that encrypts and decrypts data during uplink and downlink transmissions. And a DTLS layer is incorporated into Acklio FullSDK to manage security for the device. This layer is based on mbedtls library using DTLS v1.2.

At both ends of the communication, an IP tunnel (IP/tun controller) is required to establish a network communication channel between IP and the other protocols and create a Linux interface on the computer.

Acklio FullSDK is embedded into the AT Modem application, actually a Serial LTE Modem (SLM).

Demo Use Case 4

Routing Issues

In this Demo example, in order to avoid routing issues, the combination "DLMS server and tun controller" must be running on a different machine than the combination "VPN agent and HES".

Recommendations

Recommendations

Demo Functioning

This DLMS IP-DTLS example demonstrates how a DLMS HES can securily request values to a DLMS server and get secured responses even if data passes through a public network and transits over NB-IoT.

DTLS IP Use Case

This Demo repository provides a device application (the DLMS server) simulating the DLMS meter and a DLMS client simulating the Head-End System.

An initial handshake is requested by the SLM. The handshake is handled in a transparent way by Acklio FullSDK. See the SCHC DTLS page for detailed information.

The DLMS Client periodically starts sending a series of DLMS requests in order to get information from the device application.

The example demonstrates how Acklio FullSDK allows the device application to exchange IPv6/UDP/DLMS frames with the Head-End System through the use of (nrf 9160) AT commands.

In this example the IPv6, UDP, and DLMS wrapper headers are compressed, limiting over-the-air transmission to the DLMS payload. This represents 56 bytes (40 + 8 + 8) less for each message.

In the case when fragmentation is also necessary, Acklio FullSDK uses the Ack-On-Error mode, as described in the SCHC template configured in Acklio IPCore.

Gurux workflow