How to successfully communicate with IoT devices from anywhere

Whether you’re building a fleet management sensor or a livestream camera solution, you know that the data you collect from devices can drive ROI. But, it’s also important to be able to complete inbound device communication to effectively manage costs.

You’ve likely heard acronyms like MQTT, VPN, TCP, UDP and more consistently referenced. These aren’t just alphabet soup — rather, they’re incredibly important communication protocols that you should know to help you communicate with devices from anywhere. Not all use cases rely on the same protocols, so keep reading to learn what you need to know about some of the most common types.

Why do you need to communicate with IoT devices?

There are lots of reasons why you may need to communicate with a device once it’s been deployed in the field. For example, you may need to reach a device for reconfiguration, such as changing application parameters. Additionally, you need the ability to update firmware to fix bugs or add features. Remote device communication is also critical when investigating issues with the device’s functionality. However, most IoT devices deployed are not reachable from the public internet due to the presence of a CGNAT. In addition, there can be significant security concerns if IoT devices were not protected from the public internet, and thus generally sit behind firewalls for additional security.

The difficulty with inbound communications to an IoT device is the presence of a CGNAT. CGNAT stands for Carrier-Grade NAT, and is a type of large-scale network address translation used by carriers to deliver internet connected services to a very large number of devices. Simply put, there are more devices online in the world than what can be possibly addressed by the IPv4 address ranges, and CGNAT is used to limit the number of required public IPv4 addresses that are used. Because CGNAT masks the internal address of devices on the network, there is no public address available for a user to directly address, or reach, a device behind a CGNAT. However there are tools and protocols that can be used to overcome this and enable you to communicate remotely to your device.

Thus, when you are looking to deploy your fleet of devices, understanding the protocols available that enable you to access your devices is critical to maintaining your fleet over the long run. Without an ability to have remote access, and perform the necessary functions to maintain your fleet, will result in the need to send a team member out to the field to service your devices. Given many IoT devices are deployed in remote, hard to reach locations, there can be a significant expense in sending out a team member to manage a low-cost device. Thus, understanding and developing capabilities to remotely manage your devices can help protect your IoT investment, and reduce future cost risks.

What are the OSI and TCP/IP network stacks?

To best understand some of the different types of protocols in IoT, it can be helpful to first look at the OSI and TCP/IP models of network stacks. The network stack refers to the ordered layers of software and hardware that interact and depend on each other to send communications.

Each layer has a function and corresponding protocols. Although the OSI and TCP/IP models have different layers, they have the same functions as you go up in the stack. Typically, protocols that sit higher in the stack can be easier to integrate with your other applications.

Types of IoT remote device communication protocols

Short message service (SMS)

Although SMS is commonly thought of in consumer cell phone examples, it’s also used in IoT to send messages (or commands) to devices. SMS is a low level protocol that can be used for simple commands. While it doesn’t offer the most robust capabilities, SMS can be useful in sending commands to one, or even thousands of devices at a time, such as in fleet management examples. Unlike other methods, it doesn’t require that a connection be established — an SMS will always send, regardless of whether the device is able to receive it.

User Datagram Protocol (UDP)

UDP is a simple, connectionless internet protocol wherein error-checking and recovery services are not provided. With UDP, there is no overhead for opening a connection, maintaining a connection, or terminating a connection. Because of this very low overhead, UDP is mainly used in loss-tolerant, low-latency data transfers, such as in video streaming use cases that require high throughput performance. Because UDP is not a connectionless internet protocol, delivery isn’t guaranteed.

In terms of access to your deployed devices, because UDP is a connectionless protocol there is no mechanism to send UDP packets through the CGNAT to your devices. So while it may be tempting to utilize UDP for packet communication in a cellular application due to its low overhead, without additional tools in place, UDP will not provide the ability to reach your devices.

Transmission Control Protocol (TCP)

TCP is a connection-oriented communication protocol, meaning once a connection has been established data can be transmitted in both directions. This connection allows for both inbound and outbound device communication, and ensures all packets are delivered in order without errors. Because TCP is bidirectional, once a device establishes an outbound connection to a publicly accessible server, as an example, the server is able to communicate back to the device directly. Because of this ability, TCP is the most fundamental protocol within the OSI stack that enables communications to your devices, it is the backbone of all the other protocols and communication channels discussed in this blog. However because TCP is a low-level protocol on the OSI stack, managing raw TCP connections can be complex to setup and manage. As such, a TCP interface to your devices are more appropriately managed by a firmware developer, as opposed to a field tech or product manager.

Message Queuing Telemetry Transport (MQTT)

MQTT is a lightweight, low data usage option to send messages to control outputs and read and publish data from sensors, built on top of TCP. MQTT uses a publish and subscribe mechanism, where devices are signed up to topics. Topics may consist of things like health or status messages. The devices will connect to the cloud via an MQTT broker, such as AWS or Microsoft Azure, and can provide a one to many, or a many-to-many, communication model. It’s widely used in IoT, and well suited for a variety of use cases ranging from industrial monitoring to robotics.

Virtual Private Network

Virtual private networks, or VPN, is a service that establishes a secure, encrypted connection between devices and the internet, providing a private tunnel for data and communications. The data transmitted via a VPN tunnel is protected from unauthorized access or tampering, ensuring the end-to-end privacy and security of the information. VPNs are especially important in IoT environments where sensitive data is being transmitted, such as in industrial control systems, financial systems, and healthcare devices. The use of encryption algorithms and authentication protocols helps to prevent unauthorized access to the network and the devices connected to it, reducing the risk of cyber attacks and data breaches.

Recommended reading: VPN vs. APN in IoT security: What’s the difference?

Secure device tunneling

Secure device tunneling, similar to VPNs, is a technique used to gain access to devices behind firewalls for troubleshooting and configuration. The data transmitted via secure device tunneling is however typically not encrypted and the data doesn’t have the same protection as in the case of VPNs. This generally means that secure device tunneling services, such as Spacebridge provided by Hologram, uses much less resources on your devices and reduces the overall data usage to do the same tasks as can be done in a VPN. There are also many other vendors, such as Amazon’s AWS IoT Core that provides out of the box secure device tunneling services. Even in non-cellular applications, secure tunneling does not require updates to existing inbound firewall rules, so your device can keep the same security level provided by firewall rules at a remote site.

Communicate securely with your devices with Hologram

Spacebridge is Hologram’s secure device tunneling service that can be enabled on any Hologram SIM. With Spacebridge, users can securely tunnel to a TCP port on their device to send and receive data. In addition, tunnels can be opened using standard SSH protocol for command-line or programmatic access, or HTTP connection to view device based webpages. Because of the low overhead of Spacebridge, and the fact that you as a user do not need to set up additional cloud based services, it is an overall cheaper option than implementing a VPN solution. Spacebridge can be used through Hologram’s Dashboard to access your devices remotely, sending TCP, UDP, or SMS messages directly to your device without the need to setup or configure additional resources. Spacebridge also has an ability to be run on a local machine to enable connecting to the webpage (HTTP) of your device, or connect over SSH to reach a command line terminal to a linux-based device, as examples.