Scribd
Upload
7 views8 pages

Web Connectivity Principles in IoT (1)

Uploaded by

anayreddypalamakula033
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
7 views8 pages

Web Connectivity Principles in IoT (1)

Uploaded by

anayreddypalamakula033
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 8

Case Study

on
Web Connectivity Principles in IoT

by

KUMMARI MALLIKARJUNA
22R91A04D4

Department of Electronics and Communication Engineering

Teegala Krishna Reddy Engineering College


(UGC Autonomous) Medbowli, Meerpet, Balapur(M), Hyderabad,
Telangana-500097 April, 2025
we will explore various web connectivity technologies and protocols that allow
the connected devices in IoT to transfer data to the cloud and receive commands
or data back.

Data from connected devices route over the web in two types of communication
environments as given below:
 Unconstrained environment web applications use HTTP and RESTful
HTTP for web object communication between the client and the server. A
web object consists of 1000s of bytes. Data routes over the IP networks
for Internet connectivity. The web applications and web services use
TCP/IP protocols for network and transport layers.
 Constrained RESTful Environment (CoRE) devices application-support
layer use CoAP. The data is generally 10s of bytes at the client end. The
data gathered from numerous devices consists of 100s of bytes which,
after enriching and consolidation at the gateway, is communicated to the
web using the Internet. A constraint is data Routing Over Low power and
Lossy network (ROLL).

REpresentational State Transfer (REST) architectural style can be used for


HTTP or CoAP access by GET, POST, PUT and DELETE methods for the
resources, and building the web services.

Communication module consists of protocol handlers for web connectivity


protocols like:
 LightWeight Machine to Machine communication protocol (LWM2M)
 Constrained Application Protocol (CoAP)
 HyperText Transfer Protocol (HTTP)
 Message Queue Telemetry Transport (MQTT)
 Transport Layer Security (TLS)
 Datagram Transport Layer Security (DTLS)
Contents
 1 LWM2M
 2 CoAP
 3 MQTT
 4 REST
LWM2M
LWM2M protocol is an application-support layer protocol specified by Open
Mobile Alliance (OMA) for transfer of service data. It enables device
management in cellular or sensor networks.

It enables communication between a LWM2M client (an IoT device or a


machine object) and a LWM2M server or between a M2M LAN and a gateway.

Lightweight means it does not require more OS resources and is compact. It is


generally used along with CoAP.
CoAP
IETF recommends Constrained Application Protocol (CoAP) for the CoRE and
ROLL network data over the low-power lossy networks. CoAP is an open
standard for application-support layer for the constrained environment in place
of HTTP. CoAP is for asynchronous communication over IP.

CoAP features are as follows:


 CoAP web objects communicate using request/response interaction model
 A specialized web transfer protocol used for CoRE using ROLL networks
 Use of object model for resources, and each object can have multiple
instances
 Object or a resource uses CoAP, DTLS, and UDP for request and
response
 Supports the resource directory and discovery functions
 The resource identifiers uses the URI, coap://
 Has a small message header of 4 bytes
 Integrates easily with the web using the CoAP application cross-protocol
proxies
MQTT
Message Queuing Telemetry Transport (MQTT) is an open source protocol for
M2M/IoT connectivity. MQTT has been accepted as a OASIS (Organization for
the Advancement of Structured Information Standards) standard. MQTT is a
publish-subscribe messaging protocol.

MQTT features are:


 It is a constrained environment protocol.
 PubSub messaging architecture instead of request-response client-server
architecture. Publisher sends the messages on a topic, and a subscriber
receives the messages on a subscribed topic.
 MQTT is lightweight. It uses a fixed-length header of 2 bytes.
 Uses broker-based publish-subscribe model. Enables one to many
message distribution decoupled with the applications. Notifies on an
abnormal disconnection of a client. Notifies all nodes subscribing to the
message. Also notifies the will message (last will).
 Authentication by username/password in connect message and client
security through SSL/TLS.
 Messages can be published by a server at one time or at intermittent
intervals on a topic subscription by a client device.
Three Quality of Service (QoS) levels for message delivery:
 QoS 0: Deliver messages at most once on best effort basis by the network
(ex: street lights)
 QoS 1: Deliver message at least once (RFID parcel tracking)
 QoS 2: Deliver messages exactly once (ATM network)

MQTT broker does the following:


 Functions as a server node capable of storing messages from publishers
and forwarding them to the subscribing clients
 Receives topics from the publishers
 Performs a store-and-forward function
 Receives subscriptions from the clients on topics
 Acts as a broker between the publisher of the topics and subscriber of the
topics
REST
REST is an architectural style which is stateful, unlike HTTP. REST provides
guidelines and best practices for creating scalable web services. It was
developed by W3C.

REST system uses GET, POST, PUT, DELETE for retrieving web pages. REST
is an alternative to Simple Object Access Protocol (SOAP) and Web Services
Description Language (WSDL).

REST characteristics are data transfers which use the stateless, client-server,
cacheable. The resources themselves are conceptually separate from the
representations that are returned to the client.

For example, the server may send data as HTML, XML, or as JSON from the
database which can have another internal representation.

The formal REST constraints are:


 Uniform interfaces for simplification and decoupling of the architecture.
The four constraints for an uniform interface are:
o Identification of individual resources, identified in requests
o Separation of concerns (separation of clients and servers)
o Client holding representation of a resource to easily modify or
delete that resource
o Manipulation of resources
 Stateless client-server communication (no history of client is maintained
at server)
 Definable cache ability
 Option to transfer of executable code (ex: applets or scripts)

When all interactions used in the applications conform fully to the REST
constraints, it is called RESTful. REST architectural style can be used for HTTP
access by GET, POST, PUT and DELETE methods for the resources and for
building web services.

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy