Data transport

IoT protocols for IP (OSI layer 7)

To start with, familiarize yourself with a small selection of IoT protocols:

• MQTT (Message Queuing Telemetry Transport) is an extremely popular binary protocol (M2M communication) that supports publish-subscribe.
  • Binary means that unlike normal text, none of the data at protocol layer is easily readable by humans.
  • Publish-subscribe is a communication mechanism akin to sending info letters to all interested parties. There is a sender who provides the information, a broker who accepts delivery of the information, and receivers who have deliberately chosen to receive information on a specific topic (e.g. the temperature in Berlin) and have registered to do so.
• HTTP (Hypertext Transfer Protocol) is the best known protocol that everyone who’s called a Web page via a browser has used. HTTP is mainly used to load Web pages in a Web browser. Communication takes place in accordance with the request-response mechanism (client-server model).
  • Request-response as a communication mechanism means that a corresponding reply is returned or expected for each query. Generally, the questioner actively waits for the response, which arrives quickly. However, it is also possible for the questioner to wait passively for an answer (for example, in an e-mail conversation).
• AMQP (Advanced Message Queuing Protocol) is a binary publish-subscribe protocol. It provides more functions than MQTT but is more complicated and more resource-intensive.
• CoAP (Constrained Application Protocol) is a binary protocol that masters both public-subscribe and request-response communication mechanisms. It can be seen as a restricted, really slim version of HTTP for machine-to-machine communication.
• XMPP (Extensible Messaging and Presence Protocol) is a text-based publish-subscribe and request-response protocol that was originally designed for message exchange in chat programs.
• DDS (Data Distribution Service) is a binary publish-subscribe protocol that is trying to establish itself in the IoT and in Industry 4.0. It is particularly suitable for machine-to-machine communication.

Industry 4.0 protocols

Among other things, Industry 4.0 describes communication inside production plants. Here, it seems understandable that the direct connection to the cloud is not in the foreground. At least, not from the perspective of the machine wanting to communicate with other machines.

Here is a selection of protocols that is by no means exclusive:

• Once you start learning about Industry 4.0, you’re bound to come across OPC UA (Open Platform Communications Unified Architecture). You’ll quickly realize that OPC UA is much more than just a protocol. OPC UA has the potential to become the de facto standard for industrial plants. It’s a good idea to understand the concepts a little better. That’s why we go into more detail in the next section.
• ProfiNet has a long history, and is one of the traditional industrial protocols. It has been subject to constant further development and is therefore one of the most widespread specifications. In addition, it works well with OPC UA. ProfiNet is the Industrial Ethernet variant of the traditional Profibus, a fieldbus that is not based on Ethernet.
• Modbus TCP is the Ethernet variant of the traditional Modbus (a fieldbus) and is particularly suited to smaller systems. As a result, Modbus TCP is frequently found in this segment, too.
• EtherNet/IP (Ethernet Industrial Protocol) is another protocol specification that builds upon Ethernet and meets special industrial requirements using TCP and UDP. Today, it is the most widespread Industrial Ethernet variant by far.
• Ethernet – or, to be more precise, Industrial Ethernet(s) – denotes the modern variants of machine-to-machine communication in industrial plants. Fieldbus can be seen as the predecessor.

Trusted execution environments in brief

Trusted execution environments (TEEs) can help here. A TEE ensures that programs and data cannot be read or changed from outside without authorization. Due to these properties, TEEs are used, for example, in payment solutions – both traditional chip card approaches and today’s smartphone apps.

Generally, TEEs appear in two different forms: Integrated into the main processor (in the case of smartphones, ARM TrustZone is usually used as the solution here) or as a separate chip, often called a secure element. This hardware support contributes to protecting against runtime accesses to sensitive storage areas, input/output (I/O) devices, and persistent data. TEEs can also provide many of the mechanisms that are provided by other trusted computing primitives (e.g. the Trusted Platform Module or TPM), such as remote checks.

As one of the first steps in the IoT landscape, it is important to establish an encrypted and authenticated connection between the devices as well as to a cloud or to an individual back end. To enable this, a public key infrastructure, which forms the basis for TLS, is generally created. The required cryptographic keys and certificates can be kept safely in a secure element that is integrated into the device.

The following diagram shows the hardware security elements and their integration into the AWS IoT Greengrass. The software enhances the cloud functions on edge devices and offers a hardware-root-of-trust storage of private keys in order to enable hardware-secured message encryption.

AWS IoT Greengrass HSI critical security objects. Source: © Amazon Web Services, https://aws.amazon.com/de/blogs/apn/adding-secure-element-support-using-aws-iot-greengrass-hardware-security-integration-hsi/

Blockchain and distributed ledger technology

You’ve surely heard of Bitcoin, and you know that a digital currency is ideal for machine-to-machine payment. And that a blockchain can be used when machines need to negotiate contracts. Why? With blockchains, we combine trusted communication, decentralized protection, and data immutability. Isn’t that exactly what we need?

Let’s get started: Bitcoin is a specific implementation of Blockchain technology. Blockchain is, in its turn, one of the best known incarnations of distributed ledger technology (DLT). Mostly, it’s all about saving data securely in a distributed environment without an intermediary (such as a bank).

Distributed ledger technologies.
Source: Own representation

The technologies differ, among other things, when it comes to properties such as the number of achievable transactions per second (TPS) and the underlying data structure. Note that distributed ledger technologies are currently still in the fledgling stage – even if major investments have already been made in Bitcoin technology and its adaptation.

There are various different implementations of DLTs, and the applications are diverse. For example, in the IoT environment, the following specific distributed ledger technologies are of particular interest to us:

• IOTA offers possibilities for the efficient use of micropayments. In the industrial environment, machines will be able to make purchases on the basis of sensor data, for example.
• Ethereum enables the use of smart contracts. This allows machines to enter into contracts that are associated with actions in certain (negotiated) conditions.

At present, good advice is a rarity – and it’s hard to separate the hype from the reality. Successful projects have indeed already been realized with DLTs. We believe that DLTs will find their niche in future (however large that niche might turn out to be). In any case, it makes sense to take a look at this aspect, and perhaps even investigate it further.