CH 4 Edge To Cloud Protocol

Edge to Cloud
Protocols
Dr. Ashish Vanmali
Outline of the Chapter
❖Web-based Application Layer Protocols

▪ HTTP
▪ WebSocket
❖IoT Application Layer Protocols
▪ CoAP
▪ MQTT
▪ MQTT-SN
▪ STOMP
▪ AMQP
Dr. Ashish Vanmali, VCET, Vasai 2

Application Layer Protocols
▪ Application layer protocols are classified in two categories:
• Web-based Application Layer Protocols
• IoT Application Layer Protocols
▪ Web-based Application Layer Protocols, as the name suggest, these protocols are
designed for web-based applications.
▪ IoT application layer protocols are devised to run on constrained nodes with a small
compute footprint and are well adapted to the network bandwidth constraints.
Web-based Application Layer IoT Application Layer
Protocols Protocols
• HTTP • CoAP
• WebSocket • MQTT

HTTP
❖HTTP = Hyper Text Transfer Protocol

▪ Web pages use HTTP protocol to exchange data.
▪ HTTP is a text-based protocol.
▪ It operates at the application layer and conforms to RESTful principles.
▪ It can be used with IoT devices even when there is no web page present.
Ref: Andrew Minteer, Analytics

for the Internet of Things (IoT) -
Intelligent Analytics for Your
Intelligent Devices
HTTP
❖HTTP and IoT:

▪ HTTP is not designed for IoT. However, it is a mature standard and in wide use. This
makes it an established and well supported interface.
▪ The latency is not predictable in HTTP, and it often depends on polling to detect state
changes.
▪ HTTP is a text-based protocol, which means message size tends to be large. This adds
power needs and complexity overhead, for IoT devices to communicate using it.
▪ Connections are established from a client device to a server device and remain open
until the communication is completed.
▪ Delivery is guaranteed and data message receipts are acknowledged at every step of
the process.

HTTP
❖Communication with HTTP:

▪ Clients and servers communicate using HTTP
▪ Client and server establish TCP connection
▪ Client requests content
▪ Server responds with requested content
▪ Client and server close connection (usually)
HTTP request
Web
Web
client
server
(browser)
HTTP response
(content)

HTTP
❖Methods of adding HTTP support to sensor:

1. The sensor is a client who publishes information to a server on the Internet. The
server acts as a broker and informs the interested parties about the sensor values.
This pattern is called publish/subscribe.
2. All the entities in the network be both clients and servers, depending on what they
need to do.
3. The sensor becomes the HTTP server, and anybody interested in knowing the status
of the sensor becomes the client. (Most preferred method)
❖ Method of adding HTTP support to controller:
1. The controller acts as a HTTP client. It uses HTTPSocketClient class to access
the web resources provided by the sensor.

HTTP
❖HTTP REST API:

▪ It assumes interactions are client/server-based and are stateless.
▪ Key commands supported by the HTTP REST API Interface:
• HTTP POST: Adds a new resource
• HTTP PUT: Updates a specific resource by replacing it with an updated version
• HTTP GET: Reads a specified resource
• HTTP PATCH: Partially updates a resource in a collection
• HTTP DELETE: Deletes a resource

HTTP
❖Advantages to HTTP:
▪ Reliability: Message delivery is guaranteed and acknowledged.
▪ Ubiquity: HTTP is used all over the place and is very easy to implement.
▪ Ease of implementation: If you can connect to the internet, you can use HTTP
anywhere in the world. No special hardware or software is required.
❖Disadvantages to HTTP:
▪ Higher power needs: Communications have frequent back and forth interactions,
connections need to be sustained, and plain text results in larger message sizes. All of
this requires more power to support.
▪ The IoT device complexity: The device needs enough memory and CPU power to
support the TCP protocol and high level HTTP RESTful APIs.
WebSocket
▪ WebSocket is a bi-directional communication protocol which has emerged recently
with the introduction of HTML5.
▪ WebSocket protocol is not just an enhancement of the current HTTP protocol; it is
enormously advanced, especially for real-time, event-driven communication.
▪ WebSocket is a low-latency (real-time), full-duplex (bidirectional), long-running
(persistent), single connection (TCP) between a client and server.
▪ WebSockets provide a huge benefit for real-time, event-driven web applications.
▪ It is used for real-time data updates and synchronization, live text chat, video
conferencing, VOIP, IoT control and monitoring.
▪ These capabilities enable apps in gaming, social networks, logistics, finance and
home, vehicle and industrial automation etc.

WebSocket
Ref:
https://www.hcltech.com/site
s/default/files/images/inline-
migration/images/html5.jpg
WebSocket
❖Connect with HTTP-Compatibility:

▪ WebSocket protocol was designed to work well with the legacy web infrastructure.
▪ It uses an HTTP-compatible handshake to establish a connection between the client
and server.
▪ The process to start a WebSocket connection begins with the client sending an HTTP
GET with the WebSocket “Upgrade” field.
▪ After a connection is initialized, communication switches to a bidirectional binary
protocol unlike the HTTP protocol.
▪ If the server supports WebSockets, it responds with a HTTP UPGRADE response.
▪ TCP socket used for the HTTP communication is recycled to be used for the
WebSocket connection, and either party can begin sending data.
▪ WebSockets use the same ports as HTTP – 80 for HTTP, and 443 for HTTPS.
WebSocket
Ref:
https://blog.scaleway.com/co
ntent/images/2021/02/webso
ckets-bigger-4.png
WebSocket
❖Advantages to WebSocket:
▪ Bidirectional:
• HTTP relies on a client request to receive a response from the server for every
exchange.
• WebSockets allow for full-duplex bidirectional communication. This enables the
server to send real-time updates asynchronously, without requiring the client to
submit a request each time.
▪ Persistent:
• Rather than establishing and terminating the connection for each client request and
server response, WebSockets allow for a persistent client-server connection.
• After an initial HTTP “handshake,” the connection is kept alive using a “ping-pong”
process, in which the server continuously pings the client for a response.
• The server only terminates this connection after an explicit request from the client,
or implicitly when the client goes offline.
WebSocket
▪ Low Latency:
• By eliminating the need for a new connection with every request, WebSockets
greatly reduce the data size of each message, drastically decreasing latency.
• After the initial handshake, which includes standard HTTP header information, all
subsequent messages include only relevant information.
▪ Extensible:
• Flexibility is ingrained into the philosophy and design of the WebSocket protocol,
enabling the implementation of subprotocols and extensions for additional
functionality.
• Currently, the WebSocket API supports over 40 subprotocols such as WAMP, XMPP,
AMQP and MQTT, as well as extensions that enable powerful functionality like
multiplexing and data compression. This makes WebSockets a highly adaptable.
WebSocket
▪ Secure:
• The WebSocket Secure (WSS) protocol uses standard SSL and TLS encryption to
establish a secure connection between the client and server.
• Using a mutually agreed-upon authorization and authentication system, the client
and server can safely exchange encrypted WebSocket messages, which is critical in
sensitive government, military and corporate applications.
• While unsecured WebSockets uses TLS port number 80, WSS uses port 443.

WebSocket
❖Disadvantages to WebSocket:
▪ WebSocket requires a TCP implementation, which may or may not be a problem, but
it also requires an HTTP implementation for the initial connection setup.
▪ Additionally, WebSocket was not designed with the requirements of highly
constrained embedded systems in mind, so implementations may not be
straightforward.

WebSocket v/s REST
The basis of
WebSocket REST
Comparison
The use of HTTP occurs in the initial HTTP is a common protocol in RESTful web
HTTP
connection. services.
Communication Bi-directional in nature. Uni-directional in nature.
Resources based concept, rather than
Nature Socket-based concept.
commands.
Scenario Real-time chat application. Lots of getting request.
Based on the HTTP protocol and uses HTTP
Dependency Rely on IP address and port number.
methods to relay data.
The cost of communication is comparatively
Cost The cost of communication is lower.
higher than WebSocket.
Performance Better with high loads. Great for occasional communication.
REST is based on HTTP, which is a stateless
State WebSocket is a stateful protocol.
protocol.
IoT Application Layer Protocols
▪ When considering constrained networks and/or a large-scale deployment of
constrained nodes, web-based and data model protocols like HTTP or WebSocket may
be too heavy for IoT applications.
▪ To address this problem, the IoT industry focuses on lightweight protocols that are
better suited to large numbers of constrained nodes and networks.
▪ Two of the most popular protocols are CoAP and MQTT.
Ref: David Hanes et al., IoT

Fundamentals Networking
Technologies, Protocols, and Use
Cases for the Internet of Things
CoAP
❖CoAP = Constrained Application Protocol

▪ CoAP is a lightweight version of HTTP defined by IETF in the Constrained RESTful
Environments (CoRE) standard.
▪ CoAP has been designed to with resource-constrained devices with as low as 10 kB of
RAM and 100 kB of code space.
▪ It is UDP based with small headers (<10 bytes).
▪ It suits the RESTful programming approach and works according to the client-server
paradigm.
▪ Supports block transfer, proxy, caching, resource discovery.

CoAP
❖CoAP Architecture:
Ref:
https://www.wallarm
.com/what/coap-
protocol-definition
CoAP
❖CoAP Architecture:
▪ The Internet and the constraints ecosystem are the 2 foundational elements of the
CoAP protocol architecture.
▪ Here, the server monitors and helps in communication happening using CoAP and
HTTP while proxy devices bridge the existing gap for these 2 ecosystem, making the
communication smoother.
▪ CoAP allows CoAP clients exchange data/information with each other within resource
constraints.
▪ The server provides resources identified by the URIs. The client communicates with a
server with a known, predefined address.
▪ CoAP offers 7 PDU types, i.e., 4 request methods (GET, POST, PUT, DELETE) and the
response, acknowledgement, reset messages.
CoAP
❖CoAP Message Format:
Ref: David Hanes et al.,

IoT Fundamentals
Networking Technologies,
Protocols, and Use Cases
for the Internet of Things
CoAP

▪ CoAP message is composed of a short fixed length Header field (4 bytes), a variable-
length but mandatory Token field (0–8 bytes), Options fields if necessary, and the
Payload field.
CoAP Message Field Description
Ver (Version) Identifies the CoAP Version
T (Type) Defines message type: Confirmable (CON), Non-confirmable (NON),
Acknowledgement (ACK) or Reset (RST)
TKL (Token Length) Specifies the size of the token field (0-8 bytes)
Code Indicates the request method for a request message and a response code for a
response message.

CoAP

CoAP Message Field Description
Message ID Detects message duplication and used to match ACK and RST message types to
CON and NON message types.
Token With the length specified by TKL, correlates requests and responses.
Options Specifies option number, length and option values.
Capabilities provided the Options field include specifying the target resources of a
request and proxy functions.
Payload Carries the CoAP application data.
This field is optional, but when it is present, a single byte of all 1s (0xFF) precedes
the payload. The purpose of this byte is to delineate the end of the Options field
and the beginning of the Payload.

CoAP

▪ While running over UDP, CoAP offers a reliable transmission of messages when a
CoAP header is marked as “confirmable.”
▪ In addition, CoAP supports basic congestion control with a default time-out, simple
stop and wait retransmission with exponential back-off mechanism, and detection of
duplicate messages through a message ID.
▪ If a request or response is tagged as “confirmable,” the recipient must explicitly either
acknowledge or reject the message, using the same message ID.
▪ If a recipient can’t process a non-confirmable message, a reset message is sent.

CoAP
❖CoAP Communication Example:
▪ CoAP is used to adjust the brightness of the light using POST command
Ref: IoT
Fundamentals
Bootcamp,
Cisco 2019
CoAP
❖CoAP Communication Example:
▪ CoAP is used to adjust the brightness of the light
Ref: IoT
Fundamentals
Bootcamp,
Cisco 2019
CoAP
❖Advantages of CoAP:
▪ Reduced power requirements: It operates over UDP, which requires minimal
overhead for communications. It also allows faster wake up times and extended
sleepy states. Taken together, this means batteries last longer for IoT devices.
▪ Smaller packet size: Another advantage of UDP is small packet sizes. This leads to
faster communication cycles. Again, this allows batteries to last longer.
▪ Security: When Datagram Transport Layer Security (DTLS) is employed over UDP,
communication is encrypted and secure. (Note that it is optional)
▪ Asynchronous communication option: Clients can request to observe a device by
setting a flag. The server (IoT device) can then stream state changes to the client as
they happen. Either side can cancel the observe request.
▪ IPv6 based: It was designed from the beginning to support IPv6. This also allows for a
multicasting option.
▪ Resource discovery: Servers can provide a list of resources and media types. The
client can then review and discover what is available.
CoAP
❖Disadvantages of CoAP:
▪ Message unreliability: UDP does not guarantee the delivery of datagrams. CoAP adds
a method to request a confirmation acknowledgement to confirm the message was
received. This does not verify that it was received in its entirety and decoded
properly.
▪ Standards are still maturing: CoAP is still evolving, although there is a lot of market
momentum behind it. It is likely to mature quickly as use becomes more widespread.
▪ NAT issues: Network Address Translation (NAT) devices are commonly used in
enterprise networks and cloud environments. CoAP can have problems
communicating with devices behind a NAT since the IP can be dynamic over time.
▪ Security: CoAP is unencrypted by default. This makes it natively unsecure and you
need to take additional steps to make sure communication is not open to hackers.

MQTT
❖MQTT = Message Queuing Telemetry Transport

▪ MQTT is an open standard maintained by OASIS.
▪ The MQTT paradigm is publish-subscribe with a broker.
▪ Publishers and subscribers act as clients, while the broker acts as a server.
▪ The broker handles the subscription and unsubscription process for the topic and
pushes the application data to MQTT clients acting as subscribers.
▪ The topics are organized in a hierarchical structure.
▪ The broker can delete a message sent to all subscribers of the given topic; it can also
delete a message if there is no subscriber.

MQTT
❖MQTT Publish/Subscribe Framework:

IoT Fundamentals
MQTT
▪ The clients can subscribe to all data (using a wildcard character) or specific data from
the information tree of a publisher.
▪ In addition, the presence of a message broker in MQTT decouples the data
transmission between clients acting as publishers and subscribers.
▪ In fact, publishers and subscribers do not even know (or need to know) about each
other.
▪ A benefit of having this decoupling is that the MQTT message broker ensures that
information can be buffered and cached in case of network failures.
▪ This also means that publishers and subscribers do not have to be online at the same
time.

MQTT
❖MQTT Message Format:

▪ MQTT control packets run over a TCP transport using port 1883.
▪ TCP ensures an ordered, lossless stream of bytes between the MQTT client and the
MQTT server.
▪ Optionally, MQTT can be secured using TLS on port 8883, and WebSocket (defined in
RFC 6455) can also be used.

MQTT

IoT Fundamentals
MQTT

▪ MQTT is a lightweight protocol because each control packet consists of a 2- byte fixed
header with optional variable header fields and optional payload.
▪ A control packet can contain a payload up to 256 MB.
▪ MQTT contains a smaller header of 2 bytes (compared to 4 bytes for CoAP).

MQTT

Header Field Description
Message Type • Identifies the kind of MQTT packet within a message
DUP (Duplication Flag) • This flag, when set, allows the client to notate that the packet has been
sent previously, but an acknowledgement was not received.
QoS • Allows for the selection of three different QoS levels
Retain flag • Only found in a PUBLISH message.
• The Retain flag notifies the server to hold onto the message data.
• This allows new subscribers to instantly receive the last known value
without having to wait for the next update from the publisher.
Remaining Length • This field specifies the number of bytes in the MQTT packet following this
field.
MQTT

▪ Fourteen different types of control packets are specified in MQTT. Each of them has a
unique value that is coded into the Message Type field.
Message Type Value Flow Description
CONNECT 1 Client to server Request to connect
CONNACK 2 Server to client Connect acknowledgement
PUBLISH 3 Client to server Publish message
Server to client
PUBACK 4 Client to server Publish acknowledgement
Server to client
PUBREC 5 Client to server Publish received
Server to client
PUBREL 6 Client to server Publish release
Server to client
MQTT

Message Type Value Flow Description
PUBCOMP 7 Client to server Publish complete
Server to client
SUBSCRIBE 8 Client to server Subscribe request
SUBACK 9 Server to client Subscribe acknowledgement
UNSUBSCRIBE 10 Client to server Unsubscribe request
UNSUBACK 11 Server to client Unsubscribe acknowledgement
PINGREQ 12 Client to server Ping request
PINGRESP 13 Server to client Ping response
DISCONNECT 14 Client to server Client disconnect
(Note that values 0 and 15 are reserved)
MQTT
❖QoS in MQTT:
▪ The MQTT protocol offers three levels of quality of service (QoS).
▪ QoS for MQTT is implemented when exchanging application messages with publishers
or subscribers, and it is different from the IP QoS.
Level of QoS Description
QoS 0 • This is a best-effort and unacknowledged data service referred to as “at
most once” delivery.
• The publisher sends its message one time to a server, which transmits it
once to the subscribers.
• No response is sent by the receiver, and no retry is performed by the
sender.
• The message arrives at the receiver either once or not at all.
MQTT
❖QoS in MQTT:
QoS 1 • This QoS level ensures that the message delivery between the publisher
and server and then between the server and subscribers occurs at least
once.
• In PUBLISH and PUBACK packets, a packet identifier is included in the
variable header. If the message is not acknowledged by a PUBACK packet, it
is sent again.
• This level guarantees “at least once” delivery.

MQTT
❖QoS in MQTT:
QoS 2 • This is the highest QoS level, used when neither loss nor duplication of
messages is acceptable.
• There is an increased overhead associated with this QoS level because
each packet contains an optional variable header with a packet identifier.
• Confirming the receipt of a PUBLISH message requires a two-step
acknowledgement process.
• The first step is done through the PUBLISH/PUBREC packet pair, and the
second is achieved with the PUBREL/PUBCOMP packet pair.
• This level provides a “guaranteed service” known as “exactly once”
delivery, with no consideration for the number of retries as long as the
message is delivered once.
MQTT
❖QoS in MQTT:

IoT Fundamentals
MQTT
❖QoS in MQTT:

IoT Fundamentals
MQTT
❖QoS in MQTT:

IoT Fundamentals
MQTT
❖Advantages to MQTT:
▪ Packet agnostic: Any type of data can be transported in the payload carried by the
packet as long as the receiving party knows how to interpret it.
▪ Reliability: Offers Quality of Service (QoS) options that can be used to guarantee
delivery.
▪ Scalability: The publish/subscribe model scales well in a power-efficient way.
▪ Decoupled design: There are several elements to the design that decouple the device
and the subscribing server, which result in a more robust communication strategy.
▪ Time: A device can publish its data regardless of the state of the subscribing server.
The subscribing server can then connect and receive the data when it is able. This
decouples the two ends of the communication on a time basis.

MQTT
❖Advantages to MQTT:
▪ Space (delivery details): It also allows both ends to operate independently. The
subscriber can be changed or upgraded and additional subscribers added with no
change needed on the publishing device end.
▪ Synchronizing: The process is asynchronous. There is no need to interrupt work in
progress to publish a message.
▪ Bidirectional: A device can be both a publisher and a subscriber. In this way, it can
receive commands by subscribing to a topic on the broker. It could also receive data
from other devices that could be an input into the data it publishes.

MQTT
❖Disadvantages to MQTT:
▪ It operates over TCP: TCP requires more handshaking to set up communication links
before any messages can be exchanged. This increases wake-up and communication
times, which affects the long-term battery consumption. TCP connected devices tend
to keep sockets open for each other with a persistent session. This adds to power and
memory requirements.
▪ Centralized broker can limit scale: The broker can affect scalability as there is
additional overhead for each device connected to it. The network can only grow as
large as the local broker hub can support it. This puts a limit on expansion for each
hub and spoke group.
▪ Broker single point of failure: The failure of broker brings the entire network down.
▪ Security: MQTT is unencrypted by default. This makes it natively unsecured and
requires you to take additional steps and absorb some overhead to make sure TLS/SSL
is implemented.
CoAP v/s MQTT
Ref:
https://www.wallarm
.com/what/coap-
protocol-definition
CoAP v/s MQTT
CoAP MQTT
Uses UDP as main transport protocol Uses TCP as main transport protocol
Based on request – response model Based on publish – subscribe model
Message dispatching happens on a unicasting basis Central broker handles message dispatching,
(one-to-one). The process is same as HTTP. following the optimal publisher to client path.
Communication model is one-to-one Communication model is many-to-many
It uses asynchronous and synchronous messaging. It uses only asynchronous mode for messaging.
Viable for state transfer Suitable for event-oriented operations
It defines messages properly using labels and makes No message labeling but have to use diverse
its discovery easy. messages for different purposes.
Effectiveness in LLN (Low power Lossy Networks) is Effectiveness in LLN (Low power Lossy Networks) is
excellent. low.
CoAP v/s MQTT
CoAP MQTT
Security is provided through DTLS (Datagram Security is not defined. It is provided through SSL
Transport Layer Security) (Secure Sockets Layer) / TLS (Transport Layer Security)
encryption
It has 4 bytes sized header It has 2 bytes sized header
It is RESTful based. It is not RESTful based.
It does not have persistence support. It is mainly used for live communication and has
persistence support.
Power consumption is lower than MQTT Power consumption is higher than CoAP
Reliability is provided through Confirmable messages, Provides reliability through 3 Quality of service levels
Non-confirmable messages, Acknowledgements, and viz., QoS 0: Delivery not guaranteed, QoS 1: Delivery
Retransmissions confirmation, QoS 2: Delivery double confirmation
MQTT-SN
❖MQTT-SN = MQTT for Sensor Networks

▪ MQTT-SN is a publish/subscribe messaging protocol for WSN, with the aim of
extending the MQTT protocol beyond the reach of TCP/IP infrastructure for Sensor
and Actuator solutions.
▪ MQTT-SN is optimized for implementation on low-cost, battery-operated devices with
limited processing and storage resources.

MQTT-SN
❖MQTT-SN v/s MQTT:

1. The CONNECT message is split into three messages. The two additional ones are
optional and used to transfer the Will topic and the Will message to the server.
2. To cope with the short message length and the limited transmission bandwidth in
wireless networks, the topic name in the PUBLISH messages is replaced by a short,
two-byte long “topic id”.
3. “Pre-defined” topic ids and “short” topic names are introduced, for which no
registration is required. They are known in advance by both the client’s application
and the gateway/server. Therefore, both sides can start using pre-defined topic ids;
there is no need for a registration.
4. A discovery procedure helps clients without a pre-configured server/gateway’s
address to discover the actual network address of an operating server/gateway.
Multiple gateways may be present at the same time within a single wireless network
andVCET,
Dr. Ashish Vanmali, can
Vasaico-operate in a load-sharing or stand-by mode. 53
MQTT-SN
❖MQTT-SN v/s MQTT:

5. The semantic of a “clean session” is extended to the Will feature, i.e. not only client’s
subscriptions are persistent, but also Will topic and Will message. A client can also
modify its Will topic and Will message during a session.
6. A new offline keep-alive procedure is defined for the support of sleeping clients.
With this procedure, battery-operated devices can go to a sleeping state during
which all messages destined to them are buffered at the server/gateway and
delivered later to them when they wake up.

MQTT-SN
❖MQTT-SN Architecture:
Ref: https://www.oasis-
open.org/committees/do
wnload.php/66091/MQTT
-SN_spec_v1.2.pdf
MQTT-SN
❖MQTT-SN Architecture:
▪ There are three kinds of MQTT-SN components, MQTT-SN clients, MQTT-SN gateways
(GW), and MQTT-SN forwarders.
▪ MQTT-SN clients connect themselves to a MQTT server via a MQTT-SN GW using the
MQTT-SN protocol. A MQTT-SN GW may or may not be integrated with a MQTT
server.
▪ In case of a stand-alone GW the MQTT protocol is used between the MQTT server and
the MQTT-SN GW. Its main function is the translation between MQTT and MQTT-SN.
▪ MQTT-SN clients can also access a GW via a forwarder in case the GW is not directly
attached to their network.
▪ The forwarder simply encapsulates the MQTT-SN frames it receives on the wireless
side and forwards them unchanged to the GW; in the opposite direction, it
decapsulates the frames it receives from the gateway and sends them to the clients,
unchanged
Dr. Ashish Vanmali, VCET, Vasai too. 56
MQTT-SN
❖Transparent and Aggregating Gateways:

▪ Depending on how a GW performs the protocol translation between MQTT and
MQTT-SN, we can differentiate between two types of GWs, namely transparent and
aggregating GWs.
MQTT-SN MQTT-SN
MQTT
MQTT
Broker Broker
Ref: https://www.oasis-
open.org/committees/do Clients Clients
wnload.php/66091/MQTT Transparent Aggregating
-SN_spec_v1.2.pdf GW GW
MQTT-SN

▪ Transparent Gateway:
• For each connected MQTT-SN client, a transparent GW will setup and maintain a
MQTT connection to the MQTT server.
• This MQTT connection is reserved exclusively for the end-to-end and almost
transparent message exchange between the client and the server.
• There will be as many MQTT connections between the GW and the server as MQTT-
SN clients connected to the GW.
• The transparent GW will perform a “syntax” translation between the two protocols.
• Since all message exchanges are end-to-end between the MQTT-SN client and the
MQTT server, all functions and features that are implemented by the server can be
offered to the client.
MQTT-SN

▪ Aggregating Gateway:
• Instead of having a MQTT connection for each connected client, an aggregating GW
will have only one MQTT connection to the server.
• All message exchanges between a MQTT-SN client and an aggregating GW end at
the GW. The GW then decides which information will be given further to the server.
• Although its implementation is more complex than the one of a transparent GW, an
aggregating GW may be helpful in case of WSNs with very large number of clients
because it reduces the number of MQTT connections that the server has to support
concurrently.

STOMP
❖STOMP = Streaming Text Oriented Messaging Protocol

▪ STOMP is a frame based protocol, with frames modelled on HTTP and works over TCP.
▪ A frame consists of a command, a set of optional headers and an optional body.
▪ STOMP is text based but also allows for the transmission of binary messages.
▪ The default encoding for STOMP is UTF-8 Unicode standard, but it supports the
specification of alternative encodings for message bodies.

STOMP
❖STOMP Frame:
▪ Communication between Client-Server is through a “frame” consisting of a number of
lines.
▪ The first line contains the command, followed by headers in the form <key>: <value>
(one per line), followed by a blank line and then the body content, ending in a null
character.
COMMAND
header1:value1
header2:value2
Body^@
▪ Communication between server and client is through a MESSAGE, RECEIPT or ERROR

frame with a similar format of headers and body content.
STOMP
❖STOMP Frame:
▪ The protocol uses following commands:
• CONNECT
• SEND
• SUBSCRIBE
• UNSUBSCRIBE
• BEGIN
• COMMIT
• ABORT
• ACK
• NACK
• DISCONNECT
STOMP
❖CONNECT:
▪ A STOMP client initiates the stream or TCP connection to the server by sending the
CONNECT frame.
CONNECT
accept-version:1.2
host:stomp.github.org
^@
▪ If the server accepts the connection attempt, it will respond with a CONNECTED
frame.
CONNECTED
version:1.2
^@

STOMP
❖CONNECT:
▪ The server can reject any connection attempt. The server should respond back with
an ERROR frame explaining why the connection was rejected and then close the
connection.
ERROR
version:2.0
content-type:text/plain
^@

STOMP
❖CONNECT:
Protocol Negotiation:
▪ The CONNECT frame must include the accept-version header. It should be set
to a comma separated list of incrementing STOMP protocol versions that the client
supports.
CONNECT
accept-version:1.0,1.1,2.0
host:stomp.github.org
^@
▪ The protocol that will be used for the rest of the session will be the highest protocol
version that both the client and server have in common.

STOMP
❖CONNECT:
Protocol Negotiation:
▪ The server will respond back with the highest version of the protocol that it has in
common with the client.
CONNECTED
version:1.1
^@
▪ If the client and server do not share any common protocol versions, then the server
must respond with an ERROR frame.
ERROR
version:1.2,2.1
^@
STOMP
❖SEND:
▪ The SEND frame sends a message to a destination in the messaging system.
▪ It has one required header is destination , which indicates where to send the
message.
▪ The body of the SEND frame is the message to be sent.
SEND
destination:/queue/a
hello destination
^@

STOMP
❖SUBSCRIBE:
▪ The SUBSCRIBE frame is used to register to listen to a given destination.
▪ Like the SEND frame, the SUBSCRIBE frame requires a destination header
indicating the destination to which the client wants to subscribe.
▪ Any messages received on the subscribed destination will henceforth be delivered as
MESSAGE frames from the server to the client.
▪ The ack header controls the message acknowledgment mode.
▪ If the server cannot successfully create the subscription, the server must send the
client an ERROR frame and then close the connection.
SUBSCRIBE
id:0
destination:/queue/foo
ack:client
^@
STOMP
❖SUBSCRIBE:
▪ An id header must be included in the frame to uniquely identify the subscription.
▪ Within the same connection, different subscriptions must use different subscription
identifiers.
▪ The valid values for the ack header are auto, client, or client-individual.
▪ If the header is not set, it defaults to auto. Here the client does not need to send the
server ACK frames for the messages it receives.
▪ In client, the client must send the server ACK frames for the messages it
processes.
▪ In client-individual, the acknowledgment operates just like the client
acknowledgment mode except that the ACK or NACK frames sent by the client are
not cumulative. This means that an ACK or NACK frame for a subsequent message
must not cause a previous message to get acknowledged.
▪ In case the client did not process some messages, it should send NACK frames to tell
the server
Dr. Ashish Vanmali, VCET, Vasai it did not consume these messages. 69
STOMP
❖UNSUBSCRIBE:
▪ The UNSUBSCRIBE frame is used to remove an existing subscription.
▪ Once the subscription is removed the STOMP connections will no longer receive
messages from that subscription.
▪ An id header must be included in the frame to uniquely identify the subscription to
remove. This header must match the subscription identifier of an existing
subscription.
UNSUBSCRIBE
id:0
^@

STOMP
❖ACK:
▪ ACK is used to acknowledge consumption of a message from a subscription using
client or client-individual acknowledgment.
▪ The ACK frame must include an id header matching the ack header of the MESSAGE
being acknowledged.
▪ Optionally, a transaction header may be specified, indicating that the message
acknowledgment should be part of the named transaction.
ACK
id:12345
transaction:tx1
^@

STOMP
❖NACK:
▪ NACK is used to tell the server that the client did not consume the message.
▪ NACK takes the same headers as ACK.
NACK
id:12345
transaction:tx1
^@

STOMP
❖BEGIN:
▪ BEGIN is used to start a transaction.
▪ The transaction header is required, and the transaction identifier will be used for
SEND, COMMIT, ABORT, ACK, and NACK frames to bind them to the named
transaction.
▪ Within the same connection, different transactions must use different transaction
identifiers.
BEGIN
transaction:tx1
^@

STOMP
❖COMMIT:
▪ COMMIT is used to commit a transaction in progress.
COMMIT
transaction:tx1
^@
❖ABORT:
▪ ABORT is used to roll back a transaction in progress.
ABORT
transaction:tx1
^@

STOMP
❖DISCONNECT:
▪ DISCONNECT is used to stop a transaction.
▪ To ensure that the previously sent frames have been received by the server, a three
step process is followed:
1. Send a DISCONNECT frame with a receipt header set.
DISCONNECT
receipt:77
^@
2. Wait for the RECEIPT frame response to the DISCONNECT.

RECEIPT
receipt-id:77
^@
3. Close the socket.

AMQP
❖AMQP = Advanced Message Queuing Protocol

▪ AMQP is an open source published standard for asynchronous messaging by wire.
▪ AMQP enables encrypted and interoperable messaging between organizations and
applications.
▪ Key Capabilities of AMQP:

AMQP connects across:
• Organizations – applications in different organizations
• Technologies – applications on different platforms
• Time – systems don’t need to be available simultaneously
• Space – reliably operate at a distance, or over poor networks

AMQP
❖Working of AMQP:
▪ AMQP uses publish-subscriber model.
Ref:
https://support.smart
bear.com/readyapi/do
cs/testing/amqp.html
AMQP
❖Working of AMQP:
▪ In AMQP, applications that send messages (known as publishers) to AMQP brokers
that distribute them to applications that process messages (consumers).
▪ The internal structure or an AMQP broker includes three types of entities: exchanges,
queues and bindings.
▪ Messages posted to a broker first go to an exchange.
▪ Then, the exchange will route the message to a queue that is bound to the exchange
using special rules called bindings.
▪ Each exchange can have zero or more queues bound to it.
▪ Lastly, consumers will receive the messages from the queue (they can be subscribed
to it, or the user can fetch the messages manually).

AMQP
❖Message Routing:
▪ Both bindings and messages contain strings called routing keys that the broker uses
to decide where to route the message.
▪ The mode of routing messages from an exchange to a queue is based on the type of
the exchange.
▪ The routing keys of messages sent to a topic exchange must be a list of dot-separated
words. For examples:
office.server.test
office.server.update
office.client.test

AMQP
❖Message Routing:
▪ There are four types of exchanges:
• Direct: Direct exchanges route messages to queues that are bound to them if the
binding routing key is identical to the message routing key.
• Fanout: Fanout exchanges route messages to all the queues that are bound to
them. The message routing key is ignored.
• Topic: Topic exchanges route messages to bound queues if the message routing key
matches the pattern specified in the binding routing key.
• Headers: Headers exchanges route messages to bound queues based on multiple
attributes expressed as message headers rather that the routing key.

AMQP
❖Benefits of Using AMQP Protocol:

▪ Reliability: Reliability of message deliveries.
▪ Ensure Delivery: Rapid and ensured delivery of messages.
▪ Acknowledgements: It provides message acknowledgements that has been received
or not.
▪ Secure Connection: AMQP provides secured connection.
▪ Extensibility: AMQP has explicitly defined points of extensibility.

Parameter AMQP HTTP
AMQP v/s HTTP

Full Form Advanced Message Queuing Protocol. Hyper Text Markup Protocol.
Communication
It has asynchronous communication nature. It has synchronous communication nature.
Nature
It is user centric and it can be used in every

Usage It is easy to setup and manage.
aspect.
Message Delivery It has guaranteed message delivery. It has no guarantee for message delivery.
Interface It provides publish/subscribe interface. It provides point to point interface.
AMQP protocol can bear the server broke issue HTTP protocol is not capable to react to the
Fault Tolerance
on its own. server breakdown issue.
It has the property of segmentation and can It does not has this capability to treat each
Segmentation
process messages into slots. message as segments.
Protocol It is general purpose protocol and is used for

It is specific protocol used for specific purposes.
Characteristics multiple purposes.
It is well known, efficient and multi-purpose

Advantages It is fast, flexible and cost effective protocol.
protocol.
Ref: https://www.geeksforgeeks.org/difference-between-amqp-and-http-protocols/
Dr. Ashish Vanmali, VCET, Vasai Ref: https://microcontrollerslab.com/iot-protocols-types/ 83
Reference Books
❖Andrew Minteer, Analytics for the Internet of Things (IoT) - Intelligent

Analytics for Your Intelligent Devices
❖David Hanes et al., IoT Fundamentals Networking Technologies, Protocols,
and Use Cases for the Internet of Things
❖Peter Waher, Learning Internet of Things

CH 4 Edge To Cloud Protocol

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CH 4 Edge To Cloud Protocol

Uploaded by

Copyright:

Available Formats

Edge to Cloud

❖Web-based Application Layer Protocols

Dr. Ashish Vanmali, VCET, Vasai 2

Dr. Ashish Vanmali, VCET, Vasai 3

❖HTTP = Hyper Text Transfer Protocol

Ref: Andrew Minteer, Analytics

❖HTTP and IoT:

Dr. Ashish Vanmali, VCET, Vasai 5

❖Communication with HTTP:

Dr. Ashish Vanmali, VCET, Vasai 6

❖Methods of adding HTTP support to sensor:

Dr. Ashish Vanmali, VCET, Vasai 7

❖HTTP REST API:

Dr. Ashish Vanmali, VCET, Vasai 8

Dr. Ashish Vanmali, VCET, Vasai 10

❖Connect with HTTP-Compatibility:

Dr. Ashish Vanmali, VCET, Vasai 16

Dr. Ashish Vanmali, VCET, Vasai 17

Ref: David Hanes et al., IoT

❖CoAP = Constrained Application Protocol

Dr. Ashish Vanmali, VCET, Vasai 20

❖CoAP Message Format:

Ref: David Hanes et al.,

❖CoAP Message Format:

Dr. Ashish Vanmali, VCET, Vasai 24

❖CoAP Message Format:

Dr. Ashish Vanmali, VCET, Vasai 25

❖CoAP Message Format:

Dr. Ashish Vanmali, VCET, Vasai 26

Dr. Ashish Vanmali, VCET, Vasai 30

❖MQTT = Message Queuing Telemetry Transport

Dr. Ashish Vanmali, VCET, Vasai 31

❖MQTT Publish/Subscribe Framework:

Ref: David Hanes et al.,

Dr. Ashish Vanmali, VCET, Vasai 33

❖MQTT Message Format:

Dr. Ashish Vanmali, VCET, Vasai 34

❖MQTT Message Format:

Ref: David Hanes et al.,

❖MQTT Message Format:

Dr. Ashish Vanmali, VCET, Vasai 36

❖MQTT Message Format:

❖MQTT Message Format:

❖MQTT Message Format:

Dr. Ashish Vanmali, VCET, Vasai 41

Ref: David Hanes et al.,

Ref: David Hanes et al.,

Ref: David Hanes et al.,

Dr. Ashish Vanmali, VCET, Vasai 46

Dr. Ashish Vanmali, VCET, Vasai 47

❖MQTT-SN = MQTT for Sensor Networks

Dr. Ashish Vanmali, VCET, Vasai 52

❖MQTT-SN v/s MQTT:

❖MQTT-SN v/s MQTT:

Dr. Ashish Vanmali, VCET, Vasai 54

❖Transparent and Aggregating Gateways:

❖Transparent and Aggregating Gateways:

❖Transparent and Aggregating Gateways:

Dr. Ashish Vanmali, VCET, Vasai 59

❖STOMP = Streaming Text Oriented Messaging Protocol

Dr. Ashish Vanmali, VCET, Vasai 60

▪ Communication between server and client is through a MESSAGE, RECEIPT or ERROR