 Hello everyone, today we will be discussing about application protocols used in IoT. Here is the learning outcome, by the end of this session, students will be able to relate a given protocol with a specific IoT application. Here is the outline, first we will be discussing about why we need protocols and what are exactly IoT protocols and then we will be going through where these IoT application protocols exactly lie in the IoT protocol stack and then we will be getting through an example and then we will be going through an example where we will discuss how MQ2T works with respect to a simple temperature based IoT application. So before proceeding ahead I would like students to pause the video for a while and think on where exactly the IoT protocols lie and why do exactly we need IoT application protocols. So if you could refer the previous video and IoT protocol stack you can easily be able to identify this. So as we talk about an IoT application protocols, the things will be more clear and the answer exactly lies. For the question why do we need IoT protocols, the answer to this lies in overcoming a challenge that we usually come across whenever we are building an IoT project or application. So the basic challenges here are device-to-device communication on a local network or device-to-device communication over internet or device-to-server communication which is situated somewhere in the cloud and server-to-server communication over internet for storing the sensor data. And this challenge is generally resolved by protocols like MQ2T and COAP which stands for message queuing telemetry transport and constrained application protocols founded on TCP and UDP. Where do these protocols exactly stand in the protocol stack? This is a very important topic to understand. So as you can see you can think on this for a while again by pausing the video and the answer is very much clear as soon as you get this protocol stack in front of you. So as you can see we have application protocols and we are most often interested in today's session about these two protocols that is COAP and MQ2T. So these are generally built on UDP and TCP. So as you can see MQ2T is built upon TCP which is a connection oriented protocol whereas UDP is a datagram based or a connection less protocol and hence COAP will be a connection less protocol as well whenever we are utilizing them in our application. So what is more important in this overall TCP IP stack is we are interested in the application protocol. So we are interested in the application layer protocols which are COAP and MQ2T. So exactly how these applications come into picture and how they act in a given IoT application can be easily understood by looking into a couple of examples of IoT. So what are standard protocols in IoT? So the standard protocols in IoT are basically two which are MQ2T and COAP. These are open standards and they are better suited for constrained environments. Like maybe imagine like we have a small microcontroller whose RAM is very less and we can't bear any sort of resources where we need a very high RAM like processing computing and all the things because more often in an IoT application we have because more often in IoT based applications we have sensors which are directly connected to either a small microcontroller or we often have sensors which can be programmed directly. Having said that we have small sensors or microcontrollers it's a proven thing that wherever you have microcontrollers they often have very less amount of RAM available for processing and that is the reason why most of the sensors actually sense the data and they do a small scale processing like maybe sampling or some sort of frequent analysis and then that is directly pumped on to the gateway and then the data is pushed directly to the servers where the analytical modeling or prediction and other types of things are handled by the server. So the entire CPU intensive jobs are based on the servers or the clouds. So having said that again we need to remember always that most of the IoT applications where sensors are enrolled the only job of sensor is to sense the data and by using some hardware protocol directly transfer them to the controllers internal memory space or maybe the internal RAM and we can't rely on these microcontroller RAMs for CPU intensive jobs. So that's the reason why these kind of protocols like MQT and CUIP becomes handy so that we can directly transfer the given data or the sensor data to the servers. They also provide a mechanism for asynchronous communication as well as they can run on IP. We will discuss this in detail. So as an outcome so as a take away of this small discussion so as a take away of this small discussion we can conclude like we can conclude the things like MQT gives flexibility in communication patterns and acts purely as a pipe for binary data whereas CUIP is designed for interoperability with web it is similar to HTTP. Now let us discuss a little bit more about an MQT protocol. So what is MQT? MQT is basically a public subscribed based messaging protocol that is used for transferring data by means of a lightweight or M2M communication. So let us imagine about a condition where we have a central broker generally if we are aware of things like server and client where a client tries to access the servers data and that is how we generally refer the server as a web server. So imagine a small condition so now let us go through a small example of how so now let us simply go through example of how an MQT works in a given IoT application. So as we are already aware that this is a published subscribed based messaging protocol so definitely we need to have some server and a client. So imagine we have a central server which we refer as broker in terms of IoT language especially whenever we are dealing with MQT protocol we need to call the central gateway or the server as a broker. Next imagine we have three clients called Client A, Client B and Client C as shown on the screen and Client A for example is having some temperature sensors connected throughout its own organization or an application. So imagine that Client A has a couple of temperature sensors connected through a micro controller and it wants the sensitive temperature data to be pumped directly to an internet gateway and it wants to broadcast the given temperature to maybe some other clients like Client B and Client C. So with this scenario imagine that you have Client A which is trying to sense the temperature and as shown on the screen it is trying to simply sense the data and directly publish that particular data to the broker. So as you can see here the sensitive temperature is actually sent to the broker so this particular process of a given client transferring a given data towards the broker is known as publishing the data in terms of the IoT and MQT perspective. Next broker is going to get all this data and it is going to transfer the data further to these two clients called Client B and Client C. So the process of broker transferring the data being published by another client in the given network to other clients is known as publishing the data from broker towards the clients. So this is how we exactly talk about whenever we are talking about some other sensitivities. So imagine that we have Client A, Client B and Client C. Now for instance if Client A has temperature sensor connected to it and it wants to publish the data that it has sensed to the remaining two clients called Client B and Client C. So in this case we are going to allow Client A to publish the data. So Client A has currently published the data to the broker and now the broker is having all the sorts of data that Client A has actually sensed in terms of the temperature and now the job of broker is to publish the data further to Client B and Client C and this is how it is done. So do note the arrow directions here. So this is how Client A has actually transferred the data to the broker and broker is now responsible for transferring the data to Client C as well as Client B. Now in this scenario there are two important things to be noted that is whenever a particular client wants to talk with another client like for example Client A wants to talk with Client C and Client A wants to talk with Client B it is not directly possible. The things need to happen only through the broker. So this is how the things generally happen in terms of the impurity. So with this given example it can be very easily identified that wherever you have, so wherever you have a client server based of a logic similar to the example on the screen we need to definitely have the broker working efficiently in between. Now another advantage of using impurity is that only those clients which have actually subscribed to a given specific topic will be getting the data. So this is a new case where we are having four clients Client A, B, C and D as you can see on the screen. So here Client D is a non-subscriber. So do note that Client D is a non-subscriber. So whenever we say it is a non-subscriber what do we exactly mean? So we mean that the data that Client A has sensed and it is trying to publish will only be transferred to the clients which are subscribers which I have underlined that is Client C and Client B whereas Client D is a non-subscriber and that's the reason why there is no data transmission from the broker of the temperature towards Client D. So this is how impurity generally works. So the important points that you need to note whenever you are talking about impurity is we need to identify the topic and then we need to identify the message which needs to be transferred and then we need to identify the subscribers without which it will be very difficult to identify whether the sensor data will be broadcasted or whether is there anyone available to listen or not. So the things will be more clear further if we implement these things clearly in our upcoming videos. Further we have a constraint application protocol which is very much similar to the functionality of a UDP and most oftenly this is a document transfer protocol. The reason why this is known as a document transfer protocol is again this follows the server client model and the packet size is very much very tiny and the packet size involved in COIP is very tiny and that's the reason why most of the IoT based applications wherever we want a one-to-one communication between server and client which involve very tiny microcontrollers which less amount of RAM are utilized. So COIP comes handy whenever you have less resources in terms of RAM and you want a direct one-to-one communication which is also connectionless. Here are the references used for the video. Thank you.