Unit-iii-IoT Architecture and Protocols

Taxonomy:

Taxonomy refers to a process whereby items are named and classified according to their
similarities and differences. In the area of IoT, taxonomy is based on the architectural elements and
the protocols of IoT.

Architecture Reference Model

•An ARM consists of two main parts: a Reference model and a Reference Architecture.

•A reference model describes the domain using a number of sub-models

 IOT Reference architecture and reference model dependency

IOT Reference Model

IoT domain model
The domain model captures the basic attributes of the main concepts and the relationship between
these concepts. A domain model also serves as a tool for human communication between people
working in the domain in question and between people who work across different domains.

Information Model
Virtual Entity in the IoT Domain Model is the “Thing” in the Internet of Things, the IoT information
model captures the details of a Virtual Entity- centric model. Similar to the IoT Domain Model, the
IoT Information Model is presented using Unified Modelling Language (UML) diagrams.

Functional model
The IoT Functional Model aims at
describing mainly the Functional
Groups (FG) and their interaction with
the ARM, while the Functional View of
a Reference Architecture describes the
functional components of an FG,
interfaces, and interactions between the
components. The Functional View is
typically derived from the Functional
Model in conjunction with high-level
requirements.
Device functional group

The Device FG contains all the possible functionality hosted by the physical Devices that are used for
increment the Physical Entities. This Device functionality includes sensing, actuation, processing,
storage, and identification components, the sophistication of which depends on the Device capabilities

Communication functional group

The Communication FG abstracts all the possible communication mechanisms used by the relevant
Devices in an actual system in order to transfer information to the digital world components or other
Devices.

IoT Service functional group

The IoT Service FG corresponds mainly to the Service class from the IoT Domain Model, and contains
single IoT Services exposed by Resources hosted on Devices or in the Network (e.g. processing or
storage Resources).

Virtual Entity functional group

The Virtual Entity FG corresponds to the Virtual Entity class in the IoT Domain Model, and contains
the necessary functionality to manage associations between Virtual Entities with themselves as well as
associations between Virtual Entities and related IoT Services, i.e. the Association objects for the IoT
Information Model. Associations between Virtual Entities can be static or dynamic depending on the
mobility of the Physical Entities related to the corresponding Virtual Entities.

IoT Service Organization functional group

The purpose of the IoT Service Organisation FG is to host all functional components that support the
composition and orchestration of IoT and Virtual Entity services. Moreover, this FG acts as a service
hub between several other functional groups such as the IoT Process Management FG when, for
example, service requests from Applications or the IoT Process Management are directed to the
Resources implementing the necessary Services.

IoT Process Management functional group

The IoT Process Management FG is a collection of functionalities that allows smooth integration of IoT-
related services (IoT Services, Virtual Entity Services, Composed Services) with the Enterprise
(Business) Processes.

Management functional group

The Management FG includes the necessary functions for enabling fault and performance monitoring
of the system, configuration for enabling the system to be flexible to changing User demands, and
accounting for enabling subsequent billing for the usage of the system. Support functions such as
management of ownership, administrative domain, rules and rights of functional components, and
information stores are also included in the Management FG.
Security functional group

The Security FG contains the functional components that ensure the secure operation of the system as
well as the management of privacy. The Security FG contains components for Authentication of Users
(Applications, Humans), Authorisation of access to Services by Users, secure communication (ensuring
integrity and confidentiality of messages) between entities of the system such as Devices, Services,
Applications, and last but not least, assurance of privacy of sensitive information relating to Human
Users.

Application functional group

The Application FG is just a placeholder that represents all the needed logic for creating an IoT
application. The applications typically contain custom logic tailored to a specific domain such as a Smart
Grid

Communication model
Safety

The IoT Reference Model can only provide IoT-related guidelines for ensuring a safe system to the
extent possible and controllable by a system designer. Eg: smart grid.

Privacy

Because interactions with the physical world may often include humans, protecting the User privacy is
of utmost importance for an IoT system. The IoT-A Privacy Model depends on the following functional
components: Identity Management, Authentication, Authorisation, and Trust & Reputation

Trust

Generally, an entity is said to ‘trust’ a second entity when the first entity makes the assumption that the
second entity will behave exactly as the first entity expects.”

Security

The Security Model for IoT consists of communication security that focuses mostly on the
confidentiality and integrity protection of interacting entities and functional components such as Identity
Management, Authentication, Authorisation, and Trust & Reputation.

IoT Reference Architecture

•Functional View: Description of what the system does, and its main functions.

•Information View: Description of the data and information that the system handles.

•Deployment and Operational View: Description of the main real world components of the system
such as devices, network routers, servers, etc.
IOT Functional View

Device and Application functional group

Devices are like phone, machines

Communication functional group

The Hop-by-Hop Communication is applicable in the case that devices and messages have to traverse
the mesh from node-to-node (hop-by-hop) until they reach a gateway node which forwards the message
(if needed) further to the Internet.

This FC has two main interfaces:

 one “southbound” to/from the actual radio on the device, and
 one “northbound” to/from the Network FC in the Communication FG.

The Network FC is responsible for message routing & forwarding and the necessary translations of
various identifiers and addresses.

The translations can be

(a) between network layer identifiers to MAC and/or physical network identifiers,
(b) between high-level human readable host/node identifiers to network layer addresses and
(c) translation between node/service identifiers and network locators in case the higher layers above the
networking layer use node or service identifiers

The End-to-End Communication FC is responsible for end-to-end transport of application layer

messages through diverse network and MAC/PHY layers.
IoT Service functional group
 The IoT Service FC is a collection of service implementations, which interface the related and
associated Resources.
 For a Sensor type of a Resource, the IoT Service FC includes Services that receive requests from
a User and returns the Sensor Resource value in synchronous or asynchronous (e.g.
subscription/notification) fashion.
 The IoT Service Resolution FC contains the necessary functions to realize a directory of IoT
Services that allows dynamic management of IoT Service descriptions and
discovery/lookup/resolution of IoT Services by other Active Digital Artifacts.

Virtual Entity functional group

 The Virtual Entity FG contains functions that support the interactions between Users and
Physical Things through Virtual Entity services.
 An example of such an interaction is the query to an IoT system of the form, “What is the
temperature in the conference room Titan?”

Process Management functional group

The IoT Process Management FG, integration of business processes with IoT-related services. It
consists of two FCs:

 The Process Modelling FC provides that right tools for modelling a business process that utilizes
IoT-related services.
 The Process Execution FC contains the execution environment of the process models created
by the Process Modelling FC and executes the created processes by utilising the Service
Organisation FG in order to resolve high-level application requirements to specific IoT services

Service Organization functional group

 The Service Composition FC manages the descriptions and execution environment of complex
services consisting of simpler dependent services.
 An example of a complex composed service is a service offering the average of the values
coming from a number of simple Sensor Services.
 The Service Orchestration FC resolves the requests coming from IoT Process Execution FC or
User into the concrete IoT services that fulfill the requirements.

The Service Choreography FC is a broker for facilitating communication among Services using the
Publish/Subscribe pattern. Users and Services interested in specific IoT-related services subscribe to
the Choreography FC, providing the desirable service attributes even if the desired services do not
exist.

Security functional group

 The Security FG contains the necessary functions for ensuring the security and privacy of an IoT
system.
  The Identity Management FC manages the different identities of the involved Services or Users
in an IoT system
 The The Authentication FC verifies the identity of a User and creates an assertion upon
successful verification. verifies the identity of a User and creates an assertion upon successful
verification.
 The Authorization FC manages and enforces access control policies. It provides services to
manage policies (CUD), as well as taking decisions and enforcing them regarding access rights
of restricted resources.
 The Key Exchange & Management is used for setting up the necessary security keys between
two communicating entities in an IoT system.
 The Trust & Reputation FC manages reputation scores of different interacting entities in an IoT
system and calculates the service trust levels.
Management functional group
* The Configuration FC maintains the configuration of the FCs and the Devices in an IoT system.
The component collects the current configuration of all the FCs and devices, stores it in a
historical database, and compares current and historical configurations.
* The Fault FC detects, logs, isolates, and corrects system-wide faults if possible. This means that
individual component fault reporting triggers fault diagnosis and fault recovery procedures in
the Fault FC.The component collects the current configuration of all the FCs and devices, stores
it in a historical database, and compares current and historical configurations.
* The Member FC manages membership information about the relevant entities in an IoT
system.
* The State FC is similar to the Configuration FC, and collects and logs state information from the
current FCs, which can be used for fault diagnosis, performance analysis and prediction, as well
as billing purposes.
* The Reporting FC is responsible for producing compressed reports about the system state
based on input from FCs. ii-font-family

IOT Information View

Information Description
 Virtual Entity context information, i.e. the attributes (simple or complex) as represented by
parts of the IoT Information model.
 IoT Service output itself is another important part of information generated by an IoT system.
For example, Sensor or a Tag Service.
 Virtual Entity descriptions in general, which contain not only the attributes coming from IoT
Devices (e.g. ownership information).
 Virtual Entity Associations with other Virtual Entities (e.g. Room #12 is on floor#7)
 Resource Descriptions –> type of resource (e.g. sensor), identity, associated Services, and
Devices.
 Device Descriptions –> device capabilities (e.g. sensors, radios).
 Descriptions of Composed Services –> the model of how a complex service is composed of
simpler services.
 IoT Business Process Model describes –> the steps of a business process utilizing other IoT-
related services.
 Management information such as state information from operational FCs used for
fault/performance purposes, configuration snapshots, reports, membership information, etc.
 Three-layer and five-layer architecture of IoT

There is no single consensus on architecture

for IoT, which is agreed universally. Different
architectures have been proposed by different
iot developers.

The most basic architecture is a three-layer

architecture as shown in figure A:

It was established in the initial phases of

study in this area. The architecture comprises
of three layers, namely, the perception,
network, and application layers

The perception layer (or object layer/devices layer): The perception is the external layer with
sensors for sensing and collecting environmental data. In the environment, it detects those physical
parameters or recognizes certain smart objects. The physical devices include different types of sensors
like the ones based on micro-electromechanical systems (MEMS) technology.

Many different types of Sensors are available for this use like proximity sensors, light sensors,
gesture and optical sensors, touch and fingerprint sensors, pressure sensors, and many more.
Standardized plug and play mechanisms are used by the physical layer to consolidate and construct
the heterogeneous types of sensors that belong to the IoT device ecosystem. The data collected at this
layer is passed on to the next layer using different network channels.

The network layer: The network layer provides the link between network devices and servers to
create smart devices or IoT. Its features are also used for transmitting and processing sensor data. The
data transmission can happen using any of the following technologies:
RFID GSM Wi-Fi Infrared
3G UMTS Bluetooth low energy ZigBee

Specialized processes for handling functions such as cloud computing and data management are also
present in this layer.

The application layer: The application layer makes it possible to provide specific services to
users. It is that part of the IoT architecture that outlines the various applications for IoT to be deployed,
for example, in smart homes and smart health. This layer is responsible for meeting the various kinds
of services requested by users (customers). The type of service requested by the customer depends on
the specific use case that is adopted by the customer.
For example, if a smart home is the use case under consideration, then the customer may request for
specific parameters such as heating, ventilation, and air conditioning (HVAC) measurements or
temperature and humidity values. This layer provides the various types of smart services, which are
offered by various IoT verticals. Some of the prominent IoT verticals are as follows:
Smart cities Smart buildings or homes Smart industry
Smart energy Smart living
Smart health care Smart transportation
The five-layer architecture
The three-layer architecture defines the main idea of the IoT, but it is not sufficient for research on IoT
because research often focuses on finer aspects of the IoT. That is why we have many more layered
architectures proposed in the literature.
The five-layer architecture includes the two layers of perception and application, describe in figure B:

The transport layer: The transport layer is responsible for transferring sensor’s data from the
perception layer to the processing layer and vice versa by means of a variety of connectivity such as
RFID, NFC, LAN, Bluetooth, and many more.

The processing layer: This is where the middleware layer which stores, analysis, and processes
a large amount of data in the transport layer architecture. It manages the different services to the
lower layers and uses technologies such as databases, cloud computing, and Big Data processing
modules to achieve its functions.

The business layer: This part of the architecture manages and responsible for the whole IoT
system. This layer includes the applications, business and the profit models as well as user privacy. It
performs the overall management of all IoT activities and services. This layer uses the data that are
received from the network layer to build various components such as business models, graphs, and
flowcharts. This layer also has the responsibility to design, analyze, implement, evaluate, and monitor
the requirements of the IoT system. This layer can use big data analysis to support decision-making
activities. This layer also performs a comparison of obtained versus expected outputs to enhance the
quality of
services.
Cloud and fog based architecture of IoT
Fog based architecture or also known as fog networking uses edge devices to perform a
significant amount of computation, storage, and communicate locally over the Internet backbone. Fog
in IoT utilizes a decentralized computing infrastructure in which data storage, computing, and
applications are located somewhere between the data source and the cloud. Thus, it makes it possible
to bring the benefits of the cloud closer to where data is created or produced and acted upon.
In recent times, the trend is to advocate for Fog computing as system architecture. In this
respect, sensors and network gateways are used in data processing and analytics. This type of
architecture offers a layered approach that covers areas of control, storage, and protection between
the physical and transport layers, while the monitoring layer takes control of the power, resources and
services.
Cloud-based architecture of IoT Cloud computing provides scalable and flexible services which
include information storage options, software tools and analytics, suitable platform, and core
infrastructure for the development. It is an extension of cluster and grid computing used to collect
resources at one place and utilize them to high-performance computing.
It provides three types of services namely; Software as a Service (SaaS), Platform as a Service
(PaaS) and Infrastructure as a Service (IaaS). It also provides mobility features for information handling
and storage is reloadable from nearby clients. We can also have big data, machine learning as well as
data analytics along with cloud computing for more information. The nature of information sensed as
well as produced in the form of data by an IoT device.
The cloud platform receives and aggregate data summaries from many fog nodes, and it also
performs analysis on IoT data and data from other sources to gain business insight. Cloud computing
architecture can send new application rules to the fog nodes:

Data processing in the cloud and fog-based architectures of IoT

The figure describes how data is being processed between fog and cloud-based architecture.
The left part of the figure shows the cloud layer which consists of three layers, at the center is cloud
layer, above the cloud layer is an application of layers and below the cloud layer is a network of things
layer. The right side of the figure describes the fog-based architecture of IoT. It consists of six layers
physical, transport, security, monitoring, pre-processing, and storage.
Fog based architecture
Fog based architecture presents a layered approach which inserts monitoring, pre-processing,
storage and security layers between the physical and transport layers. Fog based architecture is also
known by another name that is edge-based architecture. Fog based architecture is an advanced version
of cloud-based architecture.
Fog computing acts on IoT data in milliseconds, based on policy and sends selected data to the
cloud for long–term storage. Fog computing performance is better than cloud computing for handling
user request. Fog computing has flexible infrastructure.
In fog-based structure, response time is low, unlimited number of users as well as resources.
Besides sending a vast amount of data to the cloud, it analyzes most time-sensitive data at the network
edge. Mainly fog architecture considered only the four layers, that is, the following layers of fog
architecture are:
Monitoring layer: It performs the monitoring functions like check the availability of resources
and requirement of services by the clients and various responses.
Pre-processing layer: It helps in analyzing the data by doing filtering processes.
Storage layer: The data from the pre-processing layer is sent to the storage layer. It helps in
storage in a different format as per requirement and needs with suitable protocols.
Security layer: It helps in offering privacy status to the data flow as well as helpful in the
encryption and decryption of data.

Figure shows that the fog lies at the

centre, cloud lies above the fog layer where the
data is stored whereas device lies below the fog:
The most time-sensitive data are
analyzed on the fog node closest to the things
generating the data. In a Cisco Smart Grid
distribution network, for example, the most
time-sensitive requirement is to verify that
protection and control loops are operating properly. Therefore, the fog nodes closest to the grid
sensors can look for signs of problems and then prevent them by sending control commands to
actuators.
Data that can wait seconds or minutes for action is passed along to an aggregation node for
analysis and action. In the Smart Grid example, each substation might have its aggregation node that
reports the operational status of each downstream feeder and lateral.
Data that is less time-sensitive is sent to the cloud for historical analysis, big data analytics, and
long-term storage (see sidebar).
For example, each of thousands or hundreds of thousands of fog nodes might send periodic
summaries of grid data to the cloud for historical analysis and storage

Advantages of fog computing

Greater business agility: Developers with proper skills and tools develop applications and
market them according to the requirement or demand. Fog applications help in operating the
machinery and tools in the way of customer requirement.
Better security: With the proper privacy and along with the cybersecurity solutions, protect fog
nodes for better security by using the proper procedures as well as using the same policy. Deeper
insights, with privacy control: Fog computing analyse sensitive data locally instead of sending it to the
cloud for analysis.
 Lower operating expense: It Conserves network bandwidth by processing selected data locally
instead of sending it to the cloud for analysis.

IoT Protocols
There are various protocols on various layers when we compare them based on architecture.
The main and most important layers are transport layer, and internet layer as only these two layers
are majorly responsible for the transfer of information from one location to another. Most of the bugs
and attacks are also made on this layer.
For example, if we are transferring the data between two machines then while transferring the
data, an attacker can intercept the data in between if the connection is not secure by using man in the
middle attack. Let’s discuss the function of each protocol in detail:
 There are two dominant data exchange protocol architectures:

1. Broker based: In this architecture, Broker controls the distribution of information. It stores,
forwards, filters and prioritizes public requests from the publisher client to the subscriber clients.
Clients switch between publisher role and subscriber roles depending on the functionalities desired.
EXAMPLES of broker based protocols:

➤AMPQ: Advanced Message Queuing Protocol

➤CoAP: Constrained Applications Protocol
➤MQTT: Message Queue Telemetry Transport
➤JMS: Java Message Service API

2. Bus based: In this architecture, clients publish messages for a specific topic which are directly
delivered to the subscribers of that topic. There will not be any centralized broker or any broker based
services here. EXAMPLES of bus based protocols:

➤DDS(Data Distribution Service)

➤REST(Representational State Transfer)
➤XMPP(Extensible Messaging Presence Protocol)
6LowPAN
6LoWPAN stands for IPv6 over Low-Power Wireless Personal Area Networks. It is an open
standard defined in RFC 6282 by the Internet engineering task force (IETF). The key feature of
6LoWPAN that makes it suitable for IoT communication is that though it was originally designed to
support IEEE 802.15.4 low-power wireless networks in the 2.4-GHz band, it now supports a wide range
of networking media such as sub-1 GHz low-power RF, Bluetooth smart, power line control (PLC), and
low-power Wi-Fi.

Network Architecture of 6LoWPAN

The architecture of 6LoWPAN mesh network is depicted in the diagram that is given in below Figure.
The uplink to the Internet is provided by the access point (AP), which in this case is an IPv6 router.
Different types of devices such as PCs and servers could be connected to the AP. The components of
the 6LoWPAN network are connected to the IPv6 network using a 6LoWPAN edge router. Following
are the functions performed by the edge router:
 It enables exchange of data between 6LoWPAN devices and the Internet (or other IPv6
network).
 It enables exchange of data among devices that are part of 6LoWPAN network.
 It helps to generate and maintain the 6LoWPAN network

 It works great with open IP standard including TCP, UDP, HTTP, COAP, MATT and web-sockets.
 It offers end-to-end IP addressable nodes. There’s no need for a gateway, only a router which can
connect the 6LoWPAN network to IP.
 It supports self-healing, robust and scalable mesh routing.
 Offers one-to-many & many-to-one routing.
 The 6LoWPAN mesh routers can route data to others nodes in the network.
 In a 6LowPAN network, leaf nodes can sleep for a long duration of time.
 It also offers thorough support for the PHY layer which gives freedom of frequency band & physical
layer, which can be used across multiple communication platforms like Ethernet, WI-Fi, 802.15.4
or Sub-1GHz ISM with interoperability at the IP level.
 It is a standard: RFC6282

6LoWPAN Application Areas

» Automation: There are enormous opportunities for 6LoWPAN

to be used in many different areas of automation.
» Industrial monitoring: Industrial plants and automated
factories provide a great opportunity for 6LoWPAN. Major
savings can be made by using automation in every day
practices. Additionally, 6LoWPAN can connect to the cloud
which opens up many different areas for data monitoring and
analysis.
» Smart Grid: Smart grids enable smart meters and other
devices to build a micro mesh network. They are able to send
data back to the grid operator’s monitoring and billing system
using the IPv6.
» Smart Home: By connecting your home IoT devices using IPv6, it is possible to gain distinct
advantages over other IoT systems.

6LoWPAN Security
* 6LoWPAN can use AES-128 link layer security which is defined in IEEE 802.15.4. This provides
link authentication and encryption.
* Further security is provided by the transport layer security mechanisms. This is defined in RFC
5246 and runs over TCP.
* For systems where UDP is used, the transport layer protocol defined under RFC 6347 can be
used
RPL
RPL stands for routing protocol for low power and lossy networks. It is an IPv6 protocol. Low power
Lossy networks include wireless personal area networks (WPANs), low-power line communication
(PLC) networks, and wireless sensor networks (WSNs). These networks have some characteristics:
o Capability to optimize and save energy
o Capability to support traffic patterns other than unicast communication
o Capability to run routing protocols over link layers with restricted frame sizes

1. What is a low power/lossy network? How does that relate to IoT?

“LLN: Low-Power and Lossy Network. Typically composed of many embedded devices with
limited power, memory, and processing resources interconnected by a variety of links, such as
IEEE 802.15.4 or low-power Wi-Fi. There is a wide scope of application areas for LLNs,
including industrial monitoring, building automation (heating, ventilation, and air
conditioning (HVAC), lighting, access control, fire), connected home, health care,
environmental monitoring, urban sensor networks, energy management, assets tracking, and
refrigeration.”

2. What is RPL and how does it work (high level)?

RPL was designed to support minimal routing needs by building a highly robust topology over lossy networks.
This protocol provides support for various types of traffic models: multi point-to-point, point-to-multipoint,
and point-to-point. It is a Distance Vector (DV) protocol and Source Routing Protocol.
Devices in the network that use this protocol are connected to each other in such a way that no cycles are
present in the connection.

What is a Distance Vector (DV) protocol?

● Distance-vector protocols are based on calculating the Direction and Distance to any link
in a network.
− "Direction" usually means the next hop address and the exit interface.
− "Distance" is a measure of the cost to reach a certain node.
● The least cost route between any two nodes is the route with minimum distance.
● Each node maintains a vector (table) of minimum distance to every node.
● The cost of reaching a destination is calculated using various route metrics
What is a Source Routing (path addressing) protocol?
Allows a sender of a packet to partially or completely
specify the route the packet takes through the network.
Enables a node to discover all the possible routes to a host.
RPL organizes a topology as a...

...Partitioned into one or more...

A DAG rooted at a single destination at a single

DAG root (DODAG root) with no outgoing
edges

A RPL Instance is a set of one or more

DODAGs that share a RPLInstanceID.

To Identify and maintain a topology RPL uses...

RPL Instance ID is a unique identifier within a network. DODAGs with the same RPL
Instance ID share the same Function (OF) used to compute the position of node in the DODAG.

DODAG Version Number

A DODAG Version is a specific iteration of a DODAG
with a given DODAGID A DODAG Version Number Is a
sequential counter that is incremented by the root to form a
new version
Rank
Defines the node's Individual position Relative to other
nodes with respect to DODAG root

Grounded and Floating DODAG

● A grounded DODAG offers connectivity to hosts that are required for satisfying the
application goal
● A floating DODAG is not expected to satisfy the goal, it only provides routes to nodes within
the DODAG. e.g, provide interconnectivity during repair

RPL routers work under one of the two modes of operation (MOP):
Storing and Non-Storing Mode-of-Operation
● A storing LLN keeps a downward routing table at each node.
○ traffic travels only as far as common parent.
○ storing mode limited by size of routing table
■ nodes with lower rank, have bigger tables!
■ protocol fails when any table is full.
● A non-storing LLN sends all traffic to root. Root uses source routes to send traffic to leafs.
○ limited by ram of DODAG root/6LBR, but usually non-constrained device
○ requires more bits on wire, which often is more expensive (energy wise) than more
ram, or compute cycles.
● New work (“dao-projection”) tries to add some routes to non-storing mode.
● Original protocol (pre-2011) thought to mix and match, but this proved unworkable.

CoAP
Constrained application protocol (CoAP) is a specialized web transfer protocol for use with
constrained nodes and constrained networks in the IoT space. The protocol is designed for
M2Mapplications such as smart energy and building automation. CoAP includes several HTTP
functionalities, which have been redesigned for M2M applications over constrained environments on
the IoT. That is, it takes into account the low processing power and energy constraints of small
embedded devices, such as sensors.

In addition, CoAP offers a number of features that HTTP lacks such as built-in resource
discovery, IP multicast support, native push model, and asynchronous message exchange. There are
many implementations of CoAP in various languages, such as libcoap1 (an open-source C-
implementation) and Sensinode’s NanoService2.
 The comparison of HTTP and CoAP stacks is pictorially indicated in Figure

 CoAP is a software protocol intended to be used in very simple electronics devices that allow
them to communicate interactively over the Internet. It is particularly targeted for small low-
power sensors, switches, valves, and other similar components that need to be controlled or
supervised remotely, through standard Internet networks.
 CoAP is an application layer protocol that is intended for use in resource-constrained Internet
devices, such as WSN nodes.
 CoAP is designed to easily translate to HTTP for simplified integration with the web, while also
meeting specialized requirements such as multicast support, very low overhead, and simplicity.
Multicast, low overhead, and simplicity are extremely important for IoT and M2M devices,
which tend to be deeply embedded and have much less memory and power supply than
traditional Internet devices have. Therefore, efficiency is very important.
 CoAP can run on most devices that support UDP or a UDP analog.

CoAP Architecture
 The CoAP messaging model is primarily designed to facilitate the exchange of messages
over UDP between endpoints, including the secure transport protocol Datagram Transport
Layer Security (DTLS).
From a formatting perspective, a 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. Below Figure details the CoAP message format, which delivers
low overhead while decreasing parsing complexity.

The CoAP message format is relatively simple and flexible. It allows CoAP to deliver low
overhead, which is critical for constrained networks, while also being easy to parse and process
for constrained devices

CoAP message
header Description

Ver It is 2 bit unsigned integer. It mentions CoAP version number. Set to one.

It is 2 bit unsigned integer. Indicates message type viz. confirmable (0),

T non-confirmable (1), ACK (2) or RESET(3).

TKL It is 4 bit unsigned integer, Indicates length of token (0 to 8 bytes).

It is 8 bit unsigned integer, It is split into two parts viz. 3 bit class (MSBs)
Code and 5 bit detail (LSBs).

16 bit unsigned integer. Used for matching responses. Used to detect

Message ID message duplication.

Token With length specified by TKL, correlates request and response.

 Specifies options number, length and option value. Capabilities provided by
the Options field include specifying the target resource of a request and
Options proxy functions

Carries the CoAP application data. This filed is optional, when it present, a
single byte of all 1s(0xFF) precedes the payload. The purpose of this byte is
Payload to delineate the end of the Options filed and beginning of Payload.

CoAP Protocol Message Exchanges

 There are two modes in which CoAP protocol messages get exchanged between CoAP
client and CoAP server viz. without separate response and with separate response.

 With separate response, server notifies client about receipt of the request message.
This will increase processing time but help in avoiding unnecessary retransmissions.
 CoAP IoT is unreliable protocol due to use of UDP. Hence CoAP messages reach
unordered or will get lost when they arrive at destination.
 To make CoAP as reliable protocol, stop and wait with exponential back off
retransmission feature is incorporated in it. Duplicate detection is also introduced.
 CoAP can run over IPv4 or IPv6. However, it is recommended that the message
fit within a single IP packet and UDP payload to avoid fragmentation. For IPv6, with
the default MTU size being 1280 bytes and allowing for no fragmentation across
nodes, the maximum CoAP message size could be up to 1152 bytes, including 1024
bytes for the payload.
In the case of IPv4, as IP fragmentation may exist across the network,
implementations should limit themselves to more conservative values and set the
IPv4 Don’t Fragment (DF) bit.

CoAP communications across an IoT infrastructure can take various paths.

Connections can be between devices located on the same or different constrained
networks or between devices and generic Internet or cloud servers, all operating over
IP. Proxy mechanisms are also defined, and RFC 7252 details a basic HTTP mapping
for CoAP.
As both HTTP and CoAP are IP-based protocols, the proxy function can be
located practically anywhere in the network, not necessarily at the border between
constrained and non-constrained networks.

Just like HTTP,

CoAP is based on the
REST architecture, but
with a “thing” acting as
both the client and the
server. Through the
exchange of
asynchronous messages,
a client requests an
action via a method code
on a server resource. A
uniform resource
identifier (URI) localized on the server identifies this resource. The server responds
with a response code that may include a resource representation. The CoAP
request/response semantics include the methods GET, POST, PUT, and DELETE.
 Message Queuing and Telemetry System (MQTT)
At the end of the 1990s, engineers from IBM and Arcom (acquired in 2006 by
Eurotech) were looking for a reliable, lightweight, and cost-effective protocol to
monitor and control a large number of sensors and their data from a central server
location, as typically used by the oil and gas industries. Their research resulted in
the development and implementation of the Message Queuing Telemetry Transport
(MQTT) protocol that is now standardized by the Organization for the
Advancement of Structured Information Standards (OASIS).

MQTT (Message Queuing Telemetry Transport) is a messaging protocol for

restricted low-bandwidth networks and extremely high-latency IoT devices. Since Message
Queuing Telemetry Transport is specialized for low-bandwidth, high-latency
environments, it is an ideal protocol for machine-to-machine (M2M) communication. MQTT
supports messaging between devices to the cloud and the cloud to the device.

MQTT is the most commonly used messaging protocol for the Internet of Things (IoT).
MQTT stands for MQ Telemetry Transport.

 The protocol is a set of rules that defines how IoT devices can publish and subscribe to data
over the Internet.

 MQTT is used for messaging and data exchange between IoT and industrial IoT (IIoT)
devices, such as embedded devices, sensors, industrial PLCs, etc.

 MQTT works on the publisher / subscriber principle and is operated via a central broker.

 The sender (Publisher) and the receiver (Subscriber) communicate via Topics and are
decoupled from each other. This means that the sender and receiver have no direct
connection.

 The connection between them is handled by the MQTT broker. The MQTT broker filters all
incoming messages and distributes them correctly to the Subscribers.

 The data sources report their data via a publish and all recipients with interest in certain
messages (“marked by the topic”) get the data delivered because they have registered as
subscribers.

MQTT architecture and protocol overview

The MQTT architecture is made up of the following key parts: MQTT broker and MQTT client.

MQTT broker (server): An MQTT broker or server is software running on a computer that receives
messages from external sources–publishers, and then routes them to the appropriate destination-–
subscribers. The computer can be a Raspberry Pi, an on premise desktop PC, or a cloud-based server
running open-source or proprietary software. One of the most popular open-source message brokers
is the Mosquito broker. You can have your own instance of Mosquito running on your own PC. But
rather than using the Mosquito on a local PC, there are readily available cloud-based servers such
as Eclipse IoT, ThingMQ, CloudMQTT, and Heroku that implement the Mosquito broker. They’re
particularly useful in situations where you want your IoT projects to be controllable over the Internet.

Depending on the implementation, a broker can manage up to thousands of simultaneously connected

MQTT clients. Therefore when choosing an MQTT broker, you should consider factors such as
scalability and integration. In addition to receiving and routing messages to clients, the broker also
delivers other capabilities such as:

 Quality of Service (QoS): The QoS feature allows the MQTT protocol to provide additional
messaging qualities of service that ensure that the message in transit is delivered as required
by the service.

 MQTT provides a choice of three different levels of quality of service for message delivery as
follows:

QoS 0: at most once delivery – best effort message delivery with no confirmation of
receipt.
QoS 1: at least once delivery – message receipt is acknowledged, duplicates are
possible.
QoS 2: exactly once delivery – message receipt confirmed, no duplicates

 Store and Forward: Just as the name implies, MQTT provides support for storing persistent
messages on the broker.
 Security: MQTT broker may require username and password authentication from clients to
connect for security. To ensure the privacy of messages in transit, the TCP connection may be
encrypted with SSL/TLS.

MQTT client (publishers and subscribers): MQTT clients can be any device or application ranging from
a simple Arduino microcontroller to a full cloud-hosted application server that runs an MQTT library
and connects to an MQTT broker over a network. MQTT clients can be either a publisher, a subscriber,
or both. These two functions can be implemented in the same MQTT client.

During the communication phase, a

client can perform connect, publish,
subscribe, unsubscribe and disconnect
operations as the case may be. There
are fourteen defined message types
used to connect and disconnect a client
from a broker, to publish data, to
acknowledge receipt of data, and to
supervise the connection between
client and server
MQTT Message format:

• MQTT messages contain a mandatory fixed-length header (2 bytes) and an optional message-specific
variable length header and message payload.
• Optional fields usually complicate protocol processing.
• However, MQTT is optimized for bandwidth constrained and unreliable networks (typically wireless
networks), so optional fields are used to reduce data transmissions as much as possible. MQTT uses
network byte and bit ordering.
 How does MQTT work?
1. An MQTT client establishes a connection with the MQTT broker.
2. Once connected, the client can either publish messages, subscribe to specific messages, or do both.
3. When the MQTT broker receives a message, it forwards it to subscribers who are interested.

MQTT topic
The term ‘topic’ refers to keywords the MQTT broker uses to filter messages for the MQTT clients.
Topics are organized hierarchically, similar to a file or folder directory. For example, consider a smart
home system operating in a multilevel house that has different smart devices on each floor. In that
case, the MQTT broker may organize topics as:
ourhome/groundfloor/livingroom/light
ourhome/firstfloor/kitchen/temperature

MQTT publish

MQTT clients publish messages that contain the topic and data in byte format. The client determines
the data format such as text data, binary data, XML, or JSON files. For example, a lamp in the smart
home system may publish a message on for the topic livingroom/light.

MQTT subscribe
MQTT clients send a SUBSCRIBE message to the MQTT broker, to receive messages on topics of
interest. This message contains a unique identifier and a list of subscriptions. For example, the smart
home app on your phone wants to display how many lights are on in your house. It will subscribe to
the topic light and increase the counter for all on messages.
What are the benefits of using MQTT?
The lightweight properties and minimum overhead of the MQTT protocol architecture help ensure
smooth data transfer with low bandwidth and reduce the load on the CPU and RAM. Among MQTT's
advantages over competing protocols are the following:
 efficient data transmission and quick to implement, due to its being a lightweight protocol;
 low network usage, due to minimized data packets;
 efficient distribution of data;
 successful implementation of remote sensing and control;
 fast, efficient message delivery;
 uses small amounts of power, which is good for the connected devices; and
 Optimizes network bandwidth.

What are the drawbacks of MQTT?

Potential downsides to MQTT include the following:
 MQTT has slower transmit cycles compared to Constrained Application Protocol (CoAP).
 MQTT's resource discovery works on flexible topic subscription, whereas CoAP uses a stable
resource discovery system.
 MQTT is unencrypted. Instead, it uses TLS/SSL (Transport Layer Security/Secure Sockets Layer) for
security encryption.
 It is difficult to create a globally scalable MQTT network.
 Other MQTT challenges relate to security, interoperability and authentication.