Lec 5
Lec 5
Lecture – 05
Introduction: IoT Networking - Part II
We, now continue our discussions from the previous lecture on IoT Networking and the
different issues governing it.
The requirements of IoT networks include coverage, high throughput, low latency, ultra-
reliability and high power efficiency. We need to ensure that there is adequate coverage,
coverage in terms of the deployment of these sensor nodes. And, then ensure that there is
sufficient coverage in terms of sensing, communication throughout the territory of interest
where the IoT devices are deployed.
The second thing is throughput that the network supports. Throughput essentially talks about
the data rates, high data rates ensures that through the network, typically a lossy network; you
have higher throughput, higher data rates can be supported. Then, low latency is very
important, you need to have an assurance that from the source to the receiver intended
receiver the time that is spent is minimum. But, in most cases IoT networks would have to
support real time traffic, where the timeliness of the data as we said previously in the
previous lecture is very important. These packets if not received on time, then that data is not
going to be useful for supporting the adequate quality of service of the network. The next one
is reliability ultra-reliability in the face of lossiness, in the face of interference, noise etc. The
next one is high power efficiency, we are talking about low powered nodes, low battery
power, highly energy constrained environments. So, it is very essential to ensure that
whatever solutions we are talking about from a networking point of view, for IoT networks,
these have to be highly power-efficient.
So, before we talk about any further detail, let us again talk about a sample implementation of
IoT. So, this is a very simple kind of example that I will give you. Let us say, that these
different IoT nodes are like different sensors. These IoT devices will have different
components such as the radio interface, the processor, the sensor and few other components.
These IoT devices will collect data, which will be sent through the gateway, maybe a proxy
server, or through the internet. The cloud will do storage, processing etc and at the cloud
there could be different types of analytics; that could be executed. Based on the analytics,
there could be some actuation.
(Refer Slide Time: 06:53)
Let us talk about some of the solutions. One of which is the MQTT protocol. MQTT- the full
form is Message Queue Telemetry Transport which was introduced by IBM and standardized
by OASIS in 2013. MQTT is based on the concept of Publish/Subscribe. This is the key thing
over here in MQTT and this works on top of the existing TCP/IP, the way MQTT has been
designed to work right.
So, Publish/Subscribe, but this you know the way MQTT works is basically to work on top of
TCP/IP, but you know you could have a different variant of MQTT, where TCP/IP
framework may not be used right; you could come up with something else. So, the
advantages of MQTT is that a Publish/Subscribe framework has been proposed, which is very
suitable for IoT, because IoT devices typically would be publishing data, sensing data,
publishing the data. And, you need to take help of the subscribers and the clients, who will try
to pull the data out of the published, data that is buffered somewhere in some agent.
So, this kind of architecture is suitable for IoT and it has the advantage of being reliable,
lightweight, and cost effective.
(Refer Slide Time: 08:14)
This is an example of how the MQTT publish/subscribe framework works. So, look at this
particular picture. We have the MQTT client, which is the publisher on one hand. So, this
publisher will publish different sensed data such as temperature, humidity etc. And, this data
that will be published in the MQTT broker. MQTT broker, which is a server stores this data.
Now, different clients would subscribe to, depending on their interests, and based on the
subscription this MQTT broker, the server is going to respond with the published
information. This is based on publish/subscribe model and this is how this MQTT protocol
works.
(Refer Slide Time: 09:47)
Now, let us look at few more concepts before we talk about few other things. In MQTT we
are talking about different components.
MQTT components: what are these components? We are talking about publishers,
subscribers, and brokers. These publishers are lightweight sensors.
The subscribers are the applications, which are interested in sensor data. These brokers would
help to connect the subscribers with the publishers. So, this is how it is going to work. Now,
let us look at in this kind of backdrop what are the different models for this connectivity.
(Refer Slide Time: 11:43)
MQTT provides different methods that are used to connect, disconnect, subscribe,
unsubscribe, and publish.
We have some kind of this publisher, which are like different IoT sensors like temperature
sensor. These will send the data to the broker which has this queue, where the data will be
queued at the broker. And, then based on the subscription from clients, the data are going to
be sent.
These could be laptops, PDAs, mobile phones etc. We need to talk about QoS, because
without QoS we cannot think of IoT. Quality of service (QoS) is very important. So, for QoS
of MQTT protocol, there are different transactions that will have to be taken into
consideration. The first transaction is basically between the publishing client and the MQTT
server. The second transaction is between the MQTT server and the subscribing client.
(Refer Slide Time: 14:10)
There are different levels of QoS; the first one is the QoS 0 which is about ensuring at most
once delivery. So, this is kind of a best effort and unacknowledged data service. And, here the
publisher transmits the message one time to the server and the server transmits it one time to
the subscriber. There is basically no scope for retry.
QoS 1: on the other hand, talks about at least once delivery, where retry is performed until the
acknowledgement of the message is received. QoS 2 is further different; it is about exactly
once delivery and ensuring that the retry is performed until the message is delivered exactly
once. So, this is how this MQTT protocol works.
Let us now look at the CoAP protocol. CoAP is kind of an application layered protocol. It is
kind of session protocol. CoAP is a protocol, which helps ensure running different APIs,
different applications in IoT.
The full form of CoAP is Constrained Application Protocol, which was designed by IETF.
The full form of core is Constrained RESTful Environment. So, this particular working group
has come up with this core to enable applications with lightweight interface to run in place of
HTTP.
It is a restful service, which is equivalent of the HTTP. So, instead of HTTP, you run CORE.
Core basically works on top of UDP, in the transport layer. This is a protocol, which is called
the Datagram Transport Layer Security Protocol; for securing the transport layer.
(Refer Slide Time: 16:35)
CoAP defines four types of messages: conformable message, non-conformable message, RST
is the reset message, acknowledgement. For confirmable type message, the recipient must
exactly explicitly either acknowledge or reject the message. So, some confirmation has to be
received. And, in case of non-confirmable type message, the recipient sends the reset
message, if it cannot process the message.
So, it utilizes different message messages, such as GET, PUT, OBSERVE, PUSH, DELETE
etc like the MQTT. Similarly, all these different message types like GET, PUT, OBSERVE,
PUSH and DELETE, together are used in order to perform different-different things such as
IP multicast, in M2M communication for IoT.
There are lot of things available, if you have further interest to dig into this particular
protocol. But, from an expository point of view I think this kind of information whatever I
have provided to you is sufficient.
From another point of view, there is another protocol which is called the XMPP protocol. The
full form of which is Extensible Messaging and Presence Protocol, which is again based on
publish, subscribe, model that we talked about in the context MQTT. The communication
protocol, XMPP is based on XML, and it uses DTLS secure transport layer at the bottom in
the transport layer for transport layer security.
(Refer Slide Time: 18:49)
This model is decentralized; that means, there is no requirement for having a centralized
server. And, it has manifold advantages such as it supports interoperability between
heterogeneous networks, heterogeneous devices, and heterogeneous agents. It supports
extensibility; that means, supporting privacy lists, multi-user chat, publish/subscribe chat,
status notifications etc.
And, it also talks about the advantage of having flexibility of supporting customized markup
language defined by different organizations according to their needs, because it is based on
XML. Some of these are very high level. Another one at a very high level is the AMQP
protocol.
(Refer Slide Time: 19:46)
AMQP-full form is Advanced Message Queuing Protocol. This is also based on the
publish/subscribe model like MQTT and XMPP. And, it supports two types of framework:
one is the point to point communication and the other one is multi-point communication and
is typically used for application such as financial applications, and digital finance. It uses
token based mechanism for flow control, which ensures that there is no buffer overflow at the
receiving end. So, flow control is all about use of a token-based mechanism.
The details of which you know I am not going through, at a very high level this is the kind of
feature that is there with AMQP to ensure that there is minimal buffer overflow at the
receiving end and the flow control is preserved. The message delivery guarantees are of
different types using AMQP: one is at least once; that means, offering guarantees in terms of
message delivery. But, these guarantees may do so, multiple times at most once which is
about each ensuring that each message is delivered once or never. And, exactly once which
talks about ensuring no message gets dropped and is delivered only once.
(Refer Slide Time: 21:15)
The full form of this thing is Distributed Data Service Real Time Publish and Subscribe;
again we are talking about publish/subscribe. Because of its inherent characteristics, it is very
much attractive for use in IoT networks, this support Publish/Subscribe framework on top of
UDP transport layer protocol. So, it is a data centric binary protocol and this data in this
context are termed as “topics”. There are topics means like there are users, which subscribe to
a particular topic of interest and the listeners listen to these.
There is a single topic that may have multiple speakers of different priorities and this
supports enlisted QoS for data distribution in terms of data persistence, maintaining,
ensuring, delivery deadline, reliability, freshness of data and in a different protocol, earlier in
the context of IoT networks. The application such as military, industrial and healthcare
monitoring are the ones that find this particular protocol to be of use.
With this we come to an end of both the lectures on IoT networks. All these protocols that we
have talked about are very much attractive for use with any kind of IoT applications and IoT
and industry 4.0 applications these protocols are very attractive.
One of the very key requirements is connected behavior. And for this, all these protocols
these publish, subscribe based protocols that we have talked about in this lecture and the
previous one these will help you to build this kind of connected system, connected network,
and the behaviors content within it.
Thank you.