How Do IoT Devices Communicate

Internet of Things (IoT) devices communicate is dozens of different ways, using hundreds of different protocols. That’s because how they communicate depends on what they are, where they are, what other devices and systems they need to talk to, and what they have to say. There’s no single best protocol, which is essentially the common “language” used to route messages from one IoT device to another. The right choice always depends on the application’s specific needs.

There are also constraints to be considered. What’s the device’s power budget? What are the cost limitations? What are the requirements for physical size, security, time to market, geographic regions and remote maintenance? In this article we’ll take a look the embedded components of an IoT communication system, and discuss how different needs and contexts determine the best solution for each use case.
Components for IoT Device Communication

While IoT systems come in many different architectures, most include the following components:

1. IoT device– anything from the tiniest temperature sensor to a giant industrial robot
2. Local communications – the method the device uses to speak with neighboring devices
3. Application protocol – the framework that defines how information content is transported
4. Gateways – translate and re-transmit information, typically linking local device networks to the Internet
5. Network servers – systems that manage the acceptance and transmission of IoT data, typically located inside cloud data centers
6. Cloud applications – process IoT data into useful information, for presentation to users
7. User interface – where people see IoT information, manipulate it, and issue commands back to IoT devices

IoT Devices

When we talk about IoT devices, we are usually describing things like environmental sensors, connected appliances, vehicle trackers, or even assembly line machines. While an IoT device is arguably any electronic device that can communicate with the Internet, we usually don’t mean mobile phones or general use computers.

Typically, we’re focused on devices with a narrower purpose, such as controlling the lights in your home or tracking tank levels for manufacturing chemicals. As an example, the following graphic shows the connectivity between an industrial tank sensor using a Digi XBee radio module, communicating with a gateway that houses a Digi ConnectCore System on Module (SOM).

Connecting Wireless Devices

Many of these devices weren’t originally created with Internet capabilities and must be modified with after-market solutions to become connected. However, IoT capabilities are increasingly being designed right into new devices, where they can greatly lower costs and improve functionality.

While IoT devices vary depending on the need they were created to fill, some fundamental components are almost always included. For example:

• There’s typically a sensor to detect physical occurrences, like motion or a water leak.
• There may also be actuators that create physical changes, like turning on a light or closing a valve.
• These sensors and actuators connect with one or more microprocessors running the logic that drives the IoT functionality.
• As a connected device, it must have at least one communication component, either some type of radio or a wired communication method like Ethernet.
• IoT devices are often battery-operated, making power management a key consideration when selecting equipment, designing functionality, and creating communications strategies.

All these components will be housed in some type of enclosure, often quite a small one. Depending on the environment, this enclosure may need to be sealed and watertight, or it may be heavily vented to manage heat. Because IoT devices are often deployed in very large quantities, getting the cost right is critical. Every penny counts when those pennies get multiplied into the millions.

Local Communications Methods and Protocols

Every IoT device needs to communicate. Some devices only send information; many others both send and receive. While some communications with peer devices are direct, remote communications will often need to pass through a gateway to get to their destination. No matter where the device’s messages need to go, every journey begins with a first step.

The following graphic illustrates one model for wireless communications, and how each “node” in the wireless network plays a defined role. As you can see in this example, which is called a “star network,” a smart wireless module coordinates communications out to devices acting as routers and they move the communications out to end devices.

The scenario changes for different combinations of wireless devices and protocols. In the following diagram, you can see how networks can be built to behave in various ways with the use of different wireless protocols. The best protocol depends on a number of factors, such as the distance between communication nodes on the network.

The first step or “hop” in IoT communication will either be wired or wireless. Wired connections may use a simple serial protocol, though most frequently a networking system like Ethernet will be employed, allowing “direct” Internet protocol (TCP/IP) connections to a network server or cloud application. Messages passing over the Internet are routed through many different devices, however as IoT architects, we can safely abstract this process away. Wired connections are fast and reliable, however frequently it is too expensive or impractical to run physical cabling. Naturally for anything mobile, wires are out of the question.

Wireless communications for IoT almost always happen over radio, and there are hundreds of radio protocols out there to choose from. Several are quite popular. Here’s a high-level overview of some popular communication protocols:

• Some devices use Wi-Fi, which has many advantages as long as its power requirements can be met and its complex processing and provisioning needs don’t create a barrier. Wi-Fi runs TCP/IP natively, so once configured, we can abstract away the complexities of the Internet itself.
• Zigbee and Z-wave are big names in home automation networking because they are optimized for low-power, low-bandwidth communications, and both allow devices in the home to talk directly to each other for speed and security. Neither directly supports Internet protocol, so communications outside of the local area typically are routed through a gateway.
• LoRaWAN protocol is increasingly popular for low bandwidth IoT as well. It combines long-range with very low bandwidth, supporting miles of line-of-sight range for devices that only have very small things to say.
• Bluetooth and its low-energy sister BLEare extremely popular for simple IoT devices. Neither can communicate very far, so another device — often a mobile phone — will be used to facilitate long-distance messaging.
• Cellular networks can now easily accommodate IoT devices. New cellular protocols like Cat-M and NB-IoT allow battery-operated devices to run for months without recharging, in trade for very limited bandwidth.
• Other protocols like 4G LTE and 5G require much more power, but can also handle heftier data like digital video.
• There are also many proprietary and single-manufacturer protocols tuned for unique distance needs, special bandwidth requirements, difficult radio environments, and of course cost-optimization. There’s no one protocol that rules them all. Every project will have its own best solution.

Computer networking frameworks are typically structured in virtual layers. The lowest layer deals with the physical part, wires or radio waves. Next are the layers that coordinate how messages are formed, addressed, routed and confirmed. These middle layers are fascinating but beyond the scope of this discussion.

The highest layer manages the useful content, typically referred to as the “application, as shown in the illustration of the “OSI networking model.” OSI stands for Open Systems Interconnection, and the model is a conceptual framewok describing the components or layers of a network’s functions.

The application layer is where the real work of IoT gets done, and it can happen in many different ways. Having a standard way to communicate about particular jobs is incredibly helpful when devices from many different manufacturers need to cooperate to get work done. Some wireless protocols standardize messaging about common tasks like lighting control, security or audio streaming.

Zigbee, Bluetooth and Z-Wave all include application protocols that provide a standard language so that, for example, a light switch made by one company can turn on three different lamps all made by other companies.

Other application protocols are more generic. MQTT and CoAP are both very lightweight application protocols that standardize communications between different devices without restricting messaging to particular tasks. Because they are lightweight, they consume very little bandwidth and therefore very little power, making them ideal for battery-operated devices.

Devices with more power and bandwidth may use RESTful communications via HTTP — the protocol behind the web. This widely implemented framework is task-agnostic too, but because it wasn’t designed with extreme efficiency in mind, it can quickly exhaust both the batteries and bandwidth of a small IoT device and should be implemented with caution.
Gateways

When a device isn’t capable of running Internet Protocol (TCP/IP) directly, it will typically pass its messages to another device called a gateway. This gateway will process and forward messages to and from the Internet.

Gateways help IoT devices stay small, battery-operated and inexpensive, because they typically handle multiple devices as a local base station. For example, here are some real-life scenarios:

• Wearable devices running Bluetooth/BLE often use a mobile phone as their gateway to the Internet. This works well as long as the phone and the devices are nearby each other.
• Home automation protocols such as Zigbee, Z-Wave and LoRaWAN can’t be handled by a mobile phone directly, nor would it make sense since mobile phones don’t stay in a fixed location. These protocols as well as proprietary ones typically use a gateway box plugged into wall power and either Ethernet, Wi-Fi or cellular. They receive information from devices using their native protocol, like Zigbee, process what they receive, and then forward it along over the Internet.
• Industrial environments, such as solar fields and wind farms require a hardened industrial gateway to route communications from devices distributed across the remote device network, as shown in the following illustration.

This “multi-hop” gateway process allows devices with limited capabilities to connect with far-off locations, often using a sequence of different protocols to get the job done. Gateways generally use application protocols such as MQTT, REST or CoAP to connect with a network server or cloud application that is typically housed in some remotely-located data center.

Network Servers and Cloud Applications

Most IoT communications are initially accepted and handled by some type of network server. Certain protocols require this to complete low-level work like de-duplication of redundant messages and conversion of special protocol formats. Even when a protocol does not require additional processing, it is endlessly helpful to have a system that not only manages communications but can configure, secure and report on the devices themselves.

Digi Remote Manager is a leader in this role, focused on providing the best cloud experience for users of Digi’s modules, gateways and routers. Other services like AWS and Azure offer IoT data processing with some more generic device management, and these systems can collaborate together to provide custom solutions.

Once the network server has done its work, data is typically exchanged with a cloud application that will finish turning the IoT data into useful information, offer it to human users and store it for subsequent analysis. Cloud applications often run alongside other network services on platforms like AWS or Azure. They are commonly created using languages like Node.js, Python or Java, and tied to a SQL or NoSQL database that can manage the avalanche of data coming from fleets of IoT devices.

A big data center isn’t a requirement for every system. Even a small hobby computer like Raspberry Pi can do most of what the cloud giants offer, albeit at a definitely limited scale. A living network has many inter-related components at work ensuring that data is delivered where it needs to go, when it needs to get there.

• Cloud servers finish the process of turning data — raw facts about the world — into useful information.
• Pulses from electric meters get transformed into decisions about bringing power plants online.
• Temperature readings get turned into weather predictions. Information flows in both directions, so cloud servers also manage outgoing commands that control everything from traffic lights to chicken coop feeders.

Even with all of this technology in place, human interaction is always required. So a critical task for cloud servers is providing the user interface that brings people into the loop.

User Interface

User interfaces are the last step in the IoT communications chain. They are also the first step in the chain for commands that will flow through the system for one or more IoT devices to execute. There are many types of user interface and an IoT solution often supports more than one.

Humans may interact with the system through a web site, smartphone mobile app, special desktop application, or indirectly through an API integration with business services like Salesforce. Not all interactions happen remotely. Some IoT devices are designed to support direct access and configuration, whether it’s through an onboard touchscreen or even just some switches. Whatever the method, the user interface is where the rubber meets the road. It’s where people unlock the full value of their IoT systems and the information they create.

Light Switch Example

Here’s a simple example of a home automation system that uses all of these components. A homeowner wants to control their dining room lamp using a local switch, and also be able to flip the lights on and off remotely. They select a system that includes a battery-powered IoT wall switch. It communicates directly with lamps using the Zigbee wireless protocol.

This protocol includes a specially designed language for lighting. Since Zigbee is a low-bandwidth protocol that doesn’t use much power, it is also limited in range. Therefore, for remote access, the system comes with a small gateway. The gateway translates the Zigbee messages to the MQTT application protocol and passes it to a network and cloud server that runs the home automation system application. That cloud application communicates back to a mobile app used by the homeowner. Whether right there in their home, or on a totally different continent, they can see the current state of their dining room light and instantly control it.