Internet of Things
Module 2 – Application Protocols
Application protocol
Application protocol
• It handles communications Web
between things, sensors, Server
Client
or
gateways and applications Things/
using the WWW Sensors
• Data flows from sensor
nodes, things, or gateways
to applications
• Control information, such as
triggers or actuations,
Application
flows from the web server to Gateway Layer Protocol
things
• The web server uses
application layer protocols
Application protocol
Application protocol
Request-Response model
1 Request-Response model
2 Publish Subscribe model
3 Constrained Application Protocol
4 Message Queue Telemetry Transport
Extensible Messaging and Presence
5
Protocol
Request-Response model
Application protocol
Request-Response model
• Is a stateless communication model
• Is complex for a large number of clients
• The usage of the application protocol is in HTTP
• A client sends requests to a server
– the client is a web browser
• The server responds to the client
– application on the computer hosting a website is a server
Request
Resources
Response
Client Server
Request-Response model
Application protocol
Request-Response model
• Client-Server Interaction
– The client sends requests to the server, such as asking for a web page
– The server responds with the requested content or data, enabling the
client to display or use it
• Communication Model
– The stateless model means each request is independent,
with no memory of previous interactions
– This design simplifies request handling but requires all
necessary information to be included in each request
• Model Characteristics
– The model is simple because it treats each request in isolation
– High coupling between client and server can make
managing numerous clients complex
Request-Response model
Application protocol
Request-Response model
• Application Protocol
– HTTP(Hypertext Transfer Protocol) governs the
exchange of requests and responses on the web
– It defines how clients and servers communicate and transfer web
content
• Example
– The client is a web browser requesting web pages
– The server is the application hosting the website,
providing the
requested content
Application protocol
Application protocol
Request-Response model
Publish Subscribe model 1 Request-Response model
2 Publish Subscribe model
3 Constrained Application Protocol
4 Message Queue Telemetry Transport
Extensible Messaging and Presence
5
Protocol
Publish Subscribe model
• Publish-subscribe model contains
– Publisher
• source of data
– Subscriber
• receiver of data
– Broker
• It allows for unidirectional communication between
multiple subscribers
• The subscribers subscribe to some topics
• The publisher is unaware of the subscribers
• An example of this protocol is Message
Queue Telemetry Transport (MQTT)
Publish Subscribe model
Application protocol
Request-Response model • It is similar to the request-response model
Publish Subscribe model but supports unidirectional communication
Topic: temperature laptop
Consumer1
Publish
Temperature sensor
Publisher
MQTT-Broker
Broker
Topic1
Topic2
. Mobile device
.
Consumer n
Publish Subscribe model
Application protocol
Request-Response model • Communication Dynamics
Publish Subscribe model – Multiple subscribers (receivers) and a single
– Communication
Dynamics
publisher (source of data) interact
– Coupling and – Subscribers subscribe to specific topics of interest
Notification
– The publisher pushes new data to all
subscribers for those topics, enabling a
one-to-many distribution
• Coupling and Notification
– Loose coupling: The publisher does not need to
know about the subscribers
– Asynchronous and non-blocking
notifications: Subscribers do not wait for
message publication
Application protocol
Application protocol
Request-Response model
Publish Subscribe model 1 Request-Response model
– Communication
Dynamics
– Coupling and
Notification 2 Publish Subscribe model
– Polling and
Efficiency
– Protocol Application
Constrained 3 Constrained Application Protocol
Example
Protocol
4 Message Queue Telemetry Transport
Extensible Messaging and Presence
5
Protocol
Constrained Application Protocol
Application protocol
Request-Response model • Is standardized by Internet Engineering Task Force
Publish Subscribe model (IETF) in RFC 7252
– Communication
Dynamics • Is designed for constrained devices of IoT networks
– Coupling and
Notification • CoAP uses a 4 bytes short fixed-length
– Polling and
Efficiency
binary header
– Protocol Application
Constrained – that may be followed by compact
Example
Protocol binaryoptions and a payload
• It supports the multicast IP destination address
as CoAP runs over UDP
• It uses Datagram Transport Layer Security (DTLS)
over UDP
HTTP and CoAP Abstract Layer
HTTP
Abstract layer of CoAP Server
Application HTTP
TCP 3-way GET / HTTP TCP 2-way
Handshake light
Request/ Response CoAP 200 OK Termination
Message HTTP
Client
UDP
HTTP request
HTTP and CoAP Abstract Layer
Application protocol
Request-Response model • HTTP Message Exchange
Publish Subscribe model • For a GET request, a total of 7 messages
– Communication
Dynamics are exchanged
– Coupling and
Notification
– 3 messages for establishing the TCP session
– Polling and – 1 message for the HTTP request from the client
Efficiency
– Protocol Application
Constrained – 1 message for the HTTP response from the server
Example
Protocol – 2 messages for terminating the TCP session
– HTTP and CoAP
Abstract Layer
HTTP and CoAP Abstract Layer
Application protocol
Request-Response model • CoAP Abstract Layer
Publish Subscribe model • Is a Two-Layer Approach
– Communication
Dynamics – Message Layer: Handles UDP and the
– Coupling and
Notification
asynchronous nature of interactions
– Polling and • Types of messages: Confirmable, Non-
Efficiency Confirmable,
– Protocol Application
Constrained Acknowledgment, and Reset
Example
Protocol
– HTTP and CoAP
– Request/Response Layer: Manages request and response
Abstract Layer interactions
• Methods: GET, PUT, POST, and DELETE
• Security
– CoAP uses Datagram Transport Layer Security (DTLS)
over UDP for securing communication
Unreliable and Reliable Transmission in CoAP
Application protocol
Request-Response model • The two types of messages in CoAP
Publish Subscribe model are
– Communication
Dynamics – NON (non-confirmable message)
– Coupling and – CON (confirmablemessage
• Non-confirmable message)
Notification
– Polling and
Efficiency
– It does not require reliability
– Protocol Application
Constrained – Example: Sensor nodes sending measurement
Example
Protocol data without expecting an acknowledgment
– HTTP and CoAP
Abstract Layer – It uses a message ID (MID) for duplicate detection (e.g.,
– Unreliable and Reliable MID = 0xABCD)
Transmission in CoAP
• Non-confirmable – If the server cannot process a NON message, it responds
message
with a RST (Reset)
Unreliable and Reliable Transmission in CoAP
Application protocol
Request-Response model
Publish Subscribe model
– Communication Unreliable Message Reliable Message
Dynamics
Server Transmission Server Transmission
– Coupling and
Notification
– Polling and
Efficiency NON [0 x CON [0xWXYZ]
– Protocol Application
Constrained ABCD] ACK [0xWXYZ]
Example
Protocol
Client Client
– HTTP and CoAP
Abstract Layer
– Unreliable and Reliable
Transmission in CoAP Confirmable and non-confirmable messages
Unreliable and Reliable Transmission in CoAP
Application protocol
Request-Response model • CON (Confirmable Message)
Publish Subscribe model – It provides reliability
– Communication
Dynamics – Retransmitted after a default time-out with
– Coupling and exponential back-off until an ACK is received
Notification
– Polling and – If the server cannot process the CON message,
Efficiency it responds with a RST (Reset) instead of an ACK
– Protocol Application
Constrained
Example
Protocol
– The message ID (MID) must be the same for both CON
– HTTP and CoAP and ACK (e.g., MID = 0xWXYZ)
Abstract Layer
– Unreliable and Reliable
Transmission in CoAP
• Non-confirmable
message
• CON (Confirmable
Message)
Request/Response Models in CoAP
GET Request with Piggybacked GET Request with Piggybacked
Response - Successful Response - Unsuccessful
Server Server
CON [0 x ABCD] CON [0 x ABCDE]
GET humidity ACK [0 x ABCD] GET humidity ACK [0 x ABCDE]
Token 0x71 2.05 Content Token Token 0x72 4.04 Content Token
0x71 “12 %” 0x72 “Not found”
Client Client
GET request with piggybacked response
Token acts as a request ID
Request/Response Models in CoAP
Application protocol
Request-Response model
• Token in CoAP
Publish Subscribe model – It is used to match responses with requests
Constrained Application
Protocol
– It is different from the message ID
– HTTP and CoAP • It acts as a request ID
Abstract Layer
– Unreliable and Reliable
– Every request should include a token, even if it is of zero
Transmission in CoAP length
– Request/Response
Models in CoAP • Response Codes
• Token in CoAP
• Response Codes –A successful response may have codes such as
2.05 (Content) or 2.03 (Valid)
– These codes are included in the response to
indicate success
Request/Response Models in CoAP
Application protocol
Request-Response model
• Piggybacked Response
Publish Subscribe model – If the response to a CON (Confirmable)
Constrained Application message
immediatelyis ready, it is included in the
Protocol
– HTTP and CoAP ACK (Acknowledgment) message. This is
Abstract Layer piggybacked response
known as a
– Unreliable and Reliable
Transmission in CoAP – No separate acknowledgment for the piggybacked
– Request/Response response is required; the client is expected to re-request
Models in CoAP
• Token in CoAP if the ACK is lost
• Response Codes
• Piggybacked
Response
Separate Response in CON and NON
GET Request and Response in CON GET Request and Response in
NON
Server Server
CON [0 x BDAF] CON [0xDAFC] NON [0 x BDAG]
GET humidity 2.05 Content GET humidity
ACK [ Token 0x73 ACK [ NON[0XBDAG]
Token 0x73 0xBDAF] Token 0x74
“12%” 0xDAFC] 2.05 Content Token
0x74 “12%”
Client Client
GET request with response
Separate Response in CON and NON
Application protocol
Request-Response model
• The server sends an empty ACK to avoid
Publish Subscribe model further retransmissions from the client
Constrained Application
Protocol • Later, the server sends a new CON
– HTTP and CoAP (Confirmable)
message when it is ready, which the client
Abstract Layer
– Unreliable and Reliable acknowledges
Transmission in CoAP
– Request/Response • Response to NON Messages
Models in CoAP – If the request is made using a NON (Non-
– Separate Response in
CON and NON Confirmable) message, the response is also sent in a separate
NON message
– Alternatively, the server may use a CON message
for the response
• Token Importance
– The token is crucial for matching requests and responses
Message Format in CoAP
Application protocol
Request-Response model
• The message header is fixed-size 4 bytes followed
Publish Subscribe model by message which consists of variable-length
Constrained Application
Protocol
token value (0 to 8 bytes size), optional
– HTTP and CoAP options and payload
Abstract Layer
– Unreliable and Reliable • Version (Ver) field of CoAP
Transmission in CoAP
– Request/Response
– Is a version number which is of 2 bits
Models in CoAP – Here, bits 01 in binary is equivalent to 1 in decimal and
– Separate Response in
CON and NON other combinations are reserved for future use.
– Message Format in
CoAP
Message format
CoAP version
number For Example, CON [0xABCD] Get/ humidity
Bit
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 1516 1718 19 20 2122 2324 2526 27 28 2930 31
Ver=1 T=0
TKL =1 Code = 0.01 Message ID = 0xABCD
Token, if any
Option, if any
Payload
Message Format in CoAP
Application protocol
Request-Response model
• Type (T) is made of 2 bits
Publish Subscribe model • The types of message are as follows
Constrained Application
Protocol – 0 for confirmable
– HTTP and CoAP
Abstract Layer
– 1 for non-confirmable
– Unreliable and Reliable – 2 for ACK
Transmission in CoAP
– Request/Response – 3 for reset
Models in CoAP
– Separate Response in • Token Length (TKL)
CON and NON
– Is of 4 bits
– Message Format in
CoAP – The size of variable-length token field is between 0 and
Message Format in
CoAP
8 bytes
Message Format in CoAP
Application protocol
Request-Response model
• CODE
Publish Subscribe model – Is of 8 bits out of which 3 most significant bits for class
Constrained Application (0 to 7 in decimal) and 5 least significant bits for
Protocol
– HTTP and CoAP code (00 to 31 in decimal) in the form [Link]
Abstract Layer
– Unreliable and Reliable
• Message ID
Transmission in CoAP – Is of 8 bits for detecting message duplication, and to
– Request/Response
Models in CoAP match ACK message with CON/NON message
– Separate Response in
CON and NON
– Message Format in
CoAP
Message Format in
CoAP
Application protocol
Application protocol
Request-Response model
Publish Subscribe model 1 Request-Response model
Constrained Application
Protocol
Message Queue 2 Publish Subscribe model
Telemetry Transport
3 Constrained Application Protocol
4 Message Queue Telemetry Transport
Extensible Messaging and Presence
5
Protocol
Message Queue Telemetry Transport (MQTT)
Application protocol
Request-Response model
• It is TCP-based application layer protocol
Publish Subscribe model • It is suitable for constrained devices
Constrained Application
Protocol • It provides higher throughput and lower
Message Queue
Telemetry Transport
latency compared to CoAP
• It is designed by IBM, latest version MQTT
v3.1
adopted for IoT by Outcome and Assessment
Information Set (OASIS) standard.
– supports multicast communication
– uses the publish-subscribe model
MQTT broker
Application protocol
Request-Response model Reliable Message
Publish Subscribe model Transmission
Constrained Application
Protocol Publisher
Message Queue Publish
Telemetry Transport (topic)
– MQTT broker
Broker
Subscribe Publish
(topic) (topic)
Subscriber
Message Queue Telemetry Transport (MQTT)
Application protocol
Request-Response model
• Additionally, it uses hierarchical QoS as
Publish Subscribe model presented below:
Constrained Application
Protocol • QoS Level 0
Message Queue – The sender tries at most once and the delivery
Telemetry Transport
– MQTT broker
is not guaranteed
– QoS Level 0 – The receiver does not send an acknowledgment
– The message is neither stored nor re-transmitted. This is
simple and has a low overhead
– An example includes sensor sending measurements for a
long time and some may be missed
Message Queue Telemetry Transport (MQTT)
Application protocol
Request-Response model
• QoS Level 1
Publish Subscribe model – The sender stores and retransmit multiple times till the
Constrained Application receipt of the acknowledgment from the receiver,
Protocol
Message Queue that is, at-least once
Telemetry Transport – The delivery is guaranteed
– MQTT broker
• however, duplicate message is possible
– QoS Level 0
– QoS Level 1 • QoS Level 2
– QoS Level 2
– The message is delivered only once, that is exactly once
– For example, billing system (invoice)
Message Queue Telemetry Transport
Application protocol
Request-Response model
• MQTT Wild Cards
Publish Subscribe model – Topic
Constrained Application • is a UTF-8 string that broker uses to filter messages for each
Protocol
Message Queue
subscriber
Telemetry Transport • MQTT supports the hierarchical topic and
– MQTT broker
– QoS Level 0 uses forward-slash (/) like folders and files of a
– QoS Level 1 computer
– QoS Level 2
– MQTT Wild Cards – For example, iot/sensor/light
• Topics are case-sensitive and must have at least
a character
• Wild card is used by the subscriber, not
the publisher
Message Queue Telemetry Transport
Application protocol
Request-Response model
• Single-Level Wildcard (+)
Publish Subscribe model • It matches any string at a single topic level in
Constrained Application
Protocol the topic filter
Message Queue
Telemetry Transport
• Example:
– MQTT broker – iot/+/EEG will match
– QoS Level 0
• iot/sensor/libelium/EEG,
– QoS Level 1
– QoS Level 2 • iot/eHealthSens/EEG,
– MQTT Wild Cards • and iot/sensor5/EEG
• Single-Level
Wildcard (+) • It is useful for subscribing to messages related
to EEG signals from various sensors
Message Queue Telemetry Transport
Application protocol
Request-Response model
• Multi-Level Wildcard (#)
Publish Subscribe model • It matches any string for zero or multiple
Constrained Application
Protocol topic levels at the end of the topic filter
Message Queue
Telemetry Transport
• Example:
– MQTT broker – iot/ehealthSens/# will match
– QoS Level 0
• iot/ehealthSens/EEG,
– QoS Level 1
– QoS Level 2 • iot/ehealthSens/ECG,
– MQTT Wild Cards • iot/ehealthSens/EEG/singleChannel,
• Single-Level
iot/ehealthSens/EEG/singleChannel/5,
Wildcard (+)
• Multi-Level Wildcard • iot/ehealthSens/battery
(#)
– Useful for subscribing to all messages under a
specific hierarchical path, including all sub-levels
Application protocol
Application protocol
Request-Response model
Publish Subscribe model 1 Request-Response model
Constrained Application
Protocol
Message Queue 2 Publish Subscribe model
Telemetry Transport
Extensible Messaging
and Presence Protocol
3 Constrained Application Protocol
4 Message Queue Telemetry Transport
Extensible Messaging and Presence
5
Protocol
Extensible Messaging and Presence Protocol
Application protocol
Request-Response model
• Is standardized in RFC 6120 and 6121
Publish Subscribe model • Open-source and commonly used in IoT networks
Constrained Application
Protocol • Protocol Characteristics
Message Queue – Text-based protocol supporting instant messaging
Telemetry Transport
Extensible Messaging
between users
and Presence Protocol – Operates over TCP or HTTP
– Supports bidirectional requests and both client-server
and publish-subscribe models
• XMPP has built-in TLS mechanisms for encryption,
enhancing security compared to MQTT and CoAP,
which do not include encryption within the protocol
itself.
Extensible Messaging and Presence Protocol
Application protocol
Request-Response model
• It uses Extensible Markup Language (XML) text
Publish Subscribe model format for communication
Constrained Application
Protocol • The limitations are as follows
Message Queue – It does not provide QoS, the size of the message
Telemetry Transport
Extensible Messaging
becomes large because of XML language, and
and Presence Protocol inconvenient for networks with bandwidth constraints