Cloud, server, data base , user end applications : data presentation, data analytics, big data, AI,….

Ben Fradj Hanene

<!-- Slide number: 7 -->

IOT 4 Layers

7


Ben Fradj Hanene

<!-- Slide number: 8 -->

MQTT definition

MQTTis a machine-to-machine (M2M) IoT connectivity protocol.

It is a lightweight publish and subscribe messaging transport protocol.

It is useful for connections to remote locations where a small code footprint is required, or network bandwidth is at a premium.

Notes:

According to https://www.mqtt.org, Andy Stanford-Clark of IBM and Arlen Nipper of Cirrus Link authored the first version of the MQTT protocol in 1999. In 2013, IBM submitted MQTT V3.1 to OASIS.

MQTT V3.1 is the most used version with the TCP/IP protocol. Version 3.1.1, also know as MQTT-SN, supports networks that do not use TCP/IP, such as Zigbee. The core difference between MQTT V3.1 and MQTT-SN V3.1.1 is that MQTT V3.1 depends on TCP and MQTT-SN depends on UDP or Bluetooth.

In this course, the focus is on MQTT V3.1.

<!-- Slide number: 9 -->

MQTT components

Topic is the place to or from which a device wants to put or retrieve a message.

Broker is the server that handles the data transmission between the clients.

receives all messages from the clients and then routes the messages to the appropriate destination clients.

There are many brokers that implement the MQTT protocol. One of the most popular and commonly used is the Mosquito broker. HiveMQ,…


Notes:

MQTT components:

•In MQTT, the word topic refers to an UTF-8 string that the broker uses to filter messages for each connected client. The topic consists of one or more topic levels. Each topic level is separated by a forward slash (topic level separator).

The client can subscribe to the exact topic or use a wildcard. For example, subscription to house/+/temperature results in all message being sent to the topic house/living-room/temperature and any topic with an arbitrary value in the place of living room, for example, house/kitchen/temperature.

The plus sign is a single-level wildcard and allows arbitrary values for only one hierarchy. If you need to subscribe to more than one level, for example, to the entire subtree, there is also a multilevel wildcard (#). You can use it to subscribe to all underlying hierarchy levels. For example, house/# subscribes to all topics beginning with house.

<!-- Slide number: 10 -->

MQTT components

Message is the data that a device receives “when subscribing” from a topic or sends “when publishing” to a topic.

Publish is the process that a device uses to send its message to the broker.

Subscribe is the process that a device uses to retrieve a message from the broker.

In a publish and subscribe system, a device can publish a message on a topic, or it can be subscribed to a topic to receive messages.

For example, if Device1 publishes on a topic and Device 2 is subscribed to the same topic as device 1 is publishing in, Device 2 receives the message.

Notes:

Reference:

https://1sheeld.com/mqtt-protocol/

<!-- Slide number: 11 -->

Publish and subscribe pattern

In general, the publish and subscribe pattern is composed of the following components:

Publisher

Subscriber

Broker


Notes:

The publish and subscribe pattern (also known as pub/sub) provides an alternative to traditional client/server architecture. In the client-sever model, a client communicates directly with an endpoint.

•The pub/sub model decouples the client that sends a message (the publisher) from the client or clients that receive the messages (the subscribers). The publishers and subscribers never contact each other directly. In fact, they are not even aware that the other exists. The connection between them is handled by a third component (the broker).

•The job of the broker is to filter all incoming messages and distribute them correctly to subscribers. So, let’s dive a little deeper into some of the general aspects of pub/sub.

This slide shows an example of the publish and subscribe pattern. The publisher sends the message to the broker, and all subscribers are connected to the same broker.

•The publisher (in this case, a temperature sensor) sends temperature information to the MQTT broker.

•There are three subscribers:

-Mobile, which is controlled by an operation engineer.

-An actuator that controls another machine.

-A web dashboard that represents the control loop.

•When the sensor sends its information to a predefined topic (in this case, CAI/TEMP), all subscribers that are subscribed to this topic receive a copy of this message.

<!-- Slide number: 12 -->

Publish and subscribe pattern

This slide shows the following pattern:

The Temp Sensor connects to the MQTT broker.

The mobile device connects to the same MQTT broker.

The mobile device is subscribed to the topic CAI/TEMP, so when the Temp Sensor publishes any data on topic CAI/TEMP, the broker send the message to the mobile device.


Notes:

<!-- Slide number: 13 -->

MQTT quality of service

An MQTT client provides three types of QoS for delivering publications to Broker and to the MQTT client:

At most once.

At least once.

Exactly once.

When an MQT T client sends a request to IBM MQ to create a subscription, the request is sent with the "at least once" QoS:

At most once: QoS=0 is the fastest, but is less reliable.

At least once: QoS=1

Exactly once: QoS=2 is the slowest, but is more reliable.

<!-- Slide number: 14 -->

MQTT quality of service

QoS is a balance between speed and reliability. Here are some examples of QoS in action:

A sensor must send a continuous stream of temperature readings every second. In this case, QoS=0 is likely the best option because in a worst-case scenario where you might lose a few seconds, this lapse can be accommodated.

An actuator receives a command to turn off a car engine if it is stolen. In this case, QoS=1 is likely the best option because you want to ensure that the car engine is turned off, and if you turn off the car engine twice it should not cause an issue.

You have a robot that works on hazardous environments, and you are sending tuning commands to control its arm. For such a mission-critical situation, QoS=2 is likely the best option because sending a command twice might cause an error.

Notes:

Reference:

https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_9.0.0/com.ibm.mq.dev.doc/q029090_.htm

<!-- Slide number: 15 -->

MQTT

At most once (QoS=0)

This service level guarantees a best-effort delivery. There is noguarantee of delivery.

The recipient does not acknowledge receipt of the message and the message is not stored and retransmitted by the sender.

QoS0 is often called “fire and forget” and provides the same guarantee as the underlying TCP protocol.


Notes:

•The message is delivered at most once or it is not delivered at all. Its delivery across the network is not acknowledged.

•The message is not stored. The message might be lost if the client is disconnected or the server fails.

•QoS=0 is the fastest mode of transfer. It is sometimes called "fire and forget".

•The MQTT protocol does not require servers to forward publications at QoS=0 to a client. If the client is disconnected when the server receives the publication, the publication might be discarded depending on the server. The telemetry (MQXR) service does not discard messages that are sent

<!-- Slide number: 16 -->

MQTT

16


Ben Fradj Hanene

Notes:

At least once (QoS=1):

•QoS=1 is the default mode of transfer.

•The message is always delivered at least once. If the sender does not receive an acknowledgment, the message is sent again with the DUP flag set until an acknowledgment is received. As a result, the receiver can be sent the same message multiple times and might process it multiple times.

•The message must be stored locally at the sender and the receiver until it is processed.

•The message is deleted from the receiver after it processes the message. If the receiver is a broker, the message is published to its subscribers. If the receiver is a client, the message is delivered to the subscriber application. After the message is deleted, the receiver sends an acknowledgment to the sender.

•The message is deleted from the sender after it receives an acknowledgment from the receiver.

<!-- Slide number: 17 -->

MQTT

17


Ben Fradj Hanene

Notes:

Exactly once (QoS=2):

•The message is always delivered exactly once.

•The message must be stored locally at the sender and the receiver until it is processed.

•QoS=2 is the safest but slowest mode of transfer. It takes at least two pairs of transmissions between the sender and receiver before the message is deleted from the sender. The message can be processed at the receiver after the first transmission.

•In the first pair of transmissions, the sender transmits the message and gets acknowledgment from the receiver that it stored the message. If the sender does not receive an acknowledgment, the message is sent again with the DUP flag set until an acknowledgment is received.

<!-- Slide number: 18 -->

TOPICS

IOT Context and architecture

IOT Layers

MQTT protocol overview

MQTT definition

MQTT components

Publish and subscribe pattern

MQTT quality of service (QoS)

HTTP protocol overview

HTTP definition

Client/server model

HTTP Request and Response

HTTP and MQTT protocol comparison

<!-- Slide number: 19 -->

HTTP (Hypertext Transfer Protocol) : definition

19

HTTPis an application-level protocol for distributed and collaborative hypermedia information systems.

It is a generic and state less protocol that can be used for many tasks beyond hypertext, such as name servers and distributed object management systems by extending its request methods, error codes, and headers.

The HTTP protocol has the following components:

Methods (verbs): GET, POST, PUT, DELETE, and PATCH

Error codes (status codes):

1XX: Information

2XX: Success

3XX: Redirection

4XX: Client Error

5XX: Server Error

Headers

Headers are the components for the header sections for both requests and responses. A header includes a name and values.

Here are two example headers:

Content-Type: Describes the media type of the body of the POST and PUT methods.

Content-Length: Describes the length of the response body in octets.

Developers can define their own headers.

Ben Fradj Hanene

Notes:

Reference:

https://tools.ietf.org/html/rfc2616

<!-- Slide number: 20 -->

HTTP : client/server

20

The term client/server describes a type of distributed processing in which an application is divided into two parts.

Each part might be on separate operating systems, but they work together to provide a service to the user.


Ben Fradj Hanene

Notes:

<!-- Slide number: 21 -->

HTTP: client/server

21

In general, a back-end service can be databases or applications that are developed with any language (such as C, Java, Python, C++, or JavaScript). The client can be a user, physical entity (connected sensor), mobile device, or another application that uses a common programming language.

Microservices, also known as the microservice architecture, is an architectural style that structures an application as a collection of services.

An application that calls another application is the basic principle of microservices, which is an architecture pattern that you can use to build a distributed loosely coupled network of services that communicate with each other by using the HTTP protocol.

Ben Fradj Hanene

Notes:

Reference:

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.ieak500/ieak511.htm

<!-- Slide number: 22 -->

HTTP request and responses

22

HTTP Request and Response provide a simplified view of the TCP/IP protocols.

Here is an example of how the seven layers model can simplify and hide the complexity of the underlying layers.


Ben Fradj Hanene

<!-- Slide number: 23 -->

HTTP request and responses

23

Here are some important highlights regarding HTTP/1.1:

The client always initiates the connection. If the client wants to retrieve or post something from the backend, the client still must initiate the connection.

After the server responds with any status code, the connection is terminated.

Questions to be discussed:

What if the server wants to send the user a message, such as “Turn off the device”?

What if you want to keep the connection open for a long period to stream data, such as car trips?

What if the user or device wants to communication with another user or device?

Ben Fradj Hanene

<!-- Slide number: 24 -->

TOPICS

IOT Context and architecture

IOT Layers

MQTT protocol overview

MQTT definition

MQTT components

Publish and subscribe pattern

MQTT quality of service (QoS)

HTTP protocol overview

HTTP definition

Client/server model

HTTP Request and Response

HTTP and MQTT protocol comparison

<!-- Slide number: 25 -->

HTTP/ MQTT comparison

25

Most protocols fall into either of the following two categories:

Client/server, which is like HTTP.

Publish and subscribe, which is like MQTT.

When you design an IoT system, you must consider the protocol that you will use:

HTTP/1.1 is the most widespread protocol that is used for the web. It is limited for use with an IoT solution because it goes in one direction only, which is client to server. Also, the communication terminates when the request is fulfilled.

MQTT 3.1 is designed for IoT and its unreliable communication. Also, the device always initiates the outbound connection, which is inherently secure.

Ben Fradj Hanene

<!-- Slide number: 26 -->

HTTP/ MQTT comparison

26

These protocols do not replace each other and neither one is better than the other. The protocol that you use depends on your situation and device support.

MQTT is broadly supported by many libraries and providers.

Many open source and commercial brokers of MQTT are available, such as HiveMQ, Eclipse Mosquitto, IBM WebSphere MQ, and RabbitMQ.

There is also a customized version of MQTT that is provided by Watson IoT.

Ben Fradj Hanene

Notes:

Reference:

https://www.eclipse.org/paho/

<!-- Slide number: 27 -->

Next

27

HTTP

IOT plateforme

Ben Fradj Hanene

<!-- Slide number: 28 -->

Examples of IoT platforms

28

Consumer IoT platforms:

IBM Watson IoT Platform

Amazon Web Services (AWS) IoT Platform

Microsoft Azure IoT Platform

Google IoT Cloud Platform

Open-source IoT platforms

ThingsBoard

myDevices (Cayenne)

Blynk

Industry-based IoT platforms

IoT platforms for vehicles ( IoV)

IoT platforms for assets management

IoT platforms for agriculture

Ben Fradj Hanene