Taming erratic cellular latency with "extreme asynchronous" IoT firmware design

October 28, 2016

Matthew.Eshleman-October 28, 2016

Many Internet of Things (IoT) devices incorporate cellular modules to enable the device’s Internet access. Incorporating a self-contained cellular module into an IoT device’s design has many advantages, yet the complexity and associated communication delays of the cellular network remain. If this inherent complexity is not properly addressed by the device’s microcontroller firmware, then the end user may be exposed to erratic behavior induced by cellular network latency. Even if the device does not require user interactions, ignoring the impact of the cellular network may induce timing jitter in recorded sensor readings with the potential of invalidating the usefulness of the data. To fully solve these challenges, we must embrace “Extreme Asynchronous” event-driven firmware design. This article was inspired by legacy code improvement projects where the author was requested to improve IoT devices exhibiting faults induced by firmware exposed to the delays inherit in the cellular system.

The hardware
IoT devices incorporating a cellular module often follow a design pattern as shown in Figure 1.


Figure 1: Generic IoT Device Hardware Diagram

The focus of this article is the UART interface between the microcontroller, acting as the Data Terminal Equipment (DTE) and the cellular module as the Data Communications Equipment (DCE). This serial interface is often controlled via “AT” style commands, a long lived legacy from Hayes modems and the 1980s. In the context of a cellular modem, some AT commands may incur substantial delays in delivering a response. These delays are often the root of erratic behavior in an IoT device.

The cellular network
There is no doubt that the modern cellular network is an amazing engineering and digital communications achievement. However, to better understand the core issue discussed in this article, a brief examination of some of the challenges involved with the cellular network is required. A device using the cell network for data communications must contend with:

  • Device Registration

    • The device must be registered with the appropriate carrier. When activating, the device must contact the assigned carrier endpoint to join the network and receive an IP address.

    • Joining the network and receiving an IP address may take substantial time.

  • Location and Movement

    • Whether the device is designed to be mobile or is installed in a fixed location, there is no guarantee that the location enjoys a solid data connection.

    • A fixed location device may still be exposed to variations in cellular performance as objects in the vicinity move, trees grow, or buildings are erected.

    • Variations in cell signal quality will cause variations in response times.

  • Connection quality

    • As other cellular devices traverse the area, the device may be exposed to varying levels of data connection quality as the active cell tower adjusts for varying loads.

    • Changes in data rates or quality also impact response times.

The challenges listed above are just a few of the core issues faced by IoT firmware designers making use of a cellular network.

The cellular modems
There are many suppliers of embedded cellular modules with each providing various command interfaces allowing an external microcontroller or other device to control the modem. A common messaging and control interface is the “AT Commands” interface often delivered via a standard UART serial port or other serial data connection.

Most cellular modules adhere to the industry specification 3GPP 27.007 [3] which provides for a common “AT command set for User Equipment (UE).” This specification provides a base set of common AT commands and behavior among compliant cellular modules. Additionally, all cellular modules implement manufacturer specific proprietary commands to support their specific value-added features such as module assisted HTTP queries, FTP transfers, TLS support, and other commands as deemed necessary by the manufacturer and their target market.

It is fundamental to the design challenges called out in this article to emphasize that the AT interface is designed as a command-response style interface. The host controller (DTE) issues an AT command to the module and then waits for a response. No other commands are allowed until the cellular module responds. This restriction is verified with the following excerpt from [2]:

“The chain Command -> Response shall always be respected and a new command must not be issued before the module has terminated all the sending of its response result code.” – [2] Section 3.2.5 – Command Issuing Timing

This is not specific to the quoted manufacturer it is a core behavior among all cellular module AT command interfaces. Given that the DTE must wait for a response, how long might that wait be? Various datasheets again point us to an answer as shown in Table 1 where a small sample of commands and their specified max response delays are listed.

Table 1: Sampling of AT Commands and Possible Response Delays

Source

Command

Description

Estimated Maximum Response Time
(seconds)

[2] – Section 3.2.2

+COPS

Operator Selection

30

[2] – Section 3.2.2

+CGACT

Context Activation

150

[1] – Section B.4

+UPSDA

Context Activation

150

[1] – Section B.4

+USOCO

Connect Socket

20

Yes, some of the commands in the above table may take minutes to respond. Not microseconds. Not milliseconds. Not seconds. Minutes. IoT system and firmware designers must not ignore this information in their module’s datasheet. The author personally investigated a report involving legacy code where the device failed to respond to user interactions for over 2 minutes. This is the core reason for this article.

Continue reading on page 2 >>

 

< Previous
Page 1 of 2
Next >

Loading comments...