| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| en:iot-open:communications_and_communicating_sut:high_level_communication [2019/05/25 19:09] – irena.skarda | en:iot-open:communications_and_communicating_sut:high_level_communication [2020/07/20 09:00] (current) – external edit 127.0.0.1 |
|---|
| ==== Host Layer Protocols ==== | ===== ===== |
| | <box #5374d5></box> |
| | <box #5374d5></box> |
| | ===== Host Layer Protocols ===== |
| | <box #5374d5></box> |
| | <box #5374d5></box> |
| The host layers protocols include session (SES), presentation (PRES) and application (APP) level, particularly APP (application) layer in the regular Internet communication is dominated by the HTTP protocol and XML-related derivatives, e.g. SoAP. Also, FTP protocol for file transfer is ubiquitous; it exists since the beginnings of the Internet. Most of them are somehow related to the text. They're referenced as "WEB" protocols. Although these protocols are frequently used by advanced and more powerful IoT devices, this is problematic to be implemented in the constrained IoT devices world. Event simplest HTTP header occupies at least 24 + 8 + 8 + 31 bytes without any payload! There is also a problem to cross firewall boundaries when communication between subnetworks of the IoT devices is expected to occur. | The host layers protocols include session (SES), presentation (PRES) and application (APP) level, particularly APP (application) layer in the regular Internet communication is dominated by the HTTP protocol and XML-related derivatives, e.g. SoAP. Also, FTP protocol for file transfer is ubiquitous; it exists since the beginnings of the Internet. Most of them are somehow related to the text. They're referenced as "WEB" protocols. Although these protocols are frequently used by advanced and more powerful IoT devices, this is problematic to be implemented in the constrained IoT devices world. Event simplest HTTP header occupies at least 24 + 8 + 8 + 31 bytes without any payload! There is also a problem to cross firewall boundaries when communication between subnetworks of the IoT devices is expected to occur. |
| Some IoT designed protocols are reviewed below. | Some IoT designed protocols are reviewed below. |
| |
| === MQTT === | ==== MQTT ==== |
| MQTT protocol ((https://www.hivemq.com/mqtt/)) was invented especially for the constrained IoT devices and low bandwidth networks. It is located in APP layer 7 of the ISO/OSI stack, but in fact, it covers all layers 5–7. It is text-based protocol yet very compact end efficient. Protocol stack implementation requires about 10 kB of RAM/flash only. | MQTT protocol ((https://www.hivemq.com/mqtt/)) was invented especially for the constrained IoT devices and low bandwidth networks. It is located in APP layer 7 of the ISO/OSI stack, but in fact, it covers all layers 5–7. It is text-based protocol yet very compact end efficient. Protocol stack implementation requires about 10 kB of RAM/flash only. |
| | |
| <figure mqtt_broker> | <figure mqtt_broker> |
| {{ :en:iot-open:communications_and_communicating_sut:mqtt_broker.png?200 |}} | {{ :en:iot-open:communications_and_communicating_sut:mqtt_broker.png?200 |}} |
| <caption>MQTT Broker, Publishers and Subscribers.</caption> | <caption>MQTT broker, publishers and subscribers.</caption> |
| </figure> | </figure> |
| |
| **MQTT Message**\\ | ===MQTT Message=== |
| MQTT is a text-based protocol and is data-agnostic. | MQTT is a text-based protocol and is data-agnostic. |
| A message is composed of a Topic (text) and a Payload (data). | A message is composed of a Topic (text) and a Payload (data). |
| The payload (data) of the message is text as well, so in case one need to send binary data, it is necessary to encode it (e.g. Base64). | The payload (data) of the message is text as well, so in case one need to send binary data, it is necessary to encode it (e.g. Base64). |
| |
| **MQTT Broker**\\ | ===MQTT Broker=== |
| MQTT Broker is a server for both publishers and subscribers. The connection is initiated from the client to the Broker, so assuming it is located outside of a firewall, it breaks firewall its boundaries. | MQTT Broker is a server for both publishers and subscribers. The connection is initiated from the client to the Broker, so assuming it is located outside of a firewall, it breaks firewall its boundaries. |
| The Broker provides QoS (Quality of Service), and it can retain message payload. There are three levels of MQTT Broker QoS (supplied in the message level). | The Broker provides QoS (Quality of Service), and it can retain message payload. There are three levels of MQTT Broker QoS (supplied in the message level). |
| </table> | </table> |
| |
| === CoAP === | ==== CoAP ==== |
| |
| CoAP protocol (RFC7252) originates from the REST (Representational State Transfer). CoAP does not use a centralised server as MQTT does, but every single device "hosts" a server on its own to provide available resources to the clients asking for service offering distributed resources. CoAP uses UDP (comparing to MQTT that uses TCP) and is stateless thus does not require memory for tracking the state. The CoAP implementation assumes every single IoT device has a unique ID, and things can have multiple various representations. It is intended to link "things" together using existing standard methods. It is rather a resource-oriented (not document-oriented like HTTP/HTML), designed for slow IoT networks with a high degree of packet loss, also support devices to be periodically offline. CoAP uses URIs : | CoAP protocol (RFC7252) originates from the REST (Representational State Transfer). CoAP does not use a centralised server as MQTT does, but every single device "hosts" a server on its own to provide available resources to the clients asking for service offering distributed resources. CoAP uses UDP (comparing to MQTT that uses TCP) and is stateless thus does not require memory for tracking the state. The CoAP implementation assumes every single IoT device has a unique ID, and things can have multiple various representations. It is intended to link "things" together using existing standard methods. It is rather a resource-oriented (not document-oriented like HTTP/HTML), designed for slow IoT networks with a high degree of packet loss, also support devices to be periodically offline. CoAP uses URIs : |
| Request-reponse pair is identified by a unique "Token". | Request-reponse pair is identified by a unique "Token". |
| Sample request-response scenarios are presented in images below. | Sample request-response scenarios are presented in images below. |
| Sample CoAP message exchange scenarios between client and server are presented in the following figures (two per image). | Sample CoAP message exchange scenarios between client and server are presented (two per image) in Figure {{ref>CoAP1}} and Figure {{ref>CoAP2}}. |
| <figure CoAP1> | <figure CoAP1> |
| {{ :en:iot-open:communications_and_communicating_sut:grafika8.png?400 |}} | {{ :en:iot-open:communications_and_communicating_sut:grafika8.png?400 |}} |