Communication Protocols for IoT
IoT is about connectivity and interoperability, as previously outlined. Without these basic elements, we cannot deliver business value. Therefore, we need communication to happen—and in as uniform a way as possible. As with IoT standards, the standards for protocols and media are heavily fragmented. This section provides an overview of the key communications protocols required for IoT to be successful. It also covers the main wireless offerings that provide the pervasive coverage essential to IoT and touches on some essential wired ones. This section aims to give an overview of the key communications protocols so that you understand what is required from a platform connectivity perspective, especially at the edge and fog layers of the system. This is not designed to be a detailed protocol analysis because much information already exists in this area.
As you have already seen, many emerging and competing networking technologies are being adopted for IoT. Various consortia/alliances, vertical markets, and vendors offer differing technologies for IoT connectivity. Traditional enterprise technologies such as Wi-Fi and Ethernet can be applied for IoT. At the same time, new technologies are being developed specifically to meet the challenges of IoT, especially closer to the edge where specific device, distance, or bandwidth challenges need to be addressed. However we look at it, communications are still the foundational enabler for IoT and are needed for all use cases.
Communication protocols are a set of rules that allow two or more devices in hardware or software to establish a reliable communication system that allows data to be transmitted between them. Rules include syntax, semantics, and synchronization, as well as error recovery mechanisms.
The most common communications model is the Open Systems Interconnection (OSI) model (see the left side of Figure 4-7), which breaks communications into seven functional layers for easier implementation of scalable and interoperable networks. Each layer delivers a specific function and handles clearly defined tasks while interfacing with the layers located directly above and below it. The model is the most widely used in network communications today, with clearly defined layers allowing easier implementation of interoperable and scalable networks.
)
Figure 4-7 Open Systems Interconnection (OSI) Model
Although this model is applicable in IoT, it faces certain challenges, especially when devices are very simple and have limited capabilities and computing. A layered approach such as this introduces complexity to the device or software and usually requires more code and memory. It also introduces data overhead because every layer requires additional framing and control messages. More complexity and data transmitted can mean increased power consumption by devices; again, this might not suit an IoT deployment with simple, battery-powered devices. A layered approach does enable more flexibility and scale, however, and also provides the best opportunity for interoperability.
As a result, we see various implementations in IoT. Some use the full OSI reference model, from physical layer to application layer. Others specify only parts of the OSI reference model and leave the remaining aspects of communication up to other technologies. This has led to a more simplistic version of the OSI model for IoT that maps more closely to the TCP/IP model. The right side of Figure 4-7 shows how the model can be simplified for IoT deployments. Some layers are collapsed here, without losing any functionality. This does not mean that one approach is better than the other, particularly because different applications running on top of the communications have different requirements; it simply makes choosing the right option more of a challenge when taking interoperability into account.
This section discusses protocols and communication media, aligning them with the IoT-centric model. Within our focus on communications for data exchange, we look at last-mile communication technologies to the things, or within the fog/edge layers. It is important to make a distinction here because the requirements are different and still emerging. The core networks remain the same and are typically service provider or enterprise based (such as with MPLS). The main change involves connecting the multitude of things together to allow them to communicate between themselves locally or else bringing them back via some kind of backhaul to a central location. Some examples you already are familiar with from the IoT standards overview section; the aim here is to reference the communication elements within them. A fundamental concept to understand is that there is no “one size fits all” approach. A deployment in a smart city might have Ethernet and Wi-Fi connections, whereas a deployment to a remote oil field could be cellular or satellite.
This is extremely important when architecting the system and can dictate architectural and technology decisions. As an example, a gateway might need to be leveraged to provide protocol translation from a legacy system at the edge so that it can be transported through the IoT system by the platform. In another case, a particular function (such as real-time analytics) might have to happen locally because limited bandwidth will not allow a certain amount of data to be transmitted. A more powerful endpoint might thus be deployed to do analytics and data normalization at the fog layer.
From the perspective of the IoT platform, it is important to understand that a wide variety of these protocols need to be addressed as uniformly as possible. This can include IP or non-IP, and different protocols are likely to exist at different levels of the IoT hierarchy. The IoT platform must provide connectivity interfaces for these protocols at the edge or fog layers, whether natively or via a gateway, and must provide a way to securely transport the data flows to their destinations at any level. This applies to both the control and content/data planes.
Following the IoT-centric model, a number of key IoT communication types are mapped out in Figure 4-8.
)
Figure 4-8 IoT-Centric Communications Model Example
This model has four layers to cover the communications stack. Although it covers all the functions required, not all of the protocols fit neatly into one level. For example, DTLS fits into the transport, application, and session levels. Similarly, 6LoWPAN fits into the network, physical, and MAC levels. However, this model provides a good starting point for organizing thoughts around communication.
Physical and MAC Layers
This layer covers how a device is physically connected to a network via wired or wireless mechanisms, as well as how devices are uniquely identified by a MAC address (or potentially another method) for physical addressing. Most standards combine the physical and MAC layer protocols; these protocols are essential in establishing communication channels. For IoT, considerations when designing at this level include devices that need to operate with a long battery life, require low power consumption, and have less processing capabilities. Other points to consider are lower bandwidth availability and the need to scale in terms of connecting and operating many more devices in a single environment.
In IoT, wired Ethernet 802.3 and Wi-Fi 802.11 a/b/g/n standards are often leveraged, depending on the environment. Smart cities and manufacturing plant floors are good examples with dense coverage. Other technologies in use include 802.15.4 (802.15.4e, 802.15.4g, WirelessHART, ISA100.11a), cellular (2G, 3G, 4G, CDMA, LTE), Low Power Wide Area Network LPWAN (Long Range Radio LoRa, SigFox, Narrow Band IoT NB-IoT), 802.16 WiMax, RFID, NFC, Bluetooth (including Bluetooth Low Energy BLE), and Zigbee.
Network Layer
This layer focuses on logical addressing and how to deliver packets of information between source and destination endpoints, particularly between different networks. Routing and encapsulation protocols need to be lightweight (constrained devices) and highly scalable (potentially millions of endpoints).
The Internet Protocol (IP) is an essential element of IoT. This includes both IPv4 and IPv6; the latter is essential to address scale. IPv4 provides around 4.3 billion addresses in total, which can create a challenge as we move toward the predicted 20–50 billion endpoints by 2020. IPv6 provides around 340 billion billion billion billion addresses, meaning that the scalability challenge is negated. However, not all IoT devices need a unique or a public address; many will be deployed on private networks that will continue to use private address ranges or will be hidden behind gateways at the edge and fog layers of the network.
The use of IP not only provides interoperability benefits, but also helps with longevity and future-proofing of solutions. With the speed of change of IoT devices and technologies, the physical and data link layers evolve every few years. Using IP provides support for a smooth evolution of technologies, without changing core architectures, affecting the stability of deployments, or introducing new use cases. Even if the endpoints do not support IP, gateways can be deployed at the edge or fog levels to provide connectivity and transport, as well as to support multiple physical and data link layer types.
Many last-mile communication options can be unreliable and unpredictable, so a new routing protocol was created to address routing for constrained devices such as those in wireless sensor networks. The IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL) routes IPv6 traffic over low-power networks and lossy networks (LLN). LLNs are a class of network in which both the devices and their communication mechanisms are constrained. LLN devices are typically constrained by processing power, memory, and battery; their communications are characterized by high loss rates, low data rates, and instability. LLNs can scale from a few dozen up to thousands of devices.
In areas with low-power radio communication, the IPv6 Low Power Wireless Personal Area Network (6LoWPAN) can be leveraged. It was designed with very constrained devices in mind and allows IPv6 to be used over 802.15.4 wireless networks. 6LoWPAN optimizes the transmission of IPv6 packets over LLNs such as IEEE 802.15.4 through header compression.
Transport Layer
This layer addresses secure end-to-end communication, including reliability, bandwidth, and congestion management, as well as sequencing and session maintenance. Operating in constrained and highly geographically dispersed environments, as well as leveraging physical media that is less reliable, makes User Datagram Protocol (UDP) the protocol of choice in place of the more heavyweight Transmission Control Protocol (TCP). Transport Layer Security (TLS) and Datagram TLS (DTLS) are typically leveraged for secure transport.
Application Layer
This layer covers application-level messaging and provides the interface between the user and the desired IoT application. Hypertext Transfer Protocol (HTTP) and Secure HTTP (HTTPS) continue to be leveraged in IoT. In addition, the Constrained Application Protocol (CoAP) is often leveraged as a lightweight alternative to HTTP as a specialized web transfer protocol for use with constrained nodes and constrained networks. It is often used in combination with 6LoWPAN.
To allow data exchange and facilitate control of the data pipeline, a messaging service is often leveraged within IoT deployments. Messaging protocols such as Message Queue Telemetry Transport (MQTT), Advanced Message Queuing Protocol (AMQP), and Extensible Messaging and Presence Protocol (XMPP) have been leveraged for some time. More recently, feature-rich message services such as the Cisco Edge Fog Fabric (EFF) have been introduced, providing detailed topologies, strong QoS mechanisms, and real-time analytics capabilities as part of the IoT data/content pipeline management.
Industrial IoT environments and specific markets continue to use more industry-specific protocols that have been designed over many years to address certain vertical or market needs. IEC 61850 Sampled Values (SV), Generic Object Oriented Substation Event (GOOSE), and Manufacturing Message Specification (MMS), IEC 60870, Modbus, Distributed Network Protocol (DNP3), and OLE for Process Control (OPC), provide the core communication mechanisms for industrial environments such as power utilities, manufacturing, oil and gas, and transportation.
Many IoT environments, particularly industrials, have a requirement to connect legacy devices and sensors. This means that, in addition to IP- and Ethernet-based protocols, serial-based protocols must be connected. This not only adds integration complexity, but it introduces security considerations.
In summary, as well as in practice, different IoT standards use many of these protocols. Choosing the right protocol often comes down to the vendor, the environment, the network topology, the bandwidth available, and the vertical or market in which the use case will be deployed. Other considerations can include power constraints and usage, reliability requirements, and, of course, security. Some of the options listed, such as IEEE 802.15.4, have security mechanisms built in, such as access control, message integrity, replay protection, and message confidentiality.