This article compares two approaches to interfacing an LTE-M (Cat-M1) modem. The article was written by Altus Technologies, a Canadian manufacturer of cold chain monitoring and other IoT solutions.

The aim of this project was for Altus Technologies to develop a wireless temperature sensor that sends data over an LTE-M (Cat-M1) network and measure its performance characteristics as compared to a LoRaWan based design.

The current architecture of a LoRa based temperature sensor is described in Figure-1.

The STM32L03X MCU has the logic to read temperature periodically or based on user input. The sampled values are sent to the LoRa gateway via LoRa messaging. On the cloud side, a LoRa server receives the message from the Gateways and connects to a cloud dashboard for visualization and analytics.

This architecture is perfect for industrial use cases where the device is either stationary or mobile for up to a few kilometres. But, it cannot support the use case where the device is in transit on a refrigerated truck. Also, LoRa doesn’t provide QoS at levels required by most critical industrial use cases.

Figure-1: Current System Architecture for a LoRa Sensor

Learn more about the PicoLTE and what it can do for you.

Use cases where temperature needs to be monitored continuously while the device is in transit and alerts need to be generated immediately are addressed by the CATM based sensor. To achieve this an LTE CAT-M module that supports band-14 is chosen. The chosen HL78xx CAT-M module from Sierra Wireless has support for band 14 and band 42. This module is PTCRB certified and is available today for deployment in Verizon, Rogers, Vodafone, T-Mobile and Sierra Wireless network. The module is pre-certified, and no software/firmware change is necessary. The HL78 module will be interfaced to our existing STM32 processor via a UART interface.

There are two approaches we considered:

An LwM2M client is already implemented on the L78xx CAT-M module. One can leverage Sierra’s LwM2M stack and send data to Airvantage Cloud just using a few simple AT commands on the STM32L03X MCU. This is the simplest approach.

The other approach is to implement our own stack on STM32. One can implement LwM2M, MQTT, some other protocol, or define your own protocol and deal with raw TCP or UDP packets.

We settled on implementing MQTT on the STM32 (Approach #2) because we wanted a simpler protocol that is more comparable to LoRaWAN and that is about providing transport for publishing sensor data to the cloud. We didn’t need the security framework of LwM2M nor the device management feature.

Telit has a great article on the differences between MQTT and LwM2M which we won’t cover here.

In this case, we are still leveraging the TCP/IP stack on the Sierra Module, but we are not using the Airvantage specific AT commands. We are only using the AT commands to open a port and establish a tcp/ip socket connection to our server. MQTT is implemented on the STM32.

The cons of our approach is longer development time, risks in implementing MQTT on STM32 etc. Also, more testing and optimization will be required to ensure proper functioning of MQTT, especially under poor Cat-M1 coverage conditions. Unlike the LwM2M that comes fully configured and vetted, we used Nutaq’s PicoLTE to implement a private Cat-M1 network in bands 14 and 42 and optimized and characterized the device’s behaviour in various network conditions in a controlled environment.

An MQTT client needs to be ported to the STM processor and an AT client will send the MQTT packets to the CATM module. The TCP/IP stack runs on the CATM module. Porting MQTT client to STM and its memory usage is a high-risk item and was already analyzed to de-risk the project.

Figure-2: Proposed System Architecture for a CAT-M sensor

The baseline firmware has logic to sample the ADC and sends LoRa messages periodically. MQTT needs to be ported on this platform and an AT client to interface to the HL78 CATM module needs to be developed. The TCP/IP stack will run on the CATM module and is pre-certified for several carriers.

The Main MCU is the master in this architecture and samples data as per user configuration. The MCU will wake up the CATM module by toggling a GPIO. After the MCU wakes up, a TCP connection will be established for transmitting sensor data to the cloud. If network connection is not available, the device will store the samples locally and sync up to the cloud at the next period.

Warning: If USB_VBUS is connected, it will not be possible to enter Lite Hibernate or Hibernate mode.

Based on our analysis, the MQTT Client fits comfortably using the proposed architecture. Though there is enough space to support a network stack including LwIP and SSL, adding them into the STM processor could cost us more than 100KB and is risky if we want to keep space for adding new features. With the proposed architecture, LwIP and SSL will be in the CATM Module, hence memory usage is not a concern.

As MQTT has programmable QoS settings and LoRa QoS is similar to MQTT QoS level-0, we compared LoRa implementation with MQTT at QoS level-0 as base case.

Captures at the server side while the device was sending temperature data using a CATM network via MQTT allowed confirming no drop in packets as while the cell’s rssi remained strong.

Figure-7: Wireshark IO Graph

Learn more about the PicoLTE and what it can do for you.