Application Layer Protocol Options for M2M and IoT Functionality

With adoption of Internet of Things (IoT) and Industry 4.0 functions, devices are increasingly connected via industrial protocols. What’s more, today’s machine to machine (M2M) communications are rapidly standardizing on these protocols. Complicating matters is that IoT protocols don’t describe a single application-layer protocol, as several standards are in operation. So while early IoT implementations used standard internet protocols, there are also dedicated IoT protocols now available.

Modeling communication structures and identifying the right protocol for a particular application can be daunting. This article outlines what various protocols do as well as the options available for these protocols — so design engineers can more easily select the most suitable to integrate.

Figure 1: IIoT functions in industrial automation rely on increasingly connected devices employing industrial protocols for networking. The abstracted layers of these networks require no knowledge of underlying layer functions … which is why so much design engineering focuses on machine networks’ top (application) layer. (Image source: Getty Images)

Defining the application-layer protocol for industrial networks

The structures of communication protocols for digital M2M and IoT systems are conceptually broken into abstract layers, with the most common models having three, four, five, or seven layers. These conceptual frameworks assume that every layer essentially “hides” the detailed workings of a given device or software layer from other devices or algorithms with which it’s communicating. That’s because the layers are defined as containing just enough information for the data exchanges at hand.

Figure 2: Traditional system architectures are hierarchical, but cloud and fog computing have blurred the lines between component functions. That’s prompted use of new network protocol models. (Image source: motioncontroltips.com)

No matter the model used, all establish an application layer as the highest abstraction layer between devices that communicate with each other on a network. Consider the application layer as a concept of the Open Systems Interconnection (OSI) model — in which it was first defined by the International Organization for Standardization (ISO) nearly three decades ago for network communications. This classic seven-layer model is somewhat overcomplicated for describing some of today’s protocols, but is still useful for fully understanding data flow within systems:

A protocol’s physical layer allows the transmission of raw data (digital bits) as electrical, radio, or optical signals. This layer specifies the pin layouts, voltage levels, data rates, and line impedances of the physical elements carrying the data. Ethernet is a common physical layer protocol. Read the DigiKey article EtherNet/IP versus PROFINET for more on this.

The data-link layer connects network nodes to let devices establish connections and correct errors at the physical layer. Within the IEEE 802 standard, the data-link layer is divided into a Medium Access Control (MAC) layer (again, to let devices connect) and a Logical Link Control (LLC) layer for identifying the next layer to be used (the network layer) as well as error checking and synchronization. Read more about the functions of the data-link layer in the DigiKey article Implementing Industrial Ethernet with 32-bit MCUs. In contrast, the network layer allows the forwarding of data packets to network addresses. Where internet protocols refer to the Transmission Control Protocol and Internet Protocol (TCP/IP) model (covered in this article’s next section) there’s an internet layer between the data link and network layers. In fact, the internet layer is often considered a part of the network layer.

The first of the next three OSI-model layers is the transport layer, which ensures communication reliability and security during data-sequence transfers. Then the session layer controls when devices connect with each other and whether the connection is one-way (simplex) or in two directions (duplex). Finally, the presentation layer allows data translation so that devices using different syntaxes can communicate.

The focus of this article — the application layer — is the highest level of abstraction and the one with which users and system software interact.

Figure 3: Modern networking protocols (and the application layer) are often described using the classic OSI model of industrial (and commercial) networks. In contrast, three-layer IoT architecture models set the application layer above perception and network layers; four-layer models put it above data processing, network, and sensing layers. Five-layer IoT protocol models are similar but add processing and enterprise layers. (Image source: Design World)

Internet protocols in industrial automation

Internet protocols are data-communication systems so named for the way in which they relay data between networks (and usually reciprocally) for inter-boundary communications. Their functions are often described with the four-layer model of TCP/IP mentioned above. Here, the physical network or link layer is the same as the OSI model’s physical layer. In contrast, the TCP/IP internet layer (which roughly approximates a combination of the OSI model’s data-link and network layer functions) handles connections as well as data packets. In IPv6, this layer uses 128-bit IP addresses to identify hosts on the network — and allows more than 10³⁸ unique hosts.

The transport layer in TCP/IP generally consists of either the transmission control protocol (TCP) or the user datagram protocol (UDP). TCP is generally used for human interactions such as email and web browsing. It provides logical connections, acknowledgment of packets transmitted, retransmission of lost packets, and flow control. However, embedded systems use UDP to get lower overhead and better real-time performance. UDP works for domain name servers (DNS) and the dynamic host configuration protocol (DHCP) as well as new IoT applications.

The application layer is the highest level in the TCP/IP model of networks. Functions include those associated with the OSI model’s session and presentation layers.

Generic TCP/IP application-layer protocols

Different application-layer protocols have different data bandwidths, real-time capabilities, and hardware requirements. These factors along with plant or OEM-team familiarity with a protocol are often an important selection criterion. Though early internet protocols including the hypertext transfer protocol (HTTP) and simple mail transfer protocol (SMTP) are largely used for human-driven and human-consumed communications, TCP/IP protocols with an IIoT slant are more focused on machine to machine (M2M) and other industrial communications.

Complicating matters somewhat is how many established application-layer protocols used in TCP/IP for web-based human interactions with information also have consumer and industrial IoT uses. That’s certainly true for HTTP and SMTP as well as the secure shell (SSH) and file transfer protocol (FTP). Implementing IoT functions with web technologies is usually feasible if eXtensible Markup Language (XML) and JavaScript Object Notation (JSON) are also used. One caveat is that using HTTP has security implications. That’s why it’s usually best if any IoT devices in such systems only include a client — and not a server. This prevents the device from receiving connection requests that could allow unauthorized outside access to the network. Here, the WebSocket protocol can establish a full-duplex communication via HTTP. Otherwise, the extensible messaging and presence protocol (XMPP) may be preferred for installations that need to address a large number of devices with good security and real-time data communications.

When IoT projects are led by staff with an IT background, these familiar standards (from the human-readable web) may be preferred. However, newer IIoT protocols can in some instances be better suited to M2M and other industrial communications.

MQTT for vertical connectivity transport functions

Seeing the most rapid adoption in IIoT is the Message Queuing Telemetry Transport (MQTT) protocol — a lightweight protocol initially intended for IoT devices with limited memory. Offering operation on compact processing footprints and requiring minimal bandwidth, MQTT was first developed by IBM to connect sensors on oil pipelines. Unlike the constrained application protocol (CoAP), MQTT is already standardized according to ISO/IEC 20922. MQTT uses the somewhat more resource-intensive TCP transport layer and therefore consumes more power … but messages can be two bytes — even smaller than those of CoAP.

Due to its open nature, MQTT can also be particularly easy to implement. No wonder Amazon Web Services’ AWS IoT employs MQTT for message transport and (with caveats) supports MQTT based on the v3.1.1 specification.

MQTT does have some limitations, which may be due to the fact that MQTT was initially intended as a telemetry protocol — in contrast to the IoT-specific Lightweight Machine to Machine (LwM2M) protocol to be covered shortly. Features such as objects, connectivity monitoring, and remote device actions aren’t included in the standard, so inclusion of these tends to be vendor specific which degrades the standardized protocol’s value somewhat. MQTT also offers no error-handling abilities. Finally, although MQTT can be made secure with a full TLS protocol, doing so increases its overhead.

Primarily at the enterprise level: AMQP

Advanced Message Queuing Protocol (AMQP) is another open standard with some similarities with MQTT. It offers advanced features such as message queuing. However, the overhead of AMQP is higher than that of MQTT, making it poorly suited to connecting very constrained devices. No wonder its use in industrial IoT applications is less common than its use in performance enterprise messaging.

CoAP for connecting simple devices

The constrained application protocol (CoAP) from the Internet Engineering Task Force (IETF) allows communication on low-power networks between devices with minimal memory and processing power. It can operate with very low overhead and requests and responses can be as small as four bytes. CoAP eschews the use of a complex transport stack for use of UDP instead. Refer to the DigiKey article on EtherNet/IP versus PROFINET linked above for more on UDP. Like HTTP, CoAP also uses the REST model — with servers making resources available under a URL and clients accessing them via POST, GET, DELETE and PUT methods. What’s more, CoAP can be easily translated into HTTP for integration with other web functions … and integrates with XML and JSON. Engineers should find that connecting IoT devices with CoAP is very similar to connecting devices with Web API.

Figure 4: Nordic's SiP is a low-power MCU with an integrated LTE-M and narrowband (NB)-IoT modem, as well as GPS. A Software development kit allows setup of CoAP. (Image source: Nordic Semiconductor)

Connecting battery-powered devices with LwM2M

An application-layer protocol from the Open Mobile Alliance is the LwM2M protocol built specifically for IoT applications. Employed in smart-city applications, shipping-container, and cargo tracking, automated off-highway routines, and utilities monitoring, LwM2M is based on CoAP, so shares many of its attributes. The standard encompasses a wide range of clearly defined and maintained standard objects as well as connectivity-monitoring and remote-device actions. Automatic firmware upgrades also simplify the management of LwM2M-connected devices. Although the inclusion of modules such as JSON increases its overhead, it also makes design work easier for developers. Because LwM2M has been designed specifically for IoT applications, it can also operate a strong DTLS security protocol without increasing overhead.

DDS for real-time distributed applications

The data distribution service (DDS) is a little different — and is often classified as an M2M middleware rather than an application-layer protocol. It provides secure and high-performance connections in (among other things) autonomous vehicles, power generation, and air-traffic control systems. In these settings, DDS supports the connection of embedded systems for distributed control that’s freed from overreliance on gateways. DDS also handles the routing and delivery of messages without requiring intervention from applications. Plus the quality of DDS service parameters are configurable — so network operations can be optimized to the work within system constraints.

Figure 5: Connext Drive software for autonomous vehicles is built on data distribution service (DDS) middleware — which serves as part of the foundation for AUTomotive Open System ARchitecture (AUTOSAR) Adaptive and ROS2 software architectures. This is just one example of how DDS supports IoT software integration. (Image source: Real-Time Innovations)

Conclusion: IIoT application layer protocols

All protocols have strengths and weaknesses, but open-source options allowing rapid deployment and security (preferably with low overhead) are the most suitable for IoT applications. Embedded systems and system-on-chip (SoC) devices with ever-increasing computing capabilities continue to spur IIoT implementation — and further expand what’s possible at various protocols’ application layers.