We have touched on many topics in this IoT series of blogs and briefly touched on the protocols involved. Now that you know more about the wireless technologies and common applications, let’s get into the details of a few of these protocols.
In choosing the appropriate protocol for your IoT application there are a few considerations that must be made. Some of the primary considerations that must be made are security, data reliability, and system architecture/purpose.
- Are you going to be transmitting sensitive data or is the data intended to be publicly available? Different IoT protocols provide different levels of security. Knowing what level of security is required will help you choose the best one.
- Does your system include environmental or other non-critical sensors and a missed data point here and there doesn’t impact your system or are you controlling a device that may be damaged or cause injury if any piece of data is not received by the intended device? IoT protocols use two main methods of transferring data on the network level, one that guarantees your data will be delivered to a connected device and one that does not. This will heavily impact your protocol choice.
- Do all devices in your system need to be able to receive data from other devices or do all your devices simply communicate with a master device or a hub? Do you have just a few devices or 1000s of devices? How your data should move around the system impacts the complexity of protocol required for your application.
MQ Telemetry Transport primarily referred to as MQTT is one of the more popular protocols being adopted by IoT system developers. As mentioned before, there are two main underlying methods of transporting data used in IP networks. MQTT used TCP which guarantees that the data will be sent to the desired destination, assuming that destination is available. This ensures reliability of data transmission for more critical applications. MQTT utilizes a “Publish & Subscribe” paradigm for how data is transferred using TCP from one device to others. In publish and subscribe architecture, a broker acts as a central hub/database for all devices in the system as you can see in the figure below.
Each device may publish data to the broker (e.g. temperature, energy usage, user input) which then forwards the data to any device that has subscribed to that particular type of data of the particular device that is sending the data. This creates very flexible datapaths depending on the system being implemented. Additionally, the MQTT can be used with or without SSL encryption depending upon the security desired and the ability of devices to perform the processing necessary for SSL.
RESTful protocols utilize the HTTP or HTTPS specifications for IoT applications. Everyone is familiar with HTTP as every time you enter a URL into your browser you are using HTTP. HTTP also uses TCP to guarantee data delivery to connected devices. Now imagine instead of trying to load a webpage using a URL, you want to control a light. With a RESTful protocol, the device that controls the light contains a simply webserver that can accept URLs as command. For example to turn on the light, an application or user may enter the url:
http://(ip address of light)/GET/lighton
By sending this url to the device, the light would turn on and also has the capability of sending back a message to the application that indicates that the light has been turned on. Some advantages to RESTful protocols are its ability to use HTTP or HTTPS depending upon the desired security and since it uses traditional HTTP, many existing systems can easily integrate with new devices. However, these protocols require enough process power and memory to run a webserver and only point to point communication and control is possible.
The constrained application protocol or CoAP takes a different approach to IoT communications. CoAP takes some of the concepts of RESTful interfaces, but pares them down to something that can be executed on devices with limited memory and processing power. Since CoAP is designed for lightweight devices, rather than using TCP, CoAP utilizes UDP which does not guarantee data will arrive at its destination but has much less processing overhead. To improve data reliability CoAP provides mechanisms for data that is not received to be retransmitted by the sender, achieving a balance of data reliability and minimal processing. Additionally, since CoAP uses UDP, it cannot take advantage of security protocols such as SSL but provides the ability to use lighter weight security such as TLS. One of the biggest advantages of CoAP other than its low power and memory requirements is its ability to broadcast data to multiple devices simultaneously. TCP requires a server/client relationship whereas UDP is a “connectionless” protocol which allows CoAP to accomplish message broadcasts. For example, if an IoT system has a single sensor but can have multiple user interfaces, one may want the sensor to broadcast it’s data simultaneous to all user interfaces for viewing.
If none of the existing standards based protocols fit your application, you may choose to select bits and pieces from the discussed protocols to develop a custom protocol to best fit your needs. Need help in deciding? Anuva has experience with standards based protocols as well as developing custom protocols and we would be happy to assist you in your decision and implementation.