Communication Protocols for the Internet of Things: A Few Choices

With more and more devices being connected to the Internet and millions of devices interacting with each other and the server, the need for communication protocols is critical. MQTT, CoAP, and Bluetooth are some of the communication protocols covered in this article.

In 2008, the number of connected devices in operation exceeded the number of humans connected to the Internet. It is estimated that by 2025 there will be more than 50 billion connected devices generating a revenue of US$ 11 trillion. Though the term, the Internet of Things or IoT, was first coined back in 1999, the buzzword has started becoming a feasible reality in recent years. As we can see, the consumer electronics market is already flooded with smart and connected LED bulbs, home automation solutions and intelligent vehicles. Meanwhile, the Do-It-Yourself (DIY) hobbyist sector is seeing ultra-low power and high performance SoCs with built-in Wi-Fi, LoRa or Bluetooth communication features.

The prices of radio chips are now as low as US$ 5 and there are tons of new products, unimaginable before but now a reality, as was seen at this year’s Consumer Electronics Show (CES), Las Vegas and Mobile World Congress (MWC), Barcelona. Products like a smart toothbrush that learns your brushing habits, connected drones that can follow and record you while you are in the middle of an adventurous moment like river rafting, or a simple over-the-air (OTA) software update that can turn your car into a smart self-driving vehicle. With IoT and artificial intelligence backing it up, the possibilities are endless.

Getting started with IoT

IoT provides a great development stack, so everyone can contribute to its development and growth. It can be broadly divided into three constituents.

1. The hardware: This makes up the ‘things’ part of IoT and usually has a small microcontroller with sensors/actuators and firmware running on it, which is responsible for how it functions. A good example of this would be a smart fitness tracker with, say, an ARM Cortex M4 microcontroller and an Inertial Measurement Unit (accelerometers or gyroscopes) sending data to your smartphone via Bluetooth.

2. The software: Firmware running on the device, mobile applications, cloud applications, databases, device management/implementation, the frontend to display data or an algorithm which gives intelligence to your IoT project—all come under the software portion of the IoT stack.

3. The cloud: The ability to stream and store data over the Internet, visualise it in a Web browser and control the device remotely from any part of the world is all because of the cloud, which virtually makes the data available anytime, anywhere.

There are innumerable ways to get into the IoT space, right away. In this article, I’ll talk about communication protocols for the IoT space, which can be used for communication between machines or between a machine and server. Due to constraints in processing capabilities and the low power requirements of IoT devices (which are generally meant to be deployed in environments with constant battery power) with limited bandwidth capabilities, a need was felt for dedicated standards and protocols especially designed for IoT. Since those who manufacture IoT devices and those who create the IoT platforms are different, this required industry standards and protocols that were not high on power consumption, bandwidth usage, or processing power and could be adopted easily by all IoT players—hardware manufacturers, software developers or cloud solutions/service providers.

When developing and deploying an IoT project, it’s important to answer questions like:

• How do my devices talk to each other or to me?
• Do I want the stability of a wired network or the freedom of a wireless one?
• What are my constraints? Data rates, battery power or poor networks?
• What communication options do I have?

Enter the world of IoT communications

This section covers a list of IoT communication protocols.

1. MQTT (Message Queue Telemetry Transport)

MQTT is my preferred IoT protocol, which I use for almost all my IoT automation projects. It was created about 15 years back for monitoring remote sensor nodes, and is designed to conserve both power and memory. It is based on the ‘Publish Subscribe’ communication model, where a broker is responsible for relaying messages to MQTT clients. This allows multiple clients to post messages and receive updates on different topics from a central server known as the MQTT broker. This is similar to subscribing to a YouTube channel, where you get notified whenever a new video is posted.

Using MQTT, a connected device can subscribe to any number of topics hosted by an MQTT broker. Whenever a different device publishes data on any of those topics, the server sends out a message to all connected subscribers of those topics, alerting them to the new available data. It is overall a lightweight protocol that runs on embedded devices and mobile platforms, while connecting to highly scalable enterprise and Web servers over wired or wireless networks. It is useful for connections with remote embedded systems, where a small code footprint is required and/or network bandwidth is at a premium or connectivity is unpredictable. It is also ideal for mobile applications that require a small size, low power usage, minimised data packets, and efficient distribution of information to one or many receivers. It is an ISO standard (ISO/IEC PRF 20922) protocol. The good performance and reliability of MQTT is demonstrated by Facebook Messenger, Amazon IoT (AWS-IoT), IBM Node-Red, etc—organisations that are using it to serve millions of people daily.

An MQTT-SN or MQTT sensor network allows you to use MQTT over a wireless sensor network, which is not generally a TCP/IP based model. The MQTT broker can be run locally or deployed on the cloud. It is further enhanced with features like user name/password authentication, encryption using Transport Layer Security (TLS) and Quality of Service (QoS).

MQTT implementation: MQTT can be implemented with a broker and MQTT clients. The good news is that both can be found open sourced in the Mosquitto package, which is an open source MQTT broker available as a package for Linux, OSX or Windows machines. It runs an MQTT broker daemon, which listens for MQTT translations on Port 1883 of TCP (by default). To install it on Debian based machines (like Ubuntu 16.04, Raspbian Jessie, etc), simply run the following command from the terminal:

# sudo apt-get install mosquito mosquito-clients

This will install and run MQTT broker on your Debian based Linux machine and provide clients the utilities mosquitto_pub and mosquitto_sub, which can be used to test and use it.

On the device/client side, Eclipse IoT provides a great open sourced implementation of MQTT and MQTT-SN version 3.1.1 in the form of a library known as Eclipse PAHO, which is available for almost all modern programming languages like C, C++, Java, Python, Arduino, etc, or can be used over WebSockets. For more details or the API reference, visit http://www.eclipse.org/paho/. The table in Figure 3 compares HTTP and MQTT, clearly showing why the latter is a winner in the IoT space.

2. CoAP (Constrained Application Protocol)

Constrained Application Protocol (CoAP) is an Internet application protocol for constrained devices (defined in RFC 7228). It enables constrained devices to communicate with the wider Internet using similar protocols. CoAP is designed for use between devices on the same constrained network, between devices and general nodes on the Internet, and between devices on different constrained networks joined by the Internet. It is an application layer protocol designed for network constrained IoT devices like wireless sensor network nodes, and is often termed the lightweight version of HTTP with support for REST APIs. It can run on most devices that support UDP or a UDP analogue. It implements the REST architectural style which can be transparently mapped to HTTP. However, CoAP also provides features that go beyond HTTP such as native push notifications and group communication. While a usual HTTP header can be around 100 bytes, a CoAP standard header can be as light as just 4 bytes. Unlike MQTT, CoAP doesn’t require a broker server to function. On the implementation side, the Eclipse Californium project provides a Java implementation of the CoAP protocol, including support for the DTLS security layer. There’s also a MicroCoAP project which provides CoAP implementation for Arduino. Check out https://github.com/1248/microc.

3. Bluetooth and Bluetooth Low Energy

While MQTT and CoAP are infrastructure-independent, which means that it doesn’t matter whether you’re connected to a wired or a wireless network, Bluetooth provides only wireless communication over radio frequency (2.4GHz spectrum in the ISM band) using an industry standard that was initially used to share files between mobile phones and is now powerful enough to play music (Advanced Audio Distribution Profile/A2DP), stream data, or build your next IoT device. Bluetooth, generally, is divided into three categories.

Bluetooth Classic: This is meant for high data rate applications like streaming audio wirelessly.

Bluetooth Smart or Low Energy/BLE: This is meant for low powered battery-operated devices that stream low packets of data.

Bluetooth SmartReady: These are essentially the ‘hub’ devices such as computers, smartphones, etc. They support both the ‘classic’ and ‘smart’ devices.

Bluetooth is a sophisticated ad hoc networking protocol, and is now especially designed from the ground up for IoT. It provides a stable connection and communication channel, which is extremely low profile and low powered. An obvious example is fitness trackers, which even though powered on throughout the day, can last for months on a single charge or run on a coin cell battery, all thanks to BLE (Bluetooth Low Energy). Bluetooth Classic has fixed profiles like UART over Bluetooth class and A2DP class for audio streaming. On the other hand, Bluetooth Low Energy provides GATT or Generic Attribute Profile, which allows users to define their own profile using Bluetooth, like in the case of a heart rate monitor. BLE is extremely flexible and useful in the IoT space. Bluetooth 5.0 is already out and is maturing, offering more range, more data rates and double the transmission speeds.

Which protocol should I use for my next IoT project?

There are many different protocols and industry standards that are specially designed for IoT or can be used for it, such as the few mentioned above and others like Wi-Fi WebSockets, Zigbee, LoRA, Simple RF, XMPP, RFID, NFC, etc. Yet, one’s choice should be based on the project requirements and the constraints of the application you are thinking of developing. MQTT, for example, is extremely powerful when you have an actuator network which needs to respond to a common sensor. The PUB/SUB model is ideal in that case. In the case of CoAP, you can create your own constrained network environment and relay information to the Internet via proxy. If your project does not require the Internet or long range communication, like a fitness tracker, then Bluetooth Low Energy could be the best choice. The possibilities in the IoT space are endless.