IoT Device Communication protocols

It is essential to have secure, optimized data delivery between IoT Devices, Gateway and cloud edge. The interaction between IoT endpoints follow M2M communications. The protocol must be reliable, stable, secure and most importantly it should enable seamless, real time data transfer with less over-head. There are variety of application, data transfer protocol exists in IoT ecosystem. The article briefly explains the protocols and clearly points out which one to choose based on the scenario and use cases.

Requirement of IoT protocols

As many protocols are evolving in IoT space to gather, transmit and transport data from M2M. The protocols should satisfy the requirement for efficient and effective data transmission and realization.

• Protocols should support transferring information from one to many  
• Protocols should have the ability to listen for the events and react
• Able to transfer small payload streams quickly
• Able to sustain and transfer information in low bandwidth network environments.
• Support power constrained, processing constrains devices/sensors
• Support authentication and transport level security
• Able to deliver messages in near real time and real time
• Ensure guaranteed message delivery and message persistence

IoT Network Stack

The IoT stack comprises diverse of protocols for communication from data collection, package, transfer and control.

• Data Collection – Data collected from multiple sensors, actuators
• Data Aggregation – Aggregate the data collected from multiple sources.
• Data Assessment – Data assessed, noise filtered and remove the unnecessary data
• Data Transmission - The assessed data transmitted to the cloud/servers
•  Data Response - The machine receives the response back from the cloud/servers

Application protocols

IoT applications use variety of application protocols. Following are some of the key protocols used in IoT applications.

HTTP/HTTPS:

HTTP (Hyper Text Transport Protocol) is stateless protocol and one of the widely used protocol in IoT irrespective of its non-persistence connection and overhead to transmit IoT data. connection between client (web user) and web server. It is the common used protocol for the Internet and one of the protocol used in IoT applications especially when traditional system/devices connects with the IoT ecosystem.HTTP is not optimized for constrained device communication. HTTP does not have quick delivery and enhanced QoS delivery. It is mostly suited for IoT device/sensors which can initiate connections to a web server but does not want back channel communication

 Key merits:

·       Stateless nature reduces the burden in server computing and memory environment

Limitations:

·       Non-persistent connections

·       Request and response model not feasible in many IoT use cases

·       Bulky header for each request/response

·       Continuous polling required for back channel communication

MQTT:

MQTT (Message Queuing telemetry Transport) specially designed for machine-to-machine (M2M) communication and IoT connectivity. MQTT is the light-weight protocol widely used to send frequency message with less payload. It is used by embedded monitoring devices, Sensors for effective transmission of messages. Main functionalities are

• Topics – Decide which topic to exchange messages between clients.
• Publish/Subscribe – Send and receive messages on specific topics
• Messages – Packaged message contain payload.
• Broker – Receive, filter, route and send messages. Many brokers available .Mosquito ,RabbitMQ are widely used brokers

Architecture:

QoS(Quality of Service) : support different Quality of Service level.

·       QoS:0 ->At most once

·       QoS:1 ->At least once

·       QoS:2 ->Exactly once

Key merits:

1. Asynchronous communication of events

2.Low over heard message transfer

3.Ability to communicate with low bandwidth environment

4.Ability to operate and communicate devices run in low power environment

5.Low foot print

Limitations:

1.Connection need to be opened always which consume more computing power and memory.

AMQP

AMQP (Advanced Message Queuing Protocol) designed for messaging middleware data communication. AMQP uses TCP for reliable delivery and connections are long-lived. It supports secure delivery using TLS(SSL).It is highly reliable and easily interoperable.  It provides reliable queuing, publish/subscribe, routing and secure transmission.

Architecture:

Three main functionalities of Broker

·       Exchange: Receive message from publishers and route to the appropriate message Queue

·       Message Queue: Store messages until consumer consumes the messages

·       Binding: Relationship between exchange and message queue which decides routing criteria

Exchange :

Messages are received and routed to appropriate Queue.  Messages are routed to zero or more queues

1.       Direct
2.       Fan-out
3.       Topic
4.       Headers

Message Queue:

1. ·       Store and forward
2. ·       Private publish Queue
3. ·       Private subscription Queue

Binding:

Bindings are constructed from commands from the client application (the one owning and using the message queue) to an exchange.

Queue-> BIND -> Messages (Conditions)

Key merits:

• ·       AMQP gives better reliability and allows asynchronous delivery.
• ·       Maintain long lived connections
• ·       Fanouts helps to scale messages and route to multiple components.
• ·       Can work broker less peer to peer connection mode

Limitations:

• ·       Heavy weight protocol and not always suitable for IoT applications
• ·       Computing, power and memory requirements are relatively high compare to lightweight IoT protocols
• ·       More header size.

             CoAP(Constrained Application Protocol) 

CoAP is a constraint application internet protocol based on HTTP and it designed for constrained devices communication. CoAP is designed to transfer document between client and server. CoAP helps to save header space due to Bitfields and string mappings. The packet package and parsing in CoAP uses minimum resources due to it simple packet structure which is best suited for constrained devices. The operation includes resource discovery, registration and Notification. It uses UDP as underlying transport protocol which leads to consistent performance and real time delivery. The packet reordering and retrieve should be taken care by application. HTTP and CoAP share the REST model for transferring the content between client and server. CoAP is compatible with HTTP but it is specifically  designed for devices with constrained resources like sensors and microcontrollers.

Architecture:

QoS (Quality of Service):

CoAP support two levels of QoS

·       Without Acknowledgement- It sends and forget the message and does not ensure the guaranteed message delivery

·       With Acknowledgement – It sends and confirm the message delivery by receiving acknowledgement.

Key merits:

• ·       Works with power and processing constraint environments
• ·       Asynchronous communication
• ·       Best suited for home device communication
• ·       Very fast device-to-device communication in UDP.

Limitations:

1.Message unreliability due to UDP. To ensure guaranteed message delivery, method needs to be added in application stack

2.CoAP uses UDP and many devices behind the corporate firewall and enterprise network . The communication blocked by the firewall due to Network Address Translation

Websocket:

Websocket is a bidirectional connection-oriented protocol which use TCP as underlying transfer protocol. It uses HTTP for initial handshake with server and maintain persistence connection between server and client. Bidirectional connection helps invoke clients if any event occurrence at the other end. Browsers support WebSocket to connect with the server and real time data transfer. Web sockets are ideal choice for IoT communication as it needs lot of small data transfer and also require back channel communication. Websockets replace traditional HTTP due to its low overhead and bidirectional nature. It also suitable for ingesting streaming data. It avoids polling or long-polling which requires polling server at regular intervals for new data/event. In WebSocket when new data available it will send message back about data availability

Architecture:

Key merits:

• ·       Persistent connectivity
• ·       Minimal header size
• ·       Bidirectional ,Async and real time
• ·       Suitable for IoT streaming data transfer

Limitations:

• ·       Connection keep alive for long time may not be feasible all the time.
• ·       Not compatible with Load balancers

MQTT over WebSockets 

MQTT widely used for constrained device communication. However, when device wants to communicate MQTT through browser it is required to abstract MQTT messages over websocket. Direct MQTT connection is not possible with browser due to raw TCP connection restriction in browser. MQTT over WebSockets empowers the browser to leverage all MQTT features. It helps to realize many IoT scenarios such as

• Application to display live sensor/device data
• Receive alert and notifications

Comparison

	HTTP	MQTT	AMQP	CoAP	WebSocket
Model	Request/Response	Point to Point	Publish/Subscribe	Request/Response, publish/Subscribe	Request/ Response
Message payload	large payload	Small payload	Large payload	Small Payload	Small Payload
Header	Medium/large	2 byte	8 byte	4 byte	2 byte
Connection	One to one	One to one, one to many	One to one, one to many	One to one	One to one
Data encryption	SSL/TLS	SSL/TLS	SSL/TLS	DTLS	SSL/TLS
Applications	Device to Cloud Cloud to Cloud	Device to Device Device to Cloud	Device to Device Device to Cloud Cloud to Cloud	State transfer approach	Device to cloud Cloud to Cloud
Transport protocol	TCP	TCP	TCP	UDP	TCP
Content discovery	No	No	No	Yes	No
QoS	All messages are served with same QoS	3 levels of QoS	2 levels	2 levels	All messages are served with same QoS
Communication mode	Synchronous	Asynchronous	Asynchronous	Asynchronous	Asynchronous