Hello there,
This is the 2nd post on Protocols used in IoT brought to you by Unit 10xT. In my previous post I wrote about the different components involved in an IoT network. From this post I’ll start explaining about some of the most common protocols and how and why they fit into each layer of the IoT network stack.
Various sources define the IoT network layers in different ways. Each of them has their own pros, cons and explanations. I’m going to choose the most simple one I’ve read and understood. Given below is the figure of the network model I chose.
- Link Layer: It determines how the data is physically sent over the network’s physical layer (Copper wire, coaxial cable or a radio wave). Link layer determines how the packets are coded and signaled by the hardware device over the medium to which it is attached.
- Network Layer: It is responsible for IP datagrams from source network to the destination network. It uniquely identifies networks and routes packets from one network to another.
- Transport Layer: Provides end-to-end message transfer capability independent of the underlying network. Message transfer capability can be set up on connections, either using handshakes or without handshakes/acknowledgments. It also performs functions such as error control, segmentation, flow control and congestion control.
- Application Layer: This layer defines how the applications interface with the lower layer protocols to send the data over the network. Application data is encoded by the application layer protocol and encapsulated in the transport layer protocol which provides connection oriented communication over the network.
Usually when understanding layers, we start from the bottom and work our way up. I think I’ll use a different approach and start at the top. I’m adopting this method because, the protocols that piques our interest lies in the application layer. The most common protocols used in the application layer are, HTTP, CoAP, WebSockets, MQTT, XMPP, DDS and AMQP. If you remember googling IoT protocols when you read my last post, protocols like MQTT, CoAP and XMPP would’ve appeared in every site you opened. Let’s talk about MQTT now.
MQTT is expanded as Message Queue Telemetry Transport. It is a publish-subscribe based lightweight messaging protocol for use in conjunction with the TCP/IP protocol. MQTT was introduced by IBM in 1999 and standardized by OASIS in 2013. It is designed to provide connectivity between applications and middlewares on one side and networks and communications on the other side.
MQTT has three components:
- Message broker controls the publish-subscribe messaging pattern. A topic to which a client is subscribed is updated in the form of messages and distributed by the message broker.
- Subscribers are the clients who are subscribed to one or more topics. They only receive messages about topics to which they are subscribed to.
- Publishers are sensors which collect data and sends it to the broker.
MQTT has five methods:
- Connect- Waits for connection to be established with the server.
- Disconnect- Waits for the MQTT client to finish any work, which needs to be done and for the TCP/IP session to disconnect.
- Subscribe- Requests the server to let the client subscribe to one or more topics.
- Unsubscribe- Requests the server to let the client unsubscribe from one or more topics.
- Publish- Publishes the data from sensors or end devices.
The protocol uses a publish/subscribe architecture. It is event driven and enables messages to be pushed to clients. The central communication point is the MQTT Broker, which is in charge of dispatching all the messages between the senders and the rightful receivers. Each client that publishes a message to the broker, includes a topic into the message. This topic is the routing information for the broker. Each client that wants to receive messages subscribes to certain topic and the broker delivers all the messages with the matching topic to the client. Therefore, the clients won’t have to know each other. They only communicate over the topic. This architecture enables highly scalable solutions without dependencies between the data producers and data consumers.
A topic is a simple string that can have more hierarchy levels, which are separated by a slash. For example the topic for sending living room temperature could be home/living_room/temperature. The client can also use wildcards for subscribing to a topic. A single level wildcard denoted by a ‘+’ only allows arbitrary values for one hierarchy. An example is home/+/humidity which sends the clients humidity data from every topic under house having humidity sensors. A multilevel wildcard denoted by ‘#’ subscribes to more than one level of topics. So if the clients is subscribed to home/# then the client will be subscribing to all the topics under home.
So that’s the basics of MQTT there. I will discuss in deep about MQTT and more protocols in future posts. Thank you for reading and please give your suggestions if you have any.
Thank you & stay secure.
