IoT Protocol Architecture/Stack

IoT Protocol Stack

IoT Protocol stack
consists of
• IoT Application,
• Device Management
services,
• Data management
and
• reporting services,
• communication
service at various
levels of IoT
communication and
likewise.
 Objective of this Topic
• Explain the principles of CoAP and how it
differs from traditional HTTP protocols.
• Understand how CoAP works over UDP and its
benefits for constrained devices.
• Identify CoAP’s architecture including clients,
servers, and proxy intermediaries.
• Compare CoAP with other IoT protocols like
MQTT and REST in terms of efficiency, speed,
and overhead.
CONSTRAINED APPLICATION PROTOCOL (CoAP)

• CoAP is a lightweight, specialized web transfer protocol

designed specifically for resource-constrained devices
in the Internet of Things (IoT).
• It is built on top of the User Datagram Protocol (UDP)
– The length of the message body is implied by the datagram
length. When bound to UDP, the entire message must fit
within a single datagram.
• Intended for simple, low-power devices that operate in
constrained environments, such as low-bandwidth or
lossy networks.
• CoAP can be seen as a specialized web transfer protocol
for use with constrained networks
 Key principles of CoAP

• Lightweight and Efficient

• CoAP is designed to work in environments with limited resources,
such as low-power sensors or devices with small amounts of
memory and processing power.
• It has low overhead in terms of message size, making it ideal for
constrained devices and networks.
• Based on REST Architecture
• CoAP follows the same principles as the Representational State
Transfer (REST) architecture, similar to HTTP.
• It supports familiar methods like GET, POST, PUT, and DELETE to
interact with resources (just like HTTP), making it easy for
developers to understand and use.
• CoAP messages are much more compact than HTTP messages, as
they are optimized for constrained networks.
 Key principles of CoAP

• Operates Over UDP (User Datagram Protocol)

• Unlike HTTP, which uses TCP (Transmission Control
Protocol), CoAP uses UDP, which is
connectionless.
• This makes CoAP faster and more efficient, but it
also means that it does not guarantee reliable
message delivery in the same way as TCP.
• However, CoAP includes optional mechanisms like
message acknowledgments (ACK) and
retransmissions to improve reliability.
 Key principles of CoAP
• Low Power and Low Latency
• CoAP is designed for low-power devices that may need to
operate on batteries for years.
• The use of UDP reduces the connection overhead, making
CoAP more suitable for low-latency communication where
devices need to wake up, send/receive data, and return to
sleep quickly.
• Asynchronous Communication
• CoAP supports asynchronous communication, meaning that
clients can send requests and get responses later,
• Devices can also send non-confirmable messages, which are
sent without requiring acknowledgment, further reducing
overhead when the reliability of delivery is not critical.
 Key principles of CoAP

• Built-in Discovery and Simplicity

• CoAP has built-in support for resource discovery.
• Devices can discover services and resources
available on the network using simple requests,
which helps to automate communication between
devices in dynamic environments.
• CoAP is also simpler compared to HTTP, as it’s
stripped down to essential features needed by
constrained devices, which results in less
complexity and resource usage.
 Key principles of CoAP
• Proxy Support
• CoAP can be used with proxies, allowing
communication between constrained networks
and more traditional IP networks (like the
internet).
• A CoAP-to-HTTP proxy can enable CoAP devices to
interact with HTTP services, which helps integrate
IoT devices into the broader internet ecosystem.
 CoAP and HTTP-Important differences

• Transport Layer (UDP vs. TCP)

– HTTP: Uses TCP, a connection-oriented protocol.
• TCP ensures reliable, ordered delivery of packets, but it
introduces higher overhead and latency due to
connection establishment, acknowledgments, and error
correction.
– CoAP: Uses UDP, a connectionless protocol.
• UDP is faster and more efficient because it does not
require a connection to be established or maintained.
• CoAP handles reliability at the application level through
acknowledgments and optional retransmissions.
 CoAP and HTTP-Important differences

• Message Overhead
• HTTP:
• HTTP headers are verbose(provides detailed
information) and can add significant overhead to each
message, which is fine for powerful servers but inefficient
for constrained devices.
• CoAP:
• CoAP uses compact binary headers and much smaller
message sizes.
• This makes it more suitable for devices with limited
bandwidth, memory, and processing power.
 CoAP and HTTP-Important differences
• Reliability
• HTTP:
• Provides guaranteed delivery and ordered messages through
TCP. If a message is lost, TCP ensures it is retransmitted.
• CoAP:
• Uses confirmable messages to achieve reliability.
• When a device sends a confirmable message, it waits for an
acknowledgment (ACK) from the recipient.
• If no ACK is received, the message is retransmitted.
• However, CoAP also supports non-confirmable messages,
which do not require an acknowledgment, trading reliability
for speed and simplicity.
 CoAP and HTTP-Important differences

• Stateless Communication
• HTTP:
• Is a stateless protocol, meaning each request/response
pair is independent, with no session state maintained
between messages.
• CoAP:
• Also follows a stateless model like HTTP.
• Each CoAP request-response pair is independent, but
CoAP can maintain state across multiple devices using
block-wise transfers to handle larger payloads in smaller
parts.
 CoAP and HTTP-Important differences

• Resource Discovery
• HTTP:
• Does not have built-in resource discovery; external
methods (such as using APIs or protocols like DNS
Service Discovery) are typically needed.
• CoAP:
• Has built-in mechanisms for resource discovery.
• Devices can advertise their resources, and other
devices can easily find them using the CoAP discovery
features.
 CoAP and HTTP-Important differences

• Security
• HTTP:
• Uses TLS (Transport Layer Security) over TCP for secure
communication, adding encryption and authentication,
which increases the overhead.
• CoAP:
• Uses DTLS (Datagram Transport Layer Security) over
UDP for encryption and authentication.
• DTLS is a lightweight version of TLS designed for
connectionless protocols like UDP, providing security
while maintaining low overhead.
 CoAP: Four types of messages
• Messages are used to communicate between
devices
• Each serving a specific purpose in communication
• Message types help manage communication
efficiency,Four types
reliability,
of messages
and flexibility for
constrained devices and networks
• Four types of messages
– confirmable (CON),
– non-confirmable (NON),
– acknowledgement,
– reset
 CoAP: Four types of messages
• Confirmable Message (CON)
• Purpose:
• A confirmable message is used when a device wants to
ensure that the message it sent is received by the other
device. It’s like sending a letter where you need a receipt
(acknowledgment) that the recipient got it.
– Example:
• A temperature sensor sends a confirmable message with
the current temperature to a smart thermostat.
• The thermostat acknowledges (ACK) that it received the
temperature.
• If the sensor doesn’t receive the acknowledgment, it will
resend the message.
 CoAP: Four types of messages
• Non-confirmable Message (NON)
• Purpose:
• A non-confirmable message is sent when the sender
doesn’t care whether the message is received or not.
It’s like broadcasting a message to a room where you
don’t expect anyone to respond.
• Example:
• A motion sensor sends a non-confirmable message to
the lights to turn on when it detects movement.
• The motion sensor doesn’t expect a response or
confirmation from the lights that the message was
received. If the message is lost, it won't resend it.
 CoAP: Four types of messages
• Acknowledgment Message (ACK)
• Purpose:
• An acknowledgment message is sent in response to a
confirmable message to tell the sender, “I got your
message.”
• Example:
• The thermostat sends an acknowledgment message
back to the temperature sensor after receiving the
current temperature.
• This lets the sensor know that its message was
successfully delivered.
 CoAP: Four types of messages
• Reset Message (RST)
• Purpose:
• A reset message is sent when the receiver gets a
message it can’t process or doesn’t understand. It’s like
saying, “I don’t understand this message, please stop.”
• Example:
• A smart light bulb receives a message from a controller
to turn on, but the message is corrupt or incorrect.
• The light bulb sends a reset message (RST) back to the
controller, telling it that the message couldn’t be
processed.
 CoAP: Four types of messages
• conceptual structure that divides CoAP into different functional layers,
simplifying communication and making it modular.

handling RESTful requests like GET, POST

managing reliability and message

providing transport

lightweight and efficient communication can

function over lossy and low-power networks
CoAP: Architecture
 CoAP: Architecture

• Client-Server Model:
• CoAP follows a basic client-server model, similar
to the web's HTTP system. The client sends a
request to access or manipulate resources, and
the server responds to that request.
• Client:
• Requests data or performs actions (e.g., a smart
thermostat asks for temperature data).
• Server:
• Provides data or responds to actions (e.g., a
temperature sensor sends back the current
temperature).
 CoAP: Architecture

• RESTful Design:
• CoAP is built around the REST (Representational
State Transfer) architecture, using familiar
methods like GET, POST, PUT, and DELETE to
interact with resources. Resources are identified
using URIs (just like URLs on the web).
• Example:
• A client may send a GET request to a sensor's URI to get
the current temperature reading.
CoAP: Architecture

UDP handshaking is lighter

and easier to implement
on microcontrollers.
A client requests a resource
at a URI (Uniform Resource
Identifier) and the server
responds.
 CoAP Packet Format
• Message of CoAP uses simple binary format.
Message= fixed-size 4-byte header plus a
variable-length Token plus a sequence of CoAP
options plus payload.
 CoAP Packet Format
• Version (VER) (2 bits)
– Indicates the CoAP version number.
• Type (2 bits)
– Indicates if this message is of type
• Confirmable (0),
• Non-confirmable (1),
• Acknowledgement (2), or
• Reset (3)
• Token Length (8 bits)
– Indicates the length of the variable-length Token field, which may be 0-8 bytes in
length.
• CoAP Request/Response Code (8 bits)
– The three most significant bits form a number known as the "class", which is
analogous to the class of HTTP status codes.
– Method: 0.XX Message ID (16 bits) Used
– Success : 2.XX 1. To detect message duplication
2. To match messages of type
– Client Error : 4.XX
Acknowledgement / Reset to messages of
– Server Error : 5.XX
type Confirmable/Non-confirmable.
– Signaling Codes : 7.XX
MQTT vs CoAP
 JSON
• JavaScript Object Notation
– A minimal, readable format for structuring data.
– It is used primarily to transmit data between a server and web application, as
an alternative to XML.
– XML is a markup language, JSON is a way of representing objects.
– JSON is preferred for IoT applications since it can self-describe and is more
programmatic, where X
– ML was made for document mark up like HTML.
• Keys and Values
– The two primary parts that make up JSON are keys and values. Together they
make a key/value pair.
• Key: A key is always a string enclosed in quotation marks.
• Value: A value can be a string, number, Boolean expression, array, or object.
• Key/Value Pair: A key value pair follows a specific syntax, with the key followed by a
colon followed by the value. Key/value pairs are comma separated.
 JSON
• A JSON value MUST be an object, array, number, or
string, or one of the following three literal names:
– false null true
• Types of Values
1."site_admin": false,
– Array: An associative array of values.
1."public_repos":
– Boolean: True or false. 838,
– Number: An integer.
– Object: An associative array of key/value pairs.
• An object structure is represented as a pair of curly brackets
surrounding zero or more key/value pairs (or members).
– String: Several plain text characters which usually form a
word.
1."location": "New york city",
 JSON
• Its Image member is an object whose Thumbnail
member is an object and whose IDs member is an
array of numbers.
Example
 Concise Binary Object Representation (CBOR)
• Limitation of JSON
– If your device operates on a constrained network
parsing and constructing JSON becomes difficult.
• This is when it’s better to use a lightweight binary
format such as CBOR
• CBOR is a data format whose design goals
include
– the possibility of extremely small code size,
– fairly small message size, and
– extensibility without the need for version compromise
 Concise Binary Object Representation (CBOR)

• The objectives of CBOR

– The representation must be able to unambiguously encode
most common data formats used in Internet standards.
– The code for an encoder or decoder must be able to be
compact in order to support systems with very limited
memory, processor power, and instruction sets.
– The format must be applicable to both constrained nodes
and high-volume applications.
– The format must support all JSON data types for conversion
to and from JSON.
– The format must be extensible, and the extended data must
be decodable by earlier decoders.
 Concise Binary Object Representation (CBOR)
• Decoder:
– A process that decodes a CBOR data item and makes it available to an
application. Formally speaking, a decoder contains a parser to break up the
input using the syntax rules of CBOR, as well as a semantic processor to
prepare the data in a form suitable to the application.
• Encoder:
– A process that generates the representation format of a CBOR data item from
application information.
 Concise Binary Object Representation (CBOR)

• Indefinite-Length Arrays and Maps

– Indefinite-length arrays and maps are simply opened
without indicating the number of data items that will be
included in the array or map, using the additional
information value of 31.