Comparing Approaches to Interfacing an LTE-M (CAT-M1) Modem

Introduction

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.

Project Objective

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.

Baseline Architecture

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

PicoLTE -The Network in a Box

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

Learn more

Proposed Architecture of the CAT-M Module

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:

Approach #1) Use the on-module LwM2M stack

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.

Approach #2) Implement your own stack on our MCU

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.

Process

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

Software Architecture

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.

Figure-3: Software Architecture

Modes of Operation

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.

Figure-4: Modes of Operation

Low Power Modes in CATM Module

The HL78 module is operating as a slave in this design. The CATM module will be woken up by the external MCU by a GPIO signal. After the device wakes up, a TCP connection is made to the cloud server and samples are transferred over the network. If network connectivity is not available, the CATM module goes back to Hibernate mode.

Power Mode Possible Modem State I/O State Hardware Wake-up Signal Source
Sleep Stack OFF, DRX, eDRX, PSM, No Service Retained UART1_DTR
Wake_Up
Lite Hibernate Stack OFF, eDRX, PSM, No Service Retained UART1_DTR
Wake_Up
Hibernate Stack OFF, eDRX, PSM Not Retained UART1_DTR

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

Figure-5: Low power modes

Project Report

Memory Usage

As a first step towards this, the memory usage of the MQTT client on STM32 device was studied. The findings are as follows:

Memory Type Available Used Currently MQTT Requirement Usage (Including MQTT Client)
Flash 192 KB 55.10 KB ~3.5 KB 30.5%
RAM 20 KB 7.14 KB ~0.5 KB 38.2%
EEPROM 20 KB Not Used N/A N/A

Table-2: Memory Usage

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.

Network performance

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-6: Wireshark Trace

Figure-7: Wireshark IO Graph

The PicoLTE was instrumental in optimizing and characterizing the behavior of our device as we decreased the Cat-M1 cell gain, introduced packet jitter, tested hand over, and activated coverage enhancement mode.

Figure-8: Nutaq PicoLTE Cat-M1 and NB-IOT Simulator

PicoLTE -The Network in a Box

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

Learn more

IPV4 Statistics

We simulated network disconnects by removing the antenna and connecting it back as well as restarting the server. We also stopped and restarted the Cat-M1 cell on the PicoLTE. The device reconnected again (as shown by the 3 different ports in the below image) and recovered as soon as the network was established again.

Figure-9: Wireshark Destinations and Ports

Hardware Architecture & Design

Instead of the smart modem, a bit pipe modem is used for the project as it was the only device supporting BAND14 and certified for Canadian carriers at the start of the project.

The bit pipe modem is from Sierra Wireless and a module called HL7800. It is connected to a programmable STM32 embedded processor via UART.

Figure-10: Hardware Architecture

Conclusion

In conclusion, we have been able to develop a wireless temperature sensor that publishes to an MQTT broker over an LTE-M (Cat-M1) network and compare it to our baseline LoRaWan based design. We have learned about the tradeoffs between two approaches :

Approach #1) Use the on-module LwM2M stack

Approach #2) Implement your own stack on our MCU

We have learned to use Nutaq’s PicoLTE network simulator to optimize and validate our device.