Chathuranga Dissanayaka

Embedded Systems Engineer

BSc (Hons) University of Moratuwa,
Electronics and Telecommunication Engineering
Network

Application
Transport
Network
Data Link
Physical
Application
Transport

Network
Data Link
Physical
 Network and Transport Layers

• Segmentation and Reassembly:

– Breaks data into smaller segments for transmission and reassembles them at the destination.

• End-to-End Communication:
– Ensures reliable communication between source and destination devices by establishing a connection-
oriented or connectionless service.

• Flow Control:
– Manages the rate of data transmission between sender and receiver to prevent network congestion or receiver
overload.

• Error Detection and Correction:

– Detects errors in the transmitted data and requests retransmission of corrupted segments.

• Multiplexing and Demultiplexing:

– Differentiates data streams from multiple applications on the same device and delivers them to the correct
application at the destination.
Network and Transport Layers
 Network and Transport Layers

• Routing:
– Determines the optimal path for data to travel from the source to the destination across multiple networks.

• Logical Addressing:
– Assigns IP addresses to devices and ensures that data packets are routed to the correct address in the network.

• Packet Forwarding:
– Forwards data packets from one network segment to another, ensuring they reach their destination.

• Fragmentation and Reassembly:

– Splits large data packets into smaller fragments to fit the size constraints of the network and reassembles them
at the destination.

• Error Handling and Diagnostics:

– Provides mechanisms for reporting network errors and status, such as through Internet Control Message
Protocol (ICMP).
Network and Transport Layers
 Application Protocols

• Message Queuing Telemetry Transport (MQTT):

• RESTful HTTP (REST):
• Data Distribution Service (DDS):
• Very Simple Control Protocol (VSCP):
• Extensible Messaging and Presence Protocol (XMPP):
• Constrained Application Protocol (CoAP):
• Advanced Message Queuing Protocol (AMQP):
• OMA LightweightM2M (LWM2M):
Application Protocols
Application Protocols
 Application Protocols → MQTT

• MQTT is a standards-based messaging protocol, or set of rules,

• used for machine-to-machine communication.
– Smart sensors, wearables, and other Internet of Things (IoT) devices
• typically have to transmit and receive data over a resource-constrained network with limited
bandwidth.
• MQTT supports messaging between devices to the cloud and the cloud to the device.
Application Protocols → MQTT
Application Protocols → MQTT
 Application Protocols → MQTT

Lightweight and efficient

• MQTT implementation on the IoT device requires minimal resources, so it can even be used on small microcontrollers. For example,
a minimal MQTT control message can be as little as two data bytes. MQTT message headers are also small so that you can
optimize network bandwidth.

Scalable
• MQTT implementation requires a minimal amount of code that consumes very little power in operations. The protocol also has built-
in features to support communication with a large number of IoT devices. Hence, you can implement the MQTT protocol to connect
with millions of these devices.

Reliable
• Many IoT devices connect over unreliable cellular networks with low bandwidth and high latency. MQTT has built-in features that
reduce the time the IoT device takes to reconnect with the cloud. It also defines three different quality-of-service levels to ensure
reliability for IoT use cases— at most once (0), at least once (1), and exactly once (2).

Secure
• MQTT makes it easy for developers to encrypt messages and authenticate devices and users using modern authentication
protocols, such as OAuth, TLS1.3, Customer Managed Certificates, and more.

Well-supported
• Several languages like Python have extensive support for MQTT protocol implementation. Hence, developers can quickly implement
it with minimal coding in any type of application.
 Application Protocols → MQTT

• Space decoupling
– The publisher and subscriber are not aware of each other’s network location and do not exchange information
such as IP addresses or port numbers.

• Time decoupling
– The publisher and subscriber don’t run or have network connectivity at the same time.

• Synchronization decoupling
– Both publishers and subscribers can send or receive messages without interrupting each other. For example,
the subscriber does not have to wait for the publisher to send a message.
 Application Protocols → MQTT

MQTT client
• An MQTT client is any device from a server to a microcontroller that runs an MQTT library. If the client is
sending messages, it acts as a publisher, and if it is receiving messages, it acts as a receiver. Basically, any
device that communicates using MQTT over a network can be called an MQTT client device.

MQTT broker
• The MQTT broker is the backend system which coordinates messages between the different clients.
Responsibilities of the broker include receiving and filtering messages, identifying clients subscribed to each
message, and sending them the messages. It is also responsible for other tasks such as:
– Authorizing and authenticating MQTT clients
– Passing messages to other systems for further analysis
– Handling missed messages and client sessions

MQTT connection
• Clients and brokers begin communicating by using an MQTT connection. Clients initiate the connection by
sending a CONNECT message to the MQTT broker. The broker confirms that a connection has been
established by responding with a CONNACK message. Both the MQTT client and the broker require a TCP/IP
stack to communicate. Clients never connect with each other, only with the broker.
 Application Protocols → MQTT

• Broker:
– A central server that manages message distribution. Devices publish messages to the broker, and the broker
ensures messages reach the right subscribers.

• Publisher:
– A device or application that sends messages to specific topics on the broker.

• Subscriber:
– A device or application that receives messages by subscribing to specific topics on the broker.

• Topic:
– A label that categorizes messages. Subscribers express their interest in specific topics to receive relevant
messages.
 Application Protocols → MQTT

MQTT defines three levels of QoS to provide different levels of message reliability. Each message can
independently set its own QoS when published.

QoS 0: delivers a message at most once and may be lost;

QoS 0 is the lowest level of service and is also known as "fire and forget". In this mode, the sender does not wait for acknowledgement or
store and retransmit the message, so the receiver does not need to worry about receiving duplicate messages.

QoS 1: delivers a message at least once and guarantees arrival, but may be duplicated;
To ensure message delivery, QoS 1 introduces an acknowledgement and retransmission mechanism. When the sender receives a
PUBACK packet from the receiver, it considers the message delivered successfully. Until then, the sender must store the PUBLISH
packet for potential retransmission.

QoS 2: delivers a message exactly once and guarantees arrival without duplication.
QoS 2 ensures that messages are not lost or duplicated, unlike in QoS 0 and 1. However, it also has the most complex interactions and
the highest overhead, as it requires at least two request/response flows between the sender and receiver for each message delivery.

As the QoS level increases, the complexity of message transmission also increases. You need to choose the
appropriate QoS level based on the actual scenario.
 Application Protocols → MQTT

Retained Message
• Unlike regular messages, retained messages can be stored on an MQTT server. When any
new subscriber subscribes to a topic that matches the topic of a retained message, they
immediately receive that message, even if it was published before they subscribed to the
topic.
• The retained message feature allows subscribers to receive data updates immediately upon
connecting, without having to wait for the publisher to re-publish the message. Retained
messages can be thought of as a message "cloud drive" in some ways: upload messages to
the "cloud drive" at any time, and retrieve messages from the "cloud drive" at any time.
However, this "cloud drive" is limited to storing only one latest retained message per topic.
 Application Protocols → MQTT

The feature of Pub/Sub pattern determines that no client, other than the server, is aware of a
client leaving the communication network. However, a will message provides the ability for a
disconnected client to notify other clients.

Clients can set their own will message with the server when they establish a connection, and
the server publishes this message immediately or after a specified delay if the client
disconnects unexpectedly. Clients subscribed to the corresponding will message topic will
receive this message and take appropriate action, such as updating the online status of that
client, etc.
Application Protocols
Application Protocols → RESTfull
 Application Protocols → RESTfull

• URL endpoint:
– Is a URL link that represents the resources we want to access. Resources can be text, images, documents or any
data entry. For example, example.com/surveys allows us to view or create survey templates and example.com/surveys/123/responses allows
us to do the same for all responses of survey 123.

• HTTP verb:
– Tells the server what we want to do with the URL endpoint resource. For example, a POST request means we want
to create a new survey template and a GET request means we want to view an existing survey template.

• Body message:
– Is an optional custom payload which contains a message with the properties and values we want to use to create
or update a given resource.

• Status Code:
– Upon receiving a HTTP request in the basic RESTful format the server will return a HTTP status code along with
any optional JSON payloads. Here are the most common HTTP status codes and their meaning:
 Application Protocols → RESTfull

• GET:
– make a read only request to view either a single or list of multiple resources

• POST:
– create a new resource based on the payload given in the body of the request

• DELETE:
– destroy the given resource based on the id provided

• PUT:
– update the entire fields of the resource based on the given body of the request or create a new one if not already
exist

• PATCH:
– update only the fields of the resource if it exists
Application Protocols → RESTfull
 Application Protocols → RESTfull

• GET:
– make a read only request to view either a single or list of multiple resources

• POST:
– create a new resource based on the payload given in the body of the request

• DELETE:
– destroy the given resource based on the id provided

• PUT:
– update the entire fields of the resource based on the given body of the
request or create a new one if not already exist

• PATCH:
– update only the fields of the resource if it exists
Application Protocols → RESTfull
Application Protocols
 Application Protocols → CoAP

• CoAP stands for Constrained Application Protocol. It’s a bit of a mouthful, but don’t worry; I’ll
break it down. Imagine you have a tiny computer, like the one inside a temperature sensor or a
light bulb. These little computers have very little power and memory, so they can’t speak the
same way our laptops or phones do. They need a special language, and that’s where CoAP
comes in.

• CoAP is like a tiny, efficient messenger. It sends very short messages, almost like text
messages, to tell other devices what it wants to do or what it needs to know. It’s excellent for
small, low-power devices because it doesn’t use much energy or memory.
 Application Protocols → CoAP

• Lightweight:
– CoAP minimizes overhead, making it efficient for small, low-power devices.

• UDP-based:
– CoAP uses the User Datagram Protocol (UDP) for communication, which is faster and consumes fewer resources
than TCP (Transmission Control Protocol).

• RESTful:
– It follows the principles of Representational State Transfer (REST), simplifying interactions with IoT resources.

• Scalable:
– CoAP can scale from small, local networks to the internet.

• Resource Discovery:
– Devices can discover and interact with resources on other devices using CoAP.

• Multicast Support:
– CoAP supports one-to-one, one-to-many, and many-to-one communication patterns.
 Application Protocols → CoAP

1. Client Request:
– A CoAP client sends a request to a CoAP server. The request includes a method (e.g., GET, POST, PUT, DELETE)
and a Uniform Resource Identifier (URI) indicating the resource the client wants to access.

2. Server Response:
– The CoAP server processes the request and sends a response back to the client. The response contains the
requested data or status information.

3. Message Format:
– CoAP messages are compact, consisting of a header and optional payload. This lightweight format is suitable for
low-bandwidth networks.

4. Observing Resources:
– CoAP supports resource observation, allowing clients to receive notifications when a resource’s state changes.
Application Protocols
Application Protocols
Application Protocols

Aspect REST CoAP

General-purpose protocol
Purpose Lightweight for IoT devices
for web services
UDP with optional
Transport Protocol HTTP over TCP
reliability
Message Format JSON/XML Binary format

Security HTTPS (TLS over TCP) DTLS (TLS over UDP)

Request-response and
Communication Model Request-response model
observe models
• https://www.emqx.com/en/blog/esp32-connects-to-the-free-
public-mqtt-broker
• https://iotboys.com/what-is-coap-protocol-coap-vs-mqtt-
comparison/#What_is_CoAP_Protocol
• https://www.wallarm.com/what/coap-protocol-definition