IoT Gateways with LwM2M

Building an IoT gateway with analogue sensors

One of my business contacts has been producing analogue sensors for decades. These were later upgraded to wireless links on 868 MHz, saving the need to lay cables. In the meantime, everyone is talking about the Internet of Things and "Could". Until now, the data from the sensors has been transmitted via a proprietary wireless protocol to a proprietary gateway. From there, the data is transferred to a proprietary cloud solution. Technically, everything works, but the maintenance of the firmware in the gateway and the maintenance of the software in the cloud requires in-house resources. The idea is to optimise this.

Exchange for a classic gateway with mobile radio and LwM2M protocol

My proposal is to replace the in-house gateway with a classic mobile radio gateway with several MiniPCie or M.2 slots. The M.2 slots open the door to 5G. Some end customers already insist on 5G, although 4G with LTE Cat 1 is sufficient. The core of the gateway is an embedded Linux with LwM2M protocol stack. The stack of LwM2M uses PPP, IP, UDP or CoAP under Linux. LwM2M can use 2G, 3G, 4G (LTE, LTE-M, NB-IoT) or 5G NR. The cellular modem can easily be swapped for a Wi-Fi modem or even a satellite modem. The LwM2M stack can control almost any modem with PPP under Linux.

The second slot is used for a MiniPCIe card with the 868 MHz radio module. If other radio modules, modulation types or other frequencies are required later, this is done by replacing the MiniPCIe card. The concept with the standard slots with MiniPCIe and M.2 makes the gateway modular and future-proof. Even the exchange of the gateway for another one with embedded Linux is possible.

Advantages of the LwM2M protocol for the sensor gateway

MQTT, CoAP and HTTP are only transport protocols. All three transport protocols and transport data from A to B. CoAP has the smallest overhead. LwM2M uses all three transport protocols. The preferred protocol is CoAP because CoAP based on UDP has the lowest energy consumption. For the sensor gateway with permanent voltage, energy consumption is not so important. However, LwM2M was specified for microcontrollers with, for example, FreeRTOS. It needs little memory and it should save energy. The device with a small MCU or with embedded Linux have in common that you have to manage them. LwM2M is a protocol above the three transport protocols mentioned. For some of the functions, even an SMS or LoRaWAN is sufficient.

Features of LwM2M

Secure bootstrapping

There is a secure login of the gateway with the required cryptographic keys/certificates to the server in the LwM2M mechanisms.

Remote management

There are functions to configure the sensor gateway.

Device management

Devices can be grouped into end users and again into sites within end users. The gateway manufacturer can see all gateways. The customer only his own devices.

Firmware update

Secure and efficient Firmware-Over-the-Air-Updates (FOTA) is already part of the stack.

Fault management

Device faults are reported by the gateway via push message.

Reporting

The gateway can report changes to its current status. Or the server can query the status and configuration settings.

Example of the gateway with two analogue temperature sensors

Device Object and Connectivity Monitoring Object in the graphic are both mandatory protocols of each device under LwM2M. The serial number of the device, serial number of the SIM card, status of the mobile network, which networks are available and much more are standardised and the LwM2M server can query this. The devices can also report it periodically on their own or report it when the RSSI level becomes critical. Since these objects are specified, the IoT developer no longer has to develop them.

Temperature and many other measured variables are also specified in standardised objects. If an object is missing, you can define your own. To do this, you only have to tell the LwM2M server the object ID and the structure of the object once.

In our example, own objects are not necessary. The LwM2M server can send the sensor gateway a request as to what objects it is capable of. The answer is then object ID 3, 4 and twice 3303. 3303 stands for the object temperature with the value and the unit (Celsius or Kelvin). If 10 sensors were connected to the gateway, the gateway would answer with ten times 3303. If it were a mixture of temperature and pressure sensors and other measured variables, then these would appear with their object ID. If you want to manage the serial number of the sensor in the object in addition to the temperature, then you define your own object. If the sensor measures temperature and pressure or other measured variables at the same time, then you also define your own object.

The LwM2M protocol contains everything that the IoT developer needs for his device or gateway. You can find many LTE/Wifi gateways under Linux there, because there is an LwM2M stack for Linux. For the LwM2M server, the sensor gateway is an LwM2M device with mandatory objects and other objects. The LwM2M server does not know that the objects for temperature are filled by analogue sensors with 868 MHz radio. Nor does it need to know this, because in the end it only manages standardised or customer-specific objects.

The secure login, logout, firmware update-Over the Air can all be programmed and maintained on top of CoAP or MQTT itself. Man-months of work are followed by years of software maintenance. Or you can take the inexpensive route and use the ready-made LwM2M protocol, to which hundreds of engineers have contributed their ideas from LwM2M V1.0 to V1.2.

Structure of an IoT gateway with NeoMesh modules from NeoCortec

In terms of data, there is no difference between the gateway described above and the analogue sensors with star network and a Meshnet with NeoCortec or other Meshnet protocol. The sensors generate data and pass it on via radio link. The IoT gateway accepts the data and manages them in LwM2M objects. These objects are monitored by the firmware in the gateway and an alarm is triggered if the limits are exceeded. If the limit data is not exceeded, the data is stored in the gateway and transferred to the cloud server once a day.

In this case, too, the LwM2M stack takes care of the secure login, logout, firmware update over the air and much more. The IoT developer can concentrate on the application and the LwM2M stack takes care of the necessary standard tasks. This saves a lot of time and money.

I hope I was able to give a few suggestions with these two examples. You can get the LwM2M test account from me for free. Just send me an email to Harald.naumann (at) Crout.eu or harald.naumann (at) lte-modem.com. Enquiries about NeoMesh from NeoCortec, other radio technology or antennas are as always welcome. For a short, inexpensive consulting on setting up your new IoT device, feel free to contact me.

Imprint

• Harald Naumann, Ludwig-Kaufholz-Weg 4, 31535 Neustadt, Germany
• Contact: harald.naumann (at) lte-modem.com, Phone: +49-5032 801 9985, Mobile:+49-152-33877687